7. Жизненный цикл программных средств. Модели жизненного цикла пс

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

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

Наиболее известными являются:

• каскадная модель,

• эволюционная модель,

• модель формальной разработки,

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

• итерационные модели.

Первые две модели широко используются на практике.

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

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

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

При детальном проектировании подробно описываются компоненты ПС и их взаимосвязи.

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

Далее отдельные программы интегрируются и тестируются в виде целостной системы.

Затем ПС сопровождается документами и передается в эксплуатацию.

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

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

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

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

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

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

Эволюционная модель приемлема для разработки небольших ПС (до 100 000 строк кода) и программ среднего размера (до 500 000 строк) с относительно коротким сроком жизни.

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

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

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

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

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

В этом подходе этапы специфицирования и аттестации такие же, как и в других моделях. Этапы, расположенные между ними, имеют следующий смысл:

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

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

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

• разработка и сборка системы(в рамках рассматриваемого подхода сборка системы является скорее частью разработки, чем отдельным этапом).

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

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