Проектирование Информационных систем. Часть 10. Разработка требований 10.1. Правила формирования требований

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

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

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

ИТ-архитекторы: приручение корпоративной энтропии

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

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

#энтропия #системный_подход #сложные_системы #хаос_в_компании #рынок_труда_в_ит #проектирование_систем #архитектура #прогнозы_в_ит #итархитектор

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

Моделирование поведения системы — это процесс создания упрощённого, формального или визуального представления динамики системы во времени, ее реакций на события и взаимодействий между компонентами. Основные виды моделирования поведения: 1) Диаграммы поведения в UML

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

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

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

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

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

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

Языково-ориентированное… моделирование?

Историю можно начать с 1994 года, в котором Мартин Уорд (Martin Ward) на основании исследования больших проектов предложил парадигму языково-ориентированного программирования , когда процесс разработки программного обеспечения разбивается на стадии создания предметно-ориентированных языков и описания решения задачи с их использованием. Цель языково-ориентированного программирования — разделить сложности разработки: машиноориентированная часть кода (низкоуровневая функциональность) и человеко-ориентированная (решение прикладной задачи) разрабатываются независимо друг от друга. Далее в 2003 году Эрик Эванс (Eric Evans) ввел понятие предметно-ориентированного проектирования (Domain-Driven Design, DDD) для набора программных и организационных практик, позволяющих разрабатывать сложные масштабируемые системы. Этот подход до сих пор активно используется, например, в микросервисной архитектуре и в информационной безопасности (см. Secure by Design ). В этом подходе вводятся понятия: «модель», «проектирование по модели» (Model-Driven Design), «изоляция предметной области» и «изолированный контекст» (Bounded Context). Особенно интересно, что Эванс упоминает о предметно-ориентированных языках, как идеальном средстве описания модели конкретной предметной области, которая должна быть изолирована в своём контексте. Но как обстоят дела с имитационным математическим моделированием? До сих пор мы применяем инструменты, разработанные по большей части на базе концепций из середины прошлого века. В то время, как за последнюю пару десятилетий теория и технологии развивались достаточно динамично. Возможно, в этом нет ничего страшного (об этом позже). Но вот что интересно: можно ли объединить понятия разработки математических моделей и программного обеспечения на базе представленных выше концепций? Вот мы и добрались до моделирования в широком смысле. Далее речь пойдёт о подходе, который может быть применён, как для имитационного математического моделирования, так и для разработки сложного программного обеспечения. Начнём с имитационного моделирования, поскольку в этой области есть наиболее интересные результаты, но перспективы нового подхода в разработке сложных программных систем постараюсь тоже затронуть.

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

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

Брайлекс — мобильное устройство ввода текста шрифтом Брайля

Что такое BraiLex ? BraiLex — это мобильная аппаратная клавиатура, которая позволяет вводить текст с использованием шрифта Брайля, сохраняя его в памяти или передавать на телефон в любое открытое приложение. BraiLex можно использовать для ввода текста без фиксированного основания даже во время ходьбы. Эта серия статей рассказывает об идее создания такого устройства и этапах ее реализации от первого чертежа до прототипа к которому мы сейчас подошли. (По состоянию на 11 июня 2025 года).

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

#diyпроекты #брайлевская_клавиатура #проектирование_систем

Проектирование Информационных систем. Часть 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 #ресурсное_планирование #предварительные_оценки #оценка_трудозатрат

Как спроектировать сложный цифровой продукт: метод КРИ — Карта реализации историй

Что, если пользовательские истории не работают? Что, если заказчик не понимает, чего он хочет, а команда тонет в предположениях? Андрей Шапиро @xraizor — дизайнер интерфейсов и соавтор фреймворка проектирования социотехнических систем — рассказывает о «Карте реализации историй» (КРИ) — практическом методе проектирования, который помогает вытащить смысл из хаоса, превратить знания в структуру и наконец-то начать делать сложные продукты осознанно.

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

#проектирование #проектирование_интерфейсов #проектирование_систем #управление_проектами #управление_продуктом #управление_разработкой #ux #ui