Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

Об управление жизненным циклом и об архитектуру

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

Моё понимание (которое я там и высказал) не выделяет особо "управление жизненным циклом" из системной инженерии. Все дисциплины системной инженерии нужны, все практики важны и связаны, а "управление жизненным циклом" не представляет из себя отдельной профессиональной дисциплины.

Очень смешно звучало несколько докладов, в которых центральным был термин PLM с многократным указанием, что "PLM не сводится к чисто IT-решениям". Сам факт, что "PLM -- это не IT" требуется указывать специально, означает встроенную в данный подход "управления жизненным циклом" проблему. Без рассмотрения в рамках системной инженерии PLM представляет собой произвольно выдергиваемое подмножество практик, инструментов, профессиональных позиций.

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

Это, вроде, просто -- но на самом деле очень сложно. Само определение функции (в некоторых школах слово "функция" вводится чуть ли не как синоним системы -- см., например, тут выражения типа function/system: http://15926.info/representing%20a%20system/index.htm), но само по себе инженерное употребление слова "функция" включает пять разных позиций (работы Andries van Renssen). Архитектура не обсуждается иначе, нежели через архитектурное описание, заключённое в набор различных архитектурных артефактов. Конструкция (структура, материал) -- не менее сложный объект. На всё это накладывается иерархия разбиения системы на элементы (на каждом уровне этой иерархии возникает пара "функция-конструкция" -- http://15926.info/functional-physical-object/index.htm). Тем самым функции и конструкция путаются, архитектура не документируется в каких-то оговоренных артефактах с нужным набором моделей, омонимы затрудняют понимание, а отсутствие инженерной рамки (инженерии архитектуры, создания набора архитектурных артефактов/рабочих продуктов) не позволяет обсуждать архитектурную деятельность.

А мы ещё не добрались до подробного обсуждения инженерии системной архитектуры, всё продолжаем разбираться с инженерией требований.
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 5 comments