OMG Essence — различия между версиями

(Новая страница: «Стандарт OMG Essence - Kernel and Language for Software Engineering Methods. В стандарте можно выделить две части: *'''я…»)
 
(Карточки)
Строка 51: Строка 51:
 
== Карточки ==
 
== Карточки ==
  
Стандарт вводит кроме графического и текстового языков для описания практик ещё и представление на карточках - когда для каждого состояния альфы делается отдельная карточка с представлением чеклиста (англоязычные карточки, готовые к распечатке, можно взять тут: http://www.ivarjacobson.com/uploadedFiles/Content/Landing_Pages/SEMAT%20SW%20Eng%20Kernel%20Cards%20A8.pdf), а потом для каждой альфы выкладывается ряд этих карточек с группировкой состояний по разным принципам:
+
Стандарт вводит кроме графического и текстового языков для описания практик ещё и представление на карточках - когда для каждого состояния альфы делается отдельная карточка с представлением чеклиста.
 +
см. [http://www.ivarjacobson.com/uploadedFiles/Content/Landing_Pages/SEMAT%20SW%20Eng%20Kernel%20Cards%20A8.pdf Англоязычные карточки, готовые к распечатке].
 +
а потом для каждой альфы выкладывается ряд этих карточек с группировкой состояний по разным принципам:
 +
*уже достигнутые, в работе, ещё не достигнутые (оценка состояния дел в проекте). Попробуйте оценить состояние проекта в онлайн-инструменте SEMAT Accelerator -- http://sematacc.meteor.com/ (требует бесплатной регистрации).
 +
*те, которые будем достигать мы, и которые были достигнуты или будут достигнуты другими (жизненный цикл нашего проекта в общем жизненном цикле)
 +
*те, которые будут достигнуты на каждой стадии жизненного цикла (так определяется вид жизненного цикла -- см. также рис.160 в тексте самого стандарта)
 +
*те, которые будут достигнуты на текущем шаге/итерации/спринте (планирование шага работы).
  
уже достигнутые, в работе, ещё не достигнутые (оценка состояния дел в проекте). Попробуйте оценить состояние проекта в онлайн-инструменте SEMAT Accelerator -- http://sematacc.meteor.com/ (требует бесплатной регистрации).
 
те, которые будем достигать мы, и которые были достигнуты или будут достигнуты другими (жизненный цикл нашего проекта в общем жизненном цикле)
 
те, которые будут достигнуты на каждой стадии жизненного цикла (так определяется вид жизненного цикла -- см. также рис.160 в тексте самого стандарта)
 
те, которые будут достигнуты на текущем шаге/итерации/спринте (планирование шага работы).
 
 
 
== Практики и методы ==
 
== Практики и методы ==
  

Версия 16:48, 12 ноября 2015

Стандарт OMG Essence - Kernel and Language for Software Engineering Methods.

В стандарте можно выделить две части:

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

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

Увы, эта "простота" временами чрезмерна. Так, вместо того, чтобы сказать "онтология" или хотя бы "мета-модель", говорится о common ground.

Язык

Язык (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)
    • Альфы: работа, команда, способ работы.
    • Деятельности: приготовиться к выполнению работы, координировать дела, поддерживать команду, отслеживать прогресс, остановить работу.
    • Компетенции: лидерство, менеджмент.

Для каждого типа альф вводятся её состояния, а для состояний приводится [Практика контрольных вопросов|чеклист].

Конечно, понятие Alpha (Abstract-Level Progress Health Attribute) является ключевым для стандарта, оно определяется как существенный (essential) элемент софтверноинженерного проекта, за которым нужно следить при оценке его продвижения (progress) и "здоровья".

Карточки

Стандарт вводит кроме графического и текстового языков для описания практик ещё и представление на карточках - когда для каждого состояния альфы делается отдельная карточка с представлением чеклиста. см. Англоязычные карточки, готовые к распечатке. а потом для каждой альфы выкладывается ряд этих карточек с группировкой состояний по разным принципам:

  • уже достигнутые, в работе, ещё не достигнутые (оценка состояния дел в проекте). Попробуйте оценить состояние проекта в онлайн-инструменте SEMAT Accelerator -- http://sematacc.meteor.com/ (требует бесплатной регистрации).
  • те, которые будем достигать мы, и которые были достигнуты или будут достигнуты другими (жизненный цикл нашего проекта в общем жизненном цикле)
  • те, которые будут достигнуты на каждой стадии жизненного цикла (так определяется вид жизненного цикла -- см. также рис.160 в тексте самого стандарта)
  • те, которые будут достигнуты на текущем шаге/итерации/спринте (планирование шага работы).

Практики и методы

Работы (works) ведутся в соответствии с Практиками, которые добавляют к абстрактным сущностям более конкретные:

рабочие продукты (work products), состояние которых позволяет судить об абстрактных состояниях альф. Сами рабочие продукты имеют не состояния, но уровни детальности. дела (activity), которые выполняются в деятельностях, изменяют рабочие продукты в части поднятия их уровня детальности, и тем самым продвигают состояние альф. Дела делаются по порядку (между делами есть связь "следует за" -- то есть это такой способ описания процессов).

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

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

Локализация

Переводом на русский язык стандарта в целом занимается сейчас abayda. В России создается Русское отделение SEMAT.