Государственный стандарт РФ ГОСТ Р ИСО/МЭК ТО 15271-2002
"Информационная технология.
Руководство по применению ГОСТ Р ИСО/МЭК 12207
(Процессы жизненного цикла программных средств)"
(принят и введен в действие постановлением Госстандарта РФ
от 5 июня 2002 г. N 227-ст)
Information technology.
Guide for the application of GOST R ISO/IEC 12207
(Software life cycle processes)
Дата введения 1 июля 2003 г.
Введен впервые
Введение
В настоящем стандарте приведены рекомендации по практическому
применению ГОСТ Р ИСО/МЭК 12207 в условиях реализации конкретных проектов
создания программных средств. Опытное применение ГОСТ Р ИСО/МЭК 12207 в
ряде организаций подтвердило необходимость выработки таких рекомендаций
для однозначного понимания требований и норм, установленных в ГОСТ Р
ИСО/МЭК 12207. Вместе с тем, ряд концептуальных положений и понятий,
определенных в указанном стандарте, требуют дополнительного пояснения и
более расширенной трактовки. В настоящем стандарте учтены обобщенные
предложения по практическому применению ГОСТ Р ИСО/МЭК 12207,
представленные Техническим комитетом по стандартизации ТК 22
"Информационные технологии".
В частности, термин "работа (activity)" трактуется (в зависимости от
излагаемого контекста) более расширенно как "деятельность" или "виды
деятельности (activities)", термин "задача (task)" - как "задание" (в
зависимости от контекста), а термин "программно-аппаратное средство
(firmware)" - как "программы, реализованные техническими средствами" (во
избежание путаницы с аналогичным понятием, применяемым по отношению к
компонентам автоматизированных систем).
Примечание - Текст основной части стандарта дополнен приложениями
A-D.
1 Область применения
1.1 Назначение
Настоящий стандарт содержит рекомендации по применению ГОСТ Р ИСО/МЭК
12207, а также приложения А, В, С и D.
В стандарте основное внимание уделено особенностям, подлежащим учету
при прикладном применении ГОСТ Р ИСО/МЭК 12207 в условиях реальных
проектов создания программных средств. Приведенные в настоящем стандарте
рекомендации не касаются обсуждения обоснованности требований ГОСТ Р
ИСО/МЭК 12207.
В стандарте рассмотрены три основополагающие модели жизненного цикла
и приведены примеры прикладного применения ГОСТ Р ИСО/МЭК 12207.
1.2 Пользователи стандарта
Настоящий стандарт может быть использован субъектами (лицами,
организациями), желающими применить ГОСТ Р ИСО/МЭК 12207 при реализации
договоров независимо от объема или сложности проекта, конкретной
организацией для самоконтроля или работ по совершенствованию процессов
жизненного цикла программных средств.
В настоящем стандарте указано, как можно использовать ГОСТ Р ИСО/МЭК
12207 применительно к различным типам программных средств и какие процессы
соответствуют каждому случаю.
Настоящий стандарт дополняет ГОСТ Р ИСО/МЭК 12207, являющийся не
только нормативным документом, но и эталоном для управления реальным
проектом. (Например, последний случай имеет место, когда ГОСТ Р ИСО/МЭК
12207 является образцом при проведении части работ процесса
усовершенствования.) Настоящий стандарт должен быть осмыслен целиком, но в
отдельных случаях могут быть использованы его конкретные разделы.
1.3 Предпосылки
Предпосылками для использования настоящего стандарта являются:
a) наличие ГОСТ Р ИСО/МЭК 12207;
b) хорошее знание ГОСТ Р ИСО/МЭК 12207;
c) хорошее знание политики соответствующей организации;
d) общее знание вопросов управления созданием программных средств,
программной инженерии и моделирования жизненного цикла программных
средств.
2 Нормативные ссылки
В настоящем стандарте использованы ссылки на следующие стандарты:
ГОСТ Р ИСО/МЭК 9126-93 Информационная технология. Оценка программной
продукции.
Характеристики качества и руководства по их применению
ГОСТ Р ИСО/МЭК 12207-99 Информационная технология. Процессы
жизненного цикла программных средств
ИСО/МЭК ТО 15504-1-98* Информационная технология. Оценка программного
процесса. Часть 1: Общие положения и вводное руководство
ИСО/МЭК ТО 15504-2-98* Информационная технология. Оценка программного
процесса. Часть 2: Эталонная модель процессов и их возможностей
ИСО/МЭК ТО 15504-3-98* Информационная технология. Оценка программного
процесса. Часть 3: Проведение оценки
ИСО/МЭК ТО 15504-4-98* Информационная технология. Оценка программного
процесса. Часть 4: Руководство по проведению оценок
ИСО/МЭК ТО 15504-5-99* Информационная технология. Оценка программного
процесса. Часть 5: Модель оценки и руководящие указания
ИСО/МЭК ТО 15504-6-98* Информационная технология. Оценка программного
процесса. Часть 6: Руководство по компетентности экспертов
ИСО/МЭК ТО 15504-7-98* Информационная технология. Оценка программного
процесса. Часть 7: Руководство по применению в процессе усовершенствования
ИСО/МЭК ТО 15504-8-98* Информационная технология. Оценка программного
процесса. Часть 8: Руководство по применению при определении возможностей
процесса поставщика
ИСО/МЭК ТО 15504-9-98* Информационная технология. Оценка программного
процесса. Часть 9: Словарь
3 Система обозначений
Диаграммы, описывающие процессы и работы ГОСТ Р ИСО/МЭК 12207,
соответствующие стилю указанного стандарта, приведены на рисунке 1.
"Рис. 1. Графическая система обозначений"
4 Основные концепции в развитие ГОСТ Р ИСО/МЭК 12207
4.1 Инженерная дисциплина
Применение программной инженерии является сравнительно молодой
дисциплиной по сравнению с традиционными направлениями инженерной
деятельности. В результате контроль, обычно сопровождающий проекты
традиционной инженерной деятельности, не всегда возможен для программных
средств.
Основные положения ГОСТ Р ИСО/МЭК 12207 в таких вопросах, как
разработка и сопровождение программного средства, должны быть реализованы
методом, определяемым инженерной дисциплиной. Использование такого метода
позволяет определить структуру, четко привязанную к функциональной среде
системной инженерии, охватывающей программные и технические средства,
персонал и бизнес.
4.2 Архитектура жизненного цикла программного средства
ГОСТ Р ИСО/МЭК 12207 устанавливает архитектуру верхнего уровня
жизненного цикла программного средства от замысла до утилизации.
Архитектура состоит из множества процессов и взаимосвязей между данными
процессами. Процессы основаны на двух исходных принципах: модульности и
ответственности.
4.2.1 Модульность
Процессы в ГОСТ Р ИСО/МЭК 12207 являются модульными в том смысле, что
они:
a) строго связаны. Все части процесса строго взаимоувязаны;
b) свободно соединены. Число интерфейсов между процессами сведено к
минимуму.
В принципе каждый процесс предназначен для реализации уникальной
функции в жизненном цикле и может привлекать другой процесс для выполнения
специализированной функции. Ниже представлены правила для обозначения,
определения области применения и структурирования процессов:
a) процесс должен быть модульным, т. е. один процесс должен выполнять
одну и только одну функцию в жизненном цикле, а интерфейсы между двумя
любыми процессами должны быть минимизированы;
b) каждый процесс должен быть вызываем из архитектуры;
c) если процесс А вызван процессом В и только процессом В, тогда А
принадлежит к В;
d) если функция вызвана более чем одним процессом, тогда функция сама
становится процессом;
e) должна быть возможность верификации любой функции в модели
жизненного цикла;
f) каждый процесс должен иметь внутреннюю структуру, установленную в
соответствии с тем, что должно им быть выполнено.
4.2.2 Ответственность
В ГОСТ Р ИСО/МЭК 12207 термины "организация" и "сторона" являются
близкими по смыслу. Организация, являющаяся группой лиц, собранных для
реализации некоторой конкретной цели, может быть представлена как
корпорация, агентство, предприятие, общество, союз или клуб. Размер
организации может варьироваться от одного человека до множества лиц. Когда
организация в целом (или ее часть) заключает договор, то она становится
стороной. Организация имеет самостоятельные подразделения, а стороны могут
быть из одной или разных организаций.
Каждый процесс в ГОСТ Р ИСО/МЭК 12207 рассмотрен с точки зрения
ответственности (обязанностей) стороны. Организация может выполнять один
или несколько процессов. Процесс может быть выполнен одной или несколькими
организациями, при этом одна из организаций должна быть определена как
ответственная сторона. Сторона, выполняющая процесс, несет ответственность
за весь данный процесс, даже если выполнение отдельных задач поручено
другим людям.
Принцип ответственности в архитектуре жизненного цикла облегчает
прикладное применение ГОСТ Р ИСО/МЭК 12207 для конкретного проекта, в
который может быть вовлечено множество лиц.
4.3 Характеристика процессов
Процессы сгруппированы в три общих класса:
- основные;
- вспомогательные;
- организационные.
4.3.1 Основные процессы
Основными процессами являются:
- заказ;
- поставка;
- разработка;
- эксплуатация;
- сопровождение.
На практике процесс заказа открывает жизненный цикл программного
средства. Процесс поставки отвечает за выполнение процессов разработки,
эксплуатации и (или) сопровождения.
4.3.2 Вспомогательные процессы
Вспомогательными процессами являются:
- документирование;
- управление конфигурацией;
- обеспечение качества;
- верификация;
- аттестация (валидация);
- совместный анализ;
- аудит;
- решение проблемы.
Вспомогательный процесс может быть использован другим процессом,
который таким образом обеспечивает реализацию конкретной цели.
4.3.3 Организационные процессы
Организационными процессами являются:
- управление;
- создание инфраструктуры;
- усовершенствование;
- обучение.
Организация может использовать данные процессы для создания,
реализации и совершенствования процессов жизненного цикла.
4.3.4 Детализация процессов
Каждый процесс затем должен быть определен в терминах составляющих
его работ, каждая из которых должна быть определена в терминах
составляющих ее задач. Работа в процессе состоит из набора связанных
задач. В ГОСТ Р ИСО/МЭК 12207 установлено множество процессов, работ и
задач, количество которых указано в таблице 1.
Таблица 1 - Анализ процессов
+----------------+-----------------+-----------------+------------------+
¦ Класс ¦ Процессы ¦ Работы ¦ Задачи ¦
+----------------+-----------------+-----------------+------------------+
¦Основной ¦ 5 ¦ 35 ¦ 135 ¦
+----------------+-----------------+-----------------+------------------+
¦Вспомогательный ¦ 8 ¦ 25 ¦ 70 ¦
+----------------+-----------------+-----------------+------------------+
¦Организационный ¦ 4 ¦ 14 ¦ 27 ¦
+----------------+-----------------+-----------------+------------------+
¦Всего ¦ 17 ¦ 74 ¦ 232 ¦
+----------------+-----------------+-----------------+------------------+
Задача (задание) должна(о) быть выражена(о) в виде требования,
самообъявления, рекомендации или допустимого действия. С этой целью в ГОСТ
Р ИСО/МЭК 12207 тщательно отобраны некоторые вспомогательные глаголы для
выделения различий между видами задач:
- глагол "должна (shall)" использован для выражения соглашения между
двумя или более сторонами;
- глагол "будет (will)" выражает объявление цели или намерения одной
из сторон;
- глагол "следует (should)" выражает рекомендацию из имеющихся
возможных вариантов;
- глагол "может (may)" указывает образ действий, допустимый в рамках
ГОСТ Р ИСО/МЭК 12207.
4.4 Процессы и проекты
ГОСТ Р ИСО/МЭК 12207 описывает набор процессов, используемых для
больших и (или) сложных программных проектов. Однако ГОСТ Р ИСО/МЭК 12207
может быть применен к программному проекту любого типа, меньшего размера и
сложности. Этот стандарт также может быть использован для программных
средств, являющихся самостоятельными объектами или частями общей системы.
Процессы, работы и задачи в ГОСТ Р ИСО/МЭК 12207 описаны в наиболее
общей естественной позиционной последовательности. Эта последовательность
не предопределяет последовательность реализации модели жизненного цикла.
Описанная последовательность предназначена для того, чтобы в проекте
создания программного средства выбрать, упорядочить, применить и повторить
присущие проекту или подходящие для него процессы, работы (виды
деятельности) и задачи (задания).
В рамках одного проекта ГОСТ Р ИСО/МЭК 12207 может быть использован
многократно и выборочно. Например, в конкретном проекте создания
программного средства заказчик может попросить поставщика выполнить
разработку программного средства с использованием единого метода
применения ГОСТ Р ИСО/МЭК 12207. Поставщик далее может попросить
субподрядчика выполнить всю разработку программного средства или ее часть.
Поставщик (в режиме заказчика) и его субподрядчик (в режиме поставщика)
могут использовать конкретный метод реализации ГОСТ Р ИСО/МЭК 12207. В
обеих ситуациях необходимо прикладное применение ГОСТ Р ИСО/МЭК 12207 для
отражения достигнутых соглашений.
Дальнейшее уточнение данной ситуации - в соответствии с разделом 6.
4.5 Процессы и организации
Организация (или сторона) получает наименование в соответствии с
процессом, который она выполняет в данное время, например называется
заказчиком, когда выполняет процесс заказа.
Процессы в ГОСТ Р ИСО/МЭК 12207 образуют исчерпывающее множество,
удовлетворяющее потребностям различных организаций. Организация, малая или
большая, в зависимости от специфики, может выбрать соответствующее
подмножество процессов (и соответствующих работ и задач) для реализации
поставленной цели. ГОСТ Р ИСО/МЭК 12207 предназначен для применения как
внутри организации, так и в договорных отношениях между двумя или
несколькими организациями. Для того чтобы облегчить применение ГОСТ Р
ИСО/МЭК 12207 как внутри организации, так и вне ее, задачи (задания)
должны быть сформулированы на языке договора. Когда указанный стандарт
применяют внутри организации, язык договора определяется внутренними
задачами, как описано в разделе 7.
ГОСТ Р ИСО/МЭК 12207 должен быть гармонизирован с политикой(ами)
организации и другими существующими стандартами. Обычно имеет место
случай, когда в организации уже используют собственные стандарты и
конкретные методы для разработки программных средств. Поэтому при
применении ГОСТ Р ИСО/МЭК 12207 внутри организации важно выяснить связи
между указанным стандартом, собственными стандартами организации и
различными используемыми методами.
На рисунке 2 приведен один из примеров таких взаимосвязей, который
может быть использован при прикладном применении ГОСТ Р ИСО/МЭК 12207
внутри организации. ГОСТ Р ИСО/МЭК 12207 расположен на первом уровне,
стандарты организации расположены на втором уровне, а третий уровень
предназначен для уточненных методик проведения работ и инструментальных
средств, специфичных для проекта. Термины, устанавливаемые и используемые
на втором и третьем уровнях, должны соответствовать ГОСТ Р ИСО/МЭК 12207.
Уровень 1
+-------------------------------+
Ни входные, ни выходные данные не ¦ ¦
определены. ¦ ГОСТ Р ИСО/МЭК 12207 ¦
Задание выдают в соответствии с ¦ ¦
объектами каждого процесса. ¦ ¦
+----------------+--------------+
Уровень 2 ¦
+----------------+--------------+
Задание выдают в соответствии с ¦ ¦
процедурами в установленной ¦ Стандарты в организации ¦
последовательности. ¦ ¦
+----------------+--------------+
¦
Уровень 3 +---------+---------+
¦ ¦
+----------+-----------+ +-----+----+
¦ Стандарты конкретной ¦ ¦ ¦
¦ области ¦ ¦ Методы ¦
¦ ¦ ¦ ¦
+----------------------- +----------+
Процедуру уточняют для конкретной области.
Они содержат методы для решения проблемы.
Обеспечены средства для поддержки различных методов.
Рисунок 2 - Взаимосвязь между существующими документами
Решения по любым возникающим противоречиям должны быть приняты на
уровне организации, использующей ГОСТ Р ИСО/МЭК 12207, и могут включать в
себя разработку схем и, при необходимости, заполнение выявленных пробелов.
4.6 Программные средства и системы
4.6.1 Интерфейс с системной инженерией
ГОСТ Р ИСО/МЭК 12207 устанавливает строгую связь между системой в
целом и программным средством. Это возможно потому, что указанный стандарт
основан на принципах общей системной инженерии.
ГОСТ Р ИСО/МЭК 12207 разработан с некоторой степенью расширения для
применения в процессе системной инженерии. Когда программное средство
является частью общей системы, его выделяют из системы, создают и включают
в систему. Данное свойство ГОСТ Р ИСО/МЭК 12207 полезно при отсутствии
стандартов системного уровня. Когда программное средство имеет отдельную
область применения, задачи системного уровня можно трактовать как полезные
рекомендации. В любом случае ГОСТ Р ИСО/МЭК 12207 предусматривает
существенное использование программной инженерии в системной инженерии.
4.6.2 Связь между программным средством и системой
Система является конкретной комбинацией технических средств,
компьютеров, программных средств, материалов, персонала и возможностей,
как показано на рисунке 3. Все это фактически образует работоспособную
систему. В исходной системе существуют реальные процессы. Программные
средства служат для обеспечения выполнения некоторых функций данных
процессов на компьютерах. Программные средства могут быть постоянно
(резидентно) размещены в компьютерах, встроены как программы,
реализованные техническими средствами, или интегрированы в объект
технических средств. В любом случае заказ, поставку, разработку,
эксплуатацию или сопровождение программных средств необходимо
координировать и гармонизировать с аналогичными процессами для исходной
системы.
"Рис. 3. Программные средства в системе"
В организации может быть несколько компьютерных систем,
обеспечивающих реальные бизнес-процессы, что показано на рисунке 4.
4.6.3 Системы на основе программных средств
Хотя ГОСТ Р ИСО/МЭК 12207 определяет жизненный цикл системы в целом,
но он охватывает такие процессы, как разработка, эксплуатация и
сопровождение системы только в части ее программных средств. Поэтому
процессы жизненного цикла технических средств в ГОСТ Р ИСО/МЭК 12207 не
определены.
4.6.4 Классификация системных и программных работ (видов
деятельности)
В процессе разработки программных средств по ГОСТ Р ИСО/МЭК 12207
различают два типа работ (видов деятельности): системные и программные.
Область применения данных работ отражена в их наименовании.
Соотношения между системными и программными работами показаны на
рисунке 5, разделенном на две соответствующие группы.
Как показано на рисунке 5, системные работы (виды деятельности) в
процессе разработки программных средств по ГОСТ Р ИСО/МЭК 12207 начинают с
анализа требований к системе (5.3.2) и завершают квалификационными
испытаниями системы (5.3.11).
В разделе 8 настоящего стандарта описано, как система становится
комбинацией технических и программных средств и ручных операций.
Разделение системы на данные элементы начинают с работы "Проектирование
системной архитектуры" (5.3.3 ГОСТ Р ИСО/МЭК 12207). Программные работы,
которые выделяют из конкретного архитектурного (эскизного) проекта,
начинают с анализа требований к программным средствам (5.3.4) и завершают
квалификационными испытаниями программных средств (5.3.9).
"Рис. 4. Компьютерные системы в организации"
После завершения разработки программных средств их интегрируют с
техническими средствами и ручными операциями в соответствии с работой
"Сборка системы" (5.3.10 ГОСТ Р ИСО/МЭК 12207), а затем выполняют работу
"Квалификационные испытания системы" (5.3.11). Основываясь на
вышеуказанных работах, можно сделать вывод о том, что системные работы
являются расширением набора программных работ.
4.7 Управление и планирование
Для каждого из основных и вспомогательных процессов управление
соответствующим процессом на проектном уровне реализуют, конкретизируя
процесс управления. Посредством этого процесса осуществляют планирование,
а также реализацию и контроль всех запланированных событий. Разделы,
которые должны быть включены в план, определены в 7.1.2.1 ГОСТ Р ИСО/МЭК
12207, тогда как 7.1.3.2 указанного стандарта определяет отчетность о ходе
процесса, а 7.1.3.3 его же устанавливает отчетность о проблемах.
4.7.1 План управления проектом
В процессе поставки по 5.2.4.5 ГОСТ Р ИСО/МЭК 12207 требуется
подготовка плана управления проектом, а по 5.2.5.1 указанного стандарта
данный план реализуют и контролируют. Далее в процессе поставки должен
быть осуществлен надзор за технической реализацией, расходами, выполнением
планов (графиков) и проведена соответствующая отчетность (5.2.5.3 ГОСТ Р
ИСО/МЭК 12207).
"Рис. 5. Классификация работ (видов деятельности)
по ГОСТ Р ИСО/МЭК 12207"
4.7.2 Дополнительные планы
Вопросы, требующие дополнительного рассмотрения и перечисленные в
5.2.4.5 ГОСТ Р ИСО/МЭК 12207, связаны с некоторыми вспомогательными и
организационными процессами. Для ряда таких процессов требуется разработка
соответствующих планов, например обеспечения качества, верификации и
обучения. В зависимости от объема и сложности проекта, а также возможности
субподрядного выполнения всех или ряда работ данные планы могут быть
включены в план управления проектом или подготовлены в виде отдельных
дополнительных документов.
При привлечении субподрядчиков подобные вопросы отслеживают в
соответствии с 5.2.5.4 ГОСТ Р ИСО/МЭК 12207, уделяя особое внимание
установлению необходимых взаимосвязей для синхронизации данных планов.
Сводные сведения о наборе дополнительных планов могут быть получены
из таблиц В.2 и В.З приложения В к настоящему стандарту.
4.7.3 Контроль документов
Требования по управлению документами включают в себя планы, описанные
в процессе документирования (6.1 ГОСТ Р ИСО/МЭК 12207).
4.8 Реализация принципов управления качеством
В ГОСТ Р ИСО/МЭК 12207 реализованы принципы управления качеством и
сделано это тремя основными способами, описанными ниже.
4.8.1 Интеграция качества в жизненный цикл
ГОСТ Р ИСО/МЭК 12207 устанавливает требования к всеобъемлющему
интегрированному набору процессов, охватывающих жизненный цикл
программного средства. Указанный стандарт обеспечивает для каждого
процесса доступ к циклу "план - реализация - проверка - акт" (plan - do -
check - act) посредством процесса усовершенствования. При этом все работы,
связанные с качеством и трактуемые как неотъемлемая часть жизненного цикла
программного средства, входят в соответствующие процессы жизненного цикла.
Таким образом, за каждым процессом и персоналом, отвечающим за его
реализацию, закреплены работы в рамках данного процесса, связанные с
качеством.
4.8.2 Процесс обеспечения качества
Процесс обеспечения качества (6.3 ГОСТ Р ИСО/МЭК 12207) предназначен
для обеспечения соответствия продуктов и услуг конкретным требованиям и
установленным планам. Лица, отвечающие за данный процесс, должны быть
наделены необходимой организационной независимостью и соответствующими
полномочиями. Организационная независимость подразумевает независимость от
тех, кто непосредственно отвечает за создание продукта, а соответствующие
полномочия подразумевают права на проведение оценки и инициализацию
корректирующих действий.
4.8.3 Процесс усовершенствования
ГОСТ Р ИСО/МЭК 12207 (7.3) определяет процесс усовершенствования для
дальнейшего повышения качества работ организации в целом независимо от
договорных обязательств.
4.9 Гибкость и отзывчивость на развитие технологии
ГОСТ Р ИСО/МЭК 12207 является гибким и чувствительным к развитию
дисциплины программной инженерии. Это достигается обеспечением открытой
архитектуры высокого уровня, т.е. ГОСТ Р ИСО/МЭК 12207 является:
a) применимым к любой(ым):
- модели(ям) жизненного цикла (например, каскадной, инкрементной или
эволюционной);
- методам или технологиям программной инженерии (например,
объектно-ориентированное проектирование, структурное программирование,
нисходящее тестирование или макетирование);
- языкам программирования (например, КОБОЛ, Ада или ассемблер).
Решение данных вопросов зависит от самого проекта и современного
состояния технологии, а выбор этих элементов осуществляет пользователь
ГОСТ Р ИСО/МЭК 12207;
b) гибким с общей точки зрения, т. е. работы (виды деятельности) и
задачи (задания) процесса жизненного цикла отвечают на вопросы "что
делать?", а не на вопросы "как делать?". Другими словами, задачей может
быть "разработать и документально оформить архитектурный проект", но не
"разработать или документально оформить архитектурный проект с
использованием метода нисходящего функционального проектирования". Данная
схема предоставляет заказчику широкие возможности для установления
требований к конечному продукту или услуге и, в то же время, позволяет
продавцу разрабатывать и применять соответствующие методы, способы и
инструментарий для создания продукта или предоставления услуги;
c) адаптируемым к любой отрасли промышленности (например, к военным
или коммерческим целям) или любой национальной или организационной
культуре.
4.10 Процессы и документирование
ГОСТ Р ИСО/МЭК 12207 не является стандартом в области
документирования, т. е. даже если в указанном стандарте установлены
требования к документированию некоторых выходных результатов процессов, он
не определяет формат или содержание документов. Указанный стандарт не
определяет, как объединять аналогичные выходные результаты, такие как
планы, спецификации (технические задания) или требования к тестированию.
Уточненные требования к документированию приведены в приложении В к
настоящему стандарту.
4.11 Метрики программных средств
ГОСТ Р ИСО/МЭК 12207 не определяет или не задает свойств (атрибутов)
программного средства (таких как надежность или удобство сопровождения) в
терминах конкретной системы показателей (метрик) и указателей. Этот
стандарт описывает способы для определения подобных свойств программного
средства, но они должны быть уточнены пользователями ГОСТ Р ИСО/МЭК 12207.
4.12 Согласованность
Соответствие с ГОСТ Р ИСО/МЭК 12207 может быть достигнуто следующими
способами:
a) организация публично объявляет условия сделки, набор процессов,
работ (видов деятельности) и задач (заданий) из ГОСТ Р ИСО/МЭК 12207,
которым должны подчиняться поставщики данной организации;
b) программный проект адаптирует соответствующие процессы, работы и
задачи, которые должны быть реализованы по договорным критериям.
Примечание - ГОСТ Р ИСО/МЭК 12207 содержит набор требований,
сформулированных как "должен". Пользователи указанного стандарта не
обязаны подчиняться данному документу в целом, т. е. они не должны
добиваться соответствия всем формулировкам "должен" из ГОСТ Р ИСО/МЭК
12207. Соглашение по данному вопросу может быть достигнуто между двумя
сторонами. Стороны могут решить, что ГОСТ Р ИСО/МЭК 12207 является основой
для соглашения, или они могут согласовать соответствующую адаптацию ГОСТ Р
ИСО/МЭК 12207 для удовлетворения своих частных требований.
4.13 Заключение
ГОСТ Р ИСО/МЭК 12207 не заменяет строго систематизированное
управление проектированием программного обеспечения систем. Указанный
стандарт определяет структуру, в которой процессы, работы и задачи,
связанные с программным средством, могут быть соответствующим образом
определены, запланированы и выполнены. ГОСТ Р ИСО/МЭК 12207 содержит набор
четко определенных конструктивных блоков (процессов). Пользователь
указанного стандарта должен выбрать, практически применить и скомпоновать
данные блоки соответственно целям и задачам своей организации и проекта.
При практическом применении ГОСТ Р ИСО/МЭК 12207 должны быть сохранены его
архитектура, сущность и целостность, например включением элементов
стандарта с пометой "не применяется" и объяснением причины его
неиспользования.
5 Внедрение ГОСТ Р ИСО/МЭК 12207
5.1 Обзор
ГОСТ Р ИСО/МЭК 12207 может быть внедрен по разным причинам, включая:
- применение его в конкретном проекте при определении процессов,
работ и задач, связанных с программными средствами:
- использование его организацией в качестве основы для
усовершенствования программных процессов в самой организации;
- использование его в качестве компонента в процессе моделирования
общего жизненного цикла системы.
Какой бы ни была причина для внедрения ГОСТ Р ИСО/МЭК 12207,
рекомендуемая стратегия его практического применения состоит из следующих
шагов:
a) плана внедрения;
b) практического применения ГОСТ Р ИСО/МЭК 12207;
c) проведения сопровождения пилотного проекта(ов);
d) формализации метода внедрения;
e) утверждения метода внедрения.
Стратегией является типовой метод внедрения, которого следует
придерживаться при внесении изменений в деятельность организации или
проект. Описанная выше стратегия внедрения может быть неоднократно
повторена в проекте или организации, когда вводят дополнительные процессы
и (или) совершенствуют существующие.
Когда проект или организация уже находится в стабильном состоянии, т.
е. для него(е) определены и утверждены процессы по ГОСТ Р ИСО/МЭК 12207,
тогда стратегия внедрения должна быть укорочена и может состоять из
следующих шагов:
a) плана внедрения;
b) практического применения ГОСТ Р ИСО/МЭК 12207;
c) проведения сопровождения пилотного проекта(ов).
5.2 План внедрения
Внедрение ГОСТ Р ИСО/МЭК 12207 должно быть рассмотрено как конкретный
проект и соответствующим образом спланировано.
При планировании внедрения указанного проекта должны быть учтены
следующие аспекты:
а) определение области применения проекта, включая, возможно:
- единый проект внутри организации или часть двустороннего договора;
- выделение некоторых ключевых процессов или даже единственного
процесса, от которого ожидают выгоду для организации. Данный метод может
быть использован, когда были обнаружены недостатки в деятельности
организации и в дальнейшем предполагают полное внедрение ГОСТ Р ИСО/МЭК
12207;
- практическое применение ГОСТ Р ИСО/МЭК 12207 через ряд проектов с
вероятным постадийным его введением. При этом в организации могут
отсутствовать или существовать некоторые процессы, которые должны быть
стандартизованы по ГОСТ Р ИСО/МЭК 12207;
- практическое применение ГОСТ Р ИСО/МЭК 12207 во всех проектах и во
всех подразделениях данной организации. Вероятность использования данного
метода какой-либо организацией, за исключением очень небольшой, невелика.
Данный метод внедрения может быть пригоден для нового филиала существующей
организации, в которой для практической работы ранее уже был использован
ГОСТ Р ИСО/МЭК 12207;
b) определение целей проекта и установление того, как они
соответствуют общим целям деятельности организации. Если явная связь между
данным проектом и деловыми интересами организации не установлена, то
сформулировать предложение по достижению целей проекта внедрения ГОСТ Р
ИСО/МЭК 12207 затруднительно;
c) определение ролей и обязанностей группы или организации
проектировщиков с установлением единоличной ответственности за каждый
процесс. В большинстве случаев одно лицо или организация отвечает за
несколько процессов, особенно в малых проектах или организациях;
d) определение ресурсов, необходимых для внедрения ГОСТ Р ИСО/МЭК
12207, таких как время, деньги, персонал и оборудование;
e) создание и документальное оформление плана управления проектом по
внедрению ГОСТ Р ИСО/МЭК 12207.
5.3 Практическое применение ГОСТ Р ИСО/МЭК 12207
При выполнении позиций плана внедрения, связанных с практическим
применением указанного стандарта, реализуют процесс адаптации, описанный в
приложении А ГОСТ Р ИСО/МЭК 12207. Рекомендации по практическому
применению ГОСТ Р ИСО/МЭК 12207 для конкретных целей приведены в разделах
6 - 8 настоящего стандарта.
Данные рекомендации из настоящего стандарта должны быть изучены
совместно с общими советами по его практическому применению, приведенными
в приложении В ГОСТ Р ИСО/МЭК 12207, и материалами, связанными с
конкретной ситуацией. Например, практическое применение указанного
стандарта может быть выполнено внутри организации с использованием
особенностей модели жизненного цикла системы.
На рисунке 6 показана последовательность событий в процессе
адаптации, который рассмотрен в приложении А ГОСТ Р ИСО/МЭК 12207.
Конкретные примеры практического применения указанного стандарта приведены
в приложении D к настоящему стандарту. В данных примерах:
- использованы сценарии для определения среды проектирования;
- при необходимости определены дополнительные работы и задачи;
- обобщены решения по практическому применению ГОСТ Р ИСО/МЭК 12207 и
приведены обоснования для него.
5.3.1 Определение среды проектирования и характеристик проекта
Характеристики организации могут быть определены при ответе на
следующие вопросы:
- Какие процессы, стратегии и процедуры уже применяются?
(Это важно для определения применяемых процессов и практических
методов, подлежащих включению в общий набор необходимых процессов.)
- Является ли данный процесс основным для достижения целей
организации?
- Учтен ли повышенный деловой риск?
- Где существуют проблемные области?
- Какова практика организации (легкоадаптируема или невосприимчива к
изменениям)?
Характеристики проекта могут быть определены при ответе на следующие
вопросы:
- Какая модель жизненного цикла системы или проекта используется?
- Каков уровень совершенства конкретного процесса?
- Каков технический риск?
- Является ли система критичной по безопасности?
- Будут ли использованы новые технологии?
5.3.2 Запрос исходных данных
Соответствующие требования, выделенные из деловых и договорных
потребностей организации (проекта), являются исходными данными для
практического применения ГОСТ Р ИСО/МЭК 12207. Например, ГОСТ Р ИСО/МЭК
12207 может быть применен в соответствии с договором между поставщиком и
покупателем продукта.
+-------------------------+
¦ ¦
¦ Начало ¦
¦ ¦
+-------------------------+
+----------------------------------+
¦ Определение ¦
¦ среды проектирования и ¦
¦ характеристик проекта ¦
+----------------------------------+
+----------------------------------+
¦ Запрос ¦
¦ исходных данных ¦
+----------------------------------+
+----------------------------------+
¦ Выбор процессов, ¦
¦ работ и задач ¦
+----------------------------------+
+----------------------------------+
¦ Документирование ¦
¦ решений по внедрению ¦
¦ и их обоснований ¦
+----------------------------------+
+-------------------------+
¦ ¦
¦ Конец ¦
¦ ¦
+-------------------------+
Рисунок 6 - Работы по практическому применению ГОСТ Р ИСО/МЭК 12207
Потребитель может потребовать только проведения проектирования
программного средства, а не полной разработки программного обеспечения
системы. В другом случае, если требования потребителя связаны с критичным
по безопасности программным средством, заменяющим существующее у него
программное средство, ряд задач (заданий) из ГОСТ Р ИСО/МЭК 12207 может
быть исключен.
Заинтересованные стороны должны быть вовлечены в процесс принятия
решений по практическому применению указанного стандарта. Данные лица
могут обеспечить реализацию и эффективность применения выбранных
процессов. При этом, по возможности, должна быть обеспечена
преемственность реализуемых проектов.
5.3.3 Выбор процессов, работ и задач
Должны быть определены подлежащие реализации процессы или части
процесса из ГОСТ Р ИСО/МЭК 12207 и приоритеты их реализации. Обычно
предпочтительнее начинать с процессов, от которых может быть получена
наибольшая отдача, чем пытаться сразу внедрить весь ГОСТ Р ИСО/МЭК 12207.
ГОСТ Р ИСО/МЭК 12207 не определяет последовательность выполнения
процессов, работ и задач и не предписывает какую-либо конкретную модель
жизненного цикла программного средства. На данной стадии полезно провести
привязку существующих процессов, практического опыта и (или) методов к
процессам, работам и задачам из ГОСТ Р ИСО/МЭК 12207.
Подобная привязка может быть применена для проверки полноты
используемого метода внедрения, т. е. определения наличия "пробелов" между
существующей и планируемой ситуацией, в которой предполагают использовать
процессы из ГОСТ Р ИСО/МЭК 12207.
5.3.4 Документирование решений по внедрению и их обоснований
При практическом применении ГОСТ Р ИСО/МЭК 12207 должна быть
документально оформлена привязка установленных процессов, работ и задач к
выбранной модели(ям) жизненного цикла программного средства вместе с
выявленными взаимосвязями и обоснованиями применения выбранного метода.
Данные документы должны быть включены в план управления проектом по
внедрению ГОСТ Р ИСО/МЭК 12207, чтобы обеспечить эталонную структуру для
проведения оценки или обзора реализации конкретного метода внедрения.
5.4 Проведение сопровождения пилотного проекта(ов)
При внедрении в организации ГОСТ Р ИСО/МЭК 12207 через реализацию
ряда проектов можно ограничить степень риска для организации путем
использования некоего "лоцмана" в ключевых областях и процессах. Успешное
внедрение ГОСТ Р ИСО/МЭК 12207 обычно включает в себя такие методы, как:
a) определение пилотных проектов, которые могут использовать
выбранные процессы. Данные пилотные проекты должны быть выбраны на основе
приоритетных работ, которые с высокой вероятностью приведут к
значительному улучшению результатов и от которых ожидают быструю реальную
отдачу;
b) выбор группы добровольцев для сопровождения пилотных проектов с
последующим пропагандированием и вознаграждением их усилий;
c) обучение всех вовлеченных в процесс. Повышению знаний обучаемых
можно способствовать путем регулярного уведомления их о развитии процесса
внедрения в дополнение к официальным курсам обучения;
d) планирование пилотных проектов и определение критических факторов
достижения успеха;
e) включение выбранного адаптированного процесса(ов) в план
управления проектом для каждого пилотного проекта. При этом в план должны
быть включены документы, описанные в 5.3.4 настоящего стандарта, или даны
ссылки на них;
f) реализация пилотного проекта(ов), отслеживание и документирование
хода его выполнения по критическим факторам успеха реализации. Навыки
документирования осваивают в ходе пилотного проекта(ов). Полученные уроки
должны быть учтены при совершенствовании процессов.
5.5 Формализация метода внедрения
Формализация включает в себя введение нового процесса в ряд проектов
и (или) в организации. При этом принимают и используют такие методы, как
обучение, документирование, предоставление инструментальных средств для
нового процесса(ов), а также слежение за данным процессом(ами) и
определение его недостатков. В любом утвержденном и реализуемом проекте
должно быть осуществлено планирование перехода к новому процессу(ам).
Примечание - При надзоре за ходом проекта в него могут быть внесены
усовершенствования (уточнения). Подобные уточнения также могут быть
внесены при сравнении одного проекта с другим с целью определить наилучшие
методы внедрения ГОСТ Р ИСО/МЭК 12207, подлежащие реализации в последующих
проектах.
5.6 Утверждение метода внедрения
Утверждение метода внедрения ГОСТ Р ИСО/МЭК 12207 обеспечивает
последовательную и автоматизированную реализацию процесса внедрения в
проекте или организации. При этом также обеспечивают оценку протекания
данного процесса и, при необходимости, его усовершенствование. Для этой
цели может быть использован процесс усовершенствования, описанный в 7.3
ГОСТ Р ИСО/МЭК 12207.
6 Применение в проектах
В настоящем разделе приведены дополнительные рекомендации по
применению ГОСТ Р ИСО/МЭК 12207 в проекте. Однако данные рекомендации не
являются исчерпывающими в связи с отличиями одного проекта от другого.
Следующие факторы могут влиять на заказ, разработку, эксплуатацию или
сопровождение программного средства:
- различия в стратегиях и процедурах, принятых в разных организациях;
- особенности стратегий различных проектов в цикле "заказ -
поставка";
- объем и сложность проекта;
- требования к системе.
ГОСТ Р ИСО/МЭК 12207 разработан с учетом подобных вариантов и
подходит для любого проекта. Кроме того, в целях снижения стоимости и
повышения качества разработки ГОСТ Р ИСО/МЭК 12207 можно практически
применять к конкретному проекту. Всем субъектам проекта должны быть
предоставлены возможности участия в процессе адаптации указанного
стандарта.
6.1 Особенности практического применения ГОСТ Р ИСО/МЭК 12207
В настоящем подразделе рассмотрены ключевые факторы, которые должны
быть учтены при применении ГОСТ Р ИСО/МЭК 12207 в проекте. Перечень этих
факторов, не являющийся исчерпывающим, связан с текущим состоянием
рассматриваемого вопроса, а каждый из данных факторов должен быть
взаимоувязан с другими и влиять на них в зависимости от специфики
программного проекта. При рассмотрении среды проектирования может быть
полезна следующая группа факторов:
- организационные вопросы;
- проектный риск;
- наличие и достаточность ресурсов.
6.1.1 Модель жизненного цикла системы
Степень практического применения ГОСТ Р ИСО/МЭК 12207 в качестве
обязательного (нормативного) или рекомендуемого документа зависит от места
данного программного проекта в модели жизненного цикла системы (типовые
модели жизненного цикла рассмотрены в приложении С к настоящему
стандарту).
Должна быть определена соответствующая позиция модели жизненного
цикла системы, в которой программное средство становится частью системы
(см. 8.1). Установление этого поможет определить:
- является ли программное средство частью системы или имеет
самостоятельное применение;
- можно ли использовать ГОСТ Р ИСО/МЭК 12207 в качестве метода для
проведения компьютерного моделирования и имитации;
- можно ли использовать ГОСТ Р ИСО/МЭК 12207 для разработки,
эксплуатации или сопровождения программного средства.
Следует также рассмотреть соответствующие пункты данного раздела и
обеспечить установление необходимых интерфейсов в модели жизненного цикла
системы.
6.1.2 Политики и процедуры организаций
Должны быть определены соответствующие политики и процедуры
заинтересованных организаций, особенно заказчика и поставщика, с которыми
необходимо согласовать программный проект. Например, политики и процедуры,
связанные с:
- защитой;
- безопасностью;
- конфиденциальностью;
- управлением риском;
- использованием независимого органа по верификации и аттестации
(валидации);
- использованием конкретного языка программирования;
- обеспечением техническими ресурсами.
Необходимо определить любые соответствующие законы и подзаконные
акты, включая документы, относящиеся к среде, общей безопасности и
конфиденциальности и влияющие на программный проект. Это необходимо для
контроля за соответствием поведения системы данным нормативным актам.
Вышеназванные политики и процедуры необходимо соответственно
учитывать при разработке, эксплуатации и сопровождении программного
средства. Например, если имеются политики безопасности и защиты, в них
необходимо включить работы по анализу требований из процесса разработки и
работу по эксплуатации системы из процесса эксплуатации.
6.1.3 Характеристики системы
Необходимо определить на соответствующем уровне детализации
подсистемы и элементы конфигурации системы. Необходимо определить
характеристики системы, особенно те, которые относятся к программному
средству. При определении данных характеристик необходимо отметить, какие
из них являются критичными при эксплуатации системы.
Примерный перечень характеристик системного уровня (относящихся к
программному средству и подлежащих учету) включает в себя:
- межсистемные и внутрисистемные интерфейсы;
- интерфейсы пользователя;
- влияние ошибок программного средства на защиту и безопасность
системы;
- оценку вычислительных мощностей и временных ограничений;
- наличие программ, реализованных техническими средствами;
- наличие соответствующих компьютеров.
Если в систему входит много подсистем или элементов конфигурации, для
них должны быть полностью проведены работы системного уровня из процесса
разработки. Должны быть учтены все требования к интерфейсам и сборке
(интеграции) системы. Для небольшой системы подобная строгая
последовательность действий может не понадобиться.
6.1.4 Характеристики программного средства
Должны быть определены характеристики программного уровня, например:
- потенциальное число элементов программной конфигурации;
- типы, объемы и критичность программных средств;
- технический риск;
- типы, комплектность и носители документов;
- необходимость новой разработки, изменения или повторного применения
программного средства;
- аспекты из ГОСТ Р ИСО/МЭК 9126, такие как надежность.
Если в программное средство входит много элементов программной
конфигурации, компонентов и модулей, для каждого элемента данной
конфигурации должны быть полностью проведены работы программного уровня из
процесса разработки. Должны быть учтены все требования к интерфейсам и
сборке (интеграции) программного средства. Для небольшого программного
средства подобная строгая последовательность действий может не
понадобиться.
Должны быть определены работы (виды деятельности), связанные с
контролем за административным управлением и проведением оценок, которые
могут потребоваться для программного средства с точки зрения критичности
системы и характеристик самого программного средства.
6.1.5 Политика сопровождения программного средства
Должны быть учтены вопросы, связанные с сопровождением программного
средства. Типовыми объектами, рассматриваемыми при этом, являются:
- ожидаемый период сопровождения;
- ожидаемая периодичность внесения изменений;
- критичность применения;
- определение персонала, осуществляющего сопровождение;
- определение степени квалификации данного персонала;
- определение среды, необходимой для сопровождения программного
средства, включая его тестирование.
Должны быть учтены все требования к документированию программного
средства, особенно если предполагают длительный период его сопровождения
или внесение в него существенных изменений. При необходимости в среде
документирования может быть предусмотрено средство для поиска необходимой
информации.
Полезно также обеспечить в период сопровождения электронный доступ к
документам.
6.1.6 Модель жизненного цикла проекта
Для проекта должен быть проведен выбор одной или нескольких
соответствующих моделей жизненного цикла (см. приложение С к настоящему
стандарту). Должно быть установлено, является ли модель жизненного цикла
программного средства составной частью модели жизненного цикла системы
либо полной моделью жизненного цикла.
Каждая модель жизненного цикла в приложении С содержит некоторые
процессы и работы, которые могут быть выполнены последовательно, повторно
или комбинированно. Работы процессов из ГОСТ Р ИСО/МЭК 12207 должны быть
отображены в выбранной модели жизненного цикла. С точки зрения создания
модифицируемого, развивающегося, структурированного и планируемого
продукта, результаты одной работы из модели жизненного цикла должны быть
переданы следующей. В этом случае соответствующие документы должны быть
созданы к окончанию данной работы, т. е. до начала следующей работы.
6.1.7 Разнообразие участвующих сторон
Должны быть определены стороны, участвующие в проекте, и их
ответственность за конкретные процессы. Должны быть учтены все работы и
задачи из ГОСТ Р ИСО/МЭК 12207, связанные с взаимодействиями
(интерфейсами) между этими сторонами.
Для большого проекта, в который вовлечено много лиц, необходим
развитой административный надзор и контроль. Например, проведение
внутренних и независимых оценок, анализов, аудиторских проверок, инспекций
и подготовка отчетов, являющихся главным инструментарием для большого
проекта. Для малых проектов подобные средства контроля могут быть
излишними и должны быть использованы взвешенно.
6.1.8 Типы программных средств
Должны быть определены типы программных средств, охваченных проектом,
так как для различных типов требуются различные решения по внедрению ГОСТ
Р ИСО/МЭК 12207. Примерами типов программных средств являются:
a) новая разработка;
b) готовое;
c) программы, реализованные техническими средствами;
d) автономное;
e) непоставляемое.
Ниже приведены некоторые важные рекомендации по основным типам
программных средств. Следует запомнить, что различные типы программных
средств реализуются на различных этапах процесса разработки, связанных с
выполнением соответствующего набора работ.
a) Новая разработка.
Данный тип программного средства изначально охвачен процессом
разработки. Поэтому для него должны быть учтены все требования к процессу
разработки.
b) Готовое:
- используют именно готовое программное средство целиком. Данный тип
программного средства уже спроектирован, запрограммирован и тестирован, но
может потребоваться дополнительное тестирование в зависимости от такого
его свойства, как критичность или практика применения. Данный тип
программного средства охватывается процессом разработки не позднее
проведения квалификационных испытаний системы, а полный процесс разработки
для него является избыточным. Для данного типа должны быть оценены:
качество функционирования, документы, права собственности и возможности
его сопровождения (поддержки);
- готовое программное средство включают в процесс разработки без
изменений, но требуется настройка его параметров под необходимую
конфигурацию. В список настраиваемых параметров, например, может входить
формат данных или размер бумаги. Данный тип охватывается процессом
разработки после тестирования или сборки (интеграции) программных модулей
разрабатываемого программного средства. Полный процесс разработки для
данного типа может быть избыточным. Для данного типа должны быть оценены:
качество функционирования, документы, права собственности и возможности
его сопровождения (поддержки);
- модифицированное готовое программное средство, например с
дополнением более подходящими форматами отчетов или отсутствием ряда
документов. В данном случае, в зависимости от критичности объекта и
предполагаемых изменений в нем, процесс разработки должен быть применен
через процесс сопровождения. Процесс разработки подключают при
программировании и тестировании модификаций данного программного средства.
Для этого типа должны быть оценены: качество функционирования, документы,
права собственности и возможности его сопровождения (поддержки).
c) Программы, реализованные техническими средствами.
Это программное средство аппаратно встроено в систему или подключено
к ней. Так как данное программное средство является частью большой
системы, в процессе его разработки должны быть предусмотрены работы
системного уровня. Из работ системного уровня должны быть выбраны те,
которые определяются глаголами "выполнить" или "обеспечить". Если данный
тип (программного средства в целом или входящих в него программ,
реализованных техническими средствами) в дальнейшем изменять не
предполагается, то требуется тщательная проверка документов к нему.
d) Автономное.
Данный тип охватывает автономные программные средства. Так как они не
являются частью законченной системы, проведения работ системного уровня в
процессе разработки для них не требуется. При этом для них должны быть
тщательно проверены необходимые документы, особенно в части их
сопровождения.
e) Непоставляемое.
Так как данный тип средств не является объектом заказа, поставки или
разработки, соответствующие разделы ГОСТ Р ИСО/МЭК 12207 для них не
учитывают, за исключением 5.3.1.5 указанного стандарта. Однако если
заказчик решит заказать часть таких программных средств для последующей их
эксплуатации и сопровождения, тогда к ним следует применять рекомендации в
соответствии с перечислениями b) и d) данного пункта.
6.1.9 Объем проекта
Большой проект, в который вовлечены десятки или сотни лиц, вызывает
значительные трудности в управлении им по сравнению с проектом, в котором
заняты, например, три человека. Большие проекты или проекты с привлечением
субподрядчиков требуют тщательного административного надзора и контроля. В
некоторых проектах данные мероприятия реализуют применением совместных
анализов, аудиторских проверок, верификации, аттестации и обеспечением
качества. Для малых проектов подобные методы контроля могут быть
излишними.
6.1.10 Критичность проекта
Для системы, работа которой в значительной степени зависит от
правильного функционирования программных средств и своевременной выдачи
результатов, необходим более тщательный надзор и контроль. Напротив, для
некритичного программного средства излишний надзор и контроль, вероятно,
неэффективен. (Для уточнения понятия критичности - см. 6.4.1.1 ГОСТ Р
ИСО/МЭК 12207.)
6.1.11 Технический риск
При разработке программного средства может иметь место технический
риск. Если использована несовершенная технология программирования, то
будет создано уникальное или сложное программное средство; если к
программному средству предъявлены требования по безопасности и (или)
защите или другие критические требования, то могут быть необходимы строгое
определение технических требований, тщательное проектирование,
тестирование и оценка, а также независимая верификация и аттестация.
7 Применение в организациях
7.1 Предпосылки и методы
Организации должны широко использовать ГОСТ Р ИСО/МЭК 12207 в
качестве составной части деятельности по усовершенствованию процессов,
связанных с программными средствами. Это может быть выполнено автономно
или вместе с доступными методами оценки и определения функциональных
возможностей процесса, например описанными в стандартах серии ИСО/МЭК ТО
15504.
Применение ГОСТ Р ИСО/МЭК 12207 в организации основано на тех же
методах внедрения, которые используют в проектах. Организации, внедряющие
ГОСТ Р ИСО/МЭК 12207, должны использовать рекомендации, приведенные в
разделе 6, и политики, описанные в разделе 5 настоящего стандарта.
7.2 Возможности применения
Причины, по которым ГОСТ Р ИСО/МЭК 12207 внедряют в организации,
могут быть следующими:
- проверка совершенства существующего метода. Это обычно имеет место,
когда метод был разработан самой организацией или ею был выбран и изменен
существующий метод;
- практическое применение данного метода для предотвращения риска,
связанного с выходом на новые секторы рынка с более жесткими требованиями,
связанными с потенциальным риском;
- разработка нового метода, например для удовлетворения потребностям
новой организации. Тем самым могут быть охвачены организации, созданные
путем слияния или делового сотрудничества. Это может быть необходимо для
сопровождения некоторых моделей процессов обеспечения конкретных работ;
- управление внедрением новой технологии, например: автоматизация
ручных процессов или изменение методов, используемых при внедрении
программного продукта. ГОСТ Р ИСО/МЭК 12207 устанавливает критерии,
которые могут быть использованы для контроля совершенства соответствующего
метода до или после изменения технологии;
- оценка внутренних возможностей стороны с точки зрения
удовлетворения критериям договора, например в качестве стороны,
участвующей в конкурсном (тендерном) процессе;
- определение контрольных этапов, при реализации которых могут быть
разработаны более совершенные программы, например проведение аудита в
соответствии с ГОСТ Р ИСО/МЭК 12207 и использование самого процесса
усовершенствования.
7.3 Распространение административного управления
Для любой программы работ, связанной с изменениями существующей
практической деятельности, внутри организации должно быть обеспечено
административное управление надзором за реализацией и внесением изменений.
При участии в работах многих сторон подобный метод должен быть
предусмотрен договором и, в случае реализации его головной организацией,
распространен на все участвующие стороны.
8 Прикладное применение модели жизненного цикла системы
Настоящий раздел иллюстрирует общую модель жизненного цикла системы
или проекта и описывает, как ГОСТ Р ИСО/МЭК 12207 может быть внедрен в
данной модели жизненного цикла системы. Обзор типовых моделей жизненного
цикла - по приложению С к настоящему стандарту.
8.1 Модель жизненного цикла системы
Типовая модель жизненного цикла системы начинается с концепции идеи
системы или потребности в ней, охватывая разработку, создание,
эксплуатацию и сопровождение системы, и заканчивается снятием системы с
эксплуатации (утилизацией). Модель жизненного цикла обычно разделяют на
периоды реализации, например стадии или этапы. Каждый подобный период
включает в себя основные реализуемые в нем работы и задачи, при завершении
которых может потребоваться разрешение на переход к следующему периоду
реализации.
Например, общую модель жизненного цикла системы разделяют на стадии
(этапы) с последующей адаптацией каждой из них к модели жизненного цикла
конкретной системы:
a) определение потребностей;
b) исследование и описание основных концепций;
c) демонстрация и аттестация основных концепций;
d) проектирование и разработка;
e) создание и производство;
f) распространение и продажа;
g) эксплуатация;
h) сопровождение и поддержка;
i) снятие с эксплуатации (утилизация).
8.2 Модель жизненного цикла программного средства
Типовая модель жизненного цикла программного средства состоит из ряда
работ. Данная модель начинается с формулировки замысла (идеи) или
концепции программного продукта или услуги, продолжается работами по
применению методов системной и программной инженерии, работами по
эксплуатации, сопровождению и поддержке и заканчивается снятием с
эксплуатации (утилизацией). В ГОСТ Р ИСО/МЭК 12207 все эти и другие,
связанные с ними работы, объединены в основные, вспомогательные и
организационные процессы, из которых формируют модель жизненного цикла
программного средства.
8.3 Пример использования ГОСТ Р ИСО/МЭК 12207 в общей модели
жизненного цикла системы
На рисунке 7 основное внимание уделено использованию ГОСТ Р ИСО/МЭК
12207 в общей модели жизненного цикла гипотетической системы. Основным
назначением данного рисунка является сжатое представление метода
применения ГОСТ Р ИСО/МЭК 12207. В таблице 2 (см. 8.13) представлен состав
работ жизненного цикла системы и используемых процессов жизненного цикла
программного средства.
Организация может использовать ГОСТ Р ИСО/МЭК 12207 в любой работе
или в общей модели жизненного цикла самостоятельно, а также может
привлекать для этого (частично или полностью) поставщика соответствующих
продуктов или услуг.
+--------------+ +-----------------------+ +-----------+
¦ Начало ¦ - ¦ Демонстрация ¦ ¦
¦ ¦ ¦ +-----------------------+ ¦ +-------------------+
¦ ¦ ¦ ¦ Используют процессы ¦ ¦ ¦ Распространение и ¦
+------+-------+ ¦ ¦ заказа, поставки и ¦ ¦ ¦ продажа ¦
¦ ¦ разработки для ¦ ¦ ¦ ¦
+-------------------+ ¦ ¦определения требований ¦ ¦ ¦Используют процессы¦
¦ Определение ¦ ¦ ¦ к системе, системной ¦ ¦ ¦заказа, поставки и ¦
¦ потребностей ¦ ¦ ¦архитектуры и проектных¦ ¦ ¦ разработки для ¦
+-------------------+ ¦ ¦программных требований ¦ ¦ ¦ввода в действие и ¦
¦Используют процесс ¦ ¦ ¦ к элементам ¦ ¦ ¦настройки продуктов¦
¦заказа для принятия¦ ¦ ¦ (компонентам) ¦ ¦ +---------+---------+
¦ решения о ¦ ¦ ¦ программного средства ¦ ¦
¦ выполнимости ¦ ¦ +-----------+-----------+ ¦ +-------------------+
¦ технических, ¦ ¦ ¦ ¦ Эксплуатация ¦
¦эксплуатационных и ¦ ¦ +-----------------------+ ¦ +-------------------+
¦ экономических ¦ ¦ ¦ Разработка ¦ ¦ ¦Используют процессы¦
¦ требований ¦ ¦ +-----------------------+ ¦ ¦заказа, поставки и ¦
+---------+---------+ ¦ ¦ Используют процессы ¦ ¦ ¦ эксплуатации для ¦
¦ ¦ заказа и поставки для ¦ ¦ ¦ обеспечения ¦
+-------------------+ ¦ ¦ запуска процесса ¦ ¦ ¦ эксплуатационных ¦
¦Описание концепции ¦ ¦ ¦разработки. Используют ¦ ¦ ¦ услуг ¦
+-------------------+ ¦ ¦ процесс разработки ¦ ¦ +---------+---------+
¦Используют процессы¦ ¦ ¦ (полностью) для ¦ ¦
¦заказа, поставки и ¦ ¦ ¦создания, тестирования ¦ ¦ +-------------------+
¦ разработки для ¦ ¦ ¦ и сборки продукта ¦ ¦ ¦ Сопровождение и ¦
¦ определения ¦ ¦ +-----------+-----------+ ¦ ¦ поддержка ¦
¦ требований к ¦ ¦ ¦ +-------------------+
¦ проектированию ¦ ¦ +-----------------------+ ¦ ¦Используют процессы¦
¦ системы, к ¦ ¦ ¦ Изготовление ¦ ¦ ¦заказа, поставки и ¦
¦ прототипам ¦ ¦ +-----------------------+ ¦ ¦ сопровождения для ¦
¦ разработки и к ¦ ¦ ¦ Используют ¦ ¦ ¦сопровождения/под- ¦
¦ анализу обратной ¦ ¦ ¦ вспомогательные ¦ ¦ ¦ держки ¦
¦ связи с ¦ ¦ ¦процессы для контроля и¦ ¦ +---------+---------+
¦ пользователем в ¦ ¦ ¦ верификации ¦ ¦
¦ целях реализации ¦ ¦ ¦тиражируемых продуктов ¦ ¦ +-------------------+
¦ предложенных ¦ ¦ +-----------+-----------+ ¦ ¦ Снятие с ¦
¦ решений ¦ ¦ ¦ ¦ ¦ эксплуатации ¦
+---------+---------+ ¦ ¦ +-------------------+
¦ ¦ +-------------+ ¦Используют процессы¦
¦ ¦ заказа и ¦
------------+ ¦ сопровождения для ¦
¦ снятия с ¦
¦ эксплуатации ¦
+---------+---------+
+----------------+
¦ Конец ¦
+----------------+
Рисунок 7 - Использование ГОСТ Р ИСО/МЭК 12207
для обеспечения модели жизненного цикла системы
8.4 Определение потребностей
Во время данной работы выявляют и определяют замысел или потребность
в новой или усовершенствованной системе. Формулируют общие потребности с
учетом таких факторов, как стоимость, критичность и реализуемость
планируемой системы.
Процесс заказа может быть использован для установления
технологических или эксплуатационных возможностей системы до выполнения
исследований, разработки и привязки. Далее процесс разработки может быть
использован для создания программного средства, методов или моделей для
принятия соответствующих решений.
8.5 Исследование и определение концепции
Данная работа открывает период первоначального планирования, в
течение которого оценивают технические, стратегические и
рыночно-экономические аспекты системы путем всесторонних исследований,
опытной разработки и оценки ее концепции. Решения, предложенные для
реализации определенной потребности, могут быть однозначными или
альтернативными, разработанными на основе оценки возможностей, прикидок
(таких как стоимость, график работ, перспективы продажи,
интеллектуальность и логистика), изучения компромиссных вариантов и
проведения анализов. Выходными результатами данной работы, передаваемыми в
следующую работу, являются предварительные общие требования к системе и
возможные программные средства, выбранные в качестве прототипа. Процессы
заказа, поставки и разработки могут быть использованы для:
- помощи при установлении предварительных требований к системе;
- определения прототипов разработки;
- анализа и учета взаимодействий (обратной связи) с пользователем по
предложенным решениям.
Сам по себе процесс разработки может быть использован в качестве
метода для разработки программного средства, реализующего аналитические
или имитационные модели, необходимые при исследованиях и принятии
определенных решений.
8.6 Демонстрация и аттестация
При выполнении данной работы уточняют характеристики системы, ее
концепции и принятые решения, включая вычислительные ресурсы, используя
при этом методы системной инженерии, определяют предварительные требования
к программному средству и его прототипам, включая их тестирование и
аттестацию. Характеристики системы, а также выбранные концепции и решения
аттестуют для демонстрации того, что система, включая технические и
программные средства, пригодна для технологической разработки. Требования
к системе являются основой для дальнейшего их разбиения по компонентам
системы, таким как технические средства, компьютеры, программные средства
и персонал. Данные выходные результаты передают в следующую работу.
Процессы заказа, поставки и разработки могут быть использованы для
анализа и определения требований к системе, принятия общих проектных
решений по системе и предварительных требований для компонентов системы,
включая программные средства. Процесс разработки может быть использован в
качестве метода для анализа, демонстрации, аттестации, тестирования и
макетирования соответствующих требований и проектных решений.
8.7 Проектирование и разработка
Данная работа охватывает период проектирования, создания, интеграции
(сборки), тестирования и оценки системных технических средств,
компьютеров, программных средств, оборудования, персонала подсистем, его
обучения и объектов сопровождения. Выходными результатами данной работы
являются система, достаточно близкая к создаваемой, документы, необходимые
для последующей работы, и результаты тестирования качества создаваемой
системы.
При проведении данной работы полностью применим ГОСТ Р ИСО/МЭК 12207.
При этом для выполнения разработки или модернизации программного средства
должны быть выбраны, соответствующим образом адаптированы и использованы
процессы, работы и задачи из процессов заказа, поставки и разработки.
Данная работа может включать в себя однократное или многократное
использование процесса разработки, скоординированное с другими
компонентами системы. Результатами данной работы являются исходные
требования к программному средству, его проект и соответствующие
программы.
Если программное средство разрабатывают как часть системы, то должны
быть востребованы все работы процесса разработки. Дополнительно уточняют,
должен ли разработчик выполнять или обеспечивать работы, связанные с
системой. Если программное средство разрабатывают в виде автономного
продукта или продукта, не являющегося частью системы, тогда нет
необходимости в выполнении работ, связанных с системой, но их следует
учесть (предусмотреть).
8.8 Создание и производство
Во время данной работы спроектированную и разработанную систему
изготовляют для заказчика (пользователей) или рынка (потребителей). Период
создания охватывает работы от постановки на производство до поставки и
приемки системы. Целями данной работы являются квалифицированное
изготовление и поставка работоспособной и сопровождаемой системы заказчику
(пользователям). Период производства охватывает деятельность от постановки
на производство до перепроектирования или снятия системы с производства.
Целями данной работы являются квалифицированное производство и поставка
работоспособной и поддерживаемой системы потребителям (на рынок).
Для программных средств, по сравнению с техническими средствами,
работа по созданию и производству незначительна. Она состоит из
копирования (тиражирования) разработанного программного средства и
документов к нему на соответствующие носители для различных пользователей
(потребителей). (Конкретные задачи по реализации данной работы в ГОСТ Р
ИСО/МЭК 12207 не установлены.) В этом случае могут быть использованы
конкретные промышленные методы и соответствующие государственные акты. Для
контроля за выполнением указанных задач может быть использована работа по
управлению выпуском и поставкой из процесса управления конфигурацией.
Также могут быть использованы другие соответствующие работы, такие как
верификация сборки.
8.9 Распространение и продажа
При выполнении данной работы систему поставляют заказчику
(пользователям) или покупателям (на рынок). Период распространения
начинается с поставки первой работоспособной системы заказчику
(пользователям или сопровождающей организации). Период продажи охватывает
деятельность от поставки первой партии систем потребителям до изъятия
системы с рынка.
Процессы заказа, поставки и разработки могут быть использованы для
ввода в действие и наладки разработанного или модифицированного
программного средства.
8.10 Эксплуатация
Данная работа включает в себя эксплуатацию, применение или
использование системы пользователями (потребителями), заканчиваясь снятием
ее с эксплуатации.
Процессы заказа, поставки и эксплуатации могут быть использованы при
эксплуатации программного средства и обеспечении эксплуатационной
поддержки соответствующих пользователей.
8.11 Сопровождение и поддержка
При выполнении данной работы систему модифицируют, что связано с
наличием в ней ошибок, дефектов, возникновением проблем, появлением
запросов пользователей или появлением в данной организации потребностей в
ее адаптации или усовершенствовании. Данная работа включает в себя
предоставление логистической, технической и ремонтной поддержки
пользователям (или потребителям) системы.
Процессы заказа, поставки и сопровождения могут быть применены для
сопровождения программного средства и предоставления услуг по поддержке
системы в соответствующих организациях, у пользователей (потребителей).
При этом должны быть определены все взаимосвязи (интерфейсы) с
процессом разработки. В зависимости от важности решаемой проблемы могут
быть в разной степени применены работы из процесса разработки (в
зависимости от конкретной ситуации).
8.12 Снятие с эксплуатации (утилизация)
В этот период систему снимают с обслуживания. Данная работа включает
в себя архивирование снимаемой системы и обеспечение ограниченной
поддержки ее пользователей в данный период.
Процесс заказа и работа по снятию с эксплуатации из процесса
сопровождения могут быть использованы при снятии с эксплуатации
программного средства и обеспечении услуг по поддержке системы в данный
конкретный период в организациях, у пользователей (потребителей).
8.13 Процессы жизненного цикла программного средства в общей модели
жизненного цикла системы
В таблице 2 приведен пример распределения процессов жизненного цикла
программного средства по периодам жизненного цикла системы. Показаны
только основные процессы из ГОСТ Р ИСО/МЭК 12207. Вспомогательные или
организационные процессы должны быть использованы через основные процессы.
Буквой "П" обозначено использование процесса из ГОСТ Р ИСО/МЭК 12207, а
буквой "М" - использование соответствующего метода. Обозначение "(П)" или
"(М)" указывает на возможность использования соответствующего процесса или
метода.
Таблица 2 - Процессы жизненного цикла программного средства в общей
модели жизненного цикла системы
+----------------------------------------+----------------------------------------------------------+
¦ Периоды жизненного цикла системы ¦ Процессы жизненного цикла программного средства ¦
¦ +-----------+----------+-----------+-----------+-----------+
¦ ¦ Заказ ¦ Поставка ¦Разработка ¦Эксплуата- ¦Сопровожде-¦
¦ ¦ ¦ ¦ ¦ ция ¦ ние ¦
+----------------------------------------+-----------+----------+-----------+-----------+-----------+
¦Определение потребностей ¦ ¦ ¦ ¦ (-) ¦ ¦ ¦
¦ ¦ ¦ ¦ ¦ ¦ ¦
+----------------------------------------+-----------+----------+-----------+-----------+-----------+
¦Исследование и определение концепции ¦ ¦ ¦ (¦) ¦ (¦), -- ¦ ¦ ¦
¦ ¦ ¦ ¦ ¦ ¦ ¦
+----------------------------------------+-----------+----------+-----------+-----------+-----------+
¦Демонстрация и аттестация ¦ ¦ ¦ ¦ ¦ ¦, -- ¦ ¦ ¦
¦ ¦ ¦ ¦ ¦ ¦ ¦
+----------------------------------------+-----------+----------+-----------+-----------+-----------+
¦Проектирование и разработка ¦ ¦ ¦ ¦ ¦ ¦, -- ¦ ¦ ¦
¦ ¦ ¦ ¦ ¦ ¦ ¦
+----------------------------------------+-----------+----------+-----------+-----------+-----------+
¦Создание и производство ¦ ¦ ¦ ¦ ¦ ¦
¦ ¦ ¦ ¦ ¦ ¦ ¦
+----------------------------------------+-----------+----------+-----------+-----------+-----------+
¦Распространение и продажа ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
¦ ¦ ¦ ¦ ¦ ¦ ¦
+----------------------------------------+-----------+----------+-----------+-----------+-----------+
¦Эксплуатация ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
¦ ¦ ¦ ¦ ¦ ¦ ¦
+----------------------------------------+-----------+----------+-----------+-----------+-----------+
¦Сопровождение и поддержка ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
¦ ¦ ¦ ¦ ¦ ¦ ¦
+----------------------------------------+-----------+----------+-----------+-----------+-----------+
¦Снятие с эксплуатации ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
¦ ¦ ¦ ¦ ¦ ¦ ¦
+----------------------------------------+-----------+----------+-----------+-----------+-----------+
______________________________
* Оригиналы международных стандартов ИСО/МЭК - во ВНИИКИ Госстандарта
России.
Приложение А
(справочное)
Процессы качества и требования к оценке
Вспомогательные процессы жизненного цикла, связанные с качеством
программного средства, показаны в сгруппированном виде, выделенном серым
фоном, на рисунке 1 в ГОСТ Р ИСО/МЭК 12207. Такими процессами являются:
- обеспечение качества;
- верификация;
- аттестация (валидация);
- совместный анализ;
- аудит.
При реализации каждого из основных процессов могут быть привлечены не
только вышеперечисленные вспомогательные процессы, связанные с
деятельностью по оценке или аттестации, но также и дополнительные задачи
по оценке, за решение которых персонально отвечает определенное лицо.
Такие дополнительные задачи предназначены для последовательного повышения
качества выполнения других задач, работ и процессов. В некоторых проектах
подобный метод может привести к дублированию работ или выполнению большего
объема работ, чем необходимо, для создания высококачественного продукта.
Для других проектов, таких как критичные оборонные проекты, необходимы все
процессы, работы и задачи по проведению соответствующих оценок. Поэтому
ключевым моментом использования ГОСТ Р ИСО/МЭК 12207 является адаптация
процессов, связанных с качеством, проведенная до начала реализации
проекта, а также распределение ролей данных конкретных процессов,
реализуемых в проекте. ГОСТ Р ИСО/МЭК 12207 формулирует эту важную задачу
в виде подготовки плана обеспечения качества, подкрепленного, при
необходимости, другими связанными с ним планами, такими как планы
верификации и аттестации.
Применение задач, связанных с качеством, может привести к объединению
конкретных задач или выполнению обязанностей, связанных с качеством,
другими задачами. Например, в малых проектах по разработке управляющей
информационной системы, используемой внутри компании, план обеспечения
качества должен допускать проведение верификации и аттестации группой
проектантов и предусматривать элементарный процесс управления анализом.
Для большой критичной оборонной системы, разрабатываемой для заказчика, в
ее проекте должны быть запланированы независимые группы по верификации и
аттестации, а также совместные анализы и аудиторские проверки. В этом
случае решающую роль играют объем и сложность проекта вместе с уровнем
интеграции создаваемого приложения или системы.
В таблице А.1 показаны требования, связанные с оценками продуктов,
услуг и процессов. В соответствующей работе жизненного цикла проекта или
процесса эксперт должен оценить либо программные продукты и услуги самой
организации, либо сторонние программные продукты или услуги. В ГОСТ Р
ИСО/МЭК 12207 данные оценки сгруппированы в пять нижеперечисленных типов
(см. таблицу А.1). Первые четыре типа оценок реализуют на проектном
уровне, а последний - на уровне организации. Данные оценки должны быть
выбраны и адаптированы пропорционально области применения, важности,
сложности и критичности проекта (или стратегии) и потребностям
организации. Отчеты о проблемах, несоответствиях или необходимых
усовершенствованиях, полученные в результате оценок, передают в процесс
решения проблем.
Таблица А.1 - Требования к оценкам продуктов, услуг и процессов
+-------------+--------------+-------------+-------------+--------------+
¦ Тип оценки ¦ Пункт ГОСТ Р ¦ Назначение ¦ Исполнитель ¦ Примечание ¦
¦ ¦ИСО/МЭК 12207 ¦ ¦ ¦ ¦
+-------------+--------------+-------------+-------------+--------------+
¦Оценки внутри¦ 5.1-5.5 ¦Ежедневная ¦Персонал, ¦ ¦
¦процесса ¦ ¦работа ¦выполняющий ¦ ¦
¦ ¦ ¦ ¦задачи по¦ ¦
¦ ¦ ¦ ¦оценке в¦ ¦
¦ ¦ ¦ ¦процессе ¦ ¦
+-------------+--------------+-------------+-------------+--------------+
¦Обеспечение ¦ 6.3 ¦Независимое ¦Персонал, ¦Можно ¦
¦качества ¦ ¦подтверждение¦организацион-¦использовать ¦
¦ ¦ ¦соответствия ¦но ¦результаты ¦
¦ ¦ ¦программных ¦независимый ¦других работ в¦
¦ ¦ ¦продуктов и¦от тех, кто¦качестве ¦
¦ ¦ ¦услуг ¦отвечает за¦исходных ¦
¦ ¦ ¦требованиям ¦разработку ¦данных. Можно¦
¦ ¦ ¦договора и¦программного ¦скоординиро- ¦
¦ ¦ ¦соблюдения ¦средства ¦вать данные¦
¦ ¦ ¦установленных¦ ¦работы с¦
¦ ¦ ¦планов ¦ ¦другими ¦
¦ ¦ ¦ ¦ ¦работами по¦
¦ ¦ ¦ ¦ ¦оценке ¦
+-------------+--------------+-------------+-------------+--------------+
¦Верификация и¦ 6.4 и 6.5 ¦Верификация и¦Заказчик, ¦Можно не¦
¦аттестация ¦ ¦аттестация ¦поставщик, ¦дублировать ¦
¦(валидация) ¦ ¦продуктов с¦разработчик, ¦или заменять¦
¦ ¦ ¦различной ¦оператор, ¦другими ¦
¦ ¦ ¦степенью ¦персонал по¦оценками, т.е.¦
¦ ¦ ¦зависимости ¦сопровождению¦данные оценки¦
¦ ¦ ¦от проекта ¦или ¦дополнительны ¦
¦ ¦ ¦ ¦независимый ¦ ¦
¦ ¦ ¦ ¦персонал, или¦ ¦
¦ ¦ ¦ ¦третья ¦ ¦
¦ ¦ ¦ ¦сторона ¦ ¦
+-------------+--------------+-------------+-------------+--------------+
¦Совместные ¦ 6.6 и 6.7 ¦Оценка ¦Оценивающая ¦ - ¦
¦анализы и¦ ¦состояний и¦сторона ¦ ¦
¦аудиторские ¦ ¦завершенности¦(аналитик или¦ ¦
¦проверки ¦ ¦продуктов и¦аудитор) и¦ ¦
¦ ¦ ¦работ по¦оцениваемая ¦ ¦
¦ ¦ ¦согласованным¦сторона ¦ ¦
¦ ¦ ¦графикам ¦(анализируе- ¦ ¦
¦ ¦ ¦ ¦мая или¦ ¦
¦ ¦ ¦ ¦проверяемая) ¦ ¦
¦ ¦ ¦ ¦совместно ¦ ¦
+-------------+--------------+-------------+-------------+--------------+
¦Оценка и¦ 7.3 ¦Эффективное ¦Администратор¦ - ¦
¦усовершенст- ¦ ¦управление и¦ ¦ ¦
¦вование ¦ ¦самоусоверше-¦ ¦ ¦
¦ ¦ ¦нствование ¦ ¦ ¦
+-------------+--------------+-------------+-------------+--------------+
Приложение В
(справочное)
Классификация выходных результатов процессов
В настоящем приложении определены выходные результаты процессов (см.
таблицы В.1 - В.4), которые должны быть документально оформлены в
соответствии с требованиями или рекомендациями ГОСТ Р ИСО/МЭК 12207.
Перечислены только те пункты ГОСТ Р ИСО/МЭК 12207, по которым требуются
выходные результаты. Документы по данным выходным результатам должны быть
выбраны и скомплектованы пропорционально области применения, значимости,
сложности и критичности проекта или организации. В графе "Выходные
результаты" таблицы В.1 наименования или заголовки соответствующих
документов не указаны.
Таблица В.1 - Выходные результаты основных процессов жизненного цикла
+----------+-------------+---------------------------+------------------+
¦ Процесс ¦Пункт ГОСТ Р ¦ Выходные результаты ¦ Тип выходного ¦
¦ ¦ИСО/МЭК 12207¦ ¦ результата ¦
+----------+-------------+---------------------------+------------------+
¦Заказ ¦ 5.1.1.8 ¦План заказа ¦План ¦
¦ +-------------+---------------------------+------------------+
¦ ¦ 5.1.1.9 ¦Стратегия и условия заказа ¦Описание ¦
¦ +-------------+---------------------------+------------------+
¦ ¦ 5.1.2.1 ¦Заявка на подряд (тендер) ¦Описание ¦
¦ +-------------+---------------------------+------------------+
¦ ¦ 5.1.2.1 ¦Документы по заказу ¦Описание ¦
¦ +-------------+---------------------------+------------------+
¦ ¦ 5.1.3.1 ¦Процедура выбора поставщика¦Процедура ¦
¦ +-------------+---------------------------+------------------+
¦ ¦ 5.1.3.4 ¦Договор ¦Договор ¦
+----------+-------------+---------------------------+------------------+
¦Поставка ¦ 5.2.2.1 ¦Предложение ¦Предложение ¦
¦ +-------------+---------------------------+------------------+
¦ ¦ 5.2.4.5 ¦План(ы) управления проектом¦План ¦
¦ +-------------+---------------------------+------------------+
¦ ¦ 5.2.6.4 ¦Отчеты о проведенных¦Отчет ¦
¦ ¦ ¦оценках, анализах,¦ ¦
¦ ¦ ¦аудиторских проверках,¦ ¦
¦ ¦ ¦испытаниях и реализованных¦ ¦
¦ ¦ ¦решениях возникших проблем ¦ ¦
+----------+-------------+---------------------------+------------------+
¦Разработка¦ 5.3.1.2 ¦Протоколы о проблемах и¦Протокол ¦
¦ ¦ ¦несоответствиях ¦ ¦
¦ +-------------+---------------------------+------------------+
¦ ¦ 5.3.1.4 ¦Планы разработки ¦План ¦
¦ +-------------+---------------------------+------------------+
¦ ¦ 5.3.2.1 ¦Технические требования¦Описание ¦
¦ ¦ ¦(спецификация) к системе ¦ ¦
¦ +-------------+---------------------------+------------------+
¦ ¦ 5.3.3.1 ¦Документ по архитектуре¦Описание ¦
¦ ¦ ¦системы ¦ ¦
¦ +-------------+---------------------------+------------------+
¦ ¦ 5.3.3.1 ¦Документ на привязку к¦Описание ¦
¦ ¦ ¦объектам системы ¦ ¦
¦ +-------------+---------------------------+------------------+
¦ ¦ 5.3.4.1 ¦Технические требования к¦Описание ¦
¦ ¦ ¦программному средству ¦ ¦
¦ +-------------+---------------------------+------------------+
¦ ¦ 5.3.4.2 ¦Результаты оценки¦Протокол ¦
¦ ¦ ¦технических требований к¦ ¦
¦ ¦ ¦программному средству ¦ ¦
¦ +-------------+---------------------------+------------------+
¦ ¦ 5.3.5.1 ¦Объект программной¦Программное ¦
¦ ¦ ¦конфигурации ¦средство ¦
¦ +-------------+---------------------------+------------------+
¦ ¦ 5.3.5.1 ¦Требования к архитектуре¦Описание ¦
¦ ¦ ¦(эскизный проект) ¦ ¦
¦ +-------------+---------------------------+------------------+
¦ ¦ 5.3.5.2 ¦Требования к интерфейсам¦Описание ¦
¦ ¦ ¦программного средства¦ ¦
¦ ¦ ¦(эскизный проект) ¦ ¦
¦ +-------------+---------------------------+------------------+
¦ ¦ 5.3.5.3 ¦Эскизный проект базы данных¦Описание ¦
¦ +-------------+---------------------------+------------------+
¦ ¦ 5.3.5.4 ¦Руководство(а) пользователя¦Руководство ¦
¦ +-------------+---------------------------+------------------+
¦ ¦ 5.3.5.5 ¦Требования к испытанию¦Описание ¦
¦ ¦ ¦(тестированию) программного¦ ¦
¦ ¦ ¦средства ¦ ¦
¦ +-------------+---------------------------+------------------+
¦ ¦ 5.3.5.6 ¦Анализ проекта ¦Протокол ¦
+----------+-------------+---------------------------+------------------+
¦Разработка¦ 5.3.6.1 ¦Технический проект ¦Описание ¦
¦ +-------------+---------------------------+------------------+
¦ ¦ 5.3.6.2 ¦Уточненные требования к¦Описание ¦
¦ ¦ ¦интерфейсам программного¦ ¦
¦ ¦ ¦средства (технический¦ ¦
¦ ¦ ¦проект) ¦ ¦
¦ +-------------+---------------------------+------------------+
¦ ¦ 5.3.6.3 ¦Технический проект базы¦Описание ¦
¦ ¦ ¦данных ¦ ¦
¦ +-------------+---------------------------+------------------+
¦ ¦ 5.3.6.5 ¦Требования к тестированию¦Описание ¦
¦ ¦ ¦программных модулей ¦ ¦
¦ +-------------+---------------------------+------------------+
¦ ¦ 5.3.6.7 ¦Анализ технического проекта¦Протокол ¦
¦ +-------------+---------------------------+------------------+
¦ ¦ 5.3.7.1 ¦Программные модули и базы¦Программные ¦
¦ ¦ ¦данных ¦средства ¦
¦ +-------------+---------------------------+------------------+
¦ ¦ 5.3.7.1 ¦Процедура испытаний¦Процедура ¦
¦ ¦ ¦(тестирования) ¦ ¦
¦ +-------------+---------------------------+------------------+
¦ ¦ 5.3.7.2 ¦Результаты тестирования¦Протокол ¦
¦ ¦ ¦программных модулей ¦ ¦
¦ +-------------+---------------------------+------------------+
¦ ¦ 5.3.7.5 ¦Анализ результатов¦Протокол ¦
¦ ¦ ¦программирования и¦ ¦
¦ ¦ ¦тестирования ¦ ¦
¦ +-------------+---------------------------+------------------+
¦ ¦ 5.3.8.1 ¦План сборки программного¦План ¦
¦ ¦ ¦средства ¦ ¦
¦ +-------------+---------------------------+------------------+
¦ ¦ 5.3.8.2 ¦Результаты сборки и¦Протокол ¦
¦ ¦ ¦тестирования программного¦ ¦
¦ ¦ ¦средства ¦ ¦
¦ +-------------+---------------------------+------------------+
¦ ¦ 5.3.8.5 ¦Анализ плана сборки и¦Протокол ¦
¦ ¦ ¦документирования ¦ ¦
¦ ¦ ¦программного средства ¦ ¦
¦ +-------------+---------------------------+------------------+
¦ ¦ 5.3.9.1 ¦Результаты квалификационных¦Протокол ¦
¦ ¦ ¦испытаний (тестирования)¦ ¦
¦ ¦ ¦объекта программной¦ ¦
¦ ¦ ¦конфигурации ¦ ¦
¦ +-------------+---------------------------+------------------+
¦ ¦ 5.3.9.3 ¦Анализ сборки программного¦Протокол ¦
¦ ¦ ¦средства ¦ ¦
¦ +-------------+---------------------------+------------------+
¦ ¦ 5.3.9.4 ¦Аудиторская проверка сборки¦Протокол ¦
¦ ¦ ¦программного средства ¦ ¦
¦ +-------------+---------------------------+------------------+
¦ ¦ 5.3.10.1 ¦Результаты сборки и¦Протокол ¦
¦ ¦ ¦испытания системы ¦ ¦
¦ +-------------+---------------------------+------------------+
¦ ¦ 5.3.10.2 ¦Требования к¦Описание ¦
¦ ¦ ¦квалификационным испытаниям¦ ¦
¦ ¦ ¦системы ¦ ¦
¦ +-------------+---------------------------+------------------+
¦ ¦ 5.3.10.3 ¦Анализ квалификационного¦Протокол ¦
¦ ¦ ¦испытания системы ¦ ¦
¦ +-------------+---------------------------+------------------+
¦ ¦ 5.3.11.1 ¦Результаты квалификационных¦Протокол ¦
¦ ¦ ¦испытаний системы ¦ ¦
¦ +-------------+---------------------------+------------------+
¦ ¦ 5.3.11.3 ¦Результаты аудиторских¦Протокол ¦
¦ ¦ ¦проверок системы ¦ ¦
¦ +-------------+---------------------------+------------------+
¦ ¦ 5.3.12.1 ¦План по вводу в действие¦План ¦
¦ ¦ ¦программного средства ¦ ¦
¦ +-------------+---------------------------+------------------+
¦ ¦ 5.3.12.2 ¦Реализация и результаты¦Протокол ¦
¦ ¦ ¦ввода в действие¦ ¦
¦ ¦ ¦программного средства ¦ ¦
¦ +-------------+---------------------------+------------------+
¦ ¦ 5.3.13.1 ¦Готовность к приемке и¦Протокол ¦
¦ ¦ ¦приемочные испытания¦ ¦
¦ ¦ ¦программного средства ¦ ¦
+----------+-------------+---------------------------+------------------+
¦Эксплуата-¦ 5.4.1.1 ¦План эксплуатации ¦План ¦
¦ция ¦ ¦ ¦ ¦
¦ +-------------+---------------------------+------------------+
¦ ¦ 5.4.1.2 ¦Процедура подготовки¦Процедура ¦
¦ ¦ ¦отчетов по проблеме ¦ ¦
¦ +-------------+---------------------------+------------------+
¦ ¦ 5.4.1.2 ¦Отчетность по проблеме ¦Протокол ¦
¦ +-------------+---------------------------+------------------+
¦ ¦ 5.4.1.3 ¦Процедура тестирования в¦Процедура ¦
¦ ¦ ¦эксплуатационной среде ¦ ¦
+----------+-------------+---------------------------+------------------+
¦Сопровож- ¦ 5.5.1.1 ¦План сопровождения ¦План ¦
¦дение ¦ ¦ ¦ ¦
¦ +-------------+---------------------------+------------------+
¦ ¦ 5.5.1.1 ¦Процедура сопровождения ¦Процедура ¦
¦ +-------------+---------------------------+------------------+
¦ ¦ 5.5.1.2 ¦Процедуры описания проблемы¦Процедура ¦
¦ ¦ ¦и реализации заявки на¦ ¦
¦ ¦ ¦внесение изменений ¦ ¦
¦ +-------------+---------------------------+------------------+
¦ ¦ 5.5.2.4 ¦Протокол фиксации сообщения¦Протокол ¦
¦ ¦ ¦о проблеме или заявки на¦ ¦
¦ ¦ ¦внесение изменения ¦ ¦
¦ +-------------+---------------------------+------------------+
¦ ¦ 5.5.3.1 ¦Протоколы внесения¦Протокол ¦
¦ ¦ ¦изменений ¦ ¦
¦ +-------------+---------------------------+------------------+
¦ ¦ 5.5.3.2 ¦Результаты тестирования¦Протокол ¦
¦ ¦ ¦внесенных изменений ¦ ¦
¦ +-------------+---------------------------+------------------+
¦ ¦ 5.5.5.2 ¦План переноса программного¦План ¦
¦ ¦ ¦средства ¦ ¦
¦ +-------------+---------------------------+------------------+
¦ ¦ 5.5.6.1 ¦План снятия с эксплуатации ¦План ¦
+----------+-------------+---------------------------+------------------+
Таблица В.2 - Выходные результаты вспомогательных процессов жизненного
цикла
+-------------+-------------+----------------------------+--------------+
¦ Процесс ¦Пункт ГОСТ Р ¦ Выходные результаты ¦Тип выходного ¦
¦ ¦ИСО/МЭК 12207¦ ¦ результата ¦
+-------------+-------------+----------------------------+--------------+
¦Документиро- ¦ 6.1.1.1 ¦План документирования ¦План ¦
¦вание ¦ ¦ ¦ ¦
+-------------+-------------+----------------------------+--------------+
¦Управление ¦ 6.2.1.1 ¦План управления¦План ¦
¦конфигурацией¦ ¦конфигурацией ¦ ¦
¦ +-------------+----------------------------+--------------+
¦ ¦ 6.2.4.1 ¦Отчеты и протоколы по¦Протокол ¦
¦ ¦ ¦управлению конфигурацией ¦ ¦
+-------------+-------------+----------------------------+--------------+
¦Обеспечение ¦ 6.3.1.3 ¦План обеспечения качества ¦План ¦
¦качества ¦ ¦ ¦ ¦
¦ +-------------+----------------------------+--------------+
¦ ¦ 6.3.1.4 ¦Протоколы по обеспечению¦Протокол ¦
¦ ¦ ¦качества ¦ ¦
+-------------+-------------+----------------------------+--------------+
¦Верификация ¦ 6.4.1.5 ¦План верификации ¦План ¦
+-------------+-------------+----------------------------+--------------+
¦Аттестация ¦ 6.5.1.4 ¦План аттестации ¦План ¦
+-------------+-------------+----------------------------+--------------+
¦Совместный ¦ 6.6.1.4 ¦Результаты совместного¦Протокол ¦
¦анализ ¦ ¦анализа ¦ ¦
+-------------+-------------+----------------------------+--------------+
¦Аудит ¦ 6.7.1.5 ¦Результаты аудиторских¦Протокол ¦
¦ ¦ ¦проверок ¦ ¦
+-------------+-------------+----------------------------+--------------+
¦Решение ¦ 6.8.1.1 ¦Отчет о проблеме ¦Протокол ¦
¦проблем ¦ ¦ ¦ ¦
+-------------+-------------+----------------------------+--------------+
Таблица В.3 - Выходные результаты организационных процессов жизненного
цикла
+-------------+-------------+----------------------------+--------------+
¦ Процесс ¦Пункт ГОСТ Р ¦ Выходные результаты ¦Тип выходного ¦
¦ ¦ИСО/МЭК 12207¦ ¦ результата ¦
+-------------+-------------+----------------------------+--------------+
¦Управление ¦ 7.1.2.1 ¦План управления ¦План ¦
¦ +-------------+----------------------------+--------------+
¦ ¦ 7.1.3.3 ¦Анализы проблем ¦Отчет ¦
+-------------+-------------+----------------------------+--------------+
¦Создание ¦ 7.2.1.2 ¦План создания инфраструктуры¦План ¦
¦инфраструкту-+-------------+----------------------------+--------------+
¦ры ¦ 7.2.2.1 ¦Конфигурация инфраструктуры ¦Описание ¦
+-------------+-------------+----------------------------+--------------+
¦Усовершенст- ¦ 7.3.1.1 ¦Процедуры организационных¦Процедура ¦
¦вование ¦ ¦процессов ¦ ¦
¦ +-------------+----------------------------+--------------+
¦ ¦ 7.3.2.1 ¦Процедура оценки процесса ¦Процедура ¦
+-------------+-------------+----------------------------+--------------+
¦Обучение ¦ 7.4.1.1 ¦План обучения ¦План ¦
¦ +-------------+----------------------------+--------------+
¦ ¦ 7.4.3.1 ¦Протоколы об обучении ¦Протокол ¦
+-------------+-------------+----------------------------+--------------+
Процесс адаптации из приложения А к ГОСТ Р ИСО/МЭК 12207 используют
как дополнительный. В случае применения данный процесс должен иметь
следующие выходные результаты (таблица В.4).
Таблица В.4 - Выходные результаты процесса адаптации
+------------+--------------+----------------------------+--------------+
¦ Процесс ¦ Пункт ГОСТ Р ¦ Выходные результаты ¦Тип выходного ¦
¦ ¦ИСО/МЭК 12207 ¦ ¦ результата ¦
+------------+--------------+----------------------------+--------------+
¦Адаптация ¦ А.4.1 ¦Принятые решения по¦Протокол ¦
¦ ¦ ¦адаптации и их обоснования ¦ ¦
+------------+--------------+----------------------------+--------------+
Приложение С
(справочное)
Модели жизненного цикла
Существует множество моделей жизненного цикла, но три из них -
фундаментальные. Этими фундаментальными моделями жизненного цикла
являются:
- каскадная;
- инкрементная;
- эволюционная.
Каждая из указанных моделей может быть использована самостоятельно
или скомбинирована с другими для создания гибридной модели жизненного
цикла. При этом конкретную модель жизненного цикла следует выбирать так,
чтобы процессы, работы и задачи из ГОСТ Р ИСО/МЭК 12207 были связаны между
собой и определены их взаимосвязи с предшествующими процессами, работами
(видами деятельности) и задачами (заданиями).
В настоящем приложении описаны три фундаментальные модели жизненного
цикла с присущими им недостатками (аргументами против их применения) и
преимуществами (выгодами). Эти недостатки и преимущества должны быть
учтены при выборе модели жизненного цикла для проекта.
С.1 Каскадная модель
Каскадная модель жизненного цикла по существу реализует принцип
однократного выполнения каждого из следующих видов деятельности в их
естественных границах:
- установление потребностей пользователя;
- определение требований;
- проектирование системы;
- изготовление системы;
- испытание;
- корректировка;
- поставка или использование.
При применении такого принципа разработки каждого программного
объекта соответствующие работы и задачи процесса разработки обычно
выполняют последовательно (см. рисунок С.1). Однако они могут быть
частично выполнены параллельно в случаях перекрытия последовательных
работ.
Когда несколько программных объектов разрабатывают одновременно, для
всех этих объектов работы и задачи процесса разработки могут быть
выполнены параллельно. Процессы сопровождения и эксплуатации обычно
реализуют после процесса разработки. Процессы заказа и поставки, а также
вспомогательные и организационные процессы обычно выполняют параллельно с
процессом разработки.
С.1.1 Недостатки
Данной модели присущи следующие недостатки, которые необходимо
учитывать при оценке возможности ее применения:
a) требования к объектам определены недостаточно четко;
b) система обычно слишком велика, чтобы все работы по ее созданию
выполнять однократно;
c) предполагаемые скорые изменения в технологиях работ;
d) возможные текущие изменения требований к системе;
e) ограниченность ресурсов, например средств или персонала;
f) промежуточный продукт может быть непригоден для использования.
"Рис. С.1. Пример каскадной модели"
С.1.2 Преимущества
Преимущества использования данной модели:
a) однократное представление всех возможностей (характеристик)
системы;
b) необходимость только единственной фазы перехода от старой системы
к новой.
С.2 Инкрементная модель
Инкрементная модель жизненного цикла, называемая также
запланированным усовершенствованием продукта, начинается с выдачи набора
требований и реализует разработку последовательности конструкций. Первая
конструкция содержит часть требований, в последующую конструкцию добавляют
дополнительные требования и так далее до тех пор, пока не будет закончено
создание системы. Для каждой конструкции выполняют необходимые процессы,
работы и задачи, например анализ требований и создание архитектуры могут
быть выполнены сразу, в то время как разработку технического проекта
программного средства, его программирование и тестирование, сборку
программных средств и их квалификационные испытания выполняют при создании
каждой из последующих конструкций.
В данной модели при разработке каждой конструкции работы и задачи
процесса разработки выполняют последовательно или частично параллельно с
перекрытием. При частично одновременной разработке последовательных
конструкций работы и задачи процесса разработки могут быть выполнены
параллельно для ряда конструкций.
Работы и задачи процесса разработки обычно выполняют многократно в
той же последовательности для всех конструкций. Процессы сопровождения и
эксплуатации могут быть реализованы параллельно с процессом разработки.
Процессы заказа и поставки, а также вспомогательные и организационные
процессы обычно выполняют параллельно с процессом разработки (рисунок
С.2).
С.2.1 Недостатки
Данной модели присущи следующие недостатки, которые необходимо
учитывать при оценке возможности ее применения:
а) требования к объектам определены недостаточно четко;
"Рис. С.2. Пример инкрементной модели"
b) предусмотрены сразу все возможности системы;
c) предполагаемые скорые изменения в технологиях работ;
d) возможные текущие изменения требований к системе;
e) привлечение ресурсов (средств или персонала) на длительный период
ограничено.
С.2.2 Преимущества
Преимущества использования данной модели:
a) необходимость изначального использования характеристик системы;
b) пригодность для использования промежуточного продукта;
c) естественное разделение системы на наращиваемые компоненты
(инкременты);
d) возможности наращивания привлекаемого персонала и средств.
С.3 Эволюционная модель
В эволюционной модели жизненного цикла систему также разрабатывают в
виде отдельных конструкций, но в отличие от инкрементной модели требования
изначально не могут быть полностью осознаны и установлены. В данной модели
требования устанавливают частично и уточняют в каждой последующей
конструкции (рисунок С.3).
При таком методе для каждой конструкции работы и задачи процесса
разработки выполняют последовательно или параллельно с частичным
перекрытием.
Работы и задачи процесса разработки обычно выполняют многократно в
той же последовательности для всех конструкций. Процессы сопровождения и
эксплуатации могут быть реализованы параллельно с процессом разработки.
Процессы заказа и поставки, а также вспомогательные и организационные
процессы обычно выполняют параллельно с процессом разработки.
В таблице С.1 показано, как могут быть распределены процессы в модели
жизненного цикла программного средства при создании ее для эволюционного
жизненного цикла. В таблице С.1 учтены только работы процесса разработки.
Отмеченные знаком "." объекты указывают на конкретную работу или задачу, а
горизонтальные строки представляют собой шкалу времени. При необходимости
может быть проведена дальнейшая детализация распределения процессов.
"Рис. С.3. Пример эволюционной модели"
Таблица С.1 - Пример разметки эволюционной разработки
+--------------+------------------------------------------------------------------------------------------------+
¦Процесс/работа¦ Шкала времени ¦
¦ / задача ¦ ¦
+--------------+---+---+--+---+--+---+--+---+---+--+---+--+---+---+--+---+--+---+---+--+---+--+---+---+--+---+--+
¦Реализация ¦ - ¦ - ¦ ¦ ¦ ¦ ¦ ¦ ¦ - ¦- ¦ ¦ ¦ ¦ ¦ ¦ ¦- ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
¦процесса ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
+--------------+---+---+--+---+--+---+--+---+---+--+---+--+---+---+--+---+--+---+---+--+---+--+---+---+--+---+--+
¦Анализ ¦ ¦ - ¦- ¦ - ¦ ¦ ¦ ¦ ¦ ¦- ¦ - ¦ ¦ ¦ ¦ ¦ ¦ ¦ - ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
¦требований к ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
¦системе и ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
¦программному ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
¦средству ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
+--------------+---+---+--+---+--+---+--+---+---+--+---+--+---+---+--+---+--+---+---+--+---+--+---+---+--+---+--+
¦Архитектурный ¦ ¦ ¦- ¦ - ¦- ¦ ¦ ¦ ¦ ¦ ¦ - ¦- ¦ ¦ ¦ ¦ ¦ ¦ ¦ - ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
¦(эскизный) ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
¦проект системы¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
¦и программного¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
¦средства ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
+--------------+---+---+--+---+--+---+--+---+---+--+---+--+---+---+--+---+--+---+---+--+---+--+---+---+--+---+--+
¦Технический ¦ ¦ ¦ ¦ - ¦- ¦ - ¦ ¦ ¦ ¦ ¦ ¦- ¦ - ¦ ¦ ¦ ¦ ¦ ¦ ¦- ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
¦проект ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
¦программного ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
¦средства ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
+--------------+---+---+--+---+--+---+--+---+---+--+---+--+---+---+--+---+--+---+---+--+---+--+---+---+--+---+--+
¦Программирова-¦ ¦ ¦ ¦ ¦- ¦ - ¦- ¦ ¦ ¦ ¦ ¦ ¦ - ¦ - ¦ ¦ ¦ ¦ ¦ ¦ ¦ - ¦ ¦ ¦ ¦ ¦ ¦ ¦
¦ние и ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
¦тестирование ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
¦программного ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
¦средства ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
+--------------+---+---+--+---+--+---+--+---+---+--+---+--+---+---+--+---+--+---+---+--+---+--+---+---+--+---+--+
¦Сборка и ¦ ¦ ¦ ¦ ¦ ¦ - ¦- ¦ - ¦ ¦ ¦ ¦ ¦ ¦ - ¦- ¦ ¦ ¦ ¦ ¦ ¦ ¦- ¦ ¦ ¦ ¦ ¦ ¦
¦квалификацион-¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
¦ные испытания ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
¦программного ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
¦средства ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
+--------------+---+---+--+---+--+---+--+---+---+--+---+--+---+---+--+---+--+---+---+--+---+--+---+---+--+---+--+
¦Сборка и ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ - ¦ - ¦- ¦ ¦ ¦ ¦ ¦- ¦ - ¦ ¦ ¦ ¦ ¦ ¦ ¦ - ¦ ¦ ¦ ¦ ¦
¦квалификацион-¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
¦ные испытания ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
¦системы ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
+--------------+---+---+--+---+--+---+--+---+---+--+---+--+---+---+--+---+--+---+---+--+---+--+---+---+--+---+--+
¦Ввод в ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ - ¦ - ¦- ¦ ¦ ¦ ¦ ¦ ¦ - ¦- ¦ ¦ ¦ ¦ ¦ ¦ ¦ - ¦ ¦ ¦ ¦
¦действие и ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
¦обеспечение ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
¦приемки ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
¦программного ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
¦средства ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
+--------------+---+---+--+---+--+---+--+---+---+--+---+--+---+---+--+---+--+---+---+--+---+--+---+---+--+---+--+
¦Процесс ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦- ¦ - ¦- ¦ - ¦ - ¦- ¦ - ¦- ¦-- ¦ - ¦- ¦ - ¦- ¦ - ¦ - ¦- ¦ - ¦- ¦
¦эксплуатации ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
+--------------+---+---+--+---+--+---+--+---+---+--+---+--+---+---+--+---+--+---+---+--+---+--+---+---+--+---+--+
¦Процесс ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦- ¦ - ¦- ¦ - ¦ - ¦- ¦ - ¦- ¦ - ¦ - ¦- ¦ - ¦- ¦ - ¦ - ¦- ¦ - ¦- ¦
¦сопровождения ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
+--------------+---+---+--+---+--+---+--+---+---+--+---+--+---+---+--+---+--+---+---+--+---+--+---+---+--+---+--+
¦Процесс ¦ - ¦ - ¦ ¦ ¦ ¦ ¦- ¦ - ¦ - ¦- ¦ - ¦ ¦ ¦ - ¦- ¦ - ¦- ¦ - ¦ - ¦- ¦ - ¦- ¦ - ¦ - ¦ ¦ ¦- ¦
¦документирова-¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
¦ния ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
+--------------+---+---+--+---+--+---+--+---+---+--+---+--+---+---+--+---+--+---+---+--+---+--+---+---+--+---+--+
¦Процесс ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ - ¦ ¦ ¦ - ¦ ¦ ¦ ¦- ¦ - ¦- ¦ - ¦ - ¦- ¦ - ¦- ¦ - ¦ - ¦ ¦ ¦- ¦
¦управления ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
¦конфигурацией ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
+--------------+---+---+--+---+--+---+--+---+---+--+---+--+---+---+--+---+--+---+---+--+---+--+---+---+--+---+--+
¦Процесс ¦ ¦ ¦ ¦ ¦ ¦ - ¦- ¦ - ¦ ¦ ¦ ¦ ¦ ¦ ¦- ¦ - ¦- ¦ - ¦ - ¦- ¦ - ¦- ¦ - ¦ - ¦ ¦ ¦- ¦
¦обеспечения ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
¦качества ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
+--------------+---+---+--+---+--+---+--+---+---+--+---+--+---+---+--+---+--+---+---+--+---+--+---+---+--+---+--+
¦Процесс ¦ ¦ ¦ ¦ ¦ ¦ - ¦- ¦ - ¦ - ¦ ¦ ¦ ¦ ¦ ¦- ¦ - ¦- ¦ - ¦ - ¦- ¦ - ¦- ¦ - ¦ - ¦ ¦ ¦- ¦
¦верификации ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
+--------------+---+---+--+---+--+---+--+---+---+--+---+--+---+---+--+---+--+---+---+--+---+--+---+---+--+---+--+
¦Процесс ¦ ¦ ¦ ¦ ¦ ¦ - ¦- ¦ - ¦ ¦ ¦ ¦ ¦ ¦ ¦- ¦ - ¦- ¦ - ¦ - ¦- ¦ - ¦- ¦ - ¦ - ¦ ¦ ¦- ¦
¦аттестации ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
+--------------+---+---+--+---+--+---+--+---+---+--+---+--+---+---+--+---+--+---+---+--+---+--+---+---+--+---+--+
¦Процесс ¦ - ¦ - ¦ ¦ ¦ ¦ ¦ ¦ - ¦ - ¦- ¦ ¦ ¦ ¦ ¦ ¦ - ¦- ¦ ¦ ¦ ¦ ¦- ¦ - ¦ - ¦ ¦ ¦- ¦
¦совместного ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
¦анализа ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
+--------------+---+---+--+---+--+---+--+---+---+--+---+--+---+---+--+---+--+---+---+--+---+--+---+---+--+---+--+
¦Процесс аудита¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ - ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ - ¦ ¦ ¦ ¦- ¦ ¦- ¦ ¦ - ¦ ¦ ¦ ¦
+--------------+---+---+--+---+--+---+--+---+---+--+---+--+---+---+--+---+--+---+---+--+---+--+---+---+--+---+--+
¦Процесс ¦ ¦ ¦ ¦ - ¦ ¦ ¦ ¦ - ¦ ¦ ¦ ¦- ¦ ¦ - ¦- ¦ - ¦ ¦ - ¦ - ¦- ¦ - ¦- ¦ - ¦ - ¦- ¦ - ¦- ¦
¦решения ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
¦проблемы ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
+--------------+---+---+--+---+--+---+--+---+---+--+---+--+---+---+--+---+--+---+---+--+---+--+---+---+--+---+--+
¦Управление ¦ - ¦ ¦ ¦ ¦ ¦ ¦ ¦ - ¦ - ¦ ¦ - ¦ ¦ ¦ ¦- ¦ - ¦- ¦ - ¦ ¦ ¦ ¦ ¦ - ¦ - ¦- ¦ - ¦- ¦
¦процессом ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
¦разработки ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
+--------------+---+---+--+---+--+---+--+---+---+--+---+--+---+---+--+---+--+---+---+--+---+--+---+---+--+---+--+
¦Управление ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ - ¦ - ¦- ¦ ¦ ¦ ¦ ¦- ¦ - ¦- ¦ - ¦ ¦ ¦ ¦ ¦ - ¦ - ¦- ¦ - ¦- ¦
¦процессом ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
¦сопровождения ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
+--------------+---+---+--+---+--+---+--+---+---+--+---+--+---+---+--+---+--+---+---+--+---+--+---+---+--+---+--+
¦Процесс ¦ - ¦ - ¦- ¦ - ¦ ¦ ¦ ¦ - ¦ - ¦- ¦ ¦ ¦ ¦ - ¦- ¦ - ¦ ¦ ¦ ¦ ¦ - ¦- ¦ - ¦ - ¦ ¦ ¦ ¦
¦создания ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
¦инфраструктуры¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
+--------------+---+---+--+---+--+---+--+---+---+--+---+--+---+---+--+---+--+---+---+--+---+--+---+---+--+---+--+
¦Процесс ¦ - ¦ - ¦- ¦ - ¦ ¦ ¦ ¦ ¦ - ¦- ¦ - ¦ ¦ ¦ ¦ ¦ ¦- ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
¦обучения ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
+--------------+---+---+--+---+--+---+--+---+---+--+---+--+---+---+--+---+--+---+---+--+---+--+---+---+--+---+--+
¦Процесс ¦ - ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ - ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦- ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦- ¦
¦усовершенство-¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
¦вания ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
+--------------+---+---+--+---+--+---+--+---+---+--+---+--+---+---+--+---+--+---+---+--+---+--+---+---+--+---+--+
С.3.1 Недостатки
Данной модели присущи следующие недостатки, которые необходимо
учитывать при оценке возможности ее применения:
а) все возможности системы предопределены изначально;
b) ограниченные возможности долговременного привлечения ресурсов
(средств или персонала).
С.3.2 Преимущества
Преимущества использования данной модели:
a) изначальное определение возможностей системы;
b) пригодность для использования промежуточного продукта;
c) естественное разделение системы на наращиваемые компоненты
(инкременты);
d) привлечение персонала и средств по мере необходимости;
e) необходимая обратная связь с пользователем для полного понимания
требований;
f) упрощение надзора за изменением технологии.
Приложение D
(справочное)
Примеры адаптации ГОСТ Р ИСО/МЭК 12207
D.1 Расширение области практического применения стандарта
Данный пример показывает, как ГОСТ Р ИСО/МЭК 12207 может быть
практически внедрен в условиях договора путем введения новых работ,
расширяющих область его применения (рисунок D.1). Пояснительный текст к
данному примеру изложен подобно изложению ГОСТ Р ИСО/МЭК 12207.
D.1.1 Сценарий
Ключевым аспектом анализа соответствующих требований является выбор
метода удовлетворения конкретному требованию: исключительно программными
решениями или изменением существующей практической деятельности в
организации.
Примечание - В данном случае под практической деятельностью понимают
способ решения задачи конкретным лицом при выполнении им повседневной
работы. Например, обработка документа, которая может быть выполнена более
эффективно в другой последовательности действий, внедренной при
модернизации системы.
В ряде случаев внедрение системы, содержащей программные средства,
может оказать существенное влияние на практическую деятельность
соответствующей организации. Классическим примером этого являются
управление системами трудовых ресурсов и информации, особенно при переходе
с ручных операций на электронные. Также следует ожидать изменений в
практической деятельности организации при поставке программного средства в
виде готового пакета, который может быть использован с незначительными
изменениями (настройками) или без них.
D.1.2 Решения по адаптации (практическому применению)
В процесс разработки внесены следующие дополнительные работы:
- практическая деятельность по анализу требований;
- практическая деятельность по проектированию и документированию;
- практическая деятельность по сборке.
В процесс эксплуатации внесена дополнительная работа - практическая
деятельность по оценке.
D.1.3 Обоснование адаптации (практического применения)
ГОСТ Р ИСО/МЭК 12207 описывает процессы жизненного цикла программных
средств в общем контексте системы. Хотя основные работы по системе и
процесс верификации из ГОСТ Р ИСО/МЭК 12207 обеспечивают некоторую
поддержку управления практической деятельностью, предполагают, что
наиболее эффективные общие решения будут приняты с учетом конкретной
практической деятельности. Это особенно важно при значительном изменении
существующей практической деятельности, когда требуется тщательный надзор
и контроль изменений в деятельности организации.
Четыре последующих пункта изложены подобно их изложению в ГОСТ Р
ИСО/МЭК 12207. В данных пунктах уточнены задачи, которые должны быть
выполнены в каждой из дополнительных работ.
D.1.4 Практическая деятельность по анализу требований
Данная работа состоит из следующих задач, которые разработчик должен
выполнить или обеспечить их выполнение в соответствии с условиями
договора:
а) существующая практическая деятельность должна быть
проанализирована согласно работе по анализу требований к программному
средству из процесса разработки с целью определить наиболее эффективные
методы реализации системы. Данная работа должна охватывать обзор деловой
деятельности, структуру организации, а также полномочия и обязанности
каждого подразделения организации, вовлеченного в проект. Требования к
практической деятельности должны быть документально оформлены;
"Рис. D.1. Пример адаптации к практической деятельности"
b) практическая деятельность должна быть оценена с учетом
нижеперечисленных критериев, а результаты этих оценок должны быть
документально оформлены:
- отслеживания требований к системе и программному средству;
- полноты исходных данных, полученных от работодателей и профсоюзов;
- осуществимости реализации;
- согласованности с нормативными требованиями;
- выполнимости аудита системы.
D.1.5 Практическая деятельность по проектированию и документированию
Для каждого конкретного вида практической деятельности данная работа
состоит из следующих задач, при решении которых разработчик должен:
a) определить, в соответствии с интересами участников процесса,
информационные потоки процесса, связанные с практической деятельностью;
b) создать предварительные версии процедурных (технологических)
документов;
c) подготовить методические материалы, используемые при реализации
договора, для обучения персонала соответствующей практической
деятельности;
d) предусмотреть поощрительные мероприятия по стимулированию
деятельности персонала организации заказчика, связанного с окончательным
вводом системы в действие.
D.1.6 Практическая деятельность по сборке
Для каждого конкретного вида практической деятельности данная работа
состоит из следующих задач, при решении которых разработчик должен:
a) подготовить программу первоначального обучения персонала рабочих
мест на основе предварительных процедурных (технологических) документов и
соответствующих программных средств;
b) провести обучение персонала, используя предварительные версии
данных документов с целью определить эффективность этих документов и
соответствующих учебных материалов;
c) оценить данные документы, учебные и методические материалы по
нижеперечисленным критериям, а результаты этих оценок документально
оформить:
- отслеживания требований к системе и программному средству;
- согласованности с практикой эксплуатации компонентов программного
средства;
- соответствия инструкциям;
- простоты использования данных материалов при эксплуатации;
- эффективности устанавливаемых взаимосвязей;
- выполнимости аудита системы;
d) доработать, при необходимости, соответствующие процедурные
(технологические) документы и материалы.
D.1.7 Практическая деятельность по оценке
Данная работа состоит из следующих задач, выполняемых оператором в
соответствии с условиями договора:
a) для каждой редакции программного продукта или процедурных
(технологических) документов обеспечить их совместимость с системой;
b) выполнять регулярные обследования степени удовлетворения запросов
пользователя и анализировать их результаты в целях определения степени
пригодности системы. При необходимости в результате таких анализов должны
быть выданы документально оформленные предложения по дальнейшей
деятельности, например по дополнительному обучению, анализу практической
деятельности или изменению программного средства.
D.2 Пример макетирования небольшой системы
Данный пример показывает, как ГОСТ Р ИСО/МЭК 12207 может быть
адаптирован для обеспечения макетирования небольшой системы (рисунок D.2).
D.2.1 Сценарий
При разработке небольших деловых систем полное применение ГОСТ Р
ИСО/МЭК 12207 может быть излишним, потому что в результате этого ресурсы
будут потрачены впустую, а созданы малозначительные документы, излишне
увеличивающие стоимость проекта. В данном случае для достижения требуемых
целей должно быть принято наиболее экономически эффективное решение по
макетированию.
Ключевой целью такого решения должна являться максимально возможная
детализация на ранних стадиях проекта. Это достигается путем установления
прямой связи между разработчиком программного средства и пользователями,
непосредственно участвующими в соответствующих деловых процессах.
Требования к системе должны быть определены пользователями, в особенности
функции системы и внешние интерфейсы, а соответствующие деловые процессы
должны быть уточнены при проведении пользователем серии оценок
используемого прототипа системы.
Для небольших систем технические средства, эксплуатируемые
программные средства и пакет базы данных могут быть приобретены на
свободном рынке в виде соответствующих стандартных продуктов. Разработчик
программного средства может применить базу данных с использованием
инструментальной системы "4GL" для быстрого проектирования экранов и
оперативного наращивания, изменения или уточнения объектов. Пользователь
имеет возможность непосредственно проверить актуальность принятого решения
опытным путем в реальной эксплуатационной ситуации.
"Рис. D.2. Пример адаптации при макетировании"
Временной разрыв между анализом требований и квалификационными
испытаниями должен быть максимально сокращен, а роль решения по наиболее
полному удовлетворению требованиям с точки зрения пользователей повышена.
D.2.2 Решения по адаптация (практическому применению)
Следующие стандартные работы (из процесса разработки по ГОСТ Р
ИСО/МЭК 12207) должны быть объединены в работу, названную
"Программирование программного средства с использованием 4GL":
- проектирование программной архитектуры;
- техническое проектирование программного средства;
- сборка программного средства.
Данная единая работа должна быть использована, как показано на
рисунке D.2, в котором соответствующие работы из ГОСТ Р ИСО/МЭК 12207
выделены и привязаны к макетированию для наглядной иллюстрации этого
метода.
Определен фиксированный период проведения макетирования и
предусмотрены любые дополнительные итерации.
D.2.3 Обоснование адаптации (практического применения)
Макетирование требует быстрого и точного определения интерфейса
пользователя. Одновременно данный интерфейс должен быть принят, а
разработка системы проведена с учетом таких факторов, как преобразования
данных и характеристики производительности.
Разработчик программного средства контролирует макетирование
посредством:
- установления приоритетов требований;
- ужесточения ограничений временного интервала;
- привлечения конечного пользователя.
D.3 Пример ускоренной разработки приложения
В предыдущем примере введено понятие макетирования. В настоящем
примере макетирование используют в модели жизненного цикла полной
разработки системы, часто называемой "Ускоренная разработка приложения
[(УРП) Rapid Application Development (RAD)]".
Примечание - Данный пример УРП выделен из метода динамической
разработки системы [(МДРС) Dynamic Systems Development Method (DSDM)] для
иллюстрации общего применения метода УРП (см. www.dsdm.org).
D.3.1 Сценарий
Для успешной реализации УРП разработчики должны взаимодействовать с
конечными пользователями, иметь навыки работы с соответствующими
технологиями и средствами, а область применения приложения не должна быть
критичной (т.е. являться коммерческой). На основе данных предпосылок
следующие критические факторы определяют успешность реализации УРП:
- установление приоритетов практических требований, определяющих
качество эксплуатационных характеристик системы;
- анализ создаваемой продукции, ориентированный на виды выполняемой
деятельности и являющийся более гибким по сравнению с анализом работ,
ориентированным на выполнение заданий;
- использование строгих процедур управления конфигурацией, потому что
каждое вносимое изменение может быть аннулировано;
- обоснование состава персонала, необходимого для достижения
поставленных целей, более широких, чем сформулированные задачи;
- проведение испытаний на всем протяжении жизненного цикла объекта;
- обоснование временных и стоимостных оценок функциональных
возможностей конечных продуктов, более широкое, чем установленный состав
работ по их созданию;
- углубленная оценка риска при функционировании системы, более
детальная по сравнению с анализом структуры системы;
- установление общих требований, так чтобы они были достаточно
гибкими для декомпозиции во время разработки.
D.3.2 Решения по адаптации (практическому применению)
Принятая модель жизненного цикла УРП должна включать в себя следующие
компоненты, показанные на рисунке D.3:
a) Осуществимость
Для определения того, будет ли проект удовлетворять критериям
успешной реализации УРП.
Примечание - Данный компонент охвачен процессом разработки по 5.3.1
ГОСТ Р ИСО/МЭК 12207.
b) Анализ деловой деятельности
Должны быть определена область применения и разработан план
макетирования.
Примечание - Данный компонент охвачен процессом разработки по 5.3.1
ГОСТ Р ИСО/МЭК 12207.
c) Цикл функциональной модели
"Рис. D.3. Пример ускоренной разработки приложения (УРП)"
Примечание - В квадратных скобках указаны пункты ГОСТ Р ИСО/МЭК
12207.
Должен быть разработан функциональный прототип (макет),
сформулированы нефункциональные требования и стратегия реализации.
Примечание - Данный компонент, ранее не определенный и дополняющий
процесс разработки, реализуют по 5.3.1 ГОСТ Р ИСО/МЭК 12207. Могут быть
полезны и другие аспекты из ГОСТ Р ИСО/МЭК 12207, такие как верификация и
обеспечение качества.
d) Цикл проектирования и создания
Должна быть создана тестированная система, удовлетворяющая всем
функциональным и нефункциональным требованиям.
Примечание - Данный компонент предусматривает последовательную
итерацию работ по 5.3.3 - 5.3.8 ГОСТ Р ИСО/МЭК 12207.
e) Реализация
Когда разработчики внедряют систему в среде пользователя, они должны
обеспечить ее документирование и обучение соответствующего персонала.
Примечание - Данный компонент является комбинацией 5.3.1.2 ГОСТ Р
ИСО/МЭК 12207 с отдельными аспектами процессов документирования и
обучения.
В перечислениях с) и d) разработчики должны определить прототипы в
соответствии с графиками их создания и анализа. Каждый шаг данного
итерационного цикла имеет определенный временной интервал, при этом
конкретное время его реализации обычно определяется набором трех итераций
- предварительное исследование, уточнение и утверждение (принятие).
Примечание - Для полной адаптации должна быть проведена взаимоувязка
на уровне задач между методом УРП и требованиями ГОСТ Р ИСО/МЭК 12207.
D.3.3 Обоснование адаптации (практического применения)
Метод УРП часто применяют при необходимости ускоренной разработки
новых систем или реализации полной ее разработки.
D.4 Пример сопровождения
В данном примере показано, как можно путем добавления и удаления
работ практически применить ГОСТ Р ИСО/МЭК 12207 в конкретной ситуации
сопровождения. В пример также включен поясняющий текст, изложенный подобно
изложению в ГОСТ Р ИСО/МЭК 12207.
D.4.1 Сценарий
Во время рассмотрения договора в процессе поставки организации по
сопровождению могут пожелать внести дополнительные процессы и задачи,
помимо установленных в ГОСТ Р ИСО/МЭК 12207. Например, в процессе заказа
организацией по сопровождению может быть определена организация, отличная
от исходного поставщика, а она пожелает провести подробное изучение
заказанного программного продукта с точки зрения его сопровождения. На
основе такого анализа данная организация может попросить перепроектировать
программный продукт до начала процесса полного его сопровождения. Это
может быть обеспечено путем введения в процесс заказа работы, названной
"Программная инженерия и оценка качества". В процессе заказа важно
обеспечить, чтобы соответствующие задачи были отражены в договоре и были
выполнены при приемке и завершении заказа.
В случае принятия решения о перепроектировании программного продукта
организация по сопровождению может отказаться от ряда работ процесса
сопровождения. Обычно при принятии решения о перепроектировании жизненный
цикл программного продукта продлевают сверх указанного в договоре. Поэтому
может возникнуть необходимость в исключении работы по снятию с
эксплуатации (см. 5.5.6 ГОСТ Р ИСО/МЭК 12207).
Дополнительное качество сопровождаемого продукта может быть
обеспечено организацией по сопровождению путем внесения дополнительных
задач в процесс совместного анализа (см. 6.6 ГОСТ Р ИСО/МЭК 12207).
Организация по сопровождению может потребовать неформального рассмотрения
своих анализов, предшествующих поставке программного продукта, в процессах
его разработки и сопровождения.
Процесс усовершенствования может быть расширен при использовании
показателей качества во всех процессах. В него может быть внесена
дополнительная задача по выбору, анализу и интерпретации показателей для
самого этого процесса (см. 7.3 ГОСТ Р ИСО/МЭК 12207).
На рисунке D.4 показано графическое представление возможности
адаптации процесса сопровождения для данного примера. Это следует
интерпретировать только как пример его дополнения и уточнения, а не как
исчерпывающий рецепт адаптации сопровождения.
D.4.2 Решения по адаптации (практическому применению)
В процесс заказа внесена работа, названная "Программная инженерия и
оценка качества".
Из процесса сопровождения удалена работа по снятию программного
средства с эксплуатации.
D.4.3 Обоснование адаптации (практического применения)
Сопровождающая организация требует проведения анализа создаваемого
программного средства до закрытия договора. По конкретным условиям
договора исключена необходимость управления снятием программного средства
с эксплуатации.
D.4.4 Программная инженерия и оценка качества
Данная работа состоит из следующих задач, которые в соответствии с
условиями договора должна выполнить или обеспечить их выполнение
организация по сопровождению:
a) исходные программы поставляемого программного продукта должны быть
проанализированы для определения возможности их сопровождения. В
результатах оценки особенно должны быть учтены следующие факторы:
- объем (размер) программного продукта;
- число строк комментариев и исходного программного кода в исходных
программах;
- сложность компонентов программного средства;
b) исходные программы поставляемого программного продукта должны быть
проанализированы с целью определить потребность в их перепроектировании.
При этом должны быть:
- локализованы места расположения избыточных программных кодов;
- определены области неисполняемых программных кодов;
c) на основе установленного числа посторонних кодов и степени
сложности исходных программ должно быть принято решение о
перепроектировании программного продукта. При этом должны быть:
- удалены посторонние коды;
- удалены никогда не исполняемые коды;
- перепроектированы и перепрограммированы наиболее сложные исходные
программы;
- переделан программный продукт в целом.
"Рис. D.4. Пример адаптации сопровождения"
Примечание - В данном примере в зависимости от технологических
потребностей может быть проведена дальнейшая адаптация процесса
разработки.
D.4.5 Снятие программного средства с эксплуатации
Работа по снятию с эксплуатации должна быть исключена из процесса
сопровождения следующим образом: организация по сопровождению не должна
выполнять работу по снятию с эксплуатации из процесса сопровождения.
D.4.6 Равноправные анализы
В процесс совместного анализа должна быть внесена следующая задача:
организация по сопровождению должна провести неформальные анализы во время
работ по техническому проектированию программного средства,
программированию и тестированию программного средства, сборке программного
средства и квалификационным испытаниям программного средства из процесса
разработки в соответствии с 6.6 ГОСТ Р ИСО/МЭК 12207.
D.4.7 Показатели (метрики) качества
В процессе усовершенствования (см. 7.3 ГОСТ Р ИСО/МЭК 12207) в работу
по усовершенствованию процесса должна быть внесена следующая задача: в
целях усовершенствования процесса сопровождения организация по
сопровождению должна собрать, проанализировать и интерпретировать
показатели (метрики) качества программного средства, связанные с процессом
сопровождения.
АИСС БКБ, www.orioncom.ru, tel (495) 783-5510