Каскадный жизненный цикл

Лекция 1

Жизненный цикл разработки программного обеспечения

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

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

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

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

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

Каскадный жизненный цикл

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

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

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

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

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

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

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

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

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

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