Metodologa de desarrollo software

Tras leer algunos libros y buscar por internet, me da la impresin de que esto de las
metodologas es algo que est todava un poco verde. Hay montones de ellas y cada
"gur" tiene la suya. Sin embargo, casi todas ellas tienen muchas cosas comunes, as que
aqu tratar de resumir la conclusin a la que he llegado. El resultado es cosa ma,
cogiendo lo que he creido mejor de lo que he leido y tratando de obtener una metodologa
que me resulte prctica.
FASES
Las fases en las que hay que desarrollar un proyecto, son bsicamente Requisitos,
anlisis, diseo preliminar, diseo detallado, codificacin y pruebas. Voy a detallar estas
fases con un ejemplo, suponiendo que quiero hacer un programa para jugar al ajedrez.
REQUISITOS
Los requisitos son una lista de cosas que queremos que haga nuestro programa. Lo
normal es que recopilemos dicha lista hablando con todas las personas que podamos:
usuarios de nuestro programa, expertos en el tema de que trata el programa (ajedrez),
etc, etc.
Normalmente la gente con la que hablemos nos dar los requisitos de una forma vaga y
desordenada. Es labor nuestra ordenarlos (por temas, por dificultad, por importancia para
los usuarios, etc) y asegurarnos de que son claros.
Para asegurarnos de que un requisito es claro, debemos saber qu persona lo ha
propuesto y por qu lo ha propuesto, qu es lo que cree exactamente que vamos a hacer
en nuestro programa cuando nos ha dicho ese requisito.
Por ejemplo, unos cuantos requisitos para nuestro programa de ajedrez pueden ser:
Que avise de los jaques
Que el movimiento de las piezas del tablero sea suave
Que tarde menos de 30 segundos en "pensar" un movimiento
Si el usuario no sabe qu mover, que pueda pedirle ayuda al ordenador.
Que pueda aprender aperturas que se le introduzcan.
Que guarde las partidas en una base de datos.
...
y ahora toca aclararlos. Qu es avisar de los jaques? un pitido? un texto "jaque" en
algn sitio de la pantalla? una voz que diga "jaque"? Debe avisar tambin cuando el
usuario es el que da jaque al ordenador? ...
E incluso ordenarlos. Cuales son los ms importantes para los usuarios? Los menos
importantes se podran dejar para el final o darles menos importancia, dedicarles menos
tiempo que a los importantes. Cuales son ms difciles de hacer?. Quizs debamos
dedicarnos a ellos primero, para saber si vamos a ser capaces de hacerlos, o vamos a
tener que dejar el programa a medias, despus de haber trabajado unos meses en l.
Podramos empezar a negociar antes con el cliente para cambiar dicho requisito por otro.
ANLISIS
Durante el anlisis vamos a definir ms claramente qu es lo que va a hacer nuestro
programa. Debemos hacer varias cosas principalmente:
Identificar actores. En lenguaje UML, actores son los usuarios y cualesquiera
otros sistemas con los que se pueda comunicar nuestro programa. En nuestro
programa de ajedrez, un actor sera el usuario que va a jugar al ajedrez. Le
llamaremos "jugador". Tambin se indicaba como requisito que pueda aprender
aperturas. La persona que le va a ensear aperturas a nuestro programa podra
ser otro actor, al que podemos llamar "maestro". Una misma persona puede ser
varios actores. Por ejemplo si alguien compra nuestro programa de ajedrez, a
veces puede jugar y otras veces puede ensearle aperturas. Es la misma persona,
pero el papel que desempea en cada caso es distinto.
Identificar casos de uso. Un caso de uso es algo que un actor quiera hacer con
nuestro sistema. Por ejemplo, un caso de uso para un "jugador" es "jugar una
partida". Est claro que el jugador quiere nuestro programa para jugar una partida
de ajedrez. Otro posible caso de uso es "anlisis de un tablero". El "jugador" pone
las piezas en determinada posicin y quiere que el ordenador le d una lista de
posibles movimientos, etc, etc. En resumen, debemos obtener una lista de cosas
que los actores van a querer hacer con nuestro sistema. Deben ser cosas grandes
y no meternos en los detalles. "Mover una pieza" no sera un caso de uso, sino
una parte de "jugar una partida". De aqu saldra un diagrama UML de casos de
uso.
Detallar casos de uso. En un texto vamos poniendo varios puntos. En cada punto
ponemos sentencias del estilo "el usuario hace tal cosa y el programa hace tal
otra". Es decir, explicamos por escrito, desde el punto de vista del usuario, qu es
lo que tiene que hacer y qu es lo que va a hacer el ordenador. Por ejemplo, para
"jugar una partida"
o El usuario indica que quiere jugar una partida. El programa le pregunta el
color de las piezas con las que quiere jugar
o El usuario elige el color. El programa le dibuja el tablero con las piezas
colocadas en la posicin inicial. Las piezas del usuario en la parte inferior
de la pantalla. Si el programa tiene blancas, piensa y realiza el primer
movimiento.
o El usuario mueve su pieza. El programa comprueba que el movimiento es
correcto, piensa y realiza su propio movimiento.
o Se repite el paso anterior hasta llegar a jaque mate o tablas.
En el caso de uso se detalla una situacin normal, sin fallos ni situaciones raras. Al
final debera ponerse una pequea lista con los posibles fallos o situaciones
anmales.
o Si el movimiento del ordenador pone en jaque al usuario, el ordenador
avisa del jaque
o Si el usuario intenta un movimiento incorrecto, el ordenador avisa y deja al
usuario que vuelva a intentarlo
Advertir que en ningn caso nos hemos metido a detallar cmo va a hacer algo
nuestro programa, slamente qu es lo que va a hacer.
Siguiendo los esquemas UML, podemos incluso hacer por cada caso de uso un
diagrama de secuencia en el que los objetos implicados son el actor (el "jugador")
y nuestro programa, sin meternos dentro de l.
Tambin en este paso podemos ir empezando a pensar en cmo van a ser las
pantallas de la interface de usuario, de nuestro programa.
Diagrama de clases del negocio. Es un diagrama de clases de objetos que
tienen sentido para el usuario. En el caso del ajedrez los objetos seran del estilo
"tablero", "pieza blanca", "torre blanca", "jugador", "cronmetro", "partida", "torneo"
etc. Nunca "lista de piezas", "array de casillas", etc. Tambin se presentan las
relaciones entre ellos, como "las piezas estn en el tablero", "la torre blanca es
una pieza blanca", etc.
Este diagrama a este nivel tiene dos utilidades:
o Asegurar que los que saben del tema y los que hacen el programa estn
hablando de lo mismo.
o Servir de base para el diseo detallado orientado a objetos.
Cuando el tema es ms complejo o menos conocido que una partida de ajedrez,
es posible que el informtico que programa no tenga muy claros muchos de los
conceptos que tiene que manejar. No sabe qu es un asiento contable, un
balance, si hay relacin entre ellos, etc. Es por eso importante hacer un diagrama
de este tipo, en conjunto con un experto o con el cliente, para asegurar que no hay
malentendidos.
DISEO PRELIMINAR
Aqu ya empezamos a pensar en cmo vamos a hacer las cosas.
En el diseo preliminar tratamos de establecer la arquitectura de nuestro programa. La
arquitectura es un esquema de en qu mdulos/paquetes vamos a dividir nuestro
programa, qu libreras. Si el programa es suficientemente grande, quizs vaya en varios
ejecutables, una arquitectura cliente/servidor, etc.
Viendo los casos de usos, deberamos ver qu cosas podemos hacer comunes o como
librerias aparte, que podamos reutilizar. Por ejemplo, en nuestro caso del juego de
ajedrez, podramos hacer los siguientes paquetes:
Paquete de ajedrez. Un paquete que sea capaz de jugar al ajedrez, pero sin
ningn tipo de relacin con las pantallas. Si es una clase, tendra mtodos del
estilo "Poner_Piezas_Posicin_Inicial()", "Mover_Pieza()",
"Dame_Siguiente_Movimiento()", etc, etc. Slo con este paquete, seramos
capaces de jugar al ajedrez, o de instanciar dos paquetes y hacer que jueguen
entre ellos, o jugar en red, etc.
Interface con el usuario. Un paquete con el dibujo del tablero, las piezas, recoger
los movimientos del usuario etc.
Dentro de estos paquetes, podemos ir pensando ms subpaquetes, etc.
En este punto y con los casos de uso en general, debemos tener cuidado. Segn una
crtica generalizada a los casos de uso, estos llevan a un diseo funcional y no a uno
orientado a objetos. Debemos tratar de pensar en objetos y almacenarlos juntos en la
misma librera cuando estn muy relacionados entre s, no en funciones. Por ello es
buena idea tratar de agrupar las clases del diagrama de clases del negocio en paquetes y
tratar de desarrollar la arquitectura a partir de ellas.
Es importante en este paso definir las interfaces y relaciones entre paquetes. Para ello
puede servir de ayuda hacer los diagramas de secuencia de los casos de uso mostrando
los actores, los paquetes y los mensajes entre ellos. Segn vayan creciendo los
diagramas de secuencia por aquello de ir entrando en detalles, podremos ir extrayendo
subcasos de uso, como "mover pieza", "elegir color", etc.
DISEO DETALLADO
En el diseo detallado ya se entra a nivel de clases y mtodos. Por cada paquete que
hayamos extraido en el paso anterior y siguiendo siempre los casos de uso, debemos ir
detallando las clases que vamos a implementar y los mtodos que van a tener.
Detallamos aun ms los casos de uso y las interfaces de las clases.
En este punto pueden ser de ayuda los patrones de diseo. La gente que ha ido
diseando a lo largo de la historia, se ha encontrado con problemas (cmo hago que la
clase A se entere que la clase B ha cambiado sin necesidad de que B vea a A?, En qu
clase pongo el metodo que suma las clases A y B? Como me aseguro que de esta clase
slo se haga una instancia?, etc, etc). Algunos de dichos problemas salen con mucha
frecuencia (como los indicados de ejemplo) y se han establecido soluciones "estandard",
que funcionan bien. Dichas soluciones se llaman patrones. No est de ms leer algo
sobre patrones de diseo orientados a objetos para tener una lista de "soluciones" a
aplicar.
Hay incluso patrones a nivel de arquitectura. Es bastante conocido, por ejemplo, el patrn
separacin modelo-vista. En nuestro caso "modelo" sera el conjunto de clases que
juegan al ajedrez. "Vista" sera el conjunto de clases que "pintan" la partida en la pantalla.
Hacer esa separacin en dos mdulos, hace que nuestro mdulo de ajedrez sea
reaprovechable, incluso si cambiamos de entorno de ventanas (de windows a ms-dos o
de ms-dos a unix). Eso s, es imprescindible que slo la "vista" vea al "modelo" y nunca al
revs. Si lo hacemos al revs y queremos llevarnos nuestro "modelo" juego de ajedrez,
tendremos que llevarnos tambin parte de la "vista".
IMPLEMENTACIN Y PRUEBAS
Pues a ello. Hay muchas cosas que se podran contar aqu, pero no son de diseo.
De las pruebas podemos decir que hay que escribir los "casos de prueba". Bsicamente
son como la descripcin de los casos de uso, pero indicando datos concretos que el
operador va a introducir y qu resultados exactos debe dar nuestro programa.
DESARROLLO ITERATIVO E INCREMENTAL
En casi todas las metodologas que he leido, se habla de hacer el sistema en varias
iteraciones. Es decir, hacer un poco de requisitos, un poco de analisis, un poco de diseo,
un poco de codificacin y pruebas y vuelta a empezar.
Hay varios motivos para realizar esto as:
No eternizarse en un paso. Por mucho anlisis que hagamos, nunca estaremos
seguros de haber acabado y siempre se nos ocurriran ms cosas. Idem para el
diseo. Siguiendo este mtodo, nos fijaramos unos plazos para cada cosa y
haramos lo siguiente:
o Obtener los mximos requisitos posibles en el tiempo fijado. Ordenarlos y
fijarnos en los ms importantes.
o Obtener los mximos casos de uso y actores posibles. Ordenarlos por
importancia (ms importantes para el usuario, ms dificiles de implementar
o que ayuden a definir lo mximo posible la arquitectura) y detallar slo los
primeros en la lista.
o Obtener la arquitectura para esos primeros casos de uso.
o Diseo detallado para esos primeros casos de uso, siempre con un plazo.
o Codificar y probar.
o Vuelta a empezar con los requisitos (han cambiado?, hay nuevos?), los
casos de uso (buscar ms casos de uso, detallar los siguientes en
importancia), etc, etc.
Cada uno de estos pasos hay que detenerlo cuando creamos que tenemos algo
que puede funcionar. No hay que tratar de dejarlo perfecto. Cada vez que
pasemos al siguiente paso, encontraremos fallos en el paso anterior. Hay que ir
arreglndolos de forma que al final todo quede coherente.
Ir haciendo versiones intermedias de nuestro programa. Cuando hayamos
implementado varios casos de uso (que son los ms importantes), podemos hacer
una versin para ensear al cliente. Es mejor que ponga las pegas y sugerencias
ahora que no cuando ya lo hayamos terminado todo. Este punto es especialmente
til cuando el cliente no sabe muy bien qu es lo que quiere.
En la pgina de los libros tienes algunos sobre este tema. Entre los libros tienes el del
"Proceso unificado de desarrollo software" (RUP en ingls). Hay un resumen de ese libro
en http://www.cs.ualberta.ca/~pfiguero/soo/metod/uml-met.html que tambin explica los
diagramas de UML
La programacin extrema es otra metodologa que se sale un poco de este resumen.