Calculo de estimado con COCOMO

[Casimiro Noteví]

Empezado por Delphius

......

Creo que eso mismo ha querido decir AzidRain, que en software no se puede cuantificar los proyectos como en otras disciplina, en las que es más fácil medir tiempo y trabajo realizado. Lo nuestro es más creativo. Por ejemplo, anoche no podía dormir porque estaba dándole vueltas a un problema y se me ocurrió una manera abstracta de solucionarlo, me levanté a medianoche a anotarlo y esta mañana me he puesto a implementarlo. ¿Eso cómo se mide y cuánto vale?, lo mismo lo solucionas en un rato pensando mientras estás en el baño, que tardas un par de días dándole vueltas y haciendo distintas pruebas, buscando información, preguntando en foros, etc.

[[Delphius]]

Empezado por Casimiro Notevi

Creo que eso mismo ha querido decir AzidRain, que en software no se puede cuantificar los proyectos como en otras disciplina, en las que es más fácil medir tiempo y trabajo realizado. Lo nuestro es más creativo. Por ejemplo, anoche no podía dormir porque estaba dándole vueltas a un problema y se me ocurrió una manera abstracta de solucionarlo, me levanté a medianoche a anotarlo y esta mañana me he puesto a implementarlo. ¿Eso cómo se mide y cuánto vale?, lo mismo lo solucionas en un rato pensando mientras estás en el baño, que tardas un par de días dándole vueltas y haciendo distintas pruebas, buscando información, preguntando en foros, etc.

En espíritu el ejemplo de AzidRain va con buen sentido, pero al momento de presentar su caso va un reducctio ad extremum. Si vamos a ofrecer ejemplos para ilustrar la diferencia entre lo que vemos en Ingeniería Civil y en Ingeniería en Informática, al menos que sea de una forma en la que no se denigre a ninguna.
Si, se puede "calcular" cuanto va a costar a un obrero cavar un pozo, o cuanto nos cuesta la mano de obra en alisar una pared o revestirla según el material, pero reducir la Ingeniería Civil a ejemplos tan pobres (aunque no deja de ser una noble y digna actividad y que requiere su disciplina y experiencia manual) es un insulto. Y lo mismo va para el área de Informática y hasta para cualquier tarea laboral. Ofrescamos un ejemplo más real.
A manera de cierre, una vez expuesto el punto, y ya con humor si puedes dejarlo. Tal como lo hice para el caso del jefecito que intenta vender el soft más completito y promete hacer hasta actividades recreativas en la parte baja , un recurso literario que se emplea para llamar la atención pero nada más.

Saludos,

[mamcx]

Ya quedo plasmado que es imposible determinar de antemano con precision cuanto va a tardar/costar un software.

Pero de *alguna manera* se debe poder hacer una aproximación, verdad? Si no, seria imposible operar en este negocio.

A groso modo, puedes pensar que un programa va a tardar:

- 1 semana
- 3 meses
- 6 meses
- 1-3 años
- 10 años

Estos son rangos que se repiten mucho y sirven para ubicar los proyectos.

Como se hace la aproximacion?

Debes tener un listado tan detallado como sea posible de cada aspecto del programa. Esto requiere no solo la toma de "caracteristicas" tipicas, sino hacer mockups de las pantallas/procesos, hablar con el cliente/involucrados y desgranar tareas que por experiencia, no te lleven mas de 5h en completar.

Por ejemplo:

"Quiero que le programa tenga seguridad"

Eso asi no te sirve de nada. Asi que digamos que al final tienes que:

1- Crear tabla(s) de usuarios/grupos = 1h
2- Formulario Login = 2h
3- Encriptacion de datos = 5h (incluido cuanto te lleva averiguar los metodos seguros actuales)
4- Crear logica interna de ingreso = 2h
5- Test automaticos = 3h

Y asi por el estilo. Terminas teniendo una lista larga de tareas por completar. Esto es importante, porque asi puedes comunicar facil lo que *realmente* implica hacer el trabajo.

A eso, le debes agregar demoras de comunicacion. Por ejemplo:

- Cuanto demora el cliente en responderte una duda?
- Cuanto demora el cliente en retornar datos de pruebas?
- Y en testear una tarea?

Con eso le agregas otro poco.

El resultado final SERA INEXACTO, Y POR MUCHO

Pero, el punto crucial es que NO DEBES CUANTIFICAR CUANTO TE VAS A DEMORAR, SINO CUANTAS ACTIVIDADES HAY POR HACER!

Resolver un punto de una tarea, aun estimada que no pase de 3-5 horas puede igual irse a unos dias. Comunmente, porque quedas bloqueado por el cliente en responder. Este es un punto crucial.

Sin exagerar, he tenido que esperar hasta *6 meses* a un cliente para poder avanzar en una tarea que toma unas cuantas horas. Es brutal todo lo que implica "comunicar" entre areas distintas del proyecto y es una de las demoras mas significativas e inesperadas por quienes son novatos en esto.

Asi que esa es la formula: Cuantificar en pedazos pequeños las actividades, agregar buffers de comunicacion, y dejar claro que cada actividad no programada OBLIGA a parar las demas. Y que raramente se pueden hacer actividades en paralelo, asi que todo el equipo, INCLUIDO EL CLIENTE, tiene que moverse a un ritmo aceptable.