Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

Проблемы моделеориентированной инженерии требований

Вчера состоялось двадцать третье заседание Русского отделения INCOSE, на котором мы обсуждали модели системной динамики (это делал vvagr) в контексте моделеориентированной инженерии требований (контекст делал я, регулярно изображая дисплей моделей URN) -- http://community.livejournal.com/incose_ru/13302.html. Видео и даже аудиозаписи нет, по совокупности причин.

Мои заметки с этого заседания:

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

Вывод: нужно срочно выбирать какой-нибудь метод (и связанные с ним инструменты) GORE и практиковать его совместно с мультимоделированием. Пока не увидят образцы работы (действий, а не только модели!), ничего не поймут. Нужно показать процесс, как работать с мультимоделью системы, моделью требований, моделью целей и прочими моделями (включая как имитационные, так и концептуальные) в ассортименте...

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

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

3. Если есть стейкхолдер, которому интересно получить ответ на свои вопросы из модели, он работает в режиме уточнения модели ("вы тут пропустили X, вы тут должны учесть НЭ). А если стейкхолдера, у которого к модели есть вопросы, нет, то у случайных зрителей возникает тьма тьмущая вопросов про то, "что вы хотите из этой модели извлечь, и почему у вас получится?".

Вывод: не забывать постоянно спрашивать "ты как кто задаешь вопрос/критикуешь? Какой вопрос должна задавать названная тобой позиция и для какого интереса?".

4. Модель как объект, который обеспечивает коммуникацию разных позиций (инженер, менеджер, финансист, эксплуатационщик и т.д.) вообще не понимается. В головах людей нет "заинтересованных сторон", а есть Заказчик. Концептуальный переход от Единого Заказчика к Множеству Заинтересованных Лиц происходит только в режиме чтения (учебников системной инженерии), а вот в режиме записи (действий для работы по проекту) происходит немедленный возврат к парадигме Заказчика и неважности обеспечения коммуникации заинтересованных сторон. Допускается, что модель отражает разную информацию, но почему-то не допускается, что она помогает проводить переговоры.

Вывод: нужно явно обозначать/называть/раскрывать парадигму с одним Заказчиком, ибо она "невидима" для застрявших в ней людей. И дальше маркировать связанные с ней рассуждения, чтобы тренировать собеседников. Работа со всеми заинтересованными сторонами вовсе неочевидна, люди привыкли к "одному начальнику/одному заказчику".

5. Я уже писал, что понимания разницы между имитационным и концептуальным моделированием почти ни у кого нет, "калибровка модели" почему-то воспринимается как обеспечение "истинности" (а не "полезности") модели. Путаница между моделями, теориями, программами моделирования, языками и т.д.

Вывод: нужна русскоязычная методологическая литература, издать учебник (переводной, ибо нет пророка в своем отечестве) и всех в него тыкать. Другое дело, что эта литература будет только про моделирование, а меня интересует вся триада:
-- программирование
-- моделирование
-- онтологизирование

Вот с этим -- засада. SIMULA67 -- это было первый объектно-ориентированный язык (http://progopedia.ru/dialect/simula-67/), но он позиционировался как язык моделирования. Про онтологии я вообще молчу, с этим путаницы еще больше -- но ISO 15926 используется, например, для интеграции данных (т.е. передачи моделей) CAD/PLM, и игнорировать онтологизирование нельзя.

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

6. Sphinxes -- ужасная программа для системной динамики. Она портит видеопамять, не отображается в dimdim.com, она падает с порчей файла модели и т.д..

Вывод: Поскольку все равно нужно пересаживаться на другую программу, будем пересаживаться сразу на Modelica -- и системную динамику, ежели нужно, пользовать в виде библиотеки Modelica.

7. Инженерия требований, даже моделеориентированная, оказывается много более СОЦИО-технической дисциплиной, чем это представляется. И в этом как раз западня: про ее социо-часть готовы рассуждать менеджеры, но не в связи с моделями и требованиями, а инженеры готовы обсуждать модели и требования, но не в связи с ее социо-частью.

Вывод: нужно четкое и явное выделение социо-части (методы, концепты, терминология предметной области и т.д.), чтобы ее можно было обсуждать. Сейчас же техническая часть обсуждается, а социо-часть должна быть "читаема между строк". Срочно сформулировать, в чем фишка этого "социо" в социо-техничности инженерии треований -- для этого подсесть на какую-то теоретическую базу (а ежели не обнаружится -- то создать её. Но наверняка обнаружится, если сделать не один случайный запрос к Гуглю, а "трижды забросить невод").
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 3 comments