Desde hace mucho tiempo escuchamos hablar sobre la bendita Orientación a Objetos. Si programamos en .NET o Java, hacemos uso de la POO (Programación Orientada a Objetos), entonces sino hacemos un AOO (Análisis Orientado a Objetos) que continúe con un DOO (Diseño Orientado a Objetos) como podríamos terminar en una correcta Programación Orientada a Objetos???

A continuación propondré, 10 pasos para hacer que esta secuencia se cumpla, para ello es necesario utilizar la notación UML, de manera que podamos representar de forma correcta las etapas de nuestro desarrollo (esto es solo un resúmen propuesto, algo así como un RUP ultra ultra ultra ligth).

  1. Realizar un Diagrama de Casos de Uso. Este paso es sencillo, hay que tener en cuenta que cada Caso de Uso representa una funcionalidad del software (o sea que terminará siendo alguna web page o formulario según sea el caso) que vamos a construir, de manera que ,tantos casos de Uso tengamos debemos plasmarlos en alguna pantalla de nuestro software.
  2. Priorizar los Casos de Uso a trabajar. Pongamos los casos de uso en una lista colocando los mas importantes al inicio y los menos importantes al final. Ojo, para el cliente, todos son importantes pero hay que darle un número de orden a cada Caso de Uso y tratemos de hacer los casos de uso por partes, es decir, primero hacemos los 5 o 10 primeros y despues los 5 o 10 siguientes y despues los que siguen…. esto se llama iteraciones. Es decir que nuestro desarrollo será por iteraciones y cuantas iteraciones hagamos dependerá de cuantos requerimientos tengamos, pero de esto hay que advertirle al cliente, para ir entregando el proyceto por partes, además que el desarrollo mejora, el cliente va usando las opciones que desea con menos tiempo de espera.
  3. Generar los Documentos de Caso de Uso. Un diagrama de Casos de Uso, no sirve si no viene acompañado de un Documento que describa lo que hace el Caso de Uso. Ese documento debe ser generado por el Analista del proyecto y debe tener mas o menos la siguiente estructura:
    • Descripción Breve. De lo que hace el Caso de Uso.
    • Precondiciones. Condiciones que deben ser cumplidads antes de ejecutar el Caso de Uso.
    • Flujo Básico. Descripción paso a paso de las acciones a realizar por el Usuario cuando trabaja de forma correcta en este Caso de Uso.
    • Flujo Alternativo. Detalle de los pasos que seguirá el usuario cuando no trabaje de forma correcta en este requerimiento, ejemplo: validaciones, etc.
    • PostCondiciones. Las acciones que se deben realizar despues de que se ha terminado de ejecutar el Caso de Uso.
    • Interfaz Gráfica. Prototipo de como debe quedar la pantalla del caso de uso para ser vista por los usuarios.
  4. Generar los Diagramas de Secuencia. Los diagramas de Secuencia de UML permiten conocer la forma en la que los objetos se comunicarán en una pantalla (Web Page, Formulario, Requerimiento o Caso de Uso, como prefieran llamarle) para cumplir su objetivo. Aunque no es indispensable hacer este gráfico es muy recomendable pues ayuda a entender como se comunicarán los diferentes objetos entre sí. Esta labor ayudará también a que el Arquitecto de Software comprenda mejor lo que debe hacer.
  5. Diseñar el FrameWork del proyecto. Esto significa que el Arquitecto de Software del proyecto hará su trabajo, el cual consiste en diseñar las clases que se usarán en todo el Software. Este trabajo es bastante delicado ya que el mal diseño de las clases involucra que no se programen las funcionalidades de cada clase de forma correcta. Esto conllevará a escribir un “Spaghetti Code”, que signifca que el código estará enredado (para ser mas simples). Esta etapa de diseño además debe ser revisada con cuidado y si es posible utilizar algún Patrón de Diseño de Software, pues en buena hora, hay que aplicarlo.
  6. Creación de la Base de Datos. El diagrama de Clases de UML puede servir como Base para el diseño de la Base de Datos del proyecto, claro, solo utilizando la Capa de Datos, es decir, las clases de estereotipo Entidad.
  7. Construir la máscara de nuestro WebSite o Aplicación Windows. Mientras los pasos 4, 5 y 6 se estan realizando, un poco aparte, el personal a cargo del Diseño del Sistema, sobretodo en el caso del diseño web, pueden ir desarrollando las plantillas para la creación de las páginas web ayudándose de los gráficos de las GUI’s que se encuentran en los Documentos de Casos de Uso.
  8. Programar las funcionalidades de los Casos de Uso. Una vez estén terminadas las clases, entonces se empezará a programar las funcionalidades de los Casos de Uso, para ello los programadores tomarán como referencia los documentos de Casos de Uso que el o los analistas desarrollaron y basándose en el Diagrama de Secuencia y en las clases diseñadas por el Arquitecto escribirán el código necesario para que esta opción, osea el caso de uso funcione.
  9. Probar los Requerimientos del Software. Aunque el Documento de Casos de Uso muestre detalladamente la forma en la que debe funcionar el requerimiento y pese a los diagramas y todo, siempre se escaparán algunos detalles que se deben corregir en una etapa de pruebas exhaustivas, pero estas etapas no deben ser hechos por las personas que programaron los Casos de Uso, es mucho mejor que lo haga otra persona.
  10. Integrar los requerimientos concluidos. Ahora si, despues de esto, ya es momento de unir lo que se hizo (es lo mas probable porque el código no lo escribe un solo programador, no normalmente) y ponerlo a disposición de los usuarios.

De los pasos 3 al 10 se deben repetir por cada iteración que se haya programado para el proyecto, así podremos controlarlo. La etapa de análisis está entre los pasos 1 al 4, la etapa de diseño esta entre la etapa 5 y 6, la programación la podremos ver en los pasos 8 y 9 y la puesta en marcha en el paso 10.

Bien, como ya habíamos comentado, esto es una versión Super Light de metodología, pero es válida ya que se respetan ciertas acciones básicas…..

Espero que sirva para sus proyectos, saludos.