Fase 3 - Planificacio de l'Execucio (26h)

Objectiu de la fase

La Fase 3 correspon al RA3 - Planifica l'execucio del projecte. Partint del disseny elaborat a la Fase 2, l'alumnat ha de planificar detalladament l'execucio: seqüenciar les activitats, assignar recursos, identificar riscos, elaborar el diagrama de Gantt amb el cami critic i produir tota la documentacio d'execucio.

En 26 hores l'alumnat produeix el Pla d'Execucio del Projecte (o Project Plan), que es el document operatiu que guiaria un equip real durant la implementacio del sistema.

Resultats esperats al finalitzar la Fase 3:

Diagrama de Gantt professional amb cami critic identificat
Matriu de riscos amb pla de mitigacio per a riscos especifics de IA
Documentacio d'execucio completa (PRD final, ADRs, runbook)
Pla de gestio de permisos i autoritzacions
Valoracio economica de l'execucio per fases
Procediments d'execucio per a cada fase del projecte

Eines de planificacio

GitHub Projects

GitHub Projects es l'eina de planificacio integrada a GitHub, ideal per a projectes tecnologics. Permet gestionar milestones, issues i un board Kanban.

Configuracio recomanada per a un projecte IA:

Milestones (hitos principals):

v0.1 - Infraestructura base (setmana 2)
v0.2 - Data pipeline operatiu (setmana 4)
v0.3 - Model de baseline entrenat (setmana 6)
v0.4 - API en staging (setmana 8)
v0.5 - Monitoratge configurat (setmana 10)
v1.0 - Produccio i acceptacio (setmana 12)

Labels d'issues recomanats: - type: feature - Nova funcionalitat - type: bug - Correccion d'error - type: docs - Documentacio - type: experiment - Experiment de ML - priority: critical - Bloqueig del cami critic - priority: high - Important per al milestone - component: data - Relacionat amb dades - component: model - Relacionat amb el model - component: api - Relacionat amb l'API - component: infra - Relacionat amb infraestructura

Board Kanban per a projectes IA:

Backlog	In Analysis	In Progress	In Review	Done
Totes les tasques futures	En analisi detallada	En implementacio activa	En revisio o testing	Completades

Regles del board: - Maxim 3 tasques per persona a "In Progress" - Cada tasca a "In Review" ha de tenir un revisor assignat - Cap tasca passa a "Done" sense code review i tests passats

Jira - Scrum adaptat a projectes IA

Jira es l'eina estandard a les empreses per a la gestio de projectes. La metodologia Scrum es pot adaptar a projectes IA/ML:

Estructura de Scrum per a projectes IA:

Epic: Pipeline de dades
  Story: Connexio a les fonts de dades
    Task: Connector MySQL (4h)
    Task: Connector CSV/Excel (2h)
    Task: Tests unitaris (3h)
  Story: Validacio de qualitat de dades
    Task: Implementar Great Expectations (6h)
    Task: Configurar alertes (2h)

Epic: Model de ML
  Story: Analisi exploratori (EDA)
    Task: Estadistiques descriptives (4h)
    Task: Visualitzacio de distribucions (3h)
    Task: Informe EDA (2h)
  Story: Entrenament i avaluacio
    Task: Implementar baseline (3h)
    Task: Hiperparameter tuning (8h)
    Task: Avaluacio i metriques (4h)

Definicio de les cerimonies Scrum:

Ceremonia	Frequencia	Duracio	Objectiu
Sprint Planning	Inici de sprint (2 setmanes)	1h	Seleccionar i estimar tasques
Daily Standup	Cada dia	15 min	Que vaig fer? Que fare? Bloquejos?
Sprint Review	Fi de sprint	30 min	Demo del treball acabat
Retrospectiva	Fi de sprint	30 min	Que ha anat be/malament/millorem

Notion per a documentacio del projecte

Notion es excel·lent per a la documentacio de projectes IA:

Estructura recomanada a Notion:

Projecte [Nom]
├── Home (resum i links rapids)
├── Planificacio
│   ├── Gantt (embed de GanttProject/Smartsheet)
│   ├── Milestones
│   └── Meeting notes
├── Tecnologia
│   ├── Arquitectura
│   ├── ADRs (Architecture Decision Records)
│   └── Runbook
├── Dades
│   ├── Cataleg de dades
│   ├── Acords de comparticio (NDA, DPA)
│   └── Qualitat de dades
├── Model
│   ├── Experiments (link a MLflow)
│   ├── Metriques objectiu
│   └── Changelog del model
└── Recursos
    ├── Bibliogafia
    ├── Eines i llicencies
    └── Contactes

Diagrama de Gantt

El diagrama de Gantt es la representacio visual de la planificacio temporal del projecte. Es el document principal de la Fase 3.

Eines per crear el Gantt

Eina	Tipus	Cost	Avantatge principal
GanttProject	Desktop, open source	Gratuit	Capaç, exporta a PDF/PNG
ProjectLibre	Desktop, open source	Gratuit	Similar a MS Project
Smartsheet	SaaS	14 $/mes	Collaboratiu, integra amb GitHub
Monday.com	SaaS	9 $/mes/usuari	Interficie molt visual
MS Project	Desktop	500 €+	Estandard corporatiu
draw.io / Mermaid	Web/codi	Gratuit	Facil d'integrar a documentacio

Elements obligatoris del Gantt

Un diagrama de Gantt professional per a un projecte IA ha d'incloure:

Totes les tasques del WBS (nivel 2 o 3 del WBS com a activitats)
Durada estimada de cada tasca (en dies o hores)
Dependencies entre tasques (FS = Finish-to-Start, SS = Start-to-Start)
Assignacio de recursos (qui fa que)
Milestones (hitos clau - forma de diamant)
Cami critic (marcat en vermell o amb estil diferent)
Buffer de contingencia (temps reservat per a imprevistos)
Linia base (plan inicial per comparar amb l'execucio real)

Exemple de Gantt per a un sistema RAG (12 setmanes)

gantt
    title Sistema RAG - Gestio Documental (12 setmanes)
    dateFormat  YYYY-MM-DD
    axisFormat  Setmana %V
    section Infraestructura
    Configuracio Docker         :g1, 2025-10-06, 3d
    CI/CD GitHub Actions        :g2, after g1, 2d
    Entorn cloud AWS            :g3, after g1, 4d
    section Dades
    Recopilacio documents       :d1, 2025-10-06, 5d
    Preprocessament text        :d2, after d1, 4d
    Generacio embeddings        :d3, after d2, 3d
    section Model RAG
    Configuracio LLM            :m1, after g3, 3d
    Implementacio pipeline RAG  :m2, after m1, 5d
    Prompt engineering          :m3, after m2, 3d
    Avaluacio RAGAS             :m4, after m3, 3d
    section API i Interficie
    FastAPI backend             :a1, after m2, 4d
    Gradio frontend             :a2, after a1, 3d
    Autenticacio JWT            :a3, after a2, 2d
    section Monitoratge
    Prometheus i Grafana        :mo1, after a3, 3d
    Alertes i dashboards        :mo2, after mo1, 2d
    section Tancament
    Testing final               :t1, after mo2, 3d
    Documentacio final          :t2, after t1, 3d
    Revisio i entrega           :milestone, after t2, 0d

Identificacio del cami critic

El cami critic es la sequencia de tasques que determina la duracio minima del projecte. Qualsevol retard en una tasca del cami critic retarda el projecte sencer.

Com identificar el cami critic:

Calcula l'Early Start (ES) i Early Finish (EF) de cada tasca (forward pass)
Calcula el Late Start (LS) i Late Finish (LF) de cada tasca (backward pass)
Les tasques amb marge temporal (float) = 0 formen el cami critic

Exemple:

Tasca A (5d) → Tasca C (3d) → Tasca E (4d) = 12 dies
Tasca B (3d) → Tasca D (6d) ──────────────→ = 9 dies
Tasca A (5d) → Tasca D (6d) ──────────────→ = 11 dies

Cami critic: A → C → E (12 dies)
Float de Tasca D: 12 - 11 = 1 dia
Float de Tasca B: 12 - 9 = 3 dies

Implicacions practiques del cami critic: - Cal assignar els millors recursos a les tasques del cami critic - Cal monitoritzar diariament el progres de les tasques critiques - Qualsevol canvi de scope que afecti el cami critic ha de ser aprovat formalment - Es possible acurcar el projecte "crashing" el cami critic (afegint recursos)

Gestio de riscos especifics de projectes IA

La gestio de riscos en projectes IA te particularitats que no existeixen en projectes de software convencionals. La seguent taula presenta els riscos mes habituals amb la seva analisi i pla de mitigacio:

Matriu de riscos

#	Risc	Probabilitat	Impacte	Nivell	Estrategia	Accions de mitigacio
R01	Dades insuficients o de baixa qualitat	Alta	Crític	Molt Alt	Mitigar	Validar la qualitat de les dades (Great Expectations) abans de comencar. Tenir un pla de backfill.
R02	El model no assoleix les metriques objectiu	Mitjana	Alt	Alt	Mitigar	Definir un baseline senzill primer. Iterar amb Optuna. Tenir criteri clar de quan abandonar.
R03	Data drift en produccio	Baixa	Crític	Alt	Mitigar	Configurar Evidently AI per a deteccio automatica. Reentrenament programat.
R04	Canvis en els requisits del client	Alta	Mitjana	Alt	Acceptar	Sprints curts (2 setmanes). Gestio de canvis documentada. Scope statement signat.
R05	Fallada o canvi de preu de l'API externa (OpenAI)	Baixa	Alt	Mitja	Mitigar	Arquitectura multi-proveidor. Capa d'abstraccio LiteLLM.
R06	Restriccions RGPD/AI Act	Baixa	Crític	Alt	Evitar	Analisi legal previa. Privacy by Design. DPO involucrat des del principi.
R07	Costos cloud superiors als previstos	Mitjana	Mitjana	Mitja	Mitigar	Budget alerts a AWS/GCP. FinOps: spot instances, auto-scaling off-peak.
R08	Retard en l'acces a les dades del client	Alta	Alt	Molt Alt	Mitigar	Iniciar els tràmits d'acces el primer dia. Tenir dades sintetiques com a backup.
R09	Dependencia tecnica d'un unic membre de l'equip	Baixa	Alt	Mitja	Mitigar	Documentacio de tots els processos. Pair programming per a components critic.
R10	Degradacio de la qualitat del LLM (model extern)	Baixa	Mitja	Baixa	Acceptar	Pinning de la versio del model. Monitoratge de la qualitat de les respostes.

Matriu probabilitat × impacte

         Impacte
         Baix    Mitja   Alt     Critic
Alta  |   Mitja  | Alt  | MOlt  | MOlt  |
      |          |      | Alt   | Alt   |
Mitja |   Baix   | Mitja| Alt   | Molt  |
      |          |      |       | Alt   |
Baixa |   Baix   | Baix | Mitja | Alt   |

Nivells: Baix (monitorar), Mitja (accions preventives), Alt (pla de mitigacio), Molt Alt (escalar immediatament)

Permisos i autoritzacions

Drets sobre les dades

En projectes IA, l'acces a les dades es sovint el principal bloqueig legal. Cal gestionar:

Acord de Processament de Dades (DPA - Data Processing Agreement): Document obligatori si el projecte processa dades personals per compte del client (article 28 RGPD): - Objecte i duracio del tractament - Naturalesa i finalitat del tractament - Tipus de dades personals tractades - Obligacions del processador (confidencialitat, seguretat, subcontractes) - Drets del responsable: auditoria, instruccions per escrit

Data Sharing Agreement: Quan les dades provenen d'una tercera part (no del client directe): - Quines dades es comparteixen i per a quina finalitat - Limitacions d'us (no es poden usar per a altres projectes) - Mesures de seguretat exigides - Procediment en cas de bretxa de seguretat

Base legal per al tractament de dades (RGPD)

El tractament de dades ha de tenir una base legal (art. 6 RGPD):

Base legal	Quan usar-la	Exemple
Consentiment	Quan l'usuari el pot revocar lliurement	Analisi de comportament d'usuaris d'app
Contracte	Quan es necessari per executar un contracte	Recomanador de productes per a clients
Interes legitimate	Quan el benefici supera el risc	Deteccio de frau intern
Obligacio legal	Quan ho exigeix una norma	Conservacio de registres fiscals

NDA (Acord de No Divulgacio)

L'NDA protegeix la informacio confidencial del client. Elements obligatoris: - Definicio de la informacio confidencial - Obligacions de les parts (no divulgar, no usar per a altres finalitats) - Excepcions (informacio publica, obtinguda d'altres fonts) - Duracio de la confidencialitat (tipicament 3-5 anys) - Jurisdiccio i llei aplicable

Autoritzacio per a prova de sistemes (pentest/penetration testing)

Si el projecte inclou proves de seguretat sobre sistemes del client: - Carta d'autoritzacio signada per la direccio del client - Abast exacte de les proves (IPs, sistemes, tipus d'atac) - Finestra temporal (dates i horaris autoritzats) - Contactes en cas d'incident durant les proves - Compromes de confidencialitat sobre les vulnerabilitats trobades

Documentacio d'execucio

PRD - Product Requirements Document

El PRD es el document central de la fase de disseny i execucio. Conte tots els requisits del producte d'una manera que qualsevol membre de l'equip pugui entendre:

Estructura d'un PRD per a un sistema IA:

PRD: [Nom del Sistema]
Versio: 1.0 | Data: [data] | Autor: [nom] | Estat: Aprovat

1. CONTEXT I OBJECTIU
   1.1. Problema que resolem
   1.2. Proposta de valor
   1.3. Metriques d'exit (KPIs)
   1.4. Fora d'abast

2. USUARIS I CASOS D'US
   2.1. Perfils d'usuari (personas)
   2.2. User stories (taula)
   2.3. Fluxos principals (diagrames)

3. REQUISITS FUNCIONALS
   Cada RF amb: ID, descripcio, prioritat (Must/Should/Could/Won't)

4. REQUISITS NO FUNCIONALS
   Rendiment, seguretat, disponibilitat, escalabilitat

5. ARQUITECTURA PROPOSADA
   Diagrama d'arquitectura, components, integracions

6. CRITERIS D'ACCEPTACIO
   Per a cada historia, la definicio de done

7. DEPENDENCIES I RISCOS
   Dependencies externes, riscos principals

8. PLA D'IMPLEMENTACIO
   Fases, milestones, equip

9. PREGUNTES OBERTES
   Decisions pendents, amb data de resolucio

ADR - Architecture Decision Records

Els ADRs documenten les decisions d'arquitectura importants. Format estandard (MADR - Markdown Architecture Decision Records):

# ADR-001: Seleccio de la base de dades vectorial

Data: 2025-10-15
Estat: Acceptat
Decisors: [noms]

## Contexte
El sistema RAG necessita emmagatzemar i cercar embeddings de documents.
Hem d'escollir entre Chroma, Qdrant, Weaviate i Pinecone.

## Decisio
Usem Qdrant.

## Justificacio
- Chroma: massa limitat per a escala de produccio (>1M vectors)
- Pinecone: cost elevat (70€+/mes) per al volum previst
- Weaviate: massa complex de configurar per al cas d'us
- Qdrant: equilibri entre rendiment, cost (open source + cloud) i facilitat

## Consequencies
- Positives: rendiment excel·lent, API REST neta, filtratge per metadades
- Negatives: cal gestionar la infraestructura (si on-premise)
- Riscos: empresa petita (menys ecosistema que Pinecone)

## Alternatives considerades
Detall comparatiu: [taula o link]

Runbook - Manual d'operacio

El runbook es el manual que permet a l'equip d'operacions (o a qualsevol persona) gestionar el sistema en produccio. Ha d'incloure:

Estructura d'un runbook per a una API de ML:

RUNBOOK: [Nom del Sistema] v1.0

1. ARQUITECTURA DE PRODUCCIO
   - Diagrama de components
   - URLs de produccio i staging
   - Credencials (link al gestor de secrets, MAI en text pla)

2. DESPLEGAMENT
   - Com desplegar una nova versio
   - Com fer rollback
   - Checklist pre-desplegament

3. OPERACIO DIARIA
   - Com comprovar que el sistema esta operatiu
   - Dashboards de monitoratge (links a Grafana)
   - Alertes actives i procediment de resposta

4. INCIDENTS FREQUENTS
   - Error: "Model not responding" → Procediment de recuperacio
   - Error: "Out of memory" → Com reiniciar el servei
   - Alert: "High latency" → Com investigar i resoldre

5. BACKUP I RECUPERACIO
   - Frequencia de backup de la BD vectorial
   - Procediment de restauracio
   - RTO (Recovery Time Objective) i RPO (Recovery Point Objective)

6. CONTACTES
   - Responsable tecnic: [nom, email, telefon]
   - Responsable del client: [nom, email, telefon]
   - Suport cloud: [ticket URL]

Changelog

El changelog documenta tots els canvis en el sistema. Format recomanat (seguint Conventional Commits):

# Changelog - Sistema RAG v1.0

## [Unreleased]

## [1.0.0] - 2025-12-01
### Afegit
- Sistema de control d'acces per rol (RBAC)
- Dashboard de monitoratge a Grafana

### Canviat
- Actualitzat Llama 3 de 8B a 70B per a millor qualitat
- Millorat el chunking de documents (800→400 tokens amb overlap)

### Corregit
- Corregit bug en el filtrat de permisos per departament
- Corregit problema de memoria amb documents >100 pagines

## [0.5.0] - 2025-11-15
### Afegit
- Primera versio funcional del pipeline RAG
- Interficie Gradio basica
- Tests unitaris del pipeline (cobertura 78%)

Guio del document de planificacio

Index recomanat

1. Portada i control de versions

2. Resum executiu de la planificacio (max. 2 pagines)
   - Visio general del projecte
   - Calendari resum (dates clau)
   - Pressupost total
   - Riscos principals

3. Sequencia d'activitats
   3.1. Llista d'activitats amb estimacio
   3.2. Dependencies entre activitats
   3.3. Hitos (milestones)

4. Diagrama de Gantt
   4.1. Gantt completa (imatge o embed)
   4.2. Cami critic identificat i justificat
   4.3. Recursos assignats per activitat

5. Gestio de riscos
   5.1. Metodologia d'analisi de riscos
   5.2. Matriu de riscos (probabilitat × impacte)
   5.3. Fitxes de risc per als riscos d'Alt i Molt Alt
   5.4. Pla de contingencia general

6. Permisos i autoritzacions
   6.1. Permisos necessaris (llista)
   6.2. Pla d'obtencio (responsable, data)
   6.3. Impacte si no s'obtenen a temps

7. Procediments d'execucio
   7.1. Procediment d'ingesta de dades
   7.2. Procediment d'entrenament i avaluacio
   7.3. Procediment de desplegament (CI/CD)
   7.4. Procediment de rollback

8. Valoracio economica
   8.1. Costos per fase
   8.2. Facturacio i hitos de pagament
   8.3. Control pressupostari

9. Documentacio d'execucio
   9.1. PRD (o link)
   9.2. ADRs principals
   9.3. Runbook (esborrany)

10. Conclusions i proxims passos

Annexos:
   A. Gantt detallada (format original)
   B. Fitxes de risc completes
   C. Templates de documentacio

Rubrica de la Fase 3

Criteri	Pes	Excel·lent (9-10)	Notable (7-8)	Aprovat (5-6)	Insuficient (<5)
Gantt i cami critic (CA3.1-CA3.2-CA3.6)	35%	Gantt professional amb totes les tasques del WBS, dependencies, recursos i cami critic identificat. Milestones definits.	Gantt correcte amb dependencies i recursos. Cami critic identificat.	Gantt basic amb tasques principals. Algunes dependencies.	Gantt absent o molt incomplet. Sense dependencies.
Gestio de riscos (CA3.5)	25%	Matriu de riscos completa (min. 8 riscos especifics IA). Fitxes de risc per als d'alt nivell. Pla de contingencia.	Riscos identificats i categoritzats. Principals mitigaciones definides.	Alguns riscos identificats. Mitigaciones generiques.	Sense analisi de riscos o molt generica.
Permisos i procediments (CA3.3-CA3.4)	20%	Permisos identificats amb pla d'obtencio. Procediments detallats per a totes les fases.	Principals permisos identificats. Procediments clars.	Permisos basics. Procediments generals.	Permisos i procediments absents.
Documentacio execucio (CA3.7-CA3.8)	20%	PRD complet, ADRs per a decisions clau, runbook operatiu, changelog configurat.	Principals documents presents i correctes.	Documents basics presents.	Documentacio absent o molt deficient.

Consells per a la Fase 3

Gantt realista: Afegeix un 20-30% de buffer a les estimacions inicials. Els projectes IA sempre tarden mes del previst per problemes amb les dades.
Riscos especifics: No copies riscos generics (retard, malaltia). Identifica riscos reals del teu projecte: "les dades del client no compleixen la qualitat minima", "el model de GPT-4 canvia de preu", etc.
Cami critic documentat: Has d'explicar PER QUE les tasques del cami critic son critiques, no nomes marcar-les al diagrama.
Permisos aviat: En un projecte real, els acords legals (NDA, DPA) poden tardar setmanes. Inclou-los al Gantt com a tasca prioritaria.

Errors freqüents de la Fase 3

Gantt amb tasques sense dependencia: totes les tasques comencen el dia 1
Riscos generics: "retard en el projecte", "problemes tecnics" sense especificar
No identificar el cami critic o identificar-lo incorrectament
ADRs buids o sense justificacio de les decisions
No calcular el cami critic i simplement dir "totes les tasques son critiques"
Runbook sense els procediments d'incidents mes habituals