Feb
14
2013

Método de Estimación Puntos Casos de Uso (Use Case Points)

Caso de uso

Imagen de berlinbrown.


El método de Puntos Casos de Uso (Use Case Points) fue desarrollado en 1993 por Gustav Kamer, bajo la supervisión de Ivar Jacobson (creador de los casos de uso y gran promovedor del desarrollo de UML y el Proceso Unificado).

Este método ha sido ampliamente utilizado por la empresa Rational. Su principal ventaja es su rápida adaptación a empresas que ya estén utilizando la técnica de Casos de Uso.

Para el cálculo se procede de forma similar a Puntos de Función: se calcula una cuenta no ajustada Puntos Casos de Uso (UAUCP), asignando una complejidad a los actores y a los casos de uso.

Esta complejidad será ponderada con un Factor de Ajuste técnico y por un Factor de Ajuste relativo al entorno de implantación, obteniendo tras ello una cuenta de Puntos Casos de Uso Ajustados.

Veamos a continuación en detalle los pasos del método:

  • 1) Clasificar cada interacción entre actor y caso de uso según su complejidad y asignar un peso en función de ésta. Para poder clasificar la complejidad de los actores debemos analizar la interacción de éste con el sistema que se va a desarrollar.
    La complejidad de los actores puede corresponderse con una de las tres categorías posibles:

    • a. Simple. Representa a otro sistema con una API definida. Se le asigna un peso de valor 1.
    • b. Medio. Representa a otro sistema que interactúa a través de un protocolo de comunicaciones. Por ejemplo TCP/IP o a través de un interfaz por línea de comandos. Se le asigna un peso de valor 2.
    • c. Complejo. La interacción se realiza a través de una interfaz gráfica. Se le asigna un peso de valor 3.

     

    APRENDE A MEDIR Y ESTIMAR PROYECTOS DE SOFTWARE

    • ¿Por qué? Aprende a justificar porque se deben medir los proyectos de software
    • ¿Para qué? Aprende para que sirve una medición y los beneficios que obtienes con ellas.
    • ¿Cómo? Aprende métodos de estimación y medición como: COCOMO 81 y COCOMO 2000, Putnam, Estimación de 3 puntos, Puntos Función IFPUG, NESMA, MKII, COSMIC, SiFP, Puntos de Casos de Uso, SNAP, T-Shirt y un largo etc.
    Ver Más Información
    ¡Sólo vale 7,52€ (en papel 12,35€)!
    Tipo de Interacción Peso Asignado
    Simple
    (a través de API)
    1
    Media
    (a través de protocolo)
    2
    Compleja
    (a través de interfaz gráfica)
    3

    Tabla con los pesos en función de la complejidad de la interacción con los actores

  • 2) Calcular la complejidad de cada caso de uso según el número de transacciones o pasos del mismo. Para calcular la complejidad de un caso de uso debemos determinar el número de transacciones, incluyendo los caminos alternativos.
    Se entiende por transacción a un conjunto de actividades atómicas, donde se ejecutan todas ellas o ninguna.
    En función del número de transacciones que posee un caso de uso se clasifica el caso de uso como simple, medio o complejo, siendo la asignación de pesos la que se muestra en la tabla siguiente:

    Nº de Transacciones del Caso de Uso Tipo Peso
    menor o igual que 3 Simple 5
    mayor o igual que 4 y menor que 7 Medio 10
    mayor o igual que 7 Complejo 15

    Tabla con los pesos en función de la complejidad de los casos de uso

  • 3) Calcular los Puntos Casos de Uso No Ajustados (UUCP) del sistema. Se obtienen sumando los Puntos Casos de Uso de todos y cada uno de los actores y casos de uso que se han identificado y catalogado en función de su complejidad.
  • 4) Cálculo de los Factores Técnicos (TCF). A cada uno de los Factores Técnicos de la tabla siguiente se le asigna un valor de influencia en el proyecto entre 0 (no tiene influencia) a 5 (esencial), 3 se considera de influencia media.
    Obtenidos los grados de influencia se multiplican por el peso de cada factor y con la siguiente fórmula se calcula el Factor Técnico que aplica:


    \mathbf{TCF}=0,6+(0,01\cdot\displaystyle\sum_{i=1}^{i=13} R_i)

    Factor Descripción Peso Influencia
    R1 Sistema Distribuido 2 n
    R2 Objetivos de rendimiento 1 n
    R3 Eficiencia respecto al usuario final 1 p
    R4 Procesamiento complejo 1 q
    R5 Código reutilizable 1 r
    R6 Instalación sencilla 0,5 s
    R7 Fácil utilización 0,5 t
    R8 Portabilidad 2 u
    R9 Fácil de cambiar 1 v
    R10 Uso Concurrente 1 w
    R11 Características de seguridad 1 x
    R12 Accesible por terceros 1 y
    R13 Se requiere formación especial 1 z

    Tabla con los Factores Técnicos para el cálculo del TCF

  • 5) Cálculo de los Factores de Entorno. A cada uno de los Factores de Entorno de la tabla siguiente se le asigna un valor de influencia en el proyecto entre 0 (no tiene influencia) a 5 (esencial), 3 se considera de influencia media.
    Obtenidos los grados de influencia se multiplican por el peso de cada factor y con la siguiente fórmula se calcula el Factor de Entorno que aplica:


    \mathbf{EF}=1,4-(0,03\cdot\displaystyle\sum_{i=1}^{i=8} R_i)

    Factor Descripción Peso Influencia
    R1 Familiar con RUP 1,5 n1
    R2 Experiencia en la aplicación 0,5 n2
    R3 Experiencia con orientación a objetos 1,0 n3
    R4 Capacidades de análisis 0,5 n4
    R5 Motivación 1,0 n5
    R6 Requisitos estables 2,0 n6
    R7 Trabajadores a tiempo parcial -1,0 n7
    R8 Lenguaje complejo -1,0 n8

    Tabla con los Factores de Entorno para el cálculo del EF

  • 6) Obtención de los Puntos Casos de Uso Ajustados. Una vez calculados los dos factores calculamos el valor ajustado de Puntos Casos de Uso con la siguiente fórmula:


    \mathbf{UCP} = UAUCP \cdot TCF \cdot EF

Una vez obtenido el número de Puntos Casos de Uso, si se quiere obtener el esfuerzo necesario para llevarlos a cabo en el método se provee de un factor de productividad.
El autor propone un valor de 20 horas/persona aunque existen distintas propuestas sobre este valor.

Este esfuerzo calculado no abarcaría a todas las fases del proyecto sino únicamente a la codificación de los Casos de Uso no estando contemplada otras fases del desarrollo.

Por tanto, para calcular el esfuerzo total del proyecto habría que estimar el esfuerzo en realizar el resto de actividades del proyecto y sumarlas a las obtenidas por el método de Puntos Casos de Uso.



¿Conocías el método de estimación de Casos de Uso? ¿Lo utilizas en tu empresa?

 

Consigue Más de 100 Libros gratis

Suscríbete a nuestro newsletter por email y conseguirás Más de 100 Libros Gratis sobre Gestión de Proyectos, Innovación, Emprendimiento, Empresa, etc. directamente en tu correo


The following two tabs change content below.
Te Ayudo a Dirigir tus Proyectos al Éxito. Sólo puedes ir más rápido, juntos podemos ir más lejos ¿Conectamos?

35 Comentarios+ Escribir Comentario

  • Hola Julián,

    La verdad es que no lo conocía, pero a primera vista parece muy interesante. Nosotros estimamos más con métricas cruzadas y Delphi.

    Distribuyo el link entre mis compañeros, por si a alguien le puede interesar.

    Gracias!

  • Es un método interesante cuando se desarrollan casos de uso en el proyecto sino no merece la pena el esfuerzo de realizar los casos de uso y luego la estimación.

    Te adelanto que en un post que estamos preparando sobre los métodos de estimación más utilizados en la industria, el método de Puntos Casos de Uso es el tercero más utilizado junto con el de Puntos de Historia (éste para metodologías ágiles).

    Gracias a ti por la divulgación.

    Saludos.

    • Sí, está claro que si no se usan casos de uso no merece la pena. Nosotros sí usamos en algunos desarrollos (no siempre).

      Quedo a la espera del resto de artículos sobre estimación!

  • Si lo hen leido anteriormente, pero no lo he aplicado como se describe en este documento, lo que hemos aplicado es el siguiente criterio.
    1.- Cantidad de tablas que intervienen el caso de uso: cuantos de consulta, cuantos de escritura, cuantos de actualizacion, cada uno de ellos con una complejidad distinta.
    2.- Cuantas pantallas o ventanas maneja el caso de uso, a mas ventanas mas dificultad.
    3.- Dificultad de la funcion en si, siguiendo el mismo principio que se describe en este documento.

    Es lo que puedo comentar.

    • Casi todos los métodos tienen variantes pero no por ello unas son mejores que otras simplemente se adaptan mejor a cada situación.

      En métodos de estimación tenemos que buscar siempre el que se adapte mejor a nuestro caso, si la variante que comentas es mejor para tu caso, y te permite hacer buenas estimaciones, es lo ideal.
      Alguna pega tendría que tener y sería que no podrías compararla con otras personas que utilizaran el método tal cual lo describimos aquí pero bueno eso es sólo si tuvieras la necesidad de realizar la comparación.

      Gracias por la aportación.

      Saludos.

  • Muy interesante, un programita para verificar los resultados. Descargar http://crar01.wordpress.com/puntos-caso-de-uso-estimaa/

    • Gracias Ariel, si quieres puedes incluir una descripción un poco más detallada de en que te basas lo que puede hacer y demás.

      Saludos.

      • EstimaMAA.
        La aplicación se basa en los pasos que describes en el articulo y en: http://es.wikipedia.org/wiki/Puntos_de_caso_de_uso y otros sitios visitados
        La diferencia es que para realizar el “Factor de peso de los casos de uso sin ajustar”, se basa en clases de análisis y no en transacciones. En mi humilde opinión, prefiero las clases de análisis, ya que no es tan susceptible en la estimación del caso de uso.
        Sabemos que el método solo estima la implementación 40% del proyecto SW. El autor indica: Análisis 10% – Diseño 20% – Implementación 40% – Pruebas 15% – Sobre Carga 15%. Alguna bibliografia como Larman o Pressman (no recuerdo muy bien) indica esos porcentajes (con holgura de +-5), finalmente solo nos queda realizar una regla de tres simple y tenemos la estimación total del proyecto SW, la aplicación hace esta tarea.
        Para las personas que usan Enterprise Architect para el modelado, la aplicación importa el archivo de EA, recupera los actores, casos de uso y clases para empezar la estimación, muy pronto se aumentará para Rational Rose y ArgoUml, y aumentar algunas funcionalidades que le hacen falta.
        Saludos.

  • Excelente información, me ayudo a mis tareas de la universidad. …. pero que otras metodologìas existen para project management.

    • Gracias Blanca.

      ¿Te refieres a metodologías de Gestión de Proyectos o a otros métodos de Estimación como son los Puntos de Casos de Uso?

      Saludos.

  • estoy realizando un proyecto investigativo, me gustaria saber si tienen algunos ejemplos de estimacion de puntos de casos de uso

  • Hola que tal me ha gustado mucho el articulo y me ha sido de gran utilidad para mi trabajo, pero tengo una duda sobre lo que mencionaba crar01 al asignar peso a los casos de uso, cual es la diferencia entre clases de análisis y transacciones? la razon de que algunos autores describan diferentes pesos para los casos simples(5) ,medios (10) y complejos (15) se debe ha la diferencia entre esos dos conceptos (clases de análisis y transacciones)?

    • Las gracias te las tengo que dar yo a ti Yesia porque como bien has notado habia una errata. Ya la he solucionado no estaban bien los pesos realmente deben ser 5,10 y 15 y también habia una errata en el factor R2 objetivos de rendimiento que debe ser 1.

      Yesia el peso no varía es el mismo. Lo que varía es como distribuyes en las categorías Simple, Medio o Complejo.

      En un caso puedes contar las clases de análisis de un caso de uso y en otro las transacciones. Pero como te comento el peso es el mismo en ambos lo que varía es el criterio de entrar en un peso u otro.

      Un saludo

      • Gracias por la aclaración Julián me has sacado de una gran duda, ahora ya estoy segura de que la puntuación correcta es 5,10 y 15.
        Saludos.

        • No las merece Yesica te reitero mis gracias a tí por avisarme!

          Un saludo

          • jejeje acabo de notar que escribí mal mi nombre, soy Yesica mucho gusto 😀

          • No hay problema Yesica todo solucionado.

            Igualmente 😉

          • jejeje grax, saludos y que tenga buen dia

  • Hola , excelente explicación pero ¿Por qué estos factores R7 Trabajadores a tiempo parcial y R8 Lenguaje completo -1,0 tienen valores negativos?

    y otra pregunta, los pesos que se asignan a cada factor en base a que están definidos?

    • Ulises la idea subyacente es que al ser negativos explosionan menos puntos de casos de uso, es decir son factor de entorno (ambientales) que limitan la creación de puntos de casos de uso: tanto el tener personal a tiempo parcial como la complejidad del lenguaje de programación.

      El valor de los pesos de cada factor se asignan de forma subjetiva por parte de la persona que hace la estimación en función del conocimiento que tiene del sistema y del entorno.

      • Muchas gracias.por.la.explicacion, me.ha servido.de mucho. Es una verdadera proeza la estimación de.esfuerzos en.desarrollo, ya pase por.Rup, UML, scrum y mada me.convence.mucho,,,,creo.que.hay un area de oportunidad enorme en este rubro,,,saludos y nuevamente muchas gracias,

        • Nada Ulises cualquier cosa me comentas.

          Puedes mirar también los Puntos Función.

          Un saludo.

          • Julián nuevamente una pregunta, de las Formulas:
            EF = 1.40 + (-0.03 * EFactor) y la de TCF = 0.4 + (0.01 * TFactor)

            los valores -0.03 y el 0.01 respectivamente ¿en que están basados?

            Muchas gracias…Saludos

          • En el primer caso según indica Kamer en su primer estudio el 1,4 y el -0,03 están basados en unas estimaciones tempranas que parecen ser razonables en base a las entrevistas realizadas con usuarios experimentados de Objetive Systems.
            En el otro caso 0,4 y 0,01 indica que inicialmente se tomaron los valores definidos por Albrecht para los Puntos Función.

          • Gracias por la respuesta, lo que no me queda claro es porque es -0.03, por qué es negativo. Saludos

  • Gracias por la respuesta, lo que no me queda claro es porque es -0.03, por qué es negativo. Saludos

    • El sentido es que todos los Factores de Entorno actuan de forma positiva en que haga el trabajo con menos esfuerzo y por tanto en menos tiempo. Por ello el multiplicador deberá ser más pequeño de ahí que se reste al 1.4

      Todos los FE exceptos dos que como su impacto es negativo se restan a los otros, es decir si suceden deberás tener una estimación mayor.

      Espero haberlo aclarado Ulises.

      • Totalmente aclarado, ya presenté mi proyecto en base a esta metodología y ya me lo validaron…muchas gracias….

        …Excelente ayuda.

  • Buenas tardes.

    Tengo una consulta con respecto a este tipo de estimacion y es si esta incluido el tiempo para hacer la reporteria.
    Existen ciertos reportes que son faciles como los de tipo catalogos, pero hay otros que pueden ser complejos y por ende demandan tiempo. Entonces, que pasa con el tiempo que se le debe decicar a estos reportes?

    • Yader ¿a que tipo de reporte te refieres a reportes definidos como casos de uso o a reportes de gestión del proyecto? ¿Puedes poner un ejemplo?

      • Buenas.

        Me refiero a los reportes que son parte de un sistema tradicional. Pongamos de ejemplo un sistema de inventario. Este puede tener reportes para imprimir las unidades de medida, las presentaciones de un producto, Estados o departamentos de un pais, etc.

        Los reportes anteriores son de catálogos del sistema y sencillos, pero cuando vemos las entradas pueden surgir una gran cantidad de reportes para analizar las entradas desde diferentes puntos de vistas. Y si analizamos la administración del inventario, la cantidad de reportes puede ser considerable.

        Entonces, mi consulta gira alrededor del tiempo que se le debe dedicar a diseñar y programar estos reportes. De un caso de uso puede diseñarse uno o varios reportes y un reporte puede ser parte de muchos casos de uso. Por ejemplo, un reporte que analice los movimientos de los productod. Para este se puede necesitar casos de uso de entradas, inventario y salidas.

        Espero haya quedado un poco mas clara mi inquietud y gracias por sus comentarios y aportes.

        Saludes.

        • Es una buena cuestión la que preguntas Yader una de los cuidados que hay que tener al utilizar este método es que todos los Casos de Uso deben estar al mismo nivel de detalle. Yo te recomendaría que el nivel de detalle fuera el del usuario final de la aplicación (o sistemas que interactúen) así podrás determinar la medición de una forma más precisa. En el ejemplo que comentas tendrías un caso de uso por cada informe. Si mezclamos casos de uso más generales con otros más específicos como bien apuntabas la estimación se puede desvirtuar.

          • Muchas gracias Julian. Esta era una duda que tenia desde hace un tiempo y no encontraba una solucion que me convenciera ya que lo que he leido sobre casos de usos no mencionan de qué forma se deben manejar/analizar/documentar los informes que utilizarán los usuarios finales. Tomando como base lo que decis, los informes vendria a ser funcionalidades que son parte del sistema que se esta analizando, es decir que son requerimientos (es un pedido, por ejemplo la solicitud de un nuevo sistema) y TI expone los requisitos de dichos informes (es una condición o capacidad que necesita un usuario para resolver un problema o para alcanzar un objetivo).
            Muchas gracias .
            Saludes.

¿Te ha gustado? Pues sólo cuesta un Comentario. ¡Gracias por adelantado!

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.

No te pierdas nada de lo que publiquemos…

Comparte lo que te gusta…

¡Síguenos en Twitter!



¡Síguenos por email!

Recibe nuestro contenido exclusivo para suscriptores: Más de 100 Libros gratuitos, notificaciones de nuevo contenido, ventajas, etc.

Únete a otros 14.639 suscriptores

¡Síguenos por email!

Recibe nuestro contenido exclusivo para suscriptores: Más de 100 Libros gratuitos, notificaciones de nuevo contenido, ventajas, etc.

Únete a otros 14.639 suscriptores

¡Síguenos por email!

Recibe nuestro contenido exclusivo para suscriptores: Más de 100 Libros gratuitos, notificaciones de nuevo contenido, ventajas, etc.

Únete a otros 14.639 suscriptores

Leer entrada anterior
Requerimientos
Las 5 Realidades de los Requisitos de Usuario que un Jefe de Proyecto debe conocer (NICAS)

Los requerimientos de usuario no tienen una única representación, no son una única realidad sino que en verdad hay una...

Cerrar