Category: дизайн

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

2019

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что самое трудное в системном мышлении

Вот пример ответа на анкетку для выпускников "системного менеджмента и стратегирования":

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

До сих пор сложно составлять функциональную холархию (с модульной просто). Не понимаю как оценить функциональную холархию - функциональная ли она, правильная ли она, полезная ли она.

Что было самым контринтуитивным и удивляет до сих пор?
Взгляд на деятельность как на практику. Описание практики как дисциплина + технология.

Вроде бы часто приходилась слышать слова «best practices», обсуждать методологию работы, но то что из практик удобно составлять архитектуру предприятия - до сих пор удивляет.

Удивляет то, что стало понятно как между собой связанны продукт, архитектура предприятия, стратегия.
Например, вопрос «как развивать сотрудников» резко перешёл в понятные - спланируй развитие продукта - определи практики - назначь практики на роли, роли на должности.

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

2. Описал свою должность на языке archimate - стало понятно за какие практики я отвечаю, какие практики можно было бы ещё добавить.

Есть ли у вас какие планы на эту тему? Есть ли планы в письменном виде?
Планирую описать архитектуру своего отдела в Archimate, описать стейкхоледров с которыми работаю в виде стейкхолдер-интерес-оценка интереса-цель. Планирую подготовить стратегию личного развития.

Планы есть в issue tracker’е.

Изменилось ли у вас мышление в результате курса? В чем именно?
1. Изменилось состояние, появилось спокойствие и уверенность. Связываю это с тем, что более-менее разобрался с холархией и местом своей системы в ней.

2. В общении стал постоянно думать о том, какой интерес скрывается за фразой и какой, соответственно, стейкхолдер.

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

4. Понял какой я стейкхолдер, придерживаюсь роли.

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

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

Очень надеюсь, что самые разные люди займутся теперь instructional design для системного мышления. И список "самых сложных мест курса" после этого поменяется. Вот, например, я писал про функциональные против конструктивных элементов тут, на примере ножниц: https://ailev.livejournal.com/1361765.html. Но наверняка это можно изложить и проще, и таким способом, чтобы потом можно было более легко переносить это объяснение на ситуации собственных проектов. Вот спецы по instructional design пусть этим и займутся.
2019

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

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

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

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

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

AMA со мной в CreativeRussia

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

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

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

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

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

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

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

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

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

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

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

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

Системный моделер из стены и липучек

User story mapping -- http://jpattonassociates.com/user-story-mapping/. Основная заявленная идея тут упорядочить пользовательские задачи (activities) во времени, из историй сделать эпопею. Если внимательно приглядеться, то время оказывается логическим -- привет, вид жизненного цикла (то бишь практики) по горизонтали с разбивкой на эпические/тематические подпрактики по вертикали.

Тем самым user story mapping оказывается про принципиальную схему взаимодействия пользователя с системой, функциональный анализ -- "как оно работает, как получается польза". Поэтому user story map так сильно отличается от product backlog, который появляется исключительно в попытке модульного синтеза -- "как это реализовать, из каких кусков сделано".

Поразглядывайте примеры для user story map в google image. Очень поучительно.

И сразу становится понятным, почему user story mapping хорошо сочетается с domain-driven design (DDD) -- http://blog.eriksen.com.br/en/mapping-domain-knowledge.

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

Одно системное мышление, тысяча применений.

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

Вот что пишет автор подхода user story map (http://jpattonassociates.com/the-new-backlog/): "I hate that word “epic.” I haven’t written Beowulf here. There’s no hero with a magic weapon slaying a monster. It’s just my user “managing email” – a relatively basic thing from my user’s perspective. At least the terms “activity” and “user task” give me some idea of what kinds of stories they are. That said, I’m not fond of the term “user story” either, but I’ve come to accept it. It beats the crap out of requirement.

Куда ведёт в этой цитате ссылочка со слова requirements? К его же статье Requirements considered harmful, где от слова requirements с его кажущейся неизменяемостью и окончательностью он уходит к слову decision, что можно было бы изменять и объяснять. Но кончается всё опять-таки не словом desicion, а теми самыми "нарративами" и "эпопеями" (epic) в user stories -- описаниями. Требования всего-то описания системы как чёрного ящика, со стороны её работы в составе использующей системы. И, конечно, описания могут меняться по мере продвижения в понимании, почему бы и нет.

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

UPDATE: пара интересных реплик на этот пост появилась в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10206161610733298
2019

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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