UpCore

1. Общие сведения

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

2. Функциональные характеристики

2.1 Анализ исходного кода

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

2.2 Оценка эффективности

• расчет трудоемкости кода в часах и денежном выражении;
• сравнение ожидаемых трудозатрат со временем из событий, табелей или ворклогов;
• учет более 50 факторов: стадия проекта, состав команды, сложность задач, объем вклада, качество результата, баги, код-ревью, архитектурная ценность;
• выявление аномалий эффективности, снижения производительности, выгорания и рисков срыва сроков;
• контроль динамики после внедрения новых процессов и ИИ-инструментов.

2.3 Грейдинг и развитие специалистов

• определение реального грейда разработчика;
• сравнение специалиста со средними показателями проекта, стека, компании и рынка;
• выявление over-skill и under-skill относительно задач проекта;
• формирование индивидуального плана развития;
• подготовка отчетов для performance review, 1-1, онбординга, ротации и кадровых решений.

2.4 Управление проектами и подрядчиками

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

2.5 ИИ-ассистент

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

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

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

Компоненты платформы

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

• веб-интерфейс — клиентское приложение (личный кабинет пользователя): дашборды, отчеты, грейдинг, настройки;
• обратный прокси-сервер — единая точка входа, шифрование канала (TLS) и маршрутизация обращений к серверным компонентам;
• серверный API — бизнес-логика, авторизация и разграничение доступа, единая точка доступа к данным, модуль интеграций с внешними системами;
• модуль анализа кода и расчетная математическая модель — разбор истории репозиториев, расчет метрик сложности и оценки эффективности;
• ИИ-ассистент — поиск данных и объяснение результатов на естественном языке;
• система управления базами данных (PostgreSQL) — основное хранилище метрик, пользователей, проектов и настроек;
• объектное хранилище — артефакты анализа, отчеты и выгрузки данных.

Схема взаимодействия компонентов

Взаимодействие компонентов организовано следующим образом:

1. обращения пользователей выполняются из браузера по защищенному протоколу HTTPS; обратный прокси-сервер выполняет шифрование канала и маршрутизацию запросов к веб-интерфейсу, серверному API и сервисным веб-модулям;
2. веб-интерфейс получает данные от серверного API в формате JSON; доступ к API предоставляется только после аутентификации пользователя (по логину и паролю либо через внешнего провайдера SSO) и авторизуется по маркеру доступа;
3. серверный API является единой точкой доступа к данным: чтение и запись выполняются в базе данных PostgreSQL, файловые артефакты размещаются в объектном хранилище;
4. задания на анализ репозиториев помещаются в очередь и обрабатываются модулем анализа кода асинхронно; результаты расчета сохраняются в базе данных;
5. модуль анализа получает исходный код из подключенных Git-репозиториев по протоколам HTTPS или SSH;
6. модуль интеграций серверного API синхронизирует задачи и трудозатраты с таск-трекерами и выполняет аутентификацию пользователей через корпоративные каталоги;
7. ИИ-ассистент обращается к языковой модели — локальной (в контуре заказчика) или внешней по согласованию с заказчиком.

Интеграции

• Git-репозитории: GitLab, GitHub, Bitbucket и совместимые Git-серверы;
• таск-менеджеры и ворклоги: Jira, YouTrack, Redmine и другие системы через API;
• SSO и учетные записи: LDAP, SAML, OpenID Connect;
• корпоративная отчетность: BI-дашборды, CSV/JSON-выгрузки, API;
• LLM-модули: on-prem модель или внешний провайдер по согласованию с заказчиком.

Безопасность

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

4. Установка

4.1 Требования к окружению

4.2 Порядок установки в контуре заказчика

1. Согласовать архитектуру развертывания, список интеграций и требования ИБ.
2. Подготовить серверы, доменное имя, TLS-сертификат, учетные записи и доступ к СУБД.
3. Получить дистрибутив UpCore и лицензионный ключ от правообладателя.
4. Развернуть контейнеры приложения через Docker Compose или Kubernetes-манифесты.
5. Заполнить конфигурацию: адреса сервисов, параметры БД, SSO, Git-интеграции, права доступа.
6. Выполнить миграции БД и первичную проверку состояния сервисов.
7. Подключить пилотные репозитории и запустить первичный анализ.
8. Проверить отчеты, роли пользователей и журнал событий.

4.3 SaaS-подключение

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

4.4 Доступ к экземпляру программного обеспечения для проверки

Для проверки функциональности правообладатель предоставляет доступ к демонстрационному контуру UpCore по адресу демо.ап-кор.рф. Тестовые учетные записи с необходимым набором ролей выдаются по запросу на sales@dex-it.ru. Установка программного обеспечения на стороне проверяющего при этом не требуется: демонстрационный контур содержит подключенные репозитории и рассчитанные показатели.

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

5. Эксплуатация

Раздел описывает порядок повседневной эксплуатации UpCore после установки или подключения SaaS-доступа. Инструкция предназначена для администратора системы, руководителей разработки и сотрудников, отвечающих за сопровождение продукта у заказчика.

5.1 Роли пользователей

• Администратор управляет настройками, пользователями, интеграциями и правами доступа.
• Руководитель ИТ смотрит сводные показатели компании, проекты, риски и финансовый результат.
• Руководитель проекта анализирует команду, сроки, трудозатраты и качество результата.
• Тимлид использует отчеты для ревью, 1-1, развития команды и распределения задач.
• HR смотрит грейды, динамику онбординга, ИПР и кадровые риски.
• Разработчик видит личные показатели, обратную связь и план развития.

5.2 Основные сценарии

1. Подключить проект, репозиторий и источник рабочих часов.
2. Запустить первичный анализ истории кода.
3. Проверить дашборды эффективности, грейдов, рисков и финансового результата.
4. Настроить регулярный анализ новых merge request, задач и релизов.
5. Использовать отчеты для управления проектом, развития специалистов и контроля подрядчиков.

5.3 Регламент эксплуатации

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

5.4 Авторизация и управление доступом

Вход в систему:

• доступ к веб-интерфейсу выполняется по логину и паролю, учетную запись выдает администратор;
• поддерживается единый вход через корпоративные каталоги и провайдеры идентификации: LDAP, SAML, OpenID Connect;
• действует парольная политика: требования к длине и составу пароля, ограничение срока его действия, блокировка учетной записи после серии неудачных попыток входа и ограничение времени неактивной сессии;
• поддерживается двухфакторная аутентификация;
• успешные и неуспешные попытки входа фиксируются в журнале событий.

Управление пользователями выполняется администратором в веб-интерфейсе, без доступа к серверу и правки конфигурационных файлов:

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

Ролевая модель доступа (RBAC). Права назначаются сочетанием роли и области видимости: организация, проект, команда, сотрудник.

• разработчик видит только личные показатели и адресованные ему рекомендации;
• тимлид и руководитель проекта видят данные своей команды и своего проекта;
• руководитель ИТ видит сводные показатели компании, проекты и риски;
• HR видит грейды, динамику онбординга и планы развития;
• администратор управляет пользователями, ролями, интеграциями, системными настройками и журналом событий.

5.5 Первый вход и подготовка к работе

1. Администратор входит в систему по выданной учетной записи или через SSO.
2. Проверяет реквизиты организации, часовой пояс, календарь рабочих дней и базовую валюту расчетов.
3. Создает рабочие группы: организация, проекты, команды, роли пользователей.
4. Добавляет руководителей, тимлидов, HR и разработчиков либо выполняет импорт из корпоративной учетной системы.
5. Проверяет доступ к журналу событий, странице интеграций и системному мониторингу.

5.6 Подключение проекта

1. Создать карточку проекта и указать стек, команду, период анализа и ответственного руководителя.
2. Подключить Git-репозиторий через токен доступа, SSH-ключ или сервисную учетную запись.
3. Подключить источник задач и рабочих часов: Jira, YouTrack, Redmine, табель или API заказчика.
4. Сопоставить пользователей UpCore с авторами коммитов, merge request и задач.
5. Настроить исключения: служебные ветки, автогенерируемые файлы, внешние библиотеки, тестовые репозитории.
6. Сохранить настройки и запустить первичный анализ.

5.7 Запуск анализа и контроль выполнения

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

5.8 Работа с отчетами

• Отчет разработчика показывает эффективность, вклад, качество результирующего кода, динамику и сравнение с командой.
• Отчет проекта показывает рейтинг, потери, сложность, размер, длительность, прирост и риски сроков.
• Отчет по коду показывает вклад участников, архитектурную сложность, качество ревью и уровень багов.
• Руководитель использует отчеты для планирования, performance review, контроля подрядчиков и перераспределения задач.
• Данные могут выгружаться в согласованном формате или передаваться в BI-систему через API.

5.9 Резервное копирование и восстановление

• Резервному копированию подлежат база данных, конфигурация, ключи интеграций и системные настройки.
• Рекомендуемый режим: ежедневная копия БД, хранение не менее 30 календарных дней, проверка восстановления не реже одного раза в квартал.
• Восстановление выполняется администратором из последней корректной копии с последующей проверкой интеграций и отчетов.
• Для SaaS-формата порядок резервного копирования определяется регламентом поставщика сервиса.

5.10 Типовые ситуации

5.11 Настройка регулярной синхронизации

1. Открыть раздел интеграций и выбрать подключенный источник данных.
2. Указать расписание синхронизации: по событию, каждый час, ежедневно или по индивидуальному расписанию.
3. Задать глубину обработки истории и период, за который данные должны попадать в отчеты.
4. Включить уведомления об ошибках синхронизации для администратора и ответственного руководителя.
5. Сохранить настройки и выполнить тестовый запуск.

5.12 Обновление версии

1. Получить пакет обновления, описание изменений и инструкцию по миграции.
2. Создать резервную копию БД, конфигурации и ключей интеграций.
3. Установить обновление в тестовом контуре и проверить вход, интеграции, расчеты и отчеты.
4. Согласовать окно работ для промышленного контура.
5. Установить обновление, выполнить миграции и проверить состояние сервисов.
6. При критической ошибке выполнить откат на предыдущую версию по резервной копии.

5.13 Мониторинг и журналы

5.14 Обработка инцидентов

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

5.15 Завершение работы пользователя

1. Пользователь завершает работу через выход из учетной записи.
2. При смене сотрудника администратор блокирует учетную запись и проверяет права на проекты.
3. Исторические данные сохраняются в отчетах, если это требуется для аналитики и договорной отчетности.
4. При удалении данных администратор действует по утвержденному регламенту заказчика и политике обработки персональных данных.

5.16 Контрольный список после ввода в эксплуатацию

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

6. Процессы, обеспечивающие поддержание жизненного цикла

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

6.1 Поддержание жизненного цикла

• Развитие и сопровождение продукта выполняются правообладателем ООО «Дексмобайл».
• Жизненный цикл включает разработку, тестирование, выпуск версии, развертывание у заказчика, эксплуатацию, сопровождение и вывод версии из обращения.
• Новые версии выпускаются по мере готовности функциональных улучшений и исправлений; к каждой версии готовятся описание изменений и инструкция по миграции.
• Обновления устанавливаются сначала в тестовом контуре, затем в промышленном; порядок описан в разделе 5.12.
• Документация обновляется при изменении функций, требований к установке или регламента эксплуатации.
• Поддержка внедрения и обучения предоставляется в течение первых двух месяцев пилотного проекта.

6.2 Устранение неисправностей, выявленных в ходе эксплуатации

• Неисправности регистрируются через электронную почту поддержки или согласованную с заказчиком систему Service Desk.
• При обращении указываются контур, версия продукта, описание проблемы, время возникновения, затронутый проект, текст или снимок экрана с ошибкой и последние действия пользователя.
• Обращению присваивается уровень критичности по классификации раздела 5.14: критичный, высокий, средний или низкий.
• Критичные обращения обрабатываются приоритетно; конкретные сроки реакции и восстановления фиксируются в договоре сопровождения.
• По результатам разбора выпускается исправление в составе планового или внепланового обновления; заказчик получает уведомление и инструкцию по установке.
• Массовые исправления доставляются обновлением версии продукта, единичные — по индивидуальному обращению заказчика.

6.3 Совершенствование программного обеспечения

• Предложения по развитию продукта принимаются от заказчиков на адрес sales@dex-it.ru и через ответственных специалистов сопровождения.
• Поступившие предложения, замечания и результаты разбора инцидентов формируют план развития продукта.
• Правообладатель самостоятельно определяет состав и сроки доработок; приоритет отдается изменениям, влияющим на корректность расчетов и устойчивость системы.
• Реализованные улучшения включаются в очередную версию, изменения отражаются в описании версии и в настоящей документации.

6.4 Техническая поддержка

7. Сведения о правообладателе