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

Жизненный цикл программного обеспечения (ПО) — период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации^[1]. Этот цикл — процесс построения и развития ПО.

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

• ГОСТ 34.601-90
• ISO/IEC 12207:1995 (российский аналог — ГОСТ Р ИСО/МЭК 12207-99)

Стандарт ГОСТ 34.601-90

Стандарт ГОСТ 34.601-90 предусматривает следующие стадии и этапы создания автоматизированной системы:

1. Формирование требований к АС
   1. Обследование объекта и обоснование необходимости создания АС
   2. Формирование требований пользователя к АС
   3. Оформление отчета о выполнении работ и заявки на разработку АС
2. Разработка концепции АС
   1. Изучение объекта
   2. Проведение необходимых научно-исследовательских работ
   3. Разработка вариантов концепции АС и выбор варианта концепции АС, удовлетворяющего требованиям пользователей
   4. Оформление отчета о проделанной работе
3. Техническое задание
   1. Разработка и утверждение технического задания на создание АС
4. Эскизный проект
   1. Разработка предварительных проектных решений по системе и ее частям
   2. Разработка документации на АС и ее части
5. Технический проект
   1. Разработка проектных решений по системе и ее частям
   2. Разработка документации на АС и ее части
   3. Разработка и оформление документации на поставку комплектующих изделий
   4. Разработка заданий на проектирование в смежных частях проекта
6. Рабочая документация
   1. Разработка рабочей документации на АС и ее части
   2. Разработка и адаптация программ
7. Ввод в действие
   1. Подготовка объекта автоматизации
   2. Подготовка персонала
   3. Комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями)
   4. Строительно-монтажные работы
   5. Пусконаладочные работы
   6. Проведение предварительных испытаний
   7. Проведение опытной эксплуатации
   8. Проведение приемочных испытаний
8. Сопровождение АС.
   1. Выполнение работ в соответствии с гарантийными обязательствами
   2. Послегарантийное обслуживание

Эскизный, технический проекты и рабочая документация — это последовательное построение все более точных проектных решений. Допускается исключать стадию «Эскизный проект» и отдельные этапы работ на всех стадиях, объединять стадии «Технический проект» и «Рабочая документация» в «Технорабочий проект», параллельно выполнять различные этапы и работы, включать дополнительные.

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

Стандарт ГОСТ Р ИСО/МЭК 12207 (ISO/IEC 12207)

Федеральным агентством по техническому регулированию и метрологии РФ 01.03.2012 г. взамен ГОСТ Р ИСО/МЭК 12207-99 принят стандарт ГОСТ Р ИСО/МЭК 12207-2010 «Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств», идентичный международному стандарту ISO/IEC 12207:2008 «System and software engineering — Software life cycle processes».

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

Процессы жизненного цикла ПО

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

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

Каждый процесс включает ряд действий. Например, процесс приобретения охватывает следующие действия:

1. Инициирование приобретения
2. Подготовка заявочных предложений
3. Подготовка и корректировка договора
4. Надзор за деятельностью поставщика
5. Приемка и завершение работ

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

1. Формирование требований к системе
2. Формирование списка программных продуктов
3. Установление условий и соглашений
4. Описание технических ограничений (среда функционирования системы и т. д.)

Стадии жизненного цикла ПО, взаимосвязь между процессами и стадиями

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

Стандарт ГОСТ Р ИСО/МЭК 12207-99 не предлагает конкретную модель жизненного цикла. Его положения являются общими для любых моделей жизненного цикла, методов и технологий создания ИС. Он описывает структуру процессов жизненного цикла, не конкретизируя, как реализовать или выполнить действия и задачи, включенные в эти процессы.

Модель ЖЦ ПО включает в себя:

1. Стадии;
2. Результаты выполнения работ на каждой стадии;
3. Ключевые события — точки завершения работ и принятия решений.

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

На каждой стадии могут выполняться несколько процессов, определенных в стандарте ГОСТ Р ИСО/МЭК 12207-99, и наоборот, один и тот же процесс может выполняться на различных стадиях. Соотношение между процессами и стадиями также определяется используемой моделью жизненного цикла ПО.

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

Водопадная (каскадная, последовательная) модель

Основная статья: Модель водопада

Водопадная модель жизненного цикла (англ. waterfall model) была предложена в 1970 г. Уинстоном Ройсом. Она предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем этапе. Требования, определенные на стадии формирования требований, строго документируются в виде технического задания и фиксируются на все время разработки проекта. Каждая стадия завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков.

Этапы проекта в соответствии с каскадной моделью:

1. Формирование требований;
2. Проектирование;
3. Реализация;
4. Тестирование;
5. Внедрение;
6. Эксплуатация и сопровождение.

Преимущества:

• Полная и согласованная документация на каждом этапе;
• Легко определить сроки и затраты на проект.

Недостатки:

В водопадной модели переход от одной фазы проекта к другой предполагает полную корректность результата (выхода) предыдущей фазы. Однако неточность какого-либо требования или некорректная его интерпретация в результате приводит к тому, что приходится «откатываться» к ранней фазе проекта и требуемая переработка не просто выбивает проектную команду из графика, но приводит часто к качественному росту затрат и, не исключено, к прекращению проекта в той форме, в которой он изначально задумывался. По мнению современных специалистов, основное заблуждение авторов водопадной модели состоит в предположениях, что проект проходит через весь процесс один раз, спроектированная архитектура хороша и проста в использовании, проект осуществления разумен, а ошибки в реализации легко устраняются по мере тестирования. Эта модель исходит из того, что все ошибки будут сосредоточены в реализации, а потому их устранение происходит равномерно во время тестирования компонентов и системы^[2]. Таким образом, водопадная модель для крупных проектов мало реалистична и может быть эффективно использована только для создания небольших систем^[3].

Итерационная модель

Альтернативой последовательной модели является так называемая модель итеративной и инкрементальной разработки (англ. iterative and incremental development, IID), получившей также от Т. Гилба в 70-е гг. название эволюционной модели. Также эту модель называют итеративной моделью и инкрементальной моделью^[4].

Модель IID предполагает разбиение жизненного цикла проекта на последовательность итераций, каждая из которых напоминает «мини-проект», включая все процессы разработки в применении к созданию меньших фрагментов функциональности, по сравнению с проектом в целом. Цель каждой итерации — получение работающей версии программной системы, включающей функциональность, определённую интегрированным содержанием всех предыдущих и текущей итерации. Результат финальной итерации содержит всю требуемую функциональность продукта. Таким образом, с завершением каждой итерации продукт получает приращение — инкремент — к его возможностям, которые, следовательно, развиваются эволюционно. Итеративность, инкрементальность и эволюционность в данном случае есть выражение одного и то же смысла разными словами со слегка разных точек зрения^[3].

По выражению Т. Гилба, «эволюция — прием, предназначенный для создания видимости стабильности. Шансы успешного создания сложной системы будут максимальными, если она реализуется в серии небольших шагов и если каждый шаг заключает в себе четко определённый успех, а также возможность «отката» к предыдущему успешному этапу в случае неудачи. Перед тем, как пустить в дело все ресурсы, предназначенные для создания системы, разработчик имеет возможность получать из реального мира сигналы обратной связи и исправлять возможные ошибки в проекте»^[4].

Подход IID имеет и свои отрицательные стороны, которые, по сути, — обратная сторона достоинств. Во-первых, целостное понимание возможностей и ограничений проекта очень долгое время отсутствует. Во-вторых, при итерациях приходится отбрасывать часть сделанной ранее работы. В-третьих, добросовестность специалистов при выполнении работ всё же снижается, что психологически объяснимо, ведь над ними постоянно довлеет ощущение, что «всё равно всё можно будет переделать и улучшить позже»^[3].

Различные варианты итерационного подхода реализованы в большинстве современных методологий разработки (RUP, MSF, XP).

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

Спиральная модель (англ. spiral model) была разработана в середине 1980-х годов Барри Боэмом. Она основана на классическом цикле Деминга PDCA (plan-do-check-act). При использовании этой модели ПО создается в несколько итераций (витков спирали) методом прототипирования.

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

На каждой итерации оцениваются:

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

Важно понимать, что спиральная модель является не альтернативой эволюционной модели (модели IID), а специально проработанным вариантом. К сожалению, нередко спиральную модель либо ошибочно используют как синоним эволюционной модели вообще, либо (не менее ошибочно) упоминают как совершенно самостоятельную модель наряду с IID^[3].

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

1. Дефицит специалистов.
2. Нереалистичные сроки и бюджет.
3. Реализация несоответствующей функциональности.
4. Разработка неправильного пользовательского интерфейса.
5. Перфекционизм, ненужная оптимизация и оттачивание деталей.
6. Непрекращающийся поток изменений.
7. Нехватка информации о внешних компонентах, определяющих окружение системы или вовлеченных в интеграцию.
8. Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.
9. Недостаточная производительность получаемой системы.
10. Разрыв в квалификации специалистов разных областей.

В сегодняшней спиральной модели определён следующий общий набор контрольных точек^[5]:

1. Concept of Operations (COO) — концепция (использования) системы;
2. Life Cycle Objectives (LCO) — цели и содержание жизненного цикла;
3. Life Cycle Architecture (LCA) — архитектура жизненного цикла; здесь же возможно говорить о готовности концептуальной архитектуры целевой программной системы;
4. Initial Operational Capability (IOC) — первая версия создаваемого продукта, пригодная для опытной эксплуатации;
5. Final Operational Capability (FOC) –— готовый продукт, развернутый (установленный и настроенный) для реальной эксплуатации.

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

Этот раздел не завершён. Вы поможете проекту, исправив и дополнив его.

• Rational Unified Process (RUP).
• Microsoft Solutions Framework (MSF). Включает 4 фазы: анализ, проектирование, разработка, стабилизация, предполагает использование объектно-ориентированного моделирования.
• Экстремальное программирование (англ. Extreme Programming, XP). В основе методологии командная работа, эффективная коммуникация между заказчиком и исполнителем в течение всего проекта по разработке ИС. Разработка ведется с использованием последовательно дорабатываемых прототипов.
• ЕСПД — комплекс государственных стандартов Российской Федерации, устанавливающих взаимосвязанные правила разработки, оформления и обращения программ и программной документации.

Литература

• Братищенко В.В. Проектирование информационных систем. — Иркутск: Изд-во БГУЭП, 2004. — 84 с.
• Вендров А.М. Проектирование программного обеспечения экономических информационных систем. — М.: Финансы и статистика, 2000.
• Грекул В.И., Денищенко Г.Н., Коровкина Н.Л. Проектирование информационных систем. — М.: Интернет-университет информационных технологий - ИНТУИТ.ру, 2005.
• Мишенин А.И. Теория экономических информационных систем. — М.: Финансы и статистика, 2000. — 240 с.
• Орлик С., «Модели жизненного цикла»

Примечания

1. ↑ Стандарт IEEE Std 610.12, Глоссарий
2. ↑ Брукс Ф. Мифический человеко-месяц или как создаются программные системы : пер. с англ. / Ф. Брукс. — Санкт-Петербург : Символ-Плюс, 1999. — 304 с.: ил.
3. ↑ ^{1 2 3 4} Мирошниченко Е. А. Технологии программирования: учебное пособие / Е. А. Мирошниченко. — 2-е изд., испр. и доп. — Томск: Изд-во Томского политехнического университета, 2008. — 128 с.
4. ↑ ^{1 2} Ларман К. Итеративная и инкрементальная разработка: краткая история / К. Ларман, В. Базили // Открытые системы. — 2003.— N 9.
5. ↑ Орлик С. Введение в программную инженерию и управление жизненным циклом ПО. [1]