En la actualidad, existen diversas técnicas y métodos que se pueden utilizar para calcular el esfuerzo, costo y tiempo necesario para el desarrollo de un software. Algunas técnicas pertenecen a la rama tradicional, otras a la ágil y otras son más, por así decirlo, abstractas. Usar la técnica correcta es en realidad una tarea difícil, puesto que existen demasiadas variables a considerar. Sin embargo con práctica y experiencia, es posible ajustar las técnicas a los diferentes proyectos y las necesidades específicas del mismo.

Una de las técnicas que más me gustan es la conocida como Use Case Points (UCP) debido a que me permite especificar el esfuerzo necesario para desarrollar un sistema desde la perspectiva del desarrollador, pero con orientación a cómo el usuario interactúa con el sistema. Adicionalmente UCP toma en consideración variables adicionales tales como la experiencia del desarrollador, la complejidad del desarrollo, etc.

Muchos desarrolladores podrán decir que usar casos de uso no es ágil, pero duela a quien le duela, hay que ser francos, “Historias de usuario” es algo muy  distinto de “casos de uso” e incluso la orientación es completamente diferente. Mientras que las historias de usuario están orientadas a definir el producto, es decir el “que”, los casos de uso están orientados a definir el “cómo” o mejor dicho, la funcionalidad del sistema. Ciertamente las historias de uso son muy útiles pues definen el producto y el valor que se entrega al usuario, sin embargo no definen en ninguna forma los aspectos técnicos del requerimiento, es decir, nunca una frase entregará la definición necesaria. Por otro lado los casos de uso pueden ser algo muy “pesado” y que consumen tiempo, pero con práctica puede ser una tarea que toma solo unas horas y ayudan a definir mejor aspectos técnicos de desarrollo, ahorrando a larga, mucho trabajo o iteraciones innecesarias.

Como ingenieros, deberíamos conocer bien cómo estimar usando casos de uso, antes de sumirnos en la “agilidad”. Resulta hasta cómico cuando leo en las redes sociales, ingenieros con muchos años de experiencia, incitando a otros a usar métodos ágiles, pero luego postear “como se cuanto cobrar por mi software”, “cómo puedo estimar cuanto demorare en desarrollar este sistema”, es chistoso y a la vez lamentable. Nuevamente, esto al principio puede parecer tedioso, pero a la larga con práctica, llevará solo unos minutos y quizás hasta lo hagas mentalmente. Entonces ahí puedes usar la misma técnica solo usando un frase o una historia de usuario.

Luego de burlarnos de la pobre base técnica de estos “profesionales de título” e ignorar las ganas de pegar una imagen con los posts de Facebook, vamos a comenzar con un ejemplo: Un usuario necesita enviar un mensaje al dueño de un sitio web, usando el conocido formulario de contacto. Entonces, como historia de usuario diríamos: “Como USUARIO, quisiera contar con un formulario de contacto, para enviar información y obtener soporte”. El rol es USUARIO, el punto de interacción es el “formulario de contacto” y el objetivo es “enviar información”. Excelente definición del valor para el usuario y del producto. Pero nula información técnica o como el desarrollo debe ocurrir.

Entonces, veamos el caso de uso: En general, los casos de uso tienen 2 componentes, el diagrama de caso de uso usando UML y el caso de uso narrado que cuenta la historia de lo que sucede en el diagrama. Aunque el diagrama no es algo obligatorio y comúnmente se obvia para ahorrar tiempo, en mi opinión cuando el desarrollador y el analista son personas diferentes, son muy útiles para comunicar gráficamente los requerimientos a través de la técnica de la “monística” o el arte de dibujar monos. Por otro lado, el caso de uso narrado se separa en lo que hace el sistema frente a lo que hace el usuario, en este ejemplo:

Cuando algo sale mal con el formulario, ocurre un flujo alternativo. Por ejemplo el usuario ingreso mal un dato:

Bien, ya tenemos nuestro primer caso de uso. De este podemos descomponer algunas cosas:

• Los actores son USUARIO y SISTEMA.
• El sistema usa una base de datos.
• El nombre del botón es “Enviar”.
• El sistema requiere base de datos.
• Los mensajes a desplegar para el caso de éxito y cuando hay un error.

Ahora comenzaremos con UCP. En este ejemplo tenemos solo un caso de uso, pero habitualmente un sistema estará formado por múltiples casos de uso. UCP se compone de 4 datos:

1. Factor de Complejidad Técnica (TCF – Technical Complexity Factor).
2. Factor de Complejidad Ambiente (ECF – Environment Complexity Factor).
3. Puntos de Casos de Uso sin Ajustar (UUCP – Unadjusted Use Case Points).
4. Factor de Productividad (PF – Productivity Factor).

Los pasos para obtener el valor de cada ítem son:

1. Determinar y calcular los Factores Técnicos.
2. Determinar y calcular el Factor Ambiente.
3. Calcular los Puntos sin Ajustar de los Casos de Uso.
4. Determinar el Factor de Productividad.
5. Multiplicar el valor de todas las variables.

Determinando el Factor Técnico:

Existen trece factores técnicos estándar para estimar el impacto en la productividad que diferentes variables generan en la aplicación. Estos 13 factores tienen un valor de peso estandarizado y uno puede agregar un valor de 0 a 5 que nos permite indicar la importancia que dichos factores tienen en nuestra aplicación. La multiplicación de peso con el valor dado nos entregan el factor que cada ítem tendrá. La suma total de estos factores se conoce como Factor de Complejidad Técnica sin ajustar. El valor final para el Factor de Complejidad Técnica se obtiene usando la fórmula adicional: FCT =(FCT sin Ajustar*0,01)+0,6. En este ejemplo:

Factor de Complejidad Ambiente:

El Factor de Complejidad Ambiente estima el impacto en la productividad de varios factores ambientales, tales como el si los desarrolladores tienen conocimiento y experiencia en el lenguaje, si son desarrolladores de medio tiempo, su nivel de motivación, etc. Al igual que en el caso anterior, tenemos una serie de preguntas a contestar, las que tienen un peso e influencia, y se les asigna un valor de 0 a 5 para definir el factor final. Nuevamente, la suma de los factores nos otorgaran el valor del factor ambiente no ajustado, y obtendremos el final usando la siguiente fórmula: FA =1,4–(FA sin ajustar*0,03). En este ejemplo:

Puntos por Caso de Uso sin Ajustar:

Los puntos por caso de uso sin ajustar se calculan en base a dos datos:

• El peso sin ajustar de los casos de uso (Unadjusted Use Case Weight – UUCW), basado en el número total de actividades o pasos contenidos en el escenario del caso de uso.
• El peso sin ajustar del Actor (Unadjusted Actor Weight – UAW), basado en la combinación de la complejidad de los actores (usuarios u otros sistemas) que intervienen en el caso de uso.

El peso sin ajustar de los casos de uso se categorizan en Simple, Mediano y Complejo. Como se mencionó anteriormente se valorizan de acuerdo al número de pasos que contienen, incluyendo flujos alternativos.

Peso sin ajustar de los actores:

De igual forma los actores son clasificados en función de su complejidad y cantidad de interacciones como Simple, Medio y Complejo.

Finalmente, el valor de los casos de uso sin ajustar se obtiene sumando el total del peso o valor de los casos de uso con el peso o valor de todos los actores. Por ejemplo:

Con todos estos valores, es posible obtener los puntos por caso de uso multiplicando los resultados entre si. Y para obtener la cantidad de horas hombre correspondientes al esfuerzo por desarrollar, basta con multiplicar la cantidad de puntos obtenidos por el factor de productividad que corresponde al tiempo que un desarrollador requiere para completar un punto. El valor estándar es de 20 horas por punto, pero esto puede variar según la experiencia del desarrollador y la complejidad del proyecto. Puesto que nuestro ejemplo es solo un formulario, podemos decir que puedo completar 1 punto por día (8 horas laborales).

Esto representa entonces el valor de horas requeridas para programar, sin embargo todo proyecto formal tiene otras fases además de la de desarrollo, tales como análisis, diseño y pruebas. Usando valores porcentuales para asignar una proporción del tiempo al proyecto, podemos obtener un estimado de lo que demora el proyecto completo.

Luego, ya que conocemos el valor hora de un desarrollador promedio, podremos completar el resto de los cálculos necesarios para estimar el valor venta del proyecto. Habitualmente podemos cobrar el doble del costo del valor de horas necesarias para completar el proyecto, más el impuesto (20%), es decir, multiplicamos los valores de costo por 2.2.

Finalmente tendremos el resumen de nuestro proyecto completo:

Para facilitar la vida a quienes desean usar mi template, pueden copiarlo desde Google Docs.

Happy Coding!