Mientras que existen métodos para analizar y evaluar arquitecturas, tales como SAAM, ATAM, CBAM, QAW. Los diseñadores y arquitectos (y también los encargados de la calidad del software) necesitan hacer ZOOM a los diseños para revisar sin son viables estas estrategias tempranas de diseño.
Estas estrategias iniciales son pobremente documentadas y diagramadas, y presentan una falta de detalles importantes que indiscutiblemente surgirán en etapas posteriores (les parece conocido….. Es que en la vida no todo es bolear código). Eso sin contar con que la documentación solo se hace como para cumplir un requisito y no se mantiene una constante actualización que permita minimizar los tiempos de empalme y de “curva de aprendizaje” a la cual le tienen tanto miedo. Aunque no crean, en mi mas humilde opinión, el fracaso de la mayoría de los proyectos de desarrollo se debe al miedo al cambio, adopción de la tecnología adecuada (por la “curva de aprendizaje”) y a la indispensabilidad (o poca comunicación en el equipo de trabajo), esto ultimo se resume a una frase que ya he escuchado en varios proyectos y que es síntoma de una mala gestión y de una mala comunicación en el equipo, “Es que el único que sabe de eso es perengano”, o “Es que yo soy el único que puede hacer eso” (que pasa si se incapacita, se acaba el proyecto?).
Pero me desvié mucho del tema (La buena gestión de proyecto es otro tema mucho mas largo que discutir). Retomando la pobre documentación en el diseño inicial, la revisión del diseño en etapas tempranas puede descubrir importantes inconsistencias en donde una corrección temprana de estas puede ser invaluable para el proyecto. Si lo vemos en plata, es menos tiempo, pero yo lo veo mas como las trasnochadas de los desarrolladores, la mala fama ante los clientes, las inconformidades en las entregas y la mejora en la estimación de los SPRINTS (con T).
Para solventar este problema, el SEI (Software Engineering Institute) ha trabajado en un método llamado ARID (por Active Reviews for Intermediate Designs) complementario a las revisiones de arquitectura. Este permite asegurar diseño detallados de alta calidad en el desarrollo de software. Como lo cita el SEI en http://www.sei.cmu.edu/architecture/arid.html; “El método asegura participación activa de los revisores cuestionándolos a utilizar el diseño en una serie de ejercicios, mientras que se evitan las preguntas SI/NO que son fácilmente de contestar para el revisor con respuestas no muy claras y a la ligera”. Por esto, se prueba un diseño de forma real y no fingido.
Como una introducción a ARID, muestro estos 4 grandes pasos:
- Se deben identificar los revisores. Se recomienda que sean los encargados de utilizar el diseño, si son diferentes a los diseñadores.
- Se prepara una breve explicación del diseño (por parte del diseñador). Se presenta a los revisores y hace explicación completa de los ejercicios usando el diseño.
- Los revisores realizan una tormenta de ideas para usar el diseño para resolver los problemas que esperan enfrentar. Se priorizan los escenarios, y se define como se puede utilizar el diseño en el escenario. Si el diseño trabaja bien para los escenarios definidos, entonces se acuerda que el diseño ha pasado la revisión.
- Los revisores realizan pseudo-código donde usen servicios del diseño para los escenarios de mas alta prioridad. Y se almacenan los problemas, inconvenientes y lugares que son difíciles de pasar.
Igual a las sesiones JAD, este método puede ser difícil de implementar en empresas donde los proyectos son pequeños, donde no existen muchos revisores (Creo que por ese muro mental que se tienen a las revisiones en grupo). Y donde los diseños se saquen a la ligera por el afán de escribir código. Pero puede ser una herramienta fuerte para la detección de problemas tempranos, y sobre todo a ver si utilizamos el titulo de Ingenieros para algo diferente a bolear código.
posted by Unknown @ 11:07 a. m.
0 Comments:
Publicar un comentario
<< Home