commit 436248937243a3c71df1549f324280226a1077d6 Author: Kavalar Date: Sat Sep 26 18:42:46 2026 +0300 docs: add technical specification (GOST 34.602-2020) and analysis diff --git a/docs/analiz_TZ.md b/docs/analiz_TZ.md new file mode 100644 index 0000000..cf1d9ad --- /dev/null +++ b/docs/analiz_TZ.md @@ -0,0 +1,156 @@ +# Анализ технического задания + +**Документ:** ТЗ на создание автоматизированной системы «Платформа ОПОРА РОССИИ» +**Основание:** ГОСТ 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-ФЗ), фиксация вариантов, устранение внутренних расхождений и уточнение нефункциональных требований. После этого ТЗ может служить основанием для договора и календарного плана. diff --git a/docs/spec_text.txt b/docs/spec_text.txt new file mode 100644 index 0000000..3402d56 --- /dev/null +++ b/docs/spec_text.txt @@ -0,0 +1,456 @@ +ТЕХНИЧЕСКОЕ ЗАДАНИЕ +на создание автоматизированной системы «Платформа ОПОРА РОССИИ» +Документ разработан в соответствии с ГОСТ 34.602-2020 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы» +Таблица 1 — Сведения о документе +Шифр темы +(заполняется при утверждении) +Версия документа +0.3 +Дата +25.09.2026 +Статус +Проект ТЗ (черновик для согласования) + +1. Общие сведения +1.1. Полное наименование системы: Автоматизированная система «Платформа ОПОРА РОССИИ» (далее — Система). +Условное обозначение: АС «Платформа ОПОРА РОССИИ». +1.2. Наименования заказчика и разработчика (участников работ) — заполняются при утверждении настоящего ТЗ. +1.3. Перечень документов, на основании которых создаётся Система: +– настоящее техническое задание; +– описание бизнес-процессов Организации «ОПОРА РОССИИ» (Приложение А); +– материалы обследования аналогичной действующей платформы (референс функциональности): скриншоты экранов сайта `rmpred.ru` и бота `@pmpred_bot` (Приложение Б). +1.4. Плановые сроки начала и окончания работ по созданию Системы — заполняются при утверждении настоящего ТЗ. +1.5. Сведения об источниках и порядке финансирования — заполняются при утверждении настоящего ТЗ. +1.6. Порядок оформления и предъявления заказчику результатов работ: результаты работ по этапам предъявляются заказчику в соответствии с календарным планом; приёмка осуществляется в порядке, установленном разделом 6 настоящего ТЗ. +2. Назначение и цели создания (развития) системы +2.1. Назначение Системы. +Система предназначена для автоматизации деятельности общероссийской общественной организации малого и среднего предпринимательства «ОПОРА РОССИИ» (далее — Организация), а именно: +– автоматизации учёта, расчёта и отображения целевых показателей Организации (цели, рейтинги, динамика региональных отделений и округов); +– автоматизации коммуникаций с членами Организации через мессенджер-бот (информационные, образовательные и рейтинговые рассылки); +– обеспечения авторизованного доступа членов Организации к личному кабинету через бота (мессенджеры Telegram и MAX); +– ведения данных региональных отделений (карточка отделения, члены, численность, ссылки на сообщества и чаты); +– хранения и загрузки артефактов; +– ведения задач (трекер); +– обмена практиками между региональными отделениями («Советы от регионов»); +– поддержки ассистента «Зам» (вариант — см. п. 4.2.14). +2.2. Цели создания Системы: +– рост базы членов Организации до целевого значения (общая цель, например +1096 к базе от «точки 0»); +– обеспечение прозрачности результатов: каждое региональное отделение и округ видит свой вклад в общий результат; +– сокращение времени на сбор, обработку и публикацию данных (автообновление срезов); +– повышение вовлечённости региональных отделений: выявление «красной зоны» (отделения без динамики) и адресная помощь; +– снижение рутинных операций за счёт автоматических рассылок и (вариант) AI-ассистента; +– создание единой точки входа: бот → сайт → личный кабинет. +3. Характеристика объектов автоматизации +3.1. Объектом автоматизации является деятельность Организации «ОПОРА РОССИИ», включающая: +– руководителей региональных отделений (89 регионов, 8 федеральных округов); +– членов Организации; +– координаторов (выдача ссылок для входа); +– администраторов платформы. +3.2. Автоматизируемые процессы: +– регистрация и авторизация членов Организации через бота; +– рассылки: информационные, образовательные, рейтинговые (еженедельный фокус целей); +– учёт целевых показателей (проекты Организации и др.): «точка 0», текущие срезы, прирост, динамика; +– формирование рейтингов региональных отделений; +– ведение карточек региональных отделений (численность, ссылки на сообщества и чаты, члены); +– загрузка и хранение артефактов; +– ведение задач; +– обработка запросов (заявки на вступление, на доступ, на участие в мероприятиях, на поддержку); +– ведение базы знаний, календаря событий, истории платформы. +3.3. Условия эксплуатации: пользователи работают с Системой преимущественно с мобильных устройств (основной сценарий) через браузер; бот функционирует в мессенджерах Telegram и (вариант) MAX. Допускается работа с персональных компьютеров. +4. Требования к системе +4.1. Требования к системе в целом +4.1.1. Требования к структуре и функционированию Системы. +Система включает следующие подсистемы и компоненты: +1. Мессенджер-бот (Telegram, MAX) — точка входа, авторизация, рассылки, интерактив. +2. Веб-приложение (mobile-first) — личный кабинет, цели, рейтинги, данные региональных отделений, задачи, артефакты. +3. Серверная часть (API) — единое API для бота и сайта. +4. База данных — единое хранилище данных. +5. Модуль выгрузок данных — загрузка срезов, расчёт прироста от «точки 0», автообновление. +6. Модуль рассылок — формирование и отправка сообщений через бота. +7. Модуль AI-ассистента «Зам» (вариант — см. п. 4.2.14). +Требования к функционированию: +– бот и сайт используют единые данные (то, что загружено на сайте, используется в рассылках бота); +– вход на сайт выполняется только через бота по одноразовой ссылке; +– после подтверждения входа ботом сайт открывается автоматически (при сбое — кнопка «Открыть сайт»); +– данные целей обновляются автоматически по выгрузкам (режим «Автообновление»). +4.1.2. Требования к численности и квалификации персонала Системы. +Таблица 2 — Роли и функции персонала +Роль +Функции +Кол-во (ориентировочно) +Администратор платформы +Управление ролями, выгрузками, рассылками, справочниками +1–3 +Координатор +Выдача одноразовых ссылок, поддержка пользователей +5–20 +Руководитель регионального отделения +Работа с целями, рейтингами, карточкой отделения +до 89 +Член Организации +Регистрация, участие, загрузка артефактов +по мере роста базы + +Квалификация: уверенный пользователь мобильных устройств и мессенджеров; специальная подготовка не требуется (обучение — по п. 7). +4.1.3. Показатели назначения. +– время загрузки основных экранов мобильной версии — не более 3 с при типовом канале связи; +– отображение экрана «Цели организации» с данными по 89+ регионам — без заметных задержек (не более 2 с); +– доставка массовой рассылки по всей базе подписчиков — не более 1 часа; +– автообновление срезов — без ручного вмешательства, по расписанию; +– доступность Системы — не менее 99% в месяц. +4.1.4. Требования к надёжности. +– доступность Системы — не менее 99% в месяц (допустимый простой — не более 7,2 ч/мес); +– корректная обработка устаревших выгрузок: цели со свежестью выгрузки более 7 дней исключаются из рассылки «Еженедельный фокус целей»; +– резервное копирование базы данных — ежесуточно; +– восстановление работоспособности после сбоя — не более 24 часов; +– отсутствие потери данных при штатном завершении работы. +4.1.5. Требования к безопасности. +– вход по одноразовым ссылкам; повторное использование ссылки блокируется с сообщением «Ссылка уже была использована. Запросите новую у координатора»; +– привязка сессии к аккаунту мессенджера пользователя; +– разграничение прав доступа по ролям (п. 4.1.8); +– передача данных по защищённому протоколу (TLS); +– журналирование действий пользователей и ассистента (кто, что, когда). +4.1.6. Требования к эргономике и технической эстетике. +– интерфейс проектируется по принципу mobile-first (ширина экрана 360–430 px); +– крупные элементы управления, удобные для касания; +– ключевые показатели отображаются крупными цифрами с подписями («Точка 0», «Сейчас», «Цель»); +– цветовое кодирование зон: динамика / «красная зона» / нейтральное состояние; +– единый визуальный стиль с брендом «ОПОРА РОССИИ»; +– пустые состояния сопровождаются подсказками (например: «Советов пока нет. Когда отделение даст динамику по цели, в боте появится кнопка "Дать совет для других лидеров"»). +4.1.7. Требования к эксплуатации, техническому обслуживанию, ремонту и хранению. +Эксплуатация Системы осуществляется в соответствии с регламентом, разрабатываемым на этапе «Ввод в действие». Техническое обслуживание — силами разработчика (или эксплуатационной организации) по договору сопровождения. +4.1.8. Требования к защите информации от несанкционированного доступа. +– ролевая модель доступа: администратор, координатор, руководитель регионального отделения, член Организации, (вариант) заместитель; +– аутентификация — через аккаунт мессенджера (Telegram/MAX) по одноразовой ссылке; +– авторизация — на уровне API и интерфейса; +– защита от перебора ссылок (случайные токены достаточной длины); +– журналирование попыток несанкционированного доступа. +4.1.9. Требования по сохранности информации при авариях. +– ежесуточное резервное копирование БД; +– хранение резервных копий не менее 30 дней; +– восстановление данных — не более 24 часов. +4.1.10. Требования к защите от влияния внешних воздействий. +Система функционирует в стандартной серверной среде; специальные требования к стойкости к внешним воздействиям не предъявляются (типовые требования к веб-приложениям: защита от DDoS, ограничение частоты запросов). +4.1.11. Требования к патентной чистоте. +Используемые технические решения должны обеспечивать патентную чистоту на территории Российской Федерации. +4.1.12. Требования по стандартизации и унификации. +При создании Системы руководствоваться: ГОСТ 34.601-2020 (стадии создания), ГОСТ 34.602-2020 (настоящее ТЗ), ГОСТ 34.603-2021 (испытания), ГОСТ 19.201-78 (при разработке программной документации). +4.1.13. Дополнительные требования. +– поддержка русского языка интерфейса; +– работа в основных мобильных браузерах (Chrome, Safari) и встроенных браузерах мессенджеров; +– масштабируемость в соответствии с выбранным вариантом (п. 4.1.13.1); +– варианты решений по открытым вопросам приведены в пп. 4.1.13.1–4.1.13.10. +4.1.13.1. Масштаб системы (варианты). +Вариант 1 (рекомендуемый): до 10 000 зарегистрированных пользователей, до 100 000 подписчиков рассылок. Достаточно одного сервера приложений и СУБД с репликацией. +Вариант 2: до 100 000 пользователей, до 1 000 000 подписчиков рассылок. Требуется кластерная архитектура, горизонтальное масштабирование, очередь сообщений для рассылок. +4.1.13.2. Мессенджеры (варианты). +Вариант 1 (рекомендуемый): интеграция с Telegram и MAX с первого этапа создания Системы (единый бот-адаптер с двумя каналами). +Вариант 2: на первом этапе — только Telegram; интеграция с MAX — на втором этапе, после подтверждения возможностей Bot API мессенджера MAX. +4.1.13.3. Дизайн интерфейса (варианты). +Вариант 1 (рекомендуемый): разработка интерфейса на основе брендбука / гайдлайнов «ОПОРА РОССИИ» (при наличии у заказчика). +Вариант 2: разработка нового дизайн-концепта с нуля (создание фирменного стиля интерфейса). +4.2. Требования к функциям (задачам), выполняемым системой +4.2.1. Функция «Авторизация и управление доступом». +– выбор мессенджера на сайте: «Войти через MAX» / «Войти через Telegram»; +– подтверждение входа ботом; автооткрытие личного кабинета; +– одноразовые ссылки входа, выдаваемые координатором; блокировка повторного использования; +– сценарий «Нет доступа? Начните регистрацию через бота»; +– подтверждение входа в боте: «{ФИО}, вход выполнен!»; +– завершение сессии («Выйти»). +4.2.2. Функция «Бот: онбординг, меню, команды». +– онбординг в формате 5 шагов: 1) регистрация на платформе; 2) заявка на вступление в Организацию; 3) онлайн-обучение; 4) участие в очном мероприятии; 5) защита проекта и получение поддержки; +– главное меню: «Войти на сайт», «Мои возможности», «Регионы и пользователи», «Цели организации», «Регистрации на мероприятия», «Помощь»; +– команды: `/start`, `/login`, `/requests`, `/regions`, `/goals`, `/events`, `/help`; +– кнопки: «Открыть сайт», «Открыть цели», «Меню», «Дать совет для других лидеров». +4.2.3. Функция «Рассылки». +Три типа рассылок: +Таблица 3 — Типы рассылок +Тип +Содержание +Периодичность +Информационные +Новости, анонсы, изменения платформы +По мере необходимости +Образовательные +Материалы обучения, шаги программ, практики +По расписанию программ +Рейтинговые / целевые +«Еженедельный фокус целей» — персональная сводка по региону +Еженедельно + +Формат «Еженедельного фокуса целей»: +– регион получателя (например, «Донецкая Народная Республика»); +– включаются только цели со свежей выгрузкой за последние 7 дней; +– позиция региона: «Ваш регион: топ прироста, прирост от 11.06.2026: +134»; +– динамика округа: «Округ: ЮФО: +365, с динамикой 12/12 регионов»; +– рекомендация: «Что делать: удержать темп и поделиться рабочими действиями с округом»; +– кнопка «Открыть цели» — переход на сайт. +4.2.3.1. Управление рассылками (варианты). +Вариант 1 (рекомендуемый): фиксированные шаблоны рассылок (еженедельный фокус целей, анонсы, образовательные материалы). Администратор редактирует тексты шаблонов и запускает рассылки; аудитория определяется автоматически (по региону, роли, подписке). +Вариант 2: конструктор рассылок: произвольный текст/медиа, выбор аудитории (регион, округ, роль), отложенный запуск, статистика доставки и открытий, A/B-тестирование. +4.2.4. Функция «Цели организации». +Экран целевых показателей: «что набираем, где есть движение и кому нужна помощь». Состав экрана: +– общая цель Организации — например, «+1096 к базе членов»; пояснение: «У Организации одна общая цель: вырасти на 1096 от точки 0. Округа показываются как вкладчики в общий результат»; +– вклад в общую цель — суммарный вклад округов (например, +338), численность, зарегистрированные члены, кнопка «Открыть»; +– динамика по цели — «Точка 0» / «Сейчас» / «Цель» с числовыми значениями; +– проекты Организации: активные цели, регионы с динамикой (например, 89), «Есть динамика», «Численность», «Организация: вклад сейчас» (+25), «Проекты: прирост от точки 0» (+2 594); +– параметры среза: «Точка 0: 2026-05-08; текущий срез: 2026-08-07», режим «Автообновление»; +– накопительная динамика регистраций по регионам — график/список прироста от точки 0, стартовая точка (например, 11.06.2026); +– топ включившихся регионов — «Кто сильнее всего включился в проекты» (Москва +224, Башкортостан +217, Санкт-Петербург +159, Донецкая Народная Республика +136, Татарстан +132 и др.); +– красная зона проектов — регионы без накопительного прироста от точки 0; при отсутствии проблемных регионов — статус «все регионы дали прирост»; кнопка «Полный список»; +– советы от регионов — практики региональных лидеров; пустое состояние с подсказкой о кнопке «Дать совет для других лидеров» в боте. +4.2.5. Функция «Рейтинг регионов». +– список/таблица регионов с показателями (прирост, динамика, численность); +– сортировка, фильтры по округам, выделение «красной зоны». +4.2.5.1. Методика расчёта рейтинга (варианты). +Вариант 1 (рекомендуемый): рейтинг по накопительному приросту от «точки 0» (чем больше прирост, тем выше место). +Вариант 2: комплексный рейтинг по взвешенной формуле: прирост от точки 0 + численность + активность членов + выполнение задач. Состав весов утверждается заказчиком. +4.2.6. Функция «Карточка региона». +– основные данные региона (название, округ, статус); +– численность — ввод и обновление; +– ссылки на сообщества и чаты — добавление, редактирование, удаление; +– члены — добавление, список, статусы; +– резиденты (активные члены) — добавление, список; +– история изменений карточки. +4.2.6.1. Права редактирования карточки региона (варианты). +Вариант 1 (рекомендуемый): руководитель регионального отделения редактирует только карточку своего отделения; администратор — карточки всех отделений. +Вариант 2: все авторизованные пользователи могут редактировать карточки любых региональных отделений (открытая модель). +4.2.7. Функция «Члены Организации». +– добавление членов и резидентов (активных членов); +– просмотр списков, поиск; +– учёт численности (общая и по категориям). +4.2.8. Функция «Артефакты». +– загрузка файлов с привязкой к региону / цели / задаче; +– список, скачивание, удаление. +4.2.8.1. Модель хранения артефактов (варианты). +Вариант 1 (рекомендуемый): простая загрузка файлов (изображения, PDF, DOCX, XLSX, до 50 МБ на файл) с привязкой к объекту. +Вариант 2: медиатека с категориями, тегами, поиском, версионированием файлов и контролем прав на скачивание. +4.2.9. Функция «Задачи» (трекер). +– создание задачи: название, описание, срок, приоритет, ответственный; +– назначение исполнителя (член Организации / отделение / роль); +– статусы: новая → в работе → на проверке → выполнена; +– комментарии, прикрепление артефактов; +– список задач с фильтрами (мои, по региону, просроченные). +4.2.9.1. Доступ к задачам (варианты). +Вариант 1 (рекомендуемый): задачи доступны всем авторизованным членам Организации: каждый ведёт свои задачи; руководитель регионального отделения видит задачи своего отделения; администратор — все задачи. +Вариант 2: задачи доступны только руководителям региональных отделений и администраторам (члены Организации задачи не ведут). +4.2.10. Функция «База знаний». +– статьи, инструкции, материалы Организации; +– категории, поиск. +4.2.11. Функция «Календарь событий». +– события Организации (мероприятия, вебинары, дедлайны); +– отображение по месяцам; +– напоминания через бота. +4.2.12. Функция «Запросы». +– заявки членов Организации (на вступление, на доступ, на участие в мероприятиях, на поддержку); +– статусы обработки, ответы. +4.2.13. Функция «История платформы». +4.2.13.1. Содержание раздела (варианты). +Вариант 1 (рекомендуемый): публичная лента новостей и достижений платформы (хронология событий, доступна всем пользователям). +Вариант 2: внутренний журнал изменений Системы (аудит-лог), доступен только администраторам. +4.2.14. Функция «Ассистент "Зам"». +4.2.14.1. Модель ассистента (варианты). +Вариант 1 (рекомендуемый): AI-ассистент — программный агент на базе технологий искусственного интеллекта. Подключается к личному кабинету владельца; по командам владельца публикует информацию от его имени: заполняет карточку региона, загружает данные для рейтинга, выкладывает артефакты, создаёт задачи. Требования: +– ассистент действует в рамках прав владельца (не выше); +– все действия ассистента фиксируются в журнале и доступны владельцу; +– владелец может отключить ассистента или ограничить его действия (например, только публикация, без удаления); +– подключение — через настройки кабинета с подтверждением владельца. +Вариант 2: живой заместитель — отдельная роль «Заместитель» (человек). Владелец кабинета выдаёт заместителю права на публикацию информации от своего имени. Требования: +– назначение заместителя — владельцем кабинета или администратором; +– действия заместителя журналируются; +– владелец может отозвать права в любой момент. +4.3. Требования к видам обеспечения +4.3.1. Математическое обеспечение. +– алгоритм расчёта накопительного прироста от «точки 0»: прирост = значение текущего среза − значение точки 0; +– алгоритм определения динамики региона/округа (наличие положительного прироста за период); +– алгоритм расчёта вклада округа в общую цель (сумма приростов регионов округа); +– алгоритм определения «свежести» выгрузки (не старше 7 дней); +– (вариант) алгоритм комплексного рейтинга (п. 4.2.5.1, Вариант 2). +4.3.2. Информационное обеспечение. +– справочники: регионы (89), федеральные округа (8), роли пользователей, типы целей, типы рассылок, статусы задач, статусы запросов; +– данные целей: «точка 0» (дата и значение), текущий срез (дата и значение), история срезов; +– данные региональных отделений: карточка отделения, численность, члены, ссылки на сообщества и чаты; +– артефакты: файлы с метаданными (тип, размер, автор, дата, привязка); +– задачи: атрибуты и статусы; +– советы регионов: текст, автор, регион, цель, дата; +– журналы: действий пользователей, действий ассистента, рассылок. +4.3.3. Лингвистическое обеспечение. +– язык интерфейса — русский; +– единая терминология: «точка 0», «текущий срез», «прирост», «динамика», «красная зона», «вклад округа», «фокус целей»; +– тексты сообщений бота — в едином стиле, с персональными вставками (регион, ФИО, числа). +4.3.4. Программное обеспечение. +– серверная часть: API (REST), СУБД (реляционная), очередь сообщений для рассылок (при Варианте 2 п. 4.1.13.1); +– веб-клиент: адаптивная вёрстка (mobile-first), поддержка Chrome и Safari; +– бот: адаптеры Telegram Bot API и (вариант) MAX Bot API; +– (вариант) модуль AI-ассистента: интеграция с LLM-провайдером через API; +– состав конкретного ПО определяется на этапе технического проектирования. +4.3.5. Техническое обеспечение. +– серверное оборудование — в соответствии с выбранным вариантом масштаба (п. 4.1.13.1); +– требования к клиентским устройствам: смартфон с современным браузером, ПК — не ниже типовых офисных конфигураций; +– хостинг — на территории Российской Федерации. +4.3.6. Метрологическое обеспечение. +Система не выполняет измерительных функций; метрологическое обеспечение не требуется. +4.3.7. Организационное обеспечение. +– регламент выдачи одноразовых ссылок координаторами; +– регламент проведения рассылок; +– регламент загрузки и обновления выгрузок данных; +– должностные инструкции администратора и координатора. +4.3.8. Методическое обеспечение. +– методика работы руководителя регионального отделения с целями и рейтингами; +– методика формирования «Советов от регионов»; +– (вариант) методика работы с AI-ассистентом «Зам». +5. Состав и содержание работ по созданию системы +Таблица 4 — Состав и содержание работ по созданию системы +Этап (по ГОСТ 34.601-2020) +Содержание работ +Результат +1. Формирование требований +Обследование объекта автоматизации, анализ референсной платформы, утверждение ТЗ +Утверждённое ТЗ +2. Разработка концепции +Выбор варианта реализации (по пп. 4.1.13, 4.2), оценка стоимости +Концепция, план +3. Техническое задание +Настоящий документ +ТЗ +4. Эскизный проект +Архитектура, макеты экранов, прототип бота +Эскизный проект +5. Технический проект +Проектные решения по подсистемам, структура БД, API +Технический проект +6. Рабочая документация +Разработка ПО, вёрстка, настройка бота, документация +Рабочая документация, ПО +7. Ввод в действие +Подготовка данных, обучение, опытная эксплуатация, приёмка +Акт ввода в действие +8. Сопровождение +Исправление ошибок, развитие +Регламент сопровождения + +6. Порядок контроля и приемки системы +6.1. Виды испытаний: +– предварительные испытания — после завершения разработки, на тестовых данных; +– опытная эксплуатация — продолжительностью не менее 30 дней, на реальных данных (пилотные регионы); +– приёмочные испытания — после успешной опытной эксплуатации. +6.2. Приёмка осуществляется комиссией заказчика с участием разработчика. +6.3. Критерии приёмки: +– реализованы все функции, закреплённые в разделе 4 настоящего ТЗ (по выбранным вариантам); +– показатели назначения (п. 4.1.3) достигнуты; +– замечания опытной эксплуатации устранены; +– документация передана в соответствии с разделом 8. +6.4. Результаты испытаний оформляются актами по ГОСТ 34.603-2021. +7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие +– подготовка исходных данных: справочник регионов и округов, «точка 0» и стартовые срезы по целям, база членов Организации; +– регистрация бота в Telegram и (вариант) MAX, настройка домена (заполняется при утверждении ТЗ); +– назначение администраторов и координаторов; +– обучение персонала: администраторов, координаторов, руководителей региональных отделений (вебинары + инструкции); +– разработка регламентов (п. 4.3.7); +– план переноса данных из действующих учётных систем Организации (при наличии). +8. Требования к документированию +Состав документации: +– руководство пользователя (сайт); +– руководство пользователя (бот); +– руководство администратора; +– руководство координатора; +– регламент рассылок; +– регламент выгрузок данных; +– (вариант) руководство по работе с AI-ассистентом «Зам»; +– протоколы и акты испытаний. +Документация разрабатывается в соответствии с ГОСТ 19.201-78 и ГОСТ 34.201-2020. +9. Источники разработки +1. Описание заказчика (краткое описание платформы, назначение, сценарии использования). +2. Материалы обследования аналогичной действующей платформы (референс функциональности): скриншоты сайта `rmpred.ru` и бота `@pmpred_bot` (Приложение Б). +3. ГОСТ 34.601-2020 «Стадии создания автоматизированных систем». +4. ГОСТ 34.602-2020 «Техническое задание на создание автоматизированной системы». +5. ГОСТ 34.603-2021 «Виды испытаний автоматизированных систем». +6. ГОСТ 19.201-78 «Техническое задание. Требования к содержанию и оформлению». +7. ГОСТ 34.201-2020 «Виды, комплектность и обозначение документов при создании автоматизированных систем». +Приложение А. Описание бизнес-процессов (краткое) +А.1. Сценарий «Вход на сайт». +Пользователь открывает сайт → выбирает мессенджер (MAX/Telegram) → бот подтверждает вход по одноразовой ссылке → открывается личный кабинет. При повторном использовании ссылки — сообщение об ошибке и запрос новой ссылки у координатора. +А.2. Сценарий «Еженедельная рассылка». +Система формирует персональную сводку по каждому региону (прирост от точки 0, динамика округа, рекомендация) → отправляет через бота → кнопка «Открыть цели» ведёт на сайт. +А.3. Сценарий «Работа с целями». +Руководитель регионального отделения открывает раздел «Цели организации» → видит общую цель, вклад округов, топ регионов, красную зону, советы → при наличии динамики у отделения в боте появляется кнопка «Дать совет для других лидеров». +А.4. Сценарий «Ведение региона». +Руководитель отделения заполняет карточку регионального отделения (численность, ссылки на сообщества и чаты), добавляет членов, загружает артефакты, ведёт задачи. +А.5. Сценарий «Ассистент "Зам"» (по выбранному варианту п. 4.2.14). +Владелец подключает ассистента → ассистент публикует информацию от имени владельца → действия фиксируются в журнале. +Приложение Б. Состав экранов аналогичной действующей платформы (референс функциональности, по скриншотам) +Ниже приведён состав экранов аналогичной действующей платформы, использованной в качестве референса функциональности. Финальный состав экранов Системы уточняется на этапе эскизного проектирования. +Таблица Б.1 — Состав экранов референсной платформы +Экран +Содержимое +Вход +«Вход через рабочий бот», выбор MAX/Telegram, одноразовая ссылка, «Нет доступа? Начните регистрацию через бота» +Бот — приветствие +5 шагов: регистрация → заявка на интенсив → онлайн-обучение → Мурманск → защита проекта и грант +Бот — меню +Войти на сайт, Мои возможности, Регионы и пользователи, Цели сообщества, Регистрации МПР 2026, Помощь; команды /start /login /requests /regions /goals /mpr /help +Бот — рассылка +«Еженедельный фокус целей»: регион, прирост от 11.06.2026, динамика округа, «Что делать», кнопка «Открыть цели» +Бот — вход +«{ФИО}, вход выполнен!», «Сайт откроется автоматически», кнопка «Открыть сайт» +Сайт — меню +Главная, Цели сообщества, Календарь событий, Запросы, База знаний, Рейтинг регионов, История платформы, Выйти +Сайт — цели +Общая цель +1096, вклад округов +338, точка 0 / сейчас / цель, МПР 2026: прирост +2594, 89 регионов с динамикой +Сайт — динамика +Точка 0: 2026-05-08, срез: 2026-08-07, автообновление, накопительная динамика регистраций +Сайт — топ +Москва +224, Башкортостан +217, Санкт-Петербург +159, ДНР +136, Татарстан +132 +Сайт — красная зона +Регионы без прироста от точки 0, «все регионы дали прирост», полный список +Сайт — советы +«Советы от регионов», пустое состояние с подсказкой про кнопку в боте + +Приложение В. Сводная таблица вариантов решений +Таблица В.1 — Сводная таблица вариантов решений +№ +Вопрос +Вариант 1 (рекомендуемый) +Вариант 2 +1 +Ассистент «Зам» (п. 4.2.14) +AI-ассистент (программный агент) +Живой заместитель (роль-человек) +2 +Доступ к задачам (п. 4.2.9.1) +Все авторизованные члены +Только руководители отделений и администраторы +3 +Артефакты (п. 4.2.8.1) +Простая загрузка файлов +Медиатека с категориями и версиями +4 +Карточка региона (п. 4.2.6.1) +Только своё отделение (+админ — все) +Открытое редактирование +5 +Рассылки (п. 4.2.3.1) +Фиксированные шаблоны +Конструктор рассылок +6 +Рейтинг (п. 4.2.5.1) +По приросту от точки 0 +Комплексный (взвешенная формула) +7 +История платформы (п. 4.2.13.1) +Публичная лента новостей +Внутренний аудит-лог +8 +Мессенджеры (п. 4.1.13.2) +Telegram + MAX сразу +Сначала Telegram, MAX — этап 2 +9 +Масштаб (п. 4.1.13.1) +До 10 тыс. пользователей +До 100 тыс. пользователей +10 +Дизайн (п. 4.1.13.3) +По брендбуку «ОПОРА РОССИИ» +Новый дизайн-концепт с нуля + +Документ подготовлен как проект для согласования. Позиции, отмеченные как «Вариант 1 (рекомендуемый)», предлагаются к утверждению по умолчанию; заказчик вправе выбрать Вариант 2 по любому пункту. diff --git a/docs/ТЗ_ГОСТ_34.602-2020.docx b/docs/ТЗ_ГОСТ_34.602-2020.docx new file mode 100644 index 0000000..af801c8 Binary files /dev/null and b/docs/ТЗ_ГОСТ_34.602-2020.docx differ