125 lines
13 KiB
Markdown
125 lines
13 KiB
Markdown
# [DEF:EffortAssess:Report]
|
||
# @COMPLEXITY: 3
|
||
# @PURPOSE: Оценка трудозатрат для репозитория на основе эволюции требований в specs и изменений объёма по git-истории.
|
||
# @RELATION: DEPENDS_ON -> [Project_Knowledge_Map:Root]
|
||
# @RELATION: DEPENDS_ON -> [Module:Specs]
|
||
|
||
## Обзор
|
||
|
||
- Оценка трудозатрат по объёму, представленному в `specs/002`–`specs/027`: **~4 400 человеко-часов**.
|
||
- Рекомендуемый плановый диапазон: **3 800–5 100 человеко-часов**.
|
||
- Практическая форма поставки: **ядро команды 5–6 человек** примерно на **4–6 календарных месяцев**, в зависимости от степени параллелизации и объёма уже выполненной части.
|
||
|
||
## Размер кодовой базы (line of code)
|
||
|
||
По выводу `cloc backend/src frontend/src --exclude-dir=__pycache__,node_modules`:
|
||
|
||
| Язык | Файлов | Blank | Comment | Code |
|
||
|---|---:|---:|---:|---:|
|
||
| Python | 231 | 8 931 | 14 681 | 40 641 |
|
||
| Svelte | 97 | 2 191 | 1 333 | 26 798 |
|
||
| JavaScript | 77 | 1 321 | 1 909 | 7 852 |
|
||
| JSON | 3 | 0 | 0 | 3 473 |
|
||
| TypeScript | 8 | 30 | 137 | 194 |
|
||
| Markdown | 2 | 5 | 0 | 25 |
|
||
| HTML | 1 | 0 | 0 | 13 |
|
||
| CSS | 1 | 0 | 0 | 3 |
|
||
| SVG | 1 | 0 | 0 | 1 |
|
||
| **Итого** | **421** | **12 478** | **18 060** | **79 000** |
|
||
|
||
Это подтверждает, что оценка должна учитывать не только требования, но и уже значимый объём реализации в backend и frontend.
|
||
|
||
## Как получена оценка
|
||
|
||
Оценка опирается на три источника доказательств:
|
||
|
||
1. **Объём и сложность требований в `specs/`** — поздние спецификации заметно крупнее и сильнее завязаны на интеграции. Примеры: в `017-llm-analysis-plugin` 31 функциональное требование, в `025-clean-release-compliance` — 33, в `027-dataset-llm-orchestration` — 51.
|
||
2. **Хронологическая эволюция требований** — проект развивается от базовой настройки веб-интерфейса и исправления UI к консолидации платформы, затем к LLM-сценариям, отчётности, RBAC, enterprise-compliance и многосоставной оркестрации датасетов.
|
||
3. **История git, показывающая расширение объёма** — несколько коммитов фиксируют выход за рамки исходной постановки, особенно в части semantic-compliance, миграции на Svelte 5, hardening clean-release, test-contract enforcement и dataset-review.
|
||
|
||
## Эволюция требований (по времени)
|
||
|
||
| Период | Эволюция объёма | Доказательства | Сигнал по трудозатратам |
|
||
|---|---|---|---|
|
||
| Декабрь 2025 | Базовое веб-приложение: настройки, Svelte UI, глобальные стили, запуск, ранний UX задач | `specs/002-app-settings/spec.md`, `005-fix-ui-ws-validation/spec.md`, ранние коммиты `2d8cae5`, `9b7b743` | Умеренные трудозатраты на full-stack старт |
|
||
| Конец декабря 2025 — январь 2026 | UX миграции углубляется: история задач, логи, запросы пароля, backup/storage, миграция CLI→web, консолидация backend (`superset_tool` удалён), унификация frontend-дизайна и редизайн навигации | `specs/008`, `010`, `012`, `013`, `015` | Объём смещается от полировки UI к платформенному рефакторингу |
|
||
| Конец января — февраль 2026 | Продукт становится “intelligence-enabled”: валидация/документация LLM dashboard, постоянное логирование задач, унифицированные отчёты, assistant chat, восстановление cross-filter | `specs/017`, `018`, `020`, `021`, `022` | Высокая стоимость интеграции backend, frontend, async-задач, Superset и LLM-провайдеров |
|
||
| Март 2026 | Появляется enterprise- и governance-слой: clean enterprise delivery, фильтрация профиля пользователя, redesign для clean-release compliance, окна health для dashboard | `specs/023`, `024`, `025`, `026` | Добавляются release engineering, compliance evidence, RBAC, уведомления и policy-driven workflows |
|
||
| Середина марта 2026 и далее | Оркестрация датасетов становится самым сложным участком продукта: semantic enrichment, уточнения, preview gating, audited SQL Lab launch, совместная работа и сохранение сессий | `specs/027-dataset-llm-orchestration/spec.md` и `plan.md` | Самый рискованный orchestration-сценарий в репозитории |
|
||
|
||
## Релевантная git-история, показывающая изменение объёма
|
||
|
||
| Коммит | Что изменилось по объёму | Почему это важно для оценки |
|
||
|---|---|---|
|
||
| `8406628` | Clean-enterprise выделен в `023-clean-repo-enterprise` с 1 500+ строк новых spec-артефактов | Clean-enterprise стал отдельной программой, а не мелким дополнением |
|
||
| `de1f044` | Добавлены test contract annotations и tracking покрытия | QA/compliance вышли за пределы обычного feature testing |
|
||
| `36742cd` | Добавлен Docker admin bootstrap для clean release | Clean-release расширился до deployment/bootstrap операций |
|
||
| `0083d90` | Frontend переведён на Svelte 5 runes в 60+ файлах | Миграция платформы добавила стоимость репозитория на уровне фронтенда |
|
||
| `321e0eb` | Жёсткие tiers заменены на adaptive complexity semantics | Процессная и semantic-миграция создала сквозной объём документации и compliance |
|
||
| `023bacd` | Доставлена и принята автоматическая часть US1 для dataset-review | Подтверждает, что `027` — реальная ветка реализации, а не только спецификация |
|
||
| `ed3d5f3` | Добавлены clarification engine, preview adapter, batch approvals, RBAC sweep, i18n для `027` | Показывает, что dataset-review вырос в многофазную оркестрацию и hardening |
|
||
|
||
## Оценка трудозатрат по фазам
|
||
|
||
| Фаза | Включённый объём | Оценка часов |
|
||
|---|---|---:|
|
||
| Базовая платформа и миграция web | Specs `002`, `005`, `008`, `010`, `012`, `013`, `015` | 1 000 |
|
||
| Observability, LLM, отчётность, assistant, cross-filtering | Specs `017`, `018`, `020`, `021`, `022` | 1 450 |
|
||
| Enterprise clean release, compliance, фильтрация профиля, health windows | Specs `023`, `024`, `025`, `026` | 950 |
|
||
| Оркестрация датасетов и контролируемое исполнение | Spec `027` | 1 000 |
|
||
| **Итого** | | **4 400** |
|
||
|
||
## Оценка трудозатрат по направлениям
|
||
|
||
| Направление | Оценка часов |
|
||
|---|---:|
|
||
| Уточнение продукта/spec, архитектура, design review | 360 |
|
||
| Backend-сервисы, модели, API, persistence, task orchestration | 1 500 |
|
||
| Frontend-роуты, компоненты, состояние, UX-потоки, i18n | 1 050 |
|
||
| Внешние интеграции (Superset, Git, LLM-провайдеры, уведомления) | 650 |
|
||
| QA, contract testing, semantic/test compliance, regression hardening | 600 |
|
||
| DevOps / упаковка релизов / hardening деплоя | 240 |
|
||
| **Итого** | **4 400** |
|
||
|
||
## Рекомендуемый состав команды
|
||
|
||
| Роль | Рекомендуемая загрузка | Примечания |
|
||
|---|---|---|
|
||
| Техлид / архитектор | 0,5–1,0 FTE | Владеет cross-feature дизайном, semantic protocol и интеграционными решениями |
|
||
| Backend-инженеры | 2,0 FTE | Основные API, оркестрация, persistence, compliance, интеграции |
|
||
| Frontend-инженер | 1,0 FTE | Svelte/SvelteKit, task/report/assistant/dataset UX |
|
||
| Full-stack инженер | 1,0 FTE | Связывает API, storage, RBAC и end-to-end сценарии |
|
||
| QA / automation инженер | 1,0 FTE | Contract, API, UI, regression и release validation |
|
||
| DevOps / release инженер | 0,5 FTE | Offline bundle, Docker/bootstrap, deployment/compliance tooling |
|
||
| Product/UX/Data SME | 0,5 FTE | Clarification flows, LLM UX, enterprise acceptance decisions |
|
||
|
||
**Рекомендуемое ядро команды:** **5,5–7,0 FTE в смеси ролей**.
|
||
|
||
## Допущения
|
||
|
||
- Оценка покрывает объём, отражённый в текущей истории `specs/`, а не минимальный MVP.
|
||
- Существующие FastAPI/Svelte-архитектура, TaskManager, модель авторизации и интеграция с Superset считаются переиспользуемыми, а не переписываемыми с нуля.
|
||
- Зависимости LLM/провайдеров и Superset доступны для разработки и тестирования.
|
||
- Semantic-protocol и test-contract compliance считаются обязательной частью поставки, а не опциональной документацией.
|
||
- Часть функциональности уже реализована, но оценка отражает **полную трудоёмкость проекта, подразумеваемую объёмом репозитория**, включая rework и hardening, на которые указывает git-история.
|
||
|
||
## Доверие и риски
|
||
|
||
**Доверие:** среднее.
|
||
|
||
**Основные риски, влияющие на диапазон:**
|
||
|
||
1. **Спецификации описаны неравномерно**; поздние specs (`025`, `027`) заметно тяжелее ранних.
|
||
2. **Сквозная semantic/process-работа** существенна и не видна только по product-specs.
|
||
3. **Интеграционный риск** высок для Superset, LLM-провайдеров, Git-операций и async task/reporting surfaces.
|
||
4. **Объём enterprise-compliance расширялся в ходе реализации**, особенно для clean release и audit evidence.
|
||
5. **Оркестрация датасетов остаётся самой неопределённой частью**, потому что `027` объединяет LLM UX, сохранение сессий, provenance, preview gating и audited execution.
|
||
|
||
## Использованные источники
|
||
|
||
- Specs: `specs/002-app-settings/spec.md`, `005-fix-ui-ws-validation/spec.md`, `008-migration-ui-improvements/spec.md`, `010-refactor-cli-to-web/spec.md`, `012-remove-superset-tool/spec.md`, `013-unify-frontend-css/spec.md`, `015-frontend-nav-redesign/spec.md`, `017-llm-analysis-plugin/spec.md`, `018-task-logging-v2/spec.md`, `020-task-reports-design/spec.md`, `021-llm-project-assistant/spec.md`, `022-sync-id-cross-filters/spec.md`, `023-clean-repo-enterprise/spec.md`, `024-user-dashboard-filter/spec.md`, `025-clean-release-compliance/spec.md`, `026-dashboard-health-windows/spec.md`, `027-dataset-llm-orchestration/spec.md`.
|
||
- Plans: `specs/021-llm-project-assistant/plan.md`, `specs/025-clean-release-compliance/plan.md`, `specs/027-dataset-llm-orchestration/plan.md`.
|
||
- Git evidence: коммиты `8406628`, `de1f044`, `36742cd`, `0083d90`, `321e0eb`, `023bacd`, `ed3d5f3`, а также хронологический `git log --reverse -- specs`.
|
||
|
||
# [/DEF:EffortAssess:Report]
|