Анатолий Левенчук - Системное мышление

Как пользоваться постоянно раздувающимся списком подальф с их контрольными вопросами для прохождения контрольных точек может помочь практик работы с чеклистами, описанная в книге Атула Гаванде «Чеклист. Как избежать глупых ошибок, ведущих к фатальным последствиям». 204 204 https://www.ozon.ru/context/detail/id/26845885/

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

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

Горбатая диаграмма, использовавшаяся в RUP, получила своё развитие: в более современных версиях (например, из enterprise unified process, EUP, 2013) приводится другой набор практик и другой (полный, а не только стадии разработки и перехода к эксплуатации) набор стадий 205 205 http://enterpriseunifiedprocess.com/ :

Интересно, что и тут есть трудности – попытка изобразить то, что происходит до момента запуска проекта как последовательности стадий работ, но в жизненный цикл попадает.

Стандарт OMG Essence предложил ещё один вид жизненного цикла, удобный для отслеживания смены состояний основных альф. Это представление похоже на «горбатую диаграмму», использовавшуюся в EUP, только вместо практик там указаны задающие тематику работ альфы (а практики подразумеваются те, которые будут работать с этими альфами и их рабочими продуктами):

Как и любые диаграммы видов жизненного цикла, диаграммы OMG Essence – огромное упрощение. Так, в этих диаграммах не отражены подальфы, которые тоже меняют свои состояния асинхронно. На диаграммах также не отражено то, что в жизни мы наблюдаем не альфы непосредственно, но судим об их состоянии по рабочим продуктам. Более того, от этих диаграмм остаётся впечатление того, что проект может быть устроен «водопадным» образом, а это не так. Во-первых, альфы совершенно необязательно меняют своё состояние строго поступательно: нет, в них в ходе проекта возможны (и обычно происходят) откаты назад, включая и состояния их подальф. Во-вторых, мы показали тут только намеренно упрощённую последовательность прохождения состояний, а ведь состояния альфы могут представлять собой произвольный граф, включая циклы в этом графе.

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

Иногда последовательность смены состояний альфы «технология» выделяют как отдельную модель зрелости(maturity model). Модель зрелости иногда путают с жизненным циклом практик, но чаще всего практика уже есть, и речь идёт только о том, чтобы эта внешняя по отношению к организации практика превратилась в оргвозможность (capability) данной организации, могла быть задействована в работах различных предпринятий в данной организации – модель зрелости тем самым не жизненный цикл практики, а жизненный цикл проекта освоения практики.

Например, для ISO 15288 (стандарта практик жизненного цикла системной инженерии) штатно предполагается использование модели зрелостей из ISO 1504 (стандарт проверки соответствия используемых практик описанным международными стандартами практик). Соответствие предполагает некоторые уровни, и вот эти уровни и есть «модель зрелости» (maturity model). Модели зрелости часто изображаются в виде «ступенек», по которым нужно «идти вверх»:

Модели готовности технологий(technology readiness) затрагивают как раз предыдущие по отношению стадиям модели зрелости группе стадий жизненного цикла технологии: о разработке. Например, Technology Readiness Level, разработанная 35 лет назад для аэрокосмоса, а затем распространившаяся в машиностроении нефтегазовой промышленности, где ступеньки-уровни для технологии ближе к классическому жизненному циклу в варианте 1.0, только речь идёт именно об инструментарии, «технологии» 206 206 http://www.atominfo.ru/newsp/w0965.htm :

• TRL 1. Сформулирована фундаментальная концепция технологии и обоснование её полезности.

• TRL 2. Определены целевые области применения технологии и её критические элементы.

• TRL 3. Получен макетный образец и продемонстрированы его ключевые характеристики.

• TRL 4. Получен лабораторный образец, подготовлен лабораторный стенд, проведены испытания базовых функций связи с другими элементами системы.

• TRL 5. Изготовлен и испытан экспериментальный образец в реальном масштабе по полупромышленной технологии, проведена эмуляция основных внешних условий.

• TRL 6. Изготовлен полнофункциональный образец на пилотной производственной линии, подтверждены рабочие характеристики в условиях, приближенных к реальности.

• TRL 7. Прототип системы продемонстрирован в составе системы в реальных условиях эксплуатации.

• TRL 8. Окончательное подтверждение работоспособности образца. Разработка. функционирующей реальной системы завершена.

• TRL 9. Изделие удовлетворяет всем требованиям: инженерным, производственным, эксплуатационным, по качеству и надёжности. Возможна модификация по снижению себестоимости, развитию и эволюции системы. Функционирующая реальная система подтверждена в ходе реальной эксплуатации через успешное выполнение испытательных заданий.

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