lunes, 1 de diciembre de 2014

De los puntos función a los requisitos y tiro porque me toca

Los Puntos Función presentan posibilidades de uso que podrían resultar sorprendentes. Además de su uso principal para determinar el tamaño funcional de un desarrollo software tienen usos adicionales de cierta relevancia que podrían aportar un impulso considerable a los Puntos Función.
 
Un problema que se presenta con demasiada frecuencia en sistemas software en producción es la carencia total o parcial de la descripción de estos productos en términos de una especificación de requisitos. A esta carencia se suman, entre otras anomalías, lacalidad de la especificación que pudiera haber y la predisposición limitada para abordar estos problemas. Estas circunstancias tienen consecuencias importantes en lo que se refiere al mantenimiento del sistema software en producción.

Parte de la solución podría estar delante de nuestros ojos. Se trataría de aprovechar y complementar el trabajo que se realiza al valorar el tamaño funcional del producto software en Puntos Función buscando la simbiosis, entre ambas disciplinas del software, sacando provecho de la situación.

Y de igual forma que en el juego de la oca, cuando nos encontramos con una casilla en la que hay una oca (los Puntos Función), podemos dar un salto en el juego, sin apenas esfuerzo, y avanzar hasta la siguiente casilla de la oca (que es la gestión de requisitos) o viceversa.
 
La simbiosis es la asociación de individuos animales o vegetales de diferentes especies, sobre todo si los simbiontes sacan provecho de la vida en común.

Ya se ha hablado en anteriores entradas en este blog de lo útiles que son los puntos función para dimensionar las actividades del proceso de prueba (ver "la llave"), pero además, esa misma llave nos permite buscar una simbiosis entre un resultado intermedio de la determinación del tamaño funcional software y la gestión de requisitos.

Una especificación de requisitos es una fuente para la estimación del proceso de desarrollo. En realidad no es una fuente, es “la” fuente. Los procesos orientados al producto de diseño, construcción y pruebas intercambian información con el proceso de requisitos para su desarrollo y consolidación a lo largo de ciclo de vida de desarrollo. Los distintos procesos utilizarán el resultado de un proceso anterior para el desarrollo del producto específico (i.e. el proceso de diseño utilizará la especificación de requisitos para desarrollar los productos de diseño, la construcción utilizará el diseño para generar el código que lo implementa y el proceso de prueba utilizará los resultados de todos los procesos como bases de las pruebas para evaluarlos).

Hay una cadena (secuencial o iterativa) de entradas, procesos y salidas que dan como resultado final un producto prestando un servicio en un entorno. Normalmente, se utiliza el resultado de la estimación para planificar el proceso de desarrollo y consecuentemente, hacer un seguimiento y control del mismo. Sin embargo, hay resultados intermedios de la estimación que permitirían un intercambio con el proceso de IR a efectos de educción, consolidación y estructuración de los requisitos.

En esta entrada se propone el uso del soporte de la estimación con la técnica de puntos función para el apoyo mutuo, entre la estimación y la Ingeniería de Requisitos para:

· La educción (“elicitation”) de requisitos.

· La estructuración de los requisitos funcionales.

· La evaluación de la completitud de los requisitos funcionales.

Se puede partir de una situación razonablemente realista, se cuenta con un proyecto que dispone de una especificación de requisitos de usuario, desarrollada por el cliente, en lenguaje natural, de calidad desconocida y de estructuración limitada. Tanto la estimación inicial como la especificación de requisitos software se realizaran a partir de esta especificación de requisitos de usuario. En un escenario normal, podría ocurrir que esta especificación de requisitos de usuario sirviera de insumo para dos productos con contenidos parcialmente independientes. En general, la especificación de requisitos software y sus modificaciones podrían seguir siendo un insumo de la medición pero no al revés.

Lo que se propone es que haya un intercambio de información en ambos sentidos, de esta forma cualquier funcionalidad identificada en la medición sea validada y verificada en la especificación de requisitos, con esto se lograría que la educción fuera eficiente, estando soportada (principalmente) por la IR y “corroborada” por la medición en PF.

En un proyecto podrían tener lugar más de una medición además de la inicial, por lo que esta supuesta “simbiosis” requeriría de un esfuerzo adicional limitado, ya que no implicaría un aumento significativo del número de implicados (“stakeholders”), el proceso existe y se debería haber tenido en cuenta en la IR. En lo que respecta a requisitos no aportaría nuevos requisitos propios sino requisitos no identificados por otros implicados y modificaciones como consecuencia de necesidades de información para poder completar el proceso de medición. Esta limitación en el ámbito de la educción para el implicado y la validación de requisitos identificados en la especificación y la medición, conformarían el mecanismo de comprobación de la completitud de requisitos funcionales y por lo tanto habría un intercambio bidireccional de información. Esto llevaría a la conclusión de que la IR y la medición en PF son simbiontes.
 
Fuera de la analogía pretenciosa y exagerada en el ámbito de la biología, es conveniente resaltar que este intercambio de información, que no es otra cosa que la reutilización de información entre procesos de una ingeniería de software, no es sólo una propuesta, ya se ha utilizado en proyectos reales con resultados positivos.

No hay comentarios:

Publicar un comentario

Related Posts Plugin for WordPress, Blogger...