Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

Основа -- сущности и язык для методов программной инженерии (OMG Essence)

Стандарт OMG Essence -- Kernel and Language for Software Engineering Methods (Основа -- сущности и язык для методов программной инженерии) получил 73% голосов на заседании OMG 12 ноября 2012 (эта версия тут: http://semat.org/wp-content/uploads/2012/02/2012-11-01.pdf), ему не хватило всего 2% для его немедленного утверждения. Следующая попытка -- в феврале 2013года. Это разработка главным образом SEMAT (http://semat.org/), хотя там уже есть поддержка и множества других организаций. Я отслеживаю эту инициативу с 2010г. (http://blogs.yandex.ru/search.xml?text=semat+%3C%3C+author%3D%22ailev%22), а теперь пришла пора рассказать о ней подробнее -- но не слишком подробно, ибо только в тексте стандарта 283 страницы по состоянию на 12 ноября 2012.

Книжка по применениям стандарта выйдет 28 января 2013, предзаказы уже принимаются: http://www.amazon.com/The-Essence-Software-Engineering-Applying/dp/0321885953/

Основная маркетинговая презентация -- http://semat.org/wp-content/uploads/2012/12/SEMAT-Introduction.pdf Я не рекомендую туда смотреть, просто знайте, что именно эта презентация сейчас выдаётся за суть происходящего. Нет, происходящее в разы интересней этой презентации. Увы, в этих слайдах ничего существенного, сплошной невнятный разговор про "великое начало великого дела", уймы подписантов и прочих сторонников, но ничего по сути дела SEMAT. Эта суть дела доступна в других местах, прежде всего в самом тексте стандарта, а также в многочисленных других презентациях, ссылки на которые я дам ниже.

Уже сейчас доступен моделер для разработки и расширения сущностей и основанных на них практик -- http://www.ivarjacobson.com/Practice_Workbench_Download/ (и там нужно следовать по пути SEMAT USERS). Качайте, устанавливайте, дерзайте описать что-то своё.

Есть уже много адептов -- вот, например, попытка сделать общий метод на основе Essence, VDML, CMMNб SoaML и ряда других стандартов: http://neffics.eu/ (увы, там отнюдь не все deliverables доступны. Ну, и уровень интеграции этих стандартов и инструментов пока оставляет желать. Но сам заход любопытен). Уже на основе Essence ведутся курсы по software engineering (не путаем с computer science!) в ряде ведущих университетов -- от Китая до Норвегии.

Можете записывать и меня в адепты, хотя и с некоторыми оговорками (всё-таки я специализируюсь на немного других инженериях -- системная и организационная инженерии не укладываются тут в программную инженерию, чтобы иметь возможность использовать Основы непосредственно).

Критика у Основ тоже есть, и моя, и чужая, но ней позже.

Сразу оговорюсь, что предложения по русскоязычному переводу в этом посте самые начальные, и я буду время от времени возвращаться, и править тут "по живому". Переводом на русский язык стандарта в целом занимается сейчас abayda, его имя также дважды попало в стандарт (он член подгруппы по разработке cущностей/kernel). Вообще, в России потихоньку создается Русское отделение SEMAT (http://metacode-ru.livejournal.com/6830.html), так что перспективы стандарта на применение в русскоговорящих странах вполне есть.

В стандарте можно выделить две части:
-- язык (language) для описания методов программной инженерии
-- сущности (kernel, в словаре есть и значение "сущность") для методов такой предметной области (domain), как программная инженерия.

В части языка Основы представляют собой следующее поколение стандартов ситуационной инженерии методов (предыдущее поколение -- SPEM 2.0 и ISO 24744, отличия из которых прямо прописаны в Основах). От предыдущих стандартов главное отличие -- это отказ от сложности и нацеленности на нужды модельеров методов. Упрощено было всё: и язык (в духе отказа от "занаученных" терминов), и нотация, и способ употребления (простейший из них теперь -- раскладывание карточек на столе). А вместо радости для модельеров методов стандарт представляет теперь радость для применяющих методы команд.

Увы, эта "простота" временами чрезмерна. Так, вместо того, чтобы сказать "онтология" или хотя бы "мета-модель", говорится о common ground. В плане понятности этот хрен редьки не слаще: даже если сопровождать это слайдом, где все программные инженеры стоят на одной кочке в болоте вместо того, чтобы стоять на разных кочках, понимания это не добавляет. Мне лично очень трудно продираться сквозь любымые Ivar Jacobson (предводитель команды разработчиков) маркетинговые blah-blah-blah про "поиск оснований", "универсальность", "важность того, что это будут использовать много разных людей" и т.д.. Ибо если вместо слова "онтология" приводить красочные метафорические описания, становится не столько понятней (ибо нет непонятных слов, ура!), сколько туманней (ибо вообще не остаётся никаких слов, за которыми стоят хоть сколько-нибудь устойчивые значения, которые можно подсмотреть в словаре).

Язык (language) Основ -- это минимальный набор понятий, в терминах которых описываются методы программной инженерии. Особое внимание тут уделялось минимальности языка. Конечно, язык не ограничен именно программной инженерией, но особо оговорено, что никаких пока приложений к другим областям (domains -- системной инженерии, адаптивному управлению кейсами и т.д.) не было.

"Описывать в терминах" -- это означает использовать мета-язык. Основы вводят четыре уровня этих "мета" (традиционных для MDA, но и очень похожих на уровни ISO 15926) для описания
3 -- meta-language: MOF (мета-класс, отношение и т.д.)
2 -- мета-модель/язык: Construct (понятия языка Основ -- alpha/альфа, activity/дело)
1 -- ситуационный метод/сущности: Types (конкретные ядра и практики -- "требования", "прописать сценарии использования").
0 -- жизнь: Occurence (экземпляры времени выполнения, объекты в реальной жизни)

Язык Основ предписывает использовать следующие основные термины-конструкты (их, конечно, больше -- но эти главные):
-- альфа (alpha -- то, что требует отслеживания для успеха разработки, что будет продвигаться работами по последовательности состояний)
-- состояние альфы в ходе разработки (alpha state)
-- деятельность (activity space, "пространство дел", т.е. деятельность -- она меняет состояния)
-- компетенции, требуемые для деятельностей -- с набором уровней для каждой компетенции.

В этих терминах-конструктах описываются абстрактные сущности (kernel) для программной инженерии, имеющие определяемые Языком типы. Эти сущности разбиты на три области интересов (area of concern):
-- клиент (Customer. Альфы: возможности и заинтересованные стороны. Деятельности: исследовать возможности, понять нужды заинтересованных сторон, обеспечить удовлетворение заинтересованных сторон, использовать систему. Компетенции: представление заинтересованной стороны).
-- решение (Solution. Альфы: требования и программная система. Деятельности: понять требования, смоделировать/shape систему, изготовить систему, тестировать систему, развернуть/deploy систему, управлять/operate системой. Компетенции: анализ, разработка, тестирование).
-- предпринятие (Endeavor. Альфы: работа, команда, способ работы. Деятельности: приготовиться к выполнению работы, координировать дела, поддерживать команду, отслеживать прогресс, остановить работу. Компетенции: лидерство, менеджмент).

Для каждого типа альф вводятся её состояния (для "требований": 1. замыслены/concieved, 2. ограничены/bounded, 3. .... 6. Удовлетворены/fulfilled), а для состояний приводится чеклист (для "требования -- замыслены": начальный состав заинтересованных сторон согласился, что систему нужно создавать; заинтересованные стороны, которые будут использовать систему, выявлены; заинтересованные стороны, которые будут финансировать начальную работу над новой системой, выявлены; есть ясно понимаемая возможность, которую адресует новая система). Да, это те самые чеклисты, которые я недавно так хвалил в http://ailev.livejournal.com/1029295.html -- и одно только это залог успешности стандарта.

Конечно, понятие Alpha (Abstract-Level Progress Health Attribute) является ключевым для стандарта, оно определяется как существенный (essential) элемент софтверноинженерного проекта, за которым нужно следить при оценке его продвижения (progress) и "здоровья". Как я понимаю, авторы стандарта хотели, чтобы это слово было необычным -- поэтому я бы его в переводе не трогал. Моя гипотеза -- это ведь case из adaptive case management (поглядите пример из http://ailev.livejournal.com/946134.html, разве приведённые там кейсы не соответствуют альфам из Основ?).

Очень поучительно поглядеть историю появления этих сущностей в том виде, в котором они присутствуют в стандарте: http://semat.org/wp-content/uploads/2012/12/Universals_Track_Intro_Stockholm.pdf (там сущности называются ещё не kernel, а universals).

Эти сущности уже позволяют делать ого-го сколько, даже без их конкретизации в конкретные практики и уточнения до метода. Дело в том, что стандарт вводит кроме графического и текстового языков для описания практик ещё и представление на карточках -- когда для каждого состояния альфы делается отдельная карточка с представлением чеклиста (англоязычные карточки, готовые к распечатке, можно взять тут: http://www.ivarjacobson.com/uploadedFiles/Content/Landing_Pages/SEMAT%20SW%20Eng%20Kernel%20Cards%20A8.pdf), а потом для каждой альфы выкладывается ряд этих карточек с группировкой состояний по разным принципам (см. картинки, как это делается в конце презентации по истории появления сущностей, ссылка в предыдущем абзаце):
-- уже достигнутые, в работе, ещё не достигнутые (оценка состояния дел в проекте). Попробуйте оценить состояние проекта в онлайн-инструменте SEMAT Accelerator -- http://sematacc.meteor.com/ (требует бесплатной регистрации).
-- те, которые будем достигать мы, и которые были достигнуты или будут достигнуты другими (жизненный цикл нашего проекта в общем жизненном цикле)
-- те, которые будут достигнуты на каждой стадии жизненного цикла (так определяется вид жизненного цикла -- см. также рис.160 в тексте самого стандарта)
-- те, которые будут достигнуты на текущем шаге/итерации/спринте (планирование шага работы).

Вот картинка для соблазнения таки пройти по ссылкам:

Конечно, можно создавать свои сущности (kernels) для разных предметных областей (например, для "программной инженерии встроенных систем", как более специализированных вариантов), а также расширения сущностей (kernel extensions) для целей более подробных и точных описаний. Стандарт предлагает некоторые такие расширения сущностей для программной инженерии (например, для альфа "программной системы" будут ещё субальфы "компонента" и "баг", для "работы" будет субальфа "задача" -- и для каждой из этих субальф будет свой набор состояний, чтобы можно было запланировать дела по продвижению этих субальф в ходе проекта. Прогресс этих подальф двигает (drives) каждый свою альфу, а прогресс всех альф двигает общий успех проекта. Конечно, можно добавлять и другие сущности: компетенции с их уровнями, например).

Для увеличения выразительности Языка добавлены:
-- ресурсы (то, что будет потом использоваться без изменений при переносе из метода в жизнь: шаблоны, примеры, руководства, курсы для получения компетенций и т.д.)
-- паттерны (связки сущностей и их отношений -- стадии жизненного цикла и даже роли вводятся паттернами).

Работы (works) ведутся в соответствии с Практиками (архитектурное проектирование, моделирование, использование процессного подхода, непрерывная интеграция, использование use cases, user stories, и т.д. -- вот тут есть примеры, которые не совсем compliant стандарту, тем не менее позволяют судить о чём идёт речь: http://www.ivarjacobson.com/Practices/) которые добавляют к абстрактным сущностям более конкретные:
-- рабочие продукты (work products), состояние которых позволяет судить об абстрактных состояниях альф. Сами рабочие продукты имеют не состояния, но уровни детальности.
-- дел (activity), которые выполняются в деятельностях, изменяют рабочие продукты в части поднятия их уровня детальности, и тем самым продвигают состояние альф. Дела делаются по порядку (между делами есть связь "следует за" -- то есть это такой способ описания процессов).

Пример построения практики Scrum -- http://task3.cc/wp-content/uploads/2012/11/Essence_Kernel_and_Scrum-from-ICSE_Semat_Presentation.pdf

Дальше всё так же, как в любом другом изводе ситуационной инженерии методов. Разных практик много (в SEMAT идентифицировали примерно 250 для программной инженерии), из них составляются библиотеки (library). Впрочем, библиотеки составляются для коллекции чего угодно в той или иной дисциплине или области знаний -- сущностей (kernel), практик. Как всегда, есть общий огромный мешок самых разных компонент методов и связок из этих компонент -- практик. В 2006 году я примерно про то же самое писал для ОпенМеты в терминах репозитория и дистрибутива: http://openmeta.livejournal.com/191373.html -- можно возвращаться к вопросу, и разрабатывать ядро и практики ОпенМеты, используя Язык Основ).

Метод -- это тот небольшой набор практик из библиотеки, которым в жизни будет пользоваться команда разработчиков. Из 250 практик составляются (composed) тысячи и тысячи методов, в зависимости от ситуации. Ситуационная инженерия методов -- это как раз про это. Важно, что метод не становится организационной догмой после извлечения ситуационной связки практик из огромного мешка наличных двухсот пятидесяти. Нет, практики в методе меняются по ходу дела, метод эволюционирует в ходе разработки.

Далее для методов определены способы их задействования (enactment), вплоть до того, что стандарт позволяет формально подсказывать, что когда можно делать (для этого может быть использован традиционный для OMG язык ограничений -- OCL).

Критики для всего этого хватает. Вот, например, свеженький пример: http://www.slideshare.net/dJdU/in-search-of-the-higgs-or-whats-wrong-with-semat (это Rich Hillard хочет сделать concerns, как первоклассные понятия в SEMAT -- желающих расширить Язык и Сущности ведь хоть отбавляй), а вот предложение сурово пересмотреть в сторону добавки domain engineering как одной из главных частей программной инженерии -- http://www2.imm.dtu.dk/~dibj/semat-s.pdf. Продолжаются и работы по попыткам подвести хоть какую-то теоретическую базу: найти тот малый набор объектов, который позволит строить теории (типа "физического тела", "математической точки", "химической связи" -- то, из чего потом можно вытащить целую связку теорий для построения большой дисциплины. Ведь нет собственных "идеальных объектов" -- нет и собственной дисциплины) -- вот, например, Proceedings of The Semat Workshop on a General Theory of Software Engineering: http://semat.org/wp-content/uploads/2012/10/GTSE_2012_Proceedings.pdf

Вот моя начальная критика:
-- если соотносить стандарт с поколениями проектного управления, то это второе поколение, соответствующее PMBoK и PRINCE2 -- упор на отдельные проекты. Третье поколение (P2M, TOC) объявило, что не бывает управления проектами в отрыве от управления программами (TOC говорит более жёстко: управлять проектами можно только в том смысле, что перебрасывать ресурсы с одних проектов на другие в рамках программы). Обсуждаемые Основы, конечно, делают упор на один проект. Команда собралась, сделала систему, проэксплуатировала её, распалась. Не так явно, как я тут об этом пишу, но никаких акцентов на предпринятие, делающее разные системы для разных заинтересованных сторон, нет.
-- опущены инструменты, разве что методы работы предусматривают какие-то tools giude. Я бы их ожидал как специализации Команды (то бишь Person и Tool специализации Actor), это радикальное решение, но стандарт вообще избегает на эту тему каких-то предложений. Но, может, это "ресурсы"? Ибо ресурсы вполне соответствуют и инструментам тоже, они используются "непосредственно из уровня описания практик на уровне жизни". Видно, что тут пока "не договорились". В любом случае, без инструментов практики -- это не практики.
-- плотная привязка к MOF (хоть от UML удалось убежать, о чём было прямо заявлено, но MOF -- это текущее требование OMG). Это сразу даёт кривизну в определении мета-уровней и классификаций. Ибо MOF -- это объект-атрибутный язык, а не факт-ориентированный. И это не онтологический язык, а язык MDA-моделирования, со всеми вытекающими.

Ладно, хватит на первый раз...
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 3 comments