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

La carrera por el PMP (Project Management Professional)

Después de que ha sido confirmado el día y la hora del examen de certificación, entonces empieza la verdadera carrera, el estudio del portafolio, programa y proyectos, de los 5 grupos de procesos, de las 9 áreas de conocimiento, de los 50 procesos, del libro de 506 páginas

Para saber cual era mi estado físico y mental, hice los tests del curso de preparación de certificación. Esto me dio una idea de que áreas de conocimiento estaban más flojas, tuve desde 57% hasta 76%, con estos resultados priorice el estudio del libro.

Es importante coger una cadencia, me propuse 2 días cada área de conocimiento, y examen al final. Esto me permitió ganar confianza y llegar a superar el 78% de aciertos en un test, igualmente mis notas quedaron reflejadas en presentaciones powerpoint.

Pude también revisar el libro de Rita Mulcahy, súper interesante y de gran ayuda para el examen. La cadencia fue esta vez un día y medio cada área de conocimiento y prueba al final, ya estaba sobre el 80% de comprensión, la meta ya estaba cerca.

Como Murphy no podía estar ausente, tuve asuntos personales que atender por lo que los últimos estudios fueron forzados, y tuvo que romperse la recomendación de no estudiar el día anterior, así que me toco el código de ética para el último.

Y por fin el examen, mezcla de cansancio, esperanza, temor a no aprobar, las últmas charlas con amigos y los comentarios de tantos que se presentaron y no pudieron alcanzar la certificación a la primera.

El sprint final, sábado a las 9 de la mañana, examen en papel, hoja de respuestas, calculadora con las 4 operaciones y lápiz para poder borrar las respuestas dudosas, a las 2 horas, y estaba por la pregunta 105, preocupación por que faltaba casi mitad y ya estaba cansado, apretar el ritmo. Llegue a las pregunta 200 a las 3 horas 50 minutos. 10 minutos para la reflexión final, verificar dudas y no hay tiempo para más, el reloj marca las 4horas, the teacher said The time is over……

Los chismes pos parto, discusión de las preguntas que no tenían sentido, todos estábamos con la cara larga, nadie irradiaba satisfacción y convicción de que si conseguía la certificación. A esperar día a día hasta que llegue un mail con los resultados.

Ufff…. Al final llego el tan ansiado mail, tanto esfuerzo recompensado en una sola sentence, Usted a aprobado el test y es reconocido como PMP, realmente que alivio, un momento de orgullo interno y a prepararse para la siguiente carrera.