Онтика системного мышления, 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
А ещё можно упростить терминологию примерно по тем же основаниям, что я упрощал русскоязычную терминологию архимейта в версии 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