Рациональность обоснований

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

В основе традиционного однократного обоснования лежит обычно метод картирования аргументов (argument map). Он не очень удобен, ибо чаще всего даётся в диаграммной форме (часто пишут как argument diagram)^[1]. Этот метод реализован в довольно разной терминологии в самых разных стандартах инженерных обоснований для водопадной модели однократного прохождения жизненного цикла, которые помогают как-то унифицировать ведение обосновывающих дел главным образом в «железной» инженерии крупных инженерных систем (часто с госфинансированием и жёстким регулированием инженерной деятельности со стороны госорганов самых разных стран). Это прежде всего стандарты:

IEEE/ISO 15026 «Systems and software engineering — Systems and software assurance»^[2] (в русском переводе assurance перевели как «гарантирование», что плохо отражает инженерную суть дела^[3]), четыре его части в разных версиях вышли в 2011-2021 годах.
GSN, Goal Structuring Notation Community Standard^[4], версия 2 вышла в 2018 году.
OMG SACM, Structured Assurance Case Metamodel^[5], версия 2.2, вышла в 2021 году
CAE framework, Claims, Argument, Reasoning^[6], разработка Adelard LLP. с 2007 по настоящее время^[7]. Именно этот фреймворк поддерживается наиболее распространённым софтом для построения обосновывающих дел, ASCE^[8]. Впрочем, и для всех остальных вариантов достаточно моделеров, все они строят дерево обоснования, для простейших случаев рекомендуют использовать любой софт Mind Map для отображения деревьев, но и аутлайнеры (в том числе outliner в MS Word) с этим справляются, если отойти от диаграммной формы для дерева и перейти к списку с гнездованием/отступами.
Assurance 2.0 framework^[9], разработка 2020 года. Основная тут цель — это поддержка инноваций (ибо любое новое инженерное решение кажется при традиционных обоснованиях подозрительным и ненадёжным) и инкрементальное построение обоснования (более совместимое с agile).
… и это ещё далеко не всё. Стандарты «де юре» (нейтральные по отношению к инструментам разных поставщиков), разработанные организациями стандартизации и стандарты «де факто» (стандарты, задаваемые конкретным программным инструментарием) для assurance case более чем распространены, а ещё они часто не отдельны, а входят в самые разные другие стандарты.

Практически идентичные идеи структурирования обоснований на основе аргументов лежат в основе стандартов целеориентированной инженерии требований (GORE, goal-oriented requirements engineering), где упор делается на то, что требования должны быть обоснованными, равно как обоснованными должны быть и претензии на удовлетворение этих требований. Все эти стандарты появились существенно раньше примерно 2015-2016 года, когда инженерия требований перестала восприниматься как живой, активно развивающийся инженерный метод. В основе всего этого движения был агент-ориентированный фреймворк i*^[10] ещё 1995 года и основанный на нём стандарт ITU-T 151 User Requirements Notation (URN) с его диалектом Goal-oriented Requirement Language (GRL). Есть работы, которые показывают, что типичный стандарт инженерных обоснований ISO 15026 легко отображается на GRL, и сам этот стандарт ISO 15026 может думаться как подмножество GRL за минусом агентской ориентации GRL^[11]. Такие же стандарты начинают появляться в области обоснований принятых решений (rationale).

Обоснования успешности/assurance (часто переводят как «обоснование качества» или «гарантирование качества»), обоснования решений/rationale (например, архитектурных решений, **architecturerationale) все имеют общую природу****—** обоснования/assurance, иногда их называют и рассуждениями/reason, и доказательствами/proofs, и аргументированием/argumentation.

Все эти стандарты сделаны для того, чтобы было легче находить ошибки аргументации**.** Обратите внимание, что чаще всего в обоснованиях делают не ошибки проведения испытаний, или моделирования, или экспертизы, а именно ошибки аргументации**—** ошибки вывода заключения на основе каких-то свидетельств, то есть логические ошибки**, в том числе ошибки в причинных рассуждениях (causalinference****).** Рациональность как метод принятия решений на основании причинных рассуждений в условиях неопределённости объяснялась в руководстве по рациональной работе. Но до причинности (и связанной с причинностью контрфактуальностью) в инженерных обоснованиях часто не доходят, довольствуются простыми проверками «формальной логики», а не проверками логики причинности.

В частности, стандарт ISO 15026-2 ссылается на работу «A Taxonomy of Fallacies in System Safety Arguments»^[12], в которой приводится классификация ошибочных аргументов (заблуждений/fallacies) и приводятся их примеры в хорошо известных обоснованиях. Вот эта классификация:

Circular Reasoning

Circular Argument
Circular Definition

Diversionary Arguments

Irrelevant Premise
Verbose Argument

Fallacious Appeals

Appeal to Common Practice
Appeal to Improper/Anonymous Authority
Appeal to Money
Appeal to Novelty
Association Fallacy
Genetic Fallacy

Mathematical Fallacies

Faith in Probability
Gambler’s Fallacy
Insufficient Sample Size
Pseudo-Precision
Unrepresentative Sample

Unsupported Assertions

Arguing from Ignorance
Unjustified Comparison
Unjustified Distinction

Anecdotal Arguments

Correlation Implies Causation
Damning the Alternatives
Destroying the Exception
Destroying the Rule
False Dichotomy

Omission of Key Evidence

Omission of Key Evidence
Fallacious Composition
Fallacious Division
Ignoring Available Counter-Evidence
Oversimplification

Linguistic Fallacies

Ambiguity
Equivocation
Suppressed Quantification
Vacuous Explanation
Vagueness

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

Подключение искусственного интеллекта тут пока плохо помогает. Есть работы, которые демонстрируют, что искусственный интеллект, построенный на нейронных сетях, тоже склонен делать такие же ошибки, как и люди^[13]. Хотя простая просьба «проверь перед тем, как отдать результат» существенно повышает вероятность правильного ответа^[14], но этот шаг проверки-приёмки надо запланировать и сделать! AI будет ведущим трендом, ибо несмотря на всю свою слабость его работа обходится дешевле работы людей, он работает быстрее, а также каждые полгода его умственные возможности растут с каждой новой моделью, с каждым новым доступным инструментом, а вот возможности людей –не растут, люди остаются прежними, весьма склонными к ошибкам и весьма сопротивляющимися тратить время на дополнительные проверки.

Есть и множество других работ, которые анализируют предвзятости человеческого мышления (cognitive biases), которые ведут к ошибкам аргументации^[15]. Тем не менее, исследования показывают, что люди — это очень плохие формальные логики, они лучше как байесовские вычислители, и при этом довольно неплохи как квантовоподобные вычислители. Квантовоподобные^[16] (не путать с квантовыми! Это не квантовая физика, а математика, которая используется в том числе в квантовой физике) модели оказываются довольно точно соответствующими реальности^[17], так что как относиться к этим число логическим «предвзятостям» — не очень понятно. Более того, поиск таких предвзятостей обычно абсолютно отвлекает от сути дела: теряется предмет обсуждения, цели обсуждения, насколько важно искать именно логические предвзятости или же лучше делать что-то другое (например, поставить дополнительный эксперимент) в условиях дефицита мыслительного ресурса.

Инженерные обоснования в ходе эволюционной инженерии надо делать непрерывно (continuous assurance), нельзя «сделать и забыть». По факту создателями системы реализуется модель active inference^[18], в которой система-агент имеет

границу с окружением,
порождающую модель себя,
порождающую модель окружения,

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

В инженерии всё то же самое, но поскольку целевые системы до сих пор довольно безмозглы (если это не агентные AI-системы^[19], которые становятся всё умнее и умнее), всё это моделирование и работы по изменениям на основании итогов моделирования делается создателями системы. Тут ещё и слово «создатель» имеет оттенок однократности: вроде как «создал, и система есть». Нет, читать это слово нужно как «создатель MVP системы, а дальше он непрерывно продолжает развивать систему». То есть «создатель-развиватель», мы это неоднократно подчёркивали.

«Сопровождение» (maintenance) раньше включало в себя только поддержание работоспособности системы, а сейчас включает в себя развитие системы (иногда пишут modification или continuous adaptation), и даже смена слова на «поддержка» (support) не совсем тут адекватна. Речь ведь идёт о непрерывном вводе в эксплуатацию новых и новых возможностей системы. Увы, пока непонятно, как об этом говорить в части инженерных обоснований, устоявшихся общепризнанных методов и фреймворков нет.

Оказывается, нельзя говорить и об обосновании как чём-то, что переводит систему из состояния «свойство не обосновано» в состояние «свойство обосновано», ибо речь идёт уже не о статической системе, а о быстро меняющейся системе. «— Посмотри, у меня поворотник на машине работает? — Да, смотрю. Работает, не работает, работает, не работает…». Обоснованность тут меняет своё значение, она говорит о том, что если что-то окажется необоснованным, то оно будет замечено, в какой бы момент проекта (когда эксплуатация уже идёт!) эта необоснованность ни появилась.

И тут нужно ещё помнить, что обоснования требуют затраты ресурсов: если вам нужно обосновать использования винтика под крестообразную отвёртку или под обычную, это будет одно обоснование. Если этот винтик как-то существенно оказывается связанным с надёжностью получающейся системы и скоростью её изготовления и ремонта, то вы ещё подумаете о других развилках (сварка, 3D-печать, болт и гайка, клеевое соединение и т.д.). Цена вопроса тут совсем другая, но всё одно обоснование вряд ли потребует много ресурсов. Но вот если какое-то ваше проектное/design или архитектурное решение требует выделения $2 млн., то объём обоснований будет существенно больше, а при $2 млрд. может оказаться и нелинейно больше, при этом «непрерывное уточнение функциональности, архитектуры и учёт изменений окружения системы» и прочие ваши трудности с рассуждениями мало кого будут волновать. Ещё одна проблема в том, что вы легко сможете отбиться, изобразив «формальное обоснование в полном соответствии со стандартами»: часто речь идёт о выделении не личных денег, а вполне себе обезличенных каким-то «фондом», собранным инвесторами в лучшем случае, или денег госбюджета, которые гарантированно не принадлежат распорядителям этих денег, и поэтому этим распорядителям могут быть важны не собственно обоснования, а убедительная демонстрация того, что какое-то внимание обоснованиям таки было уделено. Так что содержание обоснований не посмотрят, критику аргументации вести не будут, continuous delivery с его «проверкой гипотез» обсуждать не будут, но на любые несоответствия формы записи обратят особое внимание, будьте к этому готовы.

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

Почему это всё важно? Мышление происходит на основе высказывания каких-то догадок, часто ошибочных. Чисто логически нельзя доказать догадку, но можно её опровергнуть, показав ошибочность аргументации в её поддержку. Поэтому качество мышления зависит от нескольких факторов:

Качество выдвижения догадок. Нужно быть достаточно безумным фантазёром, чтобы выдвинуть догадку, до которой раньше никто ещё не додумался. Догадки должны быть «умными», а не совсем уж случайными. Эволюция должна быть не совсем уж методом проб и ошибок: все пробы должны быть крайне вероятными в части их возможного успеха.
Качество критики. Все ошибки в догадках должны быть обнаружены как можно раньше. И вот тут помогает логика. Логика не может дать качественную догадку, догадки не выводятся из данных, но зато на основе данных можно качественно прокритиковать догадку. Инженерные обоснования не говорят, как получить успешную систему. Но они не дают получить неуспешную систему, они прямо указывают на её неуспешность и дают границы для уверенности в успехе.
Ресурсы, которые вы можете потратить как на выдвижение догадок, так и на критику. Ибо пока толстый сохнет, тонкий сдохнет. В конечном итоге на рынке (или в политической борьбе, или в экосистеме — инженерии бывают очень разные) победит тот, у кого хватит ресурсов больше выдвигать догадки, жёстче их критиковать и больше экспериментировать в реальной жизни.

Рациональность обоснований ​

Рациональность обоснований