Область применения каскадной модели

 

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

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

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

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

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

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

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

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

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

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

Марри Кантор [7] отмечает ряд важных аспектов, характерных для каскадной модели. Каскадная схема включает несколько важных операций, применимых ко всем проектам:

· составление плана действий по разработке системы;

· планирование работ, связанных с каждым действием;

· применение контрольных этапов отслеживания хода выполнения действий.

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

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

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

· заранее заданная последовательность этапов упрощает задачу планирования и позволяет вести контроль сроков завершения каждого этапа.

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

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

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

Одна из проблем такой модели ЖЦ разработки заключается в отсутствии возможности оценить конечный результат до завершения всего процесса разработки ПО. Как показывает практика, будущие пользователи охотнее вносят изменения и уточнения в ходе оценки какого-либо прототипа системы (которого в данной модели ЖЦ не строится).

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

 

2. V-образная модель разработки. Достоиства и недостатки, рекомендации по применимости

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

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

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

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

 

Рис. 4. V –образная модель жизненного цикла разработки ПО

 

Фазы V-образной модели

Ниже подано краткое описание каждой фазы V-образной модели, начиная от планирования проекта и требований вплоть до приемочных испытаний:

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