Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

Заметки с SEMAT track на АПСПИ-2015: проблематизируем Essence

От русского отделения INCOSE было 8 докладов про разные приложения Essence, плюс были доклады от русского отделения SEMAT -- эдакий фестиваль. Вот пара моих заметок:

1. Практически все замечали, что с помощью Essence много быстрее учить студентов. Хорошая явно задаваемая онтология позволяет заменить "опыт" на быстро передаваемое знание. Почему? Мой ответ: основное знание кодируется в альфах. Оно:
-- компрессирует знание про рабочие продукты в 6-10 раз, задаёт уровень абстрации
-- позволяет обсудить как инженерные, так и менеджерские аспекты проекта. Системный инженер обсуждает содержание альфы, CTO обсуждает практики (дисциплины и технологии) работы с альфой, а операционный менеджер ресурсы и время работы с альфой.

2. Альфа четырёхмерна (оставим пока в сторону очевидные онтологические непонятки). Это позволяет легко понимать альфу в том числе как activity по изменению участвующих (отношение participation) в ней рабочих продуктов. Скажем, альфа Team -- это activity с командой (изменения, процессы, происходящие с командой во всё время её существования). В любой момент я могу говорить не про activity аспект (аспект изменений), а просто обозначать альфой участвующие предметы. Тем самым альфа это product-based способ описания, в котором изменяющиеся и имеющие разные состояния products (artifacts). Трекинг (как в issue tracking) идёт именно альф. Case management -- альф. Четырёхмерие тут даёт смотреть на альфу и как на (изменяющуюся) вещь, и как на сам процесс изменения (вещи).

3. Моя страшная гипотеза в том, что состояния альфы -- это тоже альфы (подальфы), равно как чекпойнты это тоже альфы (подальфы). То есть "иерархия трёх типов" это традиционный случай введения первоначально жёсткой по типам и числу уровней иерархии, а затем признания факта, что никаких особых там отдельных типов нет, а число уровней N. Это очень консистентно с тем, что происходит в проектном управлении: жизненный цикл бьют сначала на гейты, затем вводят контрольные точки посередь стадий, затем вводят контрольные точки по отдельным частностям -- и получают порядка 1000 контрольных точек (для выпуска Боинга) или 15000 контрольных точек (для проведения Олимпийских игр). Это по факту уже case management, issue tracking -- это не процессное, не проектное управление. И это же проясняет, почему в классической литературе по case management сами кейсы именуются по основной вещи, которая изменяется в ходе кейса (кандидаты, менеджеры), а иногда и мероприятия (интервью) -- http://ailev.livejournal.com/946134.html.

Такой онтологический взгляд даёт ответ на некоторые "трудные вопросы":
-- почему никакой особой стадийности/гейтовости не наблюдается в состоянии альф? Потому как можно очень по-разному нарезать входящие в activity объекты на темпоральные части (сами по себе activity).
-- почему отдельные чекпойнты так и хочется ставить в разные состояния разных альф? Потому как они сами подальфы (темпоральные части) этих подальф (состояний альф). И да, с чекпойнтами тоже идёт большая работа по изменению участвующих в чекпойнтах темпоральных частей.

4. Если мы принимаем этот продуктно-работный дуализм альф, то сразу понятно становится связь не только с case management/issue tracking, но и всем lean. Например, small batch size -- это про измельчение альф (набора участвующих в работах объектов), что эквивалентно измельчению связанных с этими объектами работ. И этот же дуализм и четырёхмерие объясняет все трудности объяснения альф, case, issue -- это очень хитрые объекты из чуждой пока обыденному восприятию 4D экстенсиональной онтологии. В таком подходе сам проект -- это case/issue/topalpha, а семь альф -- это его "канонические подальфы", то есть иерархия не со срезанной верхушкой. Более того, в этом случае понятно, как включать проект в проект/кейс/issue более высокого уровня. Там можно придумать какой-нибудь вариант IEC 81346, позволяющий именовать структуру не только статичной целевой системы, но и связанных с ней работ (то есть включать именование и обеспечивающей системы тоже, а также задумываться о включении в рассмотрение используемой системы).

5. Вообще, отсутствие в явном рассмотрении в Essence используемой системы меня напрягает сильно. Ибо пока там в виде подальфы возможностей есть только Needs. Обеспечивающая система рассматривается наряду с целевой системой, и даже более детально (аж три альфы endeavour).

5. Похоже, что текущий вариант показа проектов технологического развития -- это не столько удвоение ядра (две диаграммы Essence для целевой системы и обеспечивающей системы соответственно), сколько порождение новых area of concerns в рамках того же ядра. То есть Team общая для команды развития и команды проекта, а они сами подальфы Team, хотя и разведённые в разные area of concern (а не две топовые альфы).

6. Все эти соображения пока крайне мутны, но все мои мысли больше и больше ведут к желанию сделать Essence 2. Но не в варианте именно как Essence 2, а в варианте ArchiEssence -- case management/issue tracking ready, с диаграммами как в ArchiMate и простыми карточками как в Essence.

Конечно, я помню и про SysMoLan, но там размышления у меня больше про другие аспекты (мультимоделирование, теоркатегорный формализм и т.д. -- меньше управления жизненным циклом, больше собственно системной инженерии).
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 13 comments