Fase 2 - Disseny del Projecte (26h)
Objectiu de la fase
La Fase 2 correspon al RA2 - Dissenya el projecte. Partint de la necessitat identificada a la Fase 1, l'alumnat ha de dissenyar una solucio tecnica completa, definir l'arquitectura, establir objectius SMART, elaborar el pressupost i definir el pla de qualitat.
En 26 hores l'alumnat produeix el Document de Disseny del Projecte, que inclou tots els elements necessaris per demostrar que la solucio es viable, esta ben pensada i pot ser executada per un equip professional.
Resultats esperats al finalitzar la Fase 2:
- Document de requisits (PRD) complet i ben estructurat
- Estudi de viabilitat tecnica documentat
- WBS (Work Breakdown Structure) amb 3 nivells de descomposicio
- Objectius SMART per al projecte
- Pressupost desglossat per partides (personal, infraestructura, llicencies)
- Pla de qualitat amb metriques i SLAs
- Diagrama d'arquitectura del sistema
Recollida de requisits per a projectes IA
User Stories
Les User Stories son la manera mes agil d'expressar els requisits del sistema des de la perspectiva dels usuaris. Format estandard:
Com a [rol d'usuari], vull [accio o funcionalitat] per tal de [benefici o objectiu].
Exemples per a un sistema RAG de gestio documental:
| # | User Story | Criteri d'acceptacio |
|---|---|---|
| US-01 | Com a empleat, vull fer preguntes en llengua natural sobre el manual intern per tal d'obtenir respostes precises sense llegir tot el document | El sistema respon en < 3 segons amb la resposta i la font citada |
| US-02 | Com a responsable de RRHH, vull que el sistema processi nous documents automàticament per tal de mantenir la base de coneixement actualitzada | Nous documents indexats en < 5 minuts |
| US-03 | Com a administrador, vull gestionar els permisos d'acces per departament per tal de garantir la confidencialitat | Les respostes nomes mostren informacio accessible al rol de l'usuari |
| US-04 | Com a directiu, vull un historial de les consultes mes frequents per tal de identificar lacunes de coneixement | Dashboard amb top 20 preguntes setmanalment |
Exemples per a un pipeline ML de prevision de demanda:
| # | User Story | Criteri d'acceptacio |
|---|---|---|
| US-01 | Com a responsable de compres, vull previsions de demanda a 4 setmanes per tal de planificar els estocs | Previsions amb MAE < 8% respecte a la demanda real |
| US-02 | Com a Data Scientist, vull reentrenar el model automàticament cada setmana per tal de mantenir la qualitat | Pipeline automatitzat amb MLflow que reentrana si el MAE > 12% |
| US-03 | Com a tecnics d'IT, vull monitoritzar el rendiment de l'API per tal de detectar problemes de produccio | Grafana dashboard amb latencia, error rate i throughput en temps real |
Casos d'us
Els casos d'us complementen les user stories amb una descripcio mes detallada del flux d'interaccio:
Cas d'us: Consulta al sistema RAG
Nom: Consulta de document
Actor principal: Empleat
Precondicions: Empleat autenticat. Documents indexats al sistema.
Flux principal:
1. L'empleat escriu la pregunta en el xat
2. El sistema vectoritza la pregunta
3. El sistema cerca els fragments mes rellevants (top-k=5)
4. El LLM genera una resposta basada en els fragments
5. El sistema mostra la resposta i les fonts citades
6. L'empleat valora la resposta (polze amunt/avall)
Flux alternatiu:
3a. Cap fragment supera el llindar de similitud (0.75):
3a.1. El sistema respon "No he trobat informacio sobre aquest tema"
3a.2. Suggereix reformular la pregunta
Postcondicions: Resposta enregistrada al log d'interaccions
Criteris d'acceptacio (Definition of Done per a IA)
La Definition of Done per a un model o sistema d'IA ha de cobrir:
Qualitat del model: - [ ] Metriques de test superiors al llindar definit (ex: accuracy > 85%, F1 > 0.80) - [ ] Matriu de confusio revisada i sense biaixos greus per subgrups - [ ] Model explicable: SHAP values calculades per a les 10 features principals - [ ] Tests de regressio: el nou model no es pitjor que l'anterior
Qualitat del codi: - [ ] Pull request revisat per un company (code review) - [ ] Tests unitaris i d'integracio passats (cobertura > 80%) - [ ] Documentacio del codi (docstrings, README) - [ ] Linting: sense errors de flake8/pylint
Qualitat del desplegament: - [ ] Docker image construida i publicada al registry - [ ] API REST documentada amb Swagger/OpenAPI - [ ] Health check endpoint funcionant (/healthz) - [ ] Monitoratge configurat (Prometheus metrics, alertes Grafana) - [ ] Rollback plan documentat i provat
Requisits no funcionals
| Requisit | Metrica | Valor objectiu | Mesura |
|---|---|---|---|
| Latencia d'inferencia | p50 / p99 | < 200ms / < 500ms | Prometheus histogram |
| Throughput | Requests per segon | > 100 rps | k6 load test |
| Disponibilitat | Uptime | > 99.5% (22h/any) | Blackbox exporter |
| Escalabilitat | Tiempo resposta sota 10x carrega | < 2x latencia | Kubernetes HPA |
| Seguretat | Vulnerabilitats crítiques | 0 | OWASP ZAP, Trivy |
| Cost operatiu | Cost mensual cloud | < [valor definit] € | AWS Cost Explorer |
Estudi de viabilitat tecnica
Com seleccionar el stack tecnologic
La seleccio del stack tecnologic ha d'estar justificada amb criteris objectius. No s'ha de triar la tecnologia que simplement "es coneix millor", sino la mes adequada per al cas d'us.
Criteris de seleccio:
| Criteri | Pes | Questions a respondre |
|---|---|---|
| Adequacio tecnica | 30% | Resol el problema tecnic concret? Te les funcionalitats necessaries? |
| Maduresa i comunitat | 20% | Quants anys porta en produccio? Quina activitat te a GitHub? |
| Cost (TCO) | 20% | Llicencia gratuita? Costos d'operacio? Estalvi vs alternativa? |
| Facilitat d'operacio | 15% | Infraestructura necesaria? Equip format? Corba d'aprenentatge? |
| Escalabilitat | 15% | Pot creixer amb la demanda? Limitacions de volum de dades? |
Comparativa de tecnologies per tipus de projecte
Opcions per a LLMs i sistemes RAG:
| Eina | Tipus | Avantatge | Desavantatge | Cost |
|---|---|---|---|---|
| OpenAI API (GPT-4o) | SaaS | Millor qualitat, facil | Cost per token, privacitat | 0,005-0,015 $/1K tokens |
| Ollama + Llama 3 | Local | Privacitat, sense cost API | Requereix GPU, qualitat inferior | Hardware (GPU) |
| Anthropic Claude API | SaaS | Raonament excel·lent, context llarg | Cost, dependencia externa | 0,003-0,015 $/1K tokens |
| vLLM + model propi | On-premise | Control total, privacitat | Complex d'operar, cost GPU | Infraestructura |
Opcions per a bases de dades vectorials:
| Eina | Tipus | Escala | Cost | Millor per a |
|---|---|---|---|---|
| Chroma | Open source | Petita-mitjana | Gratuit | Prototips, projectes petits |
| Qdrant | Open source / Cloud | Mitjana-gran | Gratuit / 25€+ mes | Projectes en produccio |
| Weaviate | Open source / Cloud | Gran | Gratuit / 25€+ mes | Multimodal (text+imatge) |
| Pinecone | SaaS | Molt gran | 70€+ mes | Empreses amb molt volum |
Diagrames d'arquitectura
Arquitectura de referencia - Sistema RAG:
[Usuari] → [Interficie Gradio/Streamlit]
↓
[FastAPI Backend]
/ \
[LLM (Ollama)] [Vector DB (Chroma)]
↑
[Indexer Pipeline]
↑
[Documents (PDF, DOCX, MD)]
Arquitectura de referencia - Pipeline ML:
[Dades brutes] → [Ingesta (Airflow)] → [Data Lake (S3/MinIO)]
↓
[Preprocessament (Spark)]
↓
[Entrenament (scikit-learn/XGBoost)]
↓
[MLflow Experiment Tracking]
↓
[Model Registry (MLflow / Hugging Face)]
↓
[Serving API (FastAPI + Docker)]
↓
[Monitoratge (Grafana + Evidently AI)]
Infraestructura: cloud vs on-premise vs hibrid
Cloud public (AWS, GCP, Azure): - Avantatges: escalabilitat instantania, sense inversio inicial, manteniment externalitzat, serveis gestionats (SageMaker, Vertex AI, Azure ML) - Desavantatges: cost variable i impredictible, dependencia del proveidor (vendor lock-in), latencia per a IoT, privacitat de dades sensibles - Millor per a: startups, projeces amb demanda variable, prototips
On-premise (servidors propis): - Avantatges: control total de les dades, cost predictible a llarg termini, baix latencia per a sistemes industrials - Desavantatges: inversio inicial alta (servers GPU), manteniment propi, escalabilitat limitada - Millor per a: dades molt sensibles (salut, defensa), volums molt grans amb acces frequent
Arquitectura hibrida: - Dades sensibles: on-premise - Entrenament esporadico de models: cloud (spot instances) - Serving de models: cloud (auto-scaling) - Millor per a: empreses amb regulacio estricta pero que volen escalabilitat
Calculadora de costos cloud (AWS, 2025)
Exemple de pressupost mensual per a un sistema RAG en AWS:
| Servei | Configuracio | Preu/mes |
|---|---|---|
| EC2 (serving) | t3.xlarge (4 vCPU, 16 GB RAM) | 120 € |
| EC2 (embedding) | g4dn.xlarge (GPU T4) | 380 € |
| S3 (documents) | 100 GB + requests | 25 € |
| OpenSearch (vectors) | t3.medium.search | 85 € |
| RDS PostgreSQL | db.t3.medium | 65 € |
| CloudFront (CDN) | 100 GB transfer | 15 € |
| CloudWatch | Logs + metriques | 20 € |
| Total estimat | 710 €/mes |
Per a optimitzar costos: - Usar spot instances per a entrenament: estalvi 60-70% - Reserved instances (1 any) per a serving: estalvi 40% - S3 Intelligent Tiering per a dades poc accedides: estalvi 30-50% - Auto-scaling per evitar pagar capacitat no usada
WBS (Work Breakdown Structure)
El WBS descompon el projecte en elements gestionables. Es recomana un maxim de 3 nivells de profunditat per a projectes d'aquesta envergadura.
WBS per a un sistema RAG
1. SISTEMA RAG GESTIO DOCUMENTAL
1.1. Gestio del projecte
1.1.1. Reunions setmanals d'equip
1.1.2. Seguiment del Gantt
1.1.3. Documentacio
1.2. Infraestructura i entorn
1.2.1. Configuracio Docker Compose
1.2.2. Configuracio servidor / cloud
1.2.3. Pipeline CI/CD (GitHub Actions)
1.3. Processament de documents
1.3.1. Ingesta i conversio de formats (PDF, DOCX, MD)
1.3.2. Chunking i preprocessament de text
1.3.3. Generacio d'embeddings
1.3.4. Indexat a la base de dades vectorial
1.4. Motor de cerca i recuperacio
1.4.1. Cerca per similitud cosinus (top-k)
1.4.2. Reranking dels fragments recuperats
1.4.3. Filtratge per metadades i permisos
1.5. Integracio amb LLM
1.5.1. Prompt engineering i templates
1.5.2. Gestio del context i la conversa
1.5.3. Citacio de fonts
1.6. Interficie d'usuari
1.6.1. Xat (Gradio / Streamlit)
1.6.2. Gestio de sessions d'usuari
1.6.3. Panell d'administracio
1.7. Monitoratge i qualitat
1.7.1. Logging d'interaccions
1.7.2. Dashboard de metriques (Grafana)
1.7.3. Avaluacio periodica de la qualitat RAG
1.8. Seguretat
1.8.1. Autenticacio (OAuth2 / JWT)
1.8.2. Autoritzacio per rol (RBAC)
1.8.3. Auditoria d'acces
WBS per a un pipeline ML en produccio
1. PIPELINE ML EN PRODUCCIO
1.1. Gestio del projecte
1.1.1. Planificacio i Gantt
1.1.2. Documentacio
1.2. Ingesta i qualitat de dades
1.2.1. Connectors de fonts de dades
1.2.2. Validacio de qualitat (Great Expectations)
1.2.3. Versionat de datasets (DVC)
1.3. Preprocessament i feature engineering
1.3.1. Neteja de dades
1.3.2. Transformacions i encoding
1.3.3. Feature store (Feast / Hopsworks)
1.4. Experimentacio i entrenament
1.4.1. Analisi exploratori (EDA)
1.4.2. Seleccio d'algorismes i baseline
1.4.3. Hiperparameter tuning (Optuna)
1.4.4. Tracking d'experiments (MLflow)
1.5. Avaluacio i seleccio del model
1.5.1. Metriques de rendiment
1.5.2. Tests de biaix i fairness
1.5.3. Explicabilitat (SHAP)
1.6. Desplegament
1.6.1. Packaging (Docker)
1.6.2. API REST (FastAPI)
1.6.3. CI/CD pipeline (GitHub Actions)
1.6.4. Model registry (MLflow)
1.7. Monitoratge en produccio
1.7.1. Metriques d'API (Prometheus)
1.7.2. Data drift (Evidently AI)
1.7.3. Alertes i notificacions
Objectius SMART aplicats a projectes IA
Els objectius SMART son una eina fonamental per definir clarament que s'espera aconseguir amb el projecte. Cada lletra te un significat concret:
S - Especific (Specific): L'objectiu ha de ser concret i clar, no ambigu. - Malament: "El sistema ha de funcionar be" - Be: "El model de classificacio ha de categoritzar els tickets de suport en 5 categories (tecnic, facturacio, enviament, devolucio, consulta general)"
M - Mesurable (Measurable): Ha d'haver-hi una metrica que permeti saber si s'ha assolit. - Malament: "El model ha de ser molt precis" - Be: "El model ha d'assolir un F1-score > 0.82 en el conjunt de test"
A - Assolible (Achievable): L'objectiu ha de ser realista amb els recursos disponibles. - Malament: "El model ha de tenir accuracy > 99%" - Be: "El model ha d'assolir accuracy > 88% (el benchmak del sector es 85%)"
R - Rellevant (Relevant): L'objectiu ha d'estar alineat amb el cas de negoci. - Malament: "El sistema ha de tenir un dashboard molt complet" - Be: "El sistema ha de reduir el temps de resposta als tickets de suport de 4 hores a < 1 hora"
T - Temporal (Time-bound): L'objectiu ha de tenir un termini definit. - Malament: "El model ha d'estar llest aviat" - Be: "El model ha d'estar en produccio el 15 de novembre de 2025"
Exemples d'objectius SMART per tipologia
Tipologia 1 - Sistema RAG: - O1 (S,M,A,R,T): "El sistema RAG ha de respondre el 80% de les preguntes de validacio amb resposta correcta (RAGAS faithfulness > 0.8) i en menys de 3 segons, en produccio el 10/11/2025" - O2: "El sistema ha de processar i indexar 10.000 pagines de documents PDF en menys de 30 minuts" - O3: "El codi ha de tenir una cobertura de tests > 75% i passar el pipeline CI/CD"
Tipologia 2 - Pipeline ML: - O1: "El model de prevision de demanda ha d'assolir un MAPE < 8% en el conjunt de test de les ultimes 8 setmanes" - O2: "El pipeline de reentrenament ha d'executar-se automàticament cada diumenge i registrar els resultats a MLflow" - O3: "L'API de serving ha de tenir una disponibilitat > 99.5% i latencia p99 < 500ms"
Pressupost detallat
Estructura del pressupost
El pressupost del projecte ha d'incloure totes les partides de cost. Format recomanat:
1. Personal (la partida mes important, normalment 60-70% del total)
| Perfil | Hores | Tarifa (€/h) | Total |
|---|---|---|---|
| ML Engineer (lider tecnic) | 200h | 65 €/h | 13.000 € |
| Data Engineer | 120h | 55 €/h | 6.600 € |
| DevOps / MLOps | 80h | 60 €/h | 4.800 € |
| UX/UI Designer | 40h | 45 €/h | 1.800 € |
| Project Manager | 60h | 55 €/h | 3.300 € |
| Subtotal Personal | 500h | 29.500 € |
Tarifes de mercat 2025 (consultoria IA, Espanya): - Junior (0-2 anys): 35-45 €/h - Mid (2-5 anys): 45-65 €/h - Senior (5+ anys): 65-90 €/h - Lead / Arquitecte: 90-120 €/h
2. Infraestructura i serveis cloud
| Servei | Duracio | Cost mensual | Total |
|---|---|---|---|
| Entorn de desenvolupament (AWS EC2) | 3 mesos | 250 €/mes | 750 € |
| Entorn de produccio (AWS EKS) | 6 mesos | 800 €/mes | 4.800 € |
| Emmagatzematge (S3 + RDS) | 6 mesos | 120 €/mes | 720 € |
| Serveis gestionats (SageMaker) | 2 mesos | 400 €/mes | 800 € |
| OpenAI API (prototip + prod) | 6 mesos | 150 €/mes | 900 € |
| Subtotal Infraestructura | 7.970 € |
3. Llicencies de software
| Eina | Llicencia | Cost anual |
|---|---|---|
| GitHub Teams | SaaS | 84 € |
| Notion Team | SaaS | 96 € |
| Smartsheet | SaaS | 300 € |
| Cursor / Copilot (x2) | SaaS | 240 € |
| Subtotal Llicencies | 720 € |
4. Formacio i documentacio
| Concepte | Cost |
|---|---|
| Cursos especifics (Udemy, Coursera) | 300 € |
| Llibres tecnics | 150 € |
| Certificacio AWS/GCP (si escau) | 350 € |
| Subtotal Formacio | 800 € |
5. Resum i contingencies
| Partida | Import |
|---|---|
| Personal | 29.500 € |
| Infraestructura | 7.970 € |
| Llicencies | 720 € |
| Formacio | 800 € |
| Subtotal | 38.990 € |
| Contingencies (15%) | 5.849 € |
| TOTAL PROJECTE | 44.839 € |
Nota: Les contingencies del 15-20% son imprescindibles en projectes IA/Big Data per cobrir imprevistos com: necessitat de mes dades d'entrenament, reentrenament del model, retards en l'obtencio de permisos d'acces a dades o canvis en els requisits del client.
Control de qualitat
Metriques de qualitat del model
Depenent del tipus de model, les metriques principals son:
Models de classificacio:
| Metrica | Formula | Quan usar-la |
|---|---|---|
| Accuracy | TP+TN / Total | Classes equilibrades |
| Precision | TP / (TP+FP) | Minimitzar falsos positius (spam, frau) |
| Recall | TP / (TP+FN) | Minimitzar falsos negatius (cancer, frau) |
| F1-Score | 2 × (P×R)/(P+R) | Classes desequilibrades |
| AUC-ROC | Area sota la corba ROC | Comparar models |
| MCC | Matthews Correlation | Dataset molt desequilibrat |
Models de regressio:
| Metrica | Descripcion | Interpretacio |
|---|---|---|
| MAE | Error absolut mitja | En unitats de la variable objectiu |
| RMSE | Arrel de l'error quadratic mitja | Penalitza errors grans |
| MAPE | Error percentual absolut mitja | Interpretable com a % |
| R² | Coeficient de determinacio | 1 = perfect, 0 = inutil |
Models de generacio de text (LLMs / RAG):
| Metrica | Que mesura | Eina |
|---|---|---|
| RAGAS Faithfulness | La resposta es fiel als documents recuperats? | RAGAS |
| RAGAS Answer Relevance | La resposta respon la pregunta? | RAGAS |
| BLEU / ROUGE | Similitud lexica amb resposta referencia | Hugging Face evaluate |
| Latencia d'inferencia | Temps de resposta | Prometheus |
SLAs de l'API
Service Level Agreement (SLA) recomanats per a una API de IA:
| Indicador | Definicio | Objectiu | Alerta |
|---|---|---|---|
| Uptime | % de temps disponible | > 99.5% | < 99.0% |
| Latencia p50 | Mediana del temps de resposta | < 200ms | > 400ms |
| Latencia p99 | Percentil 99 del temps de resposta | < 500ms | > 1000ms |
| Error rate | % de respostes amb error (5xx) | < 0.1% | > 0.5% |
| Throughput | Requests per segon maxim | > 50 rps | < 20 rps |
Revisio de codi (Pull Requests)
Les bones practiques de revisio de codi per a projectes IA:
Checklist de Pull Request: - [ ] El codi segueix el coding style del projecte (PEP8, black) - [ ] Hi ha tests per a la nova funcionalitat - [ ] La documentacio esta actualitzada (docstrings, README) - [ ] No hi ha secrets ni credencials al codi - [ ] Les metriques del model no han degradat (test de regressio) - [ ] El codi nou no introdueix vulnerabilitats de seguretat - [ ] El model es reproductible (seed fixes, versionat de dades)
Tests per a sistemes IA
Piramide de tests per a un sistema ML:
/\
/ \
/ E2E \ <- Tests d'extrema a extrema (1-5%)
/--------\
/ Model \ <- Avaluacio del model (20-30%)
/ Tests \
/--------------\
/ Integracio \ <- Tests d'integracio (20-30%)
/----------------\
/ Tests Unitaris \ <- Tests unitaris (40-50%)
/------------------\
Guio del document de disseny
Index recomanat
1. Portada i control de versions
2. Resum executiu del disseny (max. 2 pagines)
3. Recollida de requisits
3.1. User stories (taula completa)
3.2. Casos d'us principals
3.3. Requisits no funcionals
3.4. Restriccions i suposicions
4. Estudi de viabilitat tecnica
4.1. Analisi del problema tecnic
4.2. Opcions de solucio considerades (min. 3)
4.3. Comparativa i justificacio de la seleccio
4.4. Riscos tecnics identificats
4.5. Conclusio de viabilitat
5. Arquitectura del sistema
5.1. Diagrama d'arquitectura (C4 model o similar)
5.2. Components principals i responsabilitats
5.3. Fluxos de dades
5.4. Infraestructura requerida
6. WBS - Work Breakdown Structure
6.1. WBS complet (3 nivells)
6.2. Estimacio d'hores per tasca
6.3. Dependencies entre tasques
7. Objectius SMART
7.1. Objectius principals (min. 3)
7.2. Metriques de succes associades
7.3. Criteris d'acceptacio
8. Recursos necessaris
8.1. Equip huma (perfils i dedicacio)
8.2. Infraestructura tecnologica
8.3. Llicencies i serveis externs
8.4. Formacio especifica
9. Pressupost
9.1. Desglossament per partides
9.2. Comparativa opcions (ex: cloud vs on-premise)
9.3. Analisi cost-benefici
9.4. Necessitats de finançament
10. Control de qualitat
10.1. Metriques de qualitat del model
10.2. SLAs de l'API
10.3. Procediments de revisio de codi
10.4. Estrategia de tests
11. Conclusions i proxims passos
Annexos:
A. Matriu de requisits
B. Diagrames tecnics detallats
C. Calculs de dimensionament
Rubrica de la Fase 2
| Criteri | Pes | Excel·lent (9-10) | Notable (7-8) | Aprovat (5-6) | Insuficient (<5) |
|---|---|---|---|---|---|
| Recollida de requisits (CA2.1) | 15% | User stories detallades amb criteris d'acceptacio. Requisits no funcionals quantificats | User stories correctes. Alguns requisits no funcionals | User stories basics. Requisits NFR generals | Sense user stories o molt generes |
| Viabilitat tecnica (CA2.2) | 20% | Min. 3 opcions comparades i justificades. Riscos tecnics identificats. Conclusio solida | 2 opcions comparades. Justificacio correcta | 1 opcio analitzada superficialment | Sense analisi de viabilitat |
| WBS i objectius (CA2.3-CA2.4) | 20% | WBS 3 nivells complet. Objectius SMART verificables. Scope statement clar | WBS 2 nivells. Objectius majoritariament SMART | WBS 1 nivell. Objectius basics | Sense WBS o objectius no mesurables |
| Pressupost (CA2.5-CA2.7) | 25% | Pressupost detallat per partides. Personal amb tarifes reals. Infraestructura calculada. Contingencies | Pressupost correcte amb principals partides | Pressupost aproximat | Pressupost absent o irreal |
| Qualitat i documentacio (CA2.8-CA2.9) | 20% | Pla de qualitat complet. SLAs definits. Document professional i complet | Pla de qualitat correcte. Document complet | Aspectes de qualitat basics | Sense pla de qualitat |
Consells per a la Fase 2
- Arquitectura primer: Dibuixa l'arquitectura en paper abans de triar les eines. La tecnologia ha de seguir l'arquitectura, no al reves.
- Pressupost real: Consulta els preus actuals d'AWS/GCP/Azure. Usa la calculadora de preus oficial. No inventes xifres.
- Objectius mesurables: Cada objectiu ha de tenir una metrica concreta. "El sistema ha de funcionar be" NO es un objectiu SMART.
- WBS prou detallat: Cada tasca del WBS ha de tenir una duracio estimada. Si una tasca te mes de 16h, descompon-la mes.
Errors freqüents de la Fase 2
- Copiar una arquitectura d'un tutorial sense adaptar-la al cas d'us concret
- Pressupost amb personal a 0 € ("ja ho faig jo") o tarifes irreals (5 €/h)
- WBS amb un sol nivell (sense descomposicio real de les tasques)
- Objectius no mesurables: "el sistema ha de ser rapid i fiable"
- No considerar les contingencies al pressupost
- Triar tecnologies sense comparar alternatives