Моделирование как способ анализа систем

Моделирование и визуализация при анализе и проектировании ИТ систем. И не только

Проблема

Нет, это не про визуализацию желаний и совсем не про психологию.

IT специалисты применяют моделирование и визуализацию, чтобы упростить анализ объектов. Объекты могут быть разными: корпорации, бизнес-процессы, требования клиентов или информационные системы любых размеров.

Один из великих философов 20-го века, Людвиг Витгенштейн, размышлял о том, как у людей получается обмениваться идеями между собой. Он предположил, что язык запускает в людях картинки объектов реальности. То есть, вслед за словом приходит на ум картинка-модель реальности, она помогает мысленно увидеть ситуацию и понять ее.

Разные ситуации + разный жизненный опыт = разные картинки в голове разных людей. Это мешает качественной передаче информации. Часто, мы и сами не имеем четкой картинки того, что хотим передать.

Современные исследования (например “Picture or Text First? Explaining Sequence Effects when Learning with Pictures and Text” K. Scheiter и A. Eitel) подтверждают, если дополнять текстовую информацию ее визуальной версией – её будет проще понимать и запоминать.

Что такое визуализация и моделирование

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

Модель — упрощенное представление реальности, созданное для передачи информации определенной аудитории для поддержки анализа, коммуникации и понимания (BABOK 3.0).

Модель — представление системы, процесса, услуги или другой сущности, которое используется для понимания и прогнозирования их поведения и взаимодействий (ITIL 4).

У меня было три повода писать это:

В современном мире масса возможностей для саморазвития. Но решить, что полезно и что повысит мою ценность для работодателя — большой вопрос.

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

В команде интеграции важно использовать такие методы донесения информации, которые поймёт команда и специалисты со стороны. Иначе ни с кем не интегрируешься.

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

Кому и почему полезна статья:

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

Опытные: пополнят свой инструментарий, основываясь на практике других аналитиков.

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

Тем, кто хочет работать в IT или смежной сфере

Поймут, чем отличаются модели между собой, какие изучать сначала, а какие потом.

Как собирались данные и проводилось исследование

Данные собирались 2 месяца, в опросе участвовали 193 человека. Большая часть участников — аналитики. Подробный состав будет описан внутри. Опрос проводился среди коллег в различных тематических группах ТГ, ФБ.

Большая часть ответивших — живут и работают в ИТ компаниях СНГ. Есть мнение, что между этими рынками есть серьезная разница, т.к. Украина и Беларусь имеют большую долю аутсорсинговых проектов в Европе и США. Там другая специфика. В опросе это не учитывается.

Данные были нормализованы для улучшения понятности и читаемости.

Основная часть

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

Изложение в виде изображений:

+ Проще читать и понимать текст.

+ Делает текст менее монотонным;

+ Информация становится привычнее для мозга. Вместо сложных смыслов — простые визуальные объекты;

+ Может отражать связи и тренды, которые сложно уловить через текст или числа;

+ Создает единое информационное поле и контекст внутри него с разными уровнями абстракции;

+ Это просто красиво;

— Может терять часть передаваемой информации и излишне упрощать;

— Часто зависит от собственного контекста, того, кто создает модель или визуализацию;

— Для некоторых нотаций и моделей нужны специальные знания.

Вот, что Карл Вигерс пишет в части “Навыки, необходимые аналитику” (книга “Разработка требований к программному обеспечению”):

“Аналитик должен уметь работать с разнообразными средствами, начиная с древних блок-схем и структурированных моделей анализа (диаграммы потоков информации, диаграммы ≪сущность-связь≫ и т.д.) и заканчивая современным языком UML (Unified Modeling Language, унифицированный язык моделирования). Некоторые из этих средств полезны при общении с пользователями, другие — с разработчиками”

Важно, как Вигерс определяет аналитика. “Аналитик — это одна из ролей участников проекта, а не обязательно название должности. Функции аналитика могут выполнять менеджер проекта, менеджер продукта, разработчик и даже пользователь”.

То есть, Вигерс считает навыки моделирования обязательными для ведения аналитической работы, независимо от того, кто выполняет ее в команде.

Cвод знаний по бизнес-анализу (BABOK) среди техник для анализа выделяет: моделирование понятий, данных, требований, решений, скоупа, процессов, состояний и организационное моделирование. Как инструменты предлагается использовать богатый зоопарк различных нотаций.

Очевидно, моделирование — важный и полезный навык. Но какие конкретно модели, нотации и стили лучше использовать, чтобы они были максимально понятны и полезны?

Об этом статистик Джордж Бокс сказал: «В сущности, все модели неверны, но некоторые — полезны».

Результаты опроса

Роли участников в команде

Опрос размещался по большей части среди аналитиков. Поэтому основная масса из 193 участников — системные аналитики и бизнес аналитики (кстати о том, как я их различаю можно почитать ЗДЕСЬ).

Как часто они используют модели

На этой таблице можно увидеть, насколько часто участники используют визуализацию и модели. Очевидно, что такой навык является почти всегда обязательным. Он важен для системного или бизнес-аналитика, руководителя ИТ проекта или ИТ архитектора. Более 90% специалистов используют визуализацию и моделирование ежедневно или часто.

Данные подтверждают сказанное ранее — моделирование — это навык, который используется часто. В опросе был ответ “Никогда не использую”, он получил 0 ответов.

В каких областях работают

В опросе можно было выбрать несколько областей специализации.

Участники опроса чаще занимаются финтехом, проектами в государственном секторе, внедрением “коробок”. Есть даже счастливчики (на мой взгляд), которые разрабатывают беспилотники.

Не могу утверждать, но кажется, что это хорошо отражает направленность основной массы ИТ проектов, которые реализуются сейчас.

Какими диаграммами и моделями пользуются

В опросе была возможность выбрать тип модели из списка или дополнить свою. Для большей информативности добавляю перечень полностью, чтобы было понятно и то, что используется часто и то, что уже скорее раритет.

! Важно. Обратите внимание, что BPMN указан в двух вариантах — полной (аналитическая или исполнимая) и упрощенной версии (описательная).

Где моделируют и рисуют

С полученной информацией каждый поступит по-своему. Лично для меня очевидно следующее:

Работа в ИТ сфере требует понимания и использования визуализаций и моделей;

Многие из нотаций и диаграммы, которые традиционно преподаются в ВУЗах и на курсах морально устарели;

Мои попытки заняться скетчингом нужно продолжать, т.к. часто рисуют абстрактно и от руки;

Требования в вакансиях и вопросы во время интервью часто различается с тем, что требуется в отрасли;

Эта статья — не руководство к действию и не требование “хоронить” неиспользуемые. Для меня это отражение, что стоит чаще применять, чтобы меня лучше понимали;

Теперь ясно, какие навыки в части моделирования следует поддерживать в актуальном состоянии и какие из диаграммы не останутся непонятыми коллегами.

Источник

1.6. Моделирование как метод системного анализа

Одной из проблем, с которой сталкиваются почти всегда при проведении системного анализа, является Проблема эксперимента в системе или над системой. Очень редко это разрешено моральными законами или законами безопасности, но сплошь и рядом связано с материальными затратами и (или) значительными потерями информации.

Опыт всей человеческой деятельности учит — в таких ситуациях надо экспериментировать не над объектом, интересующим нас предметом или системой, а над их Моделями. Под этим термином надо понимать не обязательно модель Физическую, Т. е. копию объекта в уменьшенном или увеличенном виде. Физическое моделирование очень редко применимо в системах, хоть как то связанных с людьми. В частности в социальных системах (в том числе — экономических) приходится прибегать к Математическому моделированию.

Буквально через минуту станет ясно, что математическим моделированием мы овладеваем еще на школьной скамье. В самом деле, пусть требуется найти площадь прямоугольника со сторонами 2 и 8 метров. Измерение сторон произведено приближенно — других измерений расстояний не бывает! Как решить эту задачу? Конечно же — не путем рисования прямоугольника (даже в уменьшенном масштабе) и последующем разбиении его на квадратики с окончательным подсчетом их числа. Да, безусловно, мы знаем формулу S = B·H И воспользуемся ею — применим Математическую модель Процесса определения площади.

Возвращаясь к начатому ранее примеру системного анализа обучения, можно заметить, что там собственно нечего вычислять по фор-мулам — где же их взять. Это так и есть, не существует методов расчета в такой сфере как “прием-передача” знаний и сомнительно, чтобы эти методы когда-либо появились.

Но ведь не существует формулы пищеварения, а люди все таки едят, планируют процесс питания, управляют им и иногда даже успешно.

Так что же? Если нет математических моделей — не выдумывать же их самому? Ответ на этот вопрос самый простой: Всем это уметь и делать — не обязательно, а вот тому, кто взялся решать задачи системного анализа — приходится и очень часто. Иногда здесь возможна подсказка природы, знание технологии системы; в ряде случаев может выручить эксперимент над реальной системой или ее элементами (т. н. методы планирования экспериментов) и, наконец, иногда приходится прибегать к методу “черного ящика”, предполагая некоторую статистическую связь между его входом и выходом.

Таким “ящиком” в рассматриваемом примере считался не только студент (с вероятностью такой-то Получивший знания), но и все остальные элементы системы — преподаватели и лица, организующие обучение.

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

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

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

· Из хорошо себя зарекомендовавших на практике можно упомянуть модели: межотраслевого баланса; роста; планирования эко-номики; прогностические; равновесия и ряд других.

Завершая вопрос о моделировании при выполнении системного анализа, резонно поставить вопрос о Соответствии используемых моделей Реальности.

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

Иными словами — в реальных системах вполне возможно Логическое Обоснование моделей элементов. Эти модели мы как раз и стремимся строить Минимально достаточными, простыми настолько, насколько это возможно без потери сущности процессов. Но логически осмыслить взаимодействие десятков, сотен элементов человек уже не в состоянии. И именно здесь может “сработать” известное в математике следствие из знаменитой теоремы Гёделя — в сложной системе, полностью изолированной от внешнего мира, могут существовать истины, положения, выводы вполне “Допустимые” с позиций самой системы, но не имеющие Никакого смысла Вне этой системы.

То есть, можно построить логически безупречную модель реальной системы с использованием моделей элементов и производить анализ такой модели. Выводы этого анализа будут справедливы для каждого элемента, но ведь система — это не простая сумма элементов, и ее свойства не просто сумма свойств элементов.

Отсюда следует вывод — без учета внешней среды выводы о поведении системы, полученные на основе моделирования, могут быть вполне обоснованными при взгляде изнутри системы. Но не исключена и ситуация, когда эти выводы не имеют никакого отношения к системе — при взгляде на нее со стороны внешнего мира.

Для пояснения вернемся к рассмотренному ранее примеру. В нем почти все элементы были построены на вполне оправданных логических Постулатах (допущениях) типа: если студент Иванов получил оценку “знает” по некоторому предмету, и посетил все занятия по этому предмету, и управление его обучением было на уровне “Да” — то Вероятность получения им оценки “знает” будет выше, чем при отсутствии хотя бы одного из этих условий.

Но как на основании системного анализа такой модели ответить на простейший вопрос; каков вклад (хотя бы по шкале “больше-меньше”) Каждой из подсистем в полученные фактические результаты сессии? А если есть Числовые описания этих вкладов, то каково доверие к ним? Ведь управляющие воздействия на систему обучения часто можно производить только через семестр или год.

Здесь приходит на помощь особый способ моделирования — метод статистических испытаний (Монте Карло). Суть этого метода проста — имитируется достаточно долгая “жизнь” модели, несколько сотен семестров для нашего примера. При этом моделируются и регистрируются случайно меняющиеся Внешние (входные) Воздействия на систему. Для каждой из ситуации по уравнениям модели просчитываются Выходные (системные) показатели. Затем производится обратный расчет — по заданным выходным показателям производится расчет входных. Конечно, никаких совпадений мы не должны ожидать — каждый элемент системы при входе “Да” вовсе не обязательно будет “Да” на выходе.

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

Источник