1.1. Основные процессы жизненного цикла

Приобретение- процесс приобретения определяет работы и задачи заказчика, приобретающего программное обеспечение или услуги, связанные с ПО, на основе контрактных отношений. Процесс приобретения состоит из следующих работ (названия ГОСТ 12207 даны в скобках, если предлагают другой перевод названий работ оригинального стандарта): • Inititation – инициирование (подготовка) • Request-for-proposal preparation – подготовка запроса на предложение (подготовка заявки на подряд) • Contract preparation and update –подготовка и корректировка договора • Supplier monitoring – мониторинг поставщика (надзор за поставщиком) • Acceptance and completion – приемка и завершение (приемка и закрытие договора) Все работы проводятся в рамках проектного подхода.

Поставка- процесс поставки, в свою очередь, определяет работы и задачи поставщика. Работы также проводятся с использованием проектного подхода. Процесс включает следующие работы: • Inititation – инициирование (подготовка) • Preparation of response – подготовка предложения (подготовка ответа) • Contract – разработка контракта (подготовка договора) • Planning - планирование • Execution and control – выполнение и контроль • Review and evaluation –проверка и оценка • Delivery and completion – поставка и завершение (поставка и закрытие договора).

Разработка - процесс разработки определяет работы и задачи разработчика. Процесс состоит из следующих работ: • Process implementation – определение процесса (подготовка процесса) • System requirements analysis – анализ системных требований (анализ требований к системе) • System design – проектирование системы (проектирование системной архитектуры) • Software requirements analysis – анализ программных требований (анализ требований к программным средствам).

Эксплуатация- процесс разработки определяет работы и задачи оператора службы поддержки. Процесс включает следующие работы: • Process implementation – определение процесса (подготовка процесса) • Operational testing – операционное тестирование (эксплуатационные испытания) • System operation – эксплуатация системы • User support – поддержка пользователя.

Сопровождение- процесс разработки определяет работы и задачи, проводимые специалистами службы сопровождения. Процесс включает следующие работы: • Process implementation – определение процесса (подготовка процесса) • Problem and modification analysis – анализ проблем и изменений • Modification implementation – внесение изменений • Maintenance review/acceptance – проверка и приемка при сопровождении • Migration – миграция (перенос) • Software retirement – вывод программной системы из эксплуатации (снятие с эксплуатации).

2. Модели жизненного цикла программного обеспечения

Наиболее часто говорят о следующих моделях жизненного цикла: • Каскадная (водопадная) или последовательная • Итеративная и инкрементальная – эволюционная (гибридная, смешанная) • Спиральная (spiral) или модель Боэма Легко обнаружить, что в разное время и в разных источниках приводится разный список моделей и их интерпретация. Например, ранее, инкрементальная модель понималась как построение системы в виде последовательности сборок (релизов), определенной в соответствии с заранее подготовленным планом и заданными (уже сформулированными) и неизменными требованиями. Сегодня об инкрементальном подходе чаще всего говорят в контексте постепенного наращивания функциональности создаваемого продукта. Может показаться, что индустрия пришла, наконец, к общей “правильной” модели. Однако, каскадная модель, многократно “убитая” и теорией и практикой, продолжает встречаться в реальной жизни. Спиральная модель является ярким представителем эволюционного взгляда, но, в то же время, представляет собой единственную модель, которая уделяет явное внимание анализу и предупреждению рисков. Поэтому представленные три модели ПО – каскадную, эволюционную и спиральную.

Каскадная (водопадная) модель- данная модель предполагает строго последовательное (во времени) и однократное выполнение всех фаз проекта с жестким (детальным) предварительным планированием в контексте предопределенных или однажды и целиком определенных требований к программной системе.

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

«http://inftis.narod.ru/ais/ais-n5.htm»

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

Итеративная и инкрементальная модель эволюционный подход. Итеративная модель предполагает разбиение жизненного цикла проекта на последовательность итераций, каждая из которых напоминает “мини-проект”, включая все фазы жизненного цикла в применении к созданию меньших фрагментов функциональности, по сравнению с проектом, в целом. Цель каждой итерации – получение работающей версии программной системы, включающей функциональность, определенную интегрированным содержанием всех предыдущих и текущей итерации. Результата финальной итерации содержит всю требуемую функциональность продукта. Таким образом, с завершением каждой итерации, продукт развивается инкрементально. С точки зрения структуры жизненного цикла такую модель называют итеративной (iterative). С точки зрения развития продукта – инкрементальной (incremental). Опыт индустрии показывает, что невозможно рассматривать каждый из этих взглядов изолировано. Чаще всего такую смешанную эволюционную модель называют просто итеративной (говоря о процессе) и/или инкрементальной (говоря о наращивании функциональности продукта). Эволюционная модель подразумевает не только сборку работающей (с точки зрения результатов тестирования) версии системы, но и её развертывание в реальных операционных условиях с анализом откликов пользователей для определения содержания и планирования следующей итерации. “Чистая” инкрементальная модель не предполагает развертывания промежуточных сборок (релизов) системы и все итерации проводятся по заранее определенному плану наращивания функциональности, а пользователи (заказчик) получает только результат финальной итерации как полную версию системы. С другой стороны, Скотт Амблер например, определяет эволюционную модель как сочетание итеративного и инкрементального подходов. В свою очередь, Мартин Фаулер пишет: “Итеративную разработку называют по- разному: инкрементальной, спиральной, эволюционной и постепенной. Разные люди вкладывают в эти термины разный смысл, но эти различия не имеют широкого признания и не так важны, как противостояние итеративного метода и метода водопада.”

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

«http://inftis.narod.ru/ais/ais-n5.htm»

Спиральная модель-спиральная модель была впервые сформулирована Барри Боэмом (Barry Boehm) в 1988 году [Boehm, 1988]Отличительной особенностью этой модели является специальное внимание рискам, влияющим на организацию жизненного цикла.: 1. Дефицит специалистов. 2. Нереалистичные сроки и бюджет. 3. Реализация несоответствующей функциональности. 4. Разработка неправильного пользовательского интерфейса. 5. “Золотая сервировка”, перфекционизм, ненужная оптимизация и оттачивание деталей. 6. Непрекращающийся поток изменений. 7. Нехватка информации о внешних компонентах, определяющих окружение системы или вовлеченных в интеграцию. 8. Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами. 9. Недостаточная производительность получаемой системы. 10. “Разрыв” в квалификации специалистов разных областей знаний. Большая часть этих рисков связана с организационными и процессными аспектами взаимодействия специалистов в проектной команде.

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

«http://inftis.narod.ru/ais/ais-n5.htm»