Ejemplos java y C/linux

Tutoriales

Enlaces

Licencia

Creative Commons License
Esta obra está bajo una licencia de Creative Commons.
Para reconocer la autoría debes poner el enlace http://www.chuidiang.com

Metodología de desarrollo software

Tras leer algunos libros y buscar por internet, me da la impresión de que esto de las metodologías es algo que está todavía 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 conclusión a la que he llegado. El resultado es cosa mía, cogiendo lo que he creido mejor de lo que he leido y tratando de obtener una metodología que me resulte práctica.

FASES

Las fases en las que hay que desarrollar un proyecto, son básicamente Requisitos, análisis, diseño preliminar, diseño detallado, codificación 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:

y ahora toca aclararlos. ¿Qué es avisar de los jaques? ¿un pitido? ¿un texto "jaque" en algún sitio de la pantalla? ¿una voz que diga "jaque"? ¿Debe avisar también cuando el usuario es el que da jaque al ordenador? ...

E incluso ordenarlos. ¿Cuales son los más importantes para los usuarios? Los menos importantes se podrían dejar para el final o darles menos importancia, dedicarles menos tiempo que a los importantes. ¿Cuales son más difíciles de hacer?. Quizás debamos dedicarnos a ellos primero, para saber si vamos a ser capaces de hacerlos, o vamos a tener que dejar el programa a medias, después de haber trabajado unos meses en él. Podríamos empezar a negociar antes con el cliente para cambiar dicho requisito por otro.

ANÁLISIS

Durante el análisis vamos a definir más claramente qué es lo que va a hacer nuestro programa. Debemos hacer varias cosas principalmente:

DISEÑO PRELIMINAR

Aquí ya empezamos a pensar en cómo vamos a hacer las cosas.

En el diseño preliminar tratamos de establecer la arquitectura de nuestro programa. La arquitectura es un esquema de en qué módulos/paquetes vamos a dividir nuestro programa, qué librerías. Si el programa es suficientemente grande, quizás vaya en varios ejecutables, una arquitectura cliente/servidor, etc.

Viendo los casos de usos, deberíamos ver qué cosas podemos hacer comunes o como librerias aparte, que podamos reutilizar. Por ejemplo, en nuestro caso del juego de ajedrez, podríamos hacer los siguientes paquetes:

Dentro de estos paquetes, podemos ir pensando más subpaquetes, etc.

En este punto y con los casos de uso en general, debemos tener cuidado. Según una crítica generalizada a los casos de uso, estos llevan a un diseño funcional y no a uno orientado a objetos. Debemos tratar de pensar en objetos y almacenarlos juntos en la misma librería cuando estén 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. Según 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.

DISEÑO DETALLADO

En el diseño detallado ya se entra a nivel de clases y métodos. 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 métodos que van a tener. Detallamos aun más los casos de uso y las interfaces de las clases.

En este punto pueden ser de ayuda los patrones de diseño. La gente que ha ido diseñando a lo largo de la historia, se ha encontrado con problemas (¿cómo 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 sólo 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 más leer algo sobre patrones de diseño orientados a objetos para tener una lista de "soluciones" a aplicar.

Hay incluso patrones a nivel de arquitectura. Es bastante conocido, por ejemplo, el patrón separación modelo-vista. En nuestro caso "modelo" sería el conjunto de clases que juegan al ajedrez. "Vista" sería el conjunto de clases que "pintan" la partida en la pantalla. Hacer esa separación en dos módulos, hace que nuestro módulo 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 sólo la "vista" vea al "modelo" y nunca al revés. Si lo hacemos al revés y queremos llevarnos nuestro "modelo" juego de ajedrez, tendremos que llevarnos también parte de la "vista".

IMPLEMENTACIÓN Y PRUEBAS

Pues a ello. Hay muchas cosas que se podrían contar aquí, pero no son de diseño.

De las pruebas podemos decir que hay que escribir los "casos de prueba". Básicamente son como la descripción 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 metodologías 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 diseño, un poco de codificación y pruebas y vuelta a empezar.

Hay varios motivos para realizar esto así:

En la página de los libros tienes algunos sobre este tema. Entre los libros tienes el del "Proceso unificado de desarrollo software" (RUP en inglés). Hay un resumen de ese libro en http://www.cs.ualberta.ca/~pfiguero/soo/metod/uml-met.html que también explica los diagramas de UML

La programación extrema es otra metodología que se sale un poco de este resumen.

Estadísticas y comentarios

Numero de visitas desde el 4 Feb 2007: