Обсуждение

Оффтоп В статье "Towards a Systems Engineering Essence" есть "Figure 2: V-diagram expressed in Essence Language" Считаю что она некорректна. 1. Она некрасивая. "Натягивание совы на глобус". 2. Она содержит альфы, которых в стандарте нет. 3. Не содержит частей, которые есть на диаграмме (полочка System Operation) 4. Несовпадение типов сущностей. V-диаграмма показывает процесс во времени слева направо по фазам/этапам. Кода одна начинается, предыдущая заканчивается. Альфы же (кроме целевой системы) существуют на всем протяжении проекта. Их нельзя расставить последовательно во времени. 5. Для V-диаграммы есть отличные кандидаты в самом стандарте - "кораблики" из области Solution: Изображение — открыть источник

Вы как-то заметили, что Essence написан на довольно низкоуровневом языке, чтобы программные инженеры поняли, а по хорошему там нужно формулировать онтологически. Вы не думали написать Essence для системной инженерии в онтологическом ключе? Системных инженеров онтологиями не напугаешь, а программные глядя тоже подтянутся может быть.

Да, мы сделали много подходов к этой задаче, но там есть существенные препятствия: альфы некоторые tangible, а некоторые intangible -- Essence допускает существование какого-то типа объектов, который бывает иногда классом (мыслью), а иногда индивидом (физической вещью). В онтологиях такого не допускается обычно. Ну, и там ещё много других нюансов того же рода. Так что для онтологически строгого изложения Essence для начала нужно стандарт поменять.

1. Мне наоборот, эта диграмма кажется красивой -- тут, как говорится, "на вкус и цвет". Очень хорошо получилось. Это фрагмент графа, на который наложили форму V. 2. Конечно, она содержит эти альфы, которых в стандарте нет. Работа две альфы стандарта меняет (это главное предложение работы), а остальные стандартным образом вводит (стандарт предусматривает расширение числа альф по потребности). 3. Полочка operations в V-диаграмме отнюдь не всегда показывается. Хотя я сам обычно её люблю показывать, но это скорее исключение чем правило. 4. По классике V-диаграмма не строго соответствует последовательному выполнению работ, она считается часто "логической" и используется также для описания работ в ходе concurrent engineering. Так что тут у меня всё то же самое: "логическое" время (впрочем, на этой конкретной диаграмме меня больше волновали основные рабочие продукты, на которых центрируются практики, поминаемые в V-диаграмме). 5. Я намеренно не касался activity space вообще и процессного представления. Тем более что тамошние "кораблики" совсем не системноинженерные, там главного архитектурного кораблика нетути (на основании того, что отнюдь не все софтверные проекты явно работают с архитектурой. А в системной инженерии все проекты явно работают с архитектурой, иначе это не системная инженерия -- и это нужно выражать).

1. Она только запутывает и ничего не проясняет. На фоне стройных и простых диаграмм Essence она выглядит совершенно чужеродной. В ней столько несуразностей и ошибок, что самое простое - считать ее всю одной ошибкой. 2. Например, Part никак не может быть Abstract Level Progress Health Attribute. Она никак не relevant to an assessment of the progress and health of the endeavor. Если такой прокол в основах (pun intended), о чем можно вообще говорить? 5. "Тем более что тамошние "кораблики" совсем не системноинженерные". Конечно. Я же дал ссылку на activity spaces программного Essence. Системноинженерного варианта нет в природе. Но именно элементы из этого класса наилушим образом располагаются на V-диаграмме и такое их расположение дает ага-эффект.

Скорее всего Essence его авторы сами переизлагать не будут и побудить их к онтопереписыванию вряд ли получится. Так что похоже остается лишь способ при создании системноинженерного варианта внося системноинженерные изменения вносить также и изменения, которые позволят формулировать его онтологически строго.