Gestión del desarrollo de software
Guía de estudio según los contenidos mínimos del Plan 2024. La cátedra elige la forma de trabajo (ágil, por etapas o mixta) y las herramientas. Esta página ordena los temas del plan: no es un apunte de clase.
Carga de clase: 4 horas semanales, 64 horas. La Ordenanza 2115 suma 61 horas de trabajo autónomo (125 horas totales, 5 créditos). Cuarto cuatrimestre.
Fuente: Ordenanza 2018, Plan 2024 y Ordenanza 2115. Los mismos mínimos figuran en la ordenanza de la modalidad a distancia.
Objetivos
- Usar herramientas de gestión para llevar adelante un proyecto de software, integrando lo que ya viste en programación, bases de datos y metodología.
- Administrar tiempos y recursos sin perder de vista el producto.
- Recorrer las etapas y los roles de un proyecto, del pedido inicial a los manuales.
Software, proceso y producto
Conviene separar tres palabras que se mezclan:
- Producto: lo que va a usar una persona (el sistema, con su código y su documentación).
- Proceso: cómo se construye (etapas, roles, revisiones, entregas).
- Ingeniería de requisitos: el trabajo de descubrir, escribir y acordar qué tiene que hacer el producto.
Un requisito útil se puede comprobar. “Que sea fácil” no alcanza. “Una persona con cuenta puede recuperar una contraseña y recibe un aviso” sí se puede probar.
Propuesta, alcance e interesados
La propuesta de proyecto responde, por escrito:
- Qué problema se quiere resolver y para quién.
- Objetivos del proyecto (no solo del código).
- Alcance: qué entra y qué queda afuera.
- Registro de interesados: quién decide, quién usa, quién mantiene.
- Criterios de aceptación: cómo se va a saber que el trabajo está terminado.
- Supuestos y restricciones: plazos, datos disponibles, tecnologías que no se pueden cambiar.
Dejar por escrito las exclusiones evita que, a mitad de la cursada, el trabajo crezca sin tiempo.
Estimación, métricas y calendario
Estimar es una hipótesis, no una promesa. El plan pide trabajar tiempos, costos y métricas de software, y armar un cronograma.
Una forma concreta de practicar:
- Partir el producto en entregas chicas.
- Estimar cada entrega con el equipo, y anotar en qué se basó el número.
- Marcar hitos: qué entregable (documento o código) existe al final de cada tramo.
- Definir las iteraciones: qué entra en cada una y qué queda para después.
- Comparar, al cerrar la iteración, lo estimado contra lo que pasó. Esa diferencia es una métrica útil.
Artefactos, reportes y manuales
Además del código, el plan pide dejar rastro:
- Documentación técnica: decisiones, modelo de datos, contrato de la API, cómo se corre el proyecto.
- Reportes, indicadores y estadísticas del avance (lo hecho, lo bloqueado, lo que cambió de alcance).
- Manuales e instructivos para quien usa el sistema y para quien lo tiene que instalar o mantener.
Un repositorio con el código y sin ninguna de estas piezas no cubre la materia.
Cómo estudiarla
Armá una propuesta de una página para un sistema chico y completala con alcance, interesados, criterios de aceptación y un cronograma de tres iteraciones. Después contrastala con el Trabajo Final Integrador: esta materia es la que ordena ese proyecto.