Жизненный цикл программных систем

5.7. Виды моделей ЖЦ ПО

Каскадная модель (классический жизненный цикл)

Эта модель обязана своим появлением У. Ройсу ([1], 1970 г.). Модель имеет и другое название – водопад (waterfall). Особенность модели – переход на следующую ступень осуществляется только после того, как будет полностью завершена работа на предыдущей стадии; возвратов на пройденные стадии не предусматривается (рис.5.4).

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

Требования к разрабатываемой ПС, определенные на стадиях формирования и анализа, строго документируются в виде ТЗ и фиксируются на все время разработки проекта. Каждая стадия завершается выпуском полного комплекта документации (ТЗ, ЭП, ТП, РП), достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков. Критерием качества разработки при таком подходе является точность выполнения спецификаций ТЗ. Основное внимание разработчиков сосредоточивается на достижении оптимальных значений технических характеристик разрабатываемой ПС – производительности, объема занимаемой памяти и др.

Преимущества каскадной модели:

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

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

Недостатки каскадной модели:

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

Итерационная модель ЖЦ ПС

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

Рис. 5.5. Итерационная модель жизненного цикла программного обеспечения

В итерационной модели (рис.5.5) недостатки проектирования и программирования могут быть устранены позже путем частичного возврата на предыдущую стадию. Чем ниже уровень обнаружения ошибки, тем дороже ее исправление. Если стоимость усилий, необходимых для обнаружения и устранения ошибок на стадии написания кода, принять за единицу, то стоимость выявления и устранения ошибки на стадии выработки требований будет в 5-10 раз меньше, а стоимость выявления и устранения ошибки на стадии сопровождения – в 20 раз больше (рис.5.6).

Рис. 5.6. Зависимость стоимости и устранения ошибки от стадии разработки программного обеспечения

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

Макетирование

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

Модель может принимать следующие формы.

1. Бумажный макет (рисованная схема человеко-машинного диалога) или макет на основе ПК.
2. Работающий макет, реализующий некоторую часть требуемых функций.
3. Существующая программа, характеристики которой должны быть улучшены.

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

Рис. 5.7. Итерации макетирования программного обеспечения

Последовательность действий при макетировании представлена на рис.5.8. Макетирование начинается со сбора и уточнения требований к создаваемой программной системе. Разработчик и заказчик совместно определяют цели ПО, устанавливают, какие требования известны, а какие предстоит доопределить. Затем выполняется быстрое проектирование. В нем сосредотачиваются на характеристиках, которые должны быть видимыми пользователю. Быстрое проектирование приводит к построению макета. Макет оценивается заказчиком и используется для уточнения требований к ПО. Итерации продолжаются до тех пор, пока макет не выявит все требования заказчика и даст возможность разработчику понять, что должно быть сделано.

Достоинства макетирования – возможность обеспечения определения полных требований к системе. Недостатки макетирования:

• заказчик может принять макет за продукт;
• разработчик может принять макет за продукт.

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

Рис. 5.8. Последовательность действий при макетировании программного обеспечения

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

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

Стратегии конструирования ПО

Существует три стратегии конструирования программных систем:

• однократный проход (каскадная стратегия, рассмотренная выше) – линейная последовательность этапов конструирования;
• инкрементная стратегия. В начале процесса определяются все пользовательские и системные требования, оставшаяся часть конструирования выполняется в виде последовательности версий. Первая версия реализует часть запланированных возможностей, следующая версия реализует дополнительные возможности и т. д., пока не будет получена полная система;
• эволюционная стратегия. Система также строится в виде последовательности версий, но в начале процесса определяются не все требования. Требования уточняются в результате разработки версий. Характеристики стратегий конструирования ПО с соответствии с требованиями стандарта IEEE/EIA 12207 приведены в табл. 5.1.