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

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

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

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

• циклическое повторение пройденных этапов (как в классической модели).

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

На рис. 7.3 приведена схема каскадной модели, построенная как мо­дификация классической итерационной модели.

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

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

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

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

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

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

• аттестация отвечает на вопрос, правильно ли работает программ­ная система.

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

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

Каждая из указанных проверок может отослать разработчиков сис­темы к любому из ранее пройденных этапов, что иллюстрируется стрел­ками на рис. 7.3- В то же время каскадная модель разработана в ответ на требование практики реализации программных проектов, в которых за :чет преодоления проверочных барьеров достигается минимизация воз­вратов к пройденным этапам. Такая минимизация возможна не только в отношении количества откатов по схеме: за счет ужесточения проверок разработчики пытаются ликвидировать прямые возвраты через несколько этапов. Соответствующая схема, называемая строгой каскадной моделью*, представлена на рис. 7.4.

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

• оно противоречиво, т.е. содержит несовместимые или невыполни­мые требования;

• не выработаны критерии для выбора одного из возможных вариан­тов решения.

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

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

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

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

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

* Сегодня строгая каскадная модель рассматривается как чуть ли не единственная модель жиз­ненного цикла последовательного развития проектов. Поэтому слова «waterfall», «sequential» и «cascade» применительно к процессу разработки программных проектов часто считают сино­нимами. Как мы успели убедиться, это не совсем корректно.

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

• Принята более абстрактная схема, которая указывает лишь на на­личие этапов, а не на их содержание: этапы-работы обозначаются стрелками, соединяющими так называемые вехи (контрольные точки). Для реального проекта всегда этапы и вехи конкретизиру­ются. Изображение вех как «осязаемых» фигур и работ как лишь соединительных линий соответствует тому, что активность менедж­мента возрастает именно в контрольных точках.

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

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

• Как следствие предыдущего, не учитываются только что рассмотрен­ные моменты строгой каскадной модели: разделение труда и совмест­ная работа на соседних этапах. В результате соответствующие аспек­ты не формализуются и их приходится объяснять дополнительно.

• Модель работает, когда на начальном этапе проекта или на после­довательно развиваемой его части можно четко определить неиз­менный набор требований к разрабатываемому решению. Однако это условие редко соответствует реальности.

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

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