Какие бывают модели данных
Всех (многих) системных аналитиков когда-то учили, что модели данных бывают:
1. Концептуальные.
2. Логические.
3. Физические.
Но при внимательном рассмотрении (Matthew West - Developing high quality data models, глава 3) можно увидеть, что модели данных бывают:
1. Физические.
2. Логические.
3. Концептуальные.
4. Канонические.
5. Модели данных приложения.
6. Модели данных бизнес-требований.
7. Интеграционные.
8. Модели данных предприятия.
9. Бизнес-информационные.
10. Использования данных.
На рисунке ниже показано как они между собой соотносятся с точки зрения Уэста.
Много интересного об этих моделях, как из разрабатывать и как их использовать Уэст пишет в упомянутой книге.
И вообще есть у меня гипотеза: если заставить проектировщиков освоить две книги: Криса Партриджа «BORO…» и Мэтью Уэста «Разработка высококачественных моделей данных», - то проектировщики стали бы умнее не только в профессиональной деятельности.
#уэст #партридж #boro #моделированиеданных
Всех (многих) системных аналитиков когда-то учили, что модели данных бывают:
1. Концептуальные.
2. Логические.
3. Физические.
Но при внимательном рассмотрении (Matthew West - Developing high quality data models, глава 3) можно увидеть, что модели данных бывают:
1. Физические.
2. Логические.
3. Концептуальные.
4. Канонические.
5. Модели данных приложения.
6. Модели данных бизнес-требований.
7. Интеграционные.
8. Модели данных предприятия.
9. Бизнес-информационные.
10. Использования данных.
На рисунке ниже показано как они между собой соотносятся с точки зрения Уэста.
Много интересного об этих моделях, как из разрабатывать и как их использовать Уэст пишет в упомянутой книге.
И вообще есть у меня гипотеза: если заставить проектировщиков освоить две книги: Криса Партриджа «BORO…» и Мэтью Уэста «Разработка высококачественных моделей данных», - то проектировщики стали бы умнее не только в профессиональной деятельности.
#уэст #партридж #boro #моделированиеданных
🔥3👍2
Итерации, гипотезы и адаптивность при разработке государственных ИС
Если чиновников, ответственных за цифровизацию, заставить освоить, сдать экзамен и реализовать хотя бы один проект в соответствии с методическими рекомендациями по ссылке в конце поста – страна начнет стремительно прогрессировать в области цифровизации.
Я неоднократно писал о причинах неизбежного отставания государственных цифровых проектов от частных:
1. Системная инженерия последнее десятилетие эволюционирует в сторону всё более высокой адаптивности и стремительности внедрения изменений: «требования» всё больше заменяются «гипотезами», описания проектируемых функций меняют модус от «система должна категорически и бесповоротно во веки вечные» в сторону «предполагается, что данная функция системы будет наиболее оптимальна для потребностей пользователей, а если нет, то по ходу дела мы ее улучшим».
2. Государственный процесс цифровизации – косный и неповоротливый в силу длительности согласований, выделения бюджета, карательной политики относительно неточности реализации проектируемых систем. А также потому что чиновники делают системы не на свои деньги, не для себя и ничем, как правило, не рискуют.
Однако, как оказывается, государственные организации не оставляют попыток угнаться за техническим прогрессом в цифровизации. Мне прислали замечательный документ Минцифры России под названием «Методические рекомендации по организации производственного процесса разработки государственных информационных систем с учетом применения итерационного подхода к разработке». И там, фантастика (!), они пишут (стр.19-20):
«Независимо от того, насколько хорошо Система изначально определена и спроектирована, реальные потребности клиентов и выбор технологический решений являются неопределенными и, соответственно, развивающимися. Поэтому понимание того, как Система должна быть реализована, должно адаптироваться с течением времени. Исходя из этого при разработке Технического проекта рекомендуется придерживаться следующих правил:
1. Проектирование осуществляется на основе требований к Системе, исходящих от заинтересованных сторон, в том числе – клиентов, эксплуатирующего систему персонала, должностных лиц Ведомства.
2. В ходе проектирования рекомендуется использование практик, сохраняющих как можно дольше рассмотрение возможных вариантов реализации Системы (гипотез) в процессе её создания и принятие обоснованных (например, с точки зрения лучших экономических результатов) технических решений только после проверки гипотез.
3. И т.д.».
Рекомендуется системы внедрять итерациями, причем на каждой итерации проводить работы по проектированию, реализации, оценке и корректировке требований (гипотез) для следующей итерации. В рамках одной итерации разработка может вестись ежеквартальными инкрементами. Бюджет может быть независимый для каждой отдельной итерации. И много еще чего из современного ИТ-менеджмента, что является тайным знанием для многих госслужащих, предлагается использовать для успешного создания ИС ГО.
Сложно сходу глубоко оценить ценность и адекватность конкретных рекомендаций – нужно глубоко анализировать документ, а лучше испытать предлагаемые методики в реальном проекте. Но в любом случае есть что нам перенять для усовершенствования нашего законодательства в сфере создания ИС ГО.
Ссылка на документ: МЕТОДИЧЕСКИЕ РЕКОМЕНДАЦИИ
ПО ОРГАНИЗАЦИИ ПРОИЗВОДСТВЕННОГО
ПРОЦЕССА РАЗРАБОТКИ ГОСУДАРСТВЕННЫХ
ИНФОРМАЦИОННЫХ СИСТЕМ С УЧЕТОМ
ПРИМЕНЕНИЯ ИТЕРАЦИОННОГО ПОДХОДА К
РАЗРАБОТКЕ
#егов #менеджмент #мцриап #минцифры
Если чиновников, ответственных за цифровизацию, заставить освоить, сдать экзамен и реализовать хотя бы один проект в соответствии с методическими рекомендациями по ссылке в конце поста – страна начнет стремительно прогрессировать в области цифровизации.
Я неоднократно писал о причинах неизбежного отставания государственных цифровых проектов от частных:
1. Системная инженерия последнее десятилетие эволюционирует в сторону всё более высокой адаптивности и стремительности внедрения изменений: «требования» всё больше заменяются «гипотезами», описания проектируемых функций меняют модус от «система должна категорически и бесповоротно во веки вечные» в сторону «предполагается, что данная функция системы будет наиболее оптимальна для потребностей пользователей, а если нет, то по ходу дела мы ее улучшим».
2. Государственный процесс цифровизации – косный и неповоротливый в силу длительности согласований, выделения бюджета, карательной политики относительно неточности реализации проектируемых систем. А также потому что чиновники делают системы не на свои деньги, не для себя и ничем, как правило, не рискуют.
Однако, как оказывается, государственные организации не оставляют попыток угнаться за техническим прогрессом в цифровизации. Мне прислали замечательный документ Минцифры России под названием «Методические рекомендации по организации производственного процесса разработки государственных информационных систем с учетом применения итерационного подхода к разработке». И там, фантастика (!), они пишут (стр.19-20):
«Независимо от того, насколько хорошо Система изначально определена и спроектирована, реальные потребности клиентов и выбор технологический решений являются неопределенными и, соответственно, развивающимися. Поэтому понимание того, как Система должна быть реализована, должно адаптироваться с течением времени. Исходя из этого при разработке Технического проекта рекомендуется придерживаться следующих правил:
1. Проектирование осуществляется на основе требований к Системе, исходящих от заинтересованных сторон, в том числе – клиентов, эксплуатирующего систему персонала, должностных лиц Ведомства.
2. В ходе проектирования рекомендуется использование практик, сохраняющих как можно дольше рассмотрение возможных вариантов реализации Системы (гипотез) в процессе её создания и принятие обоснованных (например, с точки зрения лучших экономических результатов) технических решений только после проверки гипотез.
3. И т.д.».
Рекомендуется системы внедрять итерациями, причем на каждой итерации проводить работы по проектированию, реализации, оценке и корректировке требований (гипотез) для следующей итерации. В рамках одной итерации разработка может вестись ежеквартальными инкрементами. Бюджет может быть независимый для каждой отдельной итерации. И много еще чего из современного ИТ-менеджмента, что является тайным знанием для многих госслужащих, предлагается использовать для успешного создания ИС ГО.
Сложно сходу глубоко оценить ценность и адекватность конкретных рекомендаций – нужно глубоко анализировать документ, а лучше испытать предлагаемые методики в реальном проекте. Но в любом случае есть что нам перенять для усовершенствования нашего законодательства в сфере создания ИС ГО.
Ссылка на документ: МЕТОДИЧЕСКИЕ РЕКОМЕНДАЦИИ
ПО ОРГАНИЗАЦИИ ПРОИЗВОДСТВЕННОГО
ПРОЦЕССА РАЗРАБОТКИ ГОСУДАРСТВЕННЫХ
ИНФОРМАЦИОННЫХ СИСТЕМ С УЧЕТОМ
ПРИМЕНЕНИЯ ИТЕРАЦИОННОГО ПОДХОДА К
РАЗРАБОТКЕ
#егов #менеджмент #мцриап #минцифры
🔥5👍2
Вот мы тут капаем желчью, глядя на системы егов, а между прочим на днях правительство опубликовало концепцию развития ИИ до 2029 года. Которая в числе прочих задач поедусматривает использование ИИ в госуслугах. И уже в текущем году на реализацию заложили 2 млрд. тг.
Идея стартапа: напишите кто-нибудь на нейросетке и натренируйте бота по госуслугам - можно назвать его "Нить Ариадны". Слоган: "Получи услугу - убей Минотавра".
УПД. Можно еще в форме игры сделать: битва с монстрами-госслужащими в лабиринте, квест по поиску выхода и т.д. На последнем этапе игры нужно будет последовательно выиграть поединок с чудовищами: мцриаптерами, нитозаврами и колдунами гтсекты...
УПД2. Кстати, хорошая идея для пополнения бюджета: покупать скины и вооружение для ускоренного прохождения уровней. можно еще интеллектуальную песочницу сделать: смоделируй деятельность ГО и получи годовой абонемент на егов без глюков...
УПД3. Чувствую наведут на меня порчу сотрудники ГО без чувства юмора...
Ссылка - https://www.gov.kz/memleket/entities/mdai/documents/details/606493?lang=ru
#егов #ИИ
Идея стартапа: напишите кто-нибудь на нейросетке и натренируйте бота по госуслугам - можно назвать его "Нить Ариадны". Слоган: "Получи услугу - убей Минотавра".
УПД. Можно еще в форме игры сделать: битва с монстрами-госслужащими в лабиринте, квест по поиску выхода и т.д. На последнем этапе игры нужно будет последовательно выиграть поединок с чудовищами: мцриаптерами, нитозаврами и колдунами гтсекты...
УПД2. Кстати, хорошая идея для пополнения бюджета: покупать скины и вооружение для ускоренного прохождения уровней. можно еще интеллектуальную песочницу сделать: смоделируй деятельность ГО и получи годовой абонемент на егов без глюков...
УПД3. Чувствую наведут на меня порчу сотрудники ГО без чувства юмора...
Ссылка - https://www.gov.kz/memleket/entities/mdai/documents/details/606493?lang=ru
#егов #ИИ
😁6
Еще о моделировании данных и мышлении
Читаю Matthew West - Developing High Quality Data Models.
Коротко об авторе:
По образованию химик, работал в Shell, с 1987 года стал айтишником со специализацией в управлении данными. Внес ключевой вклад в разработку стандартов ISO 15926 и ISO 1887. Эти стандарты (кто не знает) разрабатывались для задач обмена информацией между промышленными предприятиями – там, где предприятий сотни и тысячи, номенклатура объектов – много-много миллионов и надо как-то интегрироваться, обмениваться данными в длинных производственных цепочках.
Чем хороша книга:
1. По ходу раскрывает не только приемы моделирования данных, но и поневоле показывает принципы человеческого мышления относительно выделения понятий, отношений между понятиями.
2. Дает много практических советов относительно разработки моделей данных. В частности, много рассказывает о типовых проблемах моделирования исторических данных, четырехмерных объектов, событий и состояний и т.д. и т.п.
3. В приложении дает обширный набор шаблонов данных из ISO 15926.
4. Возникает соблазн использовать книгу как хрестоматию для обучения а) мышления, б) моделирования данных (наряду с книгой Партриджа).
Недостатки:
1. Для совсем незнакомых с принципами реляционных БД многое будет непонятно.
2. Для тех, у кого сложности с понятийным мышлением, желательно для начала прочитать учебник логики.
Ссылку на английский текст книги я давал пару постов выше (можно найти поиском либо по тэгам). На русский перевожу по ходу чтения – так проще читать не торопясь – готово уже 9 глав (всего теоретических глав – 16, полкниги занимают шаблоны данных).
Ссылка на русский перевод – https://docs.google.com/document/d/1kvqJ4aI6Hr2gcNbNB96QFNCJWuDIW-Ri5JTDHn6X_ek/edit?usp=sharing
#уэст #моделированиеданных #перевод
Читаю Matthew West - Developing High Quality Data Models.
Коротко об авторе:
По образованию химик, работал в Shell, с 1987 года стал айтишником со специализацией в управлении данными. Внес ключевой вклад в разработку стандартов ISO 15926 и ISO 1887. Эти стандарты (кто не знает) разрабатывались для задач обмена информацией между промышленными предприятиями – там, где предприятий сотни и тысячи, номенклатура объектов – много-много миллионов и надо как-то интегрироваться, обмениваться данными в длинных производственных цепочках.
Чем хороша книга:
1. По ходу раскрывает не только приемы моделирования данных, но и поневоле показывает принципы человеческого мышления относительно выделения понятий, отношений между понятиями.
2. Дает много практических советов относительно разработки моделей данных. В частности, много рассказывает о типовых проблемах моделирования исторических данных, четырехмерных объектов, событий и состояний и т.д. и т.п.
3. В приложении дает обширный набор шаблонов данных из ISO 15926.
4. Возникает соблазн использовать книгу как хрестоматию для обучения а) мышления, б) моделирования данных (наряду с книгой Партриджа).
Недостатки:
1. Для совсем незнакомых с принципами реляционных БД многое будет непонятно.
2. Для тех, у кого сложности с понятийным мышлением, желательно для начала прочитать учебник логики.
Ссылку на английский текст книги я давал пару постов выше (можно найти поиском либо по тэгам). На русский перевожу по ходу чтения – так проще читать не торопясь – готово уже 9 глав (всего теоретических глав – 16, полкниги занимают шаблоны данных).
Ссылка на русский перевод – https://docs.google.com/document/d/1kvqJ4aI6Hr2gcNbNB96QFNCJWuDIW-Ri5JTDHn6X_ek/edit?usp=sharing
#уэст #моделированиеданных #перевод
👍7🔥1
Об архитектуре требований, viewpoint’ах, view (1/2)
Сегодня Денис Гобов рассказывал для Казахстанского чаптера IIBA про Анализ требований и определение дизайна, и вкратце среди прочего про архитектуру требований, viewpoint’ы и view.
Судя по вопросам про архитектуру тема для слушателей непростая. Есть повод повторить и сравнить подходы к определению архитектуры из BABOK Guide и ISO 42010 (Systems and software engineering. Architecture description).
BABOK Guide:
• Архитектура требований — это структура всех требований изменения.
• Точка зрения (viewpoint) — это набор соглашений, определяющих как представляются требования, как эти представления организуются, и как они будут связаны. Точки зрения дают шаблоны для учета интересов конкретных групп заинтересованных сторон.
• Представление (view) - фактические требования и дизайны для конкретного решения с выбранной точки зрения. Набор представлений образует архитектуру требований конкретного решения.
Обратите внимание, что определение архитектуры требований в BABOK Guide противоречиво: с одной стороны, это «структура требований», в другом месте это «набор представлений», т.е. архитектура включает в себя содержание требований. Возникает неизбежный вопрос, всё-таки «архитектура требований» - это «набор представлений (описаний, view)» или «структура всех требований»?
ISO 42010:
• Архитектура – основные понятия или свойства системы в окружающей среде, воплощенной в ее элементах, отношениях и конкретных принципах ее проекта и развития.
• Описание архитектуры (architecture description) – рабочий продукт, используемый для выражения архитектуры.
• Точка зрения (viewpoint) – рабочий продукт, устанавливающий условности конструирования, интерпретации и использования архитектурного представления для структуризации определенных системных интересов.
• Представление (view) – рабочий продукт, выражающий архитектуру некоторой системы с точки зрения определенных системных интересов.
Для сравнения терминологии BABOK Guide и ISO 42010 необходимо учитывать, что ISO 42010 рассматривает архитектуру «системы», а BABOK Guide рассматривает архитектуру «требований», которые по сути являются описанием «системы», т.е. «архитектуру описания системы». Если толкователи BABOK Guide будут держать в голове подход, выраженный ISO 42010, то они будут считать, что архитектура требований - это основные свойства набора требований, выраженные во представлениях (view), но а) это не простая сумма всех view, б) это не просто «структура» требований. Dixi.
Однако, на самом деле, начиная пост, я просто хотел привлечь внимание к двум важным понятиям:
• Viewpoint.
• View.
Для системной инженерии и бизнес-анализа это очень важные понятия. Viewpoint переводят на русский по-разному: аспект, точка зрения, способ описания. View – представление, описание.
#системнаяинженерия #бизнесанализ
Сегодня Денис Гобов рассказывал для Казахстанского чаптера IIBA про Анализ требований и определение дизайна, и вкратце среди прочего про архитектуру требований, viewpoint’ы и view.
Судя по вопросам про архитектуру тема для слушателей непростая. Есть повод повторить и сравнить подходы к определению архитектуры из BABOK Guide и ISO 42010 (Systems and software engineering. Architecture description).
BABOK Guide:
• Архитектура требований — это структура всех требований изменения.
• Точка зрения (viewpoint) — это набор соглашений, определяющих как представляются требования, как эти представления организуются, и как они будут связаны. Точки зрения дают шаблоны для учета интересов конкретных групп заинтересованных сторон.
• Представление (view) - фактические требования и дизайны для конкретного решения с выбранной точки зрения. Набор представлений образует архитектуру требований конкретного решения.
Обратите внимание, что определение архитектуры требований в BABOK Guide противоречиво: с одной стороны, это «структура требований», в другом месте это «набор представлений», т.е. архитектура включает в себя содержание требований. Возникает неизбежный вопрос, всё-таки «архитектура требований» - это «набор представлений (описаний, view)» или «структура всех требований»?
ISO 42010:
• Архитектура – основные понятия или свойства системы в окружающей среде, воплощенной в ее элементах, отношениях и конкретных принципах ее проекта и развития.
• Описание архитектуры (architecture description) – рабочий продукт, используемый для выражения архитектуры.
• Точка зрения (viewpoint) – рабочий продукт, устанавливающий условности конструирования, интерпретации и использования архитектурного представления для структуризации определенных системных интересов.
• Представление (view) – рабочий продукт, выражающий архитектуру некоторой системы с точки зрения определенных системных интересов.
Для сравнения терминологии BABOK Guide и ISO 42010 необходимо учитывать, что ISO 42010 рассматривает архитектуру «системы», а BABOK Guide рассматривает архитектуру «требований», которые по сути являются описанием «системы», т.е. «архитектуру описания системы». Если толкователи BABOK Guide будут держать в голове подход, выраженный ISO 42010, то они будут считать, что архитектура требований - это основные свойства набора требований, выраженные во представлениях (view), но а) это не простая сумма всех view, б) это не просто «структура» требований. Dixi.
Однако, на самом деле, начиная пост, я просто хотел привлечь внимание к двум важным понятиям:
• Viewpoint.
• View.
Для системной инженерии и бизнес-анализа это очень важные понятия. Viewpoint переводят на русский по-разному: аспект, точка зрения, способ описания. View – представление, описание.
#системнаяинженерия #бизнесанализ
❤3🔥1
Об архитектуре требований, viewpoint’ах, view (2/2)
Viewpoint – это о том, что у разных сторон есть различные интересы (concern) относительно системы, и им не нужны все возможные описания системы. Собственника бизнеса интересуют одни аспекты, и он хочет видеть описания своего бизнеса и своей инфраструктуры со стороны своих интересов – под его интересы формируется один или несколько viewpoint, а под каждый viewpoint формируются свои view. В физическом мире мы видим как аналитики, архитекторы и разработчики для владельца делают специальные документы: концепцию, business requirement specification и т.д.
У финансового директора, соответственно свои интересы, свои viewpoint и ему нужны свои view. У технического директора – третье. У архитектора – четвертое. У руководителя службы безопасности – пятое. И так далее.
Концепция viewpoint-view позволяет очень детально и очень гибко описывать даже очень сложные системы, при этом сохранять различные уровни абстрактности для описания архитектуры. Инструментально это реализовано, например, в стандарте описания архитектуры archimate и редакторах поддерживающих стандарт: вы можете для каждой диаграммы устанавливать небходимые viewpoint’ы.
Если усвоить в работе с системами, архитектурой, требованиями этот подход деления на viewpoint’ы-view, то работать становится проще: при взаимодействии с различными стейкхолдерами вы сразу анализируете их интересы (concerns) относительно системы, выясняете их viewpoint’ы и планируете какие view вы для них должно готовить.
Диаграмма связи этих архитектурных понятий на картинке ниже.
Ссылки:
1. Стандарт ISO 42010 – https://docs.cntd.ru/document/1200139542
2. Стандарт Archimate – https://pubs.opengroup.org/architecture/archimate3-doc/ch-Stakeholders-Architecture-Views-and-Viewpoints.html
3. Вебинар по анализу требований и определению дизайна –
https://youtu.be/3HMgHd_N_7o?si=bSY-n65YOBXJUwnz
#системнаяинженерия #бизнесанализ
Viewpoint – это о том, что у разных сторон есть различные интересы (concern) относительно системы, и им не нужны все возможные описания системы. Собственника бизнеса интересуют одни аспекты, и он хочет видеть описания своего бизнеса и своей инфраструктуры со стороны своих интересов – под его интересы формируется один или несколько viewpoint, а под каждый viewpoint формируются свои view. В физическом мире мы видим как аналитики, архитекторы и разработчики для владельца делают специальные документы: концепцию, business requirement specification и т.д.
У финансового директора, соответственно свои интересы, свои viewpoint и ему нужны свои view. У технического директора – третье. У архитектора – четвертое. У руководителя службы безопасности – пятое. И так далее.
Концепция viewpoint-view позволяет очень детально и очень гибко описывать даже очень сложные системы, при этом сохранять различные уровни абстрактности для описания архитектуры. Инструментально это реализовано, например, в стандарте описания архитектуры archimate и редакторах поддерживающих стандарт: вы можете для каждой диаграммы устанавливать небходимые viewpoint’ы.
Если усвоить в работе с системами, архитектурой, требованиями этот подход деления на viewpoint’ы-view, то работать становится проще: при взаимодействии с различными стейкхолдерами вы сразу анализируете их интересы (concerns) относительно системы, выясняете их viewpoint’ы и планируете какие view вы для них должно готовить.
Диаграмма связи этих архитектурных понятий на картинке ниже.
Ссылки:
1. Стандарт ISO 42010 – https://docs.cntd.ru/document/1200139542
2. Стандарт Archimate – https://pubs.opengroup.org/architecture/archimate3-doc/ch-Stakeholders-Architecture-Views-and-Viewpoints.html
3. Вебинар по анализу требований и определению дизайна –
https://youtu.be/3HMgHd_N_7o?si=bSY-n65YOBXJUwnz
#системнаяинженерия #бизнесанализ
🔥5
Принципы технического экспресс-перевода
Есть важные книги, для которых нет русского перевода, и которые нужно читать медленно, перечитывая несколько раз. Читать не за 1-2 дня, но, минимум, 1-2 недели. Перечитывая не потому что слабо владеешь языком оригинала, а потому что темы сложные и за одно прочтение не разберешься. Очевидно, что если делаешь заметки по прочитанному, то понимаешь и запоминаешь лучше. Но можно не просто делать заметки, но сразу делать и перевод на русский – при этом а) ты и внимательно прочитываешь каждое слово, б) пишешь, формулируешь мысли автора на родном языке, в) на выходе после чтения остается русский текст, которым можно поделиться с теми, кто не может читать свободно по-английски.
Вчера закончил перевод для такой книги – Matthew West «Developing High Quality Data Models». Понял для себя несколько особенностей такого перевода в процессе чтения:
1. Невозможно книгу из 400 страниц перевести качественно за неделю. Для качественного перевода нужны не 1-2 недели, но 1-2 месяца полной занятости минимум.
2. Однако, можно за неделю перевести книгу так, чтобы она была доступной и understandable для людей, слабо владеющих английским.
3. Системы машинного перевода за последние несколько лет очень сильно эволюционировали – можно смело ими пользоваться с тем, чтобы не переписывать за них каждое предложение. Однако каждое предложение за ними нужно проверять.
4. Много времени занимает перевод диаграмм и рисунков – поэтому я их не перевожу.
5. Если машинный перевод отдельного предложения грамматически правильный и понятный, хотя стилистически не очень (типа, русские обычно так не говорят), то я оставляю машинный вариант.
6. Если машинный перевод предложения звучит по-русски непонятно, то начинаем разбираться почему: непонятно по причине плохого машинного перевода или по причине сложности темы или по причине туманности авторской мысли? При любом варианте приходится переводить предложение «вручную»: если причиной непонятности была слабость машинного перевода то предложение становится понятным, если сложность темы или авторский стиль – тут уж извините…
7. Копипаста через систему машинного перевода, форматирование текста и вставка иллюстраций занимает по времени 1-2 дня работы. Внимательное чтение и редактирование текста – 5-6 дней работы.
Мэтью Уэст хорош, большой молодец, я много открыл для себя в моделировании данных – но об этом в другой раз…
#перевод #мышлениеписьмом #уэст
Есть важные книги, для которых нет русского перевода, и которые нужно читать медленно, перечитывая несколько раз. Читать не за 1-2 дня, но, минимум, 1-2 недели. Перечитывая не потому что слабо владеешь языком оригинала, а потому что темы сложные и за одно прочтение не разберешься. Очевидно, что если делаешь заметки по прочитанному, то понимаешь и запоминаешь лучше. Но можно не просто делать заметки, но сразу делать и перевод на русский – при этом а) ты и внимательно прочитываешь каждое слово, б) пишешь, формулируешь мысли автора на родном языке, в) на выходе после чтения остается русский текст, которым можно поделиться с теми, кто не может читать свободно по-английски.
Вчера закончил перевод для такой книги – Matthew West «Developing High Quality Data Models». Понял для себя несколько особенностей такого перевода в процессе чтения:
1. Невозможно книгу из 400 страниц перевести качественно за неделю. Для качественного перевода нужны не 1-2 недели, но 1-2 месяца полной занятости минимум.
2. Однако, можно за неделю перевести книгу так, чтобы она была доступной и understandable для людей, слабо владеющих английским.
3. Системы машинного перевода за последние несколько лет очень сильно эволюционировали – можно смело ими пользоваться с тем, чтобы не переписывать за них каждое предложение. Однако каждое предложение за ними нужно проверять.
4. Много времени занимает перевод диаграмм и рисунков – поэтому я их не перевожу.
5. Если машинный перевод отдельного предложения грамматически правильный и понятный, хотя стилистически не очень (типа, русские обычно так не говорят), то я оставляю машинный вариант.
6. Если машинный перевод предложения звучит по-русски непонятно, то начинаем разбираться почему: непонятно по причине плохого машинного перевода или по причине сложности темы или по причине туманности авторской мысли? При любом варианте приходится переводить предложение «вручную»: если причиной непонятности была слабость машинного перевода то предложение становится понятным, если сложность темы или авторский стиль – тут уж извините…
7. Копипаста через систему машинного перевода, форматирование текста и вставка иллюстраций занимает по времени 1-2 дня работы. Внимательное чтение и редактирование текста – 5-6 дней работы.
Мэтью Уэст хорош, большой молодец, я много открыл для себя в моделировании данных – но об этом в другой раз…
#перевод #мышлениеписьмом #уэст
🔥5👍4
Развитие и модернизация ИС
Задали вопрос чем отличается развитие от модернизации в контексте разработки ПО – для использования в официальной документации. Спрашивали – отвечаем:
1. В обыденном русском языке развитие и модернизация – синонимы. Тексты по социологии выделяют оттенки этих понятий: развитие – органичный рост системы (в данном случае социальной), реализация присущего системе потенциала изменений; модернизация – изменения в строго заданном направлении, перенимание и внедрение уже существующих в других местах образцов.
2. В казахстанском законе «Об информатизации» модернизация – часть развития, не касающаяся изменений в функциональности: «Ст.1 п. 6-1) развитие объекта информатизации - этап жизненного цикла объекта информатизации, на протяжении которого осуществляется комплекс мероприятий по реализации дополнительных функциональных требований, а также модернизации объекта информатизации».
3. В международных стандартах термин развитие для ПО, кажется, не используется. Вероятно, потому что за термином «development» закреплено понятие, которое в русском языке передается термином «разработка». Вместо этого используются термины «адаптивная модернизация» и «полная модернизация». Причем, разделение между ними проходит не по основанию «добавляем или нет новую функциональность», а по основанию цели изменений. Адаптивная модернизация выполняется в рамках адаптивного сопровождения программного средства для обеспечения работоспособности в изменяющейся операционной среде. Полная модернизация выполняется в рамках полного сопровождения в интересах пользователя. Т.е. и адаптивная и полная модернизация может затрагивать функциональность ПО, различие между ними – в объеме и цели изменений (См. ИСО/МЭК 14764-2002).
4. Российская нормативная практика, если смотреть на официальные комментарии Минцифры, ориентируется на ИСО/МЭК 14764-2002.
5. Можно также посмотреть эти термины в ШСМ А.Левенчука – там есть понятие метода работы/практики. Метод работы включает в себя а) технологии/инструменты; б) дисциплину/методику. Если меняются только технологии – то это модернизация, т.е. меняются только инструменты: писали тексты в одном приложении, потом поставили более современное, но задачи и способы написания текстов не изменились. Если изменили методы работы, дисциплину (например, тексты перестали писать копирайтеры, а стал генерировать ИИ на основе спецификаций требований, ну или вообще перешли на видео вместо текстов) – то это развитие.
Резюме: Если вы пишете спецификацию или договор, то лучше в тексте полностью раскрывать понятия, давать четкие определения. Иначе вы можете понимать под модернизацией обновление версий ОС, а заказчик – разработку дополнительной функциональности любого объема. Или наоборот.
Ссылки:
• ИСО/МЭК 14764-2002 "Информационная технология. Сопровождение программных средств" – https://files.stroyinf.ru/Data2/1/4294817/4294817040.pdf
• «Об информатизации» Закон Республики Казахстан от 24 ноября 2015 года № 418-V ЗРК – https://adilet.zan.kz/rus/docs/Z1500000418
#развитие #модернизация
Задали вопрос чем отличается развитие от модернизации в контексте разработки ПО – для использования в официальной документации. Спрашивали – отвечаем:
1. В обыденном русском языке развитие и модернизация – синонимы. Тексты по социологии выделяют оттенки этих понятий: развитие – органичный рост системы (в данном случае социальной), реализация присущего системе потенциала изменений; модернизация – изменения в строго заданном направлении, перенимание и внедрение уже существующих в других местах образцов.
2. В казахстанском законе «Об информатизации» модернизация – часть развития, не касающаяся изменений в функциональности: «Ст.1 п. 6-1) развитие объекта информатизации - этап жизненного цикла объекта информатизации, на протяжении которого осуществляется комплекс мероприятий по реализации дополнительных функциональных требований, а также модернизации объекта информатизации».
3. В международных стандартах термин развитие для ПО, кажется, не используется. Вероятно, потому что за термином «development» закреплено понятие, которое в русском языке передается термином «разработка». Вместо этого используются термины «адаптивная модернизация» и «полная модернизация». Причем, разделение между ними проходит не по основанию «добавляем или нет новую функциональность», а по основанию цели изменений. Адаптивная модернизация выполняется в рамках адаптивного сопровождения программного средства для обеспечения работоспособности в изменяющейся операционной среде. Полная модернизация выполняется в рамках полного сопровождения в интересах пользователя. Т.е. и адаптивная и полная модернизация может затрагивать функциональность ПО, различие между ними – в объеме и цели изменений (См. ИСО/МЭК 14764-2002).
4. Российская нормативная практика, если смотреть на официальные комментарии Минцифры, ориентируется на ИСО/МЭК 14764-2002.
5. Можно также посмотреть эти термины в ШСМ А.Левенчука – там есть понятие метода работы/практики. Метод работы включает в себя а) технологии/инструменты; б) дисциплину/методику. Если меняются только технологии – то это модернизация, т.е. меняются только инструменты: писали тексты в одном приложении, потом поставили более современное, но задачи и способы написания текстов не изменились. Если изменили методы работы, дисциплину (например, тексты перестали писать копирайтеры, а стал генерировать ИИ на основе спецификаций требований, ну или вообще перешли на видео вместо текстов) – то это развитие.
Резюме: Если вы пишете спецификацию или договор, то лучше в тексте полностью раскрывать понятия, давать четкие определения. Иначе вы можете понимать под модернизацией обновление версий ОС, а заказчик – разработку дополнительной функциональности любого объема. Или наоборот.
Ссылки:
• ИСО/МЭК 14764-2002 "Информационная технология. Сопровождение программных средств" – https://files.stroyinf.ru/Data2/1/4294817/4294817040.pdf
• «Об информатизации» Закон Республики Казахстан от 24 ноября 2015 года № 418-V ЗРК – https://adilet.zan.kz/rus/docs/Z1500000418
#развитие #модернизация
👍8🔥2
Кто такой аналитик бизнес-данных
Закончил перевод стандарта от IIBA Руководство по аналитике бизнес-данных. Стандарт выстроен примерно по той же схеме что и другие стандарты:
• Введение
• Области знаний (домены).
• Типовые задачи, которые решают аналитики.
• Техники (методы работы), которые используются для решения задач.
Кроме того, в отличие от BABOK Guide, здесь присутствуют в количестве практические примеры из реальной жизни – как та или иная компания решали свои проблемы с помощью аналитики данных, а также по каждому домену приводится разбор учебного кейса – в этом Руководство по аналитике бизнес-данных легче использовать как учебник, чем BABOK Guide.
Роль аналитика бизнес-данных в данном стандарте занимает примерно такое же место как роль бизнес-аналитика в BABOK Guide.
В BABOK Guide цепочка ролей от бизнес к технологиям выглядит примерно так: Эксперт предметной области – Бизнес-аналитик – Технический специалист. На реальном рынке это может быть даже Эксперт предметной области – Бизнес-аналитик – Системный аналитик – Технический специалист (разработчик). Понятно, что на практике иногда сотрудник может в одном лице исполнять некоторые смежные роли.
В руководстве по аналитике бизнес-данных цепочка ролей получается примерно следующая: Эксперт предметной области – Аналитик бизнес-данных – Специалист по обработке данных (data scientist) – Технический специалист (data engineer, разработчик).
Аналитик бизнес-данных – это не просто специалист по данным, которые умеет работать с данными знает технические инструменты и статистические методы (за этим лучше идти к дата-сайентистам), но это тот кто:
1. Может понять проблемы бизнеса и поставить правильные вопросы для решения с помощью данных: сформулировать гипотезы и спланировать исследование.
2. Может найти, изучить источники данных, получить из них релевантные данные.
3. Может выполнить анализ полученных данных.
4. Может выполнить правильную интерпретацию данных и подготовить отчеты по данным.
5. Может выполнить задачи по использованию результатов исследования для влияния на принятие бизнес-решений.
6. Может участвовать в управлении стратегией организации в области аналитики бизнес-данных.
О задачах, которые необходимо решать, чтобы всё это делать, в общих чертах и рассказывает стандарт на 200 страницах.
Ссылка на страницу IIBA с официальной информацией о стандарте и сертификации - https://www.iiba.org/business-analysis-certifications/business-data-analytics-certification/
#бизнесанализ #датаналитика #iiba #babok #cdba
Закончил перевод стандарта от IIBA Руководство по аналитике бизнес-данных. Стандарт выстроен примерно по той же схеме что и другие стандарты:
• Введение
• Области знаний (домены).
• Типовые задачи, которые решают аналитики.
• Техники (методы работы), которые используются для решения задач.
Кроме того, в отличие от BABOK Guide, здесь присутствуют в количестве практические примеры из реальной жизни – как та или иная компания решали свои проблемы с помощью аналитики данных, а также по каждому домену приводится разбор учебного кейса – в этом Руководство по аналитике бизнес-данных легче использовать как учебник, чем BABOK Guide.
Роль аналитика бизнес-данных в данном стандарте занимает примерно такое же место как роль бизнес-аналитика в BABOK Guide.
В BABOK Guide цепочка ролей от бизнес к технологиям выглядит примерно так: Эксперт предметной области – Бизнес-аналитик – Технический специалист. На реальном рынке это может быть даже Эксперт предметной области – Бизнес-аналитик – Системный аналитик – Технический специалист (разработчик). Понятно, что на практике иногда сотрудник может в одном лице исполнять некоторые смежные роли.
В руководстве по аналитике бизнес-данных цепочка ролей получается примерно следующая: Эксперт предметной области – Аналитик бизнес-данных – Специалист по обработке данных (data scientist) – Технический специалист (data engineer, разработчик).
Аналитик бизнес-данных – это не просто специалист по данным, которые умеет работать с данными знает технические инструменты и статистические методы (за этим лучше идти к дата-сайентистам), но это тот кто:
1. Может понять проблемы бизнеса и поставить правильные вопросы для решения с помощью данных: сформулировать гипотезы и спланировать исследование.
2. Может найти, изучить источники данных, получить из них релевантные данные.
3. Может выполнить анализ полученных данных.
4. Может выполнить правильную интерпретацию данных и подготовить отчеты по данным.
5. Может выполнить задачи по использованию результатов исследования для влияния на принятие бизнес-решений.
6. Может участвовать в управлении стратегией организации в области аналитики бизнес-данных.
О задачах, которые необходимо решать, чтобы всё это делать, в общих чертах и рассказывает стандарт на 200 страницах.
Ссылка на страницу IIBA с официальной информацией о стандарте и сертификации - https://www.iiba.org/business-analysis-certifications/business-data-analytics-certification/
#бизнесанализ #датаналитика #iiba #babok #cdba
🔥4
Моделирование данных: нормализация vs. онтология (1/2)
Нормализация – это подход к моделированию данных, при котором проектировщики стремятся устранить избыточность данных. Если вы ведете учет товаров на складе, то вам не важно вы храните насосы или хрустальную посуду – вам нужны только название, маркировка, размер. Поэтому, скорее всего вы будете хранить данные по товарам в одной таблице – вся нужная информация по объектам хранения вполне может быть описана несколькими полями реляционной таблицы. При проектировании с точки зрения нормализации борьба идет за форму хранения – чтобы данные хранились компактно, а что там за объекты реального мира кроются за данными – не важно. Правда, у нормального подхода есть недостаток: как только возникает необходимость по хрустальной посуде хранить дополнительную информацию, то нормальную модель нужно переделывать, и, соответственно, информационную систему.
Онтологический подход – это подход, при котором проектировщики стремятся к тому, чтобы их модель по возможности адекватно отражала реальный мир. Если вы проектируете модель данных для процессов производства, использования и обслуживания насосного оборудования, то вам неудобно будет использовать одинаковое описание для насосов и для хрустальной посуды – вы проектируете различные типы насосов (их сотни), которые имеют различное устройство, изготавливаются из различных материалов и по-разному используются. У каждого насоса может быть собственный жизненный цикл, от момента начала проектирования до утилизации. Каждый насос может фигурировать в большом количестве информационных систем, в которых его проектируют, производят, хранят, используют, и эти информационные системы могут обмениваться между собой данными о конструкциях насосов и о конкретных изделиях, их состоянии. Для того чтобы такой обмен данным был возможен, информационная модель насоса должна как можно точнее отображать реальный мир, «жизнь» насоса – тогда с большой вероятностью этой моделью смогут пользоваться и проектировщики, и производственники, и пользователи оборудования.
Все проектировщики моделей данных знают интересное свойство сего занятия: попроси двух проектировщиков построить модель одной и той же предметной области – получится две совершенно разных и, часто, несовместимых модели. Причем несовместимых не из-за разных названий, но и по существу. Отсюда рождается предположение: если мир проектировать исходя не из удобства и компактности хранения данных, а из его физических свойств, то модели у разных проектировщиков должны получаться более-менее одинаковые. Правда, о способах «правильного» онтологического описания реального мира тоже нужно договориться – а то на примере истории философии мы можем увидеть, что философские онтологии могут быть абсолютно несовместимыми. Технические онтологии должны быть универсальными, упрощать взаимопонимание насколько это возможно и в то же время точно отражать физические свойства моделируемых объектов.
К чему привели попытки договориться о правилах онтологического моделирования?
#моделирование #моделированиеданных #boro #hqdm #gellish
Нормализация – это подход к моделированию данных, при котором проектировщики стремятся устранить избыточность данных. Если вы ведете учет товаров на складе, то вам не важно вы храните насосы или хрустальную посуду – вам нужны только название, маркировка, размер. Поэтому, скорее всего вы будете хранить данные по товарам в одной таблице – вся нужная информация по объектам хранения вполне может быть описана несколькими полями реляционной таблицы. При проектировании с точки зрения нормализации борьба идет за форму хранения – чтобы данные хранились компактно, а что там за объекты реального мира кроются за данными – не важно. Правда, у нормального подхода есть недостаток: как только возникает необходимость по хрустальной посуде хранить дополнительную информацию, то нормальную модель нужно переделывать, и, соответственно, информационную систему.
Онтологический подход – это подход, при котором проектировщики стремятся к тому, чтобы их модель по возможности адекватно отражала реальный мир. Если вы проектируете модель данных для процессов производства, использования и обслуживания насосного оборудования, то вам неудобно будет использовать одинаковое описание для насосов и для хрустальной посуды – вы проектируете различные типы насосов (их сотни), которые имеют различное устройство, изготавливаются из различных материалов и по-разному используются. У каждого насоса может быть собственный жизненный цикл, от момента начала проектирования до утилизации. Каждый насос может фигурировать в большом количестве информационных систем, в которых его проектируют, производят, хранят, используют, и эти информационные системы могут обмениваться между собой данными о конструкциях насосов и о конкретных изделиях, их состоянии. Для того чтобы такой обмен данным был возможен, информационная модель насоса должна как можно точнее отображать реальный мир, «жизнь» насоса – тогда с большой вероятностью этой моделью смогут пользоваться и проектировщики, и производственники, и пользователи оборудования.
Все проектировщики моделей данных знают интересное свойство сего занятия: попроси двух проектировщиков построить модель одной и той же предметной области – получится две совершенно разных и, часто, несовместимых модели. Причем несовместимых не из-за разных названий, но и по существу. Отсюда рождается предположение: если мир проектировать исходя не из удобства и компактности хранения данных, а из его физических свойств, то модели у разных проектировщиков должны получаться более-менее одинаковые. Правда, о способах «правильного» онтологического описания реального мира тоже нужно договориться – а то на примере истории философии мы можем увидеть, что философские онтологии могут быть абсолютно несовместимыми. Технические онтологии должны быть универсальными, упрощать взаимопонимание насколько это возможно и в то же время точно отражать физические свойства моделируемых объектов.
К чему привели попытки договориться о правилах онтологического моделирования?
#моделирование #моделированиеданных #boro #hqdm #gellish
🔥4
Моделирование данных: нормализация vs. онтология (2/2)
1. Крис Партридж популярно объяснил о сложностях разработки правильных онтологий, выделил базовые сущности моделирования, обосновал необходимость думать о физических объектах, как о 4D – пространственно-временных протяженностях.
2. Группа специалистов разработала набор стандартов ISO 15926, как лингва франка обмена данными между независимыми информационными системами. По некоторым сведениям использование подхода, описанного в данном стандарте позволяет многократно сократить затраты на интеграционные проекты.
3. Некоторые соавторы ISO 15926 продолжили работу над улучшением решений, предложенных в стандарте. Мэтью Вест предложил свой вариант – HQDM (High Quality Data Modelling), Андрис ван Ренссен – Gellish (он с середины 90-х годов начал разрабатывать свой «Общий инженерный язык», как универсальный язык инженерного проектирования, который в итоги превратился в язык концептуального моделирования данных).
4. Параллельно с подачи Э.Эванса возникла идеология DDD – domain-driven design, которая не про интеграции, а про адаптивность в рамках одной системы: если мы спроектируем программные объекты системы по возможности отражающими реальный мир, то систему будет легче развивать.
В чем проблема онтологического подхода к данным?
1. Мышление людей сильно привязано к объект-атрибутной парадигме, корни которой уходят еще к Аристотелю (об этом много пишет Партридж).
2. Проектируя сложные системы и интеграции, люди теряются в сложности, как правило, плохо понимая, что многие сложности возникают не только из-за сложности предметной области, но и из-за подхода к проектированию.
3. Пока не созданы популярные и надежные решения, позволяющие реализовать онтологический подход к проектированию.
4. Другое)
Мораль: без рационального и осознанного онтологического проектирования тяжело жить даже на уровне создания отдельных сложных систем, а когда дело доходит до уровня крупного холдинга, отрасли или егов – разработка экосистемы превращается в непрерывный эпикфэйл.
О базовых объектах онтологий и прочих приятных вещах – в следующих постах.
#моделирование #моделированиеданных #boro #hqdm #gellish
1. Крис Партридж популярно объяснил о сложностях разработки правильных онтологий, выделил базовые сущности моделирования, обосновал необходимость думать о физических объектах, как о 4D – пространственно-временных протяженностях.
2. Группа специалистов разработала набор стандартов ISO 15926, как лингва франка обмена данными между независимыми информационными системами. По некоторым сведениям использование подхода, описанного в данном стандарте позволяет многократно сократить затраты на интеграционные проекты.
3. Некоторые соавторы ISO 15926 продолжили работу над улучшением решений, предложенных в стандарте. Мэтью Вест предложил свой вариант – HQDM (High Quality Data Modelling), Андрис ван Ренссен – Gellish (он с середины 90-х годов начал разрабатывать свой «Общий инженерный язык», как универсальный язык инженерного проектирования, который в итоги превратился в язык концептуального моделирования данных).
4. Параллельно с подачи Э.Эванса возникла идеология DDD – domain-driven design, которая не про интеграции, а про адаптивность в рамках одной системы: если мы спроектируем программные объекты системы по возможности отражающими реальный мир, то систему будет легче развивать.
В чем проблема онтологического подхода к данным?
1. Мышление людей сильно привязано к объект-атрибутной парадигме, корни которой уходят еще к Аристотелю (об этом много пишет Партридж).
2. Проектируя сложные системы и интеграции, люди теряются в сложности, как правило, плохо понимая, что многие сложности возникают не только из-за сложности предметной области, но и из-за подхода к проектированию.
3. Пока не созданы популярные и надежные решения, позволяющие реализовать онтологический подход к проектированию.
4. Другое)
Мораль: без рационального и осознанного онтологического проектирования тяжело жить даже на уровне создания отдельных сложных систем, а когда дело доходит до уровня крупного холдинга, отрасли или егов – разработка экосистемы превращается в непрерывный эпикфэйл.
О базовых объектах онтологий и прочих приятных вещах – в следующих постах.
#моделирование #моделированиеданных #boro #hqdm #gellish
👍5🔥1
Предел Ходжсона по Переслегину
Слушал лекцию Переслегина о проблемах оснований в математике и физике. Показаны проблемы взаимодействия онтологий, возникающих на различных предметных областях: теории чисел, теории множеств, геометрии, классической механики, термодинамики, электродинамики, теории излучения. В результате попыток создания Единой Теории Всего возникает квантовая механика и квантовая теория поля. Однако, новая теория «нефизична». В итоге, по мнению автора, в 20 веке в науке возникает кризис, который он называет «пределом Ходжсона» (термин придумал Сергей Шилов по аналогии с пределом Лейбница).
Предел Лейбница – это невозможность в одной голове уместить все науки – он был достигнут в 18 веке. Это «не травмирующий» предел – люди (ученые) легко смиряются с тем, что всего понять нельзя. Предел Ходжсона – травмирующий: это невозможность логически объединить в рамках одной науки разные направления исследований, при этом любые попытки объединить приводят к неприемлемым для мышления результатам. Предел Ходжсона достигается либо когда в рамках науки необходимо создать обобщающую теорию, а это не получается, либо когда по результатам рефлексии о созданной Теории Всего нужно вернуться к осмыслению оснований и всё заново перестроить стройно и логично в непротиворечивую теорию. Физика столкнулась с пределом понимания, математика столкнулась с пределом рефлексии.
В результате достижения этого предела ученые прилагают усилия, чтобы остановить парадигмальное развитие своей науки (им страшно), при этом локальное развитие возможно (иди и считай – это не страшно). В физике заставили поверить в существование промежуточного бозона Хикса (чтобы скрыть страх непонимания), в математике произошел переход к модели Цермело-Френкеля, которая не позволяет рефлексировать её основания.
На очереди подход к пределу Ходжсона экономики, эволюционной биологии и антропологии.
Почему предел назвали в честь Ходжсона – был такой фантаст в начале 20 в., с которого западная фантастика свернула с позитивного направления в хоррор, в ощущение онтологического трансцендентного зла (за ним Лавкрафт, Стивен Кинг и прочие). Отдельно можно поговорить как предел познания сказывается на состоянии культуры и политики – всеобщее ощущения конца истории, либо, наоборот, грядущих катастроф – откуда-то оттуда.
Кроме пределов Лейбница и Ходжсона Переслегин говорит еще о двух пределах познания, которые он именует пределами Ницше и Хокинга – об этом в другой раз (или никогда – и прекрасному есть предел, однако).
Ссылки:
1. 4-й предел познания. Почему наука не будет прежней. С. Переслегин, Д. Перетолчин. - https://dzen.ru/video/watch/61b0b998261b1a2ac63d64c9
2. Сергей Переслегин. Лекция №8. Предел Ходжсона и возникновение квантового подхода. Ч.1 - https://www.youtube.com/watch?v=IeoyODhBspA&ab_channel=%D0%A1%D0%9E%D0%A6%D0%98%D0%9E%D0%A1%D0%9E%D0%A4%D0%A2.%D0%A2%D0%92
3. Сергей Переслегин. Лекция №8. Предел Ходжсона и возникновение квантового подхода. Ч.2 https://www.youtube.com/watch?v=JgKhC2-SnSI&list=PLVJKvxv2YVRKQC07WZpmcQ8_xSpAo2lgA&index=12&ab_channel=%D0%A1%D0%9E%D0%A6%D0%98%D0%9E%D0%A1%D0%9E%D0%A4%D0%A2.%D0%A2%D0%92
#философиянауки #переслегин
Слушал лекцию Переслегина о проблемах оснований в математике и физике. Показаны проблемы взаимодействия онтологий, возникающих на различных предметных областях: теории чисел, теории множеств, геометрии, классической механики, термодинамики, электродинамики, теории излучения. В результате попыток создания Единой Теории Всего возникает квантовая механика и квантовая теория поля. Однако, новая теория «нефизична». В итоге, по мнению автора, в 20 веке в науке возникает кризис, который он называет «пределом Ходжсона» (термин придумал Сергей Шилов по аналогии с пределом Лейбница).
Предел Лейбница – это невозможность в одной голове уместить все науки – он был достигнут в 18 веке. Это «не травмирующий» предел – люди (ученые) легко смиряются с тем, что всего понять нельзя. Предел Ходжсона – травмирующий: это невозможность логически объединить в рамках одной науки разные направления исследований, при этом любые попытки объединить приводят к неприемлемым для мышления результатам. Предел Ходжсона достигается либо когда в рамках науки необходимо создать обобщающую теорию, а это не получается, либо когда по результатам рефлексии о созданной Теории Всего нужно вернуться к осмыслению оснований и всё заново перестроить стройно и логично в непротиворечивую теорию. Физика столкнулась с пределом понимания, математика столкнулась с пределом рефлексии.
В результате достижения этого предела ученые прилагают усилия, чтобы остановить парадигмальное развитие своей науки (им страшно), при этом локальное развитие возможно (иди и считай – это не страшно). В физике заставили поверить в существование промежуточного бозона Хикса (чтобы скрыть страх непонимания), в математике произошел переход к модели Цермело-Френкеля, которая не позволяет рефлексировать её основания.
На очереди подход к пределу Ходжсона экономики, эволюционной биологии и антропологии.
Почему предел назвали в честь Ходжсона – был такой фантаст в начале 20 в., с которого западная фантастика свернула с позитивного направления в хоррор, в ощущение онтологического трансцендентного зла (за ним Лавкрафт, Стивен Кинг и прочие). Отдельно можно поговорить как предел познания сказывается на состоянии культуры и политики – всеобщее ощущения конца истории, либо, наоборот, грядущих катастроф – откуда-то оттуда.
Кроме пределов Лейбница и Ходжсона Переслегин говорит еще о двух пределах познания, которые он именует пределами Ницше и Хокинга – об этом в другой раз (или никогда – и прекрасному есть предел, однако).
Ссылки:
1. 4-й предел познания. Почему наука не будет прежней. С. Переслегин, Д. Перетолчин. - https://dzen.ru/video/watch/61b0b998261b1a2ac63d64c9
2. Сергей Переслегин. Лекция №8. Предел Ходжсона и возникновение квантового подхода. Ч.1 - https://www.youtube.com/watch?v=IeoyODhBspA&ab_channel=%D0%A1%D0%9E%D0%A6%D0%98%D0%9E%D0%A1%D0%9E%D0%A4%D0%A2.%D0%A2%D0%92
3. Сергей Переслегин. Лекция №8. Предел Ходжсона и возникновение квантового подхода. Ч.2 https://www.youtube.com/watch?v=JgKhC2-SnSI&list=PLVJKvxv2YVRKQC07WZpmcQ8_xSpAo2lgA&index=12&ab_channel=%D0%A1%D0%9E%D0%A6%D0%98%D0%9E%D0%A1%D0%9E%D0%A4%D0%A2.%D0%A2%D0%92
#философиянауки #переслегин
👍5🔥3
Пет-проекты для аналитиков – насколько реально?
Сегодня с коллегой (Даурен Айтенов) коснулись вопроса о системных аналитиках: «Проводя много собеседований, часто удивляюсь отсутствию желания расти самостоятельно у БА и СА, знают практически нифига... Единицы, например спецы: НИТ, РЦЭЗ, ЦРТР, внедряли системы и в целом и этапность и доки через себя пропускали и как говорится вспоминая свой опыт - отвечают на часть вопросов, но остальные крайний ахтунг...». Даурен предлагает придумать удобную форму для пет-проектов аналитиков, с помощью которых они могли бы учиться и которые можно было бы показывать на собеседованиях.
Итак, pet-проекты – это личные проекты, над которыми специалист работает в тренировочных целях. Зачем они нужны:
1. Для самообучения.
2. Для демонстрации своего профессионализма.
В какой форме аналитики могли бы делать свои пет-проекты:
1. Концепция системы.
2. Концепция + прототип.
3. Бизнес-канвас + cjm + бэклог для продукта.
4. BRD + SRS + план работ.
5. Любой набор концептуального описания, логического и технического проектирования.
Пет-проект по анализу должен по возможности касаться всех аспектов гипотетического проекта, акценты могут быть разные: у аналитика на продуктовой разработке может быть акцент на анализе рынка и рыночных гипотезах, у системного аналитика – на проработке технических решений, интеграций, моделей данных и т.д. – кто на что учился (хочет научиться).
Личный пет-проект удобен еще и тем, что под него проще находить менторов и учебные материалы: проработка под руководством ментора сильно ускорит процесс обучения и позволит перенять у ментора рабочие практики и подходы.
Ну и про перспективы найма можно сказать точно – когда специалист на собеседовании рассказывает про конкретный проект, для которого он сам придумывал решения, может обосновать свои подходы, методы и объяснить почему он выбрал те или иные решения – это производит чрезвычайно выгодное впечатление. Обычно это могут делать только высококвалифицированные специалисты с многолетним опытом – те, которые работали ведущими аналитиками на серьезных проектах. Джуны и мидлы обычно «пилят» отдельные «куски» систем и не несут серьезной ответственности за успех проекта в целом – поэтому на концептуальные вопросы касательно проекта в целом и способов его реализации внятно ответить не могут – они с этой стороны и не думали. Точкой роста здесь может стать личный пет-проект – это хороший способ научиться продемонстрировать своё системное мышление и специфические навыки, в которых вы сильны.
В связи с этим возникают вопросы:
1. Насколько реально создать моду на пет-проекты по анализу?
2. Не нужно ли для этого создать ряд рекомендуемых шаблонов?
3. Не нужно ли создать моду на менторство по разработке пет-проектов?
4. Не нужно ли создать моду на «если ты закончил курс по БА и у тебя нет личного пет-проекта – ты отучился зря»?
Предлагаю обсудить.
Примечание: я знаю про хорошую практику личных проектов в некоторых школах и курсах по БА/СА – речь не о счастливых исключениях, а о широкой практике и потоке тех кандидатов, которые приходят к нам на собеседование.
#бизнесанализ #системныйанализ
Сегодня с коллегой (Даурен Айтенов) коснулись вопроса о системных аналитиках: «Проводя много собеседований, часто удивляюсь отсутствию желания расти самостоятельно у БА и СА, знают практически нифига... Единицы, например спецы: НИТ, РЦЭЗ, ЦРТР, внедряли системы и в целом и этапность и доки через себя пропускали и как говорится вспоминая свой опыт - отвечают на часть вопросов, но остальные крайний ахтунг...». Даурен предлагает придумать удобную форму для пет-проектов аналитиков, с помощью которых они могли бы учиться и которые можно было бы показывать на собеседованиях.
Итак, pet-проекты – это личные проекты, над которыми специалист работает в тренировочных целях. Зачем они нужны:
1. Для самообучения.
2. Для демонстрации своего профессионализма.
В какой форме аналитики могли бы делать свои пет-проекты:
1. Концепция системы.
2. Концепция + прототип.
3. Бизнес-канвас + cjm + бэклог для продукта.
4. BRD + SRS + план работ.
5. Любой набор концептуального описания, логического и технического проектирования.
Пет-проект по анализу должен по возможности касаться всех аспектов гипотетического проекта, акценты могут быть разные: у аналитика на продуктовой разработке может быть акцент на анализе рынка и рыночных гипотезах, у системного аналитика – на проработке технических решений, интеграций, моделей данных и т.д. – кто на что учился (хочет научиться).
Личный пет-проект удобен еще и тем, что под него проще находить менторов и учебные материалы: проработка под руководством ментора сильно ускорит процесс обучения и позволит перенять у ментора рабочие практики и подходы.
Ну и про перспективы найма можно сказать точно – когда специалист на собеседовании рассказывает про конкретный проект, для которого он сам придумывал решения, может обосновать свои подходы, методы и объяснить почему он выбрал те или иные решения – это производит чрезвычайно выгодное впечатление. Обычно это могут делать только высококвалифицированные специалисты с многолетним опытом – те, которые работали ведущими аналитиками на серьезных проектах. Джуны и мидлы обычно «пилят» отдельные «куски» систем и не несут серьезной ответственности за успех проекта в целом – поэтому на концептуальные вопросы касательно проекта в целом и способов его реализации внятно ответить не могут – они с этой стороны и не думали. Точкой роста здесь может стать личный пет-проект – это хороший способ научиться продемонстрировать своё системное мышление и специфические навыки, в которых вы сильны.
В связи с этим возникают вопросы:
1. Насколько реально создать моду на пет-проекты по анализу?
2. Не нужно ли для этого создать ряд рекомендуемых шаблонов?
3. Не нужно ли создать моду на менторство по разработке пет-проектов?
4. Не нужно ли создать моду на «если ты закончил курс по БА и у тебя нет личного пет-проекта – ты отучился зря»?
Предлагаю обсудить.
Примечание: я знаю про хорошую практику личных проектов в некоторых школах и курсах по БА/СА – речь не о счастливых исключениях, а о широкой практике и потоке тех кандидатов, которые приходят к нам на собеседование.
#бизнесанализ #системныйанализ
👍9🔥3❤1
Рациональность, войны и Левенчук 🙂 (1/2)
Встрял в сети в дискуссию по поводу свежего поста Анатолия Левенчука на тему, что если делать людей умнее, то войн будет меньше.
Левенчук начал свою просветительскую деятельность с обучения магистрантов системной инженерии. Несмотря на то, что его ученики были сравнительно подготовлены (например, это могла быть магистратура МФТИ), практика показала, что большинство учеников имеют проблемы с понятийным мышлением и с системностью мышления. В связи с этим появилось несколько подготовительных курсов: моделирование, системное мышление, системное саморазвитие.
На практике было выявлено, что если обучать группу людей (профессиональных инженеров с высшим образованием), то нормальное понятийное мышление доступно примерно 10% учеников, которые имеют большие проблемы с усвоением системной инженерии. Если “ставить” мышление предварительными курсами то системная инженерия становится доступной почти всем ученикам. Вокруг курсов и книг Левенчука образовалась ШСМ - школа системного менеджмента - своеобразная инженерно-менеджерская школа, которую прошли уже тысячи людей. Обучение, кстати, доступное: все материалы в свободном доступе, если нужна возможность выполнять домашние задание и тесты, то стоимость - 700 р. в месяц, если нужны специальные занятия с преподавателем - тогда гораздо дороже. Сейчас в ШСМ опубликовано 12 курсов, рассчитанных на 3 года вдумчивого изучения. Впрочем, самостоятельно курсы можно проходить в произвольном порядке в собственном темпе. Что мне больше всего нравится в текстах Левенчука - его стремление быть “на фронтире” научного знания и пользоваться последними достижениями в изучаемых дисциплинах, т.н. SOTA - state of the art, т.е. тексты курсов и книги непрерывно обновляются и изменяются, вплоть до корректировки междисциплинарной онтологии, благодаря этому удобно следить что происходит нового в междисциплинарном мире и как взаимодействуют между собой идеи ведущих специалистов в физике, математике, инженерии, философии науки, этике, экономике.
Краткий перечень идеологических предпочтений Левенчука:
1. Атеизм.
2. Либертарианство.
3. Австрийская экономическая школа.
4. Космополитизм.
Впрочем, учебные материалы не являются пропагандой идеологии - предлагается предельно рациональный подход на основе идеи: чтобы договариваться нужно прежде всего уметь понимать чужие картины мира, чужую этику, чужое мировоззрение. Не говоря уже о том, что нужно уметь моделировать и разбираться с собственной картиной мира.
Так, панегирик завершу, теперь о войне.
#мышление #война #левенчук #шсм #пинкер #дойч
Встрял в сети в дискуссию по поводу свежего поста Анатолия Левенчука на тему, что если делать людей умнее, то войн будет меньше.
Левенчук начал свою просветительскую деятельность с обучения магистрантов системной инженерии. Несмотря на то, что его ученики были сравнительно подготовлены (например, это могла быть магистратура МФТИ), практика показала, что большинство учеников имеют проблемы с понятийным мышлением и с системностью мышления. В связи с этим появилось несколько подготовительных курсов: моделирование, системное мышление, системное саморазвитие.
На практике было выявлено, что если обучать группу людей (профессиональных инженеров с высшим образованием), то нормальное понятийное мышление доступно примерно 10% учеников, которые имеют большие проблемы с усвоением системной инженерии. Если “ставить” мышление предварительными курсами то системная инженерия становится доступной почти всем ученикам. Вокруг курсов и книг Левенчука образовалась ШСМ - школа системного менеджмента - своеобразная инженерно-менеджерская школа, которую прошли уже тысячи людей. Обучение, кстати, доступное: все материалы в свободном доступе, если нужна возможность выполнять домашние задание и тесты, то стоимость - 700 р. в месяц, если нужны специальные занятия с преподавателем - тогда гораздо дороже. Сейчас в ШСМ опубликовано 12 курсов, рассчитанных на 3 года вдумчивого изучения. Впрочем, самостоятельно курсы можно проходить в произвольном порядке в собственном темпе. Что мне больше всего нравится в текстах Левенчука - его стремление быть “на фронтире” научного знания и пользоваться последними достижениями в изучаемых дисциплинах, т.н. SOTA - state of the art, т.е. тексты курсов и книги непрерывно обновляются и изменяются, вплоть до корректировки междисциплинарной онтологии, благодаря этому удобно следить что происходит нового в междисциплинарном мире и как взаимодействуют между собой идеи ведущих специалистов в физике, математике, инженерии, философии науки, этике, экономике.
Краткий перечень идеологических предпочтений Левенчука:
1. Атеизм.
2. Либертарианство.
3. Австрийская экономическая школа.
4. Космополитизм.
Впрочем, учебные материалы не являются пропагандой идеологии - предлагается предельно рациональный подход на основе идеи: чтобы договариваться нужно прежде всего уметь понимать чужие картины мира, чужую этику, чужое мировоззрение. Не говоря уже о том, что нужно уметь моделировать и разбираться с собственной картиной мира.
Так, панегирик завершу, теперь о войне.
#мышление #война #левенчук #шсм #пинкер #дойч
👍6🔥1
Рациональность, войны и Левенчук 🙂 (2/2)
В отношении к различным войнам Левенчук обычно нейтрален: воюющие стороны стоят друг друга и ничем друг друга не лучше. Политика и идеология всех государств - порочна. В посте повторяется мысль о том, что войны - от неумности, и что главное - просвещать людей: “Без … массового образования будут продолжаться все проблемы (войны, локдауны для победы над ковидом, религиозная промывка мозгов, допотопное образование, очень плохая наука, феномены типа биг фармы в медицине, несть этим бедам числа), которые вроде как требуют немедленной с ними борьбы, хотя эта борьба оказывается вполне тщетной. Я считаю, что не хватает знаний (оптимизм по Дойчу), чтобы прорваться, для знаний нужны просто неглупые люди, а их можно взять -- и научить. Надо только (возвращаюсь к предыдущему пункту из трёх шагов):
-- знать, чему учить
-- иметь материалы курсов,
-- развернуть инфраструктуру дешёвого качественного обучения”.
В целом мне нравится направление мыслей Левенчука, на мой взгляд оно беспроигрышное, даже если ничего не получится - качественное образование это всегда хорошо. Единственно я сделал несколько замечаний по теме:
Гипотеза 1. Если политиков, военных и инженеров из ОПК провести через курсы ШСМ, то воевать они от этого меньше не станут.
Гипотеза 2. Если какая-то из сторон массово обучит своих политиков, инженеров и военных на курсах ШСМ, то получит некоторое военное преимущество.
Гипотеза 3. Гуманизм, как и приемлемость войн, связаны с эволюцией сознания. Способность к эмпатии, готовность делиться пищей с неродственными особями, как и готовность жертвовать своей жизнью или жизнью части собственной популяции ради выживания популяции в целом - эволюционные биологические явления, для изменения которых курсов ШСМ будет недостаточно, если только курсы не вырастут в систему эволюционного отбора в "правильном" направлении (с точки зрения создателей системы).
Гипотеза 4. Если люди становятся умнее, то им проще понимать и свою этику и этику других, а также они будут видеть больше вариантов решений, и, если есть склонность к гуманности, то легче будет находить взаимоприемлемые решения, не связанные со смертоубийством или грубым насилием.
Гипотеза 5. Есть общий исторический тренд в сторону гуманизации, который как-то связан с просвещением - это пытаются доказывать Д.Дойч и С.Пинкер. Если смотреть на периоде в несколько сот лет, то можно видеть несомненную гуманизацию человечества - предположительно это связано с просвещением и образованием. Утверждение, конечно, спорное, но хочется ему верить.
Мораль: безусловно нужно учиться самому и учить других. Учеба должна идти в сторону прагматизма и рационализма - это поможет договариваться людям разных культур и рас (учеба шаманским практикам, нумерологии и гаданию по картам Таро не об этом).
Ссылки:
Пост А.Левенчука “Работать с причиной, а не следствиями: массово делать людей и AI умнее” на сайте клуба ШСМ - https://systemsworld.club/t/rabotat-s-prichinoj-a-ne-sledstviyami-massovo-delat-lyudej-i-ai-umnee/11437
Пост А.Левенчука в ЖЖ - https://ailev.livejournal.com/1719578.html
Собственно сайт ШСМ - https://aisystant.system-school.ru/
Стивен Пинкер. Просвещение продолжается - https://ozon.kz/product/prosveshchenie-prodolzhaetsya-v-zashchitu-razuma-nauki-gumanizma-i-progressa-nauchno-299227090/
#мышление #война #левенчук #шсм #пинкер #дойч
В отношении к различным войнам Левенчук обычно нейтрален: воюющие стороны стоят друг друга и ничем друг друга не лучше. Политика и идеология всех государств - порочна. В посте повторяется мысль о том, что войны - от неумности, и что главное - просвещать людей: “Без … массового образования будут продолжаться все проблемы (войны, локдауны для победы над ковидом, религиозная промывка мозгов, допотопное образование, очень плохая наука, феномены типа биг фармы в медицине, несть этим бедам числа), которые вроде как требуют немедленной с ними борьбы, хотя эта борьба оказывается вполне тщетной. Я считаю, что не хватает знаний (оптимизм по Дойчу), чтобы прорваться, для знаний нужны просто неглупые люди, а их можно взять -- и научить. Надо только (возвращаюсь к предыдущему пункту из трёх шагов):
-- знать, чему учить
-- иметь материалы курсов,
-- развернуть инфраструктуру дешёвого качественного обучения”.
В целом мне нравится направление мыслей Левенчука, на мой взгляд оно беспроигрышное, даже если ничего не получится - качественное образование это всегда хорошо. Единственно я сделал несколько замечаний по теме:
Гипотеза 1. Если политиков, военных и инженеров из ОПК провести через курсы ШСМ, то воевать они от этого меньше не станут.
Гипотеза 2. Если какая-то из сторон массово обучит своих политиков, инженеров и военных на курсах ШСМ, то получит некоторое военное преимущество.
Гипотеза 3. Гуманизм, как и приемлемость войн, связаны с эволюцией сознания. Способность к эмпатии, готовность делиться пищей с неродственными особями, как и готовность жертвовать своей жизнью или жизнью части собственной популяции ради выживания популяции в целом - эволюционные биологические явления, для изменения которых курсов ШСМ будет недостаточно, если только курсы не вырастут в систему эволюционного отбора в "правильном" направлении (с точки зрения создателей системы).
Гипотеза 4. Если люди становятся умнее, то им проще понимать и свою этику и этику других, а также они будут видеть больше вариантов решений, и, если есть склонность к гуманности, то легче будет находить взаимоприемлемые решения, не связанные со смертоубийством или грубым насилием.
Гипотеза 5. Есть общий исторический тренд в сторону гуманизации, который как-то связан с просвещением - это пытаются доказывать Д.Дойч и С.Пинкер. Если смотреть на периоде в несколько сот лет, то можно видеть несомненную гуманизацию человечества - предположительно это связано с просвещением и образованием. Утверждение, конечно, спорное, но хочется ему верить.
Мораль: безусловно нужно учиться самому и учить других. Учеба должна идти в сторону прагматизма и рационализма - это поможет договариваться людям разных культур и рас (учеба шаманским практикам, нумерологии и гаданию по картам Таро не об этом).
Ссылки:
Пост А.Левенчука “Работать с причиной, а не следствиями: массово делать людей и AI умнее” на сайте клуба ШСМ - https://systemsworld.club/t/rabotat-s-prichinoj-a-ne-sledstviyami-massovo-delat-lyudej-i-ai-umnee/11437
Пост А.Левенчука в ЖЖ - https://ailev.livejournal.com/1719578.html
Собственно сайт ШСМ - https://aisystant.system-school.ru/
Стивен Пинкер. Просвещение продолжается - https://ozon.kz/product/prosveshchenie-prodolzhaetsya-v-zashchitu-razuma-nauki-gumanizma-i-progressa-nauchno-299227090/
#мышление #война #левенчук #шсм #пинкер #дойч
SystemsWorld Club
Работать с причиной, а не следствиями: массово делать людей и AI умнее
Войны – следствия незнания, незнание – следствие неумности. Надо массово делать людей и AI умнее Пока в мире идёт ползучая мировая война, я продолжаю работать: я уже довольно много провёл времени (десятки лет) в разных проектах в попытках изменить мир к…
👍5🔥2
Литература, новости и кино - человечество как совокупность интегрированных систем (1/2)
Саясат Нурбек, когда не был еще министром, любил читать лекции о литературе и кино - о том как анализировать художественные произведения с точки зрения анализа “пути героя”, по мотивам книги Джозефа Кэмпбелла “Тысячеликий герой”. Кэмпбелл проанализировал мировую литературу с точки зрения пути героя, разделив ее примерно на 17 стадий: жизнь, призвание, отказ от зова, помощь наставника и т.д. Идея Кэмпбелла (и Саясата) - при помощи этого метода можно понять любое художественное произведение.
Мне всегда этот подход казался примитивизацией анализа художественных произведений. На одной из лекций я задал Саясату вопрос: хорошо, путь героя, а кто главный герой у Чехова в “Вишневом саду”, и кто главный герой в “Форресте Гампе”? Про “Вишневый сад” лектор умолчал (там, если кто не помнит, небольшой театр абсурда, герой - не человек, уходящая эпоха), а про Форреста Гампа сказал только, что образ Форреста - это аллюзия на Иисуса Христа, само присутствие которого меняет жизни окружающих людей. То есть напрямую, если не “натягивать сову на глобус”, этот подход не работает даже на многих известных произведениях. Почему примитивизация? Я объясню)
Кейс Савельева
Есть такой профессор Сергей Савельев, который много занимается проблема определения структуры человеческого мозга - цитоархитектоники. Он утверждает, что пока не построен томограф с разрешением в 1 воксель определять способность человека к различным типам мышления можно только через тексты - как человек пишет и анализирует тексты. При этом есть уровни понимания текста по возрастающей сложности:
1. Анализ фабулы (сюжета).
2. Анализ структуры текста (построение фраз, структура текста в целом).
3. Анализ контекста (кто автор, почему и зачем автор говорит что говорит, почему он говорит именно так, почему ты, читая, воспринимаешь так как воспринимаешь и т.д.).
Так вот, анализ пути героя - это, как правило, только самый простой уровень - анализ фабулы. За бортом рассмотрения остается структура, эмоциональные инструменты повествования, контекст.
Кейс общества как совокупности вычислительных систем
Для того, чтобы понять место художественного произведения в обществе мне нравится понятная для айтишников метафора общества как совокупности вычислительных систем:
#мышление #литература #кэмпбелл #савельев #пропп
Саясат Нурбек, когда не был еще министром, любил читать лекции о литературе и кино - о том как анализировать художественные произведения с точки зрения анализа “пути героя”, по мотивам книги Джозефа Кэмпбелла “Тысячеликий герой”. Кэмпбелл проанализировал мировую литературу с точки зрения пути героя, разделив ее примерно на 17 стадий: жизнь, призвание, отказ от зова, помощь наставника и т.д. Идея Кэмпбелла (и Саясата) - при помощи этого метода можно понять любое художественное произведение.
Мне всегда этот подход казался примитивизацией анализа художественных произведений. На одной из лекций я задал Саясату вопрос: хорошо, путь героя, а кто главный герой у Чехова в “Вишневом саду”, и кто главный герой в “Форресте Гампе”? Про “Вишневый сад” лектор умолчал (там, если кто не помнит, небольшой театр абсурда, герой - не человек, уходящая эпоха), а про Форреста Гампа сказал только, что образ Форреста - это аллюзия на Иисуса Христа, само присутствие которого меняет жизни окружающих людей. То есть напрямую, если не “натягивать сову на глобус”, этот подход не работает даже на многих известных произведениях. Почему примитивизация? Я объясню)
Кейс Савельева
Есть такой профессор Сергей Савельев, который много занимается проблема определения структуры человеческого мозга - цитоархитектоники. Он утверждает, что пока не построен томограф с разрешением в 1 воксель определять способность человека к различным типам мышления можно только через тексты - как человек пишет и анализирует тексты. При этом есть уровни понимания текста по возрастающей сложности:
1. Анализ фабулы (сюжета).
2. Анализ структуры текста (построение фраз, структура текста в целом).
3. Анализ контекста (кто автор, почему и зачем автор говорит что говорит, почему он говорит именно так, почему ты, читая, воспринимаешь так как воспринимаешь и т.д.).
Так вот, анализ пути героя - это, как правило, только самый простой уровень - анализ фабулы. За бортом рассмотрения остается структура, эмоциональные инструменты повествования, контекст.
Кейс общества как совокупности вычислительных систем
Для того, чтобы понять место художественного произведения в обществе мне нравится понятная для айтишников метафора общества как совокупности вычислительных систем:
#мышление #литература #кэмпбелл #савельев #пропп
🔥3
Литература, новости и кино - человечество как совокупность интегрированных систем (2/2)
1. Представьте себе много информационных систем, которые обмениваются друг с другом и со своими подсистемами различными сообщениями, необходимыми как для выполнения собственных функций, так и для синхронизации каких-то процессов деятельности.
2. Сообщения могут иметь сложную структуру: данные для использования, программный код, метаданные, которые что-то говорят об источниках и промежуточных точках сообщений.
3. Мышление процесс коллективный: каждый человек - это своего рода вычислительная система, семья, социальные группы, организации, государства - тоже являются вычислительными системами, модулями, подсистемами. Обмен сообщениями позволяют выстраивать взаимодействие между этими системами.
4. Художественные произведения, публицистика, новости, любого рода информация - это своего рода сообщения между человеческими системами. При этом сообщения могут нести как исполняемый код, так и данные, так и метаданные. Исполняемый код - это прямые инструкции, либо образцы для подражания (путь героя). Данные - это сопутствующая информация, настройки (эмоции, картина мира). Метаданные - это информация с отпечатками обработки сообщений в различных системах и подсистемах.
5. Теперь представьте что вы что-то прочитали или посмотрели: вы как система получили сообщение. Что вы можете из него узнать: а) принять его как инструкцию на исполнение; б) что-то выяснить об источниках сообщения; в) что-то выяснить об общей системной архитектуре; г) что-то выяснить о целях генератора или посредников сообщения; д) что-то выяснить о себе - почему вы обработали сообщения определенным образом (нет ли у вас ошибки в принимающем сервисе или структуре данных - мировоззрении).
Также надо учитывать, что человек самопринадлежен - у каждого человека есть индивидуальный суверенитет, право лично определять способ обработки поступающей информации. Читая книгу, новости или просматривая видео, при наличии соответствующих вычислительных способностей и хороших моделей обработки данных, человек может сам проанализировать сообщение и понять (хотя бы частично): что здесь код для исполнения, какие данные ему преподносят и какова совокупная вычислительная архитектура, связанная с полученным сообщением.
Мораль: ты - не робот, ты - суверен в собственном мышлении, ты можешь сам перестраивать свои вычислительные способности, ты должен уметь системно понимать входящие сообщения и сам решать что тебе принимать к исполнению и какие данные учитывать.
Кейс Проппа
Нельзя говорить об анализе текста и не упомянуть с уважением Владимира Яковлевича Проппа. Задолго до Кэмпбелла Пропп открыл эту тему, и он же ее закрыл, причем на всех уровнях анализа текста - никто из последователей, в общем-то, не вышел за рамки обдуманного Проппом. Dixi.
Ссылки:
- Джозеф Кэмпбелл. Тысячеликий герой.
- Сергей Савельев. Изменчивость и гениальность.
- Владимир Пропп. Исторические корни волшебной сказки.
#мышление #литература #кэмпбелл #савельев #пропп
1. Представьте себе много информационных систем, которые обмениваются друг с другом и со своими подсистемами различными сообщениями, необходимыми как для выполнения собственных функций, так и для синхронизации каких-то процессов деятельности.
2. Сообщения могут иметь сложную структуру: данные для использования, программный код, метаданные, которые что-то говорят об источниках и промежуточных точках сообщений.
3. Мышление процесс коллективный: каждый человек - это своего рода вычислительная система, семья, социальные группы, организации, государства - тоже являются вычислительными системами, модулями, подсистемами. Обмен сообщениями позволяют выстраивать взаимодействие между этими системами.
4. Художественные произведения, публицистика, новости, любого рода информация - это своего рода сообщения между человеческими системами. При этом сообщения могут нести как исполняемый код, так и данные, так и метаданные. Исполняемый код - это прямые инструкции, либо образцы для подражания (путь героя). Данные - это сопутствующая информация, настройки (эмоции, картина мира). Метаданные - это информация с отпечатками обработки сообщений в различных системах и подсистемах.
5. Теперь представьте что вы что-то прочитали или посмотрели: вы как система получили сообщение. Что вы можете из него узнать: а) принять его как инструкцию на исполнение; б) что-то выяснить об источниках сообщения; в) что-то выяснить об общей системной архитектуре; г) что-то выяснить о целях генератора или посредников сообщения; д) что-то выяснить о себе - почему вы обработали сообщения определенным образом (нет ли у вас ошибки в принимающем сервисе или структуре данных - мировоззрении).
Также надо учитывать, что человек самопринадлежен - у каждого человека есть индивидуальный суверенитет, право лично определять способ обработки поступающей информации. Читая книгу, новости или просматривая видео, при наличии соответствующих вычислительных способностей и хороших моделей обработки данных, человек может сам проанализировать сообщение и понять (хотя бы частично): что здесь код для исполнения, какие данные ему преподносят и какова совокупная вычислительная архитектура, связанная с полученным сообщением.
Мораль: ты - не робот, ты - суверен в собственном мышлении, ты можешь сам перестраивать свои вычислительные способности, ты должен уметь системно понимать входящие сообщения и сам решать что тебе принимать к исполнению и какие данные учитывать.
Кейс Проппа
Нельзя говорить об анализе текста и не упомянуть с уважением Владимира Яковлевича Проппа. Задолго до Кэмпбелла Пропп открыл эту тему, и он же ее закрыл, причем на всех уровнях анализа текста - никто из последователей, в общем-то, не вышел за рамки обдуманного Проппом. Dixi.
Ссылки:
- Джозеф Кэмпбелл. Тысячеликий герой.
- Сергей Савельев. Изменчивость и гениальность.
- Владимир Пропп. Исторические корни волшебной сказки.
#мышление #литература #кэмпбелл #савельев #пропп
🔥3👍1
Плюсы и минусы цеттельскастена в канале телеграм
«Не пишешь – значит не думаешь» – из этой идеи рождается практика мышления письмом – ежедневных письменных заметок, постов, статей. За время ведения этого тележного блога, который предназначен быть основным окном моего мышления письмом, я заметил несколько плюсов и минусов такого подхода – возможно будет полезно если кто планирует начать думать более регулярно.
1. Плюс. Публичный блог хорош тем, что заставляет додумывать мысли и придавать им читабельную форму – наличие подписчиков непроизвольно порождает желание не уменьшать их количество.
2. Минус. Наличие подписчиков порождает ожидание лайков – это сбивает фокус с того что, возможно, интересно только автору на поиск тем, которые интересны не только автору.
3. Плюс. Среди сотен подписчиков может найтись два-три человека, которые активно интересуются теми же вопросами – они могут высказать своё «фи», либо «одобрямс», либо подбросить дополнительные идеи для дальнейшего осмысления.
4. Минус. В мозговую кофеварку попадает много вопросов, по которым надо бы сделать заметки, чтобы не забыть важные инсайты, но заметки краткие, которые неуместны в публичном блоге.
5. Минус. На законченный пост я обычно трачу 30-40 минут, но иногда заготовке с постом нужно отлежаться и дозреть – постить заготовку в публичный блог не комильфо.
6. Минус. Иногда мыслительный реактор порождает материал большого объема, который не помещается в пост, и должен быть оформлен в полноценную статью. Для статей нужна более вместительная площадка чем телеграм.
Чтобы избавиться от минусов, вариантом решения может быть следующее:
1. Вести закрытый блог в телеге для заметок и заготовок постов и статей – это обеспечит регулярность и систематичность мышления письмом и отключит негативное влияние наличия аудитории.
2. Вести дальше открытый блог в телеге, может быть не один (если есть желание иметь устойчивую аудиторию): информационно-новостной – отдельно, айтишный – отдельно, гуманитарный – отдельно, что-нибудь ещё – отдельно.
3. Большие статьи можно размещать в открытом блоге по своей теме, только не в телеге (из-за размера), а на другой площадке – в телеге давать только ссылку.
Будем посмотреть что получится. Всем продуктивного мышления!
UPD. Церен Церенов (соучредитель ШСМ) поделился ссылкой на на хорошее видео по теме поста - https://www.youtube.com/watch?v=3k3nhH15le0.
#мышлениеписьмом #zettelkasten
«Не пишешь – значит не думаешь» – из этой идеи рождается практика мышления письмом – ежедневных письменных заметок, постов, статей. За время ведения этого тележного блога, который предназначен быть основным окном моего мышления письмом, я заметил несколько плюсов и минусов такого подхода – возможно будет полезно если кто планирует начать думать более регулярно.
1. Плюс. Публичный блог хорош тем, что заставляет додумывать мысли и придавать им читабельную форму – наличие подписчиков непроизвольно порождает желание не уменьшать их количество.
2. Минус. Наличие подписчиков порождает ожидание лайков – это сбивает фокус с того что, возможно, интересно только автору на поиск тем, которые интересны не только автору.
3. Плюс. Среди сотен подписчиков может найтись два-три человека, которые активно интересуются теми же вопросами – они могут высказать своё «фи», либо «одобрямс», либо подбросить дополнительные идеи для дальнейшего осмысления.
4. Минус. В мозговую кофеварку попадает много вопросов, по которым надо бы сделать заметки, чтобы не забыть важные инсайты, но заметки краткие, которые неуместны в публичном блоге.
5. Минус. На законченный пост я обычно трачу 30-40 минут, но иногда заготовке с постом нужно отлежаться и дозреть – постить заготовку в публичный блог не комильфо.
6. Минус. Иногда мыслительный реактор порождает материал большого объема, который не помещается в пост, и должен быть оформлен в полноценную статью. Для статей нужна более вместительная площадка чем телеграм.
Чтобы избавиться от минусов, вариантом решения может быть следующее:
1. Вести закрытый блог в телеге для заметок и заготовок постов и статей – это обеспечит регулярность и систематичность мышления письмом и отключит негативное влияние наличия аудитории.
2. Вести дальше открытый блог в телеге, может быть не один (если есть желание иметь устойчивую аудиторию): информационно-новостной – отдельно, айтишный – отдельно, гуманитарный – отдельно, что-нибудь ещё – отдельно.
3. Большие статьи можно размещать в открытом блоге по своей теме, только не в телеге (из-за размера), а на другой площадке – в телеге давать только ссылку.
Будем посмотреть что получится. Всем продуктивного мышления!
UPD. Церен Церенов (соучредитель ШСМ) поделился ссылкой на на хорошее видео по теме поста - https://www.youtube.com/watch?v=3k3nhH15le0.
#мышлениеписьмом #zettelkasten
YouTube
В сложной ситуации - пиши
Подробнее читайте в моём телеграм-канале о мышлении письмом: https://t.iss.one/systemsthinkinglife/243
Мышление через письмо: Стратегия для решения сложных ситуаций
В современном мире, где информационный поток непрерывен, а решения нужно принимать быстро, нельзя…
Мышление через письмо: Стратегия для решения сложных ситуаций
В современном мире, где информационный поток непрерывен, а решения нужно принимать быстро, нельзя…
🔥9
Сложности разработки онтологий для айтишников, базовые онтологии Партриджа и Веста (1/2)
Умение анализировать и разрабатывать онтологии предметной области – комплекс довольно сложных навыков. Если ему учить как следует, то нужен как минимум семестр теории и практики. Запишу некоторые базовые идеи:
1. Любая теоретическая и практическая деятельность всегда оперирует понятиями какой-то онтологии. Эта онтология может быть неотрефлексирована, интуитивна, не описана, но она есть. «Онтология» у меня здесь = онтика = система понятий. Я знаю, что сам термин означает «описанную систему понятий» - логия. Но, в конце концов, хотя бы в форме нейронных связей в головах каждого человека складываются некоторые онтологии.
2. Разные люди как правило используют разные онтологии для одной предметной области. Разные онтологии (разная структура системы понятий и разная терминология) – одна из причин почему люди часто друг друга плохо понимают. Чтобы понимать друг друга быстрее для некоторых задач нужно договариваться об общей онтологии.
3. Онтология не может быть правильной или не правильной. Однако онтология может быть более эффективной или менее эффективной для решения некоторых практических задач.
4. Проектировщики баз данных и информационных систем (некоторые) «прокачали» свои онтологические навыки в связи с необходимостью моделирования данных. Раньше онтологическими вопросами занимались только философы, ученые и некоторые хорошо образованные люди.
5. Айтишники сосредоточены на разработке «предметных» онтологий в рамках задач автоматизации. Системы понятий многих видов человеческой деятельности, «гуманитарных», но не только, чрезвычайно сложны, ими айтишники не занимаются.
6. Разработка онтологии – это не разработка структуры БД. Одна и та же онтология предметной области может быть спроектирована чрезвычайно разным образом для одной и той же СУБД.
7. Значительная часть знакомых мне проектировщиков ИС разрабатывают структуры БД, не описывая онтологии, лежащие в их основы, полагая, что «хорошая» структура таблиц – это и есть правильное описание онтологии предметной области. Это ошибка. Наличие «концептуальной модели» –хотя бы частичного описания онтологии сильно упрощает взаимопонимание, а еще сильнее – проекты по развитию, интеграции, миграции данных ИС.
8. Онтология всегда многоуровневая. В задачах автоматизации уровни выглядят, например, так:
a. Первый уровень – реальные физические объекты (например, конкретная ложка с уникальным инвентарным номером. Или, например, конкретная задача по проекту, выполняемая конкретным человеком).
b. Второй уровень – типы объектов (например, для ложки: чайная ложка определенного дизайна; для задачи: задача по разработке API по протоколу SOAP).
c. Третий уровень – типы типов объектов (например, товары на реализацию, запчасти, задачи разработчика).
d. Четвертый уровень – типы типов типов объектов, например, базовые понятия методологии, по которой ведется разработка. Например, стандарт BABOK Guide задает некоторую базовую онтологию для задач по бизнес-анализу, PMBOK задает некоторую базовую онтологию для задач по управлению проектами и т.д. Между этим и предыдущим уровнем может быть еще некоторое количество уровней.
e. Пятый уровень - онтология методологии описания онтологий (например, например 3D- или 4D-протяженность, или, например, базовые типы объектов, приводимые в книгах Партриджа, Веста и проч. – о них дальше). Между этим и предыдущим уровнем также могут «затесаться» другие уровни.
9. Онтологии не всегда иерархия/дерево, может быть и сложный граф. Но об этом долго рассказывать.
10. Базовые понятия Партриджа (5 уровень): объект, отношение, состояние, событие, класс.
#партридж #уэст #бизнесанализ #системнаяинженерия #онтология
Умение анализировать и разрабатывать онтологии предметной области – комплекс довольно сложных навыков. Если ему учить как следует, то нужен как минимум семестр теории и практики. Запишу некоторые базовые идеи:
1. Любая теоретическая и практическая деятельность всегда оперирует понятиями какой-то онтологии. Эта онтология может быть неотрефлексирована, интуитивна, не описана, но она есть. «Онтология» у меня здесь = онтика = система понятий. Я знаю, что сам термин означает «описанную систему понятий» - логия. Но, в конце концов, хотя бы в форме нейронных связей в головах каждого человека складываются некоторые онтологии.
2. Разные люди как правило используют разные онтологии для одной предметной области. Разные онтологии (разная структура системы понятий и разная терминология) – одна из причин почему люди часто друг друга плохо понимают. Чтобы понимать друг друга быстрее для некоторых задач нужно договариваться об общей онтологии.
3. Онтология не может быть правильной или не правильной. Однако онтология может быть более эффективной или менее эффективной для решения некоторых практических задач.
4. Проектировщики баз данных и информационных систем (некоторые) «прокачали» свои онтологические навыки в связи с необходимостью моделирования данных. Раньше онтологическими вопросами занимались только философы, ученые и некоторые хорошо образованные люди.
5. Айтишники сосредоточены на разработке «предметных» онтологий в рамках задач автоматизации. Системы понятий многих видов человеческой деятельности, «гуманитарных», но не только, чрезвычайно сложны, ими айтишники не занимаются.
6. Разработка онтологии – это не разработка структуры БД. Одна и та же онтология предметной области может быть спроектирована чрезвычайно разным образом для одной и той же СУБД.
7. Значительная часть знакомых мне проектировщиков ИС разрабатывают структуры БД, не описывая онтологии, лежащие в их основы, полагая, что «хорошая» структура таблиц – это и есть правильное описание онтологии предметной области. Это ошибка. Наличие «концептуальной модели» –хотя бы частичного описания онтологии сильно упрощает взаимопонимание, а еще сильнее – проекты по развитию, интеграции, миграции данных ИС.
8. Онтология всегда многоуровневая. В задачах автоматизации уровни выглядят, например, так:
a. Первый уровень – реальные физические объекты (например, конкретная ложка с уникальным инвентарным номером. Или, например, конкретная задача по проекту, выполняемая конкретным человеком).
b. Второй уровень – типы объектов (например, для ложки: чайная ложка определенного дизайна; для задачи: задача по разработке API по протоколу SOAP).
c. Третий уровень – типы типов объектов (например, товары на реализацию, запчасти, задачи разработчика).
d. Четвертый уровень – типы типов типов объектов, например, базовые понятия методологии, по которой ведется разработка. Например, стандарт BABOK Guide задает некоторую базовую онтологию для задач по бизнес-анализу, PMBOK задает некоторую базовую онтологию для задач по управлению проектами и т.д. Между этим и предыдущим уровнем может быть еще некоторое количество уровней.
e. Пятый уровень - онтология методологии описания онтологий (например, например 3D- или 4D-протяженность, или, например, базовые типы объектов, приводимые в книгах Партриджа, Веста и проч. – о них дальше). Между этим и предыдущим уровнем также могут «затесаться» другие уровни.
9. Онтологии не всегда иерархия/дерево, может быть и сложный граф. Но об этом долго рассказывать.
10. Базовые понятия Партриджа (5 уровень): объект, отношение, состояние, событие, класс.
#партридж #уэст #бизнесанализ #системнаяинженерия #онтология
👍6🔥3