Category: знаменитости

Category was added automatically. Read all entries about "знаменитости".

2019

Я автор религиозного бестселлера №1

У меня религиозный бестселлер №1 на русском по версии Амазона (https://www.amazon.com/gp/bestsellers/digital-text/9938704011/, 23 февраля 2018):
religion_systems

В анкетке ridero мне из довольно узкого списка было предложено выбрать жанры. Системное мышление попадало хоть как-то только под жанры "Самосовершенствование" и "Философия" (рядом с философией никаких других слов не было!) -- всё остальное было уж совсем мимо. Как я понимаю, потом "философия" неожиданно оказалась "философия и религия" (ещё внутри Ridero), а затем в Амазоне уже "религия и духовность" (https://www.amazon.com/gp/bestsellers/digital-text/9938704011/):
product_details

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

UPDATE: обсуждение в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10212379827624834

На 19:10 я уже в мировом топ 1000 по религии и духовности в Kindle Store:
#1 in Kindle Store > Kindle eBooks > Foreign Languages > Russian > Religion
#864 in Kindle Store > Kindle eBooks > Religion & Spirituality
#2084 in Books > Religion & Spirituality
2019

Мой год кизомбы

Ровно год назад, 10 августа вечером я сходил на пробное занятие кизомбы (http://ailev.livejournal.com/1285622.html -- и к этому посту был единственный комментарий от volk "Считаю, лучше сразу на бачату").

За этот год я прошёл несколько групп для начинающих, несколько средних групп в Spicy Salsa и AfroFusion -- по kizomba fusion, authentic kizomba/semba, urban kiz и даже чуток new urban tarraxo. За год добрался до старших групп. На вечеринках я уже никак не выделяюсь из общей толпы, хотя бываю на вечеринках довольно редко, примерно раз в месяц. Похудел в периметре на 10 сантиметров, немного выпрямился. Некоторое время размышлял о танцевальном мышлении и системном фитнесе. И не только размышлял, но и тренировал тело: в этой специфической сфере размышления ничего не стоят, если за ними нет собственной телесной работы. Даже не буду приводить ссылки, я регулярно писал об этом и большие тексты, и множество мелких заметок в постах lytdybr.

Удачно ли я выбрал кизомбу изо всего множества танцев? Да, удачно. Когда-то Уилбер сказал, что большие религии интересны тем, что предоставляют разные свои версии для самых разных людей: неотёсаным дают сказки и чудеса, а высокообразованным дают утончённые философские идеи и строгую логику. Вот кизомба оказалась примерно такой же: новички на ней не потеют, они сразу могут топтаться на вечеринке, зная три-четыре движения. А дальше -- замечаешь много дверей, и за каждой из них открывается огромный и разный мир. В некоторых из этих миров очень даже потеют, а движений нужно знать сотни и танцевать их с точностью ног меньше сантиметра на довольно больших скоростях. И этих миров добавляется с каждым годом. За год базу не узнаешь, а в кизомбе как зонтичном жанре довольно много разных баз -- и преподавателям обязательно демострировать знание даже афрохауса. Вершины кизомбы простым смертным недоступны: танец кажется очень лёгким, но это совсем не так. И не потому что там заоблачно трудные движения. Нет, каждое отдельное движение там вполне осваиваемо. Трудность там в огромном разнообразии кизомба-мира и в быстрых изменениях. Так, год назад партнёрши в кизомбе практически не крутились. Поворот партнёрши был исключением, а не правилом. А сейчас все крутятся будь здоров. И это буквально за год. Так что в кизомбе нужно бежать со всех ног, чтобы только-только остаться на месте.

Что занимает меня через год занятий, какие планы? Вот краткий списочек по трём уровням, на которые я делю сегодня умение танцевать:

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

2. База: владение танцевальной культурой какого-то направления. Одно из преподавательских пожеланий Алёны Фортуновой ко мне было таким: "в зависимости от музыки ты должен превращаться в другого танцора". Если это магическое "превращаться в другого танцора" расшифровать, то это означает умение легко менять базу. В кизомбе по факту есть четыре существенно разные базы -- authentic, fusion, urban, tarraxo. И бесчисленное число гибридов и вариантов. Если не знаешь базы, то ты не знаешь ничего. При этом "за год базу не узнаешь", а тут этих баз по факту множество. Laurent об этих базах говорил так (цитирую не очень точно, только суть): "ты выходишь на танцпол -- и щёлк, становишься другим человеком, у тебя появляется другая поза, другое настроение, всё другое. Тренируйтесь переключать состояния".

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

4. Методологический уровень: именно на нём обсуждается, как связаны задачи всех предыдущих уровней (фитнеса, базы, танца), на нём достигаешь осознанности в своём развитии. Я бы переписал текст про танцевальное мышление (http://ailev.livejournal.com/1332624.html), развернул его. Но это только после того, как закончу учебник системного мышления.

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

UPDATE: обсуждение в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10210942253286374
2011

Архитектурные требования к мышлению

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

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

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

Осознанность – это возможность понять, как мы мыслим, как мы рассуждаем. Если мы просто «имеем интуицию», это нас не удовлетворит. Мы не сможем научить других мыслить, научить их повторять наши рассуждения. Мы не сможем заметить ошибку в нашем мышлении, не сможем его улучшить или изменить, не сможем выучить другой способ мыслить, ибо мы его не будем замечать, не будем его осознавать. Мы не сможем удерживать внимание в мышлении, ибо нельзя удерживать внимание на том, чего не осознаёшь. Мы не сможем предъявить неосознаваемое нами мышление для проверки со стороны логики и рациональности, не сможем сознательно принять решение о том, что в той или иной ситуации нам достаточно от мышления интуитивной догадки, а не строгого рационального рассуждения. Мы хотим знать, о чём мы размышляем, как мы это делаем, мы хотим иметь возможность выбирать – мыслить нам о чём-то или не мыслить, мы не хотим быть бессознательными мыслящими автоматами. Мы хотим быть осознанными в мышлении, мы должны учитывать не только мышление, но и наличие самого мыслителя". Ещё сюда "«рефлексия» – это осознанность, но только не на текущую ситуацию, а уже прошедшую".

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

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

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

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

UPDATE: дискуссия в фейсбуке https://www.facebook.com/ailevenchuk/posts/10209965413425988 и https://www.facebook.com/groups/771940449578453/permalink/1124132284359266/
2019

Хрестоматия музыкальных жанров

Всю жизнь о таком мечтал: аудиографика http://everynoise.com/engenremap.html -- там если нажимать на название жанра, то звучит пример музыки. А если нажимать на кавычку после названия -- проваливаешься на детальный уровень, где уже множество примеров от конкретных исполнителей (в частности, если речь идёт о музыке какой-то страны, то ничего не звучит как пример "музыки страны", но можно познакомиться с отдельными исполнителями -- жмите на кавычку). Можно кликать и дальше -- там будет ссылка на Spotify.

Вот примерно так и выглядят семантические пространства -- в самом верху deep tech house, в самом низу -- classical piano, в промежутке какой-нибудь deep northern soul.
2019

lytdybr

Отрок третий день безо всякого принуждения всё свободное время смотрит мульт-сериал истории государства российского (в пересчёте на "обычные сериалы" по 20 минут это примерно 100 серий), в основном вокруг Иоанна III. Расспросы показали, что он воспринимает это как пример "стратегии", вполне содержательный для него жанр "прохождения". По мере просмотра он даже высказывал замечания по осмысленности/стратегичности действий тех или иных исторических персонажей. Кстати, версия истории по этим мультикам существенно отличается от версии в школьном учебнике. Учебник не котируется у него ни разу, интереса не вызвает совсем. Ибо непонятно, какого жанра учебник, что с ним делать. А фильм-"стратегия" -- оно понятно, какого жанра, и понятно как использовать. Я не выдержал, и задал вопрос после сегодняшнего просмотра -- "ну, и кто там выиграл?". Отрок отнёсся к вопросу серьёзно, и ответил, что "пока никто, но Россия потом останется, я знаю". А затем им была расчехлена Sid Meyer's Civilization: Beyond Earth.

В MineCraft по вечерам они уже играют по скайпу втроём, с Юлей и Виталиком. А ещё он сегодня ходил на свиданку с Лизой, объяснял ей умножение и деление десятичных дробей (а Лизиной маме демонстрировал решение вступительных задач в 8й класс не очень трудной физматшколы). Социальная жизнь бурлит. С этими свиданками он окончательно убил мой самокат, уж отдам этот самокат насовсем, а себе новый возьму.

Выяснилось, что я не публиковал ещё в ЖЖ ссылки на материал про peer instruction -- http://erazvitie.org/article/pervyj_kavaler_minervy. Там используется и concept inventory -- http://en.wikipedia.org/wiki/Concept_inventory (гнездо там и много-много материалов на тему как учить концептам http://modeling.asu.edu/R%26E/Research.html). Хотя это ещё не венец развития -- Лей Бао сотоварищи показали, что умение рассуждать и тренинг в мышлении на базе какого-то набора концептов это не одно и то же, http://arxiv.org/ftp/arxiv/papers/0807/0807.2061.pdf. Изучение физики оказывается не таким уж "выправляющим мозги" -- A historically held belief among educators and researchers is that training in physics, which has a beautiful structure of logical and mathematical relations, would in general improve students’ abilities in conducting reasoning that is intellectually challenging. However, the result from this study suggests that training in physics content knowledge in the traditional format alone is not enough to improve students’ general reasoning abilities). Ну, и появились материалы, обсуждающие beyond concept inventories towards measuring how students think -- http://www.ncbi.nlm.nih.gov/pmc/articles/PMC2830154/ (concerns about measuring student thinking as opposed to student knowledge, но все эти попытки плохо технологизируются по сравнению с concept inventory). В любом случае, нужно бы по моим учебным курсам делать этот самый concept inventory, в классическом варианте. Я этим эпизодически занимался, но нужно бы потратить достаточно времени и ресурсов.

Долго размышлял над постом http://alarmingdevelopment.org/?p=926 -- там Jonathan Edwards признаёт, что изобрёл решение для проблемы, которую не все даже признают за проблему. Текущее решение это увеличить стек (сделать патч на уже имеющемся стеке программирования), а нормальное решение -- это изменить стек технологий. Понятно, что никто не хочет менять сегодняшний статус кво. И тогда он принимает решение... работать для конечных пользователей и не-программистов, которые ещё не привыкли к текущему технологическому стеку. Вау, какой образ мыслей. Для меня это продолжение темы про "никто не хочет учиться играть на XYZ" (http://ailev.livejournal.com/1158826.html) и "революционную математику Синичи Мочидзуки" (http://ailev.livejournal.com/1176759.html). Такое впечатление, что теория категорий в инженерии сейчас попадает в похожую ситуацию.

Видео моих лекций 2012 года в МФТИ (курс "Основания системной инженерии") в связи с заменой видеплатформы переместили на страницу http://video.techpred.ru/lecturer/LevenchukAI/

16 мая будет празднование 100-летия РГУ, на Поляне перед физфаком. За последние несколько месяцев меня нашло довольно много народу, знакомого по студенческим годам. И весь этот народ, как выясняется, давно уже живёт в Испании, Литве, Германии, Эквадоре, Канаде, Австрии и прочих интересных странах.

Осознал, что не смотрел никаких анимешек больше года (это были Kill la Kill и Golden Time в апреле 2014 года, судя по timeline в anidb.net). Только манга и манхва. Более того, я даже не следил за тем, что происходило весь этот год в мире аниме. Надо бы поинтересоваться, вдруг я пропустил что-то великое.
2019

Видео моего выступления "Система в глазах смотрящего"на TEDxSadovoeRing

Видео моего 18-минутного выступления "Система в глазах смотрящего" 2 июля 2014 на TEDxSadovoeRing (http://www.ted.com/tedx/events/12440, http://tedxsadovoering.com) в музее Скрябина на Арбате (http://youtu.be/mo69z1LyQu4):



Вот тут ещё несколько моих фотографий с того мероприятия, которые собрал для меня Фейсбук (хотя я не понимаю, как из них отобрать только те, что относятся к TEDxSadovoeRing): https://www.facebook.com/ailevenchuk/photos
2019

Second Life и каменистая почва для системной инженерии

Сегодня на мероприятии у клиента увидел в гостевой презентации три своих слайда, которые я делал для предприятий системы Росатома. Один из этих слайдов у меня датирован 8 октября 2007г., другой февралём 2008г, третий маем 2008г. Эти слайды, как я понял, практически без изменений кочевали по презентациям разных организаций с тех давних времён, а рассказывались последние разы вчера в Обнинске и сегодня в Москве. Управление жизненным циклом, системная инженерия. В 2007-2008 году это было про опыт западных товарищей (главным образом Toshiba и Bechtel) и предложения сделать что-то подобное.

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

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

Забавно, что майский 2008 года слайд был сделан на основе снимка экрана из Second Life -- объемная V-диаграмма, стрелочка из цилиндра и конуса, странные цвета виртуальной тогдашней жизни. Сейчас про виртуальные миры все уже забыли, но в те давние поры это был хит сезона, эдакий квазипузырь (инвестиций в эти виртуальные миры было немного, но пресса ими сильно интересовалась). Мы завели остров TechInvestLab в ноябре 2006г. (http://ailev.livejournal.com/432982.html), а атомщикам рассказали про Second Life и виртуальные миры осенью 2007 года на Ростовской АЭС. Но тогда мы ещё не знали слов "системная инженерия". В 2008г. мы уже слова "системная инженерия" знали, и сделали "объемную презентацию" с трёхмерными "слайдами", даже несколько раз её показали разным людям. Часть "трёхмерных слайдов" использовали в обычных слайдах, сделав снимки тамошней "камерой" с удобных ракурсов -- оттуда и появился этот слайд с V-диаграммой (можете найти эти слайды тут: http://www.slideshare.net/ailev/isoiec-152882008-presentation, в те давние времена они даже имели какой-то инженерный шарм, ибо были страшно похожи на картинки, вытаскиваемые из тогдашних 3D САПР -- с такими же странными сочетаниями цветов. То, что на некоторых слайдах были даже видны облака, ибо съемки велись в небесах Второй Жизни, мало кого волновало -- да и вы бы и не догадались, если бы я вам об этом не сказал).

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

Интересно, встречу ли я в чьих-то презентациях через шесть лет те слайды, которые я делаю сейчас? Будут ли цвести у клиентов через шесть лет те идеи, которые я высаживаю у них сегодня? И не рассказывайте мне, что каменистая почва шестилетней давности сегодня уже отлита в граните, оставшись каменистой, но уже не почвой. Я это и сам знаю. Но не опускать же руки?! Можно же на что-то надеяться?! Можно?!
2019

Основа -- сущности и язык для методов программной инженерии (OMG Essence)

Стандарт OMG Essence -- Kernel and Language for Software Engineering Methods (Основа -- сущности и язык для методов программной инженерии) получил 73% голосов на заседании OMG 12 ноября 2012 (эта версия тут: http://semat.org/wp-content/uploads/2012/02/2012-11-01.pdf), ему не хватило всего 2% для его немедленного утверждения. Следующая попытка -- в феврале 2013года. Это разработка главным образом SEMAT (http://semat.org/), хотя там уже есть поддержка и множества других организаций. Я отслеживаю эту инициативу с 2010г. (http://blogs.yandex.ru/search.xml?text=semat+%3C%3C+author%3D%22ailev%22), а теперь пришла пора рассказать о ней подробнее -- но не слишком подробно, ибо только в тексте стандарта 283 страницы по состоянию на 12 ноября 2012.

Книжка по применениям стандарта выйдет 28 января 2013, предзаказы уже принимаются: http://www.amazon.com/The-Essence-Software-Engineering-Applying/dp/0321885953/

Основная маркетинговая презентация -- http://semat.org/wp-content/uploads/2012/12/SEMAT-Introduction.pdf Я не рекомендую туда смотреть, просто знайте, что именно эта презентация сейчас выдаётся за суть происходящего. Нет, происходящее в разы интересней этой презентации. Увы, в этих слайдах ничего существенного, сплошной невнятный разговор про "великое начало великого дела", уймы подписантов и прочих сторонников, но ничего по сути дела SEMAT. Эта суть дела доступна в других местах, прежде всего в самом тексте стандарта, а также в многочисленных других презентациях, ссылки на которые я дам ниже.

Уже сейчас доступен моделер для разработки и расширения сущностей и основанных на них практик -- http://www.ivarjacobson.com/Practice_Workbench_Download/ (и там нужно следовать по пути SEMAT USERS). Качайте, устанавливайте, дерзайте описать что-то своё.

Есть уже много адептов -- вот, например, попытка сделать общий метод на основе Essence, VDML, CMMNб SoaML и ряда других стандартов: http://neffics.eu/ (увы, там отнюдь не все deliverables доступны. Ну, и уровень интеграции этих стандартов и инструментов пока оставляет желать. Но сам заход любопытен). Уже на основе Essence ведутся курсы по software engineering (не путаем с computer science!) в ряде ведущих университетов -- от Китая до Норвегии.

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

Критика у Основ тоже есть, и моя, и чужая, но ней позже.

Сразу оговорюсь, что предложения по русскоязычному переводу в этом посте самые начальные, и я буду время от времени возвращаться, и править тут "по живому". Переводом на русский язык стандарта в целом занимается сейчас abayda, его имя также дважды попало в стандарт (он член подгруппы по разработке cущностей/kernel). Вообще, в России потихоньку создается Русское отделение SEMAT (http://metacode-ru.livejournal.com/6830.html), так что перспективы стандарта на применение в русскоговорящих странах вполне есть.

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

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

Увы, эта "простота" временами чрезмерна. Так, вместо того, чтобы сказать "онтология" или хотя бы "мета-модель", говорится о common ground. В плане понятности этот хрен редьки не слаще: даже если сопровождать это слайдом, где все программные инженеры стоят на одной кочке в болоте вместо того, чтобы стоять на разных кочках, понимания это не добавляет. Мне лично очень трудно продираться сквозь любымые Ivar Jacobson (предводитель команды разработчиков) маркетинговые blah-blah-blah про "поиск оснований", "универсальность", "важность того, что это будут использовать много разных людей" и т.д.. Ибо если вместо слова "онтология" приводить красочные метафорические описания, становится не столько понятней (ибо нет непонятных слов, ура!), сколько туманней (ибо вообще не остаётся никаких слов, за которыми стоят хоть сколько-нибудь устойчивые значения, которые можно подсмотреть в словаре).

Язык (language) Основ -- это минимальный набор понятий, в терминах которых описываются методы программной инженерии. Особое внимание тут уделялось минимальности языка. Конечно, язык не ограничен именно программной инженерией, но особо оговорено, что никаких пока приложений к другим областям (domains -- системной инженерии, адаптивному управлению кейсами и т.д.) не было.

"Описывать в терминах" -- это означает использовать мета-язык. Основы вводят четыре уровня этих "мета" (традиционных для MDA, но и очень похожих на уровни ISO 15926) для описания
3 -- meta-language: MOF (мета-класс, отношение и т.д.)
2 -- мета-модель/язык: Construct (понятия языка Основ -- alpha/альфа, activity/дело)
1 -- ситуационный метод/сущности: Types (конкретные ядра и практики -- "требования", "прописать сценарии использования").
0 -- жизнь: Occurence (экземпляры времени выполнения, объекты в реальной жизни)

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

В этих терминах-конструктах описываются абстрактные сущности (kernel) для программной инженерии, имеющие определяемые Языком типы. Эти сущности разбиты на три области интересов (area of concern):
-- клиент (Customer. Альфы: возможности и заинтересованные стороны. Деятельности: исследовать возможности, понять нужды заинтересованных сторон, обеспечить удовлетворение заинтересованных сторон, использовать систему. Компетенции: представление заинтересованной стороны).
-- решение (Solution. Альфы: требования и программная система. Деятельности: понять требования, смоделировать/shape систему, изготовить систему, тестировать систему, развернуть/deploy систему, управлять/operate системой. Компетенции: анализ, разработка, тестирование).
-- предпринятие (Endeavor. Альфы: работа, команда, способ работы. Деятельности: приготовиться к выполнению работы, координировать дела, поддерживать команду, отслеживать прогресс, остановить работу. Компетенции: лидерство, менеджмент).

Для каждого типа альф вводятся её состояния (для "требований": 1. замыслены/concieved, 2. ограничены/bounded, 3. .... 6. Удовлетворены/fulfilled), а для состояний приводится чеклист (для "требования -- замыслены": начальный состав заинтересованных сторон согласился, что систему нужно создавать; заинтересованные стороны, которые будут использовать систему, выявлены; заинтересованные стороны, которые будут финансировать начальную работу над новой системой, выявлены; есть ясно понимаемая возможность, которую адресует новая система). Да, это те самые чеклисты, которые я недавно так хвалил в http://ailev.livejournal.com/1029295.html -- и одно только это залог успешности стандарта.

Конечно, понятие Alpha (Abstract-Level Progress Health Attribute) является ключевым для стандарта, оно определяется как существенный (essential) элемент софтверноинженерного проекта, за которым нужно следить при оценке его продвижения (progress) и "здоровья". Как я понимаю, авторы стандарта хотели, чтобы это слово было необычным -- поэтому я бы его в переводе не трогал. Моя гипотеза -- это ведь case из adaptive case management (поглядите пример из http://ailev.livejournal.com/946134.html, разве приведённые там кейсы не соответствуют альфам из Основ?).

Очень поучительно поглядеть историю появления этих сущностей в том виде, в котором они присутствуют в стандарте: http://semat.org/wp-content/uploads/2012/12/Universals_Track_Intro_Stockholm.pdf (там сущности называются ещё не kernel, а universals).

Эти сущности уже позволяют делать ого-го сколько, даже без их конкретизации в конкретные практики и уточнения до метода. Дело в том, что стандарт вводит кроме графического и текстового языков для описания практик ещё и представление на карточках -- когда для каждого состояния альфы делается отдельная карточка с представлением чеклиста (англоязычные карточки, готовые к распечатке, можно взять тут: http://www.ivarjacobson.com/uploadedFiles/Content/Landing_Pages/SEMAT%20SW%20Eng%20Kernel%20Cards%20A8.pdf), а потом для каждой альфы выкладывается ряд этих карточек с группировкой состояний по разным принципам (см. картинки, как это делается в конце презентации по истории появления сущностей, ссылка в предыдущем абзаце):
-- уже достигнутые, в работе, ещё не достигнутые (оценка состояния дел в проекте). Попробуйте оценить состояние проекта в онлайн-инструменте SEMAT Accelerator -- http://sematacc.meteor.com/ (требует бесплатной регистрации).
-- те, которые будем достигать мы, и которые были достигнуты или будут достигнуты другими (жизненный цикл нашего проекта в общем жизненном цикле)
-- те, которые будут достигнуты на каждой стадии жизненного цикла (так определяется вид жизненного цикла -- см. также рис.160 в тексте самого стандарта)
-- те, которые будут достигнуты на текущем шаге/итерации/спринте (планирование шага работы).

Вот картинка для соблазнения таки пройти по ссылкам:

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

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

Работы (works) ведутся в соответствии с Практиками (архитектурное проектирование, моделирование, использование процессного подхода, непрерывная интеграция, использование use cases, user stories, и т.д. -- вот тут есть примеры, которые не совсем compliant стандарту, тем не менее позволяют судить о чём идёт речь: http://www.ivarjacobson.com/Practices/) которые добавляют к абстрактным сущностям более конкретные:
-- рабочие продукты (work products), состояние которых позволяет судить об абстрактных состояниях альф. Сами рабочие продукты имеют не состояния, но уровни детальности.
-- дел (activity), которые выполняются в деятельностях, изменяют рабочие продукты в части поднятия их уровня детальности, и тем самым продвигают состояние альф. Дела делаются по порядку (между делами есть связь "следует за" -- то есть это такой способ описания процессов).

Пример построения практики Scrum -- http://task3.cc/wp-content/uploads/2012/11/Essence_Kernel_and_Scrum-from-ICSE_Semat_Presentation.pdf

Дальше всё так же, как в любом другом изводе ситуационной инженерии методов. Разных практик много (в SEMAT идентифицировали примерно 250 для программной инженерии), из них составляются библиотеки (library). Впрочем, библиотеки составляются для коллекции чего угодно в той или иной дисциплине или области знаний -- сущностей (kernel), практик. Как всегда, есть общий огромный мешок самых разных компонент методов и связок из этих компонент -- практик. В 2006 году я примерно про то же самое писал для ОпенМеты в терминах репозитория и дистрибутива: http://openmeta.livejournal.com/191373.html -- можно возвращаться к вопросу, и разрабатывать ядро и практики ОпенМеты, используя Язык Основ).

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

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

Критики для всего этого хватает. Вот, например, свеженький пример: http://www.slideshare.net/dJdU/in-search-of-the-higgs-or-whats-wrong-with-semat (это Rich Hillard хочет сделать concerns, как первоклассные понятия в SEMAT -- желающих расширить Язык и Сущности ведь хоть отбавляй), а вот предложение сурово пересмотреть в сторону добавки domain engineering как одной из главных частей программной инженерии -- http://www2.imm.dtu.dk/~dibj/semat-s.pdf. Продолжаются и работы по попыткам подвести хоть какую-то теоретическую базу: найти тот малый набор объектов, который позволит строить теории (типа "физического тела", "математической точки", "химической связи" -- то, из чего потом можно вытащить целую связку теорий для построения большой дисциплины. Ведь нет собственных "идеальных объектов" -- нет и собственной дисциплины) -- вот, например, Proceedings of The Semat Workshop on a General Theory of Software Engineering: http://semat.org/wp-content/uploads/2012/10/GTSE_2012_Proceedings.pdf

Вот моя начальная критика:
-- если соотносить стандарт с поколениями проектного управления, то это второе поколение, соответствующее PMBoK и PRINCE2 -- упор на отдельные проекты. Третье поколение (P2M, TOC) объявило, что не бывает управления проектами в отрыве от управления программами (TOC говорит более жёстко: управлять проектами можно только в том смысле, что перебрасывать ресурсы с одних проектов на другие в рамках программы). Обсуждаемые Основы, конечно, делают упор на один проект. Команда собралась, сделала систему, проэксплуатировала её, распалась. Не так явно, как я тут об этом пишу, но никаких акцентов на предпринятие, делающее разные системы для разных заинтересованных сторон, нет.
-- опущены инструменты, разве что методы работы предусматривают какие-то tools giude. Я бы их ожидал как специализации Команды (то бишь Person и Tool специализации Actor), это радикальное решение, но стандарт вообще избегает на эту тему каких-то предложений. Но, может, это "ресурсы"? Ибо ресурсы вполне соответствуют и инструментам тоже, они используются "непосредственно из уровня описания практик на уровне жизни". Видно, что тут пока "не договорились". В любом случае, без инструментов практики -- это не практики.
-- плотная привязка к MOF (хоть от UML удалось убежать, о чём было прямо заявлено, но MOF -- это текущее требование OMG). Это сразу даёт кривизну в определении мета-уровней и классификаций. Ибо MOF -- это объект-атрибутный язык, а не факт-ориентированный. И это не онтологический язык, а язык MDA-моделирования, со всеми вытекающими.

Ладно, хватит на первый раз...
2019

Онтологическая инженерия в помощь системной инженерии

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

2. Онтологическая инженерия помогает создавать формальные языки описания инженерного метода, и тем самым формализует порождение инженерного процесса. Это позволяет говорить не только о generative design, но и generative manufacturing.

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

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

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

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

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

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

9. Сама системная инженерия как метод представляет собой что-то невнятное: то есть речь не идёт о том, чтобы адекватно выразить основные ее понятия (они, скорее, сводятся к понятиям системного подхода -- и тут всё ОК), сколько выразить то общее, что есть в практиках различных системных инженеров. И тут выясняется, что нет никакого согласованного сообществом системных инженеров мнения о том, что является такими практиками -- дальними подступами тут является стандарт ISO 15288, но с уходом от документ-ориентированной системной инженерии он стремительно теряет адекватность. Более того, опыт системной инженерии Boeing и NASA (классика жанра) широко известен, но больше хотелось бы услышать об опыте системной инженерии в проектах частного космоса, производителей смартфонов, работах по возведению промышленных зданий Broad Group: именно эти проекты указывают на уникальный опыт, и именно используемые в этих проектах онтики (или, если свезёт их обнаружить, онтологии) хорошо было бы использовать для создания контринтуитивной онтологии системной инженерии, и именно эту онтологию нужно было бы закреплять в схемах данных современных PLM.

Если подытожить, то можно себе представить Systems Engineering Service Smart Bus (можно назвать это также Единым Информационным Пространством инжениринговой фирмы, или PLM нового поколения), которая как фикус в кадке сидит в горшке с наличным инженерным знанием (справочными данными -- регулированием, каталогами оборудования, стандартами и нормативами), а кроной-листочками взаимодействует с самыми разными агентами-авторами (которые даны в виде интерфейсов авторских систем). Эта Systems Engineering Service Smart Bus способна выполнять интеллектуальные запросы с их маршрутизацией или к наличным знаниям, или к отдельным авторам, а также способна интеграцию данных и интеграцию workflow крупного инженерного проекта. Это абсолютно системноинженерная система, ибо вся специальная инженерия уходит в авторские системы, а системноинжерное мультидисциплинарное онтологическое (в отличие от опирающихся на онтики специальных авторских систем) ядро "держит целое".

И любые крохотные шажочки в выполнении описанной в данном постинге исследовательской программы в области онтологической инженерии приведут к драматическим улучшениям в возможностях и принципиальной реализуемости этой Systems Engineering Service Smart Bus.
2019

Бесфокусная камера -- пока не более, чем игрушка. Но только пока.

Примеры съемок камерой LYTRO с "послесъемочным фокусом" -- http://oh-so-coco.tumblr.com/tagged/Lytro (много разных фоток, на которых можно кликать по местам, в которых мы хотим получить фокус -- но это, конечно, веб-трюки).

Хех, пока игрушка. Профессиональный народ недоумевает (http://dpreview.com/news/1107/11072515lytrofashionshoot.asp). Дискуссия напоминает старинные дебаты "плёнка против цифры" во времена первых дорогущих цифровых камер с разрешением те самые 0.25Мпикселей. История повторяется, но уже по поводу перевода не матрицы, а оптики. Ибо эта технология хороша не своим переменным фокусом, а отсутствием движущихся деталей. Этим и победят.