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