Яблоки из задачи и яблоки из жизни: альфы и рабочие продукты
Главная трудность в понимании Essence -- это как дисциплина (теория) связана с технологией реального мира, давая практику.
Для отображения видов объектов реального мира (технологии) в практике есть дела и рабочие продукты (например, "яблоки" и "сосчитать яблоки"), а из дисциплины в практику приходят только альфы и деятельности (например, "количество предметов" и "сосчитать предметы"). Тут нужно опять вспомнить байку про яблоки из задачи и из жизни, например, в таком варианте: пришла в ... школу учительница, которая начиталась работ о дидактической функции наглядных пособий и считала, что надо учить на наглядных пособиях. А проходили они в этот момент задачку на сложение: «3+5». И она принесла три яблока и еще пять яблок, выложила их на стол и говорит: «Дети, вот вы видите здесь - раз-два-три - три яблока, а здесь вот - раз-два-три-четыре-пять - пять яблок. Вот я их соединяю, сколько получится всего яблок?» Дети пялятся на яблоки, слюни у них текут, но задачи не понимают. Второй день проходит, третий - рекорд: в таком классе обычно за день это проходили. Она приходит в учительскую, жалуется, что вот-де она применяет новые методы, наглядно все, а результата нет. И вот на пятый день с задней парты тянется рука, и ученик говорит: «Мэм, я теперь понял: эти яблоки, которые вы выложили на стол, не настоящие - это яблоки из задачи». - «Да, а что?» - «Ну тогда, мэм, совсем другое дело». И с этого момента, когда класс понял, что это не настоящие яблоки, а яблоки из задачи, все моментально пошло. Почему? Когда вы кладете реальные яблоки - что с ними надо делать? Их надо есть. А чтобы считать, нужны рисуночки.
Вот vlkamov напомнил и ещё про то же самое: -- Мы займемся арифметикой... У вас в кармане два яблока...
Буратино хитро подмигнул:
-- Врете, ни одного...
-- Я говорю, -- терпеливо повторила девочка, -- предположим, что у вас в кармане два яблока. Некто взял у вас одно яблоко. Сколько у вас осталось яблок?
-- Два.
-- Подумайте хорошенько.
Буратино сморщился, -- так здорово подумал.
-- Два...
-- Почему?
-- Я же не отдам Некту яблоко, хоть он дерись!
-- У вас нет никаких способностей к математике, -- с огорчением сказала девочка.
Альфы -- это яблоки из учебников и задачников. Рабочие продукты -- это яблоки, которые мы едим. К ним применяются разные действия. Как их различить, и как отождествить -- это главная трудность в освоении не только Essence, но и других языков описания деятельностей (например, как отличить и связать объекты работы и данные в ArchiMate -- это ровно про то же самое). Да что уж там, это главная трудность обучения любой теории: как объекты этой теории совмещать с объектами реального мира. Это как раз то, что физиков отличает от математиков: физиков волнует, чему в реальном мире соответствуют их формулы, а математиков не волнует. Essence заставляет об этом различении говорить явно: альфу "требований" из теории усматривать и в стопке карточек с user story, и в спецификации с user cases, и в стопке брошюрок ГОСТов.
Альфы и рабочие продукты представляют собой основные элементы языка Essence, которые нужны для представления простейших форм практик -- в которых даже не описывается поведение (деятельности, дела -- "как работать, что делать"), а описываются только проверяемые контрольными вопросами состояния альф и уровни детальности рабочих продуктов -- "над чем работать".
Альфы -- это функциональные (ролевые, идеальные) объекты, по которым мы судим о продвижении (progress, "как много мы уже сделали?") и здоровье (health, "в проекте всё идёт хорошо") проекта. Альфы -- это абстракция того же сорта, какого "физическое тело" является абстракцией реальных физических объектов (да, это физическое тело имеет массу, а геометрическая точка имеет координаты. Но мы связываем физические тела и математические точки как идеальные объекты с реальными объектами, и после надлежащего тренинга "склеиваем" в мышлении идеальные и реальные объекты. Поэтому об экземплярах альф в проекте принято говорить так, как будто они вполне реальны и существуют в мире, несмотря на все абстракции.
Альфы фиксируют компактное описание мира (теорию), удобную для решения каких-то проблем. Это нужно, чтобы иметь возможность повторно использовать известные нам способы рассуждений и решения задач для самых разных объектов. Так, мы думаем о "физическом теле" и "математических точках" единообразно, "как в учебниках физики и геометрии", а применимо это мышление к самым разным "реальным объектам вокруг нас" -- от летящей после удара ногой болонки до крутящегося по марсианской орбите космического корабля. В этой экономии мышления (учимся думать один раз, затем похоже думаем в самых разных ситуациях) и заключается фишка разделения альф и рабочих продуктов. Например, учимся думать о "требованиях" -- а применяем потом это мышление к конкретным рабочим продуктам, которые можно найти на производстве "в реале": спецификациям требований, требованиям из текстов стандартов, user stories на карточках, записям в базе данных системы управления требованиями и т.д.).
Несмотря на всю "идеальность" и "абстрактность", об альфах говорят как о вполне существующих в физическом мире -- поразумевая при этом их тождественность тем рабочим продкутам, по которым мы можем судить об их существовании. Так, можно определить альфу "моя любимая игрушка" -- и, хотя в детстве у меня это был нарисованный на ватмане пульт управления космическим кораблём, а сегодня это мой ноутбук, я могу говорить про прохождение "моей любимой игрушкой" состояний "полюбил", "разлюбил", "поломалась", "играю", "забросил" и т.д. -- независимо от того, какая именно это игрушка прямо сейчас. Если я говорю о "требовании" -- то меня не волнует, пункт ли это протокола совещания с представителями заказчика, или запись в базе данных системы управления требований, или фрагмент диаграммы какой-то модели требований. Для меня это "требование" -- и я после этого знаю, что с ним делать, и как о нём думать, я обсуждаю "требование" как реальный объект, существующий в мире, имеющий своё состояние и меня в этот момент мало волнует, что у этого требования есть ещё и какие-то особенности выражения (как при счёте яблок меня мало волнует, что их ещё и едят).
Формально ALPHA это Abstract-Level Progress Health Attribute, но неформально это просто "идеальный рабочий продукт", названный "альфой" для уменьшения путаницы с "реальными рабочими продуктами" и аббревиатура для него была подобрана задним числом. Альфы -- это то, что изменяется в проекте, и изменения чего мы хотим понимать, отслеживать, обеспечивать, направлять, контролировать.
То, что альфы (точнее, экземпляры альф) изменяются в ходе стратегирования, инженерной, организационной, операционной деятельностей, отражено в том, что альфы имеют состояния (state), а эти состояния имеют контрольные вопросы (checkpoint) как критерий определения достижения этих состояний -- этот критерий (condition) нахождения альфы в заданном состоянии принимает значения "да" или "нет" (true или false). Cостояния альф обычно определяются на всём пути от самого появления альфы в проекте до прекращения ещё существования. Планирование и контроль выполнения инженерного проекта ведётся прежде всего в терминах этих состояний альф: каждый пункт плана и контроль выполнения плана имеет ввиду достижение этого состояния.
Контрольная точка (milestone) жизненного цикла инженерного проекта определяется набором предопределённых видом жизненного цикла состояний альф его дисциплины (не только альфы воплощения системы и определения системы, но и альф стейкхолдеров, команды и т.д.). Стадии жизненного цикла -- это деятельности, которые нужны для приведения набора альф из состояний начальной контрольной точки стадии в состояния конечной контрольной точки стадии. Тем самым контрольные точки и стадии жизненного цикла инженерного проекта определяется уже отнюдь не только состоянием его целевой системы, но и состоянием команды, состоянием стейкхолдеров и т.д.. Это и есть системный подход, отражающий всю полноту и сложность понятия системы -- когда система мыслится неотъемлемо от её стейкхолдеров, обеспечивающих систем, систем в операционном окружении, всегда в контексте разворачивания её существования во времени (жизненного цикла). Жизненный цикл определяется набором его стадий, которые определяются набором состояний альф.
Конечно, не все обнаруженные понятия инженерного проекта -- это непременно альфы. Например, те же контрольные точки и стадии -- это паттерны (именованная связка других элементов языка, в данном случае синхронизируемого набора состояний альф как контрольной точки и отфильтрованного между двумя контрольными точками набора деятельностей как стадии). Паттерны не имеют состояний, не отслеживаются в проекте, это просто удобные для выражения каких-то идей конструкции языка, имеющие имя. Впрочем, о паттернах -- позже, сейчас важно показать, что не все встречающиеся в той или иной теории термины нужно сразу обзывать альфами, и первичный критерий тут -- это наличие у альфы состояний, которые меняются деятельностью (выполняемой работой) команды.
Состояния альф -- это граф, в котором переходы состояний произвольны. В Essence на карточках принято отображать только одну "главную цепочку", но это только для упрощения, для облегчения восприятия. Состояния альф сменяются, как в полной машине состояний, в которой возможны любые возвраты к уже пройденным состояниям, перескоки в преимущественной последовательности, итерации по сложным циклам. Деятельности меняют состояния альф, это обнаруживается контрольными вопросами этих состояний, после чего состояния продолжаются меняться деятельностями, это изменение обнаруживается контрольными вопросами -- и так все альфы постепенно продвигаются от их начальных состояний к конечным в условной их последовательности.
Альфы могут быть вложены друг в друга (связь AlphaContaiment, выражает отношение часть-целое двух альф), при этом выполняется важное правило: продвижение по состояниям вложенной альфы (части) означает какое-то продвижение по состояниям объемлющей альфы (целого). Так, продвижение требований как целого по их состояниям может быть за счёт того, что продвигаются отдельные требования -- по их состояниям. Никакой связи между состояниями частей ("подчинённых" альф, subordinate) при этом и состоянием целого (альф-"начальников") нет, кроме общего понимания, что "продвижение в изготовлении частей как-то продвигает нас в изготовлении целого".
Отношения вложенности альф -- это тоже направленный граф, одна альфа может быть частью других альф. Так, член команды может быть подальфой и команды в целом, и подальфой стейкхолдеров (ибо члены команды формально тоже стейкхолдеры, хотя и "внутренние"). Обратите внимание, что рассуждения про альф тут такие же, как про реально существующие объекты. Яблоки в задаче и яблоки в жизни очень легко перепутать, для тренинга в их использовании и нужны учителя и консультанты.
Альфы между собой связаны (AlphaAssociation) -- можно думать об этих связях, как о стрелочках на диаграмме альф, эти связи в стандарте Essence не обрабатываются, но очень полезны в описании системы альф (например, "определение системы определяет воплощение системы", "команда выполняет работы" и т.д.).
Рабочий продукт представляет (represent) собой альфу в реальном мире. Это "яблоко из жизни", "его едят" -- рабочий продукт имеет в реальном мире какую-то пользу для проекта. Рабочие продукты -- это спецификации, тесты, диаграммы и какие-то модели, базы данных и физические объекты. В Essence рабочим продуктом могут быть и какие-то мероприятия (совещания, презентации, уборка рабочего места), необязательно что-то "вещественное" типа распечатанных на бумаге документов. Одну альфу может представлять несколько рабочих продуктов, ибо у альфы в деятельности могут проявляться много различных свойств, требующих различных представлений в мире. И несколько альф могут быть представлены в одном рабочем продукте. Эта связь рабочих продуктов и их альф (WorkProductManifest) обычно определяется в рамках какой-то практики.
Помним, что в дисциплинах рабочие продукты не определяются, они ситуативны для технологии конкретной организации, использующей конкретный набор практик для работы (практика=дисциплина+технология). Зачем это разделение на дисциплину (входящие в kernel элементы) и технологию (не входящие в kernel элементы)? Одна альфа отражается в 10-15 рабочих продуктах (это можно найти в презентациях SEMAT), следовательно разговор в терминах альф существенно экономит время и мозги, снижая сложность обсуждаемого объекта -- а при необходимости можно копнуть глубже и перейти к обсуждению рабочих продуктов, погрузившись в детали. Выделение дисциплины -- это обеспечение простоты, упрощение, переход к теоретической модели, подчёркивающей только самое нужное для принятия решений. То же с деятельностями и делами: деятельности представлены десятками дел, но они требуют самостоятельного обсуждения. Деятельностям учат в ВУЗе один раз, а дела конкретны и разнообразны в каждом отдельном предпринятии, с учётом используемых инструментов, особенностей рабочих продуктов и т.д..
Рабочие продукты могут быть как входными для проекта, так и представлять собой результаты, или же быть полезными только команде, не являясь ни входными ни результирующими для проекта.
Как и альфа меняется, проходя состояния, рабочий продукт меняется, проходя уровни детальности. Рабочие продукты в ходе инженерного проекта создаются, модифицируются, уничтожаются. Они вместе с их уровнями детальности наблюдаемы, в отличие от альф, о состояниях которых мы можем судить только "по приборам" -- по рабочим продуктам.
Уровни детальности также определяются контрольными вопросами, только в случае альф состояние определяется через "и" ("да" в ответе на все вопросы), а в случае рабочих продуктов уровень детальности определяется по любому из вопросов, т.е. через "или" ("да" в ответе хотя бы на один вопрос). Состояния альф и уровни детальности рабочего продукта не связаны между собой, они про разное. Так, для согласованных со стейкхолдерами требований спецификация может быть в виде краткого резюме, более-менее подробна, в виде формальной модели. С другой стороны, может быть детальнейшие требования, которые совсем не согласованы со стейкхолдерами, и эти требования могут быть противоречивы между собой. Так что уровни детальности -- это просто уровни гранулярности и объема информации, который мы можем почерпнуть о той или иной альфе, а уж какое состояние этой альфы -- это другой вопрос. Заметим, что работа прежде всего продвигает состояние альф -- а уж будет ли продвинуто состояние альфы, если вложиться в работы по повышению детальности рабочего продукта, это большой вопрос. Повышение детальности рабочих продуктов, конечно, как-то связано с общим состоянием работ в проекте, но не впрямую.
* * *
Для тех, кто разбирался с ISO 15926, то различение и отождествление альф и рабочих продуктов очень похоже на различение и отождествление FunctionalPhysicalObject и MaterializedPhisicalObject. Напомню:
-- A [FunctionalPhysicalObject] is a [PhysicalObject] that has functional, rather than material, continuity as its basis for identity. Adjacent temporal parts of a [FunctionalPhysicalObject] need not have common matter or energy, provided the matter or energy of each temporal part fulfils the same function. Не напоминает определение альфы?
-- A [MaterializedPhysicalObject] is a [PhysicalObject] that has matter and/or energy continuity as its basis for identity. Matter or energy continuity requires some matter or energy to be common to adjacent temporal parts of the [MaterializedPhysicalObject]. Replacement of some components from time to time does not create a new identity. Это, конечно, про рабочий продукт (с точностью до того, что рабочие продукты часто бывают данными, так что на данном уровне объяснения ограничимся аналогией, а не точной онтологической спецификацией).
Примерно такое же разделение есть и в ArchiMate по отношению "реализация", только не двухуровневое, а трёхуровневое (объекты работы/альфы -- данные/рабочие продкуты -- оборудование/физческие объекты). Не забывайте, что Essence изначально разрабатывалось для программистских проектов, поэтому с различением данных и физических объектов есть проблемы не только в ArchiMate (где физических объектов вообще нет по определению, есть только информация о них), но и в Essence есть проблемы (например, подумайте про конкретного человека, выполняющего роль представителя стейкхолдеров -- всё легко на уровне "карточки представителя стейкхолдера", но сложнее, если имеется ввиду именно сам человек "из костей и мяса", that has matter and/or energy continuity as its basis for identity -- сложно его назвать "рабочим продуктом", да?).
При моделировании Essence и ArchiMate в ISO 15926 прежде всего нужно решать именно эту проблему -- не забывая, что рассуждения в 4D экстенсионализме не самые привычные, и цепочки "информация альфы -- представленность в реале" может быть отмоделирована либо в один уровень "информация на носителе" (на это претендует Essence, хотя в Essence этот носитель легко может быть понят как "данные"), либо в два уровня "информация выражена данными, а уж данные на носителе", как в ArchiMate. В любом случае, обобщение Essence и ArchiMate для системной инженерии требует тщательного онтологического разбирательства, чем и займёмся в ближайшее время.
Для отображения видов объектов реального мира (технологии) в практике есть дела и рабочие продукты (например, "яблоки" и "сосчитать яблоки"), а из дисциплины в практику приходят только альфы и деятельности (например, "количество предметов" и "сосчитать предметы"). Тут нужно опять вспомнить байку про яблоки из задачи и из жизни, например, в таком варианте: пришла в ... школу учительница, которая начиталась работ о дидактической функции наглядных пособий и считала, что надо учить на наглядных пособиях. А проходили они в этот момент задачку на сложение: «3+5». И она принесла три яблока и еще пять яблок, выложила их на стол и говорит: «Дети, вот вы видите здесь - раз-два-три - три яблока, а здесь вот - раз-два-три-четыре-пять - пять яблок. Вот я их соединяю, сколько получится всего яблок?» Дети пялятся на яблоки, слюни у них текут, но задачи не понимают. Второй день проходит, третий - рекорд: в таком классе обычно за день это проходили. Она приходит в учительскую, жалуется, что вот-де она применяет новые методы, наглядно все, а результата нет. И вот на пятый день с задней парты тянется рука, и ученик говорит: «Мэм, я теперь понял: эти яблоки, которые вы выложили на стол, не настоящие - это яблоки из задачи». - «Да, а что?» - «Ну тогда, мэм, совсем другое дело». И с этого момента, когда класс понял, что это не настоящие яблоки, а яблоки из задачи, все моментально пошло. Почему? Когда вы кладете реальные яблоки - что с ними надо делать? Их надо есть. А чтобы считать, нужны рисуночки.
Вот vlkamov напомнил и ещё про то же самое: -- Мы займемся арифметикой... У вас в кармане два яблока...
Буратино хитро подмигнул:
-- Врете, ни одного...
-- Я говорю, -- терпеливо повторила девочка, -- предположим, что у вас в кармане два яблока. Некто взял у вас одно яблоко. Сколько у вас осталось яблок?
-- Два.
-- Подумайте хорошенько.
Буратино сморщился, -- так здорово подумал.
-- Два...
-- Почему?
-- Я же не отдам Некту яблоко, хоть он дерись!
-- У вас нет никаких способностей к математике, -- с огорчением сказала девочка.
Альфы -- это яблоки из учебников и задачников. Рабочие продукты -- это яблоки, которые мы едим. К ним применяются разные действия. Как их различить, и как отождествить -- это главная трудность в освоении не только Essence, но и других языков описания деятельностей (например, как отличить и связать объекты работы и данные в ArchiMate -- это ровно про то же самое). Да что уж там, это главная трудность обучения любой теории: как объекты этой теории совмещать с объектами реального мира. Это как раз то, что физиков отличает от математиков: физиков волнует, чему в реальном мире соответствуют их формулы, а математиков не волнует. Essence заставляет об этом различении говорить явно: альфу "требований" из теории усматривать и в стопке карточек с user story, и в спецификации с user cases, и в стопке брошюрок ГОСТов.
Альфы и рабочие продукты представляют собой основные элементы языка Essence, которые нужны для представления простейших форм практик -- в которых даже не описывается поведение (деятельности, дела -- "как работать, что делать"), а описываются только проверяемые контрольными вопросами состояния альф и уровни детальности рабочих продуктов -- "над чем работать".
Альфы -- это функциональные (ролевые, идеальные) объекты, по которым мы судим о продвижении (progress, "как много мы уже сделали?") и здоровье (health, "в проекте всё идёт хорошо") проекта. Альфы -- это абстракция того же сорта, какого "физическое тело" является абстракцией реальных физических объектов (да, это физическое тело имеет массу, а геометрическая точка имеет координаты. Но мы связываем физические тела и математические точки как идеальные объекты с реальными объектами, и после надлежащего тренинга "склеиваем" в мышлении идеальные и реальные объекты. Поэтому об экземплярах альф в проекте принято говорить так, как будто они вполне реальны и существуют в мире, несмотря на все абстракции.
Альфы фиксируют компактное описание мира (теорию), удобную для решения каких-то проблем. Это нужно, чтобы иметь возможность повторно использовать известные нам способы рассуждений и решения задач для самых разных объектов. Так, мы думаем о "физическом теле" и "математических точках" единообразно, "как в учебниках физики и геометрии", а применимо это мышление к самым разным "реальным объектам вокруг нас" -- от летящей после удара ногой болонки до крутящегося по марсианской орбите космического корабля. В этой экономии мышления (учимся думать один раз, затем похоже думаем в самых разных ситуациях) и заключается фишка разделения альф и рабочих продуктов. Например, учимся думать о "требованиях" -- а применяем потом это мышление к конкретным рабочим продуктам, которые можно найти на производстве "в реале": спецификациям требований, требованиям из текстов стандартов, user stories на карточках, записям в базе данных системы управления требованиями и т.д.).
Несмотря на всю "идеальность" и "абстрактность", об альфах говорят как о вполне существующих в физическом мире -- поразумевая при этом их тождественность тем рабочим продкутам, по которым мы можем судить об их существовании. Так, можно определить альфу "моя любимая игрушка" -- и, хотя в детстве у меня это был нарисованный на ватмане пульт управления космическим кораблём, а сегодня это мой ноутбук, я могу говорить про прохождение "моей любимой игрушкой" состояний "полюбил", "разлюбил", "поломалась", "играю", "забросил" и т.д. -- независимо от того, какая именно это игрушка прямо сейчас. Если я говорю о "требовании" -- то меня не волнует, пункт ли это протокола совещания с представителями заказчика, или запись в базе данных системы управления требований, или фрагмент диаграммы какой-то модели требований. Для меня это "требование" -- и я после этого знаю, что с ним делать, и как о нём думать, я обсуждаю "требование" как реальный объект, существующий в мире, имеющий своё состояние и меня в этот момент мало волнует, что у этого требования есть ещё и какие-то особенности выражения (как при счёте яблок меня мало волнует, что их ещё и едят).
Формально ALPHA это Abstract-Level Progress Health Attribute, но неформально это просто "идеальный рабочий продукт", названный "альфой" для уменьшения путаницы с "реальными рабочими продуктами" и аббревиатура для него была подобрана задним числом. Альфы -- это то, что изменяется в проекте, и изменения чего мы хотим понимать, отслеживать, обеспечивать, направлять, контролировать.
То, что альфы (точнее, экземпляры альф) изменяются в ходе стратегирования, инженерной, организационной, операционной деятельностей, отражено в том, что альфы имеют состояния (state), а эти состояния имеют контрольные вопросы (checkpoint) как критерий определения достижения этих состояний -- этот критерий (condition) нахождения альфы в заданном состоянии принимает значения "да" или "нет" (true или false). Cостояния альф обычно определяются на всём пути от самого появления альфы в проекте до прекращения ещё существования. Планирование и контроль выполнения инженерного проекта ведётся прежде всего в терминах этих состояний альф: каждый пункт плана и контроль выполнения плана имеет ввиду достижение этого состояния.
Контрольная точка (milestone) жизненного цикла инженерного проекта определяется набором предопределённых видом жизненного цикла состояний альф его дисциплины (не только альфы воплощения системы и определения системы, но и альф стейкхолдеров, команды и т.д.). Стадии жизненного цикла -- это деятельности, которые нужны для приведения набора альф из состояний начальной контрольной точки стадии в состояния конечной контрольной точки стадии. Тем самым контрольные точки и стадии жизненного цикла инженерного проекта определяется уже отнюдь не только состоянием его целевой системы, но и состоянием команды, состоянием стейкхолдеров и т.д.. Это и есть системный подход, отражающий всю полноту и сложность понятия системы -- когда система мыслится неотъемлемо от её стейкхолдеров, обеспечивающих систем, систем в операционном окружении, всегда в контексте разворачивания её существования во времени (жизненного цикла). Жизненный цикл определяется набором его стадий, которые определяются набором состояний альф.
Конечно, не все обнаруженные понятия инженерного проекта -- это непременно альфы. Например, те же контрольные точки и стадии -- это паттерны (именованная связка других элементов языка, в данном случае синхронизируемого набора состояний альф как контрольной точки и отфильтрованного между двумя контрольными точками набора деятельностей как стадии). Паттерны не имеют состояний, не отслеживаются в проекте, это просто удобные для выражения каких-то идей конструкции языка, имеющие имя. Впрочем, о паттернах -- позже, сейчас важно показать, что не все встречающиеся в той или иной теории термины нужно сразу обзывать альфами, и первичный критерий тут -- это наличие у альфы состояний, которые меняются деятельностью (выполняемой работой) команды.
Состояния альф -- это граф, в котором переходы состояний произвольны. В Essence на карточках принято отображать только одну "главную цепочку", но это только для упрощения, для облегчения восприятия. Состояния альф сменяются, как в полной машине состояний, в которой возможны любые возвраты к уже пройденным состояниям, перескоки в преимущественной последовательности, итерации по сложным циклам. Деятельности меняют состояния альф, это обнаруживается контрольными вопросами этих состояний, после чего состояния продолжаются меняться деятельностями, это изменение обнаруживается контрольными вопросами -- и так все альфы постепенно продвигаются от их начальных состояний к конечным в условной их последовательности.
Альфы могут быть вложены друг в друга (связь AlphaContaiment, выражает отношение часть-целое двух альф), при этом выполняется важное правило: продвижение по состояниям вложенной альфы (части) означает какое-то продвижение по состояниям объемлющей альфы (целого). Так, продвижение требований как целого по их состояниям может быть за счёт того, что продвигаются отдельные требования -- по их состояниям. Никакой связи между состояниями частей ("подчинённых" альф, subordinate) при этом и состоянием целого (альф-"начальников") нет, кроме общего понимания, что "продвижение в изготовлении частей как-то продвигает нас в изготовлении целого".
Отношения вложенности альф -- это тоже направленный граф, одна альфа может быть частью других альф. Так, член команды может быть подальфой и команды в целом, и подальфой стейкхолдеров (ибо члены команды формально тоже стейкхолдеры, хотя и "внутренние"). Обратите внимание, что рассуждения про альф тут такие же, как про реально существующие объекты. Яблоки в задаче и яблоки в жизни очень легко перепутать, для тренинга в их использовании и нужны учителя и консультанты.
Альфы между собой связаны (AlphaAssociation) -- можно думать об этих связях, как о стрелочках на диаграмме альф, эти связи в стандарте Essence не обрабатываются, но очень полезны в описании системы альф (например, "определение системы определяет воплощение системы", "команда выполняет работы" и т.д.).
Рабочий продукт представляет (represent) собой альфу в реальном мире. Это "яблоко из жизни", "его едят" -- рабочий продукт имеет в реальном мире какую-то пользу для проекта. Рабочие продукты -- это спецификации, тесты, диаграммы и какие-то модели, базы данных и физические объекты. В Essence рабочим продуктом могут быть и какие-то мероприятия (совещания, презентации, уборка рабочего места), необязательно что-то "вещественное" типа распечатанных на бумаге документов. Одну альфу может представлять несколько рабочих продуктов, ибо у альфы в деятельности могут проявляться много различных свойств, требующих различных представлений в мире. И несколько альф могут быть представлены в одном рабочем продукте. Эта связь рабочих продуктов и их альф (WorkProductManifest) обычно определяется в рамках какой-то практики.
Помним, что в дисциплинах рабочие продукты не определяются, они ситуативны для технологии конкретной организации, использующей конкретный набор практик для работы (практика=дисциплина+технология). Зачем это разделение на дисциплину (входящие в kernel элементы) и технологию (не входящие в kernel элементы)? Одна альфа отражается в 10-15 рабочих продуктах (это можно найти в презентациях SEMAT), следовательно разговор в терминах альф существенно экономит время и мозги, снижая сложность обсуждаемого объекта -- а при необходимости можно копнуть глубже и перейти к обсуждению рабочих продуктов, погрузившись в детали. Выделение дисциплины -- это обеспечение простоты, упрощение, переход к теоретической модели, подчёркивающей только самое нужное для принятия решений. То же с деятельностями и делами: деятельности представлены десятками дел, но они требуют самостоятельного обсуждения. Деятельностям учат в ВУЗе один раз, а дела конкретны и разнообразны в каждом отдельном предпринятии, с учётом используемых инструментов, особенностей рабочих продуктов и т.д..
Рабочие продукты могут быть как входными для проекта, так и представлять собой результаты, или же быть полезными только команде, не являясь ни входными ни результирующими для проекта.
Как и альфа меняется, проходя состояния, рабочий продукт меняется, проходя уровни детальности. Рабочие продукты в ходе инженерного проекта создаются, модифицируются, уничтожаются. Они вместе с их уровнями детальности наблюдаемы, в отличие от альф, о состояниях которых мы можем судить только "по приборам" -- по рабочим продуктам.
Уровни детальности также определяются контрольными вопросами, только в случае альф состояние определяется через "и" ("да" в ответе на все вопросы), а в случае рабочих продуктов уровень детальности определяется по любому из вопросов, т.е. через "или" ("да" в ответе хотя бы на один вопрос). Состояния альф и уровни детальности рабочего продукта не связаны между собой, они про разное. Так, для согласованных со стейкхолдерами требований спецификация может быть в виде краткого резюме, более-менее подробна, в виде формальной модели. С другой стороны, может быть детальнейшие требования, которые совсем не согласованы со стейкхолдерами, и эти требования могут быть противоречивы между собой. Так что уровни детальности -- это просто уровни гранулярности и объема информации, который мы можем почерпнуть о той или иной альфе, а уж какое состояние этой альфы -- это другой вопрос. Заметим, что работа прежде всего продвигает состояние альф -- а уж будет ли продвинуто состояние альфы, если вложиться в работы по повышению детальности рабочего продукта, это большой вопрос. Повышение детальности рабочих продуктов, конечно, как-то связано с общим состоянием работ в проекте, но не впрямую.
* * *
Для тех, кто разбирался с ISO 15926, то различение и отождествление альф и рабочих продуктов очень похоже на различение и отождествление FunctionalPhysicalObject и MaterializedPhisicalObject. Напомню:
-- A [FunctionalPhysicalObject] is a [PhysicalObject] that has functional, rather than material, continuity as its basis for identity. Adjacent temporal parts of a [FunctionalPhysicalObject] need not have common matter or energy, provided the matter or energy of each temporal part fulfils the same function. Не напоминает определение альфы?
-- A [MaterializedPhysicalObject] is a [PhysicalObject] that has matter and/or energy continuity as its basis for identity. Matter or energy continuity requires some matter or energy to be common to adjacent temporal parts of the [MaterializedPhysicalObject]. Replacement of some components from time to time does not create a new identity. Это, конечно, про рабочий продукт (с точностью до того, что рабочие продукты часто бывают данными, так что на данном уровне объяснения ограничимся аналогией, а не точной онтологической спецификацией).
Примерно такое же разделение есть и в ArchiMate по отношению "реализация", только не двухуровневое, а трёхуровневое (объекты работы/альфы -- данные/рабочие продкуты -- оборудование/физческие объекты). Не забывайте, что Essence изначально разрабатывалось для программистских проектов, поэтому с различением данных и физических объектов есть проблемы не только в ArchiMate (где физических объектов вообще нет по определению, есть только информация о них), но и в Essence есть проблемы (например, подумайте про конкретного человека, выполняющего роль представителя стейкхолдеров -- всё легко на уровне "карточки представителя стейкхолдера", но сложнее, если имеется ввиду именно сам человек "из костей и мяса", that has matter and/or energy continuity as its basis for identity -- сложно его назвать "рабочим продуктом", да?).
При моделировании Essence и ArchiMate в ISO 15926 прежде всего нужно решать именно эту проблему -- не забывая, что рассуждения в 4D экстенсионализме не самые привычные, и цепочки "информация альфы -- представленность в реале" может быть отмоделирована либо в один уровень "информация на носителе" (на это претендует Essence, хотя в Essence этот носитель легко может быть понят как "данные"), либо в два уровня "информация выражена данными, а уж данные на носителе", как в ArchiMate. В любом случае, обобщение Essence и ArchiMate для системной инженерии требует тщательного онтологического разбирательства, чем и займёмся в ближайшее время.