Estimación de proyecto usando Métricas de Casos de Uso
Enterprise Architect provee
una herramienta de estimación de proyectos
comprensiva que calcula el esfuerzo desde los
objetos de caso de uso y actor unido con
configuraciones de proyectos definiendo la
complejidad del ambiente de trabajo. Este método
está basado en el Método de Puntos de Casos de
Uso de Karner con muchas variaciones mencionadas
abajo. También puede producir un reporte de
métricas conteniendo el análisis de estimación
del proyecto para incorporarlo a su
documentación de proyectos.
Antes de estimar el tamaño del proyecto, primero necesitará configurar los factores técnicos y ambientales (ver el ítem de menú Configuración - Tipos de Métricas y Estimación - valores FCT y FCA). Para ambos FCT (Factor de Complejidad Técnica) y FCA (Factor de Complejidad del Ambiente), una tabla editable contiene una lista de factores influenciando la productividad del proyecto. Se asocia un peso con cada factor reflejando cuanto afecta relativamente ese factor a la productividad, un peso no es relativo a un proyecto. Los factores provistos y sus pesos asociados son definidos por el método de Puntos de Caso de Uso, aunque pueden ser ajustados para satisfacer las necesidades específicas de un proyecto. Para la mayoría de los propósitos, la única columna de la tabla que necesita el ajusta será 'Valor', que indica el grado de influencia que un factor particular tiene sobre un proyecto. Como una sugerencia, un valor de '0' indica que no hay influencias, y '5' indica fuerte influencia.
A medida que construye su proyecto utilizando casos de uso UML para describir la funcionalidad propuesta, se debería asignar una tasa de complejidad a cada caso de uso:
- Fácil (5 puntos): el Caso de Uso es considerado una parte simple de trabajo, usa una interfaz de usuario simple y toca solamente una entidad particular de la base de datos; su escenario exitoso tiene menos de 3 pasos; su implementación involucra menos de 5 clases.
- Medio (10 puntos): el Caso de Uso es más difícil, involucra mas diseño de interfaces y toca dos o mas entidades de bases de datos; su escenario exitoso tiene entre 4 y 7 pasos; su implementación involucra entre 5 y 10 clases.
- Complejo (15 puntos): el Caso de Uso es muy difícil, involucra una interfaz de usuario compleja o procesamiento y toca 3 ó más entidades de bases de datos; su escenario exitoso tiene más de 7 pasos; su implementación involucra más de 10 clases.
Lo expresado arriba son, por supuesto, guías; si está escribiendo una aplicación sin persistencia pero de procesamiento complejo, tendrá que utilizar su juicio para asignar las tasas de complejidad.
Mientras se construyen los casos de uso, tenga en cuenta que también puede asignarlos a fases (por ejemplo, 1.0, 1.1) y más tarde filtrar su estimación basada en la fase. También puede ingresar texto libre en el campo 'Tag' de un caso de uso y filtrar la estimación basada en la información de ese campo (por ejemplo, <URGENTE>).
El método de Puntos de Caso de uso de Karner también calcula el esfuerzo del proyecto considerando los actores y la complejidad con la que contribuyen. Hay una opción para incluir actores en el calculo de estimación; por defecto, sólo se consideran los casos de uso. Si los actores de proyecto se incluyen también, hay que asegurarse de que la complejidad será asignada por algún método; las guías para esta asignación se proveen abajo.
- Fácil: el actor representa otro sistema con una API definida
- Medio: el actor representa otro sistema interactuando a través de un protocolo, como TCP/IP
- Complejo: el actor es una persona interactuando por una interfaz.
Una vez que estableció los casos de uso y el ambiente, resalte el paquete raíz a estimar en el navegador de proyecto, haga clic con el botón derecho y seleccione 'Métricas de Paquete' (Package Metrics). Aparecerá la siguiente pantalla:
Esta detalla la información de complejidad para su proyecto:
1. | El factor de complejidad técnica (FCT) se calcula a partir de la información que ingresó |
2. | La complejidad ambiental (FCA) se calcula a partir de la información que ingresó |
3. | Los puntos no ajustados de los casos de uso (PNACU)= la suma de las tasas de complejidad de los casos de uso. * |
4. | Los PNACU se multiplican por los factores FCT y FCA para producir un número de puntos de caso de uso (PCU) balanceado |
5. | El número resultante se multiplica por las horas por defecto por caso de uso para producir la estimación final |
6. | También se muestran las horas promedio para casos de uso simple, medios y complejos |
*Aunque el método de PCU de Karner recomienda excluir los casos de uso incluidos y extendidos en esta cuenta, Enterprise Architect considera todos los casos de uso en este cálculo. Si éstos casos de uso requieren funcionalidad para ser desarrollad, el esfuerzo aún existe y debería ser descompuesto en factores.
Un factor crítico es la variable “Horas Pre-derminadas”. Aunque en EA está configurada a 10 horas, esta variable puede fácilmente exceder las 30 horas, dependiendo del entorno.
La mejor forma de de configurar correctamente un nuevo proyecto a su entorno único es considerar los casos de uso de proyectos completos. Después de configurar un proyecto completo como se especificó anteriormente, y ejecutar un reporte de métricas, los factores disponibles se pueden conectar para rendir un tiempo estimativo similar a las horas actuales. De esta forma, puede comenzar a usar estas figuras como su Línea Base.
Tenga en cuenta que un buen control de que todo está bien consiste en mirar la figura de horas promedio por caso de uso: si cree que puede construir un caso de uso simple en el tiempo permitido (incluyendo diseño, prueba, documentación, revisiones, etc., etc. [dependiendo de sus procesos]) al igual que el medio y el complejo, entonces se encuentra en el camino correcto.
No espere una respuesta mágica a la pregunta '¿cuánto costo?' o '¿cuánto tiempo?', recolecte algunas estadísticas y experiencia y úselas para estimar nuevos proyectos.