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

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

ИСТОРИЯ ИЗМЕНЕНИЙ НОРМАТИВНО-ТЕХНИЧЕСКИХ АКТОВ

flowchart LR
  n0["ГОСТ Р ИСО/МЭК 15026-1-2016"]:::rst
  click n0 "https://bukva.ai/docs/standart-gost-r-isomek-15026-1-2016" "ГОСТ Р ИСО/МЭК 15026-1-2016. Национальный стандарт Российской Федерации. Системная и программная инженерия. Гарантирование систем и программного обеспечения. Часть 1. Понятия и... "
  n1["ГОСТ Р 71304-2024"]:::doc
  n0 --> n1
classDef rst fill:#FFEBEB,stroke:#8B0000,color:#000;
classDef doc fill:#EBFFEB,stroke:#006400,color:#000;
classDef notEnt fill:#FFFFEB,stroke:#FF8C00,color:#000;

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

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

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

ЧАСТЬ 1

ПОНЯТИЯ И СЛОВАРЬ

Systems and software engineering. Systems and software assurance. Part 1. Concepts and vocabulary

(ISO/IEC 15026-1:2013, IDT)

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

Предисловие

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

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

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

4 Настоящий стандарт идентичен международному стандарту ИСО/МЭК 15026-1:2013 «Системная и программная инженерия. Гарантирование систем и программного обеспечения. Часть 1. Понятия и словарь» (ISO/IEC 15026-1:2013 «Systems and software engineering — Systems and software assurance — Part 1: Concepts and vocabulary», IDT).

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

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

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

Введение

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

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

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

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

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

Первая редакция настоящего стандарта отменяет действие и заменяет пересмотренный документ ИСО/МЭК ТО 15026-1:2010.

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

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

В разработке международных стандартов ИСО/МЭК 15026 вместе с ИСО/МЭК СТК 1 принимало участие компьютерное сообщество ИИЭР. В качестве базовых документов для настоящего стандарта использовались стандарты: ИИЭР Std 1228-1994 и ИИЭР для плана обеспечения безопасности.

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

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

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

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

ИСО/МЭК 15026 не применим для гарантирования службы, которая эксплуатируется и управляется непрерывно.

2. Применимость

2.1. Целевая аудитория

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

2.2. Область применимости

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

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

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

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

3.1. Термины, относящиеся к гарантии и свойствам

3.1.1 гарантия, гарантирование (assurance): Основание для утверждения, что требование выполнено или будет выполнено.

3.1.2 претензия, требование (claim): Утверждение типа «истина/ложь» о выполнении ограничений на значения однозначно определенных свойств (называемых связанными с претензией свойствами), а также ограничений на неопределенность значений свойств в пределах этих ограничений в случае применимости претензии при указанных условиях.

Примечания

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

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

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

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

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

Примечание - В гарантийный случай входят следующие составляющие и их отношения:

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

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

Примечания

1 Термин «надежность» применяется только для общего неколичественного описания.

2 В ИСО/МЭК 25010 [99] отмечено, что «характеристики функциональной надежности включают в себя готовность и свойственные ей или внешние факторы влияния, такие как надежность, отказоустойчивость, восстанавливаемость, целостность, защищенность, сопровождаемость, долговечность и поддержка технического обслуживания». Надежность рассматривается в нескольких стандартах (например, [64] и [69]), а кроме того, многие стандарты посвящены качеству надежности. В МЭК 60050-191 [63] приводятся соответствующие определения.

[МЭК 60300-1:2003]

3.2. Термины, относящиеся к продуктам и процессам

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

[ИСО/МЭК 15288:2008 и ИСО/МЭК 12207:2008]

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

[ИСО/МЭК 15288:2008, D.3]

3.2.3 продукт (product): Результат процесса.

Примечания

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

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

[ИСО/МЭК 15288:2008 и ИСО 9000:2005]

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

Примечания

1 Систему можно рассматривать как продукт или предоставляемые услуги.

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

[ИСО/МЭК 15288:2008]

3.2.5 требование (requirement): Утверждение, которое отражает или выражает потребность и связанные с ней ограничения и условия.

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

[ИСО/МЭК/ИИЭР 29148:2011]

3.2.6 элемент системы (system element): Представитель совокупности компонентов, образующих систему.

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

[ИСО/МЭК 15288:2008]

3.3. Термины, относящиеся к уровню целостности

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

Примечания

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

2 Адаптировано из ИСО/МЭК 15026:1998.

3.3.2 требования уровня целостности (integrity level requirements): Набор определенных требований, предъявляемых к характеристикам системы, продукта или элемента, и связанных с ними аспектов, необходимых для достижения заданного уровня целостности (то есть выполнения условий) при удовлетворении ограничений на неопределенности, включая получение необходимых доказательств.

Примечания

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

2 В ИСО/МЭК 15026:1998 (пункты 3.3.1 и 3.3.2) использованы понятия «уровень целостности» и «требования целостности» соответственно. Для большей ясности и в целях использования той же терминологии, что применяется в области безопасности, последнее понятие было заменено на «требования уровня целостности».

3 ИИЭР 1012:2004 определяет уровень целостности как «значение, представляющее уникальные для проекта характеристики (например, сложность программного обеспечения, критичность, риск, уровень защищенности, уровень безопасности, требуемая производительность, надежность), которые и определяют важность программного обеспечения для пользователя». То есть уровень целостности является значением свойства целевого программного обеспечения. Поскольку и требование, и утверждение того, что свойство имеет определенное значение, могут рассматриваться в качестве характеристики системы или программного обеспечения, то оба определения уровней целостности, в сущности, одинаковы.

3.4. Термины, относящиеся к условиям и последствиям

3.4.1 последствие (consequence): Эффект (изменение или отсутствие изменения), как правило, связанный с событием, состоянием или системой и, как правило, допускаемый, обусловленный, предотвращенный или измененный событием, состоянием или системой либо способствующий им.

Примечание - Следствием эффекта может быть выгода, ущерб либо ни то, ни другое.

3.4.2 негативное последствие (adverse consequence): Нежелательное последствие, связанное с ущербом.

3.4.3 желательное (или положительное) последствие (desirable (or positive) consequence): Последствие, результатом которого является выгода или преимущество либо предотвращение негативного последствия.

3.4.4 дефект (error): Недопустимое состояние системы.

3.4.5 ошибка (fault): Недостаток в системе или ее представлении, при активации (при выполнении) которого система может перейти в недопустимое состояние.

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

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

3.4.7 нарушение (violation): Поведение, действие или событие системы, выходящие за рамки требуемых свойств или требований.

Примечание - В области безопасности термин «нарушение» использован для описания преднамеренного нарушения процедуры или правила человеком.

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

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

3.4.10 риск (risk): Функция вероятности возникновения заданной угрозы и потенциально неблагоприятных последствий возникновения этой угрозы.

Примечания

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

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

3 По вопросам, связанным с безопасностью, следует обратиться к Руководству ИСО/МЭК 51.

[ИСО/МЭК 16085]

3.5. Термины, относящиеся к организациям

3.5.1 организация (organization): Группа работников и необходимых средств с распределением ответственности, полномочий и взаимоотношений.

Примечания

1 Объединения людей, организованные для некоторой определенной цели, такие как клуб, объединение, корпорация или сообщество, являются организацией.

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

[ИСО/МЭК 15288:2008]

3.5.2 ответственный за систему (approval authority): Человек (люди) и/или организация (организации), ответственные за утверждение действий, артефактов и других аспектов системы во время ее жизненного цикла.

Примечания

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

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

3.5.3 ответственный проектировщик (design authority): Человек или организация, которые отвечают за проектирование продукта.

3.5.4 ответственный за обеспечение целостности (integrity assurance authority): Независимый человек или организация, ответственные за сертификацию соответствия требованиям уровня целостности.

Примечание - Адаптировано из ИСО/МЭК 15026:1998, в котором дано следующее определение: «Независимый человек или организация, ответственные за оценку соответствия требованиям целостности».

4. Структура стандарта

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

Библиография размещена в конце стандарта. Ссылки на пронумерованные элементы библиографии везде далее приведены в квадратных скобках.

5. Фундаментальные понятия

5.1. Введение

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

5.2. Гарантия

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

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

Гарантия относится к вопросам: 1) будет ли система или программное обеспечение в том виде, как это задано в спецификации, отвечать реальным нуждам и соответствовать ожиданиям; 2) будет ли соответствовать или соответствует ли система в том виде, как она построена и как эксплуатируется, спецификации; либо к обоим случаям, 1) и 2).

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

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

5.3. Заинтересованные стороны

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

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

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

5.4. Система и продукт

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

5.5. Свойство

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

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

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

Многие из свойств, к которым предъявляются требования, являются показателями качества системы. Списки и определения показателей качества, которые могут быть предметом гарантии, представлены в ряде стандартов и отчетов: ИСО/МЭК 9126-1, ИСО/МЭК 25010 и связанные с ними серии, ИСО/МЭК 2382-14, ИСО 9241, ИСО/ТО 18529 и ИСО/ТС 25238.

Применение термина «свойство» в настоящем стандарте вытекает из повсеместного использования этого термина в ИСО/МЭК 25010 и согласовано с ним. В ИСО/МЭК 25010 этот термин охватывает свойства, которые являются присущими или нет, внутренними или внешними, явными или подразумеваемыми.

Производители и другие заинтересованные стороны могут наделять приоритетом такие свойства, как эффективность и надежность, и искать компромисс между этими свойствами и связанными с ними требованиями. Для решения таких задач было разработано множество методов, описанных в [25], [64], [122], [157] и [40]. Определение требования верхнего уровня к свойству в некоторых случаях является результатом анализа, включая и анализ компромиссных решений.

5.5.1 Свойства как поведение

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

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

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

<1> Если определено формально, то возможен статический анализ соответствия проекта и кода, что потенциально увеличивает надежное обоснование гарантии.

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

5.6. Неопределенность и уверенность

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

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

5.7. Условия и инициирующие события

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

Исторически сложилось так, что одним из условий, считающимся самым важным, является системный отказ. Системному отказу посвящено множество инструкций, практик и публикаций (например, [2], [71] и [14, глава 18, с. 475 — 524]). Несмотря на то что преимущественно эти разработки были сделаны в сообществах, занимающихся безопасностью, защитой или человеческими ошибками, системный отказ может привести к снижению достижения положительного свойства или последствиям, а также может стать причиной отрицательных свойств или убытков.

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

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

5.8. Последствия

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

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

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

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

Злоумышленники могут обладать возможностями, ресурсами, мотивацией и намерениями, которые позволяют им инициировать и приложить вредоносные усилия для нарушения требований. Нарушители используют свои преимущества, чтобы воспользоваться в своих интересах предоставленными системой и/или средой возможностями, называемыми «уязвимостями», то есть «слабыми местами, которые могут быть использованы или инициированы источником угрозы» [150] <1>.

<1> В большинстве случаев смысловая значимость и необходимость отделения уязвимости от других слабых мест могут быть низки либо вообще отсутствовать. Кроме того, вопрос всегда рассматривается в контексте настоящего и будущего, что очень важно для утверждения «...могут быть использованы или инициированы».

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

В нескольких стандартах и отчетах рассматриваются последствия, относящиеся к системам в определенных предметных областях. Такими стандартами являются ИСО 14620 [79], ИСО 19706 [81] и ИСО/ТС 25238 [121]. Кроме того, в стандартах менеджмента рисков также рассматриваются последствия, например в ИСО/МЭК 16085 [91] и ИСО 31000.

6. Применение нескольких частей ИСО/МЭК 15026

6.1. Введение

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

6.2. Начальное руководство по использованию

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

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

6.3. Взаимосвязь частей ИСО/МЭК 15026

ИСО/МЭК 15026 состоит из следующих частей:

• ИСО/МЭК 15026-1 «Понятия и словарь», в которой объясняются понятия и термины, базисные для всех частей этого стандарта;
• ИСО/МЭК 15026-2 «Гарантийный случай», в которой рассмотрены требования к содержанию и структуре гарантийного случая;
• ИСО/МЭК 15026-3 «Уровни целостности системы», которая связывает уровни целостности с гарантийным случаем и включает в себя требования использования уровней целостности с гарантийным случаем и без него (пересмотр ИСО/МЭК 15026:1998);

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

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

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

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

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

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

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

6.4. Ответственные

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

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

7. ИСО/МЭК 15026 и гарантийный случай

7.1. Введение

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

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

Примечание — В случае если требования верхнего уровня относятся к безопасности, защищенности, надежности или RAM (надежность, готовность и сопровождаемость), то гарантийные случаи, связанные с этими требованиями, называют случаями безопасности, случаями защищенности, случаями надежности или случаями RAM соответственно. См. элемент «Библиография»: [139], [142], [143], [146], [154], [155], [168], [74], [22], [23], [24].

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

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

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

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

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

Показатели качества, определенные в ряде стандартов серии ИСО/МЭК 25000, включают в себя также показатели качества, связанные с функциональностью и ограничениями. С обеих точек зрения интерес представляет работа «Общие Критерии v.3.1 Пересмотр 2» [30].

7.2. Обоснование метода доказательства

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

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

В методы доказательств входят:

количественные:

• детерминированные (например, формальные доказательства);
• недетерминированные формальные системы доказательства:

a) вероятностные,

b) теоретико-игровые (например, минимакс),

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

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

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

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

7.3. Средства получения доказательств и управления ими

Для любого свойства существуют много способов получения доказательства. К ним относятся: опыт, история, результаты измерений и непосредственно измерения, тесты, оценка соответствия и ее результаты, исследования, дефекты и выводы. Доказательство должно достигнуть целей, заявленных в аргументации гарантии (см. [139, часть 3, 9.1]).

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

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

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

7.4. Сертификации и аккредитации

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

Авиационная и атомная промышленность имеют длинную историю стандартов и сертификаций, а сообщество безопасности в подкомитете ИСО/МЭК СТК 1/Подкомитет 27 работало над темой гарантии на протяжении многих лет. Базой для сертификации операционных систем системы менеджмента информационной безопасности (ISMS) являются: Общие Критерии, FIPS 140 для криптологии, ИСО/МЭК 27002 «Информационные технологии. Свод правил для менеджмента информационной безопасности» в сочетании с ИСО/МЭК 27001 (ранее британский стандарт BS 7799-2:2002). Министерство обороны Великобритании и Управление гражданской авиации также разработали эффективные стандарты, включая рассматривающие гарантийные случаи стандарты для надежности, сопровождаемости и безопасности, например [139], [142], [143], [22] и [23]. В библиографии указаны и другие стандарты.

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

8. ИСО/МЭК 15026 и уровни целостности

8.1. Введение

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

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

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

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

Примечание — Уровни целостности и связанные с ними стандарты, особенно в области безопасности, имеют богатую историю. Уровни целостности в стандартах, связанных с безопасностью, определены в виде многоуровневых наборов, относящихся к различным степеням строгости и/или неопределенности в их достижении более высоких уровней, обеспечивающих более высокую строгость и более низкую неопределенность. В качестве примера можно рассмотреть стандарт безопасности МЭК 61508 «Функциональная безопасность электрических/электронных/программируемых электронных связанных с безопасностью систем» [70]. В других источниках подобные схемы используются в рамках другой терминологии, например «классы соответствия».

8.2. Анализ рисков

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

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

Например, МЭК 61508 [70] и МЭК 31010, редакция 1.0 (2009-11-27) «Менеджмент рисков. Методы менеджмента рисков», описывают подходы к анализу рисков. В МЭК 300-3-9 используется специфичная для безопасности терминология, поэтому термины «опасность» (hazard) и «вред» (harm) должны быть интерпретированы как «опасное условие» (dangerous condition) и «негативное последствие» (adverse consequence) соответственно. Общее представление дается и в МЭК 60300 «Менеджмент надежности» [64].

Другие специализированные стандарты и документы применимы в различных областях: ИСО 13849 [78] - для машинного оборудования, ИСО 14620 [79] - в космических системах, ИСО 19706 [81] - в пожарном деле, ИСО/ТС 25238 [121] - в медицинской информатике, ИСО/МЭК 27005 [110] - в области информационной безопасности, UK CAP 760760 [24] - на воздушном транспорте и в аэропортах. Возможный интерес могут представить более общие стандарты менеджмента рисков ИСО/МЭК 16085 [91] и ИСО 31000.

9. ИСО/МЭК 15026 и жизненный цикл

9.1. Введение

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

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

Все процессы, действия, задачи, методические материалы и рекомендации должны быть представлены в контексте модели жизненного цикла. Состоящий из нескольких частей технический отчет ИСО/МЭК ТО 24748 «Системная и программная инженерия. Менеджмент жизненного цикла» предназначен для того, чтобы упростить для описания процесса совместное использование содержания двух стандартов процесса жизненного цикла. ИСО/МЭК ТО 24748 обеспечивает объединенное и консолидированное руководство по менеджменту жизненного цикла систем и программного обеспечения. Его цель состоит в том, чтобы обеспечить непротиворечивость в концепциях системы и понятиях жизненного цикла, моделях, этапах, процессах, приложениях процесса, итерации и рекурсии процессов во время жизненного цикла, ключевых понятиях представления, адаптации и использовании в различных областях. ИСО/МЭК 24748-1 показывает применение модели жизненного цикла для систем в контексте ИСО/МЭК 15288 и приводит соответствующий пример использования модели жизненного цикла для программного обеспечения в контексте ИСО/МЭК 12207.

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

Пользователям ИСО/МЭК 15026-4 могут потребоваться оценка степени риска и менеджмент рисков, измерения и требования к процессам, разработанные более досконально, чем это предоставлено в ИСО/МЭК 15288 и ИСО/МЭК 12207. Для обеспечения большего числа деталей этих трех процессов совместно со стандартами ИСО/МЭК 15288 и ИСО/МЭК 12207 можно использовать три международных стандарта: ИСО/МЭК 16085 «Менеджмент рисков», ИСО/МЭК 15939 «Измерение» и ИСО/МЭК/ИИЭР 29148 «Инженерия требований». Другими стандартами, в которых представлены полезные требования и методические материалы по специфическим процессам, является ИСО/МЭК/ИИЭР 15289 для документирования результатов выполнения процессов жизненного цикла и ИСО/МЭК/ИИЭР 16326 для процесса управления проектами.

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

9.2. Мероприятия гарантии в жизненном цикле

Чтобы обеспечить основание для уверенности в свойствах системы, необходимо выполнить запланированную и систематическую совокупность гарантийных мероприятий. Такая совокупность действий разработана для обеспечения соответствия процессов и систем требованиям к ним, стандартам, методическим материалам и определенным процедурам [145]. «Процессы» в данном контексте включают в себя все действия, связанные с проектированием, разработкой и техническим обслуживанием системы. Для программного обеспечения понятие «программный продукт» включает в себя само программное обеспечение, связанные с ним данные, его документацию, поддерживающие и отчетные документы, произведенные как часть программного процесса (например, результаты испытаний и аргументы гарантии), а также все то, что необходимо для завершения гарантийного случая. «Требования» включают в себя требования к свойствам, которые должны быть доказаны, в конечном счете на основе требований, направленных на ограничение, уменьшение или управление связанными со свойством затратами и убытками. «Стандарты, методические материалы» могут быть как техническими, определяющими технологию для использования в системе или программном обеспечении, так и нетехническими, определяющими аспекты процесса, которые далее очерчены «процедурами», обеспечивающими возможность удовлетворения требований к системе.

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

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

10. Заключение

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

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