32. Жизненный цикл программного обеспечения. Фазы жц, их характеристики артефакты.

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

1. процесс приобретения ПО, средств разработки и общесистемного ПО;

2. процесс поставки (инициирование поставки, подготовка договора, планирование, выполнение и контроль, проверка и оценка);

3. процесс разработки (подготовительные работы, анализ требований, проектирование архитектуры системы, кодирование и тестирование, интеграция, установка и приемка);

4. процесс эксплуатации (обучение персонала, эксплуатационное тестирование, эксплуатация, поддержка пользователей);

5. процесс сопровождения (анализ проблем и запросов на модификацию ПО, модификация ПО, проверка и приемка, перенос ПО в другую среду, снятие ПО с эксплуатации);

Выделяют еще вспомогательные процессы, такие как:

• документирование процессов проектирования и разработки;

• обеспечения качества продукта (системы) и процесса (работ);

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

• аудит (определение соответствия требованиям, планами условиям договора);

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

33. Модели жизненного цикла разработки программного обеспечения. Сравнение моделей.

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

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

Первой, по времени появления являлась каскадная модель.

Этапы: Формирование требований к ПО → Проектирование → Реализация → Тестирование → Ввод в действие → Эксплуатация и сопровождение.

Модель предполагает следующие свойства взаимодействия этапов:

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

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

• этапы не перекрываются во времени, т.е. следующий этап не начинается, пока не завершится предыдущий,

• возврат к предыдущим этапам не предусматривается,

• результат появляется только в конце разработки.

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

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

(–): 1). Реальный процесс создания ПО никогда полностью не укладывается в такую жесткую схему. 2). Заказчик не в состоянии сразу изложить все свои требования и не могут предвидеть, как они изменятся в ходе разработки. 3). За время разработки могут произойти изменения во внешней среде, которые повлияют на требования к системе.

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

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

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

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