De la captura de requisitos a la construcción del software

En la última entrada comentaba a grandes rasgos las características de la norma ISO 15504, en esta quiero entrar en el detalle de los cuatro procesos que hemos considerado vitales para Okkum.

ENG1. Captura de requisitos del cliente

La norma intenta minimizar los riesgos de cambios, asegurar que la información que obtenemos del cliente fiable y que se satisfacerán las necesidades del cliente en los términos que se pacten. Ahí es nada. En total recoge seis buenas prácticas, nosotros nos hemos organizado de la siguiente manera, se establecerán con el cliente las funcionalidades a desarrollar y se firmará un contrato en el que queden (meridianamente) claros los requisitos, este documento deberá ser revisado en cada reunión con el cliente, para comprobar que efectivamente se va en la linea adecuada y estas reuniones deberán ser prefijadas al inicio del proyecto. Hay varias buenas prácticas que todavía no tengo claro como aplicar, pero a grandes rasgos es nuestra respuesta al modelo: un documento inicial lo más completo posible y una serie de reuniones prefijadas donde revisar los avances y tratar posibles desviaciones o cambios.

ENG4. Análisis de requisitos software

Aquí esta el quid de la cuestión, hemos acordado unos requisitos con el cliente y tenemos un documento, muy bonito. Hay que convertir estas funcionalidades, expresadas en términos del cliente, a requisitos software. Pero no basta, con eso; una vez los hemos detallado, hay que priorizarlos (pero por algún criterio), especificar como vamos a comprobar que se han realizado correctamente estas funcionalidades, establecer métodos para valorar el impacto (en tiempo, por lo tanto dinero) de los cambios que se vayan produciendo, mantener la trazabilidad de los requisitos de software con los requisitos del cliente. A mi no me gusta el exceso de documentación, así que hemos pensado en continuar trabajando como hasta ahora, tenemos muchas reuniones (más o menos formales) en las que vamos decidiendo el diseño de forma iterativa (que es la forma fina de decir sobre la marcha), pero a esta flexibilidad tenemos que dotarla de capacidad de organización y previsión.

ENG5. Diseño del software

En este proceso es especialmente importante la trazabilidad entre los requisitos y la solución propuesta, a parte de proponer en detalle la solución a nivel de diseño, es decir detallar como vamos a construir la aplicación, como se va a comunicar con otros elementos y como vamos a comprobar que lo que debería hacer es lo que hemos propuesto. Aquí de nuevo nos encontramos con dificultades, para no sobrecargarnos de trabajo de documentación. Al final, tendremos que tener una especie de mapa que nos relacione requisito de cliente, con requisito de software, con diseño y el código que hemos hecho. Para ello estamos intentando que desde el producto final, el código guardado en nuestro repositorio SVN, pueda emanar toda esta información, que se va generando en nuestras continuas reuniones del equipo de desarrollo y diseño. Por el momento usamos Trac para esta trazabilidad, pero no tenemos claro que sea una solución óptima.

ENG6. Construcción del software

¡A programar! Aunque no solo eso, hay que picar el código, pero también realizar las pruebas unitarias donde corresponda. Debemos verificar que hemos desarrollado todas los requerimientos del cliente, tal como  hayamos definido en el diseño y tratar de verificar la calidad del código. Este es el proceso fundamental, tengo la tentación de hablar sobre Muda y otros temas de calidad pero dejare que os documentéis por vuestra cuenta, sin codificación no hay software, pero sin documentación del código, trazabiidad de los requerimientos y pruebas unitarias, el mantenimiento de la aplicación puede ser insostenible y como ya he dicho, el objetivo de Okkum es producir software barato y mantenible (o sea bueno y fabricada eficazmente).

Una parte importante del aseguramiento de calidad, creo que tiene que ver con la selección y formación del personal, también con la correcta metodología de trabajo, las herramientas que se usan y en general el factor humano. El proceso es importante, pero el programa será mejor o peor en función del desarrollador, el lenguaje (y framework), el ambiente de trabajo y un muchos más intangibles*

Nota: Los procesos tal como están explicados, son una interpretación propia, supongo que expertos en la materia podrían ser mucho más precisos, pero no es mi intención documentar la norma, sino mostrar los efectos que tiene en una pyme.

* Para mi, desarrollar sobre maquinas Linux supone un factor fundamental, puesto que tenemos menos tiempos muertos por mal funcionamiento de los equipos y que cada uno de nosotros tiene libertad de provar y usar cientos de herramientas a un solo click de distancia

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s