Recientemente ojeando JavaHispano, he visto que han publicado un documento hablando de niveles de calidad de software y su inclusión, o más bien no inclusión en las metodologías de desarrollo actuales ya sean ágiles o tradicionales.
El documento ha sido escrito por Francisco Morero Peyrona y Abraham Otero (si no me equivoco con el apellido), y aunque es un texto corto (16 páginas), su lectura es interesante.
Quizás la primera parte habla de cosas que un desarrollador ya conoce y ha pensado en más de una ocasión, pero las directrices o reglas que ofreces en el apartado que ellos han nombrado como “Reglas del pulgar” son bastante interesantes. Como siempre decir que son casos generales y que luego cada uno tiene que tomar sus propias decisiones y, adaptar las cosas a su caso concreto. Con esto, me ha parecido una lectura interesante ya que le dan forma (de documento) a unas ideas que casi todos llevamos en la cabeza.
En general yo diría que mi idea sobre que nivel de calidad a aplicar es más o menos la siguiente
Si el tiempo y el presupuesto lo permite (lo decide el cliente normalmente)
Aplicar calidad de mayor a menor a
Proyectos que van a usar otros desarrolladores
Proyecto que solo van a usar los usuarios
Chapuzillas (vease aquí script, aplicaciones para automatizar cosillas puntuales,...)
Sino
Se hace lo que se puede
Está ha sido muy resumida mi regla siempre.
La verdad es que si en algo tienen razón, es en que es algo que nunca se nombra ni se hace referencia en las metodologías de software, todas ellas parecen enfocadas a alcanzar siempre la “perfección”, pero ¿de verdad merece la pena hacer siempre el esfuerzo? Esta es una muy buena reflexión.
También es cierto que debe ser difícil como mínimo tratar con un cliente y tener que especificar el nivel de calidad que se va a utilizar en un proyecto y presupuestarlo en este. Imagino que siempre es más fácil no decir nada y centrarse únicamente en la funcionalidad y la calidad, ya se verá sobre la marcha. Sobre todo porque depende de muchos factores, tiempo, imprevistos, preparación de nuestro equipo de desarrolladores, cambios de requisitos, … cosas que por lo general, no pueden ser medidas específicamente.
Y vosotros, ¿tenéis alguna regla sobre esto? ¿Aplicáis el 100% de la calidad siempre? ¿Nunca?
Os dejo el enlace al post en JavaHispano para que podáis leer el artículo:
Niveles de calidad: el agujero en las metodologías de software
Nos vemos.
Binary Coders 
Pues si. La regla tiene que ver con las pruebas y los casos de uso. Los niveles de calidad serian los siguientes.
1 PROTOTIPO I Happy path y pruebas
2 PROTOTIPO II Sad paths y pruebas
3 PREPRODUCCION I Logging y monitorización para producción
4 PREPRODUCCION II Si tenemos un juego de datos igual que en producción y podemos simular la carga crearemos indices necesarios en la bd solo cuando haga falta.
5 ENTREGA Refactoring, aplicaciones de patrones de diseño para que sea escalable y mantenible, documentacion. Si el producto lo entregamos a un tercero y paga por ello.
En primer lugar soy un fiel creyente y practicante del TDD y los Casos de Uso. El caso de uso no es ese monigote amarrado a un cirulo de UML, el caso de uso es un texto que describe que es lo que hace un programa. Si se redacta usando el modelo de Alistair Cockburn http://www.fransvandunne.com/escribe-casos-de-uso-efectivos/ , como un dialogo, nos sale un diagrama de actividad y de estados de un tirón… sabremos exactamente que métodos tendremos que implementar y que interfaces de usuario.
El punto uno (happy path) se refiere al diagrama de actividad que nos saldria del caso de uso cuando todo sale bien, p.e. reserva de un coche (el usuario pide una lista de coches disponibles, el sistema los muestra, el usuario elige uno, el sistema lo bloquea y le da un id de la operacion al usuario). Son el 80% de los casos, y requiere el 20% del esfuerzo, a veces es suficiente para algunos clientes que supervisarán manualmente el sistema.
El punto dos (sad paths) son las acciones cuando se producen errores, p.e. el coche se ha reservado ya, alguien se ha adelantado. Son el 20 % de los casos. 80% del curro, hay que pensar que hacer en esos casos. En cambio el sistema podrá funcionar sin apenas supervisión y con gran confianza.
El punto 3, logging es crear código de logging robusto para que podamos identificar la causa de un error si se produce, los niveles deberian ser FATAL, ERROR, DEBUG, INFO. El logging debe seguir un patron y diseño homogeneo, con el estado de los parametros de entrada a las funciones y la salida de invocacion de código, tambien una posible causa del error (hint) . Los objetos del dominio deben tener un toString() para pasarlos al log y se muestre su estado. El logging debe poderse cambiar en tiempo de ejecución, p.e. jmx. En el nivel FATAL y/o ERROR debe poderse ejecutar código de alerta para los administradores del sistema (sms, e-mail, etc) En el nivel INFO es donde se debe monitorizar las llamadas a otros sistemas, tiempo de ejecución, etc.
Con esto ya tendriamos hecho un sistema de alta calidad.
El punto 4 solo tiene sentido si tenemos un juego de datos como el de producción, las mismas máquinas y podemos simular la carga. De nada servirá hacer indices sobre un juego de datos ‘simulado’ que no tendrá las mismas características que el de producción, y el rendimiento depende también mucho de la máquina (memoria, discos, sistema de ficheros, red …) Lo dicho si no tenemos mismos datos y máquinas, mejor dejarlo para tunear en producción.
Por último si entregamos release, debemos dejarlo para que otros lo puedan mantener, por lo que refactorizaremos y documentaremos mientras se lo explicamos a un tercero con un code review. La documentación debe ser breve, para entender ideas a alto nivel. A bajo nivel el código debe ser tan claro como prosa.
LikeLike
Gracias por la respuesta. Casi parece un artículo. Un saludo.
LikeLike
Jaja, a lo mejor me animo y me hago un blog. El TDD ha sido mi caballo de batalla durante muchos años, pero era predicar en el desierto. Ahora parece que se toma mas en serio.
En resumidas cuentas para conseguir calidad lo primero de todo es saber que hacer, con un caso de uso bien hecho. Hacer pruebas, unitarias, las justas, ni mas ni menos.
— llegar hasta aqui ya es mucho para los estandares habituales —
Y la guinda es crear un sistema de logging robusto, lanzando las excepciones a la capa de control y que sea esta la que lo maneje. El logging es parte integral de la calidad pero por lo general se suelen escribir cadenas de texto aqui y alla, ensuciando el código sin ningún criterio.
Y por supuesto usar patrones de diseño, fachadas para aislar capas, decorators para añadir funcionalidad a las capas (logging, seguridad, etc) y codigo claro.
Nada, un saludo, me ha gustado tu blog, veo que eres un informático con vocación, pensaba que no quedaban. 😀
LikeLike