Методологическое
Нижеприведенные тезисы -- констатация направлений дальнейшей работы, не более. Они тут приведены исключительно как материал для обдумывания.
1. Под "методом" я понимаю набор компонент метода, описывающих способ достижения какой-то цели. Это понимание соответствует ISO 24744, только существенно расширенному (например, с добавлением таких важных компонент метода, как обоснования). Вот это расширение нужно проделать в явном виде, чтобы можно было отображать любые аспекты метода (см. следующий пункт про "аспекты" и архитектурные описания).
2. Поскольку метод -- это сложная система из его компонент, описания методов часто доступны только аспектные в смысле ISO 42010 -- в одной книжке можно найти описание экономическое, в другой -- технологическое, в третьей -- организационные (распределение ответственностей и полномочий среди акторов) и т.д. Нужно разобраться с тем, как склеивать аспектные описания, как применить ISO 42010 к методическим архитектурам. Этот же вопрос можно переформулировать как "язык архитектурного описания/модульный язык -- т.е. набор DSL -- для описания разных аспектов метода" (по мотивам предложений Voelter для модульных DSL -- http://ailev.livejournal.com/871316.html).
Это всё ведет к "языкоориентированному методологизированию" с одной стороны, и обсуждению "методических архитектур" с другой стороны.
3. Мереология методов -- терра инкогнита. Метод все-таки представляет собой что-то типа "языка программирования деятельности" (а ситуционный метод -- что-то типа программы на этом языке, см. предыдущий пункт). Для языков же программирования и программ существует совсем другая мереология, нежели для статичного состояния физических объектов. Так, каскадирование (в смысле, введенном Voelter для модульных DSL) трудно представить себе для физических объектов, но в каком-то смысле "текст на микропрограммном языке" находится как бы "внутри" текста на языке программирования. Я считаю, что это самое мутное место -- и разбирательство тут означает что-то типа создания дополнения Части 2 из ISO 15926 для работы с information_representation и languages -- в том числе с концепцией "интерпретации" -- в вариантах "трансляции" и "исполнения" (включая и "исполнение" и "трансляцию" как "интерпретацию в особых смыслах").
В частности, эта мереологическая дискуссия должна привести к набору понятий, в терминах которых можно выразить нахождение ситуативного метода в составе полного каталога компонент методов.
4. Хоть какое-то разбирательство с предыдущим "онтологическим" пунктом позволит внятно ответить на вопрос про множественность и единственность числа понятия "метод", да и сам предмет каталогизации в понятиях "каталог компонент метода/методов", "каталог метода/методов". Нужно определиться с построением специализированного RDL (формата ISO 15926) как каталога методов -- какие требования нужно предъявлять к RDL, чтобы считать его соответствующим стандарту каталогом методов?!
5. Огромное количество литературы -- это "неполное собрание невыделенных компонент метода". Для того, чтобы с таким собранием работать дальше, нужно сделать следующее:
а) оттранслировать эти компоненты в пригодный для связывания с другими (недостающими) компонентами язык (например, выполнив mapping в ISO 15926)
б) объединить эти компоненты с недостающими (например, ежели описаны виды рабочих продуктов, то объединить с описанием практик, временных циклов и акторов. Если описаны практики, то объединить с описанием рабочих продуктов, временных циклов и акторов -- и т.д.). Это означает оформление в виде, подразумевающем набор ситуационного метода из данных компонент.
Преимущество такого подхода -- это четкое понимание того, "чего в супе не хватает" для полноценной работы по всем этим бесчисленным стандартам, руководствам, учебникам, описаниям практик и т.д.
Еще одно преимущество такой переработки: любое "учебное пособие" избыточно -- оно описывает не ситуативный метод (который -- "бери и делай"), но заранее избыточный набор компонент метода, из которых можно собрать множество разных ситуативных методов сообразно разным ситуациям. Тем самым переработка в явные компоненты метода предотвращает попытки "немедленного применения" без соответствующей адаптации к ситуации и -- главное -- дополнения недостающими компонентами метода, описанными в каких-то других источниках.
6. Использование "паттернов" (pattern languages) -- это недооформленная работа с методами. Поскольку паттерны -- это явный заход на методы, они оказываются крайне полезны. Поскольку паттерны недооформлены, это движение все время на грани вымирания, "вечно перспективно". Все "паттерны" нужно явно переоформлять в набор компонентов методов.
7. Все ответы на поставленные вопросы нужно оформлять как метод -- в меру текущего понимания, что такое метод. По мере продвижения в понимании, нужно этот "метод ситационной инженерии методов" соответственно изменять. Как и в случае любого "языка программирования, написанном на нём самом", от этого возникает множество чудесных и полезных следствий -- но выполнить это самоописание очень трудно.
8. Поскольку сами методы без того, чтобы кто-то (люди или машины) их поняли и применили, бесполезны -- требуется разобраться с их освоением и применением:
а) программированием компьютеров методами
б) программированием (хи-хи, нейролингвистическим ;) людей, то есть образованием/обучением
В этом плане нужно разобраться,
i) какую часть каталогам методов держать собственно в каталоге-экзокортексе, а какую -- в приложении/голове
ii) как, собственно, проводить это программирование/обучение
Не нужно и говорить, что результаты этого разбирательства тоже нужно оформлять как набор компонентов метода...
И тут может выясниться, что подробные и детальные "по науке" описания метода полностью несовместимы с их усвоением простыми людьми...
* * *
Из приоритетов мне представляется самым существенным разбирательство с многоаспектным описанием метода, причем каждый аспект поддерживается отдельным методом описания, а методы описания состоят из видов моделей (в терминах ISO 42010). Тем самым нужно разработать модульный язык (т.е. связный набор DSL) для описания метода как (избыточного для каждой ситуации) набора компонент метода. При этом хорошо бы еще понять что-то про модульный язык -- пока я понимаю только, что он крайне похож на "архитектурные языки", но мне кажется, что простого понимания этого сходства будет маловато. Сама идея взять ArchiMate или SysML и бодро начинать переписывать методы на подобных языках мне представляется бредовой, а сами эти языки кажутся не слишком похожими на "модульный язык". Графический язык из ISO 24744 изобилует упоминаниями "такие-то и такие-то концепты в нашем языке не представлены, ибо для их выражения существуют другие языки", плюс мы же задумали расширения! Так что придется подумать над этим в первую голову.
1. Под "методом" я понимаю набор компонент метода, описывающих способ достижения какой-то цели. Это понимание соответствует ISO 24744, только существенно расширенному (например, с добавлением таких важных компонент метода, как обоснования). Вот это расширение нужно проделать в явном виде, чтобы можно было отображать любые аспекты метода (см. следующий пункт про "аспекты" и архитектурные описания).
2. Поскольку метод -- это сложная система из его компонент, описания методов часто доступны только аспектные в смысле ISO 42010 -- в одной книжке можно найти описание экономическое, в другой -- технологическое, в третьей -- организационные (распределение ответственностей и полномочий среди акторов) и т.д. Нужно разобраться с тем, как склеивать аспектные описания, как применить ISO 42010 к методическим архитектурам. Этот же вопрос можно переформулировать как "язык архитектурного описания/модульный язык -- т.е. набор DSL -- для описания разных аспектов метода" (по мотивам предложений Voelter для модульных DSL -- http://ailev.livejournal.com/871316.html).
Это всё ведет к "языкоориентированному методологизированию" с одной стороны, и обсуждению "методических архитектур" с другой стороны.
3. Мереология методов -- терра инкогнита. Метод все-таки представляет собой что-то типа "языка программирования деятельности" (а ситуционный метод -- что-то типа программы на этом языке, см. предыдущий пункт). Для языков же программирования и программ существует совсем другая мереология, нежели для статичного состояния физических объектов. Так, каскадирование (в смысле, введенном Voelter для модульных DSL) трудно представить себе для физических объектов, но в каком-то смысле "текст на микропрограммном языке" находится как бы "внутри" текста на языке программирования. Я считаю, что это самое мутное место -- и разбирательство тут означает что-то типа создания дополнения Части 2 из ISO 15926 для работы с information_representation и languages -- в том числе с концепцией "интерпретации" -- в вариантах "трансляции" и "исполнения" (включая и "исполнение" и "трансляцию" как "интерпретацию в особых смыслах").
В частности, эта мереологическая дискуссия должна привести к набору понятий, в терминах которых можно выразить нахождение ситуативного метода в составе полного каталога компонент методов.
4. Хоть какое-то разбирательство с предыдущим "онтологическим" пунктом позволит внятно ответить на вопрос про множественность и единственность числа понятия "метод", да и сам предмет каталогизации в понятиях "каталог компонент метода/методов", "каталог метода/методов". Нужно определиться с построением специализированного RDL (формата ISO 15926) как каталога методов -- какие требования нужно предъявлять к RDL, чтобы считать его соответствующим стандарту каталогом методов?!
5. Огромное количество литературы -- это "неполное собрание невыделенных компонент метода". Для того, чтобы с таким собранием работать дальше, нужно сделать следующее:
а) оттранслировать эти компоненты в пригодный для связывания с другими (недостающими) компонентами язык (например, выполнив mapping в ISO 15926)
б) объединить эти компоненты с недостающими (например, ежели описаны виды рабочих продуктов, то объединить с описанием практик, временных циклов и акторов. Если описаны практики, то объединить с описанием рабочих продуктов, временных циклов и акторов -- и т.д.). Это означает оформление в виде, подразумевающем набор ситуационного метода из данных компонент.
Преимущество такого подхода -- это четкое понимание того, "чего в супе не хватает" для полноценной работы по всем этим бесчисленным стандартам, руководствам, учебникам, описаниям практик и т.д.
Еще одно преимущество такой переработки: любое "учебное пособие" избыточно -- оно описывает не ситуативный метод (который -- "бери и делай"), но заранее избыточный набор компонент метода, из которых можно собрать множество разных ситуативных методов сообразно разным ситуациям. Тем самым переработка в явные компоненты метода предотвращает попытки "немедленного применения" без соответствующей адаптации к ситуации и -- главное -- дополнения недостающими компонентами метода, описанными в каких-то других источниках.
6. Использование "паттернов" (pattern languages) -- это недооформленная работа с методами. Поскольку паттерны -- это явный заход на методы, они оказываются крайне полезны. Поскольку паттерны недооформлены, это движение все время на грани вымирания, "вечно перспективно". Все "паттерны" нужно явно переоформлять в набор компонентов методов.
7. Все ответы на поставленные вопросы нужно оформлять как метод -- в меру текущего понимания, что такое метод. По мере продвижения в понимании, нужно этот "метод ситационной инженерии методов" соответственно изменять. Как и в случае любого "языка программирования, написанном на нём самом", от этого возникает множество чудесных и полезных следствий -- но выполнить это самоописание очень трудно.
8. Поскольку сами методы без того, чтобы кто-то (люди или машины) их поняли и применили, бесполезны -- требуется разобраться с их освоением и применением:
а) программированием компьютеров методами
б) программированием (хи-хи, нейролингвистическим ;) людей, то есть образованием/обучением
В этом плане нужно разобраться,
i) какую часть каталогам методов держать собственно в каталоге-экзокортексе, а какую -- в приложении/голове
ii) как, собственно, проводить это программирование/обучение
Не нужно и говорить, что результаты этого разбирательства тоже нужно оформлять как набор компонентов метода...
И тут может выясниться, что подробные и детальные "по науке" описания метода полностью несовместимы с их усвоением простыми людьми...
* * *
Из приоритетов мне представляется самым существенным разбирательство с многоаспектным описанием метода, причем каждый аспект поддерживается отдельным методом описания, а методы описания состоят из видов моделей (в терминах ISO 42010). Тем самым нужно разработать модульный язык (т.е. связный набор DSL) для описания метода как (избыточного для каждой ситуации) набора компонент метода. При этом хорошо бы еще понять что-то про модульный язык -- пока я понимаю только, что он крайне похож на "архитектурные языки", но мне кажется, что простого понимания этого сходства будет маловато. Сама идея взять ArchiMate или SysML и бодро начинать переписывать методы на подобных языках мне представляется бредовой, а сами эти языки кажутся не слишком похожими на "модульный язык". Графический язык из ISO 24744 изобилует упоминаниями "такие-то и такие-то концепты в нашем языке не представлены, ибо для их выражения существуют другие языки", плюс мы же задумали расширения! Так что придется подумать над этим в первую голову.