Модели жизненного цикла автоматизированных информационных систем

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

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

зультатом работы.

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

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

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

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

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

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

1) Требования к программному продукту заранее неизвестны;

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

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

4) Нужна проверка концепции;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 8Многопроходная модель

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

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

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

 Скачать реферат