Пример описания связи интересов надсистемы и целевой системы
Давайте рассмотрим различия между концепцией использования, концепцией системы и архитектурной документацией. Прием системного мышления состоит в том, что сначала мы рассматриваем систему как «черный ящик» или с точки зрения концепции использования. Сначала смотрим вовне системы (как она эксплуатируется), а уже исходя из концепции использования разбираемся с её внутренним устройством, создавая концепцию системы и архитектурную документацию.
Концепция использования и сценарии использования – это описание вверх от границы целевой системы, которое отвечает на вопрос «как система выполняет свою функцию». И это описание системы как «чёрного ящика». Раньше разрабатывали системные требования, а сейчас разрабатывают концепцию использования. Про смерть инженерии требований читайте подробнее в курсе «Системное мышление» и «Системная инженерия».
Рассмотрение системы как «прозрачного ящика» включает в себя предложение функциональной декомпозиции для системы (от функции системы к функциям подсистем) и последующего модульного синтеза. Это описывается в концепции системы.
При этом при рассмотрении «прозрачного ящика» отдельно выделяется архитектурная документация. Она отражает решение по модульному разбиению системы для удовлетворения главных (архитектурных) характеристик системы или предметов интересов[1].
При этом все эти документы «живые», то есть все эти описания – гипотезы, которые требуется тестировать, менять, обосновывать и согласовывать. Тестирование происходит путем изменения систем, причем система создается сначала как MVP[2], и далее постоянно развивается за счет инкрементов[3]. Архитектурно инкременты выпускаются для максимально незацепленных модулей (loose coupling) автономными командами. Таким образом достигается непрерывное развитие системы.
Обратите внимание, что системное мышление рекурсивно, то есть каждая команда-создатель применяет его одинаково на каждом системном уровне. Рекурсивность означает, что концепция использования целевой системы – это часть описаний концепции надсистемы. То есть получается, что в команде-создателе целевой системы кто-то занимается описанием надсистемы, кто-то — подсистемами и еще кто-то создает саму команду-создателя. Со всеми этими системами на разных системных уровнях и цепочках создания необходимо работать в рамках одного проекта или всего предприятия.
В следующем разделе мы рассмотрим, как это непрерывное развитие и рассмотрение множества систем поддерживается системами создания.
Архитектурные решения могут включать выбор ограничений и модулей, связь между модулями и другие факторы. Важные архитектурные характеристики могут включать способность системы к развитию, легкость внесения изменений и доступность. Подробнее о концепции архитектуры можно узнать в курсе "Системная инженерия". ↩︎
Minimal Viable Product (минимально жизнеспособный продукт). ↩︎
Небольшие улучшения продукта, которые сразу после завершения готовы к использованию. Инкременты противопоставляются итерациям, после которых что-то будет готово к использованию только в конце проекта (всех итераций). ↩︎