В итоге было признано:
• Важны не требования, а непрерывно уточняющиеся поведенческие модели (модели изменения состояний в ходе функционирования), то есть сценарии использования. Эти модели отражают непрерывно меняющийся набор гипотез о том, что должна делать успешная система. Поскольку вопрос об успешности системы (успешности подсистемы, и т. д. по уровням), то в этих моделях должны учитываться и внешние проектные роли (а внутренние проектные роли вполне могут быть внешними проектными ролями для подпроектов: разработчик самолёта будет внешней проектной ролью по отношению к разработчику авиадвигателя).
Концепция системы – это описание основной идеи модульного синтеза: каким образом какой-то набор конструктивных частей целевой системы исполняет роли функциональных частей системы, чтобы в конечном итоге выдать требуемый от системы сервис на уровень надсистемы. Архитектура системы при этом накладывает на концепцию системы ограничения: говорит о такой разбивке на модули, которые дают необходимые архитектурные характеристики: высокую скорость развития/evolvability для времени создания системы, возможность масштабирования как увеличения производительности по мере роста потребности в сервисе системы, собственно самой производительности системы, и т. д.
Безопасность/safety? Сразу подумайте, а не после того, как к вам придёт инспекция или что-то плохое произойдёт из-за вашей системы в жизни. Защита/security? Сразу подумайте, будьте прочным! Не берите архитектуры, которые легко взламываются, не берите части системы, про уязвимость которых вам ничего не известно! Учитывайте защиту сразу, а не после того, как вашу систему взломали!
То есть continuous delivery (непрерывный ввод в эксплуатацию со всё новыми и новыми фичами, всё новыми и новыми исправленными ошибками, а иногда и со всё новой и новой архитектурой, которая позволяет далее менять систему более быстро) используется и в «железной» инженерии. И уж тем более в инженерии предприятия, где и команды и предприятие в целом ежедневно изменяются в части своей организации и методов своей работы, а не застывают после разового изготовления, сборки, наладки и «пуска в эксплуатацию».
Тут можно просто использовать кофе перед совещанием (повышает количество выдаваемых идей на 30%
Итого: сначала нужно понять функцию системы, её поведение. Моделируется и документируется поведение при помощи use cases
• Вы должны предложить несколько альтернативных концепций, их всегда больше одной, вариантов конструкции обычно много. Если оценивается только одна концепция, то вы что-то делаете не так. Если у вас одно архитектурное решение для выбора из них, а не пять-шесть, то вы чего-то не понимаете в инженерии.
Какие-то идеи могут быть удачны, какие-то нет. Поэтому мы критикуем эти идеи, выбираем лучшие из худших (это особо оговаривается: оптимальных решений нет, поэтому всегда выбираем не лучший вариант, а наименее плохой) и реализуем их, проверяя уже жизнью. Потом пробуем улучшить эти идеи, а если не получается улучшить, отказываемся от этих идей и пробуем что-то ещё.
Цифровые двойники появляются как продолжение трендов моделеориентированности и численного моделирования, при этом полноценная реализация этого тренда сводится к моделеориентированному представлению (параметры модели в виде машиннообрабатываемых данных) и калибровке численных моделей системы по актуальным данным в ходе её эксплуатации, то есть цифровой двойник рассматривается уже за пределами разработки и изготовления. Раньше говорилось о важности цифрового моделирования системы в ходе её разработки и изготовления, но цифровой двойник показывает, что время эксплуатации не менее важно в части моделирования
Тренды практик создания, то есть тренды в сервисах организационных систем, которые обычно и служат системами создания. Например, непрерывность инженерии вместо жёстко организованного стадийного водопадного одноразового производства — и в программной инженерии, и в практически любой инженерии. Это дало не только распространение разного сорта вариантов DevOps и SRE как способов быстрой проверки и введения в эксплуатацию результатов работы разработчиков
