RESUMEN ISW CAPITULO 21 CONCEPTOS DE GESTION DE PROYECTOS 1. EL ESPECTRO DE LA GESTION La gestión eficaz de la gestión de pryects de sftware se enfca sbre las cuatr P: persnal, prduct, prces y pryect. 1.1.1 EL PERSONAL El factr human es tan imprtante que el Sftware Engineering Institute ha desarrllad un mdel de madurez de la capacidad de gestión del persnal (MMCGP). El mdel de madurez de gestión de persnal define las siguientes áreas clave prácticas para el persnal de sftware: reclutamient, selección, gestión del desempeñ, entrenamient, retribución, desarrll de la carrera, diseñ de la rganización y el trabaj, y desarrll de la cultura del equip. Las rganizacines que lgran alts niveles de madurez en el área de gestión de persnal tienen una mayr prbabilidad de implementar efectivas prácticas de ingeniería de sftware. 1.1.2 EL PRODUCTO Antes de planear un pryect se deberían establecer ls bjetivs y el ámbit del prduct, cnsiderar slucines alternativas e identificar las restriccines técnicas y de gestión. El desarrlladr del sftware y el cliente se deben reunir para definir ls bjetivs y el ámbit del prduct. Ls bjetivs identifican las metas glbales del prduct, sin cnsiderar cóm se las lgrarán. El ámbit identifica ls dats primaris, las funcines y ls cmprtamients que caracterizan al prduct y ls intents pr enlazar tales características en una frma cuantitativa. Una vez entendids ls bjetivs y el ámbit del prduct se cnsideran slucines alternativas. Aunque se trata relativamente pc detalle, las alternativas psibilitan que ls gestres y practicantes seleccinen un mejr enfque, cúmplanlas restriccines que impnen las fechas límites de entrega, las restriccines presupuestarias, la dispnibilidad del persnal, las interfaces técnicas y miles de factres más. 1.1.3 EL PROCESO Un prces de sftware prprcina el marc de trabaj desde el cual se puede establecer un plan detallad para el desarrll del sftware. Un pequeñ númer de actividades del marc de trabaj es aplicable a tds ls pryects de sftware, sin imprtar su tamañ cmplejidad. Alguns cnjunts de tareas diferentes (tareas, hits, prducts de trabaj y punts de cntrl de calidad) permiten que las actividades del marc de trabaj se adapten a las características del pryect de sftware, así cm a ls requisits del equip del pryect. Finalmente, las actividades prtectras (cntrl de calidad del sftware, la gestión de cnfiguración del sftware y la medición) cubren el mdel de prces. Las actividades prtectras sn independientes de cualquier actividad del marc de trabaj y curren durante td el prces. 1.1.4 EL PROYECTO Ls pryects de sftware se realizan de manera planificada y cntrlada pr una razón principal: es la única frma cncida de gestinar la cmplejidad. Para evitar el fracas del pryect, un gestr de pryect de sftware y ls ingeniers de sftware que cnstruyen el prduct deben eludir un cnjunt de señales de advertencia cmunes, cmprender ls factres de éxit crítics que cnducen a una buena gestión del pryect y desarrllar un enfque de sentid cmún para planificar, supervisar y cntrlar el pryect.
2. PERSONAL Ls gestres argumentan que las persnas sn l principal en ls prcess de ingeniería de sftware, per sus accines cn frecuencia cntradicen sus palabras. 2.1. LOS PARTICIPANTES El prces de sftware l integran participantes que pueden clasificarse dentr de una de cinc categrías: 1. Gestres ejecutivs: definen ls aspects del negci que usualmente tienen una influencia significativa en el pryect. 2. Gestres del pryect: quienes planifican, mtivan, rganizan y cntrlan a ls prfesinales que realizan el trabaj del sftware. 3. Prfesinales: quienes prprcinan las habilidades técnicas necesarias para realizar la ingeniería de un prduct aplicación. 4. Clientes: quienes especifican ls requisits para la ingeniería del sftware y trs elements que tienen un interés mínim en el resultad. 5. Usuaris finales: quienes interactúan cn el sftware una vez que se libera para su us prductiv. 2.2. LIDERES DE EQUIPO La gestión del pryect es una actividad intensamente humana, pr l tant, ls prfesinales cmpetentes cn frecuencia n sn buens líderes de equip. Simplemente n tienen la mezcla crrecta de habilidades cn el persnal. Weinberg sugiere un mdel MOI de liderazg, basad en la Mtivación, Organización e Innvación. Otra visión de las características que definen un gestr de pryect eficiente resalta 4 rasgs clave: Reslución de prblemas, Dtes de gestión, Incentivs e Influencia y fment de la cultura de equip 2.3. EL EQUIPO DE SOFTWARE Existen casi tantas estructuras rganizacinales de prfesinales para el desarrll de sftware cm rganizacines que tiene el mism fin. La estructura rganizacinal n puede ser fácilmente mdificada. Las precupacines acerca de las cnsecuencias prácticas y plíticas de cambi rganizacinal n están dentr del ámbit de respnsabilidad del gestr del pryect de sftware. Sin embarg, la rganización de la gente directamente invlucrada en un pryect de sftware está dentr del ámbit del gestr del pryect. Ls factres de pryect que deberían cnsiderarse cuand se planifica la estructura de ls equips de ingeniería del sftware sn: La dificultad del prblema que se reslverá. El tamañ del prgrama resultante en líneas de códig punts de función. La vida del equip. El grad en el que el prblema puede separarse en móduls. La calidad y cnfiabilidad requeridas del sistema que se cnstruirá. La rigidez de la fecha de entrega. El grad de sciabilidad que requiere el pryect. Cnstantine, sugiere 4 paradigmas rganizacinales para ls equips de ingeniería de sftware: Paradigma cerrad, estructura un equip a l larg de una jerarquía tradicinal de autridad. Ests equips pueden trabajar mejr cuand prducen sftware muy similar a ls pryects anterires, per será mens prbable que sean innvadres.
Paradigma aleatri, estructura un equip libremente y depende de la iniciativa individual de ls miembrs del equip. Cuand se requieren innvación adelants tecnlógics, ls equips que siguen el paradigma aleatri serán excelentes, per n sn recmendables cuand se requiere desempeñ rdenad. Paradigma abiert, el trabaj se desarrlla en clabración. La sólida cmunicación y la tma de decisines basada en el cnsens sn las marcas características de ls equips de paradigma abiert. Las estructuras de equip de paradigma abiert se adecuan bien a la slución de prblemas cmplejs, per n pueden desempeñarse de manera tan eficiente cm trs equips. Paradigma sincrónic, rganiza a ls miembrs del equip para trabajar en partes del prblema cn pca cmunicación activa entre ells. 2.4. EQUIPOS AGILES La filsfía ágil alienta la satisfacción del cliente y la temprana entrega incremental de sftware; pequeñs equips de trabaj enrmemente mtivads; métds infrmales; mínims prducts de trabaj de ingeniería del sftware y simplicidad glbal de desarrll. El enfque ágil subraya la cmpetencia individual en cnjunción cn la clabración del grup cm factres de éxit cruciales para el equip. Para aprvechar en frma eficiente las cmpetencias de cada miembr del equip y fmentar la clabración eficaz a l larg de un pryect de sftware, ls equips ágiles sn aut rganizads. Un equip aut rganizad n necesariamente mantiene una sla estructura de equip, sin que más bien aprvecha elements de ls paradigmas aleatri, abiert y sincrónic. 2.5. CONFLICTOS DE COORDINACION Y COMUNICACIÓN Existen muchas raznes pr las cuales ls pryects de sftware se vuelven prblemátics. La escala de muchs esfuerzs de desarrll es grande, l que cnduce a cmplejidad, cnfusión y dificultades significativas en la crdinación de ls miembrs del equip. 3. EL PRODUCTO 3.1. Ámbit del sftware La primera actividad de gestión de un pryect de sftware es la determinación del ámbit de sftware. El ámbit se define al respnder las siguientes preguntas: CONTEXTO Cóm encaja el sftware que se desarrllará en un sistema más grande, prduct cntext de negcis, y qué restriccines se impnen cm resultad del cntext? OBJETIVOS DE INFORMACION Qué bjets de dats visibles al usuari se prducen cm resultad del sftware? Qué bjets de dats se requieren de entrada? FUNCION Y DESEMPEÑO Qué funcines realiza el sftware para transfrmar ls dats de entrada en salida? Existen algunas características de desempeñ especiales que deban abrdarse? El ámbit del pryect de sftware n debe ser ambigu ni incmprensible a niveles de gestión y técnic. Se debe actar un enunciad del ámbit del sftware, es decir, se establecen de manera explícita ls dats cuantitativs, se antan las restriccines limitacines y se describen ls factres que reducen riesgs.
3.2. Descmpsición del prblema La descmpsición del prblema, a veces llamada partición elabración del prblema, es una actividad que se asienta en el núcle del análisis de requisits de sftware. La descmpsición se aplica en ds grandes áreas: La funcinalidad que debe entregarse. El prces que se empleará para entregarl. Un prblema cmplej se divide en prblemas menres que resultan más manejables. Ésta es la estrategia que se aplica cuand cmienza la planificación del pryect. Las funcines de sftware se evalúan y refinan para prprcinar más detalles antes del cmienz de la estimación. Puest que las estimacines de cst y planificación tempral están funcinalmente rientadas, cn frecuencia es útil ciert grad de descmpsición. 4. EL PROCESO El prblema que se presenta es seleccinar el mdel de prces aprpiad para que un equip de pryect smeta al sftware a ingeniería. El gestr de pryects debe decidir cuál mdel de prces es más aprpiad para: Ls clientes que han slicitad el prduct y el persnal que hará el trabaj. Las características del prduct mism. El ambiente del pryect en el que trabaja el equip de sftware. Cuand se ha seleccinad un mdel de prcess entnces el equip define un plan de pryect preliminar cn base en el cnjunt de actividades del marc del trabaj del prces. Una vez que se establece el plan preliminar, cmienza le descmpsición del prces. 4.1. Cmbinación del prduct y el prces La planeación del pryect cmienza cn la cmbinación del prduct y del prces. Cada función que el equip de sftware smeterá a ingeniería debe pasar a través del cnjunt de actividades del marc de trabaj definidas para una rganización de sftware. 4.2. Descmpsición del prces Un equip de sftware debe tener un grad significativ de flexibilidad al elegir el mdel de prcess de sftware que sea mejr para el pryect y las tareas de ingeniería de sftware que integren el mdel de prcess una vez elegid. Enfque secuencial lineal: para realizar un pryect relativamente pequeñ similar a trs que se hayan realizad. Mdel de desarrll rápid de aplicacines: utilizad cuand existen restriccines de tiemp muy ceñidas. Estrategia Incremental: utilizad cuand la fecha límite es tan ceñida que la funcinalidad cmpleta n puede alcanzarse. Pryects cn tras características cnducirán a la búsqueda de trs mdels. Una vez elegid el mdel de prces, el marc de trabaj respectiv se adapta a él. Pdrá aplicarse el marc de trabaj genéric: cmunicación, planificación, mdelad, cnstrucción y despliegue. Funcinará para mdels lineales, iterativs e incrementales, así cm evlutivs e inclus para mdels cncurrentes de ensamble de cmpnentes.
La descmpsición del prces cmienza cuand el gerente de pryect pregunta Cóm lgrarems esta actividad del marc de trabaj? 5. EL PROYECTO La gestión de un pryect de sftware exits requiere entender que puede salir mal. Jhn Reel define10 señales que indican que un pryect de sistemas de infrmación está en peligr: 1. El persnal de sftware n entiende las necesidades de sus clientes. 2. El ámbit del prduct está mal definid. 3. Ls cambis se gestinan mal. 4. La tecnlgía elegida cambia. 5. Las necesidades cmerciales cambian, están mal definidas. 6. Ls plazs de entrega n sn realistas. 7. Ls usuaris se resisten. 8. Se pierde el patrcin. 9. El equip de pryect carece de persnal. 10.Ls gestres evitan las mejres prácticas y las leccines aprendidas. La lista de las señales mencinada, sn las causas que cnducen a la regla 90-90. El primer 90% de un sistema absrbe el 90% del esfuerz y tiemp asignads. El últim 10% tma el tr 90% del esfuerz y tiemps asignads. Cóm actúa un gestr para evitar ls prblemas mencinads? Sugiere un enfque de sentid cmún de 5 partes para pryects de sftware: 1. Cmience cn el pie derech: Entender bien el prblema para establecer bien ls bjetivs y expectativas. Cnstruir el equip crrect y darle a éste autnmía, autridad y tecnlgía. 2. Mantenga el ímpetu: El gestr de pryect debe prprcinar incentivs, el equip debe resaltar la calidad en cada tarea que realiza y ls gestres ejecutivs deben hacer l psible pr mantenerse fuera del camin del equip. 3. Rastree el prgres: En un pryect de sftware el prgres se rastrea cnfrme se elabran ls prducts de trabaj(códig fuentemdels) y se aprueban cm parte de una actividad de aseguramient de calidad 4. Tmar decisines inteligentes: Las decisines del gestr de pryect y del equip de sftware deben encaminarse para mantenerl simple. 5. Realice un análisis de resultads: Establezca un mecanism cnsistente para extraer leccines aprendidas pr cada pryect. Evalúe la planificación real y la prevista, reclecte y analice métricas, btenga realimentación pr parte del equip y de ls clientes. RESUMEN Gestión de pryects de sftware: actividad prtectra dentr de la ingeniería del sftware. Cmienza antes de iniciar cualquier actividad técnica y cntinúa a l larg de la definición, el desarrll y el sprte del sftware de cmputadra. Esta actividad abarca medidas y métricas, estimación y planificación análisis de riesgs, segumient y cntrl. Las 4 P: Persnal, Prduct, Prces y Pryect. Persnal: debe estar rganizad en equips eficientes, mtivads para hacer un trabaj de sftware de alta calidad y crdinads para lgrar una cmunicación eficaz.
Prduct: ls requisits del prduct se deben cmunicar del cliente al desarrlladr, ser dividids en sus partes cnstitutivas y distribuirse para que trabaje el equip de sftware. Prces: debe adaptarse al persnal y al prblema. Se seleccina un marc de trabaj de prces cmún, se aplica un paradigma de ingeniería de sftware adecuad y se elige un cnju8nt de tareas para llevar a cab el trabaj. Pryect: debe estar rganizad en una frma que permita triunfar al equip de sftware. El element central de tds ls pryects de sftware es el PERSONAL. Ls ingeniers de sftware pueden rganizarse en diferentes estructuras de equip que van desde las jerarquías de cntrl tradicinales hasta ls equips de paradigma abiert. Se pueden aplicar varias técnicas de crdinación y cmunicación para apyar el trabaj del equip. CAPITULO 23 ESTIMACION PARA PROYECTOS DE SOFTWARE INTRODUCCION Gestión del pryect del sftware: cmienza cn un cnjunt de actividades que en grup se llaman PLANIFICACION DEL PROYECTO. Antes de que el pryect cmience, el gestr del pryect y el equip de sftware deben estimar el trabaj que habrá de realizarse, ls recurss que se requerirán y el tiemp que transcurrirá desde el principi hasta el final. Una vez que se cmpleten estas actividades, el equip de sftware debe establecer un Plan De Pryect, que defina las tareas y fechas clave de la ingeniería del sftware, que identifique quién es el respnsable de dirigir cada tarea y especifique las dependencias entre tareas que pueden ser determinantes del prgres. 1. OBSERVACIONES ACERCA DE LA ESTIMACION La planificación requiere que ls gestres técnics y ls miembrs del equip de sftware establezcan un cmprmis inicial. Aunque la estimación es tant un arte cm una ciencia, esta imprtante actividad n necesita realizarse en una frma imprvisada.
Puest que la estimación clca ls cimients para las demás actividades de planificación del pryect y ésta prprcina la ruta para la ingeniería del sftware exitsa, se estaría mal acnsejand si se embarcara sin ella. El riesg de estimación se mide pr el grad de incertidumbre de las estimacines cuantitativas establecidas para recurss, csts y prgrama de trabaj 2. EL PROCESO DE PLANIFICACION DEL PROYECTO El bjetiv de la planificación del pryect de sftware es prprcinar un marc de trabaj que permita al gestr estimar raznablemente recurss, cst y prgrama de trabaj. Además, las estimacines deben intentar definir ls escenaris de mejr y per cas de md que ls resultads del pryect se puedan actar. El plan del pryect se debe adaptar y actualizar cnfrme avance el pryect. 3. AMBITO DEL SOFTWARE Y FACTIBILIDAD El ámbit del sftware describe las funcines y características que se entregarán a ls usuaris finales, ls dats que sn entrada y salida, el cntenid que se presenta a ls usuaris cm cnsecuencia de emplear el sftware, así cm el desempeñ, las restriccines, las interfaces y la cnfiabilidad que actan al sistema. El ámbit se define al usar una de las ds técnicas siguientes: Después de una cmunicación cn tds ls participantes se desarrlla una descripción narrativa del ámbit del sftware. Ls usuaris finales desarrllan un cnjunt de cass de us. Una vez identificad el AMBITO es raznable preguntar Es psible cnstruir el sftware para satisfacer el ámbit? El pryect es factible? El AMBITO n es suficiente para cntestar las preguntas mencinadas. Una vez que el ámbit se cmprende el equip de sftware y trs deben trabajar para determinar si se puede hacer dentr de las siguientes dimensines: Tecnlgía Finanzas Tiemp Recurss 4. RECURSOS La segunda tarea de la planificación es la estimación de ls recurss necesaris para cmpletar el esfuerz de desarrll de sftware. 4.1. RECURSOS HUMANOS El planificadr cmienza evaluand el ámbit del sftware y seleccinand las habilidades requeridas para cmpletar el desarrll. Se especifican tant la psición rganizacinal cm la especialidad. El númer de persnas que requiere un pryect de sftware sl se determina después de que se ha hech una estimación del esfuerz de desarrll. 4.2. RECURSOS DE SOFTWARE REUTILIZABLES La ingeniería del sftware basada en cmpnentes enfatiza la reutilización, es decir, la creación y reutilización de blques de cnstrucción de sftware. Tales blques, usualmente llamads cmpnentes, deben catalgarse para cnsultarls cn facilidad,
estandarizarse para facilitar su aplicación y validarse para integrarls fácilmente. Bennatan sugiere 4 categrías: Cmpnentes ya desarrllads: El sftware existente se puede adquirir de un tercer se desarrlló internamente para un pryect previ (están lists y validads). Cmpnentes experimentales: Especificacines, diseñ, códig dats de prueba existentes que se desarrllarn para pryects previs similares. Cmpnentes de experiencia parcial: Especificacines, diseñ, códig dats de prueba existentes que se desarrllarn para pryects previs están relacinads cn el pryect actual, per requerirán mdificacines sustanciales. Cmpnentes nuevs: El equip de sftware debe cnstruir ls cmpnentes de sftware específicamente para las necesidades del pryect actual. 4.3. RECURSOS DEL ENTORNO El entrn que sprta un pryect de sftware, cn frecuencia denminad entrn de ingeniería de sftware (EIS), incrpra hardware y sftware. El hardware prprcina una platafrma que sprta herramientas (sftware) cn que se prducen ls prducts de trabaj basads en una buena práctica de la ingeniería del sftware. El planificadr del pryect de sftware debe especificar cada element de hardware. 5. ESTIMACION DE PROYECTOS DE SOFTWARE La estimación de cst y esfuerz nunca será una ciencia exacta. Sin embarg, la estimación del pryect se puede transfrmar de una práctica scura en una serie de pass sistemátics que prprcinan estimacines cn riesg aceptable. Para lgrar estimacines cnfiables de cst y esfuerz se tienen varias pcines: Demrar la estimación hasta más tarde en el pryect. (Pc práctica, las estimacines deben realizarse pr adelantad). Basar las estimacines en pryects similares que ya hayan sid cmpletads (Puede funcinar si el pryect en curs es muy similar a ls previs). Emplear técnicas de descmpsición relativamente simples para generar estimacines de cst y esfuerz del pryect. Utilizar un más mdels empírics en la estimación de cst esfuerz. Las últimas 2 pcines sn enfques viables, deben aplicarse juntas, cada una empleada cm una marca de verificación para la tra. 6. TECNICAS DE DESCOMPOSICION La estimación del pryect de sftware es una frma de reslver prblemas, en la mayría de ls cass cmplejs cm para cnsiderar una sla pieza. Pr ell, se descmpne el prblema. 6.1. TAMAÑO DEL SOFTWARE La precisión de la estimación de un pryect de sftware se manifiesta en varis factres: 1. El grad cn el cual el planificadr ha estimad adecuadamente el tamañ del prduct que se cnstruirá.. 2. La habilidad para traducir la estimación del tamañ en esfuerz human, prgrama de trabaj y diner.
3. El grad en el cual el plan del pryect refleja las habilidades del equip de sftware. 4. La estabilidad de ls requisits del prduct y el entrn que sprta el esfuerz de ingeniaría de sftware. Putnam y Myers sugieren 4 enfques al prblema del tamañ: 1. Tamañ de lógica difusa: El planificadr identifica el tip de aplicación, establece su magnitud. 2. Tamañ de punt de función: El planificadr desarrlla estimacines de las características del dmini de la infrmación. 3. Tamañ de cmpnentes estándar: El planificadr del pryect estima el númer de currencias de cada cmpnente estándar y lueg aplica dats de pryects histórics para determinar el tamañ de entrega pr cmpnente estándar. 4. Tamañ del cambi: El planificadr estima el númer y tip de las mdificacines que se deben lgrar 6.2. ESTIMACION BASADA EN EL PROBLEMA Las estimacines de LDC y PF sn distintas técnicas de estimación, aunque ambas tienen varias características en cmún Las técnicas de estimación LDC y PF difieren en cuant al detalle requerid para descmpsición y el bjetiv de la partición. Mientras may sea el grad de partición es más prbable que se desarrlle una estimación raznablemente precisa de LDC. 6.3. ESTIMACION BASADA EN EL PROCESO La técnica más cmún para estimar un pryect es basar la estimación en el prces que se empleará. Es decir, el prces se descmpne en un cnjunt relativamente pequeñ de tareas y se estima el esfuerz requerid para lgrar cada tarea. La estimación basada en el prces cmienza cn un bsquej de las funcines del sftware btenidas a partir del ámbit del pryect. Cada función requiere realizar un grup de actividades del marc de trabaj. Una vez que se cmbinan las funcines del prblema y las actividades del prces, el planificadr estima el esfuerz que se requerirá para lgrar cada actividad del prces de sftware en cada función. Lueg se aplica la tasa de trabaj prmedi (cst/unidad de esfuerz) al esfuerz estimad para cada actividad del prces. 6.4. ESTIMACION CON CASOS DE USO Ls cass de us permiten que un equip de sftware cmprenda el ámbit del sftware y ls requisits. Raznes pr las cuales, desarrllar un enfque de estimación cn cass de us, es prblemátic: Ls cass de us se describen empleand muchs frmats y estils diferentes, n existe un frmat estándar. Ls cass de us representan una visión externa de visión externa (del usuari), del sftware y cn frecuencia están escrits cn diferentes grads de abstracción. Ls cass de us n abrdan la cmplejidad de las funcines ni de las características que se describen. Ls cass de us n describen el cmprtamient cmplej que invlucran muchas funcines y características. A diferencia de las LDC PF, el cas de us de una persna tal vez requiera meses de esfuerz mientras que el de tra quizá se implemente en un día ds.
7. MODELOS EMPIRICOS DE ESTIMACION Ls dats empírics que apyan la mayría de ls mdels de estimación prceden de una manera limitada de pryects. Pr esta razón ningún mdel de estimación es aprpiad para tdas las clase de sftware ni en tds ls entrns de desarrll. Un mdel de estimación debe calibrarse para reflejar las cndicines lcales. El mdel debe prbarse mediante la aplicación de ls dats recpilads a partir de pryects cmpletads, clcar ls dats en el mdel y lueg cmparar ls resultads reales cn ls predichs. 8. ESTIMACION PARA PROYECTOS ORIENTADOS A OBJETOS Enfque plantead explícitamente para sftware OO: 1 Desarrllar estimacines aplicand la descmpsición del esfuerz, análisis de PF y cualquier tr métd que sea aplicable en aplicacines cnvencinales. 2 Aplicar el mdelad de análisis OO. 3 Determinar el númer de clases clave. 4 Categrizar el tip de interfaz para la aplicación. 5 Multiplicar el númer ttal de clases pr el númer prmedi de unidades de trabaj pr clase. 6 Cmprbar de manera cruzada la estimación. RESUMEN El planificadr del pryect de sftware debe estimar 3 factres antes de que un pryect cmience: Cuánt tiemp tmará. Cuánt esfuerz requerirá. Cuánt persnal está invlucrad También debe predecir ls recurss (hard y sft) que se requerirán y el riesg invlucrad. La descripción del AMBITO ayuda al planificadr a desarrllar estimacines empleand una más técnicas que se clasifican en ds amplias categrías: Descmpsición Mdel empíric Las técnicas de descmpsición requieren un bsquej de las principales funcines del sftware, seguid pr estimacines de: Númer de LDC Valres seleccinads dentr del dmini de infrmación Númer de cass de us Númer de persnas-mes requerids para implementar cada función Númer de persnas-mes requerids para cada actividad de ingeniería de sftware Las técnicas empíricas usan expresines para esfuerz y tiemp btenidas empíricamente para predecir estas cantidades del pryect.
CAPITULO 24 CALENDARIZACION DE PROYECTOS DE SOFTWARE CONCEPTOS BASICOS Aunque existen muchas raznes pr las cuales el sftware se entrega cn retras, la mayría se encuadra en una más de las siguientes causas: Una fecha límite irrealizable establecida pr alguien extern al grup de ingeniería del sftware e impuesta a ls gestres y prfesinales del grup. Cambis en ls requisits del cliente que n se reflejan en mdificacines a la calendarización. Una subestimación raznable de la cantidad de esfuerz de recurss que se requerirán para alcanzar el trabaj. Riesgs que n se cnsiderarn cuand empezó el pryect. Dificultades técnicas que n pudiern preverse. Dificultades humanas imprevisibles. Falta de cmunicación entre el persnal del pryect, l que genera demras. Una falla en la gestión del pryect prque n recnció el retras ni emprendió una acción para crregir el prblema. Pass a seguir ante una situación de fecha límite: 1. Realizar una estimación detallada usand dats de pryects previs. Determinar esfuerz y duración estimads. 2. Aplicar un mdel de prces incremental. Desarrllar una estrategia de ingeniería de sftware que entregará la funcinalidad crítica en la fecha límite impuesta, per demrará tra. 3. Reunirse cn el cliente y cn la estimación detallada, explicarle pr qué la fecha límite impuesta es irrealizable. Asegurarse de señalar que tdas las estimacines están basadas sbre el desempeñ en pryects previs. 4. Ofrezca la estrategia de desarrll incremental cm alternativa. CALENDARIZACION DE PROYECTO. A Fred Brks se le preguntó cóm se retrasan ls pryects de sftware en la calendarización y cntestó: DE UN DIA A LA VEZ La realidad de un pryect técnic es que cients de pequeñas tareas deben realizarse para lgrar una meta mayr. Si las tareas cn trayectria crítica se retrasan en la calendarización, la fecha de terminación del pryect se pne en riesg. Objetiv del Gestr: definir tdas las tareas del pryect, cnstruir una red que bsqueje sus interdependencias, identificar las tareas cruciales dentr de la red y lueg seguir su prgres para garantizar que la demra se prduce un día a la vez. Calendarización del pryect de sftware: es una actividad que distribuye estimacines de esfuerz a través de la duración planificada del pryect al asignar el esfuerz a tareas específicas de ingeniería de sftware. La calendarización evlucina a l larg del tiemp.
La calendarización para pryects de ingeniería de sftware se puede ver desde 2 perspectivas: Ya se ha establecid una fecha final para la liberación de un sistema basad en cmputadra. Supne que se han cmentad límites crnlógics aprximads, per que a la fecha final la establece la rganización de ingeniería del sftware. PRINCIPIOS BASICOS Cmpartimentación: El pryect debe dividirse en cmpartiments en varias actividades, accines y tareas manejables.(descmpner tant el prduct cm el prces). Interdependencia: Se debe determinar la interdependencia de cada actividad, acción tarea cmpartimentada. Asignación de tiemp: A cada tarea pr calendarizar se le debe asignar ciert númer de unidades de trabaj, fecha de inici, fecha de terminación. Validación del esfuerz: Td pryect tiene un númer definid de persnas en el equip de sftware. Cnfrme curre la asignación de tiemp, el gestr de pryect debe asegurarse de que, en un tiemp dad, n se han asignad más que el númer de persnas calendarizad. Definición de respnsabilidades: Tda tarea calendarizada se la debe asignar a un miembr específic del equip. Definición de resultads: Tda tarea calendarizada debe tener un resultad definid. En pryects de sftware generalmente es un prduct de trabaj. Definición de hits: Un hit se lgra cuand se ha revisad la calidad de un más prducts de trabaj y se ha aprbad RELACION ENTRE EL PERSONAL Y EL ESFUERZO MITO: Si ns retrasams en la calendarización, siempre pdems incrprar más prgramadres y recuperarns más adelante en el pryect Desgraciadamente, agregar más persnas en etapas tardías tiene un efect perturbadr sbre éste, l que prvca que la calendarización se desfase aún más. Las persnas que se agregan tienen que aprender el sistema, y la gente que les enseña es la misma que estaba haciend el trabaj. Durante la enseñanza n se realiza trabaj y el pryect experimenta mayres retrass. DEFINICION DE UN CONJUNTO DE TAREAS PARA EL PROYECTO DE SOFTWARE Es difícil desarrllar una taxnmía cmpleta de tips de pryects de sftware, en la mayría de las rganizacines del ram se encuentran ls siguientes pryects: 1. Pryects de desarrll del cncept, ls cuales se inician para explrar algunas aplicacines cncepts de negci s de alguna nueva tecnlgía. 2. Pryects de desarrll de nuevas aplicacines, ls cuales se llevan a cab cm cnsecuencia de una slicitud específica del cliente. 3. Pryects de mejra de la aplicación, ésts curren cuand el sftware existente experimenta grandes mdificacines en la función, el desempeñ las interfaces visibles para el usuari final. 4. Pryects de mantenimient de aplicación, ls cuales crrigen, adaptan extienden el sftware existente en frmas que n sean bvias inmediatamente para el usuari final.
5. Pryects de reingeniería, ésts se llevan a cab cn la finalidad de recnstruir un sistema existente en td en parte. CALENDARIZACION Técnicas que se aplican para la calendarización: PERT, CMP, GANTT. Seguimient de la calendarización La calendarización del pryect prprcina un mapa de carreteras al gestr del pryect de sftware. Si se ha realizad de manera adecuada, la calendarización del pryect define las tareas e hits que se deben seguir y cntrlar cnfrme avance el pryect. El seguimient se puede hacer de diferentes maneras: Cn la realización periódica de reunines para valrar el estad del pryect en las cuales cada un de ls miembrs del equip infrma del prgres y ls prblemas. Cn la evaluación de ls resultads de tdas las revisines realizadas a l larg del prces de ingeniería del sftware. Cn la determinación de si se han lgrad ls hits frmales del pryect en la fecha prgramada. Al cmparar la fecha de inici real cn la fecha prevista para cada tarea del pryect. Al reunirse de manera infrmal cn ls trabajadres para btener su evaluación subjetiva del prgres, hasta la fecha y ls prblemas que se vislumbran. Cn el us del análisis del valr btenid para evaluar el prgres cuantitativamente.
FILMINAS ESTIMACIONES DE SOFTWARE Prblemática de la estimación Averiguar l que cstará desarrllar una aplicación (persnas, diner, tiemp). Mment en que se desea cncer el cst. Siempre se quiere muy prnt. Cada vez que se avanza más en el pryect, y se btiene más infrmación, la estimación es más precisa. El prblema es realizar prediccines. Prces de estimación prpuest Medir l que el usuari quiere: Especificar y cuantificar l que el usuari necesita. Estimar l que cstará: Experiencia individual Experiencia de empresa Debe tenerse en cuenta la experiencia en pryects previs. Lueg de que se hayan desarrllad varis pryects, se cntará cn características claves de negci. Métds Utilizads Basads en la experiencia -Juici expert: Pur, Delphi. -Analgía -Distribución de la utilización de recurss en el cicl de vida Basads exclusivamente en ls recurss Métd basad exclusivamente en el mercad Basads en ls cmpnentes del prduct en el prces de desarrll Métds algrítmics JUICIO EXPERTO PURO Un expert estudia las especificacines y hace su estimación. Se basa fundamentalmente en ls cncimients del expert.
Si desaparece el expert la empresa deja de estimar. Si el expert n está, el equip n sabe cóm realizar las estimacines, se debe tratar de transmitir el cncimient a td el equip. Estructurand el Juici Expert Hacer una WBS cn una granularidad aceptable Usar el métd de Optimista, pesimista y habitual y su fórmula (0+4h+p)/6. Use un checklist y un criteri definid para asegurar cbertura. JUICIO EXPERTO WIDEBAND DELPHI Un grup de persnas sn infrmadas y tratan de adivinar l que cstará el desarrll tant en esfuerz cm en duración. Las estimacines en grup suelen ser mejres que las individuales. La reunión se prepara 24hs antes, se junta un grup de experts para enfrentar pinines y estimar. Cada un de ls experts envía su estimación al crdinadr. Lueg se tabulan las estimacines (sn anónimas). Se dan especificacines a un grup de experts. Se les reúne para que discutan tant el prduct cm la estimación. Remiten sus estimacines individuales al crdinadr. Cada estimadr recibe infrmación sbre su estimación, y las ajenas per de frma anónima. Se reúnen de nuev para discutir las estimacines. Cada un revisa su prpia estimación y se la envía al crdinadr. Se repite el prces hasta que la estimación cnverge de frma raznable. Cuántas rndas sn aceptables? Generalmente 3 reunines sn aceptables. Analgía Cnsiste en cmparar las especificacines de un pryect cn las de trs pryects. Cmparar cmpnentes similares Cuand se cmpara pr analgía hay much errr, n sn fiables. Analgía-Factres Tamañ: Mayr menr? Cmplejidad: Más cmplej de l usual? Usuaris: Si hay más usuaris habrán más cmplicacines Otrs factres: Sistema perativ, entrns (la primera vez más). Hardware, Es la primera vez que se va a utilizar? Persnal del pryect, nuevs en la rganización? Generalmente l que más afecta es la cmplejidad y `para quién se estima. Estrategia de estimación Cuente primer Use un métd para cnvertir las cuentas en estimacines Use el juici de expert cm últim resrte. Primer se debe cntar y fijar la medida.
Segund se debe transfrmar la cuenta en estimación. NO USAR UN SOLO MÉTODO SE RECOMIENDA USAR POR LO MENOS 2, Y SE SUELEN USAR DE A PARES. Generalmente se usa el juici expert y un algrítmic. Calibracines y Histrical Data Las calibracines sn slamente usadas para cnvertir las cuentas a estimads (líneas de códig a esfuerz, use cases a calendaris, requerimients a númers de test cases, etc.). Estimar, siempre invlucra algún tip de calibración sea directa implícita. Las estimacines pueden ser calibración usand cualquiera de ests tres tips de dats: 1. Industry Data: dats de tras rganizacines que aprtan al mercad y desarrllan prducts cn algún grad de semejanza y que permite una cmparación básica. (En general están es estándares) 2. Histrical Data: dats de la rganización de pryects que se desarrllarn y ya se cerrarn.(se guardarn dats-estimacines) 3. Prject Data: dats del pryect per de etapas anterires a la que se está estimand.(cada vez que se abre una fase estimarla) Actividades Omitidas Una de las fuentes de errr más cmún en las estimacines es mitir actividades necesarias para la estimación del pryect: Requerimients faltantes Actividades de desarrll faltantes (dcumentación técnica, participación en revisines, creación de dats para el testing, mantenimient de prduct en previas versines). Actividades generales (días pr enfermedad, licencia, curss, reunines de la cmpañía) Us de buffers clchón. Nunca tenga temr de que las estimacines creadas pr desarrlladres sean demasiad pesimistas, dad que ls desarrlladres siempre generan schedules demasiad ptimistas. L que más afecta a la estimación es: 1. Requerimients n relevantes 2. Requerimients mal relevads Siempre guardar una cantidad de días extra pr alg que salga mal falte: buffer clchón. Factres que afectan a la estimación: Ns lvidams de ls requerimients NO FUNCIONALES, sól tenems en cuenta ls funcinales. Estimación de tamañ El númer que más se busca en las estimacines de sftware es el tamañ del sftware a ser cnstruid. El tamañ puede ser expresad en LDC (líneas de códig), punts de función, númer de requerimients, númer de web pages u tra medida. Pcker Estimatin
Ppular entre ls ágiles practitines, publicad pr Mike Chn. Cmbina pinión de expert, analgía y desegregación. Participantes en planning pcker sn desarrlladres Las persnas más cmpetentes en reslver una tarea deben ser quienes la estiman. El misteri de Fibnacci. Pcker Planning Defina la lista de actividades, móduls, use cases, etc. Acuerde y cnsensue en la más simple, ejempl tarea z. Asigne tamañ/cmplejidad 1 a la tarea z Ejecute un wide Band delphi para estimar cmplejidad/tamañ del rest de la lista, cmparad cn la más simple y sl asignand valres de COMPLEJIDAD de la serie de Fibnacci. Se puede hacer cm una rnda de cartas. Estime el esfuerz requerid para llevar a cab la tarea z y aplique el multiplicadr a tdas las actividades. Estimación basada en cass de us Basada en un cnjunt de cass de us y su cmplejidad asciada. Se agregan valres que mdifican el tamañ. Se agregan valres que mdifican el esfuerz. Estimación de tamañ: Cmplejidad. Actres. Optimización. Reusabilidad. Tecnlgía. Salidas. Dmini. Criteris: Generales. Particulares. Estimación de esfuerz: Madurez de la rganización. Experiencia en la tecnlgía. Cncimient en el prces. Esfuerz distribuid en el cicl de vida: Ajuste pr slapamient. Criteris Generales. Particulares. Prblemas en las estimacines La estimación de tamañ es el pas intelectual más difícil (per n impsible), y muchas veces se saltea y se trabaja directamente en la estimación del crngrama (tiemp).
Ls clientes y desarrlladres a menud n recncen que el desarrll de sftware es un prces gradual, que requiere el refinamient de las estimacines tempranas. Las rganizacines a menud n registran, guardan y analizan sus dats histórics de perfrmance de desarrll de pryect. A menud es difícil generar crngramas realistas aceptads pr clientes y gerentes. Pryects de mantenimient Cuand se está estimand el tamañ para un pryect de mantenimient se debe tener en cuenta que insertar una nueva funcinalidad será factible si la arquitectura existente del prduct puede acmdarse a dicha función. Cas cntrari, el esfuerz de mantenimient incrementará el retrabaj de la arquitectura. Puede existir una sbre estimación si se utilizan mdels de estimación calibrads para nuevs pryects. A menud ls pryects de mantenimient tienen fecha de entrega fija así cm un númer de persnal asignad. Es tr element cn el que hay que lidiar en el mment de hacer la estimación. N aplican ls métds de estimación para pryects nuevs en pryects de mantenimient. Estimacines en Pryects pequeñs Prces pequeñ: trabajan una ds persnas en un tiemp menr a 6 meses. Ls dats industriales de mdels de estimación que existen n están calibrads para este tip de pryect, de md que sn inadecuads y l mejr es utilizar ls dats histórics de la rganización. Las estimacines de ls pryects pequeñs dependen en gran medida de las capacidades de ls individus que hacen el trabaj. El Persnal Sftware Prcess es de gran ayuda para ests pryects.