Зачем нужно Техническое Задание (ТЗ) и как его правильно составить

Зачем нужно Техническое Задание (ТЗ) и как его правильно составить для заказной разработки СКУД «ЭНТ»

Приветствуем вас, коллеги!

Если вы читаете эту статью, значит, встроенных возможностей СКУД «ЭНТ Контроль доступа» вам уже недостаточно, и вы хотите заказать внешнюю разработку: нестандартный отчет или сценарий гибкого пропускного режима.

Мы в компании «Эра новых технологий» всегда рады помочь реализовать ваши бизнес-задачи. Но чтобы итоговый продукт точно соответствовал вашим ожиданиям, был сделан в срок и без лишних правок, нам необходимо говорить на одном языке. Этим языком является Техническое Задание (ТЗ).

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

1. Что такое ТЗ и почему это важно?

ТЗ — это не бюрократическая отписка и не формальность. Это фундамент вашего проекта.

• Для вас (Заказчика): ТЗ — это гарантия того, что вы получите именно тот продукт, который ожидаете. Если в ТЗ написано «отчет выгружает колонку А и Б», а вы хотели еще и колонку В, но забыли её указать — разработчик сделает всё строго по ТЗ.
• Для нас (Исполнителя): ТЗ — это четкая инструкция к действию. Чем точнее оно составлено, тем быстрее мы оценим трудозатраты, назовем сроки и цену, и тем качественнее будет результат.

2. Как мы работаем: процесс заказной разработки

Чтобы вы понимали, чего ожидать, вот наш стандартный алгоритм работы:

3. Анатомия ТЗ: плохо vs хорошо

Чтобы понять разницу, давайте посмотрим на примеры.

Плохое ТЗ для отчета

«Нужен отчет по рабочему времени. Чтобы показывал, кто когда пришел и ушел. Должен быть удобным, красивым и работать быстро. Сделать как в 1С.»

Хорошее ТЗ для отчета

• Название: Отчет «Фактическое время присутствия с учетом опозданий».
• Назначение: Контроль трудовой дисциплины.
• Источники данных: События «Проход» из ПО «ЭНТ Контроль доступа - Клиент».
• Выходные данные: ФИО, Табельный номер, Подразделение, Свойство 1, Дата, Время входа, Время выхода, Факт опоздания (Да/Нет).
• Настройки отчета: отчет должен взаимодействовать с чекбоксом «Не разбивать отчет на страницы» в ПО «Клиент».

Логика расчета времени и опозданий:

1. Время входа: берется первое событие «Проход (Вход)» за день.
2. Время выхода: берется последнее событие «Проход (Выход)» за день.
3. Факт опоздания: если «Время входа» позже 09:00, ставим «Да», иначе «Нет».
4. Обработка «грязных» данных: если за день есть только вход без выхода — считать время до конца рабочего дня (23:59). Двойные входы подряд игнорировать, брать только последнее событие.

Плохое ТЗ на сценарий

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

Хорошее ТЗ на сценарий

• Название: сценарий «Контроль баланса и глобальный антипассбэк».
• Назначение: ограничение доступа при нулевом балансе и запрет повторного прохода в одном направлении на всех точках прохода офиса.
• Описание бизнес-задачи: при прикладывании карты система должна проверить остаток баланса сотрудника. Если баланс положительный — разрешить проход и списать 1 единицу. Также система должна следить за направлением: нельзя войти дважды подряд без выхода.

Алгоритм принятия решения:

1. Получить UID ключа и направление (Вход/Выход) от контроллера.
2. Найти в БД сотрудника по UID и проверить поле «Баланс».
3. Если «Баланс» <= 0 — вернуть «Запретить».
4. Если «Баланс» > 0 — проверить последнее событие «Проход» этого сотрудника.
5. Если последнее событие совпадает с текущим направлением (например, снова Вход) — вернуть «Запретить» (сработал антипассбэк).
6. Если направление противоположное — вернуть «Разрешить» и обновить в БД поле «Баланс» (уменьшить на 1).

Используемое оборудование и архитектура проходов:

• Тип точки прохода: Турникеты с датчиками поворота трипода (событие прохода фиксируется по датчику).
• Несколько контроллеров: Два контроллера (на главной проходной и запасном выходе). Логика применяется ко всем точкам вместе (глобальный антипассбэк). Контроллеры объединены в «Общую зону прохода» в ПО «Клиент».

Изменения в БД: Сценарий должен уменьшать значение в поле «Баланс» на 1 при каждом успешном проходе.

4. Технические нюансы, которые нужно знать

Прежде чем писать ТЗ, важно понимать, как устроены наши решения «под капотом». Это сэкономит вам время.

Про внешние отчеты (.rep)

Внешний отчет подключается к базе данных Firebird напрямую и пишет свои SQL-запросы.

• Производительность: Скорость формирования отчета зависит от объема данных, сложности запросов и мощности вашего сервера (SSD, объем RAM). Если у вас тысячи проходов в день, и вы строите отчет за год — это потребует времени. Если потребуется дополнительная оптимизация базы данных (например, настройка индексов), мы сможем это сделать за дополнительную плату.

Про сценарии гибкого режима (.dll)

Сценарий работает как плагин для службы «Подтверждение доступа». Он получает от контроллера UID ключа, направление и время, делает запрос в БД и возвращает решение «Разрешить» или «Запретить».

5. Чек-листы для составления ТЗ

Используйте эти списки как шаблон при написании вашего ТЗ.

Чек-лист ТЗ на разработку внешнего отчета

• 1. Название отчета.
• 2. Назначение: функциональное и эксплуатационное назначение. Какие задачи решает?
• 3. Визуальный макет: скриншот или рисунок того, как отчет должен выглядеть (можно отдельным приложением к ТЗ).
• 3. Шаблон отчет:
  • Выходные данные и композиция: какие именно колонки/поля должны быть в отчете (ФИО, дата, время, свойства 1-4 и т.д.), их организация, размер, шрифт, цвет.
  • Источники данных: откуда брать данные. Например:
    • Поле отчета «Должность» из поля ПО «Клиент» «Должность» / «Свойство пользователя»;
    • Поле отчета «Группа» из поля ПО «Клиент» «Свойство #1» / «Свойство пользователя»; 
    • Поле отчета «Время входа» — это время первого за сутки события «Проход» по направлению вход).
  • Логика работы: Формулы расчета, правила округления, конвертации данных. Например:
    • Формула расчета для поля «Общее время присутствия» = последний выход за сутки — первый вход за сутки.
    • Все расчеты производятся в секундах. Финальная конвертация в формат ЧЧ:ММ. Секунды отбрасываются (округление вниз).
  • Обработка ошибок и граничные случаи: как обрабатывать двойные входы/выходы, первый выход без входа, последний вход без выхода.
  • Требования к представлению: группировка, сортировка, визуализация (таблица, списки).
• 4. Формат выгрузки: Excel, PDF, XML, прямая печать.
• 5. Требования к настройкам отчета: базовые параметры (выбор периода, фильтрация) применяются автоматически. Но если нужны специфические настройки в интерфейсе, их нужно перечислить. Примеры:
  • 11.a. Чекбокс «Считать незакрытые периоды».
  • 11.b. Чекбокс «Не выводить в отчет пользователей с пустыми значениями».
  • 11.c. Чекбокс «Не разбивать отчет на страницы».
  • 11.d. Кнопка «Использовать архивные таблицы».
• 6. Используемое оборудование и архитектура проходов:
  • 8.a. Тип точки прохода: укажите, что именно установлено. Есть ли преграждающий механизм (турникет, калитка, шлагбаум) или это просто дверь? Это для понимания того, что будет давать сигнал на формирование события о проходе.
  • 8.b. Несколько контроллеров: если для отчета необходимо использовать несколько контроллеров, опишите, как они расположены с алгоритмом прохождения через них пользователей.

Чек-лист ТЗ на разработку сценария (плагина)

• 1. Название сценария.
• 2. Назначение: функциональное и эксплуатационное назначение.
• 3. Описание бизнес-задачи: что должно происходить при проходе сотрудника.
• 4. Алгоритм принятия решения: какие данные проверять в БД, какие условия должны быть выполнены для разрешения/запрета прохода.
• 5. Используемое оборудование и архитектура проходов:
  • 5.a. Тип точки прохода: укажите, что именно установлено (турникет, калитка, дверь без геркона и т.д.).
  • 5.b. Несколько контроллеров: опишите алгоритм прохождения пользователем через точки прохода. Уточните, логика применяется к каждой точке отдельно (локальный антипассбэк) или ко всем вместе (глобальный).
• 6. Изменения в БД: нужно ли сценарию обновлять данные в базе (например, списывать баланс, менять счетчики).

6. Юридические, финансовые аспекты и приемка

Порядок сдачи и приемки работ

Внесение изменений в процессе разработки

Если в процессе работы вы хотите изменить логику, алгоритмы или добавить новые требования, необходимо подписать Дополнительное соглашение к ТЗ. Если изменения увеличивают трудозатраты, стоимость и сроки пересматриваются.

Гарантийный период

Что НЕ входит в стоимость разработки

Заключение

© Эра новых технологий. Скворцов Константин Валерьевич.