Scribd Logo
Upload

Welcome to Scribd!

  • Leer Ing. Software

    Uploaded by

    Crisval Vallejo Rojas
    8 views34 pages
    cap 23

    Copyright

    © © All Rights Reserved

    Available Formats

    PDF or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    Report this Document
    cap 23

    Copyright:

    © All Rights Reserved
    Download as PDF or read online from Scribd
    Flag for inappropriate content
    8 views34 pages

    Leer Ing. Software

    Uploaded by

    Crisval Vallejo Rojas
    cap 23

    Copyright:

    © All Rights Reserved
    Download as PDF or read online from Scribd
    Flag for inappropriate content
    of 34
    EsTIMACION PARA ' PROYECTOS DE SOFTWARE ConcePros a gestion del proyecto de software comienza con un conjunto de activida~ CLAVE des que en grupo se denominan planificacin del proyecto, Antes de que ef ee proyecto comience el gestor del proyecto y el equipo de software deben es- . timar el trabajo que habré de realizarse, los recursos que se requeriran y el tiempo coupled ---703 ue transcurrira desde e! principio hasta el final’ Una vez que se completen estas — actividades, el equipo de software debe establecer un plan del proyecto que de- bosedo fina las tareas y fechas clave de la ingenieria del software, que identifique quién ‘on LC... .700 eae ‘es responsable de dirigir cada tarea y especifique las sepsis entre tareas herele oe ee que pueden ser determinantes en el progreso jens 7 En una excelente guia para “sobrevivir el proyecto de software”, Steve McConnell cordhon 70s (MC98] presenta Una Vision del mundlo real de la planiicacion del proyecto: onde, ae Muchos trabajadores técnicos preferirén realizar el trahajo técnico en hugar de pa- roconsiliacén 708 sar el tiempo en la planificacion. Muchos gestores técnicos no tienen suficiente en- en es ttenamiento en la gestion técnica para sentirse seguros de que su planificacion : | ‘mejorard el resultado de un proyecto. Puesto que ninguna parte quiere hacer la pla- Cone nificacién, con frecuencia no se realia. Pero las fallas para planificar es uno de tos mayor errores qué tin proyecto pueda cometer... se necesita la planificacién eficaz para resolver los problemas corriente arriba [temprano en el proyecto] a bajo costo, mas que commiente abajo tarde en el proyecto) a alto costa, EI proyecto promedio gasta a0 por cento de si tiempo en ree- laboracién: corrigiendo etrores que se cometieron en etapas tempranas del proyecto. UN visTAZO ETN a ile) CAPITULO 23 ESTIMACION'PARA PROYECTOS DE SOFTWARE McConell argumenta que cualquier proyecto puede encontrar el tiempo para pla- nificar (y adaptar el plan a lo largo del proyecto) simplemente tomando un pequeito porcentaje del tiempo que se habria gastado en la reelaboracion que ocurre debido a que no se planificé. La planificacion requiere que los gestores técnicos y los miembros del equipo de software establezcan un compromiso inicial, aun cuando sea probable que este “compromiso” pruebe estar equivocado. Siempre que se realizan estimaciones se atisba al futuro y se acepta autométicamente algtin grado de incertidumbre, Para citar a Frederick Brooks (BRO75]: INluestras técnicas de estimacion estan pobremente desarrolladas, Mas seriamente, re- flejan una suposici6n no expresada que es bastante incierta, es decir; que todo ird bien. Puesto que no estamos seguros de nuestras estimaciones, con frecuencia los gestores de software carecen de la cortés testarudez para hacer que la gente espere un buen producto. ‘Aunque la estimaci6n es tanto un arte como una ciencia, esta importante actividad no necesita realizarse en una forma improvisada. Existen técnicas utiles para la esti- macién de tiempo y esfuerzo. Las métricas del proceso y del proyecto offecen la perspectiva historica y la energia para la generacién de estimaciones cuantitativas. La experiencia (de toda la gente involucrada) puede auxiliar enormemente conforme se desarrollan y revisan las estimaciones. Puesto que la estimacién coloca los cimientos para las demés actividades de planificacion del proyecto, y ésta propor ciona la ruta para la ingenieria del software exitosa, se estaria mal aconsejado si se embarcara sin ella. Clouse Meas mis, conzea, mor estinaré En consecvence, crue sus conforme avance af PARTE CUATRO cisticn De PROYECTOS DE SOFTWARE La estimacion de recursos, costo y programa de trabajo para una tarea de inge- nierla de software requiere experiencia, acceso a buena informacion historica (métricas) y el valor para comprometerse con predicciones cuantitativas cuando la informaci6n cualitativa es todo lo que existe, La estimacién implica riesgo inheren- te, ' y éste conduce a la incertidumbre. La disponibilidad de informacion historica tiene una fuerte influencia en el Tiesgo de la estimaci6n. Al mirar en retrospectiva, se pueden emular las cosas que funcio- naron y mejorar las 4reas donde surgieron problemas. Cuando hay disponibles amplias métricas de software (capitulo 22) de proyectos previos, las estimaciones se hacen con mayor seguridad, los programas de trabajo se pueden establecer para evi- tar dificultades pasadas y el riesgo global se reduce. mete isi ws desasar sasfcho on lad de pr ar peprOrT) El riesgo de la estimacion se mide por el grado de incertidumbre en las estima- Clones cuantitativas establecidas para recursos, costos y programa de trabajo. Si el Ambito del proyecto se comprende en forma deficiente 0 los requisitos del proyecto estan sujetos a eventuales cambios, la incertidumbre y el riesgo de la estimacion se incrementan peligrosamente. El planificador y, en forma mas importante, el cliente deben reconocer que la variabilidad en los requisitos del software significa inestabi- lidad en costo y programa de trabajo. Sin embargo, un gestor de proyecto no debe obsesionarse con las estimaciones Los modernos enfoques de ingenieria del software (por ejemplo, modelos de proce- so incremental) asumen una vision iterativa del desarrollo. En tales enfoques es posible, aunque no siempre aceptable politicamente, reexaminar las estimaciones (cuando se conozca mas informacién) y modificarlas cuando el cliente cambia los requisitos. El objetivo de la planificacion del proyecto de software es proporcionar un marco de trabajo que permita al gestor estimar razonablemente recursos, costo y programa de trabajo. Ademés, las estimaciones deben intentar definir los escenarios de mejor y peor caso de modo que los resultados del proyecto se puedan acotar. Aunque existe un grado inherente de incertidumbre, el equipo de software se embarca en un plan establecido como consecuencia de las tareas de planificacién. Por lo tanto, el plan se debe adaptar y actualizar conforme avance el proyecto. En las secciones siguientes se estudiara cada una de las actividades asociadas con la planificacién del proyecto de software. 1 Enel capitulo 26 se presentan técnicas sistematicas para el andlisis del riesgo CAPITULO 23. ESTIMACION PARA PROYECTOS DE SOFTWARE 693 Lee AU NEKO at td Conjunto de tareas para Ja planificacién del proyecto 1. Establecer el émbito del proyecto b. Desarrollar dos o més edtimaciones empleando 2, Determinor la faciblidad, tamafio, puntos de funcién, tareas de proceso © 3) “Analizor los riesgos (eapitilo 25). cots de uso, ee insect betas Reconciliar la esimaciones. rm Z 6. Desarrollar un plan del proyecto (capitulo 24). 2. Determinar los recursos humanos requeridos. nbecerun:conjunto de treas sige: .Definir los recursos de software reutlizables. Definir una red de tareas. .Identficar los recursos del entorno. ¢. Usor herramionios de planificecién para Estimar costo y esfuerzo. 4 ret, SOO ad a : |. Definir mecanismos de seguimiento 8. Descomponer el problema t a robe. re El émbito del software describe las funciones y caracteristicas que se entregaran a los usuarios finales, los datos que son entrada y salida, el “contenido” que se presenta a los usuarios como consecuencia de emplear el software, asi como el desempenio, las restricciones, las interfases y la confiabilidad que acotan el sistema. E! ambito se defi- ne al usar una de las dos técnicas siguientes 1. Después de una comunicacién con todos los participantes se desarrolla una descripcion narrativa del Ambito de! software. Meksreuisins 2+ LOS usuarios finales desarrollan un conjunto de casos de uso? Las funciones descritas en el enunciado del ambito (0 dentro de los casos de uso) se evaluan y en algunos casos se refinan para proporcionar mas detalles antes de comenzar la estimacién. Puesto que las estimaciones de costo y programa de trabajo estén funcionalmente orientadas, con frecuencia es titil cierto grado de descompo- sicion. Las consideraciones del desempefio abarcan los requisitos de procesamiento y tiempo de respuesta. Las restricciones identifican los limites colocados en el soft. ware por el hardware externo, la memoria disponible u otros sistemas existentes Una vez identificado el Ambito (con la participacion del cliente) es razonable pre- guntar: ges posible construir software para satisfacer este ambito? 2E] proyecto es factible? Con mucha frecuencia los ingenieros de soflware soslayan estas preguntas (0 gestores o clientes impacientes los presionan para hacerlo), s6lo para verse enre- dados en un proyecto condenado al fracaso. Putnam y Myers [PUT97a] abordan este conflicto cuando escriben: 2. Los casos de uso se discutieron cori detalle en las partes 2 y 3 de este libro. Un caso de uso es una descripcién basada en escenario de la interaccion del usuario con el software, desde el punto de vista del usuario. 694 Crouse 1 ictbied del proyecto es impor ‘ona, pto una cons lec de as recesades del negocio es inchso ‘mts mga, No 2 bueno const an sistema o producto de ato tecraloga que nadie quite. PARTE CUATRO cision Dz PROYECTOS De SOFTWARE IN)o todo lo imaginable es factible, incluso ni en software, tan evanescente como puede Parecer a los extrafios. Por el contrario, la factibilidad del software tiene cuatro dimensio- nes solidas: Tecnologia: cel proyecto es técnicamente factible? Esta dentro del terrenode la disciplina? e CLAVE En los estimaciones PF bo descomposin se enfoa sobre os carters dl dominio de inhormocién, eCémo se calola of “valor esperado” para el tamaiio de software? PARTE CUATRO GESTION DE PROVECTOS DE SOFTWARE pardmetros relevantes. Luego se tienen que calcular los promedios de dominio local Cuando se estima un nuevo proyecto primero debe ubicarse en un dominio, y luego aplicar el promedio del dominio apropiado para la productividad y asi generar la esti- macion. Las técnicas de estimacién LDC y PF difieren en en cuanto al detalle requerido para descomposicién y el objetivo de la particion. Al emplear LDC como variable de estimacién la descomposicion es absolutamente esencial y con frecuencia se lleva a grados considerables de detalle. Mientras mayor sea el grado de particion es mas probable que se desarrolle una estimacidn razonablemente precisa de LDC. En las estimaciones de PF la descomposicion funciona de manera diferente. Mas que enfocarse sobre la funcién, se estima cada una de las cinco caracteristicas de dominio de informacién, asi como los 14 valores de ajuste de complejidad estudia- dos en el capitulo 15, Entonces se pueden utilizar las estimaciones resultantes para derivar un valor de PF que se pueda ligar a datos previos y empleados para generar una estimacion. Sin importar la variable de estimacion que se utilice, el planificador del proyecto comienza estimando una gama de valores para cada funcion o valor de dominio de informaci6n. Al emplear datos hist6ricos o (cuando todo lo demas falla) intuicion, ef planificador estima un valor de tamafio optimista, mas probable, y pesimista para cada funci6n 0 cuenta para cada valor de dominio de informacion. Cuando se espe cifica un rango de valores se proporciona un indicio implicito del grado de incerti- dumbre. Entonces se puede calcular un valor de tres puntos o uno esperado. El valor espe- rado para la variable de estimacion (tamatio), S, se calcula como un promedio pon derado de las estimaciones optimista (S39), mas probable (S,) y pesimista (S,.). Por ejemplo, S = (Sopt + 4Sin + Spes)/6 23-%) brinda la credibilidad més fuerte a la estimacin “mas probable" y sigue una distri- buci6n de probabilidad beta. Se supone que existe una probabilidad muy pequena de que el tamario real resultante se ubique fuera de los valores optimista y pesimista Una vez determinado el valor esperado para la variable de estimacion se aplican los datos de productividad histérica de LDC 0 PF. ¢Son correctas las estimaciones? La unica respuesta razonable a esta pregunta es: no se puede estar seguro. Cualquier técnica de estimacion, no importa cuan sofisticada sea, debe contrastarse con otro enfoque. Incluso entonces deben prevalecer el sentido comin y la experiencia. 23.6.3 Un ejemplo de estimacién basada en LDC Como ejemplo de técnicas de estimacién de LDC y PF basadas en el problema, con- sidérese un paquete de software que sera entregado para una aplicacion de diseho asistido por computadora (CAD, por sus siglas en inglés) destinado a componentes mecanicos. El software se ejecutaré en una estacion de trabajo de ingenieria y debe CAPITULO 23 _ESTIMACION PARA PROYECTOS DE SOFTWARE 701 tener interfaz con varios periféricos que incluyen raton, digitalizador, monitor de color de alta resolucién e impresora laser. Se puede elaborar una descripcién preli minar del Ambito del software: El software CAD mecénico aceptara del ingeniero datos geométricos de dos y tres dimen- siones. El ingeniero interactuaré y controlara el sistema CAD a través de una interfaz. del usuario que exhibiré caracteristicas de buen disefio de interfaz humano-maquina, Todos los datos geométricos y otra informacién de soporte se conservarén en una base de datos CAD, Se desarrollaran médulos de analisis de disefio para producir la salida requerida, la cual se desplegara en una diversidad de dispositivos graficos. El software se disenara para controlar ¢ interactuar con dispositivos periféricos que incluyen ratén, digitalizador, im- presora laser y plotter. Esta descripcién del Ambito es preliminar, no esta acotada. Se tendria que expandir cada oracién para oftecer detalle concreto y acotacién cuantitativa. Por ejemplo, antes de que comience la estimacion, el planificador debe determinar qué significa “caracteristicas de buen disefio de interfaz humano-maquina” o cuales seran el tamafio y la complejidad de la "base de datos CAD” En cuanto a los propésitos actuales, se supone que se ha llevado a cabo mis refi- namiento y que estén identificadas las grandes funciones de software mencionadas en la figura 23.2. Al continuar con la técnica de descomposicién para LDC se elabo- ra una tabla de estimacién, la cual se muestra en la figura 23.2, En cada funcién se desarrolla un rango de estimaciones LDC, Por ejemplo, el rango de las estimaciones. LDC para la funcién de andlisis geométrico 3D es: optimista, 4 600 LDC; mas proba- ble, 6.900 LDC; y pesimista, 8 600 LDC. Al aplicar la ecuaci6n 23-1 el valor esperado para la funcién de andlisis geométrico 3D es 6 800 LDC. Otras estimaciones se deri- van en forma similar. Al sumar verticalmente en la columna de LDC estimadas, se establece una estimacion de 33 200 lineas de codigo pata el sistema CAD. PARTE CUATRO GESTION DE PROYECTOS DE SOFTWARE Una revision de los datos historicos indica que el promedio organizacional de pre ductividad para sistemas de este tipo es de 620 LDC/pm, Con base en una ta laboral de 8 000 d6lares por mes, el costo por linea de cédigo es aproximadame: de 13 délares. Con base en la estimacion de LDC y los datos histéricos de product vidad, el costo total estimado del proyecto es de 431 000 dolares y el esfuierzo e mado es de 54 personas-mes,° HOGARSEGURO 23.6.4 Un ejemplo de estimacién basada en PF La descomposicion de la estimacin basada en PF se centra en los valores de dominio de informacion més que en las funciones de software. Al consultar la tabla presen- tada en la figura 23.3 el planificador del proyecto estima entradas externas, salidas extemas, consultas externas, archivos logicos internos y archivos de interfaz exter- nos para el software CAD. Los PF se calculan usando la técnica estudiada en el capi- 6 Las estimaciones estén redondeadas @ 1 000 dolares y a la persona-mes mas cercanos. Mayor pre- cision es innecesaria e irreal, dadas las limitaciones de precision de la estimacion. CAPETULO 23. EsTRMACION PARA PROYECTOS DE SOFTWARE Estimacién de valores de dominio de informacién. tulo 15. En cuanto a los propésitos de esta estimacion se supone que el factor pon- derado de complejidad es el promedio. La figura 23.3 presenta los resultados de esta estimacién. Se estima cada uno de los factores ponderados de complejidad y el valor del fac tor ajustado se calculan como se describe en el capitulo 15: £ g Respaldo y recuperacién ‘Comunicaciones de datos Procesamiento distibuido. Desempefio critica Eniorno operaiivo existente Entrada de datos en tinea Transaccién de entrada sobre paniallas miltiples IWF cctuclizado en liner Complejo de valores de dominio de informacion 10. Complejo de procesamiento inteno 11. Cédigo disefado para reutilizacién 12. Conversién/nstolocion en disefio 13. Instalaciones méltiples 14, Aplicacion diseftada para combio Factor de ajuste de valor imme ©CONOM RENO HP UGLAUUOUAL RON Finalmente, se deriva el ntimero estimado de PF: PFestimado = Conteo total x [0.65 + 0.01 = E(F)] PEestimado = 375 La productividad organizacional promedio para sistemas de este tipo es 6.5 PF/pm. Con base en una escala salarial de 8 000 ddlares por mes, el costo por PF es aproxi- madamente | 230 délares. Con base-en la estimacion de PF y los datos de producti- Ceonsie Sie tempo bo permit sel ame iad ia condo especie ls teas ela fou 23.4 Por siemple, dvd al ondiisis en sus toreas incl y este cod 0 separa, ‘Tabla de estimacién, basada en Procesos. PARTE CUATRO GEsriON De PROvECTOS DE SOFTWARE vidad historicos, el costo total estimado del proyecto es de 461 000 délares;y et esfuerzo estimado es de 58 personas-mes, 23.6.5 Estimacién basada en el proceso 1a técnica mas comtin para estimar un proyecto es basar la estimacién en el proce- So que se empleara. Esto es, el proceso se descompone en un conjunto relativa- mente pequefio de tareas y se estima el esfuerzo requerido para lograr cada tarea Al igual que las técnicas basadas en el problema, la estimacion basada en el pro- Ceso comienza con un bosquejo de las funciones del software obtenidas a partir de! Ambito del proyecto, Cada funcién requiere realizar una setie de actividades del marco de trabajo. Las funciones y actividades’ del marco de trabajo relacionadas se pre- sentan como parte de una tabla similar a la presentada en la figura 23.4. CC = comunicacién del cliente EC = evaluacién del cliente Una vez que se combinan las funciones del problema y las actividades del proce- 50, el planificador estima el esfuerzo (por ejemplo, personas-mes) que se requerira para lograr cada actividad del proceso de software en cada funcion. Estos dates constituyen la matriz central de la tabla en la figura 23.4, Entonces se aplican las tasas de trabajo promedio (es decir, costo/unidad de esfuerzo) al esfuerzo estimado. Pata cada actividad del proceso. Es muy probable que la tasa de trabajo varie en cada tarea. El equipo veterano esté enormemente involucrado en las actividades 7. las actividades del marco de trabajo que se eligen para este proyecto difieren un poco de la active dades genéricas tratacias en el capitulo 2, que son la comunicacién con el cliente (CA), la planifica- i6n, el andlisis de riesgos, la ingenieria y la construccién-liberacion a. CAPITULO 23. ESTIMACION PARA PROYECTOS DE SOFTWARE 708 tempranas del marco de trabajo y generalmente es mds costoso que el equipo menos experimentado involucrado en la construccién y liberaci6n. Los costos y el esfuerzo para cada funcién y actividad del marco de trabajo se cal- culan como él ultimo paso. Si la estimacion basada en el proceso se realiza inde- pendientemente de la estimacién de LDC 0 PF, ahora se tienen dos o tres estimacio- nes para costo y esfuerzo que se pueden comparar y armonizar. Si ambos conjuntos de estimaciones muestran una concordancia razonable, existe una buena razon para creer que las estimaciones son confiables. Si, por otra parte, los resultados de dichas técnicas de descomposicin muestran poca concordancia, se debe llevar a cabo mayor investigacion y analisis. 23.6.6 Un ejemplo de estimacién basada en el proceso Para ilustrar el uso de la estimaci6n basada en el proceso considérese de nuevo el software CAD introducido en la seccién 23.6.3. La configuracion del sistema y las funciones del software permanecen invariables y las indica el ambito del proyecto. En la tabla basada en el proceso que se muestra en la figura 23.4 las estimacio. nes del esfuerzo (en personas-mes) para cada actividad de ingenieria del software se proporcionan para cada funcion del software CAD (abreviadas para mayor rapidez) Las actividades de ingenieria y de liberacion de construccién se subdividen en las principales tareas de ingenieria del software que se muestran. Las primeras estima- clones de esfuerzo corresponden a comunicacién con el cliente, planificacién y and lisis de riesgos, las cuales se registran en la hilera total al final de la tabla. Los totales horizontal y vertical ofrecen un indicio del esfuerzo estimado que se requiere para anilisis, disefio, cddigo y prueba. Se debe senalar que 53 por ciento del esfuerzo se emplea en las tareas de ingenieria del sistema de salida (analisis de requisitos y dise- io), lo que indica la importancia relativa de este trabajo. Con base en la escala salarial promedio de 8 000 délares por mes, el costo total estimado del proyecto es de 368 000 délares , y el esfuerzo estimado es de 46 perso- has-mes. Si se desea, los promedios de trabajo pueden asociarse con cada actividad del marco de trabajo o tarea de ingenieria del software y calcularse por separado 23.6.7 Estimacién con casos de uso Como se ha sefialado a lo largo de las partes 2 y 3 de este libro, los casos de uso per- miten que un equipo de software comprenda el Ambito del software y los requisitos. sin embargo, desarrollar un enfoque de estimacién con casos de uso es problemati co por las siguientes razones [SMI99} ® Los casos de uso se describen empleando muchos formatos y estilos dife- entes; no existe un formato estandar. PARTE CUATRO GESTION DE PROYECTOS DE SOFTWARE * Los casos de uso representan una vision externa (la vision del usuario) del software y con frecuencia estan escritos con diferentes grados de abstraccién. + Los casos de uso no abordan Ja complejidad de las funciones ni de las carac- teristicas que se describen. * Los casos de uso no describen el comportamiento complejo (por ejemplo, interacciones) que involucran muchas funciones y caracteristicas, A diferencia de las LDC 0 un punto de funcién, el “caso de uso” de una persona tal vez requiera meses de esfuerzo mientras que el de otra quizé se implemente en um dia 0 dos, Aunque varios investigadores han considerado los casos de uso como una entra- daa la estimaci6n, a la fecha no ha surgido ningun método de estimacién probado Smith (SMI99] sugiere el empleo de los casos de uso en la estimacién, pero solo s Se consideran dentro del contexto de la “jerarquia estructural" que los casos de uso describen. ‘Smith argumenta que cualquier nivel de esta jerarquia estructural se describe con: no mas de 10 casos de uso. Cada uno de éstos abarcaria no mas de 30 escenarios distintos. Obviamente, los casos de uso que describen un sistema grande estan escri- tos con un gtado mucho mayor de abstraccion (y representan considerablemente més esfuerzo de desarrollo) que aquellos que describen un solo subsistema. En con- Secuencia, antes de que los casos de uso se empleen en la estimacién, se establece <1 nivel en la estructura jerarquica, se determina la longitud promedio (en paginas) de cada caso de uso, se define el tipo de software (por ejemplo, tiempo real, de nego- Cios, de ingenieria/cientifico, anidado) y se considera una arquitectura comin de! sistema. Una vez establecidas dichas caracteristicas, los datos empiricos se aprove- chan para establecer el nimero estimado de LDC o de PF por caso de uso (para cada nivel de la jerarquia). Entonces se utilizan los datos historicos para calcular el esfuer- Zo necesario para desarrollar el sistema Enseguida se ilustra como realizar este calculo; por tanto, considérese la siguien- te relacion:* LDC estimada = N x LDCprom + [(So/Sn~ 1) + (Po/Ph.~1)] X LDCyyse (23-2) donde N = ntimero real de casos de uso LDCyem = promedio historico de LDC por caso de uso para este tipo de subsis- tema 8 Es importante sefialar que la expresi6n (23-2) se emplea s6lo con propésitos ilustrativos. Al igual ue todos los modelos de estimacion, debe validarse localmente antes de que se le pueda utilizar con seguridad, CAPITULO 23 ESTIMACION PARA PROYECTOS DE SOFTWARE 707 LDC,jue = Tepresenta un ajuste con base en n por ciento de LDCpraq, donde se define localmente y representa la diferencia entre este proyecto y los proyectos “promedio” 5, = escenarios reales por caso de uso Sj = escenarios promedio por caso de uso para este tipo de subsistema P, = paginas reales por caso de uso Py = pagina promedio por caso de uso para este tipo de subsistema Con la expresiOn (23-2) se desarrolla una estimacion comtin del numero de LDC con base en el ntimero real de casos de uso ajustado mediante el mimero de scenarios y la longitud de la pagina de los casos de uso. El ajuste representa hasta n por cien- to del promedio historico de las LDC por caso de uso. 23.6.8 Un ejemplo de estimacién basada en casos de uso El software CAD presentado en la seccion 23.6.3 est compuesto de tres grupos de subsistemas: © Subsistema de interfaz del usuario (incluye FIUC) * Grupo de subsistema de ingenieria (incluye el subsistema AG2D, subsistema AG3D y el subsistema MAD) Grupo de subsistema de infraestructura (incluye el subsistema FPCG y el subsistema FCP), Seis casos de uso describen el subsistema de interfaz del usuario. Cada caso de uso lo describen no mas de 10 escenarios y tiene una longitud promedio de seis paginas. El grupo de subsistema de ingenieria lo describen 10 casos de uso (considerados en un nivel mas alto de la jerarquia estructural). Cada uno de los casos de uso no tiene mas de 20 escenarios asociados y tiene una longitud promedio de ocho paginas. Finalmente, el grupo de subsistema de infraestructura lo describen cinco casos de uso con un promedio de solo seis escenarios y una longitud promedio de cinco paginas. Con la relacién anotada en la expresién (23-2) y n = 30 por ciento se elabora la tabla de la figura 23.5. Si se considera la primera hilera de la tabla, los datos histori cos indican que el software 1U requiere un promedio de 800 LDC por caso de uso cuando éste no tiene mas de 12 escenarios y esta descrito en menos de cinco pagt CGEED Estimacién de caso de uso. casos de uso terfaz del usuario 6 yma de ingenieria 10 istema de infraestructura 5 Tolal LDC estimadas PARTE CUATRO GESTION DE PROYECTOS DE SOFTWARE nas, Estos datos se ajustan razonablemente bien para el sistema CAD. Asi pues, la estimacion de LDC para el subsistema de interfaz del usuario se calcula mediante la expresion (23-2). Si se aplica el mismo enfoque, se realizan estimaciones para los grupos de subsistemas de ingenieria ¢ infraestructura. La figura 23.5 resume las esti- maciones e indica que el tamatio global del software CAD se estima en 42 500 LDC Si se utilizan 620 LDC/pm como la productividad promedio en los sistemas de este tipo y una escala salarial de 8 000 délares por mes, el costo por linea de cédigo: es aproximadamente de 13 dolares. Con base en la estimacién de caso de uso y los datos historicos de productividad, el costo total estimado del proyecto es de 552 000 dolares, y el esfuerzo estimado es de 68 personas-mes. 23.6.9 Reconciliacién de estimaciones Las técnicas de estimacién estudiadas en las secciones precedentes dan por resultado miltiples estimaciones que deben reconciliarse para producir una sola estimacion de esfuerzo, duracién de! proyecto o costo. Este procedimiento de reconciliacién se ilustra considerando de nuevo el software CAD presentado en la seccion 23.6.3. El esfurerzo estimado total para el software CAD varia desde un bajo de 46 perso- nas-mes (obtenido empleando el enfoque de la estimacion basada en el proceso} hasta un alto de 68 personas-mes (derivado con la estimacion de caso de uso). La. estimacion promedio (que utiliza los cuatro enfoques) es de 56 personas-mes. La varia~ cién de la estimacion promedio es aproximadamente 18 por ciento en el lado bajo, y de 21 por ciento en el lado alto. 9 ‘También se han propuesto modelos orientados a PF. Entre éstos se incluyen: E = 91.4 + 0.355 PF modelo de Albrecht y Gaffney E = ~37 + 0.96 PF modelo de Kemerer E = ~12.88 + 0.405 PF modelo de regresion para proyecto pequefio Un rapido examen de estos modelos indica que cada uno producira un resultade: diferente para los mismos valores de LDC 0 PF. La implicaci6n es clara. jLos mode los de estimacién deben calibrarse para las necesidades locales! 23.7.2 El modelo COCOMO II En su libro clasico acerca de "economia de la ingenieria del software”, Barry Bochm [BOES1] introduce una jerarquia de modelos de estimacién de software que lleva e nombre de COCOMO, por COnstructive COst MOdel (Modelo Constructive de Costos) EI modelo COCOMO original se volvi6 uno de los mas ampliamente utilizados y estu- diados modelos de estimacion de costo de software en la industria, Ademds, ha evo- lucionado a un modelo de estimacién mas amplio, llamado COCOMO II [BOE96 BOEOO]. Al igual que su predecesor, COCOMO II es en realidad una jerarquia de modelos de estimacién que aborda las areas siguientes: {Ovi es ‘m punto CAPITULO 23. ESTMMACION PARA PROVECTOS DE SOFTWARE nm. ‘* Modelo de composicion de la aplicacién. Se emplea durante las primeras etapas de la ingenierfa del software, cuando son primordiales la elaboracin de prototipos de las interfases de usuario, la consideracion de la interaccién del software y el sistema, la valoracion del desempefio y la evaluacién de la madutez de la tecnologia. * Modelo de etapa de disefio temprano. Se utiliza una vez que se han estabili- zado los requisitos y se ha establecido la arquitectura basica del software. * Modelo de etapa posterior a la arquitectura. Se emplea durante la construccion del software. Al igual que los modelos de estimacién del software, los modelos COCOMO Ii requie- ren informacion de tamafio. Como parte de la jerarquia del modelo hay disponibles tres opciones diferentes de tamafio: puntos objeto, puntos de funcion y lineas de cOdigo fuente, El modelo COCOMO 11 de composicién de la aplicacion emplea puntos objeto, una medida indirecta de software que se calcula mediante conteos del miimero de 1) pan- tallas (en la interfaz del usuario), 2) reportes y 3) componentes que probablemente se requieran para construir la aplicacion, Cada instancia de objeto (por ejemplo, una pantalla o reporte) se clasifica en uno de tres niveles de complejidad (es decir, sim- ple, medio o dificil) aplicando criterios sugeridos por Boehm [BOE96]. En esencia, a complejidad es una funcién del numero y origen de las tablas de datos del cliente y el servidor que se requieren para generar la pantalla o reporte, y el mimero de vis tas 0 secciones presentadas como parte de la pantallla o el informe. Una vez que se ha determinado la complejidad, el nimero de pantallas, informes y componentes se pondera de acuerdo con la tabla ilustrada en la figura 23.6. Entonces se determina la cuenta de puntos objeto al multiplicar el nimero original de instancias de objeto por el factor de ponderacién en la figura y se suma para obte- ner una cuenta total de puntos objeto. Al aplicar el desarrollo basado en compo nentes 0 la reutilizacion general de software se estima el porcentaje de reutilizacion (Géreut) y se ajusta la cuenta de puntos objeto: NPO = (puntos objeto) x [(100 - %reut)/100] donde NPO se define como nuevos puntos objeto. Para obtener una estimacion del esfuerzo con base en el valor NPO calculado, se debe calcular una “tasa de productividad”. La figura 23.7 presenta la tasa de produc- tividad PROD = NPO/persona-mes para diferentes niveles de experiencia del desarrollador y madurez del entorno de desarrollo. Una vez determinada la tasa de productividad se puede obtener una esti maci6n del esfuerzo del proyecto de! modo siguiente: esfuerzo estimado = NPO/PROD n2 PARTE CUATRO GESMIGN DE PROVECTOS DE SOFTWARE complejidad Parc tipos de objeto [BOE96]. En modelos COCOMO II mas avanzados'” se requieren varios factores de escala_ controladores de costo y procedimientos de ajuste. El lector interesado debe k [BOE0O] 0 visitar el sitio Web de COCOMO I. 23.7.3 La ecuacién del software La ecuacién de software [PUT92] es un modelo multivariable que supone una distr! buci6n especifica del esfuerzo a lo largo de la vida de un proyecto de desarrollo software. E] modelo procede de datos de productividad recopilados de casi 4 Proyectos de software contempordneos. Con base en estos datos, un modelo de macion de la forma E = [LDC x BPP x (1/2) (23-4) donde E = esfuerzo en personas-mes 0 personas-aiio ¢ = duraci6n del proyecto en meses 0 afios B= “factor especial de habilidades”'* 10 Como se anoté anteriormente, estos modelos utilizan conteos de PF y KLDC para la variable 11 Baumenta lentamente conforme “crecen la necesidad de integracion, las pruebas, la garantia de lidad, la documentacion y las habilidades de gestion” [PUT92]. Para programas pequenios (KLDC = 4 15), B=0.16, Para programas mas grandes que 70 KLDC, B = 0.39. a CAPRTULO 23 _EsmMACION PARA PROYECTOS DE SOFTWARE n3 *parémetro' de productividad” que refleja: madurez global del proceso y practicas de gestion, la medida en la que se emplean las buenas practicas de ingenieria del software, el nivel de los lenguajes de programacién utili- zados, el estado del entorno del softwate, las habilidades y experiencias del equipo de software, y la complejidad de la aplicacién Los valores tipicos pueden ser P = 2 000 para desarrollo del software anidado de tiempo real; P = 10 000 para software de telecomunicaciones y sistemas; P = 28 000 para aplicaciones de sistemas de negocios. El parametro de productividad se puede calcular para condiciones locales si se emplean datos historicos recopilados de esfuerzos de desarrollo previos Es importante notar que la ecuacién del software tiene dos parametros indepen- dientes: 1) una estimacién del tamafio (en LDC) y 2) una estimaci6n de la duracion del proyecto en meses o aftos calendario. Putnam y Myers [PUT92] sugieren un conjunto de ecuaciones derivadas de la ecuacién del software para simplificar el proceso de estimacion y emplear una forma més comtin para su modelo de estimacién. El tiempo minimo de desarrollo se defi- ne como Cinin = 8.14(LDC/P)"* en meses para fnin > 6 meses (23-5a) E = 180B¢ en personas-mes para E = 20 personas-mes (23-Sb) Notese que t se representa en afios en la ecuacién (23-5b) Al utilizar las ecuaciones (23-5) con P = 12 000 (el valor recomendado para soft- ware cientifico) para el software CAD estudiado previamente en este capitulo, tein = 8.14(33 200/12 000)°*° trim = 12.6 meses calendario E = 180 X 0.28 x (1.05)° E = 58 personas-mes Los resultados de la ecuacion del software corresponden favorablemente con las estimaciones desarrolladas en la seccién 23.6. Al igual que el modelo COCOMO sefialado en la seccién precedente, la ecuacién del software ha evolucionado duran- te la década pasada. En [PUT97b] se puede encontrar una detallada exposicion de una version extendida de este enfoque de estimacion Vale la pena complementar los métodos convencionales de estimacién de costo del software con un enfoque disefiado explicitamente para software OO. Lorenz y Kidd [LOR94] sugieren el enfoque siguiente: 1. Desarrollar estimaciones aplicando la descomposicion de esfuerzo, andlisis de PF y cualquier atro método que sea aplicable en aplicaciones convencionales. PARTE CUATRO Gestion Dz PROYECTOS DE SOFTWARE 2. Aplicar el modelado de andlisis orientado a objetos (capitulo 8), desarrollar casos de uso y determinar un conteo. Reconocer que el numero de casos de uso puede cambiar conforme avance el proyecto 3. A partir del modelo de andlisis, determinar el numero de clases clave (llama~ das clases de andlisis en el capitulo 8). 4. Categorizar el tipo de interfaz para la aplicaci6n y desarrollar un multiplic para las clases de sopo ENE Tipo de interfaz Multiplicador Sin UG 20 Interiaz del usvotio basade en texto 2.25 UG 2.25 IUG complejo 3.0 a Multiplicar el nimero de clases clave (paso 3) por el multiplicador para obte- ner una estimacion del ntimero de clases de soporte. 5. Multiplicar el ntimero total de clases (clave + soporte) por el numero prome- dio de unidades de trabajo por clase. Lorenz y Kidd sugieren de 15 a 20 perso nas-dia por clase. 6. Comprobar de manera cruzada la estimacién basada en clase al multiplicar & numero promedio de unidades de trabajo por caso de uso. Las lécnicas de estimacién estudiadas en las secciones 23.6, 23.7 y 23.8 se pueden’ aplicar en cualquier proyecto de software. Sin embargo, cuando un equipo de soft ware encuentra una duracion de proyecto extremadamente corta (semanas mas que meses) —que probablemente tengan una continua corriente de cambios— la planifi- cacion del proyecto en general y la estimacion en particular se deben abreviar.? Em las secciones siguientes se examinan dos técnicas de estimacién especializadas. 23.9.1 Estimacién para desarrollo dgil Puesto que los requerimientos para un proyecto gil (capitulo 4) se definen como um Conjunto de escenarios de usuario (por ejemplo, “historias” en programacion extre- ma) es posible desarrollar un enfoque de estimacion informal, aunque razonable~ mente disciplinado y significativo dentro del contexto de la planificacién del proyec= to para cada incremento de software La estimacién para los proyectos agiles aplica un enfoque de descomposicion que abarca los pasos siguientes: 12 “Abreviar” no significa eliminar. incluso los proyectos de corta duracién deben planificarse, y la es: timacion es el fundamento de la planificacion sélida. CAPITULO 23. ESTIMACION PARA PROYECTOS DE SOFTWARE ns 1, Cada escenario de usuario (el equivalente de un minicaso de uso creado en el comienzo mismo de un proyecto por los usuarios finales u otros participantes) se considera por separado respecto de propésitos de estimacién 2. Elescenario se descompone en el conjunto de funciones y las tareas de inge- nieria del software que se requeriran para desarrollarlo. 3a, Cada tarea se estima por separado. Nota: la estimacion se puede basar en da- tos histéricos, en un modelo empirico o en la “experiencia”. 3b. Alternativamente, l “volumen’ (tamafio) del escenario se puede estimar en LDC, PF 0 alguna otra medida orientada a volumen (por ejemplo, puntos ob- jeto) 4a. Las estimaciones de cada tarea se suman para crear una estimacion para el escenario. 4b, Alternativamente, el volumen estimado para el escenario se traduce en es- fuerzo mediante la aplicacion de datos histéricos 5. Las estimaciones de esfuerzo acerca de todos los escenarios que se imple- mentardn para un incremento de software dado se suman con el fin de desa rrollar el esfuerzo estimado para el increment Puesto que la duracién del proyecto requerido para el desarrollo de un incremento de software es bastante corta (usualmente de 3-6 semanas), este enfoque de esti- macion tiene dos propésitos: 1) asegurar que el nimero de escenarios que se inclui- ran en el incremento se integra con los recursos disponibles, y 2) establecer una base para ubicar el esfuerzo conforme se desarrolla el incremento. 23.9.2 Estimacién para proyectos de ingenieria Web Como se asent6 en el capitulo 16, los proyectos de ingenieria Web con frecuencia adoptan el modelo de proceso agil. Es factible emplear una medicion de punto de funcién modificada, en conjunto con los pasos subrayados en la seccion 23.9.1, con el fin de desarrollar una estimacion para la WebApp Roetzheim [ROEO0] sugiere los siguientes valores de dominio de informacion cuando se adaptan puntos de funcién (capitulos 15 y 22) para la estimacion WebApp: Entradas son cada pantalla o formato de entrada (por ejemplo, CGI 0 Java), cada pantalla de mantenimiento y, si en alguna parte utiliza una etiqueta de metafora de cuaderno, cada etiqueta. « Salidas son cada pagina Web estatica, cada guin de pagina Web dinamica (por ejemplo, ASP, ISAPI u otro guién DHTML) y cada reporte (ya sea que esté basado en Web o sea del todo administrativo) # Tablas son cada tabla logica en la base de datos mas, si emplea XML para almacenar datos en un archivo, cada objeto XML (0 coleccién de atributos XML) PARTE CUATRO Gustin DE PROYECTOS DE SOPTWARE « Las interfaces retienen su definicién como archivos l6gicos (por ejemplo, formatos de registro tinicos) en las fronteras exteriores del sistema « Consuiltas son cada interfaz publicada externamente o utiliza una interfaz orientada al mensaje. Un ejemplo tipico son las referencias externas DCOM o com Los puntos de funcion (calculados empleando los valores de dominio de informacion anotados) son un indicador razonable del volumen para una WebApp. Mendes y sus colegas [MENO1] sugieren que el volumen de una WebApp se deter- mina mejor mediante la recopilacién de medidas (llamadas “variables predictoras”) asociadas con la aplicacién (por ejemplo, conteo de pagina, conteo de medios audiovisuales, conteo de funcion), las caracteristicas de su pagina Web (por ejemplo complejidad de pagina, complejidad de vinculacion, complejidad grafica), sus carac- teristicas de medios audiovisuales (por ejemplo, duracién de los clips) y caracteristi- cas funcionales (por ejemplo, longitud de cédigo, longitud de codigo reutilizadoy Dichas medidas se pueden emplear en el desarrollo de modelos de estimacion empi- ECR Om ALE Cs Estimacién de estuerzo y costo Objetivos El objetivo de las herramientas de Estimate Profesional, desarrollado por el Software estimacion de esfuerzo y costo es proporcionar Productivity Center, Inc. (www.spc.com), esti basodo en contratacion. Como concepto, la subcontratacion es extremadamente simple. Las actividades de ingenieria del software se contratan con una tercera parte que realiza el trabajo CAPITULO 23. ESTIMACION PARA PROVECTOS DE SOFTWARE ng un costo mas bajo y, asi se espera, mayor calidad. El trabajo de software llevado a cabo dentro de una compaitia se reduce a una actividad de gestion de contratos.'* La decision de subcontratar puede ser estratégica 0 tactica. En el Ambito estraté- gico, los gestores comerciales consideran si una porcién significativa de todo el tra- bajo de software se puede contratar con otros. En el plano tactico, un gestor de pro- yecto determina si parte o todo un proyecto puede lograrse mejor al subcontratar el trabajo de software Sin importar la amplitud de la vision, la decision de subcontratar usualmente es financiera. Una exposicién detallada del andlisis financiero de la subcontratacion esta mas alla del Ambito de este libro y mejor se deja a otros (por ejemplo, [MIN9S)). Sin embargo, vale la pena una breve revision de los ptos y contras de la decisién. En el lado positivo, usualmente es factible ahorrar en el costo reduciendo el niimero de personal de software y las instalaciones (por ejemplo, computadoras, infraestructura) que los soportan. En el lado negativo, una compaiiia pierde cierto control sobre el software que necesita. Dado que el software es una tecnologia que diferencia sus sistemas, servicios y productos, una compaiiia corre el riesgo de poner el destino de su competitividad en las manos de una tercera parte. FNS) 1clu Le} 14 La subcontratacion se puede considerar, de manera mas general, como cualquier actividad que con: duce a la adquisicion de software 0 algunos de sus componentes con una fuente extema a la orga- nizacién de ingenieria del software. PARTE CUATRO istiGw ne pROYECTOS Dz SOFTWARE El planificador del proyecto de software debe estimar tres factores antes de que un Proyecto comience: cuanto tiempo tomara, cuanto esfuerzo requerita y cuanto per sonal estar involucrado. Ademés, el planificador debe predecir los recursos (har ware y software) que se requeriran y el riesgo involucrado. La descripcion del émbito ayuda al planificador a desarrollar estimaciones emplean- do una 0 més técnicas que se clasifican en dos amplias categorias: descamposicién y modelado empirico. 4 Las técnicas de descomposicién requieren un bosquejo de las principales funcio- Nes del software, seguido por estimaciones de 1) el ntimero de LDC, 2) valores selec- cionados dentro del dominio de informacién, 3) el numero de casos de uso, 4) 4 ntimero de personas-mes requerido para implementar cada funci6n, 0 5) el nimero de personas-mes requerido para cada actividad de ingenieria del software. Las téc- nicas empiricas usan expresiones para esfuerzo y tiempo obtenidas empiricamente para predecir estas cantidades del proyecto. Se pueden utilizar herramientas auto- matizadas para implementar un modelo empirico especifico. Por lo general, las estimaciones precisas de proyecto emplean al menos dos de Jas tres técnicas anotadas. Al comparar y reconciliar las estimaciones obtenidas com la aplicacion de diferentes técnicas, el planificador tiene mas probabilidad de calcu- CAPITULO 23. ESTIMACISN PARA PROYECTOS DE SOFTWARE 7a. Jar una estimacién precisa. La estimacién del proyecto de software nunca seré una ciencia exacta, pero una combinacién de buenos datos historicos y técnicas siste- maticas puede mejorar la precision de la estimacion [BEN92] Bennatan, E. M., Software Project Management: A Practitioner's Approach, McGraw-Hill, 1992. [BENO3] Bennatan, E. M.,“So Whatiis the State of Software Estimation?” en The Cutter Edge (hoja informativa en linea), 11 de febrero de 2002, disponible en htip://www.cutter.com. [BOESi] Boehm, B., Software Engineering Economics, Prentice-Hall, 1981 [BOES9] Boehm, B., Risk Management, IEEE Computer Society Press, 1989 [BOE96] Bochm, B., “Anchoring the Software Process", en IEEE Software, vol. 13, nim. 4, julio de 1996, pp. 73-82 [BOE00] Boehm, B. et al., Software Cost Estimation in COCOMO II, Prentice-Hall, 2000. [BRO75] Brocks, F, The Mythical Man-Month, Addison-Wesley, 1975. [GAU89} Gause, D.C. y G. M. Weinberg, Exploring Requirements: Quality Before Design, Dorset House, 1989 [HOO91] Hooper, J. y R. O. Chester, Software Reuse Guidelines and Methods, Plenum Press, 1991 UON96] Jones, C., “How Software Estimation Tools Work’, en American Programmer, vol. 9, nim. 7, julio de 1996, pp. 19-27 {LOR94) Lorenz, M. y J. Kidd, Object-Oriented Software Metrics, Prentice-Hall, 1994 [MAT94] Matson, J.,.B. Barrett y J. Mellichamp, “Software Development Cost Estimation Using Function Points’, en IEEE Trans. Software Engineering, vol. SE-20, nim. 4, abril de 1994, pp. 275-287. IMCC98] McConnell, S., Software Project Survival Guide, Microsoft Press, 1998. IMENOI] Mendes, E., N. Mosley y S, Counsell, “Web Metrics-Estimating Design and Authoring Effort’, IEEE Multimedia, enero-marzo de 2001, pp. 50-57 IMIN95] Minoli, D., Analyzing Outsourcing, McGraw-Hill, 1998, IPHI98] Phillips, D., The Software Project Managers tiandbook, IEEE Computer Society Press, 1998. [PUT78] Putnam, L., “A General Empirical Solution to the Macto Software Sizing and Estimation Problem’, en IEEE Trans. Software Engineering, vol. SE-4, riim. 4, julio de 1978, pp. 345-361 [PUT92] Putnam, L. y W. Myers, Measures for Excellence, Yourdon Press, 1992. [PUT97a] Putnam, L. y W. Myers, “How Solved Is the Cost Estimation Problem?’ en IEEE Software, noviembre de 1997, pp. 105-107. [PUT97b] Putnam, L. y W. Myers, Industrial Strength Software: Ejfective Management Using ‘Measurement, en IEEE Computer Society Press, 1997. IROEOO] Roetzheim, w., “Estimating internet Development”, en Software Development, agosto de 2000, disponible en http://www.sdmagazine.com/documents/s=741 /sdm0008d/0008d htm. ISMI99] Smith, J., "The Estimation of Effort Based on Use Cases’, Rational Software Corp., 199, se puede descargar de http://www rational. com/media/whitepapers/finalTP17 1.PDE. 23.1, Suponga que es el gestor de proyecto de una compaiiia que construye software para robots caseros. Se le ha contratado para construir el software destinado a un robot que corta el pasto. Describa por escrito el ambito de! software. Aseguirese de que la descripcién del ambito esté acotada. Si no esté familiarizado con los robots, investigue un poco antes de comenzar a escribir. Ademas, establezca sus suposiciones acerca del hardware que se requerira.

    You might also like