Инженерное обоснование деятельно, оно требует ресурсов

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

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

Что считать рационально обоснованными решениями? Обычно такими решениями называют решения, выработанные согласно SoTA известным человечеству теориям решений (мы уже касались этого вопроса, когда говорили о прохождении развилок/trade-off studies):

• Нужно быть lean, если проблема неважна, то просто её не решаем.
• Если важна, то шаг формализации того, чего нужно достичь, какую проблему решаем (и тут нужно понимать, что пока вы занимаетесь решением проблемы, обстоятельства могут измениться, проблема может «поплыть», формализация станет сомнительной). В формальной постановке проблемы проще находить ошибки, без этого нельзя.
• Сгенерировано какое-то количество альтернатив (уже известных, или новых). Нет альтернатив — плохие решения. Помним, что всё, что говорится про мутации (абсолютное большинство плохих и ухудшающих, немного примерно одинакового квазиоптимального SoTA уровня, крайне редко скачки в SoTA за счёт предложения нового решения, оптимизирующего конфликты на многих системных уровнях за счёт усложнения) верно для генерации альтернатив. Если альтернатива одна, то есть альтернатив нет — у вас плохое воображение, это провал.
• Выбор между альтернативами (прохождение развилки) обоснован согласно SoTA методам. Когда-то это была только булева логика, затем вероятностный выбор частотный, потом вероятностный выбор по байесовской статистике, затем вероятностный выбор по квантовоподобным вычислениям^[1]. Текущие стандарты обоснований поддерживают в их простейшей форме «научный метод» как «рассуждения по индукции и дедукции», лучшие из них (например, Assurance 2.0) выходят в статистические методы снятия неопределённости, большинство признаёт важность в том числе и принятие «экспертных» (читай: интуитивных, никак не формализованных) решений. Мало какие методы учитывают то, что понятие рациональности двигается со временем. Мало какие методы вообще подразумевают явные отсылки к разным теориям рациональности и теориям решений. И ещё важно помнить, что речь идёт про причины и следствия и контрфактические рассуждения, а не просто про «логику» (логика легко отрывается от физической реальности, а вот причины и следствия обычно стараются как-то привязать к реальности).
• Дальше надо принять рациональный выбор всерьёз: запланировать работы по итогам выбора.
• Выполнить запланированные работы! Учтите результаты обоснований! Если обосновать успешность системы не удалось, то надо или отказаться от проекта, или что-то менять в системе!
• Убедитесь, что результатами пользуются: если не пользуются, то всего этого можно было бы и не делать.

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

Говорим мы тут об обосновании выбора технического решения (rationale для выбора, например, одной архитектуры из трёх предложенных — но их сначала надо три предложить!) или о самом выборе способа обоснования (выбор типа аргумента, их тоже лучше рассмотреть несколько)? Речь идёт об обоих случаях. И технические решения нужно предложить в достаточном количестве и качестве, чтобы было из чего выбрать, а затем нужно предложить достаточное количество способов обоснования этих решений, чтобы выбирать уже из этих способов.

Вспомним предыдущий пример обоснования того, что модуль M реализует требование, там говорилось о том, что обоснование велось

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

Но можно предложить и ещё варианты:

• доказать, что претензия всегда удовлетворена «в силу конструкции» (by design, и это недопустимый способ, нельзя обосновывать «в силу требования» или «в силу проекта/design», ибо необязательно в воплощении системы будет реализовано требование или конструкция, это как раз и обосновывается: получили то, что хотели, а не «верно, потому как хотели»),
• построить тестовую установку, которая будет случайным образом менять напряжения на входе и отмечать/записывать ситуации, когда не выполняется требование (то есть автоматизировать шаги построения таблицы и сравнения значений замеров).
• … таких вариантов можно предложить ещё и ещё.

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

Ещё надо помнить об эргодичности^[2]: гипотеза эргодичности говорит, что результат подбрасывания монетки 1000 раз в плане выпадания решки и орла такой же, как подбрасывания 1000 монеток по одному разу, ибо монетки и условия одинаковы. Увы, в технических системах с памятью всё не так, эти системы не эргодичны. Вы не можете согнуть телефон 1000 раз и сказать, что с ним дальше при сгибаниях всё будет в порядке, если он не поломался от этого. Ибо в материале накопилась усталость, в материале есть память на эти сгибания. Если вы завели автомобиль перед выдачей его покупателю, это вовсе не означает, что он и дальше будет заводиться так же всё время его эксплуатации. В обоснованиях нужно учитывать и этот эффект.

Для некоторых ситуаций вы не можете провести испытаний (единственная ракета, которая летит на Марс: как испытать её в полёте?). Тогда вы можете приложить значительные усилия, чтобы отмоделировать эти «испытания». Так, после всемирного моратория на ядерные испытания в 1985 году резко возрос спрос на компьютеры для моделирования ядерных взрывов, и доступ к суперкомпьютерным технологиям стал приравниваться к доступу к самим испытаниям, на экспорт мощных процессоров США постоянно вводят эмбарго^[3] как раз из-за того, что они помогают разрабатывать ядерное оружие, не прибегая к натурным испытаниям, проводят обоснования успешности разработки ядерного оружия за счёт моделирования.

Вот этот деятельностный характер моделирования ни в коем случае нельзя выпускать из виду:

• Если это деятельность, то она задействует ресурсы. Если нет информации для снижения степени неопределённости инженерного обоснования, то нужно её купить. Если нельзя купить, нужно что-то делать самим**, но это тоже можно оценить в деньгах****.** Инженерные обоснования дорогие, программы всевозможных испытаний (главный способ добычи свидетельств для обоснований успешности) могут доходить до 85% стоимости проекта.
• Обоснования тесно связаны с безопасностью и защитой, поэтому они предмет манипулирования («ради безопасности мы за ценой не постоим» и далее расчёты ресурсов на обоснования не производятся, решение принимается «политическое» — в том числе с необоснованно высокими тратами ресурсов). Оцените финансовые потоки на обоснование того, что вы не болеете коронавирусной инфекцией в 2020-2021 году, и до сих пор неадекватность принятых тогда политических решений не принято обсуждать (хотя уже начинаются попытки, но тут правду ещё долго не узнают — данные для любых обоснований на самом нижнем уровне учёта массово подделывались).
• Работы по обоснованию (отнюдь не только испытания/testing, но и другие виды обоснований) нужно планировать, эти работы нужно адекватно оплачивать. Тут легко и перефинансировать выше оптимума, и недофинансировать (иметь недостаточную уверенность в успешности). Как вы будете определять оптимум выделения ресурсов на обоснования?
• Обоснования трудно выделить в отдельный метод, ибо обоснования рекурсивно задействованы в каждой части проекта (когда вы сделали винтик M3 для самолёта, это хорошо бы как-то обосновать — точно ли это винтик M3, или «какой-то винтик», но есть обоснования и уровня всего самолёта в целом, так что отдельно посчитать ресурсы и финансы «на обоснования» по факту невозможно, нужно считать их на каждом отдельном системном уровне).
• Чем формальнее обоснование, тем оно кажется точнее. Это совсем не так! Проблема с обоснованиями на среднем уровне формальности: там, где невозможно сделать точный расчёт вероятностей успешности и любой шаг повышения формальности крайне дорог, но и любая чисто интуитивная оценка не годится. Стандарты «обосновывающих дел» запредельно дороги в их применении именно потому, что заведомо требуют неадекватно высокого уровня формализма, и их применение вдруг делает весь проект невыгодным. Атомная энергия дико дорогая потому, что нормы обоснований на атомный проект в разы и разы выше, чем в среднем по промышленности: трубопроводная арматура там стоит в разы выше, чем для нефтепроводов, водопроводов и газопроводов именно из-за дополнительных обоснований. Оправдано ли это экономически? Нет, это обсуждается в профессиональных кругах, но поскольку речь идёт о ценах, которые платят налогоплательщики (по факту нет «частного мирного атома»), то ситуация становится только хуже.
• Если вы что-то обосновали вчера, то сегодня вам нужно обосновывать это заново: жизнь изменилась!

Вот примерные составляющие цены обоснования потребительских продуктов через их испытания (и это только сбор свидетельств в пользу претензии на успешность системы, а ещё аргументирование, документирование, коммуникация и т.д.)^[4]:

• Время аренды лаборатории и её оборудования, в том числе время переналадки оборудования, проведения измерений, уборки после проведения испытаний. Если речь идёт о скоростном тестировании износа (скажем, смоделировать двухлетнюю эксплуатации за всего месяц испытаний), то это получается всё равно долго, поэтому дорого.
• Продукты и их части, особенно если это разрушающее тестирование. Если это прототипы, то они обычно существенно дороже стоят, чем серийная продукция, так что это может быть ещё дороже, чем вы думаете.
• Спецоборудование для тестирования: начиная от крепления до довольно сложных стендов, создающих предположительно эксплуатационную обстановку. А поскольку речь идёт о тестировании в каких-то диапазонах параметров окружающей среды, это может быть довольно дорого: представьте себе тестирование устойчивости к перепадам температур при диапазоне каких-то влажностей, причём сопряжённое с измерением механических характеристик: печка-холодильник с контролируемой влажностью. Дальше вопрос о размерах ваших продуктов, о массовости замеров.
• Логистика на доставку продуктов на тестирование, зарплаты, если это лаборатория, то ещё и накладные расходы на дивиденды владельцам лаборатории. Но если вы проводите тестирование у себя, то не факт, что оно будет зачтено (независимость тестирования важна, в своей-то лаборатории заведомо всё будет «суперуспешно»), плюс много выше начальные затраты (оборудование лаборатории с нуля стоит довольно дорого).

И помним, что не испытывать будет много, много дороже:

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

Не все обоснования делаются по итоговой уже изготовленной/воплощённой системе. Чем раньше вылавливается ошибка, тем дешевле она исправляется. Поэтому проверяются и описания. Такие проверки обычно называют **просмотры/**review — кода, проекта/design, архитектуры, требований, программ испытаний (часто review передают калькой, так и говорят: «архитектурное ревью»). Это тоже средство обоснования заявки на успешность/качество целевой системы, призванное «отловить баги» (найти ошибки) на ранних стадиях разработки, а не в ходе приёмо-сдаточных испытаний или даже эксплуатации. Коллеги и специально приглашённые эксперты смотрят описания системы, которые делают разработчики и задаются вопросами, почему эти описания именно такие, и что можно было бы сделать иначе. Это очень дорогой способ работы.

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

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

Мало что можно сказать про проверку описаний. Вообще, работа с описаниями понятна меньше, чем работа с физическими объектами — ибо заземление/grounding много проще для физических объектов. Так, для физических объектов есть отношения части-целого, они понятны, на этой основе строится системное мышление. А вот для описаний непросто разобраться, что такое «часть» и «целое», чем отличается «функциональная часть описания» от «конструктивной части описания» (в отличие от функциональных и конструктивных частей самой системы). Так что про «испытания описаний» (кроме как «сделать воплощение системы по его описанию и затем испытать это воплощение») можно немного сказать, это на сегодня больше искусство, чем наука/дисциплина, и уж тем более нормативная дисциплина.

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

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

В методе экстремального программирования/eXtreme Programming предложили довести идею просмотра кода до экстремума, «если хорошо, чтобы на код смотрела не одна пара глаз, так пусть всё время смотрит не одна пара», эту концепцию назвали «парное программирование»/pair programming^[5]. Как и в случае TDD (test-driven development, с многочисленными его последующими вариантами вроде BDD, ATDD, мы это уже обсуждали в нашем руководстве) результаты улучшений оказались не такие драматические, к ним было много вопросов (удивительно, но производительность не падала вдвое, но и не росла при заданном уровне дефектов), и после периода краткой моды этот метод так и не стал распространённым. Ситуация поменялась с появлением дешёвых «парных программистов» в составе IDE (GitHub Copilot, Amazon CodeWhisperer, Cursor и т.д.), ситуация аналогична в CAD/CAM/CAE — copilots (а то и peer programmer) становятся важным средством повышения производительности труда инженеров. Но помним, что как люди, так и AI лучше «пишут без ошибок», чем находят уже сделанные ошибки, мы это уже упоминали. Получается, что инженерные обоснования делать чуть ли не дороже, чем проектировать!

Но всё-таки ситуация с автоматизацией как проектирования, так и инженерных обоснований меняется, и по историческим меркам — меняется быстро. Сейчас ошибки безопасности в софте и ошибки несоответствия стандартам в информационных моделях строительства находят специализированные программы анализа кода^[6] и проверки соответствия информационных моделей стандартам, но «автоматизированные ревью» пока ещё не очень надёжны, хотя инфраструктура для них уже более-менее готова (тот же инструментарий DevOps и eXperience platforms). Расчёт всё-таки делается на просмотр кода, информационных моделей и прочих описаний самими разработчиками, но уже с участием агентов AI. А уж если говорить о тех обоснованиях, от которых нельзя отказаться, то есть обоснование соответствия стандартам безопасности, то рынок автоматизации такого обоснования более чем насыщен^[7].

В целом на инженерные обоснования надо закладывать от 20% до 85% бюджета проекта**, и** для не-инженеров это неожиданно**.** Конечно, автоматизация тестирования помогает снизить затраты, но не так сильно: сами коммерческие программы анализа кода или информационных моделей, или построения программ испытаний какой-то аппаратуры стоят достаточно дорого, а испытания на каждом инкременте требуют солидных вычислительных ресурсов. Ну, и написание тестов (даже если их совместить с описанием функциональности или описанием принятых архитектурных решений) тоже занимает время. Или пользователи превращаются в отдел обоснования качества, находят ошибки сами, но и последствия для бизнеса от этого соответствующие. Поэтому надо запомнить, что инженерные обоснования в классических инженерных проектах**—** это по стоимости примерно половина проекта (хотя это всего-навсего небольшой раздел в нашем руководстве**, но по ресурсам он тянет на половину всех ресурсов, нужных на разработку****).**

---

1. https://ailev.livejournal.com/1611838.html ↩︎

2. https://ru.wikipedia.org/wiki/Эргодичность ↩︎

3. Вот пример 2015 года, http://new.gva.vc/ru/about/news/512/?PAGEN_2=4 ↩︎

4. https://qualitytest.net/product-testing-vs-not-testing-costs/ ↩︎

5. https://en.wikipedia.org/wiki/Pair_programming ↩︎

6. Для софта, например, https://www.guru99.com/code-review-tools.html, для информационных моделей ↩︎

7. https://www.g2.com/categories/security-compliance ↩︎