Файл: Применение процессного подхода для оптимизации бизнес-процессов (Бизнес-процессы).pdf

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

Принцип модели основан на однократном осуществлении процессов в форме заблаговременно ограниченных и однозначно упорядоченных во времени стадий, осуществляемых в их естественных границах.[13]

Схема, иллюстрирующая каскадную модель, представлена на рисунке 12.

Рисунок 12 – Классическая каскадная модель

Позже каскадная модель неоднократно регламентировалась множеством разнообразных нормативных актов, в например, известным стандартом Министерства обороны и российскими стандартами серии ГОСТ 34.

Обязательными качествами классической каскадной модели являются:

• определение требований к разрабатываемой системе на начальной стадии работы над продуктом;
• фиксированная последовательность выполнения этапов;
• переход к очередной стадии проекта возможен только полного завершения работы на текущей стадии (возврат на пройденные стадии запрещен);
• временного перекрытие этапов отсутствует;
• возврат к предыдущим этапам отсутствует;
• результата получают только в конце разработки.

Отмечают следующие преимущества использования каскадной модели:

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

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

Отмечают и другие недостатками каскадного подхода:

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

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

Позже появилась усовершенствованная модифицированная каскадная модель (рисунок 13).

Рисунок 13 – Модифицированная каскадная модель

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

1.4 Поэтапная модель с промежуточным контролем

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

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

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

За счет этого трудоемкость отладки программ существенно снижается в сравнении с каскадной моделью.

Поэтапная модель с промежуточным контролем вошла в практику с 1987 года.

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

Поэтапная модель с промежуточным контролем представлена на рисунке 14.

Рисунок 14 - Поэтапная модель с промежуточным контролем

1.5 Спиральная модель жизненного цикла программного средства

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

В середине восьмидесятых годов двадцатого века инженером Барри Боэмом был предложен собственный вариант итерационной модели. Эту модель назвали спиральной моделью жизненного цикла программного средства.[22]

Спиральная модель в упрощенном виде представлена на рисунке 15.

Рисунок 15 – Спиральная модель в упрошенной форме

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

Классическая спиральная модель жизненного цикла программных средств представлена на рисунке 16.

Рисунок 16 – Классическая спиральная модель жизненного цикла программных средств

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

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

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

Существенные свойства спиральной модели:

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

К достоинствам спиральной модели относят:

• ускоренные темпы разработки (заметно более раннее получение итоговых результатов за счет применения прототипирования);
• регулярное внимание и участие заказчика в процессе разработки;
• дифференцирование большого объема работы на мелкие части;
• понижение риска (увеличение вероятности предсказуемого поведения системы).

Основной проблемой спирального цикла считают определение момента перехода к следующему этапу проекта.

1.6 Инкрементная модель жизненного цикла программного средства

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

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

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

Инкрементная модель представлена на рисунке 17.

Рисунок 17 – Инкрементная модель жизненного цикла

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

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

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

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

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

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

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

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

2 ОПТИМИЗАЦИЯ БИЗНЕС-ПРОЦЕССОВ

2.1 Общая характеристика бизнес-процесса

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

Дадим общую характеристику бизнес-процесса разработки программного продукта на заказ.

Характеристика представлена в таблице 1.

Таблица 1 – Характеристика бизнес-процесса