Estimando el costo del proyecto usando las transacciones del caso de uso (1)

La pregunta para el Director de proyecto, siempre es la misma. Cuanto nos cuesta hacer el sistema?

Para tener una primera visión del alcance del proyecto, siguiendo las recomendaciones de RUP seria de concretar las aspiraciones de los usuarios y el entendimiento del equipo técnico en el documento llamado Visión. A estas alturas del partido se tienen identificadas únicamente características que son comprendidas por los usuarios y no existe el detalle del como se implementaran técnicamente.

Siguiendo la recomendación de la metodología se debería llegar a tener una identificación de los casos de uso que soportarán las características comprometidas en el documento de visión. Se hace una primera redacción rápida del escenario principal del caso de uso, que será la base para realizar la estimación. Debido a la incertidumbre originada por la falta de conocimiento detallado del caso de uso, el analista debe apoyarse en su experiencia o al estilo del PMBOK apoyarse en el juicio de los expertos que son los colegas con experiencia en proyectos y temáticas similares.

El caso de uso describe la “conversación” que hace el actor con el “sistema”, así a una acción del actor recibe una respuesta del sistema, y de acuerda a ella el actor vuelve a interactuar con el sistema. Esta pareja acción/reacción constituye una transacción en el caso de uso (un punto) y para comprender este tema se hace las siguientes aclaraciones de lo que NO es:

• Una transacción de caso de uso no es un paso en el detalle del caso de uso
• Una transacción de caso de uso no es una transacción en la base de datos.
• Una transacción de caso de uso no es cada acción iniciada por el actor

Igualmente los escenarios alternos o los flujos de excepción implican otros diálogos actor-sistema por lo que ellos constituyen otra transacción del caso de uso. Hay que recordar que cuando un caso de uso es utilizado por más de un actor, implica interacciones diferentes, las mismas que pueden ser expresadas en flujos alternos y contados por lo tanto como transacciones diferentes. También se debe tomar en cuenta que un caso de uso con muchas transacciones (más de 12) es un síndrome de los casos de uso Superman (que lo hacen todo), y por tanto la recomendación es dividir el caso de uso.

Con todas estas aclaraciones entonces el analista estaría listo para contar las transacciones del caso de uso, no obstante en base a su conocimiento y experiencia puede ser que considere alguna transacción como “fácil”, y omitirla del conteo en el caso de uso.

Según las recomendaciones de puntos de caso de uso se tiene:

Caso de uso Simple – 1 a 3 transacciones – Peso 5

Interface de usuario sencilla afectando a una entidad en la base de datos, manejando 5 clases.

Caso de uso Medio – 4 a 7 transacciones – Peso 10

Interface de usuario versátil afectando a mas de una entidad en la base de datos, manejando 5-10 clases.

Caso de uso Complejo – más de 7 transacciones – Peso 15

Interface de usuario compleja afectando a mas de 3 entidad en la base de datos, manejando más de 10 clases.

Con la cuantificación del caso de uso, se puede tener un estimado de cuanto tiempo se estima la implementación, tomando en cuenta los elementos adicionales identificados en la metodología de los puntos de casos de uso(3).

1. Factores ambientales del proyecto que toma en cuenta la madurez y estabilidad de la empresa en el manejo y ejecución de proyectos de TI (ejemplo respeto a los compromisos adquiridos, re-priorizaciones, estabilidad de requerimientos, etc.
2. Tiempos adicionales de la gestión de los requerimientos, las pruebas de integración, el deployment, etc.
3. Complejidad Técnica
4. Factor de productividad

Con todos estos elementos se procede a la estimación del tiempo(2), se puede tomar en cuenta la recomendación que un punto de caso de uso (transacción) toma entre 15 y 30 horas del equipo de trabajo, el determinar este valor dependerá de cada lugar de trabajo en particular.

Con la estimación de tiempo realizada se procede a la valoración tomando en cuenta los costos de los recursos involucrados y utilizados en el equipo de trabajo. En base a los costos que nos proporcione la contabilidad tanto de los gastos directos (ejemplo sueldos de los técnicos) como de los indirectos (luz, Internet, etc).

1.- Software cost estimation using use case points: Getting use case transactions straight, Remi-Armand Collaris, Eef Dekker

2. Use Case Points an Estimation Aproach, Gautam Banerje, 2001-Aug.

http://www2.fiit.stuba.sk/~bielik/courses/msi-slov/reporty/use_case_points.pdf

3. Project estimation with use case points, RoyClem, 2005 Mar

http://www.codeproject.com/KB/architecture/usecasep.aspx