Модели процесса разработки ПС (каскадная, спиральная)

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

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

Модель ЖЦ ПО включает в себя:

1. Стадии;

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

3. Ключевые события — точки завершения работ и принятия решений.

В 1970 году Уинстон Ройс (компания TRW) предложил модель разработки, известную как модель “водопада” (или “каскадная” модель). Схематично ее можно изобразить следующим образом:

В модели “водопада” содержатся следующие усовершенствования строго “пошаговой” модели:

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

b. Появились петли обратной связи между этапами, т.е. есть возможность вернуться на этап выше, если необходимо.

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

d. Возросла роль анализа требований – они являются основой для проектирования и кодирования.

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

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

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

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

Недостатки:

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

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

Впервые эту модель предложил Боэм в 1988 году. Модель базируется на лучших свойствах классической модели и макетирования, к которым добавляется новый элемент – анализ риска. И еще появился новый этап – системный анализ.

Схематично спиральную модель можно изобразить следующим образом:

Итак, модель определяет 4 основных действия, которые представлены четырьмя квадрантами спирали.

1. Планирование – определение целей, требований, ограничений, а также составление плана разработки витка спирали (начиная со 2-го витка спирали, планирование проводится уже на основе оценки и рекомендаций заказчика).

2. Анализ риска (на 1-м витке спирали анализ риска на основе начальных требований, на следующих – на основе реакции заказчика).

3. Конструирование – разработка ПС (на 1-м витке – начальный макет, на 2-м – следующий уровень макета, на последнем – готовая система).

4. Оценивание – оценка заказчиком текущих результатов конструирования.

Получается, что с каждым витком спирали строятся все более полные версии ПО (и по функциональности, и по эффективности).

Достоинства спиральной модели:

• наиболее реально (в виде эволюции) отображает разработку ПО;

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

• использует моделирование для уменьшения риска.

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

• повышенные требования к заказчику;

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

15. Модели процесса разработки ПС (компонентно-ориентированная, инкрементная, RAD – модель).

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

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

Модель ЖЦ ПО включает в себя:

1. Стадии;

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

3. Ключевые события — точки завершения работ и принятия решений.

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

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

Впервые эту модель предложил Кратчен в 1995 году. Затем Ройс слегка усовершенствовал ее в 1998 году.

В начале процесса конструирования определяются почти все пользовательские и системные требования. Затем конструирование выполняется в виде последовательности итераций. На первой итерации реализуется часть запланированных функций (возможностей) – самых важных (базовых) или самых рискованных (с высоким уровнем риска. Следующая версия реализует дополнительные возможности и т. д., пока не будет получена полная система (реализует все запланированные функции).

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

RAD (от англ. rapid application development — быстрая разработка приложений) — - это жизненный цикл процесса проектирования, созданный для достижения более высоких скорости разработки и качества ПО, чем это возможно при традиционном подходе к проектированию.

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

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

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

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

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

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

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

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

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

Технология быстрой разработки приложений (RAD) позволяет обеспечить:

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

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

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

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