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

Рисунок 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) Многопроходная модель

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

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

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

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

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

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

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