Puntos de Historia Aplicativo Web que implementa las métricas de estimación para proyectos de software Universidad Francisco de Paula Santander Facultad de Ingeniería Programa de Ingeniería de Sistemas Grupo de Investigación y Desarrollo de Ingeniería de Software (GIDIS)
ESTIMACIÓN POR PUNTOS DE HISTORIA La estimación de Puntos de Historia se realiza de muchas maneras; en la mayoría de los casos el equipo de trabajo decide utilizar Planning Poker (explicado más abajo) para realizarlo, pero esta herramienta por sí sola no suministra los resultados más óptimos. Es por ello que se plantea el siguiente procedimiento que contempla tres herramientas para mejorar la estimación: Establecimiento de las Historias de Usuario Estimacion por Puntos de Funcion Revision de Lecciones aprendidas de otros proyectos Ajuste por Planning Poker Estimacion de la velocidad del equipo y duracion del proyecto Figura 1 Esquema de la estimación por Puntos de Historia Paso 1. Establecimiento de las Historias de Usuario Debemos averiguar con precisión aproximada lo que hay que realizar en el proyecto. Pero también hay que hacer ver que sabemos que va a haber cambios que imposibilitan la certeza absoluta y que desconocemos en el inicio de un proyecto. 1 El equipo de trabajo y el cliente deben reunirse para la especificación de las historias. Estableciendo los requerimientos del software y sus condiciones de aceptación. En la siguiente tabla puede encontrar un formato que representa las características fundamentales que debe tener una historia de usuario: Identificador: Titulo: (Numero) (Representa a grandes rasgos la historia de usuario) Descripción: (La funcionalidad requerida, debe especificarse el usuario implicado, la funcionalidad buscada y el objetivo que se relaciona ) Valor: Dependencias: (La importancia de la historia) (Las historias que deben desarrollarse antes) Condiciones de Satisfacción: (Por medio de preguntas se establecen restricciones o características que el sistema debe tener para ser funcional) Tabla 1 Formato de historias de usuario 1 DIAZ, José Ramón. La estimación ágil de proyectos, puntos-historia y velocidad. Febrero 2013.
Paso 2. Estimación por Puntos de Función Para dar soporte a la estimación de puntos de historias se recomienda realizar una previa con otra métrica. Los puntos de función se basan en los requerimientos funcionales para hacer el cálculo y estos tienen muchas cosas en común con las historias de usuario. Los puntos de función no hay necesidad de ajustarlos; los puntos sin ajustar son funcionales acá. Lo que se busca es ofrecer una base para los puntos de historia. Figura 2 Representación de los puntos de Función - Puntos de Historia 1. Contar las funciones de datos Una función de datos es una característica de almacenamiento que tiene el sistema. Sean tablas de una base de datos o un archivo lógico, son fundamentales en el desarrollo de un software y de la misma manera en una estimación. La complejidad la complejidad de una función de datos, se debe hacer un conteo de lo que se conoce como DETs y RETs. Los DETs son los campos de datos únicos e identificables por el usuario y por otro lado, los RETs, son los subgrupos de datos en el mismo almacenamiento y que son identificables por el usuario, cuando en el almacenamiento no hay subgrupos de datos, se considera que el almacenamiento tiene un solo RET 2. Cada una de las funciones de datos debe ser clasificada según la siguiente tabla: Figura 3 Clasificación de las funciones de datos 2 MENESES, Rafael. Estimación de Tamaño de Software: Puntos de Función. Universidad de los Andes, Bogota.
Una vez realizado el paso anterior, es necesario diferenciarlas según el ámbito al que pertenecen: - Archivo Lógico Interno (ILF): Son tablas de bases de datos o archivos que son identificables por el usuario y se administran dentro de la frontera de la aplicación. - Archivo de Interfaz Externo (EIF) Son tablas de bases de datos o archivos que son referenciados pero no administrados por alguna transacción dentro de la frontera de la aplicación. Finalmente tendrá una tabla que especifique cuantos Archivos Lógicos Internos (ILF) y cuantos Archivos de Interfaz Externos (EIF) tienen una determinada complejidad. TIPO ILF BAJA ILF MEDIA ILF ALTA EIF BAJA EIF MEDIA EIF- ALTA CANTIDAD Tabla 2 Conteo de las funciones de datos 2. Contar las funciones transaccionales. Este paso consiste en identificar y contar la capacidad de realizar operaciones. Se distinguen tres tipos de funciones transaccionales: - Entrada Externa (EI): Es un proceso cuyo propósito principal es mantener uno o más archivos lógicos internos. - Salida Externa (EO): Es un proceso cuyo propósito principal es presentar información al usuario mediante un proceso lógico diferente al de sólo recuperar los datos. - Consulta Externa (EQ): Es un proceso cuyo propósito principal es presentar información al usuario leída de uno o más grupos de datos.
Figura 4 Representacion de las funciones transaccionales La complejidad de las funciones transaccionales depende del número de DETs y FTRs. Los DETs, en las funciones transaccionales, son campos únicos de información que son identificables por el usuario y que entran o salen de la función transaccional. Por mencionar sólo algunos criterios de conteo, aplicables al conteo de DETs para las funciones transaccionales, se tienen los siguientes: - Para ser contado el DET debe entrar o salir de la aplicación, es decir un campo que sea utilizados internamente y que no entre o salga de la aplicación no es contado como DET. - Las etiquetas, nombres de campo, nombres de columna y variables de sistema como (fecha de sistema, número de página, número de columna, entre otros.) no son contados. - En aplicaciones on-line, contamos 1 DET para la capacidad de ejecución sin importar de cuantas formas distintas se pueda ejecutar el proceso elemental. Por ejemplo, si podemos ejecutar la función de Insertar Empleado presionando el botón Salvar o presionando Ctrl-I o dando click en una opción de menú, sólo contaremos un DET por la capacidad para ejecutar dicha función. - En aplicaciones on-line, contamos 1 DET para la capacidad de envío de mensajes, sin importar cuantos mensajes sean enviados dentro de la misma función transaccional. Por ejemplo, en la función Insertar Empleado, por ejemplo, podrían hacerse diversas validaciones sobre cada uno de los datos capturados (longitud del campo, formato de la fecha, etc), sin importar cuantas validaciones sean realizadas, sólo se contará un DET por la capacidad de generar mensajes en dicha función transaccional.
Por otro lado los FTRs, son el número de Funciones de Datos que son mantenidas y/o referenciadas por la Función Transaccional. Con el número de DETs y FTRs y el tipo de cada función transaccional, se consultará en las siguientes tablas la complejidad: Las Entradas Externas se consultan aquí: Figura 5 Clasificación de las entradas externas Las Salidas externas y las consultas se verifican aquí: Figura 6 Clasificación de las salidas y consultas externas Con estos valores relacionados con la complejidad de cada una de las funciones, se puede generar una tabla que especifique cuantos tipos de entradas externas, consultas y salidas existen. TIPO ENTRADA EXTERNA BAJA ENTRADA EXTERNA MEDIA ENTRADA EXTERNA ALTA CONSULTA EXTERNA BAJA CONSULTA EXTERNA MEDIA CONSULTA EXTERNA ALTA SALIDA EXTERNA BAJA SALIDA EXTERNA MEDIA SALIDA EXTERNA ALTA Tabla 3 Clasificación de las funciones transaccionales CANTIDAD
3. Determinar los puntos de función no ajustados. Utilizando los valores establecidos en las funciones de datos y las transaccionales, y en base a la siguiente tabla, puede calcular los factores no ajustados. 3 Figura 7 Cálculo de los puntos de funcion no ajustados En conclusión, los PFSA (Puntos de Función Sin Ajustar) se calculan como la suma de los productos de cada componente por su complejidad. PFSA = PFTe + PFTo + PFTq + PFTif + PFTef Donde: - PFTe: Total Puntos de Función para las entradas del sistema. - PFTo: Total Puntos de Función para las salidas del sistema. - PFTq: Total Puntos de Función para las consultas del sistema. - PFTif: Total Puntos de Función para los archivos internos del sistema. - PFTef: Total Puntos de Función para los archivos externos del sistema. Paso 3. Revisión de Lecciones aprendidas de otros proyectos Este paso puede omitirse en algunos casos, no siempre se tienen lecciones aprendidas de otros proyectos. Las lecciones son mediciones realizadas antes, entre y después del desarrollo del producto. Una de sus mediciones es la duración estimada del proyecto versus la duración real, que, junto a las características del proyecto y del equipo desarrollador, puede ser un referente en la estimación de otros proyectos. Esta herramienta de estimación es netamente subjetiva pero puede suministrar argumentos que justifiquen nuestras decisiones cuando utilicemos Planning Poker. 3 DURÁN RUBIO, Sergio Eduardo. Puntos por Función. Una métrica estándar para establecer el tamaño del software. Boletin de Politica Informatica No.6, 2003
Paso 4. Ajuste por Planning Poker El Planning Poker está basado en una lista de características para ser entregadas, la estimación previa por puntos de función, las lecciones aprendidas de otros proyectos y una baraja de cartas. La lista de características, por lo general una lista de historias de usuario, describen un software que necesita ser desarrollado. Las cartas en el mazo están numeradas. Los valores que se utilizan para representar la complejidad no tienen un valor absoluto sino que su valor es función de su posición en escala. 4 Se comenzó utilizando la serie de Fibonacci: 1,2,3,5,8,13,21,, aunque para evitar que se pensara que hay una precisión matemática en los valores a partir de cierto número se sustituyeron por otros aproximados: 3,5,8,13,40,100, (El 1 y el 2 no se recomienda utilizarlos al no incluir mucha diferencia con respecto al 3). Planning Poker, siendo la herramienta más utilizada para la estimación de proyectos agiles, se basa en el juicio del equipo desarrollador para realizar la estimación de los puntos de historia. Pero esta estimación puede sustentarse con otras herramientas que focalicen al equipo en una sola dirección y permitan un mejor resultado. Un moderador, que no jugará, preside la reunión, apoyado y asesorado por el Gestor del Proyecto. El desarrollador con más conocimiento de una determinada característica proporciona una breve introducción sobre la misma, la estimación previa por puntos de función y menciona la duración real de otros requerimientos similares. El equipo tiene la oportunidad de hacer preguntas y discutir para aclarar los supuestos y riesgos. Un resumen de la discusión es registrado por el Gestor del Proyecto. Cada persona coloca una tarjeta boca abajo que representa su estimación. Las unidades utilizadas pueden ser variadas y definidas previamente. Pueden ser días de duración, días ideales o puntos de la historia. Durante el debate, los números no deben ser mencionados en absoluto. Todo el mundo muestra sus tarjetas de forma simultánea. A las personas con estimaciones altas y bajas se les da un tiempo para ofrecer su justificación para la estimación y la discusión continúa. Se repita el proceso de cálculo hasta que se alcance un consenso. El programador que probablemente tenga el entregable tiene una gran parte del voto de consenso, aunque el moderador puede negociar el consenso. Se puede utilizar un reloj de arena para asegurar que el debate sea estructurado, el moderador o el Gestor del Proyecto podrá en cualquier punto terminar el reloj y cuando se acaba toda discusión debe cesar y otra ronda de póquer se juega. 4 PALACIO, Juan. Flexibilidad con SCRUM, SafeCreative, Octubre 2008.
Las cartas están numeradas de esta forma para explicar el hecho de que, cuanto una estimación es mayor, existe mayor incertidumbre. Así, si un desarrollador quiere jugar un 6 se ve obligado a reconsiderar y aceptar que parte de la incertidumbre percibida no existe y jugar un 5, o aceptar una estimación más conservadora de la incertidumbre y jugar un 8. Paso 5. Estimación de la velocidad del equipo y duración del proyecto Es en este momento cuando realmente hacemos una estimación, respondiendo a la pregunta: a qué velocidad avanzará este equipo en este proyecto? Esta es la verdadera piedra angular de la estimación y que nos dará como resultado una posible planificación temporal. 5 La situación ideal se da en un equipo que tiene históricos anteriores. Guardamos las velocidades anteriores de los proyectos, y si el proyecto se da en condiciones parecidas, la velocidad anterior la podemos proyectar al futuro! Cuando no tenemos históricos, es cuando realmente hacemos una estimación compleja. Cuántos puntos de historia de las definidas anteriormente creemos que podemos hacer por sprint? Vamos a ir más rápido o más lento construyendo el software? El equipo debe calcular cuánto será capaz de hacer por sprint, para estimar la velocidad. Juega siempre con un rango, una estimación pesimista y otra optimista. Es más fácil así dejar claro que es una estimación, y que puede tener un error. Dada la velocidad y el tamaño del proyecto podemos hacer una simple regla de tres para conocer una posible planificación, entre la velocidad optimista y pesimista. Número de puntos totales dividido por la velocidad por iteración = número de iteraciones. Sumando imprevistos y cualquier cuestión que quede fuera de historias de usuario, tendremos nuestra primera aproximación al proyecto. 5 GARZAS, Javier; ENRÍQUEZ DE S, Juan; IRRAZÁBAL, Emanuel. Gestión Ágil de proyectos Software, P-25. Kybele Consulting, España, 2012.