Лабораторный журнал

Ближайшие планы PraxOS

2009-12-16T12:27:15Z

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

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 (пришлите мне письмо, а я отвечу с приложением материалов, которых нет в открытом доступе).

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

Cherrypal Africa -- компьютер за $99

2009-12-15T23:22:06Z

За $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é

2009-12-15T22:30:48Z

В качестве моделера для 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

BPMN 2.0 Beta 1

2009-12-15T22:15:51Z

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

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

Десктоп суперкомпьютеры по500 евро за терафлопс: куда девать такую мощь

2009-12-15T09:22:33Z

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

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

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

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

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

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

Выполнение метода

2009-12-15T07:46:21Z

Выполнение (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):

Примеры систем, которые как-то учитывают (или не учитывают) дальнейшее исполнение кастомизированного метода (инструмент+репозиторий):

APE editor + O-maSE repository (OPF+SPEM)
http://people.cis.ksu.edu/~jgarciao/publications/p707-garcia-ojeda.pdf

metameth tool + prode repository
http://www.pa.icar.cnr.it/woa08/materiali/Talk/Seidita.ppt

no tools + OPFRO repository (желаемая архитектура, в модели нет enactment)
http://www.opfro.org/index.html?OPFRO/FutureEnhancements.html~Contents

Fujitsu Apt (EssWork, SPEM-based)
http://www.ivarjacobson.com/resource.aspx?id=525

Полуавтоматическое распознавание предметных областей

2009-12-13T22:11:21Z

Много раз читал (и даже что-то писал) про 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 нужно приглядеться внимательней. Это вся та же идея расположиться повыше в знаниевой трофической цепи, использовав чью-нибудь онтологическую работу как исходный материал.

Pandora на 192Kbps

2009-12-13T21:55:21Z

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

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

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

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

Demonoid вернулся

2009-12-13T21:30:28Z

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

Свежее интервью с Голдраттом

2009-12-13T21:28:07Z

Вот новое (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

Игры и упражнения в обучении

2009-12-13T20:09:01Z

Упражнения на тренингах сейчас модно называть играми -- вот, например, сборник 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 СМД-методологов тоже знаю.

Инженерия требований

2009-12-13T18:23:32Z

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

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

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

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)
-- модели требований (моделеры, в том числе интегрируемые в САПР)

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

Политическое шаманство, австрийская школа, математические и прочие модели

2009-12-12T19:10:25Z

Слушаю шаманское радио в 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 (осторожно, там много абсолютно ненормативной лексики). Пора бы господам экономученым привыкнуть, что есть и просто пользователи их теорий -- и эти пользователи либо удовлетворены практическими результатами, либо нет.

Тренды моделеориентированной системной инженерии

2009-12-12T08:52:40Z

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

PraxOS и ISO 15926

2009-12-11T22:58:49Z

Удивительно: именно я оказался человеком, который сообщил тусовке разработчиков 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 САПРами -- если только не окажется, что рабочая группа, когда она соберется, сделает такую "консенсусную" онтологию деятельности, которая свяжет нас по рукам и ногам и поэтому будет нами же с негодованием отвергнута. Но попытка не пытка, быть стандартизированными на международном уровне -- это все-таки правильно.

Введение в системную инженерию. Лекция вторая.

2009-12-11T18:45:11Z

Первая моя лекция была пару недель назад (комментарий --http://ailev.livejournal.com/757488.html, видео -- http://ailev.livejournal.com/757223.html).

Сегодня мы с vvagr прочли вторую лекцию (хотя и не стали давать ее трансляцию в "прямом интернете", как в прошлый раз):

Кто не хочет смотреть через плеер, вот одним файлом (268Мб): http://narod.ru/disk/15879642000/SE_intro2_11dec09.ASF.html

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

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

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

Уже в кулуарах обсудили, что в ВУЗах всей этой "практической системной инженерии" не проходят примерно по той же причине, по какой предпочитают учить студентов истории философии, но не учить философствованию.

Моделирование деятельности и ISO 15926

2009-12-10T20:40:16Z

Этот пост -- пересказ сделанного по просьбе сообщества ISO 15926 (ага, у меня идет с ними какое-то общение, и они читают мой блог) англоязычного постинга http://levenchuk.com/2009/12/10/activity-modeling-and-iso-15926/.

Для описания деятельности требуется как минимум 4 разных группы описаний (клиентская, инженерная, менеджерская, организационная -- http://ailev.livejournal.com/764492.html (но об этом много раз писалось и раньше, например http://ailev.livejournal.com/695537.html).

Должна существовать какая-то схема (метамодель, онтология) для того, чтобы выразить эти четыре обязательные группы описаний. Многие требования к метамодели описания деятельности (поддержка множества групп описаний одновременно, масштабируемость, возможность нескольких уровней специализации/экземпляризации, возможность порождения выполняемого экземпляра модели) уже обсуждались в рамках ситуационной инженерии методов (http://ailev.livejournal.com/750878.html). Мы добавим еще несколько. Метамодель деятельности должна быть:
-- согласована с/выражена в терминах онтологии более высокого уровня (upper ontology) для того, чтобы описание деятельности потом можно было связать с описаниями продукта и описаниями сервисов (в смысле SOA -- какая-то инфраструктура эти деятельности должна поддерживать).
-- достаточно богата, чтобы позволять отображение (mapping) деятельности в инженерных САПР (на двух уровнях: тамошние workflow/routing проектных решений между рабочими местами самого САПР, и описания инженерного процесса на уровне модели управления жизненным циклом проектируемого объекта)
-- должна поддерживать правильную модель времени (http://www.conradbock.org/)
-- должна поддерживать системный подход, поэтому определять жизненный цикл как онтологическую сущность, которая имеет все эти различные группы описаний

Метамодель деятельности (activity) помянута как часть в ISO 15926-4 но нет никакой теории под относящимися к деятельности понятиями из ISO 15926-2,4 и тем, что уже находится в RDL. Информационные объекты модели (OIM) должны быть добавлены в RDL на трех уровнях:
-- метамодель деятельности (понятия)
-- словари деятельности (для различных отраслевых и национальных языков)
-- нотации деятельности (чтобы выражать данные для этой метамодели в "родной" нейтральной по отношению к вендорам софта нотации, а не только в софте в ходе проектов отображения-mapping) [сейчас нет возможности погружать нотации в RDL. Для этого сначала нужно добавить понятия предметной области нотационной инженерии (notational engineering, http://ailev.livejournal.com/549681.html, http://ailev.livejournal.com/546301.html -- но наверняка это все известно еще под огромным количеством имен. В конце концов, сейчас построением языков занимаются все, кому не лень).

Где мы можем взять ядро такой модели деятельности?
-- метамодель ситуационной инженерии деятельности (по меньшей мере эта метамодель уже сочетает инженерную и менеджерскую группу описаний). Например, мы можем начать с метамодели ISO 24744. Этот способ требует просто закодировать ее в одном из представлений ISO 15926 (например, с использованием протошаблонов). Также мы можем применить предложенную для ISO 24744 нотацию для описания жизненных циклов (http://isotc.iso.org/livelink/livelink/fetch/2000/2122/327993/755080/1054034/2541793/JTC001-N-8628.pdf?nodeid=6558555&vernum=0).
-- современные "схемы" (метамодели) САПР -- это очень интересно, ибо в САПРах уже реализованы связи между моделями деятельности и моделями продуктов.
-- исследовательские обзоры деятельностно-ориентированных метамоделей (например, работы Tyson Browning по архитектурам продуктовых процессов -- http://sbufaculty.tcu.edu/tbrowning/Publications/Browning%20(2009)–SE%20Towards%20a%20PAF.pdf).
-- метамодели деятельности из других онтологий, типа языка спецификации процессов (PSL) или CYC.
-- организационные метамодели DEMO (http://demo.nl)
-- онтологии экономного (lean) производства/строительства (Голдратт, LastPlanner, "фабричная физика" и т.д.)
-- парадигма агентского программирования (для моделирования целей деятельности, назначения мероприятий и т.д.)

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

SEMAT -- метод и теория программной инженерии (software engineering method and theory)

2009-12-10T17:47:29Z

Стал подписантом SEMAT -- http://www.semat.org. Там ставится задача найти теоретическое ядро программной инженерии: найти те инварианты описания деятельности программных инженеров, которые верны в любых разработках и которые можно дальше детализировать и уточнять в зависимости от ситуации. Список литературы: http://www.semat.org/bin/view/Main/PubsandRefs

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

Они говорят, что программная инженерия сейчас не представляет собой предмета -- это то ли набор преходящих мод, то ли политика с попытками собрать под эмоциональные лозунги типа agile manifesto побольше сторонников, то ли искусство. Текущие методы -- коктейль практик, а не разворачивание какой-то теоретической идеи. Средние века, одним словом. А хочется сделать красиво и научно -- чем и займутся.

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

А дальше есть варианты написать строчку либо "буду счастлив, если они там что-нибудь сделают", либо "буду счастлив, если мы что-нибудь сделаем". Забавно, что я стал обращать на такие формулировки внимание.

Моделирование ISO 15288 и ISO 24748-1 в SPEM 2.0

2009-12-10T13:14:30Z

Вчера на 18-м заседании Русского отделения INCOSE vvagr выступил с докладом "Моделирование в метамодели SPEM 2.0 с использованием EPF Composer" -- http://community.livejournal.com/incose_ru/10384.html.

Пройдя по ссылке, вы найдете не только два с половиной часа видео с заседания (довольно бессмысленное, ибо текст на экране нечитаем. Хотя звук вполне осмысленный и разборчивый), но и ссылку на пару плагинов моделей (практики ISO 15288 и иллюстративный жизненный цикл ISO 24748) и комментарий по принятым при их моделировании решениям -- http://www.techinvestlab.ru/files/LCModels/tilselcmodels.rar

Не забывайте саму библиотеку держать в корне диска, ибо при моделировании получились очень длинные имена файлов, и длинный путь к библиотеке где-нибудь внутри My Documents в сочетании с этими длинными именами приводит к ошибкам в файловой системе.

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

2009-12-10T10:33:55Z

Когда уведомления о комментах стали приходить ко мне на почту через сутки-двое, я нашел способ поправить ситуацию -- http://www.livejournal.com/inbox/, где эти комменты появлялись мнгновенно. Пару суток назад ситуация драматически поменялась: в инбоксе уведомления о комментах появляются теперь тоже через сутки, или даже больше.

Поэтому не удивляйтесь, что я стал отвечать с существенным опозданием. Я просто день, два или три не знаю, что мне написали.

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

Канадским крупнейшим звукозаписывающим лейблам хотят приписать $6млрд. за нарушение копирайта

2009-12-08T22:57:51Z

Как причудлива судьба: выяснилось, что канадские крупнейшие студии звукозаписи не заплатили по совокупности причин за 300тыс. песенок, которые они издали в составе сборников -- и поэтому им собираются вчинить иск за нарушение ими копирайта. Хитрость в том, что за каждое нарушение от них хотят $20тыс., посчитанных ровно по той же методике, по которой они считают ущерб от интернет-пиратов. Ежели вся затея окажется успешной (что вряд ли), то готовящийся коллективный иск будет на сумму $6млрд. -- http://www.thestar.com/business/article/735096--geist-record-industry-faces-liability-over-infringement

Об выбор САПРов

2009-12-08T22:35:34Z

Два полных дня с утра до вечера дня провел за изучением вопроса о САПР (включая слушание докладов, беседы с поставщиками, чтение документации в количестве и просмотр мнений в форумах. UPDATE: я САПРЫ и PLM системы не различаю принципиально, это все автоматизация проектирования и производства). Результаты:

1. Все ведущие "поставщики решений" нажрались "лучших продуктов" в виде закупки компаний, и теперь наперегонки пытаются переварить их в "продуктную линию, закрывающую весь спектр". Переваривание получается у кого-то плохо, у кого-то очень плохо.

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

3. Проблемы те же, что и с внедрением больших ERP-систем: либо предприятие начинает работать так, что решение "из коробки" подкручивать не нужно, либо подкручивать будет стоить столько же, сколько заставить предприятие работать так, как требует этого программа. Беда в том, что из коробки отнюдь не все решения работают.

"Процесс решает всё" -- САПРы не слишком помогут при закупке одного модуля на одном рабочем месте. Нужно много разных модулей на разные рабочие места, и чтобы они все работали вместе. Это самое трудное.

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

Про ситуационную инженерию методов все они ничего не слышали, но в плане activity modeling -- все имеют какие-то варианты схемы для нескольких видов workflow, проектов и т.д. Почему несколько? Ну, там ведь в ядре сидят несколько продуктов разных разработчиков, у каждого из которых когда-то был свой вариант воркфлоу...

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

5. В сотрудников российских офисов не стрелять: они продают, как умеют! Опыт показывает, что самые интересные сведения находятся в R&D отделениях фирм-поставщиков, и требуются немалые усилия, чтобы местным сейлзам добыть актуальную информацию, а не маркетинговое бла-бла-бла. Кстати, про маркетинговое бла-бла-бла: в САПРах, оказывается, этого не меньше, чем в ERP-мире. Или даже больше: материалы все под большим секретом, описания продуктов максимально неподробны, на вебсайтах ничего кроме бла-бла-бла-лучше-всех-бла-бла нет.

6. На сегодняшний день в части работ в части замысла-ТЭО-проектирования моим лидером является Dassault Systemes V6:
-- продукты, конечно существенно недопереварены (так, данные 3D-проекта и жизненного цикла инжиниринга "синхронизированы" уже, но имеют до сих пор разные называния и структуру), но уже четко видно, в какую сторону это переваривание идет -- от документоцентрики стремительно отказываются, архитектура становится SOA. Есть вижн (чего не нашел у других). А вижн вполне может быть конкурентным преимуществом.
-- системная инженерия со всеми ее свойствами (рекурсивность, инкрементальность, итеративность и т.д.) лежит в основе всей продуктной линейки, масштабируемость налицо. От фотоаппарата до небоскреба будет проектироваться одним и тем же софтом, и лежать все это будет в одной и той же базе (которая, кстати, у в ноябре 2009г. вышедшего продукта V6E2010X может находиться в облаке, чтобы ресурсов всегда было "достаточно"). V-диаграмма поддерживается программно (ага, прямая аллюзия с "аппаратно"). У многих других продуктов это требуется специально настраивать, если догадываешься о ее существовании. Тут ей обучают в порядке пользования программой. У меня есть впечатление, что курсу системной инженерии вполне можно учить с использованием этого программного обеспечения: там "жизненный цикл" у любого объекта базы данных.
-- интерфейсы не хочется лизнуть, как у Apple, но они явно поприятнее, нежели у конкурентов. Более того, коллаборативность там понимают абсолютно правильно: работа в итоге должна быть в среде, похожей на виртуальный многопользовательский мир типа Second Life.

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

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

Недостатков у Dassault Systemes V6 тоже тьма тьмущая, начиная с самой высокой по сравнению с конкурентами цены и заканчивая "эта фича у нас есть, но вам она будет доступна только в версии 2012года".

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

В следующих сериях этой саги о САПРах бы рассказал:
-- о жути таблично-формовых мастдайных интерфейсов (или у вас абсолютно единообразный ужасный таблично-формовый интерфейс, или единообразные команды с не пойми какими ключами, или вам нужно учить десятки удобных текстовых и графических DSL -- которые вы просто не сможете все запомнить. Что делать?)
-- о ситуационной инженерии методов и "настройке" монстрообразных корпоративных приложений типа САПР, EPR и т.д.
-- о софтовых приложениях для предприятия vs приложения предприятия к софтам.

Системные инженеры древнего Рима

2009-12-05T19:49:03Z

Леонид Каганов про системную инженерию древних (http://lleo.aha.ru/dnevnik/2009/11/25.html):

Акведук Пон-дю-Гар снабжал водой не Рим, а городок под названием Немаус. Там и без него имелось несколько источников водоснабжения, но этот был главный. Он подавал воду из источника за 20 километров. Но 20 километров — это если смотреть по прямой. А напрямик воду не проведешь, потому что сплошные ущелья, холмы, и надо долбить 8 километров тоннеля в камне. Что даже сегодня не каждый горбюджет может себе позволить. Поэтому римляне ведут воду в обход по дуге в 55 километров. Сложность задачи в том, что перепад уровня воды от источника до города всего 11 метров, поэтому трассу надо спроектировать так, чтобы равномерно поделить это расстояние и вода все-таки двигалась самотеком. Уклон каменного желоба составлял от 7 до 60 сантиметров на километр (!). И даже такой разброс в цифрах не потому, что «так получилось», а строго по проекту: перед Пон-де-Гар римляне максимально понизили уровень трассы, чтобы облегчить строительство моста, а дальше шлифовали миллиметры. Как им удавалось без лазерных рулеток так точно выдержать уклон каменного желоба — загадка. Как им вообще удавалось делать такие точные расчеты и так строго соблюдать проект — еще большая загадка, потому что заново эти законы гидротехники были открыты только в 19 веке.

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

Дизайн рулит

2009-12-05T19:37:34Z

Нашел аудиоплейер, который меня почему-то сразил:

Я сам грозный противник всякого антиквариата и воспроизведения облика кареты в автомобиле, а облика автомобиля в самолете, но этот бобинник почему-то не оставил равнодушным. Когда-то я снял со своей Ноты-М крышку и засунул круглую батарейку "Сатурн" в дырку между корпусом и кнопками управления. После этого эта "приставка" ставилась на пол. Когда я нажимал ногой на выступающую батарейку, то она давила на рычаг, и лента начинала двигаться. А если отпускал -- лента останавливалась. Руки же при этом оставались свободными, чтобы в этом старт-стопном режиме писать слова играемых песен. Выглядела эта приставка без крышки некрасиво, но зато пользоваться было очень удобно. Художественный дизайн -- это когда и выглядит красиво, и пользоваться удобно.

Увы, этим плеером недостаточно удобно пользоваться. Например, он не поддерживает .flac

Еще один дизайн, который сегодня мне страшно понравился, это рейтинг записей в блогах рунета в формате просмотра "эквалайзером" -- http://whoyougle.ru/blogs/personal/. Всем составителям рейтингов (любых, не только блогосферы) учиться, учиться и учиться. Всем пользователям рейтингов (любых) крутить слайдеры и много думать.

Яндекс, конечно, рулез -- отдал дизайнерам рейтингов дизайнерово, оставив себе трудный инфраструктурный хлеб. Смотреть хит парад рейтинг-дизайнеров и удивляться тщательно срежиссированному народному выбору можно тут: http://yaca.yandex.ru/yca/ungrp/cat/Computers/Internet/Ratings/blogs_ratings/.

Три занятия консультанта и план релиза PraxOS 2.2

2009-12-05T18:06:32Z

1. Три занятия консультанта
Когда-то давным-давно (последний раз я писал об этом в 2005г. -- http://ailev.livejournal.com/366097.html) я вывел правило успешной работы:
а) треть времени заниматься чем-то полезным другим людям -- перформанс, приложение сил, демонстрация мастерства. Это и есть видимая часть айсберга консультационной работы. Не это является делом консультанта, это приложение дела.
б) треть времени заниматься своим инструментарием той области, в которой приносишь пользу. Это и есть основное дело. Музыкант всю жизнь репетирует, спортсмен всю жизнь тренируется, консультант всю жизнь учится методам -- это и есть их работа.
в) треть времени заниматься инструментарием того, чем делаешь приносящие пользу инструменты. Музыканту нужно разобраться с его музыкой, спортсмену с физикой движений и психологией, консультанту нужно разобраться в методах. Или тебе свезло, и у тебя есть Великий Гуру, который обеспечивает тебя надлежащим инструментарием для твоего основного дела -- продюсер у музыканта, тренер у спортсмена, и методолог у консультанта, или не свезло -- и тогда нужно заниматься этим делом самостоятельно.

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

А) приложение дела
Я занимаюсь нанесением непоправимой пользы в ходе консультирования -- работы с ситуациями моих клиентов (http://ailev.livejournal.com/759616.html). "Ситуация" -- это когда непонятно, что делать. "Ситуация" -- это когда неизвестен метод. Передавать людям нужный метод -- это вытаскивать их из ситуации. Это и есть та работа, видная публично и оправдывающая то основное дело, которым я занимаюсь. Основные разговоры проходят наполовину в языке клиента, наполовину в перетолковывании этих же высказываний в языке предлагаемого метода, а затем нахождение решения уже во вновь появившемся языке. Как только ты начинаешь говорить "инженерия требований", то при этом подтаскивает тащится довольно большой кусок новой онтологии, в терминах которой можно описать довольно много новых практик, и клиент, работавший раньше в терминах "технических заданий" вдруг осознает, как ему улучшить свою ситуацию, казавшуюся при работе в терминах "технических заданий" неразрешимой. Из практик конструируется новый процесс, жизнь налаживается и можно переходить к освоению следующего метода (рассмотрев точку приложения сил своих и клиента при помощи методов теории ограничений).

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

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

Основное дело консультанта -- это как раз напитываться метаметодами, делать свое собственное консалтерское Lego, или Magnastix, или Geomag, или Smogi или Mega Blocks или Механический конструктор №1. Важно, чтобы в твоих метаметодах, как в конструкторе нашлись все нужные детальки-фрагменты методов, из которых ты быстро соберешь подходящий для ситуации клиента метод решения его проблем. В крайнем случае ты должен быть хотя бы "стихийным методологом", чтобы этот новый метаметод создать по потребности, но лучше бы этого не делать -- лучше не изобретать собственный велосипед, а учиться на чужих ошибках.
Плюс у консультанта должен быть набор специфические для его собственной работы метаметодов: для конструирования соответствующего каждой конкретной консультационной ситуации метода помощи клиенту в освоении им передаваемого целевого содержательного метода.

Основное дело -- это "репетиции", "тренировки", "самообразование", то есть а) накачка себя наиболее употребительным набором "содержательных" метаметодов (ISO 15926, MFESA, TOC и т.д.) и "процессных" метаметодов (с какой стороны подойти с содержательным методом к сотрудника клиента, чтобы они этот метод начали осваивать -- change management, НЛП и много чего другого).

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

Главное в PraxOS -- это разбирательство с предметным и процессным содержанием работы. Так, "метод персонажа", примененный к ситуации "идеального акционера" (подробнее -- http://ailev.livejournal.com/511947.html) может быть еще более обобщен, если понимаешь, что речь идет о метаметоде инженерии требований -- а инженерия требований в общем случае это работа с ролями. "Персонаж" -- это про метод перевода роли заинтересованной стороны в позицию (http://ailev.livejournal.com/760041.html). Как только вы поняли, что речь идет о какой-то заинтересованной стороне и ее требованиях, которая вам непосредственно недоступна -- вы смело можете применять этот метод, даже если речь не идет о разработке коробочного софта или юзабилити.
Как только вы сообразили, что организация -- это система, а акционер -- это заинтересованная сторона, у которой всегда есть требования, то далее не нужно быть восьми пядей во лбу, чтобы на этом уровне общности вспомнить про метод персонажа. Случайные "озарения" становятся рутиной. Главное в методах -- это их масштабируемость, применение одних и тех же мыслительных паттернов на самых разных уровнях детализации в самых разных делах.

Создатели ISO 15288 (как рассказывал нам его архитектор Гарольд Лоусон) чрезвычайно были озабочены именно этой стороной вопроса: масштабируемостью и универсальностью описываемого в нем метаметода системной инженерии. Сохранение этой масштабируемости и есть главная фишка.

Близкий родственник PraxOS в этом плане opfro.org (http://ailev.livejournal.com/674073.html -- где я делаю возмутительную ошибку, спутав ISO 24744 и ISO 24774, что месяцев на пять задержало неминуемую разборку с ситуационной инженерией методов). В OPFRO.org cобрано порядка 1100 фрагментов методов в единой онтологии (и там тоже отражен метаметод инженерии системной архитектуры MFESA). Отличается PraxOS двумя вещами:
а) другим набором "избранных методов" (так, у нас есть Голдратт, а в opfro.org его нет. У нас есть ICM, а в opfro.org его нет. У нас сделан вывод о минимальных четырех описаниях жизненного цикла, а в opfro не сделан. У нас есть методы онтологической интеграции данных, а в opfro.org их нет).
б) использованием немного другого инструментария работы с методами. С одной стороны, oprfo.org тоже движется в русле системной инженерии методов, и даже имеет собственную метамодель. Но наш PraxOS уже сейчас ориентируется на:
-- поддержку полной онтологии ISO 15926 и честную работу с моделью продукта (поддержка продуктной, ценностной группы описаний -- http://ailev.livejournal.com/764492.html).
-- на сегодняшний день работу не в "ручном" режиме, а сразу в SPEM 2.0 (и использование EPFC для этой работы). А в будущем -- выход на собственную метамодель и регистрацию этого стандарта в RDL ISO 15926 (да, я знаю, что там сначала фиксируются определения из оксфордского словаря, затем определения из стандартов ISO, затем только определения из стандартов промышленных ассоциаций, и только в последнюю очередь ориссы. Википедия, она и есть википедия, даже если ее обозвать RDL и дать статус международного стандарта).

Но мало создать такую библиотечку. Нужно еще и уметь применять в ней написанное -- это означает, что мало найти опубликовать в RDL онтологию рабочих продуктов онтологию рабочих продуктов инженерии системной архитектуры (http://ailev.livejournal.com/766364.html). Нужно еще опубликовать эту онтологию у себя в мозгу так, чтобы мозг сумел ей воспользоваться (а потом еще и помог освоить эту онтологию сотрудникам клиента).

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

В) инструментарий для дела -- методология
Для основной деятельности консультанта (разбирательства с лучшими практиками работы) требуется хорошо освоить инструментарий работы с методами, как объектами. Ибо метод представляет из себя довольно сложный объект -- метод состоит из его предмета (онтологии, лексики, нотаций -- http://ailev.livejournal.com/761744.html), плюс практик/содержания методов, плюс процессов/жизненных циклов. Метод сам выражается при помощи метамодели, онтологии, лексики, нотаций выбранной версии метаметода системной инженерии методов. Границы метода как системы чрезвычайно расплывчаты. Заинтересованных в методе сторон довольно много (разработчик метода, применяющий метод, кодировщик описания метода, проверяющий выполнение метода, учитель метода и т.д.), все они предъявляют разные требования и к методу, и к инструментарию с ним работы.

Основным методом системной инженерии является построение моделей методов. То есть нашим инструментом в работе с методами является моделирование методов, их анализ и синтез, препарирование и оживление. Для этих целей нужно иметь набор правильных описаний методов, "вынуть методы из головы" и положить их в компьютер -- даже не для того, чтобы эти методы компьютер мог исполнить сам (хотя сингулярность уже близка, и кто знает, что будет через полтора десятка лет?). Это нужно просто для того, чтобы как самому иметь возможность размышлять о метаметодах, методах и т.д. ("внутри головы думать нельзя" -- http://community.livejournal.com/openmeta/190239.html). Но в неменьшей степени это нужно для того, чтобы обеспечивать совместную работу над этими метаметодами, повышать их качество.

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

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

2. Что делать: план релиза PraxOS 2.2
Нужно выпустить релиза PraxOS 2.2 (предыдущий план релиза 2.1 был в октябре 2008г. -- http://ailev.livejournal.com/627019.html). В этом релизе признается, что общая цель версии 2 -- разбирательство с "процессными фреймворками" -- остается (это мы так год назад нащупывали идею ситуативной инженерии методов), но также фиксируется зацикленность предыдущей версии на методологических занятиях -- хотя это принесло плоды, ответы на многие поставленные вопросы получены (хотя реализации пока не было).

В этой версии цели мы распишем на три группы, соответствующие трем занятиям консультанта:

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

б) пополнение библиотечки метаметодов и их освоение -- профессиональный рост.
-- исследования и формулирование метаметода иженерии требований второго поколения, т.е. развитие идей http://ailev.livejournal.com/754369.html
-- разбирательство с инженерией системной архитектуры, http://ailev.livejournal.com/758212.html
-- Суровый (крутой, недетский) рефакторинг текущих знаний -- с учетом общая рамки ситуационной инженерии методов, онтологии системного подхода, в том числе онтологии дисциплин системной инженерии -- минимально в части наиболее общих артефактов и именований ее дисциплин. По-хорошему, нужно было бы переписать все постинги, переделать все презентации, перечитать все видео, и заменить тексты на сайте PraxOS. Рефакторинг, он и есть рефакторинг: остановка сегодня, чтобы не затормозиться навсегда завтра.
-- документирование результатов рефакторинга. Вряд ли в версии 2.2 это будет документировано в "универсальном моделере", но на его роль временно назначается EPFC. Возможно, нужно вебсайт http://PraxOS.ru из вики-сайта переделать в продуцируемый этим моделером сайт. Все равно вики-сайты не взлетают, если их пополняют менее пяти человек, а в PraxOS пятерых разработчиков все нет и нет (хотя наблюдают за работой довольно много народу -- обычный эффект торрентовых сетей: аплоадят не более 3%, а пользуются потом все).

в) методология -- инструментарий
-- доформулировать подход PraxOS как интеграцию методов в промышленных масштабах (http://ailev.livejournal.com/640702.html)
-- продолжение планирования "универсального моделера" (http://ailev.livejournal.com/757999.html, http://ailev.livejournal.com/758941.html).
-- -- выбор онтологии, лексики и нотации для (минимально) четырех групп описаний процесса/жизненного цикла http://ailev.livejournal.com/764492.html и реализация их в "универсальном моделере".
-- Онтологию и лексику activity model из предыдущего пункта погрузить в ISO 15926 RDL (или хотя бы в WIP).
-- сделать для универсального моделера мэппинг (с использованием ISO 15926-фасада) для workflow распространенных САПРов (а также для их модулей генерации ППР -- "планов производства работ", встроенных хелпов, чтобы включать в этих хелпы методы клиента и прочая интеграция в конкретные САПР).
-- присматривание к интерактивному программированию в плане изменения метаметодов (т.е. отладки как цикла исследования-создания взаимоувязанных онтологии, лексики, нотации и содержания метаметода) без потери целостности порожденного прошлой версией и доработанного при этом "напильником" метода.
-- агентские архитектуры как решение проблемы SOA и "программирования в большом"
-- Cola как language workbench следующего поколения. Можно ли сделать моделер?
-- соответствие SOA-инфраструктуры для поддержки методов и самих методов (за это, вроде, взялся foxtreme).

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