8 ait DATOS REALES Estimacion Contenido 8.1. Historia de la estimacién del software 8.2, Introduccién al proceso de estimacion 8.3. Estimacién del tamafio 8.4. Fstimacién del esfinerz0 8.5, Estimacién de la planificacion 8.6. Estimaciones simples de planificacién 8.7. Refinamiento de las estimaciones Temas relacionados Planificacion: Capitulo 9 Medidas: Capitulo 26 Planificacién 50/50: Seccién 6.3 ALGUNAS ESTIMACIONES SE HACEN CUIDADOSAMENTE, y otras se hacen a ojo. La mayoria de los proyectos rebasan los limites de sus planificaciones estimadas entre ¢l 25 y el 100 por 100, pero muy pocas organizaciones han logrado realizar una prediccién de Ia planifieacién can una precisin de un 10 por 100. ¢ incluso se ha llegado en algtin caso a un 5 por 100 (Jones, 1994). Una estimacién precisa de la planificacién constituye una de las bases para obtener una velocidad maxima de desarrollo. Sin tna estimacion pre- cisa de la planificacién, no se establecen las bases para una planifieacién cefectiva, y no hay soporte para el desarrollo répido (véase el Fjemplo & 1) Este capitulo nos ofrece una introduccién a la estimacién de los pro- yeetos software. Describe cémo aleanzar una buena estimacién; como ‘manipular los niimeros y crear algo razonablemente preciso, Alcanzar una 177478 Desarrollo y gestién de proyectos informaticos estimacion perfecta no es suficiente si la estimacién no es aceptada, asi que el siguiente capitulo describe cémo controlar los elementos interper- sonales implicados en la planificacién de proyectos de software, Ejemplo 8.1. Estimacién de proyectos a ojo (continia)8.1. Capitulo 8: Estimacion 179 taba claro que Carl tamposo podria cumplir la planificacion de los 10 me- ses, Anunei6 un tereer aplazamiento (a 12 meses), Cuando Car le ananic al aplazamiento, a cara de Bill se puso roja, y Ia presion lleg6 a ser més ‘ntensa, Carl empezo a sentir que su trabajo estaba en juego. ‘La codificacién jbo bastante bicn, poto unas cuantas portea necesita, ban volver a ser disefiadas e implementadas. En esas partes, el equipo no ‘abi coordinado bien los detalles de disefo, y algunas de sus implemen- taciones entraban en conflicto. En la weunién de los 11 meses del comité de supe vision, Cail auuci6 el cuaito aplazamiento, a 13 meses, ill se quer 48 livid: «Tene algnna iden de lo qne esti hacienda, le dijo a gritos ‘jObviainente no iene ni idea! {No.tiene ni idea de cudndo-va a terminar-el proyecto! ;Ahora mismo le yoy a decir cudndo va a estar terminado! (Va a estar terminado en 13 meses, 0 le voy a veypedit? jPstoy camsado de set manipolado por los Gipos del software! ;Usted y su equipo van a trabajar 60 horas @ ls seman hasta que terminen!» Carl sintié como subfa su pre- sin arterial, especialmente porque Bill nsisti6'en la planificecion tan poco fealista que habian hecho al principio, Pero €1 sabia que con cuatro aplaza- tiontad on sit huber, habla perdido toda eredibilidad, Sabie. que tendria ‘que hacer horas extras ala fuerza o te echarian del trabaio. Cart Te comet a su equipo lo qu sucedio en I euni, Els tabae {Jaron dito y consiguieron entregar el software en 13 meses. La splemen- | tacién adicional no eubrié 10s flecos det disco adicional, poro trabajando todo el mando 60 horas a la semana. a sangre y fuego. entregaron el pro- dict. Historia de la estimacién del software La estimacién del software es dificil, y lo que algunas personas intentan hacer con ella no es ni siquiera tedricamente posible. Los altos cargos, los ejecutivos, los clientes y algunos desarrolladores no parecen entender por qué la estimacién es tan dificil. Las personas que no entienden las difi- cultades inherentes a a estimacion del software pueden, de forma invo- Tuntaria, hacerla incluso mas dificil de lo que ya es. Las personas recuerdan mejar las histarias que las hechos aisladas, y hay una historia que se debe contar para explicar por qué la estimacién del, software es tan dificil. Pienso que como desarrolladores que somos, necesi- tamos contar esta historia. Hay que asegurarse de que los clientes y los directivos de cualquier nivel de la organizacion la oigan y la comprendan. El argumento basico de la estimacién del software es que el desarrollo del software es un proceso de refinamiento gradual. Se comienza con uma imagen borrosa de lo que se desea construir. y se pasa el resto del proyec- to intentando aclarar esa imagen. La estimacién del tiempo y del esfuerzo necesarios para construir e] software también es borrosa, debido a que la180 Desarrollo y gestién de proyectos informaticos imagen del software que se estd intentando construir lo es. La estimacion se puede enfocar junto con el software, lo que significa que la estimacion del proyecto del software es también un proceso de refinamiento gradual, Tas subsecciones siguientes describen la historia con més detalle Software y construccién Suponga que va a ver a su amigo Stan, que eo arquitecto, y le diee que desea eonstruirse wna casa, Comienza preguntindole a Stan si ede cons- truir una casa con tres dormitorios por 100.000 délares. Le dird que si, pero también le dird que el coste variard en funcién de las caracteristicas detalladas que desee (véase la Figura 8.1). Si se conforma con todo lo que Stan le disene, serd posible que se cum- pla su estimacién, Pero si tiene ideas eapecificas sobre Ia clase de casa que desea (si insiste en vm garaje para tres caches, cacina de hija, terraza, pis cina, estudio, dos chimeneas, molduras doradas y suelo y paredes de mar- Un ate para conetruie Blon. Vamos a empezar. una casa aqui? No hay Me core prisa.» ringun problem Figura 8.1. Es dificil saber si es posible construir el producto que e! cliente desea en el tiempo esperado hasta que se comprenda perfectannente lo yue ef cliente quiere.El ideal de una ‘mente tnstruida es (quedor salefocka ‘con el grado de precision que admita Te naturalea do wn tema, 9 no buscar la ‘exacitud cuando silo es posible ‘aleanzar wna proximacton de fa verdad. Acistoteles Capitulo 8: Eatimacin 181 ‘mol italiano, y la casa con la mejor vista del estado) su casa padria costar mucho més de 100.000 délares, aunque el arquitecto le hubiera dicho que era posible construir una casa con tres dormitorios por 100.000 délares. El desarrollo del software como un proceso de refinamiento {Cunto cuesta la nueva casa? Depende de como sea. ;Cudnto cuesta el nuevo sistema de facturacién? Depende de como sea el sistema. Algunas organizaciones desean estimar el coste con un margen de un 10 por 100, ademés antes de trabajar en la definicién de requerimientos. Aunque seria interesante tener ese grada de precisién al camien7a del prayecta, no es tedricamente posible. Al principio, se realizard una buena estimacién con un factor 2, No se puede estimar con precisién el coste del programa hasta que se comprenda con detalle cada una de las prestaciones. El desarrollo del soft- ware es un proceso cn el que se van tomando decisiones cada vez més detalladas. El concepta del producta se refina en Ia fase de requerimien- tos, los requerimientos en el disefio preliminar, el disefio preliminar en el disefio detallado y el disefio detallado en el cédigo. En cada una de estas fases se toman decisiones que afectan al coste final y a la planificacién del proyecto. La incertidumbre sobre la naturaleza del producto aporta incertidumbre a la estimacién, ya que no se pucden conocer las decisio- nes que se van a tomar hasta que na se tomen A continuacién se muestran algunos ejemplos de la clase de preguntas que aportan incertidumbre a la estimacién: # (Deseard el cliemte la prestacion X? + {Descart al clionte una versién cara o cconémica de la prestacién X? Normalmente hay al menos un factar de diferencia 10 en la dificnl- tad de la implementacién de las diferentes versiones de la misma prestacién, ‘Si se implementa la versin econémica de la prestacién X, gdesea- 14 el cliente implementar la versidn cara después de todo? ‘+ yCémo disciiaré Ia prestacién X? Normalmente hay un factor de diferencia 10 en la complejiciad del dise’ia de los diferentes tipos para la misma prestacién Cuil sera el nivel de calidad de la prestacion X? Dependiendo de la atencién que se preste durante la implementacién, puede haber un factor de diferencia 10 en el nimero de defectos contenidos en la implementacién original. ‘© Cudinto tiempo se tardard en depurar y corregir las errares cometi dos en la implementacién de la prestacién X? Dependiendo del pro-182 Desarrollo y gestién de proyectos informéticos gramador, aun teniendo el mismo nivel de experiencia, el rendi- miento en la depuracién y correccin de los mismos problemas puede variur on un faetwr de 10, + {Cudnto tiempo se emplears en integrar la prestacién X con las demas prestaciones? EFEAENCA Como se puede observar, la incertdumbre sobre tna sola prestacion paaver ZiC4 pus introduc bastante dud en la esimacign inieial del proyecie. Mul- ‘etelodo sobre as tiplicado a lo largo de todo el proyecto, se realizaran miles de decisiones noon ittgt sobre especificaciones, disefio e implementacién antes de determinar el uedor eller al coste final del proyecto, Sin embargo, conforme aumenta el porcentaje de empodeasetoe decisiones tomadas, se puede afinar el rango de estimacién. ‘Odjetives poco caros ‘secon a2, Cantidad de refinamiento posible Los investizadores han descubierto que las estimaciones de proyectos entran dentro de precisiones previsibles en varios estados del proyecto. El grifico de convergencia de estimacién de la Figura 8.2 muestra como la estimacién se hace mds precisa conforme avanza el proyecto. La Figura 8.2 mucstra las razones por las quc la catimacién del soft- ware es tan dificil. En el momento en que se pide a los desarralladores Coste del proyecto Duracisn (esfuerzo y tamatio) del proyecto 4x - ~ 1,6 2 | 1.25% | ) 15 | 448% 1.25% 1,25« ox 10x. ox ox 067% o.85 ose ox 0% 6% Dsfricén Detnen Espeaficacn Especteacion Expecicasén Progte roduto prodico requemientos deipredico ‘detalado Figura 8.2. Grafico de convergencia de estimacion. Para algunas prectacicnes dads, Ia procision de la ostimacién puede mejorar conforme €1 software se vaya refinando. Fuente: Adaptado de «Cost Models for Future Life Cicle Processes: COCOMO 2.0» (Boehm et al., 1995).Capitulo 8: Estimacion 183 que den una estimacién bruta, puede haber un factor de diferencia de 16 en- tre la mayor y la menor estimacién del esfuerzo. Incluso después de finalizar los requerimientos, s6lo se puede saber Ia cantidad del esfuerzo necesario en un 50 por 100. y en la mayoria de las organizaciones desean que esa estimacién se dé en délares. Los rangos de estimacién implicados en la Figura 8.2 se resumen numéricamente en la Tabla 8.1 ‘Como muestra la Tabla 8.1, la estimacion del proyecto deberia comen- zar de forma muy general ¢ ir refindndose conforme avanza el proyecto Los rangos son amplios, pero, aun asi, hay algunos casos extremos ‘que no estarin dentro, No hay rangos de estimacién para el caso en el que el cliente insista en el equivalente de poner mdrmol italiano por todas partes, Para utilizar los factores de 1a tabla, simplemente se multiplica la esti- ‘macién puntual «més probable por el factor optimista para obtener la estimacién optimista, y por el factor pesimista para obtener la estimacién pesimista. La estimacién se puede presentar entonces como un rango en lugar de como un punto de estimaci6n. Si la estimacién «més proba- ble» es de 50 personas-mes y ya se ha finalizado la especificacién de los requerimientos, habria que multiplicar por 0,67 y 1,5 y estimar un rango de 34 a 75 personas-mes. A veces los clientes insistiran en que se les dé tuna estimacién «més probablen, y habré que dérsela. Pero si esto no su- cede, no es necesario publicar un tinico punto de estimacién, excepto en las notas personales. Tabla 8.1. Mulliplicadores de estimacién por fase del proyecto stuerzo y tamano Planiticacion Fase Optimista Pesimista Optimista Pesimista Comepre inivial 0.25 40 0,60 1,60 del producto Concepwo del producto 0,30 20 0,80 1,23 aprobado Especificacion 0.97 13 0,85 4 de requerimientos Especificacion del diseno 0,80 1,25 0,90 del producto Especificacion del diseno 0,90 110 0,95 1,05 detallado Fuente: Adaptado de «Cost Models for Future Software Life Cycle Processes: COCO- MO 2.0» (Buchu ev ul, 1993)184 Desarrollo y gestién de proyectos informéticos REFERENCIA aUzADA Para mas ntomacon Ta eetmacén do la uanncacon yo fetrzo, veo a Socaen 6, on plenfcaciéns Por razones que se comentarin posteriormente en este capitulo, los factores optimistas y pesimistas para la estimacién de la planificacion son diferentes a los factores del csfuerzo y del tamaiio. Se supone que cn la estimacién de la planifieacién, primera se crea una estimacién del esfier- zo ¥ luego. a partir de ésta, se calcula la planificacién (el procedimiento para hacerlo se explicara posteriormente en este capitulo). Si la planifica- cin se ha estimado a ojo, seré mejor utilizar los rangos mostrados en «isfuerzo y tamaho» que los de «Planificaciony. Estimacién frente a control Lamayoria de los clientes de software desean inicialmente mis de lo que se pueden permitir. Como muestra la Figura 8.3, los clientes tienen que adaptar sus ideas sobre el producto a los recursos con los que estan dispuestos a comprometerse. A veces el cliente desearé adaptar tanto los recursos como el conjunto de prestaciones para llegar a un acuerdo entre ambos {Cémo se puede moldear el conjunto de prestaciones para encontrar los recursos disponibles? Fn el caso de la construcciin de una casa nueva podria decitle a su amigo Stan: «No sabria decirte exactamente Io que deseo, pero si sé seguro que no necesito una sauna ni una piscina, y tampoco necesito tener la mejor vista del estado, No tengo gustos excesivamente ca- +08, Considerando esto, ;podrias construirme la casa por 100.000 dolares?» Stan le dint: «Definiivamente, puedo construirt la easa por 100.000 d6- lares, pero tendrés que dejarme todo el cantral cabre la canstruceidn de Ia casa. Tendré que utilizar planos con los que el constructor ya esté fami- liarizado. Tendré que utilizar puertas, ventanas, aparatos ¢ instalaciones estindares. S6lo podré darte unas pocas opciones donde elegir en cuanto a restaclones Las prestaciones se adaptan para adecuarse a tos recursos disponibles. | Conjunto de prestacionce Conjunto de prostaciones | ff Seeaco nicer L ‘deseadoinicialmente Tamaio * Tamafo Prestaciones ‘el Prestaunes « GB pearl producto producto A Recursos Pevurses Recursos: Gisponibles “— sscparihies inelaimente inilaimente Evolucion del proyecto Evolucién del proyecto Figura 8.9. La mayoria de los proyectos software comienzan con una discordancia entre el conjunto de prestaciones deseadas y os recursos disponibles. El conjunto de recursos o de prestaciones (0 ambos) se tiene que moldear para adaptarse al otro.AEFERENCIAS Pera obloner mas informacion sobre cletiente, veer Disminién oa presion dela olanieacions: Capi 10, ‘alclentn: ye capita 37, «Gestion ‘Theory Ws. Capitulo 8: Estimacion 185 a las encimeras, alfombras y suelos. Es posible que al tmal no puedas bleu la vasa que deseas.» «Bien», le dijo, apero el limite esta en 100.000 délares. Los constructores del software eligen entre la exactitud de la estima- cién y el control del proyecto, Si se puede ser flexible en cuanto a las caracteristicas del producto, se puede tener cierto control sobre el coste y la planificacton y se puede «desarrollar segun el presupuesto». Fero ‘eas vee que haya que elegit entte incorporar una prestacién o dejarla fuera, se tendré que dejar fuera. Cada vez que haya que escoger entre implementar la mejor prestacién o una de menor coste, habré que elegir la de menor coste. Y habra que seguir el patrdn firmemente. Si unas veces se implemen- tan las mejores prestaciones y otras veces las de menor coste, no se estatd desatiollando el presupuesto. Se esté haciendo un desarcollo del software normal. Si no se pueden aceptar la diseiplina y los compromisos implicados en la aproximacién a la construccién del presupuesto. simpl mente se tendré que aceptar mucha imprecision en la estimacién inicial del proyecto, Cooperacién Hasta aqui, la historia de la estimacién se ha centrado en indicar las razones por las que no se puede dar una estimacién tan precisa como se desearia Estas son razones interesantes; sin embargo, las personas que deseen una estimacién precisa también tienen buenas razones para esperatla, y hay que pensar que se tiene la responsabilidad de ofrecer tanta informacién como se pueda. Se debe ayudar a los clientes indicéndoles las partes del proyecto que hay posibilidad de estimar. Si hay posibilidad de estimar el final de ta fase en curso, 1o mejor es decirselo, También hay que decitle cuéndo se tiene una mejor estimacién. No se debe dejar que se sientan completa mente perdidos. Hay que indicarles dénde esté el siguiente hito. Hay que hacerle comprender al cliente la estrategia a seguir. segin el conjunto de estimaciones que se intenten proporcionar, Comentarle que se actualizarin las estimaciones al final de las fases de definicion del producto, especificacion de requerimientos, diseno del producto y diseno Uetallado, Intente preparar el presupuesto, si eso le ayuda, pero hay que asegurarse de que los clientes comprendan todos los compromisos que supone esa aproximacién, Si los clientes aiin preguntan por una estimacién mas precisa de la que se les ha proporeionado, digales que no puede darsela porque ain no la conoce. Pero deje bien claro que se desea colaborar. Digale: «Tan pronto como lo sepa, se lo haré saber.»186 Desarrollo y gestién de proyectos informaticos Convergencia entre estimacién y realidad Los clientes también tienen que cooperar. Si los clientes desean Ia plani« ficacién més corta posible, no deberian presionar para reducir la estima- cién o proporcionar unas estimaciones precisas equivocadas. Como muestra la Figura 8.4, la planificacién real mas corta resulta de la programacién planificada mas precisa (Symons, 1991). Si la estima- cién cs demasiado baja, la planificacién incficiente conduciré al coste real del proyecto, Si In estimacién es demasiado alta, segiin Ia ley de Parkin- son (el trabajo se reparte para cubrir el tiempo disponible), conduciré al coste real del proyecto. El truco consiste en no realizar la estimacién ni demasiado alta ni demasiado baja, sino en el punto exacto. El objetivo de la estimacion con- siste on buscar la convergencia entre la estimacién y la realidad. Por defi- nicién, Ia estimacién y Ia realidad convergen en ls entrega del software. CCuanto antes se junten los dos caminos, podrin tomarse mejores decisiones sobre la gestién y el producto; la planificacién del proyecto y sus inter- dependencias sera mas ajustada; se podré dar una mejor relacién entre los desarrolladores, gestores, clientes, vendedores y usuarios finales; se po- dra alcanzar una mayor velocidad de desarrollo. La historia de la estimacion en pocas palabras Para contar Ia historia de la estimacién, es necesario explicar estos cuatro puntos: Paniticgctén Panteact minima % praniticacién reat - Planiieacin estimada vOe—E—oerrcrveveveree Planificacién estimada Figura 8.4, Rolacién ontro ol octuorzo cctimade y ol oefuerzo real. Una ‘estimacién demasiado bala o demasiado alta resultar en una planificacién real més larga que dptima.Capitulo 8: Estimacin 187 ‘© Construir el software es igual que construir una casa: no se puede Uevit cou exactitud eudnty va # custat hasta que ny se vonuzca con exactitud cémo va a ser. ‘© Al igual que en la construccién de una casa, puede construir la casa de sus suefios (los gastos aumentardn) o se puede construir segin un presupuesto, Si se desea construir segiin un presupuesto, hay que ser flexible en cuanto a las caracteristicas del producto. = Tanto si se construye segiin unt presupuesto o ny, el desarrollo del software es un proceso de refinamiento gradual, de forma que es inevitable que se produzca alguna imprecisién. A diferencia de la construccién de una casa, en el software la tnica forma de refinar el concepto del producto, y por lo tanto la estimacién, es constru- yendo el software. + La estimacion se puede it wefinand a lu lange del proyecto, Se puede prometer al cliente que en cada paso se iré dando una estimacién mis refinada. El Ejemplo 8.2 del final del capitulo nos muestra e6mo utilizar la his- toria de la estimacion en la vida de un proyecto. eet aera)188 Desarrollo y gestién de proyectos informéticos 8.2. Introduccién al proceso de estimacion Ahora que se han explorado a fondo las razones a las que se debe la di- ficultad de la estimacion, {como se realiza realmente una estimaci6n? Er procese pata crear una planificaciéu de desarrollo exacta consta de tres pa 1. Estimar el tamario del producto (niimero de lineas de eédigo 0 punios de funcién). Algunos proyectos saltan directamente a a estimacion de la planiticacion, pero una estimacion efectiva nevesita estinrar primero el tamativ del software pata poder truirlo. Este paso es con diferencia el mas dificil intelectualmen- ser una de las razones por las que se lo suelen 2. Estimar el esfuerzo (personas-mes). Si tiene una estimacién exacta del tamatio y los datos previos de a organizacion en proyectos similares, es fécil realizar la estimacién del esfuerz0. 3, Estimar la planificacién (meses). Una vez que se han estimado el tamaio y el esfuerzo, por razones que se explicarén posterior- mente en este capitulo, estimar la planificacién resulta casi trivial. Pero obtener la aceptacién de una estimacién de la planificacion realista puede ser la parte mas dificil del proyecto. El siguiente capitulo esté Uedivado integramente a este tema. Estos tres pasos se pueden englobar dentro de un paso mas general, ‘un metapaso: 4, Dar un intervalo de estimacion ¢ ir refinando periddicamente ese itervalo, pata ir aumentande la precisién a medida que avanza el proyecto. Las secciones siguientes describen con detalle cada uno de estos pasos. Rete cu Our amu cesCaptuio 8: Estimacion 189 8.3. Estimacién del tamafio REFERENCIA ‘CRUZADA Para mésiniormacion sobre le ecogide de medidas de proyectos, ease 0! Capito 26, Medias» ‘CRUZADA Las regis que se usan ie funcion son mucho ‘que 88 presentan aq vec» este captula. Se puede estimar el tamaiio de un proyecto de varias formas: © Utilizar un enfoque algoritmico, como los puntos de funcién, para estimar el tamaiio del programa a partir de las prestaciones (este uiéiodo se describe en Lieve). ‘+ Utilizar un software de estimacién para estimar el tamaio del pro- grama, a partir de la descripcién de las prestaciones del programa (pantallas, didlogos, archivos, tablas de la base de datos, etc) © Si ya se ha trabajado en proyectos similares, y se conoce el tamaiio, estima cada una de las partes principales del nuevo sistema como un porcentaje del lanai de una parte similar del sistema antigue Estimar el tamaio total del sistema nuevo sumando los tamavios estimados de cada una de las partes. La mayoria de programas software y algunos de los enfoques algorit- mivos reyuicten que el métody de estimacién se ajuste al entomno, antes de utilizarlo. La medida exacta de proyectos anteriores es la clave para obtener el éxito a largo plazo, utilizando cualquier tipo de estimacién (véase el recuadro de la pigina siguiente). Estimaci6n de los puntos de funcién Un punto de funciGn es una medida sintéticw del tamaiy del progtauna, que se cuele utilizar en los primeros estados del proyecto (Albrecht, 1979). Los puntos de funein son més féciles de determinar a partir de la especi- ficacién de los requerimientos que las lineas de cédigo, y proporcionan tuna medida mis exacta sobre el tamaiio del programa, Existen diferentes, métodos para contar los puntos de tuncion; el que se describe aqui se basa en «1984 IBM Method», que es la base del métody actual de IBM y del International Function Point User Groups’s (IFPUG's) (Jones, 1991), EI niimero de puntos de funcién en un programa se basa en el mimero y la complejidad de cada uno de los elementos siguientes: + Eniradas. Pautallss, formulaivs, cuadioy de didlogy, voutoles o rmensajeo, através do los euales un usuario final o cualquier otro pro- _grama pueda afadir, borrar o cambiar datos del programa. Esto inclu- ye cualquier entrada que tenga un formato tinico o un solo procesa- miento. ‘© Salidas. Pantallas, intormes, graticos 0 mensajes que el programa getters para el ustatio final 0 cualyuies of progiana, Esto inclue rye cualquier salida que tenga un formato diferente o requiera un procesamiento diferente a otros tipos de salida190 Desarrollo y gostién de proyectos informaticos Rene se clue) ‘© Consultas. Combinaciones de entrada/salida, en las que cada en- ‘rada genera una salida simple e inmediata, El término surge en el mundo de las bases de datos para hacer referencia a una bisqueda directa de un dato especitico, usando generalmente una unica clave. En las aplivaciones GUI moderas, la separacign entie las cousul- tas y las ealidas e& confusa; sin embargo, gencralmente las consultas recuperan datos directamente de una base de datos y muestran s6lo el formato elemental, mientras que las salidas pueden procesar, combinar 0 resumir datos complejos y presentar muchos formatos. Archivos logicos internos. Los principales grupos logicos de datos, jus finales v iufornacién de voutiol que estén completa- ‘mente controlados por el programa. Un archive logice podria constar {nico archivo plano o de una sola tabla en una base de datos relacional. © Archivos de interfaz externos. Archivos controlados por ottos pro- ‘gramas, con los que el programa va a iteractuar. Esto incluye cada tuny de ly principales lupus de datos lgicos o informacion de control que entre o salga del programa. La terminologfa que se utiliza en el enfoque de los puntos de funcién ‘esta poco ortentada a las bases de datos. Ei enfoque basico funciona bien para toda clase de software, pew si ny se estén constiuyendy sistemas intensivos do bases de datos tendré que ajustarse al propio entorno, ‘Como sugiere la Tabla 8.2, para caleular el nimero de puntos de fun- ccién en un programa, se toma el nimero de entradas de menor compleji-Capitulo 8: Estimacién 191 Tabla 8.2. Multiplicadores de puntos de funcién Puntas de f Caracteristicas Complejidad Complejidad Complejidad del programa baja alta ‘Niimero de entradas x3 x4 «6 Niimero de salidas x4 XS “7 Consultas x3 x4 x6 Archivos I6gicos internos x7 x10 xAS Archivos de interfaz extemnos xs xT x10 Fuente: Adaptade de Applied Safhunve Measurement (Janes, 1991), dad y se multiplica por 3. el nimero de salidas de menor complejidad y se muliiplica por 4, y asi sucesivamente con todos los demas. La suma de estos, iiimeros da «et total de los puntos de funcién sin ajustary. Posteriormente se calcula un «multiplicador de influenciay basado en 1a influenvia que tienen 14 factores sobre el programa, factores que inclu- yen comunicaciones de datos, entrads de datos en linea, complejidad del Procesamiento y facilidad de instalacién. El intervalo del multiplicador de influencia es de 0,65 a 1,35. Cuando se multiplica el total sin ajustar por el multiplicador de in- fiuencia, se obtiene la suma total de los puntos de funcion. La Yabla 8.3, muestra un ejemplo de como ubtenerlus. Lus utmeivs especificus de entradas, calidas, dgicos internos y archivos de interfaz externos que se muestran en la tabla son arbitrarios. Estos y el multiplica- dor de influencia tinicamente fueron escogidos con el objetivo de poner un ejemplo, El programa de la Labla 8.5 calcula un tamatio de 330 puntos de fun- ign, Si se hubiera ubtenide ese ndntere, se podtia compara vou el tama fo y Ia planificacién de proyectos anteriores, y ee podria estimar una planificacién a partir de éstos. También se podria utilizar el método de estimacion de primer orden de Jones, que se describird posteriormente en este capitulo, consultas, archivi Consejos sobre estimaciones A continuacién muestran algunas directrices generales para realizar Ia estimacién del tamaiio. Evite las estimaciones de improviso. En ocasiones, los desarrollado- res son atrapados por estimaciones de improviso. El jefe pregunta: «,Cudnto192 Desarrollo y gestién de proyectos informaticos [ERROR CLASICO Tabla 8.3. Ejemplo del célculo del numero de puntos de tuncién Puntas de funcidn Caracteristicas ‘Complejidad Complejidad Complejidad del programa baja medi alta ‘Niimero de entradas 6x3=18 2x4=8 3x65 18 ‘Niimero de salidas Tx$=28 7 Ox7=0 Consultas 0x3= 4% 6624 Archivos lgicos internos $x 7935 3x 15=45 Archivos de interfaz externos 9 ¥ 5 = 45 2«10=20 Total de puntos de finoin 304 sin ajustar Multiplicador 15 Total de puntos de funcién 350 ajustados ticmpo llevaria implementar la funcién de previsualizacién de impresién en Giga-Tron?s Lsted contesta: «No lo sé Pienso que me podria levar toda Ja semana. Lo comprobaré.» Se marcha a su despacho, mira el diseilo y el cédigo del programa en cuestién, observa unas cuantas cosas que habia olvidado cuando hablé con el gerente, incorpora los cambios y decide ue tardard unas cinco semanas. Répidamente va a la oficina dei gerente para actualizar Ja primera estimacién que hizo, pero el gerente esté en una rennin Posteriormente, va a informar al gerente de la sitnacién, pero antes de que pueda abrir la boca, el gerente dice: «Como me parecié un proyecto pequefio, me adelanté y pregunté si la funcién de previsualiza~ cién de impresién era aceptada en la reunién de presupuestos de esta mafiana. Todo el comite de presupuestos estaba excitado por las nuevas prestaciones y no pueden esperar hasta Ia semana préxima, ,Puedes co menzar a trabajar en él hoy mismo?» Qué ha sucedido? ;Ha sido una mala gestién? ;Un mal desarrollo? Una mala comunicacién? Probablemente ha sido un poco de las tres cosas, y se ha legado a la conclusién de que la mejor politica es simplemente no ar una estimacién de improviso. Nunca se sabe lo lejos que va x llegar, y 9 instil intentar poner condiciones; Ia gente tiene suficientes problemas intentanda recordar si propia estimacidn, y parece coma sino recardaran las condiciones que se impusieron. Reserve tiempo para la estimacién, y planifiquela. Las estimacio- nes por intuiciOn son poco precisas. Si esti estimando un proyecto gran-Capitulo 8: Estimacién 198 de, trate la estimacion como si fuera un miniproyecto, y tome el tiempo necesario para planificar la actividad de estimacién, de forma que se puc- da hacer bien. Puede que se deba a mi sangre escocesa, pero es asombro- so ver como las compaiiias suelen gastar un millén de délares en un siste- ma basado en una estimacién a vuelta de correo. Si el dinero fuera mio, emplearia el suficiente en la estimacién pata conocer si realmente el sis- tema va a costar tn millon 0 dos de délares. Use datos de proyectos anteriores. E] método mis comin utilizado para la estimacidn es la comparacién con proyectos similares realizados anteriormente, basdndose tinicamente en Ja memoria personal (Lederet y Prasad, 1992), Este método esta asociado con el retraso de la planifica- ion y el incremento del coste. La incertidumbre y Ia intuicién son tam- bién comunes, y también estén asociadas con cl retraso de la planifica- cién y el incremento del coste. Sin embargo, el uso de datos documentados. de proyectos anteriores similares contribuye a reducir el retraso de Ia pla- nificacion y del coste Use estimaciones basadas en el desarrollador. Las estimaciones hechas por personas diferentes a los desarrolladores que van a realizar el trabajo son menos precisas que las realizadas par los propios desarro- adores (Lederer y Prasad, 1992). Cuando los desarrolladores estima- Gores realizan la estimacién y el trabajo, cumplir sus propias estimaciones se refleja positivamente en su estimacién y st capacidad de trabajo. Los estimadores ajenos suelen subestimar el trabajo del otro mas que los esti- madores desarrolladores (Lederer y Prasad, 192). Estime por consenso. Cada miembro del equipo tiene que realizar la estimacién de una parte del proyecto de forma individual, y luego en una reunién se comparan las estimaciones. Se deben discutir suficientemente las diferentes estimaciones para comprender las fuentes de tales diferen- cias, Se trabaja hasta que se Hlega a un acuerdo sobre los valores mayores y menares del rango de la estimacién Estime por categorias. Simplemente se realiza una clasificacién de las partes en categorias sencillas, medias y dificiles. Se asigna un tamafio fijo a cada una de las categorias, y luego se suman esos tamanos. Estima a un bajo nivel de detalle. Dehemas hasar la estimacidn en al examen detallado de las actividades del proyecto. En general, cuanto més detallado sea el examen, mas precisa serd la estimacién, La Ley de los Grandes Nimeros dice que los errores de las sumas sern mayores que la suma de los errores. En otras palabras, un error de un 10 por 100 en una parte grande es un 10 por 100 por encima, 0 un 10 por 100 por debajo.194 Desarrollo y gestién de proyectos informéticos ERROR CLISICO Los errores de un 10 por 100 en 50 partes pequefias serdn tanto por enci- ‘ma como por debajo y tenderén a cancelarse entre sf. La suma de la dura- cién de las tareas es inversamente proporcional al retraso de Ia planifica cién y el coste (Lederer y Prasad, 1997) No omita tareas comunes. La gente no suele omitir las tareas a pro- posito, pero cuando se tiene que desarrollar el producto en el menor tiempo posible, nadie se entretiene en buscar tareas extras. A continuacién, se ‘mucstra una lista de tarcas que normalmente se omiten: recortes, conversion, de datos, instalacién, personalizacién, gestién del programa de pruebas beta, demostracién del programa a los clientes o usuarios, espera de reunio~ nes pata control de cambios, trabajos de mantenimiento en los sistemas existentes durante el proyecto, soporte técnico de los sistemas existentes durante el proyecto, correccién de defectos, administracién relacionada con el seguimiento de defectos, coordinacién eon control de calidad, so- porte para la documentacién de usuario, revisién de documentacién téc- nica, integracién, dias festivos, vacaciones, dias de baia pot enfermedad, reuniones de la empresa y departamentales y formacién. Use herramlentas de estimacion de software. Las herramientas de estimacién de software pueden generar estimaciones para una gran variedad de tamafios de proyectos, tipos de proyectos, tamaiio del equipo, contrata- cién de personal y otras variables del proyecto, En proyectos grandes, las herramientas de estimacién de software proporcionan una planificacién més precisa y una menor incidencia en los retrasos de! coste que los mé- todos de estimacién manual (Jones, 19946). Use varias técnicas distintas para la estimacidn y comparacién de los resultados. Prucbe diferentes técnicas de estimacién, y estudie Jos resultados que se obtengan. Los productores de software comercial mas sofisticado tienden a utilizar como minimo tres herramientas de estimacion y a buscar la convergencia o dispersion entre las estimaciones de planificacién. La convergencia entre las estimaciones indiea que hay probabilidad de una buena estimacién. La dispersidn indica que proha- blemente hay factores que no se han tenido en cuenta y necesitan com- prenderse mejor Si sélo se utiliza la informacién proporcionada en este capitulo, se puede estimar una planificacién basada en la evaluacién de dos cosas di- ferentes * Lineas de cédigo y las planificaciones de las Tablas de la 8.8 a 128.10. '* Puntos de funcién y método de medida de «primer orden» de Jones (Ge describird posteriormente en este capitulo).Wo tiene sentido ser ‘exacto sobre algo si ‘no se sabe siguiera de fo que se est hhablando, John von Neumann Capitulo 8: Estimacion 195 Cambie de métodos de estimacién conforme avanza el proyec- to. En los primeros estados del proyecto, sera mas precisa la estimacién con algoritmos o las tablas de consulta, Durante estas etapas, lo mejor es utilizar el software de estimacién o las Tablas de Ia 8.8 a la 8.10 de este capitulo, A la mitad del disefio, la suma de las estimaciones individuales de cada una de las tareas permitira obtener la estimacién més precisa del proyecto, que se mantendra hasta el final det mismo (Symons, 1991). Estilos de presentacion de estimaciones La forma cn que inicialmente se presente la estimacién inflaye enorme- mente en lo que suceda cuando posteriormente se necesite modificar esa estimacién, La estimacién de software normalmente conlleva una gran cantidad de riesgo e incertidumbre, y una buena estimacién capta ese riesgo y esa incertidumbre. ‘A continuacion se muestran algunas técnicas para presentar la estima vcién de la planificacién. Modificadoras més-o-menos. Ltilice una estimacién del estilo mas- o-menos para indicar tanto la cantidad como la tendencia de la incer- tidumbre en la estimacién. Es posible conocer cémo va a ser de arries- gada Ja planificacién, incluso cuando nos veamos obligados a prometer que se va a tener el software en un marco de tiempo poco realista, pre- sentando una estimacién del estilo mas-o-menos. Una estimacién de 6 meses, +1/? mes, —1/9 mes, indica que la estimacién ex hastante precisa y que hay bastante probabilidad de conseguirla. Una estimacién de 6 me- ses, + 3 meses, ~ 2 meses, indica que la estimacién no es muy precisa y que es menos probable conseguirla, Una estimacién de 6 meses, + 6 me- ses, — O meses, indica que la estimacion es bastante optimista; proba- bblemente poco realista. Rangos. Uno de los problemas de la estimacién con el estilo més-o- ‘menos es que a veces en la organizacién s6lo se difunde la parte nominal de la estimacién, Se eliminan los factores mis-o-menos, cuyo resultado pierde informacion de forma signiticativa. Si ése es el caso, una alterna- liva es utilizar un intervalo de estinracién, en vez de la estinmacion del estilo més o menos. Por ejemplo, si la estimacién es de 6 meses, + 3 me ses /~ 1 mes, se podria presentar la estimacién como de 5-9 meses. Cuantificaci6n de riesgos. Una extensién de la estimacién mas-o-me- hos consiste en explicar lo que representan los signos més y menos. En vez de decir simplemente «6 meses, + 3 meses, ~ 2 meses», se puede ailadir informacién con el formato que se muestra en la Tabla 8.4196 Desarrollo y gestién de proyectos informéticos REFERENOIA ‘CRUZADA Para ooiener mas Informacisn sobre fa gestion de los resgos sofware, vease el capo 9, «deste 8 esgos Tabla 8.4. Ejemplo de estimacién de cuantificacién de riesgos Eotimacién: 6 meses, + 3 meses, — 2 meses + I mes por el retraso en la entrega 1 mes por menos retraso del que se del subsistem de gsifivus espetaba en Ja eontiataviou de nuevos desarralladares + 1 mes por las nuevas herramientas 1 mes por las nuevas herramicntas de desarrollo que no estén de desarrollo que funcionan mejor de funcionando como se planificd Jo que se planifies +0,5 mes por baja de personal +0,5 mes por subestimacién del tamaiio ‘Cuando se documentan en la estimacién las fuentes de la incertidumbre, se proporciona a los clientes cierta informacién que se puede utilizar para reducir los riesgos en el proyecto y sentar las bases para poder explicar los cambios de la planificacién, si cualquiera de los riesgos se hiciera realidad. Cuando la estimacién se presenta de esta forma, hay que prepararse para poder contestar preguntas sobre cOmo realizar la planificactén para gestionar los riesgos y beneficiarse de las reducciones de la planificacién. Casos. Una variante de Ia estimacién de la cuantificacién de riesgos es la estimacién basada en casos. Se presenta la estimacién para el mejor y peor caso, para el caso planificado y para el caso real. Las relaciones entre las diferentes estimaciones zerdn muy interesantes. Por ejemplo, si el eas0 planificada y el mejor son el misma, y el caso real y el peor también coin- ciden, jel proyecto tiene problemas! La Tabla 8.5 muestra un ejemplo de la estimacién para un proyecto que no tiene demasiados problemas. Barry Boehm sefiala que en la practica la estimacién del «aso plani- ficado» 0 «el mas probable» tiende a acercarse al final del rango del «me- {jor caso», y los resultados reales tienden a agruparse al final del rango del ‘pear cason (Roehm, 1981). Fsto hay que tenerlo en cuenta cuando se vaya a crear y a revisar el conjunto de casos, Tabla 8.5. Eiemplo de estimacién basada en casos Caso Estimaci Mejor caso 1 abril Caso planificado 15 mayo Caso real 30 mayo Pear case 15 juin‘CRUZADA ara ooener mas ‘etalles sobre la Blantieaion det S50 Tonga un 0 por 100 de probebicad se terminato a tempo, vwoase a Secoion 63 Posilidad de twmiara tempo Capitulo 8: Estimaciin 197 Hay que estar preparado para explicar a los elientes lo que tendria que haber ocurrido para conseguir el «mejor caso» 0 caer en el «peor caso». Los clientes deseardn tener informacién de las dos posibilidades. Fechas poco precisas y periodos de tiempo. Si as estimaciones son aproxinuadas, es elatantente nigjor usar uiinerus poco precisus, comy teivet trimestre del 97 o 10 personaeado, que usar nimeroe precise engaogoe, como 19 de julio de 1997 0 520 personas-semana, Ademas de indicar que las fechas son aproximadas, los niémeros poco precisos tienen la ventaja de que no se arriesga a perder informacién cuando se simplifican, Una es- timacion de «6 meses, + 3 meses, ~ | mes» se puede reducir a ub meses». Uni estimavién de «ieiver trimestic del 97% esté excnta de tal reducci6 Factores de confianza. Una de las preguntas que la gente se suele hacer sobre una planificacién es: «{Qué probabilidad hay de mantener esta fecha?» Si se utiliza un enfoque con factotes de confianza, se puede responder a la pregunta proporctonando una estimacion similar a la de 1a Tabla 8.6. fe pueden aproximar estos intervaloe de confianza utilizando Ia esti- macién del punto «més probable» y los multiplicadores de Ia Tabla 8.1, segtin la fase del proyecto. Si se siguen los consejos que se indican en este libro, se habra creado la estimacién «més probable», de forma que se pueda uttlizar con una contianza de un 30 por 100. Multiplicando la esti- maviéu «nas probable por el factor soptimistay de la Tabla 8.1 se dard una estimacién que se puede utilizar con una confianza de un 5 por 100. Multipticando por el factor «pesimista» se dard una estimacién que se puede utilizar con una confianza de un 95 por 100, 8.4. Estimacion del esfuerzo Una vez que se tiene Ia estimacién del famaifo, se puede pasar al segundo paso de estimacién, derivar la estimacién del esfuerzo. Aunque la estima- cién no es esirictamente necesaria para estimar una planificacién del soft Tabla 8.6. Ejemplo de estimacién de factor de confianza Fecha de entrege Frobabilidad de entrega en la fecha planificada a antes de la 4 abril % 1 mayo 50% 1 junio 95%198 Desarrollo y gestién de proyectos informéticos ware, se necesitard estimar el esfuerzo para poder saber a cusintas perso- has hay que incorporar en el proyecto; y ademés, teniendo una estimacién del esfuerzo, se facilita la estimacién de la planificacién, Derivar la estimacién del esfuerzo es un proceso sencillo. A continua- cin se muestran algunas de las formas para convertir la estimacién del tamaiio en la del esfuerzo: + Utilizacién de software de estimacién para crear directamente la estimacién del esfuerzo a partir de la del tamatio. ‘© Utilizacién de las tablas de planificacién de las Tablas 8.8 a la 8.10 para convert la estimacién del tamafio en lineas de cédigo a una estimacién del esfuerzo, ‘© Uttnzacion de datos anteriores de la organizacion para estimar cuanto cesfucrzo se sealiad en proyectos anteriores del tamaiio estimade. A ‘menos que tenga fuertes razones para pensar que el proyecto nue- vo serd diferente a los proyectos anteriores de tamaiio similar, se supone que Hevaré una cantidad de esfuerzo similar. De nuevo, la mayoria de la informacién iil que se tenga en este estado son datos hustoricos (no en Ja memoria del personal) de proyectos dentro de 1a propia uiganizacion. + Usilizacién de un método algoritmico de aproximacién como el modelo COCOMO de Barry Boehm (Boehm, 1981) 0 e! modelo del ciclo de vida de Putnam y Myers (Putnam y Myers, 1992) para convertir la estimacién de las lineas de cédigo en estimacién del estuerzo. Para Ia estimacién del esfuerzo también se pueden aplicar muchos de los consejos de estimacién del tamaiio, descritos en la seccién anterior. 8.5. Estimacién de la planificaci6n El tercer paso en la estimacién de un proyecto de software es calcular la estimacién de la planificacién, Una regla es calcular la planificacién a partir de la estimacién del esfuerzo, utilizando la Ecuacién 8.1 Ecuacién 8.1. Ecuacién de la planificacién del software planificacion en meses = 3,0 personas-mes'” Si ha estimado que serdn necesarias 65 personas-mes para construit el proyecto, fa Heuacton 8.1 muestra que la planificacion Optima es de 12 meses 3,0 * 65°"), Esto implica un tamaiio éptimo del equipo de 65 per~