November 17th, 2009

2019

Волновая игрушка

Google Wave -- мощнейшая игрушка, с которой никто не знает, что делать. Кто туда хотел попасть, уже все попали (сразу оговорюсь, возможности давать инвайты у меня нет, когда появится такая возможность -- не знаю). Теперь эти все приличные люди добавляют меня (там я получаюсь даже более торжественный: не ailev, как тут, а полностью -- ailevenchuk) в разные волны с общим содержанием "и что с этими волнами делать кроме совместной работы по редактированию текста"?! И все внимательно смотрят: кто что придумает, кто вложится в программирование, кто вложится в контент, и что вообще там можно. А можно ой-ой-ой сколько, если не жалко времени. Интернет начала времен, огромные перспективы. Платформа, каких поискать. Интернет нового поколения, как когда-то стал WWW внутри интернета. Мегааськовый мультитредовый форум с посылкой писем. Карму скоро прикрутят.

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

Наблюдать за волнами можно вот таким плагином: https://addons.mozilla.org/en-US/firefox/addon/14973 (для FireFox).

Для себя я решил, что Wave у меня в голове пока имеет такой же статус "платформы" и "места", как ЖЖ, а дальше поглядим, что будет. Вот Second Life таким "местом" не стала, хотя надежды и были велики. FrendFeed сразу было понятно, что коротковат форматом.

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

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

Трехосевой гироскоп на MEMS

Дешевые MEMS (microelectromechanical systems) есть в каждом сматрфоне -- это датчики движения, акселерометры. Теперь к трехосевым микроакселерометрам прибавились трехосевые микрогироскопы: движение какой-нибудь железки с ними может быть отслежено не только с точки зрения направления движения, но и с точки зрения вращений. Высококачественный гироскоп за $3.6 за штучку в партии от тысячи штук -- http://www.st.com/stonline/stappl/cms/press/news/year2009/p2440.htm (полная спецификация http://www.st.com/stonline/products/literature/ds/16747.pdf, внушаить).

В сочетании трехосевым акселерометром этот трехосевой гироскоп позволяет полностью измерять движение.

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

Стек технологий ISO 15926

Важно понимать, что одного человека/фирмы, обеспечивающего все необходимые компетенции, нет -- и тем не менее весь этот стек целостен.

1. Системные инженеры-исследователи (academic level systems engineers, как их ласково называют на Западе), обеспечивающие протошаблоны ISO 15926-7 -- строятся поверх начального набора из 201 концепта и их ожидается около 300 штук. Именно эти люди обсуждают выражение модели данных ISO 15926 в языках EXPRESS, UML, OWL, RDF, таблицах (как в Gellish) и эквивалентность этих выражений. Именно эти люди обеспечивают строгие формализмы (типа логики первого порядка).

2. Поставщики системного софта, которые "упаковывают" работу инженеров-исследователей в форму, готовую для организации отображения данных. Думайте о софте типа iRing с разными модификациями, облегчающими интеграцию в разный прикладной софт. Этот софт сразу работает в терминах 300 протошаблонов, и для работы с ним не нужно "вышивать" в терминах исходных 201 концепта. Этот софт с самого начала все понимает про RDL, про фасады -- только он ничего не знает про предметную область, с которой нужно работать. Это системный софт.

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

4. Поставщики готового софта, использующие уже готовые справочные данные для их предметных областей, и разрабатывающие интерактивные (хорошая была опечатка по Фрейду: интеграктивные) среды для разных предметных областей -- думайте о поставщиках современных САПР, EPR и EAM suits и т.д.. Внешний интерфейс этих систем как раз и будет фасадом ISO 15926, семантическими веб-сервисами. Эти программисты оживят модели данных, которые сделаны промышленными метафизиками.

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

Все, что нужно сделать, это
-- понять, что это неизбежно и мейнстрим
-- самоопределиться, в каком месте стека тебе работать
-- начинать работать в соответствии с этим самоопределением

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

Стек методов системной инженерии

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

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

Можно использовать двух, трех или даже трехуровнево (описано в приложении A из ISO 19760), причем варьируя набор уточняющих стандартов для каждой стадии жизненного цикла:
-- на первом уровне сам ISO 15288
-- на втором уровне детали уровня мероприятий ISO 15288 из какого-то другого, более подробного стандарта
-- на третьем уровне детали уровня дел из какого-то еще более подробного стандарта.

Я предлагаю использовать ISO 15288 в рамках ситуационной инженерии методов:

I. Общеметодический уровень: для всех систем и всех стадий жизненного цикла

1. ISO 15288, как набор практик (чтобы не забыть о том, каков более-менее полный набор практик системной инженерии, и чтобы получить основу для совмещения между собой всех остальных практик, а также задать общий язык).
2. общеметодические стандарты, раскрывающие выполнение отдельных практик. Например, MFESA для архитектурного проектирования. ICM для описания жизненного цикла. P2M для проектного управления. Моделеориентированная инженерия требований (model-driven requirements engineering), которая второго поколения, а не первого.

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

Тут еще вполне применим термин "практика", или "дисциплина" как тематический набор практик (дисциплина инженерии требований, практика архитектурного проектирования и т.д.). MFESA явно говорит о best practices в своем составе.

Это как раз уровень, на котором хотелось бы удержать PraxOS.

II. Ситуационный уровень: для отдельных типов систем и отдельных стадий жизненного цикла
-- учет природы целевой системы (так, для разработки архитектуры организации, железки и софта нужны разные архитектурные методы, хотя в любом случае это архитектурные методы, а не методы инженерии требований или методы проектной работы -- предметная специфичность удерживается)
-- учет стадии жизненного цикла (так, архитектурная работа на стадии разработки и архитектурная работа на стадии техобслуживания и ремонтов требует использования разных методов, постановки совершенно разных целей)
-- привязка к конкретным приемам работы и связанной с ними инструментальной инфраструктуре (методы и инструменты неразделимы). Например, уточнить требования MFESA для DSM -- design structure matrix, чтобы поднять модульность. И обязательно привязаться к инструменту (как выполнять DSM с использованием имеющегося софта).

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

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

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

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

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

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

Про всего два уровня абстракции я, конечно, сверхобобщил. Все много, много хуже.

Пока же ситуация такова, что даже при двухуровневой структуре я забежал далеко-далеко вперед: если вокруг только те, кто не в состоянии поддержать разговор о методе, то ситуативную инженерию методов применять еще слишком рано: "Какое такое архитектурное проектирование, которое мы тут должны адаптировать к ситуации нашей целевой системы, этапа жизненного цикла проекта и наличествующих инструментов?! Вы о чем? Садитесь, и проектируйте -- если не понимаете, как, поглядите в ГОСТЫ 1953 года издания, или посмотрите, как работают наши пенсионеры"...

Как это все отмоделировать хотя бы в том же EPF Composer, это отдельная задача: для ситуативного моделирования методов это хороший инструмент, но для общеметодической работы не слишком. Впрочем, тут и специальные LMS тоже могут оказаться бесполезными -- но мне они с инструментарием ситуативной инженерии методов представляются родственниками. В частности, в LMS популярна метафора музыкального сервиса -- альбомы, жанры, треки, плей-листы. Это очень напоминает то, что делает EPF Composer: у вас есть 1100 исходных треков (это не с потолка, это число фрагментов методов в репозитории методов http://ofpro.org), вам нужно сделать плейлист этих методов для вашего проекта, причем как диджею (синхронизируя треки друг с другом, сочиняя и тут же записывая собственные треки прямо в плейлист, подпевая солистам и непрерывно меняя плейлист для учета настроения тех, кто потом будет его играть-слушать).