Home » Библиотека » Стандарты » Оформление проектных документов » ГОСТ P » Р ИСО/МЭК 15271-02 Процессы жизненного цикла программных средств.

ГОСТ Р ИСО/МЭК ТО 15271-2002

ГОСУДАРСТВЕННЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Информационная технология

РУКОВОДСТВО ПО ПРИМЕНЕНИЮ ГОСТ Р ИСО/МЭК 12207

(Процессы жизненного цикла программных средств)

Издание официальное

ГОССТАНДАРТ РОССИИ
М о с к в а
Предисловие

1. РАЗРАБОТАН И ВНЕСЕН Всероссийским научно-исследовательским институтом стандартизации (ВНИИстандарт) Госстандарта России
   
2. ПРИНЯТ И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Госстандарта России от 5 июня 2002 г. № 227-ст
   
3. Настоящий стандарт содержит полный аутентичный текст международного стандарта ИСО/МЭК ТО 15271—98 «Информационная технология. Руководство по применению ИСО/МЭК 12207 (Процессы жизненного цикла программных средств)»
   
4. ВВЕДЕН ВПЕРВЫЕ
   

   © ИПК Издательство стандартов, 2002
   

Содержание

1 Область применения 1
1.1 Назначение 1
1.2 Пользователи стандарта 1
1.3 Предпосылки 1
2 Нормативные ссышки 1
3 Система обозначений 2
4 Основные концепции в развитие ГОСТ Р ИСО/МЭК 12207 2
4.1 Инженерная дисциплина 2
4.2 Архитектура жизненного цикла программного средства 2
4.3 Характеристика процессов 3
4.4 Процессы и проекты 4
4.5 Процессы и организации 4
4.6 Программные средства и системы 5
4.7 Управление и планирование 7
4.8 Реализация принципов управления качеством 8
4.9 Гибкость и отзывчивость на развитие технологии 9
4.10 Процессы и документирование 9
4.11 Метрики программных средств 9
4.12 Согласованность 9
4.13 Заключение 10
5 Внедрение ГОСТ Р ИСО/МЭК 12207 10
5.1 Обзор 10
5.2 План внедрения 10
5.3 Практическое применение ГОСТ Р ИСО/МЭК 12207 11
5.4 Проведение сопровождения пилотного проекта(ов) 12
5.5 Формализация метода внедрения 12
5.6 Утверждение метода внедрения 13
6 Применение в проектах 13
6.1 Особенности практического применения ГОСТ Р ИСО/МЭК 12207 13
7 Применение в организациях 16
7.1 Предпосыики и методы 16
7.2 Возможности применения 17
7.3 Распространение административного управления 17
8 Прикладное применение модели жизненного цикла системы 17
8.1 Модель жизненного цикла системы 17
8.2 Модель жизненного цикла программного средства 17
8.3 Пример использования ГОСТ Р ИСО/МЭК 12207 в общей модели жизненного цикла системы 18
8.4 Определение потребностей 18
8.5 Исследование и определение концепции 18
8.6 Демонстрация и аттестация 19
8.7 Проектирование и разработка 19
8.8 Создание и производство 19
8.9 Распространение и продажа 20
8.10 Эксплуатация 20
8.11 Сопровождение и поддержка 20
8.12 Снятие с эксплуатации (утилизация) 20
8.13 Процессы жизненного цикла программного средства в общей модели жизненного цикла системы 20
Приложение А Процессы качества и требования к оценке 21
Приложение В Классификация выходных результатов процессов 23
Приложение С Модели жизненного цикла 26
С.1 Каскадная модель 26
С.2 Инкрементная модель 27
C. 3 Эволюционная модель 28
Приложение D Примеры адаптации ГОСТ Р ИСО/МЭК 12207 31
D. 1 Расширение области практического применения стандарта 31
D.2 Пример макетирования небольшой системы 33
D.3 Пример ускоренной разработки приложения 34
D.4 Пример сопровождения 37

Введение

В настоящем стандарте приведены рекомендации по практическому применению ГОСТ Р ИСО/МЭК 12207 в условиях реализации конкретных проектов создания программных средств. Опытное применение ГОСТ Р ИСО/МЭК 12207 в ряде организаций подтвердило необ­ходимость выработки таких рекомендаций для однозначного понимания требований и норм, установленных в ГОСТ Р ИСО/МЭК 12207. Вместе с тем, ряд концептуальных положений и понятий, определенных в указанном стандарте, требуют дополнительного пояснения и более расширенной трактовки. В настоящем стандарте учтены обобщенные предложения по практи­ческому применению ГОСТ Р ИСО/МЭК 12207, представленные Техническим комитетом по стандартизации ТК 22 «Информационные технологии».

В частности, термин «работа (activity)» трактуется (в зависимости от излагаемого контекста) более расширенно как «деятельность» или «виды деятельности (activities)», термин «задача (task)» — как «задание» (в зависимости от контекста), а термин «программно-аппаратное средство (firm­ware)» — как «программы, реализованные техническими средствами» (во избежание путаницы с аналогичным понятием, применяемым по отношению к компонентам автоматизированных систем).

ГОСУДАРСТВЕННЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Информационная технология

РУКОВОДСТВО ПО ПРИМЕНЕНИЮ ГОСТ Р ИСО/МЭК 12207

(Процессы жизненного цикла программных средств)

Information technology.Guide for the application of GOST R ISO/IEC 12207 (Software life cycle processes)

Дата введения 2003—07—01

4 Основные концепции в развитие ГОСТ Р ИСО/МЭК 12207
Инженерная дисциплина
Применение программной инженерии является сравнительно молодой дисциплиной по срав¬нению с традиционными направлениями инженерной деятельности. В результате контроль, обычно сопровождающий проекты традиционной инженерной деятельности, не всегда возможен для про¬граммных средств.
Основные положения ГОСТ Р ИСО/МЭК 12207 в таких вопросах, как разработка и сопровож¬дение программного средства, должны быть реализованы методом, определяемым инженерной дисциплиной. Использование такого метода позволяет определить структуру, четко привязанную к функциональной среде системной инженерии, охватывающей программные и технические средства, персонал и бизнес.
Архитектура жизненного цикла программного средства
ГОСТ Р ИСО/МЭК 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 — Анализ процессов

Задача (задание) должна(о) быть выражена(о) в виде требования, самообъявления, рекоменда¬ции или допустимого действия. С этой целью в ГОСТ Р ИСО/МЭК 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.

Рисунок 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). Программные

Рисунок 4 — Компьютерные системы в организации

работы, которые выделяют из конкретного архитектурного (эскизного) проекта, начинают с анализа требований к программным средствам (5.3.4) и завершают квалификационными испытаниями программных средств (5.3.9).
После завершения разработки программных средств их интегрируют с техническими средствами и ручными операциями в соответствии с работой «Сборка системы» (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 — Классификация работ (видов деятельности) по ГОСТ Р ИСО/МЭК 12207

ления проектом, а по 5.2.5.1 указанного стандарта данный план реализуют и контролируют. Далее в процессе поставки должен быть осуществлен надзор за технической реализацией, расходами, выполне¬нием планов (графиков) и проведена соответствующая отчетность (5.2.5.3 ГОСТ Р ИСО/МЭК 12207).

4.7.2 Дополнительные планы
Вопросы, требующие дополнительного рассмотрения и перечисленные в 5.2.4.5 ГОСТ Р ИСО/МЭК 12207, связаны с некоторыми вспомогательными и организационными процессами. Для ряда таких про-цессов требуется разработка соответствующих планов, например обеспечения качества, верифика¬ции и обучения. В зависимости от объема и сложности проекта, а также возможности субподрядного выполнения всех или ряда работ данные планы могут быть включены в план управления проектом или подготовлены в виде отдельных дополнительных документов.
При привлечении субподрядчиков подобные вопросы отслеживают в соответствии с 5.2.5.4 ГОСТ Р ИСО/МЭК 12207, уделяя особое внимание установлению необходимых взаимосвязей для синхронизации данных планов.
Сводные сведения о наборе дополнительных планов могут быть получены из таблиц В.2 и В.3 приложения В к настоящему стандарту.

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. Рисунок 6 — Работы по прак- Например, ГОСТ Р ИСО/МЭК 12207 может быть применен в соот- тическому применению ветствии с договором между поставщиком и покупателем продукта. ГОСТ Р ИСО/МЭК 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 указан¬ного стандарта. Однако если заказчик решит заказать часть таких программных средств для последующей их эксплуатации и сопровождения, тогда к ним следует применять рекомендации в соответствии с перечислениями Ь) и 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 — Требования к оценкам продуктов, услуг и процессов

Окончание таблицы А.1

приложение в

(справочное)

Классификация выходных результатов процессов

В настоящем приложении определены выходные результаты процессов (см. таблицы В. 1—В.4), которые должны быть документально оформлены в соответствии с требованиями или рекомендациями ГОСТ Р ИСО/МЭК 12207. перечислены только те пункты ГОСТ Р ИСО/МЭК 12207, по которым требуются выходные результаты. Документы по данным выходным результатам должны быть выбраны и скомплектованы пропорционально области применения, значимости, сложности и критичности проекта или организации. В графе «Выходные результаты» таблицы В.1 наименования или заголовки соответствующих документов не указаны.

Таблица В.1 — Выходные результаты основных процессов жизненного цикла

Продолжение таблицы В.1

Окончание таблицы В.1

Таблица В.2 — Выходные результаты вспомогательных процессов жизненного цикла

процесс адаптации из приложения А к ГОСТ Р ИСО/МЭК 12207 используют как дополнительный. В случае применения данный процесс должен иметь следующие выходные результаты (таблица В.4).

Таблица В.4 — Выходные результаты процесса адаптации

ПРИЛОЖЕНИЕ С

(справочное)
Модели жизненного цикла
Существует множество моделей жизненного цикла, но три из них — фундаментальные. Этими фундамен-тальными моделями жизненного цикла являются:
– каскадная;
– инкрементная;
– эволюционная.
Каждая из указанных моделей может быть использована самостоятельно или скомбинирована с другими для создания гибридной модели жизненного цикла. при этом конкретную модель жизненного цикла следует выбирать так, чтобы процессы, работы и задачи из ГОСТ Р ИСО/МЭК 12207 были связаны между собой и определены их взаимосвязи с предшествующими процессами, работами (видами деятельности) и задачами (заданиями).
В настоящем приложении описаны три фундаментальные модели жизненного цикла с присущими им недостатками (аргументами против их применения) и преимуществами (выгодами). Эти недостатки и преиму¬щества должны быть учтены при выборе модели жизненного цикла для проекта.
С.1 Каскадная модель
Каскадная модель жизненного цикла по существу реализует принцип однократного выполнения каждого из следующих видов деятельности в их естественных границах:
– установление потребностей пользователя;
– определение требований;
– проектирование системы;
– изготовление системы;
– испытание;
– корректировка;
– поставка или использование.
при применении такого принципа разработки каждого программного объекта соответствующие работы и задачи процесса разработки обычно выполняют последовательно (см. рисунок С.1). Однако они могут быть частично выполнены параллельно в случаях перекрытия последовательных работ.
Когда несколько программных объектов разрабатывают одновременно, для всех этих объектов работы и задачи процесса разработки могут быть выполнены параллельно. процессы сопровождения и эксплуатации обычно реализуют после процесса разработки. процессы заказа и поставки, а также вспомогательные и организационные процессы обычно выполняют параллельно с процессом разработки.
С.1.1 Недостатки
Данной модели присущи следующие недостатки, которые необходимо учитывать при оценке возможности ее применения:
a) требования к объектам определены недостаточно четко;
b) система обычно слишком велика, чтобы все работы по ее созданию выполнять однократно;
c) предполагаемые скорые изменения в технологиях работ;
d) возможные текущие изменения требований к системе;
e) ограниченность ресурсов, например средств или персонала;
f) промежуточный продукт может быть непригоден для использования.

Рисунок С.1 — пример каскадной модели

С.1.2 Преимущества

преимущества использования данной модели:

• однократное представление всех возможностей (характеристик) системы;
  
• необходимость только единственной фазы перехода от старой системы к новой.
  

  С.2 Инкрементная модель
  Инкрементная модель жизненного цикла, называемая также запланированным усовершенствованием продукта, начинается с выдачи набора требований и реализует разработку последовательности конструкций. первая конструкция содержит часть требований, в последующую конструкцию добавляют дополнительные требования и так далее до тех пор, пока не будет закончено создание системы. Для каждой конструкции выполняют необходимые процессы, работы и задачи, например анализ требований и создание архитектуры могут быть выполнены сразу, в то время как разработку технического проекта программного средства, его программирование и тестирование, сборку программных средств и их квалификационные испытания выполняют при создании каждой из последующих конструкций.
  В данной модели при разработке каждой конструкции работы и задачи процесса разработки выполняют последовательно или частично параллельно с перекрытием. при частично одновременной разработке последовательных конструкций работы и задачи процесса разработки могут быть выполнены параллельно для ряда конструкций.
  Работы и задачи процесса разработки обычно выполняют многократно в той же последовательности для всех конструкций. процессы сопровождения и эксплуатации могут быть реализованы параллельно с процессом разработки. процессы заказа и поставки, а также вспомогательные и организационные процессы обычно выполняют параллельно с процессом разработки (рисунок С.2).
  С.2.1 Недостатки
  Данной модели присущи следующие недостатки, которые необходимо учитывать при оценке возможности ее применения:
  а) требования к объектам определены недостаточно четко;
  

Рисунок C.2 — Пример инкрементной модели

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

  С.2.2 Преимущества
  

  Преимущества использования данной модели:
  

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

  С.З Эволюционная модель
  

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

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

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

  В таблице C. 1 показано, как могут быть распределены процессы в модели жизненного цикла программного средства при создании ее для эволюционного жизненного цикла. В таблице C. 1 учтены только работы процесса разработки. Отмеченные знаком « • » объекты указывают на конкретную работу или задачу, а горизонтальные строки представляют собой шкалу времени. При необходимости может быть проведена дальнейшая детализация распределения процессов.
  

Рисунок C.3 — Пример эволюционной модели

Таблица C.1 — Пример разметки эволюционной разработки

Окончание таблицы С.1

С.З.1 Недостатки

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

а) все возможности системы предопределены изначально;

Ь) ограниченные возможности долговременного привлечения ресурсов (средств или персонала). С.З.2 Преимущества

преимущества использования данной модели:

1. изначальное определение возможностей системы;
   
2. пригодность для использования промежуточного продукта;
   
3. естественное разделение системы на наращиваемые компоненты (инкременты);
   
4. привлечение персонала и средств по мере необходимости;
   
5. необходимая обратная связь с пользователем для полного понимания требований;
   
6. упрощение надзора за изменением технологии.
   

   приложение d
   

   (справочное)
   

   Примеры адаптации ГОСТ Р ИСО/МЭК 12207
   

   D.1 Расширение области практического применения стандарта
   

   Данный пример показывает, как ГОСТ Р ИСО/МЭК 122О7 может быть практически внедрен в условиях договора путем введения новых работ, расширяющих область его применения (рисунок D.1). пояснительный текст к данному примеру изложен подобно изложению ГОСТ Р ИСО/МЭК 122О7.
   

   D.1.1 Сценарий
   

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

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

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

   D.1.2 Решения по адаптации (практическому применению)
   

   В процесс разработки внесены следующие дополнительные работы:
   

• практическая деятельность по анализу требований;
  
• практическая деятельность по проектированию и документированию;
  
• практическая деятельность по сборке.
  

  В процесс эксплуатации внесена дополнительная работа — практическая деятельность по оценке.
  

  D.1.3 Обоснование адаптации (практического применения)
  

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

  Четыре последующих пункта изложены подобно их изложению в ГОСТ Р ИСО/МЭК 122О7. В данных пунктах уточнены задачи, которые должны быть выполнены в каждой из дополнительных работ.
  

  D.1.4 Практическая деятельность по анализу требований
  

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

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

Рисунок D.1 — Пример адаптации к практической деятельности

Ь) практическая деятельность должна быть оценена с учетом нижеперечисленных критериев, а результаты этих оценок должны быть документально оформлены:

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

  D.1.5 Практическая деятельность по проектированию и документированию
  

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

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

  D.1.6 Практическая деятельность по сборке
  

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

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

  D.1.7 Практическая деятельность по оценке
  

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

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

  D.2 Пример макетирования небольшой системы
  

  Данный пример показывает, как ГОСТ Р ИСО/МЭК 122О7 может быть адаптирован для обеспечения макетирования небольшой системы (рисунок D.2).
  

  D.2.1 Сценарий
  

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

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

  Для небольших систем технические средства, эксплуатируемые программные средства и пакет базы данных могут быть приобретены на свободном рынке в виде соответствующих стандартных продуктов. Разработчик программного средства может применить базу данных с использованием инструментальной системы «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:
  

• Осуществимость
  

  Для определения того, будет ли проект удовлетворять критериям успешной реализации УРП.
  

  Примечание — Данный компонент охвачен процессом разработки по 5.3.1 ГОСТ Р ИСО/МЭК 12207.
  

• Анализ деловой деятельности
  

  Должны быть определена область применения и разработан план макетирования.
  

  Примечание — Данный компонент охвачен процессом разработки по 5.3.1 ГОСТ Р ИСО/МЭК 12207.
  

• Цикл функциональной модели
  

Рисунок D.3 — Пример ускоренной разработки приложения (УРП)

Примечание — В квадратных скобках указаны пункты ГОСТ Р ИСО/МЭК 12207.

Должен быть разработан функциональный прототип (макет), сформулированы нефункциональные требования и стратегия реализации.

Примечание — Данный компонент, ранее не определенный и дополняющий процесс разработки, реализуют по 5.3.1 ГОСТ Р ИСО/МЭК 12207. Могут быть полезны и другие аспекты из ГОСТ Р ИСО/МЭК 12207, такие как верификация и обеспечение качества.

• Цикл проектирования и создания
  

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

  Примечание — Данный компонент предусматривает последовательную итерацию работ по 5.3.3—5.3.8 ГОСТ Р ИСО/МЭК 12207.
  

• Реализация
  

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

  Примечание — Данный компонент является комбинацией 5.3.12 ГОСТ Р ИСО/МЭК 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 Программная инженерия и оценка качества
  

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

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

1. на основе установленного числа посторонних кодов и степени сложности исходных программ должно быть принято решение о перепроектировании программного продукта. При этом должны быть:
   

• удалены посторонние коды;
  
• удалены никогда не исполняемые коды;
  
• перепроектированы и перепрограммированы наиболее сложные исходные программы;
  
• переделан программный продукт в целом.
  

Рисунок D.4 — Пример адаптации сопровождения

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

D.4.5 Снятие программного средства с эксплуатации

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

D.4.6 Равноправные анализы

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

D.4.7 Показатели (метрики) качества

В процессе усовершенствования (см. 7.3 ГОСТ Р ИСО/МЭК 12207) в работу по усовершенствованию процесса должна быть внесена следующая задача: в целях усовершенствования процесса сопровождения организация по сопровождению должна собрать, проанализировать и интерпретировать показатели (метрики) качества программного средства, связанные с процессом сопровождения.

УДК 681.3.06:006.354    ОКС 35.080    П85    ОКСТУ 5001

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

Редактор Л.В. Афанасенко Технический редактор Л.А. Гусева Корректор Н.Л. Рыбалко Компьютерная верстка И.А. Налейкиной

Изд. лиц. № 02354 от 14.07.2000. Сдано в набор 22.07.2002. Подписано в печать 21.08.2002. Усл. печ. л. 5,12. Уч.-изд.л. 5,10.

Тираж 426 экз. С 7103. Зак. 691.

ИПК Издательство стандартов, 107076 Москва, Колодезный пер., 14. http://www.standards.ru e-mail: info@standards.ru

Набрано в Издательстве на ПЭВМ Филиал ИПК Издательство стандартов — тип. «Московский печатник», 103062 Москва, Лялин пер., 6.

Плр № 080102