Skip to content

Clase 7 — Tema 4: Reutilización del software + refuerzo (corrección actividad 1)

Resumen Ejecutivo

Clase doble con cambio de bloque. Primera parte: inicio del segundo bloque de la asignatura con el tema 4 (Reutilización del software). Se sistematiza qué se puede reutilizar (conocimiento, diseños, componentes, frameworks, aplicaciones completas), los enfoques (oportunista vs proactivo), los niveles de granularidad (fino/medio/grueso) y los problemas (jardines vallados, síndrome Not-Invented-Here). Segunda parte (refuerzo): corrección en directo de 4 entregas reales anonimizadas de la actividad 1 (sprint planning + burndown + enfoques de reutilización), extrayendo patrones buenos y errores típicos. ⚠️ EXAMEN: la clase contiene pistas claras de errores frecuentes — portada/introducción, paneles al inicio del día, burndown realista, no mezclar horas con puntos de historia.

Parte 1: Reutilización del software

Conceptos Clave

  • Reutilización: filosofía de afrontar proyectos sin empezar desde cero. Va más allá del código: se reutilizan conocimiento (tutoriales, libros, Stack Overflow, patrones), diseños (arquitecturas, tarjetas CRC) e implementaciones (librerías, componentes, frameworks, aplicaciones enteras).
  • Objetivos fundamentales (3): ⚠️ EXAMEN
  • Reducir tiempo de desarrollo.
  • Reducir costes (consecuencia del 1 y del mantenimiento).
  • Aumentar calidad — el software reutilizado ya está probado por comunidades amplias de usuarios.
  • Enfoque oportunista: buscar qué reutilizar ante un problema concreto. Práctico y habitual.
  • Enfoque proactivo: anticiparse, construir biblioteca propia de componentes reutilizables. Más valioso en organizaciones que trabajan en sectores concretos con proyectos similares.
  • Niveles de granularidad: grano fino (funciones, clases), grano medio (componentes, subsistemas, widgets), grano grueso (frameworks, aplicaciones completas).
  • Jardín vallado (walled garden): metáfora para situaciones en las que una tecnología/proveedor/framework nos atrapa. Es bonito, útil, cómodo… pero salir es difícil. Ejemplos: Microsoft y licencias educativas, servicios cloud con lock-in.
  • Síndrome Not-Invented-Here (NIH): desconfianza hacia código externo; "lo haremos mejor nosotros". A veces es orgullo, a veces es prudencia legítima cuando el componente es core de negocio.
  • Software libre (4 libertades): ⚠️ EXAMEN
  • Ejecutar el programa con cualquier propósito.
  • Estudiar y modificar el código.
  • Distribuir copias.
  • Mejorar y publicar las mejoras.
  • Código abierto ≠ software libre: todo software libre es código abierto, pero no al revés.

Desarrollo del Temario

1. Por qué reutilizar: los 3 objetivos

  1. Menos tiempo: las partes que reutilizamos no hay que construirlas. Queda el esfuerzo de integración.
  2. Menos costes: menos tiempo → menos horas de ingeniería → menos presupuesto.
  3. Más calidad: reutilizamos componentes probados por comunidades amplias, a menudo con contribuyentes más especializados que nosotros. A lo cual se suma reducción de coste de mantenimiento… con matices ⚠️ EXAMEN:
  4. Las actualizaciones de dependencias pueden romper el proyecto.
  5. Dependencias pueden desaparecer (proyecto discontinuado, empresa cerrada).
  6. Seguridad: librerías comprometidas (NPMX como ejemplo real) pueden introducir vulnerabilidades.

2. Qué ha hecho posible la reutilización moderna

  • Software libre y código abierto: Richard Stallman, GNU, emacs. Poder ver, modificar y redistribuir código.
  • Estándares: XML, JSON, W3C. Permiten que componentes de distintos fabricantes "encajen".
  • Frameworks: cada framework es en sí mismo un estándar del equipo que lo usa.

3. Qué podemos reutilizar: la taxonomía completa

Ámbito Ejemplos
Conocimiento Libros, tutoriales, cursos, Stack Overflow, IA, experiencias previas, patrones.
Diseño Arquitecturas de referencia (MVC, microservicios), patrones de diseño (GoF), tarjetas CRC.
Implementación Funciones, clases, librerías, servicios, componentes, frameworks, aplicaciones completas.

Reflexión del profesor: Stack Overflow sigue teniendo valor frente a la IA por el debate entre humanos expertos, aunque la IA cubre muchos casos de uso de forma más eficiente.

4. Niveles de granularidad

flowchart LR
    Fine[Grano fino:<br/>funciones, clases] --> Med[Grano medio:<br/>componentes, widgets, subsistemas]
    Med --> Coarse[Grano grueso:<br/>frameworks, aplicaciones]
  • Grano fino: funciones de una librería matemática (sqrt), clases concretas. Evolución histórica: fue el primer nivel (años 80-90, librerías C).
  • Grano medio: componentes reutilizables (Material UI, paquetes Django). Segundo nivel histórico, ligado a OO y a ActiveX/COM.
  • Grano grueso: frameworks completos (Django, Next.js, React) y aplicaciones listas (Word, Chrome, WordPress para montarse un blog en un servidor en lugar de programarlo). Tercer nivel, el más reciente.

Propiedad clave: cada nivel engloba a los inferiores. Usar Django (framework) arrastra componentes y librerías.

5. Servicios: no todo servicio es remoto ⚠️ EXAMEN

Un servicio es software que ofrece funcionalidad a otros. No implica "remoto".

Ejemplo canónico — un sistema operativo es una colección de servicios:

Aplicaciones
  ↓ llamadas al sistema
Servicios del SO (I/O, red, archivos, audio)
  ↓ drivers
Hardware

Cuando mi app reproduce un MP3, no sabe cómo funciona el archivo MP3: hace una llamada al sistema y el SO resuelve. Android expone esto como Application Framework → HAL (Hardware Abstraction Layer). El servidor X (Unix) lleva décadas siendo un servicio gráfico local.

6. Componentes: el contrato como caja negra ⚠️ EXAMEN

Un componente es una unidad de software independiente con dos interfaces bien definidas:

  • Interfaz requires (mano abierta ☝): lo que el componente necesita para funcionar (dependencias).
  • Interfaz provides (bola cerrada): lo que el componente ofrece a quien lo use.

Caja negra = puedo ver el código si está abierto, pero no debería necesitar hacerlo. Lo que me importa es la interfaz y la documentación. Requisitos: - Estandarizado. - Componible. - Implementable independientemente. - Bien documentado.

7. Frameworks

Definición: conjunto integrado de artefactos de software (código + documentación + tutoriales + validaciones) que proporciona una arquitectura reutilizable.

Ventajas: - No inventamos arquitectura desde cero. - Integración natural con frameworks de pruebas. - Engloba niveles inferiores de reutilización (librerías, componentes).

Problemas: - Curva de aprendizaje puede ser dura, sobre todo para novatos. - Elegir framework es complicado (mercado saturado, riesgo de que se abandone). - Depuración: cuando falla, a veces hay que bajar a las tripas (y descubrir por qué saber C sigue importando). Ejemplo del profesor: Django, adorable hasta que te toca seguir un traceback hasta C.

8. Aplicaciones COTS (Commercial Off The Shelf)

  • COTS: aplicaciones listas para instalar y usar. Zoom, Word, WordPress, SAP.
  • Software privativo vs libre: con privativo, las adaptaciones dependen del proveedor. Con libre, puedes adaptar pero necesitas equipo técnico.
  • Sistemas integrados de COTS: componer varios productos comerciales y hacer el "pegamento". Típico en empresas grandes (universidad con Moodle + Canvas + Magento + Jira + web pública).
  • Soluciones a medida sobre COTS: consultoría tipo SAP — te instalan, configuran y adaptan a tu organización. Tú olvidas el mantenimiento.

9. Ingeniería basada en componentes (CBSE): flujo de proceso

flowchart TD
    Req[Requisitos iniciales] --> Search[Buscar componentes disponibles]
    Search --> Adapt1{Componente<br/>obliga a cambiar<br/>requisitos?}
    Adapt1 -->|sí| Req
    Adapt1 -->|no| Eval[Evaluar componentes]
    Eval --> Select[Seleccionar componentes]
    Select --> Design[Diseño arquitectónico final]
    Design --> Int[Integrar y construir]

Retroalimentación: es habitual que la elección de componentes modifique los requisitos (ej.: "encontré un componente brutal pero requiere datos en XML, no en JSON"). Es una decisión pragmática, no un fallo de ingeniería.

10. Beneficios y problemas (consolidado)

Beneficios adicionales (más allá de los 3 objetivos): ⚠️ EXAMEN - Conocimiento especializado: comunidades globales de expertos en tu componente concreto (gente en Helsinki, Tokio… ni siquiera en tu empresa). - Experiencia de usuario uniforme: botones, menús, widgets estandarizados → el usuario reconoce patrones en distintas aplicaciones. - Diseño arquitectónico mejor: el framework ya impone una estructura probada. - Inversión a futuro: las librerías internas se reutilizan en proyectos sucesivos.

Problemas adicionales: ⚠️ EXAMEN - Mantenimiento con código ajeno que no se puede auditar. - Jardines vallados: atrapamiento en proveedor. - Cambios de precios o condiciones (caso Microsoft educación). - Coste de aprendizaje + creación de librerías internas. - Integración no trivial (ver diagrama anterior). - Síndrome NIH: la desconfianza del ingeniero senior.

11. Cómo decidir qué reutilizar (checklist ⚠️ EXAMEN)

  1. Tiempo disponible: plazo ajustado → buscar reutilizar.
  2. Complejidad del proyecto.
  3. Vida esperada + mantenimiento: ¿comunidad sólida?, ¿buena documentación?, ¿código fuente accesible?
  4. Experiencia del equipo: ¿sabemos usar y adaptar ese framework?
  5. Criticidad: sistema crítico → más control, menos dependencias externas opacas.
  6. Dominio: ¿hay componentes maduros o es territorio nuevo?
  7. Plataforma de despliegue: ¿la integración es factible?

12. Patrones de arquitectura vs patrones de diseño (adelanto)

  • Arquitectura (temas 5-6): visión general del sistema, grandes componentes y cómo interactúan. Ejemplos: repositorio de datos + API + front. MVC está a medio camino.
  • Diseño detallado (tema 7): soluciones a nivel de clases. Patrones de GoF (Gamma et al.).

En el grado hay una asignatura específica (Reutilización del Software) que programa estos patrones. En esta asignatura se ven de forma general: entender de qué van, no programarlos.

Parte 2: Refuerzo — Corrección de la actividad 1

Objetivo

Comentar 3-4 entregas reales anonimizadas para extraer buenos patrones y errores típicos. Trabajos de notable para arriba — no hay entregas malas, pero sí cosas mejorables.

Errores y patrones observados

Trabajo 1 — Sólido con detalles a pulir

Bien: - Portada y redacción cuidada. - Introducción concisa pero completa: resumen del proyecto en pocas líneas. - Equipo de 4 personas, 8h/día, 4 días de desarrollo + 1 día para cierre (reunión, revisión, retrospectiva) → cálculo 128 h disponibles. - Descomposición de historias en tareas con tabla con total. - Panel con convenio de colores por desarrollador. - Burndown realista: evolución día a día con actualizaciones intermedias. - Enfoques de reutilización específicos al proyecto (Leaflet/Google Maps para mapas, API ministerio para precios, Material UI).

Mejorable: - Elección de historia 10 (validación de información) antes que la 8 (envío de información por empresarios). Sin información enviada, no hay qué validar. ⚠️ EXAMEN — patrón a evitar. - Uso de MVC como ejemplo de "reutilización de componentes": MVC es un patrón, no un componente. Diferenciar.

Trabajo 2 — Sobrio pero con redacción problemática

Problemas de redacción: ⚠️ EXAMEN - Sin portada ni índice. - Uso de barras ("/") como conectores — coloquial, evitar en documentación profesional y TFG. - Cambios de persona: "Os dejaré unas tablas que he construido". Redactar en segunda persona del plural como si fuera un diálogo con el lector chirría en un documento técnico. Indicio de redacción asistida por IA mal revisada. - Reescritura del enunciado en la introducción: desperdicia espacio y sube el porcentaje de similitud (Turnitin).

Problemas de contenido: - 200h disponibles - 160h comprometidas = 40h de margen. No se justifica en qué se usan. En otro trabajo estaba claro: "último día para revisión + retrospectiva + reuniones". - Panel organizado por columnas (una por historia) en lugar de filas. Menos legible. - Burndown con una línea recta entre día 1 y día 4 — implica que no hay actualizaciones intermedias. Irrealista.

Trabajo 3 — Buena presentación, errores de concepto serios

Bien: - Presentación muy cuidada. - Aplica un "factor de foco" del 80% (20% reservado para reuniones, ceremonias). - Tablas con totales bien visibles. - Justifica selección de historias por flujo funcional.

Mal (errores conceptuales graves): ⚠️ EXAMEN - Panel tras la primera daily con tareas YA completadas. Imposible. La primera daily es justo después de la planificación; no ha habido tiempo de completar nada. - Historias de usuario completadas pero con tareas todavía en proceso: incoherente. - Burndown sin sentido. - Afirmación "si hiciéramos todas las historias serían 300 horas" — débil, porque la pila de producto entera serían miles de horas (es el proyecto completo). Mala interpretación de qué se espera de un sprint.

Trabajo 4 — Bueno pero incompleto

Bien: - Portada muy cuidada. - Introducción concisa. - Desarrollo día a día con diálogos de la daily muy realistas. - Retrospectiva final excelente: identifica que "los desarrolladores tienden a resolver problemas en solitario en lugar de pedir ayuda" — exactamente el tipo de insight que se busca.

Mal: - Ana toma una tarea de 4 horas cuando tiene 8 horas disponibles — queda tiempo inexplicado. - Día 2: el equipo sigue en las mismas tareas, nadie ha terminado — y en la daily del día 2 nadie comenta el problema. Falla la comunicación. La daily es precisamente para eso. - Al final, varias historias quedan incompletas: la review con el cliente fue "un horror". - Mezcla "86 horas/puntos" — NO mezclar horas con puntos de historia, mucho menos con una barra. - Apartado de reutilización: no existe. Olvido importante.

Lecciones generales extraídas de las 4 correcciones ⚠️ EXAMEN

  1. Portada + índice + estructura APA cuando el enunciado lo permite o pide.
  2. No copiar el enunciado de la actividad en el documento: sube el Turnitin y desperdicia espacio.
  3. Evitar etcéteras, puntos suspensivos y barras ("/") en documentación técnica; son fuentes de incertidumbre.
  4. Nunca mezclar horas con puntos de historia.
  5. Panel del día 1 (tras primera daily): nada puede estar "Done". Todas las tareas están en "Pending" o "In progress".
  6. Burndown realista: evolución día a día, no una línea recta con un solo punto intermedio.
  7. Justificar la reserva de tiempo (reuniones, ceremonias, buffer) — no dejar 40h "colgando" sin explicación.
  8. Redacción uniforme (persona consistente, no "os dejaré" mezclado con "se presenta").
  9. Imágenes y tablas grandes → páginas apaisadas para favorecer lectura. Consejo para TFG especialmente.
  10. Retrospectiva explícita — se valora mucho cuando el alumno identifica problemas reales de la dinámica (comunicación, estimaciones) y propone mejoras.
  11. Enfoques de reutilización específicos al proyecto concreto — no genéricos. "Leaflet para mapas" > "se pueden usar APIs y sistemas de diseño".

Debate en clase

P: ¿Qué opinión tiene el profesor sobre que un desarrollador se autoasigne dos tareas que superan sus horas del día?

R: A priori bien, si el equipo lo discute en la daily. Si es por iniciativa propia ("me apetece") y el equipo acepta, perfecto. Si es acaparamiento (mandato individual), falla el respeto y la comunicación, y el Scrum Master debe intervenir.

Rol del Scrum Master: NO es jefe de proyecto. Facilita. Orienta cuando el equipo está perdido. Su tarea principal es garantizar que se siguen los valores y prácticas (como detectar que Ana no pregunta cuando está atascada).

Daily: 5 minutos, de pie (stand-up), tres preguntas: ⚠️ EXAMEN 1. ¿Qué hice ayer? 2. ¿Qué voy a hacer hoy? 3. ¿Tengo algún problema?

Si aparece un problema, no se debate en la daily: se agenda para después con los miembros concretos involucrados (típicamente pair programming de 1h entre dos personas). La daily no es café ni reunión larga; es un mecanismo de flujo de información.

Preguntas de Autoevaluación

  1. Nombra los 3 objetivos fundamentales de la reutilización. Reducir tiempo, reducir costes, aumentar calidad.
  2. ¿Qué diferencia hay entre enfoque oportunista y proactivo? El oportunista busca qué reutilizar ante un problema concreto; el proactivo se anticipa y construye una biblioteca reutilizable para proyectos futuros.
  3. Cita las 4 libertades del software libre. Ejecutar, estudiar/modificar, distribuir, mejorar y publicar.
  4. ¿Código abierto implica software libre? No. Al revés sí: todo libre es abierto, no todo abierto es libre.
  5. Nombra los 3 niveles de granularidad y un ejemplo de cada uno. Fino (función sqrt, clase ArrayList); medio (Material UI, paquetes Django); grueso (Django framework, WordPress).
  6. ¿Puede un servicio no ser remoto? Da un ejemplo. Sí. Un sistema operativo ofrece servicios locales a las aplicaciones a través de llamadas al sistema.
  7. ¿Qué son las interfaces requires y provides de un componente? Requires = dependencias que necesita. Provides = funcionalidad que ofrece.
  8. ¿Qué significa que un componente sea "caja negra"? Que para usarlo basta con su interfaz y documentación, sin necesidad de entrar al código interno.
  9. Define "jardín vallado" y da un ejemplo. Situación de atrapamiento en un ecosistema tecnológico del que es difícil salir. Ejemplo: SAP, AWS, o el cambio de Microsoft con las licencias educativas.
  10. Síndrome NIH. "Not Invented Here": tendencia a rechazar soluciones externas por desconfianza o por pensar que se harían mejor internamente.
  11. ¿Qué significa COTS? Commercial Off-The-Shelf: aplicaciones comerciales listas para instalar y usar.
  12. Nombra 3 criterios para decidir si reutilizar o construir desde cero. Tiempo disponible, vida esperada + calidad del soporte, criticidad del sistema.
  13. ¿Qué errores típicos comete un alumno al representar el panel tras la primera daily? Poner tareas en "Done". Es imposible: la primera daily ocurre antes de que nadie haya producido nada.
  14. Daily: tres preguntas canónicas. ¿Qué hice ayer? ¿Qué hago hoy? ¿Tengo algún problema?
  15. ¿Por qué es un error mezclar horas con puntos de historia en la misma tabla? Son unidades distintas: horas miden esfuerzo absoluto; puntos de historia miden complejidad relativa. Mezclarlas rompe la coherencia.

Referencias

  • Richard Stallman, movimiento GNU/FSF, fundador del software libre.
  • Libro de referencia sobre componentes (GoF más adelante en el tema 7).
  • Próxima clase: patrones de arquitectura (tema 5-6) y más tarde patrones de diseño (tema 7).
  • Actividad 3: llegará próximamente con proyectillo Node+React, con framework de pruebas preconfigurado.