November 2nd, 2009

2021 год

Вокруг 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.
2021 год

Три артефакта координации работ менеджеров и инженеров


(это слайд из http://www.slideshare.net/ailev/ss-2290189).

Для того, чтобы в крупных проектах избежать основных ошибок координации работ между менеджерами и инженерами требуется минимально три артефакта:
-- модель жизненного цикла
-- требования
-- "оценочное дело"

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

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

Для того, чтобы понимать, какие именно это стадии жизненного цикла, и какие требуются содержательные артефакты (состояние системы на конец стадии -- проект, или прототип, или готовая система), а также для фиксации самого факта наличия пересмотра выделения ресурсов между этими стадиями необходимо иметь описание (лучше -- компьютерную модель) жизненного цикла. Требование иметь это описание есть в ISO 15288, а в руководствах к нему (ISO TR 24748-1 и ISO TR 19760) рассказывается о том, что между стадиями происходит пересмотр выделения ресурсов, т.е. происходит принятие решения о том,
-- выделить ли ресурсы для перехода к следующей стадии,
-- продолжить ли выполнение текущей стадии в счет уже выделенных ресурсов, или небольшой добавки ресурсов, достаточной для получения результатов, позволяющих принять решение о выделении ресурсов для перехода на следующую стадию
-- закрыть проект (признать, что дальнейшее выделение ресурсов нецелесообразно0

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

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

Когда говорится о "требованиях", то имеется ввиду:
-- разные виды требований (прежде всего -- заинтересованных лиц, к числу которых прежде всего относим менеджеров; требования к системе, определяющие границы системы)
-- текущее понимание требований: переговоры между менеджерами и инженерами идут в течение всего хода проекта, а не только в самом начале проекта. Поэтому требования фиксируются на предыдущем пересмотре выделения ресурсов (базис, baseline), чтобы команда инженеров могла спокойно работать всю стадию N до текущего пересмотра ресурсов. В то же время, всю эту стадию N требования пересматриваются, и к пересмотру готовится новый набор требований -- который будет зафиксирован на новую стадию N+1. Ибо менеджерам выделять деньги на продолжение реализации устаревших требований "по состоянию на конец стадии N-1" было бы неправильно: в ходе выполнения стадии N были получены новые знания, и требования просто обязаны быть откорректированы. Инженеры и менеджеры должны поэтому договориться о пределах этой корректировки, и как эта корректировка может повлиять на бюджет, сроки и риски проекта в целом.

ISO 15288 не рассказывает об этой работе с требованиями, он просто фиксирует необходимость наличия разных видов требований, а также необходимость трассировки этих требований к разным заинтересованным сторонам -- и постулирует непротиворечивость требований к системе (что означает, что заинтересованные стороны должны по этим требованиям договориться). Работа по непрерывному изменению всех видов требований в ходе всего жизненного цикла и недопустимость замораживания начальных требований оговаривается практически всеми методами управления жизненным циклом. Метод постадийного выделения ресурсов (ICM) конкретизирует, что
-- должна проводиться процедура фиксации требований на каждую следующую стадию N+1, но фиксируемый вариант должен уточняться в ходе всей предыдущей стадии N
-- возможность выполнения требований в ходе проекта должна доказываться инженерами менеджменту в моменты пересмотра выделения ресурсов.

Особое внимание нужно обратить тут на то, что требуется не столько доказательство того, что инженеры выполнили требование этапа (выдали "на гора" какие-то артефакты, представляющие систему в состоянии на текущей стадии ЖЦ -- дали эскизный проект, или предъявили полностью соответствующие давно оговоренным спецификациям детали будущей конструкции), сколько требуется доказательство того, что весь проект будет успешным в момент его окончания.

Это замечание очень похоже на разницу оценка успеха проекта "традиционным" управлением проектами (анализ освоенных объемов), а оценки "по Голдратту" -- оценки того, когда проект будет выполнен. Менеджеров интересует не успех предыдущей стадии, а успех будущей стадии (помним: в этот момент происходит выделение ресурсов на будущую стадию N+1. Ресурсы на предыдущую стадию были выделены при предыдущем пересмотре выделения ресурсов после стадии N-1 и перед стадией N. Поэтому интересуют риски продолжения проекта, а не то, насколько справились инженеры с выполнением задач предыдущей стадии -- менеджеров интересует оценка будущего, а не оценка прошлого).

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

Слово "доказательство" (а не сверка, проверка и т.д.) тут не случайно: в какой-то момент в методе ICM пришлось менять термин на "доказательство", ибо все другие термины позволяли инженерам просто предъявлять результат работы ничего не понимающим в содержании менеджерам, и тем самым их ошибки становились очевидными только на самых поздних стадиях проекта, когда исправлять их было уже поздно. ICM прямо говорит, что должна быть продемонстрирована очевидность (evidence) приемлемости рисков продолжения проекта.

В ходе осознания проблемы коммуникации между менеджерами и инженерами было предложено и опробовано множество (порядка десятка) разных методов такого "доказательства приемлемости рисков", но выжил только один: работа в ходе всего проекта с особым артефактом "оценочное дело" (assurance case). Этот способ получил свою фиксацию в особом стандарте системной инженерии ISO 15026. Оценочное дело (термин выбран по аналогии с "судебным делом") доказывает, что требования будут выполнены:
-- для каждой декларации соответствия требованиям (т.е. необходимо поддерживать соответствие "оценочного дела" артефакту "требования") формулируется
-- набор промежуточных аргументов в поддержку этих деклараций.
-- Для каждого аргумента в оценочное дело "подшиваются" материалы, показывающие неголословность этих аргументов (результаты испытаний, акты экспертных заключений, расчеты и т.д.).

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

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

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

Склейка "в малом" и "в большом". Новые материалы на vpri.org

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

  • How do you find the Sine function, if you don't know its name?, Ted Kaehler
  • Chains of meaning in the STEPS system, Ian Piumarta
  • An Assembler for AVM2 using S-Expression, Takashi Yamamiya
  • High-level Expressions in Language L, Hesam Samimi
  • Research Summary: A Programming Methodology and A Reliability Mechanism, Hesam Samimi
  • COLA Kernel Abstraction, Ian Piumarta
  • A Lazy List Implementation in Squeak, Takashi Yamamiya
  • Register Allocation via Puzzle Solving via Planning, Hesam Samimi
  • RCCola: Remote Controlled Cola, Takashi Yamamiya
  • Recognizing the CAICO, A Collection of Almost-Identical Complex Objects, Ted Kaehler
  • BabySteps: An approach to bootstrap an interactive system on COLA, Yoshiki Ohshima
  • Quantum Object Dynamics, Ian Piumarta

  • А вот SOA -- это программирование-в-большом. Я не очень понимаю, кто сейчас лидер в этой области: "как мало нужно сказать, чтобы описать другие автономные программы, и как мало нужно сказать, чтобы эти другие программы поняли, как им слипнуться для общей цели". Пока присматриваюсь к моделям-в-большом от группы AtlanMod (http://www.emn.fr/z-info/atlanmod/index.php/New_Results) и практическим разработкам типа Dassault Systemes V6, я писал об этом неделю назад -- http://ailev.livejournal.com/748188.html.

    Я вот думаю сейчас, что эти такие разные большие-малые программирования-моделирования (с размытой между ними всеми границей) очень похожи на проектирование и конструирование в нынешних инженерных проектах. Когда-то "просто инженер" сейчас -- либо инженер-конструктор (с ЕСКД, прошитой в голову), либо инженер-проектировщик (с прошитой в его голове СПДС). Эта разница отражалась и софтом, и ВУЗами, и повадками.

    Но онтологические САПР позволяют сегодня преодолеть разницу между конструированием и проектированием (например, в CATIA начиная с V5 проектирование и конструирование ведутся в одном окошке, между этими режимами работы по факту нет переключения). Я думаю, что language workbenches становятся такими же мостиками между двумя (а то и всеми четырьмя, если учесть моделирование) уже успевшими разойтись и теперь настоятельно нуждающимися в склейке программистскими-модельерскими "в малом" и "в большом" мирами.

    И тут нужно вспомнить, что одна из идей всех этих COLA и STEPS из vpri.org -- создание компактной и удобной системы для многоязыкового мультипарадигмального программирования. Что это, если не language workbench?! Но аборигены vpri.org не пользуются терминологией от Martin Fowler, они и сами с усами.