February 22nd, 2010

2019

Об SEMAT vision

Недавно было опубликовано вИдение SEMAT (так и хочется написать видЕние SEMAT -- это может быть ближе к истине)"Software Engineering Method and Theory -- A Vision Statement", скромно подписанное "By Ivar, Bertran and Richard" -- http://www.semat.org/pub/Main/WebHome/SEMAT-vision.pdf

Сразу видно, что эти знаменитые Ивар, Бертран и Ричард пытаются повторить свой успех с UML -- и точно так же с самого начала протаскивают в основу одну из идеологий, закрывая двери для других. В текущей версии протаскивается SPEM. Я делаю этот вывод из того, что в явном виде различаются practices и patterns (а в SPEM это methodContent и practices -- но они же не за слова цепляются).

Вот краткая выдержка:



Универсалии -- это то, что встречается в каждом проекте. В кандидатурах Working Program (работающий код), Project, Team, User Experience, System, Quality, Intent, Requirements.

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

The following rules apply to practices:
• A practice is a separate concern of a method. Examples are “development from requirements to test”, “iterative development”, “component-based development”.
• Every practice shall be described on its own, separately from any other practice.
• Every practice, unless explicitly defined as a continuous activity, has a clear beginning and an end.
• Every practice brings defined value to its stakeholders.
• Every practice must be assessable; its description must include criteria for its assessment.
• Whenever applicable, the assessment criteria must include quantitative elements; correspondingly, the description must include suitable metrics.
• Composition mechanisms for practices include merging and extension.

The following rules apply to patterns:
• Every pattern (per the definition in section 3) shall be applicable to several
different practices.
• Every pattern shall be described on its own, separately from any other pattern
and any practice to which it applies.

В разделе про оценку вдруг протаскивается tasks: "The tasks that will be subject to assessment include all important tasks of software engineering: both technical tasks (from analysis to design, implementation, documentation, verification and validation, deployment, operation, and others) and human-centered tasks such as management, training, support and communication".

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

Такое ощущение, что SEMAT хочет сделать SPEM 3, сохранив все его концептуальные недостатки (пробовали на своей шкуре, знаем), но дополнив:
-- формальной теоретической моделью (это, кстати, очень сильное требование: не оставлять формализм на потом)
-- средствами оценки (как ISO 15504 для ISO 15288 -- способ оценки вшит в стандарт, а стандарт "подогнан" под оценку)
-- хотя бы одним конкретным синтаксисом
-- консенсусом среди широкого круга разработчиков метамоделей ситуационной инженерии методов, которых "уболтают" на этот консенсус специальной оргработой и публичной дискуссией так же, как уболтали пятнадцать лет назад с UML

В любом случае, за этой инициативой нужно внимательно следить. Но почему-то после этого "видЕния Ивара, Бертрана и Ричарда" мне не кажется, что в эту инициативу нужно лезть внутрь.
2019

Готовьтесь снимать обувь и ремень перед входом в поезд

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

Думаю, сейчас начнется террористическая истерия на поездах: http://top.rbc.ru/incidents/22/02/2010/373660.shtml

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

Хотел бы я быть тут неправым...
2019

Топливные элементы: уже близко

Похоже, что большие надежды на топливные элементы начинают оправдываться -- http://www.engadget.com/2010/02/22/the-bloom-box-a-power-plant-for-the-home-video/ (и там смотреть видео).

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

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

Энергетика -- это сыр.
2019

Об СМД-методологию

Планирую завтра сходить на Щедровицкие чтения (тезисы докладов уже выложены тут: http://www.fondgp.ru/projects/chteniya/abstracts). Читаю эти тезисы, и печалюсь: до сих пор ракоходное пережевывание исторического наследия ММК. Когда ММК было 5 лет, было мало что пережевывать, и поэтому был шанс делать какие-то шаги вперед. Когда ММК стало 50 лет, то пережевывать есть ого-го сколько, и поэтому шаги вперед будут либо незаметны на этом фоне, либо их просто нельзя будет сделать.

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

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

А где сейчас настоящий рок-н-ролл? Где в России по-настоящему безумные идеи завтрашнего дня? Поглядите, например, материалы на http://www.university.kiev.ua/biblio/. Если откинуть идеи социального устройства (которые и у СМД-методологов тоже не блещут), а поглядеть на суть предлагаемого подхода "творения новых форм" через изменение режима работы мозга и создание адекватных естественно-искусственных языков, обслуживающих эту работу (читать нужно первую пару книг О.Бахтиярова по приведенной ссылке), то это и есть рок-н-ролл, который еще жив. Еще одно место -- перекодирование китайских двигательных практик европейским языком http://www.dongyue.ru/Library/Lmain.html. Это все не про "психологию". Это все про мышление, про коммуникацию, про языки, про деятельность. Именно из этих странных и очень мутных мест могут вырасти те новые мыслительные и коммуникационные практики, для которых будут совершенно недостаточны сегодняшние выразительные средства. Оба указанных мной места -- это проекты по моделированию деятельности, оба проекта связаны с обучением (что обязательно должно присутствовать в любых проектах по моделированию -- иначе как понять, что отмоделировали правильно?), оба проекта выходят за рамки того, что традиционно было в центре западной цивилизации (формально-логическое мышление) и потому хорошо описывается сегодняшними формальными языками. Вот это и есть рок-н-ролл, если хочется абсолютной философской новизны. Хотя это все примеры для моделирования "человека-одиночки", а не примеры моделирования коллективной работы. В стране коллективизма, как водится, отдельные кадры решают все, а не спаянные коллективы...

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

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

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

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

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

Вот конкретные примеры:
-- стандартизация онтологий (ISO 15926, ISO 18629, SUMO, CYC и т.д.)
-- терминология (SBVR, SKOS и прочие из http://metadata-standards.org)
-- стандартизация ситуационной инженерии методов (OMG SPEM, ISO 24744, OPFRO, из свежих инициатив SEMAT, и много-много других менее мелких, но не менее интересных)
-- стандартизация процессов (битва за объединение множества стандартов в OMG BPMN 2)
-- и так далее по всему списку тем, о которых я давно тут пишу.

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

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

Disclaimer. Конечно, я понимаю, что приведенные мной представления с "циклом стандартизации" соответствуют понятию практики из схемы акта деятельности (см. доклад Дубровского на нынешних Чтениях): противопоставление практики и методологии. Но я обращу особое внимание, что в том же DEMO и BPMN 2 рассматриваются протоколы, а это уже из совсем другой методологической схемы. Вполне можно уживаться с разными группами описаний, нужными для разных целей. Скажите, для чего вы хотите использовать этот мой текст -- и я разверну его по-другому (если, конечно, сочту это использование интересным).
2019

OIМ для моделеориентированной инженерии требований. Группы описания требований как product model.

Когда мы рассматриваем такой сложный продукт работы, как "требования", разным людям для работы с ним требуются разные группы описаний. Это означает, что информационная модель требований для работы с собой будет требовать разных языков представления, разного программного и методического. В частности, нужна классификация не только самих требований (функциональные, нефункциональные и т.д. -- см., например, http://ailev.livejournal.com/769827.html), но и групп описаний и адресуемых ими интересов.

Для требований в целом необходимо построить OIM (object information model -- из ISO 15926, метамодель -- из OMG, абстрактный синтаксис -- в language workbenches, "рабочую онтологию" -- из СМД-методологии), которая будет выражаться в разного сорта диаграммах (не обсуждается в ISO 15926, диаграммы -- в OMG, конкретный синтаксис -- в language workbenches, схемы в СМД-методологии), адресующих разные группы описаний. Эту метамодель нужно будет затем выразить в терминах объемлющей онтологии (онтологии интеграции данных) -- в нашем случае в ISO 15926.

Для этой работы выражения OIM требований в ISO 15926 нужно будет разобраться со специфически онтологическими вопросами: где мы говорим о создании экземпляра модели требований, согласно метамодели, а где речь идет только об уточнении требований, а где сами проектные решения или даже реализованная (т.е. реальная) по этим проектным решениям система (для случая системной инженерии требований эта работа выполняется прямо сейчас на базе находок стандарта ISO 24744 в проекте PraxOS -- http://praxos.livejournal.com/. Скорее всего, для требований придется делать аналогичный проект -- и решать абсолютно аналогичные задачи (ибо для требований, как и для методов могут быть использованы совершенно разные специфические предметные онтологии, зависящие от конкретной ситуации, к которой прилагаются "типовые" решения. Требования также могут быть повторноиспользуемыми и "типовыми", и т.д.).

Тут еще нужно подумать, как OIM собственно требований (в инженерии требований это OIM для product model) связано с OIM инженерии требований в целом как метода (где product model является только частью общей модели, а кроме того как минимум есть process model, project model, organizational model инженерии требований).

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

По итогам моделирования, конечно, нужно будет переопределено и уточнено содержание дисциплины "инженерия требований" (предыдущий немоделеориентированный вариант был собран тут: http://ailev.livejournal.com/769827.html) -- для современного варианта моделе-ориентированной инженерии требований (http://ailev.livejournal.com/801113.html, причем с учетом переинтерпретации из предыдущего абзаца. То есть работа будет весьма итеративной).

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