Сразу видно, что эти знаменитые Ивар, Бертран и Ричард пытаются повторить свой успех с UML -- и точно так же с самого начала протаскивают в основу одну из идеологий, закрывая двери для других. В текущей версии протаскивается SPEM. Я делаю этот вывод из того, что в явном виде различаются practices и patterns (а в SPEM это methodContent и practices -- но они же не за слова цепляются).
Вот краткая выдержка:
Универсалии -- это то, что встречается в каждом проекте. В кандидатурах Working Program (работающий код), Project, Team, User Experience, System, Quality, Intent, Requirements.
Термин "паттерн" используется в видЕнии для обозначения общего способа действия, который применяется в разных практиках (более чем одной). Например, много практик используют проведение рабочих встреч (workshops), или полагаются на самоорганизацию команд. Описанием таких концептов, как паттерны, SEMAT хочет избегать повторения деталей в описании специфических практик.
The following rules apply to practices:
• A practice is a separate concern of a method. Examples are “development from requirements to test”, “iterative development”, “component-based development”.
• Every practice shall be described on its own, separately from any other practice.
• Every practice, unless explicitly defined as a continuous activity, has a clear beginning and an end.
• Every practice brings defined value to its stakeholders.
• Every practice must be assessable; its description must include criteria for its assessment.
• Whenever applicable, the assessment criteria must include quantitative elements; correspondingly, the description must include suitable metrics.
• Composition mechanisms for practices include merging and extension.
The following rules apply to patterns:
• Every pattern (per the definition in section 3) shall be applicable to several
different practices.
• Every pattern shall be described on its own, separately from any other pattern
and any practice to which it applies.
В разделе про оценку вдруг протаскивается tasks: "The tasks that will be subject to assessment include all important tasks of software engineering: both technical tasks (from analysis to design, implementation, documentation, verification and validation, deployment, operation, and others) and human-centered tasks such as management, training, support and communication".
Для меня это чудовищная смесь содержательных (онтологических, сущностных) и языковых (экспрессивных, выражения) вопросов. Так, "паттерны" -- это аспекты в аспект-ориентированном описании метода? Но аспекты, кажись, это тут сами практики (и рядом с ними ключевое слово concern, связанный с каждой практикой). Тогда это "вызываемые из практик библиотечные процедуры"? Но тогда почему всего два уровня вложенности (что явно недостаточно, когда начинаешь работать с SPEM!) -- ибо паттерны самодостаточны в описаниях, а практики могут только "сливаться" и "расширяться". Паттерны -- это просто "макросы"? Но тогда почему они объявляются сущностными, а не относятся к языковым средствам, которым излагаются методы?
Такое ощущение, что SEMAT хочет сделать SPEM 3, сохранив все его концептуальные недостатки (пробовали на своей шкуре, знаем), но дополнив:
-- формальной теоретической моделью (это, кстати, очень сильное требование: не оставлять формализм на потом)
-- средствами оценки (как ISO 15504 для ISO 15288 -- способ оценки вшит в стандарт, а стандарт "подогнан" под оценку)
-- хотя бы одним конкретным синтаксисом
-- консенсусом среди широкого круга разработчиков метамоделей ситуационной инженерии методов, которых "уболтают" на этот консенсус специальной оргработой и публичной дискуссией так же, как уболтали пятнадцать лет назад с UML
В любом случае, за этой инициативой нужно внимательно следить. Но почему-то после этого "видЕния Ивара, Бертрана и Ричарда" мне не кажется, что в эту инициативу нужно лезть внутрь.
