Metodologías hay montones de ellas y según se dice, algunas son adecuadas para determinados tipos de proyectos y otras para otros.
Un resumen más o menos general sería:
REQUISITOS
- Requisitos del sistema. Lista de todo lo que tiene que hacer el sistema. Deben ser claros y nada ambiguos.
ANALISIS
- Casos de uso y diagramas de secuencia desde el punto de vista del usuario. Describir sólo que mensajes da el usuario al sistema y que mensajes da el sistema al usuario.
- Diagrama de clases de negocio. Únicamente deben aparecer clases que tienen sentido para el usuario. Nada de "lista de.." ni de "array de ...". Solo "Alfil", "Torre", "Tablero", ...
DISEÑO:
- Definir arquitectura. Tratar de extraer operaciones comunes de los casos de uso para determinar qué librerías comunes, estructura de directorios, etc vamos a hacer. Es decir, cómo vamos a organizar nuestro programa en módulos. De aquí podría sacarse un diagrama de "deployment" o de clases con muchos paquetes (según la complejidad del sistema).
- Detallar casos de uso y diagramas de secuencia/colaboracion. Ya nos metemos dentro del sistema y empezamos a ver qué mensajes se mandan de una librería a otra, definir clases dentro de las librerias, etc. También irían saliendo los diagramas de clases detallados (que deberían partir del diagrama de clases que sacamos en el analisis)..
CODIFICACIÓN Y PRUEBAS.
A ello.
DESARROLLO ITERATIVO
Es importante no eternizarse en un paso para dejarlo perfecto. Vete haciéndolos todos en orden hasta que tengan "buena pinta" y fijándote plazos. Detalla primero sólo los casos de uso más importantes (que más código lle
