Источник: OMG Essence

• Границы системной инженерии размыты (пересекается с инженерией систем управления, программных продуктов, даже с инженерией предприятия) из-за широкого спектра рассматриваемых систем.
• Стандартизация - один из источников кросс-доменного инженерного знания.

Как описывать системную инженерию

Терминология и онтология

• Разница между “сообществами по языку” (speech communities, используют одни и те же слова) и “сообществами по семантике” (semantic communities, используют одни и те же концепты, вне зависимости от используемых слов). Проработать связь с Единый язык в разработке ПО.
• “Онтология - это формальная спецификация общей концептуализации” (Gruber, T. 1995¹). Иначе говоря, это стандарт для используемого языка, позволяющий совместить границы сообществ по языку и по семантике. В целом, онтология для предметной области должна быть “не слишком проработанной” (underspecified), чтобы быть полезной (вероятно, из-за наличия “пространства для маневра” при приложении к конкретным ситуациям). Важно найти тот самый “полезный” уроввень общности для онтологии какой-либо предметной области.

Теория системной инженерии

• Любая теория оперирует объектами ментального пространства, идеальными объектами, не существующими непосредственно в физическом мире, но частично соотносящими с объектами физического пространства.
• Язык Essence использует термин Альфы (Alphas) для репрезентации объектов ментального пространства и Продукты труда (возможно, лучше Артефакты? Work Products) для репрезентации объектов физического пространства. Сам стандарт описывает Альфы как индикаторы здоровья и прогресса в важных для проекта областях. Поэтому для каждой Альфы определен набор состояний, для каждого состояния определен чек-лист, позволяющий понять, находится ли Альфа в нем.
• Альфа - это акроним Abstract-Level Progress Health Attribute

Ситуационная разработка метода

• Методы работают только для тех ситуаций, для которых они были разработаны. Понимание этого ограничения позволило продвинуться в направлении стандартизации “переиспользуемых” компонентов методов и разработки языка этих компонентов, не зависимого от конкретного проекта / ситуации.
• OMG Essence - это первый из ситуационных стандартов второго поколения (чем оно отличается от первого?), который определяет дисциплину “разработки ПО” на теоретической основе (то есть опираясь на объекты ментального пространства, Альфы)

Альфы на уровне “Решений”

Разница между системной инженерией и инженерией ПО

• Инженерия ПО - это частный случай системной инженерии, поэтому терминология OMG Essence “как есть” не подходит для обобщенного описания системной инженерии. На уровне “Решений” необходимо заменить Альфы “Требования” и “ПО” на “Описание системы” и “Воплощение системы” соответственно.

V-диаграмма

• Отличная диаграмма, разделяющая этапы жизненного цикла системы на “Определение” и “Реализацию”, плюс показывающая отношения проверки (валидации и верификации) между отдельными этапами.
• Во время “Определения” мы оперируем “битами”, объектами из ментального пространства. Во время “Реализации” работаем с “атомами”, объектами физического пространства.
• Основной эвристический принцип системной инженерии заключается в сдвиге работы в фазу “Определение”, чтобы устранить возможные ошибки как можно раньше, потому что абстрактными “битами” манипулировать проще, чем конкретными “атомами”
• В чем разница между валидацией и верификацией?
• Под-альфы используются для демонстрации практик валидации и верификации. “Нужды Пользователей (Stakeholder/User needs)” - под-альфа “Возможности”; “Требования”, “Архитектура” и “Неархитектурный дизайн” - под-альфы “Описания системы”.
• Нужды пользователей описывают как черный ящик Использующую систему, которая включает разрабатываемую систему и системы в ее операционном окружении. Валидация тут заключается в том, что Использующая система удовлетворяет нужды Пользователей
• Требования определяют разрабатываемую систему как черный ящик, включающий подсистемы. Верификация в том, что разрабатываемая система удовлетворяет требованиям
• Архитектура описывает разрабатываемую систему как прозрачный ящик с подсистемами. Верификация - подсистемы вписываются в архитектуру.
• Валидация проходит для более масштабной использующей системы, включающей в себя “Воплощение системы”
• Верификация проходит для “Воплощения системы”