157 lines
16 KiB
Markdown
157 lines
16 KiB
Markdown
# Анализ технического задания
|
||
|
||
**Документ:** ТЗ на создание автоматизированной системы «Платформа ОПОРА РОССИИ»
|
||
**Основание:** ГОСТ 34.602-2020
|
||
**Версия:** 0.3 от 25.09.2026, статус — проект ТЗ (черновик для согласования)
|
||
**Объём:** 9 разделов + 3 приложения (А, Б, В)
|
||
|
||
---
|
||
|
||
## 1. Общая характеристика
|
||
|
||
Документ описывает создание автоматизированной системы для общероссийской общественной организации МСП «ОПОРА РОССИИ». Система объединяет три канала:
|
||
|
||
- **мессенджер-бот** (Telegram, вариант — MAX) — точка входа, авторизация, рассылки;
|
||
- **веб-приложение (mobile-first)** — личный кабинет, цели, рейтинги, карточки регионов, задачи, артефакты;
|
||
- **серверная часть (API) + БД** — единое хранилище для бота и сайта.
|
||
|
||
Ключевая бизнес-идея — прозрачный учёт целевых показателей (рост базы членов, «точка 0», прирост, рейтинг 89 регионов и 8 округов) и вовлечение региональных отделений через персональные рассылки и «красную зону».
|
||
|
||
Документ подготовлен аккуратно, структура соответствует ГОСТ, открытые вопросы вынесены в варианты решений. Это **хороший черновик уровня «концепция + ТЗ»**, но до подписания требует устранения ряда пробелов и внутренних несоответствий.
|
||
|
||
---
|
||
|
||
## 2. Соответствие ГОСТ 34.602-2020
|
||
|
||
| Требуемый раздел ГОСТ | Наличие | Комментарий |
|
||
|---|---|---|
|
||
| Общие сведения | ✅ | п. 1, но часть полей — заглушки |
|
||
| Назначение и цели создания | ✅ | п. 2, цели измеримы |
|
||
| Характеристика объектов автоматизации | ✅ | п. 3 |
|
||
| Требования к системе | ✅ | п. 4 (в целом, функции, виды обеспечения) |
|
||
| Состав и содержание работ | ✅ | п. 5, таблица по стадиям ГОСТ 34.601 |
|
||
| Порядок контроля и приёмки | ✅ | п. 6 |
|
||
| Требования к подготовке объекта | ✅ | п. 7 |
|
||
| Требования к документированию | ✅ | п. 8 |
|
||
| Источники разработки | ✅ | п. 9 |
|
||
|
||
**Вывод:** формально структура полная. Основные проблемы — не в составе разделов, а в глубине и непротиворечивости требований.
|
||
|
||
---
|
||
|
||
## 3. Сильные стороны
|
||
|
||
1. **Чёткая структура и трассируемость** — функции (4.2), виды обеспечения (4.3) и приёмка (6.3) связаны между собой.
|
||
2. **Измеримые показатели назначения** (4.1.3): время загрузки ≤ 3 с, экран целей ≤ 2 с, рассылка ≤ 1 ч, доступность ≥ 99%.
|
||
3. **Явные варианты решений** (Приложение В) — 10 открытых вопросов с рекомендацией «Вариант 1». Это правильный способ зафиксировать неопределённость до согласования.
|
||
4. **Mobile-first и эргономика** (4.1.6) — учтён основной сценарий (смартфон, встроенные браузеры мессенджеров).
|
||
5. **Безопасность входа** — одноразовые ссылки, блокировка повторного использования, привязка сессии к аккаунту мессенджера, журналирование.
|
||
6. **Референс функциональности** (Приложение Б) — состав экранов аналогичной платформы, что снижает риск недопонимания.
|
||
7. **Хостинг на территории РФ** (4.3.5) и патентная чистота (4.1.11) — учтены российские требования.
|
||
|
||
---
|
||
|
||
## 4. Пробелы и риски
|
||
|
||
### 4.1. Незаполненные обязательные поля
|
||
- Шифр темы, заказчик и разработчик, сроки начала/окончания, источники финансирования, домен (пп. 1.1–1.5, 7).
|
||
- Без этих данных ТЗ не может быть утверждено и не может служить основанием договора.
|
||
|
||
### 4.2. Персональные данные и регуляторика (критично)
|
||
- Система хранит ФИО, аккаунты мессенджеров, членство, контакты. **Нет ни одного упоминания 152-ФЗ** «О персональных данных»: согласие на обработку, цели, сроки хранения, права субъекта, требования к защите (ПП-1119, при необходимости — ФСТЭК).
|
||
- Нет требований к согласию и **отписке от массовых рассылок** (риск спама и жалоб).
|
||
- Для AI-ассистента «Зам» (Вариант 1) не определено, где обрабатываются данные и какому LLM-провайдеру передаются — риск утечки ПДн за периметр РФ.
|
||
|
||
### 4.3. Нефункциональные требования заданы поверхностно
|
||
- **Нагрузка:** нет профиля (число одновременных пользователей, пиковые нагрузки), хотя масштаб задан в пользователях/подписчиках.
|
||
- **Надёжность:** RPO/RTO не заданы явно (только «восстановление ≤ 24 ч» и ежесуточный бэкап → RPO до 24 ч, что может быть неприемлемо).
|
||
- **Мониторинг/алертинг/наблюдаемость** не описаны.
|
||
- **Сроки хранения журналов** (аудит, действия ассистента, рассылки) не заданы.
|
||
- **SLA** ограничен доступностью 99%; нет описания поддержки, времени реакции на инциденты.
|
||
|
||
### 4.4. Интеграции и данные
|
||
- Интеграция с существующими учётными системами — только «при наличии» (п. 7), без анализа.
|
||
- **MAX Bot API** — возможность интеграции не подтверждена (п. 4.1.13.2, Вариант 2). Это внешний риск, влияющий на сроки.
|
||
- Нет требований к API: версионирование, лимиты, форматы ошибок, идемпотентность.
|
||
- Не определён **владелец и жизненный цикл «точки 0»** (кто задаёт, можно ли менять, как корректируются ошибки выгрузок).
|
||
|
||
### 4.5. Функциональные неоднозначности
|
||
- **Рейтинг, Вариант 2** — «взвешенная формула», но веса не заданы и не определены шкалы.
|
||
- **Рассылки, Вариант 2** — конструктор, A/B-тесты, статистика открытий: существенно расширяет объём, но без оценки трудозатрат.
|
||
- **Артефакты, Вариант 2** — медиатека с версионированием и правами: отдельная подсистема.
|
||
- **AI-ассистент** — не заданы модель угроз, ограничения по типам действий, механизм подтверждения владельцем, поведение при ошибке публикации.
|
||
- Нет требований к **модерации** «Советов от регионов» и пользовательского контента.
|
||
|
||
### 4.6. Отсутствующие разделы/темы
|
||
- Оценка стоимости и трудозатрат (в п. 5 упоминается «оценка стоимости» на этапе концепции, но цифр нет).
|
||
- Требования к тестированию и покрытию (кроме видов испытаний в п. 6).
|
||
- Требования к доступности для людей с ограниченными возможностями.
|
||
- Требования к резервному копированию файлов (артефактов), а не только БД.
|
||
- План миграции данных и критерии качества данных.
|
||
|
||
---
|
||
|
||
## 5. Внутренние несоответствия и дефекты
|
||
|
||
1. **Битая ссылка на подпункты.** П. 4.1.13 (строка 142) ссылается на «пп. 4.1.13.1–4.1.13.10», но фактически существуют только 4.1.13.1–4.1.13.3. Нужно либо добавить подпункты, либо исправить диапазон.
|
||
2. **Расхождение онбординга.** П. 4.2.2: 5 шагов — «…защита проекта и получение поддержки». Приложение Б: «…Мурманск → защита проекта и грант». Формулировки и содержание шагов не совпадают.
|
||
3. **Терминология.** В основном тексте — «проекты Организации», в Приложении Б — «МПР 2026» / «Регистрации МПР 2026». Нужен единый глоссарий (частично есть в 4.3.3, но «МПР» не раскрыт).
|
||
4. **Ссылки на пункты в таблице В.1** корректны, но в тексте п. 4.1.13.1 назван «Масштаб системы», а в таблице — «Масштаб»; мелочь, но для утверждаемого документа важна точность.
|
||
5. **Приложение Б** описывает референс, но не помечено, какие экраны **обязательны**, а какие — только ориентир. Это создаёт риск спора на приёмке.
|
||
6. **Критерии приёмки** (6.3) ссылаются на «выбранные варианты», которые ещё не выбраны. До фиксации вариантов приёмка неопределима.
|
||
|
||
---
|
||
|
||
## 6. Сводка открытых вопросов (Приложение В)
|
||
|
||
| № | Вопрос | Рекомендуемый вариант | Влияние на объём |
|
||
|---|---|---|---|
|
||
| 1 | Ассистент «Зам» | AI-ассистент | Высокое (LLM, безопасность, ПДн) |
|
||
| 2 | Доступ к задачам | Все авторизованные | Среднее |
|
||
| 3 | Артефакты | Простая загрузка | Низкое/Высокое (медиатека) |
|
||
| 4 | Карточка региона | Только своё отделение | Среднее (риск открытой модели) |
|
||
| 5 | Рассылки | Фиксированные шаблоны | Высокое (конструктор) |
|
||
| 6 | Рейтинг | По приросту от точки 0 | Среднее |
|
||
| 7 | История платформы | Публичная лента | Низкое |
|
||
| 8 | Мессенджеры | Telegram + MAX сразу | Высокое (риск MAX API) |
|
||
| 9 | Масштаб | До 10 тыс. пользователей | Высокое (кластер) |
|
||
| 10 | Дизайн | По брендбуку | Среднее |
|
||
|
||
**Рекомендация:** зафиксировать все 10 вариантов **до** заключения договора, иначе объём и стоимость будут плавающими.
|
||
|
||
---
|
||
|
||
## 7. Рекомендации
|
||
|
||
**Приоритет 1 (блокеры утверждения):**
|
||
1. Заполнить обязательные поля (заказчик, разработчик, сроки, финансирование, шифр, домен).
|
||
2. Добавить раздел по **152-ФЗ**: правовые основания, согласия, сроки хранения, меры защиты, локализация ПДн.
|
||
3. Зафиксировать выбор по всем 10 вариантам Приложения В.
|
||
4. Устранить внутренние несоответствия (п. 5 настоящего анализа).
|
||
|
||
**Приоритет 2 (управление рисками):**
|
||
5. Провести техническое обследование **MAX Bot API** до фиксации Варианта 1 по п. 4.1.13.2.
|
||
6. Задать профиль нагрузки и уточнить RPO/RTO, мониторинг, сроки хранения журналов.
|
||
7. Для AI-ассистента — модель угроз, ограничения действий, требования к LLM-провайдеру и локализации данных.
|
||
8. Определить жизненный цикл «точки 0» и правила корректировки данных.
|
||
|
||
**Приоритет 3 (качество):**
|
||
9. Добавить требования к API (версионирование, лимиты, ошибки).
|
||
10. Добавить требования к тестированию, доступности (a11y), резервному копированию файлов.
|
||
11. Пометить в Приложении Б обязательные и опциональные экраны.
|
||
12. Приложить оценку трудозатрат и стоимости по каждому варианту.
|
||
|
||
---
|
||
|
||
## 8. Итоговая оценка
|
||
|
||
| Критерий | Оценка |
|
||
|---|---|
|
||
| Соответствие ГОСТ 34.602-2020 (структура) | 9/10 |
|
||
| Полнота требований | 6/10 |
|
||
| Непротиворечивость | 6/10 |
|
||
| Готовность к утверждению | 4/10 (черновик) |
|
||
| Управление неопределённостью (варианты) | 9/10 |
|
||
|
||
**Вывод:** документ — качественный черновик с правильной структурой и хорошей проработкой бизнес-логики. Главные доработки перед утверждением: правовой блок (152-ФЗ), фиксация вариантов, устранение внутренних расхождений и уточнение нефункциональных требований. После этого ТЗ может служить основанием для договора и календарного плана.
|