Category: дизайн

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

Картинки с текстами vs. тексты с картинками

Что-то щёлкнуло у меня в мозгу, и я таки начал читать мангу. Раньше никогда не получалось: этот жанр был для меня недоступен, я никак не понимал, как можно сравнивать черно-белые картинки с пометками типа "бац" и "жамк" с полноценным текстом или полноценным аниме. Раз в год я делал попытку -- и через двадцать страниц все эти попытки заканчивались, ибо бросал в недоумении. Но в этом году у меня получилось! Я прочёл несколько полномасштабных (размер в 3тыс. страниц картинок -- это не такая уж редкость) манг -- и оказалось, что "послевкусие" от них у меня примерно такое же, как от аниме (и совсем не такое, как от книг). Да, несмотря на отсутствие в манге цвета, звука и движения.

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

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

Про инфографику я подробно писать не буду, там тоже картинки с вкраплениями текста.

LMS (learning management systems) в плане создания контента выродились в слайдовые презентации на стероидах -- учитывая тот факт, что звук и видеоролики в эти слайдовые презентации тоже вставляются элементарно (http://ru.wikipedia.org/wiki/SCORM).

Active essay (www.vpri.org/pdf/tr2009002_active_essays.pdf) сегодня в точных науках делаются довольно легко -- во многих вычислительных системах реализованы notebooks, позволяющие перемежать текст, картинки, фрагменты исполнимого компьютерного кода и области вывода результатов выполнения этих фрагментов кода. Эту идею легко можно распространить и дальше: на все эти "сложные тренажёры" и "моделеры предметных областей".

Да, это всё очень разные жанры донесения содержания:
-- книжка с картинками (текст с картинками)
-- комикс/манга (картинки с текстом)
-- инфографика (сложные картинки с поясняющим текстом)
-- классический "слайдомент" из powerpoint (к которому не предполагается устного выступления)
-- SCORM-пакет в LMS
-- видео (то же аниме, но можно равным образом представить "учебный кинофильм". Меньше всего имею тут ввиду видео говорящей головы лектора -- но и это важно, ибо наблюдение за невербальными акцентами, которые делает лектор, крайне полезно)
-- active essays

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

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

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

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

Тут всё очень и очень неоднозначно. Так, я не верю в графические языки для разработки: большие системы нельзя написать на графических языках, для этого пригодны только текстовые языки. Графические языки нужны только для того, чтобы вынести какую-то проблемную диаграммку на суд не слишком разбирающихся в текстовой нотации экспертов, которые будут обсуждать какой-то крошечный аспект проблемы. Но данный пост не про графические языки, он про картинки -- схемы ad hoc, из головы. Он больше про то, что-то сложное рассказывать людям хорошо бы как в манге (см., например, http://www.mangapark.com/manga/molester-man -- обратите внимание, сколько там текста!), а не как в романе Л.Н.Толстого "Война и мир" (можете даже взять иллюстрированное издание). Да, это шапкозакидательное заявление, и можно спорить: тратить ли пару часов на придумывание правильной картинки-схемы, или на полировку текста. Мне почему-то кажется, что создание правильной картинки-схемы в плане отношения затрат времени к количеству переданных из головы авторов в головы читателей ("рассматривателей", ага) знаний более продуктивно. Так, я мог бы долго полировать предыдущую фразу. А мог бы нарисовать картинку (статичную. Вря ли тут бы помог мультик, вряд ли было бы уместно активное эссе).

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

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

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

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

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

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

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

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

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

4D система и ее жизненный цикл

Вчера на 27 заседании INCOSE рассматривался порождающий дизайн (видео, слайды и картинки -- http://community.livejournal.com/incose_ru/16172.html), докладывал Вячеслав Петухов, а я давал комментарии. Утром я еще некоторое время подумал над высказанными соображениями, и пришел к следующим выводам:

1. Мегамодель системы -- это темпоральная часть системы. Система "в железе" -- это темпоральная часть системы. Трансформации мегамодели и системы нужно отражать в терминах 4D онтологии (например, ISO 15926).

2. Порождения (generation) в мегамодели -- это жизненнй цикл мегамодели. Это generative design. А когда мы порождаем трансформации "в железе" -- это generative manufacturing. Ключевое тут -- это акты порождения, трансформации. Поэтому жизненные циклы нужно показывать как цепочки порождений, а не просто нарастающее количество артефактов/рабочих продуктов. Нужно помнить, что "код на языке высокого уровня", "код на языке машины" -- это две темпоральных части "кода" (причем в ходе трансформации код на языке высокого уровня не исчезает, превращаясь в код на языке машины -- ведь это информационные объекты. А вот прямая труба, выданная в монтаж, превращается в гнутый отрезок трубы, и исчезает при этом -- но это все та же труба, только в разных состояниях. А еще до этого код существовал в виде модели (из которой был порожден кодогенерацией, а потом сгенерированный код был отредактирован, а затем компилирован -- не становясь от этого другим кодом!), а труба существовала в виде чертежей (из которых была порождена в ходе сооружения).



На всех этих картинках не хватает главного: показа трансформаций "одного и того же объекта". Система -- она и в голове система, и в железе, только у нее в жизненном цикле много-много было трансформаций. Мыслить в терминах жизненного цикла -- это как раз мыслить одну и ту же систему с темпоральными частями, которые существуют не всё время. Кодируют "по старинке" только темпоральные части. А ведь нужно еще кодировать и трансформации/морфизмы!
Осторожно выскажу гипотезу: возможно, для записи жизненных циклов нужно использовать моноидальные диаграммы.

3. Поэтому языки из списочка http://ailev.livejournal.com/840977.html должны проверяться на то, соответствуют ли они 4D онтологии или 3D онтологии: разные ли в них объекты до и после трансформации, или же это идут трансформации одного объекта, только в нем меняются темпоральные части в ходе трансформации.
Четко видно, что в одних системах главным является одиночный акт, у которого есть вход и выход -- входят одни объекты, выходят другие. А в других системах цепочка операций происходит над одним и тем же объектом, который проходит через ряд преобразований, оставаясь самим собой в разных состояниях.

4. Понятно, что переход к 4D онтологии породит дикие противоречия "бытового языка" (у нас таки 3D "народная" онтология, т.е. объекты существуют в определенные моменты/срезы времени, а что происходит с ними между этими моментами -- загадка) и 4D языка. Тем не менее, онтологическая шизофрения по поводу попыток описания изменений в языке, в котором нет изменений, а есть средства описания только рядов дискретных состояний, будет меньше. Я начинаю понимать, почему в команде ISO 15926, которая пыталась заниматься жизненным циклом, а не только "проектированием" (когда будущее системы представляется "точкой", а не периодом, в котором система постоянно изменяется), победили сторонники 4D онтологии. Контроль конфигурации (системы, мегамодели, версий кода и т.д.) должен делаться в 4D языке, а в 3D языке это делать не так удобно (хотя и привычней).
Особо отмечу, что для всех "внешних" пользователей ISO 15926 именно 4D "навороты" представляются излишествами и критикуются наиболее сильно как "ненужные для большинства применений". Вот-вот: пока "большинство применений" не связано с жизненным циклом и системным мышлением, 4D не нужно. Если вам не нужно "удерживать целое", то вам не нужно 4D. Если вы не системный инженер, вам не нужно 4D.

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

Литература для начала копаний в 4D-онтологии: http://www.matthew-west.org.uk/publications.html
2019

Из разговора с Rob Hamann

Позавтракали сейчас с Rob Hamann из Дельфтского университета, в прошлом системного инженера по проектам аэрокосмических роботов. На EuSEC2010 он был сопредседателем academic (образовательной? исследовательской? и не переведешь...) секции. Просто, чтобы не забыть некоторые мысли из разговора:

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

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

Выяснилось, что огромное количество системных инженеров не любят INCOSE Handbook (я уже писал, что Мартон Форкош хвастается, что аналогичный NASA Handbook лучше). Rob Hamann использует какую-то древнюю версию середины 90-х, потому как в ней еще сохранились следы обсуждения структуры (продукта) и инструментов (акторов). В текущей версии 3.2 не осталось ничего, кроме процессов -- а это только часть метода! И действительно, текущая версия -- это переписанный ISO 15288, в котором намеренно выкошено все про акторов (роли и инструменты) и продукты (софт, железо и в том числе модели). То есть не учебник, а одна треть учебника. Тем не менее, Роб не пользуется понятием "метод", когда приводит такое рассуждение, "целое" изо всех этих частей у него безымянно и не слишком структурированно. Поэтому он в разговоре пропускает роли, но выпячивает инструменты, а про продукт говорит только "структура" (в оппозицию процессу).

Он считает, что должен быть Главный Системный Инженер во всех проектах, чья задача в диалогах (не путем выдачи команд, а путем убеждения) снимать противоречия между разными "предметными" специалистами (в числе которых он называет Главного по железу, Главного по софту и т.д. -- он приводил в пример свои робототехнические проекты). Должна быть строгая иерархия в принятии решений, иначе по версии Роба будет каюк проектам. Я с ним не соглашался, приводя в пример менеджеров крупных компаний (в их инженерной ипостаси -- они ведь организационные инженеры, а не проектные менеджеры по большей части!): еще пару десятков лет назад про них думали как о строгой иерархии, а теперь общепризнано, что на верхушке менеджерской "пирамиды" не остиё, а ровная площадка небольшой команды с разными мыслительными стилями. Так и в системной инженерии: должна быть команда из людей с разными мыслительными стилями и предпочтениями, и разным тренингом. Роб согласился, что расхождение по факту мыслительных стилей инженера по требованиям и инженера-архитектора неизбежно, но требовал для них одинакового тренинга, "чтобы они лучше понимали, что делает каждый из них в команде" -- и даже в этом случае он считает, что нужен какой-то "командир, снимающий противоречия". Явно в этом месте "коллективного системного инженера" нужно еще копаться и копаться: мне лично кажется, что воззрения "олдовых" системных инженеров тут явно не соответствуют современным хорошим практикам и копируют мыслительный стиль двадцатилетней давности (с точки зрения развития мышления на человеческом коллективном субстрате) прошлого. Одно дело мыслительные прорывы в одной дисциплине (математике, алгоритмическом дизайне), другое дело мыслительные прорывы по всему жизненному циклу и всем дисциплинам: армии, бывало, из-за гвоздя в подкове пропадали -- и "главный командир" тут вряд ли сможет помочь, нужны другие методы организации мышления.
2019

Требования, верификация, дизайн

Стоимость верификации софта в Boeing -- 50% от общей его стоимости (http://shemesh.larc.nasa.gov/LFM2008/slides/Session4/Manolios.pdf). Для дизайна интегральных схем -- 30%-70% (http://www.ccs.neu.edu/home/pete/courses/Decision-Procedures/2007-Fall/lectures/Lecture0.pdf). Современный инжиниринг, по идее, должен включать формальную верификацию (http://https://dashlink.arc.nasa.gov/static/dashlink/media/group/Manolios-2008-10-Nasa-Panel.pdf). С другой стороны, верификация и сам дизайн связаны много теснее, чем можно подумать (http://www.cs.cofc.edu/~bowring/classes/csis%20602/docs/ManoliosISSTA.pdf -- тут работали с реальной авионикой Boeing 787, сокращение времени верификации было с нескольких человеко-лет до нескольких человеко-недель, что дало возможность попробовать в дизайне другие архитектуры).

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

Тем самым к системам работы с требованиями возникают не просто вопросы по а) ее связи с верификацией и валидацией в варианте assurance case (http://ailev.livejournal.com/646290.html), но и б) возможность формулировки требований в виде, доступном для формальной проверки.

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

Тем самым рассматривать какой-нибудь CAD вне связи с полным Vee циклом стадии дизайна (это мы еще исключаем concurrent engineering!) "сбор требований -- анализ требований -- (архитектурный, детальный) дизайн -- верификация -- валидация" сейчас нельзя. Это must.
* * *
Все руки не доходят вернуться к "серой бумаге" (http://ailev.livejournal.com/545386.html). Комменты в том постинге пошли в сторону формы -- "языкоориентированности". А нужно разворачиваться в сторону содержания -- какие языки (сиречь "методы описания") нам нужны, как их структурировать, как сделать так, чтобы сделанные на этих языках описания попадали к нуждающимся в них стейкхолдерам. Собственно, это одна из постановок задачи "управления информацией".

Но пока нужно выполнить план по постам (http://ailev.livejournal.com/647552.html). После этого язык изложения (да и в значительной мере то, что этим языком излагается) будет совсем другим, нежели в годичной давности "серой бумаге".
2019

Об "управление требованиями"

Очень много разговоров про требования в эти предновогодние дни. Запишу кратенько, чтобы потом вернуться к этому вопросу подробнее:

1. Требования, нормы, проект (и в смысле project, и в смысле design), интересы стейкхолдеров и даже сами процессы и их практики -- все это "требования", и с этим нужно еще разобраться.

2. Нет процесса "управление требованиями" в ISO 15288. Там есть два разных процесса -- "сбор требований" и "анализ требований".

3. Согласно Vee-диаграмме, требования потребуются в процессах архитектурного дизайна, а также верификации и валидации (впрочем, и во всех других), поэтому они должны храниться в форме, удобной для этого использования: должна быть предусмотрена трассировка дизайн-решений к требованиям (возможно, по типу assurance case, т.е. через arguments), а для целей верификации и валидации уж точно должна быть предусмотрена форма assurance case, где к claims (соответствующих требованиям) идут связи от evidence (результаты измерений, симуляционного моделирования и других расчетов, актов испытаний и т.д.), причем через agruments -- и нужно понимать, где именно эти arguments, evidence и связи между ними (включая связи к claims) хранятся. Поэтому "IT-система управления требованиями" не должна просто учитывать требования и позволять их быстро искать. Большой вопрос о функциях этой системы, а также о хранимой в ней информации и способах с ней работать -- эти функции и способы работы должны соответствовать не только и не столько процессам "сбор требований" и "анализ требований", сколько другим процессам, в которых требования используются.
2019

Понятийный минимум подхода системной инженерии к управлению жизненным циклом

Если ваша организация вдруг решила заняться системной инженерией, и вы даже раздобыли текст стандарта ISO 15288:2008, то сразу выяснится:
а) о вычитанном в стандарте невозможно говорить по-русски;
б) этого стандарта недостаточно, чтобы понять, о чем идет речь: он упоминает еще пару десятков основных стандартов в самых интересных местах, и нужно также разбираться с этими другими стандартами (архитектурных описаний, процессного подхода и т.д.);
в) центральное понятие (жизненный цикл) непонятно -- достаточно задуматься о том, чем отличаются слова "жизненный цикл" и "управление жизненным циклом" (не говоря уже о "системе управления жизненным циклом системы"). Или попробовать отличить стадии жизненного цикла от процессов жизненного цикла (например, стадию "архитектурный дизайн" от процесса "архитектурный дизайн"). Или понять, почему дизайн всенепременно "архитектурный"?
г) стандарт документоцентричен, и непонятно как его стыковать с датацентричными стандартами типа ISO 15926;
д) совершенно непонятно, с чего начать использование этого стандарта на практике так, чтобы как можно быстрее получить от него пользу.

TechInvestLab.ru в рамках работ над практической организационной системой PraxOS предлагает некоторые ответы на эти вопросы:
а) разработан понятийный минимум подхода системной инженерии к управлению жизненным циклом, причем не только на базе ISO 15288, но и на базе ряда других стандартов;
б) философские основания стандарта сделаны явными;
в) не просто предложены переводы для трудных английских терминов, но и даны их обоснования. Для этих же терминах приведены определения, позволяющие судить об их типах (то есть устроенные по принципу "X -- это специализация Y": "тигр -- это животное, которое большое и хищное").
г) предложено решение, как говорить о документоцентрических и датацентрических системах управления информацией в одном языке, но различать их, когда необходимо;
д) начинать использование стандарта нужно с подготовки "Концепции управления жизненным циклом", в которой перечислить основные целевые системы вашей организации и дать нормативные архитектурные описания процессов управления жизненным циклом для этих систем.

Отныне ответы на подобные вопросы доступны всем не только в форме семинаров, но и в письменном виде. Опубликованы наши свежие разработки по PraxOS:

1. Понятийный минимум подхода системной инженерии к управлению жизненным циклом -- http://www.techinvestlab.ru/495344

2. Требования к "Концепции управления жизненным циклом" -- http://www.techinvestlab.ru/495347

3. Обновленный подстрочник к семинару (слайды) "Подход системной инженерии к управлению жизненным циклом" -- http://www.techinvestlab.ru/486759
2019

COINS и VISI

COINS -- это попытка ввести в голландскую строительную практику:
-- системную инженерию
-- объектный подход
-- интреграцию 3D-моделей и процессов.

COINS (голладнский аналог BIM, Building Information Model) продвигается тем же Henk Schaap, который двигал VISI, и с самого начала VISI-compatible. А VISI -- это приложение DEMO к строительным контрактам.

Вот текст, описывающий, как подобного сорта фреймворки могут становиться обязательными для отрасли: http://wiki.e-bouw.org/images/d/d4/COINS_Mandating_Report_Concept_v2.2.pdf. Среди ключевых факторов для внедрения приводятся:
-- наличие софта, поддерживающего стандарт;
-- достаточные средства и желание инвестировать;
-- внешние и внутренние бизнес-стимулы для изменения традиционных методов работы и производственной культуры (чтобы перейти от документоцентрики к моделецентрики);
-- доверие, влияние, поддержка и количество вовлеченных партнеров, которые могут ускорить инновации в отрасли.

В концептуальную основу (Systematics) COINS входят:
• Defining a building object
• Making junctions and connections
• 3D-geometry
• Functions, requirements and performances
• Systems engineering
• Managing a stage and a state
• Create, modify and release
• Exchanging information
• Roles, responsibilities and authorizations
• Requesting and decision making

Фиксированы стадии жизненного цикла для дизайна, в частности:

Но это я уже взял из голландского текста http://www.coinsweb.nl/downloads/De_COINS-systematiek_april08.pdf. Приходится много читать по-голландски, но это нетрудно делать через гугль-переводчик. Еще лет пять, и язык в Сети не будет иметь значения (как минимум, в случае голландского языка).

В VISI самое главное -- это заранее прописанные транзакции и роли, а также диаграммы обмена сообщениями, например:
.
Описание VISI можно почерпнуть тут: http://cic.vtt.fi/lean/singapore/Vrijhoef.pdf. Уже есть три вендора для софта VISI.