2 Цели и видение системы

2.1 Общие сведения 

Название проекта: "Автоматизированная система управления заявками на осмотр судов" (Портал "Осмотры судов")

Категория системы: "Адаптивная Web-система с элементами бизнес-аналитики"

Заказчик: (Инициатива Тазмар)

2.2 Текущая ситуация и анализ проблем


  1. Агенты за 72 часа до прибытия судна в порт создают заявку на вход в ПО PortCall
  2. Служба капитана порта получает заявку и, если судно приплывает из зарубежного порта, то отправляет список заявок в Службу контроля
  3. Служба контроля принимает решение о необходимости проведения осмотра подводной части судна, отправляет решение в Службу капитана порта.
  4. Служба капитана порта сообщает Агенту о необходимости осмотра судна
  5. Агент ищет Исполнителя, который сможет провести осмотр судна. Заключает с ним договор.
  6. Исполнитель выполняет осмотр подводной части судна и отправляет результаты осмотра в службу капитана порта
  7. Служба капитана порта отправляет результаты осмотра в службу контроля
  8. Служба контроля принимает решение о допуске судна в порт и сообщает решение Службе капитана порта
  9. Служба капитана порта сообщает итоговое решение о допуске судна в порт Агенту.


Существующие проблемы 

  • Отсутствие систематизированного процесса осмотра судов
  • Высокий риск потери важной информации (заявки, результаты осмотра) 
  • Отсутствие истории заявок и прозрачности процесса работы с обращением Клиента на осмотр.


Текущий бизнес-процесс управления заявками представлен в нотации BPMN в Как есть сейчас: Бизнес-процесс оформления заявки на осмотр судна


Деятельность, которую хочется улучшить  

  • Оформление и согласование заявок; 
  • Составление отчетов о результатах осмотра;
  • Коммуникации между заинтересованными лицами.

2.3 Цели разработки

Цели разработки системы:  

  • Снизить риск потерь информации и данных за счет систематизации заявок на осмотр судов💬
  • Создать единый стандарт осмотра судов 


Назначение системы 

  • Управление заявками на осмотр судов

2.4 Бизнес-требования

Бизнес-требования

Постановление Правительства Российской Федерации от 25 ноября 2025 г. N 1867 “Об утверждении Правил согласования разрешения на заход следующих из иностранных портов судов в морские порты Российской Федерации с должностным лицом органа федеральной службы безопасности💬 и Правил проведения осмотра подводной части судов, прибывающих в морские порты Российской Федерации” - https://www.garant.ru/products/ipo/prime/doc/413032861/

2.5 Видение продукта

2.5.1 Функциональные модули системы 

 1) Справочники

Назначение: хранение справочных данных, управление 

Список справочников системы:

  • Порты, причалы и стоянки;
  • Судна.

2) Заявки

Назначение: обработка заявок на осмотр

Функции: 

  1. Создание, обработка и управление заявками на осмотр;
  2. Назначение Исполнителей;
  3. Планирование работ по осмотру;
  4. Фиксация результатов осмотра;
  5. Экспорт заявок;
  6. Прикрепление файлов в карточку Заявки.
  7. Генерация Актов по завершению осмотра.

3) Пользователи

Назначение: хранение данных пользователей, управление пользователями 

Функции: 

  1. Создание и управление пользователями 
  2. Обновление данных пользователей 
  3. Управление правами и доступами пользователей 
  4. Настройки уведомлений


Новый бизнес-процесс управления заявками представлен в нотации BPMN Как будет: Бизнес-процесс оформления заявки на осмотр

Схема черного ящика (контекстная диаграмма) представлена в нотации C1 Контекстная диаграмма

2.5.2 Классы и характеристики пользователей

Классы и характеристики пользователей

Комментарии (8) · по состоянию на 2026-09-18

К фрагментам текста

claude-code · 2026-09-15 09:13 МСК · открыт · к фрагменту · 73074879
«Снизить риск потерь информации и данных за счет систематизации заявок на осмотр судов»

[Ревью] Критично (MVP): качественные цели раздела 2.3 («снизить риск потерь информации», «создать единый стандарт осмотра судов») сформулированы без измеримых критериев — нет baseline, целевого показателя (%) и метода измерения. Без этого нельзя будет подтвердить достижение целей проекта.

Софья Герасимова · 2026-09-15 10:24 МСК · 73075183

В рамках инициативы нет конкретных измеримых показателей. Работаем пока без них

claude-code · 2026-09-15 13:40 МСК · 73075455

[Ревью] Не решено (принято как риск): подтверждаем, что измеримые метрики к целям раздела 2.3 (baseline, целевой %, способ измерения) сознательно не вводятся в рамках текущей инициативы. Фиксируем это как осознанно принятое решение/риск, не блокирующий MVP — вопрос остаётся открытым на будущее.

claude-code · 2026-09-16 08:45 МСК · 73075667

[Ревью] Пока актуально: цели/показатели раздела 2.3 не имеют измеримых метрик (baseline, целевой %, метод измерения). Новая страница решений (id 73075569) этот вопрос не закрывает — метрики к целям там не упомянуты. Оставляем как принятый риск для MVP, актуально для послед. этапов.

claude-code · 2026-09-15 09:13 МСК · решён · к фрагменту · 73074881
«федеральной службы безопасности»

[Ревью] Критично (вне MVP, но важно для понимания): в п.2.2 фигурирует актор «Служба контроля», а в нормативной ссылке (п.2.4) и на диаграммах — «Федеральная служба безопасности». Не ясно, это одна и та же роль (переименование) или разные сущности — есть риск создать в системе две разные роли вместо одной.

Софья Герасимова · 2026-09-15 10:25 МСК · 73075184

Это одно и то же

claude-code · 2026-09-15 13:40 МСК · 73075458

[Ревью] Решено, спасибо — подтверждено, что «Служба контроля» и «федеральная служба безопасности» это одна и та же сущность, риска создания двух разных ролей нет.

claude-code · 2026-09-16 10:16 МСК · 73075766

[Ревью] РЕШЕНО — можно удалить. Подтверждено: «Служба контроля» и «федеральная служба безопасности» — одна и та же сущность, риск дублирования ролей снят.