Стратегирование в ISO 24744. Первый черновик.
1. По идее, этот постинг нужно было бы писать на языке 24744, расширенном средствами стратегирования. Но поскольку этих средств сейчас нет, будем использовать bootstraping (то есть пишем уж как можем, а после создания всех необходимых продуктов -- самого DSL-24744 и описываемых в этом постинге средств расширения) переписка в "представление для погружения в репозиторий методов" будет упражнением для студентов.
2. ISO 24744 является описанием способа действий: выбранных практик работы, используемых инструментов, последовательности стадий работы, занимаемых акторами ролях и т.д. В этом плане текст, отвечающий требованиям ISO 24744 (то есть читаемый человеком рендеринг кода модели, представленного в соответствии с метамоделью ISO 24744), может быть использован как (и это обсуждается традиционно):
-- учебник метода, фиксирующий существующие знания о методе.
-- стандарт работы (возможно, требующий детализации в рамках ситуационной инженерии методов)
-- набор шаблонов (OIM), по которому будут созданы экземпляры объектов предпринятия.
Но если поглядеть на ситуации, когда метода еще нет, а фиксация в соответствии с метамоделью является просто средством записи, то результат является планом будущих работ, их программой, подразумевающей выполнение коллективом акторов (людей и инструментов). В этом плане, если он хорош, отражены сами планируемые работы (plan), используемые хитрости и уловки (ploy), перспектива (perspective), позиция (position), паттерн (pattern) -- те самые 5P, которые может означать слово "стратегия" у Минцберга (чтобы понять, о чем идет речь, когда говорится о стратегии и стратегировании в организационном контексте, см. http://ailev.livejournal.com/571136.html).
Действительно, ISO 24744 -- это стандарт, в соответствии с которым можно описывать стратегии. Форма, вмещающая необходимое содержание.
3. Несмотря на то, что в ISO 24744 присутствуют все необходимые элементы формы, в которых можно выразить стратегию (план, метод, учебный материал -- что угодно!), в нем отсутствуют элементы (примитивы, объекты, связи, средства выражения -- выберите по вкусу) для важнейшей компоненты содержания метода, обуславливающей принятие или отвержение этой стратегии/плана/учебного материала "целевой аудиторией":
обоснование метода, т.е. доказательство того, что стратегия/план/метод работает, что заявленные в методе цели достижимы описанными в методе средствами.
4. Для коммуникации "целей -- средств" имеется множество разработанных языков (languages в смысле ISO 24744), ключевыми в которых является разделение на "цели" (желаемые состояния мира) и "средства" (дела, которые приводят к желаемым состояниям мира). См. кратенький обзор в http://ailev.livejournal.com/811715.html. Собственно, данный постинг -- это в какой-то мере реализация пункта 5д из этого постинга ("переход с использующегося в текущей литературе по целям-обоснованиям с языков паттернов и структурных описаний в тех или иных нотациях на язык ситуационной инженерии методов. От существительных структур-языков-артефактов к тому, что нужно делать, глаголам").
5. Для пополнения метамодели ISO 24744 элементами метамодели обоснований был выбран набор элементов обоснований, предложенный Элияху Голдраттом в методе изображения/рендеринга стратегий в виде strategy and tactic tree (по-русски в свое время мы перевели этот способ рендеринга "карта действий и результатов", КДР). Литература на английском и примеры, а также некоторые комментарии по применению -- тут.
Можно рассматривать два варианта применения метамодельного комплекса "ISO 24744+КДР":
-- выражающая стратегию/план карта действий и результатов может быть доведена до уровня подробности метода
-- подробный метод может быть представлен в краткой и выразительной форме карты действий и результатов, представляющий стратегию/план
6. Набор элементов стратегии, выраженной как карта действий и результатов
№имя КДРопределениеname S&TTModelUnit из ISO 24744комментарий1Имя работыкраткая формулировка Работы, отглагольное существительное для наименования всей группыотсутствует (но всегда есть заголовок слайда с узлом его дерева)WorkUnitKind, атрибут Purpose2Обстоятельство что заставляет нас хотеть данного результата -- в частности, нежелательные явленияNessesary Assumptionдобавить новый атрибут к Outcome: +case как в use case или in case of ... do ...3Результатсостояние мира, которое нам нужно в результате давления обстоятельств. Это не работы!StrategyOverall_Outcome -- множество всех Outcome данной WorkUnitKindТут нужно понимать, что один вид работы -- это много результатов в ISO 24744. Так что нас интересует набор из всех этих результатов4Аргументобъяснения того, каким образом Действия будут причиной Результата. Parallels Assumptions ("параллельность" тут от "действия и результат -- параллельные стороны одной медали") Новый класс WorkUnitKindJustification со связями между Overall_Outcome и/или просто Outcome и WorkUnitKind5Работаприводящее к результату (т.е. состоянию мира)TacticWorkUnitKindне WorkUnit, ибо Outcome не у нее6Особенностисоображение, заставляющее объяснять (т.е. декомпозировать работу) дальше (все формулировки типа "Да, действия таковы, но..." -- и в ответ на это возникает следующий уровень).Sufficiency assumption (достаточность в смысле "не нужно дальше декомпозировать")добавить в WorkUnitKind атрибут +"detail needed"Ежели атрибут пуст, то эта WorkUnitKind далее не детализируется на элементы. Если атрибут не пуст и содержит критические вопросы, то нужно декомпозировать ProcessKind или TaskKind дальше.
Дальнейшие вопросы:
1. При планировании интересно показать, что "один результат достижим многими вариантами работ", а затем выбрать нужный. Текущая версия ISO 24744 не дает этого сделать, там WorkUnitKind связан с пачкой Outcome ровно наоборот: через +Result как 1 к 0..*
2. Понятия не имею, как выразить в модели данных (и на каком языке это делать) конструкции 3 и 6. Так же не понимаю, как объяснить, что Обстоятельств может быть много (т.е. атрибуты эти могут размножаться). Или это нужно делать выделением отдельного прицепленного к WorkUnitTask класса Case, такого же, как Outcome? Интересно, также, что просто Outcome, а не OutcomeKind -- я никак не уразумею эти тонкости.
3. Есть загадочное место с TaskTechniqueMappingKind, в котором предусмотрен атрибут +RecommendedUsage, чрезвычайно похожий на особого сорта Обстоятельство (case) к TaskKind. Нужно ли брать за основу именно так организованный механизм для общего вида Обстоятельств любой в том числе одиночной работы (технический прием -- это просто дело, которое нужно во многих местах), или не нужно и пусть этот случай обоснования дел так и будет особенным, я не знаю.
4. В assurance case есть еще один элемент: argument, который выражает способ доказательства "из учебника логики", чтобы легче было проверить обоснование. Например, "от противного", "перечислением всех возможных случаев" и т.д. Пока нет специалистов по докзательной логике, я в это не суюсь.
5. Это все пока противоречит правилам пополнения модели (9 раздел ISO 24774, страницы 66-67), в частности замечанию:
The elements in the SEMDM are immutable, i.e. they cannot be changed when extending the metamodel. This means that, among other things:
• No attributes can be added to standard classes. Attributes can be added to extension classes only.
• No associations can be added that involve standard classes. Associations can be added to extension classes only.
• No root enumerators can be added to standard enumerated types.
• No standard metamodel element can be changed or deleted in any way.
Так что придется принимать решение, оставлять добавку атрибутов и связей у главных элементов, или новые элементы создавать.
2. ISO 24744 является описанием способа действий: выбранных практик работы, используемых инструментов, последовательности стадий работы, занимаемых акторами ролях и т.д. В этом плане текст, отвечающий требованиям ISO 24744 (то есть читаемый человеком рендеринг кода модели, представленного в соответствии с метамоделью ISO 24744), может быть использован как (и это обсуждается традиционно):
-- учебник метода, фиксирующий существующие знания о методе.
-- стандарт работы (возможно, требующий детализации в рамках ситуационной инженерии методов)
-- набор шаблонов (OIM), по которому будут созданы экземпляры объектов предпринятия.
Но если поглядеть на ситуации, когда метода еще нет, а фиксация в соответствии с метамоделью является просто средством записи, то результат является планом будущих работ, их программой, подразумевающей выполнение коллективом акторов (людей и инструментов). В этом плане, если он хорош, отражены сами планируемые работы (plan), используемые хитрости и уловки (ploy), перспектива (perspective), позиция (position), паттерн (pattern) -- те самые 5P, которые может означать слово "стратегия" у Минцберга (чтобы понять, о чем идет речь, когда говорится о стратегии и стратегировании в организационном контексте, см. http://ailev.livejournal.com/571136.html).
Действительно, ISO 24744 -- это стандарт, в соответствии с которым можно описывать стратегии. Форма, вмещающая необходимое содержание.
3. Несмотря на то, что в ISO 24744 присутствуют все необходимые элементы формы, в которых можно выразить стратегию (план, метод, учебный материал -- что угодно!), в нем отсутствуют элементы (примитивы, объекты, связи, средства выражения -- выберите по вкусу) для важнейшей компоненты содержания метода, обуславливающей принятие или отвержение этой стратегии/плана/учебного материала "целевой аудиторией":
обоснование метода, т.е. доказательство того, что стратегия/план/метод работает, что заявленные в методе цели достижимы описанными в методе средствами.
4. Для коммуникации "целей -- средств" имеется множество разработанных языков (languages в смысле ISO 24744), ключевыми в которых является разделение на "цели" (желаемые состояния мира) и "средства" (дела, которые приводят к желаемым состояниям мира). См. кратенький обзор в http://ailev.livejournal.com/811715.html. Собственно, данный постинг -- это в какой-то мере реализация пункта 5д из этого постинга ("переход с использующегося в текущей литературе по целям-обоснованиям с языков паттернов и структурных описаний в тех или иных нотациях на язык ситуационной инженерии методов. От существительных структур-языков-артефактов к тому, что нужно делать, глаголам").
5. Для пополнения метамодели ISO 24744 элементами метамодели обоснований был выбран набор элементов обоснований, предложенный Элияху Голдраттом в методе изображения/рендеринга стратегий в виде strategy and tactic tree (по-русски в свое время мы перевели этот способ рендеринга "карта действий и результатов", КДР). Литература на английском и примеры, а также некоторые комментарии по применению -- тут.
Можно рассматривать два варианта применения метамодельного комплекса "ISO 24744+КДР":
-- выражающая стратегию/план карта действий и результатов может быть доведена до уровня подробности метода
-- подробный метод может быть представлен в краткой и выразительной форме карты действий и результатов, представляющий стратегию/план
6. Набор элементов стратегии, выраженной как карта действий и результатов
№имя КДРопределениеname S&TTModelUnit из ISO 24744комментарий1Имя работыкраткая формулировка Работы, отглагольное существительное для наименования всей группыотсутствует (но всегда есть заголовок слайда с узлом его дерева)WorkUnitKind, атрибут Purpose2Обстоятельство что заставляет нас хотеть данного результата -- в частности, нежелательные явленияNessesary Assumptionдобавить новый атрибут к Outcome: +case как в use case или in case of ... do ...3Результатсостояние мира, которое нам нужно в результате давления обстоятельств. Это не работы!StrategyOverall_Outcome -- множество всех Outcome данной WorkUnitKindТут нужно понимать, что один вид работы -- это много результатов в ISO 24744. Так что нас интересует набор из всех этих результатов4Аргументобъяснения того, каким образом Действия будут причиной Результата. Parallels Assumptions ("параллельность" тут от "действия и результат -- параллельные стороны одной медали") Новый класс WorkUnitKindJustification со связями между Overall_Outcome и/или просто Outcome и WorkUnitKind5Работаприводящее к результату (т.е. состоянию мира)TacticWorkUnitKindне WorkUnit, ибо Outcome не у нее6Особенностисоображение, заставляющее объяснять (т.е. декомпозировать работу) дальше (все формулировки типа "Да, действия таковы, но..." -- и в ответ на это возникает следующий уровень).Sufficiency assumption (достаточность в смысле "не нужно дальше декомпозировать")добавить в WorkUnitKind атрибут +"detail needed"Ежели атрибут пуст, то эта WorkUnitKind далее не детализируется на элементы. Если атрибут не пуст и содержит критические вопросы, то нужно декомпозировать ProcessKind или TaskKind дальше.
Дальнейшие вопросы:
1. При планировании интересно показать, что "один результат достижим многими вариантами работ", а затем выбрать нужный. Текущая версия ISO 24744 не дает этого сделать, там WorkUnitKind связан с пачкой Outcome ровно наоборот: через +Result как 1 к 0..*
2. Понятия не имею, как выразить в модели данных (и на каком языке это делать) конструкции 3 и 6. Так же не понимаю, как объяснить, что Обстоятельств может быть много (т.е. атрибуты эти могут размножаться). Или это нужно делать выделением отдельного прицепленного к WorkUnitTask класса Case, такого же, как Outcome? Интересно, также, что просто Outcome, а не OutcomeKind -- я никак не уразумею эти тонкости.
3. Есть загадочное место с TaskTechniqueMappingKind, в котором предусмотрен атрибут +RecommendedUsage, чрезвычайно похожий на особого сорта Обстоятельство (case) к TaskKind. Нужно ли брать за основу именно так организованный механизм для общего вида Обстоятельств любой в том числе одиночной работы (технический прием -- это просто дело, которое нужно во многих местах), или не нужно и пусть этот случай обоснования дел так и будет особенным, я не знаю.
4. В assurance case есть еще один элемент: argument, который выражает способ доказательства "из учебника логики", чтобы легче было проверить обоснование. Например, "от противного", "перечислением всех возможных случаев" и т.д. Пока нет специалистов по докзательной логике, я в это не суюсь.
5. Это все пока противоречит правилам пополнения модели (9 раздел ISO 24774, страницы 66-67), в частности замечанию:
The elements in the SEMDM are immutable, i.e. they cannot be changed when extending the metamodel. This means that, among other things:
• No attributes can be added to standard classes. Attributes can be added to extension classes only.
• No associations can be added that involve standard classes. Associations can be added to extension classes only.
• No root enumerators can be added to standard enumerated types.
• No standard metamodel element can be changed or deleted in any way.
Так что придется принимать решение, оставлять добавку атрибутов и связей у главных элементов, или новые элементы создавать.