?

Log in

No account? Create an account
Лабораторный журнал -- Day [entries|friends|calendar]
Anatoly Levenchuk

[ website | Лабораторный журнал ]
[ userinfo | livejournal userinfo ]
[ calendar | livejournal calendar ]

Системная инженерия и онтологика [27 Sep 2019|02:49pm]
Вчера в Школе на встрече сообщества обсуждали архитектурную практику, и я вспомнил старинный слайд команды Яна Диеца с представлением архитектурного фреймворка xAF (2006, у меня на компьютере он хранится с 2008 и я раньше часто его показывал).

Вон она, "использующая система" (без использования никак нельзя) и даже "целевая система" с прямым указанием object. Описание, которое должно быть онтологично/предметно, указание на реверс-инженерию для надсистемы и прямой инженерии для целевой системы, функциональный анализ и последующий модульный синтез как основное в архитектуре. Учитывая то, что массовый разговор об архитектуре начался где-то с IEEE 1471 в 1995 году, а системная терминология была только-только устаканена в ISO 15288:2003. И это было всё очень круто и ново в 2006, Ян Диец работал на фронтире. Сейчас пыль тех методологических рассуждений об архитектуре уже осела, и это всё общее место. Я давно не использую эту диаграмму в своих слайдах, в учебнике обо всём этом пишу другими словами, но десяток лет назад разглядывание этой картинки мне сильно помогло в понимании архитектурной работы. Так что пусть повисит тут памятником эпохе.

Заодно опять коснулись онтологики в мышлении инженера: шестерёнки часов ещё не показывают время, часы показывают время, дом с часами на стене уже не показывает время -- это про эмерджентность, она определяется на отношении часть-целое, системное мышление это прежде всего про отношения часть-целое. Для уместного разговора нужно говорить на адекватном системном уровне. Но этот разговор всё одно нужно как-то поверять формализмами. Всё системное мышление по факту оказывается про то, что на разных системных уровнях нужно применять разные формализмы для описаний мира. Но! Сами системные уровни -- это мереологический формализм, формализм частей-целого, отношение композиции, а не, например, классификации. У коровы Маргариты есть хвост, корова Маргарита есть часть стада. Часть стада, а не входит в стадо как во множество! И после этого можно говорить, что у стада есть хвост -- тот самый хвост коровы Маргариты. Все молекулы хвоста входят в число молекул стада. Это абсолютно корректно, это позволяет поддерживать управление вниманием на хвосте, корове, стаде -- внимание определяется тут отношением composition/is_part_of. Но в разговоре на раз-два отношение composition заменяется отношением классификации/is_a, принадлежности к стаду как множеству коров. Множество -- это не материальный объект, и принадлежность ко множеству это не отношение часть-целое. Коровы в стаде физическом взаимодействуют и дают эмерджентность (можно, например, говорить о минимальной площади, занимаемой стадом), в стаде как множестве -- не взаимодействуют и не дают эмерджентности. Различиям этим в типах объектов и типах отношений учит онтологика, без этого инженерные рассуждения становятся очень зыбкими, в них могут легко попадать ошибки -- источником ошибок являются естественность языка, который более чем терпим к ошибкам. Формализация позволяет избавляться от ошибок, но должна быть некоторая беглость в этой мыслительной работе с проверкой типов объектов и отношений, чтобы она смогла стать полезной. А пока лихо путаются отношения классификации, специализации, композиции -- системное мышление невозможно.

Я писал об этом в учебнике 2019 года, вот цитата: ""Корова Маргарита имеет своей частью хвост, корова Маргарита является частью коровьего стада. Нехорошо позволять говорить, что коровье стадо имеет хвост, хотя это вроде как корректно. Это корректно, но не системно, и это вроде как интуитивно понятно всем. Но интуитивно непонятно, можно ли говорить, что карбюратор — часть автомобиля. Он отдельная часть автомобиля, или он часть топливной подсистемы, или часть двигателя?! Но интуитивно понятно: неправильно говорить, что поршень или цилиндр двигателя — это часть автомобиля. Формально это верно, но неправильно". Вот это "формально верно" и "системно неправильно" люди не могут обосновать. Разница в том, что они прыгают от отношений is_part_of к отношениям is_a. Когда говорят о стаде как горе мяса и костей и стаде как математическом множестве — не могут различить.

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

Но как поднять онтологическое образование у человека, который даже не знает, что ему нужно подтянуться в этом отношении -- мне пока неведомо. Курсы по онтологике у нас в Школе есть, после них становится сильно лучше, но походы на эти курсы отнюдь не массовы и объяснить, почему на эти курсы нужно идти, получается пока не очень. Но ничего, лиха беда начало. Мы вчера вспоминали, что лет десять назад о подобных курсах онтологики для инженеров и менеджеров можно было только мечтать. А сейчас курсы уже есть, хотя ещё и не полный набор (три курса из запланированных пяти). Завтра у нас день открытых дверей (суббота, с 14 часов на ул.Щипок, https://www.facebook.com/events/493244901513042/, вход свободный), будем стратегироваться в том числе на тему онтологики и инженерии.

Один из ходов тут -- использовать более современные техники обучения, чтобы добиваться учебного результата более эффективно. Тут у нас тоже есть некоторый прогресс: вчерашний семинар включал анонс нашего курса по эффективному самообразованию (его будет вести Кирилл Гайдамака), который основан не на попсовых книжках, а на оригинальных работах когнитивистов (видео: https://www.youtube.com/watch?v=55k5Qsxk1ak). Вот завтра и пообсуждаем, как можно ускорить обучение работы с типами. Чтобы на всех диаграммах люди проверяли типы объектов-прямоугольничков, типы отношений-стрелочек и не забывали при этом хоть как-то помнить, что это не просто картинка, а в чём-то правдоподобное описание кусочка мира.
1 comment|post comment

Чего мне не хватает в MS Teams [27 Sep 2019|05:37pm]
Провёл вчера целый день в офисе MS (pun intended, речь идёт о помещении) в изучении MS Teams, читал тамошние пейджеры и много думал. Основной плюс -- Teams можно рассматривать как эдакую систему повышения осознанности в командах. Презентация продукта напирала на то, что Teams имеет много разных средств управления вниманием команды, это ровно в направлении мыслей по киборгизации команд: https://ailev.livejournal.com/1488271.html

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

Как живут вместе разработчики и клерки (разработчики сидят в Visual Studio и Azure DevOps, клерки в Office и Teams) -- непонятно, ибо в Teams всё выстроено вокруг офисных документов в папочках, а в DevOps вокруг системы управления версиями кода. Всё, что на вкладках в Teams (даже на вкладках Planner как тамошней реализации канбан-доски) -- остаётся на вкладках и не втягивается в беседы, хотя есть способы привлекать внимание ко вкладкам (коннектор может сообщить, что во внешней системе что-то произошло и выдать в беседу ссылку на место, куда смотреть).

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

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

Альтернативные решения (сразу в голову приходит стек Jira+Confluence+Slack) по тем же критериям более заморочены: они ориентированы на разработчиков больше, и меньше на менеджеров, предпринимателей и уж тем более на внешних людей. Остаётся признать, что нет в айтишном мире счастья, оно всегда впереди, как горизонт.

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

Ещё барьер для входа. MS Teams это форум+мессенджер+контент+групповые звонки и поэтому входной барьер там примерно вчетверо от входного барьера в одиночных приложениях. Нужно полчаса на то, чтобы разобраться в интерфейсе. Если человек к нам приходит на короткий шестичасовой курс, то будет ли он доволен, когда ему придётся в этом разбираться? Но на втором же коротком курсе это окупится сторицей. Или если курс шестидневный. Это опять же к вопросу, что у нас Школа представляет собой какой-то симбиоз кровавого энтерпрайза и социальной сети.

Записал себе в план набросать архитектуру курса blended learning (cейчас Школа использует фейсбук, телеграм, imind, яндекс.диск, почту и ВКонтакте для организации работы -- плюс зоопарк самых разных authoring tools, от Офиса и yEd до видеокамеры, Archi и совсем уж экзотических рисовалок у наших курсантов). Сказать, что связность всех бесед выше, чем она была бы в Teams -- нельзя. Но значительная часть бесед идёт в соцсетях или группах telegram и публична. Но часть наоборот, непублична -- обсуждения в учебных группах, обсуждения по линии менторства. Там обсуждаются рабочие проекты, они не любят яркого света. Вот как правильно поделить внешние и внутренние беседы -- это отдельный вопрос.

Что касается учебных проектов -- идеи из статьи про учебный CAD+PLM остаются в силе (https://ailev.livejournal.com/1473691.html), и будем их потихоньку реализовывать. Но думать и о социальном шлейфе, жизненный цикл курсантов начинается задолго до начала курсов и прекращается сильно после их окончания. С абитуриент-курсант/студент-alumni (при этом ещё для каждого отдельного курса и для школы со множеством курсов в целом -- есть разница) та же онтологическая проблема, что и с issue-task-notice: софт это должен поддерживать, но из коробки ни один софт это поддерживать не будет.

UPDATE: обсуждение в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10216340724924791
12 comments|post comment

navigation
[ viewing | September 27th, 2019 ]
[ go | previous day|next day ]