December 2nd, 2009

2021 год

Мясо из выращиваемой ткани

В Нидерландах вырастили свиную мышечную ткань -- но есть ее еще нельзя (http://www.telegraph.co.uk/foodanddrink/6684854/Scientists-grow-meat-in-laboratory.html). Есть надежда, что эту ткань удастся как-то "упражнять", чтобы довести ее до съедобных кондиций. Исследования по тому, как вырастить бифштекс из животных клеток, а не из животных в клетке могут занять пять лет.

Проект представляет собой "частно-государственное партнерство" нидерландского правительства и производителя колбасы.

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

А если дать им еще пяток лет, то на деревьях будут расти не булки, а бифштексы -- и никаких заводов не нужно будет, никакого металла и пластика.
2021 год

Eclipse Process Framework Composer (EPF Composer) и SPEM 2.0 по-русски

Eclipse Process Framework Composer -- это использующее метамодель SPEM 2.0 программное средство для поддержки ситуационной инженерии методов (http://ailev.livejournal.com/750878.html).

Взять EPF Composer можно вот тут: http://www.eclipse.org/epf/

Пакет русификации EPF Composer вот тут: http://www.eclipse.org/downloads/download.php?file=/technology/epf/composer/release/NLPack-epf-composer-1.5.0.zip (если сразу не русские меню не получились, то дополнительно вставляем две строчки
-nl
ru
в самом начале файла epf.ini).

Перевод текста Хомера Питера о том, зачем нужен EPF Composer, и как его использовать: http://narod.ru/disk/15588425000/EPFC_Overview_nov09.doc.html

Сокращенный перевод SPEM 2.0 (билингвальный текст, только для того, чтобы ввести русскоязычную терминологию, хоть как-то совмещенную с русскоязычной терминологией, введенной в ходе перевода стандартов системной инженерии): http://www.techinvestlab.ru/586621

Обращаем особое внимание, что предлагаемая нами в переводах терминология не соответствует текущему пакету русификации программы. Устранение этих расхождений у нас в планах.
2021 год

Четыре группы описаний жизненного цикла в PraxOS

Для того, чтобы описывать жизненный цикл, PraxOS требует как минимум четырех групп описаний, адресующих интересы различных сторон:

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

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

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

4. Организационная (соглашений, полномочий и обязанностей) -- договорные (включая неформальные) трансакции акторов с цепочками поручений и контролем исполнения. Метамодель DEMO, LastPlanner.

Подробнее про важность первых трех групп описаний см. презентации http://www.slideshare.net/ailev/ss-presentation-615257 (двухлетней давности) и http://www.slideshare.net/ailev/ss-2290189 (месячной давности), плюс свежайший обзор http://www.techinvestlab.ru/586456.

Объединение всего этого зоопарка метамоделей можно устроить при помощи шаблонов и OIM ISO 15926 (а не UML). Вовсе необязательно при этом разворачивать все эти описания вокруг SPEM 2.0 или ISO 24744, но из них можно взять много интересного и полезного. Например. из ISO 24744 можно взять интересную нотацию, позволяющую организовать многоаспектное представление жизненных циклов: http://isotc.iso.org/livelink/livelink/fetch/2000/2122/327993/755080/1054034/2541793/JTC001-N-8628.pdf?nodeid=6558555&vernum=0. Так что, скорее всего, итоговую метамодель придется делать самим, не забывая кроме онтологии еще о лексике и нотации. Подробности в http://ailev.livejournal.com/761744.html.

Где взять моделер, который поддерживает (меняя лексику по потребности, и в удобных нотациях!) все эти 4 группы описаний? Скорее всего, сделать самим, используя инструменты типа платформы Whole (ключевые слова -- DLS, language workbench) -- подробности в http://ailev.livejournal.com/760577.html.

Как эти описания жизненного цикла доводить до сведения выполняющих workflow самых разных САПР (а не только до сведения людей-работников)? Скорее всего, через прикрутку софта IRING (http://iring.ids-adi.org/repository/org/ids-adi/camelot/index.html) к моделеру на платформе Whole.

Такое решение позволяет использовать нестандартную метамодель, обеспечивая стандартную функциональную совместимость (interoperability) по ISO 15926 (как работает ISO 15926 -- см. https://www.posccaesar.org/wiki/ISO15926Primer).

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

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

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

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

UPDATE: Английский пост на эту же тему -- http://levenchuk.com/2009/12/04/situational-method-engineering-and-life-cycle-modeling-roadmap/
2021 год

Качество и ности, архитектура, себестоимость и системный подход.

Настоящий системный подход в качестве главной характеристики системы называет целокупность (http://en.wikipedia.org/wiki/Holism). Или эмерджентность (http://en.wikipedia.org/wiki/Emergence). Или мета-системный переход (http://en.wikipedia.org/wiki/Metasystem_transition). Все это практически об одном и том же: "свойства системы не сводятся к свойствам ее частей".

Вся системная инженерия -- про то, как сделать систему из ее частей так, чтобы она была системой, а не суммой частей. Стандарт ISO 15288 по большей части не придерживается системного подхода: основная процедура там "разноска" (например, требований по частям системы -- allocation), причем с обеспечением "трассировки" (http://en.wikipedia.org/wiki/Traceability_matrix). Среди всех недостатков данного стандарта этот -- главный.

Беда в том, что с настоящими системами никакие "разноски" и "трассировки" не работают: свойства системы (системные свойства) не отнесешь/разнесешь к ее частям, а не разнесешь -- поэтому и не оттрассируешь. Так, качество является системным свойством. Характеристики качества потому и оказываются неуловимы, что они системны и не могут быть сведены к характеристикам частей системы -- они не могут быть "разнесены" и эта разноска не может быть "оттрассирована". Каждая деталь пиджачка может быть качественна как автономная система, но пиджачок в целом, составленный из этих подсистем, вполне может "не сидеть". Про качество пишут философские романы (http://www.pirsig.narod.ru/). Качеством спекулируют под именем ISO 9000. Качество системно, поэтому оно трудно дается.

Donald Firesmith (http://en.wikipedia.org/wiki/Donald_Firesmith) четко определяет характеристики качества, как относящиеся к нефункциональным характеристикам (наряду с характеристиками интерфейсов и данных). Это такие характеристики, как "ности" (в английском -- "ilities": reliability, mainteinability и т.д., включая safety и security) надежность, ремонтопригодность и т.д., включая безопасность и защищенность. Если мы требуем, чтобы у системы такие характеристики присутствовали -- это и есть требования качества, часть нефункциональных требований.

Поскольку эти требования эмерджентны и практически нетрассируемы к отдельным структурным элементам системы, то традиционный способ "разделяй и властвуй" с ними не работает. Так, для обоснований наличия нужной степени ностей применяется особая форма -- "оценочное дело" (в данном случае -- "дело о качестве", quality case). Качество не доказывается логически, качество доказывается как в суде: через поддержку заявлений о его наличии аргументами, и поддержку аргументов какими-то свидетельствами. Логика присутствует, но она тут теоретически бессильна: из того, что все составляющие бинарного газа безопасны вовсе не значит, что сам бинарный газ как система будет безопасен.

Абсолютно аналогично обстоит дело в архитектурном синтезе. Есть функции системы, и функциональные структуры. Нужно сообразить, как конструкция системы обеспечит функции. Конструкция не трассируется напрямую к функциям, но определяет их. "Функциональные системы" -- это не системы, их границы произвольны. Функциональный анализ ничего не скажет, что нужно сделать (что реализовать: построить, соорудить, закодировать), чтобы система могла выполнить все эти наанализированные функции. Нужно сделать архитектурный синтез, чтобы получить конструкцию -- получить описание системы на языке, понятном ее изготовителям (сборщикам, наладчикам). И тут же убедиться в том, что оттрассировать функции к элементам конструкции нельзя (я писал полтора года назад, разбираясь с работами системного инженера Jan Dietz по архитектуре: http://ailev.livejournal.com/600247.html).

От бухгалтера требуют предъявить баланс дебита и кредита, но не требуют предъявить трассу от каждого прихода к каждому расходу -- хотя как этого всем хочется! Именно от этого возникает дурилово с "себестоимостью" и той самой "разноской", от которого открещивается Голдрат (учет прохода http://webfile.ru/3994425 и дальше учет ограничений http://ailev.livejournal.com/467813.html). Именно поэтому Голдратт относит себя к последователям системного подхода, что понимает про нетрассируемость системного прохода к частям обеспечивающей его системы.

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

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