Анализ и проектирование систем *

Работая аналитиком 1С уже не первый год, я всё больше прихожу к выводу: время — один из главных ресурсов. А значит, любые инструменты, которые помогают сэкономить его — на вес золота.

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

Целевая аудитория — аналитики, которые не просто составляют ТЗ, но и погружаются в логику системы, отлаживают процессы, и работают с программистами на одном языке.

⸻

 1. Конструктор универсальных отчётов и запросов

Зачем нужен: Быстро проверить наличие данных, отладить сложные выборки, посмотреть движение по регистраторам.
Что использую:
1.1 Универсальный отчет (по регистрам, документам, справочникам) — спасал десятки раз (Все инструменты и обработки, если они не под NDA, выложу в Telegram-канале ).
1.2 Встроенный запрос к СКД — полезно при настройке новых отчётов, когда нужно быстро проверить выборку (Все инструменты и обработки, если они не под NDA, выложу в Telegram-канале ).

⸻

 2. Сверка остатков и регистра накопления

Зачем нужен: Быстро выявить несостыковки между данными — особенно полезно, когда бухгалтерия жалуется “в отчёте не то”.

Что использую:
2.1 Обработка сверки по остаткам/оборотам по регистраторам (Хороший вариант предложен здесь, но он платный). Также вариант написать свою обработку, но для этого нужен толковый программист.
2.2 Отчет «Отчет По Движениям Документа» — must-have для всех, кто работает с логикой движений (e1cib/app/Отчет.ОтчетПоДвижениямДокумента )

Друзья, привет! Меня зовут Ларионов Александр. Я работаю системным аналитиком. Совместно с Лабораторией инноваций Московской биржи мы изучали вопрос применения AI в системном анализе.

Когда я впервые столкнулся с задачей внедрения AI-ассистентов в процессы работы системного аналитика, то отреагировал скептически. Поводов было немало: большинство материалов на эту тему представляли собой восторженные отзывы вроде «AI автоматизирует рутину» или «machine learning улучшает принятие решений». Однако, при ближайшем рассмотрении, эти фразы распадались на абстрактные утверждения. Попытки уточнить у авторов конкретные кейсы или сценарии применения их инструментов для системного анализа сводились к общим фразам: «Обучите модель на ваших данных — и она всё поймёт».

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

Как же убедиться, что AI полезен для нашей профессии, когда в поиске реальных кейсов находишь информационный вакуум? Я решил переосмыслить подход и начать экспериментировать самостоятельно. За основу я взял самые распространённые задачи, с которыми сталкиваются системные аналитики, в том числе и мы в Лаборатории инноваций Московской биржи.

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

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

На текущем этапе проектирования воспользуемся Алгоритмизацией, еще одним приемом дисциплины «Системный Анализ».

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

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

1)    Экстраполяционная модель

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

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

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

Цикл статей о проектировании, призван показать один из возможных путей, достижения успеха, через проектирование программного обеспечения с использованием UML (англ. Unified Modeling Language — унифицированный язык моделирования).

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

-------------

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

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

Это моя первая статья на Хабре. Формат нащупываю. Хотелось бы сразу с кейсами и диаграммами, но решил начать с простого — краткий разбор архитектуры нашего сервиса и того, как мы пришли к текущему состоянию.

Сервис — это проверка физических и юридических лиц по открытым источникам. Пользователь вводит ИНН или ФИО и получает отчёт: есть ли долги, исполнительные производства, признаки банкротства, участие в сомнительных организациях и так далее. Отчёт собирается на лету по 10+ источникам.

Система существует давно. Код — не идеален. Архитектура — не микросервисная. Docker и Kubernetes у нас не прижились, зато есть реальный боевой опыт. Ниже — краткий разбор, как оно устроено, какие ошибки мы прошли и как всё это выживает под нагрузкой.

Когда бизнес внедряет 1С, он ждёт, что «всё будет работать само». Но вместо автоматизации начинается война с системой.

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

В чём корень проблемы?

Предприниматели думают, что 1С — это готовое решение. И действительно, «Управление торговлей», «Розница», «Бухгалтерия» — это мощные платформы. Но ключевое слово тут — платформы, а не решения.

Типовые конфигурации создавались под максимально обобщённые кейсы.

Данных в современных приложениях становится все больше, прямо как снежный ком. И рано или поздно многие системы начинают задыхаться – база данных не справляется. Когда старые добрые методы вроде подкрутки запросов, добавления индексов или покупки сервера помощнее уже не помогают (или стоят как крыло от самолета), на помощь приходит горизонтальное масштабирование.

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

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

Diplodoc — опенсорс‑платформа для работы с документацией в парадигме Docs as Code, которая создаётся в Яндексе силами команд Yandex Infrastructure и Yandex Cloud и является частью наших опенсорс‑инструментов. С её помощью мы собираем всю документацию компании. Это суммарно более 300 тысяч статей в более чем 2500 документационных проектов и порядка 6000 запусков Diplodoc CLI каждый день.

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

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

Больше всего от растущего времени сборки страдали технические писатели: для просмотра внесенных изменений им требовалось собирать документацию целиком и на больших проектах это стало приводить к ожиданию более 10 минут. С десятками тысяч правок документации ежедневно эти десятки минут складываются в человеко‑месяцы простоя, которые никому не идут на пользу. Поэтому мы приняли решение всё это основательно причесать.

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

Изучение способов выявления и формализации функций системы, особенно актуальны для современных тенденции ИТ-рынка, связанных с развитием Сервисных моделей и архитектуры микросервисов. Затронем тезисно эти подходы.

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

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

Может быть, не всё legacy, чему больше года, но у нас и правда был запущенный случай: несколько лет в режиме стартапа над проектом работали разные команды, начиная от аутсорса, заканчивая маленькими инхаус-группами. Мы жили в парадигме «работает — не трогай», но всему есть предел и в конце-концов техдолг стал слишком сильно блокировать развитие. 

Эта статья не о том, как выделить ресурсы на рефакторинг, и не о процессах. Мы фокусируемся на логике принятия технических решений, рассказываем о выбранных и приводим примеры реализации современной гибкой и масштабируемой фронтенд-архитектуры. 

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

 В очередной деловой игре нашего киберклуба мы задались вопросами: какими умениями должна обладать команда проекта программной инженерии? Как оценивать и развивать компетенции команды проекта?

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

Цель данной группы работ: собрать максимально полные и точные сведения о потребностях заказчика, которые они хотят удовлетворить при помощи разрабатываемого продукта

Я уже двадцать лет проектирую интерфейсы. Делаю интерактивные прототипы, готовлю проектную документацию, вот это всё. Получается, я сочетаю в себе компетенции системного аналитика, UX-дизайнера и ещё всякого по мелочи.

Итак.

Правда №1: я не знаю объективного способа подтвердить, что с проектированием продукты делаются быстрее и дешевле, чем без него.

То есть, для меня это очевидно. Это логично и рационально. Но не проверить.

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

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

Правда №2: никто не читает…

Как перейти от первых проектов к успешной автоматизации сотен процессов с помощью гибкого пошагового подхода.

Нам часто задают такие вопросы:

— Как масштабировать внедрение Camunda в рамках всей компании?

— Как создать корпоративную платформу для управления процессами?

Мы видим, как масштабно Camunda используется в таких компаниях, как Goldman Sachs (3000 процессов, 8000 пользователей в день), Societe Generale (600 процессов, 60 000 завершённых задач в месяц, 7500 активных пользователей) или 24Hour Fitness (800 процессов, 230 миллионов выполнений активностей в день). Как нам достичь такого уровня?

Какую архитектуру данных выбрать, когда на горизонте — Data Warehouse, Data Lake, Lakehouse и Mesh, а проект требует гибкости, отчетности и масштабируемости? В этой статье — практический разбор подходов с позиций data-инженера. Рассматриваем плюсы и ограничения каждого варианта, углубляемся в архитектуры Инмона, Кимбалла, Data Vault и медальонную модель, а также разбираемся, где граница между аналитическими целями и технической реализацией.

Одним из основных признаков системы, отличающим ее от #НЕСистемы, является подчиненность всей структуры некоторым целям. Проектная работа команды представляет собой тоже некую систему и, следовательно, должна «идти на поводу» у какой-то цели. Потому установив коммуникации между участниками проекта, начнем вместе с ними определять цели, которые каждое из заинтересованных лиц хочет достичь в результате создания нового продукта.

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

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