Жизненный цикл программы

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

Этот процесс нужно спланировать, оценить ресурсы, для чего, в свою очередь, требуются более или менее точные спецификации

Появление понятия жизненного цикла ПО было связано с кризисом программирования, который наметился в конце 60-х – начале 70-х годов прошлого века.

Суть кризиса состояла в том, что программные проекты все чаще стали выходить из-под контроля: нарушались сроки, превышались запланированные объемы финансирования, результаты не соответствовали требуемым. Многие проекты вообще не доводились до завершения.

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

Ситуация была вызвана ростом сложности проектов. Масштабы ее нарастали. Необходимо было принимать меры для радикального усовершенствования принципов и методов разработки ПО с учетом его развития и сопровождения.

Впервые о жизненном цикле ПО заговорили в 1968 г. в Лондоне, где состоялась встреча 22-х руководителей проектов по разработке ПО.

Именно на этой встрече была предложена концепция жизненного цикла ПО

Программный продукт (software product): Набор машинных программ, процедур и, возможно, связанных с ними документации и данных.

Сопровождение программного продукта - поддержка работоспособности программного продукта, переход на его новые версии, внесение изменений, исправление обнаруженных ошибок и т.п.

Жизненный цикл программного продукта (SLC- software life cycle) – это непрерывный процесс, который начинается с момента принятия решения о необходимости его создания и заканчивается в момент его полного изъятия из эксплуатации

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

Основными процессами (иногда называют этапами или фазами) жизненного цикла являются:

• Разработка спецификации требований (результат – описания требований к программе, которые обязательны для выполнения – описание того, что программа должна делать)

• Разработка проекта программы (результат – описание того, как программа будет работать)

• Кодирование (результат – исходный код и файлы конфигурации)

• Тестирование программы (результат - контроль соответствия программы требованиям)

• Документирование (результат – документация к программе)

Модель программного процесса — это упрощенное описание программного процесса, представленное с некоторой точки зрения.

К наиболее известным моделям относятся:

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

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

Основными принципами каскадной модели являются:

• Строго последовательное выполнение фаз:

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

Каждая фаза имеет определенные критерии входа и выхода: входные и выходные данные.

• Каждая фаза полностью документируется

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

• Основа модели – сформулированные требования (ТЗ), которые меняться не должны

• Критерий качества результата – соответствие продукта установленным требованиям.

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

Каскадная модель. Применимость

• Спиральная (циклическая) модель – процесс также разбивается на стадии, но стадии выполняются циклическим повторением.

Циклический характер разработки ПО отражен в спиральной модели ЖЦ, описанной Б. Боэмом в 1988 году

Схема работы спиральной модели выглядит следующим образом.

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

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

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

Дальнейшие циклы связаны с наращиванием прототипа до полного удовлетворения требований.

Спиральная (итерационная) модель. Преимущества и недостатки

Спиральная модель (по отношению к каскадной) имеет следующие очевидные преимущества:

• Более тщательное проектирование (несколько начальных итераций) с оценкой результатов проектирования, что позволяет выявить ошибки проектирования на более ранних стадиях.

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

• Участие заказчика в выполнении проекта с использованием прототипов программы. Заказчик видит, что и как создается, не выдвигает необоснованных требований, оценивает реальные объемы финансирования.

• Планирование и управление рисками при переходе на следующие итерации позволяет разумно планировать использование ресурсов и обосновывать финансирование работ.

• Возможность разработки сложного проекта «по частям», выделяя на первых этапах наиболее значимые требования.

Основные недостатки спиральной модели связаны с ее сложностью:

• Сложность анализа и оценки рисков при выборе вариантов.

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

• Сложность оценки точки перехода на следующий цикл

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