Просмотр исходного текста страницы Рациональное и системное мышление: практики и компетенции аналитика (AnalystDays-2023)

{{RightNote|[[:Категория:Системное мышление|Еще про системное мышление]]}}
 27-28.10.2023 [https://analystdays.ru/ru/program/109904 '''AnalystDays-2023''']
 [https://analystdays.ru/ru/talk/111854 Доклад на сайте конференции]
 Видео https://vimeo.com/880429828 и https://youtu.be/KpdivjKBxrs 
 Интересное [https://t.me/AnalystDaysChannel/10 обсуждение в чате], перенес [[#Обсуждение в чате|в этот раздел]]
 Продолжение темы доклада '''[[Системное мышление и его место в работе аналитика (AnalystDays-2024a)]]'''

Необходимое умение аналитика – выделять объекты и их взаимосвязи и определять типы и workflow документов, в общем – строить модели. Это надо делать при проведении интервью, анализе документов и Excel-файлов. Обычно для этого используют методы объектно-ориентированного подхода. ООП является частным случаем методов системного мышления, базирующегося на рациональном. Они учат структурировать информацию о мире: выполнять разметку текстов и другого нарратива, строить модели, рассматривая мир как на набор взаимодействующих систем. Понимание этих методов мышления дает мощный аппарат для аналитика для решения сложные задачи. Это аналогично с методами интегрирования: есть частные способы для конкретных интегралов и есть общие подходы. 

В докладе мы поговорим о применении методов рационального и системного мышления для решения задач аналитика. В том числе, разберем ситуации, в которых надо выходить за рамки ООП, решая задачи учета, расписания, бюджетирования и другие.

= Видео =

{{Vimeoembed|880429828|720|405}}

<!--
<div style="padding:56.25% 0 0 0;position:relative;"><iframe src="https://player.vimeo.com/video/880429828?badge=0&amp;autopause=0&amp;player_id=0&amp;app_id=58479" frameborder="0" allow="autoplay; fullscreen; picture-in-picture; clipboard-write" style="position:absolute;top:0;left:0;width:100%;height:100%;" title="Рациональное и системное мышление: практики и компетенции аналитика"></iframe></div><script src="https://player.vimeo.com/api/player.js"></script>

<html><iframe width="560" height="315" src="https://www.youtube.com/embed/KpdivjKBxrs?si=1B-vPpnESOaWxMHG" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe></html>
-->

= Презентация = 

{{Presentation|SysThinking-AD-2023-Tsepkov-CUSTIS.pdf|290px}}

= Обсуждение в чате =

Anton: Очень интересный доклад. Хотелось бы подискутировать с автором, почему он решил начать с ООП, ведь есть более простое решение mind mapping.

Maxim Tsepkov: Потому что mind map как раз является псевдоструктурированной конструкцией, ты можешь рисовать его произвольно - как и писать текст. У них нет метамодели. Есть правила, которые позволяют рисовать хорошие структурированные mind map, но их массово не придерживаются. Татьяна Гаврилова, которая много лет с этим работает и несколько раз рассказывала на Teamlead о них говорит, что у нее нет проблем найти в интернете плохие схемы, а с хорошими - напряженно. ООП - сразу был ориентирован на структурированное представление мира с метамоделью.

Anton: А как же С4 model? Зачем ООП прикручивать к системному анализу?

Maxim Tsepkov: Объектно ориентированное проектирование (Object Oriented Design and Architecture) построено "поверх" системного подхода, он лежит в основе. Потому что ты там имеешь дело с системами, процессами и так далее. Что касается c4model, то это очень конкретная модель слоя технической архитектуры, с небольшим заходом в архитектуру приложений (как эти слои выделяет, например, Archimate). Пока не было контейниризации было достаточно указать хостинг приложений на нодах, а теперь появился еще один уровень абстракции - контейнеры, его добавила c4 model. А все что выше там упаковано в Context. B она - только про софт, части связанные с людьми там практически отсутствуют.

Anton: Исходя из c4  model (https://infostart.ru/pm/1540208/), Контейнер (Container) (приложения и хранилища данных) - Не Docker! В модели C4 контейнер представляет приложение или хранилище данных. Контейнер - это то, что должно быть запущено для работы всей программной системы. В реальном выражении контейнер - это что-то вроде:
* Серверное веб-приложение: Веб-приложение Java EE, работающее на Apache Tomcat, ASP.NET Приложение MVC, работающее на Microsoft IIS, приложение Ruby on Rails, работающее на WEBrick, Node.js применение и т.д.
* Веб-приложение на стороне клиента: Приложение JavaScript, работающее в веб-браузере с использованием Angular, Backbone.JS, jQuery и т.д.
* Клиентское настольное приложение: Настольное приложение Windows, написанное с использованием WPF, настольное приложение OS X, написанное с использованием Objective-C, кроссплатформенное настольное приложение, написанное с использованием JavaFX, и т.д.
* Мобильное приложение: Приложение Apple iOS, приложение для Android, приложение Microsoft Windows Phone и т.д.
* Консольное приложение на стороне сервера: Автономное (например, "public static void main") приложение, пакетный процесс и т.д.
* Бессерверная функция: Одна бессерверная функция (например, Amazon Lambda, функция Azure и т.д.).
База данных: Схема или база данных в системе управления реляционными базами данных, хранилище документов, графическая база данных и т.д., Такие как MySQL, Microsoft SQL Server, база данных Oracle, MongoDB, Riak, Cassandra, Neo4j и т.д.
Хранилище больших двоичных объектов или контента: Хранилище больших двоичных объектов (например, Amazon S3, хранилище больших двоичных объектов Microsoft Azure и т.д.) Или сеть доставки контента (например, Akamai, Amazon CloudFront и т.д.).
* Файловая система: Полная локальная файловая система или часть более крупной сетевой файловой системы (например, SAN, NAS и т. Д.).
* Сценарий оболочки: Один сценарий оболочки, написанный на Bash и т.д.
* и т.д.
Контейнер - это, по сути, контекст или граница, внутри которой выполняется некоторый код или хранятся некоторые данные. И каждый контейнер - это отдельно развертываемая/запускаемая вещь или среда выполнения, обычно (но не всегда) работающая в своем собственном пространстве процессов. Из-за этого связь между контейнерами обычно принимает форму связи между процессами.
: Maxim Tsepkov: Понятно, что контейнер - не обязательно докер. Но до массовой виртуализации и переходе на микросервисы этот уровень абстракции не выделяли, было два основных шаблона для условно-монолитов, 2 и 3 звенная модель, и это можно было рассматривать как уровни в устройстве приложения, физический (tier), в отличие от логических (layer), хотя это как раз часто смешивали. 

Anton: 4-й уровень как раз диаграмма классов. https://www.infoq.com/articles/C4-architecture-model/
: Maxim Tsepkov: Да. но это - диаграмма классов устройства конкретного компонента, и эти классы могут быть связаны с объектами предметной области или совершенно с ними не связаны. Если глянуть в историю, напрмиер, шаблоны программирования Фаулера, то использование объектов предметнй области в качестве классов в реализации - лишь один из шаблонов, Business Objects.

Maxim Tsepkov: Вообще если на уровни c4 model посмотреть с точки зрения системного подхода, то получается очень интересная картина, надо будет о ней еще детальнее подумать. И о сопоставлении этой модели с более ранними архитектурными диаграммами.

Anton: А есть более расширенный доклад, по данной тематике, а также пример описания (с нуля)  таким методом какой-либо системы?
: Maxim Tsepkov: Пока нет, это - мой первый доклад на эту тему. И уже понятно, что надо развивать.

Anton: Просто ваш подход означает, что мы собираем ИТ систему снизу вверх и он имеет место быть, но как бы не получить монолит, либо плохую архитектуру.
: Maxim Tsepkov: Про снизу-вверх просьба пояснить. В докладе был пример слоев Archimate: Business - Application - Technical. B на каждом уровне, в общем случае, своя декомпозиция. Сделаем ли мы при этом монолит или проведем декомпозицию, какую архитектуру построим - другой вопрос. Но Achimate - он преимущественно про софт, там Business layer описывает контекст. А реальная система - включает софт вместе с людьми, которые совместно реализуют процессы, что-то в софте, а что-то - и без него. И насколько монолитной и в какой архитектуре мы ее строим, например, делаем ли мы систему доставки в торговой компании монолитной, или делаем отдельно доставку для интернет-магазина, для доставки из магазинов, для завоза в магазины и для оптовых заказов - это как раз вопрос декомпозиции. И насколько софт должен поддерживать вариации организационной декомпозиции.
: Anton: Простите упустил данный момент. Спасибо

[[Категория:Доклады]][[Категория:Системное мышление]]