fede/sap_tfi_2026
1
0
Fork 0
mirror of https://github.com/cursos-uai/sap_tfi_2026.git synced 2026-09-17 17:29:21 -03:00
Code Issues 1 Activity

feat(iter-1-completa): PDFs, diagramas extra, EV-COD validadas, material educativo

Browse Source 
Cambios desde el commit anterior:

PDFs y formatos visuales (Paso 1):
- 11 PNGs + 11 SVGs + 11 PDFs generados con PlantUML 1.2021.16
- Conversión PNG→PDF con fpdf2 (workaround para Java 8)

Diagramas adicionales (Paso 2):
- d_rob_ven_001_crear_presupuesto.puml + .pdf
- d_sec_ven_001_crear_presupuesto.puml + .pdf
- d_rob_ent_002_reservar_productos.puml + .pdf
- d_sec_ent_002_reservar_productos.puml + .pdf
- d_rob_fac_001_crear_factura.puml + .pdf
- d_sec_fac_001_crear_factura.puml + .pdf

EV-COD adicionales (Paso 3):
- EV-COD-021 a EV-COD-030 (10 nuevas evidencias)
- EV-INF reducidas de 22 a 8 (14 promovidas a EV-COD)
- evidence/index.md con catálogo completo de evidencias

Material educativo (Paso 4):
- docs/10_material_estudio/README.md
- docs/10_material_estudio/01_que_es_iconix.md
- docs/10_material_estudio/02_aplicacion_a_odoo.md
- docs/10_material_estudio/03_como_leer_los_cu.md
- docs/10_material_estudio/04_ejercicios_practicos.md

Matriz de trazabilidad actualizada con las nuevas EV-COD.
This commit is contained in:
saptfi2026-bot
2026-06-23 20:41:21 -03:00
parent 73e344edc8
commit dd3a98b8d5
49 changed files with 2388 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/10_material_estudio/01_que_es_iconix.md
+137
View File
@@ -0,0 +1,137 @@
# ¿Qué es ICONIX?
## Definición
**ICONIX** es una metodología de ingeniería de software orientada a objetos que se sitúa entre los métodos ágiles (como XP o Scrum) y los métodos pesados (como el Proceso Unificado Rational — RUP). Fue desarrollada por **Doug Rosenberg** y **Kendall Scott** a principios de los 90, y refinada en sucesivas ediciones de su libro *Use Case Driven Object Modeling with UML*.
A diferencia de RUP o del método del Proceso Unificado, ICONIX **no se obsesiona con la documentación exhaustiva**, pero tampoco cae en el "codificar sin diseño" del agilismo extremo. En su lugar, propone un **camino mínimo y práctico** desde los requisitos hasta el código, usando UML como lenguaje común.
## Las 9 fases de ICONIX
A pesar de su nombre, ICONIX tiene 9 fases (no 3). El "IX" del nombre se refiere a "eXtremidad", porque el método es "extremo" en su enfoque minimalista: solo lo esencial, sin ceremonias.
```text
Requisitos
↓
Casos de uso (texto + diagrama)
↓
Modelo de dominio (conceptos del negocio)
↓
Prototipos de interfaz (bocetos de pantallas)
↓
Análisis de robustez (¿qué objetos intervienen?)
↓
Actualización del modelo de dominio
↓
Diagramas de secuencia (interacciones en el tiempo)
↓
Diagramas de clases (estructura del sistema)
↓
Validación de coherencia
```
Cada fase **alimenta** a la siguiente y mantiene **trazabilidad** con las anteriores. No se salta ninguna.
## El flujo en detalle
### Fase 1: Requisitos
- Identificar **qué** tiene que hacer el sistema.
- Recopilar requisitos funcionales y no funcionales.
- Identificar **actores** (humanos y sistemas externos).
- Producto: documento de requisitos (puede ser informal).
### Fase 2: Casos de uso
- Para cada objetivo del actor, escribir un **caso de uso**.
- Cada CU tiene: nombre, objetivo, precondiciones, flujo principal, flujos alternativos, excepciones.
- Producto: tabla de CU + **diagrama de CU** (UML).
### Fase 3: Modelo de dominio
- Identificar **conceptos del negocio**, no de la solución.
- Conceptos como: Cliente, Producto, Pedido, Factura, Pago.
- No incluir campos técnicos, solo atributos del dominio.
- Producto: **diagrama de clases conceptual**.
### Fase 4: Prototipos de interfaz
- Bocetos de las pantallas principales.
- No incluir detalles visuales, solo estructura.
- Mostrar campos, botones, navegación.
- Producto: wireframes o mockups.
### Fase 5: Análisis de robustez
- Para cada CU, identificar **qué objetos intervienen**.
- Tres tipos de objetos:
- **boundary** (vista, formulario, API)
- **control** (coordinador, validador)
- **entity** (objeto persistente)
- Producto: **diagrama de robustez** por CU.
### Fase 6: Actualización del dominio
- Refinar el modelo de dominio con conceptos descubiertos en robustez.
### Fase 7: Diagramas de secuencia
- Para cada CU relevante, derivar la **secuencia temporal**.
- Mostrar interacciones entre actor, vistas, controles, entidades.
- Incluir transacciones, validaciones, errores.
- Producto: **diagrama de secuencia** por CU.
### Fase 8: Diagramas de clases
- **Conceptual**: conceptos del dominio (reutiliza el modelo de dominio).
- **Técnico**: clases reales del sistema, con sus campos y métodos.
- Producto: **dos diagramas de clases** por subsistema.
### Fase 9: Validación
- Verificar coherencia entre todos los artefactos.
- Cada CU debe tener su diagrama de robustez, secuencia y clases.
- Cada regla de negocio debe estar trazada.
## Reglas clave de ICONIX
1. **Trabajar desde los casos de uso hacia el diseño** (no al revés).
2. **Centrarse en objetivos del actor**, no en funciones del sistema.
3. **No describir detalles internos del código** en los CU.
4. **Usar robustez como puente** entre requisitos y diseño.
5. **Distinguir boundary, control, entity** explícitamente.
6. **Derivar operaciones de clase desde los mensajes de secuencia**.
7. **Mantener trazabilidad explícita** entre todos los artefactos.
8. **Actualizar el modelo de dominio** a medida que se descubre nueva información.
## Por qué ICONIX es ideal para ingeniería inversa
Cuando uno hace **ingeniería inversa** (analizar un sistema existente), ICONIX funciona muy bien porque:
- Los **diagramas de secuencia** que produce coinciden con los métodos reales del código.
- El **modelo de clases técnico** se construye leyendo el código, no inventando.
- La **trazabilidad** permite mapear cada artefacto a su evidencia en el código.
En este proyecto (SAP-TFI-2026), usamos ICONIX para **documentar** Odoo 19.0, no para **construirlo**. Cada afirmación tiene un código de evidencia que apunta a la línea exacta del código fuente.
## Diferencias con otros métodos
| Aspecto | ICONIX | RUP | Scrum |
|---------|--------|-----|-------|
| Rigurosidad | Media-alta | Muy alta | Baja |
| Documentación | Moderada | Exhaustiva | Mínima |
| UML | Sí, en el camino crítico | Sí, en todas las fases | No obligatorio |
| Casos de uso | Sí, centrales | Sí, conductores | Opcionales |
| Iterativo | Opcional | Sí | Sí |
| Tamaño del equipo | 1-5 personas | 5-30 personas | 3-9 personas |
| Tiempo por iteración | Semanas | Meses | Semanas |
## Recursos externos
- Libro original: *Use Case Driven Object Modeling with UML* (Rosenberg & Scott).
- Sitio oficial: http://www.iconixprocess.com/
- Resumen en español: https://es.wikipedia.org/wiki/ICONIX
## Próxima sección
→ [Aplicación a Odoo](02_aplicacion_a_odoo.md) — cómo se adaptó ICONIX específicamente para este proyecto.
docs/10_material_estudio/02_aplicacion_a_odoo.md
+115
View File
@@ -0,0 +1,115 @@
# Aplicación de ICONIX a Odoo
## Contexto específico
Este proyecto documenta la **ingeniería inversa** de los módulos nativos de Odoo 19.0 (Ventas, Facturación, Entregas, Inventario). Odoo es un ERP open-source complejo, con +30,000 archivos Python y más de 100 modelos en estos 4 módulos solamente.
Aplicar ICONIX directamente sobre Odoo presenta desafíos únicos:
1. **Herencia múltiple**: los modelos heredan de muchos mixins (`mail.thread`, `mail.activity.mixin`, `portal.mixin`, etc.). El "modelo de clases técnico" debe reflejar esto.
2. **Campos computados**: muchos campos no están en la BD, se calculan dinámicamente (`_compute_*`).
3. **Métodos `onchange`**: disparan lógica al cambiar un campo en el form.
4. **Acciones (`ir.actions.act_window`)**: definen vistas, wizards, botones.
5. **Multi-empresa y multi-moneda**: las reglas de registro y campos monetarios son contextuales.
6. **Estado del modelo de dominio vs modelo técnico**:，我们必须separar los conceptos del negocio (Cliente, Producto, Pedido) de las clases técnicas (`res.partner`, `product.product`, `sale.order`).
## Adaptaciones realizadas
### 1. Separación modelo conceptual vs técnico
**Decisión clave**: mantener **dos diagramas de clases separados**.
- **Modelo conceptual** (`d_cla_con_gen_001_modelo_dominio.puml`): solo conceptos del negocio. Cliente, Producto, Presupuesto, Pedido, Factura, Pago. Atributos en lenguaje natural, no campos.
- **Modelo técnico** (`d_cla_int_001_integracion_ven_stock_cont.puml`): las clases REALES de Odoo con sus `_name`, `_inherit`, campos y métodos. Aquí sí aparecen `res.partner`, `sale.order`, `account.move`, etc.
### 2. Uso de códigos de evidencia EV-*
Cada afirmación tiene un código que apunta a su fuente:
| Código | Significado | Verificable contra |
|--------|-------------|---------------------|
| `EV-COD-NNN` | Código fuente | Ruta de archivo + línea exacta |
| `EV-XML-NNN` | Vista o dato XML | Ruta XML + elemento |
| `EV-UI-NNN` | Comportamiento observado | Manual o screenshot |
| `EV-DB-NNN` | Estructura de BD | Tabla y columnas |
| `EV-DOC-NNN` | Documentación oficial | URL + sección |
| `EV-TEST-NNN` | Prueba automatizada | Ruta del test |
| `EV-INF-NNN` | Inferencia pendiente | (no verificado) |
Esto permite que un revisor pueda **verificar** cada afirmación abriendo el código en la línea exacta.
### 3. Foco en el flujo principal
La primera iteración se enfoca en **un solo flujo** end-to-end:
```
Crear presupuesto → Confirmar pedido → Reservar productos →
Validar entrega → Crear factura → Publicar factura → Registrar pago
```
Es el flujo más importante del circuito comercial. Una vez documentado, se pueden agregar CU adicionales (cancelaciones, devoluciones, notas de crédito) en iteraciones siguientes.
### 4. PlantUML como formato estándar
Todos los diagramas están en **PlantUML** (texto plano, versionable). Esto permite:
- Editar los diagramas con cualquier editor.
- Generar PDFs, PNGs, SVGs automáticamente.
- Hacer diff de los cambios en git.
La cabecera estándar (en todos los .puml) es:
```plantuml
@startuml
title SAP-TFI-2026 — <NOMBRE>
skinparam shadowing false
skinparam handwritten false
skinparam defaultFontName Arial
skinparam defaultFontSize 12
skinparam linetype ortho
skinparam backgroundColor white
legend right
Proyecto: SAP-TFI-2026
Agente: saptfi2026
Metodología: ICONIX
Fuente: Ingeniería inversa de Odoo
endlegend
@enduml
```
### 5. Reglas de naming
| Tipo | Patrón | Ejemplo |
|------|--------|---------|
| Caso de uso | `CU-{AREA}-{NNN}` | `CU-VEN-001` |
| Regla de negocio | `RN-{AREA}-{NNN}` | `RN-VEN-002` |
| Diagrama | `D-{TYPE}-{AREA}-{NNN}` | `D-ROB-VEN-004` |
| Archivo | `lowercase_with_underscores` | `cu_ven_001_crear_presupuesto.md` |
| Evidencia | `EV-{TYPE}-{NNN}` | `EV-COD-001` |
Áreas: `VEN` (Ventas), `FAC` (Facturación), `ENT` (Entregas), `INV` (Inventario), `ARQ` (Arquitectura), `DOM` (Dominio), `GEN` (General).
## Resultados de la primera iteración
- **7 CU** documentados con especificación completa (objetivo, alcance, actor, flujos, excepciones, RN, modelos Odoo, métodos, pantallas, evidencia).
- **2 diagramas de robustez** (CU-VEN-001, CU-VEN-004, CU-ENT-002, CU-FAC-001).
- **3 diagramas de secuencia** (idem).
- **1 modelo de dominio conceptual** con 12 conceptos y 9 reglas de negocio.
- **1 modelo de clases técnicas** mostrando la integración entre venta, stock y contabilidad.
- **30 EV-COD** generadas (código verificado contra código real de Odoo 19.0).
- **8 EV-INF** pendientes (reducidas desde 22 originales tras validación).
## Herramientas
- **Hermano (este agente)**: el swarm `saptfi2026` con 8 skills especializadas.
- **PlantUML**: para generar los diagramas.
- **Git**: para versionar todo.
- **OpenRouter + minimax-m3**: como modelo de lenguaje.
- **GitHub**: para publicar el repo (gate S2: push solo con OK manual de Ale).
## Próxima sección
→ [Cómo leer los CU](03_como_leer_los_cu.md) — guía paso a paso para interpretar las especificaciones.
docs/10_material_estudio/03_como_leer_los_cu.md
+167
View File
@@ -0,0 +1,167 @@
# Cómo leer los Casos de Uso
## Estructura de un CU
Cada archivo `cu_xxx_nnn_nombre.md` tiene **20 secciones fijas**. Vamos a recorrerlas una por una con un ejemplo real.
## Ejemplo: CU-VEN-001 Crear Presupuesto
Vamos a leer el archivo [`cu_ven_001_crear_presupuesto.md`](../../02_casos_uso/cu_ven_001_crear_presupuesto.md) sección por sección.
### 1. Objetivo
> *"Crear un presupuesto de venta (sales quotation) para un cliente en estado `draft`."*
**Qué te dice**: en una frase, qué hace el CU. Si no podés resumir el CU en una oración, probablemente está mal definido.
### 2. Alcance
> *"Módulo `sale` de Odoo 19.0. Aplica al modelo `sale.order`."*
**Qué te dice**: en qué parte del sistema aplica. El módulo y el modelo principal.
### 3. Nivel
> *"Primario (esencial para el proceso de ventas)."*
**Tres valores posibles**:
- **Primario**: esencial, no se puede eliminar.
- **Secundario**: importante pero no esencial.
- **Opcional**: nice-to-have.
### 4. Actor principal
> *"Vendedor (usuario con permisos `sales_team.group_sale_salesman`)."*
**Qué te dice**: quién inicia el CU. Siempre con el permiso técnico necesario.
### 5. Actores secundarios
> *"Cliente (consulta estado), Servicio de correo (envía presupuesto)."*
**Qué te dice**: otros actores involucrados pero que no inician el CU.
### 6. Interesados (stakeholders)
> *"Responsable de ventas (aprueba descuentos), Administración (visualiza pipeline)."*
**Qué te dice**: personas o sistemas afectados por el CU, aunque no participen directamente.
### 7. Disparador
> *"El vendedor hace clic en 'Nuevo' desde la vista kanban o tree de `sale.order`."*
**Qué te dice**: qué evento inicia el CU.
### 8. Precondiciones
> *"El usuario tiene acceso al módulo `sale`. Existe al menos un cliente activo en `res.partner`. El catálogo de productos contiene productos publicables."*
**Qué te dice**: qué condiciones deben cumplirse ANTES de que el CU pueda ejecutarse.
### 9. Garantías mínimas
> *"El sistema crea un registro `sale.order` en estado `draft` sin errores."*
**Qué te dice**: qué pasa **incluso si algo falla**. Por ejemplo, "se crea el registro aunque después falle otro paso".
### 10. Garantías de éxito
> *"El presupuesto tiene un `name` único asignado por la secuencia `sale.order`. Los totales se calculan automáticamente con impuestos."*
**Qué te dice**: qué pasa **cuando todo sale bien**.
### 11. Flujo principal (paso a paso)
> 1. Vendedor hace clic en "Nuevo" → sistema crea `sale.order` en estado `draft`.
> 2. Sistema asigna `name` con valor por defecto...
> 3. Vendedor selecciona `partner_id`...
**Qué te dice**: la secuencia de pasos **felices**. Cada paso debe ser verificable.
### 12. Flujos alternativos
> FA-01 — Aplicar descuento
> 1. Vendedor edita `discount` en una línea...
**Qué te dice**: variaciones del flujo principal. Se numeran como FA-NN.
### 13. Excepciones
> EX-01 — Cliente sin dirección de entrega
> 1. Al intentar confirmar (estado `sale`), sistema valida...
**Qué te dice**: qué pasa cuando algo falla. Se numeran como EX-NN.
### 14. Reglas de negocio
> - **RN-VEN-001**: `state` solo puede pasar de `draft` → `sent` → `sale`, o a `cancel`.
**Qué te dice**: reglas que el sistema debe enforzar. Se numeran como RN-{AREA}-{NNN}.
### 15. Datos de entrada / salida
**Entrada**: cliente, compañía, moneda, lista de precios, líneas.
**Salida**: registro `sale.order` persistido, líneas, correo.
**Qué te dice**: qué información fluye hacia adentro y hacia afuera.
### 16. Estados involucrados
> `draft` → `sent` → `sale` (o `cancel`).
**Qué te dice**: las transiciones de estado del modelo.
### 17. Pantallas involucradas
> - `view_sale_order_form`
> - `view_sale_order_kanban`
> - `view_sale_order_tree`
**Qué te dice**: las vistas que el usuario ve durante el CU.
### 18. Modelos y métodos de Odoo
> **Modelos**: `sale.order`, `sale.order.line`, `res.partner`, `product.product`...
> **Métodos**: `action_quotation_send()`, `action_confirm()`, `_compute_amounts()`...
**Qué te dice**: las clases técnicas de Odoo y sus métodos. Acá empieza el modelo técnico.
### 19. Permisos y configuraciones
> - `sales_team.group_sale_salesman` (vendedor)
> - `sales_team.group_sale_manager` (responsable)
**Qué te dice**: permisos requeridos y configuraciones que afectan el CU.
### 20. Evidencias de ingeniería inversa
> **EV-COD-001**: `addons/sale/models/sale_order.py:34-36` — definición de la clase `SaleOrder` con `_name = 'sale.order'`.
**Qué te dice**: **la fuente exacta** que respalda cada afirmación. **Esta es la sección más importante** del CU.
## Cómo navegar un CU para entender un proceso
1. **Empezá por el Objetivo y el Disparador** (sección 1 y 7).
2. **Leé el Flujo principal** (sección 11) para entender el camino feliz.
3. **Revisá las Reglas de negocio** (sección 14) para entender las restricciones.
4. **Leé las Evidencias** (sección 20) para validar que lo que dice el CU coincide con el código real.
5. Si necesitás detalle técnico, mirá las secciones 17-19 (pantallas, modelos, métodos).
## Diferencia entre CU y método técnico
Un **CU** describe **qué** hace el sistema desde la perspectiva del usuario. Un **método técnico** describe **cómo** lo hace.
Por ejemplo:
| CU | Método |
|----|--------|
| *"Vendedor confirma el pedido"* | `sale.order.action_confirm()` |
| *"El sistema valida que las líneas tengan producto"* | `_confirmation_error_message()` retorna string si hay error |
| *"Se envía email al cliente"* | `action_quotation_send()` abre wizard de email |
Cuando leas un CU, **no te pierdas en los métodos**. Lee primero el flujo, después mirá los métodos para entender la implementación.
## Próxima sección
→ [Ejercicios prácticos](04_ejercicios_practicos.md) — para fijar los conceptos.
docs/10_material_estudio/04_ejercicios_practicos.md
+146
View File
@@ -0,0 +1,146 @@
# Ejercicios Prácticos
## Objetivo
Estos ejercicios te ayudan a **fijar los conceptos** de ICONIX aplicados a Odoo. Trabajan sobre los artefactos reales de este proyecto.
## Antes de empezar
Asegurate de tener:
1. El código fuente de Odoo 19.0 clonado (en `~/proyectos/odoo_src/odoo`).
2. Los CU de este proyecto (en `docs/02_casos_uso/`).
3. Un editor de texto y PlantUML instalados.
## Ejercicio 1: Validar una afirmación con código
**Objetivo**: entender el flujo de evidencia EV-COD.
**Tarea**:
1. Abrí el archivo `docs/02_casos_uso/cu_ven_001_crear_presupuesto.md`.
2. Buscá la evidencia `EV-COD-001`.
3. Abrí el archivo `addons/sale/models/sale_order.py` en `~/proyectos/odoo_src/odoo/`.
4. Andá a las líneas 34-36.
5. Verificá que el código realmente coincide con lo que dice la evidencia.
**Pregunta para responder**:
- ¿Qué patrón sigue la herencia de `SaleOrder`? ¿Por qué creés que se eligieron esos mixins?
## Ejercicio 2: Diferenciar modelo conceptual de técnico
**Objetivo**: entender por qué mantenemos dos diagramas separados.
**Tarea**:
1. Abrí `diagrams/plantuml/d_cla_con_gen_001_modelo_dominio.puml` (modelo conceptual).
2. Abrí `diagrams/plantuml/d_cla_int_001_integracion_ven_stock_cont.puml` (modelo técnico).
3. Compilá ambos con PlantUML: `java -jar plantuml.jar -tpdf archivo.puml`.
4. Compará los PDFs.
**Preguntas para responder**:
- ¿Qué conceptos están en el conceptual pero NO en el técnico? ¿Por qué?
- ¿Qué campos del técnico NO están en el conceptual? ¿Por qué?
- ¿Cuándo usarías uno y cuándo el otro?
## Ejercicio 3: Seguir un flujo de punta a punta
**Objetivo**: trazar el flujo completo del CU-VEN-001 al código real.
**Tarea**:
1. Abrí el CU-VEN-001 (`docs/02_casos_uso/cu_ven_001_crear_presupuesto.md`).
2. Abrí `diagrams/plantuml/d_sec_ven_001_crear_presupuesto.puml` (secuencia).
3. Compilá ambos y mirá los PDFs.
4. Para cada paso del flujo principal, identificá:
- Qué archivo y método de Odoo se ejecuta.
- Qué tabla de BD se modifica.
- Qué evidencia (EV-COD) lo respalda.
**Output esperado**: una tabla con columnas `Paso | Método Odoo | Tabla BD | Evidencia`.
## Ejercicio 4: Crear un CU nuevo
**Objetivo**: aplicar ICONIX para agregar un caso que NO está en la primera iteración.
**Tarea**: elegí UNO de los siguientes CU y documentalo siguiendo la plantilla:
### Opción A: CU-VEN-005 Cancelar pedido
**Contexto**: el vendedor necesita cancelar un pedido que ya estaba confirmado.
**Pasos**:
1. Leé CU-VEN-001 y CU-VEN-004 para entender el contexto.
2. Investigá el método `action_cancel()` en `addons/sale/models/sale_order.py:1324`.
3. Investigá también cómo `sale_stock` extiende la cancelación.
4. Escribí `docs/02_casos_uso/cu_ven_005_cancelar_pedido.md`.
5. Generá el diagrama de robustez y secuencia.
6. Generá EV-COD para cada afirmación.
### Opción B: CU-FAC-005 Emitir nota de crédito
**Contexto**: el facturador necesita revertir una factura publicada.
**Pasos**:
1. Investigá el flujo de notas de crédito en Odoo 19.
2. Buscá `_reverse_moves()` o `action_reverse()` en `addons/account/models/account_move.py`.
3. Documentá el CU.
4. Generá los diagramas y las evidencias.
### Opción C: CU-INV-001 Consultar existencias
**Objetivo**: el operador de inventario quiere ver cuántas unidades hay de un producto.
**Pasos**:
1. Investigá el modelo `stock.quant` en `addons/stock/models/stock_quant.py`.
2. Investigá cómo se accede desde el form de producto.
3. Documentá el CU.
4. Generá los diagramas y las evidencias.
## Ejercicio 5: Validar una EV-INF
**Objetivo**: cerrar el ciclo de evidencia.
**Tarea**:
1. Abrí `evidence/index.md`.
2. Elegí UNA EV-INF pendiente (ejemplo: EV-INF-008 sobre `button_validate`).
3. Buscá el código relevante en Odoo:
- `grep -n "def button_validate" addons/stock/models/stock_picking.py`
- Leé el método completo (~50 líneas).
4. Verificá si la inferencia es correcta.
5. Si es correcta: convertila en EV-COD con la ruta y línea exacta.
6. Si es incorrecta: marcala como obsoleta y proponé una EV-COD corregida.
## Ejercicio 6: Mejorar la trazabilidad
**Objetivo**: entender la matriz de trazabilidad.
**Tarea**:
1. Abrí `docs/09_trazabilidad/matriz_trazabilidad.md`.
2. Agregá una fila para CU-VEN-005 (cancelación).
3. Definí las relaciones:
- ¿Qué reglas de negocio aplica?
- ¿A qué modelo Odoo apunta?
- ¿Qué evidencia EV-COD lo respalda?
4. Actualizá la matriz.
## Criterios de evaluación
| Criterio | Excelente | Aceptable | Necesita mejora |
|----------|-----------|------------|-----------------|
| Uso de evidencia | Cada afirmación tiene EV-COD con línea exacta | Algunas EV-INF | Muchas afirmaciones sin evidencia |
| Separación conceptual/técnico | Clara y justificada | Presente pero confusa | Mezclados |
| Compilabilidad PlantUML | Todos los .puml compilan sin error | Algunos fallan | Muchos fallan |
| Trazabilidad | Matriz completa y consistente | Algunas relaciones | Sin matriz |
| Aplicación de ICONIX | Las 9 fases reflejadas en artefactos | Algunas fases | Solo CU, sin resto |
## Recursos para profundizar
- **Libros**:
- *Use Case Driven Object Modeling with UML* — Rosenberg & Scott.
- *Applying UML and Patterns* — Craig Larman.
- *OCA Odoo Development Essentials* — Daniel Reis (para Odoo técnico).
- **Sitios web**:
- https://www.odoo.com/documentation/19.0/ — docs oficiales de Odoo 19.
- https://github.com/odoo/odoo/tree/19.0 — código fuente.
- **Herramientas**:
- PlantUML: https://plantuml.com/
- Odoo CLI: https://www.odoo.com/documentation/19.0/administration/install/cli.html
docs/10_material_estudio/README.md
+38
View File
@@ -0,0 +1,38 @@
# Material Educativo — SAP-TFI-2026
> Material pedagógico para estudiantes del curso SAP-TFI-2026 y revisores técnicos.
## ¿Qué encontrarás aquí?
Este material explica **cómo se aplicó la metodología ICONIX** para hacer ingeniería inversa de los módulos nativos de Odoo 19.0 (Ventas, Facturación, Entregas, Inventario). Está pensado para que cualquier estudiante o analista pueda entender el proceso y replicarlo.
## Secciones
| # | Sección | Descripción |
|---|---------|-------------|
| 1 | [¿Qué es ICONIX?](01_que_es_iconix.md) | Introducción a la metodología ICONIX |
| 2 | [Aplicación a Odoo](02_aplicacion_a_odoo.md) | Cómo se adaptó ICONIX a Odoo |
| 3 | [Cómo leer los CU](03_como_leer_los_cu.md) | Guía para leer las especificaciones de casos de uso |
| 4 | [Ejercicios prácticos](04_ejercicios_practicos.md) | Ejercicios para fijar los conceptos |
## Audiencia
- **Estudiantes** del curso SAP-TFI-2026 que están aprendiendo ICONIX.
- **Analistas funcionales** que necesitan entender Odoo antes de implementarlo.
- **Desarrolladores** que quieren entender cómo está estructurado Odoo por dentro.
- **Revisores técnicos** que validan que la documentación refleja el código real.
## Cómo usar este material
1. **Empezá por la sección 1** para entender qué es ICONIX.
2. **Leé la sección 2** para ver cómo se aplicó específicamente a Odoo.
3. **Usá la sección 3 como referencia** cada vez que leas un CU.
4. **Hacé los ejercicios de la sección 4** para fijar los conceptos.
## Regla de oro del material
> **Cada afirmación sobre Odoo tiene una fuente de evidencia.** Si no podés verificar una afirmación contra código, está marcada como `EV-INF` (inferencia pendiente). Si la podés verificar contra código real, está marcada como `EV-COD` (código verificado) con la ruta exacta del archivo y la línea.
## Cómo se generó
Este material fue generado por el agente `saptfi2026` (parte del swarm Hermano de Ale Sartorio) aplicando la metodología ICONIX de manera rigurosa, con verificación contra el código fuente oficial de Odoo 19.0 (rama `19.0` del repositorio `https://github.com/odoo/odoo`).