Ситуационная инженерия методов (situational method engineering).
Инженерия методов (method engineering, http://en.wikipedia.org/wiki/Method_engineering -- и нужно понимать, что, как обычно, из программной инженерии method engineering стремительно перемещается в системную инженерию) относится так же к методологии, как системная инженерия к системному мышлению (теории систем). Напомню: Harold Lawson предложил схемку, при которой инженерия -- это движение от придуманных концепций к их воплощению в реальных системах, а системное мышление изучает реальность и придумывает соответствующие ей концепции.
Примером приложения инженерии методов к системной инженерии служит сам стандарт ISO 15288, который определяет (в соответствии с метамоделью ISO TR 24774) набор практик (методов, дисциплин, паттернов) системной инженерии в целом -- практики определения требований заинтересованных сторон, анализа требований, архитектурного проектирования и т.д. Затем в этом же стиле MFESA (Method Framework for engineering system architecture, формально текущая версия описана в книге: http://www.freebookspot.in/Books-Method%20Framework%20for%20Engineering%20System%20Architectures.htm и в подробной презентации: http://www.sei.cmu.edu/library/assets/mfesatutorialoneday20090420.pdf) определяет практики работ по архитектурному проектированию -- планирование и обеспечение ресурсами архитектурных работ, определение влияющих на архитектуру факторов, создание начальных архитектурных моделей, определение возможностей для повторного использования архитектурных элементов и т.д.. Легко можно предположить третий уровень уточнения, на котором описывается не только, что нужно делать, но и как нужно делать, например, определение возможностей для повторного использования архитектурных элементов (Task 4 MFESA) в заданном инструментальном окружении.
На каждом уровне происходит детализация требований к выполнению работы. Так, ISO 15288 не требует никаких "оценочных дел" (это требует ISO 15026, в котором указано, как он связан с ISO 15288). Но вот MFESA конкретизирует требования "оценочного дела" и описывает методы/практики/дисциплины/паттерны, связанные с "делами архитектурного качества" (architectural quality case).
Другой пример: практики жизненного цикла ISO 15288 на верхнем уровне, уточнение практики планирования проектов по Голдратту на втором уровне, и уточнение практики определения и документирования начальной длительности буфера проекта при использовании конкретного голдратт-совместимого софта управления проектами в условиях конкретной организации.
Ситуационная инженерия методов (situational method engineering) имеет под собой ту идею, что метод выполнения работ нельзя задать заранее: каждая система уникальна, имеет свой собственный уникальный жизненный цикл, и поэтому каждая из систем требует для себя уникального метода работы. Утверждается, что какие-то кусочки/фрагменты методов все-таки можно осознать и хранить для повторного использования, но для конкретной системы из таких кусочков нужно "по ситуации" собирать ее уникальный метод, который будет продвигать эту систему по ее уникальному жизненному циклу, учитывая уникальную специфику этой системы и уникальные риски в соответствии с ситуацией. Тем самым утверждается, что людям нельзя дать универсальный метод, но можно дать "конструктор методов" с достаточным количеством этих кусочков/фрагментов, который позволит сплести (weaving) необходимый специализированный метод по потребности.
Это означает, что "горбатую диаграмму" (hump diagramm) можно рисовать не только для применений (не путаем описание самой практики, и ее применение в развертке по времени!) первого уровня разбиения работ по дисциплинам/практикам/методам, но и для дисциплин/практик/методов второго уровня. Вот, например, классика жанра -- горбатая диаграмма набора методов (методологии) RUP для всего процесса:
Вот диаграмма для архитектурной работы по MFESA:
Пара определений (по мотивам онтологий MFESA и SPEM):
Метод -- это систематический, документированный, осознанный (intended) способ, которым должна быть выполнена работа. В методе вполне могут быть шаги, но заранее неизвестно, в какой момент этот метод будет выполняться в конкретном жизненном цикле. Метод -- это единица повторной используемости.
Процесс -- это способ, которым выполняется работа "в жизни". Можно сказать, что процесс -- это применение метода, происходящее-длящееся в конкретный интервал времени (и тем самым тесно переплетенное с применениями других методов). Процесс -- это всегда развертка во времени. Впрочем, описания процесса тоже могут быть повторноиспользуемы: тогда говорят о "шаблонах процесса" (в SPEM это capability patterns).
Для создания "конструктора методов", используемого при ситуационной инженерии методов должны существовать:
-- метамодель описания методов (правила описания кусочков методов и сборки из них методов более высокого уровня).
-- метамодель описания жизненного цикла (правила описания применения методов в их развертке во времени, "от методов -- к процесссу")
-- сами кусочки методов (говорят о репозитории методов)
-- шаблоны жизненного цикла
-- инструменты, позволяющие выполнять ситуационную сборку из кусочков и последующую доработку-уточнение целевого метода, включая указания о применении методов в различные моменты уникального жизненного цикла.
В неявном виде ситуационная инженерия методов предполагается уже давно. Всякие "наборы процессов" типа CMMI, PMBoK, ITIL, да и набор практик жизненного цикла системной инженерии из ISO 15288 -- это как раз оно и есть. В каждом из этих текстов стандартов явно прописано, что предлагаемые описания процессов (т.е. практики, методы, паттерны, дисциплины, "области знаний") перед употреблением нужно дорабатывать согласно принятым в организациях приемам работы (второй уровень детализации) и выбранному инструментарию (третий уровень детализации). Число уровней детализации, конечно, может быть произвольным, к тому же на каждом уровне может происходить довольно сильное ветвление -- но существует рекомендация любому заинтересованному лицу разбираться только с тремя уровнями детальности.
По факту активного использования ситуационной инженерии методов не происходило: предприятия не создавали методы "по потребности", а просто прописывали в своих инструкциях какие-то абстрактные "регламенты на все случаи жизни" и "обобщенные жизненные циклы". До примерно 2004г. не было разумных методов и "попсовых" инструментов для реальной ситуационной инженерии методов.
На сегодняшний день ситуация существенно изменилась, хотя положение нельзя назвать удовлетворительным:
-- существует огромное количество разных "наборов методов", они есть на все случаи жизни.
-- все эти "наборы методов" описаны абсолютно по-разному, эти описания не придерживались никакой мета-модели. Есть совсем немного разных мета-моделей для ситуационной инженерии методов: ISO 24744, SPEM, OPEN/OPFG, ad hoc UML схема, SMSDM ("австралийские вариации" из http://ailev.livejournal.com/749986.html), неявная метамодель (когда люди "пишут единообразно" внутри себя, но не публикуют описания правил достижения этого единообразия), отсутствие метамодели.
-- по факту существует только один вариант доступного полупопсового инструментария, подразумевающего обмен моделями методов: для метамодели OMG SPEM 2.0. Во всех остальных случаях приходится пользоваться результатами академических разработок, или какими-то "настройками" к разным моделерам общего назначения -- что явно не подразумевает обмена результатами работы по моделированию методов.
В рассмотренном нами примере ISO 15288 придерживается метамодели ISO 24774, а MFESA придерживается метамодели OPEN (впрочем, OPEN -- это упрощенный вариант ISO 24774). Для OPEN есть огромный репозиторий кусочков методов (я писал уже о нем как о "родственнике PraxOS" -- http://ailev.livejournal.com/674073.html) с 1100 описаниями отдельных методов, выполненных в соответствии с метамоделью OPEN: http://www.opfro.org. Одна беда: никакого инструментария для поддержки создания кусочков методов (method authoring) для этого огромного репозитория нет, никакого инструментария для сборки нужных для данного проекта методов и описания их применения в ходе жизненного цикла системы тоже нет. Все "руками", и поэтому данная инициатива практически мертва на сегодня.
Метамодель SPEM всем хороша, но у нее есть несколько существенных недостатков:
-- в ней не предполагается многоуровневости описания методов, аспект-ориентированного многоуровневого плетения. Любой перескок с уровня на уровень (например, сделать шаг делом, а дело превратить в мероприятие) представляет собой проблему.
-- нет совместимости с ISO TR 24774, а стандарты описания методов/практик системной инженерии используют именно этот подход (как ISO 15288, так и в какой-то мере MFESA. И это вряд ли изменится: сама проверка соответствия стандарту чаще всего проходит по ISO 15504, и ISO TR 24774 сам вырос из результатов дискуссий о том, как проверять выполнение методов в процессах. Авторов SPEM волновали совсем другие вопросы: их много больше волновало, как соединить описания методов с описаниями процессов)
-- ничего не говорится про "оценочное дело" (разве что можно указать такой артефакт)
Поэтому по факту вся ситуативная инженерия (чаще всего это разные вариации на тему RUP, облегченного агилизированного варианта OpenUP, eXtreme programming, SCRUM и прочих "софтверных процессов" -- см. http://www.eclipse.org/epf/) проходит сегодня с использованием SPEM-инструментария, а ситуативная инженерия методов соответствующей стандартам ISO "настоящей системной инженерии" либо вообще не происходит (что прямо противоречит требованиям этих стандартов), либо происходит "вручную", т.е. запредельно медленно и дорого.
Отсюда выводы и программа ближайших работ:
-- нужно создать русскоязычную терминологию для говорения о ситуативной инженерии методов.
-- нужно исхитриться описывать методы/практики/дисциплины/паттерны, соответствующие метамодели ISO 24774 (т.е. стандарты практик системной инженерии) с использованием метамодели SPEM (создать специальный "метод описания методов")
-- создать архитектуру репозитория кусочков/фрагментов методов PraxOS, пригодного для многоуровневого уточнения методов (в том числе методов системной инженерии, ибо есть и другие интересные для PraxOS методы -- например, дидактические методы, психотехнические методы и т.д.)
-- создать начальную библиотеку методов PraxOS (ISO 15288, ICM, Голдраттовское планирование проектов, MFESА и т.д.) на русском языке
-- внимательно отслеживать появление инструментария, соответствующего другим метамоделям и принять активное участие в международной инициативе SPEM 3.0, исправляющей самые вопиющие недостатки текущей метамодели (наверняка эта инициатива есть, ее только нужно найти и поддержать).
-- предоставить полностью русскоязычный инструмент для ситуативной инженерии методов (т.е. гармонизированно перевести документацию/хелпы к EPF Composer).
Примером приложения инженерии методов к системной инженерии служит сам стандарт ISO 15288, который определяет (в соответствии с метамоделью ISO TR 24774) набор практик (методов, дисциплин, паттернов) системной инженерии в целом -- практики определения требований заинтересованных сторон, анализа требований, архитектурного проектирования и т.д. Затем в этом же стиле MFESA (Method Framework for engineering system architecture, формально текущая версия описана в книге: http://www.freebookspot.in/Books-Method%20Framework%20for%20Engineering%20System%20Architectures.htm и в подробной презентации: http://www.sei.cmu.edu/library/assets/mfesatutorialoneday20090420.pdf) определяет практики работ по архитектурному проектированию -- планирование и обеспечение ресурсами архитектурных работ, определение влияющих на архитектуру факторов, создание начальных архитектурных моделей, определение возможностей для повторного использования архитектурных элементов и т.д.. Легко можно предположить третий уровень уточнения, на котором описывается не только, что нужно делать, но и как нужно делать, например, определение возможностей для повторного использования архитектурных элементов (Task 4 MFESA) в заданном инструментальном окружении.
На каждом уровне происходит детализация требований к выполнению работы. Так, ISO 15288 не требует никаких "оценочных дел" (это требует ISO 15026, в котором указано, как он связан с ISO 15288). Но вот MFESA конкретизирует требования "оценочного дела" и описывает методы/практики/дисциплины/паттерны, связанные с "делами архитектурного качества" (architectural quality case).
Другой пример: практики жизненного цикла ISO 15288 на верхнем уровне, уточнение практики планирования проектов по Голдратту на втором уровне, и уточнение практики определения и документирования начальной длительности буфера проекта при использовании конкретного голдратт-совместимого софта управления проектами в условиях конкретной организации.
Ситуационная инженерия методов (situational method engineering) имеет под собой ту идею, что метод выполнения работ нельзя задать заранее: каждая система уникальна, имеет свой собственный уникальный жизненный цикл, и поэтому каждая из систем требует для себя уникального метода работы. Утверждается, что какие-то кусочки/фрагменты методов все-таки можно осознать и хранить для повторного использования, но для конкретной системы из таких кусочков нужно "по ситуации" собирать ее уникальный метод, который будет продвигать эту систему по ее уникальному жизненному циклу, учитывая уникальную специфику этой системы и уникальные риски в соответствии с ситуацией. Тем самым утверждается, что людям нельзя дать универсальный метод, но можно дать "конструктор методов" с достаточным количеством этих кусочков/фрагментов, который позволит сплести (weaving) необходимый специализированный метод по потребности.
Это означает, что "горбатую диаграмму" (hump diagramm) можно рисовать не только для применений (не путаем описание самой практики, и ее применение в развертке по времени!) первого уровня разбиения работ по дисциплинам/практикам/методам, но и для дисциплин/практик/методов второго уровня. Вот, например, классика жанра -- горбатая диаграмма набора методов (методологии) RUP для всего процесса:
Вот диаграмма для архитектурной работы по MFESA:
Пара определений (по мотивам онтологий MFESA и SPEM):
Метод -- это систематический, документированный, осознанный (intended) способ, которым должна быть выполнена работа. В методе вполне могут быть шаги, но заранее неизвестно, в какой момент этот метод будет выполняться в конкретном жизненном цикле. Метод -- это единица повторной используемости.
Процесс -- это способ, которым выполняется работа "в жизни". Можно сказать, что процесс -- это применение метода, происходящее-длящееся в конкретный интервал времени (и тем самым тесно переплетенное с применениями других методов). Процесс -- это всегда развертка во времени. Впрочем, описания процесса тоже могут быть повторноиспользуемы: тогда говорят о "шаблонах процесса" (в SPEM это capability patterns).
Для создания "конструктора методов", используемого при ситуационной инженерии методов должны существовать:
-- метамодель описания методов (правила описания кусочков методов и сборки из них методов более высокого уровня).
-- метамодель описания жизненного цикла (правила описания применения методов в их развертке во времени, "от методов -- к процесссу")
-- сами кусочки методов (говорят о репозитории методов)
-- шаблоны жизненного цикла
-- инструменты, позволяющие выполнять ситуационную сборку из кусочков и последующую доработку-уточнение целевого метода, включая указания о применении методов в различные моменты уникального жизненного цикла.
В неявном виде ситуационная инженерия методов предполагается уже давно. Всякие "наборы процессов" типа CMMI, PMBoK, ITIL, да и набор практик жизненного цикла системной инженерии из ISO 15288 -- это как раз оно и есть. В каждом из этих текстов стандартов явно прописано, что предлагаемые описания процессов (т.е. практики, методы, паттерны, дисциплины, "области знаний") перед употреблением нужно дорабатывать согласно принятым в организациях приемам работы (второй уровень детализации) и выбранному инструментарию (третий уровень детализации). Число уровней детализации, конечно, может быть произвольным, к тому же на каждом уровне может происходить довольно сильное ветвление -- но существует рекомендация любому заинтересованному лицу разбираться только с тремя уровнями детальности.
По факту активного использования ситуационной инженерии методов не происходило: предприятия не создавали методы "по потребности", а просто прописывали в своих инструкциях какие-то абстрактные "регламенты на все случаи жизни" и "обобщенные жизненные циклы". До примерно 2004г. не было разумных методов и "попсовых" инструментов для реальной ситуационной инженерии методов.
На сегодняшний день ситуация существенно изменилась, хотя положение нельзя назвать удовлетворительным:
-- существует огромное количество разных "наборов методов", они есть на все случаи жизни.
-- все эти "наборы методов" описаны абсолютно по-разному, эти описания не придерживались никакой мета-модели. Есть совсем немного разных мета-моделей для ситуационной инженерии методов: ISO 24744, SPEM, OPEN/OPFG, ad hoc UML схема, SMSDM ("австралийские вариации" из http://ailev.livejournal.com/749986.html), неявная метамодель (когда люди "пишут единообразно" внутри себя, но не публикуют описания правил достижения этого единообразия), отсутствие метамодели.
-- по факту существует только один вариант доступного полупопсового инструментария, подразумевающего обмен моделями методов: для метамодели OMG SPEM 2.0. Во всех остальных случаях приходится пользоваться результатами академических разработок, или какими-то "настройками" к разным моделерам общего назначения -- что явно не подразумевает обмена результатами работы по моделированию методов.
В рассмотренном нами примере ISO 15288 придерживается метамодели ISO 24774, а MFESA придерживается метамодели OPEN (впрочем, OPEN -- это упрощенный вариант ISO 24774). Для OPEN есть огромный репозиторий кусочков методов (я писал уже о нем как о "родственнике PraxOS" -- http://ailev.livejournal.com/674073.html) с 1100 описаниями отдельных методов, выполненных в соответствии с метамоделью OPEN: http://www.opfro.org. Одна беда: никакого инструментария для поддержки создания кусочков методов (method authoring) для этого огромного репозитория нет, никакого инструментария для сборки нужных для данного проекта методов и описания их применения в ходе жизненного цикла системы тоже нет. Все "руками", и поэтому данная инициатива практически мертва на сегодня.
Метамодель SPEM всем хороша, но у нее есть несколько существенных недостатков:
-- в ней не предполагается многоуровневости описания методов, аспект-ориентированного многоуровневого плетения. Любой перескок с уровня на уровень (например, сделать шаг делом, а дело превратить в мероприятие) представляет собой проблему.
-- нет совместимости с ISO TR 24774, а стандарты описания методов/практик системной инженерии используют именно этот подход (как ISO 15288, так и в какой-то мере MFESA. И это вряд ли изменится: сама проверка соответствия стандарту чаще всего проходит по ISO 15504, и ISO TR 24774 сам вырос из результатов дискуссий о том, как проверять выполнение методов в процессах. Авторов SPEM волновали совсем другие вопросы: их много больше волновало, как соединить описания методов с описаниями процессов)
-- ничего не говорится про "оценочное дело" (разве что можно указать такой артефакт)
Поэтому по факту вся ситуативная инженерия (чаще всего это разные вариации на тему RUP, облегченного агилизированного варианта OpenUP, eXtreme programming, SCRUM и прочих "софтверных процессов" -- см. http://www.eclipse.org/epf/) проходит сегодня с использованием SPEM-инструментария, а ситуативная инженерия методов соответствующей стандартам ISO "настоящей системной инженерии" либо вообще не происходит (что прямо противоречит требованиям этих стандартов), либо происходит "вручную", т.е. запредельно медленно и дорого.
Отсюда выводы и программа ближайших работ:
-- нужно создать русскоязычную терминологию для говорения о ситуативной инженерии методов.
-- нужно исхитриться описывать методы/практики/дисциплины/паттерны, соответствующие метамодели ISO 24774 (т.е. стандарты практик системной инженерии) с использованием метамодели SPEM (создать специальный "метод описания методов")
-- создать архитектуру репозитория кусочков/фрагментов методов PraxOS, пригодного для многоуровневого уточнения методов (в том числе методов системной инженерии, ибо есть и другие интересные для PraxOS методы -- например, дидактические методы, психотехнические методы и т.д.)
-- создать начальную библиотеку методов PraxOS (ISO 15288, ICM, Голдраттовское планирование проектов, MFESА и т.д.) на русском языке
-- внимательно отслеживать появление инструментария, соответствующего другим метамоделям и принять активное участие в международной инициативе SPEM 3.0, исправляющей самые вопиющие недостатки текущей метамодели (наверняка эта инициатива есть, ее только нужно найти и поддержать).
-- предоставить полностью русскоязычный инструмент для ситуативной инженерии методов (т.е. гармонизированно перевести документацию/хелпы к EPF Composer).