Лекция №2 Модели проектирования ис

Методология проектирования информационных систем описывает процесс создания и сопровождения систем в виде жизненного цикла (ЖЦ) ИС, представляя его как некоторую последовательность стадий и выполняемых на них процессов. Для каждого этапа определяются состав и последовательность выполняемых работ, получаемые результаты, методы и средства, необходимые для выполнения работ, роли и ответственность участников и т.д. Такое формальное описание ЖЦ ИС позволяет спланировать и организовать процесс коллективной разработки и обеспечить управление этим процессом.

Жизненный цикл ИС можно представить как ряд событий, происходящих с системой в процессе ее создания и использования.

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

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

• Каскадная

• Спиральная

• Итеративная

• V-model

Рассмотрим подробнее все этим модели:

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

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

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

Рис. 2.1.  Каскадная модель ЖЦ ИС

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

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

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

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

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

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

Отличительным свойством каскадной модели можно назвать то, что она представ­ляет собой формальный метод, разновидность разработки "сверху вниз", она состоит из независимых фаз, выполняемых последовательно, и подвержена частому обзору.

Преимущества каскадной модели

Нетрудно заметить, что каскадная модель имеет множество преимуществ, если ее использовать в проекте, для которого она достаточно приемлема. Ниже перечислены эти преимущества:

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

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

• она весьма доступна для понимания, так как преследуется простая цель — выпол­нить необходимые действия;

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

• ее структурой может руководствоваться даже слабо подготовленный в техниче­ском плане или неопытный персонал;

• она отличается стабильностью требований;

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

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

• она способствует осуществлению строгого контроля менеджмента проекта;

• при правильном использовании модели дефекты можно обнаружить на более ран­них этапах, когда их устранение еще не требует относительно больших затрат;

• она облегчает работу менеджеру проекта по составлению плана и Комплектации команды разработчиков;

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

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

• стадии модели довольно хорошо определены и понятны;

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

Недостатки каскадной модели

Но при использовании каскадной модели для проекта, который трудно назвать подходящим для нее, проявляются следующими недостатки:

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

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

• она не отображает основное свойство разработки ПО, направленное на разреше­ние задач. Отдельные фазы строго связаны с определенными действиями, что отличается от реальной работы персонала или коллективов;

• она может создать ошибочное впечатление о работе над проектом. Выражение типа "35 процентов выполнено" — не несет никакого смысла и не является показа­телем для менеджера проекта;

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

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

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

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

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

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

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

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

• возникает необходимость в жестком управлении и контроле, поскольку в модели не предусмотрена возможность модификации требований;

• модель основана на документации, а значит, количество документов может быть избыточным;

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

• отсутствует возможность учесть переделку и итерации за рамками проекта.

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

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

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

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

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

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