Club Delphi  
    FTP   CCD     Buscar   Trucos   Trabajo   Foros

Retroceder   Foros Club Delphi > Principal > Varios
Registrarse FAQ Miembros Calendario Guía de estilo Buscar Temas de Hoy Marcar Foros Como Leídos

Grupo de Teaming del ClubDelphi

Respuesta
 
Herramientas Buscar en Tema Desplegado
  #1  
Antiguo 07-12-2015
lgarcia lgarcia is offline
Miembro
 
Registrado: jul 2004
Posts: 479
Poder: 20
lgarcia Va por buen camino
Calculo de estimado con COCOMO

Hola:
Estoy tratando de realizar un estimado de costo de un software y encontre esta formula Effort = 2.94 * EAF * (KSLOC)E, donde KSLOC son los miles de lineas de codigo, mi duda es que si las lineas de codigo son las que unos genera directamente en las Unit o si incluye todo lo que se va generando cuando uno va insertando componentes y si el sistema trabaja con bases de datos si tambien hay que incluir todas las lineas de codigos de los procedimientos almacenados que unos crea para la administracion de esa base de datos. Trabajo con Delphi 7 y MSSQL Server 2008.

Saludos
Luis Garcia
Responder Con Cita
  #2  
Antiguo 08-12-2015
Avatar de Delphius
[Delphius] Delphius is offline
Miembro Premium
 
Registrado: jul 2004
Ubicación: Salta, Argentina
Posts: 5.582
Poder: 25
Delphius Va camino a la fama
Cita:
Empezado por lgarcia Ver Mensaje
Hola:
Estoy tratando de realizar un estimado de costo de un software y encontre esta formula Effort = 2.94 * EAF * (KSLOC)E, donde KSLOC son los miles de lineas de codigo, mi duda es que si las lineas de codigo son las que unos genera directamente en las Unit o si incluye todo lo que se va generando cuando uno va insertando componentes y si el sistema trabaja con bases de datos si tambien hay que incluir todas las lineas de codigos de los procedimientos almacenados que unos crea para la administracion de esa base de datos. Trabajo con Delphi 7 y MSSQL Server 2008.

Saludos
Luis Garcia
¿Concretamente que pretendes realizar?
COCOMO se emplea para estimar esfuerzo (expresado en persona-mes), Tiempo (meses) y Personas requeridas para proyectos futuros. No se emplea en trabajos actuales y en marcha.
Necesariamente debe contarse con varios proyectos con los cuales realizar los cálculos (al menos unos 10 para empezar), compararlos, y luego se procede a ajustar los valores de las constantes para que de esta manera se apliquen y reflejen lo mejor posible tu negocio.

Además COCOMO no goza de suficientes ventajas, es bastante subjetivo y relativo y depende mucho de la visión que cada persona del equipo tenga. Al estar basado en las KLDC (así es la sigla y no la que tu pusiste) y al ser ésta una métrica bastante arcaica los resultados no necesariamente reflejan la realidad (o mejor dicho la realidad que uno pretendía medir). Medir el tamaño del software por las KLDC no necesariamente es lo mejor... eso era útil en los años 80 y principios del 90. Hoy el Software es mucho más que líneas de código y en un modelo OO como el tiene Delphi (y/o cualquier otro LOO) la métrica pierde sentido. Pero claro, al ser una métrica tan fácil, directa y rápida, de obtener la gente le sigue dando cierta utilidad. ¿Porqué? Porque las KLDC son una medida interna, de lo que sucede por dentro. En un mundo en donde el paradigma OO gobierna, lo que se ve hacia afuera son clases y no las KLDC. Justamente una forma útil en donde puede ser de ayuda las LDC (ya no hablamos de kilos), de forma indirecta, es para calcular el método ponderado por clase (MPC) para normalizar la complejidad de cada método respecto a la LDC de cada uno:
MPC = C1/LDC1 + ... + Cn/LDCn

COCOMO ha sido ampliamente estudiado y desarrollado en base a un amplio abanico de casos de estudio, se supo ganar su reputación en su momento pero bien hace la comunidad de Ingeniería de Software al señalar los riesgos de enamorarse en sus resultados (y lo mismo aplica a cualquier otra métrica, medida e indicador que se proponga)
Pero las cosas han cambiado y se han propuesto otros enfoques.... como FURPS por ejemplo que propone métricas orientadas a la "calidad" y no quedarse únicamente en una mirada en controlar el esfuerzo y la cantidad de personas. Además según el paradigma que se proponga se han ido proponiendo métricas pensadas para cada uno.
Así como carece sentido de medir el tamaño de un soft bajo OO por las KLDC, es que hay todo un mundo de medidas, métricas, e indicadores OO para todo.

La lección a todo esto es que importa más que tengas tu propio método de estimación y control de tus proyectos. Tu mismo eres libre de proponer tus propios modelos empíricos, matemáticos, cualitativos, y/o cuantitativos que mejor te sirvan. Pero volviendo a lo central, y mi pregunta inicial: ¿Que pretendes hacer?

Seriamente te invito a leer como mínimo el libro de Ingeniería de Software, un enfoque práctico de Roger S. Pressman.

Saludos,
__________________
Delphius
[Guia de estilo][Buscar]
Responder Con Cita
  #3  
Antiguo 08-12-2015
lgarcia lgarcia is offline
Miembro
 
Registrado: jul 2004
Posts: 479
Poder: 20
lgarcia Va por buen camino
Gracias Delphius por tu respuesta, pero en mi caso especifico se trata de sistemas que estan en explotacion y lo que necesito para poder recibir una remuneración es presentar un método o una formula que pueda presentar a la comision que lo evalue y que el costo no salga del aire, o sea referenciarlo contra algo. Por eso esa formula de Cocomo me podria venir bien, pero como explique en el caso de las lineas de codigo son todas las que estan en la Unit o solo las que uno va generando a traves de los eventos u otras definiciones en el programa y tambien queria esclarecerme acerca del codigo que uno va creando en los procedimientos almacenados de la BD formaban parte de eso.

Saludos
Luis Garcia
Responder Con Cita
  #4  
Antiguo 09-12-2015
Avatar de Delphius
[Delphius] Delphius is offline
Miembro Premium
 
Registrado: jul 2004
Ubicación: Salta, Argentina
Posts: 5.582
Poder: 25
Delphius Va camino a la fama
Cita:
Empezado por lgarcia Ver Mensaje
Gracias Delphius por tu respuesta, pero en mi caso especifico se trata de sistemas que estan en explotacion y lo que necesito para poder recibir una remuneración es presentar un método o una formula que pueda presentar a la comision que lo evalue y que el costo no salga del aire, o sea referenciarlo contra algo. Por eso esa formula de Cocomo me podria venir bien, pero como explique en el caso de las lineas de codigo son todas las que estan en la Unit o solo las que uno va generando a traves de los eventos u otras definiciones en el programa y tambien queria esclarecerme acerca del codigo que uno va creando en los procedimientos almacenados de la BD formaban parte de eso.

Saludos
Luis Garcia
Con más razón, ¡COCOMO no! Va de nuevo: COCOMO es para estimar proyectos a futuro en base a proyectos históricos. Si la idea es ofrecer una base sólida para argumentar el valor de tu proyecto piensa de otra forma. ¿Que vale más para ti? ¿El código? ¿tus años de experiencia? ¿O el tiempo que le invertiste en el análisis, en el diseño, la implementación y las pruebas?
COCOMO es para algo interno, le sirve al equipo de desarrollo. No tiene sentido buscarle la tuerca y tratar de ofrecerle una formulita mágica al cliente como para justificar lo que ya está hecho. Si te demoraste 6 meses, pues eso: 6 meses. No lo que te tire COCOMO. Valórate. No por aplicar un modelo "estándar" como COCOMO te hace ser más profesional.
COCOMO además no es exacto, es sólo una estimación y que hay que estar corrigiendo los coeficientes a números locales y ajustados para el negocio o empresa particular. Y para eso debe analizarse varios proyectos. Ajustarlo para que calce a este proyecto en particular es mentirse.
Tomá si queres todas las líneas, descartando comentarios, o si quieres la sección implementation... ¡de todas formas tendrás que toquetear!

Vamos por parte: convengamos que esa es la forma errada de encararlo. ¿Y si te lo rechazan? ¿Que haces con tu tiempo y esfuerzo gastado al vicio? Justamente lo que se debe hacer es definir de entrada una estimación inicial con cierto márgen de error (hacia arriba y nunca para abajo) y poner en papel y con gancho. Tener la cosa segura. Se le ofrece unos tiempos prudenciables, y unos costos esperables y si hay visto bueno recién se arranca fuerte. Naturalmente para dar dicha estimación debe haber un pre análisis y estudio del caso. Para llegar a esos números bien se podría utilizar aquellos datos históricos que gracias a COCOMO podrían ayudar... (la cosa es que tu pretendes ver lo actual con COCOMO cuando este mira el pasado para adivinar el futuro) pero lo primero y fundamental a poner en la mesa es la propia experiencia, lo que tienes por aportar, y aplicar un buen plan de viabilidad técnica-operativa, económica y legal.


Otra cosa, ¿y si resulta que la formulita de COCOMO te tira para abajo lo que esperas? ¿Que haces? Digamos que en tu cabeza ronda un numerito de 50.000 dólares y la formulita de COCOMO de libro te sale un 35.000. ¿Sos el carero? ¿O es que COCOMO infravalora? ¿Y si el esfuerzo persona-mes no es lo que en verdad te ha llevado? Y esto te lo digo porque si hay algo en lo que COCOMO falla es en proyectos medianos a chicos... se lo conoce por no ser preciso en los proyectos chicos y esto se debe a que el Modelo se basó en un estudio de mega proyectos millonarios ¡y de hace años! En el año 1997 salió COCOMO II, que al menos en lugar de usar KLDC también puede emplearse la medida Puntos de Función y algo le "calibraron" pero sigue teniendo los mismos inconvenientes de sus orígenes.

Las medidas, métricas e indicadores en Ingeniería de Software son un concepto que extrapolamos y copiamos de Ingeniería Civil... en un mundo de exactas. En Informática las cosas son más abstractas, relativas... y no hay recetas mágicas. En Civil hay formulitas que dicen esto es así y si le erras se te cae la estructura. Acá las formulitas no son nada mágicas, y no hay nada certero... tenemos blanco, negro y grises. Pesa mucho más nuestra propia experiencia e intuición que lo que te pueda decir una formulita propuesta en la universidad Yanqui y que ha estudiado en mega proyectos locales.

Con todo respeto: busca otra carta que jugar. Si la idea es ofrecer una jugada que los atraiga y le den visto bueno aporta otro enfoque.

Saludos,
__________________
Delphius
[Guia de estilo][Buscar]

Última edición por Delphius fecha: 09-12-2015 a las 04:57:14.
Responder Con Cita
  #5  
Antiguo 09-12-2015
Avatar de Delphius
[Delphius] Delphius is offline
Miembro Premium
 
Registrado: jul 2004
Ubicación: Salta, Argentina
Posts: 5.582
Poder: 25
Delphius Va camino a la fama
Para profundizar quisiera dejarte algunas palabras que expresé hace ya un buen tiempo:
Hilo 1
Hilo 2

Y de estos hilos, me quedo con éste post. Esto no lo digo porque sea bonito, sino porque me ha pasado a mi.

No es que tire mala onda, es que intentar que las cosas salgan bien por arte de magia en base a los libros y sacar formulitas de la galera para autojustificarnos no necesariamente sirve. Si han fracasado grandes proyectos informáticos aún aplicando las buenas prácticas de la Ingeniería de Software ¡mirá si un simple tipo detrás de una PC en un cuartito de 4x5 no va caer en la misma suerte!

A lo que apunto es que no hay garantías de nada. Las métricas y estimaciones son necesarias (traer orden a la casa es muy importante y nos dará un buen plan de trabajo que a la larga nos ayuda a ser mejores)... pero también son un arma de doble filo en mentes optimistas y también en las pesimistas. Un día las amas, al día siguiente te bajan del trono. ¡Yo vivo con ese amor odio!
No hay que cuidarse, y esto se aprende a por las duras... y te lo dice alguien que se viene curando desde hace años con esto de estimaciones

Por cierto, ahora recuerdo otra de Pressman... ¡Que fácil es estimar cuando uno ya tiene el proyecto hecho! La dejo de yapa para que la analicen

Saludos estimados diría Al.
__________________
Delphius
[Guia de estilo][Buscar]
Responder Con Cita
  #6  
Antiguo 09-12-2015
lgarcia lgarcia is offline
Miembro
 
Registrado: jul 2004
Posts: 479
Poder: 20
lgarcia Va por buen camino
Muchas gracias Delphius por tus sabias recomendaciones, voy a leerme esos link y vere como encuentro la mejor forma de enfrentar el problema.

Saludos
Luis Garcia
Responder Con Cita
  #7  
Antiguo 10-12-2015
Avatar de AzidRain
[AzidRain] AzidRain is offline
Miembro Premium
 
Registrado: sep 2005
Ubicación: Córdoba, Veracruz, México
Posts: 2.914
Poder: 21
AzidRain Va camino a la fama
COCOMO es super anticuado...tanto que lo utilice en un proyecto de universidad hace casi 25 años precisamente para estimar el costo de un proyecto de software sobre el cual no se había escrito ni una sola línea. No me convenció mucho en ese entonces porque su estructura se basa en cuestiones que sabemos no son determinantes en un proyecto como por ejemplo la cantidad de líneas de código que un programador promedio genera para resolver un x problema. En los años 80s lejos de programación web y lenguajes visuales y cerca de lenguajes como fortraan, cobol y otros similares, sí tenía sentido. Ahora cualquier entorno de desarrollo te genera cualquier cantidad de líneas adicionales a las que realmente el desarrollador introduzca. Coo dice Delphius en Ingeniería civil y arquitectura hay modelos que permiten definir un costo aproximado pues no son técnicas que tengan que abstraer nada, sin embargo, como toda ingeniería deben encontrar soluciones para resolver problemas, los cuales son problemas físicos y tangibles: v.g.: Hacer un hoyo y sacar el escombro que genere cuesta $XXXX, Allanar una pared con yeso de primera calidad cuesta $XXX x m2...etc. En el software esto no funciona así... Imáginate: Hacer que cada vez que un usuario se equivoque y escriba mal un emal de cliente, llegue un aviso al supervisor y a su jefe, quede un registro de que se envio el correo...Cuanto cuesta eso??? Es imposible de medir y siempre variará en función de la experiencia y habilidad de quien desarrolle la solución.
__________________
AKA "El animalito" ||Cordobés a mucha honra||
Responder Con Cita
  #8  
Antiguo 10-12-2015
Avatar de Delphius
[Delphius] Delphius is offline
Miembro Premium
 
Registrado: jul 2004
Ubicación: Salta, Argentina
Posts: 5.582
Poder: 25
Delphius Va camino a la fama
Cita:
Empezado por AzidRain Ver Mensaje
COCOMO es super anticuado...tanto que lo utilice en un proyecto de universidad hace casi 25 años precisamente para estimar el costo de un proyecto de software sobre el cual no se había escrito ni una sola línea. No me convenció mucho en ese entonces porque su estructura se basa en cuestiones que sabemos no son determinantes en un proyecto como por ejemplo la cantidad de líneas de código que un programador promedio genera para resolver un x problema. En los años 80s lejos de programación web y lenguajes visuales y cerca de lenguajes como fortraan, cobol y otros similares, sí tenía sentido. Ahora cualquier entorno de desarrollo te genera cualquier cantidad de líneas adicionales a las que realmente el desarrollador introduzca. Coo dice Delphius en Ingeniería civil y arquitectura hay modelos que permiten definir un costo aproximado pues no son técnicas que tengan que abstraer nada, sin embargo, como toda ingeniería deben encontrar soluciones para resolver problemas, los cuales son problemas físicos y tangibles: v.g.: Hacer un hoyo y sacar el escombro que genere cuesta $XXXX, Allanar una pared con yeso de primera calidad cuesta $XXX x m2...etc. En el software esto no funciona así... Imáginate: Hacer que cada vez que un usuario se equivoque y escriba mal un emal de cliente, llegue un aviso al supervisor y a su jefe, quede un registro de que se envio el correo...Cuanto cuesta eso??? Es imposible de medir y siempre variará en función de la experiencia y habilidad de quien desarrolle la solución.
Como que los ejemplos que propones están un pelín exagerados
En Ing. Civil se manejan mucho con tablas con valores ya previamente calculados. Pero para otras cosas hay todo un abaraje de ecuaciones y fórmulas que con unos cuantas variables ya te calculan la cantidad de vigas, de que tamaño, grosor de los hierros, etc. Es ciencia exacta. Es a estos ejemplos a los que apunto.
Y como que es medio absurdo buscar el precio por una "funcionalidad" extraña y traída de los pelos. Suena más real intentar predecir el costo de mantenimiento de un módulo que data de 3 años, y que ha sufrido ya 5 cambios mayores y posee 10 clases fuertemente acopladas ¿no crees?

El ejemplo que pones sobre el costo de mano de obra también medio que está tabulado... y eso lo manejan majormente más los arquitectos. Por lo general acá los Ingenieros Civiles tienen un perfil más del tipo calculista/proyeccionista y se dedican a los aspectos estructurales y la gestión de plazos y del personal y del diseño y distribución/funcionalidad de/en obra se suele delegar en arquitectos. Por lo general estas tablas de costos se define y forma parte (al menos en Argentina) de lo que se conoce como Índice de construcción. Cada provincia tiene una organización que regula esto, y las inmobiliarias, agentes de fideicomisos, constructoras, etc. toman como base para proyectar sus costos. Estos índices se actualizan mes a mes según como varía el precio de las materias primas y de la mano de obra, etc.
No estoy seguro si los arquitectos se manejaran con algo de métricas, creería que si porque recuerdo de un amigo que comentaba sobre cátedras de gestión o administración y andaban con algunos profes de Ing. Civil.
Otro concepto que recuerdo que les robamos a los Ing Civiles son los patrones. Nosotros los llamamos patrones de diseño; ellos lo llaman Lenguaje de Patrones. En escencia es lo mismo: una descripción de problema/solución para una situación particular. ¡Que manga de copiones que somos!

El problema de estimar un proyecto en Informática es que es muy abstracto y demasiado "artístico" (o como se suele decir, del estado del arte). Es un mundo creativo, que requiere otras percepciones y visiones más complejas... las interacciones son diferentes. Los equipos y distribución de trabajos son diferentes a los que encontramos en obras de construcción, etc. Amoldar las prácticas de ingeniería de otras disciplinas no es tan fácil. Por dar un ejemplo, podes estimar cuanto te demora un albañil en levantarte una pared de 4x5 con ladrillos comunes (de 15x10x3) e incluso hasta realizar métricas como m2/horas. Es una labor muy mecánica. Ponele que Juan te levanta 30m2 en 2hs, y Santiago apenas hace el mismo trabajo en 2,5h. Si el Inge necesita mandarse 10000m2 sabe como organizarse.
Es bastante habitual ver en consultores y jefes deseosos de controlar la productividad de sus desarrolladores que proponen la métrica KLDC/horas... ponele que Pedrito apenas te manda 0,128 KLDC/h (o bien 2,13 LDC/min) y se pasó 6 hrs sin teclear. Para el jefecito le parece una pérdida de tiempo, lo que no ve es que ese Pedrito es un capo que INVIRTIO esas 6h en llegar a una solución tran creativa, óptima, y eficiente que le basta con esas 128 simples LDC para el módulo que tenía a su cargo.
Acá el Jefe no tiene una idea tan aproximada de cuanto realmente va a ser necesario para llegar a la solución final (ni sabe a ciencia cierta) si en realidad es la mejor solución. ¡Sabes como desearían poder saber que el producto fuera como levantar 100 paredes!

Por esto es que a nuestros clientes no lo podemos estar dandole demasiado formulerío que esto será así, que ponemos a 4 tipos a desvelarse y alimentados por sonda con pizza triturada y 10000 litros de café y en 3 meses tendrá el soft que por poco no maneja un brazo biónico para que le haga una manuela. Necesitamos ofrecer otras maneras creativas de como justificar y poder demostrarle nuestro valor del trabajo. Los números son fríos, aburridos, académicos y nuestros clientes son humanos que viven en la tierra. Las métricas sirven para controlar nuestro trabajo de manera interna... Como dice una amiga mía... ¡tenemos que salir de nerdlandia más a menudo!

Saludos,
__________________
Delphius
[Guia de estilo][Buscar]
Responder Con Cita
  #9  
Antiguo 10-12-2015
Avatar de Casimiro Notevi
Casimiro Notevi Casimiro Notevi is offline
Moderador
 
Registrado: sep 2004
Ubicación: En algún lugar.
Posts: 32.021
Poder: 10
Casimiro Notevi Tiene un aura espectacularCasimiro Notevi Tiene un aura espectacular
Cita:
Empezado por Delphius Ver Mensaje
......
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.
Responder Con Cita
  #10  
Antiguo 10-12-2015
Avatar de Delphius
[Delphius] Delphius is offline
Miembro Premium
 
Registrado: jul 2004
Ubicación: Salta, Argentina
Posts: 5.582
Poder: 25
Delphius Va camino a la fama
Cita:
Empezado por Casimiro Notevi Ver Mensaje
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,
__________________
Delphius
[Guia de estilo][Buscar]
Responder Con Cita
  #11  
Antiguo 10-12-2015
Avatar de mamcx
mamcx mamcx is offline
Moderador
 
Registrado: sep 2004
Ubicación: Medellín - Colombia
Posts: 3.911
Poder: 25
mamcx Tiene un aura espectacularmamcx Tiene un aura espectacularmamcx Tiene un aura espectacular
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.
__________________
El malabarista.
Responder Con Cita
Respuesta


Herramientas Buscar en Tema
Buscar en Tema:

Búsqueda Avanzada
Desplegado

Normas de Publicación
no Puedes crear nuevos temas
no Puedes responder a temas
no Puedes adjuntar archivos
no Puedes editar tus mensajes

El código vB está habilitado
Las caritas están habilitado
Código [IMG] está habilitado
Código HTML está deshabilitado
Saltar a Foro

Temas Similares
Tema Autor Foro Respuestas Último mensaje
Calculo de tiempos jafera Varios 9 04-11-2010 13:08:47
Estimado Emilio (dos puntos) roman La Taberna 4 10-12-2008 17:43:53
Precedir el tiempo estimado de una descarga sagitarius Internet 1 26-01-2007 20:26:25
calculo en dbgrid dariana20 SQL 1 12-06-2006 22:32:43
calculo en SELECT mangk SQL 6 16-08-2005 21:03:55


La franja horaria es GMT +2. Ahora son las 02:07:40.


Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi
Copyright 1996-2007 Club Delphi