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

Модель ЖЦ зависит от специфики ПО и специфики условий, в которых оно создается и функционирует.

Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПО. Его регламенты являются общими для любых моделей ЖЦ, методологий и технологий разработки. Стандарт ISO/IEC 12207 описывает структуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы.

Модель ЖЦ любого конкретного ПО определяет характер процесса его создания.

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

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

В состав ЖЦ ПО обычно включаются следующие этапы:

1) формирование требований, предъявляемых к ПО;

2) проектирование структуры ПО;

3) реализация;

4) тестирование;

5) ввод в действие;

6) эксплуатация и сопровождение;

7) снятие с эксплуатации.

На каждом этапе могут выполняться несколько процессов, оп­ределенных в стандарте 1SO/IEC 12207, и, наоборот, один и тот же процесс может выполняться на различных этапах.

Существующие модели ЖЦ определяют порядок исполнения этапов в ходе разработки, а также критерии перехода от этапа к этапу.

К настоящему времени наибольшее распространение получили следующие три основные модели ЖЦ.

1) Каскадная модель (1970-1980 гг.) предполагает переход на следующий этап после полного завершения работ предыдущего этапа.

2) Поэтапная модель с промежуточным контролем (1980-1985 гг.) — итерационная модель разработки ПО с циклами обратной связи между этапами.

3) Спиральная модель (1986-1990 гг.) делает упор на начальные этапы ЖЦ (анализ требований, проектирование спецификаций, предварительное и детальное проектирование).

Основные характеристики каскадного способа:

- разбиение всей разработки на этапы;

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

- возможность планировать сроки завершения всех работ и соответствующие затраты;

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

- исходными для каждого этапа являются документы и решения, полученные на предыдущем этапе.

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

Рис. 4.1. Каскадная модель разработки программного обеспечения

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

Основной недостаток каскадного подхода: требования к ПО "заморожены" в виде технического задания на все время его создания. Пользователи могут внести свои замечания только после того, как работа над ПО будет полностью завершена. В случае неточного изложения требований или их изменения в течение длительного периода создания ПО, пользователи получают систему, не удовлетворяющую их потребностям. Модели (как функциональные, так и информационные) автоматизируемого объекта могут устареть одновременно с их утверждением.

Поэтому реально каскадная модель создания ПО имеет вид, показанный на рис. 4.2.

Рис. 4.2. Модель с промежуточным контролем

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

Для преодоления перечисленных проблем была предложена спиральная модель ЖЦ (рис. 4.3), делающая упор на начальные этапы ЖЦ: анализ требований, определение спецификаций и проектирование (предварительное и детальное).

Рис. 4.3. Спиральная модель жизненного цикла

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

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

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

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

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

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

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

Другими недостатками спиральной модели являются:

- трудоемкость внесения изменений;

- большой объем документации по проекту, затрудняющий программирование;

- сложность переноса на другие платформы.

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

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