OSS / Системноинженерное мышление в управлении жизненным циклом(2014)

Это простейший вид: одномерная "колбаска", стадии которой не перекрываются друг с другом.

Гейты и вехи

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

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

Гейты характеризуются:

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

●проведением испытаний, проверкой инженерных обоснований (в том числе с привлечением независимых экспертов)

●Принятием осознанного решения "Go -- No Go -- Cancel" (пройти на следующую стадию жизненного цикла -- вернуться и доработать -- прекратить проект в целом). Если риск продолжения проекта приемлемый, то идём на следующую стадию. Если риск высок, то возвращаемся на доработку, снижающую риск. Если риск очень высок и доработка вряд ли поможет его снизить, то проект закрывается, жизненный цикл системы прекращается.

Desicion gate -- это развилка в проекте, имеющая дело прежде всего с оценкой рисков его продолжения, и это нельзя забывать.

Обычно решение "Go" означает принятие решения по дальнейшему финансированию проекта (даже если деньги гарантированно были выделены на прохождение нескольких стадий жизненного цикла, в гейтах это выделение ресурсов пересматривается -- проходит commitment review). Одна из методик управления жизненным циклом так и называется -- ICM, incremental commitment model (пошаговое выделение ресурсов). Подробней см. http://ailev.livejournal.com/691464.htmlВехи -- это просто дополнительные точки контроля, на которых проверяется выполнение графика работ, но не ожидается принятие решений "Go-NoGo-Cancel".

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

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

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

Рабочие продукты для определения жизненного цикла

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

Вот пример диаграммы жизненного цикла, используемого консорциумом FIATECH в качестве roadmap (долгосрочного плана работ) по развитию отрасли капиталоёмких проектов (capital projects -- строительство заводов, инфраструктурных сооружений типа мостов и эстакад и т.д.), эта диаграмма жизненного цикла разработана в 2004г:

Обратите внимание на то, что наименования части стадий даются по именам практик (отглагольные существительные), а часть по состояниям целевой системы на этой стадии. Кроме этого авторы диаграммы вынуждены были показать практики (управление проектом, управление данными) и ресурсы (новые материалы, рабочая сила и т.д.), которые должны быть использованы на всём протяжении жизненного цикла. Различные передачи рабочих продуктов (hand over) показаны стрелками, но и природа этих стрелок различна (так, "обратная связь от опыта и знаний" относится вообще к разным системам из разных проектов: когда объект уже построен, сценарное планирование будет вестись уже для другого проекта). Очевидно, что для составления этой диаграммы не было использовано никакого метода описания жизненного цикла, но сама идея для рассказа о какой-то сложной деятельности иметь в основе жизненный цикл целевой системы этой деятельности -- это правильная и продуктивная идея.

Информационные системы управления жизненным циклом

Информационные системы управления жизненным циклом (PLM, product life cycle management) по факту поддерживают не полный жизненный цикл, а главным

образом стадию проектирования. Хотя часто пытаются говорить о PLM как product life cycle management (практике управления жизненным циклом изделия/продукта/установки/сложного инженерного объекта/системы), аббревиатура PLM чаще всего используется для указания на вид инженерных информационных систем, выполняющих следующие функции:

●Управление конфигурацией инженерной системы на стадии архитектурного проектирования (хранилище информации проекта -- PDM, product data management). Самые различные (механические, электрические, технологические и т.д.) САПР и системы инженерных расчётов работают со связанными между собой моделями в этом хранилище. Хранилище поддерживает версионирование моделей.

●Управление изменениями (отслеживание дел, главным образом запросов на изменение проекта/design), наиболее часто в виде issue tracker

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

PDM.

Вот информационные системы в жизненном цикле мотора, появляющегося в инженерном проекте:

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

содержится в ERP-системе. Закупленный мотор-модуль монтируется, и становится "установленным оборудованием". Информация о нём (индивидуальный журнал для конкретного мотора с серийным номером, куда попадают записи о поломках, техобслуживании и т.д.) теперь находится в EAM системе (Enterprise asset management), используемой службой эксплуатации.

Управление информацией/данными жизненного цикла

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

На практике это означает, что информация по мотору из предыдущего раздела будет перевведена руками в среднем 7 раз за время проекта. Это медленно, при этом вносятся ошибки, и это очень дорого (ибо работают не компьютеры, а люди). Ситуация осложняется и тем, что PLM, ERP, EAM системы часто находятся в разных организациях, ответственных за разные стадии жизненного цикла целевой системы (например, атомной станции или судна-контейнеровоза, куда должен быть установлен мотор из примера).

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

Вот пример модели данных (онтологии), отображающей жизненный цикл трубопроводной задвижки (Control Valve), описываемый примерно так, как описывался жизненный цикл мотора из предыдущего раздела. Это описание использует метод описания из ISO 15926:

Обратите внимание, что часть отношений между сущностями этой модели данных проходит через границы информационных систем, работающих на разных стадиях жизненного цикла установки (plant) -- и значительная часть таких отношений будут отношениями Temporal Whole Part. (четырехмерный объект является временнОй частью четырехмерного объекта целиком, например, установленная, т.е.in service задвижка с серийным номером #5628 является в целом временнОй частью компоненты-задвижки P101 на установке XYZ и временнОй частью модуля Siemence Control Valve 023). Именно потому, что приходится работать со временем в условиях, когда описание одного и того же объекта в ходе жизненного цикла меняется разительно, стандарт ISO 15926 использует онтологию 4D экстенсионализма -- система представляется не только в её уровнях декомпозиции, не только как совмещение разных объектов, которыми оперируют разные стейкхолдеры, но и как совокупность всех её состояний в ходе жизненного цикла. Моделирование инженерных данных должно это отражать.

Практики жизненного цикла

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

Учёт распределения практик жизненного цикла во времени возможен, если от "колбаски" жизненного цикла перейти к двумерным группам описания.

V-диаграмма

Самая знаменитая диаграмма жизненного цикла (да и всей системной инженерии) -- это V-диаграмма. Иногда её называют V-model, поскольку рассматривают и как вариант вида жизненного цикла "водопадного" жёсткого стиля -- просто "каскад" перегнут в точке "изготовления" (перехода от стадий определения системы к стадиям реализации системы).

Именно V-диаграмма используется чаще всего, чтобы пояснять самые общие черты системноинженерного процесса/метода/жизненного цикла:

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

●Соответствие определений и воплощений системы, поддерживаемое через проверки (верификация) и приёмки (валидация)

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

●Разницу между системноинженерными практиками (выше пунктирной линии), имеющими дело с системой в целом и "обычными" инженерными практиками, имеющие дело с частями системы.

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

Эта простейшая диаграмма имеет огромное число вариаций и модификаций

(например, см. http://en.wikipedia.org/wiki/Dual_Vee_Model).

Горбатая диаграмма

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