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

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

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

Первой по времени появления и самой распространенной явилась каскадная модель (Рис.8).

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

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

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

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

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

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

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

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

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

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

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

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

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

Каскадная модель характеризуется следующими основными особенностями:

- последовательным выполнением входящих в ее состав этапов;

- окончанием каждого предыдущего этапа до начала последующего;

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

- отсутствием (или определенным ограничением) возврата к предыдущим этапам;

- наличием результата только в конце разработки.

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

Итерационная модель

Итерационная модель ЖЦ, или, так называемая поэтапная модель с промежуточным контролем (Рис. 9) стала следующей стадией развития теории проектирования программного обеспечения.

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

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

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

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

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

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

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

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

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

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

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

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

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

5. Кодирование — выполняется преобразование алгоритмов в готовое программное обеспечение;

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

7. Интеграционное тестирование — осуществляются интеграция программного продукта и его тестирование;

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

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

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

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

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

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

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

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

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

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

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

Модель прототипирования

Модель прототипирования (Рис. 11) позволяет создать прототип программного продукта до или в течение этапа составления требований к программному продукту.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Недостатки многопроходной модели:

· не предусмотрены итерации внутри каждого инкремента;

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

· может возникнуть тенденция оттягивания решения трудных задач;

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

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

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

Спиральная модель

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

Рис.14 Спиральная модель

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

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

Спиральная модель обладает следующими достоинствами:

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

· заказчики принимают активное участие в разработке программного продукта;

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

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

· усложненная структура;

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

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

· целесообразно создание прототипа;

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

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

· заказчики не уверены в своих потребностях;

· требования слишком сложные;

· проект очень большой.

Rational Objectory Process

(методология объектно-ориентированного программирования)

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

· модель жизненного цикла;

· действия;

· нотация языка.

Жизненный цикл UML

Фирма Rational Software, разработавшая язык UML, предложила также и свою модель ЖЦ, которая называется Rational Objectory Process (ROP). Означенная технология прямого перевода не имеет, т.к. rational в данном случае употребляется в значении «рациональный» и как название фирмы одновременно, во-вторых, слова objectory в английском языке не существует.

Основные свойства ROP-технологии.

Rational Objectory Process – итеративный процесс, в течение которого происходит последовательное уточнение результатов.

Rational Objectory Process направлен именно на создание моделей, а не на разработку каких-либо других элементов проекта (например, текстовых документов).

Действия Rational Objectory Process определяются в первую очередь блоками использования.

Rational Objectory Process разбит на циклы, каждый из которых, в свою очередь, состоит из четырех фаз:

• начальная стадия (Inception);

• разработка (Elaboration);

• конструирование (Construction);

• ввод в эксплуатацию (Transition).

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

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

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

Окончанием начального этапа могут служить следующие результаты:

• начальный проектный словарь терминов;

• общее описание системы — основные требования к проекту, его характеристики и ограничения;

• начальная модель вариантов использования;

• начальный бизнес-план;

• план проекта, отражающий стадии и итерации;

• один или несколько прототипов.

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

• Самым важным результатом стадии разработки является описание базовой архитектуры будущей системы.

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

• оценка времени реализации каждого варианта использования;

• идентификация всех наиболее серьезных рисков и возможности их ликвидации.

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

При этом необходимо отметить следующее:

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

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

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

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

· бета-тестирование, позволяющее убедиться, что новая соответствует ожиданиям пользователей;

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

· оптимизацию производительности;

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

Дата добавления: 2014-01-05