El Blog de Pablo Fernando Sanchez

Luego de haber respondido a algunas preguntas que planteó Ángel en esta entrada en la que conté acerca de RCL, el proyecto del IEEE que busca desarrollar un lenguaje estándar para la captura de requerimientos bajo el código IEEE P1805™, y habiendo recabado más información, escribo esta entrada para ampliar el asunto.

Ampliemos. El propósito del resultado final de este proyecto de estandarización, la mencionada guía estándar "Guide for Requirements Capture Language (RCL)", es:

• Definir un nuevo lenguaje, el mencionado RCL, para la captura de requerimientos de TI.
• Facilitar la estimación automática del tamaño de los requerimientos luego de finalizada su captura mediante el empleo de la técnica de Puntos de Función.
• Mostrar que la captura de los requerimientos basada en una estructura de árbol es lo que mejor se ajusta a la captura de requerimientos de TI debido a que está más cerca a cómo se estructura el mundo que nos rodea —es por ello que se necesita un nuevo lenguaje.
• Estandarizar la estructura de árbol de tal forma que sea compatible con Puntos de Función, es decir, que sea posible aplicar la técnica de Puntos de Función sobre los elementos del árbol una vez finalizada la captura de los requerimientos.
• Permitir la captura de requerimientos tanto funcionales como no funcionales dentro de la estructura del lenguaje.
• Permitir la captura de la dinámica del sistema, como eventos y lógica, dentro del mismo árbol.
• Permitir un análisis rápido de impacto para así poder tomar decisiones inmediata y correctamente.
• Permitir el versionado de requerimientos a medida que la captura vaya progresando por su cuenta como una estructura de árbol.
• Permitir la traducción de RCL a otros estándares como diagramas UML.
• Asegurar que este árbol de requerimientos sea "a prueba del futuro" en la medida en que se pueda mejorar fácilmente mediante la posterior inclusión de nuevas capturas de requerimientos, tanto por la evolución propia del sistema como por la ampliación del alcance, hasta llegar a cubrir la totalidad de la organización o empresa —con requerimientos que no sean de TI además de los de TI.

O sea, en un futuro se espera que el lenguaje evolucione hacia un nivel estratégico para que sea capaz de capturar desde la misión del negocio, las oportunidades y las amenazas, las decisiones, la visión, las jerarquías entre la gente, los sitemas de TI —que es el alcance actual—, los procesos manuales, eventos y todo otro requerimiento que posiblemente pueda surgir dentro de la organización.

Ángel también me preguntó sobre la fecha en que este estándar estará disponible. Contesté que "seguirá el camino estandarizado del proceso de estandarización del IEEE, valga la redundancia. Esto es que posiblemente haya un borrador el año entrante, algunas evoluciones y una liberación definitiva para 2012. En estos días voy a escribir sobre dicho proceso, para que quede más claro el por qué de los tiempos".

Los mantendré al tanto, a la vez que pronto escribiré sobre el citado proceso de estandarización del IEEE.

Sí señoras y señores, nuevamente The Institute of Electrical and Electronics Engineers (el IEEE) en la coordinación de un proyecto que, sin lugar a dudas, nos terminará dando una herramienta más que necesaria para quienes estamos de alguna forma en la industria del software.

Resulta que la IEEE Standards Association aprobó que se comience a trabajar en el proyecto IEEE P1805™, "Guide for Requirements Capture Language (RCL)" —o "Guía para Lenguaje de Captura de Requerimientos". Dicho proyecto cuenta con el patrocinio del Software & Systems Engineering Standards Committee (S2ESC) de la IEEE Computer Society. Su intención es que, cuando el proyecto sea finalmente liberado como estándar, ayude a facilitar la estimación automática del tamaño del software.

RCL es un concepto novedoso que apunta a proveer un medio efectivo para trasferir la perspectiva de negocios a los equipos que trabajan del lado tecnológico del desarrollo. Una vez completa, la guía aplicará para escenarios en los que se necesite:

• capturar requerimientos de TI para la creación o el mantenimiento de sistemas basados en software;
• transferir la perspectiva de negocios en forma rápida, fluida, completa y clara entre los grupos de negocios y los departamentos y/o empresas de servicios de TI; y
• establecer en forma automática el tamaño de los requerimientos de TI una vez concluida su captura, empleando la técnica de Puntos de Función y, en consecuencia, permitiendo agilidad en los procesos de estimación de tamaño y esfuerzo al comienzo del ciclo de vida.

La información correspondiente a RCL será presentada en una estructura de árbol, la cual se ajustará a las necesidades de los requerimientos de TI mejor que los otros sistemas empleados en la actualidad.

Al margen de la noticia, creo que es interesante pues permitiría romper con algunas de las críticas típicas que se le hacen a las técnicas de estimación como la de Puntos de Función, la cual por el momento es especialmente adecuada para desarrollos de gran envergadura y empleando métodos conducidos por plan, como ser que:

• requiera una dedicación adicional en los proyectos de desarrollo de software,
• resulte arduo formar al personal en su utilización,
• resulte arduo mantener unos criterios homogéneos de recuento,
  
• carezca de precisión cuando se trata de proyectos pequeños,
• resulte muy costoso tener recontada la mayor parte de la base instalada de la organización o
  
• el factor de ajuste calculado a partir de las características generales del sistema resulte de dudosa utilidad, entre otras.
  

Si vemos estas críticas y las contrastamos con la idea de contar con un estándar real, formalizado y con el consenso de la industria, como será RCL, creo que podríamos ir superándolas, así como extender la aplicación de este estándar a un rango metodológico superior. Ya veremos en sucesivos avances cuánto podremos abarcar de dicho espectro con este estándar.

Ya escribí en este blog sobre extender los modelos que nos dan ejemplos de procesos y prácticas a nivel organizacional, como el CMMI, con modelos de un nivel más bajo que provean detalles específicos para los desarrolladores de software y los equipos que ellos integran, y creo que RCL es un caso de muy bajo nivel que podría aplicarse a dicho planteo.