Category: дизайн

Category was added automatically. Read all entries about "дизайн".

2019

Системноинженерные ветры: погоды стоят предсказАнные

INCOSE INSIGHT в выпуске 3 тома 21 (октябрь 2018) вдруг обратился к теме системного мышления в системной инженерии и изменениям в системной инженерии. Конечно, вопрос назрел. Я писал про коннективистскую проблематизацию системного подхода в марте 2016, https://ailev.livejournal.com/1252230.html. Проблемы с системным подходом есть, но:
-- в это выпуске INCOSE INSIGHT они признаются, но не решаются (и это, как мне кажется, отражает текущую ситуацию в INCOSE в целом). Но делается правильный вывод, что если системный подход меняется, то и системная инженерия тоже должна поменяться. А посколько системная инженерия по факту сильно меняется, то это означает, что "что-то уже происходит" -- главным образом с моделеориентированностью. Но на ста страницах текста не говорится, что именно происходит.
-- предлагаются в количестве разные классификационные схемы (типа захмановских банальных "что когда где почему") для того, что и так уже есть в современном системном подходе, и эти схемы берутся по линии философских абстрактных рассуждений линии системологии (systemology, как вместо текущего systems theory предложил переводить в 1973 году Russ Ackoff с немецкого берталанфиевское systemlehre из 40х годов прошлого века -- при этом сам фон Берталанфи перевёл в 50х как раз systems theory), а не из инженерии. Вот эти замены терминов вроде как и должны отражать "прогресс", увы.

Писали в этот INCOSE INSIGHT в основном люди, консервирующие системное знание полувековой давности в разных Systems Societies/Associations (много их), а также немного INCOSE Fellows, но они обращались не столько к инженерному актуальному опыту, сколько к рассуждениям по поводу предыдущего инженерного опыта. Уровень абстракции вырос (классификации известного!), но связь с жизнью (практиками, где эти предлагаемые классификации можно было бы использовать как аттракторы внимания) упала.

Но какой-то прогресс в понимании всё-таки отражён, главным образом в тексте про новое определение системной инженерии. Сегодня существует множество определений системной инженерии, и вот одно из них (попавшее в INCOSE Handbook) и пытаются поправить INCOSE Fellows. Вот их два текущих варианта (оба из одной статьи -- один из начала, "вот мы тут предложили новый вариант" и второй из "summary and conclusions", которые на сегодня является "самым современным" (и имеет статус "для дискуссий"), я так и не разобрался из текста, какой же из них предложен, но они разные, изменения выделены:
Systems engineering is a transdisciplinary approach and means, based on systems principles and concepts, to enable the realization of successful whole-system solutions.

It focuses on: establishing stakeholders’ purpose and success criteria, and defining actual or anticipated customer needs and required functionality, early in the development cycle; establishing an appropriate lifecycle model and process approach considering the levels of complexity, uncertainty and change; documenting and modelling requirements for each phase of the endeavor, then proceeding with design synthesis and system validation; while considering the complete problem and all necessary enabling systems and services.

Systems engineering provides guidance and leadership to integrate all the disciplines and specialty groups into a team effort forming an appropriately structured development process that proceeds from concept to production to operation, evolution, and eventual disposal.

Systems engineering considers both the business and the technical needs of all customers with the goal of providing a quality solution that meets the needs of users and other stakeholders and is ft for the intended purpose in real-world operation.
* * *
Systems engineering is a transdisciplinary approach and means, based on systems principles and concepts, to enable the successful realization, use, and retiral of engineered systems.
It focuses on
establishing stakeholders’ purpose and success criteria, and defining actual or anticipated customer needs and required functionality early in the development cycle;
establishing an appropriate lifecycle model and process approach considering the levels of complexity, uncertainty and change;
■ documenting and modeling requirements and solution architecture for each phase of the endeavour; and
■ proceeding with design synthesis and system validation while considering the complete problem and all necessary enabling systems and services.

Systems engineering provides facilitation, guidance and leadership to integrate all the disciplines and specialty groups into a team effort forming an appropriately structured development process that proceeds from concept to production to operation, evolution, and eventual disposal.

Systems engineering considers both the business and the technical needs of all customers with the goal of providing a quality solution that meets the needs of users and other stakeholders and is fit for the intended purpose in real-world operation and avoids or minimizes adverse unintended consequences.
Все эти изменения сделаны, чтобы отразить факт перехода системной инженерии
-- от создания present paradigm целевых систем of robust, dependable, mainly technological, “deterministic systems” к созданию future paradigm of resilient, adaptive “evolutionary systems” and systems-of-systems, encompassing products, services and enterprises, integrating technological, social and environmental elements
-- от present paradigm обеспечивающих систем implicitly, a command and control view of how systems engingeering works к future paradigm explicitly, a collaborative view of how systems engineering works.

В Сети есть текст, который разъясняет многое из этих предложений (от большинства же авторов): https://www.researchgate.net/publication/327073164_Envisioning_Systems_Engineering_as_a_Transdisciplinary_Venture.

Для меня это всё -- махать белым платочком уже давно ушедшему поезду. Даже этот крутой переход от "междисциплинарности" к "трансдисциплинарности" (признание системной инженерии "кругозорной дисциплиной", находящейся на другом уровне абстракции по от отношению к другим инженерным дисциплинам) -- это всё отражение давно осознанного, это не "будущее", это признание настоящего. Есть уже и новый учебник "трансдисциплинарной системной инженерии" -- https://www.amazon.com/Transdisciplinary-Systems-Engineering-Convergence-Hyper-Connected/dp/3319621831 (вышел год назад, в октябре 2017), и оценки читателей там все -- must read. Конечно!

Переход от system к solution (чтобы включить и сервисы тоже, а не только системы) -- ну, просто взяли уже давно прижившийся в IT термин. То, что делается акцент на real world operation -- это то, что нужно дойти до реализации системы в 4D и её стадии эксплуатации, банальность. То, что нужно смотреть за границы "типового жизненного цикла", так что operation его не заканчивает, а дальше идёт evolution перед выводом из эксплуатации -- это тоже давно понятно, у меня это во всех курсах говорится. Что системная инженерия существенно занимается архитектурой обеспечивающей системы, а не только архитектурой целевой системы, так это тоже давно понятно (то, что в ISO 15288 пришлось вместо подобного полноценного взгляда сдать позиции набежавшим из ISO 9000 процессникам, заставило уйти Harold "Bud" Lawson с позиции выпускающего редактора -- по идеологическим разногласиям, более десятка лет назад).

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

Но я рад: этот выпуск INCOSE INSIGHT показывает, что мы тут никуда не опоздали, ни от чего не отстали. Все погоды стоят предсказАнные.

DISCLAIMER. Я сам до сих пор директор по исследованиям Русского отделения INCOSE, и этот текст отражает мою личную точку зрения, а не точку зрения Русского отделения, и уж тем более не INCOSE в целом.
2019

Доклад "Визуальное мышление"

Я выступил с почти трёхчасовым докладом "Визуальное мышление" в лаборатории визуального мышления 24 мая 2018 (https://www.facebook.com/events/183898065564572/). Предварительные тезисы доклада я подготовил тут: https://ailev.livejournal.com/1418832.html, но в докладе я затрагивал больше тем.

Вот слайды (https://www.slideshare.net/ailev/ss-99175083, а те, кто внутри совка, могут взять их тут: https://yadi.sk/i/8Z6iYtOq3WcJCN):


Вот видео (https://vimeo.com/272129795):


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

И дальше я весь доклад разворачивал тезис, что чем более развито мышление в какой-то предметной области, тем больше вероятность обнаружить в ней не идеографические (https://ru.wikipedia.org/wiki/Идеограмма) средства его поддержки, а тексты самой разной структуры (в том числе организованные в таблицы и даже более сложные формы, но тексты). Грубо говоря, мышление в промышленных (а не попсовых развлекательных) масштабах поддерживается текстами, а не визуальными полотнами. Все эти design thinking, скрайбинг и прочее -- развлекательные мероприятия, эйфория и действенный эффект от которых исчезает на второй день после их проведения. Они поддерживают мотивацию, интерес, что угодно, кроме мышления. А мышление? Мышление проходит при помощи абсолютно альтернативных средств, и в конечном итоге мы имеем поддержку мышления текстами разной степени формальности. Это очень жёсткий тезис, всегда можно найти ему какой-то пример-другой в опровержение, но парочка примеров ничего тут не меняют (я отдельно рассказал о байесовских оценках всех гипотез). Реальные инженеры работают абсолютно не так, как рассказывают адепты design thinking. Они работают с формальными языками по большей части, а не с картинками. Картинки-эскизы у них бывают, конечно (словами сложные формы в 3D трудно изображать, хотя когда речь идёт о моделях САПР они опять-таки хранятся и обрабатываются в последовательностях символов, а не собственно картинками).

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

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

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

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

У меня всё это и множество других затронутых тем довольно подробно было расписано в разных текстах последнего десятка лет, но доклад проходил по самым разным местам в этих текстах, собирая их содержание -- и это длилось два часа сорок минут. Может быть, когда-нибудь этот доклад прочтёт искусственный интеллект и сделает из него конспект, который можно будет быстро прочесть. А пока есть один только способ ознакомиться с содержанием: смотреть видео и смотреть слайды. Это медленно, это IMHO не слишком поддерживает мышление, зато очень, очень визуально -- многие будут довольны.

Уже в кулуарах меня спросили, почему я не поминал Дракон? Потому как а) визуальный, это анахронизм, б) нерасширяемый (я поминал про внутренние DSL как мейнстрим), в) императивный в наш век мультипарадигмальности. Этого достаточно, чтобы не поминать Дракон. Ему место в музее, как старинной прялке. Рассказывать детям, как кучеряво мыслили люди в двадцатом веке. А сейчас уже 18% от 21 века прошло.

Пара реплик в обсуждениях и фотки: https://www.facebook.com/sun.oxana/posts/1972918972720366, https://www.facebook.com/photo.php?fbid=2141480432535729&set=a.810993412251111.1073741829.100000213806603&type=3
UPDATE: ещё обсуждение https://www.facebook.com/ailevenchuk/posts/10213024327936939
2019

Купить нельзя, изготовить

Сегодня на NVIDIA GTC'18 я побывал на презентациях по будущему AI-проектированию от Autodesk и Dassault Systemes/Exalead. Эти проектирования оказались абсолютно разными, общие там были разве что клятвы в любви к NVIDIA -- ибо GPU сегодня это обеспечивающая технология (enabling technology) для грядущих чудес.

Autodesk (отнюдь не первый раз его представители рассказывают об искусственном интеллекте, на GTC'17 я тоже имел удовольствие их слушать) считает, что фишка не в проектировании, а фишка в том, чтобы в конечном итоге сделать (make). И далее слова design for manufacturability не звучат, но разговор только об этом. Нужно взять намерение проектировщика (designer's intent) и затем просто найти нужное решение в пространстве возможных решений -- с учётом всех требований и ограничений. Например, нужно опросить всех сотрудников об их предпочтениях по офисному пространству, и затем просто синтезировать/породить/generate офис, в котором каждому указать на то место, которое более-менее соответствует его предпочтению. Одному нравится сидеть спиной ко всем, другому лицом ко всем, третьему в тёмном углу, четвёртому повыше. Вот дать каждому то, что он хочет: это ж типичная оптимизационная задача. Люди из Autodesk Research взяли и сделали это. А ещё они перетолковали знаменитые "форма следует функции" и "функция следует форме" в "форма следует силе" -- форма должна порождать малое количество материала, для этого нужно просто сделать прочностной расчёт и породить самую лёгкую и простую в изготовлении конструкцию, удовлетворяющую прочностному расчёту. А ещё? Текущие их интересы в переносе стиля: сочетаемость деталей они научились выявлять, но вот теперь хотят делать детали красивыми, просто перенося стиль красивого дизайна на порождённую "по силе" не слишком стильную форму. Одним словом: generative design. Что будет после CAD? Я всегда хихикал, говоря, что САПР -- это Автоматизация Проверки, а не Проектирования. Будет порождение, generative:

autodesk_gtc18_afterBIM

А в строительстве? А то же самое, порождение/generative:

Autodesk_GTC18_afterBIM2

Впрочем, это не сильно отличается от того, что я уже много лет говорю (вот я в 2009 году говорил, https://ailev.livejournal.com/728605.html -- разве что тогда я считал, как все, что правила порождения нужно запрограммировать, а не выучить. Сегодня жизнь изменилась: порождение осталось, а правила его выучиваются на базе прежних работ по проектированию.

Презентация Dassault Systemes/Exalead отличалась существенно. Потому как если в Autodesk от поиска переходили к порождению, то тут переходили от поиска к нахождению. В чём разница? Между search и find разница была определена как в одном случае итеративная процедура, когда вы с помощью компьютера что-то ищете, а в другом случае бот улавливает как-то ваше проектное намерение и находит то, что нужно. Где находит, в пространстве решений? Нет, на рынке. Рынок (marketplace), понятно, уже сделан и фишка в том, что для 3D-деталей можно находить похожие по форме и дальше просто покупать. Ах, ещё и помочь заказать и проследить за логистикой. И проследить, чтобы не было при покупке большого разнообразия. Если что-то можно найти и купить, то ни в коем случае этого нельзя делать!
Exalead_GTC18_buy

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

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

Но в этом-то и фишка, что вместо десяти сегодняшних убогих металлоёмких деталей в сборе сегодня можно изготовить одну деталь -- где форма будет следовать силе, где надёжность больше, а стоимость в конечном итоге просто за счёт отсутствия логистики десяти различных компонент к месту сборки, сборки и контроля качества сборки. Меняется сам подход к проектированию и изготовлению. Найти-купить в конечном итоге может оказаться дороже, чем изготовить. Проектирование само по себе настолько быстро съёживается, что сам Автодеск себя пытается переделать в компанию-мейкера и для отладки проектов уже открыл пару публичных мастерских (design and build spaces).

Вот этот тренд от "найти и купить, ручной и головной труд дорог и долог" к "спроектировать и изготовить самому, это нетрудно при должной автоматизации" сейчас повсеместен.

Когда я учился на химика в конце 70-х, все химики сокрушались: найти нужный "синтез" (кухонный рецепт, как сварить какое-то нужное тебе вещество) занимало столько же примерно времени и было настолько же нудным и трудоёмким, сколько разработать свой метод синтеза. Потом появились компьютеры, и "искать синтез" стало быстро. "Найти и купить" стало ведущей парадигмой, слегка отягощаемой случаями, когда найденный синтез не удавалось повторить или ничего не находилось, потому как нужно было сварить действительно что-то новое, рецепта которого просто ещё не существовало. Вот, сегодня (29 марта 2018) опубликована работа, в которой проблема решена: глубокие нейронные сетки были натренированы на все опубликованные реакции органической химии, а затем слепым двойным методом определили, что качество этих "синтезов" такое же, как у людей. Ещё одно проектирование, теперь уже химического синтеза, стало порождающим -- https://www.nature.com/articles/nature25978 (статью можно взять в https://vk.com/wall-44016343_19264).

Это не значит, что в фразе "купить нельзя изготовить" запятую нужно прямо вот сейчас ставить как "купить нельзя, изготовить". Вот прямо сейчас это все не Autodesk, а Autodesk Research. Не химический завод, а Nature. Сейчас на земном шаре "купить, нельзя изготовить". Но идея принтера-самобранки, который напечатает тебе нужное вещество, почку, гамбургер и старинный манускрипт, неотличимый от натурального, живёт. Сегодняшний момент просто подсказывает, что у этого принтера будут ещё и мозги, которые сначала породят-спроектируют запрашиваемое. Порождающее проектирование, порождающее производство. В 2009 году, когда я делал доклад про будущее инженерии (ибо manufacturing это уже не только design, разговор шёл про полный жизненный цикл), уже был generative manufacturing. Но это казалось далёким будущим. Далёким по времени. А сейчас из России это просто далёкое по расстоянию будущее, но уже не по времени.

Situational methods engineering, скорее всего, постигнет такая же судьба. Практики/методы будут порождаться (проектирование практики -- generative design), и вовсе необязательно, что речь пойдёт о фрагментах практики из какого-то каталога. И постановка результирующей сборной практики (уже не собранной из кусочков, а более-менее связной) для компании из людей и вполне вменяемой (и даже разговаривающей, почему бы и нет) нежити будет существенно отличаться от сегодняшней -- generative organizational change, примерный аналог порождающего изготовления. Стратегирование и оргизменения тоже будут склеиваться, и тоже будут поддержаны софтом. Сначала в лабораториях. Потом в немногих компаниях early adopters. А потом мир опять изменится -- и мало кому будет понятно, что происходит. Но с предприятиями, в отличие от железок, софта и зданий-сооружений в этом плане придётся подождать ещё несколько лет. Ибо предприятие на принтере не напечатаешь, метод изготовления предприятий -- лидерство (подробней вам об этом расскажут тут: http://system-school.ru/event/kurs-osnov-sistemnogo-liderstva-2018-04-07/).

Вообще, на GTC'18 промышленности и стройки было уже довольно много -- прямо в выставочном зале стоял экскаватор Komatsu (у него были глазки, которые помогали ему ориентироваться на стройплощадке), всяческие системы мониторинга использования строительной тяжёлой техники и т.д.. Недреманное око пришло на производство и стройку, непрерывно отслеживает план и факт. Но было бы что отслеживать. Основной упор на то, что проект и план должны порождаться не людьми. Люди должны только выразить намерение и задать ограничения. И это "видение сказочников от IT" уже не полная фантастика. В кулуарах люди из Autodesk рассказывали, что в этой всей деятельности им больше всего нравится наблюдать лица инженеров, которые получали "из машины" неожиданные проектные решения -- такие, какие самим бы инженерам в голову не пришли. Это истории уже сегодняшнего дня, не завтрашнего. Завтра просто это перестанет быть предметом обсуждения, это будет просто быт -- и эмоций от "компьютерного творчества" уже не будет. Будут эмоции, когда компьютер будет выдавать решения, которые люди и сами могли бы выдать: зачем им тогда компьютер, если они и без него могут такое придумать?
2019

Пост-объект-ориентированная Julia

Крис Партридж говорил, что современных программистов легче убить, чем переучить в другие парадигмы -- например, в них в ВУЗе намертво вколочен аристотелевский онтологический подход с объектами и атрибутами, а факт-ориентированность для них интеллектуально недоступна. Julia тоже плохо понимается современными ООП-программистами, ибо она не объект-ориентирована: в ней используется multiple dispatch. Я тут подобрал несколько ссылок, где можно почитать подробней о пост-объект-ориентированном стиле программирования в Julia:

-- две большие фичи Julia: multiple dispatch (который вместо ООП) и средства интроспекции -- http://ailev.livejournal.com/1218155.html (и там довольно много дополнительных ссылок на разъяснения).
-- The Design Impact of Multiple Dispatch As the core paradigm of Julia (Stefan Karpinski): http://nbviewer.jupyter.org/gist/StefanKarpinski/b8fe9dbb36c1427b9f22 -- базовый пример.
-- Type-Dispatch Design: Post Object-Oriented Programming for Julia (Сhristopher Rackauckas): http://www.stochasticlifestyle.com/type-dispatch-design-post-object-oriented-programming-julia/
-- Modular Algorithms for Scientific Computing in Julia (Christopher Rackauckas): http://www.stochasticlifestyle.com/modular-algorithms-scientific-computing-julia/
-- 7 Julia Gotchas and How to Handle Them (Christopher Rackauckas): http://www.stochasticlifestyle.com/7-julia-gotchas-handle/ (о 7 типовых ошибках, которые делают начинающие работать на Julia)
-- DSL в Julia http://ailev.livejournal.com/1366789.html (и там ссылка на общий паттерн метапрограммирования для DSL в https://julialang.org/blog/2017/08/dsl).

За всё нужно платить. Julia -- более трудный в изучении язык, чем Python, R или Matlab. И материалов для изучения особенностей Julia пока не так много. Хотя на Julia можно достичь бОльшего, чем на Python, R или Matlab, платить за это нужно дополнительным временем обучения, дополнительной ломкой мозга. Это скрипка Энгельбарта (http://ailev.livejournal.com/1158826.html), да ещё и специально заточенная на вычислительную математику.

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

AMA со мной в CreativeRussia

Опубликовано видео AMA (формат ask me anything) со мной в CreativeRussia, стримилось это live через Hangout на несколько десятков человек 27 апреля 2016г. (https://youtu.be/ey4RNOQEOuk):

Спрашивали о всяком разном, но главным образом про машиноинтеллектуальное творчество. Оно и понятно, Creative Russia ведь как раз сообщество "криэйторов" ("вся соль дизайна, технологий, медиа и стартапов" -- http://creativerussia.co/), а у кого что болит, тот о том и говорит.

Я уж старался "криэйторам" всё "на пальцах" объяснять, даже темп речи у меня медленней обычного получился. Это вполне поправимо: плеер youtube позволяет смотреть это и с удвоенной скоростью.
2019

Нужны ли виртуальные персональные и групповые ассистенты? Не факт!

Вот обратите внимание, как непросто подбирать задачи для Cortana, Google Now, Siri. Для поиска задачек к M городят целый огород с настоящими людьми.

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

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

Ассистент должен сам уметь делать что-то гениальное, а не просто разговаривать. Если есть аппка, то проще этой аппкой воспользоваться самому на голосовом интерфейсе, безо всякого посредника. Аппы сами будут разговаривать, аки люди-эксперты. Секретари для общения с ними могут оказаться не нужны. Посадить пяток аппов, и беседовать с ними. А персональный ассистент? Что он сам должен мочь? "Позови мне Васю и Петю?" Так в виртуальном мире можно просто сказать "ОК, Вася и Петя" вместо "ОК, Гугль, позови Васю и Петю" -- всего-то делов.

К коллективным ассистентам это тоже относится. Или они фасилитаторы/модераторы/менеджеры (то есть приложения, которые что-то умеют, т.е. не "ассистенты-разнорабочие"), или их быстренько дисинтемедиируют. Всё как с людьми.

Платформы, которые дадут вашему гениальному приложению разговаривать без посредников, уже есть:
-- https://api.ai/ (эта платформа и персональных ассистентов поддержит, это же тоже "приложение", например https://assistant.ai/),
-- https://mindmeld.com/
-- Alexa Voice Service, https://developer.amazon.com/public/solutions/alexa/alexa-voice-service
-- https://www.houndify.com/
-- http://viv.ai/ -- viv radically simplifies the world by providing an intelligent interface to everithing
-- ...тысячи их, дальше просто лень смотреть.

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

UPDATE: дискуссия в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10206694169046923
2019

Справочные, конфигурационные, трансакционные данные

Похоже, что деления на два типа данных (справочные и проектные как в смысле design так и в смысле project) недостаточно. Более осмысленное деление такое:
-- справочные данные: картина мира, как он устроен везде -- учебники, классификаторы, справочники, стандарты, законы, upper и middle ontology и т.д.. В общем, НСИ в ассортименте, правила и ограничения живут тут. Знайте, в каком мире живёте, здесь вам не тут.
-- конфигурационные данные: функциональное и конструктивное знание о целевой и обеспечивающих системах (это и есть design и организационная часть от project -- то бишь organizational design). Инженер, знай свою систему-железку. Менеджер, знай свою систему-организацию. Знайте, с чем работаете.
-- трансакционные данные: данные об изменениях (временные ряды в ходе operations, первичка для внесения изменений в конфигурацию design, в том числе обеспечивающие системы и системы в операционном окружении). Это, по большому счёту, информация разных сообщений.

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

Фишка в том, что управление конфигурацией легко объяснять финансистам. А вот в российском инженерном укладе оно как-то не развито. Оно некоторое время назад и в западном инженерном укладе было не развито (так, одну из штатовских атомных станций остановили именно потому, что управление конфигурацией там было потеряно: не смогли объяснить инспекторам, какое оборудование реально стоит на станции, и какой набор чертежей является описанием реально установленного оборудования -- финансовый аналог тут "не смогли сказать, сколько у них на счёте"). Но на западе инженеры хотя бы знают такое слово, а в России и слова такого не знают (есть, конечно, инженерный учёт, но он устроен по-другому при взгляде на полный жизненный цикл сложной инженерной системы).

Я косвенно проверил это. Примерно год назад я спросил в ACDM (http://acdm.org, Association for Configuration and Data Management), есть ли там ещё члены из России, кроме меня. Мне ответили, что я первый. То есть управление конфигурацией на плечах каких-то наших кулибиных где-то как-то выезжает (иначе вообще бы всё загнулось), но как дисциплина и профессия не живёт, да и слова такого нету.

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

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

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

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

Вариативность: платформы и фичи.

Состав практик моделеориентированной системной инженерии должен учитывать, что инженерия отдельных систем происходит очень и очень редко, требования повторного использования накопленных знаний (reuse) приводят по факту к разработкам семейств систем, продуктных линеек, технологических платформ (http://ailev.livejournal.com/626229.html и там далее по ссылкам подробности и обоснования. С тех пор ещё много разного появилось -- http://www.esi.es/Families/famResults.html, и краткие справочки http://en.wikipedia.org/wiki/Product_family_engineering и http://en.wikipedia.org/wiki/Domain_engineering). Как всегда, основные идеи идут от software product lines, огрубляясь и упрощаясь для общего случая киберфизической системы.

Это означает, что практики моделеориентированной системной инженерии не просто включают в себя порождающее моделирование в целом (http://ailev.livejournal.com/728605.html) и накопление справочных данных в практике , но и расщепление жизненного цикла системы на три разных жизненных цикла её воплощения (realization), имеющих разные объекты и находящиеся в мета-отношении (отношении порождения) друг ко другу:
-- отрасль/предметная область (domain, и тут нужно понимать, что иногда это отождествляется с платформой http://en.wikipedia.org/wiki/Domain_engineering в рамках DDD, но в общем случае для одного domain имеются альтернативные платформы, хотя они обычно совместимы между собой через нейтральные стандарты)
-- платформа (общее техническое решение для линейки продуктов/семейства продуктов, обычно в рамках одного предпринятия или даже эко-системы: наследуемые системой-индивидом технические решения с общей архитектурой и набором интерфейсов, то общее знание, из которого потом делаются отдельные продукты путём добавки разных наборов фич/features -- это термин)
-- конкретная система (индивид, продукт -- и оставим онтологам разбираться с тем фактом, что речь идёт о "строчке каталога", а не об индивидуальной системе с серийным номером. Но и это может быть не так в эпоху mass customization).

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

Моделеориентированность (то есть использование моделей, по которым происходит автоматическое порождение следующих каких-то артефактов -- например, генерация моделей продукта по моделям платформы и профилю фич) проникла и сюда, что один из поставщиков соответствующего софта даже назвал "вторым поколением подхода продуктных линий" (http://www.biglever.com/learn/newsletters.html) примерно так же, как Dassault Systems пыталась поднять на щит PLM 2.0. Мы помним, что из этого вышло с PLM: это стало таким же общим местом, как и использование САПР или базы данных, и особая реклама этого подхода выглядит такой же нелепой, как реклама использования баз данных. "Все говорят прозой, ну и что? Забудьте это слово, оставьте его учёным".

Проблема reuse, которой сто лет в субботу, никак не изменяется от того, что её вдруг называют mass customization, или "созданием платформы", или семействами систем, или даже в полупроводниковой промышленности design for variability. Поэтому на конференциях по продуктным линиям появляются на семинаре по требованиям работы типа "Adopting feature-centric reuse of requirements assets: an industrial experience report" или "Automatic generation of feature models from UML requirement models", "Generating feature model from creative requirements using model driven design" (proceedings конфереции 2012г. -- http://dl.acm.org/citation.cfm?id=2364412&preflayout=flat, уж звиняйте, ежели кто не член ACM и не может прочесть). Никаких "семейств" или "линий" -- просто фичи бывают разными, но должен быть reuse всего (начиная от требований). Действительно, ни один идиот не собирает требования каждый раз "с нуля", обязательно кто-то ведь проделывал очень похожую работу для очень похожих продуктов, и можно безопасно передрать из этой работы довольно много всего. Ну, или специально разрабатывать требования так, чтобы помочь разработчикам будущих отдельных продуктов. Ничего особенного, "все делают это", каждый в меру своей извращённости.

Большинство PLM так или иначе поддерживают variant management (of modular product families) -- да, это опять про то же самое. Поставщики систем управления продуктными линиями -- нет проблем, вот примеры успехов только одного из них: http://www.biglever.com/learn/reports.html, а вот ещё: http://www.softwareproductlines.com/successes/successes.html

Итак, есть общее понимание:
-- продукты включают в себя разные наборы (профили) фич на базе общей платформы для всех продуктов,
-- модель должна быть не столько одного продукта, сколько платформы плюс фич (а некоторые договариваются, что и платформы нет -- это тоже фичи),
-- модель продукта генерируем по профилю фич (и уже предложен первый простейший стандарт CVL для этого: http://www.omgwiki.org/variability/doku.php, хотя есть и другие инициативы типа TVL -- http://www.info.fundp.ac.be/~acs/tvl/, поглядите на картинку того, как это устроено тут: http://www.cetic.be/IMG/pdf/CIEL12-Acher-tutorial.pdf).

С софтом (и даже софтом контроллеров аппаратуры -- http://www.phaedsys.com/pressreleases/pressreleasesdata/pure/purepresentation.pdf) это всё получается очень хорошо, с железом довольно плохо. Тем не менее, рынок моделей телефонов, планшетов, автомобилей, самолётов и т.д. показывает, что и с железом все уже давно "делают это": работают в терминах модульных платформ и наборов опциональных фич к ним. Реактивно (допиливая напильником проект каждого продукта для получения следующего продукта) или проактивно (предусматривая, что допиливать напильником придётся в разные стороны, и лучше бы это учесть сразу) -- это уже второй вопрос. Если вас прижмёт, то вы просто не сможете быстро сработать реактивно, при всей "экономичности" этого подхода. Опять же, если прижмёт, то денег и времени не хватит работать чисто проактивно: жизнь в плане изменения требований к профилям фич оказывается много богаче фантазии. Вот все и крутятся.

И другой моделеориентированной системной инженерии, похоже, уже нет. "Целевая система" сегодня -- это часто даже не строчка каталога, за которой скрываются одинаковые железки с разными серийными номерами. "Целевая система" -- это сам каталог, в котором можно набрать себе самых разных опций. А уж сколько после этого выбора опций будет сделано допроектирования, сколько уйдёт в пересчёт моделей с чуть изменившимися параметрами, а сколько не потребует никаких расчётов, а только решения логистической задачи сборки из не меняющихся модулей -- это уже зависит от решений системных инженеров каждого предприятия, общей практики тут пока нет. Общее только то, что одиночных изделий не бывает -- и поэтому управление конфигурацией должно быть многомерным (много продуктов, много стадий жизненного цикла, много базисов -- http://www.biglever.com/newsletters/2G_SPL_Part3.html).

Куда мы отнесём эти практики вариативности в общем наборе практик системной инженерии (http://ailev.livejournal.com/1026262.html)? Вестимо, к практикам управления конфигурацией. Это PLM в чистом виде, variant management. Ну, а дальше управление конфигурацией предъявляет свои требования к системам моделирования, и каждая практика (работа с user needs и составление профилей фич -- не забываем, что никаких ТЗ не будет с учётом развития продуктовой линии и эволюции платформы, как заметил Отставнов в http://ailev.livejournal.com/625474.html -- в софтостроении давно уже идут только багрепорты и фичереквесты как основная практика; высокоуровневое моделирование с учётом множества вариантов; низкоуровневое моделирование для отдельных конкретных продуктов; и т.д.) учитывают вариативность просто по принципу их построения.
2019

Детские визитки

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

Я ответствовал, что лучше бы это делать в типографии -- и мы сходили в http://www.a-cifra.ru/contacts/ (это десять минут пешком от нашей двери, и три минуты от "Третьяковской" или "Новокузнецкой". Работают с 10 до 21 без выходных).

Через десять минут диалога дизайнера и клиента получился любимый зелёный фон, шрифты с засечками (как в книжках! объяснить, что это не слишком хорошо в визитках, не удалось), вместо названия фирмы класс и номер школы, телефон, адрес электронной почты и адрес блога. С помощью гугла.картинок был найден правильный зомби из Plants and Zombies, ибо без него требовательный клиент дизайна визитки не принимал. Макет был тут же отправлен клиенту по электронной почте, взятой из самой визитки.

Висеть (при любых других способах не получалось) на рычаге резака было доверено самому дитёнку, а самым трудным и долгим было потом увести дитятку из типографии (ибо там ведь ещё много было вокруг интересного, то есть неподёрганного и непокрученного).

Сделали на "полудизайнерской" бумаге (чуть-чуть тиснёной) аж сто штук односторонних, обошлось вместе с дизайном в 620 рублей.

Сводите своих дитяток, пусть им будет счастье и польза.
2019

Неподвижное время

Оказалось, что я встречался со многими работами Bret Victor (http://worrydream.com/), просто не знал, что всё это разнообразие идёт от одного человека. В январе он сделал презентацию своих работ по связке кода программы и результатов её работы на CUSEC 2012, а месяц назад ее опубликовали (https://vimeo.com/36579366):



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

То есть generative design мной всегда понимался как порождение чего-то неразвёрнутого во времени. Bret Victor с этого только начинает. А дальше у него generative design, которые порождает что-то во времени развёрнутое. И он выходит из этого, порождая 4D артефакт, и давая ему развёртку.

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

Идея изображения на полях текущих значений переменных и сообщений об ошибках была сделана в КуМире еще в 1987 году. Для детей соединение кода и результатов его исполнения было определяющим. Но у Bret Victor это соединение идёт дальше: поля эти становятся широкими, а время выполнения опять-таки представлено всё сразу, одномоментно, здесь и сейчас.

Мне кажется, что размышление про 4D онтологию времени (что время -- это просто еще одна координата объекта, и можно мыслить объект как неподвижный во времени) сейчас идёт у самых разных людей и потихоньку будет укореняться в культуре. Хотя мало кто, конечно, мыслит об этом именно как об онтологической проблеме.

Редкостно вдохновляющая презентация, буду думать.

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