Системное мышление 2019 Левенчук Анатолий
В случае железа реактора и труб всё тут очевидно: вероятность выпуска чистого диметилфторидметилхлорпентилбензолтитана в этой ситуации равна нулю. Но в случае софта почему-то кажется, что задачу так решать можно. И вот пишут про «сервера» и «базы данных», но каким образом там будет происходить обработка какой информации, и с чего бы эта обработка вдруг оказалась даже не лучше конкурентов, а вообще возможной, этого вопроса не возникает. Ровно как в предыдущей задаче, где нет химика, есть только сварщики и спецы по корпусам высокого давления. Они точно сделают софтверный «универсальный реактор», но вот что там с чистотой «информационного вещества» или даже просто запуском нужной «информационной реакции» (слова «обработка информации» или «расчёт» так и пишутся, без малейших уточнений, какой именно), и получить исходные данные (или исходную информацию? данные! ибо информация что-то означает, а данные тут как сырьё – можно игнорировать их содержание) – это не к ним. А поскольку в проекте получения чистого диметилфторидметилхлорпентилбензолтитана химика пока нет, про химию разговор поддержать некому, равно как сообразить, как же эта химия влияет на примеси, а примеси на здоровье пациента. За разговорами про реакторы и трубы к этому моменту уже можно забыть, что задачка про медицину, потребности тут в здоровье пациента. А делать приходится железную конструкцию. И нужно протянуть строгую логическую цепочку от одного к другому – через химические реакции, которые описывают функциональную структуру целевой системы, через ведущие к появлению вредных примесей отклонения от режимов проведения этих реакций. При этом предметная область функциональных (химических) рассмотрений – по факту клиентская, а итоговые модульные (труб и реакторов) рассмотрения – предметная область разработчика-контрактора.
Увы, с первого раза получить функциональную диаграмму, в которой рассказывается о том, что содержательно происходит с клиентской информацией в корпоративных информационных системах, обычно не удаётся. Нужна пара-тройка итераций, но зато после её получения уже вполне осмысленно и существенно корректируется уже модульная диаграмма (в случае нашего «железного примера» – изменяется число реакторов, убираются лишние трубы, проводятся дополнительные исследования по наличию на рынке дешёвых датчиков чистоты продукта, находится контрактор, который пишет управляющий софт для закрытия-открытия задвижек на реакторах, чтобы управлять ходом синтеза на основе показаний датчиков и т.д.).
Потом нужно будет рассмотреть и модули, и размещения. Но это всё потом. Сначала же нужно разобраться с функционированием: что происходит в тот момент, когда система работает/функционирует (слово «функционирует» тут не случайно!), а не когда её собирают из размещаемых где-то частей-модулей.
Это рассуждение про необходимость начального рассмотрения функций приложимо к любым создаваемым людьми конструкциям: сначала нужно обсудить подробно, зачем эти конструкции и как они будут работать, а уже потом рассматривать, из чего они будут собраны. Например, можно рассмотреть применение этих рассуждений к танцам. Просто махание ногами и руками (с запасом! Побольше махов, и сами махи пошире!) никого не устроит. Каждый мах должен быть понятен, зачем – какая там эмоция, что этим махом хотят сказать, что продемонстрировать. Тогда и мах будет подобран соответствующий (резкий, плавный, объёмный или короткий, рукой или ногой – ровно под необходимую функцию, а не «стандартный»).
Мыслить только про конструкции нельзя. Отсутствие мышления о функциональности нужно как-то осознавать и исправлять. А это отсутствие мышления о функциональности заметно только в случае наличия системного мышления – оно позволяет заметить то, о чём вы забыли подумать, управляет вашим вниманием.
Предпринятия
В системах из людей модули – это прежде всего сами люди, с их аудио, зрительным, тактильным и прочими интерфейсами. Обратите внимание, что функции людей даже не делается попыток обсуждать, равно как и смысл и содержание информации или изменений окружающей среды, которое поступает к людям и уходит от них через интерфейсы.
Следующий уровень – это команды и прочие организационные звенья (в предприятиях – подразделения), получаемые из организованных (то есть с понятными полномочиями по использованию труда друг друга и других ресурсов) людей. Сервисы команд, сервисы подразделений, оказываемые ими на их интерфейсах, обсуждение интерфейсов-каналов для общения с ними являются типичным предметом обсуждения, сервисы пытаются стандартизовать. Предприятие буквально составлено, собрано, сделано из своих подразделений – это конструктивные, а не функциональные подразделения. Из обсуждения организационной диаграммы не скажешь, как работает предприятия, какие функции подразделений по отношению друг ко другу, и именование оргзвеньев это часто отражает. Цех №5, палата №6 – простые номера в именах, из которых не следует функций, являются типичными указателями на конструктивное рассмотрение. Функций, исполняемых конструктивными элементами предприятия, может быть множество, и самых неожиданных. С другой стороны, если «подразделение переезжает в другое здание», то это описание связи ипостасей конструктивной и размещения. «Подразделение будет выполнять новые виды деятельности» – это обсуждение связи функциональной и конструктивной ипостасей подразделения.
Необходимость хорошей модульности
Система должна собираться из модулей по принципу подводной лодки, в которой все отсеки делаются максимально автономными – если один из них будет затоплен, это не будет означать затопления подводной лодки. В системе все части системы взаимосвязаны, в системном окружении они ведут себя совершенно не так, как могли бы вести себя без системного окружения. Если у нас нет интерфейсов, через которые мы контролируем все взаимодействия в системе, то любая попытка улучшить модуль может привести к улучшению только этого модуля – но ухудшению системы в целом через влияние на другие модули по неотслеживаемым связям.
Вот компьютерная симуляция зависимости от числа попыток улучшений падения стоимости разработки при улучшении n отдельных модулей, при d связей каждого из них130:
Видно, что если связь одна, то стоимость разработки с каждым улучшением падает быстро по экспоненте, слабо зависящей от числа модулей. Но если связей больше, то снижение стоимости идёт плохо.
Каждая связь имеет свою цену, не было бы этой цены, мы не имели бы даже в живой природе «органов», «клеток» и других модулей131. Но модульность человеческого организма не идёт ни в какое сравнение с модульностью современного компьютера или смартфона, собираемого из стандартизованных деталей. Поэтому слабомодульный человеческий организм не очень понятно как улучшать или даже просто лечить, а компьютер или смартфон удаётся улучшать конструктивно и лечить-ремонтировать много проще.
Интерфейс – это не просто соединение, это соединение через какой-то вполне определённый канал по вполне определённому протоколу (лучше бы – определяемому стандартом, хотя это и не всегда соблюдается), так что это взаимодействие можно отследить, и ошибка не распространится по системе. Более того, можно просто заменить модуль на альтернативный (это проще, если интерфейс стандартный) – и система продолжит работать. Если же какие-то связи будут проходить не через интерфейсы модулей, а система будет эти связи использовать для реализации своей функции, то замена модуля приведёт к исчезновению этих связей и нарушениям в работе системы.
Есть множество методов, которые помогают уменьшать связность модулей в создаваемой системе. Одним из наиболее известных таких методов является DSM (design/dependency structure matrix)132.
Минимальная связность модулей нужна и в «железных» системах, и в программных системах, и в организационных, и даже в танцах. Это совсем не означает, что части системы/подсистемы не находятся в тесном взаимодействии друг с другом. Это означает, что эти взаимодействия ставятся под жёсткий контроль, и подсистемы можно улучшать, а в случае стандартизации интерфейса даже заменять на принципиально другие по конструкции и принципу действия, не рискуя при этом ухудшить работу всей системы в целом.
Системный подход обычно называют холистическим, ибо он обращает внимание на систему в целом. Но нет других подходов, которые так бы интересовались разбиением на самые разные части, как системный подход. Суть системного подхода не только ко вниманию к целой системе, но и одновременному вниманию к частям системы.
Борьба со сложностью в мышлении
Edsger Dijkstra в 1974 году ввёл133 понятие разделения интересов (separation of concerns) как способ упорядочивания человеческих мыслей о каком-то предмете. Этот принцип гласит, что нужно обсуждать сложные ситуации по одному интересу за раз, удерживая внимание на каком-то одном аспекте, одной ипостаси этой ситуации. Это не значит, что игнорируются все остальные. Просто это удерживание во внимании одного аспекта проблемы и одновременно всей проблемы. По словам Edsger Dijkstra про такое мышление, «It is being one – and multiple-track minded simultaneously».
И это разделение мышления по интересам проводится на каждом уровне системной холархии, поскольку ввиду эмерджентности на каждом уровне система начинает проявлять какие-то новые свойства.
Сложность обсуждения системы тем самым падает по двум направлениям:
• деление полного обсуждения всей системы на обсуждение её отдельных частей по уровням холархии. Каждая часть холона проще, чем холон в целом, поэтому обсуждение проходит более-менее единообразно на каждом уровне, каждая часть холона определяется его требованиями (requirements). В требованиях игнорируется внутренняя структура холона и его частей – это определение системы как «чёрного ящика».
• деление полного обсуждения каждого холона на обсуждение отдельных ипостасей этого холона как прозрачного ящика: принципов организации взаимодействия и структуры частей холона. Важнейшие из этих определений – это архитектура (architecture), а все остальные определения с точностью, достаточной для изготовления – это неархитектурная часть проекта (non-architectural part of design).
Тем самым детальное и в подробностях обсуждение огромных сложных систем принципиально (в силу самой сути системного подхода) может быть разбито на достаточно маленькие части, и ни одна часть этого обсуждения не будет забыта, ни одно описание не будет пропущено. Как съесть слона? По кусочку за раз!
Системное мышление по своей природе коллективно, оно позволяет разделить умственный (по проектированию) и физический (по изготовлению и эксплуатации) труд системы, задействовать множество разных исполнителей стейкхолдерских ролей – и при этом обеспечивается детальное продумывание всех частей системы (холархия!) со всех сторон (множественность частных описаний!).
Но как договориться о том, как склеивать все эти самые разные частные описания самых разных частей системы в одно целое? Как договориться всем этим людям? Это можно сделать на основании 4D экстенсионализма. Все эти описания можно совместить, если понимать, что они описывают одно и то же место в пространстве-времени, относятся к одному и тому же воплощению системы. Без системного подхода сложные проекты с задействованием большого количества разных специалистов выполнить в срок и вовремя невозможно.
Требования как часть определения системы
Требования являются частью определения системы, и они в силу этого всегда есть: о них не принято говорить, что их разрабатывают (их не придумывают!), их обычно выявляют (discover) в разговорах с различными стейкхолдерами, а также в экспериментах. О требованиях хорошо думать примерно так же, как о цвете системы (который тоже может входить в требования, так что это не самый плохой пример).
Цвет – это не сама система, и это не часть описания системы (описанием для цвета был бы фрагмент текста с номером цвета из каталога цветов, или длиной волны для этого цвета, или названием цвета, или пятно краски нужного цвета, или значения интенсивностей красного-зелёного-голубого в составе цвета, и т.п.). Мы можем обсуждать цвет системы, можем выявлять пожелания к цвету у разных стейкхолдеров, а затем описывать выявленный цвет после выбора адекватного метода описания. Вот и самые разные требования как часть определения системы мы можем обсуждать, выявлять, а затем описывать после выбора метода описания.
Приключения требований на этом не заканчиваются: требования анализируют, затем их наборы делают непротиворечивыми, после чего обеспечивают к ним доступ самых разных стейкхолдеров (это обеспечение доступа и называется управление требованиями/requirements management). Всё вместе называют инженерия требований (requirements engineering). Обратите внимание, что как выявление требований входит в инженерию требований, так и управление требованиями. Управлять нельзя тем, чего ещё нет, а выявленные требования это только сырьё для дальнейшей работы.
В описаниях требования выражаются как спецификации требований, части технических заданий (технические задания обычно – это «задания на работы», требования в них маленькая часть), протоколы технических совещаний и т. п. Требования декомпозируемы: любое требование может быть разбито на множество более мелких, часто говорят о наборах требований.
Два понимания требований
Есть два понимания требований, которые нужно различать по контексту их употребления (помним, что люди вполне могут разбираться в высказываниях типа «косил косой с косой косой косой на косе» и понимают при этом, что у каждого слова может быть много значений):
1. Требования (requirements) – это часть определения системы, определяющая систему как «чёрный ящик», т.е. что делает система по отношению к её системному окружению, без описания внутренней структуры системы, происходящих внутри системы взаимодействий частей системы. Прежде всего тут важно поведение системы, выполнение ей своего назначения, функции в использующей системе. Поэтому основные требования называют функциональными требованиями. Нефункциональных требований не бывает, хотя в литературе этот термин регулярно встречается, но он считается некорректным: все требования описывают какое-то поведение системы, ожидания этого поведения. Но речь не всегда идёт о поведении в использующей системе. Требования качества в отличие от функциональных, относятся прежде всего к поведению в обеспечивающих системах, в том числе обслуживающих уже готовую систему: по-английски их иногда называют – ilities (reliability, accessability и т.п.), а по-русски – ости (надёжность, доступность, и т.п.).
Требования отличают от потребностей (stakeholder needs, stakeholder requirments) как требований внешних стейкхолдеров к использующей системе. Если мы выходим за пределы инженерии, то у требований могут быть другие имена. Например, для организаций речь может идти о стратегии – но суть тут будет та же самая: описание того, что хотелось бы получить от организации. Требования, взятые вместе со временем их выполнения, называют контрольными точками (milestone). Если требование – это «помидор красный», то «помидор красный, 10 мартобря 2019 года» будет контрольной точкой. Очень часто на контроле стоят не сами требования, а контрольные точки: «дорога ложка к обеду».
2. Альтернативное понимание требования уже не имеет отношения к системному подходу, не связано с границами системы. Это просто любое утверждение, данное в деонтической модальности. Любое высказывание из описания системы (например, «X=10») невозможно как-то понять по отношению к деятельности без указания на модальность (modality)134: то, как нужно понимать значения высказывания. Скажем, «в системе [существует] X=10» это алетическая (aletic) модальность, модальность существования. «Я верю, что в системе X=10» – это модальность доксическая (doxastic), веры. Деонтическая (deontic) модальность говорит о долженствовании, разрешении, рекомендации135: «Я требую, чтобы X=10». В этом втором понимании требований можно потребовать что угодно – и оно станет требованием, даже если речь идёт не о чёрном ящике. Например, «в автомобиле должен быть корпус из углепластика», «в смартфоне должны быть использованы отечественные микропроцессоры» относятся к «прозрачному ящику», но слова «должен» и «должны» указывают на деонтическую модальность.
Ограничения (constraints) свободы принятия решений по поводу «прозрачного ящика» связаны именно с таким пониманием: ограничения как высказывания в деонтической модальности по поводу устройства «прозрачного ящика» поступают вместе с функциональными требованиями и требованиями качества, но их часто тоже называют требованиями не по их системному пониманию, а по альтернативному, деонтическому. Поэтому «в автомобиле должен быть корпус из углепластика» является не требованием, а ограничением с точки зрения системного подхода, но «по бытовому» это тоже требование.
Требования и холархия
Стандарт описания требований ISO/IEC 29148:2011 подчёркивает то, что требования есть у каждого холона в холархии. Вот пример из этого стандарта:
Чтобы лучше понять этот пример, нужно «перевести с айтишного» слово business.
Стандарт ISO/IEC 29148:2011 даёт чёткое указание, что слово бизнес (business) тут просто условный термин, обозначающий просто организацию (organization): «The term business is used even though it could apply to not-for-profit organizations such as in the public sector. Users of this standard may replace each occurrence of the term business with the term organization or organizational depending on the users’ environment».
Это относится не только к требованиям, но и ко многому другому. Так бизнес-процесс лучше называть организационным процессом.
Картинка очень неподробно и схематично показывает холархию какой-то организации, в которой внутри организационного окружения (organization environment) находится вся работающая организация (business operation), в которой содержится какая-то часть организации, работающая с системой (system operation), в которой есть система (system), в которой есть элемент системы (system element), в котором есть программное обеспечение (software). Каждый из указанных холонов в холархии имеет какие-то описания «чёрного ящика», называемые требованиями – и на картинке некоторые из них показаны зелёными стрелками, указывающими на границы соответствующих вложенных друг в друга систем-холонов.
Целевой системой тут является «система» (system), требования к ней так и называются: системные требования (system requirements).
Требования к использующей системе будут называться требования стейкхолдеров (stakeholder requirements) или потребности/нужды стейкхолдеров (stakeholder needs). Их не перепутать: они описывают разные системы на их границах (как «чёрный ящик», без подробностей про внутреннее устройство каждой из систем), на картинке это чётко видно.
Мы привели эту картинку для того, чтобы показать присутствие в проекте множества самых разных требований.
Нельзя считать, что в проекте есть только требования для целевой системы и потребности для использующей. Они, конечно, основные для рассмотрения, но обычно ситуация сложней, и выявлять приходится множество самых разных требований к самым разным системам из системной холархии, которые приходится учитывать в проекте.
Целеориентированная инженерия требований
Идея о том, что требования не «объективны», а их субъективно задают стейкхолдеры для того, чтобы достичь каких-то целей, не так уж стара.
В 1986 году Ивар Якобсон предложил технику выявления требований, при которой рассматриваются варианты использования (use cases)136.
Вариант использования определяет взаимодействие между пытающимися достичь своих целей внешними актёрами (actors) и целевой системой.
Актёры в вариантах использования (в других практиках термин актёр/актор/actor может означать совсем друге) это функциональные объекты, которые необязательно люди: они могут быть людьми, компанией или просто предпринятием, компьютерной программой, или даже компьютером.
Требования при анализе взаимодействия внешних актёров и системы легко выявлялись, и подход получил широкое признание в инженерии требований.
Вот типичная диаграмма вариантов использования137:
В 1995 году появился подход к моделированию требований, называемый i*138, и он продолжил идею взаимодействия актёров и системы для достижения своих целей. Упор был сделан не только на варианты использования системы актёрами, но и на описания взаимодействий самих актёров, а весь подход получил название целеориентированной инженерии требований (goal-oriented requirements engineering). В философии тех, кто может иметь свои цели, принято называть агентами (agents) – независимо от живой или неживой (например, системы искусственного интеллекта) природы этих агентов.
В i* приняли, что требования отражают цели, убеждения, возможности и договорённости агентов, окончательно признав социальную природу требований, их «необъективность»: «Agents attribute intentional properties (such as goals, beliefs, abilities, commitments) to each other and reason about strategic relationships. Dependencies between agents give rise to opportunities as well as vulnerabilities. Networks of dependencies are analyzed using a qualitative reasoning approach. Agents consider alternative configurations of dependencies to assess their strategic positioning in a social context».
Был предложен язык для записи взаимодействий актёров, преследующих свои цели:
С тех пор моделями требований называют такие описания требований, которые включают не только сами модели требований, но и как-то описывают ситуации их возникновения, прежде всего участвующих актёров, достигающих своих целей. Конечно, самый частый вариант актёра – это стейкхолдер.
В 2008 году международный союз телекоммуникаций принял стандарт ITU-T Z.151139, в котором для моделирования требований предлагался целеориентированный язык требований подхода i* (Goal-oriented Requirements Language) и карты вариантов использования (Use Case Maps). В простейшем случае вариант целеориентированной системной инженерии предполагает написание коротких пользовательских историй (user story), в которых актёр сведён до обычной стейкхолдерской роли. Пример формата таких историй140: «Я как _стейкхолдер_ хочу, чтобы _целевая-система_ _формулировка требования _, для того чтобы _потребности-для-использующей-системы_».
Проверка и приёмка
Проверка и приёмка (verification and validation, V&V, верификация и валидация) служат для того, чтобы убедиться в работоспособности системы. По сути, это просто тщательное тестирование системы, проведение испытаний, обоснование успешности системы. Успешность – это соответствие ожиданиям стейкхолдеров. Стейкхолдеров же у нас два набора:
• внешние, которых волнует прежде всего работоспособность использующей системы. Работает ли использующая система с включением в её состав целевой системы как задумано, удовлетворяет ли требованиям стейкхолдеров/потребностям?
• и внутренние, которых волнует работоспособность целевой системы – работает ли целевая система как задумано, удовлетворяет ли системным требованиям?
Почему же используется два слова? Потому что по факту проверяется работоспособность двух систем, проводятся два набора испытаний: проверочные (целевой системы, соответствие её требованиям) и приёмочные (использующей системы, соответствие её потребностям).
Почему это так важно различать? Потому что не факт, что команда инженеров правильно сформулировала требования. Вполне возможно, что при попадании целевой системы в её системное окружение появится взаимодействие между элементами системы, которое не было учтено в требованиях – и требования будут удовлетворены, а потребности – нет. Инженеры будут считать, что они выполнили требования, и требовать оплаты за работу. А стейкхолдеры будут считать, что денег за работу давать не нужно, ибо для них система оказывается бесполезна. И стейкхолдеры всегда найдут способ доказать, что они правы. Поэтому целевая система не только проверяется, но и использующая валидируется.
Испытания/тестирование разного сорта могут составлять до 85% от общей стоимости проекта. Именно потому, что недостаточно проверки/верификации, но ещё нужна и валидация, в испытаниях требуется участие не только целевой системы, но и значительной части её системного окружения. Поскольку системное окружение может быть недоступно, или очень дорого, то это требует часто создания испытательных стендов, более дорогих, чем сама целевая система. В результате какая-нибудь задвижка для атомной станции оказывается полностью идентичной задвижке для городского водопровода, но будет стоить впятеро дороже: потому что её много тщательней испытывали.
Понятие архитектуры
Архитектура, как и любое другое определение системы, всегда есть – начиная с того момента, когда вы выделили систему из окружающего мира. Не всегда есть архитектурное описание. Архитектура дана нам в виде архитектурных описаний, и поэтому в речи и текстах часто путаются понятия «архитектуры» и «архитектурного описания». Обычно понятно из контекста, о чём идёт речь.
Так, «цвет» шкафа тоже есть, но есть и описание цвета – слово «чёрный», код цвета по одной из цветовых моделей141 или даже попытка воспроизвести этот цвет (на каком-то носителе, вот прямо как тут). Но если есть шкаф, то и цвет у него есть. И архитектура у шкафа есть. Но может не быть описание цвета (нигде не будет написано, какой у шкафа цвет), как может не быть описания архитектуры.
Об описании цвета или архитектуры мы говорим, или о самом цвете или архитектуре – это понимаем из контекста, или проговариваем явно. Если мы говорим «цвет нужно сделать почернее», то это про цвет, а если «цвет в кодировке RGB», то про описание цвета. С архитектурой всё то же самое.
ISO 42010 даёт следующее определение архитектуры: «Архитектура (системы) – основные понятия или свойства системы в её среде, заключающиеся в её элементах, их отношениях и принципах её проектирования и развития»142. Обратите внимание, что в этом определении нет никакого упоминания структуры системы. Ибо для такой системы как интернет нельзя указать на структуру системы: в интернете никто не знает, что входит в структуру интернета в каждый конкретный момент, какие есть связи между элементами этой системы, непрерывно появляются и исчезают новые узлы интернета и между ними непрерывно появляются и исчезают новые каналы связи. Но определение от этого не стало понятней.
Вот другое определение архитектуры, от части авторов того же ISO 42010, но данное ими в книге про документирование системных архитектур143: «Архитектура системы это набор структур, необходимых для рассуждений о системе, каковые структуры состоят из элементов, отношений и свойств этих элементов и отношений»144. Там наоборот, дан акцент на структуры.
Но самых разных определений много больше, и в интернете есть место, где собрано более 150 таких определений145. Самые разные стейкхолдеры определяют архитектуру по-разному, с акцентом на те или иные её свойства, те или иные классы целевых систем.
Мы будем придерживаться неформального простого и понятного определения архитектуры, которое дал Ralf Johnson: «Архитектура – это обо всём важном. Что бы это ни было.»146.
Эти слова обычно указывают на важные решения, которые могут быть для «железных» систем инженерные, для предприятия организационные, менеджерские или предпринимательские, в случае танцев – постановочные решения, и т. д. Важные решения определяются как такие, в случае принятия альтернативных решений по ним придётся перепринять большинство других решений, то есть перепроектировать и затем переделать всю систему. Так, если при проектировании самолёта принято решение сделать его с реактивным двигателем, а не обычным поршневым, то это означает переделку практически всей конструкции: от устройства топливной системы до формы крыльев и фюзеляжа. Если в здании принято решение печатать его на бетонном 3D-принтере, а не выкладывать его из бетонных блоков или даже из кирпича, то смело можно переделывать всю проектную документацию – или переделывать весь дом, если он уже построен.
Если принято решение сделать какой-то винтик не с левой резьбой, а с правой, то вряд ли это приведёт к переделке всего изделия. Будет переделан лишь этот винтик и резьба в связанной с ним гайке. Такое решение не архитектурное. Весь проект/design тем самым делится на две части: архитектура и неархитектурная часть проекта (non-architectural part of design).
Архитектурное описание в простейшем виде представляет собой список принятых важных инженерных решений. При этом то, что одному архитектору кажется важным, другому архитектору может казаться неважным – это не «объективный» список, он существенно зависит от опыта и знаний того, кто этот список составляет. Важно при этом, что такой список находится не в голове архитектора, а выписывается отдельно, документируется. Неважно, будет ли это документирование в форме электронного текста или таблицы, или в виде бумажного документа, или просто в виде записей фломастером на флип-чарте – подойдёт любая форма, в которой эти важные решения перечислены, и их можно обсудить с командой проекта и внешними экспертами.
Более сложные формы архитектурных описаний включают в себя компонентные, модульные диаграммы, трассировку компонент и их функций к модулям, размещения и компоновки. То есть архитектурное описание это совсем необязательно список принятых решений: решения могут быть документированы и в других формах. Главное, чтобы они не оказались устными. Интересно, что в советской устной архитектурной традиции, когда архитектурных описаний практически не было, всё важное обозначалось словами «заделы», «опыт», «наработки». Архитектуры были, но их нельзя было предъявить, обсудить, передать, развить иным способом, кроме как задействовав ту команду, которая имела тот самый «опыт» и «заделы» в голове.
Обычно важнейшими архитектурными решениями оказываются решения модульного синтеза: какие модули выбираются для выполнения каких потребных функций. Тем самым в архитектуру попадают решения по верхнеуровневому разбиению на функции, и верхнеуровневому разбиению на модули – в их взаимосвязи. Иногда функциональные описания называют логической архитектурой, а модульные описания и описания компоновки – физической архитектурой. Есть и возражение к такой терминологии: архитектура это про всё важное, а если выбирать только логические и только физические части важного, то это только части архитектуры, а не отдельные архитектуры. Тем не менее, термины эти можно встретить довольно часто, равно как часто можно встретить и другой нерекомендованный термин «нефункциональные требования».
Все эти решения оказываются не только субъективными в части отнесения к архитектурным (и поэтому нельзя провести чёткую границу между «важным» и «неважным»), но относительными в части принятия их разными стейкхолдерами: что архитектурное для одного, неархитектурное для другого. Если один конструктор делает самолёт (целевая система), а другой делает к нему двигатель (подсистема), то для первого выбор типа топливного насоса – неархитектурное решение, а для второго – важное архитектурное решение.
На рисунке субъективность отнесения к архитектурным решениям показана насыщенностью цвета, при этом стрелки примерно соответствуют небольшому числу взаимосвязанных решений, определяющих все остальные решения. Стейкхолдеров-архитекторов показано два: один занимается архитектурой всей системы, другой архитектурой подсистемы. Где остановиться в принятии архитектурных решений? Спускаясь по отношениям часть-целое в холархии нужно остановиться там, где стейкхолдер-архитектор считает, что там уже нет его важных решений, то есть работа уже поделена между разработчиками модулей и дальше будут их важные решения.
Требования, которые однозначно ведут к архитектурным решениям часто называют архитектурными требованиями. Например, для самолёта скорость является архитектурным требованием. Если самолёт должен обеспечивать скорость 0км/час, то его архитектура должна быть ахитектурой вертикального взлёта и посадки. Если скорость должна быть 2000км/час, то это может быть обеспечено только для реактивного самолёта.
Итак, архитектура это (с точностью до разницы между определением и описанием – самой архитектурой и выражающими её рабочими продуктами):
• самые важные части функционального и конструктивного определений системы в их взаимосвязи, или оно же как
• компоненты + модули + размещения (только важные, верхнеуровневые), или оно же как
• принципиальная схема + заказная спецификация + компоновка (только важные, верхнеуровневые), или оно же как
• логическая архитектура + физическая архитектура (при учёте возражения о недопустимости «частных архитектур»), или оно же как
• список важнейших принятых конструкторских/проектных/постановочных решений
Понятие конфигурации
Конфигурация (configuration) – это текущее актуальное состояние холархии системы и её описаний. Обычно в ходе разных проектов порождается множество самых разных вариантов частей воплощения системы, множество самых разных описаний системы, относящихся к разным моментам времени, разработанных самыми разными людьми, и нужно понимать – какие изо всех этих частей системы входят в холархию, и какие описания являются для них актуальными.
В ходе разработки инженерной системы обычно рассматривают самые разные варианты требований, архитектуры, неархитектурной части проекта/design. И эти описания ещё и изменяются каждое по нескольку раз. Как определить, какие из этих описаний должны быть использованы изготовителями системы? А если часть изготовителей изменили систему так, что она уже не соответствует этим описаниям, а часть изготовителей работает «как договаривались» – можно ли быть уверенным, что из изготовленных частей можно будет собрать работающую систему? Конечно, нет. Ошибки, связанные с тем, что некоторые части системы и их описания не известны, или даже известны, но не соответствуют друг другу, весьма распространены.
Конфигурация системы – это сами части системы и их описания. Сама конфигурация может быть определена (defined) и, соответственно, описана (described). Описание конфигурации (configuration description, иногда говорят и «конфигурационное описание») в речи часто сокращают до просто «конфигурация» – и разницу между конфигурацией (составом самой системы) и описанием конфигурации нужно определять из контекста так же, как разницу между архитектурой и архитектурным описанием, когда для обоих используют слово «архитектура».
Управление конфигурацией (configuration management) – отслеживание, что конфигурация воплощения системы и описания системы известны и соответствуют друг другу. Это дисциплина лежит посредине между менеджерскими и инженерными дисциплинами. Конфигурация составляется из конфигурационных единиц (configuration item) – самых мелких частей, на которые делится система в части её логистики. Речь идёт о единицах передачи частей системы и описаний этих частей от одного исполнителя работ к другому, от одной обработки к другой.
Инженеры часто имеют более детальные описания частей системы, чем это требуется для организации перемещения рабочих продуктов. Например, каждый из многих миллиардов транзисторов на чипе уникален, но конфигурационной единицей в цеху электроники служит сам чип но не эти транзисторы, ибо отдельно транзисторы никому не передаются.
Чтобы не потерять эти конфигурационные единицы при учёте, иметь возможность на них сослаться в разговоре и различных описаниях системы, им даются индивидуальные обозначения (designations). Стандарт IEC 81346147 представляет собой стандарт, в котором предлагается типовой способ такого описания, учитывающий системный подход – наличие нескольких альтернативных структур системы (компонентной/функциональной, модульной/продуктной, размещений, и т.д.).
Описания системы всегда являются описаниями каких-то конфигурационных единиц и их обозначения обычно создаются путём приписывания к названию конфигурационной единицы вида описания. Если для каких-то целей вдруг потребовалось описать три или четыре конфигурационных единицы, то скорее всего речь идёт об описании какой-то системы из этих единиц и нужно просто создать из них новую конфигурационную единицу, которой и будет соответствовать описание.
Версия (version) системы – это её конфигурация по состоянию на какой-то момент времени. Отслеживание смены версий в результате изменений (changes) нужно для того, чтобы точно указывать, какая из многочисленных возникающих и исчезающих по ходу проекта конфигураций системы имеется ввиду.
Базис (baseline, конфигурационный базис) – это проверенная на целостность и утверждённая административно версия.
Управление изменениями (change management) часто включают в состав управления конфигурацией (так и пишут: «управление конфигурацией и изменениями», но обычно это отдельная дисциплина. Её не нужно путать с управлением организационными изменениями – как нужно менять организацию, чтобы это не вызывало сопротивления людей и вело к положительным результатам. Инженерное управление изменениями – это про то, как принимать решения по изменению конфигурации, чтобы минимизировать конфигурационные ошибки. Для этого в конфигурации различают обычные рабочие версии с более простыми внесениями изменений и базисы, внесение изменений в которые связано с дополнительными инженерными и административными проверками на целостность конфигурации.
Инженерия предприятия
Обеспечивающая система – тоже система, только нужно не забывать, что всё её существование связано с целевой системой и поэтому не нужно говорить, что она сама целевая. Если вы поставляете какой-нибудь продукт для использования в составе какого-то предприятия или предпринятия (или его части, если речь не идёт обо всём предприятии или предпринятии в целом), то оно будет использующей системой для вашего продукта. Часы, которые вы поставили автомобильному заводу, могут быть использованы заводчанами (а не «пользователями часов») либо в выпускаемом заводом автомобиле (и заводчане тогда не «пользователи часов!»), либо в заводском цеху (и тогда заводчане сначала выступают как разработчики цеха как использующей системы для часов, а потом и как пользователи для часов).
В случае инженерии предприятия все системные рассмотрения остаются, только может меняться терминология. Так, потребности и требования могут называться стратегией, модулями предприятия называются подразделения (более общий термин – организационное звено, ведь в предприятии могут быть и «правления» и «советы», которые не являются подразделениями в обычном смысле слова, но явно включены в организацию), компонентами предприятия являются его практики, а управление конфигурацией предприятия называется учётом.
Если речь идёт вообще не об инженерии, то терминология может поменяться ещё больше. В медицине, в хореографии используется тот же системный подход, но терминология будет отличаться как от инженерной, так и от менеджерской.
6. Понятие жизненного цикла
Биологический жизненный цикл
Поскольку системный подход поначалу развивался на сложных биологических системах, то часть терминологии осталась с тех времён. Вот жизненный цикл печёночного сосальщика148:
Этот паразитический плоский червь проводит свою жизнь в разных состояниях (яйца, личинки, цисты, взрослый червь), проходя метаморфозы (полную перестройку своей внутренней структуры) за время своей жизни. При этом никто не придумывает и не проектирует систему-червя. Это сделала эволюция. Никто также не изготавливает систему червя: все эти стадии происходят без вмешательства человека, это и есть жизнь. А ещё всё повторяется, начиная с яиц червя.
В инженерии, менеджменте, предпринимательстве, культуре всё не так:
• целевые системы сами не растут и не проходят метаморфозы, их придумывают, проектируют, изготавливают, эксплуатируют, модернизируют, выводят из эксплуатации люди в обеспечивающих системах. Это означает, что в самих системах никакой жизни нет, жизненный цикл оказывается не жизненным.
• Целевые системы не несут яиц, не живородят, не размножаются вегетативно. Это означает, что жизненный цикл не замыкается, не повторяется. То есть это не цикл.
Жизненный цикл оказался для неживых систем не жизненным и не циклом, но сам термин остался, причём он постепенно менял своё значение.
Понятие жизненного цикла системы 1.0
Поначалу жизненный цикл (life cycle) просто обозначал отрезок времени, во время которого происходили проводимые обеспечивающими системами работы с целевой системой, при этом по аналогии с биологическим циклом последовательно проходящие работы относили к разным стадиям (stages), иногда называемым фазами (phase) жизненного цикла – отрезки времени, в которых система была в каком-то состоянии.
Работы – это процессные (то есть разворачивающиеся в конкретный участок времени) модули. Эти модули составлены из 4D-модулей, называемых в данном случае ресурсами для этих работ.
Для планирования работ обычно составляется план, в котором прописываются ответственные за выполнение работ, и время, за которое эти работы должны быть сделаны. Часто в план прописывают и другие требуемые ресурсы.
Каждая работа проходит следующий цикл (это подробно обсуждается в подходе к архитектурному описанию предприятий DEMO149):
• Работа затребована, часто в виде её появления в каком-то плане (с заданной последовательностью выполнения работ) или бэклоге (backlog, набору работ к выполнению – но без указания строгой последовательности их выполнения): координационный акт, речь идёт об информационном мире поручений-согласований-обещаний, но не о реальной работе по изменению мира.
• Работа принята к исполнению, это тоже координационный акт.
• Работа выполняется. Это производственный акт (production act), реальное выполнение работ.
• Работа предъявлена к приёмке, это координационный акт.
• Работа принята, координационный акт.
Деление на координационные и производственные акты важно, чтобы делать правильные оценки времени: от момента затребования работы до момента принятия работы на координационные акты может уходить до 40% времени, и только 60% времени на проведение самой работы. Как планировать работы – по полному времени координации+производства работ, или только по актуальному времени потребления ресурсов? Разные школы управления работами отвечают на этот вопрос по-разному.
При этом сразу в жизненный цикл стали включать и работы, которые происходили в начальный (до изготовления деталей системы) с разными описаниями будущей системы, но не с воплощением системы. С этого момента жизненный цикл вообще перестал при этом ассоциироваться с изменением состояний воплощения системы, а значение термина перешло полностью на работы.
Вскоре повсеместно жизненным циклом стали называть даже не сам отрезок времени, а обеспечивающую систему, представляемую как идущие одна за другой стадии/фазы/крупные части работ с целевой системой на всём времени существования системы: от первых описаний до ликвидации использованного и уже не нужного никому воплощения.
Сама целевая система при этом просто была маркером, который позволял отметить все относящиеся к системе (как к воплощению системы, так и к определению системы) работы, кто бы их ни производил в самых разных предприятиях, которые занимались системой на всём протяжении жизненного цикла.
Когда говорили «жизненный цикл АЭС», то имели ввиду разбитые на стадии все работы, которые выполняли многочисленные предприятия от момента замысла АЭС до момента вывода её из эксплуатации с получением после этого зелёной площадки.
Когда говорили «жизненный цикл танца», то имели ввиду работы по замыслу танца, его постановке, последующих перформансах – кто бы этим ни занимался в самых разных командах всё это время с момента замысла танца до момента прекращения его просмотра (помним, что танец мог ещё жить и на записи, поэтому его жизненный цикл необязательно завершается в момент исполнения).
Изображение жизненного цикла как работ (1.0)
Изображались такие жизненные циклы с периодизацией работ очень просто: такими «колбасками», в которых поминались производимые последовательно крупные работы, и эти работы были стадиями/фазами жизненного цикла.
Вот примеры такого изображения жизненного цикла разных типов систем из стандарта ISO 15288:
Нижняя строчка там представляет собой один из вариантов «типового жизненного цикла», который в том или ином виде может быть определён для почти каждого типа целевой системы. При этом часто стадии «использование» и «поддержка» показывают даже не последовательно, а в одном и том же месте «колбаски», говоря, что стадии жизненного цикла могут пересекаться – то есть работы разных стадий могут выполняться в одно и то же время.
Вот этот же жизненный цикл, но там уже используются не ломтики «колбаски», а «шеврончики», означающие «процесс» с последовательными стадиями:
На этой картинке уже нельзя указать точные моменты времени, когда начинается один процесс и заканчивается другой, и это намеренно. В жизни разных работ в каждой стадии обычно много, и когда работы одной стадии начинаются (например, начинается изготовление каких-то деталей будущей системы), работы другой стадии вполне могут ещё продолжаться (например, проектирование других деталей будущей системы не закончено).
Сам термин «жизненный цикл» всегда означает «полный» (от замысла до прекращения существования проэксплуатированной системы). В этом и была сила системного подхода, сам термин указывал думать о полном жизненном цикле, а не о его отдельных частях-стадиях.
Но поскольку уже было понятно, что речь идёт о работах, а естественной единицей работ стал «проект» (в смысле «проектного управления», project, а не design), то появился ещё один термин: жизненный цикл проекта (project life cycle) – он означал те работы жизненного цикла системы, которые попадали в конкретный проект. Проекты эти обычно совпадали с работами, проводимыми для каких-то полных стадий жизненного цикла, одной или нескольких. Это было естественным делением жизненного цикла, потому что разные проекты часто выполнялись разными организациями – и нужно было как-то выделять части жизненного цикла, за которые несла ответственность проводящая проект организация/предпринятие.
По факту системное мышление и проектное мышление в этот момент слились: жизненным циклом называли происходящие по поводу целевой системы работы, которые являлись предметом проектного управления в разнообразных проектах по поводу целевой системы.
Часто жизненный цикл системы обозначали просто линией времени с засечками, при этом он всегда обозначался полный: от замысла до момента прекращения существования, но на нём вполне можно было указать и жизненный цикл проекта, который мог быть короче жизненного цикла системы (например, включать в себя только замысел и проектирование/design, или только изготовление/воплощение системы как физического объекта, или только эксплуатация – тут могут быть самые разные варианты).
Помним, что работы – это 4D процессы, которые мы вполне можем представить как участвующие в этих работах (т.е. жизненном цикле) 4D объекты-индивиды обеспечивающих систем, которые в ходе взаимодействия с целевой системой меняют её состояния. Эти работы понимались типично как работы проектного управления: имеющие конкретную дату начала и конца, последующая работа обычно не могла начаться, пока не кончится предыдущая, требующая для своего выполнения «ресурсов» (тех самых 4D объектов-модулей, которые должны провзаимодействовать для получения целевой системы). Работы жизненного цикла по сути – это модульное представление обеспечивающих систем на всём времени, когда внешние и внутренние стейкхолдеры занимались целевой системой.
Это было первое (1.0) поколение понимания жизненного цикла: модульное, обеспечивающие системы/предпринятия как наборы всех работ по поводу целевой системы.
Попробуйте перестать рисовать целевую систему квадратиком или кружочком. Вместо этого рисуйте её жизненный цикл, обозначая его стрелочкой с засечками. Это будет напоминать не только о воплощении целевой системы, но и длительности работ с целевой системой, и о 4D предпринятиях, ведущих эти работы.
Тем самым от статических рассмотрений целевой системы мы перешли к динамическим (развёртка во времени) и перенесли фокус с самой системы на обеспечивающие системы/предпринятия (но не на системное окружение! Речь идёт о другой холархии, нежели холархия целевой системы и её использующей системы/операционного окружения).
Проблемы с жизненным циклом 1.0
Но не успело новое понятие жизненного цикла как системы поделённых на стадии работ прижиться, как начались проблемы.
Во-первых, начала вырождаться стадийность. В agile (гибких) подходах к разработке появились не тематические «стадии», а безымянные «итерации» какой-то фиксированной длины – и на этих итерациях было очень трудно отследить, какая же там преимущественная тематика работ.
Затем появилась вообще параллельная инженерия (concurrent engineering), в которой намеренно в параллель/одновременно выполнялись работы, ранее считавшиеся строго разнесёнными по разным последовательным стадиям жизненного цикла: одновременно и велось проектирование, и изготовление системы, а какие-то неполные версии системы ещё и начинали эксплуатировать. Разговор о «стадийности» жизненного цикла всё больше и больше становился условным, а не сущностным.
Вот типичная картинка объяснения перехода к параллельной инженерии (и на ней хорошо видно, что сроки работ существенно сокращаются)150:
Во-вторых, интерфейсы между работами обсуждались с точки зрения продуктных входов и выходов, доступности ресурсов в проектном управлении. Это было очень удобно, когда речь шла о точном ответе на вопросы «когда и кем будет выполняться работа, когда она будет закончена». Но когда обсуждается, как лучше (а не как быстрее) выполнить работы, и нужно менять сами работы – информации категорически не хватало. Обеспечивающую систему нужно проектировать, как-то «изготавливать» и «налаживать» (хотя предпринятия как системы деятельности «изготавливают» и «налаживают» совсем другими методами, чем программные и аппаратные системы).
Сейчас хорошо понятно, что так долго продолжаться не могло, и на передний план должно было выйти функциональное представление обеспечивающих систем – «как работает» (а не «из чего собрать») обсуждается именно по принципиальным схемам, функциональным диаграммам. Но это произошло не сразу, поначалу появилось множество гибридных диаграмм. Одной из самых известных таких гибридных диаграмм жизненного цикла является горбатая диаграмма (hump diagram) из методологии rational unified process (RUP)151:
В этой диаграмме 1996 года уже видно, что кроме безымянных «итераций», по-старинке разбитых на «стадии» во времени, появилась новая сущность, практика (practice, деятельность), именованная по её теоретической инженерной или менеджерской дисциплине (discipline). «Практика» и есть появление функционального аспекта в определениях жизненного цикла.
Работы разных практик (в RUP это практики организационное моделирование, инженерия требований, анализ и проектирование, разработка, испытания, разворачивание, управление конфигурацией, управление проектом, работа с окружением) как-то распределены по стадиям.
На самом графике показано, что интенсивность этих работ по разным дисциплинам разная в разные моменты времени жизненного цикла (часто по-прежнему говорят и «в разные моменты жизненного цикла»). Тем самым на графике интенсивности работ появляются «горбы», отсюда и название «горбатая диаграмма».
С этого момента жизненный цикл перестал обсуждаться как чистые «колбаски» из видов работ и стал представлять собой архитектурное описание деятельности: основные (не все!) практики (функциональные объекты, определявшие, что нужно делать, чем заниматься) в нём как-то назначались на основные работы, разворачиваемые во времени (модульные объекты, указывающие на единицы использования ресурсов и места во времени, когда эти ресурсы задействованы).
Жизненный цикл 2.0
Недостаточность и ограниченность описания жизненного цикла (описания обеспечивающей системы как деятельности) через метод описания (viewpoint) стадий жизненного цикла была всё очевидней: во всё большем и большем числе проектов (начиная с айтишных проектов) становилось очевидно, что никакого предварительного планирования работ достичь нельзя, разработка велась, как судебные дела, «непрерывно открывающимися обстоятельствами».
Наборы различных архитектурных решений по поводу отнесения практик к работам жизненного цикла получили название виды жизненного цикла (life cycle model152, модели жизненного цикла).
Эти наборы решений грубо можно отнести к двум разным полюсам: в одном укрупнённые практики и работы-стадии совпадают и для их выражения хватает «колбаски» с интерфейсами между работами («видимость работ», как обычно в модульных диаграммах – нельзя из работы одной стадии затребовать работу не соседней стадии), а в другом не совпадают и для их выражения нужны какие-то сложные структуры с акцентом на связь практик, т.е. даже внешне похожие на принципиальные схемы, а не модульные диаграммы.
Первый вид жизненного цикла (квинтэссенция подхода 1.0) получил название «водопад» (cascade, каскад).
Как и в водопаде, работы какой-то практики выполняются, созданные рабочие продукты передаются как ресурсы для следующих работ, и больше к этим практикам никакого возврата нет, выполняются работы последующих практик.
Для более убедительной иллюстрации этого «невозвратного» хода работ традиционную «колбаску» начали рисовать как ступеньки настоящего водопада153:
Между стадиями осуществлялась тщательная проверка и приёмка (verification and validation, V&V) рабочих продуктов-результатов предыдущих стадий, при этом принималось решение о продолжении работ, возврате на доработку или прекращении работ. Эти проверки и приёмки с принятием решений между стадиями жизненного цикла получили название гейтов (gates, ворота):
Но данная модель жизненного цикла оказалась полной утопией, она более-менее выполнялась лишь в проектах, где можно было накопить огромный опыт создания многочисленных очень похожих систем, например, гражданское (жилищное) строительство.
Во всех остальных случаях (и особенно ярко это проявлялось в айтишных проектах) после выполнения работ по любой из практик «водопадного жизненного цикла» (например, инженерии требований в ходе стадии работ «формирование требований») после всех гейтов с их проверкой независимыми экспертами, после всех ожиданий, когда все рабочие продукты соберут по их состоянию готовности на конец стадии (скажем, если речь идёт о требованиях – то это будут абсолютно все требования, и если не готово даже какое-то второстепенное требование, то его будут ждать), всё равно при попытке работы с этими результатами предыдущих стадий находятся ошибки и недоработки и приходится выполнять работы, задействующие практики работ предыдущих стадий жизненного цикла. «Водопад» был только на бумаге в учебниках и в мечтах менеджеров. А в жизни инженерам приходилось признавать, что практики – отдельно, с ними приходилось работать в ходе всего жизненного цикла, а работы назначать (и выделять ресурсы для проведения этих работ) на эти практики приходилось независимо от «водопадной» модели жизненного цикла.
Менеджерам и особенно госчиновникам в военных проектах гейтовая схема была очень удобна, ибо она позволяла легко организовывать финансирование проектов, по их стадиям. Проектные управляющие до сих пор пользуются гейтовой схемой как основной для организации своей работы.
Но инженерам нужно было делать сами проекты, им нужно было содержательно преодолевать утопичность «водопада с гейтами».
Поэтому была предпринята радикальная попытка заменить модель жизненного цикла с приматом метода описания работ-стадий на прямо противоположную, функциональную, с приматом метода описания практик. Работы в этой модели учитывались как развёртка применения тех или иных практик работы во времени, а сама линия времени как символ выделения ресурсов для показанных практик была нарисована по спирали. Этот вид жизненного цикла был предложен Barry Boehm в 1978 году, успешно реализован им 1981 и опубликован 1988 году. Этот жизненный цикл получил название спирального154:
На рисунке показан вариант спирального вида жизненного цикла 1989 года, когда уже невозможно было игнорировать тот факт, что в системный подход пришло понятие стейкхолдеров – просто к практикам работы с продуктом (целевой системой) и практиками жизненного цикла (часто называемым в их путанице с работами-модулями «процессом») добавились практики работы со стейкхолдерами.
Работы представлялись как идущие по спирали задействования практик: на каждом витке спирали предполагалось, что в работах задействуются последовательно все практики (продукт как бы разрабатывается до конца на каком-то уровне детальности), после чего цикл повторяется много раз, пока продукт не будет окончательно готов.
Это был очень несовершенный вариант вида жизненного цикла (по факту он подразумевал много-много идущих подряд «водопадов», список выбранных практик был отнюдь не полный для жизненного цикла от замысла до уничтожения уже использованного воплощения системы, а ограничивался разработкой – но это не помешало спиральной модели считаться основой неутопических вариантов жизненного цикла. Уже разбиравшаяся «горбатая диаграмма» 1996 года как раз представляет собой гибридный вариант спиральной модели (выделены отдельно практики, введены «итерации» как повторения практик) и водопадной модели (введена линейная ось времени, последовательные стадии жизненного цикла, хотя и признаётся, что на каждой стадии жизненного цикла будут работы всех практик, определяемых их дисциплинами).
Современный вариант спиральной модели жизненного цикла носит название «модель пошагового спирального выделения ресурсов» (Incremental Commitment Spiral Model, разрабатывалась Barry Boehm, Jo Ann Lane, Supannika Koolmanojwong, Richard Turner в 2006—2014 годах как продолжение работ по развитию идей спирального вида жизненного цикла) и используется в военных инженерных проектах США155.
Вот современный вариант, в котором укрупнённые практики обобщённого жизненного цикла раскладываются по линии времени (и обратите внимание, что тут тоже по факту «жизненный цикл проекта», так как не входит замысел, эксплуатация и вывод из эксплуатации):
Переход от «проектного» понимания жизненного цикла как удовлетворяющего только менеджерски-логистический взгляд на работы обеспечивающей системы с точки зрения «как сделать систему работ-модулей» с производством и потреблением ресурсов проекта в строго запланированное время, акцента на своевременную закупку ресурсов и учёт рабочих продуктов, контроль выдаваемых обещаний и приёмок-сдач (координационные акты DEMO) к настоящему времени завершился.
Сегодня «модель жизненного цикла» (в том числе модель жизненного цикла проекта) упирает не на модульную структуру работ, а на компонентную структуру практик, ответ на вопрос инженера предпринятия (enterprise engineer, инженер, который организует предпринятие, а не создаёт целевую систему) «как будем работать». Модель жизненного цикла документирует архитектурные решения о назначении модулей-работ на компоненты-практики.
Поэтому время там «логическое» (функциональное), а не «физическое» (конструктивное, для выстраивания последовательности работ).
Эксплуатация как выделенная стадия жизненного цикла
Эксплуатация (operations, функционирование, usage, использование) – это особая стадия жизненного цикла, поскольку именно на этой стадии у нас с определением и воплощением целевой системы имеют дело не обеспечивающие системы, а системы в операционном окружении.
Все проекты/предпринятия/обеспечивающие системы по замысливанию, проектированию и созданию системы, затем проекты её ремонта и модернизации, а в конце концов и вывода из эксплуатации делаются главным образом для того, чтобы система могла выполнить свою функцию, оказать сервис, чтобы она могла быть проэксплуатированной. Вот схематически это показано на примере сверхсложной системы-человека.
Сам человек тут показан как 4D индивид. Это позволяет обсуждать изменение его состояний как полных темпоральных частей.
Его рожают (показана семья как обеспечивающая система), учат (школа/учительница как обеспечивающая система), и в этот момент, когда он ещё не вырос, и недоучен, он не является полностью дееспособным. Затем он эксплуатирует (сам себя! У него самопринадлежность), и обеспечивающие системы не показаны – вместо них мы находим множество систем в его операционном окружении. Да, в это же время идут «ремонты» (врачи) и «модернизации» (учёба, физподготовка), но чаще всего на диаграммах жизненного цикла это не отражается. А затем доктора его лечат, а микробы прекращают существование тела.
Где же тут жизненный цикл? Жизненный цикл тут – это выполняемые практики всех обеспечивающих систем, воплощённые в работах по поводу «замысливания», «проектирования», «производства» и «вывода из эксплуатации», плюс практики работы операционного окружения с целевой системой, воплощённые в соответствующих работах в ходе её эксплуатации.
Пример с человеком очень провокационен, ибо человек самопринадлежен, слово «эксплуатация» (в любых вариантах: использование) крайне эмоционально окрашено, по отношению к человеку плохо говорить о его «проектировании» и «производстве» в любом смысле этих слов. Но этот пример крайне полезен, чтобы понять принцип: одно и то же системное мышление с обязательным учётом границ его применимости можно использовать для снижения сложности разбирательства с самыми разными системами и самыми разными обеспечивающими системами и системами в операционном окружении.
Вот пример, который показывает, как целые цепочки жизненных циклов связаны через стадию эксплуатации, ибо стадия эксплуатации обеспечивающей системы – это когда она участвует в работах жизненного цикла целевой системы, и это может распространяться на несколько уровней.
Нужно всегда понимать, о какой системе вы говорите: когда вы говорите «топор», то непонятно – вы делаете топор (целевая ваша система), вы используете топор для колки дров (целевая система – дрова, топор – одна из обеспечивающих систем, необходимая для подготовки целевой системы к эксплуатации – сгоранию в печке) или топор для вас она из систем в операционном окружении целевой для вас колоды, совместно с которой топор должен колоть дрова и свойства которого вы выясняете для того, чтобы спроектировать и изготовить правильную колоду156.
Есть более простой способ показывать диаграммы жизненного цикла обеспечивающих систем: жизненный цикл на них рисуется изображающими время стрелками с зарубками, отделяющими стадии жизненного цикла, а отрезки работы обеспечивающей системы над соответствующей целевой системой показываются фигурной скобочкой на линии времени:
На таких диаграммах удобно рассказывать истории типа «мы организуем стартап, который создаст САПР, при помощи которого мы затем спроектируем топор, при помощи которого мы потом будем колоть дрова» – и для каждой системы в такой диаграмме понятно, что она проходит довольно долгую жизнь перед тем, как быть использованной/проэксплуатированной.
Есть два разных понимания эксплуатации в части представления ремонтов (обслуживания, maintainance – конструкция и функциональность остаются прежними) и модернизации (modernization, частичное изменение функциональности и конструкции):
• Эксплуатация как стадия включает в себя все эти работы. Главные люди – операторы и пользователи. Ремонтники и инженеры по модернизации отдельно не учитываются.
• Техобслуживание и ремонты, равно как и модернизация считаются отдельными стадиями, при этом модернизация разделяет несколько разных (первую, вторую и т.д.) стадий эксплуатации, а техобслуживание и ремонты считается стадией, которая протекает в одно и то же время с эксплуатацией, понимаемой как «рабочее функционирование» (operations). То есть техобслуживание и ремонты не считаются «короткими стадиями», а считаются длинной стадией, которая длится всё то же самое время, которое длится сама стадия эксплуатации – и это неважно, что сами работы по обслуживанию и ремонтам составляют не слишком большое время от этой стадии. Важно, что разделяются работы разных людей, эти работы (времени, когда система работает, и времени, когда система не работает) в обсуждениях не смешиваются друг с другом.
Это лишний раз подчёркивает условность отнесения работ к разным стадиям.
Три времени жизненного цикла
В жизненном цикле есть три явно выделенных времени, которые нужно удерживать в сознании всё время работы с целевой системой:
1. Время эксплуатации, оно в момент разработки обычно находится в будущем, и поэтому приходится думать о системе как находящейся в одном из возможных миров, в котором она существует и успешна (т.е. удовлетворяет ожиданиям своих стейкхолдеров, а то и превосходит их ожидания). Это время эксплуатации может быть очень небольшим, например, 20 миллисекунд для исполнения какого-нибудь софта или реализации взрыва. Это также может быть тремя минутами для танцевального перформанса, или восьмьюдесятью годами бесперебойной работы энергоблока атомной электростанции.
2. Время самого жизненного цикла, которое включает кроме времени эксплуатации ещё и другие стадии – от замысла до прекращения существования воплощения системы.
3. Методологическое время, в котором мы думаем о всех этих временах. Это самое трудное время, но его легко понять, если вспомнить про 4D, в котором по определению у систем (целевой, обеспечивающих, в операционном окружении) нет ни «уже», ни «ещё», они все одновременно присутствуют. Но думаем мы обо всех этих временах как бы находясь вне этого времени.
Удобно представлять время эксплуатации отдельно, а не только в составе жизненного цикла, ибо это обычно обсуждение целевой системы в её операционном окружении. Часто с этим временем связаны модели поведения целевой системы в ходе её работы в операционном окружении.
Разговор про время жизненного цикла – это уже не разговор про целевую систему. Это обсуждение обеспечивающих систем, которые работают с определениями и воплощениями целевой системы на всех стадиях, а не только стадии эксплуатации.
Методологическое время легче представлять как время просмотра и обсуждения какого-то статического изображения покадровой развёртки 4D-индивида «жизненный цикл», находящегося прямо перед внутренним взором обсуждающего жизненный цикл человека. В европейской традиции при этом линия времени такой «развёртки во времени» представлена на уровне глаз слева направо, примерно как изображено на нашем рисунке.
Понятие практики
Как и для любых других определений системы, ключевым для определения обеспечивающих систем является её компонентное, функциональное определение, отвечающее на вопрос «как работает?». Компонентами/функциональными элементами обеспечивающих систем как систем человеческой деятельности являются практики (practices).
Сегодня часто кроме слова «практика» говорят и «процесс» (process) – за последние пять лет слово «процесс» перестало всегда означать развёртку во времени/работы и приобрело оттенок указания на функциональный аспект работ, а не только модульный/конструктивный в части управления процессами или управления проектами.
Очень часто про практику говорят и «деятельность» (activity или action), когда речь идёт о выполнении работ какой-то практики стейкхолдерами, роли которых играют актёры с какими-то предметными (domain) компетенциями. По этой терминологической традиции инженерные практики называют «инженерной деятельностью», практику управления конфигурацией называют «деятельностью по управлению конфигурацией». Неправильно говорить, что это «профессиональные компетенции», потому как часто речь идёт о более простых умениях, чем профессиональное (например, практики подготовки презентаций – презентации готовят все, для этого не нужно быть профессиональным «презентатором»), да и само понятие «профессия» как пожизненное занятие чем-то отмирает157, человек просто овладевает множеством разных компетенций.
Читать бесплатно другие книги:
