Tema 15: Administración de Proyectos y Diseño Detallado

📝 Resumen Ejecutivo

Esta sesión es una síntesis conceptual de la Administración de Proyectos de Software, enfocándose en el modelo de las "4 P" (Personal, Producto, Proceso, Proyecto) como pilares fundamentales. Se destaca la importancia crítica del factor humano y la comunicación por encima de las herramientas técnicas. Además, se aborda la transición del Análisis al Diseño, explicando cómo transformar un modelo de dominio en un diagrama de clases de diseño real utilizando patrones como DAO y MVC.

🗝️ Conceptos Clave

Modelo de las 4 P: Marco conceptual para la gestión de proyectos (Personal, Producto, Proceso, Proyecto).
Stakeholders (Participantes): Incluye gerentes, técnicos, clientes y usuarios finales (estos últimos no siempre son los que pagan).
Regla 90-90 (Tom Cargill): Paradoja de la estimación de tiempo en desarrollo de software.
Principio W5HH: Serie de 7 preguntas (Why, What, When, Who, Where, How, How much) para definir un proyecto.
Patrón DAO (Data Access Object): Patrón de diseño para desacoplar la lógica de negocio de la persistencia de datos.

📚 Desarrollo del Temario

1. El Marco de Gestión: Las 4 P

La administración de proyectos no se trata solo de fechas, sino de manejar la complejidad basándose en cuatro objetivos fundamentales.

A. Personal (People) - El Factor Vital

Es el elemento más importante ("Importancia vital en un proyecto" ). El éxito del proyecto se delega en las personas, alineándose con el Manifiesto Ágil.

Los Participantes (Stakeholders):
Profesionales: Quienes desarrollan (habilidades técnicas).
Clientes vs. Usuarios Finales: Es crucial distinguir que quien paga (cliente) no siempre es quien usa el software (usuario).

Ejemplo de Clase: Si desarrollas una app para Movistar, tu cliente es Movistar (la empresa), pero tus usuarios finales son los clientes de Movistar que consultan sus facturas. El feedback del usuario final llega indirectamente a través del cliente.

Gerentes: Tanto de negocio (ejecutivos) como técnicos.
Líderes de Equipo:
Se valora no solo la capacidad técnica, sino las Soft Skills: comunicación, motivación e influencia.
¡OJO AL DATO!: Un mal líder o una mala gestión de los problemas personales del equipo puede hundir el rendimiento. El profesor enfatiza que un director técnico es también un "director de personas y sus problemas".
Organización de Equipos:
Regla de oro: Equipos pequeños para ser controlables y manejables.
Cohesión y Acoplamiento: Se busca alta cohesión dentro del equipo y un nivel de interacción (acoplamiento) adecuado con otros equipos.
Modelos de Equipo (Tipología):
Equipo de Negocios: Horizontal, con un jefe técnico (Team Leader) que actúa más como líder técnico que como jefe jerárquico.
Programador Jefe: Jerárquico. El jefe hace el diseño y código crítico; el resto apoya.
Equipo SWAT: Especialistas en una herramienta o problema concreto. Son "paracaidistas" que entran, resuelven un fuego y se van.
Equipos Ágiles: Pequeños, automotivados, autoorganizados y con autonomía. Se busca maximizar la competencia individual.

B. Producto (Product)

Antes de planificar, hay que saber qué se va a construir.

Objetivo: Definir el ámbito y contexto del software.
Utilidad: Entender el producto facilita las estimaciones de coste, tiempo y recursos.
Nota del profesor: En consultoría, a veces se hacen estimaciones rápidas con poca información; en empresas de producto, se tiende a meditar más estas decisiones.

C. Proceso (Process)

Es el marco de trabajo. No existe un proceso único para todo.

Selección: Se debe elegir el modelo (Ágil, Cascada, etc.) basándose en las características del producto y del cliente.
¡Importante para examen!: Si el cliente no va a estar disponible día a día, no uses metodologías ágiles. El proceso debe adaptarse a la realidad de la participación del cliente.

D. Proyecto (Project)

El objetivo es manejar la complejidad.

Señales de Peligro (Riesgos):
Mal entendimiento de necesidades o ámbito mal definido.
Deadlines irreales o cambios mal gestionados.
Resistencia al cambio por parte de los usuarios.
Regla 90-90 (Tom Cargill):

"El primer 90% del código ocupa el primer 90% del tiempo de desarrollo. El 10% restante del código ocupa el otro 90% del tiempo".

Explicación: El trabajo no es lineal. Los detalles finales y la integración suelen consumir mucho más tiempo del estimado. El profesor usa la analogía del maratón (Murakami): los últimos kilómetros son los más duros psicológicamente.
Principio W5HH (Boehm):
Siete preguntas para obtener una "foto" inicial del proyecto: Why, What, When, Who, Where, How, How much .
Sirve para alinear objetivos, hitos y responsabilidades.

2. Transición de Análisis a Diseño (Resolución Actividad)

Esta sección es vital para entender la diferencia entre "lo conceptual" y "lo real".

Diferencia entre Diagrama de Análisis y Diseño

Análisis (Modelo de Dominio): Son clases conceptuales (entidades). Son meros contenedores de información sin lógica compleja. En el diseño, estas clases persisten como "moldes" de datos.
Diseño (Implementación): Introduce arquitectura real.
Capas: Interfaz (Vista), Negocio (Controlador/Lógica), Persistencia (Datos).
Desacoplamiento: Se busca que la capa de negocio no dependa directamente de cómo se guardan los datos.

El Patrón DAO (Data Access Object)

Problema: Si la lógica de negocio llama directamente a la base de datos, cualquier cambio en la base de datos rompe el negocio.
Solución: Se introduce una clase intermedia (DAO).
La capa de negocio pide "dame el cliente X".
El DAO sabe cómo hacer el SELECT o INSERT y devuelve un objeto.
Beneficio: Desacopla la persistencia del negocio.

Diagramas de Comportamiento en Diseño

Diagrama de Secuencia: Es como un "pseudocódigo pintado". Muestra paso a paso qué objeto llama a qué método. Es útil para programar pero costoso de mantener.
Diagrama de Actividad: Muestra el flujo de ejecución (decisiones, bucles) de un caso de uso completo. Es útil para entender la lógica de negocio (ej: si el pedido tiene > 24h, enviar mail; si > 72h, borrar).

🧪 Preguntas de Autoevaluación

Según el modelo de las 4 P, ¿por qué un "usuario final" no es necesariamente lo mismo que un "cliente"? Proporcione un ejemplo.
Respuesta: El cliente es quien contrata/paga el proyecto, el usuario final es quien interactúa con el software. Ejemplo: Movistar (cliente) vs. Abonado que usa la app (usuario).
Explique la Regla 90-90 de Cargill y qué implica para la planificación de un proyecto.
Respuesta: Implica que el desarrollo no es lineal; el último 10% del código (detalles, integración, correcciones) suele consumir tanto tiempo como todo el desarrollo previo, lo que a menudo lleva a retrasos si no se planifica.
En el contexto de equipos de trabajo, ¿qué es un equipo SWAT y cuándo se utiliza?
Respuesta: Es un equipo de especialistas en una herramienta o método concreto. Se utilizan para resolver problemas específicos y complejos ("fuegos") y luego se mueven a otro proyecto.
¿Cuál es la función principal del patrón DAO mencionado en la resolución de la actividad?
Respuesta: Desacoplar la capa de negocio de la capa de persistencia (base de datos), permitiendo cambiar la implementación de almacenamiento sin afectar la lógica del programa.
¿Qué riesgo de gestión destaca el profesor si se elige una metodología ágil con un cliente poco participativo?
Respuesta: El proyecto puede fracasar o desviarse porque las metodologías ágiles requieren feedback continuo. Si el cliente no está, el proceso no funciona adecuadamente.