Что такое assurance case
Что такое assurance case
ГОСТ Р ИСО/МЭК 15026-1-2016
НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
СИСТЕМНАЯ И ПРОГРАММНАЯ ИНЖЕНЕРИЯ
Гарантирование систем и программного обеспечения
Systems and software engineering. Systems and software assurance. Part 1. Concepts and vocabulary
Дата введения 2017-06-01
Предисловие
1 ПОДГОТОВЛЕН Обществом с ограниченной ответственностью «Информационно-аналитический вычислительный центр» (ООО ИАВЦ) на основе собственного перевода на русский язык англоязычной версии международного стандарта, указанного в пункте 4
2 ВНЕСЕН Техническим комитетом по стандартизации ТК 22 «Информационные технологии»
При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты, сведения о которых приведены в дополнительном приложении ДА
6 ПЕРЕИЗДАНИЕ. Январь 2019 г.
Введение
Международная организация по стандартизации (ИСО) и Международная электротехническая комиссия (МЭК) образуют специализированную систему для всемирной стандартизации. Национальные органы по стандартизации, которые являются членами ИСО или МЭК, участвуют в разработке международных стандартов через технические комитеты, созданные соответствующей организацией для определенных областей технической деятельности. Технические комитеты ИСО и МЭК сотрудничают в сферах, представляющих взаимный интерес. Другие международные правительственные и неправительственные организации, связанные с ИСО и МЭК, также принимают участие в работе по разработке стандартов. В сфере информационной технологии ИСО и МЭК учредили совместный технический комитет ИСО/МЭК СТК 1.
Международные стандарты разрабатываются в соответствии с правилами, приведенными в Директивах ИСО/МЭК, Часть 2.
Основная задача совместного технического комитета состоит в подготовке международных стандартов. Проекты международных стандартов, принятые совместным техническим комитетом, распространяются среди национальных органов по стандартизации для вынесения решения. Для публикации в качестве международного стандарта требуется одобрение по крайней мере 75% национальных органов по стандартизации, участвующих в голосовании.
Следует обратить внимание на тот факт, что отдельные элементы настоящего стандарта могут являться объектами патентного права. ИСО и МЭК не несут ответственность за установление какого-либо или всех подобных патентных прав.
ИСО/МЭК 15026-1 был подготовлен Подкомитетом 7 «Системная и программная инженерия» совместного технического комитета ИСО/МЭК СТК 1 «Информационные технологии».
Первая редакция настоящего стандарта отменяет действие и заменяет пересмотренный документ ISO/IEC TR 15026-1:2010.
ИСО/МЭК 15026 с общим названием «Системная и программная инженерия. Гарантирование систем и программного обеспечения» состоит из следующих частей:
— Часть 1. Понятия и словарь;
— Часть 2. Гарантийный случай;
— Часть 3. Уровни целостности системы;
— Часть 4. Гарантии жизненного цикла.
В разработке международных стандартов ИСО/МЭК 15026 вместе с ИСО/МЭК СТК 1 принимало участие компьютерное сообщество IEEE. В качестве базовых документов для настоящего стандарта использовались стандарты: IEEE 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, а также следующие термины с соответствующими определениями.
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] приводятся соответствующие определения.
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 На практике интерпретация значения термина часто уточняется посредством ассоциативного существительного, например «система самолета». Кроме того, слово «система» может быть заменено просто контекстно-зависимым синонимом, например «самолет», хотя подобная замена может скрыть аспекты системных принципов.
Assurance Case: аргументированное обоснование безопасности
Как наиболее полно оценить безопасность, и ничего при этом не упустить? Возможно ли собрать в одном документе (или диаграмме) все разнообразие артефактов, относящихся к безопасности, и организовать их таким образом, чтобы можно было наглядно представить любой аспект с понятным уровнем детализации?
Технические специалисты были бы рады изобретению такого «философского камня», который, если даже не обеспечил бы безопасность, то, по крайней мере, оценил бы ее с требуемым уровнем полноты. Подобные наработки существуют уже более 20 лет, однако, практически не известны русскоязычному читателю. Речь пойдет о методологии Assurance Case (или Safety Case), под которой подразумевается структурированный набор аргументов и документальных подтверждений, обосновывающих соответствие системы или сервиса заданным требованиям.
Введение
Перед прочтением статьи хотел бы обратить ваше внимание на пару важных моментов. Изложенный материал применим, в первую очередь, для объектов критической информационной инфраструктуры (КИИ). Для таких объектов, в частности, для информационных и управляющих систем, должен быть выполнен анализ безопасности. Результаты анализа безопасности представляются в виде соответствующих отчетов. Все это выполняется уже десятки лет, однако, отчеты, как правило, имеют произвольную текстовую форму, в логике которой не всегда просто разобраться.
Основная идея излагаемого подхода состоит в том, что результаты анализа безопасности могут быть представлены в графическом виде с использованием полуформальных нотаций, со всеми вытекающими отсюда преимуществами. Таким образом, Assurance Case является способом интегрального представления всех мер по обеспечению и оцениванию безопасности, не заменяя и не отменяя такие частные методы, как, например, тестирование, статический анализ кода, расчет надежности, FMEA, анализ рисков и т.п. Данная статья продолжает ранее опубликованную серию статей по безопасности.
Карты аргументов и их философские истоки
Как мы можем понять или утверждать, что некоторый объект является безопасным? Очевидно, для этого надо ввести ряд критериев. Однако, для этих критериев нам необходимо определить, насколько наше знание об объекте является достоверным? Почему мы можем этому знанию доверять? Что делает наши доводы и рассуждения действительно заслуживающими доверия? Углубившись в подобные проблемы, нельзя обойтись без философских дисциплин, таких как, онтология, гносеология, эпистемология, логика, а также, без великих мыслителей, которых волновали эти вопросы. В античном мире таковыми являлись Аристотель и Платон, а в эпоху «нового времени» основоположником современного научного метода считается Френсис Бэкон.
Что же можно сделать для обоснования или оценки безопасности разумным и логичным путем? В основе такого подхода лежит теория аргументации. Новый импульс современному развитию аргументации был дан в работе британского философа Стивена Тулмина под названием «The Uses of Argument», изданной в 1958 году. Тулмин расширил логический импликативный вывод дополнительными параметрами и предложил представлять эту операцию в графической форме. Нотация Тулмина оперирует следующими сущностями: data (D) – исходные данные для анализа, claim (С) – цель логического импликационного вывода (If D So C), warrant (W) – дополнительный аргумент, qualifier (Q) – степень уверенности в результатах логического вывода, rebuttable (R ) – дополнительный контраргумент (Рисунок 1).
Рисунок 1. Нотация Стивена Тулмина
Карты аргументов или аргументации (Argument Map) использовались в целях визуализации рассуждений и до Тулмина, но именно он наиболее удачно обобщил структурную модель для анализа и верификации аргументов. Отметим, что в современных картах аргументов, как правило, не используется нотация Тулмина, все упрощено, например, как на рисунке ниже. Это нотация, используемая платным онлайн сервисом Rational (бесплатная версия существует, но она крайне ограничена по функционалу) (Рисунок 2). Платная версия умеет преобразовывать полученные диаграммы в логически структурированный текст. На сайте также доступны бесплатные guides & tutorials по критическому мышлению и составлению карт аргументов.
Рисунок 2. Карта аргументов, разработанная при помощи сервиса Rational
Как видим, все довольно прозрачно, существуют всего четыре сущности и три типа связи между ними. Результат логического ввода называется Contention, подтверждающий аргумент – Reason (связь because), контраргумент – Objection (связь but), а вот контраргумент для контраргумента имеет специальное название – Rebuttal (связь however).
На данный момент не существует общепринятой нотации для составления карт аргументов. Нет единства и в обозначениях, применяемых для структуры аргументов. Например, результат логического вывода может называться claim, contention, conclusion, goal. Аргументы могут называться premise, justification и т.д. В области моделирования аргументов существует ряд международных инициатив и сообществ (например, Argument Interchange Format, AIF), но вопросы унификации они не решили. Существуют исследования, проводящие параллели между картами аргументов и ментальными картами (Mind Map, наверно, все о них слышали). Действительно, возможности Mind Map редакторов позволяют построить аналог карты аргументов.
История и концепция Assurance Case
Какое отношение имеет все это к безопасности? Чтобы ответить на этот вопрос, обратимся ко второй половине ХХ века, именно там берет свое начало современная теория и практика обеспечения безопасности. Тогда, в результате развития сложных техногенных отраслей, таких, как атомная энергетика, космическая техника, нефтегазовая и химическая промышленность, транспорт, человечество столкнулось с техногенными катастрофами невиданных ранее масштабов.
Тогда и появилась первые отчеты по анализу безопасности, в которых сводились воедино вся релевантные требования, а, также, информация, подтверждающая их соблюдение. Позже появился термин Safety Case (по сути, аналитический отчет по безопасности), который являлся предшественником Assurance Case. Отметим, что термины «Safety Case» или «Assurance Case» напрямую перевести термин на русский язык невозможно, в данном контексте, наиболее логичным переводом является «обоснование безопасности». Хотя, например, в российских переводах серии стандартов ИСО/МЭК 15026 (Systems and software engineering – Systems and software assurance) «Assurance Case» переведен, как «гарантийный случай».
Следует отметить, что в некоторых отраслях термин Safety Case применяется и в настоящий момент, наравне с Assurance Case. Assurance Case, будучи более современным термином, противопоставляется Safety Case в том смысле, что на сегодняшний день система должна соответствовать не только требованиям safety (функциональная безопасность), но, также, и security (информационная безопасность). Поэтому, предлагается использовать понятие Assurance Case, а Safety Case считать его частным случаем.
Под Assurance Case, в современном понимании этого термина, подразумевается отчет о выполненном анализе безопасности, включающий визуальное представление в виде графа или таблицы, полученных с применением полуформальных нотаций (о нотациях речь пойдет ниже). При этом, получается некоторое разночтение одного и того же термина, поскольку возможно трактовать Assurance Case, с одной стороны, как некоторый документ (отчет об анализе безопасности или отчет об обосновании безопасности), а, с другой стороны, как систему аргументации с использованием полуформальной нотации. В идеале, Assurance Case, может включать оба компонента, то есть документ, оценивающий безопасность, строится на основании модели аргументов.
Вернемся, однако, в ХХ век. Первым нормативным документом, требующим разрабатывать и анализировать Safety Case для потенциально опасных индустриальных объектов, стал «CIMAH (Control of Industrial Major Accidents Hazards) Regulations», первоначально выпущенный в Великобритании в 1984 году, а затем адаптированный и в ряде других стран. Более широкое внедрение Safety Case в практику стало происходить после небывалой аварии на нефтяной платформе Piper Alpha в Северном море, унесшей в 1988 году жизни 167 человек.
В 1990-х годах исследователи продолжают искать новые подходы к оцениванию безопасности. Идея, вроде бы, лежит на поверхности: давайте разработаем специальную нотацию для обоснования соответствия техногенных объектов и систем требованиям по безопасности. За дело взялись две британские университетские команды, лондонский университет Сити (City, University of London), где была создана спин-офф компания Adelard, и университет Йорка (University of York). Надо сказать, что и в наши дни Adelard и университет Йорка занимают лидирующие позиции в области продвижения Assurance Case.
Для разработки нотаций упор был сделан на логическую аргументацию того, что свойство или компонент системы соответствует заявленным требованиям. В качестве теоретической основы были выбраны уже рассмотренные нами труды Стивена Тулмина. Будучи гуманитарием, Тулмин вряд ли он думал о техногенных системах, однако, в историю, он вошел, в том числе, и как основоположник аргументации для Assurance Case.
Взяв за основу, нотацию Тулмина, британцы вскоре разработали методологию Assurance Case (называемую в то время Safety Case) и довели результаты до практических индустриальных внедрений. В университете Йорка, была разработана Goal Structuring Notation (GSN), эту тему продвигал PhD студент Tim Kelly под руководством профессора John McDermid. В результате произошел тот редкий случай, когда диссертация «Arguing Safety: A Systematic Approach to Managing Safety Cases. PhD thesis. University of York, 1998» уже больше 20 лет считается классическим трудом, и ее продолжают активно цитировать. Однако, подход к решению проблемы безопасности был, на мой взгляд, в большей степени академический, и, как результат, не был почему-то сделан вроде бы понятный и логичный шаг, связанный с разработкой программного средства для поддержки Assurance Case.
Adelard же, под руководством Robin Bloomfield и Peter Bishop, напротив, в первую очередь стремился к коммерциализации результатов. Параллельно с Йорком, в Лондоне была разработала нотация Claim, Argument and Evidence (CAE), а также программный инструмент Adelard ASCE (Assurance and Safety Case Environment), который поддерживает и CAE, и GSN. В Великобритании разработка Assurance Case (Safety Case) требуется законами и стандартами во многих областях, связанных с безопасностью, поэтому ASCE имеет здесь довольно устойчивый рынок. ASCE был и остается наиболее используемым инструментом разработки Assurance Case. Основной частью инструмента является графический редактор, в котором к графическим блокам может быть прикреплена дополнительная текстовая или гиперссылочная информация (Рисунок 3). Самостоятельно загрузить программное обеспечение ASCE с веб-сайта Adelard не получится. Вы должны заполнить запрос на 30-дневную пробную версию или академическую лицензию, после чего запрос будет рассмотрен компанией.
Рисунок 3. Интерфейс программы Adelard ASCE
Теперь рассмотрим две базовые нотации, применяемые для разработки Assurance Case (CAE и GSN).
Нотация CAE (Claim, Argument and Evidence)
Нотация CAE (Claim, Argument and Evidence – цель, аргумент, подтверждение) оперирует тремя указанными сущностями: цели указывают на достижение требуемых свойств системы, подтверждения предоставляют документированный базис для аргументации, демонстрирующей достижение либо не достижение целей, аргументы строятся при помощи правил вывода и связывают подтверждения с целями. Обычно применяются такие аргументы, как детерминистские (или логические), вероятностные и качественные. Для обозначения целей, аргументов и доказательств вводятся графические примитивы, имеющие различную форму (Рисунок 4).
Рисунок 4. Нотация Claim, Argument and Evidence (CAE): основные компоненты
Построение иерархии целей и подцелей является первым этапом разработки Assurance Case. Как показано на схеме, структура целей, аргументов и подтверждений не обязательно является трехуровневой, например, для поддержки аргументации могут использоваться дополнительные подцели. CAE нотация также легко трансформируется в табличный вид. Столбцами такой таблицы будут являться все те же цели, аргументы и подтверждения, между которыми теперь будут установлены связи в пределах табличных записей. Подобный подход к разработке Assurance Case используется, например, компанией exida.
Нотация GSN (Goal Structuring Notation)
GSN оперирует такими компонентами, как цель (goal, обозначается прямоугольником и является аналогом claim в CAE), стратегия аргументации (strategy, обозначается параллелограммом и является аналогом argument) и решение (solution, обозначается кругом и является аналогом evidence) (Рисунок 5). Контекст (context) применяется для информационной поддержки целей. Для поддержки аргументации могут применяться предположение (assumptions) и обоснование (justifications). Структура целей имеет иерархический характер.
Рисунок 5. Нотация Goal Structuring Notation (GSN): основные компоненты
Если сравнивать между собой CAE и GSN, то следует отметить, что CAE уделяет больше внимания обоснованию отдельных аргументов. Для этого выполняется детальное конструирование шагов аргументации. GSN больше фокусируется на типовых структурах (паттернах) аргументов. За счет большего числа сущностей, GSN является менее строгой, и, в то же время, при более лаконичном описании она может быть сведена к CAE. Применение каждой из нотаций может быть в достаточной мере субъективным, поскольку подход к конструированию аргументов зависит от лица, которое выполняет эту задачу. Некоторые практики Assurance Case отмечают, что в нотациях существует ряд пробелов, связанных с полнотой определения элементов семантики.
Сложилось так, что на сегодняшний день более распространенной является GSN. Формат GSN закреплен в стандарте «Goal Structuring Notation (GSN) Community Standard», а также в метамодели данных «Structured Assurance Case Metamodel (SACM)» от Object Management Group (OMG).
База знаний: отрасли, стандарты, исследования, инструменты, альтернативные нотации
Assurance Case используется, в первую очередь, в тех отраслях, в которых его применение регламентировано нормативными документами. Лидером здесь является Великобритания и некоторые другие страны Британского содружества. В отчете британской Health Foundation «Using safety cases in industry and healthcare» (2012) говорится об опыте нормативного применения Assurance Case (Safety Case) в здравоохранении, авиации, атомной энергетике, автомобильной, оборонной, нефтехимической и железнодорожной отраслях.
Если рассматривать требования к применению Assurance Case за пределами Великобритании, то следует отметить:
Также следует отметить ряд организаций (помимо уже упомянутых Adelard и High Integrity Systems Engineering Group из университета Йорка), которые активно работают в области Assurance Cases. К ним относятся:
Из программных средств поддержки Assurance Case наиболее известным остается Adelard ASCE (Case Case and Safety Case Environment). Большинство проектов, упоминаемых в разные годы, так и не вышли на какой-либо серьезный уровень. NASA заявило о создании ПО AdvoCATE, но они применяют его в собственных целях, и не планируют выпускать на рынок. Учитывая простоту нотации, для составления диаграмм Assurance Case и их дополнения гиперссылками можно использовать, например, MS Visio.
Из альтернативных подходов к разработке Assurance Case можно также упомянуть программный инструмент NOR-STA. Он бы разработан польской компанией Argevide (spinoff Гданьского технологического университета). NOR-STA поддерживает собственную нотацию TRUST-IT. Разница состоит в том, что вместо графического представления NOR-STA использует структурированный иерархический список (Рисунок 6).