С точки зрения структуры жизненного цикла такую модель называют итеративной (iterative). С точки зрения развития продукта – инкрементальной (incremental). Опыт индустрии показывает, что невозможно рассматривать каждый из этих взглядов изолировано. Чаще всего такую смешанную эволюционную модель называют просто итеративной (говоря о процессе) и/или инкрементальной (говоря о наращивании функциональности продукта).

Эволюционная модель подразумевает не только сборку работающей (с точки зрения результатов тестирования) версии системы, но и её развертывание в реальных операционных условиях с анализом откликов пользователей для определения содержания и планирования следующей итерации. “Чистая” инкрементальная модель не предполагает развертывания промежуточных сборок (релизов) системы и все итерации проводятся по заранее определенному плану наращивания функциональности, а пользователи (заказчик) получает только результат финальной итерации как полную версию системы.

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

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

Наиболее распространенные риски:

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

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

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

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

5. “Золотая сервировка”, перфекционизм, ненужная оптимизация и оттачивание деталей.

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

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

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

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

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

Большая часть этих рисков связана с организационными и процессными аспектами взаимодействия специалистов в проектной команде.

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

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

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

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

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

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

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

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

40. Понятие и характеристика RAD-технологии проектирования программного обеспечения экономических информационных систем.

Подход RAD (Rapid Application Developme) (Rapid (быстрая) Application (приложений) Development (разработка)) предусматривает наличие трех составляющих:

• небольших групп разработчиков (от 3 до 7 человек), выполняющих работы по проектированию отдельных подсистем ПО. Это обусловлено требованием максимальной управляемости коллектива;

• короткого, но тщательно проработанного производственного графика (до трех месяцев);

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

Основные принципы подхода RAD:

• разработка приложений итерациями;

• необязательность полного завершения работ на каждой из стадий жизненного цикла ПО;

• обязательность вовлечения пользователей в процесс разработки;

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

• использование прототипирования, позволяющее полнее выяснить и удовлетворить потребности пользователей;

• тестирование и развитие проекта, осуществляемые одновременно с разработкой;

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

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

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

Жизненный цикл ПО в соответствии с подходом RAD состоит из четырех стадий:

• анализ и планирование требований;

• проектирование;

• реализация;

• внедрение.

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