Модели жизненного цикла

Жизненный цикл можно изучать сам по себе, поэтому можно строить те или иные модели жизненного цикла, определяющие взаимосвязи и последовательность выполнения процессов, действий и задач на этапах разработки и эксплуатации. Модель жизненного цикла, с одной стороны, зависит от типа создаваемого продукта, а с другой стороны, определяет характер процесса создания ПО. В настоящее время общепринятыми являются две модели: каскадная и спиральная. Название каскадной модели по-английски звучит как waterfall model, что переводится как «водопадная модель». Изображение (рис.1) этапов и переходов от этапа к этапу напоминает водопад.

Рис. 1. Каскадная модель жизненного цикла.

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

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

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

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

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

Вендров[7]: «Основным недостатком каскадного подхода является существенное запаздывание с получением результатов и, как следствие, достаточно высокий риск создания системы, не удовлетворяющий требованиям пользователя». На самом деле первое влияет на второе, но никак не определяющим образом. Запаздывание – это недостаток опыта планирования работ в области разработки ПО. Неудовлетворение же потребностей пользователя вызвано самой каскадной моделью: на начальной стадии работ полностью и точно сформулировать требования к будущей системе часто не удается. Во-первых, сами пользователи не обладают достаточным опытом, чтобы точно сформулировать требования к системе; во-вторых, за время разработки могут произойти изменения во внешней среде, которые повлияют на требования к системе. Например, изменится операционная система, в которой должна будет работать будущая система. Однако сама сущность каскадной модели заключается именно в том, что требования и проектные решения, хотя и согласовываются с заказчиком, но в некоторый момент фиксируются в соответствующих документах и более уже не изменяются.

Рис. 2. Каскадная модель с обратной связью.

Практика разработки больших систем потребовала создания модели другого рода, которая отражала бы непрерывный процесс «продолжающейся разработки», придерживаясь в то же время традиционного деления на стадии разработки. Таким образом, была придумана спиральная модель (рис.3). Её особенностью является то, что процесс эволюции программы включается в цикл разработки. На каждом витке создается очередная версия системы.

Рис. 3. Спиральная модель разработки ПО.

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

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