1.5Модели жизненного цикла
Согласно ГОСТ Р ИСО/МЭК 12207 выделяют следующие модели жизненного цикла [ГОСТ Р ИСО/МЭК 12207]:
каскадная (водопадная) или последовательная;
итеративная и инкрементальная – эволюционная (гибридная, смешанная);
спиральная (spiral) или модель Боэма.
1.5.1Каскадная (водопадная) модель
Данная модель предполагает строго последовательное (во времени) и однократное выполнение всех фаз проекта с жестким (детальным) предварительным планированием в контексте предопределенных или однажды и целиком определенных требований к программной системе.
Рисунок. Каскадная модель жизненного цикла.
На рисунке изображены типичные фазы каскадной модели жизненного цикла и соответствующие активы проекта, являющиеся для одних фаз выходами, а для других – входами.
Практика показывает, что каскадная модель не эффективна для большинства ИТ-проектов. В программной инженерии – высокая «подвижность» требований, которые часто корректируются и уточняются, в силу невозможности их четкого и однозначного определения требований до начала работ по реализации. В каскадной модели переход от одной фазы проекта к другой предполагает полную корректность результата (выхода) предыдущей фазы. Однако, например, неточность какого-либо требования или некорректная его интерпретация, в результате, приводит к тому, что приходится “откатываться” к ранней фазе проекта и требуемая переработка не просто выбивает проектную команду из графика, но приводит часто к качественному росту затрат и, не исключено, к прекращению проекта в той форме, в которой он изначально задумывался. Кроме того, эта модель не способна гарантировать необходимую скорость отклика и внесение соответствующих изменений в ответ на быстро меняющиеся потребности пользователей, для которых программная система является одним из инструментов исполнения бизнес-функций. И таких примеров проблем, порождаемых самой природой модели, можно привести достаточно много.
Достоинство:
наличие чёткого плана и временного графика по всем этапам проекта.
Недостатки:
высокие издержки по причине частых откатов;
реальные проекты часто требуют отклонения от стандартной последовательности шагов;
цикл основан на точной формулировке исходных требований к ПО (реально в начале проекта требования заказчика определены лишь частично);
результаты проекта доступны заказчику только в конце работы.
Сфера применения:
программные средства, являющиеся элементами аппаратных систем, требования к которым хорошо определены и изменяются не часто;
программные средства, применяемые в оборонной, медицинской, космической или авиационной отрасли.
1.5.2Итеративная и инкрементальная модель – эволюционный подход
Итеративная модель предполагает разбиение жизненного цикла проекта на последовательность итераций, каждая из которых представляет собой самостоятельный проект, но в миниатюре, включая все фазы жизненного цикла. Цель каждой итерации – получение работающей версии программной системы, включающей функциональность, определенную интегрированным содержанием всех предыдущих и текущей итерации. Результатом финальной итерации является версия ПС, которая реализует всю требуемую функциональность продукта. Таким образом, с завершением каждой итерации, продукт развивается инкрементально.
Эволюционная модель подразумевает не только сборку работающей (с точки зрения результатов тестирования) версии системы, но и её развертывание в реальных операционных условиях с анализом откликов пользователей для определения содержания и планирования следующей итерации.
Значимость эволюционного подхода на основе организации итераций особо проявляется в снижении неопределенности с завершением каждой итерации. В свою очередь, снижение неопределенности позволяет уменьшить риски. Рисунок 3 иллюстрирует некоторые идеи эволюционного подхода, предполагая, что итеративному разбиению может быть подвержен не только жизненный цикл в целом, включающий перекрывающиеся фазы – формирование требований, проектирование, конструирование и т.п., но и каждая фаза может, в свою очередь, разбиваться на уточняющие итерации, связанные, например, с детализацией структуры декомпозиции проекта – например, архитектуры модулей системы.
Рисунок . Снижение неопределенности и инкрементальное расширение функциональности при итеративной организации жизненного цикла.
Достоинства:
снижение неопределённости в требованиях по мере проектирования, позволяющее уменьшать число откатов;
совмещение относительно строгой последовательности шагов и итеративного подхода обеспечивает достаточно сбалансированный по рискам затрат план работ.
Недостатки:
трудность прогнозирования сроков окончания проекта;
возможность отката при интеграции отдельных компонентов, что может приводить к откатам и связанным с ними затратам.
Сфера применения:
программные средства, имеющие относительно несложную структуру в несколько десятков модулей, компоненты которой можно достаточно легко сочетать.
Наиболее известным и распространенным вариантом эволюционной модели является спиральная модель, ставшая уже, по сути, самостоятельной моделью, имеющей различные сценарии развития и детализации.
1.5.3Спиральная модель
Спиральная модель была впервые сформулирована Барри Боэмом (Barry Boehm) в 1988 году [Boehm, 1988]. Отличительной особенностью этой модели является специальное внимание рискам, влияющим на организацию жизненного цикла.
Боэм формулирует перечень наиболее распространенных (по приоритетам) рисков [SWEBOK]:
Дефицит специалистов.
Нереалистичные сроки и бюджет.
Реализация несоответствующей функциональности.
Разработка неправильного пользовательского интерфейса.
“Золотая сервировка”, перфекционизм, ненужная оптимизация и оттачивание деталей.
Непрекращающийся поток изменений.
Нехватка информации о внешних компонентах, определяющих окружение системы или вовлеченных в интеграцию.
Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.
Недостаточная производительность получаемой системы.
“Разрыв” в квалификации специалистов разных областей знаний.
Большая часть этих рисков связана с организационными и процессными аспектами взаимодействия специалистов в проектной команде.
Рисунок 4. Оригинальная спиральная модель жизненного цикла разработки по Боэму
В 2000 году [Boehm, 2000], представляя анализ использования спиральной модели и, в частности, построенного на его основе подхода MBASE – Model-Based (System) Architecting and Software Engineering (MBASE), Боэм формулирует 6 ключевых характеристик или практик, обеспечивающих успешное применение спиральной модели:
Параллельное, а не последовательное определение артефактов (активов) проекта
Согласие в том, что на каждом цикле уделяется внимание:
целям и ограничениям, важным для заказчика
альтернативам организации процесса и технологических решений, закладываемых в продукт
идентификации и разрешению рисков
оценки со стороны заинтересованных лиц (в первую очередь заказчика)
достижению согласия в том, что можно и необходимо двигаться дальше
Использование соображений, связанных с рисками, для определения уровня усилий, необходимого для каждой работы на всех циклах спирали.
Использование соображений, связанных с рисками, для определения уровня детализации каждого артефакта, создаваемого на всех циклах спирали.
Управление жизненным циклом в контексте обязательств всех заинтересованных лиц на основе трех контрольных точек:
Life Cycle Objectives (LCO)
Life Cycle Architecture (LCA)
Initial Operational Capability (IOC)
Уделение специального внимания проектным работам и артефактам создаваемой системы (включая непосредственно разрабатываемое программное обеспечение, ее окружение, а также эксплуатационные характеристики) и жизненного цикла (разработки и использования).
Эволюционирование спиральной модели, таким образом, связано с вопросами детализации работ. Особенно стоит выделить акцент на большем внимании вопросам уточнения – требований, дизайна и кода, т.е. придание большей важности вопросам итеративности, в том числе, увеличения их количества при сокращении длительности каждой итерации.
В результате, можно определить общий набор контрольных точек в сегодняшней спиральной модели:
Concept of Operations (COO) – концепция <использования> системы;
Life Cycle Objectives (LCO) – цели и содержание жизненного цикла;
Life Cycle Architecture (LCA) – архитектура жизненного цикла; здесь же возможно говорить о готовности концептуальной архитектуры целевой программной системы;
Initial Operational Capability (IOC) – первая версия создаваемого продукта, пригодная для опытной эксплуатации;
FinalOperationalCapability (FOC) – готовый продукт, развернутый (установленный и настроенный) для реальной эксплуатации.
Достоинства:
большое внимание раннему анализу возможностей повторного использования;
предоставляет механизмы достижения необходимых параметров качества как составную часть процесса разработки программного продукта;
большое внимание предотвращению ошибок и отбрасыванию ненужных, необоснованных или неудовлетворительных альтернатив на ранних этапах проекта, за счёт работ по анализу рисков, проверке различных характеристик создаваемого продукта (включая архитектуру, соответствие требованиям и т.п.) и подтверждение возможности двигаться дальше на каждом “цикле” процесса разработки;
контроль источников проектных работ и соответствующих затрат;
возможность использования модели как для разработки нового продукта, так и для расширения (или сопровождения) существующего;
возможность решения интегрированных задач системной разработки, охватывающих и программную и аппаратную составляющие создаваемого продукта.
Недостатки:
высокая нагрузка на заказчика, который становится, по сути, участником разработки;
большая сложность в прогнозировании окончания проектных работ;
наличие риска снижения качества финальной версии ПС по причине отказа от последних итераций для снижения сроков разработки.
Сфера применения:
программные средства широкого применения (операционные системы, офисные программы, бизнес-приложения, игры и т.д.), разрабатываемые для коммерческого использования и некритичные к некоторому количеству небольших ошибок;
программное обеспечение информационных систем, разработка которого может без потерь продолжаться и в процессе сопровождения.
Следует отметить, что с позиций отечественных стандартов существует только каскадная модель жизненного цикла, регламентированная в ГОСТ 19.102-77. Однако форма изложения стандарта позволяет с некоторыми уточнениями использовать его и для других моделей жизненного цикла.
|
