Estimar tiempos de desarrollo

[[AzidRain]]

A ver mis estimados delphineros...Voy a inicar un proyecto de software administrativo (gestión para los españoles) y aunque quisiera hacerlo como Dios manda (hacer análisis, diagramación, etc.) creo que no voy a poder hacerlo así y tendré que hacerlo como creo acostumbramos muchos..al vuelo.

Bien pues: El sistema en cuestion es para administración de empresas de autotransporte de carga consolidada (tipo paqueteria) y constara de lo sig .modulos:

* Facturacion
* Cuentas por pagar
* Cuentas por cobrar
* Bancos
* Tráfico
* Liquidación a operadores (gastos de viaje)
* Contabilidad
* Bodega (entradas y salidas)
* Rastreo de envíos y acuse de recibo
* Taller y llantas

Usando:

Delphi 6.0
Zeos
MySQL

Mas lo que se acumule.

Lo que me cuesta trabajo es estimar el tiempo de desarrollo ya que en función de eso es lo que voy a cobrar, cabe mencionar que es un desarrollo a medida pero con miras a poder venderlo después. Para evitar eso de modificaciones y adiciones interminables de un solo modulo planeo hacer una especie de "iteraciones" en el sistema completo, es decir, tratar de desarrollar todo aunque sea muy simple o "feo" y ya que funcione, volver a ir revisando los cambios que hayan salido durante el primer desarrollo y asi sucesivamente.

Planeo liberarlo Open Source al final una vez terminadas todas las modificaciones o "embellecimientos" y vender unicamente el soporte y mantenimiento del código.

A ver quien me ayuda a calcular un tiempo estimado...no hay prisa

Y claro aunque no es un hilo para el foro de "trabajo" si alguien quiere ayudar bienvenido...
Saludos.

[[egostar]]

Existe un modelo llamado COCOMO donde puedes darte una idea sobre tu problematica, ve al apartado Estimación del esfuerzo que supongo es el que te interesa.

Obviamente, es un modelo llamese "ideal", pero recuerda que todo es relativo pero creo que si te puede ayudar mucho.

Saludos.

[Neftali [Germán.Estévez]]

Empezado por AzidRain

...y aunque quisiera hacerlo como Dios manda ... ...y tendré que hacerlo como creo acostumbramos muchos..al vuelo.

¿Y la razón cual es?

Soy de la opinión de que "perder" un tiempo en un buen análisis, te reportará menos tiempo de programación.

[[AzidRain]]

Empezado por Neftali

Soy de la opinión de que "perder" un tiempo en un buen análisis, te reportará menos tiempo de programación.

Estoy totalmente de acuerdo ya ha habido variosc asos en que le invierto tiempo al análisis y a la hora de codificar todo es como en automático, pero en estos casos normalmente el cliente quiere ver resultados casi de inmediato y poco se entiende que implica hacer un análisis previo. En ocasiones el "análisis" según el cliente no es más que unas cuantas entrevistas y comentarios sobre lo que necesita y con eso hay que trabajar. Algunos incluso quieren un prototipo en unas cuantas semanas...Definitivamente un diseño a la medida implica mucho análisis pero esto a su vez requiere tiempo que se traduce en costos que muchos clientes no están dispuestos a pagar.

Otra cosa muy mala es que al menos aqui en Córdoba, México; el mercado esta muy devaluado gracias a muchas empresas y programadores que con tal de aprender en el intento ofrecen sus servicios muy baratos por lo que muchas veces un buen sistema, bien planeado y organizado les resulta muy caro a los clientes si lo comparan con lo que hacen otros (sin planeación, al "ahí se va", o con herramientas de cuarta ).

En fin, finalmente quisiera apoyarme en la experiencia de ustedes que probablemente han hecho alguno de los módulos por aqui mencionados.

[mamcx]

Estimar tiempos no es *tan* dificil. De hecho es muy, muy simple. Lo que pasa es que a veces uno le presta atencion a metodologias que estan hechas para tipos de desarrollo o tamaños de equipos de desarrollo diferentes... y no cuadran.


Yo he aplicado unas cuantas ideas y en casi todos los proyectos que he trabajado he acertado con un margen de error de 2 meses, que no esta mal :

- Primero, hay que tener un taller que se preste para ser productivo:

-- No es discutible el uso de control de codigo
-- No es discutible herramienta de guardar bugs y tareas

http://bdn.borland.com/article/33656

http://local.joelonsoftware.com/medi...ra_los_bugs.3F

Armarse de herramientas y montar todo (al menos: subversion + bug tracking + probemos como es la vuelta) toma 1 semanita. Y paga todo el año en dividendos.

Aprender a usar nant, want o lo que sea y hacer el primer instalador en un solo tiro es 1 semanita, contando el producto mas grande que me ha tocado.

- Segundo, armar un cronograma es ASI DE FACIL:

http://www.joelonsoftware.com/articl...000000245.html

Eso toma un par de minutos por cada punto y puede gastarse unos 3 o 4 dias. Pero es algo dinamico, porque al ir entrando en codigo o ir viendo la cosa se da uno cuenta que falto esto o aquello. Asi que vas actualizando.

Todo proyecto importante toma 1 año, minimo. Con esto, tendras una certeza de +/- 2 meses para la primera vez y eso si sos tan desorganizado e indisciplinado como yo...

-- Como hacer las especificaciones:

http://spanish.joelonsoftware.com/Ar...Specifi-2.html

[Neftali [Germán.Estévez]]

Empezado por mamcx

Estimar tiempos no es *tan* dificil. De hecho es muy, muy simple.

Hombre haciéndolo con tu sistema sí que es simple.
Tiempo de desarrollo = 1 año. ¡¡Y t' has quedao tan fresco!!

Empezado por mamcx

Yo he aplicado unas cuantas ideas...
...
==> Armarse de herramientas y montar todo... (al menos: subversion + bug tracking + probemos como es la vuelta) toma 1 semanita.
==> Aprender a usar nant, want o lo que sea y hacer el primer instalador en un solo tiro es 1 semanita, contando el producto mas grande que me ha tocado.
==>...Eso toma un par de minutos por cada punto y puede gastarse unos 3 o 4 dias.

Estamos hablando de Tiempos de Desarrollo de un proyecto.
El tema Subversión, control de Bugs, nant, want, ... está muy bien y tu artículo en BDN también, pero no creo que sean cosas que debas incluir en una temporización de un proyecto.
Estamos hablando de tiempos de desarrollo para cobrarle a un cliente debidamente especificados; No un papel que ponga:

Tiempo desarrollo = 1 año.
Precio = $$$$ €

Estás hablando de cosas que deberás tener montadas tú por tu cuenta si es que deseas utilizarlas, pero no tienen nada que ver con un proyecto, ni puedes cobrar por ellas a un cliente.

Empezado por mamcx

...Lo que pasa es que a veces uno le presta atencion a metodologias que estan hechas para tipos de desarrollo o tamaños de equipos de desarrollo diferentes... y no cuadran.

Sinceramente me parece un poco "despectivo" ese comentario respecto a este tipo de metodologías. Si estamos hablando de un proyecto de 1 año, no creo que sean desdeñables. Aunque está claro que con tu sistema siempre será más rápido de calcular.

[mamcx]

Empezado por Neftali

Hombre haciéndolo con tu sistema sí que es simple.
Tiempo de desarrollo = 1 año. ¡¡Y t' has quedao tan fresco!!

En mi experiencia, ese es un tiempo realista para un proyecto serio, y en base al tipo de aplicacion de la que se esta hablando no es para nada desfasado. Ahora, estoy hablando de un tiempo para un desarrollador solito o si acaso con otro.

Anteriormente y aun mas fresco, yo decia "En 3 meses esta!" e igual se demoraba 1 o 2 años. Es mejor ser pesimista y decir 1 año, y trabajar con ahinco y organizacion y sacarlo en 6 meses, que lo contrario ¿no?. Y como en el caso presente no hay ninguna informacion concreta ¿que mas se puede estimar? que se va a tomar mucho tiempo... puede que a la hora de la verdad sea menos pero hasta no sacar un calculo no se sabe.

Empezado por Neftali

Estamos hablando de Tiempos de Desarrollo de un proyecto.
El tema Subversión, control de Bugs, nant, want, ...

Bueno, pongamoslo de esta manera (ya se que toda comparacion es imperfecta):

Si vas a construir un carro y no tienes taller, no tienes planos, no tienes maquinaria adecuada, no tienes experiencia suficiente para saber que se necesita y todo tus trabajos anteriores han sido "machetazos"

VS.

Todo lo anterior

Quien se tomara *menos* tiempo? De verdad no influye el tipo de "taller" que se tenga? Quien puede mas? El del serrucho o el de la sierra electrica? Subversión, control de Bugs, nant, want (o sus alternativas) son sierras electricas.

Yo antes creia que estas cosas no valian o lo hacian por otras razones, pero he visto que tener un sistema de CVS y un lugar donde anotar los problemas, tareas y demas, automatizar los builds y las pruebas de errores son generadores de eficiencia y mejoran de forma realista los tiempos.

La primera vez que lo implemente, estaba atrasado 1 año en el desarrollo, no tenia la mas minima idea de que faltaba, no podia entregar nunca un instalador a tiempo, no sabia que errores tenia (mas alla de lo que tenia en memoria), tenia el jefe encima, los testers y estaba ya agotado de todo eso.

No teniendo nada mas que perder, le saque 1 mes a todo esto y logre terminar en unos 2 meses y llegue al punto de scar un instalador con 0 defectos (importantes) en menos de 15 minutos a cualquier hora del dia, cuando me lo pedian. Y por fin, pudimos saber y estimar cuando acabar y no me descache por mas de 1 mes, que no estuvo tan mal.

Asi que esas cosas son indicativos profundos de si se acaba o no en x tiempo? No tengo la mas minima duda.

Empezado por Neftali

Estás hablando de cosas que deberás tener montadas tú por tu cuenta si es que deseas utilizarlas, pero no tienen nada que ver con un proyecto, ni puedes cobrar por ellas a un cliente.

Claro, uno no le cobra a los clientes por tener esas herramientas (y las que recomende en el articulo como las que uso personalmente son todas gratuitas), pero el no tenerlas le pasa factura al cliente, de forma indirectas...

Empezado por Neftali

Sinceramente me parece un poco "despectivo" ese comentario respecto a este tipo de metodologías.

Aqui vale una aclaracion: No se cuales son las metodologias que se mencionaron y tampoco me referia a ellas... la verdad es que mas bien me acorde de cuando empeze hace mucho con la metodologio de Rational,la de cascada y otras que la verdad son practicamente imposibles para un equipo de menos de 5.

El comentario, en su espiritu, es acerca de verificar que la metodologia a elegir este adecuada para el tamaño y tipo de desarrollo.

--------------------

Ahora lo importante es entender que no es en si las "herramientas" o "metodologias" las que por si solas resuelven este tipo de problemas. Algo tan *simple* como hacer un cronograma de trabajo en excel ya es una gran mejora. Lo importante es hacerse a la mentalidad que si se puede, y no permitir que las excusas que abundan sean un impedimiento.

Resumiendo la idea que expone Joel, es hacer esto:

- Pones una descripcion general del proyecto, nada mas te das ideas...
- Sacas una lista de todas las tareas que haya que hacer. El truco es no poner tareas que uno diga "las hago en 1 semana" porque esas siempre son falsas. Mas bien tareas pequeñas (creo que la hago en 1 hora). Eso implica que la lista sera mas bien larga. Lo que implica que si no se quiere que sea *tan* larga entonces hay que recortarle. Luego, ese es un tiempo realista.

Le sumas vacaciones, tiempos enfermos, tiempos con problemas en el equipo, visitando a los padres , navegando en foros, hablando con clientes, hablando con la mama, etc...

Y ese es el verdadero tiempo.

Luego, ajustar la lista diariamente y anotar los avanzes.

Por ejemplo, esta es mi lista para esta semana:

Issue ID	Component	     Type	           Priority	Summary	                                       Status	Resolution
PARA-42		Clases Internas	     Nueva caracteristica  Normal	Permitir envio noticias y eventos....	       Asignado	Sin resolver
BIZ-40		Clientes Vulcano     Tarea	           Normal	Hacer cambios desing center	               Asignado	Sin resolver
BIZ-19		Clientes Vulcano     Tarea	           Importante	Pasar sitio tipalma	                       En progres   Sin resolver
THIS-35		Clases	             Nueva caracteristica  Trivial	Convertidor de imagenes	                       Asignado	Sin resolver
THIS-39		Clases	             Nueva caracteristica  Trivial	Empaquetador	                               Asignado	Sin resolver
THIS-38		Clases	             Nueva caracteristica  Trivial	Convertidor Texto	                       Asignado	Sin resolver
THIS-37		Clases	             Nueva caracteristica  Trivial	Convertidor documentos	                       Asignado	Sin resolver
THIS-36		Clases	             Nueva caracteristica  Trivial	Convertidor Video	                       Asignado	Sin resolver
THIS-34		Documentacion	     Nueva caracteristica  Trivial	Definicion del proyecto	                       En progreso	Sin resolver
PARA-24		Clases Internas	     Nueva caracteristica  Importante	Agregar ingreso y login para restaurantes      Asignado	Sin resolver	06 Nov 2006	12 Nov 2006
PARA-23		Clases Internas	     Nueva caracteristica  Trivial	Reestrucuturar entrada de categorias y tags    Asignado	Sin resolver	02 Nov 2006	30 Nov 2006
PARA-29		Clientes	     Nueva caracteristica  Normal	Envio de noticias a los visitantes	       Asignado	Sin resolver	07 Nov 2006	09 Nov 2006
PARA-28		Clases Internas	     Nueva caracteristica  Normal	Habilitar jhonBot	                       Asignado	Sin resolver	09 Nov 2006	17 Nov 2006
PARA-26		Clientes	     Nueva caracteristica  Trivial	Pagos en linea	                               Asignado	Sin resolver	21 Nov 2006	10 Dec 2006
PARA-25		Clientes	     Nueva caracteristica  Trivial	Automatizar envio de informes a los clientes   Asignado	Sin resolver	13 Nov 2006	15 Nov 2006

Noten que tiene fecha de finalizacion, y en que etapa van. Aqui esta correcion de errores, tareas pendientes, cosas que me gustaria hacer (esas son las que no tienen fechas). A cada tarea le estimo un tiempo (nunca pongo una tarea que me gaste mas de 6 horas) y luego le voy poniendo cuanto me demoro...

[Neftali [Germán.Estévez]]

Empezado por AzidRain

Lo que me cuesta trabajo es estimar el tiempo de desarrollo ya que en función de eso es lo que voy a cobrar...

Para esto hay un sistema que se conoce como "Métricas de Software" o "Métricas para Sistema Informáticos", que básicamente es un sistema empírico de calcular tiempos (y a partir de ahí costes y demás) de desarrollo de aplicaciones. Se supone que se hace un coste a partir del análisis y luego dependiendo del lenguage de programación (y algun otro parámetro) se evaluan tiempos, y costes de desarrollo.

A parte de eso, hay aplicaciones (como ya te han comentado) que te permiten hacer un análisis detallado, aunque no son sencillas. Ya te han comentado COCOMO; También puedes buscar información sobre CANTATA o CODECHECK.

Puedes darte una vuelta por la página de la "Asociación Española de Métricas en Sistema Informáticos"; Encontrarás mucha información y seguro que más referencias.

También puedes echarle un vistao a esta página; No es tan técnica, pero explica las cosas bastantes claras, e incluso tienen algun ejemplo práctico de estimación por puntos de función.

Y éste documento PDF, también está muy bien. En el título reza: "No puedo controlar, lo que no puedo medir"

Si buscas por Internet, seguro que encuentras más...