ГОСТ Р 56713-2015 (ISO/IEC/IEEE 15289:2011). Национальный стандарт Российской Федерации. Системная и программная инженерия. Содержание информационных продуктов процесса жизненного цикла систем и программного обеспечения (документация)

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

Утвержден и введен в действие Приказом Федерального агентства по техническому регулированию и метрологии от 16 ноября 2015 г. № 1820-ст

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

(ISO/IEC/IEEE 15289:2011, IDT)

ГОСТ Р 56713-2015 (ISO/IEC/IEEE 15289:2011)

ОКС 03.220.01

35.240.01

Дата введения 1 августа 2016 года

Предисловие

1 ПОДГОТОВЛЕН Федеральным государственным бюджетным образовательным учреждением высшего профессионального образования «Московский автомобильно-дорожный государственный технический университет» (МАДИ) на основе собственного перевода на русский язык англоязычной версии стандарта, указанного в пункте 4

2 ВНЕСЕН Техническим комитетом по стандартизации № 57 «Интеллектуальные транспортные системы»

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

4 Настоящий стандарт является идентичным по отношению к международному стандарту «ИСО МЭК ИИЭР 15289:2011 Системная и программная инженерия. Содержание информационных продуктов процесса жизненного цикла систем и программного обеспечения (документация)» (ISO/IEC/IEEE 15289:2011 Systems and software engineering — Content of life-cycle information products (documentation), IDT).

Международный стандарт разработан Техническим комитетом по стандартизации JTC 1/SC 7.

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

Некоторые из элементов настоящего стандарта могут быть предметом патентования прав

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

Правила применения настоящего стандарта установлены в ГОСТ Р 1.0-2012 (раздел 8). Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru). Часть содержания настоящего стандарта может быть объектом патентных прав

Введение

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

Настоящий стандарт базируется на процессах жизненного цикла, указанных в ИСО/МЭК 12207:2008 «Информационные технологии. Процессы жизненного цикла программного обеспечения», ИСО/МЭК 15288:2008 «Системотехника, процессы жизненного цикла системы», указанные в ИСО/МЭК 20000-1:2005 «Информационные технологии. Менеджмент услуг. Часть 1. Технические требования» и ИСО/МЭК 20000-2:2005 «Информационные технологии. Менеджмент услуг. Часть 2. Свод установленных правил».

ИИЭР внес в качестве источника для настоящего стандарта ИИЭР 12207.1-1997 «Отраслевое внедрение ИСО/МЭК 12207:1995. Информационные технологии. Процессы жизненного цикла программного обеспечения».

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

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

Для каждого процесса жизненного цикла было бы возможно подготовить план, процедуры и отчеты, а также многочисленные записи, запросы, описания и спецификации. Такая разработка схемы документации была бы более строгой, чем указанная в ИСО/МЭК 15288:2008 или ИСО/МЭК 12207:2008. ИСО/МЭК 15288:2008 (пункт 1.4) указывает, что настоящий стандарт не детализирует процессы жизненного цикла с точки зрения методов или процедур, необходимых для удовлетворения требований и результатов выполнения процесса. Таким образом, информационные позиции могут быть объединены или подразделены по мере необходимости в проектных или организационных целях, как определено в разделах 2, 3.

Не включено в настоящий стандарт следующее:

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

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

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

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

e) информационные позиции, показывающие только утверждение, такое как в ИСО/МЭК 12207:2008 (подпункт 6.1.2.3.4.5);

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

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

2.1 Цель

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

a) для обращения к технической информации, необходимой вовлеченным в ИСО/МЭК 15288:2008 и ИСО/МЭК 12207:2008 процессам;

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

2.2 Предназначен пользователям настоящего стандарта

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

a) руководителями проекта, ответственными за процесс управления информацией ИСО/МЭК 15288:2008 (пункт 5.4.8) в течение системного жизненного цикла;

b) руководителями проекта, ответственными за идентификацию информационных требований единиц и содержание документа при использовании ИСО/МЭК 12207:2008 или любого другого процесса жизненного цикла разработки программного обеспечения, чтобы помочь определить, что должно быть задокументировано и каково должно быть содержание документов;

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

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

e) частными лицами, ответственными за идентификацию информационных позиций, требующих соответствия с ИСО/МЭК 12207:2008, ИСО/МЭК 15288:2008 или ИСО/МЭК 20000-1:2005;

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

2.3 Применимость для трудовой деятельности

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

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

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

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

d) к документации в продуктах Commercial Off The Shelf (COTS), когда продукт COTS указан как результат при двухсторонней ситуации.

Примечание - См. ИСО/МЭК 12207:2008.

2.4 Применимость для целевой группы информационных единиц

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

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

3. Соответствие

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

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

Примечания

1 Поставщики услуг должны ссылаться на ИСО/МЭК 20000-1:2005 и ТО ИСО/МЭК 20000-5:2010 относительно требований соответствия для определенного объема сертификации, например, организационных единиц, услуг, расположений.

Для требования соответствия с настоящим стандартом, адаптировав выбранную систему или процессы жизненного цикла программного обеспечения, пользователи настоящего стандарта должны подготовить информационные позиции, идентифицированные в настоящем стандарте, применимом к выбранному и адаптированному процессу ИСО/МЭК 15288:2008, ИСО/МЭК 12207:2008 или ИСО/МЭК 20000-1:2005.

Универсальная и определенная запись и информационное содержание единицы в разделах 7, 9 и 10 настоящего стандарта могут быть адаптированы для удовлетворения требований организации, ее проектов или соглашений на основе адаптированного соответствия с ИСО/МЭК 15288:2008 (Станд. ИИЭР 15288-2008) или ИСО/МЭК 12207:2008 (Станд. ИИЭР 12207-2008). В адаптации могут быть изменены информационные названия позиции и содержание, предоставленное в настоящем стандарте (добавление, объединение или повторное упоминание). Содержание информационных единиц должно соответствовать выбранным и адаптированным процессам.

2 Приложение A ИСО/МЭК 15288:2008 и ИСО/МЭК 12207:2008 обеспечивают требования для процесса адаптации.

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

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

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

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

3.2 Ситуации соответствия

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

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

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

Примечания

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

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

3.3 Тип соответствия

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

a) адаптированный: минимальный набор требуемых информационных позиций определяется путем адаптации процессов и операций в соответствии с ИСО/МЭК 12207:2008 (приложение A) или ИСО/МЭК 15288:2008 (приложение A).

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

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

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

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

ИСО/МЭК 12207:2008 «Станд. ИИЭР 12207-2008, Информационные технологии. Процессы жизненного цикла программного обеспечения» [ISO/IEC 12207:2008 (IEEE Std 12207-2008), Systems and software engineering — Software life cycle Processes]

ИСО/МЭК 15288:2008 «Системотехника. Процессы жизненного цикла системы» [ISO/IEC 15288:2008 (IEEE Std 15288-2008), Systems and software engineering — System life cycle Processes]

ИСО/МЭК 20000-1:2005 «Информационные технологии. Менеджмент услуг. Часть 1. Технические требования» (ISO/IEC 20000-1:2005, Information technology — Service management — Part 1: Specification)

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

В настоящем стандарте применены термины по ИСО/МЭК 12207:2008, ИСО/МЭК/ИИЭР 24765:2010, а также следующие термины с соответствующими определениями:

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

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

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

5.3 непротиворечивая: Без внутренних конфликтов.

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

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

5.6

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

5.8 описание: Информационная единица, которая представляет запланированное или фактическое понятие, функцию, дизайн или объект.

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

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

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

Примечания

1 Информационный продукт — это синоним.

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

5.12 включать информацию: Наличие информации или ссылка на информацию, предоставленную в настоящем стандарте.

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

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

Примечание - Универсальный тип документа — это синоним.

Пример - План — это информационный тип изделия для всех планов, и отчет — это информационный тип изделия для всех отчетов.

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

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

5.17

5.18 представимый: Воспроизводимый и видимый.

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

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

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

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

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

5.23 позиция программного обеспечения: Идентифицируемая часть программного продукта.

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

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

5.25 отслеживаемость: Наличие компонентов, происхождение которых может быть определено.

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

5.27 поддающиеся проверке: Могут быть проверены на правильность лицом или инструментом.

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

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

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

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

a) однозначность,

b) полнота,

c) проверяемость,

d) непротиворечивость,

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

f) отслеживаемость,

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

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

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

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

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

Данные жизненного цикла следуют из процесса выполнения или сервисных операций и задач стандарта. Многие пункты в ИСО/МЭК 15288:2008 и ИСО/МЭК 12207:2008 требуют, чтобы данные жизненного цикла были произведены или зарегистрированы. Однако пункты ИСО/МЭК 15288:2008 и ИСО/МЭК 12207:2008 не диктуют содержание, расположение, формат или среду, которую следует использовать для записи и поддержки данных. При выборе надлежащих данных, которые будут зарегистрированы, пользователи должны также определить, где в организации или системах ведения записей проекта должны быть зарегистрированы данные. Записи могут сохраняться в базах данных, реестрах, репозиториях, архивах или других системах управления данными. Проекты должны установить политику сохранения записей с учетом системного жизненного цикла и организационного управления или потребностей служб управления данными. Раздел 9 определяет содержание универсальных записей и рекомендует содержание для определенных записей.

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

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

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

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

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

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

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

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

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

e) поддержку всех документов в соответствии с указанными критериями.

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

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

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

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

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

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

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

7. Универсальные типы информационных позиций

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

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

a) описанию;

b) плану;

c) политике;

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

e) отчету;

f) запросу;

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

Примечание - Раздел 9 идентифицирует универсальное содержание записей данных.

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

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

7.2 Описание — универсальное содержание

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

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

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

a) дату выпуска и статус;

b) объем;

c) выпуск организации;

d) ссылки;

e) контекст;

f) примечание для описания;

g) организацию;

h) резюме;

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

j) историю изменения идентифицированных информационных позиций:

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

7.3 План — универсальное содержание

Цель — определить, когда, как и кем определенные процессы или операции должны быть выполнены.

План должен включать:

a) дату выпуска и статус;

b) объем;

c) выпуск организации;

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

e) утверждение полномочий;

f) подход для технического и управленческого обзора и отчетности;

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

h) запланированные операции и задачи;

i) идентификацию инструментов и методов;

j) графики;

k) бюджеты и оценки затрат;

l) ресурсы и их распределение;

m) ответственность и власть, включая старшего ответственного владельца и непосредственного владельца процесса;

n) интерфейсы для участвующих сторон;

o) учет рисков и их определение, оценка и операции смягчения;

p) обеспечение качества и меры контроля;

q) среду, инфраструктуру, безопасность;

r) отчет об обучении;

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

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

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

Идентифицированные информационные позиции:

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

7.4 Политика — универсальное содержание

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

Политика должна включать:

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

b) объем;

c) выпуск организации;

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

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

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

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

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

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

Идентифицированные информационные позиции:

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

7.5 Процедура — универсальное содержание

Ссылка: ИСО/МЭК 15288:2008 (Станд. ИИЭР 15288-2008), пункт 5.3.1

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

a) дату выпуска и статус;

b) объем;

c) выпуск организации;

d) полномочия утверждения;

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

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

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

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

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

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

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

Идентифицированные информационные позиции:

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

7.6 Отчет — универсальное содержание

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

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

a) дату выпуска и статус;

b) объем;

c) организацию выпуска;

d) факторы;

e) резюме;

f) введение;

g) контекст (предположения);

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

i) заключения и рекомендации;

j) ссылки;

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

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

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

Идентифицированные информационные позиции:

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

7.7 Запрос — универсальное содержание

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

Запрос должен включать в себя:

a) дату инициирования;

b) объем;

c) предмет;

d) создателя запроса;

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

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

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

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

Идентифицированные информационные позиции:

• запрос на изменение;
• опрос удовлетворенности клиентов;
• запрос предложений (RFP);
• запрос ресурса;
• запрос действия риска.

7.8 Спецификация — универсальное содержание

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

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

a) дату выпуска и статус;

b) объем;

c) выпуск организации;

d) ссылки;

e) полномочия утверждения;

f) организацию;

g) требования гарантии;

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

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

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

Идентифицированные информационные позиции:

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

8. Отображение информационных позиций к жизненному циклу и процессам управления службами

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

Таблица 1 соотносит ИСО/МЭК 15288:2008 пункты (графа 2), процессы и позиции выходной информации. Таблица 2 соотносит ИСО/МЭК 12207:2008 пункты (графа 2), процессы и позиции выходной информации. Таблица 3 соотносит ИСО/МЭК 20000-1:2005 и ИСО/МЭК 20000-2:2005 пункты (графа 2), процессы и позиции выходной информации. Таблицы 1 - 3 содержат также список рекомендованной входной информации (исходные документы и данные) в колонке 1 для помощи произведения позиций выходной информации.

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

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

Для почти каждого процесса ИСО/МЭК/ИИЭР 15228:2008 и ИСО/МЭК 12207:2008 (Станд. ИИЭР 12207-2008) указывают, что организационные политики и процедуры являются источником для операций, процесса и результатов. В таблицах 1, 2 и 3 «организационные политики и процедуры» не перечисляются, но их нужно рассмотреть как ввод для каждой информационной позиции. В договорной работе договор/соглашение и требования нужно также рассмотреть как ввод для каждой информационной позиции, указывает ли исходный стандарт, что процесс должен быть выполнен, как указано в договоре.

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

8.1 Отображение информационных позиций к системному жизненному циклу

Как определено в ИСО/МЭК/ИИЭР 15288:2008 и показано в заголовках таблицы 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

Отображение ИСО/МЭК 15288:2008 пунктов к информационным позициям для каждого системного процесса жизненного цикла

8.2 Сопоставление информационных позиций с жизненным циклом программного обеспечения

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

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

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

2 Поставка.

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

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

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

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

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

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

Проектные процессы:

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

2 Проектная оценка и управление;

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

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

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

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

7 Измерение.

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

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

2 Анализ системных требований;

3 Системный архитектурный дизайн;

4 Внедрение;

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

6 Системное тестирование квалификации;

7 Установка программного обеспечения;

8 Поддержка принятия программного обеспечения;

9 Работа программного обеспечения;

10 Сопровождение программного обеспечения;

11 Размещение программного обеспечения.

Процессы внедрения программного обеспечения:

1 Внедрение программного обеспечения;

2 Анализ требований к программному обеспечению;

3 Дизайн архитектуры программного обеспечения;

4 Детальное проектирование программного обеспечения;

5 Разработка программного обеспечения;

6 Интеграция программного обеспечения;

7 Тестирование пригодности программного обеспечения.

Процессы поддержки программного обеспечения:

1 Управление документацией программного обеспечения;

2 Управление конфигурированием ПО;

3 Обеспечение качества программного обеспечения;

4 Проверка программного обеспечения;

5 Верификация программного обеспечения;

6 Валидация программного обеспечения;

7 Аудит программного обеспечения;

8 Разрешение проблемы программного обеспечения.

Процессы повторного использования программного обеспечения:

1 Инженерия предметной области;

2 Управление активами повторного использования;

3 Управление программой повторного использования.

Таблица 2

Отображение ИСО/МЭК 12207:2008 пунктов по отношению к информационным позициям для каждого процесса жизненного цикла программного обеспечения

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

Таблица 4 соотносит информацию позиции к 13 процессам управления службами, как определено в ИСО/МЭК 20000-1:2005 и ИСО/МЭК 20000-2:2005. Существуют шесть процессов предоставления услуг, два процесса отношения, два процесса резолюции, два процесса управления и процесс выпуска. В дополнение существует много информационных позиций, требуемых всеми службами процессов управления как часть цикла «план — выполнение — проверка — принятие мер».

Примечания

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

2 Как указано в таблице 3 и ИСО/МЭК 20000-1:2005 (подпункты 3.1 и 3.2), все процессы требуют политик, планов и процедур. В таблице 3 политики, планы и процедуры показаны для определенных услуг, когда дополнительная информация доступна в ИСО/МЭК 20000-1 или ИСО/МЭК 20000-2.

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

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

2 Сервисная отчетность;

3 Сервисная непрерывность и управление доступностью;

4 Составление бюджета и учет IT-услуг;

5 Управление мощностями;

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

Процессы отношения:

1 Управление деловыми отношениями;

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

Процессы резолюции:

1 Управление инцидентами;

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

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

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

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

Процесс выпуска:

1 Управление выпуском.

Таблица 3

Отображение пунктов ИСО/МЭК 20000-1:2005, ИСО/МЭК 20000-2:2005 в информационные позиции для каждого процесса управления службами

9. Записи

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

9.1 Запись — универсальное содержание

Цель — организовать данные, которые сохраняет организационная единица.

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

Запись должна включать в себя:

a) дату записи, дату регистрации и статус;

b) объем;

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

d) организацию выпуска;

e) ссылки;

f) организацию;

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

9.2 Определенное содержание записи

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

Примечания

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

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

Таблица 4

Ссылки на записи и содержание

10. Содержание определенной информационной единицы (документа)

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

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

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

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

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

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

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

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

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

ИСО/МЭК 15288:2008, подпункт 6.3.1.3 b)

ИСО/МЭК 12207:2008, подпункт 6.1.1.3.1.9

Универсальный тип: план

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

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

10.3 Приемочный контроль и проверяющий отчет

ИСО/МЭК 12207:2008, ссылка 6.4.8.3.1.1

Универсальный тип: отчет

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

10.4 План закупок

ИСО/МЭК 12207:2008, подпункты 6.1.1.3.1.8, 6.1.1.3.1.9, 6.1.1.3.1.12

Универсальный тип: план

План закупок включает в себя:

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

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

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

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

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

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

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

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

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

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

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

f) проектный обзор и контрольные этапы;

g) текущие и запланированные операционные стороны.

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

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

ИСО/МЭК 12207:2008, подпункты 7.3.2.2, 7.3.2.3.1.1, 7.3.2.3.1.3, 7.3.2.3.2.2

Универсальный тип: план

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

10.6 Контрольный отчет о подтверждении

ИСО/МЭК 12207:2008, подпункт 7.2.7.3.1.6

Универсальный тип: отчет

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

10.7 План аудита

ИСО/МЭК 12207:2008 (Станд. ИИЭР 12207-2008), подпункты 6.2.1.3.2.2, 7.2.7.3.2.1

ИСО/МЭК 20000-1:2005, подраздел 4.3

ИСО/МЭК 20000-2:2005, подраздел 4.3

Универсальный тип: план

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

10.8 Аудиторская процедура

ИСО/МЭК 12207:2008, подпункт 7.2.7.3.1.4

ИСО/МЭК 20000-1:2005, подразделы 4.3, 9.1, 9.2

Универсальный тип: процедура

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

10.9 Аудиторский отчет

ИСО/МЭК 12207:2008, подпункты 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:200, подраздел 4.3

ИСО/МЭК 20000-2:2005, подраздел 9.1.5

Универсальный тип: отчет

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

10.10 Полный план

ИСО/МЭК 20000-1:2005, подраздел 6.5

ИСО/МЭК 20000-2:2005, подраздел 6.5

Универсальный тип: план

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

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

ИСО/МЭК 20000-1:2005, подраздел 6.5

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

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

ИСО/МЭК 12207:2008, подпункты 6.1.1.3.4.3, 6.1.2.3.3.2, 6.3.9.3.4.3, 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

ИСО/МЭК 20000-1:2005, ссылка 2.11, 4.4.2, 6.5, 7.2, 9.1, 9.2, 10.1

ИСО/МЭК 20000-2:2005, ссылка 5.1.2, 9.1.3, 9.2.1, 9.2.2

Универсальный тип: запрос

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

См. также: отчет о проблеме.

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

10.13 Процедура рассмотрения жалобы

ИСО/МЭК 20000-1:2005, подраздел 7.2

ИСО/МЭК 20000-2:2005, пункт 7.2.2

Универсальный тип: процедура

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

См. также: процедура управления инцидентами, сообщение о происшествии, процедура управления проблемой, отчет о проблеме.

10.14 Понятие операций

ИСО/МЭК 15288:2008, подпункт 6.4.1.2 a), пункт D.4 a

ИСО/МЭК 12207:2008, подпункты 6.1.1.3.1.1, 6.4.1.2, 6.4.1.3.2.3

Универсальный тип: описание

Понятие операций (или операционное понятие) включает:

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

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

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

d) резюме операционных, организационных и влияние развития;

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

Понятие операций может включать:

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

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

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

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

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

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

Примечание - ИИЭР 1362-1998 обеспечивает дополнительное разъяснение.

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

ИСО/МЭК 15288:2008, подпункт 6.3.5.3

ИСО/МЭК 12207:2008, подпункты 6.3.5.3.1.1, 7.2.2.3.1.1

ИСО/МЭК 20000-1:2005, подразделы 9.1, 9.2, 10.1

ИСО/МЭК 20000-2:2005, пункты 9.1.1, 10.1.2, 10.1.4

Универсальный тип: план, политика

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

Примечания

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

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

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

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

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

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

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

План управления выпуска обеспечивает полное направление для планирования выпуска. Определенный план выпуска включает применимые подробные данные для определенного выпуска.

2 ИИЭР 828-2005 стандартов ИИЭР для планов управления конфигурированием ПО обеспечивает дополнительное разъяснение.

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

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

ИСО/МЭК 20000-1:2005, подразделы 9.1, 9.2. 10.1

ИСО/МЭК 20000-2:200, подразделы 9.2.1, 10.1.2, 10.1.7

Универсальный тип: процедура

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

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

a) внедрение процесса;

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

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

d) управление изменениями;

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

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

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

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

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

j) как неуспешное изменение может отменяться или исправляться.

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

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

b) регистрацию и анализ влияния запросов на изменение;

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

d) операции правления управления изменениями;

e) отслеживание происходящих изменений;

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

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

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

ИСО/МЭК 12207:2008, подпункты 7.2.2.2 e), 7.2.2.3.4.1, 7.2.2.3.5.1

ИСО/МЭК 20000-2:2005, подраздел 6.5, подпункты 9.1.1, 9.1.4, 9.2.1

Универсальный тип: отчет

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

10.18 Договор

ИСО/МЭК 15288:2008, подпункты 6.1.1.2, 6.1.1.3, 6.1.2.2, 6.1.2.3, 6.1.3.3

ИСО/МЭК 12207:2008, подпункты 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-2:2005, пункты 7.3.2, 7.3.3, 7.3.4

Универсальный тип: спецификация

Договор является формальным соглашением между аквизитором и поставщиком. Это обращается к следующему:

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

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

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

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

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

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

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

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

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

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

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

10.19 Исследование удовлетворенности клиентов

ИСО/МЭК 12207:2008, подпункт 6.2.5.3.1.4

ИСО/МЭК 20000-2:2005, пункты 7.2.3, 10.1.8

Универсальный тип: запрос

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

10.20 Описание проектирования баз данных

ИСО/МЭК 12207:2008, подпункты 7.1.3.3.1.3, 7.1.4.3.1.3

Универсальный тип: описание

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

a) обзор базы данных и идентификация;

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

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

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

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

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

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

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

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

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

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

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

Детальное проектирование базы данных может указать:

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

b) предприятия данных и их отношения;

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

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

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

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

ИСО/МЭК 12207:2008, подпункты 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.22 План размещения

ИСО/МЭК 15288:2008, подпункт 6.4.11.3

ИСО/МЭК 12207:2008, подпункт 6.4.11.3.1.1

ИСО/МЭК 20000-1:2005, раздел 5

Универсальный тип: план

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

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

ИСО/МЭК 12207:2008, подпункты 6.3.6.3, 7.2.1.2, 7.2.1.3.1.1

Универсальный тип: план

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

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

10.24 План разработки предметной области

ИСО/МЭК 12207:2008, подпункт 7.3.1.3.1.1

Универсальный тип: план

Разработка предметной области планирует то, как организация намеревается провести процедуры разработки предметной области и операции. Это описывает процесс для обработки запросов на изменение.

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

ИСО/МЭК 15288:2008, подпункт 6.2.5.3

ИСО/МЭК 12207:2008, подпункты 6.1.2.3.1.15, 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-2:2005, пункт 9.2.2

Универсальный тип: отчет

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

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

10.26 Процедура внедрения

ИСО/МЭК 15288:2008 подпункт 6.4.4.3 b)

Универсальный тип: процедура

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

См. также операционную процедуру тестирования, учебную документацию.

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

ИСО/МЭК 12207:2008, подпункты 6.2.1.3, 6.3.4.3.1.5

ИСО/МЭК 15288:2008, подпункты 6.2.1.3, 6.3.4.3

ИСО/МЭК 20000-1:2005 подраздел 4.3, пункты 4.4.2, 4.4.3, подразделы 6.1, 8.3, 8.3.9, 9.2, 9.3, 10.1

ИСО/МЭК 20000-2:2005, подраздел 4.3, пункты 4.4.2, 6.1.3, 6.6.7, 7.2.2, 7.2.3, 8.2.2, 8.3.9, 9.1.5, 9.2.2, 10.1.9

Универсальный тип: план

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

Примечание - ИСО/МЭК 15504-4 дает дополнительное разъяснение.

10.28 Политика улучшения

ИСО/МЭК 20000-1:2005, пункт 4.4.1

ИСО/МЭК 20000-2:2005, пункт 4.4.1

Универсальный тип: политика

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

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

ИСО/МЭК 20000-1:2005, подразделы 6.6, 8.2, 8.3

ИСО/МЭК 20000-2:2005, подразделы 6.6.6, 8.2.2, 8.3.7

Универсальный тип: процедура

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

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

10.30 Сообщение о происшествии

ИСО/МЭК 20000-1:2005, ссылка 6.6, 8.2

ИСО/МЭК 20000-2:2005, ссылка 6.6.6, 8.2.1

Универсальный тип: отчет

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

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

Это может включать:

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

b) идентификацию репортера инцидента;

c) дату и время возникновения инцидента, роста, резолюции и закрытия;

d) расположение (среда) инцидента в системе, программном обеспечении или информационном элементе конфигурации;

e) применимое предоставление договора или требование соответствия;

f) причину, природу и влияние (серьезность) инцидента;

g) слова «непосредственное корректирующее действие» рекомендованы;

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

i) ссылки на подобные инциденты, кто сообщил о проблемах и известных ошибках;

j) ответственное лицо или организацию, вместе с надлежащим утверждением показа подтверждения и внедрением решения;

k) информацию о закрытии инцидента;

l) информацию из организационных (внутренних) обзоров.

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

См. также: отчет о проблеме, запрос на изменение.

10.31 План управления информацией

ИСО/МЭК 15288:2008, подпункт 6.3.6.3, D.4 m)

ИСО/МЭК 12207:2008, подпункты 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.32 План информационной безопасности

ИСО/МЭК 20000-1:2005, подраздел 6.6

ИСО/МЭК 20000-2:2005, пункты 6.6.6, 6.6.7

Универсальный тип: план

План информационной безопасности включает следующее:

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

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

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

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

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

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

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

Примечание - ИСО/МЭК 27002:2005 обеспечивает инструкции для управления информационной безопасностью. ИСО/МЭК 27001:2005 обрабатывает для установления, реализации, работы, контроля, рассмотрения, поддержания и улучшения информационной безопасности.

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

ИСО/МЭК 12207:2008, подпункт 6.1.2.3.4.5

ИСО/МЭК 20000-1:2005, подраздел 6.6

ИСО/МЭК 20000-2:2005, пункты 6.6.1, 6.6.5

Универсальный тип: политика

Политика информационной безопасности включает следующее:

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

b) цели для сохранения конфиденциальности, целостности и доступности информации;

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

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

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

10.34 Инсталляционный план

ИСО/МЭК 15288:2008, пункт 6.4.7.3

ИСО/МЭК 12207:2008, подпункт 6.4.7.3.1.1

Универсальный тип: план

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

10.35 Отчет об установке

ИСО/МЭК 15288:2008, подпункт 6.4.7.3

ИСО/МЭК 12207:2008, подпункт 6.4.7.3.1.2

Универсальный тип: отчет

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

10.36 Интеграция и отчет о тесте

ИСО/МЭК 12207:2008, подпункты 6.4.5.3.1.1, 7.1.6.3.1.2

ИСО/МЭК 20000-2:2005, пункт 9.1.2

Универсальный тип: отчет

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

10.37 План интеграции

ИСО/МЭК 15288:2008, подпункты 6.4.4.3, 6.4.5.3

ИСО/МЭК 12207:2008, подпункты 7.1.6.3.1.1, 7.1.6.3.1.2, 7.1.6.3.1.5

Универсальный тип: план

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

См. также: план улучшения.

Примечание - В управлении обслуживанием план внедрения может быть подготовлен к проекту реализации новой услуги или улучшения существующего обслуживания, как описано в TR ИСО/МЭК 20000-5:2010.

10.38 Описание интерфейса

ИСО/МЭК 15288:2008, подпункт 6.4.3.3

ИСО/МЭК 12207:2008, подпункты 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:2005, подразделы 7.3, 9.1

Универсальный тип: описание

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

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

ИСО/МЭК 15288:2008 подпункты 6.2.1.2, 6.2.1.3, 6.2.3.3 b) 1) iii), пункты 2.3, B.2.3

ИСО/МЭК 12207:2008, подпункты 6.2.1.1, 6.2.1.2, 6.2.1.3.1.1, 6.2.1.3.3.1, пункт 2.3.1

Универсальный тип: политика, процедура

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

10.40 План обслуживания

ИСО/МЭК 15288:2008, подпункт 6.4.10.3

ИСО/МЭК 12207:2008, подпункт 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.41 Правила технического обслуживания

ИСО/МЭК 15288:2008, подпункт 6.4.10.3

ИСО/МЭК 12207:2008, подпункт 6.4.10.3.1.1

Универсальный тип: процедура

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

10.42 План измерения

ИСО/МЭК 15288:2008, подпункт 6.3.7.3

ИСО/МЭК 12207:2008, подпункт 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

ИСО/МЭК 20000-2:2005, раздел 4.3

Универсальный тип: план

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

10.43 Контроль и отчет об управлении

ИСО/МЭК 15288:2008, подпункты 6.3.2.3, 6.3.4.3 b), 6.3.7.1, 6.3.7.3 b)

ИСО/МЭК 12207:2008, подпункты 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:2005, подразделы 4 c), 6.1, 9.2

ИСО/МЭК 20000-2:2005, подпункты 6.1.3, 6.3.2, 9.2, 9.2.1, 9.2.4

Универсальный тип: отчет

Отчет о контроле и управлении обеспечивает контролирующие результаты. Это может включать следующее:

a) историю всех контрольных результатов и действий управления и результатов отдельных контрольных аудитов;

b) измерения процессов и услуг против целей и требований;

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

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

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

10.44 Операционная процедура тестирования

ИСО/МЭК 12207:2008, подпункты 6.4.9.3.1.3, 6.4.9.3.2.2

Универсальный тип: процедура

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

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

10.45 Процедура управления проблемой

ИСО/МЭК 12207:2008, подпункты 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:2005, подраздел 6.6, 8.3

ИСО/МЭК 20000-2:2005, подпункты 7.2.2, 7.2.3, 8.3.7

Универсальный тип: процедура

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

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

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

10.46 Отчет о проблеме

ИСО/МЭК 15288:2008, подпункты 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.3 b), 6.4.9.2 c), 6.4.10.2 e), 6.4.10.3 b)

ИСО/МЭК 12207:2008, подпункты: 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:2005, подраздел 8.3

ИСО/МЭК 20000-2:2005, пункт 8.3.6

Универсальный тип: отчет

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

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

Это может включать:

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

b) идентификацию репортера проблемы;

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

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

e) применимое предоставление договора или требование соответствия;

f) причину, природу и влияние (серьезность) проблемы;

g) это решение или корректирующее действие рекомендованы;

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

i) ссылки на подобные проблемы, ранее сообщенные;

j) ответственное лицо или организацию вместе с надлежащим утверждением показа подтверждения и внедрением решения;

k) проблемную информацию о закрытии;

l) информацию из организационных (внутренних) обзоров.

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

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

См. также: запрос на изменение, сообщение о происшествии.

10.47 Обработать процедуру оценки

ИСО/МЭК 12207:2008, подпункт 6.2.1.3.2.1

Универсальный тип: процедура

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

10.48 Отчет об анализе совершенствования процесса

ИСО/МЭК 15288:2008, подпункты 6.2.1.3 c), 6.3.7.3 c)

ИСО/МЭК 12207:2008, подпункты 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.49 Оценка потребности продукта

ИСО/МЭК 15288:2008, подпункт 6.1.2.3

ИСО/МЭК 12207:2008, подпункты 6.1.1.2, 6.1.1.3.1.1

Универсальный тип: отчет

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

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

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

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

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

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

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

d) предварительную информацию о типе договора;

e) текущую и потенциальную ответственность организаций;

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

См. также: понятие операций.

10.50 Отчет о ходе работ

ИСО/МЭК 15288:2008, подпункты 6.1.2.3, 6.2.3.3, 6.3.2.2, 6.3.2.3, 6.3.3.2, 6.3.3.3

ИСО/МЭК 12207:2008, подпункты 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

ИСО/МЭК 20000-1:2005, подразделы 4.2, 4.3, пункты 4.4.2, 4.4.3, раздел 5

Универсальный тип: отчет

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

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

ИСО/МЭК 15288:2008, подпункты 6.1.2.3, 6.2.3.3, 6.3.1.1, 6.3.1.2, 6.3.1.3

ИСО/МЭК 12207:2008, подпункты 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) риски и анализ степени риска для технического, стоимостного и временного рисков;

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

Это может включать следующее:

a) процедуры для перепланирования;

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

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

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

См. также: план управления службами.

Примечания

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

2 ИИЭР 1058-1998 обеспечивает дополнительное разъяснение.

10.52 Предложение

ИСО/МЭК 15288:2008, подпункты 6.1.1.3, 6.1.2.2, 6.1.2.3

ИСО/МЭК 12207:2008, подпункты 6.1.2.2 b), B.3.2.1.2

Универсальный тип: описание

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

10.53 Процедура испытаний качества

ИСО/МЭК 12207:2008, подпункты 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.54 Отчет об испытаниях качества

ИСО/МЭК 12207:2008, подпункты 7.1.7.3.1.1, 7.1.7.3.1.3, 7.2.7.3.2.1

Универсальный тип: отчет

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

10.55 План управления качеством

ИСО/МЭК 15288:2008, подпункты 6.2.5.3, 6.3.1.3

ИСО/МЭК 12207:2008, подпункты 6.1.2.3.4.3, 6.2.5.3.1.5, 6.3.1.3, 7.2.3.3.1.3

Универсальный тип: план

План управления качеством (или план обеспечения качества), в соответствии с ИСО/МЭК 9001:2008 или другим стандартом качества, представляет подход для выполнения качественных аспектов программы, проекта, продукта или услуги. Это включает следующее:

a) проект или заданные уровни качества организации и качественные политики организации;

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

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

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

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

f) управление конфигурацией записей;

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

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

i) требуемую координацию операций обеспечения качества программного обеспечения с другими проектными операциями.

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

ИСО/МЭК 12207:2008, подпункты 6.2.5.2, 6.2.5.3.1.1

ИСО/МЭК 15288:2008, подпункты 6.2.5.2, 6.2.5.3, 6.2.5.3.1.1

ИСО/МЭК 20000-2:2005, пункт 4.4.1

Универсальный тип: политика, процедура

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

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

10.57 План выпуска

ИСО/МЭК 12207:2008, подпункты 6.4.10.3.5.2, 6.4.11.3.2.1

ИСО/МЭК 20000-1:2005, раздел 10.1

ИСО/МЭК 20000-2:2005, пункты 10.1.1, 10.1.3, 10.1.8

Универсальный тип: план

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

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

10.58 Запрос предложений (RFP)

ИСО/МЭК 15288:2008, подпункт 6.1.1.3

ИСО/МЭК 12207:2008, пункты 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.59 Запрос ресурса

ИСО/МЭК 15288:2008, подпункты 6.3.1.3 d), 6.3.2.3 b

ИСО/МЭК 12207:2008, подпункт 6.3.1.3.3.2

Универсальный тип: запрос

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

10.60 План повторного использования

ИСО/МЭК 12207:2008, подпункты 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.61 Протоколы обзора

ИСО/МЭК 12207:2008, подпункты 6.1.2.3.4.15, 6.4.10.3.5.6, 7.2.6.2, 7.2.6.3.1.5

ИСО/МЭК 20000-1:2005, подраздел 7.2

ИСО/МЭК 20000-2:2005, пункт 7.2.1

Универсальный тип: отчет

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

10.62 Запрос действия риска

ИСО/МЭК 15288:2008, подпункт 6.3.4.3

ИСО/МЭК 12207:2008, подпункты 6.3.4.3.2.3, 6.3.4.3.4.1

Универсальный тип: запрос

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

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

ИСО/МЭК 15288:2008, подпункт 6.3.4.3

ИСО/МЭК 12207:2008, подпункты 6.3.4.3.1.1, 6.3.4.3.1.2, 6.3.4.3.2.1

Универсальный тип: план, политика

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

Примечание - ИСО/МЭК 16085:2006 «Системное проектирование и разработка программного обеспечения. Процессы жизненного цикла. Управление рисками» обеспечивает дополнительное разъяснение.

10.64 Сервисная доступность и план непрерывности

ИСО/МЭК 20000-1:2005, подраздел 6.3

ИСО/МЭК 20000-2:2005, подразделы 6.1.2, 6.3.4

Универсальный тип: план

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

a) требования доступности для услуги, как указано в соглашениях об уровне обслуживания;

b) влияние на бизнес сервисной недоступности на различное время и приоритетов для восстановления услуг;

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

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

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

f) процедуры для тестирования плана непрерывности;

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

10.65 Сервисный каталог

ИСО/МЭК 20000-2:2005, пункты 6.1.1, 7.3.3

Универсальный тип: описание

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

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

ИСО/МЭК 20000-1:2005, подразделы 2.13, 3.2, раздел 5, подразделы 6.1, 7.3

ИСО/МЭК 20000-2:2005, пункты 6.1.2, 10.1.1, 10.1.7

Универсальный тип: спецификация

Соглашение об уровне обслуживания (SLA) между поставщиком услуг и клиентом, должно быть разрешено сервисным поставщиком и аквизитором. Это указывает следующее:

a) требования для услуги;

b) объем и лимиты рабочей нагрузки (верхний и ниже);

c) ответственность поставщика и клиента;

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

e) процедуры для инцидента и проблемного управления, роста, уведомлений и жалоб;

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

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

Это может включать цели вне минимального допустимого уровня услуги.

10.67 План управления службами

ИСО/МЭК 12207:2008, пункт 6.4.9.3.1.1

ИСО/МЭК 20000-1:2005, подразделы 3.1, 3.2, 4.1, 4.2, пункты 4.4.1, 4.4.3, раздел 5

ИСО/МЭК 20000-2:2005, подраздел 3.2, пункты 3.3.2, 3.3.3, 4.1.1, 4.1.2, 4.1.3, 4.1.4, 4.4.1, 6.2.1

Универсальный тип: план

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

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

b) планы по ресурсам и преемственность планируют укомплектовать услугу;

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

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

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

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

См. также: план внедрения, план улучшения, план управления рисками.

10.68 Сервисный отчет

ИСО/МЭК 12207:2008, подпункт 6.2.5.3.1.4

ИСО/МЭК 20000-1:2005, подраздел 6.2

ИСО/МЭК 20000-2:2005, подраздел 6.2, пункты 6.2.1, 6.2.2, 6.2.3, 7.3.2

Универсальный тип: отчет

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

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

10.69 Описание архитектуры программного обеспечения

ИСО/МЭК 12207:2008, подпункты 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) одно или более представлений системы. Каждое представление архитектуры является представлением полной системы с точки зрения одной или более проблем для ее заинтересованных сторон.

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

a) обеспечить объяснение для архитектурных решений;

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

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

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

e) обеспечить основание для спецификации требований к программному обеспечению и проектировать обработку.

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

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

b) модель области или справочную архитектуру для семьи или системы программного обеспечения.

См. также: описание системы архитектуры.

Примечание - Описание архитектуры программного обеспечения можно рассмотреть как спецификацию для проектирования программного обеспечения. Для большей информации об описании архитектуры смотри ИСО/МЭК 42010.

10.70 Описание проектирования программного обеспечения

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

Это включает следующее:

a) публикуемость;

d) понятие выполнения, включая поток данных и поток управления;

e) соображения безопасности;

f) элементы повторного использования;

g) обработку ошибок.

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

a) спецификацию протоколов;

b) разделение программного обеспечения в предприятия дизайна и описания важных свойств и отношений среди тех предприятий.

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

Это включает следующее:

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

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

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

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

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

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

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

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

b) ссылка на известные ограничения синхронизации;

c) спецификацию протоколов.

См. также: описание системы элемента.

Примечание - ИИЭР 1016-2008 обеспечивает дополнительное руководство.

10.71 Спецификация требований к программному обеспечению

ИСО/МЭК 12207:2008, подпункты 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) требования для упаковки, установки, операций, обновления продукта и обслуживания.

См. также: спецификация системных требований.

Примечание - ИИЭР 830-1998 ИИЭР обеспечивает дополнительное руководство.

10.72 Описание единицы программного обеспечения

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

10.74 Единица программного обеспечения проверяет отчет

ИСО/МЭК 12207:2008, подпункты 6.4.10.3.3.2, 7.1.5.3.1.2

Универсальный тип: отчет

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

10.75 Процедура управления поставщиками

ИСО/МЭК 20000-1:2005, подраздел 7.2

ИСО/МЭК 20000-2:2005, пункты 7.3.1, 7.3.3, 7.3.4

Универсальный тип: процедура

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

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

10.76 Процедура отбора поставщика

ИСО/МЭК 12207:2008, подпункт 6.1.1.3.3.1

Универсальный тип: процедура

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

10.77 Описание системы архитектуры

ИСО/МЭК 15288:2008, подпункты 6.3.1.3, 6.4.3.1, 6.4.3.2, 6.4.3.3

Универсальный тип: описание

Описание системы архитектуры включает следующее:

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

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

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

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

Описание системы архитектуры должно сделать следующее:

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

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

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

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

10.78 Описание системы элемента

10.79 Спецификация системных требований

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

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

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

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

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

2 ИСО/МЭК/ИИЭР 12207 отсылает к спецификации системных требований, когда программное обеспечение считается системой. ИИЭР 1233-1998 (R2002) обеспечивает дополнительное разъяснение.

10.80 Учебная документация

10.81 Учебный план

ИСО/МЭК 15288:2008, подпункт 6.2.4.3

ИСО/МЭК 20000-2:2005, пункты 3.3.2 c), 3.3.3 f), 5.1.2

Универсальный тип: план

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

10.82 Пользовательская документация

ИСО/МЭК 15288:2008, подпункт 6.4.9.3

ИСО/МЭК 12207:2008, подпункты 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:2005, подпункты 8.3.9, 8.3.10, 10.1.3, 10.1.5, 10.1.7, 10.1.8

Универсальный тип: процедура

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

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

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

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

c) поставляемые и требуемые ресурсы и оперативную обстановку (аппаратные средства/программная платформа);

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

e) поиск и устранение неисправностей и процедуры коррекции ошибок;

f) доступность проблемной отчетности и помощи.

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

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

10.83 Пользовательское уведомление

ИСО/МЭК 12207:2008, подпункты 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.84 План проверки

ИСО/МЭК 15288:2008, подпункт 6.4.8.3

ИСО/МЭК 12207:2008, подпункт 7.2.5.3.1.4

Универсальный тип: план

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

Примечание - ИИЭР 829-2008 обеспечивает дополнительную подробность.

10.85 Отчет о проверке

ИСО/МЭК 15288:2008, подпункт 6.4.8.3

ИСО/МЭК 12207:2008, подпункт 7.2.5.3.1.4 d)

Универсальный тип: отчет

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

10.86 Спецификация теста проверки

ИСО/МЭК 12207:2008, подпункты 7.2.5.3.2.1, 7.2.5.3.2.2, 7.2.7.3.2.1

Универсальный тип: спецификация

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

10.87 План проверки

Универсальный тип: план

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

a) стратегию проверки и как процесс проверки будет проводиться;

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

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

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

e) предварительные испытательные требования и график для интеграции программного обеспечения;

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

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

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

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

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

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

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

m) испытательные приготовления и пробные случаи, которые будут сконфигурированы или построены;

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

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

p) ожидаемые результаты испытаний (выходные данные) для каждого испытательного шага;

q) как результаты испытательного выполнения будут зарегистрированы, чтобы показать, что требования продукта или услуги были удовлетворены;

r) процедура для направления проверки сообщается тем, кто нуждается в них;

s) риски, связанные с планом.

Это может включать следующее:

a) уровень целостности программного обеспечения и схему;

b) оставшиеся недостатки, ограничения или оговорки в системе;

c) влияние условий испытаний;

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

Примечание - ИИЭР 829-2008 стандартов ИИЭР для программного обеспечения и системной испытательной документации обеспечивает дополнительную подробность.

10.88 Отчет о проверке

ИСО/МЭК 15288:2008, подпункт 6.4.6.3 b)

ИСО/МЭК 12207:2008, подпункт 7.2.4.3.1.5

Универсальный тип: отчет

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

См. также: отчет об оценке.

Приложение A (информативное)

ПРОЦЕДУРА ДЛЯ ИДЕНТИФИКАЦИИ ИНФОРМАЦИОННЫХ ПОЗИЦИЙ И ИХ СОДЕРЖАНИЕ

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

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

2 Исследовать пункт 8, таблицы 2 - 4 настоящего стандарта для соответствия информационным позициям с организацией и процессами жизненного цикла проекта и услугами;

3 Исследовать пункт 8 приспособление, таблицы 2 - 4 настоящего национального стандарта для удовлетворения потребностей и требований документации проекта;

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

Примечание - Этот шаг выполнен на основе применимых соглашений и организационных политик;

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

6 Адаптировать и завершить требования к содержанию каждой требуемой информационной позиции;

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

8 Исследовать таблицы 2 - 4 для идентификации вводов позиции источников информации;

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

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

11 Определить показатели качества каждой информационной позиции и информационного типа изделия;

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

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

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

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

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

ИНФОРМАЦИОННЫЕ ПОЗИЦИИ И ЗАПИСИ С РАЗБИВКОЙ ПО ИСТОЧНИКАМ

Таблица B.1

Информационные позиции с разбивкой по источникам

Таблица B.2

Записи с разбивкой по источникам

Библиография