V-диаграмма
V-диаграмма используется для демонстрации разбиения практик жизненного цикла системы на практики её определения и воплощения (левая и правая ветви V), при этом перекладины символизируют соответствие определения и воплощения друг другу.
На рисунке горизонтальная пунктирная линия отделяет практики и работы системной инженерии (сверху) от практик и работ предметной/прикладной инженерии (снизу). Так что из диаграммы видно, что практики системной инженерии встречаются главным образом на начальных и конечных стадиях проекта, а в середине проекта превалирует работа самых разных других инженерных специальностей, направляемая немногими архитектурными решениями.
Особенности
V-диаграмма поясняет самые общие черты системноинженерного процесса/метода/жизненного цикла:
- Фундаментальную разницу между практиками определения системы (работы с информацией), реализации системы (работы с веществами и полями), а также использованием системы. В том числе на V-диаграмме показывается основная идея системной инженерии “восемь раз отмерь, один раз отрежь”: рекомендуется максимизировать трату ресурсов на более ранних стадиях, чтобы потом экономить трату много больших ресурсов на более поздних стадиях.
- Соответствие определений и воплощений системы, поддерживаемое через проверки (верификация) и приёмки (валидация).
- Ведущие практики жизненного цикла (дисциплины-рабочие продукты- инструменты).
- Разницу между системноинженерными практиками (выше пунктирной линии), имеющими дело с системой в целом и “обычными” инженерными практиками, имеющие дело с частями системы.
- Взаимодействие между практиками: работа идёт отнюдь не по той практике-стадии, которой соответствует точка времени на диаграмме! Нет, одновременно задействована вся “вертикаль” практик — архитектор общается и с инженерами по требованиям, и с занимающимися рабочим проектированием, а инженер-интегратор общается и с эксплуатационщиками, и с производителями оборудования.
Должно быть так: «что определяли, то и воплотили» - это обеспечивают практики проверки и приёмки (validation, verification).
Говорят, что потребности стейкхолдеров фокусируют требования, требования фокусируют архитектуру, архитектура фокусирует неархитектурную часть проекта («рабочую документацию»). Свобода в выборе инженерных решений на каждом уровне фокусирования уменьшается. Минимальная свобода — у конструктора или проектировщика, который разрабатывает рабочую документацию. Каждое определение системы ограничивает/фокусирует последующее.
Но “отвечать” и “фокусироваться” вовсе не означает последовательности во времени: так, ограничения в технологии вполне могут повлиять на архитектурные решения, или даже на саму возможность выполнить требования — и тогда получаемая в конце цепочки фокусирования новая информация заставляет менять определения, вплоть до изменения требований или признания невозможности инженерного проекта.