1.4.5Типичная схема управления процессом создания программного обеспечения

Управление процессами при разработке программного обеспечения в общем случае реализуется по спиральной схеме и состоит из следующих повторяемых действий [SWEBOK]:

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

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

• реализация и изменение процесса (Process Implementation and Change), предусматривающая выполнение разработанного плана по внедрению нового (усовершенствованного) процесса, в результате чего он процесс должен быть внедрен в практику организации;

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

РИСУНОК

1.5Модели жизненного цикла

Согласно ГОСТ Р ИСО/МЭК 12207 выделяют следующие модели жизненного цикла [ГОСТ Р ИСО/МЭК 12207]:

• каскадная (водопадная) или последовательная;

• итеративная и инкрементальная – эволюционная (гибридная, смешанная);

• спиральная (spiral) или модель Боэма.

1.5.1Каскадная (водопадная) модель

Данная модель предполагает строго последовательное (во времени) и однократное выполнение всех фаз проекта с жестким (детальным) предварительным планированием в контексте предопределенных или однажды и целиком определенных требований к программной системе.

Рисунок. Каскадная модель жизненного цикла.

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

Практика показывает, что каскадная модель не эффективна для большинства ИТ-проектов. В программной инженерии – высокая «подвижность» требований, которые часто корректируются и уточняются, в силу невозможности их четкого и однозначного определения требований до начала работ по реализации. В каскадной модели переход от одной фазы проекта к другой предполагает полную корректность результата (выхода) предыдущей фазы. Однако, например, неточность какого-либо требования или некорректная его интерпретация, в результате, приводит к тому, что приходится “откатываться” к ранней фазе проекта и требуемая переработка не просто выбивает проектную команду из графика, но приводит часто к качественному росту затрат и, не исключено, к прекращению проекта в той форме, в которой он изначально задумывался. Кроме того, эта модель не способна гарантировать необходимую скорость отклика и внесение соответствующих изменений в ответ на быстро меняющиеся потребности пользователей, для которых программная система является одним из инструментов исполнения бизнес-функций. И таких примеров проблем, порождаемых самой природой модели, можно привести достаточно много.

Достоинство:

• наличие чёткого плана и временного графика по всем этапам проекта.

Недостатки:

• высокие издержки по причине частых откатов;

• реальные проекты часто требуют отклонения от стандартной последовательности шагов;

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

• результаты проекта доступны заказчику только в конце работы.

Сфера применения:

• программные средства, являющиеся элементами аппаратных систем, требования к которым хорошо определены и изменяются не часто;

• программные средства, применяемые в оборонной, медицинской, космической или авиационной отрасли.