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

программных средств

Шаршеева К.Т.
 ISO/IEC 12207-95
• ГОСТ Р ИСО/МЭК 12270. 2000
– Процессы жизненного цикла программных средств
• Программный продукт (или ПО):
– набор компьютерных программ, процедур
– и связанной с ними документации и данных
• Жизненный цикл ПО – это непрерывный процесс,
который
– начинается с момента принятия решения о необходимости его
создания
– заканчивается в момент его полного изъятия из эксплуатации
• Стандарт определяет:
– организацию и
– структуру ЖЦ ПО
 ИСО/МЭК 12207 устанавливает общую структуру для
процессов жизненного цикла программных средств с
четкой терминологией, на которую может ссылаться
промышленность.

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

Включены те аспекты определения системы, которые необходимы

для обеспечения контекста программной продукции и услуг.
 Понятия системы и программных
средств (1)
• Применение ИСО/МЭК 12207 предполагает
понимание понятий системы.
• Система — это комбинация взаимодействующих
элементов, упорядоченная для достижения одной
или нескольких поставленных целей.
• Эти системы могут формироваться из аппаратных и
программных средств, услуг, людей, процессов
(например процесса анализа), процедур (например
инструкций оператору), оборудования и
естественных материалов (например, воды,
организмов)
 Понятия системы и программных
средств (2)
• Программные средства — это подсистемы
или системные элементы, состоящие из
компьютерных программ,
соответствующих процедур, документации
и данных, имеющих отношение к
функционированию подсистемы или
элемента.

• Понятия системы непосредственно

применимы к программным средствам.
Компьютеризированная система в организации
Жизненный цикл
и процессы
• ИСО/МЭК 12207 ориентирован на процессы,
которые применены в пределах жизненного
цикла.
• Процесс — это интегрированное множество
видов деятельности, которые преобразуют
входы (например, требования) в желаемые
результаты (например, желаемое решение).
• Деятельность (действия) — это множество
связных задач.
• Задача — это требование, рекомендация или
допустимое действие, способствующие
достижению одного или более результатов
процесса.
ИСО/МЭК 12207 группирует действия, которые могут быть
выполнены в течение жизненного цикла программной
системы, в семь групп.
Четыре из них являются группами процесса в контексте системы, а
три — группами специальных процессов программных средств.
Группы процесса в контексте системы:
- процессы соглашения;
- процессы организационного обеспечения проекта;
- процессы проекта;
- технические процессы.
Группы специальных процессов программных средств:
- процессы реализации программных средств;
- процессы поддержки программных средств;
- процессы повторного использования программных средств

Каждый из процессов жизненного цикла в пределах этих семи

групп описан в терминах его цели и желательных выходных
результатов и перечисляет деятельность и задачи, которые
должны быть выполнены для достижения этих результатов.
5.4.5 Применение
процессов в модели
жизненного цикла
• ИСО/МЭК 12207 требует, чтобы
установление модели жизненного цикла
служило основой, в которой выполнены
процессы международного стандарта
• Это также требует определения цели и
результатов для каждой стадии в
установленной модели жизненного цикла
Организационное и инженерное представления, связанные
с соответствующей моделью жизненного цикла системы
 5.4.5.2 Организационное
представление
• Организации используют действия по осуществлению
организационного представления различными
способами, чтобы удовлетворить разнообразный
бизнес и стратегии реакции на риски.
• Часто используются последовательные,
инкрементные или эволюционные подходы.
• Факторы выбора:
a) политика организации;
b) природа и сложность системы;
c) устойчивость системных требований;
d) технологические возможности;
e) потребность в различных способностях системы в
различное время;
5.4.5.2.2
Последовательный подход
• Долгий цикл разработки
• Наиболее эффективный и экономичный
подход для инженерных систем
• Устойчивость существующих систем
• Модернизация устаревших систем

Система (устойчивая)

Проект (процесс)
5.4.5.2.2.3 Риски последовательного
подхода
a) за эти годы реализации могут измениться ожидания и
требования, связанные с системой;
b) из команд могут уйти знающие работники;
c) может измениться персонал, принимающий решения
в организации;
d) может измениться персонал заказчика в организации
приобретающей стороны;
e) могут уйти из бизнеса поставщики системных
элементов и связанных услуг или измениться
технологии;
f) могут иметь место технические риски;
g) за время длительной реализации может возникнуть
техническое устаревание
 5.4.5.2.2.4 Возможности
последовательного подхода
a) подход преднамеренного поэтапного уточнения,
посредством чего прогресс в реализации системы
тщательно оценивается в каждой контрольной точке,
позволяет оценивать системные качество и риски и
подтверждать инвестиционные решения прежде, чем
осуществляется переход к следующей стадии
реализации, производства или поставки партии на
рынок;
b) все способности системы поставляются в одно и то же
время;
c) штатные решения по модификации позволяют
определить, осуществлять ли сопровождение,
существенную модификацию или вывести систему из
обслуживания;
d) старые системы могут быть синхронно выведены из
обслуживания или удалены с рынка.
5.4.5.2.3
Инкрементный подход
 5.4.5.2.3 Инкрементный подход
• Новые версии продуктов
• Контрольные точки установлены в запланированных
интервалах, чтобы ввести запланированную версию системы,
которая может быть выпущена на рынок.
• Система, реализованная как результат стадии замысла, может
оказаться первой версией. Вполне обычно, когда полные
способности последней версии, которая будет представлена на
рынке, могут быть известны в начале реализации системы.

• новые, расширяемые версии способностей системы, которые

будут вводиться в короткие сроки для сохранения
конкурентоспособности на рынке.

• Системы информационных технологий, такие как бизнес-

системы
 Риски инкрементных систем
a) у начальных версий системы может быть такое ограниченное
множество способностей, что заказчики могут быть не
удовлетворены и не заинтересоваться закупкой следующей
версии;
b) версии, проданные со слишком коротким интервалом, могут
привести к неудовлетворенности заказчика с учетом затрат на
модернизацию или переобучение;
c) затраты для обучения (время и деньги), чтобы перейти от
одной версии к следующей, могут оказаться недопустимо
большими;
d) ожидания могут оказаться неоправдаными, если заказчики
желают полного множества способностей сразу в первой
версии;
e) могут быть получены неадекватные результаты, если
требования также непоняты, как и первоначальные задумки;
f) незапланированные технологические изменения или
конкурентные способности системы могут потребовать
перенаправления реализации и оказать существенное
воздействие на затраты и сроки для последующих версий;
g) заказчик может изменить требования при реализации.
Возможности инкрементных систем
a) требования приобретающей стороны могут
быть удовлетворены для ранних
способностей;
b) у разработанных прототипов для каждой
ранней контрольный точки может быть место
на рынке;
с) в условиях конкуренции раннее выведение
системы, даже с ограниченными
способностями, может позволить
эксплуатацию на рынке.
5.4.5.2.4
Эволюционный подход
• Эволюционный подход также применим к
организациям, которые регулярно или в
запланированных интервалах поставляют
на рынок новые версии продукции.
• Главное различие этого подхода с
инкрементным подходом то, что, когда
предпринимается эволюционная
реализация, полное множество
способностей последней версии системы
неизвестно
 Риски эволюционного подхода
a) может оказаться предпочтительным одновременная
готовность полного множества способностей;
b) затраты на обучение могут оказаться недопустимыми
для продвижения следующей версии;
c) может иметь место неопределенность, связанная с
определением будущих требований;
d) может иметь место неопределенность относительно
планирования сроков выпуска следующей версии;
e) управление конфигурацией может быть
проблематичным;
f) неприемлемо раннее использование прототипа
продукта в производстве.
 Возможности эволюционного подхода
a) требования приобретающей стороны для ранних
способностей могут быть удовлетворены;
b) обратная связь с заказчиком может быть
использована для увеличения способностей
будущей версии системы;
c) прототипы, разработанные для удовлетворения
ранних контрольных точек, могут найти
использование на рынке;
d) раннее выведение ограниченной системы
способностей может позволить противостояние
угрозам со стороны конкурентов;
e) использование преимуществ появляющихся
технологий.