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

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

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

В настоящее время можно выделить пять основных подходов к организации процесса создания и использования ПС.

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

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

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

Формальные преобразования. Этот подход включает разработку формальных спецификаций ПС и превращение их в программы путем корректных преобразований. На этом подходе базируется САSЕ-технология разработки ПС.

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

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

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

Наиболее часто говорят о следующих моделях жизненного цикла:

· Каскадная (водопадная) или последовательная

· Итеративная и инкрементальная – эволюционная (гибридная, смешанная)

· Спиральная (spiral) модель.

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

Преимущества каскадной модели

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

• она позволяет главе проекта строго его контролировать;

• при правильном использовании модели, дефекты и ошибки можно обнаружить на более ранних этапах, когда их устранение еще не требует относительно больших затрат;

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

Недостатки каскадной модели

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

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

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

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

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

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

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

Эволюционная модель

Чаще всего объединяют обе модели. Такую смешанную эволюционную модель называют просто итеративной (говоря о процессе) и/или инкрементальной (говоря о наращивании функциональности продукта).

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

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

Рисунок 3. Снижение неопределенности и инкрементальное расширение функциональности при итеративной организация жизненного цикла.

Спиральная модель

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

Спиральная модель (представлена на рисунке 4) была впервые сформулирована Барри Боэмом (Barry Boehm) в 1988 году [Boehm, 1988]. Отличительной особенностью этой модели является специальное внимание рискам, влияющим на организацию жизненного цикла.

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

Рисунок 4. Оригинальная спиральная модель жизненного цикла разработки по Боэму

Область применения спиральной модели:

· когда создание прототипа представляет собой подходящий тип разработки продукта;

· для проектов, выполнение которых сопряжено со средней и высокой степенью риска;

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

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

· когда требования слишком сложные;

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

· в случае больших проектов;

· когда преимущества разработки невозможно точно определить, а достижение успеха не гарантировано;

Рисунок 5. Обновленная спиральная модель c контрольными точками проекта.
(данное представление создано Сергеем Орликом
на основе оригинальной модели Боэма и ее модификациях)

1.1.

Scrum

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

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

В настоящее время можно выделить пять основных подходов к организации процесса создания и использования ПС.

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

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

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

Формальные преобразования. Этот подход включает разработку формальных спецификаций ПС и превращение их в программы путем корректных преобразований. На этом подходе базируется САSЕ-технология разработки ПС.

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