Модели жизненного цикла разработки программного продукта

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

Стандарт ISO/IEC 12207 не предлагает конкретные модель жиз­ненного цикла и методы разработки ПП. Положения стандарта являются общими для любых моделей жизненного цикла, мето­дов и технологий разработки ПП.

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

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

Наибольшее распространение получили следующие модели жизненного цикла разработки ПП:

· каскадная модель, или «водопад» (Waterfall model);

· V-образная модель (V-shaped model);

· модель прототипирования (Prototype model);

· модель быстрой разработки приложений, или RAD-модель (RAD — Rapid Application Development model);

· многопроходная модель (Incremental model); спиральная модель (Spiral model).

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

Таблица 1- Модели жизненного цикла разработки программного продукта

 

Название	Характеристики
Каскадная модель	Прямолинейная и простая в использовании. Необходим постоянный жесткий контроль за ходом работы. Разрабатываемое программное обеспечение не доступно для изменений
V-образная модель	Простая в использовании. Особое значение придается тестированию и сравнению результатов фаз тестирования и проектирования
Модель прототипирования	Создается «быстрая» частичная реализация сис­темы до составления окончательных требований. Обеспечивается обратная связь между пользо­вателями и разработчиками в процессе выпол­нения проекта. Используемые требования не полные
Модель быстрой разработки приложений	Проектные группы небольшие (3...7 человек) и составлены из высококвалифицированных специалистов. Уменьшенное время цикла разработки (до 3 мес) и улучшенная производительность. Повторное использование кода и автоматизация процесса разработки
Многопроходная модель	Быстро создается работающая система. Уменьшается возможность внесения изменений в процессе разработки. Невозможен переход от текущей реализации к новой версии в течение построения текущей частичной реализации
Спиральная модель	Охватывает каскадную модель. Расчленяет фазы на меньшие части. Позволяет гибко выполнять проектирование. Анализирует риски и управляет ими. Пользователи знакомятся с ПП на более раннем этапе благодаря прототипам

 

2) Каскадная модель

В однородных информационных системах 1970-х и 1980-х годов прикладные ПП представляли собой единое целое. Для разработ­ки такого типа ПП применялась каскадная модель, или «водопад» (waterfall) показанная на рисунке 8).

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

Преимущества каскадного способа:

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

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

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

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

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

Это объясняется следующими причинами:

пользователи не в состоянии сразу изложить все свои требо­вания и не могут предвидеть, как они изменятся в ходе разра­ботки;

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

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

 

 

Рисунок.

 

3.1. Каскадная модель

 

 Рисунок 3.2.Схема реального процесса разработки пп

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

3) V-образная модель

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

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

Данная модель основана на систематическом подходе к про­блеме, для решения которой определены четыре базовых шага: анализ, проектирование, разработка и обзор. При выполнении анализа осуществляются планирование проекта и составление тре­бований. Проектирование разделяется на высокоуровневое и де­тальное (низкоуровневое). Разработка включает в себя кодирова­ние, а обзор — различные виды тестирования.

На модели хорошо просматриваются взаимосвязи между ана­литическими фазами И фазами проектирования, которые предшествуют кодированию и тестированию.

 

Рисунок 10- V – образная модель

 

Штриховые стрелки поазывают, что эти фазы надо рассматривать параллель-но.

Модель включает в себя следующие фазы:

составление требований к проекту и планирование — определя­ются систем-ные требования и выполняется планирование работ;

составление требований к продукту и их анализ — составляется полная спе-циификация требований к программному продукту;

высокоуровневое проектирование — определяются структура ПП, взаимосвязи между основными его компонентами и реализуемые ими функции;

детальное проектирование — определяется алгоритм работы каж­дого компонента;

кодирование — выполняется преобразование алгоритмов в го­товое программ-мное обеспечение;

модульное тестирование — выполняется проверка каждого ком­понента или модуля ПП;

интеграционное тестирование — осуществляются интеграция ПП и его тести-рование;

системное тестирование — выполняется проверка функциони­рования ПП после помещения его в аппаратную среду в соответ­ствии со спецификацией требований;

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

ПреимуществаУ-образной модели:

· большая роль придается верификации и аттестации ПП, начи­ная с ранних стадий его разработки, все действия планируются;

· предполагаются аттестация и верификация не только самого ПП, но и всех полученных внутренних и внешних данных;

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

Кроме перечисленных достоинств модель обладает и рядом недостатков:

o не учитываются итерации между фазами;

o нельзя вносить изменения на разных этапах жизненного цикла;

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

Данную модель целесообразно использовать при разработке программных продуктов, главным требованием для которых яв­ляется высокая надежность.

 

 

 

 

Рисунок 11- Модель прототипирования

 

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

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

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

Модель прототипирования обладает целым рядом преимуществ:

· взаимодействие заказчика с разрабатываемой системой начи­нается на раннем этапе;

· благодаря реакции заказчика на прототип сводится к миниму­му число неточностей в требованиях;

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

· в процессе разработки всегда можно учесть новые, даже не­ожиданные требования заказчика;

· прототип представляет собой формальную спецификацию, воп­лощенную в ПП;

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

o заказчик всегда видит прогресс в процессе разработки ПП;

· возможность возникновения противоречий между разработчи­ками и заказчиками сведена к минимуму;

· уменьшается число доработок, что снижает стоимость разра­ботки:

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

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

Кроме указанных достоинств модели прототипирования при­сущ и целый ряд недостатков:

o решение сложных задач может отодвигаться на будущее;

· заказчик может предпочесть получить прототип, а не закон­ченную полную версию ПП;

o прототипирование может неоправданно затянуться;

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

· Модель прототипирования рекомендуется применять в следу­ющих случаях:

o требования к ПП заранее неизвестны,

o требования не постоянны или неудачно сформулированы;

o требования необходимо уточнить;

o нужна проверка концепции;

o существует потребность в пользовательском интерфейсе;

o выполняется новая, не имеющая аналогов разработка;

· разработчики не уверены в том, какое решение следует выб­рать.

 

4) Модель быстрой разработки приложений (RAD-модель)

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

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

На рисунке 12, поясняющем принцип RAD-модели, указаны эта­пы процесса разработки и отображено участие заказчиков (штри­ховая линия) на каждом из них.

Модель включает в себя следующий фазы:

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

описание пользователя — проектирование ПП, выполняемое при непосредственном участии заказчика;

создание — детальное проектирование, кодирование и тести­рование ПП, а также поставка его заказчику;

сопровождение — приемочные испытания, установка ПП и обу­чение пользователей.

Модель обладает следующими достоинствами:

· использование современных инструментальных средств позво­ляет сократить время цикла разработки;

· привлечение к работе заказчика сводит к минимуму риск того, что он останется недоволен готовым ПП;

· повторно используются компоненты уже существующих про­грамм.

o В то же время ей присущи и недостатки:

· если заказчики не могут постоянно участвовать в процессе раз­работки, то это может негативно сказаться на ПП;

· для работы нужны высококвалифицированные кадры, умеющие пользоваться современными инструментальными средствами;

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

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

 

 

Рисунок 12- RAD- модель

5) Многопроходная модель

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

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

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

· в начале разработки требуются средства только для разработки и реализации основных функций ПП;

· после каждого инкремента получается функциональный про­дукт;

· снижается риск неудачи и изменения требований;

· улучшается понимание как разработчиками, так и пользовате­лями ПП требований для более поздних итераций;