ГОСТ Р ИСО/МЭК 15026-4-2016. Национальный стандарт Российской Федерации. Системная и программная инженерия. Гарантирование систем и программного обеспечения. Часть 4. Гарантии жизненного цикла

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

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

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

ГАРАНТИРОВАНИЕ СИСТЕМ И ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

ЧАСТЬ 4

ГАРАНТИИ ЖИЗНЕННОГО ЦИКЛА

Systems and software engineering. Systems and software assurance. Part 4. Assurance in the life cycle

ISO/IEC 15026-4:2012 Systems and software engineering — Systems and software assurance — Part 4: Assurance in the life cycle (IDT)

ГОСТ Р ИСО/МЭК 15026-4-2016

Предисловие

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

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

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

4 Настоящий стандарт идентичен международному стандарту ИСО/МЭК 15026-4:2012 «Системная и программная инженерия. Гарантирование систем и программного обеспечения. Часть 4. Гарантии жизненного цикла» (ISO/IEC 15026-4:2012 «Systems and software engineering — Systems and software assurance — Part 4: Assurance in the life cycle»).

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

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

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

Введение

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

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

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

Следует обратить внимание на тот факт, что отдельные элементы настоящего стандарта могут являться объектами патентного права. ИСО и МЭК не несут ответственность за установление какого-либо или всех подобных патентных прав.

ИСО/МЭК 15026-4 был подготовлен Подкомитетом 7 «Системная и программная инженерия» совместного технического комитета ИСО/МЭК СТК 1 «Информационные технологии».

ИСО/МЭК 15026 с общим названием «Системная и программная инженерия. Гарантирование систем и программного обеспечения» состоит из следующих частей:

• Часть 1. Понятия и словарь;
• Часть 2. Гарантийный случай;
• Часть 3. Уровни целостности системы;
• Часть 4. Гарантии жизненного цикла.

Части ИСО/МЭК 15026:

a) ИСО/МЭК 15026-1 Системная и программная инженерия. Гарантирование систем и программного обеспечения. Часть 1. Понятия и словарь;

b) ИСО/МЭК 15026-2 Системная и программная инженерия. Гарантирование систем и программного обеспечения. Часть 2. Гарантийный случай;

c) ИСО/МЭК 15026-3 Системная и программная инженерия. Гарантирование систем и программного обеспечения. Часть 3. Уровни целостности системы;

d) ИСО/МЭК 15026-4 Системная и программная инженерия. Гарантирование систем и программного обеспечения. Часть 4. Гарантии жизненного цикла.

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

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

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

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

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

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

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

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

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

a) демонстрацией того, что требуемые результаты представления процесса гарантирования систем (см. 6.1.2) были достигнуты в дополнение к соответствию соглашению, проекту и техническим процессам, описанным в ИСО/МЭК 15288;

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

Требование соответствия относится только к конкретным требованиям для разработанных систем или программного обеспечения.

Соответствие ИСО/МЭК 15026-2 может помочь в достижении результатов, требуемых двумя представлениями процесса, согласно настоящему стандарту.

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

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

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

ИСО/МЭК ТО 15026-1 Системная и программная инженерия. Гарантирование систем и программного обеспечения. Часть 1. Понятия и словарь (ISO/IEC TR 15026-1, Systems and software engineering — Systems and software assurance — Part 1: Concepts and vocabulary)

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

ИСО/МЭК 15288:2008 Системная и программная инженерия. Процессы жизненного цикла систем (ISO/IEC 15288:2008, Systems and software engineering — System life cycle processes)

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

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

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

В настоящем стандарте применены термины и определения, приведенные в ИСО/МЭК ТО 15026-1, ИСО/МЭК 15288:2008 и ИСО/МЭК 12207:2008.

5. Ключевые понятия и использование ИСО/МЭК 15026-4

5.1. Подход жизненного цикла

Предполагается, что пользователь настоящего стандарта применяет определенную модель жизненного цикла и набор процессов жизненного цикла для управления жизненным циклом системы и/или управления жизненным циклом программного обеспечения. В представлениях процессов всех жизненных циклов систем и программного обеспечения в разделе 6 используются указания и рекомендации раздела 7 для выполнения конкретных процессов, действий и задач в целях достижения и демонстрации достижения требований. Поскольку все процессы, описанные в ИСО/МЭК 15288 и ИСО/МЭК 12207, используются в жизненном цикле многократно и рекурсивно, то указания и рекомендации по обеспечению гарантии также применяются многократно и рекурсивно. Таким образом, достижение гарантии может быть проверено во время любой итерации или рекурсии.

Примечание - Для получения дополнительной информации о моделях жизненного цикла, итерации и рекурсии процессов см. ИСО/МЭК ТО 24748-1.

5.2. Гарантийные требования

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

Примечание - В данном разделе используются материалы ИСО/МЭК 15026-2.

Достижение гарантийных требований обычно включает в себя все аспекты, связанные с выполнением строгих требований. Требование определено в ИСО/МЭК 29148 как «утверждение, которое транслирует или выражает потребность и связанные с ней ограничения и условия», а в ИСО/МЭК 15026-1:2013 требование гарантии определено как «утверждение чего-либо, соответствующего истине, включая соответствующие условия и ограничения». В настоящем стандарте предполагается, что требования являются утверждениями значений для переменных, а требования гарантии — утверждениями, что требования являются истиной.

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

a) «Гарантийные требования», т.е. требования верхнего уровня, в которые входят:

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

2. ограничения на допустимую неопределенность относительно этого достижения;

3. допустимые условия и/или продолжительность применимости;

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

b) «Обоснование для гарантийных требований», т.е. обоснование для выбора и указания этих определенных гарантийных требований.

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

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

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

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

5.3. Использование ИСО/МЭК 15026-4

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

5.3.1 Использование в соглашении

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

Примечание - Соглашение может иметь различную форму от официального договора до устной договоренности.

5.3.2 Использование для нормирования

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

5.3.3 Использование для разработки

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

6. Цели представления процесса и требуемые результаты

6.1. Представление процесса гарантирования систем

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

6.1.1 Цель

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

6.1.2 Требуемые результаты

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

a) определено подмножество требований для достижения критических свойств;

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

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

d) степень достижения гарантийных требований передана заинтересованным сторонам.

6.2. Представление процесса гарантирования программного обеспечения

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

6.2.1 Цель

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

6.2.2 Требуемые результаты

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

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

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

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

d) степень достижения гарантийных требований передана заинтересованным сторонам.

7. Указания и рекомендации по гарантированию для отдельных процессов

7.1. Введение

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

7.2. Процесс приобретения

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

7.2.1 Соответствующие действия и задачи

Действия по стандарту 15288

Действия по стандарту 12207

6.1.1.3 c) Инициируйте соглашение. 1) Согласуйте соглашение с поставщиком. d) Контролируйте соглашение. 1) Оцените выполнение соглашения. 2) Своевременно предоставляйте данные, необходимые поставщику, и разрешайте проблемы

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

7.2.2 Указания и рекомендации по гарантии

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

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

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

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

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

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

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

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

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

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

Примечание - Подробности процесса менеджмента изменений в контракте можно найти в разделе F.3 (приложение F) ИСО/МЭК 12207.

7.3. Процесс поставки

7.3.1 Соответствующие действия и задачи

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

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

6.1.2.3 c) Инициируют соглашение. 1) Согласуйте соглашение с приобретателем. d) Выполните соглашение. 1) Выполняйте соглашение согласно утвержденным планам поставщика проекта и строго следуя этому соглашению. 2) Оцените выполнение соглашения

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

7.3.2 Указания и рекомендации по гарантии

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

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

b) В случае, если точная оценка стоимости затруднена, нужно рассмотреть возможность поэтапного соглашения.

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

7.4. Процесс планирования проекта

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

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

7.4.1 Соответствующие действия и задачи

Действия по стандарту 15288

Действия по стандарту 12207

6.3.1.3 a) Определите проект. 1) Определите проектные цели и ограничения. 3) Определите и поддержите модель жизненного цикла, разбитого на этапы, используя конкретные модели жизненного цикла организации. b) Спланируйте ресурсы проекта. 1) Определите и поддерживайте график проектных работ на основе целей проекта и оценок работы. 2) Определите критерии достижения проекта схем принятия решения этапа жизненного цикла, даты поставки и главные зависимости от внешних вводов или выводов. 3) Определите расходы на проект и спланируйте бюджет. 4) Установите структуру полномочий и ответственности за выполнение работ в рамках проекта. 5) Определите инфраструктуру и службы, необходимые для реализации проекта. 6) Планируйте приобретение материалов, покупных изделий и услуг обеспечивающих систем для выполнения проекта. c) Запланируйте технический менеджмент и менеджмент качества проекта. 1) Сформируйте и доведите план до заинтересованных сторон для технического управления проектом, включая соответствующие ревизии

6.3.1.3.1 Инициация проекта. 6.3.1.3.1.1 Менеджер должен установить требования инициируемого проекта. 6.3.1.3.2 Планирование проекта. 6.3.1.3.2.1 Менеджер должен подготовить планы для выполнения проекта. Планы, связанные с выполнением проекта, должны включать описания связанных действий и задач и идентификацию программных продуктов, которые будут поставляться. Эти планы должны включать по крайней мере следующее: a) графики работ для своевременного завершения задач; b) оценку усилий; c) ресурсы, необходимые для выполнения задач; d) распределение задач; e) распределение обязанностей; f) количественное определение рисков, связанных с задачами или самим процессом; g) мероприятия по гарантии качества для применения в пределах всего проекта; h) затраты, связанные с выполнением процесса; i) обеспечение окружающей среды и инфраструктуры; j) определение и сопровождение модели жизненного цикла, состоящей из стадий, используя определенные модели жизненного цикла для проектов организации

7.4.2 Указания и рекомендации по гарантии

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

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

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

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

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

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

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

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

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

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

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

7.5. Процесс менеджмента решений

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

7.5.1 Соответствующие действия и задачи

Действия по стандарту 15288

Действия по стандарту 12207

6.3.3.3 a) Спланируйте и определите решения. 1) Определите стратегию менеджмента решений. 2) Установите обстоятельства и необходимость принятия решений. 3) Привлекайте заинтересованные стороны к принятию решений для использования их опыта и знаний. b) Проанализируйте информацию о решении. 2) Определите желаемые результаты и измеримые критерии успеха

6.3.3.3.1 Планирование решения. 6.3.3.3.1.1 Проект должен определять стратегию принятия решений. 6.3.3.3.1.2 Проект должен привлекать заинтересованные стороны к принятию решений для использования их опыта и знаний. 6.3.3.3.1.3 Проект должен устанавливать обстоятельства и необходимость принятия решений. 6.3.3.3.2 Анализ решений. 6.3.3.3.2.1 При реализации проекта необходимо выбирать и объявлять стратегию принятия решения для каждой ситуации, в которой необходимо принять решение. Проект должен определять желаемые результаты и измеримые критерии успешного принятия решений

7.5.2 Указания и рекомендации по гарантии

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

7.6. Процесс менеджмента рисков

Примечание - Несмотря на то что первое из приведенных выше предложений взято из ИСО/МЭК 15288, в настоящем стандарте из-за рисков гарантии, свойственных поставке систем, добавлено слово «поставка».

7.6.1 Соответствующие действия и задачи

Действия по стандарту 15288

Действия по стандарту 12207

6.3.4.3 a) Спланируйте менеджмент рисков. 1) Определите политики менеджмента рисков. b) Установите и поддерживайте профиль рисков. 3) Установите и поддерживайте профиль рисков. c) Проанализируйте риски. d) Обработайте риски. 2) Реализуйте те альтернативы обработки риска реализации, для которых решение о приемлемости принимаемых мер принимают заинтересованные стороны. e) Производите мониторинг рисков. 2) Реализуйте и контролируйте показатели для оценки результативности обработок риска

6.3.4.3.1 Планирование менеджмента рисков. 6.3.4.3.1.1 Должны быть определены политики менеджмента рисков, описывающие руководящие указания, регламентирующие выполнение менеджмента рисков. 6.3.4.3.1.2 Описание осуществляемого процесса менеджмента рисков должно быть документировано. 6.3.4.3.1.3 Должны быть определены стороны, ответственные за выполнение менеджмента рисков, их роли и обязанности. 6.3.4.3.1.4 Ответственные стороны должны быть обеспечены ресурсами, достаточными для выполнения процесса менеджмента рисков. 6.3.4.3.2 Менеджмент профиля риска. 6.3.4.3.2.1 Содержание процесса менеджмента рисков должно быть определено и документировано. 6.3.4.3.1.5 Должно быть предоставлено описание процесса оценки и совершенствования процесса менеджмента рисков. 6.3.4.3.2.2 Должны быть документированы пороговые значения риска, определяющие условия, при которых уровень риска может быть принят. 6.3.4.3.2.3 Должен устанавливаться и поддерживаться профиль рисков. 6.3.4.3.2.4 Содержание соответствующего профиля рисков должно периодически доводиться до сведения правообладателей в зависимости от их потребностей. 6.3.4.3.3 Анализ рисков. 6.3.4.3.3.1 Риски должны быть идентифицированы в категориях, описанных в контексте менеджмента рисков. 6.3.4.3.3.2 Должна быть оценена вероятность возникновения и последствий каждого идентифицированного риска. 6.3.4.3.3.3 Каждый риск должен быть оценен по отношению к его пороговым значениям. 6.3.4.3.3.4 Для каждого риска, который находится выше его порогового значения, должны быть определены и документированы рекомендуемые стратегии обработки. Измеримые значения показателей, характеризующих результативность альтернативных вариантов обработки, также должны быть определены и документированы

7.6.2 Указания и рекомендации по гарантии

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

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

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

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

7.7. Процесс менеджмента конфигурации

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

7.7.1 Соответствующие действия и задачи

Действия по стандарту 15288	Действия по стандарту 12207
6.3.5.3 a) Спланируйте менеджмент конфигурации. 1) Определите стратегию менеджмента конфигурации. b) Выполните менеджмент конфигурации. 1) Обеспечьте предоставление информации о конфигурациях с надлежащим уровнем целостности и защищенности	6.3.5.3.1 Планирование менеджмента конфигурации. 6.3.5.3.1.1 В проекте должна быть определена стратегия менеджмента конфигурации. 6.3.5.3.2 Осуществление менеджмента конфигурации. 6.3.6.3.2.1 Проект должен поддерживать информацию о конфигурации на приемлемом уровне целостности и защищенности

7.7.2 Указания и рекомендации по гарантии

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание - Дополнительное разъяснение этих методов менеджмента конфигурации представлено в ИСО/МЭК 27002 «Информационные технологии. Методы и средства обеспечения безопасности. Свод правил по менеджменту информационной безопасности» и в ИСО 10007:2003 «Системы менеджмента качества. Руководящие указания по менеджменту конфигурации».

7.8. Процесс менеджмента информации

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

7.8.1 Соответствующие действия и задачи

Действия по стандарту 15288

Действия по стандарту 12207

6.3.6.3 a) Спланируйте менеджмент информации. 1) Определите элементы информации, которые будут подлежать управлению в течение жизненного цикла системы и, согласно политике организации или законодательству, поддерживаться в течение определенного периода после завершения жизненного цикла. 2) Распределите полномочия и обязанности, относящиеся к зарождению, созданию, накоплению, архивированию и уничтожению элементов информации. 3) Определите права, обязанности и обязательства, касающиеся хранения, передачи и доступа к элементам информации. 4) Определите содержание, семантику, форматы и средства для представления, хранения, передачи и поиска информации. 5) Определите действия по сопровождению информации. b) Обеспечьте менеджмент информации. 3) Обеспечьте поиск и распространение информации среди определенных сторон в соответствии с требованиями согласованных графиков или при определенных обстоятельствах

6.3.6.3.1 Планирование менеджмента информации. 6.3.6.3.1.1 В проекте должны определяться информационные блоки, которые будут подвергаться менеджменту в течение жизненного цикла системы и, согласно политике организации или законодательству, поддерживаться в течение определенного периода после его окончания. 6.3.6.3.1.2 При реализации проекта необходимо распределять полномочия и обязанности, относящиеся к зарождению, созданию, накоплению, архивированию и использованию информационных блоков. 6.3.6.3.1.3 При реализации проекта должны быть определены права, обязанности и обязательства, касающиеся хранения, передачи и доступа к информационным блокам. 6.3.6.3.1.4 При реализации проекта необходимо определить содержание, семантику, форматы и средства для представления, хранения, передачи и поиска информации. 6.3.6.3.1.5 При реализации проекта необходимо определить действия по сопровождению информации. 6.3.6.3.2 Выполнение менеджмента информации. 6.3.6.3.2.3 При реализации проекта необходимо находить и распространять информацию среди определенных сторон в соответствии с требованиями согласованных графиков работ или при определенных обстоятельствах

7.8.2 Указания и рекомендации по гарантии

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

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

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

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

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

b) информацию о достоверности и целостности информационных гарантийных требований;

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

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

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

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

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

7.9. Процесс определения требований заинтересованной стороны

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

7.9.1 Соответствующие действия и задачи

Действия по стандарту 15288

Действия по стандарту 12207

6.4.1.3 c) Анализируйте и поддерживайте требования заинтересованной стороны. 1) Проанализируйте полный набор выявляемых требований. 6) Обеспечьте целостность и прослеживаемость системных требований к требованиям заинтересованной стороны

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

7.9.2 Указания и рекомендации по гарантии

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

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

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

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

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

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

Примечания

1 В ИСО/МЭК 29148:2011 «Разработка требований» приведены все типы требований и операционных понятий.

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

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

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

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

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

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

Примечания

1 Итеративная природа этих действий и задач более подробно рассмотрена в разделе 5 ИСО/МЭК 29148:2011 «Разработка требований».

2 Процесс внесения изменений в соглашение описан в разделе F.3 (приложение F) «Процесс менеджмента изменений в контракте» ИСО/МЭК 12207:2008.

7.10. Процесс анализа требований

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

Примечание - В ИСО/МЭК 16026-1 гарантийное требование определено как «утверждение чего-то, что является истиной, включая связанные условия и ограничения». В данном случае «что-то» — это «значения переменных для свойства».

7.10.1 Соответствующие действия и задачи

Действия по стандарту 15288	Действия по стандарту 12207
Анализ требований	Анализ требований к системе	Анализ требований к программному обеспечению
6.4.2.3 a) Определите системные требования. 1) Определите функциональные границы системы в терминах ее поведения и свойств, которые должны быть обеспечены. 2) Определите каждую функцию, которую система должна выполнять. 3) Определите необходимые ограничения по изготовлению системы и ее элементов, которые обусловлены требованиями правообладателей или неизбежными ограничениями, связанными с принятием решений. 4) Определите технические показатели и показатели качества при использовании, позволяющие оценивать технические достижения. 5) Установите системные требования и функции, в соответствии с которыми определяются риски и критические параметры системы, связанные с такими свойствами, как здоровье, безопасность, защищенность, безотказность, готовность, а также со свойствами обеспечивающих систем	6.4.2.3.1 Спецификация требований. 6.4.2.3.1.1 Должны быть проанализированы особенности планируемого применения разрабатываемой системы для задания системных требований. Спецификация системных требований должна описывать: функции и возможности системы; требования деловой сферы, организационные и пользовательские требования; требования по безопасности, защищенности, эргономике, интерфейсам, рабочим операциям и сопровождению; проектные ограничения и квалификационные требования. Спецификация системных требований должна быть документирована	7.1.2.3.1 Анализ требований к программному обеспечению. 7.1.2.3.1.1 Исполнитель должен установить и документально оформить требования к программным средствам (включая спецификации характеристик качества), описанные ниже. a) спецификации функциональных характеристик и возможностей, включая эксплуатационные, физические характеристики и условия окружающей среды, при которых будет применяться программная составная часть; b) внешние интерфейсы к программной составной части; c) квалификационные требования; d) спецификации по безопасности, включая спецификации, относящиеся к методам функционирования и сопровождения, влиянию окружающей среды и ущербу для персонала; e) спецификации по защите, включая спецификации, связанные с угрозами для чувствительной информации; f) спецификации эргономических факторов, включая спецификации, связанные с ручными операциями, взаимодействием человек-оборудование, ограничениями по персоналу и областям, требующим концентрации внимания и чувствительным к ошибкам человека и уровню его обученности; g) описание данных и требования к базам данных; h) инсталляция и требования к приемке поставляемого программного продукта в местах функционирования и сопровождения; i) требования к документации пользователя; j) операции пользователя и требования к их выполнению; k) пользовательские требования к сопровождению

7.10.2 Указания и рекомендации по гарантии

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

Пример - Если в качестве критического свойства выбрана функциональная защищенность, то частью требований к системе, которые должны быть определены в этом представлении процесса, будут «требования к защищенности жизненного цикла», как описано в МЭК 61508-1.

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

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

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

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

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

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

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

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

7.11. Процесс верификации

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

7.11.1 Соответствующие действия и задачи

Действия по стандарту 15288	Действия по стандарту 12207
Верификация	Верификация программного обеспечения
6.4.6.3 a) Спланируйте верификацию. 1) Определите стратегию верификации систем в течение жизненного цикла. 2) Определите план верификации, основываясь на системных требованиях. 3) Идентифицировать и сообщать о потенциальных ограничениях на проектные решения. Примечание — К ограничениям относятся практические ограничения по точности, уровню неопределенности, воспроизводимости, которые налагаются в результате верификации обеспечивающих систем, связанных методов измерения, необходимости в системной интеграции, а также готовности, доступности и взаимосвязи с обеспечивающими системами	7.2.4.3.1 Реализация процесса. 7.2.4.3.1.1 Должны быть определены условия реализации процесса, если проектом предусматриваются работы по верификации и необходима определенная степень организационной независимости этих работ. Требования проекта должны быть проанализированы на критичность. Критичность может быть оценена в терминах: а) потенциального наличия необнаруженной ошибки в требованиях к системе или программам; и) степени отработки технологии программных средств и рисков, связанных с ее применением. 7.2.4.3.1.5 Должен быть разработан и документально оформлен план проведения верификации на основе установленных задач верификации. План должен содержать действия в течение жизненного цикла и предмет верификации программных продуктов, необходимые задачи по верификации для каждого действия в течение жизненного цикла и программного продукта, связанные с ними ресурсы, ответственность и графики проведения работ. План должен предусматривать процедуры направления отчетов о верификации приобретающей стороне и другим заинтересованным организациям

7.11.2 Указания и рекомендации по гарантии

7.12. Процесс функционирования

7.12.1 Соответствующие действия и задачи

Действия по стандарту 15288	Действия по стандарту 12207
Функционирование	Функционирование программного обеспечения
6.4.9.3 a) Подготовьтесь к работе. 1) Подготовьте стратегию работы	6.4.9.3.1 Подготовка к функционированию. Данный вид деятельности состоит из решения следующих задач: 6.4.9.3.1.1 Оператор должен разрабатывать план и определять эксплуатационные стандарты для выполнения действий и задач этого процесса. План должен быть задокументирован и выполнен

7.12.2 Указания и рекомендации по гарантии

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

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

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

7.13. Процесс сопровождения

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

7.13.1 Соответствующие действия и задачи

Действия по стандарту 15288	Действия по стандарту 12207
Обслуживание	Сопровождение программного обеспечения
a) Спланируйте сопровождение. 1) Подготовьте стратегию обслуживания	6.4.10.3.1 Реализация процесса. 6.4.10.3.1.1 Сопровождающая сторона должна разрабатывать, документировать и выполнять планы и процедуры для проведения действий и решения задач в рамках процесса сопровождения программных средств

7.13.2 Указания и рекомендации по гарантии

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

Примечания

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

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

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

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

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

СВЕДЕНИЯ О СООТВЕТСТВИИ ССЫЛОЧНЫХ МЕЖДУНАРОДНЫХ СТАНДАРТОВ НАЦИОНАЛЬНЫМ СТАНДАРТАМ РОССИЙСКОЙ ФЕДЕРАЦИИ

Таблица ДА.1

Обозначение ссылочного международного стандарта	Степень соответствия	Обозначение и наименование соответствующего национального стандарта
ISO/IEC TR 15026-1	-	<*>
ISO/IEC 15288:2008	-	<*>
ISO/IEC 12207:2008	IDT	ГОСТ Р ИСО/МЭК 12207-2010 «Системная и программная инженерия. Процессы жизненного цикла программного обеспечения»
<*> Соответствующий национальный стандарт отсутствует. До его утверждения рекомендуется использовать перевод на русский язык данного международного стандарта. Примечание — В настоящей таблице использовано следующее условное обозначение степени соответствия стандарта: - IDT — идентичный стандарт.

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

В качестве дополнительного руководства в области гарантии качества пользователи этой части ИСО/МЭК 15026 могут ознакомиться с обширной библиографией в ИСО/МЭКТО 15026-1. Приводимая здесь библиография фокусируется на стандартах процесса.

[1]	ISO/IEC 90003:2004, Software engineering — Guidelines for the application of ISO 9001:2000 to computer software
[2]	ISO/IEC 15026-2:2011, System and software engineering — System and software assurance — Part 2: Assurance case
[3]	Software and Systems Engineering Vocabulary (sevocab). Available at: www.computer.org/sevocab/
[4]	ISO/IEC 15289:2011, System and software engineering — Content of life cycle information products (documentation)
[5]	ISO/IEC 15504-1:2004, Information Technology — Process Assessment — Part 1: Concepts and vocabulary
[6]	ISO/IEC 15504-2:2003, Information Technology — Process Assessment — Part 2: Performing an Assessment
[7]	ISO/IEC 15504-3:2004, Information Technology — Process Assessment — Part 3: Guidance on performing a process improvement and process capability determination
[8]	ISO/IEC 15504-5:2012, Information Technology — Process Assessment — Part 5: An exemplar software process assessment model
[9]	ISO/IEC TR 15504-6:2008, Information Technology — Process Assessment — Part 6: An exemplar system life cycle process assessment model
[10]	ISO/IEC 15504-7:2008, Information Technology — Process Assessment — Part 7: Assessment of organizational maturity
[11]	ISO/IEC 15939:2007, Systems and software engineering — Measurement process
[12]	ISO/IEC 16085:2006, Systems and software engineering — Life cycle processes — Risk management
[13]	ISO/IEC 16326:2009, System and Software engineering — Life cycle Processes — Project management
[14]	ISO/IEC 21827:2008, Information technology — Systems Security Engineering — Capability Maturity Model (SSE - CMM^{®})
[15]	ISO/IEC TR 24748-1:2010, Systems and software engineering — Life cycle management — Part 1: Guide for life cycle management
[16]	ISO/IEC TR 24748-2:2011, Systems and software engineering — Life cycle management — Part 2: Guide for the application of ISO/IEC 15288 (System life cycle processes)
[17]	ISO/IEC TR 24748-3:2011, Systems and software engineering — Life cycle management — Part 3: Guide for the application of ISO/IEC 12207 (Software life cycle processes)
[18]	ISO/IEC 25000:2005, Software engineering — Software product Quality Requirements and Evaluation (SQuaRE) — Guide to SQuaRE
[19]	ISO/IEC 25010:2011, Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality models
[20]	ISO/IEC 25012:2008, Software Engineering — Software product Quality Requirements and Evaluation (SQuaRE) — Data Quality Model
[21]	ISO/IEC 25020:2007, Software engineering — Software product Quality Requirements and Evaluation (SQuaRE) — Measurement reference model and guide
[22]	ISO/IEC 25030:2007, Software engineering — Software product Quality Requirements and Evaluation (SQuaRE) — Quality requirements
[23]	ISO/IEC 25040:2011, Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — Evaluation process
[24]	ISO/IEC 25051:200, Software engineering — Software product Quality Requirements and Evaluation (SQuaRE) — Requirements for quality of Commercial Off-The-Shelf (COTS) software product and instructions for testing
[25]	ISO/IEC 27001:2005, Information technology — Security techniques — Information security management systems — Requirements
[26]	ISO/IEC 27002:2005, Information technology — Security techniques — Code of practice for information security management
[27]	ISO/IEC 29148:2011, Systems and software engineering — Requirements engineering

---