V-диаграмма — различия между версиями
(Новая страница: «'''V-диаграмма''' используется для демонстрации разбиения практик жизненного цикла систем…») |
Admin (обсуждение | вклад) |
||
(не показаны 3 промежуточные версии этого же участника) | |||
Строка 1: | Строка 1: | ||
'''V-диаграмма''' используется для демонстрации разбиения практик жизненного цикла системы на практики её определения и воплощения (левая и правая ветви V), при этом перекладины символизируют соответствие определения и воплощения друг другу. | '''V-диаграмма''' используется для демонстрации разбиения практик жизненного цикла системы на практики её определения и воплощения (левая и правая ветви V), при этом перекладины символизируют соответствие определения и воплощения друг другу. | ||
+ | |||
+ | [[File:V-diagramm_ШСМ.png|center]] | ||
+ | |||
+ | На рисунке горизонтальная пунктирная линия отделяет [[Практика|практики]] и [[Работа|работы]] системной инженерии (сверху) от практик и работ предметной/прикладной инженерии (снизу). Так что из диаграммы видно, что практики системной инженерии встречаются главным образом на начальных и конечных стадиях проекта, а в середине проекта превалирует работа самых разных других инженерных специальностей, направляемая немногими архитектурными решениями. | ||
+ | |||
+ | == Особенности == | ||
+ | V-диаграмма поясняет самые общие черты системноинженерного процесса/метода/жизненного цикла: | ||
+ | * Фундаментальную разницу между практиками определения системы (работы с информацией), реализации системы (работы с веществами и полями), а также использованием системы. В том числе на V-диаграмме показывается основная идея системной инженерии “восемь раз отмерь, один раз отрежь”: рекомендуется максимизировать трату ресурсов на более ранних стадиях, чтобы потом экономить трату много больших ресурсов на более поздних стадиях. | ||
+ | * Соответствие определений и воплощений системы, поддерживаемое через проверки (верификация) и приёмки (валидация). | ||
+ | * Ведущие практики жизненного цикла (дисциплины-рабочие продукты- инструменты). | ||
+ | * Разницу между системноинженерными практиками (выше пунктирной линии), имеющими дело с системой в целом и “обычными” инженерными практиками, имеющие дело с частями системы. | ||
+ | * Взаимодействие между практиками: работа идёт отнюдь не по той практике-стадии, которой соответствует точка времени на диаграмме! Нет, одновременно задействована вся “вертикаль” практик — архитектор общается и с инженерами по требованиям, и с занимающимися рабочим проектированием, а инженер-интегратор общается и с эксплуатационщиками, и с производителями оборудования. | ||
Должно быть так: «что определяли, то и воплотили» - это обеспечивают практики [[Проверки и Приемки|проверки и приёмки]] (validation, verification). | Должно быть так: «что определяли, то и воплотили» - это обеспечивают практики [[Проверки и Приемки|проверки и приёмки]] (validation, verification). | ||
− | [[File:V-diagramm.png | + | [[File:V-diagramm.png]] |
Говорят, что потребности стейкхолдеров фокусируют требования, требования фокусируют архитектуру, архитектура фокусирует неархитектурную часть проекта («рабочую документацию»). '''Свобода в выборе инженерных решений на каждом уровне фокусирования уменьшается.''' Минимальная свобода — у конструктора или проектировщика, который разрабатывает рабочую документацию. Каждое определение системы ограничивает/фокусирует последующее. | Говорят, что потребности стейкхолдеров фокусируют требования, требования фокусируют архитектуру, архитектура фокусирует неархитектурную часть проекта («рабочую документацию»). '''Свобода в выборе инженерных решений на каждом уровне фокусирования уменьшается.''' Минимальная свобода — у конструктора или проектировщика, который разрабатывает рабочую документацию. Каждое определение системы ограничивает/фокусирует последующее. | ||
Строка 9: | Строка 21: | ||
Но “отвечать” и “фокусироваться” вовсе не означает последовательности во времени: так, ограничения в технологии вполне могут повлиять на архитектурные решения, или даже на саму возможность выполнить требования — и тогда получаемая в конце цепочки фокусирования новая информация заставляет менять определения, вплоть до изменения требований или признания невозможности инженерного проекта. | Но “отвечать” и “фокусироваться” вовсе не означает последовательности во времени: так, ограничения в технологии вполне могут повлиять на архитектурные решения, или даже на саму возможность выполнить требования — и тогда получаемая в конце цепочки фокусирования новая информация заставляет менять определения, вплоть до изменения требований или признания невозможности инженерного проекта. | ||
− | [[Категория: | + | == Модификации == |
+ | * [http://en.wikipedia.org/wiki/Dual_Vee_Model Dual V-model] | ||
+ | |||
+ | |||
+ | [[Категория:Модели ЖЦ]] |
Текущая версия на 09:10, 11 апреля 2024
V-диаграмма используется для демонстрации разбиения практик жизненного цикла системы на практики её определения и воплощения (левая и правая ветви V), при этом перекладины символизируют соответствие определения и воплощения друг другу.
На рисунке горизонтальная пунктирная линия отделяет практики и работы системной инженерии (сверху) от практик и работ предметной/прикладной инженерии (снизу). Так что из диаграммы видно, что практики системной инженерии встречаются главным образом на начальных и конечных стадиях проекта, а в середине проекта превалирует работа самых разных других инженерных специальностей, направляемая немногими архитектурными решениями.
Особенности
V-диаграмма поясняет самые общие черты системноинженерного процесса/метода/жизненного цикла:
- Фундаментальную разницу между практиками определения системы (работы с информацией), реализации системы (работы с веществами и полями), а также использованием системы. В том числе на V-диаграмме показывается основная идея системной инженерии “восемь раз отмерь, один раз отрежь”: рекомендуется максимизировать трату ресурсов на более ранних стадиях, чтобы потом экономить трату много больших ресурсов на более поздних стадиях.
- Соответствие определений и воплощений системы, поддерживаемое через проверки (верификация) и приёмки (валидация).
- Ведущие практики жизненного цикла (дисциплины-рабочие продукты- инструменты).
- Разницу между системноинженерными практиками (выше пунктирной линии), имеющими дело с системой в целом и “обычными” инженерными практиками, имеющие дело с частями системы.
- Взаимодействие между практиками: работа идёт отнюдь не по той практике-стадии, которой соответствует точка времени на диаграмме! Нет, одновременно задействована вся “вертикаль” практик — архитектор общается и с инженерами по требованиям, и с занимающимися рабочим проектированием, а инженер-интегратор общается и с эксплуатационщиками, и с производителями оборудования.
Должно быть так: «что определяли, то и воплотили» - это обеспечивают практики проверки и приёмки (validation, verification).
Говорят, что потребности стейкхолдеров фокусируют требования, требования фокусируют архитектуру, архитектура фокусирует неархитектурную часть проекта («рабочую документацию»). Свобода в выборе инженерных решений на каждом уровне фокусирования уменьшается. Минимальная свобода — у конструктора или проектировщика, который разрабатывает рабочую документацию. Каждое определение системы ограничивает/фокусирует последующее.
Но “отвечать” и “фокусироваться” вовсе не означает последовательности во времени: так, ограничения в технологии вполне могут повлиять на архитектурные решения, или даже на саму возможность выполнить требования — и тогда получаемая в конце цепочки фокусирования новая информация заставляет менять определения, вплоть до изменения требований или признания невозможности инженерного проекта.