V-диаграмма

Самым упрощённым, популярным и распространённым визуальным представлением «однократного» жизненного цикла с показом основных практик в их развёртке по «логическому времени» является V-диаграмма (V-diagram, Vee diagram), популяризованная в 1991 году Kevin Forsberg[1]:

Это «культурное наследие» прошлых времён, и его нужно знать хотя бы для того, чтобы мочь поддержать разговор с инженерами старших поколений.

Название этой диаграммы происходит от формы латинской буквы V, а форма выражает линию времени, перегнутую пополам в точке, где укрупнённая стадия описания системы/system definition переходит в укрупнённую стадию воплощения системы/system realization. То есть это двумерная диаграмма: в ней стадии (работы, разворачивающиеся по неявной линии времени) по горизонтали, а практики указаны по вертикали на разных частях диаграммы. В этой диаграмме также отражено старинное представление о практиках разработки: не столько выдвижение гипотез о том, какая может быть концепция использования, сколько «выявление потребностей» и «определение требований» (requirements definition). Мы не будем менять набора практик на современные на этой диаграмме, даём её в привычном для предыдущего поколения инженерии виде.

Перегиб линии времени легко понять, если вспоминать, что время в функциональных диаграммах «логическое», это ведь не последовательно идущие шаги работы, а практики/функции. Так что время на этих «неколбасных» диаграммах жизненного цикла с методом описания, ориентированным на практики, а не только стадии, означает совершенно необязательно строгий порядок выполнения работ, но указывает те деятельности/практики, которыми нужно будет заниматься в проекте. Тем не менее, на этой диаграмме условно можно выделить три «логические» стадии условных работ (ну, или «укрупнённые практики, работы по которым выполняются последовательно»), в которых отчётливо виден «водопад».

Первая из них --- стадия описания системы (system definition, проектирование), когда физической системы/воплощения системы не существует, а ведущими являются практики инженерии требований, инженерии системной архитектуры (в старом её понимании) и (рабочего, то есть с точностью, достаточной для изготовления) проектирования. Это «работа с битами», информационная. Словосочетание «описание системы» тем самым используется в двух разных значениях (и никогда в значении «словарное определение» из неправильного перевода system definition!), и его значение определяется из контекста:

  • Информация о системе, выраженная в требованиях, архитектуре и неархитектурной части проекта/design (акцент на то, что это описание как содержание системной документации)
  • Обобщённая/укрупнённая стадия жизненного цикла, то есть работы по описыванию системы/созданию описания системы в первом смысле этого слова (информация о системе, а не стадия).

Дальше линия времени делает перегиб, и логически начинается вторая стадия воплощения системы (system realization, реализация как «вынос в реальность»). Словосочетание «воплощение системы» тем самым тоже используется в двух словарных значениях:

  • Название типа самой системы как физического тела в пространстве-времени
  • Название обобщённой/укрупнённой стадии жизненного цикла, то есть работ различных практик по воплощению системы в физическом мире (а не работ описания, не работ эксплуатации).

Сам излом V нужен для того, чтобы показать инженерные обоснования/assurance. Эти обоснования делят на два рода: проверки/верификации/verification и приёмки/валидации/validation. Изготовление деталей (неделимых далее в проекте модулей) системы делается и проверяется в соответствии с проектом/design, стрелки проверки/верификации показывают именно этот факт. Ради показа этих стрелок проверки соответствия воплощения описанию и сделана сама V-диаграмма: она показывает способ работы/вид жизненного цикла/упорядоченный логически набор практик, в котором воплощение/создание/realization системы происходит не путём проб и ошибок в физическом мире, а сначала путём размышлений и моделирования-документирования/описания системы/system definition. И созданная/воплощённая (изготовленная в виде деталей, а затем собранная из этих деталей) система проверяется на соответствие её предварительно разработанному описанию --- эти проверки изображаются стрелочками проверки на диаграмме.

Последнее, что происходит в ходе воплощения --- это приёмка в эксплуатацию/валидация/validation, которая проходит в форме проведения испытаний на соответствие определённым в самом начале потребностям (то есть проверяется, что происходит не с целевой системой, а с надсистемой, когда в её составе работает целевая система --- испытывается надсистема, или хотя бы её модель/эмуляция/имитация).

На этом первые V-диаграммы обычно и заканчивались, но потом иногда начали изображать и стадию эксплуатации/использования (работу/функционирования системы, system operation) как длинный горизонтальный отрезок. На нашем рисунке это «иногда» показано квадратными скобочками вокруг [работы системы]/system operation. Внешний вид диаграммы больше стал напоминать квадратный корень, но название «V-диаграмма» осталось.

Стадию вывода из эксплуатации на V-диаграммах изображать так и не начали. Это отражает постепенное восприятие системного мышления инженерами: сначала идея жизненного цикла проекта разработки системы (то, чем занимаются системные инженеры в своём проекте), потом охват мышлением стадии эксплуатации (ещё шаг к удержанию внимания на полном жизненном цикле), и только в самое последнее время (уже в 21 веке, начиная со стандарта ISO 15288, первая версия которого вышла в 2002 году) умолчанием является обязательное рассмотрение полного жизненного цикла --- в том числе и (инвестиционный, коммерческий) замысел, начиная с проверки соответствия идеи проекта стратегии предприятия, берущегося за проект, и заканчивая выводом из эксплуатации/уничтожением после использования.

Горизонтальная пунктирная линия, отделяющая верх и низ V-диаграммы часто используется для того, чтобы отделить практики и работы (в V-диаграмме практики и работы перемешаны и чётко не разделяются) системной инженерии (то есть практики и работы с требованиями, архитектурой, проверкой и приёмкой) от практик и работ предметной/прикладной инженерии, то есть от практик и работ по рабочему (а не архитектурному: в рабочем проектировании детальность, достаточная для изготовления, а не только самое важное, как в архитектурном) проектированию механических, электрических элементов, кодированию софта, а затем изготовлению/воплощению механических и электрических частей системы, разворачиванию программных частей системы на целевых компьютерах. Так что из диаграммы видно, что практики системной инженерии встречаются главным образом на начальных стадиях проекта/project и конечных стадиях, а в середине проекта превалирует работа самых разных других инженерных специальностей, направляемая немногими архитектурными решениями.

V-диаграмма --- это одна из первых (это 1991 год, спиральная диаграмма --- 1986 год, практически неразличимы в историческом масштабе) «логических» диаграмм, «принципиальных схем жизненного цикла», где появляются деятельностные практики, именуемые по содержательным инженерным дисциплинам. Её главная новация --- разделение практик по описанию и воплощению системы с проверками и приёмками взаимного соответствия, а не только интересующие менеджеров и требующие ресурсов работы стадий жизненного цикла с грубым разделением по замыслу, разработке, изготовлению. V-диаграмма во многом хранит в себе черты водопадного жизненного цикла, но переход к двумерному отображению жизненного цикла от «колбаски» уже даёт многое --- есть огромное число вариантов V-диаграммы, обсуждающих разные аспекты архитектурных решений по поводу жизненного цикла: каким образом практики задействуются в работах[2].

V-диаграмма, сохраняющая хотя бы видимость водопадной последовательности применения практик, изображающая «непрерывный прогресс» без возвратов назад и повторений, была не так радикальна, как спиральное изображение жизненного цикла, поэтому полюбилась менеджерам и получила огромную популярность. V-диаграмма активно используется и сегодня.


  1. Forsberg, K., Mooz, H., 1991, "The Relationship of System Engineering to the Project Cycle", Chattanooga, Tennessee: Proceedings of the National Council for Systems Engineering (NCOSE) Conference, pp. 57--65., http://www.damiantgordon.com/Courses/ISE/Papers/The%20Relationship%20of%20System%20Engineering%20to%20the%20Project%20Cycle.pdf ↩︎

  2. https://incose-ru.livejournal.com/12765.html ↩︎