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

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

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

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

Гарантирование систем и программного обеспечения

Часть 4

Гарантии жизненного цикла

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

ОКС 35.080

Дата введения 2017-06-01

Предисловие

Предисловие

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

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

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 16 мая 2016 г. N 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", IDT).
________________
* Доступ к международным и зарубежным документам, упомянутым здесь и далее по тексту, можно получить, перейдя по ссылке на сайт . - .


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

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

6 ПЕРЕИЗДАНИЕ. Ноябрь 2018 г.


Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. N 162-ФЗ "О стандартизации в Российской Федерации". Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 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 Нормативные ссылки

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


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

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


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

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 Соответствующие действия и задачи

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7.7.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 Соответствующие действия и задачи

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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 Соответствующие действия и задачи

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечания

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

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


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

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

Приложение ДА (справочное). Сведения о соответствии ссылочных международных стандартов национальным стандартам Российской Федерации

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

Таблица ДА.1

Библиография

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

Электронный текст документа
и сверен по:
официальное издание
М.: Стандартинформ, 2018