Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

Вокруг SPEM

Method engineering развивается и предлагает самые разные софтопроцессные (читай -- жизненноцикловые) метамодели: SPEM, OPF, OOSPICE, SMSDM. Фишкой тут является соединение жизненноцикловых менеджерски-ориентированных "макропроцессов" и используемых в конкретные моменты работы инженерно-ориентированных "микропроцессов" (подробнее -- http://www.icsp-conferences.org/icsp2009/PDF/B4/Zhu_ICSP2009.pdf, в том числе описание трудностей такого синтеза в рамках формализма SPEM. Впрочем, эти трудности мне вчера долго рассказывал vvagr, безо всякого знакомства с этой презентацией).

По факту среди методных инженеров (о, великий русский языка!) победил SPEM: и сама метамодель оказалась удачна, и выбор метамодели определяется наличием свободного мощного инструментария (EPF Composer). Современные лекции по методологической инженерии читаются в конечном итоге на примере SPEM (очень хорошее введение в проблематику -- http://www.uio.no/studier/emner/matnat/ifi/INF5120/v09/undervisningsmateriale/F07-020309-Method-Engineering-be.pdf, хотя эту ссылку я уже давал, но с удовольствием повторю).



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

Каждый метод включает в себя приемы (technique, специфические описания, поддерживающие метод) и процесс (последовательность шагов, ведующая к результату). Приемы отвечают на вопросы кто, что, как, зачем и т.д., а процесс отвечает на один вопрос: когда.

Понятно, что все эти понятия нужно пересмотреть, ибо в том же SPEM, выделяют method content (те самые "приемы"), process и practice -- причем practice "ортогональна" и приемам, и процессам, и представляет собой описание каких-то аспектов, общих для многих приемов и процессов. Это все удивительно, но когда я слышу "аспект", я просто понимаю, что речь идет не об изложении какой-то последовательности, а о "плетении" (weaving) -- так что практики я считаю теми же приемами, только не поддающимися "процессному" выстраиванию в явную последовательность, а подразумевающими аспект-ориентированное "вплетение".

Впрочем, все эти "процессы" более пригодны именно для машинного исполнения, или должны пониматься как очень крупная нарезка. Люди все приемы выполняют в режиме "плетения", а не строго следуют "процессу" на нижнем уровне.

В системной инженерии SPEM использовался как-то для моделирования и последующей адаптации EIA-632: невнятный текст, сводящийся к пересказу введения в SPEM со словами "системная инженерия" http://www.lattis.univ-toulouse.fr/uploaded/files/publications/conferences/EXPPAND08_V01b.pdf и hмного более подробный http://tel.archives-ouvertes.fr/docs/00/34/60/37/ANNEX/soutenance_en.pdf (впрочем, эти ссылки я уже давал где-то полгода назад). В этих работах показывается традиционная архитектура "метода создания метода":
-- берем крупнонарезанные практики и жизненный цикл "из Стандарта системной инженерии". Это отраслевой уровень.
-- уточняем мелконарезанными практиками и стандартами выполнения отдельных работ (инженерии требований, управления информацией и т.д. -- отвечаем на вопрос "как именно", по какой методологии это все делаем). Это уровень выбранных предприятием методов работы.
-- уточняем, какой конкретный инструментарий, жизненный цикл и связанные с ним особенности будут использоваться в ходе конкретного проекта (экземпляра ЖЦ) по работе с конкретной системой, учитывающие уже все технологические особенности и риски именно этого проекта.

Для стандарта системной инженерии EIA-632 (140 страниц текста) получилось 69 пакетов методов, 79 диаграмм, 1534 элемента, 1502 связи. Моделировали прямо в UML стереотипами SPEM.

Для того, чтобы лучше понять достоинства и недостатки SPEM, нужно ознакомиться с критикой этой метамодели и конкурирующими проектами. Наиболее активны тут австралийские вариации на тему улучшения SPEM в рамках исследований по situational method engineering:

Bhuvan Unhelkar, 2009: http://www-staff.it.uts.edu.au/~brian/Module2_6perpage.pdf (учебный курс Module-2)
Brian Henderson-Sellers, 2006: http://emmsad06.idi.ntnu.no/EMMSAD06_p6-henderson.pdf
Brian Henderson-Sellers, 2005: http://www.pa.icar.cnr.it/cossentino/al3tf3/docs/hs.ppt (FAME Project)
Cesar Gonsalez-Perez, Brian Henderson-Sellers, Tom McBride, 2004: http://www.verdewek.com/work/Download/Seminars/COTAR-May04-IntroSMSDM.ppt

Это все из проекта по стандартизации процесса построения агентской архитектуры FIPA. Похоже, что именно этот подход (а не SPEM) лег в основу ISO 24774, и тем самым ISO 15504 и ISO 15288. Но софтовых инструментов пока не найдено.

Эти работы продолжаются. Например, в 2009г. вышла статья "A method to build information systems engineering process metamodels", где приводится ряд мета-моделей процессов (activity-, product-, decision-, context-, strategy-oriented) и описываются проблемы их синтеза. Вот еще презентация -- http://www.icsp-conferences.org/icsp2009/PDF/B4/Zhu_ICSP2009.pdf

Тем временем, в агентской архитектуре таки победил SPEM -- в том числе он был оттестирован австрало-итальянской командой на возможность описания не только ОО-процессов, но и процессов самоорганизации в агентских системах -- моделирование пяти разных методов в SPEM http://www.dcs.bbk.ac.uk/research/techreps/2009/bbkcs-09-05.pdf, и чуть менее доступная работа http://portal.acm.org/citation.cfm?doid=1363686.1363853.
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 3 comments