Scribd Logo
Cargar

¡Te damos la bienvenida a Scribd!

  • Unidad 15

    Cargado por

    martha
    7 vistas16 páginas
    q

    Título original

    UNIDAD-15

    Derechos de autor

    © © All Rights Reserved

    Formatos disponibles

    PDF o lea en línea desde Scribd

    ¿Le pareció útil este documento?

    ¿Este contenido es inapropiado?

    Denunciar este documento
    q

    Copyright:

    © All Rights Reserved
    Descargue como PDF o lea en línea desde Scribd
    Marcar por contenido inapropiado
    7 vistas16 páginas

    Unidad 15

    Cargado por

    martha
    q

    Copyright:

    © All Rights Reserved
    Descargue como PDF o lea en línea desde Scribd
    Marcar por contenido inapropiado
    de 16
    422 Introducci6n a los métodos recomendables Esta parte del libro contiene 27 «métodos recomendables»: Capitulo 17 Grupo de control de cambios Capito 18 ConsirucciGn y prueba diarias Capitulo 19 Diseho para el cambio Capitulo 20 Ratrega evotutiva Capitulo 21 Prototipado evolutivo Capitulo 22 Definicién de objetivos Capitulo 23 Inspecciones Capitulo 24 Desarrollo conjunto de aplicaciones (IAD) Capitulo 25 eleccién del modelo de ciclo de vida Capitulo 26 Medidas Capitulo 27 Hitos miniatura Capitulo 28 Desarrollo externo (Outsourcing) Capitulo 29 Negociacién conveniente Capitulo 30 Entornos productives Capitulo 31 Lenguajes para et desarrollo rapido (LDR) Capitulo 32 Filtrado de requerimientos Capitulo 33 Reutilizacién Capitulo 34 Compromiso (Signing up) Capitulo 35 Modelo de ciclo de vida en espiral Capituio 36 Entrega por eapas Capitulo 37 Gestion Theory W Capitulo 38 Prototipos desechables Capitulo 39 Desarrollo en ventanas temporales Capitulo 40. Grupo de herramientas Capitulo 41 Lista de los 10 riesgos principales Capitulo 42 Provtipado de la intertaz de usuario Capitulo 43 Horas extras voluntarias La tabla resumen de ejemplo de método recomendable mostrada en la Figura II1.1 es un ejemplo de las tablas resumen que describen las carac- teristicas que detinen cada método. Leyendo cada uno de los resiimenes de los capitulos del 17 al 43, debe poder determinar cudles son los méto- dos apropiados para su proyecto u organizacién. 100 Ejemplo de tabla resumen de método recomendable Cada método recomendable tene una tabla resumen que describe as caracteristicas que derinen dicho metodo. LLayando los resiimenes de los capitulos del 17 al 43. debe poder determinar cudles son los métados apropiados para SU proyecto u organizacion, Eficacia Reduccion potencial _Ninguna (=0%4), Media (0-10%, dela planificacién —_Duene (10-20%), Muy buena nominal (20-30%), Excelente (30%+) Majora en ta visibiidad Ninguna (=0%), Media (0-25%), del progreso Buena (25-80%), Muy buena (60-755), Exeelante (75842) Efecto sobre al riesgo Dieminuya al daggo, Sin alacta, dela planifieacién Aumenta al riesgo, Posibilidad de éxito Baja (=0-20%), Media (20-40%), inital Buena (40-60%), Muy buena (60-80%). Excelente (80-100%) Posibilidad de éxito Bala (~0-20%), Media (20-40%), alargo piazo Buena (40-60%), Muy buena (60-00%), Excelente (00-1007) iesgos principales + Esta seccién resume los riesgos principales aftadidos or este método en el resto del proyecto. No incluye los Figegoe para toner éxito con ol propio métado, Interacciones y equilibrios principales ‘+ Esta seccion resume las principales interacciones aot métalo ean teas métaclos, y al aquilbrio de factores implicados en el uso del método. Figura Ill1. Ejemplo de tabla resumen de método recomendable, con explicacién de sus caracteristicas. 423, 424 Desarrollo y gestién de proyectos informaticos Los capitulos de esta parte del libro describen los métodos recomen- dables para desarrollo rapido. Estos métodos representan el estado del arte actual en Ia velocidad de desarrollo. Algunos de ellos son nuevos. Otros han sido utilizadas dneante 20 afiox o mis. Algunos de ellos pare- cen cuestiones de sentido comin (jojald se utilizara en general el sentido comiin!). Otros puede que no patezcan métodos recomendables hasta que Tea el capitulo correspondiente. Estos métodos no estén pensados para ser usados todos simulednea- mente, Algunos de ellos son mutuamente excluyentes. Pero probablemente cencantrara algnnas que pede usar en sn proyectos en curse sin madifie car radicalmente su enfoque para el desarrotlo de software. Otros méto- dos pueden parecer tan atractivos que desearé modificar radicalmente su. enfoque de desarrollo para poder utilizarlos. Organizacién de los capitulos de métodos tecomendables _ Todos los capitulos de métodos recomendables estin organizados de for- tma similar. Cada uno comienza con una tabla como la del ejemplo mos- trado al inicto de este capftulo. La tabla presenta un resumen de ta efica- cia, riesgos, interacciones y equilibrios de cada método. Cada comentario del resnmen es explicado con mas detalle en el cuerpo del capitulo. Las primeras tres entradas del apartado «Eficacia» de ta Figura IIL.1 describen los tres tipos de mejoras en la planificacién descritos en la Sec- cién 1.2, «Como lograr el desarrollo ripido»: ‘+ Reduecién potencial de la planificacién nominal. ‘© Mejora en la visihilidad del progreso, # Efecto sobre el riesgo de la planificacién, Los siguientes parrafos explican estas tres entradas y el resto de la informacién de la seccién de resumen de métodos recomendables. «Reduceién potencial de la planificacién nominal». Esta entrada contiene una estimacién del efecto del uso del método sobre la planifica- cién del proyecto. Todas las posibles redueciones suponen que el método se ejecuta de forma experta. Generalmente, en los proyectos en que se use tun método por primera vez, se cometerin errores qué reducirn la efica- cia det método. esta clasificacién se realiza de forma verhal (Ninguna, Media, Buena, Muy buena y Excelente) en lugar de una escala numérica. La tabla de ejemplo de método recomendable de la Figura II1.1 muestra la correspon- dencia aproximada entre esta escala verbal y las reducciones en porcenta- je. En algunos casos, la base de fa reduccidn en porcentaje i sido estima- ‘CRUZADA ‘sobre ol modelo do ‘ico devia en cascada, const a ‘section 71, »Caseada Introduecién a ns métadas ranamandables 425 da por otros. y se describe en la seccién «Puntos cruciales» incluida en el capitulo; en otros casos es mi mejor estimacién de la eficacia del método. Puede trasladar la escala verbal a rangos de porcentajes, pero la escala verbal es la mejor descripcién de la posible reduccién. Generalmente, el estado del desarrollo de software no permite que alguien utiliee expresiones precisas como wel prototipado reduce la planificacién en un 34,27 por 100 Un estudio puede encontrar que el prototipado reduce el tiempo de desa~ rrollo en un 25 por 100; otro podria detectar que lo ha reducido en un 45 por 100, Un tercero podria no encontrar ningiin ahorro, La escala verbal tefleja la imprecisién de los datos subyacentes. atlejora en la visibilidad del progreson. Esta clasificacidn también std dada en una escala verbal en lugar de una numérica. Es dificil concretar aigo tan amorfo como «Mejora en la visibilidad del progreso», y he crea- do la mejor aproximacién posible definiendo la mejora como el porcentaje del proyecto que un método hace visible respecto @ un modelo de ciclo de vida tradicional en cascada. Las clasificaciones de esta categoria surgen de mis propias estimaciones, De nuevo, hay una correspondencia aproxi- mada entre la clasificacién verbal y la cuantificacién subyacente, pero la clasificacién verbal expresa mejor la inexactitud de los datos. «Efecto sobre el riesgo de la planiticacién». Algunos métodos, como cl prototipado evolutivo, dismiauyen generalmente el ticmpo de desarro- Ilo en camparacién con las métados tradicianales, pera hacen mAs dificil predecir especificamente cuando va a terminar el proyecto. Un esfuerzo de desarrollo tradicional puede requerir un promedio de tres meses, con una variacién de mas/menos dos semanas. Un enfoque con prototipado evolutivo del mismo proyecto podria requerit un promedio de dos meses, y variar en !6 semanas/-2 semanas. Se considera que estos métodos in- crementan el riesga de la planifieacién. Esta clasificacién (Disminuye el riesgo. Sin efecto, Aumenta el riesgo) indica si un método mejora la posi- bilidad de cumplir un plazo especifico, no le afecta, o la empeora. He incluido algunos métodos como métodos recomendables especifica- ‘mente porque tienen un fuerte efecto positivo sobre el riesgo de la plant- ficacién, Puedlen tener o no una ligera influencia sobre la duracién media de Ia planificacién, pero ayudarin a controlar fluctuacianes salvajes de Ia planificacién, y ayudarén a poder volver a controlar planificaciones in- controladas. «Posibilidad de éxito Inlclal». Alguios de los mérodos son mas difi- ciles de aprender a usar que otros. Con algunos métodos, puede esperar tener éxito inmedintamente; en atros, es pasihle que tenga que esperar a obtener Ia recompensa posteriormente. Algunos métodos (como la reuti- lizacién) requieren un gran esfuerzo en infraestructura antes de empezar 426 Desarrollo y gestién de proyectos informaticos REFERENCIA Pramas ntormacion ‘sobeehevamlentas Horramiantas CAS on ln Seecin 13.5 a obtener rendimiento, Estos no tienen practicamente ninguna posibilidad de éxito «inicial», y estén clasificados como «Dajan en esta categoria, aunque tengan un enorme potencial a largo plazo. «Posibilidad de éxito a largo plazo». Cuando apartamos el efecto de la curva de aprendizaje, algunos métodos simplemente tienen éxito con mas frecuencia que otros. Esta clasificacion describe las posibilidades de que tn método tenga éxito si sigue fiel al mismo el tiempo suficiente para tener experiencia en su uso, En teoria, Ia clasifieacién de esta categoria va desde Baja a Excelente, pero como estos capitulos describen métodos recomendables, actualmente no hay ningin métado con una clasificacién por debajo de Buena. Algunos métodos, como las herramientas CASE, no se han incluido especificamente en este libro como métodos recomenda- bles, porque la posibilidad de éxito a largo plazo sélo ha sido Media 0 Baja. Comparando la clasificacién de esta categoria con la categoria «Posi- bilidad de éxito inicial» le dara una indicacién de la progresividad de la curva de aprendizaje asociada con el método. Algunos métodos, como la lista de Jos 10 niesgos principales, tienen la misma clasficacion para el éxito inivial y a laigo plazo. Estos métodos son excepeionalmente féciles de aprender a usar. Otros, como el disefo para el cambio, tienen una dife- rencia de mas de un nivel de clasificacién; esos métodos son relativamen- te dificiles de aprender a usar. «Rilesgos principales». La palabra «riesgo» puede ser usada en va- rios sentidos, incluyende el riesgo celative al uso con éxito del propio método. Estos riesgos estin deseritos en el cuerpo del capitulo (en la sex cién «Uso de método recomendablen), pero no estén descritos en esta tabla, Esta entrada resume los riesgos principales que supone el uso de esta practica sobre el resto del proyecto. winteracciones y equilibrios principales». sta entrada describe la interaccién del método con otros métodos de desarrollo rapido y desarrollo eficiente, y los equilibrios de factores involucrados en el método, Aleu- ‘nos métodos orientados a la velocidad no implican practicamente ningiin equilibrio de factores, pero otros requieren que se gaste mas dinero, se sacritique la tlexibilidad o se acepten mas riesgos para disminuit la plani- ficaciGu. Otras secciones Ademas de la tabla resumen, los capitulos de métodos recomendables ti nen practicamente la misma organizacién, incluyendo las siguientes sec- Introduncién a Ins métodes recamandables 427 Uso del método recomendable. Gestién de los riesgos del método recomendable. Efectos secundarios del método recomendable. Interaceiones del método recomendable con otros métodos. Puntos cruciales del método recomendable. Claves para el éxito en el usa del mérada recomendable, Bibliografia adicional Resumen de los candidatos a métodos recomendables ‘CRUZADA Pave mde itormacion sobre os res tpos de mmelodosrelaconades ‘on la paniieacén ‘consuls le Seccidn 12, -C8me Tograr el desaralo vapl: Cada método descrito en un capitula de métodos recomendahles ha sido seleccionado por una de las siguientes razones: * Reduccién de las planificaciones de desarrollo, © Reduccion de las planificaciones de desarrollo percibidas, hacien- do mas visible el progreso. #- Reduccién de la volatilidad de la planificacién, reduciendo Ia opor- tunidad de que el proyecto se descontrole. Algunos de los métodos recomendables estin descritos en la Parte 1 de este libro, y estos métodos recomendables simplemente estin resumidos ca cata parte del libro. Podrin preguntarse: «Por qué ignara los grificas de estructuras de abje- tos FooBar, que son mi método favorito?» Esta es una cuestion que me he planteado mucho a lo largo de la creacién de este libro. Una técnica candi- data a método recomendable puede ser excluida por una de varias razones. Métodos pertenecientes a las bases del desarrollo, Muchos candi- datos a métodos recamendables entran dentra de la categoria de los métodos fundamentales del desarrollo. Uno de los desafios a superar al escribir este libro ha sido evitar que se convierta en un manual general de ingenieria del software, De cara a mantener el libro dentro de un tamafo razonable, he introducido estas tecnicas en el Capitulo 4, «Bases del desarrollo de softwaren, y he ofrecide referencias a otras fuentes de informacién. Tlay mucha informacién disponible en otras fuentes sobre métodas fundamen tales. En algunos pocos casos, podria considerar correctamente que un mé- todo es fundamental, pero si tiene un profundo impacto en la velocidad de ‘desarrollo, 1o he inciuido de todos modos como metodo recomendable en estos capitulos, Filosofia recomendable, pero no método recomendable. Alcunos candidatos a métodos recomendables parecen ser més bien tearias o filo- 428 Desarrollo y gestion de proyectos intormaticos soflas que (ecuicas. Le distineion enlie teoris, prévtiva y filusofia nv esta clara en el desarrollo de software, y por ello, un método al que yo llamo una filosofian podria ser visto por otros como una «técnica», y vicever- sa. Independientemente de como se lame, si consideto que es «recomenda- ble», Jo trataré en algin punto del libro, Pero si considera que es una filoso- fia estara en la primera 0 segunda partes del hibro (vease la Tabla IIL.1 para ver una lista de dude se Uta cada Filosofia vecomendable. Puede ser un método recomendable, pero no para la velocidad de desarrollo. Algunos candidatos a métodos recomendables pueden ser perfectamente métodos recomendables por su efecto sobre la calidad o la facilidad de uso, pero es posible que no pasen las pruebas de mejora de las pluificaciones actuales, las planificacioues percibidas o la volatilidad de la planificacién. Estos métodos no han sido incluidos en este libro. Evidencia insuficiente de la eficacia de un método. Algunos mé- todos prometedores ain no han aportado la evidencia suficiente para ser clevados a la categoria de métodos recomendables. Si la comunidad de desarrollo todavia no tiene suliciente experiencia sobre un método para publicar informes sobre su experiencia con él, no lo he inctuido. Sin duda, algunos de los métodas que entran en esta categoria probarin algin dia que producen grandes beneficios en la velocidad, y los incluiré en una edicién futura de este libro. En algunos casos en los que las publicaciones en si no eran suticien- les para justificar tratar un mnétodo como métody reconensdable, lie teatidy ‘experiencias personales con ese método que me han convencido de que era un método recomendable. Los he ineluido a pesar de la falta de publi- caciones que los apoyen desde otras fuentes. Evidencia cuestionable de la eticacia de un metodo. Algunos can- didatos # méodos recomnendubles pareven prometedores, pero Ta daica informacién publicada que he podido encontrar era de eus vendedores de otras fuentes que tienen intereses en la promocién de los métodos, por lo que los he excluido. No ser un metodo recomendable. Algunos candidatos a métodos re- vouicndables son muy bicn visies (iucluso celusamente guardados) en al- gunos lugares, pero esto no los convierte en métodos recomendables. En algunos casos, los informes sobre experiencias reales indican que un mé- todo bien visto falla generalmente a la hora de cubrir las expectativas. En. conclusién, un método puede ser un buen método, pero no un método Tecomendable. kn otros casos, e1 método funciona maravillosamente cuan- do funciona, pero falla demesiado a menudo pata ser considerado un mé~ todo recomendable. Introduccién a los métodos recomendables 429 En un caso (RAD), el método candidato consiste en una combinacién de muchos de los restantes métodos descritos en este libro. Podria ser perfectamente una combinacién eficaz en algunas circunstancias. Pero como este libro defiende la seleccién de métodos de desarrollo répido que cumplan las necesidades de su proyecto en particular, esta combinacion espevifica predcterminada de métodes no ha sido considerada en si como un método recomendable ‘$8 que muchos lectores seguirin pregunténdose cémo he clasificado los métodos especificos, como los grificos estructurados de objetos FooBar ‘o cualquier otro (lo he hecho). Para satisfacer esta curiosidad, la Tabla II.1 resume los candidatos a métodos recomendables € indica dénde se descri- ‘bent en este libro © por qué se han dejado fuera, Esta tabla también puede servir como una referencia exhaustiva de ‘métodos orientados a la velocidad para alguien que esté planificando un proyecto de desarrollo rapido. Tabla It. Resunnen de los vandidatos a métodos recomendables Candidato a método Dénde se hace referencia 0 raz6n recomendable por Ia que no se incluye 4GL Método recomendable. Véase Lenguaies para desarrollo répido (LDR). Analisis de requerimientos Fundamento. Arquitectura Fundamento. Adquisicién frente a Fundamento, planificacién y construccién Herramientas CASE Evidencia insuficiente de la eficacia del método, Vease «Herramientas CASE», en la Seccién 15.5, Grupo de control de cambios Método recommendable deserivo en ouy capitulo. Véase «Grupo de control de cambios», en Ia Seceién 14.2, y el resumen del Capitulo 17. Desarrollo aislado Puede ser un método recomendable, pero no para el desarrollo rapido. Codigo legible, de alta calidad — Fundamento, Métodos eficaces de construccién Fundamento Orientacién al cliente Filosofia recomendable. Véase el Capitulo 10, Desarrollo orientado al cliente. (continia) 430 Desarrollo y gestin de proyectos informaticos Tabla i.1. (Continuacion) Candidato a método recomendable Construcelon y prueba dlarias ‘Cuadernos de disevio Diseo estructurado, orientado a objetos, etc Modelo de ciclo de vida de disefio por planificacion Modelo de ciclo de vida de diseiio por herramientas Disefio para el cambio Educacién de la directiva Educacién del equipo técnico Midulos propensos a errores Herramientas autométicas 4e estimacion Estimacién y planificacién pievisas Modelo de cielo de vida de entrega evolutiva Modelo de cielo de vida de prototipado evolutivo Control del conjunto de prestaciones Definivién de objetivos Contatucidn de persons brillantes Dénde se hace referencia o razén por la que no se ineluye Método recomendable, Véase el Capitulo 18, ‘uConstruccién y prueba diarias. No 20 digpone de informacién cuficionte para considerarlo un método recomendable. Fundamento. No es un método recomendable, Véase la Seccién 7.7, «Diseiio por planificacién». No es un método recomendable, Véase la Seccién 7.9, «Disefio por herramientas», Método recomendable. Véase el Capitulo 19, «Diseiio para el cambio». Puede ser un método recomendable, pero no para la velocidad de desarrollo. Puede ser un método recomendable, pero no para la velocidad de desarrollo. Fundament, Fundamento. Filosofia recomendable. Véanse el Capitulo 8, ‘Estimacié», y el Capitulo 9, «Planificaciénn Método recomendable. «Entrega evolutivay, 20 ol Capitulo 20, Métoda recomendahle Véase el Capitila 21 «Prototipade evolutivoy. Filosofia recomendable. Véase el Capitulo 14, «Control del conjunto de prestacioneso, Método recomendable descrito en otro capitulo. Véase «Definicién de objetivos», en la Seccidn 11.2, y el resumen del Capitulo 22. Fuundamento. Véase «Persouasy, on la Seevidn 2.2 {contimia) Infroducci6n a fos ridiodos revuuientdables 481 Tabla MLA. (Contimuacién) Candidato a método Dénde se hace referencia o razin Fecomendable por Ia que no se incluye Ingenietia de la informacién No hay suficientes evidencias de la eficacia del método. Inspecciones Fundamento. Método recomendable descrito dentro de otro capitulo, Véase cdnspecciones», en la Sevci6n 4.3, y el resumen del Capitulo 23 Bstrategias de integracién Fundamento. Desarrollo conjunto Método recomendable. Véase el Capitulo 24, de aplicaciones (Joint «Desarrollo conjunto de aplicaciones (JAD)». Application Development, JAD) Planificacién conjunta ‘No es un método recomendable. Véase de requerimientos (JKP) Planificacion JAD», en la Seccion 24.1 Liderazgo Fundamento. Seleccion de! modelo de ciclo Método recomendable deserito en de vido otro capitulo. Véase el Capitulo 7, «Planificacién del ciclo de vida. y el resumen del Capitulo 25. Medidas Método recomendable. Véase el Capitulo 26, «Medidasy, Reuniones eficientes Fundamento. Hitos principales No es un método recomendable. Véase

    También podría gustarte