Системная инженерия – 2022 - страница 10



• Эксплуатация одной версии системы

• Жизненный цикл одной версии системы

• Непрерывная инженерия множества версий (множество жизненных циклов «замысел-проектирование-изготовление-эксплуатация-вывод из эксплуатации»).


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

• Потребнадзор::сообщество и общество

• Клиентура::сообщество (маркетинг)

• Клиент::личность

• Желудок и кишечник::существо

• Таблетка::вещество

• Лактобактерия::существо


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

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

Потребуется каждый раз описывать функциональность системы и определять приоритеты в архитектурных характеристиках (надёжность, изменяемость и т.д.) для систем из каждого уровня, принимать архитектурные решения, разрабатывать концепцию системы и изготавливать её, вводить в эксплуатацию и заниматься всеми остальными инженерными практиками, хотя они и будут носить разные имена и для веществ, и для существ, и для личностей, и так далее. И это простой и обозримый пример, хотя уже и в нём нужно затрагивать проблемы высоких уровней. Скажем, все штаммы молочнокислых бактерий, грубо говоря, «штаммы кефира и йогурта разных сортов», обладают примерно одинаковой полезностью по влиянию на микрофлору и уж точно не являются лекарствами, их даже «биодобавками» считать сложно – если вы упакуете кефир или йогурт в капсулы, они ж не станут от этого «биодобавками»? Но вы можете использовать «связи в министерстве», чтобы этот кефир с йогуртом в капсулах назвать лекарством, получить лицензию и устроить на этом маркетинг! Это этично, или нет? Хорошо ли от этого будет людям (они получат плацебо!), а хорошо ли будет (гражданскому) обществу?

А теперь представьте реальную разработку: вряд ли проект закончится выпуском партии таблеток. Скорее всего, команда будет готовить другие версии – улучшать упаковку, вещество, варьировать цену, увеличивать разнообразие вариантов в надежде на привлечение покупателей, менять название и рекламные слоганы, получать новые сертификаты и лицензии, собирать статистику по итогам применения, и т. д. Инженерия таблетки оказывается не разовой, а непрерывной, при этом работа идёт отнюдь не только с веществом таблетки, она вполне многомасштабна.