ГОСТ Р 71303-2024. Национальный стандарт Российской Федерации. Системная и программная инженерия. Возможности программных инструментариев для организационного управления инцидентами. Общие положения

Федеральное агентство по техническому регулированию и метрологии · № ГОСТ Р 71303-2024Действующий акт

Актуально на 01.11.2026.

Как цитировать: "ГОСТ Р 71303-2024. Национальный стандарт Российской Федерации. Системная и программная инженерия. Возможности программных инструментариев для организационного управления инцидентами. Общие положения". ГОСТ Р 71303-2024. https://bukva.ai/docs/standart-gost-r-71303-2024

(утв. и введен в действие Приказом Росстандарта от 07.06.2024 № 741-ст)

Примечание

Документ введен в действие с 30.09.2024.

Утвержден и введен в действие Приказом Федерального

агентства по техническому
регулированию и метрологии
от 7 июня 2024 г. № 741-ст

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

СИСТЕМНАЯ И ПРОГРАММНАЯ ИНЖЕНЕРИЯ

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

ОБЩИЕ ПОЛОЖЕНИЯ

Systems and software engineering. Capabilities of software
tools for organizational incident management.
General provision

(ISO/IEC 23531:2020, NEQ)

ГОСТ Р 71303-2024

ОКС 35.020

Дата введения
30 сентября 2024 года

Предисловие

1 РАЗРАБОТАН Обществом с ограниченной ответственностью «Информационно-аналитический вычислительный центр» (ООО ИАВЦ)

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

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 7 июня 2024 г. № 741-ст

4 Настоящий стандарт разработан с учетом основных нормативных положений международного стандарта ИСО/МЭК 23531:2020 «Системная и программная инженерия. Возможности инструментальных средств для решения проблем» (ISO/IEC 23531:2020 «Systems and software engineering — Capabilities of issue management tools», NEQ)

5 ВВЕДЕН ВПЕРВЫЕ

6 Некоторые положения настоящего стандарта могут являться объектами патентных прав

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. № 162-ФЗ «О стандартизации в Российской Федерации». Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.rst.gov.ru)

Введение

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

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

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

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

Настоящий стандарт сфокусирован на описании возможностей программных инструментариев для поддержки организационного управления инцидентами. При этом под инцидентом понимается отклонение или неожиданное событие, множество событий, условия или ситуация в любое время в ходе жизненного цикла проекта, продукции, услуги или системы (см. 3.1). Такие возможности программных инструментариев востребованы и на практике реализуются в рамках процессов оценки и контроля проекта, управления решениями, определения требований к системе, управления качеством, гарантии качества, управления рисками, функционирования, сопровождения систем по ГОСТ Р 57193, решения проблем в программных средствах по ГОСТ Р ИСО/МЭК 12207, управления инцидентами и запросами на обслуживание, управления проблемами по ГОСТ Р ИСО/МЭК 20000-1.

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

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

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

ГОСТ Р 51583 Защита информации. Порядок создания автоматизированных систем в защищенном исполнении. Общие положения

ГОСТ Р 53647.1 Менеджмент непрерывности бизнеса. Часть 1. Практическое руководство

ГОСТ Р 54145 Менеджмент рисков. Руководство по применению организационных мер безопасности и оценки рисков. Общая методология

ГОСТ Р 56920/ISO/IEC/IEEE 29119-1:2013 Системная и программная инженерия. Тестирование программного обеспечения. Часть 1. Понятия и определения

ГОСТ Р 57193 Системная и программная инженерия. Процессы жизненного цикла систем

ГОСТ Р 57272.1 Менеджмент риска применения новых технологий. Часть 1. Общие требования

ГОСТ Р 58494 Оборудование горно-шахтное. Многофункциональные системы безопасности угольных шахт. Система дистанционного контроля опасных производственных объектов

ГОСТ Р 58539 Информационные технологии. Концепция интероперабельности на основе метамоделей. Часть 1. Основные положения

ГОСТ Р 58609/ISO/IEC/IEEE 15289:2017 Системная и программная инженерия. Состав и содержание информационных элементов жизненного цикла (документации)

ГОСТ Р 59337-2021 Системная инженерия. Защита информации в процессе оценки и контроля проекта

ГОСТ Р 59338-2021 Системная инженерия. Защита информации в процессе управления решениями

ГОСТ Р 59339-2021 Системная инженерия. Защита информации в процессе управления рисками для системы

ГОСТ Р 59346-2021 Системная инженерия. Защита информации в процессе определения системных требований

ГОСТ Р 59355-2021 Системная инженерия. Защита информации в процессе функционирования системы

ГОСТ Р 59356-2021 Системная инженерия. Защита информации в процессе сопровождения системы

ГОСТ Р 59989 Системная инженерия. Системный анализ процесса управления качеством системы

ГОСТ Р 59990-2022 Системная инженерия. Системный анализ процесса оценки и контроля проекта

ГОСТ Р 59991-2022 Системная инженерия. Системный анализ процесса управления рисками для системы

ГОСТ Р 59994-2022 Системная инженерия. Системный анализ процесса гарантии качества для системы

ГОСТ Р ИСО 13381-1 Контроль состояния и диагностика машин. Прогнозирование технического состояния. Часть 1. Общее руководство

ГОСТ Р ИСО/МЭК 12207 Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств

ГОСТ Р ИСО/МЭК 15414 Информационные технологии. Открытая распределенная обработка. Эталонная модель. Язык описания предприятия

ГОСТ Р ИСО/МЭК 20000-1 Информационные технологии. Менеджмент сервисов. Часть 1. Требования к системе менеджмента сервисов

ГОСТ Р МЭК 61069-2 Измерение, управление и автоматизация промышленного процесса. Определение свойств системы с целью ее оценки. Часть 2. Методология оценки

ГОСТ Р МЭК 61069-6 Измерение, управление и автоматизация промышленного процесса. Определение свойств системы с целью ее оценки. Часть 6. Оценка эксплуатабельности системы

ГОСТ Р МЭК 61508-1 Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 1. Общие требования

ГОСТ Р МЭК 61508-7 Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 7. Методы и средства

ГОСТ Р МЭК 62508 Менеджмент риска. Анализ влияния на надежность человеческого фактора

Примечание - При пользовании настоящим стандартом целесообразно проверить действие ссылочных стандартов в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет или по ежегодному информационному указателю «Национальные стандарты», который опубликован по состоянию на 1 января текущего года, и по выпускам ежемесячного информационного указателя «Национальные стандарты» за текущий год. Если заменен ссылочный стандарт, на который дана недатированная ссылка, то рекомендуется использовать действующую версию этого стандарта с учетом всех внесенных в данную версию изменений. Если заменен ссылочный стандарт, на который дана датированная ссылка, то рекомендуется использовать версию этого стандарта с указанным выше годом утверждения (принятия). Если после утверждения настоящего стандарта в ссылочный стандарт, на который дана датированная ссылка, внесено изменение, затрагивающее положение, на которое дана ссылка, то это положение рекомендуется применять без учета данного изменения. Если ссылочный стандарт отменен без замены, то положение, в котором дана ссылка на него, рекомендуется применять в части, не затрагивающей эту ссылку.

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

В настоящем стандарте применены термины по ГОСТ Р ИСО/МЭК 12207, ГОСТ Р ИСО/МЭК 20000-1, ГОСТ Р ИСО 13381-1, ГОСТ Р 53647.1, ГОСТ Р 54145, ГОСТ Р 57193, ГОСТ Р 59989, ГОСТ Р 59990, ГОСТ Р 59994, ГОСТ Р МЭК 61508-1, ГОСТ Р МЭК 62508, а также следующие термины с соответствующими определениями:

3.1

инцидент: Отклонение или неожиданное событие, множество событий, условия или ситуация в любое время в ходе жизненного цикла проекта, продукции, услуги или системы. [ГОСТ Р 57193-2016, пункт 4.1.18]

3.2

системная инженерия: Междисциплинарный подход, управляющий полным техническим и организаторским усилием, требуемым для преобразования ряда потребностей заинтересованных сторон, ожиданий и ограничений в решение и для поддержки этого решения в течение его жизни.
[ГОСТ Р 57193-2016, пункт 4.1.47]

3.3

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

4 Объектная модель для программных инструментариев

4.1 Обзор

Существуют различные описательные модели для программных инструментариев поддержки организационного управления, в т.ч. инцидентами (см. ГОСТ Р ИСО/МЭК 15414, ГОСТ Р 58539, ГОСТ Р 53647.1, ГОСТ Р 54145, ГОСТ Р 57272.1, ГОСТ Р 58494, ГОСТ Р 58539, ГОСТ Р 58609, ГОСТ Р МЭК 61069-2, ГОСТ Р МЭК 61069-6, ГОСТ Р МЭК 61508-7).

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

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

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

Примечание — В настоящем стандарте управление проблемами в одноименных процессах (введенных по ГОСТ Р ИСО/МЭК 12207, ГОСТ Р ИСО/МЭК 20000-1) рассматривается как частный случай управления инцидентами (согласно широкому определению инцидента по ГОСТ Р 57193, пункт 4.1.18) и упоминается далее по тексту там, где уместно в связке «инцидент (проблема)».

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

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

4.2 Пример использования

4.2.1 Описание примера

Организационное управление рассматривают как целенаправленное организационное воздействие.

В данном пункте в качестве примера определены три варианта использования программных инструментариев в организационном управлении на различных этапах жизненного цикла проекта, продукции, услуги или системы (см. рисунок 1):

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

б) управление дефектами в процессе тестирования программных средств: реакция на выявление ошибок и дефектов в процессе тестирования системы, в процессе решения проблем в программных средствах;

в) управление инцидентами в процессе эксплуатации: реагирование на отказы системы в процессах функционирования или сопровождения систем.

4.2 Пример использования

Рисунок 1 — Пример вариантов использования инструментариев

4.2.2 Сценарии использования

4.2.2.1 Сценарий управления работой

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

а) руководитель проекта поручает работу заказчику или разработчику;

б) заказчик или разработчик выполняют порученную работу и сообщают о результатах;

в) руководитель проекта утверждает результат, работы завершены.

4.2 Пример использования

Рисунок 2 — Схема деятельности по управлению работами

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

Таблица 1

Пояснения к сценариям использования в управлении работами

Процесс	Действующее лицо	Исходные данные	Результаты
Анализ требований (для заказчика)	Заказчик	Объекты исследования	Результат исследования
Анализ требований (разработчику)	Разработчик (системный аналитик)	Объекты исследования	Результат исследования
Проектирование	Разработчик (проектировщик)	Требование	Проект
Реализация	Разработчик (программист)	Проект	Исходный код

4.2.2.2 Сценарий управления дефектами в процессе тестирования

Управление инцидентами (проблемами) можно использовать для управления дефектами, которые выявляют во время тестирования. Детали по тестированию приведены в ГОСТ Р 56920, ГОСТ Р 51583. Действующими лицами являются ответственный за дефекты технический менеджер, разработчик, тестировщик и система, показанная на рисунке 3. Эти действующие лица выполняют работы по следующему сценарию:

а) тестировщик испытывает систему. В случае обнаружения дефекта тестировщик создает рабочий элемент дефекта;

б) технический менеджер, ответственный за дефекты, утверждает рабочий элемент дефекта и поручает исправление дефекта разработчику;

в) разработчик определяет причину дефекта, указанную техническим менеджером, ответственным за дефекты, и исправляет систему;

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

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

4.2 Пример использования

Рисунок 3 — Схема деятельности по управлению дефектами

4.2.2.3 Сценарий использования управления инцидентами в эксплуатируемой системе

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

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

б) менеджер по эксплуатации получает уведомление от пользователя и создает отчет об инциденте;

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

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

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

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

ж) разработчик с одобрения технического менеджера выпускает модифицированную систему в рабочую среду;

з) технический менеджер подтверждает, что проблема решена в рабочей среде, и сообщает пользователю, что инцидент устранен;

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

к) менеджер по эксплуатации закрывает отчет об инциденте.

4.2 Пример использования

Рисунок 4 — Схема деятельности по управлению ИТ-сервисами

4.3 Объектная модель

4.3.1 Общая информация

Информация, используемая, как правило, во всех случаях применения, представлена в виде пространства имен под названием «Общая», а информация, обрабатываемая в каждом сценарии использования, может быть представлена в виде пространств имен, например: применительно к 4.2 (см. рисунок 1) под названиями «Управление работами», «Управление дефектами» и «Управление ИТ-сервисами». Объект «Общая» информация импортируется и используется в каждом сценарии.

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

4.3.2 Объекты управления работами

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

4.3.3 Объекты управления дефектами

Управление дефектами включает в себя несколько объектов. Их определяют как подклассы четырех классов, импортируемые из объекта «Общая» (информация). Проблема, импортированная из объекта «Общая» (информация), наследуется в объекте «Дефект». Импортируемая из объекта «Общая» (информация) целевая система наследуется в объекте «Артефакт», создаваемом для целевой системы. Артефакт наследуется и детализируется как «Требование», «Проектный документ» и «Программа». Отчет, импортируемый из объекта «Общая» (информация), наследуется в объекте «Список статусов дефекта», отражающем статус проблем. Триггер, импортируемый из объекта «Общая» (информация), наследуется в объекте «Тестирование» для выявления дефектов. Тестирование состоит из таких подклассов, как «План тестирования», «Тестовая среда», «Программа тестирования», «Тестовые данные» и «Результат тестирования».

4.3.4 Объекты управления ИТ-сервисами

Управление ИТ-сервисами включает в себя несколько объектов. Их определяют как подклассы четырех классов, импортируемые из объекта «Общая» (информация). Статус, импортируемый из объекта «Общая» (информация), наследуется в объекте «Внутренний одобренный статус». Проблема, импортированная из объекта «Общая» (информация), наследуется в объекте «Инцидент». Целевая система, импортированная из объекта «Общая» (информация), наследуется в объекте «Эксплуатируемая система». Триггер, импортированный из объекта «Общая» (информация), наследуется в объекте «Свидетельства». Свидетельства наследуются и детализируются как «Претензия», «Снимок экрана», «Работа экрана» и «Входные данные».

4.4 Категории возможностей инструментариев

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

5 Категории объектов управления

5.1 Обзор

В этом разделе определены объекты, с которыми ведется работа по управлению инцидентами (проблемами). Общие объекты и три конкретных объекта определены как подклассы.

5.2 Общие объекты

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

а) Инцидент (проблема)

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

б) Статус

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

в) Целевая система

Информация, относящаяся к объекту, в котором возникла проблема, фиксируется и управляется как единый экземпляр «Целевая система». Обычно объекты различают в зависимости от категорий, общая информация не обрабатывается.

г) Триггер

Информация о причине проблемы фиксируется и управляется как экземпляр «Триггер». Обычно объекты различают в зависимости от категорий, общую информацию не обрабатывают.

д) Отчет

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

5.3 Объекты управления работами

Информацию общих и специфических для управления работами объектов фиксируют и обрабатывают как единый экземпляр объектов «Управление работами». Атрибуты каждого объекта приведены в таблице 2.

Таблица 2

Обобщение объектов

Категория	Название общего объекта	Название объекта, относящегося к конкретной категории	Объяснение объекта	Имя атрибута	Объяснение атрибута
Общая	Статус	-	Статус и ответственность за утверждение, связанные проблемой, определяют и фиксируют совместно. Как правило, для утверждения одного состояния требуется одобрение нескольких участников	Идентификатор	Идентификатор для определения связанной проблемы
				Название статуса	Название статуса проблемы
				Утверждаемые обязанности	Ответственность за одобрение изменения статуса проблемы
				Дата утверждения	Дата и время утверждения
				Утверждено (кем)	Информация об утверждающем лице
	Целевая система	-	Фиксация и управление информацией об объекте, связанном с проблемой, месте возникновения проблемы вместе с идентификатором проблемы. Как правило, фиксируемая и управляемая информация отличается от категории к категории	-	-
	Триггер	-	Фиксация и управление информацией о причине, из-за которой возникла проблема, вместе с идентификатором проблемы. Как правило, фиксируемая и управляемая информация отличается от категории к категории	-	-
	Отчет	-	Набор проблем, соответствующих конкретному состоянию. Обычно в качестве условия указывается статус проблем	Идентификатор	Идентификатор отчета
				Набор идентификаторов проблем	Набор идентификаторов проблем, сопоставленных с указанным условием
				Указанное условие для фильтрации проблем	Условие для фильтрации и управления набором проблем в виде отчета
Управление дефектами	Целевая система	Требования	Часть, связанная с возникшей проблемой, в требованиях к целевой системе	Идентификатор	Идентификатор требования
				Версия возникновения проблемы	Версия, в которой возникла проблема
				Содержание	Содержание требования
		Проектная документация	Часть, связанная с возникшей проблемой, в проектной документации целевой системы	Идентификатор	Идентификатор проекта
				Версия возникновения проблемы	Версия, в которой возникла проблема
				Содержание	Содержание проекта
		Программа	Часть, связанная с возникшей проблемой, в программах для целевой системы	Идентификатор	Идентификатор программы
				Затронутая версия	Версия, затронутая проблемой
				Версия возникновения проблемы	Версия, в которой возникла проблема
				Версия ожидаемого решения	Версия, в которой проблема будет решена
				Среда	Среда, в которой возникла проблема
				Вероятность наступления риска	Вероятность наступления риска, когда проблемы управляются как риски
				Регулярность возникновения риска	Регулярность возникновения рисков, когда проблемы управляются как риски
				Условное название	Другое название проблемы по сравнению с первоначальным. Условное название позволяет справиться с некоторыми проблемами, вызванными одной причиной с одним названием
				Исходный код	Исходный код, в котором возникла проблема
				Сборка	Сценарий сборки целевой системы, в которой возникла проблема
				Номер сборки	Идентификатор для определения сборки целевой системы, в которой возникла проблема
				Результат сборки	Результат сборки целевой системы, в которой возникла проблема
	Триггер		Этот объект регистрирует и управляет информацией о причине возникновения проблемы с идентификатором проблемы. Сюда относится информация, которую фиксирует и обрабатывает объект «Триггер» в категории общей информации, и специфическая информация в категории управления дефектами, такая как снимок экрана, время возникновения проблемы	Снимок экрана	Снимок экрана с возникшей проблемой
	Отчет		Управление отчетом для управления дефектами	Список аналогичных проблем	Список аналогичных проблем
	Отчет		Управление отчетом для управления дефектами	Список состояний проблемы	Список состояний проблемы
Управление работами	Нештатная ситуация		Возникшая проблема регистрируется и управляется как экземпляр. Фиксируется информация, которую обрабатывает объект «Проблема» в категории общей информации, и конкретная информация в категории управления работами. Идентификатор для определения типа проблемы фиксируется как «Тип проблемы». Например, «Дефект» и «Задача» регистрируются и управляются как разные типы проблем	Идентификатор типа проблемы	Идентификатор для определения типа проблемы
				Название типа проблемы	Название типа проблемы
				Атрибут типа проблемы	Название и тип данных атрибутов типа проблемы
				Список статусов проблемы	Список статусов проблемы, относящихся к конкретному типу проблемы
				Изменение статуса типа проблемы	Список изменений статусов по типу проблемы
Управление ИТ-сервисом	Целевая система		Фиксируется и обрабатывается информация о целевой системе, в которой возникла проблема. Информация, которую записывает и обрабатывает целевой объект в общей категории, и специфическая информация в управлении ИТ-сервисами, такая как затронутая версия, версия, где возникла проблема, версия ожидаемого решения, среда возникновения проблемы, вероятность наступления риска и регулярность возникновения риска, записывается и управляется как целевой объект в этой специфической категории	Затронутая версия	Версия, затронутая проблемой
				Версия возникновения проблемы	Версия, в которой возникла проблема
				Версия ожидаемого решения	Версия, в которой проблема будет решена
				Среда	Среда, в которой возникла проблема
				Вероятность риска	Вероятность риска, если проблема управляется как риск
				Регулярность возникновения риска	Как часто возникает риск, если проблема управляется как риск
	Триггер		Фиксируется и обрабатывается информация о причине возникновения проблемы. Информация, которую записывает и обрабатывает целевой объект в общей категории, и специфическая информация в управлении ИТ-сервисами, такая как сообщивший о проблеме, фиксируется и обрабатывается как целевой объект в управлении ИТ-сервисами. Кроме того, можно создавать и управлять общими с поставщиком услуг служебными записками внутри компании	Общая служебная записка	Обмен служебными записками с поставщиком услуг внутри компании
				Сообщивший о проблеме	Имя лица, ответственного за сообщение о проблеме
				Название организации на стороне клиента	Название организации на стороне клиента, получившей сообщение о проблеме
	Статус		Статус утверждения проблемы может фиксироваться и управляться как объект «Статус» в управлении ИТ-сервисами и как объект «Статус» в определенной категории	Статус внутреннего утверждения	Статус утверждения у поставщика услуг

5.4 Объекты управления дефектами

Информацию общих и специфических для управления дефектами объектов фиксируют и обрабатывают как единый экземпляр объектов «Управление дефектами». Атрибуты каждого объекта приведены в таблице 2.

5.5 Объекты управления ИТ-сервисами

Информацию общих и специфических для управления ИТ-сервисами объектов фиксируют и обрабатывают как единый экземпляр объектов «Управление ИТ-сервисами». Атрибуты каждого объекта приведены в таблице 2.

5.6 Краткая информация о субъектах управления инцидентами

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

6 Возможности программных инструментариев

6.1 Обзор

В этом разделе приведено описание возможностей типового инструментария для управления инцидентами. В разделах 4 и 5 возможности разделены на четыре категории: общие возможности, возможности управления работами, возможности управления дефектами и возможности управления ИТ-сервисами. В таблице 3 все перечисленные возможности обобщены. Некоторые возможности указаны как в общих возможностях, так и в других категориях. Эти отношения также показаны в виде перекрестных ссылок в таблице 3 для уточнения соответствия.

а) Управление инцидентами (проблемами)

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

регистрация/упоминание/обновление инцидента (проблемы)

Возможность обновлять, упоминать и обновлять инцидент (проблему). Создает и обновляет объект «Проблема» в объектной модели, показанной в 4;

изменение статуса инцидента (проблемы)

Возможность представляет собой переходный статус инцидента (проблемы). Создает и обновляет объект «Статус» в объектной модели, показанной в 4;

отчетность

Возможность создания отчетов об управлении инцидентами (проблемами) и о самих инцидентах (проблемах). Создает и обновляет объект «Отчетность» в объектной модели, показанной в 4;

отслеживание

Возможность упоминать и редактировать целевые инциденты (проблемы). Упоминает и обновляет целевую систему в объектной модели, показанной в 4;

обмен информацией

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

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

настройка для работы: эта возможность настраивает инструмент управления инцидентами для работы в соответствии с целевой средой;
настройка управления инцидентами

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

6.2 Общие возможности

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

а) Возможность управления инцидентами (проблемами): эта возможность должна выполнять следующие действия:

регистрацию/упоминание/обновление инцидентов (проблем): эта возможность регистрирует, упоминает и обновляет атрибуты следующим образом:

название;
пояснение;
дата и время возникновения;
назначено (кому);
приоритет;
связанные файлы;
решение.

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

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

Необходимо предусмотреть возможность создания информации об инциденте (проблеме) на основе того, что уже происходило ранее;

изменение статуса инцидента (проблемы): эта возможность должна выполнять следующее действие:

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

Необходимо включить следующие возможности:

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

отчетность: эта возможность должна выполнять следующие действия:

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

Необходимо включить следующие возможности:

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

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

регистрацию/упоминание комментариев к инциденту (проблеме): эта возможность должна регистрировать комментарий и ссылаться на инцидент (проблему).

Необходимо включить следующие возможности:

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

б) Возможность администрирования: эта возможность должна выполнять следующие действия:

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

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

настройку управления инцидентами (проблемами): эта возможность должна выполнять следующие действия:

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

Ожидается наличие следующих возможностей:

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

6.3 Возможности управления работами

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

а) возможность управления инцидентами (проблемами): эта возможность должна выполнять следующие действия:

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

тип инцидента (проблемы);
атрибуты, определенные для типа инцидента (проблемы);

обмен информацией: эта возможность должна выполнять следующие действия:

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

б) возможность администрирования: эта возможность должна выполнять следующие действия:

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

назначение типа инцидента (проблемы), используемого проектом: эта возможность выбирает тип инцидента (проблемы) для каждого проекта;
регистрация шаблона для каждого проекта: эта возможность определяет такие параметры, как тип проблемы и шаблон отчета в качестве стандарта для проекта;

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

6.4 Возможности управления дефектами

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

Возможность управления инцидентами (проблемами): эта возможность должна выполнять следующие действия:

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

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

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

вероятность возникновения риска;
регулярность возникновения риска;
условное название;
исходный код;
номер сборки;

отслеживание: эта возможность должна выполнять следующие действия:

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

обмен информацией: эта возможность должна выполнять следующие действия:

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

6.5 Возможности управления ИТ-сервисами

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

а) возможность управления инцидентами (проблемами): эта возможность должна выполнять следующие действия:

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

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

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

тип проблемы;
атрибуты, определенные для типа проблемы;
общая служебная записка;

изменение статуса инцидента (проблемы): эта возможность должна выполнять следующее действие:

внутреннее одобрение перехода статуса;

обмен информацией: эта возможность должна выполнять следующие действия:

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

б) возможность администрирования: эта возможность должна выполнять следующие действия:

настройку для работы: для этой возможности необходима реализация общих возможностей согласно 6.2, а также следующих возможностей, специфичных для категории управления ИТ-сервисами:

назначения типа инцидента (проблемы), используемого проектом: эта возможность выбирает тип инцидента (проблемы) для каждого проекта;
регистрации шаблона проекта: эта возможность определяет такие параметры, как тип инцидента (проблемы) и шаблон отчета в качестве стандарта для проекта;

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

название типа инцидента (проблемы): эта возможность позволяет настраивать изменение статуса инцидента (проблемы) и управлять им с определенным названием.

6.6 Обобщение возможностей

Возможности программных инструментариев обобщены в таблице 3.

Таблица 3

Обобщение возможностей

Возможности			Категория возможностей
Группа возможностей 1	Группа возможностей 2	Возможность	Общая (информация)	Управление дефектами	Управление работами	Управление ИТ-сервисами
(1) Возможность управления инцидентами	(1-1) Регистрация/упоминание/обновление	Регистрация/упоминание/обновление названия инцидента (проблемы)	Т
		Регистрация/упоминание/обновление описания вопроса	Т
		Регистрация/упоминание/обновление даты и времени возникновения инцидента (проблемы)	Т
		Регистрация/упоминание/обновление имени лица, которому поручен разбор инцидента (проблемы)	Т
		Регистрация/упоминание/обновление приоритета	Т
		Регистрация/упоминание/обновление связанных файлов	Т
		Регистрация/упоминание/обновление реагирования	Т
		Регистрация/упоминание/обновление воздействия	О
		Регистрация/упоминание/обновление проекта, в котором возник инцидент (проблема)	О
		Регистрация/упоминание/обновление связанного проекта	О
		Регистрация/упоминание/обновление связанного пользователя	О
		Регистрация/упоминание/обновление расчетного срока решения инцидента (проблемы)	О
		Регистрация/упоминание/обновление крайнего срока решения инцидента (проблемы)	О
		Регистрация/упоминание/обновление прогресса в решении инцидента (проблемы)	О
		Регистрация/упоминание/обновление даты начала решения инцидента (проблемы)	О
		Регистрация/упоминание/обновление ожидаемой даты решения	О
		Регистрация/упоминание/обновление связанных инцидентов (проблем)	О
		Регистрация/упоминание/обновление связанного ключевого слова	О
		Регистрация/упоминание/обновление параметров конфиденциальности	О
		Регистрация нового инцидента (проблемы) на базе существующей	О
		Регистрация/упоминание/обновление затронутой версии		Т		Т
		Регистрация/упоминание/обновление версии, в которой возник инцидент (проблема)		Т		Т
		Регистрация/упоминание/обновление версии, в которой ожидается устранение инцидента (проблемы)		Т		Т
		Регистрация/упоминание/обновление среды, в которой возник инцидент (проблема), например, программный компонент, оборудование и т.д.		Т		Т
		Регистрация/упоминание/обновление вероятности возникновения риска		О		Т
		Регистрация/упоминание/обновление частоты возникновения риска		О		Т
		Регистрация/упоминание/обновление условного названия		О
		Регистрация/упоминание/обновление исходного кода		О
		Регистрация/упоминание/обновление номера сборки		О
		Регистрация/упоминание/обновление снимка экрана		Т
		Регистрация/упоминание/обновление типа проблемы			Т	О
		Регистрация/упоминание/обновление атрибутов, определенных в типе инцидента (проблемы)			Т	О
		Регистрация/упоминание/обновление сообщившего об инциденте (проблеме)				Т
		Регистрация/упоминание/обновление общей внутренней служебной записки				О
		Регистрация/упоминание/обновление названия организации на стороне клиента				О
	(1-2) Изменение статуса	Изменение статуса	Т
		Запрос и разрешение на переход статуса	О
		Внутреннее одобрение перехода статуса				О
	(1-3) Отчетность	Вывод списка незавершенных инцидентов (проблем)	Т
		Отображение истории изменений	Т
		Отображение прогресса	О
		Результат анализа тенденций в отношении решения инцидентов (проблем)	О
		Отображение списка инцидентов (проблем), которые не были завершены в течение длительного времени	О
		Отображение списка проблем для каждого назначающего лица	О
		Рабочая нагрузка	О
		Показывает время, прошедшее с момента начала решения инцидента (проблемы)	О
		Панель мониторинга	О
	(1-4) Отслеживание	Управление исходным кодом	О	О
	(1-4) Отслеживание	Сборка		О
	(1-5) Обмен информацией	Регистрация/упоминание комментария к инциденту (проблеме)	Т
		Уведомление об изменении статуса	О
		Импорт и экспорт объектов инцидента (проблемы)	О	О	О	О
		Импорт и экспорт объектов статуса	О	О	О	О
		Импорт и экспорт объектов отчетности	О	О	О	О
		Импорт и экспорт объектов целевой системы	О	О	О	О
		Импорт и экспорт объектов триггера	О	О	О	О
(2) Административные возможности	(2-1) Настройка для работы	Регистрация пользователя	Т
		Регистрация проекта	О
		Регистрация подпроекта	О
		Указание полномочий пользователя	О
		Параметры надстройки	О
		Добавление надстройки	О
		Определение шаблона для отчета	О
		Регистрация шаблона проекта			О
		Назначение типа инцидента (проблемы), используемого проектом			Т	О
	(2-2) Настройка управления инцидентами	Определение типа проблемы	Т
		Определение статуса для каждого типа инцидента (проблемы)	Т
		Определение утверждающего для изменения статуса инцидента (проблемы)	О
		Определение шаблона уведомления об изменении статуса	О
		Название типа инцидента (проблемы)			Т	О
Примечание — Т - требуются и будут реализованы; О — ожидаемая реализация.

6.7 Расширение возможностей с внедрением прогнозирования рисков

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

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

Примечание — Как пример практической реализации возможностей программных инструментариев для организационного управления инцидентами следует рассматривать создание Координационного центра Правительства Российской Федерации, в интересах которого предусмотрено создание, функционирование и развитие информационной системы управления инцидентами, аналитической информационной системы и иных информационных систем для обеспечения оперативных и согласованных действий федеральных органов исполнительной власти, органов исполнительной власти субъектов Российской Федерации и организаций при разрешении инцидентов (штатных и нештатных ситуаций) и реализации приоритетных задач Правительства Российской Федерации [1].

Приложение А
(справочное)

ТИПОВЫЕ ПОКАЗАТЕЛИ, МОДЕЛИ И МЕТОДЫ ПРОГНОЗИРОВАНИЯ РИСКОВ

Для прогнозирования рисков могут применяться любые возможные модели и методы, обеспечивающие приемлемое достижение поставленных целей. В настоящем приложении приведены ссылки на стандарты системной инженерии, содержащие рекомендации по типовым показателям, моделям и методам прогнозирования рисков в стандартных процессах оценки и контроля проекта, управления решениями, определения требований к системе, управления качеством, гарантии качества, управления рисками, функционирования, сопровождения систем по ГОСТ Р 57193 (см. таблицу А.1). Эти показатели, методы и модели в полной мере применимы для расширения возможностей программных инструментариев, поддерживающих организационное управление инцидентами.

Таблица А.1

Ссылки на типовые модели и методы прогнозирования рисков

Системный процесс	Вероятностные показатели риска	Типовые модели и методы
Процесс оценки и контроля проекта	Для системных процессов риски по ГОСТ Р 59337-2021 (подраздел 6.3) (с учетом дополнительных специфических системных требований на примере требований по защите информации) и ГОСТ Р 59990-2022 (подраздел 6.3)	По ГОСТ Р 59337-2021 (приложение В), ГОСТ Р 59990-2022 (приложение В)
Процесс управления решениями	Риск нарушения надежности реализации процесса (без учета дополнительных требований); риск нарушения дополнительных специфических системных требований (на примере требований по защите информации); риск нарушения реализации процесса с учетом дополнительных специфических системных требований (на примере требований по защите информации)	По ГОСТ Р 59338-2021 (приложение В)
Процесс управления рисками для системы	Для системных процессов риски по ГОСТ Р 59339-2021 (подраздел 6.3) (с учетом дополнительных специфических системных требований на примере требований по защите информации); интегральные риски нарушения качества системы в сценарных условиях комбинации используемых системных процессов в течение задаваемого периода прогноза по ГОСТ Р 59991-2022 (подраздел 6.3)	По ГОСТ Р 59339-2021 (приложение В), ГОСТ Р 59991-2022, приложение В
Процесс гарантии качества для системы	Для системных процессов риски по ГОСТ Р 59339-2021 (подраздел 6.3); интегральные риски нарушения качества системы по ГОСТ Р 59991-2022 (подраздел 6.3)	По ГОСТ Р 59994-2022 (приложение В)
Процесс определения системных требований (на примере требований по защите информации)	Частные показатели риска реализации угроз безопасности информации, направленных на нарушение функционирования системы, в условиях отсутствия мер защиты, предлагаемых к применению в ходе формирования системных требований, и в условиях их применения (показатели остаточного риска нарушения функционирования системы); частные показатели риска реализации угроз утечки конфиденциальной информации в условиях отсутствия мер защиты, предлагаемых к применению в ходе формирования системных требований, и в условиях их применения (показатели остаточного риска нарушения требований по защите конфиденциальной информации в системе или о системе); интегральные показатели риска реализации угроз, направленных на нарушение функционирования системы в течение ее жизненного цикла, в условиях отсутствия и применения мер защиты, предлагаемых в ходе формирования системных требований. Примечание — Приведенные показатели демонстрируют возможности модификации показателей прогнозируемых рисков.	По ГОСТ Р 59346-2021 (приложения В, Д)
Процесс функционирования системы	Риск нарушения надежности реализации процесса (без учета дополнительных требований); риск нарушения дополнительных специфических системных требований (на примере требований по защите информации); риск нарушения реализации процесса с учетом дополнительных специфических системных требований (на примере требований по защите информации)	По ГОСТ Р 59355-2021 (приложение В)
Процесс сопровождения системы	Риск нарушения надежности реализации процесса (без учета дополнительных требований); риск нарушения дополнительных специфических системных требований (на примере требований по защите информации); риск нарушения реализации процесса с учетом дополнительных специфических системных требований (на примере требований по защите информации)	По ГОСТ Р 59356-2021 (приложение В)

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

БИБЛИОГРАФИЯ

[1]	Постановление Правительства Российской Федерации от 12 февраля 2021 г. № 171 «О Координационном центре Правительства Российской Федерации»

УДК 006.34:004.056:004.056.5:004.056.53:006.354	ОКС 35.020
Ключевые слова: системная и программная инженерия, управление услугами, инструменты управления инцидентами