V-диаграмма — различия между версиями
Admin (обсуждение | вклад) |
Admin (обсуждение | вклад) м (→Модификации) |
||
Строка 18: | Строка 18: | ||
== Модификации == | == Модификации == | ||
− | * http://en.wikipedia.org/wiki/Dual_Vee_Model Dual V-model | + | * [http://en.wikipedia.org/wiki/Dual_Vee_Model Dual V-model] |
[[Категория:Модели ЖЦ]] | [[Категория:Модели ЖЦ]] |
Версия 09:29, 3 августа 2016
V-диаграмма используется для демонстрации разбиения практик жизненного цикла системы на практики её определения и воплощения (левая и правая ветви V), при этом перекладины символизируют соответствие определения и воплощения друг другу.
Особенности
V-диаграмма поясняет самые общие черты системноинженерного процесса/метода/жизненного цикла:
- Фундаментальную разницу между практиками определения системы (работы с информацией), реализации системы (работы с веществами и полями), а также использованием системы. В том числе на V-диаграмме показывается основная идея системной инженерии “восемь раз отмерь, один раз отрежь”: рекомендуется максимизировать трату ресурсов на более ранних стадиях, чтобы потом экономить трату много больших ресурсов на более поздних стадиях.
- Соответствие определений и воплощений системы, поддерживаемое через проверки (верификация) и приёмки (валидация).
- Ведущие практики жизненного цикла (дисциплины-рабочие продукты- инструменты).
- Разницу между системноинженерными практиками (выше пунктирной линии), имеющими дело с системой в целом и “обычными” инженерными практиками, имеющие дело с частями системы.
- Взаимодействие между практиками: работа идёт отнюдь не по той практике-стадии, которой соответствует точка времени на диаграмме! Нет, одновременно задействована вся “вертикаль” практик — архитектор общается и с инженерами по требованиям, и с занимающимися рабочим проектированием, а инженер-интегратор общается и с эксплуатационщиками, и с производителями оборудования.
Должно быть так: «что определяли, то и воплотили» - это обеспечивают практики проверки и приёмки (validation, verification).
Говорят, что потребности стейкхолдеров фокусируют требования, требования фокусируют архитектуру, архитектура фокусирует неархитектурную часть проекта («рабочую документацию»). Свобода в выборе инженерных решений на каждом уровне фокусирования уменьшается. Минимальная свобода — у конструктора или проектировщика, который разрабатывает рабочую документацию. Каждое определение системы ограничивает/фокусирует последующее.
Но “отвечать” и “фокусироваться” вовсе не означает последовательности во времени: так, ограничения в технологии вполне могут повлиять на архитектурные решения, или даже на саму возможность выполнить требования — и тогда получаемая в конце цепочки фокусирования новая информация заставляет менять определения, вплоть до изменения требований или признания невозможности инженерного проекта.