Aplicativo Web que implementa las métricas de estimación para proyectos de software

Transcripción

1 Múltiples Métricas 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)

2 ESTIMACIÓN POR MÚLTIPLES MÉTRICAS La estimación por Métrica Hibrida es un desarrollo propio de este proyecto, inicialmente establecimos una metodología más robusta para estimar Puntos de Historia (ver el documento Estimación por puntos de Historia) y en esta métrica se trabaja de manera similar. La gran diferencia es la inclusión de los puntos de casos de uso como herramienta para dar soporte a la estimación; suministrando al Planning Poker más documentación que sustente la estimación. En esta métrica se tienen datos sobre el impacto de la capa persistente de la aplicación, la capa de presentación y la capa de aplicación; fundamentales para una buena estimación. El procedimiento es el siguiente: Establecimiento de las Historias de Usuario Estimacion por Puntos de Funcion Estimación por Puntos de Casos de Uso Revision de Lecciones aprendidas de otros proyectos Ajuste por Planning Poker Figura 1 Esquema de estimación por múltiples métricas 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 ) 1 DIAZ, José Ramón. La estimación ágil de proyectos, puntos-historia y velocidad. Febrero 2013.

3 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 Paso 2. Estimación por Puntos de Función Para dar soporte a la estimación 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 Múltiples Métricas 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. 2 MENESES, Rafael. Estimación de Tamaño de Software: Puntos de Función. Universidad de los Andes, Bogota.

4 Cada una de las funciones de datos debe ser clasificada según la siguiente tabla: Figura 3 Clasificación de las funciones de datos 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.

5 - 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.

6 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

7 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. 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

8 Paso 3. Estimación por Puntos de Casos de Uso La segunda métrica que dará soporte a la estimación es Puntos de Casos de Uso, para la satisfacción de las necesidades buscadas se recomienda el cálculo de los puntos de casos de uso sin ajustar; como se muestra en la siguiente gráfica y se explica posteriormente: Figura 8 Representación de Puntos de Casos de Uso - Múltiples Métricas 1. Clasificación de los Actores: Consiste en la evaluación de la complejidad de los actores con los que tendrá que interactuar el sistema. Este puntaje se calcula determinando si cada actor es una persona u otro sistema 4. Tipo de actor Descripción Factor Simple Medio Complejo Otro sistema que interactúa con el sistema a desarrollar mediante una interfaz de programación (API). Otro sistema interactuando a través de un protocolo (ej. TCP/IP) o una persona interactuando a través de una interfaz en modo texto. Una persona que interactúa con el sistema mediante una interfaz gráfica (GUI). Tabla 4 Clasificación de los actores - Puntos de Casos de Uso Si asignamos un factor a cada actor del sistema y luego los sumamos, tendremos el Peso de los Actores en la estimación. Este valor se conoce como UAW. 4 CLEMMONS, Roy K. Project Estimation With Use Case Points, Universidad Veracruzana, Mexico, 2006.

9 2. Clasificación de los Casos de Uso: Este punto funciona muy similar al anterior, pero para determinar el nivel de complejidad se puede realizar mediante dos métodos: basado en transacciones o basado en clases de análisis. Una transacción es un conjunto de actividades atómicas, lo que quiere decir que se ejecutan todas o no se ejecuta ninguna. o Basado en transacciones: Toma en cuenta el número de transacciones que se pueden realizar en un caso de uso 5 y lo evalúa según la siguiente tabla: Tipo de Caso de Uso Descripción Factor Simple 3 transacciones o menos 5 Medio 4 a 7 transacciones 10 Complejo Más de 7 transacciones 15 Tabla 5 Clasificación de los casos de uso basado en transacciones Iván Jacobson, inventor del caso de uso, describe una transacción de caso de uso como un viaje de ida y vuelta que va desde el usuario hasta el sistema para luego volver al usuario; una transacción está terminada cuando el sistema espera un nuevo estímulo de entrada. 4 En otras palabras, en una transacción el actor lleva a cabo una acción que representa una entrada para el sistema. A continuación, el sistema reacciona, es decir, procesa la entrada y devuelve el resultado al actor. Cuando el actor reacciona ante el resultado comienza una nueva transacción, que a su vez representa una nueva entrada para el sistema. 6 o Basado en clases de análisis: Toma en cuenta el número de clases que tiene un caso de uso y lo evalúa según la siguiente tabla: Tipo de Caso de Uso Descripción Factor Simple Menos de 5 clases 5 Medio 5 a 10 clases 10 Complejo Más de 10 clases 15 Tabla 6 Clasificación de los casos de uso basados en clases 5 PERALTA, Mario. Estimación de esfuerzo basada en Casos de Uso. Reportes técnicos en Ingeniería de Software Vol. 6 No.1 ISSN: , Buenos Aires, COLLARIS, Remi-Armand; DEKKER, Eef. Estimación del costo del software usando puntuación en casos de uso: clarificar las transacciones de casos de uso. IBM, 2009.

10 Ahora independientemente del camino utilizado para clasificar los casos de uso, el resultado se halla de la misma manera. Cada uno de los Casos de Uso debe encajar en un tipo de Caso de Uso, la suma de los respectivos factores es el valor del Peso de los Casos de Uso. Este valor se conoce como UUCW. 3. Casos de Uso sin ajustar (UUCP) El UUCP son los puntos de casos de uso sin ajustar, esto nos puede servir para tener una idea un poco más precisa de la dificultad de los casos de uso e interfaces, tomando en cuenta los pesos de los actores (UAW) y los pesos de los casos de uso (UUCW). 7 UUCP = UAW + UUCW Estas siglas significan: - UUCP: Puntos de casos de uso sin ajustar. - UAW: Peso de los actores. - UUCW: Peso de los casos de uso. Paso 4. 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. 7 CLEMMONS, Roy K. Project Estimation With Use Case Points, Universidad Veracruzana, Mexico, 2006.

11 Paso 5. Ajuste por Planning Poker El Planning Poker está basado en una lista de características para ser entregadas, las lecciones aprendidas de otros proyectos, una baraja de cartas y la estimación previa por puntos de función y puntos de casos de uso. 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. 8 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, menciona la duración real de otros requerimientos similares (lecciones aprendidas de otros proyectos) y la estimación previa por puntos de función y puntos de casos de uso. 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. 8 PALACIO, Juan. Flexibilidad con SCRUM, SafeCreative, Octubre 2008.

12 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 6. 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. 9 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. 9 GARZAS, Javier; ENRÍQUEZ DE S, Juan; IRRAZÁBAL, Emanuel. Gestión Ágil de proyectos Software, P-25. Kybele Consulting, España, 2012.