Мест меньше, чем сотрудников. Кто-то бронирует и не приезжает, кто-то встаёт на чужое место, а разбираются потом руками — по журналам шлагбаума и переписке в чате.
← Все проекты
Производство и офис · Архитектура и ТЗ · часть контура в продакшене
Корпоративный паркинг: бронирование мест и СКУД
Сервис бронирования парковки, где въезд по брони подтверждают шлагбаум и камеры, а неявки и нарушения считаются без ручного разбора. Требования написаны так, что разработку можно оценить заранее и принять по списку.
157пунктов, по которым принимается работа
4противоречия сняты до разработки
2источника подтверждают въезд: шлагбаум и камеры
Задача
Что сделали
Работу принимают по списку
157 требований, у каждого — источник в исходном документе и критерий приёмки. Отдельный каталог из 27 сценариев: 19 Must, 6 Should, 2 Could.
Противоречия сняты до кода
Окно check-in в одном разделе −30/+30 минут, в таблице параметров −30/+60. Таких мест четыре — и все вынесены заказчику до разработки.
Предупредили, каким данным вендора пока нельзя верить
Фактический выезд машины из него напрямую не определяется — только по косвенному признаку. Записали, что его нужно проверить на выборке, прежде чем строить на нём отчётность.
Учтено то, что пряталось в процессах
Около 60 требований вытащены из сквозных процессов, уведомлений и санкций. В разделе «Функциональные требования» была меньше половины.
Почему этому можно верить
- Повторное событие проезда
- Приём идемпотентный. Если СКУД прислал одно событие дважды, второго check-in не будет и нарушение не начислится.
- Время проезда
- Когда интеграция передаёт только факт, без времени, ставится время приёма и признак «приближённое». Признак виден в детализации и учитывается в отчётах. Спрятать его значило бы врать в статистике неявок.
- Сверка
- Расхождения между сервисом и СКУД ловятся регламентной сверкой, по умолчанию раз в 5 минут, интервал меняется без остановки. Верить, что интеграция всегда доставила, не стали.
- Противоречия в исходнике
- Четыре нашли до проектирования: окно check-in задано двумя значениями, статус «Подтверждено» есть в процессах и отсутствует в модели, check-in приходит из двух источников, пропуск описан то как долгоживущее право, то как одноразовый. Все четыре у заказчика.
Как устроено
- Наш слой
- Фасад над API бронирования вендора: действия с бронями, блокировка пользователей, статистика. Управление фондом мест в первую версию не входит.
- СКУД
- События проезда с временем и направлением, повторные попытки, мониторинг задержки, сверка.
- Видеоаналитика
- Второй источник check-in, контроль занятия места.
- Требования
- 157 ФТ в 17 блоках, у каждого источник в исходном документе и критерий приёмки. Шесть НФТ: атомарная бронь, 3 секунды на 95-м перцентиле, ограничение частоты запросов против массового бронирования.
- Сценарии
- Каталог из 27 UC в пяти группах, у каждого помечено, чей это слой, вендора или наш.
Похожая задача?
Опишите её — пришлём состав работ и смету за 24 часа.