1

Bienvenido al desarrollo rpido

Contenido 1.1. Qu es el desarrollo rpido'/ 1.2. Cmo lograr el desarrollo rpido
Temas relacionados
Quin debe leer este libro: Prlogo Beneficios fundamentales del libro: Priogo
,Por qu se ha escrito este libro'l: Prlogo Estrategia para el desarrollo rpido: Captulo 2 Cuestiones fundamentales para el desarrollo rpido: Captulo 6

EL RESPONSABLE DE PRODUCTOS ME DIJO que quera desarrollar un producto preparado para un cambio. Deseaba tener en cuenta la calidad, evitar el crecimiento de prestaciones, controlar la planificacin y tener una fecha de entrega predecible. Cuando lleg la hora de realizar el proyecto, qued claro que la nica prioridad real era poner el producto a la venta 1o antes posible. ,Usabilidad? 1/o tenemos tiempo. Rendirniento? Puede esperar. ,Facilidad de mantenimienf"o? Para el prrimo proveclo. Verificacin7 Nuestros usuurios qttieren el produco ahora. Hav que terminar conto sea. Este responsable de productos en particular no eta el responsable de un solo producto. Podra haber sido prcticamente cualquiera de los responsables de productos para los que he trabajado. Este comportalniento se repite todos los das, en todos los estados y en todos ios pases. El tiempo de desarrollo se ha convertido en una prioridad tan irnportante que ha cegado a las personas sin dejarles ver otras consideraciones importantes, incluso algunas que afectan al final al tiempo de desarrollo.

Desarrollo y gestn de proyectos informticos

1.1

Qu es el desarrollo rpido?
Para algunas personas. el desarrollo rpido consiste en aplicar una nica herramienta o mtodo. Para el hacker, el desarrollo rpido consiste en codificar 36 horas de un tirn. Para el ingeniero de sistemas de informacin" es RAD (Lrna cornbinacin de herramientas CASE,, la participacin intensiva del usuario y \entanas temporales estrictas). Para el programador de mercado, consiste en usar prototipado rpido con la ltima versin de Microsoft Visual Basic o Delphi. Para el clirectivo desesperado por acortar una planificacin. es cualquier mtodo recomendado en el ltimo nmero de Business trfeek. Cada uno de estos mtodos y herramientas va bien hasta un clerto lmite, y cada uno puede contribuir a incrementar la velocidad de desarrollo. Pero para obtener todo el beneficio posible, cada uno tiene que estar coordinado dentro de una estrategia global. Ninguno de ellos es aplicable a todos los casos. y ninguno puede compararse frente a otras tcnicas que generaimente no son consideradas como tcnicas de desarrollo rpido. pero que sin embargo tienen profundas implicaciones en la velocidad de desarrollo. En lugar de identificar una herramienta o mtodo especficos, en lo que respecta a este libro ei <desarrollo rpido> es simplemente una frase descriptiva opuesta a,,desarrollo lento y tpico>. No es Desarrollo Rpiclor\, una frase o palabra mgicas. No es una fulgurante metodologa de desarrollo rpido Blaze-O-Matic o Gung-HO-OO. E,l desarrollo rpido es un trmino genrico que significa lo nismo que <desarrollo veloz> o <planificaciones ms cortas)). Significa desarrollar software a una velocidad superior a Ia alcanzada en este momento. E,nionces, un <proyecto de desarrollo rpido> es cualquier proyecto que necesite hacer nfasis en 1a velocidad de desarrollo. En las circunstancias actuales, esta descripcin se adapta a gran cantidad de proyectos.

1.2. Gmo lograr el desarrollo rpido

libro es claramente la ruta menos transitada en la industria actual. Pasar por 1a ruta menos transitada puede parecer arriesgado. Pero la ruta ms concurrida esla que actualmente est redundando en costes maslvos y retrasos en la planificacin, baja calidad, proyectos cancelados, muchos cambios de personal, fricciones entre directivos, desarrolladores y clientes, y todo el resto de problemas que estamos tratando de evitar. Si trabaja en una organizacin normal y sigue los mtodos descritos
E,l camino marcado en este

Captulo 1: Bienvenido al desarrollo rpido

en este libro, podr reducir significativamente su tiempo de desarrollo,

puede que hasta la mitad, e incrementar tambin su productividad. Adems, podr hacerlo sin alterar la calidad, el coste. el rendimiento o la facilidad de manteniriento. Sin embargo, la mejora no ser instantnea, no la obtendr a partir de una nica y nueva herramienta o mtodo, y no \a alcanzar cogiendo simplemente el paquete de la estantera. Requerir tiempo y esfuerzo. Hubiera deseado tener una solucin sencilla para el problema de la

,,lo prctblema

:'t(10 ha.l un

' { \' errnel.

L. \lenckcn

a:t('.\d corta.

velocidad de desarrollo. Tambin me gustara tener cinco millones de dlares. Pero las soluciones simples tienden a funcionar slo con problemas sencillos, y cl desarrollo de software no 1o es. El desarrollo rpido de
software es an menos simple. Como sugiere la Figura 1.1, el conjunto de todos los mtodos disponibles para desarrollo de software es inmenso. Dentro de esre conjunto, el subconjunto de mtodos tambin es grande. E,n un proyecto en particular, slo se utiliza un pequeo subconjunto de estos mtodos. Visto por encima, para tener xito en el desarrollo rpido se requieren dos cosas:

o .

Seleccionar mtodos eflcaces en lugar de mtodos ineflcaces.

Seleccionar mtodos orientados especficamente a alcanzar sus obje-

tivos de planificacin.

Mlodos ineficaces

Conjunto

de mtodos
usados en

un proyecto
determinado

1.1. Conjunto de todos los mtodos para desarrollo de software La velocidad de desarrollo depende de la seteccin de los mtodos de desarrollo. La velocidad con que desarrollemos cualquier programa concreto depender de Ia proporcin de mtodos eficaces y de mtodos orientados a la planificacin que seleccionemos.
Figura

Desarrollo y gestin de proyectos informticos

Podramos pensar que esto es obvio. pero como se explica en el Captulo 3, las organizaciones seleccionan habitualmente mtodos ineficaces. Eligen mtodos cuya ineficacia est probada, o que fallan ms de la cuenta. Cuando necesitan la mxima certeza en los plazos. seleccionan prcticas de alto riesgo, que reducen la posibilidad de alcanzar las fechas lmite fijadas. Cuando necesitan reducir costes, seleccionan mtodos orientados a la velocidad, que incrementan los costes. En estas empresas, el primer paso hacia la me.jora de la velocidad de desarrollo consiste en admitir que estn seleccionando rntodos ineficaces, y a partir de ah comenzar a elegir mtodos eficaces. En la Figura L l. todos los mtodos efectivos orientados a la planificacin estn agrupados en una categora, pero como sugiere la Figura 1.2, actualmente se puede elegir entre tres tipos de mtodos orientados a la planificacin:

. .

Mtodos que mejoran la velocidad de desarrollo, permitiendo entregar antes el software. Mtodos que reducen el riesgo en la planificacin, permitiendo evitar
grandes retrasos de planificacin. Mtodos que hacen visible el progreso, perrnitiendo disipar la irnpresin de tener un desarrollo lento.

Los tipos especficos quc seleccione de mtodos orientados a planificacin estarn determinados por sus problemas con la velocidad de desarrollo. Si piensa que simplemente necesita desarrollar ms rpido, debe

Mtodos onentados a la planificacin

Mt0dos orientados a la velocidad

1.2. Hay tres tipos de mtodos orientados a la planificacin: mtodos que permiten desarrollar ms rpido, que reducen el riesgo en la planificacin y que hacen visible el progreso.
Figura

Captulo 1: Bienvenido al desarrollo rpido centrarse en n-rtodos orientados a la velocidad de desarrollo. Si piensa que su velocidad de desarrollo es correcta, y que el problema radica en la percepcin de la velocidad cle desarrollo por parte del cliente, debera centrarse en los mtodos orientados a la visibilidad. Al unir mtodos ef-ectivos orientados a planificacin junto con un plan para usarlos, ver que el conjunto ofrece mejoras drsticas y reales en ia velocidad de desarrollo. Esto es mejor que usar un software <elixir> Habichuelas-Mgicas,que realmente no funciona. Por supuesto, seleccionar mtodos eficaces y evitar los ineficaces es fcil de decir, pero difcil de hacer, y ste es el tema del resto del libro.

Estrategia para ef desarrollo rpido

Contenido
2.1

E,stratcgia general para e1 desarrollo rpido

2.2. Cuatro c'limensiones cle la vclocidad de desarrollo 2.3. Tipos generales de desarrollo rpido
2.'1. ,Cul cs la dimensin ms importante? 2.5. Una estratcgia alternativa para el dcsarrollo rpido Temas relacionados
E,rrores clsicos: Captulo 3 Bases dcl desarrollo de software: Captulo 4

Gestrn dc riesgos: Captulo 5 Cuestiones fundamentales Dara el dcsarrollo rpido: Capitulo 6

SI COGIESEN4OS lOO MUSICOS DE PRESTIGIO A NIVEL MUNDIAL y los pusisemos en una orquesta sin director, no sonaran como una orquesta de calidad. E1 tempo de 1a seccin de cuerda no coincidira con el de la seccin dc madera y viento o con 1a seccin de metal. Indicar a los r.nsicos quc lo hagan <1o mejor que puedan> no les ayuda a saber si debcn ir ms rpido o ms lento. Scmejante evento musical sera un desperdicio de taleuto. E.n el desarrollo de softr.varc sc produce un desperdicio similar de talento. Equipos de clesarrolladores intcligentes y dedicados utilizan 1as tcnicas rnejorcs I nrs recientes. y siguen sirt podcr alcanzar sus objetivos

de planificacin. Una de las trantpas rns tentacloras en las que cae la gente que qulere desarrollar ms rpido consiste cn centralse slo en mtodos de desarrollo orientados a planificacin. Podramos ejecutar cl prototipado rpido

10

Desarrollo y gestin de proyectos informticos perf'ectamente, pcro si corletemos un error no obtclrdrerlos un desarr.

rpido (<Vaya!, en la planificacin hemos olr.idado inclLrir tierrpo p.,: hacer el subsistema de in-rpresin>). Las tcnicas concrstas orientac'la. planificacin son slo parte de lo que necesitarnos para obtener el pr., ms corto posible. Tambin se necesita Lln cntorno global que pernt.. utilizar estas tcnicas con el mximo beneflcio. De aqu cn adclanlc cste capitulo proponc una cstratcgia orqrre.r.re para conseguir un desarrollo rpido.
Ejemplo

2.1.

Desarrollo rpido sin una estrategia clara

Mickey estaba preparado para dirigir su segundo proyeclo en Square-Tech. un gigante en el mundo de las hojas de clculo sobre pC. Su primer proyecto fue mal. El plan original prevea que su equipo entregase Square-Calc versin 2.0 en i2 meses, pero emple 18. El equipo saba desde el princip1o que la fcha era agresiva, por lo que casi durante los l8 meses completos llevaron una marcha tlepidante, trabajando l2 horas al dia 6 o 7 das a la semana. Al final, dos de los seis miembros del equipo se fueron, y Bob. el desarrollador ms importante del equipo, parti desde Seattle en su bicicleta hacia un lugar desconocido. Bob dijo que no abandonaba, y envi una postal a Mickey desde Otturnwa, en Dakota del Sur, una foto suya montando en un rodeo, pero nadie saba cundo volvera. La versin 3.0 de Square-Calc tena que entregarse l2 meses despus que la versin 2.0, as despus de dos meses del fin del poyecto, diagnsticos post-mortem y vacaciones, Mickey estaba dispuesto a intentarlo de nuevo. Tenia i0 meses para entregar la versin 3.0. Mickey se reuni con Kim, su jefa, para discutir el plan dei proyecto. A Kim se le conocia por su capacidad para aprovechar hasta el ltimo esfuerzo de los desarrolladores
a su cargo. Tambin estaban John, de documentacin de usuario, y Helen, de control de calidad.

<La versin 3.0 tiene que superar a la competencia>, dijo Kim. <Por tanto, en este proyecto tenemos que hacer un gran esfuerzo. S que tu equlpo no cree que la compaia les haya apoyado mucho anteriormente. asi que ahora la compaa est dispuesta a darles todo el apoyo que pueda. He autorizado despachos privados e individuales, computadores ms modernos y refrescos gratis durante todo el proyecto. Qu te parece?> <Me parece bieo. dijo Mickey. <Todos los desarrolladores tienen experiencia, as que principahnente quiero darles motivacin y apoyo, y entonces dejarles trabajar. No quiero controlarles estrechamente. Me gustaria que cada uno se responsabilizase de una parte del sistema. Antes tuve problemas c<n las interthces, as que quiero dedicar algn tiempo en disear las interfaces entre las partes, r despus dejarles a su aie.> <Si es un proyecto de l0 meses, en 8 meses necesito una versin con el aspecto definitivo del software para tener la documentacin de usuario lis\( ()llIlllllti
J

Captulo 2: Estrategia para el desarrollo

rpido

11

ta a tiempo>, dijo John. <La ltima vez los desarrolladores estuvieron haciendo cambios hasta el f,nal. El archivo LEAME tsna 20 pginas, y adems enrevesadas. Los manuales de usuario estn siendo destrozados en las revisiones. Siernpre que ests de acuerdo con tener lista una versin con la interfaz definitiva, el mtodo de desarollo parece correcto.)) <Necesito la versin definitiva ms o menos en la misma fecha para escribir secuencias autornticas de prueba>, aadi Helen. Mickey acept el planteamiento de la versin definitiva. Kirn aprob la estrategia global de Mickey y le dijo que le dejase organizarse. Cuando comenz el proyecto, los desarrolladoes andaban contentos con sus despachos individuales, sus nuevos ordenadores y los refrescos, asi que empezaron fuerte. No tardaron mucho en quedarse voluntariamente a lrabajar por la tarde. Los meses pasaban, y hacan progresos constantss. Pronto construyeron un prototipo, y continuaron generando cdigo. La directiva mantenia la presin, John record a Mickey varias veces su acuerdo de tener la vesin con el aspecto definitivo en 8 meses, cosa que Mickey encontr irritante, pero todo pareca progresar bien. En el cuarto res del proyecto Botr volvi de su viaje en bicicleta. fresco, e irrumpi en el proyecto con nuevas ideas que haba concebido mientras pedaleaba. Mickey estaba preocupado por si Bob podra implementar las funciones que necesitaba en el tiernpo disponibie, pero Bob estaba comprometido con sus ideas y garantizaba la entrega a tiempo sin importar lo mucho quc tuviera que trabajar. Cada miembro del equipo trabajaba individualmente en su parte, y como la entrega de la versin con la interfaz definitiva se aproximaba, corenzaron a integrar el cdigo. Comenzaron a las 2:00 de la tarde del dia anterior a la entrega de la versin definitiva y pronto descubrieron que su programa no compilaba, y menos an se ejecutaba. El cdigo combinado tena varias docenas de errores de sintaxis, y pareca que cada uno que se correga generaba otros 10. A medianoche, decidieron dejarlo por esa noche. A la maana siguiente, Kirr se reuni con el equipo. <El programa est listo para entregarlo al equipo de documentacin y prueba?> <An no>i, dijo Mickey. <<Tenemos aigunos problemas en laintegracin; podemos tenerlo listo esta tarde.> El equipo trabaj esa tarde y por la noche, pero no consiguieron corregir todos los errores que encontraron. Al final del dia admitieron que no tenan ni idea de cunto tiempo llevara la integracin. Emplearon dos semanas completas en corregir todos los errores de sintaxis y tener el sistema funcionando al completo. Cuando el equipo entreg la versin buena tras un retraso de dos semanas, los equipos de prueba y de documentacin la rechazaron inmediatamente. <Es demasiado inestable como para documentarla>, dijo John. <Se viene abajo cada pocos minutos. y hay dernasiadas opciones que no pueden plobarse.> Helen aar,li: ,,No tiene senlido escribir un informe de errores, si el sistema es tan inestable que se interrumpe casi cada vez que se hace una eleccin en el men.>
(aDnInuLt\

12

Desarrollo y gestin de proyectos informticos

Mickey estaba de acuerdo con elros, y drjo que los esfuerzos der equipo se tenan que centrar en corregir errores. Kim les record la fecha tope de 10 meses, y dijo que ese producto no poda retrasarse como el anterior.
se emple un mes en hacer que el sistema fuese lo bastante fiable como para comenzar la documentacin y la prueba. por entonces slo quedaban dos semanaspara el plazo de 10 meses, y trabajaron an ms. Pero la pruetra enc,ntraba defectos con ms rapidez de la e'.rpleada por los desarrolladores para corregirlos. Las correcciones en Lrna parte del sistema frecuentemente generaban problemas en otras. No habia posibiliclad alguna de acabar el dcimo mes. Kim convoc una reunin de emergencra. <veo que estis trabajando duro>, dijo. <pero no es suficiente. Necesito resultados. os he dado todo tipo de ayuda, y an no tengo ningn sofiware que ensear. Si no acabis pronto el producto, la cornpaia podra hundirse.>> Segn aumentaba la presin. bajaba la moral rpidamente. Segn pa_ saban los meses, el producto comenzaba a estabilizarse, y Kim t.t..rani"na la presin. Algunas de las interfaces se volvieon extremadanlente ineficientes' y se necesltaron varias semanas ms para nrejorar la eficiencia. Bob, a pesar de trabajar contra reloj, entreg su softrvare ms tarde que el resto del equipo. El cdigo estaba virtualmente libre de ,.ru "rro."r" haba cambiado algunos elcmentos de la interfaz de usuario, y las pruebas y documentacin de usuario no encajaban. Mickey se reuni con John y Helen. <No os gustar esto, pero las op_ ciones son ias siguientes: Podemos mantener el cdigo de Bob como est. y revisar ias pruebas y la documentacin de usuario, o podemos descartar el cdigo de Bob y escribirlo todo de nuevo. Bob no reescribir su cdigo. ni nadie del resto del equipo. parece que tendris que carnbiar la documintacin de usuario y las secuencias de pruebas.> Despus de oponer un poco de resistencia, John y Helen aceptaron de mala gana. Finalmente, 1os desarrolladores emplearon l5 meses en acabar el software. Debido a los cambios de aspecto, la documentacin de usuario perdi su lugar en el programa de produccin de la imprenta, asi que <lespus de que los desarrolladores tuvieran los discos naestros, hubo dos semanas ms de retraso en el lanzamiento mientras square-Tech esperaba que llegaran los documentos de la imprenta. Despus del lanzamiento la respueita de los usuarios a la versin 3.0 de square-calc fue poco entusiast, y al cabo de los meses descendi del segundo al cuarto puesto en el mercado. Mickey concluy que haba acabado su segundo proyecto un 50 por 100 de tiempo ms tarde de 1o planificado, igual que el prirnero.

2.1. Estrategia general para el desarrollo rpido

El modelo descrito en el F.jemplo 2. r es habitual. Evitar estc rnoclelo supone un esfuerzo, pero apartarse de estos malos hbltos est dentro del alcance de cualquiera. Sc puede obtener un desarrollo rpic1o siguiendo csta estrategia en cuatro partcs:

Captulo 2: Estrategia para el desarrollo rpido

13

l. 2. 3. 4.

Evitar los errores clsicos. Aplicar las bascs del dcsarrollo.

Gestionar los riesgos para e'n'itar ull retorno catastrflco. Aplicar nttodos orientados a planificacin. conto los trcs mostrados en la Figura 1.2 dcl Captulo 1.

Como se sugierc en la Figura 2.1. cstas cllatro tcnicas olicccrr soporte para el mcjor plan posible. Las imgenes con pilarcs no le llaman la atencilt r rradic. lero los pilures de esta figura nruestlan rarios puntos irnporlantes. E,l soporte ptimo para el rnejorplan posiblc cs tcner los cuatro pilares colocados en su lugar. y hacer que cada uno de ellos sea lo nts firc-rte posible. Sin el soporte de los tres primeros pilares. las posibilidadcs dc conscguir cl rnejor plan posiblc estarn en peligro. Podentos utilizar los nttodos lus potentes orientados a la planificacin. pero si contetentc'rs cl error clsico de descuidar la calidad del proyecto clt sLls fases inicialcs. clcsperdiciaremos ticmpo corrigiendo defectos justo cuarrdo cs u.rs carcl. Nucstrcr proyecto sc retrasar. Si pasan.ros por alto cl rxiontr dc desarrollo de crear un buen diseo antes cle contenzar a codillcar. ltLrcstro progfauta firllar cuanclo cambie la concepcin del producto durantc cl troceso cic desarrollo, y el proyecto se retrasar. Y si no controlrmos los riesgcts. pocler.nos descubriljusto antes de la fecha dc cntrega quc uu subcontratistr clave sc ha retrasado tres meses scgn el tllan. Dc nuevo tcndrentos rctrast,.

Mejor planificacin
posible

"!:s*
rrfiNti

rl

,i1rl

&#;; ;#;;
clscos desarrollo Figura

**M

Evitar errores

Bases
oel

Gestin Mtodos de orientados

riesgos la planif icacin

2.1. Los cuatro pilares del desarrollo rpido. El mejor plan posibte depende de evitar los errores clsicos, las bases del desarrollo y la gestin de riesgos, adems del uso de mtodos orientados a planificacin.

14

Desarrollo y gestin de proyectos informticos La figura tambin sugiere que ros tres primeros pilares ofrecen la rnayor parte del soporte necesario para obtener el mejor plan posibre. euizs no sea el soporte ideal, pero es la mayor parte de lo que necesitamos. Debemos ser capaces de obtener un plan ptimo sin mtodos orientados plaa

todo el trabajo, probablemente no tenclremos todo er soporte ne."su.iolsi lo hacemos una vez, puede que no seamos capaces de hacerlo de nuevo. Los tres primeros pilares rnostrados en ra Figura 2.r son bsicos para el xito del desarrollo rpido, as se har 1o posible para clarificar qu quiere decir evitar errores clsicos, bases del desarroll y gestin de ries_ gos. El captulo 3 trata los errores clsicos. En la nrayria de los casos, estar avisado simplernente de la natural eza d,e un error ser suficiente para evitarlo. as que en este captulo se muestra una lista de los errores clsicos. El tema de las bases del desarrollo se trata en el captulo 4, y el tema de la gestin de riesgos en el Captulo 5. El resto del libro trata de mtodos concretos orientados a planificacrn, incluyendo mtodos orientados a velocidad, orientados a la olanifi_

nificacin. Se podra obtener el mejor plan posible centrndose nicamenre en mtodos orientados a planificacin? Se podra hacer. La gente va ha rea_ lizado antes proezas como sta. pero como muestra la Figura i.2, ., ,n difcil problema de equilibrio. puedo mantener en equilibrio una silla en mi barbilla y mi perro puede mantener en equiribrio una galleta en sr-r nariz. Pero la elaboracin ile un proyecto software no ., un-t.uco de saln, y si confiamos en que los mtodos orientados a planificacin hasan

Mtodos orientados a la planif icacin

Figura 2.2. Resurtado de centrarse solamente en mtodos orientados a planificacin. Ni los mtodos orentados a ptanificacin ms avanzados son capaces de soportar por ellos solos el mejor ptan posible.

)aptulo 2: Estrategia para el desarrollo

rpido l5

resto de captulos.

cacin de riesgos y orientados a la visibiridad. En la tercera parte del ribro, <Mtodos recomendables>. se muestra el efecto de cad mtodo en la velocidad del desarrollo, planificacin der riesgo y visibilidad. Si desea pasar al desarrollo rpido en s antes de leer acerca de los tres pasos necesarios para conseguir las bases del desarroilo rpido, puede saltar al Captulo 6, <Cuestiones fundamentales para el desrrollo rpido>, y al

2.2. cuatro dimensiones de la velocdad de desarrollo

Tanto si nos hemos atascado en el lodo intentando evitar los errores como si cruzamos a toda velocidad utilizando mtodos orientados a planificacin efectivos, nuestro proyecto software se desarrolla a travs de cuatro dimensiones principales: personas! proceso, producto y tecnologa. Las personas trabajan rpidamente o lentamente. El proces ,upon. ,nu -.Jora en la actividad de las personas, o coloca un obstculo etrs de otro. Un producto se define de forma que casi se construye solo, o de forma que pone obstculos a los rnejores esfuerzos de la gente que est construyndolo. La tecnologa ayuda ar esfuerzo del desarrolro u obstacuriza los meJores intentos de los desarrolladores. Podemos potenciar cada una de esas cuatro dimensiones para maximtzar la velocidad de desarrollo. La Figura 2.3 ilustra esta idea.

Personas

Producto

Tecnologa

2.3. Las cuatro dimensiones de ra verocidad de desarroilo (mostradas aqu en dos dimensiones). podemos centrar la atencin en las cuatro dimensiones a la vez.
Figura

16

Desarrollo y gestion de proyectos informticos

Como rplica a este diagran.ra. algunos ingenieros diran: <E,h!, no son cLratro dinten.srttes. Son cuatro tlirec'c'one.s. Arn no podemos dibujar cn cr-ratro clirrensiones!> Es cierto. No se puede dibujar en cuatro dir.nensioncs. y sta es la raz(rn dc que la figura se muestre en dos dimensiones. Por cl conccllto qLle se quiere mostrar es lls rna dirnensin que una
d
i

rcccin.

Los libros de dcsarrollo de softr.vare tienden a hacer nfasis en una dircccin v a nrinir.uizar las derns. pero no hay necesidad de renunciar entre central'se en las personas. el proceso. el producto o la tecnologa. Si fucscn direcciones. cntonces centrarse en las personas podra quitar valor a centrarsc en la tecnologa. Ccntrarsc en el producto impedira centrarse en c[ proceso. Pero pllesto qlle son dimensiones. podemos centrarnos al misl.no tiempo en la gente. cl proccso. el producto y la tecnologa.
Las organizacioncs de softu'are tienden a t'er las dir.nensiones que no utilizan como valores fi.jos. y sta puedc ser una de las razones de que la planificacin de proyectos pueda ser frustrante. cspecialmente la planiflcacin teurporal. Cuando r-rtilizamos una sola dimensin, es prcticamente irnposible satisfacer los objetivos dc todos. El dcsarrollo autntrcamente rrido necesita que incorporemos gran variedad de tipos distintos de nrtodos (Boehm et ul..198.:l; Jones. 199 l). Las organizaciones r.ns efeclivas en la consecucin de un desarrollo rpido optimizan simultneamcnte las cuatro diurcnsiones. Aprender cada una de las cnatro dimensiones puede suponer una gran rcnta.ja para la planificacin del softu'arc: la planificacin pr"rede llegar a scr mis completa. rs creativa, ms efectiva y nos satisfar mejor. tanto a nosotros conto al resto de los intplicados. Las siguicntcs subsecciclne s tratan de las cuatro dimensiones v dc cnro
sc relaciorran.

Personas
Se conoccn los resultados dc experimentos concretos cn tcmas de personal (peotleu'arc). Poder.nos estar familiarizados con la tcsis de que la di-

fcrencia cn la proclu.^tividad cntre diferentcs desarrolladores cs al nrenos o estar lamiliarizados con la aportacin positiva que pucde tcuer unr utcjora cxplcita en 1a r.notir,acin. Lo que es rrenos lamiliar de la rnayora dc los dcsarrollaciores. incluida la mavora de la serrte de la industria. es que los resultados cn las incle dicz a uno.

vcstisacioncs sobre pcrsonal sc han ido acumulando de fonrra cstable

durante los pasados qr"rincc a vcinte aos. Ahora es posible hacer un recorriclo por rruchas cle las conclusioncs en estudios concretos. y sintetizar algunas conclusiones globales segrn las tendencias en la investigacin. La prirnera conclusin es que ahora sabemos con seguridad que los tcmas relacionados coll pcrsonas tienen un lravor impacto cn la produc-

Captulo 2: Estrategia para el desarrollo rpido

17

tiviclacl del sofiu'arc y por tanto cn la calidad del software. Desdc f-inales dc los sesenta. estudio tras estudio sc ha descubierto que la productividad de programadorcs concretos dc sirnilar nirel de experienciu pLrede variar en un factor dc al menos de dicz a uno (Sackr.nan. Erikson y Grant, 1968: Curtis. l98l: Mills. 1983: DcMarco y Lister. 1985; Curtis
1986: Card. 1987: Valett y McGarry. 1989). Los estuclios tambin han descubicrto r.ariaciones en la eficiencia de equipos cor.npletos del ordcn de 3, 4. o 5 a I (Weinbcrg -v- Schulman. 197.1: Boehm. 198 l; Mills. I 983: Boehr. Grav y Seeu aldt. 1984). Despus
er

ul.,

,:

=-ALES

dc 20 aos de erperirnentar cn pfoyectos rcales. los ini'cstigaclores del La-

boratorio de Ingeniera del Soltrvare de la NASA han llcgado a la cor.lclusin dc que la tecnologia no es la respucsta; los u.rtodos ms ef'ectivos son aquellos quc sacan partido al potencial humano dc sus desarrolladorcs (Basili er al.,1995). Puesto qllc est claro quc todo lo relacionaclo con peopler.r'are influyc fuertemente en la productividad. ahora tarnbin queda n.ruy claro que cualcluicr organizacin que trate seriantentc de ntclorar la productiridad primero debe ocLlparse c1c temas relacionados con pc-rsonal. contt'r lr ntotir,'acin. cquipo de trabajo. seleccin dcl personal y fbrrnacicin. Hav otras formas dc mejorar la productividad" pero la gcstin de personal of}ece los mayorcs beneflcios potcnciales. Si nos interesa cl dcsarrollo rpido. de bcmos preocuparnos de las personas. Conjuntarrcntc. los tcntas relacionados cor.t el persorral son r"ns in.rportantcs que cl proccso. el producto cl la tecnologa. Tendremos que tenerlos clt cuenta si buscan.tos el rito. Este rcsultado es contundente. pcro no dcbe tornarsc con.lo base de cualquier iniciativa relacionada con pcoplervarc cn cada rca. Los resultados de la investigacir-r simplentcnte dicen quc los cl-cctos cle la habilidad y motivacin individuales. y habilidad y motiracin clc.l eqr.ril'rtr son pcqueos factores que influyen en la productlvidad. No dicen especticamente que las camisetas. los refrescos gratis. las oficiurs extericlres. rccompensas de productir,'idad o la cerveza dc los viernes por 1a tarcle rrrc..jtrrcn la motivacin. pero hay una relacin clara: Llrla elrlprcsa que quiera n.rcjorar la productividad debe utilizar cstos utedios. E,ste libro incluye r''arias lirnnas de maxitrizar cl pcltencial Ituntano 1, reducir los planes del softrvare.

Seleccin del personal para equipos de proyectos. En su libro clave. Sofiture Engineerirtg Eccltctntit'.s. Barr, Boehnt presenla cinco Ir'irrcipios para la seleccin de pcrsonal (Boehm. 1981 ):
a a

,)Ixinto tulento. Usar poco y bucn personal. Trabttjo uclec'uudo. Asignar tarcas segn la habilidad y nrotiracin dc la gente disponible. Progresitr tt'o./e.sionul. Ayr-rdar a la _gente a actualizrrse por s

18

Desarrollo y gestn de proyectos informticos

REFERENCIAS CRUZADAS Para ms informacin sobre adecuacin de trabajos y cafiera profesional, vase "El trabajo en s", en la Seccn 1 1.2. Para ms informacin sobre el equlibrado de equipos y poblemas de personal, vanse el Captulo 12, "Equipo
.lo tr.h.i^\?

c o

mlsma en vez de obligarles a trabajar donde ms experiencia tienen o donde son ms necesarios. Equilibrado del equipo. Seleccionar a gente que se complemente y armonice con los dems. Eliminar la inadaptacin. Ehminar y reemplazar a los miembros problemticos del equipo lo antes posible.

Captulo 13, " Estructura del equiPo"

Otros factores que pueden marcar la diferencia son la habilidad de diseo del personal, la habilidad en programacin, la experiencia en el entorno y la rnquina y la experiencia en el rea de aplicacin.

Organizacin del equipo. La forma de organizar al personal tiene un gran efecto sobre la eficiencia con la que trabajen. Las empresas de software sacan partido a la estructura de sus equipos para que concuerden con el tamao dei proyecto, las caractersticas del producto y los objetivos de planificacin. Un proyecto software especfico tambin puede sacar provecho de la especializacin apropiada.

Motivacin. Una persona que carece de motivacin no va a querer trabajar duro, y prefiere dejarse llevar. La motivacin es el nico factor que provocar que una persona renuncie a las tardes y los fines de semana srn que se le pida. Pocos otros factores pueden aplicarse a tanta gente dentro de tantos equipos en tantas empresas. La motivacin es potencialmente el aliado ms fuerte que tenemos para el desarrollo rpido de un proyecto.

Diferencias en la productividad mayores de l0 a 1 entre individuos con diferencias en la diversidad y profundidad de su experiencia, Diferencias de productividad de 10 a I enrre individuos con los
mismos niveles de experiencia.

Diferencias en la productividad de 5 a I entre grupos con diferentes

niveles de experiencia.

Diferencias en la productividad de 2,5 a 1 entre grupos con niveles

de experencia similares.

Proceso
Tal y como se aplica al desarrollo del software , el proceso incluye tantas metodologas de gestin como metodologas tcnicas. E,l efecto que tiene el proceso en el plan de desarrollo es ms fcil de calcular que el que

Captulo 2: Estrategia para el desarrollo rpido

19

tiene la gente, y el Software Engineering Institute y otras organizaciones han desarrollado gran cantidad de trabajo para docurnentar y publicitar los procesos de softrvare efectivos. E,l proceso representa un rea de gran relevancia en la mejora de la r clocidad de desarrollo, casi tanto como las personas. Hace diez aos era razonable debatir acerca de la importancia de centrarse en el proceso, pero hoy da, como ocurre con el personal. existen gran cantidad de evidencias en favor de prestar atencin al proceso. Organizaciones cono Hughes Aircraft, Lockheed, Motorola, NASA, Raytheon y Xerox. que se han dedicado durante varios aos a mejorar explcitamente sus procesos de desarrollo. han reducido sus plazos de salida al mercado a la mitad, y han reducido costes y errores en un factor de 3 a 10 (Pietrasanta, 1991;Myers, 1992; Gibbs. 1994; Putnarn,1994; Basili e al.,1995; Raytheon, 1995; Saiedian

y Hamilton, 1995).
Algunas personas piensan que ocuparse del proceso es agobiante, y no hay duda de que algunos procesos son demasiado rgidos y burocrticos. Hay gente que ha creado estndares en procesos principalmente para sentirse ms poderosos. Pero se trata de un abuso de poder, y el hecho de que se abuse de centrarse en el proceso no debe permitir echar por tierra los benefrcios que puede ofrecer este enfoque. La forma ms habitual de abusar del proceso es 1a negligencia, y su efecto es que desarrolladores
inteligentes y concienzudos trabajan ineficientemente y con objetivos cruzados, cuando no sera necesario trabajar de esta forma. Centrarse en el proceso puede ser ti1.

DATOS REALES

Evitar la repeticin de trabajo. Si en las ltimas etapas del proyecto hay un cambio en los requerinrientos, es necesario redisear, recodificar y volver a hacer las pruebas. Si ha habido problemas en el diseo que no se descubren hasta la prueba, se debe volver al diseo detallado y la codificacin y comenzar de nuevo. Una de las mejores fonnas de ahorrar tiempo en los proyectos software es orientar el proceso de forma que se evite hacer la misma cosa dos veces. Raytheon obtuvo en 1995 el IEEE Computer Society's Software process Achievement Award por reducir sus costes de repeticin de trabajo dei 4l por 100 a menos del l0 por 100. y simultneamenre triplicar su productividad (Raytheon. 1995). La reiacin entre estas dos proezas no es una casualidad. Control de calidad. El control de calidad tiene dos objetivos princrpales. El primero es asegurarse de que el producto entregado tiene un nivel de calidad aceptable. Aunque se trate de un objetivo importante, est fuera del alcance de este libro. El segundo objetivo es detectar los errores en el proceso en el momento que haya que emplear menos tiempo (y menos diseo) para corregirlos. Esto siempre quiere decir localizar los errores lo

,i,

REFERENCIA CRUZADA Para ms informacin sobre control de calidad vase la Seccin 4.3, "Bases del control de calidad".

20

Desarrollo y gestin de proyectos informticos

ms pronto posible desdc cI lrontento en el que sc introducen. Cuanto rrs tiempo pcnnanczca un error en el producto. ms tiempo (y ms dinero) se emplear cn clinrinarlo. Por tanto. para un progranta serio de desarrollo riipido cs indispensable controlar la calidad.
BEFERENCIA CRUZADA Para ms informacin sobre las bases del desarro lo, consulte la Seccin 4 2, -Bases
tecn lcas,,
.

Bases del desarrollo. La mayor parte del trabajo realizado durantc los pasados 20 aos en el campo dc la ingeniera del softrvare est rclacionada con clesarrollar softu'arc rpidamente. Muchos traba.jos se centran cn la <productiriclacl> ns quc cn cl desarrollo rpido en s mismo. 1' por csto algunos de ellos sc han oricntado hacia obtencr el tllisnro trabajo hccho por nenos gentc. cn vcz de conseguir hacer el proyccto ms riipidarnente. Sin cmbargo. podemos intcrpretar los principios subyacentes descle cl punto de vista clel desarrollo rpido. Las lecciones aprcndidas a lo largo c1e 20 arlos clar.rclo tropczoncs pueden ayudar a que su proyecto se desarrolle tranquilamente. A pesar de qr.rc los r.ntodos estndar en in-ee-

niera del soft'uvare para el anlisis. diseo. constrtrccin. intcgracin y

prucba no van a acelerar por s mismos el plan de fbma firlgurante, pLrcden cvitar clue los proyectos se quedcn fuera de control. La ntitad del desaflo del desarrollo rirpiclo consiste en c'n'itar cl desastrc. y sta es un rea en 1a que sobresalen los princirales cstndares de desrrrollo clcl softu'are.
REFEFENCIA CRUZADA Para ms nformacin sobre gestin de
,,Y9u vvorc cl

Gestin de riesgos. La gestin

de riesgos es Llna de las tcnicas espe-

cflcas que se centran en evitar el clesastrc. El desarrollo rpido no es sllficientcrxentc bucno si durante dos setnanas antes de la fecha dc cntrega
nos clucclamos fircrr de.j uego. Para prograr.nar un desarrollo rpido es rrecesario gestionar los riesgos asociados con la planifcacin.

Captulo 5, "Gestin de rlesgos".

Atencin a los recursos. Los recursos pueden enfocarse de fbrma e fectir,'a y ayudar ir la procluctividad global. o pueden dirigirse ntal y usarsc dc fbrnra inef'cctir"a. En un proyecto de desarrollo rpido. es incluso rns irnportante de lo habitual acertar al rnximo er.r el rncior plan. Tcnicas con.ro oficinns productir''as, desarrollo cn ventanas temporales. planificacin a.justacla y horas ertras r,'oluntarias ayudan a asegurarse dc que cacia da sc hace todo el trabajo posiblc.
REFERENCIA CRUZADA Para ms informac on sobre la planifrcac on del ciclo de vida. consulte el Captulo 7. ,,Planlf icacin del clclo
Oe vlOa,,.

Planificacin del ciclo de vida. Una de las clal'es para la asignacirr efcctira clc los recursos cs utilizarlos dentro de un ciclo de vida deflnido quc tenga sentido para cl proyecto concreto. Un modelo de ciclo de vida es til porque describc r-rn plan de gestitin bsico. Por ejcmplo. si tenemos un llroyecto arriesgado. cs recomendable un ciclo clc r''ida oricntado al ricsgo: si los requerir.nicntos no estn claros. funcionar n.rejor r.rn rnodelo cle ciclo de vida increr.ncntal. Los modelos de ciclo de vida hacen qlte sea ms fcil identiflcar y orgarrizar las muchas tal'eas neccsarti.ts cn un proyc-cto sofiu'arc. y as poder realizarlas con la mayor e ficacia.

Captulo 2: Estrategia para el desarrollo rpido

:::=RENCIA
] UZADA

21

:. -':,f t.tactn :-:-:ac on ai ': ::.su te e ::l 1u o 10, : I _1r entaoo

.- C ente..

Orientacin al cliente. Uno dc los cambios fundamentales entre el desarrollo de softu'are tradicional sobre mainfiames y los ntodernos estilos de
desarrollo es el giro hacia las necesidades y deseos del cliente. Los desarrollaclores han aprendido que desarrollar el software a partir de la especificacin supone slo la mitad del trabajo. La otra mitad es ayudar al cliente a deflnir el producto quc dcsea. 1, la mayora de las veces es necesarla una aplorimacin diferentc a la tradicional especificacin en papel. Ponerse en su lugar es una dc las rnejores fbnnas de cvitar las vueltas atrs maslvas provocadas por el clicnte que decide que el producto correcto no es el quc se est dcsarrollando desde hace 12 meses. Mtodos colno la entrega llof etapas. entrega evolutiva. prototipado evolutivo, prototipado desechable y rregociacin conveniente rpoltan Vc-ntajas a este rea.

. ... ,.;i: .;,..,

'

::";'b:l:":'i;1:;

,;:;. ;,;:,;ii .,;

:

En este libro^ cuando hablamos de clientes nos referimos a quienes pagan para que se desarrolle el software y son los responsables de aceptar o rechazar el producto. En algunos proyectos se trata de la misma persona o grupo de personas, y en otros son diferentes. Hay casos en los que el cliente es el autntico cliente de carne y hueso que paga el coste del desarrollo del proveclo directarnente. En olros proyectos. es un grupo interno dentro de una organizacin. An queda otro tipo de proyectos, en los que el cliente es la persona que pone sobre el mostrador 200 dlares para comprar el software <prt--porter>, En este caso, el cliente real es un cliente lernoto y habitualrnenre hay un directivo o un especialista de mercado que

lo represerrla.
Segn sea la situacin concreta, el trmino <cliente> puede representar <cliente>. <especialista de mercado>>, <usuaio final> o <<jefe>.

Producto
La dimensin rrs tangible dcl cuarteto genteiprocesoiproducto/tecnologa es la climensin producto, y ocupal'se del tantao y caractersticas del prodr-rcto plantea enoflncs oportunidades de reducir la planificacin. Al rcdLrcir el cclnjur.tto dc prcstaciclnes del producto rcducimos el plan. Si el conjuuto de prestaciones cs flexible. se pucde aplicar la regla 80/20 1'clesarrollar el 80 por 100 dcl producto empleando slo el 20 por 100 de1 tiemtr-ro. Mis tarcle se dcsarrollar el 20 por 100 restante. Si hacemos que el aspccto. las caracter'sticas dc rendimiento y las caractersticas de calidad dcl proclucto sean flcriblcs. podernos ensatnblar el producto empleando componentes preexistentcs y cscribir la r.nnima cantidad de cdigo especiflco. E,l total en la reduccin sobrc cl plan que sc obtiene al ajustar en el tanrao v las caractersticas dcl producto slo se ve limitado por el concepto cle prcducto quc ticnc cl cliente y la crealividad del equipo.

22

Desarrollo y gestin de proyectos informticos

Tanto el producto como las caractersticas clel producto ofiecen oportunidades para acortar el ticmpo dc clesarrollo.
REFERENCIAS CRUZADAS Para ms informacin sobre Ia manipulacin del tamao del producto para obtener velocidad en el desarrollo, consulte el

Captulo 14, "Control

del conjunto de

prestaciones". Para
ms informacin sobre el efecto del tamao del producto en el plan de desarrollo, consulte el Captulo 8,
" Estimacin "
.

producto. El tamao del producto es el elernento individual que ms aporta al plan de desarrollo. para productos grandes se ernplea nrs tiempo. Para productos nis pcquerios. menos. prestaciones adrcionales necesitan especificacin. diseo. construcciones, prueba e integracin adicionales. Rcquieren ttna coordinacin aclicional con cl resto tle las utilidades. y neccsitamos coordinar las otras con ellas. puesto que el esluerzo para construir softwarc se increncnta clesprclpor-cionaclamentc ms rirpido que el tamao del software. la recruccin clel tanrao urejorar la vclocidad del desarrollo clesproporcionadamente. Reducir a la mitacl el tamao de un progranra intermedio nornralmcnte supone una reduccin de ai menos dcs tercio,s del esfuerzo. Podemos reducir drsticamente el tarnao del pro<lucto esforzndonos en desarrollar slo las prestaciones ms esencialcs. o rcducir-lo temporalmer.rte desarrollando el producto en etapas. Tanbin es posiblc reducirlo empleando un lenguaje de un nivel ms aito o un conju'to cle herramientas para que cada utilidad necesite menos cdigo.
Tamao del

REFERENCIA CRUZADA Para ms informacin sobre el efecto que pueden tener los objetivos en el plan de desarrollo, consulte "Definicin de objetivos", en la Seccin 1 1.2.

caractersticas del producto. Aunque no rienen la misma influencia que el tamao del producto, hay otras caractersticas clel proclucro qlle afectan al p1an. Se emplear ms tiempo en desarroliar un producto con objetivos ambiciosos respecto al rendimiento. uso de memoria. robustez y fiabilidad que el que se emplear en uno sin nin-en ob.ieti'o para estas caractersticas. Hemos de elegir nuestras metas. Si la autntica prioridad es el desarrollo rpido, no pondremos trabas a los desarrolladores insistiendo en demasiadas prioridades a la vez.

Tecnologa
REFERENCIA CRUZADA Para ms informacin sobre herramientas de productvidad, vase el Captuto t S, " Herramientas para aumentar la productividad..

una fbrma rpida de la velociciad de clesarrollo es Dasar cle usar 'ejorar herramicntas menos efectivas a otras ms efectivas. En la hisroria det desarrollo de software. uno de los cambios con mayor influencia fue el paso de lenguajes de bajo nivel, como el ensamblador, a lenguajes de alto nivel, corno c o Pascal. La actr"ral tendencia haua componentr.are (vBX y oCX) puede producir resultados igualrnentc espcctaculares. La seleccin de herramientas efectivas y la gestin de ros riesgos asociados son aspectos claves en una iniciativa de desarrollo rnido.

DATOS REALES

ffi

Sinergia
Hay un momento en que ocuparse de la gente, cl proceso, el proclucto y Neil olsen rcaliz un estuclio cr.r el que descubri que pasar de una inversin baja a media e'pcrsonal,
Ia tecnologa se convierte en un todo.

Captulo 2: Estrategia para el desarrollo

rpido

23

formacin y entorno de trabajo produce unas ganancias similares: inversiones adicionales se justificaban con ganancias i a l, aproximadamente. Pero al pasar de una inversin en personal. formacin y entorno de trabajo dc nilcl medio a alto. la productividad se dispara, con una ganancia dc 2 a 1, o de 3 a I (Olsen, 1995). Los urtodos de ingeniera del software tambin pueden cooperar. Por ejer-nplo. los cstndares en codificacin de una organizacin ayudan a proyectos concretos. pero tambin hacen que sea ms fcil reutilizar componentes en otros proyectos. A la r,'cz, un grupo de componentes reusables pucde ayudar a que se respeten los estndares en codificacin, y asegurarse de que mantienen el significado entre distirrtos proyectos. Las revrsiones del diseo y el cdigo ayudan a distribuir el conocimiento sobre los estndares en codiflcacir-r y los componentes reusables existentes, y f'acilitan cl nivel de calidad necesario para que la reutilizacin tenga xito. Buenas tcnicas sueien ser la bases de otras.

Tipos generales de desarrollo rpido

Difcrentes situaciones requieren distintos niveles de compromiso en ia vclocidad de desarrollo. E,n algunos casos. nos gustara incrementar la velocidad de desarrollo sicmpre que sea fcil hacerlo, y sin que suponga un coste adicional ni la dcgradacin del producto. En otros casos, las
circunstancias requieren que increr.nenten-ros la velocidad a cualquier coste. La Tabla 2.1 describe algunas relaciones entre diferentes enfoques de desa-

rrollo.
Tabla 2.1. Caractersticas de los enfoques estndar de desarrollo orientado a la planificacin
Ef'ecto del enfoque de desarrollo en.,.

Enfbque de desarrollo
N4todo normal

...

Plan

... Coste
Medio

... Producto Medio

Medio

Desarrollo eticiente ( equilibrio

de coste, plan y' tirncionalidad) Desarrol lo eflcientc ( desarrol lo efi ciente orientrdo hacia el nre.lor plan)

que media Mucho rnejor que la media

Me.lor

la

Meor que la nredia

Mejor

que

la media

Algo rnelor que la media

Algo mejor
que la rnedia Peor que la media

Desarrollo rpido a fondo

El ms corto Peor que la

posible

media

24

Desarrollo y gestin de proyectos informticos

Desarrollo eficiente
REFERENCIAS CRUZADAS Para ver un ejemplo de los benef icios dei desarrollo raprdo, consulte la Seccin 4.2, "Bases tcncas", y de forma general el Captulo 4, -Bases del desarrollo
de software".

Tal como se ve en la Tabla 2.1. el rtodo nredio es... nleciio. El se-cunclcr enfoque nrostrado en la tabla se c.tiqucta corno <clesarrollo etlcienre)). y. como muestra la Fi-uura 1..1. es la conrbinacin de los tres pilar.es clc la velocidad mrima de c'lesarrollo. E,ste enfoquc es el que sencra nrL-ior
resultado que la media en cada una cle las tres catcgoras. N{ucha -ucnte alcanza sus objetivos cle planificacin dcspus cle roner los trcs prinrcros pilares cn su sito. Algunas personas clescubrcn quc clcspuers cle toclo ncr necesitaban el dcsarrollo rpiclo; slo tcnan c'ue organizarscl para muchos proyectos. cl desarrollo etlciente sLlllonc rLna optintizacirin notrblc del costc. plan y caractersticas del proclucto. ,Se pueclen conseguir planes cortos sin alcanzar prinrercl cl clesarrollcr eficicnte'.) Es posible. Podemos elegir mtodos cf-ectir.os v orientacios u la planificacin v evitar mtoclos lentos e ineficaces sin ocuparrnos tlel desarrollo eflciente cn s Sin enrbar_uo. aunclue sc obtenga el clesarrclllo eficiente, las posibilidades de rito cn el uso cle r.ntoclos oricntados a planificaci6n son inciertas. Si cmplcanros nrtoclos concretos oric-n1ados a planificacin sin una estratcgia general" emplearcmos nriis tie nrro mejorando la capacidad c'le dcsarrollo global. por supucsto. scilo uosotros

.$.s

Mejor planifrcacin posible

clsicos desarrollo
Figura

Evitar Bases errores del

FM

e@M

e&

Gest
de rie

Mtodos orientados a planif icacin

2.4. Desarrollo eficiente. Los tres primeros pasos para lograr el mejor plan posible conforman el *desarrollo eficiente.. Muchos equipos de proyectos descubren que el desarrollo eficiente ofrece toda la vetocidad de
desarrollo que necestan.

Captulo 2: Estrategia para el desarrollo

rpido

25

srbrcmos si r-'s urs importante me'jofar las capacidades cle desarrollo glo-

bal o intentar acabar nras lariclanreute uu pfolecto coucrcto. Otra razn pafa ccntrafse en el clesarrollo cflciente consiste en que en la rlayora clc las olganizncioncs. Ios clnrillos para llcgar al desarrollo eficientc ) obtcner planes nris cortos son los n.lisr.r.ros. E,n cstc aspecto. hasta llegar a cieflo llLluto. los canrinos hacia planes cortos. nrenos def'cctos v llrenor coslc son tanrbin islrales. C'onro r.r.rucstra la FigrLra 2.5" cuando sc alcanza el cie'sarlollo ctlciente los ciulrinos e()lnicuzan a scpararse. per() dondc uos clrcontran.ros ihora. la nral'ora cle los grupos cle desarrollo sc bcneflciarian dc poncr runtbo cn printcl lugar hacia cl clesa-

rrollo elicienlc.

Desarrollo eficiente orentado hacia el mejor plan

,-:
EFERENCIAS CRUZADAS Tas rnf ormac n
B

El tercer cntbque

dc-

clcsarrollo nrostrado cn la Tabla 2.1 cs una variacin

ciel clcsarrollo eficicutc. Si e stanros aplicanclo el dcsan'ollo

cllcicntc y velltos

:-:aos oflentaoos

: -. r:

dad o mtodos :-:aoos at r esgo 0 an consulte la

clue an nccesitamos una nrc.jor eficacia clcl plan. pociemos optar pof ntetcldos dc clcsrrrollo clur' sc oLrcr.rtcr.r lr rne re-ntentar la r elociclaci dc dcsarro-

:=:c on L2..Cmo - -t'ar e desarrollo

raptdo,,. y la ::,c o 6 2. ,,Qu : -.o 0e desarrollo -:. do necesita?',

llo. rcciucir cl ric-s-uo dc la planrfictcirr o urejorar la risibilidacl dcl progre s(). Tcrrct'cmos qLle haccr peclueos sacrifle i()\ L-lt costl- I, ca|re tcrsticas
dcl prociLrcto llara ganar clt tclocic'lacl o prcclccibilidad; sin crrbargo. si paltimcls clc la base clel clcsan'ollo eflcicntc" aun cstarcntos utuy pol encin-ra

dc

lt mc-clia.

Ciudad del desarrollo

Para llegar aqu use mtodos eficrentes en general

rpido
A la ciudad de reducci
de defectos

Ciudad de la olanificacin y cosre

\
Ciudad del

A acudad
desarrollo
ef

iciente

oe maxrma satrsfaccin del usuario

Figura 2.5. El camino hacta el desarrollo rpido. Desde donde estan ahora la mayora de las organizaciones. la ruta hacia el desarrollo rpido sigue el msmo camino que Ia ruta hacia el mnmo de defectos, mximo de satisfaccin del usuarto y los menores cosfes de desarrollo. Despues de llegar al desarrollo eficiente, las rutas comenzan a separarse.

26

Desarrollo y gestin de proyectos informticos

Desarrollo rpido a fondo

REFERENCIAS CRUZADAS Para ms informacin soore pranes nominales. consulte
. Plan
if

Hl irltinrc'r cr.rfirquc- cle clesarrollo oricntar'lo a la planificacin es el clenol.ntnaclo <ciesarrollo ruitrirkr r tirndo>. la courLrinicin cle mcltcldos ot'icntados

icacion

nOmlnaleS", en la Seccin 8.6. Para ms informacin sobre costes de la reduccin del plan. vase ,,Dos Seccin 8.6.

REFEFENCIA CRUZADA Para ms infornacin sobre la necesrdad de

.locr/r^ll^ rf,r.l r

fondo. consulte ia Secc n 6 2. ,,Qu t po de desarrollo rpido necesta? -

a planil'icacitin cficit--ntcs e ieflcientcs. l-lcga u11 ptlltto cn el ctre trabajanros lo rne.lor v lo mas dr,Lro cluc poclcnros. t t'u irr Ltttico qtLe Llucda por hacer cs ragar rnlis. retluclr cl conirrnto clc caracteristicrs o reducir el lre tl.it..l.t de l Pt'odlit l,r. LJn e'jcnrplo cie quc! cluiere rlecir nitt'lcio <inclicicnte)) cs: podeutc'ls t'eclucir cn un 2-5 iror i0() el pian clc dcsarrollo nonrinal cle un prol,ectcl sinrplenrcnlc inclLrvcnclo mas gcntc. Siu clnbargo^ cicbido rl increr.ltcrrto en las conrunicaciones 1'la gcstitin global. su'clcbcra incrcntctttar cl tanrao clel cquipo en un 75 por 100 pant obtct-tct'una rccluccin clcl plan dc un 2-5 por l(X). El ef'ccto nclt cle acortar el plan 1'agranclat'cl tantao del cqtripo cs cplc cl pro;-cc1o cucsta un 3.i 1'lr.rr 100 nlris cluc cl ltro.vccto origirtal. L.l salto ai ciesan'ollo r'pido a tbnrlo cs urr gran paso. v es tteccsario aceplai'cl inclctnentcl en cl riesgo clel ltlan o las gt'atrdes cotrcesiones cn coste v caractcristicas clel prodLtcto. () arttbos. Pocos proycctos aclmitct.t e'stas coucesioncs. v la mavoru sc acaban nrcjclt'itsanclo slo alguna fbrrrra de dcsarrollo cficiente.

2.4.

Cul es la dimensin ms importante?

Boeins. \'lict'osolt. NAS.,\. Ra1'tliccln v otras cllpresas han aprerlcliclo a desan'ollal sofiriarc clc lbrma cple sc a.iuste a sus neccsidades. A nivel
stratgico. cstas clistiutas clllprcsas licnct.l bastante etl conrtttr. Han atrlrcntlitlo a e'r'itar los crrorcs clsicos. Aplican las bases clel clcsarrollo. Y lcalizan unr gestin acli\'r dc ricsgos. A nivcl tctico. cxistc un nlundo cle cliferencias cn las lbrmas cn lrs quc cacla una dc csrs orqanizilciolrcs que han tcniclo rito sc cL-ulru cn la gcntc. cl proccst'l y'la tccnologa. I)ilerentcs provcclos ticncu clilcrentcs necesidades. pero en todos los castls la clrvc cs rccptrf los lnritcs cn las dinrensiones que no podentos crnibial v ccntrarsc cn las olras dinrensiones para obtcner el rcsto cle los bcneticios quc lrcccsitanros cn la planificacirin. Si estamcls clesarrollanclo un sistenrr cie inycccin de courbustible cle urr cochc. para clcsarrollar sofiri'arc cn'rl.rotrirclcl dc tienrpo rcal no podeluos utilizar lcnguajcs c1c cuarla ge ncracin o en.rpleal entornos de progranracrtin risnrl: neccsitan.ros ilis cflcicncia l mavor conlrol a ba.io nivel dcl que o1'rcccn esns helranliculas. Evital'cmos cxpandir demasiaclo la clirnensin de la tccnologit. hn vcz dc cso. dcsarrollarcnros la tecnologa lo quc todanios. y ceutrarenros toclos nucstros esfuerzos en las dimcnsiones cctrrespondicnles a personas. proccso y producto.
e

REFFRENCIA CRUZADA Para ms informacin

sobre la personalzacin

de os procesos
solllvar e a las necesrdades de proyectos concrelos. vase 1a Secon 6.1, ,,Existe un modelo n co?-

Capitulo 2: Estrategia para el desarrollo rpido Si estanros trabajanclo cn Lln pfosranra clc gcstirr domstica. quizs

27
se

rrtilicc url lcnguaie tlc cuut'tu genr'r':rein. un entorno clc proeranrtrcin yisLlal o ull'l herrrtrtict'lt CASE. Potlren'los crpanclir al mhrin.to la tccnologa. Pcro podr'a tlaba.jlr nllra rurl cnrl)rc\il pesacla quc nos impicla hacer
tlrttchas cosas ct'l ia dirttcltsirirt corrcsroudicutc r las pu'sctnas. Se clcsarrollrrh la clinrensitin cL,-l pcrsonal toclo lo cLrc rclnrita la compaa. ),el rcsto dcl cslcrzo sc enrrleani en las cliurensioncs crc rroccso y proclucto. Si t|abajanrr)s en ulr nrercaclo diri-giclo Irrrr pr'!-\tirci()nL-s clr paquctes ((pft--llortcr'). no l.loclcnros rcclLrcir cl conjunto clc prestacioncs lo suflcientc cr.rn'rti para tencr Lrn lrlan ar-rstacio. Sc rcclucirn lo rs posible v se clcsarrollarn la gcntc. el rroccstl y, lir tccnologa hasta obterrcr lo rrccesa-

n0

plra

cubrir cl plan

Este libro describe tres tipos genelales de proyectos: cle sisfent,,-, de.qest(tt .t ,, l1t (:t-r't.l)(tt'lL't
,,.

El softr.r'are <<prt-c)-porte.> es soltrvare empaquetaclo y que se vencle cornercialmente. Incluvc trltto Irruductos pilra el rnercado horizontal (corno tratarrientos dc texto v hojas de clculo), corno productos para el mercado (como rrogramas de anhlisis nanciero. escritura cle guiones y ges'ertical tin de infoluraoin lcgal). Se emplca' algunos ot'os t'ninos para ref-erirsc a tipos de softu,are que no estn clescritos por estas tres etiquetas generales. Softu'are (.oner, cial es cualquier tipo de softu,are desan'ollado para venderlo comercialrnente. Ef software dontstic es el softr.vare desarrollado nicamente para usos domsticos y no para la venta. E,l soft,,vare militur se escribe parauso nrilitar. El softrvare iilfera(rivo es e I softu,'are con el que el usuario puede intelactuar clirectarnente. cue engloba la lravor partc del softu,'are que se escribe hoy dia.

inclr-rye el sistcma operativo. controladorcs de dispositi"'os. compiladorcs 'bibliotecas de cdigo. Desde el punto de vista de este libro (-".' a pesar cle sus dif'erencias). el sofiv'are entpott.crtlo, finn,t'ure, sistat|u.s en lienpo t'col 1' sofiture cietrf.fico tienen las misrnas caractersticrs que el soft',,uare de sisternrs. El software de gesriltn se reflere a sistcrnas internos. q'c' se utilizan en una nica empresa. [runciona sobrc un hardrvare limitado. quizs un nico computador. Los cjemplos tpicos son sistenras cle control de nminas. contabilidad o control dc ahacn. El.] cste libro. el sotin,are IS, IT y MIS se tratan corno pertenecrentes a un grupo ms general. el soflware de gestin.
c1e ,ri.r're,r"r

Hl softlvare

[:u resurnen. se clebc analizar el pnlvccto para c'leternrinar curl de las cLlatro clitllensiones cst linritaclu I cLuil puecle suponer la r.n riuta rcta.ja.
Lttegc'r liav qtrc fbrzrl cittlrr unlr r'l nltriru,,. [rsta es. cn resumiclrs cucntas. la clar,'e clcl rito dcl clcsarrttllo rpiclo.

28

Desarrollo y gestion de proyectos informticos

2.5. Una estrategia alternativa para el desarrollo rpido

REFERENCIAS CRUZADAS Para ms informac n soore enloques basados en
<^ ,, .^<L lio

Planif icacin basada en compromso,,. en la Seccln 8.5, y

El enfbclr-rc para el dcsalrollo rpido cluc se tratt cn cstc libro no es ei unico c'nfbque conocidcl ;\lsunos provcctos han scgLriclo con rito tLn carnino clif-erentc. Estc crurino se clrctct'izil ltor colttratal al ntcjor personal posible. buscirnckr un conrpronliso total con el llrovccto. sarantiz;.ildolcs casi totrl autononra. nrotirlrdolcs en graclo crtrcmo. r'clcspus eonrprobirr que trabajan 60" 80 o inclu-so 100 horas a la sertrana l.rasta qr-re bir':t cllos o el provccto tcrnrinrn. El clcsalrollo rirpiclo con Lllr cnfircue basacl, en cr)lrprouriso sc consir:ue cou valor. suclor 1' detcnlinrcititr. Este enfoquc ha gcneraclo ri1os notables. incluvenclo N{icrosoti \\ inclous NT i.0 r cl l)ata (ienr-ral Faglc C'ontputer" I'cs incucstionable clil. cs cl enfbquc dc dcsarrollo rpido nts polular clue sc usa hoy clia. Pur'., una cmpresa cn clcsarrollo con preoclrpacioncs fespecto a sLl econont:,.. sLrpone la rentaja clc sacar el trabajo cle clos lleses cle un cntpleado con . laga de Llu mes. Esto puccle lrArcAr la clif'erencil put' ar'ehur urr plocluc. clarc a tier.nlo clc colocarlo cn cl ntcrcado. haciutdo que la entplest g.t::, una fbrtuna v cousi-ga dinero rtrriclamente" llrtcs incluso cle clue el erlut:' acabe el prclclucto. iVlrntener un cquipo cle pequeo tantao tarrbin lc.i .cc las corl.runicacioncs. la coordinacirin 1, la gestin global. Si se entp. conocienclo los intcrrsos riesgos 1' con algunas lin-ritaciones. el cntb.: ..pucde tener rito. Dcsafortunaclanrente. cstc cntbque sicrnprc cs llcr rclo a la prctre .i , ms durcza qr.re cr.riclaclo. Nornralrucute un enfbclue clc coclit'r , -senera cin a clcstajo. clue provoca qne los provcctos se alrrgucl.l conlo sl tir;:.. etenros. El enfoque es una correccin rpicla" v ticnc toc'los los problc:: de otras correcciones riipidas. A lo largtt del libro sc criticarr tspt-.crrr. . este enfclclr-rc. A cclnlinLrrcin se ntucstra un resuuten.

el Capitulo 34. -Comprom so,,.

El enfoque implica ganar o perder. A vece s fLrncionr: 0 \ CCC. Los frctorcs quc hacen quc fimcione o no son prcticaurentc ilnpr'- ' clc controlar. Curndo se llcga al flnal clel pt'o_vecto. l veces se obri; , firncionalidad que se planil-ica; v a veces rros sorprender.r.los. A r.'.:consiguen los ob.jctiros cle calidad; a veces no. Este enfircluc hacc.1L.. difcil contrcllar lis caracterslicas cspccficas del proclucto.

Provoca problemas de motivacin a largo plazo. En los |r.o\ -colrprolliso. los desarrolladorcs con'ricr.rzan con cntuSr.i.:-' cnrplear.r tantas horrs cxtras colno elt sus tientpos clc princitrtiant.'. completar sus conrpronrisos. Nonralntcntc. r.lo cs suf icielrte colr :r' .. horas. - firllan al intcnlar conseguir los conttronlisos dcl plan. L. nr. ., sr-r r.lroral se allaga )'sc ven obligaclos r rclntitir la dcrrota. C'nlnclo lcls clcsan'olladores ponclr su colazirll , su alnra intl: lograr sLts conrlron-tisos fallan. se ruclrct.l lcae irls tt i.lcr-l)tlu'!\,r rr'
basados clr
.

"

Captulo 2: Estrategia para el desarrollo rpido

29

sos adicionales. Comienzan a resentirse cle las horas ertras. Aceptan nuevos courpror.r.risos de palabra pcfo lro c'lc corazn, y' el proy'ccto picrdc todo aspecto de plarrilicacin o control. En un proyecto cluc ha alcanzado este estado. es cor.nrn decir <cluedan tfes sclnanas para cl final>> dr-raute scis rleses o mhs.

No se puede repetir. Ar-rncluc cl cnfirque cle codiflcacin a destajrr terrga rito una vez. esto no sLlponc unr basc para cl ritcl en otfo caso. Puesto que cansa a la gcntc. cs ms probable qlle sientc las bases para futuros l'allos. Una errpresa r.ro puede reparar fcilnentc el clao hut.nano quc provocan cstos proycctos. y los estudios de estcls pro)'ectos indican quc provocan uu sran volur.nen de canrbio dc pcrsonal (por ejernplo. Kiddcr. 1981: Carroll. 1990: Zachary'. 199-l.

Es duro para organizaciones no dedicadas al software. E,l enfbclue dc codiflcacin a destaio aporta poca viabilidad y cor.rtrol a los den.rs irrplicados en el provccto porclLle se basa en hcroicidades indil'iduales en vez de en la coordinacin. coopcracin l planrficacin. Incluso cuando sc dcsarlolle con rito cl sofirvare ms rapidamctrte de lo c1r-rc cs habitual, no hay fbnna de saber cunlo llcrar el proyecto. No sabrcnros cunclcl acabar hasta quc' se acabe.

Alguno de los beneflcios dc relociclaci cluc'sc consiguen con cl cnfoque basaclo en conlprouriso sc neutraliza debiclo a quc hay otros grullos con quienes cleben coorclirrarsc los clesarrolladorcs. couro son los gfupos de prueba" documentacill dc usuario o cor.uercializacin.;'' rro se rucdc planificar. En un ployecto a desta.jo. la fl'ustracin dc los dcsarrolladorcs al no poder obtener informacin flable ciel plan provoca Llna tcndL-uclf, a la irritacill. , cl pcrsonal clcl equipg est ett colltra dcl pcrsortal ertcrno al equipo. Lo quc cs bucno para una parte del proyccto no cs buencr llcecsal'iltlnetttc l)at't cl pt'ttyccto eolllIlctrr.
Se malgastan recursos humanos exageradamente. Los dcsarrolladorcs que participau cn cstc tipo de proyectos se olvidan dc la f-amilia. ar-nigos. hobbics c incluso c'le su rropia salud para tener rito cn cl trrroyccto. Selcros conflictos pcrsonales son la rcgla en \;cz cle la erccpcirin. Este nivcl cle saclillcio pLrcdc scr justitlcable pal'a gallar Llul guerra o llc'r'ar un hombrc a la Luna. pcro no cs ncccsario para clesarrollar softu'arc de gcsticin. Con pocas excepcioncs. cstc sacrillcio no es ncccsario: sc pucdcn conscguir' los lrismos resultados con llnl gestin cuidaclosa. scria e intcligcntc y con uua planificacin tcnica. lo que suponc lnucho urcuos csfuerzo. La Tabla 2.2 resunre al_eunas clc las difcrencias entre el mtodo a destajo y cl quc dcscribe este libro. EI nltodo dcscrito cn este libro mr-restra c(rrro obtcner cl dcsarrollo rpido con una planificacirin cuidadosa. Llna Lrtilizacin eflcicntc del tiL'nrpo

30

Desarrollo y gestin de proyectos informticos Tabla 2.2. Comparacin det mtodo a destajo con el mtodo propuesto en este libro

\Itodo a destaio
Sus de f'ensores aducen rnc. joras increbles e instantirncas cn cl ticrrpo de clesarrollo.

\Itodo de este libro

SLrs def'cnsores aclucert rodestas rneJors lnstantneas. seguiclas por rre.Joras ntavores y a ms largo plazo.

Ncccsltu toca erpericncit tccnol(tgica aprtc. dc conocitr-lielrltts en cod i ficrc irin. Ricsgo alto: fl'ecucntentente f'alla. inclriso curnclo se ha hecho dc la

Nc-ccsita una experiencia tecnol-qica

acler-ns de

conocimient()s en

cod i fl cac i n.

fbrrla

Ries-qo ba.jo: pocas '".eces falla cuanclo sc aplica cle fbna ef'cctrva.

nrs ef-ectiva posible

Los denrhs ltos vcn cono <r-aclicales)); parecc qLie csturos en las r"rltinras. quc tuvirantcls toclo.
Se entple-an clentasiaclos recursos

Los derns nos vcn como consen'adores. aburridos e incluso f'eos. No parece que estamos trabajando duro.
Usr los recursos huranos de fbnna humana v eficiente.
E,s posiblc personalizar el mtodo para dar toda la visibilidad y el

huranos. Ofl'ecc poco avancc cn r.isibiliclacl o

control. Sc sabc cue sc ha

curndo se terrnina.

rcabado

control neccsarios.
Los elerentos clales del mtodo se
enrrlcan con xito desde hace nis de
I

Es un nttoclo tan viejo cor.no cl pro:rio sofiu.'arc.

5 aos.

Frcrtc: f nsllirad. eil .Rcnlrds of taiiirg thc path Lcss Tral.cleii>r (Dar.is. i99.1t.

corto que la nredia. Cuando falra. se debe a que la gcnte piercle ra determinacin dc seguir isando el nttoclo, no a que falle cl propio mtodo. Resuuriendo. el mtodo a desta jo asegura un sacrilicio extraorcirnario. per. no unos resultados cxtraordinarios. Si el objetivo es la mrima velocidad de desarrollo en vez de las rxi'as horas cle bullicio (actividacl), cualqr-rier persona razonablc apostar por cl desarrollo eficiente. Si leemos e'tre las l'eas de cste libro. encontramos toda la infbrmacin nccesa.ia pa'a llcr,ar con cl rnejor .xito posible un proyecto a destajo. ciertarrentc. una pcrsona podra transformar este ribro der cioctor Jekyll en el dc Nfr. H,dc a destajo. pero hay ntncho cje rn cn este tipo de desa_ rrollo. y no \ov a crplicar cmo usarlo.

disponible y la aplicacin de tcnicas de desarrollo orientadas a pranificacicin. Las horas ertras son habitrales en este tipo de desarrollo rpido. pcro no suele ser el misr.no montn de horas exrras que se usan en el m_ todo a destajo. No'.'alnrentc. el dcsarrollo cficie'te genera un plan ms

Captulo 2: Estrategia para el desarrollo

rpido

31

Ejemplo

2.2.

Desarrollo rpido con una estrategia clara

Miembro de la compaa a partir de Square-Calc 3.0, Sara estaba preparando el proyecto Square-Plan 2.0. Square-Plan era el paquete de gestin de proyectos de Square-Tech. Sara era el jefe tcnico. En la primera reunin de equipo, Sara present a los miembros del equipo y plante directanlente el asunto. <He recorrido toda la compaia recolectando los infonnes post-ntortem de los proyectos>, dljo. <Tengo una lista de un kilmetro de los enores que se han cometido en otros proyectos de la compaa. He puesto la lista en la sala de reuniones. y nre gustaria que avisarais si cometemos aiguno de ellos. Tal.nbin querra cue incluyeseis cualquier posible emor que conozcis o que encontris segn avanzarnos. Si no hay que hacerlo, no es cuestin de repetir la historia. Os he seleccionacio para este equipo porque cada uno de vosotros domina las bases del desarrollo. Sabis lo que significa hacer un buen trabajo de recopilacin de requisitos y diseo para que no perdamos tiempo en vueltas atrs innecesarias. Qr,riero que todos en este proyecto trabajls inteligentemente en vez de trabajar duro. El personal que trabaja demasiado duro comete dernasiados errores, y no tenemos ticrnpo para ello.
Tambin he incluido un plan de gestin de riesgos. El plan es agresivo, asi que no podemos pennitir que nos atrapen los riegos de los que estamos avisados. E,l mayor riesgo de la lista es que el plan puede ser inalcanzable. Quiero que rehagis el plan al final de la semana, y si no se puede cumpllr. haremos uno algo ms realista.> Todo el equipo asintiti. Para el personal que vena de provectos que se haban desarrollado a un ritmo endiablado, las palabras de Sara parecian como una bocanada de aire fresco. A1 final de esa semana, Sara se reuni con su jef'e. Eddie. <El equipo ha echado un buen vistazo al plan del proyecto, Eddie, y henros comprobado que slo tenemos un 5 por 100 de posibilidades para llegar a la fecha tope con las prestaciones actuales. Suponiendo que no ha,a cambios, 1, siempre hay algunas cosas que cambian.) <<Eso no es bueno), dijo Eddie, Eddie tena reputacin de entregar lo que prometa. <Quiero al menos el 50i50 de posibilidacles cle entregar el soflwarc a tiempo, y quiero que scalnos capaces de responder a los cambios en el mercado durante los prximos l2 meses. ,,Qu recon.riendas?> <An no est completamente especificado el producto, y tenemos alguna flexibilidad>, do Sara. <Pero creo que el conjunto de requisitos actual llevar de l0 a 30 meses. S que es un margen arnplio. pero es lo ms que puedo decir antes de saber ms sobre 1o que tenerros que construir. Tenemos que acabaren 12 meses, cierto? Considerando esto, creo que se debera incluir otro desarrollador y entonces fijar un plan de entregas evolutivas donde se planificar construir una versin comercializable del software cada dos meses, con la prinrera entrega a partir de los 8 meses.D
\.(onltlluu
)

32

Desarrollo y gestin de proyectos informticos

guna gente y te llamar.>

<Me parece bien>. dijo Eddie. <Aderns. crco que cn este proyecto la funcionalidad ciebe ser ms irr.rportante que er pran. Djame hablar con al-

cuando Eddie llarn a Sara, le dijo quc la compaa tenia la voluntad de forzar a cue el plan del software fuese de ll rneses para conseguir las prestaciones descadas. pero para nrayor segulidad deberia emplear el plan de cntregas evolutir,as. Sara se tranquiliz ' dijo que ella pensaba que ste era un objetivo ms realista. Durante las p'imeras semanas del proyecto, el equipo desarroll un prototipo de la interfaz de usuario detallada y con aspecto hollvwoodense. La <lista de errores> de r,ez en cuando indicaba que el esfuerzo en el prototipado pocla suponer una vida en s lnismo, as que se fij una ventana temporal rgida para cl trabajo en el prototipado que evitase construir un pfototipo excesivamente rreticuloso. El prototipo se utiliz para realizar entrevlstas con los posibles clientes acerca de las utilidades canclidatas, y el prototipo s* rcvis i arias r cces cn respuesta a las indicacioncs de rncjode los usuarios. Sara sigui manteniendo la lista de riesgos y determin que los tres ricsgos clat'es para el prorecto eran la baja calidatl, que podra provocar excesivas vueltas atrs y el alargamiento del plan, Ia agresiviclad del plan, , las prestaciones que aadiria la competencia desde ahora hasta la linalizacin del proyecto. Sara crea que el plan tle entregas evolutivas se haba aplicado por el riesgo de la calidad. Deberian entregar la primera versin clel software al grupo de control de calidad. eA, en el lmite de los g rneses. y QA podra ir ei.'olucionando los casos de prueba con el software. El equipo control el riesgo en el plan creando una lista de prestaci.nes priorizada. Deban desarrollar lo ms que pudiesen en l4 meses, pero llevando el producto a un estado comercializable cada dos meses. y debian asegurarse de tener algo que entregar cuando fuera el nromento. Tarbin tomaron decisiones de diseo para varias prestaciones que estaban especificamente indicadas para ahorrar tiempo de implementacin. El menor tiempo consunrido en las implementaciones no era una tfanlpa, pero era aceptable, y supuso una reduccin en el riesgo del plan. El equipo gestion el .iesgo de las prestaciones de los competidores de dos fb'nas. Emplearo' cinco rneses en desaroilar un diseo que incluyese un entorno capaz de sopoftar todas las prestaciones que haban prototipado v unas cuarltas rns que crean que deban incluirse en la versin 3.0. su diseo pretenda qr,re se pudiese adaptar a los cambios con poca dificultad. Tambin asignaron tiempo en el rnes l2 para revisar los productos de los competidores, revisar el prototipo e irnplementar las prestaciones necesarias para ser con-rpetitivos en los ltimos dos meses. En el sexto l1res, con el diseo cornpleto, el equipo fij un conjunto rJe hitos miniatura que indicaban el calnino a seguir pura otten.. la primera versin comercializable que pudiese ser probada en el octavo mes. La versin del octavo mes no haca rnuchas cosas, pero la calidad era buena, y
l

ll

(otlltiluuJ

Capitulo 2: Estrategia para el desarrollo rpido

33

suponia una buena base para cl trabajo siguiente. Pasado este punto, el equipo fij otro cclnjunto de hitos miniatura, que los llevaria hasta la ntarca del rnes 10. El equipo Lrtiliz la misma tcnica para el hito dei nres 12. En el mes I 2. 1, segn lo planeado. el equipo revis los productos de la competencia. Un cornpetidor haba acabado un buen producto en el mes 10. y contenia alguna utilidad que Square-Plan 2.0 tena que incluil para ser competitivo. El equipo incluy !'stas ltuevas prestaciones a su lista priorzada, reordenndola, y se jaron ntinihitos para los dos ltimos meses. En ese tiempo, Jos, uno de los desarrolladores con lrenos experiencia. descubri una organizacin r.rn poco nrcjor de los cuadros de dilogo del producto y llev el asunto a una reunin del personal. George. uno de los desarrolladores ms veteranos, respondi: <Tu idea es buena. Creo que deberiamos cambiarlo. pero ahora no podenos, Jos, Slo se neccsita un da para el carnbio. pero afectaria al plan de docurnentacin al nrenos en una sernanr. ,Qu os parece si lo ponernos en la lista de la versin 3.0'l> <No haba pensado en el efecto sobre el plan dc documentacin>, dijo .los. <Est bien. Lo pondr como una peticin de cambio para nrs tarde.>> A los 14 meses. el equipo acab la versin final del software. tal como se plane. La calidad de Square-Plan era cxcelente. puesto que se haba probado desde el octavo rnes. La seccin de doculentacin pudo centrar sus esfuerzts en el plototipo detallado de la interfaz de usuario. mientras esperaba que llegase el software. Los desarolladores no tuvieron tiempo de implententar varias de las prestaciones de ms baja prioridad, pero haban implernentado tocias las importantes. Square-Plan 2.0 fue un xito.

3 i bl

iografa adicional
No conozccr libros gencrales quc traten los terras del productcl o la tecnologa colno se han dcscrito cn este captulo. Este libro trata estos elementos cn ms profuncliclad c.n el Captulcl 14" <Control clcl conjuntt'r de prestacioncs>: el Captulo I 5. <Herrauricntas rara aumentar la productividad>. 1'en cl Captulo 31. <<Lcngua.jes para el clesarrollo r'pido>. Los trcs libros siguientes oll-ecen inlbnracin gencral sobrc enfbqucs basac'lcrs etr pcrsonal (pt'otlt,vurt.) para cl clesarrollo clel softu,arc. El prinlero es un clisico:
DcN1arco. Tonr. y Tintothy Lister: Paopletrura; Pt'tdut'tiye Pt'oit,r't.s trttd Tt,unts. 1.-eu York. Dorsct Housc. 1987. Constrntir.rc" Larry L.'. Constuitta rtt Peoplerut'a. E,rrglcri'oocl Clifl\.

N. .1.: Yourdon Press. 1995. Plauger. P. J.: Progt'untntittg ort

Purtost'll;

[:.s.su.t'.s

otr Sofiwure Pcotle.

Engloroocl Cllif s. N..1.: PTt{ Prcntice Hall. 1993.

34

Desarrollo y gestin de proyectos informttcos

Los siguientcs libros ofl'ccen info'racin sobre los procesos del softu'arc. cl prin.rero a nivel orsanizacional. el scgundo a nivel del equipo y el tcrccrcl a nivel inclividiral.
N{el lon Un i vcrsity/Sofl."vare Engineering Institute: T he c apub i lit.t' il,'uturit.t' ,\loclel; Guitlelines fbr. inrtr.oying the .sofiwctre prot'ess. Rcading. Mass.: Addison-Wesley. 1995. Este libro es un resumen de los rltimos trabajos para mc-jorar el proceso de softwarc realizados por cl Soltu.'arc Ensincering Institute. Describe el ntodclo complcto de ntaclurcz cle procesc'rs cn cinco nir,cles, los beneficios que se obticnen con cada nir'cl v los mtodos quc caractcrizan cada uno de ellos. Tanibin it.rcluvc ejenrlos dctallados de una entprcsa que ha consegLrido los ntayorcs nivcles cic madur.sz. calidacl 1, productividad. Ma-euirc, Stcr.c: D,gging the Development Proc'e,ss. Rcdrlond, Wash.: Microsof Pless. 199.1. hl libro dc Nlaguire presenta ur.r conjunto de mximas tradicionalcs qr-re pr.reden utilizar los rcsponsables dc los proycctos para hacel quc sus cquipos sean productilos. y da un vistazo intcresante de las intcrioridrdes dc algunos proyectos de Microsoft. FIur-riplrrcy, Watts S.: A Dist'ipline ./br So.ftu.are Engineering. Reading, Mass.: Adclison-\\'esley" 1995. I{umphrey define su propio proceso de sofirvare. que trtrtderlos adoptar a nil'el individual, independienternente de que nucstra entpresa sopofte la ntejora del proccso.

carnegie

Errores clsicos

Contenido

3.l.

E.jcmplo de errores clsicos

de ulr dcsarrollo

3.2. E,fecto dc los crrores en la pro-tr.antaciitn 3.3. Relacin de errores clitsicos 3.4. La fuga de Lu islu de Gilligun
Temas relacionados
Gestin de riesgos: Captulo 5 Estrategia para el desarrollo rpido: Captr-rlo 2

F]S UNA ACTIVIDAD COMPLICADA. Un proyecto softu'arc tpico puedc presentaf r.ns oportunidades para aprender cle los errorcs que las planteadas a algr-rnas pcrsonas durante toda su r''ida. Este captulo exantina algunos dc los crrores clsicos que sc conteten cuando se intenta ciesarrollal sofir,t,are rniclatnente.

EL DI]SARROLLO DE SOFTWARE

Ejemplo de errores clsicos

El sigLricnte c'jeniplo es un poco corro lcls pasaticmpos clc los nios. cn los que intentamos encoutraf toclos los objetos cu1,o nourbre conrienza
con la letra <M>. ,Cuntos errores clsicos pucclc cncontrar en cI sigLricnte e.1e-rrrplo'.)
35

36

Desarrollo y gestin de proyectos informticos

Ejemplo

3.1. Errores clsicos

Mike. un responsable tcnico de Giga Safe, estaba conriendo en sn ol'icina y n.rirando por la Ientana una brillante lnaana de abril. <Felicidadesl Mike. ya rienes los fondos para el programa Giga_ Quotel> Era Bill. el jefe de Mike en Giga, una cornpaa de seguros mdicos. <Al cornit ejccutivo le ha gustado la idea de autornatizar nuestras cuotas de seguro mdico. Y tambin la idca de volcar cada noche las cuotas del cla en la oflcinr principal para que siempre tengamos al da los ltimos valoes de ventas. Ahora tengo una reunin. pero podemos discutir
los detalles ms adelante. Br-ren trabajo!> Mike escribi la propuesta para el programa Giga-euote meses anres, pcro estaba pensada conto u11 programa para un solo pC. sin ninguna capa_ cidad de cornunicacin con la oflcina principal. perfecto. sta era la oportunidad de cii.igir Lrn proyecto cliente-servidor en Lln moderno entorno GUI (inferiaces grlicas de usuario).1o que sienrprc haba querido hacer. El proyecto le llevara al lnenos un ao. y lo ocupara a tiempo completo. Mike descolg el telfbno y marc el nmero de su esposa. <Cario, esta noche cenaremos fuela para celebrarlo...rr A la maana siguiente. Mike qued con Bill para discutirel proyecto. <Vamos a ver. Bill. ,Qu pasa? Esto no se parece a la propuesta en la que
he trabajado.>r Biil se sinti inseguro. Mike no haba participado en las revisiones de la propuesta, pero no hubo tierrrpo de avisarle. CLlando el comit e.jecutivo

estudi c-l programa Giga-Quote^ tontaron los mandos. <Al con-rit ejecutivo le gust la idea de construir software para automatizar las cuotas de seguros mdicos. Pero querian que se pudieran transferir automticamente las cuotas locales al cornputador central. Y qucran tener hecho el sisterna antes de que se hagan efectivas Ias nuevas cuotas el I de enero. Adelantaron la fecha de finalizacitin del software que propusiste del I de marzo al I de noviembre, con lo que se acort el plan propuesto en 6 meses.> Mike haba estinrado que el trabajo ller,.ara l2 meses. No crey que tuviese la suerte de acabar en seis meses, y as se 1o dijo a Bill. <Varnos a r''er si me he enterado>. diio Mike. <Parece que ests dicindome que el comit aadi requisitos de comunicaciones a gran escala y ha acortado el plan de 12 a 6 rreses.> Bill se encogi de hombros. <S que ser un reto. pero t eres creati\.o y creo que puecles con todo. Han aprobado el presupuesto que queras, y aadir el enlace de comunicaciones no debe ser difcil. Pediste 36 personas-mcs y las tienes. Puedes reclutar a quien quiera que necesites para el proyecto e incrementar el tamao del equipo.> Bill le dijo que hablase con algn otro desarrollador y que buscasen la forma de entregar el software a tiernpo. Mike se reuni con Carl. otro responsable tcnico, y buscaron la fornta de rcortar el plan. <,;Por qu no usas C+* v diseo orientado a objetos?>,
\( otlttnIt(t
)

Captulo 3: Errores

clsicos

37

crrlent Carl. <Sers ms productivo que con C, y el plan se acor.tar en uno o dos meses.) A Mike le pareci bien. Carl tambin conocia una hel'r'arienta de elaboraciirn de infbm-res que supuestamente acortaba el tiempo de desarrollo a la mitad. El proyecto tenia bastantes infornres, y por tanto esos dos car-ltbios los llevaran hasta los 9 rneses. Consiguieron hard\\are nuevo y ms rpido. y esto les ahorraba un par de setnanas. Si realrnente poda recluta a desarrolladores dc primerisima categolia. podra bajar a 7 r.neses. Esto era suflcientenrente ajustado. Mike coment sus progresos
a Bill.
<<\,1ira>. dijo Bill, <dejarel plan cn 7 mescs est bien, pero no es suficiente. El conrit dej claro que el plazo de entrega eran seis meses. No me clieron opcin. Puedo daros el hardr,vare que necesitis, pero t y tu equipo tenis que encontrar una fornta de redr.rcir el plan a seis meses, o tendrrs que hacer algr.rnas horas extra para paliar la diferenciar. Mike se plante el hecho de que su estimacin inicial slo fue una aploxirnacin y pens que quizs podra bajar.la a meses. <De acuerclo, Bill, buscar un par de personas externas espabiladas para el proyecto. euizs puedn cnctrntrJr geltte eon expericncia cn comunicaciones para que nos ay*udc en la descarga de datos desde el PC al rainfranre.> EI I de nrayo. Mike haba formado el equipo. Jill. Sue y Tomas eran buenos desarrolladores de la casa. y fueron liberados. Complet el equipo con Keiko y Clhip, dos contratados extentos. Keiko tenia experiencia tanto en PC como en los rrainfiale con los que tena que conectarse. Jill y Tomas habian entrevistado a Chip y no querian contratarlo, pero Mike lo impuso. Tena expericncia en conrunicaciones y estatra disponible, as que Mike lo contrat. En la primera reunin de I equipit. Bill dijo que el programa Ciga-Quote era estratgicarnenfe irnportantc para Giga Safe Corporation. Algunos de los rnagnates de la cornpaa estaran pendientes de ellos. Si tenan xito seran recornpensados. Dijo que estaba seguro de que lo conseguiran. Despus de los nimos infundidos porel discurso de Bill, Mike se sent con el equipo y mostr el plan. El comit ejecutivo les haba proporcionado una especificacin aprorimada, y emplearon las siguientes dos semanas en completar las lagunas, Despus se emplearian 6 semanas en e I diseo, lo que dejaba 4 meses para la construccin y la prueba. Su estimacin aproxirnada fue que el producto flnal tendra unas 30.000 lneas en C++. Todos los asistentes asintieron, dando su confbnnidad. Era arlbicioso, per-o lo sabian cuando se comprometieon con el proyecto. A la semana siguiente, Mike se reuni con Stacy, la responsable de la prueba. Indic que debera tener pares del producto tcrminadas para probarlas no despus del I de septiembre. con el propsito de tener un producto con todas las funciones el i de octubre. Mike estaba de acuerdo. El equipo acab la especificacin de los requerirnientos rpidarnente. y se meti en el diseo. Obtuvieron un diseo que pareca hacer buen uso de las prestaciones de C++. (totttittt)

38

Desarrollo y gestion de proyectos inforrnaticos

balsa de accite. Ni a.lill ni a Tornas les gllsraba Chip. Sue se qucjaba <ie 1. que no queria que nadie se,ce'case a su cdigo. Mikc atribuy los choques de personaliclacles a las muchas lroras cle tr.abajo. No obstante, a primeros de gosto" le indicaron quc cstaba hccho entre el g,5 v el 90 oor 100. A rnitad de agost., el departa'renro actuarial dio las tsas paia el ao siguiente, el equipo descubriri que teria que rnodificar completamente la estnlctura pal'a las nueYas tasas. El nuer.o nrtodo dc tasacin necesitaba realizal preguntas sobre hbitos de ejercicio, en ia bebida, en la comida, actividades cle ocio y otros factores que no se haban incluido antes en las frmulas de tasacin. Pensaron que c*r deba prote*erlos de los efectos cle esos carnbios. c'alcularon que slo tendrian que incluir nuevos valores en las tablas de tasas. Pero tendran que cambiar el diiilogo cle entrada, el diseer clc la base de datos" el acccso a la base de clatos los objetos de -v colrunicaciones para adaptarlos a la nuer.'a estmctura. como el equipo estaba revuelto lorrlue tena que reajustar sr-r cliseo. Mike dijo a Stacy que se rctrasaran unos tlias en la cntrcga de la primera \,ersin para la prueba. El equipo no hbia te'lrinado er I de septienbre. y Mike asegur a Stacv que acabaran cn slo uno o dos das. Los dias sc semanas. El lmite del I de octubre para entregar 'ol'icron el producto cornpleto llara sir prucba lleg y fire rebasado. Desarrollo aun no haba acabado e-l primer pr-oducto para prueba. Stac, llanr a Bill a una l'cunin para tratar el plan. <An no tcnemos nada cle desarrollo;r, dijo, <rsuponianros clue tcrrdrarros la prinrera versin el I cie septiembre, y puesto que ahn no tenelll0s nada. por lo menos nos relrasaremos un r-nes respecto al plan oiginal. Creo cue tcnelxos Lrn problemar>. <Es crerto, tenemos r"rn probrema>>. dijo Biil. <Djarne que hable con el equipo. He prorneticlo a 600 agentes qLre tendrauros el progralra el l de noi.iellbre . l-o entregarerros a tierrrpo para cl canlbio de asa.s.> Bll cottt'oc una re,nin con el equito. <<sfe es utt equpo l-antstict, l'debera currplir cor s,s co*promisos>, res dijcl. <N. s qu es lo que ha ido r.nal, pero espcro qre todos traba.iis duro y entregurs el softwae a trempo. Airr.r podeis conseguir las bonificaciones, pero ahora tendris que I,char por ellas. Desde ahora .s asignar horario de 6 das por r",.,.,unu. l0 horas al dia. hasta q'e cl sottlvare est'n hecho.> Dcspus <ie la reunin, Jill r" Tomas se quejaron a Mike de q,e l.raba necesidacl de que los 'o trataser.I como nios. pero accedieron a trabajar las horas que Bill quera.

Acabaro'el diseo cl l-i cle.iunio. adclant'close al pltrn. y col.rlenzaron a cociilicar como locos para llcgar al objetivo r1e tener la prirnera versin de p^reba el I de septieurbre. E,l trabajo cn el pr.oyectn no .r, uno

prueba antes c1e que entrasen en vigor las nuevas tasas en enero. EI ccluip. cntrcgti su p.imera al grupo de prucbas cuatro semanas despus del I de no'iembre. y'ersin se rer:ni para tratar algunas de las reas problenrticas que qr-reclaban.
|( ()ilI

El equipo rctra-c el plan dos semanas, prorretiendo te.er la utilidad completa construida el I 5 de novieurbre. Esto dejaba 6 senranas para la

tl |tLt

Captulo 3: Errores clsicos

39

con Llnl barrea. <La pgina resuluen de cuotas incl-ve grtico de barras. He utilizaclo un gene raclor cle infbnles que srttrron:r generaba grficos cle barras. pero [a nica forr.lta de gencrarlos cs en pginas individuales. Uno de los requeriurientos del grupo de velltas es que hav que pnner grficos cle brrras y texto en la lnisnra pgina. He- pensaclo que puedo tranlpeal un intbrr.ne con un griifico tlc barras pasando e I texto dcl inforrne conlo una leyenda clel objeto grfico cie bal'ras. Realnrente es trlln tranrps. pero siernp|e puedo volVer atrs v reimpletrentarlo ms clarat-nente despLrs de la plirttclr r crsi,itl.', Mike respondi: <No I'eo cltinde est c-l problema. Tenemos que acabaf el producto. v no hav tienrpo de hacer un cirdigo perl'ecto. Bill ha dejado Lricn claro que no podcnlos tencl nls fallos. Usa esc truco.)) Chip conrent quc stt cdigo dc comunicaciolres estaba hecho al 95 pol i00 y cLre t-unciortaba. pet'o que airtl tenia que hacer algunas prrtebas de ejc'cr-rcin. N'like r.'io que Jill y Tomas sc mirallan. pero decidi ignorarlo.

Tor.nas estaba traba.jando en la gcneraciirn de infornres

)'

se encontr

El equipo traba-i duro

ches del 14 y

el l5

cle

hastr el l5 de novielnbre- incluyenclo las nonovicntbre. pcro no pudiclon lraccr quc [a feclia de

entrega lue se el 15 de noviembre. El e quipo estaba exhausto' pero la maana rlel clieciseisayo dia. fue Bill quien se sinti deprinrido. Stacy le haba avisado de quc desarrollo n9 habia entregado la versin coniplela el dia anterior. La irltima senrana halra dicho al cornit ejecutil'o que el provecto estaba encarrilaclo. OtIa gestol'a cle provectos. Claire. haba investigado en los ptogresos del equipo. dicicndo qtlc habia oilo que no estabarl cul'nplienclo la-s entregas pianiticadas con el equipo de prueba. Bill pens que Claire estaba tensa y n0 le gustaba su info|me. Le haba asegulado a ella quc su cquipo estlba eu bucn carnino para cunrplir las entlegas llaneadas. Bill cli.io a lVlike qtte reuniese al equipo. v cuarldo lo hizo. llit'ccan derrotados. Un ures v nteclio a 60 hors semallales haban sido la punt:illa. Mike pregunt cunto ticnrpo lcs llevara rcabar" pero su tnica respuesta lue el silencio. <i,Qu nrc estis ciiciendo?>. dijo. <t{oy ibanros a fener lista la versirin con todas las funcioltes. (.La tellemos'l)) <Mira. lr'{ike>. dijo Toras. (llLredo entregar hot n.ri cdigo y decir que incluve "tcda la funcionalidacl''. pel'o plobablemente rlece sitar' tfes semanas cle traba.fo cle lirnpieza urt vez que lo etltregtre>. Mike pregunt qu qucr'a decil Tot.nas con <limpieza. <rNo hc puesto el logotiptl de la empresa en cada prgina. ni clue el lronrbt'e y el tellbno del agente aparezca al pie de la pgina. Son pequerias cosas como sa. Todo lo importante funciona bien. He acabado al 99 por 100.> <Yo tamtoco hc hecho exactatnente el 100 por 100>. admjti .lill. (Mi antiguo grullo me ha llamado para que les diese apoyo tcnico' y he tenido quc emplear un plr de holas ciiat'ias con cllos. Adems, haba olvidado hasta ahor.a rnismo que los agelites redan poner su nombre y su telfbno en los infirrrnes. An no he iurplementado los dilo-eos de entradaparaesos
\(onttilrrLt)

40

Desarrollo y gestn de proyectos tnformticos

datos. y tambin ten-qo que hacer alg'nos dilogos de mantenimiento. No crea que fuesen necesarios para el hito de la ,.utilidacl completa'..i>

Ahora Mike talnbien empezaba a sentirse mal. <Si he odo lo que creo que hc oido, mc estiis diciendo que neccsitis tres selnanas para completar el sofhvare. ,,Es correcto?> <<Al men,s tres semanls)r. dijo Jill. Elresto de los desarrolradores estude acue'do. Mike pas uno por uno y lcs pregunt si podran conrpletar 'o pafie en tres seianas. su uno por uno. cada programador le dijo que trabaduro, y que pensaba que poda hacerlo. .jara Al final dc ese da. despus cle una discusin larga e inc(rnroda, Mike y Bill acordaron retrasar c'1 plan 3 semanas, hasta el 5 tle diciembre, sienrpre que el equipo prometiera t.abajar 12 horas al da en vez cle 10. Bill clijo que tenia que demostrar a su jefe quc estaba azuzando al equipo de desarrolro. La revisin del plan implicaba que rendfan que probar el c<ligo y prepa_ rar al personal al urisnro tiempo, pero era la rnica posibilidacl de entr-egar el cdigo el I de enero. Sracy se que.i de que cl control de calidad del softrvare no tenia asignado el tienrpo suficiente para probarlo, pero Bill no le hizo caso.

El 5 dc diciernbre el equipo Giga-euote cntreg el progrania

Qr-rote

Giga_

completo al grupo de pruebas antes del rneclioda. v salieron pronto del trabajo para tener su largamente esperado descanso. Habar.r trabajaclo
casr constantcmente dcsde cl I de septiembfe. Dos das ms tarde, Stacy dio la prirnera lista de errores, se desat el 1, infierno. En dos das el grupo de pruebas iclentific ms cre 200 def'ectos en

el programa Giga-Quote, incluyendo 23 clasificados conro de sevcridad l (<Tienen que corregirse>). <Ner veo la fbrma de que el soitr.r,are est listo para entregarlo a los agentes locales antes del 1 de enero>, clijo. <probablemente el grupo de pruebas necesite ese tiempo para escribir los casos de
prueba de los defectos qlle ya ha descubielto. y est descubriendo def-ectos cada hora.> Mike con'oc urra reunin de personal a las I en punto de la rnaana siguiente. Los desarrolladores estaban quisquillosos. Decan que haba unos cuantos errores serios. pero la rnayoria de los errores indicados no eran realnlente errores, sino lnalas interpretaciones de cmo se supona quc tena que funcionar el progranla. Tomas indic que el error # 143 era un ejemplo de eso. <El inlbrme del error #143 dice que en la pgina resurnen de la cuota, el grfico de barras ticne que estar elr la clerecha de la pgina en vez de en la izquierda. Esto no es Lln error de severidarl L Es la tpica lornra en que los comprobadores sobreestiman un problema.> Mike distribuy copias de los informes de errores. Encarg a los desarrolladores que revisasen los errores que el grupo de pruebas les haba asignado y estimasen cunto tiempo les llevara corregir cacla u'o de ellos. Cuandcl el equipo se reuni de nuevo por la tarde. las noticias no eran buenas. <Siendo realista. estimo que necesito dos senranas completas cle trabajo para corregir los errores que ya nos han pasado>, dijo SLre. <Adems.

Captulo 3: Errores

clsicos

41

tengo que acabar las comprobaciones de integridad referencial de la base de datos. En total, necesito cuatro semanas a partir de hoy.> Tomas habia devuelto el error #143 a los comprobadores, cambiando su severidad de I a 3 (<Cambro esttico>). El grupo de pruebas respondi que los informes fesumen de Giga-Quote tenan que coincidir con informes similares generados por el programa instalado en el mainfrane para polticas de renovacin, que era similar a los formatos de marketing preimpresos que la compaa haba usado durante muchos aos. Los 600 agentes de la compaa estaban acostumbrados a ver sus valores de ventas en grficos de barras a la derecha, y tenan que quedarse a la derecha. El error se qued con un nivel 1, y supuso un problema. <Recuerdas ia trampa que utilic para que se pudiesen imprimir en la misma pgina el grfico de barras y el informe'?>, pregunt Tomas. <Para poner el grfico a la derecha, tengo que reescribir ese informe eoncreto desde el principio, lo que significa que tengo que escribir mi propio cdigo a bajo nivel para dar formato al informe y al grfico.> Mike tembl, y pidi una estin,acin aproximada de cunto tiempo necesitaba. Tomas dijo que por lo menos 10 das, pero que tendra que verlo ms despacio antes de estar seguro. Antes de volver a casa, Mike dijo a Stacy y Bill que el equipo trabajara incluso ios dias de fiesta y que todos los errores encontrados se corregiran para el 7 de enero. Bill dijo que se lo esperaba y que habia aproLrado un retraso en el plan de 4 semanas antes de irse a un cfucero de un mes por ei Caribe que tenia planeado desde el pasado verano. El mes siguiente Mike estuvo ocupado manteniendo al grupo unido. Durante cuatro meses haban trabajado todo lo duro que se poda trabajar, y no crea que pudiesen hacer ms. Estaban en la oficina 12 horas al da, pero empleaban rnucho tiempo leyendo revistas, pagando facturas y hablando por telfono. Pareca que se irritaban siempre que les preguntaba cunto les quedaba para reducir la cuenta de errores. Por cada error que se corregia, el grupo de prucbas descubra dos nuevos. Errores cuya correccin deba haber llevado 2 minutos tenan implicaciones en el proyecto completo y podan llevar dias. Pronto calcularon que no haba forma de que pudieran corregir todos los defectos para el 7 de enero. El 7 de enero Bill volvi de sus vacaciones, y Mike le dijo que el equrpo de desarrollo an necesitaba 4 semanas ms. <Esto es serio>, do Bill, (tengo 600 agentes locales que estn hartos de dar vueltas alrededor de un puado de aprendices de informticos. El comit ejecutivo est hablando de cancelar el proyecto. Tienes que encontrar una forma de entregar el software en las prximas dos semanas. sea como sea)). Mike convoc una reunin del equipo para estudiar sus opciones. Les comunic el uitimtum de Bill y les pidi una estimacin aproximada de cundo entregaran el producto, primero en semanas, luego en meses. El equipo se call. Ninguno se arriesgaba acerca de cundo podran entregar finalmente el producto. Mike no sabia qu decirle a Bill.
\( ollIIItLtu
I

42

Desarrollo y gestin de proyectos informticos

equipo centrase sus esfuerzos en un puado de mduros propensos a errores, que se iniciasen inmediatamente revisiones del diseo y la codificacin para corregir todos los errores y que el equipo .otrr.nrur. trabajando horas fijas. para que se pudiesen hacer mtricas precisas del esfuerzo empleado en el proyecto y cunto se necesitara para terminarlo. Tres semanas ms tarde. en la primera ,.tnrnu de marzo, la lista de effofes pendientes baj un poco por primera vez. La moral del equipo subi un poco, y basndose en los progresos regulares que se iban haciendo, el asesor estim que el soitware podra entregarse, completamente probado y fiable, el 15 de mayo. Puesto que el incremento semestral de la tasa de Giga Safe tendra efecto a parlir de I ile julio, claire j ra fecha oficial de lanzamienro el I de junio.

tad de febrero. finalmente Claire decidi que ya habia odo suficiente y mand un (stop) al programa Giga-euote. Se reuni con Mike el viernes. (Este proyecto est fuera de control>, dijo. <Desde hace meses. Biil no me ha dado una estimacin fiabre. Es un proyecto de 6 meses, y ya lleva ms de 3 meses de retraso sin un final claro. Estis trabaiando tantas horas oue no hacis progresos. Quiero que descansis todos utr tin o. se*anu; qriro que desarrolles un informe detallado. paso a paso. que incluya roOo. y Oigo todo, lo que queda por hacer del proyecto. No quiero que foicis el pioyec_ to para encajarlo en un plan artificial. Si se necesitan otros 9 meses quiero saberlo. Quiero el informe del trabajo pendienre para el lnircoles. o tene que ser bonito, pero tiene que estar completo.> El equipo de desarrorlo se aregr de tener un fin de semana ribre, y durante la semana siguiente atacaron el informe detallado con enersas renovadas. Estuvo en la mesa de claire para el mircoles. Revis el i-nforme con charles, un asesor en ingenieria del software que tambin haba revisado las estadsticas de errores del proyecto. charles recomend que el

Tras la reunin, Chip drjo a Mike que haba aceptado un contrato de otra compaa y que empezaba el 3 de febrero. Mike comenz a sentir que sera un alivio que se cancelara el proyecto. Mike busc a Kip, el programador que haba sido responsable del aparta_ do de comunicaciones entre er pc y er mainfiame, reasignado de apoyo al proyecto. y 1o dedic a corregir los errores en el cdigo de comr,nicu"iones del PC. Despus de luchar una semana con el cdigJde Chip, Kip conclu_ y que tena algunos defectos conceptuales profundos que haran que nunca funcionara correctamente. Kip se vio obligado a redisear y reimpmentar la parte PC del enlace de comunicaciones entre el pC y el mainfiame. Puesto q'e Bill se sali por la tangente en ra r.unin ejecutiva de mi-

Eplogo
EI programa Giga Quote se entreg a los agentes locales de acuerdo con el plan e[ I de junio. Los agentes locales de Giga Safe ro acogieron con entusiasmo y algo de escepticismo.
((()nltnuu)

Captulo 3: Errores clsicos

43

La corporacin Giga Safe mostr su aprecio al trabajo duro realizado por el equipo de desarollo dando a cada desarrollador una bonificacin de 250 dlares. Unas cuantas semaas ms tarde, Tomas pidi una larga traja, ir Jill se fue a trabajar a otra compaa. El producto final Giga-Quote se entreg en 13 meses en vez de en 6, pasndose del lmite ms de un i00 por 100. El esfuerzo de desarrollo, incluyendo las horas extras, fue de 98 personas-mes, lo que supuso ua exceso del 170 por 100 respecto a las 36 personas-mes planificadas. El producto final tena en torno a 40.000 lneas de cdigo C** no vacias y sin comentarios, superior en ms de un 33 por 100 a las estimaciones aproximadas de Mike. Puesto que fue un producto distribuido en ms de 600 puestos internos. Giga-Quote es un hibrido entre un producto de gestin y un producto <prt--porter>. Un producto de este tamao y este tipo normalmente se debera haber acabado en 1 I meses y medio con un esfuerzo de 71 personas-mes. El proyecto sobrepas ambas cantidades.

2,

Efectos de los errores en la programacin de un desarrollo

Michael Jackson (el cantante, no el infbmtico) cantaba que <Onc bad applc don't spoil the wholc bunch. baby> (una manzana podrida no estropca cl barril completo, pequea). Esto puede ser cierto para las manzanas. pefo no lo es para el software. Una manzana podrida puede estropear el proyecto completo. Un grupo de invcstigadores dc ITT revis 44 proyectos de 9 pases para examirrar el impacto de l3 factores de productividad en la productiviciad (Vosburgh et ct1.,1984). Los f-actores incluan el uso de tcnicas de programacin modernas. diflcultad del cdigo, requisitos de eficiencia, nivel de participacin del cliente en la especificacin de los requerinrientos, experiencia personal y alguno nts. Asignaron a cada factor distintas categorias quc csperaban asociar con una cficiencia baja, media o alta. Por ejemplo, asignaron al factor <uso de tcnicas ntodernas de prograntacin> r'alores dc bajo uso, uso medio o alto. La Figura 3.1 de la pgina siguiente muestra lo que descubrieron los investigadorcs acerca del f'actor <uso de tcnicas moclernas de progranacin>. Cuanto ms estudiamos la Figura 3.1, ms interesante resulta. Muestra un patrn general que es representativo de los descubrimientos de cada uno dc los factores de productil'idad estudiados. Los investigadores de ITT vieron que los proyectos de las categoras que tuvierall poca productil'idad rcalmente tenan una productividad pobre, como muestra la estrecha franja de la categora Baja en la Figura 3.1. Pero la productividad cn

44

Desarrollo y gestin de proyectos informticos

REFERENCIA CRUZADA Para un anlisis rns detallado
.lo acta

Uso de tcnicas modernas de programacin (pocentaje del sistema total) Porcentaje de la planificacin nomrnal

concreto. consulte la Seccin 4.2, "Bases tcnicas".

^ri{i.^

Bala Media (0-25%) (26 75%)

Alta (76-100%)

+200
Leyenoa

+1

00

0 (media)

I
-1 00

,,.. I L?i,',0"'ru..
ISIS?,0",

ll\,4nimo

Figura 3.1. Estudio sobre el factor *Uso de tcnicas modernas de programac1" (Vosburgh et al., 1984). Hacer algunas cosas ben no garantza el desarrollo rpido. Tambin tenemos que evtar hacer mal cualquer cosa.
catcgorias dc alto rendimiento variaba mucho, segn muestra la franja
ancha dc la categora Alta en la figura. La productividad de los proyectos dc Ia catcgora Alta r,'ariaba desde pobre a ercelente. No es sorprendente que proyectos que se espera que tengan una productividad pobre la tengan realmente. Pero s debiera ser una sorpresa el dcscubrimiento de quc muchos proyectos que se esperaba quc tuviesen una productividad excelente tienen una productividad pobre. Lo que este grfico y otros como ste muestran a lo largo de todo el libro es que aunquc es necesario utilizar alguno de los mtodos recomendables, no es suficiente para obtener la ntxima velocidad de desarrollo. Incluso si se hacen

BEFERENCIA CRUZADA Para ms informacin acerca del papel que luegan los errores en el desarrollo rpido. vase la Seccin 2.1, .Estrategia general para el desarroilo rPido'

algunas cosas bien, como la utilizacin de tcnicas de programacin

modernas. an poder.nos cometer un error que anule las mejoras en la pro-

ductividad.

Al pensar cn el desarrollo rpido, resulta tentador pensar que todo lo que hay que haccr es identificar las causas iniciales de un desarrollo lento y eliminarlas. y despus obtendremos un desarrollo rpido. El problema es que no hay slo unas pocas causas del desarrollo lcnto. y que al final no es muy rtil intentar identificar todos los orgenes del desarrollo lento. Es corno preguntarse: ,cul es la causa principal de que no sea capaz de correr una milla en cuatro minutos'l Bueno, soy demasiado viejo. Peso mucho. No estoy cn forma. No me atrevo a intentarlo. No tengo un buen entrenador o capacidades atlticas. No podra ir tan deprisa aunque fuese ms joven. La lista crece y crece.
Cuando hablamos dc proezas excepcionales, las razones de que la gente

no las alcancc son simplenente demasiado numerosas conto para contar-

Captulo 3: Errores clsicos

45

las. El equipo de Giga-Quote del Ejemplo 3.1 cometi muchos de los errores que han plagado el desarrollo de software desde los tiempos ms remotos de la informtica. El camino dcl desarrollo de software est lleno de baches. y los baches en que caigamos determinan la rapidez o la lentitud

con que desarrollamos el software.

En el software! una manzana podrida puede estropear todo el barril, pequea. Para caer en el desarrollo lento, todo lo que hay que hacer es colneter realmente un gran error; para conseguir el desarrollo rpido tellen'los que evltar cometer algtin gran error. La siguiente seccin enumera
1os grandes errores ms habituales.

Relacin de errores clsicos

-{l-eunas tcnicas de desarrollo inefectivas han sido elegidas con tanta fiecuencia, por tanta gente, con resultados tan malos y predecibles que son dignas de ser llamadas (errores clsicos>. Muchos de los errores tienen una apariencia seductora. ,,Necesitamos salvar un proyecto retrasado? Metamos a ms gente! ,Tenemos que reducir el plan? planifiquemos de forma ms agresiva! ,Alguno de los miembros clave in-

Figura 3.2. El proyecto software estaba repleto de errores, y todos tos directivos de mayor categora y los responsables tcnicos juntos no lo pueden salvar a ningn precio.

46

Desarrollo y gestn de proyecfos informticos

al rcsto dcl cciuipo'.) Lrspcrarentos hasta quc rcabc el proyccto para dcspcdirlol ,,Hav clue accleral'cl proyccto para acabar'/ C'ogerentcls
comodl

cuantos dcsarrollaclorcs estn i,a drsponiblcs.

posible
!

y que colnicnccu lo antes

Los dcsarrollaclorcs. ilirectir os y clicntcs rrormalnrentc ticncr.l buenas lrs clecisiones qLrc tonralr. y la aparicncia scductora dc los crrores clsicos cs unl dc las razones dc que esos crrorcs sc colretan tan a r.l'lcl.luclo. Pero clcbrdo a qLre sc han conrcticlo n.luchas \cccs. sus consccucncias sc han he'cho lciles dc predccir. Y los crrorcs clirsicos rara vcz produccn los lesultaclos quc la gcnte espcfa. F,sta scccirt elrulrrcra allccledol clc dos clocenas de errorcs clsicos. Pcrsottalr.ltcntc he risto colncter cacla uncl clc esos crrorcs al menos una vcz. y )-o misrxo hc contetido bastrntes. \fuchos dc cllos aparecen en cl Llcmplo i.l. El colrur denorrrinador de csos en'orcs cs clue el desarrollo r'pid,r no sc erlnsi!trc llee csll'iltnlcnte si sc er ilan. l)ct'() s no sc cr itall. segLrfo quc sc consiguc el dcsarrollo lento. Si alguno de estos errorcs nos resulta funriliar. hay clue ulutarse. muchos otros lOs han colTrcticlo antes. Una l,ez que comprendamos sr-rs cfectos en la velociclacl clc clesarrollo. roclrer.nos utilizar esta lista para ayuclarnos en la planificacin dc nuestro provccto r,'elt la -ucstiu de
razoncs pafa tomar nesgos.

Algunos tlc l,rs cl'rrrrcs nllis sirnilicrrtiros ticncn strs propias \ce ioncs cn otras partes dc este libro. otros no sc tratarn nrrs. Para f'acrlitar la consulta. la lista sc ha dirrclido emplcanclo las clinlensioncs de la r,elociclad de desarrollo: persoitas. proceso. ploducto y tecnologa.

Personas
A cclntinuacitin alarccen algunos dc los errores clisicos relrcionados con
las pelsonas.
FEFERENCIA CRUZADA Para ms informacin sobre los buenos y malos usos de la motivacin, consulte el Captulo 11,
.,
l\,4

1 : Motivacin dbil. Estudio tras estudio sc ha rnostrado qr.rc la nrotir rcicin probablelrente ticne r.uavor efecto sobre la procluctir idacl y la calidacl

otivacin "

que ningn otro fhctor (Boehm. l98l). En el Ejemplo 3.l.los directivos tomaron a lo largo de lodo el proyccto mediclas qr.rc nrinaban la r.uoral: conro dar nirnos a diario al principio para peiiir horas extras en la rrritad. y como irsc de'n'acaciones ntientras el equipo estaba trabajanclo incluso los das de fiesta. para dar rccontpensas al final del proyccto que resnltaron ser de nrenos de un cllal por cada hora extra.

2: Personal mediocre.

Despus dc la rnotivacin" la capacidacl indir,iclLral cle los micr.ubros clcl eciuipo. as cor"no sus relaciones como ccluipo. probablerrentc tienen la nrayor inf-luencia en la productividad (Boehm^ l9ltl: Lakhanpal. 19c)3). Contratar apurando el fbndo clel barril

Captulo 3: Errores clsicos

47

dctcrntina

:ullondr unA aurcnaza al esfuerzo dcl clcsarrollo rpiclo. En el ejemplo, la :e'li-'ccin dcl pcrsonal se hizo buscando quin podra contratarse ms ri.rcio" erl vez cle quin rcalizara la mavora dcl trabajo durante la vida del jrro)ec1o. Esta tcnica consi-gue rrn inicio rpido dcl proyecto. pero no
Lrn

llnal rpido.

rl trarar con .'5enal problcmtico tarnbin an')enaza la r clociclacl cle dcsarrollo. Es un nrobler.na habitual. y sc ha corrprendido bien. al rrenos dcsdc que Geralci

3: Empleados problemticos incontrolados. Lrn fallo

\\ cinberg pLrblic

l tomar una clecisin cuando sc trata con Lrn empleado problemtico es

Lrna cle r1e

P.s-t't'holog.t'of c'otnttttcr. prtt,4t.urtrnrirg en I szl .

un fallo

rrr sabia clue Chip

erii ura lrlnzana poclricla, pcro el jefe del equrpo no hizo'acla. El resultado cra predecible: rehacer cl trabajo c'le chip.

las cluejas r.r.rrs coll"rur.lcs que liencn lcls nricmbros clel equipo respecto sus responsables (Lalson 1.'LaFasto. lggc)). En el Ejernplo 3. l. el equi-

contribuycn al proce so

rir-lc a los pfogfcsos flnres y consistcntcs y'a los infbrmes signilicativos ric progreso. El resultaclo flc r-rn nrocleltl de pla'ificacin al imite en el iluc las amcnazls cle dc.sajuste dcl plan no se dctcctaban. ni sc collocran o rrr sc iulbllnabin a la caclena dc clirectir.os hasta el irltimo minuto. Un pe querio ecluipo dc clcsarrollo v sus jefcs inmediatos toman cono relrenes ir una courpaa entera por lro adnritir que tiencn problenras para cumplir 5u plan. El enfasis !-n los conrrortarlicntos hcroicos ibmenta correl.ul.r fiesgo cxlren'ro. e impidc la cooperacin entre los mLrltiples elementos que
c'lc

dc nir el lneclio dieron mavores arlausos a actitudcs clel trpo <ser capaz de>

4: Hazaas. Algu'ros dcsarrolladores cle sofiu/rre pouen un gran nfasrs en la rcalizacin dc hazaas en los proyectos (Bach. 1995J. pero lo llue hacen tienc mis de rlalo quc de bucno. Err el ejemplo. los directivos

dcsarrollo dcl sttfiu,are.

Al-qunos clirectir os lilnentan cl conrporlamiento heroico cuanclo se cOnccntran con dcnrasiada firnrcza en actitr.rdcs (ser capaz cle>. E,levando L'stas actlturies llor encima cle intbrmcs del estado exactos y a veces pesr_ rrristas. los clirectivos cic estos provectos coartan su capacidad de tomar nrcdicias colrcctivas. Ni sicluicra sabcn que tre nerr que r-mprendcr acclolres correctolas hasra clLrc el dao 'a cst hecho. Couro dijo Torn DeMar_ co. ias actitucies (ser caplz clc> conriertcn pequeos contratienlpos en auleir.rticcls ciesastres ( DcN4arco. I 995).

cl nrs clsico de Ios errores clrsicos. crr-ranclo uu proyecto se alarga, aaclir nrrs gcr.rtc rr-rcdc quitar n'riis procir-rc-tilidacl a los r.nierrbros del equipo exlstcnte cle la que aaclen los nuevos miembros. Frc<i Brooks colr-

5: Aadir ms personal a un proyecto retrasado. Este es quizs

(Brooks.

pala aadir gente a un proyecto retrasaclo con cchar gasolina en un fuego

1975 ).

48

Desarrollo y gestn de proyectos informticos

REFERENCIA CRUZADA Para ms informacin sobre los efectos del entorno pscolgico en
ra pruuuLUvruduj

6: Oficinas repletas y ruidosas. La mayora de los desarrolladores

consideran sus condiciones de trabajo como insatisfactorias. Alrededor del 60 por 100 indican que no tienen suficiente silencio ni privacidad (DeMarco y Lister. 1987). Los trabajadores que estn en oficinas silencrosas y privadas tienden a funcionar significativamente mejor que aquellos que ocupan cubculos en salas ruidosas v repletas. Los entornos repletos y ruidosos alargan los planes de desarrollo.

consulte el Captulo 30, . Entornos Productivos..

REFERENCIA CRUZADA Para ms informacin sobre las relaciones efectivas con los clientes, consulte el Captulo 10, . Desarrollo orientado al clente..

7: Fricciones entre los clientes y los desarrolladores. Las fricciones entre los clientes y los desarrolladores pueden presentarse de distintas formas. A los clientes puede parecerles que los desarrolladores no cooperan cuando rehsan comprometerse con el plan de desarrollo que desean los clientes o cuando fallan al entregar lo prometido. A los desarrolladores puede parecerles que los clientes no son razonables porque insisten elr

planes irreales o cambios en los requerimientos despus de que stos hayan sido fijados. Pueden ser simplemente conflictos de personalidad entre dos grupos. El principal efecto de esta friccin es la mala comunicacin, y los efectos secundarios de la mala comunicacin incluyen el pobre entendimiento de los requerimientos. pobre diseo de la interfaz de usuario y, en el peor caso. el rechazo del cliente a aceptar el producto acabado. En el caso medio, las fricciones entre clientes y desarrolladores de software llegan a ser tan se\eras que ambas partes consideran la cancelacin del proyecto (Jones, 1994). Para remediar estas fricciones se consume tiempo, y distraen tanto a desarrolladores como a clientes del trabaio real en el proyecto.

REFERENCIA CRUZADA Para ms informacin sobre f ilar expectatvas, consulte la Seccin 10.3, "Gestin de las expectativas del

8: Expectativas poco realistas. Una de las causas rns comunes de fricciones entre los desarrolladores y sus clientes o los directivos son las expectatlvas poco realistas. En el Ejemplo 3.1. Bill no tena razones para
pensar que el programa Giga-Quote se podra desarrollar en 6 meses, pero se era el plazo en que lo quera el comit ejecutivo de la compaa. La

Cllenle'.

incapacidad de Mike de corregir esta expectativa irreal fue la principal fuente de problemas. E,n otros casos, los directivos o los desarrolladores de un proyecto se buscan problemas al pedir fondos basndose en estimaciones de planificacin demasiado optimistas. A veces prometen un conjunto de funciones tan altas como la Luna. Aunque por s mismas las expectativas irreales no alargaran el plan. contribuyen a la percepcin de que el plan de desarrollo es demasiado largo, y de que puede ser malo. Una inspeccin de Standish Group marc las expectativas realistas como uno de los cinco factores principales necesarios para asegurar el xito de los proyectos internos de software de gestin (Standish Group. 1994).

Captulo 3: Errores clsicos

49

;htrs dc los aspectos del desarrollo rpido es necesario un promotor del lrrrvecto de alto nivel. incluyendo una planificacin realista, el control de ;nrbios y la introduccin de nuevos mtodos de desarrollo. Sin un pro:lotor ejecutivo efectivo, el resto del personal de alto nivel de la empresa :.uede forzar a que se acepten fechas de entrega irreales o hacer cambios .1ue debiliten el proyecto. El consultor australiano Rob rhomsett afirma ue la falta de un promotor ef-ectivo garantiza virtualmente el fracaso clel irrovecto (Thomsett, 1995). 10: Falta de participacin de los

9: Falta de un promotor efectivo del proyecto. para soportar mu-

impricados.

Todos los principales

po. miembros del equipo, personal de ventas, usuarios finales, chentes y cualquiera que se juegue algo con el proyecto. La cooperacin estrecha scllo se produce si se han i'rplicado todos los participantes. permitiendo una coordinacin precisa del esfuerzo para el desarrollo rpido, que es imposible conseguir sin una buena participacin.
11

prftrcipantes del esfuerzo de desarrollo de software deben imolicarse en c-i p.oyecto. Incluyendo a los promotores, ejecuti'os. responsables del equi-

: Falta de participacin del usuario. La inspeccin de Standish

nras de Infonnacin tuviesen xito es la implicacin del usuario (Standish

Group descubri que la razn nmero uno de que los proyectos de Siste-

Group, 1994). Los proyectos que no implican al usuario desde el principio corren el riesgo de que no se comprendan los requerimientos del pro\ecto. y son vulnerables a que se consun-ra tiempo en prestaciones que rns tarde retrasarn el proyecto.

12: Poltica antes que desarroilo. Larry constanti'e indic que si hay cuatro equipos hay cuatro tipos difercntes de orientaciones polticas (constantine, 1995a). Los <polticos> estn especializados en la <<gestin>, centrndose en las relaciones con sus directivos. Los <investigadores> se centran en explorar y reunir informacin. Los <aislacionistas> estn solos. creando fronteras para el proyecto que rnantienen cerradas a los que no son miembros del equipo. Los <generalistas> hacen un poco de todo: establecen relaciones con sus clirectivos, realizan investigaciones y exploran actividades, y se coordinan con otros cquipos conlo parte de su modo de trabajo. constantine indic que inicialmente los equipos polticos y generalistas estn bien vistos por los directivos de alto nivel. pero despus de un ao y medio, los equipos polticos llegan a la muerte sbita. Primar la politica en vez de los resultados es fatal para el desarrollo orientado a la velocidad.
13: llusiones. Estoy impresionado de ver cuntos problemas del desarrollo del software se deben a la ilusin. cuntas veces hemos escuchado cosas como stas a distintas personas:

50

Desarrollo y gestin de proyectos informticos <Ninguno de los rnicrlbros clel provccto cree reillrente que pueda coutplctafse el prol'ccto rle acrcrcio con eJ tllrn (lue tir-nclr. pcro picnsan que cluizlis si trabrtjan ciuro. r natla la r-nrl. r tiencr Lllr poco clc suerte. sc-riin t.tpitc) tlc .,rltr'lur' \()n \ito.,' r<\ucstro cquil-ro no hacc urllcho traba.jo parii la coorclinaciirn clc las intcrttccs cntrc- las distintas partes (lel proclucto. pcro tcncnr()s .rna bucna conrunicilcin pafa otras cosas. v las rnterfaces son relati\'mente sinrples. slt ncccsitarcnros un da o clos para elinrinar los

:::J:: ,i-t,rtrlr-nrcritc
<Sabcnros que c()ntlnros con Lrn clesan'ollador e\tcnro clc poco talento e I subsiste'nra dc'lt base- dc thtos. \, clc cs cliflcilvel ctin.ro va a acabar el trabajo con lo. nirelcs de'pcrsonal que lia esrccificailo en sLl propLrcsta. No ticncn tarlta expcricncia couro algunos de los cie-nts desarrollaclores e\ternns. pero pLretlc cluc contpenser con enerqa lo clue les falta en experiencia. [)robrblenrente ucaben tienll]o.)) <<No ncccsitarnos fel'1.'iar l irltima lista dc canlbios cn cl prototipo para cl cliente. Lstor. scquro cle quc rot'ahOt' sabelnos lo cluc clLliere.)) ,,El cquil-ro csth clicicnclo quc rcalizar un estucrzo extrrorclinrrio I-riu u cirnrplil con la lecha clc cntrcgr. \'clLlc no han llegaclo a su printer hito por pocos clias. pcro creo quc nlcanzarlt rlstc u ttetrrpo. " para

Las ilusioncs no son slo optintismo. Re alutente colsistcn clt cerrar los ios )'csllcrar que toclo lirncione cuurdo no se tienen las bases razonAbles para pcnsar qLre serll rs. Las ilr.rsioncs al comienzo del proyecto llevan a grandcs cxplosiones al tlnal. Intpiclcn llet'ar a cabo uua planificaci(in coh'rcrite y pueclen ser la raz de nts problenras cn el soft$,are que todas las otras calrsrs conrbinaclas.

Proceso
Los errores rclacionaclos con el proccso ralentizan los proyectos porquc malgastan cl talcnto y el esfucrzo clel personal. A continllacin sc ntllestran algunos dc los peorcs crrores relrcionados colt el proccso.
REFERENCIA CRUZADA Para ms informacin
<^hro l^c l.nc

irreales, consulte la Seccin 9.1 . Planif icacin excesivamente optimista,,.

.

14: Planificacin excesivamente optimista. Los rctos a los quc sc elfrenta alguicn qLre dcsarfolla una aplicacin en trcs nlcscs son muy dil-crentcs de aqucllos a los quc sc eufl'enta algLrien que desarrolla una aplicacin que neccsita un ao. Fi.jal Lrn plar"r crcesir antelrtc optinrista predispone a qur- el proyccto f'alle por infravalorar el alcance dcl proyecto, minando la planificacicin cfectiva, y rcduciendo las actir.'idac'lcs criticas para el ciesarrollo. cono cl anlisis de rcqucrimientos o cl disco. Tanlbin supone una exccsi\/a presin para los desarrolladores. quisl.lss a largo plazo se ven af'ectados cn su nroral y su producti\idtd. Esta t-s la mayur fuente de problcmas clel Ejenrplo 3.1.

Capttulo 3: Errores clasicos

51

15: Gestin de riesgos insuficiente. Algr-rnos crrorcs no son lo suficicntcl.lrcnte habituale s conto para considerarlos clsicos. Son los llamados ,,ricsgos>>. Cor.no con los errorcs clsicos. si no e-jercernos una gcstin activa dc los ricsgr)s. colr que slo va_va ntal ulta cosa se pasar de tcner un pro\ccto con un clesarrollo rupiclo a uno cou un dcsarrollo lento. El f-allo de no gcstional' uno solo clc cstos riesgc'ls es un crror clsico.

16: Fallos de los contratados. Las

rcalizacion
cie pirrtes

corr-rpaas a r,cccs contratan la dc un plor,ccto cuando tienct.l dentasiada prisa para

haccr cl trabqo en c1sa. Pcr<t los contrataclos fl'c-cuentementc entregan sll lrabao trrcle" con uua calidrc1 inaceptable cl quc falla al no coincidir con lrr e 'rr'ifie le itlll t Bochlll. lt)x,,1 t. Ric:t()\ e onto rcqucrimicntos inctables cl interf aces nial clcfinicias pueclen scr enorntes cuando un contratado entra elr escr-na. Si las relaciones con los contratados no se _eestionan cuidadosamente . la utilizacin dc desarrolladorcs cxternos nuede ralentizar el Drovecto cn vez dc acelerarlo.

17: Planificacin insuficiente. Si no planificamos para conseguir un clesarrollo rpido. r'ro rodcnros espcrar obtcnerlo.
18: Abandono de la planificacin bajo presin. Los equipos de desarrollo haccn plane s y rulinarian.rentc los abanclonan cuanclo sc tropiezan
con Lln problema or la planificacin (Humplrrey. 1989). El problcma no cst en el abandono del plar.r. sino nrs bien en fallar al no crear un plan alternatlvo. \'cacr elttoltccs en el t.nodo dc trabajo de codiflcar y corregir. En el Ejcnrplo 3.1. el cquipo abandon su plan despus de fallar en la prirnera

entrega. v csto es lo habitual. A rartir cie cste punto. el trabajo no tuvo cooldinacitin ni cJcgancia. hasta cl punto de que Jill empez a trabajar partc dcl tier.npcl llara Llu llroyecto c1e su liejo grupo y nadic lo supo.

19: Prdida de tiempo en el inicio

tlenrpo quc transcLlfre

difuso.

ln1cs c1e qLrc cor.nicnce

El <inicio difuso> es el el proyecto; estc tiempo

: -'-^
:':.

::

normalnlcnte se picrcle en el proceso de aprobar y hacer el presupuesto. No cs poco cor.n[tn quc ull pro]-ccto dcsperdrcic lreses o aos en un inicio difuso. v cntonces se cst a las -ruertas de un plan agresivo. Es r.nucho rns fcil r barato y lxenos arries-eado suprirrrir Luras pocas selranas o lneses del inicio dilirso cn vez cie contprir.r.rir el plan de desarrollo en ese misl.l.lo tiempo.
A

20: Escatimar en las actvidades iniciales. Los proyectos que se

acelcran intentando lcortar las actii.'idades no escnciales" y puesto que el anilisis dc requerintientos. la arquitcctura r cl disco no produccr.r cdigo directanrcnte. son los candidatos 1ciles. En un proyecto clesastroso en el qLrc particip. ped que ntc cnseascn el disco. E1 respclnsable del equipo rne dijo: <No hernos te niclo tientpo clc hacer cl cliseo.>

-::

es.

:a on

: .:.--ele

52

Desarrollo y gestin de proyectos informticos

DATOS REALES

ffi

Los resultados de este error, tambin conocido como (saltar a la codificacin>, son todos demasiado predecrbles. E,n el ejemplo. un truco de diseo en el informe del grfico de barras fue sustituido por un trabajo de diseo de calidad. Antes de poder entregar el producto, el traba.o con truco tuvo que trrarse, y hubo que hacer de todos modos el trabajo bien hecho. Los proyectos que normalmente escatir.nan en sus actividades iniciales tendrn que hacer ese trabajo en otro momento. con un coste de l0 a 100 veces superior a haberlo hecho bien inicialmente (Fagan, l 976; Boehm y Papaccio, 1988). Si no podemos encontrar ci'co horas para hacer
el trabajo correctamente la printera vez. ,cmo vamos a encontrar 50 para hacerlo correctamente ms tarde'l

21: Diseo inadecuado. un caso especial de escatimar en las acti\ idades iniciales es el diseo inadecuado. Proyectos acelerados generan un diseo indeterminado. no asignando suficiente tiempo para l y originando un entorno de alta presin que hace difcil la posibilidad de considerar alternativas en el diseo. El nlasis en el diseo est ms orientado a la conveniencia que a la calidad, por lo que necesitar r'arios ciclos de diseo antes de poder finalizar completamente el sistema.
REFERENCIA CRUZADA Para ms informacin sobre control de calidad, consulte la Seccin 4.3, .Bases del control de calidad".

DATOS REALES

22: Escatimar en el control de calidad. En los proyecros que se hacen con pnsa se suele cortar por lo sano. eliminando las revisiones del diseo y del cdigo, eliminando la planificacin de las pruebas y realizando slo pruebas superficiales. En el ejemplo, las revisiones del diseo y del cdigo se eliminaron lirnpiamente para conseguir una ganancia considerable en el plan. Al final. cuando el proyecto alcanz su hito de plena funcionalidad, an tena demasiados errores y se retras ms de 5 meses. Este resultado es tpico. Acortar en un da las actividades cle control de calidad al comienzo del proyecto probablemente supondr de 3 a l0 clas de actir.'idades finales (Jones, 1994). E,sta rcduccin va contra la velocidad de desarrollo.
23: Control insuficiente de la directiva. En et ejemplo hay poco control de la directiva para detectar a tiempo los signos de posibles retrasos en
el plan, y los pocos controles definidos al comienzo se abandonaron cuando el proyecto comenz a tener problemas. Antes de encarrilar un proyecto, en primer lugar debemos ser capaces de decir si va por buen camrno.

REFERENCIAS CRUZADAS Para ms informacin sobre controles de la directiva, consulte

.Seguimiento.. en
la Seccin 4.1, y el Captulo 27, ,Hitos mtntatura..

24: Convergencia prematura o excesivamente frecuente. Bastante antes de que se haya programado entregar un producto, hay un impulso para preparar el producto para la elttrega, mejorar el rendimiento del producto, imprimir la documentacin final, incorporar entradas en el sistema final de ayuda, pulir el programa de instalacin. eliminar las funciones que no van a estar listas a tiempo y dems. E,n proyectos hechos con prisa,

Captulo 3: Errores clscos

53

'i:i'rClA :,ZADA - : l:'c

a

hay una tcndencia a fbrzar prematuramente la convcl'gencia. Puesto que

no es posible fbrzar la convergencia del producto cuando sc desea, algunos proyectos de desarrollo rpido intentan forzar la convergencia media docena de veces o ms antes de que finalrnente se procluzca. Los intentos adicionales de convergencia no benefician al producto. Slo son una prdida de tiempo y prolongan el plan.

25: Omitir tareas necesarias en la estimacin. Si la gente no guafda cuidadosamcntc datos dc proycctos antcriores. olrida las tareas ntcnos r.'isiblcs. pero son tareas que se han de aadir. El esfuerzo ontitido suelc aumentar el plan de desarrollo en un 20 o 30 por 100 (Van GcnLrchten. l99l). 26: Planificar ponerse al da ms adelante. Un tipo de reestinracin es responder inapropiadanentc al rctraso dcl plan. Si hcrnos trabajado en un proyecto durante 6 nreses. y hemos empleado tres n.reses en llegar al hito correspondiente a los dos rreses. .qu hacer'l E,n muchos proyectos
simplemente se plantea recuperar el retraso l.ns tardc. pero nunca se hace. Aprenderemos ms del producto confonne lo estarnos construyendo. incluyendo ms sobre lo que nos llevar construirlo. E,stos conocinrientos nccesitan reflejarse en la reestimacin del plan. Otro tipo de error eu la reestimacin se debe a cambios er.r el prociucto. Si el producto que estamos construyendo carnbia. la cantidad de tiempo nccesaria para construirlo cambiar tarnbin. En el Ejcnplo 3.1, los requerimiertos principales cambiaron entre la propuesta original y el conricnzo del proyecto sin la correspondiente reestir.nacin del plan o de los recursos. El crecinliento dc Ias nue\as prestaciones sin a.j rrstar cl plarr gal'antizil quc no se alcanzar la f'echa de entrega.

27: Programacin a destaio. Algunas organizaciones cr.--cn quc Ia codiflcacin rpida, libre. tal corro salga. cs cl camino hacia el desarrollo rpido. Piensan que si los desarrolladores estn lo suflcientcmcntr- motivados, pueden solr,entar cualquicr obstculo. Dcbido a las razoncs que se vern claramente a lo largo de todo cstc libro. esto est lejos dc la vcldad. Este enfoque muchas vcccs se prcseuta colno uu enfbque <empresarial>> al desarrollo de softrvarc, pero realmeute es slo la envoltura dcl l'ie-jo paradigrra a destajo combinado con Llna planificacin anrbiciosa. y esta combinacin raras veccs funciona. Es un ejemplo de que dos negaciortc-s r.rcl constituyen una verdad.

Producto
A continuacin
se n-ruestran los errores clsicos relacionados con la fbr-

ma eu la que se define el producto.

54

Desarrollo y gestin de proyectos informticos

28: Exceso de requerimientos. Algunos proyectos tienen lns reqLlerimientos cle los que necesitan. desde el misrno inicio. La eficiencia se fija como requisito ms a menuclo de lo qtle cs necesario. y pucde generar una planificacin del softu'are innecesariamente larga. Los usuarios tiencien a interesarse menos en las prestacioncs con-rplcjas que en las de las
secciones de marketing o de desarrollo. r las prestaciones cornplejas alargan desproporcionadantente el plan de desarrollo.
REFERENCIA CRUZADA Para ms informacin sobre el camtlio de prestaciones, consulte el Captulo 14, "Control del conjunto
.l nraelr.i^nac-

29: Cambio de las

prestaciones.

Incluso si hemos eyitado con xito los

rcquerimientos erccsivos" los proyectos sufren como rnedia sobre uu 25 por 100 de carnbios en los rcqLlerinlientos a lo largo de su vida (Jones. 1994). Un cambio de este calibre puede producir un aumento en el plan de al mcnos un 25 por I 00, 1o que puedc ser fatal para los proycctos de dcsarrollo rpido.

REFERENCIA CBUZADA Para consultar un ejemplo sobre cmo, incluso accidentalmente, un desarrollador puede caer en requerimientos excesivos o superf luos, vase ,,Objetivos poco claros o imposibles", en la Seccin 14.2.

30: Desarrolladores meticulosos. Los desarrolladorcs encuentran

fascinante 1a nuel'a tccnologia, y a veces e stn ansiosos por probar nuevas prestaciones de su lcnguaje o cntorno. o por crear su propia implemcntacin de una utilidad bonita que han visto en otro producto, la nccesitc o no su producto. E,l esfuerzo requerido para disear. irnplementar. probar, documentar o mantener cstas prestaciones itlnccesarias alarga

el plan.

31: Tiras y af loias en la negociacin. Cuando un directivo aprueba un retraso en el plan de un proyecto quc progresa ms lento de 1o csperado, y entonces aade tareas completamente nuevas despLrs de un cambio en el plan. se produce una situacin curiosa. La ran Subyacente de esto cs difcil de localizar, puesto que el directivo que aprlteba el retraso en el
plan
1o hace sabiendo implcitarnente quc el plan estaba equivocado. Pero una vez que Se corrige. la misma persona realiza acciones cxplcitas para volver a cquivocarse. E,sto slo pucde ir en contra del plan.

32: Desarrollo orientado a la investigacin. Seymour Cray. el diseador de los supercomputadores Cray. dijo quc no intentaba sobrepasar
los lmites de la ingcrriera cn ms de dos reas a la vez. porque el riesgo de un f-allo es demasiado alto (Gilb, 19S8). Muchos proyectos software deberan aprender la leccin de Cray. Si el proyccto fuerza los lmites de la informtica porqLle necesita la creacin de nuevos algoritmos o de nuevas tcnicas de contputacin. no estamos desarrollando softrvare; estamos inr,'estigando en software. Los planes de desarrollo de softrvare son razona-

blernente preclecibles: 1os planes en la inr.'estigacin sobre software nr siquicra son predecibles tericamcnte. Si cl producto tiene objctivos que pretenden aumentar los conocirnicntos

Captulo 3: Errores clastcos

55

existentes. como algoritrnos. velocidad, utilizaci dc la metnoria y dcrns. debemos asumir que la planificacin es altamente especulativa. Si queremos mejorar el estado dcl arte y tenemos algn otro punto dbil en el proyecto. recortes de personal, debilidades en el personal, rcquerinlientos \agos, interfaces inestables coll contratados externos. etc . podemos tlrar poi la ventana la planificacicin prevista. Si queremos supcrar el estado del u.t. po. todos los medios, hagmoslo. Pcro no debemos esperar hacerlo
rpidamente
I

Tecnologa
L,l resto
c1e

los erlores clsicos estll relacionados con el uso correcto

incorrecto de la tecnologa moderna.

-:-:-= \urA

33: sndrome de la panacea. En cl ejerplo. se cofi

: : -'--'Tacin : : -:-3me de

: = JZADA

_-_: f

trl

demasiado las I'cntajas proclamaclas de tecnologas que no se habian usado antes en (gencradores de informes. diseo orientado a objetos y C++) y demasiada poca inlormacin sobre 1o buenas que seran en cste entorno de desarrollo concreto. Cuando el equipo cicl proyccto sc aftrra slo a una nueva tcnica. uua nueva tecnologa o un proceso rigido. y espera resolver con ello sus problemas cle planificacin. est ineyitablemente equivocado (Jo-

nes.1994).
-:-r-f \u1A

:: -ZADA -:i - -'-aclon :: : -::

,Sando

34: sobreestimacin de las ventaias del empleo de nuevas herramientas O mtOdOS. Las organizaciones rejoran raranente su producrir itiad a grandes saltos. sin inrportar cutltas nuevls het'ralllicntas o lnetoclos ernpleen o lo buenos que sean. Los beneficios de las nuevas tcnicas

--:.ora de

: : - -:: '., dad. . : :::Jcclon : -:.-::'15.4.

:::=l:NCIA
-'

i: ---'laclon ::,
ZaClOn,,.

, I JZADA

son parcialmente desplazados por las curvas de aprendizaje que llevan asociadas. y aprerrdcr a utilizar nuevas tcnicas para aprovecharlas al mrimo lleva su tiempo. Las nucvas tcnicas tambin suponcn nucvos riesgos. que slo descubriremos usndolas. Ms bien experirnentaremos rncjoras lentas y continuas cn un pequeo porcentaje por proyccto en lugar dc grandes saltos. El equipo del Ejemplo 3.1 debera haber previsto omo mucho un l0 por 100 de ganancia en productividad por la utilizacin de las nuevas lecnologias en vez de asumir que cstaran cerca de duplicar su productividad. Un caso especial de sobreestimaciones de las nrejorls se producc cuando se reutiliza cdigo c1e proyectos anteriores. Este tipo de reutilizacin puedc ser una tcnica ntuy clectil'a. pero el tiernpo que Se gana no es tan grande como se espera.

35: Cambiar de herramientas a mitad del proyecto' Es un r iejo recurso que funciona raramente. A veces puede tencr sentitlo actualizar

56

Desarrollo y gestin de proyectos informticos

incrementalmente dentro cle la misma lnea de productos, de la versin 3 1. Pero cuando estamos a la mitad de un proyecto, la curva de aprendizajc. rehacer el trabajo y los inevitables errores cometidos con nna herramienta totahrente nueva. normalmente anulan cualquier posible bencficio.
a la 3.1, o incluso a la

36: Falta de control automtico del cdigo fuente. Un fallo en

REFEFENCIA CRUZADA Para ms informacin sobre el control del cdigo fuente, consulte .Gestin de
L^ iq ^^^^,,.^^i^ uu,,,r9ur4u,w,l

la

utilizacin clel control autonltico del cdigo fuente expone a los proycctos
a riesgos innecesarios. Sin 1. si dos desarrolladores estn trabajando en la r.lrisma parte del programa. deben coordinar su trabajo manualurente. De-

del software., en la Seccin 4.2.

berian ponerse de acuerdo para poner la ltima versin de cada archivo en el directorio maestro y verificarlos con los dems antes de copiarlas en este directorio. Pero invariablemente alguno sobreescribir el trabajo del otro. Se desarrolla nuel'o cdigo con intcrfaccs dcsfasadas. y despus se tiene que redisear el cdigo al descubrir que se ha utilizado una versin eqr.ril'ocada de la interfaz. Los usnarios avisan de errores que no podemos reproducir porque no hay forma de volver a crear los elementos que han utilizado. Cclr.no media. los cambios en el cdigo fuente suelen ser de un l0 por 100 al mes. y con un control manual dcl cdigo fuente no deberan crecer (.lones, 1994). La Tabla 3.1. de la pgina siguientc. conticnc una lista completa de lcls errorcs clsicos.

3.4.

La fuga de La isla de Gilligan

Una lista completa de los errores clsicos ocupara muchas ms pginas, pero los que se indican son los ms cornunes y los ms serios. Como indic Davicl Urr-rpress, de la Univcrsidad dc Scattle, la vigilancia que la mayora de las organizaciones realiza para evitar estos errores es como ver una y otra vez Lu islct cle Glligan. Al principio de cada episodio, Gilligan. el Capitn o el Profesor llegaban con un plan tonto para salir de la isla. El plan pareca funcionar inicialmente. pero, corro revelaba el episodio, algo iba mal. y al final del episodio los nufragos volvan donde haban empezado. perdidos en la isla. De igual forma, la r.nayora de las compaas descubrc al final de cada proyecto que han cornetido otro error clsico y que han entregado otro proyecto luera de plazo. con mayor coste, o ambas cosas.

Su propia lista de malos hbitos

Debe ser cuidadoso con los errores clsicos. Puede crear listas de <malos hbitos> para evitarlos en futuros proyectos. Comience por la lista que apa-

Captulo 3: Errores

clsicos

57

. -:-l',:
,.. .

con el

Errores relacionados Errores relacionados Errores rclacionados proceso con el producto con la tecnologa

ji Sndrome de la .I Planificacin 28. Exceso de e-rcesivamente requerilxientos panacea . ,,_ optirnisa 29. Cambio de las -l1. Sobreestimacin 15. Gestin de riesgos prcstaciones de las ,,,entajas del insuflciente . ernpleo de nuc,u,as 30. Desarrollaclorcs herramientas lb. Fallos de los rneticulosos I.ntodos contratidos i l. Tiras y aflojas en 11. Planiflcacin la negociacin 35. Cambiar de insul-icie nte herrarnientas a .. -. 32. Desarrollo mitacl del proyecto lE. Abanclono clc la orientaclo a la -:. planificacin bajo invcstisacin j6. Falta cle control Preslon automtico del . -' :-cdigo fuente 19. Prdida de tiernpo . en el inicio difuso . ,\ - r. -,.f) 10. Escatimar cn las
cr

actir, idades

iniciales

. ,

__

\., II. 22.

Diseoinadecuatlo
Escatimar cn el control de calidad

i. Jc- 23. Control - , .:..1': insuflciente de la directrva . . .lcl 2.1. Conr ergencia
.

.\ t-'r.
r r

prematura o ercesir alilenle

frecuenre

:.

25. Omitir

tareas neccsarias en la

estimacin

26. 27.

Planificar ponerse al da rns adelante

Prograntacin
destaj o
a

rece en este captulo. Vaya incrementando la lista segn se vayan acabanclo proyectos para aprender de los errores cometidos por su equipo. E,stimule

esie comportamlento para otros proyectos dentro de la cmpresa, para

58

Desarrollo y gestin de proyectos informticos

aprcnder dc stts errores. Intercanbie cxpcriencias con los colegas de otras y aprenda de su cxpcrienciii. Exhiba en lugai r.'isible la lista de errores. y asi la gente la vcr y aprcr.rdcrii sin cometer cle nuevo los

orgrrlizacioncs
Inlsnt()S

eI.l'OfCS.

Bibl iografa adicional

Aunque algunos libros tratan sobre errores dc cdigo, no conozco libros
quc describan los errorcs clsicos relacionacios con los planes de desarrollo. En cl resto de este libro se incluycn referencias sobre temas relacionados.

Bases del desarrollo de software

Contenido
-1.1. Bases de gestin

4.2. 4.3. 1.4.

Bascs tcnicas Bascs del control de calidad

Seguir las insrrucciones

Temas relacionados
Estrategia para el desarrollo rpido: Captulo 2 Resumen de inspecciones: Captulo 23

RED AUERBACH. EL ENTRENADoR QUE MAS TIEMPo DUR con los Boston Celtics. y lrasta hace poco. el que ms veces gan cn la historia del baloncesto profesional. lanz un video titulado <Rcd on Roundball>. Auerbach nantiene el hecho de que los conocin.tientos bsicos son el punto clave para tener xito clentro del baloncesto prof'esional. Indica quc dc al rnenos 20 pascs de los que se realicen. slo van a tener xito aquellos en los que htn'o ulguien que cojct el haln. La clal'e del rito en el rebote radica en coqer el baln. Tencr una buena base fuc la estratc-gia quc Auerbach sigui para ganar ocho l'cccs seguidas los carnpeonatos dc la NBA. Para obtener rito en el software hay que prestar la urayor atencin posible a los fundamentos. Podra ser el Bob Cousy, Kareem Abdul Jabbar o Michael .lordan de su organizacirin softu,are. Podra disponer de una serie dc mtodos orientados a la planificacin. Pero si no utiliza los
conceptos bsicos dc desarrollo corno el punto nts importante del esfuer-

zo de desarrollo. sc arriesgar a no alcanzar las r.nclas dc planificacin

que se l.ra propuesto.
59

60

Desarrollo y gestin de proyectos informticos

No'ralmente las personas suelen decirre que use buenos ntodos de ingeniera del software porque estn <bien>) o porque contribuir a aumentar la calidad. Srrs consejos parecen tcner connotaciones religiosas.
utilcelas. Si no funcionan. ino lo hagal Mi opinin es qllc se deberan utilizar los mtodos fundamentales de ingeniera del software descritos en este captulo, no porquc estn <bien>>. sino porque r.educen el coste y el tiempo de cornercializacin. Esta postura es menos terica de lo que se podran imaginar. En ur.l anlisis de l0 proyectos software. que las organizaciones seleccionaron como <los mejores proyectos)). Bill Hetzel lle-e a la conclusin dc que <si haba que birscar una conclusin que destacara por encima de las dems, se poda decir que los r.nejores proyectos lo eran porque se basaban
cn los fundamentos. Todos conocemos los fundamentos para un buen software; la diferencia est en que la mayora de los proyectos no lo hacen bien, y entonces tienen problemas> (Hetzel, 1993). Pero no piense cn esto como una cuestin dc fe. Si las tcnicas fLrncronan.

Tottos deseun <'stur en ttrt aclttipo cttrrtpen, p(r0 nude descu reLt/i:ur el
e.t.f

irer:o pa ru llet'ut'lt u lu prtit f itu.

Bobb' Knirht

El mejor lugar para comenzar a buscar informacin sobre los funciamentos del desarrollo del software es un libro de texto de ingeniera del software en general. Este libro no es un libro dc texto cle ingenieria del soflware. de forn-ra que este captulo se limita a identificar los funclamentos del desarrollo. explicar cmo afectan a la planificacin clel desarrollo. cuantificar el impacto de su efecto (si es posible). y proporcionar inciicaciones para poder obtener ms informacin. En este captulo, los mtodos se dividen en mtodos de gestin, tcnicos y de control de calidad. Algunos dc los mtodos no se encuadran dcntro de u'a categora, de fbrma que podria hojear todas las catcgoras aunque est r.ns interesado en una en particular. pero primero sera conr,,cniente ver el Ejemplo 4.1 para situarse dentro del cclnrexro.
Ejemplo

4.1.

Falta de fundamentos de desarrollo

<<Nosotros pensbamos que estbarnos seguros de lo que estbamos haciendo>, dijo Bill a charles. <La versin 3 de nuestro programa de primas de ventas, PPV, que utilizamos para pagar las comisiones a los agentes, nos sali bastante bien. Pero con la versin 4 todo cambi.) Bill haba sido el jefe de las versiones de la I hasta la 4, y charles era un consejero tcnico llamado por Giga-Safe para que les ayudara a comprobar por qu ra versin 4 haba sido tan problemtica. <Cules fueron las diferencias entre la versin 3 y la 4?>, pregunt Charles. <Tuvimos problemas con las versiones I y Z>, respondi Bill, <pero con la versin 3, creamos que nuestros problemas haban quedado atrs.
|

(otrtulLtul

Captulo

4:

Bases del desarrollo de software

61

*utgtn de seguridad ;;to* ;;;"dimos ano tuvieron problemas co las tareas' herramientas ";;;"; desarrolladores casl

Sedesarrolisinapenasproblemas'Nuestraestimacinfueprecisa'enpare 30 por 100' Los

de un o

Todo fue fenomenal>' elementos de diseo que se les oividaban' 4?>' apunt Charles' .. <<Entonces, qu ocurri con la versin versin 3 erauna actualizacin evo<Fue algo totalmente diferente' La que se tuvo l"ti;;;;;;i" versin 4 era un producto completamente nuevo' que desarrollar desde el principio' q,nr ^^.^^^i'-ir^" adqut-

aplicar 1os conocimientos Los miembro* a"t la "{ttifo'intentaron Pero en una parte del proyecto' ridos en las versiones r at I "t PPV' ser ms com-

p"1t.".i0"

resultaron comenz u li't'ut' Las tareas tcnicas esttTareas.que^los.desarrolladores haban plicadas de lo que ,. problemas "tpttubu' 2 o,3 semanas Haba "*"" o"t p"riun turui z lu' la bata'"q""tun lt"rrie"tat de desarrollo' y el equipo perdi con algunas nuevas no conocan todas las reglas equipo lla con ellas. Los nuevos miembros del sobreescriban eny desaprovecharon trabajo y tiempo' porque del mismo, Al final, naie poda predecir cundo estre ellos sus archivos ",iuuuo. en que realmente 1o estuvo' La tara listo el producto, hasta el momento por 100'> ' versin 4 tuvo un retraso de un 100 - habia tentque L^Lr^ +^ bastante mal>' ug'"g' Charles' <Mencion <<Eso suena

describirme un poco esos y do problema, con las versiones 1 2' Puede

proyectos?> I'ersin 1 del PPV' el proyecto <Por supuesto), contest Bill' <En la del proyecto t"ryl:t^".,y t" fue un completo caos. Se hizo una estimacin Los problemas tcntcos piunifi.u.iAn de las tareas pareca casi aleatoria' herramientas de desarroresultaron ,", -uyo.",-t fo qut se esperaba'.Las tiempo incrementaron el tiempo de la 1lo que se supona qut it'un u uho"ut

planificacin.Elequipodedesarrollosufriaunretrasotrasotloenlaplanificacin'yningunosabacundoelproductoestararealmentepreparado, realmente lo estuvo' Al final' el equipo hasta uno o dos dias unit" t que de retraso sobre la planientreg .i pt;;t;;; t* un I 00 por 100
det PPV

ficacin inicial.> con la versin 4>' dijo Charles' <Esto es muy similar a lo que sucedi

<Escierto>,Billsacudilacabeza.<Pensquehabamosaprendidola
leccin hace mucho tiemPo 't pregunt Charles' <Qu sucedi con la versin 2?>' de una forma tns regular que <En la versin z, a Jttu*ollo procedi proyecto y la pianificatt:1: las^taeas en la versin 1. La estimacin del gstar mas ba1o conp"t*i.""t ms realistas, y el trabajo tcnico nareci desarrollo y el trabajo de troi. Hubo ,r."no, p.oii"*ut ton las herramientas haba estimado' Cometiede desarrolio llev el tiempo que se del equipo tiemgo de ms' ,on .iror., en la estimacin, poniendo el final del proyecto' el equipodescSbri Pero cuando ,. l u""undo tareas' Tamno hban incluio muchas de las que en la estimacin "tigit"f el diseo' 1o cual signific que tendran que bin descubrieron talloi en
(t
on
t

intiu)

62

Desarrollo y gestin de proyectos informticos

volver a revisar del l0 al l5 pol l0c) del sistema. Tenr un gran retraso en la planificacin, donde tenian que incluir las tareas olvidaclas y la revisin.
Terminaron el trabajo. encontrando unos cuantos problemas ms, sufrieron otro retraso. v finalrnente entregaron el producto un 30 por 100 tacle. En este momento aprendirros a aadir un 30 por' 100 de margen de seguridad a las planificaciones.> <Y entonces, la versin 3 fue bien?>. prcgi.rnt Charles. <Desde luego>. agreg Bill. <Segn he entendido.,,se utiliz el misnro cdigo base en las versio_ nes de la I a la 3'l>, pregunt Charles.

(S>.
<,Trabajaron los mismos miembros del equipo en las versiones de la a la 3'l>
1

<S, pero muchos se rnarcharon al terntinar la versin

j.

anteriornlente. ) <Cracias>, dijo Charles. <Ha sido de gran ayuda.> Charles pas el resto del da hablando con el equipo de <lesarrollo, y por la noche se encontr de nuevo con Bill. <Lo que tengo que decirle puede que no sea fcil para usted>, dijo charles. <como consejero tcnico, he visto docenas de proyectos en un ao, y en toda mi profesin he visto cientos de proyectos en ms de cien organizaciones. El proceso seguido por las versiones de la I a la 4 del ppV es bastante comn. Anteriormente, me dio a entender que los clesarroiladores no controlaron el cdigo fuente de forma automtica, y esta tarde lo confirm hablando con ellos. Tambin confirm que el equipo de desarrollo no realizaba revisiones del cdigo o del diseo. La organizacin confia ms en la estimacin que se hace a ojo, aunque se tengan disponibles mtodos de estimacin ms fiables.> <De acuerdo>>, dijo Bill. <Todo eso es cierto. pero, qu tenemos que hacer para que no nos ocurra lo mismo con otlos proyectos como con la

la mayoria del equipo de la'ersin 4 no haba trabajado cn el proyecto

de forma que

versin

4'?>

<Eso es parte de lo que puede ser duro de oir>, dijo Charles. aNo ne_ cesita hacer nada. Necesita mejorar en los fundamentos clel desarrollo del software o se encontrar con lo mismo una y otra vez. Necesita consolidar los tundamentos. En la parle de gestin, se necesita una mayor efectividad en la programaci', planificacin, seguimiento y meclidas. En la parte tcnica, necesita ms efectividad en la gestin de requisitos, diseo, construccin y configuracin. Y aderr-rs necesita un mayor control de calidad.> <Pero la versin 3 la hicimos bien>, objet Bill. <Desde luego>, agreg Charles. <Lo hicieron bien de vez en cuando. cuando trabajaron con un producto con el que estaban familiarizados, con miembros de un equipo con el que haban esta<io trabajando antes en el mismo producto. La mayora del eqr"ripo de la versin 3 haba trabajado en
l(

onurttd

Captulo 4: Bases del desarroilo de

software

63

. : . ,irr'! I , 2. Una de las razoues por las que las organizaciones pien_ - -..: r: n!-cesitan primar las bases de desarrollo del software es porque . -. :..,-rr er.ito. Pueden obtener resultados bastante buenos en la estimr. ' t'.-tnitlcacin de un producto en particular. piensan que lo hacen - . :i piensan que alguien lo puede hacer mejor.. r:' . >1r catacrdad de dc-sarrollo se construye sobre una base frgil. : !'..ir]r!'frte slo saben crno desarrollar un producto en particular *. .---: :,rill]a especfica. Cuando se enfrentan con cambios importantes en : -:r'i,,lt.ll. en las herramientas o elttorno de desar.rollo, o en e1 concepto ,- :.:,-.itctit" la capacidad de desarollo se derrumba. De repente se en_ ,-.r ::,r: tle nuer,o en el paso l. Esto sucedi con ppV 4 cuando tuvieron -; rr',i:rr el producto desde el inicio. con los desarrollaclores nuevos. i: - -: J: l.t causa dc que los resultados de la versin I y la 4 fueran muy
f ., Ir"ia pensaclo en eso antes. pero probablemente lleve razn>, ilijo :: ::..:nquilamentc. (En mi opinin, eso sllena a mucho trabaio. No s si : -::nos.justiticarlo.> :r no da rtray'or importancia a los fundamentos, lo har bien en los - ' rcrtrS sencillos, pero los proyectos complicados se vendrn abajo>, do
-,:i::. ,rr
stos son a los que realmente l.ray que prestar atencin>.

-:<:

s de gestin
- - . ,inclrrlrentos clc gestin tierrcn al rrenos tanta influencia corno los --r'!o: r-'n la planil-icacin de desarrollos. El Instituto de Ingeniera del ' -..',.lfc hr obscn'ado repeticlanrcnte clue las organizaciones que intr.u:- ::rpl111 la disciplina de la ingeniera dcl sofiu,are antes que la cle
-;r..rrn dc rrovcctcls estrr abocadas al
r-.

fl"acrso

(Burlton. 1992). La

ges-

,.:).rrrollo sicr.npre controla la planificacin real: y a vsces tambin con.:.,,i la planificacin progfantacir). Los liurdar.nentos de gestin consisten en cleterminar el tamao clei .':'orllicto (incluyenclo funcionaliclad, conplejictad y otras caractersticas .r-') prociucto). asignando los recursos apropiados a ur.r producto dc esc .nrao" crcando un plan para aplicar csos recursos y luego controlanrlo y .irligiendo los recursos para impedir que el proyccto sc desr,,e. En alguiros casos. los altos cargos clclegan explicitamente estas tareas de gestin .r los respor.rsrbles tcnictrs. y en r)tros casos simplcmente lo dcjan vacante . ocuprrdolo un rcsponsable o desarrollador rnotivado.

nrr'mllnrenlc controla las tres magnitudes dcl tringulo cle equilibrio ,.-,.rCLr lplanrficacin. coste y prodLrcto), aunqLre algunas veces el depar-::r.'1rto dL- marl(eting controla Ia cspecificacin del producto, y a veces - !11'partamento de dcsarrollo controla la planilicacin (normalmente. cl

64

Desarrollo y gestin de proyectos informticos

Estimacin y planficacin
BEFERENCIAS CRUZADAS Para obtener ms informacin sobre la estimacin, vase el Captulo 8, "Estimacin.. Para obtener ms informacin sobre la planificacin. vase el Captulo 9.
. Planif icacin..

planificacin software. Primero se estima er tamao der producto, luego se estima el esfuerzo necesario para constrllir un producto con ese tamao y por ltimo se realiza una planificacrn, basndose en la estimacin del esfuerzo.

Los proyectos bien ejecutados pasan por tres etapas bsicas para crear una

La planificacin y estimacin son las bases crel desarrollo porque una estimacin incorrecta reduce la eficiencia en el desarrollo. Una estimacin correcta es una condicin necesaria para una planificacin efectrva. que aderns es esencial para un dcsarrollo eficicnte.

Planif icacin
como Philip w. Metzger seal en su clsico Managing a programrtring Project (Gestin de un Proyecto de programacin), la mala planificacin
se manifiesta como luente de problemas ms a menudo que cualquier otra causa (Metzger, l98l). A continuacin se enumera la lista de problemas que aparecen en el desarrollo software que l propone:

ERROF CLASICO

Mala planificacin. o Contrato mal definido. Mala planificacin. Definicin del problema inesrable. Mala planificacin. Falta de experiencia en la gestin. Mala planificacin. o Presin poltica. o Mala planificacin. o Control de cambios poco efectivo. . Mala planificacin. o Plazos poco realistas. o Mala planificacin.
En la revisin qr.re hizo de los mejores proyectos,

REFERENCIAS CRUZADAS Para ms informacln sobre estos temas. vanse el Captulo 12, " Equipo de trabajo"; el Captulo 13, "Estructura de{ equtpo'; el Captulo 7, "Planif icacin del ciclo de vida", ei Captulo 5. ,,Gestin de riesgos". y el Captulo 14, ,, Control del conlunto de prestaciones,,.

Bill

Hetzel en-

corrtr quc los mejores proyectos de la industria se caracterizabanpor una fuerte planificacin anticipada para definir las tareas y programaciones (Hetzel, 1993). La planificacin de un proyecto sofru'are incruye las actir''idades siguientes:

o ' .

Estimacin y planificacin. Determinar el nirmero de personas que deben participar en el equipo del proyecto, qu habilidades tcnicas son necesarias. cundo aumentar el nmero de personas y quin participar. Decidir cmo organizar el equipo.

Captulo 4: Bases del desarrollo de software

65

. o .

Elegir el modelo de ciclo de vida que se va a utilizar.

Gestin de riesgos.

Tomar decisiones estratgicas, tales como controlar el conjunto de prestaciones del producto y decidtr si hay que comprar o crear algunas partes del producto.

Seguimiento
Una vez que se haya planificado el proyecto, hay que seguir el proceso de desarrollo para comprobar que se est cumpliendo el plan previsto: que satisface sus objetivos de planificacin, coste y calidad. Normalntente el

control de seguimiento en el nivel de gestin incluye listas de tareas.

reuniones e informes sobre el cstado, revisiones de hitos, informes de presupuestos y dems gcstiones. El control de seguimiento en el nivel tcnico normah.l.lente incluye las intervenciones y rer,isiones tcnicas y las entradas de calidad, que controlan si los hitos se consideran terminados. Bill Hetzel descubri que en todos <los mejores proyectos) era c',idente la realizacin de una cstricta medicin y seguimiento del estado del proyecto. La medicin del estado para mantener la gestin del proyecto aparece como un subproducto natural de ur.r buen trabajo de planificacin, ' cs un lactor clave de xito (Hetzel, i993). Como sugiere la Figura 4.1, en un proyecto tpico la gesrin del proyecto es casi una funcin de caja negra. Dificilmente se conoce lo que se va a hacer durante el proyecto, y slo hay que quedarse con el resultado final. En un proyecto ideal, en todo momento se tiene el 100 por 100 de visibilidad. E,n un proyccto eficiente, sier.npre se ticne al menos un poco de visibilidad, siendo ms normal el tener una buena visibilidad oue no tener nlnguna.

Inicio
Visibilidad de un proyecto ideal Visibilidad de un proyecto eficiente Visibilidad de un proyecto con el modelo de ciclo de vida en cascada bien desarrollado Visibilidad de un proyecto tipco Prnnrocn del proyecto n

|l

r,j

i.r

Figura 4.1. La visibilidad del progreso cambia segn la clase de proyecto. El desarrollo eficiente ofrece ms visibilidad que el desarrollo
tpico.

66

Desarrollo y gestin de proyectos informticos

DATOS REALES

proyect0.

capcrs.lones iufbnna que <el control cle un proccs.r softuarc es tan nlalo quc t.nuchos dcsastres softu'arc bastantc conociclos no se conoclerolr hasta el nrisnro cla del despliegue cspcraclo> (Jones. l995Lr). DcspLrs de cvaluar 59 nruestras cr,trc 1987 , 1993. cl Instituto de lngeniera dcl Soflivare dedLrjo que el 75 pol 100 rrecesitaban rrrcjorar-la supcr.r,.isin y el scguinticnto del rrovccto (Kitson l,Mastcrs. 1993). Cuanclo las ttr.gani_ zaciones han sitlo rsesoraclas. han intentando nrcjorar v han'r,uelto a soIicitar el'aluacicin. se ha visto que los principales problernas aparecen en las reas clc planificacitin. seguimicnto v supervisin cicl proyecto (Baumert. I995 ). El seguirniento cs una acti'iclad lundrmental cn el proceso de ln planilicacin softriare. Si no sc puccle seur-rir un llroyecto. uo sc pueclc gestionar. No hay fbrnra cic sabcr si e'l plan se cstii llevanclo r cabo ni lo quc se debera haccr clcspr.rs. No hay brrna dc controlar los rics,{os en el proyecto. un sc-euimiento cfectiio perrnite cletcctar-rpiclamc-nte los problcmas dc planificacin. cuanc'lo arn quccla tierrpo para pocler resolverlos. El clcsarrollo rirpiclo no se puecic llc'ar a cabo si no se sigue cl

Medidas
REFERENCIA CRUZADA Para obtener ms nformacln sobre las medidas. vase el Captuto 26.
,,Medidas,,.

una de las formas de progresar cn una orernizacicin soli*are. a largo plazo' es recoger datos trttricos para analizar la caliclad v prodLrctir.iclacl dcl
softlvare. Prcticar.ncnte todos los proyectos recogen clatos sobre los costes 1, la planificacin. Pcro cstos datos son rimitaclos y no avuclan mucho a reducir los costes o a clisntinuir la planificacin. Recogcr rns datos pr-redc suponcr n.lucho tiempo. Si aclems clc datos de coste v planificacin se obticnen datos histricos" corno el trrao dc los progran.ras en lneas cle cdigo. o cualcluier otra meclida" se tcr.rcirn las bascs para la planificacin de proyectos tirrr.rros. cFre srcmpre es nrcjor que cl instinto. cuando eljef'e cliga: <,podis dcsarrollar estc proclucto en

nucve nlcscs'.'r>. podremos dccir: (Nuestfa organizacirl nunca ha clesarrollado un producto de ese tamao en lrcl.los de I I n.reses. y el tienrp, nredio para tal producto es cle l3 nteses.> Para rcalizar el dcsarrollo cie fbrma eficientc'. se necesita teller unos
conocir.uientos bsicos sobrc las rnediclas o r.r.lcltricas ciel softu,are. Se nccesita conocer los ter-nas a los que af'ecta la recogicia de mecliclas. incluyenclo qu cantidad o cunto tie'nrpo se necc-srta para recogcrlos 1.,ctirno hacerlo. Se deberan tener conocimientos sobre mtricas cspeciticas utilizarlos para 1,

analizar el estado. la calidacl y la prodr-rctil'idacl. una organizacitin qire desee implantar el clesarrollo rpido neccsita recoger las meciidas bsicas
rara sabel cul es la r.elocidacl dc desarrollo v si es meior o Dcor a medicl qLlc transcul'rc el tiet.npo.

Captulo 4: Bases del desarrollo de software

67

Bibliografa adicional sobre las bases de gestin

Los cr-ratro rrimclos voliurenes listaclos a continuacin tratan sobre tenras nruy gcncralcs c1c soit'ui'are. incluyendo telras pragmticos. corxo por
e.jemplo qu hacer cou un miembro problemtico del equipo: cuestiones tericas. corlo pucdc scr cnro modelizar un proyccto softu'arc corno url

sistcma. y tclras csotricos" como puede ser la importancia que tiene la obscrvacicin para cl clesrn'ollo clel softu'are. Los liblos de Weinberg son entretcnidos y llenos clc ideas.

\\'einberg, Gerald N[.: Quulin' Sofitrure ,lluttugentent, t't1. l Srsen1s Thn/ririg. Neu'York: Dorsct House, 1992. \\'cinberg. Gerald M.: Quulitr So/iwure Iluttugerttettt, rol. 2: I'-it'st-Orcler :\Ieusttretttan l. Nc\\' York: Dorset Hcluse. 1993. \\'cinberg" Gerald M.: QuuIit.t Sttfi:r.ut'e ,11unugetrtettt, t'oI 3: C'cntgruent .1r'tiou. Ner.r York: Dorsct llousc. 199.1. \\'einbcrg. Gerald M.'. Ottulit.t' Sofitut'c .\lunagetuettt, vol. 4: .,lntic'ipLttittg
Chunge, Neri York: Dorset IIousc. 1996.
Plessnran. Roger S.: ,1 ,)lutruger'.s Guide to Sofin,are Engineering. Neu' York: McGrau-Hill. 1993. E,s uno clc los libros que nruestran una visin ger.reral sobre la gestin clc un prclyccto soft."r,are. Ir-rcluye una introduccin sobre la estlnlacin. anlisis de ries-eos. planificacin .v scguimiento. as cor.no el elcrncnto hur.nano. El iurico inconreniente es clue utiliza un fblmato a base de prcguntas y respuestas. lo cual poclra parecer ir.rct'rr.rcxo a algunos lectores. (Fue lo que rre suce-

cliti a mi.)
f'arr.regie N4ellon Univcrsity,$ofirvare Engineerin-9 Institute: Tlte Cutuhilit.t';\lutut'it.t'1'lodel; Guidelitrt,.s /itr Irttprcn,ing the Soliu'ure Proc'e.ss. Reading. Mass.: Addison-Wcsley. 1995. Estc libro clescribe un entorno a nivei clc gcsticin apto para la cornprensin, gcstin y mejora dcl

lo clcl sollu'rre. Tha,'er. Richalcl II.. cd.: Ttttot'ial: Stfivure Ettgineerittg Projecf Manugetneltt. L-os .Alanlitos. C'alif.: IEEE ('omputer Socict, Prcss. 1990. Es urra colcccirin de .15 artculos sobrc tcr.nas de gcstin dc proycctos solju'arc. Los artcr.rlos son algunos de los me'jorcs esludios disponiblcs sobrc tcrras de planil'icacin. organizacin. contratacin dL. persorral. dircccin y control de un proyecto softr,r,arc. Thaycr hacc una breve intrcldr-rccin y una serie cle correntarios sobre estos temas en cada uno dc los altculos. Gilb. Tom: Prirtt'iple.s ol So.fiu'ure Engineering Xlunugetnent. Wokingham, Englirnd: Adtlison-\\eslcy. 1988. La tesis que Gilb mantiene es ciue los directores de los llroycctos generahrrente no desean preclecir lo clue suceder con sus proycctos: prefiercn controlarlo. Gilb se centra cn cl clcsarrollo de los r.ntodos que contribuyen al control de la
clesarrol

68

Desarrollo y gestin de proyectos informticos

planificacindelsoftrvare.ymuchosdelosmtodosqueseincluyen enestelibroestncatalogadoscomomtodosrecomendables. DeMarco.Tot:n,.Contl.tlllngSofiv,areProjects'NewYork:YourdonPress, lgs2.EllibrodeDeMarconopareceenabsolutoanticuado'Trataen lg82conlosmtsmosproblernasconlosquenosenfrentamoshoy: directivosqueloquierentodoyclientesquedeseantodoalmomento. PresentaestrategiaSdegestindeproyectos,prestandoespecialatencin a las mediciones' Metzger.PhilipW...MttnagingctProgrammingProjec,t,2dECl.E,ng]e-

wcloclCliff.s.N.J.:PrenticeHall.lg8l.Esunlibrodetextoclsico

que hace una introduccin a 1a gestin de proyectos' Est bastante

desf.asaclo.yaqueprestaespecialatencinalmodelodeciclodevida .n .arcudu y a miodos de rlesarrollo dirigidos por documentos..Pero

alguienqu.l.oellibroconintencindesercrticoencontrarque
Metzgerantienecosasimportantesquedecirsobrelosproyectosde hoy. y adems lo dice bastante bien'
proyectos Aunque el libro siguiente no trate especficamente sobre sofilvare, puecle ser dc inters comentarlo' Random House' Grove, Andrerv S.: High Otptrt Managemen 1' New'York: de Intel y tiene.grandes 1983. Andy Grove es uno de los fundadores

conocimientossobrecomogestlonarunacompaaenunaindustria de tcnica competitiva. Grove uru un enfoque altamente cuantitativo la gestin.

4.2. Bases tcnicas

moUn estudio realizado en 1984 sobre <Mtodos de programacton gran clernos> (bases tcnicas) comprob que no se puede alcanzat,una 4'2 muestra los resultados del frocluctividad sin utilizarlos. La Figura estudio. <Errores Es el mismo tipo de grfico que se present en el captulo mensaje La aplicacin de las bases clsrcos>. y nos muestrull -it-o productividad' tcnicas. pr s sola. no es suficiente para obtener una alta mtodos de programacin modernos Hay aigunos proyectos que utilizan que no los .o,i g.in detaile. , obtienen la misma productividad que otros necesarias' pero no suficientes' Esto nos indica que las bases son

utiliian.

para conseguir un desarrollo rpido' ' Lu..y c]onstantine cuenta una historia sobre el concurso de Software

delaAustralianComputerSociety(Constantine.l995b).Elconcursoconpara desarrollar y sisti en llamar a equipos formados por tres personas 6 horas' entregar una aplicacin de 200 puntos dc funcin en

Captulo 4: Bases del desarrollo de software

Uso de tcnicas modernas de programacin (porcentaje del sistema total) P^r.t2i rl

69

a planificacin
nomlnal +200

Baja (o-25%)

Media (26-75%)

Alta (76-100%)

Leyenoa
+1

00

0 (meda)

l-l Mximo del 75'" Prcentil I ."'".Jnt" | lN/linimo o"r zt'" I

_1 00

Figura 4.2. Resultados del factor .Uso de los mtodos de programacon modernos" (Vosburgh el al., 1984). No se puede alcanzar Ia productividad mxima sin utilizar "los mtodos modernos de programasis', Que en este captulo se denomnan "bases tcnicas,.

El equipo de Ernst y Young decidi seguir una metodologa de desarrollo formal. una versin reducida de la metodologa que acostumbraban a seguir: completa con actividades por etapas y entregas intermedias' Su propuesta incluy un cuidadoso anlisis y diseo, parte de 1o que se describe en este captulo como bases tcnicas. Muchos de sus competidores se rnetieron de lleno en la codificacin, y en las primeras horas. el equipo de E,rrrst y Young se qucd atrs. Sin embargo. al medioda el equipo de Ernst y Young era el eqtripo
dominante. Al terminar el da. este equipo perdi, pero no fue debido a su metodologia formal. Perdieron porque sobreescribieron accidentalmente algunos de 1os archivos. entregando lrlenos funciones al final del da de 1as que haban dernostrado que tenan a la hora del almuerzo. De forma irnica. lo que les hubiera salvado no era el habcr sido rnenos formales. sino el haberlo sido ms: es decir, la gestin de configuracin formal incluye copias de seguridad peridicas. Ellos se dejaron engaar por el error clsico de no utilizar un control efectivo del cdigo fuente. El mensa.je de esta historia parece suficientemente claro, pero algunos escpticos" incluyndorne a mi. quedaron sorprendidos: Realmente, ,debera el equipo de Ernst y Young haber garrado si tro hubiera sido por el embrollo de la gestin de la configuracin'? La respuesta es <s>. Reaparecieron unos rrleses ms tarde en otro concurso de desarrollo rpido (esta vez colr control de versiones y haciendo copias de seguridad) y ganaron (Constantine. 1996). En este caso. las metodologas formales merecieron 1a pena en un solo da. Si prestando atencin a las bases tcnicas se puede conseguir esta

70

Desarrollo y gestin de proyectos informticos

dif-erencia en esta canticlrd de tiempo. irragincn la dif-erencia que puedc haber en un nro\/ecto de 6 a l2 rneses.

Gestin de requerimientos
REFERENCIA CRUZADA Para ms informacin sobre los mtodos tradicionales de la gestin de requerlmientos, vase

e Capitulo 14, "Controi del conlunto de prestac ones..

DATOS REALES

FEFEFENCIA CRUZADA Para ms rnformacin sobre ei control de

an Ire ^r^hlam.< nretr. \/orca It ^nac

La gcstitirr de reqtrclirtticr'rl()s cs cl ploceso rluc c()l):istc cn leunir reqtrericn un documento. corrco clcctrnico. cuaderno dc interf-az dc usuario. prototipo e-jccutable o cualquier otro fbrmato: hacer un scguir.niento del disco y del cdigo; y gcstionar los car.nbios para cl restcl dcl proyecto. E,s r.nr-ry cornirn que los clesarrolladorcs se laurellten de los problerras rsociados a los rntodos de gestirr dc requerimientos tradicionalcs, sienc1o la rnayora cle cllos demasiado rgidos. Algunos rrtodos pucdcn ser denasiado rgidos. pero la altcrnativa que clfreccn suele ser peor. Un estuclio realizado en rns de 8.000 proyectos encontr que las tres razones principales por las que los proyectos cran entregados tarclc. por cncinra del prcsu-rucsto y cou nleuos firncionaliciacl dc la que se esperaba eran debiclas a los r.ntodos cle gestin de requerirlientos: falta de inforrnacin del usuario. rcquerimientos incompletos y cambios en los requerinrientos (Standish (iroup. 1994). Un estuclio realizado por cl Instituto de Ingcnicra del Sofir.vare lleg a la r.nisma conclusin: rrs dc la mitad de los proyectos quc se estudiaron tur,ieror.l una gestin inadccuada de los requclimientos (Krtson y Mastcr. 1993). E,l rito en la gestin de requerimicntos dependc dcl conocimicnto de suficientes r.ntodos difcrcntes. de tbrma que sea posiblc escoger los rna-s apropiados para un proyecto espccl-ico. A continuacicir.r sc rnilcstran la,s busc. dc llr ecstin dc reqtrcrirrricnlos:
r.r.ricntos: plasnrallos

Secc n 1 4.2. ,,Proyecto avanzado. control de camblos de

Irc roeie.i^na<,

o o

Metodologas de anlisis dc re querir.r.rientos. inclr.ryendo anlisrs cstructurado, anlisis estructurado de datos y anlisis oricntado a
ob.jetos.

Mtodos para crcar el modelo del sistcma. como diagramas de clascs. cliagramas dc 11Lrjo cle datos. diagranas enticlad-re lacin. notacitrn del diccionario de datos v diagrarnas de estado-transicin. Mtodos de comunicacin. como el Dcsarrollo Conjr.rnto cle Apli-

caciones (JAD). prototipaclo de la illterfaz de usuario y mtodo. genL'l'illcs de entrcr islas. Las relaciones entre la gcstin de requerimientos y los difclcntc. nrodelos ciel ciclo de r ic1a. incluyendo el prototrpado clolutir,o. 1 entrega por etapas. cspiral. cascada y codificar y corrcgir.

Lir gcstirt dc r'.'querinricrrttls propoleiona de clos fornlas dil'erent;Llna gran influcncia en la velocidad de dcsarroilo. En primer lugar. la recogida de requerimientos cs tur paso que tiende a hacerse sin prisas. conr-

Captulo 4: Bases del desarrollo de software

::::trN^l .: 7A

71

:: --:'-acton .: :: :: On de - :.::S VASE ::: ' -:C On de - :-'t,r. en la ::-: on 6.5.

-:

a=ALES

parado con otras actividades del desarrollo del software. Si esre paso se acelera sin perjudicar a la calidad. se puede disminuir en conjunro cl tiempo de desarrollo. En segundo lugar. obtener un requerimiento collro es dcbido en cl primcr paso non.nalmente cLlesta de 50 a 200 r eccs lDcnos quc si se espera a las 1'ases dc construccin o mantenimiento (Boehrn y papaccio. 1988). Un proyecto nomral tiene un 25 por 100 dc caurbios en los requerirnientos. Algunos mtodos de gestin de requerimientos pen.niten reciucir cl nmero de calnbios. Otros nltodos de desarrollo permiten reducir el costc de cada cambio en los reqr.rerin.rientos. Ima-uine el efecto cornbinaclo que ploducir'a por un lado reducir el nrero dc cambios de un 25 a un l0 por 100. y simultnearnente reducir el coste de cacla cambio en r-rn f'actor de 5 o 10. El desarrollo rpido podra estar a su alcance.

Diseo
Del misn-ro n.rodo quc tiene sentido crear una serie de bocctos antes cjc construir una casa" tiene sentido cfear una arquitcctura y un diseo antes dc construir un sistema softw'are. Un error de disco que no se detecta hasta la fase de comprobacin. necesita l0 r,eces rns tiempo para arrcglarlo quc si se detectara en la fase de disco (Dunn, 198.1).
es quc
,Est preparado cualquiera para hacer un bucn diserlo'l No. Mi opinin cl buen diserlo es un ter.na de convcrsacin comn cn el desarrollo

ciel sofln'are,y que realmente pocos desarrolladores haccn argo cle diseo. Un discador que trabajaba para Microsoti dijo que en 6 aos de en-

trevistar a nrs de 200 candidatos para cl puesto cle dcsarrollador del

sofirvare. slo haba entrcr"istado a 5 quc pudicran ciescribir exactanrcute

los conceptos de <r'r.rodularidacl> y <<ocultar.ricnto de infrlrmacin> (Kohen.1995). Los conccptos de rnodularidad v ocultamiento de informacirin son las
bascs del diseo. Ar.nbos son parte de las bascs del disco estructuraclo 1, del diseo orientado a objetos. Un desarrollador que no puecie cliscutir sobrc los conceptos de modularidad y de ocultamiento dc informacir.r es couro unjugador dc baloncesto qLle uo sabe regatear con cl baln. cuanclo consideramos quc Microsoft examina rigurosarncnte a sus candidatos. incluso antes de que seau entrevistados. llegamos a la cspantosa conclusin de

que Ia situacin cn el r.nundo dcl desarrollo del sofi'ur.'are cst considerablemente peor de lo quc se crea. que de 200 desarrolladores. 195
ticnen lagunas importantes en sus conocimientos soblc las bases del diserio. A contiuuacin se muestran los tenras bsicos sobre la arquitectr-rra y

el diserlo:

Principales estilos de dise'o (como cl cliserlo orierrtado a objetos, diseo estructurado. diseo orientado a la cstructnra dc datos).

72

Desarrollo y gestin de proyectos informticos

Conceptos fundamentales del diseo (como ocultanriento de infbrmacin, modularidad, abstraccin. encapsulacin, cohesin, asociacin. jerarquia. herencia. polimorfismo, algoritmos bsicos y estructuras de datos bsicas). Enfbques de diseo estndar en reas generalmente duras (incluyendo manejo t1e excepciones. intenlacionaIizacin y localizacin. portabilidad, almacenamiento de cadenas. entrada/salida, gesti' de memoria, almacenantiento de datos. aritr.t.ltica en punto flotante. diseo de bases de datos, rendimiento y reutilizacin). Consideraciones dcl diseo propias del dominio de la aplicacin en la que se est trabajando (aplicaciones financieras, aplicaciones cientficas, sistenras <empotrados>, sistemas en tiempo real, softll'are de seguridad crtica y otros). Esquernas de arquitectura (como organizacin de subsisternas, niveles, estilos de comunicacin de subsistemas y arqLritectura tpica de sistemas). Uso de herramientas de diseo.
REFERENCIA CRUZADA Para obtener ms detalles sobre un tipo de diseo bien adaptado a los proyectos de desarrollo rpido, vase el Captulo 19,,,Diseo para el cambio".

Es posible desarrollar un sistema sin disearlo prir.ncro. Los principales sistemas se han implementado a travs de una codillcacin completa r una habilidosa depuracin, gran entusiasmo y mucho ms tiempo clel csperado (y sin diseo sistemtico). Sin embargo, el diseo es la base de l

construccin, planificacin. seguimiento y control del proyecto, y ese diseo efectivo es imprescindible para conseguir la velocidad rnxima d.. desarrollo.

Construccin
En cl monrento en que se llega a la construccin, ya se ha llevado a cabo i.. mayor parte del trabajo para el xito o fiacaso del proyecto. Tanto la gestir.: de requerimientos como el diseo ofrecen una mayor influencia en la p1.-

nificacin del desarrollo que la construccin. En estas actir,'idacles.

lt.

cambios pequeos pueden n-rarcar una gran diferencia en la planificaclo j: En la planificacin. la construccin no ofrece muchas oportunidacle . de reduccin, pero el trabajo de construccin es tan detallaclo y laborio.

quc es importante hacerlo bien. Si en un principio la calidad del c digo no es ptirna. es casi imposible volver hacia atrs y rrejorarla. Re" mente no es efectivo hacerlo dos vcces. Aunque la construccin es una actividad de bajo nir.'el, se presenr.l posibilidad de perder el tiempo en cosas poco eficientes o cle clespista:.en tareas que, aunque no son crticas, consufilen tiempo. por ejerl. se puede perder el tiempo en funciones que no tienen que ser brillanr... depurar cdigo intil o ejecutar con esnero pequeas secciones del sis -. ma antes de saber si realntente es necesario afinarlas.

74

Desarrollo y gestin de proyectos informticos

para usted en este equipo. ya que hay bastantes mdulos que tienen demasiados fallos y tienen que volver a escribirse.> Esta frase delata a una persona que an no comprende por qu requiere tanto tiempo realizar un proyecto software. Cuando todo est dicho y hecho, prestar atencin a las bases de la construccin es tanto un mtodo de gestin de riesgos como un mtodo de ahorro de tiempo. Las buenas construcciones previenen la creacin de un nido de ratas de cdigo indescifrable, que hace que el proyecto se pare lenta y ruidosamente cuando una persona cae enferma, cuando se descubre un fallo crtico, o simplemente cuando se necesita hacer un cambio. Estos mtodos mejoran las previsiones y el control que se tiene sobre el proyecto e incrementan la probabilidad de entregarlo a tiempo'

Gestin de la configuracin del software

La gestin de la configuracin del software (SCM, Software configu.ulion Management) es un mtodo de gestin de los <artefactos> del proy.ato. de forma quc el proyecto permanezca cn un estado consistcnte todo el tiempo. SCM incluye mtodos para evaluar los cambios propuestos, seguir los cambios, manejar varias versiones y guardar copias de ia evolucin de los artefactos del proyecto. El artefacto del proyecto ms controlado suele ser el cdigo fuente, pero puede aplicar SCM a los requerimientos, planes, diseos, casos de prueba, informes del problema. documentacin del usuario, datos y cualquier otro elemento que se utilice para constrlrir el producto. Yo incluso utilic SCM para escribir este libro, ya que el no utilizarlo en mi ltimo libro me caus demasiados problemas. La mayora de los libros de desarrollo del softu'are consideran la SCM como un mtodo de garanta o control de calidad, y tiene un efecto bastante fuerte sobre la calidad. Pero el tratarlo como un mtodo de control de calidad podra implicar que tiene un efecto neutro o negativo en la plani-

ficacin del desarrollo. A veces. la SCM se implementa de forma que disminuye la eficiencia, pero es crtica en el caso de que se desee alcanzar la mxima velocidad de desarrollo. Sin la gestin de la configuracin, los
compaeros de equipo pueden cambiar parte del diseo y olvidarse comentarlo a los dems. Entonces, se puede implementar el cdigo de forma in-

compatible con los cambios efectuados en el diseo, de forma que bierl

uste o sus compaeros de equipo tendran que rehacer de nuevo el traba.1o. La falta de control automtico sobre el cdigo fuente es bastante comn e ineficiente. En las organizaciones analizadas entre 1987 y 1993. el Instituto de Ingeniera del Software encontr que rns del 50 por 100 nemejorar la gestin de configuracin del software (Kitson r

ERROR CLASICO

cesitaban Masters, 1993). En los proyectos pequeos, la carencia de 1a gestin d.' configuracin aumenta un poco el porcentaje del coste del proyecto. Erl

Captulo 4: Bases del desarrollo de software

75

grandes proyectos, la gestin de la configuracin es un elemento del canrino crtico (Jones. 1994).

Bibliografa adicional sobre las bases de desarrollo

Muchas organizaciones de formacin ofrecen cursos sobre anlisis de requerimientos y diseo. Los cursos sobre construccin y gestin de la configuracin son ms difciles de encontrar. La mayor parte de las fuentes de infonnacin disponibles sobre alguno de estos temas probablemente se cncuentran en los libros, as que a continuacin se enumeran los meores libros de cada uno de los ternas.

Gestin de requerimientos Yourdon, Edward: Modern Structurecl Anctlysis. New York: Yourdon Press. 1989. El libro de Yourdon contiene un estudio sobre la especificacin de los rcquerimientos y el anlisis hacia el ao 1989. incluyendo

herramientas de modelizacin, proceso de recogida de requerimientos y temas relacionados. Observe que una de las secciones ms interesantes se encuentra oculta en un apndice: <Tcnicas de entrevista y

recopilacin de datos>. Hatley, Derek J., y ImLtaz A. Pirbhai: Strateges .f'or Reul-Time St;stent Specificatictn New York: Dorset House Pubhshing, 1988. Hatley y Pirbhai prestan especial atencin a los sistemas en tiernpo real, y extienden la notacin grfica utilizada por Yourdon al entorno en tiempo real. Gause, Donald C., y Gerald Weinberg: Explorng Requirements: Qttalin, Before Design. Nerv York: Dorset House, 1989. Gause y Weinberg
presentan un curso poco comn en el terreno de la gestin de requerimientos. Trata sobre la ambigedad, reuniones, resolucin de conflic-

tos, represiones, expectativas. razones por las que las metodologas no son suficientes y otros temas. E,llos evitan principalrnente los temas que incluyen otros libros de requerimientos y tratan los temas que otros libros evitan.

Diseo
Plauger. P. J.'. Prograntnting on Purpose.' Essa-r'.r on So.fiv'are Design. E,nglewood Cliffs, N.J.: PTR Prentice Hall, 1993. Es una coleccin reconfortante de ensayos que fueron originalmente publicados en la revista Computer Language. Plauger es un gran diseador que se dedica a una sran variedad de tenas relacionados tanto con ser disea-

76

Desarrollo y gestn de proyectos informticos

dor como con el diseo en abstracto. Se extiende libremente por todo el mbito del diseo. y no se restringe exclusivamente a un estilo de diseo; esto es lo que hace que 1os ensayos sean tan reconfortantes. E,ste resultado es nico en su mbito y provocatlor. Mcconnell, Steve: code Complete. Redmond, wash.: Microsoft press. 1993. Este libro contiene varias secciones que tratan sobre el diseo, particularmente el diseo relativo a la construccin. Al igual que el libro de Plauger. describe varios estilos de diseo. Yourdon. Edward, y Larry L. constantine: structurecr Design; Fundamentals o/'a Discipline of'Computer Prograrn and svstents Design. Englewood cliffs, N.J.: Yourdon press, 1979. ste es un rexto clsico sobre el diseo estructurado creado por uno de los coautores (constantine) del artculo original. El libro est escrito con sumo cuidado. contiene temas completos sobre acoplamiento, cohesin, notaclones grficas y otros concepros importantes. Algunas personas han catalogado este libro como <tcnicamente difcil>, pero es muy difcil ensear un mtodo mejor que sus inventores originales. Page-Jones, Meilir: The Practical Guide to srructurecl svsents Design, 2d Ed. Englewood Clifls. N.J.: yourdon press, l9gg. Es un libro*de texto muy conocido que presenta el mismo contenido sobre el diseo estructurado que el libro de Yourdon y constantine y se escribi con un considerable entusiasmo. Algunas personas han encontrado el libro de Page-Jones ms accesible que el de yourdon y Constantine. Booch, Grady: object oriented Analt,si.s ancl Design; with Apptications. 2d Ed. Redwood City. Calif.: Benjamin/Cr-n-'ingr, tgg4'.'El libro de
Booch trata sobre los fundamentos tericos y prcticos del diseo orientado a objetos en ms de 300 pginas, y luego tiene 175 pginas ms sobre el desarrollo de aphcaciones orientadas a objetos en c++. Nadie ha hecho una defensa ms activa sobre el drseo orientado a objetos que Grady Booch, y es el volumen definitivo sobre el tema. coad, Peter, y Edward Yourdon: object-orientecl Design E,nglewoocl Cliffs. N.J.: Yourdon Press, 199 l. sta es una alternativa ms ligera al libro de Booch, y algunos lectores podran encontrarla como una introduccin ms sencilla sobre el diseo orientado a obietos.

Construccin
Mcconnell, Steve: Code Complete. Redmond, wash.: Microsoft press, 1993. ste es el nico libro conocido que trata sobre todos los temas claves
en la construccin, identificados en la seccin <Construccin>. Contiene listas de control de gran utilidad en algunos aspectos de la construc-

cin, as como datos que hacen ms efectivos los mtodos de construccin. El libro contiene varios cientos de ejemplos de cdigo en c.
Pascal, Basic, Fortran

y Ada.

Captulo 4: Bases del desarrollo de software

77

Marcotty. Michael: Sofhrare Intplementatior. NewYork: Prentice Hall, 199 l. E,ste libro trata sobre temas generales involucrados en la construccin del software. prestando especial atencin a la abstraccin, complejidad, legibilidad y correccin. La primera parte del libro trata sobre la historia de la programacin, sr"rbcultura, equipos de programacin y cmo reparten el tiempo de forma general. El libro est escrito con ingenio y estilo. y especialmente las primeras 100 pginas sobre <el negocio de la programacin> estn muy bien hechas.

Los dos libros de Bentley que vamos a ver a continuacin tratan el tema de 1a programacin y explican claramente las razones por las que hay personas que consideran la programacin colo un tema muy interesante. El hecho de que la informacin no sea de fcil comprensin o no est rigurosamente organizada no evita que los libros traten unas ideas muy significativas, las cuales se leern en unos pocos rninutos y se utilizarn durante aos.

Bentley, Jon Programnting Pearls. Reading, Mass.: Addison-Wesley,

I

986.

Bentley. Jon: More Programnting Pearls: Confbssions o/'o Coder. Reading" Mass.: Addison-Wcsley, 1988. Maguire, Steve: I4lriling Solid Crde. Redmond. Wash.: Microsoft Press,
1993. Este libro describe los mtodos claves de construccin softwarc utilizados por Microsoft. Explica cmo minimizar los errores utilizando avisos (v'arnings) de compilacin, protegiendo el cdigo con sentencias de afirmacin, fortaleciendo los subsistemas con pruebas de integridad. diseando funciones de interfaz no ambiguas. comprobando el cdigo con un depurador y evitando los mtodos de progra-

rnacin peligrosos.

Gestin de la configuracin del software (SCM)

Estos libros de Bersoff y Babich tratan en profundidad los temas de SCM.

Bersoff, Edward H., et al.: Sofitt'ctre Configuration Manugemenl. E,nglewood Cliffs. N.J.: Prentice Hall. 1980. Babich, W.: So./lv'are Configuration Mttnogerel. Readiug. Mass.: Addi-

son-Wesley. 1986. Bersoff, Edward H., y Alan M. Davis: <lmpact of Life Cycle Models on Software Configuration Managemenf>, Contmunications o/' the ACM 34, nm.8 (August 1991):104-118. Estc artculo describe cnro la SCM est influenciada por las nuevas aproximaciones al dcsarrollo dei software, especialmente por el prototipado.

Desarrollo y gestn de proyectos informticos

4.3. Bases del control de calidad

Al igual que las bases de gestin y tcnicas, las bases dcl control
de ca-

lidad proporcionan un apoyo fundamental para obtener la mxima velocidad de desarrollo. Cuando un producto software tiene demasiados errores, los desarrolladores emplean ms tiempo corrigiendo e1 software que escribindolo. Muchas organizaciones han descubierto que todo funciona mejor si no se cometen los errores en el primer paso. La clave principal para no cometer errores es prestar atencin a las bases del control de calidad desde el primer da.

Algunos proyectos intentan ahorrar tiempo reduciendo el tiempo

que emplean en los mtodos de control de calidad. como en el diseo y en

las revisiones del cdigo. Otros proyectos (que van retrasados) intentan

ERROR CLASICO

recuperar el tiempo perdido reduciendo la planificacin de la prueba. lo cual es bastante sensible a la reduccin porque normalmente es el elemento del camino crtico al final del proyecto. Estas son algunas de las peores decisiones que una persona que desea maximizar la velocidad
de desarrollo puede tomar, porque al aumentar la calidad (desde el punto de

vista de menor tasa de dcfectos) se reduce el tiempo de desarrollo. La Figura 4.3 muestra la relacin entre la tasa de defectos y el tiempo de
desarrollo.
Pocas son las organizaciones que tienen una tasa de defectos extremadamente baja (mostrada en el extremo derecho de la curva de la Figura 4.3). en cuyo punto, la reduccin adicional del nmero de defectos incrementar la cantidad de tiempo de desarrollo. El tiempo extra es ne-

La mayona de organizacones se encuenlran alrededor de este punto

Tiempo de

desarrollo

Porcentaje de defectos suprimidos

Fuente: Datos extrados de Applled Software Measurement(Jones, 199'1).

=95%

100%

Figura

4.3. Relacin entre la tasa de defectos y el tiempo de desarrollo. En la mayora de los casos, los proyectos que se llevan a cabo con una tasa de defectos ms baja tambin tienen una planificacin menor.

Captulo 4: Bases del desarrollo de software

7g

cesario cuando se aplica a sistemas crticos para la vida, tal como 10s sistemas de soporte vital de una lanzadera espacial, pero no cuando se aplica a desarrollo de software no crtico para la vida.

IBM fue la primera compaa en descubrir quc la calidad y la planificacin del software estaban relacionadas. Tambin descubrieron que los productos con menor nmero de defectos eran los que tenan una menor planificacin (Jones, 1991). En la actualidad, muchas organizaciones han desarrollado software con un nivel de defectos que le asigna una planificacin mayor de la necesaria. Despus de realizar un estudio de ms de 4.000 proyectos software, Capers Jones informa que una caiidad baja es una de las principales razones del retraso en la planificacin (Jones , 1994). Tambin dice que la baja calidad es una de las razones por las que se cancelan ms de la mitad de los proyectos. Un estudio del Software E,ngineering Institute descubri que un 60 por I 00 de 1as organizaciones tenan un control de calidad inadecuado (Kitson y Masters, 1993). En la curva de la Figura 4.3, estas organizaciones son las que estn al lado izquierdo de la 1nea que indica el 95 por 100. Algunos puntos alrededor del 95 por 100 son significativos por-]S
REALES

que ese nivel de supresin de defectos parece ser el punto en donde los proyectos generalmente alcanzan la planificacin ms baja, el menor esfuerzo y el nivel ms alto de satisfaccin del usuario (Jones, 199 1). Si despus de lanzar el producto se tienen ms de un 5 por 100 de def'ec-

tos, ser vulnerable a los problemas asociados a una calidad baja, y probablemente se tardar ms tiempo del necesario en desarrollar el
software.

::

OR CLASICO

Los proyectos que se realizan con prisas son particularmente vulnerables a engaos en cuanto al nivel de calidad del desarrollador. Cuando se tienen prisas, se hacen recortes porque <slo faltan 30 das para la entrega). En vcz de escribir un mdulo de impresin completamente distinto, se hace a partir del mdulo de visualizacin en pantalla. Se sabe que el diseo es malo, que no es ampliable o de mantenimiento fcil, pero no hay tiempo para hacerlo bien. Se tienen prisas por termlnar el producto. de fbrma que uno se siente obligado a tomar el camrno ms corto. Tres mescs ms tarde, el producto an no se ha terminado, y empiezan a aparecer los problemas derivados de esos recortes. Se encuentra con que los usuarios no estn contentos con la forma de imprimir, y que la nica manera de satisfacer sus requerimientos es aumentando significativamente la funcionalidad del mdulo de rmpresin. Desafortunadamente, desde hace tres meses el mdulo de impresin y el de visualizacin en pantalla se han ido entrelazando. Redisear el mdulo de impresin y separarlo del de visualizacin es una operacin difcil, que consume tiempo y es susceptible a errores.

80

Desarrollo y gestin de proyectos informticos

El resultado es que en un proyecto que se supona que prestaba espe_ cial atencin al desarrollo de una planificacin lo ms corta posible, sc pierde el tiempo en las actividades siguientes:

ya que la mayora del cdigo se desechar. El tiempo que se ent_ ple cn la prueba y la depuracin del mdulo de impresin tambi.

Perder el tiempo en disear e implementar el mdulo de impresin.

sr.'

desperdici.

El tiempo adicional que se debe emplear en separar el mdulo de impresin del mdulo de visualizacin por pantalla. Se debe emplear tiempo de prueba y depuracin adicional en asegurar que el cdigo de visualizacin que se ha modificado sigue funcionando despus de separarlo ilel mdulo de impresin.
El mdulo de irnpresin, que debera haberse diseado como 'uevo una parte integral del sistema, se ha diseado fuera del sistema exlstente. no siendo sta la forma de diseo que se tena pensada.

DATOS REALES

DATOS REALES

Todo esto sucede, cuando el nico coste necesario (si se hubieran tomado las decisiones apropiadas en el momento correcto) era el diseo e implementacin del mdulo de impresin. Este ejemplo es bastante comn. El nmero de defectos que se presentan cuando los programadores lanzan productos bajo una excesiva presin en la planificacin es hasta cuatro veces mayor (.rones. 1994). En losproyectos que tienen problemas de planificacin, se suelen obsesionar por trabajar ms duro, en vez de trabajar de forma ms ingeniosa. prestar atencin a la calidad es como si fuera un lujo. El resultado es que los proyectos suelen funcionar mal, dando lugar incluso a problemas graves de planificacin. Decidir al inicio del proyecto no centrarse en la deteccin de errores equivale a la decisln de posponer la deteccin de defectos hasta mas tarde. cuando ser mucho ms cara y consumir tiempo. No es una decisin racional cuando el tiempo apremia. Si se pueden prevenir o detectar los defectos y eliminarlos pronto, se obtiene una ventaja significativa en la planificacin. Los estudios han demostrado que revisar errores de requerimientos, diseo y cdigo norrnalmente consume del 40 al 50 por 100 del coste total del desarrollo del softvu'are (Jones. 1986b; Boehm, 1987a). como regla emprica, cada hora que se emplea en prevenir defectos reduce el tiempo empleado en la recuperacin de 3 a 10 horas (Jones, 1994). En el peor caso. revisar un problema de requerimientos software, una vez que el programa est ejecutndose, normalmente cuesta de 50 a 200 veces ms de lo que costara revisar el problema cuando est en la fase de requerimientos (Boehm y Papaccio, 1988). Dado que ms del 60 por 100 de los errores se dan en tiempo de diseo (Gilb, 1988), se pueden ahorrar grandes cantidades de ticmpo detectando los errores antes de hacer la prueba del sistema.

Capitulo 4: Bases del desarrollo de software

81

En este libro se hace referencia a muchas ratios de coste, y como algunos de los valores son similares, las diferencias pueden llevar a confusin. A continuacin se muestra un resumen:

r r r

Cada hora que se emplea en las actividades de control de calidad, como son las revisiones de diseo, ahorra de 3 a 10 horas en el coste total. Un defecto en los requerimientos que no se detecta hasta la construccin o el mantenimiento necesitar una correccin que costar de 50 a 200 veces ms que si se hubiera hecho en la fase de reque-

rimientos. De forma ms general, un defecto que no se detecta al inicio (durante la fase de requerimientos o diseo) necesitar para su correccin de 10 a 100 veces ms esfuerzo al encontrarlo al final (durante la prueba) de 1o que habra costado corregirlo al principio. Al detectar un error, cuanto ms tiempo haya pasado desde el inicio, ms costar corregirlo.

Mdulos propensos a errores

Un aspecto particularmente inrportante sobre el control de calidad. en cuanto al desarrollo rpido, es la existencia de mdulos propensos a errores. Un mdulo propenso a errores es un mdulo responsable de un
nmero desproporcionado de defectos. Por ejemplo, en su proyecto IMS.

-:

S REALES

IBM descubri que el 75 por 100 de los errores se agrupaban en el

7 por 100 de los mdulos (Jones. 1991). Barry Boehm infbrma que sobre el 20 por 100 de los mdulos en un programa son norntalmente responsables del 80 por 100 de los errores (Boehm, 1987b). Los mdulos con tasas de defectos elevadas son ms costosos y consumen ms tierrpo para ejecutarlos que los mdulos menos propensos a errores. El desarrollo de mdulos normales cuesta de 500 a 1.000 dlares porpunto de funcin. Los mdulos propensos a errores cucstan de 2.000 a 4.000 dlares (Jones, 1994). Los mdulos propensos a errores tienden a ser ms complejos que los dems mdulos del sistema, menos estructurados e inusualmente grandes. Suelen desarrollarse bajo una fuerte presin de planificacin, y no suelen estar completamente probados. Si la velocidad de desarrollo es importante, identificar y redisear los mdulos propensos a errores es prioritalio. Si la tasa de errores de un mdulo alcanza los l0 defectos por cada l00lneas de cdigo, habr que revisarlo para determinar si debera volverse a disear o implementar. Si el mdulo est mal estructurado, es excesivamente compleio o lareo. ha-

82

Desarrollo y gestin de proyectos informticos br que volverlo a disear e implementar desde el inicio. Se ahorrar tient,

y se mejorar la calidad del producto.

Prueba
El mtodo ms comn de control de calidad es indudablementc la prueba d; ejecucin: encontrar crrores al ejecutar el programa y ver lo que hace. La. dos clases ms comunes de pruebas de ejecucin son las pruebas indil,iduales, en las cuales el desarrollador comprueba su propio cdigo para verificar que funciona correctamente, y las pruebas del sistema, en las que un probador independiente comprueba si el sistema funciona como se esperaba La eficacia de las pruebas vara enormemente. La prueba individua. puede encontrar del 10 al 50 por 100 de los defectos en un programa. \ laprueba del sistema del 20 al 60 por 100. Al unir las dos, la tasa acumulada de la deteccin de defectos suele ser menor del 60 por 100 (Jones, 1986a). Los errores que no se localizan se pueden encontrar por otras tcnicas de deteccin de errores. como las revisiones o los usuarios finales, despus de que el software se haya puesto en funcionamiento. La prueba es la oveja negra en lo que respecta a los mtodos de control de calidad, y en lo que respecta a la velocidad de desarrollo. Realmente se puede hacer tan mal como para retrasar la planificacin de desarro1lo, pero su efecto en la planificacin suele ser indirecto. La prueba descubre que la calidad del producto es demasiado baja para lanzarlo. y el producto tiene que retrasarse hasta que se pueda rnejorar. De esta manera. la prueba se convierte en el mensajero que comunica las malas noticias que afectan a la planificacin. La mejor forma de fomentar la prueba, desde el punto de vista del desarrollo rpido, es preparar un plan antes de obtener las malas noticias: establecer la prueba de forma que si se dan malas noticias, la prueba permita lanzar el producto tan pronto como sea posible.

DATOS REALES

Revisiones tcnicas
Las revisiones tcnicas incluyen toda clase de revisiones que se utilizan para detectar defectos en requerimientos. diseo, cdigo, casos de prueba o cualquier otro artefacto del proyecto. Las revisiones varan en cuanto al nivel de formalidad y eficacia, y juegan un papel ms crtico en la velocidad de desarrollo que las pruebas. Las secciones siguientes resumen los tipos de revisiones ms comunes.

Reuniones
DATOS REALES

Las reuniones informales son el tipo ms comn de revisin. El trmino <reunin> se define aproximadamente y se refiere a cualquier reunin en

Captulo 4: Bases del desarrollo de software

83

la que dos o ms desarrolladores revisen el trabajo tcnico con el objetivo .1e r.t.rejorar su calidad. Las reuniones son tiles para el desarrollo rpido, porque se pueden utilizar para detectar errores antes de la prueba. Por elemplo. en el caso de que la prueba pueda detectar un defecto en los

requerimientos,
diseado

lo har despus de quc stos se hayan especificado, y codificado. Una reunin puede detectar un defecto en los

requerimientos. en tiempo de especificacin, antes de que se realice el rirseo o se codifique. Las reuniones pueden encontrar entre el 30 y el 70 por 100 de los errores en un programa (Myers, 1979; Boehm, 1987b; Yourdon.1989b).

Lectura del cdigo

La lectura del cdigo es un proceso de revisin ms formal que una

reunin, pero normalmente slo se aplica al cdigo. E,n la lectura del cdigo. el autor del mismo distribuye listados del cdigo fuente entre dos o ms revisores. Los revisores leen el cdigo e informan de cualquier error al autor del cdigo. Un estudio en el Laboratorio de Ingenieria del Softn'are de la NASA descubri que la iectura del cdigo detcctaba dos veces ms cantidad de defectos por hora de esfuerzo que la prueba (Card, 1 987). Esto sugiere que en un proyecto de desarrollo rpido, la combinacin de lectura del cdigo y prueba sera ms efectiva para la planificacin que solamente la prueba.

Inspecciones

-Mr,

?*' &

4F+
::::'.:lA _: _::lA . ::-_en
:1, : :3 i : :::l
aS

. \F

-.: -.23. :;:: _^es,,.

- :

==ALES

Las inspecciones son un tipo de revisin tcnica formal, que ha demostrado scr extremadamente efectivo en la deteccin de errores en un proyecto. Con las inspecciones, los desarrolladores reciben una preparacin especial y juegan un papel especfico durante las mismas. E1 <moderador> se vuelca en trabajaren el producto para inspeccionarlo antes de la reunin de inspeccin. Los <revisores> examinan el producto antes de la reunin y utilizan listas de control para estimular su revisin. Durante la reunin de inspeccin, el <autor>> normalmente comenta el material inspeccionado, los revisores identifican los errores y el <secretario> guarda los errores. Despus de la reunin, el moderador genera un informe sobre la inspeccin, describiendo cada uno de los defectos e indicando lo que se har con ellos. A 1o largo del proceso de inspeccin, se recogen datos sobre defectos, se emplean horas corrigiendo estos defectos, y se emplean horas en las inspecciones, de forma que se pueda analizar 1a efectividad del proceso de desarrollo del software y mejorarlo. Al igual que en las reuniones, las inspecciones se pueden utilizar para detectar defectos tan pronto como colt la prueba. Se pueden utilizar para detectar errores en requerimientos, prototipos de interfaz de usuarios. diseo.

Desarrollo y gestin de proyectos informticos

cdigo y otros artefactos del proyecto. Las inspecciones encuentran de un 60 a un 90 por 100 de defectos en un programa, lo cual es considerablemente mejor que las reuniones o las pruebas. Las inspecciones generan una planificacin neta, ahorrando de un I 0 a un 30 por I 00. ya que se pueden utilizar en el ciclo de desarrollo (Gilb y Graham, 1993 ). E,n un estudio realizado sobre un programa grande, se encontr que cada hora empleada en las inspecciones produca una media de 33 horas de ahorro, y las inspecciones eran 20 veces ms eficientes que las pruebas (Russell, 199 l).

Comentarios sobre las revisiones tcnicas

Las revisiones tcnicas son un complemento til e importante para la prueba. Las revisiones tienden a encontrar errores de tipos diferentes a las pruebas (Myers, 1978; Basili, Selby y Hutchens, 1986). Encuentran defectos ms pronto, lo cual es bueno para la planificacin. Las revisiones tienen un coste ms efectivo en la bsqueda de defectos, ya que detectan

al mismo tiempo tanto el sntoma como la causa fundamental del defecto. La prueba slo detecta el sntoma del defecto: el desarrollador an tiene que encontrar la causa en la depuracin. Las revisiones tienden a encon-

trar un porcentaje alto de defectos. Y las revisiones proporcionan un

foro para que los desarrolladores muestren sus conocimientos sobre los rntodos recomendables. aumentando las posibilidades de desarrollo rpiclo. Las revisiones tcnicas son un componente crtico de cualquier esfucrzo de desarrollo que est intentando alcanzar la planificacin ms
corta posible.

effi
4.4. No permita que le suceda esto! Cuanto ms tiempo permanezca un defecto, ms tiempo necesitar para corregirlo. Corriia los defectos oculto cuando estn en un estado inicial v son fciles de controlar.
Figura

Captulo 4: Bases del desarrollo de

software

85

Bibliografa adicional sobre los fundamentos del control de calidad

i\{uchos de los libros referenciados en otros aspectos de este captulo contienen secciones sobre aspectos generales de la calidad del software, revisiones, inspecciones y pruebas. Estos libros incluyen A manager's Guide to
So.ftware Engineering (Pressman, 1993), SoJiware Engineering: A Pracriioner's Approach (Pressman, 1992), So.fiware Engineering (sommerrille, 1996), y Code Complefe (McConnell, 1993). A continuacin se muestran las fuentes adicionales de informacin sobre temas esDecficos.

Calidad del software en general

Building Qualitv Solivrare. E,nglewood Cliffs, N.J.: Prentice Hall, 1992. Este libro examina consideraciones sobre la calidad durante todas las fases del desarrollo del software, incluyendo requerimientos, diseo, implementacin, mantenimiento y gestin. Describe y evala una gran cantidad de n-rtodos y muestra numerosas descripciones de otros libros y artculos sobre calidad del software. Chow, Tsun S., ed.: Tutorial; So.ftv,are Qualit,v- Assuranc'e: A Practical Approach. Silver Spring, Md.: IEEE Computer Society Press, 1985. Este libro es una coleccin de unos 45 artculos que tratan del tema de la calidad del software. Las secciones incluyen definiciones sobre la calidad del software, medidas y aplicaciones; directivas de planificacin, organizacin, estndares y convenios; cuestiones tcnicas sobre requerimientos, diseo, prograrnacin, prueba y validacin; e implementacin de un programa sobre seguridad y calidad del software. Contiene muchos artculos clsicos sobre este tema. v su sran tamao lo hace especialmente valioso. Prueba Myers, Glenford J.: The urt of Sofiw,are Testing. New York: John Wiley & Sons, 1979. Es un clsico de la prueba del software, y an hoy sigue siendo uno de los mejores textos disponibles. Los contenidos son claros: la psicologa y rentabilidad sobre la prueba del programa; diseo
G1ass, Robert L.:

de casos de prueba; prueba de mdulos; prueba de orden superior: depuracin; herramientas de prueba; y otras tcnicas. El libro es corto (177 pginas) y entretenido. La encuesta que incluye al principio pretende hacerle pensar como un probador y demuestra exactamente las formas en las que el cdigo puede tener defectos. Hetzel, Bill: The Complete Guide to Sofiw,are Testing, 2d Ed. Wellesley, Mass.: QED Information Systems, 1988. El libro de Hetzeles una buena alternativa al libro de Myers, ya que trata sobre el mismo tema, pero

86

Desarrollo y gestion de proyectos informticos de forma ms moderna. Adems de tratar 1o misrno que Myers, Hetzel tambin trata sobre la prueba de requerimientos y diseo, prueba de regresin. compra de software. y consideraciones de gestin. Con 284 pginas, tambin es relativamente corto, y e1 autor muestra una gran

calidad, presentando conceptos tcnicos bastante potentes.

Revisiones e inspeccones

Gilb, Tom. y Dorothy Graham: Sofiwure Inspection. Workingham, England: Addison-Wesley, 1993. Este libro hace un tratamiento mu1'
minucioso sobre las inspecciones. Tiene un enfoque prctico e incluye ejemplos de muchas organizaciones que han establecido programas de inspeccin. Freedman, Daniel P., y Gerald M. Weinberg: Handbook of Walkthroughs. Inspecions and Technical Revieu,s, 3d Ed. New York: Dorset House, 1990. Es un libro excelente en cuanto a revisiones de toda clase. incluyendo reuniones e inspecciones. Weinberg es el promotor originai de la <programacin annima>, la base de la mayora de las revisiones prcticas. Es enormemente prctico e incluye muchas listas de control tiles, informes sobre el xito de las revisiones en varias compaas, y ancdotas entretenidas. Se presenta con un formato de preguntas y respuestas.
Los dos artculos siguientes estn escritos por el desarrollador de inspecciones. Contienen lo nccesario para ejecutar una inspeccin, incluyendo los formularios de inspeccin estndares. Fargan, Michael E: <Design and Code Inspections to Reduce Errors in Program Development>>,lBM S-v-stems Journal, vol. t5, nm. 3, 197.

pp. 182-21 l.
Fargan, Michael E: <Advances in Software Inspections>>, IEEE Transuttions on Sofiware Engineering, July 1986, pp. 144-151.

4.4. Seguir las instruccones

Cuando estaba en sptimo grado, mi profesor de arte insisti en que cualquier estudiante que siguiera sus instrucciones obtendra al menos una B. sin necesidad de tener talento artstico. Era un ex marino de 120 kilos. r teniendo en cuenta que daba este aviso al menos una vez por SellsDil. \'tl estaba asombrado de cuntos alumnos del sptimo curso, de 60 kilos, no srguieron sus instrucciones y no consiguieron alcanzar una B. A juzgar po: su trabajo, no estaban atormentados por alcanzar la gloria, ni tampoco eran contrarios a su visin artstica. Ellos sentan que hacan algo diferente.

Captulo 4: Bases del desarrollo de software

87

Como adulto, suelo ver que los proyectos software fallan simplemente porque los programadores y directivos que trabajan en ellos no siguen las instrucciones. las bases del desarrollo de software descritas en este captulo. Es cierto que se puede desarrollar software sin dominar los fundalnentos, a veces incluso rpidamente. Pero a juzgar por los resultados de la mayoria de las personas, si los fundamentos no prevalecen al principio, no se tendr ei control necesario sobre el proyecto para desarrollarlo rpidamente. lncluso no se podr saber si tendr xito o fallar, hasta el final del proyecto. Suponga que va a comenzar un proyecto de pintura, y lee las instrucciones siguientes en la lata de pintura:

1. 2. 3.

Prepare la superficie: raspe la madera o el metal; ljela con suavi-

dad; quite los restos con disolvente. Prepare la superficie utilizando un producto adecuado. Despus de que la superficie est completamente seca (al menos 6 horas), aplique una capa fina. La temperatura ambiente debe estar entre l5 y 30 grados centgrados. Djela secar durante dos
horas.

4.

Aplique una segunda capa fina y djela durante 24 horas antes de utilizarla.

,Qu sucedera si no se siguieran las instrucciones'l Si va a pintar la caseta del perro un martes por 1a noche, despus del trabajo, slo tendra dos horas para pintarla, y Fido necesita dormir esa noche. No hay tiempo para seguir las instrucciones. Podra decidir saltar directamente al paso 3, ,' aplicar en el paso 4 utra capa gruesa de pintura en vez de una fina. Si el tiempo es bueno y la casa de Fido es de madera y no est demasiado sucia, es probable que todo vaya bien. Despus de unos pocos meses, la pintura se podra agrietar, al ser la capa de pintura demasiado gruesa, o se podran desconchar las superficies de metal de los clavos al no estar preparadas adecuadamente, y habra que r olverla a pintar otra vez el prximo ao, pero realmente no tendra den-ra-

siada importancia.
,Qu sucedera

si en vez de la caseta del perro se estuviera pintando

un Boeing 141'! En este caso, sera conveniente seguir las instrucctones de la lata. Si no quitara la capa de pintura previa, incurrira de forma significativa en la seguridad y en 1a eficiencia: una capa de pintura en un 7 47 pesa de 200 a 400 kilos. Si no prepara la superficie adecuadamente, el viento y la lluvia atacaran la pintura al ir a 600 millas por hora, y tendran efecto mucho ms rpidamente que un viento y una lluvia suaves en la caseta de Fido. Qu sucedera si se pintara algo que estuviera entre una caseta de un perro y unl4l , por ejemplo una casa? En este caso, las consecuencias de

88

Desarrollo y gestn de proyectos informticos

realizat un mal trabajo serian menos severas que para uni4i, y ms que para una caseta de un perro. No desearemos volver a pintar la casa en dos aos, y desearemos tener mejores resultados que con la caseta del perro. La mayora de los proyectos software que tienen problemas de planificacin son proyectos del tamao de la casa o mayores, y son esros proyectos los que principalmente interesan en este libro. En tales proyectos. las bases de desarrollo ahorran tiempo. Si se tiene suficiente conocimiento sobre el problema, sera un proceso mucho menos rgido que los pasos de la lata de pintura. proporcionando toda la flexibilidad necesaria.
Se

pueden ignorar las instrucciones si se desea, pero hay que hacerlo teniendo conciencia del riesgo que conlleva.

Bibliografa general
La seccin bibliografa adicional del final de este captulo presenta un listado de libros de ingeniera del software. El motivo de leer un libro de
conocimientos generales sobre ingeniera del software no es adquirir un conocimiento profundo sobre un tema especfico, sino ver a grandes rasgos el desarrollo del software. dentro del contexto. Los siguientes libros describen una visin de los mtodos que este captulo describe como bases del desarrollo del software.

Sommerville,lan: Software Engineering, 6th Ed. Reading, Mass.: Addison-Wesley, 1996. En la sexta edicin de este libro se tratan de forma equilibrada los requerimientos, diseo, validacin de la calidad y gestin. Contiene diagramas tiles y cada tema tiene una seccin sobre bibliografa adicional. Con 700 pginas, no es necesariamente un libro que se tenga que leer de principio a fin, pero si se desea una breve descripcin sobre un tema en particular, probablemente se encuentre en este libro. Tiene un buen ndrce. Pressman, Roger S.'. So.fi,,rare Engineering: A Practitioner's Aptroar.lt 3d Ed. New York: McGraw-Hlll, 1992. Es una excelente alternatira al libro de Sommerville y es similar en contenido y tamao. No scconfunda con el ttulo I Practitioner's Approach (<Un enfoque prctico>); aun siendo excelente, este libro es ms adecuado como un libro para proporcionar una visin sobre temas importantes que para ser usado como libro orofesional.

Gestin de resgos

Contenido

5.1. Elementos de la gestin de riesgos 5.2. Identificacin de riesgos 5.3. Anlisis de riesgos
5 .1

Pri ori zac

in de

ie sgo s

5.5. Control de riesgos 5.6. Riesgo, alto riesgo y azar

Temas relacionados
E,strategia de desarrollo rpido: Captulo 2 Errores tpicos: Captulo 3 Bases del desarrollo de software: Captulo 4 Resumen del filtrado de requisitos: Captulo 32 Resumen de los diez riesgos ms frecuentes: Captulo

4l

SI QUIERE APOSTAR SEGURO, VAYA A LAS VEGAS y juegue a las mquinas tragaperras. Los casinos han calculado minuciosamente las probabilidades y han determinado que pueden obtener beneficios incluso cuando las mquinas paguen hasta el 97 por 100 del dinero de la recaudacin. Las probabilidades se refieren a que si un da juega 1.000 dlares en monedas en las mquinas tragaperras, podr obtener hasta 970 dlares. Si no le gustan las mquinas tragaperras, puede jugar al blackjack y contar las cartas para poder aprovecharse de las probabilidades. (Pero no se equivoque al contarl) Si Las Vegas le resulta muy aburrida, el software puede ser su juego apropiado. Los proyectos de software incluyen un conjunto amplio de riesgos que pueden causar pesadillas a los apostadores de Las Vegas (cambio

de los requisitos del usuario, mala estimacin de la planificacin, per89

90

Desarrollo y gestion de proyectos informticos sonal contratado poco fiable, f-alta de experiencia en la gestin, problemas de personal. problernas con la tecnologia, cambio de las leyes del gobier-

DATOS REALES

no y problemas con el desarrollo. por nombrar slo unos de ellos). La probabilidad de que un proyecto complejo finalice en el tiempo estimado tiende a cero. Las probabilidadcs de que un proyecto complejo se cancele se aproximan a las de acertar allanzar una moneda al aire (Jones, l99 l). En I 988, Peat Marwick encontr que sobrc el 35 por 100 de 600 empresrs encuestadas han tcnido al menos un proyecto que se les ha ido de las manos (Rotht-eder, 1988). Los daos producidos por proyectos descontrolados hacen parecer a los combates de Las Vegas tan tranquilos como tonrar una taza de t con la Reina. Allstate comenz a automatizar en 1982
sus actividades aclministrati'u as. Planificaron una temporizacin para crnco

y un presupuesto de 8 ntillones. Seis aos ms tarde y l5 millones despus, Allstatc establcci una nueva f'echa lmite y estim un nuevo presupuesto de 100 millones de dlares. En 1988, la Westpac Banking corporation clecidi redefinir sus sistemas dc informacin. Planificaron un proyecto cle 85 nlillones de dlares para cinco aos. Tres aos ms tarde. despus de gastar 150 millones con poco xito, asumi sus prdidas. cancel el proyecto y elirrin 500 empleos de desarrollo (Glass, 1992). Incluso los combates de Las Vegas no son tan crueles. Hay una serie de mtodos de gestin de riesgos que pueden prevenlr dcsastres como stos, y que le harn aprender mucho de ellos antes de lo que aprcndera a contar las cartas en eI blackjack. De acuerdo que hay pcrsonas queJuegalt al blackjack sin haber aprendido a contar las cartas. y personas que planifican proyectos de software sin haber aprendido mucho acerca de la gestin de riesgos. Pero el hecho es el siguiente: si no controla los riesgos, no podr crear desarrollos rpidos. Como dice Tom Gilb, <si no controlas los riesgos, cllos te controlarn a ti>. E,l control de riesgos tiene una serie de problemas. Los proyectos que llevan un control de riesgos efectivo son menos excitantes que los proyectos que no lo hacen. Perder el rniedo que supone tener que decirle a su jefe que el proyecto tiene que retrasarse tres meses debido a un problema que nunca haba mencionado. Dejar de ser un hroe por trabajar noches y fines de semana durante seis meses sin descanso. Para muchos de nosotros, stos son problemas con los que se puede vivir. El control de riesgos en software es un tema relativamente nuevo, pero ya eriste infbrmacin suficiente como para estudiarlo con profundidad en este captulo. El estudio de este captulo se centra en los riesgos en la planificacin e ignora los riesgos sobre costes y produccin, salvo cuando af'ecten a la planificacin. Este captulo tambin se centra en los aspectos prcticos del control de riesgos de planificacin. La teora del control de riesgos es interesante e inrportanre. pero es menos til, por lo que la hemos evitado, mostrando en la seccin de bibliografa adicional al final del captulo dnde puede encontrar ms informacin.
aos

Captulo 5: Gestin de

ilesgos

91

Ejemplo

5.1.

Falta de gestin de riesgos al contratar

<He recitrido el visto bueno para realizar Square-Plan 2.5>, le dijo Kim a Eddie. Kim y Eddie eran responsables de proyectos de Square-Tech, una empresa de software <prt--porter>. <Tengo cuatro meses para entregar la actualizacin, y creo que va a ser un bombazo.> Kim entreg su ltimo proyecfo, Square-Calc 3.0, con mucho retraso. Eddie ha realizado bien su primer proyectoo Square-Plan 2.0, y Kim est ansiosa por demostrar que la diferencia se ha debido a que su producto era mucho ms complejo que el
de tddre.

<Yo de ti estara ms preocupado>, le dijo Eddie a ella. <He visto la especificacin de 1a 2.5, y pienso que con el equipo actual te quedan ms de seis meses de trabajo. Has pensado en utilizar el equipo de la 2.0?> <S, claro. Y tambin he pensado en ajustar el plan de trabajo a cuatro meses. La semana pasada le un articulo sobre desarrollo externo, y he encontrado a alguien que se puede encargar de las actualizaciones de los grficos, 1o que reducira el plan en dos meses.>> <<Bueno, spero que sepas 1o que ests haciendo>, le dijo Eddie. <He visto a mucha gente fracasar por culpa del personal contratado. ,,Cul es tu plan para el control de riesgos?> <He contratado a una persona de prestigio>, drlo Kim. <He comprobado sus referencias y estoy segura de que har un buen trabajo. Le echar un ojo de vez en cuando. Esto es un negocio arriesgado, y algunos riesgos son inevitables. Cuando tengo tanto trabajo por hacer, no pienso perder mi tiempo en trabajos intiles.> Eddie pens que ella debera tener ms cuidado, pero Eddie y Kim ya pasaron por esto antes. l haba aprendido a no discutir cuando ella ya habia decidido lo que iba a hacer. <<Buena suerte), le dijo Eddie. Kim se reuni pronto con la persona contratada y le dio una especificacin para las acfualizaciones de los grficos. Chip, la persona contratada, le dijo que las especificaciones le parecian claras y que se pondra a

trabajar enseguida.
Seis semanas ms tarde, Kim llam a Chip para comprobar el estado del trabajo. <Todo va bien>, dijo 1. <He estado trabajando en un proyecto muy importante de otra empresa, por lo que todava no he podido avanzar mucho. Pero todavia tenemos tres meses y medio para realizar un trabajo de dos meses, as que no te preocupes.)) <<Eso suena bien>, 1e dijo Kim. <<Avsame si necesitas algo. Te volver' a llamar dentro de seis semanas para tratar la integracin.r Seis semanas ms tarde, Kim volvi a llamar para comprobar la evolucin del trabajo. <El ltirno proyecto me llev ms tiempo del que esperaba>, le do Chip. <<He comenzado la actualizacin de los grficos, y he estado trabajando como un loco, pero necesito analizarlos ms profundamente, pienso que tendr que dedicarle otros tres meses.)) ((ontinudl

Desarrollo y gestin de proyectos informticos

Kim casi se ahoga. Esto hara que el tiempo de desarrollo total fuese seis meses en lugar de cuatro. <Tres meses? Me ests tomando el pelo? Necesito ese cdigo en dos semanas para empezar con la integracin. Se supone que ya lo tenas que tener hecho.> <<Lo sientoi;, dijo Chip. <<Pero no es culpa mia. Esfo tiene ms trabajo del que haba estimado. Lo terminar tan pronto como pueda.> Chip desanoll el software en tres meses, pero el proyecto se retras otro mes ms por los problemas de integracin con el cdigo del equipo propio. .41 final el tiempo total de desarrollo fueron siete meses, en lugar de los cu.atro meses previstos. Kim acab pensando que Eddie le habia hecho cargar a ella con un proyecto que l nunca hubiese podido llevar a cabo.

5.1. Elementos de la gestin de resgos

La funcin de la gestin de riesgos del software es identificar, estudiar y eliminar las fuentes de riesgo antes de que empiecen a amenazar la finalizacin satisfactoria de un proyecto software. Puede controlar los riesgos a varios niveles. La Tabla 5.1 describe algunos de los niveles de la ges-

tln de riesgos. El objetivo de este captulo es describir cmo estudiar los riesgos de 1a planificacin software en 1os niveles 4 y 5, en lugar de en ros niveles del 1 al 3. Si est controlando riesgos al nivel 1,2 o 3, ya ha perdido la batalla de la planificacin. Generalmente, la gestin de riesgos se divide en valoracin de riesgos y control de riesgos. Adems, se compone de varias subcategoras. como se muestra en la Figura 5.1. Esto se explica en los siguientes epgrafes.
Tabla

5.1.

Niveles de gestin de riesgos

l. 2.
3.

Crntrol de crisis. Apagar el fuego; controlar los riesgos slo cuando se han convertido en problemas.

Arreglar cada error. Detectar y reaccionar rpidamente ante cualquier

riesgo, pero slo despus de que se haya producido.

Mitigacin de riesgos. Planificar con antelacin el tiempo que necesitaria para cubrir riesgos en el caso de que ocurran, pero no intentar eliminarlos
inicialmente. Prevencin. Crear y llevar a cabo un plan como parte del proyecto sofiware para identificar riesgos y er itar que se conr iertan en problemas.

5.

Elintinar:i(n de lus causas principules. Identificar y eliminar los factores que puedan hacer posible la presencia de algn tipo de riesgo.

Fuentc: Adaptado de,1 Munuger's Guitle to solivrare Engneering (pressman, 1993

Captulo 5: Gestin de riesgos

ldentificacin de Estimacin de nesgos Anlisis de Priorizacin de riesgos Gestin de riesgos Planificacin

de la gestin de riesgos
Control de nesgos Resolucin de riesgos Monitorizacin de riesgos

Figura

5.1. La gestin de riesgos se compone de estimacin y control riesgos. Fuente: Software Risk Management (Boehm, 1989).

Estimacin de riesgos
La estimacin de riesgos se compone de identificacin de riesgos, anlisis de riesgos y asignacin de prioridades a los riesgos:

o o o

La identi.licac:in cle riesgos genera una lista de riesgos capaces de romper la planificacin del proyecto. El anlisis de riesgos mide la probabilidad y el impacto de cada riesgo, y los niveles de riesgo de los mtodos alternativos. La asignacin de prioridades a los riesgos genera una lista de riesgos ordenados por su impacto. Esta lista sirve como base para el control de riesgos.

Control de riesgos
El control de riesgos se compone de planificacin de la gestin de riesgos, resolucin de riesgos y monitorizacin de riesgos:

La plani.licacin de la gestin de riesgos genera un plan para tratar cada riesgo significativo. Tambin asegura que los planes para la gestin de riesgos de cada uno de los riesgos individuales son consistentes entre s y con el plan del proyecto. La resoluc:in de rie.sgos es la ejecucin del plan para resolver cada

o La monitorizacin

uno de los riesgos significativos. de riesgcts es la actividad del progreso de la monitorizacin dirigido a la resolucin de cada elemento del riesgo. La monitorizacin de riesgos tambin puede incluir la continuacin de la actrvidad de la identificacin de nuevos riesgos y volver a considerarlos en el proceso de la gestin de riesgos.

94

Desarrollo y gestin de proyectos informticos

Los apartados dc la si-truiente seccin explican cada uno de estos aspectos de la gestin de riesgos en su aplicacin a la gestin de riesgos en la planificacin soltware.

5.2. ldentificacn de riesgos

Si no pide

inlitrntucitin soltra
riesgo.s, a.stti bu.scundo

pnthlenr us.

Tom Gilb

en un proyecto de clesarrollo rpido, que soll olvidar los tres pilares del desarrollo rpido, descritos en cl captulo 2, <E,strategia para el desarrollo rpido>:

El primer paso en la gestin de riesgos es la identiflcacin de los factores que introducen un riesgo en la planificacin. Hay tres riesgos generalcs

o . o

comcter uno de los errores tpicos clescritos en el captulo 3, <Errores claslcos). lgnorar las bases del desarrollo descritas en el Captulo 4, <Base,s del desarrollo de software>. Fallar en la gestin activa dc riesgos descnta en este captulo.

Una vez que haya superado cstos riesgos generales, habr encontrado

casi todos los tipos de riesgos de los proyectos software. Sin embargo. hay una scrie de errores que aparecen una y otra vez, y una de las formas ms l'ciles de identificar los riesgos es comprobar su proyecto frente a una lista dc riesgos de la planificacin. E,l apartailo siguiente proporciona una lista crhaustiva de los posibles riesgos en la planificacin.

Riesgos ms comunes en planificacn

La Tabla 5.2 contiene una lista de los riesgos ms comunes en la planificac i n.

Si los riesgos de esta tabla le son familiares. se debe a que cada untr de ellos ya sc coment en los errores clsicos del captulo 3. La nica diferencia entre un error clsico y un riesgo es que los errores clsicos se
cometen con mayor frecuencia. Los riesgos son menos colrunes o pueden

ser nicos en su proyecto. cada uno de los riesgos dc la Tabla 5.2 se describe con ms detalle en la Seccin 3.3, <Relacin cle errores clsicos)), y la forma de controlarlos se estudia posteriormente en este caDtulo. en la Tabla 5.6.

Lista completa de riesgos de planificacin

a la planificacin de un proyecto software. Slo algunos de ellos aparecern cn la mayora de los proyectos. Los riesgos se han organizado en
La Tabla 5.3 contiene una lista exhaustil'a de los ricsgos que pueden afecta

Captulo 5: Gestin de

riesgos

95

Tabla

5.2.

Riesgos ms habituales en planificacin

l. 2. 3. 4. 5. 6. 7. u. 9. 10.

Cambio de requisitos. Meticulosidad cn requcrimicntos o dcsarrolladores.

Escatirnrr en la calidad.

Planificaciones dernasiado optimistas. Diseo inadecuado.

Sndrome de la panacea.

Desarrollo orientado a la investigacin.

Pclsonrl rncdioele.
Error en la contratacin.
Dif-erencias entre el
pe

rsonal de desarrollo y los clientes

y.,1.r,sc,.ssrcn/

Fucntes: Adaptado de Sofiuure Ri.sk ,I4unugentcl (Bochnr. 1989)

untl Ctn-

trol ol .\oliut'e Rl.ii.r 1.lones.

199,1).

categoras, pero sin un orden concreto. Si la lista le parece abrumadora, concntrese en los riesgos ms comunes de la seccin anterior. Adems de la lista de riesgos de esta tabla, la mayora de los proyectos tienen riesgos que son caractersticos de ese proyecto: <Joe est dispuesto a abandonar, a mcnos que se pueda llevar su perro al trabajo, y la direccin an no ha decidido si va a pemitir que Bowser entre en la oficina.> Estc tipo de riesgos los tendr que identificar usted mismo. Tabla

5.3.

Riesgos potenciales de Ia planificacin

Crescin de Iu planificocitr
Las deflniciones de la planificacin, de los recursos r del producto han sido impuestas por el cliente o un directivo superior, v no estn equilibradas.

Planificacin optirxista, <mejor caso> (en lugar de realista, <caso esperado>).

La planificacin no incluye tareas necesarias.

La planificacin se ha basado en la utilizacin de pelsonas especf-icas de un cquipo, pero estas personas no cstn disponibles. No se puedc construir un producto de tal envergadura en cl tiempo asignado. El producto es ms grande que cl cstirnado (en lneas de cdigo. en el nmero de puntos de funcin. o en relacin con el tamao del pro'ecto anterior). El esfuerzo cs lnayor que el estimado (por lineas de cdigo, nlrel'o de puntos de funcin. rndulos, etc.).
\( onltnltu
)

96

Desarrollo y gestin de proyectos informticos

Tabla

5.3.

(Continuat.irjn)

La reestimacin debida a un retraso en la pranificacin es demasiado optimisre o ignora la historia del provecto.
La presin excesiva en la planificacin reduce la prodr.rctividad. La fecha final ha cambiado sin ajustarse al mbito der producto o a los recursLr: disponibles.

un retraso

en una tarea procluce retrasos en cascada en las tareas clependientes. Las reas desconocidas del producto llevan rns tiernpo del esperado en el dise.

y en la implernentacin.

Organizacin y gestin El proyecto carece de un promotor efectivo en los superiores. El proyecto languidece demasiado en el inicio difuso. Los despidos y las reducciones de Ia prantiila reducen la capacidad del equrpo. Direccin o marketing insisten en tomar decisiones tcnicas que alargan la planificacin. La estructura inadecuada de un equipo reduce Ia productividad. El ciclo de revisin/decisin de ra directiva es ms lento de lo esperado. El presupuesto varia el plan clel proyecto. La direccin toma decisiones que reducen la motivacin del equipo de
desarrollo. Las tareas no tcnicas encargadas a terceros necesitan ms tiempo del esperado laprobacin del presupuesto. aprobacin de la aclquisicin de material. revisiones legales. seguridad, etc.).

La planificacin es demasiado mala para ajustarse a la velocidad de desarrolro

deseada.

Los planes del proyecto se abandonan por la presin, llevando al caos y a un

desarrollo ineficiente.

La direccin pone ms nf'asis en las heroiciirades que en informarse exacramente del estado' lo que reduce su habilidad para detectar y corregrr problernas.

Entorno de desarrollo
Los espacios no estn disponibles en el momento necesario. Los espacios estn disponibles pero no son adecuados (por ejemplo, falta de telfonos, cableado de la red, mobiriario. material d" oii.inu, .t..).
Los espacios estn sobreutiliza<Jos, son ruidosos o dlstraen. Las herramientas de desarroilo no estn disponibles en el momento
deseado.

Las herramientas de desarrollo no funcionan como se esperaba; er personar de

desarrollo necesita tiempo para resolverlo o adaptarse a las nuevas herramienras.
\LOn tt rTuu

Captulo 5: Gestin de

riesgos

97

Tabla 5.3. lL'trntiilttd( t;nl

Las herramientas de desarrollo no se han elegido en funcin de sus caractersticas tcnicas, y no proporcionan Ias prestaciones pre\ istas.

La curva de aprendizaje para la nueva herramienta de desarrollo es ms larga de lo esperado.

Usuarios finales

Los usuarios finales insisten en nuevos requerimientos.

En el ltimo momento, a los usuarios finales no les gusta el producto, por lo que hay que volver a disearlo y a construirlo.

Los usuarios no han realizado la compra del material necesario para el proyecto v por tanto no tienen la infraestructura necesana.

No

se ha solicitado informacin al usuario, por lo que el producto al final no se ajusta a las necesidades del usuario, y hay que volver a crear el producto.

Clienfe El cliente insiste en nue\os requisitos. Los ciclos de revisin/decisin del cliente para los planes, prototipos y especificaciones son ms lentos de lo esperado. El cliente no participa en los ciclos de revisin de los planes. prototipos y
especificaciones, o es incapaz de hacerlo, resultando unos requisitos inestables y la necesidad de realizar unos cambios que consumen tienrpo.

El tiempo de comunicacin del cliente (por ejernplo. tiempo para responder las preguntas para aclarar los requerimientos) es ms lento del esperado. El cliente insiste en las decisiones tcnicas que alargan la planificacin. El cliente intenta controlar el proceso de desarrollo, con lo que el progreso ms lento de lo esperado.

es

Los componentes suministrados por ei cliente no son adecuados para el producto que se est desarrollando, por lo que se tiene que hacer un trabajo extra de
diseo e integracin.

Los componentes suministrados por el cliente tienen poca calidad, por lo que
tienen que hacerse trabajos extra de cornprobacin, diseo e integracin. Las herramientas de soporte y entornos irnpuestos por el cliente son incornpatibles, tienen un bajo rendimiento o no funcionan de forma adecuada, con lo que se reduce la productividad.

El cliente no acepta el software entregado, incluso aunque cumpla todas sus

espec

ificaciones.

El cliente piensa en una velocidad de desarrollo que el personal de desarrollo no

puede alcanzar. ((onti nu)

98

Desarrollo y gestin de proyectos informticos

Tabla

5.3.

(('tn/intutt.in\

Personal confrutado El personal contratado no s,ministra ros cornponentes en el periodo estableciclo. El personal contratado propo.ci.ra rnaterial de una caridad inaceptable. por lo quc hay que aaclir rrn tientpr.r e\tra para ntejorar la calidacl.
Los pro"'ecdorcs no se irrtegran cn dc rCndilnir'nt() quc se ltcccsilr.
Req
c-r

prol'ccto. con lo que no se alcanza er ni,",el

uisitos

Los recluisitos se han aclaptado. pero continan cambiandcl. Los requisitos llo sc han deflnido correctaurcnte, y su reclefinicin aurnenta el intbito del proyccto.
Se aaden requisitos extra. Las paftes del proyecto que se no se han especifrcado crararnente consumen

rns tientpo dcl esperado.

Producfo
Los mdulos propensos a tener errores necesitan rns trabajo cre comprobacin. diseo e implementacin. Una calidad no aceptable rcquiere de un trabajo de comprobacin. diseo irnplementacin supcrior al esperaclo.
e

utiliz,ar lo irltinro en infb'ntica ararga ra planificacin de forma irnpredecible.

El desarrollo de lunciones sofiwarc errneas r.equiere vorver a disearlas y
imp ler-nentarlas.
a

El desarrollo de una interfaz de usuario inadecuada requiere'or'er a disearra y a implernentarla. El desarrollo de funciones softr'vare innecesarias alarga ra planificacin, Alcanzar el mbito der procructo o ras restricciones de .,,elociclad requiere nr.

tiempo del espcrado. incruvendo el tiempo para'orver a disear i-pr.,n.nt' " unos requisitos rgidos de compatibilidaci con el sistema existente necesitan un trabajo extra de comprobacin. diseo e irnplernentacin. Los requisitos para crear intcrfaces con otros sistemas. otros sistemas cornprejo:. u otros slstemas que no estn bajo er control del equipo de desarr.llo suponei-. un diseo, irnplementacin y prueba no pevrstos.

El requisito de trabajar con varios sistemas operativos necesita rns tiempo

esperado.

der

El traba.io con un entorno software desconocido causa probremas no prevrstos. El trabaf o con un entorno hardrvare clesconocido causa problemas imprevistos. El desa'ollo de un tipo de cornponente nue',o para ra organizacin consume tns tier.npo del esperado.

Captulo 5: Gestin de

riesgos

99

Tabla

5.3.

(Conrinuutin)

Depender dc una tecnologa quc an est en f'ase de desarlollo alarga la

planificacin. Fuerzas meyores El producto depende de las nonnatiras del gobierno. quc pueden carnbiar de forma inesperada. El producto depende dc cstndares tcnicos rror,'isionalcs. que pueden carnbiar de fonna inesperada. Personal
La contratacin tarda r.ns de lo espcrado. Las tareas prelirninares (por cjcmplo. forrnacin. finalizacin de otros pro-yectos. adquisicin de licencias) no se han cornpletado a tientpo. La falta cle relaciones entre la direccin ' el equipo de desarrollo ralentiza la toma de decisiones. Los nrierubros de I equipo no se irnplican en el provecto. y por lo tanto no alcanzan el nivcl de rendimiento deseado.

La falta de rnotivacin y de moral reduce la productividad. La f-alta de la especializacin necesaria aumenta los def'ectos repetir el trabajo.
herramientas cl entornos nuevos.
1'

la necesidad de

El personal neccsita un tienrpo r-xtla para acostulnbrarse a trabajar con El personal necesita un tieurpo extra para acostul-nbrarse a trabajar con
hardrvare nuevo.

El personal necesita un ticrtrpo !-\trr fara aplendel un lenguaje de

progran-racin nuevo.

El personal contratado abandona el proyecto antes de su finalizacin. Alguien dc la plantilla abandona el prol'ecto antes de su finalizacin. La incorporacin de nuevo pelsonal de desarrollo al prol,ecto ya avanzado. y el aprendizaje v conlunicaciones c\tra irnprer istas rcducen la eficiencia de los rnicnrbros dcl equipo e\istentes. Los uriernbros del equipo no trabajan bicn juntos.
Los conflictos entre los mier-nbros del equipo conducen a problenras cn la colnunicrcin y en el diseo. crrores en la intcrfaz y tener que repetir algunos trabajos. Los miernbros problemticos de un equipo no son apartados. influyenclcr negativamente en la rnotir,'acin de I rcsto del equipo. Las personas ms apropiadas para tlabajar en el prcll,ecto no estn disponibles.
(LIttlnt!Lt\

100

Desarrollo y gestn de proyectos informticos

Tabla

5.3.

(Contintnt'in)

Las personas ms apropiadas para trabajar en el proyecto estn disponibles, pero no se pueden incorporar por razones polticas o de otro tipo.
Se necesitan personas para el proyecto con habilidades muy especificas y no se encuentran.

Las personas clave slo estn disponibles una parte del tiempo. No hay suficiente personal disponible para el proyecro. Las tareas asignadas al personal no se ajustan a sus posibilicrades. E,l personal traba.ja nts lento de lo esperado.

El sabotaje por parte de la direccin del proyecto deriva en una planificacin ineflciente e inefectrva. El sabotaje por parte del personal tcnico cleriva en una prdida de trabajo o en un trabajo de poca calidad, por Io que hay que repetir algunos trabajos. Diseo e implementacin

un diseo demasiado sencillo no cubre las cuestiones principales, con

hay que volver a disear e implementar.

l.

que

Un diseo demasiado complejo exige tener en cuenta cornplicaciones innecesarias e improductivas en la implerr-rentacin. Un mal diseo implica volver a disear e implernentar. La utilizacin de metodologas desconocidas deri'a en un perodo extra de fbrmacin y tener que volver atrs para corregir los errores iniciales cometidos en la metodologa. El producto est implementado en un lenguaje de bajo nivel (por ejempio, ensamblador) y la productividad es menor de la esperada. No se puede implementar la funcionalidad deseada con el lenguaje o bibliotecas utilizados; el personal de desarrollo tiene que utilizar otras bibliotecas. o crearlas l mismo para conseguir la funcionalidad deseada.
Las bibliotecas de cdigo o clases tienen poca calidad, y generan una cornprobacin extra, correccin de errores y la repeticin de algunos trabajos.
Se ha sobreestimado

el ahorro en la planificacin derivado del uso de herramientas para mejorar la productividad.

Los componentes desarrollados por separado no se pueden integrar de forma sencilla. teniendo que volver a disear z repetir algunos trabajos.
Proceso

La burocracia produce un progreso ms lento del esperado. La falta de un seguirniento exacto del progreso hace que se desconozca que el proyecto est retrasado hasta que est muy avanzado.
(continiru
t

Captulo 5: Gestin de riesgos

101

Tabla

5.3.

(Continuac'in\

Las actividades iniciales de control de calidad son recortadas, haciendo quc sc tenga que repetir el trabajo.

Un control de calidad inadecuado hace que los problemas de calidad que afectan a la planificacin se conozcan tarde. La falta de rigor (ignorar los fundamentos y estndares del desarrollo de software) conduce a fallos de comunicacin, problemas de calidad y repeticin del trabajo. Un consumo de tiempo innecesario. El exceso de rigor (af'erramiento burocrtico a las polticas y estndares de software) lleva a gastar ms tiempo en gestin del necesario. La creacin de informes de estado a nivel de directiva lleva ms tiempo al
desarrollador de lo esperado.

La falta de entusiasmo en la gestin de riesgos irnpide detectar los riesgos ms

importantes del proyecto.

La gestin de riesgos del proyecto software consume ms tiempo del esperado.

Fucntes: Principles o.f So./twure Engineering trlunogenent (Cilb, l99tt). So/iware Risk Mandgetnent (Boehm, 1989)..1 Manuger's Guitle to Sofiware Engineering (Pressman. 1993 ). Third Il ave Projec't Management (Thontsett. 1993 ) , Assessnent and Cotttt.ol of'Solnvre
R.iAs

(Jones. 1994).

Anlisis de riesgos
Una vez que haya identificado los riesgos de planificacin de su proyecto, el paso siguiente es analizar cada riesgo para determinar su impacto. Puede

utilizar el anlisis de riesgos para poder elegir entre varias alternativas

de desarrollo, o para gestionar los riesgos asociados con una alternativa que

ya haya elegido. Con los riesgos en general, esto puede ser difcil, pero cuando est interesado en los riesgos de planificacin, la estimacin es
ms sencilla.

Exposicin a resgos
Un mtodo til en el anlisis de riesgos es determinar la <exposicin a riesgos) de cada uno de los riesgos que haya identificado. La exposicin a riesgos a menudo se abrevia como (ER) (hay quien la llama <impacto del riesgo>). Una definicin de riesgo es <prdida no esperada>. La exposicin a riesgos es igual a la probabilidad de prdida no esperada multiplicada por la magnitud de la prdida. Por ejemplo, si piensa que la probabilidad puede ser del 25 por 100 y puede haber un retraso de cuatro semanas

102

Desarrollo y gestin de proyectos informticos

sobre la duracin del proyccto. la erposicin al riesgo sera 25 por 100 multrplicado por cuatro semanas. es decir, una semana. Como slo est interesado en los riesgos de planificacin, puede erpl'esar las prdidas cn semanas o meses o en otra unidad de tiempo que fhcilite la comparacin. La Tabla 5.4 cs un e.jernplo de cstimacin de riesgos de planificacin que puede crear a partir dcl riesgo. la probabilidad de prdida, la magnitucl de la prdida y la exposicin a riesgos.
E,n el ejenplo de estimacin dc riesgos de la Tabla 5.4. el proyecto ha identificacio varios riesgos cuya grar.'cdad pucde estar entre I y 20 semanas,

Tabla

5.4.

Ejemplo de tabla de estimacin de riesgos

Riesgo

probabilidad llagnitud Exposicin de la prdida a riesgo dc prdida ' (semanas) (semanas l

Planificacin dentasiado

optiniista

50ot, -501, 35,fn 25,'/u 15% 25% 10% 109'0 10-20,%

Aadir un reqrLisito para la actualizacin autorntica desde el

mainfiarne

5 20 8 4 15 ,1 2 I ,1

2,5
1"0

Aadir nucvas caractersticas rurarketing (sin conocer las

caractersticas cspecificas
de grficos inestablc
)

desde

2,8

Interfaz del subsistcrna de

fbrn.rato voll'er

1,0

Diseo inadecuado (hay qLre

a discar)

2,25

La aprobacin del proyecto

nrs de lo esperaclo

rarda

1.0

Los recursos no estn en sLl monlento

disponibles de en

0,2

Los infbrmes de estado a nir,'el clilectir a nccesitrn rns tiernpo

clel prer,isto

0.

El personal contratado

se retrasa

0.4-0,8

la entrega del subsisterna encargado de formatear los grficos Las nuevas herramientas de prograrnacin no producen cl ahorro

30o,i,

l.-5

pronletido

Captulo S: Gestin de

riesgos

103

Las probabilidades de que ocurra alguno dc los ricsgos oscilan entrc un y un 50 por 100. En un proyecto real tencira que iclentificar muchos rrs riesgos de los que se muestran en la tabla anterior. ,De dnde han salido las probabilidades y la nagnirud de la prdida? Estos nme.os hay que estimarlos, sin pretender que sean exactos.
5

Estimacin de la magntud de la prdida

Muchas veces es rs fcil estimar la nragnitud de la prdicla quc la probabilidad. En el ejemplo anterior, podra haber estimado 20 rreses como el tienrpo que se necesitara para automatizar las actualizacioncs clesde el mainfiame. o bien podra saber que el proyecto se aprobar el I de febrero o el I de marzo, clependicndo del mes en que la comisin revise la propuesta dcl proyecto. Si suponc que podra aprobarse el I cle febrero. la magnitud del riesgo para la aprobacin del proyecto sera exactanentc un mes. En los casos en que la mag'itud de prdida no es fcll de e stimar directamente, se puede dividir ia prdida en prdidas ms pequeas, estirrarlas, y combinar las prdidas pequeas eu una estimacin cle la prdicla. por e.emplo. si est utihzando tres herramientas cle programacin. podra estimar la prdida resultante a partir de las prdidas que podra generar cada una de las herramientas. As podra sumar las prclidas, y obtencr la estimacin de una forma ms scncilla que la estintacin global.

Estimacin de la probabilidad de prdida

Normalmente, la estimacin cic la probabiliclad cle prdida es ms subjetiva que Ia estimacin dc ia magnitud de la prdicla. existiendo muchas tcnicas para mejorar 1a cxactitud de esta estimacin subjetiva. He aqu algunas ideas:

' o

Disponer de la persona que cst ms familiarizada con cl slstelna para que estime la probabilidad de cada riesgo. y luego realizar una revisin de la estimacin. Usar tcnicas Delphi o de consenso en grupo. Con la tcnica Del-

phi, cada persona cstima individuahllente cada ricsgo, y luego se discute o se escribe el origerr de cada estimaci'. especialmente en las que haya nayores diferencias. Continuar con el proceso hasta

hacer conr,'erger las estimaciones. Realizar analogias con apuestas: <,Aceptarias esta apuesta? Si los recLlrsos estn disponibles en su momento ganas 125 dlares. Si no lo estn, yo gano 100 dlares.> Ajustar la apuesta hasta que los dos apostantes estn igual de seguros. La probabilidail de nesgo

104

Desarrollo y gestin de proyectos informticos sera la apuesta menor dividida entre la cantidad total en juego. En

el ejemplo, la probabilidad de que 1os recursos no estn disponibles en su momento podra ser 100 / (100 + 125)- 44 por 100. Utilice la <calibracin mediante adjetivos>. Primero cada persona elige el nivel de riesgo entre una serie de frases como muy probable, bastante probable, probable, improbable, muy improbable. Despus se convierte cada una de las estimaciones verbales a estimaciones cuantitativas (Boehm, I 989).

Retraso total del proyecto y margen de retraso

Un efecto colateral interesante de calcular los nmeros de exposicin
a

riesgos mostrados en la Tabla 5.4 es el hecho de que, en trminos estadsticos, estas exposiciones a riesgos son <valores esperados>. El riesgo de un diseo no adecuado le podra costar hasta quince semanas si ocurre ahora. Como no es seguro que ocurra al 100 por 100, no espera perder quince semanas. Pero como tampoco es imposible que ocurra, tampoco debe esperar no perder ninguna semana. Estadsticamente hablando, la cantidad que espera perder es la probabilidad por el tamao, o 15 por 100 veces quince semanas. En este ejemplo <esperara> perder 2,25 semanas. Como slo estamos hablando de riesgos en la planificacin, puede sumar todas las exposiciones a riesgos para obtener el retraso total del proyecto. Asi el retraso si no se hiciese ninguna gestin de riesgos estara entre 12,8 y
13.2 semanas.

La magnrtud del retraso total esperado permite intuir el nivel global de riesgo del proyecto. Si el proyecto del ejemplo es un proyecto de 25 semanas, y el retraso total estimado esperado est entre 12,8 y 13,2 semanas, necesitaramos hacer una gestin de riesgos activa.
REFERENCIA CRUZADA Para mayor informacn sobre los srgnos mas o menos en la planificacin, consulte "Estilos de presentacin de una estimacin", en la Seccin 8.3.

rado'l Creo que s. Vuelva a calcular la exposicin a riesgos total despus de haber realizado el plan de gestin de riesgos, y luego adalo a su planificacin con-Io un margen. Esto le dar un margen de retraso ms claro que la regla elemental que utilizan algunas personas para ajustar sus planificaciones. Otra manera sera crear una planificacin con signos ms o menos para cada riesgo, y ajustar la planificacin cuando se produzca un riesgo.

Se podra cambiar

la planificacin para reflejar el retraso espe-

5.4. Prionzacin de riesgos

Una vez que haya creado la lista de los riesgos de la planificacin, el paso siguiente es priorizar los riesgos de forma que sepa dnde centrar el esfuerzo para la gestin de riesgos. Los proyectos gastan generalmente

Captulo 5: Gestin de

riesgos

105

-.4ue tos iraya calculado la exposicin a riesgos multiplicado la probabilidad de -' 'c/? /rs pe;dida por la magniiud de la prdida, ordene 1os riesgos segn la exposiqueda';:li::;l .iOn u .iesgos en su tabla de estimacin de riesgos' y vea cmo ha riesgos estimacin de .,,,l,{,r. do. La labta S.S es un ejemplo de una tabla de : l)rucker ordenada por la exposicin a riesgos'

, Uttitil el 80 por 100 de su presupuesto en arreglar el 20 por 100 de sus proble,tttttin,tr nrur, po. lo que es til poder centrarse en este 20 por i00 ms importante' 1os riesgos de slo ,,):,]),;l Una |ez-ms, el trabajo es ms fcil sitipos considera Una l'ez que de riesgos' todos los - ,i,','r'')|, planificacin que si se centra en

Tabla

5.5.

Eiempto de tabla de estimacin de riesgos priorizada Proba.birid,ad

Riesgo

oe

Peroloa (semanas)
35%

r;tf

-rXl;[, t:T::'J:"
(scmanas)
2.8

Aadir nuevas caracteristlcas desde marketing (sin conocer las

caractersticas esPecficas) Planifi cacin demasiado optrmista Diseo inadecuado (haY que volver a disear) Las nuevas herramientas de progran.racin no Producen el ahorro prometido

50%
l5'l/

2.5

l5

))\
15

30%

Aadir un requisito Para la actualizacin automtica desde

el mainframe

5u.:i

20

1.0

Interfaz del subsistema de formato de grficos inestable

La aprobacin del ProYccto tarda
rns de lo esperado

25'k
25%
t0-209/

1.0

1.0

El personal contratado se retrasa en la entrega del subsistema encargado de fbrmatear los

grficos

0.4-0.E

Los recursos no estn disPonibles

en su lomento

109i,

0.2
0.1

Los infbrmes a nivel de directiva necesitan rns tiernpo del previsto

10%

106

Desarrollo y gestin de proyectos informticos

E,sta forma de ordenacin de la tabla genera una

lista de los liescos

ordenada aproximadamente por prioridades. Si consigue controlar los cinco primeros riesgos de la tabla, cabra esperar una reduccin de 9,8 semanas en el retraso total esperado de la planificacin. Si se decidiera a controlar

los cinco ltimos riesgos de la tabla slo podra esperar una reduccin enfre 2,J y 3,1 semanas sobre cl retraso total esperado del proyecto. En trmino medio, sera mejor concentrar el esfuerzo en el control de los cinco primeros riesgos de la lista. La razn por la que la lista slo est ordenada <aproximadamente) se debe a que quiz podra dcscar priorizar algunos de los riesgos que produciran una prdida grande, independiententente del lugar que ocLrpasel en la tabla. E,n la Tabla 5.5, el riesgo <Aadir el rcqtrisito de actualizacin
automtica desde el mainframe> es aproximadamente del 5 por 100" pero producira un retraso de 20 semanas. que es mayor que el de cualquier otro tipo de riesgo. Si se produjese un retraso de 20 semanas. podra suponer un desastre para su proyecto, por lo que debera gestionar los rresgos de esa magnitud para asegurar que no ocurriese ninguno de ellos. incluso aunque tengan una probabilidad pequea de ocurrencia. Asimismo, puede querer priorizar un grupo de riesgos encadenados en lugar de priorizar cada uno de los riesgos inclividualmente. Por ejemplo, la inestabilidad de la interfaz del subsistema de formato de grficos es un riesgo, y tambin es un riesgo 1a fecha en la que el personal contratado entregue el producto. El riesgo combinado que aparece al utilizar personal contratado y tener el cdigo desarrollado por ellos para crear una interfaz que parece inestable, es un poco mayor que si se considera cada uno de los riesgos de forma individual.

La ordenacin de prioridades slo es aproximada por otra razn

los nmeros que se han utilizado para crear la tabla son estimac'itnt.-, As pues. la exactitud de los nmeros de la exposicin a riesgos y el or.den de las prioridades depende de la precisin de las estimaciones cl.' la probabilidad y de la magnitud del riesgo. La conversin de estimaciones en un valor de exposicin a riesgos ajustado a la realidad slo puede hacerse si la priorizacin es precisa. Como la priorizacin slo pued; llegar a ser tan exacta como la entrada. y como 1a entrada es algo subjetrvo, la priorizacin tambin es algo subjetivo. As. su capacidad de valon-.cin es una parte necesaria para cada uno de los aspectos de la gestin d-'
nesgos.

Una vez que haya identificado cada uno de los elementos de alto rie.go, tambin es importante realizar una priorizacin de riesgos para r-formar de los riesgos que se pueden ignorar. No nos preocuparenr. de la gestin de pequeos riesgos que adems tengan una probabilidad c. aparicin pequea. En el ejemplo anterior podra gastar ms tiempo en -, gestin del riesgo por que los recursos no estn disponibles en su mome:'to que si realmente no estuviesen disponibles en su momento. La plio: -

Captulo 5: Gestin de

riesgos

107

zacin de riesgos es un proceso crtico en el que hay que tener cuidado de no dedicar todo el esfuerzo a la sestin de riessos en si.

Control de riesgos
Una vez que haya identificado los riesgos de su proyecto, analizado sus probabilidades y magnitudes. y los haya priorizado. est preparado para controlarlos. Esta seccin describe los tres aspectos del control de riesgos: planificacin de la gestin de riesgos, resolucin de riesgos y monitoriza-

cin de riesgos.

Planificacin de la gestin de riesgos

El objetrvo de la planificacin de la gestin de riesgos es desarrollar un plan que controle cada uno de los riesgos de prioridad alta identificados en las actividades anteriores. El plan de gestin de riesgos puede ser tan sencillo colno un prrafo para cada riesgo, describiendo quin, qu, cundo y crno sc gestiona cada uno de los riesgos. Tambin debera contener previsiones para la monitorizacin de riesgos, descartando los riesgos que se han resuelto e identificando los riesgos que aparecen.

Resolucin de riesgos
La resolucin de un riesgo concreto depende mucho del riesgo especfico. Los mtodos que controlan el riesgo de un diseo inadecuado no se adaptan bien ai riesgo de que su equipo sea expulsado de sus oficrnas. Supongamos que est encargado de la contratacin y est preocupado por los riesgos de la creacin de un diseo inadecuado en un rea nueva para usted y que su despacho va a ser cedido a otro grupo de trabajo de la empresa. A continuacin se describen una serie de mtodos para tratar los riesgos mediante ejemplos relacionados con los riesgos del diseo y del
lugar de trabajo.

Evite el riesgo. No realice actividades arriesgadas. Por ejemplo, tome responsabilidades en la mayor parte del diseo del sistema, pero no en las partes que no conozca. En cuanto al problema del lugar de trabajo, negocie con el grupo que pretende desplazarlo de su lugar de trabajo y convnzalos para que no lo trasladen. Traslade el riesgo de una parte del sstema a otra. A veces lo que es un riesgo en una parte del proyecto no lo es en otra parte del proyecto, por lo que puede trasladarlo a otra parte. Por ejemplo, en el rea de relaciones pblicas: lmagine que tiene que disear una parte del sistema en-

108

Desarrollo y gestin de proyectos informticos cargada al resto del equipo" que va a disear una parte con la que no esrfamiliarizado. O podra hacer que le revisasen y aprobasen su diseo, trasldndoles las responsabilidades. En el caso del espacio de trabajo, dispo-

ner de otro grupo cuya planilicacin menos crtica permita cambiar .. espacio en lugar de en el suyo. o esperar a que el sistema est preparaclc para el traslado. En general, aparte el riesgo del camino crtico. Planifique el proyectc de forma que si ocurre nn riesgo, el proyecto completo no se retrase.

Consiga informacin acerca del riesgo. Si no conoce el autntic. peligro del riesgo, avergelo. Por ejemplo, desarrolle un prototipo par. comprobar la viabilidad de su alternativa de diseo. Localice un asescr:. que evale su diseo. Utilice la planificacin de recursos para ver si pu,-.de permanecer cn su lugar de trabajo mientras dure el proyecto.
Elimine el origen del riesgo. Si el drseo de una parte del sistcma e > dcmasiado arriesgado, cambie la parte del sisterna a un proyecto de inr esrrgacin y climnelo de la versin que est desarrollando. Intente convence:' al grupo de trabajo que trata de ocupar su lugar de trabajo de que utilice otro espacio en donde puedan estar todosjuntos. U obtenga una confirmacin del grupo de planificacin de infraestructuras para quc le dejen permanecer en su despacho mientras dure el proyecto.

Asuma el riesgo. Acepte que el riesgo puede ocurrir, pero no prcu\j demasiado en ello. Si las consecuencias son pequeas y el esfuerzo qrii se requicre para evitarlo es mucho, hacer caso omiso puede ser la rnet: estrategia. Simplemente acepte las consecuencias de un diseo inadecuado o de que lo echen de su despacho.
Comunique el

riesgo.

Haga saber al personal de la direccin y de mar'-

keting y a los clientes la presencia del riesgo y sus consecuencias. Intentc suavizar el susto que se llevarn si llega a ocurrir.

Controle el riesgo. Acepte que e1 riesgo puede ocurrir y desarroll.. planes de contingencia para controlar el riesgo si no puede resolverlo Busque recursos extra para comprobar la parte del sistema con el diserio que le preocupa! y prepare un tiempo extra para corregir los problemas Planifique con antelacin el traslado de su despacho para evitar problemas: planifique la mudanza para un sbado por la noche para evitar molestias; y busque personal temporal para facilitar las tareas de empaquetar. y desempaquetar.
Recuerde el riesgo. Cree una coleccin de planes dc gestin de riesgos que pueda utilizar en proyectos futuros.

Captulo 5: Gestin de

riesgos

109

planiflcac in.
Tabla

Para ilustra'la forma cn quc puecle c.ntrolar algunos clc est.s r.icsgos. Ia Tabla 5.6 lista los mtodos cie co'trol de los ricsgos r.us conlures cn la

5.6.

planif icacin Riesgo

Mtodos de control de los nesgos ms habituales en

Nttodos de control

Dnde encontrar nls infbrmacin C'aptulo I 0.,<Desar.rollcr oricntado al clientc>r.

|.

C'ambio clc prcstacioncs

Uso cle telcnicas ofrcntadas al cliente. Uso dc tcnicas clc

clcsalrollo incrcr-ncntal.

( rrpitult' ?. ., l)lallifle le ion

del ciclo cle vidr>.

( ontrole cl conjunttr de
1-r'cstac

Captulo
C

ioncs.

1.1. <Conrrol clcl conjunto de plestaciones>.

Diseo para cl cambio.

apitulo

I c).

<rl)isco para

el ca'' bio,r.

2.

Requerrnrientos

Filtrado de
rccuc-rinr

,<Filtrado

cle
lr

supo'fluos n
pcrsonal dc
dcsan'ollcr

icntos.

rcquerimientosr. cn Scccin l-1. I

. <<

nreticuloso

Dcsarrollo con velltanas

tcnrpora I cs.

Captulo 19. Dcsarrollo con \ elrtanas tertrltorales>.

CapitLrlo l-{. ((Control clel

(-ontrol clel conjunto

prcstac i oncs.

cic

conlunto de pre.slaciones>>. Capttrlo i6. ((Entrc0a por ctapirs). r' Secci(rn 7.6. ,,llntrega p0r etapasD.

Uso dc cntrega por

ctapa
s.

l-so

clc tlototrpos
I

( littrltr .i\.
dcsec hab
I

..p1ro1tr1rr

dcsechab
Di ser-io

s.

es >.

por plan i ficaci(rn

Scccin 7.7. <Diseo por

p lan

il icac i(rn

>,.

-1. Recortc de la cal idad

Deje ticr.npo a Ias actir idades dcl control de calidud v pfestc atencin a las bascs del control de calidad.

Seccirin -1.3. <lJascs del

control de calidacl>r.

.1. Planrflcacin
demasiado optintista

Utilizacin clc r rrias

tcn icas de estimrci irn.

C'aptulo 8. < Estirtracionr

arios cstintaclores r, hcrranticntas clc estirnacirin.

r

110

Desarrollo y gestn de proyectos informticos

Tabla 5.6. ((-ttttinuutinl

Ricsgo

\ltodos de control
Utilizacitin
de

Dnde encontrar ms informacin

Scccin t).2. <Disluinucin
Ia presitin de planificacin>.
cle-

.1. Planillcaciin...
(ttnfittttuciittI

llegoclclC)lrcs

con\ enlcntcs.
p

Disco plra lanifi cac in.

Seccin 7.7. <Diseo para

p I an i fi cac i (rrr >.

Uso de tercnicas de cicsarrollo incrcmcntal.

( ittulo -. ,, Pllnrfre
del ciclo dc vida>.

rrcrirn

5.

Diseo inadecuadt'r Tcncr tiernpo snflcicntc

para Llna actir iclad cle diseo 1" planificacin e.rplc itos.

rp itu lo 7.

.,

PII

ni

l'iclc rtln

dci ciclo dc r ida>. v

,<Disco>. en Secci(in .1.:,

Tcner inspeccioncs dc
clisco.

<lnspecciones>. e-n Seccin .1.-i. 1' resurnen

en Captulo 23.
<I

t-tspcccionc-s>>.

Sndrome de la
panacea

Ser escptico sobre los plobler.nas clc

Scccin I 5.5. <Sindronr.' de la panacea>.

productir iclad.
C

onflglrrar un proqranra

(iapitulo 26. <Medidas,'

CaptLrlo 15. <Hcrrarnicntas para
attr.ncr-ltar
lt

cle medidas dc sollw'are.

Confleurar un erupo clc herratricntas de sofin,arc

productir idad>.
Dcsarro llo orientado a la
inr,esti-gac in

No intente inr estigar v nrarirnizar la r,clocidad dc dcsarrollo al misnro

,<Desarrollo oric-ntaclo inrestigacin>. en la Seccrn 3.i. C'aptulo 7. <Planlfi,:.,, del ciclo de vicla,,. Este capitulo.

.,

tlelrpo. Utilice un ciclo clc vida orientaclo al riesgo.

Gcstione los riesgos con
atenc ilr.

8.

Personal mccliocre

Personal con talento.

Captulo 12. <EqLri

trabajo>. 1, Capttr1,, (EstructLrra dcl cc1L, "
:

Captulo 5: Gestin de riesqos

f11

Tabla 5.6. lCorttitttrut.rt)

Riesgo
Pcrsonal.

\Itodos de control
.. I

Dnde encontrar ms informacin

It ottI ittuuc in

C'ontratar y planificar los n-lie.lltbros clavc del equipo nrucho antes dc quc conrience cl pfo)'ecto.

Captulo 12. <Equipo de trrrbajo,,. r (lpirrrlo 13. <<[stnrctura del equitor,.

Preparlcin.

Captulo 12. <Equipo clc trubrio,,. y ( rrptulo 13. <<Estructura del equipor>. Captulo 12. <Ecluipo de trabajori. y Captulo 13. ,, Fstruclul.u rlcl equipo,,. Captulo 28. <Desarrollo
e.\ te rn

Deflnicin dcl equipo.

t).

Problelltas

cc-rn

Pedir leferencias. Estimar la caracidad clel pcrsonal contfatado antes dc contratarlo.

el re-rsonal
contrataclo

or.

Captulo 28. < Dcsarrollt,

ex tef no)).

Tcncr bucnas relaciones con el personal contratado.

C'aptulo 28. <Desarrollcr

cxtcrno). C'apitulo I 0. <Desarrollo onentado al clientc>

10. Problerras
cl relsonal
c

entr.c dc

desarrollo I'el
lien te

Utilizar las tcnicas orielttrdas al cl icnte-.

Monitorizacn de riesgos
La l'icia cn cl n'undo clel softu'arc seria nrs fcir si los riesgos apareclcsen dcspus de que havarrros desarrolracro planes para tratalos. pcro los riesgos aparecer l" desaparece'r cn er crcsar-roilo crer proyccto. por lo que se neccsrta ura rroritorizacin de riesgos para colxprobar cmo progresa el control cle un riesgo e icrentifrcar ciiro apareccn lcls nue',os riesgos.

Lista de los 10 riesgos princpates

\y
s4-

4 ['["

""1

er la lista.

una de las herramientas.uris potcntes para ra rnonitorizacin de riesgos es la utilizacin cle urra lista de <<Los l ricsgos, creacla por uno mismo. La.l is.ta dc los l0 riesgos urs inrportartcs contienc la posicin crcl riesgo
su posicin

a'terior. er nr'rero cie'eces quc ha aparecido en la

112

Desarrollo y gestin de proyectos informticos

lista'

rcsltlrell c1c lts actttaciorles qltc 'a sc han llci'ado a cabo clestl ejcrnpl la ltinta reyisin. La Tabla 5.7 sigr-riente muestra una lista dc de los l0 riesgos PrinciPalcs'
" Lln

Tabla
E

5.7.

Eiempto de una tista de "Los 10 ilesgos principales'

Scmana pasada Scmanas en lista Riesgo Canrbio de rrcstac ioncs

sta senla n a

Progreso de la resolucin del ricsgo

Utilizar tcnica cle eutrega por etaps: explicacin de la tcnica al Pe'rstlllal clr
tttrrketing fl nales.
-Y

usuaritl'

Disco ittaclecuaclo.
se ncccsita volrcr
di scar.
a

Disco cn t-nal'cha
selecc

lclentificacirl r' in de- tevi sor."

Ote rta dc tt'aba1o a
tL:

expertos. Rcsponsable de pruebas ttt'r

encontracitl.
cancl idatt'r adccuaclo.

estalrtos a la csrcra.

lnestabilidad cle la
rntcrl-az dcl
sr.rbsisteuta dc

clc-

lrlltrir i.lht)rll cl (ll\ell la intcrfaz clc

ttrmato de grhficos:
no sc ha terlnitladtl

fbl'mato de griificos Entf!-gil con retraso clel subsistcma dc

el diseo. Negociar la
cooldinicin de contratados exPerto: Petici(rn al contratatl cle qrtc dcsigne un

tilnnato

cic grirfi cils

encargado.

coordinador oficial:
tocla\ a no ha

lespondido.
Retl'aso ett
lr

tlan llegado 5 de ln:

7 hcrramicntas.

entrega de las

hcrrarrientas de
cle

sarrollo.

El gnrpo dc adquisicitin de
hert'allretrtas na inlbrmado sobrc la neccsidad int-tlecllatlt clcl rcsto dc las herratnicntas.

Capitulo 5: Gestin de ilesgos

113

Tabla 5.7. lContinttutin\

Esta Scnrana semana pasada

Semanas en lista

Riesgo

Progreso de la resolucin del ricsgo

En cvaluacitin.

cle la

iclo de lcr ision clirecciilt

lento.

C'iclo dc rctisi(rn dcl cliente lcnto.

Plan ifl cac itin
d crnrs ia d cr

En cr alr-rciirn.
Se
hr

tenrina(lo

tlcrlrpo el plinrcr hito

Estudio de la ibilidacl de l

optimist.

l0

Arjaciir el lequisito de la actualrzacir-r

autonrrticr dcsde cl nrrinfl'anrc.

actr-ral

izacin ntanual

\rcr el rie s-{o de

canrbio de
prestac i ones.

El rcsponsable de discrio prc'r'cle

tierrpo

danclcr

L,l provecto anterror sc ha trasladaclo a \laska.

soporte a Lln provect() antertor.

No tienc ir.nportanciit cl hecho dc qr,re la lista cle los l0 riesgos principales contenga exactamcnte l0 riesgris. Cor.r.ro se lrluestra en cl rltinlo clemento dc la lista. tarnbin pLlede coutencr riesgos qLlc hayan salido dc la lista clesde la ltirna rcr isin. En un proyecto cle dcsarrollo rpido. el adnlinistrador del proyecto ), cl-ief-e del administrador del pfoyecto cleben rer.isar semanahrentc la lista de los 10 ricsgos principales. La nrayor utilidad cle la lista de los l0 riesprincipalcs es qr.re fucrza a la rcvisin peridica de los riesgos v le -eos infoma de los cambios dc posicin que ha habido segn su importancia.

Comprobaciones intermedias
Aunque la lista dc los l0 ries-qos principales quiz sea la rne.jor fo'rra para la rnonitorizaciiin dc riesgos, uu proyccto acelerado tambin cleberr

incluir cor.nprobaciones intern.ledias durante todo el proyecto. Muchos rcsponsables del proyecto espcran al flnal para hacel la conrprobacin. Esto nos podra bencflciarpara el prrimo proyecto. pcro no serr,ir cuando reall.ncntc lo nccesitamos cu el trrroyecto actr.ral. Para una urayor cf-ectiii-

114

Desarrollo y gestin de proyectos informticos

clad" rcalicc cotrrprobacioncs intcrrredias a pequca cscala despus

de,,-

canzar cada hito plincipal.

Encargado de riesgos
Algunas el.ltpresas dcsi-{nan a un cucarsado de riesgos para estos caso. irl traba.io dcl encat'gac'lo clc riesgos es cstar alcrta sobre los ricsgos tl; pt'o)L-ctr) .\ r-\ itar tlttc los administraclclres y dcsarrolladores los ignor..: en la planifictcin. Al igual que las re"isiones y las comprobacic'lncs rurtnarias" se dcbera tcncr una persolla cuyo traba.jo sca cl de abogaclo ti. cliablo. bttscar todas lrs razones que hagan que cl provccto fhlie. En pr.,yectos grandcs (nts de 50 pcrsonas). el trabio dcl encargado c1e rrc:g,, pucde ocupar ttldo su tierttttt. Iin prol,ectos r-r.uis pcqr-rcos. puede oSr!n.: a otra persona clue tcltsa otras fur.rciones cn el troyccto para qr-rc rea1i..
este papel cuanclo scr neccsario. Por las razones psicolgicas urcnciolt,.c'las. la persona clesignacla no cleberia ser cl aclministrador del provecc

5.6. Riesgo, alto riesgo y azar

Ltt
rtt tt grr i t rr tl tl t' I n!\.qo no e.\ lo

titrito tttt'
n?( (:.\tuilo.\ purLl
I

poder reuli:ur ; t'. |i ttt u t i t tt t'.s

tt tlat i.s it tt c.t entpre.:uriuIe.s. Es .solre totlt el tito tlt, riesgo. Pot' ejenttlo.

,.c.s
t't r s g(

lu clu.sc de

) q It( tt ttl ettt o.t perntitir', t lu t lu.sc dc rre.tgo qu( no tod a nt o.s pcrnt f i r'.)
r'.e.s

utt ric.\go lL01 e.\lruo paro lul espetiulrnente

intportunt( qu(
tto no.s tod<'ttto.;

pt't'rrtitir t'l lujo

de tcntur.
e

in d

cp

nd

e n t t'

nt e ttt a

tle

Iu s ptt.ri bi I idu

dt's.'

Pc.ter Drllcker

En cl dcsarrollo rpido. llgunos provcctos son arriesgados. algr,rnos s nruy arriesgacios y otros son irrprcr.isiblcs. Es clifcil encontrar algirrr pr yccto que no intpliqLrc ningLrn riesgo..v los proyectos que son slo ((ni-gos)) soll los ms apropiados para alcanzar la r.uxima velocidad de cie.,rrollo. Estos rroyectos facilitan la eilciencia y consigucn que la lnea de:.., el inicio del proyecto hasta el flnal sea rccta. El dcsarrollo rapido, qLrc: es necesariancnte fcil de alcanzal'. es mcjor encargarlo ii uha pcrstrr' que domine las estrategias y prcticas qLrc se erplican en este librtt. L,l riesgo alto y cl clesarrollo rpido foman una contbinacin nten compatiblc. Los riesgos tiendcn a prolongar los planes de dcsarrollr.. los riesgos altos tienden a prolongarlos ms. Pero a veces la realiciacl c:: presarial le obliga a eucargarse dc un plan cle dcsarrollo ar.nbicioso. inclLicuando un proyecto implique ntuchos ricsgos (r'agucdad en los rcqursrt, , personal no cualilicado. reas dcsconocidas. elcmcntos de irtr,esti-rrat cluros. o todos los anteriorcs). Si se ve obligado a encargarse de un plan ambicioso en estas cir.cur .tancias. infrmcse de la naturaleza del compromiso. Con dos o trcs ar.r-,,cic alto ricsgo. inclusrr sLrs rrre-jorcs estirnrrciones cn la planificacin p;:.dern su sentido. Asegrrcse de cxplicarlcs a las personas que clepr-nc. dc usted que est disprrc'sto a tornal ricsgos calculados. incluso riesg,. altos. pero que probablemcute no \/a a ser capaz de cntregar a tiertrpo quc estn esperando. En cstos casos. una gestin de riesgos no slo actt. sino tambin enrgica le ayudar a resolr.er n.rejor una situacin coulf t. metida.
r

Captulo 5: Gestin de

ilesgos

115

A1 flnal dc la escala de riesgos. algurros proyectos sc planifican tan agrcsivamente que caen cn el azar. se parecen r.ns a la corr-rpra de un nmero de lotera quc a una decisin calculada. Sobre r-rn tercio de los proycctos tlencn una combinacin intposible de planificaciones, corrjuntos de caractersticas y rccursos. establecida antes de entpczar. En estas circunstancias. no hay ningn estmulo a la hora de rcalizar una gcstin de riesgos. porqlre antes de que el proyecto contience hay un 100 por 100 de probabilidadcs de f'allo. Sino hay posibilidadcs de ajustar las planificaciones nrediante alguna de las tcnicas de gcstin de riesgos, sera razonable apostar 1.000 a 1 por cl desarrollo con la tcnica dc codificar y corrcgir. E,stos proyectos, que necesitan la ve locidad de desarrollo mxima, paradjicamente se convierten cn los proyectos quc probablclnente tiren por la vcntana las tcnicas contrastadas orientadas a la velocidad. Los resultados son inevitables. La apuesta no ha funcionado. y cl proyccto sc ha entregado tarde. rl.tucho ms tarde quc si se hubiesen utilizado ricsgos calculados en lugar tle dcjarlo al azar. ,Un tercio dc los proycctos neccsitan realmente confiar en el azar'l ,Un tercio de los proyectos necesitan tomarse como apucstas 1.000 a l'l Creo que no. Tenga cuidado con el nivel de riesgo de su proyecto e intcnte mantenerlo en una categora de <riesgo> o <a1to riesgo>. Ejemplo

5.2.

Gestin de riesgos sistemtica

La versin 3.0 de Square-Calc ha sido un desastre, superando su planificacin en un 50 por 100. Eddie decidi encargarse dcl proyccto de la versin 3.-5, y esperaba hacerlo mejor de lo de lo hizo el responsable anterior. <Colno ya sabis, Square-Calc 3.0 no sigui mu, bien la planificacin prevista), cont al equipo de desarrollo en la primera reunin de planificacin. <Estaba previsto realizarlo en 10 meses. y tardti 15. Necesitamos hacerlo meior. Tenentos cuatro meses para realizar algunas mejoras, y pienso que tenemos tiempo suf,rciente para poder realizar este trabajo. La gestin de riesgos va a tener una de las rnayores prioridades. Lo primero que voy a hacer es nombrar un encargado de riesgos, alguien que se dedique a buscar todas 1as cosas que podran ir mal en este proyecto. ,Hay

algn interesado?>

Jili haba trabajado en el ltimo proyecto mucho ms duro de lo que ella queria. y cstaba dispuesta a evitar que le ocurriera de nuevo, por lo que dijo: <Yo estoy dispuesta. Qu tengo que hacer?> <Lo prirnero que tienes que hacer es crear una lista de los riesgos conocidos>, le do Eddie. <Quiero que te renas esta maana con cada una de las personas del equipo de desarrollo y que encontris cules son los riesgos que se conocen. y lueeo quiero que te renas conmigo csta tal'de.
Estudiaremos los riesgos y partiremos de ese estudio.>
l( ()lllUtUU
\

116

Desarrollo y gestin de proyectos informtcos

Esa tarde, Eddie y Jill se reunieron en el despacho de Eddie. <Tod. incluida vo misma, pensanlos qr"re el mayorriesgo es el cdigo de Squar:. Calc 3.0. Es una autntica chapuza>, dijo Jill. <Ninguno de nosotr,-. quiere realizal rnodificaeioncs irrrportanrcs. y hay algunos rndulo. c.:

nadie se atreve a tocar.

El siguiente riesgo imporrante es la planiticacin de la creacin cmanual de usuario. En parte. la entregarlos tarcle debido a que no nos crrr,:dinamos bien para crear el manual de usuario. Nos aseguraremos de q,-. esto no r'uelva I ocurril. El ltimo riesgo impoftante son los calnbios en los requerimientos. HaL:,_ varias caracteristicas que no entraron en la versin 3.0, por lo que ter.i,

que marketing intentar colarlas.> Jill sigui comentando una doce::-, de riesgos menos inrportantes. pero los tres primeros eran los ms ir:-.portantes. <De acuerdo. quiero qr.re preparis un plan de gestin de riesgos pa:.-. los riesgos principales>, cljo Ecldie. Le coment a ella la idea de los 10 riesgos principalcs y dijo que quera revisar semanalmente con el equipo ,. lista de los l0 riesgos principales. Para la gestin del riesgo del cdigo anterior, decidi analizar su ba:: de datos de errores para cltantos mdulos del sistema realmente tendian _ producir errores. Asignaron un mes de la planificacin de los cuatro mese: a dedicarse a volver a escribir el cdigo de los mdulos ms propensos :
errores.

Para el riesgo de la creacin del manual de usuario, decidieron cisarrollar un prototipo desechable de interfaz de usuario que utilizara ,-nisma interiaz que el cdigo que estaban escribielldo. No permitiran o.f'erencias externas con el prototipo. Tambin incluiran un inforrne de ,., documentacin de usuario en las reuniones semanales de gestin de rie.gos, que les ayudara a sincronizarse con el trabajo de la creacin de ,. docullrentacin. Para el riesgo de los cambios en los requerirnientos. Eddie se comprolneti a hablar con alguien del departan,ento de rnarketing. <S que su ob,jetivo principal es tener el producto a tiempo>, dijo. <Necesitamos recul:)irar la confianza del cliente despus de los problemas de planificacin de i" versin 3.0. Les explicar la importancia de la definicin clara de objetivos, y pienso que cortarn los carnbios en los requisitos.> Tambin invit ;, Carlos, del Departamento de Marketing, a asistir a las reuniones de riesgos, pensando que si alguien de nrarketing comprenda todos los riesgos ; los que se enfientaban, rnarketing podra evitar que se cayera en nue\,oi
nesgos.

Durante las cuatro semanas siguientes, la identificacin y sustitucin de los mdulos propensos a fallos marcharon segn lo previsto. Se vio que

el 5 por 100 de los mdulos causaban un 50 por 100 de errores. Fueron

capaces de volver a disearlos e implementarlos cuidadosamente. Sometieron cada mdulo a una revisin durante cada etapa, v lo realizaron en el

Captulo 5: Gestin de

riesgos

117

tiempo previsto, lo que hizo que se sintieran bien, ya que el cdigo de la versin anterior podra soportar el resto de las modificaciones que se tenian que realizar para crear la versin 3.5. En la eunin de resgos semanal de la sexta semana, Jill apareci con una tarea nueva. <<Como ya sabis, he estado supervisando algunos de los riesgos de menor prioridad adems de la supervisin de los riesgos ms
impor'tantes, y uno de ellos es ms importante de 1o que se pensaba. Bob ha estado trabajando intentando optimizar algunas de las funciones de clculo cientfico, y me dijo hace unas semanas que no estaba seguro de cubrir las especifi caciones previstas. Aparentemente, haba investigado los mejores algoritmos disponibles, los haba implementado, y la$ funciones slo eran un 50 por 100 ms rpidas. Las especificaciones hablaban de una mejora en la velocidad del 100 por 100. por 1o que Bob est intentando encontrr otros algoritmos ms rpidos. Le he comentado que coloque un punto de alerta roja en el plan, para que si no lo realiza en el tiempo previsto, podamos dar una seal de alerta. Ayer alcanzamos el punto de alerta roja, y Bob dice que an necesita ms tiempo para terminar su trabajo. Bsicamente pienso que como est realizando un trabajo de investigacin, no hay forma de predecir el tiempo que va a necesitar.>> Carlos, del Departamento de Marketing, dijo algo. <He sido uno de los que han apostado por la mejora en la velocidad, y pienso que la cifra del "100 por 100" es flexible. Es ms importante terminar el producto a tiempo que seguir el requerimiento de velocidad al pie de la letra. Al menos podremos demostrar a nuestros clie ntes que somos personas responsables.> <Eso suena bien>, dijo Eddie. <Pienso que una mejora del 50 por 100 en el rendimiento es suficienteo por lo que le diremos a Bob que se dedique a hacer otras tareas. Eso har que tengamos un riesgo menos del que preocu-

parnos.)
Despus de esto, aparecieron otras sorpresas. Se produjeron algunos cambios pequeos que se pudieron controlar bien. Comparndolo con el ltimo proyecto, ste haba sido un poco aburrido, por 1o que nadie lo recordara. Algunas de las personas de marketing intentaron aadrr nuevas caractersticas, pero Carlos consider que 1o importante era el objetivo del plan y as mantuvo las quejas a raya, sin que llegara a escucharlas el personal de desarrollo. El equipo hizo un buen trabajo y entreg Square-Calc 3.5 en los cuatro meses previstos.

cliograf a adicional
Boehrn, Barry W.. ed.'. Sofiv'are Risk Management. Washington, DC: IEEE Computer Society Press, 1989. E,ste conjunto de trabajos se basa en la premisa de que los buenos administradores de proyectos son buenos administradores de riesgos. Boehm ha recopiiado un conjunto de trabajos a partir de fuentes tcnicas y empresariales. Una de las princi-

18

Desarro//o y gestin de proyectos informficos de este libro es lacontribucin de 70 paginas q... ha realizado el nrismo Boehm. ErLr zo pginas suponen una buei:inrroduccin a ra gestin a. .i.sgo, er softivare. p;;;;-ii"gr. a pe r:sar que un ruroriai pubricado .n lq's p"dri; il;.;;;r;: obsorer, pero en realidad presenta una visin

pares caractersticas

."Tl'":Hfi:r*:,ir:esrin c' nirt *, ces> rEiE sorrnyl;, enero reer, oo fiil:,iJ'fi1:1,:: iti,i.T;:. puntos clave de a sori,,, Rick Man,r";;,':;:;ffiH'ff.il: .]3;irffi.;LXjJ. Jones, Capers: A.s.yessment
Boehm, Barry W.: <,Softrvu..
riesgos que ra que puede encontrar

gravedaddelriesgo,fiecuencia.o.,,l3.^cadariesgo.ydescribe "rtnur'
vo. Iibros. public ,r: c h o s ct e' r, ul,, ir' 0".';:;:'J:'.', t i " de la base de" datos de JonJs,.on.r.4.000
bremas asociados, mtodos o.

cambio, describe con derare zo . tes. Jones utlliza un formato

to extraordinario para el tutorial sobre de riesgos de Boe h: No comenta .urinuau de la gestin o. 9"t"un

o.f.Softwar.e cliffs' N'J': yourdon press, lqq+. alli.o

qnd Contro/

Risks. Englerit . de Jones.r"un .J.pr"n,.,

i", ,ii:::-,oll::Hi'"11.-i,liT,l;

o*".".i"- l;;lliiii"lili""lll;L
ffi "bff
:

que esta especialmente indicado para el tema de la estimacin cle r:..._ gos' Er mtodo de desarrolro . *rt'"u." que describe Gilb en el r:.del libro pone mucho nfasis g.rriO" de riesgos. Thomserr, Rob: Thirct "" (1ve!rolec, iri,rr"n/. Englewood Cliffs. \ Yourdon press, 1993. El fi6.o.onri.il un.u.rtionario con,t.l r:.._ guntas sobre Ia sesjin de riesgos, que puede utilizarpara hacers., ,.: idea de sj el nivel de riesgo O. ,u proy..to es bajo, medio o alio.

Gilb, Tom: principle,s Srtror" in-[in]nrirg Maragentenl. .oJ. Woki::_ham' Ingraterra: Addisonlw.rr.y, i. pr," Iibro tiene un capir'.

"""rm:fi li proyectos sofni.are

;

r#
f-

fe

#ffffiffiffi$
iffiffiffiffiffiffi

#ffiffiffi ffiffiffi ffi

$ffi

Cuestiones fundamentales para el desarrollo rpido

Contenido

6.1. 6.2. .3. 6.4. 6.5. 6.6.

6.1

,Eriste un modelo rnico'.'} ,QLr tipo de dcsarrollo rpido necesita'l Posibilidatl de tcrnlinal a ticmpo

6.8.

Pcrccpcin y rcalidad Distribucin del ticmpo ernplcado Equilibno de factorcs de la vclocidad de desarrollo Patrn tpico de mejora de la planificacin Canlino hacia el desarrollo rpido

Temas relacionados
Estrategia para el desarrollo rpido: Captulo
2

UNA VEZ QUE HAYA APRENDIDO A EVITAR los errores clsicos y haya asirnilado los fundamentos del desarrollo de softlvarc y la gestin de riesgos, estar preparado para centrarsc en mtodos dc desarrollo orientados a la planificacin. El prirner paso en csta dircccin es contprender ciertas cuestiones que radican en el ncleo de la mxima r.'elocidad de desarrollo.

Existe un modelo nico?

Para desarrollar

el control de un marcapasos usar tcnicas disrintas

que para desarrollar un sistema de control de int,entario para cintas de vdeo. Si un error dcl software hace que se picrda una cinta de cacla 1.000. puede que afecte levcmente a los beneficios. pero no irnporta. Pertt si un
121

122

Desarrollo y gestin cle proyectos informticos

error

hrce

quc sc picrda urro dc cada 1.000 rrarcapasos. tenclr serios

pr.rr-

bler.nrs.

REFERENCiA CRUZADA Para ms rnformac n sobre la persona izacin de los procesos del software segun las necesidades especificas de los proyectos. consu te la Seccin 2.4. ,, Cul es la dimensin ms mportante?.

Dif crentes provectos ticnen dif'ercntes necesicradcs cle clesarrollo rpido. aunque toclos necesiten ser dcsarrollados <tan rpido cono sea posrble>>. En trminos -gencrales. los prodr-rctos ile gran clitusin neccsitan s..: clesarrollados con ms cuidacio que los productos con poca difusin. Lt,. productils crry'a fiabiliclad cs importante necesitin scr clesarrollaclos ct',: ms cuiclaclo que los procluctos cuva fiabilidacl no ticne r.nucha importancia. La Fisura 6.1 nruestra algunas cle las variaciclncs en distribucin. l'irrbilithLi. Las qrtraclas cspecficas cle la cuadrcula son slo meros cjemplo. Podra scr cliscutible por qLr un controlador de pantalla o un progronc trr iurpuestos necesitan scr ms flables. o si el software cle autoeclicin cl 1.. hoias dc cirlculo licnen mayor difirsin. Sc trata de ver que tanto el rr:brto clc clistribucin corro la l-iabilidad necesaria varan arnnlianrcnr; cntre dibrgrtes ti.ros dc soliri'arc. Un firllo dc- softnare pLrccle acarrc.rl pe!rcliclas de tienrpo. trabajo. clincro o vidas humanas. Algunos rntoilo. dc ciesarrollo oricntados a la planificacin, quc sou perfectalrente acetrtables cuanclo el tiempo de desarrollo es lo nico importante. seran abscIutame'te inaccptables cuando hay humanas dc por nrcclio. 'idas Por otra parte. los mtodos cluc pucderr considerarse rpidos chap/ ceros en ulr slstenra crtico para la rida pucderr resultar demasiado ri-cL.fosos para una aplicacin clc soft'ulare de ncgocios. El desarrollo rpi.: cle soltu'arc dc clistribucin linritacla puede constar de cosas qr.re consicler.,-

.F .=
't

N,4ercado

hri7^tal

""" oi",o.

. JflSiliTto

Hoj"

cre

.:fi:"3:
Mercado verltcal

E e
E

.:;,::3::i;
u1

"*,""

a orog'nd

crcuro,
oard

sistema operativo

..ff::::""i."
o

.:fi"il3"1:0""?"""'
gerp..

"

0""

';:?:'il: :f,:',i:""

t:::ii:"."

So'lwa'" o' et.. ro , ,

.;;l;1;5" "

vroeoclJo

.:l"Hn:S"":3i:'',0" -st5terd de..onlro de p,oqramo oe b,il'"i'i! !!g,,os inveccrn de combust br pr

Personalizado,

interno
Personal

'"r i" .-i.ir

Aplicaciones

Prog'Td O de segr rrenro de voelas [/:, ,, ,, -,

p oqraa oe Sonwdre de lrzade _ ! coti'o oe Oresras a

oe ca,Terag

IierPo'el

en

e5odcral

Sistemas

Sistemas crticos para la vida

Fiabitidad requerida

Figura 6.1. Los diferentes tipos de software requieren diferentes tipos de soluciones. Mtodos que se consideran rpidos y bastos para un contt: de marcapasos pueden resultar excesivamente rigurosos para un libro de cocina interactivo.

Captulo 6: Cuestiones fundamentales para el desarrollo

rpido

123

ramos <<menudencias) cu sotiu'are cle mayor distribucin. Pegue hor. y no naalra, algunas piczas que resuell'an el problema dc hov. Maana podra ser denrasiado tardc: una solucin tarda podria rcsultar inrtil. Como resultado dc esta tremenda variaciin en los objetivos clc desarrollo. es inrposiblc dccir <Aqu est su solucin para desarrollo rpido> sln conocer las circunstrncias cspccficas del caso. Lt solucin corrccta depcnde de la posicin cn quc se encuentre en la grfica cle la Figura 6.1. Muchos productos no eucaiau claranrente er.r las categoras de la figura. y los prodr-rctos varan tarnbin en otras caracterstlcas clistintas clel grado de flabilidad y el n-rbito dc distribucin. Esto implica qLre la mavorr dc personas tendrn quc llcrsonalizar una solncin parr sLl propia situacin. Como muestra la Figurr 6.2. no eriste un nroclclo nico.

Qu tipo de desarrollo rpido necesta?

iurportantc rclacionado ccln el clcsalrollo rpido cl tipo dc dcsarrollo rpic1o que neccsita. ,Necesita un ligero aurncnto dc r clocidad. mayor predicibilidad, rtte' jor r isibilidad clel progreso. meuores costcs o l'ns r'clocidad a cLralquicr costc'l Una cie las cosas r.t.ts sortrrrcnclcntes que descr-rbr al rcalizar la tnr"estigacin cie base para cslc libro cs ct-tc nruchrs pcrsoni.ts qLrr- inicialntente
r.ns

El tcrra plimordial

es deternrinar cuil es

fr.fr

Figura

6.2.

No existe un modelo nico.

124

Desarrollo y gestin de proyectos informticos

clescubren quc lo que realdicen que necesltan un desarrollo ms rpido mayor preclecibilidad (o simplemente necesitan es Lln menor coste o una mente una iorma c1e evitar un fallo catastrfico)' para ayudarle a determinar el tipo Pr-reclc plantearse varias preguntas de dcsan'ollo rlrritio qtte tlecesitlt:

o . o

de la restriccin de planificacin del producto'' ,Cul es la fuerza del proyccto ha surgido porque es

),Ef nf'asis en la planificacin rpido>'l realmcnte ltna cle las uapariencias del desarrollo por cualquier punto d-bil que podrla liniclo ,Stt proyecto cst xito'l impedir llcvar a cabo el clcsarrollo rpido con

a estas pregunlas Las siguientes seccioncs describcn cmo responder

productos con fuertes restrcciones de planificacin

Losprocluctosqtlenecesitanrealmentecentrarseenalcanzarlarnxintr o la prcdecibilidad tiel-rerr r.clocitlacl de clcsarrollo sin in]portar el coste
uno.,.u"ticrr-rpo-valordistintaaladelosproductosnonrrales.Conromues- de la Figura 6 3' el valor tra la lrrea cle ralor clc r'rn protlucto normal en con c1 paso del tiempo' Erl un prndu.to nornlal clisnlinuyc gradualmcnte

cambio.conullprocluctoqu.ti."n.unafuerterestriccindeplanificacirl. precipitadamente hay un punttl en el que el ialor del producto disminuye Parautlprclcluctollorl-nal.eldcsarrollocficicnteofrecegeneralment.y rendirniento de 1a planilila mcjor conlbinacicin cle coste de clesarrollo

Productos con fuertes restricciones de planif icacion

Tiempo

Figura

en una ianta urgencia en terminar un producto normal una fuerte restriccin de e x,-qlente para et caso de un producto con

6.3. Representacin det valor a lo largo del tiempo de No hay de planificacin' normales y productos cin fuertes restriccione fecha concreta con:

productos

: =-':acin

Captulo 6: Cuestiones fundamentales para el desarrollo

rpido

125

cacin. Pero es posiblc que su producto tenga qus estar listo para la tenrporada dc Na'idad. o si no" rcnga que espel'ar al ao siguicnte. puecle que necesitc el-cctnar un cambit'r cn el sistema de nntinas a tientpo para cr-rr.nplir la nueva normativa flscal. Puede quc su cmpresa est a purrto de quebrar. y necesite los ingrcsos de la r,enta del producto para salvarla. O puedc que nccesite enfl'cntarsc a un producto cornpetidor. y espere doblar sus beneflcios si pueclc adelantarse seis senranas a sLl courpelidor en vez dc sacar el producto dos semanas despus. Ccluro sugiere cl grfico. en estos proyectos pucde haber un pulrto i partir del cual si no ha terminado el producto es como si no hubiera hecho nada. E,n estos casos. plrede resultar apropiado centrarsc por cor.npleto er.r la vclocidad de dcsarrollo.

Apariencias del desarrollo rpdo

E,n algunos cascls. la demanda de <desarrollo rpido> llcga por un carnino procedente dc los usuarios o clientcs. o dcsde los altos cargos. stos pLrecien aplicar una prcsin increble para hacer que un proclucto se terrnine ms rpido. pcro en ocasiones lo que dcsean realmente es ufl rrenor coste o fllcllos flesgos. Simpler.nente, no sabcn c,-o pedir esas cosas. o no saben que csas cosas n() ran ligaclas a la Vclocidad mxir.na cle dcsarrollo. Antes dc oricntar sll proyecto hacia la rlanilicacin nrs corta en vez de hacia el l'nenor coste o la u.re-jor funcionalidad. dcscubra lo que realmcnte se ncccsita. Hay ralias apariencias del desarrollo rpido que pareccn clar-uar ror alcanzar la mxima r,elocidad dc desarrollo. pcl'o lo qr.re realmente piden es olra cosa; \,arros a describirlas c. los sigLrientes apartados.

Evitar retrasos. Si la organizaci(rn dc soriu'are tiene un historial cle ercedcrse cu sus presupLrcstos y' planificaciones. cl cliente puccle pcciir <dcsarrollo rpido>. Sir.r embargo. en este caso. lo que er cliente c'lesea rcallurcutc es asegufarse de qr-re el proyccto se terminari ajustndosc a los pllzos y plcst-tl)uc:t0s t|cr istos. Puede distinguir cste aparente dcsa.'ollo rpido de la nccesicracl dc alcanzar la mxir.na rclocidad dc desarrollo cor.nprobanclo que no cxiste otro objetiro especfico de planificacin quc. tclminar (tau pronto conlo sca posiblc>. o bien. si hay un objetilo eslccfico. encontrando que naclie pucdc erplicar su inrportancia. Un historial dc proyectos retrasaclos puecie scr otra pista. En cste caso. la solucirin no consiste cu usar mtodos orientados a planificacin. sino usar uua mc-jor gestin de ricsgos, cstirnacin del proyccto y control de la directir,a.

Predecibilidad. E,n muchos casos. los clientes dcscan coorclinar la parte de desarrollo de soliware de ur.l proyecto con previsiones cle beneflcios. rurarkcting. planificacin dc personal y otrcls proyectos sofilvarc. Aunquc

126

Desarrollo y gestin de proyectos informticos

pucden pcdir <desarrollo rpido)). reiilmelttc cstn dcltttrtdarlclo [lna prcclccibiliclad sutlcicntctnente bttena para ptldcr coorclittar los csfuerzos r.-lacionaclos. Si sus cliurtcs hacen nf'asis clt la rtccesiclad clc tcrnlitlat'c sclttu.arc <a tiem.ro>i. no tienen ningLrnr rcstriccin externa tal cttt.l'lt' una prescntacirT cn una l'eria. probablemctttc estn rtts preocttpados ptr: la prcclecibiliclacl c1r.rc ltor inclementar al mrirrro la r.clociclad cle clesarrollo. En estc caso. debe ccntru'sc cn el desarrollo cficiente. y haccr hirlcapi cn nrtodcls que recluzcan cl ricsgo de planificacin.

REFERENCIA CRUZADA Para ms nformacin sobre la reduccin de 1a p anificacin. consulte ,, Los costes se incrementan rpidamente al reducir
r^ ^.^^"^--^:^ ra v u9, a,,,ou,u, I ^^, Pul

debajo de la nominal.. en a Seccin 8.6.

Menor coste. No cs raro que los clicntcs deseen nrinin.rizat'el ctlstc cic Lln proyccto dc dcsarrollo cie sofi'ur,'arc. E,n estos casos. hablarn dc tclllr;nar pronto el sofiu arc. pclcl harn rlf'asis cn su preocupacitl por el pr.-supuesto r no sobre la trtlanificacin. Si la preocupacin principal de los clicntcs cs el coste cle un provecto. centrarse cn la planificacin dcl cicsarrollo resulta particulan.l.tcntc cle:afortunado. Attnque resulta lcigrco sLlponer quc 1a planiticacin trs cort., clc desarrollo es tambin la ms barata" actualtnentc los mtoclos qLte ttlintrnizan el costc y la planificitcitx son clilerentes. Alargar algo la planificaci(rn pclr encima de la inicial , clisnrinuir el tar.uao del equipo puetl; reducir el costc total de Lur pro-vccto. Algunos r.ntodos dc desarrollo rapiclo increnrcntan cl coste total.
Fecha fija de prdida de valor. Clorrro se mLrestra en la Figura 6.3. e:: ocasiones cI ralor cle un proclucto dismirluye patrlirtinamcnte a Io larg. ciel ticmpo. v cn ocasiotres clescicndc precipitaciamcltte pasado utl cic-rt. llunto. Si eriste un punto en el cual clcscieltde precipitadamente. parc.. lcigico decir: <Ncccsitanros toda la r.clocidaci posible de clcsarrollo. plr; cstar scguros dc quc cntregarentos el prodttcto antes de esc punto.) Sin crrbargo. lr rrecesidad clel dcsrrrollo rpiclo depcndc realmetlt: del ticrnpo c'lLrc se tenga para realizar el proyecto. y del tierrpo llcccs0l'lr para desan'ollarlo usanclo r"utoclos de desan'ollo cf icicntc. La Figura 6 nrucstra dos posibiliclacles. Si puede conrpletar el prol,ccto en el perodo I (antcs cle la f-echa d; prclida clc valor) usanclo nttodos de desarrollo cflcierltc. h-qalo. y ctltrc:; en la lcduccin de riesgos y no cn la velocidad dc desarrollo. Esto ofl-cccr., la r.nayclr posibilidacl de terminar el pro,vecto a tiernpcl. Al-guncls mtodtri de desarrollo rirpido clisnrinuyen el tierlpo dc desarrollo. pcro increnlentr: tunlbii'n la incel'tidtrnlhrc de lr pl.rnil'icaeitjn. ser'rr ttn crror usar lllct,'clos que increr.nenten cl riesgcl de la planificacin cn esta situacin. Si los mtodos dc dcsarrollo eflcicntc no pen.ttiten por s solos ternllnar cl pro;-ecto antes dc la fecha de prclida de ralor (por cjernplo. si stil' permiten terntinar el proyecto en el pcrioclo 2). etltonces necesitar us.,mtodos orientados a la vclocidacl para tcncr alguna oportunidad de tel'minar a ticrnpo el pro.vccto.

Captulo 6: Cuestiones fundamentales para el desarrollo

rpido

127

Fecha de prdida oe vator

Tiempo

6.4. La necesidad del uso de mtodos de desarrollo rpido depende de Io pronto que necesite el software. Si puede desarrollarlo en el perodo 1 usando mtodos de desarrollo eficiente, debe hacerlo y mantener as los riesgos bajos, en vez de centrarse en tcnicas orientadas a la velocidad, que pueden incrementar el riesgo.
Figura Deseo de horas extras gratuitas. En escasas ocasioncs. el inters dcl clicntc (o directiro tor el desarrollo rirpido enntascara cl deseo de mcjorar la basc dcl desarrollo rapido sacancio todo cl tientpo crtra gratr-rito clc desarrollo posible. La scnsrcin dc urgencia creada por uua planificacin
ambiciosa ayr.rda a esta situacin. Esta circunstaucia es lcil cle distin-euir del verciadero clesarrollo rirpiclo. porque el clientc insistir cn la irlportancia dc la planificacin y, sinrultneamente. se negnrti a ofi'eccr cl soportc nccesalio para mejorar la rclociclad de desarrollo por cualcluict'otlcl ntcclio quc no sean las horas ertlas sin relrunerar. El cliente no insistiri cn tcner rns personal. mcjorar las hcrramientas hardu are" tencr r.nejclres hcrrarrientas softu are u otros tipos dc soporte. El clicnte no scri particlario cle analizar la posibilidacl cie reducir
las prestaciolrcs pafa alcanzar ob.jetir os de planificacin. En un vcrdaclercr

proyecto de dcsarrollo rpido. el clientc estar dispuestcl a considcral cualquier rredio para reclucir la planificacin. Si cumplir lir planilicaci(tn del proyecto es suflcientententc iutportante para ser presionaclo. tantbin es sullcicntenrente irnportunte para que el cliente increnrcnte el nivel de soportc al proycctct. Si la emprcsa ride a los er.r.rpleados que trabajen r.l.rs duro, tambin debe estar dispuesla a trabajar r.ns duro. Si se cncuentrl en Lrna situacin er.r la que su cliente est intentando simpleurcute hacerlc traba.jar gratis (incluyencio a su cquipo), es probable quc l.ro pueda haccr nada para rne.jorarla. Los clientes quc practican este estilo dc dcsarrollo cle softr,r'arc uo tielten preseltte lo ntcjor para los clerrs. Las opciones que le qr-rcdar.r son rehusar trabajar cn tales proyectos o cambial dc empleo.

128

Desarrollo y gestin de proyectos informticos

Realmente necesita el desarrollo rpido

a toda costa?
Es habitual que los clicntes. incluy'enclo usuarios filales. r.cncledorcs. c]ir.., tiros y otros. piclan sicnrprc nucvas presracloncs v nuevas r,ersrones. p...

los clientcs tarnbin son conscicntes cle los probler.nas qr-rc puedc causr.

coste cn poco ticrr.rpo. pero gencralnrcnte s<ilo rccogcri uno o dos cle es. tres dcscos. Dcsarrollar un producto cle baja caliclacl cn poco ticmpo:1.. ser la combinacin crrnca. Si entrcga a tier.ntrro un trrroclucto cle bl.jl .,. dad. la gente rccordar quc era cle poca calidad. no quc se entrcg(r a ric.,:-

actualizacitin dc un producto. Tenga presente que los clientes dcsean... equilibre el proclucto. el coste y la planrlicacin de la mejor nraner-a pr'ble. Por sullLlesto. le pedirn que dcsarrolle un trrroducto con un l.-,
-qran

Si cntrega con retfaso un procir-rcto que les cle.ic con la boca abicrta.. clicntes recclrdarn quc desarroll un prodr-rcto impresiorrante; al pas: , tiernpo. la entrega con retraso perder la irnportancir que parece tcrrr.r.: el mornento presente.
Para detem.rinar si las peticiones dc un clie'ntc justifican un esfucrzrr ..clesarrollo rpido total. intente clctcrminar si la lnea cle r,alor del nroclLr,ticnc el aspecto de la lrrea clc los productos nornrales o de Ios prodtictos c fucrtes restriccioncs" nrostradas cn la Fisura 6.3. Deternrine si la plan: cacin est controlacla por una f-echa externa. o si la f'echa cs sirrplcnrer: (tan pronto conro sca posible>. Por ultimo. cleter.mine si los altos cafs . clfi'eccrirn el niiel cle soportc neccsario para un esfuerzo cjc cjesarrollo r..,pido. Tiene poco scntido eslbrzarse si se r.a a carsar con todo el trabr. Si no est segufo dc clue la'clocidad clc desarrollo sca la prior.irr,,. nnrcro uno. trncse su tienrpo y desarrollc un softu'arc dcl quc pue.:, sentirsc orgr.rlloso. Desarrolle Lln programa por el que i,alga la pena csir,rar: los productos dc alta calidad son ms diflciles dc clesbancar quc 1,, prodr-rctos trediocres desarrollados con rapidez. La historia dc la inciustria dcl softrrn'arc para rnicrocor.r.rputadoras c:.. repleta de e.icmplos dc productos quc se tcrminaron tarclc. pero que h"adquirido una inmensa popularidacl. E,l desarrollo cre Microsofi worcl l
_

REFEBENCIA CRUZADA Para ms lnformac n sobre el desarrollo de Word para Windows. consulte .Un ejemplo de planificacln excesivamente optrm sta,,, en la Seccin 9.1
.

para windows fuc planificado originalmentc para hacerse cr.r un at,. . neccsit cinco (lansiti. 1991). Microsofi winclou,s 95 fue entregaclo L.rario y medio ms tarcle de la f-echa anunciada originalnrente (cusunrar-; y Selbr. 1995). y se ha convertido en uno cle los productos softrvarc'e1rdidos rns rpidanrente. un producto financiero en el quc trabaj ii: . entregado con un 50 por 100 dc retraso respecto a la planificacin ong nal de la empresa. pero se conr,'irti err el producto softrvarc nrs populr,: de dicha clr.)presa. Para cada uno de estos procfi-rctos. la entrega a tlemll, (segrr la pla'ificacrn original) ro era un fhctor clar.e. aunqne todo e mundo pcnsara que la planificacin del clesarrollo cra un factor crtico c:su lll()r-rlefrto.

Captulo 6: Cuestiones fundamentales para el desarrollo

rpido

129

.3,

Posibilidad de terminar a tempo

Muchos proyectos parecen progresaf lentaurcntc: sin er.nbalgo. no todos los proyectos van despacio del misnlo modo. Algunos esflerzc'ls de desarrollo son realmente lentos. y otros siurplcr.ncntc lo pareccu. cicbido a la imposibilidad de clesarrollar los esfuerzos estinrados. Uno de los enfoques cle la estinracirr de llroyectos softwarc mantiL-ne que todo proyecto tiene una f'echa eracta err la que debe ser tcrminado. E,stc er.rfoque nrurticnc que si el proyecto se ejecuta corrcctamentc. exislc- un 100 por 1 00 de posibilidadcs dc quc sc tcmine en ulla fecha determinacia. La Figura 6.5 muestra una rcllresentacitin grhfica de cste punto de vista. La erperiencia de la mayora dc los desarrolladores no courparte este pLlnto de rista. Hay r.nuclias incgnitas quc particjpan en la planificacin dc softu'are. Las circunstancias cambian. Los dcsarrollaclores aprenden nrs sobrc cl proclucto que constrLrycn a nrcdida que lo desarrollan. Algunos mtodos funcionan mejol de lo espcrado. y otlos peor.

Los proyectos softu'are contienen demasirdas variablcs couro parl poderdclinirplarrificacioncs con un 100 por 100 de exactitud. E,n lugar dc
tenef Llna f'eclra particular cn la que debe terrninarse un proyecto. para cualquier proyecto dado criste un rango de fechas dc finalizacin. dc las cualcs urlls son ms rrobables que otras. La distribucin de probabilidad dc cstc rango de fechas es similal a la cun'a mostrada en la Figura 6.6 (r'asc pgina siguiente). La fon.na de esta curn'a de probabrlidadcs expre sa valias hiptitcsis. Una de ellas cor-rsiste en quc eristc rLn lmitc absoluto sobre la r,elocidad a la que sc puede ten.r.rinar cualquier proyecto. Terminar antes no es silnplcmcn-

:
:

==ERENCIA CRUZADA

-: lrOrmaClOn
soore ras

:, res lo rns
' aac ones lo : -:as posrore-.

Secc n 8.6.

Posibilidad del 1009o de termrnar en fecha prevista

la

---+

Probabilidad de terminar
exactamente en la fecha programada

Fecha final programada

Figura 6.5. Un enfoque de la planificacin del software. Defiende que el proyecto tene un 100 por 100 de posibilidades de estar termnado en una fecha determinada.

130

Desarrollo y gestin de proyectos informticos

Probabilidad de terminar
exactamente en la fecha programada

Fecha final programada

6.6. Forma de una planificacin de software. Debido a tas incgnitas que influyen en un proyecto software, algunas fechas de finalizacin son ms probables que otras. pero ninguna de ellas es totalmente cierta.
Figura
te clifcil: cs inrposible. otra hiptitesis consiste cn clue la fornra de la curva cn cl laclo <inicial> no cs la nrisrna quc en el lado <<flnal>. Aunque existc un Irrite estricto sobre la rapidcz con quc se pr-rccle terntinar un proyecto. no cristc tal lnritc para la lentitud con que se puede terminar. como es urs fcil terminar trrcie Lln proyccto quc ternrinarlo antes dc tienrpo. la forrra de lr curva en cl lado firal es ms graclual que er1 el lado inicial. Tor.n DeMarco pl'opLrso qr-rc los proyectos deben ser planificados para cluc la probabilidad de cntre-qarlos antcs de tiernpo sea la misma que la de

cntregarlos tarde (DeMarco. 1982). E,n otras palabras. dcflnir la planificacin del proyccto para tener un 50 por 100 de posibilicladcs de ternrinar' a ticnrpo. colro se lluestra en la Figura 6.7.

I
i

Planificacin

lProbabilidad de terminar
exactamente en la fecha programada
Probabilidad de terminar antes o en la fecha final prevista

"equilibrada" 50/50

Probabilidad de terminar despus de la fecha prevista

Fecha final programada

6.7. Planificacin equilibrada. Existe un lmite en la velocidad mxima a la que se puede completar un proyecto, pero no para el tiempo que pueda prolongarse su desarrollo. Esta planificacn ofrece un 50 por 100 de posibilidades de terminar a tiempo.
Figura

Capitulo 6: Cuestiones fundamentales para el desarrollo

rpido

131

La cstrategia dc planificacin ecluilibracla de DeMarco es ull pttnto til para avanzar en la cotllprensin del desarrollo lcnto. Ptrcde por dil'idir el grlico de probabilidades cll \'arlas zollas. feprcsencoltlellzar tando cada una de ellas una cliftrcrrte vclocidacl de desarrollo. colllo se nlucstra en la Figr.rra 6.8. La zona clcl crtrer.r.ro izquierclo dcl grfico cs ll (zotla de clcsan'ollo ilnposiblc>. L,sta zona reprcscnta un nivc'l de productiridacl quc no ha sido rlcaltzldo ltunca por ningitn proyccto. Los lroycctcls planificados cll esta zona estlt colldenados a salirse dc sLr progralllacin inicial. La zona de la izquielda dc la curva es la <zona dc desarrollo rpido>>. Un proyccto temriltado elt CSta zona eS collsiclcracltl rpido. ya cltrt- tiettc lreltos clc Lrn 50 por 100 de posibiliciaclcs dc tertlinar a tielllllo. Ut.t ctlurptr cle desarrollo que contpletc utt proyccto etl esta zolla tirlrrlil.la toclos los
cic particla

pronsticos. La zona central de la curva es la (zoua cle desarrolltt cllcier.rtc>>. Url proyecto que tcrlttina clelltro de esta zolla se considcra eficiente dcbiclo a que no ha ganado la apuesta. pero talllpoco la ha pcrdido. El proyccto se ha tenninaclo ccrca de str f'ccha estiltlacla cle llnalizacirl. Las elllpresas dc desarrollo dc sofiu'arc cficientes planilican y temtiltan sLts prodttctos de tin.na cousistentc en esta zona. que Icpresenta tula bLtctra cotlrbinacin
de plarrilicacin r coste.

El rca de la parte dcrecha dc la curva es ll (zolll cle clesarrollo lcnto>>. Un proyecto terrniado en cStl zolta Se Considera lentc'r lorquc- ttcltc ms del 50 por 100 de posibilidades clc terminar coll 111/ls rctraso. Ell lo qLle respccta a la plarlificaci11. un prOYecto qtle terlllina L-ll r'stu zona Slll intentarlo ha tl'acasado. Tener rito en la planificacitln al 50.50 dependc

Probabilidad de terminar
exactamente en la fecha programada
Zona de desarrollo
I

Zona de desarrollo ef iciente Zona de

--)|.

desarrollo lenlo

Fecha final programada

Zona de desarrollo imPosible

6.8. Distintas zonas de una curva de planificacin. Muchos proyectos buscan la zona de desarrollo imposible (sin saber que es imposible)' y terminan en la de desarrollo lento (sin desearlo).
Figura

132

Desarrollo y gestin de proyectos informticos

dc una estirnacin exacta y dc la obtencin de la lceptueiirn dc tnla cslimacin exacta. temas clescritos con dctalle en los Captulos 8 y c.).

6.4. Percepcin y realdad

Suponga qr.te dentro c'lc scis meses piensa nrudarse a una nueva ciudad situacla a 100 kilmctro\ y ct'rnstruil ulrc nue\,a casa. Contrata a la cnrprcsa constrLlctora Honest Abc para que le cclnstruya la casa. Acucrda pagafle 100.000 dlares a Abc. y ste acepta tener la casa lista dcntro dc scis mescs. para clue pueda mudarse a ella cnando llegue a la ciudad. Ya hr comprado el solar. y Abe dicc clue es adecuaclo. As que cstrcchan sLrs manos. lc paga la mitad dcl dinero a cuenta y cspcra tener lista su casa. Pasadas algurras scmanas. le entra curiosidad sobre crno van las obra: de la casa. as que un fin dc sclrana coge el coche y recorre los 100 kilometros para ir al solar y echar un'n,istazo. Para su sorpresa. lo irnico elrr.' ve en el solar es una zonl con el suclo nivelado. No har cimientcls. nr

estructura ni ningrn otro traba.jo. Llama a Honest Abe y le pregunta <,Cimo van las obras cle rli casa'l> Abe le contesta: <Hentos cr.lrpczadc poco a poco pofque estalnos ternrinando otra casa. He incluido un ticnr,, de resen,a cn mi estimacin dc su casa. as clue no hay por qLr preocuparse.

Est muy ocupado con su trabqo. y cuando tiene ur.r hueco para ir 11. nuevo a ver cl progreso de su casa. han pasado trcs meses. Llega cle nr"rer ,

rl

) csta \cz cncuenlra los eirnientos. pero no sc \c ninsn ot:' Llama a la enrpresa. y le dicen: <No hav ningn problenra. Iist.,traba.jo.
solur"
mos dentro dc 1o planificado.>> Sigue estancio nervioso. pero decide acel'tar la palabra de Abe. Pasan el cuarto 1' cluinto nlcscs. Llama a Atc varias \,eces parl cor'probar sLls prosrcsos. y sienrpre le dicc cluc toclo va bicn. Al principrtr.: sexto ncs. decide ir a ver la casa Llna vcz ms antes dc que est tenlir.,da. Est nervioso por vcrla. Pero cuando llcga al sitio. lo rrico que re .la estructura de la casa. No hay techo. niparcdcs. ni fbntanera. ni in:tr. cin clctrica. calefaccin ni aire acondicionado. Est nerl'ioso y tensr, clecide ir a comprobar algur.ras de las relercncias dc Honest Abe. C.,. prucba qlle para una casa qLrc Abe termina en el plazo comprorncticlo. inruchas que termina con un 25 a un 100 por 100 de rctraso. Est enf.,-,.do. <Han pasaclo cinco de seis nrcscs. y no ha hecho casi nada>. le g: <,Cundo vov a tener mi casa'l Nccesito mudarme a ella dentro tl; mes.> Abc lc contcsta: <Mi equipo est trabajando a tope. Tenclr sLr.... a tiernpo. Crarnc.> ,Decidc crccr a Abe'l Por supuesto quc nol No con su histolri progrcso que ha r,isto.

En ciclos similares dcl dcsarrollo cle softrvare. con nlazos sinrrr.,: -.

Captulo 6: Cuestiones fundamentales para el desarrollo

rpido

133

incluso con rns dinero en juego. cspefarnos que nuestros clicnres qrricran ver menos signos de progreso de los quc nosotros exigirantos a alguierr que nos cst construyendo una casa. Esperar.r.ros de ellos que acepten un conjunto de requerimientos. y luego esperen sentados semanas. nteses o incluso aos antcs de tener algo tangiblc para cnsearles. No rcsulta ertrao que los clientes se pongan nerviososl E,s pcrfectamente nonual que los clientes piensen que cl desarrollo de software requiere mucho tierrpo! Aunque est completamente dentro dc lo planificado. sea consciente de que la percepctn de un desarrollo lento puede afectar a su proyccto tanto como el desarrollo real. Aunque lo hagarnos siempre, no es razonablc esperar que los clientes csperen sentados durante mcses! y rnostrarles signtrs evidentes de progreso fbrma partc de nucstro trabajo.

Expectativas poco realistas de los clientes

En ocasiones, superar la percepcin de un desarrollo lento requiere algo
ms quc ofi'eccr signos visibles de progreso. La mayora de proycctos actuales estn programados dentro de las zonas de desarrollo rpido o inrposible. La r.nayora de proyectos careccn de los compromisos de planificacin y recursos necesanos para cumplir sus planificaciones agresivas. A nrenudo, los planificadores de proyectos no son corrscientes dc lo ambiciosos que resultan sus planes, y. collto sugiere la Figura 6.9, gcneralmente se ternrinan en la zona lenta. El perodo entre la fccha cstimada y la fecha real de finalizacin cuenta r.nucho en la percepcin de que los proyectos softw.are van lentos. Si un proyecto medio se planifica en la zona imposible, pero es terr.ninado en la

La mayora de proyectos estn programados

Probabilidad de terminar
exactamente en la fecha programada

La mayoria de proyectos se termnan en una de estas zonas

Fecha final programada

6.9. Planificacin tpica en relacin con la curva de planificacion del software. Debido a estmacones poco realstas, Ia mayora de proyectos parecen ir lentos aunque se terminen en las zonas de desarrollo
Figura
roido o eficiente.

134

Desarrollo y gestin de proyectos nformtcos

sus desarozona eflcietc. la gete cor.rsiclerar que ha sido trtl fallo. aLrnqtrc y pucdcn haberlcl tcrnrinnllaclorcs lo hayanlcrnrinaclcl clc fbrma cficiente

clolomirsprolltOposibleconlosrecursosclequcclisponian.

Superacin de la percepcn de un desarrollo lento

lento de En trntincls gencr.alcs. puecle superar cl problcma del desarrollo
dos lbnttas:

o o

(,ettrut'.st' ett !4 rettlidtttl

caclones \,1gel1tes. ciente" o clcl clcsarrollo etlciente al de sarrollo rpido' (.atttt.ttr.se en lu terc'ett'ip iel desut't'tllt 1'rl. Elirlinar las

tlt'l tlesttt'rollct lentr. Acortar las planitipasar.rclo clel clcsarrollo lento a1 desarrollo elliders

Lttcipicas.,vhaccrqttelasplar-rificacionesinicialcsseannlst.ealistas. alaigri'dolas para ccrrar el hueco cntt'e las f-echas dc fi'alizacinplanificadayactllal.Utilicemtoclosquedestaquenlavisibiliclacl clel progreso. E,n ocasiones. los clientes no deseen tant(r incrcrre'tar la ielociclacl cle clcsarrollo. sino que si*plcmente deseall cstar illfbrlnadcls.
La zona clc vclociclacl cle clesarrollo en la quc- sL- enctlentre determtnarll del desarrt''st clebe ccntrarse cn cl clesarrollo rirpicio cn s o en 1a perccpcin problema cn anlllo rpido. con urucha frecr-rencia habr clue rcsollcr cl

bos nivelcs.

6.5. Distribucin del tiempo emPleado

REFERENCIA CFUZADA Para n'rs detalles sobre ia distribucln del tiempo empleado en sus Propios proyectos, consulte el CaPtulo 26. ,,l\4edid as.

rca en -', Urra estratcgia para lograr el clesarrollo rpido es detcrminar el clcl tiempo cn un proyecto tpico' y L'ntonc'i qlre se.nlpla,, la rnarora iitentar rcclucir clicho ticmpo. Puedc reclucir algu'ras tareas con ms fae inadrt':liclacl que otras. c llttclttar reducir algunas de ellas puede alargar tidarnentc lu plani l'icrcirl. de i':' Dentro clc un proyecto sofitvarc. el tiempo puede contemplarse vista producen diferentes prCc':ntas c-listintas. y 1os diferentcs pLlntos tlc el r' cioncs clel emplco clc clicho tienlpo. E1 siguierlte apartado presenta posterlores prcsentan oIl. to c1e r ista clsico (fase a thsc). y los apartados pLlntos clc vista.

El punto de vista clsico

proyectos conlienzan en ulla f-ase poco definida de pt'":':qLrisitos. que puccle dur-ar bastante tienpo. En a1gn ll1onlento. col'ui: postc'l' .. tcc0gicla procluctiva de requerinrientos. y en algn mornento

La mayora

c1c

Captulo 6: Cuestiones fundamentales para el desarrollo

rpido

135

comicnza oflcialnlcnte cl dcsarrollo dc softr'i'are . Las actir idadcs posteriores a los rcquerir.nientos tienden a se r la rartc tnc-jor deflnida del proyecto. La Tabla 6.1 ofrece una idca aprorimada dc dnde se cnrplea el tienrpo en 1as actividades posteriores a los requerir.nientos cn pro,vectos grandes y peqi.reos bien ejecutados.

Las actir.idades que requicren nrs tieurpo clc un proyecfo pequt--rr son las tareas de construccin de diseo dctallado. codificacin.depuracin y prueba de unidades. Si pudiera elir.uinarlas por arte de magia. podra reducir el esfuerzo de su pro'eclo cn urr 65 ror 100. En un proycctcl grancle, las actir'idacles cie construccin rr.quir'ren IIcn()s partc' dcl esfuerzo global. E,lirninarlas de un plumazo stilo reduciria alrcdcdor dc Lrn 35 por 100 del esfuerzo reqr"rerido pol el pro_vccto.
La mayora dc nosotros ha aprendido a tra\'s de la clura expcncncra
a

no acortar arbitrariamcntc las actiridades inicialcs de arclr-ritectura 1, cliseo. Podcrros pclrsaf que reclucir el tiempo de diserio en un -5 por 100 puedc rcducir la planificacin del desarrollo en rrn 5 pol 100. pcro lo rrs probable es que cualquier tienrpo rhorrado por rcortar cl disco sca pagado posteriornrente con intercscs cn las ctrpas flnales del proyccto (actualrrente, la penalizacin suf ida pucdc accrcarsc r.ns a la usura cluc al intcrs). Dicho de otra fbnna. un dcl-ccto dc discr'lo que requicrc r-rr.ra hora y media para ser detectado cn la fasc cle discrlo puecle necesitar de dos cias a un nles para ser resuelto si no sc dctccta hasta la comprobacicin dcl sis-

.-]S

REALES

tema ( Fagan. 1 976 ) Una estrategia ms clcctiia quc la rcduccicirr arbitraria de las lascs iniciales consiste en realizarlas dcl moclo rrs eflcientc posiblc. o usar mtodos que requieran lnenos disco (con.ro ejcnrplo, podran-ros usar unr biblioteca de cdigo para Lrna partc'del sistema). Es ms probable reducir el tienrpo total de desarrclllo si se er.nrlea r.niis tienrpo cn Ias actividades iniciales. v no mcnos.
Tabla

6.1.

Distribucin aproximada de actividades por tamao del proyecto

Actividad
Arqu itectura,,'cli seo Diserio dctallado

Prolccto pequeo
(2.500 lncas de cdigo)
I0'ln
20e.;
)
5(1,i,

Provecto grandc (500.000 lneas)

0(1.;

209.u

( udille

re

irin tlcpLrrrcrrr

109.
50.i, 20,1.n l-5(f i)
)

Plucba de unidades lntegracicin

Prueba del sisterna

2011

l5rti
I0,,,;

Fuentc: Adaptacio cic Cirrl tontplt'te (N,[cC'onncll. lt)t)3

136

Desarrotto y gestin de proyectos informticos

Puntos clave
Capers Jones informa que l'r Dcspus dc rcvlsar ms clc't'000 proyectos' l0{t inclustriaclel sofirvareengeneral puedetenerunaeficienciadeun35.por se gasta en actividades (.lones, 199'+). El 65 poi 100 de tiempo restante el uso de herramientas de productiperjudiciales o lnlprocluctivas' como de mdulos desarrollados de tbrma r,iclad que no funcronan. 1o "pur.utin la falta de control de configuracior' descuidacia, trabaio perditlo ebido a puede ahorrar tiempo'l Los siguientes subapartado' , clems. ,Dndc se derclibcn algtrnas de cttls arcas'

DATOS REALES

REFERENCIA CFUZADA Para rns informacin sobre la lmPortancia de evltar rePetlr el trabajo. consulie la Seccin 4.3, "Bases del control de calidad'

y cdigo defectut'Trabaio repetido' Repetir requerimientos' diseo por 100 de1 coste tot'r un 40 a un 50 sos puede consurltr generalmentt dt (Jones, l9g6b; Boehrn. 1987a). La correcciorr del desarrollo de softrvare
del trabajo, ofrece las corrccci.llcs evltall una repetlclon posterior proyectos' oportLrniclad potentc para reducir sus

costosos de corrcgir y cuandt' tcmprana de defectos. cuardo resultan.'enos utr"

REFERENCIA CRUZADA Para ms informacin sobre el cambio de prestaciones, consulte la Seccin 14 2, avanzado: " Proyecto control de camblos de las Prestaclones"

Cambiodeprestaciones'Elcambiodeprestaciot-rcs.puededeberse..

por parte deldesarrollador cambios en los requct'imientos o nleticulosiclacl de un 25 por 100 de cambit" Un proyecto norrnal expcrimenta alrededor lo que aade ms dc ttrl en sus requerimier.rtos a lo largo de su clesarrollo' (Bochn-r' 1981;Jones' 1994)' No limi25 por 100 cle csfucrzo ai proiecto estrictanlente necesarios es ttl' tar los cambios e,t los ,equerimientos a los y eliminar cl cam.bio de preserror clsico en la relociiacl c1e desarrollo,

tu.ion.,ayudarnuclroaeliminarlosretrasosglobalesenlaplanificaclr..
REFERENCIA CRUZADA Para ms informacin sobre e1 anl1ss de requertmlentos' consulte la Seccin 14 1 iniciado: " Proyecto reduccin del conJunto de Prestaciones"

Especificacinderequerimientos'-Laespecificacin{grequerimier.tosesunaactiviciaclqu.noestref.lcjaclaenlaTabla6'l.Mientrasquell. actir,idacleslistaclasenlaTabla6.lestnrelacionadascotrlasolucintl.
trnproblema.lacspecificacrncierequerimientosestrelacionadacot-ti'. especificacirrclclproblen]aens'Esr'rnaactir,.idadn-rsabicrtaqueotl.]: recogiendo rcquerintterractividades de desarrollo. y el tiempo empleado

tosnoguardalllngunarelacincleterminaclaconeltienrpototalempleatt. 12 meses ttt:il.::^1" requef:constrLiycndo ei prograrna' Pucclcn paslr i'' n-rescs para construirse O podl nrientos pal'a utl ,,rtaitu que necesitar 36 dedicar]osnllsmosl2nlesesrrrediandoentrevariosgruposp.aradefin::para su construccin' Gen"un sistellla quc slo requerir seis meses necesita entre un 101 t'r:' ralmente. la especrficacin de requerimientos ptoytcto (Boehm' 30 por 100 del trempo empleaclo tn.ttn '1981)' es una actividad tan abicrt' Como la recopilacin de requerimierrtos dc ticmpo innecesaLtanlcilt' cs posible ,.l..p.'Alti" grrndcs'cr.nticlades Urrlrroderadosenticiodeurgenciadurantelarecopilacindcrequerin-rier.' total de pnico al final del proyecto' tos pucde evttar una

"n'ut-in

Captulo 6: Cuestiones fundamentales para el desarrollo

rpido

137

Los r.ntodos de desarrollo rpido que se llcvan a cabo para cornbatir el tierrpo perdido durantc la especificacin de requerimientos incluyen el desarrollo conjunto de aplicaciones (.lAD. .loint Apphcation Der.'elopment), cl prototipado er"olutivo. la entrega por ctapas y diversos cnfbques de la gestin de riesgos. Estos nttodos estn dcscritos a io largo de1 libro.

El .,inicio difusor. Otro tipo de actividad que no est descrita en la Tabla 6.1 es el <inicio difuso>. El trempo total necesario para dcsarrollar un producto sofir,varc r,'a desde el pr.rnto en que el proyecto es sintplcnente una visin en la rrente dc alguien hasta cl ntomento en que el sofiware tenninado cst cn manos del cliente. Algn tiempo despus de que el proyecto es una visin cn la mentc dc alguien, se tolra la decisin de <contenzar>, 1, ernpieza oficialmente el proyecto softrvare. El tiernpo transcurrido entre la chispa inicial y la decisin dc <comenzar> puetle ser u.tuy largo. Este .iinicio difuso> puede consurnir sran parte del ticntpo disponible para poner un producto en el mercado. El E.jcntplo 6.1 describc un caso tpico.
Ejemplo

6.1.

Vagando por el inicio difuso

Bill

es un directivo de la empresa de seguros Giga Safe. Estas son las notas que torn sobre el proceso de aprobacin del Giga-Quote 1.0, un programa de primas de seguros: I de octubre. Queremos desarrollar un nuevo programa de primas para

nuestros corredores. Queremos que el progranra descargue las primas de cada da en la oficina central cada noche. Harn falta unos 12 meses para terminar su desarrollo, as que no podremos tenerlo a tiempo para la subida de tarif'as de enero prximo, pero podramos tenerlo para la subida posterior (dentro de 15 meses). Deberamos intentar terminarlo para el I de noviembre (dentro de 13 meses), para tener tietnpo de formar a los agentes antes de cambiar las primas. Voy a proponer el proyecto en la reunin del comit ejecutivo a final de rres. 2 de enero. La propuesta de Giga-Quote ha sido retrasada dos meses en la agenda del comit ejecutivo. Finalmente, la he presentado a finales de diciembre, y he recibido la aprobacin para preparar un anlisis de be-

neficios.

de

lbbrero. El anlisis de beneficios

est

terminado; slo necesita ser

rer,isado.

I de mur:o. Dos de los principales responsables de ventas estn de vacaciones. El anlisis de bene{'icios no puede ser aprobado hasta que Io revisen. I 5 de abr|. Ya estn todas las revisiones, y el proyecto est <en marcha>. El comit ejecutivo sigue queriendo que el proyecto est terminado el I de noviembre, as que el equipo tiene que empezar a codificar ahora
1111S1TIO.

138

Desarrollo y gestin de proyectos informticos

C'onro no se realizur controles fbrnrales (no hal planificaci(rn. ni presupucsto. ni nretas. ni ob.jctiro-\). clurante este peroclo cl trrrogrcso cs dificil clc controlar'. Acienrs. la nrayora cle clirectivos ticlrclcn ir dal'poca prioridad a csla lasc. p()rqur'el inrpacto llnanciero cst lc-jos. En cl inicio clifuso. pLrcdc pclc'lcr tie'ttt1-rtr l)()l- estll\ r'irz()ltes:
a a

Naclie tiene asignacla la rcspurrsabilidad dcl clesarrollo dcl producto.

Llna clccisin clu comenzarrlro conrclrzar r clesarrclllar c1 protlucto. No existe Lrn mccanisnro para e'r'itar qlrc el prociucto sc clLrcnna elr Ios laureles. No cxiste un nrecanisro pal'a rcsucitar un producto ulrr vcr cluc se' hr clornritlo en los laulclcs. Los aspectos clave en la r iabilidad clel procluctt'r 1r iabiliclacl telcnica v atractivo eu cl tlcrcaclo) no uecien ser erploraclc'rs hasta cluc sc aprucbe el presupucsto dcl pKryecto. L-.1 pt'oclucto clebe csperar-un ciclo annal c1e aprobacin dc llocluctos o presul)uestos lntcs clc qr-Le pueda tcner apnrbaclo cl pre supuesitr El cquipo clLle desarrolla cl proclucto no se forma a partir dcl cqLlipo clLle ha traba.jaclo parl la aprobacrn c1e1 proyccto. .{l rrclarar.' equipo cie desarrollo. lrn-riliarizarlo con el procltrctr'r y cncargirrlc 1., tilrcrr sc ricrdc tierrrpo ) crrrp.jL'.

No eriste nna sensacicin cle rLrsencia para realizar

BIBLIOGRAFIA ADICIONAL Para ms informacin sobre el inicio dif uso. lea Developtng Products in Half the lme (Smith y

Reinertsen 1991).

El esfircrzo empleaclo en el inicio dc urr provcctcl suele scr ba-jo. pcr', cl coste lcsultantc clel retraso en el lanzanricnto al lnercaclo pucdc scf alt(l La nica lbrma de recuperar Lur lres percliclo en el inicio L-s acortar ulr nrci el ciclo dc dcsarrollo clel proclncto en su fhse final. Acorlrr en un nrL-s ! csfirerzo global de <lesarrollo cuestr bastante r.r.rs que abrcviar el inici, cn el misnro pcl'oc1o. El inicio presenta una de las oportLrnidacies rns ect'nn-ricrs y ef'ectil as dc dcsarrollo rpido.

6.6. Equilibrio de factores de la velocidad de desarrollo

Una cle las lllosofas subl,accr.rtcs cn cstc libro es la de que cs me-jor tonr"' dccisiones sobrc cicrtos factores con los ojos abicrtos que haccrlcl col.t 1.. o.jos ccrraclos. Si la velocidad cle desarrollo cs reallttcnte sll pt'itrttri., mxirla, entonces lncese e increurente el coste cicl proyecto v colliti'' nreta cl cclr.r.junto de prestaciones ciel proyecto para cntregarlo a tient' Pero courprenda el alcance cie las decisiones que tonra. No cierre los rr.r y cspefe pocler optirnizar sirnultineamente 1a planif icacir.r. costc ,r' prc-taciones cle su prol,ecto. No podr. En Iugar cle ello. acabar pol'no on: mizar ninguno cle ellos: pelcler tier.t.t1.lo y dinelo. y entl'esar tttt proclui con nrenos fincionalidad dc la que podria habcr tenido.
,

Capitulo 6: Cuestiones fundamentales para el desarrollo

rpido

139

Equilibrio entre planificacin, coste y producto

Un tliangulo rlc ccluilitrrio entre planificaciu. costc y caliclacl clr sus extrcmos cs algo bsico para lir gestin. Sin cnrbargo. en softnare no tienc l.r.rucho sentickr tcncr un cxtrenro dc <calicld>) cn Lur tringLrlo dc equiliblio. C'cntrarse en cicrtos tipos cic calldad rcciucc cl coste v la tlanificacirirt. pcro hav cieltos olros tipos que los incrcnrctrtan. [:n el lcrrcno clcl sofiuare. es me-jor rcr cl eclLrilibrio o balance cntl'c planificacitin. costc y trodtttto. Lil ertrcnro cle-l troclucto incluirc la calidacl y todos ios atributos relaciorlaclos con el proclucto. inclu'enclo prcstarciones" complc-jidacl. usabilidad. [aciliclad rlc nrocliflcaci(rn. ntanlotintiento" tasa de crrorcs y dcrurrs. La Fisura (r. l0 iluslr'r .'l triringulo dc cquilibrio ciel soltr.lare Para manle ncr cclr-Lilibratlo cl tritingulo" ticnc que calibrar la planilicacin" cl coste 1'el trrroducto. Si dcscr inciclil en la csclr.rina clcl produclo. tcudr clue incrementar cl costc. la planilicaci(rr o alnbos. t on las restantes courbinacitl.

ll)lIe\

nes plsa lo nrisnro. Si dcsea nrodillcal uno de los r'rtices clel triangulo. tenclrii cluc niodilicar al nrenos uno clc los otlos para urlutenello cclLrilibraclo. Para avudat'mc r llcnsar la opcitin a r.naniltular- clurante las reunioncs de plalril-icacilt nre gllstr llfcsentar un grau tringulo con sus r'r'tices rotulrclos cotro <planilicacitin))" (coslc) v <procluctor>. Los clientes cligcn cl r'r-

ticc o irtices que dcscan controlar'. Nuestro trabajo conro desarrollaclores clc sclljr"'rrc consistc en clue los clicntcs r.tos enseen los r'rtices a los clue ticnden. y cnscriarlcs lo cluc hay cluc haccl para ecluilibrar el tringulo. Si trn cliclttc se celtlrl crt los verrticcs ((llroclucto) y (coste)" le dircn.ros ct'rnlo rcsulta afcctaclo el rrticc <<planilicacirin>>. Si s(rlo se flian en el rrtice <productt'lir^ podcnros darles unr anrplia r,'ariedacl de cclmbinacioncs clccostc ), planif icacin. Pero cor.no desan'ol1rdores necesitan.ros tcucr couto mnit'nrt iur r't'ticc para controlar'. Si su clicntc no le pen.nitc cotltfolar Llll rcirticc clcl triiingulo. scneraln.cntc no podr c-jecutar el pfoyccto.
P lan if

icacin

Producto

Figura 6.10. Tringulo de equilibrio del software. Para tener xito en el proyecto, hay que mantener equiltbrados la planificacin, el coste y el
producto.

140

Desarrollo y gestin de proyectos nformtcos

ERROR CLSICO REFERENCIA CRUZADA Para ms informacin sobre ta negociacin en entornos dif ciles. vase la Seccin 9.2, .Dtsminucin de la presn de la
ptan
if

icac i n,,

info'ra que en un soncleo infbrmal ha encontrado que 40 ror 100 de tocios los proyectos cle desarrollo adolecen de la irnposicin simultnea de prestacioncs. recursos y planifjcacin (Mccarthy. 1995). si no eristc un eqtrilibrio i.icialc.ntrc pianificacin. costc y proclucto. que gcneralmente no se cla. csto su_qiere quc entre ur.r 30 r, un 40 por 100 cle los proyectos dc cicsarrollo conrienzan sin posibiliclad dc cquilibrar las caractersticas de Ios proyectos para rercr exiio. cuanclo un cliente le pasa la deflnicir de un pfoducto^ un coste fijo y una planificacin fa. generalrnc'rtc est intcntanclo mcter urr producto cle l0 kilos en una bolsa para 5 kilos. Pucclc intentar fbrzar cl paqlrete de l0 kilos cn la bolsa, cstirar la bolsa y rornperla. pero ar final simplenrente se clesesperar.a. simplemerrte porquc no cabe. y seguir tcnicndo que decidir sr neccsita una bolsa ms {rande o poner lreros canticlacl en la bolsa que trene.
Jim Mccarthy
Lrn

cntre un -i0 y

Compromisos de calidad
REFEFENCIA CRUZADA Para ms detalles sobre la relacin entre la tasa de defectos y el tiempo de desarrolio. consulte la Seccin 4.3, "Bases del control de calidad.. REFERENCIA CBUZADA Para ms detalles sobre el uso de este trpo de calidad para reducir el tiempo de desarrollo. consulte ei Captulo 14. "Control det conjunto de prestacrones".

Los productos soft*'arc ticnen dos tipos de caliclacl. que afecta'a la planificacin de fbrmas. Un tipo de caliciad es una taja tasa de deicctos. Hasta cicrto'arias tener pocos clcf-ectos y Lrn tiempo corto de desarrollo punto, sor cosas rclacionadas, as que no hay fbrma de cq,ilibrar este tipo cie calidad pa.a planificar. El camino hacia la planificacin rns corta posrble consiste en obtenc'r cl proclucto correcto a la primera. para no percrer. tiempo volvienclo a trabajar en el diseo y la cocrificacin. El otro tipo de calidad incluye todas las resta'tes caractersticas cn las que piensa al inlaginar ttn proclucto softrvare cle alta caliciacl: usabiliclacl. eflcacia, robustcz y dems. centrarse en este tipo de calidad alarga ra planificacin del desarrollo, as q*e eriste la posibiliclacl de equilibrar esre tipo de calidaci flenre a la planificacin.

Compromiso de eficiencia por persona

persona
,Eriste un conflicto entre intentar alcanzar la mrima prociuctir iclad

fo'na de maximizar la procir-rctir,.idacl por persona conslste en manreuei. un tamao de eqLripo reducido. una de las fbrmas ms fciles de rcclucrr. uua planificacin de software consistc en incrementar el tamao dcl equipo. lo quc i'rcrcnrcnta la productiviclad total. pero gc'eralmente hace que crclil persona sea menos eficiente. El ciesarrollo rpido no siempre es eficiente

y la rrayor eficicncia cr la planificacin'l Si. existe. La nrer-,

pr

6.7.

Patrn tpico de mejora de la planificacin

'elociclad sando al desarrollo eficiente sigtren un patrn predecible. Si coge 100 proyectos normales. encontrar quc sus posibiliclades cie terminar a ticrnlr,, sern como las rlostradas en la Fieura 6.1 l. Las organizaciones que intentan nrcjorar su de desarrolro
pa-

Captulo 6: Cuestiones fundamentales para el desarrollo

rpido

141

Planif icacin nicial

Planificacin al 50/50

Probabilidad de terminar
exactamente en la fecha programada

Fecha final programada

Figura 6.11. Curva de planificacin en el desarroilo tpico. Los proyectos normales tienen planificaciones que carecen prcticamente de posibilidades de cumplir.

Entre los proyectos normales. el mbito del rendirniento clel proyecto es amplio, y muchos de los proyectos tienen rL.trasos significativos. Observe que gran parte de la curva de la Figura 6. I I est a la dcrecha de la lnea de planificacin inicial en proyectos normales. Hay pocos proyectos que se acerquen a sus objetivos iniciales de coste o pla:3_iOGFAFIA i]ICIONAL
:: : ;-l r oct.

ificac in.

I s.usin, lea : _ :: :,r' l\4aturity t: ':'soltware, :'tPaulkel i 1 993).

Como muestra la Figura 6.12. entrc los proyectos con desarrollo cflcicntc la variacin de la planificacin es rrenor. y la mayora dc proyectos se acercan a sus objeti\.os de coste y planificacin. Casi la rnitad de los proyectos terminan antes de la fccha fijada, y casi la otra mitad ternrinan despr.rs. Las planificaciones iniciales son ms largas que en cl desarrollo

La planificacin inicial y la planficacin al 50/50 son iguales

Probabilidad de terminar
exactamente en la fecha programada

Fecha final programada

Figura 6.12. Curva de planificacin en desarrollo eficiente. Las

pl an if icacio
n es i n icia les de los proyectos eficientes son ms largas que en los proyectos normales, pero las planificaciones definitivas resultan ms cortas.

142

Desarrollo y gestn de proyectos informticos

tpico, pero las planificaciones reales son ms cortas. Esto se debe en parfe a aprender cmo definir los objetivos de un modo ms realista, y tambin a aprender cmo desarrollar el software con ms rapidez. Pasar de la imaginacin a la planificacin de proyectos con sentido es crucial para pasar del desarrollo tpico al desarrollo eficiente. Una vez alcanzado el desarrollo eficiente, el patrn de mejora depende de si desea mejorar la velocidad de desarrollo, la predecibilidad de la planificacin o ambas cosas. Idealmente, podra emplear mtodos que l.' conduciran a la compacta curva mostrada en la Figura 6.13. Desafortunadamente para nosotros, la curva iilel cle la Figura 6. l3 es tan utpica en el desarrollo de software como la reduccin de peso en las dietas milagrosas. Como se muestra en la Figura 6.14,la mayora de rnetodos de desarrollo rpido estn orientados hacia incrementar la velocidad de desarrollo o reducir el riesgo en la planificacin, pero no en ambos
sent idos.

Al seleccionar mtodos de desarrollo rpido, necesita decidir si desea mejorar las posibilidades de entregar antes un producto o reducir el riesgo de que el producto se retrase ms all de una cierta fecha. El resto de.
libro describe estos mtodos.

6.8. Camino hacia el desarrollo rpido

Los restantes captulos de esta parte del libro describen los enfoques que

contribuyen al desarrollo rpido. E,stos son los mtodos:

Planificacin del ciclo de vida.

Estimacin.

Probabilidad de terminar
exactamente en la fecha programada

Fecha final programada

Figura 6.13. Curva de planificacin ideal en desarrollo rpido. Si todo como est previsto, el resultado consiste en velocidad y predecibilidad
mayores.

va

Captulo 6: Cuestiones fundamentales para el desarrollo

rpido

143

Probabilidad de terminar
exactamente en la fecha programada

Aumentar

Reducir el riesgo

^'-

Fecha final programada

Figura 6.14. Opciones de planificacin. El desarrollo rpido puede centrarse en incrementar la velocidad de desarrollo o reducir los riesoos
relaconados con la planificacn.

o o . o .

Planificacin. Desarrollo orientado al cliente.

Motir,.acin. Equipo de trabajo. E,structura del equipo.

Control dei conjunto de prestaciones.

Herramientas para aumentar Recuperacin de proyectos.
1a

productividad.

Algunos de estos ternas pueden considerarse como parte de lo que hemos descrito como <bases del desarrollo) o (desarrollo eficiente>. Como
creo que estos enfoques son bsicos para alcanzar la mxima velocidad
de desarrollo, estn descritos en esta parte del libro.

bliografa adicional
DeMarco, Tom: Contrclling Sry'in-are Projects. New York: Yourdon Press. 1982. Este libro contiene gran parte de la inspiracin de la parte de curvas de planificacin de software de este captulo. DeMarco dibuja una imagen vvida, humorstica y en ocasiones llena de pnico de los mtodos actuales de estimacin, que, en lo que puedo decir, no han cambiado desde que public su libro en 1982. Describe un mtodo para mejorar la estimacin y la planificacin. Martin, James: Rapid Application Det,elopmen. New York: Macmillan Publishing Company, 1991. Este libro presenta una perspectiva distinta de los temas fundamentaies del desarrollo rpido para aplicaciones de sistemas de inforrnacin.

144

Desarrollo y gestin de proyectos informticos

Smith"

P.G.,y D. G. Reinertsen: Deleloping Procluc't.s itt Hal/'tltc 7., Neu' York: Van Nostrand Rernhold. 199 1. Aunque no est dedic"especficamentc al desarrollo de softrvare. este libro contiene ntu. ' infbrmacin relacionada con el desarrollo rrrs rpido de produ; softwarc. El Captulo 3 contiene una descripcin completa del .,in clifuso>.