2.2 Стратегии и модели жизненного цикла

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

· характеристиками проекта;

· требованиями к продукту;

· командой разработчиков;

· командой пользователей.

Существуют 3 стратегии разработки (конструирования) ПО:

• однократный проход (каскадная, «водопадная» стратегия) — линейная последовательность этапов конструирования;

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

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

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

Стратегии могут быть реализованы различными моделями ЖЦ.

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

Р и с. 2. Каскадная схема разработки ПО

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

Детально состав процессов жизненного цикла регламентируется международным стандартом ISO/IEC 12207: 1995 «Information Technologe – Software Life Cycle Processes» («Информационные технологии – Процессы жизненного цикла программного обеспечения»). ISO – International Organization for Standardization – Международная организация по стандартизации. IЕС – International Electrotechnical Commission – Международная комиссия по электротехнике.

Рассмотрим какие действия предусматривает стандарт для процесса проектирования (разработки) ПО:

• подготовительную работу – выбор модели жизненного цикла, стандартов, методов и средств разработки, а также составление плана работ;

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

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

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

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

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

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

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

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

• интеграцию системы – сборку всех компонентов системы, включая программное обеспечение и оборудование;

• квалификационное тестирование системы – тестирование системы на соответствие требованиям к ней и проверка оформления и полноты документации;

• установку программного обеспечения – установку программного обеспечения на оборудовании заказчика и проверку его работоспособности;

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

Классическая каскадная модель ЖЦ, ориентированная на этап разработки, при этом будет представляться следующим образом (рис.).

Как и любая схема действий классический жизненный цикл имеет достоинства и недостатки.

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

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

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

Недостатки классического ЖЦ:

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

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

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

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

Р и с. 3. Реальный процесс разработки ПО по каскадной схеме

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

Разновидностью классической каскадной модели является V-образная модель.

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

Однако в V-образной модели выделены связи между шагами, предшествующими программированию, и соответствующими видами тестирования и испытаний.

Рисунок 2.6 иллюстрирует вариант V-образной модели, адаптированный к работам процесса разработки, определенного в СТБ ИСО/МЭК 12207-2003.

Рис. V-образная модель жизненного цикла

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

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

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

На этапе программирования и тестирования программных средств выполняется кодирование и тестирование программных модулей.

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

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

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

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

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

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

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

Эволюционная (спиральная) модель – классический пример применения эволюционной стратегии конструирования.

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

Как показано на рисунке, модель определяет четыре действия, представляемые четырьмя квадрантами спирали:

1. планирование – определение целей, вариантов и ограничений.

2. анализ риска – анализ вариантов и распознавание/выбор риска

3. конструирование – разработка продукта следующего уровня

4. оценивание – оценка заказчиком текущих результатов конструирования.

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

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

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

В большинстве случаев движение по спирали продолжается, с каждым шагом продвигая разработчиков к более лучшему продукту. В каждом цикле по спирали требуется конструирование, которое может быть реализовано классическим ЖЦ или макетированием. Заметим, что количество действий по разработке возрастает по мере продвижения от центра спирали.

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

1. наиболее реально (в виде эволюции) отображает разработку ПО

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

Недостатки спиральной модели: трудности контроля и управления временем разработки.