Размещено на http://www.allbest.ru/

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ АВТОНОМНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ

«НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ ЯДЕРНЫЙ УНИВЕРСИТЕТ «МИФИ»

ЭКОНОМИКО-АНАЛИТИЧЕСКИЙ ИНСТИТУТ НИЯУ МИФИ КАФЕДРА №71

«ЭКОНОМИКА И МЕНЕДЖМЕНТ В ПРОМЫШЛЕННОСТИ»

Магистерская программа

Бизнес-информатика в высокотехнологичных отраслях экономики

Пояснительная записка

НИРМ на тему

Разработка формализованного описания бизнес-процесса с использованием UML

Магистр группы_У01-71БИ

Андрякова Анна Александровна

Руководитель Золотухина Елена Болеславовна

МОСКВА 2016 г.



ЗАДАНИЕ НА НАУЧНО-ИССЛЕДОВАТЕЛЬСКУЮ РАБОТУ МАГИСТРА

Тема: Разработка формализованного описания бизнес-процесса с использованием UML (название процесса уточняется).

Студент Андрякова Анна Александровна

Цель работы

Повышение эффективности процесса (название процесса уточняется)

Решаемые задачи

1. Изучение и анализ существующий методологий разработки АС

2. Разработка формализованного описания бизнес-процесса (название процесса уточняется)

3. Разработка регламента бизнес-процесса (название процесса уточняется)

4. Определение требований пользователей к автоматизированной системе, поддерживающей бизнес-процесс (название процесса уточняется)

5. Разработка модели автоматизированной системы, поддерживающе бизнес-процесс (название процесса уточняется)

6. Разработка ТЗ на создание автоматизированной системы, поддерживающей бизнес- процесс (название бизнес-процесса уточняется)

Объект исследования

Деятельность в сфере связанной с бизнес-процессом (название бизнес-процесса уточняется)

Предмет исследования

Средства и методы повышения эффективности в сфере связанной с бизнес-процессом (название бизнес-процесса уточняется)

Задания по основным разделам (исходные данные)

1. Актуальность работы

Актуальность обусловлена необходимостью автоматизации процесса (название процесса уточняется)

2. Научная новизна

Научная новизна заключается в создании формализованного описания бизнес-процесса (название бизнес-процесса уточняется) с использованием UML

3. Теоретическая и практическая значимость

Теоретическая и практическая значимость заключается в разработке регламентированного описания бизнес-процесса (название бизнес-процесса уточняется)

4. Публикации: 2-е тезисов на международных конференциях, 2-е статьи (ВАК, СКОПУС)



Аннотация

В данной научно-исследовательской работе содержатся: постановка целей и задач, актуальность рассматриваемой задачи и ее практическая новизна. Так же проведен анализ и сделаны выводы, определяющие дальнейшую работу над поставленной задачей.



Введение

автоматизированный система методология пользователь

В настоящее время вопрос создания востребованной автоматизированной системы очень актуален. Для правильного проектирования и разработки автоматизированной системы необходимо не только выбрать эффективные технологии и средства разработки, обеспечить необходимый бюджет и найти квалифицированных разработчиков, но и следовать правилам, по которым участники проекта распределяют задачи между собой, взаимодействуют друг с другом и создают необходимые отчетные единицы, которые существуют в каждой организации. Такие правила и определяют методологию, с помощью которой разрабатываются различные автоматизированные системы. Под автоматизированной системой подразумевается система состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций. Такие системы как правило существуют, или создаются в некоторой конкретной организации и обеспечивает ее деятельность. Таким образом каждая автоматизированная система уникальна. Также автоматизированная система обязательно предполагает выполнение пользователем заданных функций по формализованным правилам, т.е. если перед работниками организации просто поставили компьютеры и не дали четких указаний как и что делать, это не будет автоматизированной системой.

Основными признаками автоматизированной системы являются:

1. Наличие технических средств;

2. Программное обеспечение;

3. Персонал.

При этом происхождение первых двух составляющих значения не имеет, они могут быть закуплены, а могут быть разработаны специально для данной системы.

Кроме того, автоматизированная система всегда создается исполнителем для заказчика. А в качестве заказчика всегда выступает та организация, которая намерена автоматизировать свою деятельность, в то время как исполнители могут быть разными.

Главной целью создания автоматизированных систем является категоризация и стандартизация автоматизируемого процесса, что позволяет обеспечивать стабильность работы системы, простоту ее контроля и анализа слабых мест и основания для ее развития или свертывания.

Разработка автоматизированных систем еще долго будет актуальна и востребована, т.к. в случае правильной автоматизации деятельности организаций, она упрощает принятие решений и уменьшает требуемое время для решения проблем для руководителей любого уровня.

Методологией разработки автоматизированной системы является совокупность правил, принципов, идей, понятий, методов и средств, определяющих способ создания и разработки автоматизированной системы.

На данный момент существует множество различных методологий создания и разработки автоматизированных систем со своими особенностями.

Актуальность данной научной работы обусловлена тем, что в настоящее время множество процессов нуждаются в автоматизации для упрощения работы с ними, в том числе и рассматриваемый бизнес-процесс (название уточняется).



Глава 1. Анализ методологий разработки автоматизированных систем

1.1 Разработка шаблона паспорта

В ходе изучения литературы о различных методологиях разработки автоматизированных систем было принято решение о разработке паспорта автоматизированной системы, для упрощения процесса сравнения методологий и выбора наилучшей.

Так же было принято решение, что паспорт должен содержать следующие пункты: название методологии; этапы работ; модели жизненного цикла, поддерживаемые методологией; ролевой состав; поддержка документирования; формализованное описание методологии; инструментальная поддержка методологии; класс проекта; достоинства; недостатки; поддержка этапа бизнес - проектирования. Шаблон паспорта методологии представлен в Таблице 1.

Таблица 1. Шаблон паспорта методологии

Название методологии	Название методологии с расшифровкой
Этапы работ	Этапы работ, поддерживаемые методологией
Модели жизненного цикла, поддерживаемые методологией	Модели жизненного цикла, которые поддерживает методология при разработке автоматизированных систем
Ролевой состав	Поддержка методологией ролевого состава, т.е. четко прописанный состав команды разработчиков
Поддержка документирования	Поддерживает ли методология отдельный этап создания документации или создание документации в процессе одного из этапов
Формализованное описание методологии	Поддерживает ли методология формализованное описание протекающих процессов
Инструментальная поддержка методологии	Список программ поддерживающих методологию
Класс проекта	Наименование класса проекта (большой, средний, малый), для разработки которого используется методология
Достоинства	Описание основных плюсов методологии
Недостатки	Описание основных минусов методологии
Поддержка этапа бизнес - моделирования	Поддерживает ли методология бизнес - моделирования, если да, то на каком этапе

1.2 Описание методологий разработки автоматизированных систем

В настоящее время существует огромное множество различных методологий создания и разработки автоматизированных систем. Для их сравнения было принято решение создать унифицированный паспорт методологии, отражающий основные ее особенности. Были созданы паспорта наиболее распространенных и популярных методологий, применяемых для создания и разработки автоматизированных систем.

1.2.1 ГОСТ 34й серии

ГОСТы 34й серии представляют собой требования к составу и содержанию эксплуатационной документации на автоматизированную систему. Однако за счет правил и требований к документации, описанных в ГОСТах этой серии, их можно принимать как полноценную методологию разработки автоматизированных систем. В ГОСТах 34й серии четко прописаны этапы работ и состав документации, что позволяет четко спланировать работу команды разработчиков.

Стадии создания автоматизированных систем в ГОСТах 34й серии подразделяются на этапы работ:

1. Формирование требований к АС

1.1. Обследование объекта и обоснование необходимости создания АС.

1.2. Формирование требований пользователя к АС.

1.3. Оформление отчёта о выполненной работе и заявки на разработку АС (тактико-технического задания)

2. Разработка концепции АС

2.1. Изучение объекта.

2.2. Проведение необходимых научно-исследовательских работ.

2.3. Разработка вариантов концепции АС, удовлетворяющего требованиям пользователя.

2.4. Оформление отчёта о выполненной работе.

3. Техническое задание (Разработка и утверждение технического задания на создание АС).

4. Эскизный проект

1.1. Разработка предварительных проектных решений по системе и её частям.

1.2. Разработка документации на АС и её части.

5. Технический проект

1.1. Разработка проектных решений по системе и её частям.

1.2. Разработка документации на АС и её части.

1.3. Разработка и оформление документации на поставку изделий для комплектования АС и (или) технических требований (технических заданий) на их разработку.

1.4. Разработка заданий на проектирование в смежных частях проекта объекта автоматизации.

6. Рабочая документация

1.1. Разработка рабочей документации на систему и её части.

1.2. Разработка или адаптация программ.

7. Ввод в действие

7.1. Подготовка объекта автоматизации к вводу АС в действие.

7.2. Подготовка персонала.

7.3. Комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями).

7.4. Строительно-монтажные работы.

7.5. Пусконаладочные работы.

7.6. Проведение предварительных испытаний.

7.7. Проведение опытной эксплуатации.

7.8. Проведение приёмочных испытаний.

8. Сопровождение АС

8.1. Выполнение работ в соответствии с гарантийными обязательствами.

8.2. Послегарантийное обслуживание. [2, 4, 5]

Паспорт методологии по ГОСТ 34й серии представлен в Таблице 2.

Таблица 2. Паспорт методологии по ГОСТ 34й серии

1. Название методологии	ГОСТ 34й серии
2. Этапы разработки АС	Основные: 1. Формирование требований к АС, 2. Разработка концепции АС, 3. Техническое задание, 4. Эскизный проект, 5. Технический проект, 6. Рабочая документация, 7. Ввод в действие, 8. Сопровождение АС
3. Модели ЖЦ, поддерживаемые методологией	Любая
4. Ролевой состав	Не поддерживает
5. Поддержка документирования	Да
6. Формализованное описание методологии	Отсутствует
7. Инструментальная поддержка методологии	Возможно использование CASE-средств
8. Класс проекта	Любые АС
9. Достоинства	§ Самодостаточность для создания любой АС
10. Недостатки	§ Отсутствие формализованного описания § Отсутствие поддержки вспомогательных и управленческих процессов § Большое число оформляемых документов § Не поддерживает управленческие и часть вспомогательных процессов создания АС
11. Поддержка этапа бизнес-моделирования	Да

ГОСТы 34 серии позволяют избежать ситуаций недопонимая в группе разработчиков, т.к. они комплексно ориентированы на систему и единую терминологию. Так же серия этих ГОСТов помогает достичь высокой степени формализации проекта, что исключает случаи неполной документации по проекту. [2, 5]

Не смотря на все свои плюсы, ГОСТы 34 серии описывают устаревший «плановый» подход к управлению предприятием, что для нынешних проектов не актуально, и описывают не сами процессы разработки, а лишь формулируют требования к ним. К тому же большая часть понятий в этих стандартах определяются слишком широко, что может привести к недопониманию между заказчиком и разработчиком. [5, 9]

Однако, перечисленные выше особенности не мешают использовать ГОСТов 34й серии разработчикам для создания больших проектов. Кроме того существует дополнение к данной серии ГОСТов позволяющая опустить этапы работ, которые не подходят к разрабатываемой автоматизированной системе.

1.2.2 ARIS - методология

ARIS - методология - это одноименная методология и тиражируемый программный продукт для моделирования бизнес-процессов организаций. Продукт и методология принадлежат немецкой компании Software AG как результат поглощения компании IDS Scheer автора методологии Августа-Вильгельма Шеера. Любая организация в методологии ARIS рассматривается с пяти точек зрения: организационной, функциональной, обрабатываемых данных, структуры бизнес-процессов, продуктов и услуг. При этом каждая из этих точек зрения разделяется ещё на три подуровня: описание требований, описание спецификации, описание внедрения. [1, 3, 9]

Паспорт ARIS - методологии представлен в Таблице 3.

Таблица 3. Паспорт ARIS - методологии.

1. Название методологии	ARIS
2. Этапы работ	Основные: 1. Постановка задачи, 2. Определение требований, 3. Написание проектной спецификации, 4. Описание реализации, 5. Физическая реализация.
3. Модели ЖЦ, поддерживаемые методологией	Трехфазовая модель ЖЦ
4. Ролевой состав	Поддерживает. Зависит от модели
5. Поддержка документирования	Да
6. Формализованное описание методологии	Да
7. Инструментальная поддержка методологии	Семейство продуктов ARIS и ее модулей
8. Класс проекта	Средние, большие
9. Достоинства	§ Обладает большим набором функций. § Предусмотрена возможность анализа построенных моделей. § Возможность рассматривать объект с разных точек зрения. § Применяя дополнительные модули и внутренний язык программирования, пользователь может сформировать любые регламенты и положения.
10. Недостатки	§ Достаточно высокая стоимость программного обеспечения. § Для освоения основных функциональных возможностей ARIS придется посетить несколько специализированных учебных курсов продолжительностью от пяти до пятнадцати дней. § Система содержит большое количество функций, которые, возможно, никогда не будут востребованы. § Невозможность генерации каких-либо кодов или БД при проектировании, с использованием case средств, поддерживающих методологию.
11. Поддержка этапа бизнес-моделирования	Да

Одним из важных преимуществ ARIS - методологии является то, что она обладает большим набором функций, а так же в ней предусмотрена возможность анализа построенных моделей и рассмотрения объекта с разных точек зрения, что позволяет обнаружить и устранить ошибки и предоставить заказчику практически идеальный продукт. Кроме того применяя дополнительные модули и внутренний язык программирования, пользователь может сформировать любые необходимые регламенты и положения. [1, 3]

Однако, ARIS - методология отличается тем, что имеет достаточно высокую стоимость программного обеспечения. А за счет большого количества функций, которые могут быть и вовсе не востребованы, необходимо довольно длительное обучение персонала для их освоения. [1, 9]

Несмотря на все свои отличительные черты ARIS - методология крайне востребована, в том числе и в нашей стране, и пользуется большой популярностью у крупных компаний, использующих ее для проектов, относящихся к классу средних и больших.

1.2.3 CDM - методология

Методология CDM является развитием давно разработанной версии Oracle CASE-Method, применяемой в CASE-средстве Oracle CASE.

Методология Oracle CDM выделяет следующие процессы, протекающие на протяжении жизненного цикла ИС:

§ Определение производственных требований,

§ Исследование существующих систем,

§ Определение технической архитектуры,

§ Проектирование и построение баз данных,

§ Проектирование и реализация модулей,

§ Конвертирование данных,

§ Документирование,

§ Тестирование,

§ Обучение,

§ Переход к новой системе,

§ Поддержка и сопровождение. [9]

Паспорт CDM - методологии представлен в Таблице 4.

Таблица 4. Паспорт CDM - методологии

1. Название методологии	Oracle CDM (Oracle Custom Development Method)
2. Этапы работ	Основные: 1. Определение требований, 2. Анализ, 3. Проектирование, 4. Реализация, 5. Внедрение, 6. Эксплуатация.
3. Модели ЖЦ, поддерживаемые методологией	Каскадная модель ЖЦ
4. Ролевой состав	Да
5. Поддержка документирования	Да
6. Формализованное описание методологии	Нет
7. Инструментальная поддержка методологии	Набор инструментов Oracle
8. Класс проекта	Большие
9. Достоинства	§ Уменьшение себестоимости разработки. § Уменьшение количества ошибок, снижение цены ошибки. § Прогнозирование сроков, предсказуемость затрат и результатов. § Снижение рисков работодателя, независимость от персоналий.
10. Недостатки	§ Жесткая ориентация на линейку продуктов Oracle. § Сложна в использовании. § Необходимость обучения методологии.
11. Поддержка этапа бизнес-моделирования	Да

Одним из главных преимуществ данной методологии является значительное уменьшение себестоимости разработки, а так же снижение количества ошибок при разработке и соответственно снижение цены ошибки. Кроме того CDM - методология позволяет спрогнозировать сроки, предсказать затраты и результаты, что позволяет снизить риски работодателя.

Однако CDM - методология жестко ориентирована на линейку продуктов Oracle и сложна в использование, а следовательно при ее использовании необходимо обучить персонал. [9]

Не смотря на это данная методология очень востребована среди групп опытных разработчиков и активно ими используется для больших проектов.

1.2.4. RAD - методология

Следующая не менее популярная методология это RAD - методология. RAD - методология - это жизненный цикл процесса проектирования, созданный для достижения более высокой скорости разработки и качества ПО, чем это возможно при традиционном подходе к проектированию. С конца XX века RAD - методология получила широкое распространение и одобрение. [9]

Паспорт RAD - методологии представлен в Таблице 5.

Таблица 5. Паспорт RAD - методологии

1. Название методологии	RAD (Rapid Application Development)
2. Этапы работ	Основные: 1. Планирование, 2. Пользовательское проектирование, 3. Конструирование, 4. Внедрение
3. Модели ЖЦ, поддерживаемые методологией	Спиральная модель ЖЦ
4. Ролевой состав	Небольшая команда разработчиков, имеющих опыт в анализе, проектировании, генерации кода и тестировании ПО с использованием CASE-средств, способных хорошо взаимодействовать с конечными пользователями и трансформировать их предложения в рабочие прототипы.
5. Поддержка документирования	Да, на этапе внедрения
6. Формализованное описание методологии	Да
7. Инструментальная поддержка методологии	§ Embarcadero RAD Studio § Axure RP § C++ Builder § Delphi § DevelStudio § Expression Studio § GUI Machine § IBM Lotus Domino Designer § IntelliJ IDEA § IntraWeb § Microsoft Visual Studio § NetBeans IDE § PowerBuilder § Visual DataFlex § Visual Basic и др.
8. Класс проекта	Малый, средний
9. Достоинства	§ Обеспечивает быстроту продвижения программного продукта на рынок. § Позволяет создать интерфейс наиболее подходящий пользователю, за счет постоянного контактирования с заказчиком. § Способствует легкой адаптируемости проекта к изменяющимся требованиям. § Обеспечивает простоту развития функциональности системы.
10. Недостатки	§ Подходит для разработки небольших систем для конкретного заказчика. § Изолированное проектирование модулей. § Согласованный вариант прототипа не всегда означает готовность модуля. § Основное внимание сконцентрировано на экранных формах. § Отсутствие целостной системы, как правило получается набор автоматизированных рабочих мест.
11. Поддержка этапа бизнес-моделирования	Нет

Данная методология обеспечивает быстроту продвижения программного продукта на рынок и позволяет создать интерфейс наиболее подходящий пользователю, за счет постоянного контактирования с заказчиком. Кроме того RAD - методология способствует легкой адаптируемости проекта к изменяющимся требованиям и обеспечивает простоту развития функциональности системы.

В тоже время эта методология имеет и свои недостатки. Например, она подходит только для разработки небольших систем для конкретного заказчика. Так же она поддерживает лишь изолированное проектирование модулей. Согласованный вариант прототипа не всегда означает готовность модуля, а соответственно основное внимание сконцентрировано на экранных формах. Кроме всего прочего при использовании RAD - методологии отсутствует целостная система и в результате как правило получается набор автоматизированных рабочих мест. [9]

Несмотря на это RAD - методология активно используется разработчиками для небольших и уникальных проектов.

1.2.5. RUP - методология

Продукт Rational Unified Process (RUP) разработан и поддерживается Rational Software. Он регулярно обновляется с целью учета передового опыта и улучшается за счет проверенных на практике результатов. Кроме того поддерживает процесс создания моделей при помощи унифицированного языка моделирования (UML).

В основе RUP лежат следующие принципы:

1. Ранняя идентификация и непрерывное (до окончания проекта) устранение основных рисков.

2. Концентрация на выполнении требований заказчиков к исполняемой программе (анализ и построение модели прецедентов (вариантов использования)).

3. Ожидание изменений в требованиях, проектных решениях и реализации в процессе разработки.

4. Компонентная архитектура, реализуемая и тестируемая на ранних стадиях проекта.

5. Постоянное обеспечение качества на всех этапах разработки проекта (продукта).

6. Работа над проектом в сплочённой команде, ключевая роль в которой принадлежит архитекторам. [6, 7]

Паспорт RUP - методологии представлен в Таблице 6.

Таблица 6. Паспорт RUP - методологии.

1. Название методологии	RUP (Rational Unified Process)
2. Этапы работ	Основные: 1. Бизнес-анализ, 2. Управление требованиями, 3. Анализ и проектирование, 4. Реализация, 5. Тестирование, 6. Развертывание. Вспомогательные: § Управление проектом, § Управление конфигурацией, § Управление средой.
3. Модели ЖЦ, поддерживаемые методологией	Любая
4. Ролевой состав	Для каждого процесса разработки определяет ролевой состав команды
5. Поддержка документирования	Да
6. Формализованное описание методологии	Присутствует, может меняться в зависимости от потребностей проекта
7. Инструментальная поддержка методологии	Набор инструментов IBM Rational
8. Класс проекта	Большие, средние, малые
9. Достоинства	§ Широкий диапазон решений в части формализации процесса разработки. § Можно использовать как основу для водопадного стиля разработки, так и в качестве гибкого процесса. § Снижение основных рисков заказчика и разработчика. § Экономия ресурсов за счет автоматизации тестирования. § Улучшение качества тестирования за счет использования современных технологий.
10. Недостатки	§ Документирование на английском языке
11. Поддержка этапа бизнес-моделирования	Да

Одной из основных отличительных положительных черт RUP - методологии является широкий диапазон решений в части формализации процесса разработки, а так же снижение основных рисков заказчика и разработчика. RUP - методология является довольно универсальной, ее можно использовать как основу для водопадного стиля разработки, так и в качестве гибкого процесса. Кроме того эта методология позволяет достичь значительной экономии ресурсов за счет автоматизации тестирования и улучшить качество тестирования за счет использования современных технологий.

Несмотря на все преимущества RUP - методология ориентирована на поддержку всего жизненного цикла программного продукта без учета модульности, что затрудняет исправление ошибок в некоторых модулях системы. Так же RUP отличается длительными стадиями анализа и проектирования, и предоставляет возможность для документирования только части из перечисленных процедур, т.к. ориентируются в большей степени на разработку программных систем. [7, 8, 11]

Впрочем все эти свойства RUP - методологии не мешают ее распространению среди групп начинающих разработчиков и активному ее использованию крупными компаниями.



1.2.6. SADT - методология

Следующая методология рассмотренная и проанализированная в магистерской работе - SADT - методология. SADT - это методология структурного анализа и проектирования, интегрирующая процесс моделирования, управление конфигурацией проекта, использование дополнительных языковых средств и руководство проектом со своим графическим языком. Она возникла в конце 60-х годов в ходе революции, вызванной структурным программированием. [9]

Паспорт SADT - методологии представлен в Таблице 7.

Таблица 7. SADT - методология

1. Название методологии	SADT (Structured Analysis and Design Technique)
2. Этапы работ	1. Анализ 2. Проектирование 3. Реализация 4. Тестирование 5. Установка 6. Эксплуатация
3. Модели ЖЦ, поддерживаемые методологией	Итерационная модель
4. Ролевой состав	Вход, выход, управление, механизм, функция
5. Поддержка документирования	Нет
6. Формализованное описание методологии	Да
7. Инструментальная поддержка методологии	Design/IDEF, CA ERwin, BPwin
8. Класс проекта	Средний, малый
9. Достоинства	§ Полнота описания бизнес-процесса (управление, информационные и материальные потоки, обратные связи). § Комплексная декомпозиция. § Возможность агрегирования и детализации потоков данных и управления (разделение и слияние стрелок). § Жесткие требования метода, обеспечивающие получение моделей стандартного вида. § Соответствие подхода к описанию процессов стандартам ISO 9000.
10. Недостатки	§ Слишком абстрактная модель, которая при проектировании ПО становится перегруженной излишними данными вроде потока механизма. § Условие максимального количества блоков на одном уровне (6-7) вынуждает проектировщика к чрезмерному дроблению системы
11. Поддержка этапа бизнес-моделирования	Да

Данная методология обладает полнотой описания бизнес-процесса (управление, информационные и материальные потоки, обратные связи) и комплексной декомпозицией. Так же эта методология предоставляет возможность агрегирования и детализации потоков данных и управления (разделение и слияние стрелок). А жесткие требования метода, обеспечивающие получение моделей стандартного вида, так же соответствующие подходу к описанию процессов по стандартам ISO 9000.

Однако, SADT - методология является слишком абстрактной моделью, которая при проектировании ПО становится перегруженной излишними данными вроде потока механизма. Условие максимального количества блоков на одном уровне (6-7) вынуждает проектировщика к чрезмерному дроблению системы. Так же SADT имеет слабую интеграцию с приложениями проектирования ИС. [9, 10]

Но несмотря на все свои особенности SADT - методология довольно популярна у разработчиков занимающихся проектами, относящимися к классу малых и средних.

1.2.7. TDD - методология

Последняя методология рассмотренная в рамках анализа, TDD - методология. Данная методология описывает технику разработки продукта, которая основывается на повторении очень коротких циклов разработки: сначала пишется тест, покрывающий желаемое изменение, затем пишется код, который позволит пройти тест, и под конец проводится рефакторинг нового кода к соответствующим стандартам. Кент Бек, считающийся изобретателем этой техники, утверждал в 2003 году, что разработка через тестирование поощряет простой дизайн и внушает уверенность. [9]

Паспорт TDD - методологии представлен в Таблице 8.

Таблица 8. Паспорт TDD - методологии.

1. Название методологии	TDD (test-driven development), Разработка через тестирование.
2. Этапы работ	Основные: 1. Добавление теста, 2. Запуск всех тестов (убедиться, что новые тесты не проходят), 3. Написание кода, 4. Запуск всех тестов (убедиться, что все тесты проходят), 5. Рефакторинг , 6. Повторить цикл.
3. Модели ЖЦ, поддерживаемые методологией	Определенной нет, используется та, которая удобнее
4. Ролевой состав	Не определен
5. Поддержка документирования	Документация только в виде тестов
6. Формализованное описание методологии	Да
7. Инструментальная поддержка методологии	§ PHPUnit § SimpleTest § qUnit § CodeCoverage § Selenium § VisualStudio и др.
8. Класс проекта	Малые, средние
9. Достоинства	§ Фокусировка на тестах позволяет представить необходимый заказчику интерфейс на ранних стадиях разработки. § Формирование четких и небольших интерфейсов. § Общее время, затраченное на разработку, меньше. § Большое количество тестов позволяет уменьшить количество ошибок в коде. § Тесты позволяют производить рефакторинг кода без риска его испортить. § Разработка через тестирование способствует более модульному, гибкому и расширяемому коду. § Автоматизированные тесты покрывают все пути исполнения. § Тесты могут использоваться в качестве документации.
10. Недостатки	§ Не универсальный метод разработки, некоторые задачи невозможно решить при помощи тестирования. § Разработку через тестирование сложно применять в тех случаях, когда для тестирования необходимо прохождение функциональных тестов, например, разработка интерфейсов пользователя. § Требуется больше времени на разработку и поддержку. § Тесты обычно пишутся теми же, кто пишет тестируемый код (при неправильном понимании задачи, ошибка буде и в коде и в тесте). § Тесты являются источником накладных расходов.
11. Поддержка этапа бизнес-моделирования	Нет

Основными достоинствами TDD - методологии являются фокусировка на тестах, которая позволяет представить необходимый заказчику интерфейс на ранних стадиях разработки, и формирование четких и небольших интерфейсов. При использовании данной методологии общее время, затраченное на разработку, значительно меньше, а большое количество тестов позволяет уменьшить количество ошибок в коде. Кроме того тесты позволяют производить рефакторинг кода без риска его испортить и могут использоваться в качестве документации.

Однако TDD не является универсальным методом разработки, т.к. некоторые задачи невозможно решить при помощи тестирования. Разработку через тестирование сложно применять в тех случаях, когда для тестирования необходимо прохождение функциональных тестов, например, разработка интерфейсов пользователя. К тому же на разработку с помощью TDD - методологии требуется больше времени на разработку и поддержку. [9]

Но за счет широкой инструментальной поддержки данная методология обрела немалую популярность у групп начинающих разработчиков, занимающихся средними и малыми проектами.

1.1. 2. Анализ методологий

Таблица 9. Сводная таблица методологий

	Этапы разработки АС	Модели ЖЦ	Роли	Документирование	Формализованное описание	Инстр - я поддержка	Класс проекта	Достоинства	Недостатки	Поддержка этапа бизнес-моделирования
ГОСТы 34 серии	§ Формирование требований к АС § Разработка концепции АС § Техническое задание § Эскизный проект § Технический проект § Рабочая документация § Ввод в действие § Сопровождение АС	Любая	Не поддерживает	Да	Отсутствует	Возможно использование CASE-средств	Любые АС	Самодостаточность для создания любой АС	§ Отсутствие формализованного описания § Отсутствие поддержки вспомогательных и управленческих процессов § Большое число оформляемых документов § Не поддерживает управленческие и часть вспомогательных процессов создания АС	Да
ARIS	§ Постановка задачи, § Определение требований, § Написание проектной спецификации § Описание реализации, § Физическая реализация.	Трехфазовая модель ЖЦ	Поддерживает. Зависит от модели	Да	Да	Семейство продуктов ARIS и ее модулей	Средние, большие	§ Обладает большим набором функций. § Предусмотрена возможность анализа построенных моделей. § Возможность рассматривать объект с разных точек зрения. § Применяя дополнительные модули и внутренний язык программирования, пользователь может сформировать любые регламенты и положения.	§ Достаточно высокая стоимость программного обеспечения. § Система содержит большое количество функций, которые, возможно, никогда не будут востребованы.	Да
CDM	§ Определение требований, § Анализ, § Проектирование, § Реализация, § Внедрение, § Эксплуатация	Каскадная модель ЖЦ	Да	Да	Отсутствует	Набор инструментов Oracle	Большие	§ Уменьшение себестоимости разработки. § Уменьшение количества ошибок, снижение цены ошибки. § Прогнозирование сроков, предсказуемость затрат и результатов. § Снижение рисков работодателя, независимость от персоналий.	§ Жесткая ориентация на линейку продуктов Oracle. § Сложна в использовании. § Необходимость обучения методологии	Да
RAD	§ Планирование § Пользовательское проектирование § Конструирование § Внедрение	Спиральная, эволюционная	Поддерживает	Да, на этапе внедрения	Формализация с использованием диаграммы процессов	Embarcadero RAD Studio, Axure RP, C++ Builder, Delphi, DeveStudio, GUI Machine, Microsoft Visual Studio и др.	Малый, средний	§ Быстрота продвижения ПП на рынок § Способность к адаптации § Постоянное взаимодействие с заказчиком § Простота развития функциональности системы	§ Подходит для разработки небольших систем для конкретного заказчика § Изолированное проектирование модулей § Отсутствие целостной системы § Согласованный вариант прототипа не всегда означает готовность модуля.	Нет
RUP	§ Бизнес-анализ, § Управление требованиями, § Анализ и проектирование, § Реализация, § Тестирование, § Развертывание.	Любая	Для каждого процесса разработки определяет ролевой состав команды	Да	Присутствует, может меняться в зависимости от потребностей проекта	Набор инструментов IBM Rational	Любые АС	§ Широкие возможности по формализации процесса разработки § Конфигурируется под любые типы проекта § Улучшение качества тестирования § Экономия ресурсов за счет автоматизации тестирования	§ Ролевая команда очень большая § Большое число создаваемых артефактов § Документирование на английском языке	Да
SADT	§ Анализ § Проектирование § Реализация § Тестирование § Установка § Эксплуатация	Любая	Поддерживает	Да	Да	Design/IDEF, CA ERwin, BPwin	Средний, малый	§ Полнота описания бизнес-процесса § Комплексная декомпозиция. § Жесткие требования метода, обеспечивающие получение моделей стандартного вида § Соответствие подхода к описанию процессов стандартам ISO 9000.	§ Слишком абстрактная модель, которая при проектировании ПО становится перегруженной излишними данными вроде потока механизма. § Условие максимального количества блоков на одном уровне (6-7) вынуждает проектировщика к чрезмерному дроблению системы	Да
TDD	§ Добавление теста § Запуск всех тестов § Написание кода § Запуск всех тестов § Рефакторинг § Повторить цикл	Любая	Не поддерживает	Только в виде тестов	Нет	PHPUnit, SimpleTest, qUnit, CodeCoverage, Selenium, VisualStudio и др.	Малые, средние	§ Формирование четких и небольших интерфейсов § Сокращение времени на разработку § Уменьшение количества ошибок в коде § Автоматизированные тесты покрывают все пути исполнения	§ Метод разработки не универсален § Необходимо больше времени на разработку и поддержку § Увеличение накладных расходов § Тесты -источник накладных расходов.	Нет

На основе сводной Таблицы 9 был проведен анализ и сравнение всех рассмотренных методологий создания автоматизированных систем.

Если сравнивать методологии по этапам разработки автоматизированных систем наиболее привлекательной является методология основанная на ГОСТах 34й серии, т.к. в ней наиболее четко и полно прописаны все этапы моделирования, что позволит избежать недопонимая в команд разработчиков. Так же стоит отметить наличие этапа бизнес-анализа у методологии RUP.

Рассматривая методологии с точки зрения поддерживаемых моделей жизненного цикла, снова можно отметить методологии ГОСТов 34й серии и RUP, которые поддерживают любые модели жизненных циклов, что является значительным преимуществом. Однако, есть и другие методологии, поддерживающие любые модели жизненного цикла.

С точки зрения поддержки ролевого состава команды методология ГОСТов 34й серии на фоне других методологий проигрывает. А вот методология RUP является очень привлекательной, т.к. позволяет для каждого процесса разработки подобрать свой необходимый ролевой состав команды, в зависимости от задачи, стоящей перед разработчиками.

Документирование поддерживают все рассмотренные методологии, а вот формализованное описание является исключением. И по этому параметру вновь выигрывает методология RUP, т.к. при использовании данной методологии формализованное описание может изменяться в зависимости от потребностей проекта.

Рассматривая следующий параметр - инструментальную поддержку - видно, что при использовании каждой из методологий используются различные средства разработки, однако RUP является оптимальной методологией в контексте данной магистерской работы, т.к. поддерживает разработку с использованием UML (унифицированного языка моделирования), что и требуется для выполнения поставленной задачи.

Рассматривая методологии с точки зрения классов проектов, которые можно разрабатывать используя методологию, вновь наиболее оптимальным являются методология RUP и методология, основанная на ГОСТах 34й серии, т.к. они поддерживают создание и разработку любых классов проектов, будь то большие, средние или малые.

Если говорить о достоинствах методологий, то среди всех прочих выделяются самодостаточность для создания любой АС, широкие возможности по формализации проекта и экономия ресурсов, которыми отличаются методологии RUP и ГОСТов 34й серии.

Наиболее незначительными недостатками обладает методология RUP, отличающаяся от прочих тем, что ее минусы никак не мешают процессу разработки и достаточно легко исправимы.

Все рассмотренные методологии так или иначе поддерживают этап бизнес - моделирования, за исключением двух: методологии RAD и TDD.

Проведенный анализ методологий показал, что при работе над поставленной задачей оптимально будет использовать две методологии: RUP и методологию основанную на ГОСТах 34й серии, т.к. каждая из них имеет преимущества перекрывающие недостатки второй методологии. Именно эти две методологии и будут использованы в рамках научно-исследовательской работы магистра.

2.1 Постановка задачи исследований

Тема научно-исследовательской работы магистра - «Разработка формализованного описания бизнес-процесса с использованием UML». Целью работы является повышение эффективности бизнес-процесса (название бизнес-процесса уточняется).

Для достижения поставленной цели необходимо решить следующие задачи:

1. Изучение и анализ существующий методологий разработки АС

2. Разработка формализованного описания бизнес-процесса (название процесса уточняется)

3. Разработка регламента бизнес-процесса (название процесса уточняется)

4. Определение требований пользователей к автоматизированной системе, поддерживающей бизнес-процесс (название процесса уточняется)

5. Разработка модели автоматизированной системы, поддерживающе бизнес-процесс (название процесса уточняется)

6. Разработка ТЗ на создание автоматизированной системы, поддерживающей бизнес- процесс (название бизнес-процесса уточняется)

Объектом исследования научно-исследовательской работы является Деятельность в сфере связанной с бизнес-процессом (название бизнес-процесса уточняется).

Предмет исследования - средства и методы повышения эффективности в сфере связанной с бизнес-процессом (название бизнес-процесса уточняется).

Научная новизна магистерской диссертации заключается в формализованном описании бизнес-процесса (название уточняется) с использованием UML (унифицированного языка моделирования). С помощью инструментального средства Enterprise Architect будет построена модель основных последовательных этапов разработки автоматизированной системы бизнес-процесса (название уточняется). Затем каждый этап будет декомпозирован для отображения более детального описания.

Практическая значимость состоит в разработке регламента бизнес-процесса (название уточняется), то есть создания документа, описывающего последовательность операций, ответственность, порядок взаимодействия исполнителей и порядок принятия решений по улучшениям.



Заключение

В результате промежуточного итога научно-исследовательской работы были проанализированы 7 методологий разработки автоматизированных систем на основе составленных паспортов. Каждая из них имеет свои достоинства и недостатки, но методики ГОСТов 34й серии и RUP наиболее подходят для разработки формализованного описания бизнес-процесса с использованием UML (унифицированного языка моделирования), что было определено в ходе сравнительного анализа всех методологий разработки автоматизированных систем.

Так же были определены предмет, объект исследования, актуальность темы научной работы, ее научная новизна и практическая значимость. Кроме того были сформулированы цели научно-исследовательской работы и задачи, которые необходимо решить для достижения целей.



Список литературы

1. Август-Вильгельм Шеер. ARIS - моделирование бизнес-процессов. -- Вильямс, 2000. -- 175 с. -- ISBN 978-5-8459-1449-1.

2. В. В. Репин, В. Г. Елиферов. . -- Стандарты и качество, 2003. -- (Практический менеджмент). -- ISBN 5-94938-040-1.

3. Скворцов В.И., к.т.н., каф.22 НИЯУ МИФИ, доцент. Лекции.

4. Информационный портал http://www.rugost.com/

5. Золотухина Е.Б., к.т.н., каф.71 НИЯУ МИФИ, доцент. Лекции.

6. Gary Pollice, Liz Augustine, Chris Lowe, and Jas Madhur (2003). Software Development for Small Teams: A RUP-Centric Approach.

7. Ahmad Shuja, Jochen Krebs (2007). RUP Reference and Certification Guide.

8. Per Kroll, Philippe Kruchten (2003). Rational Unified Process Made Easy, The: A Practitioner's Guide to the RUP

9. Информационный портал http://www.intuit.ru/

10. Ларман К. Применение UML и шаблонов проектирования / Пер. с англ. М.: Вильямс, 2002.

11. Крачтен Филипп. Введение в Rational Unified Process. -- 2-e изд.: Пер. с англ. -- M.: Издательский дом “Вильямс”, 2002. -- 240 с.



Приложение

Список определений и сокращений

Автоматизированная система - совокупность согласованных компонентов программного, технического, информационного, организационного, методического, правового обеспечения, используемая пользователями для реализации заданной информационной технологии.

Жизненный цикл программного обеспечения - период времени, который начинается с момента принятия решения о необходимости создания ПО и заканчивается в момент его полного изъятия из эксплуатации.

Методология - система принципов, а также совокупность идей, понятий, методов, способов и средств, определяющих стиль разработки программного обеспечения.

Унифицированный язык моделирования (Unified Modeling Language - UML) - язык визуального моделирования, предназначенный для разработки моделей предметной области и программных систем различных классов.

Размещено на Allbest.ur

...