11-software_lifecycle_models (1133551), страница 3
Текст из файла (страница 3)
Спиральная модель является ярким представителем эволюционного взгляда, но,в то же время, представляет собой единственную модель, которая уделяет явное вниманиеанализу и предупреждению рисков. Поэтому, я попытался именно представленным выше образомвыделить три модели – каскадную, эволюционную и спиральную.
Их мы и обсудим.Каскадная (водопадная) модельДанная модель предполагает строго последовательное (во времени) и однократное выполнениевсех фаз проекта с жестким (детальным) предварительным планированием в контекстепредопределенных или однажды и целиком определенных требований к программной системе.Рисунок 2. Каскадная модель жизненного цикла.На рисунке изображены типичные фазы каскадной модели жизненного цикла и соответствующиеактивы проекта, являющиеся для одних фаз выходами, а для других - входами.
Марри Кантор[Кантор, 2002, с.145-146] отмечает ряд важных аспектов, характерных для водопадной модели:“Водопадная схема включает несколько важных операций, применимых ко всем проектам: составление плана действий по разработке системы; планирование работ, связанных с каждым действием; применение операции отслеживания хода выполнения действий с контрольными этапами.Copyright © Сергей Орлик, 2005-2010.http://swebok.sorlik.ru7Основы программной инженерии (по SWEBOK)Модели жизненного цикла программного обеспеченияВ связи с тем, что упомянутые задачи являются неотъемлемым элементом всех хорошоуправляемых процессов, практически не существует причин, препятствующих утверждениюполнофункциональных, классических методов руководства проектом, таких как анализкритического пути и промежуточные контрольные этапы.
Я часто встречался с программнымименеджерами, которые ломали себе голову над тем, почему же столь эффективный наборметодик на практике оборачивается неудачей...”Будучи активно используема (де факто и, например, в свое время, как часть соответствующегоотраслевого стандарта в США), эта модель продемонстрировала свою “проблемность” вподавляющем большинстве ИТ-проектов, за исключением, может быть, отдельных проектовобновления программных систем для критически-важных программно-аппаратных комплексов(например, авионики или медицинского оборудования).
Практика показывает, что в реальноммире, особенно в мире бизнес-систем, каскадная модель не должна применяться. Спецификатаких систем (если можно говорить о “специфике” для подавляющего большинства создаваемыхсистем) - требования характеризуются высокой динамикой корректировки и уточнения,невозможностью четкого и однозначного определения требований до начала работ по реализации(особенно, для новых систем) и быстрой изменчивостью в процессе эксплуатации системы.Фредерик Брукс во втором издании своего классического труда “Мифический человеко-месяц” такописывает главную беду каскадной модели [Брукс, 1995, с.245]:“Основное заблуждение каскадной модели состоит в предположениях, что проект проходит черезвесь процесс один раз, архитектура хороша и проста в использовании, проект осуществленияразумен, а ошибки в реализации устраняются по мере тестирования.
Иными словами, каскаднаямодель исходит из того, что все ошибки будут сосредоточены в реализации, а потому ихустранение происходит равномерно во время тестирования компонентов и системы.”В каскадной модели переход от одной фазы проекта к другой предполагает полную корректностьрезультата (выхода) предыдущей фазы. Однако, например, неточность какого-либо требованияили некорректная его интерпретация, в результате, приводит к тому, что приходится“откатываться” к ранней фазе проекта и требуемая переработка не просто выбивает проектнуюкоманду из графика, но приводит часто к качественному росту затрат и, не исключено, кпрекращению проекта в той форме, в которой он изначально задумывался.
Кроме того, эта модельне способна гарантировать необходимую скорость отклика и внесение соответствующихизменений в ответ на быстро меняющиеся потребности пользователей, для которых программнаясистема является одним из инструментов исполнения бизнес-функций. И таких примеров проблем,порождаемых самой природой модели, можно привести достаточно много.
Достаточно для чего?Для отказа от каскадной модели жизненного цикла.Итеративная и инкрементальная модель – эволюционный подходИтеративная модель предполагает разбиение жизненного цикла проекта напоследовательность итераций, каждая из которых напоминает “мини-проект”, включая все фазыжизненного цикла в применении к созданию меньших фрагментов функциональности, посравнению с проектом, в целом. Цель каждой итерации – получение работающей версиипрограммной системы, включающей функциональность, определенную интегрированнымсодержанием всех предыдущих и текущей итерации. Результата финальной итерации содержитвсю требуемую функциональность продукта. Таким образом, с завершением каждой итерации,продукт развивается инкрементально.С точки зрения структуры жизненного цикла такую модель называют итеративной (iterative). Сточки зрения развития продукта – инкрементальной (incremental).
Опыт индустрии показывает, чтоневозможно рассматривать каждый из этих взглядов изолировано. Чаще всего такую смешаннуюэволюционную модель называют просто итеративной (говоря о процессе) и/или инкрементальной(говоря о наращивании функциональности продукта).Эволюционная модель подразумевает не только сборку работающей (с точки зрения результатовтестирования) версии системы, но и еѐ развертывание в реальных операционных условиях санализом откликов пользователей для определения содержания и планирования следующейитерации. “Чистая” инкрементальная модель не предполагает развертывания промежуточныхсборок (релизов) системы и все итерации проводятся по заранее определенному плануCopyright © Сергей Орлик, 2005-2010.http://swebok.sorlik.ru8Основы программной инженерии (по SWEBOK)Модели жизненного цикла программного обеспечениянаращивания функциональности, а пользователи (заказчик) получает только результат финальнойитерации как полную версию системы.
С другой стороны, Скотт Амблер [Ambler, 2004], например,определяет эволюционную модель как сочетание итеративного и инкрементального подходов. Всвою очередь, Мартин Фаулер [Фаулер, 2004, с.47] пишет: “Итеративную разработку называют поразному: инкрементальной, спиральной, эволюционной и постепенной. Разные люди вкладывают вэти термины разный смысл, но эти различия не имеют широкого признания и не так важны, какпротивостояние итеративного метода и метода водопада.”Брукс пишет [Брукс, 1995, с.246-247], что, в идеале, поскольку на каждом шаге мы имеемработающую систему: можно очень рано начать тестирование пользователями; можно принять стратегию разработки в соответствии с бюджетом, полностьюзащищающую от перерасхода времени или средств (в частности, за счет сокращениявторостепенной функциональности).Таким образом, Значимость эволюционного подхода на основе организации итераций особопроявляется в снижении неопределенности с завершением каждой итерации.
В свою очередь,снижение неопределенности позволяет уменьшить риски. Рисунок 3 иллюстрирует некоторые идеиэволюционного подхода, предполагая, что итеративному разбиению может быть подвержен нетолько жизненный цикл в целом, включающий перекрывающиеся фазы – формированиетребований, проектирование, конструирование и т.п., но и каждая фаза может, в свою очередь,разбиваться на уточняющие итерации, связанные, например, с детализацией структурыдекомпозиции проекта – например, архитектуры модулей системы.Рисунок 3. Снижение неопределенности и инкрементальное расширение функциональности приитеративной организация жизненного цикла.Наиболее известным и распространенным вариантом эволюционной модели является спиральнаямодель.Copyright © Сергей Орлик, 2005-2010.http://swebok.sorlik.ru9Основы программной инженерии (по SWEBOK)Модели жизненного цикла программного обеспеченияСпиральная модельСпиральная модель (представлена на рисунке 4) была впервые сформулирована Барри Боэмом(Barry Boehm) в 1988 году [Boehm, 1988].
Отличительной особенностью этой модели являетсяспециальное внимание рискам, влияющим на организацию жизненного цикла.Боэм формулирует “top-10” наиболее распространенных (по приоритетам) рисков (используется сразрешения автора):1. Дефицит специалистов.2. Нереалистичные сроки и бюджет.3. Реализация несоответствующей функциональности.4. Разработка неправильного пользовательского интерфейса.5. “Золотая сервировка”, перфекционизм, ненужная оптимизация и оттачивание деталей.6. Непрекращающийся поток изменений.7.
Нехватка информации о внешних компонентах, определяющих окружение системы иливовлеченных в интеграцию.8. Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.9. Недостаточная производительность получаемой системы.10. “Разрыв” в квалификации специалистов разных областей знаний.Большая часть этих рисков связана с организационными и процессными аспектамивзаимодействия специалистов в проектной команде.Рисунок 4. Оригинальная спиральная модель жизненного цикла разработки по Боэму(используется с разрешения автора) [Boehm, 1988]Copyright © Сергей Орлик, 2005-2010.http://swebok.sorlik.ru10Основы программной инженерии (по SWEBOK)Модели жизненного цикла программного обеспеченияСам Барри Боэм так характеризует спиральную модель разработки (используется с разрешенияавтора):“Главное достижение спиральной модели состоит в том, что она предлагает спектр возможностейадаптации удачных аспектов существующих моделей процессов жизненного цикла.
В то же время,ориентированный на риски подход позволяет избежать многих сложностей, присутствующих в этихмоделях. В определенных ситуациях спиральная модель становится эквивалентной одной изсуществующих моделей. В других случаях она обеспечивает возможность наилучшего соединениясуществующих подходов в контексте данного проекта.Спиральная модель обладает рядом преимуществ:Модель уделяет специальное внимание раннему анализу возможностей повторногоиспользования. Это обеспечивается, в первую очередь, в процессе идентификации и оценкиальтернатив.Модель предполагает возможность эволюции жизненного цикла, развитие и изменениепрограммного продукта. Главные источники изменений заключены в целях, для достижениякоторых создается продукт. Подход, предусматривающий скрытие информации о деталях наопределенном уровне дизайна, позволяет рассматривать различные архитектурные альтернативытак, как если бы мы говорили о единственном проектном решении, что уменьшает рискневозможности согласования функционала продукта и изменяющихся целей (требований).Модель предоставляет механизмы достижения необходимых параметров качества каксоставную часть процесса разработки программного продукта.
Эти механизмы строятся наоснове идентификации всех типов целей (требований) и ограничений на всех “циклах” спиралиразработки. Например, ограничения по безопасности могут рассматриваться как риски на этапеспецифицирования требований.Модель уделяет специальное внимание предотвращению ошибок и отбрасыванию ненужных,необоснованных или неудовлетворительных альтернатив на ранних этапах проекта. Этодостигается явно определенными работами по анализу рисков, проверке различных характеристиксоздаваемого продукта (включая архитектуру, соответствие требованиям и т.п.) и подтверждениевозможности двигаться дальше на каждом “цикле” процесса разработки.Модель позволяет контролировать источники проектных работ и соответствующих затрат.По-сути речь идет об ответе на вопрос – как много усилий необходимо затратить на анализтребований, планирование, конфигурационное управление, обеспечение качества, тестирование,формальную верификацию и т.д.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
