Category: мода

Category was added automatically. Read all entries about "мода".

2019

"Рассказать про данные"

Время от времени (последний раз -- буквально вчера) меня просят где-то публично "рассказать про данные", ибо "больно уж тема на слуху". Что, что мне рассказывать?! Для меня "про данные" -- это:
-- маркетинговый трёп про «дайте нам ваши данные, мы дадим вам бизнес-советы» (это собирается под словом-зонтиком BigData). В узком смысле тут можно дойти до конкретных алгоритмов shallow learning (а вот deep learning "про данные" специально не жужжит, хотя нельзя сказать, что данные там не поминаются. Поминаются, но «не на слуху», на уровень обывателей не выходит). Ещё тут можно говорить про DataFrames, но это уж совсем узко.
-- интеграция данных в промышленных масштабах (мастер-данные, стандарты качества данных, нормативно-справочная информация, управление инженерной документацией, управление конфигурацией и т.д.). Я много лет об этом писал, повторяться не буду -- все эти PLM и ISO 15926. Боком тут -- что происходит с базами данных: все эти NoSQL, трипл-сторы и прочие нереляционности.
-- иногда под "данными" понимают разнообразную визуализацию данных -- научную или даже "инфографику". Так сказать, современная каллиграфия: если есть, что сказать (данные), то нужно сказать максимально кратко, доходчиво, выразительно.
-- отсутствие «данных» в учебных курсах, алгоритмика там есть, а вот работы с данными нет. По этой линии легко прийти к онтологиям (ибо computational ontology -- это про модели данных). Тренд на работу со всё более и более содержательно кучерявыми данными всё более и более простыми алгоритмами.
-- социальные сети, как "общая помойка всего", и способы разгребания мировой помойки. Персональные данные и прайвеси, цифровые следы и скоринговые агентства. Раскрытие информации государства.
-- … и так далее.

А вот про алгоритмы никто не просит рассказать. Они уже вышли из моды, или ещё в моду не вошли? Слово-то "данные" тоже давно используется, но никогда оно не было модным, не просили рассказать о них людям. А "алгоритмы"? Типа как "были бы данные, а алгоритмы найдутся". Нет, не найдутся. Deep learning -- это ведь прежде всего алгоритмы, хотя в какой-то мере и другие типы данных тоже (распределённые представления -- это ведь тоже про данные! Но вряд ли просящие "рассказать про данные" имеют ввиду распределённые представления).
2019

Многоступенчатая объективация и объективизация: от философской логики до системой инженерии

По итогам вчерашнего дня на методологической школе (все материалы школы -- http://goo.gl/nl8Um0) я добавил пару слайдов в презентацию (последними -- http://www.slideshare.net/ailev/ss-38128372), и фактически в докладе рассказал главным образом только их (кому невтерпёж, звук доклада тут: http://goo.gl/M058oJ). Материал этот относительно новый, и я его пока нигде особо не рассказывал. С другой стороны, "узок круг этих революционеров, страшно далеки они от народа". В докладе проясняется цепочка профессиональных позиций в разделении труда, которое обслуживает многоуровневую объективацию:
  • Философские логики – знаковые системы и их связь с окружающим миром, предельные онтологи

  • Рефлексирующие модельеры данных – MOF, Part 2 (Upper ontology, foundational ontology). Компьютерщики: преобразования одних выражений мысли в другие (теоркатегорное представление выходит на передний план, не теория множеств – операции главные, вычисление)

  • Модельеры данных/intermediate ontology – одна логика, помогают выразить мысль непротиворечиво (теоретико-множественное представление – объекты главные).

  • Ситуационные инженеры методов, кейс менеджмент, BPM, проектные управленцы, оргдизайнеры – мысли о деятельности

  • Рефлексирующие инженеры/микротеоретики=онтики – мысли о своей дисциплине (объекты-предметы: системная инженерия, программная инженерия, инженерия предприятия, инженерия психика)

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

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

Доклад "Процессы, проекты, кейсы, практики и прочие описания деятельности"

Доложился сегодня на 2й конференции "Процессное управление сегодня и завтра" (http://www.businessstudio.ru/conference/2013/program/). Мне казалось, что я рассказываю про "процессное управление сегодня", но мне организаторы пояснили, что это остальные доклады "про сегодня", а вот мой доклад как раз "про завтра". Ну-ну, все мы живём на одном глобусе, но "здесь и сейчас" в разные времена.

Вот слайды (http://www.slideshare.net/ailev/ss-28529665):


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

Руслан Горб сделал доклад, который мне особенно понравился. В этом докладе НОТ (напомню: научная организация труда, иначе "тейлоровщина" -- крайне могучий и эффективный подход в умелых руках) и отчасти голдратовщина были аккуратно прикрыты словами "кайдзен", "KPI", "процектный подход", "процессный подход" и всякими другими модными словами. Эти модные слова нужно было просто правильно толковать из говоримого "между строк". Так, практически все KPI были нормами скорости работы, выражаемыми во времени выполнения какой-то единицы деятельности. Никаких "сбалансированностей" и прочего размытия информации, всё непосредственно измеримо, упор на фронт-офис (в данной фирме это по факту и есть основное производство). Всякие непосредственно не выходящие на клиентов работы проходят через хелп-деск (используется ITIL -- для любых внутренних сервисов, не только IT), и там автоматически регистрируются и измеряются -- опять же, прежде всего на скорость. В результате имеем неплохой рост бизнеса. Моё пожелание к ним было продолжать в том же духе и не вестись на все эти "завязывания показателей друг на друга" и "тотальный кайдзен всего", ибо в этот момент стремительный рост почему-то начнёт тормозиться: мушка-то будет сбита, их де-факто слоган "скорость решает всё" будет размыт во "всё решает всё".
2019

Фейсбук -- лидер в поддержке гламурного мышления

Редко, но я заглядываю в фейсбук (куда транслируется мой ЖЖ). Первое, что я увидел сегодня в тамошней ленте -- это запись, сгенерированную по формату "X likes that Y liked R". Важным событием стало уже не то, что понравилось кому-то, а то, что им понравился факт нравленья чего-то другим.

Почему-то вспоминается "Гламурное Кисо, и вообще человек гламурного мышления есть существо, которое считает акты потребления — достижениями" (http://krylov.livejournal.com/1404527.html). Пожалуй, фейсбук с его лайком-на-лайк окончательно закрепился как главная на планете информационная система поддержки гламурного мышления. Кто-то что-то потребил и задокументировал это, другой это лайнул, признав достижением, третий лайкнул то, что второй оценил это как достижение...
2019

Семантический каталог (компонент) методов и софт для его использования

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

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

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

3. Основной сценарий, предлагаемый сторонниками ситуационной инженерии методов: используя Составитель (Method Composer), отбираются компоненты метода для конкретного проекта. А потом уже данный "метод проекта" публикуется для сценария 2 -- чтобы быть справочником по методу для всех участников проекта.
Для этого сценария нужно реализовать софт Составителя.
Но я не думаю, что этот сценарий главный. Представьте, что у вас есть толстый учебник "Системная инженерия", из которого вам нужно вырвать ненужные страницы для того, чтобы остаток раздать вашим работникам в качестве руководства к действию. Страницы-то вырвать можно, а с мыслями там что делать? Что-то такой вариант меня не греет (хотя и используется в больших компаниях для постановки "процессного управления", плодя варианты RUP на EPF Composer).
Пусть весь мир идет этим путем, мы не будем этим заморачиваться. Это путь в тупик, в порождение толстых пачек "описания процессов" без малейшей связи с производственной реальностью (хотя я охотно верю, что где-то есть Очень Дисциплинированные Исполнители, которые могут в военно-приказном порядке все это использовать на деле -- но мне даже неинтересно в этом направлении работать).

4. Инженеры, которым нужно выполнить некоторый проект, используют Читальню из сценария 2, но в режиме "активного эссе" (http://ailev.livejournal.com/466004.html, и чуть более развернуто в http://ailev.livejournal.com/810126.html). Это означает, что все ВидыМоделей-из-Читальни работоспособны и могут порождать конкретные модели. Тем самым речь идет не столько о Читальне, сколько о Писальне -- это уже не столько Читальня Учебников, сколько Библиотека Рабочих Тетрадей с Хелпами к ним. Если компонента метода описывает какой-то ВидМоделей, то инженеру-пользователю можно породить экземпляр этой модели и работать с этим экземпляром. Рабочая Тетрадь при этом подтягивает Справочные Данные из RDL (как типографская Рабочая Тетрадь, в которой что-то уже преднапечатано в типографии), а данные моделирования оставляет при себе (как вписывание ручкой в типографскую Рабочую Тетрадь).
И верстать/составлять нужно не "компоненты метода", а экземпляры используемых моделей, оставляя связанные с ними компоненты метода в качестве Хелпа (еще раз напомню про http://ailev.livejournal.com/810126.html)!
Про workflow/lifecycle/project, который ведет инженера через заполнение этой Рабочей Тетради я пока молчу, это мне представляется не главным. Как правильно заметил Cesar Gonzales-Perez, пул продуктов важнее, и софт нужно организовывать вокруг поддержки него, а не поддержки воркфлоу. Как будет устроен тамошний issue tracker можно будет понять позднее).
Для этого нужно реализовать софт Писальни -- Рабочей Тетради Модельера/Инженера/Организатора (инженера -- если модели "железной" системы; организатора, если речь идет об организационной модели).

Итого: нужно делать Каталог-RDL (невидимый простым человечьим глазом, а видимый только как endpoint из semantic web), Верстак, публичную Читальню и затем коллаборативную Писальню (Рабочую тетрадь модельера).
2019

Модель интеллектуальной обработки: ускорители в ассортименте. Вероятностный сопроцессор на подходе.

Моя модель интеллектуальной обработки сводится к разнообразию используемых обработок знаний (и тем самым применяемых в этих обработках спецпроцессоров -- ровно как в мозге довольно много разных "зон" с их специализацией), но в целом я бы выделил три основных работы (давно об этом думаю, вот, например, переписка июля 2003г. http://community.livejournal.com/openmeta/24040.html, но тут я добавлю куски):
1. Вероятностная работа со "смыслами" (контекст-анализ), определяющая предметную область в достаточной мере, чтобы разобраться с омонимами и вообще речью. Распознавание образов тоже сюда относится: отнесение каких-то "образов" к смыслам.
2. Эвристичные логические алгоритмы для высокопорядковых логик в рамках контекста/микротеории, найденной в пункте. Понятное дело, из-за NP-характера (запредельная вычислительная сложность) задачи эти все решения являются "вероятными", и не факт, что здесь тоже не будут работать вероятностные алгоритмы, связанные с "распознаванием образов". Cyc, например, решает такие задачи введением марковской логики (где логические высказывания снабжаются вероятностями их истинности).
3. Собственно "логика", подразумевающая "точное решение" (например, SAT). Но это совсем специальный случай, а не самый частый. Это только недоразумение, что компьютеры ассоциирууются сегодня только с этими алгоритмами.
4. А еще должны быть симуляционные модели, которые воспроизводят какие-то сложные куски реальности (можно думать о какой-нибудь Моделике).
5. И так далее...

Современные исследования тоже где-то в этом русле (например, поглядите на работы последних лет от Cyc: http://cyc.com/cyc/technology/pubs, или вспомните тот же пакет по работе с натуральными текстами Apache UIMA http://uima.apache.org/). Прорывы в софте налицо: одни и те же данные молотят самыми разными методами -- сочетая вероятностные расчеты и строгий логический вывод, а часто еще и численное моделирование в рамках одной задачи.

Но главное, намечается существенный прорыв в аппаратуре. Когда-то думали, что пролог-машины или лисп-машины решат все задачи AI, но теперь очевидно, что этого недостаточно. Нужны обильные вероятностные расчеты, и поэтому процессорные ускорители должны быть не только "логическими", но и "вероятностными". И вот оно -- готовятся к выпуску (скоро, в 2013 году) аппаратные ускорители x1000 для вероятностных алгоритмов: http://www.hpcwire.com/features/Startup-Aims-to-Shake-Up-Computing-with-Probability-Processing-100816474.html?viewAll=y

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

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

Мир второй жизни сегодня: глянец и гламур.

Несколько лет назад, когда виртуальные миры только-только появлялись, я частенько проглядывал синдицированные блоги про Second Life -- http://planet.worldofsl.com/.

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

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

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

Требовательный инжиниринг

Начал отвечать на коммент (http://ailev.livejournal.com/667768.html?thread=5692024#t5692024) и решил вынести отдельным постом. В комменте vit_r приводит фрагмент картинки из реальной requirement diagram, выполненной по современной моде системной инженерии, в SysML:


vit_r пишет: "это элементарный случай дюжина на дюжину. У меня во многих случаях идёт сто на сто. Так что графическое решение многих задач красиво только на элементарных (рекламных) примерах".

ППКС! Полностью согласен с приведенным примером. Хотя из этого не следует, что язык можно сразу выкинуть: можно сохранить его онтологию и семантику, но поменять нотацию. Так, схемами IDEF0 (даже в более расширенном их варианте, так называемом eIDEF0) в графическом виде пользоваться нельзя, но их великолепно подшивать к отчетам по договору: очень умно выглядят и занимают много-много листов бумаги. А вот пользоваться ими удобно только в виде их табличного представления. Хорошенькая такая табличка, с парой дюжиной полей и мнооооожеством строчек, готовится в Exel (например, программой ОргМастер), свободно читается топ-менеджерами без айтишного образования...

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

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

Я думаю, наш самый большой вклад в INCOSE может быть в том, что мы будем усомневать SysML в качестве единственного языка системной инженерии. Мне кажется, что будущее тут не за "один язык для всех и обо всем", а за набором DSL для разных групп описаний. Ход на стыковку Modelica с SysML мне не представляется самым удачным (хотя Modelica и имеет текстовое и графическое представление одновременно. Кто знает, вдруг редакторы для Modelica станут средством массового применения SysML для больших систем?).

Если вернуться от общего обсуждения недостатков графических языков для описания больших систем к представлению требований, то
а) с онтологией требований все пока очень плохо:
-- понятие "трассировка" совершенно неоперационально (протрассируйте-ка требования ilities! Как раз про это assurance case, и нужно как-то требования привязывать к claims и далее к тестированию и обоснованиям, что в системах управления требованиями не слишком-то поддерживается, равно как в системах оценки: нет того места, где claims сопоставлялись бы с требованиями, или генерировались из них);
-- верификацию от валидации отличить зачастую затруднительно. Тут вся эта дискуссия про intents, различие "духа" требований и их "буквы", что очень трудно отразить в языке. Различение превращается в игру слов и выпячивание должностей участвующих;
-- иерархичность требований непонятно по каким типам отношений проходит -- понятно только что по разным (в мереологии обсуждается, что иерархии требований-подтребований могут строиться по разным основаниям);
-- разница между функциональными/черного ящика и конструкторскими/белого ящика требованиями размыта;
-- привязка требований к стейкхолдерам, и далее различные view и viewpoints для их выражения отнюдь не способствует единообразному их представлению. Требование "чтобы 2*2 было =4" лучше представлять в формате выражения, а вот требование "на самом видном месте должен быть налеплен логотип" даже не сразу понятно, в каком формате представлять, кроме текстового (хотя я верю, что "самое видное место" вполне можно формализовать и затем проверять выполнение этого требования приборно -- распознаванием сцен).
Этот список можно продолжать и продолжать. Сведение всего этого списка к "требование -- это текстовая строка, не более" сводит системы управления требованиями к простому блокноту, т.е. явно не дает особого выигрыша по сравнению с любой неспециализированной базой данных "текстовых строк". А как только мы пытаемся выскочить за пределы такого упрощения, тут же получаем все непонятки с требованительной онтологией.

б) с DSL (domain specific language) требований тоже плохо: язык должен выражать какую-то определенную онтологию, нотация должна быть компактна для этой онтологии. Ежели у нас нет онтологии, то мы не можем представить компактный язык для ее описания. Так, сначала можно поверить в SysML как адекватный язык представления требований, затем предложить альтернативную нотацию. Но вот что-то не кажется, что язык (его семантика) адекватен. Далее см. пункт 1 -- нелепо переходить к оптимизации нотации без уверенности в выразительной силе подлежащей семантики.
2019

Еще об моделирование данных.

AspenTech выпустила aspenONE V7 с интерфейсом ISO 15926 и master data model -- http://www.aspentech.com/publication_files/introv7_prf.pdf. Ах, сколько умных слов в их пресс-релизе! Сам продукт -- http://www.aspentech.com/v7/

Модельерам данных с "черным поясом" (sic) требуется разбираться в следующих моделях данных:
-- схема их любимого интеграционного софта (от Bentley, Intergraph, AVEVA или AspenTech). А ежели в проекте участвуют несколько таких софтов, то во всех.
-- ISO 15926-2 (чтобы говорить с коллегами).
-- Gellish (чтобы говорить с инженерами).

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

Ссылочки

Срочно закрываем все табы, пока все не подвисло.

Российское проектное управление задает образец для мирового сообщества: доклад Либерзона сотоварищи 6 мая в Чикаго -- http://www.pmforum.org/blogs/news/2008/04/archibald-liberzon-mello-to-showcase.html

Отличия Spider Project от западных пакетов: http://www.spiderproject.ru/library/difference.ppt. Автоматически выбирать назначение на роли из пула скиллов они научились. И бригады у них есть. И поддержка самых уродливых форм российского нормирования работ ("объемы работ") -- есть. Есть "движение материалов" (что является шагом к моделированию производственных процессов). Сравнение версий проекта. Движение денежных средств. Анализ трендов (самый писк моды в измерениях!). И так далее -- огромный список. Критический ресурсный путь (сильно усложненный вариант критической цепочки) тоже есть.

Про ProChain я уже давал ссылку, но повторюсь: http://www.prochain.com/

Таинственные поставщики Gellish-браузера: http://www.steplib.com/Products/main.htm

Сайт по RM-ODP (The Reference Model of Open Distributed Processing, RM-ODP, ITU-T Rec. X.901-X.904 | ISO/IEC 10746) -- http://www.rm-odp.net/

И тут у меня браузер все-таки подвис, ссылки поэтому кончились.