Проектирование Информационных систем. Часть 9. Моделирование поведения 9.1. Теория систем часть 2

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

https://habr.com/ru/articles/919454/

#проектирование_систем #анализ #анализ_и_проектирование_систем #системный_анализ #инженерия_требований #системный_аналитик #промышленная_автоматизация #поведенческий_анализ #ингерентность #эмерджентность

От родовспоможения к системной аналитике: как я поменял профессию после 40 лет в медицине

Хабровчане, приветствую! Меня зовут Андрей Иванов, я системный аналитик в сфере медицины и здравоохранения. Но это сейчас, а до этого я 20 лет работал врачом, а после — руководителем медицинского информационно-аналитического центра. Я хочу рассказать о своём опыте как в медицине, так и в системной аналитике. Такая идея ко мне пришла после встречи со студентами и выпускниками Яндекс Практикума. Она была долгой, но я был удивлён — на пике мой рассказ слушали 84 посетителя, а до финала «досидели» 64 человека. Может, моя история будет интересна читателям и здесь. Буду рад, если кому-то станет хоть немного легче в трудной ситуации смены профессии.

https://habr.com/ru/companies/yandex_praktikum/articles/916194/

#смена_профессии #системная_аналитика #системный_анализ #системный_аналитик #медицина

Проектирование Информационных систем. Часть 8. Разработка логической структуры данных. 8.2. Шаблонный подход

В 1950 году математик по имени Клод Шеннон опубликовал в журнале статью «Как запрограммировать компьютер для игры в шахматы». В этой статье он подсчитал, что количество комбинаций в шахматах будет равно 10 120 . Это на самом деле превосходит количество атомов в известной Вселенной, которое оценивается от 10 78 до 10 82 атомов. Но среднестатистическому шахматисту для успешного старта не обязательно изучать все существующие варианты начала игры, а достаточно выбрать несколько популярных дебютов за каждый цвет. По факту это использование формализованных шаблонов успешных тактических позиций для достижения желаемых результатов. Аналогично шахматным, успешные шаблоны используют и в ИТ. Для того, чтобы, при решении однотипные задачи проектирования не изобретать каждый раз велосипед, принято использовать паттерны проектирования. Давайте рассмотрим некоторые из них, применительно к моделированию хранилищ данных. Приспособленец (Flyweight) - структурный паттерн проектирования, который нужен для эффективной работы с большим количеством мелких объектов. Основная идея: разделить общее состояние объектов и вынести его в отдельное место , чтобы не плодить кучу дубликатов данных и экономить место. При этом объект, представляет себя как уникальный экземпляр в разных местах программы, но фактически не являющийся таковым.

https://habr.com/ru/articles/918450/

#проектирование_систем #проектирование_по #анализ_и_проектирование_систем #системный_анализ #системный_аналитик #инженерия_требований #промышленная_автоматизация #паттерны_проектирования #моделирование_данных #моделирование_предметной_области

Проектирование Информационных систем. Часть 8. Разработка логической структуры данных. 8.1. UML Class diagram

Одним из важнейших этапов в проектировании Информационной системы является выявление бизнес-объектов и их детализация на сущности Предметной области. По результатам этих активностей можно спроектировать модель хранилищ данных. Чаще всего такие работы выполняют параллельно с этапом описания бизнес-процессов. Как всегда, объявим цели текущего шага: определить и задокументировать сущности Предметной области и способы их взаимодействия. Спроектировать модель хранилищ данных. Таким образом мы расширяем наш домен решений, добавляя в него – модель данных. Чтобы сложить картинку о бизнес-объектах области автоматизации, необходимо уметь описывать бесконечное разнообразие сущностей мира - конечными фразами. Это можно сделать огрублено, приблизительно, упрощенно. 1) Первый шаг упрощения основан на том, что все объекты различны, но одни отличаются друг от друга «слабо», «мало», «незначительно», другие — «сильно», «существенно». 2) Второй шаг состоит в том, чтобы объединить все мало различающиеся объекты в одну группу, оставив вне ее все сильно различающиеся. В итоге бесконечно разнообразный мир описывается конечным множеством отличающихся друг от друга классов. Похожий прием мы уже использовали на каждом этапе, классифицируя рассматриваемы элементы, определяя для них простейшую абстрактную модель разнообразия действительности. Для выражения различий между классами им присваиваются различные имена (названия, обозначения, символы, номера и т.п.). Классифицировать можно не только объекты, но и свойства (цвета, звуки, силы, размеры и т.д.), и процессы (ходить, бегать, тянуть, есть, пить и т.д.). Таким образом, классификация сущностей исследуемой предметной области идентифицируется в виде названия некоторых классов.

https://habr.com/ru/articles/917654/

#проектирование_систем #проектирование_по #проектирование_баз_данных #анализ_и_проектирование_систем #системный_анализ #бизнесмодель #сущность #инженерия_требований #нормализация_данных

Проектирование Информационных систем. Часть 7. Инжиниринг бизнес-процессов 7.2. Применение BPMN. Ресурсоемкость

Один из популярных инструментов BPMN (Business Process Model and Notation) — стандарт графического моделирования бизнес-процессов, разработанный Object Management Group (OMG). Он широко используется для визуализации, анализа и оптимизации процессов внутри организаций. Но в отличие от прочих нотаций, BPMN может использоваться совместно со специальным BPM-движком (engine), встроенным в различные ИТ-платформы. То есть бизнес-процессы, описанные с помощью BPMN, не просто визуализируются, а управляют логикой выполнения в реальных ИТ-системах, превращая нотацию в исполняемый код , который интерпретируется движком, При этом продвигая процессы в соответствии с описанной в диаграммах бизнес-логикой, BPMN-движок следит за выполнением шагов, направляет задачи сотрудникам, вызывает API сервисов, генерирует события, фиксирует в Базе Данных (далее – БД) результат и тому подобное. Помимо того, такой инструмент выполняет мониторинг и логирование каждого запущенного экземпляра процесса и фиксирует прогресс и актуальные состояния в БД.

https://habr.com/ru/articles/916942/

#проектирование_систем #проектирование_по #проектирование #анализ_и_проектирование_систем #системный_анализ #промышленная_автоматизация #bpmn #ресурсное_планирование #предварительные_оценки #оценка_трудозатрат

ИИ помощник или конкурент?

Привет, Хабр, я Татьяна, системный аналитик. В этом году у меня профессиональный юбилей – 5 лет в IT. Я работаю на проекте в банковском секторе. В прошлом году в банке запустили пилотный проект по использованию ИИ. Коллеги из разных компетенций учились применять искусственный интеллект в своей работе. В этой статье хочу поделиться с вами своим мнением о внедрении нейросети в процессы системного аналитика, советами для эффективной коммуникации с ИИ и примерами промтов.

https://habr.com/ru/companies/inpglobal/articles/917180/

#ии_помощник #ииассистент #ииагенты #ииинжиниринг #системный_анализ

AI в помощь системному аналитику: от скепсиса к практике

Друзья, привет! Меня зовут Ларионов Александр. Я работаю системным аналитиком. Совместно с Лабораторией инноваций Московской биржи мы изучали вопрос применения AI в системном анализе. Когда я впервые столкнулся с задачей внедрения AI-ассистентов в процессы работы системного аналитика, то отреагировал скептически. Поводов было немало: большинство материалов на эту тему представляли собой восторженные отзывы вроде «AI автоматизирует рутину» или «machine learning улучшает принятие решений». Однако, при ближайшем рассмотрении, эти фразы распадались на абстрактные утверждения. Попытки уточнить у авторов конкретные кейсы или сценарии применения их инструментов для системного анализа сводились к общим фразам: «Обучите модель на ваших данных — и она всё поймёт». Скептицизма добавляло и то, что сама роль системного аналитика строится на работе в условиях высокой неопределенности. В этой специальности регулярно сталкиваются с неоднозначными требованиями, непонятной бизнес-логикой, конфликтующими приоритетами, быстро меняющимися требованиями. Это противоречит глубинному принципу современных AI-моделей — обучению на конкретных, четко структурированных данных. Машине сложно оперировать «чувством здравого смысла» или «интуитивным пониманием бизнес-процессов», которые так важны для аналитика. Как же убедиться, что AI полезен для нашей профессии, когда в поиске реальных кейсов находишь информационный вакуум? Я решил переосмыслить подход и начать экспериментировать самостоятельно. За основу я взял самые распространённые задачи, с которыми сталкиваются системные аналитики, в том числе и мы в Лаборатории инноваций Московской биржи.

https://habr.com/ru/companies/moex/articles/916758/

#системный_анализ #аналитика #системный_аналитик #ai #ии #ииассистент #ииагенты #документация

Проектирование Информационных систем. Часть 7. Инжиниринг бизнес-процессов заказчика 7.1. Применение UML Activity

В качестве следующего шага на пути формирования проектного решения определим процессы, которые должны проистекать внутри разрабатываемой системы и окружать ее из вне. Поддерживая непрерывность процесса проектирования, будем отталкиваться от функций, которые мы выявили на предыдущем этапе. Как всегда, обозначим цели текущего шага: на основании выявленных функций, определить сценарии использования/применения, разрабатываемого целевого продукта . На текущем этапе проектирования воспользуемся Алгоритмизацией , еще одним приемом дисциплины «Системный Анализ». Рассмотренные нами ранее модели в большей степени отражали статику, ведь в итоге формализованные функции воплощают свойства системы, которые можно использовать. Теперь внесем немного динамики, моделируя действия. Важное отличие алгоритмов от используемых нами ранее диаграмм IDEF0, это возможность организовывать условные переходы, то есть в зависимости от выполнения некоего условия на определенном шаге сценария, предпринимать далее те или иные варианты действий. Концепция инжиниринга бизнес-процессов подразумевает осмысление различных моделей текущего состояния системы и прогнозирования будущих с целью достижения существенных улучшений по ключевым показателям: стоимость, качество, скорость, ресурсоемкость и прочее. В зависимости от актуальных условий может использоваться: 1) Экстраполяционная модель

https://habr.com/ru/articles/916676/

#проектирование_систем #проектирование_по #анализ #анализ_и_проектирование_систем #системный_анализ #инженерия_требований #промышленная_автоматизация #activity #uml #umlпроектирование

Диаграмма последовательности на практике в реальном кейсе

Привет Хабр! Меня зовут Татьяна Ошуркова, я системный аналитик и разработчик. Несмотря на то, что UML-диаграммы являются популярным и востребованным инструментом, не все системные аналитики используют его в своей работе. Одной из причин может быть непонимание пользы для требований и проработки задачи. Скажу честно, что такое было и со мной, когда опыта у меня было немного. Сложностей в работе хватало и без дополнительных инструментов, которые требовали время на погружение. В этой статье я на практическом примере покажу, как проработать процесс с помощью моделирования на UML. Подробно посмотрим, как сделать это быстро, понятно, а также выделим основные преимущества решения.

https://habr.com/ru/articles/916730/

#системный_анализ #системный_аналитик #моделирование #uml #umlпроектирование #plantuml #sequence_diagram #требования #требования_к_системе #требования_к_по

Проектирование Информационных систем. Часть 6. Выявление функции системы. 6.1. Теория систем

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

https://habr.com/ru/articles/915546/

#проектирование_систем #проектирование_по #проектирование #анализ #анализ_и_проектирование_систем #системный_анализ #системный_аналитик #инженерия_требований #промышленная_автоматизация #системотехника