Вдруг кому нужно: официально вышел FAR 2.0 (стабильный билд 1263, 4 декабря 2009г., а первая версия появилась в 1996г.) -- http://www.farmanager.com/download.php?l=ru

Я, когда гляжу на эти двухоконные "файловые менеджеры", всегда вспоминаю неслучайность популярности этих файловых менеджеров и выигрышу их у всяких других интерфейсов. Правильный интерфейс в огромном количестве случаев заключается в двух окошках с сущностями, между которыми нужно указать отношение, построив тем самым факт (левая_сущность-отношение-правая_сущность), или выполнив действие: отношение это ведь всегда глагол!

Впрочем, я это все писал уже ("Двухоконная лесопилка", июль 2007г. -- http://ailev.livejournal.com/498958.html, где я говорил про аутлайнер-коммандер):

Дано: кучерявые (вплоть до ациклического графа) деревья (например, планы и связанные с ними расписания).

Требуется: их редактировать (создавать, удалять, копировать ветви и листья).

Решение: аутлайнер (ибо визуальное майндмэп-представление не столько для "нелинейной" работы, сколько для "последовательной/нарративной" презентации). И этот аутлайнер (в отличие от шикарного аутлайнера http://freemind.sourceforge.net/wiki/index.php/Main_Page) должен быть двухоконным (аутлайнер-коммандер):
-- короткие узкие списки, которые можно "сканировать быстрочтением" (а картинки и "широкие тексты" -- нет).
-- возможность задать команду (глагол действия) на клавиатуре.
-- местоимение "там" (второе окно) вдобавок к "тут" (в отличие от просто командной строки и однооконного интерфейса).
-- плотность представления информации много выше, чем в "графических представлениях" узлов и ребер.
-- скролл только вертикальный (ибо еще и горизонтальный скролл в "красивой картинке дерева") путает жутко.

Двухоконные редакторы онтологий тоже бывают:
-- ОргМастер в одном из режимов редактирования (http://bigc.ru/instruments/bigmasterpro/bm/om/). Это правильно (ибо два окна сущностей смотрят в одну их таксономию, а отношения показываются прямо между окнами).
-- всякие мэпперы (например, плагин к NeOn -- http://neon-toolkit.org/wiki/Ontology_Mapping), но это паллиатив (окна в разные онтологии, а правильно -- чтобы можно было и в одну и ту же!).

Спасибо bablaw, указавшему на новость почти уже трехнедельной давности: 3D принтер для печатания живых тканей: http://www.invetech.com.au/download/dec%202009%20invetech%20delivers%20organovo%203d%20bioprinter.pdf, http://www.organovo.com/news.php?id=178


На снимке Scott Dorman (инженер в одной из двух фирм-создателей -- Organovo), печатает человеческие ткани из клеток пациента, для использования при создании новых кровяных сосудов.

Микронная точность, лазерная калибровка, поэтому и возможна печать кровяных капилляров. Две печатающие головки -- одна для человеческих кленток, вторая для гидрогеля, поддерживающих веществ и прочих обеспечителей формы. Продажи с 2010, рынок ожидается только для исследователей. Но это пока.

Это в продолжение к моим недавним постингам про новый 3D-принтер с прогнозом о скорой печати бифштексов (http://ailev.livejournal.com/742703.html) плюс утверждению, что все самое главное в 3D принтерах уже произошло, и пора заняться разработкой дизайнерских программ для этой печати (http://ailev.livejournal.com/749111.html).

Про постинг о выращивании бифштекса я тоже помню (http://ailev.livejournal.com/764050.html).

Печатать и выращивать, печатать и выращивать...

Побывал на семинаре с TerraPower (http://www.intellectualventures.com/TerraPower.aspx), послушал доклад про их первый реактор на бегущей волне (TP-1), перекинулся парой слов с их сотрудниками на кофе-брейке.

Чуда никакого нет: внутри он существенно похож на любой другой реактор. Бегущая волна делается механическими руками: горит центр цилинтра, а тепловыделяющие сборки по мере сгорания перемещаются специальным механизмом на периферию цилиндра, а свеженький обедненный уран в виде сборок же (очень похожих на используемые сегодня) перемещается в центр. И так 40 лет они перемешивают 8 тонн урана на 300МВт реакторе. В принципе, все то же самое, можно было бы делать на сегодняшних реакторах (если бы знать, как перемешивать, плюс из чего делать такие ТВС, плюс ответить еще на довольно многочисленные вопросы).

Сгорать у них поначалу тоже будет 10% (что дает возможность использовать материалы с весьма консервативными 170с.н.а.), а все остальное -- это пока надежды на новые материалы (15% -- это 250с.н.а., передовой край сегодняшней материаловедческой науки. Но они мечтают о появлении материалов 500с.н.а., и тогда будет сгорать все 30%).

Лицензию они получат на очень консервативную конструкцию "почти обычного реактора", а потом будут менять лицензию по мере понимания возможностей этого реактора (возможности же меняются в зависимости от того, как лихо они будут переставлять ТВС в корпусе). Строить будут не в США, ибо разницы между коммерческими и пробными реакторами в США нет -- поэтому отлицензироваться в США для строительства в 2020г. будет нереально.

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

Основа всего их подхода -- моделирование. Основной моделирующий код был взят промышленный, и доработан. Доработку вел архитектор Windows NT -- сотрудник TerraPower рассказал, что он никогда не видел, чтобы так программировали: человек просто писал код (на фортране, ясное дело), как машинистка текст, сверху вниз с огромной скоростью, после чего этот код просто работал. Прикидки 3D сами они делают в AutoCAD, хотя их подрядчики работают со много более продвинутыми программами. Зато расчеты они делают на кластере в 1000 серверов.

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

Почему приехали в Россию? Исследования по облучению нейтронами материалов (а каждый процент выгорания -- это требования к материалам) можно делать только в России, Индии, Японии, и вот-вот можно будет делать в Китае. По этим точкам и организовали себе экскурсии. Вся кооперация в США уже налажена -- нет таких лабораторий (Аргоннская, Ливерморская, MIT и т.д.), где они бы не переманили людей в штат или не заключили контракт с самой лабораторией.

Их 60 человек, штаб-квартара в Сиэттле (да, Редмонд по факту -- пригород Сиэттла, все не случайно). Живут все в разных местах (при тех лабораториях, откуда их переманили), раз в месяц слетаются в Сиэттл на очную встречу, раз в неделю обязательный "селектор" (по телефону), очень активно используются видеоконференции. Билл Гейтс и прочие бывшие майкрософтовцы активно участвуют в работе, а не просто дали деньги -- и это участие существенно помогает.

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

Я думаю, что будет как с той самой Windows NT: неважно, какие у этих реакторов в итоге будут технические характеристики и сколь чудесными будут принятые для них технологические решения, но эти характеристики и решения будут именно такими, благодаря которым эти реакторы будут в итоге стоять на каждом столе... пардон, в каждом дворе. Я напомню, что каждый раз, когда Биллу Гейтсу указывали на то, что его операционная система Windows плоха в первые годы ее распространения по миру, он смиренно отвечал: зато она самая дешевая. И впрямь, во много раз более крутой Unix в те поры продавался по три тысячи долларов штучка. С этими реакторами на бегущей волне будет ровно такая же история. Только урановый линукс представить себе пока нельзя...

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

Еще недавно репозиториев (библиотек типовых методов, reference method library) не было, а сегодня их полно -- строгие вокруг тех или иных метамоделей (библиотеки в формате SPEM, или OPFRO)
-- нестрогие в форме PMBoK, BABoK и прочих ITIL.

Интересности начинаются, когда нам требуется исполнение методов (enactment): интеграция должна быть не только на уровне описания библиотеки методов или собранного из библиотеки одного "типового", но и на уровне описания порожденного этим типовым методом процесса -- каковой процесс (workflow) должен будет исполняться машинами и людьми в расширенном предприятии (extended enterpise).

И тут, я думаю, может помочь ISO 15926 с его подходом к интеграции данных, включая архитектуру RDL. Аналогии есть, и они более чем глубокие. Поэтому ISO 15926 может выступать как один из инструментов такой интеграции методов, равно как и образец архитектуры интеграции.

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

Поэтому у PraxOS может быть разные судьбы:
-- репозиторий методов, такой же, как OPFRO, только русскоязычный и другой по составу (например, в нем будут методы Голдратта). Но лучше сразу вступить в OPEN Framework Repository Organisation, и просто добавлять методы туда.
-- особое внимание к задаче интеграции методов и перехода к автоматизированному исполнению методов. Тогда PraxOS может выступать в качестве reference method library так же, как RDL в ISO 15926 (а в RDL ISO 15926 будет упихнут значительный кусок онтологии предметной области методологии).

По-английски на эту тему я высказался тут: http://levenchuk.com/2009/12/17/situational-method-engineering-reference-method-library-as-a-way-to-methodworkflow-integration/

Toyota предъявляет к своим руководителям и сотрудникам строгое требование: уместить всю необходимую информацию на одной стороне листа формата A3. Почему именно A3? Потому что это самый большой лист, который можно отправить по факсу.
Как правило, такой отчет представляет собой не лаконичную служебную записку, а развернутое и подробное описание процесса. Он должен содержать краткую характеристику проблемы, описание текущей ситуации, определение первопричины проблемы, предложение альтернативных решений, аргументацию выбора одного из них и анализ затрат и результатов. Все это нужно уместить на одном листе бумаги, используя как можно больше цифр и графиков.
В последние несколько лет в Toyota развернуто движение за переход к отчетам на листе формата А4 — в компании убеждены, что в меньшем можно выразить большее.
- Джеффри Лайкер, «Дао Toyota»

Нанимайте и продвигайте по службе, во-первых, на основе честности; во-вторых, мотивации; в-третьих, способностей; в-четвертых, понимания; в-пятых, знаний; и лишь в последнюю очередь — на основе опыта. Без честности мотивация опасна; без мотивации способности невозможно применить; без способностей понимание ограничено; без понимания знания ни к чему; без знаний опыт слеп. Люди, обладающие всеми этими качествами, кроме опыта, легко его приобретут и быстро найдут ему достойное применение
- Ди Хок, основатель и почетный СЕО компании Visa

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

1. Все желающие поучаствовать ставят себе Protege, закачивают туда ISO 15926-2,4 и разбираются с ISO 15926-7,8. Это у нас будет развернута среда онтологического моделирования с накоплением знаний (Protege используется вместо привычного для всех UML или ER моделера).

2. Потом туда как-то добавляется метамодель ситуационной инженерии методов ISO 24744 -- чтобы подготовить возможность работать с репозиториями методов типа PraxOS, OPFRO и прочими Body of Knowledge (foxtreme).

3. Для тестирования получившегося добавляется содержимое вебсайта www.opfro.org (piter239)
-- содержимое сайта парсируется, чтобы получились данные хоть в каком-то удобном для обработки формате, а не нынешние html-страницы
-- содержимое сайта подводится под сделанную на шаге 2 метамодель (при этом, возможно, метамодель расширяется) в формате хранения данных этой
-- содержимое сайта помещается в среду, позволяющую его удобно редактировать (скорее всего, Protege) и публиковать в виде вебсайта (скорее всего, публикационный плагин к Protege)

4. Русификация:
-- метамодель методов (итог шага 2) расширяется, чтобы учесть возможность перевода на русский и другие языки.
-- содержимое OPFRO начинает переводиться на русский

5. Делается метамодельный механизм (Reference Method Library, по архитектуре, максимально приближенной к ISO 15926 RDL), позволяющий различать оригинальное содержание OPFRO, содержание PraxOS и устраивать различные варианты гибридизации содержания (пополнение OPFRO из репозитория PraxOS и обратно). Это обеспечит международное партнерство методологов и инженеров методов. Больше RDL/RDM хороших и разных -- больше "песочниц" (sandbox из проекта IRING, чтобы онтологические эксперименты можно было вести, не мешая другим).

6. Заводится песочница RDL/RDM PraxOS и пополняется наработанным на настоящий момент содержанием методов (Голдратовщина и т.д.) -- кодирование методов (vvagr).

Ветвь: курс на автоматизированное исполнение предполагает следующие шаги, которые могут начинаться после шага 2 (foxtreme):

3. Добавить в RDL PraxOS метамодель BPMN 2, чтобы иметь возможность детального моделирования процессов.

4. Добавить метамодель сервисов, чтобы было описание той инфраструктуры, которая обеспечивает выполнение всех конкретных (ситуационных) методов-процессов-проектов.

Ветвь: курс на то, чтобы этим все могли пользоваться тоже может начинаться после шага 2:

3. Реализовать method composer на базе какой-то из language workbenches (Whole или ConceptBase).
-- реализовать презентационные нотации (например, нотация ISO 24744) для методов.

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

Ссылки и объяснения использованных терминов не даю, все это уже обсуждалось у меня в блоге: кому интересно, тот все уже понял и заинтересовался. Русскоязычных материалов по этой проблематике пока нет. Кто еще хочет поучаствовать (бескорыстно), you are welcome (пришлите мне письмо, а я отвечу с приложением материалов, которых нет в открытом доступе).

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

За $99 можно уже сегодня получить(в магазине http://www.cherrypal.com):

The 7" Cherrypal was designed with developing countries in mind. The Africa is powered with an 400 MHz processor, 256 MB DDR / 2 GB NAND-flash and runs Linux (GMo) or Windows CE. Here are some more basics: Screen: 7 inch high-resolution TFT .(800 x 480 pixels) LAN:10/100M Ethernet Access WIFI: IEEE 802.11 b/g Ethernet RJ-45 Keyboard: QWERTY 86 keys Mouse&Touch pad:build-in touch panel, set two shortcut key,and support usb port mouse USB Port: USB 2.0 x 1 (aid external memory) USB 1.1 x 2 (aid keyboard & mouse only) External Memory : SD card , U-Disk , USB-HDD Card port: SD / MMC card slot (8GB) Battery: 7.4 V 1800Mha built in Lithium battery 1800MAH Last time:4 HRS Sound effect:build-in realtek sound effect chipset, Built in 2 x 0.5W Built in speaker 1 x microphone Weight:1.2kg Size: 213.5 x 141.8 x 30.8 mm

В качестве моделера для ISO 15926 Онно Паап рекомендует использовать Protégé (http://protege.stanford.edu/) и OWL в манчестерском синтаксисе (http://www.co-ode.org/resources/reference/manchester_syntax/, поддерживается версией 4 Protégé) -- а затем поступать так, как написано в ISO 15926-7,8 (то есть работать с шаблонами).

Страничка с онтологией (части 2 и 4 стандарта) в OWL -- https://www.posccaesar.org/wiki/ISO15926inOWL

Вдруг кому нужно -- на http://www.bpmn.org/ выложен текст BPMN v2.0 Beta 1 (похоже, что это версия середины августа 2009, а выложена где-то 20 октября, судя по properties файла).

BPMN (версии 1.0) по состоянию на 24 сентября 2009г. имела 61 реализацию и еще 4 запланированных.

Американцы нередко полагают, что можно решить проблему, купив новую технику. Toyota, решая проблемы, в первую очередь занимается людьми и процессами и только потом дополняет и поддерживает работу людей с помощью техники.
В первую очередь вы должны позаботиться о том, чтобы все сотрудники компании усвоили принцип — за качество отвечает каждый. Обеспечение качества для потребителя должно определять вашу систему ценностей, и здесь нет места компромиссам, поскольку ваш бизнес существует только благодаря тому, что вы создаете добавленную ценность для потребителя, и именно это позволяет вашей компании зарабатывать деньги, а сотрудникам сохранять свои рабочие места.
- Джеффри Лайкер, «Дао Toyota»

Консалтинговые фирмы снизили долю нанимаемых выпускников бизнес-школ до половины и обнаружили, что не имеющие степени МВА сотрудники не менее успешны.
- Э. Майклз, Х. Хэнфилд-Джонс, Э. Экселрод, «Война за таланты»

Оно, понятно, что это ненастоящий суперкомпьютер (из NVIDIA GTX295), но бельгийцы собрали настольный блок о 12 терафлопсах за 6000 евро, самый мощный десктоп в мире -- http://fastra2.ua.ac.be/ (там и видео есть).

Куда девать такую мощь? Вычислять ненужное! Используется этот десктоп для 3D-томографии костей (повысили на тех же данных разрешение вдвое за счет того, что увеличили вычислительную мощность в восемь раз). Поглядел я на видео в примере, и понял: -- в основном там считаются данные, которые никогда и никому не понадобятся, их никто никогда увидеть не сможет, кроме крошечных кусочков.

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

В САПР была та же самая задача: какая-нибудь подводная лодка с 4млн. деталями не хотела быстро крутиться на экране -- пока Dassault Systemes V6 не придумала вынимать из базы, рендерить (переводить данные в визуальную форму) и дальше уже крутить только то, что на этом экране помещается. Если вся лодка, то на экране крутится лодка -- винтики в ней не крутятся, их все равно не видно. Если вы сделали зум такой, что стали видны винтики, то тогда крутятся только винтики, а лодки уже не видно, и все лишнее из вычислений для отображения изымается.

У веб-разработчиков такой прорыв был с AJAX -- как и в САПР, в революция произошла именно в тот момент, когда Google в своем почтовом интерфейсе стал обмениваться с сервером не целыми страницами, а только теми кусками, которые прямо сейчас нужны. Все необходимые решения в стандартах, серверах и браузерах к тому моменту уже давно (несколько лет как) присутствовали, но нужно было систематически провести эту идеологию в жизнь. И тут же скорости уже имеющихся каналов и производительности уже имеющихся компьютеров стало хватать для более-менее приличной работы, ранее доступной только в варианте толстых клиентов и локальной базы данных.

Точно так и тут. Не нужны алгоритмы, которые восстанавливают всё. Нужны алгоритмы и способы их вызова, которые восстанавливают только то, что можно посмотреть "на лету" -- и с тем разрешением, которое можно разглядеть. Хотя запрограммировать такое будет явно дороже, чем купить 12терафлопс в настольном исполнении -- зато потом можно будет использовать массово, иметь сканеры чуть ли не в телефонах.

Принятие к действию (enactment) метода в предприНятии (endeavour, проект/программа/организация) является существенным концептом современной ситуационной инженерии методов, в которой метод существует на трех уровнях абстракции: метамодель, методология (набор фрагментов и их связей) и конкретное предпринятие.

Чем инструменты ситуационной инженерии методов лучше инструментов управления бизнес-процессами (workflow+business rules) или инструментов управления проектами?
1. Особое внимание уделяется накоплению знаний, в том числе и неформализуемых (guidance). Поэтому в поле внимания и поддержки попадает конструирование процессов/методов из шаблонов, а не "с нуля". Выделению повторноиспользуемых шаблонов уделяется значительное внимание -- в том числе и путем использования шаблонов высокого уровня абстракции (репозиториев методов).
2. Особое внимание используется обучению людей (хелпы, описания продуктов работы и т.д.), "встроенная документация по процессу/проекту".
3. Управление процессами и проектами обычно в разных инструментах, требует разных групп описаний (на PERT не видны продукты, в BPMN трудно со стадиями и контрольными точками -- хотя в свежей версии это может быть, уже и снято, нужно проверить). В любом случае, традиционные инструменты управления процессами/проектами несбалансированы для различных (инженерной, менеджерской, клиентской, организационной) групп описаний.
4. Существенный упор на группы описаний продуктов работы, команды людей и инструментов, а не только группу описаний процесса-проекта: подразумевается модель деятельности, а не только процесса/проекта.
5. Поддерживает постепенное создание метода (emergent process -- https://openair.rgu.ac.uk/bitstream/10059/220/1/Allison+and+Merali+ISTJ+paper+final.pdf).
7. Есть тенденция к объединению достоинств традиционного процессного подхода и ситуационной инженерии методов (например, SPEM+BPMN).
8. Тоже стандартизовано, но поскольку "процесс" рассматривается как шаблон, то выразимы более сложные случаи, нежели в традиционных проектах-процесссах (например, для ISO 24774 http://www.pa.icar.cnr.it/cossentino/AOSETF08/docs/UnisconKeynote.ppt):
( тут большая картинка примера нотации ISO 24744 для enactment )
Примеры систем, которые как-то учитывают (или не учитывают) дальнейшее исполнение кастомизированного метода (инструмент+репозиторий):

( четыре системы )

Давно зрела мысль поснимать спарринги на видео, чтобы посмотреть на себя со стороны. Поснимали меня. В пятницу было предложено прийти пораньше поспаринговаться с тренером. МС, чемпион Москвы и т.д. до 61 или 57 кг. Высокий и худой. Само собой пришел. :) Пробежался 2 км для разминки и вперед. Сейчас вот после немного вина начал просмотр. На трезвую сыкотно. :) Было всего три раунда. 3 с тренером и 1 с давно занимающимся. Ну это конечно не пиздец. Ну вот честно, не пиздец. Так какая хуйта. Редкостная конечно... Замеченные косяки:
1. Защита ушей. Т.е. я поднимаю руки выше ушей и открываю печень. Куда трижды от тренера получил. :) В каждом райнде. :) Само собой нифига не вижу ударов - все еще боюсь ударов. Причем на просмотре четко видно как соперник расслабляется после моей тупой защиты и просто играет ручками по открытым зонам. Типа печень, апперкот и боковой. Получаешь все три. :) Или одной рукой печень апперкот. Со стороны красиво, но внутри обидно.
2. Нет серий в спарринге. Т.е.один два и все. Больше отбивался.
3. На встречу и на отходе не бил. Не хватает СКОРОСТИ. Забываю про такую фигню...
4.Выносливось очень очень на низком уровне. Хотя пробежаться в приличном темпе 6 км не проблема. Скорее даже скоростной выносливости не хватает.
5. Нет нормального шага на ударе. Прямая связь с п.2. Если бы нормально работал ногами, то и проще было бы бить больше двух.
6. В защите наклоняюсь вперед. Скручиваюсь в позу эмбриона. Рефлекс фигли...
В третьем раунде тренер даже сам сказал про защиту. Мда...

Продолжаем тренироваться.

З.Ы. Сегодня пострелял из 12 калибра Binelli автоматического. Внушает. Позже постреляем из пестика. :)

Много раз читал (и даже что-то писал) про ADOM (Application-based Domain Modeling, но только сейчас обратил внимание на самое интересное: они автоматизируют распознавание предметных областей: http://mis.hevra.haifa.ac.il/~iris/research/SDM/index.htm

Берут модели нескольких приложений, и делают из них модель предметной области (метамодель) путем полуавтоматического обобщения (Semi-Atomated Domain Modeling Approach). Тренируются главным образом на проектном управлении и системах планирования производства -- http://mis.hevra.haifa.ac.il/~iris/research/SDM/SDMrepository.htm

Как я понимаю, примерно так же действуют люди из тусовки ISO 15926: они делают конкретные мэппинги в конкретных приложениях, добавляя в RDL то, чего там для этого не хватает. В итоге предметные области будут иметь структуру, почерпнутую главным образом из приложений (а приложения имеют метамодели/онтологии, разработанные безо всякого domain-driven подхода. То есть никакие -- но в любом случае знание предметной области в них будет присутствовать, и его можно пытаться отловить).

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

Не выдержал, и заплатил за Пандору ($36 в год, страшные деньги!). Их реклама и паузы совершенно не раздражали, но захотелось послушать музыку на 192Kbps. Послушал, и не пожалел. Оказывается, я вполне себе аудиофил. А поскольку у меня стоит профессиональная аппаратура, то на ней разница очень хорошо слышна (если кто хочет попробовать: слушайте звуки ударных инструментов. Если слышите реальные удары железок и деревяшек, то качество хорошее. А если эти железки и деревяшки бьют как бы через тряпочки разной толщины -- то эти тряпочки как раз у вас в звуковом тракте, у кого-то бьют через носовой платочек, а у кого-то и через толстое ватное одеяло).

Напомню, я инструкцию по прослушиванию из России дал вот тут: http://ailev.livejournal.com/752249.html

Этот музыкальный сервис -- лучший.

А вот риппер к ней (например, типа http://applian.com/replay-music/) покупать не хочу. Почему-то мне странна мысль записывать радио. Если уж что-то понравилось, то лучше сгулять в торрренты.

Кто соскучился -- налетайте. Demonoid восстановился.

Вот новое (24 ноября 2009г.) интервью с Голдраттом по поводу его новой книжки "Разве это не ясно?! (Isn't It Obvious?) про розничную торговлю: http://www.scribd.com/doc/23593618/Clarke-Interviews-Eli-Goldratt (аудио -- http://media.libsyn.com/media/clarkeching/Clarke_Interviews_Eli_Goldratt_about_Isnt_It_Obvious.mp3).

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

А сейчас он пишет книжку про изготовление под заказ (make to order), то есть переписывает "Ту самую Цель" -- хочет показать три больших скачка (одна из идей Голдратта заключается в том, чтобы не полировать очередное решение, а немедлено делать следующий Большой Скачок. В книжках он хочет показывать три таких скачка, чтобы был понятен также и паттерн непрерывного роста, а не только паттерн одного шага в этом росте).

А наиболее важной из написанных книг Голдратт считает "The Choice".

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

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

UPDATE: вот еще комментарий по этому интервью -- о финансовом кризисе в восприятии Голдратта: http://vvagr.livejournal.com/1430101.html

Упражнения на тренингах сейчас модно называть играми -- вот, например, сборник agile-ориентированных игр: http://blog.tastycupcakes.com/. От игры до театра один шаг -- и дальше на тренингах гибких людей появляются вообще уроки театральной импровизации (http://www.infoq.com/news/2009/12/agile-teaching-games).

По поводу этих игр обычно дискуссия: это трата времени или наоборот, единственный способ понять содержание?! Главное, что в этом деле даже эксперимента с воспроизводимыми результатами не поставишь, настолько все зависит от сочетания тех, кто пришел и того, кто пытается учить.

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

Напомню, кстати, что изо всех традиционных метафор (обычно -- войны, или каких-нибудь боевых искусств) мне метафора игры сильно больше нравится. А для Agile метафора игры и вообще ключевая (напомню из http://ailev.livejournal.com/723608.html):

вечная дискуссия про отличие agile-проектов от анархических, в которых работы не планируются никаким образом, и не используются никакие методы хранения. Интересно наблюдать, как сторонники дисциплины "водопадного" подхода не могут вообразить наличие любой другой дисциплины. С их точки зрения, если игра не идет по правилам шахмат, то игра обязательно идет без правил вообще -- и тогда она вообще не игра. Игры в футбол или в Го они не могут себе представить вообще. Объяснить, что у agile планирование и архитектурная работа подчиняются не менее жесткой дисциплине, чем при водопадном подходе, оказывается практически невозможным. Тем не менее, в жизни более чем регулярно встречаются ситуации, когда водопадный подход не применяется -- и эти ситуации почему-то автоматически приписываются к agile. Как будто, если я пишу не правой рукой, значит я автоматически пишу левой. Нет! Я ведь могу при этом писать ногой (с соответствующим ноге качеством письма), или даже вообще не писать. В ситуациях неприменения водопадного подхода agile чаще всего тоже не применяется, что бы об этом не говорили (например, если нет регулярных релизов, связанных с ними пересмотров выделения ресурсов, планирования итераций, то при чем тут agile?). Основные беды в проектном управлении не от водопада или agile-подхода, а от полного отсутствия метода.

А для контраста приведу ровно обратный пример: отсутствие игры там, где ее все усматривают -- Second Life, в которой нет ни правил, ни цели, ни выигрыша...

DISCLAIMER. Хейзингу я читал еще в нежном возрасте, и про play-game-perfomance СМД-методологов тоже знаю.

Инженерия требований представляет собой одну из основных дисциплин системной инженерии, наряду с инженерией системной архитектуры, интеграцией и т.д.

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

Для нижеприведенной структуры не предполагается какая-либо последовательность не только применения в проекте, но и изложения (например, в учебных курсах). Для развернутого представления подобного материала должен быть использован гипертекст. Так, в репозитории методов OPEN Process Framework (http://www.opfro.org/index.html?Components/WorkUnits/Activities/RequirementsEngineering/RequirementsEngineering.html~Contents) можно найти в виде гипертекста обширный объем знаний, предусматриваемый предлагаемой нами структурой, хотя и не все знания.

1. Описание предметной области (онтологии) требований
1.1 Назначение требований
1.2. Требования как рабочие продукты (артефакт)
1.2.1. Отличия рабочих продуктов требований от архитектурных и проектных рабочих продуктов. Различение требований и ограничений.
1.2.2. Виды формулирования требований и требования к ним
-- уровень неформальности: текст -- модели
-- используемая парадигма (декларативные-процесссные)
-- информационные модели (в том числе онтологии и метамодели для них -- как минимум, глоссарий).
-- спецификации требований. Шаблоны информационных объектов.
-- концепции
1.2.3 Виды использования
-- автономные требования
-- требования как задания на испытания и test-driven development
-- требования как запросы на изменения и практики issue tracking
1.2.4 Виды по источникам
-- требования и нужды заинтересованных сторон
-- результат анализа требований
1.3. Классификация требований по их предмету
1.3.1. Контрактные, производные, эксплуатационные, к обслуживанию, обеспечению, обучению, прекращению использования, организационные, программные, аппаратные, оборудованию и т.д. -- разнообразие типов требований, каждый из которых требует своих рабочих продуктов, производящих и использующих их практик и квалификации инженеров требований
1.3.1. К методу разработки
1.3.2. К продукту
1.3.2.1. Функциональные
1.3.2.2. Нефункциональные
-- качества (ценовая доступность, производительность, настраиваемость, надежность (защитимость (устойчивость, безопасность, защищенность, выживаемость), бездефектность (доступность, правильность, предсказуемость, надежность-стабильность)), экономичность, сопрягаемость, эксплуатационные характеристики, поддерживаемость, удобство в использовании
-- к данным
-- к интерфейсам
-- ограничения (включают все виды требований)

2. Практики работы с требованиями
2.1. Место практик инженерии требований
-- в жизненном цикле
-- среди других инженерных дисциплин
-- смежные практики: планировать усилия инженерии требований, готовить инфраструктуру управления требованиями и моделирования, управлять данными и конфигурацией требований, улучшать практики и т.д.
2.2 Стандартизация практик
-- международные стандарты: ISO 15288 и ISO 12207, ISO 29148, IEEE 1233, для обоснования ISO 15026
-- частные стандарты: OPFRO, QUASAR
2.3. Разнообразие практик в части по природы системы ([программоемкая] система, модель бизнеса, предметная область, компонент, семейство продуктов, программное приложение, датацентр, завод и т.д.). Стандарты BABOK, ITIL.
2.4. Типовой набор практик
2.4.1. бизнес-анализ
-- анализ клиента
-- анализ конкурента
-- анализ рынка
-- анализ технологии
-- анализ пользователя
-- профилирование заинтересованных сторон
-- выявление целей заинтересованных сторон
-- разработка обоснования бизнес-модели
2.4.2. Предвосхищение (visioning) -- бизнеса, системы, приложения, компоненты
2.4.3. Разработка требований
-- выявление требований
-- переиспользование требований
-- анализ (моделирование) требований
-- прототипирование требований
-- формулирование требований
-- валидация требований

3. Обоснование выполнения требований (requirements case)
3.1. Рабочие продукты (декларации, аргументы, свидетельства)
3.2. Практики обоснования
-- набор практик обоснования
-- жизненный цикл обоснования

4. Команда, ее роли и требуемые квалификации
-- источники требований
-- разработка требований
-- использование требований
-- проверка требований
-- управление требованиями

5. Инструменты инженерии требований
-- автономные требования (типа IRqA etc.)
-- требования-запросы (Dassault Systemes Requirements/Engineering Portal)
-- модели требований (моделеры, в том числе интегрируемые в САПР)

Замечания, предложения, вопросы?

так мало нужно девушке, чтобы чувствовать себя красивой:

черная юбка, черная блузка, минимум косметики и любящий ее мужчина рядом

Слушаю шаманское радио в Pandora (называется оно у меня shaman hey-heya), и время от времени музыкальный алгоритм подмешивает к шаманским бессмертным хитам типа animal sacrifice music творчество глубоко политизированной группы Quilapayun -- вот только что они спели шаманский хит "По долинам и по взгорьям" на испанском языке (ага, про волочаевские дни там хорошо слышится). Можно только пожалеть алгоритм классификации радио Пандоры, ведь в остальных случаях он вполне работает. Не стреляйте в компьютер, он классифицирует, как умеет. Если музыка шаманская, он ее так и отклассифицирует -- слов-то он не понимает...

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

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

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

Так вот, мейнстримовские экономисты ничего не понимают в моделях, заявляю ответственно -- они считают узкий класс численных моделек всем моделированием! Они считают, что в других моделях нет математики! Они смешат мои тапочки, они отстали на полвека. Современное моделирование тем и сильно, что от чисто численных моделей стремительно уходит в другие типы моделирования -- не менее строгие. Я даже не буду эту тему тут разворачивать, ибо надеюсь, что их в Гугле еще не забанили. Но если уж очень хочется, то могут начать, например, с моего еще летнего постинга http://ailev.livejournal.com/721298.html, где я как раз защищаю аналитическое моделирование от "критики справа". Или постинга http://ailev.livejournal.com/747288.html, где я приводил темы современных конференций по моделированию.

Поэтому я бы нашим мейнстримовцам-экономистам вчинил бы встречный иск: не оболванивайте людей, не вешайте им шоры на глаза по поводу того, что является истинным моделированием и истинной экономикой.

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

Я, замечу, именно поэтому и люблю австрийскую школу, что она серьезно относится к онтологическим и эпистемологическим вопросам, серьезно относится к своему методу. И не позволяет этот метод профанировать, сводя экономические понятийные модели только к аналитическим/математическим. Австрийская школа как раз и занимается Моделированием, а мейнстрим от нее в этом плане безнадежно отстал.

Ничего, скоро экономмейстрим сообразит, что промахнул мимо поворота, и вместо нынешнего массового подсаживания на Modelica породит чудовищный UML 2 Profile для своих надобностей -- EconML -- и будет применять его так же неуклюже, как сейчас численные методы. А я буду лениво ругать этот EconML по той же линии, что сейчас ругаю самый модный язык мейнстрима системной инженерии -- SysML. И мейнстримные экономисты в очередной раз запишут меня во враги народа. Но это будет еще через десять лет, в мейнстриме обычно не торопятся.

UPDATE: вот, кстати, еще пример пользователя экономавстризма -- http://screamager.deadjournal.com/445848.html (осторожно, там много абсолютно ненормативной лексики). Пора бы господам экономученым привыкнуть, что есть и просто пользователи их теорий -- и эти пользователи либо удовлетворены практическими результатами, либо нет.

Любимый мой способ отследить современные тренды -- это поглядеть на темы последних конференций. Раз в пару лет проходит конференция по моделеориентированной системной инженерии. Вот темы MBSE'09 (http://www1.technion.ac.il/_root/Announcements/info-links/MBSE_2009_Call_for_Papers_v12.pdf):
-- языки и подходы концептуального (понятийного) моделирования
-- онтологические основания для и требования из языка моделирования системной инженерии
-- модели исследование операций и их отношение к системной инженерии
-- стандарты для моделей системной инженерии
-- освоение практик моделирования в организациях: подходы, достижения и полученные уроки
-- UML и SysML: предмет, ожидания и наблюдения в отношении системной инженерии
-- объектно-процессная методология для системного моделирования и поддержки жизненного цикла
-- одна против множества групп описаний: согласование и интеграция моделей системы
-- образование для целостного системного мышления и моделирования
-- подходы к управлению сложностью в языках моделирования систем
-- отношение между языками моделирования систем и методологией разработки систем
-- методологии, процессы и языки моделирования: следствия и влияния
-- информационная инженерия и инженерия программных систем: поддисциплина системной инженерии или отдельная область?
-- инженерия человеческого познания (cognition) и человеческого фактора при проектировании систем
-- промышленный опыт моделирования сложных систем: полученные уроки
-- сравнительное изучение подходов и языков концептуального моделирования
-- концептуальное моделирование для гибкой разработки систем
-- автоматическое порождение артефактов (например, кода, документации) из моделей
-- оценка и верификация моделей систем
-- модели сервисной инженерии
-- модели системной инженерии в промышленном контексте
-- моделеориентированное управление проектом и управление жизненным циклом продукта
-- моделеориентированное проектирование верификации и испытаний
-- новые типы парадигм системной инженерии: биологическая, нано, и т.д.

Удивительно: именно я оказался человеком, который сообщил тусовке разработчиков ISO 15926 о стандарте SBVR. Теперь я им сообщил об OMG ODM (http://levenchuk.com/2009/12/12/omg-ontology-representation-related-standards-odm-sbvr-and-iso-15926/).

А всего-то я от них хочу, чтобы они определили стандарт, в котором готовить русскоязычную версию ISO 15926, но их интересует более широкий круг вопросов.

Интересно, что наш план по разработке онтологии деятельности в принципе был одобрен -- и нам даже предложили по нему сделать рабочую группу PoscCAESAR (см. комменты к http://levenchuk.com/2009/12/10/activity-modeling-and-iso-15926/). Жаль только, что мы эту рабочую группу создать сами пока не в состоянии (мне кажется, что это все-таки не совсем по профилю деятельность для организационных консультантов -- быть лидерами методологического проекта). Но с удовольствием поучаствуем, буде она создастся -- как неосновной деятельностью заниматься методологией весьма полезно.

После чего PraxOS будет иметь стандартизованную онтологию деятельности -- причем по-русски и по-ангельски, что приятно. И софт PraxOS сможет легко и свободно стыковаться с поддерживающими ISO 15926 САПРами -- если только не окажется, что рабочая группа, когда она соберется, сделает такую "консенсусную" онтологию деятельности, которая свяжет нас по рукам и ногам и поэтому будет нами же с негодованием отвергнута. Но попытка не пытка, быть стандартизированными на международном уровне -- это все-таки правильно.