Каскадная модель. Первоначально (1970-1985 годы) была предложена и использовалась каскадная схема разработки программного обеспечения (рисунок 5.1), которая предполагала, что переход на следующую стадию осуществляется после того, как полностью будут завершены проектные операции предыдущей стадии и получены все исходные данные для следующей стадии.
Рисунок 5.1 Каскадная модель ЖЦ
Достоинствами такой схемы являются:
• получение в конце каждой стадии законченного набора проектной документации,
отвечающего требованиям полноты и согласованности;
• простота планирования процесса разработки.
Именно такую схему и используют обычно при блочно-иерархическом подходе к разработке сложных технических объектов, обеспечивая очень высокие параметры эффективности разработки. Однако данная схема оказалась применимой только к созданию систем, для которых в самом начале разработки удавалось точно и полно сформулировать все требования. Это уменьшало вероятность возникновения в процессе разработки проблем, связанных с принятием неудачного решения на предыдущих стадиях. На практике такие разработки встречается крайне редко.
В целом необходимость возвратов на предыдущие стадии обусловлена следующими
причинами:
• неточные спецификации, уточнение которых в процессе разработки может привести к необходимости пересмотра уже принятых решений;
• изменение требований заказчика непосредственно в процессе разработки;
• быстрое моральное устаревание используемых технических и программных средств;
• отсутствие удовлетворительных средств описания разработки на стадиях постановки задачи, анализа и проектирования.
Отказ от уточнения (изменения) спецификаций приведет к тому, что законченный продукт не будет удовлетворять потребности пользователей. При отказе от учета смены оборудования и программной среды пользователь получит морально устаревший продукт. А отказ от пересмотра неудачных проектных решений приводит к ухудшению структуры программного продукта и, соответственно, усложнит, растянет по времени и удорожит процесс его создания. Реальный процесс разработки, таким образом, носит итерационный характер.
Модель с промежуточным контролем.Схема, поддерживающая итерационный характер процесса разработки, была названа схемой с промежуточным контролем. Контроль, который выполняется по данной схеме после завершения каждого этапа, позволяет при необходимости вернуться на любой уровень и внести необходимые изменения (рисунок 5.2). Основная опасность использования такой схемы связана с тем, что разработка никогда не будет завершена, постоянно находясь в состоянии уточнения и усовершенствования.
Рисунок 5.2 Модель ЖЦ с промежуточным контролем
Примечание. Народная мудрость в подобных случаях говорит «лучшее - враг хорошего».
Осталось только понять, что можно считать «хорошим» и как все-таки добиться лучшего...
Спиральная модель.Для преодоления перечисленных проблем в середине 80-х годов XX в, была предложена спиральная схема (рисунок 5.3). В соответствии с данной схемой программное обеспечение создается не сразу, а итерационно с использованием метода прототипирования, базирующегося на создании прототипов. Именно появление прототипирования привело к тому, что процесс модификации программного обеспечения перестал восприниматься, как «необходимое зло», а стал восприниматься как отдельный важный процесс.
Прототипом называют действующий программный продукт, реализующий отдельные функции и внешние интерфейсы разрабатываемого программного обеспечения.
На первой итерации, как правило, специфицируют, проектируют, реализуют и тестируют интерфейс пользователя. На второй - добавляют некоторый ограниченный набор функций. На последующих этапах этот набор расширяют, наращивая возможности данного продукта.
Рисунок 5.3 – Спиральная модель ЖЦ
Основным достоинством данной схемы является то, что, начиная с некоторой итерации, на которой обеспечена определенная функциональная полнота, продукт можно предоставлять пользователю, что позволяет:
• сократить время до появления первых версий программного продукта;
• заинтересовать большое количество пользователей, обеспечивая быстрое продвижение следующих версий продукта на рынке;
• ускорить формирование и уточнение спецификаций за счет появления практики использования продукта;
• уменьшить вероятность морального устаревания системы за время разработки.
Основной проблемой использования спиральной схемы является определение моментов перехода на следующие стадии. Для ее решения обычно ограничивают сроки прохождения каждой стадии, основываясь на экспертных оценках.
(лекция 6)
