Гост р исо мэк 12207 2010 кратко

Обновлено: 02.07.2024

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

IEEE — читается "ай-трипл-и", Institute of Electrical and Electronic Engineers , Институт инженеров по электротехнике и электронике;
ISO — International Standards Organization, Международная организация по стандартизации;
EIA — Electronic Industry Association, Ассоциация электронной промышленности;
IEC — International Electrotechnical Commission , Международная комиссия по электротехнике;

а также некоторыми национальными и региональными институтами и организациями (в основном, американскими и европейскими, поскольку именно они оказывают наибольшее влияние на развитие технологий разработки ПО во всем мире):

ANSI — American National Standards Institute, Американский национальный институт стандартов;
SEI — Software Engineering Institute, Институт программной инженерии;
ECMA — European Computer Manufactures Association, Европейская ассоциация производителей компьютерного оборудования;

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

Группа стандартов ISO

ISO/IEC 12207 Standard for Information Technology — Software Life Cycle Processes[1] ( процессы жизненного цикла ПО , есть его российский аналог ГОСТ Р-1999[3]).

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

Самыми крупными элементами являются процессы жизненного цикла ПО (lifecycle processes) . Всего выделено 18 процессов, которые объединены в 4 группы.

Передача ПО (в использование);

Поддержка ПО Документирование;

Адаптация описываемых стандартом процессов под нужды конкретного проекта

Процессы строятся из отдельных видов деятельности (activities) .

Стандартом определены 74 вида деятельности , связанной с разработкой и поддержкой ПО. Ниже мы упомянем только некоторые из них.

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

Каждый вид деятельности нацелен на решение одной или нескольких задач (tasks). Всего определено 224 различные задачи. Например:

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

Отличается от предыдущего нацеленностью на рассмотрение программно-аппаратных систем в целом.

В данный момент продолжается работа по приведению этого стандарта в соответствие с предыдущим.

ISO/IEC 15288 предлагает похожую схему рассмотрения жизненного цикла системы в виде набора процессов. Каждый процесс описывается набором его результатов (outcomes), которые достигаются при помощи различных видов деятельности .

Всего выделено 26 процессов, объединяемых в 5 групп.

Передача в использование;

Изъятие из эксплуатации

Адаптация описываемых стандартом процессов под нужды конкретного проекта

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

Должны быть поставлены технические задачи, которые предстоит решить.
Должны быть сформулированы системные требования.

Деятельности в рамках этого процесса следующие.

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

Определяет правила оценки процессов жизненного цикла ПО и их возможностей, опирается на модель CMMI (см. ниже) и больше ориентирован на оценку процессов и возможностей их улучшения.

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

Определяются 5 категорий, включающих 35 процессов и 201 вид деятельности :

Определение нужд заказчика;

Проведение совместных экспертиз и аудитов;

Подготовка к передаче;

Поставка и развертывание;

Оценка удовлетворенности заказчиков

Обеспечение среды для работы

Планирование жизненного цикла;

Управление ресурсами и графиком работ;

Выделение системных требований и проектирование системы в целом;

Выделение требований к ПО;

Реализация, интеграция и тестирование ПО;

Интеграция и тестирование системы;

Сопровождение системы и ПО

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

Группа стандартов IEEE

IEEE 1074-1997 — IEEE Standard for Developing Software Life Cycle Processes[8] (стандарт на создание процессов жизненного цикла ПО).

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

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

Аналог ISO/IEC 12207, сменил ранее использовавшиеся стандарты J-Std-016-1995 EIA /IEEE Interim Standard for Information Technology — Software Life Cycle Processes — Software Development Acquirer - Supplier Agreement (промежуточный стандарт на процессы жизненного цикла ПО и соглашения между поставщиком и заказчиком ПО) и стандарт министерства обороны США MIL-STD -498.

ГОСТ Р ИСО/МЭК 12207-2010

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Системная и программная инженерия

ПРОЦЕССЫ ЖИЗНЕННОГО ЦИКЛА ПРОГРАММНЫХ СРЕДСТВ

Information technology. System and software engineering. Software life cycle processes

Дата введения 2012-03-01

Цели и принципы стандартизации в Российской Федерации установлены Федеральным законом от 27 декабря 2002 г. N 184-ФЗ "О техническом регулировании", а правила применения национальных стандартов Российской Федерации - ГОСТ Р 1.0-2004 "Стандартизация в Российской Федерации. Основные положения"

Сведения о стандарте

1 ПОДГОТОВЛЕН Федеральным государственным унитарным предприятием "Научно-исследовательский институт "Восход" на основе собственного аутентичного перевода на русский язык стандарта, указанного в пункте 4

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 22 "Информационные технологии"

4 Настоящий стандарт идентичен международному стандарту ИСО/МЭК 12207-2008* "Системная и программная инженерия. Процессы жизненного цикла программных средств" (ISO/IEC 12207:2008 "System and software engineering - Software life cycle processes"), разработанному подкомитетом ПК 7 "Системная и программная инженерия" (SC 7 System and Software Engineering) Совместного технического комитета N 1 ИСО/МЭК - СТК 1 "Информационные технологии" (ISO/IEC JTC 1 Information Technology)

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

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

1 Общие положения

1.1 Область применения

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

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

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

Процессы, виды деятельности и задачи настоящего стандарта - самостоятельно либо совместно с ИСО/МЭК 15288 - могут также использоваться во время приобретения системы, содержащей программные средства.

1.2 Назначение

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

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

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

1.3 Ограничения

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

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

Примечание - В [19] установлены требования к информационному содержанию разделов документации, описывающей процессы жизненного цикла.

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

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

2 Соответствие

2.1 Предполагаемое соответствие

Требования изложены в разделах 6, 7 и в приложении А настоящего стандарта. Настоящий стандарт устанавливает требования для ряда процессов, приемлемых для использования в течение всего жизненного цикла программного продукта или услуги. Допускается, что в отдельных проектах или в некоторых организациях может не возникнуть потребность применять все процессы, приведенные в настоящем стандарте. В этом случае применение настоящего стандарта обычно сводится к выбору ряда процессов, подходящих для организации или проекта. Существует два способа такого выбора, выполнение которых может потребовать соответствия с положениями настоящего стандарта. Любое заявление о соответствии должно быть оформлено только в одной из двух приведенных ниже форм.

2.2 Полное соответствие

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

2.3 Адаптированное соответствие

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

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

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

Примечание 3 - Требования настоящего стандарта отражаются использованием глагола "должен", рекомендации - глаголом "следует", а разрешения - глаголом "может".

3 Нормативные ссылки

Нормативные ссылки в настоящем стандарте не использованы.

4 Термины и определения

В настоящем стандарте применены следующие термины с соответствующими определениями.

4.1 приобретающая сторона (acquirer): Правообладатель, который приобретает или получает продукт или услугу от поставщика

Примечание - Приобретающей стороной может быть: покупатель, заказчик, владелец, оптовый покупатель.

4.2 приобретение (acquisition): Процесс получения системы, программного продукта или программной услуги

4.3 деятельность (activity): Совокупность согласованных задач процесса

4.4 соглашение (agreement): Взаимное признание сроков и условий, в соответствии с которыми осуществляются рабочие отношения

4.5 аудит (audit): Независимая оценка программных продуктов и процессов, проводимая уполномоченным лицом с целью оценить их соответствие требованиям

4.6 базовая линия (baseline): Спецификация или продукт, которые были официально рассмотрены и согласованы с тем, чтобы впоследствии служить основой для дальнейшего развития, и которые могут быть изменены только посредством официальных и контролируемых процедур изменения

4.7 составная часть конфигурации (configuration item): Объект в пределах конфигурации, который удовлетворяет некоторой функции целевого применения и может быть однозначно идентифицирован в данный момент времени

4.8 контракт (contract): Обязательное соглашение между двумя сторонами, главным образом опирающиеся на юридические нормы, или подобное внутреннее соглашение в рамках организации

4.9 заказчик (customer): Организация или лицо, получающие продукт или услугу

Примечание 1 - Заказчик может быть внутренним или внешним по отношению к организации.

Примечание 2 - Адаптировано из ИСО 9000:2005.

Примечание 3 - Другие термины, используемые для термина "заказчик": "приобретающая сторона", "розничный покупатель", "оптовый покупатель".

4.10 разработчик (developer): Организация, которая выполняет разработку задач (в том числе анализ требований, проектирование, приемочные испытания) в процессе жизненного цикла

Примечание - В настоящем стандарте термины "разработчик" и "исполнитель" являются синонимами.

4.11 обеспечивающая система (enabling system): Система, которая служит дополнением к рассматриваемой системе на протяжении стадий ее жизненного цикла, но не обязательно вносит непосредственный вклад в ее функционирование

Примечание 1 - Например, если рассматриваемая система вступает в стадию производства, то требуется обеспечивающая производственная система.

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

4.12 оценивание (evaluation): Систематическое определение степени, с которой некоторый объект удовлетворяет установленным критериям

4.13 основные средства (facility): Физические устройства или оборудование, способствующие выполнению действий, например, здания, инструменты, принадлежности

4.14 фирменное средство (firmware): Сочетание технического средства и компьютерных команд или данных, встроенных в это техническое средство в качестве предназначенного только для чтения программного средства

Примечание - Фирменное программное средство не может быть легко модифицировано под управлением какой-либо программы.

4.15 исполнитель (implementer): Организация, которая выполняет реализацию задач

Примечание - В настоящем стандарте, термины "разработчик" и "исполнитель" являются синонимами.

4.16 жизненный цикл (life cycle): Развитие системы, продукта, услуги, проекта или других изготовленных человеком объектов, начиная со стадии разработки концепции и заканчивая прекращением применения

4.17 модель жизненного цикла (life cycle model): Структура процессов и действий, связанных с жизненным циклом, организуемых в стадии, которые также служат в качестве общей ссылки для установления связей и взаимопонимания сторон

4.18 сопровождающая сторона (maintainer): Организация, которая осуществляет деятельность по сопровождению

4.19 мониторинг (monitoring): Текущий контроль состояния деятельности поставщика и результатов этой деятельности, проводимый приобретающей или третьей стороной

4.20 непоставляемая составная часть (non-deliverable item): Техническое средство или программный продукт, который не требуется поставлять по условиям контракта, но который может использоваться в разработке программного продукта

4.21 готовый (off-the-shelf): Уже разработанный и имеющийся в наличии

4.22 оператор (operator): Какой-либо объект, осуществляющий работу системы

В настоящем стандарте существует два важных подразделения процесса. В разделе 6 представлен системный контекст для работы с автономным программным продуктом или услугой, или программной системой. Раздел 7 содержит специальные процессы программных средств для использования в реализации программного продукта или услуги, которые являются некоторым элементом более крупной системы.

Для помощи в одновременном использовании [18] и настоящего стандарта соответствующие процессы раздела 6 имеют одинаковые обозначения подразделов.

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

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

Таким образом, процессы соглашения, приведенные в настоящем стандарте, ориентированы на программные средства процессами соглашения из [18].

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

Процессы организационного обеспечения проекта включают в себя:

a) процесс менеджмента модели жизненного цикла;

b) процесс менеджмента инфраструктуры;

c) процесс менеджмента портфеля проектов;

d) процесс менеджмента людских ресурсов;

e) процесс менеджмента качества.

В общем случае процессы организационного обеспечения проекта, предусмотренные настоящим стандартом, являются процессами, ориентированными на программные средства из соответствующей совокупности процессов в [18].

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

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

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

а) процесс планирования проекта;

b) процесс управления и оценки проекта.

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

a) процесс менеджмента решений;

b) процесс менеджмента рисков;

c) процесс менеджмента конфигурации;

d) процесс менеджмента информации;

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

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

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

Технические процессы состоят из следующих процессов:

a) определение требований правообладателей (специальный случай процесса определения требований правообладателей, приведенного в [18]);

b) анализ системных требований (специальный случай процесса анализа требований);

c) проектирование архитектуры системы (специальный случай процесса проектирования архитектуры, приведенного в [18]);

d) процесс реализации (специальный случай процесса реализации элементов системы, приведенного в [18] и далее разработанного в разделе 7 настоящего стандарта как процесса реализации программных средств);

e) процесс комплексирования системы (специальный случай процесса комплексирования, приведенного в [18]);

f) процесс квалификационного тестирования системы (процесс, который способствует достижению результатов процесса верификации, приведенного в [18]);

g) процесс инсталляции программных средств (процесс, который способствует достижению результатов процесса передачи, приведенного в [18]);

h) процесс поддержки приемки программных средств (процесс, который способствует достижению результатов процесса передачи, приведенного в [18]);

i) процесс функционирования программных средств (специальный случай процесса функционирования, приведенного в [18]);

j) процесс сопровождения программных средств (специальный случай процесса сопровождения, приведенного в [18]);

k) процесс изъятия из обращения программных средств (специальный случай процесса изъятия и списания, приведенного в [18]).

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

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

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

Процесс реализации программных средств включает в себя несколько специальных процессов более низкого уровня:

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

b) процесс проектирования архитектуры программных средств;

c) процесс детального проектирования программных средств;

d) процесс конструирования программных средств;

e) процесс комплексирования программных средств;

f) процесс квалификационного тестирования программных средств.

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

a) процесс менеджмента документации программных средств;

b) процесс менеджмента конфигурации программных средств;

c) процесс обеспечения гарантии качества программных средств;

d) процесс верификации программных средств;

e) процесс валидации программных средств;

f) процесс ревизии программных средств;

g) процесс аудита программных средств;

h) процесс решения проблем в программных средствах.

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

Стандарт определяет жизненный цикл программных систем как структуру декомпозиции работ. Детализация, техники и метрики проведения работ – вопрос программной инженерии. Организация последовательности работ – модель жизненного цикла. Совокупность моделей, процессов, техник и организации проектной группы задаются методологией. В частности, выбор и применение метрик оценки качества программной системы и процессов находятся за рамками стандарта 12207, а концепция совершенствования процессов рассматривается в стандарте ISO/IEC 15504.

Структура стандарта

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

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

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

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

Процесс адаптации

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

Читайте также: