archivo

Archivos diarios: julio 4, 2011

Después de participar en proyectos de desarrollo de software donde se pretenden conseguir objetivos faraónicos, puedo asegurar que lo mejor es enfocarlos como una carrera a largo plazo e ir conformándonos con una evolución del producto desde sus funcionalidades más básicas.

Ir a por todas desde el principio difícilmente producirá buenos resultados, tendrá unos niveles aceptables de calidad, se desarrollará en plazo y dentro del presupuesto establecido (crisis del software).

Sobre este tema he escrito otros artículos como por ejemplo: “Desarrollo de software. Desde la simplicidad” o “Ley de Zawinski“.

Una frase que he leído en el blog de Jim Highsmith y que es originaria de los fundadores de la empresa 37signals me parece rotunda en este sentido:

“Todo el mundo intenta hacer demasiadas cosas: solucionar muchos problemas, construir productos con muchas funcionalidades. Nosotros decimos no a casi todo. Si incluyes cada idea decente que se te ocurre, terminarás con una versión a medias de tu producto”.

Hace poco leí que de la misma manera que el mapa de una ciudad no es la ciudad, un diagrama de casos de uso no pueden sustituir a la descripción de los mismos.

La descripción de sus escenarios es lo realmente importante, aunque los diagramas proporcionan un apoyo importante para entenderlos.

Los casos de uso van un paso más allá de los requisitos, ya que representa interacciones entre el sistema y los actores y si se quiere que sean de utilidad deben poder ser entendidos por usuarios, aunque estos necesiten el apoyo de personal técnico, de los diagramas de casos de uso y de los diagramas de flujo que se puedan obtener a partir de la definición de las secuencias de pasos de sus escenarios.

Si la definición de casos de uso no se entiende, no sirve. Mucho esfuerzo para nada.

Mark A. Ardis es un profesor universitario americano especializado en el área de la ingeniería del software. Cuenta con una importante experiencia académica en diferentes instituciones universitarias americanas, además de haber trabajado en el pasado como contratista de determinados departamentos del gobierno americano y formar parte del área de investigación en Bell Laboratories.

Una cita de este autor, constituye el “One Page Principle” y viene a decir que: “Una {especificación, diseño, procedimiento, plan de pruebas} que no se ajuste a una página de de 8.5 por 11 pulgadas no puede ser comprendida”.

Para conseguir ese objetivo es necesario descomponer en unidades más simples cada uno de esos entregables y centrarse en describirlos de una manera clara y concisa.