Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

И не жизненный, и не цикл, а обеспечивающая система как набор разворачивающихся во времени практик

Разбирательство с жизненным циклом будет на моём тренинге в воскресенье (http://nisse.ru/actual/events/?ELEMENT_ID=131138), а сегодня у меня день подготовки -- я пытаюсь заново сформулировать идею жизненного цикла, компактифицировать ненышнее распылённое и пушистое знание, выполнить онтологическую работу. Без всякого глубокого обучения, исключительно собственными мозгами.

Судя по литературе, а особенно новым стандартам, буквально за десяток лет понятие "жизненный цикл системы" существенно изменилось. Главная интрига там была в отходе от традиционного процессного/проектного/модульного/физического подхода к жизненному циклу к компонентному/функциональному/логическому. В итоге сегодня наблюдается смесь обоих подходов -- вроде и как от "последовательности стадий разных состояний целевой системы как этапов долгого пути" (стадия=этапу проекта, как в проектном управлении) полностью не ушли, и полностью не пришли к "набору практик обеспечивающей системы и их взаимосвязей, как необходимого деятельностного разнообразия" (по ISO 24744 стадии определяются через change of mental framework, по факту -- сменой ведущей дисциплины, сменой ведущей практики данной стадии).

Вот все и мучаются: "вывод из эксплуатации" -- это стадия/этап (совпадающая с этапом проекта из проектного управления) или стадия/практика (совпадающая с практикой из учебника, mental framework)?!

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

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

В архитектурных языках это тоже поддержано. Так, в архимейте есть практики (business function), а есть процессы (business process). Жизненные циклы и их стадии рисуются через практики, а процессы/проекты и их шаги/этапы через процессы. Функциональное против модульного.

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

Вид жизненного цикла -- это примерно как вид архитектуры: ряд принятых по поводу практик и их связи решений самого верхнего уровня. Например, "все практики будут выполняться последовательно во времени -- каскадом", или "у нас будут использоваться практики из арсенала agile, и никакого каскада -- во времени это будут итерации". После чего проектные/процессные/кейс-менеджеры обеспечивают реализацию этих принципов для обеспечивающей системы примерно так же, как конструкторы или проектанты обеспечивают своими модулями выполнение принципов, заложенных в компонентную принципиальную/технологическую схему целевой системы.

Это всё про само понятие жизненного цикла и определение его вида.

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

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

Бонус тут -- это рассмотрение практик и работ/задач в 4D. Те же функциональные и физические/конструктивные объекты, компоненты и модули обеспечивающей системы, только имеющие протяжённость во времени.

Другие методы описания обеспечивающей системы (например, организация -- кто за какую практику-компоненту или кто за какую задачу-модуль ответственный) тоже вполне имеют право на существование. В целевой системе есть ещё и места, где живут её модули. В обеспечивающей системе, представляемой как набор практик и работ (два разных метода описания), практики (работы называются по имени практики, как системы называются по имени компоненты) живут в организованных агентах и их инструментах. Организованных -- это с распределением ответственностей и полномочий по распоряжению друг другом в части выполнения работ. Конечно, нужно учитывать и этот метод описания, этот организационный интерес. Нельзя считать, что достаточно определить вид жизненного цикла, и наладить управление жизненным циклом. Нет, нужно ещё организоваться. И эти три разных интереса, три разных метода описания (жизненный цикл, проект/процесс/кейс, организация) далеко не единственные для обеспечивающей системы -- просто с них всегда начинают.
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 1 comment