March 31st, 2010

2019

Спиральная динамика и системная инженерия: еще вариант "мыслительных стилей".

Сопоставление между 21 компетенцией системной инженерии согласно подходу INCOSE UK и системой ценностей из Gonçalves and Britz показали высокую корреляцию между 11 компетенциями системной инженерии и ценностями спиральной динамики (http://www.ppi-int.com/newsletter/SyEN-018.php#article):
Компетенция
Коррелирует с 
Технологическая среда и среда предприятияне принимает Бирюзовое (Мы получаем опыт)
Определение требований и управление требованиямиотрицает Зеленую систему ценностей (Мы относимся)
Порождение концепциипринимает Оранжевое (Я делаю), но не Бирюзовое (Мы получаем опыт)
“Проектирование для …”не принимается Красное (Я контролирую), в то же время принимается Бирюзовое
Моделирование и имитационное моделированиене принимается Желтое (Я учусь), Зеленое (Мы относимся) или Бирюзовое (Мы получаем опыт) и не принимается Красное (Я контролирую)
Выбор предпочтительного решенияЖелтый (Я учусь) принимается и не отклоняется
Интеграция и верификацияпринимается Красный
Интеграция предприятияне отвергается Красный (Я контролирую), не принимается Зеленый, не принимается Бирюзовый
Интеграция специализацийОтклонение Бирюзового (Мы получаем опыт)
Определение процесса жизненного циклаПринятие красного (Я контролирую) и отвергается Бирюзовое
Планирование, мониторинг и контрольне отвергается Красное (Я контролирую) и не принимается Бирюзовое

Исследователи отмечают, что для системной инженерии важно "что не отвергается", а не "что принимается".

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

Расшифровка цветов и пояснения к подходу спиральной динамики -- http://www.newcode.ru/doku.php/spiral-dynamics.
Про подход мыслительных стилей: http://praxos.ru/index.php/%D0%9C%D1%8B%D1%81%D0%BB%D0%B8%D1%82%D0%B5%D0%BB%D1%8C%D0%BD%D1%8B%D0%B5_%D1%81%D1%82%D0%B8%D0%BB%D0%B8

2019

Руководство по упреждающим индикаторам системной инженерии

Руководство по упреждающим индикаторам системной инженерии, версия 2.0 -- http://lean.mit.edu/index.php?option=com_docman&task=doc_download&gid=2464&Itemid=776. Упреждающие индикаторы отличаются от традиционных (lagging, спасибо за уточнение) тем, что измеряются тренды, а не абсолютные значения -- что стимулирует использование этих индикаторов для прогноза. Делала команда из INCOSE, MIT (lean advancement initiative)и PSM (practical software and systems measurement, http://www.psmsc.com/, команда стандарта измерений ISO 15939), представители Армии США и т.д.

Примеры показателей:

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

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

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

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

Приведена карта соответствий между практиками (как они тут обозваны -- "process activities") ISO 15288 и данными индикаторами, и куча разной другой информации (всего в этом Руководстве 146 страниц).

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

Международный семинар по формализации языков моделирования

Словения, 21 или 22 июня 2010, International workshop on formalization of modeling languages -- http://www.cis.uab.edu/FML2010/

Темы точно соответствуют тренду сближения ранее разошедшихся линий программирования, имитационного моделирования, концептуального (порождение) моделирования (и онтологизирования, как одного из видов концептуального моделирования). Вот пять проблем формализации языков моделирования, которые планируется обсудить на этом семинаре:
1. изобретение формализма поведенческой семантики, который проще использовать, чем существующие формализмы и поддающегося дальнейшей обработке с целью автоматизированного порождения инструментов моделирования (например, редакторов, отладчиков и имитаторов
2. расширение не только моделей, но и метамоделей, семантикой.
3. автоматическое порождение различных инструментов моделирования, которое требует инструменто-специфичной информации и различных алгоритмов порождения, чтобы эти инструменты сконструировать.
4. отображение (mapping) к существующим низкоуровневым формализмам/инструментам должно быть автоматическим и прозрачным для конечного пользователя языка моделирования.
5. разработка новых инструментов, которые невозможны без формальной семантики (например, проверщик модели, который может верифицировать свойства, специфичные для предметной области).
2019

Моделирование и программирование опять сближаются. Назад в будущее!

Мы немного пообсуждали в Бекасово, что объект-ориентированность была введена давным-давно (еще с SIMULA, 60-е годы 20 века -- http://en.wikipedia.org/wiki/Simula) как способ моделирования и программирования. Беда в том, что с тех пор ООП стало именно ООПрограммированием, но не ООМоделированием или ОООнтологизированием. Про функциональное или логическое моделирование я вообще молчу (хотя OCL к UML это явно шаг в данном направлении, а в самом свежем апрельском 2010 выпуске Communications of ACM сказано "functional logic programming supports specification, prototyping, and application programming within a single language. it is the basis of a practical and convenient approach to produce high-quality software." -- спецификация тут явно должна читаться, как "моделирование").

Традиционно объединенное программирование-моделирование развивается в скандинавских странах, и именно оттуда идут инициативы "назад в будущее" единого программирования-моделирования. Оттуда и SIMULA, и следующий язык этой серии (меньше, но выразительней) BETA (http://www.daimi.au.dk/~beta/, история вопроса с многочисленными рассуждениями о связи программирования и моделирования -- http://www.daimi.au.dk/~olm/index.html/PUB/BETA-HOPL-V4.7_ref.pdf -- читать и перечитывать!). Сейчас тема становится остромодной, попала даже в keynotes конференции по моделированию 2010 -- http://models2010.ifi.uio.no/keynotes.shtml (сама конференция MODELS 2010 будет в Осло, Норвегия 3-6 октября 2010, http://models2010.ifi.uio.no/). На всякий случай, различия ‘Scandinavian School’ and the ‘U.S. School’ of object-orientation именно в различном отношении к моделированию/программированию были введены Steve Cook в 1988г.

К этой же линии рассуждений можно отнести и имитационные программы/модели (Modelica, объект-ориентированный язык имитационного моделирования).

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

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

Так, если делается имитационная модель системы (реактора, турбины, телекоммуникационного оборудования -- например, на Modelica, или даже ModelicaML) -- в какой мере она может рассматриваться как одна из архитектурных (связь функции и конструкции, т.е. репрезентирующей имитационно не только функционирование и его характеристики, но и конструкцию) моделей? В какой мере можно использовать технико-экономическую имитационную модель системы для начальных прикидок конструкции? Как связаны plant breakdown structures (по группам декомпозиции оборудования, по размещению, по функциям) и имитационные модели? Сошелся ли клином свет на объект-ориентированности моделирования, или нужны мультипарадигмальные модели/программы (подсказка: фраза из "истории BETA" -- There were supporters (or followers) of object-orientation who started to claim that the world is object-oriented. This is of course wrong – object orientation is a perspective that one may use when modeling the world. There are many other perspectives that may be used to understand phenomena and concepts of the real world)?

Кстати, я сам время от времени принимаю решения вполне в русле скандинавской традиции: они тоже предпочитают термин description вместо получившего распространение modeling (как они пишут в истории BETA, The term modeling [в программировании] is perhaps somehow misleading since the model eventually becomes the real thing – in contrast to models in science, engineering and architecture. We originally used the term description, in SIMULA and DELTA terminology, but changed to modeling when OOA/OOD and UML became popular).

История моделирования и программирования (как и любая история в языках, судя по всему) -- это история не столько идей (которые производятся одними людьми), сколько история инструментов (которые производятся другими людьми). Так, в ВЦ РГУ (где я работал в 1980-1982г.г.) разрабатывался компилятор SIMULA67 для Эльбруса. А если бы этот компилятор был разработан хотя бы для ЕС ЭВМ, не говоря уже об СМ4 или -- ужас, ужас -- для появившегося в 1980г. Личного Компьютера IBM? А если бы этот компилятор получился хорошим (быстрым, безглючным, хорошо расширяемым, с обширной библиотекой, мощным отладчиком)?! Придумать хороший язык -- упражнение для одного талантливого человека на десяток лет. Сделать для него хорошую исполняющую среду и портировать ее на разные платформы -- кувыркание минимум десятка совершенно других по компетенциям человек на десяток лет. Идеи, конечно, имеют значение. Но хорошие организационные способности часто выигрывают у хороших идей (хотя тут тоже не все так просто, как можно прочесть в этих моих строках).

Нужно отдельно, конечно, помянуть самые разные обсуждения, смешанные в кучу в данном постинге:
-- программирование vs концептуальное моделирование (BETA и UML, BETA и Java)
-- программирование vs имитационное моделирование (Modelica)
-- концептуальное vs имитационное моделирование (ModelicaML -- http://www.openmodelica.org/index.php/developer/tools/134, хотя тут не столько смешение парадигм, сколько попытка выразить Modelica в терминах UML).

Более того, это все пока только объект-ориентировано, а не мультипарадигмально. Итого: обсуждение программирования/моделирования разного рода/онтологизирования пока представляет собой разные и не связанные исследовательские истории, но эти истории уже начинают рефлексивно осмысляться, и мне кажется, что в ближайшее время можно ожидать быстрого развития событий на теоретическом (а по мере развития IDE в сторону language workbenches и на практическом) фронте.

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

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

Гуглеприложения в рознице

Для тех, кто не заметил: Гугль начал приторговывать чужими приложениями -- http://www.google.com/enterprise/marketplace/home

Все продается, ничего святого. Вот, например, продажа чудес (для двух пользователей -- бесплатно) типа "интегрированная система менеджмента для Приложений Гугля", использует испытанные методы крупных консалтинговых компаний типа McKinsey & Co. (стратегия, маркетинг, продажи) или Alvarez & Marsal (переструктурирование, оборот) -- http://www.google.com/enterprise/marketplace/viewListing?productListingId=3692+7717401678176686341. Не верите в чудеса? А ведь там Seamless integration of Market strategy, Open Innovation, Portfolio upgrading, Scorecard, Product Launch, Supply Chaining, Business Process Re-engineering (BPR), Key Account, Customer management, Pricing, Corporate Diagnostic, Business & Competitive Intelligence. Если больше трех пользователей, то всего за $29 на пользователя в месяц.

Понятно, что ничего революционного в этом магазине нет -- эти приложения вполне себе существовали и без Гугля. Но Гугль дает возможность сделать из этих приложений суперприложения, используя для интеграции свои Google Docs, Calendars, Map/Street views и другие незатейливые структуры традиционного офисного документооборота...

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