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

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

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

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

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

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

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

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

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

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

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

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

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

ГОСТ Р 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 января текущего года, и по выпускам ежемесячного информационного указателя "Национальные стандарты" за текущий год. Если заменен ссылочный стандарт, на который дана недатированная ссылка, то рекомендуется использовать действующую версию этого стандарта с учетом всех внесенных в данную версию изменений. Если заменен ссылочный стандарт, на который дана датированная ссылка, то рекомендуется использовать версию этого стандарта с указанным выше годом утверждения (принятия). Если после утверждения настоящего стандарта в ссылочный стандарт, на который дана датированная ссылка, внесено изменение, затрагивающее положение, на которое дана ссылка, то это положение рекомендуется применять без учета данного изменения. Если ссылочный стандарт отменен без замены, то положение, в котором дана ссылка на него, рекомендуется применять в части, не затрагивающей эту ссылку.

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

3.1

3.2

3.3

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

б) Статус

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

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

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

г) Триггер

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

д) Отчет

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

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

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

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

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

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

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

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

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

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

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

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

3) отчетность

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

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

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

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

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

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

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

2) настройка управления инцидентами

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

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

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

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

- название;

- пояснение;

- дата и время возникновения;

- назначено (кому);

- приоритет;

- связанные файлы;

- решение.

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

- воздействие;

- проект;

- связанный проект;

- связанные пользователи;

- ожидаемое время решения инцидента (проблемы);

- срок решения инцидента (проблемы);

- развитие решения;

- дата начала решения инцидента (проблемы);

- ожидаемая дата решения;

- связанные проблемы;

- связанные ключевые слова;

- конфиденциальность.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- определение шаблона для отчета: эта возможность создает шаблон для отчета;

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

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

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

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

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

- определение шаблона уведомления об изменении статуса: эта возможность определяет шаблон уведомления об изменении статуса. Для использования этой возможности должно быть реализовано уведомление об изменении статуса.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- затронутая версия;

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

- версия ожидаемого решения;

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

- снимок экрана.

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

- вероятность возникновения риска;

- регулярность возникновения риска;

- условное название;

- исходный код;

- номер сборки;

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

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

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

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

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

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

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

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

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

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

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

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

- затронутой версии;

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

- версии ожидаемого решения;

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

- вероятности возникновения риска;

- регулярности возникновения риска;

- сообщивших об инциденте (проблеме).

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

- тип проблемы;

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

- общая служебная записка;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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