Anatoly Levenchuk (ailev) wrote in incose_ru,
Anatoly Levenchuk
ailev
incose_ru

Categories:

Рабочая встреча по проблемам системной инженерии 25-28 марта 2010 (minutes)

25-28 марта 2010 в подмосковном пансионате "Бекасово" Русское отделение INCOSE провело Рабочую встречу по проблемам системной инженерии, на которой встретились члены отделения из Москвы, Санкт-Петербурга, Киева.

Видео и аудиозапись не велись.

На встрече были обсуждены множество проблемных для современной системной инженерии вопросов, в том числе:

1. Уточнение предмета (охвата, scope, набора практик/дисциплин). Именование разных системных инженеров (инженер-архитектор, инженер по требованиям/социотехник, инженер-организатор/психотехник, инженер по управлению конфигурацией). План-карта практик системной инженерии. PraxOS.

2. Практификация: каким образом осваивать практики системной инженерии в реальном производстве? Общность отношения к системной инженерии как к "интересной, но далёкой от жизни теории": с какого момента возникает понимание практичности? Почему Рабочая встреча массово привела к пониманию практичности? Можно ли "освоить" практику и поддерживающий ее софт, или нужно обязательно "разрабатывать" практику и поддерживающий ее софт для каждого применения (в духе ситуационной инженерии методов, требующей уточнения метода для применения в любой конкретной ситуации)?

3. Миссионерство системной инженерии: объяснение окружающим необходимости использования методов системной инженерии в реальных проектах. Готовность производств той или иной страны к освоению методов системной инженерии. Катакомбное (как у христиан в начальный период их катакомбного существования) сознание системной инженерии ("мы когда-нибудь победим во всем мире, но пока нас мало", даже когда СИ становится мейнстримом, как на Западе -- и объективно нельзя говорить, что "нас мало, и мы еще не победили"). Что нужно делать, чтобы люди узнали о существовании системной инженерии в России? Планы продвижения, например, курс с top-ами "телевизионной кулинарии"/"антимультик" (т.е. в редакторе, а не только результаты"), проход по всему жизненному циклу какой-то системы (пример: двухдневный курс Primavera для топов в PM Soft).

4. Словарь/глоссарий системной инженерии: один вариант русскоязычной лексики, или много? Целесообразность "доперевода" лексики "как в блоге Левенчука" на "еще более русский язык": чему это поможет? Необходимость раскрытия имеющихся переводов стандартов (решение проблемы с копирайтом).

5. Описание деятельности, ситуационная инженерия методов. Стандарты описания деятельности/ситуационной инженерии методов ISO 24744, SPEM 2, инициатива SEMAT. Использование EPF Composer при подготовке методических рекомендаций. Описание организации (распределения полномочий и ответственностей) в DEMO. Дополнение стандартов ситуационной инженерии методов метамоделями целей, обоснований, организации.

6. "Человеческий" аспект системной инженерии -- психотехника, социотехника. НЛП (нейролингвистическое программирование) в разных вариантах рассмотрения: а) особые виды моделей/моделирования (модели/моделирование на "языке" пяти чувств), использование в НЛП порождающих грамматик, как пример "необычной" моделеориентированной инженерии и б) метод подготовки инженера-организатора. Две группы описаний "организации" в СИ: а) "упаковывание индивидов в их социальные роли" aka "совмещение проектных функций и конструкции из индивидов" (как в СМДМ) б) распределение полномочий-ответственности по совершению транзакций (как в DEMO). Организационная инженерия (enterprise engineering).

7. Использование объект-ориентированного языка акаузального имитационного моделирования Modelica. Возможность использования подобного языка как в "порождающем" (generative, языки типа UML), так и в "имитационном" (simulation, типа SPSS) моделировании. Аналогичность программирования и моделирования. Стандартизация языка, множественность исполняющих сред (OpenModelica, Dymola, MathModelica, ModelicaML, MapleSim и т.д.). Социальные аспекты появления Modelica (консорциум, сообщество). Примеры технико-экономического моделирования. Использование внешних библиотек (например, код СОКРАТ атомной энергетики) с графическим редактором Modelica. Накопление модельного знания в виде отчуждаемых библиотек Modelica. Комплексирование Modelica и других языков моделирования (ModelicaML).

8. Онтологические, эпистемологические и логические (обоснования) аспекты системной инженерии. ISO 15926, отличие "языков моделирования" от "онтологических языков" (в онтологических языков возможен неоднократный переход от "классов" к экземплярам).

9. Интеграция данных. Архитектуры и среды интеграции данных. Использование САПР и PLM различных поставщиков.

10. Сервис-ориентированность, SOA (service-oriented architecture). Совместное определение описаний деятельности ("процессов") и информационных систем (компонент софта) через модели в терминах стандартов описания деятельности и модели в терминах стандартов SOA, связанных с использованием ISO 15926 (схема совмещения деятельности и IT). Декомпозиция на сервисы одной инструментальной системы, поддерживающей разные позиции (примере 6D проектирования в терминах "используемого софта" и "используемых сервисов"). Независимость описания потребностей в софте (сервисов) от реализации этого софта программными компонентами. Уход от диктата вендоров при описании софта не в терминах программ конкретных поставщиков и не в терминах модулей конкретных поставщиков.


11. Требования и цели, моделеориентированная инженерия требований (GORE, goal-oriented requirements engineering). Диаграмма моделеориентированной инженерии требований, специальности инженерии требований (инженер-организатор, инженер по требованиям). Жизненный цикл требований в моделеориентированной системной инженерии. Новое понимание требований (заинтересованные стороны и цели, а вот содержательные высказывания про систему -- в архитектурных вариантах, и тем самым в "требования" не попадают). Языки целей (например, URN, OMG BMM).

Необходимость переописания метода моделеориентированной инженерии требований с использованием подхода ситуационной инженерии методов.

12. Обоснования, основанные на логике. Языки обоснований (GSN: goal-strategy-solution, CAE: claim-argument-evidence). Роль логики в обоснованиях. Поддержка софтом. Связь с инженерией требований.

13. Карта целей и результатов Голдратта как синтез плана+целей+обоснований. Объединение разных типов моделей (ModelicaML, языки GORE и обоснований, ISO 15926), дополнение ISO 24744/SPEM метамоделями целей и обоснований, а также SOA. Возможность одновременного использования мультимодели и для исследования (имитационное моделирование), и для генерации (порождения) реализационных моделей. Архитектура софта для подобного мультимоделирования.

14. Управление конфигурацией (в том числе в случае моделей, отличие управления версиями в софте от того, что происходит в PLM). Алгоритмы распределенного управления конфигурацией, поколения управления конфигурацией (отличия SVS, SVN, git).

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

16. Управление проектами (логистика) как практика системной инженерии. Scope против processes в планировании проектов: верхние уровни scope, нижние -- процессы/практики. Откуда приходит информация в план: сметы? 3D? план более высокого уровня? Гранулярность планирования. Кто держит планирование (что делает генподрядчик? что подрядчик?). Кто проверяет факт (6 вариантов). LastPlanner и ролевые социопрактики (например, типы собраний и регламенты ролевого поведения). Рациональность управления буферами по Голдратту, онтологическая сущность буфера (нарисован "перпендикулярно графику"), невозможность моделирования буферов традиционным софтом проектного управления. Создание ППР (плана производства работ) -- снизу-вверх, сверху-вниз, 3D-анимация и ее роль. Связь "методики календарного планирования" и "методики визуализации" -- поддержка ролевых мероприятий соответствующими группами описаний. Необходимость описания потребного софта планирования+визуализации в терминах сервисов, чтобы сделать описание, независимое от использования программ конкретного поставщика.

17. Системная инженерия на макроорганизационном уровне: общественные институты, социальная инженерия, их возможность и этичность.

Subscribe

  • Post a new comment

    Error

    Comments allowed for members only

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 0 comments