Полное меню
- Актуальное
законодательство - Интернет
и право- - Рассылка ''Закон есть закон''
- - Форум сайта (архив)
- - Законодательство
- - Судебная практика (необычная)
- - Судебная практика (авторская)
- - Процедура UDRP и и решения WIPO
- - Книги серии ''Интернет и Право''
- - Книги в открытом доступе
- - Учебный курс ''Интернет и Право''
- - Учебный курс ''Доменные споры''
- - Литература по ''Интернет и Право''
- - Литература по интел. собственности
- - Научный уголок (работы гостей)
- - Авторские публикации
- Информационные
материалы - ЮРИДИЧЕСКИЕ
УСЛУГИ- - Перечень юридических услуг
- - Карта юридических услуг
- - Юридическая консультация
- - Доменные споры (RU), авторское право
- - Международный суд по доменам (COM)
- - Защита прав на маркетплейсе (WB, Ozon)
- - Защита прав в соцсетях (Vk, Ok, FB)
- - Купля-продажа домена, сайта, ПО
- - Досудебное урегулирование конфликта
- - Защита чести и деловой репутации
- - Отмена блокировки сайта/домена РКН
- - ФАС: товарные знаки, авторское право
- - Регистрация ПО/сайта (Роспатент)
- - Юридическая проверка домена
- - Нотариальное заверение сайтов
- - Способы и формы оплаты услуг
- - Мы в СМИ
- - О компании, клиенты
- - Наши дела и победы
- - Контакты и реквизиты
- Информация
о сайте -
ОписаниеИсточник публикации М.: Стандартинформ, 2019 Примечание к документу Документ введен в действие с 01.01.2021. Название документа "ГОСТ Р 58609-2019/ISO/IEC/IEEE 15289:2017. Национальный стандарт Российской Федерации. Системная и программная инженерия. Состав и содержание информационных элементов жизненного цикла (документации)" (утв. и введен в действие Приказом Росстандарта от 22.10.2019 N 1045-ст) "ГОСТ Р 58609-2019/ISO/IEC/IEEE 15289:2017. Национальный стандарт Российской Федерации. Системная и программная инженерия. Состав и содержание информационных элементов жизненного цикла (документации)"
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
критическая информация (critical information): Информация, описывающая способы безопасного использования программного средства, способы обеспечения безопасности информации, созданной с помощью программного средства, или способы защиты конфиденциальной личной информации, созданной или сохраненной с помощью программных продуктов. [ИСО/МЭК 26514:2008] |
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
политика (policy): Четкое и измеримое одобрение предпочтительного направления и поведения для определения решений, принятых в рамках организации. [ИСО/МЭК 38500:2008 <1>] |
--------------------------------
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): Информационный элемент, который может быть проверен лицом или инструментом на предмет правильности.
В настоящем стандарте использованы следующие сокращения:
CFP - конкурс проектов;
CM - управление конфигурацией;
COTS - изделие, доступное на широком коммерческом рынке;
ITT - приглашение на тендер;
RFP - заявка на подряд;
SLA - соглашение об уровне обслуживания;
SMS - система управления сервисом.
Целью настоящего стандарта является предоставление требований для пользователей 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) Руководства единственной стороны при выполнении самостоятельных задач.
Настоящий стандарт предназначен следующим пользователям:
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) лицам, осуществляющим улучшение обслуживания систем или программного продукта в своих организациях.
Использование настоящего стандарта не ограничивается размером, сложностью или критичной важностью проекта. Он может применяться к следующему:
a) любому виду проекта и процессу жизненного цикла;
b) любым видам деятельности и задачи проекта;
c) системному или программному продукту, либо сроку службы;
d) всем формам информационных элементов, содержимому информационных материалов и средств доставки документов;
e) документации изделий, доступных на широком коммерческом рынке (COTS), когда изделие COTS указано в качестве поставки в двухсторонней ситуации.
Примечание - См. ISO/IEC/IEEE 12207, 1.2.
Пользователи настоящего стандарта должны определить взаимосвязь требований в настоящем стандарте с требованиями и потребностями их получателей (клиентов или пользователей информации) или проектных и организационных процедур. Вид решения, которое должно быть принято, или работа, которая должна быть выполнена пользователями информации, должна быть рассмотрена до подготовки информационного элемента. Анализ и понимание требований, потребностей и опыта пользователей и заинтересованных сторон имеют важное значение для правильного и экономичного применения настоящего стандарта, поскольку некоторые информационные элементы ставят различные цели и предназначены для различных групп пользователей:
a) предоставлять информацию специализированным видам пользователей, которые не могут быть частью конкретного проекта;
b) обращаться к тому же виду пользователя, но в средах, которые обычно не сосуществуют в тех же усилиях;
c) оказывать помощь пользователям, которые, как ожидается, понимают технические концепции и терминологию, а также пользователям, которые могут не обладать такими знаниями.
Настоящий стандарт может использоваться в качестве соответствия или руководящего документа для проектов и организаций, утверждающих соответствие 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. При адаптации информационные элементы, представленные в настоящем стандарте, могут быть изменены (добавлены, объединены или переименованы). Содержимое информационных элементов должно соответствовать выбранным и адаптированным процессам.
Примечание - В приложении A к ISO/IEC/IEEE 15288 и ISO/IEC/IEEE 12207 содержатся требования к процессу адаптации.
В настоящем стандарте для удобства ссылки каждый информационный элемент описывается так, как если бы он был опубликован как отдельный документ. Однако информационные элементы считаются соответствующими, если они не опубликованы, но доступны в репозитории для ссылки, разделены на отдельные документы или тома или объединены с другими информационными элементами в один документ. Использование номенклатуры конкретных записей в разделе 9 или заголовков информационных элементов в разделе 10 для подтверждения соответствия настоящему стандарту не требуется.
В настоящем стандарте слово "будет" используется для передачи положения, которое является нормативным, "должен" выражать рекомендацию среди других возможностей и "может" указывать ход действий, допустимых в пределах настоящего стандарта.
Глагол "включать", используемый в настоящем стандарте, указывает, что (1) есть информация или (2) указывается ссылка на информацию.
Соответствие может быть заявлено для организаций, проектов, проектов с несколькими поставщиками, сервисов и информационных элементов, указанных в заявлении о соответствии:
a) Когда соответствие подтверждено в отношении организации и поставщика услуг, организация или поставщик услуг должны представить документ, в котором подтверждается его адаптация записей и информационных элементов, а также его интерпретация любых положений настоящего стандарта, в которых указывается "контракт".
b) Если соответствие подтверждается в отношении проекта (или программы), планы проекта или контракт должны документировать адаптацию записей и информационных элементов и интерпретацию любых положений настоящего стандарта, в которых указывается "контракт".
c) Если соответствие подтверждается в отношении проектов с несколькими поставщиками, может случиться так, что ни один отдельный проект может не требовать соответствия, поскольку ни один контракт не требует всех необходимых записей и информационных элементов. Тем не менее, проекты в целом могут требовать соответствия, если каждая из необходимых записей и информационных элементов создается идентифицированной стороной. Планы программы должны документировать адаптацию записей и информационных элементов и их назначение различным сторонам, а также интерпретацию любых положений настоящего стандарта, в которых указывается "контракт".
d) Если соответствие подтверждается в отношении информационного элемента, элемент должен содержать типовые данные, приведенные в разделе 7 настоящего стандарта, и конкретный контент, необходимый согласно разделу 10.
Примечания
1 Один из возможных способов организации в отношении пунктов, в которых указан "контракт", заключается в том, чтобы указать, что они будут интерпретироваться в проектных планах по каждому конкретному проекту. Требование о соответствии проекта обычно указывается в отношении требования организации о соответствии.
2 В соответствии с ИСО/МЭК 17000 организация или проект, или программа, с несколькими поставщиками может считаться соответствующей настоящему стандарту, когда продукты (информационные элементы) соответствуют требованиям, но организация, проект или программа не выполнили конкретные требования к соответствию, указанные в пунктах (a), (b) или (c), приведенных выше.
Утверждается один из следующих видов соответствия. Выбранный вид должен быть идентифицирован в заявлении о соответствии:
a) Индивидуальное: минимальный набор требуемых информационных элементов определяется путем адаптации процессов и видов деятельности в соответствии с приложением A к ISO/IEC/IEEE 12207 или приложением A к ISO/IEC/IEEE 15288.
b) Абсолютное: минимальный набор требуемых информационных элементов - это все элементы, которые указаны в качестве нормативных (то есть положения, содержащие "будут") в тексте нормативных эталонных стандартов.
Абсолютное соответствие может быть подтверждено в отношении отдельных процессов или информационных элементов, даже если абсолютное соответствие всем требованиям настоящего стандарта не требуется.
В настоящем стандарте указывается, как управлять данными жизненного цикла в информационных элементах. Необходимые данные из жизненного цикла или сервисного процесса должны быть организованы в записи и представлены в одном или нескольких информационных элементах и должны соответствовать виду информационного элемента. Информационный элемент должен содержать его типовые информационные данные (раздел 7).
Каждый набор записей и каждый информационный элемент, созданный в качестве документа, описанного в настоящем стандарте, должен поддерживать следующие характеристики данных жизненного цикла:
a) недвусмысленность;
b) завершенность;
c) возможность проверки;
d) последовательность;
e) модифицируемость;
f) прослеживаемость;
g) презентабельность.
Запись представляет собой особый вид документированной информации, содержащей набор структурированных данных, рассматриваемых как единое целое. В таблице 4 в разделе 9 определены записи. В соответствии с ИСО 9000 целью записи является фиксирование достигнутых результатов или предоставление доказательств выполненных действий. Фактически, ИСО/МЭК 20000-1 (IEEE 20000-1) рассматривает любой документ или информационный элемент как запись. Однако в настоящем стандарте различаются записи данных и документов (информационные элементы).
Записи данных обретают ценность в сочетании с другими записями в наборе, как правило, путем включения в структурированные базы данных, регистры или репозитории, где отдельные записи доступны для извлечения и анализа. Записи содержат фактические данные (доказательства) для других универсальных информационных видов. Данные могут быть объединены в записи, и эти записи могут быть включены в отчет, который уже определен как конкретный информационный элемент (например, отчет об испытаниях), или они могут существовать отдельно для других видов использования, определенных проектом. Единая запись, выбор записей или полный список содержимого репозитория не подходит для выпуска в качестве полного коммуникационного продукта, как и информационные элементы (документы), такие как план или процедура. Информационные элементы (документы) создаются и передаются для использования людьми и содержат формальные элементы (такие как цель, объем и краткое изложение), предназначенные для их использования целевой аудиторией.
Данные жизненного цикла являются результатом выполнения процессов и задач системы управления деятельностью или задачами. Данные могут быть рабочим продуктом или элементом в других информационных элементах. Многие из статей в ISO/IEC/IEEE 15288 и ISO/IEC/IEEE 12207 требуют, чтобы данные о жизненном цикле были созданы или записаны. Тем не менее, положения ISO/IEC/IEEE 15288 и ISO/IEC/IEEE 12207 не определяют содержание, местоположение, формат или носитель, которые будут использоваться для записи и сохранения данных. При выборе подходящих данных, которые должны быть записаны, руководители записей должны также определять, где должны записываться в системе ведения документации организации или проекта данные. Записи могут храниться в базах данных, реестрах, репозиториях, архивах или других системах управления данными. Организации или проекты должны устанавливать политику хранения записей с учетом требований к жизненному циклу системы, а также потребностей в организации или управлении сервисами в отношении данных. Раздел 9 определяет содержание универсальных записей и рекомендует контент для конкретных записей.
Примечание - Требования и руководство по управлению записями приведены в ИСО/МЭК 16175.
Управление информационными элементами должно выполняться путем применения процесса управления информацией 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 к настоящему стандарту приводится краткая процедура определения и планирования информационных элементов и их содержимого. Информационные элементы должны быть определены как применимые к нескольким связанным процессам, используемым проектом или организацией, или к связанным с ними услугам (таким как управление инцидентами и проблемами). Информационные элементы могут объединяться или подразделяться в соответствии с проектами, сервисами или системными процессами, этапами и потребностями заинтересованных сторон.
Процесс управления информацией должен дать следующие результаты:
a) идентифицируется информация для управления;
b) определены представления информации;
c) информация получена, разработана, преобразована, сохранена, проверена, представлена и удалена;
d) определяется статус информации;
e) информация предоставляется назначенным заинтересованным сторонам.
6.4.1 Разработка плана документации
Задачи, которые должны быть выполнены в процессе управления информацией, должны быть указаны в Плане документации. При разработке Плана документации следует учитывать политику и процедуры приобретателя и поставщика. Процесс управления информацией для каждого проекта должен рассматриваться как часть повторяемого процесса для приобретателя и поставщика. План документации может быть создан для всей организации или для нескольких проектов и сервисов, которые повторно используют содержимое документа.
6.4.2 Управление и контроль информационных элементов
Проекты, организации и сервисы могут включать описания записей и описания адаптированных информационных элементов в словаре данных или структуре разбивки работ. Эта практика помогает в управлении документами, разработке и обслуживании. Необходимо установить фиксированную иерархию информационных элементов и разработать механизм для разрешения конфликтов между положениями. Например, должен быть один генеральный план работ для всего пакета планов, относящихся к одному проекту, а информация о плане, указанная в конкретных планах, должна относиться к этому генеральному плану.
Коммерческие или другие существующие информационные элементы могут быть заменены на все или часть информационного элемента, если они содержат необходимую информацию, соответствуют применимым качественным характеристикам и на них есть надлежащие ссылки. Когда существующие информационные элементы легко доступны пользователям, организациям следует рассмотреть возможность предоставления ссылок на эти информационные элементы, а не на воспроизведение информации.
Использование типовых видов упрощает применение согласованной структуры, содержания и форматов для аналогичных информационных элементов (записей и документов) для поддержки удобства использования. В настоящем стандарте определяются данные жизненного цикла 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.
В списках содержимого типовых видов информационных элементов не указывается нормативная последовательность, структура частей или список названий разделов.
Цель: представить планируемый или фактический контекст использования, функции, дизайна, сервиса или элемента.
Примечание - Описание того, что требуется, является спецификацией. Уровень детализации и презентация для использования человеком или для хранения данных определяют, представлена ли информация как описание или как предварительно отформатированная запись.
Описание должно включать в себя следующие элементы:
a) дату выдачи, статус, объем;
b) сведения об организации, выдавшей документ;
c) ссылки;
d) контекст;
e) обозначение для описания;
f) основную часть;
g) резюме;
h) глоссарий;
i) историю внесения изменений.
Идентифицированные информационные элементы:
- концепция операций (операционная концепция);
- описание дизайна базы данных;
- описание интерфейса;
- предложение;
- каталог услуг;
- описание архитектуры программного продукта;
- описание дизайна программного продукта;
- описание программного продукта;
- описание архитектуры системы; а также
- описание системного элемента.
Цель: определить, когда, как и кем должны выполняться конкретные процессы или действия.
План должен включать в себя следующие элементы:
a) дату выдачи и статус;
b) объем;
c) сведения об организации, выдавшей документ;
d) ссылки (применимые политики, законы, стандарты, контракты, требования и другие планы и процедуры);
e) сведения об органе, выдавшем разрешение;
f) введение, в котором указаны цель, аудитория и сфера применения плана;
g) запланированные мероприятия и задачи;
h) идентификация инструментов, методов и техники;
i) график;
j) бюджеты и сметы расходов;
k) ресурсы и их распределение, включая людские ресурсы, технические ресурсы (инфраструктуру) и инструменты;
l) обязанности и полномочия, включая ответственного владельца и непосредственного владельца процесса или сервиса;
m) интерфейсы между участвующими сторонами;
n) виды деятельности по оценке рисков, оценке и смягчению рисков;
o) меры обеспечения качества и эффективности;
p) информацию об окружающей среде, инфраструктуре, защищенности и безопасности;
q) обучение;
r) подход к техническому и управленческому анализу и отчетности;
s) другие планы (планы или описания задач, которые расширяют детали плана);
t) глоссарий;
u) изменение процедуры и историю;
v) процесс завершения.
Идентифицированные информационные элементы:
- план принятия;
- план приобретения;
- план управления активами;
- план аудита;
- планирование мощностей;
- план и политика управления конфигурацией;
- план развития;
- план утилизации;
- план документации;
- план разработки домена;
- план совершенствования (план улучшения процесса, план улучшения обслуживания);
- план управления информацией;
- план информационной безопасности;
- план установки;
- план интеграции (план внедрения);
- план технического обслуживания;
- план измерений;
- план управления проектами;
- план управления качеством (план обеспечения качества);
- план выпуска версий (план развертывания);
- план повторного использования;
- политика и план управления рисками;
- план обеспечения бесперебойной работы и доступности;
- план управления сервисами;
- план обслуживания (план предоставления новых или измененных услуг);
- план обучения;
- план одобрения;
- план проверки.
Цель: установить намерение и подход на высоком уровне организации для достижения целей и обеспечения эффективного контроля сервиса, процессов или системы управления.
Политика должна включать в себя следующие элементы:
a) дату выдачи, дату вступления в силу и статус;
b) область применения;
c) сведения об организации, выдавшей документ;
d) сведения об организации, выдавшей разрешение, и идентификации лиц, ответственных за соблюдение политики;
e) нормативные ссылки на соответствие или соблюдение (такие как политика, законы и правила, стандарты, контракты, требования, заявления о видении цели или миссии);
f) сведения об органе, включая цели;
g) глоссарий;
h) историю внесений изменений.
Примечание - Политики могут передаваться различными средствами или включаться в планы, процедуры, спецификации или другие документы. Политики реализуются посредством Планов и Процедур. Политики могут быть определены для любого процесса жизненного цикла или сервисного процесса.
Идентифицированные информационные элементы:
- политика бюджетирования и учетная политика (вне области применения настоящего стандарта);
- план и политика управления конфигурацией (политика управления изменениями);
- план совершенствования (и политика постоянного совершенствования);
- политика информационной безопасности;
- политика и процедура жизненного цикла;
- политика и процедура управления качеством;
- план выпуска версий (и политика);
- политика и план управления рисками;
- план управления сервисами (и политика).
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) историю внесения изменений.
Идентифицированные информационные элементы:
- процедура аудита;
- процедура управления мощностями;
- процедура коммуникации;
- процедура подачи жалобы;
- процедура управления конфигурацией (процедура управления активами, процедура управления изменениями, процедура выпуска и развертывания);
- процедура документирования;
- процедура внедрения;
- процедура совершенствования;
- процедура управления инцидентами;
- процедура управления информацией;
- процедура информационной безопасности;
- политика и процедура жизненного цикла;
- процедура технического обслуживания;
- процедура измерения;
- процедура операционного тестирования;
- процедура управления проблемами;
- процедура оценки процесса;
- процедура квалификационного испытания;
- политика и процедура управления качеством;
- процедура тестирования программного продукта;
- порядок управления поставщиками;
- процедура выбора поставщика;
- учебная документация;
- документация пользователя;
- процедура подтверждения;
- процедура проверки.
Цель: описать результаты таких мероприятий, как исследования, оценки и тесты. Отчет сообщает о решениях.
Отчет должен включать следующие элементы:
a) дату выдачи и статус;
b) область применения;
c) сведения об организации, выдавшей документ;
d) сведения об участниках;
e) резюме;
f) введение, включая цель, аудиторию и сферу охвата отчета;
g) контекст (допущения);
h) основную часть (включая методы получения результатов);
i) выводы и рекомендации;
j) ссылки;
k) библиографию;
l) глоссарий;
m) историю внесений изменений.
Идентифицированные информационные элементы:
- отчет о приеме;
- отчет о подтверждении аудита;
- аудиторский отчет;
- отчет о состоянии конфигурации;
- отчет об оценке;
- отчет об инциденте;
- отчет об установке;
- отчет об интеграции и испытаниях;
- отчет о мониторинге и контроле;
- отчет о проблеме;
- отчет об улучшении процесса;
- оценка потребности в продукции;
- отчет о ходе работы;
- отчет о квалификационных испытаниях;
- протокол анализа проекта;
- отчет об обслуживании;
- отчет об испытаниях программного продукта;
- уведомление пользователя;
- отчет об одобрении;
- отчет о проверке.
Цель: записывать информацию, необходимую для запроса ответа.
Запрос должен включать следующие элементы:
a) дату подачи;
b) область применения;
c) предмет;
d) сведения об инициаторе запроса;
e) идентификацию запрашиваемого товара, сервиса или ответа;
f) подробное описание запрашиваемого предмета, сервиса или ответа, включая дату выполнения;
g) обоснования.
Примечание - Идентификация запрашиваемого элемента может быть Спецификацией.
Идентифицированные информационные элементы:
- Запрос на внесение изменений;
- Опрос удовлетворенности клиентов;
- Заявка на подряд (RFP);
- Запрос ресурсов;
- Запрос на операции с риском;
- Запрос на обслуживание (запись).
Цель: предоставить требования к необходимому сервису, продукту или процессу.
Спецификации должны использовать четко определенный синтаксис. Спецификации должны быть внутренне согласованы в терминологии, определениях и ограничениях. Уникальные спецификации должны быть определены один раз для предотвращения несогласованных обновлений. Спецификация должна включать в себя следующие элементы:
a) дату выдачи и статус;
b) область применения;
c) сведения об организации, выдавшей документ;
d) ссылки;
e) сведения об органе, выдавшем разрешение;
f) основную часть;
g) требования к достоверности;
h) условия, ограничения и характеристики;
i) глоссарий;
j) историю внесения изменений.
Идентифицированные информационные элементы:
- контракт;
- соглашение об уровне обслуживания (SLA);
- спецификация требований к программному продукту;
- требования к системным требованиям (или требованиям к обслуживанию);
- Спецификация проверки.
В таблицах 1, 2 и 3, колонка 3, информационные элементы идентифицируются и сопоставляются с процессом, в котором они идентифицируются как выходные данные в ISO/IEC/IEEE 15288 или ISO/IEC/IEEE 12207 или ИСО/МЭК 20000-1 (IEEE 20000-1) и ИСО/МЭК 20000-2 (IEEE 20000-2). Этими рекомендациями могут быть нормативные требования, рекомендуемая продукция, информационные материалы, примеры или заметки. В настоящем стандарте определяются элементы информации, которые не указаны явно в заголовке в базовых стандартах. В этих случаях базовые стандарты указывают информацию, которая должна быть документирована, описана, запланирована, указана, сообщена, записана, запрошена или указана. В таблице B.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 "организационные политики и процедуры" не перечислены, но их следует рассматривать как вход для каждого информационного элемента. В контрактной работе договор/соглашение и требования также должны рассматриваться как входные данные для каждого информационного элемента, независимо от того, указывает ли исходный стандарт, что процесс должен выполняться "как указано в контракте".
В настоящем стандарте не указывается формат или содержание рекомендуемых входных данных или элементов входной информации, за исключением содержимого тех элементов, которые также являются выходными информационными элементами.
Как определено в 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 | |
ПРИОБРЕТЕНИЕ | ||
Предложение, другие контракты | 6.1.1.2 d), 6.1.1.3 c) | Контракт (соглашение) |
Оценка потребностей | 6.1.1.3 a) | Спецификация системных требований |
Концепция операций, спецификация системных требований, спецификация требований к программному продукту, стратегия принятия решений, другие заявки на предложение | 6.1.1.3 a) | Техническое задание (RFP) |
ПОСТАВКА | ||
Заявка на подряд, другие предложения | 6.1.1.3 a), 6.1.1.3 b), 6.1.2.2 b), 6.1.2.3 b) | Предложение |
Предложение, другие контракты и соглашения | 6.1.2.2 c), 6.1.2.2 f), 6.1.2.3 c), 6.1.3.3 f) | Контракт (соглашение) |
Отчет о проблемах | 6.1.2.3 b) | Запрос на внесение изменений |
План управления проектом | 6.1.2.3 d) | Отчет об улучшениях |
Организационная процедура, другие планы управления проектом, этапы проекта, контракт | 6.1.2.3 c), 6.1.2.3 d) | План управления проектом |
УПРАВЛЕНИЕ МОДЕЛЬЮ ЖИЗНЕННОГО ЦИКЛА | ||
Организационная процедура | 6.2.1.2 a), 6.2.1.3 a) | Политика и процедуры жизненного цикла |
Отчет об оценке, организационная процедура | 6.2.1.3 c) | План по улучшению |
Организационная процедура, процедура оценки процесса, результаты оценки процесса, отчет аудита, отчет об удовлетворенности клиентов, отчет об оценке, отчет о ходе работы, отчет о проблеме | 6.2.1.3 c) | Отчет об улучшении процесса |
УПРАВЛЕНИЕ ИНФРАСТРУКТУРОЙ | ||
Организационная процедура, другие требования к системным требованиям, план управления проектами | 6.2.2.2 | Спецификация системных требований |
УПРАВЛЕНИЕ ПОРТФЕЛЕМ | ||
Организационная процедура, план проекта, план действий | 6.2.3.3 a) | План управления проектами |
Соглашение, политика и процедуры жизненного цикла проекта | 6.2.3.3 a) | Отчет о ходе работы (отчет об инициации прогресса) |
УПРАВЛЕНИЕ ЧЕЛОВЕЧЕСКИМИ РЕСУРСАМИ | ||
Запись опыта работы сотрудника, план управления проектами | 6.2.4.3 b) | План обучения |
Политика управления знаниями, план обучения, документация пользователя, процедура проверки | 6.2.4.3 b) | Учебная документация |
УПРАВЛЕНИЕ КАЧЕСТВОМ | ||
План управления проектами | 6.2.5.3 | План управления качеством |
Организационная процедура, план управления качеством, отчет об уровне удовлетворенности клиентов, отчет о проблеме | 6.2.5.2 a), 6.2.5.3 a) | Политика и процедура управление качеством |
Опрос, интервью, спецификация требований, результаты оценки качества, результаты оценки уровня удовлетворенности клиентов | 6.2.5.3 b) | Отчет по мониторингу и контролю |
ПЛАНИРОВАНИЕ ПРОЕКТА | ||
Контракт, организационная процедура, другие планы, цели и ограничения проекта | 6.3.1.1, 6.3.1.2, 6.3.1.3 | Проект (технический) план управления |
Оценка потребности в продукции, контракт | 6.3.1.3 b) | План принятия |
Оценка потребности в продукции | 6.3.1.3 b) | План приобретения |
Политика и процедура управления качеством организации | 6.3.1.3 c) | План управления качеством |
План управления проектом, структура разбивки работ, бюджет | 6.3.1.3 d) | Запрос ресурсов |
ОЦЕНКА И КОНТРОЛЬ ПРОЕКТА | ||
Контракт, организационная процедура, другие планы | 6.3.2.2 | Отчет о проблеме |
Контракт, организационная процедура, план проекта, план обеспечения качества, другой отчет о ходе работы | 6.3.2.2 d), 6.3.2.3 a) | Отчет о ходе работы |
Отчет о проблемах, анализ показателей и вариаций | 6.3.2.3 b) | Отчет по мониторингу и контролю (отчет об оценке проекта) |
План управления проектом, рабочая структура, бюджет, отчет о ходе выполнения работ | 6.3.2.3 b) | Запрос поиска |
УПРАВЛЕНИЕ ПРОЦЕССОМ ПРИНЯТИЯ РЕШЕНИЙ | ||
Организационная процедура, контракт | 6.3.3.3 a) 2), 6.3.3.3 c) 1) | Отчет о проблеме |
Организационная процедура, контракт | 6.3.3.2 d) | Отчет (см. Типовой информационный элемент отчета) |
УПРАВЛЕНИЕ РИСКАМИ | ||
План управления проектами | 6.3.4.3 a) | Политика и план управления рисками |
План управления рисками, профиль рисков | 6.3.4.3 d) | Запрос на действия с риском |
План управления рисками, профиль рисков, процедура обеспечения качества, отчет о проблеме | 6.3.4.3 b) | Отчет о мониторинге и контроле (отчет профиля риска) |
КОНФИГУРАЦИОННОЕ УПРАВЛЕНИЕ | ||
План управления проектом, план управления информацией | 6.3.5.3 a) | План управления конфигурацией |
УПРАВЛЕНИЕ ИНФОРМАЦИЕЙ | ||
Организационная процедура, план управления проектами, план управления конфигурацией | 6.3.6.3 a) | План управления информацией |
ИЗМЕРЕНИЕ | ||
Организационная процедура | 6.3.7.3 a) | План измерений |
Данные измерений, план управления информацией | 6.3.7.1, 6.3.7.3 b) | Отчет по мониторингу и контролю |
Данные измерений, отчет о ходе работ | 6.3.7.3 c) | Аналитический отчет процесса улучшений |
ПОТРЕБНОСТИ ЗАИНТЕРЕСОВАННЫХ ЛИЦ И ОПРЕДЕЛЕНИЕ ТРЕБОВАНИЙ | ||
Контракт, оценка потребностей | 6.4.1.2 a), D.4.a | Концепция операций (операционная концепция) |
Контракт, оценка потребностей, концепция операций | 6.4.1.3 c) | Спецификация требований к системе (заинтересованным сторонам) |
ОПРЕДЕЛЕНИЕ ТРЕБОВАНИЙ СИСТЕМЫ | ||
Организационная процедура, требования заинтересованных сторон | 6.4.2.2, 6.4.2.3 | Спецификация системных требований |
ОПРЕДЕЛЕНИЕ АРХИТЕКТУРЫ | ||
План разработки, спецификация системных требований | 6.4.3.1, 6.4.3.2 a), 6.4.3.3 c) | Описание архитектуры системы |
Описание архитектуры системы | 6.4.3.2 b) | Описание элементов системы |
Описание архитектуры системы, описание дизайна системы | 6.4.4.3 a), 6.4.4.3 b) | Описание интерфейса |
РЕАЛИЗАЦИЯ | ||
Соглашение, организационная процедура, описание системы, процедура интеграции, описание интерфейса управления | 6.4.4.3 | План интеграции |
План реализации | 6.4.4.3 a), 6.4.4.3 b) | Процедура реализации |
ИНТЕГРАЦИЯ | ||
Соглашение, спецификация запросов системы, описание интерфейса, план тестирования | 6.4.5.3 a) | План интеграции |
Запись о конфигурации | 6.4.5.3 b) | Отчет о проблемах |
ПРОВЕРКА | ||
Спецификация системных требований, описание системы, описание интерфейса | 6.4.6.3 a) | План проверки |
Организационная процедура, технические требования, план проверки, определение конструкции, описание управления интерфейса, процедуры по испытаниям, отчет о ходе работы, отчет о проблеме, тестовый случай | 6.4.6.3 b) | Отчет о проверке |
Процедуры испытаний, отчет об испытаниях | 6.4.6.2 c), 6.4.6.3 b) | Отчет о проблемах |
ПЕРЕДАЧА | ||
Соглашение, описание системы, спецификация системных требований, описание интерфейса | 6.4.10.3 a) | План установки |
План установки, отчет о проблемах, отчет о ходе работы | 6.4.7.3 b) | Отчет об установке (отчет о передаче) |
Процедура управления качеством | 6.4.7.2 e), 6.4.7.3 b) | Отчет о проблемах |
ОДОБРЕНИЕ | ||
Требования заинтересованных сторон, стратегия одобрения, процедуры испытаний | 6.4.8.3 a) | План одобрения |
План управления качеством, процедуры одобрения | 6.4.8.3 b) | Отчет об одобрении |
Процедуры тестирования | 6.4.8.2 d), 6.4.8.3 b) | Отчет о проблемах |
ОПЕРАЦИЯ | ||
Отчет о проблемах, отчет об оценке | 6.4.9.3 b) | Документация пользователя |
Документация пользователя, отчет об инцидентах, соглашение об уровне обслуживания | 6.4.9.2 c) | Отчет об (операционных) проблемах |
ТЕХНИЧЕСКОЕ ОБСЛУЖИВАНИЕ | ||
Организационная процедура, операционный план, план развития | 6.4.10.3 a) | План технического обслуживания |
План технического обслуживания, документация пользователя | 6.4.10.3 a), 6.4.10.3 b) | Процедура технического обслуживания |
Процедуры технического обслуживания | 6.4.10.2 e), 6.4.10.3 b) | Отчет о проблемах |
УТИЛИЗАЦИЯ | ||
План управления проектом, спецификация системных требований, описание интерфейса, порядок установки, порядок операций | 6.4.11.3 a) | План утилизации |
АДАПТАЦИЯ | ||
Стандартная модель жизненного цикла, стандартные организационные политики и процедуры, решения по адаптации, решение об адаптации, соглашение, требование заинтересованных сторон | A.2.3 a), B.2.3 | Процедура жизненного цикла |
Таблица 2 отображает информационные элементы в жизненном цикле программного обеспечения, как определено в ISO/IEC/IEEE 12207. ISO/IEC/IEEE 12207 имеет такие же процессы, как и жизненный цикл системы: два процесса заключения соглашения, пять организационных процессов, связанных с проектом, и семь процессов проекта. Существуют также отличительные процессы для жизненного цикла программного продукта: одиннадцать технических процессов, семь процессов внедрения программного продукта, восемь процессов технического обслуживания программного продукта и три процесса повторного использования программного продукта.
Таблица 2
элементами для каждого жизненного цикла
программного продукта
Стандартные элементы входной информации | ISO/IEC/IEEE 12207 | |
ПРИОБРЕТЕНИЕ | ||
Отчет о приобретении, оценка потребности в продукции, предусмотренной по контракту, отчет о приобретении, другие планы приобретения | 6.1.1.3.1.8, 6.1.1.3.1.9, 6.1.1.3.1.12 | План приобретения |
Предложение, другие контракты | 6.1.1.2, 6.1.1.3.4.2, B.3.1.2.2, B.3.1.3.2, F.3.3.1.1, F.3.3.1.2, F.3.3.5.1 | Контракт |
Другие оценки потребности в продукции | 6.1.1.2, 6.1.1.3.1.1 | Оценка потребности в продукции |
Другие описания систем, концепция операций | 6.1.1.3.1.1 | Концепция операций |
Заявка на подряд, оценка потребности в продукции, отчет о приобретении, предыдущие заявки на предложения (RFP); концепция; системные требования; определение и анализ требований к программному обеспечению; прошлое: справка об области применения, инструкции участника, условия и положения; стратегия принятия и условия, рекомендация по приобретению | 6.1.1.3.1.10 | Заявка на подряд (RFP) |
Спецификация требований к системе, оценка потребности в продукции | 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.1.1.3.1.7 | План обслуживания |
План приобретения, план принятия, спецификация требований, контракт | 6.1.1.3.6.1, 6.1.1.3.6.2 | Процедура квалификационного тестирования |
Другие процедуры отбора поставщиков, план приобретения, другие заявки на предложения | 6.1.1.3.3.1 | Процедура выбора поставщика |
Контракт, отчет о проблеме, отчет по мониторингу и контролю | F.372, F.3.3.2.1 | Запрос изменений |
ПОСТАВКА | ||
Спецификация требований, заявка на подряд | 6.1.2.2, 6.1.2.3.3.1, 6.1.2.3.6.2, B.3.2.2.1, B.3.2.2.2 | Контракт |
Контракт, план управления проектами поставщика, план обеспечения качества | 6.1.2.3.4.8, 6.1.2.3.4.15 | Отчет об оценке |
План управления проектами | 6.1.2.3.4.15 | Протокол анализа проекта |
Результат мониторинга | 6.1.2.3.4.8, 6.1.2.3.4.15 | Отчет по мониторингу и контролю |
Отчет о пересмотре предложений, предложение, контракт, другие планы управления проектами, политика информационной безопасности | 6.1.2.3.4.3, 6.1.2.3.4.5 | План управления проектами |
Запрос клиента или запрос, запрос на предложение, другие предложения | 6.1.2.2 b), B.3.2.1.2 | Предложение |
Процедура управления проблемами | 6.1.2.3.4.15, B.3.2.3.2 | Отчет о проблеме |
План управления проектами | 6.1.2.3.4.15 | Отчет о ходе работы |
План аудита, контракт | 6.1.2.3.4.15 | Аудиторский отчет |
УПРАВЛЕНИЕ МОДЕЛЬЮ ЖИЗНЕННОГО ЦИКЛА | ||
Организационные процедуры | 6.2.1.1, 6.2.1.2, 6.2.1.3.1.1, 6.2.1.3.3.1 | Политика и процедура жизненного цикла |
Отчет об оценке, организационная процедура | 6.2.1.3 | План по улучшению |
Процедура жизненного цикла, описание процесса, протокол проверки, отчет об анализе процесса, отчет аудита, план улучшения, план управления проектами | 6.2.1.3.2.2 | План аудита |
Политики жизненного цикла, описание процесса | 6.2.1.3.2.1 | Процедура оценки процесса |
Отчет об оценке, отчет о ходе работы, отчет о проблеме, отчет об аудиторской проверке, отчет об уровне удовлетворенности клиентов | 6.2.1.3.3.2, B.3.3.1.2, B.3.3.2.2, B.3.3.3.2 | Отчет об анализе улучшения процесса |
УПРАВЛЕНИЕ ИНФРАСТРУКТУРОЙ | ||
Организационная процедура, стратегический план, спецификация системных требований | 6.2.2.2, 6.2.2.3.1.1, 6.2.2.3.2.1 | Спецификация системных требований |
Структура разбивки работ, спецификация требований к инфраструктуре | 6.2.2.3.1.2 | План управления проектами |
УПРАВЛЕНИЕ ПОРТФЕЛЕМ ПРОЕКТА | ||
Организационные процедуры, план проекта, план действий бизнеса, процедура жизненного цикла | 6.2.3.3.2.1, 6.2.3.3.1.6 | План управления проектами |
УПРАВЛЕНИЕ ЧЕЛОВЕЧЕСКИМИ РЕСУРСАМИ | ||
Отчеты о навыках работника, планы управления проектами | 6.2.4.3.2.1, 6.2.4.3.4.1 | План обучения |
Схема области знаний, отчеты об оценке | 6.2.4.3.4.1 | План управления информацией |
План обучения, документация пользователя, процедуры проверки | 6.2.4.3, B.3.4.1.2 | Учебная документация |
УПРАВЛЕНИЕ КАЧЕСТВОМ | ||
План управления проектами | 6.2.5.3.1.5 | План управления качеством |
Организационные процедуры, план управления качеством, отчет об удовлетворенности клиентов, отчет о проблеме | 6.2.5.2, 6.2.5.3.1.1 | Политика и процедура управления качеством |
Опросы, интервью, спецификация требований | 6.2.5.3.1.4 | Отчет об обслуживании |
ПЛАНИРОВАНИЕ ПРОЕКТА | ||
Предложение, контракт, другие планы, запросы бюджета, организационные процедуры, модификация контракта, другие планы | 6.3.1.1, 6.3.1.2 e), 6.3.1.3.2.1 | План управления проектами |
План управления проектом, контракт | 6.3.1.3.3.2 | Запрос ресурсов |
ОЦЕНКА И КОНТРОЛЬ ПРОЕКТА | ||
Контракт, организационные процедуры, план проекта, план обеспечения качества | 6.3.2.3.2.1 | Отчет о проблеме |
Контракт, организационные процедуры, план проекта, план обеспечения качества, другой отчет о ходе работы | 6.3.2.2, 6.3.2.3.1.1, 6.3.2.3.2.2 | Отчет о ходе работы |
Отчеты о проблемах, анализ показателей и вариаций | 6.3.2.3.2, 6.3.2.3.3 | Отчет по мониторингу и контролю |
УПРАВЛЕНИЕ ПРИНЯТИЕМ РЕШЕНИЯ | ||
Организационные процедуры, контракт | 6.3.3.3.1.3, 6.3.3.3.3.1 | Отчет о проблеме |
Организационные процедуры, контракт | 6.3.3.2 d) | Отчет |
УПРАВЛЕНИЕ РИСКАМИ | ||
Политика управления рисками, организационные процедуры | 6.3.4.3.1.1, 6.3.4.3.1.1, 6.3.4.3.2.1 | План управления рисками |
План управления рисками | 6.3.4.3.1.5 | План по улучшению |
Процедуры обеспечения качества, отчеты о проблемах | 6.3.4.3.3.4, 6.3.4.3.6.3 | Отчет по мониторингу и контролю |
Отчет об изменении, мониторинг и контроль, регистр рисков, профиль рисков | 6.3.4.3.4.1 | Запрос на риск |
УПРАВЛЕНИЕ КОНФИГУРАЦИЕЙ | ||
План управления проектом, требования к системным требованиям | 6.3.5.3.1.1 | План управления конфигурацией и политика |
УПРАВЛЕНИЕ ИНФОРМАЦИЕЙ | ||
Организационные процедуры, план управления проектами | 6.3.6.3.1, 6.3.6.3.2.5 | План управления информацией |
План управления информацией | 6.3.6.3.1 | План документации |
ИЗМЕРЕНИЕ | ||
Организационная политика, план управления проектами, договор, план управления информацией | 6.3.7.2 c), 6.3.7.3.1.1, 6.3.7.3.1.3, 6.3.7.3.1.4 | План измерений |
План измерений, процедуры измерения | 6.3.7.1, 6.3.7.3.2.4 | Отчет по мониторингу и контролю |
ОПРЕДЕЛЕНИЕ ТРЕБОВАНИЙ ЗАИНТЕРЕСОВАННЫХ СТОРОН | ||
Контракт, оценка потребностей, концепция операций | 6.4.1.3.2 | Спецификация системных требований |
Контракт, оценка потребностей | 6.4.1.2, 6.4.1.3.2.3 | Концепция операций |
АНАЛИЗ СИСТЕМНЫХ ТРЕБОВАНИЙ | ||
Организационные процедуры, контракты, требования к качеству | 6.4.2.2, 6.4.2.3.1.1 | Спецификация системных требований |
Спецификация системных требований, оценка потребностей | 6.4.2.3.2.1 | Отчет об оценке |
ДИЗАЙН АРХИТЕКТУРЫ СИСТЕМЫ | ||
План развития, спецификация системных требований | 6.4.3.2, 6.4.3.3.1.1 | Описание архитектуры программного обеспечения |
Описание архитектуры системы, описание системы | 6.4.3.2 d) | Описание интерфейса |
Спецификация системных требований, описание архитектуры системы, концепции операций | 6.4.3.3.2.1 | Отчет об оценке |
РЕАЛИЗАЦИЯ | ||
[Заменено Процессом внедрения программного обеспечения] | ||
СИСТЕМНАЯ ИНТЕГРАЦИЯ | ||
Спецификация системных требований, описание архитектуры системы, документация пользователя программного обеспечения, план тестирования интеграции программного обеспечения | 6.4.5.3.1.1 | Отчет об интеграции и испытаниях |
Спецификация системных требований, отчет об интеграции и испытаниях | 6.4.5.3.2.2 | Отчет об оценке |
ИСПЫТАНИЕ КВАЛИФИКАЦИИ СИСТЕМЫ | ||
Спецификация системных требований, план одобрения | 6.4.5.3.2.1 | Квалификационный тест |
Требования, определение дизайна, описание интерфейса | 6.4.6.3.1.2 | Отчет об оценке |
План проверки, процедуры тестирования, тестовый пример | 6.4.6.3.1.3 | Аудиторский отчет |
УСТАНОВКА ПРОГРАММНОГО ПРОДУКТА | ||
Контракт, план разработки, спецификация системных требований, описание архитектуры системы, другие планы установки | 6.4.7.3.1.1 | План установки |
Контракт, план установки | 6.4.7.3.1.2 | Отчет об установке |
ПОДДЕРЖКА ПРИНЯТИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ | ||
Контракт, план принятия, процедура принятия | 6.4.8.3.1.1 | Отчет об одобрении и тестировании |
Процедуры тестирования | 6.4.8.2, 6.4.8.3.1.1 | Отчет о проблеме |
РАБОТА ПРОГРАММНОГО ПРОДУКТА | ||
Спецификация системных требований | 6.4.9.3.1.1 | План управления сервисами |
Спецификация требований к программному продукту, подробное описание дизайна системы, концепция работы | 6.4.9.3.3.1, 6.4.9.3.4.1 | Документация пользователя |
Документация пользователя программного продукта, отчеты о проблемах; запросы на внесение изменений, другие процедуры операционных испытаний | 6.4.9.3.1.3 | Процедура оперативного тестирования |
Отчеты о проблемах, другие операционные процедуры | 6.4.9.3.1.2, 6.4.9.3.1.3 | Процедура управления проблемами |
Отчеты о проблемах, процедура управления проблемами | 6.4.9.3.4.2, 6.4.9.3.5.2 | Отчет о проблеме |
План операций, документация пользователя, отчет о проблеме, анализ удовлетворенности клиентов | 6.4.9.3.4.2 | Запрос на внесение изменений |
ТЕХНИЧЕСКОЕ ОБСЛУЖИВАНИЕ ПРОГРАММНОГО ПРОДУКТА | ||
Организационные процедуры, план операций, план развития, контракт, документация пользователя программного продукта | 6.4.10.1, 6.4.10.3.1.1 | План обслуживания |
План обслуживания, документация пользователя, процедуры установки, процедуры тестирования | 6.4.10.3.1.1 | Процедура технического обслуживания |
Спецификация требований к программному обеспечению, отчет об изменениях, низкоуровневый документ разработки программного продукта | 6.4.10.2, 6.4.10.3.3.1 | Описание программного обеспечения |
Запись версии, запрос на внесение изменений, подробный проектный документ | 6.4.10.2 | Документация пользователя |
Отчет о проблеме, описание дизайна программного продукта низкого уровня, план проверки | 6.4.10.3.3.2 | Процедура тестирования программного модуля |
Процедуры технического обслуживания | 6.4.10.3.1.2, 6.4.10.3.2.4 | Отчет о проблеме |
План тестирования программного обеспечения, отчет о проблеме. Запрос на внесение изменений | 6.4.10.3.3.2 | Отчет об испытаниях программного продукта |
План технического обслуживания, спецификация критериев тестирования и оценки, отчет о требованиях к модификации, отчет об уведомлении об изменениях, отчет об испытаниях модификации, план миграции | 6.4.10.3.5.6 | Протокол анализа проекта |
Контракт, план обслуживания, план установки, план проверки, план управления конфигурацией | 6.4.10.3.5.2 | План выпуска версий |
План выпуска версий | 6.4.10.3.5.3, 6.4.10.3.5.5 | Уведомление пользователя |
УТИЛИЗАЦИЯ ПРОГРАММНОГО ПРОДУКТА | ||
Ограничения срока службы, контракт | 6.4.11.2 | Спецификация требований к программному продукту |
План утилизации | 6.4.11.3.2.2 | Уведомление пользователя |
Организационные процедуры, контракт, план управления проектами | 6.4.11.3.1.1 | План утилизации |
РЕАЛИЗАЦИЯ ПРОГРАММНОГО ПРОДУКТА | ||
Модель жизненного цикла, спецификация требований к программному продукту, описание архитектуры программного продукта | 7.1.1.3.1.2 | Описание программного обеспечения |
Описание дизайна программного продукта, спецификации программного продукта | 7.1.1.3.1.2 | Документация пользователя |
Инциденты, проблемы | 7.1.1.3.1.2 | Отчет о проблеме |
Контракт, план управления проектами поставщика, спецификация требований к программному обеспечению, план обеспечения качества | 7.1.1.3.1.3, 7.1.1.3.1.4 | План развития |
АНАЛИЗ ТРЕБОВАНИЙ К ПРОГРАММНОМУ ПРОДУКТУ | ||
Контракт, спецификация системных требований, план развития, описание архитектуры системы, требования заинтересованных сторон, оценка потребностей продуктов, оценка рисков, оценки прототипов | 7.1.2.2, 7.1.2.3.1.1 | Спецификация требований к программному продукту |
Спецификация требований к программному продукту, концепция операций | 7.1.2.3.1.2 | Отчет об оценке |
ДИЗАЙН АРХИТЕКТУРЫ ПРОГРАММНОГО ПРОДУКТА | ||
Контракт, план развития, спецификация системных требований, спецификация требований к программному продукту | 7.1.3.3.1.1 | Описание архитектуры программного продукта |
Описание архитектуры системы, концепция операций, спецификация системных требований, спецификация требований к программному продукту | 7.1.3.3.1.2 | Описание интерфейса |
Спецификация требований к программному продукту, описание дизайна программного продукта высокого уровня | 7.1.3.3.1.3 | Описание дизайна базы данных |
Описание архитектуры системы, концепция операций, описание интерфейса | 7.1.3.3.1.4 | Документация пользователя |
План разработки, описание системы | 7.1.3.3.1.5 | Спецификация требований к программному продукту |
Требования к тестированию, план управления проектами (генеральный календарный план) | 7.1.3.3.1.5 | План развития |
Описание архитектуры системы, спецификация требований к программному продукту, концепция операций, описание интерфейса, описание дизайна базы данных | 7.1.3.3.1.6 | Отчет об оценке |
ПОДРОБНЫЙ ДИЗАЙН ПРОГРАММНОГО ПРОДУКТА | ||
План разработки, спецификация требований к программному продукту, описание архитектуры системы | 7.1.4.3.1.1 | Описание программного продукта |
Подробный дизайн программного продукта, описание архитектуры системы, спецификация требований к программному продукту | 7.1.4.3.1.2 | Описание интерфейса |
Спецификация требований к программному продукту, описание архитектуры системы | 7.1.4.3.1.3 | Описание дизайна базы данных |
План документации, спецификация требований к программному продукту, описание дизайна программного обеспечения высокого уровня, прочая документация пользователя программного продукта, описание базы данных | 7.1.4.3.1.4 | Документация пользователя |
План разработки, план принятия, спецификация требований к программному продукту, описание дизайна программного продукта низкого уровня, подробное описание дизайна базы данных | 7.1.4.3.1.5 | Процедура тестирования программного модуля |
Описание архитектуры системы, подробный дизайн программного продукта, спецификация требований к программному продукту, план тестирования программного продукта | 7.1.4.3.1.7 | Отчет об оценке |
КОНСТРУИРОВАНИЕ ПРОГРАММНОГО ПРОДУКТА | ||
Программные элементы, базы данных, план тестирования программного продукта | 7.1.5.3.1.1 | Процедура тестирования программного модуля |
Описание программного продукта | 7.1.5.3.1.1 | Описание программного продукта |
Описание программного продукта, процедуры тестирования программного продукта | 7.1.5.3.1.2 | Отчет об испытаниях программного продукта |
План документации, спецификация требований к программному продукту, описание дизайна программного продукта, прочая документация пользователя программного продукта, описание базы данных, процедуры тестирования программного продукта, отчет об испытаниях программного продукта | 7.1.5.3.1.3 | Документация пользователя |
План тестирования программного продукта, отчет об испытаниях программного продукта, спецификация требований к программному продукту, концепция операций, интеграция и отчет об испытаниях | 7.1.5.3.1.5 | Отчет об оценке |
ИНТЕГРАЦИЯ ПРОГРАММНОГО ПРОДУКТА | ||
Спецификация требований к программному продукту, описание дизайна программного продукта, описание архитектуры программного продукта, спецификации интерфейса | 7.1.6.3.1.1, 7.1.6.3.1.5 | Интеграционный план |
План интеграции, план тестирования, процедуры тестирования, записи результатов теста | 7.1.6.3.1.2 | Отчет об интеграции и испытаниях |
План документации, интеграция и отчет об испытаниях, описание программного продукта | 7.1.6.3.1.3 | Документация пользователя |
План принятия, документация пользователя программного продукта, план развития, спецификация системных требований, план интеграции, описание программного продукта, описание дизайна базы данных, спецификация требований к программному продукту, описание архитектуры системы | 7.1.6.3.1.4 | Процедура квалификационного теста |
План интеграции, спецификация требований к программному продукту, концепция операций, интеграция и отчет об испытаниях | 7.1.6.3.1.5 | Отчет об оценке |
ИСПЫТАНИЕ КВАЛИФИКАЦИИ ПРОГРАММНОГО ПРОДУКТА | ||
Спецификация требований к программному продукту, интеграция и отчет об испытаниях, процедуры квалификационных испытаний | 7.1.7.3.1.1, 7.1.7.3.1.3 | Отчет по квалификационным испытаниям |
План документации, интеграция и отчет об испытаниях, описание программного продукта | 7.1.7.3.1.2 | Документация пользователя |
Концепция операций, пользовательская документация, процедуры квалификационных испытаний, отчет о квалификационных тестах | 7.1.7.3.1.3 | Отчет об оценке |
План принятия, документация пользователя программного продукта, план разработки, спецификация требований к программному продукту, описание дизайна программного продукта, описание проекта базы данных, отчет о проведении испытаний | 7.1.7.3.1.4 | Аудиторский отчет |
УПРАВЛЕНИЕ ДОКУМЕНТАЦИЕЙ ПРОГРАММНОГО ПРОДУКТА | ||
План управления программой, план развития, аудиторские отчеты, отчеты об оценке, контракт, другие планы документации | 7.2.1.2, 7.2.1.3.1.1 | План документации |
УПРАВЛЕНИЕ КОНФИГУРАЦИЕЙ ПРОГРАММНОГО ПРОДУКТА | ||
Контракт, прочие планы управления конфигурацией | 7.2.2.3.1.1 | План управления конфигурацией |
Записи конфигурации, прочие отчеты о статусе конфигурации | 7.2.2.2 e, 7.2.2.3.4.1, 7.2.2.3.5.1 | Отчет о статусе конфигурации |
ОБЕСПЕЧЕНИЕ КАЧЕСТВА ПРОГРАММНОГО ПРОДУКТА | ||
Контракт, план управления проектами, спецификация системных требований | 7.2.3.3.1.3 | План управления качеством |
ПРОВЕРКА ПРОГРАММНОГО ПРОДУКТА | ||
Контракт, спецификация требований к программному продукту | 7.2.4.3.1.5, 7.2.4.3.1.6 | План проверки |
План проверки, спецификации испытаний, протоколы испытаний | 7.2.4.3.1.5 | Отчет о проверке |
ОДОБРЕНИЕ ПРОГРАММНОГО ПРОДУКТА | ||
Контракт, другие планы одобрения, спецификация требований к программному продукту | 7.2.5.3.1.4 | План одобрения |
Контракт, отчет о квалификационных испытаниях, требования к системным требованиям, спецификация требований к программному продукту | 7.2.5.3.2.1, 7.2.5.3.2.2 | Спецификация проверки одобрения |
Спецификация проверки одобрения | 7.2.5.3.1.4 d) | Отчет об одобрении |
АНАЛИЗ ПРОГРАММНОГО ПРОДУКТА | ||
Контракт, повестка для анализа, отчеты о проблемах, планы, графики, стандарты | 7.2.6.2, 7.2.6.3.1.5 | Протокол анализа проекта |
АУДИТ ПРОГРАММНОГО ПРОДУКТА | ||
Организационные политики и процедуры | 7.2.7.3.1.4 | Процедура аудита |
Аудиторский отчет | 7.2.7.3.1.6 | Отчет о подтверждении аудита |
Контракт, спецификация требований к программному продукту, планы тестирования, спецификация проверки одобрения, отчеты об испытаниях, документация пользователя, планы, результаты мониторинга, стандарты | 7.2.7.3.1.6 | Аудиторский отчет |
РЕШЕНИЕ ПРОБЛЕМ ПРОГРАММНОГО ПРОДУКТА | ||
Процедура управления проблемами, протоколы проверки, отчеты об инцидентах | 7.2.8.2, 7.2.8.3.1.1, 7.2.8.3.2.1 | Отчет о проблеме |
ДОМЕННАЯ ТЕХНИКА | ||
Отчет о состоянии конфигурации, отчет об оценке, описание архитектуры домена | 7.3.1.3.1.3 | Запрос на внесение изменений |
План управления проектами, организационные процедуры, бизнес-стратегия, план развития | 7.3.1.3.1.1 | Инженерный план домена |
Технический план домена, отчет об испытаниях. Запрос на внесение изменений | 7.3.1.3.1.3 | Отчет о проблеме |
Модель домена, описание интерфейса | 7.3.1.2, 7.3.1.3.3.1, 7.3.1.3.3.3 | Описание архитектуры программного обеспечения |
ПОВТОРНОЕ ИСПОЛЬЗОВАНИЕ УПРАВЛЕНИЯ АКТИВАМИ | ||
Стратегический план, план управления проектами, план обслуживания, инженерный план домена | 7.3.2.2, 7.3.2.3.1.1, 7.3.2.3.2.2 | План управления активами |
Отчет о статусе конфигурации | 7.3.2.3.3.6 | Запрос на внесение изменений |
Запрос на внесение изменений, отчет о проблеме | 7.3.2.3.3.6 | План обслуживания |
Отчет о проблеме | 7.3.2.3.3.8 | Уведомление пользователя |
Данные повторного использования активов | 7.3.2.3.3.5, 7.3.2.3.3.7 | Отчет по мониторингу и контролю |
Отчет об испытаниях, отчет аудита | 7.3.2.3.3.6 | Отчет о проблеме |
УПРАВЛЕНИЕ ПОВТОРНЫМ ИСПОЛЬЗОВАНИЕМ ПРОГРАММЫ | ||
План управления проектом, организационные процедуры, бизнес-стратегия, план развития, инженерный план домена | 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.3 | Отчет о проблеме |
АДАПТАЦИЯ | ||
Стандарты, организационные политики и процедуры | A.2.3.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) Внедрение программного продукта.
2) Анализ требований к программному продукту.
3) Программный архитектурный дизайн.
4) Детальный дизайн программного продукта.
5) Программные продукты.
6) Интеграция программного продукта.
7) Квалификационное тестирование программного продукта.
Процессы поддержки программного продукта
1) Управление документацией по программному продукту.
2) Управление конфигурацией программного продукта.
3) Обеспечение качества программного продукта.
4) Проверка программного продукта.
ИС NORMPROD: примечание. Текст дан в соответствии с официальным текстом документа. |
5) Проверка программного продукта.
6) Анализ программного продукта.
7) Аудит программного продукта.
8) Разрешение проблем программного продукта.
Процессы повторного использования программного продукта
1) Разработка домена.
2) Повторное использование управления активами.
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 принимает форму руководства и рекомендаций. Его нельзя указывать, как если бы это была спецификация, и особое внимание следует уделять обеспечению того, чтобы одобрения о соответствии не вводили в заблуждение.
Таблица 3
и ИСО/МЭК 20000-2 (IEEE 20000-2) с информационными
элементами для каждого процесса управления сервисами
Стандартные элементы входной информации | ИСО/МЭК 20000-1 (IEEE 20000-1) или ИСО/МЭК 20000-2 (IEEE 20000-2) | |
ПРИМЕНИМО В СИСТЕМЕ УПРАВЛЕНИЯ СЕРВИСАМИ ДЛЯ ВСЕХ ПРОЦЕССОВ | ||
УПРАВЛЕНИЕ СЕРВИСАМИ | ||
Политика управления сервисами, контракт, цели, область применения, требования клиентов, отчеты об эффективности | 1: 1.1, 4.1.1, 4.1.2, 4.3.1, 4.5.1, 4.5.2 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.2.4, 4.3.1.1, 4.5.2.1, 4.5.2.2, 4.5.2.4, 4.5.4.1 | План управления сервисами (включая политику управления сервисами) |
План управления сервисами, включая политику | 1: 4.1.3 2: 4.1.1.3, 4.1.3.2 | Процедура коммуникации |
План управления сервисами, SLA | 1: 4.3.1 2: 4.3.1.1 | Каталог услуг |
Контракт (или соглашение), план управления сервисами, каталог услуг | 1: 4.3.1 2: 4.1.1.3, 4.3.1.1 | Соглашение об уровне обслуживания (SLA) |
План документации, план управления информацией | 1: 4.3.1, 4.3.2 2: 4.1.3.1, 4.3.1.2, 4.3.2 | Процедура документирования |
План управления конфигурацией, план управления информацией | 1: 4.3.3 2: 4.3.3, 4.4.2.2 | Процедура управления информацией (процедура управления записями) |
Описание услуги, описание процесса | 1: 4.5.2 2: 4.2.4, 4.5.2.4 | Описание интерфейса |
План управления сервисами, соглашение об уровне обслуживания, отчет аудита | 1: 4.1.4 e), 4.5.3 f), 4.5.5.2 2: 4.1.4.4, 4.5.4.2 | Отчет об обслуживании |
Стандартные элементы входной информации | ИСО/МЭК 20000-1 (IEEE 20000-1) или ИСО/МЭК 20000-2 (IEEE 20000-2) | Элемент выходной информации |
SLA, план управления сервисами | 1: 4.5.4.1, 4.5.4.2 2: 4.5.4.2 | План аудита |
Контракт, SLA, план управления сервисами, опрос удовлетворенности клиентов, информация о ресурсах, регистр рисков, результаты аудита, изменения, улучшения, связанные с решениями и действиями | 1: 4.5.4.1, 4.5.4.3 2: 4.1.1.2, 4.1.2.1 f) | Протокол анализа проекта |
План аудита | 1: 4.5.4.2 2: 4.5.4.2 | Процедура аудита |
Процедура аудита | 1: 4.5.4.2 2: 4.5.4.2 | Аудиторский отчет |
План управления сервисами, SLA, политика улучшения, план измерений, отчеты мониторинга и контроля, протоколы проверки, результаты аудита | 1: 4.5.5.1 2: 4.5.5.2 | Процедура улучшения |
Организационные политики, планы обслуживания. Политика улучшения, план управления сервисами, отчеты о проблемах, отчеты об испытаниях | 1: 4.5.5.1, 4.5.5.2 2: 4.5.5.1, 4.5.5.2 | План улучшения (включая политику улучшения) |
План управления сервисами, требования к услуге, дизайн услуги | 2: 4.2.1, 4.2.5, 4.3.1.1, 4.5.2.3, 4.5.3 | Контракт (соглашение) |
ДИЗАЙН И ПЕРЕХОД НОВЫХ ИЛИ ИЗМЕНЕННЫХ СЕРВИСОВ | ||
Политика управления сервисами, политика управления изменениями, контракт, требования клиентов | 1: 5.1, 5.2, 5.3 | Спецификация системных требований (требования к сервису) |
Политика управления сервисами, политика управления изменениями, контракт, цели, требования клиентов, требования к сервису, отчеты об эффективности | 1: 5.2, 5.3 2: 5.2.7, 5.3.3.1 | Сервисный план (план новых или измененных сервисов) |
План управления сервисами, требования к сервису, дизайн сервиса | 1: 5.2, 5.3 2: 5.2.8 | Контракт (соглашение) |
План управления сервисами, план обслуживания, дизайн услуги | 1: 5.2 2: 5.2.8 h | Описание интерфейса |
План управления сервисами, каталог услуг | 1: 5.2 2: 5.2.8 | План утилизации |
План управления сервисами, SLA | 1: 5.3 | Каталог услуг |
Контракт (или соглашение), план управления сервисами, каталог услуг | 1: 5.3 2: 5.3.1, 5.5 | Соглашение об уровне обслуживания (SLA) |
План управления сервисами, SLA | 1: 5.3 | Процедура (типовой информационный элемент) |
План управления сервисами, соглашение об уровне обслуживания, отчет аудита | 1: 5.4 2: 5.2.8, 5.4, 5.5 | Отчет о сервисе |
УПРАВЛЕНИЕ УРОВНЕМ СЕРВИСА | ||
SLA, план управления сервисами | 1: 6.1 2: 6.1.4 | Контракт (соглашение) |
План управления сервисами, договор (соглашение о подряде или операционном уровне), каталог услуг. Запрос на внесение изменений, отчет об обслуживании, процедуры управления сервисами, организационные процедуры или процедуры клиента, политика безопасности, эффективность обслуживания, непрерывность и требования доступности | 1: 6.1 2: 6.1.3.2, 6.1.3.3, 6.1.3.4, 6.1.4 | Соглашение об уровне обслуживания (SLA) |
План управления сервисами, SLA | 1: 6.1 2: 6.1.3.4, 6.1.4 | Каталог услуг |
SLA, контракт, план обслуживания, отчет о проблеме, отчет мониторинга и контроля, отчет о расходах, процедура управления деловыми отношениями | 1: 6.1 2: 6.1.4 | Протокол анализа проекта |
Отчет об обслуживании, план управления сервисами | 2: 6.1.4 | План по улучшению |
SLA, доступность, запись об инциденте, запись жалобы | 2: 6.1.3.1, 6.1.3.4, 6.1.4 | Отчет об обслуживании |
SLA, процедура обслуживания | 2: 6.1.4 | Отчет по мониторингу и контролю |
ОТЧЕТНОСТЬ ПО СЕРВИСУ | ||
План обеспечения непрерывности обслуживания, отчет о мониторинге и контроле; SLA; отчет об инциденте; отчет о проблеме; релиз; спецификация требований к отчетности службы; мониторинг и контроль за данными о производительности, несоответствие стандартам, характеристикам рабочей нагрузки и информации о объемах, информации о тренде по периодам (например, день, неделя, месяц, период); будущие и запланированные рабочие нагрузки | 1: 6.2 2: 6.2.1, 6.2.2, 6.2.3, таблица A.3 | Отчет об обслуживании |
SLA, план аудита | 2: 6.2.3 c) | Аудиторский отчет |
ОБЕСПЕЧЕНИЕ БЕЗОПАСНОСТИ И ДОСТУПНОСТИ | ||
Бизнес-план; SLA; оценка риска; требования доступности и непрерывности сервиса; полный план, процедура восстановления услуги; запрос на внесение изменений | 1: 6.3 2: 6.3.2, 6.3.3.2, 6.3.3.3 | Планирование доступности и непрерывности обслуживания (включает доступность услуг и непрерывность) |
Записи доступности, соглашение об уровне обслуживания, план доступности и непрерывности услуг, результаты тестирования, планы действий, план управления рисками, план обеспечения непрерывности обслуживания | 1: 6.3.3 2: 6.3.4.3, 6.3.5 | Отчет об оценке |
SLA, план проверки | 2: 6.3.5 | Отчет об интеграции и тестировании (отчет о непрерывности обслуживания и доступности) |
Планирование доступности и непрерывности обслуживания, SLA | 2: 6.3.5 | Отчет по мониторингу и контролю |
Планирование доступности и непрерывности обслуживания, SLA | 2: 6.3.5 | План проверки (план обеспечения непрерывности и доступности услуг) |
БЮДЖЕТ И УЧЕТ УСЛУГ | ||
Бизнес-политика и финансовые процедуры, предыдущие бюджеты и отчеты о расходах, отчеты о финансовых прогнозах, план управления сервисами, SLA. Примечание - Бизнес-политика и финансовые процедуры, касающиеся составления бюджета, финансового учета и отчетности по расходам, выходят за рамки настоящего стандарта. | 1: 6.4 2: 4.4.1.2, 6.4.1, 6.4.2 | Финансовый менеджмент, бюджетирование и учетные политики и процедуры. Бюджет. Отчет о финансовом учете (отчет о расходах) Примечание - Содержание этих финансовых документов далее не указано в настоящем стандарте. |
УПРАВЛЕНИЕ МОЩНОСТЬЮ | ||
Полный план | 1: 6.5 2: 6.5.3.2, 6.5.4 | Процедура управления мощностями |
План управления сервисами. SLA, требования к мощности и производительности (текущие и будущие), данные и аналитические данные об использовании потенциала, отчеты об управлении изменениями | 1: 6.5 2: 6.5.1, 6.5.2, 6.5.3.2, 6.5.4 | Полный план |
Данные о мощности и производительности, отчет о проблемах, отчет мониторинга и контроля | 2: 6.5.3.1, 6.5.4 | Отчет об обслуживании |
УПРАВЛЕНИЕ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТЬЮ | ||
Организационная политика, правила | 1: 6.6.1 2: 6.6.2, 6.6.3.1, 6.6.4, таблица A.7 | Политика информационной безопасности |
План информационной безопасности, описание контроля безопасности, отчет об инциденте; отчет о проблеме, оценка процесса | 1: 6.6.2 2: 6.6.4 | Отчет об оценке |
Политика и план информационной безопасности, процедуры управления проблемами | 1: 6.6.2 2: 6.6.2, 6.6.4 | Процедуры информационной безопасности |
План информационной безопасности, отчет мониторинга и контроля, процедуры управления инцидентами, записи инцидентов | 1: 6.6.2, 6.6.3 2: 6.6.3.4, 6.6.4 | Отчет об инциденте |
Политика информационной безопасности, спецификация требований. Процедура оценки риска информационной безопасности, план управления рисками, процедура контроля безопасности | 2: 6.6.2, 6.6.4 | План информационной безопасности |
Политика и план информационной безопасности | 2: 6.6.3.4 n) | План обучения |
Отчет об инциденте, отчет о проблеме, отчет об оценке | 2: 6.6.3.5 | Запрос на внесение изменений |
УПРАВЛЕНИЕ БИЗНЕС-ОТНОШЕНИЯМИ | ||
SLA, план управления сервисами, процедура подачи жалоб | 1: 7.1 2: 7.1.3.1, 7.1.3.3, 7.1.4, таблица A.8 | Жалоба (запись) |
Соглашение, SLA, план управления сервисами | 1: 7.1 2: 7.1.3.3, 7.1.4 | Процедура подачи жалобы |
SLA, план взаимодействия | 2: 7.1.1 | Процедура взаимодействия |
SLA, контракт, поощрение, жалоба | 1: 6.2.5.3.1.4, 7.1 2: 7.1.3.3, 7.1.4, таблица A.8 | Исследование степени удовлетворенности клиентов |
SLA, контракт, план управления сервисом, отчет о проблеме, отчет о мониторинге и контроле, отчет о стоимости, процедура управления бизнес-отношениями | 1: 7.1 2: 7.1.4 | Протокол обзора |
SLA, отчет о проблеме, исследование степени удовлетворенности клиентов, оценка деятельности | 2: 7.1.4 | Отчет о сервисе |
УПРАВЛЕНИЕ ПОСТАВЩИКАМИ | ||
Соглашение об уровне сервиса, план управления сервисом, сервис-каталог, запрос изменений, политика информационной безопасности | 1: 7.2 2: 7.2.2, 7.2.3.1, 7.2.4 | Контракт (и изменения контракта) |
Контракт, процедура управления поставщиками | 1: 7.2 2: 7.2.4 | Описание интерфейса |
План управления сервисом, контракт, SLA поставщиков | 1: 7.2 2: 7.2.2, 7.2.3.2 | Соглашение об уровне сервиса (SLA) |
Контракт, SLA, отчет о мониторинге и контроле | 1: 7.2 2: 7.2.3.1 | Отчет о сервисе |
Организационная политика, план управления сервисом, соглашение об уровне сервиса | 1: 7.2 2: 7.2.2 | Процедура управления поставщиками |
УПРАВЛЕНИЕ ИНЦИДЕНТАМИ И ЗАПРОСАМИ НА ОБСЛУЖИВАНИЕ | ||
Процедура управления изменениями, план управления службами, база данных управления конфигурациями, известные ошибки, каталог служб, SLA | 1: 8.1 2: 8.1.2, 8.1.4, 8.1.5 | Процедура управления инцидентами или процедура управления запросами на обслуживание |
Процедура инцидента, известная ошибка и разрешение проблемы, записи конфигурации | 2: 8.1.5 | Отчет об инциденте |
УПРАВЛЕНИЕ ПРОБЛЕМАМИ | ||
Отчет о проблеме | 1: 8.2 | Запрос на внесение изменений |
SLA, план управления сервисами | 1: 8.2 2: 8.2.2, 8.2.3, 8.2.4 | Процедура и политика управления проблемами |
Отчет об инциденте, информация об известных ошибках, процедура управления проблемами | 1: 8.2 2: 8.2.4 | Отчет о проблеме |
Анализ проблем, отчеты о проблемах | 1: 8.2 2: 8.2.4 f) | Протокол анализа проекта |
УПРАВЛЕНИЕ КОНФИГУРАЦИЕЙ | ||
Процедура управления конфигурацией, отчет о состоянии конфигурации | 1: 9.1 2: 9.1.3.2, 9.1.4 | Аудиторский отчет |
Процедура управления конфигурацией | 1: 9.1 2: 9.1.3.5 | Запрос на внесение изменений |
План управления конфигурацией | 1: 9.1 2: 9.1.3.2, 9.1.3.3, 9.1.4 | Процедура управления конфигурацией |
План управления сервисами | 1: 9.1 | Описание интерфейса |
Политики управления системой, описание системного дизайна, соглашение об уровне обслуживания, спецификация системных требований, политика управления конфигурацией | 2: 9.1.2, 9.1.3.2, 9.1.3.3, 9.1.4 | План и политика управления конфигурацией |
План аудита, план и политика управления конфигурацией, записи конфигурации | 2: 9.1.3.2, 9.1.3.5 | Процедура аудита |
Процедура управления конфигурацией, записи конфигурации | 2: 9.1.1, 9.1.4 | Отчет о статусе конфигурации |
УПРАВЛЕНИЕ ИЗМЕНЕНИЯМИ | ||
Отчет об инциденте, отчет о проблеме, отчет о статусе конфигурации | 1: 9.2 2: 9.2.2, 9.2.3.2, 9.2.3.3, 9.2.4 | Запрос на внесение изменений |
Контракт, политики управления системой, запросы на изменение, каталог услуг, план доступности и непрерывности услуг, план управления сервисами, требования к сервису, процедура управления проблемами, SLA, план обеспечения бесперебойной работы и доступности, полный план, изменения сметы расходов | 1: 9.2 2: 9.2.3.1, 9.2.3.2, 9.2.4 | План и политика управления конфигурацией (план и политика управления изменениями) |
План управления конфигурацией, процедура управления проблемами, SLA | 1: 9.2 2: 9.2.2, 9.2.4 | Процедура управления конфигурацией (процедура управления изменениями) |
Запрос на внесение изменений, план управления изменениями, процедуры управления изменениями | 2: 9.2.4 | План выпуска версий (план развертывания) |
Запрос на внесение изменений | 2: 9.2.3.2, 9.2.4 | Отчет об оценке |
УПРАВЛЕНИЕ ВЫПУСКОМ И РАЗВИТИЕМ | ||
Запрос на внесение изменений, SLA | 1: 9.3 2: 9.3.3.2, 9.3.3.3 | Процедура управления конфигурацией (процедура управления выпуском) |
План выпуска версий, план управления версиями | 1: 9.3 2: 9.3.4 | Отчет об оценке |
Политика управления изменениями, план управления сервисами, план тестирования, план проверки, план принятия, план утилизации, график выпуска, запрос на внесение изменений | 1: 9.3 2: 9.3.3.1, 9.3.3.2, 9.3.4 | План и политика выпуска |
План тестирования, отчеты об инцидентах или записи | 2: 9.3.3.4, 9.3.4 | Отчет об интеграции и тестировании |
План управления выпуском, план выпуска; запрос на изменение, отчет о проблеме | 2: 9.3.3.4, 9.3.4 | План проверки (план тестирования) |
План выпуска версий, план управления сервисами | 2: 9.3.4 | Процедура коммуникации (план коммуникаций) |
План выпуска версий, план управления сервисами | 2: 9.3.4 | Учебный план |
План выпуска версий, план установки, план интеграции и тестирования | 2: 9.3.4 | Документация пользователя |
Разработка и переход нового или измененного процесса обслуживания
Процессы предоставления услуг
1) Управление уровнем обслуживания.
2) Отчеты служб.
3) Непрерывность обслуживания и доступности.
4) Бюджетирование и учет услуг.
5) Управление пропускной способностью.
6) Управление информационной безопасностью.
Процессы взаимодействия
1) Управление бизнес-отношениями.
2) Управление поставщиками.
Процессы разрешения
1) Управление запросами на инциденты и услуги.
2) Управление проблемами.
Процессы управления
1) Управление конфигурацией.
2) Управление изменениями.
3) Управление выпуском и развертыванием.
В данном разделе описывается Типовой и конкретный контент записей, указанных в ISO/IEC/IEEE 12207, ISO/IEC/IEEE 15288, ИСО/МЭК 20000-1 (IEEE 20000-1) и ИСО/МЭК 20000-2 (IEEE 20000-1). Проект, организация или служба должны вести записи, необходимые для требуемых информационных элементов (документов). Записи содержат данные, структурированные в постоянной, удобочитаемой форме. Записи могут быть сгенерированы для любого процесса жизненного цикла, задачи или деятельности в проекте или организации, для включения данных о требованиях, политиках, решениях и их обосновании, проектах, исходном коде, проблемах, отзывах, запросах, измерениях и тестовых данных, а также для включения товарных, качественных, юридических, официальных, финансовых и исторических данных. Записи должны сохраняться для поиска в реестрах, репозиториях или базах данных.
Цель: Организация данных, сохраняемых организационным подразделением.
Примечание - Согласно серии ИСО 9000, цель записи состоит в том, чтобы заявить о достигнутых результатах или представить доказательства деятельности, выполненной организацией.
Запись должна включать следующие элементы:
a) дату записи, дату записи и статус;
b) область применения;
c) предмет или категорию;
d) сведения об организации, выдавшей документ;
e) ссылки;
f) основную часть;
g) уникальный идентификатор записи.
В таблице 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. В таблице B.2 приведено сравнение записей по источникам.
Примечания
1 Термин "запись конфигурации" может использоваться как для записи отдельного компонента (элемента) в конфигурации, так и для записи конфигурации системы в определенный момент времени (основные данные).
2 ИСО/МЭК 20000-1 (IEEE 20000-1) и ИСО/МЭК 20000-2 (IEEE 20000-2) различают жалобы, инциденты и проблемы. Проблема является основной причиной одного или нескольких инцидентов, или жалоб. Для целей управления информацией в настоящем стандарте записи о жалобах, инцидентах и проблемах имеют сходное содержимое и часто используют одни и те же или связанные с ними системы управления записями.
Таблица 4
Запись | Процесс | Ссылка | Содержимое записи |
Запись о принятии | Управление сервисом | 20000-2: 5.4, 7.2.3.2 | Приобретатель подтвердил, что критерии приемки выполнены |
Запись об оценке (аудиторская запись) | Управление моделью жизненного цикла, оценка и контроль проекта, управление сервисами, управление информационной безопасностью, управление конфигурацией | 12207: 6.2.1.3.2.1, 6.2.1.3.3.2, 6.3.2.2, B.3.3.2.2 15288: B.1 20000-1: 4.5.4.1, 4.5.4.2, 5.2 20000-2: 6.6.3.3, 9.1.3.2 | Информация и данные, связанные с использованием стандартного процесса для конкретных проектов и услуг; результат аудита или оценки |
Запись о доступности | Обеспечение бесперебойной работы и доступности | 20000-1: 6.3.3 20000-2: 6.3.4.2, 6.3.5 | Время отклика по сравнению с SLA, фактическое доступное время, деленное на запланированное время |
Запись о жалобе (похвале) | Управление деловыми отношениями, управление поставщиками | 20000-1: 7.1 20000-2: 7.1.3.3, 7.1.4, 7.2.3.4, таблица A.8 | Клиент, вид клиента, отклонение, дефект, противоречивые требования или несоответствие; категория претензий, действия по исправлению, известная ошибка, информация о спорах, ответственность, разрешение. См. Отчет о проблеме, запрос на внесение изменений |
Запись о конфигурации (запись об активах, запись об изменениях) | Управление конфигурацией, внедрение, обслуживание, удаление, повторное использование, управление активами, проектирование доменов, управление информационной безопасностью, управление проблемами, управление выпуском и развертыванием | 15288: 6.2.5.3 b), 6.4.4.3 b) 12207: 6.3.5.3.1.2, 6.3.5.3.2.1, 6.3.5.3.2.2, 7.2.2.3.3.1 20000-1: 3.4, 9.1, 9.2 20000-2: 4.1.4.3, 4.3.2, 4.3.3, 9.1.1, 9.1.2, 9.1.3.1, 9.1.3.3, 9.1.3.4, 9.1.3.5, 9.1.4, 9.1.5, 9.2.2, 9.2.3.3, 9.2.4 | Функциональные и физические характеристики, версия, местоположение, статус конфигурации; одобрения и разрешения; связанные записи, связанные записи инцидента или проблемы, связанные известные ошибки, связанные с ними запросы на изменение, связанные инциденты или запросы на обслуживание, обоснование для одобрения исходных условий; изменения исходных условий; связь с требованиями; указание, что единица или элемент выполнили соглашение или требования; данные по техническому обслуживанию, сбоям и продолжительности работы; запись об утилизации владельцем, использованием и критичностью активов и выполняемые действия, такие как резервное копирование, хранение, архивирование, обработка и доставка настроенных элементов. Сохраняется в базе данных управления конфигурацией (CMDB) или журнале изменений. См. запрос о внесении изменений, запись об инциденте, запись о проблеме, запись о выпуске, запись о конфигурации программного элемента, описание системного элемента |
Запись о решении | Управление решениями, управление поставщиками, системный анализ | 12207: 5.1.2, 6.3.3.1 15288: 6.3.3.1, 6.3.3.3.1, 6.4.6.3 b), B.1 20000-1: 4.5.4.3 20000-2: 4.1.1.2, 5.4, 7.2.4 | Решение, допущения и обоснование; не устраненные действия |
Запись об утилизации | Утилизация | 12207: 6.4.11.1, 6.4.11.2 e) | Действия по удалению для будущего анализа рисков и воздействия |
Запись об инциденте (запись о переходе, запись об инциденте безопасности, запись запроса на обслуживание, запись основных инцидентов, запись поддержки клиентов) | Управление обслуживанием, поставкой, непрерывностью обслуживания и доступностью, управление емкостью, управление информационной безопасностью, управление запросами на инциденты и обслуживание, управление изменениями, управление проблемами, управление выпуском и развертыванием | 15288: 6.4.10.3 b), 2) 20000-1: 6.6.3, 8.1 20000-2: 4.2.3, 3.1.2, 4.3.3, 5.5 6.3.3.3, 6.3.4.2, 6.5.4, 6.6.3.4, 6.6.3.5, 6.6.4, 8.1.2, 8.1.3.1, 8.1.3.2, 8.1.5, 8.2.1, 9.3.3.5, 9.3.4, таблица A.2, таблица A.10 | Краткое описание инцидента, запрос на обслуживание, связанные элементы конфигурации, дисперсия, аномалия, дефект или несоответствие; приоритет, категория инцидентов, первопричина, действия по исправлению ошибок, известная ошибка, назначенная ответственность и эскалация, разрешение и закрытие. См. отчет об инциденте, запрос на внесение изменений |
Запись об информационном элементе (хранения) | Управление информацией | 12207: 6.3.6.2, 6.3.6.3.2.2 15288: 6.3.6.2 d), 6.3.6.3 b), | Статус информации, описание версии, запись распределения, классификация безопасности |
Запись управления знаниями | Управление моделью жизненного цикла, управление персоналом, управление знаниями, удаление, управление запросами и обслуживанием, управление проблемами | 12207: 6.2.4.3.3.5 15288: 6.2.4.3, 6.4.11.3 b) | Знания, рекомендуемая применимость, использование знаний |
Запись о контроле производительности | Управление сервисами, управление поставщиками | 20000-1: 6.1, 7.2 20000-2: 7.2.3.2 | Данные об эффективности обслуживания по целям, результаты применения процесса, уровень качества обслуживания |
Запись навыков персонала (запись задания персонала) | Управление персоналом, обслуживание | 15288: 6.2.4.3 a) 2) 20000-1: 4.4.2 20000-2: 4.4.2.2 | Идентификатор сотрудника, умения, уровня владения. См. также отчет о развитии навыков |
Запись о проблеме (запись об известной ошибке) | Контроль принятия решений, интеграция, сопровождение, оценка и контроль проектов, контроль качества, анализ программного продукта, аудит программного продукта, программные операции, обеспечение качества программного продукта, разрешение проблем программного продукта, проверка программного продукта, проектирование доменов, управление повторным использованием, управление конфигурацией, управление проблемами, управление выпуском и развертыванием | 15288: 6.3.3.3, 6.4.5.3, 6.4.10.1, 6.4.10.2 12207: 6.1.2.3.4.8, 6.3.2.3.2.1, 6.3.3.3.1.3, 6.3.3.3.3.2, 6.4.9.3.1.2, 6.4.9.3.4.1, 6.4.10.3.1.2, 7.2.3.2 c), 7.2.3.3.1.4, 7.2.4.2 d), 7.2.5.2 d), 7.2.6.2 e), 7.2.6.3.1.4, 7.2.7.2, 7.2.7.3.1.5, 7.2.8.2 b), 7.2.8.3.1.1, 7.3.3.3.5.3 20000-1: 3.19, 8.2, 9.1 20000-2: 4.5.5.2, 6.3.4.2, 8.2.2, 8.2.3, 8.2.4, 8.2.5, 9.3.3.5, 9.3.4, таблица A.10 | Проблема, дисперсия, дефект или несоответствие; проблемная категория, связанный элемент конфигурации, действия по исправлению ошибок, известная ошибка, первопричина, назначенная ответственность, разрешение. См. также отчет о проблеме, запрос на внесение изменений |
Протокол авторизации проекта | Управление портфелем, планирование проектов, оценка проектов и контроль | 12207: 7.2.3.3.1.3 c), 7.2.3.3.1.4, 7.2.3.3.1.5 20000-1: 4.3.3 20000-2: 4.3.3 | Описание проекта, ответственная организация, период авторизации |
Протокол о деятельности по обеспечению качества | Обеспечение программного продукта, улучшение | 12207: 7.2.3.3.1.3 c), 7.2.3.3.1.4, 7.2.3.3.1.5 20000-1: 4.3.3 20000-2: 4.3.3 | Выполнение деятельности по обеспечению качества, такой как рассмотрение или оценка документов |
Данные о стоимости качества | Управление моделью жизненного цикла | 12207: 6.2.1.3.3.3 | Устанавливает затраты на предотвращение и устранение проблем и несоответствий и улучшение процесса поддержки |
Запись о выпуске | Поставка, управление программным продуктом, управление выпуском и развертыванием Управление конфигурацией | 12207: 6.4.9.3.1.3, B.3.2.3.2 20000-1: 9.3 20000-2: 9.1.2, 9.3.3.5, 9.3.4 | Определяет, отслеживает и контролирует выпуск и его элементы конфигурации во время выпуска версии (включая базовую версию) Для программного продукта он идентифицирует версию программного продукта, состоящую из одного или нескольких элементов программного продукта. В нем перечислены поставляемые предметы, включая версии системных и программных элементов, прослеживаемость по спецификациям или предыдущим выпускам, которые были изменены; известные ошибки, проблемы и обходные пути. Он может ссылаться на процедуры установки или доставки и информацию об успешном выпуске, или связанные с этим проблемы |
Запись о требованиях | Определение требований заинтересованных сторон, все процессы и службы управления сервисами | 15288: 6.4.1.3 12207: 6.4.1.3.5.1 20000-1 3.34, 4.1.4, 4.5.2, 5.2, 6.3.1, 6.5, 7.1, 7.2 20000-2: 4.1.1.3, 4.1.1.7, 4.1.1.8, 4.1.1.9, 4.1.1.10, 4.1.4.3, 4.5.2.1, 4.5.2.2, 4.5.2.4, 5.2.4, 5.2.5, 5.2.7, 5.3.1, 5.5, 6.1.4, 6.2.3, 6.3.5, 6.5.4 | Прослеживаемость, приоритет, ресурсы, ограничения, возможности, непрерывность и доступность, удобство использования, безопасность и надежность, защита информации, окружающая среда, законодательная, нормативная, финансовая отчетность, качество. См. также: спецификацию требований к программному продукту, спецификацию системных требований (требования к сервисам) |
Запись или профиль риска (возможности) | Управление рисками, определение требований заинтересованных сторон. Операции, анализ программного продукта, управление сервисами, управление непрерывностью обслуживания, управление информационной безопасностью, управление изменениями | 12207: 6.3.4.3.2, 6.3.4.3.3.4, 6.4.1.3.2.5, 6.4.9.3.1.1, 7.2.6.2 e) 15288: 6.3.4.3 b) 20000-1: 4.1.1, 4.5.5.1, 5.2, 6.3.1, 6.6.1, 9.2 20000-2: 4.1.1.10, 4.1.1.11, 5.2.3, 5.2.6, 6.6.3.3, 9.2.4 | Источник, вероятность, последствия, допустимый порог, приоритет, требования к риску, стратегия исправления, статус, а также возможности для улучшения. Хранится в реестре рисков |
Запись о развитии навыков (учебная запись) | Управление персоналом, управление информационной безопасностью | 12207: 6.2.4.3.2.3, 6.2.4.3.3.5 15288: 6.2.4.3 b) 4) 20000-1: 4.4.2 e) 20000-2: 4.4.2.2, 6.3.5, 6.6.3.4 n) | Область навыков, данные о сотрудниках, продолжительность обучения, уровень владения, сертифицирующий орган. См. также: Запись о навыках персонала |
Запись о конфигурации элемента программного продукта (запись программного продукта) | Управление конфигурацией программного продукта | 12207: 7.2.2.2 e), 7.2.2.3.2.1, 7.2.2.3.4.1, 7.3.1.2 e), 7.3.1.3.4.2, 7.3.2.2 e) | Индекс конфигурации программного продукта может содержать записи конфигурации программного продукта для одного элемента программного продукта или набора программных элементов. В записи конфигурации элемента программного продукта должны быть указаны универсальная информация о записи, программный продукт (источник), код исполняемого объекта, данные архива и выпуска, инструкции по созданию исполняемого объекта и проверки целостности данных для исполняемого объекта и повторное использование активов |
Ведомость о результатах теста (ведомость выполнения) | Развитие, применение, проверка, одобрение, испытание качества системы, испытание качества программного продукта, управление непрерывностью и доступностью сервиса | 12207: 6.4.6.2, 7.1.6.2 e), 7.1.7.2, 7.1.7.3.1.1 20000-1: 6.3.3 20000-2: 5.3.3.2, 9.3.3.2, 9.3.3.4 | Результаты испытаний или применения, включая записи о проверке и одобрении |
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.13 b) 6).
Типовой вид: План.
План принятия необходимо подготавливать на основе определенной стратегии принятия с учетом критериев принятия. В нем указаны объективные критерии для определения приемлемости поставляемых рабочих продуктов и любых технических процессов, методов или инструментов, необходимых для принятия продукта. Должны быть указаны такие методы, как тестирование, демонстрация, анализ и проверка. Это указывает на степень участия поставщиков. Если принятие основано на тестах, то можно ссылаться на или предоставлять Типовой план тестирования.
См. также: План тестирования интеграции программного обеспечения.
10.3 Отчет о приемке
ISO/IEC/IEEE 12207, ссылка: 6.4.8.3.1.1.
ISO/IEC/IEEE 15288, ссылки: 6.1.1.3 e) 1), B.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.3 b) 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 c), 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.3 c) 2), 6.1.2.3 c) 2), 6.3.2.3 c) 3), B.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, таблица A.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 c), 6.4.2.2 b), 6.4.2.3 b), 6.4.2.3 c), B.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.
Типовой вид: План и Политика.
Политика управления конфигурацией (CM) (или политика управления изменениями) включает политику определения элементов конфигурации и ее компонентов, а также того, какие элементы подлежат контролю изменений и управлению выпуском.
Политика управления конфигурацией или изменениями может быть включена в план управления конфигурацией или изменениями, или может быть представлена в виде отдельного набора политик.
Политика управления изменениями определяет, что представляет собой существенное изменение и аварийное изменение (аварийное освобождение), а также обязанности по санкционированию и осуществлению нормальных и чрезвычайных изменений.
План управления конфигурацией (CM) (или план управления изменениями или релиз и развертывание) описывает ответственную организацию для авторизации и выполнения этих действий, а также их связь с другими организациями, такими как разработка программного обеспечения, управление активами, поставщики и субподрядчики и техническое обслуживание. Для наблюдательного совета или специальной организации, созданной для авторизации и выполнения деятельности CM по проекту, в плане должны быть указаны его цель и задачи; членство и присоединение; объем полномочий; и оперативной практики.
Для программного продукта план CM должен включать в себя то, как организация выполняет:
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 e), 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, B.3.2.2.1, B.3.2.2.2, B.3.1.2.2, B.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, таблица A.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, таблица A.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.3 b).
Типовой вид: Процедура.
Процедура применения подробно описывает, как создаются система или системные элементы для удовлетворения требований дизайна. Процедуры применения могут касаться конфигурации аппаратного обеспечения системы и программного продукта; создания и компиляции программного продукта, а также оперативной готовности.
См. также: Процедура эксплуатационных испытаний, учебная документация.
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) информацию о закрытии инцидента;
l) информацию из анализа организации (внутреннего).
Примечание - ИСО/МЭК 20000-1 (IEEE 20000-1) и ИСО/МЭК 20000-2 (IEEE 20000-2) различают инциденты и проблемы. Ответ на инцидент связан с восстановлением обслуживания пользователей, тогда как решение проблемы связано с выявлением и устранением причин инцидентов. Отчет о возможности аналогичен, но включает анализ потенциальных положительных событий.
См. также: Запрос на внесение изменений, инцидент (запись), отчет о проблеме, сервисный запрос (запись).
10.33 План управления информацией
ISO/IEC/IEEE 15288, ссылка: 6.3.6.3, D.4 m).
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) положения для управления контентом или стратегии повторного использования и контроля версий (управление конфигурацией документов);
e) графики разработки, рассмотрения и одобрения информации;
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, таблица A.11.
Типовой вид: Процедура.
Процедура управления информацией (или процедура управления записями) описывает, как управлять и контролировать информацию, такую как контент или записи. Она включает процедуры идентификации, обновления, хранения, извлечения и архивирования или удаления информации.
См. также: Процедура документации.
10.35 План информационной безопасности
ИСО/МЭК 20000-2 (IEEE 20000-2), ссылки: 6.6.2, 6.6.3.2, 6.6.4, таблица A.14.
Типовой вид: План.
План информационной безопасности включает следующее:
a) описание того, как организация идентифицирует, контролирует и защищает физическую и логическую безопасность систем, активов и информации;
b) описание того, как внедряются требования к конфиденциальности, целостности и доступности информации;
c) описание того, как система или служба отказывается от несанкционированного доступа, разрешает авторизованный доступ, защищает данные при передаче, хранении и обработке и обеспечивает безопасность экономически эффективным образом;
d) описание рисков безопасности и связанных с ними средств контроля, включая средства контроля доступа и способы управления и обслуживания элементов управления безопасностью;
e) описание системного мониторинга, мониторинга для выявления инцидентов безопасности и анализа тенденций безопасности;
f) конкретные процедуры защиты конфиденциальных персональных данных и данных ограниченного пользования, расследования проблем безопасности и отчетности;
g) процедуры анализа эффективности политики, процедур и действий в области информационной безопасности.
Примечание - ИСО/МЭК 27002 содержит рекомендации по управлению информационной безопасностью. ИСО/МЭК 27001 направлен на процессы управления информационной безопасностью (ISMS) для создания, внедрения, эксплуатации, мониторинга, анализа, поддержания и улучшения информационной безопасности.
10.36 Политика информационной безопасности
ISO/IEC/IEEE 12207, ссылка: 6.1.2.3.4.5 l).
ИСО/МЭК 20000-1 (IEEE 20000-1), ссылка: 6.6.1.
ИСО/МЭК 20000-2 (IEEE 20000-2), ссылки: 6.6.2, 6.6.3.1, 6.6.4, таблица A.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, таблица A.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.2 d), 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.8 h), 7.2.4.
Типовой вид: Описание.
Описание интерфейса описывает характеристики интерфейса одной или нескольких систем, подсистем, доменов, аппаратных элементов, программных элементов, ручных операций (процессов) или других компонентов системы. В нем представлены характеристики интерфейса, включая системы или элементы конфигурации, составляющие интерфейс (включая интерфейсы человек-система и человек-человек), стандарты и протоколы, ответственные стороны, информацию или записи данных, передаваемые интерфейсом, график работы интерфейса и обработку ошибок. Описание включает интерфейсные диаграммы для отображения интерфейсов. Оно должно определять существующие или постоянные характеристики интерфейса и те, которые разрабатываются или модифицируются.
10.43 Политика и процедура жизненного цикла
ISO/IEC/IEEE 15288, ссылки: 6.2.1.1, 6.2.1.2, 6.2.3.3 b) 1) iii), A.2.3, B.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, A.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.
ИС NORMPROD: примечание. Текст дан в соответствии с официальным текстом документа. |
ИСО/МЭК 20000-2 (IEEE 20000-2), ссылка: Типовой вид: Процедура.
Процедура технического обслуживания охватывает процессы для проведения профилактического и корректирующего обслуживания и предоставления пользователям обратной связи службы поддержки. Она должна определить конкретные стандарты, методы, инструменты и обязанности в рамках деятельности по техническому обслуживанию. Она может определять системы или области программных продуктов, которые могут меняться, и необходимость в обучении. Процедуры технического обслуживания систем охватывают стратегию демонтажа, методы диагностики неисправностей и последовательности повторной сборки и тестирования. Процедуры обслуживания программных продуктов включают процедуры архивирования, резервного копирования и восстановления.
См. также: Процедура управления проблемами.
10.46 План измерений
ISO/IEC/IEEE 15288, ссылка: 6.3.7.3.
ISO/IEC/IEEE 12207, ссылки: 6.3.7.2 c), 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.3 b), 6.3.7.1, 6.3.7.3 b).
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.3 a) 2), 6.4.5.3 b), 6.4.6.2 b), 6.4.6.3 b), 6.4.7.2 e), 6.4.7.3 b), 6.4.8.3b), 6.4.9.2c), 6.4.10.2e), 6.4.10.3 b).
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.2 f), 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, B.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) информацию о закрытии проблемы;
l) информацию из анализа организации (внутреннего).
Для проблем, возникающих во время тестирования или работы, отчет должен включать в себя входы, ожидаемые результаты, фактические результаты, отклонения, дату и время, шаг процедуры, среду, попытки воспроизвести проблему и наблюдателей.
Он может сообщать о временном или постоянном решении проблемы.
См. также: Запрос на внесение изменений, отчет об инциденте, запись проблемы.
10.51 Процедура оценки процесса
ISO/IEC/IEEE 12207, ссылка: 6.2.1.3.2.1.
Типовой вид: Процедура.
Процедура оценки процесса описывает, как проводить процесс улучшения жизненного цикла и как оценить соответствие и эффективность организационных процессов. Она может включать цели оценки.
10.52 Аналитический отчет о процессе улучшения
ISO/IEC/IEEE 15288, ссылки: 6.2.1.3 c), 6.3.7.3 c).
ISO/IEC/IEEE 12207, ссылки: 6.2.1.3.3.2, B.3.3.1.2, B.3.3.2.2, B.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.
ИС NORMPROD: примечание. Текст дан в соответствии с официальным текстом документа. |
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.2 b), B.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.3 d), 6.3.2.3 b).
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.1 f), 6.1.4, 7.1.4, 7.2.4, 8.2.4 f).
Типовой вид: Отчет.
Протоколы анализа (или совместные протоколы анализа или протоколы анализа услуг) предоставляют отчет о проведении анализа, например, встречу покупателя и поставщика, или поставщика услуг и клиента. Протоколы включают участников, повестку дня, рассматриваемый продукт или сервис, цели, точки входа и выхода для анализа, основные темы обсуждения, предположения, презентационные материалы, решения, касающиеся ресурсов, и совершенствование системы управления сервисами и услуги, одобрения, действия по исправлению нарушений, их статус и критерии закрытия. Протоколы документируют оценку состояния и соответствия продуктов и услуг, а также видов деятельности и статуса графика. Протоколы включают обнаруженные проблемы и их разрешение или предполагаемое разрешение.
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, таблица A.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:2012 (Стандарт 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 e), 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 c), 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, таблица A.3, таблица A.7, таблица A.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) конструктивные ограничения и требования к проектированию системы;
l) требования к системе тестирования и квалификации;
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, B.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.7 b), 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.4 d).
Типовой вид: Отчет.
В отчете одобрения представлены результаты и выводы проверки по элементу программного обеспечения, системе или подсистеме. Это позволяет приобретателю оценить подтверждение и его результаты. Он включает идентификацию и анализ системы, требования и критерии проверки, анализ результатов, идентификацию проверяемых элементов и даты проверки, подробные результаты, возникшие проблемы и обоснование для принятия решений.
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) назначенные обязанности по выполнению процедур тестирования, включая: место и организацию для менеджера тестов, лаборантов, обеспечение качества, управление конфигурацией, оценку и отчетность по тестам, а также участие поставщиков в тестировании;
l) описание тестовой среды, инструментов тестирования и вспомогательного оборудования и программного продукта;
m) подготовку к тестам или тестовые образцы, которые необходимо собрать или построить;
n) для каждого тестового образца, списки данных, которые будут использоваться во время тестирования;
o) последовательность событий (последовательность выполнения тестовых процедур) и процедуры/этапы для выполнения теста (например, требования к процедуре предварительной проверки, настройка теста, выполнение теста, этапы анализа после тестирования, инструкции по завершению);
p) ожидаемые результаты тестирования (выходные данные) для каждого этапа тестирования;
q) образец фиксирования результатов тестовых заданий с пометкой, что требования к продукту или услуге выполнены;
r) порядок пересылки отчетов о проверке тем, кто в них нуждается;
s) риски, связанные с планом.
План проверки может включать следующее:
- уровень целостности программного обеспечения и схему;
- оставшиеся недостатки, лимиты или ограничения в системе;
- влияние тестовой среды;
- рекомендованные улучшения в разработке, эксплуатации или тестировании программного обеспечения.
Примечание - IEEE 829 содержит дополнительные сведения.
10.93 Отчет о проверке
ISO/IEC/IEEE 15288, ссылка: 6.4.6.3 b).
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) Определить название, стиль, формат и график каждого информационного элемента или вида информации, включая положения об обновлении предварительных и промежуточных информационных элементов.
Примечание - Источники информации могут включать записи, организационные данные и другие рабочие продукты, такие как модели и моделирование.
9) Разработать план повторного использования информации: определить, что является общим для информационных элементов из применяемых видов информационных элементов, определить иерархию информационных элементов и выбрать метод или систему для обмена источниками информации и содержанием среди связанных информационных элементов.
10) Определить процедуры управления конфигурацией версий промежуточных и конечных информационных элементов.
11) Определить качественные характеристики каждого элемента информации и вида информации.
12) Определить, как оцениваются качественные характеристики для каждого информационного элемента и вида информационных элементов.
13) Определить критерии и процедуры проверки и одобрения представляемой информации, включая полномочия, обязанности и должность лиц, которые могут утверждать каждый информационный элемент.
14) Определить сроки хранения архивных информационных элементов и варианты носителей для хранения, например, на бумаге или диске.
15) Включить действия и результаты вышеуказанных действий в план документации или управления информацией.
(справочное)
ИНФОРМАЦИОННЫЕ ЭЛЕМЕНТЫ И ЗАПИСИ ПО ИСТОЧНИКАМ
Таблица B.1
ISO/IEC/IEEE 15288 | ISO/IEC/IEEE 12207 | ИСО/МЭК 20000-1 (IEEE 20000-1) ИСО/МЭК 20000-2 (IEEE 20000-2) |
План принятия | ||
Отчет о приемке | ||
План приобретения | ||
План управления активами | ||
Отчет о подтверждении аудита | ||
План аудита | План аудита | |
Процедура аудита | Процедура аудита | |
Аудиторский отчет | Аудиторский отчет | |
План мощности | ||
Процедура управления мощностью | ||
Запрос на внесение изменений | Запрос на внесение изменений | |
Процедура коммуникации | ||
Процедура подачи жалобы | ||
Концепция операций | Концепция операций | |
План и политика управления конфигурацией | План и политика управления конфигурацией | План и политика управления конфигурацией (план и политика управления изменениями) |
Процедура управления конфигурацией (процедура управления изменениями, процедура выпуска и развертывания) | ||
Отчет о статусе конфигурации | Отчет о статусе конфигурации | |
Контракт | Контракт | Контракт (или соглашение) |
Анализ уровня удовлетворенности клиентов | ||
Описание дизайна базы данных | ||
План развития | ||
План утилизации | План утилизации | План утилизации |
План документации | ||
План разработки домена | ||
Отчет об оценке | Отчет об оценке | Отчет об оценке |
Процедура применения | ||
План по улучшению | План по улучшению | План по улучшению (и политика) |
Процедура улучшения | ||
Процедура управления инцидентом (запрос услуги) | ||
Отчет об инциденте | ||
План управления информацией | ||
Процедура управления информацией | ||
План информационной безопасности | ||
Политика информационной безопасности | Политика информационной безопасности | |
Процедура информационной безопасности | ||
План установки | План установки | |
Отчет об установке | Отчет об установке | |
Отчет об интеграции и испытаниях | Отчет об интеграции и испытаниях | |
План интеграции (план осуществления) | План интеграции | |
Описание интерфейса | Описание интерфейса | Описание интерфейса |
Политика и процедура жизненного цикла | Политика и процедура жизненного цикла | |
План технического обслуживания | План технического обслуживания | |
Процедура технического обслуживания | Процедура технического обслуживания | Процедура технического обслуживания |
План измерений | План измерений | |
Отчет по мониторингу и контролю | Отчет по мониторингу и контролю | Отчет по мониторингу и контролю |
Процедура оперативного тестирования | ||
Процедура управления проблемами | Процедура управления проблемами | |
Отчет о проблеме | Отчет о проблеме | Отчет о проблеме |
Процедура оценки процесса | ||
Отчет об улучшении процесса | Отчет об улучшении процесса | |
Оценка потребностей в продукции | Оценка потребностей в продукции | |
Отчет о ходе работы | Отчет о ходе работы | |
План управления проектами | План управления проектами | |
Предложение | Предложение | |
Процедура квалификационных испытаний | ||
Отчет по квалификационным испытаниям | ||
План управления качеством | План управления качеством (план обеспечения качества) | |
Политика и процедура управления качеством | Политика и процедура управления качеством | Политика и процедура управления качеством |
План выпуска версий | План выпуска версий | |
Заявка на подряд (RFP) | Заявка на подряд (RFP) | |
Запрос ресурсов | Запрос ресурсов | |
План повторного использования | ||
Протокол анализа проекта | Протокол анализа проекта | |
Запрос на выполнение рискованных действий | Запрос на выполнение рискованных действий | |
Политика и план управления рисками | Политика и план управления рисками | |
Каталог услуг | ||
План непрерывности и доступности сервиса | ||
Соглашение об уровне обслуживания (SLA) | ||
План управления сервисами | План управления сервисами | |
План обслуживания | ||
Отчет об обслуживании | Отчет об обслуживании | |
Описание архитектуры программного продукта | ||
Описание дизайна программного продукта | ||
Спецификация требований к программному продукту | ||
Описание модуля программного продукта | ||
Процедура тестирования модуля программного продукта | ||
Отчет об испытаниях модуля программного продукта | ||
Процедура управления поставщиками | ||
Процедура выбора поставщика | ||
Описание архитектуры системы | ||
Описание системного элемента | ||
Спецификация требований к обслуживанию | Спецификация требований к обслуживанию | Спецификация требований к обслуживанию |
Учебная документация | Учебная документация | |
План обучения | План обучения | План обучения |
Документация пользователя | Документация пользователя | Документация пользователя |
Уведомление пользователя | ||
План подтверждения | План подтверждения | |
Отчет о подтверждении | Отчет о подтверждении | |
Спецификация теста подтверждения | ||
План проверки | План проверки | План проверки |
Отчет о проверке | Отчет о проверке |
Таблица B.2
ISO/IEC/IEEE 15288 | ISO/IEC/IEEE 12207 | ИСО/МЭК 20000-1 (IEEE 20000-1) ИСО/МЭК 20000-2 (IEEE 20000-2) |
Акт приемки | ||
Отчет об оценке | Запись об оценке | |
Запись о доступности | ||
Запись о жалобах (запись о предложениях) | ||
Запись конфигурации (запись объекта, запись изменений, запись технического обслуживания) | Запись конфигурации (запись объекта, запись изменений) | Запись конфигурации (запись объекта, запись изменений) |
Запись решений | Запись решений | Запись решений |
Запись об утилизации | ||
Запись об инциденте (протокол нарушения информационной безопасности, запрос на обслуживание) | Запись об инциденте (протокол нарушения информационной безопасности, запрос на обслуживание) | |
Запись информационного элемента (хранения) | Запись информационного элемента (хранения) | |
Запись об управлении знаниями | Запись об управлении знаниями | |
Ведомость контроля производительности | ||
Ведомость навыков персонала | Ведомость навыков персонала | |
Учет проблем | Учет проблем | Учет проблем |
Запись контроля процесса | ||
Запись о качестве деятельности | Запись о качестве деятельности | |
Данные о стоимости качества | ||
Протокол выпуска версий | Протокол выпуска версий | |
Запись требования | Запись требования | Запись требования |
Протокол риска (профиль) | Протокол риска (профиль) | Протокол риска (профиль) |
Запись конфигурации элемента программного продукта | ||
Ведомость развития навыков (учебная ведомость) | Ведомость развития навыков (учебная ведомость) | Ведомость развития навыков (учебная ведомость) |
Запись конфигурации элемента программного продукта | ||
Результат теста | Результат теста |
(справочное)
НАЦИОНАЛЬНЫМ СТАНДАРТАМ
Таблица ДА.1
Обозначение ссылочного международного стандарта | Степень соответствия | Обозначение и наименование соответствующего национального стандарта |
ISO/IEC 12207:2008 (IEEE 12207:2008) | IDT | ГОСТ Р ИСО/МЭК 12207-2010 "Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств" |
ISO/IEC/IEEE 15288:2015 | IDT | ГОСТ Р 57193-2016 "Системная и программная инженерия. Процессы жизненного цикла систем" |
ISO/IEC 20000-1:2011 (IEEE 20000-1:2013) | IDT | ГОСТ Р ИСО/МЭК 20000-1-2013 "Информационная технология. Управление услугами. Часть 1. Требования к системе управления услугами" |
Примечание - В настоящей таблице использованы следующие условные обозначения степени соответствия стандартов: - IDT - идентичные стандарты. | ||
[1] | lEEE Std 1016-2008, | IEEE Recommended Practice for Software Design Descriptions |
[2] | lEEE Std 1228-1994, | IEEE Standard for Software Safety Plans |
[3] | lEEE Std 828-2012, | IEEE Standard for Configuration Management in Systems and Software Engineering |
[4] | IEEE Std 829-2008, | IEEE Standard for Software and System Test Documentation |
[5] | ISO/IEC 15504-5, | Information technology - Process assessment - Part 5: An exemplar software life cycle process assessment model |
[6] | ISO/IEC 15504-6, | Information technology - Process assessment - Part 6: An exemplar system life cycle process assessment model |
[7] | ISO/IEC 16085, | Systems and software engineering - Life cycle processes - Risk management |
[8] | ISO/IEC 16175-1, | Information and documentation - Principles and functional requirements for records in electronic office environments - Part 1: Overview and statement of principles |
[9] | ISO/IEC 20000-2, | Information technology - Service management - Part 2: Guidance on the application of service management systems |
[10] | ISO/IEC 20000-3, | Information technology - Service management - Part 3: Guidance on scope definition and applicability of ISO/IEC 20000-1 |
[11] | ISO/IEC 26513, | Systems and software engineering - Requirements for testers and reviewers of user documentation |
[12] | ISO/IEC 26514, | Systems and software engineering - Requirements for designers and developers of user documentation |
[13] | ISO/IEC 27001, | Information technology - Security techniques - Information security management systems - Requirements |
[14] | ISO/IEC 27002, | Information technology - Security techniques - Code of practice for information security controls |
[15] | ISO/IEC 31000, | Risk management - Principles and guidelines |
[16] | ISO/IEC 38500, | Corporate governance of information technology |
[17] | ISO/IEC/IEEE 42010, | Systems and software engineering - Architecture description |
[18] | ISO/IEC 90003, | Software engineering - Guidelines for the application of ISO 9001:2000 to computer software |
[19] | ISO/IEC 9001, | Quality management systems - Requirements |
[20] | ISO/IEC TR 10000-1, | Information technology - Framework and taxonomy of International Standardized Profiles - Part 1: General principles and documentation framework |
[21] | ISO/IEC TR 20000-3, | Information technology - Service management - Part 3: Guidance on scope definition and applicability of ISO/IEC 20000-1 |
[22] | ISO/IEC TR 20000-5, | Information technology - Service management - Part 5: Exemplar implementation plan for ISO/IEC 20000-1 |
[23] | ISO/IEC TR 90005, | Systems engineering - Guidelines for the application of ISO 9001 to system life cycle processes |
[24] | ISO/IEC TR 90006, | Information technology - Guidelines for the application of ISO 9001:2008 to IT service management and its integration with ISO/IEC 20000-1:2011 |
[25] | ISO/IEC/IEEE 16326, | Systems and software engineering - Lifecycle processes - Project management |
[26] | ISO/IEC/IEEE 24765, | Systems and software engineering - Vocabulary <1> |
[27] | ISO/IEC/IEEE 26531, | Systems and software engineering - Content management for product life cycle, user, and service management documentation |
[28] | ISO/IEC/IEEE 29148, | Systems and software engineering - Life cycle processes - Requirements engineering |
--------------------------------
<1> ISO/IEC/IEEE 24765 периодически публикуется как "моментальный снимок" базы данных SEVOCAB (системная и программная инженерия), которая общедоступна на веб-сайте <www.computer.org/sevocab>.
УДК 004:006.354 | ОКС 35.080 |
Ключевые слова: жизненный цикл, процесс жизненного цикла, программный продукт | |
Вернуться в "Каталог нормативных документов"
Источник информации: https://internet-law.ru/documents/prod/gost-r_gosudarstvennyj-standart/27/gost_73838.html
На правах рекламы:
|
© Антон Серго, 1998-2026.
|
Разработка сайта |
|