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

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

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

Достоинствами такой схемы являются:

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

• простота планирования процесса разработки.

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

В целом необходимость возвратов на предыдущие стадии обусловлена следующими причинами:

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

• изменение требований заказчика непосредственно в процессе разра­ботки;

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

• отсутствие удовлетворительных средств описания разработки на стадиях постановки задачи, анализа и проектирования.

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

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

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

Примечание. Народная мудрость в подобных случаях говорит «лучшее - враг хорошего». Осталось только понять, что можно считать «хорошим» и как все-таки добиться лучшего...

Спиральная модель. Для преодоления перечисленных проблем в сере­дине 80-х годов XX в. была предложена спиральная схема (рис. 1,12). В со­ответствии с данной схемой программное обеспечение создается не сразу, а итерационно с использованием метода прототипирования, базирующегося на создании прототипов. Именно появление прототипирования привело к то­му, что процесс модификации программного обеспечения перестал воспри­ниматься, как «необходимое зло», а стал восприниматься как отдельный важный процесс.

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

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

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

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

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

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

• уменьшить вероятность морального устаревания системы за время разработки.

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

Дата добавления: 2014-01-07