Обоснование выполнения требований стандартов (compliance)
Стандартизация в инженерных обоснованиях идёт по двум вариантам:
- или стандартизация формы самого обоснования (assurance case с аргументацией, или произвольное эссе, или обязательное решение комиссии независимых экспертов, и т.д.)
- или стандартизация требований к системе, выполнение которых (compliance, подчинение требованиям) надо обосновывать (если это стандарт, то в нём — требования, а не «гипотезы» или даже use cases).
Проблемы со стандартизацией формы обоснования — это прежде всего трудоёмкость формализации: как выделение отдельно претензий, отдельно аргументов, отдельно свидетельств, отдельно сведение всего обоснования в связную непротиворечивую структуру, так и дополнительные работы по исправлению ошибок (жёсткая форма подсвечивает ошибки, которые легко пропустить в неформальном тексте). Результат стандартизации формы обоснования получается качественным, но дорогим, и тут нужно быть начеку: не слишком ли дорог этот качественный результат? Насколько экономически обоснована лишняя жёсткая формализация?
С обоснованием выполнения требований предметных стандартов (compliance) тоже часты трудности. Часто оказывается, что эти «требования стандартов» не в меру безумны, особенно для стандартов безопасности и защиты, ибо в порядке «ужесточения норм безопасности» в какой-то момент уровень требуемой характеристики становится уже такой низкий, что его непонятно как измерить на фоне шума (ниже естественного природного фона, или погрешности измерительной аппаратуры — решение ведь принимают политики и менеджеры, а не инженеры, такое, например, было на Калининской АЭС, когда для очередного энергоблока оказалось можно брать воду из местного ручья, но нельзя было её возвращать после использования на станции для охлаждения — уровень естественной радиации этого ручья был больше, чем разрешалось стандартом для сброса воды со станции), или же речь идёт о таких редких событиях, что нельзя продемонстрировать статистику (например, аварии автомобилей без водителя: они слишком редки, чтобы можно было делать уверенные выводы о безопасности или опасности таких автомобилей по сравнению с автомобилями с водителем. Можно предлагать результаты моделирования столкновений, но стандарты обычно требуют испытаний «в натуре», а для них данных обычно бывает абсолютно недостаточно для хоть какой-то уверенности). Часты ситуации, когда достижение желаемых уровней безопасности очень и очень дорого, а сам уровень установлен произвольно политиками. «Человечество разучилось рисковать», как сказал Элон Маск, когда комментировал жёсткие требования лицензирования полётов в космос. Это всё проблемы, которые нельзя обычно решить на уровне одного проекта, это чистой воды «политика». Опять же, понятие «безопасность» все понимают по-разному, ибо решения принимаются часто политиками как социальными инженерами, а не инженерами по образованию — и понятие «опасность» в нормативных документах рассматривается по-бытовому[1].
Но иногда бывает наоборот, отсутствие compliance обходится очень дорого. 42-тысячный Эрзинь находится на юге Турции, в центре провинции Хатай. В результате произошедших 6 февраля подземных толчков разрушены здания во многих районах Хатая, кроме Эрзиня. В городе не появилось не только развалин, но и хотя бы обломков, а ни один местный житель в итоге не пострадал. Все здания в городе остались целы, потому что мэр города Эрзинь Оккеш Эльмасоглу не разрешал строительство с нарушениями стандартов. А почему здания в других районах Хатая были разрушены? Потому что там соблазнились более низкими ценами на строительство. Compliance — это дорого, но не всегда безумно.
Стандарты безопасности бывают сформулированы по принципу контроля результата (performance-based) или контроля способа (design-based). Конечно, нужен результат, но соблазн перейти на design-based велик, ибо в разы проще проверять (например, не «прочность балки должна быть достаточной, чтобы выдерживать нагрузку в 100 тонн», а «использовать квадратную балку из стали XYZ и стороной квадрата 10см, лежащую на опорах с шагом не шире 1м»). Но тут проблема в остановке инноваций, ибо если будет изобретён какой-то новый способ выдерживать нагрузку в 100 тонн (какие-нибудь углепластиковые балки, лёгкие и прочные), то их использовать в случае performance-based стандарта будет можно, хотя нужно будет предоставить расчёт и результаты испытания, а вот в условиях design-based стандарта их использовать будет нельзя, разве что нужно будет менять сам стандарт (смена стандарта — это проект масштаба отрасли, а не масштаба конкретного проекта). Скажем, стандарты атомной промышленности США performance-based, а атомной промышленности России (по наследству от времён ещё СССР) design-based. Поэтому сертификация безопасности российских атомных станций в мире весьма затруднительна, если только какая-то страна не берёт за основу своей сертификационной системы весь пакет design-based стандартов и не соглашается на фактическую остановку прогресса на технологиях, закреплённых этими стандартами много десятков лет назад. Что там конкретно выбрано в качестве структуры аргументации внутри самого проекта, какой из многочисленных стандартов нотации и формализации, тут уже не имеет значения: просто некоторые аргументы не принимаются «в силу законодательства», речь уже не идёт о рациональных рассуждениях и теориях решений: решения были сделаны давно, не рационально, другими людьми в другой ситуации.
Если начинать на уровне отрасли/сообщества (а часто и общества) исправлять ситуацию и принимать какие-то рациональные решения, то эти решения имеют огромную цену реорганизации отрасли, в которой давно всё налажено и работает, хотя и не рационально: представьте себе цену смены ГОСТов в России, где на них ориентирован и весь станочный парк, и документация предприятий, и транспорт, и обученные миллионы людей. Эти исправления обычно явно выходят за пределы решений одного инженерного проекта, они выходят на уровень работы с сообществами и даже обществом.
Но на уровне общества могут работать ровно обратные механизмы, поскольку можно политически предложить явно лишние меры по защите и безопасности, в том числе и предъявление развёрнутых формальных обоснований даже там, где они не нужны — и обоснование этих явно лишних мер сделать за счёт денег налогоплательщиков.
Не забываем, что большинство стандартов для инженерных обоснований в форме «обосновывающих дел» зародились где-то в середине нулевых годов 21 века, когда резко повышались требования к безопасности чего бы то ни было со стороны законодательства. Это легко наблюдать, например, на законодательстве о детях: всю историю человечества они свободно играли на улицах практически в любом возрасте, а вот сейчас их нельзя одних выпускать из дома до 12 лет (это даже не ученики начальной школы, это пятый класс!). Можно отдельно обсуждать причины этого явления, но в системной инженерии обойти это обсуждение нельзя: происходящее в конкретном инженерном проекте на уровне технических решений целевой системы и в проектах организаций графа создателей определяется в существенной мере и тем, что происходит в сообществах и обществах, в которых происходят эти разработки и последующая эксплуатация систем.
Ещё одна проблема стандартизации обоснований в требованиях визуальных/диаграммных языков моделирования. Эта мода появилась ещё в конце 20 века, но в жизни они не получили большого распространения: софт для такого моделирования уникальный и дорогой. Хуже всего то, что визуальные модели невозможно вести/изменять (то есть трудно вести/изменять «обосновывающее дело»), их очень трудно ставить под контроль конфигурации, сравнивать и модифицировать, интегрировать с другими моделями. Так что все эти стандарты формы обоснования получили ограниченное распространение за пределами госзаказа с его неограниченными деньгами и неограниченными требованиями к обоснованиям.
Но несмотря на все эти трудности, обоснования в инженерии остались, принципы обоснования на базе документирования свидетельств и явного изложения аргументов, использованных при рассуждении, остались.
В стандартизации сама известность процедуры обоснования соответствия стандарту (compliance) делает стандарт стандартом в отличие от просто «публичного документа», например, «фреймворка» (описание того, какие объекты внимания важны в предметной области, советы «как думать»). Скажем, известный cистемноинженерный фреймворк CPS PWG (Cyber-Physical Systems Public Working Group) Cyber-Physical Systems (CPS) Framework[2] — это публичный документ, ибо для него не предусмотрено, как обосновывать следование этому документу. ISO 15288:2023 предусматривает обоснования того, что система-создатель какой-то системы следует предписаниям этого стандарта. Все положения этого стандарта следуют рекомендациям стандарта ISO 33001:2015 (он заместил более древний стандарт ISO 15504:2004 SPICE) по оценке процессов (process assessment). Это означает, что известна процедура, по которой можно оценить, следует ли какая-то разработка положениям стандарта ISO 15288 (и варианта его для программной разработки ISO 12207), и в какой степени следует. Это не означает, что вы прямо-таки должны следовать положениям этого стандарта и должны проводить оценку, но это означает потенциальную возможность: известность процедуры.
Обоснование соответствия стандарту — важная часть стандартизации, а стандартизация — важная часть системной инженерии. Обосновав соответствие стандарту (например, что вилка вашего электроприбора соответствует стандарту), вы исключаете необходимость обоснования (например, путём испытаний) соответствия вашего продукта огромному числу других продуктов (например, огромного числа розеток для этой вилки). Если вы сделали компьютерную клавиатуру, и она следует стандартам компьютерных интерфейсов (USB или Bluetooth), то вам нужно только, чтобы она честно следовала этим стандартам, и испытывать нужно именно это соответствие/compliance стандартам. Не нужно будет проверять работоспособность клавиатуры во всех возможных режимах со всеми потенциально возможными компьютерами, док-станциями, удлинителями кабелей и т.д.