Корпоративная платформа визуализации данных из внутренних систем — SRS-сборка¶

Эта страница собирает разделы для спецификации требований к ПО: от контекста и проблемы до безопасности, качества и эксплуатации.

Содержание¶

Краткое описание
Контекст и проблема
Цели, требования и ограничения
Роль и обязанности
Модель системы
Архитектура и интеграции
Безопасность, качество и эксплуатация

Краткое описание¶

Статус¶

опытно-промышленная эксплуатация для внутреннего B2E-сценария; pre-sale архитектура для B2B-продукта

Роль¶

системный аналитик / проектировщик решения

Стек¶

Домен: Enterprise GIS, логистика, железнодорожная инфраструктура; NDA: детальная архитектура, модели данных и исходный код являются конфиденциальными

Ценность проекта¶

Enterprise GIS-платформа для логистического сектора - визуализация корпоративных операционных данных на карте с пространственной привязкой к железнодорожной инфраструктуре.

Контекст и проблема¶

Контекст¶

Продуктовый контекст¶

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

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

Внешнее B2B-направление переиспользовало ту же инфраструктурную и архитектурную базу, но требовало более конфигурируемой модели: клиентские слои, динамические бизнес-метрики, on-premise deployment и более строгую продуктовую документацию.

Проблема¶

Цели, требования и ограничения¶

Цели и нецели¶

Требования¶

Ограничения¶

Роль и обязанности¶

Роль и вклад¶

Моя зона ответственности включала:

сбор и формализацию бизнес- и функциональных требований;
перевод бизнес-потребностей в задачи реализации для разработчиков;
подготовку проектной документации и архитектурных артефактов;
определение нефункциональных требований к производительности, безопасности, deployment и эксплуатации в закрытом корпоративном контуре;
проектирование API-контрактов и целевой архитектуры для B2B-продуктового направления;
подготовку технических обоснований и ADR-style notes для выбора технологического стека на pre-sale этапе;
настройку и развертывание ad-hoc инфраструктурных компонентов, включая tile server и GIS routing components;
проектирование логики обработки геоданных и сценариев редактирования инфраструктуры;
поддержку подготовки системы к промышленной эксплуатации.

Модель системы¶

Доменная модель¶

Модель данных¶

Конфигурируемая GIS-модель данных¶

Переход от внутренней ad-hoc системы к переиспользуемому B2B-продукту требовал более гибкой модели слоев, геометрии и бизнес-метрик.

Решение: спроектировал реляционную PostGIS-based модель данных, которая позволяла описывать конфигурируемые GIS-слои и связывать GeoJSON-геометрию с бизнес-атрибутами и показателями.

Это позволило описывать картографические слои не как hardcoded screens, а как конфигурируемые бизнес-объекты.

API-контракты¶

Архитектура и интеграции¶

Архитектура¶

Привязка к железнодорожной инфраструктуре¶

Исходные корпоративные системы не предоставляли единого готового GIS-графа для всех необходимых объектов железнодорожной инфраструктуры.

Решение: спроектировал логику связывания разрозненных геоданных с объектами железнодорожной инфраструктуры и графом перегонов. Участвовал в проектировании визуальных инструментов редактирования инфраструктурных данных на базе OpenLayers и backend-сервисов.

Reverse Engineering и формализация архитектуры¶

Часть системы опиралась на существующие legacy-компоненты и недостаточно документированные детали реализации.

Решение: восстановил и формализовал архитектуру существующих компонентов. Подготовил концептуальные архитектурные артефакты, включая C4 diagrams, ERD, DFD и описания интеграций, чтобы синхронизировать понимание продукта между бизнес-стейкхолдерами и командой разработки.

Потоки интеграции¶

Безопасность, качество и эксплуатация¶

Модель безопасности и доступа¶

Закрытый корпоративный контур¶

Требования корпоративной безопасности не позволяли полагаться на внешние картографические провайдеры и публичные routing API.