ГОСТ Р 58609-2019 Системная и программная инженерия. Состав и содержание информационных элементов жизненного цикла (документации)

ГОСТ Р 58609-2019/ISO/lEC/IEEE 15289:2017

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

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

СОСТАВ И СОДЕРЖАНИЕ ИНФОРМАЦИОННЫХ ЭЛЕМЕНТОВ ЖИЗНЕННОГО ЦИКЛА (ДОКУМЕНТАЦИИ)

Systems and software engineering. Content of life-cycle information items (documentation)

ОКС 35.080

Дата введения 2021-01-01

Предисловие

1 ПОДГОТОВЛЕН Акционерным обществом "Всероссийский научно-исследовательский институт сертификации" (АО "ВНИИС") и Обществом с ограниченной ответственностью "Информационно-аналитический вычислительный центр" (ООО ИАВЦ) на основе собственного перевода на русский язык англоязычной версии стандарта, указанного в пункте 4

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

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

4 Настоящий стандарт идентичен международному стандарту ISO/IEC/IEEE 15289:2017* "Системная и программная инженерия. Состав и содержание информационных элементов жизненного цикла (документации)" (ISO/IEC/IEEE 15289:2017 "Systems and software engineering - Content of life-cycle information items (documentation)", IDT).

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

ISO/IEC/IEEE 15289 разработан подкомитетом ПК 7 "Системная и программная инженерия" Совместного технического комитета СТК 1 "Информационные технологии" Международной организации по стандартизации (ИСО) и Международной электротехнической комиссии (МЭК) в сотрудничестве с Комитетом по стандартизации программных продуктов и систем Информационного общества IEEE в рамках соглашения о сотрудничестве в области развития партнерских стандартов между ISO и IEEE.

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

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

6 Некоторые положения международного стандарта, указанного в пункте 4, могут являться объектом патентных прав. ИСО и МЭК не несут ответственности за идентификацию подобных патентных прав

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

Введение

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

Настоящий стандарт основан на процессах жизненного цикла, указанных в ISO/IEC/IEEE 12207, ISO/IEC/IEEE 15288, ISO/IEC/IEEE 20000-1 и ISO/IEC/IEEE 20000-2.

ISO/IEC/IEEE 12207 и ISO/IEC/IEEE 15288 определяют набор процессов управления и выполнения этапов жизненного цикла системы. Они определяют процесс управления информацией, но "не детализируют информационные элементы сточки зрения названия, формата, явного контента и носителя записи". ISO/IEC/IEEE 15288 и ISO/IEC/IEEE 12207 устанавливают универсальную структуру для процессов жизненного цикла систем и программных продуктов и определяют или требуют нескольких элементов документации. Их эталонная модель процесса не представляет собой конкретный подход к реализации процесса, а также не предписывает модель, методологию или технику жизненного цикла системы/программных продуктов. В ISO/IEC/IEEE 12207 не всегда указывается, когда должны быть подготовлены информационные элементы программных продуктов, а также не идентифицируется содержимое элемента информации. ИСО/МЭК 20000-1 (IEEE 20000-1) устанавливает комплексные требования к документам и записям с некоторыми конкретными требованиями. ИСО/МЭК 20000-2 (IEEE 20000-2) дает рекомендации по использованию части 1.

В качестве источника настоящего стандарта использован IEEE 12207.1.

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

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

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

- ISO/IEC/IEEE 15288;

- ISO/IEC/IEEE 12207;

- ИСО/МЭК 20000-1 (IEEE 20000-1);

- ИСО/МЭК 20000-2 (IEEE 20000-2).

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

ISO/IEC/IEEE 12207 и ISO/IEC/IEEE 15288 определяют набор процессов для управления и выполнения этапов жизненного цикла программного продукта или системы. Они определяют процесс управления информацией, но не "детализируют информационные элементы с точки зрения названия, формата, явного контента и носителя записи". ISO/IEC/IEEE 15288 и ISO/IEC/IEEE 12207 устанавливают общую структуру процессов жизненного цикла системы и программных продуктов. Они идентифицируют или требуют несколько элементов документации. Их эталонная модель процесса не представляет собой конкретный подход к реализации процесса, а также не предписывает модель жизненного цикла системы/программных продуктов, методологию или технику. ИСО/МЭК 20000-1 (IEEE 20000-1) устанавливает комплексные требования к документам и записям с некоторыми конкретными требованиями. ИСО/МЭК 20000-2 (IEEE 20000-2) содержит руководства по использованию ИСО/МЭК 20000-1 (IEEE 20000-1).

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

- соглашение ISO/IEC/IEEE 15288;

- организационные меры по реализации проекта;

- техническое управление и процессы;

- основные, поддерживающие и организационные процессы жизненного цикла ISO/IEC/IEEE 12207;

- система управления сервисами ИСО/МЭК 20000-1 (IEEE 20000-1), предоставление услуг, отношения, решения и процессы управления.

Внутри каждого жизненного цикла процесса или сервиса можно подготовить политику, план, процедуры и отчеты, а также многочисленные записи, запросы, описания и спецификации. Такая разработка схемы документации будет более строгой, чем указано в ISO/IEC/IEEE 15288 или ISO/IEC/IEEE 12207. Как приведено в подразделе 1.4 ISO/IEC/IEEE 15288, пользователи настоящего стандарта несут ответственность за выбор модели жизненного цикла для проекта и сопоставление процессов, действий и задач в этом документе в этой модели. Стороны также отвечают за выбор и применение соответствующих методологий, методов, моделей и техник, подходящих для проекта. Таким образом, информационные элементы объединяются или подразделяются в соответствии с моделью жизненного цикла, как это необходимо для проектных или организационных целей, что дополнительно определено в разделах 4 и 5 настоящего стандарта.

Настоящий стандарт не устанавливает систему управления сервисами.

Область применения настоящего стандарта не включает следующее:

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

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

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

Примечание - ISO/IEC/IEEE 26531 содержит требования к управлению контентом и системам управления контентом компонентов.

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

e) информационные элементы, подтверждающие только одобрение подпункта 6.1.2.3.4.5 ISO/IEC/IEEE 12207;

f) любой подзаголовок ISO/IEC/IEEE 15288 или ISO/IEC/IEEE 12207, неявно или по смыслу идентифицирующий запись информации о процессе, деятельности или задаче, например, как приведено в пункте 6.4.4 ISO/IEC/IEEE 12207;

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

Примечания

1 ИСО/МЭК 26514 содержит руководства по форматам документации пользователя.

2 ИСО/МЭК 15504-5 и ИСО/МЭК 15504-6 детализируют содержание программных продуктов, а также информационных элементов. Их руководство включает описание набора информационных элементов (документов), с которыми может столкнуться эксперт. Информационные элементы на основании указанных выше стандартов могут быть произведены комбинациями и подразделениями требуемых информационных элементов в настоящем стандарте.

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

В настоящем стандарте использованы нормативные ссылки на следующие стандарты. Для датированных ссылок применяют только указанное издание ссылочного стандарта, для недатированных - последнее издание (включая все изменения).

ISO/IEC 12207:2008 (IEEE 12207:2008), Systems and software engineering - Software life cycle processes (Системная и программная инженерия. Процессы жизненного цикла программного обеспечения)

_______________

Заменен на ISO/IEC/IEEE 12207:2017.

ISO/IEC/IEEE 15288:2015, Systems and software engineering - System life cycle processes (Системная и программная инженерия. Процессы жизненного цикла системы)

ISO/IEC 20000-1:2011 (IEEE 20000-1:2013), Information technology - Service management - Part 1: Service management system requirements (Информационные технологии. Управление сервисами. Часть 1. Требования к системе управления сервисами)

_______________

Заменен на ISO/IEC 20000-1:2018.

3 Термины, определения и сокращения

В настоящем стандарте применены термины по ISO/IEC/IEEE 24765 (доступны на www.computer.org/sevocab).

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

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

3.1.1 подтверждение (approval): Уведомление уполномоченного представителя о том, что поставляемый товар соответствует требованиям и является комплектным.

Примечание - Такое подтверждение не переносит ответственность с поставщика в отношении выполнения требований в условиях наличия двух сторон.

3.1.2 жалоба (complaint): Отчет о предполагаемом несоблюдении соглашения об уровне обслуживания или неудовлетворенности клиентов сервисом.

3.1.3 полная [документация] (complete [documentation]): Документация, включающая в себя всю критическую информацию и любую необходимую, соответствующую информацию для целевой аудитории.

3.1.4 последовательный (consistent): Функционирование без внутренних конфликтов.

3.1.5 изделие, доступное на широком коммерческом рынке; COTS (Commercial-Off-The-Shelf-COTS): Продукт, доступный для покупки и использования без необходимости проведения мероприятий по развитию.

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

3.1.7

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

3.1.9 описание (description): Информационный элемент, представляющий запланированную или фактическую концепцию, функцию, дизайн или объект.

3.1.10 документ (document): Уникально идентифицированная единица информации для использования человеком.

Пример - Отчет, спецификация, руководство или книга в печатной или электронной форме.

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

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

3.1.12 включают [информацию] (include [information]): Данные, содержащие либо информацию, либо ссылку на информацию, которая содержится в документе.

3.1.13 информационный элемент (information item): Раздельно идентифицируемый объект информации, который создается, хранится и доставляется для использования человеком.

Примечания

1 "Информационный продукт" является синонимом. Документ, подготовленный для удовлетворения требований к информации, может быть информационным элементом или частью информационного элемента, или комбинацией нескольких информационных элементов.

2 Информационный элемент может быть подготовлен в нескольких версиях в течение жизненного цикла проекта или системы.

3.1.14 содержание информационных материалов (information item content): Информация, включенная в информационный элемент, связанный с системой, продуктом или сервисом, для удовлетворения требований или по необходимости.

3.1.15 вид информации (information item type): Группа информационных элементов, соответствующая заранее установленному набору общих критериев.

Примечание - "Вид универсального документа" является синонимом.

Пример - "План" - это вид информационного элемента для всех планов, а "отчет" - вид информационного элемента для всех отчетов.

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

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

3.1.18

_______________

Заменен на ИСО/МЭК 38500:2015.

3.1.19 презентабельный (presentable): Способный к восстанавливаемости, видимый.

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

Примечания

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

2 Согласно ИСО 9000, процедуры могут быть задокументированы или нет.

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

3.1.22 запись (record): Набор связанных элементов данных, рассматриваемых как единица.

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

3.1.24 запрос (request): Информационный элемент, который инициирует определенный курс действий или изменения для удовлетворения потребности.

3.1.25 запрос на обслуживание (service request): Запрос информации для рутинного изменения или процедуры с ранее оцененным риском.

Пример - Запрос на доступ к контролируемому приложению, запрос на перемещение оборудования.

3.1.26 элемент программного обеспечения (software item): Идентифицируемая часть программного продукта.

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

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

3.1.28 прослеживаемый (traceable): Наличие компонентов, происхождение которых можно определить.

3.1.29 недвусмысленный (unambiguous): Описанный в терминах, которые допускают только одну интерпретацию, к которым при необходимости добавлено определение.

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

3.2 Сокращения

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

CFP - конкурс проектов;

CM - управление конфигурацией;

COTS - изделие, доступное на широком коммерческом рынке;

ITT - приглашение на тендер;

RFP - заявка на подряд;

SLA - соглашение об уровне обслуживания;

SMS - система управления сервисом.

4 Применимость

4.1 Цель

Целью настоящего стандарта является предоставление требований для пользователей ISO/IEC/IEEE 12207, ISO/IEC/IEEE 15288 и ИСО/МЭК 20000-1 (IEEE 20000-1) для определения и планирования конкретных информационных элементов (информационных продуктов), которые должны быть разработаны и пересмотрены в течение жизненного цикла систем, программных продуктов и процессов управления сервисами. Настоящий стандарт предназначен для использования следующим образом:

a) Работы с технической информацией, необходимой тем, кто участвует в процессах ISO/IEC/IEEE 15288 и ISO/IEC/IEEE 12207.

b) Определения информации в процессе соглашения, как описано в ISO/IEC/IEEE 15288, или двухстороннюю ситуацию, как описано в ISO/IEC/IEEE 12207, ИСО/МЭК 20000-1 (IEEE 20000-1) и ИСО/МЭК 20000-2 (IEEE 20000-2). Двухсторонняя ситуация может варьироваться от неофициального соглашения внутри организации до юридически обязывающего договора между организациями.

c) Разработки информационных элементов, которые предоставляют доказательства для оценки процесса, выполняемые в отношении ИСО/МЭК 33001, и для руководства деятельностью по совершенствованию процесса; а также

d) Руководства единственной стороны при выполнении самостоятельных задач.

4.2 Предполагаемые пользователи настоящего стандарта

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

a) руководителям проектов, отвечающим за процесс управления информацией ISO/IEC/IEEE 15288 (6.3.6) в течение жизненного цикла системы;

b) руководителям проектов, отвечающим за определение требований к элементам информации и содержимому документов при использовании ISO/IEC/IEEE 12207 или любого другого процесса жизненного цикла разработки программного продукта для определения, что должно быть задокументировано, когда документация должна быть разработана и каким должно быть содержание документов;

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

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

e) лицам, ответственным за идентификацию информационных элементов, требуемых для соответствия требованиям ISO/IEC/IEEE 12207, ISO/IEC/IEEE 15288 или ИСО/МЭК 20000-1 (IEEE 20000-1:2013);

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

4.3 Применимость к рабочим усилиям

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

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

b) любым видам деятельности и задачи проекта;

c) системному или программному продукту, либо сроку службы;

d) всем формам информационных элементов, содержимому информационных материалов и средств доставки документов;

e) документации изделий, доступных на широком коммерческом рынке (COTS), когда изделие COTS указано в качестве поставки в двухсторонней ситуации.

Примечание - См. ISO/IEC/IEEE 12207, 1.2.

4.4 Применимость к получателям информационных элементов

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

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

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

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

5 Соответствие

5.1 Определение соответствия

Настоящий стандарт может использоваться в качестве соответствия или руководящего документа для проектов и организаций, утверждающих соответствие ISO/IEC/IEEE 15288, ISO/IEC/IEEE 12207 или ИСО/МЭК 20000-1 (IEEE 20000-1).

Примечания

1 Поставщики услуг могут ссылаться на ИСО/МЭК 20000-1 (IEEE 20000-1) и ISO/IEC TR 20000-3 относительно требований соответствия для определенной области сертификации, например, организационных единиц, услуг местоположения.

2 ИСО/МЭК 20000-1 является стандартом системы управления, устанавливающим требования к поставщикам услуг. Некоторые требования настоящего стандарта не являются требованиями ИСО/МЭК 20000-1. Некоторые требования ИСО/МЭК 20000-1 не являются требованиями настоящего стандарта.

Если выбранные системы или процессы жизненного цикла программного продукта были адаптированы в соответствии с ИСО/МЭК 15288 или ИСО/МЭК 12207, в целях соблюдения требований настоящего стандарта, пользователь настоящего стандарта должен подготовить информационные элементы, указанные в настоящем стандарте, применимые к выбранным и адаптированным стандартам ISO/IEC/IEEE 15288 или ISO/IEC/IEEE 12207.

Типовые и конкретные записи и содержание записей и информации в разделах 7, 9 и 10 настоящего стандарта могут быть адаптированы для удовлетворения потребностей организации, ее проектов или соглашений на основе соответствия требованиям ISO/IEC/IEEE 15288 или ISO/IEC/IEEE 12207. При адаптации информационные элементы, представленные в настоящем стандарте, могут быть изменены (добавлены, объединены или переименованы). Содержимое информационных элементов должно соответствовать выбранным и адаптированным процессам.

Примечание - В приложении А к ISO/IEC/IEEE 15288 и ISO/IEC/IEEE 12207 содержатся требования к процессу адаптации.

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

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

Глагол "включать", используемый в настоящем стандарте, указывает, что (1) есть информация или (2) указывается ссылка на информацию.

5.2 Условия соответствия

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

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

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

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

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

Примечания

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

2 В соответствии с ИСО/МЭК 17000 организация или проект, или программа, с несколькими поставщиками может считаться соответствующей настоящему стандарту, когда продукты (информационные элементы) соответствуют требованиям, но организация, проект или программа не выполнили конкретные требования к соответствию, указанные в пунктах (a), (b) или (c), приведенных выше.

5.3 Вид соответствия

Утверждается один из следующих видов соответствия. Выбранный вид должен быть идентифицирован в заявлении о соответствии:

a) Индивидуальное: минимальный набор требуемых информационных элементов определяется путем адаптации процессов и видов деятельности в соответствии с приложением А к ISO/IEC/IEEE 12207 или приложением А к ISO/IEC/IEEE 15288.

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

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

6 Данные жизненного цикла и информационные элементы

6.1 Характеристики данных жизненного цикла

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

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

a) недвусмысленность;

b) завершенность;

c) возможность проверки;

d) последовательность;

e) модифицируемость;

f) прослеживаемость;

g) презентабельность.

6.2 Записи по сравнению с информационными элементами (документами)

Запись представляет собой особый вид документированной информации, содержащей набор структурированных данных, рассматриваемых как единое целое. В таблице 4 в разделе 9 определены записи. В соответствии с ИСО 9000 целью записи является фиксирование достигнутых результатов или предоставление доказательств выполненных действий. Фактически, ИСО/МЭК 20000-1 (IEEE 20000-1) рассматривает любой документ или информационный элемент как запись. Однако в настоящем стандарте различаются записи данных и документов (информационные элементы).

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

6.3 Управление данными жизненного цикла (записями)

Данные жизненного цикла являются результатом выполнения процессов и задач системы управления деятельностью или задачами. Данные могут быть рабочим продуктом или элементом в других информационных элементах. Многие из статей в ISO/IEC/IEEE 15288 и ISO/IEC/IEEE 12207 требуют, чтобы данные о жизненном цикле были созданы или записаны. Тем не менее, положения ISO/IEC/IEEE 15288 и ISO/IEC/IEEE 12207 не определяют содержание, местоположение, формат или носитель, которые будут использоваться для записи и сохранения данных. При выборе подходящих данных, которые должны быть записаны, руководители записей должны также определять, где должны записываться в системе ведения документации организации или проекта данные. Записи могут храниться в базах данных, реестрах, репозиториях, архивах или других системах управления данными. Организации или проекты должны устанавливать политику хранения записей с учетом требований к жизненному циклу системы, а также потребностей в организации или управлении сервисами в отношении данных. Раздел 9 определяет содержание универсальных записей и рекомендует контент для конкретных записей.

Примечание - Требования и руководство по управлению записями приведены в ИСО/МЭК 16175.

6.4 Управление информационными элементами (документами)

Управление информационными элементами должно выполняться путем применения процесса управления информацией ISO/IEC/IEEE 12207 и ISO/IEC/IEEE 15288, процессов управления документацией и управления документацией программных продуктов ISO/IEC/IEEE 12207, включая деятельность по управлению знаниями ISO/IEC/IEEE 15288 (пункт 6.2.4) или деятельность по управлению документацией ИСО/МЭК 20000-1 (IEEE 20000-1). Процесс управления информацией должен поддерживать потребности проекта и связанного с ним продукта или услуги. Он должен включать в себя процедуры подготовки, сбора, идентификации, классификации, распространения, хранения, обновления, архивирования и получения информации.

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

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

a) идентифицируется информация для управления;

b) определены представления информации;

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

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

e) информация предоставляется назначенным заинтересованным сторонам.

6.4.1 Разработка плана документации

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

6.4.2 Управление и контроль информационных элементов

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

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

7 Типовые виды информационных элементов

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

Использование типовых видов упрощает применение согласованной структуры, содержания и форматов для аналогичных информационных элементов (записей и документов) для поддержки удобства использования. В настоящем стандарте определяются данные жизненного цикла ISO/IEC/IEEE 12207, ISO/IEC/IEEE 15288 и ИСО/МЭК 20000-1 (IEEE 20000-1) и ИСО/МЭК 20000-2 (IEEE 20000-2) путем сопоставления задач и действий со следующими типовыми видами информационных элементов:

a) описание;

b) план;

c) политика;

d) процедура;

e) отчет;

f) запрос, а также

g) спецификация.

Примечания

1 В разделе 9 определяется типовое содержание записей данных.

2 В ИСО/МЭК 20000 документы, за исключением записей, указывают на намерение, которое должно быть достигнуто.

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

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

7.2 Описание - типовое содержимое

Цель: представить планируемый или фактический контекст использования, функции, дизайна, сервиса или элемента.

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

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

a) дату выдачи, статус, объем;

b) сведения об организации, выдавшей документ;

c) ссылки;

d) контекст;

e) обозначение для описания;

f) основную часть;

g) резюме;

h) глоссарий;

i) историю внесения изменений.

Идентифицированные информационные элементы:

- концепция операций (операционная концепция);

- описание дизайна базы данных;

- описание интерфейса;

- предложение;

- каталог услуг;

- описание архитектуры программного продукта;

- описание дизайна программного продукта;

- описание программного продукта;

- описание архитектуры системы; а также

- описание системного элемента.

7.3 План - типовое содержимое

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

a) дату выдачи и статус;

b) объем;

c) сведения об организации, выдавшей документ;

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

e) сведения об органе, выдавшем разрешение;

f) введение, в котором указаны цель, аудитория и сфера применения плана;

g) запланированные мероприятия и задачи;

h) идентификация инструментов, методов и техники;

i) график;

j) бюджеты и сметы расходов;

k) ресурсы и их распределение, включая людские ресурсы, технические ресурсы (инфраструктуру) и инструменты;

I) обязанности и полномочия, включая ответственного владельца и непосредственного владельца процесса или сервиса;

m) интерфейсы между участвующими сторонами;

n) виды деятельности по оценке рисков, оценке и смягчению рисков;

o) меры обеспечения качества и эффективности;

p) информацию об окружающей среде, инфраструктуре, защищенности и безопасности;

q) обучение;

r) подход к техническому и управленческому анализу и отчетности;

s) другие планы (планы или описания задач, которые расширяют детали плана);

t) глоссарий;

u) изменение процедуры и историю;

v) процесс завершения.

Идентифицированные информационные элементы:

- план принятия;

- план приобретения;

- план управления активами;

- план аудита;

- планирование мощностей;

- план и политика управления конфигурацией;

- план развития;

- план утилизации;

- план документации;

- план разработки домена;

- план совершенствования (план улучшения процесса, план улучшения обслуживания);

- план управления информацией;

- план информационной безопасности;

- план установки;

- план интеграции (план внедрения);

- план технического обслуживания;

- план измерений;

- план управления проектами;

- план управления качеством (план обеспечения качества);

- план выпуска версий (план развертывания);

- план повторного использования;

- политика и план управления рисками;

- план обеспечения бесперебойной работы и доступности;

- план управления сервисами;

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

- план обучения;

- план одобрения;

- план проверки.

7.4 Политика - типовое содержимое

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

a) дату выдачи, дату вступления в силу и статус;

b) область применения;

c) сведения об организации, выдавшей документ;

d) сведения об организации, выдавшей разрешение, и идентификации лиц, ответственных за соблюдение политики;

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

f) сведения об органе, включая цели;

g) глоссарий;

h) историю внесений изменений.

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

Идентифицированные информационные элементы:

- политика бюджетирования и учетная политика (вне области применения настоящего стандарта);

- план и политика управления конфигурацией (политика управления изменениями);

- план совершенствования (и политика постоянного совершенствования);

- политика информационной безопасности;

- политика и процедура жизненного цикла;

- политика и процедура управления качеством;

- план выпуска версий (и политика);

- политика и план управления рисками;

- план управления сервисами (и политика).

7.5 Процедура - типовое содержимое

ISO/IEC/IEEE 15288, ссылка: 5.5.1

ИСО/МЭК 20000-1 (IEEE 20000-1) ссылка: 5.3

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

a) дату выдачи и статус;

b) область применения;

c) сведения об организации, выдавшей документ;

d) сведения об органе, предоставляющем официальное одобрение;

e) отношение к планам и другим процедурам;

f) нормативные ссылки;

g) входы и выходы;

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

i) ошибку и разрешение проблемы;

j) глоссарий;

k) историю внесения изменений.

Идентифицированные информационные элементы:

- процедура аудита;

- процедура управления мощностями;

- процедура коммуникации;

- процедура подачи жалобы;

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

- процедура документирования;

- процедура внедрения;

- процедура совершенствования;

- процедура управления инцидентами;

- процедура управления информацией;

- процедура информационной безопасности;

- политика и процедура жизненного цикла;

- процедура технического обслуживания;

- процедура измерения;

- процедура операционного тестирования;

- процедура управления проблемами;

- процедура оценки процесса;

- процедура квалификационного испытания;

- политика и процедура управления качеством;

- процедура тестирования программного продукта;

- порядок управления поставщиками;

- процедура выбора поставщика;

- учебная документация;

- документация пользователя;

- процедура подтверждения;

- процедура проверки.

7.6 Отчет - типовое содержимое

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

Отчет должен включать следующие элементы:

a) дату выдачи и статус;

b) область применения;

c) сведения об организации, выдавшей документ;

d) сведения об участниках;

e) резюме;

f) введение, включая цель, аудиторию и сферу охвата отчета;

g) контекст (допущения);

h) основную часть (включая методы получения результатов);

i) выводы и рекомендации;

j) ссылки;

k) библиографию;

I) глоссарий;

m) историю внесений изменений.

Идентифицированные информационные элементы:

- отчет о приеме;

- отчет о подтверждении аудита;

- аудиторский отчет;

- отчет о состоянии конфигурации;

- отчет об оценке;

- отчет об инциденте;

- отчет об установке;

- отчет об интеграции и испытаниях;

- отчет о мониторинге и контроле;

- отчет о проблеме;

- отчет об улучшении процесса;

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

- отчет о ходе работы;

- отчет о квалификационных испытаниях;

- протокол анализа проекта;

- отчет об обслуживании;

- отчет об испытаниях программного продукта;

- уведомление пользователя;

- отчет об одобрении;

- отчет о проверке.

7.7 Запрос - типовое содержимое

Цель: записывать информацию, необходимую для запроса ответа.

Запрос должен включать следующие элементы:

a) дату подачи;

b) область применения;

c) предмет;

d) сведения об инициаторе запроса;

e) идентификацию запрашиваемого товара, сервиса или ответа;

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

g) обоснования.

Примечание - Идентификация запрашиваемого элемента может быть Спецификацией.

Идентифицированные информационные элементы:

- Запрос на внесение изменений;

- Опрос удовлетворенности клиентов;

- Заявка на подряд (RFP);

- Запрос ресурсов;

- Запрос на операции с риском;

- Запрос на обслуживание (запись).

7.8 Спецификация - типовое содержимое

Цель: предоставить требования к необходимому сервису, продукту или процессу.

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

a) дату выдачи и статус;

b) область применения;

c) сведения об организации, выдавшей документ;

d) ссылки;

e) сведения об органе, выдавшем разрешение;

f) основную часть;

g) требования к достоверности;

h) условия, ограничения и характеристики;

i) глоссарий;

j) историю внесения изменений.

Идентифицированные информационные элементы:

- контракт;

- соглашение об уровне обслуживания (SLA);

- спецификация требований к программному продукту;

- требования к системным требованиям (или требованиям к обслуживанию);

- Спецификация проверки.

8 Сопоставление информационных элементов с жизненным циклом и процессами управления сервисами

В таблицах 1, 2 и 3, колонка 3, информационные элементы идентифицируются и сопоставляются с процессом, в котором они идентифицируются как выходные данные в ISO/IEC/IEEE 15288 или ISO/IEC/IEEE 12207 или ИСО/МЭК 20000-1 (IEEE 20000-1) и ИСО/МЭК 20000-2 (IEEE 20000-2). Этими рекомендациями могут быть нормативные требования, рекомендуемая продукция, информационные материалы, примеры или заметки. В настоящем стандарте определяются элементы информации, которые не указаны явно в заголовке в базовых стандартах. В этих случаях базовые стандарты указывают информацию, которая должна быть документирована, описана, запланирована, указана, сообщена, записана, запрошена или указана. В таблице В.1 приведено сравнение информационных элементов по источникам. Таблица 1 отображает положения ISO/IEC/IEEE 15288 (столбец 2), процессы и выходные информационные элементы. Таблица 2 отображает положения ISO/IEC/IEEE 12207 (столбец 2), процессы и выходные информационные элементы. Таблица 3 отображает положения ИСО/МЭК 20000-1 (IEEE 20000-1) и ИСО/МЭК 20000-2 (IEEE 20000-2) (столбец 2), процессы и выходные информационные элементы,

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

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

Практически для каждого процесса в ISO/IEC/IEEE 15288 и ISO/IEC/IEEE 12207 указывается, что организационные политики и процедуры являются источником для процессов и результатов процесса.

В таблицах 1, 2 и 3 "организационные политики и процедуры" не перечислены, но их следует рассматривать как вход для каждого информационного элемента. В контрактной работе договор/соглашение и требования также должны рассматриваться как входные данные для каждого информационного элемента, независимо от того, указывает ли исходный стандарт, что процесс должен выполняться "как указано в контракте".

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

8.1 Сопоставление информационных элементов с жизненным циклом системы

Как определено в ISO/IEC/IEEE 15288 и показано в заголовке таблицы 1, в дополнение к процессу адаптации, существуют еще два процесса соглашения, шесть процессов организационного проектирования, восемь процессов технического управления и четырнадцать технических процессов:

Процессы соглашения

1) Приобретение.

2) Поставка.

Организационные проекты, активирующие процессы

1) Управление моделью жизненного цикла.

2) Управление инфраструктурой.

3) Управление портфелем.

4) Управление человеческими ресурсами.

5) Управление качеством.

Процессы технического управления

1) Планирование проекта.

2) Оценка и контроль проекта.

3) Управление принятием решений.

4) Управление рисками.

5) Управление конфигурацией.

6) Управление информацией.

7) Измерение.

Технические процессы

1) Анализ требований заинтересованных сторон.

2) Анализ требований.

3) Архитектурный дизайн.

4) Реализация.

5) Интеграция.

6) Проверка.

7) Переход.

8) Валидация.

9) Эксплуатация.

10) Техническое обслуживание.

11) Утилизация.

Таблица 1 - Сопоставление статей ISO/IEC/IEEE 15288 с информационными элементами каждого процесса жизненного цикла системы

8.2 Сопоставление информационных элементов с жизненным циклом программного продукта

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

Процессы заключения соглашения

1) Приобретение.

2) Поставка.

Организационные проекты, активирующие процессы

1) Управление моделью жизненного цикла.

2) Управление инфраструктурой.

3) Управление портфелем проектов.

4) Управление человеческими ресурсами.

5) Управление качеством.

Процессы проекта

1) Планирование проекта.

2) Оценка и контроль проекта.

3) Управление принятием решений.

4) Управление рисками.

5) Управление конфигурацией.

6) Управление информацией.

7) Измерение.

Технические процессы

1) Определение требований заинтересованных сторон.

2) Анализ требований к системе.

3) Архитектурный дизайн системы.

4) Внедрение.

5) Системная интеграция.

6) Квалификационное тестирование системы.

7) Установка программного продукта.

8) Поддержка принятия программного продукта.

9) Операция программного продукта.

10) Обслуживание программного продукта.

11) Утилизация программного продукта.

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

1) Внедрение программного продукта.

2) Анализ требований к программному продукту.

3) Программный архитектурный дизайн.

4) Детальный дизайн программного продукта.

5) Программные продукты.

6) Интеграция программного продукта.

7) Квалификационное тестирование программного продукта.

Процессы поддержки программного продукта

1) Управление документацией по программному продукту.

2) Управление конфигурацией программного продукта.

3) Обеспечение качества программного продукта.

4) Проверка программного продукта.

5) Проверка программного продукта.

6) Анализ программного продукта.

7) Аудит программного продукта.

8) Разрешение проблем программного продукта.

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

1) Разработка домена.

2) Повторное использование управления активами.

3) Повторное использование программного продукта.

Таблица 2 - Сопоставление статей ISO/IEC/IEEE 12207 с информационными элементами для каждого жизненного цикла программного продукта

8.3 Сопоставление информационных элементов с процессами управления сервисами

В таблице 3 приведены информационные элементы в 14 процессах управления сервисами, как определено в ИСО/МЭК 20000-1 (IEEE 20000-1) и ИСО/МЭК 20000-2 (IEEE 20000-2). Эти 14 процессов включают в себя проектирование и переход новых или измененных сервисов, шесть процессов предоставления услуг, два процесса взаимодействия, два процесса разрешения и три процесса управления. Кроме того, в разделе 4 ИСО/МЭК 20000-1 (IEEE 20000-1) требуются некоторые информационные элементы для системы управления сервисами в целом, применимые ко всем процессам. В таблице 3 политики, планы и процедуры показаны для конкретных сервисов, а дополнительные детали доступны в стандарте ИСО/МЭК 20000-1 (IEEE 20000-1) или ИСО/МЭК 20000-2 (IEEE 20000-1), разделы 5-9.

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

Разработка и переход нового или измененного процесса обслуживания

Процессы предоставления услуг

1) Управление уровнем обслуживания.

2) Отчеты служб.

3) Непрерывность обслуживания и доступности.

4) Бюджетирование и учет услуг.

5) Управление пропускной способностью.

6) Управление информационной безопасностью.

Процессы взаимодействия

1) Управление бизнес-отношениями.

2) Управление поставщиками.

Процессы разрешения

1) Управление запросами на инциденты и услуги.

2) Управление проблемами.

Процессы управления

1) Управление конфигурацией.

2) Управление изменениями.

3) Управление выпуском и развертыванием.

Таблица 3 - Сопоставление статей ИСО/МЭК 20000-1 (IEEE 20000-1) и ИСО/МЭК 20000-2 (IEEE 20000-2) с информационными элементами для каждого процесса управления сервисами

9 Записи

В данном разделе описывается Типовой и конкретный контент записей, указанных в ISO/IEC/IEEE 12207, ISO/IEC/IEEE 15288, ИСО/МЭК 20000-1 (IEEE 20000-1) и ИСО/МЭК 20000-2 (IEEE 20000-1). Проект, организация или служба должны вести записи, необходимые для требуемых информационных элементов (документов). Записи содержат данные, структурированные в постоянной, удобочитаемой форме. Записи могут быть сгенерированы для любого процесса жизненного цикла, задачи или деятельности в проекте или организации, для включения данных о требованиях, политиках, решениях и их обосновании, проектах, исходном коде, проблемах, отзывах, запросах, измерениях и тестовых данных, а также для включения товарных, качественных, юридических, официальных, финансовых и исторических данных. Записи должны сохраняться для поиска в реестрах, репозиториях или базах данных.

9.1 Запись - типовое содержимое

Цель: Организация данных, сохраняемых организационным подразделением.

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

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

a) дату записи, дату записи и статус;

b) область применения;

c) предмет или категорию;

d) сведения об организации, выдавшей документ;

e) ссылки;

f) основную часть;

g) уникальный идентификатор записи.

9.2 Конкретное содержание записи

В таблице 4 приведены ссылки на применимый процесс жизненного цикла и содержание конкретных записей, упоминаемых в ISO/IEC/IEEE 12207, ISO/IEC/IEEE 15288, ИСО/МЭК 20000-1:2011 (Стандарт IEEE 20000-1-2013) и ИСО/МЭК 20000-2:2012 (Стандарт IEEE 20000-2-2013). Типовое содержание записей представлено в разделе 9.1. В таблице 4 нет никаких ссылок на записи результатов, которые необходимо собирать, хранить и проверять, например, данные измерений. Отчеты о проблемах включены в Отчет о проблемах в разделах 8 и 10. В таблице В.2 приведено сравнение записей по источникам.

Примечания

1 Термин "запись конфигурации" может использоваться как для записи отдельного компонента (элемента) в конфигурации, так и для записи конфигурации системы в определенный момент времени (основные данные).

2 ИСО/МЭК 20000-1 (IEEE 20000-1) и ИСО/МЭК 20000-2 (IEEE 20000-2) различают жалобы, инциденты и проблемы. Проблема является основной причиной одного или нескольких инцидентов, или жалоб. Для целей управления информацией в настоящем стандарте записи о жалобах, инцидентах и проблемах имеют сходное содержимое и часто используют одни и те же или связанные с ними системы управления записями.

Таблица 4 - Запись ссылок и содержимого

10 Содержание конкретных информационных элементов (документов)

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

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

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

Содержание информационных элементов, приведенных в разделе 10, включает идентифицированные явно элементы (но могут не требоваться для соответствия) и неявно определенные в ISO/IEC/IEEE 12207, ISO/IEC/IEEE 15288, ИСО/МЭК 20000-1 (IEEE 20000-1) и ИСО/МЭК 20000-2 (IEEE 20000-1).

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

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

Информационные элементы для систем могут быть специализированы для программного обеспечения.

Пример - Описание системного элемента, созданного для элемента программного обеспечения, можно назвать описанием программного элемента. Запрос на внесение изменений программного продукта можно назвать запросом на изменение программного продукта.

10.2 План принятия

ISO/IEC/IEEE 12207, ссылка: 6.1.1.3.1.9.

ISO/IEC/IEEE 15288, ссылка: 6.3.13b) 6).

Типовой вид: План.

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

См. также: План тестирования интеграции программного обеспечения.

10.3 Отчет о приемке

ISO/IEC/IEEE 12207, ссылка: 6.4.8.3.1.1.

ISO/IEC/IEEE 15288, ссылки: 6.1.1.3е1), В.1.

Типовой вид: Отчет.

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

10.4 План приобретения

ISO/IEC/IEEE 12207, ссылки: 6.1.1.3.1.8, 6.1.1.3.1.9, 6.1.1.3.1.12.

ISO/IEC/IEEE 15288, ссылка: 6.3.1.3b) 6).

Типовой вид: План.

План приобретения включает следующее:

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

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

c) риски и методы управления рисками;

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

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

План приобретения должен включать в себя следующее:

a) критерии отбора поставщиков;

b) назначение системы или программного продукта;

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

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

e) идентификация спонсора проекта, организации-покупателя, организаций-пользователей и агентств поддержки;

f) контрольные этапы анализа и аудита проекта, а также

g) текущие и планируемые рабочие площадки.

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

10.5 План управления активами

ISO/IEC/IEEE 12207, ссылки: 7.3.2.2, 7.3.2.3.1.1, 7.3.2.3.1.3, 7.3.2.3.2.2.

Типовой вид: План.

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

10.6 Отчет о подтверждении аудита

ISO/IEC/IEEE 12207, ссылка: 7.2.7.3.1.6.

Типовой вид: Отчет.

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

10.7 План аудита

ISO/IEC/IEEE 12207, ссылки: 6.2.1.3.2.2, 7.2.7.3.2.1.

ИСО/МЭК 20000-1 (IEEE 20000-1), ссылки: 4.5.4.1, 4.5.4.2.

ИСО/МЭК 20000-2 (IEEE 20000-2), ссылка: 4.5.4.2.

Типовой вид: План.

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

10.8 Процедура аудита

ISO/IEC/IEEE 12207, ссылка: 7.2.7.3.1.4.

ИСО/МЭК 20000-1 (IEEE 20000-1), ссылка: 4.5.4.2.

ИСО/МЭК 20000-2 (IEEE 20000-2), ссылки: 4.5.4.2, 9.1.3.5.

Типовой вид: Процедура.

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

10.9 Отчет аудита

ISO/IEC/IEEE 12207, ссылки: 6.1.2.3.4.15, 6.4.6.3.1.3, 7.1.7.3.1.4, 7.2.7.3.1.6.

ИСО/МЭК 20000-1 (IEEE 20000-1), ссылки: 4.5.4.2, 9.1.

ИСО/МЭК 20000-2 (IEEE 20000-2), ссылки: 4.3.1.1, 4.5.4.2, 6.2.3с), 9.1.3.2, 9.1.4.

Типовой вид: Отчет.

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

10.10 Полный план

ИСО/МЭК 20000-1 (IEEE 20000-1), ссылка: 6.5.

ИСО/МЭК 20000-2 (IEEE 20000-2), ссылки: 6.5.1, 6.5.2, 6.5.3.2, 6.5.4.

Типовой вид: План.

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

10.11 Процедура управления мощностью

ИСО/МЭК 20000-1 (IEEE 20000-1), ссылка: 6.5.

ИСО/МЭК 20000-2 (IEEE 20000-2), ссылки: 6.5.3.2, 6.5.4.

Типовой вид: Процедура.

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

10.12 Запрос на внесение изменений

ISO/IEC/IEEE 12207, ссылки: 6.1.1.3.4.3, 6.1.2.3.3.2, 6.3.5.3.1, 6.4.9.3.1.3, 6.4.9.3.4.1, 6.4.9.3.4.2, 6.4.10.3.1.2, 6.4.10.3.2.1, 6.4.10.3.2.4, 7.2.2.3.3.1, 7.2.8.2, 7.3.1.3.1.3, 7.3.1.3.5.1, 7.3.2.3.3.6, 7.3.2.3.3.7, F.3.2, F.3.3.2.1.

ISO/IEC/IEEE 15288, ссылки: 6.1.2.1, 6.1.1.3c) 2), 6.1.2.3c) 2), 6.3.2.3c) 3), В.1.

ИСО/МЭК 20000-1 (IEEE 20000-1), ссылки: 8.2, 9.1, 9.2.

ИСО/МЭК 20000-2 (IEEE 20000-2), ссылки: 6.6.3.5, 9.1.3.5, 9.2.2, 9.2.3.2, 9.2.3.3, 9.2.4, таблица А.14.

Типовой вид: Запрос.

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

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

См. также: Отчет о проблеме, сервисный запрос (запись).

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

10.13 Процедура коммуникации

ИСО/МЭК 20000-1 (IEEE 20000-1), ссылки: 4.1.3, 7.1.

ИСО/МЭК 20000-2 (IEEE 20000-1), ссылки: 4.1.1.3, 4.1.3.2, 7.1.1, 9.3.4.

Типовой вид: Процедура.

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

10.14 Процедура подачи жалобы

ИСО/МЭК 20000-1 (IEEE 20000-1), ссылка: 7.1.

ИСО/МЭК 20000-2 (IEEE 20000-1), ссылки: 7.1.3.3, 7.1.4.

Типовой вид: Процедура.

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

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

10.15 Концепция операций

ISO/IEC/IEEE 12207, ссылки: 6.1.1.3.1.1, 6.4.1.2, 6.4.1.3.2.3.

ISO/IEC/IEEE 15288, ссылки: 6.4.1.1, 6.4.1.2, 6.4.1.3с), 6.4.2.2b), 6.4.2.3b), 6.4.2.3c), В.1.

Типовой вид: Описание.

Концепция операций (или операционная концепция) включает в себя следующее:

a) описание того, как система работает с точки зрения пользователей;

b) определение потребностей заинтересованных сторон и ожидаемых видов пользователей системы;

c) идентификацию интерфейсов с существующими и будущими системами;

d) краткое изложение оперативных, организационных воздействий и последствий для развития;

e) анализы стоимости, критичности и осуществимости предполагаемой системы.

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

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

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

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

4) сравнение текущих процессов с будущими процессами, которые будут обрабатываться новой системой;

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

См. также: Оценка потребностей продукта, требования к системным требованиям.

Примечание - ISO/IEC/IEEE 29148 содержит дополнительные рекомендации.

10.16 План и политика управления конфигурацией

ISO/IEC/IEEE 15288, ссылка: 6.3.5.3.

ISO/IEC/IEEE 12207, ссылки: 6.3.5.3.1.1, 7.2.2.3.1.1.

ИСО/МЭК 20000-1 (IEEE 20000-1), ссылки: 5.1, 9.2, 9.3.

ИСО/МЭК 20000-2 (IEEE 20000-2), ссылки: 9.1.2, 9.1.3.2, 9.1.3.3, 9.1.4, 9.2.3.1, 9.2.3.2, 9.2.3.4, 9.2.4, 9.3.3.1, 9.3.3.2, 9.3.3.3, 9.3.3.5, 9.3.4.

Типовой вид: План и Политика.

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

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

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

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

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

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

b) управление конфигурацией и управление изменениями;

c) учет состояния конфигурации;

d) аудит и оценку конфигурации, включая недостатки в регистрации, инициирование корректирующих действий и отчетность.

Примечание - IEEE 828 дает дополнительные рекомендации.

См. также: План выпуска версий.

10.17 Процедура управления конфигурацией

ИСО/МЭК 20000-1 (IEEE 20000-1), ссылки: 9.1, 9.2, 9.3.

ИСО/МЭК 20000-2 (IEEE 20000-2), ссылки: 4.1.4.3, 5.3.3.2.1, 9.1.3.2, 9.1.3.3, 9.1.3.5, 9.1.4, 9.2.2, 9.2.4, 9.3.3.2, 9.3.3.3

Типовой вид: Процедура.

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

Примечание - ИСО/МЭК 20000-1 (IEEE 20000-1) требуют координации планирования процесса управления выпуском и развертыванием с процессом управления изменениями.

Процедуры включают следующее:

a) осуществление процесса;

b) идентификацию и запись конфигурации;

c) контроль конфигурации;

d) учет состояния конфигурации (отслеживание);

e) оценку конфигурации;

f) протоколирование и анализ воздействия запросов на внесение изменений;

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

h) управление и предоставление выпусков и развертывания;

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

j) способы отмены и исправлений неудачного изменения или выпуска.

Они должны включать следующее:

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

2) документирование объема изменений;

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

4) отслеживание изменений в процессе;

5) обновление данных конфигурации;

6) уведомление заинтересованных сторон при установке или изменении исходных условий.

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

10.18 Отчет о состоянии конфигурации

ISO/IEC/IEEE 12207, ссылки: 7.2.2.2е), 7.2.2.3.4.1, 7.2.2.3.5.1.

ИСО/МЭК 20000-2 (IEEE 20000-2), ссылки: 9.1.1, 9.1.4, 9.2.3.3.

Типовой вид: Отчет.

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

10.19 Контракт

ISO/IEC/IEEE 15288, ссылки: 6.1.1.2, 6.1.1.3, 6.1.2.2, 6.1.2.3, 6.3.1.3.

ISO/IEC/IEEE 12207, ссылки: 6.1.1.2, 6.1.1.3.4.2, 6.1.1.3.4.3, 6.1.2.2, 6.1.2.3.3.1, 6.1.2.3.6.2, 6.4.1.3.2.1, В.3.2.2.1, В.3.2.2.2, В.3.1.2.2, В.3.1.3.2, F.3.3.1.1, F.3.3.1.2, F.3.3.5.1.

ИСО/МЭК 20000-1 (IEEE 20000-1), ссылки: 5.2, 5.3, 6.1, 7.2.

ИСО/МЭК 20000-2 (IEEE 20000-2), ссылки: 4.2.1, 4.2.5, 4.3.1.1, 4.5.2.3, 4.5.3, 5.2.8, 6.1.3, 6.1.4, 7.2.2, 7.2.3.1, 7.2.4, таблица А.14.

Типовой вид: Спецификация.

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

a) идентификацию исполняющих организаций и их обязанности;

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

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

d) согласованные цены и график платежей;

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

f) график для поставщиков для доставки продукта или услуги;

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

h) положения о мониторинге, отчетности, проверке, одобрении и критериях приемлемости;

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

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

10.20 Анализ уровня удовлетворенности клиентов

ISO/IEC/IEEE 12207, ссылки: 6.2.5.3.1.4, 7.1.

ИСО/МЭК 20000-2 (IEEE 20000-2), ссылки: 7.1.3.3, 7.1.4, таблица А.8.

Типовой вид: Запрос.

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

10.21 Описание дизайна базы данных

ISO/IEC/IEEE 12207, ссылки: 7.1.3.3.1.3, 7.1.4.3.1.3.

Типовой вид: Описание.

Описание дизайна базы данных - это проект верхнего уровня для баз данных, включающий в себя следующее:

a) анализ и идентификацию базы данных;

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

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

d) обоснование проектирования базы данных;

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

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

1) краткое изложение истории разработки, использования и обслуживания базы данных;

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

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

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

5) виды ошибок, влияющих на базу данных и обработка этих ошибок;

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

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

a) методы доступа к базе данных;

b) элементы данных и их отношения;

c) ограничения безопасности и целостности;

d) требования к сохранению данных, а также

e) ожидаемый размер элементов данных.

10.22 План развития

ISO/IEC/IEEE 12207, ссылки: 7.1.1.3.1.3, 7.1.1.3.1.4, 7.1.3.3.1.5.

Типовой вид: План.

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

a) определение целей и стандартов, планируемых к использованию в процессе разработки системы или программных продуктов;

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

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

d) график, ресурсы, методологию, инструменты, стратегию повторного использования, действия для устранения нарушений, роли и обязанности, планируемые к использованию при разработке и тестировании;

e) квалификацию всех требований, включая безопасность и охрану;

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

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

10.23 План утилизации

ISO/IEC/IEEE 15288, ссылка: 6.4.11.3.

ISO/IEC/IEEE 12207, ссылка: 6.4.11.3.1.1.

ИСО/МЭК 20000-1 (IEEE 20000-1), ссылка: 5.2.

ИСО/МЭК 20000-2 (IEEE 20000-2), ссылка: 5.2.8. Типовой вид: План.

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

10.24 План документации

ISO/IEC/IEEE 12207, ссылки: 6.3.6.3, 7.2.1.2, 7.2.1.3.1.1.

Типовой вид: План.

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

См. также: План управления информацией.

10.25 Процедура документации

ИСО/МЭК 20000-1 (IEEE 20000-1), ссылки: 4.3.1, 4.3.2.

ИСО/МЭК 20000-2 (IEEE 20000-1), ссылки: 4.1.3.1, 4.3.1.2, 4.3.2.

Типовой вид: Процедура.

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

Примечание - ISO/IEC/IEEE 26513 содержит дополнительную информацию о рассмотрении и одобрении документации.

См. также: План документации, план управления информацией.

10.26 План разработки домена

ISO/IEC/IEEE 12207, ссылка: 7.3.1.3.1.1.

Типовой вид: План.

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

10.27 Отчет об оценке

ISO/IEC/IEEE 15288, ссылка: 6.2.5.3.

ISO/IEC/IEEE 12207, ссылки: 6.1.2.3.4.5, 6.1.2.3.4.8, 6.1.2.3.4.15, 6.4.2.3.2.1, 6.4.3.3.2.1, 6.4.5.3.2.2, 6.4.6.3.1.2, 7.1.2.3.1.2, 7.1.3.3.1.6, 7.1.4.3.1.7, 7.1.5.3.1.5, 7.1.6.3.1.5, 7.1.7.3.1.3.

ИСО/МЭК 20000-1 (IEEE 20000-1-2013), ссылки: 6.3.3, 6.6.2.

ИСО/МЭК 20000-2 (IEEE 20000-2-2013), ссылки: 5.5, 6.3.4.3, 6.3.5, 9.2.3.2, 9.2.4, 9.3.4.

Типовой вид: Отчет.

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

См. также: Отчет аудита, отчет о мониторинге и контроле, отчет о ходе работы, протоколы анализа проекта, сервисный отчет, отчет об одобрении и отчет о проверке.

10.28 Процедура применения

ISO/IEC/IEEE 15288, ссылка: 6.4.4.3b).

Типовой вид: Процедура.

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

См. также: Процедура эксплуатационных испытаний, учебная документация.

10.29 План улучшения

ISO/IEC/IEEE 12207, ссылки: 6.2.1.3, 6.3.4.3.1.5.

ISO/IEC/IEEE 15288, ссылки: 6.2.1.3, 6.3.4.3.

ИСО/МЭК 20000-1 (IEEE 20000-1), ссылки: 4.5.5.1, 4.5.5.2.

ИСО/МЭК 20000-2 (IEEE 20000-2), ссылки: 4.5.5.1, 4.5.5.2, 6.1.3.1, 6.1.4, 9.2.3.3.

Типовой вид: План.

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

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

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

Примечание - ИСО/МЭК 15504 дает дополнительные рекомендации.

10.30 Процедура улучшения

ИСО/МЭК 20000-1 (IEEE 20000-1), ссылка: 4.5.5.1.

ИСО/МЭК 20000-2 (IEEE 20000-2), ссылка: 4.5.5.2.

Типовой вид: Процедура.

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

10.31 Процедура управления инцидентами

ИСО/МЭК 20000-1 (IEEE 20000-1), ссылки: 6.6.3, 8.1.

ИСО/МЭК 20000-2 (IEEE 20000-2), ссылки: 6.6.6, 8.1.2, 8.1.3.1, 8.1.4, 8.1.5.

Типовой вид: Процедура.

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

См. также: Процедура управления проблемами.

10.32 Отчет об инциденте

ИСО/МЭК 20000-1 (IEEE 20000-1), ссылки: 6.6.2, 6.6.3.

ИСО/МЭК 20000-2 (IEEE 20000-2:2013), ссылки: 6.6.3.4, 6.6.4, 8.1.5.

Типовой вид: Отчет.

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

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

Он может включать следующие элементы:

a) отчетный контрольный номер и связанную с ним контрольную информацию;

b) идентификацию лица, сообщившего об инциденте;

c) дату и время возникновения, эскалации, разрешения и закрытия инцидентов;

d) местоположение (окружающую среду) инцидента в элементе конфигурации системы, программного продукта или информации;

e) применимое условие договора или требование о соответствии;

f) причину, характер и воздействие (тяжесть) инцидента;

g) рекомендуемые или выполненные немедленные корректирующие действия;

h) возможность совершенствования, связанную с этим действием, ответственное лицо или организацию, а также установленный срок;

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

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

k) информацию о закрытии инцидента;

I) информацию из анализа организации (внутреннего).

Примечание - ИСО/МЭК 20000-1 (IEEE 20000-1) и ИСО/МЭК 20000-2 (IEEE 20000-2) различают инциденты и проблемы. Ответ на инцидент связан с восстановлением обслуживания пользователей, тогда как решение проблемы связано с выявлением и устранением причин инцидентов. Отчет о возможности аналогичен, но включает анализ потенциальных положительных событий.

См. также: Запрос на внесение изменений, инцидент (запись), отчет о проблеме, сервисный запрос (запись).

10.33 План управления информацией

ISO/IEC/IEEE 15288, ссылка: 6.3.6.3. D.4m).

ISO/IEC/IEEE 12207, ссылки: 6.2.3.3.3.2, 6.2.4.3.4.1, 6.2.4.3.4.5, 6.3.6.3.1, 6.3.6.3.2.5, 7.2.4.3.2.5.

Типовой вид: План.

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

a) описание процесса и деятельности для авторизации, разработки, пересмотра, хранения, передачи и поддержания знаний или информации в электронных и печатных СМИ;

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

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

d) положения для управления контентом или стратегии повторного использования и контроля версий (управление конфигурацией документов);

е) графики разработки, рассмотрения и одобрения информации;

f) сведения о получателях информации или лицах, имеющих доступ к ограниченной информации;

g) организационную политику и процесс хранения или удаления информации и записей после закрытия проекта.

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

См. также: План документации.

10.34 Процедура управления информацией

ИСО/МЭК 20000-1 (IEEE 20000-1), ссылка: 4.3.3.

ИСО/МЭК 20000-2 (IEEE 20000-2), ссылки: 4.3.3, 4.4.2.2, 6.1.3.4, таблица А.11.

Типовой вид: Процедура.

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

См. также: Процедура документации.

10.35 План информационной безопасности

ИСО/МЭК 20000-2 (IEEE 20000-2), ссылки: 6.6.2, 6.6.3.2, 6.6.4, таблица А.14.

Типовой вид: План.

План информационной безопасности включает следующее:

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

b) описание того, как внедряются требования к конфиденциальности, целостности и доступности информации;

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

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

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

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

g) процедуры анализа эффективности политики, процедур и действий в области информационной безопасности.

Примечание - ИСО/МЭК 27002 содержит рекомендации по управлению информационной безопасностью. ИСО/МЭК 27001 направлен на процессы управления информационной безопасностью (ISMS) для создания, внедрения, эксплуатации, мониторинга, анализа, поддержания и улучшения информационной безопасности.

10.36 Политика информационной безопасности

ISO/IEC/IEEE 12207, ссылка: 6.1.2.3.4.5 I).

ИСО/МЭК 20000-1 (IEEE 20000-1), ссылка: 6.6.1.

ИСО/МЭК 20000-2 (IEEE 20000-2), ссылки: 6.6.2, 6.6.3.1, 6.6.4, таблица А.7.

Типовой вид: Политика.

Политика информационной безопасности включает следующее:

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

b) цели сохранения конфиденциальности, целостности и доступности информации;

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

d) методологию управления рисками информационной безопасности;

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

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

10.37 Процедура информационной безопасности

ИСО/МЭК 20000-1 (IEEE 20000-1), ссылка: 6.6.2, 6.6.3.

ИСО/МЭК 20000-2 (IEEE 20000-2), ссылки: 6.6.4, таблица А.9.

Типовой вид: Процедура.

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

См. также: Процедура управления инцидентами.

10.38 План установки

ISO/IEC/IEEE 12207, ссылка: 6.4.7.3.1.1.

Типовой вид: План.

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

10.39 Отчет об установке

ISO/IEC/IEEE 12207, ссылка: 6.4.7.3.1.2.

Типовой вид: Отчет.

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

10.40 Отчет об интеграции и тестировании

ISO/IEC/IEEE 12207, ссылки: 6.4.5.3.1.1, 7.1.6.3.1.2.

ИСО/МЭК 20000-2 (IEEE 20000-2), ссылки: 6.3.5, 9.3.3.4, 9.3.4.

Типовой вид: Отчет.

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

10.41 План интеграции

ISO/IEC/IEEE 15288, ссылки: 6.4.4.3, 6.4.5.3.

ISO/IEC/IEEE 12207, ссылки: 7.1.6.3.1.1, 7.1.6.3.1.2, 7.1.6.3.1.5.

Типовой вид: План.

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

Примечание - При управлении сервисом может быть подготовлен план применения для проекта внедрения нового сервиса или улучшения существующего сервиса, как описано в ISO/IEC TR 20000-5.

См. также: План улучшения.

10.42 Описание интерфейса

ISO/IEC/IEEE 15288, ссылка: 6.4.4.3.

ISO/IEC/IEEE 12207, ссылки: 6.3.5.3.2.2, 6.4.3.2d), 7.1.3.3.1.2, 7.1.4.3.1.2.

ИСО/МЭК 20000-1 (IEEE 20000-1), ссылки: 4.5.2, 5.2, 7.2, 9.1.

ИСО/МЭК 20000-2 (IEEE 20000-2), ссылки: 4.2.4, 4.5.2.4, 5.2.8h), 7.2.4.

Типовой вид: Описание.

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

10.43 Политика и процедура жизненного цикла

ISO/IEC/IEEE 15288, ссылки: 6.2.1.1, 6.2.1.2, 6.2.3.3b) 1) iii), А.2.3, В.1.

ISO/IEC/IEEE 12207, ссылки: 6.2.1.1, 6.2.1.2, 6.2.1.3.1.1, 6.2.1.3.3.1, А.2.3.1.

Типовой вид: Политика, Процедура.

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

10.44 План технического обслуживания

ISO/IEC/IEEE 15288, ссылка: 6.4.10.3.

ISO/IEC/IEEE 12207, ссылки: 6.1.1.3.1.7, 6.4.10.1, 6.4.10.3.1.1, 7.3.2.3.3.6.

Типовой вид: План.

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

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

b) критерии проведения технического обслуживания;

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

d) результаты процесса технического обслуживания;

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

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

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

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

10.45 Процедура техобслуживания

ISO/IEC/IEEE 15288, ссылка: 6.4.10.3.

ISO/IEC/IEEE 12207, ссылка: 6.4.10.3.1.1.

ИСО/МЭК 20000-2 (IEEE 20000-2), ссылка:

Типовой вид: Процедура.

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

См. также: Процедура управления проблемами.

10.46 План измерений

ISO/IEC/IEEE 15288, ссылка: 6.3.7.3.

ISO/IEC/IEEE 12207, ссылки: 6.3.7.2c), 6.3.7.3.1.1, 6.3.7.3.1.3, 6.3.7.3.1.4, 6.3.7.3.2.1.

Типовой вид: План.

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

10.47 Отчет о мониторинге и контроле

ISO/IEC/IEEE 15288, ссылки: 6.3.2.3, 6.3.4.3b), 6.3.7.1, 6.3.7.3b).

ISO/IEC/IEEE 12207, ссылки: 6.1.2.3.4.8, 6.1.2.3.4.15, 6.3.2.3, 6.3.4.3.3.4, 6.3.4.3.6.3, 6.3.7.1, 6.3.7.3.2.4, 7.3.2.3.3.5, 7.3.2.3.3.7.

ИСО/МЭК 20000-1 (IEEE 20000-1), ссылка: 6.3.3.

ИСО/МЭК 20000-2 (IEEE 20000-2), ссылки: 6.1.4, 6.3.5.

Типовой вид: Отчет.

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

a) историю всех результатов мониторинга и контрольных действий и результатов индивидуальных проверок мониторинга;

b) измерения процессов и услуг по целям и требованиям;

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

d) действия, предпринятые для устранения недостатков в отношении доступности и непрерывности обслуживания;

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

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

10.48 Процедура оперативного тестирования

ISO/IEC/IEEE 12207, ссылки: 6.4.9.3.1.3, 6.4.9.3.2.2.

Типовой вид: Процедура.

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

См. также: Процедура квалификационных испытаний.

10.49 Процедура управления проблемами

ISO/IEC/IEEE 12207, ссылки: 6.2.1.3.2.1, 6.4.9.3.1.2, 6.4.9.3.1.3, 7.2.8.3.1.1.

ИСО/МЭК 20000-1 (IEEE 20000-1), ссылка: 8.2.

ИСО/МЭК 20000-2 (IEEE 20000-2), ссылки: 8.2.2, 8.2.3, 8.2.4.

Типовой вид: Процедура.

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

См. также: Процедура управления инцидентами.

10.50 Отчет о проблеме

ISO/IEC/IEEE 15288, ссылки: 6.3.3.3a) 2), 6.4.5.3b), 6.4.6.2b), 6.4.6.3b), 6.4.7.2e), 6.4.7.3b), 6.4.8.3b), 6.4.9.2c), 6.4.10.2e), 6.4.10.3b).

ISO/IEC/IEEE 12207, ссылки: 6.1.2.3.4.15, 6.3.2.3.2.1, 6.3.3.3.1.3, 6.3.3.3.3.1, 6.4.8.2, 6.4.8.3.1.1, 6.4.8.3.1.3, 6.4.9.3.1.3, 6.4.9.3.4.2, 6.4.9.3.5.2, 6.4.10.3.1.2, 6.4.10.3.2.1, 6.4.10.3.2.4, 7.1.1.3.1.2, 7.2.8.2f), 7.2.8.3.1.1, 7.2.8.3.2.1, 7.3.1.3.1.3, 7.3.2.3.3.6, 7.3.3.3.5.3, В.3.2.3.2.

ИСО/МЭК 20000-1 (IEEE 20000-1), ссылка: 8.2.

ИСО/МЭК 20000-2 (IEEE 20000-2), ссылка: 8.2.4.

Типовой вид: Отчет.

Отчет о проблеме (также называемый протоколом несоответствия или запросом корректирующих действий) сообщает о проблемах или несоответствии (отклонения) требованиям контракта. Это может быть консолидация проблемных записей. Отчет о проблеме служит в качестве вклада в процесс разрешения проблем ISO/IEC/IEEE 12207. Он должен включать информацию последующих действий по предотвращению проблем (извлеченных уроков) и выявлению дублирования вопросов и тенденций. Отчет о проблеме может включать:

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

b) идентификацию лица, сообщившего о проблеме;

c) дату и время возникновения проблемы, развитие, разрешение и закрытие;

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

e) применимое условие контракта или требование о соответствии;

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

g) анализ проблем и принятие решений, рекомендуемое решение или корректирующие действия;

h) связанные действия по устранению нарушений, ответственное лицо или организация, а также установленный срок;

i) ссылки на аналогичные проблемы, указанные ранее;

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

k) информацию о закрытии проблемы;

I) информацию из анализа организации (внутреннего).

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

Он может сообщать о временном или постоянном решении проблемы.

См. также: Запрос на внесение изменений, отчет об инциденте, запись проблемы.

10.51 Процедура оценки процесса

ISO/IEC/IEEE 12207, ссылка: 6.2.1.3.2.1.

Типовой вид: Процедура.

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

10.52 Аналитический отчет о процессе улучшения

ISO/IEC/IEEE 15288, ссылки: 6.2.1.3c), 6.3.7.3c).

ISO/IEC/IEEE 12207, ссылки: 6.2.1.3.3.2, В.3.3.1.2, В.3.3.2.2, В.3.3.3.2, 6.3.7.3.3.

Типовой вид: Отчет.

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

10.53 Оценка потребности в продукции

ISO/IEC/IEEE 15288, ссылка: 6.1.2.3.

ISO/IEC/IEEE 12207, ссылки: 6.1.1.2, 6.1.1.3.1.1.

Типовой вид: Отчет.

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

a) решение и обоснование приобретения, разработки или совершенствования системы, программного продукта или услуги;

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

Оценка потребности в продукции может включать следующее:

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

2) оценки технических, стратегических, экономических и рыночных оснований и исследований по вопросам компромиссов;

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

4) предварительную информацию о виде договора;

5) текущие и потенциальные организационные обязанности;

6) определение рисков и методы управления рисками.

См. также: Концепция операций.

10.54 Отчет о ходе выполнения работы

ISO/IEC/IEEE 15288, ссылки: 6.1.2.3, 6.2.3.3, 6.3.2.3, 6.3.3.2, 6.3.3.3.

ISO/IEC/IEEE 12207, ссылки: 6.1.2.3.4.15, 6.3.2.2, 6.3.2.3.1.1, 6.3.2.3.2.2, 6.3.3.2, 6.3.3.3.3.1, 6.3.3.3.3.1.

Типовой вид: Отчет.

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

См. также: Сервисный отчет.

10.55 План управления проектами

ISO/IEC/IEEE 15288, ссылки: 6.1.2.3, 6.2.3.3, 6.3.1.1, 6.3.1.2, 6.3.1.3.

ISO/IEC/IEEE 12207, ссылки: 6.1.1.3.4.3, 6.1.2.3.4.3, 6.1.2.3.4.5, 6.1.2.3.4.6, 6.2.2.3.1.2, 6.2.3.3.1.6, 6.2.3.3.2.1, 6.3.1.1, 6.3.1.2, 6.3.1.3.2.1, 6.3.1.3.3.3, 6.3.2.3.2.1, 6.2.3.3.1.6, 7.2.6.3.1.1, 7.2.6.3.2.1, F.3.3.5.3.

Типовой вид: План.

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

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

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

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

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

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

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

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

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

i) риски и анализ рисков для технических, стоимостных и графических рисков.

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

Он может включать следующее:

1) процедуры перепланировки;

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

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

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

См. также: План управления сервисами.

Примечания

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

2 ISO/IEC/IEEE 16326 дает подробные сведения о содержании плана управления проектами.

10.56 Предложение

ISO/IEC/IEEE 15288, ссылки: 6.1.1.3, 6.1.2.2, 6.1.2.3.

ISO/IEC/IEEE 12207, ссылки: 6.1.2.2b), В.3.2.1.2.

Типовой вид: Описание.

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

10.57 Процедура квалификационного испытания

ISO/IEC/IEEE 12207, ссылки: 6.1.1.3.6.1, 6.1.1.3.6.2, 6.4.5.3.2.1, 7.1.6.3.1.4, 7.2, 7.3.2.1.

Типовой вид: Процедура.

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

10.58 Отчет о квалификационных испытаниях

ISO/IEC/IEEE 12207, ссылки: 7.1.7.3.1.1, 7.1.7.3.1.3, 7.2.7.3.2.1.

Типовой вид: Отчет.

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

10.59 План управления качеством

ISO/IEC/IEEE 15288, ссылки: 6.2.5.3, 6.3.1.3.

ISO/IEC/IEEE 12207, ссылки: 6.1.2.3.4.3, 6.2.5.3.1.5, 6.3.1.3, 7.2.3.3.1.3.

Типовой вид: План.

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

a) цели проекта или организации по обеспечению качества и политику организации по обеспечению качества;

b) планы улучшения продуктов или услуг;

c) планы оценки продуктов и сервиса, требования оценки, критерии, обязанности и распределение стандартов,

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

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

f) управление конфигурацией записей, связанных с качеством;

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

h) оценку практики управления конфигурацией для систем или элементов конфигурации программного обеспечения и носителей;

i) необходимую координацию деятельности по обеспечению качества программного продукта с другими проектами.

10.60 Политика и процедура управления качеством

ISO/IEC/IEEE 12207, ссылки: 6.2.5.2, 6.2.5.3.1.1.

ISO/IEC/IEEE 15288, ссылки: 6.2.5.2, 6.2.5.3.

Типовой вид: Политика, Процедура.

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

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

10.61 План выпуска версий (и политика)

ISO/IEC/IEEE 12207, ссылки: 6.4.10.3.5.2, 6.4.11.3.2.1.

ИСО/МЭК 20000-1 (IEEE 20000-1), ссылка: 9.3.

ИСО/МЭК 20000-2 (IEEE 20000-1), ссылки: 9.3.3.1, 9.3.3.2, 9.3.4.

Типовой вид: План.

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

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

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

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

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

d) планы по отмене или исправлению неуспешного выпуска (план возмещения непредвиденных расходов);

e) как освобождение предоставляется, планируется, координируется и отслеживается.

План миграции включает следующее:

1) описание результатов;

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

3) ожидаемую конфигурацию целевой среды во время миграции;

4) планы резервирования или восстановления;

5) процедуры проверки и принятия;

6) общение с клиентом и вспомогательным персоналом, и обучение.

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

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

Политика выпуска устанавливает следующее:

a) ожидаемую частоту и виды выпусков, включая аварийные;

b) разрешение на выпуск в приемочном испытании и производственных средах;

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

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

e) подход для автоматизации выпусков;

f) подход для проверки (тестирования) и принятия выпуска.

См. также: План и политика управления конфигурацией, процедура управления конфигурацией (процедура выпуска).

10.62 Заявка на подряд (RFP)

ISO/IEC/IEEE 15288, ссылка: 6.1.1.3.

ISO/IEC/IEEE 12207, ссылки: 4.24, 4.36, 6.1.1.3.1.10, 6.1.1.3.1.11, 6.1.1.3.2.1, 6.1.2.2, 6.1.2.3.2.1, 6.1.2.3.2.3, 6.4.1.3.2.1.

Типовой вид: Запрос.

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

a) системные требования заинтересованных сторон;

b) заявление об области применения;

c) инструкции участника;

d) объем задач, на которые необходимо ссылаться в проекте контракта;

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

f) условия;

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

h) контроль над субконтрактами;

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

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

Он может определить критерии выбора поставщика.

Примечание - Фактическое содержание зависит от правовой среды. Также известны как требования к приобретению, документ о приобретении, конкурс проектов (CFP), приглашение к участию в тендере (ITT), запрос тендера.

10.63 Запрос ресурсов

ISO/IEC/IEEE 15288, ссылки: 6.3.1.3d), 6.3.2.3b).

ISO/IEC/IEEE 12207, ссылка: 6.3.1.3.3.2.

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

10.64 План повторного использования

ISO/IEC/IEEE 12207, ссылки: 7.3.3.1, 7.3.3.3.2.1, 7.3.3.3.3.3, 7.3.3.3.4.1, 7.3.3.3.4.2, 7.3.3.3.4.3, 7.3.3.3.5.2.

Типовой вид: План.

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

10.65 Протокол анализа проекта

ISO/IEC/IEEE 12207, ссылки: 6.1.2.3.4.15, 6.4.10.3.5.6, 7.2.6.2, 7.2.6.3.1.5.

ИСО/МЭК 20000-1 (IEEE 20000-1), ссылки: 4.5.4.1, 4.5.4.3, 6.1, 7.1, 7.2.

ИСО/МЭК 20000-2 (IEEE 20000-2), ссылки: 4.1.1.2, 4.1.2.1f), 6.1.4, 7.1.4, 7.2.4, 8.2.4f).

Типовой вид: Отчет.

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

10.66 Запрос на осуществление рискованных действий

ISO/IEC/IEEE 15288, ссылка: 6.3.4.3.

ISO/IEC/IEEE 12207, ссылка: 6 3.4.3.2.3, 6.3.4.3.4.1.

Типовой вид: Запрос

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

10.67 Политика и план управления рисками

ISO/IEC/IEEE 15288, ссылка: 6.3.4.3.

ISO/IEC/IEEE 12207, ссылки: 6.3.4.3.1.1, 6.3.4.3.1.2, 6.3.4.3.2.1.

Типовой вид: План, Политика.

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

Примечание - ИСО/МЭК 16085 содержит дополнительные рекомендации.

10.68 Каталог услуг

ИСО/МЭК 20000-1 (IEEE 20000-1), ссылки: 4.3.1, 5.3, 6.1.

ИСО/МЭК 20000-2 (IEEE 20000-2), ссылки: 4.3.1.1, 6.1.3.2, 6.1.3.3, 6.1.3.4, 6.1.4.

Типовой вид: Описание.

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

См. также: Процедура подачи жалоб, план управления рисками.

10.69 План обеспечения непрерывности и доступности сервиса

ИСО/МЭК 20000-1 (IEEE 20000-1), ссылки: 6.3.1, 6.3.2.

ИСО/МЭК 20000-2 (IEEE 20000-2), ссылки: 4.1.1.5, 6.3.2, 6.3.3.2, 6.3.3.3, 6.3.4, 6.3.5, таблица А.4.

Типовой вид: План.

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

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

b) целевые показатели доступности для восстановления услуг;

c) влияние бизнеса на недоступность услуг в течение различных периодов и приоритетность в восстановлении услуг;

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

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

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

g) процедуры восстановления сервиса;

h) процедуры проверки плана непрерывности;

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

См. также: План проверки.

10.70 Соглашение об уровне обслуживания (SLA)

ИСО/МЭК 20000-1 (IEEE 20000-1), ссылки: 3.29, 4.3.1, 5.3, 6.1, 7.2.

ИСО/МЭК 20000-2:2912 (Стандарт IEEE 20000-2:2013), ссылки: 4.1.1.3, 4.3.1.1, 5.3.1, 5.5, 6.1.3.3, 6.1.3.4, 6.1.4, 7.2.2, 7.2.3.2.

Типовой вид: Спецификация.

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

a) требования и объем обслуживания;

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

c) обязанности поставщика и клиента;

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

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

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

g) процесс коммуникации для периодической отчетности о достигнутом уровне обслуживания для клиента.

10.71 План управления сервисами

ISO/IEC/IEEE 12207, ссылка: 6.4.9.3.1.1.

ИСО/МЭК 20000-1 (IEEE 20000-1), ссылки: 4.1.1, 4.1.2, 4.3.1, 4.5.1, 4.5.2.

ИСО/МЭК 20000-2 (IEEE 20000-2), ссылки: 4.1.1.1, 4.1.1.4, 4.1.1.5, 4.1.1.6, 4.1.2.1, 4.1.2.2, 4.1.3.1, 4.1.4.2, 4.3.1.1, 4.5.2.1, 4.5.2.2, 4.5.2.3, 4.5.3, 4.5.4.1, 7.1.3.1.

Типовой вид: План.

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

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

Он определяет следующее:

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

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

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

d) ограничения и лимиты, влияющие на систему управления сервисами;

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

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

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

h) как организация измеряет, проверяет, сообщает и улучшает SMS и сервис.

См. также: План аудита, процедура подачи жалоб, план реализации, план улучшения, спецификация интерфейса, план управления информацией, план управления проектами, план утилизации, план управления рисками, план обслуживания.

10.72 План обслуживания

ИСО/МЭК 20000-1 (IEEE 20000-1), ссылки: 5.2, 5.3.

ИСО/МЭК 20000-2 (IEEE 20000-2), ссылки: 5.2.7, 5.3.3.1, 5.4, 5.5.

Типовой вид: План.

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

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

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

c) анализ рисков, связанных с новым сервисом, и риски для существующего сервиса;

d) критерии тестирования и приемки нового или измененного сервиса;

e) обязанности и полномочия по предоставлению услуг;

f) планирование коммуникации;

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

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

10.73 Сервисный отчет

ISO/IEC/IEEE 12207, ссылка: 6.2.5.3.1.4.

ИСО/МЭК 20000-1 (IEEE 20000-1), ссылки: 4.1.4е, 4.5.3.f, 4.5.5.2, 5.4, 6.2, 7.2.

ИСО/МЭК 20000-2 (IEEE 20000-2), ссылки: 4.1.1.1, 4.1.4.4, 4.5.4.1, 4.5.4.2, 5.2.8, 5.4, 5.5, 6.1.2, 6.1.3.1, 6.1.3.4с), 6.1.4, 6.2.1, 6.2.2, 6.2.3, 6.3.2, 6.3.4.3, 6.4. 6.5.3.1, 6.5.4, 7.1.4, 7.2.3.1, 8.1.2, таблица А.3, таблица А.7, таблица А.8.

Типовой вид: Отчет.

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

См. также: Отчет аудита, отчет об оценке, отчет об инциденте, отчет о мониторинге и контроле, отчет о ходе работы.

10.74 Описание архитектуры программного продукта

ISO/IEC/IEEE 12207, ссылки: 6.4.3.2, 6.4.3.3.1.1, 7.1.1.2, 7.1.3.2, 7.1.3.3.1, 7.1.3.3.1.1, 7.3.1.2, 7.3.1.3.3.1, 7.3.1.3.3.3.

Типовой вид: Описание.

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

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

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

c) определения точек зрения для документирования процедур создания, интерпретации, анализа и оценки данных архитектуры;

d) одно или несколько мнений о системе. Каждый вид архитектуры представляет собой отражение полной системы с точки зрения одной или нескольких проблем для ее заинтересованных сторон.

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

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

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

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

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

5) обеспечение основы для спецификации требований к программному продукту и уточнения дизайна.

Описание архитектуры программного продукта может содержать следующее:

- концепцию операций с точки зрения ее элементов;

- модель домена или эталонная архитектура для семейства или системы программных систем.

См. также: описание архитектуры системы.

Примечание - Описание архитектуры программного продукта можно рассматривать как спецификацию для разработки программного продукта. Дополнительная информация об описании архитектуры приведена в ISO/IEC/IEEE 42010.

10.75 Описание дизайна программного продукта

ISO/IEC/IEEE 12207, ссылки: 6.4.10.2, 6.4.10.3.3.1, 7.1.1.3.1.2, 7.1.4.3.1.1, 7.2.2.3.5.1, 7.3.1.3.3.3.

Типовой вид: Описание.

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

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

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

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

d) концепцию исполнения, включая поток данных и поток управления;

e) соображения безопасности;

f) элементы повторного использования;

g) обработку ошибок.

Описание дизайна программного продукта должно включать следующее:

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

2) спецификацию протоколов;

3) разбивку программного продукта на объекты проектирования и описание важных свойств и отношений между этими объектами.

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

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

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

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

d) решения, влияющие на выбор и проектирование элементов программного продукта, составляющих элемент программного продукта;

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

f) характеристики интерфейса одной или нескольких систем, подсистем, аппаратных элементов, программных элементов, ручных операций или других системных компонентов.

Описание дизайна программного продукта должно включать следующее:

- описание размера, частоты или других характеристик элементов данных;

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

- спецификацию протоколов.

См. также: Описание системного элемента.

Примечание - В IEEE 1016 приведены дополнительные рекомендации.

10.76 Спецификация требований к программному продукту

ISO/IEC/IEEE 12207, ссылки: 6.1.1.3.1.2, 6.1.1.3.1.7, 6.1.1.3.1.8, 6.1.1.3.1.11, 6.4.11.2, 7.1.2.2, 7.1.2.3.1.1, 7.1.3.3.1.5.

Типовой вид: Спецификация.

Спецификация требований к программному продукту включает в себя следующее:

a) приоритетность и критичность требований;

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

c) предположения и зависимости продукта;

d) ссылки на стандарты и процедуры проектирования и испытаний;

e) функции продукта и функциональные требования системы;

f) бизнес-требования, организационные и пользовательские системные требования;

g) требования к инженерно-техническим характеристикам человека (эргономика);

h) требования к критичности системы;

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

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

k) конструктивные ограничения и требования к проектированию системы;

I) требования к системе тестирования и квалификации;

m) требования приемки;

n) требования к адаптации сайта;

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

p) требования к упаковке, установке, эксплуатации, обновлению продукта и обслуживанию.

См. также: Спецификация системных требований.

Каждое требование должно быть идентифицировано однозначно.

Примечание - ISO/IEC/IEEE 29148 содержит дополнительные рекомендации.

10.77 Описание программного продукта

ISO/IEC/IEEE 12207, ссылка: 7.1.5.3.1.1.

Типовой вид: Описание.

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

10.78 Процедура тестирования программного продукта

ISO/IEC/IEEE 12207, ссылки: 6.4.10.3.3.2, 7.1.4.3.1.5, 7.1.5.3.1.1.

Типовой вид: Процедура.

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

10.79 Протокол испытаний программного продукта

ISO/IEC/IEEE 12207, ссылки: 6.4.10.3.3.2, 7.1.5.3.1.2.

Типовой вид: Отчет.

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

10.80 Процедура управления поставщиками

ИСО/МЭК 20000-1:2011 (IEEE 2000-1:2013), ссылка: 7.2.

ИСО/МЭК 20000-2:2012 (IEEE 2000-2:2013), ссылки: 7.2.2, 7.2.3.1, 7.2.5.

Типовой вид: Процедура.

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

См. также: Контракт, план управления проектами.

10.81 Процедура выбора поставщика

ISO/IEC/IEEE 12207, ссылка: 6.1.1.3.3.1.

Типовой вид: Процедура.

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

10.82 Описание архитектуры системы

ISO/IEC/IEEE 15288, ссылки: 6.3.1.3, 6.4.3.1, 6.4.3.2, 6.4.3.3.

Типовой вид: Описание.

Описание архитектуры системы включает в себя следующее:

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

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

c) определение точек зрения для документирования процедур создания, интерпретации, анализа и оценки данных архитектуры;

d) один или несколько видов системы. Каждая архитектура представляет собой отображение полной системы сточки зрения одной или нескольких проблем системы, для ее заинтересованных сторон.

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

1) включение информации о прослеживаемости к системным требованиям;

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

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

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

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

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

- представить модель домена или эталонную архитектуру для семейства систем или системы.

См. также: Описание интерфейса, описание архитектуры программного обеспечения.

Примечание - Описание архитектуры системы можно рассматривать как спецификацию для проектирования системы. Дополнительная информация приведена в ISO/IEC/IEEE 42010.

10.83 Описание системного элемента

ISO/IEC/IEEE 15288, ссылка: 6.4.3.2.

Типовой вид: Описание.

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

10.84 Спецификация к системным требованиям

ISO/IEC/IEEE 12207, ссылки: 6.2.2.2, 6.2.2.3.1.1, 6.2.2.3.2.1, 6.4.1.2, 6.4.1.3.2, 6.4.2.2, 6.4.2.3.1.1.

ISO/IEC/IEEE 15288, ссылки: 6.1.1.3, 6.2.2.2, 6.3.1.3, 6.4.1.3, 6.4.2.2, 6.4.2.3.

ИСО/МЭК 20000-1 (IEEE 20000-1), ссылки: 3.34, 4.5.2, 5.1, 5.2, 5.3, 7.1.

ИСО/МЭК 20000-2 (IEEE 20000-2), ссылки: 4.1.1.7, 4.1.1.8, 4.1.1.9, 4.3.1.1, 5.2.5, 6.1.2.

Типовой вид: Спецификация.

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

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

Спецификация системных требований включает в себя следующее:

a) технические характеристики выбранной системы;

b) спецификации использования для предполагаемого взаимодействия человека и системы;

c) функции системного уровня;

d) требования безопасности и охраны;

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

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

Каждое требование должно быть однозначно идентифицировано.

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

Примечания

1 ISO/IEC/IEEE 12207 относится к спецификации технических требований, когда программный продукт считается системой.

2 ISO/IEC/IEEE 29148 содержит дополнительные рекомендации.

См. также: Концепция операций, спецификация требований к программному обеспечению.

10.85 Учебная документация

ISO/IEC/IEEE 12207, ссылки: 6.2.4.3, В.3.4.1.2.

ISO/IEC/IEEE 15288, ссылка: 6.2.4.3.

Типовой вид: Процедура.

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

10.86 План обучения

ISO/IEC/IEEE 12207, ссылки: 6.2.4.3.2.1, 6.2.4.3.2.3, 6.2.4.3.4.1.

ISO/IEC/IEEE 15288, ссылка: 6.2.4.3.b).

ИСО/МЭК 20000-2 (IEEE 20000-2), ссылка: 6.6.3.4.

Типовой вид: План.

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

10.87 Документация пользователя

ISO/IEC/IEEE 15288, ссылка: 6.4.9.3.

ISO/IEC/IEEE 12207, ссылки: 6.1.1.3.1.7b), 6.4.9.3.3.1, 6.4.9.3.4.1, 6.4.10.2, 7.1.1.3.1.2, 7.1.3.3.1.4, 7.1.4.3.1.4, 7.1.5.3.1.3, 7.1.6.3.1.3, 7.1.7.3.1.2, 7.2.7.3.2.1.

ИСО/МЭК 20000-2 (IEEE 20000-2:2013), ссылка: 9.3.4.

Типовой вид: Процедура.

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

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

a) краткое описание целевого использования системы (концепция операций);

b) предупреждения, предостережения и примечания с корректирующими действиями;

c) предоставленные и требуемые ресурсы и операционную среду (аппаратно-программная платформа);

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

e) процедуры устранения неполадок и исправления ошибок;

f) наличие проблемных отчетов и помощи.

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

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

10.88 Уведомление пользователя

ISO/IEC/IEEE 12207, ссылки: 6.4.10.3.5.3, 6.4.10.3.5.5, 6.4.11.3.2.2, 7.3.2.3.3.8.

Типовой вид: Отчет.

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

10.89 План одобрения

ISO/IEC/IEEE 15288, ссылка: 6.4.8.3.

ISO/IEC/IEEE 12207, ссылка: 7.2.5.3.1.4.

Типовой вид: План.

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

Примечание - IEEE 829 содержит дополнительные сведения.

10.90 Отчет одобрения

ISO/IEC/IEEE 15288, ссылка: 6.4.8.3.

ISO/IEC/IEEE 12207, ссылка: 7.2.5.3.1.4d).

Типовой вид: Отчет.

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

10.91 Спецификация проверочного теста

ISO/IEC/IEEE 12207, ссылки: 7.2.5.3.2.1, 7.2.5.3.2.2, 7.2.7.3.2.1.

Типовой вид: Спецификация.

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

10.92 План проверки

ISO/IEC/IEEE 15288, ссылка: 6.4.6.3.

ISO/IEC/IEEE 12207, ссылки: 7.2.4.3.1.5, 7.2.4.3.1.6.

ИСО/МЭК 20000-2 (IEEE 20000-2), ссылки: 6.3.5, 9.3.3.4, 9.3.4.

Типовой вид: План.

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

a) стратегию проверки и порядок проведения проверки;

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

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

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

e) предварительные требования к тестированию и график интеграции программного продукта;

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

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

h) цели тестов, сопоставление тестов и охваченных требований;

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

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

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

I) описание тестовой среды, инструментов тестирования и вспомогательного оборудования и программного продукта;

m) подготовку к тестам или тестовые образцы, которые необходимо собрать или построить;

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

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

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

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

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

s) риски, связанные с планом.

План проверки может включать следующее:

- уровень целостности программного обеспечения и схему;

- оставшиеся недостатки, лимиты или ограничения в системе;

- влияние тестовой среды;

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

Примечание - IEEE 829 содержит дополнительные сведения.

10.93 Отчет о проверке

ISO/IEC/IEEE 15288, ссылка: 6.4.6.3b).

ISO/IEC/IEEE 12207, ссылка: 7.2.4.3.1.5.

Типовой вид: Отчет.

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

См. также: Отчет об оценке.

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

Порядок идентификации информационных элементов и их содержимого

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

1) Изучить и адаптировать (по мере необходимости) ISO/IEC/IEEE 15288 или ISO/IEC/IEEE 12207 для определения модели жизненного цикла системы или программного продукта для проекта, что включает в себя любой подход к управлению информацией. В случае определения требований и рекомендаций по управлению сервисами необходимо рассмотреть ИСО/МЭК 20000-1 (IEEE 20000-1) и ИСО/МЭК 20000-2 (IEEE 20000-2).

2) Изучить раздел 8, таблицы 1, 2 и 3 настоящего стандарта для сопоставления информационных элементов с организациями и процессами и сервисами жизненного цикла проекта.

3) Адаптировать раздел 8, таблицы 1, 2 и 3 настоящего стандарта для удовлетворения потребностей и требований в информации и документации проекта.

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

Примечание - Этот пункт выполняется на основе применимых соглашений и организационных политик.

5) Определить цель каждого информационного элемента и его необходимого содержимого для жизненного цикла системы или программного продукта, организации и проекта или сервиса, используя разделы 9 и 10 настоящего стандарта.

6) Адаптировать и завершить требования к содержимому каждого необходимого информационного элемента.

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

8) Изучить таблицы 1, 2 и 3 для определения источников исходных данных информационных элементов.

Примечание - Источники информации могут включать записи, организационные данные и другие рабочие продукты, такие как модели и моделирование.

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

10) Определить процедуры управления конфигурацией версий промежуточных и конечных информационных элементов.

11) Определить качественные характеристики каждого элемента информации и вида информации.

12) Определить, как оцениваются качественные характеристики для каждого информационного элемента и вида информационных элементов.

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

14) Определить сроки хранения архивных информационных элементов и варианты носителей для хранения, например, на бумаге или диске.

15) Включить действия и результаты вышеуказанных действий в план документации или управления информацией.

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

Информационные элементы и записи по источникам

Таблица В.1 - Информационные элементы и записи по источникам

Таблица В.2 - Классификация записей по источнику информации

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

Сведения о соответствии ссылочных международных стандартов национальным стандартам

Таблица ДА.1

Библиография

_______________

ISO/IEC/IEEE 24765 периодически публикуется как "моментальный снимок" базы данных SEVOCAB (системная и программная инженерия), которая общедоступна на веб-сайте <www.computer.org/sevocab>.

Электронный текст документа

и сверен по:

, 2019