Обсуждение

Понятно, в работе над Essence отдельные усилия прилагались к тому, чтобы сохранить количество элементов базового ядра минимальным. Однако эти соображения никогда, насколько мне известно, не были самыми приоритетными. В связи с этим мои комментарии. 1. Interest. Честно говоря, я не понимаю, почему интерес должен быть альфой верхнего уровня (объектом первого класса). По-моему, это скорее подальфа Opportunity Можно аргументацию? Тот аргумент, что в ISO 42010 он таковым является кажется мне слабоватым. Где в нем Opportunity? Просто не перешли к объектам более высокого класса? 2. Principle - очень полезная штука. В базовом ядре Essence его нет, что логично, т.к. трудно себе представить какие-то универсальные принципы. А идеи наличия приниципов заложены в чеклисты различных альф. При этом при описании метода конкорга было бы правильно иметь возмоность его выразить. Стандартный механизм расширения - через паттерны. Надо бы подумать, как это можно сделать.

Concern в area of concern базовый -- разные вьюшки как раз отвечают на разные concerns. Concern это часть upper ontology обычно, совсем отдельные практики работы с ними. И если уж говорить, чья там подальфа, то интерес это не часть "возможности", а часть стейкхолдера (узнаём интересы стейкхолдера -- значит лучше знаем стейкхолдера). Но и тут не всё будет сходиться (отношение стейкхолдеров к интересам -- N:M, многие ко многим).

Про concern убедительно. Интересно, получится ли в результате RUP со всеми его проблемами, если все "недостающие" сущности в ядро включить...

Надо плевать на текущее ядро, оно начало уже застывать в его нынешней кривой форме. Нужно просто идти дальше. Сил бороться с пожилыми софтверными гуру у меня нет, я на них огромное количество времени убил -- и без толку, наши результаты не восприняты (даже Bud Lowson сдался, как мне кажется). Я плюнул для себя на всю тамошнюю тусовку, когда они согласились, что требования идут как в софтовой инженерии, а системная инженерия делается путём переименовывания софтверной системы в просто систему. То есть область интересов инженерного решения они не тронули. Получается невероятно криво. Так что там в Essence сейчас явный тупик, и нужно выбираться из этого тупика самостоятельно. Например, перегружая всё полезное (включая работу с карточками, основные альфы и т.д.) в ArchiMate в виде стиля архитектурного моделирования. Тоже плохо, но там хотя бы моделеров побольше и тусовка не меньше ))) Пока там основная найденная грабля -- это плохая совместимость с case management, для этого много чего нужно поправить: -- разобраться с ActivitySpaces и Actitivites, ибо там странное (Activity Spaces это обычно стадии, но в связи с отказом по факту от гейтов и перехода в concurrent engineering к "все стадии в параллель" замечание "стадии могут перекрываться" приводит к полному отказу от стадийности. Похоже, что стадии это mental framework, о чём намекает ISO 24744. Но это ж нужно обсуждать и выправлять! Сейчас же это что-то посередине между проектным подходом (activity spaces) и процессным подходом (диаграммы последовательности шагов-activity). Кейс-менеджмент, кейс-файл не поддержан в явном виде, бардак. И это при всех заявлениях Ивара, что он против процессного подхода! Что он понимает под процессным подходом-то? -- понять, почему с альфами появляются три типа вместо унифицированного одного направленного графа "контрольных точек" (контрольные вопросы для состояний -- это ж такие подальфы задаются, темпоральные части состояний альф -- т.е. темпоральные части полных темпоральных частей! Обычно такое моделируется milestone. А сами базовые альфы -- полные темпоральные части надальфы "проект"). Там намудрено сильно, нужно явно коленвал выправить.

Собствено, я и предлагал в Бекасово в прошлом году создать свой вариант, который и предъявить строгой общественности. Спорить по частным вопросам с сущетвующей командой не дает inferential distance. При этом я нахожу для себя все еще нахожу пользу от участия в некоторых активностях SEMAT. Но это уже оффтопик.

Касательно Principle, я думаю вот что. 1. В 42010 в разделе 4.2.1 к тому, что может быть отнесено к архитектуре относят среди прочего: -- principles of the system's organization or design; -- principles governing the evolution of the system over its life cycle. Первый пункт явно укладывается в понимание архитектуры как штуки, позволяющей делить работы с минимальными рисками. И design principles здесь явно будут подальфой архитектуры. Кстати: (http://www.cfk-convention.com/fileadmin/Convention_2014/Referenten/Vortraege/CFK_Conv2014_Bieling.pdf) - обратите внимание на слайд 8. Второй пункт похоже призван отвечать на консерны, связанные с ЖЦ системы. Таким образом, он оказывается на стыке архитектуры и Way of Working. 2. У Алтфелда про это говорится вот что: Design principles are established in order to: • standardise design solutions throughout the aircraft; • harmonise interfaces; • formalise, present and demonstrate technical solutions; • share the design rationale; • provide a basis in order to exchange and capitalise knowledge among all stakeholders; • provide directives or constraints needed to model the elementary parts in solid 3D. Design principles for in-house use often include the rationale for the principles, while design principles provided to supplies only contain rules and recommendations which must be respected by the suppliers, bit no rationale. Похоже, это соответствует первому пункту. 3. Касательно Архимейта, похоже, что приведенное ими определение вполне соответствует тому, что сказано в 42010 и у Алтфелда: заменив на слайде 8 из ссылки слово Aircraft на слово Enterprise, получим вполне логичное обоснование. При этом, думаю, что принципы, лежащие в основе практик - не те же самые принципы, о которых речь в 42010 и у Алтфелда. Они тоже есть, но это другое понятие. И моделировать их через Principle не понятно как, ведь Principle это Motivation Extension, а значит это про комментирование и обоснование архитектуры, а не про сами решения.

Принцип тем самым -- унификация вариантов решений. Но я трактую точно так же: если есть вариант выбрать разные практики, то мы унифицируем, какую практику выбрать. Выбор практики -- это как раз архитектурное решение. Если у нас архитектурное описание организационно-технической системы, то она представляет собой набор практик (а развитие такой системы -- это постановка новых практик, модификация и вывод старых практик). Принцип -- это решение, унифицирующее выбор практики. Если принцип lean, то все практики выбираем из lean. Если принцип "проектное управление", то и практики оттуда. Но можно говорить и о практике lean, практике проектного управления -- практики часто называют по имени принципа, а выбор практики или их семейства это для организации самое что ни на есть "архитектурное решение". Так что не вижу противоречий.