Category: архитектура

2019

Big Neuro: триллионы транзисторов на чипе, квинтильоны и квадрильоны операций в секунду

Буквально за несколько лет мы пришли в мир Big Neuro -- в коннективистских архитектурах, то есть "нейросетях" счёт переходит с миллиардов/гига на триллионы/тера и даже квадриллионы/пета, а пока изредка и квинтиллионы/экза (короткая шкала -- https://ru.wikipedia.org/wiki/Системы_наименования_чисел).

Самый большой чип ускорителя для нейросетей -- это 1.2триллиона транзисторов на 42тыс.мм2, Cerebras Wafer Scale Engine компании Cerebras Systems, изготавливаемый на фабриках TSMC -- https://venturebeat.com/2019/08/19/cerebras-systems-unveils-a-record-1-2-trillion-transistor-chip-for-ai/, https://www.forbes.com/sites/tiriasresearch/2019/08/20/ai-start-up-cerebras-develops-the-most-powerful-processor-in-the-world/#26b4e5a86592. Это в 57 раз больше, чем чип V100 фирмы NVIDIA с 21млрд.транзисторов на 0.8тыс.мм2. Скорость обмена данных с памятью -- 9петабайт/сек, ещё одно Big. The energy cost of communication in this architecture is well under 1 picojoule per bit, which is nearly two orders of magnitude lower than in graphics processing units. В компании Cerebras Systems работает всего 194 человека (хотя мы и не знаем, сколько у них разработчиков было в подрядчиках, тем не менее -- это ли не восхитительно?!).

Конечно, это не сравнится с суперкомпьютером. Так, Summit (запущен в эксплуатацию год назад -- https://blogs.nvidia.com/blog/2018/06/08/worlds-fastest-exascale-ai-supercomputer-summit/) имеет 27648 NVIDIA V100 и 200петафлопс (умножений плавающей) и 3exaops, экза/квинтиллионов операций умножения-сложения целых в секунду -- это помньжьте "пета" ещё на тысячу, миллиард миллиардов. At 200 petaflops — If everyone on Earth did 1 calculation/second, it would take 1 year to do what Summit does in 1 second. At 3 exaops of AI — If everyone on Earth did 1 calculation/second, it would take 15 years to do what Summit can do in 1 second. А сколько занимает места этот Summit? Два теннисных поля! Следующий за V100 чип для текущего нейро-поколения AI -- это Huawei Ascend 910, который имеет удвоенную производительность (закон Мура продолжается для GPU!), но это всего вдвое, 0.25PFLOPS, 0.5PTOPS, по факту того же класса чип -- https://medium.com/syncedreview/huaweis-first-commercial-ai-chip-doubles-the-training-performance-of-nvidia-s-flagship-gpu-86e4d0078f6f

Cerebras Wafer Scale Engine это всего один чип, хотя и потребляет он 15Квт на свои 400тыс. AI вычислительных ядер -- примерно столько же, сколько потребляло бы эквивалентное количество одиночных чипов. Чудес-то не бывает, вычисления требуют энергии.

Самая скандальная языковая модель (модель языка в нейросети) была скандальна ровно потому, что она оказалось достаточно большой, чтобы произвести нетривиальные результаты -- это GPT-2 от OpenAI, которую даже отказались публиковать из-за боязни злоупотреблений в использовании. В ней было 1.5B параметров, 0.0015P. Только что опубликовали сокращённую вдвое модель -- https://venturebeat.com/2019/08/20/openai-releases-curtailed-version-of-gpt-2-language-model/. Но десятые триллиона уже никого не останавливают, только что опубликовали независимо реализованную языковую модель такого же масштаба с практически такими же результатами: https://medium.com/@vanya_cohen/opengpt-2-we-replicated-gpt-2-because-you-can-too-45e34e6d36dc. Потолок цены тренировки такой модели -- $50К, и есть много возможностей снизить цену -- основная цена это те самые чипы и электроэнергия на их работу, сколько на их охлаждение.

И этих чипов нужно много. Чтобы обучить языковую модель BERT всего за 53 минуты потребовалось 1472 GPU V100, это 92 компьютера DGX-2H ценой $399тыс., то есть там только аппаратуры для этого почти часового счёта на почти $40млн, https://devblogs.nvidia.com/training-bert-with-gpus/). И это не самая большая модель! В работе по этой же ссылке https://devblogs.nvidia.com/training-bert-with-gpus/ указывается, что была натренирована модель GPT-2 на 0.0083 триллиона параметров, при этом достигли 15.1 PetaFLOPS sustained performance!

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

При этом сами сетки тоже становятся лучше. Полно работ, которые снижают время обучения и число параметров вдвое-втрое-вдесятеро без ухудшения качества работы сети. Но пока -- чем больше сетка, тем чудесатей результаты. Даже сильно ужатая сетка огромна и требует огромного времени обучения. И это невозможно достичь без выхода на Big Neuro.

А дальше Big Neuro сочтут маркетинговым термином, под которым будут понимать что угодно. Очень скоро будут обсуждать, как и с Big Data, что дело не в размере, а volume, veloсity, veracity, variety, value, variability (https://www.researchgate.net/figure/Six-Vs-of-big-data-value-volume-velocity-variety-veracity-and-variability-which_fig15_280124446) и ещё больше каких-нибудь V. И все формулировки можно будет брать из BigData, и все маркетинговые слоганы.

Но технологически это новый чудесатый мир, где если недостаточно мозгов, то просто добавь транзисторов. А если достаточно мозгов, то тоже добавь транзисторов.

Следующая история, конечно, про симуляторы мира. Чтобы обучить нейросетку, нужно построить виртуальный мир -- и обучать дальше сетку в этом мире, ибо в виртуальном мире эволюция идёт быстрей, чем в реальном мире. Нужно много-много симуляторов. Следующая большая история -- это логические вычислители, которым тоже хочется аппаратной поддержки (вот примеры работ, которые пытаются ускориться на текущих архитектурах вычислений -- https://arxiv.org/abs/1810.06617 и https://www.cyc.com/wp-content/uploads/2015/04/AAAI-SharmaA.1646.pdf, и такого много. Вполне возможно, что тут как с нейронными сетями поможет задействование аппаратного ускорения для получения нетривиальных результатов). Понятно, что будут попытки "повторить мозг" -- перенести логические вычисления в нейронные сетки (neural logic machines -- https://arxiv.org/abs/1904.11694, embedding of knowledge graphs -- https://arxiv.org/abs/1908.07141 и т.п.), равно как моделировать физику не уравнениями, а прямо нейронной сеткой -- https://ai.facebook.com/blog/phyre-a-new-ai-benchmark-for-physical-reasoning/. Смогут ли текущие ускорители AI на нейросетках сработать для этих же задач так же качественно, как могли бы сработать специализированные компьютерные архитектуры?

Ответ прост: нет, не смогут. Алгоритмы там везде разные, поэтому работает теорема бесплатного обеда: тот вычислитель, который хорош для одних задач, будет ужасен для других задач. Так что нейровычислитель будет хорош только "в среднем по больнице". И мы увидим в ближайший десяток лет ещё много разного и чудесатого -- и аналоговые спецвычислители, и универсальные цифровые архитектуры (для препроцессинга и постпроцессинга видео, физических вычислений, логических вычислений, вероятностных вычислений, а также и для вычислений в deep learning). Жизнь уже интересна, счёт транзисторов пошёл на триллионы -- и спецвычислитель BigNeuro на триллион транзисторов может сделать команда из меньше чем 200 человек.

А пока болеем не за динамо и спартак, а за участников этого чемпионата искусственных мозгов -- aNLI, https://leaderboard.allenai.org/anli/submissions/about. Это продолжатели дела CYC, они хотят закодировать common sence, здравый смысл. И сделали на эту тему соревнование. Рассказ про abductive commonsence reasoning -- https://arxiv.org/abs/1908.05739. У людей в этом соревновании 92.9% правильных ответов. У нейросетки BERT Large Finetuning -- 66.75%. У CYC (там ведь как раз цель соревнований была дизайн-целью) -- неизвестно, у IBM Watson (это ж победитель "Jeopardy!", по сути это ж то же самое) -- неизвестно. Но там много-много лет ручного кодирования знаний, а BERT тренируется, как мы знаем, за 53 минуты (грубо говоря, читает за это время в себя если не всю Библиотеку Конгресса, то сравнимый объём текста). А ещё было бы забавно увидеть соревнующимися там не только нейросетки и логические вычислители, но и людей. Скажем, команда победителей что-где-когда сколько бы решила в этом соревновании? Не смогла ли выдать больше ли 92%? С другой стороны, и это соревнование тоже ни о чём: нобелевские лауреаты и крутые политики обычно не эрудиты, а эрудиты и другие победители викторин не так уж и заметны в других сферах жизни. Но мы всё равно болеем.

Но причём тут Big Neuro и решение задач, объявленных в этом соревновании по использованию здравого смысла в рассуждениях? Напомню тезис Rich Sutton (http://www.incompleteideas.net/IncIdeas/BitterLesson.html): прогресс в AI определяется доступной вычислительной мощностью при простых алгоритмах. Размер решает. Текущая самая большая нейросетка GPT-2 8B пока всего в 24 раза больше BERT, текущего победителя соревнования по объяснениям на основе здравого смысла. И хотя понятно, что с этой архитектурой существенно улучшить результат не удастся, то альтернативные более успешные архитектуры вряд ли будут с меньшим количеством вычислений. IBM Watson, победивший в Jeopardy! -- это прежде всего суперкомпьютер! Big Neuro таки решает, а если там пойдёт ещё и Big Simulation и Big Logic, которые сольются в какой-то момент в Big Evolution Multi-engine, то аж дух захватывает, что может получиться!

UPDATE: обсуждение в фейсбуке -- https://www.facebook.com/groups/nevronet/permalink/1406594802840170/

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

А эволюция съест всю вычислительную мощь, которая доступна, и ещё потребует. Так что радуемся и имеем дело с Big Neuro и Big ВсёОстальное.
2019

Онтика системного мышления, 2019

Системное мышление в 2019 уже не одинокая методологическая дисциплина, поэтому часть понятий, которые я включал в её онтику в момент создания учебника ("Системные мыслемы", июль 2016 -- https://ailev.livejournal.com/1278600.html), можно выкидывать. Содержание нужно тоже подправить, после выхода учебника в феврале 2018 года я написал довольно много уточнений в блоге и чате поддержки курса, и кое-что нужно было бы включить -- но кое-что можно было бы опустить, оставив для специальных курсов.

А ещё можно упростить терминологию примерно по тем же основаниям, что я упрощал русскоязычную терминологию архимейта в версии 1.1 в июле 2015 (https://ailev.livejournal.com/1205591.html) и опыту использования этой русификации. Мало кого волнует, что терминология точно соответствует инженерным стандартам и публичным документам. Концептуальная точность остаётся, а вот терминология должна быть развёрнута в сторону масштабирования: лёгкой для запоминания и говорения, а не точным переводом терминологии стандартов. Вместо двусложных терминов выбираем односложный, вместо канцеляритных -- неформальные, а лучше и вообще сленг, чтобы "как в учебнике, так и в жизни" (а не в "как в стандарте, так и в учебнике"). Опыт перевода Архимейта показывает, что пользы от такого подхода больше, а желающие опереться на стандарты всегда могут взять англоязычные оригиналы и использовать их. А уж опираться на русскоязычную терминологию переводных ГОСТов -- это вообще последнее дело, пусть этим занимаются люди, которых волнует не мышление, а военная приёмка.

Поэтому "я это породил, я это и буду исправлять". Вот мои текущие соображения:

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

2. В курс вычислительного мышления (операции с моделями там!) уходят: частное описание (view), метод описания (viewpoint), модель, вид модели -- мета-модель, множественность описаний: мультимодель, мегамодель, прожекторный и синтетический подходы к описанию. Как ни удивительно, 42010 оказывается не столько системным стандартом, сколько стандартом информатики (опирающимся на онтологику в части соотношения моделей и мира). С этим нужно отдельно ещё поразбираться, в этом месте пока всё мутно. Вообще, курс вычислительного мышления требует к себе повышенного внимания, ибо в нём в том числе и вся тематика AI (алгоритмы искусственного интеллекта, в том числе работа с коннективистскими моделями).

3. Воплощение системы против описания системы [трудный момент: definition становится описанием, а description -- документацией. Это может вызвать проблемы с пониманием старых текстов. Но говорить так становится в разы проще]
-- воплощение системы против описания системы
-- системы против систематики ("система Линнея") и методологии ("система Станиславского")?
-- уровень системы как части системы-холона: целевая система как точка отсчёта, надсистема [было: использующая система] и подсистема. Элемент системы. [Можно подумать, оставлять ли понятие холона, или просто давать сразу систему вместо холона, и системную иерархию/декомпозицию по системным уровням вместо холархии]
-- системы в окружении [было: операционном. Можно было бы назвать "рабочее окружение", но проще опустить квалификатор окружения вообще. Окружение -- всегда в момент работы/функционирования/эксплуатации/использования. Слово "контекст" тут хуже, ибо "контекст" -- это операционный против обеспечения. Среда хуже, ибо окружение вокруг аттрактора внимания -- целевой системы, а среда не имеет центра]
-- системы в обеспечении [было "обеспечивающая система", но тот же тип преобразования, что в окружении ***тут нужно бы тоже назвать покороче, но непонятно, как. Обеспечение тут -- альтернативное название оргзвеньев, выполняющих ЖЦ: выполняющих практики обеспечения и работы обеспечения. См. ЖЦ)
-- именование системы по типовой основной функции (назначению) в момент эксплуатации
-- системная схема: связь целевой системы, надсистемы, системы в окружении, системы в обеспечении (ошибки: "объективная система", неверность в определении границ системы, "принцип почтальона" по слишком далёкой надсистеме, пропущенная надсистема -- "мужчина использует женщину", игнорирование команды: система в обеспечении как целевая, подсистема как целевая)
-- проектная система [***сейчас иногда говорят "проектируемая система", system under design. Но она не только проектируемая, но изготавливаемая, и эксплуатируемая и т.д.! У нас же говорят про подобные системы, что они реализуются по "частным техническим заданиям". Это по факту "мой винтик в целевой системе, я сделяль" -- стейкхолдерский фокус личного подпроекта того стейкхолдера, который пытается рассуждать системно про весь проект. В прошлой онтике этого не было. Введено по образу и подобию "жизненного цикла проекта" как части жизненного цикла, ограниченного рамками проекта. По сути, речь идёт о какой-то выделенной подсистеме целевой системы, или (под)системе из какого-то обеспечения.]
-- проверка и приёмка (описания и системы, описания и описания при моделеориентированности)

4. Роли, их интересы и оформляющие их описания
-- Роли [было стейкхолдеры], определяемые по отношению к системе. Конечно, одновременное использование словосочетаний "роль архитектора" и "архитектор -- это роль" ("роль Принца Гамлета" и "Принц Гамлет -- это роль") для онтологов звучит кривовато, но "интересант" и "роль интересанта" оказывается не лучше "стейкхолдера". Принц Гамлет -- это действующее лицо/интересант, и у него есть роль в пьесе, конечно. Но используем метонимию (действующее лицо/интересант с его ролью -- роль), ибо в речи это всё должно быть ОК. И даже в архимейте внутренние стейкхолдеры -- это roles. Внешние роли в проекте и внутренние роли проекта (опять же, роли "в проекте" или "проекта" -- нужно обсуждать, но интуиция подсказывает, что внешние почему-то "в проекте", а внутренние -- "проекта"). Ошибки: исполнители, оргзвенья [было: ответственные], звания, большие организации, пропуск антиклиентов.
-- интересы (и аспекты как группы интересов)
-- целокупность и эмерджентность для уровней системы (смена интересов и ролей для уровней)
-- успешная система
-- описание (definition) как ответы на интересы, безусловное существование описания
-- документация системы (description) [было -- описание. Это может быть предмет путаницы при переходе на новую версию терминологии] как рабочий продукт, необязательность существования документации
-- потребности (ролей [было -- стейкхолдеров])
-- требования / стратегия -- описания чёрного ящика
-- дизайн -- описание прозрачного ящика
-- ограничение -- описание прозрачного ящика

5. Функциональное [слово "компонента" убираем] против конструктивного/модульного, размещения
-- минимальное число видов описаний: функциональные, модульные, размещения
-- функциональный элемент, порт, связи [*** плохо, что два слова "функциональный элемент" и "элемент" тут вполне может быть далее декомпозируемым, а не именно элементом. Связи могут быть потоками]
-- функция [как поведение функционального элемента, имеющее назначение в надсистеме -- на языке надсистемы]
-- функциональная декомпозиция [не анализ!]
-- сервис [как поведение модуля на интерфейсе, имеющее значение в целевой системе -- на языке системы]
-- модульная диаграмма (стека интерфейсов, платформенного стека), функциональная диаграмма (принципиальная схема)
-- модуль, интерфейс. Конструкция, модульная декомпозиция.
-- размещение
-- совмещение функционального элемента и модуля
-- архитектура
-- архитектурное решение
-- архитектурное требование
-- архитектурная документация [было: архитектурное описание] описание
-- архитектурный синтез [логическая и физическая архитектура -- убираем]

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

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

Пример "перевода с русского на русский" -- как будет звучать "суть системного подхода в одном абзаце" из https://ailev.livejournal.com/1469354.html:

Сейчас: чтобы удовлетворить потребности внешних стейкхолдеров, нужно понять принципы функционирования и возможную конструкцию использующей системы и тем самым сформулировать функциональные и интерфейсные требования к целевой системе. Затем выполнить эти требования, для чего разработать архитектуру и затем воплотить в жизнь конструкцию целевой системы. А для этого нужно применить практики жизненного цикла целевой системы, организовав компетентную команду обеспечивающей системы и снабдив эту команду всеми нужными технологиями. И всё это нужно делать рекурсивно, для всех подсистем целевой системы.
Будет: чтобы удовлетворить потребности внешних ролей в проекте, нужно понять принципы функционирования и возможную конструкцию надсистемы и тем самым сформулировать функциональные и интерфейсные требования к целевой системе. Затем выполнить эти требования, для чего разработать архитектуру и затем воплотить в жизнь конструкцию целевой системы. А для этого нужно применить практики жизненного цикла целевой системы, организовав компетентную команду в обеспечении системы и снабдив эту команду всеми нужными технологиями. И всё это нужно делать рекурсивно, для всех подсистем целевой системы.
* * *
Тут всё пока очень сыро и очень спорно и по составу онтики, и по заменам терминов. Но release early, release often -- лучше опубличить и пообсуждать сейчас, чем переделывать толстые книжки потом. Я буду возвращаться к этому посту и редактировать его по мере возникновения понимания. Особо проблемные места обозначены через ***. Так, замена "определение --> описание" и "описание --> документация" явно хороша, но теряется совместимость с уже написанным. Плюс "онтология -- онтологическое описание", "архитектура -- архитектурное описание" неожиданно становится "онтологией (онтология -- это уже описание!) -- онтологической документацией" и "архитектурой (уже описание!) -- архитектурной документацией". Но создать/описать/define архитектуру -- это тогда чётко отличается от документировать архитектуру.

А когда пыль от этой работы осядет, нужно будет выпустить вторую редакцию учебника "Системное мышление".

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

Модели требований/целеполагания пока проигрывают в популярности архитектурным моделям

Вчера прошло совместное заседание методсовета ШСМ и русского отделения INCOSE, где обсуждали SysArсhi (https://ailev.livejournal.com/1444887.html). Большинство вопросов было к мета-модели SysArchi в части требований/целеполагания (в ней части хорошо видны -- сиреневенькая часть относится к модели требований/целеполагания, жёлтенькая к архитектуре предприятия, зелёненькая -- архитектуре целевой системы):
SysArchi_nov18

Видео всего заседания -- https://youtu.be/yTa9UrjQgd4. Утверждённое соглашение о моделировании SysArchi версии 1.0 -- https://yadi.sk/i/zhht0RshtJzyMQ

Мои выводы:
-- разговор про архитектуру и архитектурные описания (спасибо ISO 42010, IEC 81346 и т.д.) уже более-менее все поддерживают. И более-менее понимают про 4D экстенсионализм. И что целевая система и обеспечивающая система неразрывны и должны бы моделироваться вместе.
-- модели требований не понимает никто. В головах только понятия "требования" и где-то далеко от них понятие "стейкхолдер". Далее идёт неясная цепочка понятий, где выделяются "потребности". Что трассировка потребностей к требованиям впрямую не может быть осуществлена (там же граница системы по пути! Изменение стейкхолдеров и их viewpoints/языка, разные свойства разных систем) признаётся, но про механизмы моделирования этого никто не знает. Поэтому уйма вопросов,

Итого:
-- соглашение о моделировании утвердили в текущей версии (обозвали её версией 1.0 и призвали духов природы продолжать работать над следующими версиями -- вдруг откликнутся?), равно как и отметили, что SysArchi в его текущем виде мало поможет в больших проектах, и что мало кто может внести в эту метамодель что дельное (а что там лишее -- так запросто можно не использовать. Например, не использовать моделирование требований вообще). Дальше внимание нужно уделять SysMoLan (https://ailev.livejournal.com/1443879.html).
-- мне нужно что-то делать, чтобы в головах появилось не только представление об архитектуре и основных архитектурных решениях, но и представление о целеполагании.

GORE -- goal-oriented requirements engineering, это как раз то, что требует моделей требований. Я когда-то много об этом писал: https://ailev.livejournal.com/811715.html (2010 год), и это был фронтир (https://ailev.livejournal.com/900086.html), но за прошедшее время моделирование требований прошло по факту в мейнстрим, и даже в определении системной инженерии начали говорить не только о раннем по жизненному циклу определении/описании потребностей (stablishing stakeholders’ purpose and success criteria, and defining actual or anticipated customer needs and required functionality, early in the development cycle), но и документировании и моделировании требований: https://ailev.livejournal.com/1453390.html. Тем самым GORE и MBCD начинают смешиваться до неразличения -- и это поставлено как проблема в инженерии требований, см. соответствующий раздел в https://ailev.livejournal.com/1425741.html

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

Работа с целями обеспечивающих систем (в инженерии предприятий, по факту это практики стратегирования) -- это модели целеполагания, motivation models (например, стандарты OMG BMM, business motivation model, или OpenGroup ArchiMate 3.0 motivation extention).

Системность SysArсhi была в том, чтобы
-- моделировать целевую систему в её операционном окружении и обеспечивающие системы в рамках одной модели. И рамках одной же модели и с одинакомым подходом делать моделирование требований/целеполагания для целевой системы и для обеспечивающей (например, использовать эти модели для проведения business/mission analysis -- понимать, насколько участие в проекте какой-то целевой системы связано со стратегией предприятия обеспечивающей системы).
-- убрать дребезг, возникающий при моделировании сразу нескольких системных уровней (когда в зависимости от уровня кого-то называют то "член команды", то "(внешний) стейкхолдер" или одно и то же описание то "потребностью/требованием стейкхолдера", то "системным требованием". В Архимейте всё это одноуровнево, поэтому полно этих разделений на "внутренний-внешний". Поэтому значок используем один: "требование", а уж как его разные команды назовут (требование, потребность, ограничение/архитектурное решение) -- это уже зависит от того уровня, которым занимается команда, как целевой системой.
-- моделировать на одной диаграмме все важные описания: не только архитектурные описания, но и архитектурные потребносити/требования/стратегию (архитектурные, то есть ведущие к архитектурным решениям, потому как для детальной инженерии требований все эти визуальные языки -- слону дробина, см. подробней книжку "Визуальное мышление. Доклад о том, почему им нельзя обольщаться", там я об этом подробно написал: https://ailev.livejournal.com/1437344.html). Вот модель целеполагания и попала в мета-модель.

Архимейт этого всего не позволяет сделать как-то приемлемо, конечно, но цели были именно такими. Так что тамошний обрывок модели требований/целеполагания -- это как раз попытка отразить последний пункт, добавить язык моделирования требований в архитектурный язык. Конечно, возникает большое количество вопросов к самой модели целеполагания именно АрхиМейта (она не была существенно поправлена в SysArchi), но предназначена она именно для того, чтобы требования брались как-то обоснованно, с учётом какой-то цепочки моделирования ситуации в системном окружении, ведущей к системным требованиям.

Основные различения для этого моделирования заключаются в понятиях стейкхолдер, интерес, оценка интереса, цель, принцип/дисциплина, требования. Увы, большинство обсуждающих пытаются вообразить, что бы там могло скрываться за этими обыденными словами (их не волнует обычно, что в английском для "цели" могли бы быть target, goal, object, objective, aim и даже mark, purpose и end, и это ещё не конец списка -- да и по-русски тоже есть много чего, включая канцеляритную "целеустановку". Но очень редко "мишень", хотя в английском target тут вполне немилитаристски слышится). Со словом "интерес" (concern) вообще беда. Но в данном случае непонимания моделей требований упирается не в эту игру содержанием слов (см. "слова-термины важны, и слова-термины неважны" -- https://ailev.livejournal.com/1442764.html), а именно с непониманием самой идеи моделирования требований, обсуждаемых там сущностей-концептов.

Вот онтика системных описаний, где подробно прописаны понятия интереса и оценки интереса -- https://ailev.livejournal.com/1429330.html. В том числе там прописано отличие интереса (concern) и метода описания (viewpoint). Это самая частая ошибка моих студентов. Понятие дисциплины (из которой берутся принципы, как закономерности дисциплины, и для выражения понятий которой существует метод описаний) -- вот тут: https://ailev.livejournal.com/1427265.html. Дисциплина нам важна, как что-то, позволяющее адекватно моделировать интерес. Интерес -- это просто функциональное обозначение какой-то предметной области, необходимой стейкхолдеру для его деятельности. Он для удовлетворения своего интереса он выбирает (или ему предлагают!) какую-то дисциплину и связанный с ней метод описания объектов этой дисциплины. И далее уже описывается, что там с оценкой интереса в данном проекте. То есть "хотелка" это не интерес, а как раз оценка интереса! А цель -- это переход в действие, что нужно сделать (глагол), чтобы сдвинуть оценку интереса. Результирующие требования описываются в терминах выбранной дисциплины (и если вы не читали учебники по дисциплинам, отвечающим на те или иные интересы проекта, то вам этих требований обычно не понять. Ну, или вы просто не учтёте этих требований, потому как не знали о них! Помним, что требования открывают/discover или выявляют/elicit, а не "разрабатывают" -- сидя на диване, их не "сочинишь").

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

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

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

Онтологии и SysMoLan

Очередной заход к онтологии системной инженерии, ST4SE (semantic technologies for systems engineering): https://sercuarc.org/wp-content/uploads/2018/06/SE-Ontology_Smith_slides.pdf -- осторожно, там 318 слайдов, презентация декабря 2017 года (видно в "свойствах" файла). Это всё на базе BFO 2.0 в OWL (basic formal ontology, это upper ontology от Barry Smith) -- http://basic-formal-ontology.org/. Все примеры госфинансированы: биология, экология, военные. Подчёркивается авторитарный характер этих онтологий. На BFO порядка 250 таких проектов. В презентации традиционные попытки определить понятия system, lifecycle, capability, function, service и т.д.. -- на базе различалок BFO.

Ещё один подобный заход -- это IOF (industry ontology foundry, предметная область промышленного производства, проект начали в 2016 и готов кусочек на 600 сущностей) на SKOS с участием того же Barry Smith: https://ws680.nist.gov/publication/get_pdf.cfm?pub_id=925807, формальный сайт https://sites.google.com/view/industrialontologies/home.

В мире ISO 15926 тоже всё вяло, но проистекает: в этом году вышла часть 12, ISO/TS 15926-12:2018, Life-cycle integration ontology represented in Web Ontology Language -- https://www.iso.org/standard/70695.html.

Небольшой обзорчик по информационному моделированию и онтологиям (семантическим информационным моделям, как они там пишут) в системах автоматизации зданий знает про ISO 81346, но даже не поминает BFO, IOF, ISO 15926 -- https://www.researchgate.net/publication/321983944_A_survey_on_information_modeling_and_ontologies_in_building_automation

А ещё помним про knowledge graph и связанные с ними всякие SMART-DOG (Strathclyde Mechanical and Aerospace Research Toolbox for Domain Ontology Generation) https://blog.grakn.ai/semi-automatic-generation-of-a-reliable-knowledge-graph-for-space-mission-design-with-grakn-c96061eee2a3 -- имя этим проектам легион, там просто нет "официальной и большой" upper ontology, по большому счёту речь идёт об инженерных онтиках, и инженерных моделях данных (тех же онтиках). Их тьма.

Годы идут, а болото стандартов (standard quagmire) и не думает осушаться. Вот тут мои замечания 2010 года на этот счёт -- "стандарты каталогизации", https://ailev.livejournal.com/852642.html, и там дальше по цепочке ссылок на другие посты про стандарты производства-в-большом, кодификацию, каталогизацию, идентификацию, характеризакцию, классификацию. Похоже, ничего не изменилось, кроме необходимости в этих стандартах определять ещё и слово capability -- оно по-своему определено в каждом стандарте, равно как и слово service, так что улучшения ситуации не произошло.

Весь этот подход с необъятными upper ontology и reference library оказывается невзлетающим: профи разных предметных областей вдруг обнаруживают, что есть кроме их знания стандартов ещё и "нормативное знание", которое нужно выучить, чтобы разобраться с чьим-то чужим знанием. Бабах! Вместо знания своих стандартов и разборки с чужим нужно ещё и выучить "нормативное знание" -- не на уровне кругозора, а на уровне полного знания! А поскольку mapping делается не через попытку совместить смысловые пространства двух наборов концептов в их употреблениях в каких-то текстах (как это делается, например, в работах по переводу с одного языка на другой), а через попытку ручного сведения к отношениям род-вид с настаиванием на последующей возможности формально-логических рассуждений -- то легче не становится, работу эту могут выполнять только эксперты, но обязательно с приглашением онтологов. То есть задача федерирования данных с использованием справочных данных с учётом upper ontology становится не проще, она становится сложней и дороже. Но правительство всё окупает деньгами налогоплательщиков, и дальше идёт уже пиар этих сложностей.

Но если ты собираешься делать SysMoLan Studio, то все эти работы хорошо бы знать: они являются коллекцией тех граблей, на которые можно наступить. При этом системный язык в инженерии можно понимать как хочешь:
-- управление конфигурацией системы, то есть регистрация функциональных, конструктивных, пространственных частей системы и их описаний. IEC 81346 и связанное с ним версионирование/registry. Первые PDM были ровно для этого: не потерять ничего, что творят проектировщики/конструкторы. Описать систему -- выдать сводную заказную спецификацию для системы и передать её куда-то в ERP, систему планирования производства и т.д.. Чтобы в спецификации было что-то кроме кодов, вводится аннотирование. В отчётах -- таблички. Вся информация о компонентах, модулях, местах -- в файлах. SysMoLan для такого использования -- это язык аннотации обозначаемых кодами IEC 81346 объектов, а Studio должна генерировать Excel-таблички. Ура, "системный язык готов".
-- выражение архитектурных решений, то есть демонстрация совмещения функциональной, модульной и пространственной структур. Это означает, что упор делается на какую-то трассировку соответствующих объектов друг ко другу по заранее предписанным отношениям и формализации способов аннотации. Получаем варианты SysMoLan типа SysML или ArchiMate, кому что больше нравится. Дальше можно извлечь объекты и получить спецификацию из предыдущего пункта.
-- Но можно пройти на шаг дальше и научиться трассировать схемы принципиальные/технологические к каким-то 3D моделям прежде всего. Это PLM-системы датацентрические, и в такую PLM уже непосредственно втыкаются CAD, чтобы сама трассировка была "автомагической" -- схема данных такой PLM по сути дела представляет системный язык. ISO 15926 представляет собой попытку сделать ровно вот такой системный язык "интеграции данных жизненного цикла", независимый от конкретной PLM (а во многих реальных PLM просто по факту использовались предварительные наработки по ISO 15926 в их версии 1997 года). А язык типа SysML или ArchiMate там есть? А как же! На нём рисуется "логическая архитектура" перед тем, как поручить те или иные части системы спроектировать в CAD и после готовности материалов из CAD они трассируются к созданным объектам. Беда только в том, что это идеальная конструкция не выживала в силу монструозности: PLM системы существовали и существуют, с болью интегрируя результаты работы различных CAD и систем моделирования прочности и мультифизики (а это не системная инженерия, а инженерия по специальности), а рядом появляются "системноинженерные системы" на базе каких-то вариантов архитектурных языков. И эти системы в особо крупных военных проектах выживают, но не слишком интегрируясь с PLM, а в не особо крупных проектах так вместо них используются просто тематические CAD (типа редакторов принципиальных схем и технологических диаграмм, крепко адаптированных для конкретной предметной области). Можно поглядеть ещё на аналогичную жизнь в архитектуре предприятия: архитектурные диаграммы (почему-то сразу предполагается графическая/диаграммная форма!) предприятия (например, на ArchiMate) просят не путать с архитектурными описаниями (чаще всего тоже диаграммами, причём на UML) софта, оговаривают их неподробность (типа "идите в BPMN и другие стандарты/моделеры за подробностями"), но почему-то делают сверку архитектуры IT-решения с СMDB (база данных менеджмента конфигурации для IT-службы). По факту архитектура предприятия трассируется и к следующему уровню инженерных решений "с подробностью, достаточной для изготовления", и оказывается частью управления конфигурацией (ибо новые объекты прежде всего появляются в ней). Ну, и современные варианты архитектуры предприятия включают в себя бизнес-архитектуру и целеполагание -- в "обычной" системной инженерии это требования. Прикасаешься к архитектурному языку, тут же огребаешь и потребности-требования, и управление конфигурацией, и (с учётом всех трассировок) PLM с её вечной задачей мэппинга различных видов CAD и необходимостью иметь "генератор конверторов" прямо из коробки.
-- ... тут ещё много идей, что считать "системным языком". Например, это онтологический язык, в которой понятие "система" является центральным для управления вниманием, а онтология понимается как раз как чеклист для управления вниманием: мир в этой онтологии состоит не из объектов, а из систем, и эти системы сразу по-разному описываются разными стейкхолдерами, исходя из их интересов. Это ничего не добавляет, но обозвал же Ян Диец свои архитектурные соображения по устройству организации "онтология предприятия", и Захман тоже назвал свой архитектурный подход "онтологией предприятия" -- вот и SysMoLan можно обозвать systems ontology со всей сопутствующей дискуссией про то, как переводить -- "онтология систем" или "системная онтология" (победит "системная онтология"). И да, не забыть всунуть в эту онтологию соображения Диеца и Захмана -- ибо нужно описывать не только целевые системы, но и обеспечивающие! SysMoLan должен и архитектуру предприятия описывать! Так что учитывать нужно не только инженерные онтологии, но и менеджерские/организационные.

В любом случае от обсуждения онтологического статуса объектов SysMoLan не уйти. По факту SysMoLan должен быть какой-то системной (системноинженерной и системноменеджерской) онтологией и моделью данных. Это означает, что:
а) нельзя выдумывать эту онтологию из головы. И нужно как-то вписываться в текущие онтологические наработки. Понятия брать из инженерных стандартов, а вот что там в части upper ontology и какой там уровень формальности -- это нужно тщательно выбирать. Успех ArchiMate IMHO в том, что там существенно смягчённые онтологические нормы. Впрочем, SysML в этом плане не хуже. SysMoLan должен быть суперкомпактен, ибо даже ArchiMate считают излишне богатым. SysMoLan не должен быть полноценным онтологическим языком, в котором из коробки достаётся BFO и/или ISO 15926 и/или IOF, и/или даже ST4SE -- это угробит проект на старте. Он должен быть суперкомпактным для очень узкого круга задач, минимального числа сценариев. Но этот суперкомпактный язык онтологически должен быть получше ArchiMate и SysML -- иначе зачем мы его делаем?! Нас же в текущих языках не устраивает именно отсутствие онтологии системного подхода! И это Сцилла.

б) Харибда в том, что к архитектуре тут же захочется трассировать все остальные описания (например, архитектурные расчёты), и страстно захочется PLM с развитым мэппингом, и SysMoLan Studio окажется эпицентром в каком-то Smart Data Lake со всеми вытекающими. Если делать SysMoLan как DSL на Julia, то это не выглядит чем-то страшным, но это хорошо бы предусмотреть на старте. Если уж сказал слово "онтология", то мэппинг у тебя будет -- для других целей обычно без этого слова обходятся. Тут системная онтология отходит на десятый план и на первый план выходит обычное моделирование данных -- вся дискусссия из https://www.infoq.com/news/2018/10/das-modern-data-architecture (это William McKnight on Data Platforms and Creating a Modern Data Architecture) к нам в гости. И фраза из презентации Barry Smith по первой ссылке текущего поста о том, что "онтологические вопросы сводились к вопросу о моделировании данных, это и губило проекты" (ну, или наоборот, позволяло проектам выживать -- никто ж не знает!).

в) А есть больше чем Сцилла и Харибда: в тот момент, когда захочется что-то делать с самой архитектурой -- все эти search-oriented architecture, differential architecture. Закладываться сразу на это? Так в этом никто ничего не понимает. Но современный архитектурный язык должен ползти как раз в этом направлении. И онтология SysMoLan тогда должна быть современной, на вероятностной логике -- тоже, желательно, "из коробки". Иначе риск унаследовать всю головную боль с болотом онтологических стандартов. Я рассматриваю текст про language models, knowledge graphs, relational models https://ailev.livejournal.com/1449229.html ровно по этой линии, заодно решая проблему мэппинга инженерных описаний как проблему перевода с языка на язык. Но это абсолютно исследовательское направление в абсолютно неизведанных водах, когда это всё дойдёт до практики -- непонятно, каких это потребует ресурсов -- преогромных. Но зато полный фронтир и есть чем хвастаться. Из минусов -- за это никто не заплатит, если не найдётся какой-то меценат. Не в России, конечно. И такой меценат не найдётся. То есть в ближайшей перспективе года-двух это утопия, но уже в трёхлетней перспективе differentiable architecture будет очень, очень горячей темой -- и если заняться сейчас, то через три года будем в эпицентре (но кушать эти три года будет совсем нечего, в этом-то и утопичность: "невозможность" и "крайняя привлекательность" одновременно).

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

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

Описание проекта SysMoLan Studio -- https://ailev.livejournal.com/1446524.html, и там есть все нужные ссылки, чтобы понять проект.
2011

SysMoLan Studio

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

Текущие языки системного моделирования (SysML, AADL, Capella для моделирования целевых систем, UML для моделирования программных систем, ArchiMate для моделирования предприятий, SyM для связи системного и мультифизического моделирования в Modelica) не дают этих возможностей. Проект SysArchi, предпринятый Русским отделением INCOSE в 2018 году показал, что системное моделирование целевых и обеспечивающих систем в рамках ArchiMate 3.0 крайне неудобно, а традиционных языках системного моделирования по факту невозможно моделировать предприятие.

Исследовательский проект .15926 TechInvestLab по созданию моделера и платформы инженерного моделирования на базе инженерной онтологии и форматов языка ISO 15926 показал неудобство работы с низкоуровневыми представлениями для концептуального моделирования и подчеркнул необходимость использования языка программирования как для описания моделей, так и для манипуляций с моделями (создание моделей, запросы к модели). Сам проект .15926 имел акцент на создание системы мэппинга (интеграции данных) инженерных моделей, полученных в составе различных систем и меньше уделял внимание на аспектах создания системных моделей инженерами. В то же время проект .15926 показал, что программное создание объектов моделирования и представление моделей систем в текстовом и псевдографическом виде очень и очень перспективно, графические же представления "визуального моделирования" ограничены в их использовании. Это положение примата текстового представления для манипулирования большими и подробными моделями было подробно обосновано в книге А.Левенчука "Визуальное мышление. Доклад о том, почему им нельзя обольщаться". Проект по моделеориентированному концептуальному проектированию с использованием визуальных представлений на ArchiMate и манипулированием этими представлениями из языка R показал перспективность подхода использования языка программирования для работы с архитектурными системными моделями так же, как .15926 показал это для моделей интеграции инженерных данных (проект описан в книге В.Мизгулина "Системный инженер. Как начать карьеру в новом технологическом укладе").

По итогам этого исследовательского проекта TechInvesLab и русское отделение INCOSE в 2015 году выступили с инициативой создания языка системного моделирования SysMoLan, который преодолеет недостатки существующих архитектурных языков и сможет как синтаксически удобно выражать знания по структурам целевой и обеспечивающей системы, так и решать задачи интеграции данных (мэппинга различных инженерных моделеров).

В 2018 году эта инициатива получила развитие: было предложено реализовать SysMoLan как встроенный предметно-ориентированный язык (DSL) в рамках языка технических вычислений Julia. Этот же выбор сделали авторы языка инженерного моделирования Modelica, создавшие DSL Modia в Julia. Выбор Julia как хост-языка для языка системного моделирования помогает решить множество задач, плохо решаемых при других архитектурных решениях: проблемы расширения системного языка, взаимодействие различных видов инженерных моделей и моделей предприятия, наличие языка запросов к создаваемой модели, возможность оптимизации моделей (дифференцируемое программирование).

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

Предлагается создать SysMoLan Studio, представлящую из себя моделер и платформу системного моделирования для целевых и обеспечивающих систем. Моделер этой системы "из коробки" должен поддерживать ведение системных холархий (breakdown structures: system, product, work, etc. -- в соответствии со стандартом IEC81346) и описания входящих в них систем, в то же время предоставляя возможность для верхнеуровневого (архитектурного) описания систем и подсистем, входящих в эти холархии в соответствии со стандартом ISO42010. Первоначальный акцент в моделировании будет на создание структурных моделей целевых и обеспечивающих систем, а не на задачи мэппинга. Проще всего думать о SysMoLan Studio как об "Archi для системного языка", но в отличие от Archi там будет:
-- высокоуровневый язык системного моделирования SysMoLan, в котором удобно моделировать архитектуры и потребности/требования как целевых систем, так и обеспечивающих систем
-- параллельное представление на текстовом DSL-в-Julia и псевдографических отображениях (двустороннее "связывание данных", как в модели MVVC).
-- консоль работы с моделью с полноценным языком Julia для аналитических приложений, интеграции данных инженерных моделей, расширений SysMoLan, подключения альтернативных представлений и т.д.

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

Подробности:
-- цепочка текстов "SysMoLan" -- https://ailev.livejournal.com/1443879.html
-- проект "студии" -- https://ailev.livejournal.com/1280626.html (и там trainer studio, systems engineering studio, conceptual studio)
-- .15926 Editor and Platform -- https://github.com/TechInvestLab/dot15926
-- SysArchi -- системное моделирование в ArchiMate 3.0 -- https://ailev.livejournal.com/1444887.html
-- В.Мизгулин, "Системный инженер. Как начать карьеру в новом технологическом укладе" -- https://www.litres.ru/vyacheslav-mizgulin/sistemnyy-inzhener-kak-nachat-kareru-v-novom-tehnologicheskom-uklade/
-- А.Левенчук, "Визуальное мышление. Доклад о том, почему им нельзя обольщаться" -- https://ailev.livejournal.com/1437344.html
-- поиск-ориентированая инженерия -- https://ailev.livejournal.com/1122876.html
2011

Доклад "SysArchi -- системное моделирование в ArchiMate 3.0"

Прочёл сегодня из Москвы по скайпу в Нижний Новгород двухчасовой доклад "SysArchi -- системное моделирование в ArchiMate 3.0" в рамках семинара НИУ ВШЭ «Дни Инженерии организаций», проводимого факультетом информатики, математики и компьютерных наук. Студенты там в новом учебном году будут знакомиться и с курсом "Системное мышление", так что им это содержание более чем актуально. Аудиовидеозаписи не велось. Но вот слайды (https://www.slideshare.net/ailev/sysarchi, для спасающихся от Роскомпозора https://yadi.sk/i/9LL1WtvOgcjwZA):

Драфт текущей версии соглашения о моделировании SysArchi (оно сейчас активно обсуждается) -- https://yadi.sk/i/DgjcxXh3yPjQIA. Update: версия 1.0 -- https://yadi.sk/i/zhht0RshtJzyMQ, обсуждение модели требования/целеполагания -- https://ailev.livejournal.com/1454948.html

SysArchi, или "системный Архимейт" это стиль программирования на ArchiMate 3.0 (http://pubs.opengroup.org/architecture/archimate3-doc/), помогающий явным образом опереться на понятия системного подхода при моделировании не только организационных систем, но и их целевых систем по тем же принципам, что декларируются в подходе моделе-ориентированной системной инженерии (Model-Based Systems Engineering, MBSE) с использованием архитектурных языков SysML, AADL и др.. При этом моделирование на Архимейте ещё и обеспечивающей системы (жизненного цикла, вместо традиционно использующихся тут языков ситуационной инженерии методов OMG SPEM, OMG Essence, ISO 24744, но также и структуры ролей и организационных мест предприятия) обеспечивают полноту системного моделирования в инженерном проекте.

Этот стиль подразумевает полное и свободное использование возможностей, предусмотренных спецификацией языка, но при прямом моделировании понятий современного системного подхода подсказывает предпочтительные выборы элементов языка. Сам Архимейт частично системный язык (он в явном виде учитывает рекомендации ISO/IEC/IECC 42010:2011 по структурированию описаний системы), но довольно далёк от поддержки системного моделирования в общем виде, а также плох для создания моделей сложных целевых систем . Кроме того, Архимейт не слишком опирается на достижения современной онтологии, поэтому в SysArchi даются рекомендации, как обойти его ограничения.

Стиль моделирования SysArchi предполагается для использования его при совместном моделировании инженерных (целевых и использующих) систем и архитектуры предприятий (обеспечивающих систем). В системном подходе подчёркивается, что нельзя рассматривать архитектуру предприятия (обеспечивающей системы) вне целевой системы и её жизненного цикла, поэтому SysArchi применим и к «классическим» проектам моделирования архитектуры предприятия.

В сложных больших проектах архитектурного моделирования возможно использование всего полного набора элементов языка ArchiMate, а при необходимости более детального (не архитектурного) моделирования рекомендуется использовать другие языки моделирования (BPMN и т.д. – как это указано в спецификации ArchiMate). Но и в этих случаях следование рекомендациям стиля SysArchi для повышения зрелости системного моделирования остаётся предпочтительным.

После доклада были интересные вопросы, например о том, как бы сделать очередной заход на верхнюю онтологию в духе BORO для архитектуры предприятий. Мой ответ был в том, что нужно двигаться в направлении вероятностных онтологий и дифференцируемых архитектур, и в рамках работ над SysMoLan мы этим обязательно займёмся (https://ailev.livejournal.com/1443879.html). И вопрос про инструментальную поддержку SysArchi был в том же духе: этот стиль моделирования "проходной" (так же, как и ArchiEssence -- он у нас будет недолго), ибо из ArchiMate системный язык так просто не сделаешь. Вместо разворачивания экосистемы онтологически кривоватого SysArchi мы лучше наши усилия направим сразу на SysMoLan.
2019

Гибридный нижний уровень интеллект-стека

Сегодня нижний уровень интеллект-стека -- это аппаратура ускорения коннекционистских вычислений. Там всё очень бодро, кратенький обзор я дал в https://ailev.livejournal.com/1441034.html -- уменьшают время обучения, уменьшают время вывода, меняют физику аппаратуры.

А на среднем уровне интеллект-стека решают вопрос компьютерной поддержки полного спектра формальности мышления, https://ailev.livejournal.com/1438749.html -- логика и вероятность с causal inference и probabilistic programming, логика и коннекционизм с neural-symbolic computation/integration, дифференцируемая логика с relaxation representation до differentiable programming.

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

Направление это задано было когда-то Neural Turing Machine https://arxiv.org/abs/1410.5401 и Neral GPU https://arxiv.org/abs/1511.08228. И вот прямо сейчас появляется ворох новостей в этой области:

-- лучшая архитектура нейросетки для перевода естественных языков (Transformer) не могла выучить простейшее копирование строки (из abc получить abcabc). А "вычислительные нейросетки" типа Neural Turing Machine очень плохо работали с "образными задачами" типа перевода естественных языков. И вот сегодня Google Brain опубликовал Universal Transformer -- https://ai.googleblog.com/2018/08/moving-beyond-translation-with.html. Our experiments confirm that Universal Transformers are indeed able to learn from examples how to copy and reverse strings and how to perform integer addition much better than a Transformer or an RNN (although not quite as well as Neural GPUs). Furthermore, on a diverse set of challenging language understanding tasks the Universal Transformer generalizes significantly better and achieves a new state of the art on the bAbI linguistic reasoning task and the challenging LAMBADA language modeling task. But perhaps of most interest is that the Universal Transformer also improves translation quality by 0.9 BLEU1 over a base Transformer with the same number of parameters, trained in the same way on the same training data. Putting things in perspective, this almost adds another 50% relative improvement on top of the previous 2.0 BLEU improvement that the original Transformer showed over earlier models when it was released last year. The Universal Transformer thus closes the gap between practical sequence models competitive on large-scale language understanding tasks such as machine translation, and computationally universal models such as the Neural Turing Machine or the Neural GPU, which can be trained using gradient descent to perform arbitrary algorithmic tasks. Это явно шаг по направлению к гибридной архитектуре: добавление в коннекционистскую, нейросетевую архитектуру даже не эмуляции алгоритмических/символьных вычислений "по выучиваемым правилам", а "чего-то похожего на выучиваемые вычисления". Гибридный коннекционистский "образно-алгоритмический" субстрат с возможностью выучить какую-то алгоритмику оказался лучше чисто "образного".

-- а можно ли улучшить эту самую "вычислимость" в нейросетке? Ответ: можно, и это NALU (nerual arithmetic-logic unit), https://ailev.livejournal.com/1440139.html. Это тоже Google, но Google DeepMind. Всем настолько понравилась идея, что чуть ли не за сутки появилось множество реализаций этого подхода на самых разных deep learning фреймворках. А сегодня сделан интересный шаг: прокинуто множество системных уровней и сделана реализация NALU на ассемблере x86 -- http://rickyhan.com/jekyll/update/2018/08/15/neural-alu-implemented-in-python-and-assembly-x86.html. Красивая идея, "виртуальное железо" реализовывать поближе к нижнему уровню, a toy NALU implemented in x86(with SSE!) that uses real Intel FPU ALUs. Но я думаю, что это тоже ещё не предел: нужно чуток приподняться уровнем (например, писать эти "вычислительные" архитектуры на Julia, да ещё и запускать для этих архитектур нейроэволюцию -- оптимизируя и "алгоритмы", и "образы"),а результирующие архитектуры выводить не в ассемблер, а в LLVM. А затем использовать компилятор из LLVM в Verilog и сразу прошивать FPGA. Это уже делается для "традиционных сеток", которые несколько строк Питона для спецификации нейросетки в TensorFlow через компилятор XLA от Google перегоняют в LLVM, а затем из LLVM получают спецификацию на Verilog для FPGA -- https://arxiv.org/abs/1807.05317, подход LeFlow. К этому уже всё готово, так что в ближайшее время ждём реализации.

Вот эти два потока работ (1. усиление коннекционистской "образности" через коннекционистскую "алгоритмику" и 2. усиление и разгон через приближение к железу коннекционистской "алгоритмики") должны быстро склеиться. К тому же это всё может легко пройти под зонтиком Гугля (поглядите, все работы по факту оттуда), с редкими университетскими вкраплениями.

"Коннективизм" и "коннекционизм" -- синонимы, в сети встречаются почти равное число раз, оба переводы connectionism. В этом тексте я использовал "коннекционизм" и "коннекционистский подход", но не факт, что в другом тексте я не напишу "коннективизм" и "коннективистский подход". И тут нужно понимать, что я описываю в этом посте тренд "однородных нейросетевых структур", в некотором роде обратный от тренда differentiable programming: коннективистские архитектуры состоят из более-менее однородных элементов, а differentiable programming, probabilistic programing не предусматривают какой-то однородности, в них структуры весьма различаются, их некоторое богатство. В жизни же, конечно, будет какой-то промежуточный вариант. В мозгу тоже клетки не все одинаковые.

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

По факту современные GPU являются именно такими чипами, и особенно наглядно это видно на новом чипе NVIDIA с архитектурой Turing (https://ailev.livejournal.com/1441670.html): там алгоритмическая часть чипа (в данном случае не совсем универсальная, а ориентированная на ray tracing, но на архитектурном уровне можно было бы подумать, что там могло бы быть) совмещается с коннекционистской частью (её поддерживают Tensor Cores). Сейчас NVIDIA SDK NGX для визуальных эффектов имеет плагины именно для нейрообработки (https://developer.nvidia.com/rtx/ngx), но архитектурно как связаны там коннекционистские-нейро и классические алгоритмические-тьюринговские вычисления в этих "нейрообработках" может быть совершенно неочевидно -- так что можно только гадать, в каком направлении могут развиваться гибридные архитектуры типа Turing. Это может быть устроено "как мозг" на двух разных системных уровнях:
-- как сейчас в NVIDIA Turing, или NVIDIA Xavier когда разные части чипа поддерживают разные вычисления, разную встроенную логику. Это сейчас мейнстрим, по этому пути не только NVIDIA бегом бежит, просто остальные чуток отстали в плане массовости. Разные отделы мозга выполняют разные функции, реализованы они по-разному.
-- как в биологическом мозге: универсальный коннекционистский субстрат, выучивающий/эмулирующий классические алгоритмы ("медленное мышление по Канеману, эмулируемое человечьим мозгом: дикие затраты мыслетоплива, но оно есть! И оно выучивается, innate priors минимальны!"). Вот тут в комментах у нас тред с cantechnik про устранение лишних уровней виртуализации -- если транслировать LLVM архитектуру не в FPGA, даже не в ASIC, а сразу в аналог (какие-нибудь мемристоры или оптику, как в пункте 3 комментируемого поста по ссылке), то может не так уж и плохо получиться даже с эмуляцией/выучиванием: https://ailev.livejournal.com/1441034.html. Разные отделы мозга выполняют разные функции, но реализованы они одинаково.

Вот прямо сейчас расцветают сто цветов гибридизации нижних уровней интеллект-стека (равно как сто чуть менее заметных сегодня, но не менее важных цветов гибридизации его верхних уровней). Восхитительный момент, когда всё происходит стремительно со скоростью двух прорывов в неделю. Совершенно невозможно предсказать, что будет буквально через месяц-другой, и как оно отразится на цивилизации. Думаю, что отразится сильно, и быстрее, чем все это себе представляют. Другое дело, что к чудесам привыкают, и привыкают быстро. Уже сегодня ведь можно задать своему телефону где-нибудь в глухом переулке ночью классический вопрос "Как пройти в библиотеку?" и получить внятный ответ, причём с предупреждением, что "эта библиотека откроется через восемь часов, в 11:00 -- тот же самый Гугль или Алиса в телефоне знают и часы работы всех заведений вокруг). Чудо? Чудо. Никто не удивляется, только ругаются, что это всё не слишком надёжно работает. Ну, plug and play тоже когда-то ругали, говорили, что plug and pray. И модем дозваниваться мог полночи до провайдера. А сегодня всё работает в полпинка. Вот и гибридный интеллект-стек, который сможет и в логику, и в чуйку -- он тоже будет сначала шалить, а потом просто надёжно работать.

UPDATE: дискуссия в фесбуке -- https://www.facebook.com/groups/1505369016451458/permalink/2151897705131916/.
2019

Экспоненциальные технологии: на этот раз компьютерная графика x2 меньше, чем за год

NVIDIA анонсировала новые видеокарты и сервер, основанные на чиповой архитектуре Turing -- https://blogs.nvidia.com/blog/2018/08/13/jensen-huang-siggraph-turing-quadro-rtx/, https://www.nvidia.com/en-us/design-visualization/technologies/turing-architecture/. В принципе, ничего принципиально нового и всё соответствует объявленной раньше стратегии:
-- новый чип не в центре презентации, презентуется платформа для узкого рынка компьютерной графики (как говорит NVIDIA CEO Jensen Huang, "конечный продукт всегда должен быть ограничен в своём назначении, чтобы заработать на нём деньги"). В платформе видеокарты для профессиональной графики (самая дорогая карта Quadro RTX 8000 стоит $10000) и сервер с 8 такими картами за $120000. Два системных уровня вверх от чипов и чёткий рыночный фокус: промышленная компьютерная графика, поддержка мониторов разрешения 8К "из коробки" и прочие плюшки для данного рыночного сегмента визуальных эффектов, на котором по оценкам NVIDIA будет крутиться $250млд..
-- презентуется новый софтверный стек поддержки этих решений (помним, что NVIDIA себя обозвала на GTC'18 не чиповой компанией, и не только компанией компьютерной архитектуры, но и software company).

Вот картинка с GTC'18 полугодичной давности (я публиковал её в https://ailev.livejournal.com/1416697.html):

Полгода назад речь шла о том, что две карты на Volta делают ray tracing в реальном времени -- и это прорыв в компьютерной графике, никогда такого не было.

А вот картинка из вчерашней презентации, те же фирменные зелёные плашечки технологических стеков NVIDIA для ray tracing:
NVIDIA_RTX_arch
Вот он, объявленный на GTC'18 тренд: вперёд к рынку. На верхушке стека промышленные приложения создания качественной машинной графики, а от уровня интерфейса трассировки лучей их отделяет ещё один слой: язык описания материалов MDL (Material Definition Language, open source) и язык описания сцен USD (Universal Scene Description от Pixar). Подробней -- на странице платформы RTX https://developer.nvidia.com/rtx

Плашка RTX из прошлого подхода, где было в прошлой презентации было две видеокарты на чипе Volta заменили на одну карту на чипе Turing -- и показали, что там внутри появился Ray Tracing Core из новых компонент архитектуры.

В апреле я писал: "Где там искусственный интеллект? Вы можете получить в OptiX [библиотека для трассировки лучей с фирменным API от NVIDIA в отличие от API DXR от Microsoft и "нейтрального" API Vulkan] в том числе удаление визуального шума алгоритмами искусственного интеллекта, да и про трассировку лучей в части требований к ресурсам уже поговаривают, что эти требования существенно уменьшат через задействование алгоритмов искусственного интеллекта. Аппроксимации рулят численным миром, а аппроксимациями рулят сегодня глубокие нейронные сетки и прочие универсальные аппроксиматоры, которыми богато сегодня машинное обучение".

Так и произошло: сочетание алгоритмов с использованием как Ray Tracing, так и Tensor Core (добавка алгоритмов искусственного интеллекта с необходимыми аппроксимациями) позволило упихнуть функциональность двух карт с чипами на 21млрд транзисторов в одну карту с 18.6млрд. транзисторов и при этом получить крутые новые качества: высококачественную обработку не только отдельных кадров, но и связанных во времени последовательностей изображений (видео), возможность включать плагины обработки изображений на базе нейронных сетей. Всё, компьютерная графика с четвёртого квартала 2018 стала другая: на одном чипе идёт полная трассировка лучей плюс нейросетевая обработка какими-нибудь плагинами спецэффектов, сделанных с SDK NGX (скажем, генерация видео замедленной съёмки по обычным кадрам -- https://news.developer.nvidia.com/transforming-standard-video-into-slow-motion-with-ai/, изменения в освещённости фигур и фона как в https://relonch.com/ и т.д., ждём через полгодика объявлений уже не про SDK, а про готовые плагины, изготовленные с его помощью. Это ж рынок!).

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

Вот тут сейчас поток новостей про возможности архитектуры Turing -- там много видео и фото, так что поглядите сами: https://nvidianews.nvidia.com/. Видео презентации (как обычно, хороший концерт) можно найти тут: https://www.youtube.com/watch?v=XByzjj9JTBM

Не обращайте внимания на все сравнения с архитектурой Pascal, это не для инженеров, а для маркетинга (типа как Pascal был для графических карт в машинных станциях, и Turing для графических карт, а Volta для карт AI в датацентрах). Насколько я помню, Volta подавалась как x3 по сравнению с Pascal (ох, там было много разных метрик, и не про графику, но я почему-то запомнил эту как одну из многих), а две карты Volta вместо одной Turing -- это ещё x2 (этого в данных нет, но я по простому: демо на GTC'18 требовала двух карт, а тут одной). Вот они, x6 в рендеринге по сравнению с Pascal. В любом случае, это x6 за два с половиной года (Паскаль -- May 27, 2016, Вольта -- December 7, 2017, Тьюринг -- August, 13), или x2 за чуть меньше года, то есть определённо экспоненциальная технология.

Вот тут чуть больше сравнения архитектур Volta и Turing (в Turing всего поменьше, чем в Volta, кроме Ray Tracing Core -- то есть это получилась специализированная для машинной графики архитектура): https://www.pcgamer.com/nvidia-unveils-turing-architecture-providing-a-glimpse-inside-the-next-geforce-cards/.

Понятно, что NVIDIA сейчас хвастается, как может перед инженерами компьютерной графики (сегодняшний анонс выхода видеокарт с Turing в 4 квартале 2018 года был сделан на конференции SIGGRAPH). Но уже 20 августа 2018 (через неделю) есть шанс получить новинки потребительской, а не промышленной машинной графики на базе архитектуры Turing, а именно игровые видеокарты: https://www.trustedreviews.com/news/nvidia-turing-2080-release-date-2952823 (и там дополнительная техническая информация, что чипы Turing на 12нм проектных нормах). При этом отбиваться от любителей компьютерных игр придётся не похвалой ray tracing, а тем, насколько удаётся поднять FPS в компьютерных играх. Хотя может выясниться, что FPS не волнует, если картинка фотореалистичная и тем самым завораживающая. А лучше и то, и другое, да ещё и подешевле. Потребители, они такие! Почитайте вот тут в комментах, как обсуждают отсутствие отражений внутри автомобиля на демо NVIDIA на 1:54 -- https://www.youtube.com/watch?v=XByzjj9JTBM (и обратите внимание, что демо по промышленной графике пришли обсуждать главным образом геймеры, люди из абсолютно другого рыночного сегмента. Хотя это не значит, что они люди ненаблюдательные и ничего в машинной графике не понимают. Но их больше интересует, как это всё поведёт себя в играх, что не так интересно для именно этого оборудования и софта, они совсем не для игровых приложений).

Для любителей и профи в deep learning это новое поколение карт не так интересно: там всего чуток поменьше, чем в серверных картах на Volta, но чуток побольше, чем в потребительских картах GTX. Тут ничего экспоненциального пока, так что ждём весны 2019 года. Уже понятно, что будут отдельно чипы для машинной графики с ray tracing (Turing), будут отдельно чипы для автомобилей с обработкой огромных потоков входной информации (Xavier, Orin) и что-то ещё, продолжающее линию Volta -- универсальный процессор для AI, который и мир с роботом может промоделировать (поддержка видео важна, вопрос, насколько мир для обучения AI должен быть фотореалистичен! Возможно, намного -- тогда и ray tracing будет неожиданно при деле) и нейронную сетку этого робота обучить. Тут нужно было бы пуститься в абстрактные рассуждения об архитектурах поддержки AI (всех этих deep learning и differentiable programming, deep evolution и т.д.) и одновременно реалистичного имитационного моделирования физического мира, но я уже писал об этом, не буду повторяться.
2019

Выучится всё! Нейронное арифметико-логическое устройство

Пошли эксперименты с специализированными для частных предметных представлений нейронными архитектурами: и вот для чисел в DeepMind сделали нейронное арифметико-логическое устройство, НАЛУ. Реализовано NALU как активационная функция, работает на-ура: https://arxiv.org/abs/1808.00508. Experiments show that NALU-enhanced neural networks can learn to track time, perform arithmetic over images of numbers, translate numerical language into real-valued scalars, execute computer code, and count objects in images. In contrast to conventional architectures, we obtain substantially better generalization both inside and outside of the range of numerical values encountered during training, often extrapolating orders of magnitude beyond trained numerical ranges.

Практическое значение NALU не такое уж большое, но это хорошая демонстрация направления, в котором сейчас бродят мысли исследователей в глубоком обучении. Так что после публикации пять-шесть имплементаций можно было найти на GitHub в первую же пару дней после публикации (https://twitter.com/DeepMindAI/status/1025375916107673602).

В комментах там шутят про "побольше innates" -- это innate priors, знания о мире, заложенные в вычислительный хардвер. Какие знания о мире являются самыми базовыми? Логики? Арифметики? Растровой графики? Эмулировать-то можно что угодно на чём угодно, вопрос в том, что нужно для максимизации числа применений, чтобы хардвер на этих innate priors оказался самый эффективный для большинства применений. Так что фишка не в самом NALU, а в показываемом направлении исследований: в архитектуру нейронной сети встраивают активационные функции, подхаканные для каких-то специфических применений, а не "универсальные". Это открывает новые горизонты, от DeepMind требуют какую-нибудь white paper на эту тему. Но и без white paper уже всё понятно. Вот, сделали выучиваемую, а не программируемую арифметику и логику! У яндекса "найдётся всё!", а у DeepMind "выучится всё!". Вот вам обсуждение deep learning, structure and innate priors -- http://www.abigailsee.com/2018/02/21/deep-learning-structure-and-innate-priors.html

NALU расположена внизу интеллект-стека, то есть это направление работ по innate priors потенциально влияет на самые разные уровни выше -- уровень учебных алгоритмов, уровень когнитивной архитектуры, уровень прикладной архитектуры (http://ailev.livejournal.com/1356016.html). При этом на всех уровнях интеллект-стека развитие идёт со скоростью два прорыва в неделю.

У меня в первой части завтрашнего тренинга "как выжить в эпоху перемен перемен" (ага, вторая производная: сами перемены меняются!) как раз краткая характеристика происходящего в мире: http://system-school.ru/uptodate. Материал оказывается быстропрокисающим, слайды готовил буквально пару недель назад, уже чуть-чуть рассказывал по этим слайдам, https://ailev.livejournal.com/1438343.html, но уже хочется эти слайды обновить.
2011

Проблемы инженерии требований

Вчера прошёл семинар "Об инженерии требований", но я бы его назвал "об инженерию требований" ("об об", https://ailev.livejournal.com/982750.html). На семинаре Кирил Гайдамака представил самые разные имеющиеся в литературе подходы к описанию инженерии требований. Увы, не получилось ни трансляции организовать, ни видео записать. Вот тут о семинаре написал Церен Церенов -- https://www.facebook.com/tseren.tserenov/posts/1565419446889339, а я сделаю несколько заметок по сути дела.

Последний раз я затрагивал тренды в инженерии требований в докладе 2015 года http://incose-ru.livejournal.com/53170.html, но там было главным образом про тренды. И я понимаю, что с тех по ничего не изменилось в ситуации, когда на предприятиях не обнаруживаются стейкхолдеры, заинтересованные в инженерии требований -- https://ailev.livejournal.com/1217302.html. Во времена тотального имкрыша и импортзамещения людям в массе своей не до инженерии требований, за три года ничего с этим не изменилось.

Но мы в Русском отделении INCOSE, Международной ассоциации ТРИЗ, Школе системного менеджмента (по факту семинар получился совместным для всех них) это печальное положение дел с массовым отсутствием в русскоязычном мире стейкхолдеров игнорируем, мы тут сами себе стейкхолдеры: нас мало, но мы системны и поэтому можем сделать что-то интересное и без скопления больших толп. Так, мы за последний десяток лет сделали несколько шагов по улучшению изложения материала системного мышления, добавили материалы по онтологике, прояснили связь ТРИЗ и системной инженерии. И у нас есть формальная и неформальная связь с мировой системной инженерией, мировым движением ТРИЗ. Не боги горшки обжигают. Так что я позволю себе ряд проблематизаций по итогам семинара.

Системная инженерия требований vs. инженерия требований к системе
Это различие я ввёл по типу systems engineering vs. engineering of systems -- инженерия с системным подходом в голове, или инженерия "систем", где система это просто какой-то технический объект (подробней это противопоставление см. в https://ailev.livejournal.com/1146200.html и там ссылка на материал профессора Derek Hitchins http://www.hitchins.net/profs-stuff/profs-blog/systems-engineering-vs.html.

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

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

Инженерия требований для IT vs. инженерия требований для "железа"
Практики инженерии требований для больших и маленьких "железных" систем существенно отличаются от практик инженерии требований для больших и маленьких систем с IT-микросервисами. И тут легко запутаться: литература по инженерии требований на 90% относится к IT-проектам, и только на 10% к "железным". Многие книжки даже не упоминают разницы, и вроде как "общие", пригодные как для IT, так и для "железных" проектов. Но по факту они содержат опять таки 90% отличного материала для IT-проектов и 10% для проектов "железных". Уж так случилось. Конечно лет через десять-пятнадцать мы увидим многие адаптированные для "железа" практики сегодняшней айтишной инженерии требований, но на сегодняшний день эти практики не адаптированы, и вычленить из них что-то заведомо работающее для "железа" трудно.

В программной инженерии архитектурный подход менее развит, чем в железной (кроме архитектуры предприятия, которая тем не менее не эквивалентна программной архитектуре, хоть и с креном в архитектуру IT-решения). Архитектурная деятельность практически не выделяется во многих проектах -- но выделяется инженерия требований. В "железных" системах центральная дисциплина -- это как раз архитектура, изобретение, модульный синтез. Это означает, что в айтишных методологиях инженерии требований очень плохо прописан стык между практиками инженерии требований и практиками инженерии системной архитектуры. Главными потребителями софтверных требований оказываются не архитекторы, а совсем другие стейкхолдеры, поэтому артефакты инженерии требований получаются более удобными для этих других стейкхолдеров, а не для работы архитекторов. Требования трассируются не к архитектуре, а... и тут понимаешь, что требования совсем необязательно трассируются, с ними в айтишных проектах работают по-другому. Как? По-всякому, но "железные" проекты с их длительными циклами изготовления и дорогими испытаниями могут и не выжить от подобной "всякой" работы с требованиями. Что птичкам хорошо, то рыбкам смерть.

Автоматизация тестирования, откатки-накатки в ходе DevOps в существенной мере влияют на практики жизненного цикла требований. Даже время одной итерации от формулирования требования до верификации (для этого нужно пройти до продукта "в металле" или "в бетоне" по жизненному циклу неайтишного проекта) имеет значение. Если в IT можно за пару часов сформулировать требование, попробовать изменить систему, провести не только верификацию, но и валидацию, а в случае неудачки успеть откатиться назад, то в "железных" системах цена этого (иногда и многолетнего -- в случае самолётов или АЭС) цикла будет запредельно велика, а скорость низка. В айтишных проектах можно подумать -- внести изменения в систему по небрежно сформулированному требованию и тут же понять, что это было неправильное изменение, или провести побольше времени, размышляя над требованиями, а потом только ввязываться в архитектуру и уж тем более в изготовление и испытания. Автоматизация тестирования в IT и "железных" проектах, способы работы с юнит-тестами отличаются существенно. И поэтому чисто экономический расчёт по выгодности lightweight инженерии требований или наоборот, необходимости использования самых тяжёлых вариантов может быть очень разным.

Водопад vs. спираль
Классические "железные" методологии инженерии требований подталкивают к analysis paralysis и оправдывают его. Чем больше денег налогоплательщиков удаётся оправдать "надёжной методологией, без которой нельзя", тем лучше. Когда тебя не давят конкуренты (а в госсекторе той же военной системной инженерии конкуренции нет, деньги получают в ходе политического процесса и интриг, а не выигрышем на рынке), жизнь волшебным образом меняется, и бюрократия побеждает. Если можно обосновать не одну трассировку требований, а четыер -- вы их получите, и на эту тему напишете учебник (который пойдёт в обоснвание следующих подобных проектов). Финансируемые государством инженерные проекты водопадом не испортишь, на попытках реализовать водопад за-ра-ба-ты-ва-ют!

Так что при работе с тяжёлыми методологиями:
-- помним, что agile в айтишных проектах появился когда-то как попытка преодолеть лишнюю бюрократию, убрать непроизводительную работу. В "железных" проектах не нужно пугать людей словом agile (хотя многие уже не пугаются), но слова "concurrent engineering" произносить обязательно. Если методология инженерии требований не поддерживает concurrent engineering, а рассчитана на классический водопад, то лучше её выкинуть сразу, она будет хороша только для госпроектов.
-- разбираем методологии на отдельные практики и используем из этих практик только самое необходимое, и ни в коем случае не используем методологии целиком.
-- чётко понимаем, что делается "на всякий случай", а что реально важно и критично. Борьба с рисками съедает все ресурсы, и ещё чуть-чуть. Поэтому в рассмотрение того, что важно, и что неважно в инженерии требований нужно внести какие-то оценки ресурсов и при большом потреблении ресурсов той или иной практикой вводить аппроксимирующие практики: которые дают результат похуже, но зато кушают меньше ресурсов. Этот аспект эффективности инженерии требований, аспект "экономической оценки" нужно обязательно ввести. Ибо дай волю и деньги инженерам по требованиям, и центральной дисциплиной станет не архитектура с её изобретениями как главной практикой, а инженерия требований. Это отчасти уже произошло в software engineering с резко уменьшившейся долей архитектурных размышлений и выпячиванием инженерии требований. Результат -- точно соответствующие безумным требованиям убогие перераздутые и плохо спроектированные системы. Инженерия требований должна быть "достаточной", а не избыточной.

GORE разделить с MBCD
Мы должны работать прежде всего с GORE (goal oriented requirements engineering) в инженерии требований, а это появилось всего-навсего в 1995 году. В требованиях к "железу" (к какой-нибудь АЭС или самолёту) всё идёт по накатанной колее работы с текстовыми требованиями, но без моделей требований. Помним, что модели требований -- это когда не только требования трассируются к стейкхолдерам, но и показываются взаимоотношения между стейкхолдерами (например, что у какой-то пары стейкхолдеров оценки какого-то интереса противоположны).

Следующий вопрос тут -- насколько модели требований должны быть "формальными моделями" (быть схемами), а насколько находиться в левой части спектра мышления (быть схемоидами, или даже просто вдохновляющими текстами). Тот же вопрос задавался для архитектуры: насколько архитектура должна быть представлена формальными моделями -- и Donald Firesmith приходилось защищать наличие текстов в архитектурных артефактах, например, архитектурного эссе. Тут может быть "стена текста" из неатомарных текстовых требований; из атомарных текстовых требований; из атомарных требований, разобранных в таблички или деревья и т.д. -- заканчивая формальными языками представления требований (большинство архитектурных языков и языков моделирования, даже Modelica и даже Julia имеют уже какие-то метамодели для представления требований в формальном виде, при этом формальность достаточна для исполнения требований. Например, требования описывают систему как чёрный ящик, поэтому исполняемые требования просто будут вести себя как система -- и можно будет сравнивать реакции воплощения целевой системы на внешние воздействия с реакцией имитационно моделируемой системы, описанной требованиями. Об этом я говорил в докладе http://incose-ru.livejournal.com/53170.html на примере исполняемых спецификаций требований к системе предотвращения авиационных коллизий, написанных на Julia.

Конечно, тексты нужно оставлять. В мышлении задействуется весь спектр мышления, и если что-то нельзя или наоборот, намеренно не нужно формализовывать, в требованиях это "что-то" нужно иметь возможность выразить -- например, текстом на естественном языке. Любая формализация этого текста -- это сжатие информации. Нужно чётко понимать, когда и в какой момент сжимать информацию. С несжатой информацией невозможно работать, внимание должно быть приковано к очень небольшому числу объектов. Но и с отжатой информацией нельзя работать: можно потерять что-то реально важное. Так что в инженерии требований должно быть сформулировано отношение к работе со спектром мышления ("жми, господь!", https://ailev.livejournal.com/1414038.html). При подготовке курсов системной инженерии требований нужно уделить особое внимание работе инженера по требованиям с полным спектром мышления ("фундаментальное образование: системное развитие мышления", https://ailev.livejournal.com/1425003.html).

А ещё граница между моделями требований и концепцией использования (ConOp) определена очень нечётко, много менее чётко, чем граница между такими описаниями системы, как требования и архитектура. Когда практики model-based concept design (MBCD, иногда не concept, а conceptual), центрирующиеся на разработке концепции использования и mission and business analysis, вдруг переходят в практики системной инженерии, непонятно. Системные инженеры более-менее согласны, что они откуда-то получают задание на разработку системы, а не придумывают проект самостоятельно. Можно вспомнить тут известную картинку из Steven J. Saunders "Return on Investment Using Model-Based Concept Design", INCOSE INSIGHT том 17 выпуск 4, декабрь 2014:

Как именно MBCD граничит с GORE в системной инженерии -- это непонятно, но нужно сформулировать.

Системная методология инноваций aka ТРИЗ+
Развитие ТРИЗ в его "иностранный период" (после перестройки, когда эмигрировало много ТРИЗ-мастеров -- и в СНГ ТРИЗ по факту заглох, а за рубежом наоборот, вдруг набрал силу) почти неизвестно русскоязычной публике. А ведь ТРИЗ по факту это некоторая специализация практик системной инженерии -- классический ТРИЗ тут специализация главным образом практик разработки системной архитектуры. Результат успешного модульного синтеза это и есть обычно искомое архитекторами "изобретение". ТРИЗ+ прирастал в 21 веке главным образом практиками conceptual development (получение идеи продукта) и инженерии требований. В ТРИЗ+ строится некоторый набор моделей требований, в которых затем находится противоречие, решаемое в ходе архитектурной работы (см. часть про ТРИЗ в "творчество в системном мышлении", https://ailev.livejournal.com/1425331.html).

Так что нужно обязательно включить в рассмотрение практики MPV (main parameters of value, https://www.gen-triz.com/main-parameters-of-value/, https://www.metodolog.ru/01472/01472.html) и другие практики инженерии требований из ТРИЗ+.

При этом помнить, что в ТРИЗ по старой традиции принято переформализовывать и в какой-то момент переходить к численным оценкам. Методология численных оценок в ТРИЗ старая, и нужно просто заменить эту практику на более современную (на основе байесовских вероятностей), проще всего её брать из книжки Хаббарда Дугласа "Как измерить все, что угодно. Оценка стоимости нематериального в бизнесе" (http://b-ok.org/book/2315676/1b9807, но есть и обновлённое английское издание, существенно дополненное).

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

Но оценки должны делаться для как-то описанной системы. Как описывать систему? Как совмещать рассказы о системе от самых разных стейкхолдеров? Как узнать предметную область системы, существенные её свойства? Почему вдруг сценарии оказались так хороши для описания функций -- можем ли мы как-то усилить, если будем знать причину? Это та же причина, из-за которой оказался успешен behavior driven development (BDD, https://www.infoq.com/news/2018/04/cucumber-bdd-ten-years)? И как находят требования в domain driven design (DDD, https://habr.com/post/334126/, https://en.wikipedia.org/wiki/Domain-driven_design) с его event storm (http://www.russmiles.com/essais/going-events-first-for-microservices-with-event-storming-and-ddd). Онтика/дисциплина (и даже набор дисциплин), в которых требования описывают систему -- это важный вопрос, его не нужно отдавать на самотёк.

Последний вопрос мы уже затрагивали при рассмотрении формальности моделей, и тут тоже не обойтись без онтологики: на каком уровне формальности описывать систему?

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

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

Рабочий способ, которым можно было бы получить "мировоззрение" инженерии требований -- это выполнить ходы, описанные для получения "мировоззрений" в "откуда берутся полезные мировоззрения" https://ailev.livejournal.com/1425003.html.

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

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

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

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