Mac Connell

1

Bienvenidoal desarrollo rápido

Contenido

1.1. ¿Qué es el desarrollo rápido'/1.2. Cómo lograr el desarrollo rápido

Temas relacionados

Quién debe leer este libro: PrólogoBeneficios fundamentales del libro: Próiogo

¿,Por qué se ha escrito este libro'l: PrólogoEstrategia para el desarrollo rápido: Capítulo 2

Cuestiones fundamentales para el desarrollo rápido: Capítulo 6

EL RESPONSABLE DE PRODUCTOS ME DIJO que quería desarrollarun producto preparado para un cambio. Deseaba tener en cuenta la cali-dad, evitar el crecimiento de prestaciones, controlar la planificación y te-ner una fecha de entrega predecible.

Cuando llegó la hora de realizar el proyecto, quedó claro que la únicaprioridad real era poner el producto a la venta 1o antes posible. ¡,Usabili-dad? 1/o tenemos tiempo. ¿Rendirniento? Puede esperar. ¿,Facilidad de

mantenimienf"o? Para el prórimo proveclo. ¿Verificación7 Nuestros usuu-rios qttieren el producÍo ahora. Hav que terminar conto sea.

Este responsable de productos en particular no eta el responsable de

un solo producto. Podría haber sido prácticamente cualquiera de los res-ponsables de productos para los que he trabajado. Este comportalnientose repite todos los días, en todos los estados y en todos ios países. Eltiempo de desarrollo se ha convertido en una prioridad tan irnportante que

ha cegado a las personas sin dejarles ver otras consideraciones importan-tes, incluso algunas que afectan al final al tiempo de desarrollo.

4

1.1

Desarrollo y gest¡ón de proyectos informáticos

¿Qué es el desarrollo rápido?

Para algunas personas. el desarrollo rápido consiste en aplicar una únicaherramienta o método. Para el hacker, el desarrollo rápido consiste encodificar 36 horas de un tirón. Para el ingeniero de sistemas de informa-ción" es RAD (Lrna cornbinación de herramientas CASE,, la participaciónintensiva del usuario y \¡entanas temporales estrictas). Para el programa-dor de mercado, consiste en usar prototipado rápido con la última versiónde Microsoft Visual Basic o Delphi. Para el clirectivo desesperado poracortar una planificación. es cualquier método recomendado en el últimonúmero de Business trfeek.

Cada uno de estos métodos y herramientas va bien hasta un clertolímite, y cada uno puede contribuir a incrementar la velocidad de desarro-llo. Pero para obtener todo el beneficio posible, cada uno tiene que estarcoordinado dentro de una estrategia global. Ninguno de ellos es aplicablea todos los casos. y ninguno puede compararse frente a otras técnicas quegeneraimente no son consideradas como técnicas de desarrollo rápido.pero que sin embargo tienen profundas implicaciones en la velocidad dedesarrollo.

En lugar de identificar una herramienta o método específicos, en loque respecta a este libro ei <desarrollo rápido> es simplemente una frasedescriptiva opuesta a,,desarrollo lento y típico>. No es Desarrollo Rá-piclor\, una frase o palabra mágicas. No es una fulgurante metodología dedesarrollo rápido Blaze-O-Matic o Gung-HO-OO. E,l desarrollo rápidoes un término genérico que significa lo nismo que <desarrollo veloz> o<planificaciones más cortas)). Significa desarrollar software a una veloci-dad superior a Ia alcanzada en este momento.

E,nionces, un <proyecto de desarrollo rápido> es cualquier proyec-to que necesite hacer énfasis en 1a velocidad de desarrollo. En las cir-cunstancias actuales, esta descripción se adapta a gran cantidad de pro-yectos.

1.2. Gómo lograr el desarrollo rápido

E,l camino marcado en este libro es claramente la ruta menos transitada enla industria actual. Pasar por 1a ruta menos transitada puede parecer arries-gado. Pero la ruta más concurrida esla que actualmente está redundandoen costes maslvos y retrasos en la planificación, baja calidad, proyectoscancelados, muchos cambios de personal, fricciones entre directivos, desa-rrolladores y clientes, y todo el resto de problemas que estamos tratandode evitar.

Si trabaja en una organización normal y sigue los métodos descritos

,,lo prctblema:'t(10 ha.l unüa:t('.\Íd corta.' { \' errónel.

L. \lenckcn

Capítulo 1: Bienvenido al desarrollo rápido

en este libro, podrá reducir significativamente su tiempo de desarrollo,puede que hasta la mitad, e incrementar también su productividad. Ade-más, podrá hacerlo sin alterar la calidad, el coste. el rendimiento o la faci-lidad de mantenir¡iento. Sin embargo, la mejora no será instantánea, no laobtendrá a partir de una única y nueva herramienta o método, y no\a alcanzará cogiendo simplemente el paquete de la estantería. Requerirátiempo y esfuerzo.

Hubiera deseado tener una solución sencilla para el problema de lavelocidad de desarrollo. También me gustaría tener cinco millones dedólares. Pero las soluciones simples tienden a funcionar sólo con proble-mas sencillos, y cl desarrollo de software no 1o es. El desarrollo rápido desoftware es aún menos simple.

Como sugiere la Figura 1.1, el conjunto de todos los métodos dis-ponibles para desarrollo de software es inmenso. Dentro de esre con-junto, el subconjunto de métodos también es grande. E,n un proyecto enparticular, sólo se utiliza un pequeño subconjunto de estos métodos.Visto por encima, para tener éxito en el desarrollo rápido se requierendos cosas:

o Seleccionar métodos eflcaces en lugar de métodos ineflcaces.. Seleccionar métodos orientados específicamente a alcanzar sus obje-

tivos de planificación.

Mélodos ineficaces

Figura 1.1. Conjunto de todos los métodos para desarrollo de softwareLa velocidad de desarrollo depende de la setección de los métodos dedesarrollo. La velocidad con que desarrollemos cualquier programaconcreto dependerá de Ia proporción de métodos eficaces y de métodosorientados a la planificación que seleccionemos.

Conjuntode métodosusados en

un proyectodeterminado

Desarrollo y gestión de proyectos informáticos

Podríamos pensar que esto es obvio. pero como se explica en el Capí-tulo 3, las organizaciones seleccionan habitualmente métodos ineficaces.Eligen métodos cuya ineficacia está probada, o que fallan más de la cuen-ta. Cuando necesitan la máxima certeza en los plazos. seleccionan prácti-cas de alto riesgo, que reducen la posibilidad de alcanzar las fechas límitefijadas. Cuando necesitan reducir costes, seleccionan métodos orientadosa la velocidad, que incrementan los costes. En estas empresas, el primerpaso hacia la me.jora de la velocidad de desarrollo consiste en admitir queestán seleccionando rnétodos ineficaces, y a partir de ahí comenzar a ele-gir métodos eficaces.

En la Figura L l. todos los métodos efectivos orientados a la planifi-cación están agrupados en una categoría, pero como sugiere la Figura 1.2,actualmente se puede elegir entre tres tipos de métodos orientados a laplanificación:

¡ Métodos que mejoran la velocidad de desarrollo, permitiendo en-tregar antes el software.

. Métodos que reducen el riesgo en la planificación, permitiendo evitargrandes retrasos de planificación.

. Métodos que hacen visible el progreso, perrnitiendo disipar la irn-presión de tener un desarrollo lento.

Los tipos específicos quc seleccione de métodos orientados a planifi-cación estarán determinados por sus problemas con la velocidad de desa-rrollo. Si piensa que simplemente necesita desarrollar más rápido, debe

Figura 1.2. Hay tres tipos de métodos orientados a la planificación:métodos que permiten desarrollar más rápido, que reducen el riesgo en laplanificación y que hacen visible el progreso.

Métodos onentadosa la planificación

Mét0dosorientados

a la velocidad

Capítulo 1: Bienvenido al desarrollo rápido

centrarse en n-rétodos orientados a la velocidad de desarrollo. Si piensa

que su velocidad de desarrollo es correcta, y que el problema radica en

la percepción de la velocidad cle desarrollo por parte del cliente, debería

centrarse en los métodos orientados a la visibilidad.Al unir métodos ef-ectivos orientados a planificación junto con un plan

para usarlos, verá que el conjunto ofrece mejoras drásticas y reales en

ia velocidad de desarrollo. Esto es mejor que usar un software <elixir>

Habichuelas-Mágicas,que realmente no funciona. Por supuesto, seleccio-

nar métodos eficaces y evitar los ineficaces es fácil de decir, pero difícilde hacer, y éste es el tema del resto del libro.

Estrategia paraef desarrollo rápido

Contenido

2.1 . E,stratcgia general para e1 desarrollo rápido2.2. Cuatro c'limensiones cle la vclocidad de desarrollo2.3. Tipos generales de desarrollo rápido2.'1. ¿,Cuál cs la dimensión más importante?2.5. Una estratcgia alternativa para el dcsarrollo rápido

Temas relacionados

E,rrores clásicos: Capítulo 3

Bases dcl desarrollo de software:Gestrón dc riesgos: Capítulo 5

Cuestiones fundamentales Dara el

Capítulo 4

dcsarrollo rápido: Capitulo 6

SI COGIESEN4OS lOO MUSICOS DE PRESTIGIO A NIVEL MUNDIALy los pusiósemos en una orquesta sin director, no sonarían como una or-questa de calidad. E1 tempo de 1a sección de cuerda no coincidiría con el

de la sección dc madera y viento o con 1a sección de metal. Indicar a los

r.núsicos quc lo hagan <1o mejor que puedan> no les ayuda a saber si de-

bcn ir más rápido o más lento. Scmejante evento musical sería un desper-

dicio de taleuto.E.n el desarrollo de softr.varc sc produce un desperdicio similar de ta-

lento. Equipos de clesarrolladores intcligentes y dedicados utilizan 1as téc-

nicas rnejorcs I nrás recientes. y siguen sirt podcr alcanzar sus objetivosde planificación.

Una de las trantpas rnás tentacloras en las que cae la gente que qulere

desarrollar más rápido consiste cn centralse sólo en métodos de desarro-llo orientados a planificación. Podríamos ejecutar cl prototipado rápido

10 Desarrollo y gestión de proyectos informáticos

perf'ectamente, pcro si corletemos un error no obtclrdrerlos un desarr¡.rápido (<¡Vaya!, en la planificación hemos olr.idado inclLrir tierrpo p.,:hacer el subsistema de in-rpresión>). Las técnicas concrstas orientac'la.planificación son sólo parte de lo que necesitarnos para obtener el pr.,más corto posible. También se necesita Lln cntorno global que pernt..utilizar estas técnicas con el máximo beneflcio.

De aquí cn adclanlc cste capitulo proponc una cstratcgia orqrre.r.repara conseguir un desarrollo rápido.

Ejemplo 2.1. Desarrollo rápido sin una estrategia clara

Mickey estaba preparado para dirigir su segundo proyeclo en Square-Tech.un gigante en el mundo de las hojas de cálculo sobre pC. Su primer pro-yecto fue mal. El plan original preveía que su equipo entregase Square-Calcversión 2.0 en i2 meses, pero empleó 18. El equipo sabía desde el princi-p1o que la fécha era agresiva, por lo que casi durante los l8 meses comple-tos llevaron una marcha tlepidante, trabajando l2 horas al dia 6 o 7 días ala semana. Al final, dos de los seis miembros del equipo se fueron, y Bob.el desarrollador más importante del equipo, partió desde Seattle en su bici-cleta hacia un lugar desconocido. Bob dijo que no abandonaba, y envióuna postal a Mickey desde Otturnwa, en Dakota del Sur, una foto suyamontando en un rodeo, pero nadie sabía cuándo volvería.

La versión 3.0 de Square-Calc tenía que entregarse l2 meses despuésque la versión 2.0, así después de dos meses del fin del p¡oyecto, diagnós-ticos post-mortem y vacaciones, Mickey estaba dispuesto a intentarlo denuevo. Tenia i0 meses para entregar la versión 3.0. Mickey se reunió conKim, su jefa, para discutir el plan dei proyecto. A Kim se le conocia por sucapacidad para aprovechar hasta el último esfuerzo de los desarrolladoresa su cargo. También estaban John, de documentación de usuario, y Helen,de control de calidad.

<La versión 3.0 tiene que superar a la competencia>, dijo Kim. <Portanto, en este proyecto tenemos que hacer un gran esfuerzo. Sé que tu equl-po no cree que la compañia les haya apoyado mucho anteriormente. asi queahora la compañía está dispuesta a darles todo el apoyo que pueda. Heautorizado despachos privados e individuales, computadores más moder-nos y refrescos gratis durante todo el proyecto. ¿Qué te parece?>

<Me parece bieo. dijo Mickey. <Todos los desarrolladores tienen ex-periencia, así que principahnente quiero darles motivación y apoyo, y en-tonces dejarles trabajar. No quiero controlarles estrechamente. Me gustariaque cada uno se responsabilizase de una parte del sistema. Antes tuve pro-blemas c<¡n las interthces, así que quiero dedicar algún tiempo en diseñarlas interfaces entre las partes, ¡r después dejarles a su ai¡e.>

<Si es un proyecto de l0 meses, en 8 meses necesito una versión con elaspecto definitivo del software para tener la documentación de usuario lis-

\( ()llIlllllti J

Capítulo 2: Estrategia para el desarrollo rápido 11

ta a tiempo>, dijo John. <La última vez los desarrolladores estuvieron ha-ciendo cambios hasta el f,nal. El archivo LEAME tsnía 20 páginas, y ade-más enrevesadas. Los manuales de usuario están siendo destrozados en lasrevisiones. Siernpre que estés de acuerdo con tener lista una versión con lainterfaz definitiva, el método de desa¡rollo parece correcto.))

<Necesito la versión definitiva más o menos en la misma fecha paraescribir secuencias autornáticas de prueba>, añadió Helen. Mickey aceptóel planteamiento de la versión definitiva. Kirn aprobó la estrategia globalde Mickey y le dijo que le dejase organizarse.

Cuando comenzó el proyecto, los desarrollado¡es andaban contentoscon sus despachos individuales, sus nuevos ordenadores y los refrescos,asi que empezaron fuerte. No tardaron mucho en quedarse voluntariamentea lrabajar por la tarde.

Los meses pasaban, y hacían progresos constantss. Pronto construye-ron un prototipo, y continuaron generando código. La directiva manteniala presión, John recordó a Mickey varias veces su acuerdo de tener la ve¡-sión con el aspecto definitivo en 8 meses, cosa que Mickey encontró irri-tante, pero todo parecía progresar bien.

En el cuarto r¡es del proyecto Botr volvió de su viaje en bicicleta. fres-co, e irrumpió en el proyecto con nuevas ideas que había concebido mien-tras pedaleaba. Mickey estaba preocupado por si Bob podría implementarlas funciones que necesitaba en el tiernpo disponibie, pero Bob estaba com-prometido con sus ideas y garantizaba la entrega a tiempo sin importar lomucho quc tuviera que trabajar.

Cada miembro del equipo trabajaba individualmente en su parte, y comola entrega de la versión con la interfaz definitiva se aproximaba, coürenza-ron a integrar el código. Comenzaron a las 2:00 de la tarde del dia anteriora la entrega de la versión definitiva y pronto descubrieron que su programano compilaba, y menos aún se ejecutaba. El código combinado tenía variasdocenas de errores de sintaxis, y parecía que cada uno que se corregía ge-neraba otros 10. A medianoche, decidieron dejarlo por esa noche.

A la mañana siguiente, Kirr se reunió con el equipo. <¿El programaestá listo para entregarlo al equipo de documentación y prueba?>

<Aún no>i, dijo Mickey. <<Tenemos aigunos problemas en laintegración;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 deldia admitieron que no tenían ni idea de cuánto tiempo llevaría la integración.

Emplearon dos semanas completas en corregir todos los errores de sin-taxis y tener el sistema funcionando al completo. Cuando el equipo entre-gó la versión buena tras un retraso de dos semanas, los equipos de pruebay de documentación la rechazaron inmediatamente. <Es demasiado inesta-ble como para documentarla>, dijo John. <Se viene abajo cada pocos mi-nutos. y hay dernasiadas opciones que no pueden plobarse.>

Helen añar,lió: ,,No tiene senlido escribir un informe de errores, si elsistema es tan inestable que se interrumpe casi cada vez que se hace unaelección en el menú.>

(aDnI¡nuLt\


Mickey estaba de acuerdo con elros, y drjo que los esfuerzos der equi-po se tenían que centrar en corregir errores. Kim les recordó la fecha topede 10 meses, y dijo que ese producto no podía retrasarse como el anterior.

se empleó un mes en hacer que el sistema fuese lo bastante fiable comopara comenzar la documentación y la prueba. por entonces sólo quedabandos semanaspara el plazo de 10 meses, y trabajaron aún más.

Pero la pruetra enc,ntraba defectos con más rapidez de la e'.rpleada porlos desarrolladores para corregirlos. Las correcciones en Lrna parte del siste-ma frecuentemente generaban problemas en otras. No habia posibiliclad al-guna de acabar el décimo mes. Kim convocó una reunión de emergencra.<veo que estáis trabajando duro>, dijo. <pero no es suficiente. Necesito resul-tados. os he dado todo tipo de ayuda, y aún no tengo ningún sofiware queenseñar. Si no acabáis pronto el producto, la cornpañia podría hundirse.>>

Según aumentaba la presión. bajaba la moral rápidamente. Según pa_saban los meses, el producto comenzaba a estabilizarse, y Kim t.t..rani"nía lapresión. Algunas de las interfaces se volvie¡on extremadanlente ineficien-tes' y se necesltaron varias semanas más para nrejorar la eficiencia.

Bob, a pesar de trabajar contra reloj, entregó su softrvare más tarde queel resto del equipo. El código estaba virtualmente libre de

"rro."r" ,.ru

había cambiado algunos elcmentos de la interfaz de usuario, y las pruebasy documentación 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 código de Bob como está.y revisar ias pruebas y la documentación de usuario, o podemos descartarel código de Bob y escribirlo todo de nuevo. Bob no reescribirá su código.ni nadie del resto del equipo. parece que tendréis que carnbiar la documin-tación de usuario y las secuencias de pruebas.> Después de oponer un pocode resistencia, John y Helen aceptaron de mala gana.

Finalmente, 1os desarrolladores emplearon l5 meses en acabar el soft-ware. Debido a los cambios de aspecto, la documentación de usuario per-dió su lugar en el programa de producción de la imprenta, asi que <lespuésde que los desarrolladores tuvieran los discos naestros, hubo dos semanasmás de retraso en el lanzamiento mientras square-Tech esperaba que llega-ran los documentos de la imprenta. Después del lanzamiento la respueitade los usuarios a la versión 3.0 de square-calc fue poco entusiastá, y alcabo de los meses descendió del segundo al cuarto puesto en el mercado.Mickey concluyó que había acabado su segundo proyecto un 50 por 100 detiempo más tarde de 1o planificado, igual que el prirnero.

2.1. Estrategia general para el desarrollo rápido

El modelo descrito en el F.jemplo 2. r es habitual. Evitar estc rnoclelo su-pone un esfuerzo, pero apartarse de estos malos hábltos está dentro delalcance de cualquiera. Sc puede obtener un desarrollo rápic1o siguiendocsta estrategia en cuatro partcs:


l. Evitar los errores clásicos.2. Aplicar las bascs del dcsarrollo.3. Gestionar los riesgos para e'n'itar ull retorno catastróflco.4. Aplicar ntétodos orientados a planificación. conto los trcs mos-

trados en la Figura 1.2 dcl Capítulo 1.

Como se sugierc en la Figura 2.1. cstas cllatro técnicas olicccrr sopor-te para el mcjor plan posible.

Las imágenes con pilarcs no le llaman la atenciólt ¿r rradic. ¡lero lospilures de esta figura nruestlan rarios puntos irnporlantes.

E,l soporte óptimo para el rnejorplan posiblc cs tcner los cuatro pilarescolocados en su lugar. y hacer que cada uno de ellos sea lo ntás firc-rte po-sible. Sin el soporte de los tres primeros pilares. las posibilidadcs dc consc-guir cl rnejor plan posiblc estarán en peligro. Podentos utilizar los ntétodosluás potentes orientados a la planificación. pero si contetentc'rs cl error clá-sico de descuidar la calidad del proyecto clt sLls fases inicialcs. clcsperdi-ciaremos ticmpo corrigiendo defectos justo cuarrdo cs u.rás carcl. Nucstrcrproyecto sc retrasará. Si pasan.ros por alto cl ¿rxiont¿r dc desarrollo de crearun buen diseño antes cle contenzar a codillcar. ltLrcstro progfauta firllarácuanclo cambie la concepción del producto durantc cl ¡troceso cic desarro-llo, y el proyecto se retrasará. Y si no control¿rmos los riesgcts. pocler.nosdescubriljusto antes de la fecha dc cntrega quc uu subcontratist¿r clave scha retrasado tres meses scgún el tllan. Dc nuevo tcndrentos rctrast,.

"!:s*

rrfiNtirl i

,i1rl

&#;; ;#;;Evitar Baseserrores oelclás¡cos desarrollo

M **M

Gestión Métodosde orientados a

riesgos la planif icación

Figura 2.1. Los cuatro pilares del desarrollo rápido. El mejor plan posibtedepende de evitar los errores clásicos, las bases del desarrollo y la gestiónde riesgos, además del uso de métodos orientados a planificación.

Mejor planificaciónposible


Métodosorientados a la

planif icación

Figura 2.2. Resurtado de centrarse solamente en métodos orientados aplanificación. Ni los métodos or¡entados a ptanificación más avanzados soncapaces de soportar por ellos solos el mejor ptan posible.

La figura también sugiere que ros tres primeros pilares ofrecen la rnayorparte del soporte necesario para obtener el mejor plan posibre. euizás nosea el soporte ideal, pero es la mayor parte de lo que necesitamos. Debe-mos ser capaces de obtener un plan óptimo sin métodos orientados a pla-nificación.

¿Se podría obtener el mejor plan posible centrándose únicamenre enmétodos orientados a planificación? Se podría hacer. La gente va ha rea_lizado antes proezas como ésta. pero como muestra la Figura i.2, ., ,ndifícil problema de equilibrio. puedo mantener en equilibrio una sillaen mi barbilla y mi perro puede mantener en equiribrio una galleta en sr-rnariz. Pero la elaboración ile un proyecto software no ., un-t.uco de sa-lón, y si confiamos en que los métodos orientados a planificación hasantodo el trabajo, probablemente no tenclremos todo er soporte ne."su.iolsilo hacemos una vez, puede que no seamos capaces de hacerlo de nuevo.

Los tres primeros pilares rnostrados en ra Figura 2.r son básicos parael éxito del desarrollo rápido, así se hará 1o posible para clarificar quéquiere decir evitar errores clásicos, bases del desarrollá y gestión de ries_gos. El capítulo 3 trata los errores clásicos. En la nrayória de los casos,estar avisado simplernente de la natural eza d,e un error será suficiente paraevitarlo. así que en este capítulo se muestra una lista de los errores clási-cos. El tema de las bases del desarrollo se trata en el capítulo 4, y el temade la gestión de riesgos en el Capítulo 5.

El resto del libro trata de métodos concretos orientados a planifica-crón, incluyendo métodos orientados a velocidad, orientados a la olanifi_

)apítulo 2: Estrategia para el desarrollo rápido l5

cación de riesgos y orientados a la visibiridad. En la tercera parte del ri-bro, <Métodos recomendables>. se muestra el efecto de cadá método enla velocidad del desarrollo, planificación der riesgo y visibilidad. Si de-sea pasar al desarrollo rápido en sí antes de leer acerca de los tres pasosnecesarios para conseguir las bases del desarroilo rápido, puede saltar alCapítulo 6, <Cuestiones fundamentales para el desárrollo rápido>, y alresto de capítulos.

2.2. cuatro dimensiones de la veloc¡dad de desarrolloTanto si nos hemos atascado en el lodo intentando evitar los errores comosi cruzamos a toda velocidad utilizando métodos orientados a planifica-ción efectivos, nuestro proyecto software se desarrolla a través de cuatrodimensiones principales: personas! proceso, producto y tecnología. Laspersonas trabajan rápidamente o lentamente. El procesó ,upon. ,nu -.-Jora en la actividad de las personas, o coloca un obstáculo áetrás de otro.Un producto se define de forma que casi se construye solo, o de formaque pone obstáculos a los rnejores esfuerzos de la gente que está constru-yéndolo. La tecnología ayuda ar esfuerzo del desarrolro u obstacuriza losmeJores intentos de los desarrolladores.

Podemos potenciar cada una de esas cuatro dimensiones para maxi-mtzar la velocidad de desarrollo. La Figura 2.3 ilustra esta idea.

Personas

Producto

Tecnología

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

16 Desarrollo y gestion de proyectos informáticos

Como réplica a este diagran.ra. algunos ingenieros dirían: <¡E,h!, noson cLratro dinten.sír¡ttes. Son cuatro tlirec'c'íone.s. ¡Aúrn no podemos dibu-jar cn cr-ratro clirrensiones!> Es cierto. No se puede dibujar en cuatro di-r.nensioncs. y ósta es la raz(rn dc que la figura se muestre en dos dimensio-nes. Por cl conccllto qLle se quiere mostrar es llás r¡na dirnensión que unad i rccción.

Los libros de dcsarrollo de softr.vare tienden a hacer énfasis en unadirccción v a nrinir.uizar las dernás. pero no hay necesidad de renunciarentre central'se en las personas. el proceso. el producto o la tecnología. Sifucscn direcciones. cntonces centrarse en las personas podría quitar valora centrarsc en la tecnología. Ccntrarsc en el producto impediría centrarseen c[ proceso. Pero pllesto qlle son dimensiones. podemos centrarnos almisl.no tiempo en la gente. cl proccso. el producto y la tecnología.

Las organizacioncs de softu'are tienden a t'er las dir.nensiones que noutilizan como valores fi.jos. y ésta puedc ser una de las razones de que laplanificación de proyectos pueda ser frustrante. cspecialmente la plani-flcación teurporal. Cuando r-rtilizamos una sola dimensión, es prácticamenteirnposible satisfacer los objetivos dc todos. El dcsarrollo autóntrcamen-te rá¡rido necesita que incorporemos gran variedad de tipos distintos denrótodos (Boehm et ul..198.:l; Jones. 199 l). Las organizaciones r.nás efec-livas en la consecución de un desarrollo rápido optimizan simultáneamcntelas cuatro diurcnsiones.

Aprender cada una de las cnatro dimensiones puede suponer una granrcnta.ja para la planificación del softu'arc: la planificación pr"rede llegar a

scr m¿is completa. r¡ás creativa, más efectiva y nos satisfará mejor. tantoa nosotros conto al resto de los intplicados.

Las siguicntcs subsecciclne s tratan de las cuatro dimensiones v dc cónrosc relaciorran.

Personas

Se conoccn los resultados dc experimentos concretos cn tcmas de perso-nal (peo¡tleu'arc). Poder.nos estar familiarizados con la tcsis de que la di-fcrencia cn la proclu.^tividad cntre diferentcs desarrolladores cs al nrenoscle dicz a uno. o estar lamiliarizados con la aportación positiva que pucdetcuer un¿r utcjora cxplícita en 1a r.notir,ación.

Lo que es rrenos lamiliar de la rnayoría dc los dcsarrollaciores. inclui-da la mavoría de la serrte de la industria. es que los resultados cn las in-vcstisacioncs sobre pcrsonal sc han ido acumulando de fonrra cstabledurante los pasados qr"rincc a vcinte años. Ahora es posible hacer un reco-rriclo por rruchas cle las conclusioncs en estudios concretos. y sintetizaralgunas conclusiones globales segúrn las tendencias en la investigación.

La prirnera conclusión es que ahora sabemos con seguridad que lostcmas relacionados coll pcrsonas tienen un lravor impacto cn la produc-

,: =-ALES


tiviclacl del sofiu'arc y por tanto cn la calidad del software. Desdc f-ina-

les dc los sesenta. estudio tras estudio sc ha descubierto que la producti-vidad de programadorcs concretos dc sirnilar nirel de experienciu pLre-

de variar en un factor dc al menos de dicz a uno (Sackr.nan. Erikson yGrant, 1968: Curtis. l98l: Mills. 1983: DcMarco y Lister. 1985; Curtiser ul., 1986: Card. 1987: Valett y McGarry. 1989).

Los estuclios tambión 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). Despuésdc 20 años de erperirnentar cn pfoyectos rcales. los ini'cstigaclores del La-boratorio de Ingeniería del Soltrvare de la NASA han llcgado a la cor.l-

clusión dc que la tecnologia no es la respucsta; los u.rétodos más ef'ectivosson aquellos quc sacan partido al potencial humano dc sus desarrollado-rcs (Basili er al.,1995).

Puesto qllc está claro quc todo lo relacionaclo con peopler.r'are influycfuertemente en la productividad. ahora tarnbién queda n.ruy claro que cual-cluicr organización que trate seriantentc de ntclorar la productiridad pri-mero debe ocLlparse c1c temas relacionados con pc-rsonal. contt'r l¿r ntotir,'a-ción. cquipo de trabajo. selección dcl personal y fbrrnacicin. Hav otrasformas dc mejorar la productividad" pero la gcstión de personal of}ece losmayorcs beneflcios potcnciales. Si nos interesa cl dcsarrollo rápido. de bc-mos preocuparnos de las personas. Conjuntarrcntc. los tcntas relaciona-dos cor.t el persorral son r"nás in.rportantcs que cl proccso. el producto cl latecnología. 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 resul-tados de la investigaciór-r simplentcnte dicen quc los cl-cctos cle la habili-dad y motivación individuales. y habilidad y motiración clc.l eqr.ril'rtr sonpcqueños factores que influyen en la productlvidad. No dicen especítica-mente que las camisetas. los refrescos gratis. las oficiu¿rs extericlres. rc-compensas de productir,'idad o la cerveza dc los viernes por 1a tarcle rrrc..jtr-

rcn la motivación. pero hay una relación clara: Llrla elrlprcsa que quieran.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.

Selección del personal para equipos de proyectos. En su libro cla-ve. Sofiture Engineerirtg Eccltctntit'.s. Barr¡, Boehnt presenla cinco Ir'irr-cipios para la selección de pcrsonal (Boehm. 1981 ):

,)Iúxinto tulento. Usar pocoTrabttjo uclec'uudo. Asignarción dc la gente disponible.

y bucn personal.tarcas según la habilidad y nrotira-

a

a

o Progresiótr ¡tt'o./e.sionul. Ayr-rdar a la _gente a actualiz¿rrse por sí

REFERENCIASCRUZADAS

Para más informaciónsobre adecuación de

trabajos y cafieraprofesional, véase "El

trabajo en sí", en laSecc¡ón 1 1.2. Para

más información sobreel equ¡librado de

equipos y pÍoblemasde personal, véanse el

Capítulo 12, "Equipo.lo tr.h.i^- \? ól

Capítulo 13,

" Estructura delequiPo"

18 Desarrollo y gest¡ón de proyectos informáticos

mlsma en vez de obligarles a trabajar donde más experiencia tie-nen o donde son más necesarios.

c Equilibrado del equipo. Seleccionar a gente que se complementey armonice con los demás.

o Eliminar la inadaptación. Ehminar y reemplazar a los miembrosproblemáticos del equipo lo antes posible.

Otros factores que pueden marcar la diferencia son la habilidad dediseño del personal, la habilidad en programación, la experiencia en elentorno y la rnáquina y la experiencia en el área de aplicación.

Organización del equipo. La forma de organizar al personal tiene ungran efecto sobre la eficiencia con la que trabajen. Las empresas de soft-ware sacan partido a la estructura de sus equipos para que concuerdencon el tamaño dei proyecto, las características del producto y los objeti-vos de planificación. Un proyecto software específico también puede sa-car provecho de la especialización apropiada.

Motivación. Una persona que carece de motivación no va a querer tra-bajar duro, y prefiere dejarse llevar. La motivación es el único factor queprovocará que una persona renuncie a las tardes y los fines de semana srnque se le pida. Pocos otros factores pueden aplicarse a tanta gente dentrode tantos equipos en tantas empresas. La motivación es potencialmente elaliado más fuerte que tenemos para el desarrollo rápido de un proyecto.

Diferencias en la productividad mayores de l0 a 1 entre individuoscon diferencias en la diversidad y profundidad de su experiencia,Diferencias de productividad de 10 a I enrre individuos con losmismos niveles de experiencia.Diferencias en la productividad de 5 a I entre grupos con diferentesniveles de experiencia.Diferencias en la productividad de 2,5 a 1 entre grupos con nivelesde experíencia similares.

ProcesoTal y como se aplica al desarrollo del software , el proceso incluye tantasmetodologías de gestión como metodologías técnicas. E,l efecto que tieneel proceso en el plan de desarrollo es más fácil de calcular que el que


tiene la gente, y el Software Engineering Institute y otras organizacioneshan desarrollado gran cantidad de trabajo para docurnentar y publicitarlos procesos de softrvare efectivos.

E,l proceso representa un área de gran relevancia en la mejora de lar clocidad de desarrollo, casi tanto como las personas. Hace diez años erarazonable debatir acerca de la importancia de centrarse en el proceso, perohoy día, como ocurre con el personal. existen gran cantidad de evidenciasen favor de prestar atención al proceso. Organizaciones cono Hughes Air-craft, Lockheed, Motorola, NASA, Raytheon y Xerox. que se han dedica-do durante varios años a mejorar explícitamente sus procesos de desarro-llo. han reducido sus plazos de salida al mercado a la mitad, y han reducidocostes y errores en un factor de 3 a 10 (Pietrasanta, 1991;Myers, 1992;Gibbs. 1994; Putnarn,1994; Basili e¡ al.,1995; Raytheon, 1995; Saiediany Hamilton, 1995).

Algunas personas piensan que ocuparse del proceso es agobiante, yno hay duda de que algunos procesos son demasiado rígidos y burocráti-cos. Hay gente que ha creado estándares en procesos principalmente parasentirse más poderosos. Pero se trata de un abuso de poder, y el hecho deque se abuse de centrarse en el proceso no debe permitir echar por tierralos benefrcios que puede ofrecer este enfoque. La forma más habitual deabusar del proceso es 1a negligencia, y su efecto es que desarrolladoresinteligentes y concienzudos trabajan ineficientemente y con objetivos cru-zados, cuando no sería necesario trabajar de esta forma. Centrarse en elproceso puede ser úti1.

Evitar la repetición de trabajo. Si en las últimas etapas del proyectohay un cambio en los requerinrientos, es necesario rediseñar, recodificary volver a hacer las pruebas. Si ha habido problemas en el diseño que nose descubren hasta la prueba, se debe volver al diseño detallado y la codi-ficación y comenzar de nuevo. Una de las mejores fonnas de ahorrar tiempoen los proyectos software es orientar el proceso de forma que se evitehacer la misma cosa dos veces.

Raytheon obtuvo en 1995 el IEEE Computer Society's Software pro-cess Achievement Award por reducir sus costes de repetición de trabajodei 4l por 100 a menos del l0 por 100. y simultáneamenre triplicar suproductividad (Raytheon. 1995). La reiación entre estas dos proezas noes una casualidad.

Control de calidad. El control de calidad tiene dos objetivos princrpa-les. El primero es asegurarse de que el producto entregado tiene un nivelde calidad aceptable. Aunque se trate de un objetivo importante, está fue-ra del alcance de este libro. El segundo objetivo es detectar los errores enel proceso en el momento que haya que emplear menos tiempo (y menosdiseño) para corregirlos. Esto siempre quiere decir localizar los errores lo

,i,

DATOS REALES

REFERENCIACRUZADA

Para más informaciónsobre control decalidad véase la

Sección 4.3, "Basesdel control de calidad".


BEFERENCIACRUZADA

Para más informaciónsobre las bases del

desarro lo, consulte la

Sección 4 2, -Basestecn lcas,, .

más pronto posible desdc cI lrontento en el que sc introducen. Cuanto

rrás tiempo pcnnanczca un error en el producto. más tiempo (y más dine-ro) se empleará cn clinrinarlo. Por tanto. para un progranta serio de desa-

rrollo riipido cs indispensable controlar la calidad.

Bases del desarrollo. La mayor parte del trabajo realizado durantc

los pasados 20 años en el campo dc la ingeniería del softrvare está rcla-cionada con clesarrollar softu'arc rápidamente. Muchos traba.jos se cen-

tran cn la <productiriclacl> nás quc cn cl desarrollo rápido en sí mismo. 1'

por csto algunos de ellos sc han oricntado hacia obtencr el tllisnro trabajohccho por nenos gentc. cn vcz de conseguir hacer el proyccto más riipida-rnente. Sin cmbargo. podemos intcrpretar los principios subyacentes des-

cle cl punto de vista clel desarrollo rápido. Las lecciones aprcndidas a lolargo c1e 20 arlos clar.rclo tropczoncs pueden ayudar a que su proyecto se

desarrolle tranquilamente. A pesar de qr.rc los r.nétodos estándar en in-ee-

niería del soft'uvare para el análisis. diseño. constrtrcción. intcgración y

prucba no van a acelerar por sí mismos el plan de fbma firlgurante, pLrc-

den cvitar clue los proyectos se quedcn fuera de control. La ntitad del de-

saflo del desarrollo rirpiclo consiste en c'n'itar cl desastrc. y ésta es un área

en 1a que sobresalen los princi¡rales cstándares de des¿rrrollo clcl softu'are.

Gestión de riesgos. La gestión de riesgos es Llna de las técnicas espe-

cíflcas que se centran en evitar el clesastrc. El desarrollo rápido no es sll-ficientcrxentc bucno si durante dos setnanas antes de la fecha dc cntrega

nos clucclamos fircr¿r de.j uego. Para prograr.nar un desarrollo rápido es rre-

cesario gestionar los riesgos asociados con la planifícación.

Atención a los recursos. Los recursos pueden enfocarse de fbrma e fec-

tir,'a y ayudar ir la procluctividad global. o pueden dirigirse ntal y usarsc dc

fbrnra inef'cctir"a. En un proyecto de desarrollo rápido. es incluso rnás

irnportante de lo habitual acertar al rnáximo er.r el rncior plan. Técnicas

con.ro oficinns productir''as, desarrollo cn ventanas temporales. planifica-ción a.justacla y horas ertras r,'oluntarias ayudan a asegurarse dc que cacia

día sc hace todo el trabajo posiblc.

Planificación del ciclo de vida. Una de las clal'es para la asignaciórr

efcctira clc los recursos cs utilizarlos dentro de un ciclo de vida deflnidoquc tenga sentido para cl proyecto concreto. Un modelo de ciclo de vida

es útil porque describc r-rn plan de gestitin básico. Por ejcmplo. si tenemos

un llroyecto arriesgado. cs recomendable un ciclo clc r''ida oricntado al

ricsgo: si los requerir.nicntos no están claros. funcionará n.rejor r.rn rnodelo

cle ciclo de vida increr.ncntal. Los modelos de ciclo de vida hacen qlte sea

más fácil identiflcar y orgarrizar las muchas tal'eas neccsarti.ts cn un pro-yc-cto sofiu'arc. y así poder realizarlas con la mayor e ficacia.

REFEFENCIACRUZADA

Para más nformaciónsobre gestión de,,Yü9u¡ vvorc cl

CapÍtulo 5, "Gestiónde rlesgos".

REFERENCIACRUZADA

Para más informac onsobre la planifrcac on

del ciclo de vida.consulte el CapÍtulo 7.,,Planlf icación del clclo

Oe vlOa,,.

:::=RENCIA] ¡ UZADA

:. -':,f t.tactÓn:-:-:ac on ai': ::.su te e

::l 1u o 10,: I _1r entaoo

.- C ente..


Orientación al cliente. Uno dc los cambios fundamentales entre el desa-

rrollo de softu'are tradicional sobre mainfiames y los ntodernos estilos de

desarrollo es el giro hacia las necesidades y deseos del cliente. Los desarro-

llaclores han aprendido que desarrollar el software a partir de la especifi-cación supone sólo la mitad del trabajo. La otra mitad es ayudar al clientea deflnir el producto quc dcsea. 1, la mayoría de las veces es necesarla una

aplorimación diferentc a la tradicional especificación en papel. Ponerse

en su lugar es una dc las rnejores fbnnas de cvitar las vueltas atrás masl-vas provocadas por el clicnte que decide que el producto correcto no es elquc se está dcsarrollando desde hace 12 meses. Métodos colno la entrega

llof etapas. entrega evolutiva. prototipado evolutivo, prototipado desechable

y rregociación conveniente rpoltan Vc-ntajas a este área.

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

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

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 re-chazar 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 elcliente es el auténtico cliente de carne y hueso que paga el coste del desa-

rrollo del proveclo directarnente. En olros proyectos. es un grupo internodentro de una organización. Aún queda otro tipo de proyectos, en los que

el cliente es la persona que pone sobre el mostrador 200 dólares para com-prar el software <prét-á-porter>, En este caso, el cliente real es un clientelernoto y habitualrnenre hay un directivo o un especialista de mercado que

lo represerrla.Según sea la situación concreta, el término <cliente> puede representar

<cliente>. <especialista de mercado>>, <usua¡io final> o <<jefe>.

ProductoLa dimensión rrás tangible dcl cuarteto genteiprocesoiproducto/tecnologíaes la climensión producto, y ocupal'se del tantaño y características delprodr-rcto plantea enoflncs oportunidades de reducir la planificación.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 sólo el 20 por 100 de1

tiemtr-ro. M¿is tarcle se dcsarrollará el 20 por 100 restante. Si hacemos que

el aspccto. las caracter'ísticas dc rendimiento y las características de cali-dad dcl proclucto sean flcriblcs. podernos ensatnblar el producto empleando

componentes preexistentcs y cscribir la r.nínima cantidad de código espe-

ciflco. E,l total en la reducción sobrc cl plan que sc obtiene al ajustar en el

tanraño v las características dcl producto sólo se ve limitado por el con-

cepto cle prcducto quc ticnc cl cliente y la crealividad del equipo.


REFERENCIASCRUZADAS

Para más informaciónsobre Ia manipulación

del tamaño delproducto para obtener

velocidad en eldesarrollo, consulte elCapítulo 14, "Control

del conjunto deprestaciones". Para

más información sobreel efecto del tamaño

del producto en elplan de desarrollo,

consulte el Capítulo 8,

" Estimación " .

Tanto el producto como las características clel producto ofiecen opor-tunidades para acortar el ticmpo dc clesarrollo.

Tamaño del producto. El tamaño del producto es el elernento individualque más aporta al plan de desarrollo. para productos grandes se ernpleanrás tiempo. Para productos niás pcquerios. menos. prestaciones adrcio-nales necesitan especificación. diseño. construcciones, prueba e integraciónadicionales. Rcquieren ttna coordinación aclicional con cl resto tle las utili-dades. y neccsitamos coordinar las otras con ellas. puesto que el esluerzopara construir softwarc se increncnta clesprclpor-cionaclamentc más rirpi-do que el tamaño del software. la recrucción clel tanraño urejorará lavclocidad del desarrollo clesproporcionadamente. Reducir a la mitacl eltamaño de un progranra intermedio nornralmcnte supone una reducciónde ai menos dc¡s tercio,s del esfuerzo.

Podemos reducir drásticamente el tarnaño del pro<lucto esforzándo-nos en desarrollar sólo las prestaciones más esencialcs. o rcducir-lo tem-poralmer.rte desarrollando el producto en etapas. Tanbién es posiblc re-ducirlo empleando un lenguaje de un nivel más aito o un conju'to cleherramientas para que cada utilidad necesite menos código.

características del producto. Aunque no rienen la misma influenciaque el tamaño del producto, hay otras características clel proclucro qlleafectan al p1an. Se empleará más tiempo en desarroliar un producto conobjetivos ambiciosos respecto al rendimiento. uso de memoria. robustezy fiabilidad que el que se empleará en uno sin nin-eún ob.ieti'o para estascaracterísticas. Hemos de elegir nuestras metas. Si la autóntica prioridades el desarrollo rápido, no pondremos trabas a los desarrolladores insis-tiendo en demasiadas prioridades a la vez.

Tecnología

una fbrma rápida de 'ejorar

la velociciad de clesarrollo es Dasar cle usarherramicntas menos efectivas a otras más efectivas. En la hisroria det desa-rrollo de software. uno de los cambios con mayor influencia fue el pasode lenguajes de bajo nivel, como el ensamblador, a lenguajes de alto ni-vel, corno c o Pascal. La actr"ral tendencia haua componentr.are (vBX yoCX) puede producir resultados igualrnentc espcctaculares. La selecciónde herramientas efectivas y la gestión de ros riesgos asociados son aspec-tos claves en una iniciativa de desarrollo ránido.

SinergiaHay un momento en que ocuparse de la gente, cl proceso, el proclucto yIa tecnología se convierte en un todo. Neil olsen rcalizó un estuclio cr.rel que descubrió que pasar de una inversión baja a media e'pcrsonal,

REFERENCIACRUZADA

Para más informaciónsobre el efecto que

pueden tener losobjetivos en el plan de

desarrollo, consulte"Definición de

objetivos", en laSección 1 1.2.

REFERENCIACRUZADA

Para más informaciónsobre herramientas deproduct¡vidad, véase el

Capítuto t S,

" Herramientas paraaumentar la

productividad..

ffiDATOS REALES


formación y entorno de trabajo produce unas ganancias similares: in-versiones adicionales se justificaban con ganancias i a l, aproximada-mente. Pero al pasar de una inversión en personal. formación y entornode trabajo dc nilcl medio a alto. la productividad se dispara, con una ga-nancia dc 2 a 1, o de 3 a I (Olsen, 1995).

Los urétodos de ingeniería del software también pueden cooperar. Porejer-nplo. los cstándares en codificación de una organización ayudan a

proyectos concretos. pero también hacen que sea más fácil reutilizar compo-nentes en otros proyectos. A la r,'cz, un grupo de componentes reusablespucde ayudar a que se respeten los estándares en codificación, y asegu-rarse de que mantienen el significado entre distirrtos proyectos. Las revr-siones del diseño y el código ayudan a distribuir el conocimiento sobrelos estándares en codiflcaciór-r y los componentes reusables existentes, yf'acilitan cl nivel de calidad necesario para que la reutilización tenga éxito.Buenas tócnicas sueien ser la bases de otras.

r Tipos generales de desarrollo rápido

Difcrentes situaciones requieren distintos niveles de compromiso en iavclocidad de desarrollo. E,n algunos casos. nos gustaría incrementarla velocidad de desarrollo sicmpre que sea fácil hacerlo, y sin que supon-ga un coste adicional ni la dcgradación 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. Características de los enfoques estándar de desarrolloorientado a la planificación

Ef'ecto del enfoque de desarrollo en.,.

Enfbque de desarrollo ... Plan ... Coste ... Producto

N4étodo normal

Desarrollo eticiente ( equilibriode coste, plan y' tirncionalidad)

Desarrol lo eflcientc ( desarrol loefi ciente orient¿rdo haciael nre.lor plan)

Desarrollo rápido a fondo

Medio Medio

Me.lor que Me¡or que

la media la nredia

Mucho rnejor Algo rnelorque la media que la media

El más corto Peor que laposible media

Medio

Mejor que

la media

Algo mejorque la rnedia

Peor que lamedia


REFERENCIASCRUZADAS

Para ver un ejemplode los benef icios

dei desarrolloraprdo, consulte la

Sección 4.2, "Basestécn¡cas", y de formageneral el CapÍtulo 4,-Bases del desarrollo

de software".

Desarrollo eficiente

Tal como se ve en la Tabla 2.1. el r¡ótodo nredio es... nleciio. El se-cunclcrenfoque nrostrado en la tabla se c.tiqucta corno <clesarrollo etlcienre)). y.como muestra la Fi-uura 1..1. es la conrbinación de los tres pilar.es clc lavelocidad márima de c'lesarrollo. E,ste enfoquc es el que sencra nrL-iorresultado que la media en cada una cle las tres catcgorías. N{ucha -ucntealcanza sus objetivos cle planificación dcspués cle ¡roner los trcs prinrcrospilares cn su sito. Algunas personas clescubrcn quc clcspuers cle toclo ncrnecesitaban el dcsarrollo rápiclo; ¡sólo tcnían c'¡ue organizarscl para mu-chos proyectos. cl desarrollo etlciente sLlllonc rLna optintizacirin not¿rblcdel costc. plan y características del proclucto.

¿,Se pueclen conseguir planes cortos sin alcanzar prinrercl cl clesarrollcreficicnte'.) Es posible. Podemos elegir métodos cf-ectir.os v orientacios ula planificación v evitar métoclos lentos e ineficaces sin ocuparrnos tleldesarrollo eflciente cn sí Sin enrbar_uo. aunclue sc obtenga el clesarrcllloeficiente, las posibilidades de érito cn el uso cle r.nótoclos oricntadosa planificaci6n son inciertas. Si cmplcanros nrétoclos concretos oric-n1a-dos a planificación sin una estratcgia general" emplearcmos nriis tie nr¡romejorando la capacidad c'le dcsarrollo global. por supucsto. scilo uosotros

.$.s

Métodosorientados a

planif icación

Figura 2.4. Desarrollo eficiente. Los tres primeros pasos para lograr elmejor plan posible conforman el *desarrollo eficiente.. Muchos equipos deproyectos descubren que el desarrollo eficiente ofrece toda la vetocidad dedesarrollo que neces¡tan.

Mejor planifrcaciónposible

FM eá@M e&Evitar Bases Gesterrores del declásicos desarrollo rie

B EFERENCIASCRUZADAS

,-: Tas rnf ormac Ón

:-:aos oflentaoos a: -. dad o métodos

:-:aoos at r esgor: 0 an consulte la:=:c on L2..Cómo

- -t'ar e desarrolloraptdo,,. y la

::,c o¡ 6 2. ,,¿Qué

: -.o 0e desarrollo-:.¡ do necesita?',


s¿rbrcmos si r-'s urás importante me'jofar las capacidades cle desarrollo glo-bal o intentar acabar nras la¡riclanreute uu pfolecto coucrcto.

Otra razón pafa ccntrafse en el clesarrollo cflciente consiste en que en

la rlayoría clc las olganizncioncs. Ios c¿lnrillos para llcgar al desarrolloeficientc ) obtcner planes nr¿is cortos son los n.lisr.r.ros. E,n cstc aspecto.hasta llegar a cieflo llLluto. los canrinos hacia planes cortos. nrenos de-f'cctos v llrenor coslc son tanrbién islrales. C'onro r.r.rucstra la FigrLra 2.5"cuando sc alcanza el cie'sarlollo ctlciente los ciulrinos e()lnicuzan a scpa-rarse. per() dondc uos clrcontran.ros ¿ihora. la nral'oría cle los grupos cle

desarrollo sc bcneflciarian dc poncr runtbo cn printcl lugar hacia cl clesa-

rrollo elicienlc.

Desarrollo eficiente or¡entado hacia el mejor plan

El tercer cntbque dc- clcsarrollo nrostrado cn la Tabla 2.1 cs una variaciónciel clcsarrollo eficicutc. Si e stanros aplicanclo el dcsan'ollo cllcicntc y velltosclue aún nccesitamos una nrc.jor eficacia clcl plan. pociemos optar pof nte-tcldos dc clcs¿rrrollo clur' sc oLrcr.rtcr.r lr rne re-ntentar la r elociclaci dc dcsarro-llo. rcciucir cl ric-s-uo dc la planrfic¿tciórr o urejorar la risibilidacl dcl pro-gre s(). Tcrrct'cmos qLle haccr peclueños sacrifle i()\ L-lt costl- I, ca|re tcrísticasdcl prociLrcto llara ganar clt tclocic'lacl o prcclccibilidad; sin crrbargo. sipaltimcls clc la base clel clcsan'ollo eflcicntc" aun cstarcntos utuy pol enci-n-ra dc l¿t mc-clia.

Ciudaddel desarrollo

Para llegar aquÍ use métodoseficrentes en general

rápido

A la ciudadde reducciú¡de defectos

Ciudad de la olanificacióny cosre \

Ciudad deldesarrolloef iciente

A acudadoe maxrmasatrsfaccióndel usuario

Figura 2.5. El camino hacta el desarrollo rápido. Desde donde estanahora la mayoría de las organizaciones. la ruta hacia el desarrollo rápidosigue el m¡smo camino que Ia ruta hacia el mín¡mo de defectos, máximode satisfacción del usuarto y los menores cosfes de desarrollo. Despuesde llegar al desarrollo eficiente, las rutas com¡enzan a separarse.


REFERENCIASCRUZADAS

Para más informaciónsoore pranes

nominales. consulte. Plan if icacion e s

nOmlnaleS", en laSección 8.6. Para más

información sobrecostes de la reducción

del plan. véase ,,Dos

Sección 8.6.

Desarrollo rápido a fondo

Hl irltinrc'r cr.rfirquc- cle clesarrollo oricntar'lo a la planificación es el clenol.nt-

naclo <ciesarrollo ruitrirkr ¿r tirndo>. la courLrin¿ición cle mcltcldos ot'icntados

a planil'icacitin cficit--ntcs e i¡¡eflcientcs. l-lcga u11 ptlltto cn el c¡tre traba-janros lo rne.lor v lo mas dr,Lro cluc poclcnros. t t'u irr Ltttico qtLe Llucda porhacer cs ¡ragar rnlis. retluclr cl conirrnto clc caracteristic¿rs o reducir el

lre tl.it..l.t de l Pt'odlit l,r.LJn e'jcnrplo cie quc! cluiere rlecir niótt'lcio <inclicicnte)) cs: podeutc'ls t'e-

clucir cn un 2-5 iror i0() el pian clc dcsarrollo nonrinal cle un prol,ectcl sinr-plenrcnlc inclLrvcnclo mas gcntc. Siu clnbargo^ cicbido ¿rl increr.ltcrrto en

las conrunicaciones 1'la gcstitin global. su'clcbcría incrcntctttar cl tanraño

clel cquipo en un 75 por 100 pant obtct-tct'una rcclucción clcl plan dc un 2-5

por l(X). El ef'ccto nclt cle acortar el plan 1'agranclat'cl tantaño del cqtripocs 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 mavoríu sc acaban nrcjclt'itsanclo sólo alguna fbr-rrra de dcsarrollo cficiente.

REFEFENCIACRUZADA

Para más inforn¡aciónsobre la necesrdad de

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

fondo. consulte ia

Secc ón 6 2. ,,¿Qué

t po de desarrollorápido neces¡ta? -

2.4. ¿Cuál es la dimensión más importante?

REFFRENCIACRUZADA

Para más informaciónsobre la personal¡zación

de os procesossolllvar e a las

necesrdades deproyectos concrelos.

véase 1a Secoón 6.1,,,¿Existe un modelo

ún co?-

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 nivele stratógico. cstas clistiutas clllprcsas licnct.l bastante etl conrtttr. Han atrlrcn-

tlitlo a e'r'itar los crrorcs clásicos. Aplican las bases clel clcsarrollo. Y lcalizanun¿r gestión acli\'¿r dc ricsgos. A nivcl táctico. cxistc un nlundo cle clife-rencias cn las lbrmas cn l¿rs quc cacla una dc csrs orqanizilciolrcs que han

tcniclo érito sc cL-ulru cn la gcntc. cl proccst'l y'la tccnología.I)ilerentcs provcclos ticncu clilcrentcs necesidades. pero en todos

los castls la cl¿rvc cs ¿rccpt¿rf los línritcs cn las dinrensiones que no podentos

c¿rnibial v ccntrarsc cn las olras dinrensiones para obtcner el rcsto cle

los bcneticios quc lrcccsitanros cn la planificacirin.Si estamcls clesarrollanclo un sistenr¿r cie inyccción de courbustible cle

urr cochc. para clcsarrollar sofiri'arc cn'rl.rotrirclcl dc tienrpo rcal no podeluos

utilizar lcnguajcs c1c cuarla ge ncración o en.rpleal entornos de progranra-crtin risn¿rl: neccsitan.ros il¿is cflcicncia l mavor conlrol a ba.io nivel dclque o1'rcccn esns helranliculas. Evital'cmos cxpandir demasiaclo la clirnen-sión de la tccnologíit. hn vcz dc cso. dcsarrollarcnros la tecnología lo quc

¡todanios. y ceutrarenros toclos nucstros esfuerzos en las dimcnsiones cct-

rrespondicnles a personas. proccso y producto.

Capitulo 2: Estrategia para el desarrollo rápido 27

Si estanros trabajanclo cn Lln pfosranra clc gcstiórr doméstica. quizás serrtilicc url lcnguaie tlc cuut'tu genr'r':reión. un entorno clc proeranrtrción yi-sLlal o ull¿'l herr¿rtrtict'lt¡ CASE. Potlren'los crpanclir al mhrin.to la tccnolo-gía. Pcro podr'ía tlaba.jlr nllra rurl cnrl)rc\il pesacla quc nos impicla hacertlrttchas cosas ct'l ia dirttcltsirirt corrcs¡roudicutc ¿r las pu'sctnas. Se clcsarro-ll¿rrh la clinrensitin cL,-l pcrsonal toclo lo c¡Lrc ¡rclnrita la compañía. ),el rcstodcl csÍlcrzo sc enr¡rleani en las cliurensioncs crc ¡rroccso y proclucto.

Si t|abajanrr)s en ulr nrercaclo diri-giclo Irrrr pr'!-\tirci()nL-s clr paquctes((pfÓt-á-llortcr'). no l.loclcnros rcclLrcir cl conjunto clc prestacioncs lo sufl-cientc cr.rn'rti para tencr Lrn lrlan a¡r-rstacio. Sc rcclucirán lo r¡ás posible v seclcsarrollarán la gcntc. el ¡rroccstl y, lir tccnología hasta obterrcr lo rrccesa-n0 p¿lra cubrir cl plan

Este libro describe tres tipos genelales de proyectos: cle sisfent,,-, de.qes-t¡(tt¡ .t ,,

l1t (:t-r't.l)(tt'lL't ,,.

Hl softlvare c1e ,ri.r're,r¡¿¡"r inclr-rye el sistcma operativo. controladorcs dedispositi"'os. compiladorcs ¡'bibliotecas de código. Desde el punto de vis-ta 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 misrnascaracterístic¿rs que el soft',,uare de sistern¿rs.

El software de gesriltn se reflere a sistcrnas internos. q'c' se utilizan enuna única empresa. [runciona sobrc un hardrvare limitado. quizás un únicocomputador. Los cjemplos típicos son sistenras cle control de nóminas. con-tabilidad o control dc ah¡acén. El.] cste libro. el sotin,are IS, IT y MIS setratan corno pertenecrentes a un grupo más general. el soflware de gestión.

El softr.r'are <<prét-c)-porte¡.> es soltrvare empaquetaclo y que se venclecornercialmente. Incluvc trltto Irruductos pilra el rnercado horizontal (cornotratarrientos dc texto v hojas de cálculo), corno productos para el mercado

'ertical (como ¡rrogramas de anhlisis ñnanciero. escritura cle guiones y ges-

tión de infoluraoión lcgal).Se emplca' algunos ot'os té'ninos para ref-erirsc a tipos de softu,are

que no están clescritos por estas tres etiquetas generales. Softu'are (.oner,cial es cualquier tipo de softu,are desan'ollado para venderlo comercial-rnente. Ef software dontéstic¡¡ es el softr.vare desarrollado únicamente parausos domésticos y no para la venta. E,l soft,,vare militur se escribe parausonrilitar. El softrvare iilfera(rivo es e I softu,'are con el que el usuario puedeintelactuar clirectarnente. c¡ue engloba la lravor partc del softu,'are que seescribe hoy dia.

[:u resurnen. se clebc analizar el pnlvccto para c'leternrinar cu¿rl de lascLlatro clitllensiones cstá linritaclu I cLuil puecle suponer la r.ná riuta rc¡ta.ja.Lttegc'r liav qtrc fbrz¿rl cittlrr unlr r'l nltriru,,. [rsta es. cn resumicl¿rs cucntas.la clar,'e clcl érito dcl clcsarrttllo rápiclo.

28

2.5. Una estrategia alternativa para el desarrollo rápido

Desarrollo y gestion de proyectos informáticos

El enfbclr-rc para el dcsalrollo rápido cluc se trat¿t cn cstc libro no es ei

unico c'nfbque conocidcl ;\lsunos provcctos han scgLriclo con órito tLn

carnino clif-erentc. Estc crurino se clr¡ctct'izil ltor colttratal al ntcjor perso-nal posible. buscirnckr un conrpronliso total con el llrovccto. sarantiz;.il-dolcs casi tot¿rl autononría. nrotirálrdolcs en graclo crtrcmo. r'clcspuós eonr-probirr que trabajan 60" 80 o inclu-so 100 horas a la sertrana l.rasta qr-re bir':tcllos o el provccto tcrnrin¿rn. El clcsalrollo rirpiclo con Lllr cnfirc¡ue basacl,

en cr)lrprouriso sc consir:ue cou valor. suclor 1' detcnlin¿rcititr.Este enfoquc ha gcneraclo óri1os notables. incluvenclo N{icrosoti \\ in-

clous NT i.0 r cl l)ata (ienr-ral Faglc C'ontputer" I'cs incucstionable clil.cs cl enfbquc dc dcsarrollo rápido ntás po¡lular 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.n¡lo clc colocarlo cn cl ntcrcado. haciutdo que la entples¿t g.t::,una fbrtuna v cousi-ga dinero rátrriclamente" ¿llrtcs incluso cle clue el erlut:'acabe el prclclucto. iVl¿rntener un cquipo cle pequeño tantaño tarrbién lc.i .-cc las corl.runicacioncs. la coordinacirin 1, la gestión 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 práctre .i ,más durcza qr.re cr.riclaclo. Nornralrucute -senera un enfbclue clc coclit'r ,ción a clcstajo. clue provoca qne los provcctos se al¿rrgucl.l conlo sl tir;:..etenros. El enfoque es una corrección rápicla" v ticnc toc'los los problc::de otras correcciones riipidas. A lo largtt del libro sc criticarr tspt-.crrr. . -

este enfclclr-rc. A cclnlinLr¿rción se ntucstra un resuuten.

REFERENCIASCRUZADAS

Para más informac ónsoore enloques

basados en<^ .^ñ<L lio

,, Planif icación basadaen comprom¡so,,. en

la Secclón 8.5, y

el Capitulo 34.-Comprom so,,.

El enfoque implica ganar o perder. A vece s fLrncion¿r: 0 \ CCC.

Los f¿rctorcs quc hacen quc fimcione o no son prácticaurentc ilnpr'- 'clc controlar. Cu¿rndo 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..difícil contrcllar l¿is caracteríslicas cspccíficas del proclucto.

Provoca problemas de motivación a largo plazo. En los |r.o\ --basados clr colrprolliso. los desarrolladorcs con'ricr.rzan con cntuSr.i.:-'cnrplear.r tantas hor¿rs cxtras colno elt sus tientpos clc princitrtiant.'. .

completar sus conrpronrisos. Nonralntcntc. r.lo cs suf icielrte colr :r' .. -

horas. ¡- firllan al intcnlar conseguir los cont¡tronlisos dcl plan. L. nr. .,

sr-r r.lroral se allaga )'sc ven obligaclos ¿r ¿rclntitir la dcrrota.C'n¿lnclo lcls clcsan'olladores ponclr su colazirll ¡, su alnra intl:

lograr sLts conr¡lron-tisos "

fallan. se ruclrct.l lcae irls tt i.lcr-l)tlu'!\,r rr'


sos adicionales. Comienzan a resentirse cle las horas ertras. Aceptan nue-vos courpror.r.risos de palabra pcfo lro c'lc corazón, y' el proy'ccto picrdctodo aspecto de plarrilicación o control. En un proyecto cluc ha alcanzadoeste estado. es cor.núrn decir <cluedan tfes sclnanas para cl final>> dr-¡raute

scis rleses o mhs.

No se puede repetir. Ar-rncluc cl cnfirque cle codiflcación a destajrr terr-ga órito una vez. esto no sLlponc un¿r basc para cl éritcl en otfo caso. Pues-

to que cansa a la gcntc. cs más probable qlle sientc las bases para futurosl'allos. Una errpresa r.ro puede reparar fácilnentc el claño hut.nano quc pro-vocan cstos proycctos. y los estudios de estcls pro)'ectos indican quc provo-can 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 enfb-clue dc codiflcación a destaio aporta poca viabilidad y cor.rtrol a los den.rás

irrplicados en el provccto porclLle se basa en hcroicidades indil'iduales en

vez de en la coordinación. coopcración l planrficación. Incluso cuando sc

dcsarlolle con érito cl sofirvare más rapidamctrte de lo c1r-rc cs habitual, nohay fbnna de saber cuánlo llcrará el proyecto. No sabrcnros cuánclcl aca-bará hasta quc' se acabe.

Alguno de los beneflcios dc relociclaci cluc'sc consiguen con cl cnfo-que basaclo en conlprouriso sc neutraliza debiclo a quc hay otros grulloscon quienes cleben coorclirrarsc los clesarrolladorcs. couro son los gfuposde prueba" documentacióll dc usuario o cor.uercialización.;'' rro se ¡rucdcplanificar. En un ployecto a desta.jo. la fl'ustración dc los dcsarrolladorcsal no poder obtener información flable ciel plan provoca Llna tcndL-uclf, a

la irritacióll. ¡, cl pcrsonal clcl equipg está ett colltra dcl pcrsortal er-tcrno 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 dcsarrolla-dorcs 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 nivclcle saclillcio pLrcdc scr justitlcable pal'a gallar Llu¿l guerra o llc'r'ar un hombrca la Luna. pcro no cs ncccsario para clesarrollar softu'arc de gcsticin. Conpocas excepcioncs. cstc sacrillcio no es ncccsario: sc pucdcn conscguir'los lrismos resultados con lln¿l gestión cuidaclosa. scria e intcligcntc y

con uua planificación tócnica. lo que suponc lnucho urcuos csfuerzo.La Tabla 2.2 resunre al_eunas clc las difcrencias entre el método a des-

tajo y cl quc dcscribe este libro.EI nlétodo dcscrito cn este libro mr-restra c(rrro obtcner cl dcsarrollo rá-

pido con una planificacirin cuidadosa. Llna Lrtilización eflcicntc del tiL'nrpo


Tabla 2.2. Comparación det método a destajo con el método propuestoen este libro

\Iétodo a destaio \Iétodo de este libro

Sus de f'ensores aducen rnc. jorasincreíbles e instantirncas cn cl ticrrpode clesarrollo.

Ncccsltu ¡toca erpericncit tccnol(tgicaap¡rtc. dc conocitr-lielrltts encod i fic¿rc irin.

Ricsgo alto: fl'ecucntentente f'alla.inclriso cu¿rnclo se ha hecho dc lafbrrla nrás ef-ectiva posible .

Los denrhs ltos vcn coÍno <r-aclicales));parecc qLie cst¿uros en las r"rltinras.quc tuviérantcls toclo.

Se entple-an clentasiaclos recursoshur¡anos.

Ofl'ecc poco avancc cn r.isibiliclacl ocontrol. Sc sabc c¡ue sc ha ¿rcabadocu¿rndo se terrnina.

Es un ntétoclo tan viejo cor.no clpro¡:rio sofiu.'arc.

SLrs def'cnsores aclucert r¡odestasrneJor¡s lnstantáneas. seguiclas porrre.Joras ntavores y a más largo plazo.

Nc-ccsita una experiencia tecnoló-qicaacler-nás de conocimient()s encod i fl cac i ón.

Ries-qo ba.jo: pocas '".eces falla cuanclosc aplica cle fbn¡a ef'cctrva.

Los dernás nos vcn comoconsen'adores. aburridos e inclusof'eos. No parece que estamostrabajando duro.

Us¿r los recursos hur¡anos de fbnnahumana v eficiente.

E,s posiblc personalizar el métodopara dar toda la visibilidad y elcontrol neccsarios.

Los eler¡entos clales del método seenr¡rlcan con éxito desde hace niás deI 5 años.

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

disponible y la aplicación de técnicas de desarrollo orientadas a pranifica-cicin. Las horas ertras son habitrales en este tipo de desarrollo rápido.pcro no suele ser el misr.no montón de horas exrras que se usan en el mé_todo a destajo. No'.'alnrentc. el dcsarrollo cficie'te genera un plan máscorto que la nredia. Cuando falra. se debe a que la gcnte piercle ra determi-nación dc seguir i¡sando el ntótoclo, no a que falle cl propio método.

Resuuriendo. el método a desta jo asegura un sacrilicio extraorcirnario.per. no unos resultados cxtraordinarios. Si el objetivo es la márima velo-cidad de desarrollo en vez de las r¡áxi'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 infbrma-ción nccesa.ia pa'a llcr,ar con cl rnejor é.xito posible un proyecto a destajo.ciertarrentc. una pcrsona podría transformar este ribro der cioctor Jekyllen el dc Nfr. H¡,dc a destajo. pero hay ntncho cje rní cn este tipo de desa_rrollo. y no \¡ov a crplicar cómo usarlo.


Ejemplo 2.2. Desarrollo rápido con una estrategia clara

Miembro de la compañía a partir de Square-Calc 3.0, Sara estaba preparan-do el proyecto Square-Plan 2.0. Square-Plan era el paquete de gestión deproyectos de Square-Tech. Sara era el jefe técnico.

En la primera reunión de equipo, Sara presentó a los miembros delequipo y planteó directanlente el asunto. <He recorrido toda la compañiarecolectando los infonnes post-ntortem de los proyectos>, dljo. <Tengo unalista de un kilómetro de los enores que se han cometido en otros proyectosde la compañía. He puesto la lista en la sala de reuniones. y nre gustariaque avisarais si cometemos aiguno de ellos. Tal.nbién querría c¡ue incluye-seis cualquier posible emor que conozcáis o que encontréis según avanza-rnos. Si no hay que hacerlo, no es cuestión de repetir la historia.

Os he seleccionacio para este equipo porque cada uno de vosotrosdomina las bases del desarrollo. Sabéis lo que significa hacer un buentrabajo de recopilación de requisitos y diseño para que no perdamos tiem-po en vueltas atrás innecesarias. Qr,riero que todos en este proyecto tra-bajéls inteligentemente en vez de trabajar duro. El personal que trabajademasiado duro comete dernasiados errores, y no tenemos ticrnpo paraello.

También he incluido un plan de gestión de riesgos. El plan es agresivo,asi que no podemos pennitir que nos atrapen los riegos de los que estamosavisados. E,l mayor riesgo de la lista es que el plan puede ser inalcanzable.Quiero que rehagáis el plan al final de la semana, y si no se puede cumpllr.haremos uno algo más realista.>

Todo el equipo asintiti. Para el personal que venía de provectos que sehabían desarrollado a un ritmo endiablado, las palabras de Sara pareciancomo una bocanada de aire fresco.

A1 final de esa semana, Sara se reunió con su jef'e. Eddie. <El equipoha echado un buen vistazo al plan del proyecto, Eddie, y henros comproba-do que sólo tenemos un 5 por 100 de posibilidades para llegar a la fechatope con las prestaciones actuales. Suponiendo que no ha¡,a cambios, 1,

siempre hay algunas cosas que cambian.)<<Eso no es bueno), dijo Eddie, Eddie tenía reputación de entregar lo

que prometía. <Quiero al menos el 50i50 de posibilidacles cle entregar elsoflwarc a tiempo, y quiero que scalnos capaces de responder a los cam-bios en el mercado durante los próximos l2 meses. ,,Qué recon.riendas?>

<Aún no está completamente especificado el producto, y tenemos al-guna flexibilidad>, d¡o Sara. <Pero creo que el conjunto de requisitos ac-tual llevará de l0 a 30 meses. Sé que es un margen arnplio. pero es lo másque puedo decir antes de saber más sobre 1o que tenerros que construir.Tenemos que acabaren 12 meses, ¿cierto? Considerando esto, creo que sedebería incluir otro desarrollador y entonces fijar un plan de entregas evo-lutivas donde se planificará construir una versión comercializable del soft-ware cada dos meses, con la prinrera entrega a partir de los 8 meses.D

\.(onltlluu )


<Me parece bien>. dijo Eddie. <Adernás. crco que cn este proyecto lafuncionalidad ciebe ser más irr.rportante que er pran. Déjame hablar con al-guna gente y te llamaré.>

cuando Eddie llarnó a Sara, le dijo quc la compañía tenia la voluntadde forzar a c¡ue el plan del software fuese de l¿l rneses para conseguir lasprestaciones descadas. pero para nrayor segulidad deberia emplear el plande cntregas evolutir,as. Sara se tranquilizó ¡' dijo que ella pensaba que ésteera un objetivo más realista.

Durante las p'imeras semanas del proyecto, el equipo desarrolló unprototipo 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 proto-tipado poclía suponer una vida en sí lnismo, así que se fijó una ventanatemporal rígida para cl trabajo en el prototipado que evitase construir unpfototipo excesivamente rreticuloso. El prototipo se utilizó para realizarentrevlstas con los posibles clientes acerca de las utilidades canclidatas, yel prototipo s* rcvisó i arias r cces cn respuesta a las indicacioncs de rncjo-ll de los usuarios.

Sara siguió manteniendo la lista de riesgos y determinó que los tresricsgos clat'es para el pro¡recto eran la baja calidatl, que podría provocarexcesivas vueltas atrás y el alargamiento del plan, Ia agresiviclad del plan,¡, las prestaciones que añadiria la competencia desde ahora hasta la linali-zación del proyecto. Sara creía que el plan tle entregas evolutivas se habíaaplicado por el riesgo de la calidad. Deberian entregar la primera versiónclel software al grupo de control de calidad. eA, en el límite de los g rne-ses. y QA podría 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. Debían desarrollar lo más que pudiesen en l4 meses, perollevando el producto a un estado comercializable cada dos meses. y debianasegurarse de tener algo que entregar cuando fuera el nromento. Tar¡biéntomaron decisiones de diseño para varias prestaciones que estaban especi-ficamente indicadas para ahorrar tiempo de implementación. El menor tiem-po consunrido en las implementaciones no era una tfanlpa, pero era acepta-ble, y supuso una reducción en el riesgo del plan.

El equipo gestionó el .iesgo de las prestaciones de los competidores dedos fb'nas. Emplearo' cinco rneses en desar¡oilar un diseño que incluyeseun entorno capaz de sopoftar todas las prestaciones que habían prototipadov unas cuarltas rnás que creían que debían incluirse en la versión 3.0. sudiseño pretendía qr,re se pudiese adaptar a los cambios con poca dificultad.También asignaron tiempo en el rnes l2 para revisar los productos de loscompetidores, revisar el prototipo e irnplementar las prestaciones necesa-rias para ser con-rpetitivos en los últimos dos meses.

En el sexto l1res, con el diseño cornpleto, el equipo fijó un conjunto rJehitos miniatura que indicaban el calnino a seguir pura otten.. la primeraversión comercializable que pudiese ser probada en el octavo mes. La ver-sión del octavo mes no hacía rnuchas cosas, pero la calidad era buena, y

l (otlltiluuJ

Capitulo 2: Estrategia para el desarrollo rápido

suponia una buena base para cl trabajo siguiente. Pasado este punto, elequipo fijó otro cclnjunto de hitos miniatura, que los llevaria hasta la ntarcadel rnes 10. El equipo Lrtilizó la misma técnica para el hito dei nres 12.

En el mes I 2. 1, según lo planeado. el equipo revisó los productos de lacompetencia. Un cornpetidor había acabado un buen producto en el mes10. y contenia alguna utilidad que Square-Plan 2.0 tenía que incluil paraser competitivo. El equipo incluyó !'stas ltuevas prestaciones a su lista prio-rízada, reordenándola, y se ñjaron ntinihitos para los dos últimos meses.

En ese tiempo, José, uno de los desarrolladores con lrenos experien-cia. descubrió una organización r.rn poco nrcjor de los cuadros de diálogodel producto y llevó el asunto a una reunión del personal. George. uno delos desarrolladores más veteranos, respondió: <Tu idea es buena. Creo quedeberiamos cambiarlo. pero ahora no podenos, José, Sólo se neccsita undía para el carnbio. pero afectaria al plan de docurnentación al nrenos enuna sernan¿r. ¿,Qué os parece si lo ponernos en la lista de la versión 3.0'l>

<No había pensado en el efecto sobre el plan dc documentación>, dijo.losé. <Está bien. Lo pondré como una petición de cambio para nrás tarde.>>

A los 14 meses. el equipo acabó la versión final del software. tal comose planeó. La calidad de Square-Plan era cxcelente. puesto que se habíaprobado desde el octavo rnes. La sección de docul¡entación pudo cen-trar sus esfuerzt¡s en el plototipo detallado de la interfaz de usuario. mien-tras esperaba que llegase el software. Los desa¡rolladores no tuvierontiempo de implententar varias de las prestaciones de más baja prioridad,pero habían implernentado tocias las importantes. Square-Plan 2.0 fue unéxito.

33

3 i bl iografía adicional

No conozccr libros gencrales quc traten los terras del productcl o la tec-nología colno se han dcscrito cn este capítulo. Este libro trata estoselementos cn más profuncliclad c.n el Capítulcl 14" <Control clcl conjuntt'rde prestacioncs>: el Capítulo I 5. <Herrauricntas ¡rara aumentar la producti-vidad>. 1'en cl Capítulo 31. <<Lcngua.jes para el clesarrollo r'ápido>.

Los trcs libros siguientes oll-ecen inlbnración gencral sobrc enfbqucsbasac'lcrs etr pcrsonal (pt'o¡tlt,vurt.) para cl clesarrollo clel softu,arc. El pri-nlero es un cl¿isico:

DcN1arco. Tonr. y Tintothy Lister: Paopletrura; Pt't¡dut'tiye Pt'oit,r't.s trttdTt,unts. 1.¡-eu York. Dorsct Housc. 1987.

Const¿rntir.rc" Larry L.'. ConstuÍitta r¡tt Peoplerut'a. E,rrglcri'oocl Clifl\.N. .1.: Yourdon Press. 1995.

Plauger. P. J.: Progt'untntittg ort Pur¡tost'll; [:.s.su.t'.s otr Sofiwure Pco¡tle.Engloroocl Cllif Ís. N..1.: PTt{ Prcntice Hall. 1993.

34 Desarrollo y gestión de proyectos informáttcos

Los siguientcs libros ofl'ccen info'ración sobre los procesos del soft-u'arc. cl prin.rero a nivel orsanizacional. el scgundo a nivel del equipo y eltcrccrcl a nivel inclividiral.

carnegie N{el lon Un i vcrsity/Sofl."vare Engineering Institute: T he c apub i -lit.t' il,'Íuturit.t' ,\loclel; Guitlelines fbr. inr¡tr.oying the .sofiwctre prot'ess.Rcading. Mass.: Addison-Wesley. 1995. Este libro es un resumen delos úrltimos trabajos para mc-jorar el proceso de softwarc realizadospor cl Soltu.'arc Ensincering Institute. Describe el ntodclo complctode ntaclurcz cle procesc'rs cn cinco nir,cles, los beneficios que se obtic-nen con cada nir'cl v los métodos quc caractcrizan cada uno de ellos.Tanibión it.rcluvc ejen¡rlos dctallados de una entprcsa que ha conse-gLrido 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 demáximas tradicionalcs qr-re pr.reden utilizar los rcsponsables dc losproycctos para hacel quc sus cquipos sean productilos. y da un vistazointcresante de las intcriorid¿rdes 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 procesode sofirvare. que trtrtderlos adoptar a nil'el individual, independien-ternente de que nucstra entpresa sopofte la ntejora del proccso.

Errores clásicos

Contenido

3.l. E.jcmplo de errores clásicos3.2. E,fecto dc los crrores en la pro-tr.antaciitn de ulr dcsarrollo3.3. Relación de errores clitsicos3.4. La fuga de Lu islu de Gilligun

Temas relacionados

Gestión de riesgos: Capítulo 5

Estrategia para el desarrollo rápido: Capítr-rlo 2

EL DI]SARROLLO DE SOFTWARE F]S UNA ACTIVIDAD COM-PLICADA. Un proyecto softu'arc típico puedc presentaf r.nás oportuni-dades para aprender cle los errorcs que las planteadas a algr-rnas pcrso-nas durante toda su r''ida. Este capítulo exantina algunos dc los crroresclásicos que sc conteten cuando se intenta ciesarrollal sofir,t,are ránicla-tnente.

Ejemplo de errores clásicos

El sigLricnte c'jeniplo es un poco corro lcls pasaticmpos clc los niños. cnlos que intentamos encoutraf toclos los objetos cu1,o nourbre conrienzacon la letra <M>. ¿,Cuántos errores clásicos pucclc cncontrar en cI sigLricn-te e.1e-rrrplo'.)

35


Ejemplo 3.1. Errores clásicos

Mike. un responsable técnico de Giga Safe, estaba conriendo en sn ol'icinay n.rirando por la Ientana una brillante lnañana de abril.

<¡Felicidadesl ¡Mike. ya rienes los fondos para el programa Giga_Quotel> Era Bill. el jefe de Mike en Giga, una cornpañía de seguros médi-cos. <Al cornité ejccutivo le ha gustado la idea de autornatizar nuestrascuotas de seguro médico. Y también la idca de volcar cada noche las cuo-tas del clía en la oflcin¿r principal para que siempre tengamos al dÍa losúltimos valo¡es de ventas. Ahora tengo una reunión. pero podemos discutirlos detalles más 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 cornunicación con la oflcina principal. perfecto. ésta era la opor-tunidad de cii.igir Lrn proyecto cliente-servidor en Lln moderno entorno GUI(inferiaces grálicas de usuario).1o que sienrprc había querido hacer. Elproyecto le llevaría al lnenos un año. y lo ocuparía a tiempo completo.Mike descolgó el teléfbno y marcó el número de su esposa. <Cariño, estanoche cenaremos fuela para celebrarlo...rr

A la mañana siguiente. Mike quedó con Bill para discutirel proyecto.<Vamos a ver. Bill. ¿,Qué pasa? Esto no se parece a la propuesta en la quehe trabajado.>r

Biil se sintió inseguro. Mike no había participado en las revisiones dela propuesta, pero no hubo tierrrpo de avisarle. CLlando el comité e.jecutivoestudió c-l programa Giga-Quote^ tontaron los mandos. <Al con-rité ejecuti-vo le gustó la idea de construir software para automatizar las cuotas deseguros médicos. Pero querian que se pudieran transferir automáticamentelas cuotas locales al cornputador central. Y qucrían tener hecho el sisternaantes de que se hagan efectivas Ias nuevas cuotas el I de enero. Adelanta-ron 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 había estinrado que el trabajo ller,.aría l2 meses. No creyó que

tuviese la suerte de acabar en seis meses, y así se 1o dijo a Bill. <Varnos ar''er si me he enterado>. diio Mike. <Parece que estás diciéndome que elcomité añadió requisitos de comunicaciones a gran escala y ha acortado elplan de 12 a 6 rreses.>

Bill se encogió de hombros. <Sé que será un reto. pero tú eres creati\.oy creo que puecles con todo. Han aprobado el presupuesto que querías, yañadir el enlace de comunicaciones no debe ser difícil. Pediste 36 perso-nas-mcs y las tienes. Puedes reclutar a quien quiera que necesites parael proyecto e incrementar el tamaño del equipo.> Bill le dijo que hablasecon algún otro desarrollador y que buscasen la forma de entregar el soft-ware a tiernpo.

Mike se reunió con Carl. otro responsable técnico, y buscaron la forntade ¿rcortar el plan. <,;Por qué no usas C+* v diseño orientado a objetos?>,

\( otlttnIt(t )

Capítulo 3: Errores clásicos 37

cr¡rlentó Carl. <Serás más productivo que con C, y el plan se acor.tará enuno o dos meses.) A Mike le pareció bien. Carl también conocia una he-l'r'ar¡ienta de elaboraciirn de infbm-res que supuestamente acortaba el tiem-po de desarrollo a la mitad. El proyecto tenia bastantes infornres, y portanto esos dos car-ltbios los llevarían hasta los 9 rneses. Consiguieron hard-\\are nuevo y más rápido. y esto les ahorraba un par de setnanas. Si real-rnente podía recluta¡ a desarrolladores dc primerisima categolia. podría bajara 7 r.neses. Esto era suflcientenrente ajustado. Mike comentó sus progresosa Bill.

<<\,1ira>. dijo Bill, <dejarel plan cn 7 mescs está bien, pero no es sufi-ciente. El conrité dejó claro que el plazo de entrega eran seis meses. No meclieron opción. Puedo daros el hardr,vare que necesitáis, pero tú y tu equipotenéis que encontrar una fornta de redr.rcir el plan a seis meses, o tendrérsque hacer algr.rnas horas extra para paliar la diferenciar.

Mike se planteó el hecho de que su estimación inicial sólo fue unaaploxirnación y pensó que quizás podría bajar.la a ó meses. <De acuerclo,Bill, buscaré un par de personas externas espabiladas para el proyecto. euizáspuedn cnctrntrJr geltte eon expericncia cn comunicaciones para que nosay*udc en la descarga de datos desde el PC al r¡ainfranre.>¡

EI I de nrayo. Mike había formado el equipo. Jill. Sue y Tomas eranbuenos desarrolladores de la casa. y fueron liberados. Completó el equipocon Keiko y Clhip, dos contratados extentos. Keiko tenia experiencia tantoen PC como en los rrainfiaÍle con los que tenía que conectarse. Jill y To-mas habian entrevistado a Chip y no querian contratarlo, pero Mike lo im-puso. Tenía expericncia en conrunicaciones y estatra disponible, así queMike lo contrató.

En la primera reunión de I equipit. Bill dijo que el programa Ciga-Quoteera estratégicarnenfe irnportantc para Giga Safe Corporation. Algunos de losrnagnates de la cornpañía estarían pendientes de ellos. Si tenían éxito se-rían recornpensados. Dijo que estaba seguro de que lo conseguirían.

Después de los ánimos infundidos porel discurso de Bill, Mike se sen-tó con el equipo y mostró el plan. El comité ejecutivo les había proporcio-nado una especificación aprorimada, y emplearon las siguientes dos sema-nas en completar las lagunas, Después se emplearian 6 semanas en e I diseño,lo que dejaba 4 meses para la construcción y la prueba. Su estimación aproxi-rnada fue que el producto flnal tendría unas 30.000 líneas en C++. Todoslos asistentes asintieron, dando su confbnnidad. Era arlbicioso, per-o losabian cuando se comprometie¡on con el proyecto.

A la semana siguiente, Mike se reunió con Stacy, la responsable de laprueba. Indicó que debería tener par¡es del producto tcrminadas para pro-barlas no después del I de septiembre. con el propósito de tener un produc-to con todas las funciones el i de octubre. Mike estaba de acuerdo.

El equipo acabó la especificación de los requerirnientos rápidarnente.y se metió en el diseño. Obtuvieron un diseño que parecía hacer buen usode las prestaciones de C++.

(totttittút)

38 Desarrollo y gestion de proyectos inforrnaticos

Acabaro'el diseño cl l-i cle.iunio. adclantá'close al pltrn. y col.rlenza-ron a cociilicar como locos para llcgar al objetivo r1e tener la prirnera ver-sión de p^reba el I de septieurbre. E,l trabajo cn el pr.oyectn no .r, unobalsa de accite. Ni a.lill ni a Tornas les gllsraba Chip. 1. Sue se qucjaba <ieque no queria que nadie se,ce'case a su código. Mikc atribuyó los cho-ques de personaliclacles a las muchas lroras cle tr.abajo. No obstante, a pri-meros 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 tásas paia el añosiguiente, el equipo descubriri que teria que rnodificar completamente laestnlctura pal'a las nueYas tasas. El nuer.o nrétodo dc tasación necesitabarealizal preguntas sobre hábitos de ejercicio, en ia bebida, en la comida,actividades cle ocio y otros factores que no se habían incluido antes en lasfórmulas de tasación. Pensaron que c*r debía prote*erlos de los efectoscle esos carnbios. c'alcularon que sólo tendrian que incluir nuevos valoresen las tablas de tasas. Pero tendrían que cambiar el diiilogo cle entrada, eldiseñer clc la base de datos" el acccso a la base de clatos -v los objetos decolrunicaciones para adaptarlos a la nuer.'a estmctura. como el equipo es-taba revuelto lorrlue tenía que reajustar sr-r cliseño. Mike dijo a Stacy quese rctrasarían unos tlias en la cntrcga de la primera \,ersión para la prueba.

El equipo no h¡bia te'lrinado er I de septienbre. y Mike aseguró aStacv que acabarían cn sólo uno o dos dÍas.

Los dias sc 'ol'icron semanas. El límite del I de octubre para entregar

el producto cornpleto llara sir prucba llegó y fire rebasado. Desarrollo aunno había acabado e-l primer pr-oducto para prueba. Stac¡, llanró a Bill a unal'cunión para tratar el plan. <Aún no tcnemos nada cle desarrollo;r, dijo,<rsuponianros clue tcrrdríarros la prinrera versión el I cie septiembre, y puestoque ahn no tenelll0s nada. por lo menos nos relrasaremos un r-nes respectoal plan oÍiginal. Creo c¡ue tcnelxos Lrn problemar>.

<Es crerto, tenemos r"rn probrema>>. dijo Biil. <Déjarne que hable con elequipo. He prorneticlo a 600 agentes qLre tendríauros el progralra el l denoi.iellbre . l-o entregarerros a tierrrpo para cl canlbio de ¡asa.s.>

Bíll cottt'ocó una re,nión con el equi¡to. <<Ésfe es utt equípo l-antástict¡,l'debería currplir cor s,s co*promisos>, res dijcl. <N. sé qué es lo que haido r.nal, pero espcro qre todos traba.ióis duro y entreguérs el softwa¡e atrempo. Airr.r podeis conseguir las bonificaciones, pero ahora tendréis queI,char por ellas. Desde ahora .s asignaré

'n horario de 6 días por r",.,.,unu.l0 horas al dia. hasta q'e cl sottlvare estó hecho.> Dcspués <ie la reunión,Jill r" Tomas se quejaron a Mike de q,e

'o l.rabía necesidacl de que lostrataser.I como niños. pero accedieron a trabajar las horas que Bill quería.

El equipo rctra-có el plan dos semanas, prorretiendo te.er la utilidadcompleta construida el I 5 de novieurbre. Esto dejaba 6 senranas para laprueba antes c1e que entrasen en vigor las nuevas tasas en enero.

EI ccluip. cntrcgti su p.imera 'ersión

al grupo de prucbas cuatro sema-nas después del I de no'iembre. y se rer:nió para tratar algunas de las áreasproblenráticas que qr-reclaban.

|( ()ilI r tl |tLt )


Tor.nas estaba traba.jando en la gcneraciirn de infornres )' se encontró

con Lln¿l barre¡a. <La página resuluen de cuotas incl¡-ve ¡¡ grático de ba-

rras. He utilizaclo un gene raclor cle infbnles que srttrroní:r generaba gráficos

cle barras. pero [a única forr.lta de gencrarlos cs en páginas individuales.

Uno de los requeriurientos del grupo de velltas es que hav que pnner gráfi-

cos cle b¿rrras y texto en la lnisnra página. He- pensaclo que puedo tranlpeal

un intbrr.ne con un griifico tlc barras pasando e I texto dcl inforrne conlo una

leyenda clel objeto gráfico cie bal'ras. Realnrente es trlln tranrps. pero siern-

p|e puedo volVer atrás v reimpletrentarlo más clarat-nente despLrés 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 nlás fallos. Usa esc truco.))

Chip conrentó quc stt código dc comunicaciolres estaba hecho al

95 pol i00 y c¡Lre t-unciortaba. pet'o que airtl tenia que hacer algunas prrte-

bas de ejc'cr-rción. N'like r.'io que Jill y Tomas sc mirallan. pero decidió igno-

rarlo.El equipo traba-ió duro hast¿r el l5 de novielnbre- incluyenclo las no-

ches del 14 y el l5 cle novicntbre. pcro no pudiclon lraccr quc [a feclia de

entrega lue se el 15 de noviembre. El e quipo estaba exhausto' pero la maña-

na rlel clieciseisayo dia. fue Bill quien se sintió deprinrido. Stacy le había

avisado de quc desarrollo n9 habia entregado la versiÓn coniplela el dia

anterior. La irltima senrana halría dicho al cornité ejecutil'o que el provecto

estaba encarrilaclo. OtIa gestol'a cle provectos. Claire. había investigado en

los ptogresos del equipo. dicicndo qtlc habia oíilo que no estabarl cul'n-

plienclo la-s entregas pianiticadas con el equipo de prueba. Bill pensó que

Claire estaba tensa y n0 le gustaba su info|me. Le había asegulado a ella

quc su cquipo est¿lba eu bucn carnino para cunrplir las entlegas ¡llaneadas.Bill cli.io a lVlike qtte reuniese al equipo. v cuarldo lo hizo. ¡llit'ccían

derrotados. Un ures v nteclio a 60 hor¿s semallales habían sido la punt:illa.

Mike preguntó cuánto ticnrpo lcs llevaría ¿rcabar" pero su Útnica respuesta

lue el silencio. <i,Qué nrc estáis ciiciendo?>. dijo. <t{oy ibanros a fener lista

la versirin con todas las funcioltes. (.La tellemos'l))<Mira. lr'{ike>. dijo Tor¡as. (llLredo entregar ho¡t n.ri código y decir que

incluve "tc¡da la funcionalidacl''. pel'o plobablemente rlece sitar'ó tfes sema-

nas 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 em-

presa en cada pírgina. ni clue el lronrbt'e y el telélbno del agente aparezca al

pie de la página. Son pequerias cosas como ésa. Todo lo importante funcio-

na bien. He acabado al 99 por 100.>

<Yo tam¡toco hc hecho exactatnente el 100 por 100>. admjtió .lill. (Miantiguo grullo me ha llamado para que les diese apoyo técnico' y he tenido

quc emplear un p¿lr de holas ciiat'ias con cllos. Además, había olvidado

hasta ahor.a rnismo que los agelites ¡redían poner su nombre y su teléfbno

en los infirrrnes. Aún no he iurplementado los diálo-eos de entradaparaesos

\(onttilrrLt)

40 Desarrollo y gest¡ón de proyectos tnformáticos

datos. y también ten-qo que hacer alg'nos diálogos de mantenimiento. Nocreía que fuesen necesarios para el hito de la ,.utilidacl completa'..i>

Ahora Mike talnbien empezaba a sentirse mal. <Si he oído lo que creoque hc oido, mc est¿iis diciendo que neccsitáis tres selnanas para completarel sofhvare. ,,Es correcto?>

<<Al men,s tres seman¿ls)r. dijo Jill. Elresto de los desarrolradores estu-

'o de acue'do. Mike pasó uno por uno y lcs preguntó si podrían conrpletarsu pafie en tres seÍianas. uno por uno. cada programador le dijo que traba-.jaría duro, y que pensaba que podía hacerlo.

Al final dc ese día. después cle una discusión larga e inc(rnroda, Mike yBill acordaron retrasar c'1 plan 3 semanas, hasta el 5 tle diciembre, sienrpreque el equipo prometiera t.abajar 12 horas al día en vez cle 10. Bill clijo quetenia que demostrar a su jefe quc estaba azuzando al equipo de desarrolro.La revisión del plan implicaba que rendfían que probar el có<ligo y prepa_rar al personal al urisnro tiempo, pero era la úrnica posibilidacl de entr-egarel código el I de enero. Sracy se que.ió de que cl control de calidad delsoftrvare no tenia asignado el tienrpo suficiente para probarlo, pero Bill nole hizo caso.

El 5 dc diciernbre el equipo Giga-euote cntregó el progrania Giga_Qr-rote completo al grupo de pruebas antes del rnecliodía. v salieron prontodel trabajo para tener su largamente esperado descanso. Habíar.r trabajaclocasr constantcmente dcsde cl I de septiembfe.

Dos días más tarde, Stacy dio la prirnera lista de errores, 1, se desató elinfierno. En dos días el grupo de pruebas iclentificó más cre 200 def'ectos enel programa Giga-Quote, incluyendo 23 clasificados conro de sevcridad l(<Tienen que corregirse>). <Ner veo la fbrma de que el soitr.r,are esté listopara entregarlo a los agentes locales antes del 1 de enero>, clijo. <probable-mente el grupo de pruebas necesite ese tiempo para escribir los casos deprueba de los defectos qlle ya ha descubielto. y está descubriendo def-ectoscada hora.>

Mike con'ocó urra reunión de personal a las I en punto de la rnañanasiguiente. Los desarrolladores estaban quisquillosos. Decían que había unoscuantos errores serios. pero la rnayoria de los errores indicados no eranrealnlente errores, sino lnalas interpretaciones de cómo se suponía quc te-nía que funcionar el progranla. Tomas indicó que el error # 143 era un ejemplode eso. <El inlbrme del error #143 dice que en la página resurnen de lacuota, el gráfico de barras ticne que estar elr la clerecha de la página en vezde en la izquierda. Esto no es Lln error de severidarl L Es la típica lornra enque los comprobadores sobreestiman un problema.>

Mike distribuyó copias de los informes de errores. Encargó a los desa-rrolladores que revisasen los errores que el grupo de pruebas les había asig-nado y estimasen cuánto tiempo les llevaría corregir cacla u'o de ellos.

Cuandcl el equipo se reunió de nuevo por la tarde. las noticias no eranbuenas. <Siendo realista. estimo que necesito dos senranas completas cletrabajo para corregir los errores que ya nos han pasado>, dijo SLre. <Además.


tengo que acabar las comprobaciones de integridad referencial de la basede datos. En total, necesito cuatro semanas a partir de hoy.>

Tomas habia devuelto el error #143 a los comprobadores, cambiandosu severidad de I a 3 (<Cambro estético>). El grupo de pruebas respondióque los informes fesumen de Giga-Quote tenían que coincidir con infor-mes similares generados por el programa instalado en el mainfrane parapolíticas de renovación, que era similar a los formatos de marketing preim-presos que la compañía había usado durante muchos años. Los 600 agentesde la compañía estaban acostumbrados a ver sus valores de ventas en grá-ficos de barras a la derecha, y tenían 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 página el gráfico de barras y el informe'?>, preguntó Tomas. <Paraponer el gráfico a la derecha, tengo que reescribir ese informe eoncretodesde el principio, lo que significa que tengo que escribir mi propiocódigo a bajo nivel para dar formato al informe y al gráfico.> Mike tem-bló, y pidió una estin,ación aproximada de cuánto tiempo necesitaba.Tomas dijo que por lo menos 10 días, pero que tendría que verlo más des-pacio antes de estar seguro.

Antes de volver a casa, Mike dijo a Stacy y Bill que el equipo traba-jaría incluso ios dias de fiesta y que todos los errores encontrados se corre-girían para el 7 de enero. Bill dijo que se lo esperaba y que habia aproLradoun retraso en el plan de 4 semanas antes de irse a un cfucero de un mes porei Caribe que tenia planeado desde el pasado verano.

El mes siguiente Mike estuvo ocupado manteniendo al grupo unido.Durante cuatro meses habían trabajado todo lo duro que se podía traba-jar, y no creía que pudiesen hacer más. Estaban en la oficina 12 horasal día, pero empleaban rnucho tiempo leyendo revistas, pagando facturasy hablando por teléfono. Parecía que se irritaban siempre que les pregun-taba cuánto les quedaba para reducir la cuenta de errores. Por cada errorque se corregia, el grupo de prucbas descubría dos nuevos. Errores cuyacorrección debía haber llevado 2 minutos tenían implicaciones en el pro-yecto completo y podían llevar dias. Pronto calcularon que no había formade 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 equr-po de desarrollo aún necesitaba 4 semanas más. <Esto es serio>, d¡o Bill,(tengo 600 agentes locales que están hartos de dar vueltas alrededor de unpuñado de aprendices de informáticos. El comité ejecutivo está hablandode cancelar el proyecto. Tienes que encontrar una forma de entregar el soft-ware en las próximas dos semanas. sea como sea)).

Mike convocé una reunión del equipo para estudiar sus opciones. Lescomunicó el uitimátum de Bill y les pidió una estimación aproximada de

cuándo entregarían el producto, primero en semanas, luego en meses. Elequipo se calló. Ninguno se arriesgaba acerca de cuándo podrían entregarfinalmente el producto. Mike no sabia qué decirle a Bill.

\( ollIIItLtu I


Tras la reunión, Chip drjo a Mike que habÍa aceptado un contrato deotra compañía y que empezaba el 3 de febrero. Mike comenzó a sentir quesería un alivio que se cancelara el proyecto.

Mike buscó a Kip, el programador que había sido responsable del aparta_do de comunicaciones entre er pc y er mainfiame, reasignado de apoyo alproyecto. y 1o dedicó a corregir los errores en el código de comr,nicu"ionesdel PC. Después de luchar una semana con el códigJde Chip, Kip conclu_yó que tenía algunos defectos conceptuales profundos que harían que nun-ca funcionara correctamente. Kip se vio obligado a rediseñar y reimpümentarla parte PC del enlace de comunicaciones entre el pC y el mainfiame.

Puesto q'e Bill se salió por la tangente en ra r.unión ejecutiva de mi-tad de febrero. finalmente Claire decidió que ya habia oído suficiente ymandó un (stop) al programa Giga-euote. Se reunió con Mike el viernes.(Este proyecto está fuera de control>, dijo. <Desde hace meses. Biil no meha dado una estimación fiabre. Es un proyecto de 6 meses, y ya lleva másde 3 meses de retraso sin un final claro. Estáis trabaiando tantas horas oueno hacéis progresos. Quiero que descanséis todos utr tin o. se*anu; qriároque desarrolles un informe detallado. paso a paso. que incluya roOo. y Oigotodo, lo que queda por hacer del proyecto. No quiero que foicéis el pioyec_to para encajarlo en un plan artificial. Si se necesitan otros 9 meses quierosaberlo. Quiero el informe del trabajo pendienre para el lniércoles. ño t¡e-ne que ser bonito, pero tiene que estar completo.>

El equipo de desarrorlo se aregró de tener un fin de semana ribre, ydurante la semana siguiente atacaron el informe detallado con enersías re-novadas. Estuvo en la mesa de claire para el miércoles. Revisó el i-nformecon charles, un asesor en ingenieria del software que también había revi-sado las estadísticas de errores del proyecto. charles recomendó que elequipo centrase sus esfuerzos en un puñado de móduros propensos a erro-res, que se iniciasen inmediatamente revisiones del diseño y la codifica-ción para corregir todos los errores y que el equipo .otrr.nrur. trabajandohoras fijas. para que se pudiesen hacer métricas precisas del esfuerzo em-pleado en el proyecto y cuánto se necesitaría para terminarlo.

Tres semanas más tarde. en la primera ,.tnrnu de marzo, la lista deeffofes pendientes bajó un poco por primera vez. La moral del equipo su-bió un poco, y basándose en los progresos regulares que se iban haciendo,el asesor estimó que el soitware podría entregarse, completamente probadoy fiable, el 15 de mayo. Puesto que el incremento semestral de la tasa deGiga Safe tendría efecto a parlir de I ile julio, claire ñjó ra fecha oficialde lanzamienro el I de junio.

Epílogo

EI programa Giga Quote se entregó a los agentes locales de acuerdo con elplan e[ I de junio. Los agentes locales de Giga Safe ro acogieron con entu-siasmo y algo de escepticismo.

((()nltnuu)

Capítulo 3: Errores clásicos

La corporación Giga Safe mostró su aprecio al trabajo duro realizadopor el equipo de desar¡ollo dando a cada desarrollador una bonificación de250 dólares. Unas cuantas sema¡as más tarde, Tomas pidió una larga traja,

ir Jill se fue a trabajar a otra compañía.El producto final Giga-Quote se entregó en 13 meses en vez de en 6,

pasándose del límite más de un i00 por 100. El esfuerzo de desarrollo,incluyendo las horas extras, fue de 98 personas-mes, lo que supuso ua ex-ceso del 170 por 100 respecto a las 36 personas-mes planificadas.

El producto final tenía en torno a 40.000 líneas de código C** no va-cias y sin comentarios, superior en más de un 33 por 100 a las estimacionesaproximadas de Mike. Puesto que fue un producto distribuido en más de600 puestos internos. Giga-Quote es un hibrido entre un producto de ges-tión y un producto <prét-á-porter>. Un producto de este tamaño y este tiponormalmente se debería haber acabado en 1 I meses y medio con un esfuer-zo de 71 personas-mes. El proyecto sobrepasó ambas cantidades.

43

2, Efectos de los errores en la programaciónde un desarrollo

Michael Jackson (el cantante, no el infbmático) cantaba que <Onc badapplc don't spoil the wholc bunch. baby> (una manzana podrida no estropcacl barril completo, pequeña). Esto puede ser cierto para las manzanas.pefo no lo es para el software. Una manzana podrida puede estropear elproyecto completo.

Un grupo de invcstigadores dc ITT revisó 44 proyectos de 9 paísespara examirrar el impacto de l3 factores de productividad en la producti-viciad (Vosburgh et ct1.,1984). Los f-actores incluían el uso de técnicas deprogramación modernas. diflcultad del código, requisitos de eficiencia,nivel de participación del cliente en la especificación de los requerinrien-tos, experiencia personal y alguno ntás. Asignaron a cada factor distintascategorias quc csperaban asociar con una cficiencia baja, media o alta.Por ejemplo, asignaron al factor <uso de técnicas ntodernas de progranta-ción> r'alores dc bajo uso, uso medio o alto. La Figura 3.1 de la páginasiguiente muestra lo que descubrieron los investigadorcs acerca del f'actor<uso de técnicas moclernas de progranación>.

Cuanto más estudiamos la Figura 3.1, más interesante resulta. Mues-tra un patrón general que es representativo de los descubrimientos de cadauno dc los factores de productil'idad estudiados. Los investigadores deITT vieron que los proyectos de las categorías que tuvierall poca produc-til'idad rcalmente tenían una productividad pobre, como muestra la estre-cha franja de la categoría Baja en la Figura 3.1. Pero la productividad cn

REFERENCIACRUZADA

Para un análisisrnás detallado

.lo acta ^ri{i.^

concreto. consulte laSección 4.2, "Bases

técnicas".


Porcentaje dela planificación

nomrnal

+200

+1 00

0 (media)

-1 00

Uso de técnicas modernas de programación(poÍcentaje del sistema total)

Bala Media Alta(0-25%) (26 75%) (76-100%)

BEFERENCIACRUZADA

Para más informaciónacerca del papel que

luegan los errores enel desarrollo rápido.

véase la Sección 2.1,.Estrategia general

para el desarroiloráPido'

Figura 3.1. Estudio sobre el factor *Uso de técnicas modernas deprogramac¡ó¡1" (Vosburgh et al., 1984). Hacer algunas cosas b¡en nogarant¡za el desarrollo rápido. También tenemos que ev¡tar hacer malcualqu¡er cosa.

catcgorias dc alto rendimiento variaba mucho, según muestra la franjaancha dc la categoría Alta en la figura. La productividad de los proyectosdc Ia catcgoría Alta r,'ariaba desde pobre a ercelente.

No es sorprendente que proyectos que se espera que tengan una pro-ductividad pobre la tengan realmente. Pero sí debiera ser una sorpresa eldcscubrimiento de quc muchos proyectos que se esperaba quc tuviesenuna productividad excelente tienen una productividad pobre. Lo que estegráfico y otros como óste muestran a lo largo de todo el libro es que aun-quc es necesario utilizar alguno de los métodos recomendables, no es sufi-ciente para obtener la ntáxima velocidad de desarrollo. Incluso si se hacenalgunas cosas bien, como la utilización de técnicas de programaciónmodernas. aún poder.nos cometer un error que anule las mejoras en la pro-ductividad.

Al pensar cn el desarrollo rápido, resulta tentador pensar que todo loque hay que haccr es identificar las causas iniciales de un desarrollo lento yeliminarlas. y después obtendremos un desarrollo rápido. El problema esque no hay sólo unas pocas causas del desarrollo lcnto. y que al final noes muy úrtil intentar identificar todos los orígenes del desarrollo lento. Escorno preguntarse: ¿,cuál es la causa principal de que no sea capaz de correruna milla en cuatro minutos'l Bueno, soy demasiado viejo. Peso mucho.No estoy cn forma. No me atrevo a intentarlo. No tengo un buen entrena-dor o capacidades atlóticas. No podría ir tan deprisa aunque fuese másjoven. La lista crece y crece.

Cuando hablamos dc proezas excepcionales, las razones de que la genteno las alcancc son simplenente demasiado numerosas conto para contar-

Leyenoa

I ISIS?,0", ,,..

| óL?i,',0"'ru..I ll\,4Ínimo


las. El equipo de Giga-Quote del Ejemplo 3.1 cometió muchos de los erroresque han plagado el desarrollo de software desde los tiempos más remotosde la informática. El camino dcl desarrollo de software está lleno de ba-ches. y los baches en que caigamos determinan la rapidez o la lentitudcon que desarrollamos el software.

En el software! una manzana podrida puede estropear todo el barril,pequeña. Para caer en el desarrollo lento, todo lo que hay que hacer escolneter realmente un gran error; para conseguir el desarrollo rápido te-llen'los que evltar cometer algtin gran error. La siguiente sección enumera1os grandes errores más habituales.

Relación de errores clásicos

-{l-eunas técnicas de desarrollo inefectivas han sido elegidas con tantafiecuencia, por tanta gente, con resultados tan malos y predecibles queson dignas de ser llamadas (errores clásicos>. Muchos de los errorestienen una apariencia seductora. ,,Necesitamos salvar un proyecto re-trasado? ¡Metamos a más gente! ¿,Tenemos que reducir el plan? ¡plani-fiquemos de forma más agresiva! ¿,Alguno de los miembros clave in-

Figura 3.2. El proyecto software estaba repleto de errores, y todos tosdirectivos de mayor categoría y los responsables técnicos juntos no lopueden salvar a ningún precio.

46 Desarrollo y gest¡ón de proyecfos informáticos

FEFERENCIACRUZADA

Para más informaciónsobre los buenos y

malos usos de lamotivación, consulte el

Capítulo 11,., l\,4 otivación " .

comod¿l al rcsto dcl cciuipo'.) ¡Lrspcrarentos hasta quc ¿rcabc el proycctopara dcspcdirlol ,,Hav clue accleral'cl proyccto para acabar'/ ¡C'ogerentclscuantos dcsarrollaclorcs estén i,a drsponiblcs. y que colnicnccu lo antesposible !

Los dcsarrollaclorcs. ilirectir os y clicntcs rrormalnrentc ticncr.l buenasrazoncs pafa tomar l¿rs clecisiones qLrc tonralr. y la aparicncia scductora dclos crrores clásicos cs un¿l dc las razones dc que esos crrorcs sc colretantan a r.l'lcl.luclo. Pero clcbrdo a qLre sc han conrcticlo n.luchas \cccs. sus con-sccucncias sc han he'cho láciles dc predccir. Y los crrorcs clirsicos raravcz produccn los lesultaclos quc la gcnte espcfa.

F,sta sccciórt elrulrrcra allccledol clc dos clocenas de errorcs clásicos.Pcrsottalr.ltcntc he risto colncter cacla uncl clc esos crrorcs al menos unavcz. y )-o misrxo hc contetido bast¿rntes. \fuchos dc cllos aparecen en clLlcmplo i.l. El colrúur denorrrinador de csos en'orcs cs clue el desarrollor'á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 paraayuclarnos en la planificación dc nuestro provccto r,'elt la -ucstióu denesgos.

Algunos tlc l,rs cl'rrrrcs nllis sirnilicrrtiros ticncn strs propias \cüe ioncscn otras partes dc este libro. otros no sc tratarán nrírs. Para f'acrlitar laconsulta. la lista sc ha dirrclido emplcanclo las clinlensioncs de la r,eloci-clad de desarrollo: persoitas. proceso. ploducto y tecnología.

Personas

A cclntinuacitin a¡larccen algunos dc los errores cl¿isicos rel¿rcionados conlas pelsonas.

1 : Motivación débil. Estudio tras estudio sc ha rnostrado qr.rc la nrotir ¿r-

cicin probablelrente ticne r.uavor efecto sobre la procluctir idacl y la calidaclque ningún otro fhctor (Boehm. l98l). En el Ejemplo 3.l.los directivostomaron a lo largo de lodo el proyccto mediclas qr.rc nrinaban la r.uoral: conrodar ánirnos a diario al principio para peiiir horas extras en la rrritad. ycomo irsc de'n'acaciones ntientras el equipo estaba trabajanclo incluso losdías de fiesta. para dar rccontpensas al final del proyccto que resnltaronser de nrenos de un clólal por cada hora extra.

2: Personal mediocre. Después dc la rnotivación" la capacidacl in-dir,iclLral cle los micr.ubros clcl eciuipo. así cor"no sus relaciones comoccluipo. probablerrentc tienen la nrayor inf-luencia en la productividad(Boehm^ l9ltl: Lakhanpal. 19c)3). Contratar apurando el fbndo clel barril


:ullondrá unA aurcnaza al esfuerzo dcl clcsarrollo rápiclo. En el ejemplo, la:e'li-'cción dcl pcrsonal se hizo buscando quién podría contratarse más rá-i.rcio" erl vez cle quión rcalizaría la mavoría dcl trabajo durante la vida deljrro)ec1o. Esta técnica consi-gue rrn inicio rápido dcl proyecto. pero nodctcrntina Lrn llnal rápido.

3: Empleados problemáticos incontrolados. Lrn fallo ¿rl trarar con¡.'¡¡5enal problcmático tarnbién an')enaza la r clociclacl cle dcsarrollo. Es unnrobler.na habitual. y sc ha corrprendido bien. al rrenos dcsdc que Geralci\\ cinberg pLrblicó P.s-t't'holog.t'of c'otn¡ttttcr. prtt,4t.urtrnri¡rg en I szl . un fallo¡l tomar una clecisión cuando sc trata con Lrn empleado problemático esLrna cle las cluejas r.r.r¿rs coll"rur.lcs que liencn lcls nricmbros clel equipo respector1e sus responsables (Lalson 1.'LaFasto. lggc)). En el Ejernplo 3. l. el equi-¡rrr sabia clue Chip erii ura lr¿lnzana poclricla, pcro el jefe del equrpo nohizo'acla. El resultado cra predecible: rehacer cl trabajo c'le chip.

4: Hazañas. Algu'ros dcsarrolladores cle sofiu/¿rre pouen un gran énfa-srs en la rcalización dc hazañas en los proyectos (Bach. 1995J. pero lollue hacen tienc m¿is de rlalo quc de bucno. Err el ejemplo. los directivosdc nir el lneclio dieron mavores a¡rlausos a actitudcs clel trpo <ser capaz de>rir-lc a los pfogfcsos flnres y consistcntcs y'a los infbrmes signilicativosric progreso. El resultaclo flc r-rn nrocleltl de pla'ificación al iímite en eliluc las amcnaz¿ls cle dc.sajuste dcl plan no se dctcctaban. ni sc collocran orrr sc iulbllnab¿in a la caclena dc clirectir.os hasta el irltimo minuto. Unpe querio ecluipo dc clcsarrollo v sus jefcs inmediatos toman co¡no relrenesir una courpañía entera por lro adnritir que tiencn problenras para cumplir5u plan. El enfasis !-n los conr¡rortarlicntos hcroicos ibmenta correl.ul.rfiesgo cxlren'ro. e impidc la cooperación entre los mLrltiples elementos quecontribuycn al proce so c'lc dcsarrollo dcl sttfiu,are.

Al-qunos clirectir os lilnentan cl conrporlamiento heroico cuanclo secOnccntran con dcnrasiada firnrcza en actitr.rdcs (ser capaz cle>. E,levandoL'stas actlturies llor encima cle intbrmcs del estado exactos y a veces pesr_rrristas. los clirectivos cic estos provectos coartan su capacidad de tomarnrcdicias colrcctivas. Ni sicluicra sabcn que tre nerr que r-mprendcr acclo-lres correctolas hasra clLrc el daño ¡'a cstá hecho. Couro dijo Torn DeMar_co. ias actitucies (ser cap¿lz clc> conriertcn pequeños contratienlpos enauleir.rticcls ciesastres ( DcN4arco. I 995).

5: Añadir más personal a un proyecto retrasado. Este es quizáscl nrás clásico de Ios errores cl¿rsicos. crr-ranclo uu proyecto se alarga, aña-clir nr¿rs gcr.rtc ¡rr-rcdc quitar n'riis procir-rc-tilidacl a los r.nierrbros del equipoexlstcnte cle la que añaclen los nuevos miembros. Frc<i Brooks colr-pala añadir gente a un proyecto retrasaclo con cchar gasolina en un fuego(Brooks. 1975 ).

REFERENCIACRUZADA

Para más informaciónsobre los efectos del

entorno ps¡cológico enra pruuuLUvruduj

consulte el CapÍtulo 30,. Entornos

Productivos..

REFERENCIACRUZADA

Para más informaciónsobre las relaciones

efectivas con losclientes, consulte el

Capítulo 10,. Desarrollo orientado

al cl¡ente..


REFERENCIACRUZADA

Para más informaciónsobre f ilar

expectat¡vas, consultela Sección 10.3,

"Gestión de lasexpectativas del

Cllenle'.

6: Oficinas repletas y ruidosas. La mayoría de los desarrolladoresconsideran sus condiciones de trabajo como insatisfactorias. Alrededordel 60 por 100 indican que no tienen suficiente silencio ni privacidad (De-Marco y Lister. 1987). Los trabajadores que están en oficinas silencrosasy privadas tienden a funcionar significativamente mejor que aquellos queocupan cubículos en salas ruidosas v repletas. Los entornos repletos yruidosos alargan los planes de desarrollo.

7: Fricciones entre los clientes y los desarrolladores. Las friccio-nes entre los clientes y los desarrolladores pueden presentarse de distintasformas. A los clientes puede parecerles que los desarrolladores no coope-ran cuando rehúsan comprometerse con el plan de desarrollo que deseanlos clientes o cuando fallan al entregar lo prometido. A los desarrollado-res puede parecerles que los clientes no son razonables porque insisten elrplanes irreales o cambios en los requerimientos después de que éstos ha-yan sido fijados. Pueden ser simplemente conflictos de personalidad en-tre dos grupos.

El principal efecto de esta fricción es la mala comunicación, y losefectos secundarios de la mala comunicación incluyen el pobre enten-dimiento de los requerimientos. pobre diseño de la interfaz de usuario y,en el peor caso. el rechazo del cliente a aceptar el producto acabado. En elcaso medio, las fricciones entre clientes y desarrolladores de software lle-gan a ser tan se\¡eras que ambas partes consideran la cancelación del pro-yecto (Jones, 1994). Para remediar estas fricciones se consume tiempo, ydistraen tanto a desarrolladores como a clientes del trabaio real en el pro-yecto.

8: Expectativas poco realistas. Una de las causas rnás comunes defricciones entre los desarrolladores y sus clientes o los directivos son lasexpectatlvas poco realistas. En el Ejemplo 3.1. Bill no tenía razones parapensar que el programa Giga-Quote se podría desarrollar en 6 meses, peroése era el plazo en que lo quería el comité ejecutivo de la compañía. Laincapacidad de Mike de corregir esta expectativa irreal fue la principalfuente de problemas.

E,n otros casos, los directivos o los desarrolladores de un proyecto se

buscan problemas al pedir fondos basándose en estimaciones de planifi-cación demasiado optimistas. A veces prometen un conjunto de funcio-nes tan altas como la Luna.

Aunque por sí mismas las expectativas irreales no alargaran el plan.contribuyen a la percepción de que el plan de desarrollo es demasiadolargo, y de que puede ser malo. Una inspección de Standish Group marcólas expectativas realistas como uno de los cinco factores principales ne-cesarios para asegurar el éxito de los proyectos internos de software degestión (Standish Group. 1994).


9: Falta de un promotor efectivo del proyecto. para soportar mu-;htrs dc los aspectos del desarrollo rápido es necesario un promotor dellrrrvecto de alto nivel. incluyendo una planificación realista, el control de;¡nrbios y la introducción de nuevos métodos 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 clelirrovecto (Thomsett, 1995).

10: Falta de participación de los impricados. Todos los principalesp¿rftrcipantes del esfuerzo de desarrollo de software deben imolicarse enc-i p.oyecto. Incluyendo a los promotores, ejecuti'os. responsables del equi-po. miembros del equipo, personal de ventas, usuarios finales, chentes ycualquiera que se juegue algo con el proyecto. La cooperación estrechascllo se produce si se han i'rplicado todos los participantes. permitiendouna coordinación precisa del esfuerzo para el desarrollo rápido, que esimposible conseguir sin una buena participación.

1 1 : Falta de participación del usuario. La inspección de StandishGroup descubrió que la razón número uno de que los proyectos de Siste-nras de Infonnación tuviesen éxito es la implicación del usuario (StandishGroup, 1994). Los proyectos que no implican al usuario desde el princi-pio corren el riesgo de que no se comprendan los requerimientos del pro-\ecto. y son vulnerables a que se consun-ra tiempo en prestaciones quernás tarde retrasarán el proyecto.

12: Política antes que desarroilo. Larry constanti'e indicó que sihay cuatro equipos hay cuatro tipos difercntes de orientaciones políticas(constantine, 1995a). Los <políticos> están especializados en la <<gestión>,centrándose en las relaciones con sus directivos. Los <investigadores> secentran en explorar y reunir información. Los <aislacionistas> están so-los. creando fronteras para el proyecto que rnantienen cerradas a los queno son miembros del equipo. Los <generalistas> hacen un poco de todo:establecen relaciones con sus clirectivos, realizan investigaciones y ex-ploran actividades, y se coordinan con otros cquipos conlo parte de sumodo de trabajo. constantine indicó que inicialmente los equipos políti-cos y generalistas están bien vistos por los directivos de alto nivel. perodespués de un año y medio, los equipos políticos llegan a la muerte súbi-ta. Primar la politica en vez de los resultados es fatal para el desarrolloorientado a la velocidad.

13: llusiones. Estoy impresionado de ver cuántos problemas del desa-rrollo del software se deben a la ilusión. cuántas veces hemos escuchadocosas como óstas a distintas personas:


REFERENCIACRUZADA

Para más información<^hro l^c ñl.nóc

irreales, consulte laSección 9.1 .

. Planif icaciónexcesivamente

optimista,,.

<Ninguno de los rnicrlbros clel provccto cree re¿illrente que pueda cout-plctafse el prol'ccto rle acr¡crcio con eJ ¡tllrn (lue tir-nclr. pcro picnsan quecluizlis si trabrtjan ciuro. r natla la r-n¿rl. r tienc¡r Lllr poco clc suerte. sc-riin

t.tpitüc) 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 bucnaconrunicilción pafa otras cosas. v las rnterfaces son relati\'¿mente sinrples.

:::J:: ,i-t,rtrlr-nrcritc sólt¡ ncccsitarcnros un día o clos para elinrinar los

<Sabcnros que c()nt¿lnros con Lrn clesan'ollador e\tcnro clc poco talentopara e I subsiste'nra dc'l¿t base- dc thtos. \, c¡lc cs cliflcilvel ctin.ro va a acabarel trabajo con lo. nirelcs de'pcrsonal que lia es¡rccificailo en sLl propLrcsta.

No ticncn tarlta expcricncia couro algunos de los cie-ntás desarrollaclorese\ternns. pero pLretlc cluc contpenser con enerqía lo clue les falta en expe-riencia. [)rob¿rblenrente ucaben ¡ tienll]o.))

<<No ncccsitarnos fel'1.'iar l¡ irltima lista dc canlbios cn cl prototipo paracl cliente. Lstor. scquro cle quc ¡rot'ahOt'¡ sabelnos lo cluc clLliere.))

,,El cquil-ro csth clicicnclo quc rcalizará un estucrzo extr¿rorclin¿rrio I-riu u

cirnrplil con la lecha clc cntrcg¿r. \'clLlc no han llegaclo a su printer hito porpocos clias. pcro creo quc nlcanzarált rlstc u ttetrrpo. "

Las ilusioncs no son sólo optintismo. Re alutente coÍlsistcn clt cerrarlos i¡os )'csllcrar que toclo lirncione cu¿urdo no se tienen las bases razonA-bles para pcnsar qLre serll ¿rsí. Las ilr.rsioncs al comienzo del proyecto lle-van a grandcs cxplosiones al tlnal. Intpiclcn llet'ar a cabo uua planifica-ci(in coh€'rcrite y pueclen ser la raíz de ntás problenras cn el soft$,are quetodas las otras calrs¿rs conrbinaclas.

Proceso

Los errores rclacionaclos con el proccso ralentizan los proyectos porqucmalgastan cl talcnto y el esfucrzo clel personal. A continllación sc ntlles-tran algunos dc los peorcs crrores rel¿rcionados colt el proccso.

14: Planificación excesivamente optimista. Los rctos a los quc sc

eÍlfrenta alguicn qLre dcsarfolla una aplicación en trcs nlcscs son muydil-crentcs de aqucllos a los quc sc eufl'enta algLrien que desarrolla unaaplicación que neccsita un año. Fi.jal Lrn plar"r crcesir antelrtc optinrista pre-dispone a qur- el proyccto f'alle por infravalorar el alcance dcl proyecto,minando la planificacicin cfectiva, y rcduciendo las actir.'idac'lcs criticaspara el ciesarrollo. cono cl análisis de rcqucrimientos o cl discño. Tanl-bién supone una exccsi\/a presión para los desarrolladores. quisl.lss a largoplazo se ven af'ectados cn su nroral y su producti\idtd. Esta t-s la mayurfuente de problcmas clel Ejenrplo 3.1.

Capttulo 3: Errores clasicos 51

15: Gestión de riesgos insuficiente. Algr-rnos crrorcs no son lo sufi-cicntcl.lrcnte habituale s conto para considerarlos clásicos. Son los llamados,,ricsgos>>. Cor.no con los errorcs clásicos. si no e-jercernos una gcstión activadc los ricsgr)s. colr que sólo 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 deno gcstional' uno solo clc cstos riesgc'ls es un crror clásico.

16: Fallos de los contratados. Las corr-rpañías a r,cccs contratan larcalizacion cie pirrtes dc un plor,ccto cuando tienct.l dentasiada prisa parahaccr cl trabqo en c¿1sa. Pcr<t los contrataclos fl'c-cuentementc entregan slllraba¡o t¿rrcle" con uua calid¿rc1 inaceptable cl quc falla al no coincidir conlrr e '¡r¡r'ifie le itlll t Bochlll. lt)x,,1 t. Ric:t()\ e onto rcqucrimicntos inc¡ta-bles cl interf aces nial clcfinicias pueclen scr enorntes cuando un contratadoentra elr escr-na. Si las relaciones con los contratados no se _eestionan cui-dadosamente . la utilización dc desarrolladorcs cxternos nuede ralentizarel Drovecto cn vez dc acelerarlo.

17: Planificación insuficiente. Si no planificamos para conseguir unclesarrollo rápido. r'ro ¡rodcnros espcrar obtcnerlo.

18: Abandono de la planificación bajo presión. Los equipos de desa-rrollo haccn plane s y rulinarian.rentc los abanclonan cuanclo sc tropiezancon Lln problema or la planificación (Humplrrey. 1989). El problcma no cstáen el abandono del plar.r. sino nrás bien en fallar al no crear un plan alter-natlvo. \'cacr elttoltccs en el t.nodo dc trabajo de codiflcar y corregir. Enel Ejcnrplo 3.1. el cquipo abandonó su plan después de fallar en la prirneraentrega. v csto es lo habitual. A ¡rartir cie cste punto. el trabajo no tuvocooldinacitin ni cJcgancia. hasta cl punto de que Jill empezó a trabajarpartc dcl tier.npcl llara Llu llroyecto c1e su liejo grupo y nadic lo supo.

19: Pérdida de tiempo en el inicio difuso. El <inicio difuso> es eltlenrpo quc transcLlfre ¿ln1cs c1e qLrc cor.nicnce el proyecto; estc tiemponormalnlcnte se picrcle en el proceso de aprobar y hacer el presupuesto. Nocs poco cor.n[tn quc ull pro]-ccto dcsperdrcic lreses o años en un inicio difu-so. v cntonces se cstá a las ¡-ruertas de un plan agresivo. Es r.nucho rnás fácil¡r barato y lxenos arries-eado suprirrrir Luras pocas selranas o lneses del iniciodilirso cn vez cie contprir.r.rir el plan de desarrollo en ese misl.l.lo tiempo.

20: Escatimar en las act¡vidades iniciales. Los proyectos que seacelcran intentando ¿lcortar las actii.'idades no escnciales" y puesto que elan¿ilisis dc requerintientos. la arquitcctura ¡r cl discño no produccr.r códigodirectanrcnte. son los candidatos 1áciles. En un proyecto clesastroso en elqLrc participé. pedí que ntc cnseñascn el discño. E1 respclnsable del equiporne dijo: <No hernos te niclo tientpo clc hacer cl cliseño.>

:: - A: -'-^

:':. áS- : : es.

:a on: .:.--e¡le


REFERENCIACRUZADA

Para más informaciónsobre control de

calidad, consulte laSección 4.3, .Bases

del control de calidad".

Los resultados de este error, también conocido como (saltar a lacodificación>, son todos demasiado predecrbles. E,n el ejemplo. un trucode diseño en el informe del gráfico de barras fue sustituido por un trabajode diseño de calidad. Antes de poder entregar el producto, el traba.¡o contruco tuvo que trrarse, y hubo que hacer de todos modos el trabajo bienhecho. Los proyectos que normalmente escatir.nan en sus actividadesiniciales tendrán que hacer ese trabajo en otro momento. con un costede 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 hacerel trabajo correctamente la printera vez. ¿,cómo vamos a encontrar 50 parahacerlo correctamente más tarde'l

21: Diseño inadecuado. un caso especial de escatimar en las acti\ i-dades iniciales es el diseño inadecuado. Proyectos acelerados generan undiseño indeterminado. no asignando suficiente tiempo para él y originan-do un entorno de alta presión que hace difícil la posibilidad de consideraralternativas en el diseño. El énlasis en el diseño está más orientado a laconveniencia que a la calidad, por lo que necesitará r'arios ciclos de dise-ño antes de poder finalizar completamente el sistema.

22: Escatimar en el control de calidad. En los proyecros que se ha-cen con pnsa se suele cortar por lo sano. eliminando las revisiones deldiseño y del código, eliminando la planificación de las pruebas y reali-zando sólo pruebas superficiales. En el ejemplo, las revisiones del diseñoy del código se eliminaron lirnpiamente para conseguir una ganancia con-siderable en el plan. Al final. cuando el proyecto alcanzó su hito de plenafuncionalidad, aún tenía demasiados errores y se retrasó más de 5 meses.Este resultado es típico. Acortar en un día las actividades cle control decalidad al comienzo del proyecto probablemente supondrá de 3 a l0 clíasde actir.'idades finales (Jones, 1994). E,sta rcducción va contra la velo-cidad de desarrollo.

23: Control insuficiente de la directiva. En et ejemplo hay poco con-trol de la directiva para detectar a tiempo los signos de posibles retrasos enel plan, y los pocos controles definidos al comienzo se abandonaron cuandoel proyecto comenzó a tener problemas. Antes de encarrilar un proyecto,en primer lugar debemos ser capaces de decir si va por buen camrno.

24: Convergencia prematura o excesivamente frecuente. Bastanteantes de que se haya programado entregar un producto, hay un impulsopara preparar el producto para la elttrega, mejorar el rendimiento del pro-ducto, imprimir la documentación final, incorporar entradas en el sistemafinal de ayuda, pulir el programa de instalación. eliminar las funciones queno van a estar listas a tiempo y demás. E,n proyectos hechos con prisa,

DATOS REALES

REFERENCIASCRUZADAS

Para más informaciónsobre controles de la

directiva, consulte.Seguimiento.. enla Sección 4.1, y elCapítulo 27, ,¡Hitos

mtntatura..

ffiDATOS REALES

'i:i'rClA:,ZADA

- : l:'c a

Capítulo 3: Errores clás¡cos 53

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

no es posible fbrzar la convergencia del producto cuando sc desea, algunosproyectos de desarrollo rápido intentan forzar la convergencia media do-cena de veces o más antes de que finalrnente se procluzca. Los intentosadicionales de convergencia no benefician al producto. Sólo son una pér-

dida de tiempo y prolongan el plan.

25: Omitir tareas necesarias en la estimación. Si la gente no guaf-da cuidadosamcntc datos dc proycctos antcriores. olrida las tareas ntc-nos r.'isiblcs. pero son tareas que se han de añadir. El esfuerzo ontitidosuelc aumentar el plan de desarrollo en un 20 o 30 por 100 (Van GcnLrch-

ten. l99l).

26: Planificar ponerse al día más adelante. Un tipo de reestinraciónes 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 proyectossimplemente se plantea recuperar el retraso l.nás tardc. pero nunca se hace.

Aprenderemos más del producto confonne lo estarnos construyendo. in-cluyendo más sobre lo que nos llevará construirlo. E,stos conocinrientosnccesitan reflejarse en la reestimación del plan.

Otro tipo de error eu la reestimación se debe a cambios er.r el prociuc-to. Si el producto que estamos construyendo carnbia. la cantidad de tiemponccesaria para construirlo cambiará tarnbién. En el Ejcnplo 3.1, los reque-rimie¡rtos principales cambiaron entre la propuesta original y el conricnzodel proyecto sin la correspondiente reestir.nación del plan o de los recursos.El crecinliento dc Ias nue\as prestaciones sin a.j rrstar cl plarr gal'antizil qucno se alcanzará la f'echa de entrega.

27: Programación a destaio. Algunas organizaciones cr.--cn quc Ia co-diflcación rápida, libre. tal corro salga. cs cl camino hacia el desarrollorápido. Piensan que si los desarrolladores están lo suflcientcmcntr- moti-vados, pueden solr,entar cualquicr obstáculo. Dcbido a las razoncs que se

verán 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 sólo la envoltura dcl l'ie-joparadigrra a destajo combinado con Llna planificación anrbiciosa. y esta

combinación raras veccs funciona. Es un ejemplo de que dos negaciortc-s

r.rcl constituyen una verdad.

ProductoA continuación se n-ruestran los errores clásicos relacionados con la fbr-ma eu la que se define el producto.


REFERENCIACRUZADA

Para más informaciónsobre el camtlio de

prestaciones, consulteel Capítulo 14,

"Control del conjunto.ló nraelr.i^nac-

REFERENCIACBUZADA

Para consultarun ejemplo sobre

cómo, inclusoaccidentalmente, un

desarrollador puedecaer en requerimientosexcesivos o superf luos,véase ,,Objetivos poco

claros o imposibles",en la Sección 14.2.

28: Exceso de requerimientos. Algunos proyectos tienen lnás reqLle-

rimientos cle los que necesitan. desde el misrno inicio. La eficiencia se

fija como requisito más a menuclo de lo qtle cs necesario. y pucde generar

una planificación del softu'are innecesariamente larga. Los usuarios tien-

cien a interesarse menos en las prestacioncs con-rplcjas que en las de las

secciones de marketing o de desarrollo. ¡r las prestaciones cornplejas alar-

gan desproporcionadantente el plan de desarrollo.

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 (Jo-

nes. 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 rápido.

30: Desarrolladores meticulosos. Los desarrolladorcs encuentran

fascinante 1a nuel'a tccnologia, y a veces e stán ansiosos por probar nuevas

prestaciones de su lcnguaje o cntorno. o por crear su propia implemcnta-

ción de una utilidad bonita que han visto en otro producto, la ncce-

sitc o no su producto. E,l esfuerzo requerido para diseñar. irnplementar.

probar, documentar o mantener cstas prestaciones itlnccesarias alarga

el plan.

31: Tiras y af loias en la negociación. Cuando un directivo aprueba

un retraso en el plan de un proyecto quc progresa más lento de 1o cspera-

do, y entonces añade tareas completamente nuevas despLrés de un cambio

en el plan. se produce una situación curiosa. La ra¿ón Subyacente de esto

cs difícil de localizar, puesto que el directivo que aprlteba el retraso en el

plan 1o hace sabiendo implícitarnente quc el plan estaba equivocado. Pero

una vez que Se corrige. la misma persona realiza acciones cxplícitas para

volver a cquivocarse. E,sto sólo pucde ir en contra del plan.

32: Desarrollo orientado a la investigación. Seymour Cray. el di-

señador de los supercomputadores Cray. dijo quc no intentaba sobrepasar

los límites de la ingcrriería cn más de dos áreas a la vez. porque el riesgo de

un f-allo es demasiado alto (Gilb, 19S8). Muchos proyectos software debe-

rían aprender la lección de Cray. Si el proyccto fuerza los límites de la

informática porqLle necesita la creación de nuevos algoritmos o de nuevas

técnicas de contputación. no estamos desarrollando softrvare; estamos

inr,'estigando en software. Los planes de desarrollo de softrvare son razona-

blernente preclecibles: 1os planes en la inr.'estigación sobre software nr

siquicra son predecibles teóricamcnte.Si cl producto tiene objctivos que pretenden aumentar los conocirnicntos

-:-:-= \urA

: = JZADA: : -'--'Tación: : -:-3me de

_-_: f trl

-:-r-f \u1A:: -ZADA

-:i - -'-aclon

:: : -:: ,Sando

--:.ora de: : - -:: '., dad.

. : :::Jcclon

: -:.-::'15.4.

:::=l:NCIA, I JZADA

-' i: ---'laclon

::, ZaClOn,,.

Capítulo 3: Errores clastcos 55

existentes. como algoritrnos. velocidad, utilizació¡ dc la metnoria y dc-

rnás. debemos asumir que la planificación es altamente especulativa. Si

queremos mejorar el estado dcl arte y tenemos algún otro punto débil 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, hagámoslo. ¡Pcro no debemos esperar hacerlo

rápidamente I

Tecnología

L,l resto c1e los erlores clásicos estáll relacionados con el uso correcto o

incorrecto de la tecnología moderna.

33: síndrome de la panacea. En cl eje¡rplo. se co¡fió demasiado

en las I'cntajas proclamaclas de tecnologías que no se habian usado antes

(gencradores de informes. diseño orientado a objetos y C++) y demasiada

poca inlormación sobre 1o buenas que serían en cste entorno de desarrollo

concreto. Cuando el equipo cicl proyccto sc aftrra sólo a una nueva téc-

nica. uua nueva tecnología o un proceso rigido. y espera resolver con

ello sus problemas cle planificación. está ineyitablemente equivocado (Jo-

nes.1994).

34: sobreestimación de las ventaias del empleo de nuevas herra-

mientas O métOdOS. Las organizaciones r¡ejoran raranente su produc-

rir itiad a grandes saltos. sin inrportar cuátltas nuevls het'ralllicntas o lne-

toclos ernpleen o lo buenos que sean. Los beneficios de las nuevas técnicas

son parcialmente desplazados por las curvas de aprendizaje que llevan

asociadas. y aprerrdcr a utilizar nuevas técnicas para aprovecharlas al

márimo lleva su tiempo. Las nucvas técnicas también suponcn nucvos

riesgos. que sólo descubriremos usándolas. Más bien experirnentaremos

rncjoras lentas y continuas cn un pequeño porcentaje por proyccto en lu-

gar dc grandes saltos. El equipo del Ejemplo 3.1 debería haber previsto

óomo mucho un l0 por 100 de ganancia en productividad por la utiliza-

ción de las nuevas lecnologias en vez de asumir que cstarían cerca de

duplicar su productividad.Un caso especial de sobreestimaciones de las nrejorls se producc cuan-

do se reutiliza código c1e proyectos anteriores. Este tipo de reutilización

puedc ser una tócnica 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


REFEFENCIACRUZADA

Para más informaciónsobre el control

del código fuente,consulte .Gestión de

L^ ^^^í^,,.^^iÁ^iq uu,,,r9ur4u,w,l

del software., en laSección 4.2.

incrementalmente dentro cle la misma línea de productos, de la versión 3a la 3.1, o incluso a la ¿1. Pero cuando estamos a la mitad de un proyecto, lacurva de aprendizajc. rehacer el trabajo y los inevitables errores cometi-dos con nna herramienta totahrente nueva. normalmente anulan cualquierposible bencficio.

36: Falta de control automático del código fuente. Un fallo en lautilización clel control autonlático del código fuente expone a los proycctosa riesgos innecesarios. Sin é1. si dos desarrolladores están trabajando en lar.lrisma parte del programa. deben coordinar su trabajo manualurente. De-berian ponerse de acuerdo para poner la última versión de cada archivoen el directorio maestro y verificarlos con los demás antes de copiarlas en

este directorio. Pero invariablemente alguno sobreescribirá el trabajo delotro. Se desarrolla nuel'o código con intcrfaccs dcsfasadas. y después se

tiene que rediseñar el código al descubrir que se ha utilizado una versióneqr.ril'ocada de la interfaz. Los usnarios avisan de errores que no podemosreproducir porque no hay forma de volver a crear los elementos que han

utilizado. Cclr.no media. los cambios en el código fuente suelen ser de un l0por 100 al mes. y con un control manual dcl código fuente no deberíancrecer (.lones, 1994).

La Tabla 3.1. de la página siguientc. conticnc una lista completa de

lcls errorcs clásicos.

3.4. La fuga de La isla de Gilligan

Una lista completa de los errores clásicos ocuparía muchas más páginas,pero los que se indican son los más cornunes y los más serios. Como indicóDavicl Urr-rpress, de la Univcrsidad dc Scattle, la vigilancia que la mayoríade las organizaciones realiza para evitar estos errores es como ver una yotra vez Lu islct cle Gílligan. Al principio de cada episodio, Gilligan. el

Capitán o el Profesor llegaban con un plan tonto para salir de la isla. El planparecía funcionar inicialmente. pero, corro revelaba el episodio, algo ibamal. y al final del episodio los náufragos volvían donde habían empeza-do. perdidos en la isla.

De igual forma, la r.nayoría de las compañías descubrc al final de cada

proyecto que han cornetido otro error clásico y que han entregado otroproyecto luera de plazo. con mayor coste, o ambas cosas.

Su propia lista de malos hábitosDebe ser cuidadoso con los errores clásicos. Puede crear listas de <maloshábitos> para evitarlos en futuros proyectos. Comience por la lista que apa-


. -:-l',: Errores relacionados Errores relacionados Errores rclacionados,.. . con el proceso con el producto con la tecnología

.I Planificación 28. Exceso de ji Síndrome de la. ,,_ e-rcesivamente requerilxientos panacea

optirnis¡a 29. Cambio de las -l¿1. Sobreestimación15. Gestión de riesgos prcstaciones de las ,,,entajas del

. insuflciente 30. Desarrollaclorcs ernpleo de nuc,u,as

lb. Fallos de los rneticulososcontrat¿idos i l. Tiras y aflojas en I.nétodos

11. Planiflcación la negociación 35. Cambiar de

.. -. insul-icie nte 32. Desarrollo herrarnientas a

-:. lE. Abanclono clc la orientaclo a la mitacl del proyecto

planificación bajo invcstisación j6. Falta cle control

herramientas cr

automático delcódigo fuente

. -' :-- Preslon

. 19. Pérdida de tiernpo

. ,\ en el inicio difuso

- r. -,.f) 10. Escatimar cn lasactir, idadesiniciales

. __ \., II. Diseñoinadecuatlo

22. Escatimar cn el

, control de calidad

i. Jc- 23. Control- , .:..1': insuflciente de la

. directrva

. .lcl 2.1. Conr ergenciaprematura o

. . .\ r r r. ercesir alilenlet-' frecuenre

:. 25. Omitir tareasneccsarias en laestimación

26. Planificar ponerseal día rnás adelante

27. Prograntación a

destaj o

rece en este capítulo. Vaya incrementando la lista según se vayan acabancloproyectos para aprender de los errores cometidos por su equipo. E,stimuleesie comportamlento para otros proyectos dentro de la cmpresa, para


aprcnder dc stts errores. Intercanbie cxpcriencias con los colegas de otrasorgrrlizacioncs y aprenda de su cxpcrienciii. Exhiba en lugai r.'isible lalista de errores. y asi la gente la vcrá y aprcr.rdcrii sin cometer cle nuevo losInlsnt()S eI.l'OfCS.

Bibl iografía adicional

Aunque algunos libros tratan sobre errores dc código, no conozco librosquc describan los errorcs clásicos relacionacios con los planes de desarrollo.En cl resto de este libro se incluycn referencias sobre temas relacionados.

Bases del desarrollode software

Contenido

-1.1. Bases de gestión4.2. Bascs técnicas4.3. Bascs del control de calidad1.4. Seguir las insrrucciones

Temas relacionados

Estrategia para el desarrollo rápido: Capítulo 2

Resumen de inspecciones: Capítulo 23

RED AUERBACH. EL ENTRENADoR QUE MAS TIEMPo DURÓ conlos Boston Celtics. y lrasta hace poco. el que más veces ganó cn la histo-ria del baloncesto profesional. lanzó un video titulado <Rcd on Round-ball>. Auerbach nantiene el hecho de que los conocin.tientos básicos sonel punto clave para tener éxito clentro del baloncesto prof'esional. Indicaquc dc al rnenos 20 pascs de los que se realicen. sólo van a tener éxitoaquellos en los que htn'o ulguien que cojct el halón. La clal'e del érito enel rebote radica en coqer el balón. Tencr una buena base fuc la estratc-giaquc Auerbach siguió para ganar ocho l'cccs seguidas los carnpeonatos dcla NBA.

Para obtener érito en el software hay que prestar la urayor atenciónposible a los fundamentos. Podría ser el Bob Cousy, Kareem Abdul Jab-bar o Michael .lordan de su organizacirin softu,are. Podría disponer deuna serie dc métodos orientados a la planificación. Pero si no utiliza losconceptos básicos dc desarrollo corno el punto ntás importante del esfuer-zo de desarrollo. sc arriesgará a no alcanzar las r.nclas dc planificaciónque se l.ra propuesto.

59


Tottos deseun <'sturen ttrt aclttipo

cttrrtpeón, p(r0 nud¡edescu reLt/i:ur el

e.t.f irer:o pa rullet'ut'lt¡ u lu

prtit f itu.Bobb¡' Knirht

No'ralmente las personas suelen decirre que use buenos nétodos deingeniería del software porque están <bien>) o porque contribuirá a au-mentar la calidad. Srrs consejos parecen tcner connotaciones religiosas.Pero no piense cn esto como una cuestión dc fe. Si las técnicas fLrncronan.utilícelas. Si no funcionan. ino lo hagal Mi opinión es qllc se deberíanutilizar los métodos fundamentales de ingeniería del software descritosen este capítulo, no porquc estén <bien>>. sino porque r.educen el coste yel tiempo de cornercialización.

Esta postura es menos teórica de lo que se podrían imaginar. En ur.lanálisis de l0 proyectos software. que las organizaciones seleccionaroncomo <los mejores proyectos)). Bill Hetzel lle-eó a la conclusión dc que<si había que birscar una conclusión que destacara por encima de las de-más, se podía decir que los r.nejores proyectos lo eran porque se basabancn los fundamentos. Todos conocemos los fundamentos para un buen soft-ware; la diferencia está en que la mayoría de los proyectos no lo hacenbien, y entonces tienen problemas> (Hetzel, 1993).

El mejor lugar para comenzar a buscar información sobre los funcia-mentos del desarrollo del software es un libro de texto de ingeniería delsoftware en general. Este libro no es un libro dc texto cle ingenieria del sofl-ware. de forn-ra que este capítulo se limita a identificar los funclamentosdel desarrollo. explicar cómo afectan a la planificación clel desarrollo.cuantificar el impacto de su efecto (si es posible). y proporcionar inciica-ciones para poder obtener más información.

En este capítulo, los métodos se dividen en métodos de gestión, técni-cos y de control de calidad. Algunos dc los métodos no se encuadran dcn-tro de u'a categoría, de fbrma que podria hojear todas las catcgorías aun-que esté r.nás interesado en una en particular. pero primero sería conr,,cnientever el Ejemplo 4.1 para situarse dentro del cclnrexro.

Ejemplo 4.1. Falta de fundamentos de desarrollo

<<Nosotros pensábamos que estábarnos seguros de lo que estábamos hacien-do>, dijo Bill a charles. <La versión 3 de nuestro programa de primas deventas, PPV, que utilizamos para pagar las comisiones a los agentes, nossalió bastante bien. Pero con la versión 4 todo cambió.) Bill había sido eljefe de las versiones de la I hasta la 4, y charles era un consejero técnicollamado por Giga-Safe para que les ayudara a comprobar por qué ra ver-sión 4 había sido tan problemática.

<¿Cuáles fueron las diferencias entre la versión 3 y la 4?>, preguntóCharles.

<Tuvimos problemas con las versiones I y Z>, respondió Bill, <perocon la versión 3, creíamos que nuestros problemas habían quedado atrás.

| (otrtulLtul

Sedesarroliósinapenasproblemas'Nuestraestimaciónfueprecisa'enpar¡e

;;to* ;;;"dimos a "ñ;;;"; *utgtn de seguridad de un 30 por 100' Los

desarrolladores casl no tuvieron problemas co¡ las tareas' herramientas o

elementos de diseño que se les oividaban' Todo fue fenomenal>'

<<Entonces, ¿qué ocurrió con la versión 4?>' apuntó Charles' ..<Fue algo totalmente diferente' La versión 3 erauna actualizaciÓn evo-

l"ti;;;;;;i" versión 4 era un producto completamente nuevo' que se tuvo

que desarrollar desde el principio' ^^.^^^i'-ióñr^" q,nr

Los miembro* a"t "{ttifo'intentaron

aplicar 1os conocimientos adqut-

ridos en las versiones r at I ¿"t PPV' Pero en una parte del proyecto' la

pü"1t.".i0" comenzó u li't'ut' Las tareas tócnicas resultaron ser más com-

plicadas de lo que ,. "tpttubu'

Tareas.que^los.desarrolladores habían estt-

"*"¿" o"t p"¿riun tur¿ui z ¿lu' '"q""tíun

2 o,3 semanas Había problemas

con algunas nuevas lt"rrÁie"tat de desarrollo' y el equipo perdió la bata-

lla con ellas. Los nuevos miembros del equipo no conocían todas las reglas

del mismo, y desaprovecharon trabajo y tiempo' porque sobreescribían en-

tre ellos sus archivos ¿",iuuu¡o. Al final, naáie podía predecir cuándo es-

taría listo el producto, hasta el momento en que realmente 1o estuvo' La

versión 4 tuvo un retraso de un 100 por 100'> - L^Lr^ +^ '

<<Eso suena bastante mal>' ug'"g'ó Charles' <Mencionó que habia tent-

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

proyectos?><Por supuesto), contestó Bill' <En la I'ersión 1 del PPV' el proyecto

fue un completo caos. Se hizo una estimación del proyecto t"ryl:t^".,y t"

piunifi.u.iAn de las tareas parecía casi aleatoria' Los problemas técntcos

resultaron ,", -uyo.",-át fo qut se esperaba'.Las herramientas de desarro-

1lo que se suponía qut it'un u uho"ut tiempo incrementaron el tiempo de la

planificación.Elequipodedesarrollosufriaunretrasotrasotloenlaplani-ficación'yningunosabíacuándoelproductoestaríarealmentepreparado,hasta uno o dos dias unit" ¿t que realmente lo estuvo' Al final' el equipo

det PPV entregó .i pt;;t;;; t* un I 00 por 100 de retraso sobre la plani-

ficación inicial.><Esto es muy similar a lo que sucedió con la versión 4>' dijo Charles'

<Escierto>,Billsacudiólacabeza.<Penséquehabíamosaprendidolalección hace mucho tiemPo 't

<¿Qué sucedió con la versién 2?>' preguntó Charles'

<En la versión z, a Jttu*ollo procedió de una forma tnás regular que

en la versión 1. La estimación del proyecto y la pianificattó:1: las^ta¡eas

p"t*i.""t más realistas, y el trabajo técnico nareció gstar mas ba1o con-

troi. Hubo ,r."no, p.oii"*ut ton las herramientas de desarrollo y el trabajo

del equipo de desarrolio llevó el tiempo que se había estimado' Cometie-

,on .iror., en la estimación, poniendo tiemgo de más'

Pero cuando ,. lü u""undo el final del proyecto' el equipodescSbrió

que en la estimación "tigit"f no h¿bían incluiáo muchas de las tareas' Tam-

bién descubrieron talloi en el diseño' 1o cual significó que tendrían que

Capítulo 4: Bases del desarrollo de software 61

(t on t intiu)


volver a revisar del l0 al l5 pol l0c) del sistema. Tení¿r un gran retraso enla planificación, donde tenian que incluir las tareas olvidaclas y la revisión.Terminaron el trabajo. encontrando unos cuantos problemas más, sufrieronotro retraso. v finalrnente entregaron el producto un 30 por 100 ta¡cle. Eneste momento aprendirros a añadir un 30 por' 100 de margen de seguridada las planificaciones.>

<Y entonces, ¿la versión 3 fue bien?>. prcgi.rntó Charles.<Desde luego>. agregó Bill.<Según he entendido.,,se utilizó el misnro código 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 1

a la 3'l><Sí, pero muchos se rnarcharon al terntinar la versión j. de forma que

la mayoria del equipo de la'ersión 4 no había trabajado cn el proyectoanteriornlente. )

<Cracias>, dijo Charles. <Ha sido de gran ayuda.>Charles pasó el resto del día hablando con el equipo de <lesarrollo, y

por la noche se encontró de nuevo con Bill. <Lo que tengo que decirlepuede que no sea fácil para usted>, dijo charles. <como consejero técnico,he visto docenas de proyectos en un año, y en toda mi profesión he vistocientos de proyectos en más de cien organizaciones. El proceso seguidopor las versiones de la I a la 4 del ppV es bastante común.

Anteriormente, me dio a entender que los clesarroiladores no controlaronel código fuente de forma automática, y esta tarde lo confirmé hablandocon ellos. También confirmé que el equipo de desarrollo no realizaba re-visiones del código o del diseño. La organización confia más en la estima-ción que se hace a ojo, aunque se tengan disponibles métodos de estimaciónmás fiables.>

<De acuerdo>>, dijo Bill. <Todo eso es cierto. pero, ¿qué tenemos quehacer para que no nos ocurra lo mismo con otlos proyectos como con laversión 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 desarrollodel software o se encontrará con lo mismo una y otra vez. Necesita con-solidar los tundamentos. En la parle de gestión, se necesita una mayor efec-tividad en la programació', planificación, seguimiento y meclidas. En laparte técnica, necesita más efectividad en la gestión de requisitos, diseño,construcción y configuración. Y aderr-rás necesita un mayor control de ca-lidad.>

<Pero la versión 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, conmiembros de un equipo con el que habían esta<io trabajando antes en elmismo producto. La mayoría del eqr"ripo de la versión 3 había trabajado en

l ( onÍurttd )

Capítulo 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 estim¿r-

. ' t'.-tnitlcación de un producto en particular. piensan que lo hacen- . :i piensan que alguien lo puede hacer mejor..r:' . >1r ca¡tacrdad de dc-sarrollo se construye sobre una base frágil.

: !'..ir]r!'frte sólo saben córno desarrollar un producto en particular*. .---: :,rill]a específica. Cuando se enfrentan con cambios importantes en: -:r'i,,lt.ll. en las herramientas o elttorno de desar.rollo, o en e1 concepto,- :.:,-.it¡ctit" la capacidad de desa¡rollo 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 versión I y la 4 fueran muy

f ., Ir"¡ia pensaclo en eso antes. pero probablemente lleve razón>, ilijo:: ::..:nquilamentc. (En mi opinión, 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 vendrán abajo>, d¡o-,:i::. ,rr éstos son a los que realmente l.ray que prestar atención>.

-:<: s de gestión

- - . ,incl¡rrlrentos clc gestión tierrcn al rrenos tanta influencia corno los--r'!o: r-'n la planil-icación de desarrollos. El Instituto de Ingeniería del' -..',.lfc h¿r obscn'ado repeticlanrcnte clue las organizaciones que intr.u-:- ::rpl¡111¿¡ la disciplina de la ingeniería dcl sofiu,are antes que la cle

-;r..rrn dc ¡rrovcctcls estárr abocadas al fl"ac¿rso (Burlton. 1992). La ges-r-. nrr'm¿llnrenlc controla las tres magnitudes dcl triángulo cle equilibrio

,.-,.rCLr lplanrficación. coste y prodLrcto), aunqLre algunas veces el depar--::r.'1rto dL- marl(eting controla Ia cspecificación del producto, y a veces- !11'partamento de dcsarrollo controla la planilicación (normalmente. cl,.:).rrrollo sicr.npre controla la planificación real: y a vsces también con-.:.,,i¡ la planificación progfantaci¿r).

Los liurdar.nentos de gestión consisten en cleterminar el tamaño clei.':'orllicto (incluyenclo funcionaliclad, conplejictad y otras características.r-') prociucto). asignando los recursos apropiados a ur.r producto dc esc.¡nraño" crcando un plan para aplicar csos recursos y luego controlanrlo y.irligiendo los recursos para impedir que el proyccto sc desr,,íe. En algu-iros casos. los altos cargos clclegan explicitamente estas tareas de gestión.r los respor.rs¿rbles técnictrs. y en r)tros casos simplcmente lo dcjan vacan-te . ocupárrdolo un rcsponsable o desarrollador rnotivado.


BEFERENCIASCRUZADAS

Para obtener másinformación sobre la

estimación, véaseel CapÍtulo 8,

"Estimación.. Paraobtener más

información sobre laplanificación. véase

el Capítulo 9.. Planif icación..

Estimación y plan¡ficación

Los proyectos bien ejecutados pasan por tres etapas básicas para crear unaplanificación software. Primero se estima er tamaño der producto, luego seestima el esfuerzo necesario para constrllir un producto con ese tamaño ypor último se realiza una planificacrón, basándose en la estimación del es-fuerzo.

La planificación y estimación son las bases crel desarrollo porque unaestimación incorrecta reduce la eficiencia en el desarrollo. Una estimacióncorrecta es una condición necesaria para una planificación efectrva. queadernás es esencial para un dcsarrollo eficicnte.

Planif icacióncomo Philip w. Metzger señaló en su clásico Managing a programrtringProject (Gestión de un Proyecto de programación), la mala planificaciónse manifiesta como luente de problemas más a menudo que cualquier otracausa (Metzger, l98l). A continuación se enumera la lista de problemasque aparecen en el desarrollo software que él propone:

¡ Mala planificación.o Contrato mal definido.¡ Mala planificación.¡ Definición del problema inesrable.¡ Mala planificación.¡ Falta de experiencia en la gestión.¡ Mala planificación.o Presión política.o Mala planificación.o Control de cambios poco efectivo.. Mala planificación.o Plazos poco realistas.o Mala planificación.

En la revisión qr.re hizo de los mejores proyectos, Bill Hetzel en-corrtró quc los mejores proyectos de la industria se caracterizabanpor unafuerte planificación anticipada para definir las tareas y programaciones(Hetzel, 1993). La planificación de un proyecto sofru'are incruye las acti-r''idades siguientes:

o Estimación y planificación.

' Determinar el nirmero de personas que deben participar en el equi-po del proyecto, qué habilidades técnicas son necesarias. cuándoaumentar el número de personas y quién participará.

. Decidir cómo organizar el equipo.

REFERENCIASCRUZADAS

Para más informaclónsobre estos temas.

véanse el Capítulo 12,

" Equipo de trabajo";el Capítulo 13,

"Estructura de{equtpo'; el Capítulo 7,

"Planif icación del ciclode vida", ei CapÍtulo 5.

,,Gestión de riesgos".y el Capítulo 14,

,, Control del conluntode prestaciones,,.

ERROF CLASICO

Capítulo 4: Bases del desarrollo de software

. Elegir el modelo de ciclo de vida que se va a utilizar.o Gestión de riesgos.. Tomar decisiones estratégicas, tales como controlar el conjunto de

prestaciones del producto y decidtr si hay que comprar o crear al-gunas partes del producto.

SeguimientoUna vez que se haya planificado el proyecto, hay que seguir el proceso dedesarrollo para comprobar que se está cumpliendo el plan previsto: quesatisface sus objetivos de planificación, coste y calidad. Normalntente elcontrol de seguimiento en el nivel de gestión incluye listas de tareas.reuniones e informes sobre el cstado, revisiones de hitos, informes de pre-supuestos y demás gcstiones. El control de seguimiento en el nivel técni-co normah.l.lente incluye las intervenciones y rer,isiones técnicas y las en-tradas de calidad, que controlan si los hitos se consideran terminados.

Bill Hetzel descubrió que en todos <los mejores proyectos) era c',i-dente la realización de una cstricta medición y seguimiento del estado delproyecto. La medición del estado para mantener la gestión del proyectoaparece como un subproducto natural de ur.r buen trabajo de planifica-ción, ¡' cs un lactor clave de éxito (Hetzel, i993).

Como sugiere la Figura 4.1, en un proyecto típico la gesrión del pro-yecto es casi una función de caja negra. Dificilmente se conoce lo que seva a hacer durante el proyecto, y sólo hay que quedarse con el resultadofinal. En un proyecto ideal, en todo momento se tiene el 100 por 100 devisibilidad. E,n un proyccto eficiente, sier.npre se ticne al menos un pocode visibilidad, siendo más normal el tener una buena visibilidad oue notener nlnguna.

Inicio

65

Visibilidad de unproyecto ideal

Visibilidad de unproyecto eficiente

Visibilidad de unproyecto con elmodelo de ciclo

n |l h ¡r,j i.r \

Prnnrocndel proyecto

de vida en cascadabien desarrollado

Visibilidad de unproyecto tip¡co

Figura 4.1. La visibilidad del progreso cambia según la clase deproyecto. El desarrollo eficiente ofrece más visibilidad que el desarrollotípico.


DATOS REALES

capcrs.lones iufbnna que <el control cle un proccs.r softuarc es tannlalo quc t.nuchos dcsastres softu'arc bastantc conociclos no se conoclerolrhasta el nrisnro clía del despliegue cspcraclo> (Jones. l995Lr). DcspLrósde cvaluar 59 nruestras cr,trc 1987 ¡, 1993. cl Instituto de lngeniería dclSoflivare dedLrjo que el 75 pol 100 rrecesitaban rrrcjorar-la supcr.r,.isión yel scguinticnto del ¡rrovccto (Kitson l,Mastcrs. 1993). Cuanclo las ttr.gani_zaciones han sitlo ¿rsesoraclas. han intentando nrcjorar v han'r,uelto a so-Iicitar el'aluacicin. se ha visto que los principales problernas aparecenen las áreas clc planificacitin. seguimicnto v supervisión cicl proyecto(Baumert. I995 ).

El seguirniento cs una acti'iclad lund¿rmental cn el proceso de ln pla-nilicación softriare. Si no sc puccle seur-rir un llroyecto. uo sc pueclc ges-tionar. No hay fbrnra cic sabcr si e'l plan se cstii llevanclo ¿r cabo ni lo qucse debería haccr clcspr.rés. No hay Íbrrna dc controlar los rics,{os en elproyecto. un sc-euimiento cfectiio perrnite cletcctar-rápiclamc-nte los pro-blcmas dc planificación. cuanc'lo aúrn quccla tierrpo para pocler resol-verlos. El clcsarrollo rirpiclo no se puecic llc'ar a cabo si no se sigue clproyect0.

Medidas

una de las formas de progresar cn una ore¿rnizacicin soli*are. a largo pla-zo' es recoger datos trtétricos para analizar la caliclad v prodLrctir.iclacl dclsoftlvare. Prácticar.ncnte todos los proyectos recogen clatos sobre los cos-tes 1, la planificación. Pcro cstos datos son rimitaclos y no avuclan muchoa reducir los costes o a clisntinuir la planificación.

Recogcr rnás datos pr-redc suponcr n.lucho tiempo. Si aclemás clc datosde coste v planificación se obticnen datos históricos" corno el t¿rr¡año dclos progran.ras en líneas cle código. o cualcluier otra meclida" se tcr.rcirán lasbascs para la planificación de proyectos tirrr.rros. cFre srcmpre es nrcjorque cl instinto. cuando eljef'e cliga: <¿,podóis dcsarrollar estc proclucto ennucve nlcscs'.'r>. podremos dccir: (Nuestfa organizaciórl nunca ha clesa-rrollado un producto de ese tamaño 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 unosconocir.uientos básicos sobrc las rnediclas o r.r.lcltricas ciel softu,are. Se ncce-sita conocer los ter-nas a los que af'ecta la recogicia de mecliclas. incluyencloqué cantidad o cuánto tie'nrpo se necc-srta para recogcrlos 1.,ctirno hacerlo. Sedeberían tener conocimientos sobre métricas cspeciticas 1, utilizarlos paraanalizar el estado. la calidacl y la prodr-rctil'idacl. una organizacitin qiredesee implantar el clesarrollo rápido neccsita recoger las meciidas básicas¡rara sabel cuál es la r.elocidacl dc desarrollo v si es meior o Dcor a medicl¿qLlc transcul'rc el tiet.npo.

REFERENCIACRUZADA

Para obtener más¡nformaclón sobre las

medidas. véase elCapítuto 26.,,Medidas,,.


Bibliografía adicional sobre las bases de gestión

Los cr-ratro ¡rrimclos voliurenes listaclos a continuación tratan sobre te-nras nruy gcncralcs c1c soit'ui'are. incluyendo telras pragmáticos. corxo pore.jemplo quó hacer cou un miembro problemático del equipo: cuestionesteóricas. corlo pucdc scr cónro modelizar un proyccto softu'arc corno urlsistcma. y tclras csotóricos" como puede ser la importancia que tiene laobscrvacicin para cl cles¿rn'ollo clel softu'are. Los liblos de Weinberg son

entretcnidos y llenos clc ideas.

\\'einberg, Gerald N[.: Quulin' Sofitrure ,lluttugentent, t't¡1. l/ririg. Neu'York: Dorsct House, 1992.

\\'cinberg. Gerald M.: Quulitr So/iwure Iluttugerttettt, rol.:\Ieusttretttan l. Nc\\' York: Dorset Hcluse. 1993.

\\'cinberg" Gerald M.: QuuIit.t Sttfi:r.ut'e ,11unugetrtettt, t'oI.1r'tiou. Ner.r York: Dorsct llousc. 199.1.

SrsÍen1s Thín-

2: I'-it'st-Orcler

3: C'cntgruent

\\'einbcrg. Gerald M.'. Ottulit.t' Sofitut'c .\lunagetuettt, vol. 4: .,lntic'ipLttittgChunge, 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 vi-sión ger.reral sobre la gestión clc un prclyccto soft."r,are. Ir-rcluye unaintroducción sobre la estlnlación. análisis de ries-eos. planificación

.v scguimiento. así cor.no el elcrncnto hur.nano. El iurico inconrenien-te es clue utiliza un fblmato a base de prcguntas y respuestas. locual poclría 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 Cu¡tuhi-lit.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 entor-no a nivei clc gcsticin apto para la cornprensión, gcstión y mejora dclclesarrol lo clcl sollu'¿rre.

Tha¡,'er. Richalcl II.. cd.: Ttttot'ial: St¡fivure Ettgineerittg Projecf Manu-getneltt. L-os .Alanlitos. C'alif.: IEEE ('omputer Socict¡, Prcss. 1990.Es urra colcccirin de .15 artículos sobrc tcr.nas de gcstión dc proycctossolju'arc. Los artícr.rlos son algunos de los me'jorcs esludios disponi-blcs sobrc tcrras de planil'icación. organización. contratación dL. per-sorral. dirccción y control de un proyecto softr,r,arc. Thaycr hacc unabreve intrcldr-rcción y una serie cle correntarios sobre estos temas en

cada uno dc los altículos.Gilb. Tom: Prirtt'iple.s ol So.fiu'ure Engineering Xlunugetnent. Woking-

ham, Englirnd: Adtlison-\\¡eslcy. 1988. La tesis que Gilb mantiene es

ciue los directores de los llroycctos generahrrente no desean preclecirlo clue sucederá con sus proycctos: prefiercn controlarlo. Gilb se cen-tra cn cl clcsarrollo de los r.nétodos que contribuyen al control de la


planificacióndelsoftrvare.ymuchosdelosmétodosqueseincluyenenestelibroestáncatalogadoscomométodosrecomendables.

DeMarco.Tot:n,.Contl.tlllíngSofiv,areProjects'NewYork:YourdonPress,lgs2.EllibrodeDeMarconopareceenabsolutoanticuado'Trataenlg82conlosmtsmosproblernasconlosquenosenfrentamoshoy:directivosqueloquierentodoyclientesquedeseantodoalmomento.PresentaestrategiaSdegestióndeproyectos,prestandoespecialaten-ción a las mediciones'

Metzger.PhilipW...MttnagingctProgrammingProjec,t,2dECl.E,ng]e-wcloclCliff.s.N.J.:PrenticeHall.lg8l.Esunlibrodetextoclásicoque hace una introducción a 1a gestión de proyectos' Está bastante

desf.asaclo.yaqueprestaespecialatenciónalmodelodeciclodevida.n .arcudu y a méiodos de rlesarrollo dirigidos por documentos..Pero

alguienqu.l.oellibroconintencióndesercríticoencontraráqueMetzgeraúntienecosasimportantesquedecirsobrelosproyectosdehoy. y además lo dice bastante bien'

Aunque el libro siguiente no trate específicamente sobre proyectos

sofilvare, puecle ser dc interés comentarlo'

Grove, Andrerv S.: High Otúptrt Managemen 1' New'York: Random House'

1983. Andy Grove es uno de los fundadores de Intel y tiene.grandes

conocimientossobrecomogestlonarunacompañíaenunaindustriatécnica competitiva. Grove uru un enfoque altamente cuantitativo de

la gestión.

4.2. Bases técnicas

Un estudio realizado en 1984 sobre <Métodos de programacton mo-

clernos> (bases técnicas) comprobó que no se puede alcanzat,una gran

frocluctividad sin utilizarlos. La Figura 4'2 muestra los resultados del

estudio.Es el mismo tipo de gráfico que se presentó en el capítulo <Errores

clásrcos>. y nos muestrull -it-o mensaje La aplicación de las bases

técnicas. pár sí sola. no es suficiente para obtener una alta productividad'

Hay aigunos proyectos que utilizan métodos de programación modernos

.o,i g.in detaile. ¡, obtienen la misma productividad que otros que no los

utiliian. Esto nos indica que las bases son necesarias' pero no suficientes'

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

delaAustralianComputerSociety(Constantine.l995b).Elconcursocon-sistió en llamar a equipos formados por tres personas para desarrollar y

entregar una aplicación de 200 puntos dc función en 6 horas'

Capítulo 4: Bases del desarrollo de software

Uso de técnicas modernas de programación(porcentaje del sistema total)

Media Alta(26-75%) (76-100%)

69

P^r.óñt2ié rléa planificación

nomlnal

+200

+1 00

0 (med¡a)

_1 00

Baja(o-25%)

Figura 4.2. Resultados del factor .Uso de los métodos de programac¡onmodernos" (Vosburgh el al., 1984). No se puede alcanzar Ia productividadmáxima sin utilizar "los métodos modernos de programasis¡', Que en este

capítulo se denom¡nan "bases técnicas,.

El equipo de Ernst y Young decidió seguir una metodología de desa-

rrollo formal. una versión reducida de la metodología que acostumbraban

a seguir: completa con actividades por etapas y entregas intermedias' Su

propuesta incluyó un cuidadoso análisis y diseño, parte de 1o que se des-

cribe en este capítulo como bases técnicas. Muchos de sus competidores

se rnetieron de lleno en la codificación, y en las primeras horas. el equipo

de E,rrrst y Young se qucdó atrás.

Sin embargo. al mediodía el equipo de Ernst y Young era el eqtripo

dominante. Al terminar el día. este equipo perdió, pero no fue debido a su

metodologia formal. Perdieron porque sobreescribieron accidentalmentealgunos de 1os archivos. entregando lrlenos funciones al final del día de

1as que habían dernostrado que tenían a la hora del almuerzo. De forma

irónica. lo que les hubiera salvado no era el habcr sido rnenos formales.

sino el haberlo sido más: es decir, la gestión de configuración formal in-

cluye copias de seguridad periódicas. Ellos se dejaron engañar por el error

clásico de no utilizar un control efectivo del código fuente.

El mensa.je de esta historia parece suficientemente claro, pero algunos

escépticos" incluyéndorne a mi. quedaron sorprendidos: Realmente, ¿,de-

bería el equipo de Ernst y Young haber garrado si tro hubiera sido por el

embrollo de la gestión de la configuración'? La respuesta es <sí>. Rea-

parecieron unos rrleses más tarde en otro concurso de desarrollo rápido(esta vez colr control de versiones y haciendo copias de seguridad) y ga-

naron (Constantine. 1996).En este caso. las metodologías formales merecieron 1a pena en un solo

día. Si prestando atención a las bases técnicas se puede conseguir esta

Leyenoa

l-l Máximo

I P€rcentil del 75'"

| É."'".Jnt" o"r zt'"I lN/linimo


dif-erencia en esta canticl¿rd de tiempo. irragincn la dif-erencia que puedchaber en un nro\/ecto de 6 a l2 rneses.

REFERENCIACRUZADA

Para más informaciónsobre los métodostradicionales de la

gestión derequerlmientos, véase

e Capitulo 14,

"Controi del conluntode prestac ones..

DATOS REALES

FEFEFENCIACRUZADA

Para más rnformaciónsobre ei control de

^r^hlam.< an Ire

nréetr. ^nac

\/orca It

Secc ón 1 4.2.,,Proyecto avanzado.

control de camblos deIrc ñroeie.i^na<,

Gestión de requerimientos

La gcstitirr de reqtrclirtticr'rl()s cs cl ploceso rluc c()l):istc cn leunir reqtreri-r.r.ricntos: plasnrallos cn un documento. corrco clcctrónico. cuaderno dcinterf-az dc usuario. prototipo e-jccutable o cualquier otro fbrmato: hacerun scguir.niento del discño y del código; y gcstionar los car.nbios para clrestcl dcl proyecto.

E,s r.nr-ry cornirn que los clesarrolladorcs se laurellten de los problerras¿rsociados a los rnótodos de gestiórr dc requerimientos tradicionalcs, sien-c1o la rnayoría cle cllos demasiado rígidos. Algunos rrétodos pucdcn serdenasiado rígidos. pero la altcrnativa que clfreccn suele ser peor. Un es-tuclio realizado en rnás de 8.000 proyectos encontró que las tres razonesprincipales por las que los proyectos cran entregados tarclc. por cncinradel prcsu¡-rucsto y cou nleuos firncionaliciacl dc la que se esperaba erandebiclas a los r.nétodos cle gestión de requerirlientos: falta de inforrnacióndel usuario. rcquerimientos incompletos y cambios en los requerinrientos(Standish (iroup. 1994). Un estuclio realizado por cl Instituto de Ingcnic-ría del Sofir.vare llegó a la r.nisma conclusión: rrás dc la mitad de los pro-yectos quc se estudiaron tur,ieror.l una gestión inadccuada de los requcli-mientos (Krtson y Mastcr. 1993).

E,l érito en la gestión de requerimicntos dependc dcl conocimicnto de

suficientes r.nétodos difcrcntes. de tbrma que sea posiblc escoger los rna-s

apropiados para un proyecto espccíl-ico. A continuacicir.r sc rnilcstran la,s

busc. dc llr ecstión dc reqtrcrirrricnlos:

¡ Metodologías de análisis dc re querir.r.rientos. inclr.ryendo análisrscstructurado, análisis estructurado de datos y análisis oricntado a

ob.jetos.o Métodos para crcar el modelo del sistcma. como diagramas de clascs.

cliagramas dc 11Lrjo cle datos. diagranas enticlad-re lación. notacitrndel diccionario de datos v diagrarnas de estado-transición.

o Métodos de comunicación. como el Dcsarrollo Conjr.rnto cle Apli-caciones (JAD). prototipaclo de la illterfaz de usuario y método.genL'l'illcs de entrcr islas.

¡ Las relaciones entre la gcstión 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 gcstiórt dc r'.'querinricrrttls propoleiona de clos fornlas dil'erent;-Llna gran influcncia en la velocidad de dcsarroilo. En primer lugar. la re-cogida de requerimientos cs tur paso que tiende a hacerse sin prisas. conr-

::::¡trN^l .: 7Añ

:: --:'-acton

.: :: :: On de- :.::S VéASE

::: ' -:C On de- :-'t,r. en la

::-: on 6.5.


parado con otras actividades del desarrollo del software. Si esre paso seacelera sin perjudicar a la calidad. se puede disminuir en conjunro cl tiempode desarrollo.

En segundo lugar. obtener un requerimiento collro es dcbido en cl pri-mcr paso non.nalmente cLlesta de 50 a 200 r eccs lDcnos quc si se espera a

las 1'ases dc construcción o mantenimiento (Boehrn y papaccio. 1988). Unproyecto nomral tiene un 25 por 100 dc caurbios en los requerirnientos.Algunos métodos de gestión de requerimientos pen.niten reciucir cl nú-mero de calnbios. Otros nlétodos de desarrollo permiten reducir el costcde cada cambio en los reqr.rerin.rientos. Ima-uine el efecto cornbinacloque ploducir'ía por un lado reducir el núr¡ero dc cambios de un 25 a unl0 por 100. y simultánearnente reducir el coste de cacla cambio en r-rn f'ac-tor de 5 o 10. El desarrollo rápido podría estar a su alcance.

Diseño

Del misn-ro n.rodo quc tiene sentido crear una serie de bocctos antes cjcconstruir una casa" tiene sentido cfear una arquitcctura y un diseño antesdc construir un sistema softw'are. Un error de discño que no se detectahasta la fase de comprobación. necesita l0 r,eces rnás tiempo para arrc-glarlo quc si se detectara en la fase de discño (Dunn, 198.1).

¿,Está preparado cualquiera para hacer un bucn diserlo'l No. Mi opiniónes quc cl buen diserlo es un ter.na de convcrsación común cn el desarrollociel sofln'are,y que realmente pocos desarrolladores haccn argo cle dise-ño. Un discñador que trabajaba para Microsoti dijo que en 6 años de en-trevistar a nrás de 200 candidatos para cl puesto cle dcsarrollador delsofirvare. sólo había entrcr"istado a 5 quc pudicran ciescribir exactanrcutelos conceptos de <r'r.rodularidacl> y <<ocultar.ricnto de infrlrmación> (Ko-hen.1995).

Los conccptos de rnodularidad v ocultamiento de informacirin son lasbascs del diseño. Ar.nbos son parte de las bascs del discño estructuraclo 1,

del diseño orientado a objetos. Un desarrollador que no puecie cliscutir sobrclos conceptos de modularidad y de ocultamiento dc informaciór.r es courounjugador dc baloncesto qLle uo sabe regatear con cl balón. cuanclo consi-deramos quc Microsoft examina rigurosarncnte a sus candidatos. inclusoantes de que seau entrevistados. llegamos a la cspantosa conclusión deque Ia situación cn el r.nundo dcl desarrollo del sofi'ur.'are cstá consi-derablemente peor de lo quc se creía. que de 200 desarrolladores. 195ticnen lagunas importantes en sus conocimientos soblc las bases del diserio.

A contiuuación se muestran los tenras básicos sobre la arquitectr-rra yel diserlo:

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

-: a=ALES


Conceptos fundamentales del diseño (como ocultanriento de infbr-mación, modularidad, abstracción. encapsulación, cohesión, aso-ciación. jerarquia. herencia. polimorfismo, algoritmos básicos yestructuras de datos básicas).Enfbques de diseño estándar en áreas generalmente duras (inclu-yendo manejo t1e excepciones. intenlacionaIización y localización.portabilidad, almacenamiento de cadenas. entrada/salida, gestió'de memoria, almacenantiento de datos. aritr.t.lética en punto flotan-te. diseño de bases de datos, rendimiento y reutilización).Consideraciones dcl diseño propias del dominio de la aplicaciónen la que se está trabajando (aplicaciones financieras, aplicacionescientíficas, sistenras <empotrados>, sistemas en tiempo real, soft-ll'are de seguridad crítica y otros).Esquernas de arquitectura (como organización de subsisternas, ni-veles, estilos de comunicación de subsistemas y arqLritectura típicade sistemas).Uso de herramientas de diseño.

REFERENCIACRUZADA

Para obtener másdetalles sobre un tipo

de diseño bienadaptado a los

proyectos de desarrollorápido, véase el

CapÍtulo 19,,,Diseñopara el cambio".

Es posible desarrollar un sistema sin diseñarlo prir.ncro. Los principa-les sistemas se han implementado a través de una codillcación completa runa habilidosa depuración, gran entusiasmo y mucho más tiempo clel cs-perado (y sin diseño sistemático). Sin embargo, el diseño es la base de l¡construcción, planificación. seguimiento y control del proyecto, y ese di-seño efectivo es imprescindible para conseguir la velocidad rnáxima d..desarrollo.

ConstrucciónEn cl monrento en que se llega a la construcción, 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 diseño ofrecen una mayor influencia en la p1.-nificación del desarrollo que la construcción. En estas actir,'idacles. lt.cambios pequeños pueden n-rarcar una gran diferencia en la planificaclo j:

En la planificación. la construcción no ofrece muchas oportunidacle .de reducción, pero el trabajo de construcción 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 atrás y rrejorarla. Re" -

mente no es efectivo hacerlo dos vcces.Aunque la construcción 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 críticas, consufilen tiempo. por ejerl¡.se puede perder el tiempo en funciones que no tienen que ser brillanr...depurar código inútil o ejecutar con esnero pequeñas secciones del sis -.ma antes de saber si realntente es necesario afinarlas.


para usted en este equipo. ya que hay bastantes módulos que tienen de-

masiados fallos y tienen que volver a escribirse.> Esta frase delata a una

persona que aún no comprende por qué requiere tanto tiempo realizar

un proyecto software.Cuando todo está dicho y hecho, prestar atención a las bases de la cons-

trucción es tanto un método de gestión de riesgos como un método de

ahorro de tiempo. Las buenas construcciones previenen la creación de un

nido de ratas de código indescifrable, que hace que el proyecto se pare

lenta y ruidosamente cuando una persona cae enferma, cuando se descu-

bre un fallo crítico, o simplemente cuando se necesita hacer un cambio.

Estos métodos mejoran las previsiones y el control que se tiene sobre el

proyecto e incrementan la probabilidad de entregarlo a tiempo'

Gestión de la configuración del software

La gestión de la configuración del software (SCM, Software confi-gu.ulion Management) es un método de gestión de los <artefactos> del

proy.ato. de forma quc el proyecto permanezca cn un estado consistcnte

todo el tiempo. SCM incluye métodos para evaluar los cambios pro-

puestos, seguir los cambios, manejar varias versiones y guardar copias de

ia evolución de los artefactos del proyecto. El artefacto del proyecto más

controlado suele ser el código fuente, pero puede aplicar SCM a los re-

querimientos, planes, diseños, casos de prueba, informes del problema.

documentación 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 pro-

blemas.La mayoría de los libros de desarrollo del softu'are consideran la SCM

como un método de garantía o control de calidad, y tiene un efecto bastan-

te fuerte sobre la calidad. Pero el tratarlo como un método de control de

calidad podría implicar que tiene un efecto neutro o negativo en la plani-

ficación del desarrollo. A veces. la SCM se implementa de forma que

disminuye la eficiencia, pero es crítica en el caso de que se desee alcanzar

la máxima velocidad de desarrollo. Sin la gestión de la configuración, los

compañeros de equipo pueden cambiar parte del diseño y olvidarse comen-

tarlo a los demás. Entonces, se puede implementar el código de forma in-

compatible con los cambios efectuados en el diseño, de forma que bierl

usteá o sus compañeros de equipo tendrían que rehacer de nuevo el traba.1o.

La falta de control automático sobre el código fuente es bastante co-

mún e ineficiente. En las organizaciones analizadas entre 1987 y 1993. el

Instituto de Ingeniería del Software encontró que rnás del 50 por 100 ne-

cesitaban mejorar la gestión de configuración del software (Kitson r

Masters, 1993). En los proyectos pequeños, la carencia de 1a gestión d.'

configuración aumenta un poco el porcentaje del coste del proyecto. ErlERROR CLASICO


grandes proyectos, la gestión de la configuración es un elemento del ca-

nrino crítico (Jones. 1994).

Bibliografía adicional sobre las bases de desarrollo

Muchas organizaciones de formación ofrecen cursos sobre análisis de re-querimientos y diseño. Los cursos sobre construcción y gestión de la con-figuración son más difíciles de encontrar. La mayor parte de las fuentes

de infonnación disponibles sobre alguno de estos temas probablementese cncuentran en los libros, así que a continuación se enumeran los me¡o-res libros de cada uno de los ternas.

Gestión de requerimientos

Yourdon, Edward: Modern Structurecl Anctlysis. New York: YourdonPress. 1989. El libro de Yourdon contiene un estudio sobre la especifi-cación de los rcquerimientos y el análisis hacia el año 1989. incluyendoherramientas de modelización, proceso de recogida de requerimientosy temas relacionados. Observe que una de las secciones más intere-santes se encuentra oculta en un apéndice: <Técnicas de entrevista yrecopilación de datos>.

Hatley, Derek J., y ImLtaz A. Pirbhai: Strategíes .f'or Reul-Time St;stent

Specificatictn New York: Dorset House Pubhshing, 1988. Hatley yPirbhai prestan especial atención a los sistemas en tiernpo real, y ex-tienden la notación gráfica utilizada por Yourdon al entorno en tiem-po real.

Gause, Donald C., y Gerald Weinberg: Exploríng Requirements: Qttalin,Before Design. Nerv York: Dorset House, 1989. Gause y Weinbergpresentan un curso poco común en el terreno de la gestión de requeri-mientos. Trata sobre la ambigüedad, reuniones, resolución de conflic-tos, represiones, expectativas. razones por las que las metodologíasno son suficientes y otros temas. E,llos evitan principalrnente los te-mas que incluyen otros libros de requerimientos y tratan los temasque otros libros evitan.

Diseño

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 colecciónreconfortante de ensayos que fueron originalmente publicados en larevista Computer Language. Plauger es un gran diseñador que se de-

dica a una sran variedad de tenas relacionados tanto con ser diseña-


dor como con el diseño en abstracto. Se extiende libremente por todoel ámbito del diseño. y no se restringe exclusivamente a un estilo dediseño; 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 diseño,particularmente el diseño relativo a la construcción. Al igual que ellibro de Plauger. describe varios estilos de diseño.

Yourdon. Edward, y Larry L. constantine: structurecr Design; Funda-mentals o/'a Discipline of'Computer Prograrn and svstents Design.Englewood cliffs, N.J.: Yourdon press, 1979. Éste es un rexto clásicosobre el diseño estructurado creado por uno de los coautores (cons-tantine) del artículo original. El libro está escrito con sumo cuidado.contiene temas completos sobre acoplamiento, cohesión, notaclonesgráficas y otros concepros importantes. Algunas personas han catalo-gado este libro como <técnicamente difícil>, pero es muy difícil ense-ñar un método mejor que sus inventores originales.

Page-Jones, Meilir: The Practical Guide to srructurecl svsÍents Design,2d Ed. Englewood Clifls. N.J.: yourdon press, l9gg. Es un libro*detexto muy conocido que presenta el mismo contenido sobre el diseñoestructurado que el libro de Yourdon y constantine y se escribió con unconsiderable entusiasmo. Algunas personas han encontrado el librode Page-Jones más 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 deBooch trata sobre los fundamentos teóricos y prácticos del diseño orien-tado a objetos en más de 300 páginas, y luego tiene 175 páginas mássobre el desarrollo de aphcaciones orientadas a objetos en c++. Na-die ha hecho una defensa más activa sobre el drseño orientado a obje-tos que Grady Booch, y es el volumen definitivo sobre el tema.

coad, Peter, y Edward Yourdon: object-orientecl Design E,nglewooclCliffs. N.J.: Yourdon Press, 199 l. Ésta es una alternativa más ligeraal libro de Booch, y algunos lectores podrían encontrarla como unaintroducción más sencilla sobre el diseño orientado a obietos.

Construcción

Mcconnell, Steve: Code Complete. Redmond, wash.: Microsoft press, 1993.Éste es el único libro conocido que trata sobre todos los temas clavesen la construcción, identificados en la sección <Construcción>. Contie-ne listas de control de gran utilidad en algunos aspectos de la construc-ción, así como datos que hacen más efectivos los métodos de cons-trucción. El libro contiene varios cientos de ejemplos de código en c.Pascal, Basic, Fortran y Ada.


Marcotty. Michael: Sofhrare Intplementatio¡r. NewYork: Prentice Hall, 199 l.E,ste libro trata sobre temas generales involucrados en la construccióndel software. prestando especial atención a la abstracción, complejidad,legibilidad y corrección. La primera parte del libro trata sobre la historiade la programación, sr"rbcultura, equipos de programación y cómo re-parten el tiempo de forma general. El libro está escrito con ingenio yestilo. y especialmente las primeras 100 páginas sobre <el negocio de

la programación> están muy bien hechas.

Los dos libros de Bentley que vamos a ver a continuación tratan el

tema de 1a programación y explican claramente las razones por las que

hay personas que consideran la programación coÍlo un tema muy intere-sante. El hecho de que la información no sea de fácil comprensión o no

esté rigurosamente organizada no evita que los libros traten unas ideas

muy significativas, las cuales se leerán en unos pocos rninutos y se utili-zarán durante años.

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

Bentley. Jon: More Programnting Pearls: Confbssions o/'o Coder. Rea-ding" Mass.: Addison-Wcsley, 1988.

Maguire, Steve: I4lriling Solid C¿rde. Redmond. Wash.: Microsoft Press,

1993. Este libro describe los métodos claves de construcción softwarcutilizados por Microsoft. Explica cómo minimizar los errores utili-zando avisos (v'arnings) de compilación, protegiendo el código consentencias de afirmación, fortaleciendo los subsistemas con pruebas

de integridad. diseñando funciones de interfaz no ambiguas. compro-bando el código con un depurador y evitando los mótodos de progra-rnación peligrosos.

Gestión de la configuración 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,nglewo-od Cliffs. N.J.: Prentice Hall. 1980.

Babich, W.: So./lv'are Configuration Mttnoger¡e¡¡l. Readiug. Mass.: Addi-son-Wesley. 1986.

Bersoff, Edward H., y Alan M. Davis: <lmpact of Life Cycle Modelson Software Configuration Managemenf>¡, Contmunications o/' theACM 34, núm.8 (August 1991):104-118. Estc artículo describe cónrola SCM está influenciada por las nuevas aproximaciones al dcsarrollodei software, especialmente por el prototipado.

Desarrollo y gest¡ón de proyectos informáticos

4.3. Bases del control de calidad

ERROR CLASICO

Al igual que las bases de gestión y técnicas, las bases dcl control de ca-

lidad proporcionan un apoyo fundamental para obtener la máxima veloci-dad de desarrollo. Cuando un producto software tiene demasiados erro-res, los desarrolladores emplean más tiempo corrigiendo e1 software que

escribiéndolo. Muchas organizaciones han descubierto que todo funcionamejor si no se cometen los errores en el primer paso. La clave principalpara no cometer errores es prestar atención a las bases del control de cali-dad desde el primer día.

Algunos proyectos intentan ahorrar tiempo reduciendo el tiempoque emplean en los métodos de control de calidad. como en el diseño y en

las revisiones del código. Otros proyectos (que van retrasados) intentanrecuperar el tiempo perdido reduciendo la planificación de la prueba.lo cual es bastante sensible a la reducción porque normalmente es el

elemento del camino crítico al final del proyecto. Estas son algunas de

las peores decisiones que una persona que desea maximizar la velocidadde desarrollo puede tomar, porque al aumentar la calidad (desde el punto de

vista de menor tasa de dcfectos) se reduce el tiempo de desarrollo. LaFigura 4.3 muestra la relación entre la tasa de defectos y el tiempo de

desarrollo.Pocas son las organizaciones que tienen una tasa de defectos extre-

madamente baja (mostrada en el extremo derecho de la curva de la Figu-ra 4.3). en cuyo punto, la reducción adicional del número de defectosincrementará la cantidad de tiempo de desarrollo. El tiempo extra es ne-

Tiempo dedesarrollo

=95% 100%Porcentaje de defectos suprimidos

Fuente: Datos extraÍdos de Applled Software Measurement(Jones, 199'1).

Figura 4.3. Relación entre la tasa de defectos y el tiempo de desarrollo.En la mayoría de los casos, los proyectos que se llevan a cabo con unatasa de defectos más baja también tienen una planificación menor.

La mayonade organizac¡onesse encuenlranalrededor de este punto

Capítulo 4: Bases del desarrollo de software 7g

cesario cuando se aplica a sistemas críticos para la vida, tal como 10s

sistemas de soporte vital de una lanzadera espacial, pero no cuando se

aplica a desarrollo de software no crítico para la vida.IBM fue la primera compañía en descubrir quc la calidad y la planifi-

cación del software estaban relacionadas. También descubrieron que losproductos con menor número de defectos eran los que tenían una menorplanificación (Jones, 1991).

En la actualidad, muchas organizaciones han desarrollado softwarecon un nivel de defectos que le asigna una planificación mayor de la necesa-ria. Después de realizar un estudio de más de 4.000 proyectos software,Capers Jones informa que una caiidad baja es una de las principales razo-nes del retraso en la planificación (Jones , 1994). También dice que la bajacalidad es una de las razones por las que se cancelan más de la mitad delos proyectos. Un estudio del Software E,ngineering Institute descubrióque un 60 por I 00 de 1as organizaciones tenían un control de calidad ina-decuado (Kitson y Masters, 1993). En la curva de la Figura 4.3, estasorganizaciones son las que están al lado izquierdo de la 1ínea que indicael 95 por 100.

Algunos puntos alrededor del 95 por 100 son significativos por-que ese nivel de supresión de defectos parece ser el punto en dondelos proyectos generalmente alcanzan la planificación más baja, el menoresfuerzo y el nivel más alto de satisfacción del usuario (Jones, 199 1).

Si después de lanzar el producto se tienen más de un 5 por 100 de def'ec-tos, será vulnerable a los problemas asociados a una calidad baja, yprobablemente se tardará más tiempo del necesario en desarrollar elsoftware.

Los proyectos que se realizan con prisas son particularmente vul-nerables a engaños en cuanto al nivel de calidad del desarrollador. Cuan-do se tienen prisas, se hacen recortes porque <sólo faltan 30 días para laentrega). En vcz de escribir un módulo de impresión completamentedistinto, se hace a partir del módulo de visualización en pantalla. Sesabe que el diseño es malo, que no es ampliable o de mantenimientofácil, pero no hay tiempo para hacerlo bien. Se tienen prisas por termlnarel producto. de fbrma que uno se siente obligado a tomar el camrnomás corto.

Tres mescs más tarde, el producto aún no se ha terminado, y empie-zan a aparecer los problemas derivados de esos recortes. Se encuentracon que los usuarios no están contentos con la forma de imprimir, y quela única manera de satisfacer sus requerimientos es aumentando significa-tivamente la funcionalidad del módulo de rmpresión. Desafortunadamen-te, desde hace tres meses el módulo de impresión y el de visualizaciónen pantalla se han ido entrelazando. Rediseñar el módulo de impresión ysepararlo del de visualización es una operación difícil, que consume tiempoy es susceptible a errores.

-]S REALES

:: ¡OR CLASICO


DATOS REALES

El resultado es que en un proyecto que se suponía que prestaba espe_cial atención al desarrollo de una planificación lo más corta posible, scpierde el tiempo en las actividades siguientes:

¡ Perder el tiempo en diseñar e implementar el módulo de impresión.ya que la mayoría del código se desechará. El tiempo que se ent_pleó cn la prueba y la depuración del módulo de impresión tambié.sr.' desperdició.

o El tiempo adicional que se debe emplear en separar el módulo deimpresión del módulo de visualización por pantalla.

¡ Se debe emplear tiempo de prueba y depuración adicional en ase-gurar que el código de visualización que se ha modificado siguefuncionando después de separarlo ilel módulo de impresión.

¡ El 'uevo

módulo de irnpresión, que debería haberse diseñado comouna parte integral del sistema, se ha diseñado fuera del sistema exls-tente. no siendo ésta la forma de diseño que se tenía pensada.

Todo esto sucede, cuando el único coste necesario (si se hubierantomado las decisiones apropiadas en el momento correcto) era el diseño eimplementación del módulo de impresión.

Este ejemplo es bastante común. El número de defectos que se presentancuando los programadores lanzan productos bajo una excesiva presión enla planificación es hasta cuatro veces mayor (.rones. 1994). En losproyectosque tienen problemas de planificación, se suelen obsesionar por trabajarmás duro, en vez de trabajar de forma más ingeniosa. prestar atención a lacalidad es como si fuera un lujo. El resultado es que los proyectos suelenfuncionar mal, dando lugar incluso a problemas graves de planificación.

Decidir al inicio del proyecto no centrarse en la detección de erroresequivale a la decislón de posponer la detección de defectos hasta mastarde. cuando será mucho más cara y consumirá tiempo. No es una deci-sión racional cuando el tiempo apremia.

Si se pueden prevenir o detectar los defectos y eliminarlos pronto, seobtiene una ventaja significativa en la planificación. Los estudios handemostrado que revisar errores de requerimientos, diseño y código nor-rnalmente consume del 40 al 50 por 100 del coste total del desarrollo delsoftvu'are (Jones. 1986b; Boehm, 1987a). como regla empírica, cada horaque se emplea en prevenir defectos reduce el tiempo empleado en la recu-peración de 3 a 10 horas (Jones, 1994). En el peor caso. revisar un pro-blema de requerimientos software, una vez que el programa está eje-cutándose, normalmente cuesta de 50 a 200 veces más de lo que costaríarevisar el problema cuando está en la fase de requerimientos (Boehm yPapaccio, 1988). Dado que más del 60 por 100 de los errores se dan entiempo de diseño (Gilb, 1988), se pueden ahorrar grandes cantidadesde ticmpo detectando los errores antes de hacer la prueba del sistema.

DATOS REALES

-: S REALES

Capitulo 4: Bases del desarrollo de software 81

En este libro se hace referencia a muchas ratios de coste, y como algunosde los valores son similares, las diferencias pueden llevar a confusión. Acontinuación se muestra un resumen:

r Cada hora que se emplea en las actividades de control de calidad,como son las revisiones de diseño, ahorra de 3 a 10 horas en elcoste total.

r Un defecto en los requerimientos que no se detecta hasta la cons-trucción o el mantenimiento necesitará una corrección que costaráde 50 a 200 veces más que si se hubiera hecho en la fase de reque-rimientos.

r De forma más general, un defecto que no se detecta al inicio (du-rante la fase de requerimientos o diseño) necesitará para su correc-cién de 10 a 100 veces más esfuerzo al encontrarlo al final (durantela prueba) de 1o que habría costado corregirlo al principio. Al de-tectar un error, cuanto más tiempo haya pasado desde el inicio, máscostará corregirlo.

Módulos propensos a errores

Un aspecto particularmente inrportante sobre el control de calidad. encuanto al desarrollo rápido, es la existencia de módulos propensos a

errores. Un módulo propenso a errores es un módulo responsable de unnúmero desproporcionado de defectos. Por ejemplo, en su proyecto IMS.IBM descubrió que el 75 por 100 de los errores se agrupaban en el7 por 100 de los módulos (Jones. 1991). Barry Boehm infbrma que sobreel 20 por 100 de los módulos en un programa son norntalmente responsa-bles del 80 por 100 de los errores (Boehm, 1987b).

Los módulos con tasas de defectos elevadas son más costosos yconsumen más tierrpo para ejecutarlos que los módulos menos propensosa errores. El desarrollo de módulos normales cuesta de 500 a 1.000 dólaresporpunto de función. Los módulos propensos a errores cucstan de 2.000a 4.000 dólares (Jones, 1994). Los módulos propensos a errores tienden a

ser más complejos que los demás módulos del sistema, menos estructu-rados e inusualmente grandes. Suelen desarrollarse bajo una fuerte pre-sión de planificación, y no suelen estar completamente probados.

Si la velocidad de desarrollo es importante, identificar y rediseñar losmódulos propensos a errores es prioritalio. Si la tasa de errores de unmódulo alcanza los l0 defectos por cada l00líneas de código, habrá querevisarlo para determinar si debería volverse a diseñar o implementar. Siel módulo está mal estructurado, es excesivamente compleio o lareo. ha-


DATOS REALES

brá que volverlo a diseñar e implementar desde el inicio. Se ahorrará tient¡,y se mejorará la calidad del producto.

Prueba

El método más común de control de calidad es indudablementc la prueba d;ejecución: encontrar crrores al ejecutar el programa y ver lo que hace. La.dos clases más comunes de pruebas de ejecución son las pruebas indil,idua-les, en las cuales el desarrollador comprueba su propio código para verificarque funciona correctamente, y las pruebas del sistema, en las que un pro-bador independiente comprueba si el sistema funciona como se esperaba

La eficacia de las pruebas varía 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 acu-mulada de la detección de defectos suele ser menor del 60 por 100 (Jo-nes, 1986a). Los errores que no se localizan se pueden encontrar por otrastécnicas de detección de errores. como las revisiones o los usuarios fi-nales, después de que el software se haya puesto en funcionamiento.

La prueba es la oveja negra en lo que respecta a los métodos de controlde calidad, y en lo que respecta a la velocidad de desarrollo. Realmentese puede hacer tan mal como para retrasar la planificación de desarro-1lo, pero su efecto en la planificación suele ser indirecto. La prueba des-cubre que la calidad del producto es demasiado baja para lanzarlo. y elproducto tiene que retrasarse hasta que se pueda rnejorar. De esta manera.la prueba se convierte en el mensajero que comunica las malas noticiasque afectan a la planificación.

La mejor forma de fomentar la prueba, desde el punto de vista deldesarrollo rápido, es preparar un plan antes de obtener las malas noticias:establecer la prueba de forma que si se dan malas noticias, la prueba per-mita lanzar el producto tan pronto como sea posible.

Revisiones técnicasLas revisiones técnicas incluyen toda clase de revisiones que se utilizanpara detectar defectos en requerimientos. diseño, código, casos de pruebao cualquier otro artefacto del proyecto. Las revisiones varían en cuanto alnivel de formalidad y eficacia, y juegan un papel más crítico en la veloci-dad de desarrollo que las pruebas. Las secciones siguientes resumen lostipos de revisiones más comunes.

Reuniones

Las reuniones informales son el tipo más común de revisión. El término<reunión> se define aproximadamente y se refiere a cualquier reunión enDATOS REALES

¡-Mr,?*'&É

. \F4F+

::::'.:lA_: _::lA. ::-_en

:1, : :3 aS

i : :::l a

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


la que dos o más desarrolladores revisen el trabajo técnico con el objetivo.1e r.t.rejorar su calidad. Las reuniones son útiles para el desarrollo rápido,porque se pueden utilizar para detectar errores antes de la prueba. Porelemplo. en el caso de que la prueba pueda detectar un defecto en losrequerimientos, lo hará después de quc éstos se hayan especificado,diseñado y codificado. Una reunión puede detectar un defecto en losrequerimientos. en tiempo de especificación, antes de que se realice elrirseño o se codifique. Las reuniones pueden encontrar entre el 30 y el 70por 100 de los errores en un programa (Myers, 1979; Boehm, 1987b; Your-don.1989b).

Lectura del código

La lectura del código es un proceso de revisión más formal que unareunión, pero normalmente sólo se aplica al código. E,n la lectura del có-digo. el autor del mismo distribuye listados del código fuente entre dos omás revisores. Los revisores leen el código e informan de cualquier erroral autor del código. Un estudio en el Laboratorio de Ingenieria del Soft-n'are de la NASA descubrió que la iectura del código detcctaba dos vecesmás cantidad de defectos por hora de esfuerzo que la prueba (Card, 1 987).Esto sugiere que en un proyecto de desarrollo rápido, la combinación delectura del código y prueba sería más efectiva para la planificación quesolamente la prueba.

Inspecciones

Las inspecciones son un tipo de revisión técnica formal, que ha demos-trado scr extremadamente efectivo en la detección de errores en un proyec-to. Con las inspecciones, los desarrolladores reciben una preparaciónespecial y juegan un papel específico durante las mismas. E1 <mode-rador> se vuelca en trabajaren el producto para inspeccionarlo antes de lareunión de inspección. Los <revisores> examinan el producto antes dela reunión y utilizan listas de control para estimular su revisión. Durante lareunión de inspección, el <autor>> normalmente comenta el material ins-peccionado, los revisores identifican los errores y el <secretario> guardalos errores. Después de la reunión, el moderador genera un informe sobrela inspección, describiendo cada uno de los defectos e indicando lo que se

hará con ellos. A 1o largo del proceso de inspección, se recogen datossobre defectos, se emplean horas corrigiendo estos defectos, y se empleanhoras en las inspecciones, de forma que se pueda analizar 1a efectividaddel proceso de desarrollo del software y mejorarlo.

Al igual que en las reuniones, las inspecciones se pueden utilizar paradetectar defectos tan pronto como colt la prueba. Se pueden utilizar para de-tectar errores en requerimientos, prototipos de interfaz de usuarios. diseño.- : ==ALES


código y otros artefactos del proyecto. Las inspecciones encuentran de un60 a un 90 por 100 de defectos en un programa, lo cual es considerable-mente mejor que las reuniones o las pruebas. Las inspecciones generanuna planificación neta, ahorrando de un I 0 a un 30 por I 00. ya que se pue-

den utilizar en el ciclo de desarrollo (Gilb y Graham, 1993 ). E,n un estudiorealizado sobre un programa grande, se encontró que cada hora empleadaen las inspecciones producía una media de 33 horas de ahorro, y las ins-pecciones eran 20 veces más eficientes que las pruebas (Russell, 199 l).

Comentarios sobre las revisiones técnicas

Las revisiones técnicas son un complemento útil e importante para la prue-

ba. Las revisiones tienden a encontrar errores de tipos diferentes a las

pruebas (Myers, 1978; Basili, Selby y Hutchens, 1986). Encuentrandefectos más pronto, lo cual es bueno para la planificación. Las revisio-nes tienen un coste más efectivo en la búsqueda de defectos, ya que detectanal mismo tiempo tanto el síntoma como la causa fundamental del defecto.La prueba sólo detecta el síntoma del defecto: el desarrollador aún tieneque encontrar la causa en la depuración. Las revisiones tienden a encon-trar un porcentaje alto de defectos. Y las revisiones proporcionan unforo para que los desarrolladores muestren sus conocimientos sobre losrnétodos recomendables. aumentando las posibilidades de desarrollo rá-piclo. Las revisiones técnicas son un componente crítico de cualquieresfucrzo de desarrollo que esté intentando alcanzar la planificación más

corta posible.

effiFigura 4.4. ¡No permita que le suceda esto! Cuanto más tiempo permanezcaoculto un defecto, más tiempo necesitará para corregirlo. Corriia los defectoscuando están en un estado inicial v son fáciles de controlar.


Bibliografía adicional sobre los fundamentosdel control de calidadi\{uchos de los libros referenciados en otros aspectos de este capítulo con-tienen secciones sobre aspectos generales de la calidad del software, revisio-nes, inspecciones y pruebas. Estos libros incluyen A manager's Guide toSo.ftware Engineering (Pressman, 1993), SoJiware Engineering: A Prac-riÍioner's Approach (Pressman, 1992), So.fiware Engineering (sommer-rille, 1996), y Code Complefe (McConnell, 1993). A continuación semuestran las fuentes adicionales de información sobre temas esDecíficos.

Calidad del software en general

G1ass, Robert L.: Building Qualitv Solivrare. E,nglewood Cliffs, N.J.: Pren-tice Hall, 1992. Este libro examina consideraciones sobre la calidaddurante todas las fases del desarrollo del software, incluyendo reque-rimientos, diseño, implementación, mantenimiento y gestión. Descri-be y evalúa una gran cantidad de n-rétodos y muestra numerosas des-cripciones de otros libros y artículos sobre calidad del software.

Chow, Tsun S., ed.: Tutorial; So.ftv,are Qualit,v- Assuranc'e: A PracticalApproach. Silver Spring, Md.: IEEE Computer Society Press, 1985.Este libro es una colección de unos 45 artículos que tratan del tema dela calidad del software. Las secciones incluyen definiciones sobre lacalidad del software, medidas y aplicaciones; directivas de planifi-cación, organización, estándares y convenios; cuestiones técnicassobre requerimientos, diseño, prograrnación, prueba y validación; e

implementación de un programa sobre seguridad y calidad del soft-ware. Contiene muchos artículos clásicos sobre este tema. v su srantamaño lo hace especialmente valioso.

Prueba

Myers, Glenford J.: The urt of Sofiw,are Testing. New York: John Wiley& Sons, 1979. Es un clásico de la prueba del software, y aún hoy si-gue siendo uno de los mejores textos disponibles. Los contenidos sonclaros: la psicología y rentabilidad sobre la prueba del programa; diseñode casos de prueba; prueba de módulos; prueba de orden superior:depuración; herramientas de prueba; y otras técnicas. El libro es corto(177 páginas) y entretenido. La encuesta que incluye al principio pre-tende hacerle pensar como un probador y demuestra exactamente lasformas en las que el código 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 buenaalternativa al libro de Myers, ya que trata sobre el mismo tema, pero


de forma más moderna. Además de tratar 1o misrno que Myers, Hetzeltambién trata sobre la prueba de requerimientos y diseño, prueba deregresión. compra de software. y consideraciones de gestión. Con 284páginas, también es relativamente corto, y e1 autor muestra una grancalidad, presentando conceptos técnicos bastante potentes.

Revisiones e inspecc¡ones

Gilb, Tom. y Dorothy Graham: Sofiwure Inspection. Workingham, En-gland: Addison-Wesley, 1993. Este libro hace un tratamiento mu1'minucioso sobre las inspecciones. Tiene un enfoque práctico e inclu-ye ejemplos de muchas organizaciones que han establecido progra-mas de inspección.

Freedman, Daniel P., y Gerald M. Weinberg: Handbook of Walkthroughs.InspecÍions and Technical Revieu,s, 3d Ed. New York: Dorset Hou-se, 1990. Es un libro excelente en cuanto a revisiones de toda clase.incluyendo reuniones e inspecciones. Weinberg es el promotor originaide la <programación anónima>, la base de la mayoría de las revisio-nes prácticas. Es enormemente práctico e incluye muchas listas decontrol útiles, informes sobre el éxito de las revisiones en varias com-pañías, y anécdotas entretenidas. Se presenta con un formato de pre-guntas y respuestas.

Los dos artículos siguientes están escritos por el desarrollador de ins-pecciones. Contienen lo nccesario para ejecutar una inspección, incluyendolos formularios de inspección estándares.

Fargan, Michael E: <Design and Code Inspections to Reduce Errors inProgram Development>>,lBM S-v-stems Journal, vol. t5, núm. 3, 197ó.pp. 182-21 l.

Fargan, Michael E: <Advances in Software Inspections>>, IEEE Transut-tions on Sofiware Engineering, July 1986, pp. 144-151.

4.4. Seguir las instrucc¡ones

Cuando estaba en séptimo grado, mi profesor de arte insistió en que cual-quier estudiante que siguiera sus instrucciones obtendría al menos una B.sin necesidad de tener talento artístico. Era un ex marino de 120 kilos. rteniendo en cuenta que daba este aviso al menos una vez por SellsDil. \'tlestaba asombrado de cuántos alumnos del séptimo curso, de 60 kilos, no sr-

guieron sus instrucciones y no consiguieron alcanzar una B. A juzgar po:su trabajo, no estaban atormentados por alcanzar la gloria, ni tampoco erancontrarios a su visión artística. Ellos sentían que hacían algo diferente.


Como adulto, suelo ver que los proyectos software fallan simplementeporque los programadores y directivos que trabajan en ellos no siguen las

instrucciones. las bases del desarrollo de software descritas en este capítulo.Es cierto que se puede desarrollar software sin dominar los fundalnentos,a veces incluso rápidamente. Pero a juzgar por los resultados de la mayo-ria de las personas, si los fundamentos no prevalecen al principio, no se

tendrá ei control necesario sobre el proyecto para desarrollarlo rápida-mente. 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 instruc-

ciones siguientes en la lata de pintura:

1. Prepare la superficie: raspe la madera o el metal; líjela con suavi-dad; quite los restos con disolvente.

2. Prepare la superficie utilizando un producto adecuado.3. Después 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 centígrados. Déjela secar durante dos

horas.4. Aplique una segunda capa fina y déjela durante 24 horas antes de

utilizarla.

¿,Qué sucedería si no se siguieran las instrucciones'l Si va a pintar la

caseta del perro un martes por 1a noche, después del trabajo, sólo tendríados horas para pintarla, y Fido necesita dormir esa noche. No hay tiempopara seguir las instrucciones. Podría 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 su-

cia, es probable que todo vaya bien.Después de unos pocos meses, la pintura se podría agrietar, al ser la

capa de pintura demasiado gruesa, o se podrían desconchar las superficiesde metal de los clavos al no estar preparadas adecuadamente, y habría que

r olverla a pintar otra vez el próximo año, pero realmente no tendría den-ra-

siada importancia.

¿,Qué sucedería si en vez de la caseta del perro se estuviera pintandoun Boeing 141'! En este caso, sería conveniente seguir las instrucctonesde la lata. Si no quitara la capa de pintura previa, incurriría de forma sig-nificativa 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 atacarían la pintura al ir a 600 millas por hora, y ten-

drían efecto mucho más rápidamente que un viento y una lluvia suaves en

la caseta de Fido.

¿Qué sucedería si se pintara algo que estuviera entre una caseta de unperro y unl4l , por ejemplo una casa? En este caso, las consecuencias de


realizat un mal trabajo serian menos severas que para uni4i, y más quepara una caseta de un perro. No desearemos volver a pintar la casa en dosaños, y desearemos tener mejores resultados que con la caseta del perro.

La mayoría de los proyectos software que tienen problemas de plani-ficación son proyectos del tamaño de la casa o mayores, y son esros pro-yectos los que principalmente interesan en este libro. En tales proyectos.las bases de desarrollo ahorran tiempo. Si se tiene suficiente conocimien-to sobre el problema, sería un proceso mucho menos rígido que los pasosde la lata de pintura. proporcionando toda la flexibilidad necesaria. Sepueden ignorar las instrucciones si se desea, pero hay que hacerlo tenien-do conciencia del riesgo que conlleva.

Bibliografía general

La sección bibliografía adicional del final de este capítulo presenta unlistado de libros de ingeniería del software. El motivo de leer un libro deconocimientos generales sobre ingeniería del software no es adquirir un co-nocimiento profundo sobre un tema específico, sino ver a grandes rasgosel desarrollo del software. dentro del contexto. Los siguientes libros des-criben una visión de los métodos que este capítulo describe como basesdel desarrollo del software.

Sommerville,lan: Software Engineering, 6th Ed. Reading, Mass.: Addi-son-Wesley, 1996. En la sexta edición de este libro se tratan de formaequilibrada los requerimientos, diseño, validación de la calidad y ges-tión. Contiene diagramas útiles y cada tema tiene una sección so-bre bibliografía adicional. Con 700 páginas, no es necesariamenteun libro que se tenga que leer de principio a fin, pero si se desea unabreve descripción sobre un tema en particular, probablemente se en-cuentre en este libro. Tiene un buen índrce.

Pressman, Roger S.'. So.fi,,rare Engineering: A Practitioner's Ap¡troar.lt3d Ed. New York: McGraw-Hlll, 1992. Es una excelente alternatiraal libro de Sommerville y es similar en contenido y tamaño. No sc-

confunda con el título I Practitioner's Approach (<Un enfoque prác-tico>); aun siendo excelente, este libro es más adecuado como un libropara proporcionar una visión sobre temas importantes que para serusado como libro orofesional.

Gestión de r¡esgos

Contenido

5.1. Elementos de la gestión de riesgos5.2. Identificación de riesgos5.3. Análisis de riesgos5 .1 . Pri ori zac ión de r ie sgo s

5.5. Control de riesgos5.6. Riesgo, alto riesgo y azar

Temas relacionados

E,strategia de desarrollo rápido: Capítulo 2

Errores típicos: Capítulo 3

Bases del desarrollo de software: Capítulo 4Resumen del filtrado de requisitos: Capítulo 32Resumen de los diez riesgos más frecuentes: Capítulo 4l

SI QUIERE APOSTAR SEGURO, VAYA A LAS VEGAS y juegue a las

máquinas tragaperras. Los casinos han calculado minuciosamente las pro-babilidades y han determinado que pueden obtener beneficios inclusocuando las máquinas paguen hasta el 97 por 100 del dinero de la recau-

dación. Las probabilidades se refieren a que si un día juega 1.000 dólaresen monedas en las máquinas tragaperras, podrá obtener hasta 970 dóla-res. Si no le gustan las máquinas tragaperras, puede jugar al blackjack ycontar 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 ries-gos que pueden causar pesadillas a los apostadores de Las Vegas (cambiode los requisitos del usuario, mala estimación de la planificación, per-

89


DATOS REALES

sonal contratado poco fiable, f-alta de experiencia en la gestión, problemasde personal. problernas con la tecnologia, cambio de las leyes del gobier-no y problemas con el desarrollo. por nombrar sólo unos de ellos). Laprobabilidad de que un proyecto complejo finalice en el tiempo estimadotiende a cero. Las probabilidadcs de que un proyecto complejo se cancelese 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 empre-s¿rs encuestadas han tcnido al menos un proyecto que se les ha ido de lasmanos (Rotht-eder, 1988). Los daños producidos por proyectos descon-trolados hacen parecer a los combates de Las Vegas tan tranquilos comotonrar una taza de té con la Reina. Allstate comenzó a automatizar en 1982sus actividades aclministrati'u as. Planificaron una temporización para crncoaños y un presupuesto de 8 ntillones. Seis años más tarde y l5 millonesdespués, Allstatc establcció una nueva f'echa límite y estimó un nuevopresupuesto de 100 millones de dólares. En 1988, la Westpac Bankingcorporation clecidió redefinir sus sistemas dc información. Planificaronun proyecto cle 85 nlillones de dólares para cinco años. Tres años mástarde. después de gastar 150 millones con poco éxito, asumió sus pérdi-das. 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 métodos de gestión de riesgos que pueden prevenlrdcsastres como óstos, y que le harán aprender mucho de ellos antes de loque aprcndería a contar las cartas en eI blackjack. De acuerdo que haypcrsonas queJuegalt al blackjack sin haber aprendido a contar las cartas.y personas que planifican proyectos de software sin haber aprendido mu-cho acerca de la gestión de riesgos. Pero el hecho es el siguiente: si nocontrola los riesgos, no podrá crear desarrollos rápidos. Como dice TomGilb, <si no controlas los riesgos, cllos te controlarán a ti>.

E,l control de riesgos tiene una serie de problemas. Los proyectos quellevan un control de riesgos efectivo son menos excitantes que los pro-yectos 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 proble-ma que nunca había mencionado. Dejará de ser un héroe por trabajar no-ches y fines de semana durante seis meses sin descanso. Para muchos denosotros, éstos son problemas con los que se puede vivir.

El control de riesgos en software es un tema relativamente nuevo, peroya eriste infbrmación suficiente como para estudiarlo con profundidad eneste capítulo. El estudio de este capítulo se centra en los riesgos en laplanificación e ignora los riesgos sobre costes y producción, salvo cuan-do af'ecten a la planificación. Este capítulo también se centra en los as-pectos prácticos del control de riesgos de planificación. La teoría del con-trol de riesgos es interesante e inrportanre. pero es menos útil, por lo quela hemos evitado, mostrando en la sección de bibliografía adicional alfinal del capítulo dónde puede encontrar más información.

Capítulo 5: Gestión de ilesgos 91

Ejemplo 5.1. Falta de gestión 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 <prét-á-porter>. <Tengo cuatro meses para entregar laactualización, y creo que va a ser un bombazo.> Kim entregó su últimoproyecfo, 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 ladiferencia se ha debido a que su producto era mucho más complejo que elde tddre.

<Yo de ti estaría más preocupado>, le dijo Eddie a ella. <He vistola especificación de 1a 2.5, y pienso que con el equipo actual te que-dan más de seis meses de trabajo. ¿Has pensado en utilizar el equipode la 2.0?>

<Sí, claro. Y también he pensado en ajustar el plan de trabajo a cuatromeses. La semana pasada leí un articulo sobre desarrollo externo, y he en-

contrado a alguien que se puede encargar de las actualizaciones de los grá-ficos, 1o que reduciría el plan en dos meses.>>

<<Bueno, €spero que sepas 1o que estás haciendo>, le dijo Eddie. <He

visto a mucha gente fracasar por culpa del personal contratado. ,,Cuál es tuplan para el control de riesgos?>

<He contratado a una persona de prestigio>, drlo Kim. <He comproba-do sus referencias y estoy segura de que hará un buen trabajo. Le echaré unojo de vez en cuando. Esto es un negocio arriesgado, y algunos riesgos soninevitables. Cuando tengo tanto trabajo por hacer, no pienso perder mi tiempoen trabajos inútiles.>

Eddie pensó que ella debería tener más cuidado, pero Eddie y Kimya pasaron por esto antes. Él había 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 especifi-

cación para las acfualizaciones de los gráficos. Chip, la persona contrata-da, le dijo que las especificaciones le parecian claras y que se pondría a

trabajar enseguida.Seis semanas más tarde, Kim llamó a Chip para comprobar el estado

del trabajo. <Todo va bien>, dijo é1. <He estado trabajando en un proyectomuy importante de otra empresa, por lo que todavía no he podido avanzarmucho. Pero todavia tenemos tres meses y medio para realizar un trabajode dos meses, así que no te preocupes.))

<<Eso suena bien>, 1e dijo Kim. <<Avísame si necesitas algo. Te volver'éa llamar dentro de seis semanas para tratar la integración.r

Seis semanas más tarde, Kim volvió a llamar para comprobar la evo-lución del trabajo. <El últirno proyecto me llevó más tiempo del que es-

peraba>, le d¡o Chip. <<He comenzado la actualización de los gráficos, yhe estado trabajando como un loco, pero necesito analizarlos más pro-fundamente, pienso que tendré que dedicarle otros tres meses.))

((ontinudl


Kim casi se ahoga. Esto haría que el tiempo de desarrollo total fueseseis meses en lugar de cuatro. <¿Tres meses? ¿Me estás tomando el pelo?Necesito ese código en dos semanas para empezar con la integración. Sesupone que ya lo tenías que tener hecho.>

<<Lo sientoi;, dijo Chip. <<Pero no es culpa mia. Esfo tiene más trabajodel que había estimado. Lo terminaré tan pronto como pueda.>

Chip desanolló el software en tres meses, pero el proyecto se retrasó otromes más por los problemas de integración con el código del equipo propio..41 final el tiempo total de desarrollo fueron siete meses, en lugar de loscu.atro meses previstos. Kim acabó pensando que Eddie le habia hecho car-gar a ella con un proyecto que él nunca hubiese podido llevar a cabo.

5.1. Elementos de la gestión de r¡esgos

La función de la gestión de riesgos del software es identificar, estudiar yeliminar las fuentes de riesgo antes de que empiecen a amenazar la finali-zación satisfactoria de un proyecto software. Puede controlar los riesgosa varios niveles. La Tabla 5.1 describe algunos de los niveles de la ges-tlón de riesgos.

El objetivo de este capítulo es describir cómo estudiar los riesgos de1a planificación software en 1os niveles 4 y 5, en lugar de en ros nivelesdel 1 al 3. Si está controlando riesgos al nivel 1,2 o 3, ya ha perdido labatalla de la planificación.

Generalmente, la gestión de riesgos se divide en valoración de riesgosy control de riesgos. Además, se compone de varias subcategorías. comose muestra en la Figura 5.1. Esto se explica en los siguientes epígrafes.

Tabla 5.1. Niveles de gestión de riesgos

l. Cr¡ntrol de crisis. Apagar el fuego; controlar los riesgos sólo cuando sehan convertido en problemas.

2. Arreglar cada error. Detectar y reaccionar rápidamente ante cualquierriesgo, pero sólo después de que se haya producido.

3.

5.

Mitigación de riesgos. Planificar con antelación el tiempo que necesitariapara cubrir riesgos en el caso de que ocurran, pero no intentar eliminarlosinicialmente.

Prevención. Crear y llevar a cabo un plan como parte del proyectosofiware para identificar riesgos y er itar que se conr iertan en problemas.

Elintinar:i(¡n de lus causas principules. Identificar y eliminar los factoresque puedan hacer posible la presencia de algún tipo de riesgo.

Fuentc: Adaptado de,1 Munuger's Guitle to solivrare Engíneering (pressman, 1993¡

Estimaciónde nesgos

Capítulo 5: Gestión de riesgos

ldentificación de

Análisis de

Priorización de riesgos

Gestión de riesgosPlanificaciónde la gestión de riesgos

Control de nesgos Resolución de riesgos

Monitorización de riesgos

Figura 5.1. La gestión de riesgos se compone de estimación y controlriesgos. Fuente: Software Risk Management (Boehm, 1989).

Estimación de riesgos

La estimación de riesgos se compone de identificación de riesgos, análi-sis de riesgos y asignación de prioridades a los riesgos:

o La identi.licac:ión cle riesgos genera una lista de riesgos capaces deromper la planificación del proyecto.

o El análisis de riesgos mide la probabilidad y el impacto de cadariesgo, y los niveles de riesgo de los métodos alternativos.

o La asignación de prioridades a los riesgos genera una lista de ries-gos ordenados por su impacto. Esta lista sirve como base para elcontrol de riesgos.

Control de riesgos

El control de riesgos se compone de planificación de la gestión de ries-gos, resolución de riesgos y monitorización de riesgos:

. La plani.licación de la gestión de riesgos genera un plan para tratarcada riesgo significativo. También asegura que los planes para lagestión de riesgos de cada uno de los riesgos individuales son con-sistentes entre sí y con el plan del proyecto.

c La resoluc:ión de rie.sgos es la ejecución del plan para resolver cadauno de los riesgos significativos.

o La monitorización de riesgcts es la actividad del progreso de lamonitorización dirigido a la resolución de cada elemento del ries-go. La monitorización de riesgos también puede incluir la conti-nuación de la actrvidad de la identificación de nuevos riesgos yvolver a considerarlos en el proceso de la gestión de riesgos.


Los apartados dc la si-truientepectos de la gestión de riesgos enla planificación soltware.

5.2. ldentificac¡ón de riesgos

sección explicansu aplicación a la

cada uno de estos as-gestión de riesgos en

Si no pideinlitrntucitin soltra

riesgo.s, a.sttibu.scundo

pnthlenr us.

Tom Gilb

El primer paso en la gestión de riesgos es la identiflcación de los factoresque introducen un riesgo en la planificación. Hay tres riesgos generalcsen un proyecto de clesarrollo rápido, que soll olvidar los tres pilaresdel desarrollo rápido, descritos en cl capítulo 2, <E,strategia para el desa-rrollo rápido>:

o comcter uno de los errores típicos clescritos en el capítulo 3, <Erro-res claslcos).

. lgnorar las bases del desarrollo descritas en el Capítulo 4, <Base,sdel desarrollo de software>.

o Fallar en la gestión activa dc riesgos descnta en este capítulo.

Una vez que haya superado cstos riesgos generales, habrá encontradocasi 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 formasmás l'áciles de identificar los riesgos es comprobar su proyecto frente auna lista dc riesgos de la planificación. E,l apartailo siguiente proporcionauna lista crhaustiva de los posibles riesgos en la planificación.

Riesgos más comunes en planificac¡ónLa Tabla 5.2 contiene una lista de los riesgos más comunes en la planifi-cac i ón.

Si los riesgos de esta tabla le son familiares. se debe a que cada untrde ellos ya sc comentó en los errores clásicos del capítulo 3. La únicadiferencia entre un error clásico y un riesgo es que los errores clásicos secometen con mayor frecuencia. Los riesgos son menos colrunes o puedenser únicos en su proyecto. cada uno de los riesgos dc la Tabla 5.2 sedescribe con más detalle en la Sección 3.3, <Relación cle errores clási-cos)), y la forma de controlarlos se estudia posteriormente en este caDítu-lo. en la Tabla 5.6.

Lista completa de riesgos de planificaciónLa Tabla 5.3 contiene una lista exhaustil'a de los ricsgos que pueden afecta¡a la planificación de un proyecto software. Sólo algunos de ellos apare-cerán cn la mayoría de los proyectos. Los riesgos se han organizado en

Capítulo 5: Gestión de riesgos 95

Tabla 5.2. Riesgos más habituales en planificación

l. Cambio de requisitos.

2. Meticulosidad cn requcrimicntos o dcsarrolladores.

3. Escatirn¿rr en la calidad.

4. Planificaciones dernasiado optimistas.

5. Diseño inadecuado.

6. Síndrome de la panacea.

7 . Desarrollo orientado a la investigación.

u. Pclsonrl rncdioele.

9. Error en la contratación.

10. Dif-erencias entre el pe rsonal de desarrollo y los clientes

Fucntes: Adaptado de Sofiuure Ri.sk ,I4unugentc¡l¡ (Bochnr. 1989) y.,1.r,sc,.ss¡r¡cn/ untl Ct¡n-

trol ol .\oli¡ut'e Rl.ii.r 1.lones. 199,1).

categorías, pero sin un orden concreto. Si la lista le parece abrumadora,concéntrese en los riesgos más comunes de la sección anterior.

Además de la lista de riesgos de esta tabla, la mayoría de los proyectostienen riesgos que son característicos de ese proyecto: <Joe está dispuestoa abandonar, a mcnos que se pueda llevar su perro al trabajo, y la direc-ción aún 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 planificación

Cresción de Iu planificociótr

Las deflniciones de la planificación, de los recursos ¡r del producto han sidoimpuestas por el cliente o un directivo superior, v no están equilibradas.

Planificación optirxista, <mejor caso> (en lugar de realista, <caso esperado>).

La planificación no incluye tareas necesarias.

La planificación se ha basado en la utilización de pelsonas específ-icas de uncquipo, pero estas personas no cstán disponibles.

No se puedc construir un producto de tal envergadura en cl tiempo asignado.

El producto es más grande que cl cstirnado (en líneas de código. en el número de

puntos de función. o en relación con el tamaño del pro¡'ecto anterior).

El esfuerzo cs lnayor que el estimado (por lineas de código, núlrel'o de puntosde función. rnódulos, etc.).

\( onltnltu )


Tabla 5.3. (Continuat.irjn)

La reestimación debida a un retraso en la pranificación es demasiado optimisreo ignora la historia del provecto.

La presión excesiva en la planificación 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 rnás tiernpo del esperado en el diseñ.

y en la implernentación.

Organización y gestión

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.Dirección o marketing insisten en tomar decisiones técnicas que alargan la

planificación.

La estructura inadecuada de un equipo reduce Ia productividad.El ciclo de revisión/decisión de ra directiva es más lento de lo esperado.El presupuesto varia el plan clel proyecto.

La dirección toma decisiones que reducen la motivación del equipo dedesarrollo.

Las tareas no técnicas encargadas a terceros necesitan más tiempo del esperadolaprobación del presupuesto. aprobación de la aclquisición de material.revisiones legales. seguridad, etc.).

La planificación es demasiado mala para ajustarse a la velocidad de desarrolrodeseada.

Los planes del proyecto se abandonan por la presión, llevando al caos y a undesarrollo ineficiente.

La dirección pone más énf'asis en las heroiciirades que en informarse exacramentedel estado' lo que reduce su habilidad para detectar y corregrr problernas.

Entorno de desarrollo

Los espacios no están disponibles en el momento necesario.Los espacios están disponibles pero no son adecuados (por ejemplo, falta de

teléfonos, cableado de la red, mobiriario. material d" oii.inu, .t..).Los espacios están sobreutiliza<Jos, son ruidosos o dlstraen.Las herramientas de desarroilo no están 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 I


Tabla 5.3. lL'trntiilttd( ¡t;nl

Las herramientas de desarrollo no se han elegido en función de suscaracterísticas técnicas, y no proporcionan Ias prestaciones pre\ istas.

La curva de aprendizaje para la nueva herramienta de desarrollo es más larga delo esperado.

Usuarios finalesLos usuarios finales insisten en nuevos requerimientos.

En el último momento, a los usuarios finales no les gusta el producto, por loque hay que volver a diseñarlo y a construirlo.

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

No se ha solicitado información al usuario, por lo que el producto al final no seajusta a las necesidades del usuario, y hay que volver a crear el producto.

Clienfe

El cliente insiste en nue\os requisitos.

Los ciclos de revisión/decisión del cliente para los planes, prototipos yespecificaciones son más lentos de lo esperado.

El cliente no participa en los ciclos de revisión de los planes. prototipos yespecificaciones, o es incapaz de hacerlo, resultando unos requisitosinestables y la necesidad de realizar unos cambios que consumen tienrpo.

El tiempo de comunicación del cliente (por ejernplo. tiempo para responder a

las preguntas para aclarar los requerimientos) es más lento del esperado.

El cliente insiste en las decisiones técnicas que alargan la planificación.

El cliente intenta controlar el proceso de desarrollo, con lo que el progreso esmás lento de lo esperado.

Los componentes suministrados por ei cliente no son adecuados para el productoque se está desarrollando, por lo que se tiene que hacer un trabajo extra dediseño e integración.

Los componentes suministrados por el cliente tienen poca calidad, por lo quetienen que hacerse trabajos extra de cornprobación, diseño e integración.

Las herramientas de soporte y entornos irnpuestos por el cliente sonincornpatibles, tienen un bajo rendimiento o no funcionan de formaadecuada, con lo que se reduce la productividad.

El cliente no acepta el software entregado, incluso aunque cumpla todas susespec ificaciones.

El cliente piensa en una velocidad de desarrollo que el personal de desarrollo nopuede alcanzar.

((onti núu)


Tabla 5.3. (('t¡n/intutt.ión\

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 loquc hay que añaclir rrn tientpr.r e\tra para ntejorar la calidacl.Los pro"'ecdorcs no se irrtegran cn c-r prol'ccto. con lo que no se alcanza er ni,",eldc rCndilnir'nt() quc se ltcccsilr.

Req uisitos

Los recluisitos se han aclaptado. pero continúan cambiandcl.Los requisitos llo sc han deflnido correctaurcnte, y su reclefinición aurnenta el¡intbito del proyccto.

Se añaden requisitos extra.

Las paftes del proyecto que se no se han especifrcado crararnente consumenrnás tientpo dcl esperado.

Producfo

Los módulos propensos a tener errores necesitan rnás trabajo cre comprobación.diseño e implementación.

Una calidad no aceptable rcquiere de un trabajo de comprobación. diseño eirnplementación supcrior al esperaclo.

utiliz,ar lo irltinro en infb'nática ararga ra planificación de forma irnpredecible.El desarrollo de lunciones sofiwarc erróneas r.equiere vorver a diseñarlas y a

imp ler-nentarlas.

El desarrollo de una interfaz de usuario inadecuada requiere'or'er a diseñarray a implernentarla.

El desarrollo de funciones softr'vare innecesarias alarga ra planificación,Alcanzar el ámbito der procructo o ras restricciones de .,,elociclad requiere nrá.tiempo del espcrado. incruvendo el tiempo para'orver a diseñar

" i-pr.,n.nt'

unos requisitos rígidos de compatibilidaci con el sistema existente necesitan untrabajo extra de comprobación. diseño e irnplernentación.

Los requisitos para crear intcrfaces con otros sistemas. otros sistemas cornprejo:.u otros slstemas que no están bajo er control del equipo de desarr.llo suponei-.un diseño, irnplementación y prueba no p¡evrstos.

El requisito de trabajar con varios sistemas operativos necesita rnás tiempo deresperado.

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 organización consume

tnás tier.npo del esperado.


Tabla 5.3. (Conrinuutión)

Depender dc una tecnología quc aún está en f'ase de desarlollo alarga laplanificación.

Fuerzas meyores

El producto depende de las nonnatiras del gobierno. quc pueden carnbiar deforma inesperada.

El producto depende dc cstándares técnicos ¡rror,'isionalcs. que pueden carnbiarde fonna inesperada.

Personal

La contratación tarda r.nás de lo espcrado.

Las tareas prelirninares (por cjcmplo. forrnación. finalización de otrospro-yectos. adquisición de licencias) no se han cornpletado a tientpo.

La falta cle relaciones entre la dirección ¡' el equipo de desarrollo ralentiza latoma de decisiones.

Los nrierubros de I equipo no se irnplican en el provecto. y por lo tanto noalcanzan el nivcl de rendimiento deseado.

La falta de rnotivación y de moral reduce la productividad.

La f-alta de la especialización necesaria aumenta los def'ectos 1' la necesidad derepetir el trabajo.

El personal neccsita un tienrpo r-xtla para acostulnbrarse a trabajar conherramientas cl entornos nuevos.

El personal necesita un tieurpo extra para acostul-nbrarse a trabajar conhardrvare nuevo.

El personal necesita un ticrtrpo !-\trír fara aplendel un lenguaje deprogran-ración nuevo.

El personal contratado abandona el proyecto antes de su finalización.

Alguien dc la plantilla abandona el prol'ecto antes de su finalización.

La incorporación de nuevo pelsonal de desarrollo al prol,ecto ya avanzado. y elaprendizaje v conlunicaciones c\tra irnprer istas rcducen la eficiencia de losrnicnrbros dcl equipo e\istentes.

Los uriernbros del equipo no trabajan bicn juntos.

Los conflictos entre los mier-nbros del equipo conducen a problenras cn lacolnunic¿rción y en el diseño. crrores en la intcrfaz y tener que repetiralgunos trabajos.

Los miernbros problemáticos de un equipo no son apartados. influyenclcrnegativamente en la rnotir,'ación de I rcsto del equipo.

Las personas más apropiadas para tlabajar en el prcll,ecto no están disponibles.

(LIttl¡nt!Lt\


Tabla 5.3. (Contintnt'ión)

Las personas más apropiadas para trabajar en el proyecto están disponibles,pero no se pueden incorporar por razones políticas o de otro tipo.

Se necesitan personas para el proyecto con habilidades muy especificas y no seencuentran.

Las personas clave sólo están 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 ntás lento de lo esperado.

El sabotaje por parte de la dirección del proyecto deriva en una planificaciónineflciente e inefectrva.

El sabotaje por parte del personal técnico cleriva en una pérdida de trabajo o enun trabajo de poca calidad, por Io que hay que repetir algunos trabajos.

Diseño e implementación

un diseño demasiado sencillo no cubre las cuestiones principales, con l. quehay que volver a diseñar e implementar.

Un diseño demasiado complejo exige tener en cuenta cornplicacionesinnecesarias e improductivas en la implerr-rentación.

Un mal diseño implica volver a diseñar e implernentar.

La utilización de metodologías desconocidas deri'a en un período extra defbrmación y tener que volver atrás para corregir los errores inicialescometidos en la metodología.

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 obibliotecas utilizados; el personal de desarrollo tiene que utilizar otrasbibliotecas. o crearlas él mismo para conseguir la funcionalidad deseada.

Las bibliotecas de código o clases tienen poca calidad, y generan una cornprobaciónextra, corrección de errores y la repetición de algunos trabajos.

Se ha sobreestimado el ahorro en la planificación derivado del uso deherramientas para mejorar la productividad.

Los componentes desarrollados por separado no se pueden integrar de formasencilla. teniendo que volver a diseñar ¡z repetir algunos trabajos.

Proceso

La burocracia produce un progreso más lento del esperado.

La falta de un seguirniento exacto del progreso hace que se desconozca que elproyecto esté retrasado hasta que está muy avanzado.

(continiru t

Capítulo 5: Gestión de riesgos

Tabla 5.3. (Continuac'ión\

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

Un control de calidad inadecuado hace que los problemas de calidad queafectan a la planificación se conozcan tarde.

La falta de rigor (ignorar los fundamentos y estándares del desarrollo desoftware) conduce a fallos de comunicación, problemas de calidad yrepetición del trabajo. Un consumo de tiempo innecesario.

El exceso de rigor (af'erramiento burocrático a las políticas y estándares desoftware) lleva a gastar más tiempo en gestión del necesario.

La creación de informes de estado a nivel de directiva lleva más tiempo aldesarrollador de lo esperado.

La falta de entusiasmo en la gestión de riesgos irnpide detectar los riesgos másimportantes del proyecto.

La gestión de riesgos del proyecto software consume más tiempo del esperado.

Fucntes: Principles o.f So./twure Engineering trlunogenent (Cilb, l99tt). So/iware Risk Ma-ndgetnent (Boehm, 1989)..1 Manuger's Guitle to Sofiware Engineering (Pressman. 1993 ).Third Il ave Projec't Management (Thontsett. 1993 ) ¡, Assessnent and Cotttt.ol of'SolnvreR¿.iAs (Jones. 1994).

101

5 j Análisis de riesgos

Una vez que haya identificado los riesgos de planificación de su proyecto,el paso siguiente es analizar cada riesgo para determinar su impacto. Puedeutilizar el análisis de riesgos para poder elegir entre varias alternativasde desarrollo, o para gestionar los riesgos asociados con una alternativa queya haya elegido. Con los riesgos en general, esto puede ser difícil, perocuando está interesado en los riesgos de planificación, la estimación esmás sencilla.

Exposición a r¡esgos

Un método útil en el análisis de riesgos es determinar la <exposición a ries-gos) de cada uno de los riesgos que haya identificado. La exposición a

riesgos a menudo se abrevia como (ER) (hay quien la llama <impactodel riesgo>). Una definición de riesgo es <pérdida no esperada>. La ex-posición a riesgos es igual a la probabilidad de pérdida no esperada mul-tiplicada por la magnitud de la pérdida. Por ejemplo, si piensa que la proba-bilidad puede ser del 25 por 100 y puede haber un retraso de cuatro semanas


sobre la duración del proyccto. la erposición al riesgo sería 25 por 100multrplicado por cuatro semanas. es decir, una semana.

Como sólo está interesado en los riesgos de planificación, puede er-pl'esar las pérdidas cn semanas o meses o en otra unidad de tiempo quefhcilite la comparación.

La Tabla 5.4 cs un e.jernplo de cstimación de riesgos de planificaciónque puede crear a partir dcl riesgo. la probabilidad de pérdida, la magni-tucl de la pérdida y la exposición a riesgos.

E,n el ejenplo de estimación dc riesgos de la Tabla 5.4. el proyecto haidentificacio varios riesgos cuya grar.'cdad pucde estar entre I y 20 semanas,

Tabla 5.4. Ejemplo de tabla de estimación de riesgos

Riesgo

Planificación dentasiado optiniista 50ot, 5 2,5

Añadir un reqrLisito para la -501, 20 1"0actualización autornática desde elmainfiarne

Añadir nucvas características desde 35,fn 8 2,8rurarketing (sin conocer las

características cspecificas )

Interfaz del subsistcrna de fbrn.rato 25,'/u 4 1,0de gráficos inestablc

Diseño inadecuado (hay qLre voll'er 15% 15 2,25a discñar)

La aprobación del proyecto rarda 25% ,1 1.0nrás de lo esperaclo

Los recursos no están disponibles 10% 2 0,2en sLl monlento

Los infbrmes de estado a nir,'el de 109'0 I 0. I

clilectir a nccesitrn rnús tiernpoclel prer,isto

El personal contratado se retrasa en 10-20,% ,1 0.4-0,8la entrega del subsisterna encargadode formatear los gráficos

Las nuevas herramientas deprograrnación no producen cl ahorropronletido

probabilidad llagnitud Exposición

dc pérdida de la pérdida a riesgo' (semanas) (semanas l

30o,i, 5 l.-5

Capítulo S: Gestión de riesgos 103

Las probabilidades de que ocurra alguno dc los ricsgos oscilan entrc un5 y un 50 por 100. En un proyecto real tenciría que iclentificar muchosrrás riesgos de los que se muestran en la tabla anterior.

¿,De dónde han salido las probabilidades y la nagnirud de la pérdida?Estos núme.os hay que estimarlos, sin pretender que sean exactos.

Estimación de la magn¡tud de la pérdida

Muchas veces es r¡ás fácil estimar la nragnitud de la pérdicla quc la proba-bilidad. En el ejemplo anterior, podría haber estimado 20 rreses comoel tienrpo que se necesitaría para automatizar las actualizacioncs clesde elmainfiame. o bien podría saber que el proyecto se aprobará el I de febre-ro o el I de marzo, clependicndo del mes en que la comisión revise la pro-puesta dcl proyecto. Si suponc que podría aprobarse el I cle febrero. lamagnitud del riesgo para la aprobación del proyecto sería exactanentcun mes.

En los casos en que la mag'itud de pérdida no es fácll de e stimar direc-tamente, se puede dividir ia pérdida en pérdidas más pequeñas, estirrarlas,y combinar las pérdidas pequeñas eu una estimación cle la pérdicla. pore.¡emplo. si está utihzando tres herramientas cle programación. podría esti-mar la pérdida resultante a partir de las pérdidas que podría generar cadauna de las herramientas. Así podría sumar las pérclidas, y obtencr la esti-mación de una forma más scncilla que la estintación global.

Estimación de la probabilidad de pérdida

Normalmente, la estimación cic la probabiliclad cle pérdida es más subjeti-va que Ia estimación dc ia magnitud de la pérdicla. existiendo muchas téc-nicas para mejorar 1a cxactitud de esta estimación subjetiva. He aquí al-gunas ideas:

' Disponer de la persona que csté más familiarizada con cl slstelnapara que estime la probabilidad de cada riesgo. y luego realizar unarevisión de la estimación.

o Usar técnicas Delphi o de consenso en grupo. Con la técnica Del-phi, cada persona cstima individuahllente cada ricsgo, y luego sediscute o se escribe el origerr de cada estimació'. especialmente enlas que haya nayores diferencias. Continuar con el proceso hastahacer conr,'erger las estimaciones.

¡ Realizar analogias con apuestas: <¿,Aceptarias esta apuesta? Si losrecLlrsos están disponibles en su momento ganas 125 dólares. Sino lo están, yo gano 100 dólares.> Ajustar la apuesta hasta que losdos apostantes estén igual de seguros. La probabilidail de nesgo


REFERENCIACRUZADA

Para mayorinformac¡ón sobre lossrgnos mas o menos

en la planificación,consulte "Estilos depresentación de una

estimación", en laSección 8.3.

sería la apuesta menor dividida entre la cantidad total en juego. En

el ejemplo, la probabilidad de que 1os recursos no estén disponi-bles en su momento podría ser 100 / (100 + 125)- 44 por 100.

o Utilice la <calibración mediante adjetivos>. Primero cada persona

elige el nivel de riesgo entre una serie de frases como muy probable,bastante probable, probable, improbable, muy improbable. Después

se convierte cada una de las estimaciones verbales a estimacionescuantitativas (Boehm, I 989).

Retraso total del proyecto y margen de retraso

Un efecto colateral interesante de calcular los números de exposición a

riesgos mostrados en la Tabla 5.4 es el hecho de que, en términos estadís-

ticos, estas exposiciones a riesgos son <valores esperados>. El riesgo de un

diseño no adecuado le podría 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 es-

perar no perder ninguna semana. Estadísticamente hablando, la cantidadque espera perder es la probabilidad por el tamaño, o 15 por 100 veces

quince semanas. En este ejemplo <esperaría> perder 2,25 semanas. Comosólo estamos hablando de riesgos en la planificación, puede sumar todas

las exposiciones a riesgos para obtener el retraso total del proyecto. Asi el

retraso si no se hiciese ninguna gestión de riesgos estaría 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 sema-

nas, necesitaríamos hacer una gestión de riesgos activa.

¿Se podría cambiar la planificación para reflejar el retraso espe-

rado'l Creo que sí. Vuelva a calcular la exposición a riesgos total después

de haber realizado el plan de gestión de riesgos, y luego añádalo a su pla-

nificación con-Io un margen. Esto le dará un margen de retraso más claroque la regla elemental que utilizan algunas personas para ajustar sus plani-ficaciones. Otra manera sería crear una planificación con signos más omenos para cada riesgo, y ajustar la planificación cuando se produzca un

riesgo.

5.4. Prionzación de riesgos

Una vez que haya creado la lista de los riesgos de la planificación, el

paso siguiente es priorizar los riesgos de forma que sepa dónde centrar

el esfuerzo para la gestión de riesgos. Los proyectos gastan generalmente


. ¿, 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 más importante'

,,):,]),;l Una |ez-más, el trabajo es más fácil si sólo considera 1os riesgos de

- ,i,','r'')|, planificación que si se centra en todos los tipos de riesgos' Una l'ez que

-.4ue tos iraya calculado la exposición a riesgos multiplica¡do la probabilidad de

-' 'c/? /r¡s pe;dida por la magniiud de la pérdida, ordene 1os riesgos según la exposi-

';:li::;l .iOn u .iesgos en su tabla de estimación de riesgos' y vea cómo ha queda-

.,,,l,{,r. do. La labta S.S es un ejemplo de una tabla de estimación de riesgos

: l)rucker ordenada por la exposición a riesgos'

Tabla 5.5. Eiempto de tabla de estimación de riesgos priorizada

RiesgoProba.birid,ad r;tf

-rXl;[, t:T::'J:"oe Peroloa (semanas) (scmanas)

Añadir nuevas caracteristlcasdesde marketing (sin conocer las

características esPecíficas)

Planifi cación demasiado

optrmista

Diseño inadecuado (haY que

volver a diseñar)

Las nuevas herramientas de

progran.ración no Producen el

ahorro prometido

Añadir un requisito Para la

actualización automática desde

el mainframe

Interfaz del subsistema de

formato de gráficos inestable

La aprobación del ProYccto tarda

rnás de lo esperado

El personal contratado se retrasa

en la entrega del subsistema

encargado de fbrmatear los

gráficos

Los recursos no están disPoniblesen su Ílomento

Los infbrmes a nivel de directivanecesitan rnás tiernpo del previsto

35%

50%

l5'l/ó

30%

5u.:i

25'k

25%

t0-209/ó

109i,

10%

2.5

))\

15

1.0

1.0

1.0

0.4-0.E

2.8

l5

20

) 0.2

0.1


E,sta forma de ordenación de la tabla genera una lista de los liescosordenada aproximadamente por prioridades. Si consigue controlar los cincoprimeros riesgos de la tabla, cabría esperar una reducción de 9,8 semanasen el retraso total esperado de la planificación. Si se decidiera a controlarlos cinco últimos riesgos de la tabla sólo podría esperar una reducciónenfre 2,J y 3,1 semanas sobre cl retraso total esperado del proyecto. Entérmino medio, sería mejor concentrar el esfuerzo en el control de loscinco primeros riesgos de la lista.

La razón por la que la lista sólo está ordenada <aproximadamente) se

debe a que quizá podría dcscar priorizar algunos de los riesgos que pro-ducirían una pérdida grande, independiententente del lugar que ocLrpaseÍlen la tabla. E,n la Tabla 5.5, el riesgo <Añadir el rcqtrisito de actualizaciónautomática desde el mainframe> es aproximadamente del 5 por 100" peroproduciría un retraso de 20 semanas. que es mayor que el de cualquierotro tipo de riesgo. Si se produjese un retraso de 20 semanas. podría su-poner un desastre para su proyecto, por lo que debería gestionar los rres-gos de esa magnitud para asegurar que no ocurriese ninguno de ellos. in-cluso aunque tengan una probabilidad pequeña de ocurrencia.

Asimismo, puede querer priorizar un grupo de riesgos encadenadosen lugar de priorizar cada uno de los riesgos inclividualmente. Por ejem-plo, la inestabilidad de la interfaz del subsistema de formato de gráficoses un riesgo, y también es un riesgo 1a fecha en la que el personal contra-tado entregue el producto. El riesgo combinado que aparece al utilizarpersonal contratado y tener el código desarrollado por ellos para crearuna interfaz que parece inestable, es un poco mayor que si se consideracada uno de los riesgos de forma individual.

La ordenación de prioridades sólo es aproximada por otra razónlos números que se han utilizado para crear la tabla son estimac'itnt.-,Así pues. la exactitud de los números de la exposición a riesgos y el or.-

den de las prioridades depende de la precisión de las estimaciones cl.'

la probabilidad y de la magnitud del riesgo. La conversión de estima-ciones en un valor de exposición a riesgos ajustado a la realidad sólo pue-

de hacerse si la priorización es precisa. Como la priorización sólo pued;llegar a ser tan exacta como la entrada. y como 1a entrada es algo subjetr-vo, la priorización también es algo subjetivo. Así. su capacidad de valon-.-

ción es una parte necesaria para cada uno de los aspectos de la gestión d-'

nesgos.Una vez que haya identificado cada uno de los elementos de alto rie.-

go, también es importante realizar una priorización de riesgos para r--formar de los riesgos que se pueden ignorar. No nos preocuparenr. -

de la gestión de pequeños riesgos que además tengan una probabilidad c.aparición pequeña. En el ejemplo anterior podría gastar más tiempo en -,

gestión del riesgo por que los recursos no estén disponibles en su mome:'-to que si realmente no estuviesen disponibles en su momento. La plio: -


zación de riesgos es un proceso crítico en el que hay que tener cuidado deno dedicar todo el esfuerzo a la sestión de riessos en si.

Control de riesgos

Una vez que haya identificado los riesgos de su proyecto, analizado susprobabilidades y magnitudes. y los haya priorizado. está preparado paracontrolarlos. Esta sección describe los tres aspectos del control de riesgos:planificación de la gestión de riesgos, resolución de riesgos y monitoriza-ción de riesgos.

Planificación de la gestión de riesgosEl objetrvo de la planificación de la gestión de riesgos es desarrollar unplan que controle cada uno de los riesgos de prioridad alta identificadosen las actividades anteriores. El plan de gestión de riesgos puede ser tansencillo colno un párrafo para cada riesgo, describiendo quién, qué, cuán-do y córno sc gestiona cada uno de los riesgos. También debería contenerprevisiones para la monitorización de riesgos, descartando los riesgos quese han resuelto e identificando los riesgos que aparecen.

Resolución de riesgosLa resolución de un riesgo concreto depende mucho del riesgo específi-co. Los métodos que controlan el riesgo de un diseño inadecuado no se

adaptan bien ai riesgo de que su equipo sea expulsado de sus oficrnas.Supongamos que está encargado de la contratación y está preocupado

por los riesgos de la creación de un diseño inadecuado en un área nuevapara usted y que su despacho va a ser cedido a otro grupo de trabajo de laempresa. A continuación se describen una serie de métodos para tratar losriesgos mediante ejemplos relacionados con los riesgos del diseño y dellugar de trabajo.

Evite el riesgo. No realice actividades arriesgadas. Por ejemplo, tomeresponsabilidades en la mayor parte del diseño del sistema, pero no en laspartes que no conozca. En cuanto al problema del lugar de trabajo, nego-cie con el grupo que pretende desplazarlo de su lugar de trabajo y con-vénzalos para que no lo trasladen.

Traslade el riesgo de una parte del s¡stema a otra. A veces lo quees 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 rela-ciones públicas: lmagine que tiene que diseñar una parte del sistema en-


cargada al resto del equipo" que va a diseñar una parte con la que no esr-familiarizado. O podría hacer que le revisasen y aprobasen su diseño, trasl¡-dándoles las responsabilidades. En el caso del espacio de trabajo, dispo-ner de otro grupo cuya planilicación menos crítica permita cambiar ..

espacio en lugar de en el suyo. o esperar a que el sistema esté preparaclcpara el traslado.

En general, aparte el riesgo del camino crítico. Planifique el proyectcde forma que si ocurre nn riesgo, el proyecto completo no se retrase.

Consiga información acerca del riesgo. Si no conoce el auténtic.peligro del riesgo, averígüelo. Por ejemplo, desarrolle un prototipo par.comprobar la viabilidad de su alternativa de diseño. Localice un asescr:.

que evalúe su diseño. Utilice la planificación de recursos para ver si pu,-.-

de permanecer cn su lugar de trabajo mientras dure el proyecto.

Elimine el origen del riesgo. Si el drseño de una parte del sistcma e >

dcmasiado arriesgado, cambie la parte del sisterna a un proyecto de inr esrr-gación y climínelo de la versión que está desarrollando. Intente convence:'al grupo de trabajo que trata de ocupar su lugar de trabajo de que utiliceotro espacio en donde puedan estar todosjuntos. U obtenga una confirma-ción del grupo de planificación de infraestructuras para quc le dejen per-manecer en su despacho mientras dure el proyecto.

Asuma el riesgo. Acepte que el riesgo puede ocurrir, pero no prcu\jdemasiado en ello. Si las consecuencias son pequeñas y el esfuerzo qriise requicre para evitarlo es mucho, hacer caso omiso puede ser la rne¡t:estrategia. Simplemente acepte las consecuencias de un diseño inadecua-do o de que lo echen de su despacho.

Comunique el riesgo. Haga saber al personal de la dirección y de mar'-keting y a los clientes la presencia del riesgo y sus consecuencias. Intentcsuavizar el susto que se llevarán 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 resolverloBusque recursos extra para comprobar la parte del sistema con el diserioque le preocupa! y prepare un tiempo extra para corregir los problemasPlanifique con antelación el traslado de su despacho para evitar proble-mas: planifique la mudanza para un sábado por la noche para evitar mo-lestias; y busque personal temporal para facilitar las tareas de empaquetar.y desempaquetar.

Recuerde el riesgo. Cree una colección de planes dc gestión de ries-gos que pueda utilizar en proyectos futuros.

Para ilustra'la forma cn quc puecle c.ntrolar algunos clc est.s r.icsgos.Ia Tabla 5.6 lista los mótodos cie co'trol de los ricsgos r.uás conlures cn laplaniflcac ión.

Tabla 5.6. Métodos de control de losplanif icación


nesgos más habituales en

Riesgo Ntétodos de control Dónde encontrar nlásinfbrmación

|. C'ambio clc

prcstacioncs

2. Requerrnrientossupo'fluos npcrsonal dc

dcsan'ollcrnreticuloso

-1. Recortc de lacal idad

.1. Planrflcacióndemasiado optintista

Uso cle telcnicasofrcntadas al cliente.

Uso dc tócnicas clcclcsalrollo incrcr-ncntal.

( ontrole cl conjunttr de

1-r'cstac ioncs.

Diseño para cl cambio.

Filtrado dercc¡uc-rinr icntos.

Dcsarrollo con velltanastcnrpora I cs.

(-ontrol clel conjunto cic

prcstac i oncs.

Uso dc cntrega porctapa s.

l-so clc ¡tlototrposdcsechab I e s.

Di ser-io por plan i ficaci(rn

Deje ticr.npo a Ias

actir idades dcl controlde calidud v pfestcatención a las bascs delcontrol de calidad.

Utilización clc r ¿rrias

tócn icas de estim¿rci irn.r arios cstintaclores r,hcrranticntas clc

estirnacirin.

C'apítulo I 0.,<Desar.rollcroricntado al clientc>r.

( rrpitult' ?. ., l)lallifle le iondel ciclo cle vid¿r>.

Capítulo 1.1. <Conrrol clclconjunto de plestaciones>.

C apitulo I c). <rl)iscño parael ca'' bio,r.

,<Filtrado cle

rcquerimientosr. cn l¿r

Sccción l-1. I .

Capítulo 19. << Dcsarrollocon \ elrtanas tertrltorales>.

CapitLrlo l-{. ((Control clel

conlunto de pre.slaciones>>.

Capíttrlo i6. ((Entrc0a porctapirs). r' Secci(rn 7.6.,,llntrega p0r etapasD.

( l¡ittrltr .i\. ..p¡1r¡o1t¡r1rr

dcsec hab I es >.

Sccción 7.7. <Diseño porp lan il icac i(rn >,.

Seccirin -1.3. <lJascs delcontrol de calidacl>r.

C'apítulo 8. < Estirtracionr


Tabla 5.6. ((-t¡tttinuutiónl

Ricsgo \létodos de control Dónde encontrar másinformación

.1. Planillcaciin...(tt¡nfittttucii¡ttI

5. Diseño inadecuadt'r

Síndrome de lapanacea

Dcsarro lloorientado a lainr,esti-gac ión

Utilizacitin de

llegocl¡clC)lrcscon\ enlcntcs.

Discño plrap lanifi cac ión.

Uso de tercnicas de

cicsarrollo incrcmcntal.

Tcncr tiernpo snflcicntcpara Llna actir iclad cle

diseño 1" planificacióne.rplíc itos.

Tcner inspeccioncs dc

cliscño.

Ser escóptico sobre losplobler.nas clc

productir iclad.

C onflglrrar un proqranracle medidas dc sollw'are.

Confleurar un erupo clc

herratricntas de sofin,arc

No intente inr estigar vnrarirnizar la r,clocidaddc dcsarrollo al misnrotlelrpo.

Utilice un ciclo clc vidaorientaclo al riesgo.

Gcstione los riesgos conatenc iólr.

Personal con talento.

Sccción t).2. <Disluinucióncle- Ia presitin de

planificación>.

Sección 7.7. <Diseño parap I an i fi cac i (rrr >.

( it¡ítulo -. ,, Pllnrfre rrcrirn

del ciclo dc vida>.

( rp itu lo 7. ., PII n i l'iclc rtlndci ciclo dc r ida>. v,<Discño>. en Secci(in .1.:,

<lnspecciones>. e-n

Sección .1.-i. 1' resurnenen Capítulo 23.< I t-tspcccionc-s>>.

Sccción I 5.5. <Sindronr.'de la panacea>.

(iapitulo 26. <Medidas,'

CapítLrlo 15.

<Hcrrarnicntas paraattr.ncr-ltar l¿t

productir idad>.

,<Desarrollo oric-ntaclo .,

inrestigación>. en laSeccrón 3.i.

C'apítulo 7. <Planlfi,:.,,del ciclo de vicla,,.

Este capitulo.

Capítulo 12. <EqLri¡trabajo>. 1, Capíttr1,, :

(EstructLrra dcl cc1L, "

8. Personal mccliocre

Capítulo 5: Gestión de riesqos f11

Tabla 5.6. lCorttitttrut.íórt)

Riesgo \Iétodos de control Dónde encontrar másinformación

Pcrsonal. ..

It ottI ittuuc ión I

t). Problelltas cc-rn

el ¡re-rsonalcontrataclo

10. Problerras entr.ccl ¡relsonal dcdesarrollo I'elc lien te

C'ontratar y planificar losn-lie.lltbros clavc delequipo nrucho antes dcquc conrience clpfo)'ecto.

Preparlción.

Deflnición dcl equipo.

Pedir leferencias.

Estimar la ca¡racidad clelpcrsonal contfatado antesdc contratarlo.

Tcncr bucnas relacionescon el personalcontratado.

Utilizar las técnicasorieltt¿rdas al cl icnte-.

Capítulo 12. <Equipo detrrrbajo,,. r (lpirrrlo 13.<<[stnrctura del equi¡tor,.

Capítulo 12. <Equipo clctrubrio,,. y ( rrpítulo 13.<<Estructura del equipor>.

Capítulo 12. <Ecluipo detrabajori. y Capítulo 13.,, Fstruclul.u rlcl equipo,,.

Capítulo 28. <Desarrolloe.\ te rn or.

Capítulo 28. < Dcsarrollt,ex tef no)).

C'apítulo 28. <Desarrollcrcxtcrno).

C'apitulo I 0. <Desarrolloonentado al clientc>

\ys4-

""1É4 ['["

Monitorizac¡ón de riesgosLa l'icia cn cl n'undo clel softu'arc seria nrás fácir si los riesgos apareclc-sen dcspués de que havarrros desarrolracro planes para tratalos. pcro losriesgos aparecer l" desaparece'r cn er crcsar-roilo crer proyccto. por lo quese neccsrta ura rroritorización de riesgos para colxprobar cómo progresael control cle un riesgo e icrentifrcar ciiro apareccn lcls nue',os riesgos.

Lista de los 10 riesgos princ¡pates

una de las herramientas.ur¿is potcntes para ra rnonitorización de riesgoses la utilización cle urra lista de <<Los ló ricsgos, creacla por uno mismo.La.l is.ta dc los l0 riesgos urás inrportartcs contienc la posición crcl riesgoer la lista. su posición a'terior. er núr'rero cie'eces quc ha aparecido en la


lista' ¡" Lln rcsltlrell c1c l¿ts actttaciorles qltc ¡'a sc han llci'ado a cabo clestl¡

la últinta reyisión. La Tabla 5.7 sigr-riente muestra una lista dc ejcrnpl

de los l0 riesgos PrinciPalcs'

Tabla 5.7. Eiempto de una tista de "Los 10 ilesgos principales'

E stasenla n a

Scmanapasada

Scmanasen lista

RiesgoProgreso de la

resolución del ricsgo

Canrbio de

¡rrcstac ioncs

Discño ittaclecuaclo.

se ncccsita volrcr a

di scñar.

Rcsponsable de

pruebas ttt'rencontracitl.

lnestabilidad cle la

rntcrl-az dclsr.rbsisteuta dc

fbl'mato de griificos

Entf!-gil con retraso

clel subsistcma dc

tilnnato cic grirfi cils

encargado.

Retl'aso ett l¿r

entrega de las

hcrrarrientas de

cle sarrollo.

Utilizar tócnica cle

eutrega por etap¡s:explicación de la

técnica al Pe'rstlllal clr

ttt¿rrketing -Y usuaritl'fl nales.

Discño cn t-nal'cha

lclentificaciórl r'

selecc ión de- tevi sor."

expertos.

Ote rta dc tt'aba1o a tL:

cancl idatt'r adccuaclo.

estalrtos a la cs¡rcra.

lrlltrir i.lht)rll cl (ll\ell

clc- la intcrfaz clc

ttrmato de grhficos:no sc ha terlnitladtlel diseño.

Negociar lacooldin¿ición de

contratados exPerto:Petici(rn al contratatlcle qrtc dcsigne un

coordinador oficial:tocla\ ía no ha

lespondido.

tlan llegado 5 de ln:7 hcrramicntas.El gnrpo dc

adquisicitin de

hert'allretrtas na

inlbrmado sobrc la

neccsidad int-tlecllatlt

clcl rcsto dc las

herratnicntas.

Capitulo 5: Gestión de ilesgos 113

Tabla 5.7. lContinttutión\

Esta Scnranasemana pasada

Semanasen lista

Riesgo Progreso de laresolución del ricsgo

l0

I iclo de lcr isioncle la clirecciiltlento.

C'iclo dc rctisi(rndcl cliente lcnto.

Plan ifl cac itind crn¿rs ia d cr

optimist¡.

Arjaciir el lequisitode la actualrzaciór-rautonr¿rtic¿r dcsde clnr¿rinfl'anrc.

El rcsponsable dediscrio prc'r'cle

tierrpo danclcr

soporte a Lln

provect() antertor.

En cvaluacitin.

En cr alr-r¡ciirn.

Se h¿r tenrina(lo a

tlcrlrpo el plinrcr hito

Estudio de lar i¡bilidacl de l¡actr-ral ización ntanual\rcr el rie s-{o decanrbio deprestac i ones.

L,l provecto anterrorsc ha trasladacloa ¡\laska.

No tienc ir.nportanciit cl hecho dc qr,re la lista cle los l0 riesgos princi-pales contenga exactamcnte l0 riesgris. Cor.r.ro se lrluestra en cl úrltinloclemento dc la lista. tarnbién pLlede coutencr riesgos qLlc hayan salido dcla lista clesde la últirna rcr isión.

En un proyecto cle dcsarrollo rápido. el adnlinistrador del proyecto ),cl-ief-e del administrador del pfoyecto cleben rer.isar semanahrentc la listade los 10 ricsgos principales. La nrayor utilidad cle la lista de los l0 ries-

-eos principalcs es qr.re fucrza a la rcvisión periódica de los riesgos v leinfoma de los cambios dc posición que ha habido según su importancia.

Comprobaciones intermedias

Aunque la lista dc los l0 ries-qos principales quizá sea la rne.jor fo'rrapara la rnonitorizaciiin dc riesgos, uu proyccto acelerado también cleberí¿rincluir cor.nprobaciones intern.ledias durante todo el proyecto. Muchosrcsponsables del proyecto espcran al flnal para hacel la conrprobación.Esto nos podría bencflciarpara el prórimo proyecto. pcro no serr,irá cuandoreall.ncntc lo nccesitamos cu el trrroyecto actr.ral. Para una urayor cf-ectiii-


clad" rcalicc cotrrprobacioncs intcrrredias a pequcña cscala despuós 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 planific¿tción. Al igual que las re"isiones y las comprobacic'lncs rurt-narias" se dcbería tcncr una persolla cuyo traba.jo sca cl de abogaclo ti.cliablo. bttscar todas l¿rs razones que hagan que cl provccto fhlie. En pr.,-yectos grandcs (ntás de 50 pcrsonas). el trabi¡o dcl encargado c1e rrc:g,,pucde ocupar ttldo su tiertt¡ttt. Iin prol,ectos r-r.uis pcqr-rcños. puede oSr!n.:a otra persona clue tcltsa otras fur.rciones cn el ¡troyccto para qr-rc rea1i..este papel cuanclo sc¿r neccsario. Por las razones psicológicas urcnciolt,.-c'las. la persona clesignacla no cleberia ser cl aclministrador del provec¡c

5.6. Riesgo, alto riesgo y azar

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

titrito t¡ttt'n?( (:.\¡tu¡ilo.\ purLl

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

¿ tt tlat i.s it¡ tt c.tentpre.:uriuIe.s. Es

.sol¡re totlt¡ el ti¡to tlt,riesgo. Pot' ejent¡tlo.

,.c.s lu clu.sc det't r s g( ) q It( ¡tt ttl ettt o.tperntitir', t¡ lu t lu.sc

dc rre.tgo qu( no

¡tod a nt o.s pcrntí f i r'.)

0 r'.e.s utt ric.\go lL01

e.\lruño paro l¿ul

espetiulrnenteintportunt( qu(

tto no.s ¡tod<'ttto.;pt't'rrtitir t'l lujo

de tc¡ntur.i n d cp e 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 rápido. ¿llgunos provcctos son arriesgados. algr,rnos s

nruy arriesgacios y otros son irrprcr.isiblcs. Es clifícil encontrar algirrr pr

yccto que no intpliqLrc ningLrn riesgo..v los proyectos que son sólo ((ni--gos)) soll los más apropiados para alcanzar la r.uáxima velocidad de cie¡.,-rrollo. Estos ¡rroyectos facilitan la eilciencia y consigucn que la línea de:..,el inicio del proyecto hasta el flnal sea rccta. El dcsarrollo rapido, qLrc:es necesariancnte fácil de alcanzal'. es mcjor encargarlo ii uha pcrstrr'que domine las estrategias y prácticas qLrc se erplican en este librtt.

L,l riesgo alto y cl clesarrollo rápido foman una contbinación ntencompatiblc. Los riesgos tiendcn a prolongar los planes de dcsarrollr..los riesgos altos tienden a prolongarlos más. Pero a veces la realiciacl c:: -

presarial le obliga a eucargarse dc un plan cle dcsarrollo ar.nbicioso. inclLi-cuando un proyecto implique ntuchos ricsgos (r'agucdad en los rcqursrt, ,

personal no cualilicado. áreas dcsconocidas. elcmcntos de irtr,esti-rrat r

cluros. o todos los anteriorcs).Si se ve obligado a encargarse de un plan ambicioso en estas cir.cur .-

tancias. infórmcse de la naturaleza del compromiso. Con dos o trcs ar.r-,,-cic alto ricsgo. inclusrr sLrs rrre-jorcs estirnrrciones cn la planificación p;:.-derán su sentido. Asegúrrcse 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 tiertrpoquc están esperando. En cstos casos. una gestión de riesgos no sólo actt.sino también enórgica le ayudará a resolr.er n.rejor una situación coulf t. -

metida.

Capítulo 5: Gestión de ilesgos 115

A1 flnal dc la escala de riesgos. algurros proyectos sc planifican tanagrcsivamente que caen cn el azar. se parecen r.nás a la corr-rpra de unnúmero de lotería quc a una decisión calculada. Sobre r-rn tercio de losproycctos tlencn una combinación intposible de planificaciones, corrjun-tos de características y rccursos. establecida antes de entpczar. En estascircunstancias. no hay ningún estímulo a la hora de rcalizar una gcstiónde riesgos. porqlre antes de que el proyecto contience hay un 100 por 100 deprobabilidadcs de f'allo. Sino hay posibilidadcs de ajustar las planificacio-nes nrediante alguna de las técnicas de gcstión de riesgos, sería razonableapostar 1.000 a 1 por cl desarrollo con la técnica dc codificar y corrcgir.E,stos proyectos, que necesitan la ve locidad de desarrollo máxima, paradó-jicamente se convierten cn los proyectos quc probablclnente tiren por lavcntana las técnicas contrastadas orientadas a la velocidad.

Los resultados son inevitables. La apuesta no ha funcionado. y cl pro-yccto sc ha entregado tarde. rl.tucho más tarde quc si se hubiesen utilizadoricsgos 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'lCreo que no. Tenga cuidado con el nivel de riesgo de su proyecto e intcn-te mantenerlo en una categoría de <riesgo> o <a1to riesgo>.

Ejemplo 5.2. Gestión de riesgos sistemática

La versión 3.0 de Square-Calc ha sido un desastre, superando su planifica-ción en un 50 por 100. Eddie decidió encargarse dcl proyccto de la versión3.-5, y esperaba hacerlo mejor de lo de lo hizo el responsable anterior.

<Colno ya sabéis, Square-Calc 3.0 no siguió mu¡, bien la planificaciónprevista), contó al equipo de desarrollo en la primera reunión de planifi-cación. <Estaba previsto realizarlo en 10 meses. y tardti 15. Necesitamoshacerlo meior. Tenentos cuatro meses para realizar algunas mejoras, ypienso que tenemos tiempo suf,rciente para poder realizar este trabajo. Lagestión de riesgos va a tener una de las rnayores prioridades. Lo primeroque voy a hacer es nombrar un encargado de riesgos, alguien que se dedi-que a buscar todas 1as cosas que podrían ir mal en este proyecto. ¿,Hayalgún interesado?>

Jili había trabajado en el último proyecto mucho más duro de lo queella queria. y cstaba dispuesta a evitar que le ocurriera de nuevo, por loque dijo: <Yo estoy dispuesta. ¿Qué tengo que hacer?>

<Lo prirnero que tienes que hacer es crear una lista de los riesgos co-nocidos>, le d¡o Eddie. <Quiero que te reúnas esta mañana con cada unade las personas del equipo de desarrollo y que encontréis cuáles son losriesgos que se conocen. y lueeo quiero que te reúnas conmigo csta tal'de.Estudiaremos los riesgos y partiremos de ese estudio.>

l( ()lllUtUU \

116 Desarrollo y gestión de proyectos informátícos

Esa tarde, Eddie y Jill se reunieron en el despacho de Eddie. <Tod¡.incluida vo misma, pensanlos qr"re el mayorriesgo es el código de Squar:.Calc 3.0. Es una auténtica chapuza>, dijo Jill. <Ninguno de nosotr,-.quiere realizal rnodificaeioncs irrrportanrcs. y hay algunos rnódulo. c.:nadie se atreve a tocar.

El siguiente riesgo imporrante es la planiticación de la creación c-manual 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 versión 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 más ir:-.-portantes.

<De acuerdo. quiero qr.re preparéis un plan de gestión de riesgos pa:.-.

los riesgos principales>, cljo Ecldie. Le comentó a ella la idea de los 10 ries-gos principalcs y dijo que quería revisar semanalmente con el equipo ,.

lista de los l0 riesgos principales.Para la gestión del riesgo del código anterior, decidió analizar su ba::

de datos de errores para cltantos módulos del sistema realmente tendian _

producir errores. Asignaron un mes de la planificación de los cuatro mese:a dedicarse a volver a escribir el código de los módulos más propensos :errores.

Para el riesgo de la creación del manual de usuario, decidieron ci¡-sarrollar un prototipo desechable de interfaz de usuario que utilizara ,--

nisma interiaz que el código que estaban escribielldo. No permitirían o.-f'erencias externas con el prototipo. También incluirían un inforrne de ,.,

documentación de usuario en las reuniones semanales de gestión de rie.-gos, que les ayudaría a sincronizarse con el trabajo de la creación de ,.docullrentación.

Para el riesgo de los cambios en los requerirnientos. Eddie se compro-lnetió a hablar con alguien del departan,ento de rnarketing. <Sé que su ob,-jetivo principal es tener el producto a tiempo>, dijo. <Necesitamos recul:)i-rar la confianza del cliente después de los problemas de planificación de i"versión 3.0. Les explicaré la importancia de la definición clara de objeti-vos, y pienso que cortarán los carnbios en los requisitos.> También invitó ;,

Carlos, del Departamento de Marketing, a asistir a las reuniones de ries-gos, pensando que si alguien de nrarketing comprendía todos los riesgos ;los que se enfientaban, rnarketing podría evitar que se cayera en nue\,oinesgos.

Durante las cuatro semanas siguientes, la identificación y sustituciónde los módulos propensos a fallos marcharon según lo previsto. Se vio queel 5 por 100 de los módulos causaban un 50 por 100 de errores. Fueroncapaces de volver a diseñarlos e implementarlos cuidadosamente. Some-tieron cada módulo a una revisión durante cada etapa, v lo realizaron en el


tiempo previsto, lo que hizo que se sintieran bien, ya que el código de laversión anterior podría soportar el resto de las modificaciones que se te-nian que realizar para crear la versión 3.5.

En la ¡eunión de ríesgos semanal de la sexta semana, Jill apareció conuna tarea nueva. <<Como ya sabéis, he estado supervisando algunos de losriesgos de menor prioridad además de la supervisión de los riesgos másimpor'tantes, y uno de ellos es más importante de 1o que se pensaba. Bob haestado trabajando intentando optimizar algunas de las funciones de cálculocientífico, y me dijo hace unas semanas que no estaba seguro de cubrir lasespecifi caciones previstas. Aparentemente, había investigado los mejoresalgoritmos disponibles, los había implementado, y la$ funciones sólo eranun 50 por 100 más rápidas. Las especificaciones hablaban de una mejoraen la velocidad del 100 por 100. por 1o que Bob está intentando encontr¿rotros algoritmos más rápidos. Le he comentado que coloque un punto de

alerta roja en el plan, para que si no lo realiza en el tiempo previsto, po-damos dar una señal de alerta. Ayer alcanzamos el punto de alerta roja,y Bob dice que aún necesita más tiempo para terminar su trabajo. Bási-camente pienso que como está realizando un trabajo de investigación, nohay forma de predecir el tiempo que va a necesitar.>>

Carlos, del Departamento de Marketing, dijo algo. <He sido uno de losque han apostado por la mejora en la velocidad, y pienso que la cifra del"100 por 100" es flexible. Es más importante terminar el producto a tiem-po que seguir el requerimiento de velocidad al pie de la letra. Al menospodremos demostrar a nuestros clie ntes que somos personas responsables.>

<Eso suena bien>, dijo Eddie. <Pienso que una mejora del 50 por 100en el rendimiento es suficienteo por lo que le diremos a Bob que se dediquea hacer otras tareas. Eso hará que tengamos un riesgo menos del que preocu-parnos.)

Después de esto, aparecieron otras sorpresas. Se produjeron algu-nos cambios pequeños que se pudieron controlar bien. Comparándolo conel último proyecto, éste había sido un poco aburrido, por 1o que nadielo recordaría. Algunas de las personas de marketing intentaron añadrrnuevas características, pero Carlos consideró que 1o importante era el ob-jetivo del plan y así mantuvo las quejas a raya, sin que llegara a escu-charlas el personal de desarrollo. El equipo hizo un buen trabajo y entregóSquare-Calc 3.5 en los cuatro meses previstos.

t cliograf ía adicional

Boehrn, Barry W.. ed.'. Sofiv'are Risk Management. Washington, DC: IEEEComputer Society Press, 1989. E,ste conjunto de trabajos se basa en lapremisa de que los buenos administradores de proyectos son buenosadministradores de riesgos. Boehm ha recopiiado un conjunto de tra-bajos a partir de fuentes técnicas y empresariales. Una de las princi-

1 18 Desarro//o y gestión de proyectos informáficos

pares características de este libro es lacontribución de 70 paginas q...ha realizado el nrismo Boehm. ErLr zo páginas suponen una buei:-inrroducción a ra gestión 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 visiónriesgos que ra que puede encontrar ."Tl'":Hfi:r*:,ir:esrión c'

Boehm, Barry W.: <,Softrvu.. nirt ü*,ces> rEiE sorrnyl;, enero reer, oo fiil:,iJ'fi1:1,:: iti,i.T;:.puntos clave de

, Rick Man,r";;,':;:;ffiH'ff.il: .]3;irffi.;LXjJ. a sori,,,

Jones, Capers: A.s.yessment qnd Contro/ o.f.Softwar.e Risks. Englerit . _cliffs' N'J': yourdon press, lqq+. alliú.o de Jones.r"un .J.pr"n,., .to extraordinario para el tutorial sobreNo comenta .urinuau de la gestión o. 9"t"un de riesgos de Boe h:

cambio, describe con derare zo ¿. i", ,ii:::-,oll::Hi'"11.-i,liT,l; -tes. Jones utlliza un formato "rt¿n¿ur'gravedaddelriesgo,fiecuencia¿.o.,,l3.^cadariesgo.ydescribe

bremas asociados, métodos o. o*".".i"- l;;lliiii"lili""lll;L .vo. Iibros. publicc h o s ct e'

" r,

" ul,, ir' 0".';:;:'J:'.', t i ffi

,r: "bff """rm:fi ; li

:

de la base de datos de JonJs,.on.¿r¿.4.000 proyectos sofni.areGilb, Tom: principle,s .oJ.

Sr¡tror" in-[in]nrirg Maragentenl. Woki::_-ham' Ingraterra: Addisonlw.rr.y, iéáá. pr," Iibro tiene un capir'.que esta especialmente indicado para el tema de la estimación cle r:..._gos' Er método 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 sesjión de riesgos, que puede utilizarpara hacers., ,.: -idea de sj el nivel de riesgo O. ,u proy..to es bajo, medio o alio.

-f-r#fe #ffffiffiffi$

iffiffiffiffiffiffi

#ffiffiffiffiffiffi ffi

$ffi

l

Cuestiones fundamentalespara el desarrollo rápido

Contenido

6.1. ¿,Eriste un modelo úrnico'.'}

6.2. ¿,QLró tipo de dcsarrollo rápido necesita'ló.3. Posibilidatl de tcrnlinal a ticmpo6.4. Pcrccpción y rcalidad6.5. Distribución del ticmpo ernplcado6.6. Equilibno de factorcs de la vclocidad de desarrollo6.1 . Patrón típico de mejora de la planificación6.8. Canlino hacia el desarrollo rápido

Temas relacionados

Estrategia para el desarrollo rápido: Capítulo 2

UNA VEZ QUE HAYA APRENDIDO A EVITAR los errores clásicosy haya asirnilado los fundamentos del desarrollo de softlvarc y la gestiónde riesgos, estará preparado para centrarsc en métodos dc desarrolloorientados a la planificación. El prirner paso en csta dirccción es cont-prender ciertas cuestiones que radican en el núcleo de la máxima r.'elo-cidad de desarrollo.

¿Existe un modelo único?

Para desarrollar el control de un marcapasos usará tócnicas disrintasque para desarrollar un sistema de control de int,entario para cintas devídeo. 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 gestión cle proyectos informáticos

REFERENCiACRUZADA

Para más rnformac ónsobre la

persona ización de losprocesos del software

segun las necesidadesespecificas de los

proyectos. consu te laSección 2.4. ,, ¿Cuál es

la dimensión más¡mportante?.

error h¿rce quc sc picrda urro dc cada 1.000 rrarcapasos. tenclrá serios pr.rr-bler.n¿rs.

Dif crentes provectos ticnen dif'ercntes necesicradcs cle clesarrollo rápi-do. aunque toclos necesiten ser dcsarrollados <tan rápido cono sea posr-ble>>. En tórminos -gencrales. los prodr-rctos ile gran clitusión neccsitan s..:clesarrollados con más cuidacio que los productos con poca difusión. Lt,.productils crry'a fiabiliclad cs importante necesit¿in scr clesarrollaclos ct',:más cuiclaclo que los procluctos cuva fiabilidacl no ticne r.nucha importan-cia. La Fisura 6.1 nruestra algunas cle las variaciclncs en distribución.l'irrbilithLi.

Las qrtraclas cspecíficas cle la cuadrícula son sólo meros cjemplo.Podría scr cliscutible por qLró un controlador de pantalla o un progronc trriurpuestos necesitan scr más flables. o si el software cle autoeclición cl 1..hoias dc cirlculo licnen mayor difirsión. Sc trata de ver que tanto el árr:-brto clc clistribución corro la l-iabilidad necesaria varían arnnlianrcnr;cntre diÍbrgrtes ti¡.ros dc soliri'arc. Un firllo dc- softnare pLrccle acarrc.rlpe!rcliclas de tienrpo. trabajo. clincro o vidas humanas. Algunos rnétoilo.dc ciesarrollo oricntados a la planificación, quc sou perfectalrente acetr-tables cuanclo el tiempo de desarrollo es lo único importante. serían absc-Iutame'te inaccptables cuando hay

'idas humanas dc por nrcclio.

Por otra parte. los métodos cluc pucderr considerarse rápidos / chap¡¡-ceros en ulr slstenra crítico para la rida pucderr resultar demasiado ri-cL.-fosos para una aplicación clc soft'ulare de ncgocios. El desarrollo rápi.:cle soltu'arc dc clistribución linritacla puede constar de cosas qr.re consicler.,-

.F N,4ercado

.= hñri7^ñtal

'tE Mercadoe verltcal

E Personalizado,E interno

Personal

""" . JflSiliTto Hoj" cre cárcuro, . sistema operativo

oái"í,o. a orog'¿nd oard

.:fi:"3: "*,"" ..ff::::""i." "

0"" ';:?:'il: :f,:',i:"".:;,::3::i; .:fi"il3"1:0""?"""'

.:l"Hn:S"":3i:'',0"So'lwa'" o¿'¿ e¡t.. ¡ro ¡¡, , p,oqramo oe -st5terd de..onlro det:::ii:"." .;;¿l;1;5" " o b,il'"i'i! !!g,,os inveccrón de combust br€

u1 vroeoclJo pr gerp.¿.

Prog'¿Td p oqra¡a oeO de segr rrenro _ coti'o oe ¿Oresras a Sonwdre de l¿rzade ¿

de voelas ! oe ca,Terag en e5odcral

[/:, ,ñ, ,, ñ-, IierPo'e¿l

'¡"rá i" .-i.iró

Aplicaciones Sistemas Sistemas críticospara la vida

Fiabitidad requerida

Figura 6.1. Los diferentes tipos de software requieren diferentes tiposde soluciones. Métodos que se consideran rápidos y bastos para un contt:de marcapasos pueden resultar excesivamente rigurosos para un librode cocina interactivo.

Capítulo 6: Cuestiones fundamentales para el desarrollo rápido 123

ríamos <<menudencias) cu sotiu'are cle mayor distribución. Pegue ho¡r. y

no nañalra, algunas piczas que resuell'an el problema dc hov. Mañana po-

dría ser denrasiado tardc: una solución tardía podria rcsultar inúrtil.

Como resultado dc esta tremenda variaciin en los objetivos clc desa-

rrollo. es inrposiblc dccir <Aquí está su solución para desarrollo rápido>sln conocer las circunst¿rncias cspccíficas del caso. L¡t solución corrcctadepcnde de la posición cn quc se encuentre en la gráfica cle la Figura 6.1.

Muchos productos no eucaiau claranrente er.r las categorías de la figura. ylos prodr-rctos varían tarnbién en otras característlcas clistintas clel grado

de flabilidad y el án-rbito dc distribución. Esto implica qLre la mavorí¿r dc

personas tendrán quc llcrsonalizar una solnción par¿r sLl propia situación.Como muestra la Figur¿r 6.2. no eriste un nroclclo único.

¿Qué tipo de desarrollo rápido neces¡ta?

El tcrra plimordial r.nás iurportantc rclacionado ccln el clcsalrollo rápidoes deternrinar cu¿il es cl tipo dc dcsarrollo rápic1o que neccsita. ¿,Necesitaun ligero aurncnto dc r clocidad. mayor predicibilidad, rtte' jor r isibilidadclel progreso. meuores costcs o l'nás r'clocidad a cLralquicr costc'l

Una cie las cosas r.t.tás sortrrrcnclcntes que descr-rbrí al rcalizar la tnr"es-

tigación cie base para cslc libro cs c¡t-tc nruchrs pcrsoni.ts qLrr- inicialntente

frÉ.fr

Figura 6.2. No existe un modelo único.


dicen que necesltan un desarrollo más rápido clescubren quc lo que real-

mente necesitan es Lln menor coste o una mayor preclecibilidad (o simple-

mente una iorma c1e evitar un fallo catastrófico)'

Pr-reclc plantearse varias preguntas para ayudarle a determinar el tipo

de dcsan'ollo rlr¡ritio qtte tlecesitlt:

o ¿,Cuál es la fuerza de la restricción de planificación del producto''

. ),Ef énf'asis en la planificación del proyccto ha surgido porque es

realmcnte ltna cle las uapariencias del desarrollo rápido>'l

o ¿,Stt proyecto cstá liniüclo por cualquier punto dé-bil que podrla

impedir llcvar a cabo el clcsarrollo rápido con éxito'l

Las siguientes seccioncs describcn cómo responder a estas pregunlas

productos con fuertes restr¡cciones de planificación

Losprocluctosqtlenecesitanrealmentecentrarseenalcanzarlarnáxintrr.clocitlacl de clcsarrollo sin in]portar el coste o la prcdecibilidad tiel-rerr

uno.,.u"ticrr-rpo-valordistintaaladelosproductosnonrrales.Conromues-tra la lírrea cle ralor clc r'rn protlucto normal en la Figura 6 3' el valor de

un prndu.to nornlal clisnlinuyc gradualmcnte con c1 paso del tiempo' Erl

cambio.conullprocluctoqu.ti."n.unafuerterestriccióndeplanificaciórl.hay un punttl en el que el ialor del producto disminuye precipitadamente

Parautlprclcluctollorl-nal.eldcsarrollocficicnteofrecegeneralment.-la mcjor conlbinacicin cle coste de clesarrollo y rendirniento de 1a planili-

Productos con fuertesrestricciones de

planif icacion

Figura 6.3. Representación det valor a lo largo del tiempo de productos

normales y productos cin fuertes restriccioneá de planificación' No hay

ianta urgencia en terminar un producto normal en una fecha concreta con:

¿ e x,-qlente para et caso de un producto con una fuerte restricción de

: =-':aciÓn

Tiempo


cación. Pero es posiblc que su producto tenga qus estar listo para la tenrpo-rada dc Na'idad. o si no" rcnga que espel'ar al año siguicnte. puecle quenecesitc el-cctnar un cambit'r cn el sistema de nóntinas a tientpo para cr-rr.nplirla 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 puedcque nccesite enfl'cntarsc a un producto cornpetidor. y espere doblar susbeneflcios si pueclc adelantarse seis senranas a sLl courpelidor en vez dcsacar el producto dos semanas después.

Ccluro sugiere cl gráfico. en estos proyectos pucde haber un pulrto ¿i

partir del cual si no ha terminado el producto es como si no hubiera hechonada. E,n estos casos. plrede resultar apropiado centrarsc por cor.npleto er.r

la vclocidad de dcsarrollo.

Apariencias del desarrollo ráp¡doE,n algunos cascls. la demanda de <desarrollo rápido> llcga por un carninoprocedente dc los usuarios o clientcs. o dcsde los altos cargos. Éstos pLrecienaplicar una prcsión increíble para hacer que un proclucto se terrnine másrápido. pcro en ocasiones lo que dcsean realmente es ufl rrenor coste ofllcllos flesgos. Simpler.nente, no sabcn có,-o pedir esas cosas. o no sabenque csas cosas n() ran ligaclas a la Vclocidad máxir.na cle dcsarrollo.

Antes dc oricntar sll proyecto hacia la ¡rlanilicación nrás corta en vezde hacia el l'nenor coste o la u.re-jor funcionalidad. dcscubra lo que realmcntese ncccsita. Hay ralias apariencias del desarrollo rápido que pareccn clar-uar¡ror alcanzar la máxima r,elocidad dc desarrollo. pcl'o lo qr.re realmentepiden es olra cosa; \,arros a describirlas c. los sigLrientes apartados.

Evitar retrasos. Si la organizaci(rn dc soriu'are tiene un historial cleercedcrse cu sus presupLrcstos y' planificaciones. cl cliente puccle pcciir<dcsarrollo rápido>. Sir.r embargo. en este caso. lo que er cliente c'lesea rcal-lurcutc es asegufarse de qr-re el proyccto se terminar¿i ajustándosc a lospllzos y plcst-tl)uc:t0s ¡t|cr istos.

Puede distinguir cste aparente dcsa.'ollo rápido de la nccesicracl dcalcanzar la máxir.na rclocidad dc desarrollo cor.nprobanclo que no cxisteotro objetiro específico de planificación quc. tclminar (tau pronto conlosca posiblc>. o bien. si hay un objetilo es¡lccífico. encontrando que nacliepucdc erplicar su inrportancia. Un historial dc proyectos retrasaclos pue-cie scr otra pista. En cste caso. la solucirin no consiste cu usar métodosorientados a planificación. sino usar uua mc-jor gestión de ricsgos, csti-rnación del proyccto y control de la directir,a.

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


REFERENCIACRUZADA

Para más ¡nformaciónsobre la reducción de

1a p anificación.consulte ,, Los costes

se incrementanrápidamente al reducir

r^ ^.^^"^--^:^ ^^,ra v u9, a,,,ou,u, I Puldebajo de la nominal..

en a Sección 8.6.

pucden pcdir <desarrollo rápido)). reiilmelttc cstán dcltt¿trtdarlclo [lna prc-

clccibiliclad sutlcicntctnente bttena para ptldcr coorclittar los csfuerzos r.--

lacionaclos. Si sus cliurtcs hacen énf'asis clt la rtccesiclad clc tcrnlitlat'csclttu.arc <a tiem¡.ro>i. ¡ no tienen ningLrnr rcstricción externa tal cttt.l'lt'

una prescntaciórT cn una l'eria. probablemctttc estén rttás preocttpados ptr:

la prcclecibiliclacl c1r.rc ltor inclementar al márirrro la r.clociclad cle clesarro-

llo. En estc caso. debe ccntr¿u'sc cn el desarrollo cficiente. y haccr hirlca-pié cn nrétodcls que recluzcan cl ricsgo de planificación.

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. hablarán dc tclllr;-nar pronto el sofiu arc. pclcl harán érlf'asis cn su preocupaciótl por el pr.--

supuesto ¡r no sobre la trtlanificación.Si la preocupación principal de los clicntcs cs el coste cle un provecto.

centrarse cn la planificación dcl cicsarrollo resulta particulan.l.tcntc cle:-

afortunado. Attnque resulta lcigrco sLlponer quc 1a planiticación trás cort.,

clc desarrollo es también la más barata" actualtnentc los métoclos qLte ttlint-rnizan el costc y la planificitcitx son clilerentes. Alargar algo la planifica-ci(rn pclr encima de la inicial ¡, clisnrinuir el tar.uaño del equipo puetl;reducir el costc total de Lur pro-vccto. Algunos r.nétodos dc desarrollo ra-

piclo increnrcntan cl coste total.

Fecha fija de pérdida 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. l¿r rrecesidad clel dcs¿rrrollo rápiclo depcndc realmetlt:del ticrnpo c'lLrc se tenga para realizar el proyecto. y del tierrpo llcccs0l'lr

para desan'ollarlo usanclo r"uótoclos de desan'ollo cf icicntc. La Figura 6 -nrucstra dos posibiliclacles.

Si puede conrpletar el prol,ccto en el período I (antcs cle la f-echa d;pérclida clc valor) usanclo ntótodos de desarrollo cflcierltc. há-qalo. y cétltrc:;en la lcducción 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 métodtri

de desarrollo rirpido clisnrinuyen el tierlpo dc desarrollo. pcro increnlent¡r:tunlbii'n la incel'tidtrnlhrc de lr pl.rnil'icaeitjn. ¡ ser'írr ttn crror usar lllct,'-clos que increr.nenten cl riesgcl de la planificación cn esta situación.

Si los métodos dc dcsarrollo eflcicntc no pen.ttiten por sí solos ternll-nar cl pro;-ecto antes dc la fecha de pérclida de ralor (por cjernplo. si stil'permiten terntinar el proyecto en el pcrioclo 2). etltonces necesitará us.,-

métodos orientados a la vclocidacl para tcncr alguna oportunidad de tel'-

minar a ticrnpo el pro.vccto.


Figura 6.4. La necesidad del uso de métodos de desarrollo rápidodepende de Io pronto que necesite el software. Si puede desarrollarlo en elperíodo 1 usando métodos de desarrollo eficiente, debe hacerlo ymantener así los riesgos bajos, en vez de centrarse en técnicas orientadasa la velocidad, que pueden incrementar el riesgo.

Deseo de horas extras gratuitas. En escasas ocasioncs. el interés dclclicntc (o directiro¡ ¡tor el desarrollo rirpido enntascara cl deseo de mcjo-rar la basc dcl desarrollo rapido sacancio todo cl tientpo crtra gratr-rito clc

desarrollo posible. La scns¿rción dc urgencia creada por uua planificaciónambiciosa ayr.rda a esta situación.

Esta circunstaucia es lácil cle distin-euir del verciadero clesarrollo rirpiclo.porque el clientc insistirá cn la irlportancia dc la planificación y, sinrultá-neamente. se negnrti a ofi'eccr cl soportc nccesalio para mejorar la rclocicladde desarrollo por cualcluict'otlcl ntcclio quc no sean las horas ertlas sinrelrunerar. El cliente no insistir¿i cn tcner rnás personal. mcjorar las hc-rramientas hardu are" tencr r.nejclres hcrrarrientas softu are u otros tipos dcsoporte. El clicnte no scr¿i particlario cle analizar la posibilidacl cie reducirlas prestaciolrcs pafa alcanzar ob.jetir os de planificación. En un vcrdaclercrproyecto de dcsarrollo rápido. el clientc estará dispuestcl a considcral cual-quier rredio para reclucir la planificación.

Si cumplir lir planilicaci(tn del proyecto es suflcientententc iutportan-te para ser presionaclo. tantbión es sullcicntenrente irnportunte para que elcliente increnrcnte el nivel de soportc al proycctct. Si la emprcsa ¡ride a loser.r.rpleados que trabajen r.l.rás duro, también debe estar dispuesla a trabajarr.nás duro. Si se cncuentr¿l en Lrna situación er.r la que su cliente está inten-tando simpleurcute hacerlc traba.jar gratis (incluyencio a su cquipo), es

probable quc l.ro pueda haccr nada para rne.jorarla. Los clientes quc practi-can este estilo dc dcsarrollo cle softr,r'arc uo tielten preseltte lo ntcjor paralos clerrás. Las opciones que le qr-rcdar.r son rehusar trabajar cn tales pro-yectos o cambial dc empleo.

Fecha de pérdidaoe vator

Tiempo


REFEBENCIACRUZADA

Para más lnformac ónsobre el desarrollo deWord para Windows.

consulte .Un ejemplode planificaclónexcesivamente

optrm sta,,, en laSección 9.1 .

¿Realmente necesita el desarrollo rápidoa 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 tarnbién son conscicntes cle los probler.nas qr-rc puedc caus¡r.actualizacitin dc un producto. Tenga presente que los clientes dcsean...equilibre el proclucto. el coste y la planrlicación de la mejor nraner-a pr'-ble. Por sullLlesto. le pedirán que dcsarrolle un -qran trrroducto con un l.-,coste cn poco ticrr.rpo. pero gencralnrcnte s<ilo rccogcr¿i uno o dos cle es.tres dcscos. Dcsarrollar un producto cle baja caliclacl cn poco ticmpo:1..ser la combinación crrónca. 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.,:-Si cntrega con retfaso un procir-rcto que les cle.ic con la boca abicrta..clicntes recclrdarán 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 rápido total. intente clctcrminar si la línea cle r,alor del nroclLr,-ticnc el aspecto de la lírrea clc los productos nornrales o de Ios prodtictos cfucrtes restriccioncs" nrostradas cn la Fisura 6.3. Deternrine si la plan: -

cación 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,,.núnrcro uno. tórncse 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 más 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

para windows fuc planificado originalmentc para hacerse cr.r un añt,. .

neccsitó cinco (lansiti. 199¿1). Microsofi winclou,s 95 fue entregaclo L.r-

ario y medio más tarcle de la f-echa anunciada originalnrente (cusunrar-;y Selb¡r. 1995). y se ha convertido en uno cle los productos softrvarc'e1r-didos rnás rápidanrente. un producto financiero en el quc trabajó ii: .entregado con un 50 por 100 dc retraso respecto a la planificación ong -

nal de la empresa. pero se conr,'irtió err el producto softrvarc nrás populr,:de dicha clr.)presa. Para cada uno de estos procfi-rctos. la entrega a tlemll,(segúrr la pla'ificacrón original) ro era un fhctor clar.e. aunqne todo e

mundo pcnsara que la planificación del clesarrollo cra un factor crítico c:-su lll()r-rlefrto.


.3, Posibilidad de terminar a t¡empo

: ==ERENCIACRUZADA

: -: lrOrmaClOnsoore ras

:, r¡es lo rnás

' aac ones lo: -:as posrore-.: Secc ón 8.6.

Muchos proyectos parecen progresaf lentaurcntc: sin er.nbalgo. no todoslos proyectos van despacio del misnlo modo. Algunos esflerzc'ls de desa-

rrollo son realmente lentos. y otros siurplcr.ncntc lo pareccu. cicbido a laimposibilidad de clesarrollar los esfuerzos estinrados.

Uno de los enfoques cle la estinraciórr de llroyectos softwarc mantiL-neque todo proyecto tiene una f'echa eracta err la que debe ser tcrminado. E,stc

er.rfoque nr¿urticnc 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 mayoría dc los desarrolladores no courparte estepLlnto de rista. Hay r.nuclias incógnitas quc particjpan en la planificacióndc softu'are. Las circunstancias cambian. Los dcsarrollaclores aprendennrás sobrc cl proclucto que constrLrycn a nrcdida que lo desarrollan. Al-gunos mótodos funcionan mejol de lo espcrado. y otlos peor.

Los proyectos softu'are contienen demasi¿rdas variablcs couro par¿l

poderdclinirplarrificacioncs con un 100 por 100 de exactitud. E,n lugar dctenef Llna f'eclra particular cn la que debe terrninarse un proyecto. para cual-quier proyecto dado criste un rango de fechas dc finalización. dc las cualcsurl¿ls son más ¡rrobables que otras. La distribución de probabilidad dc cstcrango de fechas es similal a la cun'a mostrada en la Figura 6.6 (r'óascpágina siguiente).

La fon.na de esta curn'a de probabrlidadcs expre sa valias hiptitcsis. Unade ellas cor-rsiste en quc eristc rLn límitc absoluto sobre la r,elocidad a laque sc puede ten.r.rinar cualquier proyecto. Terminar antes no es silnplcmcn-

Posibilidad del 1009ode termrnar en la ---+fecha prevista

Probabilidadde terminar

exactamenteen la fechaprogramada

Fecha final programada

Figura 6.5. Un enfoque de la planificación del software. Defiende que elproyecto t¡ene un 100 por 100 de posibilidades de estar term¡nado en unafecha determinada.





Figura 6.6. Forma de una planificación de software. Debido a tas incógnitasque influyen en un proyecto software, algunas fechas de finalización son másprobables que otras. pero ninguna de ellas es totalmente cierta.

te clifícil: cs inrposible. otra hiptitesis consiste cn clue la fornra de la curvacn cl laclo <inicial> no cs la nrisrna quc en el lado <<flnal>. Aunque existc unIírrite estricto sobre la rapidcz con quc se pr-rccle terntinar un proyecto. nocristc tal línritc para la lentitud con que se puede terminar. como es urásfácil terminar t¿rrcie Lln proyccto quc ternrinarlo antes dc tienrpo. la forrrade l¿r curva en cl lado firal es más graclual que er1 el lado inicial.

Tor.n DeMarco pl'opLrso qr-rc los proyectos deben ser planificados paracluc la probabilidad de cntre-qarlos antcs de tiernpo sea la misma que la decntregarlos tarde (DeMarco. 1982). E,n otras palabras. dcflnir la planifi-cación del proyccto para tener un 50 por 100 de posibilicladcs de ternrinar'a ticnrpo. colro se lluestra en la Figura 6.7.

I Planificacióni

l- "equilibrada" 50/50


exactamenteen la fechaprogramada Probabilidad de terminar

después de la fechaprevista


Figura 6.7. Planificación equilibrada. Existe un límite en la velocidadmáxima a la que se puede completar un proyecto, pero no para el tiempoque pueda prolongarse su desarrollo. Esta planificac¡ón ofrece un50 por 100 de posibilidades de terminar a tiempo.

Probabilidad de terminarantes o en la fecha

final prevista

Capitulo 6: Cuestiones fundamentales para el desarrollo rápido 131

La cstrategia dc planificación ecluilibracla de DeMarco es ull pttnto

cic particla útil para avanzar en la cotllprensión del desarrollo lcnto. Ptrcde

coltlellzar por dil'idir el grálico de probabilidades cll \'arlas zollas. feprcsen-

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 gráfico cs l¿l (zotla de clcsan'ollo iln-

posiblc>. L,sta zona reprcscnta un nivc'l de productiridacl quc no ha sido

¿rlcaltz¿ldo ltunca por ningitn proyccto. Los ¡lroycctcls planificados cll esta

zona estált colldenados a salirse dc sLr progralllación inicial.La zona de la izquielda dc la curva es la <zona dc desarrollo rápido>>.

Un proyccto temriltado elt CSta zona eS collsiclcracltl rápido. 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

pronósticos.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 llnalizaciórl. Las elllpresas

dc desarrollo dc sofiu'arc cficientes planilican y temtiltan sLts prodttctos de

ti¡n.na cousistentc en esta zona. que Icpresenta tula bLtctra cotlrbinación

de plarrilicación ¡r coste.El árca de la parte dcrecha dc la curva es l¿l (zoll¿l cle clesarrollo lcn-

to>>. Un proyecto terrni¡ado en cSt¿l zolta Se Considera lentc'r ¡lorquc- ttcltc

más del 50 por 100 de posibilidades clc terminar coll 111/ls rctraso. Ell loqLle respccta a la plarlificació11. un prOYecto qtle terlllina L-ll r'stu zona Slll

intentarlo ha tl'acasado. Tener órito en la planificacitln al 50.50 dependc



Zona de desarrolloZona de desarrollo

ef iciente

Zona dedesarrollo lenlo

Fecha final programadaZona de desarrollo

imPosible

Figura 6.8. Distintas zonas de una curva de planificación. Muchos proyectos

buscan la zona de desarrollo imposible (sin saber que es imposible)' y terminan

en la de desarrollo lento (sin desearlo).

I--)|.


dc una estirnación exacta y dc la obtención de lamación exacta. temas clescritos con dctalle en los

lceptueiirn dc tnla csli-Capítulos 8 y c.).

6.4. Percepción y real¡dad

Suponga qr.te dentro c'lc scis meses piensa nrudarse a una nueva ciudadsituacla a 100 kilómctro\ y ct'rnstruil ulrc nue\,a casa. Contrata a la cnrprc-sa constrLlctora Honest Abc para que le cclnstruya la casa. Acucrda pagaf-le 100.000 dólares a Abc. y éste acepta tener la casa lista dcntro dc scismescs. para clue pueda mudarse a ella cnando llegue a la ciudad. Ya h¿r

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 córno van las obra:

de la casa. así que un fin dc sclrana coge el coche y recorre los 100 kilo-metros para ir al solar y echar un'n,istazo. Para su sorpresa. lo irnico elrr.'

ve en el solar es una zon¿l con el suclo nivelado. No ha¡r cimientcls. nr

estructura ni ningírn otro traba.jo. Llama a Honest Abe y le pregunta<¿,Ciómo van las obras cle rli casa'l> Abe le contesta: <Hentos cr.lrpczadcpoco a poco pofque estalnos ternrinando otra casa. He incluido un ticnr¡,,de resen,a cn mi estimación dc su casa. así clue no hay por qLré preocu-parse. )

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 solur" ) csta \cz cncuenlra los eirnientos. pero no sc \c ninsún ot:'

traba.jo. Llama a la enrpresa. y le dicen: <No hav ningún problenra. Iist.,-mos dentro dc 1o planificado.>> Sigue estancio nervioso. pero decide acel'-tar la palabra de Abe.

Pasan el cuarto 1' cluinto nlcscs. Llama a At¡c varias \,eces par¿l cor'-probar sLls prosrcsos. y sienrpre le dicc cluc toclo va bicn. Al principrtr.: -

sexto Íncs. decide ir a ver la casa Llna vcz más 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 fbntanería. ni in:tr.ción clóctrica. calefacción 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. i-

nruchas 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:

<¿,Cuándo 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. Cróarnc.>

¿,Decidc crccr a Abe'l ¡Por supuesto quc nol No con su histolr¡iprogrcso que ha r,isto.

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


incluso con rnás dinero en juego. cspefarnos que nuestros clicnres qrricranver menos signos de progreso de los quc nosotros exigiríantos a alguierr quenos cstá construyendo una casa. Esperar.r.ros de ellos que acepten un con-junto de requerimientos. y luego esperen sentados semanas. nteses o inclusoaños antcs de tener algo tangiblc para cnseñarles. ¡No rcsulta ertraño quelos clientes se pongan nerviososl ¡E,s pcrfectamente nonual que los clien-tes piensen que cl desarrollo de software requiere mucho tierrpo!

Aunque esté completamente dentro dc lo planificado. sea consciente deque la percepctón de un desarrollo lento puede afectar a su proyccto tantocomo el desarrollo real. Aunque lo hagarnos siempre, no es razonablc espe-rar que los clientes csperen sentados durante mcses! y rnostrarles signtrsevidentes de progreso fbrma partc de nucstro trabajo.

Expectativas poco realistas de los clientesEn ocasiones, superar la percepción de un desarrollo lento requiere algomás quc ofi'eccr signos visibles de progreso. La mayoría de proycctos ac-tuales están programados dentro de las zonas de desarrollo rápido o inrpo-sible. La r.nayoría de proyectos careccn de los compromisos de planificacióny recursos necesanos para cumplir sus planificaciones agresivas. A nre-nudo, los planificadores de proyectos no son corrscientes dc lo ambiciososque resultan sus planes, y. collto sugiere la Figura 6.9, gcneralmente se

ternrinan en la zona lenta.El período entre la fccha cstimada y la fecha real de finalización cuenta

r.nucho en la percepción de que los proyectos softw.are van lentos. Si unproyecto medio se planifica en la zona imposible, pero es terr.ninado en la

La mayoría de proyectosestán programados



La mayoria de proyectosse term¡nan en una

de estas zonas


Figura 6.9. Planificación típica en relación con la curva de planificaciondel software. Debido a est¡mac¡ones poco real¡stas, Ia mayoría deproyectos parecen ir lentos aunque se terminen en las zonas de desarrolloráoido o eficiente.

134 Desarrollo y gestión de proyectos ¡nformát¡cos

zona eflcie¡tc. la ge¡te cor.rsiclerará que ha sido trtl fallo. aLrnqtrc sus desaro-

llaclorcs lo hayanlcrnrinaclcl clc fbrma cficiente y pucdcn haberlcl tcrnrinn-

clolomirsprolltOposibleconlosrecursosclequcclisponian.

Superación de la percepc¡ón de un desarrollo lento

En tórntincls gencr.alcs. puecle superar cl problcma del desarrollo lento de

dos lbnttas:

o (,ettÍrut'.st' ett !4 rettlidtttl tlt'l tlesttt'rollct lentr¡. Acortar las planiti-

caclones \,1gel1tes. pasar.rclo clel clcsarrollo lento a1 desarrollo ell-

ciente" o clcl clcsarrollo etlciente al de sarrollo rápido'

o (.atttt.ttr.se en lu ¡terc'e¡tt'ióp iel desut't't¡llt¡ 1¿'rl¡¿¡. Elirlinar las ide¿rs

Lttcipicas.,vhaccrqttelasplar-rificacionesinicialcsseannlást.ea-listas. alaigri'dolas para ccrrar el hueco cntt'e las f-echas dc fi'ali-zaciónplanificadayactllal.Utilicemótoclosquedestaquenlavisi-biliclacl clel progreso. E,n ocasiones. los clientes no deseen tant(r

incrcrre'tar la ielociclacl cle clcsarrollo. sino que si*plcmente de-

seall cstar illfbrlnadcls.

La zona clc vclociclacl cle clesarrollo en la quc- sL- enctlentre determtnarll

st clebe ccntrarse cn cl clesarrollo rirpicio cn sí o en 1a perccpción del desarrt''-

llo rápido. con urucha frecr-rencia habrá clue rcsollcr cl problema cn anl-

bos nivelcs.

6.5. Distribución del tiempo emPleado

REFERENCIACFUZADA

Para n'rás detallessobre ia distribuclón

del tiempo empleadoen sus Propios

proyectos, consulte el

CaPítulo 26.,,l\4edid as. .

Urra estratcgia para lograr el clesarrollo rápido es detcrminar el árca en -',

qlre se.nlpla,, la rna¡roría clcl tiempo cn un proyecto típico' y L'ntonc'i

iitentar rcclucir clicho ticmpo. Puedc reclucir algu'ras tareas con más fae -

liclacl que otras. c llttclttar reducir algunas de ellas puede alargar inadrt':-

tidarnentc lu plani l'icrciórl.Dentro clc un proyecto sofitvarc. el tiempo puede contemplarse de i¡':'

ntas c-listintas. y 1os diferentcs pLlntos tlc vista producen diferentes p€rCc':-

cioncs clel emplco clc clicho tienlpo. E1 siguierlte apartado presenta el ¡r¡'¡

to c1e r ista clásico (fase a thsc). y los apartados posterlores prcsentan oIl.

pLlntos clc vista.

El punto de vista clásico

La mayoría c1c proyectos conlienzan en ulla f-ase poco definida de pt'":':-

qLrisitos. que puccle dur-ar bastante tienpo. En a1gún ll1onlento. col'ui:

.. tcc0gicla procluctiva de requerinrientos. y en algún mornento postc'l'

.-]S REALES


comicnza oflcialnlcnte cl dcsarrollo dc softr'i'are . Las actir idadcs posterioresa los rcquerir.nientos tienden a se r la ¡rartc tnc-jor deflnida del proyecto. LaTabla 6.1 ofrece una idca aprorimada dc dónde se cnrplea el tienrpo en

1as actividades posteriores a los requerir.nientos cn pro,vectos grandes ypeqi.reños bien ejecutados.

Las actir.idades que requicren nrás tieurpo clc un proyecfo pequt--ñrr

son las tareas de construcción de diseño dctallado. codificación.depu-ración y prueba de unidades. Si pudiera elir.uinarlas por arte de magia.podría reducir el esfuerzo de su pro¡'eclo cn urr 65 ¡ror 100. En un pro-ycctcl grancle, las actir'idacles cie construcción rr.quir'ren IIcn()s partc' dclesfuerzo global. E,lirninarlas de un plumazo stilo reduciria alrcdcdor dc

Lrn 35 por 100 del esfuerzo reqr"rerido pol el pro_vccto.

La mayoría dc nosotros ha aprendido a tra\'és de la clura expcncncra a

no acortar arbitrariamcntc las actiridades inicialcs de arclr-ritectura 1, cli-

seño. Podcrros pclrsaf que reclucir el tiempo de diserio en un -5 por 100

puedc rcducir la planificación del desarrollo en rrn 5 pol 100. pcro lo rrásprobable es que cualquier tienrpo ¿rhorrado por ¿rcortar cl discño sca paga-do posteriornrente con intercscs cn las ct¿rpas flnales del proyccto (actual-rrente, la penalización suf ida pucdc accrcarsc r.nás a la usura cluc al intc-rós). Dicho de otra fbnna. un dcl-ccto dc discr'lo que requicrc r-rr.ra hora ymedia para ser detectado cn la fasc cle discrlo puecle necesitar de dos ciías

a un nles para ser resuelto si no sc dctccta hasta la comprobacicin dcl sis-tema ( Fagan. 1 976 )

Una estrategia más clcctiia quc la rcduccicirr arbitraria de las lascsiniciales consiste en realizarlas dcl moclo rrás eflcientc posiblc. o usarmétodos que requieran lnenos discño (con.ro ejcnrplo, podrían-ros usar un¿r

biblioteca de código para Lrna partc'del sistema). Es más probable reducirel tienrpo total de desarrclllo si se er.n¡rlea r.niis tienrpo cn Ias actividadesiniciales. v no mcnos.

Tabla 6.1. Distribución aproximada de actividades por tamaño del proyecto

Actividad Prolccto pequeño(2.500 líncas de código)

Provecto grandc(500.000 líneas)

Arqu itectura,,'cli seño

Diserio dctallado

( udille re irin tlcpLrrrcrórr

Plucba de unidades

lntegracicin

Prueba del sisterna

I0'ln

20e.;

) 5(1,i,

2011ó

l5rti

I0,,,;

i 0(1.;

209.u

109.¡

50.i,

20,1.n

l-5(f i)

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

136 Desarrotto y gestión de proyectos informáticos

DATOS REALES

REFERENCIACFUZADA

Para rnás informaciónsobre la lmPortancia

de evltar rePetlr el

trabajo. consulie la

Sección 4.3, "Basesdel control de calidad'

REFERENCIACRUZADA

Para más informaciónsobre el cambio de

prestaciones, consultela Sección 14 2,

" Proyecto avanzado:control de camblos

de las Prestaclones"

REFERENCIACRUZADA

Para más informaciónsobre e1 anál1s¡s

de requertmlentos'consulte la

Sección 14 1 ,

" Proyecto iniciado:reducción del conJunto

de Prestaciones"

Puntos clave

Dcspués dc rcvlsar más clc't'000 proyectos' Capers Jones informa que l'r

inclustriaclel sofirvareengeneral puedetenerunaeficienciadeun35.por l0{t

(.lones, 199'+). El 65 poi 100 de tiempo restante se gasta en actividades

perjudiciales o lnlprocluctivas' como el uso de herramientas de producti-

r,iclad que no funcronan. 1o "pur.utión

de módulos desarrollados de tbrma

descuidacia, trabaio perditlo áebido a la falta de control de configuracior'

¡, clemás. ¿,Dóndc se puede ahorrar tiempo'l Los siguientes subapartado'

derclibcn algtrnas de cttls arcas'

Trabaio repetido' Repetir requerimientos' diseño y código defectut'-

sos puede consurltr generalmentt dt un 40 a un 50 por 100 de1 coste tot'r

del desarrollo de softrvare (Jones, l9g6b; Boehrn. 1987a). La correcciorr

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

las corrccci.llcs evltall una repetlclon posterior del trabajo, ofrece utr"

oportLrniclad potentc para reducir sus proyectos'

Cambiodeprestaciones'Elcambiodeprestaciot-rcs.puededeberse..cambios en los requct'imientos o nleticulosiclacl por parte deldesarrollador

Un proyecto norrnal expcrimenta alrededor de un 25 por 100 de cambit"

en sus requerimier.rtos a lo largo de su clesarrollo' lo que añade más dc ttrl

25 por 100 cle csfucrzo ai proiecto (Bochn-r' 1981;Jones' 1994)' No limi-

tar los cambios e,t los ,equerimientos a los estrictanlente necesarios es ttl'

error clásico en la relociiacl c1e desarrollo, y eliminar cl cam.bio de pres-

tu.ion.,ayudarnuclroaeliminarlosretrasosglobalesenlaplanificaclÓr..

Especificaciónderequerimientos'-Laespecificación{grequerimier.-tosesunaactiviciaclqu.noestáref.lcjaclaenlaTabla6'l.Mientrasquell.actir,idacleslistaclasenlaTabla6.lestánrelacionadascotrlasolucióntl.trnproblema.lacspecificacróncierequerimientosestárelacionadacot-ti'.especificaciórrclclproblen]aensí'Esr'rnaactir,.idadn-rásabicrtaqueotl.]:actividades de desarrollo. y el tiempo empleado recogiendo rcquerintterr-

tosnoguardalllngunarelacióncleterminaclaconeltienrpototalempleatt.constrLiycndo ei prograrna' Pucclcn paslr 12 meses ttt:il.::^1" requef:-

nrientos pal'a utl ,,rtaitu que necesitará 36 n-rescs para construirse O podl i''

dedicar]osnllsmosl2nlesesrrrediandoentrevariosgruposp.aradefin::-un sistellla quc sólo requerirá seis meses para su construcción' Gen"-

ralmente. la especrficación de requerimientos necesita entre un 101 t'r:'

30 por 100 del trempo empleaclo tn.ttn ptoytcto (Boehm' '1981)'

Como la recopilación de requerimierrtos es una actividad tan abicrt'

cs posible ,.l..p.'Alti" grrndcs'cr.nticlades dc ticmpo innecesaLtanlcilt'

Urrlrroderadosenticiodeurgenciadurantelarecopilacióndcrequerin-rier.'tos pucde evttar una

"n'ut-ión total de pánico al final del proyecto'


Los r.nétodos de desarrollo rápido que se llcvan a cabo para cornbatirel tierrpo perdido durantc la especificación de requerimientos incluyen eldesarrollo conjunto de aplicaciones (.lAD. .loint Apphcation Der.'elopment),cl prototipado er"olutivo. la entrega por ctapas y diversos cnfbques de lagestión de riesgos. Estos ntétodos están dcscritos a io largo de1 libro.

El .,inicio difusor. Otro tipo de actividad que no está descrita en la Ta-bla 6.1 es el <inicio difuso>. El trempo total necesario para dcsarrollar unproducto sofir,varc r,'a desde el pr.rnto en que el proyecto es sintplcnente unavisión en la rrente dc alguien hasta cl ntomento en que el sofiware tenni-nado cstá cn manos del cliente. Algún tiempo después de que el proyectoes una visión cn la mentc dc alguien, se tolra la decisión de <contenzar>,

1, ernpieza oficialmente el proyecto softrvare. El tiernpo transcurrido entre lachispa inicial y la decisión dc <comenzar> puetle ser u.tuy largo. Este .iiniciodifuso> puede consurnir sran parte del ticntpo disponible para poner unproducto en el mercado. El E.jcntplo 6.1 describc un caso típico.

Ejemplo 6.1. Vagando por el inicio difuso

Bill es un directivo de la empresa de seguros Giga Safe. Estas son las notasque tornó sobre el proceso de aprobación del Giga-Quote 1.0, un programade primas de seguros:

I de octubre. Queremos desarrollar un nuevo programa de primas paranuestros corredores. Queremos que el progranra descargue las primas decada día en la oficina central cada noche. Harán falta unos 12 meses paraterminar su desarrollo, así que no podremos tenerlo a tiempo para la subidade tarif'as de enero próximo, pero podríamos tenerlo para la subida poste-rior (dentro de 15 meses). Deberíamos intentar terminarlo para el I de no-viembre (dentro de 13 meses), para tener tietnpo de formar a los agentesantes de cambiar las primas. Voy a proponer el proyecto en la reunión delcomité ejecutivo a final de rres.

2 de enero. La propuesta de Giga-Quote ha sido retrasada dos meses enla agenda del comité ejecutivo. Finalmente, la he presentado a finalesde diciembre, y he recibido la aprobación para preparar un análisis de be-neficios.

I de lbbrero. El análisis de beneficios está terminado; sólo necesita serrer,isado.

I de mur:o. Dos de los principales responsables de ventas están devacaciones. El análisis de bene{'icios no puede ser aprobado hasta que Iorevisen.

I 5 de abrí|. Ya están todas las revisiones, y el proyecto está <en mar-cha>. El comité ejecutivo sigue queriendo que el proyecto esté terminadoel I de noviembre, así que el equipo tiene que empezar a codificar ahora1111S1TIO.


C'onro no se realiz¿ur controles fbrnrales (no hal planificaci(rn. nipresupucsto. ni nretas. ni ob.jctiro-\). clurante este períoclo cl trrrogrcso cs

dificil clc controlar'. Acienrás. la nrayoría cle clirectivos ticlrclcn ir dal'pocaprioridad a csla lasc. p()rqur'el inrpacto llnanciero cstá lc-jos. En cl inicioclifuso. pLrcdc pclc'lcr tie'ttt1-rtr l)()l- estll\ r'irz()ltes:

Naclie tiene asignacla la rcspurrsabilidad dcl clesarrollo dcl producto.No eriste nna sensacicin cle rLrsencia para realizar Llna clccisión clu

comenzarrlro conrclrzar ¿r clesarrclllar c1 protlucto.No existe Lrn mccanisnro para e'r'itar qlrc el prociucto sc clLrcnna elr

Ios laureles.o No cxiste un nrecanisr¡o pal'a rcsucitar un producto ulr¿r vcr cluc se'

h¿r clornritlo en los laulclcs.Los aspectos clave en la r iabilidad clel procluctt'r 1r iabiliclacl telcni-

ca 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 aprobación dc ¡llocluc-tos o presul)uestos ¿lntcs clc qr-Le pueda tcner apnrbaclo cl pre supuesitrEl cquipo clLle desarrolla cl proclucto no se forma a partir dcl cqLli-po clLle ha traba.jaclo par¿l la aprobacrón c1e1 proyccto. .{l ¡rrc¡larar.'equipo cie desarrollo. l¿rn-riliarizarlo con el procltrctr'r y cncargirrlc 1.,

tilrcrr sc ¡ricrdc tierrrpo ) crrrp¡¡.jL'.

a

a

BIBLIOGRAFIAADICIONAL

Para más informaciónsobre el inicio dif uso.

lea DeveloptngProducts 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(lLa única lbrma de recuperar Lur lres percliclo en el inicio L-s acortar ulr nrciel ciclo dc dcsarrollo clel proclncto en su fhse final. Acorl¿rr en un nrL-s !csfirerzo global de <lesarrollo cuest¿r bastante r.r.rás que abrcviar el inici,cn el misnro pcl'íoc1o. El inicio presenta una de las oportLrnidacies rnás ect'-nón-ric¿rs y ef'ectil as dc dcsarrollo rápido.

6.6. Equilibrio de factores de la velocidad de desarrollo

Una cle las lllosofías 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.,máxirla, entonces láncese 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 sirnult¿ineamente 1a planif icaciór.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 procluicon nrenos fi¡ncionalidad dc la que podria habcr tenido.

ll)lIe\

Capitulo 6: Cuestiones fundamentales para el desarrollo rápido 139

Equilibrio entre planificación, coste y productoUn tliangulo rlc ccluilitrrio entre planificacióu. costc y caliclacl clr sus ex-trcmos cs algo básico para lir gestión. Sin cnrbargo. en softnare no tiencl.r.rucho sentickr tcncr un cxtrenro dc <calicl¡d>) cn Lur triángLrlo dc equili-blio. C'cntrarse en cicrtos tipos cic calldad rcciucc cl coste v la ¡tlanifica-cirirt. 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 atributosrelaciorlaclos con el proclucto. inclu¡'enclo prcstarciones" complc-jidacl. usa-bilidad. [aciliclad rlc nrocliflcaci(rn. ntanlotintiento" tasa de crrorcs y dc-rur¿rs. La Fisura (r. l0 iluslr'¿r .'l triringulo dc cquilibrio ciel soltr.lare .

Para manle ncr cclr-Lilibratlo cl tritingulo" ticnc que calibrar la planilicación"cl coste 1'el trrroducto. Si dcsc¿r inciclil en la csclr.rina clcl produclo. tcudrá clue

incrementar cl costc. la planilicaci(rr o alnbos. t on las restantes courbinacitl-nes p¿lsa lo nrisnro. Si dcsea nrodillcal uno de los r'értices clel triangulo. ten-clrii cluc niodilicar al nrenos uno clc los otlos para ur¿lutenello cclLrilibraclo.

Para avudat'mc ¿r llcnsar la opcitin a r.naniltular- clurante las reunioncs deplalril-icaciólt nre gllst¿r llfcsentar un grau triángulo con sus r'ér'tices rotul¿r-clos cotro <planilicacitin))" (coslc) v <procluctor>. Los clientes cligcn cl r'ér-ticc o iórtices que dcscan controlar'. Nuestro trabajo conro desarrollacloresclc sclljr"'¿rrc consistc en clue los clicntcs r.tos enseñen los r'értices a los clueticnden. y cnscriarlcs lo cluc hay cluc haccl para ecluilibrar el triángulo. Sitrn cliclttc se celtlr¿l crt los verrticcs ((llroclucto) y (coste)" le dircn.ros ct'rnlorcsulta afcctaclo el rórticc <<planilicacirin>>. Si s(rlo se flian en el rórtice<productt'lir^ podcnros darles un¿r anrplia r,'ariedacl de cclmbinacioncs clc-

costc ), planif icación. Pero cor.no desan'ol1¿rdores necesitan.ros tcucr coutomínit'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 icación

Producto

Figura 6.10. Triángulo de equilibrio del software. Para tener éxito en elproyecto, hay que mantener equiltbrados la planificación, el coste y elproducto.

140 Desarrollo y gestión de proyectos ¡nformát¡cos

ERROR CLÁSICO

REFERENCIACRUZADA

Para más informaciónsobre ta negociaciónen entornos dif Íciles.

véase la Sección 9.2,.Dtsminución de la

pres¡ón de laptan if icac ió n,, .

REFEFENCIACRUZADA

Para más detallessobre la relaciónentre la tasa de

defectos y el tiempode desarrolio. consultela Sección 4.3, "Basesdel control de calidad..

REFERENCIACBUZADA

Para más detallessobre el uso de estetrpo de calidad parareducir el tiempo de

desarrollo. consulte eiCapítulo 14. "Control

det conjunto deprestacrones".

Jim Mccarthy info'ra que en un soncleo infbrmal ha encontrado quecntre un -i0 y Lrn 40 ¡ror 100 de tocios los proyectos cle desarrollo adolecende la irnposición simultánea de prestacioncs. recursos y planifjcación(Mccarthy. 1995). si no eristc un eqtrilibrio i.icialc.ntrc pianificación. cos-tc 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 dccquilibrar las características de Ios proyectos para rercr exiio. cuanclo uncliente le pasa la deflniciór de un pfoducto^ un coste fijo y una planifica-ción f¡a. generalrnc'rtc está intcntanclo mcter urr producto cle l0 kilos enuna bolsa para 5 kilos. Pucclc intentar fbrzar cl paqlrete de l0 kilos cn labolsa, cstirar la bolsa y rornperla. pero ar final simplenrente se clesesperar.a.simplemerrte porquc no cabe. y seguirá tcnicndo que decidir sr neccsitauna bolsa más {¡rande o poner lreros canticlacl en la bolsa que trene.

Compromisos de calidadLos productos soft*'arc ticnen dos tipos de caliclacl. que afecta'a la plani-ficación de

'arias fbrmas. Un tipo de caliciad es una taja tasa de deicctos.

Hasta cicrto punto, tener pocos clcf-ectos y Lrn tiempo corto de desarrollosor cosas rclacionadas, así que no hay fbrma de cq,ilibrar este tipo ciecalidad pa.a planificar. El camino hacia la planificación rnás corta posr-ble consiste en obtenc'r cl proclucto correcto a la primera. para no percrer.tiempo volvienclo a trabajar en el diseño y la cocrificación.

El otro tipo de calidad incluye todas las resta'tes características cn lasque piensa al inlaginar ttn proclucto softrvare cle alta caliciacl: usabiliclacl.eflcacia, robustcz y demás. centrarse en este tipo de calidad alarga ra pla-nificación del desarrollo, así q*e eriste la posibiliclacl de equilibrar esretipo de calidaci flenre a la planificación.

Compromiso de eficiencia por persona¿,Eriste un conflicto entre intentar alcanzar la márima prociuctir iclad p¡rpersona y la rrayor eficicncia cr la planificación'l Si. existe. La nre¡r-,fo'na de maximizar la procir-rctir,.idacl por persona conslste en manreuei.un tamaño de eqLripo reducido. una de las fbrmas más fáciles de rcclucrr.uua planificación de software consistc en incrementar el tamaño dcl equipo.lo quc i'rcrcnrcnta la productiviclad total. pero gc'eralmente hace que c¿rclilpersona sea menos eficiente. El ciesarrollo rápido no siempre es eficiente

típico de mejora de la planificación6.7. Patrón

Las organizaciones que intentan nrcjorar su 'elociclad

de desarrolro pa-sando al desarrollo eficiente sigtren un patrón predecible. Si coge 100 pro-yectos normales. encontrará quc sus posibiliclades cie terminar a ticrnlr,,serán como las rlostradas en la Fieura 6.1 l.

:3_iOGFAFIAi]ICIONAL

:: : ;-ñl ¡r oct.

I s.usión, lea: _ :: :,r' l\4aturityt: ':'soltware,:- 'tPaulkel

ái 1 993).


Planif icación Planificación¡nicial al 50/50


exactamenteen la fecha

programada


Figura 6.11. Curva de planificación en el desarroilo típico. Los proyectosnormales tienen planificaciones que carecen prácticamente deposibilidades de cumplir.

Entre los proyectos normales. el ámbito del rendirniento clel pro-yecto es amplio, y muchos de los proyectos tienen rL.trasos significa-tivos. Observe que gran parte de la curva de la Figura 6. I I está a la dc-recha de la línea de planificación inicial en proyectos normales. Haypocos proyectos que se acerquen a sus objetivos iniciales de coste o pla-n ificac ión.

Como muestra la Figura 6.12. entrc los proyectos con desarrollo cfl-cicntc la variación de la planificación es rrenor. y la mayoría dc proyectosse acercan a sus objeti\.os de coste y planificación. Casi la rnitad de losproyectos terminan antes de la fccha fijada, y casi la otra mitad ternrinandespr.rés. Las planificaciones iniciales son más largas que en cl desarrollo



Figura 6.12. Curva depl an if icacio n es i n icia leslos proyectos normales,cortas.


planificación en desarrollo eficiente. Lasde los proyectos eficientes son más largas que enpero las planificaciones definitivas resultan más

La planificación inicialy la plan¡ficación

al 50/50 son iguales


típico, pero las planificaciones reales son más cortas. Esto se debe en par-fe a aprender cómo definir los objetivos de un modo más realista, y tam-bién a aprender cómo desarrollar el software con más rapidez. Pasar de laimaginación a la planificación de proyectos con sentido es crucial parapasar del desarrollo típico al desarrollo eficiente.

Una vez alcanzado el desarrollo eficiente, el patrón de mejora depen-de de si desea mejorar la velocidad de desarrollo, la predecibilidad de laplanificación o ambas cosas. Idealmente, podría emplear métodos que l.'conducirían a la compacta curva mostrada en la Figura 6.13.

Desafortunadamente para nosotros, la curva iileál cle la Figura 6. l3 es

tan utópica en el desarrollo de software como la reducción de peso en lasdietas milagrosas. Como se muestra en la Figura 6.14,la mayoría de rne-todos de desarrollo rápido están orientados hacia incrementar la veloci-dad de desarrollo o reducir el riesgo en la planificación, pero no en ambossent idos.

Al seleccionar métodos de desarrollo rápido, necesita decidir si deseamejorar las posibilidades de entregar antes un producto o reducir el ries-go de que el producto se retrase más allá de una cierta fecha. El resto de.libro describe estos métodos.

6.8. Camino hacia el desarrollo rápido

Los restantes capítulos de esta parte del libro describen los enfoques quecontribuyen al desarrollo rápido. E,stos son los métodos:

¡ Planificación del ciclo de vida.o Estimación.



Figura 6.13. Curva de planificación ideal en desarrollo rápido. Si todo vacomo está previsto, el resultado consiste en velocidad y predecibilidadmayores.





^'- Reducir el riesgo

Figura 6.14. Opciones de planificación. El desarrollo rápido puedecentrarse en incrementar la velocidad de desarrollo o reducir los riesoosrelac¡onados con la planificac¡ón.

¡ Planificación.¡ Desarrollo orientado al cliente.o Motir,.ación.o Equipo de trabajo.. E,structura del equipo.¡ Control dei conjunto de prestaciones.o Herramientas para aumentar 1a productividad.. Recuperación de proyectos.

Algunos de estos ternas pueden considerarse como parte de lo quehemos descrito como <bases del desarrollo) o (desarrollo eficiente>. Comocreo que estos enfoques son básicos para alcanzar la máxima velocidadde desarrollo, están descritos en esta parte del libro.

bliografía adicional

DeMarco, Tom: Contrc¡lling Sry'in-are Projects. New York: Yourdon Press.1982. Este libro contiene gran parte de la inspiración de la parte decurvas de planificación de software de este capítulo. DeMarco dibujauna imagen vívida, humorística y en ocasiones llena de pánico de losmétodos actuales de estimación, que, en lo que puedo decir, no hancambiado desde que publicó su libro en 1982. Describe un métodopara mejorar la estimación y la planificación.

Martin, James: Rapid Application Det,elopmen¡. New York: MacmillanPublishing Company, 1991. Este libro presenta una perspectiva dis-tinta de los temas fundamentaies del desarrollo rápido para aplicacio-nes de sistemas de inforrnación.

Aumentar



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"-específicamentc al desarrollo de softrvare. este libro contiene ntu. '

infbrmación relacionada con el desarrollo rrrás rápido de produ;softwarc. El Capítulo 3 contiene una descripción completa del .,in -

clifuso>.

Mac Connell

Documents

Transcript of Mac Connell