Модели традиционного представления о жизненном цикле

Каскадная модель

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

Характерные черты каскадной модели:

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

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

увеличить изображение
Рис. 7.3. Каскадная модель

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

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

Результат проектирования верифицируется, т.е. проверяется, обеспечивают ли принятая структура системы и реализационные механизмы выполнимость специфицированных функций.

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

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

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

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

В ходе эксплуатации и сопровождения изделия устанавливается, насколько хорошо система соответствует пользовательским запросам, т.е. осуществляется переаттестация.

Каждая из указанных проверок может отослать разработчиков системы к любому из ранее пройденных этапов, что иллюстрируется стрелками на рис. 7.3. В то же время каскадная модель разработана в ответ на требование практики реализации программных проектов, в которых за счет преодоления проверочных барьеров достигается минимизация возвратов к пройденным этапам. Такая минимизация возможна не только в отношении количества откатов по схеме: за счет ужесточения проверок разработчики пытаются ликвидировать прямые возвраты через несколько этапов. Соответствующая схема, называемая строгой каскадной моделью, ^{2Сегодня строгая каскадная модель рассматривается как чуть ли не единственная модель жизненного цикла последовательного развития проектов. Поэтому слова "waterfall", "sequential" и "cascade" применительно к процессу разработки программных проектов часто считают синонимами. Как мы успели убедиться, это не совсем корректно.} представлена на рис. 7.4.

увеличить изображение
Рис. 7.4. Строгая каскадная модель

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

• оно противоречиво, т.е. содержит несовместимые или невыполнимые требования;
• не выработаны критерии для выбора одного из возможных вариантов решения.

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

Строгая каскадная модель фиксирует два важных момента жизненного цикла:

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

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

Строгая каскадная модель с незначительными модификациями часто рассматривается в реальных технологических шаблонах как основа жизненного цикла разработки программных систем, когда она строится по последовательной схеме. В качестве примера такого использования приведем каскадную модель, предлагаемую разработчиками MSF [ 44 ] для управления последовательно развивающимися проектами или частями проектов (см. рис. 7.5).

Рис. 7.5. Каскадная модель MSF

Она примечательна в нескольких отношениях.

• Принята более абстрактная схема, которая указывает лишь на наличие этапов, а не на их содержание: этапы-работы обозначаются стрелками, соединяющими так называемые вехи (контрольные точки). Для реального проекта всегда этапы и вехи конкретизируются. Изображение вех как "осязаемых" фигур и работ как лишь соединительных линий соответствует тому, что активность менеджмента возрастает именно в контрольных точках.
• В связи с абстрактностью модели появляются претензии на универсальную ее применимость, что фактически означает размытость границ адекватного использования. Абстрактная схема может автоматически поддерживаться только на универсальном уровне, тогда как в реальных ситуациях требуется различная поддержка качественно различающихся этапов.
• Модель строго последовательная, отличающаяся от схемы общепринятой модели лишь явным указанием на наличие вех, прохождение которых (с подтверждением, верификацией и аттестацией, остающимися за кадром), означает завершение этапа.
• Как следствие предыдущего, не учитываются только что рассмотренные моменты строгой каскадной модели: разделение труда и совместная работа на соседних этапах. В результате соответствующие аспекты не формализуются и их приходится объяснять дополнительно.
• Модель работает, когда на начальном этапе проекта или на последовательно развиваемой его части можно четко определить неизменный набор требований к разрабатываемому решению. Однако это условие редко соответствует реальности.

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

Описывая жизненные циклы, сегодня уже не рассматривают два предыдущих вида моделей, более того, говорят лишь о строгой каскадной модели как об основе последовательного развития проектов (см., например, [ 23 ] ). Это напрасно, поскольку демонстрация различных представлений в их развитии позволяет лучше понимать и разграничивать аспекты. Следует предостеречь читателя об опасности абсолютизации. Все подходы к менеджменту проектов, применяемые на практике, исходят из специфики конкретных проектов и ситуаций, в которых они развиваются. И если попытаться внедрить "понравившуюся" методологию и, в частности, ее представление о жизненном цикле в чужеродную среду, то в результате она потеряет все свои преимущества. Мы убеждены, что следует всегда явно указывать не только достоинства, но и недостатки какого бы то ни было подхода. Иными словами, надо знать границы применимости подходов.