Ситуационная инженерия методов (situational method engineering)
Ситуационная инженерия методов (SME, situational method engineering) -- это методология (разработка способов, "как делать") придерживающаяся следующих основных принципов:
а) не бывает никакого способа работы (метода), кроме как определенного ситуационно. Метод, разработанный для одной ситуации, не может быть употреблен для другой ситуации.
б) пункт (а) вовсе не означает, что знания о методе нельзя хранить и повторно использовать. Просто знание о методе должно быть разбито на модули: компоненты метода. Эти компоненты метода должны быть размещены в каталоге методов так же, как есть каталоги комплектующего оборудования (радиодеталей, задвижек, насосов, дизелей, микросхем) -- http://ailev.livejournal.com/864239.html, http://community.livejournal.com/praxos/11084.html. И метод, соответствующий ситуации, должен собираться из этих компонент.
в) в компонентах метода нужно различать акторов (люди и инструменты, являющиеся продолжением людей), работы (взятые как разворачивающиеся во времени жизненные циклы, и как практики "того, что должно делаться"), рабочие продукты aka артефакты (модели, документы), языки и нотации, руководства и т.д.
Ситуационная инженерия методов имеет свою историю примерно с середины 90-х годов. Формально ситуационная инженерия методов является частью инженерии методов (определяемой примерно так же, как программная инженерия или системная инженерия -- только по отношению к методу: способу разработки чего бы то ни было), но занимается именно конструированием метода применительно к текущей ситуации и исключает такие темы, как сравнение методов по их действенности, образование в области разработки методов и т.д. Это довольно узкая дисциплина, ее развитием занимаются пара десятков человек в мире, а научные публикации на эту тему появляются всего лишь по парочке-троечке в месяц. Последний (март 2010г.) обзор состояния ситуационной инженерии методов: http://www.jucs.org/jucs_16_3/situational_method_engineering_state/jucs_16_03_0424_0478_henderson.pdf
Менее структурированной альтернативой SME служит подход "pattern languages": в нём метод описывается в разбивке на "паттерны" -- но нет метамодели, описывающей связь этих паттернов типы этих паттернов (т.е. ничего не говорится о разделении работ, продуктов, организации и языков). В отличие от языков паттернов, описания метода в SME много более структурированы -- с соответствующими плюсами (можно как-то автоматизировать работу с этими описаниями) и минусами (переструктурированные описания невозможно "читать", только "прокликивать": не задана последовательность изложения, это "энциклопедия", а не "учебник", подробнее http://ailev.livejournal.com/845850.html).
"Метод" существенно отличается от "процесса": метод включает в себя всё нужное для выполнения работы, т.е. продукты (артефакты), процессы (жизненные циклы и используемые в них практики), организацию (люди и инструменты), используемые в работе языки и нотации. Тем самым "процесс" -- это маленькая (хотя и важная) часть от "метода".
Тем не менее, в англоязычной литературе имеются синонимы для "метода", использующие слово "процесс" с уточнениями: "development process", "delivery process", "software process". Во всех этих случаях слово "процесс" используется для указание на весь жизненный цикл разработки в целом, а не на пошаговое исполнение какой-то последовательности действий. Ситуационная инженерия методов даёт описания, трудно совместимые с традиционно понимаемыми мелко детализуемыми "логическими процессами", описываемыми в IDEF0, или еще более мелко детализуемыми (потому как для части из них подразумевается исполнение компьютером, которому всё нужно разжёвывать до мельчайших деталей и нельзя надеяться на понимание каких-то умолчаний) "физическими процессами", описываемыми в EPC/ARIS или BPMN 2.0. Описания методов конвертируются обычно не в workflow, а в projects -- и соответствующий софт умеет выгружать ситуационные методы в виде проектов MS Project. Тем самым, реализации метода (endeavor) проще рассматривать как "проекты", а не как "процессы".
От "проектирования" метод отличает большое внимание к собственно методической стороне вопроса, а не просто изложению исполнения разных работ во времени. Жизненный цикл (как одна из ипостасей развертки работ во времени, "процесса") -- только маленькая часть метода. Существенную роль играет описание практик, которые задействованы в жизненном цикле, рабочих процуктов, руководств, используемых языков и нотаций. Это обычно невозможно экспортировать в программы проектного управления. Задача метода -- дать исполнителям полное знание о том, что, когда, как и с чем делать. Задача проектного управления обычно -- сбалансировать ресурсы и уложиться вовремя, это совсем другие задачи.
SME конкурирует с "готовыми методами" (off-the-shelf-methodologies), которыми торгуют большие компании: методологии разработки, которые one-size-fit-all, и должны быть далее внедрены полностью для того, чтобы работать. Как правило, эти методологии нестандартно оформлены (описание компонент CMMI не совпадает с описанием компонент industrial eXtreme Programming, и они все не совпадают с описаниями компонент Rational Unified Process).
Был разработан ряд стандартов ситуационной инженерии методов, которые определяют "метамодель" метода -- из каких компонентов состоит метод, характеристики этих компонент, и связи между компонентами. Среди этих стандартов наиболее известны (краткий русскоязычный обзор -- http://ailev.livejournal.com/763554.html):
1. OPF -- один из ранних стандартов. Пример онлайн-каталога методов системной инженерии (более 1100 компонент методов), соответствующего стандарту OPF: http://opfro.org
2. OMG SPEM 2.0
К недостаткам этого стандарта можно отнести то, что в нём не проработаны вопросы соотнесения описываемого в нём метода и реального предпринятия (endeavor, актуального воплощения метода), нет никаких средств к работе с моделями как рабочими продуктами, ограничена иерархия практик.
Как и все остальные "инженерии", ситуационная инженерия методов как метод разработки имеет свою аббревиатуру для обозначения "автоматизированной ситуационной инженерии методов" -- CAME (computer-aided method engineering, с потерей слова "ситуационная". Ср. CASE -- computer-aided software engineeering), и свои инструменты -- CAME tools (ср. CASE tools). Главное достоинство OMG SPEM 2.0: это единственный стандарт, для которого уже сейчас существует приемлемый софт -- EPF Composer: http://ailev.livejournal.com/764182.html.
Есть довольно много описаний "лучших практик" (от RUP до SCRUM и XP, с десятком промежуточных по степени agility), выполненных в соответствии с этим стандартом -- как свободных (http://epf.eclipse.org/), так и поставляемых коммерчески вместе с "улучшителем" для EPF Composer (IBM Rational Method Composer, впрочем там не слишком много улучшений за дополнительных $400): http://www-01.ibm.com/software/awdtools/rmc/, и там идти в http://www-01.ibm.com/software/awdtools/rmc/library/.
Пример моделирования, который сделал vvagr: http://community.livejournal.com/incose_ru/10384.html
Есть еще и русский перевод help к EFP Composer.
3. ISO 24744
Не нужно путать ISO 24744 (метамодель для методов разработки) и ISO 24774 (формат описания практики, использовавшийся при создании ISO 15288). Хотя ничего не мешает использовать оба этих стандарта вместе, они друг другу не противоречат. Более того ISO 24744 гармонизирован с ISO 15288.
Это наиболее современный стандарт (есть и его перевод на русский), но для него нет программного обеспечения.
Отличительной особенностью этого стандарта является не только его принципиальная расширяемость, но и стандартизация соотношения между методом и реализацией метода (endeavour, предпринятием), а также включение описания языков и нотаций для работы с особым видом рабочих продуктов: моделями. Стандарт также задаёт графическую нотацию для описания методов. Всего его метамодель определяет 68 компонент метода (чтобы сложилось впечатление, о чем это, приведу начало этого списка, в алфавитном порядке: Action, ActionKind, Build, BuildKind, CompositeWorkProduct, KompositeWorkProductKind, Conglomerate, Constraint, Document, DocumentKind, Element, EndeavourElement, Guidline, HardwareItem, HardwareItemKind, InstrantenousStage, InstantenousStageKind, Language, MethodologyElement, Milestone и т.д. -- вот из таких кирпичиков и складываются описания методов).
Подробнее об этом стандарте тут: http://community.livejournal.com/incose_ru/16848.html (увы, обсуждение получилось не слишком учебным и структурированным).
Особенностью этого стандарта является то, что он предлагает артефакт-центрированный (а не практико-центрированный, или процесс-центрированный) метод описания: в нём главными для описания метода являются рабочие продукты, а практики и приёмы работы с ними и над ними могут меняться по ходу дела. Так, артефакт "план" может быть составлен множеством разных способов, с ним работают множество других практик, но его наличие постулируется -- и уже затем ситуационный метод строится, исходя из необходимости такого артефакта. Подробнее -- см. доклад Cesar Gonsales-Perez (презентация переведена на русский): http://www.vniiaes.ru/files/RuSEC%202010.rar
4. Из текущих инициатив по стандартизации, находящихся в русле ситуационной инженерии методов, можно отметить SEMAT: http://www.semat.org
Главной своей задачей SEMAT ставит выработку нового набора типов компонент метода (новую "схему акта деятельности"), по составу которого будет достигнут не столько "научный результат" (творцов в SEMAT более чем хватает), но общественное согласие. По факту, основатели SEMAT хотят повторить успех UML в области SME -- в начале 90-х по поводу UML договорились между собой представители самых разных методологий разработки и соответствующих им языков ОО-моделирования. Результат известен, UML сегодня "царь горы". Те же самые люди, которые занимались унификацией UML из своих разнородных подходов в середине 90-х, возглавляют теперь SEMAT. Тем самым развитие SME приобретает еще и социальное измерение: способ задания в SEMAT онтологии метода упирает на "разделяемость" (shared) множеством людей, как основное свойство онтологии -- когда они получат результат (набор компонент метода), по факту под этим результатом подпишутся множество людей, и SEMAT будет претендовать на статус "стандарта де-факто".
Ситуационная инженерия методов еще очень молода. 15 лет для такой дисциплины еще детский срок. Я думаю, в ситуационной инженерии методов всё только-только начинается. Ибо "жизненные циклы" нельзя выразить надлежащим образом ни в проектной, ни процессной парадигмах.
* * *
Данный постинг появился потому, что несколько месяцев назад я обнаружил, что по SME у меня в Лабораторном Журнале есть только ряд разрозненных заметок, но ни одного связного текста (одноименный с настоящим постинг от 3 ноября 2009г. содержит не столько какое-то связное описание, сколько заявление программу работ, которая потихоньку выполнялась -- http://ailev.livejournal.com/750878.html).
Я воспользовался методом GTD (get things done -- метод управления собственными работами): в моём списке задач тогда появилась запись о необходимости хоть как-то обзорного постинга -- в части "важное, но не срочное", и вот сегодня это важное дело было выполнено. Обратите внимание:
-- GTD не является традиционным методом управления процессом или методом управления проектами. Это управление делами (вариант issue tracking). Тем не менее, метод GTD удивительно практичен! Любителям "проектного" или "процессного" подходов рекомендую поломать голову, что же это за такой зверь с их точки зрения, и -- главное! -- нужно ли его упаковывать в такую привычную им парадигму "проектов" или "процессов". Так же и с SME: эта парадигма не так легко вписывается в "проектное управление" или "процессное управление как BPM с workflow". Кошка SME гуляет сама по себе, как и GTD -- хотя и на других путях.
-- ситуационная инженерия методов уверенно называет GTD методом: в книжках по GTD дается обширный каталог компонент метода GTD (т.е. продуктов работы, практик, жизненного цикла, организации -- как подготовить к работе с GTD себя любимого и какие инструменты взять, языков и нотаций и т.д.), после чего каждому человеку "по его ситуации" предлагается соорудить свой персональный метод, основываясь на заведомо избыточном книжном описании. У меня GTD реализован в минимальном виде: один файл, в котором есть три раздела: "к исполнению", "прокисло", "выполнено" -- и по строчке на описание каждого дела, которые я текстовым редактором разношу между этими разделами, понимая при этом, что верхушка раздела "к исполнению" просматривается по нескольку раз в день, а низ -- несколько раз в год. Это ситуационная реализация компонент метода GTD: основные рабочие продукты, предлагаемые практики, инструменты, языки и нотации соблюдены -- реальные сущности в моём предпринятии GTD классифицируются описанными в книжке классами компонент метода.
* * *
Есть многое на свете, друг Горацио, что и не снилось нашим проектникам и процессникам!
а) не бывает никакого способа работы (метода), кроме как определенного ситуационно. Метод, разработанный для одной ситуации, не может быть употреблен для другой ситуации.
б) пункт (а) вовсе не означает, что знания о методе нельзя хранить и повторно использовать. Просто знание о методе должно быть разбито на модули: компоненты метода. Эти компоненты метода должны быть размещены в каталоге методов так же, как есть каталоги комплектующего оборудования (радиодеталей, задвижек, насосов, дизелей, микросхем) -- http://ailev.livejournal.com/864239.html, http://community.livejournal.com/praxos/11084.html. И метод, соответствующий ситуации, должен собираться из этих компонент.
в) в компонентах метода нужно различать акторов (люди и инструменты, являющиеся продолжением людей), работы (взятые как разворачивающиеся во времени жизненные циклы, и как практики "того, что должно делаться"), рабочие продукты aka артефакты (модели, документы), языки и нотации, руководства и т.д.
Ситуационная инженерия методов имеет свою историю примерно с середины 90-х годов. Формально ситуационная инженерия методов является частью инженерии методов (определяемой примерно так же, как программная инженерия или системная инженерия -- только по отношению к методу: способу разработки чего бы то ни было), но занимается именно конструированием метода применительно к текущей ситуации и исключает такие темы, как сравнение методов по их действенности, образование в области разработки методов и т.д. Это довольно узкая дисциплина, ее развитием занимаются пара десятков человек в мире, а научные публикации на эту тему появляются всего лишь по парочке-троечке в месяц. Последний (март 2010г.) обзор состояния ситуационной инженерии методов: http://www.jucs.org/jucs_16_3/situational_method_engineering_state/jucs_16_03_0424_0478_henderson.pdf
Менее структурированной альтернативой SME служит подход "pattern languages": в нём метод описывается в разбивке на "паттерны" -- но нет метамодели, описывающей связь этих паттернов типы этих паттернов (т.е. ничего не говорится о разделении работ, продуктов, организации и языков). В отличие от языков паттернов, описания метода в SME много более структурированы -- с соответствующими плюсами (можно как-то автоматизировать работу с этими описаниями) и минусами (переструктурированные описания невозможно "читать", только "прокликивать": не задана последовательность изложения, это "энциклопедия", а не "учебник", подробнее http://ailev.livejournal.com/845850.html).
"Метод" существенно отличается от "процесса": метод включает в себя всё нужное для выполнения работы, т.е. продукты (артефакты), процессы (жизненные циклы и используемые в них практики), организацию (люди и инструменты), используемые в работе языки и нотации. Тем самым "процесс" -- это маленькая (хотя и важная) часть от "метода".
Тем не менее, в англоязычной литературе имеются синонимы для "метода", использующие слово "процесс" с уточнениями: "development process", "delivery process", "software process". Во всех этих случаях слово "процесс" используется для указание на весь жизненный цикл разработки в целом, а не на пошаговое исполнение какой-то последовательности действий. Ситуационная инженерия методов даёт описания, трудно совместимые с традиционно понимаемыми мелко детализуемыми "логическими процессами", описываемыми в IDEF0, или еще более мелко детализуемыми (потому как для части из них подразумевается исполнение компьютером, которому всё нужно разжёвывать до мельчайших деталей и нельзя надеяться на понимание каких-то умолчаний) "физическими процессами", описываемыми в EPC/ARIS или BPMN 2.0. Описания методов конвертируются обычно не в workflow, а в projects -- и соответствующий софт умеет выгружать ситуационные методы в виде проектов MS Project. Тем самым, реализации метода (endeavor) проще рассматривать как "проекты", а не как "процессы".
От "проектирования" метод отличает большое внимание к собственно методической стороне вопроса, а не просто изложению исполнения разных работ во времени. Жизненный цикл (как одна из ипостасей развертки работ во времени, "процесса") -- только маленькая часть метода. Существенную роль играет описание практик, которые задействованы в жизненном цикле, рабочих процуктов, руководств, используемых языков и нотаций. Это обычно невозможно экспортировать в программы проектного управления. Задача метода -- дать исполнителям полное знание о том, что, когда, как и с чем делать. Задача проектного управления обычно -- сбалансировать ресурсы и уложиться вовремя, это совсем другие задачи.
SME конкурирует с "готовыми методами" (off-the-shelf-methodologies), которыми торгуют большие компании: методологии разработки, которые one-size-fit-all, и должны быть далее внедрены полностью для того, чтобы работать. Как правило, эти методологии нестандартно оформлены (описание компонент CMMI не совпадает с описанием компонент industrial eXtreme Programming, и они все не совпадают с описаниями компонент Rational Unified Process).
Был разработан ряд стандартов ситуационной инженерии методов, которые определяют "метамодель" метода -- из каких компонентов состоит метод, характеристики этих компонент, и связи между компонентами. Среди этих стандартов наиболее известны (краткий русскоязычный обзор -- http://ailev.livejournal.com/763554.html):
1. OPF -- один из ранних стандартов. Пример онлайн-каталога методов системной инженерии (более 1100 компонент методов), соответствующего стандарту OPF: http://opfro.org
2. OMG SPEM 2.0
К недостаткам этого стандарта можно отнести то, что в нём не проработаны вопросы соотнесения описываемого в нём метода и реального предпринятия (endeavor, актуального воплощения метода), нет никаких средств к работе с моделями как рабочими продуктами, ограничена иерархия практик.
Как и все остальные "инженерии", ситуационная инженерия методов как метод разработки имеет свою аббревиатуру для обозначения "автоматизированной ситуационной инженерии методов" -- CAME (computer-aided method engineering, с потерей слова "ситуационная". Ср. CASE -- computer-aided software engineeering), и свои инструменты -- CAME tools (ср. CASE tools). Главное достоинство OMG SPEM 2.0: это единственный стандарт, для которого уже сейчас существует приемлемый софт -- EPF Composer: http://ailev.livejournal.com/764182.html.
Есть довольно много описаний "лучших практик" (от RUP до SCRUM и XP, с десятком промежуточных по степени agility), выполненных в соответствии с этим стандартом -- как свободных (http://epf.eclipse.org/), так и поставляемых коммерчески вместе с "улучшителем" для EPF Composer (IBM Rational Method Composer, впрочем там не слишком много улучшений за дополнительных $400): http://www-01.ibm.com/software/awdtools/rmc/, и там идти в http://www-01.ibm.com/software/awdtools/rmc/library/.
Пример моделирования, который сделал vvagr: http://community.livejournal.com/incose_ru/10384.html
Есть еще и русский перевод help к EFP Composer.
3. ISO 24744
Не нужно путать ISO 24744 (метамодель для методов разработки) и ISO 24774 (формат описания практики, использовавшийся при создании ISO 15288). Хотя ничего не мешает использовать оба этих стандарта вместе, они друг другу не противоречат. Более того ISO 24744 гармонизирован с ISO 15288.
Это наиболее современный стандарт (есть и его перевод на русский), но для него нет программного обеспечения.
Отличительной особенностью этого стандарта является не только его принципиальная расширяемость, но и стандартизация соотношения между методом и реализацией метода (endeavour, предпринятием), а также включение описания языков и нотаций для работы с особым видом рабочих продуктов: моделями. Стандарт также задаёт графическую нотацию для описания методов. Всего его метамодель определяет 68 компонент метода (чтобы сложилось впечатление, о чем это, приведу начало этого списка, в алфавитном порядке: Action, ActionKind, Build, BuildKind, CompositeWorkProduct, KompositeWorkProductKind, Conglomerate, Constraint, Document, DocumentKind, Element, EndeavourElement, Guidline, HardwareItem, HardwareItemKind, InstrantenousStage, InstantenousStageKind, Language, MethodologyElement, Milestone и т.д. -- вот из таких кирпичиков и складываются описания методов).
Подробнее об этом стандарте тут: http://community.livejournal.com/incose_ru/16848.html (увы, обсуждение получилось не слишком учебным и структурированным).
Особенностью этого стандарта является то, что он предлагает артефакт-центрированный (а не практико-центрированный, или процесс-центрированный) метод описания: в нём главными для описания метода являются рабочие продукты, а практики и приёмы работы с ними и над ними могут меняться по ходу дела. Так, артефакт "план" может быть составлен множеством разных способов, с ним работают множество других практик, но его наличие постулируется -- и уже затем ситуационный метод строится, исходя из необходимости такого артефакта. Подробнее -- см. доклад Cesar Gonsales-Perez (презентация переведена на русский): http://www.vniiaes.ru/files/RuSEC%202010.rar
4. Из текущих инициатив по стандартизации, находящихся в русле ситуационной инженерии методов, можно отметить SEMAT: http://www.semat.org
Главной своей задачей SEMAT ставит выработку нового набора типов компонент метода (новую "схему акта деятельности"), по составу которого будет достигнут не столько "научный результат" (творцов в SEMAT более чем хватает), но общественное согласие. По факту, основатели SEMAT хотят повторить успех UML в области SME -- в начале 90-х по поводу UML договорились между собой представители самых разных методологий разработки и соответствующих им языков ОО-моделирования. Результат известен, UML сегодня "царь горы". Те же самые люди, которые занимались унификацией UML из своих разнородных подходов в середине 90-х, возглавляют теперь SEMAT. Тем самым развитие SME приобретает еще и социальное измерение: способ задания в SEMAT онтологии метода упирает на "разделяемость" (shared) множеством людей, как основное свойство онтологии -- когда они получат результат (набор компонент метода), по факту под этим результатом подпишутся множество людей, и SEMAT будет претендовать на статус "стандарта де-факто".
Ситуационная инженерия методов еще очень молода. 15 лет для такой дисциплины еще детский срок. Я думаю, в ситуационной инженерии методов всё только-только начинается. Ибо "жизненные циклы" нельзя выразить надлежащим образом ни в проектной, ни процессной парадигмах.
* * *
Данный постинг появился потому, что несколько месяцев назад я обнаружил, что по SME у меня в Лабораторном Журнале есть только ряд разрозненных заметок, но ни одного связного текста (одноименный с настоящим постинг от 3 ноября 2009г. содержит не столько какое-то связное описание, сколько заявление программу работ, которая потихоньку выполнялась -- http://ailev.livejournal.com/750878.html).
Я воспользовался методом GTD (get things done -- метод управления собственными работами): в моём списке задач тогда появилась запись о необходимости хоть как-то обзорного постинга -- в части "важное, но не срочное", и вот сегодня это важное дело было выполнено. Обратите внимание:
-- GTD не является традиционным методом управления процессом или методом управления проектами. Это управление делами (вариант issue tracking). Тем не менее, метод GTD удивительно практичен! Любителям "проектного" или "процессного" подходов рекомендую поломать голову, что же это за такой зверь с их точки зрения, и -- главное! -- нужно ли его упаковывать в такую привычную им парадигму "проектов" или "процессов". Так же и с SME: эта парадигма не так легко вписывается в "проектное управление" или "процессное управление как BPM с workflow". Кошка SME гуляет сама по себе, как и GTD -- хотя и на других путях.
-- ситуационная инженерия методов уверенно называет GTD методом: в книжках по GTD дается обширный каталог компонент метода GTD (т.е. продуктов работы, практик, жизненного цикла, организации -- как подготовить к работе с GTD себя любимого и какие инструменты взять, языков и нотаций и т.д.), после чего каждому человеку "по его ситуации" предлагается соорудить свой персональный метод, основываясь на заведомо избыточном книжном описании. У меня GTD реализован в минимальном виде: один файл, в котором есть три раздела: "к исполнению", "прокисло", "выполнено" -- и по строчке на описание каждого дела, которые я текстовым редактором разношу между этими разделами, понимая при этом, что верхушка раздела "к исполнению" просматривается по нескольку раз в день, а низ -- несколько раз в год. Это ситуационная реализация компонент метода GTD: основные рабочие продукты, предлагаемые практики, инструменты, языки и нотации соблюдены -- реальные сущности в моём предпринятии GTD классифицируются описанными в книжке классами компонент метода.
* * *
Есть многое на свете, друг Горацио, что и не снилось нашим проектникам и процессникам!