Итеративная и инкрементальная модель – эволюционный подход

⇐ ПредыдущаяСтр 3 из 16Следующая ⇒

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

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

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

Рисунок. Снижение неопределенности и инкрементальное расширение функциональности при итеративной организации жизненного цикла.

Достоинства:

- снижение неопределённости в требованиях по мере проектирования, позволяющее уменьшать число откатов;

- совмещение относительно строгой последовательности шагов и итеративного подхода обеспечивает достаточно сбалансированный по рискам затрат план работ.

Недостатки:

- трудность прогнозирования сроков окончания проекта;

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

Сфера применения:

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

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

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

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

Боэм формулирует перечень наиболее распространенных (по приоритетам) рисков [25]:

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

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

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

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

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

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

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

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

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

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

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

Рисунок 4. Оригинальная спиральная модель жизненного цикла разработки по Боэму

В 2000 году [Boehm, 2000], представляя анализ использования спиральной модели и, в частности, построенного на его основе подхода MBASE – Model-Based (System) Architecting and Software Engineering (MBASE), Боэм формулирует 6 ключевых характеристик или практик, обеспечивающих успешное применение спиральной модели:

1. Параллельное, а не последовательное определение артефактов (активов) проекта

2. Согласие в том, что на каждом цикле уделяется внимание:

o целям и ограничениям, важным для заказчика

o альтернативам организации процесса и технологических решений, закладываемых в продукт

o идентификации и разрешению рисков

o оценки со стороны заинтересованных лиц (в первую очередь заказчика)

o достижению согласия в том, что можно и необходимо двигаться дальше

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

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

5. Управление жизненным циклом в контексте обязательств всех заинтересованных лиц на основе трех контрольных точек:

- Life Cycle Objectives (LCO)

- Life Cycle Architecture (LCA)

- Initial Operational Capability (IOC)

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

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

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

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

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

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

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

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

Достоинства:

– большое внимание раннему анализу возможностей повторного использования;

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

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

– контроль источников проектных работ и соответствующих затрат;

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

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

Недостатки:

– высокая нагрузка на заказчика, который становится, по сути, участником разработки;

– большая сложность в прогнозировании окончания проектных работ;

– наличие риска снижения качества финальной версии ПС по причине отказа от последних итераций для снижения сроков разработки.

Сфера применения:

– программные средства широкого применения (операционные системы, офисные программы, бизнес-приложения, игры и т.д.), разрабатываемые для коммерческого использования и некритичные к некоторому количеству небольших ошибок;

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

Следует отметить, что с позиций отечественных стандартов существует только каскадная модель жизненного цикла, регламентированная в ГОСТ 19.102-77. Однако форма изложения стандарта позволяет с некоторыми уточнениями использовать его и для других моделей жизненного цикла.

⇐ Предыдущая 1 234 5 6 7 8 9 10 Следующая ⇒