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