6. Прогностические модели процесса разработки: каскадная, RAD, спиральная

Водопадная (каскадная, последовательная) модель

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

Этапы проекта в соответствии с каскадной моделью:

· Формирование требований;

· Проектирование;

· Реализация;

· Тестирование;

· Внедрение;

· Эксплуатация и сопровождение.

Преимущества:

· Полная и согласованная документация на каждом этапе;

· Легко определить сроки и затраты на проект.

Недостатки:

· необходимость точной и полной формулировки требований к ПС перед началом разработки;

· невозможность изменения решений, принятых на предыдущих этапах;

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

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

RAD –Rapid Application Development

Основные принципы

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

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

· Создание прототипа для уточнения требований заказчика.

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

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

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

· Управление проектом должно минимизировать длительность цикла разработки.

Фазы разработки

Планирование - совокупность требований, полученных при системном планировании и анализе процедуры разработки жизненного цикла (SDLC). На этом этапе пользователи, менеджеры и IT-специалисты обсуждают задачи проекта, его объём, системные требования, а также сложности, которые могут возникнуть при разработке. Фаза завершается согласованием ключевых моментов с RAD-группой и получением от руководителей проекта разрешения на продолжение.

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

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

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

Преимущества

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

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

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

· простота развития функциональности системы.

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

Спиральная модель (англ. spiral model) была разработана в середине 1980-х годов Барри Боэмом. Она основана на классическом цикле Деминга PDCA (plan-do-check-act). При использовании этой модели ПО создается в несколько итераций (витков спирали) методом прототипирования.

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

На каждой итерации оцениваются:

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

· необходимость выполнения ещё одной итерации;

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

· целесообразность прекращения проекта.

Боэм формулирует 10 наиболее распространённых (по приоритетам) рисков:

· Дефицит специалистов.

· Нереалистичные сроки и бюджет.

· Реализация несоответствующей функциональности.

· Разработка неправильного пользовательского интерфейса.

· Перфекционизм, ненужная оптимизация и оттачивание деталей.

· Непрекращающийся поток изменений.

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

· Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.

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

· Разрыв в квалификации специалистов разных областей.

В сегодняшней спиральной модели определён следующий общий набор контрольных точек:

Concept of Operations (COO) — концепция (использования) системы;

Life Cycle Objectives (LCO) — цели и содержание жизненного цикла;

Life Cycle Architecture (LCA) — архитектура жизненного цикла; здесь же возможно говорить о готовности концептуальной архитектуры целевой программной системы;

Initial Operational Capability (IOC) — первая версия создаваемого продукта, пригодная для опытной эксплуатации;

Final Operational Capability (FOC) –— готовый продукт, развернутый (установленный и настроенный) для реальной эксплуатации.