Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

Практики жизненного цикла моделе-ориентированной инженерии - 2

Набросок списка дисциплин/практик (крупное верхнеуровневое деление обычно называют "дисциплинами", включая саму системную инженерию как целое, более мелкое -- "практиками". Не буду пока наводить должное занудство в этом вопросе) жизненного цикла моделеориентированной инженерии я сделал в http://ailev.livejournal.com/1023574.html. Вчера я прокомментировал этот список на 63 заседании Русского отделения INCOSE, что заняло первый час доклада (видео всего доклада -- http://incose-ru.livejournal.com/36265.html). Вот некоторые мысли из этого выступления:

1. Суть -- порождение из более абстрактных сущностей (моделей, веществ) более конкретных, при активном использовании справочных данных.

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

Моделеориентированная системная инженерия в качестве своей главной идеи берёт не столько "редактирование" человеком каких-то артефактов (как информационных -- из битов, так и физических -- из атомов), сколько автоматическую их компьютерную (станок или робот -- это просто компьютер с датчиками и эффекторами) генерацию из высокоуровневых моделей плюс справочных данных, иногда с добавлением вещества. В традиционной инженерии проектант "вручную" редактирует 3D модель, а слесарь тоже "вручную" как бы "редактирует" изготавливаемую деталь с использованием различных станков. В порождающем подходе это "редактирование" проводится компьютером: менее абстрактный артефакт генерируется компьютером (в случае вещества -- с добавлением эффекторов). Для этого компьютеру-выполнителю работы нужны две составляющих: более абстрактный артефакт и справочные данные (опять же, в случае выхода в реальность -- нужно ещё и вещество).

Этот переход от редактирования к полноценному порождению (генерированию) будет осуществляться постепенно, пошагово -- от редактирования на каждой мелкой стадии, через подробнейший диалог с компьютером к не очень подробному диалогу, похожему на взаимодействие с другим человеком.

Конечно, речь идёт о постепенном повышении степени интеллектуальности инженерных информационных систем (помним о http://ailev.livejournal.com/878210.html), при этом никаких слов "искусственный интеллект" говориться не будет, но это не должно мешать правильно понимать происходящее.

2. Разбиение дисциплин моделеориентированной системной инженерии

Дисциплины/практики системной инженерии бьются на две большие группы (более подробно о принципах такого деления -- http://praxos.livejournal.com/14905.html):
-- инженерные дисциплины, заключающиеся в работе с информационными моделями, а затем с физическими моделями и собственно частями системы и потом целой системой в сборе: принятие решений по фнукции и конструкции, выполнение трансформаций.
-- операционные дисциплины, или "управления", заключающиеся в грамотном движении объектов работы (как битов, так и атомов) по наличным выполнителям.

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

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

3. Акцент на "предпринятии предпринятий системной инженерии"

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

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

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

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

В моём списке дисциплин/практик моделеориентированной системной инженерии я отдельно и специально выделил практику работы со справочными данными (знаниями, которые формализованы в достаточном для компьютерной обработке виде, и использующимися в нескольких проектах -- подробнее в http://ailev.livejournal.com/1021613.html).

Древний стандарт практик системной инженерии ISO 15288 практически не учитывал этого. А вот OPF (http://www.opfro.org/) в явном виде уже учитывает переиспользование требований, архитектурных решений и т.д. из проекта в проект, и поэтому требует поддержку инженерами соответствующих библиотек справочных данных (хотя и использует при этом другую терминологию, и совсем не настаивает на доведении описания этих требований, архитектурных решений и т.д. до формального вида, готового к использованию в компьютере -- до вида справочных данных). Во всех дисциплинах моделеориентированной системной инженерии мы следуем линии OPF и явно рассматриваем способ, которым знание об инженерном state-of-the-art по Коэну (http://www.amazon.com/Discussion-Method-Conducting-Engineering-Technology/dp/0195155998/) привносится в проект, а также в явном виде эксплицируется и формализуется по итогам проекта.

Продолжение в http://ailev.livejournal.com/1026262.html
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 5 comments