Симултрек = архитектурный фреймворк (обеспечивающих) предприятий системной инженерии
СУТИ (система управления технической информацией, integrated repository, engineering content management system) -- программно-аппаратный комплекс , обеспечивающий учет информации о целевой системе (модель продукта), ее жизненном цикле (модель жизненного цикла), а также об обеспечивающих системах (организационная модель).
Информация -- это набор фактов.
Учет информации -- процедуры сбора и хранения фактов, а также процессов доступа к фактам.
Модель -- информация (набор фактов), используемая стейкхолдерами для удовлетворения своих интересов.
Стейкхолдер (stakeholder) -- физическое лицо или организация, которые имеют право, долю, притязания или выгоду в системе или обладанию системой характеристиками, которые удовлетворяют их нуждам и ожиданиям (individual or organization having a right, share, claim, or interest in a system or in its possession of characteristics that meet their needs and expectations).
Интерес (concern) -- конкретные озабоченности, которые имеет стейкхолдер по поводу каких-то аспектов целевой или обеспечивающих систем.
СУТИ организован так, чтобы поддерживать Симултрек. Изначально слово "симултрек" (simultrack) использовалось в спортивныхпередачах, чтобы описать трансляцию одновременно со многих камер,установленных вокруг спортивной арены -- так, чтобы режиссер всегда могвыбрать самый лучший ракурс (в современных системах спортивныхтрансляций выбирать между камерами могут и сами зрители). Дальше это слово стало использоваться в тех случаях, когда нужно отразить учетмножества точек зрения на один и тот же объект.
Симултрек (architectural framework, viewpoint library) -- это набор вьюпойнтов ("точек зрения") на связанные модели целевой системы и обеспечивающих систем. Симултрек тем самым представляет собой архитектурный фреймворк предприятий системной инженерии (обеспечивающих систем), предоставляющих ресурсы для осуществления жизненного цикла целевой системы.
Вьюпойнт (viewpoint) -- это "точка зрения", набор нотаций и инструментальных средств (приложений, обеспечивающих вывод диаграмм), которые удобно представляют факты Модели, соответствующие каким-то интересам (concerns) стейкхолдера.
Состав Симултрека (набор вьюпойнтов) определяет средства представления (репрезентации) следующих наборов фактов:
1. Модель продукта (целевой системы)
1.1. Модель функций -- как функциональные требования, "поведение", так и процессы (потоки жидкостей, балансы материалов, энергии и т.д.).
1.2. Модель конструкции (физических объектов).
1.3. Архитектурное описание (связывающее функции и конструкцию).
2. Модель проекта (обеспечивающих предприятий)
2.1. Модель жизненного цикла -- процессы системной инженерии, выполняемые обеспечивающими системами. Выполнение этих процессов и является жизненным циклом целевой системы (продукта).
2.2. Модель организации жизненного цикла (Конструкционные модели DEMO: роли акторов, транзакции, координационные факты, продукционные факты. Модели функции: целевые показатели).
2.3. Модель ресурсов жизненного цикла (людей и оборудования, необходимых для осуществления жизненного цикла целевой системы, даталогические модели для коммуникации, состав программ и оборудования СУТИ и т.д.).
Каждый из вьюпойнтов подразумевает представление (репрезентацию) трех типов фактов:
-- знания, выражаемые фактами (отношениями) типа "может быть" и "может иметь", подразумевающие, что конкретное значение для конкретного объекта будет подставлено.
-- требования, выражаемые фактами (отношениями) типа "должен быть" и "должен иметь".
-- о конкретных вещах, идеальных (дизайны) или реальных (оборудование, сооружения, проекты), выражаемых фактами (отношениями) типа "является" и "имеет".
Интегрированные данные Симултрека (integrated dataset) -- общий набор учтенных связанных фактов различных моделей, соответствующих вьюпойнтам Симултрека и находящихся в СУТИ предприятий, предоставляющих ресурсы жизненного цикла.
* * *
Конечно, все это еще чистить и чистить, но лиха беда начало. Стандартные Enterprise Architecture Frameworks не подходят, а нужно было сделать что-то в этом роде. Еще требовалось привязать все модели к стандартному делению на Facility Model (Product Model) и Project Model, и при этом учесть труды Dietz по архитектурным фреймворкам и организационной онтологии, а также жестко указать на использование онтологии фактов. Пока удалось даже обойти сколькзий вопрос про "расширенное предприятие", но не удалось обойтись без понятия "учет" (которое мало кем понимается, но у Диеца это вообще раскрывается через "ведение банков фактов о состоянии мира координации и мира производства", так что можно будет пробовать прорваться).
Информация -- это набор фактов.
Учет информации -- процедуры сбора и хранения фактов, а также процессов доступа к фактам.
Модель -- информация (набор фактов), используемая стейкхолдерами для удовлетворения своих интересов.
Стейкхолдер (stakeholder) -- физическое лицо или организация, которые имеют право, долю, притязания или выгоду в системе или обладанию системой характеристиками, которые удовлетворяют их нуждам и ожиданиям (individual or organization having a right, share, claim, or interest in a system or in its possession of characteristics that meet their needs and expectations).
Интерес (concern) -- конкретные озабоченности, которые имеет стейкхолдер по поводу каких-то аспектов целевой или обеспечивающих систем.
СУТИ организован так, чтобы поддерживать Симултрек. Изначально слово "симултрек" (simultrack) использовалось в спортивныхпередачах, чтобы описать трансляцию одновременно со многих камер,установленных вокруг спортивной арены -- так, чтобы режиссер всегда могвыбрать самый лучший ракурс (в современных системах спортивныхтрансляций выбирать между камерами могут и сами зрители). Дальше это слово стало использоваться в тех случаях, когда нужно отразить учетмножества точек зрения на один и тот же объект.
Симултрек (architectural framework, viewpoint library) -- это набор вьюпойнтов ("точек зрения") на связанные модели целевой системы и обеспечивающих систем. Симултрек тем самым представляет собой архитектурный фреймворк предприятий системной инженерии (обеспечивающих систем), предоставляющих ресурсы для осуществления жизненного цикла целевой системы.
Вьюпойнт (viewpoint) -- это "точка зрения", набор нотаций и инструментальных средств (приложений, обеспечивающих вывод диаграмм), которые удобно представляют факты Модели, соответствующие каким-то интересам (concerns) стейкхолдера.
Состав Симултрека (набор вьюпойнтов) определяет средства представления (репрезентации) следующих наборов фактов:
1. Модель продукта (целевой системы)
1.1. Модель функций -- как функциональные требования, "поведение", так и процессы (потоки жидкостей, балансы материалов, энергии и т.д.).
1.2. Модель конструкции (физических объектов).
1.3. Архитектурное описание (связывающее функции и конструкцию).
2. Модель проекта (обеспечивающих предприятий)
2.1. Модель жизненного цикла -- процессы системной инженерии, выполняемые обеспечивающими системами. Выполнение этих процессов и является жизненным циклом целевой системы (продукта).
2.2. Модель организации жизненного цикла (Конструкционные модели DEMO: роли акторов, транзакции, координационные факты, продукционные факты. Модели функции: целевые показатели).
2.3. Модель ресурсов жизненного цикла (людей и оборудования, необходимых для осуществления жизненного цикла целевой системы, даталогические модели для коммуникации, состав программ и оборудования СУТИ и т.д.).
Каждый из вьюпойнтов подразумевает представление (репрезентацию) трех типов фактов:
-- знания, выражаемые фактами (отношениями) типа "может быть" и "может иметь", подразумевающие, что конкретное значение для конкретного объекта будет подставлено.
-- требования, выражаемые фактами (отношениями) типа "должен быть" и "должен иметь".
-- о конкретных вещах, идеальных (дизайны) или реальных (оборудование, сооружения, проекты), выражаемых фактами (отношениями) типа "является" и "имеет".
Интегрированные данные Симултрека (integrated dataset) -- общий набор учтенных связанных фактов различных моделей, соответствующих вьюпойнтам Симултрека и находящихся в СУТИ предприятий, предоставляющих ресурсы жизненного цикла.
* * *
Конечно, все это еще чистить и чистить, но лиха беда начало. Стандартные Enterprise Architecture Frameworks не подходят, а нужно было сделать что-то в этом роде. Еще требовалось привязать все модели к стандартному делению на Facility Model (Product Model) и Project Model, и при этом учесть труды Dietz по архитектурным фреймворкам и организационной онтологии, а также жестко указать на использование онтологии фактов. Пока удалось даже обойти сколькзий вопрос про "расширенное предприятие", но не удалось обойтись без понятия "учет" (которое мало кем понимается, но у Диеца это вообще раскрывается через "ведение банков фактов о состоянии мира координации и мира производства", так что можно будет пробовать прорваться).