Libro

Desarrollo y gestión
de proyectos informáticos
-¡''.il) \'ega
Gálvez
- nir ersidad Nacional de Inseniería
oco ta
L L
Desarrollo y gestión
de proyectos i nform áli cos
Steve McConnell
Traducción
ISABEL M." DEL Ácuu.a cANo
ALFoNSo BoscH enÁN
Revisión técnica
ANToNro vAeuERo sÁNcHnz
Catedrático de Lenguajes y Sistemas Informáticos
Escuela Superior de Informática
Universidad Complutense de Madrid
SAMUEL rúNEz noonÍcupz
Departamento de Lenguajes y Computación
Universidad de Almería
McGraw-Hill
MADRID. BUENOS AIRES. CARACAS. GUATEMALA. LISBoA. MÉXIco
NUEVA YORK. PNruA¡¡Á. SAN JUAN . SANTAFÉ oe eocorÁ. SANTIAGo. SÁo PAULo
AUCKLAND. HAMBURGO. LONDRES. MILÁN. MONTREAL. NUEVA DELH¡. PRRíS
SAN FRANCISCO . SIDNEY. SINGAPUR . ST. LOUIS . TOK|O. TORONTO
t*__
DESARROLLO Y GESTIÓN DE PROYECTOS INFORMÁTICOS
esli permitida la reproducción total o parcial de este libro, ni su tratamiento
tico, ni la transmisión de ninguna forma o por cualquier medio, ya sea
electrónico, mecánico, por fotocopia, por registro u otros métodos, sin el permiso
previo y por escrito de los titulares del Copyright.
DERECHOS RESERVADOS A 1997, respecto a la primera edición en por

MCGRAW-HILL/INTERAMERICANA DE ESPAÑA, S. A.U.
Edificio Valrealty, 1." planta
Basauri. l7
28023 Aravaca (Madrid)
Traducido de la primera edición en inglés de

Rapid development
ISBN: l-55615-900-5
Copyright A 1996, por Microsoft Corporation

Copyright de la edición original en lengua inglesa O 1996
Publicado por McGraw-Hill/Interamericana de España por acuerdo con el editor

original, Microsoft Corporation, Redmond, Washington. EE.UU.
ISBN: 84-481-1229-6
Depósito legal: M. 26.902-1998
Editora: Mercedes F¡anco Calvo

Compuesto en: PUNTOGRAPHIC, S. L.
Impreso en: Impresos y Revistas, S. A. (IMPRESA)
IMPRESO EN ESPAÑA - PRINTED IN SPAIN
\_
F.
e
,F
3
F
I
3
F
Acerca del autor
SteveMcConnell es ingeniero jefe de softwareenCmu$fuelil

lrn&$ede
ders, Inc., una empresa de construcción de software &
Es autor de Code Complete, editor de Ia coh¡mna*BestHinn&rrnu
Sofiware, y desarrollador en activo. Su actividad@nl hil ¡i.b d dF
sarrollo de software <prét-á-porten> de gran difusión, y posaimnem
también ha sido contratado como consultor por muchas empresas det ftEa
de Puget Sound, incluida Microsoft Corporation.
Steve se graduó en el Whitman College en Walla Walla, Washington,
ebizo un máster en ingeniería de1 software en la Universidad de Seattle.
Es miembro de la IEEE Computer Sotiety y de la ACM.
Steve vive en Bellevue, Washington, con su perro Springer Spaniel,
Odie; con su perra Bearded Collie, Daisy; y con su esposa, Tammy, pro-
fesora de enseñanza primaria.
Si tiene algún comentario o sugerencia que plantear sobre este libro,
contacte con Steve en Microsoft Press, vía Internet en la dirección ste-
vemcc@construx.com, o en su página web en http://www.construx.com/
stevemcc.
Conbnido
Ejemplos xiii
Tablas de consulta xv
Prólogo xvii
PARTE I
DESARROLLO EFICIENTE
1. Bienvenido al desarrollo rápido J
1.1. ¿Qué es e1 desarrollo rápido? 4

1.2. Cómo lograr el desarrollo rápido 4
2. Estrategia para el desarrollo rápido

2.I. Estrategia general para el desarrollo rápido 12
2.2. Cuatro dimensiones de la velocidad de desarrollo ............ 15
2.3. Tipos generales de desarrollo rápido 23
2.4. ¿Cuál es la dimensión más importante? ............ 26
2.5. Una estrategia alternativapara el desarrollo rápido .. 28
Bibliografía adicional 33
3. Errores clásicos 35
3.1. Ejemplo de errores clásicos ...................:: 35

3.2. Efecto de los errores en la programación de un desarrollo............. 43
3.3. Relación de errores clásicos 45
3.4. Lafaga de La isla de Gilligan 56
Bibliografia adicional 58
4. Bases del desarrollo de software 59

4.1. Bases de gestión 63
4.2. Bases técnicas .-,.-.......... 68
vlt
/3-E iÍl?
': R¡ses del c,¡ntrol de calidad 18

!.J,," Segro l¿s instrucciones............ 86
Bibliografia general 88
5. Gestión de riesgos 89
Elementos de la gestión de riesgos... 92
Identificación de riesgos 94
Análisis de riesgos 101
Priorización de riesgos 104
Control de riesgos... 101
Riesgo, alto riesgo y azar ......... 114
Bibliografía adicional ll7
PARTE II
DESARROLLO RÁPIDO
6. Cuestiones fundamentales para el desarrollo rápido I2t

¿Existe un modelo único? l2l
¿Qué tipo de desarrollo rápido necesita? 123
Posibilidad de terminar a tiempo 129
Percepción y realidad 132
Distribución del tiempo empleado 134
Equilibrio de factores de la velocidad de desarrollo............. 138
Patrón típico de mejora de la planificación 140
Camino hacia el desarrollo rápido 142
7. Planificación del ciclo de vida....... 145

7 .1. Cascada pura ............ .............................. 148
7.2. Codificar y corregir 152
7.3. Espiral 153
7 .4. Cascadas modif,rcadas 155
7 .5. Prototipado evolutivo 159
7.6. Entrega por etapas 161
7 .7. Diseño por planificación .......... 162
7.8. Entrega evolutiva.... 164
7.9. Diseño por her:ramientas .......... 165
7.10. Software comercial existente 161
7.1.I. Selección del ciclo de vida más rápido para su proyecto 161
adicional
L
Bibliografia 17 5
Contenido IX
t71
8. Esti,mecidn
1:9
:. - l:.t..na de la estimación del software
188
!"- ,:,::o,jucción al proceso de estimación """""""""""""
189
!_: Esnrnación de1 tamaño
197
¡a r.s¡imación del esfuerzo 198
i{ Esdmación de la Planificación
201
s. r'" Estimaciones simples de planificación """"""
214
s.
-. Refinamiento de las estimaciones .""""""""
220
Bibliografía adicional..'..
223
224
9.1. Planificación excesivamente opttmtsta
239
9.2. Disminución de la presión de la planificación
251
253
10. Desarrollo orientado al cliente
254
10.1. Importancia del cliente en el desarrollo rápido
2s9
t0.2. Métodos orientados al cliente
264
10.3. Gestión de las expectativas del cliente
267
Bibliografía adicional .....
269
11. Motivación
11.1. Motivaciones típicas del desarrollador .......... 271
\t.2, Uso de los cinco factores principales de motivación """""""' " 274
I 1.3. Uso de otros factores de motivación.'............
283
11 .4. Destructores de 1a morai " 28'7
Bibliosrat'ía adicional ....... 293
29s
12. Equipo de trabajo
297
12.1. Usos de 1os equipos de trabajo en el sofnvare """"""""
12.2. Importancia del equipo de trabajo para un desarrolio rápido 298
301
12.3. Creación de un equipo de alto rendimiento
12.4. Cawas de fa1lo de 1os equipos ..'......"".. 3t2
12.5. Configuración de equipos a largo plazo ....".... 3r6
12.6. Resumen de directrices para grupos de trabajo 318
Bibiiografi a adicional ...... 319
13. Estructura del equiPo 32I

13.1. Consideraciones sobre la estructura del equipo 324
13.2. Modelos de equiPo 328
13.3. Directivos y responsables técnicos 338
ü¡ommntnuuu
343
lmu'nr ü ctm[il¡mi üe pnestaciones....""'.....
.u -¡T r¡r*ffu r:-c--¡rJrr: reducción dei conjunto de presiaciones.........'.... 345
i - i:;*:¡ ¡r¿nzado: control de cambios de ias prestaciones 356
368
--t -: P::'.ecto a punto de terminar: recorte de prestaciones ..............
Biblioerafi a adicional....' 310
JIJ
15. Herramientas para aumentar la productividad.'..""'
15.1. papel de las herramientas de incremento de la productividad en el desarrollo
3',7 6
rápido
15.2. Estrategia de las herramientas para productividad""""""""' 381
382
\5.3. Aüquisrcibn de herramientas para $od\c\i\idtd """"""
15.4. Uso de herramientas para productividad .."""""""' 388
15.5. El síndrome de la panacea .............".. 393
Bibliografia adicional..... 400
16. Recuperación de proyectos ............ 401
16. l. Opciones generales de recuperación .....'..... 404

| 6.2. Plan de recuperación ........................ 405
4t9
PARTE III
MÉTODOS RECOMENDABLES
Introducción a los métodos recomendables .............. 422
Organización de los capítulos de métodos recomendables ..........'... 424

Resumen de los candidatos a métodos recomendables............... 421
Resumen de las evaluaciones de los métodos recomendables ........... .. 434
17. Grupo de control de cambios 437
18. Construcción y prueba diarias 439
t9. Diseño para el cambio 451
20. Entrega evolutiva 461
21. Prototipado evolutivo 469
J) Definición de objetivos ................. 481
23. Inspecciones ................. 483
24. Desarrollo conjunto de aplicaciones (JAD) 48s
)É, Selección del modelo de ciclo de vida 501

Contenido xl
2ó E 503
27. h úirtura................ 519
2t" llerrr¡[o externo (Outsourcing) ................. 529
29. lYcariecnón conveniente 543
30. Erü¡rnos productivos 545
31. I-crguajes para desarrollo rápido (LDR) .. 555
32. Filtrado de requerimientos 565
33. Reutilización ................ 567
34. Compromiso (Signing AD.............. 581
35. Modelo de ciclo de vida en espiral 589

36. Entrega por etapas .........j.......... 591
37. Gestión Theory-W 603

38. Prototipos desechables ..............:..... 615
39. Desarrollo en ventanas temporales .:.................. 621
44. Grupo de herramientas.......... .. 631

41. Lista de los 10 riesgos principales 633
42. Prototipado de la interfaz de usuario ................. 635
43. Iloras extras voluntarias 645
Bibliografia 655
Índice 66s
Eiemplos
2.1. Desarrollo rápido sin una estrategia clara 10

), Desarrollo rápido con una estrategia clara 31
3.1. Er:rores clásicos 36
4.1. Falta de fundamentos de desarro11o............... 60
5.1. Falta de gestión de riesgos al contratar 91
(t Gestión de riesgos sistemática I 15
6.1. Vagando por el inicio difuso .. 137
7.1. Selección de un modelo ineficaz de ciclo de vida........................... 146
7.2. Selección de un model o eftcaz de ciclo de vida 172
8.1. Estimación de proyectos a ojo........... 178
8.2, Estimación cuidadosa de proyectos .................. 2t7
9.1. Negociación correcta de la planificación 249
10.1. El arma de los requerimientos (l.u parte).......... 255
10.2. El arma de los requerimientos (2.u parte).......... 266
11.1. Un almuerzo frustrante con el jefe ............. 270
11.2. Un entorno con fuerte motivación 291
12.1. ¿A esto le llama un equipo? 296
12.2. Un equipo de alto rendimiento 300
12.3. Selección típica de los miembros de un equipo 305
12.4. Un segundo equipo de alto rendimiento 318
13.1. Discordancia entre los objetivos del proyecto y la estructura del equipo 321
13.2. Concordancia entre los objetivos del proyecto y la estructura del equipo .......... 340
14.1. Gestión efectiva de los cambios 369
15.1. Uso ineficaz de las herramientas 374
15.2. Uso eficaz de las herramientas 399
16.1. Recuperación fallida de unproyecto.............. 402
16.2. Recuperación con éxito de un proyecto.............. 416
xilt
}{
Tablas de consulta
2.1. Características de los enfoques estándar de desarrolio orientado a la planifrcación. 23

'r) Comparación del método a destajo (code-like-helf) con el método propuesto
en este 1ibro............ 30
Resumen de los errores clásicos 51
Niveles de gestión de riesgos 92
Riesgos más habituales en planificación......... 95
Riesgos potenciales de la planificación 95
Ejemplo de tabla de estimación de riesgos I02
Ejemplo de tabla de estimación de riesgos priorizada .. 105
Métodos de control de los riesgos más habituales en planificación......... 109
Ejemplo de una lista de <Los l0 riesgos principales> .. ll2
Distribución aproximada de actividades por tamaño del proyecto .. 135
Ventajas e inconvenientes de los modelos de ciclo de vida l'70
Multiplicadores de estimación por fase del proyecto 183
Multiplicadores de puntos de función 191
Ejemplo del cálculo del número de puntos de función 192
Eiemplo de estimación de cuantificación de riesgos 196
Ejemplo de estimación basada en casos...... 196
Ejemplo de estimación de factor de confianza 197
Exponentes para calcular planificaciones a partir de puntos de función 201
Planificaciones lo más cortas posible 205
Planificaciones eficientes................ 210
Planificaciones nomina1es................ 212
Ejemplo de historia de estimación con valores puntuales 215
Ejemplo de historia de estimación con rangos ................. 215
Historia de la planificación de Word para Windows 1.0 226
Comparación de las motivaciones para analistas programadores frente a las de
directivos y personas en general 272
rt fu*ors"sa
Iu- rsr*-""¡n de hs equipos de trabajo frente a los objetivos a optimizar .......... 277
llr llc*i¡cs bisicas para miembros y responsables de equipos.. 319
l.l.L O*r¡vos y estructuras de los equipos 326
l5-l- Ejemplo del ahorro obtenido al pasar de 3GL a 4GL la mitad de un proyecto
con 32.000 LDC ........... 391
15.2. Ejemplo del ahorro obtenido al pasar de 3GL a 4GL todo un proyecto con
32.000 LDC ........... 392
IIr.1. Resumen de los candidatos a métodos recomendables ............... 429
tll.z. Resumen de las evaluaciones de los métodos recomendables............... 434
26.1. Ejemplos de tipos de datos a medir....... 507
26.2. Ejemplo de actividades para control de tiempo 508
ii
28.1. Cuestionario parala evaluación de vendedores................ 536
28.2. Consideraciones sobre contratos .537
30.1. Diferencias en entornos de trabajo entre los mejores y los peores participantes
¡
en una competición de programación............. 553
31.1. Conversiones aproximadas de puntos de función a líneas de código 557
l 31.2. Niveles aproximados de los lenguajes 559
36.1. Ejemplo de planificación con entrega por etapas de un tratamiento de textos.... 595
37.1. Implicados en un proyecto y sus objetivos 604
37.2. Pasos en la gestión de proyectos Theory-W 606
Prólogo
Los desarrolladores de software están atrapados entre dos fuegos. Uno de

ellos consiste en que los desarrolladores trabajan muy duro, y no tienen
tiempo para aprender métodos de trabajo eficaces que pueden resolver la
mayoría de problemas relacionados con el tiempo de desarrolio; el otro
fuego consiste en que no van a tener tiempo hasta que aprendan más so-
bre desarrollo rápido.
Otros problemas de nuestro entomo pueden esperar. Resulta duro justifi-
car la necesidad de tiempo para aprender más sobre calidad cuando se sufre
una intensa presión de fechas para <terminar como sea>. Resulta duro apren-
der sobre reusabilidad cuando se ha trabajado 20 días seguidos y no se ha
tenido tiempo parat al cine, ir de compras, salir, leer el periódico, cortar el
césped o jugar con los niños. Hasta que nosotros como industria aprendamos
a controlar nuestras planificaciones y liberar tiempo para que los desarrolla-
dores y directivos aprendan más sobre sus profesiones, nunca tendremos
tiempo suficiente para poner en orden el resto de nuestros asuntos.
El problema del tiempo de desarrollo es importante. En varios estu-
dios realizados, se indica que alrededor de dos tercios de todos los proyectos
superan ampliamente sus estimaciones (Lederer y Prasad, 1992; Gibbs,
1994; Standish Group, 1994). Los grandes proyectos se retrasan en su
fecha de entrega entre un 25 y un 50 por 100 de su duración, y el retraso
medio se incrementa con el tamaño del proyecto (Jones, 1994). Año tras
año, las cuestiones sobre desarrollo rápido aparecen en los primeros puestos
de las listas sobre temas más críticos a los que se enfrenta la comunidad
dedicada al desarrollo de software (Symons, 1991).
Aunque el problema del desarrollo lento es importante, algunas orga-
nizaciones implementan sus desarroilos con rapidez. Los investigadores
han encontrado diferencias de hasta diez veces en productividad entre
empresas del mismo sector, y algunos investigadores han llegado a en-
contrar variaciones mayores (Jones, 1994).
El propósito de este libro es ofrecer a los grupos que están actualmen-
te en el lado <1> de esta relación de <1 a 10> la información que necesi-
tan para pasar al lado <10>. E,ste libro le ayudaú a mantener sus proyec-
tos bajo control. Le ayudará a proporcionar una mayor funcionalidad a
sus usuarios en menos tiempo. No tiene que leer todo el libro para apren-
xvil
der algo útil; independientemente del estado en que se encuentre su pro-
yecto, encontrará metodologías que le permitirán mejorarlo'
¿Quién debe leer este libro?

El desarrollo lento afecta a todas las personas involucradas en el desarro-
llo de software, incluyendo desarrolladores, directivos, clientes y usua-
rios finales (e incluso sus familiares y amigos). Cada uno de estos grupos
tiene parte en la resolución del problema del desarrollo lento, y en este
libro hay algo para cada uno de ellos.
Este-libro ha sido concebido para intentar ayudar a los desarrolladores
y directivos para que sepan lo que es posible, para ayudar a los directivos y
.li.rrt., u ,ut", lo que és realista y pafa servir como vía de comunicación
entre desarrolladores, directivos y clientes, para que puedan consensuar
el mejor método posible para cumplir su planificación, coste, calidad y
otros objetivos.
Responsables técnicos
Este libro ha sido escrito principalmente pensando en los responsables
técnicos o de los equipos. Si ésta es su función, generalmente tendrá la
responsabilidad de incrementar |a velocidad de desarrollo de software, y
este libro le explica cómo hacerlo. Describe además los límites de la velo-
cidad de desarrollo, para que disponga de unos fundamentos sólidos para
distinguir entre programas realistas de mejora y puras entelequias.
Algunos de los métodos de trabajo descritos en este libro son radicalmen-
te técnicos. Como responsable técnico, no debería tener problemas al im-
plementarlos. Otros métodos están más orientados a la gestión, y podria
preguntarse por qué se incluyen en el libro. Al escribir el libro, he asumi-
áo la hipótesis de que el lector es el Superjefe Técnico: más rápido que un
hacker; más poderoso que Superman; capaz de mantener a raya problemas
técnicos y de gestión. Esto es algo utópico, ya lo sé, pero evita tener que
repetir constantemente: <Si es un directivo, haga esto, y si es un desarrolla-
dor, haga esto otro.> De todos modos, suponer que los líderes técnicos son
responsables de los aspectos técnicos y de gestión no resulta ningún dis-
parate. A menudo, los responsables técnicos son requeridos por los respon-
iables principales para hacer recomendaciones sobre cuestiones de gestión
con aspectos técnicos, y este libro le aludará a prepararse para ello'
Programadores individuales
Muchos proyectos software son llevados a cabo por programadores indi-
viduales o equipos autogestionados, y tienen participantes técnicos en
Prólogo xtx
puestos que de hecho son de responsable técnico. Si ésta es su función,

este libro le ayudará a mejorar su velocidad de desarrollo, por las mismas
rÍLzones que a los responsables técnicos de buena voluntad.
Directivos
En orcusimes- krs di¡ectivos piensan que alcanzar el desarrollo rápido de
softrze es fudamentalmente un trabajo técnico. Sin embargo, si es un
directiru. gffirlmÉrte podrá ayrdar tanto como sus desarrolladores a
mejorrr h r',elail¡d de desarroll'o- Este Libro describ€ muchas técnicas
de desrrollo ripirto I uircl de dirección- Eridentsmen¡¿- tarnbién puede
leer los Eétodas de tipo Écili@ púr cmprErdsr lo qrc plre&n bacer los
programadores en s nirel-
Beneficios fundamentales del libro

He pensado este libro como un compendio de Sentido común para los
desarrolladores de software. Como el Common.9ense original de Thomas
Paine, que describía en términos pragmáticos por qué América debia se-
parase de la Madre Inglaterra, este libro describe en términos pragmáti-
cos pof qué muchos de nuestros puntos de vista sobre el desarrollo nipido
son falsos. Ha llegado el momento en el que se esfá despertando el alma
de los programadores, y por ello, este libro aboga por su pequeña revolu-
ción particular en los métodos de desarrollo de softn'are.
Desde mi punto de vista respecto al desarrollo de software, los pro-
yectos software pueden optimizarse para uno de varios objetivos: menor
tasa de defectos, mayor velocidad de ejecución! mayor aceptación por parte
del usuario, mejor facilidad dg p¿atg imisnto, msnor coste o menor tiempo
de desarrollo. Parte del enfoque ingenieril del software consiste en equili-
brar los diversos factores: ¿Podemos optimizar el tiempo de desarrollo a
costa de la calidad? ¿A costa de la facilidad de uso? ¿Exigiendo a los
desarrolladores que trabajen horas extras? Cuando llega la hora de la ver-
dad, ¿cuál es realmente la reducción de tiempo que puede alcanzar? Este
libro ayuda a resolver estas cuestiones sobre equilibrio de factores, así
como otras muchas cuestiones.
Mejora en la velocidad de desarrollo. Puede usar la estrategia y los

métodos recomendables descritos en este libro para alcanzar la mayor ve-
locidad de desarrollo posible según sus circunstancias particulares. Al cabo
de un tiempo, la mayoría de las personas pueden lograr mejoras drásticas
en la velocidad de desarrollo aplicando las estrategias y métodos descri-
tos en este libro. Algunos métodos recomendados no funcionan en ciertos
tipos de proyectos, pero para virtualmente cualquier tipo de proyecto en-
Xf Wgo
contrará otros métodos que funcionarán. Dependiendo de sus circunstan-
cias, la <velocidad máxima de desarrollo" puede no ser tan rápida como
desea, pero nunca será un completo desgr¿ciedo por no poder usar un len-
guaje de desarrollo rápido, estar manteniendo código ánterior o trabajar
en un entorno ruidoso e improductivo-
El desarrollo ráp¡do se basa en ternas trnÍcioriales. Algunos de los

métodos de trabajo descritos en este libro no se contemplan generalmente
dentro de las técnicas de desarrollo rápido. Técnicas tales como la ges-
tión de riesgos, los fundamentos del desarmllo de software y la planificación
del ciclo de vida son más bien vistas cmo r<buenos métodos para desa-
rrollo de software>> más que como metodolog:ías de desarrollo rápido.
Sin embargo, estos métodos tienen profimdas implicaciones en el de-
sarrollo rápido, que en muchos casos superan a los pretendidos métodos
de desarrollo rápido. Este libro pone d€ manifiesto los incrementos de la
velocidad de desarrollo debidos a est(F métodos, usados en combinación
con otros.
Enfoque práctico. Para algunas p€rsonas, <<práctico> significa <codi-

ficación>, y para estas personas- debo admitir que este libro no debe re-
sultarles muy práctico- He evitado las tecnicas orientadas al código por
dos razones. En primer lugar, ya he escrito 800 páginas sobre técnicas
efectivas de codificación en Code Complete (Microsoft Press, 1993). No
tengo mucho más que decir al respecto. En segundo lugar, resulta evidente
que muchos de los temas críticos sobre desarrollo rápido no están centra-
dos en el código, sino que son estratégicos y filosóficos. En ocasiones, no
hay nada más práctico que una buena teoría.
Organización para una lectura ág¡1. He hecho todo lo posible para

presentar la información sobre desarrollo rápido de este libro del modo
más práctico posible. Las 400 primeras páginas del libro (Partes i y II)
describen una estrategia y filosofía de desarrollo rápido. Se han inte-
grado alrededor de 50 páginas de ejemplos, para que pueda ver cómo
actúan la estrategia y la frlosofia en la práctica. Si no le gustan los ejem-
plos, han sido formateados para poder saltarlos fácilmente. El resto del
libro contiene un conjunto de métodos recomendables para el desarrollo
rápido. Los métodos están descritos en un formato de consulta rápida,
para que pueda pasar las hojas rápidamente y localizar los métodos
que se adapten mejor a sus proyectos. El libro describe cómo usar cada
método, el tiempo de reducción que cabe esperar y los riesgos que es ne-
cesario vigilar.
El libro también usa ampliamente iconos y texto en el margen para
ayudarle a encontrar rápidamente información adicional relacionada con
el tema sobre e1 que está leyendo, evitar errores clásicos, marcar los mé-
Prólogo xxi
todos recomendados y apoyar con cifras muchas & las afirmaciones rea-
lizadas en este libro.
Una nueva forma de pensar sobre el desarrollo níp¡do. No hay

otra área de la ingeniería del software en la que haya tanta desfuforma-
ción como en el desarrollo rápido. Muchas técnicas de desermllo prácti-
camente inútiles han sido tildadas recientemente coüx) {tétdcas de desa-
rrollo rápido>, lo que ha hecho que muchos desarrolladores obssrr-en con
cinismo las afirmaciones sobre cualquier método de desarrollorápido- Hay
otros métodos genuinamente útiles, pero han sido encumbrados t¡n por
encima de sus posibilidades reales que, al final, también ha cmtribuido
a incrementar el cinismo de los desarrolladores.
Cada vendedor de herramientas y cada vendedordeffilogí$desea
convencerle de que su nueva panacea será la respues¡e a gs mesidades
de desarrollo. En ninguna otra área del softwa¡e tendrá t-¡n¡o trabajo para
separar la paja del grano. Este libro ofrece directrices para melizar la infor-
mación sobre desarrollo rápido y encontrar los escasm gr¿oc de r-erdad-
Este libro ofrece modelos mentales rápidos que le a soPesar
lo que 1e dicen los vendedores de panaceas, y le ayudarán también a in-
corporar sus propias ideas. Cuando alguien entra en sr despacho y dice:
<¡Acabo de enterarme de que ha salido una nueYa heffimiúTre fantástica
de GigaCorp Silver Bullet Company que Ya a reúrcir nrnrtro ticmpo de
desamollo en un 80 por 100!>, sabrá cómo reaccioner- No imporfa que el
libro no diga nada específico sobre GigaCorp Sih-er BuIlfi Company o su
nueva herramienta. Cuando termine de leer el l¡ibro, sebrá las preguntas
que debe plantear, el caso que debe hacer a las efirm¡ciones de GigaCorp
y cómo incorporar su nlleva herr'¿mienra en srr cntrrrx) de desarrollo, si
decide hacerlo.
A diferencia de otros libros sohc dr'$¡rrollo rápido, no le estoy pi-
diendo que se juegue todas s¡rs bazrs a ma única czrta, la misma para
todo el mundo- Reconozco que diferenres Foyoctos tienen diferentes ne-
cesidades, y que cür rm rinico metodo mágico no basta para resolver tan
siquiera los problemas de plmificación de un proyecto. He intentado ser
escéptico sin ser cínico, siendo crítico sobre la efectividad de los méto-
dos, pero absteniendome & nqoner que no funcionan. He vuelto attatar
las antiguas y ensalzadas fumas de trabajo, recuperando algunas que si-
guen resultando genuinamente útiles, aunque no sean tan útiles como se
prometió originalmente -
¿Por qué es tan grande este libro sobre desarrollo rápido? Los
desarrolladores de los ámbitos de los sistemas de infortnación, paquetes
soítware, aplicaciones militares e ingeniería del software han descubierto
valiosas técnicas para desarrollo rrápido, pero las personas de estos distintos
ámbitos raras veces intercambian opiniones. Este libro recoge las técnicas
xxil aróbgo
más interesantes de cada ámbito. combinandL- ¡Lar primera vez información

sobre desarrollo rápido procedente de ''r¿ anqlia i'ariedad de fuentes.
tendrá realmente tiem-
¿Alguien que necesite aprender desai:.r-:r- :ápido
po para leer 700 páginas sobre el tema.- E> ;'".stbie que no, pefo un libro con
la mitad de tamaño tendría tal nivel de sin:.::'icación que llegaría a resultar
inútil. Para compensar, he organizado ¿l ,:'l:o de modo que pueda leerse
con rapidez y de forma selectiva: pue ie -ee: secciones breves mientras
viaja oestá esperando. Los Capírulos 1 1 I üünriienen e1 material que tiene
qré 1.., pafa comprender cómo desarrolXar productos con más rapidez.
Tras leer estos capítulos, podrá leer 1o qut nás le interese'
Por qué se ha escrito este libro

Generalmente, la primera respuesta de clientes 1' directivos al problema
del desarrollo lento es incrementar la presión de planificación y las horas
extras de los programadores. E1 erceso rtre presión de planificación está
presente en alrededor del 75 por 1Ott de todos los grandes proyectos, y se
i""r"u al 100 por 100 en los provectos mu) grandes (Jones, 1994). Prác'
ticamente el 6b por 100 de los ,Jesarrolladores comentan que su nivel de
estrés aumenta progresivamente (Glass. 1994c). En Estados Unidos. e1
desarrollador medio trabaja de -tB a 50 horas a la semana (Ktanlz,1995).
Hay muchos que traba-ian bastante más.
En este entomo, no resulta sorprendente que la satisfacción general en el
empleo de los desarrolladores de software haya disminuido notablemente en
los últimos 15 años (Zawacki. 1993), y en un momento en el que la indus-
tria necesita desesperadamente reclutar nuevos programadores para sua-
vizarlapresión de la planificación, los desarrolladores están diciendo a su.
hermanos menores e hijos que nuestro campo ya no resulta divertido.
Claramente, nuestro campo puede ser divertido. Muchos de nosotrc'ts
entramos en é1 originalmente porque no podíamos cleer que se cobrara
dinero por desarrollar software. Pero actualmente no es tan divertido. h:
sucedido algo, relacionado con el tema del desarrollo rápido'
Es hora de comenzar a elevar el dique que separe a los desarrolladore.
del software del mar de la locura de la planificación. Este libro es un r:-
tento particular de levantar unos centímetros este dique. mantenie¡li¡ '"
locura suficientemente lejos como para poder comenzat a trabajar'
Agradecimientos
\{is primeros asrade.-imientos van dirigidos a Jack Lites'ka. edr::: l:-
pro).ecto. por hacer de la r--reación de este libro una erpenenci: .'..rl-il---
tiva 1-dir-ertida. Quiero darles 1as sracias también a Kim Eggies:"-- ::: =
Prólogo xxilt
diseño del libro, a Michael Victor por los diagramas y a Mark Monlux
por sus terribles ilustraciones. Sally Brunsman, David Clark, Susanne Freet,
Dean Holmes, Wendy Maier y Heidi Saastamoinen también han contri-'
buido a la progresión de este proyecto. Hay literalmente docenas de otras
personas que han contribuido a este libro de un modo u otro; no he tenido
contacto personal con ninguna de ellas, pero aprecio su contribución (en-
tre ellas, me han dicho que están la dibujante Jeannie McGivern y el
jefe de producción Jean Trenary, de ArtSource, y el equipo de pruebas y
edición de copias de Microsoft Press, supervisado por Brenda Morris: Ri-
chard Carey, Roger LeBlanc, Patrick Forgette, Ron Drummond, Patricia
Masserman, Paula Thurman, Jocelyn Elliott, Deborah Long y Devon Mus-
grave).
La bibliotecatécnica de Microsoft Corporation ha ofrecido una ayuda
inestimable para recopilar los cientos de libros y artículos en que se basa
este libro. Keith Barland ha encabezado esta labor, haciendo que mis tra-
bajos de investigación hayan resultado mucho más rápidos y fáciles de lo
que hubieran sido sin ella. Otras personas de la biblioteca que también
han participado son Janelle Jones, Christine Shannon, Linda Shaw, Amy
Victor, Kyle Wagner, Amy Westfall y Eilidh Zuvich.
He destacado las virtudes de las revisiones en varios lugares de este
libro, y éste se ha beneficiado ampliamente de revisiones de compañeros.
Al Corwin, Pat Forman, Tony Garland, Hank Meuret y MaII Peloquin
han estado en el proyecto de principio a fin. Gracias a ellos, ¡el libro que
tienen en sus manos no se parece mucho al que iba a escribir en un prin-
cipio! También he recibido comentarios interesantes de Wayne Beards-
ley, Duane Bedard, Ray Bernard, Bob Glass, Sharon Graham, Greg Hit-
chcock, Dave Moore, Tony Pisculli, Steve Rinn y Bob Stacy (siempre
críticas constructivas). David Sommer (de 11 años) me dio la idea del
último panel de la Figura 14.3. Gracias, David. Y, por último, tengo que
dar las gracias a mi esposa, Tammy, por su apoyo moral y buen humor.
Tengo que comenzar a escribir mi tercer libro inmediatamente, ¡para que
deje de tirarme serpentinas y llamarme Gran Autor!
Bellevue, I4ashington
Junio de 1996
1
Bienvenido
al 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ólogo
Beneficios fundamentales del libro: Prólogo
¿Por qué se ha escrito este libro?: Prólogo
Estrategia para el desarrollo rápido: Capitulo 2
Cuestiones fundamentales para el desarrollo rápido: Capítulo 6
EL RESPONSABLE DE PRODUCTOS ME DIJO que quería desarrollar

un 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 única
prioridad real era poner e1 producto a la venta 1o antes posible. ¿Usabili-
dad? No tenemos tiempo. ¿Rendimiento? Puede esperar. ¿Facilidad de
mantenimiento? Para el próximo proyecto. ¿Verificación? Nuestros usua-
rios quieren el producto ahora. Hay que terminar como sea.
Este responsable de productos en particular no era 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 comportamiento
se repite todos los días, en todos los estados y en todos los países. El
tiempo de desanollo se ha convertido en una prioridad tan importante que
ha ce-eado a las personas sin dejarles ver otras consideraciones importan-
tes. incluso algunas que afectan al final al tiempo de desarrollo.
imw¡¡nilillü ü l[wil¡cr.r a: Í/r:illems -c'nat,rcs
l*L ¿0É es el desarrollo rápido?

J=: ¡-gunas personas. el desarrollo rápido consiste en aplicar una unlca
,:=¿lnienta o método. Para e1 hacker, ei desarrollo rápido consiste en
;¡1it-rcar 36 horas de un tirón. Para el ingeniero de sistemas de informa-
:ron, es R\D (una combinación de herramientas CASE, la participación
intensiva del usuario y ventanas temporales estrictas). Para el programa-
dor de mercado, consiste en usar prototipado rápido con la última versión
de Microsoft Visual Basic o Delphi. Para el directivo desesperado por
acortar una planificación, es cualquier método recomendado en el último
número de Business Week.
Cada uno de estos métodos y herramientas va bien hasta un cierto
límite, y cadauno puede contribuir a incrementar la velocidad de desarro-
1lo. Pero para obtener todo el beneficio posible, cada uno tiene que estar
coordinado dentro de una estrategia global. Ninguno de ellos es aplicable
a todos los casos, y ninguno puede compararse frente a otras técnicas que
generalmente no son consideradas como técnicas de desarrollo rápido,
pero que sin embargo tienen profundas implicaciones en la velocidad de
desarrollo.
En lugar de identificar una herramienta o método específicos, en 1o
que respecta a este libro el <desarrollo rápido> es simplemente una frase
descriptiva opuesta a <desaroilo lento y típico>. No es Desarrollo Rá-
pidorM,una frase o palabra mágicas. No es una fulgurante metodología de
desarrollo rápido Blaze-O-Matic o Gung-HO-OO. El desarrollo rápido
es un término genérico que significa lo mismo que <desarroilo veloz> o
<planificaciones más cortas>. Significa desarrollar software a una veloci-
dad superior ala alcanzada en este momento.
Entonces, un (proyecto de desarrollo rápido> es cualquier proyec-
to que necesite hacer énfasis en la velocidad de desarrollo. En las cir-
cunstancias actuales, esta descripción se adapfa a gran cantidad de pro-
yectos.
1.2. Cómo lograr el desarrollo rápido

El camino marcado en este libro es claramente la ruta menos transitada en
la industria actual. Pasar por la ruta menos transitada puede parecer arries-
gado. Pero la ruta más concurrida esla que actualmente está redundando
en costes masivos y retrasos en la planificación, baja calidad, proyectos
cancelados, muchos cambios de personal, fricciones entre directivos, desa-
rrolladores y clientes, y todo el resto de problemas que estamos tratando
de er.itar.
Si trabaja en una organización normai y sigue los métodos descritos
4*nf:krtdffitt
en este libro, podrá reducir significativamente s --
I & ¡.-rq
puede que hasta la mitad, e incrementar tambien su proücririfl-,ilü- {':
más, podráhacerlo sin aiterar 1a calidad, e7 coste, el renü,,,iaroo le fuF

lidad de mantenimiento. Sin embargo, la mejora no será instanránea- m h
obtendrá a partir de una unica y nueva herramienta o método. v no
le alcanz¡rá cogiendo simplemente el paquete de ra estantería. Requerirá
tiempo y esfuerzo.
Para tdo yoblema Hubiera deseado tener una solución sencilla para el probrema de la
complejo hor una velocidad de desarrollo. También me gustaría tener cinco millones de
resFruesta corta,
simple y errónea. dólares. Pero las soluciones simples tienden a funcionar sólo con proble-
H. L. Ilencken mas sencillos, y el desarrollo de software no 1o es. El desarrollo rápido de
software 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 este con-
junto, el subconjunto de métodos también es grande. En un proyecto en
particular, sólo se utiliza un pequeño subconjunto de estos métodos.
Visto por encima, para tener éxito en el desarrollo rápido se requieren
dos cosas:
o Seleccionar métodos eficaces en lugar de métodos ineficaces.

o Seleccionar métodos orientados específicamenle a alcanzar sus obje-
tivos de planificación.
Figura 1.1. Conjunto de todos los métodos para desarrollo de software.

La velocidad de desarrollo depende de la selección de los métodos de
desanollo. La velocidad con que desarrollemos cualquier programa
@ncreto dependerá de la proporción de métodos eficaces y de métodos
orientados a Ia planificación que seleccionemos.
Desarrollo y gestión de proyectos informáticos
t
l
Podríamos pensar que esto es obvio, pero como se explica en ei Capi-
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 1a márima certeza en los plazos, seleccionan prácti-
cas de alto riesgo. que rei'-rcen ia posibilida d de alcanzar las fechas límite
fijadas. Cuando necesira::r reducir costes, seleccionan métodos orientados
a la velocidad. que :r.-:emenran los costes. En estas empresas, el primer
paso hacia la meiora ,je la velocidad de desarrollo consiste en admitir que
están seleccionari.. :neronlos ineficaces, y a partir de ahí comenzar a e1e-
gir métodos e:'i.-¿c:s.
En 1a Fi_sr..rra i.l. todos los métodos efectivos orientados a la p1anifi-
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 1a
planificación:
o Métodos que mejoran la velocidad de desarrollo, permitiendo en-

tregar antes el software.
o Métodos que reducen el riesgo en la planificación, permitiendo evitar
grandes retrasos de planificación.
o Métodos que hacen visible el progreso, permitiendo disipar la im-
presión de tener un desarrollo lento.
Los tipos específicos que 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
Métodos orientados
a la planificación
Figura 1.2. Hay tres tipos de métodos orientados a ta ptanificación:

métodos que permiten desarrollar más rápido, que reducen el riesgo en td
planificación y que hacen visible et progreso.
l-
Blenvenido al cesarrollo rápido
= :locidad de desarrollo. Si piensa

r;:ta. y que el problema radica en
,,- , .': por parte del cliente, debería
- - ' .-r:biiidad.
--. , :: :-ltritcación junto con un plan
:,: r';.-:as drásticas y reales en
; - - -: ..::: *n soltrvare <eiixir>
: - i :,-:r!-sto.seleccio-
-'-:... r:ro dilícii
L
Estrategia para
el desarrollo Épido
Contenido
2.1. Estrategia general para el desarollo ri1*b
2.2. Ctafto dimensiones de la r-elridad ¿g.hsÍotlo
2.3. Tipos generales de desarrollo rápido
2.4. ¿Cuál es la dimensión más imporunte?
2.5. Una estrategia alternativa para el desarrollo rápido
Temas relacionados
Errores clásicos: Capítulo 3
Bases del desarrollo de software: Capitulo 4
Gestión de riesgos: Capítulo 5
Cuestiones fundamentales para el desarrollo rápido: Capítulo 6
SI COGIÉSEMOS lOO MÚSICOS DE PRESTIGIO ANTVEL MUNDIAL

y los pusiésemos en una orquesta sin di¡ector- no sonarian como una or-
questa de calidad. El tempo de la sección de cuerda no coincidiría con el
de la sección de madera y viento o con la sección de metal. Indicar a los
músicos que lo hagan <lo mejor que puedao> no les ay'uda a saber si de-
ben ir más rápido o más lento. Semejante eyento musical sería un desper-
dicio de talento.
En el desarrollo de software se produce un desperdicio similar de ta-
lento. Equipos de desarrolladores inteligentes y dedicados utilizanlas téc-
nicas mejores y más recientes, y siguen sin poder alcanzar sus objetivos
de planificación.
Una de las trampas más tentadoras en las que cae la gente que quiere
desarrollar más rápido consiste en centrarse sólo en métodos de desarro-
llo orientados a planificación. Podríamos ejecutar el prototipado rápido
'
i
I hnÚygs*h$@s inbrmát*rc
perfectamente, pero si cometemos un error no obtendremos un desarrollo

rápido (<<¡Vaya!, en la planificación hemos olvidado incluir tiempo para
- hacer el subsistema de impresión>>). Las técnicas concretas orientada-< a
planificación son sólo pbrte de lo que necesitamos para obtener el pim
más corto posible. También se necesita un entorno global que permita
utilizar estas técnicas con el máximo beneficio.
De a{uí en adelante este capítulo propone una estrategia orquestada
para conseguir un desarrollo rápido.
Ejemplo 2.1 . Desarrollo rápido sin una estrategia clara
(continúa)
Capítulo 2: Estrategia para €:,J:-s..-cllo rápido 1i
ta a tiempo)). dijo John.,<La última vez los desarrolladores estur jcrrrn

ha-
ciendo cambios hasta er final. El archivo LEAME tenía 20 pági-na:.
más'gnrevesadas. Lol manuales de usuario estáa,sie¡do dest¡o1a¿os
¡ adc-
eo ta.
revis!*nes. siempre e4e.estés de ácuerd c , ne¡ liste una versión
con la
intérfuz definitiva, el método de desarollo óarece eorrecto.)),,
'. aNecesita la versión defrnitiva más o,menos en la mísriia fácha para
'escribir secuencias automáticas de prueba>, añadió Heren. Mickey:aeept¿
'eI plapteár*iento de ia'ersión definitiva. Kim aprobé la estraFgía gtolat
wa
,de Mickey y le dijo que le dejase organizarse. l
cón sus,despachos individuales, sus nuevos ordenadores 1os refrescos,

¡,
así qrle empézaron iuerte.
No tardaron mucho en quedarse voluntariamenfe
a trabajal por la tarde.
Los meses pasaban. y hacían progresos constantes. pronto construle-
ron un prototipo. y continuaron generando cócligo. La directiva mantenia
la presión. John recordó a Mickey varias veces su acuerdo de tener la ver-
,si-ón con,el áspecto definilivg 9n 8 mgseqo gosaque,.X4íckey encortró
irri_,
tante. pero todo parecía progresar bien.
En el cuarlo mes del proyecro Bob volvió de su viaje en bicicleta,
fres-
co. e irrumpió en el proyecto con nuevas ideas que había concebido mien-
lras^pedaleaba. Mickey estaba preocupado por si Bob podría implementar
las lunciones que necesitaba en el riempo disponible. péro Bob estaba com-
prometido con sus ideas y garanrizaba ra enirega a tiempo sin imponar
ro
mucho que ruviera que trabajar.
cada miembro del equipo rrabajaba individuarmente en su parre, y como
la enrrega de la versión óon ra inteifaz definitiva se apro*imatu.
.on'.nru-
ron a,integrai el código, comeazároa á 1a1,2:00:de',tatardi ¿ut,,ál*,aote¡io :
ata entr3gq de laversión definiriváypronto,de$cubrieron que su programa ,
no compilaba. y rnenos aún se ejecutaba. El código combinado "uarias

t.nía
docenas de errores de sintaxis, y parecía que cada uno que se
corregía ge-
'nerab.a:otfos l'f),',A, n:edianochsl iiécidier á;i"rru
por esa, noche,
-A,ia mañana siguionre; Kim qe reqnié eon éi óqaipo dÉt.¡r¡ir.. u
está lisro para entregarlo al equipo de documen{ación y prueLa?>
,<<Aún no¡r, dijo Miekey, <Tenemoq
atguno,s problemas en la integracióa;
podemos.lerrerloliqto eEt4,tarde,¡r,El equipo 1rabla¡ó
esa tarde y po, tioo.h",'
pera no consiguieron corregir fodos,los',eroies que,ens,xrtraián
Al final del
día adrnirieron que no renían ni idea de cuánto tiémpo ilevaría
tu int.gru.rJn.
Emplearon dos semanas compretas en corregir todos ros errores"
de sin-
taxis y tener el sisrema luncionando ar cornpreró. cuando.t
.quipo
gó la versión buena tras un retraso de dos sirnanas. "nir.-
los equipo, a" prr.Uu
r de documentación ra rechazaron inmediatamenre. (Es demasiado io.rru-
ble como para documenrarla>. dijo John. <Se uiu¡o l"¿, p".".,l
nuroi. I hav demasiadas opciones que no pueden "i.n.
probarse.>
Helen añadió: <lr{o tiene sentido escribir un infolrne,de:errsres,
si el
sistema cs tan inestabre que se inrerrumpe casi cada vez que
se hace una
etiüüton en el menú.>
(cont¡nuü)
L
,¿ -r Jeffr:r tr J-:rrefiüs mfurmáücos
2.1. Estrategia general para el desarrollo rápido

El modelo descrito en el Ejempio 2.1 es habitual. Evitar este modelo su-
pone un esfuerzo, pero apartarse de estos malos hábitos está dentro del
alcance de cualquiera. Se puede obtener un desarrollo rápido siguiendo
esta estrategia en cuatro partes:
Capítulo 2: Estrategia para el desarrollo rápido 13
1. Evitar los errores clásicos.

2. Aplicar las bases del desar¡ollo.
3. Gestionar los riesgos para evitar un retorno catastrófico.
+. Aplicar métodos orientados a planificación, como los tres mos-
trados en la Figura 1.2 de1 Capítulo 1.
Ct*.*. - s¡giEre en la Figura 2. 1 , estas cuatro técnicas ofrecen sopor-

E f¡ i w,rar criar. otrsible.
El desarrollo r$*t I-rs n¡gm.s c¡¡c pilares no le liaman Ia atención a nadie, pero los
del produm rea pil-cs & tm Dgn.'t Jc*ran varios Dunlos imponantes.
un método s4oa *
f,ü q:tF. E ri ¡rlü Fln puible es tener los cuatro pilares
tener eI prfutu a
el mett&:ft mlo*cr\n y¡--.p ú m & cllos sea lo m'ás fuerte po-
rápifutre siblc- Sin cl r4crc & hm puus FúrEs. hs pmr-bilidades de conse-
(probablenate 3'a guir el meirFh Fne cF¡ il Ftt€ro- Fodenos urilizar los métodos
esté retrasado¡. En
lugar de eso,6 úM más ¡mrcms üiEt& r hft¡ñctf¡¡- pero si crünetsmm el error clá-
capacidad sico & dFqr¡¡r h c|l|rlü ppr-| cl srs Éq iniciales, desperdi-
estratégira que ciaremos tfoqo cúr
-i***er¡EFs cd s5 mís caro. Nuestro
debería construirse
desde los cimientos.
pro-yecto s€ reü:rsri- Si pms por rh €t dE dc desarrollo de crear
un buen rlisrñn -Ca & eaztq'l. a c[rtñcrr_ ffio programa fallará
Preston G. Smith
y Donald G. cuando cdrÉ h cnSF¡¡ d pfu¡o fufre el proceso de desarro-
Reinertsen: llo, y el prolffio s rur¡¡ri Y si m cmr,olamos los ries-eos. podemos
Developing products descubrir jusco a[Er dr tr &shde effiege $¡e rm subcontratista clave se
ha retrasado tr6 mcscs qfu el plü- De nuero tendremos retraso.
ín Half the Time
Evitar Bases Gestión Métodos

errores del de orientados a
clásicos desarrollo riesgos la planificación
Figura 2.1 . Los cuatro pilares del desarrollo rápido. EI mejor plan posible
depende de evitar los errores clásicos, las bases del desarrollo y la gestión
de riesgos, además del uso de métodos orientados a planificación.
7
14 Desarrollo y gestión de proyectos informáticos
La figura también sugiere que los tres primeros pilares ofrecen la mayor
parte del soporte necesario para obtener el me-ior plan posible. Quizás no
sea el soporte ideal, pero es la ma¡-or pane de lo que necesitamos. Debe-
mos ser capaces de obtener un plan óptirno sin métodos orientados a pla-
nificación.
¿Se podría obtener el mejor plan porible centrándose únicamente en
métodos orientados a planificación? Se @ria hacer. La gente yaharca-
lizado antes proezas como ésta. Pem coilo muestra la Figura 2.2, es w
difícil problema de equilibrio. Puedo mantener en equilibrio una silla
en mi barbilla y mi perro puede mentEnel'en equilibrio una galleta en su
nariz. Pero la elaboración de un pro!-ecto softw-are no es un truco de sa-
lón, y si confiamos en que los métodos orientados a planificación hagan
todo el trabajo. probablemente no ten&€mos todo el soporte necesario. Si
1o hacemos una \-ez. puede que no s€amos capaces de hacerlo de nuevo.
Los tres primeros pilares mostrados en la Figura 2.1 son básicos para
el éxito del desarrollo rápido, así se hani lo posible para clarificar qué
quiere decir evitar errores clásicos, bases del desarrollo y gestión de ries-
gos. El Capítulo 3 trata los errores clásicos. En la mayoría de los casos,
estar avisado simplemente de la naturaleza de un error será suficiente para I
evitarlo, 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 tema r
de la gestión de riesgos en el Capítulo 5.
El resto del libro tata de métodos concretos orientados a planifica-
ción, incluyendo métodos orientados a velocidad, orientados a la planifi- I
Métodos
I
orientados a la
i
planificación
Figura 2.2. Resultado de centrarse solamente en métodos orientados a

planificación. Ni los métodos orientados a planificación más avanzados son t
capaces de soportar por ellos solos el mejor plan posible.
l_
cación de riesgos y orientados a la visibilidad.En la terce¡a parte del li-

bro, <<Métodos recomendables>>, se muestra el efecto de cada método en
la velocidad de1 desarrollo, planificación del riesgo y visibilidad. Si de-
sea pasar al desarrollo rápido en sí antes de leer acerca de los tres pasos
necesarios para conseguir las bases del desarrollo rápido, puede saltar al
Capítulo 6, <Cuestiones fundamentales para el desarrollo rápido>, y al
resto de capítulos.
2.2. Cuatro dimensiones de la velocidad de desarrollo

Tanto si nos hemos atascado en el lodo intentando evitar los errores como
si cruzamos a toda velocidad utilizando métodos orientados a planifica-
ción efectivos, nuestro proyecto software se desarrolla a través de cuatro
dimensiones principales: personas, proceso, producto y tecnología. Las
personas trabajan rápidamente o lentamente. El proceso supone una me-
jora en la actividad de las personas, o coloca un obstáculo detrás de otro.
Un producto se define de forma que casi se construye solo, o de forma
que pone obstáculos a los mejores esfuerzos de la gente que está constru-
yéndolo. La tecnología ayuda al esfuerzo del desarrollo u obstaculiza los
mejores intentos de los desarrolladores.
Podemos potenciar cada una de esas cuatro dimensiones para maxi-
mizar la velocidad de desarrollo. La Figura 2.3 ilustra esta idea.
Personas
Proceso Producto
Tecnología
Figura 2.3. Las cuatro dimensiones de la velocidad de desarrollo

(mostradas aquí en dos dimensiones). Podemos centrar la atención
en las cuatro dimensiones a la vez.
Como réplica a este diagrama, algunos ingenieros dirían: <¡Ehl, no

son cuatro dimensiones. Son cuatro direcciones. ¡Aún no podemos dibu-
jar en cuatro dimensionesl> Es cierto. No se puede dibujar en cuatro di-
mensiones, y ésta es la razón de que la figura se muestre en dos dimensio-
nes. Por el concepto que se quiere mostrar es más una dimensión que una
dirección.
Los libros de desarrollo de software tienden a hacer énfasis en una
dirección y a minimizar las demás, pero no hay necesidad de renunciar
entre centrarse en las personas, el proceso, el producto o la tecnoloqia. Si
fuesen direcciones, entonces centrarse en las personas podría quitar r-alor
a centrarse en la tecnología. Centrarse en el producto impediria centrarse
en el proceso. Pero puesto que son dimensiones. pt'rdemos cenrrarnos al
mismo tiempo en la gente. ei proceso. el producto r- la tecnolo_aia.
Las or_eanizaciones de softs'are tienden a rer las dimensiones que no
utilizan como valores rijos- r'ésra puede ser una de las razones de que la
pianilicación de provectos pueda ser frustrante. especiaimente la plani-
ficación temporal. Cuando utilizamos una sola dimensión. es prácticamente
imposible satisfacer los objetivos de todos. El desarrollo auténticamen-
te rápido necesita que incorporemos gran variedad de tipos distintos de
métodos (Boehm et aL.,1984; Jones, l99l). Las organizaciones más efec-
tivas en la consecución de un desarrollo rápido optimizan simultáneamente
las cuatro dimensiones.
Aprender cada una de las cuatro dimensiones puede suponer una gran
ventaja parala planificación del software; la planificación puede llegar a
ser más completa, más creativa, más efectiva y nos satisfará mejor, tanto
a nosotros como al resto de los implicados.
Las siguientes subsecciones tratan de las cuatro dimensiones y de cómo
se relacionan.
Personas
Se conocen los resultados de experimentos concretos en temas de perso-
nal Qteopleware). Podemos estar famtliarizados con 1a tesis de que la di-
ferencia en la productividad entre diferentes desarrolladores es al menos
de diez a uno. O estar familiarizados con la aportación positiva que puede
tener una mejora explícita en la motivación.
Lo que es menos familiar de la mayoría de los desarrolladores, inclui-
da la mayoría de la gente de la industria, es que los resultados en las in-
vestigaciones sobre personal se han ido acumulando de forma estable
durante los pasados quince a veinte años. Ahora es posible hacer un reco-
rrido por muchas de las conclusiones en estudios concretos, y sintetizar
algunas conclusiones globales según las tendencias en la investigación.
La primera conclusión es que ahora sabemos con seguridad que los
temas relacionados con personas tienen un mayor impacto en la produc-
Capítula 2: Estrategia para e! desarrollo rápido 17
tividad del software y por tanto en la calidad del software. Desde t-rna-
les de los sesenta, estudio tras estudio se ha descubierto que 1a producti-
la-:_: ==irES vidad de programadores concretos de similar nivel de experiencia pue-
de variar en un factor de al menos de diez a uno (Sackman, Erikson y
Grant, 1968; Curtis, 1981; Mills, 1983; DeMarco y Lister, 1985; Curtis
et al., 1986; Card, 1987; Valett y McGarry, 1989).
Los estudios también han descubierto variaciones en la eficiencia de
equipos completos del orden de 3, 4. o 5 a I (Weinberg y Schu1man,l9l4;
Boehm, 1981; Mills, 1983; Boehm. Gray y Seeu'aldt, i984). Después
DATOS REALES
de 20 años de experimentar en proyectos reales. los investi-eadores del La-
boratorio de Ingeniería de1 Software de la NASA han llegado a 1a con-
clusión de que la tecnología no es la respuesta; los métodos más efectivos
son aquellos que sacan partido al potencial humano de sus desarrollado-
res (Basili et aL.,1995).
Puesto que está claro que todo 1o relacionado con peopleware influye
fuertemente en la productividad, ahora también queda muy claro que cual-
quier organización que trate seriamente de mejorar la productividad pri-
mero debe ocuparse de temas relacionados con pelsonal, como la motiva-
ción, equipo de trabajo, selección del personal y formación. Hay otras
formas de meiorar la productividad, pero la gestión de personal ofrece 1os
mayores beneficios potenciales. Si nos interesa e1 desarrollo rápido, debe-
mos preocuparnos de las personas. Conjuntamente, los temas relaciona-
dos con el personal son más importantes que el proceso, el producto o la
tecnología. Tendremos que tenerlos en cuenta si buscamos el éxito.
Este resultado es contundente, pero no debe tomarse como base de
cualquier iniciativa relacionada con peopleware en cada átea. Los resul-
tados de la investigación simplemente dicen que los efectos de la habili-
dad y motivación individuales, y habilidad y motivación del equipo son
pequeños factores que influyen en 1a productividad. No dicen específica-
mente que las camisetas. los refrescos -eratis. las oltcinas exteriores, re-
compensas de productir,idad o la cen-eza de ios viernes por la tarde mejo-
ren la motivación, pero hay una relación clara: una empresa que quiera
mejorar la productividad debe uttlizar estos medios.
Este libro incluye varias formas de maximizar el potencial humano y
reducir los planes del software.
Selección del personal para equ¡pos de proyectos. En su libro cla-

ve, Software Engineering Economics, Barry Boehm presenta cinco prin-
cipios para la selección de personal (Boehm, 1981):
o Máximo talento. Usar poco y buen personal.

o Trabajo adecuado. Asignar tareas según la habilidad y motiva-
ción de la gente disponible.
o Progresión profesional. Ayudar a la gente a actualizarse por si
--€s:*:, 'c y gestión de proyectos informáticos
donde más experiencia tie-

: =:=:;NclAS misma en vez de obligarles a trabajar
:¡.JZADAS nen o donde son más necesarios'
- zs nformación gente que se complemente
Equilibrado deL equipo. Seleccionar a
==--=
r:,:': adecuación de
irabajos y carrera y arrnonice con 1os demás'
a los miembros
;'cfesional, véase "El
trabalo en sí", en la Eliminar la inaclaptación' Eliminar y reemplazar
Sección 11.2. Para problemáticos del equipo 10 antes posible'
más información sobre
el equilibrado de
diferencia son la habilidad de
equiPos Y Problemas Otros factores que pueden marcar la
programación' la experiencia en el
de personal, véanse el
CaPítulo 12, "Equipo
diseño del personal, la habilidad en
de trabalo", Y el ;;1;" y la máquinu y lu t*pttiencia en el área de aplicación'
CaPítulo 13,
.Estructura del de organizat al personal tiene un
equiPo" Organización del equipo' La forma
la que trabajen' Las empresas de soft-
gran efecto sobre Ia eiicie"cia con
sus para que concuerden
ware sacan partido a la estructura de "qolpot producto.y los objeti-
del
con el tamaño ¿.f p,oyi"üiu' tututtttísticas puede sa-
también
vos de planificaciót ú;;;;y;cto software
específico
.u, prou""tto de la especialización apropiada'
no va a querer tra-
Motivación' Una persona que carece de motivación
La motivación es el único factor que
bajar duro, y prefiere dejarseilevar' de semana sin
las tardes y los fines
provocará que una p""o"u renuncie a gente dentro
pueden aplicarse atanta
que se le pida. po"o. otro' factores el
potencialmente
de tantos equipos en tantas t*p"'ui'
I a motivación es
aliadomásfuertequetenemosparaeldesarrollorápidodeunproyecto'
Proceso
el proceso incluye tantas
Tal y como se aplica al desarrollo del software '
técnicas. El efecto que tiene
metodologías de gestián como metodologías que el que
el proceso.n .t ptur-t J. desarrollo -át fácil de calcular
"'
Capítulo 2: Estrategia para et ffis¿--.,to ráp¡do 1g
tiene la gente' y el software Engineering Institute y oras

oiEax.rizaciones
han desarrollado gran cantidad de trabajo para docum.nrui.
publicirar
los procesos de software efectivos.
El proceso representa un área de gran relevancia en la mejora
de la
velocidad de desarroilo, casi tanto como ras personas. Hace
diezaños era
:I-:3:=ALES razonable debatir acerca de la importancia de centrarse
en el proceso, pero
hoy día, como ocurre con el personar, existen gran cantidad
de evidencias
en favor de prestar atención ai proceso. organLacrones
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-
11o, han reducido sus plazos de salida al mercado
a la Áitad. y han reducido
costes y errores en un factor de 3 a l0 (pietrasanta, 1997; Myers,
1992;
Gibbs, 1994;Putnam. 1994: Basili e¡ at., r995; Rayrheon, i99s; saiedian
y Hamilton. 1995).
Algunas personas, piensan que ocuparse del proceso es agobiante, y
no hay duda de que algunos procesos son demasiado rígidos y"burocráti-
cos. Hay gente que ha creado estándares en procesos principaimente
para
sentirse más poderosos. pero se trata de un ábuso de poder, y
el hecho de
que se abuse de centrarse en el proceso no debe permitir
eclar por tierra
los beneficios que puede ofrecer este enfoque. La forma más
habitual de
abusar del proceso es la negligencia, y suifecto es que desarroiladores
inteligentes y concienzudos trabajan ineficientemente y con objetivos
cru-
zados, cuando no sería necesario trabajar de esta forma.
cenirarse en el
proceso puede ser útil.
Evitar la repetición de trabajo. Si;en las últimas etapas der proyecto

hay un cambio en los requerimientos, es necesario rediseñar,
recodificar
y volver a hacer las pruebas. si ha habido problemas en el
diseño que no
se descubren hasta la prueba, se debe volvei al diseño
detallado y la codi-
ficación y comenzar de nuevo. una de ras mejores formas
de ahonár tiempo
en los proyectos software es orientar er proceso de forma que
se evite
hacer la misma cosa dos veces.
Raytheon obtuvo en r995 er IEEE computer Society,s
Software pro-
cess Achievement Award por reducir sus costes
de repetición de trabajo
del 41 por 100 a menos aglto por r00, y simurtáneamente
DATOS REALES t.ifh.u. ,r.
productividad (Raytheon, r9g5). La relación entre estas
ao. fri.ru. no
es una casualidad.
REFERENCIA control de calidad. Er control de calidad tiene dos objetivos principa-

CRUZADA
Para más información l-es el primero es asegurarse de que el producto
entregaáo tiene'un niver
sobre control de de calidad aceptable. Aunque se tiate dé un objetivo
calidad véase la iriportante, está fue-
Sección 4.3. ..Bases ra del alcance de este libro. El segundo objetivo es
detectar los árrores en
rel control de cal¡dad- el proceso en el momento que haya que eáprear menos
tiempo
diseño) para corregirlos. Esto siempri quierf decir rocalizar [-e.ros
ros errores ro
20 :- :. í'Jr,ectos informáticos
::::s pronto posible desde el momento en el que se introducen. Cuan:,:,

ntas tiempo permanezca un error en el producto, más tiempo (y más dine-
ro) se empleará en eliminarlo. Por tanto, para un programa serio de desa-
rrol1o rápido es indispensable controlar la calidad.
REFERENCIA Bases del desarrollo. La mayor parte del trabajo realizado durante
CRUZADA
Para más información
los pasados 20 años en el campo de la ingeniería dei software está rela-
sobre las bases del cionada con desarrollar software rápidamente. Muchos trabajos se cen-
desarrollo, consulte la
tran en la <productividad> más que en el desarrollo rápido en sí mismo, y
Sección 4.2, "Bases
técnicas". por esto algunos de ellos se han orientado hacia obtener el mismo trabajo
hecho por menos gente, en vez de conseguir hacer el proyecto más rápida-
mente. Sin embargo, podemos interpretar los principios subyacentes des-
de el punto de vista del desarrollo rápido. Las lecciones aprendidas a lo
largo de 20 años dando tropezones pueden ayudar a que su proyecto se
desarrolle tranquiiamente. A pesar de que los métodos estándar en inge-
niería del software para el análisis, diseño, construcción, integración y
prueba no van a acelerar por sí mismos el pian de forma fulgurante, pue-
den evitar que los proyectos se queden fuera de control. La mitad del de-
safío del desarrollo rápido consiste en evitar el desastre, y ésta es un área
en la que sobresalen los principales estándares de desarrollo del software.
REFERENCIA Gestión de riesgos. La gestión de riesgos es una de las técnicas espe-

CRUZADA
cíficas que se centran en evitar el desastre. E,l desarrollo rápido no es su-
sobre gestión de ficientemente bueno si durante dos semanas antes de la fecha de entrega
riesgos, véase el
nos quedamos fuera de juego. Para programar un desarrollo rápido es ne-
Capítulo 5, "Gestión
de riesgos". cesario gestionar los riesgos asociados con la planificación.
Atención a los recursos. Los recursos pueden enfocarse de forma efec-

tiva y ayudar a la productividad global, o pueden dirigirse mal y usarse de
forma inefectiva. En un proyecto de desarrollo rápido, es incluso más
importante de lo habitual acertar al máximo en el mejor plan. Técnicas
como oficinas productivas, desarrollo en ventanas temporales, pianifica-
ción ajustada y horas extras voluntarias ayudan a asegurarse de que cada
día se hace todo el trabajo posible.
REFERENCIA Planificación del ciclo de vida. una de las claves parala asignación
CRUZADA
efectiva de 1os recursos es utilizarlos dentro de un ciclo de vida definido
sobre la planif icación que tenga sentido para el proyecto concreto. Un modelo de ciclo de vida
del ciclo de vida, es útil porque describe un plan de gestión básico. Por ejemplo, si tenenros
consulte el Capítulo 7,
.Planificación del ciclo un proyecto arriesgado, es recomendable un ciclo de vida orientado al
de vida-. riesgo; si los requerimientos no están claros, funcionará mejor un modelo
de ciclo de vida incremental. Los modelos de ciclo de vida hacen que sea
más fáci1 identificar y organizar las muchas tareas necesarias en un pro-
yecto software, y así poder realizarlas con la mayor eficacia.
Capítulo 2: Estrategia para e¡ dese..ello rápido 21
;F==E{!-.r Orientación al cliente. Uno de los cambios fundamentales enrre el desa-

-= |
-1-
= i=
*¿: rlf r-á: : - rroilo de software tradicional sobre mainframes y los modernos esriios de
s:r:r=:-É--E::- a desarrollo es el giro hacia las necesidades y deseos del cliente. Los desarro-
: É-t= : :r-s_:: ¿
:.:; :- : :3. lladores han aprendido que desarrollar el software apartk de 1a especifi-
cación supone sólo la mitad del trabajo. La otra mitad es ayudar al cliente
1 ct tLeD.
-
a definir el producto que desea, ylamayoria de las veces es necesaria una
aproximación diferente a la tradicional especificación en papetr. Ponerse
en su lugar es una de las mejores lonnas de evitar 1as vueltas atrás masi-
vas provocadas por el cliente que decide que e1 producto correcto no es el
que se está desarrollando desde hace 12 meses. N{étodos como la entrega
por etapas, entrega evoiutiva. prototipado er olutir o. prototipado desechable
y negociación conveniente aportan ventajas a este área.
Producto
La dimensión más tangible de1 cuarteto gente/proceso/producto/tecnología
es la dimensión producto, y ocuparse del tamaño y características del
producto plantea enormes oportunidades de reducir la planificación.
,A1 reducir el conjunto de prestaciones del producto reducimos el plan.
Si el conjunto de prestaciones es flexible, se puede aplicar la regla 80/20
y desarrollar el 80 por 100 del producto empleando sólo el 20 por 100 del
tiempo. Más tarde se desarrollará el 20 por 100 restante. Si hacemos que
el aspecto, ias características de rendimiento y las características de cali-
dad de1 producto sean flexibles. podemos ensamblar el producto empleando
componentes preexistentes y escribir la mínima cantidad de código espe-
cífico. E1 total en 1a reducción sobre el plan que se obtiene al ajustar en el
tamaño y las características del producto sólo se ve limitado por ei con-
cepto de producto que tiene el cliente y la creatividad del equipo.
n 1e sroyectos informáticos
Tanto el producto como las características del producto ofrecen opor-

runidades para acortar el tiempo de desarrollo.
Tamaño del producto. E,i tamaño del producto es el elemento individual

que más aporta al plan de desarrollo. Para productos grandes se emplea
más tiempo. Para productos más pequeños, menos. Prestaciones adicio-
nales necesitan especif,rcación, diseño, construcciones, prueba e integración
:-:.:Jcto para obtener
velocidad en el adicionales. Requieren una coordinación adicional con el resto de las utili-
desarrollo, consulte el dades, y necesitamos coordinar las otras con e1las. Puesto que el esfuerzo
Capítulo 14, "Control
del conjunto de
para construir software se incrementa desproporcionadamente más rápi-
prestaciones.. Para do que el tamaño del software, ia reducción dei tamaño mejorará la
más información sobre
el efecto del tamaño
velocidad del desarrollo desproporcionadamente. Reducir a la mitad el
del producto en el tamaño de un programa intermedio normalmente supone una reducción
plan de desarrollo,
de al menos dos tercios del esfuerzo.
"
Estimación ". Podemos reducir drásticamente el tamaño del producto esforzándo-
nos en desarrollar sólo las prestaciones más esenciales, o reducirlo tem-
poralmente desarrollando el producto en etapas. También es posible re-
ducirlo empleando un lenguaje de un nivel más alto o un conjunto de
herramientas para que cada utilidad necesite menos código.
REFERENCIA Características del producto. Aunque no tienen la misma influencia

CRUZADA que el tamaño del producto, hay otras características del producto que
sobre el efecto que afectan al plan. Se empleará más tiempo en desarrollar un producto con
pueden tener los objetivos ambiciosos respecto ai rendimiento, uso de memoria, robustez
objetivos en el plan de
desarrollo, consulte y fiabilidad que el que se empleará en uno sin ningún objetivo para estas
.Definición de características. Hemos de elegir nuestras metas. Si la auténtica prioridad
objetivos", en la
Sección 11.2. es el desarrollo rápido, no pondremos trabas a los desarrolladores insis-
tiendo en demasiadas prioridades a la vez.
Tecnología
REFERENCIA Una forma rápida de mejorar la velocidad de desarrollo es pasar de usar
CRUZADA
herramientas menos efectivas a otras más efectivas. En la historia del desa-
sobre herram¡entas de rrollo de software, uno de los cambios con mayor influencia fue el paso
productividad, véase el de lenguajes de bajo nivel, como el ensamblador, a lenguajes de alto ni-
Capítulo 15,
.Herramientas para vel, como C o Pascal. La actual tendencia hacia componentware (VBX y
aumentar la OCX) puede producir resultados igualmente espectaculares. La selección
Productividad-.
de herramientas efectivas y la gestión de 1os riesgos asociados son aspec-
tos claves en una iniciativa de desarrollo rápido.
Sinergia
Hay un momento en que ocuparse de la gente, el proceso, el producto y
la tecnologia se convierte en un todo. Neil Olsen rcalizó un estudio en
DATOS REALES el que descubrió que pasar de una inversión baja a media en personal,
formación y entorno de trabajo produce unas ganancias similares: tn-

r.ersiones adicionales se justificaban con ganancias 1 a 1, aprorimada-
mente. Pero al pasar de una inversión en personal, fonnación y entorno
de trabajo de nivel medio a alto, la productividad se dispara, con una ga-
nancia de 2 a 1, o de 3 a I (Olsen, 1995).
Los métodos de ingeniería del software también pueden cooperar. Por
ejemplo, los está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 vez. un grupo de componentes reusables
puede ayudar a que se respeten los estándares en codificación, y asegu-
rarse de que mantienen el significado entre distintos proyectos. Las revi-
siones del diseño y el código ayudan a distribuir el conocimiento sobre
los estándares en codificación y los componentes reusables existentes, y
facilitan el nivel de calidad necesario para que la reutilización tenga éxito.
Buenas técnicas suelen ser 1a bases de otras.
2.3. Tipos generales de desarrollo rápido

Diferentes situaciones requieren distintos niveles de compromiso en la
velocidad de desarrollo. En algunos casos, nos gustaría incrementar
la velocidad de desarrollo siempre que sea fácil hacerlo, y sin que supon-
ga un coste adicional ni la degradación del producto. En otros casos, las
circunstancias requieren que incrementemos la velocidad a cualquier coste.
LaTabla2.1 describe algunas relaciones entre diferentes enfoques de desa-
rrollo.
Tabta 2.1 . Características de los enfoques estándar de desarrollo

orientado a la planificación
Efecto del enfoque de desarrollo en...
Enfoque de desarrollo ... Plan ... Coste ... Producto
Método normal Medio Medio Medio
Desarrollo eficiente (equilibrio Mejor que Mejor que Mejor que

de coste, plan y funcionalidad) la media la media la media
Desarrollo efi ciente (desarrolio Mucho mejor Algo mejor Algo mejor
efi ciente orientado hacia que la media que la media que la media
e1 mejor plan)
Desarrollo rápido a fondo El más corto Peor que la Peor que 1a

posible media media
I
21 üesaq'o¡*o y gestión de proyectos informáticos
Desarrollo eficiente
3E-FIEI+CIAS Tal como se ve en la Tabla 2.1. er método medio es... medio. Er segundo
CRUZADAS
3a-É r,er un ejemplo enfoque mostrado en la tabla se etiqueta como (desarrollo eficiente)), y.
re los beneficios como muestra la Figura 2.4, es la combinación de los tres pilares de la
del desarrollo velocidad máxima de desarrolio. Este enfoque es el que genera mejor
ráp¡do, consulte la
Sección 4.2, .Bases resultado que la media en cada una de las tres categorías. Mucha gente
técnicas", y de forma alcanza sus objetivos de planificación después de poner ros tres primeros
general el Capítulo 4,
pilares en su sito. Algunas personas descubren que después de todo no
"Bases del desarrollo
de software.. necesitaban el desarrollo rápido; ¡sólo tenían que organizarse! para mu-
chos proyectos, el desarrollo eficiente supone una optimización notabre
del coste, plan y características del producto.
¿Se pueden consesuir planes cortos sin alcanzar primero el desarrolro
eficiente? Es posible. Podemos elegir métodos efectivos y orientados a
la planificación y evitar métodos lenros e ineficaces sin ocuparnos del
desarrollo eficiente en sí. Sin embargo, aunque se obtenga el desarrollo
eficiente, las posibilidades de éxito en el uso de métodos orientados
a planificación son inciertas. Si empleamos métodos concretos orienta-
dos a planificación sin una estrategia general, emplearemos más tiempo
mejorando la capacidad de desarrollo global. por supuesto, sólo nosotros
Desarrollo eficiente
Métodos
orientados a
Figura 2'4. Desarrollo eficiente. Los tres primeros pasos para lograr e!
mejor plan posible conforman el
"desarrollo eficiente,. Muchos eluipos de
proyectos descubren que el desarrollo eficiente ofrece toda Ia vetocidad de
desarrollo que necesitan.
Capítulo 2: Estrategia para e) 5e-<;-'l . ráp¡do 25
sabremos si es más importante mejorar las capacidades de cie s¿::t11o g1o-

ba1 o intentar acabff más rápidamente un proyecto concreto.
:=-:=rr^ A Otrarazot para centrarse en el desarrollo eficiente consiste en que en
:=-rifA la mayoría de las organizaciones, los caminos para llegar al desarrollo
ull
eficiente y obtener planes más cortos son los mismos. En este aspecto.
=!
:::-: : --¿: :' entre
:,3 :=: , ': :Cidad de hasta llegar a cierto punto, los caminos hacia planes cortos, menos de-
::-:a-: : :onsulte la
S::,: :- 4.3, "Bases fectos y menor coste son también iguales. Como muestra la Figwa 2.5,
:: ::-:': de calidad". cuando se alcanza e1 desarrollo eficiente los caminos comienzan a sepa-
rarse, pero donde nos encontramos ahora. 1a mavoría de los grupos de
desarrollo se beneficiarían de poner rumbo en primer lugar hacia el desa-
rrol1o eficiente.
Desarrollo eficiente orientado hacia el meior plan

REFERENCIAS El tercer enfoque de desarrollo mostrado en la Tabla 2.1 es una variación
CRUZADAS del desarrollo eficiente. Si estamos aplicando el desarrollo eficiente y vemos
sobre la decisión entre que aún necesitamos una mejor eficacia del plan, podemos optar por mé-
métodos orientados a todos de desarrollo que se orienten a incrementar la velocidad de desarro-
la velocidad o métodos
orientados al riesgo 1lo, reducir el riesgo de la planificación o mejorar la visibilidad del pro-
del plan, consulte la greso. Tendremos que hacerpequeños sacrificios en coste y características
Sección 1.2. "Cómo
lograr el desarrollo del producto para ganar en velocidad o predecibilidad; sin embargo, si
rápido", y la partimos de la base del desarrollo eficiente, aún estaremos muy por enci-
Sección 6.2, "¿Qué
ma de la media.
tipo de desarrollo
rápido necesita?"
Para llegar aquí, use métodos efic¡entes

orientados a la planificación Ciudad
del desarrollo
Para llegar aquÍ, use rápido
eficientes en general
A la ciudad
Ciudad de la planificación de reducción
\ de defectos
A la c¡udad
de máxima
sat¡sfacc¡ón
del usuario
Figura 2.5. El camino hacia el desarrollo rápido. Desde donde están

ahora la mayoría de las organizaciones, Ia ruta hacia el desarrollo rápido
sigue el mismo camino que Ia ruta hacia el mínimo de defectos, máximo
de satisfacción del usuario y los menores cosfes de desarrollo. Después
de llegar al desarrollo eficiente, las rutas comienzan a separarse.
fusarrollo y gestión de proyectos informáticos
Desarrollo rápido a fondo

REFERENCIAS El último enfoque de desarrollo orietrtado a la planificación es el denomi-
CRUZADAS
nado <desarrollo rápido a fondo"- 1¿ goNnfoin¿ción de métodos orientados
sobre planes a planificación eficientes e ineñcienres. Llega un punto en el que traba-
nominales, consulte jamos 1o mejor y 1o más duro qrc prodemos. v ya lo único que queda por
.Planif icaciones
nominales", en la hacer es pagar más, reducir ei con-iuuto de características o reducir el
Sección 8.6. Para más acabado del producto.
información sobre
Un ejempio de qué quiere decir rnetodo
costes de la reducción "ineficiente) es: podemos re-
del plan, véase "Dos ducir en un 25 por 100 el plan de desarrotio nominal de un proyecto sim-
hechos reales", en Ia
Sección 8.6.
plemente incluyendo más gente- Sin embargo. debido al incremento en
las comunicaciones r- la gestión gobal. :e deberia incrementar el tamaño
de1 equipo en un I,i por I fJO para obtener una reducción del plan de un 25
por 100. El efecto neto de acorrar el plan 1- agrandar el tamaño del equipo
es que el prol'ecto cuesta un 33 por 100 más que ei proyecto original.
REFERENCIA El salto al desarrollo nipido a fondo es un _qran paso, y es necesario
CRUZADA
aceptar el incremento en el riesgo del plan o las grandes concesiones en
sobre la necesidad del coste y características del producto, o ambos. Pocos proyectos admiten
desariollo rápido a estas concesiones, y la mayoría se acaban mejor usando sólo alguna for-
fondo, consulte la
Sección 6.2, "¿Qué ma de desarrollo eficiente.
tipo de desarrollo
rápido necesita?"
2.4. ¿Cuál es la dimensión más importante?

REFERENCIA Boeing, Microsoft, NASA, Raytheon y otras empresas han aprendido a
CRUZADA
desarrollar software de forma que se ajuste a sus necesidades. A nivel
sobre la personalización estratégico, estas distintas empresas tienen bastante en común. Han apren-
de los procesos dido a evitar los errores clásicos. Aplican las bases del desarrollo. y realizan
software a las
necesidades de una gestión actla de riesgos. A nivel táctico, existe un mundo de dife-
proyectos concretos, rencias en las formas en las que cada una de esas organizaciones que han
véase la Sección 6.1,
tenido éxito se centra en la gente, el proceso y la tecnología.
"¿Existe un modelo
único?. Diferentes proyectos tienen diferentes necesidades, pero en todos
los casos la clave es aceptar los límites en las dimensiones que no podemos
cambiar y centrarse en las otras dimensiones para obtener el resto de
los beneficios que necesitamos en la planificación.
Si estamos desarrollando un sistema de inyección de combustibre de
un coche, para desarrollar software empotrado de tiempo real no podemos
utilizar lenguajes de cuarta generación o emplear entornos de programa-
ción visual; necesitamos más eficiencia y mayor control a bajo nivel del
que ofrecen esas herramientas. Evitaremos expandir demasiado la dimen-
sión de la tecnología . En vez de eso, desarrollaremos la tecnología 1o que
podamos, y centraremos todos nuestros esfuerzos en las dimensiones co-
rrespondientes a personas, proceso y producto.
Capítulo 2: Estrategia para el desar,rcllo rápido 27
Si estamos trabajando en un programa de gestión doméstica. quizás se

utilice un lenguaje de cuarta generación, un entorno de programación i-i-
sual o una herramienta CASE. Podremos expandir al máximo la tecnolo-
gía. Pero podría trabajar para una empresa pesada que nos impida hacer
muchas cosas en la dimensión correspondiente a las personas. Se desarro-
llarála dimensión del personal todo lo que permita la compañía, y el resto
del esfuerzo se empleará en las dimensiones de proceso y producto.
Si trabajamos en un mercado dirigido por prestaciones en paquetes
<prét-á-porter)), no podemos reducir el conjunto de prestaciones 1o sufi-
ciente como para tener un plan ajustado. Se reducirán 1o más posible y se
desarrollarán ia gente, el proceso y la tecnología hasta obtener 1o necesa-
rio para cubrir el plan.
ta dé este libro (y a pesár de sus dilerencias), el sofrwaie emp'ot*do, fir'm-
caracterislicas que el software de sistemas.
una úniCa ernprqsa. Funciona sobre un hardware limitado" quizás un rinico

computador. Los ejemplos típicos son sistemas de control de nóminas, con-
.rabilidad o controi de almacén. En.rr. Iibio. el software IS. IT y MIS se
tratan como pertenecientes a un grupo más general, el soltware de gestión.
;;,,.': .i1i¡Ell$p.ftdáisi,;slitiál. i:porrep¡ qg softw ary e.rngl{í{t*a¿qfg¡fi+$*$;;,$,pnd$;::,',,,:
óomercialmente. lncluye tantoproductos para el mercado honiz-ontál qcomo
tratamientos de texto y hojas de cálculo). como productos para e! mercado
¡,. ,feiti@,[9nmti p*Ci&lnai ¿e an¡á.1iiísr.fi&4róiéir|,ei,É{1ffit ,'dé'gÍiaae,sl¡¡rges-
tión de infor-nración legal).
Se emplean algunos otros términos para refer-irse a tipos de software
,:l..l:4ü¿;.fiole*árt,descritospQi.€sráilffiét!qiÍB!¡i{::Eí€t1éf8Ig$l;$.CI-.firy$!d;:.:é.9.ner-
cial es cualquier tipo dé software desarrollado para venderlo éomeicial-
mente. El software doméstico es el software desarrollado únicamente para -..
usos domésticos y no para la véntá, El ioftware militar se escríbe para uso
militar. El sof,iware interactivo es él software con el que el usuariopuede
interácruár directamente, qué englobá !a mayor parte del software que se
eseribe:1ro51,d,!a:
En resumen, se debe analizar el proyecto para determinar cuái de las

cuatro dimensiones está limitada y cuál puede suponer la máxima ventaja.
Lue-eo hay que forzar cada una al máximo. Ésta es, en resumidas cuentas,
la clar-e del éxito de1 desarrollo rápido.
28 je,s=-: c ,i gestión de oroyectos informáticos
2.5" Una estrategia alternativa para el desarrollo rápido

= ==== =i¡-rAS El enfoque para el desarrollo rápido J-3 !: ::r.: en este libro no es el
l:.;ZADAS
I : -= -:s .Íormac¡ón único enfoque conocido. Aigunos::-.-:.-.::¡n seguido con éxito un
soore enfoques camino diferente. Este catnirr. j- -':::::::r---: :,1: !-ontratar ai mejor perso-
basados en nal posible, buscando ur. cratttr-:r .- :::.- -t: e1 proyecto, garantizán-
:o-rpromiso, consu¡le
,. Pianif icación basada doles casi total autonomi¡. ::,-.::-,.:i -:. -r. _ir:Jt1 e\tremo, y después com-
en compromiso", en probar que trabajan 60. Sl,r ¡,:.--s:, . . :-:.s -: semana hasta que bien
la Sección 8.5, y "
el Capítulo 34, ellos o el proyecto termilal. l-:::.--- : :::rJ.¡ L-on un enfoque basado
"Compromiso". en compromiso se consigLd,-rrr ',: _-r. !-¿:t.. ieterminación.
Este enfoque ha gener¿c¡ :r,t, : s :- : :":,:s. :nciuvendo Microsoft Win-
dou,s NT 3.0 r'e1 Dara Ger:::. E.¡:-: rJ-,::::;rer. r es incuestionable que
es e1 enloque de des::r'.- -. :.:.: ::=.:,-:i,¿r que se usa hoy día. Para
una empresa en desar:r--liLr !-L1n ::-¡a*t3ciL1:t-s respecto a su economía,
supone la venta3a de sa,--ar el traba_jo ,je dtrs mesis de un empleado con la
paga de un mes. Esto puede marcar la dit'erencia para acabar un producto
I
clave a tiempo de colocarlo en el mercado. haciendo que la empresa gane
una fortuna y consiga dinero rápidamente, antes incluso de que el equipo
acabe el producto. Mantener un equipo de pequeño tamaño también redu-
ce las comunicaciones, la coordinación y la gestión global. Si se emplea
conociendo los intensos riesgos y con algunas limitaciones, el enfoque
puede tener éxito.
Desafortunadamente, este enfoque siempre es llevado a la práctica con
más dureza que cuidado. Normalmente genera un enfoque de codifica-
ción a destajo, que provoca que ios proyectos se alarguen como si fueran
eternos. El enfoque es una corrección rápida, y tiene todos los problemas
de otras correcciones rápidas. A io largo del libro se critican aspectos de
este enfoque. A continuación se muestra un resumen.
El enfoque implica ganar o perder. A veces funciona, a veces no.

Los factores que hacen que funcione o no son prácticamente imposibles
de controlar. cuando se llega al final del proyecto, a veces se obtiene ra
funcionalidad que se planifica; y a veces nos sorprendemos. A veces se
consiguen los objetivos de calidad; a veces no. Este enfoque hace que sea
difícil controlar las características específicas del producto.
Provoca problemas de motivación a largo plazo. En los proyectos

basados en compromiso, 1os desarrolladores comienzan con entusiasmo y
emplean tantas horas extras como en sus tiempos de principiantes para
completar sus compromisos. Normalmente, no es suficiente con muchas
horas, y fallan al intentar conseguir los compromisos del plan. uno a uno,
su moral se apaga y se ven obligados a admitir la derrota.
cuando los desarrolladores ponen su corazón y su alma intentando
lograr sus conrpromisos y lallan. se r uelven reacios a aceptar compromi-
\¡-
Capítulo 2: Estrategia para et oesar¡or¡o rápido 29
sos adicionales. Comienzan a resentirse de las horas extras. Aceptan nue-

vos compromisos de palabra pero no de corazón, y el proyecto pierde
todo aspecto de planificación o control. En un proyecto que ha alcanzado
este estado, es común decir <quedan tres semanas para el final> durante
seis meses o más.
No se puede repet¡r. Aunque el enfoque de codificación a destajo ten-

ga éxito unavez, esto no supone una base para ei érito en otro caso. Pues-
to que cansa a la gente. es más probable que siente las bases para futuros
fallos. Una empresa no puede reparar tácilmente el daño humano que pro-
vocan estos proyectos. y los esrudios de estos pro\ ectos indican que provo-
can un gran volumen de cambio de personal lpor ejemplo. Kidder. 198 1:
Carroll, 1990; Zachary, 1994).
Es duro para organizaciones no dedicadas al software. E,l enfo-

que de codificación a destajo aporta poca viabilidad y control a los demás
implicados en el proyecto porque se basa en heroicidades individuales en
vez de en la coordinación, cooperación y planificación. Incluso cuando se
desarrolle con éxito el software más rápidamente de 1o que es habitual, no
hay forma de saber cuánto llevará el proyecto. No sabremos cuándo aca-
bará hasta que se acabe.
Alguno de los beneficios de velocidad que se consiguen con el enfo-
que basado en compromiso se neutraliza debido a que hay otros grupos
con quienes deben coordinarse los desarrolladores, como son los grupos
de prueba, documentación de usuario o comercialización, y no se puede
planificar. En un proyecto a destajo, la frustración de los desarrolladores
al no poder obtener información fiable del plan provoca una tendencia a
la irritación, ye1 personal del equipo está en contra del personal ex-
terno al equipo. Lo que es bueno para una parte del proyecto no es bueno
necesariamente para el proyecto completo.
Se malgastan recursos humanos exageradamente. Los desarrolla-

dores que participan en este tipo de proyectos se olvidan de la familia,
amigos, hobbies e incluso de su propia salud para tener éxito en el proyecto.
Severos conflictos personales son la regla envez de la excepción. Este nivel
de sacrificio puede serjustificable paru ganat una guerra o llevar un hombre
a la Luna, pero no es necesario para desarrollar software de gestión. Con
pocas excepciones, este sacrificio no es necesario: se pueden conseguir
los mismos resultados con una gestión cuidadosa, seria e inteligente y
con una planificación técnica, 1o que supone mucho menos esfuerzo.
La Tabla 2.2 resume algunas de las diferencias entre el método a des-
tajo y el que describe este libro.
E1 método descrito en este libro muestra cómo obtener el desarrollo rá-
pido con una planificación cuidadosa, una utilización eficiente de1 tiempo
3{¡ -}ae*C/o y gestlon @ groyectos informáticos
Tabla 2.2. Comparación del método a destajo con el método propues:t

en este libro
Método a destaio Método de este libro
Sus defensores aducen mejoras Sus defensores aducen modestas

increíbles e instantáneas en el tiempo mejoras instantáneas, seguidas por
de desarrollo. mejoras mayores y a más largo plazo.
Necesita poca experiencia tecnológica Necesita una experiencia tecnológica
aparte de conocimientos en además de conocimientos en
codificación. codificación.
Riesgo alto: frecuentemente falla, Riesgo bajo: pocas veces falla cuando
incluso cuando se ha hecho de la se aplica de forma efectiva.
forma más efectiva posible.
Los demás nos ven como <radicales>; Los demás nos ven como
parece que estamos en las últimas, conservadores, aburridos e incluso
que tuviéramos todo. feos. No parece que estamos
trabajando duro.
Se emplean demasiados recursos Usa los recursos humanos de forma
humanos. humana y eficiente.
Ofrece poco avance en visibilidad o Es posible personalizar el método
control. Se sabe que se ha acabado para dar toda 1a visibilidad y el
cuando se termina. control necesarios.
Es un método tan viejo como el Los elementos claves del método se
propio software. emplean con éxito desde hace más de
15 años.
Fuente: Inspirado en <Rewards oftaking the Path Less Traveled>> (Davis, i994).
disponible y la aplicación de técnicas de desarrollo orientadas a planifica-

ción. Las horas extras son habituales en este tipo de desarrollo rápido,
pero no suele ser el mismo montón de horas extras que se usan en el mé-
todo a destajo. Normalmente, el desarrollo eficiente genera un plan más
corto que la media. Cuando falla, se debe a que la gente pierde la determi-
nación de seguir usando el método, no a que falle el propio método.
Resumiendo, el método a destajo asegura un sacrificio extraordinario,
pero no unos resultados extraordinarios. Si el objetivo es la máxima velo-
cidad de desarrollo en vez de las máximas horas de bullicio (actividad),
cualquier persona razonable apostará por el desarrollo eficiente.
Si leemos entre las líneas de este libro, encontramos toda la informa-
ción necesariapara llevar con el mejor éxito posible un proyecto a destajo.
Ciertamente, una persona podría transformar este libro del doctor Jekyll
en el de Mr. Hyde a destajo. Pero hay mucho de mí en este tipo de desa-
rro11o. y no voy a explicar cómo usarlo.
Capítulo 2: Estrategia para et re#:c 'c
Ejemplo 2.2. Desarrollo rápido con una estrategia clara
(continua)
.r
32 J=sarrallo y gestión de proyectos ¡nformáttc.s
(M¿ parece bien,r. di-;,, :::-: \:::-=i. .-¡¡¡r QUr- en este proyeclo la
::r1,fuIlcionalidad debe ser má-i l¡rlrrrÉr1¡3 que ei plan. Déjamq habfar csn al-
guna gente y te llamare. ''
,,,, Óuáirdo Eddie llamó a Sa¡¿- ie dijo que la compáiía tenía la'vaiuntad
dg fOrzar,a'que el plan ,Jei scirrrare fuese de 14 areses para conseguir las
j ,pigslacioces desead¿s. terú para may'or segurida.d:deberí¿emplear el plan
de enlregas er oluiir a-r- Sara se rranquilizó y d¡o que ella pensaba que éste
era un objetir o más realisra.
',,,', Duranfe las prineras semanas del proyeótó, el equipo desarrolló un
prototipo de la i¡rerl-az de usuario detallada y con aspeclo holl¡woodense.
, , La <lista de errores> de vez en cuándo indjeába,qqe el esfuerzo en e1 proro-
tipado podia suponeÍ una vida en si mismo, así que se l-ijó una venrana
temporal rígida.para ei tnrbajó,,enpl pro(atipado que evitase consrn¡ir un
prototipo excesivamer¡t.e,,metiCu1oso'. ,El prototipo se ufilizó para realizar
entre"istas con los posibles clientes acerca de las utilídades can,lidaras. v
el prototipo se revisó varias veces en respuesra a las indicaciones de mejo-
ra de los usua¡ios.
*ánt
,,,1'l,,,:,',:.Saiat,'siguió la lista de riesgos y determinó que los tres
- riesgos claves para el "iendo
proyecto eran la bala calidad. que podria provocar
ercesiras rueltas atrás r el alargamiento del plan. la agresividad del plan,
v la' prestaciones quc añadina la competencia desde ahora hasta la linali-
zación del prol'ecto. Sar¿ creia que el plan de en*egas ev:slutivas se había
aplicado por el riesgo de la calidad- Deberíal entr,q$ár lalprime¡a vefsión
del softqa¡e al grupo de conirol de calidad, QA" en el límlte de los 8 me-
ses. 1' QA podria ir evolucionando los casos de prueba con el software.
El equipo coatroló el riesgó en'el¡plaa cieanda una,1lqia dq p¡eslaci.o-
nes priorizada. Debían desarrollar lo más que pudiesen en l4 meses, pero
llevando el producto a un estado comercializable cada dos meses. y debían
asegurarse de tener algo que entregar cuando fuera el momento. También
tomaron decisiones de diseño para varias preslaciones que estaban especí-
ficámente indicadas para ahorrar riempo de implementación. El menor tiem-
po consumido en las implementaciones no era una tra.pa, pero era acepta-
ble, y supuso una reducción en el riesgo del plan.
EI equipo gesrionó el riesgo de las prestaciones de los competidores de
dos formas. Emplearon cinco meses en desarrollar un diseño que incluyese
un entorno capaz de soportar todas las prestacioaes que habíaa prototipado
v unas üuantas más que creían que debían iaeluirse ea 1a vers;ón 3.0r. Su
diseio prefendÍa que se pudiese adaptar a los cambiss con poea,dificultad.
También asigtaron tiempo en el mes l2 para revisar,fol produclos dq.loS
comperidores. rer.isa¡ el prototipo e irnplemenlar las preslaciones nqcesa-
rias para ser competitivos en los últimos dos meses.
En el se.rro mes, con el diseño completo, el equipo lijó un conjunto de
hitos miniarura que indicaban el camino a seguir para obtener la primera
versión comercializable que pudiese iér probada en el octavo mes. La ver-
sión del octavo mes no hacía muchas cosas, pero la calidad era buena, y
(contin úa)
s4 -ka-sllo y gestión de proyectos informáticos
Los siguientes libros ofrecen información sobre los procesos del -r::-
ware, el pii-.to a nivel organizacional, el segundo a nivel del equipo i l-
tercero a nivel individual.
Carnegie Mellon University/Software Engineering Institute: The C apabi-

tity Maturity Model: Guidelines for improving the software Process.
Ráading, Nriutr., Addison-Wesley, 1995. Este libro es un resumen de
los últimos trabajos para mejorar el proceso de software realizados
por
'de
el Software Engineering Institute. Describe el modelo completo
madur"" de procesos en cinco niveles, los beneficios que se obtie-
nen con cada nivel y los métodos que caracteizan cada uno de ellos.
También incluye ejemplos detallados de una empresa que ha conse-
guido los mayores niveles de madurez, calidad y productividad.
Mafuire, Steve: Debugging the Development Process' Redmond, Wash':
-Microsof press,
1éé4. El libro de Maguire presenta un conjunto de
máximas tradicionales que pueden utilizar los responsables de los
proyectos para hacer que sus equipos sean productivos, y da un vistazo
interesanté de las inteiioridades de algunos proyectos de Microsoft.
Humphrey, Watts S.: A Discipline for Software Engineering' Reading'
Mu*r.' Addison-Wesley, 1995. Humphrey define su propio proceso
de software, que podemos adoptar a nivel individual, independien-
temente de que nuestra empresa soporte la mejora del proceso'
3€ --*-i:-'--- :I g9-<: a- i. slyectos informáticos
Ejemplo 3.1. Errores clásicos

: .:)
. .::::::::.:.:::: .. . : : ,,, ,. . , ,ttt::!:t:r .
Mike- un responsable técnico de Giga Safe, estaba comiendo en su ofi.-ir"i

:.:.}¡..mirarldopof'iave$ta*a'unabrilla.ntemañanadeabril.
, ,,, <<¡Felcidádesl ¡Mike, ya,!ie,nes,Fl, fondos para el programa Giga-
'Quote!,>>, Era Bill, e1 de rsegurs$ médi-
jefe, dq,Mike e.n,Gigá;'¡¡gp
"o*Oáñía
,, coS. ¡{Al:comité ejecutivó }e ha guslado la',idea de automatiztir n*,r€stras
r
,cuotas d:e,seguro médicc,:rY también la idea de volcar cada,noch,e lás,cuo-
tas del día en la oficina principal para que siempre tengamos al día los
, , últlrnos:valops de,verttas,'Ahoratengo una reunión, pero podertrás discutir
los detalles más adelante. ¡Buen trabajolr>
¡ ,; ,..:,.,Miké escribió ta propriesta pára el programa Giga-Quqfe meses antes;,
peré é*taba pen*ada, coülo un programa para un soiCIfct:siil.ninguna,capa-
cidad de comunicación con la oficina pri,ncipal. Perlecto. ésta era la opor-
tunidad de dirigir un proyecto cliente-servidor en un moderno entorno CUI
(interlaces gráñcas de usuario), Io que siempre habia querido hacer. El
proyecto le llevaría al menos un año. y lo ocuparía a tiempo completo.
Mike descolgó el teléfono y marcó el número de su esposa. <Cariño, esta
noche cenaremos fuera para celebrarlo...r'
A la mañana siguiente. Mike quedó con Bill para discutir el proyecto.
<Vamos a ver, Bill. ¿Qué pasa? Esto no se parece a la propuesta en la que
he trabajado.>
Bill se sintió inseguro. Mike no había participado en las revisiones de
la propuesta. pero no hubo liempo de avisarle. Cuando el comilé ejecutivo
, , ,estudió e! programa Giga-Quote,'tbntaro* los nrand¡rs.i <Al cortrité,ejecuti-
vo le gustó la idea de construir software para automatizar las cuotas de
; r , geguto-s:$1édicos" Pero querían que se pudieran transferir aqlorllálieÉñlente
las cuotas locales al computador central. Y querían tener hecho el sistema
antes de que se hagan electivas las nuevas cuotas el I de enero. Adelanta-
ron la lecha de finalización del software que propusiste del I de marzo al I
de noviembre, con lo que se aconó el plan propuesto en 6 meses.>
Mike había estimado que el trabajo llevaría l2 meses. No creyó que
tuviese la suerle de acabar en seis meies. y así se lo dijo a Bill. <Vamos a
ver si me he enterador,. dijo Mike. <<Parece que esrás diciéndome que el
comité añadió requisitos de comunicaciones a gran escala y ha acortado él
plan de l2 a 6 meses.))
Bill se encogió de hombros. <<Sé que será un reto, pe¡o tú eres:creativo
.v creo que puedes con todo. Han aprobado el presupuesto que querías, y
añadir ei enlace de comunicacioaes no debe ser difícil. Pediq¡e,,36 perso-
nas-mes v las tienes. Puedes reclutar a quien quiera que necesiles para
el pro¡.'ecto e incremeatar el tamaio del equipe,r>,Biil le,diiof,qlue:hablai;e
con algún otro desarrollador y que buscasen la lorma de entregar el soft-
\r,are a tiempo.
l!'tike se reunió coa Carl, otro respcnsab,letécnicO" y busc*ron 1¿,f-orma
de acortar el plan. <;,Por qué no usas Q t ^ y diseño orientado a objetos?>,
(continira)
Capítulo 3: E'":'es clásicos 37
, ,,..;,;;1:;,i:::iii1,:,11111;,..:;.11,:,, t,,.1,.::
,.... ,...,..
come-,r*é,e,i¡rll: {deiáslili**.;piod*ctivc que'coriie,,j:Xr$LP.,1+-s se acsrtara en
""a,:li
illn s;>rt(. Vtite {e pareció bien. Ca#'t*,,4ffi.3eaccia una he-
rramienta de elaboración de informes que supuestamente acortaba el tiem-
p,,i*eldc óttc.,a,la milad, Ei prgyeiio tenía,''$4ftaq1gl.rin 1 ro¡
. ,,,,tá.qioi:$eóá dcs,cárnbios los {levárían
has!3 fos p neses{onsigu}o+,,9$.har-f-
y más raeláét,t ¿¡1o,lei'aho¡raba un par de ¡le*;pnasl¡fi1ffi,.
,.i.,*a¡ar:;a'wo
,:lmentéti*a¡eclutar a desarrolladores de primerísima categorla;¡$*l$'baja1
a 7 meies. Esto era suf'¡cienlemenre ajustado. Mike comentó sus progresos
a Bill.
<Mira>, dijo Bill, <dejar el plan en 7 meses esrá bien' pero no es sufi-
ciente. E,l comité dejó claro que el plazo de entrega eran seis meses. No me
dieron opción. Puedo daros el hardware que necesitáis. pero tu y tu equipo
,,,,,,.L€n j&,qq$.,s{tc4R1{4r.,¡l$$,,ftC!q*d!.1ád¡leir el
plen ¡ seis meses, o tendréis
que hacer algúnas horas extfá para paliar la diferencia>.
que quizás pod'iu uuji*iu u 6'*.,.,. <De acuerdo,

"o*;;;;.;;J;;;;u
Bill, externas espabiladas para el proyecro. Quizas
buscaré un par de personas
pueda encOniiar gente con experiencia en comunicaciones para que nos
ayude en iá descarga de datos desde el PC al mainframe'>
El I de mayo. Mike babía formado el equipo. Jill, Sue y Tomas eran
buenos desurroiladores de la .urá, y fueron liberados. Completó el equipo
con Keiko y Chip. dos contratados externos. Keiko tenía experiencia tanto
,n pC .o*o en los mainframe con los que ienía que conectarce. Jill y To-
fnas nabirn enrreviitado a Chip.y no qu.iíut-t contratarlo. pero Mike lo im-
puso. Tenia experienc"ia en comunicaciones y esta6á disponible, asi que
Mike lo contrató.
En la primera reunión del equipo. Bill dijo que el programa Giga-Quote
eia estraégicamente importante para Giga Safe Corporation. Algunos de los
magnafes de la compañja estarían pendientes de ellos. Si tenian éxito se-
que estaba seguro de que [o conseguirían.
"rían recompensados. Dijo
Después de los ánimos infundidos por el discurso de Bill. Mike se son-
.tó con el equipo y mostró él ptan El comité ejecutivo lés habia propcircio-
nado. una especilicación aproximada, y emplearon las siguientes dos sema-
nas en completar las lagunas. Despnés se emplearian 6 semanas en el diseño,
lo que dejaba 4 meJes páia la construcción y la pruebá. Su estimación aproxi-
-u¿a fue que el producto final tendriaunas.30.000 lineas en cr+. l6¿ot
los asistentes asintieron, dando su conformidad. Era ambicioso' pero lo
sabían cuando se" comprometieron con .el.proyecto.
A la semana siguiente, Mike se reunió con Stacy. Ia responsable de la
prueba. Indicó que deberia tener partes del pr,oducto terminadas para pro-
barlas no después del t de septiembre. con el propósito de tenerun produc-
to con todas las funciones el I de octubre. Mike estaba de acuerdo,
El equipo acabó la'especificación de los iequerimientos rápidamente,
y se metió en el diseño. Obruvieron un diseño.que parecía hacer buen uso
de las prestaciollei.derGl+l
Ict¡ntinúa)
3€ =::*_ _ ' .- :a :',--,ec¡os informáticos
Acabaron el diseño et 15 de junio, adelantániosé,u} pluo, y cornenr?-

ron'a godil¡car como }ocos para llegar al objetivo de tener.la,primera 1'er-
si,én:de prueba el I de septiembre. El trabajo en el proyecto:io era una
balsa de'aceite, Ni a Jili ni a Tomas les gustaba Chip,,1t:Sue se quejaba de
qus ,no q.rería que nadie se aeercase a su código. Mile atribuyó los cho-
ques de personalidades a las rnuehas horas,de trabajo, No:,obsiante, a pri-
:moros de agosto, le indicaron que estaiba hecho entre el 85.y el 90 por 100.
A mitad de agosto. el deparlamento actuarial dio las tasas para el año
siguiCnte, el equipo descubrié qúe tenia que modificarieompletaiirente la
eslruclura pata las nuevas tasas; El nuevo método de tasasión, ugcesitaba
regliz4r preguntas sobre hábitos de ejercicio. en ta trebida, en iá eomida.
actividades de ocio y otros factores que no se habían i*cluido antes ea las
fómulas de tasación. Pensaron que C++ debía protegerlos de los efecÍos
de esos carnbios. Calcularon que sólo rendrían que incluir nuevos valores
en 1as tablas de tasas. Pelo tendrian que cambiar el diálogc de'ent¡ada, el
diseño de la base de datos- el acceso a 1a base de datos,:yr los objetos de
comunicacioncs para adaptarlos a la nueva eslructura. Como el equipo es-
ta,ba revuelfo porque fenia que reajusrar su diseño, Mike dijo a,Sta:üyrque
se,ietrasarían u*os riías en la eafesa de ia primera versión para ia prueba.
p,l equipo nq había termi¡ado eI 1 de septiembre. y Mike a$eguró a
Stacy que acabarian en sólo uno o dos dÍas.
Los días se volvieron semanas. El límite del i de octubre para enrregar
el producto completo para su prueba llegó y fue rebasado. Desarrollo aún
nq había acabado el primer producto para pruet4..,:Staqy1lal.r:ó a,Bill a,uaa
reunión para trater eI plan. <<Aún:no lenernos nadá,de desarroilo>i,.,dijo,
<suponiamos que tendríamos la primera versión el I de septiembre. y pueslo
qre aún rro teaemos nada, por 1o menos nos retrasaremas un nres igsl¡e_cto
al plan original, Creo que renemos un problerna>.
<Es cieno. tenemos un problema,r. dijo Bill. <Déjame que hable con el
equipo. He prometido a 600 agentes que tendríamos el programa el I de
noviembre,Lo'entrégaremoqatiempoparaeicambiodetasas'>
Bill convocó una ieunión con el equipo,:<rÉste'és. un equipo fantástiqo,
y dgberia gumplir con sus comprom,isos*, 1es dijo. <No ,sé:Elué, e,s !c, que, ha
ido mal" pero e$pero que.todos trabajéis d¡lro y entreguéíl elr,sóftw¿re a
tiempo. Arln podéis conseguir las bonificaciongs, pefo ahora tendréis que
luchar'por ellas,r Desde ahOra os asignaré un horario de 6 dias por'seiriaira.,
10' horailal día, hasta que el soffware:esté hecho.>>rDespués,de la reunión,
Jill y Tornas se quejaron a Mike de que no había necesidad de que los
tratase-n como niños, pero accedieron a trabajar las horas:que Fill,queria.
El'equípo retrasé et plan dos semahaso promefiendo tene{ !a ulilrdad
completa, aor€truida el I5 de noviembre.,Esto dejaba 6,semáaás.para la
prueba antes de que entrasen en vigor las nuevas tasas en enero.
Ei equipo entregó su prirnera:verFión ai gnrpo de,pllrebas cua:lfo se.me-
nas después del I de noviembre. y se reunió purá trrtur. algunas de las áreas
problemáticas que quedaban.
(conrinúul
Capítulo 3. crásicos 39
Tomas esnabe frabajando e¡r la generación de.'informes y se encoatró

con una -harrera. <La página iesümen de cuotas incluye un¡gráficq de tra_
¡ras. He ut'ilizado un generádor'de,iaformes que suponía generaba gráficós
de barras, pero la única forma de genelarlos es en páginas individuales.
Uns de los requerimientos del grupé de:ven$s es que hay que poner gráfi-
cos de barras y texto en la misma página. He pensado que puedo trampear
un informe con un gráfico de barras pasando e1 texto de1 informe como una
leyenda del objeto gráhco de ba¡¡as. Realmen¡e es una irampa, pero siem-
pre puedo voiver atrás v reimplementarlo más claramente después de la
primqra versión.¡>
, Mike respondió: <<No veo dónde está e1 prcblema. Tenemos que acabar
.el producto, y no hay tiempo de hacer un código perfecto. Bitl ha de-iado
bien claro que no podemos tqner más fallos. Usa ese iruco.t
.Chip Qünentó que sri código de comunicaciones estaba hecho al
95, por,l00 )¡,que funcionalra, pero.que aún tenía que hacer algunas pr*e,
bas de ejecución. Mike vio que Jill y Tomas, se lmiraban; pero decidié igno-
rarlq.
EI equipo trabajó duro hasta el l5 de noriembre, incluyenclo las no-
ches dej 14'' y el 15 de noviembre, pero no pudieron hacer que la fecha de
snt:rega,:füese é1 15 da noviemLire. El equipo est&ba exhau*to, perü la máña-
na del dieciseisavo día. fue Bill quien se sintió deprimido. Sracy le habia
avisadc de, que desarrollo nq había entregada la versión eompleta el día
anlerior. La última semana habia dicho al comité ejecutivo que el proyecto
estaba encarrilado. otra gestora de proyectos. claire. habia investigado en
los progresos del equipo, diciendo que había oído que no esraba¡ cum-
plieldo, las entregas planif,cadas con el equipo de prueba. Bill pensó que
claire estab,q lensa y,'r6 16 rgustaba'su,irforme. Le üabir *r.g,rtado u eilu
'quet surequipo, estaba en buenr camino para cumplir las entregas,planeadás
:, :Bil1¡ dd¡ a Mike que reuniese al eqtiipo, y ctando lo hizo, párecian
derxotados. un mes y medío a 60 horas semanales hatrían sido ra puntilla,
Mike preguntó euánto tiempo les lievaría acabar, pero sil única iespuesta
fue el silencio, <¿Qué me estáis diciendo?>, dijo. <Hoy íbamos á tenarlista
la versién con todas las funciones' ¿ta tenemos?j¡ l . ' ,
, ,<Mira, Mike¡>, dijo Tomas, <<puedo entrega¡hgy mi cédigo y deeir qüe

incluye "toda la funcionalidad". pero probablemente necesitaré tres sema-
nas de trabajo de lirnpieza una vez que lo entregue)). Mike preguntó qué
queria decir Tamas con <limpieaal. <<No,he puesto el logotipo de la, em;
presa en cada página. ni que el nombre y el telélono del agente aparezca al
pie de la página. Son pequeñas cosas como ésa. Todo lo impor-tante funcio-
na bien. He acabado al 99 por 100.>
<Yo tampocó, he hechc, gxaétamente.e1, 1 00¡porr:1 00¿,,adalitió Jill_ (Mi
antiguo grupo rne,ha ilanadopara que'lei. diésé:a,po,yo,téc-n!co, y hb teaido
que emplear un par de horas dimias óon ellss. Además, ,h¿ íá olvidado
hasta ahora mísmo que los agentes pedían poner su nombre y su teléfono
ea los informes. Aún no he intplemenfado 1os:diálogos de etttrida para esos
\LotltnlLto I
+U )esarrollo y gestión de proyectos informáttcos
datcs,:t'ttámdién tengo que iracer aisunos diálogos dq lnanienimie.nto' No

C¡eiá,q*é,'fuésen necesarios para ei hite de la "urilidad completa">
" ' 'Áhórá Mike también :meezaba a senlirse rnal. <Si he oido lo que creo
düe,he'eido; me está;s dicienio que necesitáis,ireq sem4nas para complerar
el software. ¿Es corre.'to l,'
, ,<Almenás tres semanas>. dijo Jill.,El¡ests:de l$s desárrólladores estu-
vá ae aiuerAo, \'iike pasó uno por,rno y- les piegúfié,si podrían completar
sU patte en tres seÍlarras- Uno potuho, ¿¿da pro$r4madór i:erdijo que traba-
jaría duro. l que pensaba que podia hacerlo.
' , A1 final de ese día, despuéi:óe una'disstlliófi:targa e incómoda, Mike y
BiIl acord¿ron retrasar el;pt4a 3 sénranat; hasta el 5r'de diciembre, siempre
que elequipo prometierattábajar l2rhoras al dia en vez de 18' Bitl dijo que
tenía que demostrar a su jefe que estaba azuzandt al equipo de desarrollo-
La revisión del plan implicaba que tendrían que probar e1 código t prepa-
rar ai personal ¿1 alis¡.nt'¡ tiemr-o- llero era la úaica posibilidad rie ealregar
el cridig.r et i ie eleri.- Sr:.'¡ s: guqió ,ie que el r-erntrol de calidad del
softna¡e nLr rarra:s:¡:ni,j..:.:i:mr.. sul-tci.=nte para probarlo, pero Bill no
le hizo caso.
El 5 de diciembre e1 equipo Giga-Quote entregó el progr4aaa:Giga-
Quote completo al en:po de pruebas antes del mediodía. y salieron pronto
del trabajo para tener su largameare esperado dEgqpns,o,, ÍJablan¡tiabájádo,
casi constantemente desde el I de septiembre.
Dos dias más tarde, Staeydio,la p¡imera lista'de,girrries,,y'se {eia,tO.et
i*ñerno. Es dos días el grupo:,do,lruebas]de¡rtifigé, más de 200,de{ectos,en
el programa Giga-Quofq:rinél$y€ade, :3::ciatifi¡á0QE cornq,de;severidad I
{<<Tienen qgg corggir$pr>}, 11No veo lA:.for¡rtardÉr.que:el::ss.ftvrilr!¡Wfé,listo
para entregqrlq.:,q. los pgent*¡ locales,ai¡es,det i,dg,enerori; dij,$.:a1f¡q6¿5.1"-
mente el grupo de pruebas necesite ese tiempo para escribir los casos de
prueba de los defectos que ya ha descubierto. y está descubriendo delectos
cada hora. >
Mike convocó una reunión de personal a las 8 eri punto de la mañana
siguiente. Los desarrolladores.eslaban quisquillosos. Decian que había unos
cuantos eü.ofes serics, pero la rnayoría de los errores indicados no. ef¿n
realmente errores, sino malas inlerpretaciones de cómo se suponía que te-
nía que funcionar ei programa. Tomas indicó que e1 error #143 era ua éjéntp.lo
de eso- <E1 infome del error dice que en la págiaa resulnerl:de,,}A
=143
cuota. e1 gráfico de barras tieae que esfar ea ia dereeha de,!4,pá_gina,ep,yez
de en la izquierda. Esto no es un error de ser,eridad 1. Es la típica forma en
que los comprobadores sobreestiman un problema.>
tr{ike dis¡ribr¡-vó capias de los inforraesde'eiÍ.41,e$,.Lqéargóálor.deq-a-
rrolladores que revisasen los errores que el grupo de pruebas les había asig-
nado y estiÍrasea cuá*to tiempo lee llevarla,oorrregir eadá,uno de,e$Oúr.,
Cuando ei equipo se reunió de nuevo por la tarde, las noticias no eran
buenas. <Siendo realista. estimo que necesito dos semanas completas de
trabajo para corregir los errores que ya nos han pasado>, dijo Sue. <Además.
(conrinúa)
CaPitulo 3: i-':=s : :sicss 41
tengo que acabar las comprobaciones de integridad referencial de la base

de datós. En totátr ns,Eegitó.t;düp;tr.o.semanas a partir,de hoy:>
Tomas había devuelto el erior #143 a los comprobadores. cambiando
su severidad de I a I (<Cambio estético>). El grupo de pruebas respondió
que los inlormes resumen de Giga-Quote tenían que coincidir con infor-
mes simjlares generados por el programa instalado en el mainframe para
políticas de renovación. que era similar a los formatos de marketing preim-
preSos quoia compañía había usado durante muchos años- Los 600 agentes
de,la,cór,r1pañía estaban accsfumbrados a ver sus valores di ventas en grá-
{icos de,barras a 1a derecha, y teaían que quedarse a la derecha. Ei er¡or se
quedó con un rivel i, y sliptlso un problema.
. . <t[Recuerd4s !a trampa que uti]icé para que se pudiesen imprimir en
lá mismapágíftq,tl,gÍtfrto de ba¡ras y el informe?D, preguntó Tomas. ¿<Para
poner el gráfico a la derecha. tengo que reescribir ese informe concreto
desde el principio, lo que significa que tengo que escribir mi propio
c{dlgo,a.baic.,n¡v*1,9,pf4'dar:formrto,,át:infoÍmel,y,!!;;$ráficg,r¡ Mike tem-
bló. y pidió una estimación aproximada de cuánto tiempo necesitaba.
Tomas dijo que por lo menos l0 días^ pero que tendría que verlo más des-
pacio antes de estar seguro.
Antes de volver a casa. Mike dijo a Stácy y Bill que el equipo traba-
f
jaría incluso los días de fiesta y que todos los errores encontrados se corre-
ll
girían para el 7 de enero. Bilt dijo que se lo esperaba y que había aprobado
un retraso en el plan de 4 semanas antes de irse á un crucero de un tnes por
el Caribe que tenia planeado desde el pasado verano.
El mes siguiente Mike esruvo ocupado manteniendo al gn.rpo unido.
Durante cuatro meses habían trabajado todo lo duro que se podía traba-
jar,yno creia que pudiesen hacer más. Estaban en la oficina l2 horas
al dia. pero empleaban mucho tiempo leyendo revislas. pagando lacturas
y hablando por telélono. Parecia que se irritaban siempre que les pregun-
taba cuánto les quedaba para reducir la cuenta de errores. Por cada error
que se corregia, e[ grupo de pruebas descubria dos nuevos. Errores cuya
corrección debla haber llevado 2 minutos tenian implicaciones en el pro-
yecto completo y podian llevar días. Pronto calcularon que no babía forma
gnéró:f ,: :.. rr, ,: .
,de que pudieian,*ol1*$ir:tc{o1,1'os..dé,feci,oe,fáfa él:?rde ,
r E] 7 de:ene¡ó,Billrvolvió de sus vacaciones, y::lV1iks,le dijo qu€.el'ggri-,'

po de desarrollo aún necesitaba 4 semanas más. <,Esto es serio>, dijo Bill.
<tengo ó00 agentes locales que están hartos de dar vueltas alrededor de un
puñado de aprendices de informáticos. El comité ejecutivo está hablando
de 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 esiudiar sus opciones. Les
comunicó el ultimátum de Bill y les pidió una estimación aproximada de
cuándo entregarían el producto, priméro en semanas. luego en meses. El
equipo se calló. Ninguno se arriesgaba acerca de cuándo podrían entregar
tinaimente el producto. Mike no sabía qué decirle a Bill.
ItonrinLia)
-fuuuqr*o y gestión de proyectos informáticos
(contintia)
Captir c i =
-'-- -=_i
-- :_: ::s
La corporación Giga Safe mosrró su aprecio ar trabajo duro reaiizatl,r

por el'equipq de désariolla da-*dc a cada desar.ncilador
una bonificación de
250 dglares:,u11á$,cu€r1t4s sefiranas más tarde¡Tornas pidió u.na
larga baja-
y Jít'l se fue a trabajar a otra,compairia,. . : ,,
,
final Giga-Quote se entregó en 13 meses en vez de en 6.

' El'prr-r..ducto
pásándose del límite más de un 100 por 100. El esfuerzo de
desarrollo.
incl¡ryeudo las horas extras, fue de 9g personas-mes. lo que supilso un ex-
ce,lo,del, 170 por 180 ¡especro a 1as j6 persorras-mes planificaáas.
:
, ..,. 1 ,producto fisa} tenía en rorno a 40.000 lineas de código C-
no va_
ciasrl¡'gi¡ ro*entarios, supericr en más de ua j3 por 100 a lai es¡imaciones
aproximadas de Mike. Puesto que fue un producio disirib¿ido en más de
600'puestos inrernos, Giga-euole es un híbrido entre ün p¡oducto de
ses-
tión y un,pqodac{o <<pr€t-á-portenr. un producto de esre rarnaño 1. .r,- iipo
nornralnrente se:debería haber acabado en l1 meses y medio con un esfui¡-
zo de 7t,personas:mes: El pryysqts sobrepasó ambas cantidades.
3.2. Efectos de los errores en la programación

de un desarrollo
Michael Jackson (el cantante, no el informático) cantaba que <one bad
apple don't spoil the whole bunch, baby> (una manzana podrida no estropea
el barril completo, pequeña). Esto puede ser cierto para las manzanas,
pero no lo es para el software. una manzana podrida puecre estropear
el
proyecto completo.
un grupo de investigadores de ITT revisó 44 proyectos de 9 países
para examinar el impacto de 13 factores de productividad en la producti-
vidad (vosburgh et a\.,1984). Los factores incluían el uso de téinicas
de
programación modernas, dificultad del código, requisitos de eficiencia,
nivel de participación del cliente en 1a especificación de los requerimien-
tos, experiencia personal y alguno nás. Asignaron a cada factor
distintas
categorías que esperaban asociar con una eficiencia baja, media
o arta.
Por ejemplo, asignaron al factor <uso de técnicas mod..nus
de programa-
ción> valores de bajo uso, uso medio o alto. La Figura 3.1 de ra página
sisuiente muestra 1o que descubrieron 1os investigadores acerca
del factor
,,uso de técnicas modernas de programació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 cada
-inLr de 1os factores de productividad estudiados. Los investigadores
de
irr r ieron que 1os proyectos de ras categorías que tuvieran po"ca produc-
::'' r¿:d reaimente tenían una productividad pobre, como muÉstra
ra estre-
'-:":i:nra de 1a categoría Baja en ra Figura 3.r. pero la producti'idad en
{4 imarrufo y gest,íón de proyectos informáticos
t
-=
-==r.-
t=r=
-.-. Uso de técnicas modernas de prograr-aeón
(porcentaje de.i sstema toár
r a-ia s.s
-Es EJtado Porcentaje de
* es*e gráfico la planificación Baja Media Atta
:s'ErEPo_ coalsulie la nominal (0-25%) (26-75%\ (76-10tr.)
Sdn 4.2, *Bases
técnicas".
+200
Leyenda
+1 00
f-l Máximo
Prercentll del 75=.
0 (media) I 'ÉJ...J*i,
-1 00
! o"' zr==
Figura 3.1 . Estudio sobre el factor *IJso de técnicas modernas de

programac¡ó¡" (Vosburgh et al., lgg4). Hacer algunas cosas b¡en no
garant¡za el desarrollo rápido. También tenemos que evitar hacer mal
cualqu¡er cosa.
categorías de alto rendimiento variaba mucho, según muestra la fial-:.

ancha de la categoría Alta en la figura. La productividad de los pror e.-:.x
de la categoria Alta variaba desde pobre a excelente.
REFERENCIA No es sorprendente que proyectos que se espera que tengan üna pii-
CRUZADA
Para más información ductividad pobre la tengan realmente. pero sí debiera r.r.rná sorpre*. ;,
acerca del papel que descubrimiento de que muchos proyectos que se esperaba que rur-ie-
juegan los errores en
el desarrollo rápido,
una productividad excelente tienen una productividad pobre. Lo que er:
véase la Sección 2.1, gráfico y otros como éste muestran a lo largo de todo el libro es quü ¿ .--
"Estrategia general que es necesario utilizar alguno de los métodos recomendables. no es srj-
para el desarrollo
ráPido". ciente para obtener la máxima velocidad de desarrollo. Incluso si se h¿cr
algunas cosas bien, como la utilización de técnicas de proerare.;::c
modernas, aún podemos cometer un error que anule las mejoras en ;¡ :,::*
ductividad.
Al pensar en el desarollo rápido, resulta tentador pensar
QuÉ rurrrir rr
que hay que hacer es identificar las causas iniciales de un d*arr".:,"-
-* o
eliminarlas, y después obtendremos un desarrollo rápido. El prt:-:r*. rr

que no hay sólo unas pocas causas del desarrollo lento. qrri. i_:¡- n:
¡
es muy útil intentar identificar todos los orígenes del desarlr.llt'
-::-j :i
como preguntarse: ¿cuál es la causa principal de que no sea !-aF:¿ .:É ]Jrr
una milla en cuatro minutos? Bueno, soy demasiado rieitr" p*. *r,-*..
No estoy en forma. No me atrevo a intentarlo. \o tengt-r ¡lr 3*3: .:Fsrnie--
dor o capacidades atléticas. No podría ir tan deprisi uuoqt- .--ri$,É :r'üru;
joven. La lista crece y crece.
cuando hablamos de proezas excepcionales. ias razones ¿e ;.-r ,"8 nqmÍE
no las alcance son simplemente demasiado nurnerosa-i Ji-: rÉ-- ::rtrEür-
Capítulo 3: E,rrcres clásicos
-as. El equipo de Giga-Quote dei Ejemplo 3.1 cometió muchos de los errores
que han plagado el desarrollo de software desde los tiempos más remotos
de Ia informárica. El camino del desarrollo de software está lleno de ba-
ches, y los baches en que caigamos determinan la rapidez o la lentirud
con que desarrollamos el software.
En el softwarel una manzana podrida puede estropear todo el barril,
pequeña. Para caer en el desarrollo lento, todo 1o que hay que hacer es
cometer realmente un gran errori para conseguir el desarrollo rápido te-
nemos que evitar cometer algitn gran error. La si-uuiente sección enumera
1os grandes errores más habituales.
3"3. Relación de errores clásicos

Algunas técnicas de desarrollo inefectivas han sido elegidas con tanta
frecuencia, por tanta gente, con resultados tan malos y predecibles que
son dignas de ser llamadas ((errores clásicos>. Muchos de los errores
tienen 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 los

: 'i;: , is de mayor categoría y los responsables técnicos juntos no Io
:,::a' :¿', ar a ningun precio.
Jesarrollo y gestión de proyectos informáticos
cLrmoda al resto del equipo'l ;Esperaremos hasta que acabe el prolecrc

para despedirlo! ¿Hay que ace.:r.: ei lrolecro para acabar? ¡cogeremr-r:.
cuantos desarrolladores esrén .": c:sponibies. -v que comiencen 1o antes
posible!
Los desarrolladores. dir¡crir os 1' clientes normalmente tienen buenas
razones para tomar las decrsiones que toman, y la apariencia seductora de
los errores c1ásicos es una de las razones de que esos errores se cometan
tan a menudo. Pero debido a que se han cometido muchas veces, sus con-
secuencias se han hecho fáciles de predecir. Y los errores clásicos rara
vez producen los resultados que la gente espera.
Esta sección enumera alrededor de dos docenas de errores clásicos.
Personalmente he visto cometer cada uno de esos errores a1 menos una
vez, y yo mismo he cometido bastantes. Muchos de ellos aparecen en el
Ejempio 3.1. E1 común denominador de esos errores es que el desarrollo
rápido no se consigue necesariamente si se er itan. pero si no se evitan.
se-quro que se consigue e1 desarrollo lento.
Si alguno de estos errores nos resulta familiar, hay que animarse:
muchos otros los han cometido antes. Una vez que comprendamos sus
efectos en la velocidad de desarrollo, podremos utlhzar esta lista para
ayudarnos en la planificación de nuestro proyecto y en la gestión de
riesgos.
Algunos de los errores más significativos tienen sus propias secciones
en otras partes de este libro. Otros no se tratarán más. Para facilitar la
consulta, la lista se ha dividido empleando las dimensiones de la veloci-
dad de desarrollo: personas, proceso, producto y tecnología.
Personas
A continuación aparecen algunos de los errores clásicos relacionados con
las personas.
FIEFERENCIA 1 : Motivación débil. Estudio tras estudio se ha mostrado que la motiva-

CRUZADA
ción probablemente tiene mayor efecto sobre la productividad y la calidad
sobre los buenos y que ningún otro factor (Boehm, 1981). En el Ejemplo 3.1, los directivos
malos usos de la tomaron a lo largo de todo el proyecto medidas que minaban la moral: como
motlvación. consulte el
Capítulo 1 1, dar ánimos a diario al principio para pedir horas extras en la mitad, y
,. L4oiivación..
como irse de vacaciones mientras el equipo estaba trabajando incluso los
días de fiesta, para dar recompensas al final del proyecto que resultaron
ser de menos de un dólar por cada hora extra.
2: Personal mediocre. Después de la motivación, la capacidad in-

dividual de 1os miembros del equipo, así como sus relaciones como
equipo, probablemente tienen la mayor influencia en la productividad
(Boehm. 1981: Lakhanpal, 1993). Contratar apurando el fondo del barril
.,Capítulo 3: Errores clásicos 47
supondrá una amenaza al esfuerzo del desarrollo rápido. En el ejemplo, la

seiección del personal se hizo buscando quién podría contratarse más rá-
pido, en vez de quién realiz arialamayoria del trabajo durante la vida del
proyecto. Esta técnica consigue un inicio rápido del proyecto' pero no
determina un final ráPido.
flEFEEq€lA 3: Empleados problemáticos incontrolados. un fallo al tratar con

CFT.AADA personal problemático también ameflaza la velocidad de desarrollo' Es un
b¡!Erfunelán
3ñh@bnde proUtema ttabitual, y se ha comprendido bien, al menos desde que Gerald
^Weinberg
eqlf efectivos, publicó Psyc hology oi Co*put"' Programming en l9l 1' Un fallo
É* d C4l.hrlo 12,
al tomar una decisión cuando se trata con un empleado problemático
es
-Eoin#trabalo". respecto
una de las quejas más comunes que tienen los miembros de1 equipo
(Larson y iaFasto, 1989)' En el Ejemplg el equi-
de sus responiables ?'1'
po sabía que Chip era una manzana podrida, pero el jefe del equipo no
iriro ,tuda. El resultado era predecible: rehacer el trabajo de Chip'
REFERENCIAS 4: Hazañas. Algunos desarrolladores de software ponen un gran énfa-

Pero lo
CRUZADAS
¡¡ar-a más información
sis en la reaTizactón de hazafias en los proyectos (Bach, 1995).
sobre proyectos que hacen tiene más de malo que de bueno' En el ejemplo' los directivos
i¡srffis y basados en de nivel medio dieron mayoresiplausos a actitudes del
tipo (ser capaz de))
srpromiso. consulte y los informes significativos
irSecciin 2.5, "Una que a los progresos firmós y consistentes a
cm'degia alternativa á" progr"ro. Él resultado fue un modelo de planificación al límite en el
pra el desarrollo ni se conocían o
-: la Sección 8.5,
qu. lur"urn.nazas de desajuste del plan no se detectaban,
-FErilicack¡n basada ni se informaban a la cadena de directivos hasta el último minuto.
un
como rehenes
an curpromiso., o el
pequeño equipo de desarrollo y sus jefes inmediatos toman
Capítulo 34,
-Compromiso". u unu entera por no admitir que tienen problemas para cumplir
"o-puñía
su plan. gl énfasis en los comportamientos heroicos fomenta correr
un
que
riesgo extremo, e impide la cooperación entre los múltiples elementos
contribuyen al proceso de desarrollo del software'
Algunos diiectivos fomentan el comportamiento heroico cuando se
un con demasiadaftrmeza en actitudes <<set capaz de>. Elevando
"orr""nt
estas actitudes por encima de informes del estado exactos y a veces
pesi-
mistas, los directivos de estos proyectos coartan su capacidad de tomar
medidas correctivas. Ni siquiera saben que tienen que emprender accio-
nes correctoras hasta que el daño ya está hecho' Como dijo Tom DeMar-
co, las actitudes (ser capaz de> convierten pequeños contratiempos en
auténticos desastres (DeMarco, 1995).
FEFEREilCTA 5: Añadir más personal a un proyecto retrasado. Éste es quizás

CFITJZAIDA
!!e!El€reGflta¡Yasa
el más clásico de los errores clásicos. Cuando un proyecto se alarga, aña-
lrlEzc sdvar m dir más gente puede quitar más productividad a los miembros del equipo
wF@f*¿d. existenté de la que áñud"tt los nuevos miembros. Fred Brooks com-
c¡¡rmfte Cd¡o 15-
-kc¡s&¡t rb para añadir gente a un proyecto retrasado con echar gasolina en un fuego
troleG' (Brooks.1975).
tf
48 j';sa',ollo y gestión de proyectos informáticcs
6: Oficinas repletas y ruidosas' La :a¡'orja de los desarrolladores

consideran sus condiciones i. :::::'-' Ja'nlo insatisfactorias' Alrededo¡
del 60 por 100 indican QU- rrr :-3:13: s;llc-iente silencío ni privacidad (De-
Marco y Lister, 1987). Los'iraL'a¡adores que están en oficinas silenciosas
y privadas tienden a funcionar significativamente mejor que aquellos que
ocupan cubículos en salas ruidosas y repletas. Los entornos repletos I'
ruidosos alargan los planes de desarrollo.
REFERENCIA 7: Fricciones entre los clientes y los desarrolladores. Las friccio-

CRUZADA
nes entre los clientes y los desarrolladores pueden presentarse de distintas
sobre las relaciones formas. A 1os clientes puede parecerles que los desarrolladores no coope-
efectivas con los ran cuando rehúsan comprometerse con el plan de desarrollo que desean
clientes. consulte el
Capítulo 10. los clientes o cuando fallan a1 entregar 1o prometido. A los desarrollado-
.Desarrollo orientado res puede parecerles que ios clientes no son razonables porque insisten en
al cliente".
planes irreale s o cambios en los requerimientos después de que éstos ha-
I'an sido l¡ados. Pueden ser simplemente conflictos de personalidad en-
tre dos grupos.
El principal efecto de esta fricción es la maia comunicación, y 1os
efectos 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 rcchazo de1 cliente aaceptff el producto acabado. En el
caso medio, las fricciones entre clientes y desarrolladores de software 11e-
gan a ser tan severas que ambas partes consideran la cancelación del pro-
yecto (Jones,1994). Para remediar estas fricciones se consume tiempo, y
distraen tanto a desarrolladores como a clientes del trabajo real en el pro-
yecto.
REFERENCIA 8: Expectativas poco realistas. Una de las causas más comunes de

CRUZADA
fricciones entre los desarrolladores y sus clientes o los directivos son las
sobre f ijar expectativas poco realistas. En el Ejemplo 3.1, Bill no tenía razones para
expectativas, consulte pensar que el programa Giga-Quote se podría desarrollar en 6 meses, pero
la Sección 10.3,
"Gestión de las
ése era el plazo en que 1o quería el comité ejecutivo de la compañía. La
expectativas del incapacidad de Mike de corregir esta expectativa irreal fue la principal
cliente".
fuente de problemas.
En 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 demasiado
largo, 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 de
gestión (Standish Group, 1994).
Capítulo 3: Errores clás¡cos 49
I
9: Falta de un promototr e#ecüivo del proyecto. Para soportar mu-

chrrs de 1os aspe"-:..r;:- :e:i.::--: ::: lLr es necesario un promotor del
3ittr\-iClrtr i¿:h..:::"-:-. :r: --.=r3; -.+ -----:-:cación realista, el control de
:::::?:i: -. -. 11-;-*;¡::':f- :É:-e,:5 ----:.:'l: de desarrolloisin un pro-
=-:.-: a =:-:. : ::::--- : : 5-: .lÉ lf-.:-=.; :::.1tr niiel de la empfeSa
f,-rtú:::,:Lu' t;tJÉ j€ ruEEritr i-;;:p{ j* =:-=:::3¿les o hacer cambios
J-r ietr-ir.= 3; lr-:]r;!: l- ::,r-s*-:.:r i.*rTi,:-'- 3"¡'b Thomsett afirma
;IiÉ -¿ :e.:r Je I:r¡Er¡Uf-:::-,: :i:t:*ri i--::::-::3113 el tiacaso del
pro)''erm r Tnmset:. - rli-< n-
l0: Faha de participac¡ón de los implicados- T.dt¡i ir.s rr:ncipales

participantes del esfuerzo de desarrollo de sofmare deben impniu-arse en
el proyecto. Incluyendo a los promotores. ejecutir os. respollvlbles del equi-
po, miembros del equipo, personal de ventas, usuarios t'rnales. clientes ¡'
cualquiera que se juegue algo con el proyecto. La cooperación estrecha
sólo se produce si se han implicado todos los participantes. permitiendo
una coordinación precisa del esfuerzo para el desarrollo rápido, que es
imposible conseguir sin una buena participación.
11: Falta de participación del usuario. La inspección de Standish

Group descubrió que la razón número uno de que los proyectos de Siste-
mas de Información tuviesen éxito es la implicación del usuario (Standish
Group, 1994). Los proyectos que no implican al usuario desde el princi-
pio conen e1 riesgo de que no se comprendan los requerimientos de1 pro-
yecto, y son vulnerables a que se consuma tiempo en prestaciones que
más tarde retrasarán el proyecto.
REFERENCIA 12: Política antes que desarrollo. Larry Constantine indicó que si
CRUZADA hay cuatro equipos hay cuatro tipos diferentes de orientaciones políticas
sobre las políticas de (Constantine, 1995a). Los <políticos> están especializados en la <gestión>,
seguridad, consulte la centrándose en las relaciones con sus directivos. Los <investigadores) se
Sección 10.3, "Gestión
de las expectativas del centran en explorar y reunir información. Los <aislacionistas> están so-
cliente". los, creando fronteras para el proyecto que mantienen cerradas a los que
no son miembros del equipo. Los <generalistas> hacen un poco de todo:
establecen relaciones con sus directivos, realizan investigaciones y ex-
ploran actividades, y se coordinan con otros equipos como parte de su
modo de trabajo. Constantine indicó que inicialmente los equipos políti-
cos y generalistas están bien vistos por los directivos de alto nivel. Pero
después de un año y medio, los equipos políticos llegan a la muerte súbi-
ta. Primar la política en vez de los resultados es fatal para el desarrollo
orientado a la velocidad.
l3: llusiones. Estoy impresionado de ver cuántos problemas del desa-

rrollo del software se deben a la ilusión. Cuántas veces hemos escuchado
cosas como éstas a distintas personas:
ti
I
I
,,\inguno de los miembrú: :-, ::-i.:-- ::;: ::¡lmente que pueda com-
pletarse el proyecto de a"-¡.:: - - . : '- -.-: :lenen. pero piensan que
-- quizás si trabajan duro. r n::. ".:: '-.:' :--:ral un poco de suerte, serán
capaces de concluir con érii,'.
<Nuestro equipo no hace:t-::-- :::r:-- iara la coordinación de las
interfaces entre las distintas p:::;. :. ::- ¿;cto. pero tenemos una buena
comunicación para otras cosas. i -,= ' ---:---.¡¡s son relativamente simples,
así que probablemente sólo nec¿:l:.::: -. -:; dia o dos para eliminar los
erfores.))
<Sabemos que contamos con ur ¡:.'::':i,ador externo de poco talento
para el subsistema de la base de da¡os. '. r--3 3s dificil ver cómo va a acabar
el trabajo con los niveles de personal gu: i:: especificado en su propuesta'
No tienen tanta experiencia como algun.rs de los demás desarrolladores
externos, pero puede que compensen con energia lo que les falta en expe-
riencia. Probablemente acaben a tiempo.,'
<No necesitamos reflejar 1a última lista de cambios en el prototipo para
el cliente. Estoy seguro de que por ahora sabemos lo que quiere.>
,,El equipo está diciendo que realizará un esfuerzo extraordinario pat'a
curnplir ccrn 1a fecha de entrega, y que no han llegado a su primer hito por
po.Lrs dias. pero creo que alcanzarán éste a tiempo.>
Las ilusiones no sLrir ¡¡l¡ ¡rptimismo. Realmente consisten en cerrar

1os ojos ]- esperar que lLrdo iun.-:one r-uaodo nLr se tienen 1as bases razona-
bles para pensar que será asi. Las ilusiones a1 comienzo de1 proyecto 11e-
van a grandes explosiones al fina1. Impiden ller.ar a cabo una planifica-
ción coherente y pueden serlaraíz de más problemas en el software que
todas las otras causas combinadas.
Proceso
Los errores relacionados con el proceso ralenfizan los proyectos porque
malgastan el talento y el esfuerzo del personal. A continuación se mues-
tran algunos de los peores errores relacionados con el proceso.
REFERENCIA 14: Planificación excesivamente opt¡mista. Los retos a los que se

CRUZADA
enfrenta alguien que desarrolla una aplicación en tres meses son muy
sobre los planes diferentes de aquellos a los que se enfrenta alguien que desarrolla una
irreales, consulie la aplicación que necesita un año. Fijar un plan excesivamente optimista pre-
Sección 9.1 ,
" Planif icac¡ón
dispone a que el proyecto falle por infravalorar el alcance del proyecto,
excesivamente minando la planificación efectiva, y reduciendo las actividades críticas
oPtimista'.
para el desarrollo, como el análisis de requerimientos o el diseño. Tam-
bién supone una excesiva presión para los desarrolladores, quienes alargo
plazo se ven afectados en su moral y su productividad. Ésta es la mayor
fuente de problemas de1 Ejemplo 3.1.
Capítuto 3: Enores clásicos 51
@A 15: Gestión de riesgos insuficiente. Algunos errores no son 1o sufi-

6rgrm son los llamados
cientemente habituales rá-o pu.u considerarlós clásicos.
una cosa se pasará de tener pto-

iE!ÉrGft de los riesgos, con que sólo vaya mal
*=ffiHü;;;..¿;;;l;'.,,*i'.L¿'i*l.']ll3."T::::i:1?::.j:il..'""
11
cm6t. @'o ]Irto un desarroll" tápi¿" uno con un desarrollo lento' El fallo de
r:rqm'' "on " e''or clásico.
ir";;_;i";", uno solo de estos riesgos es un
a veces contratan la
HEFERENCIA 16: Fallos de los contratados' Las compañías para
CRUZADA realizaciónde partes á" ptoy"cto cuando tienen demasiada prisa
Fara más información "
hacer el trabajo en casa' Pero los contratados
frecuentemente entregan su
sóre contratados, al no coincidir con
consulte el trabajo tarde, con una calidad inaceptable o que falla
como requerimientos inesta-
CaPítulo 28'
.Desarrollo externo". la especificación (eoehm, 1989)' Ri"'got un contratado
ser enoñnes cuando
bles o interfaces mat definidas pueden
contratados no se gestionan cui-
entra en escena. Si las relacioné' to"
los
externos puede talenttzar
REFERENCIA dadosament e, la utllizaciá" ¿" desarrolladores
CRUZADA
flara más información
el proyecto envez de acelerarlo'
sobre la Planificación,
planificamos para conseguir un
consulte
*Planificación ",
17: Planificac¡ón insuficiente' Si no
obtenerlo'
en la Sección 4. 1. desarrollo rápido, no podemos esperar
Abandono de la planificación baio

presión. Los equipos.l:1"t*
REFERENCTAS 1g: se troplezan
.RU7ADAS rrollo hacen planes y rutinariamente los abandonan cuando
1989)' El problema no está
sobre praniricación ," pr"ui"-u _"i rá pru'in"u"ión (Humphtey, al no' crear un p-lan alter-
oqo presión, consulte """
en fallar
en el abandono del pfun''ti"o *ás üi"n
tl"i,,'o¿o de trabajo de codificar y corregir' En
1;ff::t#:', lu,tuo, v caer entonces
presióndelaelEjemplo3.l,el.qoipouuu,'donósuplandespuésdefallarenlaprimera
¡aniticación",ver 1á habitual. A partii de e-ste
punto' el trabajo no,tuvo
CaPítulo 16,
.Recuperación de
"";.';;:;"rto,ri", ir punto. {e que Jill empezó a ttabajar
"t"gun.i;,*truri" grupo y nadie lo supo'
del tiempo para un proyecto dá su viejo
"ooriinuóior,
provectos>' parte
El <inicio difuso> es el
19: Pérdida de tiempo en el inicio difuso'
el proyecto; este tiempo
tiempo que transcurre antes de que comience pt"t.l,p--Yl,tto' No
tl
normalmente se pierde;;i;;d" de
aprobar y hacer
desperdicie meses o años en un inicio
difu-
es poco común que un ñ;il
so, y entonces se está u'tûíp""'tut de
o" plan agresivo' Es mucho más fácil
po"u* o meses del inicio
y barato y menos urrr",guaá suprimir unas '"-uttas
difuso envezO" eiplan de desarrollo en ese mismo tiempo'
REFERENCIA
"o*p?i*ir
Los proyectos que
20: Escatimar en las actividades iniciales'
CRUZADA se
ka rÉs infomación
gúre €scalimar en las aceleranintentandou"o,tu'lasactividadesnoesenciales'ypuestoqueel
ilivifades in¡dales. producen código
el diseño no
análisis de requerimientos, la arquitectura Y
E'!s¡.üe .Efeclos cle la
En un proyecto desastroso en el
Paaniñcadort directamente, son los .urrá¿uto* fáciles.
El responsable del equipo
etc€s¡Yarnefrte que participé, pedí q". ;; enseñasen el diseño'
opiiñ*sla-- en la
S€cciin 9'1 ' á" ái¡ot Ño ñ"*o, tenido tiempo de hacer el diseño'>
Los resultados de este error. :emLriilt ,-trlüCido como <saltar -.

"
codificación), son todos demasiadLr prii¿cl:i¡s. En e1 ejemplo, un rnrJ -
DATOS REALES de dlseño en el informe del gráfico de barr-¿s üe sustituido por un traba.,:
de diseño de calidad. Antes de poder entregar e1 producto, el trabajo c.-
truco tuvo que tirarse, y hubo que hacer de rodos modos el trabajo bil:
hecho. Los proyectos que normalmente escariman en sus actividades
iniciales tendrán que hacer ese trabajo en orro momento, con un cosi:
de 10 a 100 veces superior a haberlo hecho bien inicialmente (Fagan, 19-b:
Boehm y Papaccio, 1988). Si no podemos encontrar cinco horas para hacei
el trabajo correctamente la primera vez, ¿cómo vamos a encontrar 50 para
hacerlo correctamente más tarde?
21 : Diseño inadecuado. Un caso especial de escatimar en 1as actir i-

dades iniciales es el diseño inadecuado. Proyectos acelerados seneran un
diseño indeterminado. no asienando suficiente tiempo para é1 r-originan-
do un entorno de alta presión que hace diñcil la posibilidad de considerar
alternatir as en el diseio. E1 enl¡sis en el diseño esiá más orientado a 1a
ccrnreniencia que e la calidad. por 1o que necesitará rarios ciclos de dise-
ño antes de poder {tnahzar completamente el sistema.
REFERENCIA 22: Escatimar en el control de calidad. En los proyectos que se ha-

CRUZADA
cen con prisa se suele cortar por 1o sano, eliminando las revisiones detr
sobre control de diseño y del código, eliminando la planificación de las pruebas y reali-
calidad, consulte la zando sólo pruebas superficiales. En el ejemplo, las revisiones del diseño
Sección 4.3, .Bases
del control de calidad.. y del código se eliminaron limpiamenle para conseguir una ganancia con-
siderable en el plan. Al final, cuando el proyecto alcanzó su hito de plena
funcionalidad, 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 de control de
DATOS REALES
calidad al comienzo del proyecto probablemente supondrá de 3 a 10 días
de actividades finales (Jones, 1994). E,sta reducción va contra la velo-
crdad de desarrollo.
REFERENC¡AS 23: Control insuficiente de la directiva. En el ejemplo hay poco con-

CRUZADAS
Para más informactón
trol de la directiva para detectar a tiempo los signos de posibles retrasos en
sobre controles de la e1 plan, y los pocos controles definidos al comienzo se abandonaron cuando
directiva. consulte el proyecto comenzó a tener problemas. Antes de encarrilar un proyecto,
-Seguimiento,'. en
la Secc¡ón 4.1. y el en primer lugar debemos ser capaces de decir si va por buen camino.
Capítulo 27. -Hitos
m ¡n iatu ra.
24: Convergencia prematura o excesivamente frecuente. Bastante
.
antes de que se haya programado entregar un producto, hay un impulso

para preparar el producto para la entrega, mejorar el rendimiento del pro-
ducto. imprimir la documentación final, incorporar entradas en el sistema
final de ayuda, pulir el programa de instalación, eliminar las funciones que
no Van a estar listas a tiempo y demás. En proyectos hechos con prisa,
CaPítuto 3' Et'c'e s clásicos 53
Puesto que
ha,v una tendencia a fotzar prematuramente la convergencie'
del producto cuando':
no es posible forzat 7at""t"iÁtttia 1:'^t1 :i="not
media do-
forzar la convergencia
proyectos de desarrol;"t¿pl¿? intentan
se produzca. Los intentos
cena de veces o .,'a, u*"i J"
q.r" finalmente
al producto' Só1o son una pér-
adicionales o. .onu"ti"^"Ju "o f"ttn"ian
drda de tiemPo Y Prolongan el Plan'
guar-
la estimación' Si la gente no
25: Omitir tareas necesarias en tareas me-
anteriores' olr'ida 1as
da cuidadosamente datos de provectos omitido
se han de añadir' El esfuerzo
nos visibles, p"ro ,oi t"ur; ;"t (\¡an Genuch-
en un 20 o 30 por 100
suele aumentar e1 plan ¿. ¿.rurrollo
ten,1991).
26: Planificar ponerse al día más

adelante' Un tipo de reestimación
en
es responder inuptoplJa-u;t*
al retraso del plan' Si hemos trabajado
y hemos empléado tres meses en llegar
al
un proyecto durante 6 meses'
hacer? En muchos proyectos
hito correspondiente a los dos meses' ¿qué se hace'
el re^traso más tarde' pero nunca
simplemente se plantea recuperar construyendo' in-
Aprenderemos más JJ pt"i*'" -conforme
1o estamos
conocimientos
cluyendo más sobre; ;;; ;".
llevará construirlo. Estos
reestimación,del plan'
necesitan reflejarse en 1a
la reestimación se debe a cambios en el produc-
REFERENCIA Otro tipo de error en de tiempo
CRUZADA to. Si el producto o"; *;"; construyendo cambia' 1a cantidad
::-a -ás información tamblén' E'n el Eiemplo 3' l los reque-
-=::-: a reestimación,
necesaria ouru .o,"tiiti" ""t"Ui'a ginal,v el
'
com ienzo
la. propuesta ori
co n su Ite rimientos pri nci pales"c;;;i;;;;;;tre los recursos'
:=:: reestimación del plan o de
del proyecto ,itt tu t*"'pondiente
lcración', en la
garantiza que
Sección 8 7 sin ajustar el plan
El crecimiento de las nuevas prestaciones
no se alcanzará 1a fecha de entrega'
que la co-
27: Programac¡ón a destaio' Algunas organizaciones creen
es e'í camino hacia el desarrollo
dificación rápida, riüi ár óo*o 'ulgu'
están 1o suficientemente moti-
rápido. Piensan qt" S io* desarrolladores razones que se
obstáculo' Debido a las
vados, pueden,otu"ntut cualquier
a 1o largo de todo este ribro,
esto está lejos de la verdad'
verán ciaramente
Esteenfoquemuchasu"-t""tpresentacomounenfoque<empresarial>
es sólo la envoltura del vieio
al desarrollo de software, pero realmente ambiciosall^"::i
una planificac-ión
paradigma a destajo combi'lado con dos negactones
de que
combinación ,uru,'u"tt' funciona' Es un ejemplo
no constituYen una verdad'
Producto
.\continuaciónsemuestranlosefroresclásicosrelacionadosconlafor-
¡il en 1a que se deline e1 Producto'
54 lEsa-d,ro _y !resri6,- F l"*ec¡us ,rfuma?ire
&* Em de requerimflenb_ -lJ_emm rrma-ecros tienen más reqrc-
rmemrs ée Io> üue róü$l:rE_ O¡r¡e *¡ nriqtlo inicio. La ef,icienciá ¡c
ñ-i¡ mt' r¡c:ri:iti -.Eli e Erenod' de lo que es necesario, y puede
¡nra
ger*rr
plenificacim del softn-arc imecesariamente rarga. Los usuarios tier,-.
den a interesarse mer')s en ras prestaciones complejas que
en ras de r¿s
secciones de marketing o de desarrollo, y las presiaciones
comprejas alar-
gan desproporcionadamente el plan de áesarrollo.
REFERENCIA 29: cambio de las prestac¡ones. Incluso si hemos evitado

CRUZADA con éxito lo¡
Para más información requerimientos excesivos, los proyectos sufren como media
sobre un
sobre el cambio de 25 por 100 de cambios en los requerimientos a lo largo de
prestaciones, consulte su vida (Jo_
nes, 1994). un cambio de este calibre puede produciJun
el CapÍtulo 14, aumento en er
"Control del conjunto plan de al menos un 25 por 100, lo que puede ser fatal pu.u
de prestaciones".
to, froyecros
de desarrollo rápido.
REFERENCIA 30: Desarrolladores meticurosos. Los desarrolradores encuenrran

CRUZADA
fascinante la nueva tecnología, y a veces están ansiosos por
Para consultar probar nue\-as
un ejemp¡o sobre prestaciones de su lenguaje o entorno, o por crear
cómo, incluso
su propiá implemenu-
ción de una utilidad bonita que han visto en otro producto, la
accidentalmenle, un nece-
site o no su producto. El esfuerzo requerido para diseña.,
desarrollador puede
caer en requerimientos
i*fl.-"n*-
probar, documentar o mantener estas prestaciones innecesarias
excesivos o superf luos, alarga
véase "Objetivos poco el plan.
claros o imposibles",
en la Sección 14.2.
31: Tiras y aflojas en ra negociación. cuando un directivo
aprueba
un retraso en el plan de un proyecto que progresa más
lento de lo espera_
do, y entonces añade tareas completamenie nuevas después
de un cambio
en el plan, se produce una situación curiosa. La razón
subyacente de esto
es difícil delocalizar, puesto que el directivo que
aprueba er retraso en el
plan lo hace sabiendo implícitamente que el plan
esiaba r".o
unavez que se corrige, la misma persona reariza acciones "quiro"uoo.
explícitas para
volver a equivocarse. Esto sólo puede ir en contra del plan.
32: Desarrollo orientado a ta investigación. Seymour

cray, er di-
señador de los supercomputadores cray, dijo que
no inientaba sobrepasar
los límites de la ingeniería en más de dos áreas iruu"t,porque
el riesgo de
un fallo es demasiado alto (Gilb, rgBg). Muchos proy""to.
,oftru." ¿"0.-
rían aprender la lección de cray. Si er proyecto fuerza
los límites de la
informática porque necesita la cieación á" ,rrr.rro.
algoritmos o de nuevas
técnicas de computación, no estamos desarrollandó
software; estamos
investigando en software. Los planes de desarrollo
de software son razona_
blemente predecibles; ros planes en la investigación
sobre software ni
siquiera son predecibles teóricamente.
Si el producto tiene objetivos que pretenden aumentar
ros conocimientos
CaPítuto 3: E'r:'es clasicos 55
existentes, como algoritmos' r.eiocidad'

utilización de la memoria y de-
es altamente especulati\ a' Si
más, debemos asumir que ia planificación
algún otro punto débi1 en
queremos mejorar el esiado del arte y tenemos
el personal' requerimientos
;i;;;;;.;t, ;"ott", a"l""onal, debiiidades enexternos, etc., podemos tirar
vagos, interfaces in"*tu'uta, con contratados
queremos superar el estado del
por la venta,tu tu ptu.tiii"u"iO" prevista' Si
no debemos esperar hacerlo
arte por todos 1os meái'os, hagámoslo' iPero
rápidamentel
Tecnología
con el uso correcto o
El resto de los errores ciásicos están relacionados
incorrecto de la tecnología moderna'
ejemplo' se. confió demasiado
REFERENCIA 33: Síndrome de la panacea' En e] no se habían usado antes
que
CRUZADA en las ventaja, proclu'lradas de tecnologías
(generadore* ¿" lnt¡''-JiJi-*" ori""ádo aobjetos y C++) y demasiada
sobre el sÍndrome de serían en éste entorno de desarrollo
la panacea, consulte la poca información sobre lo buenas que
sólo a una nueva téc-
Sección 15.5, 'EI
concreto. Cuando el equipo del proyecto se aferra con
síndrome de la tíqiqo,' y
Panacea". nica, una nueva tecnoiogía o un procesg "t1"1i..:::"]ver (Jo-
inevitablemente equivocado
ello sus problemas ¿" lrá?ln"""ión, está
nes, 1994).
der empreo de nuevas herra-

REFERENCIA 34: sobreestimación de ras venta¡as
mejoran raramente su produc-
CRUZADA mientas o métoOos.' iu, organizaóiones
tividad a grandes ,ui'o',sin iriportar cuántas
tt"uut herramientas o mé-
sobre cómo salvar las
Los beneficios de las nuevas técnicas
estimaciones usando todos empleen o 1o b;;;;;"t sean'
herramientas de
son parcialm.nt" ¿"*ptu'uáo" po'
las curvas de aprendizaje que llevan
me¡ora de
técnicas para aprovecharlas al
productividad, asociadas, y upre,tdei a utllizir nuevas
técnicas también suponen nuevos
consulte "Reducción
realista del Plan", en
-ri..g"r, ti"uu iu tiempo' Las nuevas
*eî-o bien experimentaremos
la Sección 15.4. que sólo d",.ttb'i'"-os usándolas' Más
porcentaje por pfoyecto en lu-
mejoras lentas y continuas en un pequeño
gar degrandes ,"I;;;ñquipo oet^rje*pto :'t
debería haber previsto
comomuchounl0porl00degananctaenproductividadporlaul\líza-
""n
ción de las nuevas iáoi"giur ,",
que estarían cerca de
de asumir
duplicar su Productividad'
de las mejoras se produce cuan-
REFERENCIA Un caso especial de sobreestimaciones
E'ste tipo de reutilización
CRUZADA do se reutiliza código de proyectos anteriores'
ser una técniía muy eiectiva' pero
el tiempo que se gana no es tan
sobre la reutilización, ;;"d.
ionsulte el CaPítulo 33' grande como se espera'
" Reutilización' '
proyecto' - -Es un viejo
35: Cambiar de herramientas a mitad del
puede tener sentido actualizar
recurso que funciona raramente' A veces
55 --,=se--p;c _r !€SiÉ- .F 31a9CrOS infOrmátiCOS
--{:üErrntalmente dentro de la misma linea de productos, de la version -:

a ia 3.1, o incluso a la 4. Pero cuando estamos a la mitad de un proyecro. ,"
curv-a de aprendizaje, rehacer el trabajo 1. 1os inevitables errores come:--
dos con una herramienta totalmente nueva, normalmente anulan cualquie:
posible beneficio.
36: Falta de control automático del código fuente. Un fallo en l¿

utilización del control automático del código fuente expone a los proyecttrs
REFERENCIA
CRUZADA
a riesgos innecesarios. Sin é1, si dos desarrolladores están trabajando en i¿
Para más información misma parte del programa, deben coordinar su trabajo manualmente. De-
sobre el control
berían ponerse de acuerdo para poner la última versión de cada archir t-
del código fuente,
consulte "Gestión de en el directorio maestro y verificarlos con los demás antes de copiarlas en
la configuración este directorio. Pero invariablemente alguno sobreescribirá el trabajo del
del software", en la
Sección 4.2. otro. Se desarrolla nuevo código con interfaces desfasadas, y después se
tiene que rediseñar el código al descubrir que se ha utilizado una versiLin
equivocada de la interfaz.Los usuarios avisan de errores que no podemos
reproducir porque no hay forma de volver a crear los elementos que han
utilizado. Como media, los cambios en el código fuente suelen ser de un I [¡
por 100 al mes, y con un control manual del código fuente no deberian
crecer lJones. 1994.¡.
LaTabla 3.1, de la página siguiente, contiene una lista completa de
1os errores 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ágina_<"
pero los que se indican son los más comunes y los más serios. como indico
David Umpress, de la Universidad de Seattle, la vigilancia que la mal,oria
de las organizaciones realiza para evitar estos errores es como ver una \
otra vez La islq de 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 plan
parecía funcionar inicialmente, pero, como revelaba el episodio, algo iba
mal, y al final de1 episodio los náufragos volvían donde habían empeza-
do, perdidos en la isla.
De igual forma, la mayoría de las compañías descubre al final de cada
proyecto que han cometido otro error clásico y que han entregado otro
proyecto fuera de plazo, con mayor coste, o ambas cosas.
Su propia lista de malos hábitos

Debe ser cuidadoso con los errores clásicos. puede crear listas de <malos
hábitos> para evitarlos en futuros proyectos. comience por la lista que apa-
Capítulo 3: Enwes clásicos 57
Tabh 3-l- f}slff¡en de los errores clásicos
Errsrt¡ rffonados Errores relacionados Errores relacionados Errores relacionados

con l¡¡ pcrlíDnas con el proceso con el producto con la tecnología
l_ Motivación débil 14. Planificación 28. Exceso de JJ. Síndrome de la

excesivamente requerimientos panacea
2. Personal mediocre
optimista 29. Cambio de las 34. Sobreestimación
3. Empleados
Gestión de riesgos prestaciones de las ventajas del
problemáticos
incontrolados insuficiente 30. Desarrolladores empleo de nuevas
meticulosos herramientas o
Hazaias t6 Fallos de 1os
contratados métodos
3 1. Tiras y aflojas en
Añadir más 35. Cambiar de
Planif,rcación la negociación
personal a un
proyecto retrasado insuficiente 32. Desarrollo
herramientas a
mitad del proyecto
18. Abandono de la orientado a la
6. Oficinas repletas
planificación bajo investigación 36. Falta de control
y ruidosas
presión automático del
'7. Fricciones entre código fuente
los clientes y los Pérdida de tiempo
desarrolladores en el inicio difuso
8. Expectativas poco 20. Escatimar en las

realistas actividades
iniciáles
9. Falta de un
promotor efectivo 21. Diseño inadecuado
del proyecto 22. Escatimar en el
10 Falta de control de calidad
participación de 23. Control
los implicados insuficiente de ia
Falta de directiva
participación de1 24. Convergencia
usuario prematura o
t2. Política antes que excesivamente
desarrollo frecuente
13. Ilusiones 25. Omitir tareas

necesarias en la
estimación
26. Planificar ponerse
al día más adelante
2'7. Programación a
destajo
rece en este capítulo .Yayaincrementando 1a lista según se vayan acabando

proyectos para aprender de los effores cometidos por su equipo. Estimule
este comportamiento para otros proyectos dentro de la empresa' para
5t kú yg rb@inbrn¡atim
gender de sus errores. Intercambie experiencias con los colegas de otns
cgruizaciones y aprenda de su experiencia- Exhr-h en lugar visible la
lista de elTores, y así la gente la veni y aprendeni sin cometer de nuevo los
mismos errores.
Bibliograf ía adicional
Aunque algunos libros tratan sobre errores de código, no conozco libros
que describan los errores clásicos relacionados con los planes de desarrollo.
En el resto de este libro se incluyen referencias sobre temas relacionados.
Bases del desarrollo
de software
Contenido
Bases de gestión
Bases técnicas
Bases del control de calidad
Seguir las instrucciones
Temas relacionados
Estrategia para el desarrollo rápido: Capítulo 2
Resumen de inspecciones: Capitulo 23
RED AUERBACH, EL ENTRENADOR QUE tr¡Ás uBIr¿Po DURO con

los Boston Celtics, y hasta hace poco, el que más veces ganó en la histo-
ria del baloncesto profesional, lanzó un vídeo titulado <Red on Round-
ball>. Auerbach mantiene el hecho de que los conocimientos básicos son
el punto clave para tener éxito dentro del baloncesto profesional. Indica
que de al menos 20 pases de los que se realicen, sólo van a tener éxito
aquellos en los qULe haya alguien que coja el balón. La clave del éxito en
efrebote radica en coger el balón. Tener una buena base fue la estrategia
que Auerbach siguió pafa ganar ocho veces seguidas los campeonatos de
la NBA.
Para obtener éxito en e1 software hay que prestar la mayor atención
posible a los fundamentos. Podría ser el Bob Cousy, Kareem Abdul Jab-
bar o Michael Jordan de su organización software. Podría disponer de
una serie de métodos orientados a la planificación. Pero si no utiliza los
conceptos básicos de desarrollo como el punto más importante de1 esfuer-
zo de desarrollo, se arriesgará a no alcanzar las metas de planificación
que se ha propuesto.
59
l:sr--: c t, gest,tó. Je cicyectos informát),c.>
\ormalmente las personas S*-_-:, :-:::_: --_: ,:: t;3nos rne:a:_,: .:tr
ingeniería del software porque esra:- :,- , :.:r;3 Jontribuii: : i!-
mentar la calidad. Sus consejos pareia:. :a:.:: - - r.r. -:Jrrrr.lüs rii:_i-. :-
Pero no piense en esto como una cuesiión o¿ := s- -.. ::cnicas ñlr;,- ;r.
utilícelas. Si no funcionan, ¡no lo haga! \Ii rrltl,:::s que se iet-rir
utllizar los métodos fundamentales de ingenieria ,le- s,¡l-r*are ,Je.;: _,,
en este capítulo, no porque estén <bien>>, sino porqu-::,iucen e1 .::::
el tiempo de comercialización.
Todos desean estar Esta postura es menos teórica de lo que se podrían imaginar. F:.
en un equipo -.:
análisis de 10 proyectos software, que las organizaciones s;1ecc1.r:: :
cctmpeón, pero nadie
desea realizar el como <los mejores proyectos>, Bill Hetzel llegó a la conclusión :- ;-.r:
esftrerzo para <si había que buscar una conclusión que destacara por encima de -'. :1.-
llevarlo a la más, se podía decir que los mejores proyectos 1o eran porque s- l:,:::,n:
práctica.
en los fundamentos. Todos conocemos los fundamentos para un i: .. -
Bobby Knight
ware; la diferencia está en que la mayoría de los proyectos n.-
-.-
_- :-rr
bien, y entonces tienen problemas> (Hetzel, lgg3).
El mejor lugar para comenzar a buscar información sobre 1cs --
mentos del desarrollo del software es un libro de texto de inse:,¡:.. -- ::
software en general. Este libro no es un libro de texto de ingenieria ü¡ :,. --
ware, de forma que este capítulo se limita a identificar los lunc":-=.:
del desarrollo, explicar cómo afectan a la planificación de1 ie.,::-
cuantificar el impacto de su efecto (si es posible), y proporcion¿- - - -i-
ciones para poder obtener más información.
En este capítulo, los métodos se dividen en métodos de gesric,_--. :=:- _
cos y de control de caHdad. Algunos de los métodos no se encuad:.:- _. - -
tro de una categoría, de forma que podría hojear tod.as ias cateso::;: :*-*
que esté más interesado en una en particular. pero primero sería col'. ;r,:- . :
ver el Ejemplo 4.1 para situarse dentro del contexto.
Ejemplo 4.1. Falta de fundamentos de desarrollo
<ó{osotto;,pens.ábamos Qu.e ,esiábamos, sqgqros de,Jc que estábamos ha¿i:r.

do>, dijo BillaCharles. <La versión 3 de nuesrro programa de prim¿_. e
Venlas,,FPV,,qüe,utiliiamos para pagar las comiñiones a ios a.sente>- n*-i
salió bast¿nte bién. Péro,con ta,verijó* 4;todo:'cambié.> g;li ¡au;a si,jo e,
-íefe de las versiones de la I hasra la 4. y charles era un consejero ré.-a:;.:
1l¿mado por Giga-Safe pará que les ayudara a iomprobar poi qu. 1a r *-
sión 4 había sido tan probiemátic¿.. ,
<.Cuáles fueron las dilerencias entre la versión 3 y la 4?,,. pret_::.-

Charles.
<<Tu'imos prcblemas con las versiones I y Z>r.respoadió Bili- .¡r::
con ia versión 3, creiamos que nuesLros problemas habían quedadc. r:rs.
vdi-' : j' Bases del desarrollo de software
61
\l¿'::¿:stimación fue nrecisa; en parls

Se desal:ro11ó,si,n,apenas problemr<'
porque. aprendfmos a aaaditt"' *u'gtt ;:s:guridad de un 30 por' 100: Los
'¿éJorófü¿ores'cási no tuvieron p'obit-" ;¿:: ias lareas' herrainientas o
T¡;¡' ::e lenomenal>i'
.i-"*entor'¿r,diseño que se 1es oiridab¿r- ]'-
r{Entoncesi ¿q.,¿ o"*Ji"on t^ t't"¡"n -' :::iio Charles' . ' l
<iFue algo totalrnente diferénte' La lersi'ir' i ¿:¡ ::: r'ctualización evo-

cornpi:l'::a:3 :'-'r-\'Lr' que se tuvo
rlrtloi;¿í;iu,versión 4 era un producto
que deí"r 11 r,desde el principio' ---- -i-i'¡¡.< adqut-
ri-s ¡'.r¡:iil:ertos a,.ln¡
, Los miembros de1 -i¡tp" L*taron aplicar
:ridos en las vei$iones rlii ¿tl PPY' Peio ec
ura pa::e cer
té¡¡ica-<
i:::::-^..'"
¡esuit¿lt'lt >31 rr3s ccil'r-
ir ¡ral- Las ta¡eas
,¡difi*"ió" comenzó a
Tuttu'.qt"^los de=arroiladores habian
esri-
plicadas de 1o que se t;taü problemas
mado que podrían,u,¿u"'J ¿iut requerian
I o-3 semanas' !1abía
,con algunas nu"ouu t ie d"sa.rollc, -v ei equipo perdió la bata-

"rru*i"ota* der equipo no conocían todas las reelas
lra con ellas. Los nuevos miembros
, del,mismo, y desaproveitraron,traaaio
y tieqp6,p.orque robrgescribían en-
nadie podia predecir cuáado es-
, tre ellos'sus archivos ¿¿ *áU.¡" Ai'final;
en que:rea'1ql'eniei:lo estsvo' La
taría listo el produeto, hasta et momento
ve¡sión 4 tuvs un leffaso de un 100 por '100'l - , " ' ,' ,r-^Ll^ +6 '
: <Eso sue"a tastantl"áa1o;,ug*gi Charles. <Mencionó que h*tria teni-
do pio-bt"mas: con las versiones 1
y Z''¿fu"d"'doscribirme un poco'esos
proyectos?> proyecto
<<En la versrón 1 del PPV' el
t<Por supuesrorr, ccntestó Bili'
una sstimac-ién del proyecto completo v la
fue un compl"to
"u*r'ltttl'üo Lcs problemas técnicos
planifioación de tas taiau frie"iu casi aieatoria'
Las herramientas de desarro-
, resültaron s", *uyoar, áá1o qo" ge esperaba'
11ó que se suponía q."'ü;;;h"nar
iiglgo iocreq¡'enla{ou el tiempo de ta
retraso tras otro en la plani-
planificación,El equipo derdesá$ollo sufria un
el producto estaria realmente preparado'
ficación, y ninguno sabía cuándo
hasta uno o dos días ;;;; que rálmente 1o estuvo' 41 frnal' ef eq¡ino
;:## ;."-.;ü;;;;; ;; un 1 00 por 1 00 de retraso sobre la plani -
licación inicial >
versión 4>' dijo Charies'
<Esto es muy similar a 1o que sucedió'son:ia
..
' , liPensá que habiemos aprendido la
<Es ciertc¡>, Bill saci¡dió la calieza,
Iección hace mucho tiemPo''r
I ,' . ,,¿Q..é sncedió can li ve¡slón '2?>,
preguntó Charles'
de una forrna más,r€gular que
<En 1a versiór,- 2,'ei;¿*uit"ffo p.O"rdil
,.enlaverslón]'Laestimacióndelproyectoylap.lanificaciéndelastareas
con-
elltrabajo iécnico parcció- estar másl bajg
más realistas,
Iriái¿¡t" 1r
de desanollo y e1 trabajo
trol, Hubo 1rreno, pro¡üJnttoo luohtttamienias
que se había estimado' Cametie-
del equipo'de des¿rrollo llevó el tiempo
más'
,on en 1a estimáción, poniendo liempo'de
"rror., ;;do el el equipo descubrió
Pero suandQ * tú final deip¡oyecto'
muchas de las tareas' Tam-
que en la estimaciÓn origiúal nohabialinciuido
eual que tendrían que
¡ignificé
bién descubrleron fallJ'en el diseño';lo
l a t)lttitlitLt \
vt
62
rolver a revisar del l0 a1 15 por lr,tr.r ie. s::::-';. l-:¡ -: _:ri: :-:::i- :lr
la planifi cación, donde tenian que inclui¡ i¿-. -,¿re¡-. ¡. :.;-:;i 1 -l rj, .- .,1
Terminqron el'tlabajo, encontrando unos cu¿rnrlrs problemas ¡nás- sii-:-.r
otro reiraso,'y finalmente entregaron.el producto Ea ,iü por 10ü t¡:¿: ::
este momento aprendimos a añadir un 30 por 100 de margen dc s:r-: -.:
a las planificaciones.>
(Y flitonces, ¿la versión 3 iue bien?r¡, pr€gunfó Charles
<Desde luego>. agregó Bill.
<Según he entendido, ¿se utilizó el mismo código base en 1as
nes de la I a la 3?', pregunló Charles.
(Si,).
<¿Trabajaron 1os mismos miembros del eq*ipo en las r,e¡siones de .¿
a lz 1;>>
<Si. pero muchos se marcharon ai tereiaar la r-ersión 3. de lbrma q',:=
ia mavoría de1 equipo de la reisión J no habia irabajado en el pro-\3J::
aate¡ic¡rmente. t
dijo Charies. "H¡ siio úe srar ar-ud¿."
<qGracias'.'.
Charles pasó el resto dei dia hablando con el equipo de desarrti..-- .
par la noche se enconlró de nuevo con Bill. <Lo que tengo que de¿1rr:
pSgde .que no sea{ácil para usted). dijo Charles. tqComo corisejero técnicc.
he,-visto,docenas de pfoyectos en tLn año, y en toda mi profesién he vlsto
cientos de proyecfos en rnás de cien organizaciones. El proceso seguido
por las versiones de la I a la 4 del PPV es bastante cornún.
An\enormente. me dio a entender que \os desarro\\adores no comiol:: . -
el código fuente de forma automática. y esta tarde lo confrrmé i::,::¡.
con ellos. También confirmé que el equipo de desarrollo no re:.:.-::. -.-
visiones del código o del diseño. La organización confia más e¡ ..:; -:- -
:,ción que se hace a ojo'- aunque se tengan disponibles métodos de ¡s.'-':,:: :,1
más fiables.r,
<De acuerdo>,. dijo Bill. <Todo eso es cierlo. Pero. ¿que rifli¡:i: i-:
hacer para que no nos ocurra lo mismo con otros proyectos coñri .'. L:
verslon 4-'))
: :<Eso es ¡rarte'de 1o. que puede ser duro de oír>,,dijo Charles.
:: "\¡' -:-
cesita hacer nada. Necesita meiorar en los fundamentos del des¡::.-- -
del soltware o se encontrará con lo mismo una y otra vez. Necesii¡:..--
solidar los fundamentos. En la parte de gestión, se necesita una mar or :::--
tividad en la programación, planificación, seguimiento y medidas. F: :
parte técnica, necólit¿ más ,efectlvidad en la gestión de requisitos. disel,: "
construcción y configuración. Y además necesita un mayor control d: :,-
lidad. r'
<Pero la versión 3 la hicimos bien>. objetó Bill.
<Desde luego>, agregó Charles. <.Lo hicieron bien de vez en cuar¿..
cuando trabajaron con un producto con el que estaban lamiliarizadtr:..,.:
miembros de un equipo con el que habían estado trabajando anies er:-
mismo producto. La mayoría del equipo de la versión 3 habia traba.iado e:
Cltpíffio4: Bases del desarrollo de software 63
4.1. Bases de gestión

los
Los fundamentos de gestión tienen al menos tanta influencia como
Ingeniería del
técnicos en la planifiáción de desarrollos. El Instituto de
que inten-
Software ha observado repetidamente que las otganizaciones
antes que la de
BIBLIOGRAFIA tan implantar la disciplinu d" lu ingeniería del software
ADICIONAL
La descripción en este
gestióndeproyectosestánabocadasalfracaso(Burlton,1992).Lages-
caPítulo de los tión normalmente controla las tres magnitudes del triángulo de equilibrio
clásico (planificación, coste y producto), aunque algunas veces el
fundamentos del depar-
desarrollo es similar a y
tamento de marketing controla la especificación del producto,
a veces
la que el lnstituto de
el
lngeniería del Software el departamento de d-esarrollo controla la planificación (normalmente,
ha denominado un
desarrollo siempre controla la planificación real; y a veces también
con-
Proceso "rePetitivo".
Para más detalles, trola la planifi cación programada).
Los fundamentos de gestión consisten en determinar el tamaño del
véase The CaPabilitv
Maturity Model:
Guidelines for producto (incluyendo funiionalidad, complejidad y otras características
lmproving the Software
Aet proAocto), ásignando los recursos apropiados a un
producto de ese
Process (Carnegie
Mellon UniversitY/ tamáño, creando un plan pan aplicar esos recursos y luego controlando y
Software Engineering dirigiendo los recursos pára impedir que el proyecto se desvíe._ En algu-
lnstitute, 1 995). gestión
no.-"u.or, los altos ,urgo, delegan explícitamente estas tareas de
simplemente 1o dejan vacan-
a los responsables técnicos, y en otfos casos
te, ocupándolo un responsable o desarrollador motivado'
Estimación y plan¡ficación
IEFERENCIAS Los proyectos bien ejecura,i'.-s ::-:- :.-::-s e-LaFas básicas para crei: Jl,L
CRUZADAS planificación software. Pr::r::.' -: 3sil:iü ¿l tamaño del producto. lu;=- **
Para obtener más
información sobre la estima el esfuerzo nece:.1::¡ :;:¿ üonstruir un producto con ese tarr--:
estimación, véase por último se realiza una pianif'jcación. basándose en la estimación J:, ::-
el Capítulo 8,
fuerzo.
"Estimación". Para
obtener más La planificación estimación son las bases del desarrollo porqu-
información sobre la
1-
-;
estimación incorrecta reduce la eftciencia en e7 desaffo11o. Una estim;;,: -
planificación, véase
ei Capítulo 9, correcta es una condición necesaria para una planificación efecfiva, que
.Planif icación".
además es esencial paraun desarrollo efici.ente.
P\anrtrsairón
Como Philip \\r. \{etzger señaió en su c1ásico }fanaging a Progranin'..*;
Project (Gestrón de un Provecto de Pro_sramación), 1a mala planificac:-:
se manifiesta como tuente de problemas más a menudo que cualquier ,-:.
causa (Metzger, 1981). A continuación se enumera la lista de probl;:,,.
que aparecen en el desarrollo softu.are que é1 propone:
¡ Mala planilicación.
¡ Contrato mal definido.
o Mala planificación.
. Definición del problema inestable.
ERROR CLÁSIco . Falta de experiencia en la gestión.
. Mala planificación.
o Presión política.
o Control de cambios poco efectivo.
o MaIa planífícación.
o Plazos poco realistas.
¡ Mala planificación.
REFERENCiAS En 1a revisión que hizo de los mejores proyectos, Bill Hetzel en-
CRUZNDAS
contró que \os melores proyectos de la tndustrta se caracterizab¿l f r.r _r_:
sobre estos temas. luerte planificación anticipada para definir las tareas y program¿.-.':--:
véanse el Capitulo 12. (Hetzel. 1993). La planificación de un proyecto softu,are incluve las ¿; - -
"Equipo de trabajo,,:
el Capítulo 13. r,idades siguientes:
.Estructura del
equipo"; el Capítulo 7, a Estimación y planificación.
"Planificación del ciclo
de vida"; el Capítulo 5, a Determinar el número de personas que deben participar en ei :;* -
"Gestión de riesgos". po de1 proyecto, qué habilidades técnicas son neces¿ne-i. :*'---- -
y el Capítulo 14.
"Control del conjunto
aumentar el número de personas y quién participará.
de prestaciones". Decidir cómo organizar el equipo.
I
Capítuto 4: Bases del desarrollo de software 65
. Elegir el modelo de ciclo de rida que se vaaufllizar'

o Gestión de ries$os.
Tomar decisionás estratégicas, tales como controlar el conjunto
de
.
que comprar o crear al-
prestaciones del productJ y decidir si hay
gunas Partes del Producto.
Seguimiento
IJnavezque se haya planificado el proyecto, hay que seguir el proceso
de
REFERENCIA
plan previsto: que
CRUZADA desarrollo para comprobar que se está cumpliendo el
Para más detalle y calidad' Normalmente el
sobre un método del satisface sus objetivos de planificación' coste
gestión inclu¡'e listas de tareas'
seguimiento de control de seguimiento en el nivel de
proyectos, véase el hitos. informes de pre-
Capítulo 27, "Hitos reuniones e informes sobre el estado, revisiones de
miniatura". Supuestosydemásgestiones.Elcontroldeseguimientoenelniveltécni-
y las en-
.o norrnuláente incluye las intervenciones y revisiones-técnicas
terminados.
tradas de calidad, quá controlan si los hitos se
consideran
era evi-
Bill Hetzel descubrió clue en todos <los mejores proyectos> del
y seguimiento del estado
dente la realizaciónde una estricta medición
del proyecto
ptoye"to. La medición del estado para mantener la
gestión
planifica-
ipur"." como un subproducto naiu191 de un buen trabajo de
y es un factor clave de éxito (Hetzel, 1993)'
pro-
Cá*o sugiere la Figura 4.1, en un proyecto típico la gestión-del
"'iórr,
conoce 1o que se
yecto es cusilrna función de caja negra. Difícilmente se
resultado
va a hacer durante el proyecto, y sólo hay que quedarse,conêl
100 por 100 de
final. En un proyecfoid"ál, .n todo momento se tiene el
un poco
visibilidad. -En un proyecto eficiente, siempre se tiene uJ T::9t
de visibilidad, siendo.más normal el tener una buena
visibilidad que no
tener ninguna.
lnicio Final
Visibilidad de un \-J\.¡\,'\-r ---vr\ /.^/ \

1/
proyecto ideal
Visibilidad de un
proyecto eficiente
Progreso
Visibilidad de un del proyecto
proyecto con el
modelo de ciclo
de vida en cascada
bien desarrollado
Visibilidad de un
proyecto típico
Figura 4.1. La visibitidad del progreso cambia según la clase

de
práiecto. El desarrollo eficienté olre"e más visibitidad que el desarrollo
típico.
66 J9-.: i- :- :.;.,"cÍos informáticcs
Capers Jones informa que (.ci Jt':I:.'. J; -: :-_.,:-.-.:ji.i:_-j :- -_:

nalo que muchos desastres softw.are ba-rt¿:::; ;a:-a,,;-;c,s rLtr si a,:,._ ,: :-,r.rl
hasta el mismo día del despliegue esperado,, rjones. 1995br J,-.:-,jr,,
de evaluar 59 muestras entre 1987 y 1993, el Instiruto de Ingen:---. ,.
Software dedujo que el 75 por 100 necesitaban mejorar la super.,:.-.
el seguimiento del proyecto (Kitson y Masters, 1993). cuando las ,-,:-.,- -
zaciones han sido asesoradas, han intentando mejorar y han ruel:¡ . ..:*
licitar evaluación, se ha visto que los principales problemas ?p;::.;-
en las áreas de planificación, seguimiento y supervisión del prc,..:: ..
(Baumert, 1995).
El seguimiento es una actividad fundamental en el proceso de ,.:._-
nificación software. si no se puede seguir un proyecto. no se puede -=.-
tionar. No hay forma de saber si el plan se está ile'ando a cabo ni irr ;
-:
se debería hacer después. No hay lorma de controlar ros riessos ;:- .
proyecto. un seguimiento efectivo permite detectar rápidamente lo: ::--
blemas de planificación. cuando aún queda tiempo para poder res,:.-
verlos. El desarrollo rápido no se puede ller.ar a cabo si no se sisr-.e ..
proyecto.
Medidas
REFERENCIA una de las formas de progresar en una organización software. a larsc., f -.-
CRUZADA
Para obtener más
zo, es recoger datos métricos para analizar la calidad y productividac c;
información sobre las software. Prácticamente todos los proyectos recogen datos sobre los ,-¡.-
medidas, véase el
tes y la planificación. Pero estos datos son limitados y no ayudan mucl-,,:,
Capítulo 26,
.Medidas". a reducir los costes o a disminuir la planificación.
Recoger más datos puede suponer mucho tiempo. Si además de datos
de coste y planificación se obtienen datos históricos, como el tamaño ,j;
los programas en líneas de código, o cualquier otra medida, se tendrán las
bases para la planificación de proyectos futuros, que siempre es me_irr:
que el instinto. cuando eljefe diga: <¿podéis desarrollar este producro er
nueve meses?>, podremos decir: <Nuestra organización nunca ha desa-
rrollado un producto de ese tamaño en menos de 11 meses, y el tiemp..
medio paratal producto es de 13 meses.))
Para rcarizar el desarrollo de forma eficiente, se necesita tener unurs
conocimientos básicos sobre las medidas o métricas del software. Se nece-
sita conocer 1os temas a los que afecta 1a recogida de medidas, incluyendc
qué cantidad o cuánto tiempo se necesita para recogerlos y cómo hacerlo.
Se
deberían tener conocimientos sobre métricas específicas y utilizarlos para
analizar el estado, la calidad y la productividad. rJna organización que
desee implantar el desarrollo rápido necesita recoger las medidas básicas
para saber cuá1 es la velocidad de desarrollo y si es mejor o peor a medida
que transculTe e1 tiempo.
L
Capítulo 4: Bases del desarrollo de software 67
Bibliografía adicional sobre las bases de gestión

Los cuatro primeros volúmenes listados a continuación tratan sobre te-
mas muy generales de software, incluyendo temas pragmáticos, como
por
ejemploquéhu."rconunmiembroproblemáticodelequipo;cuestiones
téóricas, iomo puede ser cómo modelizar un proyecto software como
un
sistema, y temas.esotéricos, como puede ser la importancia que
tiene la
observación para ei desarrollo del softrvare. Los libros de Weinberg
son
entretenidos y llenos de ideas.
Weinberg, Gerald M.: Quality Software Management, vol' l: Systems

Thin-
king. New York: Dorset House, 1992'
Weinbirg, Gerald M.: Quality So/'tware Management, vol' 2: First-Order
Measuremenl. New York: Dorset House, 1993'
Weinberg, Gerald M: Quatity SoJiware Management' vol' 3: Congruent
Action. New York: Dorset House, 1994'
Weinberg, Gerald M.: Quality Software Management' vol' 4:
Anticipating
Change, New York: Dorset House, 1996'
pressmanl Roger s.: A Manager's Guide to software Engineering. New
york: Mcóraw_Hill, lgg3. Es uno de los libros que muestran una vi-
sióngeneralsobrelagestióndeunproyectosoftware.Incluyeuna
introáucción sobre la estimación, análisis de riesgos, planificación
y seguimiento, así como el elemento humano' El único inconvenien-
t. q.t. ultliza un formato a base de preguntas y respuestas' lo
",
cual pódría parecer inconexo a algunos lectores' (Fue lo que me
suce-
dió a mí.)
carnegie l¿etton university/Software Engineering Institute: The Cap abi-
tii l,Iqtur¡n. ,\,Íoclel: Guitletines J'or Improving the So.ftware Process.
Reading. \iass.: Addison-\\-esler'. 1995. Este libro describe un entor-
no a nivel de gestión apio para la comprensión' gestión y mejora del
desarrollo de1 soffir'are.
Thayer, Rrchard H.. ed.: Turorial: softw'are Engineering Project Mana-
ir*"n,. Los Alamitos- Caiif': IEEE Computer Society Press' 1990'
E, ,6u colección de 45 artículos sobre temas de gestión de proyectos
software. Los artículos son algunos de los mejores estudios disponi-
per-
bles sobre temas de planificación, otganización, contratación de
sonal, dirección y control de un proyecto software' Thayer hace una
breve introducción y una serie de comentarios sobre estos temas en
cada uno de los artículos.
Gilb, Tom: Principles of software Engineering Managemenl. woking-
ham, England: Addison-Wesley, 1988' La tesis que Gilb mantiene es
que los áirectores de los proyectos generalmente no desean predecir
lt que sucederá con sus proyectos; prefieren controlarlo. Gilb se cen-
tra en el desarrollo de los métodos que contribuyen al control de la
['
I
pi¡niticación del software. \- muchLrs ¿¡ -¡s -:-e:urirf,S guü se :-.;__--, -T
en este libro están catalogados como meiüdL1s r-cünendable:.
DeMarco, Tom'. Controlling Software Projects. Nes \-ork: Yourdon }¡-..
1982. El libro de DeMarco no parece en absoluto anticuado. T:¿-, ::
1982 con los mismos problemas con los que nos enfrentamos ::,
directivos que 1o quieren todo y clientes que desean todo al mome:-:.
Presenta éstrategias de gestión de proyectos, prestando especial a:e--
ción a las mediciones.
Mefzger, Philip W.: Managing a programming project,2d Ed. Ene.¡-
wood Cliffs, N.J.: Prentice Hall, 1981. Es un libro de texto clásic;
que hace una introducción a la gestión de proyectos. Está basran::
desfasado, ya que presta especial atención al modelo de ciclo de r-ic.
en cascada y a métodos de desarrollo dirigidos por documentos. per¡
alguien que lea el libro con intención de ser crítico encontrará q:,;
Metzger aún tiene cosas importantes que decir sobre los proyectos de
hoy, y además lo dice bastante bien.
Aunque el libro siguiente no trate específicamente sobre proyec{os

software, puede ser de interés comentarlo.
Grove, Andrew S.: High Output Management. New York: Random House.
1983. Andy Grove es uno de los fundadores de Intel y tiene grandes
conocimientos sobre cómo gestionar una compañía en una industria
técnica competitiva. Grove usa un enfoque altamente cuantitati'o de
la gestión.
4.2. Bases técnicas

un estudio realizado en 1984 sobre <Métodos de programación mo-
dernos> (bases técnicas) comprobó que no se puede arcanzar una gran
productividad sin utilizarlos. La Figura 4.2 muestra los resultados del
estud io.
Es el mismo tipo de gráfico que se presentó en el capítulo <Errores
clásicos>, y nos muestra el mismo mensaje. La aplicación de las bases
técnicas, por sí sola, no es suficiente para obtener una alta productividad.
Hay algunos proyectos que utilizan métodos de programación mod.ernos
con gran detalle, y obtienen la misma productividad que otros que no los
utilizan. Esto nos indica que las bases son necesarias, pero no suficientes,
para conseguir un desarrollo rápido.
Larry constantine cuenta una historia sobre el concurso de Software
de la Australian computer Society (constantine, 1995b). El concurso con-
sistió en llamar a equipos formados por tres personas para desarrollar y
entregar una aplicación de 200 puntos de función en 6 horas.
I
Capítuto 4: Bases del desarrollo de software 69
Uso de técnicas modernas de programación

(porcentaie del sistema total)
Porcentaje de
la planificación Baja Media Alta
nominal (o-25%) (26-75%) (76-1oo%)
?==ERENCIA
CRUZADA
Para obtener +200
,níormación general
sobre este tipo de Leyenda
gráficos, véase la +1 00
Sección 3.2, "Efecto
de los errores en la
programación de un 0 (media)
desarrollo".
!l:**:l;,;
-1 00
Figura 4.2. Resultados del factor "lJso de los métodos de programacron

,ód"rnor, (Vosburgh el al., 1984)' No se puede alcanzar la productividad
que en este
máx¡ma sin'utilizar ,,los métodos modernos de programac¡ón',
capítulo se denominan ubases técnicas"'
El equipo de Ernst y Young decidió seguir una metodología de desa-

rro11o foirnal, una versión reducida de la metodología que acostumblaban
a seguir; completa con actividades por etapas y entregas intermedias'
Su
que se des-
1
propiresta inciuyó un cuidadoso análisis y diseño, parte de 1o

I
.r, este capítulo como bases técnicas. Muchos de sus competidores rl
"riu"
se metieron de lleno en la codificación, y en las primeras horas, el equipo
.tI
de Ernst y Young se quedó atrás. ;¡
'i
Sin embargo, al mediodía el equipo de Ernst y Young era el equipo
dominante. Al terminar el día, este equipo perdió, pero no fue debido a su
metodología formal. Perdieron porque sobreescribielon accidentalmente
algunos ¿"e tos archivos, entregando menos funciones al final del día de
lal que habían demostrado que tenían a la hora de1 almuerzo. De forma
irónica, lo que les hubiera salvado no era el haber sido menos 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 effol
clásico de no utilizar un control efectivo del código fuente'
El mensaje de esta historia parece suficientemente claro, pero algunos
escépticos, incluyéndom e a mí, quedaron sorprendidos: Realmente, ¿de-
bería el equipo de Ernst y Young haber ganado si no hubiera sido por el
(sí>. Rea-
embrollo de la gestión de la configuración? La respuesta es
parecieron unos meses más tarde en otro concurso de desarrollo rápido
(esta vez con control de versiones y haciendo copias de seguridad) y ga-
naron (Constantine, 1996).
En este caso, las metodologías formales merecieron la pena en un solo
día. Si prestando atención a las bases técnicas se puede conseguir esta
L
t-
7ll W y gÉtun e n:syrr.tas informátiss
dittrencia en esta cantidad de tiempo' imagirren l¡e üferencia gc I¡t

haber en un proyecto de 6 a 12 meses.
Gestión de requerimientos
REFERENCIA La gestión de requerimientos es el proceso que consiste en reunirre{Fcm-
CRUZADA miJntos; plasmailos en un tlocumento, correo electrónico, cuadern &,
sobre los métodos tnlerfaz di usuario, prototipo ejecutable o cualquier otro formam: b*rm
tradicionales de la un seguimiento del dise¡o y del código; y gestionar los cambios rm. i
gestión de
requerimientos, véase resto del proyecto.
el Capítulo 14, ts muy común que los desarrolladores se lamenten de los probltmm"
"Control del conjunto asociados a los métodos de gestión de requerimientos tradicionales- w-
do la mayoría de ellos demasiado rígidos. Algunos métodos puedeu ro
de prestaciones".
demasiado rígidos, pero la alternativa que ofrecen suele ser peor' La ar-
tudio realizado en más de 8.000 proyectos encontró que las tres re-aGt'
principales por las que los proyectos eran entregados tarde, por elL:M[
áel presupuesto y con menos funcionalidad de la que se esperaba err¡m
debidas a los métodos de gestión de requerimientos: falta de inform¡"u¡'
DATOS REALES
del usuario, requerimientos incompletos y cambios en los requerirnitmmm
(Standish Group, 1994). Un estudio realizado por el Instituto de Ingrm
iiu ¿"t Software llegó a la misma conclusión: más de la mitad de loe pur-
yectos que se estudiaron tuvieron una gestión inadecuada de los requun*
mientos (Kitson y Master, 1993).
REFERENCIA El éxito en la gestión de requerimientos depende del conocimien¡g dc
CRUZADA
suficientes métodos diferentes, de forma que sea posible escogef los m¡m
apropiados para un proyecto específico. A continuación se muesrran h*
sobre el control de
problemas en las bases de la gestión de requerimientos:
prestac¡ones, véase la
Sección 14.2,
"Proyecto avanzado: o Metodologías de análisis de requerimientos, incluyendo análiqi*
control de cambios de
las prestaciones..
estructurado, análisis estructurado de datos y análisis orisnrado ¡
objetos.
o Métodos para crear modelo del sistema, como diagramas de clascs.
e1
diagramas de flujo de datos, diagramas entidad-relación. not¡;ir.'c

del diccionario de datos y diagramas de estado-transición'
o Métodos de comunicación, como el Desarrollo conjunto de A+ril-
caciones (JAD), prototipado de la interfaz de usuario y-métoúcrs
generales de entrevistas.
o Las relaciones entre la gestión de requerimientos y los diferenns
modelos del ciclo de vida, incluyendo el prototipado evolutir-o- ¡¿
entrega por etapas, espiral, cascada y codificar y corregir'
La gestión de requerimientos proporciona de dos formas üfefef,Iñ$

una gran influencia en la velocidad de desarrollo. En primer lugar. [a rc-
cogida de requerimientos es un paso que tiende a hacerse sin prisas. com'
Capítti.to 1 Bases del desarrollo de software 71
parado con otras actividades dei ie:.-.-¡11o del software. Si este paso se
acelera sin perjudicar a la calidad. se li:-ü- drsminuir en conjunto el tiempo
de desarrollo.
En segundo lugar, obtener un requelir-t¿:t:¡ ;omo es debido en el pri-
mer paso normalmente cuesta de 50 a l[r,l','--' :]e nos que si se espera a
-,
las fases de construcción o mantenimient¡ ' B ¡;:::: Papaccio, 1988). Un
proyecto normal tiene un 25 pot 100 de ca:ri-':s;:' -os requerimientos.
Algunos métodos de gestión de requerimiel:¡s :::::-l:er reducir e1 nú-
mero de cambios. Otros métodos de desarrt-¡li¡ :;:::-:::: re-l';clr e1 coste
de cada cambio en los requerimientos. Irn¿¡l:e ii ¡=ci.. ctrmbinado
que produciría por un lado reducir el número ¿e cambios de un 15 a un
DATOS REALES
l0 por 100, y simultáneamente reducir el coste de cada cambio en un f'ac-
tor de 5 o 10. El desarrollo rápido podria estar a su alcance.
Diseño
Del mismo modo que tiene sentido crear una serie de bocetos antes de
construir una casa, tiene sentido crear una arquitectura y un diseño antes
DATOS REALES
de construir un sistema software. Un error de diseño que no se detecta
hasta la fase de comprobación, necesita 10 veces más tiempo para arre-
glarlo que si se detectara en la fase de diseño (Dunn, l9B4).
¿Está preparado cualquieraparahacer un buen diseño? No'
Mi opinión
es que el buen diseño es un tema de conversación común en el desarrollo
del software, y que realmente pocos desarrolladores hacen algo de dise-
ño. Un diseñador que trabajabapara Microsoft dijo que en 6 años de en-
rrevistar a más de 200 candidatos para el puesto de desarrollador del
ERROR CLASICO softu'are. só1o había entrevistado a 5 que pudieran describir exactamente
los conceptos de <modularidad> y <ocultamiento de informaciónn (Ko-
hen.1995).
Los conceptos de modularidad v ocultamiento de información son ias
bases dei diseño. Ambos son pañe de las bases de1 diseño estructurado y
del diseño orientado a objetos. Un desarrollador que no puede discutir sobre
los conceptos de modularidad y de ocultamiento de información es como
unjugador de baloncesto que no sabe regatear con el balón. Cuando consi-
deramos que Microsoft examina rigurosamente a sus candidatos, incluso
antes de que sean entrevistados, llegamos a la espantosa conclusión de
que la situación en el mundo del desarrollo del software está consi-
derablemente peor de 1o que se creía, que de 200 desarrolladores, 195
tienen lagunas importantes en sus conocimientos sobre las bases del diseño.
A continuación se muestran los temas básicos sobre la arquitectura y
el diseño:
o Principales estilos de diseño (como el diseño orientado a objetos,

diseño estructurado, diseño orientado a la estructura de datos).
-!-
72 Dwnolto y gestion e pffic informátias
cacepto. fimdamcm¡cs der dis€Do lcomo ocultamiento de infor-

niiin- modul¡rxfrü úm¡rcci¡n- mpsulación, cohesión, aso_
rsr¡p-&¡ftbriÉ*f,
mpr&bfftr ic¡s generalmente
É-ir&FTr:rq - ern¡cionalüación y duras (inclu_
localización,
pa- *rü e-n & cadenas. entrada/salida, gestión
& ncrrnrL, rbrr-dEd-cs. lnun€nca an pun,o rlotun_
te, dis& de bases de dú8, lwhdr'lm y reutilización).
consideraciones del diseño prwias der dominio de la aplicación
en la que se está trabajando (aplicaciones financieras, aplicaciones
científicas, sistemas <<empotrados>>, sistemas en tiempo real, soft-
ware de seguridad critica y otros).
o Esquemas de arquitectura (como organización de subsistemas, ni-
veles, estilos de comunicación de subsistemas y arquitectura típica
de sistemas).
o Uso de herramientas de diseño.
REFERENCIA Es posible desarrollar un sistema sin diseñarlo primero. Los principa-

CRUZADA
les sistemas se han implementado a través de una códificación cornpleta
Para obtener más y
detalles sobre un tipo una habilidosa depuración, gran entusiasmo y mucho más tiempo
de diseño bien
del es-
perado (y sin diseño sistemático). Sin embargo, el diseño es ra
adaptado a los tase de ra
proyectos de desarrollo construcción, planificación, seguimiento y control del proyecto, y
ese di_
rápido, véase el seño efectivo es imprescindible para conseguir la velociáad máxlma
Capítulo 19, "Diseño de
para el cambio". desarrollo.
Construcción
En el momento en que se llega a ra construcc ión, ya se ha rlevado
a cabo la
mayor parte del trabajo para el éxito o fracaso del proyecto.
Tanto la gestión
de requerimientos como el diseño ofrecen una mayor influencia
en la pla-
nificación del desarrolro que la construcción. En estas actividades,
ros
cambios pequeños pueden marcar una gran diferencia en la pranificación.
En la planificación, la construcción no ofrece muchas áportunidades
de reducción, pero el trabajo de construcción es tan detallado
y laborioso
que es importante hacerlo bien. Si en un principio la
calidad del có-
digo no es óptima' es casi imposible volver hacia airás y
me¡oárta. Reat-
mente no es efectivo hacerlo dos veces.
Aunque la construcción es una actividad de bajo nivel, se presenta
ra
posibilidad de perder el tiempo en cosas poco eficientes
o de áerpirtarse
en tareas que, aunque no son críticas, consumen tiempo. por
ejemplo,
se puede perder el tiempo en funciones que no tienen
que ser brillantes,
depurar código inútil o ejecutar.on.r-"io pequeñas secciones
del siste-
ma antes de saber si realmente es necesario afinarlas.
Capítulo 4: Bases del desanotp ce ür.Írnáre
Los malos métodos de diseño pueden forzar a que se tengan que rees-
cribir las principales partes del sistema; los malos métodos de construcción
no pueden forzar a que se tenga que hacer esto. Sin embargo, los malos
métodos de construcción pueden introducir errores sutiles que pueden re-
querir días o incluso semanas para encontrarlos y coregirlos. A veces, se
puede tardar tanto tiempo en encontrar un error en la declaración de un
vector como en tener que volver a diseñar o implementar un módulo ma1
diseñado. El trabajo total que se indica en la depuración es un <<*1>, y no
varias páginas de código nuevo, aunque la penalización en la planifica-
ción es la misma.
Las bases de la construcción incluyen los temas siguientes:
o Métodos de codificación (incluyen las variables y funciones, pre-

sentación y la denominación de documentación).
¡ Conceptos relativos a los datos (incluyendo el ámbito, persistencia
y momento de asignación).
¡ Directrices para ufllizar tipos de datos específicos (incluyendo los
números en general, enteros, números en punto flotante, caracle-
res, cadenas de caracteres, booleanos, tipos enumerados, constan-
tes, vectores y punteros).
o Conceptos relativos al control (incluyendo la otgatización lineai
de1 código, uso de condicionales, control de bucles, utilización de
expresiones booleanas, control de la complejidad y utilización de
estructuras de control poco usuales, como goto, return y procedi-
m ientos recursivos).
¡ Aserciones y otros métodos de detección de errores, centrados en
el código.
o Reglas para compactar código dentro de rutinas. módulos, clases y
archivos.
o Métodos de depuración y comprobación de unidades.
o Estrategias de integración (como la integración incremental, inte-
gración <big-bang> y desarrollo evolutivo).
o Estrategias y métodos para el afinamiento del código.
o Las ventajas, inconvenientes y detalles del lenguaje de programa-
ción que se está utilizando.
o Uso de herramientas de construcción (incluyendo entorlos de pro-
gramación, soporte para grupos de trabajo, como el correo elec-
trónico y el control del código fuente, bibliotecas de código y gene-
radores de código).
Algunas de las bases anteriores requieren tiempo, aunque en la vida

del proyecto en general ahorran tiempo. Hacia el final del proyecto, un
director le comentó a un amigo mío: <Va usted más despacio que los de-
más programadores del equipo, pero es más cuidadoso. Hay un puesto
:ir*i -i:id en este equipo, ya que hay bastantes módulos que tienen *;-
:'r-:i!rs lallos y tienen que volver a escribirse.> E,sta frase delata a ;:.
t,:iSrro? que aún no comprende por qué requiere tanto tiempo realiz":
;l 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 d¡
ahorro de tiempo. Las buenas constmcciones previenen la creación de u:,
nido de ratas de código indescifrable, que hace que el proyecto se pai-
lenta y ruidosamente cuando una perscna cae enferma, cuando se descL-
bre un fallo crítico, o simplemente cuando se necesita hacer un cambic',
E,stos métodos mejoran las previsiones y el control que se tiene sobre e -
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-
guration Management) es un método de gestión de los <artefactos>> de-
proyecto, de forma que el proyecto permanezca en un estado consistenre
todo el tiempo. SCM incluye métodos para evaluar los cambios pro-
puestos, seguir los cambios, manejar varias versiones y guardar copias de
la evolución de los artefactos del proyecto. El artefacto del proyecto mas
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 construir el producto. Yo incluso utilicé SCM para escribir esre
libro, ya que el no utilizarlo en mi último libro me causó demasiados pro-
blemas.
La mayoría de los libros de desarroilo del software consideran 1a SC\{
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, ios
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 bien
usted o sus compañeros de equipo tendrían que rehacer de nuevo el traba¡o.
tu
)* La falta de control automático sobre el código fuente es bastante co-
rnún e ineficiente. En las organizaciones analizadas entre 1981 y 1993. el
Instituto de lngeniería del Software encontró que más del 50 por 100 ne-
cesitaban mejorar la gestión de configuración del software (Kitson ¡
lüasters. 1993). En los proyectos pequeños, la carencia de la gestión de
ERROR CLÁSICO confisuración aumenta un poco el porcentaje del coste del proyecto. En
Capítulo 4: Bases del desanotto de software 75
proyectos, la gestión de la configuración es un elemento del ca-

-erandes
mino 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 dificiles de encontrar. La mayor parte de las fuentes
de información disponibles sobre alguno de estos temas probablemente
se encuentran en los libros, así que a continuación se enumeran los mejo-
res libros de cada uno de los temas.
Gestión de requerimientos
Yourdon, Edward: Modern Structured Analysis. New york: yourdon
Press, 1989. El libro de Yourdon contiene un estudio sobre la especifi-
cación de los requerimientos y el análisis hacia el año 1989, incluyendo
herramientas de modelización, proceso de recogida de requerimientos
y temas relacionados. Observe que una de las secciones más intere-
santes se encuentra oculta en un apéndice: <<Técnicas de entrevista y
recopilación de datos>.
Hatley, Derek J., y Imtiaz A. Pirbhai: Strategies for Reat-Time System
Specification New York: Dorset House Publishing, 1988. Hatley y
Pirbhai prestan especial atención a los sistemas en tiempo real, y ex-
tienden la notación gráfi.ca utllizada por Yourdon al entorno en tiem-
po real.
Gause, Donald C., y Gerald Weinberg: Exploring Requirements: euality
Before Design. New York: Dorset House, 1989. Gause y Weinberg
presentan 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ías
no son suficientes y otros temas. Ellos evitan principalmente los te-
mas que incluyen otros libros de requerimientos y tratan los temas
que otros libros evitan.
Diseño
Plauger, P. L: Programming on Purpose: Essays on Software Design.

Englewood Cliffs, N.J.: PTR Prentice Hall, 1993. Es una colección
reconfortante de ensayos que fueron originalmente publicados en la
revista computer Language. Plauger es un gran diseñador que se de-
dica a una gran variedad de temas relacionados tanto con ser diseña-
76 lesiAr;1/a; n Jf5;ÍN:,: ;p ffir!€5rc infurmátias
s¡r cr.mo con el diseño en abslracfo. Se exliende /ióremenfe por ti-,J'rr

e, rrnbito del diseño, y no se restringe exclusivamente a un estilo de
diseño; esto es lo que hace qu'e los ensayos sean tan reconfortantes.
Este resultado es único en su ámbito y provocador.
McConnell, Steve: Code Complete. Redmond, Wash.: Microsoft Press,
1993. E,ste libro contiene varias secciones que tratan sobre el diseño,
particularmente el diseño relativo a la construcción. Al igual que e1
libro de Plauger, describe varios estilos de diseño.
Yourdon, E,dward, y Larry L. Constanttne: Structured Design: Funda-
mentals of a Dísciplíne of Computer Program and Systems Design.
Englewood Cliffs, N.J.: Yourdon Press, 1979. Éste es un texto clásico
sobre 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, notaciones
gráficas y otros conceptos 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 Structured Systems Design,
2d Ed. Englewood Cliffs, N.J.: Yourdon Press, 1988. Es un libro de
texto muy conocido que presenta el mismo contenido sobre el diseño
estructurado que el libro de Yourdon y Constantine y se escribió con un
considerable entusiasmo. Algunas personas han encontrado el libro
de Page-Jones más accesible que el de Yourdon y Constantine.
Booch, Grady: Object Oriented Analysis and Design: With Applications,
2d Ed. Redwood City, Calif.: Benjamin/Cummings, 1994.Ellibro de
Booch 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ás
sobre el desarrollo de aplicaciones orientadas a objetos en C++. Na-
die ha hecho una defensa más activa sobre el diseño orientado a obje-
tos que Grady Booch, y es el volumen definitivo sobre el tema.
Coad, Peter, y Edward Yourdon: Object-Oriented Design Englewood
Cliffs, N.J.: Yourdon Press, 199 1. Ésta es una alternativa más ligera
al libro de Booch, y algunos lectores podrían encontrarla como una
introducción más sencilla sobre el diseño orientado a objetos.
Construcción
McConnell, Steve: Code Complete. Redmond, Wash.: Microsoft Press, 1993.
Éste es e1 único libro conocido que trata sobre todos los temas claves
en 1a construcción, identificados en ia 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.
Capítulo 4: Bases del desanofro de software 77
Marcotty, Michael: Software Implementation. New York: Prentice Hall , 1991.

Este libro trata sobre temas genérales involucrados en la construcción
del software, prestando especial atención a la abstracción, complejidad,
legibilidad y corrección. La primera parte del libro trata sobre la historia
de la programación, subcultura, equipos de programación y cómo re-
parten el tiempo de forma general. El libro está escrito con ingenio y
estilo, 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 la programación y explican claramente las razones por las que
hay personas que consideran la programación como 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 minutos y se utili-
zarán durante años.
Bentley, Ion: Programming Pearls. Reading, Mass.: Addison-Wesley,

1 986.
Bentley, Ion: More Programming Pearls: Confessions of a Coder. Rea-
ding, Mass.: Addison-Wesley, 1988.
Maguire, Steve: IVriting Solid Code. Redmond, Wash.: Microsoft Press,
1993. Este libro describe los métodos claves de construcción software
utilizados por Microsoft. Explica cómo minimizar los errores utili-
zando avisos (wnrnings) de compilación, protegiendo el código con
sentencias 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-
mació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.: Software Configuration Managemenl. Englewo-

od Cliffs, N.J.: Prentice Hall, 1980.
Babich, W .: Software Configuration Management. Reading, Mass.: Addi-
son-Wesley. 1986.
Bersoff, Edward H., y Alan M. Davis: <<Impact of Life Cycle Models
on Software Configuration Management>>, Communications of the
ACM 34, núm. 8 (August 1991):104-118. Este artículo describe cómo
la SCM está influenciada por las nuevas aproximaciones al desarrollo
del software, especialmente por el prototipado.
j
78 -l ei-p c ! gesi',}'r oe prryectos informáticos
4.3. Bases del control de calidad

A1 igual que las bases de -eestitin r- técnicas. las bases del control de ca-
lidal proporcionan un apo\-o fundamental para obtener la máxima veloci-
dad de désarrollo. Cuando un ploducto software tiene demasiados erro-
res, los desarrolladores emplean más tiempo corrigiendo el software que
escribiéndolo. Muchas organizaciones han descubierto que todo funciona
mejor si no se cometen los errores en el primer paso. La clave principal
para no cometer errores es prestar atención a las bases del control de cali-
dad desde el primer día.
Algunos proyectos intentan ahorrar tiempo reduciendo el tiempo
que emplean en los métodos de control de calidad, como en el diseño y en
lis revisiones del código. Otros proyectos (que van retrasados) intentan
recuperar el tiempo perdido reduciendo la planificación de la prueba,
1o cual es bastante sensible a la reducción porque normalmente es el
ERROR CLASICO elemento de1 camino crítico al final del proyecto. Éstas son algunas de
1as peores decisiones que una persona que desea maximizar la velocidad
de desarrolio puede tomar, polque al aumentar la calidad (desde el punto de
vista de menor tasa de defectos) se reduce el tiempo de desarrollo. La
Figura 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 defectos
incrementará 1a cantidad de tiempo de desarrollo. El tiempo extra es ne-
Planificación más
rápida ("msje¡"
planificación)
= 95o/" 1
Porcenta¡e de defectos suprimidos

Fuente: Datos extraídosde Appl¡ed Software Measurement (Jones, 1991)
Figura 4.3. Retación entre la tasa de defectos y el tiempo de desarrollo

En Ia mayoría de los casos, los proyectos que se llevan a cabo con una
tasa de defectos más baia también tienen una planificación menor.
Capítulo 4: Bases del desarrotlo cie software 79
cesario cuando se aplica a sistemas críticos para la vida. ta1 como los
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 que la calidad y la planifi-
cación del software estaban relacionadas. También descubrieron que los
productos con menor número de defectos eran 1os que tenían una menor
planificación (Jones, 1991).
En la actualidad, muchas organizaciones han desarrollado software
con un nivel de defectos que 1e asigna una planificación mayor de la necesa-
ria. Después de realizar un estudio de más de 4.000 proyectos software,
=EALES
Capers Jones informa que una calidad baja es una de las principales razo-
nes del retraso en la planificación (Jones, 1994). También dice que labaja
calidad es una de las razones por las que se cancelan más de la mitad de
los proyectos. Un estudio del Software Engineering Institute descubrió
que un 60 por 100 de las organizaciones tenían un control de calidad ina-
decuado (Kitson y Masters, 1993). En la curva de la Figura 4.3, estas
organizaciones son las que están al lado izquierdo de la línea que indica
el 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 donde
los proyectos generalmente alcanzan la planificación más baja, el menor
]ATOS REALES
esfuerzo y el nivel más alto de satisfacción del usuario (Jones, 1991).
Si después de lanzar el producto se tienen más de un 5 por 100 de defec-
tos, será vulnerable a los problemas asociados a una calidad baja, y
probablemente se tardará más tiempo del necesario en desarrollar el
software.
Los proyectos que se reahzan 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ó1o laltan 30 días para la
entrega>. En vez de escribir un módu1o de impresión completamente
cLAStCO distinto, se hace a partir de1 módulo de visualización en pantalla. Se
==;oR
sabe que el diseño es maio, que no es ampliable o de mantenimiento
fácil, pero no hay tiempo para hacerlo bien. Se tienen prisas por terminar
el producto, de forma que uno se siente obligado a tomar el camino
más corto.
Tres meses más tarde, el producto aún no se ha terminado, y empie-
zan a aparecer los problemas derivados de esos recortes. Se encuentra
con que los usuarios no están contentos con la forma de imprimir, y que
1a única manera de satisfacer sus requerimientos es aumentando significa-
tivamente la funcionalidad del módulo de impresión. Desafortunadamen-
te, desde hace tres meses el módulo de impresión y el de visualización
en pantalla se han ido entrelazando. Rediseñar el módulo de impresión y
separarlo del de visualización es una operación difícil, que consume tiempo
y es susceptible a errores.
Eü _-E_r-<:-:r _-
--:-.: :- :t :'.,'ectos informáticos
Ei resultado es que en un pro) ÉctLr que se sü-¡L1n1a que prestaba espe-

;rai atención al desarrollo de una planrl-rcacitin io más corta posible, se
pierde el tiempo en las actividades siguientes:
o 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 em-
pleó en la prueba v la depuración del módulo de impresión también
se desperdició.
¡ El tiempo adicional que se debe emplear en separar el módulo de
impresión módulo de visualización por pantalla.
de1
o Se debe emplear tiempo de prueba 1,' depuración adicional en ase-
gurar que el código de visualización que se ha modificado sigue
funcionando después de separarlo dei módulo de impresión.
o El nuevo módulo de impresión, que debería haberse diseñado como
una parte integral del sistema, se ha diseñado fuera del sistema exis-
tente, no siendo ésta la forma de diseño que se tenía pensada.
Todo esto sucede, cuando el único coste necesario (si se hubieran

tomado las decisiones apropiadas en el momento correcto) era el diseño e
ffi
implementación del módulo de impresión.
E,ste ejemplo es bastante común. El número de defectos que se presentan
cuando los programadores lanzan productos bajo una excesiva presión en
la planificación es hasta cuatro veces mayor (Jones, 1994). En los proyectos
DATOS REALES
que tienen problemas de planificación, se suelen obsesionar por trabajar
más duro, en vez de trabajar de forma más ingeniosa. Prestar atención a la
caiidad es como si fuera un lujo. El resultado es que los proyectos suelen
funcionar mal, dando lugar incluso a problemas graves de planificación.
Decidir al inicio del proyecto no centrarse en la detección de errores
equivale a la decisión de posponer la detección de defectos hasta más
tarde, 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, se
obtiene una ventaja significativa en la planificación. Los estudios han
demostrado que revisar errores de requerimientos, diseño y código nor-
DATOS .qEALES
malmente consume del 40 al 50 por 100 del coste total del desarrollo del
softrvare (Jones, 1986b; Boehm, 1987a). Como regla empírica, cada hora
que 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-
biema de requerimientos software, una vez que el programa está eje-
cutándose. normalmente cuesta de 50 a 200 veces más de 1o que costaría
rer-isar e1 problema cuando está en la fase de requerimientos (Boehm y
Papaccio. 1988). Dado que más de1 60 por 100 de los errores se dan en
tiempo de diseño (Gilb. 1988), se pueden ahorrar grandes cantidades
de tiempo detectando los errores antes de hacer la prueba del sistema.
Capítulo 4: Bases del desanollo de software 81
Módulos propensos a errores

Un aspecto particularmente importante sobre el control de calidad, en
cuanto 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 un
DATOS REALES
nírmero desproporcionado de defectos. Por ejemplo, en su proyecto IMS,
IBM descubrió que el 75 por 100 de los errores se agrupaban en el
7 por 100 de los módulos (Jones, 1991). Barry Boehm informa que sobre
el 20 por 100 de los módulos en un programa son normalmente responsa-
bles del 80 por 100 de los errores (Boehm, 1987b).
@
DATOS REALES
Los módu1os con tasas de defectos elevadas son más costosos y
consumen más tiempo para ejecutarlos que los módulos menos propensos
a effores. El desarrollo de módulos normales cuesta de 500 a 1.000 dólares
por punto de función. Los módulos propensos a errores cuestan de 2.000
a 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 1a velocidad de desarrollo es importante, identificar y rediseñar los
módulos propensos a errores es prioritario. Si la tasa de errores de un
módulo alcanza los 10 defectos por cada 100 líneas de código, habrá que
revisarlo para determinar si debería volverse a diseñar o implementar. Si
el módulo está mal estructurado, es excesivamente complejo o largo, ha-
82
-i 4 -J: rr
. - -i -- : --:----.- ¡;:":¿ ¿- ir:i"-io. Se ahorará tiempo
¡ ir *r:" -;- :ú: -l;- :l:r:,;:,:,-
P'nreba
EI métrrrlo más común de control de calidad es indudablemente la prueba de
ejecución: encontrar effores al ejecutar el programa y ver lo que hace. Las
dos clases más comunes de pruebas de ejecución son las pruebas individua-
les, en las cuales el desarrollador comprueba su propio código para verificar
que funciona correctamente, y las pruebas del sistema, en las que un pro-
bador independiente comprueba si el sistema funciona como se esperaba.
La efi.cacia de las pruebas varía enormemente. La prueba individual
puede encontrar del 10 al 50 por 100 de los defectos en un programa, y
DATOS REALES
la prueba 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, 1 986a). Los errores que no se localizan se pueden encontrar por otras
té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 1a oveja negra en lo que respecta a los métodos de control
de calidad, y en 1o que respecta a la velocidad de desarrollo. Realmente
se puede hacer tan mal como para retrasar la planificación de desarro-
llo, 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 e1
producto tiene que retrasarse hasta que se pueda mejorar. De esta manera.
la prueba se convierte en el mensajero que comunica las malas noticias
que afectan a la planificación.
La mejor forma de fomentar la prueba, desde el punto de vista del
desarrollo 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écnicas
Las revisiones técnicas incluyen toda clase de revisiones que se utilizan
para detectar defectos en requerimientos, diseño, código, casos de prueba
o cualquier otro artefacto del proyecto. Las revisiones varían en cuanto a1
nivel 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 los
tipos de revisiones más comunes.
Reuniones
Las reuniones informales son el tipo más común de revisión. El término
DATOS REALES <reunión> se define aproximadamente y se refiere a cualquier reunión en
Capítuto 4: Bases del desarrctio de software 83
el obietivo
revisen el trabajo técnico con
la que dos o más desarrolladores rápido'
son útiles para el desarrollo
;;;;;;;t";es
de mejorar su calidad' antes de la prueba Por
eriores
porque se pueden utilizar para detectar
detectar un defecto en los
pueda
eiemplo. en el caso d;;";l;prueba
de que éstos se hayan especificado'
requerimientos. lo h;;i;;t;"is
puede detectar un defecto en los
diseñado y codificadi'-U"""*""fón antes de que se el
requerimientos, en tt;p"o';t "sp""ificutión'encontrar entre el 30
^realice
y el 70
p"ed"n
diseño o se codiflqut' f-i"t"tione' 19'79: Boehm' 1987b; Your-
por 100 de los errore' * ulp'og'u-ulMyt" '
don,1989b)'
Lectura del código

que una
proceso..de revisión más formal
La lectura del código es un lectura del có-
se aplica al código' En la
reunión, p"rono'*uii#" 'oio dos o
listados del cédigo fuente entre
digo, el autor del -i';';i;ibuye e informan de cualquier error
DATOS REALES
más revisore*. l-o' t"uilo';; i.",' el código
de lngeniería de1 Soft-
al autor del código. il;ñd. en el Laboratorio
dos veces
que la lectura del código detectaba
ware de la NASA ¿t'cl'U'iO q.r" lu prueba (card, 1987)'
esfuerzo
más cantida¿ o. ¿"r"."tl, pár'rr"r"¿. la combinación de
Esto sugiere qut t" t"t pr'fecto de desarrollo tapiaó' que
;;ra más efectivapara la planificación
lectura del código t;;;;
solamente la Prueba'
lnspecciones
Lasinspeccionessonuntipoderevisióntécnicaformal'quehademos- un proyec-
en la detección de errores en
trado ser extremadamt"t" "i"ttluo reciben una preparación
to. Con las inspecciá"Lt, l"l ¿tsarrolladores las mismas' El <mode-
y juegan ;;;;ti-;tl.ecífico dllante
especial antes de la
el producto para inspeccionarlo
rador> se vuelca en trabajar en el producto antes de
reunión de inspecció"' io' u"ui'o'""
examinan
REFERENCIA
para estimular su revisión' Durante la
CRUZADA la reunión y utilizan listas de control ins-
)z',,ver un resumen nármalmente comenta elm¿terial
le los beneficios reunión de inspecció;l;;;;t; guarda
los errores y el <secre'tario>
derivados de las peccionado, lo, t"ui'it' identifican sobre
el moderador genera un informe
los errores. Después i"l" tá""iOt'
-sDecciones en la
: a-'cación consulte 1o que se
t"¿" de los defectos e indicando
el CaPítulo 23. 1a inspecciór., ¿","'iiil"á" ""o de inspección' se recogen datos
hará con ellos. A 1"'i;;;; á"i *"t":".
..!-sPecciones"
sobredef.ectos,seempleanhorascorrlgrendoestosdefectos'ySeemplean
que se pueda analizat la efectividad
horas en las inspecciones, de forma
y meiorarlo'
á.r fro..ro de áesarrollo del software se pueden utilizar para
\l igual que en tus las inspectiontt
"uniones' para de-
la prueba' Se pueden
detectar delectos
"";;;;'**o'con "]\t:it
prototipos de interfaz de usuarios'
diseño'
iectar errores .n
'eqt'erimientos'
;c,jrgo )"otros artefactos del pro.vecl... Lr: -::::::,-::: -:-;-au::::_ ;a -:
60 a un 90 por 100 de defectos en un pra,:::::_.- ,_ :-.. :. JJiisrJ-::r,:-
mente mejor que las reuniones o las ¡irueba=. -== ....:=-:tLrles qa:-::--
una planificación neta, ahorrando de un 10 a un -1t-r ;".: - , ¡. \ a que s- :---
den utilizar en el ciclo de desarrollo (Gilb y Graham. r yy-1 En un e s:-;, :
realizado sobre un programa grande, se encontró que cada hLrra emple :J:
en las inspecciones producía una media de 33 horas de ahorro. r' las ::,.-
pecciones eran 20 veces más eficientes que las pruebas (Russeli. 199,
Comentarios sobre las revisiones técnicas

Las revisiones técnicas son un complemento útil e importante para la pru;-
ba. Las revisiones tienden a encontrar errores de tipos diferentes a .:-.
pruebas (Myers, 1978; Basili, Selby y Hutchens, 1986). Encuentr.:
defectos más pronto, 1o cual es bueno para la planificación. Las rer isr,:,-
nes tienen un coste más efectivo en la búsqueda de defectos, ya que detect¿:-
al mismo tiempo tanto el síntoma como la causa fundamental de1 dei-ecrc,
La prueba sólo detecta el síntoma del defecto; el desarrollador aún tien¡
que encontrar la causa en ia depuración. Las revisiones tienden a encor,-
trar un porcentaje alto de defectos. Y las revisiones proporcionan ul
I
foro para que los desarrolladores muestren sus conocimientos sobre 1os
métodos recomendables, aumentando las posibilidades de desarollo ra-
pido. Las revisiones técnicas son un componente crítico de cualquie:
i esfuerzo de desarrollo que esté intentando alcanzar 1a planificación más
corta posible.
r#Lrl
EWtr
@ffi
Figura 4.4. ¡No permita que le suceda esto! Cuanto más tiempo permanezca
oculto un defecto, más tiempo necesitará para corregirlo. corrija los defectos
cuando están en un estado inicial y son fáciles de controlar.
Capítulo 4: Bases del desarrollo de software 85
Bibliografía adicional sobre los fundamentos

del control de calidad
Muchos 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 to
Software Engineering (Pressman, 1993), Software Engineering: A Prqc-
tiiioner's Approach (Pressman, 1992), Sofnrare Engineering (Sommer-
ville, 1996) , y Code Complete (McConnell, 1993)' A continuación se
muestran las fuentes adicionales de información sobre temas específicos'
Calidad del software en general

Glass, Robert L.: Building Quatity software. Englewood cliffs, N.J.: Pren-
tice Hall, 1992. Este libro examina consideraciones sobre la calidad
durante 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 métodos y muestra numerosas des-
cripciones de otros libros y artículos sobre calidad del software.
Chow, Tsun S., ed; Tutorial: Software Quality Assurance: A Practical
Approach. Silver Spring, Md.: IEEE Computer Society Press, 1985'
E,ste libro es una colección de unos 45 artículos que tratan del tema de
la calidad de1 software. Las secciones incluyen definiciones sobre la
calidad del software, medidas y aplicaciones; directivas de planifi-
cación, organización, estándares y convenios; cuestiones técnicas
sobre requerimientos, diseño, programació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, y su gfan
tamaño 1o hace especialmente valioso'
Prueba
Myers, Glenford J.: The art of software 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 1os mejores textos disponibles. Los contenidos son
ólutor' 1a psicología y rentabilidad sobre la prueba del programa; diseño
de casos de prueba; prueba de módulos; prueba de orden superior;
depuración; herramientas de prueba; y otras técnicas. El libro es corto
pre-
Q17 páginas) y entretenido. La encuesta que incluye al principio
tende hacerle pensar como un probador y demuestra exactamente las
formas en las que el código puede tener defectos.
Hetzel, Blll: The complete Guide to software Testíng, 2d Ed. wellesley,
Mass.: QED Information Systems, 1988. El libro de Hetzel es una buena
alternativa al libro de Myers, ya que trata sobre el mismo tema, pero
/
l*s=-;' s y Eestio.n de oroyectos informáticos
de forma más moderna' Además

je tr;::: -¡' ::''tr'¡' ;-;e \fyers' Hetzel
también trata sobre la prueba de rec';ennleriuls
\ üi:eio' prueba de
s de gestión' Con 284
regresión, compra de sáftwa'", y consl'JeraciL'rne
muestra una gran
pá"girlar, también es relativamente corto' y el autor
potentes'
iutidad, presentando conceptos técnicos bastante
Revisiones e insPecciones
y Dorothy Graham:
Gilb, Tom,'Áddison-Wesiel'. So-fntare Inspecfion' **i1911*'U*
gtunO' 1993' Este libro hace un tratamlento muy
minuciososobretas-inspecciones'Tieneunenfoqueprácticoeinclu-
establecido progra-
ye ejemplos de muchas organizaciones que han
mas de insPección.
t., y Gerald M' Weinberg: Handbook of Walkthroughs'
Freedman, Daniel
New York: Dorset Hou-
Inspections and Technical Reviews' 3d Ed'
a revisiones de toda clase'
se, 1990. Es un libro excelente en cuanto
es el promotor original
incluyendo ,"nnio,t., e inspecciones' Weinberg
de la <programación anóni'oa', la base de
la mayoría de las revisio-
nes prácticar. g, á,to'-emente práctico. e
incluye much11--listas de
en varlas com-
contiol útiles, informes sobre el éxito de las revisiones
de pre-
pañías, y anécdotas entretenidas' Se presenta con un formato
guntas Y respuestas.
Losdosartículossiguientesestánescritosporeldesarrolladordeins-
una inspección, incluyendo
pecciones. contienen 1úecesario para ejecutar
ios formularios de inspección estándares'
to Reduce Errors in
Fargan, Michael E: <Design and Code Inspections
Journql' vol' 15' nitm' 3' 79-/6'
Program Developmenti, Bn't Systems
pp.1B2-211.
IEEE Transac-
furiun, Michael E: <Advances in Software Inspections>>'
iiow o, Software Engineeting, July 1986' pp' 144-151'
4.4. Seguir las instrucciones

insistió en que cual-
Cuando estaba en séptimo grado, mi profesor de arte
una B'
qrt.. .t*¿i"nte que siguieia sus instrucciones obtendría al menoskilos' y
marino de i20
sin necesidad de tenerialento artístico' Era un ex
que daba este aviso a1 menos rLnavez por semana' yo
teniendo en cuenta
curso, de 60 kilos, no si-
estaba asombrado de cuántos alumnos del séptimo
B' A juzgar por
grri.rorl sus instrucciones y no consiguietonalcanzar una
gloria' ni tampoco eran
Iu trabajo. no estaban atormentados por alcanzar la
que hacían algo diferente'
contrarios a su visión artística. Ellos sentían
Capítuto 4: Bases del desarra,,'c de software
Como adulto, suelo ver que los proyectos software fallan stmplemente
porque los programadores y directivos que trabajan en e11os no siguen 1as
instrucciones, las bases del desarrollo de software descritas en este capíru1o.
Es cierto que se puede desarrollar software sin dominar los fundamentos.
a veces incluso rápidamente. Pero a juzgar por los resultados de la mayo-
ría de 1as personas, si 1os fundamentos no prevalecen al principio' no se
tendrá el control necesario sobre el proyecto para desarrollarlo rápida-
mente. Incluso 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. Deipués de que la superficie esté completamente seca (al menos
6 hóras), aplique una capa fina. La temperatura ambiente debe
estar entre 15 y 30 grados centígrados. Déjela secar durante dos
horas.
4. Aplique una segunda capa fina y déjela durante 24horas antes de
utilizarla.
Si va a pintar la
¿Qué sucedería si no se siguieran las instrucciones?
del perro un martes por la noche, después del trabajo, sólo tendría
"ur.1u
dos horas para pintarla, y Fido necesita dormir esa noche. No hay tiempo
para seguii las instrucciones. Podría decidir saltar directamente al paso 3,
y aplicar en el paso 4 una capa gruesa de pintura enYez de una fina. Si el
ii.-po 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 superficies
de metal de los clavos al no estar preparadas adecuadamente, y habría que
voiverla a pintar otfaYez el próximo año, pero realmente no tendría dema-
siada importancia.
¿Qué sucedería si en vez de la caseta del
perro se estuviera pintando
un Boeing 74'72 En este caso, sería conveniente seguir 1as instrucciones
de 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 enunT4J
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.
una caseta de un
¿Qué sucedería si se pintara algo que estuviera entre
perro y un747, por ejemplo una casa? En este caso, 1as consecuencias de
l
88 l*sa--r/ir: r ;¡:snr:r/- ;¡r Jr-J*q¡íEs rrrgn*anul:*
T{i:nr;:lr ÍT.i.üL:-nrü-ü,: *ff,r!n.TTHTtj\* i"j,:r-!i{ Ji:¡:¿

Jlm
ini47,ymásque
lniüfrll! ü!¡!nDü irunsitü lrd üm -ae:-l rq: id.¡.3:¡¡-flr:s, -.ü.-r.e¡ apintar la casa en dos
.&úuilrt Ír*\nffifp'rr[ri$ ]Lrr.c-
" mgn;[-a,{ :=;¿*=ur--x que con la caseta del perro.
I ¡k rr.!i :[Í'T'ü&JFL]S lcn*ng¡-e que tienen problemas de plani_
Ínüu'hiür-iiiü
frLn*r6¡6 i¡fi[r :mr]r'rryat* ¡qr- Tr-r'iü' rle la casa o mayores, y
son estos pro-
rHmrs ]i:nF ülla r:runt--a3ri r¡tfresan en este
libro. En tales proyectos,
;eb :ltb'cs e ¡s-c|E::ia ¿htrrr¿n tiempo. Si se tiene
suficiente aorro.i*iarr-
:! i-:cq: :- ¡-:e.::"i seria un proceso mucho menos rígido que los pasos
¿e i¿ i¿¡a
'je prnnrra, proporcionando toda la flexibilidad necesaria. Se
pueden 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
un
listado de libros de ingeniería del software. El motivo de leeiun
libro de
conocimientos generales sobre ingeniería der software no es
adquirir un co-
nocimiento profundo sobre un tema específico, sino u., u grund"s
rasgos
el desarrollo del software, dentro del cbntexto. Los siguienles libros
des-
criben una visión de los métodos que este capítulo déscribe como
bases
del desarrollo del software.
Sommerville,Ian: Softwarev L,.61'Lccr

Engineering, Ed. ÁsaLullg,
6th ¿4.
Lr.ó, vLtt Reading, 1uass.: Addi
Mass.: Aodl_
son-wesley, 1996.En la sexta edición de este libro se tratan de
forma
equilibrada los requerimientos, diseño, validación de la caridad
y ges-
tión. contiene diagramas útires y cad.a tema tiene una sección
so-
bre bibliografía adicional. con 700 páginas, no es necesariamente
un libro que se tenga que reer de principio a fin, pero si
se desea una
breve descripción sobre un tema en paiticular, piobablemente
se en-
cuentre en este libro. Tiene un buen índice.
Pressman, Roger S.: Software Engineering: A practitioner,s
Approach,
3d Ed. New York: McGraw-Hir, 19gt. Es una excelente
altárnativa
al libro de Sommerviile y es simirar en contenido y tamaño.
No se
confunda con el tífuro A practitioner's Approach (<ún
enfoque prác-
tico>); aun siendo excelente, este ribro es más adecuado
como un ribro
para proporcionar una visión sobre temas importantes que
para ser
usado como libro profesional.
Gestión de riesgos
Contenido
Elementos de la gestión de riesgos :
I
Identificación de riesgos
Análisis de riesgos
Priorización de riesgos
Control de riesgos
Riesgo, alto riesgo y azar
Temas relacionados
Estrategia de desarrollo rápido: Capítulo 2
Errores típicos: Capítulo 3
Bases del desarrollo de software: Capítulo 4
Resumen del filtrado de requisitos: Capítulo 32
Resumen de los diez riesgos más frecuentes: Capífulo 41
sI QUIERE APosrAR sEGURo, vAyA A LAS VEGAS y juegue a las

máquinas tragaperras. Los casinos han carculado minuciosaménte"las pro-
babilidades y han determinado que pueden obtener beneficios incluso
guando las máquinas paguen hasta er 97 por 100 del dinero de la recau-
dación. Las probabilidades se refieren a que si un díajuega 1.000 dólares
en monedas en las máquinas tragaperras, podrá obtener hasta 9i0
dóla-
res' Si no le gustan las máquinas tragaperras, puede jugar al blackjack y
contar las cartas para poder aprovecharse de las prouáuiiloaaes. (¡pero no
se equivoque al contar!)
si Las vegas le resulta muy aburrida, el software puede ser su juego
apropiado' Los proyectos de software incluyen un conjúnto amplio de ries-
gos que pueden causar pesadillas a los apostadores de Las vegas (cambio
de los requisitos del usuario, mala estimación de ra planifiJacii.r, per-
;BtrlrÍr JilF .rrm$grcs rL-e:¡::s
riimlfu r:rúr:r-.jo poco t-lable, falta de experiencia en la gestión, problemas

ie lflsicJ.r. problemas con la tecnología, cambio de las leyes del gobier-
3: 1 -'trbnemas con el desarrollo, por nombrar sólo unos de eilos). La
:r¡ ¿trilidad de que un proyecto complejo finalice en el tiempo estimado
:rende a cero. Las probabilidades de que un proyecto complejo se cancele
se aproximan a las de acertar a\ lanzar una moneda al aire (Jones, 199 1t.
En 1988, Peat Marwick encontró que sobre el 35 por 100 de 600 empre-
sas encuestadas han tenido al menos un proyecto que se les ha ido de 1as
manos (Rothfeder, 1988). Los daños producidos por proyectos descon-
:A-OS REALES
trolados hacen parecer a los combates de Las Vegas tan tranquilos como
tomar una tazade té con la Reina. Allstate comenzó aautomatizar en 1981
sus actividades administrativas. Planificaron una tempori zacíónpara cincc
años y un presupuesto de 8 millones. Seis años más tarde y 15 millones
después, Allstate estableció una nueva fecha límite y estimó un nuevo
presupuesto de 100 millones de dólares. En 1988, la Westpac Banking
Corporation decidió redefinir sus sistemas de información. Planificaron
un proyecto de 85 millones de dólares para cinco años. Tres años más
tarde, después de gastar 150 millones con poco éxito, asumió sus pérdi-
das, canceló el proyecto y eliminó 500 empleos de desarrollo (Glass, 19921.
Incluso los combates de Las Vegas no son tan crueles.
Hay una serie de métodos de gestión de riesgos que pueden prevenir
desastres como éstos, y que le harán aprender mucho de ellos antes de 1o
que aprendería a contar las cartas en el blackjack. De acuerdo que ha1'
personas que juegan 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 no
controla los riesgos, no podrá crear desarrollos rápidos. Como dice Tom
Gilb, <si no controlas los riesgos, ellos te controlarán a ti>.
El control de riesgos tiene una serie de problemas. Los proyectos que
llevan un control de riesgos efectivo son menos excitantes que los pro-
yectos que no 1o hacen. Perderá el miedo que supone tener que decirle a
suiefe 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 de
nosotros, éstos son problemas con 1os que se puede vivir.
El control de riesgos en software es un tema relativamente nuevo, pero
)'a existe información suficiente como para estudiarlo con profundidad en
este capítulo. El estudio de este capítulo se centra en los riesgos en la
planificación e ignora los riesgos sobre costes y producción, salvo cuan-
do afecten 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-
rrol de riesgos es interesante e importante, pero es menos útil, por lo que
la hemos evitado, mostrando en la sección de bibliografía adicional al
final del capítulo dónde puede encontrar más información.
Capítulo S: Gesttó,. de rresgos 91
Ejemplo 5.1. Falta de gestión de riesgos al contratar
<He recibido el visto bueno para realizar square'plan 2.5x, le dijo Kim
a
Eddie. Kim y Eddie eran respoisables de proyectos de Square-iech, una
Qmpre sa de softr.r'are <prét-á-porteo. <Tengo cuatro freses para
entregar 1a
actualización, y creo que va a ser un bombazo.> Kim entregó su úItimo
proyecto, square-calc 3.0. con mucho ret¡aso. Eddie ha realiiadobien
su
prinrerproyecto, square-P1an2.ü, v Kim está ansiosa por demostrar que
la
dilerencia se ha debido a qLre sLr proclucto era mucbo más complejo que er
de Eddie.
' <Yo de ti estaria rnás preocupado>. ie dilo Eddie a e1la. <He
la especificación de la 2.5. y pienso que con e1 equipo actuai re 'isto que-
dan más de seis meses de trabal'0. ¿Has pensado en utilizar el equipo
de la 2.0?r
<<sí, clars. Y también he pensado en ajurtar el pran de tralrajo a cuatro
meses. La semana pasada ieí un artículo sobre desarrollo externo, y he en-
cofltrado a alguien que se puede encargar de las aciualizaciones de los grá-
ficos;1o que reduciría el plan en dos m€ses.)l
' (Bueno, espero que sepas lo que estás haciendo>, le dijo Eddie. <He
visto a mucha gente fracasarporculpa ds1 pe¡sonal eontrátaáo.
¿cuál es tu
plan para el control de riesgos?>
<<He contratado á rrna persoía de prestigio>r, dijo Kim. <He
comproba_
dé sus referencias y estoy segura de que hará un buen trabajo. Le echáré
un
ojo de vez en cuando. Esto es un negocio arriesgado, y algúnor riesgos
son
inevitables. cuando tengo tanto trabajo por hacer, no piinsdperder rnñi.*po
en trabajos inútiles.)) ,
Fddie pensó que ella debería tener más cuidádo, pero Eddie y Kim
ya pasaron pm esto antes. Él había aprendido a no discutir cuando
ella va
había decidido 1o que iba a hacer. <<Buena suerie,), le dijo Eddie
' Kim se reunió pronto con Ia persona contratada y ie dio una especifi-
cación para las actualizaciones de Ios gráficos. chip. la persona.on,ru,u-
da, le dijo que las especificaciones le parecian claras y que se pondria
a
trabajar enseguida.
seis semanas más tarde, Kim tlamó a chip para coqrprobar er estado
del Jrabaio. <Todo va Lrien>, dijo él- <He estado trabajandi en un proyecto
muy irnporlante de otra empresa, por lo que todavía no he.podido
avanzar
rriucho. Pero todavia tensmos tres meses y medio pura ,"uiir", ún
trab4jo
de dos lneses. así que no [e preocupes.>
<<Eso suena bien>. le <iüo Kim. <Avísame si necesitas
argo. Te vorveré
a llamar clentro de seis semanas para tratar 1a integración.u -
,
sgis semanas más tarde, Kim volvió a rlamar para comprobar la evo-
lución del trabajo. <El último proyecto me llevé más tiemio del que
es_
peraba>, te dijo Chip. r<He eome¡zado la,actualizaciénrde
los grádcor. ¡-
he estado trabajando eomo un loco, pero necesito analizarloJmás pro-
fundamente, pienso que tendré que dedicarle otros ffes meses.>i
lcontinuctJ
E2 :. :'Jt'ectos informáticc s
f;a cabi'.¡¡Élá*ipga, Esto haría que el tiempo de desarrollo toral f€ffi

s*s,n¡gs¡p.,e.a.;lügá¡,dF cuatrc' <¿Tres meses? ¿L{e estás to¡sando el ps¡s*
Neee$,itü,;9ry9¡lódi$orgf d.q¡::*¿xx¡$€ p¿ra eÍtyezar con la ;ntegraci& Sc
supone que ya lo tenías que tener hecho...>
<Lo siento>¡. dijo Chip. ,<Pero no es culpa mia. Esto tiene más trabqls
,,:.:ide. T,o terminaré tan pioit'lg¡,''ó,tno.',g¡e-darr
'qi;e,hgbiá.é.sqmii{o
,.,,,,:',.,:,,,,chÍp:deiá:fblt¿ tt softwaré en tres meses, peiti!.1'pigyecto se rettasé oEt{
mes máspor losproblemas de integración con el código del equipo propia
Át rl"át el üempo tom ¿$.it+s.ápqoll tfué¡órt:.sicte¡mós}s¡n lugar de 1 *
aua¡rp m€ sqq. p:evi qt-os:rKiiiiáE:á66, oeasánds, querf.,+d1e,1é.Iiábia hecho cs-
gar a ella con un ptoyecto 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, estuü-'-
eliminar las fuentes de riesgo antes de que empiecen a amenazar la :::-. -
zación satisfactoria de un proyecto software. Puede controlar los ri;s;: -
a varios niveles. La Tabla 5.1 describe algunos de los niveles de le -=.-
tión de riesgos.
El objetivo de este capítulo es describir cómo estudiar los rie:g.-' :'
la planificación software en los niveles 4y 5,en lugar de en los n:'=;'
del i al 3. Si está controlando riesgos al nivel 7,2 o 3, ya ha perdicr ''
batalla de la planificación.
-
Generalmente, la gestión de riesgos se divide en valoración de ne s = -
y control de riesgos. Además, se compone de varias subcategorías' cc'::
se muestra en la Figura 5.1. Esto se explica en los siguientes epígrales.
Tabta 5.1 . Niveles de gestión de riesgos
1. Control de crísis. Apagar e1 fuego; controlar los riesgos sólo cuando se
han convertido en problemas.

Arreglar cacJa error. Detectar y reaccionar rápidamente ante cualquier
riesgo. pero sólo después de que se haya producido.
Jlitigacíón de ríesgos. Planificar con antelación el tiempo que necesitan"
para cubrir riesgos en e1 caso de que ocurran, pero no intentar eiiminarlt's
inicialmente.
Pret'encién. Crear y llevar a cabo un plan como parte del proyecto
soft$.are para identificar riesgos y evitar que se conviertan en problema.
5. Eli¡nínación de las causas principales. Identificar y eliminar los factor¡s
que puedan hacer posible la presencia de algún tipo de riesgo.
Fuente: Adaptado de I Mctnager's GtLide to software Engineering (Pressman, 1993

Capítulo 5: Gesún & riesgos
Figura 5.1. La gestión de riesgos se compone de estimación y contror de

riesgos. Fuente: Software Risk Managemenl (Boehm, lggg).
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 identtfi.cación de riesgos genera una lista de riesgos capaces de

romper la planificación del proyecto.
o El enalisis de ríesgos mide la probabilidad y el impacto de cada
riesgo, 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 rista sirve como base para
el
control de riesgos.
Control de riesgos
El control de riesgos se compone de planificación de ra gestión de ries-
gos, resolución de riesgos y monitorización de riesgos:
' La planificación de la gestión de riesgos genera un plan parutratar

cada riesgo significativo. También asegura que los pranes para ra
gestión de riesgos de cada uno de ros riesgosindividuales son
con-
sistentes entre sí y con el plan del proyecto.
o La resolución de riesgos es la ejecución del pran para resolver cada
uno de los riesgos significativos.
o La monitorización de riesgos es la actividad del progreso de ra
monitorización dirigido a la resolución de cada elemen-to del ries_
go. La monitorización de riesgos también puede incruir la
conti-
nuación de la actividad de la identificación de nuevos riesgos y
volver a considerarlos en el proceso de la gestión de riesgos.
JT mr¡ilm ü @rr !üF@@ tfurmáticos
lrm p'ndos de la siguiente sección explican cada uno-de.estos as-

Fffi dh gestión de riesgos en su aplicación a la gestión de riesgos en
h phni-ficación software.
S - reffiiñcación de riesgos
g ¡¡; pi"le El primer paso en la gestión de riesgos es la identificación de los factores
generales
¡wd¡rro¡:'-:¡¡r soár¿ q,rá irrt.od,,.en un riésgo en la planificación. Hay tres riesgos
.:¿SSAS- eStó
huscando
* un proy"cto de desarrollo rápido, que son olvidar los tres elpilares desa-
problemas. ¿et ¿esanóllo rápido, descritos en el Capítulo 2, <<Estrategiapata
Tom Gilb rrollo rápido>:
Cometer uno de los errores típicos descritos en el Capítulo 3,

<Erro-
res clásicos>>.
Ignorar las bases del desarrollo descritas en el Capítulo 4, <Bases
del desarrollo de software>.
Fallar en la gestión activa de riesgos descrita en este capítulo'
IJnavezque haya superado estos riesgos generales, habrá encontrado

casi todos tos tipos de riesgos de los proyectos software' Sin embargo'
formas
hay una serie de errores que aparecen una y otra vez,y una de las
más fáciles de identificai los riesgos es comprobar su proyecto frente a
proporciona
una lista de riesgos de la planificación. El apartado siguiente
una lista exhaustiva de los posibles riesgos en la planificación.
Riesgos más comunes en planificación

La Tabla 5.2 contiene una lista de los riesgos más comunes en la planifi-
cación.
Si los riesgos de esta tabla le son familiares, se debe a que cada uno
de ellos ya se comentó en los errores clásicos del Capítulo 3. La única
diferencia entre un error clásico y un riesgo es que los errores clásicos se
cometen con mayor frecuencia. Los riesgos Son menos comunes o pueden
ser únicos en su pfoyecto. Cada uno de los riesgos de la Tabla 5.2 se
describe con más detalle en |a Sección 3.3, <Relación de errores clási-
cos), y la forma de controlarlos se estudia posteriormente en este capítu-
1o, en la Tabla 5.6.
Lista completa de riesgos de planificación

La Tabla 5.3 contiene una lista exhaustiva de los riesgos que pueden afectar
a la planificación de un proyecto software. Só1o algunos de e1los apare-
cerán en la mayoría de los proyectos. Los riesgos se han organizado en
Capítulo 5: Gestión de riesgos
Tabla 5.2. Riesgos más habituales en planificación
1. Cambio de requisitos.
2. Meticulosidad en requerimientos o desarrolladores.
3. Escatimar en la calidad.
4. Planificaciones demasiado optimistas.
5. Diseño inadecuado.
6. Síndrome de la panacea.
7. Desarrollo orientado a la investigación.
8. Personal mediocre.
9. Emor en la contratación.
10. Diferencias entre el personal de desarrollo y los clientes.
Fuentes: Adaptado de Software Risk Managemenl (Boehm, 1989) y Assessment and Con-
trol of Software Rls/rs (Jones, 1994).
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 proyectos
tienen riesgos que son característicos de ese proyecto: <Joe está dispuesto
a abandonar, a menos que se pueda llevar su perro al trabajo, y la direc-
ción aún no ha decidido si va a permitir que Bowser entre en la oficina.>
Este tipo de riesgos los tendrá que identificar usted mismo.
Tabla 5.3. Riesgos potenciales de la planificación
Creación de la planfficación
Las definiciones de la planificación, de los recursos y del producto han sido
impuestas por el cliente o un directivo superior, y no están equilibradas.
Planificación optimista, <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 personas específicas de un
equipo, pero estas personas no están disponibles.
No se puede construir un producto de tal envergadura en el tiempo asignado.
El producto es más grande que el estimado (en líneas de código, en el número de
puntos de función, o en relación con el tamaño del proyecto anterior). I
El esfuerzo es mayor que el estimado (por líneas de código, número de puntos

i'
de función, módulos, etc.).
(conrinLia )
gr5
-*5l.,65-3. Cqnrinuación)
-i :.:srimación debida a un retraso en la planificación es demasiado oli-nr :-.*

¡ lsnora 1a historia de1 proyecto.
La presión excesiva en la planificación reduce la productividad.
La fecha final ha cambiado sin ajustarse a1 ámbito del producto o a los re;*
disponibles.
un retraso en una tarea produce retrasos en cascada en las tareas dependr;--,.-,
Las áreas desconocidas del producto llevan más tiempo del esperado en el ¡-.:
y en la implementación.
Orgunizació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 la plantilla reducen 1a capacidad del equ
Dirección o marketing insisten en tomar decisiones técnicas que alargan la
planificación.
La estructura inadecuada de un equipo reduce la productividad.
El ciclo de revisión/decisión de la directiva
es más lento de lo esperado.
El presupuesto varía el plan del proyecto.
La dirección toma decisiones que reducen la motivación del equipo de
desarroll o.
Las tareas no técnicas encargadas a terceros necesitan más tiempo del esper;_
(aprobación del presupuesto, aprobación de la adquisición de material.
revisiones legales, seguridad, etc.).
La planificación es demasiado mala para ajustarse a la velocidad de desarr¡
deseada.
Los pla'es del proyecto se abandonan por ra presión, ilevando ar caos y
desarrol lo i neficiente.
La dirección pone más énfasis en las heroicidades que en informarse exactarr-.-:
del estado, lo que reduce su habiricrad para detectar y corregir problemas
Entorno de desawollo
Los espacios no están disponibles en el momento necesario.
Los espacios están disponibres pero no son adecuados (por ejernplo, fali, :.
teléfonos. cableado de la red, mobiliario, material ¿. oficinu, et..).
Los espacios están sobreutilizados, son ruidosos o distraen.
Las herramientas de desarrollo no están disponibles en el momento
deseado.
Las herramientas de desarrollo no funcionan como se esperaba; er persona.
:,
desa¡rollo necesita tiempo para resorverro o adaptarse a las nuevas hirramier-.
.
(.cort;i ,:
t .'kmamut $ .@síiltr¡ .re;!Íqrms ,:rci".-nalcos
;'e 53 I :a:tluitcton )
Nta*rlr, cont¡atado
=- srsonal contratado no suministra 1os componentes en el período establee-ic..
El personal contratado proporciona material
de una calidad inaceptable, por io
que hay que añadir un tiempo extra para mejorar ra
calidad.
Los proveedores no se integran en el proyecto,
con ro que no se alcanza er nirer
de rendimiento que se necesita.
Requisitos
Los requisitos se han adaptado, pero continúan
cambiando.
Los requisitos no se han definido correctamente,
y su redefinición aumenta er
ámbito del proyecto.
Se añaden requisitos extra.
Las partes del proyecto qu_e se no se han
especificado claramente consumen
más tiempo del esperado.
Prodacto
Los módulos propensos a tener errores necesitan
más trabajo de comprobación.
diseño e implementación.
una calidad no aceptable.requiere de un trabajo
de comprobación, diseño e
implementación superior al esperado.
utilizar lo último en informátic
a alargara planificación de forma impredecible.
El desarrollo de funciones software erróneas
requiere vorver a diseñarras y a
implementarlas.
El desar¡ollo de una interfaz de usuario inadecuada
requiere vorver a diseñarla
y a implementarla.
El desarrollo de funciones software innecesarias
ararga lapranificación.
Alcanzar el ámbito der producto o ras restricciones
de verocidad requiere más
tiempo del esperado,incruyéirto er tiempo para volver a diseñar e
imptementa..
unos requisitos rígidos de compatibiridad
con er sistema existente necesitan un
trabajo extra de comprobación, diseño e implementación.
Los requisitos para crear interfaces con
otros sistemas, otros sistemas complejos,
u otros sistemas que no están bajo er control
der equipo ¿. ¿.ru..olio suponen
un diseño, implementación y prueba no previstos.
El requisito de traba.iar con varios sistemas
operativos necesita más tiempo del
esperado.
El trabajo con un entorno software desconocido
causa problemas no previstos.
El traba-io con un entorno hardware desconocido
causa problemas imprevistos.
E1 desarrollo de un tipo de componente nuevo pararaorganización
más tiempo del esperado. consume
(continúal
Capítulo S: Gestión de riesgos
99
Tabla 5.3. (Continuación)
Depender de una tecnología que

aún está en fase de desarrorl0 arargala
planificación.
Faerzas mayores
El p^roducto depende de las normativas
del gobierno, que pueden cambiar de
forma inesperada.
El producto depende de estándares técnicos
provisionares, que pueden cambiar
de forma inesperada.
Personal
La contratación tarda más de lo esperado.
Las tareas preliminares (por ejemplo,
formación, finalizaciónde otros
proyectos, adquisición de licencias)
no se han compretado a tiempo.
La falta de relaciones entre la dirección y
el equipo de desarroro rarentrza ra
toma de decisiones.
Los miembros del equipo no se implican
en el proyecto, y por lo tanto no
alcanzan el nivel de rendimiento deseado.
La falta de motivación y de moral reduce
la productividad.
La falfa de la especiarización necesaria
aumenta los defectos y ra necesidad de
repetir el trabajo.
El personal necesita un tiempo extraparaacostumbrarse
a trabajar con
herramientas o entornos nuevos.
El personal necesita un tiempo extra para
acostumbrarse a trabajar con
hardware nuevo.
El personal necesita un tiempo extra para
aprender un lenguaje de
programación nuevo.
El personal contratado abándona er proyecto
antes de su finarización.
Alguien de la prantilra abandona el proyecto
antes de su finalización.
La incorporación de nuevo personal
de desarrollo al proyecto ya avanzad,o,
aprendizaje y comunicaciones extra y el
imprevistas reducen ra eficiencia
miembros del equipo existentes. de ros
Los miembros del equipo no trabajan juntos.

bien
Los conflictos entre los m,iembros
del equipo conducen a problemas en
comunicación y en el diseño, ...o.". la
.n lu interfazy táer qu"
aigunos trabajos. ffi'.
Los miembros problemático.s de un
equipo no son apartados, influyendo
negativamente en la motivación
del resto Oeiequipo.
Las personas más apropiadas para
trabajaren el proyecto no están disponibles,
(contintia)
nll[ .:mwm¡,nmru il {rgslrrí$rr .rc ría€cF}- -t:-o-:g..;s
rü 5.I. -,t.r:i¿ciónt
--&s sff!{1na-i más apropiadas para trabajar en el proyecto están disponibles.

re:ü nLr se pueden incorporar por razones políticas o de otro tipo.
-i¡ necesi¡an personas para el proyecto con habilidades muy específicas v no s-
encuentran.
Las personas clave sólo están disponibles una parte del tiempo.
No hay suficiente personal disponible para el proyecto.
Las tareas asignadas al personal no se ajustan a sus posibilidades.
El personal trabaja más lento de io esperado.
El sabotaje por parte de la dirección del proyecto deriva en una planificación
inefi ciente e inefectiva.
El sabotaje por parte del personal técnico deriva en una pérdida de trabajo o en
un trabajo de poca calidad, por 1o que hay que repetir algunos trabajos.
Diseño e implementació n
Un diseño demasiado sencillo no cubre las cuestiones principales, con 1o que
hay que volver a diseñar e implementar.
Un diseño demasiado compiejo exige tener en cuenta complicaciones
innecesarias e improductivas en la implementación.
Un mal diseño implica volver a diseñar e implementar.
La utilización de metodologías desconocidas deriva en un período extra de
formación y tener que volver atrás para corregir los errores iniciales
cometidos en la metodología.
E1 producto está implementado en un lenguaje de bajo nivel (por ejemplo,
ensamblador) y la productividad es menor de la esperada.
No se puede implementar la funcionalidad deseada con el lenguaje o
bibliotecas utilizados; el pe-qonal de desarrollo tiene que utilizar otras
bibliotecas, o crearlas él mis?ro para conseguir la funcionalidad deseada.
Las bibliotecas de código o clases tienen poca calidad, y generan una comprobación
extra, corrección de errores y la repetición de algunos trabajos.
Se ha sobreestimado el ahorro en la planificación derivado del uso de
herramientas para mejorar la productividad.
Los componentes desarrollados por separado no se pueden integrar de forma
senciila, teniendo que volver a diseñar y repetir algunos trabajos.
Proceso
La burocracia produce un progreso más lento del esperado.
Lafalta de un seguimiento exacto del progreso hace que se desconozca que el
proyecto esté retrasado hasta que está muy avanzado.
(continúa)
Capítulo 5: Gestión de riesgos 101
Tabla 5.3. (Continuacíón)
Las actividades iniciales de control de calidad son

recortadas, haciendo que se
tenga que repetir el trabajo.
un control de calidad inad.ecuado hace que los probremas

de caridad que
afectan a la planificación se conozcan tarde.'
La falta de rigor (ignorar los fundamentos y estándares

del desarrollo de
software) conduce a fallos de comunicación. probremas
de calidad y
repetición del trabajo. Un consumo de tiempo innecesario.
El exceso de rigor (aferramiento burocrático a las poríticas y

estándares de
software) lieva a gastar más tiempo en gestión del necesário.
La creación de informes de estado a nivel de directiva [eva

más tiempo al
desarrollador de lo esperado.
Lafarta de entusiasmo en ra gestión de riesgos impide detectar

ros riesgos más
importantes del proyecto.
La gestión de riesgos del proyecto software consume más

tiempo der esperado.
Fuentes: Principles of software Engineering Management
(Gilb, 199g), .tor ware Rísk Ma-
nagement (Boehm, 19gg),A Manager's Guide to
ioftware Engineeríng (pressman, rgg3),
Third w-ave Project Managemen l (Thomsett, 1993) y
Assessient andv)ntrot oj so¡t.or"
rRlsÉs (Jones, 1994).
5.3. Análisis de riesgos

u,navez que haya identificado ros riesgos de pranificación
de su proyecto,
el paso siguiente es anahzar cada riesgJ para
áeterminu, ,u i*furic. puede
utllizar el análisis de riesgos puru poa", elegir entre
varias'aiernativas
de desarrollo' o para gestionar rós riesgos asociados
con una alternativa que
ya haya elegido. con los riesgos en general,
esto puede .", oiiirit, p".o
cLrando está interesado en ros riesgos de pranificación,
la estimación es
mas sencllla.
Exposición a riesgos
un método útil en el análisis de riesgos es determinar
la <<exposición a ries-
gos> de cada uno de ros riesgos que haya
identificado. ri
riesgos a menudo se abrevialo*o upú (hay "*p"rr"ro. "
quien ra ilama'<impacto
del riesgo>). Una definición de riesgo ,<peioiáu no esperadarr. ru ."_
", de pérdida
posición a riesgos es igual a la probabilidad
no
tiplicada por la magnitud dela pSrdida. por -ut-
ejemplo, si piensa"rf..uau
que ra proba-
bilidad puede ser del 25 por I 0Ó y puede haber
un retraso de cuatro semanas
rn ,fummmmru ü,mmll¡, re ,,ryl@s nÉr"ta¡¡ffi
{murc lre úwrrion del proyecto, la exposición al riesgo sería 25 por

-- ¡*ndo por cuafro semanas? es l[rr,
decir, una semana.
Ccmo sólo está interesado en los riesgos de planificación,
puede e-\-
ir$a¡ las pérdidas en semanas o meses o en otra unidad de tiempo que
f,acilite la comparación.
La Tabla 5.4 es un ejemplo de estimación de riresgos
de planificación
a R,artir del la probabilidu¿ ¿J p¿rJiá", rl_"gni-
:T,l::Ô:.".:,"j .riesgo,
rud de la pérdida y la exposición a riesgos.
En el ejemplo de estimación de riesgos de la Tabla
5.4, erproyecto ha
identificado varios riesgos cuya gravedaá puede
estar entre i y io ,r,,'urrur.
Tabla 5.4. Ejemplo de tabta de estimación de riesgos
Probabilidad Magnitud Exposición

de pérdida de la pérdida a riesgo
(semanas) (semanas)
Planificación demasiado optimista 50o/o 5 )\
Añadir un requisito parala 5% 20 1,0
actualización automática desde el
mainframe
Añadir nuevas características desde 3s% 2,8

marketing (sin conocer las
características específi cas)
Interfaz del subsistema de formato ) <o/-

1,0
de gráficos inestable
Diseño inadecuado (hay que volver t5% l5 ) )<

a diseñar)
La aprobación del proyecto tarda 2s% 1,0

más de lo esperado
Los recursos no están disponibles

en su momento
l0y6 o)
Los infon¡es de estado a nivel de 10% 0,1
directiva necesitan más tiempo
del previsto
El personal contratado se retrasa en l0-2Ao/o

la entrega del subsistema encargado 0,4-0,8
de formatear los gráficos
Las nuer.as herramientas de

30% 1,5
programación no producen el ahor¡o
prometido
Capítulo S: Gestión de riesgos 103
Las probabilidades de que ocrrrra alguno de los riesgos

oscilan entre un
5y un 50 por 100_ En rm Fo!-trro real tendría que identificar muchos
más riesgos de los qtre sE rlrffi¿n en la tabla anterior.
¿De dónde han sdido hs probabilidades 1' la magnirud de ra pérdida?
Es¡os nrheros hy qpe
Estimacirin de !a F¡agnitud de ¡a ¡Érdida

Muchas veces es más-ñcit estimar la magnitud de la perdida que
la proba-
bilidad. En el ejemplo anterior, podria haber estimado 20 meses
como
el tiempo que se necesitaría para automatizar las actualizaciones
desde el
mainframe. o bien podría saber que er proyecto se aprobará
el l de febre-
ro o el I de marzo, dependiendo del mes en que ra cómisión
rer.ise la pro-
puesta del proyecto. Si supone que podría aprobarse
er I de febrero, la
magnitud del riesgo para la aprobación del proyecto sería exactamente
un mes.
En los casos en que la magnitud de pérdida no es fácil de
estimar direc-
tamente' se puede dividir ra pérdida en pérdidas más pequeñas,
estimarlas,
y. combinar las pérdidas pequeñas en una estimacidn
á" u pe.aiaa. por
ejemplo, si está utilizando tres herramientas de programación, podría
esti-
mar la pérdida resultante a partir de ras pérdidá, q". podría
iérr"ru, .udu
una de las herramientas. Así podría sumar tas peráidás, y
oblener ra esti-
mación de una forma más sencilla que la estimación gíoLA.
Estimación de la probab¡l¡dad de pérdida

Normalmente, la estimación de la probabilidad de pérdida
es más subjeti-
va que la estimación de la magnitud de ra pérdida, ixistiendo
muchas téc-
nicas para mejorar ra exactitud de esta esiimación subjetiva.
He aquí al-
gunas ideas:
Disponer de la persona que esté más familiarizada con

el sistema
para que estime la probabilidad de cada riesgo, y
luego rcalizar una
revisión de la estimación.
Usar técnicas Delphi o de consenso en grupo. Con la
técnica Del_
phi, cada persona estima individualm"nJe riesgo, y lrr"go ,"
"ada
discute o se escribe er origen de cada estimación, .rp-."iáh"rri" .r,
las que haya mayores diferencias. continuar proceso hasta
hacer converger las estimaciones. "o, "i
Realizar analogías con apuestas: <¿Aceptarías esta
apuesta? Si los
recursos están disponibles en su momento ganas
ri5 dólares. si
no 1o están, yo gano 100 dólares.>> Ajustar la apuesta
hasta que los
dos apostantes estén igual de ."grrár. La prolabilidad
de ,i"rgo
: :.:;:'jad total en juego. E:
e. e_iemplo. 1¿ ::'::":---::a :- J-*¿,,:,s :e,-ursos no estén dispo:r:-
bies en su rloi::el:lr tutrür-i¡ ser iuu (iU0 - 125):44 por 100.
¡ Utilice 1a .,calibración mediante adjetivos>. Primero cada persoi.
elige el nir.el de riesgo entre una serie de frases como muy probable.
bastante probable, probable, improbable, muy improbable. Despues
se convierte cada una de las estimaciones verbales a estimacione.
cuantitativas (Boehm, 1989).
Retraso total del proyecto y margen de retraso

Un efecto colateral interesante de calcular los números de exposición a
riesgos mostrados en ia 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 llue ocurra, tampoco debe es-
perar no perder ninguna semana. Estadísticamente hablando, la cantidad
que 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. Como
sólo estamos hablando de riesgos en la planificación, puede sumar todas
las exposiciones a riesgos para obtener el retraso total del proyecto. Así e1
retraso si no se hiciese ninguna gestión de riesgos estaría entre 12,8 y
13,2 semanas.
La magnitud 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.
REFERENCIA ¿Se podría cambiar la planificación para reflejar el retraso espe-
CRUZADA
rado? Creo que sí. Vuelva a calcular la exposición a riesgos total después
Para mayor
.'orrración sobre los de haber realizado el plan de gestión de riesgos, y luego añádalo a su pla-
s gncs más o menos nificación como un margen. Esto le dará un margen de retraso más claro
e. la planificación,
:o:SJ,ae . Estrlos de que la regla elemental que utilizan algunas personas para ajustar sus plani-
3-¿s::iación de una ficaciones. Otra manera sería crear una planificación con signos más o
3s: -ac'ón,'. en la
Sección 8.3. menos paru cada riesgo, y ajustar la planificación cuando se produzca un
riesgo.
5.4. Priorización de r¡esgos

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
e1 esfuerzo para la gestión de riesgos. Los proyectos gastan generalmente
t_
l
Capítulo 5: Gestión de riesgos 105
el 80 por 100 de su presupuesto en arreglar el 20 por 100 de sus proble-

mas, por 1o que es útil poder centrarse en este 20 por 100 más importante.
. -" r. ':¿.::;_- -r ,;-
;;-t--,. -- :q:¿r::--r Unavez más, el trabajo es más fácil si sólo considera los riesgos de
n::t:-:;.-t:- gs planificación que si se centra en todos los tipos de riesgos. Una vez que
írc:.:-:z:¿ que los haya calculado la exposición a riesgos multiplicando la probabilidad de
.:¿:¿os en los
pérdida por la magnitud de la pérdida, ordene los riesgos según la exposi-
q-x¿ {,-,J ;eniremos
secn los riesgos ción a riesgos en su tabla de estimación de riesgos, y vea cómo ha queda-
auténticos. do. La Tabla 5.5 es un ejemplo de una tabla de estimación de riesgos
Peter Drucker ordenada por la exposición a riesgos.
5.5.
1
Tabla Ejemplo de tabla de estimación de riesgos priorizada

ri
probabilidad -Nlagnitud Exposición

Riesgo de la pérdida a riesgo
d;;é;i;;-
-- r-- ----- (semanas) (semanas)
Añadir nuevas caracteristicas 35% 2.8

desde marketing (sin conocer las
características específicas)
Planificación demasiado 50% ')\
optimista
Diseño inadecuado (hay que l5% 15 ))\
volver a diseñar)
Las nuevas herramientas de 30% 1,5
programación no producen el
ahor-ro prometido
Añadir un requisito parala 5% 20 1,0
actualización automática desde
el mainframe
Interfaz del subsistema de 25% 1,0
formato de gráficos inestable
La aprobación del proyecto tarda 25% 1,0
más de lo esperado
El personal contratado se retrasa t0-20% 0,4-0,8
en la entrega del subsistema
encargado de formatear los
gráficos
Los recursos no están disponibles t0% 0,2
en su momento
Los informes a nivel de directiva t0% 0.1
necesitan más tiempo del previsto
t'ü
.]iM'mrmfn' il msrün rc Jrqrffi;s ¡nfa¡-rnáticps
:-qr :orr¡a de ordenación de la tabla genera una lista de los riesgos

:r-im¡,ia aproximadamente porprioridades. si consigue controlar
los cinco
rr:-üros riesgos de la tabla, cabria esperar una reducción de 9,g semanas
en el rerraso total esperado de la planificación.
Si se decidiera á controlar
los cinco últimos riesgos de ra tabra sólo podría esperar
una reducción
entre 2,7 y 3'l semanas sobre el retraso toiar esperado
del proyecto. En
término medio, sería mejor concentrar el esfueizo en
el cántiol de ros
cinco primeros riesgos de la lista.
- .Larazón por la que la rista sólo está ordenada <aproximadamente)) se
a que quizá podria desear ptiorizar algunos de los .l.rgá, que pro_
!eb7
ducirían una pérdida grande, independientemente del lugar q-.r"
o"upur".,
en la tabla. En la Tabla 5.5, er riesgo <Añadir el requisito
de áctualización
automática desde el mainframe> es aproximadamente der 5 por
100, pero
produciría un retraso de 20 semanas, que es mayor que
el de cualquier
otro tipo de riesgo. Si se produjese un retraso de 20 semanas, podría
su-
poner un desastre para su proyecto, por ro que debería gestionar
los ries-
gos de esa magnitud para asegurar que no ocurriese ninguno
de eilos, in-
cluso aunque tengan una probabilidad pequeña de ocurrencia.
Asimismo, puede querer priorizar un grupo de riesgos encadenados
en lugar de priorízar cada uno de los riesgos individualÁente. por
ejem-
plo, la inestabilidad de la interfaz der subsistema de formato
de gráficos
es un riesgo, y también es un riesgo la fecha en ra que
el personal contra-
tado entregue el producto. El riesgo combinado qrr. upu."""
ar utnizar
personal contratado y tener el código desarrollado poi ellos para
crear
una interfaz que parece inestable, es un poco mayor que
si se considera
cada uno de los riesgos de forma individual.
La ordenación de prioridades sóro es aproximada por otra razón:
los números que se han utilizado para crear ra tabla son
estimaciones.
Así pues, la exactitud de ros números de ra exposición a riesgos
y el or-
den de las prioridades depende de la precisión de las estimaciones
de
la probabilidad y de ra magnitud der 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óro puede
llegar a ser tan exacta como ra entrada,y como ra entrada es
algo subjeti-
vo, la priorización también es algo subjetivo. Así, su capacidadie
valora-
ción es una parte necesaria pata cadauno de ros aspectos de gestión
ra de
riesgos.
una vez que haya identificado cada uno de los elementos de alto
ries_.,
go, también es importante rearizar una priorización de riesgos
para in-
formar de los riesgos- que. se pueden ignorar. No nos p."á.upur._o,
de la. gestión de pequeños riesgos que además rengan
una p.ouauitidad de
aparición pequeña. En el ejempro anterior podría*gastar
gestión del riesgo por que ros recursos no .itér, -as tiempo en la
disponibles ,u
to que si realmente no estuviesen disponibres en su momento. "n La-o*"rr-
priori-
Capítulo 5: Gestian ce ,.,iesgos 1O7
zación de riesgos es un proceso crítico en el que hay que tener cuidado de

no dedicar todo el esfuerzo a la gestión de riesgos en sí.
5.5. Control de riesgos

Una vez que haya identificado los riesgos de su proyecto, analizado sus
probabilidades y magnitudes, y los haya priorizado, está preparado para
controlarlos. E,sta sección describe 1os tres aspectos de1 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 riesgos

El objetivo de la planificación de la gestión de riesgos es desarrollar un
plan que controle cada uno de los riesgos de prioridad alta identificados
en las actividades anteriores. E,l plan de gestión de riesgos puede ser tan
sencillo como un párrafo para cada riesgo, describiendo quién, qué, cuán-
do y cómo se gestiona cada uno de los riesgos. También debería contener
previsiones parala monitorización de riesgos, descartando los riesgos que
se han resuelto e identificando los riesgos que aparecen.
Resolución de r¡esgos
La 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 al riesgo de que su equipo sea expulsado de sus oficinas.
BIBLIOGRAFIA Supongamos que está encargado de 1a contratación y está preocupado
ADICIONAL
A veces, la resolución por los riesgos de la creación de un diseño inadecuado en un área nueva
efectiva de riesgos para usted y que su despacho va a ser cedido a otro grupo de trabajo de la
consiste en encontrar
una solución creativa empresa. A continuación se describen una serie de métodos para tratar los
para el riesgo riesgos mediante ejemplos relacionados con los riesgos del diseño y del
aspecífico. Una buena
fuente de ideas de
lugar de trabajo.
cómo resolver muchos
de los riesgos de un
proyecto software es
Evite el r¡esgo. No realice actividades arriesgadas. Por ejemplo, tome
Assessment and responsabilidades en la mayor parte del diseño del sistema, pero no en las
Control of Software partes que no conozca. En cuanto al problema del lugar de trabajo, nego-
Blsks (Jones, 1 994).
cie con el grupo que pretende desplazarlo de su lugar de trabajo y con-
vénzalos para que no 1o trasladen.
Traslade el riesgo de una parte del s¡stema a otra. A veces 1o que

es un riesgo en una parte del proyecto no 1o es en otra parte de1 proyecto,
por 1o que puede trasladarlo a otra parte. Por ejemplo, en el área de rela-
ciones públicas: Imagine que tiene que diseñar una parte del sistema en-
-.¿-
'1rü fnwr¡¡nfu r ¡mrmr rc 4ra:+,os informáticas
rffi:ryn ¡I resto del equipo, que va a diseñar una parte con la que no está
*nrmir¡riz¡do. O podría hacer que le revisasen y aprobasen su diseño, trasla-
ói:lri.oles las responsabilidades. En el caso del espacio de trabajo, dispo-
ner de otro grupo cuya planificación menos crítica permita cambiar el
espacio en lugar de en el suyo, o esperar a que el sistema esté preparado
para ei traslado.
En general, aparle el riesgo del camino crítico. Planifique el proyecto
de forma que si ocurre un riesgo, el proyecto completo no se retrase.
Consiga información acerca del riesgo. Si no conoce el auténtico

peligro del riesgo, averígüelo. Por ejemplo, desarrolle un prototipo para
comprobar la viabilidad de su alternativa de diseño. Localice un asesor
que evalúe su diseño. Utilice la planificación de recursos para ver si pue-
de permanecer en su lugar de trabajo mientras dure el proyecto.
Elimine el origen del riesgo. Si el diseño de una parte del sistema es

demasiado arriesgado, cambie la parte del sistema a un proyecto de investi-
gación y elimínelo de la versión que está desarrollando. Intente convencer
al grupo de trabajo que trata de ocupar su lugar de trabajo de que utilice
otro espacio en donde puedan estar todos juntos. U obtenga una confirma-
ción del grupo de planificación de infraestructuras para que le dejen per-
manecer en su despacho mientras dure el proyecto.
Asuma el r¡esgo. Acepte que el riesgo puede ocurrir, pero no piense

demasiado en ello. Si las consecuencias son pequeñas y el esfuerzo que
se requiere para evitarlo es mucho, hacer caso omiso puede ser la mejor
estrategia. Simplemente acepte las consecuencias de un diseño inadecua-
do o de que 1o 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. Intente
suavizar e1 susto que se llevarán si llega a ocurrir.
Controle el riesgo. Acepte que el riesgo puede ocurrir y desarrolle

planes de contingencia para controlar el riesgo si no puede resolverlo.
Busque recursos extra para comprobar la parte del sistema con el diseño
que le preocupa, y prepare un tiempo extra para corregir los problemas.
Planrñque 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 facllitar las tareas de empaquetar
y desempaquetar.
Recuerde el r¡esgo. Cree una colección de planes de gestión de ries-

gos que pueda utllizar en proyectos futuros.
t
Capítulo 5: Gestión de riesgos l0g
Para ilustrar la forma en que puede controlar algunos de estos riesgos.
la Tabla 5.6 lista los métodos de control de los riesgos más comunes
en la
planificación.
Tabla 5.6. Métodos de control de los riesgos más habituales en

planificación
Riesgo Métodos de control Dónde encontrar más

información
l. Cambio de Uso de técnicas Capítulo 10, <Desarrollo

prestaciones orientadas al cliente. orientado al cliente>.
Uso de técnicas de Capítulo 7, <Planifi cación
desarrollo incremental. del ciclo de vida>.
Controle el conjunto de Capítulo 14, <Control del
prestaciones. conjunto de prestaciones>.
Diseño para el cambio. Capítulo 19, <Diseño para
el cambio>.
Requerimientos Filtrado de <Filtrado de
superfluos o requerimientos. requerimientos>, en la
personal de Sección 14.1.
desarrollo
Desarrollo con ventanas Capítulo 39, <Desarrollo
meticuloso
temporales. con ventanas temporales>.
Control del conjunto de Capítulo 14, <Control del
prestaciones. conjunto de prestaciones>.
Uso de entrega por Capítulo 36, <Entrega por
etapas. etapas), y Sección 7.6,
<Entrega por etapas)).
Uso de prototipos Capítulo 38, <Prototipos
desechables. desechables>.
Diseño por p1anifi cación Sección 7.7, <Diseño por
planificacióu.
3. Recorte de ia Deje tiempo a las Sección 4.3, <Bases del
calidad actividades del control control de calidaó.
de calidad y preste
atención a las bases del
control de calidad.
4. Planificación Utilización de varias Capítulo 8, <Estimación>
demasiado optimista técnicas de estimación,
varios estimadores y
herramientas de
estimación.
(continúa I
I
364 Desarrc;;a J, Eest¡ón de proyectos informáticos
seguir trabajando como si tuviera unos requerirnientos e,.-_r :

tomas ciertas medidas para compensar los requerimienros ::r.
debe tomarlas si desea alcanzar el desarrolio rápido.
Métodos de control de cambios

Como detener los cambios a toda costa no sueie beneficiar lr.¡ r':-: ,ri,
de un proyecto, la gestión efectiva de los cambios se cont-ie :,; : - -"1'

cuestión fundamental para la mayoría de proyectos. Cualqul;: : r rtr
gestión de cambios debe perseguir varios objetivos:
Permitir cambios que ayuden a obtener el mejor produc:.- : r'r

en el tiempo disponible. No permitir ningún otro tipo de;. :
Permitir que todas las partes afectadas por un cambio F:---: r
estimen los impactos del cambio en la planificación, los re: *-,"

el producto.
Notificar cada cambio propuesto a los miembros de1 €or,-rr, .;:.
proyecto, indicando su impacto estimado y si ha sido ace::,-
rechazado.
Mantener un registro de las decisiones relacionadas con e1 .:: '. i
do del producto.
El proceso de cambio debe ser estructurado pararealizar eSt3! .j-::.-.

de forma tan eficiente como sea posible. Aquí tenemos algunas oi: : r:
para lograr este objetivo.
Métodos de recopilación de requer¡mientos orientados al clie-:*

REFERENCIAS Una de las estrategias de control de cambios consiste en minim.:.- ,
CRUZADAS
número de cambios necesarios. Los métodos de recopilación de:;--:
sobre métodos de rimientos orientados al cliente funcionan mejor para educir los re;-.-
trabajo con mientos reales que los métodos tradicionales. Por ejemplo, un estuc,. .,.
requerimientos
orientados al cliente, encontrado que la combinación de JAD y prototipado puede redL¡c-:
consulte el Capítulo 10, cambios en los requerimientos por debajo de un 5 por 100 (Jones. ,.:-
"Desarrollo orientado
al cliente.. Para más El prototipado ayuda a reducir las modificaciones porque incide justo ; - : ,
detalles sobre los a menudo se encuentra laraiz del problema: el hecho de que los c1,._-.
prototipos
desechables, consulte no saben lo que quieren hasta que 1o ven. Los prototipos desechabi;_. :=-
e{ Capítulo 38, sultan generalmente el método más eficaz en este aspecto, y olrec- i
. p rototi pos
desechables".
mayor resistencia a cambios en los requerimientos (Jones, 1994).
Análisis de los camb¡os

En muchos casos, el trabajo del desarrollador o del responsable te¡_ -.
no consiste en decir <No> a los cambios. Pero puede usar e1 proces, _:
Capítulo 14: Control del conjunto de prestaciones
análisis de los cambios para sacar a relucir los cambios superfluos. En

lugar de decir <<No> ante cada cambio. indique su impacto sobre la plani-
ficación y el coste. Explique que tiene que ajustar la planificación para
reflejar el tiempo empleado en analizat las peticiones de nuevas prestacio-
nes. Esta explicación permitirá descartar la mayoría de peticiones de cam-
bios superfluos.
También puede descartar cambios haciendo más dificil la presenta-
ción de una petición de cambio. Puede insistir en una especificación es-
crita completa del cambio, un análisis de un caso de aplicación, un ejem-
plo de las entradas y salidas afectadas, etc.
John Boddie cuenta que una vez fue llamado a la oficina centrai para
una reunión de emergenc ia para la planificación de un proyecto conflicti-
vo. Cuando llegó con su equipo, su jefe preguntó: <¿Va todo según 1o
previsto para entregar el producto el día 18?> Boddie dijo que sí. Enton-
ces su jefe preguntó: <Así pues, ¿tendremos el producto el día 18?>
Boddie dijo: <No, tendrá que esperar hasta el 19, porque esta reunión
nos ha quitado un día de trabajo> (Boddie, 1987).
En las últimas semanas de un proyecto, podría decir que el retraso
mínimo para cualquier cambio de prestaciones es de un día o más. In-
cluso podría decir que el retraso míninto por considerar Ltn cambio de
prestaciones es de un día completo o más. Esto es correcto, porque los
cambios de última hora tienden a incidir en todos los aspectos del proyec-
to, a menudo de manera que resultan difíciles de predecir sin un análisis
cuidadoso.
Es probable que desee hacer esto algo más fácll para aceptar las pe-
ticiones de cambios relacionadas con defectos. Pero incluso los defectos
sin importancia pueden tener amplias consecuencias, así que dependien-
do del tipo de programa y de la etapa del proyecto, puede que no los
acepte.
Versión 2
A la hora de decir <No> frente a una modificación del producto actual,
resulta de gran ayuda poder decir <<Sí>i a incluir dichos cambios en algún
producto futuro. Cree una lista de futuras mejoras. La gente debe com-
prender que estas mejoras no van a incluirse forzosamente en la versión 2
simplemente porque no encajan en la versión 1, pero no necesita hacer
hincapié en este punto. Lo que tiene que dejar claro es que está escuchan-
do las preocupaciones de la gente, y piensa atenderlas en el momento ade-
cuado. En un proyecto de desarrollo rápido, el momento apropiado suele
ser <El proyecto siguiente>.
Como complemento efectivo de la estrategia de la versión 2, puede
crear un <plan de tecnología multiversión), que se corresponda con una
estrategia plurianual para su producto. Esto contribuye a que las personas
_ .¡L--
Capítulo 14: Control del conjunto de prestaciones
Destrío. Además de analizar cada cambio, el grupo de cambios tiene

que aceptar o rechazar cada uno de ellos. Algunas organizaciones se refie-
ren a este aspecto del trabajo del grupo de cambios como <destrio>> (tria-
ge), término usado en la medicina de urgencia para referirse a la actividad
de ordenar en grupos a los enfermos, para que las personas que más se
van a beneficiar de un tratamiento médico 1o reciban primero.
El <destrío>> tiene algunas connotaciones particularmente adecuadas
para el funcionamiento de un grupo de control de cambios del software.
El destrío implica que se está reservando un recurso escaso, y que no hay
suficientes recursos para todo. Esto es cierto en el software. Nunca habrá
suficiente tiempo ni dinero para incorporar todas las prestaciones desea-
das por todo el mundo. El destrío también implica que algunas personas
no recibirán ayuda aunque la necesiten desesperadamente. En el software,
algunos cambios que pueden parecer desesperadamente necesarios no se
realizarán en la siguiente versión del software. Algunas prestaciones no
serán implementadas, y algunos defectos de baja prioridad no serán corre-
gidos. Por último, el destrío implica también que se está haciendo algo
crítico parala vida. Y cuando estápriorizando peticiones de cambios en
un proyecto de desarrollo rápido, realmente está haciendo un trabajo crí-
tico para Ia vida de su proyecto.
Agrupación. El grupo de cambios también puede agrupar pequeños

cambios para que los desarrolladores puedan manejarlos en grupos. Una
serie de cambios pequeños y descoordinados puede distraer y volver locos
a los desarrolladores en las etapas finales de un proyecto. Cada cambio
requiere reahzar una revisión del código, actualizar la documentación,
hacer pruebas, comprobar el cambio de archivos en el control de versio-
nes, etc. Los desarrolladores agradecerán poder gestionar los cambios pe-
queños en grupos en lugar de tratarlos de uno en uno.
Cuestiones burocráticas. Los grupos de control de cambios han

sido marcados con el estigma de ser demasiado burocráticos. Parte de
esta mala prensa se debe a los grupos de cambios ineficaces. Algunos
grupos de cambios interpretan su misión como limitarse a decir <No>
en lugar de responsabilizarse de producir el mejor producto posible en
el tiempo disponible. Pero el hecho de que algunos grupos de cambios
no se hayan comportado adecuadamente no implica que la idea sea
mala.
El resto de la mala prensa se debe al hecho de que el trabajo del gru-
po de control de cambios es impopular. Si el equipo ha hecho un trabajo
digno al especificar el producto, un grupo de control de cambios que fun-
cione adecuadamente dirá que <<No> a más solicitudes de 1as que aceptará.
A las personas que reciban un <No> les parecerá demasiado burocrático.
Puede que la organización que más se queja de un grupo de control de cam-
J€s: r,. de proyectos ínformáticos
bios sea aquella que necesita una mayor protección

frente a cambi,:,
incontrolados.
un grupo efectivo de contror de cambios garattiza que conocerá
1"s
consecuencias de cada cambio antes de realizarlo.
como Ln muchos orr..s
aspectos de las técnicas orientadas a ra verocidad
de desarrollo, un g.up-
de control de cambios resurta vaiioso porque re
ayuda a tomar áecisiones
teniendo a la vista todas ras sobre laverocidad de desarroilo
"onr..u.n"ias
14.3. Proyecto a punto de terminar: recorte

de prestaciones
F'l control del conjunto de prestaciones continúa
siendo importante hacia
el final de un proyecto. Aunque haya tenido éxito al
junto inicial mínimo de prestaciones y
..p".ifi"u, un con-
controrar los cambios en medio d:.
proyecto, hay muchas razones famiriares por las que
puede encontrars-
fuera de lo programado al final del proyec?o.
- Al llegar a este punto, una de lai opciones más potentes para reducir
ia planificación es la eliminación de prestaciones
dé baja pritridad. Esre
método-es efectivo porque erimina el esfuerzo
asociado.on tu impremen-
tación, la prueba y la documentación correspondientes.
Este métod.o es
común en Microsoft, donde ha sido considerado un método
eficaz para
controlat proyectos softwate rettasad.os (Cu.sr-rrrraro .y Se,\kr-g_ \995.. \.l\cr
tr$ \)9:\). ,
La desventaja de este método consiste en que cuando llega al final del
proyecto, puede que yahayarealizado el trabajo de diseño y parte de la
implementación y comprobación de las prestaciones que suprime. Inclu-
so puede que necesite realizar algún trabajo para suprimir la prestación
(quitar código que no se va a utilízar o desactivarlo, suprimir los casos de
prueba correspondientes, suprimir la documentación correspondiente a la
prestación, etc.). Si piensa sacar otra versión dei producto, esto sólo re-
presenta un pequeño problema, ya que posiblemente usará el trabajo su-
primido o desactivado en la versión actual.
Para una máxima eficiencia, comience por un documento de requeri-
mientos filtrado, diseñe e implemente las prestaciones que sabe que esta-
rán en el producto, y luego añada prestaciones de baja prioridad cuando
REFERENCIA
CRUZADA
tenga tiempo. No pierda tiempo en prestaciones que serán suprimidas
Para más información posteriormente.
sobre los estilos de Si no cree que pueda adaptarse a esta situación ideal, entonces plani-
desarrollo que
socortan cambios al fique de antemano la supresión de prestaciones al final dei proyecto. Use
r nai de proyecto. un modelo de ciclo de vida como el prototipado evolutivo, la entrega evo-
ci.s! te el Capitulo 7.
= a" Í cac óf del c c o
lutiva, el diseño por planificación o el diseño por herramientas, que so-
de v ia,,. portan cambios de prestaciones al final del proyecto.
Capítulo 14: Control del coniunto de prestactones 369
Ejemplo 14.1. Gestión efectiva de los cambios
Seis semanas aites de:14 fecha de qntrega previsfa de Square-Calc 4'0, Kim
fue,d despacho de Eddie, rrEddie, tenemos un problema. Nuestros compe-
lidores acaban de lanzar una nueva versión. r tiene varias prestaciones
*,rrqvu, tqug n0 tenenl}os eü nu€stro producto. Necesltamos añadir algunas
prestasio¡es ¡o.v¿5 ¿n{es:de entregar este produclo >
Ecldje asintió. <De acuerdo. Haz una lista de las nueras prestaciones.
y la discutiremos en la reunión del grapo de ccetrol de cambios de esta
laide.l Klm ásuvo de acuerdo, y votvió a su despacho para preparar 1a
li sta.
I ,'
E1l la reunién del,grupo de control de cambios, Kim propuso una doce-
na de nuevás prestaiiones,i*rcorporad¿s en eJ producto do 1a competencia
qrrt"; ;-t.d incluidas en su producto. Eítat¡a rüy :afeetada'porque los
conrpetidores.haüían simpliiicado nruóhir los melús, pasando muchos ele-
mento* a,msnús céntéxfuales. DeCiaque eslo:par€Cia $i1e granmejora de la
in,..fu, de usuario. y su producto parecería desfasado si no incorporaba
menús de ese estilo.
una vez que Kim lerminó de describir las nuevas prestaciones, Eddie
cónrerri* a haü1ar. liEn primer l*gai, puede,que nós retfasemos un día sólo
para estinrar tantos cambios. ¿El grupo piensa querestas modificáciones
son suficientemen{e importantes para;justififar ei tiempo de estimación?))
Hl grupo acordó que eran sufiiientemente importanter' <Bien>, dijo Eddie'
,,v-oy a distribuir estas nuevas prestaciones como peticiones de cambios_a
torlós ios grupos afeetados- No quiero interrumpir su ritmo de trabajo más
de 1o necesaiio en esta etapa crítica de1 proyecto, así que les da¡é algunos
días para respónder. Vamos a planificar Ia decisión de estos cambios en
,r,r"riru reunión habitual de coatrcl de cambios de la prórima semana.> E1
grupo asintió. y se dio por finalizada la reunión'
En la siguiente ,*urrión, las estimaciones estaban preparadas' '<Según
estas estimaiiones preliminares. áos fetlasafíamos 3 o 4 msses si imple'
mentáramos todos estss cambios:>, dijo Eddie. <Desaffollo considera, que
son cambios relafivamente pequeños, y ettilia qu€ podrla irnplemé¡rtarlos
en unas suatro $9man¡s, pero,la prueba y ia doctmellación se verían lras'
tantemá afectadas, El ca¡:nbio a lss menús contqxtuales es el más eostoso
ya que cambia iignificativamente la interfaz ile usua-
' "n'tétminog de plazor,
rio del prograáu. fa r-""¡¿o de prueba dice que este cambio por sí solo
exigiria ieescfibir atrededor de un tercio de los casos de prue,ba, lo que
requeririil unas 6 semanas, La seoción de docqmentación nesesita bastante
,
tiempo paia conrenzar a, imprirair, y,teaián previsto enviAr .su trabajo a la
impienta al finai de esta $emaria. T"{ecesiiaríaa ciambiar el 80 pol 100 de sus
pagiaas y 'panfallas de'ay-ilda, rvolver a captular prácticarnente tados los
, volcadoslde pantalla y volver a repetir eL ciclo final ds revisión. Esto retra-
saria s, plaáificacién áe 3 a 4 meses? dependiendo de la rapidez co'* que
puedanl,cOntiatar un escritor exteJno. 51 grupo,de facilidad de uso opina
I ¿ aiil !ili!í0 I
-
370 .lesa--:r,,o '¡,gestión de proyectos informáticos
fervientemente que no debemos plantearnos siquiera la realización de este

caqtrtigi aii
: ry ¡$¡cígg¡qtls..i¿,ie4,pelai.xi,,,,;,
,
<Sigo pensaudo'que es importantei>. dijo Kim. <pero nó creo que.justi-

fiqué un rerraso de 3 meses.', El grupo s€ puso d" acuirdo rápidaÁente en
la posposición del cambio a los menús contextuares. Lo añadieron a la lista
. de prestaciones a considerar para la.siguiente versión.
De las re.stantes peticiones de cambios, el grupo de conrrol de cambios
identificó tres cuyo irnpacto total estimado sobre el desarrollo. Ia omeba'
la documén¡ación era de una semana. Carlos, de marketing. d"reabu.ras
nuevas preslaciones, y dijo que un retraso de rura semana .era un precio
aceptable. El grupo aceptó estos cambios. se idbntificaron cinco .u*bio,
in"tuian pieiraciones a incorporar si había tiempo. pero el grupo
1ás- 9ue
decidió que no eráñ suf"rcientemente impor"tantes para cambiar la lecha de
entrega. Añadieron estos cambios a la lista de prestaciones a considerar
para la siguiente versión, y rechazaron las restantes petíciones.
. .T..1 la ¡eunión, los grup'os afectados recibieron la notillcación de la
decisión del grupo de control de cambios. como en r'a decisión se había
tenido en cuenta la opinión de cada grupo, rodoi ajusraron sus pranifica-
ciones y acepraron los cambios sin pioblemas
Bibliografía adicional
carroll, Paul B.: <creating New Software was Agonizing Task for Mitch
Kapor Firm>, The Wall Street Journal, ll de mayo de 1990, Al, A5.
Es un estudio fascinante del desarrollo de on Location 1.0, e ilustra 1o
que pueden suponer los cambios a ciegas en las prestaciones.
Gibbs, w. wayt: <<Software's chronic crisis>, scientífic American, sep-
tiembre 1994,86-95. E,ste artículo describe algunos proyectos software
recientes que han estado plagados de cambios en los requerimientos.
incluyendo el software de gestión de equipajes der aeropuerto de Denver
y el software de control de tráfico aéreo para estación de trabajo de
FAA.
Jones, Capers: Assessment and Control o.f Software Risks. Englewood
cliffs, N.J.: Yourdon Press, 1994.Elcapítulo 9, <<creeping user Requi-
rements>>, contiene un tratamiento detallado de las causas fundamenta-
les, problemas asociados, impacto en el coste y métodos de preven-
ción y control de cambios en las prestaciones.
Mcconnell, steve: code complete. Redmond, wash.: Microsoft press.
1993. Las secciones de la 3.1 a la 3.3 describen el incremento de los
costes cuando se aceptan cambios en los requerimientos en un pro-
yecto avanzado. También contienen argumentos para intentar obtener
unos requerimientos precisos tan pronto como sea posible.
Capítulo 14: Control del coniunto de prestaciones 371
Bugsy'. TriStar Pictures. Producida por Mark Johnson, Barry Levinson y

Warren Beatty, y dirigida por Barry Levinson, 1991. Esta película
comienza como una historia sobre un gángster que quiere ir a Califor-
nia para robar en Hollywood, pero se convierte rápidamente en un
cuento sobre la obsesión de Bugsy Siegel sobre la construcción del
primer casino de Las Vegas. El casino de Bugsy costó seis veces más
de lo estimado en un principio, debido principalmente a cambios en
las prestaciones. Como desarrollador de software qrle se encuentra en el
lado del constructor de este problema, no resulta dificil experimentar
un sentimiento de justicia cuando Bugsy es tiroteado al finai, por cam-
biar de opinión tan a menudo y gastar demasiado dinero de la mafia.
371
Capítulo 14: Control del coniunto de prestaciones
Johnson' Barry Levinson y

Bugsy: TriStar Pictures. Producida por Mark
Warren Beatty, y áidgiau po' bu"y Levinson' 1991' Esta película
que q,iere ir a Califor-
comienzacomo una hiítoria sobre un gángster
se convierte rápidamente en un
nia para robar en Hollywood' pero
sobre la construcción del
cuento sobre la oUt"*lán de Bugsy Siegel
costó seis veces más
pri-". casino de Las Vegas' f't caiino de Bugsy
a cambios en
de 1o estimado en un pri'ncipio, debido
principalmente
sóftware que se encuentra en el
las prestacion"r. Co-o ¿esanoliador de
lado del constructor de este problema, no
resulta dificil experimentar
unsentimientodejusticiacuandoBugsyestiroteadoalfinal,porcam-
dinero de la mafia'
biar de opinión tan a menudo y gastar demasiado
15
Herramientas para
aumentar la productividad
Contenido
15.1. Papel de las herramientas de incremento de la productividad en el
desarrollo rápido
15.2. Estrategia de las herramientas para productividad
15.3. Adquisición de he$amientas para productivrd,ad
15.4. Uso de herramientas para productividad
15.5. El síndrome de la panacea
Temas relacionados
Lenguajes para desarrollo rápido: Capítulo 31
Reutilización: Capítulo 33
Diseño por heramientas: Sección 7.9
Resumen del grupo de herramientas: Capítulo 40
LOS RESPONSABLES Y DESARROLLADORES DE SOFTWARE SON

ATRAÍDOS por las herramientas para productividad como las hormigas
a una comida en el campo, los niños a los charcos y las películas policía-
cas de la programación nocturna de televisión a los accidentes de coche.
En ocasiones, son atraídos por las herramientas para productividad como
los marinos borrachos son atraídos por los cantos de sirenas.
Las herramientas para productividad configuran la dimensión de
1a tecnología en el cuarteto personas-proceso-producto-tecnología, y
como tales desempeñan un papel importante en el desarrollo rápido.
Adoptar una nueva herramienta puede ser una de las formas más rápidas
de mejorar la productividad. Pero también puede ser una de las más arries-
gadas.
Las organizaciones más productivas han encontrado r.ías para mini-
373
374 .js-.a'-o,,,'o y gestión de proyectos informáticos
mizar los riesgos y maximizar el incremento de productividad. Su estra=-

gia depende de reconocer estas tres realidades críticas:
Las herramientas para productividad producen en raras ocasloDü$

el ahorro de tiempo prometido por sus fabricantes.
Aprender a usar una nueva herramienta o método disminuve iut-
cialmente la productividad.
Las herramientas para productividad que han sido desacreditari¿¡
proporcionan en ciertos casos ahorros significativos en la planif-
cación, aunque no tanto como se prometía originalmente.
El resto de este capítulo está dedicado a explorar de forma detallao¿

estas realidades.
Ejemplo 15.1. Uso ineficaz de las herramientas
(.continúa)
Capítulo 15: Herramientas para aumentar la productividad 375
ción a la mitad o a un tercio. puede que ahorrelnos un mes o dos. Además.

creo que la prograrnación orientada a objetos alud¿rá a nueslro proyeclo.
De acuerdo. ¡Vamos a hacerlolu
El proyecto comenzó inmediatamente. _\ el erupo estaba asombrado
de la velocidad con que podian construir la inrerlaz básica de usuario con
Blaze-O-Matic. Su sopoite para bases de datos era bueno. y esa parre del
programa se desarrolló rápidamente. Otras parrcs de la henamienta resul-
taban más dificiles de aprender, pero en el plazo de I meses habían reaiiza-
do prácticamente la mitad del producto. Como habían ido superando una
slrfva,de aprendízaje en 1a primera mitad del p.o)'ecror se senrian optimis-
ias robre la finalización de la última mitad del producro dentro dei plazo
total de 3 meses.
r , Entonsgs,descullrieron un resquicio en su armadula. (Oye, Mike, acabo
de,áescubr,ii:qne las pantallas de ayuda no son tan f;iciles de ielacionar como
pensábamos. Crpo que podré,defilirrtoelos 1os enlaces de todas las pantallas
por la tarde, pero Blaze-O-Matic no soporta la ayuda dependiente del conrex-
to. Esto va a requerir más tiempo.'r Angela estaba disgustada. Mike le dijo
:que la qyuda integrada era ufla de ]as prestaciones crítíias del nuevo sistema
de facturaciónr así que debia emplear el tiemporque fuera nesesario.
A lo largo del tercer mes, los miembros del equipo descubrieron más y
rráS:lirnilaeianes de Btraze-O-Matic: Lapublicidad de la henamienta anun-
ciatá que pódía importar automáticamente registros de archivos ASCII en
la base de datos. Contahan con esta prestación para convertir los anriguos
registros de facturación al nuevo formato de la base de datos. Pero Biaze-
O-Matic no gestionaba el tipo de registros que usaban sus archivos. por lo
que tuvieron que codificar a mano todas las rutinas de acceso. El nródulo
de informes era mediocre. y no iba a sopoa{ar exactamerte e1 formato de
informe deseado. así que emplearon mucho tiempo codificando alternati-
vas. y seguían apareciendo fallos en el lormato de los informes después de
creer que habían terminado.
Cr¡ando el equipo llegó al fina} del plazo de 3 meses, tenía pendiente
todavia la implementación del 25 por 100 de1 producto, y estaban de acuerdo
en que necesitaban como minimo dos semanas para tenninar, incluso tra-
f;a¡'ando a todas,horas;r<<Voy a dar las malas noticiasr¡, dijo Mike. Cuando
Volvió, Angela tenía rnái,noficias para é1.
I
,,,,<iTe ácuórdas de laa pantallu*.¿e ¿yuda? Resulta que Blaze-O-Matic
.ryo,sopoqta gnl¿res para,g¡,,uda dependiente del qont€xtol y no ingluye nin-
rg.una furnra de poder lanear la ayuda.desde d-entro de:una aplicación. He
pensado en lanzar la ayuda como urra aplicación genérica,, pero entonces
resull.a que Blaze-O-Matic hace algo extraño con el identificador de rarea
dq!,progrpma qus s€ inicia.. y si otra apiicación tiene abierta la ayuda, Blaze-
A1,\t{üig)a,ciéira, ¡pero no,abqq.la üuestra! E*tóy llamando constantemen-
te al servicio de soporte técnico. y me han dicho que enr,iarán una solución
al problema. Pero están trabajando en una nueva versión, 1 posiblenrenre
tardarán 3 semanas en enviárnosla.>
\ t,))1 tl tiIlLl )
376 üesarroi¡,o y gestión de proyectos informáticos
15.f . Papel de las herramientas de incremento

99 l" productividad en el desarrollo rápido
Las computadoras son buenas para tareas automáticas y repetitivas. La
mayoría de las cosas automafizadas hasta ahora por la teCnológía de desa-
rrollo de software han sido tareas repetitivas: conversión de código en-
s_amblador en lenguaje máquina, creación de descripciones de
bases de
datos a partir de descripciones en lenguaje natural, gestionar una y
otra
vez los mismos tipos de llamadas para proceso de ventanas y demás. pero
hay muchos aspectos del desarroilo de software que no son repetitivos,
y
por tanto no se adaptan bien a su automatización mediante hérramientas
hardware y software.
En 1987, Frederick p. Brooks, Jr., publicó el artícuro <No Silver Bu-
llets-Essence and Accidents of software Engineering>>, y este artículo
se ha convertido en uno de los artículos más fámosor J lrrRry"ntes
en el
campo de la ingeniería del software (Brooks, rggi-). Brooks opina que
ros
aspectos difíciles del desarrollo de software se deben al hecho
de que la
esencia de un programa informático es un conjunto de conceptos
reracio-
nados entre sí: conjuntos de datos, relaciones entre conjuntos
de datos,
algoritmos y funciones. Estos conceptos son muy precisos y tienen
mu-
chos detalles. Según Brooks, laparle dificil del desánollo
dei software es
espe,cificar, diseñar y comprobar estos conceptos en sí mismos.
Otro Brooks, Ruben Brooks, ha publicado un estudio que sugiere que
se necesitarían decenas de miles o incruso cientos
de miles de reiglas para
productividad
Capítulo 15: Herramientas para aumentar Ia
capturarelconocimientodeundesarroliadorexperto(Brooks,l911).
con todas esas reglas en un
Cu'p,.rrut el producto final obtenido a1 pensar
del software'
lenguaje de programación es la parte fácil de1 desarroilo
Pen"sarias inicialmente es 1o que resulta dificil'
extremadamente precisos
El hecho de que lo, prog'u-as sotlware sean
software son
y tengan muchos detalies io t'u u cambiar' Los programas
y no menos' Alguien tiene
cadavezmás precisos, detallados y complejos'
conceptuai de cualquier nuevo programa informá-
que pensar er-, lu
"sen"ia antiguo programa informático' Esta
ii.o'o .outquier cambio a c"álq"ier de1 progra-
persona tiene que comprender tudu d"tull" de la funcionalidad
cómo están relacionados todos esos detalles
ma, y tiene q.t.
"o-p,""der
entre sí. Comprender esto resulta difícil, es propenso a errores y requiere
uno
necesario paraalcanzar este conocimiento es
-rr"fto tiempo. El tiempo necesario para completar un
de los componentes principales de1 tiempo
proyecto de desarrollo de software'
reducción drástica en ei
Fred Brooks sostiene que para alcanzar una
tiempodedesarrollo,deberíasurgirunanuevatecnologíaquesimplifica-
ralaesenciadeldesarrollodesoftware;estoharíamuchomásfácilformular
que configuran un programa
el conjunto de conceptos interrelacionados
más incida una tecno-
informático. Como r.gtu A" sentido común' cuanto
de software, mayor será
logía en las dificultadls esenciales del desarrollo
el esfuerzo que Podrá ahorrarse'
mucho esfuerzo'
REFERENCIA Un compilado, J" un lenguaje de alto nivel ahorra
CRUZADA porqrr. lleva el conjunto de conceptos sobre los que tiene que
"o*pt"to a lo largo de
sobre lenguajes de i"rrpur.. a un nivel'más alto' Ésto es 1o que se ha conseguido
mayor nivel'
desarrollo ráPido, los años con ei.u,,'UJo a los lenguaj., á. ptogtumación-de
consulte el CaPítulo 31'
E1 cambro de lenguajes de bajo
el ensamblador' a los lengua-
.Lenguajes Para "iu"i, "o*o
desarrollo ráPido jesdealtonivel,comoelCy"Pascai,ieliberadetenerquepensarsobrelo
ejecuta su programa' El
(LDR)"
que está haciendo lu -aquiáu subyacente cuando
como Delphi' PowerBuilder
iuro u 1os lenguajes de programaciónrisual
'y permitiéndole ol-
iiruut gusiJ oi."c. u" rip-o similar de simplificación.
vidarsedemuchasdelastareasrealizadasenunentomodel.entanascuando
ejecuta un programa en un entorno gráfico'
conceptual (la parte
Las herramientas que no se dirigen a la esencia
Un editor de programas sólo
dura de la programacibn) no ayudan tanto'
rápido; es útii'
ayuda un po"o, po.-qrr" t" pt'Áitt escribir e1 código más
pero no se centra.niu de aquello que hace difícil el de.sarrollo de
""""iu
software. Esto mismo es cierto pu'u1u' herramientas
de control de código
herramientas automá-
fuente, depuradores, controladtres de ejecución'
ofrecen incrementos de
ticas de prueba, erc'; estas herramientas sólo
productividad Por la misma razón'
y bibliotecas de códi-
Las herrami",'tu, tul", como herramientas CASE
lenguajes de alto
go o de clases están en un punto intermedio entre los
nivelylasherramientasdecodificaciónensucapacidadparameiorarla
378 l:,.a".s,,: y gest¡on de proyectos informáticos
productividad; se dirigen a la raiz del problema, pero ra mayoría ¿; : ].uu

no 1o hacen con mucho énfasis.
Fred Brooks señala que nuestra industria ha llevado a cabo ur; -i:-.5ü
búsqueda de una panacea universal para resolver el problema de ," :u;¿
productividad. Alejandro Magno decayó porque ya no le quedab-- .,iur
mundos para conquistar. En 1987, Brooks aseguró que aunque 3:--: dü.
había hecho antes, no había ninguna tecnología o método qu-.-,r**

producir una mejora de un factor de 10 en la productividad en 1a sr=-,:m
década. Recomponiendo un poco estas cifras, Brooks estaba dicie:,:: ¡:r,u
ninguna herramienta o técnica podría producir una mejora de la :::*^.
tividad de un 25 por 100 anual durante diez años. ocho años c:.:,r.*".
en 1995' él reafirmó este hecho, y creo que está en 1o cierto. D::,=::L*¡'
darnos por satisfechos cuando métodos y técnicas individuales g--:a!r
mejoras en la productividad inferiores aun25 por 100 anual, o bien:,-,x-
mos buscar combinaciones de métodos y tecnologías para tener la fi,:.-.r*
nidad de una mejora mayor.
Áreas de especial aplicación

REFERENCIA Las herramientas de productividad tienden a centrarse en la construc;':,r
CRUZADA
Para más detalles del software. su efectividad en el soporte del desarroilo rápido depend; *
sobre la parte de un grado en que su proyecto esté dedicado a la construcción del sol¡r
proyecto dedicada a la -:
construcción, consulte ¿cuál es el tamaño de su proyecto? ¿cuál es el grado de complicacici:- -r*
la Sección 6.5, su proyecto? ¿Qué parte del ciclo de vida está ocupada por la consi:-:-
" Distribución del ción del software? Algunos tipos de proyectos son más r¿ciles de sopo:--1,:
tiempo empleado..
que otros.
Aplicaciones orientadas a sGBD. Las aplicaciones de bases de da::s

están bien soportadas por las herramientas de productividad en práctic"-
mente todas las plataformas. Existen herramientas de productividad c::
permiten generar esquemas de bases de datos, generar consultas, formate¿:
informes, crear pantallas de entrada de datos y demás. Si necesita des"-
rrollar 100 pantallas de entrada de datos para su uso con una base de datos.
no puedo imaginarme la codificación de ese tipo de cosas a mano, porqu.
hay muchas herramientas excelentes de bases de datos (como visual For-
Pro, Access, PowerBuilder, CA Visual Objects, FileMaker, Focus y muchas
herramientas cASE) que resuelven el trabajo repetitivo de este pror.ro
Aplicaciones personalizadas. Los lenguajes de desarrollo rápido

funcionan bien para pequeñas aplicaciones en rai que el entorno del dise-
ño está perfectamente determinado. Si su cliente va a ser feliz con formatos
estándar de entrada de datos, gráficos estándar, informes estándar (en resu-
men, con una aplicación que se parezcamucho a otras aplicaciones),
enton-
ces debe poder desarrollarla en un 4GL o en un lenguaje de programación
Capítuto 15: Herramientas para aumentar la productividad 379
visual. En muchos proyectos de software personalizados, por no decir en

su mayoría, el cliente no pone ningún reparo en aceptar algunas limitaciones
en el aspecto a cambio de un tiempo de desarrollo mucho más rápido.
Prototipos desechables. Los lenguajes de desarrollo rápido resultan

muy adecuados para el desarrollo de prototipos desechables de interfaz
de usuario. Hay que estar prácticamente loco para desarrollar un prototi-
po desechable en C/C++ o en Pascal hoy en día. Puede desarrollar el nú-
cleo de un prototipo evolutivo en esos lenguajes, para poder ampliarlo
posteriormente, pero es dificil imaginar el uso de cualquier herramienta
iirtitrtu de un lenguaje de programación visual para llevar a cabo rápidas
iteraciones de un diseño de interfaz de usuario que piensa desechar poste-
riormente.
En general, cuanto más pequeña y sencilla sea la aplicación, más va-
liosas resultarán las herramientas para la productividad. En proyectos
pequeños, la mayoría del proyecto se dedica a la construcción de código,
qu" la parte mejor soportada generalmente por estas herramientas. En
",
proyectos-más grandes, la parte del proyecto dedicada a la codificación es
*"nor, por lo que la posible contribución de 1as herramientas de desarro-
llo rápiáo, centradasin el código, será menor.
Limitaciones de las herramientas para productividad

<<Dar tres pasos adelante y dos pasos atrás> es algo inevitable con 1as he-
rramientai para productividad. Las herramientas para productividad le
ayudan, y las herramientas para productividad le dan problemas'
En un proyecto, mi equipo utilizó una biblioteca de clases de interfaz
de usuario para ei entorno de Microsoft Windows. Generalmente, el uso de
la biblioteca de clases simplificaba nuestlo trabajo. Pero luego llegamos a
una parte del proyecto en la que se suponía que debíamos copiar gráficos
de nuestra aplicación al portapapeles en un <formato de metaarchivo>
(metafile). Lá biblioteca de clases anunciaba el soporte de metaarchivos,
y ,u áo",t-.ntación técnica decía que los gestionaba. Pero cuando inten-
ri
iu-o* ,raur metaarchivos, éstos no funcionaban. Nuestros metaarchivos
¡ de pantalla completa se reducían a 1 cm2.
Después de muchas llamadas a la empresa de 1a biblioteca de clases y
!(
#1 a Microioft, concluimos que tanto Microsoft Windows como la biblioteca

de clases contenían errores en la manipulación de metaarchivos. Enton-
ces necesitamos varios días para diseñar y codificar una solución a este
problema. Cuando nos pusimos afiabajar con los metaarchivos, eslábamos
ian plenamente comprometidos con nuestro diseño, que no teníamos real-
*"ttt" ninguna otra alternativa que codificar la costosa solución encontrada
en la forma en que lo hicimos.
Al final, ahorramos mucho tiempo usando la biblioteca de clases. Pero
-G\
]les€rro,irro y gestión de proyectos informáticos
en lo que respecta a los metaarchivos, si hubiéramos conocido al pri:;,-

pio que el soporte de los metaarchivos no era correcto, habríamos diseñ.¡:
nuestro programa de forma distinta, y no habríamos perdido tanto tiern:,:
No he visto ningún estudio sistemático del tema, pero mi mejor e=::-
mación es que si piensa usar una herramienta para productividad. ce:rt
añadir alrededor del25 por 100 del tiempo total que espera trabajar cor _-r.
herramienta para usarlo diseñando soluciones para las limitaciones d¡ ;
herramienta. siempre hay cosas que resultan más difíciles de llevar a c:r:
cuando se usa una herramienta, y en ocasiones la propia herramienta :::-
ne defectos.
Papel definitivo de las herramientas para

productividad en proyectos de desarrollo rápido
cuando se sopesan las ventajas e inconvenientes del uso de herramieni-¡
para productividad, el argumento para insistir en el uso de herramientas pa::
DATOS REALES
productividad en proyectos de desarrollo rápido no está nada claro. En' -
estudio sobre 10 proyectos software seleccionados por varias organiz.-
ciones como sus mejores proyectos, Bill Hetzel dedujo que <los mejor;=
proyectos no utilizan necesariamente metodologías de última generacir-
ni hacen un amplio uso de la automatización y de las herramientas. S;
basan en principios generales como un equipo de trabajo compacto. cc-
municación entre las áreas del proyecto y controles del proyécto. L:.
buena organización y gestión parecen ser un factor mucho mái importa:-
te para el éxito que la tecnología> (Hetzei, 1993). Hay otros estudios cur,
conclusión ha sido que las herramientas para productividad constitur ¡-
sólo una contribución secundaria al nivel general de productividad de un
organización (Zelkowitz et al., 1984; Zawacki,l993).
charles Symons refuerza esto cuando informa de que hay tantas i'-
fluencias distintas en una planificación de softwar" qu. ,.ro existe ningú:
dato claro que soporte la afirmación de que ros proyectos que usan 1ec-
guajes de cuarta generación son entregados más rápido qr. Lo, proyecro:
que usan lenguajes de tercera generación (Symons, l99l). Esto no quie::
decir que no existan fragmentos de funcionalidad de esos proyectos qur
no se desarrollen más rápido, sino que las variaciones signiiicátivas en
-¿
planificación se deben con mayor frecuencia a diferencias en la progra-
mación, gestión, especificación de requerimientos y muchos otros fact¡-
res que a la tecnología usada para construir el sistema.
En un estudio llevado a cabo durante l7 años sobre más de 100 expe.-
mentos con proyectos en marcha y 50 tecnologías, el Laboratorio de Inge-
DATOS REALES niería del Software de la NASA concluyó qu. lur mejoras se caracterizar
por un cambio continuo, sostenido y metódico. No debemos esperar
can-
bios tecnológicos o depender de ellos (Glass, 1993).
Capítulo 15: Herramíentas para aumentar la productívidad
Las herramientas para productividad recién salidas al mercado pue-

denjugar un papel importante en la reducción de las planificaciones de
desarrollo, pero debemos mantener su papel en un plano adecuado. Por sí
mismas, no son ni necesarias ni suficientes para alcanzar un desarrollo
rápido.
15.2. Estrategia de las herramientas para productividad

En contra de 1o que suele ser habitual, es mejor tratar el uso de herramien-
tas como una cuestión estratégica, a largo plazo, envez de como un tema
a corto plazo, una cuestión fáctica. El uso de herramientas no es una solu-
ción a corto plazo, porque se necesitan tiempo y dinero para adquirir y
manejar las herramientas de forma efectiva. Si no emplea tiempo y dinero
en ellas, entonces estará desperdiciando tiempo y dinero usando herra-
mientas que al final no encontrará efectivas. Las nuevas herramientas (no
sólo nuevas para usted, sino nuevas) introducen incertidumbre en la calidad
y en la planificación. No es una casualidad que al estado del arte se le
denomine <el filo de la actualidad>.
El uso de herramientas no tiene por qué ofrecer ninguna ventaja com-
petitiva. Las herramientas suelen ser respaldadas por una fuerte publici-
dad, 1o que implica que cualquier herramienta de la que hayamos oído
hablar será conocida también por nuestros competidores. La ventaja
obtenida al pasar a otra herramienta es ei tiempo transcurrido entre e1
momento en que comienza a usarla adecuadamente y el momento en que
sus competidores comienzan a usarla. Cambiar a una nueva herramienta
es más fáci1 que muchos de los restantes medios existentes para mejorar
la velocidad del desarrollo, y esto implica que todo el mundo estará per-
fectamente motivado a cambiar a las nuevas herramientas, como usted
lo está. Las ventajas estratégicas, a largo plazo, vienen de mejoras en el
personal, el proceso y el producto. Estar al día en las herramientas
de productividad forma parte del juego, pero no le va a dar una baza ga-
nadora.
Si usa las nuevas herramientas de forma desorganizada, los beneficios
que recibirá de ellas serán poco consistentes. No se puede sacar mucha
ventaja al confiarse a una herramienta tres meses antes de la competencia
si resulta que se adopta una herramienta poco útil tres meses antes que
ellos. Pero, como muestra la Figura 15.1, si puede encontrar un método
para usar solamente buenas herramientas, y si puede hacerlo cotrectamente
antes que la competencia, esto le ofrecerá una ventaja competitiva estra-
tégica y continua.
IJna estrategia efectiva parala adquisición e impiantación de nuevas
herramientas debe incluir los siguientes elementos:
w. Desanollo y gestión de proyectos informáticos
Ahorro teórico máximo
Aumento
del uso
y del ahorro
Adopción lenta
Tiempo
Figura 15.1. Una estrategia efectiva de trabajo puede rnaximizar las ventajas
mediante una adopción rápida y sistemática de nuevas herramientas. Pero
también debe evitar pérdidas de productividad debidas a la adopción de
he rra m ie ntas in ef icace s.
¡ Identificación temprana de nuevas herramientas interesantes.

o Evaluación ágil y precisa de las nuevas herramientas.
o Implantación de las nuevas herramientas que demuestran ser efi-
caces.
¡ No utilizar las nuevas herramientas que resultan ser ineficaces.
¡ Continuar confiando en herramientas anteriores y comprobadas.
Si desarrolla un programa con estos elementos dentro de su organiza-

ción, adquirirá una ventaja estratégica competitiva. Adoptará las nuevas
herramientas de calidad más rápidamente. Evitará la pérdida de producti-
vidad asociada con la adopción de herramientas erróneas. Y a lo largo del
tiempo, contribuirá a su éxito con el uso continuado de herramientas anti-
guas y probadas. Las siguicrftcs secciones describen cómo implementar
este tipo de programas, y el Ejemplo 15.2 del final de este capítulo ilustra
un programa de este tipo.
15.3. Adquisición de herramientas para productividad

Las organizaciones que tienen métodos aleatorios o casuales para adquirir
herramientas software, desperdician alrededor del 50 por 100 de todo el
DATOS REALES
dinero que gastan en herramientas. Peor aún, las malas inversiones en
herramientas van asociadas con planificaciones largas. Las organizacio-
nes que utllizan estrategias formales de adquisición pueden reducir esta
pérdida a un l0 por 100 y evitar los problemas de planificación asociados

(Jones, 1994).
Aquí tenemos algunos problemas habituales con la adquisición de
herramientas:
areLrooRnpin ¡ El mercado de herramientas software es propicio a reclamos exa-

ADICIONAL
gerados y sensacionalistas.
sobre los problemas ¡ La adquisición de malas herramientas interfiere con la adquisición
asociados con la
de mejores herramientas.
adquisición de
henam¡entas, véase El 30 por 100 de las herramientas adquiridas no cubren suficiente-
Assessment and mente las necesidades de los usuarios para ser efectivas.
Control of Software
Fr.sks (Jones, 1994). a El 10 por 100 no se utilizan nunca unavez adquiridas.
a El 25 por 100 se usan menos de 1o que deberían a causa de la falta
de formación.
El 15 por 100 son seriamente incompatibles con las herramientas
existentes, y exigen ciertos tipos de modificaciones para adaptar la
nueva herramienta dentro del entorno deseado.
El coste definitivo de una henamienta sólo tiene una mínima relación

con su precio de compra. El esfuerzo de aprendizaje y las ganancias o
pérdidas de eficacia son mucho más importantes para determinar el coste
durante la vida de una herramienta que su precio de compra.
Plan de adquisición
Una organización que espera para buscar una herramienta hasta que la
necesita ha esperado ya demasiado tiempo. La evaluación y búsqueda de
herramientas debe ser una actividad continua.
Grupo de herramientas
Un método efectivo y continuo consiste en identificar una persona o grupo
como responsable de la distribución de información sobre las herramientas
software. Dependiendo del tamaño delaorganización, esta persona o grupo
puede tener asignadas responsabilidades sobre las herramientas a tiempo
completo o parcial, y debe ser responsable de las siguientes actividades:
Recogida de información. El grupo de herramientas debe estar a la

última en 1os avances del mercado de herramientas y la información rela-
tiva a las mismas (nuevos informes, publicidad, estudios comparativos,
información anecdótica suministrada por los usuarios de las herramien-
tas, discusiones por Internet, etc.).
Evaluación. El grupo debe evaluar las nuevas herramientas a medida

que estén disponibles. Debe mantener una <<lista recomendada> de herra-
I
384 )esa,rotio y gestión de proyectos informáticos
mientas para su uso general. Debe controlar el funcionamiento

ür :'&m
herramienta en proyectos grandes, pequeños, cortos' largos
y dem:' -'t'-
pendiendodeltamañodelaorganización,podríarecomendarherr¿:-.:u*
z-'-u'l
iu, puru ser usadas en proyectos piloto a modo de prueba' monitor
estos proyectos piloto para identificar buenas y maias
herramientas
nigrupo de herramientas debe continuar evaluando nuevas Yer:-:tr*
Co- "u'
de las ñeriamientas que anteriormente no han sido satisfactorias' '
veces la gente desarrolla bloqueos rn-I---¡:'is!
luaciones menos formales, a
respectoalasherramientasconlasquehatenidomalasexperie::-¡=
Rechazarán la versión 5 de una herramienta porque
la versión 2 tur ¡. :lux,
problemas que la que eligieron, ignorando que las versiones 3' 4 ¡ i r
su propiu herramienta también han tenido sus problemas'
Coordinación.Losdistintosgruposdeunaotganizaciónpueden::'*
probar todt-: 'ü
bar nuevas herramientas' pero sin coordinación podrían
misma herramienta. Puedó haber seis nuevas herramientas prometed¡:hi
que sólo se p:-i-
y seis grupos para probarlas, pero sin coordinación puede
grupos podrían ha:::
úen trJs de lai seis herramientas. Algunos de estos
encontrado perfectamente satisfactoria una de las tres
herramientas ::
debe coordinar la experimentación ¡:
fráuuAu.. Ei grupo de herramientas
las mismas lecc::*
herramientas, para que estos grupos no aprendan todos
nes de forma tan dura, y qrr" lu otgunización aprenda el
máximo posir.=
de forma eficiente.
Diseminación. El grupo de herramientas debe llevar la informaclon '

lagentequenecesita-informaciónsobrelasherramientas.Elgrupodeb.
*át.rr"rlrrformes sobre las experiencias de los distintos gfupos con cai"
grupos qL'
herramienta, y poner dichos informes a la disposición de otros
están planteán¿-os" et uso de una herramienta determinada. Si la organizz-
herramients-'
ción es suficientemente amplia, podría publicar un boletín de
resultados del uso de herra-
mensual o bimestral que iáformara sobre 1os
grupos para convertirse en grupo!
mientas en proyectos piloto, y solicitara
Esto podría facilitar la comuni-
fito,o O. tas nárra*ientas en evaluación. quizás mante-
cación informal entre diferentes usuarios de herramientas,
niendo presentaciones mensuales de herramientas nuevas en el almuerzc
o bien moderando discusiones en boletines electrónicos'
Riesgos de establecer un grupo de herramientas

Implantar un gfupo centralizado de herramientas implica varios riesgos, ¡'
peot e, el .ic"so de control. Es importante que el grupo de herramientas
,eóoja y distribuya información sobre herramientas eficaces; sin
"1 embar-
grupo tióne que soportar el desarrollo rápido, no debe permitirse
go, ,i
"1 que insisten en
éncasillaise en estándares burocráticos de la organizaci1n
que todos los grupos deben ]gltilizar únicamente las herramientas que han
(aprobado)).
El grupo de herramientas debe estructufarse como una organización de
servicios en lugar de un organización de normativas. El trabajo del gru-
po de herramientas consiste en ayrdar a aquellos que trabajan en pro-
yectos reales para que hagan mejor su trabajo. Las personas que trabajan
al pie del cañón en sus proyectos saben mejor lo que necesitan. El grupo
de herramientas puede elaborar recomendaciones, dar consejos y ofrecer
soporte, pero sus ideas sobre las herramientas a utilizar no deben prevale-
cer Sobre las conclusiones de las personas que tienen que uSaI realmente
las herramientas.
El grupo de her:ramientas necesita estar formado por personas cuyas
recomendaciones sean escuchadas. Si el grupo tiene poca prioridad y está
compuesto por desarrolladores frustrados, las recomendaciones del grupo
pueden ser ignoradas y posiblemente por muchas razones.
Criterios de selección
REFERENCIA Esta sección contiene criterios a usar en la adquisición de sus herramien-
CRUZADA
tas. Puede utlTizar estos criterios en el contexto de un grupo de herra-
Las consideraciones
sobre la selección de mientas, o paru la evaluación de una herramienta específica para un pro-
heframientas se yecto determinado.
solapan con las
consideraciones a la
hora de seleccionar BeneficioS estimados. Lo más importante para un proyecto de desa-
desarrollo externo.
Para ver estos rrol1o rápido es estimar la eficiencia que se espera ganar usando una herra-
criterios, consulte el mienta determinada. A menudo esto resulta dificil de medir, y por fazones
Capítulo 28,
descritas detalladamente a lo largo de este capítulo, debe estimarse de
"Desarrollo externo".
forma conservadora.
Una buena noffna consiste en suponer que cualquier vendedor que
diga que puede mejorar la productividad en más de un 25 por 100 a1 año
usando una única herramienta no es consciente de lo que dice, o está
mintiendo (Jones, 1994). Puede decidir lo que debe hacer con un vende-
dor que proclama tales cosas; algunas personas evitan totalmente tratar
con ellos.
Estabilidad del vendedor. Su futuro depende del futuro del vendedor

que suministra las herramientas. ¿Cuánto tiempo 1leva en el negocio la
empresa del vendedofl ¿Cuál es su estabilidad? ¿Cómo están de compro-
metidos con la herramienta de interés específico? ¿La herramienta entra
dentro de la línea principal de trabajo del vendedor, o es un pfoducto prepa-
rado? ¿La herramienta podría ser soportada por otra empresa si el vendedor
actual deja el negocio?
Si le preocupa la estabilidad del vendedor y sigue est¿ndo interesado
en la herramienta, debe considerar lo que hara si el vendedor deja el nego-
j' Eest¡ón de proyectos informáticos
cio. ¿Necesifarála herramienta para más de un proyecto o versión.. ¡:

mantener la herramienta por sí mismo? ¿Le suministrará el vende¡:n slli
código fuente? Y si es así, ¿cuál es el nivel de calidad de dicho u-i,.r,.Nr
fuente?
calidad. Dependiendo del tipo de herramienta que esté busc¿:,rr

puede que la calidad de la herramienta del vendedor determine la ;.. r*
dad de su programa. Si la herramienta del vendedor es mediocr¡. ;¡,
programa será mediocre. Si la herramienta del vendedor es lenta, su l.x*
grama será lento. compruebe las ruedas del carro del vendedor ante: tr
subirse en é1.
Madurez. A menudo, la madurez de una herramienta es una buena i:_:*

cación de su calidad y el compromiso del vendedor. Algunas organ-:jF
ciones rcchazan comprar la versión 1 de cualquier herramienta de un nr:-
vo vendedor (sin importar lo buena que digan que es) porque hay demasi.rl
riesgo en el desconocimiento de la calidad e, independientemente de -¡s
buenas intenciones del vendedor, una capacidad desconocida para su D-:-
manencia en el negocio. Algunas organizaciones siguen la <regla de .l
versión 3>.
A menudo, la versión 1 es simplemente el código de prototipado a1g_
evolucionado. El objetivo del producto no resulta demasiado claro, r i-:
puede estar seguro de la dirección que va a tomar el vendedor en futur¡.
versiones de la herramienta. Podría comprar la versión I de una biblio¡¡-
ca de clases porque todo el énfasis del vendedor se centra en el reni--
ERROR CLASICO miento, descubriendo posteriormente que en la versión 3 el vendedor h"
desplazado su interés hacia la portabilidad (con terribles consecuencia.
para el rendimiento).
Generalmente la dirección del producto es más certera en la versión l.
pero en ocasiones la versión 2 es simplemente una versión con los errore:
corregidos, o presenta el efecto de un segundo sistema: los desarrollado-
res le incluyen todas las prestaciones que deseaban introducir en la primer"
versión, afectando a la calidad del producto. La dirección del product
puede seguir sin estar clara.
Frecuentemente, la versión 3 suele ser la primera versión estable r
utilizable de una herramienta. cuando sale la versión 3, generalmente ei
objetivo del producto está claro, y el vendedor ha demostrado que tiene 1a
fuerza necesaria para continuar desarrollando su producto.
Tiempo de formación. considere si arguien que va a usar la herra-

mienta tiene experiencia directa con ella. ¿Arguien de su equipo ha asisti-
do a un curso de formación? ¿cuál es la disponibilidad de los programa-
dores libres que saben urllizar la herramienta?
¿cuánta proáuctividad
perderá en la curva de aprendizaje?
Capítulo 15: Herramientas para aumentar Ia productividad 387
REFERENCIA
CRUZADA
Aplicabilidad. ¿La herramienta es realmente aplicable a su trabajo, o
Dara más información tendrá que forzar su adaptación? ¿Puede aceptar los compromisos que
sobre el diseño por implica una estrategia de diseño por herramientas? Usar una estrategia de
herramientas, véase
la Sección 7.9,
diseño por herramientas está bien. Sólo tiene que asegurarse de hacerlo
"Diseño por con los ojos bien abiertos.
herramientas".
Compatibilidad. ¿La nueva heramienta funciona bien con las herra-

mientas que ya está usando? ¿Restringe la selección de herramientas en
un futuro?
Ámbito de crecimiento. Además de la dirección en la que sabe que

desea enfocaf su producto, ¿la heramienta soportará las direcciones en
las que podría desear encavzar su producto?
Los proyectos software tienden por naturaleza a expandirse más allá
de su ámbito original. Participé en un proyecto en el que el equipo tenía
que elegir entre un software doméstico de gestión de bases de datos y
SGBD comercial. El ingeniero que estaba a favor del gestor comercial de
bases de datos decía que bajo fuertes cargas de datos, era probable que el
ERROR CLASICO SGBD comercial funcionara varias veces más rápido. El ingeniero que
estaba a favor del sGBD doméstico insistía en que no había ningún requi-
sito de velocidad de procesamiento, de forma que la consideración del
rendimiento era irrelevante. Al seleccionar el SGBD doméstico en lugar
de su competidor más potente, la empresa no tenía que pagar la corres-
pondiente licencia, por lo que fue la opción seleccionada.
REFERENCIA Al final, la empresa no tuvo que pagar la licencia para usar el SGBD
CRUZADA
doméstico, pero pagó, pagó y pagó aún más. Aunque el SGBD doméstico
sobre los ámbitos de había funcionado de forma razonablemente rápida con pequeñas bases de
crecimiento, véase datos de prueba,bajo cargas de datos completas funcionaba con lentitud.
. Def inición de familias
de programas", en la Algunas operaciones comunes tardaban más de 24 horcs. En vista del ren-
Sección 1 9.1 . dimiento recibido (¡sorpresa, sorpresa!), tuvo que añadirse un requerimiento
de velocidad. Para entonces se habían escrito miles de líneas de código
para usar el software de bases de datos doméstico, y la empresa no podía
permitirse reescribir su software para SGBD-
Evite seleccionar una heramienta que sólo sirve mínimamente para
reahzat el trabajo.
Personalizac¡ón de los criterios de selección. Al definir un conjunto

de criterios para usar en la selección de herramientas, asegúrese de que
compra las herramientas según sus propios criterios en lugar de los criterios
de otros. Está muy bien leer comparati\¡as para ver las cuestiones impli-
cadas en el uso de una clase particular de herramienta, porque a menudo
se descubren aspectos importantes en los que no había pensado. Pero una
vez que haya visto cuáles son los aspectos a tener en cuenta, decida por sí
mismo lo que le importa. No añada criterios a su lista únicamente porque
I
I
I
)es..'3, a l, gestión de proyectos informáticos
los escritores de la revista los tienen en sus listas. Lo más probable es ;r,r
ni siquiera la mitad de las cosas mencionadas en un informe típico d; -:ru
revista sean de interés para cualquiera de sus proyectos individuales
Compromiso
Unavez que haya realizado la selección de las herramientas, comprc-:-
tase con ellas. No siga mirando sobre su hombro y preguntándose si al,¡-:u
otra herramienta hubiera resultado mejor. ¡Olvídese de las otras he=:¡
mientasl Como dice Larry O'Brien, <cuando el proyecto sufre su pr::-r
gran contratiempo, es natural preocuparse porque se está desperdicia-:l
esfuerzo. Todos los proyectos y todas las herramientas tienen un pr::r
gran contratiempo inicial> (O'Brien, 1995). No tiene que disfrutar ;-nr
los contratiempos, pero conciénciese de que encontrará algunos, sin -:-
portar lo buena que haya sido 1a selección de sus herramientas. Camb-¡r
de herramientas a mitad del proyecto sólo le garantiza que volverá a re:r-
otro gran contratiempo.
15.4. Uso de herramientas para productividad

IJna vez que haya desarrollado una estrategia efectiva de adquisic-i:
de herramientas, siguen quedando algunas cuestiones relativas al uso de -'¡
herramientas. La adaptación de las herramientas a los proyectos pu.::
tener un gran impacto en su capacidad de desarrollo rápido.
Guándo adoptar las herramientas

En un proyecto software, existe un equilibrio entre la curva de aprendiza_,-
que debe subir para familiarizarse con la nueva herramienta y la produci:-
vidad que gane una vez que se familiarice con ella. La primera vez q.r--
usa una nueva herramienta, a menudo se requiere más tiempo que si r:
hubiera usado ninguna herramienta. Se necesita tiempo parala formaciór.-
la experimentación, el aprendizaje de los puntos débiles de la herramien-*
(como en mi proyecto con los metaarchivos de Windows) y discusiones
entre los miembros del equipo sobre el uso para sacar el máximo partidr
de la herramienta.
Como sugiere la Figura 15.2, si espera que su proyecto dure tanto cor¡:¡
el proyecto B, puede esperar recuperar el esfuerzo de la curva de aprendi-
zaje. Pero si espera que su proyecto termine antes, como en el caso de-
proyecto A, sería mejor que no adoptara esa herramienta, al menos desde
el punto de vista de ese proyecto.
A nivel de organización, las consideraciones son un poco distintas. S:
siempre tiene proyectos cortos, como el proyecto A, y curvas de aprendizaie
Duración
Nivel de productiüdad
\- antes (]e
¿ürles introducir
de rfrtr(ruuqr
\ la nueva herramienta
ltA
Productividad
Productividad
Perdida
\* Productividad
N¡vel de productividad
con la nueva herramienl
(caída inicial debida a la
curva de aprendizaje)
Tiempo
Figura 15.2. Efecto de la curva de aprendizaje en la productividad. La

introducción de una nueva herramienta en un proyecto corto, como el
proyecto A, no le permite recuperar la productividad perdida en la curva de
aprendizaje.
para nuevas herramientas como la mostrada en la Figura 15.2, nunca podrá

justificar la introducción de una nueva herramienta en un proyecto indivi-
dual. Pero para mantener la capacidad de desarrollo a largo plazo de su
empresa, para continuar aumentando su nivel de productividad, en ocasio-
nes necesitará adoptar una nueva herramienta en un proyecto, aunque no
sea una solución completamente óptima para ese proyecto en particular.
Puede extraer dos conclusiones de 1o anterior de cara al desarrollo
rápido. En primer lugar, a largo plazo necesitará ir introduciendo nuevas
herramientas más eficientes para mejorar la productividad. No puede to-
mar estas decisiones basándose exclusivamente en lo que es mejor para
proyectos individuales. En segundo lugar, a corto plazo, un proyecto de
desarrollo rápido generalmente no es el proyecto adecuado para introdu-
cir una nueva herramienta. Cuando tiene prisa, es el peor momento para
tomar un nuevo camino. Seleccione un nuevo proyecto menos sensible al
tiempo, y cargue la curva de aprendizaje sobre dicho proyecto.
k
Importancia de la formación
Cuanto más potente es una herramienta, más dificil puede ser utilizarla de
forma efectiva. Sin la formación adecuada, las herramientas que podrían
ofrecer una productividad significativa se quedan en las estanterías, sin
utilizarse. Wayne Beardsley lo cuenta de esta forma:
eRRoR clÁsrco Piense en nuestra empresa de software como en üla empresa de construc-
ción. Nuestro trabajo consiste en cavar una zanja desde la calle hasta una
casa de campo situada a cinco millas. Hemos comprado el último adelanto
390 Desai'ro/io y gestión de proyectos informáticos
en excavadoras para el equipo de trabajo. En un día de trabajo nonna-- r$

trabajadores van en la excavadora desde la calle hasta el final de la a.;¿-
se bajan, y usan las palas que transpoftan con la excavadora para .-:r'nr
algunos metros. Al final del día, se suben de nuevo en la excavadLr:: l
vuelven a la calle. Quizás deberíamos explicarles que la excavadora n¡ ,r
había comprado para su desplazamiento. (Beardsley, 1995.)
Esta analogía encaja perfectamente con muchos proyectos soft$'ari
Reducción real¡sta del plan

Ningún método se lleva a la práctica en el vacío, y el entorno en el q-c
se utiliza es fundamental ala hora de determinar su éxito (Basili y McG*
rry, 1995). La productividad anunciada por los vendedores es genera-
mente el potencial máximo de un método en un entorno ideal; tiene ql=
probarlo para ver lo bien que funciona en su entorno.
Para estimar la producción de la planificación que cabe esperar ¡f:
una herramientapara productividad, piense en términos del ciclo de ric:
completo que va a usar, y entonces determine el esfuerzo que espera ahra
rrar durante cada parte del ciclo de vida.
REFERENCIA Suponga que piensa usar un lenguaje de cuarta generación (4GL), comc
CRUZADA
Para más deta¡les sobre
Focus, Visual Basic o Delphi, para el 50 por 100 de su sistema dentro d¿
el modelo del ciclo de un ciclo de vida clásico, en cascada. Suponga además que espera que e.
vida en cascada, véase proyecto tenga unas 32.000 líneas de código si se implementa completa-
la Sección 7.1 ,
"Cascada pura".
mente en un lenguaje de tercera generación (3GL), como C, Basic o Pas-
cal. La Tabla 15.1 muestra aproximadamente la descomposición de este
tipo de proyecto por actividades.
Cambiar a un 4GL es una de las formas más poderosas de usar las
herramientas de productividad en su provecho. Las estimaciones varían.
DATOS REALES
pero el paso de un 3GL a un 4GL puede reducir generalmente su esfuerzo
de codificación en un 7 5 por 1 00 o más (Jones, I 995). Puede esperar reduci¡
su esfuerzo de diseño en la misma magnitud (Klepper y Bock, 1995).
Desafortunadamente, este ahorro del75 por 100 en el diseño y la codi-
ficación no se traduce en un ahorro del 75 por 100 en la planificación.
En el ejemplo, sólo se implementa en un 4GL el 50 por 100 del programa.
por lo que el ahorro del 75 por 100 sólo se aplica a este 50 por 100. Además.
el ahorro no se aplica a todas las actividades de diseño global, prueba
individual o prueba del sistema, y se aplica sólo parcialmente a la integra-
REFEFIENCIA
ción. En conclusión, al final se obtiene una reducción de alrededor de un
CRUZADA 20 por 100 en el esfuerzo como resultado de usar un 4GL en el 50 por 100
Para más detalles de su programa.
sobre la relac¡ón entre
esfuerzo y Por desgracia, aún no hemos terminado de recortar el ahorro. Una mujer
planif icación, consulte puede tener gemelos en nueve meses, pero esto no significa que pueda
la Sección 8.5,
.Estimación de la tener un niño en 4 meses y medio. El ahorro en el esfuerzo no se trasrada
planif icación
". directamente en reducción de la planificación. Este ahorro del 20 por 100
l
capíturo 15: Herramientas para aumentar ra productividad

3g1
REFERENCIAS Tabra 15'1' Ejempto ag!gnoyg obtenido ar pasar
CRUZADAS de 3GL a 4GL ta mitad
Las estimaciones de de un proyecto con 32.000 LDC
esfuerzo de esta tabla
están derivadas de los
datos de la Tabla 8.10,
Esfuerzo Ahorro Esfuerzo
"Planif icaciones Actividad nominal esperado
nominales". Las (personas- por Expricación
estimaciones de
[111"'"r-
mes) actividad mes)
planificación están
calculados usando la Arquitectura
Ecuación 8.1, descrita 0% Se requiere el mismo
(diseño de
en la Sección 8.S. nivel de arquitectura.
alto nivel)
Cualquier ahorro sería
anulado por la necesidad
de conjugar el uso de
lenguajes 3GL y 4GL.
Diseño 38% 75o/o de reducción del
detallado
50oA del programa
codificado en 4GL.
Codificación/ 38% 75% de reducción para el
depuración
50% del programa
codificado en 4GL.
Prueba 0% Se requieren las mismas
de unidades
pruebas de unidades para
la misma funcionalidad.
Integración 6 30% 7 5o/o de reducción por la
parte codificada en 4GL,

pero la integración extra
necesaria para combinar
3GL y 4GL cancela
parcialmente este ahorro.
Prueba 6 0% Se requieren las mismas
del sistema pruebas del sistema para
1a misma funcionalidad.
Esfuerzo total 40 20% 3Z

(personas-mes)
Ahorro en la planiJícación
Planificación 10,3 g% q{
esperada
(duración
en meses)
enel esfuerzo se traduce sólo a un g por r00 de ahorro en ra planifica-

c10n.
Y ahora vienen realmente las malas noticias. Este
ejemplo no incluye
el tiempo necesario pararaespecificación de requerimientos
o ra curva de
::rrl i.
¡,,.1.'
392 ):sz": : ',' gestión de proyectos informáticos
porcentual al final dei tiemPo :'

aprendizaje. Si los incluye, el ahorro
proyecto sería incluso más pequeño' ¡Uf!
Esta i ;-
A continuación vamos u d'ut t't ejemplo más interesante'
,rrpo,lgu que está trabajando en la mtsma
ult]"u:1o1^d,tl:jtlltiillti:'
;:il';il;:".;"'i-ñ;"""'iu * un 4GL' La rabla 1j -
"omp1"tu-é"11
en este caso'
que puede esperar
ilustra el ahorro
Enestecaso,elahorro"'-t"'fu"t'oesimpresionante(unahorrogene::
sigue siendo un 23 por 1t'
del 55 por 100)' Pero .i;;;;" en planificación
no hay efecto de curva de aprenc
-
relativamente modesto, t"ponit"do que
de un 3GL a un 4GL es rli-:
,uüuro"iu¿o con e1 .u*Ulo at +Cl-'.nt paso
pasar de 3GL a 4GL todo un

REFERENCIAS Tabla 15'2. Eiemplo del ahorro obtenido al
CRUZADAS proyeclo con 32.000 LDC
Los esfuerzos
estimados en esta Ahorro Esfuerzo
tabla están derivados
Esfuerzo
de los datos de la nominal esperado final Expticación
Tabla 8.10' Actividad (personas- por (personas-
. Planif icaciones mes)
mes) actividad
nominales". Las
estimaciones de
80% El programa es tan
planificaclón están Arquttectura
pequeño que requiere
calculadas usando la (diseño
Ecuactón 8.1, descrita poca arquitectura.
de alto nivel)
en la Sección 8 5.
15oA de reducción debidcl
Diseño 8 ]s%
al paso del 3GL a1 4GL'
detaliado
'75oA dereducción debido
Codif,rcación/ 8 15%
al paso del 3GL al 4GL'
depuración "iltt
ooÁ Se requieren las mismas
Prueba
pruebas de unidades Para
de unidades
la misma funcionalidad
'75oA dereducción debido
lntegración 6 15%
al paso del 3GL al 4GL'
0o/o Se requieren las mismas

Prueba
pruebas de1 sistema Para
del sistema
la misma funcionalidad'
Esfuerzo total 40 55% 18
(personas-mes)
Ahorro en la
planíficación
1q
Planilicación 10,3 23o/o
esperada
(duración
en meses)
---
Capítuto 15: Herramientas para aumentar Ia productividad
de las mayores mejoras de productividad que puede realizar, pero aunque

pueda implementar completamente un programa en un 4GL, sólo reduci-
rá la planificación en un 25 por 100.
Puecle estar en desacuerdo con los porcentajes específicos de ahorro
estimados en estas tablas, pero no deje que eso enturbie los mensajes de
los ejemplos: es extremadamente difícil que cualquier herramienta de pro-
DATOS REALES
ductividad proporcione un 25 por 100 de reducción en 1a planificación, y
puede ignorar simplemente afirmaciones más ambiciosas. La mayoría del
ahorro real obtenido con las herramientas en general estará más de acuer-
do con el primer ejemplo, traduciéndose en ahorros de un 10 por 100 o
inferiores en la planificación. Muy pocas compañías de primera lila han
logrado mejoras de productividad entre un 15 y un 25 por 100 anual du-
rante varios años utilizando combinaciones de herramientas, y éste pare-
ce ser el límite superior (Jones, 1994).
Esia,se-cción,le ha cent;ado' en trrashei:r¡imientaspafa¡llc,rémenlar:la produp

tividad, pero los problemas asociados con ta aJopción de herramientas. la
fó¡tnación de,láspe1¡onas paralgu,usory la.ostimación del ahorro obtenido,
por el mismo r" upli.un también al uso de nuevas metodologias. La siguiente
ieCción,1Ambiéf es aplicable tanto a herramientas co¡11o a metodologías.
15.5. El síndrome de la Panacea

Érase una vez una pobre viuda que vivía con su hijo, Juan. Un día en el que
no tenían dinero para comer, la madre de Juan lo envió al mercado para
vender su vaca.
Yendo hacia el mercado, Juan encontró a un hombre mayor que le ofreció
cinco habichuelas de colores y un cuadrado de plástico por la vaca. Juan
era un buen chico, y 1o rechazó inicialmente, pero cuando el hombre le dijo
que las habichuelas brillantes y el cuadrado de plástico eran mágicos y
realmente valían por 10 vacas, Juan le entregó la vaca. El hombre puso las
habichuelas y el cuadrado de plástico en una caja de cartón y le dijo que
era una <herramienta CASE>.
Juan corrió hasta su casa para ver a su madre. <Le he dado la vaca a un
hombre que me he encontrado>, dijo Juan, <y éi me dio esto; es una "herra-
mienta CASE" y es mágica>. Abrió la caja de cartón y mostró a su madre
las habichuelas mágicas y el cuadrado de plástico.
<¡Habichuelas!>, gritó su madre. <Oh, Juan, esto no tiene nada de má-
gico. ¡Eres un tontol ¡Estamos arruinados!> Cogió la herramienta CASE y'
la arrojó por la ventana. Mandó a Juan a la cama sin ceuar.
394 Jesa"c \c !' gestión de proyectos informáticos
¿Qué pasó después de que Juan cambiaralavaca por una herram:.-:n¿

CASE? ¿Se convirtió la herramienta CASE en una planta de habichu:"rs
mágica? ¿O Juan perdió simplemente lavaca de su madre?
Indudablemente, el mayor riesgo asociado con el uso de herramie:---¿"
software es el síndrome de la panacea (silver-bullel): la creencia inge:-r
de que una única herramienta o tecnología va a reducir drásticamente ¡:n-
sí misma el tiempo de desarrollo (véase la Figura 15.3). Cambiar a -r
nuevo lenguaje de programación, probar una herramienta CASE,, pas¿t ,i
programación orientada a objetos, o adoptar un control de calidad tc:i
han sido ejercicios clásicos de buenas intenciones. El deseo de creer -
las panaceas resulta especialmente fuerte dentro de los proyectos de de-..
rrollo rápido.
Muchos de nosotros desarrollamos software porque creemos que 1:. *
algo inherentemente excitante en el software para computadoras. Cuani:

vemos una nueva herramienta software, no podemos evitar encontra:-¿
apasionante. ¡A quién le importa si es práctica! ¡Tiene barras de dcr-
plazamiento 3-D! ¡Y menús personalizables! ¡Mira! ¡Hasta emula Brie-
vi y EMACS! Las nuevas herramientas seducen a los desarrolladores;=
software, y creo que el síndrome de la panacea (silver-bullet) es un r ic.r
profesional. No estaríamos en este negocio si no fuéramos propensos :
creer que las herramientas software pueden resolver nuestros problemas
Espero que Abraham Lincoln estuviera en 1o cierto cuando dijo que
uno no puede engañar a todo el mundo todo el tiempo, pero a veces nuesr¿
industria parece estar decidida a demostrar 1o contrario. Los desarrolladore:
"Esta herramienta CASE es mágica.

Vale más de 10 de tus vacas."
Figura 15.3. AI tratar con los vendedores de herramientas, los

desarrolladores de software deben aprender a separar la verdad de los
cuentos de hadas.
de software son bombardeados con publicidad extravagante sobre la pro-

ductividad: <¡Reduzca su tiempo de desarrollo en un factor de 10!> (o 100
o 1.000). Capers Jones estima que ha habido falsas afirmaciones de produc-
tividad en prácticamente un 75 por 100 del material publicitario publicado
por los vendedores de heramientas CASE, lenguajes, metodologías y soft-
ware en los últimos años. Los vendedores de herramientas CASE son los
peores, seguidos por la ingeniería de información. RAD, 4GL y métodos
orientados a objetos (Jones, 1994). Generalmente, las herramientas que pro-
claman ser la panacea universal no han producido mejoras visibles, o bien
sólo han producido ligeras mejoras. Algunas personas han sido engañadas.
Aun cuando los desarrolladores de software tengan éxito al superar su
natural curiosidad y rechazar los anuncios de panaceas universales, sus
jefes pueden arrastrarlos. Tras revisar más de 4000 proyectos, Jones con-
DATOS REALES
cluyó que más de un 70 por 100 de todos los responsables de software de
EE.UU. creían ingenuamente que un único factor podía producir grandes
incrementos de productividad y calidad. Peor aún, constató que las organi-
zaciones que sucumben al síndrome de la panacea no tienden precisamente
a mejorar; de hecho, a menudo van hacia atrás (Jones,1994). También
advirtió que el síndrome de la panacea es especialmente común entre or-
ganizaciones de primera fila.
Desafortunadamente, los efectos de esta ingenuidad no son precisamente
benignos. El síndrome de la panacea universal plantea un riesgo a las planifi-
caciones de software similar al supuesto por el Laetrile para los pacientes
de cáncer: la búsqueda de falsas curas distrae la atención de otras curas o
conjuntos de curas que serían más efectivas. La proclamación de producti-
vidades exageradas ha reforzado la adopción de herramientas ineficaces,
yharalentizado y reducido la adopción de otras herrarnientas que podrían
haber sido más eficaces. Como compramos habichuelas mágicas en vez
de habichuelas reales, nos vamos a la cama con hambre. La creencia inge-
nua de que una única herramienta puede reducir espectacularmente el tiempo
de desarrollo nos lleva a probar nuevas herramientas de una en una en
lugar de usar un método más sistemático. Adoptamos las herramientas
beneficiosas en serie en lugar de en paralelo. Planificamos para mejoras a
corto plazo y rechazamos la planificación a largo plazo. Al final, el síndrome
de la panacea es uno de los factores causantes de la cancelación de proyec-
tos y del exceso de coste, así como de tiempos excesivos de desarrollo. El
único lado bueno de este cuento es que existen pocas posibilidades de que un
gigante diga <Fee Fi Fo Fum> y nos coma con tostadas para desayunar.
ldentificación de panaceas
Puede ignorar cualquier afirmación de poder mejorar la productividad más
de un 25 por 100 al año porque no es realista. A medida que pasa el tiem-
po, por cada herramienta presentada como panacea, la gente gana expe-
396 Desa,r"oilo y gest¡ón de proyectos informáticos
riencia real con esta cuestión, y al final la industria aprende que no es

-
absoluto una panacea. El efecto secundario indeseable consiste en que il
ocasiones tiramos al niño junto al agua del baño, rechazando compler=-
mente un método valioso sólo porque no responde a una publicidad er=-
gerada.
A continuación, vamos a citar algunas panaceas que no se adaptan I
la publicidad que se les da.
4GL. Los 4GL (lenguajes de cuarta generación) pueden ser aliados pc-
derosos parala productividad del software, pero ofrecen ganancias incre-
mentales, no revolucionarias. Los beneficios reales se aproximan a 1o.
descritos en la Tabla 15.2 d,e la página 392. Como dice Fred Brooks. i¡
última mejora realmente grande se obtuvo al pasar del ensamblador a los
3GL (lenguajes de tercera generación), cuando se pudo dejar de pensar er
los detalles del hardware de las máquinas específicas (Brooks, 198-r.
Cualquier ganancia adicional debida a mejoras en los lenguajes está des-
tinada a ser más modesta.
Herramientas CASE. La capacidad de las herramientas CASE para con-

tribuir al desarrollo de software de forma importante ha sido siempre so-
breestimada. El CASE puede ser genuinamente beneficioso en algunos
entornos, particularmente en aquellos orientados a las bases de datos. Pe¡o
en otro tipo de organizaciones, generalmente las herramientas CASE se
quedan en herramientas de alto nivel para crear diagramas de diseño. Ai
Davis 1o dice me.jor:
Las herramientas CASE ayudan a un ingeniero de software del mismo modo

que un tratamiento de textos aytda a un autor. Un tratamiento de textos no
convierte a un mal novelista en un buen novelista, pero hará que todo autor
sea más eficiente y su material sea gramaticalmente correcto. Una herra-
mienta CASE no convierte en un buen ingeniero a uno malo, pero hará que
cualquier ingeniero sea más eficiente y sus productos sean más bonitos.
Los usuarios han comenzado a obtener la misma conclusión. Un tn-

forme de Tesch, Klein y Sobol determina que los usuarios estaban con-
vencidos generalmente de que las herramientas cASE no mejoraban 1a
calidad del diseño (Tesch, Klein y Sobol, 1995).
Lo que importa es que el CASE puede ayudar, y en algunas situacio-
nes puede ayudar mucho. Pero no es una panacea.
RAD. RAD es un conjunto de métodos orientados a sistemas de infor-

mación adaptados de algún modo a circunstancias individuales. RAD fue
definido con alguna precisión cuando se introdujo en Rapid Apprication
Developmenl (Martin, 1991) y se refiere a una combinación de sesiones
"
Capítuto 15: Herramientas para aumentar la productividad 397
JAD, prototipado, equipos SWAT, entregas en ventanas temporales y

herramientas CASE, utilizados conjuntamente con una metodología bas-
tante bien definida.
como es un conjunto de métodos en lugar de un método individual,
en algunas ocasiones puede ofrecer beneficios cercanos a los de la
panacea
dentro de algunas áreas específicas de aplicaciones. Pero RAD no se aplica
a cualquier tipo de software (personalizado, <prét-á-porter) o de. sistemas,
por ejemplo) que tiende a ser el tipo más problemático' Fuera de sus orí-
g.rr", centradas en bases de datos dentro de sistemas de
"r'upíi.u"ion.r
información, RAD se ha convertido más bien en una cafrera desesperada
hacia el desarrolto rápido que en una metodología significativa'
programación automática. Es una panaceapopular que parece resur-

gir Jada pocos años. En un artículo titulado <Automatic Programming:
que la
Ñ4yths und Pro*p".ts>>, Charles Rich y Richard Waters argumentan
prágramación automática es generalmente un <<Mito de cóctel> (Rich y
Wul"rr, 1988). Según el mito de cóctel, los usuarios finales le dirán sim-
plemente a la computadora el tipo de programa que desean, y la compu-
para
iado.a lo generará áutomáticamente. La única comunicación necesaria
crear un frogru-u informático será la de los usuarios indicando a la com-
putadora una descripción completa de los requerimientos'
El problema Que.existe incluso con este mito de cóctel es el de que los
usuariás finales tienen suficientes problemas para especificar de forma
completa y precisa los requerimientos a los analistas de software humanos.
No existe nada que nos higa pensar que podrían hacerlo mejor al especi-
ficarlos en una computadora. Ciertamente, hay diferencias entre lo que se
introduce actualmente en la computadora y 1o que se introducitá en e\
futuro en 1o que se llama (un programa).
Pero el nivel más alto de lenguaje de programación que podemos es-
perar, según creo, es uno que funcione exactamente al nivel de1 negocio o
profesión de la persona; herramientas tan útiles como las hojas de cá1cu-
1o, pero adaptadas a diferentes necesidades'
Rich y Waters concluyen que <<los sistemas de programación automá-
tica del futuro serán más bien como aspiradoras que como hornos auto-
limpiables. Con un horno autolimpiable, todo 1o que hay que hacer es
¿ecidir si quiere limpiar el horno y pulsar un botón. Con las aspiradoras,
1a productividad se incrementa mucho, pero sigue teniendo mucho
trabajo
que hacer>.
ffi
DATOS REALES
Programación orientada a objetos. Las tecnologías orientadas a ob-
jetos no han evolucionado de la forma en que esperaba la -qente que las
adoptó. Hay un informe que indica que los proyectos orientados-a objetos
habianbajado de un 92 por 100 de éxito en i991 a un 66 por 100 de éxito
dos años áespués. La explicación del cambio consistía en que los proyec-
G
)esa"s ,c ',' gestión de proyectos informáticos
tos orientados a objetos de l99l estaban desarrollados

por (camr.-
que podrían haber obtenido estos resurtados
debido u tu ruyo,. tr..
y formación' Los proyectos más recientes han
sido realizados por ü-
lladores típicos, que son más críticos sobre las
ventajas . in.irr. _..
de los métodos orientados a objetos (Glass, 1g94b).
REFERENCIA
CRUZADA , La programación orientada a objetos está produciendo grande: :d'**-
ficios en el área de la reusabiridad, pero las prometidas
Para otros comentarios
veniajas i: -_ri.r:r¿,*
sobre la programación ralidad y facilidad de uso no se han cumpliáo (Schortz
orientada a objetos, et at., rgv- iiui
programación orientada a objetos integra muchas
consulte el
Capítulo 19, los últimos 35 años de desarrollo de sJftware, pero
de ias mejores ic;i, mr
"Diseño aprender a usa:,. :rmr
para el cambío".
es difícil. Puede confundir más al desarroilado,
de ro que parece ., :!vmü
verse como una tecnología para expertos. Desde
este punto áe uirt.. -, *
elemento valioso de ra caja de herramientas der
desairoilador.
cualquiera de las técnicas de este ribro, de forma individuar. nu

m*
guna de las técnicas individuales descritas en
este libro debe tomars; ,rrü*
vidualmente como una panacea. Conjuntamente, a lo
largo del r,;:r¡,i
pueden suponer diferencias impresionántes en
su capacidaá para e,.::rn:
software rápidamente.
Abrir los ojos

En el cuento de Juan y ras habichueras mógicas, ras
habichueras rn.:-:ü*
se convertían en una planta gigante, y Juan tenía
una gran aventur. :;
en la versión software, cuando la madre de Juan
tira las nu6i.¡u¡-:: ,*m
la ventana, éste es er final de ia historia. Las habichueras
no cor- -:rr
ninguna magia y Juan simplemente perdió la vaca
de su madre.
Las personas del mundo del software compran
habichuelas r,;:"..*¡r
siempre que creen en reclamos publicitarios que
racionalmente son r=11r¡*
sibles. Los vendedores continúan prometiendó
que tienen habichuer"¡ :Lr,s
producen grandes árboles y permiten a los
compradores llegar a : .:;*,
imposibles de productividad. Los desarroilado..,
y ..rponru'ui-, , - -,,.
núan gastando millones de dólares basándose
en esta publicidad. L, :-:.
gunta del millón para nuestra industria es:
<¿cuánta, u..". uun or'-" - . *-
prar las mismas habichuelas mágicas?>
Buscar la salida más fácir es argo inherente
a ra naturare Z&hrr.,:,,, ,
es totalmente racional buscar la solución

más económi.u, ,afiáu-.. _.-
Pero resulta difícii creer que profesionares
formados ,igun á.i*... *
contra delarazón durante treinta años, que es
lo que se há hecho el r.-::,
tro campo.
El desarrollo de software es un negocio duro, que
consume:,;:::,
Durante treinta años nos han dicho quá tu
magia qu. no, iba a p_::: -r
superar planificaciones y presupuestos gigantes
estaba a la r.uei-: :. ,
esquina. Durante treinta años no ha llelaáo. yo

digo que 1,a b:.:, "c
lir- --
=r
hay magia. No vale la pena esperarla. Cuanto más esperemos, más nos
privaremos de métodos valiosos e incrementalmente mejores para mu-
chos de nuestros problemas. No existen soluciones fáciles, pero sí hay
soluciones mas fáciles, que pueden aportar modestas mejoras de forma
individual y grandes mejoras de forma colectiva'
El libro completo, en cierto sentido, es un conjuro para detener la com-
pra de habichuelas mágicas y buscar panaceas. Como industria, necesita-
mos apretar los dientes, ignorar 1as panaceas y hacer el trabajo necesario
para alcanzar realmente ganancias en la productividad.
Ejemplo 15.2. Uso eficaz de las herramientas
Para su sorpresa, Angela se encoirtró de repen¡e al frente del. nuevo gmpo

de herramienta$ de su,empresa' Se había quej*do de que nadie había leídó'
su diagnósticorsobre Blaze-O-Matic r¡ersión 1. Otr. grupc de la emprgsa
tuvo una expenenc¡a srrnilar con Blaze-O-Matic después de su g{upo;,'lo
que implicaba que la empresa habia cometido dos veces gl misrno y costo-
,o Algunas se'¡anas desp¡és de su queja; alguien 1e pidilé si deseal-la
"t.oi.
encabgzar el nuevo grupo.
Pasaron los meses, y un día Mike le preguntó sl habia escnchado aigo
sobre Gung-HO-OO, una aueva biblioteea de,interfez de usuano que se
suponia era mejor que Blaze-O-Matic'
<Pues sfr, dijo el1a. <Hay un gmpo de la empresa que ya ha terminada
ur proyecto utilizándo1a, y otro grupo que la está usaado ahora y h. u t"l"i-
nadc prácticarnente su proyecto. Tengo aquí mismo una copia de los diag-
nósticos de1 prcyecto del primer grupo, y te los puedÓ pasar.,Kip és la
peñona de contacto del proyecto que esiáusando ahora,Gurrg:H.O-00''Aqui
lienes su dirección de correo electrónico'>,
, Mike 1e dio las gracias y se fue para leer el diagnóstico. Del infbrme
parecia:denvarse que Gung-HO-OO era un paquels estebls, pero sutiitilio-
téca estadística era mediocre: El grupo que escribió el diagnóstico, 11o Se
habÍa preocupádo de esto, pero 1o había¡ marcado como un posible'proble-
ma pafa otros grupos. Esto si era un problema para el proyecto de 'Mike,
que tenia que realizar bastantes cálculos numéricos' Se puso en contacto
con Kip. y le dijo que su grupo esraba haciendo tambien algún trabajo es-
tadístico, Habían pasado airededor de un mes p{obaÉdo herramienta$ de
diferentes vendedores, y habían idenfificado otro paquete, llárnado Tally-
HO-OO,'que funcionaba bien con Gung.HO'OO. Mike ¡eCornendó a su
:grupo que usaran la combinación de Gung-l{O'OO y Taltl-}{O-Or0t V és
tos aceptaron.
El grupo de Mike procedió a desairoilar su programa col1 los dospaque-
tes, y sncorrff&ron poco$ problem*s, finalizando gÍ rin ticmpo récord.
' A indioación de Angela, también habian decidído utilizar un¿ bibliote-
ca dergrá{icos que nadierhabía usado antes enrla empresa, Ella había lieva-
\ C O¡itttltttt )
-..l&F
ao,á.eáii{lrá,¡{l*!lgiq,p.-9lim!nqr, p9r9 ieslabia,advertido de los probler

,.:qrli-:1-41,.-dipódrpn,*éié¡!ais!,,Ár'e|ufó,d9,*r;proyéctoreat-
. &
,:,:',:::,.:::.N:,::f,$rp1dg1$rc¡yl$éfol9ll¡]üq.fq,dé,:Mike.$q*et ó,que Ia bibliotec¿
,,';',,';;,ffi1{1Cls.,ig6¡1m$diii qf.Lrt,tittffiCa.,lópriaba prácticamente Ia ñi¡d &
..,:t,ll6¡i:grá{iitb,sique,ite¡éii#.tái,feptes,e¡irar,rp¿iotilv:it{ :itüe:eodificar arn-
Xn . i*inri¡ádilbügttréóf¡i:q$e,i*i' iel¡ r$abfdb,9s*g1ántes;habtía¡
icf$fii'uú'.rnpjo?;diseflo.pttollris,$¡áfióes,,go!{Égpaos a mano. yhabrían cÉ
d
ir'*ido:.io$..oiros,sfur,táirt$itrab4ió.,'Cqlué.ntárrir¡¡est$iia*n.1oq:.diagnósticos
proyecto. y le enviaron rma copia a Angela. Ella lo guardó como refereüi
para futuros proyectos.
Brooks, Frederick P., Jr.: The Mythical Man-Month, Anniversary Eti:;":w,
Reading, Mass.: Addison-Wesley, 1995. Este libro contiene los e:s,n-
yos <No Silver Bullet-Essence and Accident in Software Engineer--c'
y (No Silver Bullet Refired>. El primer título es el famoso ensa). tr
Brooks reimpreso a partir del número de abril de 1987 de la rer:-om
Computer. Brooks afirma que no habrá, y lo que es más impona:=
que no puede haber, ningún método individual capaz de producir::-
ducción de un orden de magnitud en el esfuerzo necesario párÍl crn:*-
truir un sistema software en el período de 10 años que se inicia en 19i:
<No Silver Bullet Refired> es un nuevo estudio realizado 9 años ti.;r-
pués de las afirmaciones vertidas en el primer ensayo.
Glass, Robert L.: <What are the Realities of Software Productivity/Qu,:--
ty Improvements>>, Software Practitioner, noviembre de 1995, i. +;
Este artículo estudia 1a investigación de evaluación realizada soL'::
muchos de los métodos-panacea, y concluye que prácticamente en :c*
dos los casos hay poca investigación que soporte las pretendidas lri-
joras en productividad o calidad.
Jones, Capers: Assessment and Control of Software Risks. Engleu'oo:
Cliffs, N.J.: Yourdon Press, 1994. Este libro contiene una discusiri-
detallada de los riesgos asociados con la adquisición de herramient:-.
(<malas inversiones en tecnología>), el síndrome de la panacea, )-" ie-
mas relacionados, como la mejora de planificaciones a corto plazo.
Jones, Capers: <Why is Technology Transfer So Hard?> IEEE Compure"
junio 1995,86-87. En este artículo se profundiza en la razónpor
'z
que se tarda tanto en poner en práctica nuevas herramientas y metodo-
logías en una organización.
O'Brien, Larry: <The Ten Commandments of Tool Selection>>, Sofhrar;
Developmenl, noviembre 1995,38-43. Es un breve resumen de direc-
trices para seleccionar herramientas con éxito.
\: -4
402 Desan,ollo y gestión de proyectos informáticos
El equipo está a la defensiva sobre su progreso. Se siente: ,:r

zados si alguien ajeno al equipo sugiere que el proyecto pt-rc:_.1
problemas.
Las relaciones entre los desarrolladores, los representantes ü: :
ting, los directivos, los del control de calidad y los clientes sc: :-
El proyecto está a punto de cancelarse; los clientes v dr::::
están considerando esa opción seriamente.
r La moral del equipo de desarrollo se ha venid.o abajo. Ei r:
ha perdido la diversión, los miembros del equipo están ser_
Para salvar un proyecto que se encuentra en problemas, una:

ñas modificaciones no bastarán. Se necesita tomar una fuerte ac¡
corrección. Este capítulo describe un plan riguroso de rescate.
Ejemplo 16.1. Recuperación fallida de un proyecto
El'proye¿fo de1 ¡istema derconitrol de inve¡tario de carl, scl 2,0, estaba l

punto de finalirar. Su equipo había estado trabajando en el sistema duram
poco más de 4 meses. y ahora la lecha límite estaba a 3 semanas. conr-r¡o
una reunión del equipo. <De accerdo con la plánifiea¿iórl;'esta:le,nrana to&
el mundo debería estar comprobando las veiiones fi¡ató* dé su códiec"-
'¿Cémovatodo?tr:--."..'.:-'-.-.'"
. , <Sastante bien, pero ao l,o suficién.te>r; lespondió Joe honestamenúL
r r¡ifq te+id,o uaos. eúaalos p¡cbler¡¡as, esloli t¡abajelds,tads'.lo,fq,Be paedo-
.ipei* nO,o¿pE9,ütfg lar.fümja dre tefminar.en men¿S .de,5,Semanas,}) -
<A mi me sucede lo mismo,¡. dijo Jennifer. <Estoy haciendo grandes pro-
, Cre
péi
sos¡ Éci,¡.e deberia haber ptan-rtrc"¿"¡l*¡ *'*;fáiiu ;-
d" ;
: ¡.eq;'Eq.máqbienunp{dy¡q1ó
de 7 peses, Aún me quidan's; q,e ¿á*¡as más-,
,',- ,,, 'Carl,eoéié d,e forÍlá:il¡tíatifá sü,ACIlaids,:(('De acuerd;-t;;-;;;r*
la forma de darle esta noticia a mijefe. Dejarme el resto del día p;r; ;";_
:l:igüii:Bl.nlán.deloltuperación, y 1uggo os lo comi¿ia¡é:¡r,.',., :,,:,.'.t
día siguienre. Carl présentó su plan. Habla hablado con su jet-e.
_...A1
,:'Billj r'etqaiandó su planificaeiéa du¡ant-e3,seCIana$! Ibá,ape¿i¡áy*u u icin
miembro de otro gtupo. paru qr" ryrduru a Jennifer y'a Joe.'i."i;;""
gqÍ,l.t?dCIde p-rimera fila,,llarnado Keikg; para que agunliera el resto del
trabajo retrasado.
<¿Esrás hablando en serio?>. preguntó Jennifer con increduridad.
<¿No
has escuchado hablar sobre el sindrome del mito de las perscinur-..r?"lo-
corporar desarrolladores en este punlo relrasara el proyecto. Me llevará
muclro tiempo conseguir que dos personas nuevas traba¡en , b; ;i;"-
Me llevará mucho tiempo.>
,Íul6j:n he pensado en eso. y me gusraria poder evitar ese problema>.
...
dijo carl. <He pensado que podemos dividir er p.y..ro, de rorma que apena-i
Capítulo 16: Recuperación de proyectos 403
üotes la presencia de los dos desa¡¡oliadores nuer'os. Les inf_Ori¡aré yo

mismo.))
<<Es posible qr¡e nos a1'uden un poco)). interi.ino Joe en la corivetsa:
ción. (Pero honestamente necesito 5 semanas^ y ao yeo la lorma de dividir
lrri trabgjo de modo que pueda darle *n¿ parfe a alsriiea.)
.<¿Estáis colnprometidos o no en este pror-ecr;?),. dijo Carl. <El pro-
yecto no tiene tantos problemas. Haced simplemen{e vuesrro trabajo lo mejor
posible^ y \eremos que sucede. ¿De acuerdo?¡ Jennilert Joc reían que no
tenía sentido disautir, de forma que aceptaron y reg¡esaron al trabajo.
,,' Trabajaron casi sin parar clurante las 3 semanas siguieates, pero a1 ter-
minar ese tiernpo no estaban mucho más cerca de la meta. <¿,Cómo r,a-
mos?>, preguntó Carl.
' <Casi igualr.,,informé Jennifer, <<Aún me quedan'4:,o 5' semanas de
trabajo.>
, <A mí me.$rcedg lo mismo>, informó Joe. ,
,
, ,.<¿Me cstáis tomandc el: p€lobr, bufo de célera, Car3, <<Jonnifer, me di-
jiste que te lallaban 5 o 6 semanas de trabajo. y de eso hace 3 semanas.
¿Cómo puedes decirme hoy que te faltan 5 o 6 semanas?>
<,Algunas cosas me han llevado rnás tiempo del que esperaba>. dijo ella.
,<Ademas. Kip y Keiko no tienen la culpa. pero conseguir que trabajen a
buen ritmo me ha llevado mucho tiernpo. Ellos no sabian cómo manejábamos
nueslros archivos de código fuente. y Keiko sobreescribió algunos de
nnestros archivos principales. Volver a crearlos aosrllevó a Joe y a mí va-
ilos dias.D
<,¿Cómo pudo sobreescribir esos archivos?'>. preguntó Carl. <¿Estáis
utilizando el conlrol del código fuente au{omatizado y hacéis copias pe-
ri ódi cas? ¡
La paciencia de Jenniler se estaba aeotando. Esraba cansada y se había
enlregado por entero al proyecto. "Escucha. nos hemos entregado durante
más de 2 meses. Hemos dado lo mejor de nosotros. Nadie ha tenido tiempo
para establecer el control automatizado de rersiones, y tuvimos un par de
contratiempos. Mira. te dije que lo terminaría en 4 o 5 semanas. y asi lo
haré.> La reunión se disclvió y,Cail le dijo'optirrrist+,qqg1e,,a,¡8.i1I quo el
Óuatro semanas más tarde. el equipo informó que habían hecho gran-
des progresos. pero pensaron que uún l.r faltaban otras 3 ,.rnunu. ñá, o
menos hasta que terminaran. Unas cuantas semanas después, Jennifer y Joe
se dieron cuenta de que habia algunos flecos del diseño que no podian
codificar y tenían que volver a diseñar una parte importante del sistema.
Cada error corregido parecia dar origen al doble de defectos detectados, y
ét liempo de finalizasi,én estimado por el grup_o oom€nzó a escapárseie en
lrez de acerqarsé: Carl: ádmitió que no sabia realinénte cüáldo estaría te¡-
minado el proyecto.
Dos meses más tarde, después de tres retrasos de tres semanas en la
planifieación, :Bill cancéló el prof¡ecto..ñqtificó a los usuarios que ren-
drían que continuar utilizando SCI 1.0 o buscar un sustituro en el mercado.
16.1 Opciones generales de recuperación

Só1o se dispone de tres enfoques fundamentales para recuperar *:. :r,
o Reducir el tamaño del software, de forma que pueda --r.:r-
dentro del tiempo y el esfuerzo planificados.
r Incrementar la productividad del proceso centrándose el :: r1
ras a corto plazo.
¡ Enfréntese al hecho de que ei software no va a estar list¡ ,
retrase la planificación y continúe con el control de1 prt',: :
cluyendo posiblemente la cancelación del proyecto.
Combinando estos tres enfoques, aparece un cuarto:
o Omita unas cuantas prestaciones, aumente la productiri¿'- -

como pueda, y retrase la planificación 1o que sea necesar:-
Este último enfoque es la opción descrita en este capítulo.
Filosofía
Cuando está en modo de recuperación de un proyecto, es fácil cenl:::r: ilu
el tema erróneo: ¿cómo fermrnar rápidamente, cómo lo conseguíre"-. :. . *ri
difícilmente el problema rea1. Para los proyectos que tienen este::::::
ma, normalmente el probiema principal es simplemente cómo ten:.-:r-
En un plan de recuperación se pueden tomar muchas direccit-:,:; l
plan de este capítulo se centra en recuperar el control del proyecto. - :"
trol> puede tener una connotación negativa, principalmente para 10! :.. *
rrolladores con mentalidad independiente, pero no creo que sea :. - - *
recuperar un proyecto sin centrarnos en é1. En mi propia experien; t'
'
como en las experiencias recogidas de auditorías del Instituto de In..-
'
ría del Software y otros informes publicados e informales, la caus, : ;.
común de que los proyectos tengan problemas es principalmente i. -' ¡
de un control adecuado. El deseo de obtener la máxima velocidad de ::,",
rrollo conduce a los proyectos a tomar atajos poco aconsejables, e in.: .*
tidamente sacrifican a cambio la velocidad de desarrolio real. A1 f-r:, :
control es tan pequeño que ni desarrolladores ni directivos coflocer .,:: *
qué punto sus proyectos están fuera de control.
Es difícil recuperar el control que se perdió, de forma que e1 mc::--.
en el que usted y su equipo se ven obligados a hacer frente a 1a re.-,*,;
sobre la necesidad de la recuperación representa una singular opc:t-
dad de tomar el liderazgo. Le ofrece fundamentalmente la oportunic=: -,-
redefinir el proyecto,1o cual no puede hacerse si el proyecto sóL- ..:-:
pequeños problemas.
Éste es momento para entrar en acción con decisión. Si va a hacer cam-

bios, realice grandes cambios ¡' realícelos todos de una vez. Hacer muchas
correcciones pequeñas resulta desmorahzante para e1 equipo de desarolio,
y da ia impresión a 1a directiva de que no se sabe lo que se va a hacer. Es
más fácil volver a recuperar todo el control de una vez que intentar recu-
perarlo poco a poco, un poco ahora ) otro poco después.
16.2, Plan de recuperación

Existe un conjunto de directrices que pueden funcionar a ia hora de recu-
perar proyectos con dificultades; las directrices esián relacionadas con
las personas, el proceso y el producto. Pueden combinar 1os métodos de
este libro de infinitas formas pala creaf un número interrninable de planes
de recuperación. Esta sección contiene uno de estos planes'
El plan de este capítulo está diseñado para recuperar proyectos con se-
rios problemas. Éstos son 1os proyectos que más ayuda necesitan, de lorma
que he descrito un enfoque muy minucioso. Si ei proyecto no tiene tantos
esta isla'
"Estoy realmente contento de que hayamos encontrado
Por un momento ta situación parecía estar fuera de control.'
Figura 16.1. tJn pequeño intento de recuperar el control de un proyecto

puede conducir a una falsa sensación de seguridad'
406 Desarroila y gest¡ón de proyectos informáticos
problemas, se puede utilizar un enfoque menos exhaustivo. H.,, :_ -'.

el plan de recuperación a las necesidades especificas del prc,-, -::.
REFERENCIA Un plan que no funciona casi nunca es realizar recortes, , ; ,:l
CRUZADA
Para obtener una el momento para hacer recortes, la recuperación del pro)'eü:: :i
mayor información mento para volver a las bases. El plan que se describe aquí el :: .i
sobre el signif¡cado
más efectivo de la
con los cuatro pilares del desarrollo rápido: evitar los effoi:: -
lntroducción de las aplicar las bases del desarrollo, gestionar los riesgos y busc:: j.
nuevas tecnologías, de aplicar los métodos orientados a la velocidad.
véase "Cuándo adoptar
las herramientas.,
Primeros pasos
REFERENCIA Antes de emprender un plan de recuperación hay que buscar ;
CRUZADA
Para obtener más
plan que se necesita.
detalles sobre la
identificación de las Evalúe la situación. Determinar cómo es de crítica realmente ,= ,::-t¡,
prioridades de mite y la precisión necesaria para conseguirla. Podría encontrars. ;:m
desarrollo, véase
"lnventar opciones
realmente no hay ninguna fecha límite importante, y no necesi:::!
para obtener cuparse en absoluto por la recuperación del proyecto. O podría en;::m
beneficros mutuos.,
en la Sección 9.2.
con que los clientes están más dispr"restos de lo que estaban al c¡:-- :
negociar el conjunto de prestaciones para evitar un retraso en e- :-, :r
REFERENCIAS Aplique el análisis Theory-W. ¿Qué necesitan usted y su equ::'.
CRUZADAS
Para obtener más
triunfar? ¿Qué necesitan sus clientes? ¿Qué necesita hacer para * tr
detalles, véanse relación con los clientes? No se centre en el pasado. Céntrese e:- .
el Capítulo 10, sente. Si no encuentra la forma de hacer que todos salgan ganani. .
" Desarrollo orientado
u¡ s¡¡s¡19", y el sus propios medios, deshaga el proyecto.
TheorY-W". Prepárese para corregir el proyecto. Si su proyecto está en :,j¡r ü!ü
=
recuperación, y no solamente un poco atrasado, su proyecto está n'-:,rum,
Comprenda que su proyecto está destrozado. Dése cuenta de que ::- ¡lrúy-
de arreglarlo haciendo las mismas cosas que ha estado hacieni,; -*m
ahora. Prepárese mentalmente para hacer cambios significatir,,os. ?::tmm
tanto a su equipo como a la directiva para que vean los cambios slg:-,
";.-
tivos que serán necesarios si desea salvar el proyecto. Si las persc---* mu
-i"-¿1,¡-
están dispuestas a hacer cambios significativos, ya ha perdido la
Considere la cancelación del proyecto.
Pregunte al equ¡po sobre lo que se necesita hacer. pre_eun:; t:u*

dos los miembros del equipo para que contribuyan con al menos ;:rrir
ideas prácticas sobre cómo salvar el proyecto. Evalúe las ideas. 1 -_:g'
ponga en práctica tantas como pueda.
Sea realista. Si está en modo de recuperación de proyectos. prLr::: *-

mente lleve una cadena de promesas de planificación rotas alrede¿:: -l¿
cuello. Estas promesas pesan tanto como una piedra de molino. Si er:: :r
nrodo de recuperación de proyectos, su equipo necesita desesperad.::-r*
tL
te una fuerte dosis de lucidez para dirigir e1 proyecto con realismo. Cuan-
do comience la recuperación de su proyecto, admita que no sabe cuánto
tiempo Iardará en finalizar. Explique su plan para conseguir volver a en-
carrilar el proyecto, y luego dé una fecha con ia que pueda comprometer-
se como 1á nueva fecha límite. No se comprometa con una nueva fecha
límite hasta que tenga buenas razones para pensar que puede cumplirla.
Personal
Las personas son las que más influyen en el desarrollo rápido. y necesita
porr", orden esa habitación del desarrollo rápido en su casa antes de
"r,
pasar a las áreas de proceso y de producto.
REFERENCIA Haga todo lo que sea necesar¡o para recuperar la moral del gru-
CRUZADA
Para obtener más
po. Durante larecuperación del proyecto, la moral desempeña un papel
detalles sobre la i-portunt. en la productividad del equipo. Los altos cargos quelrán conocer
motivación, véase cómo motivar más al grupo. Ésta es una idea falsa durante la recupera-
el CapÍtulo 11,
.Motivación". ción del proyecto. Si el grupo ha estado trabajando duro, la cuestión no es
cómo mótivarlos al máximo, sino cómo recupelar su moral, de forma que
estén motivados del todo.
Una de las mejores formas de recuperar la moral es tomar una acción
simbólica que muestre que usted está detrás de los desarrolladores, y una
de las mejores formas de hacerlo es sacrificando a una de las vacas
BIBLIOGRAFIA sagradas lela organización. Esto muestra a los desarrolladores que la com-
ADICIONAL
Para obtener más puáíu 1". apoya e ilustra la importancia del proyecto. Sus acciones dicen:
información sobre la <Estamos comprometidos a entregar este producto, y 1o haremos sin im-
dinámica de grupo de
sacrificar a las vacas portar 1o que tengamos que hacer.>> Las vacas sagradas varían según las
sagradas, véase la ái*tintu. oiganizaciones, pero mientras se esté rompiendo un precedente,
los desarrolladores captarán el mensaje. Déjeles llegar a trabajar más tar-
regla núm. 48 en
Software Project
Dynam¡cs (Mccarlhy , de que el resto de la organización. Déjeles irse a casa temprano. Suspenda
1 995).
temporalmente el uniforme. Cómpreles los nuevos monitores grandes que
querían. Tráigales la comida. En resumen, hágales sentirse importantes.
En lo que respecta a su proyecto, 1o son.
Una de las más sagradas de las vacas sagradas pala un proyecto retra-
sado es el no permitir tomarse tiempo libre. Si se ha estado trabajando
durante meses con la presión de que quedan 3 semanas parala entrega del
producto, los desarrolladores no sólo apreciatán el tiempo libre, sino que
además será necesario para mantener al equipo sano y productivo. Un fin
REFERENCIA
CRUZADA de semana libre puede parecer toda una vida para un desarrollador que ha
Para obtener más estado trabajando sin ver el fin.
detalles sobre los
factores que Hay que asegurarse de que se están proporcionando al equipo factores
deterioran la moral, de higiene. Elimine una presión excesiva en la planificación, las malas
véase "Destructores
de la moral", en la
condiciones de trabajo, la manipulación por parte de la directiva, y otros
Sección 11.4. destructores de la moral.
408 ,?Si'ri,,a y gest¡ón de proyectos informáticos
Elimine los problernas de personal más importantes.

más comunes sobre los jefes de ros equipos es que
L,. :_,ririrür,r,
no resuelr.en ,. i r-l.i *
blemas causados por los miembros
-oi.rio, del equipo. Si cree q.- , .,,,, *,
una persona problemática, hágale frente al momento
y elimine el p:, : , ....,u,
Sustituya a aquellos miembros del equipo que no estén
aunque sean colaboradores claves. La pérdida qua
dispuer,o. . ,,*. .
en ra n_- i¡* .
reagrupando ü: - ,
equipo no compensa su aportación técnica. Los está"uurun
r$i:
modos, de forma que es un buen momento para elimrnir
las péri:'-.,
Elimine los probremas principales con ros responsabres.
E1
sable que ha llevado el proyecto al borde del desastre podría
.¡: -.
no ter-r , x.ri,
ciente credibilidad como pararealizar los cambios necesarios
proyecto tenga éxito. En algunos casos, ei responsable
par; :-:
I
ineficazes er :-.. - ,,¡,,
técnico; en otros casos, es ei director del proyecto.
Si ocupa ur t_:,1,
que le permita hacerlo, considere cambiar uior
r.rponrables de1 pr. .:,
una de las opciones es sustituir al responsabre, pero si usted
es er re.. -
,*,
ble técnico, probablemente no podrieriminar a un director
rn.nci..-.. I
usted es el director, eliminar al responsabre técnico
forma de actuar. Afortunadamentq hay muchas opciones
no es siempre 1a
= : ¡nn
disponib;. :,o
sutiles y que sueien ser más efectivas que
¡eueda despedidál:
' cambiar al jefe del director. A veces un director necesita Lr: : ir

d iferente.
Dar al director un papel más participativo. A veces,
un direct,:: - ":
orientación técnica puede contribulr de forma técnica
a a\-;: - r;
obtener más éxito en e1 proyecto de 1o que pueda aportar

,,i . - _:-
bución como líder.
Dotar al director con un ayudante. Dependiendo de lo
Qü€ S€ :,_-:
site, ei ayudante puede centrarse en loi detalles técnicos,
libe:. *
al director para que pueda centrarse en temas importantes,
o i _:-r
dedicarse a temas administrativos, liberando al director p"r,
.-1-
se en temas técnicos. En casos extremos, el
<ayudante, puede . _ .
casi todas las responsabilidades del director, dejando
á1 d,.... - ,
control de las tareas administrativas y el envío de informes
altos cargos.
. ,
Estos puntos se centran en ros cambios de
director, pero tamb:;_ ,:
aplican a los cambios en la responsabilidad técnica
del pioyecto.
Si tiene que hacerlo, aumente el número de personas
con c-*
dado. Recuerde la ley de Brooks que dice que incorporar
personas : r
proyecto retrasado es como añadir gasolina
al fuego (Brooi<s, 197i
incorpore personas en un proyecto retrasando po.
iu, iu"nur.'
Pero recuerde la iey completa. Si se puede iiui¿i,
ERRoB cLÁSICo yecto, de forma que una persona adicional pueda "t
traUa¡o de un :: _
ayuda*in -or.str.= ,
demás personas del proyecto, es interesante incorporar a esa persona. Piense

si tiene sentido meter a una persona que necesitará 8 horas para hacer lo
que uno de los desarrolladores existentes haría en una hora. Si el proyecto
está en una situación desesperada, dé un paso adelante e incorpore a esa per-
sona. Pero aténgase a las consecuencias. Hay gente que no soporta ver como
otra persona emplea 8 horas en hacer el trabajo de I hora, sin tener en cuen-
ta sus intenciones iniciales. Conozca la clase de persona que es usted. Si
piensa que podría equivocarse, peque de no incorporar a nadie.
Céntrese en el t¡empo de las personas. Cuando está en modo de

recuperación de un proyecto, es necesario uttlizar lo mejor posible a las
personas que ya están familiarizadas con el proyecto. Piense en coger
el dinero que emplearia en incorporar personas nuevas y utilícelo para
centrar el esfuerzo de las personas que ya existen. Saldrá adelante.
Puede centrarse en las personas clue ya existen en una gran variedad
de formas. Déles oficinas privadas. Quítelas de los sitios incómodos. Ase-
gúrese de que no están distraídas con otros proyectos dentro de la organi-
zación, de forma que se descarguen de las obligaciones de apoyo técnico,
mantenimiento de otros sistemas, ofertas de trabajo, y todas las demás
responsabilidades que merman el tiempo de un desarrollador. La cuestión
no es que trabajen sin levantar la cabeza, sino liberarles de todas las ta-
reas que no sean esenciales.
Si tiene que contratar personal adicional, piense en no contratar a de-
sarrolladores. Contrate a personal administrativo para que puedan ocu-
parse del trabajo de oficina y ayuden a los desarrolladores a minimizar el
tiempo de inactividad (por ejemplo, la lavandería. las compras, pagar fac-
turas, jardinería, etc.).
REFERENCIA Permitir que los miembros del equipo sean diferentes. Algunas
CRUZADA
Admitir diferentes
personas ascenderán debido al desafío de recuperación de un proyecto y
niveles de compromiso se convertirán en héroes. Otras estarán demasiado quemadas, y rechaza-
es diferente al
comienzo de
rán entregarse completamente. Eso está bien. Algunas personas quieren
un proyecto. Para ser héroes y otras no. En los últimos estados de un proyecto, hay lugar
obteneÍ más para las personas discretas, colaboradores constantes que no quieren lle-
detalles, véase
el Capítulo 34, gar a héroes, pero que conocen muy bien el producto. Para quienes no hay
"Compromiso lugar es para los charlatanes vulgares que critican a sus compañeros de
(Signing uP¡".
equipo por ser héroes. Durante la recuperación de un proyecto la moral
es frágil, y no se puede tolerar a personas que se la hagan perder al resto
REFERENCIA del equipo.
CRUZADA
Para obtener más Permitir que los desarrolladores marquen su propio ritmo. Los
información sobre cómo
los desarrolladores corredores van a velocidades diferentes, dependiendo de la distancia a la
marcan su propio ritmo, meta. Los corredores corren más rápido cuando la meta está próxima que
cuando faltan varias millas. Los mejores corredores aprenden a marcar su
"Uso de horas extras
voluntarias". propio ritmo.
410 Desarrolia y gest¡ón de proyectos informáticos
Rompa el círculo vicioso de que la presión en la planific:J-::

gar a estrés, éste da lugar a más defectos, que a su vez dan i*;-
trabajo, para volver a una mayor presión en la planificación. \l :
presión en la planificación, dándoles a los desarrolladores tie::'
centrarse en la calidad, y la planificación vendrá detrás.
Proceso
Aunque encontrará mayores ventajas en la parte relacionada con e- :,:-
también debe ordenar el proceso si desea salvar un proyecto ;-:
problemas.
REFERENCIA ldentifique y resue¡va los errores clásicos. Examine su

CRUZADA para ver si ha sido víctima de algunos de los errores clásicos. A
Para conseguir una
l¡sta con un número ción se muestran las preguntas más importantes que se pueden
mayor de errores
clásicos, véase la
Sección 3.3, "Relación
r ¿Está cambiando todavía la definición del producto?
de errores clásicos". o ¿Tiene el proyecto un diseño inadecuado?
r ¿Hay demasiado poco control de la directiva como para
guir con precisión el estado del proyecto?
a ¿Ha prescindido de la calidad para poder alcanzar la fec
a
¿Tiene una fecha límite realista? (Si ya ha retrasado su
ción dos o más veces, probablemente no.)
¿Han estado las personas trabajando tan duro que corre el
perderlos al final del proyecto o quizás antes? (Si ya ha
gente, es que están trabajando demasiado duro.)
o ¿Ha perdido ei tiempo utilizando tecnologías nuevas y sin ::.
o ¿Hay un desarrollador problemático que provoca la caída ci:-
del grupo?
o ¿Está la moral del equipo 1o suficientemente alta como
zar el proyecto?
o ¿Ha descuidado la responsabilidad? ¿Qué personas o grupi j xll¡e
tenido buenas intenciones, pero no han sido responsables i;: irnri
resultados de su trabajo?
Detecte y corr¡ja las partes del proceso de desarrollo que obt'e,

mente están destrozadas. Cuando un proyecto tiene problern¿s. ::n-
malmente todos conocen que hay pocas partes del proceso que ;:;ün
destrozadas. Aquí es donde realmente entra en juego la vuelta a los :-::¡
mentos; las partes arruinadas están así porque el proyecto ha igr'::1,:.l,
consciente o inconscientemente 1os fundamentos del software.
Si el equipo está pisando su trabajo porque no se ha establec-;- "u
control de versiones, establézcalo. Si está perdiendo la pista de ios d:--: ':-
que se están detectando, establezca vn sistema de seguimiento de :;,::-
\¡¡---
tos. Si los usuarios finales o los clientes han estado añadiendo cambios
sin control, establezca un gmpo de control de cambios. Si el equipo no se
ha podido concentrar debido a un desfile continuo de interrupciones, cám-
bielos de sitio, haga que los separen fisicamente en su área, o defina su
propia frontera desde el suelo hasta el techo con cajas vacías. Si las per-
sonas no han ido tomando las decisiones oportunas, establezca un cuartel
general: reunión a las 5:00 de la tarde cada óía. y prometa que todos los
que necesiten una decisión la tendrán.
REFERENCIA Creación de hitos miniatura detallados. Para poder salvar un pro-

CRUZADA
Para obtener más
yecto que se está hundiendo, es absolutamente necesario que establezca
detalles, véase un mecanismo de seguimiento que le permita controlar el progreso con
el Capítulo 27, "Hitos precisión. Ésta es la clave para poder controlar el resto del proyecto. Si el
miniatura".
proyecto tiene problemas, ya tiene una justificación suficiente para esta-
blecer hitos miniatura.
Los hitos miniatura le permiten conocer día a dia si el proyecto cum-
ple la planificación. Los hitos deben ser pequeños, binarios y exhausti-
vos. Son miniatura porque cada uno puede ser terminado en uno o dos
días, no más. Son binarios porque o están hechos o no están hechos (no
se hacen en (un 90 por 100)). Sonexhaustivosporque cuando se termina el
último hito, se ha terminado el proyecto. Si hay tareas que no están en la
planificación de hitos, añádalas a la planificación. No se hace ningún tra-
bajo <fuera de la planificación>.
Establecer y cumplir incluso hitos triviales proporciona un gran estímu-
1o para la moral. Demuestra que se va progresando y que hay posibilidad
de recuperar el control.
Uno de los principales problemas para establecer los hitos miniatura
al comienzo del proyecto es que no se tiene conocimiento suficiente para
identificar todo el trabajo con detalle. En modo de recuperación de proyec-
tos, la situación es diferente. En la etapa final del proyecto, los desarrolla-
dores conocen suficientemente bien el producto como para poder decir
con detalle lo que hay que hacer. Por ello, los hitos miniatura son particu-
larmente apropiados para ser utilizados en la recuperación de proyectos.
Establecer una plan¡f¡cac¡ón vinculada a la terminac¡ón de hitos.

Planifique fechas de ftnalización para cada uno de los hitos miniatura. No
planifique muchas horas extras voluntarias: no han funcionado hasta ese
momento, y no 1o van a hacer a partir de ahora. Si contempla demasiadas
horas extras en su planificación, cuando los desarrolladores se quedan
atrás, no pueden ponerse al diaffabajando más horas extras. Establezca la
planificación de forma que si los desarrolladores se quedan atrasados en
sus hitos miniatura, puedan ponerse aI día trabajando unas horas extras el
mismo día. Esto les permite mantener la planif,rcación día a día. Si cum-
ple la planificación dia a dia, la cumplirá semana a semana y mes a mes,
II
¡
412 Desa,,ro¡'¡o y gestión de proyectos informáticos
y ésa es la única forma posible de cumplir la planificación en u::::

completo.
Siga meticulosamente el progreso de la planificación. S-

trola el progreso después de establecer los hitos miniatura. el r::^-:,'
crear la planificación sólo habrá sido un ejercicio para perder e, , :n:
consulte a diario con los desarrolladores para evaruar su progre s-- : ,'rr
"--r-------
hitos miniatura. Asegúrese de que cuando se dice que un hito esr. :::;
sea cierto en un i00 por 100. Pregunte al desarroliador: <Si coio;_ ::
fuente de este módulo que está "hecho" y io guardo con llave ei _
no durante el resto del proyecto, ¿podemos entregarlo? ¿Tiene .*:
mejorarlo o refinarlo para terminarlo, o está terminado en un 100 p,::
Si los desarrolladores dicen: <Se ha hecho en un 99 por 100,,. ;::
no está terminado, y ei hito no se ha alcanzado.
No permita a los desarrolladores que se aparten de las planili;,_
de sus hitos miniatura. La forma más sencilla de apartarse es no :,-.i,
un hito y luego dejar de mantener el seguimiento. Un día de ritr,:.
convierte en 2 días de retraso, que se convierten en 3 días, y lueg. .:
semana o más. Pronto deja de haber correspondencia entre e1 tral,-.
desarrollador y la planificación del hito. rJnavez que la planific,: ,,r
ha calibrado, no tome a la ligera los retrasos en la planificacio:- :
solo desarrollador se retrasa en un solo hito, se supone que reni,:
hacer horas extras ese día para ponerse al día (si un desarrollador ..:ir,fful
pronto un único hito, debe permitirle irse a casa temprano ese i:"
--,mh
hitos diarios deben cubrirse de forma consistente, o habrá que re.: :riiüf
la planificación para que puedan alcanzarse de forma consiitenre.
Anotar las razones por las que no se han alcanzado los hitos -r-
ner anotadas las razones por las que se haperdido cada uno de i,:,: : L,ni
puede ayudar a detectar las causas subyacentes. una anotación p..;, **
dicar la necesidad individual de formación de un desarrollador o re r,-.:-*"tr
la dinámica organizacional que hace que algunos desarrolladores:-_ :rrs-
dan hacer bien sus estimaciones. Puede ayudar a distinguir entre prc,:_:::rc
relacionados con 1a estimación y otros problemas relacionados ..,. _. r *.
nificación.
Recalibrar después de un corto período de tiempo (una o dos se:nr*

nas). Si un desarrollador no alcanza 1os hitos constantemente \. sr r:
-rr.r.u
más de medio día. es el momenro de recalibrar ra pranificaclor
-- :.:
desarrollador. Recalibre aumentando Ia pianificación actual con e - : -:_:r,
taje del retraso sulrido hasta el momenro. Si er desarrollador ha ni-:: -_._
7 díasparahacerun trabajo de 4, multrplique el resto dei trabajc, : *
;
No juegue pensando que recuperará el tiempo perdido más aáe .._,,. ,:,
está en un proyecto en modo de recuperación, este juego ya se ha :=: - :,
No cambie nunca No se comprometa con una nueva planificación hasta que pueda
unafecha errónea crear una significativa. No dé una nueva planificación a los altos car-
por otra igual de
gos hasta después de que haya creado una planificación de hitos miniatura,
errónea. Ése es un
mal negocio. Si ésta haya funcionado durante al menos una o dos semanas, lahaya recali-
hace esto, estará brado y haya ido bien durante más de una o dos semanas para comprobar
desperdíciando su la recalibración. Dar una nueva planificación a la directla rcahzada de
credibilidad.
otra forma es equivalente a reemplazar una planificación mala por una
Jim McCarthy
diferente, pero igual de mala. Si sigue primero estos pasos, tendrá unas
bases más sólidas para sus compromisos futuros de planificación.
Gestione los riesgos con esmero. Céntrese en la gestión de riesgos

utilizando las directrices explicadas en el Capítulo 5, <Gestión de ries-
gos>. E,labore una lista de los 10 riesgos principales, y compruébela a
diario en la reunión de control de riesgos. Se pueden alatgar las reuniones
del cuartel general a las 5:00 para revisar los riesgos y controlar los nue-
vos temas que han surgido, así como para tomar decisiones a tiempo.
Producto
A menudo no es posible recuperar un proyecto hasta que se actúa sobre el
conjunto de prestaciones del producto.
REFERENCIA Estabilizar los requerim¡entos. Si los requerimientos han ido cam-

CRUZADA
Para obtener más
biando a 1o largo de todo el proyecto, no es necesario que siga buscando
detalles sobre el el origen del problema. Debe estabilizar los requerimientos antes de lle-
control de cambios, var su proyecto a una conclusión con éxito. Un sistema con cambios sig-
véase Ia Sección 14.2,
.Proyecto avanzado: nificativos en los requerimientos no puede desarrollarse rápidamente y
control de cambios de normalmente no se puede desarrollar en absoluto.
las prestaciones".
Es bastante común que en este estado sea necesari o realízar una especi-
ficación casi completa de los requerimientos. Algunos productos cambian
tanto durante su desarrollo que cuando llega la crisis nadie sabe con segu-
ridad las prestaciones que debe contener el producto. Los desarrolladores
y probadores están trabajando en prestaciones que el producto podría in-
cluir o no.
Algunos proyectos resistirán el trabajo implicado por la formalización
del conjunto de requerimientos en esta fase del proyecto, pero recuerde que
el otro enfoque es el que está causqndo todos los problemas. Hay que hacer
algo diferente, y necesita conocer exactamente el conjunto de prestaciones
antes de que pueda terminar el producto, incluso antes de que esté seguro
de que el equipo de desarrollo está trabajando en el producto que desea.
Si el proyecto se ha estado ejecutando durante algún tiempo , formahzar
los requerimientos será un paso difícil, ya que implicará eliminar algunas
de las prestaciones preferidas por algunas personas. Esto es demasiado
peligroso, pero debería haberse hecho antes, y tiene que hacerse antes de
41¡t Dasarrollo y gestión de proyectos informáticos
poder finalizar el proyecto. Si no se puede conseguir que las partes ari:-

iadas se pongan de acuerdo con un conjunto de prestaciofl€S ctláIldtr
i,
proyecto está pendiente de un hilo en modo de recuperación, entonc;*
ganar'
será -e¡ot dejarlo. Está luchando en una batalla que no puede
Después de obtener un conjunto de requerimientos, ponga muy alto r-
listón para aceptar cambios. Tómese incluso un día completo para considsF¡
,rn.u*bio. Exija como mínimo un día para implementar un cambio (esl'x
plazos son par; cambiar las prestaciones' y no para corregir los defectos
pre-
REFERENCIA Recorte del conjunto de prestaciones. El modo de recuperación
al conjunto mínirnt'
CRUZADA senta una oportunidad para reducir los requerimientos
Para obtener más
información sobre el aceptable. Éh*itr. las prestaciones de baja prioridad de forma implacable
No necesita corregirlo iodo, ni tampoco es necesario que implemente
recorte de tod¿-¡
requerimientos, véase este puntt-'
las prestaciones. Establezca prioridades. Recuerde que llegado
"Filtrado de posible. r''
requerimientos", en la el pioblema real no es desarrollar el producto en el menor tiempo
para la sr
creur el mejor producto posible: es terminar el producto' Deje
Sección 14.1-
guiente u"r.ióflu, preocupaciones sobre las prestaciones de baja prioridad

En esta fase, el personal tendría que estar preparado y dispuesto para
definir un conjunto de prestaciones mínimo. Si cuando el proyecto esu
en modo de recuperación el personal no está dispuesto a sacrificar
sus
prestaciones preferidas, probablemente no 1o estará nunca'
Evalúe su posición política. Si el personal no está dispuesto a congelar

los requerimientos o a replegarse hacia las prestaciones mínimas' es un
buen momento para retroceder un paso y mirar lo que le está sucediendo
realmente en el proyecto. Piense por qué las otras partes aún no se han
centrado en el próducto. ¿En qué están centradas? ¿Qué es más importante
para ellos que el producto? ¿Están centrándose en una lucha de poder'l
¿ertatt centrándose en desprestigiarle a usted
o a su jefe? Aunque sean
iontas, las tensiones políticas existen dentro de una empresa' y un signo
indicador de su existéncia es la desgana para suscribir compromisos im-
portantes cuando no hay otra opción. Si se ve atrapado en medio de una
pelea política más que en el desarrollo de un producto, el plan de recupe-
iación del proyecto descrito en este capítulo no será de mucha ayuda' 1-
tendrá que actuar en consecuencia, escogiendo sus propias acciones.
REFERENCIA Eliminar la basura. Averigüe si hay algunas partes del producto que
CRUZADA todos saben que tienen una calidad extremadamente baja. Cuando encuentre
Para obtener más
detalles, véase muchos defectos en un segmento en particular del código, resulta tenta-
"Módulos propensos dor pensar que ha encontrado el último. Pero los módulos problemáticos
a erfores>, en
la Sección 4.3. tienden a pioducir una continua y asombrosa cascada de defectos. Los
módulos propensos a errores son los responsables de una cantidad de tra-
bajo desproporcionada en un proyecto, y es mejor eliminarlos y comenzar
de nuevo que continuar trabajando con ellos.
Elimínelos. Entre en un ciclo de diseño. Revise el diseño. Implemente

el diseño. Revise la implementación. Es posible que le patezca que no se
puede permitir este trabajo cuando está en modo de recuperación, pero lo
que le tendrá en vilo en el modo de recuperación es verse acribillado por
un incontrolable número de defectos. volver a diseñar e implementar de
forma sistemática reduce los riesgos.
Reducir el número de defectos y mantenerlos a raya. Los proyectos

que tienen problemas con la planificación suelen comenzar centrándose
en la planificación y enrealizar reducciones, sin tener en cuenta la calidad.
Esos compromisos vuelven a atormentar irremisiblemente a los desa-
rrolladores antes de la entrega del producto. Si lleva mucho tiempo diciendo
que quedan 3 semanas. es casi seguro que durante ese tiempo estará ha-
ciendo compromisos y reducciones de calidad, lo que hará que el proyecto
dure más envez de acortarse.
Comience utilizando un <gráfico de defectos pendientes>> y actualíce-
lo a diario. La Figura 16.2 muestra un ejemplo.
El objetivo del gráfico de defectos pendientes es hacer énfasis en el
número de defectos pendientes que hay, y destacar la prioridad de redu-
cirlos. Lleve el número de defectos pendientes a un nivel manejable, y
manténgalo a raya. Comience realizando revisiones de código y diseño
para mantener un bajo nivel de defectos. El tiempo de desarrollo se desper-
dicia al trabajar y volver a tabajar en software de baja calidad. centrarse
en la calidad es una forma de reducir el tiempo de desarrollo, y hacerlo
así es esencialpara la recuperación de proyectos.
REFERENCIA
CRUZADA
Para obtener más
detalles sobre por qué
este gráfico reducirá
defectos, véase
el Capítulo 26,
"Medidas". Defectos
----- Detectados
f_-l Resueltos
Fl7il Corresidos
ffiRoiertos
Tiempo
Figura 16.2. Ejemplo de un gráfico de *defectos pendientes.. La

publicación de este gráfico acentúa que la reducción de defectos tiene una
alta prioridad, y ayuda a recuperar el control en proyectos con problemas
de calidad.
It16 Desarrolio y gestión de proyectos informáticos
3EF-Eq=NCIA Alcanzar un estado correcto conoc¡do, y partir del mismo. Trace e[

3BuZADA
3az ñieêr más
camino más corto posible desde dondequiera que esté su producto en esrc
gaY€s- consulte el momento hasta un estado en el que pueda construir y probar algún sutr-
Capíiulo 18,
conjunto del mismo. Cuando lleve el producto a ese punto, utilice la con-.-
*Construcción y
crueba diarias". trucción diaria para mantener el producto en un estado en el que se puede
construir y probar cada dia. Incorpore código a la consffucción y asegúr*r
que el código que incorpore no rompa el producto. Mantenga la constnx-
ción dentro de una prioridad máxima. En algunos proyectos, los desarroll¡-
dores llevan buscapersonas, y son requeridos para corregir la construc-
ción de día o de noche, si son responsables de su ruptura.
Temporización
De forma sorprendente, el mejor momento para aplicar un plan de recupera'
ción de un proyecto podría no ser el primer momento en el que se adviertc
que el proyecto tiene problemas. Necesita asegurarse de que la directir-a r
el equipo de desarrollo ya han captado el mensaje, y están preparados
para llevar a cabo los pasos necesarios para recuperar verdaderamente el
proyecto. Esto es algo que necesita hacer bien 1a primera vez.
Hay que tomar una posición entre dos consideraciones. Si el plan de
recuperación se emprende demasiado pronto, el personal aún no cree quÉ
haya necesidad de hacerlo. No conviene gritar ¡el lobo! antes de que los
demás puedan ver que el lobo está ahí. Si empieza demasiado tarde. es
probable que se vea envuelto en una serie de correcciones o miniintentos
de recuperación, que no funcionarán completamente, y disminuirán su
credibilidad de cara a reaTizar un esfuerzo de recuperación más efectivo-
a mayor escala. Tendrá que gritar <¡el lobo!> demasiadas veces.
No le recomiendo que consienta que su proyecto vaya mal simplemen-
te para que pueda hacer un mejor trabajo de recuperación. Sin embargo. si
el proyecto ya tiene problemas, le recomiendo que temporice la presenta-
ción de su plan de recuperación, de forma que todos los participantes en
el proyecto estén suficientemente receptivos y pueda tener éxito.
Ejemplo 16.2. Recuperación con éxito de un proyecto

pare,intsntarlo de suerro. Llamó a su despacho a Carl, quien,había rldo¡el

responsable del equipo del proyecto cancelado. Carl no reconocia a sujele.
,<Carl, he decidido resucitar el ICS 2.0. y voy a darte otra oportunidad.
Reúnete con Charles. Es un experto en recuperación de proyectos. y voy a
contratarlo para que te ay'ude a encarrilar esto. Ya me ha comentado que no
p*ede,propgner- inmeéiatá.meute' una nueva planihcación. Me ha difu que
,p¡dri¿tta.t4q{unas,cualtal sernanas antss de saber exactamente cuánto tiempo
'tardará enco_rregir etgqolleeté;:Realmente me be echado atrás en ia ldea de
cancelarlo. de forma que ahora tenemos que terminarlo sin imponar cómo'
Llámame tan pronto como tengas una nueva planificación.,r
:. rr: Cflrl éstaba'conten!ó de'iener otra,opoitunidadpara recriperar el pro-
yecto. Había pensado en algunas cosas que podría hacer mejor..y sabia que
,ietrtrifer,yr,foé,se deprimieron cuando el proyecio,se cánceló' É1 Y,Charles
salieron juntos del despacho de Bill.
:' , ,,
Q!¿¡|es comenzé dicienda: <<For'ló qug he'oido,:crp¡,qüe la taroá pqin¡
cipal es simplemente finalizar el proyecto. Me gustaría identificar las con-
diciones de éxito de cada grupo, y luego gestionarel reslo del proyecto de
, fuffiqque.¡e g¡¡mpIán. Según Jos usrrarios finatre$"d0n',los qaq,'he habl4do,
sustituir el antiguo sistema para final de año seria un gran logro si resolvie-
ra algunos problemas arraslrados desde hace varios años. Tengo una,lista
,
'¿o¡.losrproblertras
piinejpales, y:rJos usUárioÁ,f,iüa{és pstarárr ds acuerdo en
.,,que,:el rest podria espérar,'::tresde'lyego que.les' gust¿iia que'la siguienle
:r'
versión eitwieü tarl pláütó óomo ñrela posible, peré iealmente lo que desean
es una garantía de que la van a tener.
Las condiciones de éxito de Bill son las mismas. Desea seguir con el
grupo de usuarios. ¿Qué necesitas para tener éxito?,r
Carl se quedó pensando durante un minuto. <Necesito mostrar que puedo
'reeupsrar este proyecfo y saaisfacer las coadiciones de éxito de tgdo,ef
mundo- He descansado, y podré tabajat tanto cotlr{ $qa'necosario,n A1 fl-
, nal áel dia, CarI habló con Jeanifer, Joe y.Kip, asFt{aliqry$ gran que
,Sg.l
necesitabar¡ termi¡ar e1 trabajo qle'habfan eg.:¡€z$9'¡ y,{trvar,a1 mísmo
<No puedo sacrificar el resto de mi vida en este proyecto>, dijo Jen-

'sernánas,.dC .nácallone,s; €s!ó.y demaiiado
nifer. <rlncluso:después.'dá.'3
quemada para ello. Sería agradable terminar este proyecto, pero prefiero
, trabajar en us proyecto difgrénté:rllr.no'térmiffir nünrq,éste;r;d1Ie;vclver a
qr¡emarrne de nuevo,i¡rKip,díjd que,,estaba, dílpubsto,,a !rcbajar duro; pero
Joe dijo que se senría como Jennifer.
Charles preguntó al equipo sobre lo qué creian necesario hacer para
salvar ei proyecto, y Jennifer,y,;Jpe'estab4g eompletamente de acuerdo.
:,,
<Nosolros teniamos tantá prisa la.última vez que utilizamos toda clase de
:.rlrucss de baja caiidad, Necesitame¡'s volver,átráb:y elirninar átrgunás cosas
del producto. Esta vez no deberíamos añádir personal nuevo.t Carl asintió.
No deseaba cometer dos veces los mismos errores.
Charles tomó la iniciativa. <Me gustarÍa que todos elaboraran una lista
lconrintia )
It18 -lesa':o.,o y gestión de proyectos informáticos
óeta11@;q.g.ifi,4Eei,lry or."s 1lr. son neceqa11a5.,,p.ára salEar. el producto-

sin olvidar ninguna. Reescribir los módulos defectuosos, corregir los scripr
de construcción- estáblecer el control automático de versiones, docum+
tar el código antiguo. copiar disqueies. habtar por teléfono con los usua-
iios finales, todo. Y quiero.que estimen cuánto riempo durará cada tarea-
lj Tl.r algunas tareas.que van a tardar más de 2 días, me gustaría que las
dividieran en tareas más pequeñas que Ilevaran menos üernpo. Entonces
rios sentaremos y planifica¡emos el resto del proyecto.
Deséó que sepáis que vuestras estimaciones no son compromisos. Son
sólo estimaciones, y nadie fuerá de esta habitación sáura de ellas hasta que
estemós seguros de que éstán bién. Sé'que estoy pidiendo demasiados
detalles.i que llevará tiempo hacer rodas efas eslimaciones. No me sor-
prende que necesitéis al menos un dia para preparartai. pero este proyecto
esiá hundidó. y esto es lo que tenemos que hacer para ponerlo en buen
Los desarrollador.. .*pl.u-r' ios z días siguientes proponiendo listas

de tareas increíblernente detalladas- Joe'estaba sorprendido con algunas de
sus estimaciones. cogió las tareas que originariamente babia estimado que
. tardarian 3 días, las dividió en partes más detalladas, y enc.ontró que. la
i
suma de las partes de algunas de ellas llevarían más de o 6 días. cúarles
dijo que el no estaba sorprendido. El grupo completo creó r,ma planifica-
ción basándose en las listas de tareas.detalladas, y charles le diio a Bill
que tendrían una nueva lecha de finalización en 1.5 días.
Cart y Charles compiobaron los progresos del equipo todos los días
,j.:,idli,á*i¿,i¡isemana¡:iigente,..flp,,figi¡d*ür tu¡.qu. .a-11.*po {enaifárse
encontró con que un día terminó todo su trabájo.a media tarde. y otro día
había trabajado hasta las 9:00 de la noche. Esraba haciendo eJ trabajo. pero al
final dé la semana había trabajado casi 50 horas. Le drjo a carl qu. .ru'd.-u-
siado. Joe había tenido problemur pá* terminar sus t¿urcas a tiempo. y al final
de la semana sólo había terminado la mitad de lo que había planificado.
El equipo se reunió para ver sus progresos. iharles insistió en re-
calibrar la planificáción de Joe, multiplicando todas sus estimaciones
por 2. Aunque Jenniler estaba cumpliendo sus plazos, les recordó que. las
condiciones de Jennifer inclulan llevar una vida normal fuera del traüajo. y
recalibraron su planificación multiplicando su estimación por 1,25. La re-
calibración hizo que las planificaciones de rodos se descompensaran, de
forma que tuvieron que reorganizar el trabajo para que todos los miembros
del equipo ruvieran Ia misma cantidad de. trabajo.
Carl estaba sorprendido del resultádo. Si su estimación fuera correcta,
.
podrían te.rminarel proyecto en l0 semanas. lo cual no era tan malo como
había temido. <¿Debería comun¡cailé a Birl rás buenas.noticia*?o, preguo-
tó a Charles.
- <No, traba¡aremos otra semana en ra nueva franificación. y si ros mini-
hito_s van bien, enronces se lo diremos a Bill. pero le dirernos á eitr que
tendremos la planificación revisada .n uná r"*uni a pafiir del runes.,> '
(contintia)
T I
La siguiente semana fue sorprendentemente Lranquila. Carl continuó

consultando a Ios desarrolladores todos los días para asegurarse de que
cada una de las tareas de los hitas miniatura se esfaba hacíendo, y era:asi; ,
Jennifer se quedó tarde una noche. pero le diio a Carl que principalmenle
se quedó porque había perdido pane del día. no porque ruriera mucho tra-
bajo que hacer. A] final de la semana. todos habian cumplido la planific,a-
ción. Más importante aún. todos estaban lelices. Jenniler habia pensado en
un principio que se iba a sentir presionada por la microgesiión de lo" hitos
miniatura, pero eo e$ter momento tenía'la buena impresióa de que era posi-
ble terminarunataree oada día, y decir a todos q*e estaba progresando. La
rnoral babía me.jorado.
Carl y Charles le dijeron a Billque terminarían en 9 semanas. Bill drjo
que eran buenas noticias y que había merecido la pena esperar. tn el resto
del proyeeto, Charles y Carl tontinuaron-aomprobando los progresos a diario,
Todos se quedaban algunas noches hasta tarde para mantener sus planifi-
eaciones de los minihitos, pero al final de las 9 semanas tetminaron ¡eal-
rnente del todo, Entregaron ql software a,lot usuarios finales y se lo comu-
,nicarsn a Bill. Todos consideraron el proyecto como ul éxito.
McCarthy, Jim'. Dvnamics of Software Development. Redmond, Wash.:
Microsoft Press, 1995. Es un conjunto de lecciones muy entretenidas
que McCarthy aprendió a 1o largo de su experiencia trabajando con
Visual C++ de Microsoft y otros productos. McCarthy describe con
mucho entusiasmo 1a visión del desarrollo del software en Microsoft,
pero es realmente inflexible. Describe 1os proyectos de Microsoft como
si emplearan casi todo su tiempo haciendo 1o que en este capítulo se
ha llamado <recuperación de prol'ectos>. Si reconoce que eso es 10
que McCarthy está escribiendo y lee su libro desde ese nir e1. tiene
cosas importantes que decir.
Zachary, Pascal: Showstopper! The Breakneck Race to Crectte ll'indotrs
l¡lT and the Next Generatíon at Microsoft New York: Free Press, 19911.
E,s una descripción del desarrollo de Windows NT 3.0 de Microsoft.
De acuerdo con la descripción del autor, el proyecto NT estuvo más
tiempo en modo de recuperación que en el desarrollo normal. A1 i-gual
que el libro de McCarthy, si se lee como una lectura de recuperación
de proyectos, se pueden obtener algunas lecciones interesantes. Una
vez que haya ieído el libro, ¡estará feliz de no aprender estas leccio-
nes con su propia experiencia!
Boddie, John'. Crunch Mode. New York: Yourdon Press, 1987. Este libro
no es específico sobre recuperación de proyectos, pero trata sobre cómo
420 D€se:rs,ti,'s y gestión de proyectos informáticos
desarrollar software bajo planificaciones estrictas. El enfoque c; :

se puede aplicar bastante a un proyecto en modo de recuper';-:nr
Weinberg, Gerald M: Quality Software Management, Volume I 5
Thinking. New York: Dorset House, 1992. La presión es r:-j
pañía constantes durante la recuperación de un proyecto. Li'r
tulos 16 y 17 de este libro tratan sobre lo que Weinberg i=:.
(patrones de presión>. Describe 1o que les sucede a los de>--:
dores y a los responsables bajo tensión, así como 1o que es ni;:
hacer para controlarlo.
Thomsett. Rob: cProject Pathology: A Study ol Project Failure=
rican Programmer, julio 1995, B-16. Thomsett realiza una r:i-
profunda sobre los factores principales que hacen que los pri,,
se encuentren con problemas, e indica los signos prematurrls ;d
están en problemas.
---:ü¡--...-.--..-------.--.*-'-- -
-:
lntroducción a los métodos
recomendables
Esta parte del libro contiene 2'7 <<métodos recomendables>:
Capítulct l7 Grupo de control de cambios

Capítulo l8 Construcción y prueba diarias
Capítulo l9 Diseño para el cambio
Capítulo 20 Entrega evolutiva
Capítulo 21 Prototipado evolutivo
Capítulo 22 Definición de objetivos
Capítulo 23 Inspecciones
Capítulo 24 Desarrollo conjunto de aplicaciones (JAD)
Capítulo 25 Selección del modelo de ciclo de vida
Capítulo 26 Medidas
27 Hitos miniarura
Capírtrlo
Capítulo 28 Desarrollo externo (Outsourcing)
Capítulo 29 Negociación conveniente
Capítulo 30 Entornos productivos
Capítulo 3l Lenguajes para el desarrollo rápido (LDR)
Capítulo 32 Filtrado de requerimientos
Capítulo 33 Reutilización
Capítulo 34 Compromiso (Signing up)
Capítulo 35 Modelo de ciclo de vida en espiral
Capítulo 36 Entrega por etapas
Capítulo 37 Gestión Theory-W
Capítulo 3B Prototipos desechables
Capítulo 39 Desarrollo en ventanas temporales
Capítulo 40 Grupo de herramientas
Capítulo 4l Lista de los 10 riesgos principales
Capítulo 42 Prototipado de la interfaz de usuario
Capítulo 43 Horas extras voluntarias
La tabla resumen de ejemplo de método recomendable mostrada en ia

Figura III.1 es un ejemplo de las tablas resumen que describen las carac-
terísticas que definen cada método. Leyendo cada uno de los resúmenes
de los capítulos del 17 al 43, debe poder determinar cuáles son los méto-
dos apropiados para su proyecto u organización.
422
-l
100
Ejemplo de tabla resumen

de método recomendable
Cada método recomendable tiene una tabla resumen que
describe las caracteríslicas que definen dicho método.
Leyendo los resúmenes de los capítulos del 17 al 43, debe
poder determinar cuáles son los métodos apropiados para
su proyecto u organización.
Ef icacia
Reducción potencial Ninguna (=0%), Media (0-10%),
de la planificación Buena (10-20%), Muy buena
nominal (20 -30'/.), Excelente (30%+)
Meiora en la visibilidad Ninguna (=0%), Media (0-25%),

del progreso Buena (25-50%), Muy buena
(50-7 5%), Excelente (7 5"k+)
Efecto sobre el riesgo Disminuye el riesgo, Sin efecto,

de la planificación Aumenta el riesgo
Posibilidad de éxito Baja (=0-20%), Media (20-40"/"),
inicial Buena (40-60%), Muy buena
(60-80%), Excelenle (80-100%)
Posibilidad de éxito Baja (=9-267"¡, Media (20-40%),
a largo plazo Buena (40-60%), Muy buena
(60-80'/"), Excelente (80-1 00%)
Riesgos principales
o Esta sección resume los riesgos principales añadidos
por este método en el resto del proyecto. No incluye los
riesgos para tener éxito con el propio método.
lnteracciones y equil¡brios principales

. Esta sección resume las principales interacciones del
método con otros métodos, y el equilibrio de factores
implicados en el uso del método.
Figura lll.1. Ejemplo de tabla resumen de método recomendable, con

explicación de sus característ¡cas.
423
424 5esa,'re¡io y gestión de proyectos informáticos
Los capítulos de esta parte del libro describen los métodos recom*-
dables para desarrollo rápido. Estos métodos representan el estado o¿:
arte acfual en la velocidad de desarrollo. Algunos de ellos Son rue'tx
otros han sido utilizados durante 20 años o más. Algunos de elros pa=-
cen cuestiones de sentido común (¡ojalá se utilizara en general el sentiü
comúnl). otros puede que no parezaan métodos recomendables hasta qu
lea el capítulo correspondiente.
Estos métodos no están pensados para ser usados todos simultáne-
mente. Algunos de ellos son mutuamente excluyentes. pero probablemen::
encontrará algunos que puede usar en sus proyectos en curso sin modifr-
car radicalmente su enfoque para el desarrollo de software. otros mét.*
dos pueden parecer tan atractivos que deseará modificar radicalmente s*
enfoque de desarrollo para poder utilizarlos.
organizac¡ón de los capítulos de métodos recomendables

Todos los capítulos de métodos recomendables están organizados de for-
ma similar. Cada uno comíenza con una tabla como la del ejemplo mo;-
trado al inicio de este capítulo. La tabla presenta un resumen de ra efica-
cia, riesgos, interacciones y equilibrios de cada método. cada comentario
del resumen es explicado con más detalle en el cuerpo del capítulo.
Las primeras tres entradas del apartado <E,ficacia> de la Figura III.I
describen los tres tipos de mejoras en la planificación descritos en la Sec-
ción1.2, <Cómo lograr el desarrollo rápido>:
o Reducción potencial de la planificación nominal.

. Mejora en la visibilidad del progreso.
¡ Efecto sobre el riesgo de la planificación.
Los siguientes párrafos explican estas tres entradas y el resto de la

información de la sección de resumen de métodos recomendables.
<Reducción potencial de la planificación nominal>>. Esta entrada

contiene una estimación del efecto del uso del método sobre la planifica-
ción del proyecto. Todas las posibles reducciones suponen qr. él método
se ejecuta de forma experta. Generalmente, en los proyectos en que se use
un método por primera vez, se cometerán errores que reducirán la efica-
cia del método.
Esta clasificación se realiza de forma verbal (Ninguna, Media, Buena,
Muy buena y Excelente) en lugar de una escala numérica. La tabla de
ejemplo de método recomendable de la Figura III. I muestra la correspon-
dencia aproximada entre esta escala verbal y las reducciones en porcenta-
je. En algunos casos, la base de la reducción en porcentaje ha sido estima-
lntroducción a los métodos recomendables 425
da por otros, y se describe en la sección (Puntos cruciales) incluida en el

capítulo; en otros casos es mi mejor estimación de la eficacia del método.
Puede trasladar la escala verbal a rangos de porcentajes, pero la escala
verbal es la mejor descripción de la posible reducción. Generalmente, el
estado del desarrollo de software no permite que aleuien utilice expresiones
precisas como <<el prototipado reduce la planificación en un 34,27 por 100>>.
Un estudio puede encontrar que el prototipado reduce el trempo de desa-
rro1lo en un 25 por 100; otro podría detectar que lo ha reducido en un 45
por 100. Un tercero podría no encontrar ningún ahorro. La escala verbal
refleja la imprecisión de los datos subyacentes.
REFERENCIA (Meiora en la visibilidad del progreso)>. Esta clasificación también

CRUZADA
está dada en una escala verbal en lugar de una numérica. Es dificil concretar
sobre el modelo de algo tan amorfo como <<Mejora en la visibilidad del progreso>, y he crea-
ciclo de vida en do la mejor aproximación posible definiendo la mejora como el porcentaje
cascada, consulte la
Sección 7.1, "Cascada del proyecto que un método hace visible respecto a un modelo de ciclo de
pu ra" ' vida tradicional en cascada. Las clasificaciones de esta categoría surgen
de mis propias estimaciones. De nuevo, hay una correspondencia aproxi-
mada entre la clasificación verbal y la cuantificación subyacente, pero la
clasificación verbal expresa mejor la inexactitud de los datos.
(Efecto sobre el riesgo de la planíficación>. Algunos métodos, como

el prototipado evolutivo, disminuyen generalmente el tiempo de desarro-
l1o en comparación con los métodos tradicionales, pero hacen más difícil
predecir específicamente cuándo va a terminar el proyecto. Un esfuerzo
de desarrollo tradicional puede requerir un promedio de tres meses, con
una variación de más/menos dos semanas. Un enfoque con prototipado
evolutivo del mismo proyecto podría requerir un promedio de dos meses,
y variar en fS ssrx¿nas/-2 semanas. Se considera que estos métodos in-
crementan el riesgo de la planificación. E,sta clasificación (Disminuye e1
riesgo, Sin efecto, Aumenta el riesgo) indica si un método mejora la posi-
bilidad de cumplir un plazo específico, no le afecta, o la empeora.
He incluido algunos métodos como métodos recomendables específica-
mente porque tienen un fuerte efecto positivo sobre el riesgo de la plani-
ficación. Pueden tener o no una ligera influencia sobre la duración media
de la planificación, pero ayudarán a controlar fluctuaciones salvajes de la
planificación, y ayudarán a poder volver a controlar planificaciones in-
controladas.
<Posibilidad de éxito inicial>. Algunos de los métodos son más difí-

ciles de aprender a usar que otros. Con algunos métodos, puede esperar
tener éxito inmediatamente; en otros, es posible que tenga que esperar a
obtener la recompensa posteriormente. Algunos métodos (como la reuti-
lización) requieren un gran esfuerzo en infraestructura antes de empezar
-l
lntroducción a los métodos recamendables 427
o Uso del método recomendable.

a Gestión de los riesgos del método recomendable.
a Efectos secundarios del método recomendable.
a Interacciones del método recomendable con otros métodos.
a Puntos cruciales del método recomendable.
o Claves para el éxito en el uso del método recomendable.
a B ibliografía adicional.
Resumen de los candidatos a métodos recomendables

REFERENCIA cada método descrito en un capítulo de métodos recomendables ha sido
CRUZADA
Para más información seleccionado por una de las siguientes razones:
sobre los tres tipos de
métodos relacionados
con la planificación,
a Reducción de las planificaciones de desarrollo.
consulte la a Reducción de las planificaciones de desarrollo percibidas, hacien-
Sección 1.2, "Cómo do más visible el progreso.
lograr el desarroilo
ráPido". Reducción de la volatihdad de la planificación, reduciendo la opor-
tunidad de que el proyecto se descontrole.
Algunos de los métodos recomendables están descritos en la parte I

de este libro, y estos métodos recomendabres simplemente están resumidos
en esta parte del libro.
Podría preguntarse: <¿por qué ignora ros gráficos de estructuras de obje-
tos FooBar, que son mi método favorito?> Ésta es una cuestión que me
he
planteado mucho a io largo de la creación de este libro. una técnica
candi-
data a método recomendable puede ser excluida por una de varias razones.
Métodos pertenecientes a las bases del desarrollo. Muchos candi-

datos a métodos recomendables entran dentro de la categoría de los
métodos
fundamentales del desarrollo. uno de los desafío, u ,.,f"ru. al escribir
este
l1b1o ha sido evitar que se convierta en un manual general
de ingeniería
del software. De cara a mantener el libro dentro de un tamaño razonable,
he introducido estas técnicas en el capítulo 4, <<Bases del desarrollo
de
software>, y he ofrecido referencias a otras fuentes de información.
Hay
mucha información disponible en otras fuentes sobre métodos fundamen-
tales.
En algunos pocos casos, podría considerar correctamente que un mé-
todo es fundamental, pero si tiene un profundo impacto en la velocidad
de
desarrollo, 1o he incluido de todos modos como método recomendabie
en
estos capítulos.
Filosofía recomendabre, pero no método recomendabre. Aigunos

candidatos a métodos recomendables parecen ser más bien teorías
o filo-
I
I
I
1
-_
428 )es..-3 :s ,,, gestión de proyectos informáticos
sofias que técnicas. La distinción entre teoría, práctica y filosofía no es.:

clara en el desarrollo de software, y por ello, un método al que yo l1an.
una .<filosolía,, podría ser visto por olros como una <<técnica>>. y vice\er-
sa. Independientemente de como se llame, si considero que es (recomenda-
ble>, lo trataré en algún punto del libro. Pero si considero que es una filoso-
fía estará en la primera o segunda partes del libro (véase la Tabla III.1
para ver una lista de dónde se trata cada filosofía recomendable).
Puede ser un método recomendable, pero no para la velocídad de

desarrollo. Algunos candidatos a métodos recomendables pueden ser
perfectamente métodos recomendables por su efecto sobre la calidad o la
facilidad de uso, pero es posible que no pasen las pruebas de mejora de
las planificaciones actuales, las planificaciones percibidas o la volatilidad
de la planificación. Estos métodos no han sido incluidos en este libro.
Evidencia insuficiente de la ef¡cac¡a de un método. Algunos mé-

todos prometedores aún no han aportado la evidencia suficiente para ser
elevados a la categoría de métodos recomendables. Si la comunidad de
desarrollo todavía no tiene suficiente experiencia sobre un método para
publicar informes sobre su experiencia con é1, no lo he incluido. Sin duda.
algunos de los métodos que entran en esta categoría probarán algún día
que producen grandes beneficios en la velocidad, y los incluiré en una
edición futura de este libro.
En algunos casos en los que las publicaciones en sí no eran suficien-
tes para justíficar
1raf.ar un método como método recomendable, he tenido
experiencias personales con ese método que me han convencido de que
era un método recomendable. Los he incluido a pesar de la falta de publi-
caciones que los apoyen desde otras fuentes.
Evidencia cuestionable de la eficacia de un método. Algunos can-

didatos a métodos recomendables parecen prometedores, pero la única
información publicada que he podido encontrar era de sus vendedores o
de otras fuentes que tienen intereses en la promoción de los métodos, por
lo que los he excluido.
No ser un método recomendable. Algunos candidatos a métodos re-

comendables son muy bien vistos (incluso celosamente guardados) en al-
gunos lugares, pero esto no los convierte en métodos recomendables. En
algunos casos, los informes sobre experiencias reales indican que un mé-
todo bien visto falla generalmente a la hora de cubrir las expectativas. En
conclusión, un método puede ser un buen método, pero no un método
recomendable. En otros casos, el método funciona maravillosamente cuan-
do funciona, pero falla demasiado a menudo para ser considerado un mé-
iodo recomendable.
l
En un caso (RAD), el método candidato consiste en una combinación

de muchos de los restantes métodos descritos en este libro. podría ser
perfectamente una combinación eftcaz en algunas circunstancias. pero
como este libro defiende la selección de métodos de desarrollo rápido que
cumplan las necesidades de su proyecto en particular, esta comtinación
específica predetermin ada de métodos no ha sido considerad.a en sí como
un método recomendable.
sé que muchos lectores seguirán preguntándose cómo he clasificado los
métodos específicos, como los gráficos estructurados de objetos FooBar
o cualquier otro (lo he hecho). Para satisfacer esta curiosidad, la Tabla III.l
resume los candidatos a métodos recomendables e indica dónde se descri-
ben en este libro o por qué se han dejado fuera.
Esta tabla también puede servir como una referencia exhaustiva de
métodos orientados a la velocidadpara alguien que esté planificando un
proyecto de desarrollo rápido.
Tabla lll.l . Resumen de los candidatos a métodos recomendables
Candidato a método Dónde se hace referencia o razón

recomendable por la que no se incluye
4GL Método recomendable. Véase Lenguajes
para desarrollo rápido (LDR).
Análisis de requerimientos Fundamento.
Arquitectura Fundamento.
Adquisición frente a Fundamento.
planificación y construcción
Herramientas CASE Evidencia insuficiente de la eficacia del
método. Véase <<Herramientas CASE>, en la
Sección 15.5.
Grupo de control de cambios Método recomendable descrito en otro
capítulo. Véase <Grupo de control de
cambios>, en la Sección 14.2, y el resumen
del Capítulo 17.
Desarrollo aislado Puede ser un método recomendable, pero no
para el desarrollo rápido.
Código legible, de alta calidad Fundamento.
Métodos eficaces de construcción Fundamento.
Orientación al cliente Filosofia recomendable. Véase el Capítulo 10,
<<Desarrollo orientado al cliente>.
(continúa)
.F
430 Desarctlo y gestión de proyectos informáticos
Tabla lll.l . (Continuación\
Candidato a método Dónde se hace referencia o raz,in

Construcción y prueba diarias Método recomendable. Véase el Capítu,:

<Construcción y prueba diarias>.
Cuadernos de diseño No se dispone de información suficiente
para considerarlo un método recomenda:-:
Diseño estructurado, orientado Fundamento.

a objetos, etc.
Modelo de ciclo de vida No es un método recomendable. Véase 1:

de diseño por planificación Sección 7.7, <Diseño por planificación,,
Modelo de ciclo de vida No es un métoclo recomendable. Véase l.
de diseño por herramientas Sección 7.9, <Diseño por herramientas,'.
Diseño para el cambio Mótodo recomendable. Véase el Capítulc,
<Diseño para el cambio>.
Educación de la directiva Puede ser un método recomendable, pero
para la velocidad de desarrollo.
Educación del equipo técnico Puede ser un método recomendable, pero

para la velocidad de desarrollo.
Módulos propensos a errores Fundalnento.
Herrarnientas automáticas Fundamento.
de estimación
Estimación y planificación Filosofía recomendable. Véanse el Capítulc

preci sas <Estimación>>, y el Capítulo 9,
<Planificación>.
Modelo de ciclo de vida Método recomendable. Véase el Capítu1o i
de entrega evolutiva <Entrega evolutiva>.
Modelo de ciclo de vida Método recomendable. Véase el Capítu1o I
de prototipado evolutivo ,, Protol ipado evolutivo,,.
Control del conjunto Filosofía recomendable. Véase el Capítu1o lr

de prestaciones <Control de1 conjunto de prestaciones>.
Definición de objetivos Método recomendable descrito en otro
capítulo. Véase <Definición de objetivos>,
en la Sección 11.2, y el resumen del
Capítulo 22.
Contratación de personas Fundamento. Véase <Personas>" en'la
brillantes Sección 2.2.
br-
Tabla lll.l . (Continuación)
Candidato a método Dénde se hace referencia o razón

Ingeniería de la informacrón No hay suficientes evidencias de la eficacia

del método.
Inspecciones Fundamento. Método recomendable descrito
dentro de otro capítulo. Véase
<Inspecciones>>, en la Sección 4.3, y el
resumen del Capírulo 23.
Estrategias de integración Fundamento.
Desarrollo conjunto Método recomendable. Véase el CapiítJro 24, ii
de aplicaciones (Joint <Desarrollo conjunto de aplicaciones (JAD)>. 1i
ii
Application Development, JAD)
Planificación conjunta No es un método recomendable. Véase ii
de requerimientos (JRP) <Planificación JAD>, en la Sección 24.1. i;
Liderazgo Fundamento.
Selección del modelo de ciclo Método recomendable descrito en
de vida otro capítulo. Véase el Capítulo 7,
<Planificación del ciclo de vida>, y el
resumen del Capítulo 25.
Medidas Método recomendabie. Véase el Capítulo 26,
<Medidas>.
Reuniones eficientes Fundamento.
Hitos principales No es un método recomendable. Véase
el recuadro <Hitos principales>, en la
página 522.
Hitos miniatura Método recomendable. Véase el CapitltIo 27,
<Hitos miniatura>-
Especificación mínima No es un método recomendable. Véase
<Especificación mínimar>, en la Sección 14. 1 .
Motivación Filosofia recomendable. Véase el Capítulo i i,

<Motivación>.
Tecnología de objetos Fundamento. Véase la Sección 4.2, <Bases
técnicas>.
Desarrollo externo Método recomendable. Véase el Capítulo 28,
<Desarrollo externo).
Horas extras excesivas No es un método recomendable. Véase la
Sección 43. 1 , <Uso de las horas extras
voluntarias>.
(contínúa)
Tabla IIl.1. (Continuación)

Horas extras voluntarias Método recomendable. Véase el Ca¡

<Horas extras voluntarias).
Desarrollo en paralelo Fundamento.
Herramientas automáticas Fundamento.
de planif,rcación
Planificación efectiva Fundamento.
Negociación conveniente Método recomendable descrito efl otrr-
capítulo. Véanse la Sección 9.2, <Disn':--[riumr
de la presión de la planificación>, y el r i¡nüú
del Capítulo 29.
Mejora del proceso Filosofía recomendable. Véanse <Proce- ln
'
la Sección 2.2,y el Capítulo 26, <Med-rnii."
Entornos productivos Método recomendable. Véase el Capírul: 3tl-
<Entornos productivos>.
Herramientas para productividad Método recomendable. Véase el Capitu-; . í
<Herramientas para aumentar la
productividad>.
Control de calidad Fundamento.
Desarrollo rápido de Combinación de métodos recomendable." n¡
aplicaciones (Rapid Application es en sí un método recomendable.
Development, RAD)
Lenguajes para desarrollo Método recomendable. Véase el Capítult- : .
rápido (LDR) <Lenguajes para desarrollo rápido (LDR,.

Análisis de requerimientos Fundamento.
Filtrado de requerimientos Método recomendable descrito en otro
capítulo. Véanse <Filtrado de
requerimientos>, en la Sección 14.1,
y el resumen del Capítulo 32.
Reutilización Método recomendable. Véase el Capítulo 3-:
<Reutilización>.
Revisiones, reuniones y lectura Fundamento.
de código
Gestión de riesgos Filosofía recorrendable. Véase el Capítulc -'
<Gestión de riesgos>.
Herramientas automáticas Fundamento.
de planificación
\conItilt;
Es_
:
Tabla lll.l . (Continuación)

Niveles CMM del SEI Filosofia recomendable. Véanse <<Proceso>,

en la Sección 2.2, y <Bibliografía adicional>
en el Capítulo 2.
Compromiso Método recomendable. Véase el Capítulo 34,

<Compromiso>.
Gestión de la configuración Fundamento.

del software (Software
Configuration
Management, SCM)
Grupo de proceso de ingeniería Método recomendable. Las consideraciones
del software (Software implicadas son muy similares a las
Engineering Process correspondientes a la definición de un grupo
Group, SEPG) de herramientas. Véanse <GruPo de
herramientas>>, en la Sección 15.3, y el
resumen del Capítulo 40.
Control del código fuente Fundamento.
Modelo de ciclo de vida en Método recomendable descrito en otro

espiral capítulo. Véanse la Sección 7.3, <Espiral>,
y el resumen del Capítulo 35.
Especialización de la Plantilla Método recomendable. Véase el Capitulo 13"
<Estructura del equiPoi'.
Niveles de la plantilla Fundamento.

(cuántos y cuándo amPliarlos)
Modelo de ciclo de vida Método recomendable. Véase el Capítulo 36,
de entrega por etaPas <Entrega por etapas).
Programación estructurada Fundamento.
Estructura del equipo Filosofía recomendable. Véase el Capítulo 13,

<<Estructura del equiPo>.
Equipo de trabajo Filosofía recomendable. Véase el Capítulo 12,
<Equipo de trabajo>.
Comprobación Fundamento.
Gestión Theory-W Método recomendable. Véase el Capítulo 37,

<Gestión Theory-W>.
Prototipos desechables Método recomendable. Véase el Capítulo 38,

<Prototipos desechables>.
(continúa)
!f$4 l:,.¡.-s e y' gesl¡ón cie proyectos tniormáticas
Tabla lll.1. lContinuación)

Desarrollo en ventanas Método recomendable. Véase el Capiir:-.- -::

temporales <Desarrollo en ventanas temporalesir.
Grupo de herramientas Método recomendable descrito en oiro
capítulo. Véanse (Grupo de herramien¡¿.
en la Sección 15.3, y el resumen del
Capítulo 40.
Lista de los 10 riesgos Método recomendable descrito en otro
principales capítulo. Véanse <Lista de los 10 riesgo.
principales>, en la Sección 5.5, y e1 resur:::.
dei Capítulo 41.
Seguimiento Fundamento.
Prototipado de la interfaz Método recomendable. Véase el Capítulo :-
de usuario <Prototipado de la interfaz de usuario>.
Negociación <win-win> Véase el Capítulo 29, <Negociación
(para que todos ganen) conveniente>.
Resumen de las evaluac¡ones de los métodos

recomendables
La Tabla III.2 ofrece una comparación conjunta de los métodos recomen-
dables descritos en los capítulos del l1 al 43.
Tabla lll.2. Resumen de las evaluaciones de los métodos recomendables
Nombre del método Reducción Mejora en la Efecto sobre Posibilidad Posibilidad

recomendable potencial de la visibilidad el riesgo de la de éxito de éxito a
planificación del progreso planificación inicial largo plazo
nominal
Grupo de control Media Media Disminuye Muy buena Excelente

de cambios
Construcción Buena Buena Disminuye Muy buena Excelente
¡r prueba diarias
Desarrollo para Media Ninguna Disminuye Buena Excelente
el cambio
(continúa
t-
Tabla III.2. (Continuacíón)
Nomtrre del método Reducción Mejora en la Efecto sobre Posibilidad Posibilidad

nominal
Entrega evolutiva Buena Excelente Disminuye Muy buena Excelente
Prototipado Excelente Excelente Aumenta Muy buena Excelente

evolutivo
Definición de Muy buena Ninguna Aumenta Buena Muy buena
objetivos (Objetivo
de planificación
más corto)
Definición de Ninguna Buena Disminuye Buena Muy buena
objetivos (Objetivo
de riesgo mínimo)
Definición de Ninguna F,xcelente Disminuye Buena Muy buena
objetivos (Objetivo
de visibilidad
máxima)
Inspecciones Muy buena Media Disminuye Buena Excelente
Desarrollo conjunto Buena Media Disminuye Buena Excelente

de aplicaciones
(JAD)
Selección del modelo Media Media Disminuye Muy buena Excelente
de ciclo de vida
Medidas Muy buena Buena Disminuye Buena Excelente
Hitos miniatura Media Muy buena Disminuye Buena Excelente
Desarrollo externo Execelente Ninguna Aumenta Buena Muy buena
Negociación Ninguna Muy buena Disminuye Muy buena Excelente
conveniente
Entornos productivos Buena Ninguna Sin efecto Buena Muy buena
Lenguajes para Buena Ninguna Aumenta Buena Muy buena
desarrollo rápido
(LDR)
Filtrado Muy buena Ninguna Disminuye Muy buena Excelente
de requerimientos
Reutilización Excelente Ninguna Disminuye Mala Muy buena
Compromiso Muy buena Ninguna Aumenta Media Buena
lconrinúa)
436 D€-.aíro"''o y gestión de proyectos informáticos
Tabla lll.2. t Con:ínuacíón)
\ombre del método Reducción Mejora en la Efecto sobre Posibilidad Posibilidad

nominal
\'fodelo de ciclo Media Muy buena Disminuye Buena Excelente

de vida en espiral
Entrega por etapas Ninguna Buena Disminuye Muybuena Excelente
Gestión Theory-W Ninguna Muy buena Disminuye Excelente Excelente
Prototipos Media Ninguna Disminuye Excelente Excelente
desechables
Desarrollo Excelente Ninguna Disminuye Exceiente
en ventanas
temporales
Grupo Buena Ninguna Disminuye Muy buena
de herramientas
Lista de los Ninguna Muy buena Disminuye Excelente Excelente
I 0 riesgos
principales
Prototipado Buena Media Disminuye Exceiente Excelente
de la interfaz
de usuario
Horas extras Buena Ninguna Aumenta Media Muy buena
voluntarias
17
Grupo de control
de cambios
El grupo de control de cambios es un método para controlar los cambios

ffiffi
oe-un'producto software. Trabaja reuniendo representantes de cada
parte implicada (por ejemplo, desarrollo, control de calidad, documen- ffiffi
iación de usuario, sopofte al cliente, márketing y directiva) y dándoles la
máxima autoridad para aceptar o rechazar cambios propuestos. sus
ffiffi
beneficios para el desarrollo rápido se derivan de incrementar la visibi- ffisffi
lidad delcambio de prestaciones y reducir el número de cambios incon-
ffiHffi
trolados sobre el producto. Los grupos de control de cambios pueden
usarse en prácticamente cualquier tipo de entorno (de aplicaciones, ffiffi
"prét-á-porter" o de sistemas). ffiffi
Ef icacia
Reducción potencial de la planificación nominal: Media
Mejora en la visibilidad del progreso: Media
Efecto sobre el riesgo de la planificación: Disminuye el riesgo
Posibilidad de éxito inicial: Muy buena
Posibilidad de éxito a largo plazo: Excelente
Riesgos principales
. Aprobar demasiados cambios o aprobar muy pocos'
lnteracciones y equilibrios principales

. Puede combinarse libremente con los restantes métodos.
Para más información sobre los grupos de control de cambios, réase u Gru-
po de control de cambiosr, en la Sección 14.2
437
18
Construcción
y prueba diarias
El proceso de construcción y prueba diarias (Daily Build and Smoke

Iesf) es un proceso en el que un producto software es construido com- ffiffii
pletamente cada día, y entonces sometido a una serie de pruebas para
WI
comprobar su luncionamiento básico. Este proceso es un proceso de
construcción por etapas, y puede iniciarse incluso cuando los proyectos ffii
ya están en marcha. El proceso genera la reducción de tiempo al dismi-
ffil
nuir la posibilidad de varios riesgos comunes que pueden costar mucho
tiempo (fracasos en la integración, baja calidad y poca visibilidad de
progreso). El proceso ofrece un controlcrítico para proyectos en modo
ffiil
ffi|1
de recuperación. Su éxito depende de la seriedad con que los desarrolla-
dores se tomen el proceso y del buen diseño de las pruebas mínimas.
El proceso de construcción y prueba diarias puede usarse efectiva- i
mente en proyectos de prácticamente cualquier tipo y complejidad.
Éi.i$]ffi:l Eficacia
Reducción potencialde la planificación nominal: Buena
Mejora en la visibilidad del progreso: Buena
É¡S1¡.i!fl,li Riesgos principales
. Presión para entregar versiones intermedias de un programa con
demasiada frecuencia.
":ffi# lnteracciones y equilibrios principales

. Requiere un pequeño incremento en la gestión del proyecto, a cam-
bio de una gran reducción en el riesgo de integración y una gran
mejora en la visibilidad del progreso.
e Es especialmente efectivo cuando se usa junto mn los hitos miniafura.
. Ofrece el soporte necesario para modelos de ciclo de vida de desa-
rrollo incremental.
439
440 -ls-<er:o'ig y, gestión de proyectos informáticos
Si tiene un programa informático simple que sólo consta de un ar;, u-

'
construir el programa consiste en compilar y enlazar el archivo pare --:i[l
un programa ejecutable. En un proyecto típico en equipo que impli;: ru*
cenas, cientos o incluso miles de archivos, el proceso de crear un pr.
-t.-
ma ejecutable es mucho más complicado y requiere más tiempo. E- ¡r*
ducto tiene que ser <construido> (built) para poder ejecutarlo.
En el proceso de construcción y prueba diarias, todo el produc:. s
construido cada día. Esto implica que se compilan, enlazan y comL,'-.r'r.nr
todos los archivos para crear un programa ejecutable cada día. El pr.';;-
to es sometido entonces a una <prueba mínima> (smoke test),una pr:rt¿
relativamente simple para comprobar si el producto <echa humo)) cuarrrr
lo activan.
E,ste simple proceso ofrece ahorros de tiempo significativos en vai.:r
frentes.
Minimiza el r¡esgo de integración. Uno de los mayores riesgos a ,::

que se enfrenta un proyecto consiste en que cuando varios miembros ¡=
equipo combinan o <integran>> el código en el que han estado trabajani:
B¡BLIOGRAFIA
ADICIONAL
de forma separada, su código no funciona bien conjuntamente. Dep*-
Para más diendo de 1o tarde que se descubra esta incompatibilidad en un proyec::.
información sobre la depuración puede requerir más tiempo que si la interacción se hubie:i
la integración del
' software, véase el producido antes (debido a que puede que sea necesario cambiar inter-"-
Capítulo 27, .System ces de los programas, o rediseñar y reimplementar partes principales c;_
lntegrat¡on", en
Code complete sistema). En casos extremos, los errores de integración han causado -:
(McConnell, 1993). cancelación de proyectos. El proceso de construcción y prueba diari.'o
mantiene suficientemenfe a raya los errores de integración, y evita pr.-*
blemas de integración irresolubles.
REFERENCIA Reduce el riesgo de la baja cal¡dad. El riesgo de la baja calidad est¿

CRUZADA
Para más detalles
relacionado con el riesgo de una integración frustrada o problemática.
sobre el efecto de la Probando la compatibilidad del código del producto cada día, se evira que
baja cal¡dad en la los problemas de calidad tomen el control del proyecto. Llevamos el sis-
planificación de un
desarrollo, véase la tema a un estado conocido seguro, y 1o mantenemos en é1. Simplemente
Sección 4.3, "Bases no está permitido deteriorarlo hasta el punto en que puedan producirse
del control de calidad".
problemas de calidad que requieran tiempo para su solución.
Soporta un d¡agnóstico de fallos más fácil. Cuando el producto es

construido y comprobado cada día, es mucho más fácil ver por qué el
producto ha fallado cualquier día determinado. Si el producto funcionaba
el dia 17 y no funciona el día 18, algo ha sucedido entre las fases de cons-
trucción de los días l7 y l8 que ha estropeado el producto. si sólo realiza
una construcción y prueba mensual o semanal del producto, el problema
podría estar en cualquier parte entre el dia 17 y el día 24, o entre el día lj
ERROR CLÁSICO y eldía47.
Capítulo 18: Construcción y prueba diarias 441
Soporta la monitorizacion del progreso. Cuando se construye el sis-

tema cada día, las prestaciones presentes y no presentes resultan obvias.
Los responsables técnicos y no técnicos pueden probar simplemente el
producto para tener idea de lo cerca que está de su finalización.
Mejora la moral. Como dice Fred Brooks, ver un producto que funciona
representa un impulso increíble para la moral. Prácticamente no importa lo
que haga el producto; ¡los desarrolladores pueden estar emocionados
sólo con que presente un rectángulo! Con la construcción diaria, cada dia
funciona un trocito más del producto, y esto mantiene a\tala moral.
Mejora las relaciones con el cliente. Si la construcción diaria tiene

un efecto positivo sobre la moral del desarrollador, también tiene un efec-
to positivo sobre la moral del cliente. A los clientes les gustan los signos
de progreso, y las construcciones diarias ofrecen signos de progreso con
gran frecuencia.
18.1 . Uso de la construcción y prueba diarias

La idea que genera el proceso de construcción y prueba diarias es simple:
construir el producto y probarlo cada dia. Las siguientes secciones des-
criben algunas de las ventajas e inconvenientes de esta idea tan simple.
Construcción diaria. La parte fundamental de la construcción diaria

es construir el producto cada dia. Como dice Jim McCarthy, trate la cons-
trucción diaria como si fuera el pulso del proyecto (McCarthy, 1995c). Si
el corazótt no está latiendo, el proyecto está muerto.
De un modo algo menos metafórico, algunos describen la construc-
ción diaria como el pulso de sincronización de un proyecto (Cusumano y
Selby, 1995). El código de diferentes desarrolladores puede quedar lige-
ramente fuera de sincronía entre los pulsos de sincronización, pero con
cada pulso de sincronización todo el código vuelve a estar afinado- Cuan-
do se insiste en mantener los pulsos suficientemente cerca, se evita que
algunos desarrolladores pierdan completamente la sincronía.
Use una herramienta de construcción automática (como make) para
reducir el trabajo repetitivo asociado con la construcción diaúa.
Comprobar las construcc¡ones fallidas. Para que el proceso de cons-

trucción diaria sea efectivo, el software construido tiene que funcionar. Si
el software no es utilizable, se considera que la construcción ha fallado, y
corregir la construcción se convierte en la prioridad número uno.
Cada proyecto define su propio estándar de lo que considera una (cons-
trucción fallida>. El estándar necesita definir un nivel de calidad sufi-
442 Desarrolto y gestión de proyectos informáticos
clentemente estricto para mantener los defectos graves fuera

de ra cü:_*
trucción diaria, pero suficientemente flexible pari obviar ros
defecros :=
viales (porque una atención indebida a los efáctos triviales puede
pa:.- ,-
zar el progreso).
Como mínimo, una construcción correcta debe:
o compilar correctamente todos los archivos, bibliotecas y otros co=-

ponentes.
o Enlazar con éxito todos los archivos, bibliotecas y otros comF\*
nentes.
o Que no contenga defectos importantes que eviten que el prograr--,¿
pueda ejecutarse o que tenga un funcionamiento iniierto
o Que pase la prueba mínima.
Algunos proyecto definen estándares más estrictos, e incluyen ,c.,

errores del compilador y der enrazad.or, así como sus advertenciar,
en ," .
deliniciones de buena construcción. En cuarquier caso. la prueba consis::
en comprobar si lo construido es suficientemente estable pu.u
,", prob=-
do' Si es suficientemente estable para ser probado, no es iefectuoso.
Prueba mínima diaria. La prueba mínima o de funcionamiento

debr
comprobar el sistema de un extremo a otro. No tiene que ser
una prue rr.
exhaustiva, pero debe poder detectar problemas fundamentales. por det:::-
ción, si 1o construido pasa la prueba mínima, esto implica que es suficiea--:-
mente estable para ser probado, y que es un buen producto.
Sin la prueba mínima, la construcción diaria no tiene sentido. La prutru
mínima indica si 1o construido funciona. Si trata la construcción comc ¡,
pulso del proyecto, la prueba mínima es el estetoscopio que le pern:-::
determinar si el corazón está latiendo. Es la primera línea de comproL,;-
ción, la primera línea de defensa contra el deterioro de los programas. s¡-
la prueba mínima, la construcción diaria es simplemente una forrna c;
comprobar que se obtiene una compilación sin errores.
La prueba mínima tiene que evolucionarjunto con el sistema. Inicia--
mente, probablemente la prueba mínima será algo simple, tal como verii-
car que el sistema puede decir <hola a todos>>. A medida que el sisten:"
progresa' la prueba mínima será más exhaustiva. La primera prueba pr'
dría tardar segundos en ejecutarse. A medida que crece el sistema, la prueb,;
mínima puede llegar a 30 minutos, una hora, o más.
El grupo de construcción debe mantener la prueba mínima como sL
prioridad número uno. La calidad de su trabajo en ra prueba mínima det¡
influir en sus evaluaciones de rendimiento. El grupo de construcción seru
presionado por los desarrolladores para que la prueba mínima no sea dema-
siado <quisquillosa>, así que sus miembros deben ser elegidos entre üi
personal de control dq calidad más que entre los desarrolladores. Indepen-
Capítulo 18: Canstrucción y prueba diarias 443
dientemente de las buenas intenciones de todo el mundo, poner a un desa-

rrollador a cargo de la prueba mínima es como poner una zorÍa a cargo de
un gallinero. Los miembros del grupo deben informar al jefe de control
de calidad en lugar de al de los desarrolladores.
Ésta es una de las áreas en las que resulta muy útil diseñar el sis-
tema pata 1a verificación. La prueba mínima debe ser automalizada, y
en ocasiones es más fácil de automatizar si ha incluido elementos para la
prueba.
Def inir un grupo de construcción. En muchos proyectos, la realización

de la construcción diaria se convierte en una tarea suficientemente grande
para convertirse en parte explícita del trabajo de alguien. En grandes
proyectos, puede ser un trabajo a tiempo completo para más de una per-
sona. Por ejemplo, en Windows NT 3.0 había cuatro personas a tiempo
completo en el grupo de construcci6n(Zachaty,1994). También se requiere
esfuerzo para mantener actualizada la prueba mínima a medida que el pro-
ducto crece y evoluciona.
En proyectos pequeños, puede que no necesite dedicar una persona a
la construcción diaria. En este caso, encárguesela a alg:ún componente del
grupo de control de calidad.
Añada cód¡go al programa sólo cuando tenga sentido hacerlo..'

Aunque la construcción diaria requiere que constuuya el sistema cada dia,
no requiere que los desarrolladores añadan cada línea nueva de código
que hayan escrito para el sistema cada día. Generalmente, los desarrolla-
dores individuales no escriben el código suficientemente rápido como para
añadir incrementos significativos al programa cada día. Trabajan en un
fragmento de código, y luego lo integran cuando tienen un grupo de códi-
go en un estado consistente. Los desarrolladores deben mantener versio-
nes privadas de los archivos fuente en los que están trabajando. Unavez
que hayan creado un conjunto completo de modificaciones, realizan una
construcción privada del programa usando sus modificaciones, las prue-
ban y las marcan como comprobadas.
... pero no espere demasiado para añad¡r el cód¡go al programa.

Aunque hay pocos desarrolladores que entregan código cada dia, Ienga
cuidado con los desarrolladores que tardan en entregar el código. Es po-
sible que un desarrollador esté tan implicado en un conjunto de revisio-
nes que parezca que todos los archivos del programa estén implicados en
ello. Esto debilita el valor de la construcción diaria. El resto del equipo
seguirá contribuyendo a los beneficios de 1a integración incremental, pero
este desarrollador en particular no. Si un desarrollador tarda más de al-
gunos días en entregar un conjunto de cambios, considere que el trabajo
de ese desarrollador es un riesgo.
Exija a los desarrolladores que hagan una prueba mínima de s;

código antes de añadirlo al programa. Los desarrolladores neces,-_-
comprobar su propio código antes de añadirlo a la construcción die: i
SIBLIOGRAFIA
ADICIONAL
Un desarrollador puede hacer esto creando una construcción propia ;=
Para más detalles programa en un equipo personal, que el desarrollador comprueba eni--:-
sobre los métodos de ces individualmente. O bien el desarrollador puede entregar una vers-::
comprobación a n¡vel
de desarrollador, particular a un (comprobador amigo>, un comprobador que se centra --
consulle Wr¡t¡ng Solid el código de ese desarrollador. En cualquier caso, el objetivo es asegura:]:
Code (Maguire, 1993).
de que el nuevo código pasa la prueba mínima antes de que se le pern:-
influir en otras partes del sistema.
Crear un área de reserva para el código que tiene que añadirse al

sistema. Parte del éxito del proceso de construcción diaria depende l=
saber cuáles son las construcciones buenas y cuáles no 1o son. Al probar .-
propio código, los desarrolladores necesitan poder basarse en un siste;:-:
fiable.
La mayoría de grupos resuelven este probiema creando un área ü=
reserva para el código que los desarrolladores piensan que está listo pa:,
ser añadido a 1o construido. El nuevo código pasa a Ia zona de reserva. ..
construye la nueva versión, y si lo construido es aceptable, el nuevo cóc--
go es pasado a las fuentes maestras.
En proyectos de tamaños pequeño y mediano, esta función puede se:
realizada por un sistema de control de versiones. Los desarrolladores el-
tregan el nuevo código a través del sistema de control de versiones. Lr-:
desarrolladores que desean usar una versión certificada como buena, si:--
plemente activan una opción de fecha en su archivo de opciones de col-
trol de versión que le indica al sistema que recupere los archivos basár_-
dose en la fecha de la última versión correcta conocida.
En grandes proyectos o en proyectos que usan un software de contrc_
de versiones poco sofisticado, la función del área de reserva debe hacers.
a mano. El autor de un grupo de nuevo código envía un correo electrónic¡
al grupo de construcción para indicarle dónde encontrarán los nuevos ar-
chivos a entregar. O el grupo puede establecer un área <de entrega> en u:,
servidor de archivos, en el que los desarrolladores pondrán las nuer.es
versiones de sus archivos fuente. En este caso, el grupo de construcció:
asume la responsabilidad de introducir el nuevo código en el control d<
versiones unavez que hayan verificado que el nuevo código no inhabiiir,
lo construido.
Def inir una penal¡zac¡ón por fallar en la construcc¡ón. La mayon,

de grupos qte realizan una construcción diaria aplican una penarizació:
por fallar al construir. si se falla demasiado a menudo al construir, 1os
desarrolladores no se tomarán demasiado en serio el hecho de fallar a-
construir. El fal1o de construcción debe ser una excepción, y no la ree1a.
445
Capítulo 18: Construcción y prueba diarias
mantener una construcción

Hay que dejar claro desde el principio que
es ü prioridad máximá del proyecto' Rechace no darle importan-
"orr""tu Insista en que 10s desarrolladores que
cia a un fa110 en la construcción. que hayan
trabajos hasta
falren en ra construcción detengan sus restantes
corregido el error.
de mantener
U; castigo divertido puede ayudar areforzat 1a prioridad
muñecos a los desarrolladores
suto prod"ucto. .ttg,r,tá' g"'pó* cuelgan
"l tiene que pegar un muñeco
que fallan en la construccióf iquel que faila
el error' En otros proyectos'
Jn fu po"ttu de su despacho hasta qrre corrija
de ejecutar la prueba
la persona que falla en la construttiótt "' responsable
mismo fallo' En un proyecto
de construcción hasta que otro cometa el
tenía que po-
qrr. ttabajé,la persona que fallaba en la construcción
"rr.1 que corrigiera el error' Otros
nerse un sombrero con un puiug"ut hasta
ponerse un sombrero
gr.rpo, castigan u to, ¿t'u"ollidores culpables a
fondo común'
con cuernos o apagar cinco dólares para un
tu'1igo* más dolorosos' Los desarrolia-
Algunos proyectos establecen
de alto nivel' como NT'
dores de Microsoft que trabajan en proyectos
las etapas
Windows 95 y Excei, han llegado a llevar buscapersonas-en
son llamados para
finales de sus proy""io.' Si fallan en la construcción'
del día o de la noche' El
corregir el error, lrr¿"-p*Ji""temente c{e la hora
sea capaz
éxitole este método depertde de que el grupo de construcción
de determinar quién es et culpaure del falro conjunto- Si no
"*uctam"irte por error para corregir el pro-
tienen cuidado, ,rn J"ru,,o1lador llamado
iápidamente en un enemigo del
ducto a las tres ¿" tu -u¡una se convertirá
proceso de construcción diaria'
grupos han descu-
Entregar lo construido por la mañana' Algunos
por la noche' la prueba
bierto que es preferible tializar 1a construcción
nuevo producto construido
mínima por la mañana temprano y entregar el
prueba mínima y entre-
por la mañan a ett vez de pár 1a tarde. Realizar la
'gar ventajas'
1o construido por la mañana ofrece varias
la mañana' los comprobado-
En primer lugar'si entrega el producto por
iobre un producto reciente ese día' Si
res pueden tealizar ru. p"tJbu' 'le
entrega eiproducto por la tarde' los comprobadores se sen-
generalmente
antes de terminar la jor-
tirán obligad os abízar srrs pr.rebás automáticas
1o cual sucede a menudo'
nada. Cuando se retrasa la entrega del producto'
paralanzat sus pruebas'
los comprobadores tienen q"" qJedarsé más tarde
a. ellos' el proceso de
Como tienen que quedars" tu'á" por causas ajenas
construcción se convierte en un enemigo de la
moral'
por la mañana' tiene
Cuando el proceso de construcción se completa
se producen problemas
un acceso más fiable a los desarrolladores cuando
conloconstruido'Duranteeldía,losdesarrolladoresestánasualcance. In-
en cualquier parte'
Durante la noche, los desarrolladores pueden estar
clusocuandolo.d"ru,,olladoresllevanbuscapersonas'noresultansiem-
46 Desanollo y gestión de proyectos informáticos
pre fáciles de localizar. Podría parecer más efectivo comenzar la prue:"a

mínima al final del día y llamar a la gente a mitad de la noche cuando !,:
encuentran problemas, pero resulta más duro para el equipo, se pierG
tiempo y al final se pierde más que se gana.
tu
Realizar la construcción y la prueba incluso bajo presión. Cuano;
se intensifica la presión de planificación, el trabajo necesario para reai:-
zar la consfrucción diaria puede parecer una pérdida de tiempo extra\'¡-
gante. Lo contrario es cierto. Bajo presión, los desarrolladores pierde:
parte de su disciplina. Se ven presionados a tomar atajos para el diseño 1
ERROR CLÁSICO la implementación que no tomarían en circunstancias menos exigenre=
Revisarán y comprobarán su propio código con menos cuidado del hat:-
tual. El código pasa a un estado de entropía con mayor raptdez de la norm¡-
en períodos más tranquilos.
Frente a esto, el proceso de construcción y prueba diarias refuerza l¡
disciplina y mantiene alineados los proyectos bajo presión. El código si-
gue tendiendo hacia un estado de entropía, pero esta tendencia se manrie-
ne a raya cada día. Si construye diariamente y la construcción falla. l:
identificación del desarrollador responsable y la búsqueda de una coffec-
ción inmediata del código es una tarea asequible. Devolver el código haci:
atrás desde un estado de entropía es un trabajo relativamente simple. S:
espera dos días (hasta que haya el doble de defectos en el código), tendr:
que vérselas con el doble de defectos, y con los efectos multiplicativos de
la interacción de dichos defectos. Hará falta más del doble de esfuerz"'
para diagnosticarlos y corregirlos. Cuanto más tiempo espere entre opera-
ciones de construcción, más difícil será devolver el producto a un estadr
controlado.
¿Qué tipos de proyectos pueden usar el proceso

de construcc¡ón y prueba diarias?
La construcción diaria puede ser usada en prácticamente cualquier tip..
de proyecto (grandes proyectos, pequeños proyectos, sistemas operativos.
software <prét-á-porten y sistemas de gestión).
Fred Brooks informa que en algunas organizaciones los constructores
de software encuentran sorprendente e incluso incomprensible el proceso de
construcción diaria. Éstos dicen que realizan una construcción semanal-
pero no diaria (Brooks, 1995). El problema de la construcción semanal con-
siste en que al final se tiende a no realizar la construcción cada semana. Si
se falla en la construcción de una semana, puede que pasen varias semanas
antes de la siguiente construcción correcta. cuando esto sucede, se pierde
prácticamente todo el beneficio obtenido en las construcciones frecuentes.
Algunos desarrolladores se quejan de que no resulta práctico cons-
truir cada día porque sus proyectos son demasiado grandes. pero el pro-
Capítulo 18: Construcción y prueba diar¡as 447
yecto que posiblemente suponga ei esfuerzo más complejo de desarrollo

de softwari de los últimos tiempos usaba con éxito construcción diaria.
En su primera entrega, Microsoft NT consistía en 5,6 millones de líneas
de código en 40.000 archivos fuente. Una construcción completa requería
19 horas sobre distintos equipos, pero el equipo de desarrollo del NT se-
guía consiguiendo realizar la construcción diaria (Zachaty,1994). Lejos
á" ,"r una molestia, el equipo del NT atribuyó gran parte de su éxito en
este proyecto a 1a construcción diaria. Los que trabajamos en proyectos
*rr.ho menores (en proporción) tendríamos que dar muchas explicacio-
nes para indicar por qué no utilizamos construcción diaria'
Para los responsables técnicos, la construcción diaria resulta particu-
larmente útil porque se puede implementar a un nivel puramente técnico.
No necesita tener autorización de 1a directiva para insistir en que su equi-
po realice con éxito la prueba de construcción cada día'
REFERENCIA La construcción diaria resulta especialmente valiosa en el modo de
CRUZADA recuperación de proyectos. Si no puede alcanzat vn estado de construc-
sobre la recuperación ción correctu, .ro1i"n. esperanzas de llegar a entregar el producto, así que
de proyectos, véase resulta adecuado orientar el trabajo hacia obtenel una construcción co-
el Capítulo 16,
rrecta como uno de sus primeros objetivos de recuperación del proyecto.
"Recuperación de
Proyectos'. Una vez que alcance un estado correcto conocido, puede realizar inclu-
siones inciementales y permanecer en un estado perfecto conocido. En la
recuperación de proyectos, resulta muy útil para la moral tener un pro-
ductt que funcione en cada momento, y ayuda a mostrar indicaciones del
progreso.
18.2. Gestión de los r¡esgos del método de construcción

y prueba diarias
El proceso de construcción diaria tiene algunas desventajas. Ésta es la
más importante.
REFERENCIA Tendencia hacia la entrega prematura. Cuando las personas ajenas

CRUZADA
al grupo de desarrollo ven que el producto es construido cada día, aumenta
Los problemas de las
entregas prematuras la presión para crear versiones frecuentes pam grupos externos' La creación
están relacionados con de versiones externas puede parecer fácil a un responsable de producto, y
los problemas de Ia
convergencia resulta más fácil que cuando no se está usando construcción diaria, pero
prematura descritos en sigue absorbiendo el tiempo de los desarrolladores de forma sutil:
"Convergencia
prematura", dentro de
la Sección 9.1. ¡ Los desarrolladores emplean tiempo preparando materiales que no
son necesarios para el producto final, pero que hacen falta para
soportar la versión entregada. Estos materiales incluyen documen-
tación, versiones provisionales de prestaciones que están en desa-
448 )esa:'c"t y gest¡ón de proyectos informáticos
rro11o, manipular áreas peligrosas del producto, ocultar las

herr:-
mientas de dePuración, etcétera.
¡ Los desarrolladores realizan correcciones rápidas para que las pret-
taciones funcionen en una versión particular, en \ugar de esper::
hasta que puedan realtzar modificaciones más cuidadosas. A1 fin;-.
estas aoneaciones táprdas sue\en f al\at, y entonces \o s desanolladt -
res tienen que realizat \os cambios más cuidadosos que deberi:':
haber realizado inicialmente. El efecto neto es que los desarroll¿-
dores pierden tiempo corrigiendo dos veces el mismo código.
o Los desarroiladores emplean más tiempo respondiendo a problema.
pequeños en una base regular y en fases tempranas del ciclo c;
desarrollo, problemas que podrían ser abordados de forma mas
eficiente como parte del ciclo normal de trabajo del desarrollador
No deseará eliminar completamente las versiones intermedias. Lo qu:

puede hacer es planificar un número especí{ico de versiones intermedia>.
y una vez hecho esto, intentar no incrementar este número.
18.3. Efectos secundarios del método de construcción

y prueba diarias
Algunos desarrolladores que han usado construcción diaria afirman que
mejora la calidad general del producto (Zachary, 1994). Aparte de esto.
el efecto de la construcción diaria es limitado sobre su mejora en el ries-
go de integración, riesgo de calidad y visibilidad del progreso.
18.4. lnteracciones de la construcción y prueba diarias

con otros métodos
La construcción diaria se combina perfectamente con el uso de hitos mi-
niatura (Capítulo 27'). Como dice Chris Peters, <la regla número uno de
planificación es la vigilancia constante> (Peters, 1995). Si ha definido un
conjunto completo de hitos miniatura, y sabe que su construcción diaria
funciona, entonces tendrá una visibilidad excepcional sobre su progreso.
Podrá comprobar el producto cada día para saber si el proyecto está cu-
briendo sus hitos miniatura. Si está cubriendo sus hitos miniatura, termi-
nará a tiempo. Si va con retraso, lo detectará inmediatamente, y podrá
ajustar sus planes convenientemente. El único tipo de error de planifi-
cación que puede cometer es dejar tareas fuera de la planificación.
La construcción diaria también ofrece soporte para los métodos de
Capítulo 18: Construcción y prueba d¡ar¡as 449
REFERENCIA desarrollo incrementales (Capítulo 7). Estos métodos dependen de la po-

CRUZADA
sibilidad de entregar versiones intermedias del software a grupos exter-
sobre los métodos de nos. El esfuerzo necesario para preparar un buen producto para su entrega
desarrollo es relativamente pequeño comparado con el esfuerzo necesario para con-
¡ncrementales,
consulte el Capítulo 7, Vertir un programa noffnal, construido con poca frecuencia, en un pro-
"Planificación del ducto bien construido.
ciclo de vida".
18.5. Puntos cruciales de la construcción y prueba diarias

El proceso de construcción y prueba diarias es en su fuero más íntimo un
REFERENCIA méiodo de gestión de riesgos. Como los riesgos a los que se dirige son
CRUZADA riesgos de planificación, tiene una gran capacidad parahacer que las pla-
sobre la importancia nificacionei resulten más predecibles, y para eliminar algunos de 1os ries-
de hacer visible gos que pueden causar fuertes retrasos (problemas de integración, baja
el progreso, véase
la Sección 6.3, calidady falta de visibilidad del progreso).
"Percepción
y No conozco datos cuantitativos sobre la eficacia en la planificación
realidad".
del proceso de construcción diaria, pero los informes de casos concretos
sobie so valor son impresionantes. Jim McCarthy ha dicho que si Micro-
soft tuviera que elegir un aspecto único de su proceso de desarrollo, éste
sería el pro"éro de construcción y prueba diarias (McCarthy, 1995c).
18.6. Claves para el éxito en el uso de la construcción

y prueba diarias
Éstas son las claves para tener éxito en la construcción diaria:
o Construir cada día.

. Realizar la prueba mínima cada dia.
. Ampliar la prueba mínima junto con el producto. Asegurarse de
que la prueba sigue siendo significativa a medida que el producto
evoluciona.
. Hacer que el mantenimiento de una construcción sin errores sea la
prioridad principal del proyecto.
Tomar medidas para asegurarse de que los fallos en la construc-
ción sean excepcionales y no algo habitual.
No abandonar el proceso bajo presión.
Cusumano, Michael, y Richard Selby: Microsoft Secrets: How the lilorld's
Most Powerful software Company creates Technology, shapes Mar-
kets, qnd Manages People. New York: Free Press, 1995' El Capítulo 5
-+_
450 Desarrolto y gestión de proyectos informáticos
describe detalladamente el proceso de construcción diaria en N{ic:_-

soft, incluyendo un listado detallado de los pasos ejecutados por -
desarrollador individual en productos de apricación, tales como \{_-
crosoft Excel.
Mccarthy, Jim: Dynamics of software Developmerl. Redmond, washin=-
ton: Microsoft Press, 1995. Mccarthy describe el proceso de consrn:;-
ción diaria como un método que ha encontrado útil en el desarrollo ¿.
software en Microsoft. Su punto de vista complementa el descn:.
en Microsoft Secrets y en este capítulo.
McConnell, Steve: Code Complete. Redmond, Washington: Microst*
Press, 1993. El capítulo 27 de este libro trata de enfoques de inte-
gración. Ofrece información adicional sobre las razones que hay ba-;
la efectividad presentada por métodos incrementales de integracior*
tales como la construcción diaria.
19
Diseño para el cambio
El diseño para el cambio es una denominaciÓn general

que englobu l¡-:.ffi
varios méüdos de diseño orientados al cambio. Para que sean.elecil- -. ,_-*;6
:l:ffi
que emplearse pronto en el ciclo de vida det
vás, estas técnicas tienen
software. El éxito en el diseño para el cambio depende de
cación de los cambios probables, el desarrollo de un plan de
la identifi-
cambios
t=ffi
que los cambios no *="i,
y lá ocultación de las de'cisiones de diseño, de modo
de dise-
á" propugr"n dentro de un programa. Algunas de las técnicas :
ño orientádas alcambio r".ütt"ñ más difíóiles de lo
que cree elpersonal
informático, pero cuando se ejecutan correctamente, sientan
las bases ffiffi
pui" progr"mas de larga vidá y alcanzan una
ávuáá.. a"minimizar imfactos en la planificación
flexibilidad
debidos a
que puede
peticiones ffiffi
tardías de cambios.
Eficacia
Mejora en la visibilidad del progreso: N¡nguna
Efectos sobre el riesgo de la pánificación: Disminuye el riesgo
Posibilidad de éxito inicial: Buena
Posibilidad de éxito a largo plazo" Excelente
Riesgos princiPales
. para
Basarse demasiado en el uso de lenguajes de programación
diseño
resolver problemas de diseño, en lugar de en métodos de
orientados al cambio'

. Ofreóe el soporte necesario para técnicas de desarrollo incremental'
r Los métodos de diseño implicados trabajan firmemente unidos con
la reutilización del software.
451
452 Desarrallo y gest¡ón de proyectos informáticos
Muchos desarrolladores reconocen que el diseño para el cambio es jrj!,

buena <técnica> de ingeniería del software, pero muy pocos rscorrtriir
que contribuye de forma valiosa al desarrollo rápido.
Algunas de las peores influencias sobre la planificación de un c:*-
rrollo son los cambios tardíos e inesperados sobre un producto (cami::r;.
producidos una vez terminado el diseño inicial y unaveziniciada la iml1¡-
mentación). Los proyectos que no gestionan correctamente estos cami¡::x-
a menudo parecen progresar lentamente, incluso aunque estén dentru. u
1o planificado hasta el momento en que se introdujeron los cambios.
Los métodos de desarrollo actuales hacen cada vez más énfasis e: ,¡
respuesta a los cambios: cambios en las condiciones del mercado, camb--x
en la comprensión del problema por parte del cliente, cambios en la :¡;-
nología utllizada, y asi sucesivamente.
Frente a estos inconvenientes, el diseño para el cambio no produce ab:-
rros directos en la planificación. El cuidado necesario pa.arealizar un dis¡i;
para el cambio puede alargar la planificación nominal del desarrollo. Pero m
raras ocasiones la ecuación de planificación es tan simple como para con::-
ner como única variable la planificación nominal. Es necesario incluu -=r
ella la posibilidad de cambios, incluyendo cambios para versiones futu:-.i
En este caso, es necesario sopesar el pequeño y conocido incrementr- j*
esfuerzo necesario para realizar un diseño orientado al cambio frenre ¡u
posible y gran riesgo de no hacer diseño para el cambio. Equilibrando arnnx
factores es posible ahorrar tiempo. Si utiliza métodos de desarrollo in,-::-
mentales, tales como la entrega evolutiva y el prototipado evolutivo. ü¡-;l
introduciendo bastantes probabilidades de tener cambios en el proceso c
desarrollo, por lo que es mejor que su diseño lo tenga en cuenta.
19.1. Uso del diseño para el cambio

<<Diseño para el cambio>> no se refiere a una metodología de diseño e:
particular, sino a una panoplia de técnicas de diseño que contribul.en l
obtener diseños flexibles del software. Éstas son algunas de las cosas qu:
puede hacer:
a Identificar áreas que van a cambiar con probabilidad.

a Usar ocultación de información.
a Desarrollar un plan de cambios.
a Definir familias de programas.
a Usar diseño orientado a objetos.
El resto de esta sección describe cada una de estas técnicas. Algur-o

de ellas se solapan, perorpreo que cada una de erlas tiene su propio r-air:
heurístico distinto.
Capítulo 19: Diseño Para el cambio 453
ldentificación de las áreas suscept¡bles de camb¡os

El primer punto para tener éxito en el diseño para el cambio es identificar
los posibles .urnbior. Comience el trabajo de diseño listando las decisio-
,r", d" diseño que son susceptibles de ser modificadas' Robert L. Glass ha
indicado que una característica de los grandes diseñadores consiste en
que son de anticipar más tipos de posibles modificaciones que
"ápu."r
üs diseñadores medios (Glass, 1994a). A continuación se citan algunas
fuentes habituales de cambios:
¡ Dependencias del hardware.

o Formatos de archivo.
r Entradas y salidas.
o Prestaciones no estándar del lenguaje.
. Áreas con dificil diseño e implementación'
o Variables globales'
o Implementación de estructuras de datos específicas'
o Implementación de tipos abstractos de datos'
o Reglas de la organizaciín.
. Secuencia en 1a que se van a procesar los elementos'
o Requerimientos que han sido excluidos de la versión actual.
. Requerimientos áxcluidos globalmente de la versión actual.
. Prestaciones planificadas para la siguiente versión'
La identificación de los cambios necesita realizarse durante el diseño

o antes del mismo. La identificación de posibles cambios en los requeri-
mientos debe formar parte de la identificación de requerimientos.
Uso de la ocultación de información

REFERENCIA IJnavezque haya creado su lista de cambios posibles, aísle las decisiones
CRUZADA de diseño relacionadas con cada uno de los cambios dentro de su
propio
sobre la ocultación de módulo. A1 decir <módulo>, no me estoy refiriendo necesariamente a
información véase una rutina determinada. En este contexto, un módulo puede ser una rutina
"Bibliografía
adicional", al final o una colección de rutinas y datos. Podría ser un <módulo> en Modula-2,
del caPítulo. una <clase>> en C**, un (paquete>> en ADA, una <<unidad>> en Turbo Pas-
ffi
cal o Delphi, y así sucesivamente'
La téónica de ocultar las decisiones de diseño susceptibles de modifi-
cación dentro de sus propios módulos, conocida como <<ocultación de infor-
mación>, es una de ias pocas técnicas teóricas que han demostrado fuera
DATOS REALES que David
de toda duda su utilidad en la práctica (Boehm, 1987a). Desde
ha encontrado que los gtandes
Parnas introdujo inicialmente esta técnica, se
programas qué utilizan ocultación de información resultan más fáciles de
*oáifi"u, (hasta 4 veces más) que los programas que no lo hacen (Korson
y vaishnavi, 1986). Además, la ocultación de información forma parte de
4g Desarollo y gest¡ón de proyectos informáticos
las bases del diseño estructurado y del diseño orientado a objetos. En i

diseño estructurado, el concepto de cajas negras procede de la ocultacim
de información. En el diseño orientado a objetos, la ocultación de infor-
mación da lugar a las nociones de encapsulación y visibilidad.
En la edición del 20 aniversario de The Mythical Man-Month, Fred
Brooks concluye que su postura crítica frente a la ocultación de informa-
ción era uno de los pocos errores de la primera edición de su libro. <Parna-s
estaba en lo cierto, y yo estaba equivocado respecto a la ocultación de
información>, afirma el autor (Brooks, 1995).
Para usar la ocultación de información, comience en el diseño por listar
las decisiones de diseño susceptibles de cambiar (como se ha dicho anterior-
mente), o las decisiones de diseño especialmente difíciles. A continuación
diseñe cada módulo para ocultar los efectos de la realización de cambios
sobre una de estas decisiones de diseño. Diseñe la interfaz del módulo para
que no sea sensible a cambios ocurridos dentro del módulo. De este modo.
si se produce el cambio, sólo afectará a un módulo. El objetivo debe ser
crear cajas negras: módulos que tienen interfaces concretas y bien definidas.
y que guardanpara sí mismas sus detalles de implementación.
Suponga que tiene un programa en el que se supone que cada objeto
tiene un identificador único almacenado en una variable miembro llamada
ID.rJnmétodo de diseño consistiría en usar enteros para los identificadores.
y almacenar el identificador más alto asignado hasta ese momento en una
variable global llamada maxlD. Cada vez que se reserva un nuevo objeto,
ERROR CLÁSICO posiblemente en el constructor de cada objeto, podría usar simplemente la
instrucción1D : -l+maxlD (ésta es una instrucción en lenguaje C que incre-
menta en 1 el valor de maxlD y asigna el nuevo valor aID).Esfo garantizaría
el uso de identificadores únicos, y añadiría el mínimo posible de código
en cada lugar en el que se crea un objeto. ¿Qué puede ir mal en este caso?
Hay muchas cosas que pueden ir mal. ¿Qué sucede si desea reservar
rangos de identificadores para propósitos especiales? ¿Qué sucede si de-
sea poder reutilizar los identificadores de objetos que han sido destrui-
dos? ¿Qué pasa si quiere añadir una comprobación que compruebe cuándo
se han reservado más identificadores del número máximo previsto? Si ha
reservado identificadores utilizando instrucciones 1D : ++maxlD en todo
el programa, tendrá que cambiar el código asociado con cada una de estas
instrucciones.
La forma en que se crean los nuevos identificadores es una decisión
de diseño que debe ocultar. Si usa la instrucción *-tmaxlD a lo largo de
su programa, está publicando la información de que la forma en que se
crea un nuevo identificador es simplemente incrementado maxlD. En lugar
de ello, si utiliza la sentencia ID : nuevolDp en su programa, ocultará la
información sobre la creación de nuevos identificadores.
Dentro de la función nuevolD0, podría seguir teniendo sólo una línea
de código, return(ttmaxlD) o su equivalente, pero si posteriormente
...,qrrlE?|C"
Capítulo 19: Diseño para el cambio 455
decide reservar ciertos rangos de identificadores para propósitos especia- I
les, reutilizar antiguos identificadores o añadir comprobaciones, podrá

realizar estos cambios dentro de la propia función nuevolD0 (sin tocar
las decenas o cientos de instrucciones .ID : nuevoID)). Independiente-
mente de lo complicadas que sean las revisiones introducidas dentro de
nuevolD), no afectarán a ninguna otra parte del programa.
Ahora suponga que posteriormente descubre que necesita cambiar el
tipo de la variable ID de entero a cadena. Si ha introducido declaraciones
de variable como intlD a lo largo de su programa, el uso de la función
nuevolD0 no le ayudará. Seguirá necesitando recolrer el programa y rea-
lizar decenas o cientos de modificaciones.
En este caso, la decisión de diseño a ocultar es el tipo de identificador.
Podría declarar simplemente sus identificadores como TIPOID (un tipo
definido por el usuario que se resuelve como int) en lugar de declarar-
los directamente como del tipo int. De nuevo, la ocultación de una de-
cisión de diseño supone una gran diferencia en la cantidad de código afec-
tada por un cambio.
Desarrollar un plan de camb¡os

En las áreas susceptibles de cambios, desarrolle planes de cambio. Losplanes
de cambio pueden prescribir el uso de cualquiera de los métodos siguientes:
. Utilice interfaces abstractas en los módulos, en lugar de interfaces

que dejen ver los detalles de implementación.
r utilice constantes con nombre para los tamaños de las estructuras
BIBLIOGRAFIA de datos, en lugar de literales introducidos directamente.
ADICIONAL
Para más detalles . utilice estrategias de ligadura dinámica (late-binding). consulte los
sobre estas técn¡cas tamaños de las estructuras de datos en un archivo externo o en el
véase Code complete
(Mcconnell, 1993). registro del entorno de Windows. Reserve dinámicamente las es-
tructuras de datos basándose en estos tamaños.
. Utilice técnicas controladas por tablas en las que el funcionamiento
del programa cambie dependiendo de los datos de la tabla. Decida si
almacena la tabla dentro del programa (1o que requerirá volver a
compilar cuando haya cambios) o fuera del programa en un archivo
de datos, archivo de inicialización, el registro de Windows o un
archivo de recursos.
o Use rutinas en lugar de duplicar líneas de código, incluso si sólo
contienen una o dos líneas.
. Utilice rutinas simples que realicen funciones pequeñas e indivi-
duales. Si mantiene las rutinas simples, será más fácil utilizarlas
que formas que no haya previsto inicialmente.
o Mantenga separadas las operaciones que no estén relacionadas. No
combine operaciones que no estén relacionadas dentro de una única
456 Desarrojlo y gestión de proyectos informáticos
rutina sólo porque parezcan demasiado sencillas

para pone:-:: ::
rutinas separadas.
o Separe el código de propósito general del
código con una func: ¡:. ,
dad especializada. Distinga entie el código quJuu
u ,". uru¿o en .,,!
su organización, el que va a ser usado
el que se va a utirizar en una versión "n
rrrruaplicación especr, :,
específica J. u.,u-upti.-r,.
Todas estas técnicas son métodos recomendables
en ingenierí. _.
software, que, entre otras cosas, ayudan a soportar
los cambios.
Definición de familias de programas

David Parnas indicó ya en 1976 que el trabajo
del desarrollador h"- .
cambiado de diseñar programas individuales
á diseñar familias de :,.-
gramas (Parnas, 1976, 1g7g). En ros 20
años transcurridot ¿.r¿. --_,
escribió esto, el trabajo der desarrollador se ha
desplazad" ---
dirección. Actualmente, ros desarrolladores utilizan ";;;;;;
er mismo código :.,,
para producir difere'tes programas en diferentes
idiomas, diferentes p,,:,-
formas y para diferentes crientes. I a Figura
19.1 irustra er," pro..r.
Como la mayoría de productos se cJnvierten tarde
o t.rrrpiuno er -:.-
familia de productos, ra mayor parte de los esfuerzo,
¿. dir.¡o c-..,
concentrarse en el diseño de una familia de programas
en lugar de e: .
diseño de un programa individual.
En este entorno, parnas afirma que un diseñador
intentar an:,-
debe _
parse a las necesidades de ra familia
prog.u-us ar desarroilar er proc
d.
base' El diseñador debe anticipu. u"rrion"", -:-
iaterales, taies como \ e:. .-
nes internas, inglesas, europeas y para
el Lejano bri"nt", f'.1 c:.._
ñador también debe anticiparse a ias versiones
posteriores. Er diseñ"_. -
debe diseñar el producto de forma que ras
decisitnes prouuur.' ..
cambiar entre versiones estén ro más cerca posible -.no,
de la raiz d,er á:-: .
Esto se mantiene cuando se está diseñando
conscientemente una :. _- -
lia de programas o sólo un programa individuar
qu" a.rru p.ái.g.. r.-_,-
a los cambios.
REFERENCIAS un buen método consiste en identificar iniciarmente
CRUZADAS un subconi-.r
Para más información mínimo de funcionalidades que podrían resultar
ud""uudu, fu;;;i;.r.
sobre la definición de final, y luego definir incremenros mínimos -
conjuntos de sobre esre ,rb;;,rñ;lb"n-..

mente' el subconjunro mínimo no será suficienrerne",.
prestaciones mínimos
y sobre las técnicas de gurar un programa que nadie quiera utirzar;
rrpiio furu . _ -
entrega por versiones, resulta útil de .uru u pr-pu...,.
para el cambio, pero generalmente no."rrrltu
consulte el CapÍtulo 20, práctico.onrr*irlu p-_ ,
"Entrega evolutiva"; el mismo' Los incrementos definidos sobre
Capítulo 36,
éste deben ser tan f.[u.ao. . -
"Entrega parezcan incluso triviales. La razón
por etapas"; y ej de mantener pequeños in...._'.1 . ,
apartado Desarrollo consiste en evitar crear componentes que
"
por versiones" de ¡a
rearicen más de una run;,
Cuanto más pequeños y concretos sean los
Seccíón 14.1 . componentes, mayor s3:: ,
adaptabilidad a cambios der sistema. Er
diseño d" .o*pon.nte's-míir''
Capítulo 19: Diseño para el cambio 4tf
Producto
base
Versión
interna
Versión
inglesa
Versión
OEM
Versión
europea
Versión para
el Lejano
Oriente
Producto base Producto Producto base

para la versión base para la para una nueva
"Lite" versión 2 plataforma
.,/
Figura 19.1 . Familia de productos. Desde que la mayoría de productos,
eventualmente, se orientan hacia familias de productos, la mayoría de los
esfuerzos de diseño se deberían concentrar en el diseño de fámitias de
programas en vez de uno solo.
que añaden incrementos mínimos de funcionalidad también lleva a sis-

temas en los que se pueden recortar fácilmente las prestaciones cuando
sea necesario.
Use diseño orientado a objetos

REFERENCIA uno de los resultados de la ocultación de la información y de la modula-
CRUZADA
Para más comentarios ridad ha sido el diseño orientado a objetos. En el diseño oiientado a obje-
sobre la programación tos, se divide un sistema en objetos. En ocasiones, los objetos modeliz¡n
orientada a objetos,
consulte " ldentif icación
entidades del mundo real; en otras ocasiones modelizan estructuras infor-
de panaceas", en la máticas o entidades más abstractas.
Sección 15.5. un estudio del Laboratorio de Ingeniería del Software de la NASA ha
determinado que los métodos de desarrollo orient¿dos a objetos incre-
458 Desarrollo y gest¡ón de proyectos informáticos
mentan la reusabilidad, la reconfigurabilidad y la productividad. )' ii¡it*

cen 1as planificaciones de desarrollo (Scholtz et al.,1994)'
utilice el diseño orientado a objetos, pero no espere que sea üñ i,:*
xir milagroso. El éxito del diseño orientado a objetos en un entornLa sr-
jeto amuchos cambios depende de los mismos factores que la oculta¡:¡m
ie información. Seguirá necesitando identificar las fuentes más p.-ir]-
bles de cambio, y seguirá necesitando ocultar estos cambios detras :*
interfaces estrechas que aís1en el resto del programa de los posi'r--
cambios.
1g,2. Gestión de los riesgos del diseño para el cambio

El uso del diseño para el cambio (método recomendable) no supone I.:r:-
gos para el resto del proyecto. El riesgo principal asociado con el di>ei:
puru .t cambio es simplemente el riesgo de fallar al usar el método pr-a
extraer lodas sus ventajas.
ERROR CLÁSICO Excesiva conf¡anza en lenguaies e ¡mágenes en lugar de en el dF

seño. El simple hecho de poner objetos dentro de clases no crea un di:ei;
-Jf,
orientado a objetos, no produce ocultación de la información, y no protege
-x
programa frente a los cambios. El mero hecho de dibujar una jerarquía
móáulos no crea un diseño tolerante a cambios. Los buenos diseños se .--:
tienen a partir de un buen trabajo de diseño, no de gráficos de diseño.
REFERENCIA RealLar un diseño efectivo orientado a objetos es más difícil de.;
CRUZADA que cree la gente. Como se ha descrito en la Sección 15'5, es una te;-
Para otra descripción
más amplia de la nología expérta. David Parnas ha escrito que la tecnología orientada ¿
tecnología orientada a objeás (O-O) ha visto frenada su implantación por la siguiente razón:
objetos, véase
.ldentificación de
Panaceas', en la La orientación a objetos ha sido ligada a una gran variedad de lenguar:s
Sección 15.5.
complejos. En lugar de enseñarle a la gente que la orientación a objeto= 3*
un tipo de diseño, y darle los principios básicos de este diseño, la ger::
cree que la orientación a objetos consiste en el uso de una herramier-
particular. Podemos escribir programas buenos o malos con cualquil:
herramienta. A menos que enseñemos a la gente cómo diseñar, los lengi::-
jes importan muy poco. El resultado es que ia gente realiza malos disei¡*
con estos lenguajes, y obtiene muy poco rendimiento de ellos. (Parnas ::
Brooks, 1995.)
Para diseñar para el cambio, es necesario diseñar realmente. El ele

central del diseño orientado a objetos consiste en centrarse en áreas su'-
ceptibles de cambio, en la ocultación de información y en familias de pr.*
gramas. Si no sigue estos pasos en el diseño, podría estar trabajando per-
fectamente en Fortran, en C clásico o en ensamblador.
Capítulo 19: Diseño para el cambio 459
19.3. Efectos secundarios del diseño para el cambio

Los programas diseñados para el cambio continúan siendo rentables mu-
cho después de su desarrollo y construcción iniciales. Capers Jones infor-
ma que los programas bien estructurados y desarrollados con gran calidad
DATOS REALES
tienen garantizada una larga y útil vida de uso. Los programas mal estruc-
turados y desarrollados con poca calidad son prácticamente retirados de
la circulación o resultan excesivamente caros de mantener en un plazo de
3 a 5 años (Jones, 1994).
19.4. lnteracciones del diseño para el cambio con otros

métodos
La flexibilidad ofrecida por el diseño para el cambio es una parte impor-
tante del soporte necesario para métodos de desarrollo incremental, como la
entrega evolutiva (Capítulo 20) y el prototipado evolutivo (Capítulo 21).
Los métodos de diseño orientados al cambio también ofrecen un soporte
moderado parala reutilización (Capítulo 33).
19.5. Puntos cruc¡ales del diseño para el cambio

Laidea base que subyace en el diseño para el cambio es la reducción de
riesgos. Si el sistema es estable, no producirá reducciones inmediatas de la
planificación, pero ayuda a prevenir grandes retrasos en la planificación
que pueden producirse cuando cambios no anticipados pueden causar gran-
des efectos en cadena durante el diseño y la codificación.
19.6. Claves para el éxito en el uso del diseño

para el cambio
Éstas son las claves para tener éxito en el diseño para el cambio:
o Identificar los cambios más probables.

o Usar ocultación de información para aislar el sistema de los efec-
tos de los cambios más probables.
o Definir familias de programas en lugar de considerar sólo progra-
mas individuales.
¡ No confiar sólo en el mero uso de un lenguaje de programacion
orientado a objetos para realízar automáticamente el trabajo de di-
seño.
Bibliograf ía adicional
Las tres publicaciones de Parnas citadas a continuación sientan 1as b':--:s
de las idéas de la ocultación de información y el diseño para e1 c3:::riI
Siguen siendo parte de las mejores fuentes de información dispon-:.:r'
sobre estas ideas. Pueden resultar difíciles de localizar en sus fuentes or-
ginales, pero los artículos d,e l9'72 y 1979 han sido reproducidos en Tttro'
i¡ol o, Software Design Techniques (Freeman y Wasserman, 1983), ,v el
artículo de 1972 también ha sido reproducido en Writings of the Revoit''
rion (Yourdon. 1982).
parnas, David L.: <on the criteria to Be used in Decomposing systems

into Modules>>, Communications of the ACM, v' 5' núm' 12, diciem-
bre, 1972,1053-58 (también en Yourdon, I9'79; Freeman y Wasser-
man, 1983).
Parnas, David L.: <Designing Software for Ease of Extension and Con-
traction>, IEEE Transactions on Software Engineering, v' SE-5, mar-
zo 19'79,128-138 (también en Freeman y Wasserman, 1983)'
parnas, David Lorge; Paul C. Clements y David M. weiss: <The Moduia¡
Structure of complex Systems>, IEEE Transactions on Software En-
gineering, marzo 1985, 259 -266.
Mcóonnell, Steve: Code Complete. Redmond, Washington: Microsoft
Press, 1993. La Sección 6.1 de este libro ttatade la ocultación de in-
formación, y 1a Sección 12.3 habla de los tipos de datos abstractos.
tema relacionado con el anterior. El Capítulo 30, <<Software Evolu-
tion>, describe cómo prepararse para los cambios en el software a ni-
vel de implementación.
20
Entrega evolutiva
La entrega evolutiva es un modelo de ciclo de vida que consigue un

equilibrio entre el control de la entrega por etapas y la flexibilidad del
prototipado evolutivo. Su aportación aldesarrollo rápido proviene de en-
tregar partes del software seleccionadas antes de lo que sería posi-
ble de otra forma, pero la entrega final del producto software no será
necesariamente más rápida. Proporciona la posibilidad de cambiar
la dirección del producto a medio camino, én respuesta a las peticiones
del cliente. La entrega evolutiva se ha usado con éxito en software de
gestión interna y en software "prét-á-porter". Usado con cuidado, pue-
de mejorar la calidad del producto, reducir el tamaño del código, y ffitl
$, l
producir una distribución más uniforme de los recursos de desarrollo
y prueba. Al igual que otros modelos de ciclo de vida, la entrega evolutiva
es un método para todo el proyecto: si desea usarlo, necesita comen-
zar a planilicar usarlo al inicio del proyecto.
,:,;: Eficacia
Reducción potencial de la planificación nominal: Buena
Mejora en la visibilidad del progreso: Excelente
Riesgos principales
¡ Cambio de prestaciones.
o Disminución del control del proyecto.
. Expectativas poco realistas de presupuesto y planificación.
. Uso ineficiente deltiempo de desarrollo por pafte de los desarrolladores.

. Derivado de la entrega por etapas y del prototipado evolutivo.
¡ El éxito depende del uso del diseño para el cambio.
-L_
e62 Desarrollo y gestión de proyectos informáticos
llevando una lista completa con i¡'

Muchas personas van a hacer la compra plátanos' 3 kilos
1a semana: <2 kilos de 'i:
alimentos que necesitarán durante
manzanas,lmanojode-zanahotias))'etc'Otraspersonasvanahacerlacorn-
que les parece me-lor
con lo que necesitan y compran 1o
;r.;; ii.;", una lista huelen tittt' M" llevaré un par de
ello''
cuando están allí: *g,o'--tlo"es cebolla ytomate
Los pondre con
;;;;"""t"* "o,.gtludot fu"tt" frescos'dt solomilló son impresionantes' No
he
y haré una fritada. Ort, v Ui'ttt'
"tJt Me nevaré un par de ellos para maña-
hecho solomilro hace á""t "ii"r"po.
na.> La mayoría d" l"t';;;;;;u'
n*"tt algo intermedio' Llevan una lista para
o menor medida cuando están
allí'
la compra, pero improvisan en mayor por
de vida software' la entrega
En el mundo d" tás modelos dL ciclo prototi-
ffevando una lista completa' E'l
etapas equivale u ftutá' i" t"*pt"
sin llevar ninguna lista' La entrega
pado evolutivo es como hacer la compra
lista' pero improvisar un poco con-
evolutiva es como comenzar con una
forme
----Rt se avanza. 1 -,-1,"^_^
evolutiva proporclona 2Ll cliente
modelo de ciclo de vida de entrega t?"u;"T::l:'
si gno
g*' o i."" "1t?, 91i1"^1.:,:.:Í:": : ::i,
s vi sible s o. t p'o
;i#;
pero
'u
#;r'" rrv^lur ¿"¿ br n't"1n i1:, 'rna
n
'ruurra " "ilif; por etapas, al cliente": :ili:
:::t:l'l;":? signos-":t:i: H
visibies
"
at iguat que la enffega Pt"p:_1:1'^ ;^r ó+oñqc .rnnorciona un
i.i"ñ;;;;;;;?i",enciadeiaentreg"ry: j:1nf :-'"^nj':li"1i""l
f,:t;;;;;""n""ru'r'J"á-e".'espue'tuûlu1:ul'Y:1':Ti?":'::*?i;
il:i::::.Ji;i' "'ü i"' " q"' "i;:,,1 l:".' l *:: I-::::':3:;1,ffl'fl
oa:.,?::il;;tt"";""1il'""1"ir"^'uitrau¿*11"t"110,*:,:l^":T'J;^t:
::'iH'ff:tlfi;
/*rrw6q #;;'u '"i'"lrr\ettanüo
"'o'
o:-
l:*l:,'"de
me\otat\as'
ciclo de vida' v
extrae sus rrenta¡as 1 \es''rerr\a\as
t
La entrega evolutiva el desar:rollo rápido de varias formas

REFERENCIA 'ápoitu
CRUZADA
que el cliente no des:'
Para obtener más
detalles sobre estos
Reduce el riesgo de entregar un producto
el trabajo'
tipos de apoyo Para el evitando el tiempo perdido en repetir
hace visible el progreso entreg=-
desarrollo ráP¡do,
consulte las
Para el software personalizado,
introducciones del do el software a1 principio y con frecuencla'
entregas más frecuenl;'
CaPítulo 21, ¡ Para el software <prét-i-pórter>>' admite
" Prototipado
y del del producto ,., .-^--...,^r.,-. a ;es:''
o
"us¡u1¡ys",
Capítulo 36, "Entrega ¡ Reduce el error de estimación al
permitir recalibrar y volver
Por etaPas' evolutivas'
mar después de cada una de las entregas
integración' integrando pronto ¡
n.¿.r." riesgo de problemas de
"f
con frecuencia (siempre que se produce)'
¡ ve como un éxito desde la
Mejora la morai, porque é1 proyecto se
que se entrega la ver-
primera vez que áip'oit"to iale a escena hasta
sión final.
evolutiva' el soporte para
Como con otros aspectos de la entrega
factores depende de si tiende
el desarrollo rápido ¿" l"¿' uno de estos
el prototipado evolutivo'
más hacia la entrega por etapas o hacia
4ú )esa,rrot'!o y gestión de proyectos informáticos
En el prototipado evolutivo, tiende aiterar hasta que usted o el ciient¡

reconozcan que ha creado un producto aceptable. ¿Cuántas iteracione.
tendrá que hacer? No puede saberlo con seguridad. Normalmente no s¡
puede abordar un proyecto con un final tan indefinido.
Por otro lado, en la entrega por etapas, durante el diseño de la arqu:-
tectura planifica el número de etapas que tendrá, y lo que construirá exac-
tamente durante cada una de las etapas. ¿Qué sucede si cambia de ideal
Bien, la entrega por etapas pura no se 1o permitirá.
Con la entrega evolutiva, puede comenzar partiendo de la base de-
prototipado evolutivo y virar el proyecto hacia ia entrega por etapas para
obtener un mayor control. Puede decidir al principio que entregará el pro-
ducto en cuatro entregas evolutivas. Invite al cliente a proporcionar reali-
mentación en cada entrega, 1o que puede considerarse para la siguiente
entrega. Pero el proceso no continuará indefinidamente: patatá después
de la cuarta entrega. Decidir con antelación el número de iteraciones v
mantenerlo es uno de los factores más críticos para conseguir el éxito en
este tipo de desarrollo rápido (Burlton, 1992).
Con la entrega evolutiva, otra opción es comenzar teniendo como base
la entrega por etapas y virar el proyecto hacia el prototipado evolutivo
para obtener una mayor flexibilidad. Al principio puede decidir lo que
entregará en las etapas l,2y 3, pero puede ser más indeciso con las eta-
pas 4 y 5, 1o que le da a su proyecto una dirección, pero no un camino
organizado.
La inclinación hacia el prototipado evolutivo o la entrega por etapas
debería depender del punto hasta el que necesite adaptarse a las peticio-
nes de los clientes. Si necesita aceptar la mayoría de las peticiones, prepare
la entrega evolutiva para que se acerque más al prototipado. Algunos ex-
pertos recomiendan entregar el software en incrementos del I al 5 por 100
(Gilb, 1988). Si necesita aceptar pocas peticiones de cambios, planifique
acercarse más a la entrega por etapas, con una serie de entregas mayores.
Orden de entrega
REFERENCIA La entrega evolutiva se utiliza cuando no se está completamente seguro
CRUZADA
de 1o que se desea construir. Pero a diferencia del prototipado evolutivo, se
Para más detalles
sobre el valor de tiene al menos alguna idea, de forma que se podría organizar un conjunto
organizar pos¡bles preliminar de entregas al comienzo del proyecto, mientras se están desa-
cambios en un sistema
en tiempo de diseño, rrollando la arquitectura y el núcleo del sistema.
consulte .Definición de La planificación inicial de entregas probablemente contendrá alguna
familias de
programas". en Ia funcionalidad que claramente estará en el sistema final, alguna que pro-
Sección 19.1 . bablemente estará, y otra que podría no estar. Sin embargo, se identifica-
rán otras funcionalidades y se añadirán posteriormente.
Asegúrese de estructurar su planificación de entregas, de forma que
desarrolle antes las funcionalidades más importantes. Puede mostrar el
Capítulo 20: Entrega evolutiva 465
sistema a sus clientes, obtener su realimentación, y tener la seguridad de

que el resto de funcionalidades es realmente lo que desean (antes de co-
menzar a trabajar en él).
Cuándo usar la entrega evolutiva

REFERENCIA Si conoce tan bien su sistema como para no esperar muchas sorpresas, será
CRUZADA
Para ver una
mejor utilizar la entrega por etapas que la entrega evolutiva. Tiene un
descripcrón de las mayor control sobre el proyecto cuando organiza exactamente 1o que se
decisiones de entregará al final de cada etapa con antelación. Este estilo de desarrollo
planificación que
dependen de la suele ser más apropiado para mantenimiento o actualizaciones del pro-
correcia comprensión ducto, donde ya conoce a fondo e1 ámbito del producto v no espera encon-
del sistema, consulte la
Sección 13-1, trar ninguna idea revolucionaria a lo largo del desarrollo.
"Conside raciones Si no conoce completamente el sistema ) espeÉ muchas sorpresas,
sobre la estructura del
equiPo"
incluyendo sorpresas que probablemente afecten al sistema de forma funda-
mental, será mejor ttllizar el prototipado evolutir-o que la entrega evolu-
liva. La entrega evolutiva requiere que se tenga suficiente conocimiento
sobre el proyecto al principio, para diseñar una arquitectura e implemen-
tar la funcionalidad del núcleo. Con el prototipado evolutir-o. no tiene
que hacer esto al principio.
La entrega evolutiva no está limitada a los sistemas completamente
nuevos. En un sistema existente puede sustituir parte del sistema antiguo
y también puede proporcionar nuevas capacidades. Llega un momento en
el que habrá sustituido tantas cosas que no quede nada del sistema anti-
guo. La arquitectura del nuevo sistema necesita ser diseñada con cuidado,
de forma que pueda seguir sin verse afectado por las restricciones del
antiguo sistema. Esto podría significar que no puede crear inmediatamen-
te ciertas partes del nuevo sistema; es posible que desee esperar hasta que
el nuevo sistema pueda admitir esas partes sin sobresaltos.
20.2. Gestión de los riesgos de la entrega evolutiva

A continuación se muestra una lista de riesgos que debería controlar st su
versión de la entrega evolutiva tiende más hacia el prototipado evolutivo:
REFERENCIA Expectativas poco realistas de presupuesto y planificación, debi-

CRUZADA
Para más detalles
das al rápido progreso inicial.
sobre estos riesgos, a Disminución del control del proyecto.
consulte la a Cambio de prestaciones.
Sección 21.2,
"Gest¡ón de los
a Mala realimentación del usuario.
riesgos del a Bajo rendimiento del producto.
prototipado
evolutivo".
a Expectativas poco realistas de rendimiento.
a Mal diseño.
o Dificultades para el mantenlmlento.

. Uso ineficiente del tiempo de desarrollo por parte de los desarr.--
lladores.
A continuación se muestran los riesgos a controlar si su proyecto

de más a la entrega por etapas:
REFERENCIA
CRUZADA
Para más detalles sobre a Cambio de prestaciones.
estos riesgos, consulte
la Sección 36.2, "Gestión
a Dependencias técnicas inadvertidas.
de los riesgos de la a Centrado insuficiente del desarrollador, tendiendo a un uso
entrega por etapas". ciente del tiempo de desarrollo.
20.3. Efectos secundarios de Ia entrega evolut¡va

La entrega evolutiva mejora la posibilidad de hacer correcciones a mitad
del proyecto. En cada entrega incremental, si los resultados no son los
esperados, puede mejorar el diseño, modificar el análisis de costes/bene-
ficios o cancelar pronto el proyecto.
Realizar entregas desde el principio y con frecuencia ayuda a mejorar
srr Estrrnairbn, otrecrbrrüo\e rnás poSrb\\\üaües üe prac\\car. E s\o no aunii:-J
la velocidad de desarrollo, pero aumenta su capacidad de entregar 1; :rr*
promete, que puede ser igual de importante en un entorno sensibl¡
velocidad. Tom Gilb denomina a esto el <principio del choque fu:;: ,
" "l
los datos de proyectos anteriores pueden ser útiles, pero no pueden se: -'r
útiles como los datos actuales del proyecto en curso (Gilb, 1988).
Otra ventaja consiste en que puede pretender entregar el producto ;";
pocas semanas o meses. Haciendo esto, se reduce la cantidad de tien:,-
que lleva aprender todas las lecciones que se aprenden al finalizar un ;,-
clo del producto. El desarrollo completo de un producto es una gran -r_-
periencia, y cuando reduce el bucle de realimentación, puede obtener e-
experiencia de forma más rápida.
:
REFERENCIA Si su versión de la entrega evolutiva se inclina hacia el prototipac:

CRUZADA
Para más detalles
evolutivo, podría experimentar estos efectos secundarios:
sobre eslos efeclos
secundarios, consulte
la Sección 21.3,
Mejora de la moral de los usuarios, clientes y desarrolladores por-
"Efectos secundarios
que el progreso es visible.
del prototipado a Realimentación temprana de la aceptación del sistema
evolut¡vo".
a Disminución del tamaño global del código.
a Reducción de defectos debida a la mejor definición de requeri-
mientos.
o Suaviza las curvas de esfuerzos que reducen el efecto de la fecha
límite (que normalmente surge cuando utlliza los enfoques tradi-
cionales de desarrollo).
Capítuto 20: Entrega evolutiva 467
REFERENCIA Si su versión de la entrega evolutiva tiende hacia la entrega por eta-

CRUZADA pas, podría esperar estos efectos secundarios:
Para más detalles
sobre estos efectos
secundarios, consulte o Distribución más uniforme de los recursos de desarrollo y prueba.
la Sección 36.3, o Mejora en 1a calidad del código.
"Efectos secundarios
de la entrega por o Más probabilidad de ftnalizat el proyecto.
etaPas". . Apoya los esfuerzos de trabajo cenffados en el presupuesto'
2O.4. lnteracciones de la entrega evolut¡va

con otros métodos
E1 éxito de la entrega evolutiva depende de la efectividad del uso de1 diseño
para el cambio (Capítulo 19). La entrega evolutiva invita a cambios, y su
sistema necesita estar preparado para acomodarse a ellos'
20.5. Puntos cruciales de la entrega evolut¡va

REFERENCIA El punto crucial de la entrega evolutiva consiste en que, rcdvzca o no el
CRUZADA tiempo de desarrollo en conjunto, proporciona signos tangibles de progreso,
sobre la importancia de que pueden ser tan importantes para el desarrollo rápido como la máxima
hacer visible el vetoii¿a¿ de desarrollo. Podría parecer que este enfoque incremental re-
progreso, consulte la
Sección 6.3, quiere más tiempo que un enfoque más tradicionai, pero casi nunca es así
.Percepción y porque impide que usted y sus clientes pierdan demasiado el contacto con
realidad..
el progreso rea1.
Hay estudios que indican que el prototipado evolutivo disminuye el
esfuerzo de un 45 a un 80 por 100 (Gordon y Bieman, 1995). Por otro
lado, la entrega por etapas no reduce habitualmente el tiempo de desarrollo,
DATOS REALES
pero hace el progreso más visible. La reducción específica en tiempo de
desarrollo debido a la entrega evolutiva dependerá de la mezcla específi-
ca que utilice del prototipado evolutivo y la entrega por etapas.
20.6. Claves para el éxito en el uso de la entrega

evolutiva
A continuación se muestran las claves para el éxito en el uso de la entrega
evolutiva:
¡ Asegurarse de que 1aarquitectura del producto admite todas las po-

sibles direcciones de1 sistema que pueda imaginar.
o Definir con cuidado el núc1eo del sistema.
-e-=a__
Decidir si se inclina más hacia el prototipado

evolutivo o hacia ia
entrega por etapas, basándose en el punto hasta
el que necesita adaf
tarse a las peticiones de cambios del cliente.
ordenar la funcionalidad en el conjunto iniciar
de entregas desde <<la
más segura>> a <da menos segura). Suponga
que el número de cam_
bios se incrementará en las últi-u, .rrtr"iur.
Gestionar explícitamente ras expectativas der
usuario relacionadas
la planificación, el presupuésto y el rendimiento.
1on
Considerar si la entrega por etapas pura o prototipado
el evolutir-cr
puro podrían ser una opción más conveniente
para iu proyecto.
Gilb, Tom: Principles of Software Engineering Management.Wokingham.
England: Addison-wesley, 19gg. Lo, .upítulo,
tivamente la entrega por etapas y la entrega
I y rc ftatan exhaus-
evolutiva.
Mcconnell, steve: code Comptete'. Redmond, wash.:
Microsoft press.
1993 ' El capítulo 27 describe el método
^
cusumano' Michaer, y-Richard Selby: MicrosoJi
de la entregu
"uor*uu.
secrets: How the worrd,s
Most Powerful Software Company Creates
Technology, Shapes Mar_
kets, qnd Mqnages people. New york: Free press, 199"i. El
Clpítulo a
describe el proceso de hitos de Microsoft, qu"
similar-a la entrega evolutiva. cusumano y
.. podría .orrri¿..u.
sétuy ,on pror.*ores en er
MIT y la uc Irvine' respectivamente, y presentan
la vrsión der proce-
so desde fuera.
McCarthy, Jim: Dynamics of Software Development.
Redmond, Wash.:
Microsoft press, r995. Mccaithy describe
una visión desde dentro del
proceso de hitos de Microsoft. Desde
el punto de vista de ra entrega
evolutiva, este libro es particurarmente interesante
porque se
centra en
visual c++, un producto <prét-á-porter)) por
suscripción que se entre-
ga cada cuatro meses.
;I
i'l
l
21
Prototipado evolutivo
El prototipado evolutivo es un modelo de ciclo de

tema se desarrolla en incrementos, de forma
que
vida donde el sis-
puede m.odificarse wffil
ffiffi1
demanerainmediataenrespuestaalarealimentacióndelclienteydel
usuario final. La mayoría Oe tos esfuerzos de
óá|].ll"nrun con el prótotipaoo de la interfaz de
prototipado evolutivo
usuario, y luego desa- ffil
rrollan el sistema
"or[f"to
puede
a partir de ésta, pero el prototipado ffiffi1
comenzar con cuatquiár areá de alto riesgo. El proto.tip.ado evolutivo
de forma correcta ffiffi1
y
no coincide con los prototipos desechables' escoger
sisedesarrollaunprototipadoevolutivoodesechableesunadelascla-
u".-páru tener éxiio. Otras claves para tener éxito incluyen
contar con
ffil
desarrollado,"."*p",.i*entados,gestionarlasexpectativasdeplanifica-
ffiffi1
de prototipado.
ción y presupuesto y gástionar íal propias actividades
Eficacia
Reducción potencial de la planificación nominal:
Excelente
Excelente
M;i;tt;" lá visibilidad del progreso: . .
Efecto sobre el riesgo de la plJnificación: Disrninuye el riesgo
Posibilidad de éxito a largo plazo:
Excelente
Riesgos PrinciPales
. Expectativas poco realistas de presupuesto y planificación'
. Usb ineficiente deltiempo de prototipado'
. Expectativas poco realistas de rendimiento'
. Mal diseño.
. Dificultades para el mantenimiento'
.Sacrificaunareducciónenelcontroldelproyectoparaaumentarla
realimentacióndelusuariofinalydelclienteymejorarlavisibilidad
del progreso'
ttantintia\
469
-*¡--
4m Desanollo y gestión de proyectos informáticos
. Se puede combinar con el prototipado de la interfaz de usuario y

con los prototipos desechables.
. Puede servir de base a la entrega evolutiva.
El prototipado evolutivo es un enfoque de desarrollo donde desarrolla pn-

mero las parles seleccionadas del sistema y luego desarrolla el resto
del sis-
tema a partir de esas partes. A diferencia de otros tipos de prototipado,
en ei
prototipado evolutivo no descarta el código del prototipo; lo iransforma
en el código entregado finalmente. La Figura 2l.l muestia cómo funciona.
El prototipado evolutivo apoya el desarrollo rápido controlando pron-
to los riesgos. El desarrollo empieza dentro de las áreas de más riesg.-,
del sistema. Si puede superar los obstáculos, puede desarrollar el resto dei
sistema a partir del prototipo. Si no puede superarlos, puede cancelar el
proyecto sin tener que gastar más dinero que el necesario en descubrir
que los obstáculos eran insuperables.
21.1. Uso del prototipado evolutivo

El prototipado evolutivo es una actividad exploratoria que se utllizacuando
no se conoce con seguridad lo que hay que construir. como las áreas
de
Diseño e Refinar el prototipo Completar

implementación hasta que sea y entregar
del prototipo aceptable el prototipo
inicial
Figura 21 .1. Modeto de prototipado evolutivo. Con et protot¡pado

evolutivo comienza diseñando e imprementando ras p^rt""
más distacaaas
del programa en un prototipo. Luego continúa aumentando y
refinando er
prototipo hasta que term¡na. Normalmente el prototipo
evotúciona y se
transforma en el software que se entrega.
Capítulo 21 : Prototipado evolutivo 471
incertidumbre presentes en un esfuerzo de desarrollo varían de un pro-

yecto a otro, el primer paso va a ser identificar la parte del sistema que se
va a uttlizar como punto de partida. Las dos opciones más importantes
son comenzar con las partes más visibles o con las partes de mayor riesgo.
La intefaz de usuario suele ser a menudo la parte visible y la de mayor
riesgo, de forma que suele ser el punto de partida obvio.
Después de construir la primera parte del sistema, la muestra y luego
continúa desarrollando el prototipo basándose en la realimentación que
recibe. Si su esfuerzo de prototipado está orientado al cliente, continuará
solicitando realimentación del cliente y redefiniendo la interfaz del usuario
hasta que todo el mundo esté de acuerdo en que e1 prototipo es suficien-
temente bueno. Luego desarrolla el resto del sistema utilizando como base
el diseño y el código del prototipo.
Si su esfuerzo de prototipado tiene una orientación técnica, podría
desarrollar primero cualquier parte del sistema, como la base de datos. En
este caso, la realimentación buscada no partirá necesariamente del cliente.
Su misión podría ser comprobar el tamaño de la base de datos o el rendi-
miento con un número realista de usuarios finales. Pero el patrón general
de prototipado fundamental es el mismo. Continúa buscando la realimen-
tación y redefiniendo el prototipo hasta que todo el mundo esté de acuer-
do en que el prototipo está suficientemente bien, y luego completa el sis-
tema. El mismo principio se aplica al prototipado de las interfaces de
usuario, cálculos complejos, rendimiento interactivo, restricciones de res-
puesta en tiempo real, tamaño de datos, y aspectos de los conceptos
de prueba de sistemas innovadores.
Puede utilizar el prototipado evolutivo con mayor o menor grado en la
mayoría de los tipos de proyectos. Probablemente será mejor para los sis-
temas de gestión, donde los desarrolladores pueden tener interacciones
frecuentes e informales con los usuarios finales. Pero también es adecua-
do para proyectos comerciales, <prét-á-porten y de sistemas, siempre que
pueda implicar a los usuarios finales. La interacción del usuario en este
tipo de proyectos normalmente tendrá que ser más estructuraday formal.
21.2. Gestión de los riesgos del prototipado evolutivo

A pesar de la amplia lista de riesgos a controlar, el prototipado evolutivo
es un método con un riesgo relativamente bajo. De 1os ejempios esrudia-
dos y publicados, 33 de 39 han tenido éxito (Gordon 1-Bieman. 1995). A
DATOS REALES
continuación se muestran algunos riesgos a tener en cuenta.
Expectativas poco realistas de presupuesto y planificación. E1

prototipado evolutivo puede crear expectativas poco fiables sobre la p1a-
nificación general de desarroilo. Cuando los usuarios fina1es. directivos o
FE==FENCIAS responsables de marketing ven el progreso rápido en un prototipo, a ve-

CRUZADAS
r¿-a -ás información ces hacen suposiciones poco realistas sobre la rapidez con que pueden
sobre riesgos desarrollar el producto final. En algunos casos, el personal de ventas pasa
'e ac.onados, consulte
a los clientes expectativas de planificación poco realistas. Posteriomen-
la Sección 38.2,
.Gestión de los te, los clientes se enfadan cuando escuchan que el software tardará más
riesgos de los tiempo del que esperaban.
prototipos
desechables., y la Es fácil terminar rápidamente el trabajo más visible, pero gran parte
Sección 42.2, "Gestlón del trabajo en un proyecto de programación no es obvio para el cliente ni
de los riesgos del
prototipado de la
para el usuario final. E1 trabajo de poca visibilidad incluye un acceso ro-
interfaz de usuario". busto a bases de datos, mantenimiento de la integridad de 1a base de datos.
seguridad, redes, conversión de datos entre sucesivas versiones del pro-
ducto, diseño para un gran volumen de uso, soporte multiusuario y sopor-
te multiplataforma. Cuanto mejor sea el trabajo realizado, menos notable
se hará.
Otro problema que surge con las expectativas de esfuerzo creadas cuan-
do e1prototipado comienza desde lainterfaz de usuario es que parte de la
funcionalidad que parece más fácil desde el punto de vista del usuario
final es más difícil de implementar desde el punto de vista del desarrollador.
Las áreas difíciles que parecen fáciles incluyen cortar y pegar dentro de la
aplicación, cortar y pegar desde otras aplicaciones, imprimir, la presenta-
ción preliminar lo que se va a imprimir y mostrar la pantalla WYSIWYG.
Finalmente, los prototipos se diseñan generalmente para que sólo gestio-
nen los casos nominales; no se espera que controlen los casos excepciona-
DATOS REALES
les. Pero la gestión de excepciones requiere hasta un 90 por 100 de un
programa normal (Shaw en Bentley, 1982),lo cual indica que incluso si
un prototipo funcionara completamente para todos los casos nominales, aún
podría requerir un esfuerzo 9 veces mayor implementar los casos excepcio-
nales que implementar la funcionalidad completa del prototipo nominai.
Si la directiva no comprende la diferencia entre crear un prototipo limi-
tado y un producto completo, correrá el riesgo de presupuestar a la baja los
proyectos de prototipado. Scott Gordon y James Bieman hablan de un
caso donde la directiva presupuestó un proyecto de 2 años como un proyec-
to de 6 semanas. La directiva creía que el prototipado produciría resultados
totalmente funcionales en una cantidad de tiempo alena a las necesidades
del mundo real en un factor de alrededor de 20 (Gordon y Bieman, 1995).
REFERENCIA Estos riesgos se pueden gestionar directamente, gestionando las ex-
CRUZADA
pectativas de los usuarios finales, directivos, desarrolladores y responsa-
sobre la gestión de Ias bles de marketing. Asegúrese de que interactúan con el prototipo de for-
expectativas consulte la
ma controlada, de manera que pueda explicar las limitaciones del prototipo,
de las expectativas y asegúrese de que comprenden la diferencia entre crear un prototipo y
del cliente". crear un software completamente funcional.
Disminución del control del proyecto. Con el prototipado evolutivo

es imposible conocer al principio el tiempo que nos va a llevar crear un
Capítulo 2l: prototipado evolutivo 4Tg
producto aceptable. No se conocen las iteraciones que se van

a hacer ni
cuánto durará cada iteración.
REFERENCIA Este riesgo es mitigado en parte por er hecho de que ros
CRUZADA clientes pueden
Para obtener más ver continuos signos de progreso y en definrtiva tienden a estar menos
detalles sobre la nerviosos por la posible obtención de un prod.ucto que con los métodos
obtención de benef icios de
desarrollo tradicionales. También es positle utilizarun método
con el prototipado de entrega
evolutivo y la entrega evolutiva fuertemente orientado hacia el prototipado evolutivo, lo
por etapas, consulte el cual
proporciona el control de la entrega por etapas y la flexibilidad
Capítulo 20, "Entrega del proto-
evolut¡va.. tipado evolutivo.
REFERENCIA Mala realimentación con el usuario final o cliente. El prototipado

CRUZADA
Para más detalles
no garantiza una gran calidad en la realimentación del usuario final o
clien_
sobre ei riesgo de la te. Los usuarios finales y 1os clientes no siempre saben lo que están
mala realimentación,
viendo
cuando ven un prototipo. Es común que estén tan abrumadá, po,
consulte "compromtso ra demos-
y reallmentación con tración del software funcionando que no se den cuenta de lo que el prototipo
el usuar¡o", en la representa realmente. Si aprueban maquinalmente su trabajo, pu.d"
Sección 42.1. t.n..
la seguridad de que no comprenden totalmente lo que están viendo.
Asegú-
rese de que los usuarios finares y los crienter .rtudiun er prototipo
con
suficiente cuidado para proporcionar una realimentación significativa.
Bajo rendimiento der producto. Hay varios factores que pueden

con-
tribuir a un bajo rendimiento del producto, incluyendo:
o No considerar el rendimiento en el diseño del producto.

o Mantener un código ineficiente y ma1 estructurado que fue desarro-
liado con rapidez para el prototipo en vez de desarrollarlo para
que
fuera de calidad.
r Mantener un prototipo que en un principio se iba a desechar.
Para minimizar los riesgos de un bajo rendimiento puede

seguir estos
tres pasos:
o considerar el rendimiento al principio. Asegúrese de controlar el

rendimiento al principio, y asegúrese de que er diseño der prototi-
po admite un nivel de rendimiento adecuado.
o No desarrolle el código paÍa el prototipo de forma rápiday mala.
La calidad del código der prototipo necesita ser ro suf,icientemente
buena para que admita grandes modificaciones, 1o que significa
que
necesita que al menos sea tan bueno como er código de"un
sistema
desarrollado tradicionalmente.
. No convierta un prototipo desechable en el producto final.
Expectativas poco realistas de rendimiento. El riesgo de las

ex-
pectativas de rendimiento poco realistas está relacionado
con el riesgo de
un bajo rendimiento. Este riesgo se presenta cuando el rendimiento del

prototipo es mucho mejor que el del producto final. Como un prototipo
no tiene que hacer todo el trabajo del producto final, a veces puede ser
muy rápido comparado con el producto final. Cuando los clientes ven el
producto final, puede parecerles inaceptablemente lento.
Este riesgo también tiene una contrapartida diabólica. Si se utiliza un
lenguaje de prototipado que tiene un rendimiento mucho peor que el len-
guaje definitivo, los clientes podrían comparar los puntos débiles en el
rendimiento del prototipo con los puntos débiles en el producto final. Más
de un estudio ha reflejado el fracaso de un proyecto como resultado de las
bajas expectativas creadas por un prototipo (Gordon y Bieman, 1995).
Puede controlar este riesgo gestionando explícitamente las expec-
tativas que los clientes desarrollan a partir de la interacción con el pro-
totipo. Si el prototipo es muy rápido, incorpore retardos artificiales al
prototipo, de forma que el rendimiento del prototipo se aproxime al del pro-
ducto final. Si el prototipo es muy lento, explique a los clientes que
el rendimiento del prototipo no es indicativo del rendimiento del pro-
ducto final.
Mal diseño. Muchos proyectos de prototipado tienen mejores diseños

que 1os proyectos tradicionales, pero hay varios factores que contribuyen
al riesgo de un mal diseño.
Un diseño del prototipo puede deteriorarse, y su implementación

puede apartarse de su diseño original durante etapas sucesivas (igual
que la mayoría de los productos software tienden a empeorar du-
rante el mantenimiento). El producto final puede heredar partes del
diseño del sistema prototipo.
A veces la realimentación de los usuarios finales o clientes dirige
el producto en una dirección inesperada. Si el diseño no anticipó la
dirección, podría ser tergiversado para adaptarlo sin volver a hacer
un diseño completo.
El diseño resultante de una actividad de prototipado centrada en la
interfaz de usuario podría centrarse excesivamente en la interfaz
de usuario; podría fallar en otras partes del sistema que deberían
tener también una fuerte influencia en el diseño del sistema.
REFERENCIA El uso de un lenguaje especial de prototipado tiene como resultado
CRUZADA
un mal diseño del sistema. Los entornos adecuados para hacer rá-
sobre el fomento de pidos progresos durante las etapas iniciales de desarrollo a veces
los lenguajes de
no se adaptan a mantener la integridad en el diseño en estados de
desarrollo rápido.
consulte la desarrol I o posteriores.
Sección 28.3,
"Gestlón de Puede mitigar los riesgos de la calidad del diseño atacando el pro-
los riesgos de
los LDR". blema de raí2. Limite el ámbito del prototipo a áreas específicas del
Capítulo 21 : Prototipado evolutivo 475
l
producto, por ejemplo, a la interfaz de usuario. Desarrolle esta parte limi-

tada del producto utilizando un lenguaje de prototipado, y desarróllelo;
luego desarrolle el resto del producto utilizando un lenguaje de progra-
mación tradicional y métodos que no sean de prototipado.
Cuando cree el diseño del sistema completo. haga un esfuerzo cons-
ciente para no poner mayor énfasis en la interfaz de usuario o en cualquier
otro aspecto del sistema que haya sido prototipado. Minimice el impacto
que puede tener el diseño de un área en todo el diseño en general.
Incluya una fase de diseño en cada iteración del prototipo para asegurar
que hace evolucionar el diseño y no sólo el código. Utilice una lista de
comprobación en cada etapa para comprobar la calidad del producto desa-
rrollado.
Evite usar a desarrolladores sin experiencia en un proyecto de prototipa-
do. El prototipado evolutivo necesita que los desarrolladores tomen decisio-
nes trascendentales sobre el diseño en el proceso de desarrollo mucho antes
que cuando se utiliza otro método de desarrollo. Los desarrolladores sin
experiencia suelen estar mal equipados para tomar buenas decisiones de
ERROR CLASICO diseño bajo tales circunstancias. Hay estudios de proyectos de prototipado
que han informado de proyectos que han fallado a causa de la participa-
ción de desarrolladores sin experiencia. También han informado de pro-
yectos que han tenido éxito gracias a la participación de desarrolladores
experimentados (Gordon y Bieman, 1995).
Dificultades para el mantenimiento. A veces e1 prototipado evolu-

tivo contribuye a aumentar ias dificultades para e1 mantenimiento. El
alto grado de modularidad necesario para que el prototipado evolutivo sea
efectivo conduce a un código fácil de mantener. Pero cuando el prototipo
se desarrolla de forma extremadamente rápida, a veces también se desa-
rrolla de forma extremadamente descuidada (el prototipado evolutivo
se puede utllizar como un disfraz para el desarrollo de tipo codificar y
corregir). Por otra parte, si se utiliza un lenguaje de prototipado de pro-
pósito especial, es posible que los programadores de mantenimiento
no estén familiarizados con el lenguaje, 1o que dificultará el mante-
nimiento del programa. En los libros publicados sobre prototipado, hay
más publicaciones en las que se ha observado un peor mantenimiento con
el prototipado evolutivo que con métodos tradicionales (Gordon y Bie-
man, 1995).
Minimice el riesgo de mantenimiento siguiendo algunos pasos sim-
ples. Asegúrese de que el diseño es el adecuado utilizando las directrices
comentadas en el riesgo de <mal diseño> (en la sección anterior). Utilice
listas de comprobación de calidad en cada etapapara mantener la calidad
del código del prototipo desde el principio. Siga los convenios de nomen-
clatura normales para los objetos, métodos, funciones, datos, elementos
de la base de datos, bibliotecas y cualquier otro componente que vaya a
*--
176 Desarrollo y gestión de proyeetos informáticos
mantenerse a medida que evolucione el prototipo. Siga los convenios de

codificación para una buena presentación y comentarios. Recuerde al equi-
po que tendrá que usar su propio código a 1o largo de múltiples ciclos cie
entregas del producto (esto les dará un gran incentivo para hacer que su
código sea fácil de mantener y siga estando así).
REFERENCIA Cambio de prestaciones. Los clientes y usuarios finales normai-

CRUZADA mente tienen acceso directo al prototipo durante un proyecto de pro-'
Para obtener más
informac¡ón sobre la totipado evolutivo, y eso a veces l1eva al deseo de más prestaciones.
gestión de cambios, Además de gestionar sus interacciones con el prototipo, use las técnica.
consulte el Capítuto 14,
.Control del conjunto habituales de control de cambios para controlar el incremento de pres-
de prestaciones". taciones.
Uso ineficiente del tiempo de prototipado. El prototipado nor-

malmente se realiza con la intención de reducir la planificación de desa-
rrollo. Paradójicamente, los proyectos suelen perder tiempo durante el
prototipado, y no ahorran tanto tiempo como deberían. El prototipado es
un proceso exploratorio e iterativo, de forma que incita a tratarlo como un
ERROR CLASICO proceso que no se puede gestionar con cuidado. Los desarrolladores
no siempre conocen larapidez con que van a desarrollar el prototipo, de
forma que a veces desarrollan prestaciones que más tarde se excluyen del
producto. A veces los desarrolladores le dan al prototipo una robustez
que no necesita, o pierden tiempo trabajando en el prototipo sin seguir
una dirección clara.
Para emplear el tiempo de prototipado de forma efectiva, considere
prioritario el seguimiento y control del proyecto. Planifique con cuidado
las actividades de prototipado. Más tarde podría dividir el proyecto en
intervalos de unos cuantos días o semanas, pero durante el prototipado.
divídalo en horas o días. Asegúrese de no realizar mucho trabajo durante
el prototipado y 1a evolución de cualquier parte del sistema hasta que esté
seguro de que va a formar parte del sistema.
Los desarrolladores deben tener muy claro 1o poco que pueden ha-
cer para investigar las áreas de riesgo que está intentando explorar con
un prototipo. En un proyecto en el que trabajé, necesitábamos crear un
prototipo de la interfaz de usuario para mostrar el diseño de nuestra in-
terfaz de usuario al promotor. Uno de los desarrolladores pensó que de-
beríamos formar un equipo de tres desarrolladores durante 6 semanas
para construir el prototipo. Pensé que yo solo podría hacer todo el tra-
bajo en una semana, 1o que fue exacto. La diferencia en nuestras esti-
maciones no surgió porque yo fuera seis veces más rápido que los tres
desarrolladores juntos; esto surgió porque el otro desarrollador no tenía
claras todas las cosas que había que saltarse en ese tipo de prototipo. Por
tanto, intente evitar a desarrolladores sin experiencia en proyectos de
prototipado.
Capítulo 21 : Prototipado evolutivo
21.3. Efectos secundarios del protot¡pado evolutivo

Además de sus beneficios de desarrollo rápido, el prototipado evolutivo
produce muchos efectos secundarios,lamayoría de Ios cuales son benefi-
ciosos. El prototipado tiende a:
o Mejorar la moral de 1os usuarios finales, clientes y desarrolladores,

porque el progreso es visible.
¡ Realimentación temprana sobre 1a aceptación del sistema final.
¡ Disminución del tamaño general del código debido a los mejores
diseños y a la mayor reutllización.
o Menor tasa de defectos gracias a la mejor definición de los requeri-
mientos.
o Curvas de esfuerzo más suaves, reduciendo el efecto del plazo lí-
mite (habitual cuando se utilizan métodos de desarrollo tradicio-
nales).
21.4. lnteracciones del prototipado evolut¡vo

con otros métodos
El prototipado evolutivo es un remedio efectivo para el aumento de pres-
taciones cuando se utiliza con otros métodos. un estudio descubrió que la
DATOS REALES
combinación del prototipado y JAD (Capítulo 24) fue capaz de mantener
el cambio de requerimientos por debajo de un 5 por 100. Los proyectos
medios experimentan niveles cercanos al 25 por 100 (Jones, 1994).
El prototipado evolutivo también es un método efectivo para eliminar
defectos combinado con otros métodos. Una combinación de revisiones,
inspecciones y pruebas presentan una estrategia para eliminar defectos
con una mayor eficacia. un menor coste, y una planificación más reduci-
da. A1 incorporar prototipado a esta mezcla se obtiene una estrategia de
eliminación de defectos con una mayor eficacia acumulada en la elimina-
ción de defectos (Pfleeger, 1994a).
Si el prototipado evolutivo proporciona menos control del ne-
cesario o ya conoce lo que el sistema va a real,izar, puede utilizar en
su lugar la entrega evolutiva (Capítulo 20) o la entrega por etapas (Capí-
tulo 36).
Relación con otros tipos de prototipado

En sistemas pequeños, es prelerible usar prototipado evolutil-o que pro-
totipos desechables, ya que el coste de la creación de un prototipo dese-
chable hace que sea económicamente inviable. Si está considerando
desarrollar un prototipo desechable para un proyecto pequeño o mediar;..

asegúrese de que puede recuperar la inversión en la vida del proyecto.
En sistemas grandes (sistemas con más de 100.000 líneas de códig;
puede utilizar el prototipado evolutivo o los prototipos desechables. ,1-
veces, los desarrolladores se muestran reticentes autllizar el prototipal:
evolutivo en los sistemas grandes, pero los informes publicados sobre -
uso del prototipado evolutivo en sistemas grandes indican que ha sil:
siempre un éxito (Gordon y Bieman, 1995).
21.5. Puntos cruc¡ales del prototipado evolutivo

En algunos ejemplos, el prototipado evolutivo ha disminuido de fom-
impresionante el esfuerzo de desarrollo, de un 45 a un 80 por 100 (Go:-
DATOS REALES don y Bieman, 1995). Para conseguir este tipo de reducción, debe ges-
tionar con cuidado los riesgos del desarrollo, particularmente los riesgt-=
de un mal diseño, dificultades para el mantenimiento y cambio de pre.-
taciones. Si no lo hace, puede que el esfuerzo general aumente.
El prototipado proporciona sus beneficios rápidamente. Capers Jones
estima que el prototipado evolutivo devolverá alrededor de dos dólares
por cada dólar gastado durante el primer año, y aumentará hasta 10 dó1"-
res por cada dólar gastado en un plazo de cuatro años (Jones, 1994).
El prototipado también proporciona signos continuos y visibles d=-
progreso, mejorando la visibilidad del mismo y contribuyendo a la impre-
sión de que se está desarrollando rápidamente. Esto puede ser especiai-
mente útil cuando hay una fuerte demanda en la velocidad de desarrollc
El coste directo debido a iniciar un programa de prototipado evoiur-
vo es bajo (sólo el coste necesario para preparar al desarrollador y las
herramientas de prototipado).
21.6. Glaves para el éxito en el uso del protot¡pado

evolutivo
A continuación se muestran las claves para el éxito en el uso del prototi-
pado evolutivo:
Decidir al comienzo del proyecto si va a desarrollar el prototipo o

lo va a desechar. Asegúrese de que los directivos y desarrolladores se
han reunido para seguir el curso de la opción que han seleccionado
Gestionar explícitamente las expectativas de los clientes y usur-
rios finales relacionadas con la planificación, el presupuesto \ e-
rendimiento.
I
l'
Capítulo 21: Prototipado evolutivo 479
Limitar la interacción del usuario final con el prototipo para controlar

los requerimientos.
Utílizar a desarrolladores experimentados. Evitar utilizar a desarro-
lladores recién llegados.
Utllizar listas de comprobación del diseño en cada etapa para ase-
gurar la calidad del sistema prototipado.
Utilizar listas de comprobación de la calidad del código en cada
etapapara asegurar el mantenimiento del código prototipado.
a Considerar el rendimiento desde el principio.
a Gestionar con cuidado la propia actividad de prototipado.
a Considerar si el prototipado evolutivo proporcionará los mayores
beneficios o si sería mejor la entrega evolutiva o la entrega por
etapas.
Bibl iograf ía adicional

Gordon, V. Scott, y James M. Bieman: <Rapid Prototyping: Lessons Lear-
ned>>, IEEE Software, enero 1995, 85-95. Este artículo resume las lec-
ciones aprendidas en 22 ejemplos publicados de prototipado y de va-
rios ejemplos anónimos.
Connell, John, y Linda Shafer: Object-Oriented Rapid Prototyping. En-
glewood Cliffs, N.J.: Yourdon Press, 1995. Este libro presenta las ra-
zones por las que debería ulllizar prototipado y los diferentes estilos
de prototipado. Luego presenta una discusión completa e inteligente
sobre el prototipado evolutivo orientado a objetos, incluyendo temas
sobre las directrices del diseño, herramientas, refinamiento de proto-
tipos y modelos de ciclo de vida compatibles con el prototipado.
22
Definición de obietivos
La definición de objetivos utiliza el hecho de que la motivacbn.humana

unlco y más
eS el único
es colaborador ell
éOt¡Oo colaooraoor
mas solloo PIUuut/trvruqu' Lrr
en la productividad. En rq uv¡rrl'
la defini-
m"*
ción de objétivos, un responsable del producto o cliente simplemente ffiffi
lesindicaálosdesarrolladoresloqueeSperadeellos'Comoladefini-ffi
cióndeobjetivoscontribuyealamotivación,normalmentelosdesarro-ffi
lladorestráoajaránduro[araconseguirunobjetivode"planificación
más corta, (o planificacién menos airiesgada, o progreso más visible
o cualquiera que sea el objetivo). El principal obstáculo para tener ex'- ffi;Tffi
ffiTffiffim
to es la falta de voluntad al definir un conjunto de objetivos pequeño y trffiffi
claro, y comprometerse con ellos durante todo el proyecto' ffi
Eficacia Objetivo de Obietivo de Obietivo de
planificación menor visibilidad
más corta riesgo máxima
Reducción potencial Muy buena Ninguna Ninguna

de la planificación
nominal
Mejora en la visibilidad Ninguna Buena Excelente
del progreso
Efecto sobre el riesgo Aumenta Disminuye DisminuYe
de la planificación el riesgo riesgo
el el riesgo
Posibilidad Buena Buena Buena
de éxito inicial
Posibilidad de éxito MuY buena Muy buena MuY buena
a largo plazo
Riesgos principales
. Pérdida significativa de motivación si cambian los objetivos.
(conrinúa)
481
Desarrollo y gest¡ón de proyectos informáticos
Interacciones y compromisos pr¡nc¡pales

. Proporciona el soporte clave para el compromiso, desarrollo cr
ventanas temporales, horas extras voluntarias, y motivación en ge:-
neral.
Las clasificqciones de esta tabla dependen del objetivo específico. p;.s

más información sobre la definición de objetivos, consurte <Definicí:,r
de obletivos>, en la Sección I 1.2.
23
lnspecciones
Las inspecciones son un tipo de revisión técnica formal, en las que los
participantes en la revisión están bien formados en métodos de revi- ffi
sión y tienen asignadas tareas específicas. Los participantes comprue- ffi
ban el material de la revisión antes de la reunión de la revisión, utili-
zando listas de errores comunes. Las funciones desempeñadas durante ffi
la reunión de la revisión ayudan a estimular el descubrimiento de erro- ffi
res adicionales. se ha descubierto que las inspecciones son mucho
más efectivas para encontrar errores que las pruebas de ejecución, ffi
tanto en el porcentaje de defectos totales encontrados como en el tiempo ffi
empleado en cada defecto. sus ventajas para el desarrollo rápido provie-
nen de detectar errores al principio del proceso de desarrollo, lo cual
evita volver a repetir el trabajo posteriormente. Las inspecciones prácti-
ffi
camente se pueden utilizar en cualquier tipo de proyecto, tanto para
nuevos desarrollos como para mantenimiento.
Eficacia
Reducción potencial de la planificación nominal: Muy Buena
Riesgos principales
Ninguno.

. Se puede combinar prácticamente con cualquier otro método de
desarrollo rápido.
Pqra obtener mayor información sobre las inspecciones, véanse <Inspec-

ciones>, en la Sección 4.3, y <Bibliografía adicional sobre los ftrttdonten-
tos del control de calidad>, al Jinal de la Sección 4.3.
483
24
Desarrollo coniunto
de aplicaciones (JAD)
JAD es una metodología de definición de requerimientos y de diseño

ffi
de la interfaz de usuario en la cual los usuarios finales, ejecutivos y de-
sarrolladores asisten a intensas reuniones para trabajar sobre los deta- ffi
lles del sistema. JAD se centra más en problemas comerciales que en
ffi
detalles técnicos. Es más aplicable al desarrollo de software de gestión,
pero se puede utilizar con éxito para softwa¡s "prét-á-porter' y de sis- ffi
temas. Obtiene su ahorro disminuyendo el tiempo necesario para re-
ffi
copilar los requerimientos de un sistema y mejorando la recopilación
de los mismos, reduciendo de esta forma el número de costosos cam- ffi
bios posteriores en los requerimientos. Su éxito depende de la efectivi-
dad de los líderes de las sesiones JAD; en la participación de usuarios
ffi
finales, dirigentes y desarrolladores clave; y de alcanzar una sinergia
de grupo durante las sesiones JAD.
Eficacia
Reducción potencial de la planificaciÓn nominal: Buena
Riesgos principales
. Previsiones de productividad poco realistas tras las sesiones JAD.
. Estimaciones incorrectas y prematuras del trabajo pendiente tras
las sesiones JAD.
Interacciones y equilibrios principales

. Funciona mejor cuando se combina con un modelo de ciclo de vida
de desarrollo incremental.
. Se puede combinar con lenguajes de desarrollo rápido y herramien-
tas de prototipado.
485
JAD significa <Desarrollo conjunto de Aplicaciones). (cory'unto> hat-e

referencia al hecho de que los desarrorladores, usuarios fináres y orrtu<
partes interesadas diseñan conjuntamente el concepto de producto.
Es u¡
proceso estructurado para la recopilación y negociación de los
requeri-
mientos. El proceso se centra en una serie de seminarios a los que asisten
ejecutivos, usuarios finales y desarrolladores.
JAD fomenta la dinámica de grupo, el uso extensivo de herramientas
visuales, la documentación wysIWyG, y el desarrollo de un procesL-)
racional y organizado para recopilar los requerimientos en un corto período
de tiempo. JAD es uno de los métodos de especificación de requerimien-
tos más potentes desarrollados, y permite ahorrar tiempo y esfuerzo de
muchas formas.
REFERENCIA compromete a los altos ejecutivos en el proceso de planificación

CRUZADA
Para más información del software. JAD compromete a los altos ejecutivos desde el comien-
sobre la reducción del zo del desarrollo de un producto. La participación de los ejecutivos desde
tiempo al princip¡o del
ciclo de desarrollo de
el principio implica la disminución del ciclo de aceptación del producto.
un producto, consulte
la Secc¡ón 6.5, Reduce la fase de especificación de requerimientos. JAD reduce la
"Distribución del
tiempo empleado". cantidad de tiempo necesario para recopilar los requerimientos, lo cual dis-
minuye el ciclo de desarrollo en general. E,sto es paiticularmente útil porque
la especificación de requerimientos puede ser una actividad esencialmente
indefinida, que incremente en semanas o meses er inicio del proyecto.
Elimina prestaciones de valor cuestionable. JAD reduce el tiempo de

desarrollo eliminando prestaciones cuestionables y reduciendo el prod.ucto.
Ayuda a obtener correctamente ros requerimientos desde er prin-

cipio. Los analistas de requerimientos y los usuarios finales hablan
lenguajes diferentes, 1o cual significa que la posibilidad de que
su comu-
nicación respecto a los requerimientos del software sea efectiü es
mínima.
JAD mejora la comunicación y elimina las costosas revisiones derivadas
de unos requerimientos erróneos.
Ayuda a obtener correctamente ra interfaz de usuario a ra primera.

Algunos productos necesitan una extensa revisión debido u qu" io,
uruu-
rios finales rcchazanla inferfaz de usuario del producto. Las sesiones
de
diseño JAD se centran en el diseño de la interfaz de usuario . La
interfaz
de usuario desarrollada es normalmente aceptada por los
usuarios finales,
ya que éstos están implicados en esas sesiones.
Reduce las disputas dentro de la organización. Muchos proyectos

s_on obstaculizados por objetivos contrarios o previsiones ocurtas.
Reunien-
do a todas las personas que toman decisiones para er diseño del
sistema,
-€
I
Capítulo 24: Desarrollo conjunto de aplicaciones (JAD) 487
JAD saca estas cuestiones a la luz en la fase inicial del proyecto, cuando
aún pueden ser resueltas correctamente y antes de que haya transcurrido
tiempo para que puedan hacer mucho daño. -l
24,1. Uso de JAD
JAD consta de dos fases principales, una fase de planificación JAD y una
fase de diseño JAD. Ambas fases trabajan con 1o que tradicionalmente se
conoce como los requerimientos del sistema, pero a niveles diferentes. En
ambas fases, JAD se centra más en el problema de diseño del concepto de
la aplicación que en los detalles puramente técnicos.
Durante la fase de planificación JAD, se hace hincapié enla organiza-
ción de las posibilidades generales del sistema software. Se hace más énfa-
sis en 1o que concierne al concepto de la aplicación que en 1o que concierne
a los detalles técnicos. El resultado principal de la fase de planificación JAD
son los objetivos del sistema, las estimaciones preliminares de esfuerzo y
planificación, y la decisión sobre la continuación del desarrollo del produc-
to. La planificación JAD también configura la fase de diseño JAD.
Si se toma la decisión de seguir adelante con el producto, se continúa
con la fase de diseño JAD. El diseño JAD obtiene requerimientos más
detallados, y su objetivo es crear el diseño del software a nivel de usuario.
A pesar de llamarle <diseño>, no se centra en el diseño funcional del sis-
tema, que es lo que cabe creer cuando se piensa en el término <diseño>.
El diseño JAD utiliza prototipos de forma extensiva, y el principal obje-
tivo de esta fase es un diseño detallado de la interfaz de usuario, un esquema
de la base de datos (si es conveniente), y unas estimaciones refinadas de
la planificación y el presupuesto. Al final de esta fase, el proyecto debe
aprobarse de nuevo antes de poder continuar.
Como sugiere la Figura 24.1 , fanto la fase de planificación como la de
diseño están divididas en tres partes:
1. Personalización.El responsable de 1a sesión, y posiblemente unas

cuantas personas más, toman el esquema de la metodología JAD
y lo adaptan al proyecto específico. Normalmente necesitan de
I a 10 días.
2. Sesión. La sesión es el momento en el que se reúnen todas las
partes, y es el núcleo principal de JAD. Normalmente tardan de
1 a 10 días, dependiendo del tamaño del sistema.
3. Generación de documentación. La generación de documentación
consiste en la recogida o generación de documentación sobre la
actividad de la sesión. Las notas escritas a mano y las ayudas vi-
suales se convierten en uno o más documentos formales. Esto re-
quiere de 3 a 15 días.
I
,¿l8g Desarrollo y gestión de proyectos informáticos
,.\ Revisa
:lG;;
materi¿
Personalización Sesión Generación de

documentación [:vJ
'' -| '
Aprobación
Figura 24'r. visión generar der proceso JAD.

La pranificación y et diseño
JAD se organizan con una secuencia similar
de actividades.
Fuente: Adaptado de Joint Application Oesign
téét).
6ugust,
REFERENCIA una vez terminada la fase de diseño JAD, se pasa

CRUZADA tan rápido como sea
Para obtener más posible alaparte instrumentar dentro de tas
iases drl ¿irero'áeiirog.u*u
información sobre Ios y de la construcción- JAD.no impone ningún
modelos del ciclo de diseño d. p;";;; ni nin-
gún método de construcción en particula{pero
v¡da, consulte el es especialmente compa-
Capítulo 7, tible con los moderos de ciclo de vida incrementales
"Planificac¡ón del
y con el uso de he-
rramientas CASE.
ciclo de vida".
Aunque originariamente ra metodorogía JAD
se desarrolró para su uso
en entornos de sistemas de información
basados en marnnamJi tam¡i¿n
se ha utilizado varias veces en er desarrollo
de software cliente-servidor
(August, 1991; Martin,.r99r; Sims, 1995).
La técnica de intentar reunir a
todas las partes para discutir ros requeriiientos
de un sistema es igual_
mente aplicable a productos comerciales,
software de mercado vertical,
software <prét-á-porten> y software de sistemas. puede
utilizar ras sub-
fases de personalización de ra planificación
y er diseño JAD para adaptar
JAD a proyectos de cualquier ilu." y tamaño.
Planificación JAD
La planificación JAD se- centra en requerimientos
y pranificación. Sus
objetivos son identificar ros requerimientos
de alto nivel, definir y deli_
mitar los límites del ámbito der iistema, planificar ra
actividad del diseño
JAD, publicar el documento del plan JAb, y
obtener la aprobació n pan
actividad del diseño JAD. En ocasiones,
u tu rur. de planificación JAD,
'a
también se le denomina pranificación conjunta
de requerimientos. o JRp
Capítulo 24: Desarrollo conjunto de aplicaciones (JAD) 4gg
(Martin, 199 l). Las secciones siguientes describen las subfases de perso-
nalización, sesión y la generación de documentación.
Personalización
El objetrvo de la actrvidad de personarización es adaptar la sesión de pla-
nificación JAD a las necesidades específicas del próyecto. Las activida-
des principales durante 1a personalización son:
1. Orientar a los participantes del proceso JAD.

2. Organizar el equipo JAD.
3. Adaptar las tareas JAD y los objetivos al proyecto específico.
4. Preparar los materiales para la sesión de planificación JAD.
Las personas que participan en la planificación normalmente no son

las mismas que participan en el diseño. Los participantes de una sesión de
planificación suelen ser los más altos cargos en la organización. En el
diseño JAD participan personas que serán propietarias del sistema o que
trabajarán con él cuando se construya. Si estas personas de alto nivel y
trabajadores sobre el terreno son los mismos, puede combinar la planifi-
cación y el diseño en una fase.
Sesión
La sesión JAD es lo que establece la diferencia entre JAD y otros méto-
dos de recopilación de requerimientos. Las partes críticas de ra sesión
JAD incluyen el liderazgo por parte de un responsable JAD cuarificado,
la participación de un promotor ejecutivo y otras personas claves en la
toma de decisiones, el uso de un proceso estructurado y la posibilidad de
trabajar sin las interrupciones habituales.
Duración
REFERENCIA como se dijo anteriormente, una sesión JAD puede tardar de 1 a 10 días.
CRUZADA
Para obtener más
JAD es una actividad en equipo, de forma que se apiican las directrices
información sobre los habituales para el trabajo en equipo. Normalmente se necesit an2 días paru
factores que hacen que un equipo JAD se consolide (Martin, 1991). Si la sesión JAD dura
que los equipos se
consoliden, véase 5 días, el equipo realizará la mayor parte de su trabajo a partir der ter-
el Capítulo 12, "Equipo cer día.
de trabajo".
Sin tener en cuenta la duración de la sesión JAD, los participantes
deben estar siempre presentes. Si algunos participantes sóro asisten a par-
te de las sesiones, se pierde tiempo informándoles y poniéndose al co-
niente de los acontecimientos. Para conseguir la sinergia de grupo de una
sesión JAD, todos los miembros del grupo tienen que estar presentes.
lnstalaciones
La sala de reuniones JAD debe estar situada fuera de1 lugar de tr:::-:
idealmente en un hotel o en un lugar apropiado para conferencias. -:-*
participantes JAD son normalmente personas claves en la organizsct--
1as personas claves tienen habitualmente docenas de posibles disirac;-:-
nes. La instalación deberá liberar a los participantes de sus distraccic:=t
normales y permitirles centrarse exclusivamente en la sesión JAD. P--
mitir que los participantes respondan a las interrupciones durante una ..-
sión JAD sugiere que la sesión JAD no es importante.
La sala JAD debería incluir aparatos de medios visuales, compute;:-
ras, fotocopiadoras, bloc de notas, lápices, cámara Polaroid para gra-r--
contenidos delapizarra, tarjetas de identificación (si se necesitan). L'e:'-
das y refrescos, tanto para la planificación como para el diseño. Es;
combinación de recursos lanzaun mensaje importante a los participanr;=
JAD: <Este trabajo es importante,y la organización está detrás de usteri¡:
con su apoyo.)
Funciones
Una sesión JAD incluye una serie de personas.
Responsable de la ses¡ón. El responsable de la sesión es la persona

que más contribuye al éxito o fracaso del JAD, y un responsable con éxit.-
necesita poseer una rara combinación de habilidades. El responsable
debe tener unas excelentes capacidades de comunicación y mediación"
El responsable debe servir de mediador en las disputas políticas, en
1as luchas de poder y en los conflictos personales. El responsable nece-
sita ser imparcial (llegar a la sesión JAD sin ideas políticas) y tener la
capacidad de mantener la mente abierta y controlar las controversias. El
responsable debe ser receptivo frente a previsiones ocultas y debe ser ca-
paz de redirigirlas constructivamente. El responsable debe salvar los
vacíos de comunicación. El responsable debe sentirse a gusto hablando ¡
controlando a un grupo de personas entre las que se incluyen ejecutivos
de alto nivel. El responsable debería animar a los miembros del grupo a
participar, y evitar que las personas con fuerte personalidad dominen las
sesiones.
Para conseguir todo esto, el responsable necesita tener e1 respeto de
todos los participantes de la sesión, necesita prepararse a fondo, y necesita
un conocimiento adecuado del área de la aplicación y los métodos de
desarrollo que se lutllizarán. Finalmente, el responsable necesita estar entu-
siasmado con el JAD.
Cuando el JAD falla, casi siempre es debido al responsable de la sesión
JAD (Martin, 1991). Algunas organizaciones escogen a diferentes respon-
sables para cada uno de los proyectos. El resultado es que cada proyecto
utlliza un responsable no especializado, y obtiene resultados poco satisfac-
torios. Una organización que desee utilizar JAD debería formar a uno o
más responsables JAD, y esperar que se queden en este puesto durante
dos o más años. Normalmente se necesitan unas cuatro sesiones JAD para
que un nuevo responsable se convierta en un experto.
Promotor ejecutivo. Es la persona que corre con la responsabilidad

financiera del sistema. Ésta es la persona clave para tomar la decisión de
seguir o no seguir al final de la sesión de planificación. A veces asistirán
más de un promotor ejecutivo, especialmente durante las sesiones de pla-
nificación.
Representante del usuario f¡nal. Es un representante clave del grupo

de usuarios finales, que debe tener autoridad para tomar decisiones sobre
el programa. Al igual que los otros participantes, el representante del usua-
rio final debería ser bastante comunicativo. Pueden participar más de un
representante del usuario final, aunque la sesión de diseño representará
posteriormente el foro más importante para el usuario final.
Desarrollador. La función de esta persona es ayudar a ros usuarios

finales, apartarlos de la especificación de un sistema <maravilloso) que
no sea implementable, y conocer la perspectiva del usuario final. El desa-
rrollador reahza preguntas sobre otros sistemas, viabilidad de las pres-
taciones propuestas y coste. Los desarrolladores deberán tener cuidado
para evitar decir <sí> o ((no) a cualquier idea de los usuarios. Su fun-
ción es proporcionar información, y no dar opiniones. Los desarrolla-
dores deben conocer el sistema durante las sesiones de planificación
y diseño, de forma que puedan llegar a la ejecución después de la fase de
diseño JAD. En la sesión, pueden (y a menudo deben) participar más de un
desarrollador.
secretario. El secretario es alguien del departamento de desarrollo del

software cuya responsabilidad principal es recopirar ro que sucede duran-
te la sesión. El secretario es un participante activo, que solicita aclaracio-
nes y señala las inconsistencias detectadas dia a dia.
Especialistas. Estas personas son invitadas para proporcionar cualquier

experiencia especial que sea necesaria parala sesión. El especialista es la
excepción de la regla de que todos los participantes necesitan estar pre-
sentes todo el tiempo. se puede llamar a esta persona cuando sea necesario,
porque el especialista es un recurso para el grupo JAD, y no un miembro
íntegro del grupo.
Problemas comunes
Las sesiones JAD están sujetas a varios problemas comunes:
de poi;:'-
Las sesiones JAD dan a una organi zación la oportunidad
ciarelrendimientodesustrabajadoresmásbrillantes'Losemp':'-
una sesión J-\l
dos brillantes pueden trabalar de maravilla durante
producir resultac:';
mientras qu" io* empleados mediocres pueden
mediocres. A veces vna organización escatim a alahota
de desiS-
JAD' Es esenc:'
a las personas más destacadas para participar en
puede
la participución de todas 1as personas claves' Si no
cons3-
J-\-tl
guir que una persona clave paiticipe' no lleve a cabo la sesión
iu p-UuUitiáad de éxito se reduce enotmemente' y las person¿:
hayan pe:-
cluv"s que asisten a la sesión no asimilarán bien que se
dido muchos días, en el caso de que la sesión falle'
JAD po:-
Los observadores constituyen un riesgo en las sesiones
que normalmente no logran limitar sus funciones a las
de obsei-
vadores.Siesnecesarioqueasistan,tratealosobservadorescomi
participantes, y asegúrese de que asisten a las mismas sesione'
á. pr"putu.lórrque los demás participantes y están perfectament:
preparados.
bemariados participantes pueden impedir que el equipo
JA?.:'
consolide, lo cual perjudicará el avance del grupo' El grupo. JAD
personas o menos (Mar-
completo debería 1.n"t u.t total de 8
tin, i99t;. Algunos expertos han obtenido un gran éxito con hasta
15 participantes (August, 1991), pero es difícil
que un equipo se
tiene
consolide cuando tiene más de 8 personas' Si su organización
experienciaenelusodeJAD,podríaaproximarseallímitesuperior
de 15 participantes, pero hay que hacerlo con cuidado'
Lo que sucede durante una sesión

activi-
una sesión de planificación JAD discurre habitualmente por ocho
dades principales:
c Dirigir la orientaciótn. Presentar al grupo el objetivo de la sesión.

el horario y la agenda
Definir los requerimientos de alto nivel' Esbozar el sistema' inclu-
y"íao la identificación de las necesidades del átea de aplicación
qu. int"nta resolver el sistema: objetivos del sistema: ventajas
estimadas; lista de posibles funciones del sistema; prioridad
aproxi-
madadelasfuncionesdelsistemalyconsideracionesestratégicas
y-Limitqr
futuras.
c el ambito del sistema. Establecer límites sobre 1o que pue-
deincluirelsistema.Lasdecisionessobreloqueelsistemanodebe
-.-Ga
Capítulo 24: Desarrolto conjunto de aplicaciones (JAD) 4g3
incluir son tan importantes para la verocidad de desarrollo como

las decisiones sobre lo que debe incluir.
Identificar y estimar la fase o fases de diseño JAD. Ésr- es el pri_
mer paso en la planifrcación de las siguientes actividades JAD.
Dqr a conocer a los participantes en er diseño JAD. rdentifica a las
personas que participarán en las fases de diseño JAD posteriores.
Planificar las fases de diseño JAD. Los usuarios finales, desarrolla-
dores y promotores ejecutivos se ponen de acuerdo en una planifi_
caciín para el diseño JAD.
Documentar los temas y consideraciones. Documentar los temas
tratados durante la sesión de planificación JAD, de forma que se
tenga un documento con las opciones que se examinaron y.rrrbo"r_
mento con las razones por las cuales los temas se resolvieron de la
forma elegida.
Finqlizar lq sesión.
Para cada una de estas actividades, se sigue aproximadamente el

mismo proceso. El responsable de la sesión JAD presentalatarea,como,
por ejemplo, definir los requerimientos de alto nivel. Luego los parti-
cipantes exponen sus ideas. Estas ideas se muestran para que todo el
mundo pueda verlas, en pizarras de rotuladores o en proyectores de
transparencias. Es esencial que durante este período participen todos
los miembros del equipo, ] un buen responrubr" JAD-re asegurará de
que sea así.
Unavez que se han generado y expuesto las ideas, se evalúan. Éste es
el momento en el que entran en juego los diferentes puntos de vista de los
promotores ejecutivos, usuarios finales, representantes de los desarrolla-
dores y especialistas. El responsable JAD mantiene al grupo centrado
en
el tema principal, elimina las disputas políticas, minimiza los efectos de
las personalidades fuertes y de las poco enérgicas, y redirige los temas
laterales que no se pueden resolver durante ra sesión JADI Durante la
evaluación, los participantes suelen proporcionar ideas que resuelven
las necesidades conflictivas de forma creátiva.
_ Finalmente, el grupo se compromete con todo ro que se ha decidido
durante la fase de evaluación: objetivos del sistema, prioridad aproximada
de las funciones del sistema, restricciones en el ámblto del sistema, parti-
cipantes en la fase de diseño JAD, y demás.
Generación de documentación
La generación de documentación viene tras la sesión JAD y genera un
documento JAD, el cual debe ser un reflejo lo más fidedigno
ioJiut" o" tu
información generada durante la sesión. La salida de la slesión de planifi_
cación incluye:
¡ Lista de objetivos del sistema, incluyendo consideraciones estr::.-

gicas y futuras.
o Detalles sobre las posibles funciones del sistema, incluyendo '+
propias funciones, 1as necesidades del área de aplicación que cu:-:
cada función, ventajas de cada una de las funciones, estimación .l:
1o que se obtiene por la inversión realizada en cada función' r' :'-
r
prioridad aproximada de cada función.

. Limitaciones en el ámbito del sistema, con una de las func,-*
nes que el sistema no incluirá.
o Lista de interfaces con otros sistemas.
o Lista de temas que no se hubieran podido resolver durante la s¡-
sión JAD, incluyendo el nombre del tema, la persona responsaL'-;
y la fecha de resolución prometida.
o Planificación de 1o que sucederá después, con la identificación c;
las fases de diseño JAD siguientes, participantes en el diseño JAn.
planificaciones del diseño JAD y las fechas aproximadas para 1.
implementación.
En algunos enfoques JAD, uno de los resultados de la sesión .IAD e.

una presentación para el promotor ejecutivo, que incluye toda la informa-
ción necesariapara la decisión de continuar o parar. En otros enfoques. e,
promotor ejecutivo asiste a la sesión completa de planificación JAD, y ta.
presentación no es necesaria.
Diseño JAD
El diseño JAD se centra en los requerimientos y el diseño de la interfaz
de usuario. Sus objetivos son definir los requerimientos con detalle' definir
el ámbito, diseñar los formatos de pantallas e informes, desarrollar el pro-
totipo, y recoger los requerimiento de edición, validación de datos, proce-
samiento e interfaces del sistema. También debería generar un diseño para
el esquema de la base de datos, si es necesario. El resultado de una sesión
de diseño JAD es un documento de diseño JAD, el cual se utlTrza parc
obtener la aprobación de la implementación.
Personalización
Las actividades principales durante la personalización del diseño son las
mismas correspondientes a la planificación. La preparación para la sesión
incluye el disponer de una habitación, equipo y suministros para la sesión;
preparar formularios y herramientas visuales; preparar software y perso-
nal para la documentación y el prototipado; y preparar el lugar paru \a
sesión. El responsable de la sesión también debería preparar una lista de
especificaciones posibles antes de la sesión. E,stas especificaciones deberían
tratarse como (propuestas>.
Capítulo 24: Desarrollo conjunto de aplicaciones (JAD) 4gs
Si los usuarios finales no están familiarizados con JAD, debería

prepararlos antes de asistir a la sesión JAD. Esto los familiarizará con
los objetivos de la sesión, las funciones del responsable y der secretario, lo
que espera que aporten, y algunas técnicas especiales de esquematiza-
ción que piense utilizar.
Sesión
Las partes críticas de una sesión de diseño JAD son similares a las de la
sesión de planificación: dirección por parte de un responsable JAD capaci-
tado, participación de personas claves parala toma de decisiones, uso de
un proceso estructurado y ausencia de interrupciones. La sesión de diseño
es muy visual, utilizando pizarras de rotuladores, gráficos, proyectores de
transparencias y monitores o proyectores con pantalias grandes.
Generalmente, las sesiones de diseño JAD son más largas que las
sesiones de planificación JAD, durando desde algunos días a 10 o más
días, siendo una semana la duración más habitual. Las instalaciones nece-
sarias son idénticas a las utilizadas en la planificación JAD.
Las funciones del responsable de la sesión, del representante de
desarrollo, del secretario y del especialista son similares a las desempeñadas
en la planificación. Los representantes de desarrollo están más ocupados
porque tienen que participar en las sesiones durante el día y construir
el prototipo por las tardes. E,l promotor ejecutivo no necesita estar en la
sesión JAD, pero puede pasarse de vez en cuando para responder a pregun-
tas y ofrecer ayuda. En vez de implicar a un único representante de los
usuarios finales, deberían estar presentes un grupo de usuarios finales clave,
usuarios finales que puedan dedicar tiempo suficiente para trabajar en los
detalles del producto desde el diseño JAD hasta el diseño, implementa-
ción, prueba y entrega del programa. El director del proyecto también
podría estar presente, pero no debería dirigir la sesión, ya que el respon-
sable JAD debe ser absolutamente imparcial.
Lo que sucede durante una sesión

Una sesión de diseño JAD incluye normalmente diez actividades principales:
o Dirigir lct orientación. El responsabie de la sesión presenta el obje-

tivo de la sesión, el horario y la agenda.
o Revisar y refinar los requerimientos y el ámbito de la ptanificación
JAD. Se puede utilizar el plan de la sesión que proviene de la fase de
planificación JAD como punto de partida, pero probablemente desee
refinar el plan antes de pasar al resto de la sesión de diseño JAD.
o Desarrollar un diagrama de flujo de trabajo. Crear un diagrama
que muestre cómo se hará el trabajo con el nuevo sistema software.
Desarrollar una descripción del .flujo de trabaio. Describir cor :;t"-

labras cómo se va a trabaiar con el nuevo sistema software.
Diseñar pantallas e informes. Diseño de los formatos de pant.--r;
e informes. Las sesiones de diseño JAD hacen un uso extensl t
los prototipos interactivos, los cuales son creados por desarrc--:-
dores y usuarios finales durante y entre las reuniones.
Especfficar los requerimientos de procesamienlo. Especificar --'i
volúmenes de datos, ratios, requerimientos de auditoría, requ-:--
mientos de seguridad, etc.
Definir los requerimientos de interfaz. E,specificar los sistemas c-=
necesitan interactuar con el nuevo sistema.
Identificar los grupos de datos y las funciones del sistema. Otgar-
zar los datos del sistema, incluyendo estructuras de datos princip"-
les, elementos de las estructuras de datos, y relaciones entre estru;-
turas de datos. Si el sistema está orientado a bases de datos, cre-
un esquema normalizado de la base de datos.
Documentar los temcts y consideraciones. A1 igual que con la pla-
nificación, deseará tener un registro con las opciones considerada.
y un registro con las razones por las cuales los temas se resolvieror
del modo elegido.
Finalizar la sesión.
La dinámica de grupo de las reuniones de diseño es prácticamente

la misma que en la planificación. Para cada una de las tareas, el equip,--
desarrolla un proceso de presentación de la tarea, generación de ideas.
evaluación de las ideas y compromiso con una resolución.
El diseño JAD ahorra tiempo porque las sesiones de grupo son más
eficientes que las sesiones individuales de recopilación de requerimien-
tos. Tradicionalmente, los analistas salían de las entrevistas con los usua-
rios finales con conocimientos incompletos sobre los requerimientos de-
seados. Más tarde intentaban estimar lo que el usuario final quería o decía.
Durante una sesión JAD, los usuarios finales hablan con los analistas 1-
entre sí, y comentan 1o que desean. El grupo centra su conocimiento com-
binado del área de aplicación, el problema a resolver, las limitaciones 1'
posibilidades técnicas, las consideraciones estratégicas, los casos excep-
cionales y las áreas especialmente difíciles.
REFERENCIA La presión temporal de una sesión de diseño JAD ayuda al grupo a
CRUZADA
Para obtener más
centrarse en la tarea principal y a buscar consenso. La presión temporal
información sobre los anima a los participantes a trabajar duro y a cooperar.
efectos beneficiosos
que puede tener la
presión temporal,
Generación de documentación
" Desarrollo en ventanas La documentación JAD sustituye a una especificación de requerimientos
temPorales..
tradicional, de forma que es importante documentar cuidadosamente la
I
sesión de diseño. A continuación se muestran las actividades de genera-

ción de documentación posteriores a una sesión de diseño:
Completar el documento de diseño JAD. que de nuevo debería re-

flejar del modo más fidedigno posible 1a información generada du-
rante la sesión.
Completar el prototipo basándose en la dirección establecida du-
rante la sesión. En algunos casos sería posible compietar el prototi-
po durante la propia sesión de diseño.
Todos los participantes deben revisar el documento de diseño y el
prototipo.
Presentar los resultados al promotor ejecutivo, incluyendo un resu-
men de la sesión de diseño, el diseño JAD, las fechas de imple-
mentación preliminares, y el estado actual del proyecto.
Es importante pasar rápidamente del diseño JAD al diseño funcional

y implementación. Si un proyecto tiene que esperar varios meses para
a la
su aprobación después del diseño JAD, los requerimientos pueden empe-
zar a quedar obsoletos, puede perder los participantes claves y perderá el
apoyo del usuario final.
24.2. Gestión de los r¡esgos del JAD

El JAD es un proceso sofisticado, que debe realizarse bien para que funcio-
ne. A continuación se muestran los problemas principales que puede causar.
REFERENCIA Previsiones poco real¡stas a consecuenc¡a de la sesión JAD. La

CRUZADA
Para obtener más
sesión JAD puede generar tanta excitación que posiblemente el desarro-
información sobre los llo no pueda satisfacer la demanda para el nuevo sistema lo suficiente-
problemas causados
por un progreso rápido
mente rápido. Los participantes en la sesión ven la rapidez con que los
inusual en la fase desarrolladores pueden crear un prototipo, y no siempre comprenden por
inicial de un proyecto, qué lleva mucho más tiempo crear el sistema real. El ímpetu generado
consulte " Expectativas
poco realistas de durante las sesiones puede volverse contra los desarrolladores si no entre-
presupuesto y gan el sistema real lo suficientemente rápido.
planificación., en la
Sección 21.2. Este riesgo se puede mitigar de dos formas. En primer lugar, debería
emplearse parte de la sesión del diseño JAD en establecer expectativas
REFERENCIA
CRUZADA
realistas sobre el tiempo que el equipo de desarrollo va a tardar en la crea-
Para obtener más ción del nuevo sistema. El grupo completo debería comprometerse a una
información sobre el planificación de desarrollo al final de la sesión de diseño.
eslablecimiento de
expectativas realistas, En segundo lugar, debería escoger un método de desarrollo incremental
véase la Sección 10.3, para su uso combinado con JAD. Esto permite obtener signos de progreso re-
"Gestión de las lativamente rápidos después de la sesión de diseño JAD, así como la apa-
expectativas del
clienle". rición de otras ventajas propias de los métodos de desanollo incremental.
===E,qENCtA Estimaciones prematuras e incorrectas del trabajo restante tras

CRUZADA
ra'a 33iener más las sesiones JAD. En el proceso JAD estándar, la planificación J\D
:::a :s sobre cómo genera una fecha objetivo parafinalizar la implementación, y la estimacior-
:acer y refinar las no se revisa como parte de la fase de diseño JAD. Esto crea una estima-
as: -aciones, consulte
el Capítulo 8, ción demasiado pronto en el ciclo de desarroilo, y aumenta el riesgo de
" Es'timación". previsiones poco realistas. conocerá mucho mejor el sistema después de,
diseño JAD que después de la planificación JAD. Los participantes JAD
desearán probablemente una estimación después de ra fase dé planifica-
ción, de forma que hay que hacer una estimación aproximada después de
la planificación y una más refinada después del diseño. He moáificado
las salidas de la fase JAD estándar en este capítulo parautilizar este enfo-
que de dos estimaciones en vez de la estándar.
24.3, Efectos secundarios del JAD

Además de su impacto en la velocidad de desarrollo, el JAD tiene mu-
chos efectos secundarios, todos ellos positivos:
Da como resultado una interfaz de usuario de mayor calidad, des-

de el punto de vista del usuario final. Los prototipos hacen tangible
el diseño del software, y los participantes pueden colaborar mejor
con un prototipo ejecutable que con una fría especificación en papel.
El usuario final se siente más satisfecho debido a su participación
en el diseño del software.
Por la misma razón, genera sistemas con mayor valor en el campo
de aplicación.
Ayuda a incrementar el conocimiento de los desarrolradores sobre
las necesidades prácticas del área y los intereses de los ejecutivos y
usuarios finales.
suprime las barreras de la organización y reduce los efectos de las
políticas. cuando la misión está clara, la dinámica de grupo sacará
alaluz durante la sesión JAD previsiones ocurtas, necesidides con-
trarias, y políticas que en otro caso podrían estropear un proyecto o
dar como resultado un producto poco satisfactorio.
Evita que los desarrolladores queden atrapados en medio de con-
flictos políticos entre diferentes departamentos y usuarios finales.
Ayuda a formar a los usuarios finales sobre el desarrollo del soft-
ware a través de su participación en sesiones JAD.
24.4. lnteracciones del JAD con otros métodos

El JAD debe combinarse con un modelo de ciclo de vida incremental, tal
como entrega evolutiva, prototipado evolutivo o entrega por etapas (capí-
--l
REFERENCIA tulos 7, 20,21 y 36), que entrega parte del software relativamente pronto
CRUZADA
después de la sesión de diseño JAD.
Para obtener más
información sobre los JAD y prototipado (capítulos 21. 38 v 42) parecen ser métodos sinér-
métodos de desarrollo gicos, y la combinación puede reducir 1os cambios de requerimientos por
incremental, véase
el Capítulo 7, debajo de un 5 por 100 (Jones, 1994).
"Planificación del Si el entorno técnico lo admite, realice el trabajo de prototipado y di-
ciclo de vida".
seño durante la sesión de diseño JAD de tal forma que pueda transferirlo
-*---=[E+ a la fase de implementación. Esto es mucho más fácil en el desarrollo de
lÚtll
ll¡#iT
IHttf
SI que en otros tipos de desarrollo. JAD es una parte rntegral de la meto-
r'iil t44 Gif:\ dología RAD de James Martin, y algunas organizaciones integran JAD
DATOS REALES dentro del ciclo de vida RAD apoyado por herramientas ICASE. Si tiene
sentido hacer eso dentro de su entorno, planifique esa integración durante
la personalización de 1a planificación JAD.
24.5, Puntos cruc¡ales del JAD

La eficacia de JAD varía. Inicialmente, compañías tales como Amertcan
Airlines, Texas Instruments e IBM informaron que JAD reducía el tiempo
para hacer la especificación de los requerimientos de un l5 a un 35 por 100
DATOS REALES
(Rush, 1985). CNA Insurance Company informó que reducía el esfuerzo
dedicado a los requerimientos casi en un 70 por 100. Más recientemente,
Judy August informó que ei JAD reducía e1 tiempo transcurrido en la espe-
cificación de requerimientos de un 20 a un 60 por 100 comparado con los
métodos tradicionales, y reduce simultáneamente el esfuerzo total de un
20 aun 60 por 100 (August, l99l).
La recopilación de requerimientos lleva entre un 10 y un 30 por 100 del
tiempo transcurrido en un proyecto típico, dependiendo del tamaño y de la
complejidad del mismo (Boehm, 1981). Si supone que su proyecto va a con-
sumir más bien un 30 en vez del 10 por 100 de1 tiempo sin JAD, puede
esperar que el ahomo de los requerimientos obtenidos al usar JAD se traduz-
ca en una reducción del 5 al 15 por 100 del tiempo de desarrollo total. Para
estar seguro, planee alcanzar reducciones en la parte inferior del rango du-
rante su uso inicial del JAD. Conforme aumente su experiencia con JAD,
podrá adaptar su eficiencia especialmente dentro de la propia organización,
y usar su propia experiencia para estimar proyectos futuros.
24.6. Claves para el éxito en el uso del JAD

A continuación se citan algunas claves para tener éxito en el uso del JAD:
o Escoger un responsable con experiencia para dirigir las sesiones

JAD.
25
Selección del modelo
de ciclo de vida
Un ciclo de vida del software es un modelo que describe todas las ac-
tividades que conlleva la creación de un producto software. Los estilos de ffi
desarrollo del producto varían tremendamente entre las diferentes cla- ffi
ses de proyectos, necesitando diferentes clases de tareas y distintos
órdenes Oé las mismas. La elección de un modelo de ciclo de vida ffi
erróneo puede dar lugar a la omisión de tareas y a una secuenciación
inapropiada de las mismas, lo cual va en contra de la planificación y
ffi
eficiencia del proyecto. La elección de un modelo de ciclo de vida apro- ffi
piado tiene el efecto contrario, asegurando que todo el esfuerzo se
utiliza eficientemente. Todo proyecto utiliza un ciclo de vida de un tipo
u otro (explícita o implícitamente) y este método asegura que la elección
W
ffi
se hace explícitamente y que maximiza las posibles ventajas.
Eficacia
Riesgos principales
. La selección de un ciclo de vida no contiene en sí misma ningún ries-
go. Los modelos de ciclo de vida específicos pueden contener riesgos
adicionales.
Ninguno.
La tabla resume sólo el efecto de la elección explícita de un modelo de ciclo

de vida. Además de esos efectos, el modelo especíJico escogido de ciclo de
vida tqmbién tiene mayor o menor posibilidad de reducir la planificación,
mejorar tavisibílidad del progreso y afectar al nivel de riesgo. Para obte-
ner más información sobre la selección del modelo de ciclo de vida, con-
sulte el Capítulo 7, <PlaniJicación del ciclo de vida>.
501
26
Medidas
Las medidas son un método que ofrece beneficios sobre la motivación

a corto plazo y beneficios a largo plazo sobre el coste, la calidad y la
ffiffi
planificación. Las medidas ofrecen un antídolo frente a los problemas ffiffi
habituales de malas estimaciones, mala planificación y mala visibilidad
del progreso. Las empresas que llevan a cabo programas activos de ffi
medidas tienden a dominar sus campos de acción. Prácticamente ffiffi
cualquier organización o proyecto puede beneficiarse de Ia aplicación
de medidas en algún nivel. Para tener más efecto, las medidas deben
ffi
estar respaldadas por la directiva superior, y pueden ser llevadas a ffiFffiffi
cabo con un grupo permanente de medidas. Las medidas también pue-
den implementarse a escala inferior en proyectos individuales, por Sry
parte del equipo del proyecto o de miembros particulares del equipo.
ilitiiltt!:,í; Ef icacia
Reducción potencial de la planificación nominal: Muy buena
¿*ll¡i:*i$ Riesgos prihcipales

r Sobreoptimización de las medidas de un solo factor.
. Mal uso dé las medidas para evaluación de los empleados.
. lnformacióh equívoca de las medidas de líneas de código.
#uti.iliiii lnteraccione$ y equilibrios principales

¡ Sienta las bhses para obtener mejoras en la estimación, planificación,
evaluación de herramientas para productividad y evaluación de
métodos de programación.
503
Los productos y proyectos software pueden medirse de docenas i: lur-

mas distintas: tamaño en líneas de código o puntos de función: d¡l-¡muni
por miles de líneas de código o puntos de función; horas empleada-< :n C
diseño, codificación y depuración; satisfacción de los desarrolladores :m¡n
es sólo la punta del iceberg).
Los programas de medidas ofrecen soporte para eI desarrollo ráp:a:
de varias formas.
Las medidas ofrecen visibilidad del estado. La única cosa peor qur
irretrasado es no saber que se va con retraso. La medida del progreso
puede ayudarle a saber exactamente en qué punto se encuentra.
REFERENCIA Las medidas centran las actividades de las personas. Como ya

CRUZADA
Para más informac¡ón
he dicho en algún sitio, las personas responden a los objetivos que define
sobre la rmportancia de para ellas. Cuando mide una característica de su proceso de desarrollo r'
los ob.ietivos, véase la transmite a las personas implicadas, les está diciendo implícitamente
"Definición de
objetivos., en la que deben frabajar para mejorar su rendimiento respecto a esa caracterís-
Sección 11,2. tica. Si mide el número de errores del programa y lo transmite, reducirán
el número de errores. Si mide el porcenta.je de módulos marcados como
terminados, implementarán el porcentaje de módulos marcados como ter-
minados. Aquello que se mide resulta optimizado. Si mide las caracterís-
ticas del proyecto relacionadas con la velocidad de desarrollo, éstas serán
optimizadas.
Las medidas mejoran la moral. Bien implementado, un programa de

medidas puede mejorar la moral del desarrollador, llevando la atención a
problemas crónicos, tales como una excesiva presión de planificación, un
entorno de trabajo inadecuado y unos recursos informáticos inadecuados.
REFERENCIA Las medidas pueden ayudar a definir expectat¡vas real¡stas. Si

CRUZADA
tiene medidas que soporten su actitud, estará en una posición mucho más
sobre la definición de fuerte para realizar y defender estimaciones de la planificación. cuando
expectativas, consulte
su cliente le pida que trabaje para cumplir un plazo imposible, puede de-
la Secc¡ón 10.3,
"Gestión de las
cirle algo como esto: <Voy a trabajar duro para entregar el sistema en el
expectativas del plazo que desea, pero según el historial de trabajos y basándome en las
cliente".
cifras que acabo de describirle, tardaremos más de lo que nos ha impues-
to. Podríamos definir un nuevo récord con este proyecto, pero le reco-
miendo que modifique sus planes para adaptarlos a nuestro historial> (Rif-
kin y Cox, 1991).
Las medidas sientan las bases para la meiora del proceso a largo
plazo. El beneficio más significativo de las medidas no puede verse a
corto plazo en un solo proyecto, sino que se verá a 1o largo de 2 o 3 años.
Si mide su proyecto de forma consistente, sentará las bases para comparar
-FtI---
Capítulo 26: Medidas 505
proyectos y analizar los métodos que funcionan y los que no. Un programa
de medidas le ayuda a evitar perder tiempo con método, qn" no ,on
rentables. Le ayuda a identificar las metodologías presentadas como pana-
ceas que no están cumpliendo las expectativas prometidas. Le ayuda a acu-
mular una experiencia que soportaná una estimación miás precisa de proyec-
tos y una planificación más significativa. I¿s medidas son la piedra angular
de cualquier programa de mejora del proceso a largo plazo.
26.1. Uso de medidas

Hay varias claves para usar las medidas de forma efectiva.
Objetivos, preguntas, métr¡cas

Algunas organizaciones desperdician tiempo y dinero midiendo más cosas
de las que necesitan. un buen método para evitar este problema consiste
en asegurarse de que está recogiendo los datos por algún motivo. La técnica
de objetivos, preguntas, métricas, puede ayudarle (Basili y Weiss, l9g4):
Definir objetivos. Determine cómo desea mejorar sus proyectos y

productos. Por ejemplo, su objetivo podría ser reducir el número
de defectos iniciales incorporados en el software, para no pasar
mucho tiempo depurando y corrigiendo el software más adelante.
Hacer preguntas. Deter-rnine las preguntas que necesita hacer para
cumplir sus objetivos. Una pregunta podría ser: <¿eué tipos de de-
fectos nos están resultando más costosos de corregir?>>
Establecer métricas. Defina métricas (medidas) que respondan a
sus preguntas. Podría comenzar recogiendo datos sobre tipos de
defectos, tiempos de creación, tiempos de detección, coste de detec-
ción y coste de corrección.
un informe de recogida de datos del Laboratorio de Ingeniería del

Software de la NASA saca como conclusión que la lección más importan-
te aprendida durante 15 años era que es necesario definir objetivos de
medida antes de medir (Valett y McGarry, 1989).
Grupo de medidas
Algunas organizaciones definen un grupo separado de medidas, y general-
mente esto es una buena idea, porque las medidas efectivas requieren un
conjunto especializado de habilidades. El grupo puede constar de desa-
rrolladores típicos. pero el grupo de medidas ideal debe tener conocimientos
sobre las siguientes áreas (Jones, 1991):
i
h
i
a Estadística y análisis multivariante.

a Literatura de ingeniería del software.
a Literatura de gestión de proyectos software.
a Planificación de software y métodos de estimación.
a Herramientas para planificación y estimación del software.
a Diseño de formularios de recogida de datos.
a Diseño de informes.
a Métodos de control de calidad, incluyendo revisiones.
a Reuniones, inspecciones y todos los tipos estándar de comprobacit-,-
a Pros y contras de las métricas específicas del software.
a Principios de contabilidad.
Este es el conjunto de habilidades que poseen los grupos de media'.

con experiencia de ATT, DuPont, Hewlett Packard e IBM.
No necesita tener un grupo de medida a nivel de la empresa dedicac:
a tiempo completo para medir aspectos de proyectos específicos. El res-
ponsable del equipo o un miembro individual del mismo puede introduc--:
medidas específicas a nivel de proyecto para sacar partido de los benei-
cios de motivación a corto plazo de las medidas.
Aspectos a med¡r
Cada organización necesita decidir lo que va a medir basándose en su5
propias prioridades (sus propios objetivos y preguntas). Pero, como min:-
mo, la mayoría de organizaciones desearán guardar datos históricos sobre
tamaños de proyecto, planificaciones, requerimientos a nivel de recursos \
características de calidad. La Tabla 26.1 lista algunos de los elemenro:
de datos recogidos por diferentes organizaciones.
Unavez que haya comenzado a recoger incluso unos pocos elementos de
datos, puede obtener conclusiones de los datos recogidos, y también puede
combinar elementos de datos para obtener otras conclusiones. Aquí tiene
algunos ejemplos de combinación de elementos de datos que puede crear:
Número de defectos pendientes frente a defectos totales detectados

(para ayudar a predecir las fechas de entrega del proyecto).
Número de defectos detectados por inspección frente a defectos
detectados por prueba de ejecución (para ayudar a la planificación
de actividades de control de calidad).
Historial de los días pendientes estimados y reales restantes en el
proyecto, en forma de porcentaj e (pan ayudar al seguimiento 1-
mejorar la precisión de las estimaciones).
Promedio de líneas de código por mes de trabajo, dividido por
guajes de programación (para ayudar a estimar y planificar las
tividades de programación).
l- ----
Tabla 26.1. Ejemplos de tipos de datos a medir
Datos de coste y recursos

Esfuerzo por actividad, fase y tipo de personal (véase tambiénraTabla26.2).
Recursos informáticos.
Tiempo transcurrido.
Datos sobre cambios y defectos

Defectos por clasificación (severidad, subsistema, tiempo de inserción, fuente del
error, resolución).
Estado de informe de problemas.
Método de detección de defectos (revisión, inspección, prueba, etc.).
Esfuerzo para detectar y corregir cada defecto.
Datos del proceso

Definición del proceso (método de diseño, lenguaje de programación, método de
revisión, etc.).
Adecuación del proceso (se revisa el código cuando se supone que se debe, etc.).
Tiempo esperado para terminar.
Progreso de los hitos.
Crecimiento del código a lo largo del tiempo.
Cambios en el código a lo largo del tiempo.
Cambios en los requerimientos a 1o largo del tiempo.
Datos del producto

Fechas de desarrollo.
Esfuerzo total.
Tipos de proyecto (gestión, <prét-d-porteo, sistemas, etc.).
Funciones u objetos incluidos en el proyecto.
Tamaño en líneas de código y puntos de función.
Tamaño de los documentos producidos.
Lenguaje de programación.
o Media de puntos de función por mes de trabajo, dividido por len-

guajes de programación (para ayudar a la estimación y planifica-
ción de actividades de programación).
Porcentaje de defectos suprimidos antes de la entrega del producto
(para ayudar al control de calidad del producto).
Tiempo medio para corregir un defecto, por severidad, por subsis-
tema y por momento de inserción del defecto (para ayudar a pl::--

ficar las actividades de corrección de defectos).
¡ Promedio de horas por página de documentación (para ayuda: :
planificar las actividades de documentación de un proyecto).
En la mayoría de proyectos no se recogen los datos en bruto que F.:-

mitirán crear esta información, pero como puede ver, esta informacr¡'-
sólo requiere la recogida de unas pocas medidas.
Granularidad
Uno de los problemas relacionados con los datos recogidos por la may or:.
de organizaciones consiste en que los recogen con una granularidad dem¿-
siado grande como para que resulten útiles. Por ejemplo, una organizaciLa:
podría acumular datos sobre el número total de horas empieadas en el prc"-
yecto FooBar, pero no distinguir entre el tiempo empleado en la especifica-
ERROR CLASICO ción, el prototipado, la arquitectura, el diseño, la implementación y demás
Estos datos globales podrían resultar útiles a nivel de auditoría, pero no son
útiles para alguien que desee analizar datos de planificación y estimación. c
datos que sean utilizados para mejorar el proceso de desarrollo del software.
La Tabla 26.2|istaun conjunto de categorías y actividades para control
de tiempo que ofrecerán la granularidad necesaiapara la mayoría de los
proyectos.
Tabla 26.2. Ejemplo de actividades para control de tiempo
Categoría Actividad
BIBLIOGRAFIA
ADICIONAL Gestión Planificación.
Para ver otra Iista
Gestionar las relaciones con el cliente o
de actividades que
puede usar como usuario final.
base para el control
Gestión de los desarrolladores.
de tiempo, consulte la
Tabla 1.1 de Applied Gestión del control de calidad.
Software Measurement
(Jones, 1 991 ). Gestión de los cambios.
Administración Tiempo de preparación.
Preparación del laboratorio de desarrollo.
Desarrollo del proceso Creación del proceso de desarrollo.
Revisión o inspección del proceso de
desarrol I o.
Repetición/corrección del proceso de
desarrollo.
Formación de 1os clientes o miembros del
equipo sobre el proceso de desarrollo.
(continual
Tabla 26.2. (Continuación)
EspeciJícación de requerimientos Creación de la especificación.
Revisión o inspección de la especificación.
Repetición/corrección de la especifi cación.
Informe de defectos detectados durante la
especificación.
Prototipado Creación de prototipos.
Revisión o inspección de prototipos.
Repetición/corrección de prototipos.
Informe de defectos detectados durante el
prototipado.
Arquitectura Creación de la arquitectura.
Revisión o inspección de la arquitectura.
RepeticiórVcorrección de la arquitectura.
arquitectura:
Diseño Creación del diseño.
Revisión o inspección del diseño.
Repetición/corrección del diseño.
Informe de los defectos detectados durante
el diseño.
Implementación Creación de la implementación.
Revisión o inspección de la
implementación.
Repetición/corrección de la
implementación.
implementación.
Adquisición de componentes Investigación o adquisición de componentes,
bien comerciales o de la casa.
Gestión de la adquisición de componentes.
Comprobación de los componentes
adquiridos.
Mantenimiento de componentes
adquiridos.
Informe de defectos sobre componentes
adquiridos.
(continúa)
Tabla 26.2. (Contínuación)
Integración Crear y mantener el programa (buila.

Probar el producto.
Distribuir e1 producto.
Prueba del sistema Planificación de la prueba del sistem¿-
Creación del manual parala prueba del
sistema.
Creación de la prueba automática de1
sistema.
Ejecución de la prueba manual del sistem¿
Ejecución de la prueba automática del
sistema.
Informe de defectos detectados durante 1¿
'I
prueba del sistema.
Entrega del producto Preparación y soporte de entregas
I intermedias.
Preparación y sopofte de la versión alfa.
Preparación y soporte de la versión beta-
Preparación y soporte de la versión final-
Métricas Recoger datos medidos.
Aralizar datos medidos.
Uso de los datos recog¡dos

La recogida de los datos no reporta ninguna ventaja si no los usa. Las si-
guientes secciones explican 1o que hay que hacer con los datos recogidos-
Análisis Pareto
REFERENCIA
CRUZADA
Si le importa la velocidad de desarrollo, una de las cosas más potenre>
Para ver detalles sobre que puede hacer con los datos recogidos es realizar un análisis Parer".
la distribución del (buscar el 20 por 100 de las actividades que consumen el 80 por 100 de-
tiempo empleado en
los proyectos en tiempo). La optimización de un proyecto software para una mayor veloci-
general, consulte la dad es similar a la optimización de un programa software para obtenei
Sección 6.5,
velocidad. Mida dónde emplea su tiempo, y entonces busque métodos para
"Distribución del
tiempo empleado". hacer más eficientes las áreas que consumen más tiempo.
il
I
I
i
L__
'!
Análisis frente a medida

En el extremo opuesto de la escala correspondiente a las organizaciones
que recogen datos demasiado globales, hay organizaciones que están tan
motivadas sobre las medidas del software que recogen datos sobre prácti-
rnnoR clÁslco camente todo. Realmente, recoger demasiados datós no es mejor que re-
coger demasiado pocos. Es fácil verse abrumados por datos que son tan
poco fiables que no hay forma de saber 1o que significan. para ser signifi-
cativas, las métricas necesitan estar definidas y estandarrzadas, para po-
der hacer comparaciones entre proyectos.
El Laboratorio de Ingeniería del Software de la NASA (sEL) ha teni-
do en marcha un programa activo de medidas durante casi 20 años. una
DATOS REALES
de las lecciones aprendidas por el SEL consiste en emplear más esfuerzo
en el análisis y menos en la recogida de datos. En 1os primeros años del
programa, el SEL empleó prácticamente ei doble de esfuerzo en la re-
cogida de datos que en su análisis. Desde entonces, el esfuerzo de 1a reco-
gida de datos se disminuyó a la mitad, y el SEL emplea ahora alrededor
de tres veces más en el análisis y preparación de datos que en su recogida
(NASA, 1994).
una vez analizados los datos, el SEL ha visto también que recopiiar
las lecciones aprendidas es clave para que la recogida y análisis de datos
resulten útiles. Puede recopilar los datos y los análisis en cualquiera de
las siguientes formas:
o Ecuaciones, tales como la cantidad de esfuerzo o recursos informá-

ticos necesarios generalmente para desarrollar un programa de un
tamaño determinado.
o Gráficos de sectores, como las distribuciones de errores por seve-
ridad.
¡ Gráficos que definan rangos de situaciones normales, como el in-
cremento en líneas de código comprobadas en el control de versio-
nes a 1o largo del tiempo.
o Tablas, como por ejemplo el tiempo esperado de entrega en fun_
ción de distintos números de defectos pendientes.
o Procesos definidos, como la inspección de código o la ir,-:ura de
código.
¡ Axiomas básicos, tales como <la lectura de código encti¿ntra más
defectos de interfaz que la prueba de ejecución>.
o Herramientas software que recopilen algunas o todas las cuestio-
nes anteriores.
si acaba de comenzar un programa de medidas, use un conjunto simple

de medidas, tales como el número de defectos, er esfuerzo, el coste y 1as
líneas de código (los datos de control de tiempo descritos enlaTabla 26.2
configurarían una única medida del <esfuerzo>). Estandarice las medidas
a lo largo de sus proyectos, y ruego refínelas e increméntelas

a medr - "
que adquiera más experiencia (pietrasanta, 1990; Rifkin
y Cox, 1991t"
Las organizaciones que empiezan a recoger daros der sortware
sue.;:
tender a recoger alrededor de una docena de medidas
distintas. lnciu..¡
las organizaciones que tienen una gran experiencia con programas
DATOS REALES
medidas siguen tendiendo a recoger sólo arrededor de dos
i;
¿ár.iu, de rn:-
didas (Brodman y Johnson, l9g5).
Realimentación
unavez que haya definido un programa de medidas, es importante comu-
nicar a los desarrolladores y directivos los resultados de las medidas
ofrecer realimentación a ros desarroiladores suere ser argo poco
DATOS REALES usual e:
una organización; las organizaciones tienden a remitir losáatos
a los direc-
tivos, pero suelen ignorar a los desarrolladores. En un estudi o,
er 37 por 10r.i
de los responsables pensaban que se daba realimentación
sobre los datos
medidos, y en cambio sóro un r 1 por 100 de ros desarroiladores pensaban
1o mismo (Hall y Fenton, 1994).
Los desarrolladores tienden a ser suspicaces respecto al uso de
1os
datos medidos. Tanto los responsables como los desárroiladores
piensan
que los directivos manipulan los datos obtenidos al
menos una de cada
tres veces (Hall y Fenton, rgg4). cuando ros desarrolladores
no pueden
ver 1o que se hace con los datos, pierden conftanza en el programa
de
medidas. un programa de métricas mar implementado pueáe
p"er¡udicar
realmente la moral del desar¡ollador.
cuando una organización ofrece realimentación sobre los datos
-., me_
didos, los desarrolladores están entusiasmados con er programa
de medi-
DATOS REALES das. Al tener realimentación, éstos opinan que el progiu*i
de medidas es
<Bastante útil) o <Muy útil> aproximadamente en un
90 por r00 de ras
ocasiones. cuando una organización no ofrece rearimentación,
éstos opi-
nan que el programa de medidas es <Bastante útil> o
ntrtuy útii> só10
alrededor de un 60 por 100 de las ocasiones (Hali y Fenton,
iOO+¡.
. otro método para incrementar el entusiasmo de los desarroliadores
con_
siste en solicitarles que participen en el diseño de ros
formularios de recogi-
da de datos. Si 1o hace, los datos que recogerá serán
mejores, y su invitación
mejorará la posibilidad de su .o*pto-iro (Basili y McGairy, r995).
lnforme de estado
un tipo especial de realimentación ofrecido por ras organizaciones
que
usan medidas es un informe anuar de estado
del softwaie. El informe ie
estado es similar al informe anual financiero, pero
describe er estado de r¿
capacidad de desarrollo de software de ra organización.
Incluye resúme-
nes de los proyectos ejecutados durante el año; puntos
fuertes y débile.
Capítuto 26: Medidas 513
en las áreas de personal, proceso, producto y tecnología; niveles de la

plantilla; planificaciones; niveles de productividad y niveles de calidad.
Describe las percepciones de la otganización de desarrollo de software
por parte de personal ajeno al software y la percepción de la propia orga-
nizición de desarrollo. También incluye una descripción del inventario
de software existente en la organización'
El informe de estado se desarrolla en base a datos históricos, informes,
mesas redondas y entrevistas. No es una evaluación; no le va a indicar si
su capacidad de desarrollo de software es buena o mala' Es puramente
descriptivo. Como tal, ofrece una base crítica para comparar su estado
año a año, y para mejoras futuras'
Limitaciones
¿Dónde está la Las medidas resultan útiles, pero no son una panacea' Tenga presentes
esperanza que estas limitaciones.
hemos perdido en el
conocímiento? Exceso de Confianza en las estadíst¡cas. Uno de los errores inicia-
¿.Dónde está el
conocimiento que les cometidos por el Laboratorio de Ingeniería del Software de la NASA
hemos perdido en la (SEL) era suponef que obtendrían el máximo de información mediante el
información? análisis estadístico de los datos recogidos. Conforme el programa de me-
T. S. Eliol didas del SEL iba madurando, descubrieron que obtenían alguna infor-
mación de las estadísticas, pero que obtenían más todavía hablando de las
estadísticas con las personas implicadas (Basili y McGarry, 1995).
Precisión de los datos. El hecho de que mida algo no indica que la

medida sea precisa. Las medidas de ios procesos de software pueden
contener muchos errores. Como fuentes de errores tenemos las horas extras
DATOS REALES
no pagadas y no registradas, apuntar el tiempo a un proyecto incorrecto, no
registiar el esfuerzo del usuario, no registrar el esfuerzo de la directiva,
no registrar el esfuerzo realizado por especialistas en los proyectos, de-
fectos no informados, esfuerzo no registrado empleado antes de activar el
sistema de seguimiento del proyecto, e inclusión de tareas no relativas
al proyecto. Capers Jones informa que la mayoría de sistemas de segui-
miinto de las empresas tienden a omitir del 30 al 70 por 100 del esfuerzo
real implicado en un proyecto software (Jones, 1991). Tenga presentes
estas fuentes de error cuando diseñe su programa de medidas'
26.2. Gestión de los r¡esgos de las medidas

En general, las medidas son un método efectivo patalareducción de ries-
gos. Cuanto más mida, menos sitios tendrán los riesgos pala ocultarse'
Sin embargo, las medidas tienen sus propios riesgos. Aquí tenemos algu-
nos problemas específicos a controlar.
sobreoptimización de medidas de un único factor. Aquetri., ;r,c

mide se optimiza, y esto implica que necesita tener cuidado a1 del:-:: rl
que va a medir. Si sólo mide el número de líneas de código produc:la=.
algunos desarrolladores cambiarán su estilo de codificación para gene:::
más líneas. Algunos olvidarán compretamente la calidad del código, se
I
centrarán solamente en la cantidad. Si sólo mide defectos, puede encon-
trarse con que la velocidad de desarrollo baja drásticamente.
Es peligroso intentar usar demasiadas medidas cuando se está preparan-
do un nuevo programa de medidas, pero también es arriesgado no medir
suficientes características claves del proyecto. Asegúresede configu.ar
suficientes medidas distintas para que el equipo no sé centre en optimizar
solamente una de ellas.
Mal uso de las medidas para evaluar a los empleados. Lasmedidas

pueden ser una carga de profundidad. Muchas personas han tenido malas
ex-
periencias con las medidas en tests de inteligencia, enseñanzas medias.
evaluaciones de rendimiento del trabajo y demás. un error tentador a come-
ter con un programa de medidas del software es usarlo para evaluar a per-
ERROR CLASICO sonas específicas. Tener éxito en un programa de medidas depende de la
implicación de las personas cuyo trabajo está siendo medido, y es importante
que un programa de medidas controle proyectos, y no personas específicas.
_ Perry, Staudenmayer y votta diseñaron un proyecto de investigación

de software para ilustrar el uso de ros datos medidos. Introdujeron todos
los datos bajo códigos de identificación conocidos sólo por elios. Dieron
a cada persona implicada en el programa de medida una <<carta de dere-
chos>>, incluyendo el derecho a interrumpir temporalmente las
medidas en
cualquier momento, a borrarse completamente del programa de medidas,
a examinar los datos medidos y a pedir al grupo de medidas que no se
registrara algo. Informaron que ninguna de lai personas objeto de esta
investigación ejerció estos derechos, pero r. ,.nfíun más a gusto sabien-
do que disponían de ellos (perry, Staudenmayer y Votta, iIlbq.
Información equívoca de medidas de ríneas de código. La mayo-

ría de programas de medidas medirán el tamaño del códi[o en líneas
de
código, y estas medidas presentan argunas anomalías. É.á, ,on algunas
BIBLIOGRAFIA
ADICIONAL
de ellas;
Para una excelente
discusión sobre los
problemas con las
o Las medidas de productividad basadas en ríneas de código pueden
medidas de líneas hacer parecer a los lenguajes de arto nivel menos producivos de lo
de código, véase que son. Los lenguajes de alto nivel implementan más funcionalidad
Programming
Productiv¡ty por línea de código que los renguajes de bajo niver. un desarrolra-
(Jones, 1986a). dor podría escribir menos líneas de código al mes en un renguaje
de alto nivel, y seguir haciendo más trabajo del realizado con
más
líneas de código en un lenguaje de bajo nivel.
o Las medidas de calidad basadas en líneas de código pueden hacer

que los lenguajes de alto nivel parezcan causar una menor calidad
de la que ofrecen. Suponga que tiene dos aplicaciones equivalentes
con el mismo número de defectos, una escrita en un lenguaje de
alto nivei y otra en un lenguaje de bajo nivel. Para el usuario final,
las aplicaciones parecen tener exactamente los mismos niveles de
calidad. Pero la escrita en el lenguaje de bajo nivel tendrá menos
defectos por línea de código, simplemente porque el lenguaje de
bajo nivel necesita más código para implementar la misma funcio-
nalidad. El hecho de que una aplicación tenga menos defectos por
línea de código crea una impresión errónea sobre los niveles de
calidad de las aplicaciones.
Para evitar estos problemas, tenga cuidado con las anomalías al com-
parar métricas entre diferentes lenguajes de programación. Hay formas
más rápidas y hábiles de hacer las cosas que pueden producir menos códi-
go. Considere también el uso de puntos de función para algunas medidas.
Esto ofrece un lenguaje universal que se adapta mejor a algunos tipos de
medidas de productividad y calidad.
26.3. Efectos secundarios de las medidas

El principal efecto secundario de un programa de medidas consiste en
que aquello que se mide se optimiza. Dependiendo de lo que se mida,
podría optimizar la tasa de defectos, la facilidad de uso, la eficiencia de la
ejecución, la planificación, o cualquier otro factor.
26.4. lnteracciones de las medidas con otros métodos

Un programa de medidas ofrece las bases para mejoras en áreas tales como
la estimación (Capítulo 8), 1a planificación (Capítulo 9) y la evaluación de
herramientas para productividad (Capítulo 15). Aunque es posible diseñar
un programa de medidas que cause problemas en un proyecto de desarro-
11o rápido, no existe ninguna razon para que un programa de medidas bien
diseñado interaccione de forma negativa con cualquier otro método.
26.5. Puntos cruciales de las medidas

Se dispone de datos que avalan la eficacia natural de los programas de
medidas. El gurú de las métricas, Capers Jones, informa que las organiza-
DATOS REALES
ciones que han establecido programas completos de medidas del soltware
han mejorado en ocasiones su calidad alrededor de un 40 por 100 al año,
y la productividad alrededor de un 15 por 100 al año en cuatro o cinco

años consecutivos (Jones, 1991, 1994). Señala que sólo un reducido gru-
po de organizaciones de Estados Unidos tiene actualmente medidas pre-
cisas de las tasas de defectos del software y de supresión de defectos, 1'
que estas organizaciones tienden a ser líderes en su campo (Jones, 1991 ).
Generalmente, el coste de este nivel de mejora va del 4 al 5 por 100 del
presupuesto total del software.
26.6. Claves para el éxito en el uso de las rnedidas

Éstas son las claves para tener éxito en el uso de medidas:
. Definir un grupo de medidas. Ponerlo a cargo de identificar las

medidas útiles y ayudar a los proyectos a que establezcan sus pro-
pias medidas.
o Anotar los datos de control de tiempo en un nivel fino de granula-
ridad.
Comenzar con un pequeño conjunto de medidas. Seleccione 1o que
desea medir utilizando la técnica objetivos, preguntas, métricas.
No recoja simplemente 1os datos. Analícelos y comente los resulta-
dos con las personas cuyo trabajo ha sido estudiado.
Software Measurement Guideboofr. Documento número SEL-94-002.
Greenbelt, Md.: Goddard Space Flight Center, NASA, 1994. Es un
libro excelente a nivel de introducción que describe 1os conceptos
básicos de cómo y por qué establecer un programa de medidas. Entre
otras cosas, incluye un capítulo de directrices basadas en la experiencia,
muchos datos de ejemplo de proyectos de la NASA, y un amplio con-
junto de formularios de recogida de datos. Puede obtener una copia
gratuita escribiendo a Software Engineering Branch, Code 552, God-
dard Space Flight Center, Greebelt, Maryland 20771.
Grady, Robert B., y Deborah L. Caswell:. Software Metrics: Establishing a
Company-Wide Program. Englewood Cliffs, N.J.: Prentice Hall, 1987.
Grady y Caswell describen sus experiencias con el establecimiento de
un programa de métricas del software en Hewlett-Packard, e indican
cómo establecer uno en su organización.
Grady, Robert B.: Practical Software Metrics for Project Management
and Process Improvement. Englewood Cliffs, N.J.: PTR Prentice
Hal1. 1992. Este libro es la continuación del anterior libro de Grady
1'Casrveli, y amplía el tratamiento de las lecciones aprendidas en
Hewlett-Packard. Contiene una presentación particularmente intere-

sante de un conjunto de gráfrcos de gestión de soffware, cada uno de
los cuales incluye notas sobre los objetivos y cuestiones que origina-
ron el desarrollo de cada gráftco.
Jones, Capers: Applied Software Measurement: Assuring Productivity and
Quality. New York: McGraw-Hill, 1991. Este libro contiene las reco-
mendaciones de Jones para configurar un prograÍla de medidas a nivel
de una organización Es una buena fuente de información sobre mé-
tricas funcionales (la alternativa a las métricas de líneas de código).
Describe los problemas de la medida de1 software, varios enfoques
para las medidas, y la mecánica de la construcción de un informe de
estado de medidas. También contiene discusiones generales excelentes
sobre los factores que contribuyen ala calidad y a la productividad'
Conte, S. D.; H. E. Dunsmore y V. Y. Shen: Software Engineering Me-
trics and Models.Menlo Park, California: Benjamin/Cummings, 1986.
Este libro cataloga el conocimiento sobre medidas del software, in-
cluyendo medidas usadas habitualmente, técnicas experimentales y
criterios para evaluar resultados experimentales. Es una referencia com-
plementaria útil para los libros de Grady o el libro de Jones.
IEEE Software, julio 1994. Este número se céntra en la mejora del proce-
so basada en medidas. Contiene artículos que tratan de varias escalas
de clasificación de proceso e informes de experiencias reales sobre la
mejora de procesos basada en medidas.
27
Hitos miniatura
El método de los hitos miniatura es un enfoque de grano fino para el

seguimiento y control de proyectos que ofrece una visibilidad excep-
cional del estado de un proyecto. Genera sus beneficios para el desa-
rrollo rápido eliminando virtualmente el riesgo de retrasos incontrola-
dos y no detectados en la planificación. Puede ser usado en proyectos I
de software de gestión, "prét-á-porter" y de sistemas, y puede usarse ;i
a lo largo de todo el ciclo de desarrollo. Las claves para el éxito en su
uso incluyen vencer la resistencia de las personas que van a ser
gestionadas con el método y permanecer fiel a la naturaleza "miniatu-
ra" del método.
l
Eficacia
Mejora en la visibilidad del progreso: Muy buena
Riesgos principales
Ninguno.

. Especialmente indicado para la recuperación de proyectos.
. Especialmente efectivo cuando se combina con el método de cons-
trucción y prueba diarias.
¡ Funciona bien con el prototipado evolutivo, el prototipado de la in-
lerfaz de usuario, especificación de requerimientos y otras activida-
des dif íciles de gestionar en los proyectos.
r Sacrifica el incremento en el esfuerzo del seguimiento del proyecto
por una visibilidad y control del estado mucho mayores.
519
=
1
Imagine que es un pionero que va de la costa este hacia el oeste. Su via_i;

es demasiado largo para ser realizado en un día, así que define un conjunrr-
de puntos que marcarán los hitos significativos de su viaje. Es un viaje de
4.000 km, por 1o que marca 5 hitos separados entre sí por 800 km.
Los hitos cada 800 km son interesantes para establecer la dirección a
rargo plazo,pero no sirven para ver dónde va a estar cada día, especialmente
cuando va a viajar aproximadamente unos 40 kilómetros cada día. por esto.
necesita un control más fino. Si sabe que su hito principal está a 800 kr,
en dirección nor-noroeste, puede coger la brújula, buscar un punto que
se encuentre aproximadamente al nor-noroeste y dirigirse a é1. Una r-ez
que alcance este punto más cercano, saca otra vezla brújula, busca otra
marca y avanza de nuevo.
Las marcas cercanas que seleccione (el árbol, la formación rocosa, el
río o la colina) serán sus hitos miniatura. Alcanzar los hitos miniatura le
da una amplia sensación de trabajo realizado. como sólo selecciona hitos
que se encuentran entre el punto actual y el siguiente hito principal, a1-
canzar el hito miniatura también le da la conftanza de que antes o después
alcanzará el hito principal.
El soporte para el desarrollo rápido ofrecido por los hitos miniatura
se deriva de cuatro factores: mejora de la visibilidad del estado, control de
grano fino, mejora de la motivación y reducción del riesgo de la planifi-
cación.
Mejora de la visibilidad del estado. Uno de los problemas más

comunes en los proyectos de desarrollo de software es que ni los desarro-
lladores ni los responsables del proyecto, directivos ni clientes pueden
conocer con precisión el estado del proyecto. No es necesario hablar
sobre si pueden predecir cuándo puede estar terminado el proyecto ¡si ni
siquiera saben la parte que se ha completado!
Jim Mccarthy advierte frente al hecho de dejar solos a los desarro-
lladores (McCarthy, 1995a). Usted piensa que todo va bien. ¿por qué?
Porque cada dia les pregunta a sus desarrolladores: <¿cómo va eso?>> Ellos
responden: <Bien.> Y entonces, un día pregunta; <¿Cómo va eso?> \.
ellos dicen: <<Hum, vamos a retrasarnos unos 6 meses.> ¡Vaya! ¡Se han
ERROR CLÁSICO retrasado 6 meses en un día! ¿cómo ha sido posible? Ha ocurrido porque
estaban trabajando <en la sombra> (ni usted ni ellos veían suficientemen-
te claro su trabajo para saber que se habían estado retrasando constante-
mente).
Con los hitos miniatura, define una serie de objetivos que tiene que
cumplir en una base prácticamente dtarra. Si comienza a no alcanzar
hitos, su planificación no es realista. como sus hitos son de grano fino, se
dará cuenta pronto de que tiene un problema. Esto le dará una oportu-
nidad temprana de recalibrar la planificación, ajustar su plan y seguir ade-
lante.
Capítulo 27: Hitos m¡n¡atura 521
¿Cómo es posible Control de granO f ino. E1.Roger's Version, John Updike describe una
dieta en la que una mujer se pesa cada lunes por la mañana. Es una mujer pe-
,Y;::::7;:;";;
a clía,. queña, y desea pesar menos de 50 kilos. Si un lunes por la mañana descubre
Frederick p. que pesa más de 50 kilos, come solamente zanahorias y salvado hasta que
Brooks, Jr. vuelve a pesar menos de 50 kilos. Su razonamiento es que no puede ganar
más de un kilo a la semana, y si no gana más de un kilo, no ganatá 5 o 10.
Con su método, su peso estará siempre cerca del valor que desea.
El método de los hitos miniatura aplica esta misma idea al desarrollo
de software, y se basa en la idea de que si su proyecto nunca se va a
retrasar más de un día o dos, es lógicamente imposible que se retrase una
semana, un mes o más.
Los hitos también ayudan a rcalizat el seguimiento del personal. Sin
hitos a corto plazo, es muy fácil perder la visión general. La gente pierde
tiempo en distracciones que parecen interesantes o productivas de forma
vaga, pero que no hacenavanzar al proyecto. Con un seguimiento de grano
grueso, los desarrolladores se retrasan algunos días o una semana, y no le
ponen atención.
Con los hitos miniatura, todo el mundo tiene que cumplir sus objeti-
vos cada día o dos. Si alcanza la mayoría de sus hitos trabajando todo un
día (y cubre el resto trabajando un día extra), alcanzará los hitos globales
al igual que los pequeños. No hay posibilidad de que aparezcan errores.
REFERENCIA Mejora de la motivación. La realización es el mayor factor de moti-

CRUZADA
vación de los desarrolladores de software, y todo lo que soporte la rea-
sobre la molivación lización o haga más palpable el progreso mejorará 1a motivación. Los
de los desarrolladores, hitos miniatura hacen que el progreso resulte excepcionalmente tan-
gible.
"Motivación".
BEFERENCIA Reducción del riesgo de la planificación. Uno de los mejores métodos
CRUZADA
para reducir el riesgo de la planificación es dividir las tareas grandes y
sobre la estimac¡ón definidas de forma vaga en tareas más pequeñas. Al crear una estimación,
detallada, véase los desarrolladores y directivos tienden a concentrarse en las tareas que
.Estime a un bajo
nivel de detalle", en conocen mejor, y a ignorar las tareas que comprenden menos. El resultado
la Secc¡ón 8.3. más habitual es que una semana de trabajo parala <<interfaz de la base
de datos> puede necesitar inesperadamente 6 semanas, porque nadie exa-
minó cuidadosamente este trabajo. Los hitos miniatura controlan este riesgo
eliminando completamente las vaguedades de la planificación.
27.1, Uso de los hitos miniatura

Puede aplicar el método de los hitos miniatura a lo largo de toda la vida
de un proyecto. Puede aplicarlo a actividades iniciales tales como la espe-
cificación de requerimientos y el prototipado evolutivo; de hecho, resulta
particularmente útil para centrar estas actividades difíciles de dirigir.
:.,,,,J;p$¡:ha9s,,,U@íp4 el,saí.,1$5¡lhiios..affide*,quele ayudan a establece¡ las

:,:,,,::áLrg,oeigln .,$e:ry,
de sus proyectos. Genérá1menté|,é¡tog,l.hiÍos estrán
separados poi intervalos de meses. En los proyectos tradicionales en cas-
cada, los lri{.q¡ p¡jpc$. 1é,qi$$ag{$en¡geaéf*&lre8t$:ie.rltlár,reá1i94ó,ión,de la
definición del producto, la finalizaCión de la especificáción de requerimien-
tos. finalización ¿é lá arquitéctura. finalización del diseño detálládo. fina-
Iización de la éodifiCácion, finálización de la pfueba dél sistema y acepta-
cron oer prooucto.
En los proyectos modernos de software <prét-á-porter>), un conjunto
:'ttr:;tfnicp:rde,¡h¡?*q:Fiirw.lpqle¡:,,p1ód;iía,:c íistirr:dé:,Iá::ápié.baoión,d€t,p.r'oJecto.
definición del aspecto. definición de las prestaciones, f,rnalización de la
codificación y envio á fabricación-
;),,':,:,;,,,,,;,;,,,*w¡í1\íió,+p,!!nüi Ates resultan útites para defir.tíiitry,;$'44,tcióu'¡péróbstrln
demasiado sepaiados para'ofréCer un buen control del proyecto. La'combi-
nación de hitos principales y miniatura puede funcionar bien: los hitos
pnncipales ofrecen los objetivos estratégicos del proyecto. y los hitos mi-
niatura ofrecen los mecanismos tácticos para alcanzar cada objetivo.
Para obtener el máximo beneficio, e1 método de los hitos miniafur:

será implementado a nivel de proyecto por el responsable técnico o director.
según resulte adecuado. Pero los componentes individuales pueden im-
plementarlo a nivel personal, incluso aunque sus jefes no lo hagan.
La cantidad de detalles necesarios al implementar los hitos miniatura
dará mucho trabajo a la persona que tenga la responsabilidad de controlar
estos detalles, especialmente en grandes proyectos. Sin embargo, los gran-
des proyectos son los que quedan fuera de control con más frecuencia. 1
estos proyectos son los que requieren especialmente este tipo de segui-
miento detallado.
REFERENCIA Gomience a usar los hitos miniatura al principio del proyecto o en

CRUZADA
respuesta a una cris¡s. Los hitos miniatura ofrecen un alto grado de
sobre la toma de control del proyecto. Defínalos pronto en el proyecto, o en respuesta a la
nuevas medidas en detección de una crisis. Si los establece en otros momentos, corre el ries-
respuesla a una
crisis, véase go de parecer draconiano. Como con otros aspectos de control de proyec-
.Temporización
", tos, es más fácil controlar demasiado al principio y relajar el control a
medida que progresa el proyecto que seguir otras pautas. Como dicen Barr-r-
Boehm y Rony Ross, <es mejor pasar de duro a relajado que de relajado a
duro> (Boehm y Ross, 1989).
Permita que los desarrolladores creen sus propios h¡tos minia-

tura. Algunos desarroliadores verán los hitos miniatura como microges-
a' ---€:
Capítulo 27: Hitos min¡atura S23
tión, y realmente están en 1o cierlo. son micro-qestión. Más específicamente

es microseguimiento de proyectos. Sin embargo. no toda la microgestión es
mala. La microgestión a la que se resisten 1os desarrolladores es la micro-
gestión de los detalles de cómo realizan su trabajo.
Si deja a las personas que definan sus propios hitos miniatura, les
permite controlar los detalles de su trabajo. Todo lo que les pide es que
le indiquen cuáles son los detalles, lo que mejora la implicacrón y evita
qve parezca microgestión. Algunas personas no comprenden 1os detalles
de su trabajo, y estas personas se sentirán amenazadas con este método.
Si trata sus objeciones de forma diplomática, aprender aftabajar con una
planificación de hitos miniatura les servirá como una experiencia de for-
mación.
Usar hitos realmente miniatura. Defina hitos miniatura que puedan

alcanzarse en 1 o 2 dias. No hay nada mágico en esta limitación de tama-
ño, pero es importante que alguien que no alcance un hito pueda alcanzarlo
rápidamente. Si las personas han hecho generalmente una buena labor al
estimar su trabajo, deben poder alcanzar cualquier hito fallido trabajando
horas extras durante 1 o 2 días.
otra razón para mantener reducidos los hitos miniatura es disminuir el
número de lugares donde pueda ocultarse un trabajo no previsto. Los desa-
rolladores tienden a ver una semana o fin de semana como una cantidad
de tiempo infinita (pero no pueden hacer nada). No piensan exactamente lo
que implica la creación del <módulo de conversión de datos>, y por eso este
rnRon crÁsrco trabajo necesita dos semanas en lugar del fin de semana estimado inicial-
mente. Pero la mayoría de desarrolladores no se comprometerán a resolver
un problema en 1 o 2 dias, a menos que comprendan exactamente lo que
implica.
Para estar seguro de que está basando su planificación en estimaciones
significativas, insista en tareas de descomposición adicionales que estén
por debajo del umbral del <tiempo infinito> dentro de su entorno.
Defina hitos binarios. Defina los hitos para que estén hechos o no he-
chos. Los únicos dos estados serán <hecho)) y (no hecho>. No use porcen-
tajes. Tan pronto como la gente pueda decir que tiene algo <hecho en un
90 por 100>, los hitos pierden su capacidad para contribuir a una visión
clara del progreso del proyecto.
REFERENCIA Algunas personas no pueden resistir la tentación de drfuminar ios in-
CRUZADA
Para ver otro ejemplo,
formes de estado en los hitos miniatura. Usted pregunta: <¿Ha terminado?>
consulte .siga <¡Sí!>, 1e dicen. <¿Ha terminado al 100 por 100?>. pregunta. <<Bien. hum.
meticulosamente el
progreso de la
realmente ¡he terminado el 99 por 100!> <¿Qué quiere decir eso de un
planificac¡ón", en la 99 por 100?)), pregunta. <Bien, hum. quiero decir que todar.ía necesito
Sección '16.2. compilar, probar y depurar el módulo. ipero ya lo he escritol>
Sea intransigente respecto a la interpretación estricta de 1os hrtos.
524 Desarrollo y gestión de proyectos intormáticos
Defina un con¡unto exhaust¡vo de hitos. Asegúrese de que su lista d¿

hitos incluye todas las tareas necesarias para entregar su producto. La fuent:
más común de errores en la estimación del software es omitir las tarea-<
necesarias (Van Genuchten, 1991). No permita que los desarrolladores
mantengan una lista de trabajo <fuera de 1a planificación> en sus cabezas:
ERROR CLASICO las pequeñas tareas de <limpieza> pueden crecer rápidamente. E,ste traba-
jo puede crecer hasta un volumen capaz de hundir un proyecto. Insista er
que todas las tareas estén en la lista de hitos. Cuando marque e1 últimt
hito como completo, su proyecto debe estar terminado, y debe poder le-
vantar el campamento e irse a casa (realmente, ¡el levantamiento del cam-
pamento también debe encontrarse en la lista de hitos!)
REFERENCIA Use hitos miniatura para plan¡ficación a corto plazo (pero no a

CRUZADA
largo plazo). Elmétodo de los hitos miniatura es apropiado para con-
sobre el modo en que trolar el progreso a corto plazo dentro de un objetivo global. Los hitos
la visibilidad mejora a miniatura son los árboles, las rocas, los ríos y 1as colinas hacia los que se
medida que progresa
un proyecto, consulte dirige a continuación. No vaya demasiado lejos. Generalmente no es prác-
la Sección 8.1, tico o incluso posible crear una lista de hitos detalladapara un proyecto
"Histor¡a de la completo al principio del mismo. Por ejernplo, simplemente no sabe lo su-
estimación del
software.. ficiente antes de completar el diseño para poder crear hitos miniatura para
1a construcción.
Recuerde lametáfora del pionero. Periódicamente, encontrará un terre-
no elevado que le permitirá examinar las tierras que le rodean. Éste es el
objetivo de los hitos principales. A1 definir hitos miniatura, está planifi-
cando el camino hacia la siguiente marca principal. Sólo puede marcar
una ruta detallada de la parte del terreno que puede ver desde su punto de
observación actual.
Compruebe el progreso regularmente, y recalibre o replanifique.

Una de las ventajas principales del uso de hitos miniatura es que le per-
miten comparar con frecuencia sus estimaciones y su progreso actual.
Puede recalibrar sus estimaciones basándose en su progreso actual, y puede
mejorar rápidamente sus habilidades de estimación.
REFERENCIA Si detecta que está fallando frecuentemente al alcanzar hitos, deje de
CRUZADA intentar ponerse al día. En lugar de ello, se retrasará cada vez más. Só1o
sobre la recalibración tiene dos opciones: 1) puede recalibrar su planificación, multiplicando el
de estimaciones, resto de la planificación por el tamaño del retraso tenido hasta el momen-
consu lte
. Recalibración to; 2) puede tomar acciones correctivas para volver a la planificación, que
" ,
en la Secc¡ón 8.7. pueden consistir en recortar el conjunto de prestaciones del producto, elimi-
nar distracciones para que los desarrolladores puedan concentrarse mejor.
reasignar partes del proyecto a desarrolladores que parecen estar cumplien-
do sus hitos fácilmente, y demás.
Si un desarrollador ha ido cumpliendo la planificación a base de tra-
bajar grandes cantidades de horas extras, recalibre la planificación de este
Capitulo 27: Hitos miniatura 525
REFERENCIA desarrollador. Este desarrollador no tiene ningún margen de seguridad, y

CRUZADA
cualquier tarea que haya sido subestimada en mayor grado que el resto
sobre los peligros hará estallar 1a planificación. También necesitará darle a este desarrolla-
de una excesiva dor tiempo suficiente para evitar que tonte decisiones tontas y aceleradas
presión de
planif ¡cación, que retrasarán en definitiva el proyecto. Recalibre 1a planificación para
consulte la que pueda alcanzarce trabajando normalmente. 8 horas a1 día.
Sección 9.1,
Planif icación Si después de la recalibración encuentra que al-eunos hitos han alcan-
"
excesivamente zado un tamaño mayor de I o 2 dias, haga que ios desarrolladores des-
oPtimista".
compongan estos hitos en hitos más pequeños, y vuel\.a a estimarios.
Cuando recalibre la planificación de varios desarrolladores. encontra-
rá probablemente que las planificaciones de algunos de ellos crecen más
que otras. Si estas diferencias son muy grandes, distribuya parte del tra-
bajo para equilibrar estas planificaciones.
Fodria pregu4tarse cq{} gq,!l diferencia entfs loqhiioslajnialura y las !is-

las generales de tareas. Los dos métodos son'similares en el sentido en el
que anotan el trabajo a realizar con mucho detalle. Las di lerencias está'n
principalmente en el énlasis. El método de los hitos miniarura insiste en
que las tareas sean consideradas como terrninadas o no en un 100 por 100;
las tareas genéricas no presentan esta restricción. Los hitos miniarura defl-
nen una tarea para que tenga una duración de I o 2 días; las tareas genéri-
cas pueden tener cualquier longitud. Los hitos minjatura requieren que re-
calibre si se sale de lo prer isto: las tareas genéricas no incluyen esta noción.
En,:résumen, el uso de los hitos miniafera requiere ¡¡na mayor discipliaa
que el uso de listas genéricas de tareas.
27.2. Gestión de los r¡esgos de los hitos miniatura

Hay un riesgo de fallo en el uso efectivo del método de los hitos minia-
tura. El uso de los hitos miniatura en sí no plantea ningún riesgo al propio
proyecto.
27.3. Efectos secundarios de los hitos miniatura

El uso del método de los hitos miniatura requiere una gestión detallada y
activa. La definición de los hitos miniatura requiere tiempo y esfuerzo
por parte de los desarrolladores y sus responsables. Requiere un compromi-
so continuo pararealizar informes de estado y seguimiento. El método de
los hitos miniatura requiere más esfuerzos de gestión que otros enfoques
menos detallados; sin embargo, estos otros métodos no suelen funciona¡.

Decir que el uso de los hitos miniatura requiere más tiempo que otro5
métodos puede ser equivalente a decir que la gestión efectiva requiere
más tiempo que la gestión ineficaz.
Un segundo efecto lateral de los hitos miniatura consiste en que eviu
que un responsable de proyecto pierda el contacto con el mismo. Un res-
ponsable que use hitos miniatura estará en contacto regular con todas las
personas del proyecto cadavez que se supone que se termina un hito, 1o
cual debe suceder casi cada día. Se produce una gran cantidad de comuni-
cación, y esto ayuda a la gestión de riesgos, motivación, cuestiones de
personal y la mayoría de actividades de gestión.
27.4. lnteracciones de los hitos miniatura con otros

métodos
El método de los hitos miniatura resulta particularmente útil durante ia
recuperación de proyectos (Capítulo 1 6) porque ofrece una excelente visi-
bilidad del progreso. Como los hitos miniatura soportan comparaciones
prácticamente diarias entre el progreso estimado y el actual, también
soportan un control relativamente rápido de la duración real de un pro-
yecto.
Un proyecto que se encuentre en modo de recuperación resulta a me-
nudo especialmente adecuado parula ejecución del resto del proyecto en
hitos miniatura. En la mayoría de proyectos, no se detecta que hay pro-
blemas hasta que se está en la mitad o finalizando la fase de construcción.
En ese momento, los desarrolladores saben generalmente con detalle el
trabajo que queda por hacer. Como el personal se da cuenta de que se está
enfrentando a una crisis, está dispuesto a tomar fuertes acciones correctivas,
y se muestra receptivo al control implicado por el método de los hitos
miniatura.
Los hitos miniatura son especialmente adecuados para su uso con ei
método de construcción y prueba diarias (Capítulo 18), que mejora su
capacidad para verificar que se está alcanzando cada hito miniatura.
Los hitos miniatura también resultan útiles como medio para contro-
lar métodos de desarrollo amorfos, que de otro modo resultarían difíciles
de controlar: prototipado evolutivo (Capítulo 21), prototipado de la inter-
faz de usuario (Capítulo 42'), y demás.
Puede usar los hitos miniatura como un método para calibración de la
estimación (Sección 8.7), aunque no los use para el control del proyecto.
Planifique las primeras semanas del proyecto usando hitos miniatrtra, y
observe su comportamiento frente a la estimación. Si cumple sus esti-
maciones, puede que desee dejar de usar hitos miniatura. Si encuentra
Capítulo 27: Hitos miniatura
que sus estimaciones no se cumplen en cantidades significativas, esto le

indica que debería volver a estimar \. probar de nuevo.
27,5. Puntos cruc¡ales de los hitos miniatura

En el Capítulo 14, <Control del conjunto de prestaciones>. he descrito el
desarrollo de On Location, un proyecto que entró en grandes problemas
de planificación. El mismo artículo que describe los problemas de1 pro-
yecto también describe 1o que se tardó en entregarlo:
Reunieron a todo el equipo y realizaron un recuento minucioso de todo el

trabajo que había que hacer. Decidieron que podían terminar en algo más
de un mes, pero sólo deteniendo el trabajo del segundo proyecto y dedi-
cando 3 programadores más a On Location... Se desataron nuevas tensio-
nes en la oficina, pero el proceso se mantuvo notablemente cerca de 1a
nueva planificación. El producto (la versión 30 circulaba internamente) fue
entregado por fin para producción. (Carroll, 1990.)
Un proyecto que tenía graves problemas (suficientemente importan-

tes como para aparecer en The Wall Street Journal) puso finalmente las
cosas bajo control usando <un recuento detallado de todo el trabajo que
quedaba por hacer> (hitos miniatura). Deberían haber usado hitos minia-
tura a 1o largo de todo el proceso.
REFERENCIA El valor de los hitos miniatura radica fundamentalmente en la mejora
CRUZADA que ofrece en la visibilidad y control del proyecto. Sus beneficios parala
sobre la importancia de planificación se deben más bien a la reducción del riesgo de una gran
hacer v¡sible el acumulación de pequeños retrasos individuales de la planificación. Si pien-
progreso, consulte la
Sección 6.3, sa que ie faltan 3 meses para terminar y no puede crear una planificación
percepción y
" de hitos miniatura para el resto del proyecto, probablemente no sabe con
realidad".
detalle 1o que hay que hacer para terminar el proyecto, y es probable que
le falten de 6 a 9 meses para terminar.
Los hitos miniatura ofrecen una segunda mejora parula planificación
al centrar las actividades de los desarrolladores. Como todo el trabajo está
en la planificación, hay menos oportunidades para explorar áreas intere-
santes, pero al fin y al cabo improductivas en el desarrollo. El efecto pue-
de ser una pequeña reducción en el tiempo de desarrollo.
27,6. Claves para el éxito en el uso de hitos miniatura

E,stas son las claves para tener éxito en el uso de hitos miniatura:
o Iniciar su uso en el momento adecuado, bien al principio del proyecto

o en respuesta a una crisis.
o Utilice hitos pequeños, con una duración de un día o dos.

¡ Asegúrese de que su lista de hitos es exhaustiva.
¡ Fomente larealización de informes exactos del progreso de los hitos.
¡ Controle regularmente el progreso, y recalibre o replanifique si em-
pieza a retrasarse en la planificación de hitos.
Gilb, Tom: Principles of Software Engineering Managemenr. Woking-
ham, England: Addison-Wesley, 1988. Gilb no usa el término <hitos
miniatura>, pero la mayoría del método que describe es similar. Su
libro contiene una discusión particularmente interesante sobre la
recalibración en respuesta a la experiencia obtenida al cubrir hitos mi-
niatura.
28
Desarrollo externo
(Outsourcing)
El desarrollo externo consiste en pagar a una organización externa para

que desarrolle un programa en lugar de desarrollarlo dentro de su orga-
nización. Las compañías externas pueden tener más experiencia en el
área de la aplicación, más desarrolladores disponibles para trabajar
en un momento dado, y una biblioteca más amplia de código reutili-
zable de la que disponer. Esta combinación puede producir una reduc-
ción drástlca en el tiempo necesario para desarrollar un nuevo producto.
En algunos casos, el desarrollo externo también puede ahorrar costes
de desarrollo.
Ef icacia
Reducción potencial de la planificación nominal: Excelente
Mejora en la visibilidad del progreso: Ninguna
Efecto sobre el riesgo de la planificación: Aumenta el riesgo
Posibilidad de éxito a largo plazo'. Muy buena
Riesgos principales
o Transferencia de experiencia fuera de la organización.
. Pérdida de control sobre desarrollos futuros.
. Compromiso de información confidencial.
r Pérdida de visibilidad y control del progreso.

. Sacrifica la pérdida de controly la reducción de capacidad de desarro-
llo interna por una mejora en la velocidad del desarrollo, una reducción
de coste o ambas.
sn Daatrollo y gestión de proyectos informáticos
El desarrollo externo puede ser más rápido que el desarrollo interno

por la misma razón que comprar una barra de pan en la tienda es más
rápido que hacerlo uno mismo. Hay gente cuya dedicación principal es
hacer pan y,hay gente cuya dedicación principal es desarrollar software
para otros. Estas son algunas de las razones por las que el desarrollo ex-
terno puede ahorrar tiempo.
REFERENCIA Reutilización. Como en el ejemplo de las panificadoras, las empresas
CRUZADA
Para más detalles
comerciales de desar:rollo externo pueden lograr una economía a escala
sobre la reutilización industrial que no pueden alcanzar organizaciones individuales. Si desarro-
consulte el lla un único programa de control de inventario, quizás no pueda justificar
Capítulo 33,
. Reutilización". triplicar el coste para desarrollar una biblioteca de componentes reutiliza-
bles de control de inventario. Para un programa, esto podría costar más
simplemente sin ofrecer ningún beneficio. Pero alguien que se dedique al
desarrollo externo que desarrolla docenas de sistemas de control de inven-
tario no puede intentar siquiera desarrollar esto sin componentes reusables.
El desarrollo inicial costará quizás el triple, pero los componentes reusa-
bles le permitirán desarrollar cada programa adicional de control de inven-
tario con una pequeña parte del coste del desarrollo inicial.
Aun sin componentes reusables, el desarrollo externo soporta el desa-
rrollo rápido de varias formas.
Flexibilidad de plantilla. La empresa de desarrollo externo de soft-
ware puede dedicar más desarrolladores al proyecto de los que podría dis-
poner usted mismo. O puede que tenga desarrolladores que estén motiva-
dos a trabajar más horas extras que su propio equipo.
Experiencia. Si el área de aplicaciones es nueva para usted o implica

el uso de tecnología con la que no está familiarizado, el vendedor podría
tener más experiencia que usted en el área.
REFERENCIA Mejor espec¡f¡cación de requer¡m¡entos. Dependiendo de los detalles
CRUZADA
de su contrato con la empresa, podría necesitar crear una especificación
sobre la importancia de requerimientos más cuidadosa de la que realizaria en otro caso. Un
de una buena análisis de requerimientos de alta calidad puede ayudarle a ahorrar tiempo,
especificación de
requerimientos, independientemente de que el proyecto se desarrolle fuera o no, pero el
consulte "Gestión de incentivo para prestar atención ala calídad de los requerimientos es ma-
requerimientos", en la
Sección 4-2. yor cuando se usa desarrollo externo.
REFERENCIA Reducción del cambio de prestaciones. Los costes de los cambios
CRUZADA
Para más información de prestaciones pueden estar ocultos o resultar confusos cuando se hace el
sobre el cambio de desarrollo en la empresa, pero los vendedores son especialmente sensibles
prestaciones, consulte
la Sección 14.2,
al coste de los cambios. como con la especificación de los requerimien-
-Proyecto avanzado: tos de alla caridad, 1a disminución de los cambios de prestaciones puede
coÍÍol de cambios de ahorrarle tiempo en el caso de que utilice desarrollo externo o interrro,
las prestaciones..
pero el incentivo es mayor con el desarrollo externo.
Capítulo 28: Desarrollo externo (Outsourcing) 531
Si es un responsable técnico, probablemente no iniciará el desarrollo

externo, pero debería saber 1o que implica. Los altos directivos podrían
llamarle para evaluar si la organización debe recurrir al desarrollo exter-
no de un proyecto o participar en la evaluación de empresas de desarro-
llo. Una de las cuestiones más interesantes respecto al desarrollo externo
es que le pone en el lado del cliente en el proceso de desamollo de1 soft-
ware; esto puede darle un mayor conocimiento de 1o que experimentan
sus clientes.
28.1. Uso del desarrollo externo

En ocasiones, las organizaciones recurren al desarrollo externo porque
están frustradas con las dificultades del desarrollo propio de software.
Suponen que si alguien construye el software para ellos, su trabajo será
mucho más fácil. Pero la realidad es prácticamente opuesta. Cuando el
proyecto está siendo realizado en otro lugar de la ciudad o del mundo, se
ERROR CLASICO tiene menos visibilidad del progreso del proyecto, y para compensar esta
falta de visibilidad se requiere una gestión astuta y atenta. Por norma, el
desarrollo externo requiere una gestión más habilidosa aún que el desa-
rrollo de software propio.
REFERENCIA Desarrolle un plan de gestión que incluya gestión de riesgos. De-

CRUZADA
sarrolle planes parc \a gestión dei desarrollo externo del mismo modo
sobre la gestión de que los elaboraría para un proyecto propio. Sus planes deben incluir
riesgos, consulte el descripciones sobre cómo piensa seleccionar la empresa de desarrollo,
de riesgos". negociar el contrato, desanollar los requerimientos, gestionar los cam-
bios de requerimientos, controlar el progreso de la empresa, controlar la
calidad y validar que el software entregado cumple los requerimientos.
Podría desarrollar estos planes en colaboración con el vendedor seleccio-
nado.
Planifique emplear tiempo en la gestión de riesgos. No entrar en deta-
lles en un proyecto realizado por otra organización puede implicar ries-
gos que no haya experimentado en su propia organizaciín (hablaremos
más de esto posteriormente).
Aprender sobre la gestión de contratados. Existe un conjunto de

conocimientos bien definido relacionado con la gestión de trabajo externo.
Un buen punto de partida para comenzar a aprender sobre este tema es
leet Software Acquisition Management (Marciniak y Reifer, 1990), descrito
en la sección de <Bibliografía adicional> del final de este capítulo.
Considere pr¡oritaria la comunicación con elvendedor. Planif,rque

tener una comunicación regular con la empresa de desarrollo extemo. aun-
Desa,rollo y gestión de proyectos informáticos
que no parezca que haya nada sobre 1o que comunicarse. Aigunos prc,-
yectos software utilizan <gestión por reuniones>; cuando usa desarroi,¿
externo debe planificar hacer <gestión por teléfono>.
En ocasiones, las compañías de desarrollo externo remotas ofrecen un
enlace de datos dedicado para el intercambio de correo electrónico, archi-
vos de computadora y demás. En un caso, la existencia de un enlace vía
satélite dedicado de 64 Kilobits fue considerado como una clave para el
éxito del proyecto. Los clientes informaron que el enlace de comunicaciones
supuso el 25 por 100 del coste total del proyecto, y que sus ventajas supe-
raron con creces el coste derivado (Dedene y De Vreese, 1995).
Cuente con el uso de algunos de sus propios recursos técnicos.

En ocasiones, las organizaciones desean usar desarrollo externo porque
no tienen los conocimientos técnicos necesarios para desarroilar un pro-
ducto. El desarrollo externo suple definitivamente esta demanda de equi-
po técnico, pero no la elimina. Planifique emplear más tiempo en la es-
pecificación del producto del que usa normalmente. Generalmente, la
especificación formará parte del contrato de desarrollo externo, y sólo
tendrá aquello que pida. Si olvida pedir algo en la especificación, hay pocos
vendedores que se 1o den por amor al arte. Además, planifique también
resefvar equipos técnicos para ofrecer soporte a las preguntas del ven-
dedor y para comprobar la calidad y aceptabilidad del producto entre-
gado.
Tenga cuidado con los requerimientos inestables. Excepto en raras

ocasiones, no podrá definir con suficiente precisión sus requerimientos
para que los vendedores le den un precio exacto del proyecto antes de que
realicen algún trabajo inicial. Si insiste en fijar precios basándose en una
especificación ambigua de requerimientos, los vendedores competentes
le darán precios más altos. Só1o obtendrá ofertas más económicas de aque-
llos vendedores que no comprendan suficientemente bien el desarrollo de
software como para conocer los riesgos implicados con un software espe-
cificado de forma incompleta.
La primera parte de su proyecto (sin importar que sea rearizado en su
organización o en una empresa externa) debe estar dedicada a definir y a
estabilizar los requerimientos, de forma que pueda, en principio, hacer el
resto del proyecto sobre un precio fijo sin tener que añadir excesivo relle-
no en la estimación.
Algunos vendedores son especialistas en prototipado, sesiones JAD y
otras técnicas para obtener rápidamente los requerimientos. Esto puede
ayudarle a reducir la planificación, aunque no tenga un conjunto claro cie
requerimientos. otras empresas reahzan simplemente diseño e implemen-
tación. Si recurre a ellas, tendrá que desmenuzar sus requerimientos antes
de que puedan ayudarle a ahorrar tiempo.
Mantenga el control suficiente para devolver el trabajo a su empresa

si es necesario. Con todas 1as cosas que pueden ir mal con el trabajo
encargado externamente. asegúrese de tener un plan B.
Considere especialmente el desarrollo externo de la reingeniería

de sistemas existentes. Un prol,ecto de reingeniería de un proyecto
existente es un candidato especialmente bueno para e1 desarrollo exter-
no. Los usuarios han empleado años en obtener un sistema a su gusto, y
generalmente no desean cambiar nada. Los requerimientos tienden a ser
estables. Generalmente, el equipo de mantenimiento de un sistema exis-
tente está abrumado, y apreciará el descanso que supone tener a alguien
que reconstruya el sistema.
En los proyectos de reingeniería, la prueba del sistema puede resultar
una parte importante del esfuerzo de desarrollo, porque el resto de1 tra-
bajo se ve fuertemente apoyado por las herramientas de traducción de
código. Considere también como desarrollo externo una buena parte de 1a
prueba.
Asegúrese de desarrollar un plan para gestionar los cambios del soft-
ware reconstruido una vez que 1o tenga en casa. ¿El nuevo código podrá ser
mantenido por los desarrolladores de su empresa? ¿Quién gestionará la
corrección de defectos y mejoras?
Evite tener estándares dobles para el trabajo externo. En ocasio-

nes, ias organizaciones imponen estándares distintos a las empresas de
desarrolio externo de los empleados para los desarrolladores propios. Si
está considerando el uso de1 desarrollo externo, considere e1 electo sobre
la calidad y 1a planificación derir.ado de exigir los estándares de la em-
ERROR CLASICO presa exteñia a 1os desarrolladores propios,
Tipos de contratos
Los tipos básicos de contratos son por tiempo y materiales, de precio fijo
y progresivos. El tipo de contrato determina muchas características de la
relación que va a tener con la empresa de desarrollo.
Los contratos por tiempo y materiales ofrecen la mayor flexibilidad y
no necesita tener muchos conocimientos técnicos. Puede decir simplemente
<Quiero un foobar>, y la empresa trabajará en el foobar hasta que 1o consiga
o se agote el dinero. Puede cambiar de opinión en 1o que entiende por
<foobar>, siempre y cuando siga pagando. La desventaja consiste en que
los contratos por tiempo y materiales superan generalmente sus esti-
maciones. Además, las empresas requieren generalmente un pago inicial
importante antes de comenzar a trabajar (hasta un 50 por 100), por 1o que
cuando empiezan a exceder sus estimaciones, sentirá que ya no tiene la
opción de rescindir el contrato.
534 )'esar:c'to y gestión de proyectos informáticos
Los contratos de precio fijo son una alternativa a los contratos por
tiempo y materiales. Con el precio fijo, tiene una garantía de que el
vendedor no excederá su estimación, o por io menos que conerá con el coste
si 1o hace. Pero esta garantía puede incrementar el precio hasta en un
50 por 100 respecto al de un proyecto equivalente por tiempo y materia-
les. Los contratos de precio fijo también requieren que especifique con
cierto detalle 1o que quiere decir cuando dice <Quiero un fooban. Los
cambios de requerimientos exigirán que negocie para obtener más tiempo
y dinero. Si piensa que negociar los cambios de prestaciones con sus pro-
pios desarroiladores era duro, espere hasta que tenga que hacerlo con un
tercero. Generalmente, los contratos a precio fijo requieren un fuerte pa-eo
inicial, por 1o que rescindirlos también será costoso. Algunas empresas
ofrecen ahora un tercer tipo de contrato: contrato progresivo. Este tipo de
contrato tiende a ser más económico que los contratos por tiempo y mate-
riales o a precio fijo. Generalmente sólo se paga un 20 por 100 al princi-
pio, y no se hace ningún pago adicional hasta que el desarrollador alcanza
un hito significativo. Este hito se define de forma que cuando el desarrolla-
dor 1o alcance, puede tener ia con{ianza de que el proyecto tendrá éxito.
La única desventaja de este tipo de contrato consiste en que el desarrolla-
dor puede insistrr en que pern-ranezca implicado activamente a lo largo
de1 proyecto. Realmente csto no es una gran desventaja,ya que la ejecu-
ción con éxito de los otros tipos de contrato requiere también lo mismo.
Hay muchas variaciones de estos tipos básicos de contratos, incluyendo
los contratos con coste adrcional (básicamente contratos de precio fijo
con un incentivo para premiar la entrega a tiempo). Generalmente desea-
rá negociar los detalles de un contrato específico de desarrollo externo.
Desarrollo en el extran¡ero
ffi
DATOS REALES
Una de las opciones de desarrollo externo que se está haciendo cadavez
más popular es el desarrollo externo en ei extranjero. Las compañías ex-
tranjeras ofrecen menores costes laborales de los que podría encontrar
localmente, del orden de un 35 por 100 menos (Dedene y De Vreese, 1995),
y algunas ofrecen una calidad del orden de la encontrada en empresas de
E,stados Unidos. Hay que tener en cuenta varias cuestiones en este caso.
Comunicación. La comunicación es una de las claves para tener éxito

en cualquier proyecto cle desarrollo externo, y se convierte en un tema más
importante cuando el desarrollo extemo se realiza en un país lejano. Servi-
cios que damos por supuestos, como una conexión telefónica fiable, pueden
convertirse en grandes obstáculos.
Asegúrese de que las diferencias de idiomas no serán un problema. Si
trabaja con personas que hablan su mismo idioma, es probable que tenga
menos problemas que si trabaja con personas que hablan en otro idioma.
Capítulo 28: Desarrollo externo (Outsourcing)
Algunas compañías anuncian que tienen ingenieros extranjeros res-

paldados por directivos de EE.UU. La idea consiste en hablar con personas
que hablen su idioma, y éstas hablen con las personas que hablan el otro
idioma. Este rnétodo puede ir bien, o puede ser un infierno cuando al final
del proyecto reciba 100.000 líneas de código documentadas en ruso o en
japonés, y usted hable sólo español.
Diferencias horarias. Las diferencias horarias pueden trabajar a su fa-

vor o en su contra. Si necesita tener interacciones diarias, en tiempo real,
una diferencia horaria significativa puede resultar en el solape de ninguna
o pocas horas de trabajo, por 1o que usted o la empresa de desarrollo aca-
barán trabajando a horas extrañas.
Si puede realizar la mayoría de sus comunicaciones por correo electró-
nico, una gran diferencia horaria será más bien una ayuda que una desven-
taja. El vendedor puede responder a sus preguntas por correo electrónico
mientras usted está durmiendo y viceversa. Si está compartiendo una
computadora, la empresa extranjera podría usar su computadora durante
sus horas normales de trabajo, que pueden ser sus horas de descanso. Entre
su localidad y la de la empresa, puede trabajar con un ciclo horario que
reduzca parte dei estrés típico asociado con un planificación de este tipo.
Viajes. Planifique la reserva de algún tiempo y dinero para viajes. No

podrá resolver todas las cuestiones por correo electrónico o teléfono, y
las reuniones en persona ayudan a evitar problemas de comunicación que
pueden hacerle perder mucho tiempo. Como mínimo, planifique tener reu-
niones personales ai principio del proyecto, al final del proyecto y cada
dos meses a lo largo del proyecto.
Características del país del vendedor. Trabajar con un vendedor ex-

tranjero puede exponerle a riesgos que no tendría que considerar altrabalar
con empresas locales. Por ejemplo, necesita conocer las leyes de derechos
de autor, patentes y propiedad intelectual locales del vendedor. Además,
necesita considerar el clima político y económico del país del vendedor,
así como otros factores que podrían interferir con su proyecto.
REFERENCIA Evaluación de vendedores

CRUZADA
La evaluación de
vendedores comparte
Una de las tareas a las que se enfrentará al hacer un desarrollo de software
muchas facetas con la externo es evaluar un vendedor. Si su confianza en las capacidades del
evaluación de vendedor no está bien fundada, es prácticamente seguro que tendrá menos
herramientas. Para
más detalles, consulte beneficios de los esperados. Un ejercicio interesante consiste en usar una
la Sección 15.3, herramienta comercial de estimación para comparar a sus propios desarro-
"Adquisición de lladores frente a los del posible vendedor. Si la herramienta estima que la
herramientas para
Productividad.. planificación del vendedor no será significativamente mejor que la planr-
ficación que puede alcanzar en la propia empresa, será mejor que de*--
rrolle el proyecto dentro de su empresa.
La Tabla 28.1 lista las consideraciones a tener en cuenta al eval;,r
vendedores.
Tabla 28.1 . Cuestionario para la evaluación de vendedores
Consideraciones de gestión
o ¿Cuál es la capacidad del vendedor para cumplir sus compromisos de
planificación y presupuesto? ¿Cuál es su historial de cumplimiento de
compromisos?
B ¿Cuáles son los niveles de satisfacción de ios clientes actuales del
vendedor, incluyendo clientes a largo plazo? ¿El vendedor tiene algún
cliente habitual?
tr ¿Cuáles son las capacidades de gestión de proyectos del vendedor? ¿Tiene
experiencia en todos los aspectos de la gestión de proyectos software,
incluyendo estimación de tamaño, estimación de costes, planificación de
proyectos, seguimiento de proyectos y control de proyectos?
tr ¿Puede confiar en la confidencialidad del vendedor? ¿Trabaja también el
vendedor con sus competidores?
tr ¿Quién va a ofrecer el soporte del producto? ¿Usted o el vendedor? ¿Desea
que el vendedor lleve el soporte a sus clientes?
O ¿Hay alguna denuncia presentada contra el vendedor?
Co nsideraciones téc nicas

tr ¿cuál es la capacidad del vendedor para superar los desafíos técnicos de1
proyecto?
tr ¿La capacidad de desarrollo de software del vendedor ha sido evaluada por
su equipo técnico o por un tercero? ¿,La evaluación ha incluido los
productos de trabajo técnico y procesos de desarrollo?
a ¿cuál es el nivel de experiencia del vendedor en ei área de aplicación? ¿cu-:-
es ei nivel de experiencia del vendedor en el entorno de implementación?
tr ¿Es aceptable 1a calidad de otro software desarrollado por el vendedor? ¿E-
vendedor tiene datos cuantitativos para soportar las afirmaciones que
realíza respecto a la calidad?
tr ¿La calidad del trabajo del vendedor es suficiente para permitir futuras mejoras.'
Consideraciones generales
tr ¿La situación financiera del vendedor es estable? ¿eué le pasaría a su
proyecto si el vendedor se encuentra con un severo revés financiero?
tr ¿El vendedor ha desarrollado software por encargo en otras ocasiones? ¿La
construcción de software por encargo es la actividad principal del vendedor?
¿cuál es el nivel de compromiso del vendedor con el desarrollo externo?
l{..
---.
Considerac¡ones sobre el contrato

En algún punto de sus relaciones con una empresa de desarrollo externo,
deseará crear un contrato que describa las condiciones de desarrollo ex-
terno. De forma nominal, el contrato detallará e1 tipo de software que va a
ofrecer el vendedor, y cuándo va a entregarlo. También recogerá cuánto
dinero le va a pagar al vendedor y cuándo se 1o va apagar. Debería incluir
penalizaciones por ambas partes en caso de incumplimiento.
Además de estas cuestiones básicas, la Tabla 28.2 lista un conjunto de
otras cuestiones a considerar antes de que firme nada.
Tabla 28.2. Consideraciones sobre contratos
tr ¿Cuáles son los productos (aparte del propio software) que se derivarán de
la eiecución del contrato (descripción de la arquitectura, descripción del *
diseño, código fuente, documentación en línea, documentación externa,
plan de prueba, casos de prueba, resultados de las pruebas, métricas de t
calidad, documentación de usuario, plan de mantenimiento)? I
i
E ¿El contrato contiene puntos sobre las revisiones periódicas y la
comprobación del progreso del vendedor? t
B ¿El contrato incluye una especificación detallada de los requerimientos? t
D ¿El contrato permite cambios en los requerimientos? hd
u ¿Quién retiene la propiedad o tiene derechos sobre el código original

escrito para el proyecto?
tr ¿Quién retiene la propiedad o tiene derechos sobre el código sacado por el
vendedor de su biblioteca de código?
D ¿Proporcionará el vendedor documentación sobre el código sacado de su
biblioteca de código?
tr ¿Quién tiene la propiedad o tiene derechos sobre el código utilizado
perteneciente a la biblioteca de código propia?
B ¿Quién es responsable del mantenimiento del código, incluyendo el código
suministrado originalmente por su organizactón?
LI Si el vendedor es responsable de 1a corrección de defectos, ¿el contrato
especifica escenarios críticos de reparación y tiempos de reacción?
tr ¿,El vendedor tiene ei derecho de vender e1 software desarrollado para usted
a otros clientes?
ü Si le da código fuente al vendedor para que lo incluya en su producto, ¿el
vendedor tiene restringidos 1os derechos de reutilización de este código
fuente en otros productos o ia venta de este código fuente a otros clientes?
tr ¿Quién obtiene los derechos sobre e1 código fuente si el vendedor se
declara insolvente? ¿Puede poner una cláusula de salvaguarda sobre el
código fuente para que pueda obtenerlo si se da este caso?
(continúa)
Tabla 28.2. (Continuación\
tr ¿Necesitará darle herramientas propias al vendedor para su uso? ¿Sus

derechos sobre estas herramientas están protegidos?
tr Si el vendedor usa herramientas para construir el producto, ¿estas
herramientas le serán entregadas al final del proyecto? ¿euién las tendrá s_
se le entregan?
tr ¿Son los desarrolladores de su organización los que interaccionan con el
vendedor para firmar los acuerdos? ¿Cuáles son las implicaciones de que e
vendedor haga esto? ¿Esto restringirá la capacidad de su organización de
desarrollar sus propios productos en un futuro?
tr ¿E1 vendedor tiene prohibido contratar desarrolladores de su
organización?
tr ¿Su organización tiene prohibido contratar desarrolladores de los
vendedores? ¿Aun en el caso de que el vendedor se declare insolvente?
tr ¿El vendedor pide que haya un mensaje de licencia que contenga su
nombre en la pantalla inicial, en la ventana Acerca de, en las pantallas de
ayuda y/o en la documentación impresa?
tr ¿Cuáles son los criterios de aceptación del producto final? ¿Quién es el
responsable de determinar la aceptabilidad? ¿Qué mecanismos protegen a
ambas parles frente a desacuerdos respecto de la aceptabilidad del producto
entregado?
tr Si el software se va a dar bajo licencia, ¿cómo se van a controlar las cuotas
de licencia? ¿Se permitirá al vendedor incrementar las licencias para
versiones futuras del producto? Si es así, ¿en qué cantidad?
28.2. Gestión de los r¡esgos del desarrollo externo

El desarrollo externo puede ser un método útil, pero presenta algunos ries-
gos bien conocidos, así como implicaciones a nivel de toda la organización.
Pérdida de visibilidad. Probablemente, el riesgo más significativo aso-

ciado con el desarrollo externo es la pérdida de visibilidad necesaria para
ver el progreso del proyecto. No es raro que proyectos que informan cons-
tantemente que van a tiempo hasta el día que se supone que tienen que
entregarse, tengan de repente un retraso de varios meses en la planificación.
Asegúrese de que su contrato con el vendedor incluye comprobaciones
periódicas y significativas del progreso.
Transferencia de exper¡encía fuera de su organ¡zación. Uno de

los riesgos principales del desarrollo externo consiste en que transfiere ex-
periencia sobre el área del producto fuera de su propia organización. como
resultado, suceden dos cosas: su capacidad para desarrollar software de

este tipo se ve disminuida, incrementando además el conocimiento del
vendedor sobre sus datos y algoritmos. La sensrbilidad de esta transferen-
cia depende de la respuesta a esta pregunta: <¿Este producto software debe
considerarse como parte del núcleo de nuestro negocio?> Si es así, el de-
sarrollo externo puede resultar útil a corto plazo. pero reducirá su posi-
ción competitiva a largo plazo.
Aquí tiene algunas directrices para determinar cómo considerar si un
producto forma parte del núcleo de su negocio:
o ¿Cómo es de importante para su organización mantener la capaci-

dad técnica de desarroliar softu'are en este área?
o ¿Este software le da actualmente a su organizaciónuna ventaja com-
petitiva significativa?
o Si su organización decide ahora dejar de desarrollar software en
este área, ¿cuál es la posibilidad de que quiera volver a hacerlo
posteriormente?
o ¿Cuál será el coste de volver a desarrollar posteriormente?
o ¿Su software contiene datos de la empresa u otros datos propios?
o ¿Vende productos basados en características propias de este soft-
ware?
o ¿El desarrollo de software es más efectivo en su empresa que el de
los competidores? ¿Es suficiente para considerar esto una ventaja
competitiva?
o ¿Cuál es el tiempo que tarda en poner el software en el mercado en
comparación con sus competidores?
o ¿La calidad de su software es mejor que la de sus competidores?
Si contesta <sí> a la mayoría de estas preguntas, el desarrollo externo

no le conviene a largo plazo. Si contesta ((no)) a la mayoría de estas pre-
guntas, su proyecto es un buen candidato para el desarrollo externo.
Pérdida de moral. si el proyecto que va a desarrollar extemamente es un

proyecto en el que les hubiera gustado rrabajar a sus propios desarrolladores,
la transferencia de este proyecto fuera de la organización puede afectar
negativamente el rendimiento de los desarrolladores en otros proyectos.
Además, el desarrollo externo puede dar a los desarrolladores la impresión
de que sus propios puestos están en peligro, lo que puede llevar a ,rnu bu¡udu
generalizada de productividad en toda su organización de desarrollo.
Pérdida de control en programas futuros. ,{1 transferir el desarro-

l1o de un programa a una organización externa, puede perder la capacidad
de ampliar posteriormente el programa. Es probable que su equipo técni-
co no esté famlliarizado con el código desarrollado por la empresa externa.
El vendedor podría realtzar elecciones en el diseño o la implementac,:-

que limiten la flexibilidad futura. Dependiendo de los detalles de su con:"-
to, podría perder el derecho a modificar el programa por el que ha pagac -
O podría no tener derechos para acceder al diseño o al código fuec..
Asegúrese de que su contrato le ofrece la flexibilidad que necesita.
Compromiso de informac¡ón confidenc¡al. Asegúrese de que ider-

tifica datos y algoritmos propios, y que su contrato asegura que esta prc-
piedad intelectual queda escrupulosamente protegida.
28,3. Efectos secundarios del desarrollo externo

El desarrollo externo tiene dos efectos secundarios beneficiosos.
Descanso merecido. E1 desarrollo externo de un proyecto puede d-.=
un respiro a su plantilla. Si sus desarrolladores han estado trabajando ei -:
proyecto tras otro, podrían ver muy bien la oportunidad de descansar,v rie- ":
que alguien saque 1as castañas del fuego durante un tiempo. E1 desarr¡---
extemo puede traer un cambio agradable en la rutina, y sus desarrollado::;
pueden beneficiarse de las relaciones con otra empresa de desarrollo ¡:
software.
Reducción de las fluctuaciones de personal necesario. El d::=-

rrollo externo elimina la necesidad de contratar personal para un prLa\ -;:L:
que corre Prisa.
28.4. lnteracciones del desarrollo externo con otros

métodos
Por lo que respecta al cliente, el desarrollo externo efectivo es un e'.:- -
cio de gestión eficaz de proyectos (Sección 4.1) y gestión de riesgo. '-- r-
pítulo 5), y necesita estar especialmente pendiente de estas actirri=:=.
Aparte de esto, el método del desarrollo externo no interacciona con J':-:
métodos para el desarrollo rápido.
28.5. Puntos cruc¡ales del desarrollo externo

No se dispone de muchos datos cuantitativos sobre el éxito o el fraca. -
contratos de desarrollo externo, pero los informes esporádicos hai .
favorables. Por ejemplo, Capers Jones informa que la productivid.:;
DATOS REALES
desarrollo externo suele ser el doble respecto a la del desarrollo proF--
las aplicaciones bancarias de Nueva Inglaterra (Jones, 199 1)'
Capítuto 28: Desarrollo externo (Outsourcing) 541
28.6. Claves para el éxito en el uso del desarrollo externo

Éstas son las claves para tener éxito en el uso del desarrollo externo:
. Seleccionar cuidadosamente la empresa elegida para el desarrollo

externo.
o Redactar cuidadosamente el contrato con la empresa.
¡ Planificar la gestión del proyecto externo ai menos con el mismo
cuidado que empleariapara un proyecto propio.
o Haga que la comunicación con la empresa sea una cuestión priori-
taria, tanto de forma electrónica como en persona.
o Realice un trabajo de especificación de requerimientos igual o mejor
del que haríaparaun proyecto propio (a menos que la especificación
de requerimientos sea uno de los puntos fuertes del vendedor).
. Asegúrese de que el desarrollo externo del proyecto de desarrollo
rápido entra dentro de los intereses de su organización a largo
plazo.
Marciniak, John J., y Donald J. Reifer: Softwctre Acquisition Management.
New York: John Wiley & Sons, 1990. Marciniak y Reifer exploran
detalladamente las consideraciones existentes por parte del contratan-
te y el contratado en las relaciones del desarrollo externo de software.
El libro tiene un fuerte enfoque ingenieril, y describe cómo facturar el
trabajo, escribir contratos y gestionar proyectos de desarrollo externo
desde el principio al fin.
Humphrey, W. S., y W. L. Sweet: A Method for Assessing the Software
Engineering Capabilíty* of Contractors. SEI Technical Report CMU/
SEI-87-TR-23, Pittsburgh: Software Engineering Institute, I 987. Este
informe contiene más de 100 cuestiones detalladas que puede usar para
estimar la capacidad de una empresa de desarrollo de software. Las
preguntas se dividen en las categorías de estructura de la otganiza-
ción, recursos, personal y formación, gestión de la tecnología, están-
dares y procedimientos documentados, métricas del proceso, análisis
y control de datos, control del proceso y herramientas y tecnología.
La evaluación de empresas de desarrollo ha sido uno de los trabajos
fundamentales del Software Engineering Institute, y este informe tam-
bién describe un marco de trabajo interesante que puede usar para
evaluar las capacidades de desarrollo en general de un vendedor.
Humphrey, Watts S.: Managing the Software Process. Reading, Mass.:
Addison-Wesley, 1989. El Capítulo 19 está dedicado a la contrata-
ción de software. Contiene directrices interesantes para establecer una
relación con un vendedor, desarrollar un conjunto de requerimie':nuc

controlar el progreso, controlar la calidad y gestionar a los conlm*
dos a diferentes niveles de competencia.
Dedene, Guido, y Jean-Pierre De Vreese: <Realities of Off-Shore R.:m.
gineering>, IEEE Software, enero 1995,35-45. Contiene un es.,j'.¡u
interesante sobre un caso de desarrollo externo de dos pro]€ctr-\ ltc
software al otro lado del océano.
29
Negociación
conveniente
La negociación conveniente es una estrategia de negociación basada

en mejorar la comunicación y en la creación de opciones satisfactorias
para todos, en lugar de basarse en los trucos de negociación. Puede
utilizarse durante el análisis de requerimientos, la creación de la plani-
ficación, las discusiones sobre cambio de prestaciones y en otras oca-
siones a lo largo de un proyecto. Sus beneficios para el desarrollo rá-
pido se derivan de clarificar las expectativas e identificar exactamente
lo necesario con el objetivo de preparar el proyecto para tener éxito El
uso eficaz de la negociación conveniente depende de la separación de
las personas del problema, de centrarse en los intereses. no en las
posiciones; de Ia invención de opciones para el beneficio mutuo y de la
insistencia en el uso de criterios objetivos. Puede usarse en cualquier
tipo de proyecto.
Eficacia
Reducción potencial de la planificación nominal: Ninguna
Riesgos principales
Ninguno.

Ninguno.
Para más información sobre la negociación conveniente, véase lq Sec-

ción 9.2, <Disminución de la presión de la planificación>.
543
30
Entornos productivos
El desarrollo de software es una actividad altamente intelectual que

requiere largos períodos de concentración inlnterrumpida. Los entor- .wá,ffi
nos productivos ofrecen a los desarrolladores una protección frente al
ruido y a las interrupciones necesaria para trabajar de forma efectiva.
ffi*ffiffiffiffi
El uso de entornos productivos puede beneficiar cualquier tipo de pro-
yecto (de gestión,
ffiffir
"prét-á-porter" o de sistemas). Además de mejoras ffi*iffiffiffi¡
en la productividad, algunas organizaciones han experimentado mejo-
ras en la moral de los desarrolladores y en las tasas de retención des-
pués de implantar entornos productivos.
ffi¡
ffiffiffiffi;
ffi,ffiffiffiffiffi;
Eficacia
Efecto sobre el riesgo de la planificación: Sin -efecto
Posibilidad de éxito a largo plazo: Muy buena
Riesgos principales
. Pérdida de productividad por mejoras en los despachos orientadas
al estatus.
o Tiempo de transición.
. Repercusiones políticas del trato preferente a los profesionales del
software.
' Requiere un pequeño incremento en er coste a cambio de un gran

aumento de la productividad.
545
Si estuviese metido en el negocio del petróleo, antes de ganar u. :- tr

necesitaría localizar un yacimiento de petróleo, hacer u.r ug.r;.ro en ;_ ¡r.*-
1o, bombear e1 petróleo, refinarlo, cargarlo en barcosl camit:.. :,r
barriles y venderlo. Parte del beneficio de su negocio estaría de:::-::L-
nadopor la eficiencia con la que bombeara er petróleo del subsu;_-
-r
su técnica de bombeo dejara el 50 por 100 de petróleo en ei s;:¡-r:
lo, también estaría dejando el 50 por 100 de sus posibles ingresos :r- r
tierra.
No se puede bombear el software de un agujero en er suero. Las :¡-;*-
vas de software de un país se encuentran predominantemente dentr¡ :*
cerebro de los desarrolladores de software de dicho país, y la extrac;.:,,r
de este software de estos cerebros requiere la misma precisión que i" :. -
tracción correcta de petróleo de un yacimiento.
Paradójicamente, la mayoría de desarrolladores trabaja actuairr;- -r
bajo condiciones que parecen estar diseñadas prácticamente para er i:.: i
extracción de software que funcione de sus cerebros. Más del 70 por -.r
de todas las organizaciones de software trabajan en despachos aglon:;:l-
dos, y el tiempo medio entre interrupciones en esas condiciones es
-*:
sólo unos 11 minutos (Jones, 1994).
A diferencia de la mayoría de tareas de gestión, que están basadas
-
interrupciones y que sobreviven y se nutren de las interrupciones frecuenl;¡.
las tareas de desarrollo de software requieren rargos péríodos de conc-:.-
tración ininterrumpida. como generalmente los directivos no necesi--:
largos períodos ininterrumpidos para rearizar su trabajo, las peticiones ¡-
los desarrolladores que solicitan tranquilidad y silencio pu.d"n pare;::
peticiones de un trato preferencial. pero generalmente, los desarrollac:*
res están muy motivados, y lo que realmente están pidiendo es tener ur--.
condiciones que les permitan frabajar eficientemente.
Tiempo de concentración. Durante las etapas de análisis y disei;.

el desarrollo de software es una actividad efímera, conceptuál. corr-:
cualquier actividad conceptual, la calidad der trabajo depende de la c"-
pacidad del trabajador para mantener un <estado de fluiJez>: un estac,:
relajado de plena inmersión en un problema que facilita la comprensic,:_
del mismo y la generación de soluciones (DeMarco y Lister, tOV¡. f z
conversión de ondas cerebrales en software de computadora es un prc.-
ceso complicado, y los desarrolladores trabajan mejor durante las hora.
en las que se encuentran en este estado de concentración sin esfuerzc
Los desarrolladores requieren l5 minutos o más para entrar en un es-
tado de fluidez, que puede perdurar entonces duranle varias horas, has*
que la fatiga o la interrupción lo detengan. Si los desarrolladores
son
interrumpidos cada 1l minutos, posibremente no entrarán nunca en un
estado de fluidez, y por tanto, difícilmente alcanzarán sus niveres
de
productividad.
Capítulo 30: Entornos productivos 547
REFERENC\A Necesidades de hig\ene. Además de rncrementar \a capacidad de en-

CRUZADA
trar en un estado de fluidez, \a imp\antacton de entolnos ploducü\os ac-
sobre las necesidades túa también sobre un gran factor de motivación para los desarrolladores
de higiene, véase de software. Un despacho adecuado para el trabajo de un desarro.lladot es
"Factores de higiene", un factor motivacional de <higiene); es decir, un despacho adecuado no
en la Sección I1.4.
incrementa la motivación o la productividad, pero por debajo de un cierto
umbral, un espacio de trabajo inadecuado puede elosionar sefiamente la
motivación y la productividad.
Para los desarrolladores, la necesidad de entornos productivos es ob-
via y básica. Los entornos productivosSe encuentran en 1a misma categoría
de motivación que una iluminación adecuada, un suministro e1éctrico fia-
ble y un acceso a unos servicios dignos. Una organización que no ofrece
un entorno en el que los desarrolladores puedan trabajar efectivamente.
no está sentando las bases que sus desarrolladores necesitan pala ser
productivos, y los desarrolladores tienden a \.er estaS organizaciones como
ii estuvieran trabajando irracionalmente contra sus propios intereses. Los
buenos desarrolladores tienden a ser atraídos por organizaciones que
ofrecen buenos entornos de trabajo, en los que puedan ser productivos.
Los desarrolladotes que pelmanecen en entornos menos productivos tien-
den a perder su motivación y su moral, y la productividad se resiente (véase
la Figura 30.1).
Figura 30.1. DILBERT re7roduc¡do por autor¡zación de United Feature

Syndicate, lnc.
Generalmente, los desarolladores, responsables de equipo y directii c.

de bajos niveles no se encuentran en la posición adecuada para traslad-
un equipo a despachos más productivos, pero si su proyecto se encuenrr¿
bajo presión de planificación y sus directivos comprenden la necesidad ti-
mejoras en la productividad, podría intentar negociar el traslado a despachos
más silenciosos y tranquilos, prometiendo una mayor productividad.
30.1. Uso de entornos productivos

Los entornos productivos presentan las siguientes características:
o Un espacio mínimo aproximado de 9 metros cuadrados por desa-

rrollador.
o Un espacio de trabajo mayor de 1,5 metros cuadrados para pode:
tener libros, carpetas, notas, listados de código fuente y materia-
informático sobre el mismo simultáneamente. Los soportes de las
mesas deben estar diseñados para no obstaculizar los movimientos
de las piernas. El espacio de trabajo debe ser configurable a 1,-.
preferencias de cada desarrollador individual (por ejemplo, ten-:
el ala a la izquierda o a la derecha).
o Algún medio para detener las interrupciones telefónicas. Un inte-
nuptor de <desconexión del timbre> combinado con mensajes de
voz o la posibilidad de desviar las llamadas a un auxiliar adminis-
trativo son las soluciones más comunes. La recomendación del uso
del correo electrónico en lugar de llamadas telefónicas dentro de
una organización también es una medida efectiva para prevenir las
interrupciones telefónicas.
o A1gún medio para detener las interrupciones en persona. Un despa-
cho individual con una puerta es la solución más común. La política
de la organización debe permitir y animar a los desarrolladores cerrar
sus puertas; algunas empresas con políticas de <puertas abiertas,,
frenan esta práctica (aparentemente inconscientes de que esto per-
judica la productividad del desarrollador).
. Algún medio de eliminar el ruido no deseado. Las conversaciones
sociales y de negocios no deben tener lugar en el área de trabajo de
los desarrolladores, y el sistema de megafonía no debe interrumpir
para anunciar nada que sea menos serio que un incendio en el edificio.
De nuevo, un despacho privado con puerta es la solución más
habitual.
o Un mínimo de 5 metros lineales de estanterías.
Además de estos factores, presentes en informes publicados, mi expe-

riencia me lleva a pensar que hay otros factores adicionales importantes:
REFERENCIA Despachos con ventanas al exterior. La vista no tiene que ser es-
CRUZADA
Para más detalles pectacular, y la ventana puede estar tranquilamente enfrente de otra
sobre otros informes ventana externa, pero debe ofrecer la sensación de acceso al mun-
publicados sobre
entornos product¡vos, do exterior fuera del despacho, y debe permitir que el desarrolla-
véase la sección dor pueda fijarse periódicamente en aigo que esté a una distancia
"Base de los entornos superior a 24 pulgadas. En un despacho. miré por 5 ventanas bus-
productivos", ¡ncluida
poster¡ormente en esle cando una vista exterior, y esto era suficiente para descansar mis
capítulo. ojos y ofrecer un respiro en el uso de la computadora. E1 trabajo
con altas tecnologías requiere un entorno <sofisticadoll para cuidar
la moral (Naisbitt, 1982).
a Unapizarra de aproximadamente 1,2 metros cuadrados.
a Un tablón para notas de aproximadamente 1,2 metros cuadrados.
a Un acceso conveniente al resto de los miembros del equipo del pro-
yecto. El equipo debe tener oficinas cercanas; situarlos en distintas
plantas puede introducir demasiada <distancia> entre los miembros
del equipo.
a Un acceso conveniente a una impresora de alta velocidad.
a Un acceso conveniente a una fotocopiadora con alimentación auto-
mática de originales.
Un acceso conveniente a salas de reuniones. Los despachos priva-
dos parecen estar muy lejos de la necesidad de salas de reuniones,
pero las salas de reuniones siguen siendo necesarias siempre que
se reúna un grupo de tres o más personas.
Acceso conveniente a material común de oficina: bolígrafos, lápices,
minas, rotuiadores de marcar, ciips, gomas, grapas, cinta adhesiva,
blocs de notas, cuadernos, archivadores de anillas, disquetes en blan-
co, rótulos para disquete, cintas para copias de seguridad, notas
adhesivas de diversos tamaños, sobres estándar, sobres grandes,
sellos, archivadores, ca{petas archivadoras, carpetas colgantes, quita-
grapas, toallas de papel, rotuladores parapizarra blanca, limpiador
para pizarra blanca y limpiador para pantallas.
La Figura 30.2, de la página siguiente, muestra algunos de los diseños

de oficinas productivas desarrollados para el centro de Santa Teresa de
IBM, objeto de muchas miradas.
30.2. Gestión de los r¡esgos de los entornos productivos

La implantación de entornos productivos no es una actividad parricularmen-
te arriesgada, pero no está de más describir los pocos riesgos que imphca.
Pérdida de productividad debida a meioras de los despachos orien-

tadas al estatus. Un posible fal1o en la confieuración de los enrornos
Figura 30.2. Diseños de las oficinas productivas del laboratorio de Santa

Teresa de lBM. Los desarrolladores informaron que su productividad se
incrementó alrededor de un 1 1 por 100 al desplazarse a estos despachos.
Copyright 1978 lnternational Business Machines Corporation. Reproducido
con autorización de IBM Systems Journal, vol. 17, núm. 1.
productivos consiste en que la directiva puede tratar \a mejora en el en-

tomo de los despachos como una mejora del estatus en lugar de una mejora
de productividad. En algunas organizaciones, los despachos individuales
son símbolo de estatus, y en ocasiones la directiva interpreta la petición
de los desarrolladores de despachos individuales como una petición corpo-
rativa de mejora del estatus. Como resultado, las organizaciones gastan
dinero en algunos casos en mejoras estéticas que no mejoran la producti-
vidad, y que en ocasiones la disminuyen. La directiva podría cambiar las
paredes de los cubículos de los desarrolladores y ponerlas de cristal tin-
tado en lugar de unos paneles tapizados estándar. Podría asignar a los
desarrolladores cubículos mayores con pequeñas mesas de reuniones.
Podría sustituir el mobiliario estándar de los cubículos con muebles he-
chos en maderas nobles.
Aunque con buena intención, cada una de estas medidas puede perju-
dicar probablemente más a la productividad que mejorarla. El cristal tintado
reduce la de por sí ya limitada intimidad disponible para un desarrollador
que trabaja en un cubículo. Las mesas de reuniones incrementan la posi-
bilidad de tener reuniones imprevistas en un cubículo, lo que incrementa
las distracciones de los desarrolladores que se encuentran en cubículos
Capítulo 30: Entornos product¡vos 551
adyacentes. El mobiliario antiguo de madera reduce el movimiento de las

piernas y también eLáreaútil de trabajo dentro del cubículo. Todavía no he
encontrado un desarrollador que no prefiera trabajar en dos mesas grandes
plegables en lugar de en una pequeña mesa de despacho antigua finamen-
te rematada.
Si no se puede disponer de verdaderos despachos productivos, unas
medidas más oportunas para incrementar la efectir-idad serían elevar la
altura de los paneles de los cubículos de 1.5 metros a 2 metros, e incotpo-
rarles puertas. Asegúrese de que sus mejoras de los despachos siguen cen-
tradas en la productividad.
Tiempo de transición. E1 cambio de despacho implica prácticamente

siempre varios problemas administrativos que tienen un efecto adverso
sobre la productividad. He visto problemas en la transferencia de antiguos
archivadores y otros materiales del antiguo despacho al nuevo, y problemas
con los nuevos sistemas telefónicos, de mensajes de voz, instalaciones de
redes de computadoras, fiabilidad de la alimentación eléctrica, entrega
del equipamiento y mobiliario de oficina y varias otras cuestiones.
Además de los problemas administrativos, existe el inevitable tiem-
po de adaptación asociado con una mudanaa o remodelación. Los desarro-
lladores pierden tiempo empaquetando y desempaquetando. Las personas
sucumben a la tentación de reorganizar sus archivos y estanterías en la
mudanza. Si la mudanza es a un nuevo edificio, la gente emplea tiempo
en explorar el nuevo entorno. Y en ocasiones existe una pérdida de moral
por parte de los desarrolladores que no tienen los nuevos despachos que
esperaban.
REFERENCIA Teniendo en cuenta todos los factores, debe contemplar un mínimo
CRUZADA
de una semana de trabajo de una persona por cada desarrollador que cam-
En ocasiones, puede
incrementar la bie de ubicación. El desplazamiento a despachos productivos producirá
productividad de un beneficios a largo plazo, pero la etapa fina1 de unproyecto bajo presión
proyecto en modo de
recuperación es generalmente una mala ocasión para hacer una mudanza de este tipo.
desplazándose a una Un traslado así debe realizarse generalmente entre proyectos o en las fa-
zona de trabajo mejor.
Para ver comentarios
ses iniciales de un nuevo proyecto.
sobre la idea general,
consulte "Haga todo lo
que sea necesario para
Repercusiones políticas deltrato preferenc¡al a los profes¡onales
recuperar la moral del software. En una organizaciónque generalmente no destina oficinas
del grupo", en la individuales a su personal, los miembros de la plantilla que no están rela-
Sección 16.2.
cionados con el software pueden interpretar la adjudicación de despachos
individuales a los desarrolladores del software como un trato preferencial.
Puede mitigar este riesgo explicando las necesidades especiales de los
desarolladores de soffware a otros miembros de la plantilla que se sientan
menospreciados, o poniendo a los desarrolladores de software en un área
separada en la que las diferencias en la asignación de despachos sean menos
perceptibles.
F
30.3. Efectos secundarios de los entornos productivos

Los desarrolladores aprecian las mejoras en sus condiciones de traba--:
-,¡r
empresas que adoptan entornos productivos han encontrado que ::tr.fi
una experiencia positiva sobre la satisfacción del desarroilador v las --o,¡;usi
de retención (Boehm, 1981)
30.4. lnteracción de los entornos productivos

con otros métodos
Puede usar los entornos productivos conjuntamente con cualquier l::
método orientado a la productividad. Su efecto es independiente de -:x
efectos de los restantes métodos.
30.5. Puntos cruc¡ales de Ios entornos productivos

Tom DeMarco y Timothy Lister patrocinaron una competición de progra-
mación en la que 166 desarrolladores se enfrentaban valorando tanto la cai:-
dad como la velocidad (DeMarco y Lister, 1985). Los competidores ofi¡-
cieron información sobre las características de sus entomos físicos d;
trabajo. Y se vio que los desarrolladores que habían quedado en el grupo de-
25 por 100 con mejores resultados tenían despachos mayores, más sirencio-
sos y tranquilos, y sufrían menos interrupciones de personas y llamadas
telefónicas que el resto del grupo. La Tabla 30.1, de lapágina siguiente.
contiene un resumen de las diferencias en entornos de despachos entre los
mejores y los peores en la competición.
DeMarco y Lister creen que esta correlación entre el entorno de trabajo
y la productividad puede ser el resultado de un factor oculto, derivado de
que los mejores desarrolladores podrían tener de forma natural mejores
despachos, porque han sido ascendidos. pero cuando examinaron con
más detalle los datos, vieron que no era así: desarrolladores de las mismas
organizaciones disponían de recursos similares y su rendimiento seguía
siendo diferente.
Los datos muestran una fuerte correlación entre la productividad
y la calidad del entorno de trabajo. Los desarrolradores del grupo de ca-
DATOS REALES
bezatenían una productividad 2,6 veces mejor que los desarrolladores
del grupo de cola. Esto sugiere que pasar de un entorno correspondien-
teal 25 por 100 de cola a un entorno como el der25 por 100 de cabeza
puede redundar en una mejora superior al 100 por 100 en productividad.
En los años setenta, IBM estudió las necesidades de ros desarrollado-
L
Tabla 30.1 . Diferencias en entornos de trabajo entre los mejores y los peores
participantes en una competición de programación
Factor de entorno Primer 25o/o Último 25Yo
Superficie 9 m.2 5 m.2
Despacho aceptablemente silencioso 57oA si 29Vo si
Espacio aceptablemente privado 62% si 19% si

Teléfono desconectable 52oA sí 10% sí
Las llamadas pueden desviarse a sistemas
de mensajes o a un administrativo 76% sí 19oA si
Interrrupciones lrecuentes e innecesarias 38Yo sí 760A si
El entorno de trabajo hace 57oA si 29% sí ff

s
que los desarrolladores se sientan bien
Fuente: Tomado de Developer Performance and the Effects of the I4torkplace (DeMarco y $
Lister,1985).
res, creó unas directrices de arquitectura, y diseñó las instalaciones de

Santa Teresa pensando en los desarrolladores. Los desarrolladores parti-
ciparon en todo el proceso de diseño. El resultado ha sido que 1as instala-
ciones de Santa Teresa son consideradas como las mejores en las encues-
tas anuales realizadas en la compañía. IBM informa que las instalaciones
mejoraron la productividad alrededor de un 11 por 100 1e IBM no partía
del grupo del25 por 100 de cola) (Jones. 1994).
En mi zona, las oficinas suelen costar de 10 a 20 dólares por metro
cuadrado al mes. El tiempo del desarrollador incluvendo sueldo v primas.
cuesta entre 4.000 y 10.000 dólares al mes. El coste medio de pasar del
grupo de cola al grupo de cabeza (de 5 a 9 metros cuadrados 1' de un
espacio más económico a otro más caro) sería de 110 dólares al mes por
desarrollador. El incremento medio de la productividad se calcula multi-
plicando la productividad por un factor de 2,6,1o cual nos daría una cifra
de alrededor de 11.000 dólares al mes.
Decidir ahorrar en el espacio dedicado a despachos equivale en mi
opinión a <desperdiciar tiempo de desarrollo y recoger espacio de despa-
chos> (con un factor de alrededor de 100).
En conclusión, una organización que disponga en este momento de un
entorno dentro de la media puede esperar probablemente una mejora en su
productividad de desarrollo de un 20 por 100 o más situando a sus desarro-
lladores en entornos productivos. Para organizaciones que se encuentren
por debajo de la media o encima de la media, la ganancia puede ser dis-
tinta según el caso.
554 ]esarroito y gestión de proyectos informáticos
30.6. Claves para el éxito en el uso de entornos

productivos
Éstas son las claves para el uso con éxito del método de los entornos
ductivos:
Evitar mejoras de los despachos orientadas al estatus. Céntrese -

las características importantes de los despachos, como la intir--
dad, la ausencia de ruidos, las superficies de trabajo adecuadas 1 -r,
capacidad de frenar las interrupciones.
o Planifique el cambio de despachos para un momento que no resu-::
crítico en el proyecto. Lo mejor es cambiar de despachos entre prL-
yectos.
o Desarrolle un plan para controlar las repercusiones políticas de a.'c*
modar a los desarrolladores en despachos individuales.
DeMarco, Tom, y Timothy Lister: Peopleware: Productive Projects an;
Teams. New York: Dorset House, 1987. Este libro trata de los factores
humanos que influyen en la ecuación de la programación, incluyendr
la necesidad del tiempo de concentración y los efectos en la producti-
vidad de los entornos de trabajo.
McCue, Gerald M.: <IBM's Santa Teresa Laboratory-Architectural Design
for Program Developments>, IBM Systems Journal, vol. 17, núm. 1.
1978,4-25. McCue describe el proceso usado por IBM para crear el
complejo de oficinas de Santa Teresa.
f":*--,-
31
Lenguajes para
desarrollo
rápido (LDR)
"Lenguaje para desarrollo rápido' es un término general que se refiere
a cualquier lenguaje de programación que ofrezca una implemenia-
ción más rápida que la tradicional de los lenguajes de tercera generación,
como c/c++, Pascal o Fortran. Los lenguajes para desariollo rápido
(LDR) producen su ahorro reduciendo la caniidad de trabajo necesario
para construir un programa. Aunque el ahorro se obtiene durante la
construcción, la posibilidad de acortar el ciclo de construcción tiene
implicaciones en todo el proyecto: los ciclos de construcción más corlos
hacen viables los métodos de ciclo de vida incrementales, como el pro-
totipado evolutivo. como, a menudo, los LDR no tienen un rendimiento
de alto nivel, restringen la flexibilidad y están limitados a tipos especí-
ficos de problemas, generalmente se adaptan mejor para el desarrollo
de software de gestión interno y de software de disiribución limitada
más que a software de sistemas o
"prét-á-porter,,.
Eficacia
Efecto_sobre el riesgo de la planificación: Aumenta el riesgo
Riesgos principales
. Síndrome de la panacea y sobreestimación del ahorro.
¡ Fallo al escalar a proyectos grandes.
. Refuerzo de malos hábitos de programación.

r sacrifica alguna flexibilidad en el diseño y la implementación a cam-
bio de reducir el tiempo de implementación.
. El aumento de velocidad en la construcción soporta el prototipado
evolutivo y los métodos incrementales relacionados con éste.
555
Si utiliza un taladro automático, material preconstruido y un puh e::-' : ,'

de pintura, puede montar una caseta de perro mucho más rápido ü-*-
-l
persona que utilice un martillo, tablillas de madera y una brocha, _ .:i-
bién es cierto que es más probable que el usuario de herramientas p,:;-- -
sas tenga que acercarse al hospital para recibir atención médica de -: -*-
gencia. Y por 1o que respecta ala calidad,las herramientas potenres :-:rfl
sustituidas o complementadas de todos modos por las antiguas herran:::--i.,
manuales. El uso de herramientas potentes en el software es muv s_,: ¡
en 1o que respecta a las recompensas, los riesgos y los equilibrios"
Al decir <lenguaje de desarrollo rápido> me estoy refiriendo " -:r
amplia clase de entornos de desarrollo que ofrecen una implemeit:;: l
más rápida de la ofrecida por lenguajes de tercera generación, rale s ; -:: r
Basic, CIC++, Cobol, Pascal y Fortran. Éstos son los tipos de enton- ¡ -c
los que estoy hablando:
o Lenguajes de cuarta generación (4GL), como Focus y Rarn,.

r Sistemas de gestión de bases de datos, como Microsoft Acce ..
crosoft FoxPro, Oracle, Paradox y Sybase.
Lenguajes de programación visual, tales como Borland Delc'-- - ,,
Visual Objects, Microsoft Visual Basic, Realizer y Visual -i_;.
Herramientas especifr.cas de\ d,omimo, tales como hojas de ¿. : *r ,
paquetes estadísticos, editores de ecuaciones y otras herra::- .:;¡

que resuelven problemas que en otro caso deberian resolvers¡ :::u-
do un programa informático.
REFERENCIA En este capítulo, me refiero a estos lenguajes como <LDR)):a: *h¡-

CRUZADA
términos similares a 3GL (Lenguajes de 3.u Generación) y 4GL tL;:_..;-
sobre herramientas jes de 4.u Generación). Al hablar de LDR no estoy hablando.::tr-
para productividad en
ficamente de bibliotecas de clases o de funciones, aunque se puedan :: -ir
general, consulte el
Capítulo 15, muchas de las mismas consideraciones al uso de estas herramieni"=
"Herramienlas para Los LDR soportan el desarrollo rápido permitiendo que los i-.--.*
aumenlar la
productividad". lladores construyan los programas con un nivel más alto de abs::":- .n
del alcanzad,o con los lenguajes tradicionales. Una operación que :r-:r: -
taría cien líneas de código en C podría requerir sólo 25 líneas de .-,- ,ni
en Visual Basic. Una operación que podría requerir abrir un arch,-, : i -
tuar un puntero de archivo, escribir un registro y cerrff un archir¡ -: -
puede requerir una única sentencia RESTORE0 en un LDR.
REFERENCIA Como los distintos lenguajes de programación ofrecen tanta c:::!--
CRUZADA
Para más informac¡ón dad en la potencia ofrecida para un mismo número de líneas de ;: : ¡ .
sobre los puntos de gran parte de la industria del software está pasando a usar una:-;- :;
función, véase
denominada <puntos de función> para estimar los tamaños de 1os ::- -- ii*
"Estimación de los
puntos de función", en mas. Un punto de función es una medida sintética del tamaño del prr-;. _-
la Sección 8.3. basada en una suma ponderada del número de entradas, salidas. cf i! -J,
y archivos. Los puntos de función resultan útiles porque le permire: - ::-
5.
Capítulo 31: Lenguajes para desarrollo rápido (LDR) 557
sar sobre el tamaño del programa de un modo independiente del lenguaje.

un lenguaje de bajo nivel. como el ensamblador. requerirá muchas más
líneas de código para implemenrar un punto de función de las necesarias
en un lenguaje de mayor nivel, como C o Visual Basic. Los puntos de
función ofrecen una moneda común para hacer comparaciones entre los
lenguajes.
Los investigadores han podido derivar aproximaciones del trabajo
medio necesario para implementar un punto de función en diferentes len-
guajes. La Tabla 31.1 muestra la relación entre puntos de función y líneas
de código para programas de diversos tamaños. Las líneas de código son
sentencias fuente excluyendo líneas en blanco y comentarios.
Estos datos son aproximados, y algunas de las cifras varían mucho,
dependiendo del estilo de codificación. Por ejemplo, algunas personas
tttilizan C++ s6rns una versión de C con tipos más estrictos, en cuyo caso
las cifras del C++ estarán más cerca de las correspondientes al C en la
tabla. Pero en promedio, las comparaciones entre los diferentes lenguajes
de la tabla nos ofrecen una información importante.
Suponga que tiene un programa de tratamiento de textos cuya espe-
cificación incluye alrededor de 5.000 puntos de función. Según los datos
de la tabla, necesitaría aproximadamente 625.000 líneas de código en C
para implementar el tratamiento de textos, 250.000 líneas de código en
C++ o 150.000 líneas de código en Visual Basic. Implementando un pro-
grama en Visual Basic necesitaría aproximadamente sólo el 25 por 100
del código necesario que para implementar el mismo programa en C es-
tándar. Esta diferencia puede traducirse en un ahorro signrficativo en el
tiempo de desarrollo.
Tabla 31 .1. Conversiones aproximadas de puntos de función a líneas

de código
Tamaño en líneas de código
Tamaño
en puntos Fortran Cobol C C++ Pascal Visual
de función Basic
l 110 90 125 50 90 30
100 I 1.000 9.000 12.500 s.000 9.000 3.000
500 55.000 45.000 62.500 25.000 45.000 15.000
1.000 1.0000 1 90.000 125.000 50.000 90.000 30.000
5.000 550.000 450.000 625.000 250.000 450.000 150.000
Fuente: Tomado de los datos incluidos en <Programming Languages Table> (Jones. I 995a).
558 Desarrollo y gestión de proyectos
En general, al trabajar con un renguaje de muy arto niver se ahor,-,

tanto en la codificación como en el diseño. Los desarrolladores tiende:
a poder escribir aproximadamente el mismo número de líneas de códr-
go al mes, independientemente del lenguaje usado (Boehm, l9B 1; putnar
y Myers, 1992). Cuando usan un lenguaje de mayor nivel, la codifica-
ción es más rápida simplemente porque escriben menos líneas de códigc
para el mismo volumen de funcionalidad. El diseño también es más rá-
pido debido a que una menor codificación implica que hay menos que
diseñar.
En el ejemplo del tratamiento de textos, podría recortar en un 75 por l oir
el número de líneas de código necesarias utilizando visual Basic en luga:
de c. Esto significa que podría reducir el esfuerzo de diseño e implemén-
tación en el mismo porcentaje del i 5 por 100. podría haber otras conside-
raciones que le obligaran a usar c a pesar del posible ahorro ofrecido por
visual Basic, pero si la velocidad de desarrorlo es una consideración im-
portante, como mínimo debe saber lo que está perdiendo.
La Tabla 31.2 muestra los <niveles de lenguaje>> aproximados para
una amplia variedad de lenguajes, más extensa que la incluida en la Ta-
bla 31.1. El <nivel del lenguaje> está pensado para sustituir de forma más
específica los niveles implicados por las frases <lenguaje de 3." generación,,
y <lenguaje de 4.u generación>. se define como el número dé sentencias
en ensamblador necesarias para sustituir una sentencia en el lenguaje de
mayor nivel. Así, en promedio, se necesitarían aproximadamente 2,5 sen-
tencias en ensamblador para sustituir una instrucción en lenguaje c.
o 10 para sustituir una sentencia en Visual Basic.
Las cifras de la Tabla 31.2 están sujetas a un amprio margen de error.
pero son los mejores datos disponibles en este momento, y son suficiente-
mente precisos para soportar esta afirmación: desde el punto de vista de la
velocidad de desarrollo, debe implementar sus proyectos en el lenguaje de
mayor nivel posible. Si puede implementar algo en c en lugar de en ensam-
blador, en c++ en lugar de en c, o en visual Basic en lugar de en c+-.
podrá desarrollarlo más rápido.
La tabla muestra otros datos interesantes. uno de ellos consiste en
que los lenguajes de 3.u generación son todos ellos más o menos
compa-
rables: c, cobol, Fortran y pascal requieren todos alrededor de 100 ins-
trucciones por punto de función. Los 4GL, SGBD, y lenguajes de
programación visual, tales como dBase IV, Focus, Oracle, paradox.
Sybase y visual Basic, también son más o menos comparables entre
sí, necesitando alrededor de 35 instrucciones por punto dé función. Las
herramientas tales como hojas de cálculo (que en ocasiones se ven como
herramientas de programación para usuarios finales) llevan la produc-
tividad al máximo, necesitando sólo un promedio de 6 <instru"riorr.ru
para implementar un punto de función que necesitaría l2g instruccio-
nes en C,
Tabla 31 .2. Niveles aproximados de los lenguajes
DATOS REALES
Instrucciones por
Lenguaje punto de función
Ensamblador I 320
Ada 83 4,5 70
AWK l5 25
C t< 125
C++ 6,5 50
Cobol (ANSI85) ?5 90
dBase IV 9 35
Excel, Lotus 123, Quattro Pro =50 6
y otras hojas de cálculo
Focus 8 40
Fortran 77 J 110
GW Basic 1 ){ 100
Lisp 5 65
Macroensamblador 1,5 215
Modula 2 4 80
Oracle 8 40
Paradox 9 35
Pascal ?5 90
Perl l5 25
Quick Basic 3 55 60
SAS, SPSS y otros paquetes 10 30
estadísticos
Smalltalk 80; Smalltalk/V l5 20
Sybase 8 40
Visual Basic 3 10 30
Fuente: Tomado de 1os datos incluidos en <programming Languages Tables> (Jones, 1995a).
31.1. Uso de LDR

En general, debe seleccionar los LDR específicos usando los criterios
de selección listados en la sección 15.3, <Adquisición de herramientas
para productividad>, e implantarlos usando las directrices descritas en la
Sección 15.4, <Uso de herramientas para productividad>. Ar.::: uu

estas directrices generales,
el modo de usar LDR específicos pi--:= --.
riar de un LDR a otro, y las claves para tener éxito también :--il:r
ser distintas.
31.2. Gestión de los r¡esgos de los LDR

La potencia de un LDR puede ser seductora, y la mayoría de los :r;,¡
"
asociados con el uso de los LDR nacen de no reconocer los límites d- :"'rü
potencia.
REFERENCIA síndrome de la panacea y sobreest¡mación del ahorro. con-,: -;ru

CRUZADA
otras herramientas de productividad, los LDR son propensos a ir 3c,.,r-rr
sobre el síndrome de ñados de afirmaciones exageradas y sensacionalistas. Independienr¡ :r*
la panacea, véase te de las afirmaciones de los vendedores, es poco probable que e- r*
becclon l5.5, "El
síndrome de la potente de los LDR le permita reducir el tiempo de desarrollo com:-:,trL
DáñOCea ". en un 25 por 100. Tenga cuidado con cualquierproducto que afirme
-:::
cosa, o al menos no se vea atrapado por intentar ahorrar todo el tie:::,¡r
que ha promerido.
Aunque pueda ver a través de las afirmaciones de los vendedores :u
pretenden haber inventado la panacea universal y tenga una idea re¿,
=-L
del ahorro en tiempo de diseño y codificación derivado del uso c: -m
LDR, estimar el ahorro final de principio a fin del proyecto es dii: i,
Para unas directrices sobre esta estimación, consulte el apartado <Re¿r-
ción realista del plan>, en 1a Sección 15.4.
Aplicación a proyectos inadecuados. Los LDR no son adecu"::¡
para algunos tipos de productos. El rendimiento del código que gen3:!m
en ocasiones no es adecuado para soportar desarrollo de soñare en tie:_:rn
real o <prét-á-porter>, y en ocasiones los LDR carecen de la flexibir,-r,r
necesaria para implementar interfaces de usuario personalizadas. g-:---
cos, salidas o interfaces con otros programas. En oiasiones, sus req*-:-
mientos pedirán la funcionalidad que el LDR debe soportar, pero una :,-
dentro de su proyecto descubrirá que ar final el LDR no stporta d-.:r
funcionalidad. Los LDR funcionan mejor cuando los requerimientos , :-
nen una cierta flexibilidad, permitiéndole aprovechar las ventajas
de .:r
LDR y evitar sus debilidades.
Fallo a la hora de escalar en proyectos grandes. A menudc. _:r
LDR carecen de los elementos de la ingenierla del software necesa:::s
para soportar grandes proyectos. Las mismas prestaciones del lens--
r
que parecen convenientes en pequeños proyectos (tales como
no r-::i_
que declarar las variables antes de usarias), pueden causar pesadiilas
rr
grandes proyectos o proyectos desarrollados en equipo.
_l
I
Capítulo 31 : Lenguajes para desarrollo rápido (LDR) 561
Estos son algunos de los puntos débiles comunes:
o Tipos de datos poco estricios.

o Pocas posibilidades de es¡ructuración de datos.
. Poco soporte para la modulandad.
. Herramientas de depuración poco potentes o ineristentes.
o Herramientas de edición simples.
. Pocas posibilidades de ilamar a rutinas escritas en otros lenguajes,
o para hacer llamadas desde rutinas escritas en otros leneuajes.
o Falta de soporte de formato libre para el código fuente (es decir.
algunos LDR son más bien como ien-uua_jes orientados a lineas. tipo
Basic o Fortran. en lugar de ser lenguajes orientados a instrucciones.
como C/C++ o Pascai).
o Poco soporte para el trabajo en gmpo, incluyendo la ausencia de
herramientas de control de código fuente.
Para minimizar el riesgo de fallar en proyectos de gran escala. antes

de usar un LDR en un proyecto grande, realice un estudio de viabilidad
para asegurarse de que los puntos débiles a nivel de ingeniería del soft-
ware del LDR no le van a costar más a su proyecto de 1o que va a ahorrar
a lo largo del ciclo de desarrollo y mantenimiento. Sea conservador al
estimar el ahorro que espera obtener. Generalmente, los LDR ahorran tiem-
po, pero si el proyecto es suficientemente grande como para que la plani-
ficación sea un tema a tener en cuenta, es suficientemente grande para
tener cuidado con las limitaciones de un LDR.
Fomento de malas prácticas de programac¡ón. Con los lenguajes

tradicionales de programación, se tiende a incluir dentro de los progra-
mas infraestructura para anticiparse a áreas que no están bien soportadas
por el propio lenguaje. Desarrollará código altamente modular para que
los cambios no se propaguen a 1o largo del programa. Usará estándares de
codificación para hacer que el código sea más legible, y evitará hábitos
reconocidos como perjudiciales, como el uso de sentencias GOTO y va-
riables globales.
Una de las ironías de las debilidades de los LDR consiste en que al
reducir tanto la complejidad le inducen una falsa sensación de seguridad:
le hacen creer que 1o van a hacer todo ellos solos automáticamente. Puede
tener un proyecto muy avanzado antes de darse cuenta de que sigue nece-
sitando cosas como los estándares de diseño y codificación. Cuando ven-
ERROR CLASICO ga a darse cuenta de que los necesita, estará tan metido en e1 pro-v-ecto que
le resultará duro volver atrás para implantarlos en el código. Cuando cho-
que con la pared, 1o hará con fuerza. El trabajo se raientizará. ¡ podria
encontrarse deseando haber utilizado un ienguaje correspondiente a1 ám-
bito de los 3GL.
Esta experiencia es tan traumatizante que

algunos desarrolradores afir-
man que realmente no se ahorra ningún tiempo
al cambiar a un lengua-je
de mayor nivel. En ocasiones, esta afrimacrón
es cierta. La caridal de argu-
nos LDR es baja, y en ocasiones los LDR
no consiguen adaptarse a pro-
yectos grandes.
REFERENCIAS Pero en otras ocasiones, el problema no
CRUZADAS es tanto resultado de los pun_
Para ver los problemas tos débiles de los LDR, sino dé la tendencia
a usar técnicas ,e"ono"idus
asociados con los como malos hábitos en el diseño y la codificación
malos hábitos de de proyectos con LDR.
programación, consulte En este caso, la mara experiencia se debe más
bien al sentimiento experi-
"Construcción", en la mentado por el personar cuando sufre ras rimitaciones
Secc¡ón 4.2, y la de un LDR y tien:
que disminuir la velocidad de desarrollo.
Sección 4.3.
"Bases
Es similar a la experiencia sufric:
del control de calidad._ cuando se ha ido conduciendo a r00 Km/h durante
tto.urlv J.^r"p""r. -.
llega a LLna zona con limitación de velocidad
a 50. Le da la sensacr.-:
de que prácticamente no se está moviendo.
Le parece que si-puar..r
saltar del coche y correr iría más rápido. pero,
evidentemente, no puei:
correr a más de 50 Km/h, y generalmente no podrá
desarroltu. p.ogrur::..
completos en C y en ensamblador más rápidá que
con un Ur"JLlR.
Para evitar el riesgo de ros malos hátitos,
use técnicas de diseñc, ,,
codificación que compensen ros puntos débiles
del LDR. sr ,*r.'or-
equivocarse,hágalo sobrediseñando su programa
y siendo demasiado c---
dadoso con sus esrándares de codificacr¿nl
Éste ;r;i-;;r;;co en ._
que un gramo de previsión vale más que
un kilo de cura.
31.3. Efectos secundarios de los LDR

Los LDR específicos pueden tener influencia
sobre la calidad, facilida¿
de-uso, funcionalidad, y otras características
de ros proou.tor, y'd.b. .or-
siderar estos factores al evaluar productos
específicos LDR.
31-4- lnteracciones de ros LDR con otros métodos

Podemos aplicar prácticamente todas
ras directrices generales para el us.
de herramientas para aumentar ra producrividad (caf,ítui"
Los LDR proporcionan la posiúilidad
iijil", r¡n
de reducir ra pranificácián ¿"ui¿o
a.su capacidadpara reducir el tiempo
de construcción. como reducen tanto
el tiempo de construcción, hacen posible
además er uso de ,ruerros tipos d.
modelos de ciclo de vida. Si el paso de
un 3GL a un LDR recorta el esfuerzo
d..di:":9 detallado y codificación en un 75 por 100 (que uná Uu.nu
regla básica), esto reducirá significativamente ",
el tiempo entre iteraciones en
un modelo de ciclo de vida iterativo.
una iteración qle requie* áL.,n.r.'
en c podría reducirse incluso a dos
semanas en visual Basic. La diferen_
cia entre estos dos períodos de tiempo es
la diferencia entre clientes o
usuarios finales que le vean dando respuesta o sin responder a sus deman-
das. Para obtener el máximo beneficio del uso de un LDR, utilícelo junto
con un modelo de ciclo de vida incremental e iterativo (Capítulo 7).
Si está trabajando en software <prét-á-porteD). en tiempo real o en
otro tipo de software que no se adapta bien a su implementación con un
LDR, sigue pudiendo utllizar los LDR para el prototipado de la interfaz
de usuario (Capítulo 42)y paraprototipos desechables (Capítulo 38). Uno
de los objetivos del prototipado es emplear el mínimo esfuerzo posible, y
los LDR pueden contribuir a este objetivo.
31.5. Puntos cruc¡ales de los LDR

Como sugieren las Tablas 31.1 y 31.2, el punto crucial de los LDR radica en
que el ahorro específico que puede esperar depende del len-uuaje especíñ-
DATOS REALES
co que está usando ahora y del LDR específico al que crmbie. También
depende de si el tipo de programa que necesita constn¡ir re adapta a su desa-
rrollo con un LDR. Si actualmente está usando un 3GL. puede esperar re-
ducir el esfuerzo de construcción alrededor de un 75 por 100 cr¡ando c¡mbie
a un LDR. Esta cifra seguirá mejorando a medida que se dispong de nuevos
y mejores lenguajes (¡pero probablemente no mejorar-á ten rápidamente
como desearían hacerle creer los desarrolladores de herr¿mient¿:l t-
Si no puede cambiar completamente a un LDR puede que siea pudien-
do implementar parte de su proyecto en un LDR En ñte c¿so se aplica la
regla básica del75 por 100: puede esperar reducir el esfuerznl de diseño 1'
construcción alrededor de un 75 por 100 en la parte del código que inple-
mente con el LDR (Klepper y Bock, 1995).
BIBLIOGRAFIA A medida que se incrementa el tamaño del pro¡ecto. el ahorro obteni-
ADICIONAL do al cambiar a un LDR disminuye. Los LDR obtienen su üorro redu-
sobre los efectos del ciendo la parte de construcción de un pro,Yecto" En prol-et-tos pequeños.
tamaño del proyecto las actividades de construcción pueden suponer hasta rm 8O Frc. 100 del
en las actividades
del mismo, consulte esfuerzo total del proyecto. Sin embargo. en pro\-ectos más grandes- el
el Capítulo 21, diseño detallado, la codificación y la depuración se reducen aprorimada-
.Project Size", en
Code Complete
mente aun25 por 100 del esfuerzo total. y el ahorro obteaido al compac-
(Mcconnell, 1993). tar estas actividades se reduce proporcionalmente t\{don-nell. l99il.
31.6. Claves para el éxito en e¡ uso de LDR

Éstas son las claves para tener érito al usar LDR:
¡ En condiciones de igualdad. para obtener r¡na máxima velocidad

de desarrollo, use el lenguaje con el mayor nivel en la Tabla 31.2
(teniendo presentes las limitaciones de los datos de esta tabla).
Seleccione LDR específicos usando los criterios de seleccic- , ,ri*

dos en la Sección 15.3, <Adquisición de herramientas para
F:_,:_.lL--
tividad>.
Implante los LDR específicos usando las directrices descriras -: ;
Sección 15.4, <Uso de herramientas para productividad>.
Estime de forma conservadora el ahorro que espera obten¿: -u:
uso de un LDR. Considere el tamaño de su proyecto y la :,:-i
del ciclo de vida que espera comprimir usando el LDR. para :,,:::,
los proyectos, exceptuando los más pequeños y simples, planr--_:_;:
un tiempo para resolver los problemas planteados por las irr__-
ciones del LDR.
Tenga cuidado al usar LDR en proyectos grandes. Tenga pres-- r:
que a medida que aumenta el tamaño del proyecto, las limitaciu.:,:,
de los LDR son más fuertes, y disminuye el posible ahorro.
o Insista en un diseño muy exhaustivo y sea extremadamente cL-;¡-
doso en los estándares de codificación al usar un LDR.
o A1 cambiar a un LDR, plantéese la oportunidad de usar nue,, _.j
modelos de ciclo de vida que le permitan responder mejor a .-i
clientes.
B i bl iog r atía adicio nal

Jones, Capers: <Software Productivity Research programming Langua:;=
Table>, 7.u Edición, marzo 1995, Burlington, Mass.: Software p::_
ductivity Research, 1995. Esta tabla incluye niveles de lengua_je
=
instrucciones por punto de función para varios cientos de lenguale=
Puede acceder alafabla completa en Internet, en ra dirección htl:
www. spr. comlllbrary llangtbl.htm.
McConnell, Steve; Code Complete. Redmond, Washington: Microsc-.
Press, 1993. La mayor parte de este libro está dedicada a descn'¡-:
cómo superar las limitaciones de los lenguajes de programación, co-_
sejos que se aplican a los LDR, así como a cualquier otro lenguaje. F.
capítulo 21 describe el efecto del tamaño der programa sobre lás acti., :-
dades del proyecto, y por tanto en el potencial de un LDR para reducr:
el tiempo general de desarrolio.
32
Filtrado
de requerimientos
Elfiltrado de requerimientos es un método en elque se examina cuida-

E*
dosamente la especificación de un producto buscando requerimientos
innecesarios o demasiado complejos, que son suprimidos. Como el *t
tamaño del producto es elfactor más importante que contribuye al cos-
te y duración de un proyecto, al reducir el tamaño del producto se ob-
tiene un proyecto inmensamente más económico y una planificación
s=
Ir-
más corta. Elfiltrado de requerimientos puede usarse en prácticamen-
te cualquier proyecto.
f,q-
l=lE
Eficacia
Reducción potencial de la planificación nominal: Muy buena
lE
Efecto sobre el riesgo de la planificación; Disminuye el riesgo
Riesgos principales
r Eliminación de requerimientos que posteriormente serán recupe-
rados.

Ninguno.
Para más información sobre elJiltrado de requerirnieriú-.. ,.tt!);1:i¿ ,,Fil-

trado de requerimientos)), en la Sección 14.1.
565
'f
33
Reutilizacion
La reutilización es una estrategia a largo plazo en la que una organlza-

ffiffi
ción construye una biblioteca de componentes usados con f recuencia,
permitiendo montar rápidamente nuevos programas a partir de compo-
nentes existentes. Cuando está respaldada por un compromiso a largo
ffi
plazo de la directiva, la reutilización puede producir mayores ahorros
de planificación y esfuerzo que cualquier otra técnica de desarrollo ffiffi
rápido. Además, puede usarse en prácticamente cualquier tipo de orga-
nización para cualquier tipo de software. La reutilización también puede
ffi
implementarse de forma oportunista, como estrategia a corto plazo, re-
cuperando código para un nuevo programa a partir de programas exis-
Wffi
tentes. Este enfoque a corto plazo también puede producir ahorros signi-
ficativos de planificación y esfuerzo, pero el ahorro posible es bastante
menos impresionante que elobtenido con una reutilización planificada.
Eficacia
Posibilidad de éxito inicial: Baja
Riesgos principales
. Pérdida de esfuerzo si los componentes preparados para su reutili-
zación no son seleccionados cuidadosamente.

. La reutilización necesita estar coordinada con el uso de herramien-
tas para aumentar la productividad.
. La reutilización planificada tiene que implementarse sobre los ci-
mientos de los fundamentos del desarrollo de software'
567
Podríamos pensar que la reutilización sólo se aplica a1 código, per. :

-:'ri
implicar la rettilización de cualquier elemento obtenido en un es--:-;
previo de desarrollo: código, diseños, datos, documentación. marer : :: ir
prueba, especificaciones y planes. En aplicaciones de sistemas de in, , *-
-
ción, la planificación de la reutilización de los datos puede ser tan in: -:--:,6-
te como la planificación para la rcufilización del código. Aunque puer r .r"r
-
no lo vea como reutilización,utilizar personal que ya ha trabajado ;:. :- -
yectos similares es una de las formas más fáciles y potentes de reutilrz,: 'r
Dentro de este capítulo, vamos a considerar dos tipos básicos de := _,: .
lización:
o Reutilizaciónplanificada.
o Reutilización oportunista.
La reuttlización planificada es generalmente la mencionada r¡:

expertos cuando hablan de reutilización, pero la reutilización oporr-, , u
también puede ofrecer reducciones de la planificación. La reutiliz,: ,'jr
oportunista contempla dos partes:
¡ Reutilizacrón de componentes de origen interno.

¡ Reutilización de componentes de origen externo.
Generalmente, el uso de componentes externos no se ve como r-,:

zación; suele verse como una decisión entre comprar y construir. Pe:- .,,
cuestiones implicadas son similares, por lo que trataré varios aspec: - i *;
este tema dentro de este capítulo.
La reutilización acorta la planificación por la razón obvia de qL- - . --
malmente es más rápido, fácil y fiable reutilizar algo que ya ha sido c:=,-
que crear una cosa desde cero. Puede emplear reutilización en pro,.::- '
de prácticamente cualquier tamaño, y resulta apropiada tanto para :,:-r-
mas de gestión internos como para software de sistemas o <prét-á-p:::..-
para su difusión en el mercado.
33.1. Uso de la reutilizacaón

Las consideraciones implicadas en la reutilización oportunista
¡
lización planificada son bastante distintas, y se describen en las
ciones siguientes.
Uso de la reutilización oportun¡sta

Puede hacer una reutilización oportunista cuando descubre que un s::.:-;
existente tiene algo en común con un sistema que está a punto de co:,.::- -
-------l
Cap ítulo 33: Reutilización 569
Entonces ahorra tiempo recuperando piezas del sistema existente y usán-

dolas en el nuevo sistema.
¿Adaptar o recuperar?
Si desea hacer una reutilización oportunista. riene dos opciones: adaptar
el viejo sistema para el nuevo usol o diseñar ei nuero sistema desde el
principio y recuperar componentes del antiguo sisterna. Desde mi punto
de vista, es mejor crear un nuevo diseño para el nui\ü sisrema r-lue-eo
recuperar partes de sistemas existentes. Este enl-oque ñ;nciu¡na me-ior porque
sólo requiere que comprenda pequeñas panes aisla'Ls del antiguo siste-
ma. Adaptar un antiguo programa para un nue\o,r-..-;equiere que com-
prenda todo el programa, 1o cual es una tarea ba-.Ie:le ¿:iua. Prrr Supues-
to, si las personas que escribieron ei antiEuL-r prüSl-¿:¿ s¡n l¿s mismas
que están trabajando en el nuevo, o si el nuer... ¡s er:e::¿i¡:rec.te similar
al antiguo, es posible que sea mejor adaptar i- rrr.-er¡:-' ::lr_r-u'l.
El enfoque de recuperar partes es ollortri:r-i-Li Srrra_-: - :e--¡siia aleu-
na suerte para poder reulilizar diseño r co*jiI-l-'s;:r.- ;i - :.:iiuti antcrior
sin haberlo planificado previamente. Pue,je:3-i: i-\-:a s::- =-::s:¿t¡ siste-
ma estaba bien diseñado e implementa,jtr. Er;: ='.-." :-: ¡: an:iouo
sistema utilice modularidad y ocultación de ia ln:c:= =::;c. T¡':-bren puede
tener éxito si hay solapamiento ent¡e la-s pia¡::, .l.s ,i: ¡¡-::¡--¡ ,iei anti-
guo y del nuevo sistema. Sin algún soiap¡n:r::;-r- :-::.:=- :i---:¿r par-
tes de un antiguo sistema puede ser más bisr -.:- i-:-:::;:- tr3 Jt-tiur{raia
que de reutilización.
Sobreestimación del ahorro

El mayor problema de la reutilización optrrrun-\- c{a:*i:r:: -: ;-3 ¡s -l;ii
sobreestimar los posibles ahorros de esñ¡erz.- '. tl¡:r':-::¿;---,: -1'::".:e ei
antiguo sistema Sea muy parecido al nuer ur ,,f:S¿E'.E J_-r :\\:-.: =e: ::-:i-
ltzado un 80 por 100 del códi-so)tiene que cr.rrl-irdr::: ¡- ¿e :;¡ue-
"::=-:s:-<
rimientos, el diseño, la construcción. la pruelte- ;¿,jur;';::-::-Jt!i: ", rr:ias
ERROR CLASICO actividades en su planificación dei esfuerz.." Depelúcc¡ ¡; -. Sti"-..tiir'rrl
específica podría sef capaz de reutilüar ei ¡¡--:-<--= ;- :iq-i--:Jlitri i el
diseño o ninguno de ellos; si e1 antiguo prrrri--iur i.r i-e --:3¿,1"r r ¿ir-:¿ce-
nado para ser reutilizado. no debería r't)DtdÍ aLr;: :i-¡.--lJ.: ::::.-:: ie ¡s-¿s
cosas. Si lo único que puede reutilizar es el cojleo. es.',a üütnüij¡¡;i: cel
80 por 100 del código puede reducirse a u¡ lrl prt'-r lu-J de disrniru;roÍr en
esfuerzo, y una disminución incluso rnenor en ia pI¡nificación- aimque
los sistemas sean similares en un ,R0 por itn).
Parte del trabajo de reutilización dei .tU por 100 del código consisrira
en cuál es el 80 por 100 a reutilizar. Este puede resultar decepci,rnanremente
costoso, y puede anular rápidamente este posibie ahorro del l0 por 100.
__*_J
otro problema común ocurre cuando se reutilizan partes de. --.;:ü,*

sistema de forma no prevista en el diseño e implementación de c---- rir*
tiguo sistema (nuevos errores emergen en el código del antiguo s-:::irr.rJ'
cuando esto ocurre, si el equipono está famlliarizado an:r:-. ;
"on.i
tema, se encontrará, de repente, depurando y arreglando código --, .r.,,.
de forma que se anulará el ahorro del 20 por 100.
Experiencia con la reutilización oportunista

Algunos proyectos que han hecho uso de la reutilización oportun:s:: lJ'
tenido éxito. un proyecto realizado por el ejército francés tuvo un. :::
DATOS REALES
ra del 37 por 100 de la productividad al recuperar código de un s..-. ']lil]iti
similar existente (Henry y Faller, 1995). Los responsables dei p:-,:_.:
indicaron que el éxito del proyecto se debía al uso de la moduia:. - l
ocultación de la información en el primer sistema, a los ámbitos si:*_ _j!r:l
de los sistemas nuevo y antiguo, y a tener aproximadarnente la m,-.: ,u,,
plantilla común en ambos sistemas.
El Laboratorio de Ingeniería del Software de Ia NASA hizo u: .,,;-,
dio de 10 proyectos que buscaban una reutilización agresiva (Nlc,.- r*
Waligora y McDermott, 1989). Los proyectos iniciales no pudier-:
carmucho partido del código de proyectos anteriores, debido a c-.
proyectos anteriores no habían establecido una base de códigc i -
ciente. Sin embargo, en los proyectos subsiguientes, los proyecrc! -r.r
usaron diseño funcional pudieron aprovechar el 35 por 100 de su c:,- :
de proyectos anteriores. Los proyectos que usaron diseño basado e--- r,
jetos pudieron recuperar más del 70 por 100 de su código de pro,,=: ,
anteriores.
una de las ventajas de este tipo de reutilización es que no rec*:rli
necesariamente un compromiso por parte de los altos directivos. c.:,.-"
Jones informa que a menudo los desarrolladores individuales reui:-*-J:
su propio código, 1o que puede suponer de un 15 a un 35 por 100 c: ;:
programa dado (Jones,1994). podría alentar a los desarrollad.ores:i*'
que reutilicen la mayoría de código posible, tanto a nivel de respon¡:: r
técnico como a nivel de contribución individual.
Reutilización externa
No existe ninguna razon técnica para hacer el desarrollo propio c; _:
componente cuando se puedq comprar un componente externo ya p:-_
-,
DATOS REALES rado, pero sí puede haber una razón de e*pr"io, como desea. .on,._ ,,
una tecnología que es crítica para su empresa. Desde un punto de . ,
técnico, es posible que un vendedor externo pueda pon",
-á, r€curSt- ! :-
un componente prefabricado de los que podamos disponer internar:.;:::
y con un menor costo. Generalmente, 10s módul0s de código reutiliz,: :
Capítulo 33: Reutilización 571
se ofrecen con un precio que oscila del I al 20 por 100 del esfuerzo que
requeriría su desarrollo para el cliente (Jones. 199.+).
REFERENCIAS Para muchas personas, el mercado libre se está orientando rápidamente
CRUZADAS
hacia la reutilización. Ha sido objeto de inr.estigación indusrrial y académi-
sobre las bibliotecas ca durante años, y los vendedores llevan ofreciendo desde hace tiempo
comerciales de código,
bibliotecas comerciales de código para dominios especificos de las aplica-
consulte el Capítulo 31 ,
"Lenguajes para
ciones, tales corno interfaces de usuario. bases de datos. funciones matemá-
ii
!I desarrollo rápido ticas y demás. Pero la reutilización comercial comienza a imponerse en la
* (LDR)", y el
plataforma PC con Microsoft Visual Basic r- \TlX {c-onuoles de \.isual
ii Capítulo 15,
"Herramientas Basic). Reconociendo su popularidad. Microsoft ha ret-orzado el soporte
para aumentar la
productividad". de la teutilización con OCX (controles OLE). La: emp*as de lcnguajes de
programación, como Borland, Gupta, Microsoftl- Pos-erSoft- hen comenza-
do a soporlar tanto VBX como OCX en los lenguajer q.le oirecen.
Los problemas citados tradicionalmente como ósárüh's para la reutili-
zación también están siendo controlados porel mercado libre" Por ejemplo.
las empresas no necesitan crear sus propios repositorios de ccrmpronentes
reutilizables, porque los vendedores de VBX lo hacen por ellas" El eúto de
los vendedores depende parcialmente de lo bien que oryznicea- caraloquen
y den publicidad a sus productos para reutilización. de modo qrc l.cl> u-lientes
puedan encontrar los componentes que necesiten 1-comprarlos"
Cuando veo un Algunas personas no comprenden el éxito de los \BL pero ürel.-I que
control la raz6n es aparente. Los VBX ofrecen una encapsrlacion f.. rrn¡ c¡r--ulta-
personalizado VB,
pienso: <Ahí hay ción de la información extremadamente buenas- qrrc srrn X¿s clar es pn¡a
1.000 horas de mi una reutilización con éxito. La reutilización prometida por lengua-ies de
vida que no voy a programación orientados a objetos, como C-. se ha',ict(t crmprnmeuda
tener que pasar por el diseño de los propios lenguajes. Por ejemplo. eo C- ior dsarro-
delante de una
computadora.> lladores de código pueden hacer una interfaz de cla-se q{¡€ erpr.loga el tj¡¡-
Al Corwin cionamiento interno de la clase. Esto constituve un s¡bot¿le ftenre a la
ocultación de la información y la encapsulación. O predÉn rc¡¡ nonnbres
de función que no den ninguna pista al posible u-suario sotre h forme de
utilizar la clase. Como el lenguaje no exige que lcrs dsarrollaJor* ent¡e-
guen documentación, puede resultar dificil que alguien comprenda rrna
clase lo suficientemente bien como pam reutilizarla
Por contra, el desarrollador de un \BX no tiene o,tr¿ opcran grr sumi-
nistrar una hoja de propiedades, que ss€¡gielmente hrce gue la interfaz frl
VBX sea autodocumentada.La hoja de propiedafu oculta c¡rmpletameore
la implementación del VBX, lo que refuerza ta ocrrltacién ds informacion
y la encapsulación. Los VBX han tenido érito simplemente porque otre-
cen un buen soporte para la encapsulación del presente en mrchos len-
guajes orientados a objetos. La modularidad ¡- ta ocultación de inf,orma-
ción ofrecen el soporte que buscaba la gente para la reurilización- Este
hecho es consistente con los informes de organizaciones que han prepara-
do sus propios programas de reutilización planificada- que veremqs pos-
teriormente.
Uso de la reutilización planificada

La rcutllización planificada, como su nombre indica, es una -s:
a largo plazo que no le ayudará en el primer proyecto en que la
"':-- ::
pesar de esto, no hay ningún otro método que tenga su capacidal :e
ducción de ias planificaciones de desarrollos a largo plazo.
Para comenzar un programa de reutilización, primero debe in-' =
el software existente en su organización, e identificar los comp;:
que aparecen frecuentemente. Entonces, debe planificar hacer r¡-: lt
bles estos componentes a largo plazo, bien comprándolos a un \'l

fiable o desarrollando versiones reutiiizables propias.
Consideraciones de gestión
La reutilización vincula proyectos que anteriormente podrían haberr.
zado de forma aislada, 1o que amplía el ámbito de las decisiones sl'ri-t
proyectos. Implica que diferentes proyectos tendrán que estanda:::-:r:
pro..ror software, lenguajes y herramientas. La reutilización ele;:' L
quiere una inversión a largo plazo en formación, y un plan multip:;','
fara la construcción y el mantenimiento de componentes reusable¡
:
cuestiones plantean todo un desafío, y prácticamente todos los :':
sobre programas de reutilización o informes sobre un program3 :
fico dicen que el compromiso de la directiva es mucho más in,l:':
para el éxito que la capacidad técnica (Card y Comer, 1994: Jt'c¡
Jones, 1994; Griss y Wosser, 1995).
Éstas son algunas de las tareas de gestión implicadas en la
de un programa de reutilización:
. Designar un responsable de la directiva (pero entre los alt¡s ::
vos) para el programa de reutilización. Los directivos ¡' :
nivel no tienen incentivos para el desarrollo de compone::x
sables en un único proyecto, ya que esto repercute sobre -¡
imagen del proyecto, y no hay ningún incentivo para que e - s-:
proyecto salga mejor.
. Asegurar un compromiso a largo plazo con el programa. F. mmuum-
tante que la reutiiización no sea tratada como algo pasaler. 'ir ü[ur
pueden pasar dos años o más para que el desarrollo de c.'::-:flfllüflü*
tes reutilizables empiece a ser rentable (Jones, 1994).
c Hacer que la reutilización sea una parte integral y explíci:. -1: I!1lr&-
ceso de desarrollo. La reutllización no aparecerá por sí s.'-' ' iruü-
poco aparecerá como subploducto de otros buenos proc:=-: limu
dejar clara esta prioridad, haga que el soporte de la reuti-:-.: irü !$[
convierta en una actividad más de revisión de los emple.;:*
o Transformar los programas de medida de productir idac ¡" "rrrt*
ware de la organización para que en lugar de medir e- --- -rr iúH
hF-*
Capítuto 33: Reutilización 573
desarrollado midan el software entregado. Esto ayudará a asegurar

que los desarrolladores son recompensados por el uso de compo-
nentes reutilizados.
Establecer un grupo de reutilización separado para encargarse de
las tareas relativas a los componentes reusables. En una organiza-
ción pequeña, el (grupo)) podría estar constituido por una persona'
o incluso por una persona a tiempo parcial.
o Proporcionar formación al grupo de reutilización y a los posibles
clientes del grupo.
Difundir en la organización la existencia de la iniciativa de reutili-
zación mediante una activa campaña de relaciones públicas'
Crear y mantener una lista formal de las person¿rs que esfán reutili-
zando componentes, para que puedan ser notificadas en el caso de
que haya problemas con los componentes que están usando'
Preparar un sistema de control de coste o compensación para el uso
de componentes de la biblioteca de componentes reusables'
Uno de los aspectos más difíciles de la preparación de un programa de

reutilización consiste en que es difícil hacer que la teutllización tenga
éxito sin el apoyo de otras técnicas claves de desarrollo, tales como el
control de calidad y la gestión de la configuración. Algunos expertos ar-
gumentan que un programa de reutilización debe implementarse como parte
á" utr ptog.uma más amplio de mejora del proceso (Card y Comer, 1994)'
Consideraciones técnicas
REFERENCIA El grupo encargado del cuidado y recogida de componentes reutilizables
CRUZADA tendrá mucho trabajo. Éstas son algunas de sus tareas:
Los grupos de
reutilización tienen
muchas cosas en Evaluar si las arquitecturas actuales del software de la otganiza-
común con los grupos ción soportan la reutilización, y desarrollar arquitecturas que la
de herramientas de
productividad. Para soporten si es necesario.
más información sobre Evaluar si los estándares actuales de codificación soportan la codi-
éstos, consulte "Grupo
de herramientas", en
ficación, y recomendar nuevos estándares si es apropiado.
la Sección 15.3. Definir estándares de lenguajes de programación e interfaces que
soporten la reutilización. Es prácticamente imposible reutilizar com-
ponentes si están escritos en lenguajes distintos, usan interfaces de
llamada a funciones completamente distintas y usan diferentes con-
venios de codificación.
Definir procesos que soporten \a rculllización. Recomiende que en
cada proceso se comience buscando los componentes que podrian
ser reutilizados.
Crear una biblioteca formal de componentes reutilizables- 1' ofre-
cer algún medio para examinar la biblioteca buscando los compo-
nentes que podrían ser reutilizados.
'"
I
Además de esas tareas generales, el grupo necesitarárealizar.'r:- ilh

de diseño, implementación y control de calidad en los propios con: . : rr1,,
tes reusables.
Centrarse en componentes específicos del dominio. Los :, ..ri.,

mas de reutilización que tienen más éxito se centran en la constru.: , t xü
componentes reutilizables para dominios específicos de aplicación. S :-¡ir,",
ja en aplicaciones financieras, céntrese en construir componentes i-t:.r ," r
ros reutilizables. En programas de primas de seguros, céntrese en c,:

componentes reutilizables de seguros. Intente centrar la reutiliz,:;
el <dominio de aplicación) o (componente de gestión> (Pfleeger. .: --"
Crear componentes pequeños y simples. Es me.jor que c.:.:i i*

trabajo de reutilización en la creación de componentes especializa; - . r,-
DATOS REALES
queños y simples, que en componentes grandes y generales. Los r:.-*"
lladores que intentan crear software reutilizable creando con-tp,::;: ,:i
generales rarayez se anticipan adecuadamente a las necesidades -----i
de los usuarios. Los futuros usuarios verán el componente grande -. : . n
plicado, comprobarán que no cumple todas sus necesidades, y de: - .--:
no utilizarlo en absoluto. <Grande y complicado> implica <Dent.. i,r,
difícil de comprender>, y esto significa <Propenso a errores eil S- -:¡
Los datos obtenidos por el Laboratorio de Ingeniería del Softua:; :: *
NASA sugieren que si un componente necesita ser modificado en :.:,, u,
un 25 por 100, cuesta lo mismo desarrollar un nuevo componei:; ,rL
reutllizar uno anterior (NASA, 1990).
BIBLIOGRAFiA Es mejor dividir el componente grande en componentes pequi_,. ,
ADICIONAL
Esta opinión es objeto
centrar sus esfuerzos de reutilización sobre estos últimos. Utiliza-.: r-:
de algunas lenguaje de diseño estructurado,.f'actoríce completamen le cualquie: : ir
controversias. Para ver ponente que intente reutllizar. No presente grandes componentes : , :l
una discusión completa
del debate de RISC entidades individuaies y monolíticas. Con componentes más pequ;. . ,
f rente a CISC apl¡cado precisos, proporcionará la esperanza de resolver el problema de l¡. --:"
a la reutilizacrón del
software, véase ros usuarios de una vez, aunque de todos modos esta esperanza _q-:.:-!l
Confessions of a Used mente es poco realista. A1 menos, con componentes más pequeños :.-_ . -"
Program Salesman
(Tracz, 1 995). las posibilidades de ofrecer aigo de valor.
Céntrese en la ocultacíón de la información y la encapsulac,;n,

Otra de las claves para tener éxito es centrarse en la ocultación tJ¡ .. r
DATOS REALES
formación y la encapsulación, el núcleo del diseño basado €fl t,r-:
(McGarry, Waligora y McDermott, 1989; Scholtz et al., 1994: Hc::
Faller, 1995). La mayoría de los proyectos de reutilización existen¡-: -'r-i
han tenido éxito han usado lenguajes tradicionales, tales como _\;
Cobol y Fortran (Griss y Wosser, 1995). Un estudio sobre 29 org: _-
ciones ha encontrado que los programas desarrollados en lengua_i;. _,.
generalmente se piensa que facilitan la reutilización (como Ada r _
-
*i-c
Capítulo 33: Reutilización 575
realmente no presentan un mayor índice de reutilización que aquellos de-

sarrollados sobre ienguajes tradicionales (Frakes y Fox, 1995)'
El diseño <orientado a objetos> añade 1as ideas de herencia y poli-
morfismo al diseño basado en objetos. pero la incorporación de estas ca-
racteristicas no parece facilitar el logro de la reutilización. Un panel de
investigadores y empresas de la Conferencia Internacional de Ingeniería
del sofiware de 1994llegó a la conclusión de que e1 desarrollo orientado
a objetos por sí mismo no era ni necesario ni suficiente para la reutili-
zación(Pfleeger, lg94b). Las claves reaies para obtener érito son la oculta-
ción de la información y la encapsulación.
Crear una buena documentaCión. La reutilización requiere también

una buena documentación. Cuando crea un componente reutilizable, no sólo
está creando un programa; está creando un producto. Para que sea utlliza-
DATOS REALES
do, su nivel de acabado tiene que ser compalable a los productos comer-
ciales adquiridos por su organización. Por ello, Fred Brooks estima que el
desarrollo de un componente reutilizable costará aproximadamente tres
veces más que el desarrollo del mismo componente para su uso individual
(Brooks, 1995). Otros autores estiman también que la creación de compo-
nentes reutilizables duplica o triplica el coste (Jones. 1994',Tracz,1995).
un tipo de documentación que resulta especialmente valioso para 1a
reutilización es una lista de las limitaciones conocidas de cada compo-
nente. A menudo, el software se entrega con defectos conocidos, debido a
que algunos fallos tienen una prioridad muy baja como para ser corregi-
dos. péro un defecto de baja prioridad en un contexto puede convertirse
en uno de alta prioridad cuando el componente es reutilizado en otro pro-
ducto. No haga que la gente descubra los defectos por sí misma cuando
ya los conoce de antemano: documente las limitaciones conocidas.
REFERENCIA construya componentes reutilizables libres de errores. una reuti-

CRUZADA
lización con éxito requiere 1a creación de componentes que estén r-irrual-
sobre la penalización mente libres de effores. Si un desarrollador que intenta emplear un com-
de la velocidad de ponente reutilizabie encuentra que contiene defectos. e1 programa de
desarrollo debida a la
baja calidad, consulte ieutilización perderá rápidamente su brillo. Un proerama de reutilización
la Sección 4.3. "Bases basado en programas de baja calidad puede incrementar realmente el cos-
del control de calidad..
te del desarrollo del sothvare. En lez de pagarle a1 desarrollador original
para que depure completamente un componente- le pagará a un desarro-
llador que no está familiarizado con el mismo para depurarlo. probable-
mente de un modo menos eficiente.
Céntrese en la calidad de la biblioteca de componentes reusables,

no en el tamaño. La -eran cantidad de código disponible para ser reuti-
lizado no parece afectar al nir-ei de reutilización; las pequeñas bibliotecas
de código son usadas al menos con la misma frecuencia que ias grandes
-<-¡-
-
576 iasala'!,io y gestión de proyectos informáticos
(Pfleeger, 1994b; Frakes y Fox, 1995). Elegir entre un amplitr::,::i .@

componentes reusables existentes puede resultar tan difici1 que -:: -l;'¡".
rroliadores de Smalltalk se refieren a este fenómeno como .,Es:" -r-- .ii
montaña de Smalltalk>. Si desea implementar la reutilización. ce:.:..: ,sl
la calidad, no en la cantidad.
No se preocupe demasiado sobre si los desarrolladores aceptaratr

la reutilización. Por último, no hay que preocuparse tanto poi -. irrr
DATOS REALES
del cliente en la relación de reutilización como la gente piensa eo ocr . t,i:
La creencia general mantiene que ios desarrolladores no quieren -.-- *
código a menos que lo hayan desarrollado ellos mismos. Pero un i!:-:
de 1995 encontró que actualmente más del 70 por 100 de desar¡c.i-.:--r
prefería reutilizar componentes en lugar de desarrollarlos partie::- i'
cero (Frakes y Fox, 1995).
33.2. Gestión de los r¡esgos de la reutilización

Generalmente, los programas de reutilización mejoran la calidad ¡' ,' : :r*
ductividad con un menor coste. A nivel de proyecto, la reutilizacio:- : :t-
de a reducir el riesgo, porque hay que codificar a mano menos pani: t:
producto, y la calidad de los componentes reutilizados generalme:,:' *,
más alta que la de los componentes desarrollados en el acto. Sin err: '-; "
a nivel de la organización, aparece un conjunto de riesgos alrededo: := u

dificultad de predecir cuáles son 1os componentes que necesitarán se: :- -.:.
lizados.
Esfuerzo desperdiciado. La creación de componentes reutii.:.: :-

cuesta dos o tres veces más que la creación de un componente l,- =-!t
IJna vez desarrollado el componente, tiene que usarlo como mínir- - : *
o tres veces para quedar a \a par. Ted Biggerstaff llama a esto 1¿ r:!+
del tres>: antes de obtener ningún beneficio por 1a reutilizaciór := -m
componente, tiene que reutilizarlo tres veces (Tracz, 1995). Si:-: .".;;
seguro de que va a reutilizar un componente un mínimo de tres-..-t,,
podría seguir teniendo sentido tener componentes preconstruidos : j:',-
nibles desde el punto de vista de un desarrollo futuro, pero esta r e,-; -iiu
futura requerirá su precio.
Esfuerzos mal dirigidos. Si define un grupo separado para des"-- Jr

componentes reutilizables, existe la posibilidad de que este grup,: :;-i-
rrolle componentes que nunca se han utilizado. Si el grupo de reuti,.-.: I
rcaliza hipótesis incorrectas y uno de cada cuatro de sus corrlpt-r--i-:'r
nunca es utilizado, tendrá que planificar usar cada componente reu: .-.:,
como mínimo 5 veces para equilibrar el coste. Dentro de una organ::-: rl
{
CaPítuto 33: Reutilización 577
parecidos, este
que no desarrolla una gran can¡ida,j de slstemas reaimente
punto de equilibrio puede resultar dii-íci1 de alcanzar'
podria ser implementar
Una estrategia piáctica que reduce e-'te de sqo I
una<regladedos>:implementarcadactt¡nf'on'niecomocomponenteúnico
segunda t'ez. considerar
la primáa vez, y luego. si es necesario usarit-r una
hacerloreusable.EnestepuntosabeüL]e\'3els¿iio.-omo.mínimootra
lnenor rlesgo sl cree
vez, con lo que implícitamente está 3t'ifl3Iiitr in
q,,.,utgunureutilizaciónactualimpliCaunaÍI¿\-Lrlreutilizaciónposterior'
É.ro tltgu cuidado. Algunos "tpitot adrie-e: ";e =r
ro ha construido
tres sistemas reaies en in dominio parricular. nroba'¡;e nente. todar ia
no
conocelosulrcientedelmismoparaclesre-LrliiDüEeflI3srsulilizSb]eicon
éxito (Tracz, 1995).
reutilizacic-'n p1a-
cambios en la tecnología. uno de los riesgos en la
una estrategia a largo plazo'-\o sólo
nificada se debe al hechote que es
necesitareuliliZarun.o,npon.ntevariasvecesparafecuperarlainler-
,órl, ,ino que necesita usarlo antes de que la tecnología en ia
que está
<puede emplear mucho
basado quebe obsoleta. Como dice Chris Peters'
sólo para ver como queda ob-
tiempo haciendo qr" utgo sea compartible,
mundo en que las cosas cambian con
soleto al cabo de dos alñor. En un
díganme cuál es la parte que tiene que ser com-
ianta rapidez y violencia,
partida>i (Peters en Cusumano y Selby, 1995)'
REFERENCIA Sobreestimacióndelahorro.Nosupongaquelareutilizacióndecó-
CRUZADA
digoleharáahorrarmuchotiempo.Sisóloreutilizaelcódigo,sóloaho.
proyecto'
,rírá ,i"-po de codificación. Si reutiliza otros elementos del
sobre la estimación del
tiemPo ahorrado' podrá ahorrar tiempo en otras facetas'
consulte.Reducción
Tenga presente que reutilizar un componente tiene
un coste debido al
realista del Plan", en la
y a usarlo' Pla-
Sección 15.4. tiempo i"""rurio pira localizar el componente aprender
nifiqueemplearparalareutilizaciónd.u''ulíneadecódigoalrededor
de una quinta parte del esfuerzo necesario
para desarrollarla desde cero
(Tracz,1995).
DATOS REALES
33.3. Efectos secundarios de la reutilización

La reutllización oportunista no tiene efectos secundarios significati" 'rs'
pero la reutilización planificada sí presenta uno'
Mejoradelrendimiento.Loscomponentesreutilizadosmejoran¡.:¿:l-
dimiento en dos aspectos. A menudo. están mejor diseñados
r mi'i: =J'-
bados que los componentes individuales, 1o que a menudo imJ:;: rue
también hace que
,on -¿, rápidos 1Éfleeger, lgg4b;)' Esto 'os -s:-i:-I--rs
sean montados con mayor tapidez, lo que permite
montar en:3> -¡: siste-
-+:
mas buscando cuellos de botella en el rendimiento. Pero como ti.:-Jr tt
ser más generales, en ocasiones los componentes reusables puei;: *,lt

más lentos que los componentes normales, por 1o que necesitará c.-:::rnl*
bar el rendimiento de cualquier componente determinado por e1 q;. :re
interesado en lugar de asumir que es más lento o más rápido'
33.4. lnteracciones de la reutilización con otros métodos

La reuttlízación está relacionada con el uso de hertamientas para pi.':,r;-
tividad (Capítulo 15) y lenguajes para desarrollo rápido (Capítu1c -:
Por ejemplo, podría reutilizar una herramienta que genera rápida:-:nil
código de interfaz de usuario en Pascal o reutilizar una biblioteca de ; -':r*
ponentes de base de datos escrita en C, pero no poder hacer las dos ; -:"u*
simultáneamente. La reutilización puede apoyar o limitar el uso de ]:.::l-'
mientas esPecíficas.
Como los componentes reusables tienen que Sef más tolerantes a ; L]-
bios que los componentes normales, la reutilización se beneficia del d:=-t:
pu.u él cambio (Capítulo 19). La reutilización también puede ser irr:'-n-
tante cuando se usa e1 diseño por herramientas (Sección7.9). Por úli-:--r.
1a reutilización pianificada es difícil de implementar con éxito, a m.::!
que una empresa tenga gran experiencia y dominio con las bases de ' ¡:-
sarrollo de software (Capítulo 4).
33.5. Puntos cruciales de la reutilizacion

La potencia de la reutilización oportunista varía considerablemente. ¡=-
pendiendo del volumen de la oportunidad de reutilización. Pequeñas c--
tidades de reutilización oportunista darán lugar a un ahorro peque:;
Mayores cantidades de reutilización pueden dar lugar probablemen:- it
-.
ahorros de esfuerzo en el rango del 20 al 25 por 100 a lo largo de 1a -:¿
de un proyecto, suponiendo que se pueden reutilizar grandes parte> ::
código y del diseño, y que exista alguna continuidad de plantilla enr. ;
nuevo programa y el que está siendo recuperado.
La reutilización planificada no es una técnica a corto plazo, perr' 5-
rendimiento a largo plazo la convierte en una estrategia atractiva. Er -:
DATOS REALES
estudio de mejora del proceso del software en 13 organizaciones, alg--:-",r
¡
de ellas mostraron incrementos de productividad mucho mayores que L1::-
(Herbsleb et a1.,1994). Una empresa mejoró su productividad en un :t
por 100 anual durante cuatro años. Otra redujo su tiempo de comerc."- -
zación en un 23 por 100 anual durante 6 años (dando una reducción ¡c-¿
de un 79 por 100). Los autores del estudio atribuyen todas estas me,iLr;r:
extraordinarias a los programas de reutilización.
Capítulo 33: Reutilización
Debido a los desafios para la organización y a nivel del control de

calidad, es posible que un programa de reutilización requiera dos años
para desarrollar cualquier componente que sea realmente reutilizable (Jo-
nes, I 994). Pero la productividad con una reutilización significativa puede
superar los 35 puntos de función por mes de trabajo: compare esto con la
media nacional de alrededor de 5 puntos de función por mes de trabajo.
Como el uso de componentes reutilizables suprime completamente el diseño
y la construcción y reduce la cantidad de control de calidad necesario para
estos componentes, un programa de reutilización correcto es con mucho
el método disponible más eficaz de cara a la productividad (Jones, 1994).
33.6. Claves para el éxito en el uso de la reutilizac¡ón

Las claves para tener éxito en el uso de la reutilizacíon oportunista son
simples:
Sacar partido de la continuidad de personal entre antiguos y nue-

vos programas.
No sobreestimar el ahorro que se va a alcanzar.
Las claves para tener éxito en la reutilización planificada son más

complejas:
o Un compromiso seguro y a largo plazo de los altos directivos con

el programa de reutilización.
o Hacer de la reutilización una parte integral del proceso de desarrollo.
o Establecer un grupo de reutilización separado cuyo trabajo sea iden-
tificar candidatos a componentes reutilizables, crear estándares que
soporten la reutilización y diseminar información sobre componentes
reutilizables a los posibles usuarios.
¡ Centrarse en componentes pequeños, sencillos y específicos del do-
minio.
o Centrar los esfuerzos de diseño en la ocultación de información y
la encapsulación.
¡ Lleva¡ la calidad de los componentes reutilizables hasta el nivel de
<productos>, para ,qenerar una buena documentación y asegurar que
están prácticamente iibres de errores.
Tracz,Wlll: Confessions of a L:sed Program Salesman. Reading, Mass.:
Addison-Wesley. 1995. Este libro contiene una serie de artículos es-
critos por Tracz para IEEE Computer y otro material, escrito todo e11o
desde un punto de vista práctico. Trata cuestiones relativas a _¡

tión, la técnica y algunas relacionadas con la filosofia. Aiguno= r
ensayos son puro entretenrmiento. La escritura es ligera, y los ,e:
a los que no les gusten losjuegos de palabras deben saber que ie:
tura de Tracz es excepcionalmente rica en este sentido.
Freeman, Peter, ed.: Tutorial; software Reusability. Washington" I I
IEEE Computer Society Press, 1987. Esta colección de artícu-¡:
bre la reutili zación describe conceptos básicos de ra reutilizacir-':-
nicas y la investigación en curso desarrollada en 19g7.
IEEE Software, septiembre 7994. Este número se centra en la reu::
ción planificada. Contiene l0 artículos sobre el tema^ inclur-ei¡:
estudio de un caso de reutilización y algunos artículos más qu;
criben experiencias reales con programas de reutilización.
Udell, John : <Component Software>>, By t e, may o 19 9 4, 4 5 - 5 5 . Este
describe la rápida adopción de los VBX, y estudia las diferentes ¡
tegias de componentes reutilizables que compiten por el mercai:
34
Compromiso
(Signing Up)
Probablemente, la motivación es el factor que más influye en la pro-

ductividad. El compromiso (srgnlng up) es una técnica que en algunos
CW
casos ha llevado a niveles extraordinarios de motivación. Ha dado lugar
a éxitos notables tanto en proyectos software como hardware en diver- =W
-tdw
sos campos de la industria. Su éxito depende de tener una visión clara
con la que puedan comprometerse los miembros del equipo, y en contro-
lar aclivamente el proyecto para asegurarse de que el equipo comprome-
SW
HrffiW
tido desarrolla el producto en una dirección aceptable.
ffiffi
Eficacia
Reducción potencial de Ia planificación nominal: Muy buena
ffi
Posibilidad de éxito inicial: Media
Posibilidad de éxito a largo plazo'. Buena
Riesgos principales
. lncrementar la ineficiencia.
. Reducción de la visibilidad y control del estado.
. Disponibilidad de menos personal cualificado para el proyecto.
. Agotamiento.

. Sacrifica posibles disminuciones en visibilidad, control y eficiencia
por un mayor incremento de la motivación.
Con la técnica del compromiso. un directivo o responsable del equipo les

pide a los posibles miembros del equipo que suscriban un compromiso
incondicionalpara que un pro-vecto tenga éxito. Posteriormente se permite
al equipo que complete el proyecto a su aire. El compromiso produce sus
581
beneficios para el desarrollo rápido a partir de su increíble capacrce ,,m

motivación. Los desarrolladores que se comprometen reahzan ul :i:m*
promiso voluntario y personal con el proyecto, y a menudo llegan ¡ i*n&-
ras increíbles para hacer que el proyecto tenga éxito. Hay equipos q-r nü
han comprometido que trabajan en ocasiones con un ritmo endiabl¿¡- ¡rc
les aboca a cometer algunos errores, pero la cantidad de esfuerzo q:. :rm*
plean corrige plenamente los efectos de estos errores.
34.1. Uso del compromiso

Kerr y Hunter indican que el explorador antártico Shackleton coni¡;,lru
su tripulación buscando hombres que iban a trabajar duro en condicr;rro
peligrosas con poco sueldo, con la posibilidad de alcanzar la glor; s
tenían éxito (Kerr y Hunter, 1994). Expresado así en pocas palabra-r- rril
es la forma en que se usa el compromiso. Ofrece a los desarrollaó:mx
poco más que las recompensas intrínsecas del propio trabajo: la por:t-Ll-
dad de trabajar en algo importante, incrementar sus posibilidades. ¿--¡m*
zat rtna meta aparentemente imposible y llegar a algo que no haya ,-r-:*t-
guido aún nadie de la organización.
En The Soul of a New Machine,Tracy Kidder describe un equipo ;,;m*
prometido en el que el beneficio principal del compromiso es llac-tro
<máquina recreativa> (Kidder, 1981). En las máquinas recreativas. el u:¡su
beneficio obtenido al ganar el juego es que puede jugar de nuevo. S, 16
compromete en un proyecto de desarrollo y tiene éxito, podrá compi-iürü*
terse de nuevo en el siguiente proyecto interesante. Ésta es la recor::*ru*
sa, y es toda la recompensa que necesitan muchos desarrolladores. -1- tx*
gunas personas no les gusta jugar a los juegos recreativos, y a a,¡--lulr
personas no les gusta comprometerse. Para ellos, esto parece más b-r m
ejercicio de falta de lógica y masoquismo. Para unos, puede parec-: rru-
nipulación por parte de la directiva. Pero para otros, representa un¿ ;ulxrr*.
tunidad esperada durante largo tiempo. IBM encontró que no tel:. trn¡*
blemas buscando a gente para comprometerse. Descubrió que las f€:-n:!mü
REFERENCIAS
CRUZADAS deseaban comprometerse para producir resultados extraordinario! ir ü
Para más detalles trabajo; lo único que faltaba era la oportunidad (Scherr, 1989).
sobre la motivación y
los equipos de trabajo,
consulte el Capítulo 11, Definir un desafío y una visión. Las claves para tener éxi¡¡ ;:,rr r
.Motivación", y el
Capítulo 12, "Equipo
compromiso son similares a las claves para tener éxito en la moi-; ir::r,il
de trabajo". Para más en general y en la preparación de equipos de alto rendimiento. Co=-- ;rr:-
detalles sobre la mer elemento de las listas, tenemos ofrecer una visión clara de ic ;.s s
creación de visiones,
consulte "Definición de supone que hay que realizar en el proyecto. Para hacer que la Sr-= ,c
objetivos", en la comprometa, la visión tiene que ser extraordinariamente atracrir'¿ l:'*
Sección 11.2, y "Visión
u objetivo compartidos", minar simplemente un proyecto no basta. Aquí hay algunos ejem¡-:r ,mr
en la Sección 12.3. visiones extraordinarias :
Capítuto 34: Compromiso (Signing Up) 583
o Ser el primer grupo de exploradores en ilegar a1 Polo Sur'

o Ser el primer país en poner un hombre en la Luna'
r Diseñar y construir una computadora toralmente nueva sin el apo-
yo de la comPañía.
. biseñar el méjor sistema operatir-o de computadora del mundo.
¡ Ser el primer equipo de la organización que ciesarrolla completamen-
te un producto de software <prét-á-porter') en menos de un año'
o Crear un paquete de bases de datos que se cL-rnvieiria en
número uno
en su primera prueba comparativa en lnf c'Il or!'i \ bata a todos 1os
competidores al menos en 0.5 puntos'
Barrer decisivamente a la competencia en ia nis;¡a careeoria
de
.
software.
Dé una oportunidad de comprometerse a las personas'

Le :e "-nica
fi
del compromiso no funciona si la gente no tiene la opornrnidai ie Je;idrr I
,
que aceptar ia posibilidad de que

si quieré o no comprometerse' Tiene I
t,
e1 ccrmpr.]-
algunas de las personas que desea tener en su equipo no acepten ri
ilr I
1
El hecho de que algunas t'I

mlso extraordinario requerido por esta técnica. ;; $
personas cualificadas nt entren en el equipo está en parte a su favor' Los
$1
miernbros del equipo que pueden ver que algunas per-
-huy se comprometan
¡i I
*' I
sonas no tienen 1o que qua tener para trabajar en ello' y esto ayuda a F, I
fomentar su sentido de identidad como equipo' *il

Í, I
menos
Si ya ha configurado el equipo, no puede usar compromiso a 6jl
preparado para echar a gente del equipo que no quiera compro- fl
qrr"
".ié
áeterse u toiurgo dél proyecto. E1 compromiso necesita implementarse
al
que
principio del proyecto o en respuesta a una crisis' No es una práctica
se pueda iniciar a medio camino'
Una vez que los desarrolladores hayan hecho su elección' el compro-
que el pro-
miso debe sei inequívoco. Tienen que comprometerse a hacer
yecto tenga éxito, sin importar cómo.
Compromisoaniveldeequipo.Latécnicadelcompromisoparece
identi-
funciánar mejor en equipos suficientemente pequeños para tener una
dad de equipá. Es diticit que alguien se comprometa con una sran org3nr-
zación. Álg.tnu* han usado esta técnica con érito en sÍ.i-i¿'s
"-pr.tui
proyectos, creando pequeños equipos dentro de 1os grandes pltr\ 3u-iurS i
haciendo que la gente se comprometa con ellos'
Las personas necesitan identificarse con Lln -grr-lpt'r lu:-i;:3'-:3¡:13::e
pequeñocomoparaquesepanquesucontribucióneslil'1..Í:i:¿'C:-i'.
iur^p"r.or,u, todas 1' carja una 'ie el':-' 'E se:':-:ár
"rián "ó-ptometidas,
responsables personalmente de terminar el prt-rCuctc''' C'¡a¡ic e' ;:"c-i:t'
esté terminado, cada persona sentirá que ha sido ¡a persona cl¿"e -\i:
1a
cual el proyecto no habría sobrer-ivido. r cada una de ests: perso¡as -5Ia-

rá en 1o cierto.
Como el compromiso funciona mejor a nivei de equipo. no :r.:,i Tmr

qué ser iniciado por la directiva. Puede ser iniciado por el respon>::,: ,rir't'l
equipo o incluso por un líder <de facto> (alguien que se encuen;r :rñ!rüt*
cialmente motivado y desee tirar del resto del equipo).
Déle todas las atribuciones al equipo. El compromiso no i::: rmal,
a menos que deje que el equipo juegue solo. Señale la dirección.:-:, lur¡
especifique cómo llegar al final.
No use compromiso en un proyecto con requerimientos pocc fin-

mes. Su equipo altamente motivado necesita poder ir a toda :-j:rLllr$lul
hacia adelante, y no a toda máquina a la derecha, luego a la izc,- =l-ti¡i¡. 'q
luego a toda máquina hacia atrás. La única excepción a esta reql. s: rrrrltr-
duce cuando e1 equipo en sí es responsable de la definición de r:l!is!fr*
mientos. En estos casos podrán tolerar numerosos cambios de d-:-:'lunm
sin perder la motivación.
Compromiso en diferentes entornos

Puede usar el compromiso en prácticamente cualquier tipo de p::rl:ur
de gestión, <prét-á-porter>, de sistemas y demás. El compromiso s-='uumus
requiere una <adhesión extraordinaria>>, pero la naturaleza exact: i: i:m
adhesión extraordinaria significa cosas distintas en diferentes en::::;ri
En el mundo del RAD, James Kerr escribió sobre un equipo i; - :u,u,
al RAD que usó compromiso, 1o que implicaba que estaban deseani.: ir rrmus
de sus responsabilidades habituales y trabajar duramente colle-i-lit¿,üi,Iü{h
8 horas diarias en un proyecto (Kerr y Hunter, 1994). Kerr inl-c::: ¡¡¡r
este equipo en ocasiones tenía que trabajar en casa por las noches - Lry-
nas horas el fin de semana. Para Kerr, 1o más destacabie del prole::: r¡q
la noche en la que el equipo de cuatro personas se quedó tarde :":¡ nm*
plementar un conjunto de pantallas de ayuda. Kerr habla extensi.' :-,ffi
sobre 1o terrible que fue ese día. El equipo trabajó un día compie:-. nr,m
una pausa de media hora para tomar una pizza y una cerveza. .. ..9l.u0u
trabajando casi hasta medianoche. Kerr describe esto como una . :,::id*
cación suicida>.
Por contra, en el proyecto de Microsoft Windows NT, e1 con::- rrifl
significaba sacrificar todo para poder trabajar en el proyecto: nc;':; í,*
nes de semana, vacaciones, horario normal de sueño, incluso sr-:--'liÍtlr
(Zachary, 1994). Cuando no estaban durmiendo, estaban traba-ja:c- *mu
desarrolladores sacrificaron sus aficiones, salud y familias para :::iü[r
en el proyecto. Un miembro del equipo contestaba al coneo e1e;:-r;:u
desde el hospital mientras su esposa estaba dando aluz.El equrpo J: -r¡i¡¡b-
rrollo de NT llevaba buscapersonas, para que pudieran ser llamac,:i r il¡ft,
tres de la mañana si su código fallaba al agregarse al producto. L" ¡:r'e
Capítulo 34: Compromiso (Signing Up) 585
tenía habitaciones en las oficinas, y muchos estaban varios días sin ir a

casa. Tracy Kidder describe un nivel similar de compromiso en The Soul
of a New Machine (Kidder, 1981).
A algunas organizaciones, como a Microsoft, no les importa si la
adhesión al compromiso deriva en montones de horas extras. Otras orga-
nizaciones, como IBM, han encontrado que como parte del compromiso
se puede hacer constar no tener que trabajar horas exfras (Scherr, 1989).
Han encontrado que sometiendo un proyecto a un conjunto de restriccio-
nes severas prácticamente imposibles, el equipo considera e implementa
soluciones radicalmente productivas que noñnalmente ni siquiera se plan-
teaúan.
El nivel de adhesión cambiará dependiendo del grado del desafio. El
equipo del Windows NT se encontraba con el desaflo de desarrollar el
mejor sistema operativo del mundo. El equipo RAD de Kerr se encontraba ¡
dl
¡t
con el desafio relativamente mundano de desarrollar un sistema de ges-
tión para uso de su empresa. No resulta sorprendente que uno de los equipos
ül
-'
estuviera dispuesto al sacrificio mucho más que el otro. g!
g:
tl
34.2. Gestión de los riesgos del comprom¡so
üt
El método de1 compromiso es una espada de doble filo. Ofrece un tre-

mendo potencial de motivación, pero también ofrece tantos riesgos como
cualquiera de los otros métodos descritos en este libro.
Pienso en esa lncremento de la ineficiencia. Los equipos comprometidos tienden a

estadística de que trabalar duro en lugar de a trabajar con mayor inteligencia. Aunque es
los mejores
programadores son teóricamente posible trabajar duro y trabajar con inteligencia, la mayoría
25 veces más de las personas parecen capaces de hacer una cosa o la otra, pero no las
productivos que los dos. Si se centra en trabajar duro, queda prácticamente garantizado que
peores, y me parece
cometerá errores que lamentará toda su vida, errores que harán que el
que tengo parte de
cada uno de ambos proyecto tarde más en lugar de menos. Algunos expertos incluso han di-
extremos. cho que las personas que trabajan más de 40 horas a la semana no tienen
Al Corwin realmente más rendimiento que las personas que trabajan 40 horas (Metz-
ger, 1981; Mills en Metzger, 1981; DeMarco y Lister, 1987; Brady y
DeMarco, 1994; Maguire, 1995).
Si está trabajando en un proyecto en el que la gente está comprometida,
vigile un incremento del número de errores costosos y otras señales de
que la gente no está trabajando con el cuidado necesario.
Disminución de la visibilidad del estado. Las personas que se com-

prometen asumen el compromiso personal de entregar un producto en
el plazo más corto posible. En algunos casos, esta mentalidad voluntariosa
hace difícil determinar el estado real del proyecto.
Reforzar el equipo para que pueda tener éxito con el desa:-: _ ,

se le ha motivado a responder.
Estar preparado para controlar o aceptar las ineficacias qu. :,:
ven del hecho de que la gente trabaje duro más bien que c= '
inteligente.
Bibl iografía adicional

Kidder, Tracy: The Soul of a New Machine. Boston: Atlantic \1:::r
Little Brown, 1981. Este libro describe el compromiso de 1os ¿;;
lladores de hardware de computadoras en el proyecto de la comp-:
Eagle de Data General. Describe con detalle el proceso de co:::::;
so, e ilustra los beneficios de la motivación en el proceso (1os o;v
lladores del Eagle trabajaron prácticamenfe 24 horas al día a '',-
del proyecto). También es una lección prácfica de los riesgos as"-;
con el compromiso: gran parte del equipo de desarrollo dejó la ;-.I
sa al terminar el proyecto
E
35
Modelo de ciclo
de vida en espiral
El modelo de ciclo de vida en espiral es un modelo de ciclo de vida

sofisticado que se centra en la identificación prematura y en la reduc- ffi
ción de riesgos del proyecto. Un proyecto en espiral comienza en una
ffi
escala pequeña, explora los riesgos, realiza un plan para controlar los
riesgos y luego decide si continuar con el siguiente paso del proyecto ffi
(realizar la siguiente iteración de la espiral). su aportación al desarro-
ffi
llo rápido no procede de un aumento en la velocidad del proyecto, sino
ffi
de una reducción continua en el nivel de riesgo del proyecto (que tiene
un efecto sobre el tiempo necesario para entregarlo). El éxito en la
utilización de un modelo de ciclo de vida en espiral depende de una
gestión consciente, atenta y bien fundamentada. se puede utilizar en
w
rffi
la mayoría de los tipos de proyectos, y su enfoque en la reducción de
riesgos es siempre ventajoso.
Eficacia
Reducción potencial de la planificación nominal: Medra
lfecto sobre el riesgo de la planificación: Disminuye e riesgo
Riesgos principales
Ninguno.

. Requiere una mayor planificación y un mayor seguimiento del crc-
yecto a cambio de una gran mejora en la visibilidad del progresc ,v,
en la reducción del riesgo.
Para obtener mayor información sobre el tnodelo de ciclo ije-;:.j; ¿,: ¿s-
piral, consulte la Sección 7.3, <Espiraltt.
589
*ll---
't
36
Entrega por etapas
La entrega por etapas es un modelo de ciclo de vida en el que el software

se desarrolla por etapas, desarrollando normalmente primero las capa- ffiHffiffiffiMffij
cidades más importantes. La entrega por etapas no reduce el tiempo
necesario para construir un producto software, pero reduce sustancial-
ffiiffiffiq
mente los riesgos implícitos en su construcción, y también proporciona ffiffiffiffiffi
signos tangibles de progreso que son visibles para el cliente y útiles para
la directiva en la evaluación del estado del proyecto. Las claves para te-
ffi,ffiffiffi
ner éxito incluyen la seguridad de que la arquitectura del producto es ffi;#ffiffiffi
sólida y la definición cuidadosa de las etapas de entrega. La entrega por
etapas puede mejorar la calidad general del código, reduce el riesgo de
ffi.ffiffiffi
cancelar el proyecto y permite trabajar ajustándose a un presupuesto. ffi3wffiffi
Eficacia
lfecto sobre el riesgo de la planificación: Disminuye el riesgo
Posibilidad de éxito iniciat: Muy buena
Posibilidad de éxito a largo plazo-. Excelente
Riesgos principales
. Cambio de prestaciones.

. se puede planificar cada etapa de entrega utilizando hitos miniatura.
¡ El éxito depende de la definición de una familia de programas (parte
del diseño para el cambio).
. ofrece menos flexibilidad que la entrega evolutiva o el prototipado
evolutivo; puede servir como base para la entrega evolutiva.
. Requiere un incremento en el esfuerzo de planificación a cambio de
aumentar la visibilidad del progreso.
591
-?-----
La entrega por etapas es un modelo de ciclo de vida en donde e1 s,, . r' ,stl
se desarrolla en etapas sucesivas, y bien se muestra al cliente o se -::*5ru1
al final de cada etapa.La Figura 36.1 muestra una descripción gr.- :; ror
este modelo de ciclo de vida.
Como sugiere la Figura 36.1, con la entrega por etapas se pas3.:'-- r,m{ii
pasos de definición del concepto del software, análisis de requeri::-,=rnmr
y creación del diseño de la arquitectura del modelo en cascada. - -'r;u
se procede a hacer el diseño detallado, codificación, depuración \ ::-uimnuL
con cada etapa, creando un producto para entregar al finai de cad" -;¡¡:ulii
La entrega por etapas mejora más la planificación percibida :-: rulL
planificación real.
Progreso más visible para eldesarrollo de software personalizm,

Con algunos métodos de desarrollo de software, se completan g:-llisi
partes del ciclo de vida casi en secreto. Los proyectos técnicos s-:um
proporcionar infotmes de estado similares a <terminado en un 90 poi , i r'
Eso no es suficiente para los clientes, quienes han aprendido por su ¿r-'r:¡$li
experiencia que si el primer 90 por 100 de un proyecto ocupa el 90 pi: M
del tiempo, el último 10 por 100 del proyecto puede ocupar otro 90 pr': , 1{ri
Concepio
del software
Análisis de
requerimientos
Dir reno
gl ¡bal
Etapa 1: Diseño detallado, codilicac :"

deouración. prueba v entreaa
E|apa 2: Diseño detallado, codificac :,.

depuración, prueba y entrega
Etapa n: Diseño detallado, codificac :-

depuración, prueba y entrega
Figura 36.1 . Modelo de ciclo de vida de entrega por etapas. La entre;a :n

etapas le permite entregar un producto en etapas, tras desarrollar inicia;-:-w
los requerimientos y el diseño de la arquitectura de forma tradicionai.
\-.:"
I
Capítulo 36: Entrega por etapas 593
Es más fácil mantener a los clientes contentos cuando se les muestran

regularmente pruebas de los progresos realizados.
Para el software personalizado, un enfoque que muestra algo a los
clientes de forma regular aumenta la confianza del cliente de que final-
mente terminará el proyecto. El progreso es obvio. Mejora la percepción
del cliente sobre su velocidad.
Reduce los ciclos de entrega del producto para el desarrollo de

software (prét-á-porterr. Con los métodos de desarrollo típicos para
el software <prét-á-porteD), se define la versión 1 y luego se realiza el
diseño, la codificación y la prueba hasta que se termina. Si el desarrollo
ocupa más tiempo del planificado, el producto se envía con retraso y los
ingresos del producto llegan tarde. Si la financiación de la compañía es
inestable y 1a terminación de la versión I va lenta, es posible que nunca
se tenga la oportunidad de comenzar la vetsión 2.
Utilizando el método de entrega por etapas, puede definir versiones
internas con una granularidad más fina que la versión I y 2. Pueden definir
versiones de la 2a a Ia 2f y planear tenerlas preparadas con intervalos de
1 mes. Podría planificar tener la versión 2a preparada en 7 meses dentro
de una planificación de I año, la 2b prepatada en 8 meses, 1a 2c en 9 me-
ses, y así sucesivamente. Si cumple la planificación a I año, tendráLa2f
preparada y podrá entregar el producto completo. Si no terminala2f,ten'
drá un producto funcionando en la 2c, 2d o 2e. Cualquiera de estas versio-
nes es una mejora de la ve¡sión 1, y puede entregarla en lugar de la ver-
sión 2f. rJnavez que la entrega, puede dehnir nuevos incrementos parala
versión 3 y continuar.
Este enfoque admite entregas del producto más frecuentes y previsi-
bles. Desde el punto de vista del cliente, se han entregado dos versiones,
la I y la 2, y estas dos versiones se entregaron a tiempo. Desde su punto
de vista, desarrolló varias versiones, pero sólo entregó las dos que esta-
ban preparadas en el momento en que su compañía las necesitó.
Este enfoque requiere una coordinación sofisticada con el personal de
marketing y con la generación de la documentación del usuario, pero si
está trabajando en el mundo altamente competitivo del softwa¡e comercial,
puede ser una forma efectiva de reducir el riesgo del ciclo del desarrollo
de un producto.
Detección precoz de problemas. Cuando planifica hacer entregas ini-

ciales y frecuentes, obtiene pronto informes del progreso- frecuentes e
indiscutibles . La entrega se hace a tiempo o no. I-a calidad del trabajo es
obvia a partir de la calidad de la entrega. Si el equipo de desarrollo tiene
problemas, lo descubrirá dentro de la primera o dos primeras entregas: no
tendrá que esperar hasta que esté <<terminado en un 99 por 100> y con un
0 por 100 de funcionalidad.
Menor t¡empo de gestión. La entrega por etapas también coni;--:lurffi

mucho a eliminar el tiempo administrativo empleado por los des¿::,,Liu-
dores en crear informes sobre el progreso y otros informes de sequ-- n.*'
to tradicionales. El producto funcionando constituye un informe de :;aou
más preciso que cualquier informe en papel.
Ofrece más opciones. Aunque se sienta incómodo por entregar -, -- s*-

sión 2c a sus clientes cuando planificó entregar la versión 2f, utilizara: ru
entrega por etapas puede hacer la entrega, si 1o exigen las circuns¡a:1ru.
Finalmente, podría decidir que no es de su interés entregar la versiór -; n
aplazar la entrega para la versión 2d. Pero si no utiliza la entreg. :üm

etapas, no tendrá esa opción.
REFERENCIA Reducir el error de estimación. La entrega por etapas evita e- :n:r*

CRUZADA
Para obtener más
blema de la mala estimación entregando pronto y frecuentemenre ir
informac¡ón sobre el vez de hacer una gran estimación para el proyecto completo, puede nn*
refinamiento de las
cer varias estimaciones pequeñas para muchas entregas más pequ=,ei
estimaciones basadas
en la experiencia, Con cada una de las entregas, puede aprender de los errores de sus :sm*
consu lte maciones, recalibrar su método y mejorar la calidad de las estimaci¡m
.Recalibración", en
la Sección 8.7. futuras.
REFERENCIA Minimizar los problemas de integración. Un riesgo común er .,:s

CRUZADA
proyectos software consiste en la dificultad de integrar componentes ;Jü
sobre la ¡ntegrac¡ón se desarrollaron por separado. La probabilidad de tener serios probleras.
frecuente, consulte el
de integración está relacionada con el tiempo que transcurre entre los ;--
Capítulo 18,
"Construcción y
tintos intentos de integración. Si el tiempo entre los intentos es granie. u.
¡rrueba diarias.. probabilidad de problemas es grande. cuando se entrega el software prr:rou
y frecuentemente, como se hace en la entrega por etapas, la integrac::m
también debe realizarse pronto y frecuentemente. Esto minimiza los ::-
sibles problemas de integración.
36.1. Uso de la entrega por etapas

En la entrega por etapas, se comienza con una idea clara der producto ;..e
finalmente se entregará. La entrega por etapas es un método de desarrc,. ,;
a aplicar con el proyecto avanzado. Si está siguiendo un modelo de cick .s
vida en cascada, no necesita comenzar a planificar su uso hasta desp¡::
de que haya finalizado el análisis de requerimientos y er diseño de la ,:-
quitectura.
unavez finalizado el diseño de la arquitectura, para utnizar ra enr-:-
ga por etapas planifique una serie de entregas. como sugiere la Figura
-1r ,
de la página 592, denffo de cada etapa se realiza un ciclo completo
"x
diseño detallado, construcción y prueba, y al final de cada etapa se enr:+
un producto funcionando. Por ejemplo, si eslá desarrollando un programa

de un tratamiento de textos, podría crear el plan de entregas siguiente:
Tabla 36.1 . Ejemplo de planificación con entrega por etapas de un

tratamiento de textos
Etapa 1 El editor de textos está disponible, incluyendo edición,

almacenamiento e impresión.
Efapa2 Está disponible el formato básico de párrafos -v de caracteres.
Etapa 3 El formato avanzado esrá disponible- incluyendo la presentación

de páginas WYSIWYG y herr.amientas de formato de pantalla.
Etapa 4 Están disponibles las utilidades, incluyendo verificación de ortografia,
diccionario, revisión gramatical, guiones y fusión de documentos.
Etapa 5 Se termina la integración completa con otros productos.
La primera entrega debería ser el germen del producto que se entre-

gará finalmente. Las entregas siguientes añaden más posibilidades, de una
forma planificada con mucho cuidado. El producto final se entrega en la
última etapa.
La planificación de la primera entrega es única en el sentido de que
necesita incluir algunas ideas globales de la arquitectura, lo que provoca
preguntas como ésta: <¿Es la arquitectura del software lo suficientemente
abierta para admitir modificaciones, incluyendo muchas que no habíamos
anticipado completamente?> También es una buena idea trazat una direc-
ción general para el software al comienzo del proyecto (aunque, depen-
diendo de si desea úilizar un enfoque de entrega por etapas pura o uno de
entrega evolutiva, esta dirección general podría ser simplemente una su-
posición más probable que podrá anular posteriormente).
Paratttllizar el método de la entrega por etapas, no tiene que entregar
cada versión al cliente, y puede implementarla en un nivel de responsable
técnico. En el caso del tratamiento de textos, podría no entre,gar una r-ersión
al cliente hasta la entrega 3 o 4, o incluso la 5. Pero podría utilizar la entrega
por etapas como una ayuda para seguir el progreso, coordina¡ ls5 s*mbios
para asegurar la calidad, o reducir el riesgo de problemas de integración.
Para que el enfoque funcione bien, cada estado deberia incluir objetivos
de tamaño, rendimiento y calidad, además de objetivos de ñmcionalidad- Si
no se entrega un producto verdaderamente operatir-o al final dr cada sstado-
se va acumulando demasiado trabajo oculto conf<rrme se va ar-anzando.
Como objetivo general, intente entregar las capacidades del softn-are
desde la más importante a la menos importante. Definfu las entregas de
esta forma fuerza a las personas a dar prioridades y ayuda ¿ gliminar la
meticulosidad. Si realiza un buen trabajo, en el momento en el que haya
entregado el B0 por 100 del producto, su cliente se estará pregun::_:

qué puede haber quedado en ese último 20 por 100.
Dependencias técnicas
En una sola entrega larga, el orden de la entrega de los componeni_: :
importa mucho. Muchas entregas pequeñas de un producto requierel _:
mayor planificación que una única entrega grande, y tiene que
asegu:i:)ü
de que no ha pasado por alto ninguna dependencia técnica de la pne: -.-
cación. Si planifica implementar el guardado automático en la enrre :.
-'
será mejor que se asegure de que el almacenamiento manual no
está p,.:_ _
ficado parala entrega 4. Asegúrese de que er equipo de desarroilo re\
-.:
:
plan de entregas con el ojo puesto en ras dependencias técnicas
antes de : .-
meter a los clientes prestaciones concretas en un tiempo específico.
Trabajo centrado del desarrollador

La entrega por etapas requiere que cada desarrolrador cumpra ra fec:,
-r:
entrega para cada etapa. Si un desarroilador se pasa de una fecha i¡ .,:-
frega, la entrega completa puede retrasarse. Algunos desarrolladore :.:--
s
tán habituados a trabajar soios, rearizando sus tareas en el orden que
..
decidan. Algunos desarrolladores podrían resentirse con las restriccr =.- :
-
que impone un plan de entrega por etapas. Si les permite
a ros desa¡i: ,r-*
dores el grado de libertad al que están habituados no cumprirá las f;::,u
de entrega, y perderá gran parte del valor de la entrega por
etapas.
con la entrega por etapas, 1os desarrorladores ná pueden-disrr-. ,.
tanto como ellos quisieran. Necesita asegurarse de que lás desarrolra¿
-::
han asumido el plan de entrega y se comprometen airabajar
de acuercic : .ri
é1. La mejor forma de asegurar el compromiso
del desarrórludo. es im:--- ¡
íntimamente a los desarrolladores en ra creación del pran. Si el p,"-.
i
entrega es sa plan de entrega (y si no hay una mano dura que influenc.,
,.
trabajo) no tendrá que preocuparse por obtener su participación,
Entrega por temas

REFERENCIA una buena forma de definir las etapas consiste enutilizartemas para
CRUZADA
entrega incremental (whitaker, 1994). La definición de
-.;
Para obtener más entrejas:-:-.r
detalles sobre otro tipo provocar negociaciones a prestación por prestación, qu" pr.á.n
de temas. véase --_ ,"
mucho tiempo. El uso de temas eleva esas negociacion",
"Visión u objetivo u ur. nivel sup=: -
compartidos", en la En laplanificación de entregas mostrada en ra Tabla 36.1
de re:,:-
Sección 12.3. na 595, los temas son edición de texto, formatos básicos,
formatos , :
zados, utilidades e integración. Estos temas facilitan la
decisión sc,::: ,*
entregas en que se incorpora una característica en particuiar.
Inclus¡ . -
prestación no está clara (por ejemplo, podría crasificar
ra numeracr,:: , --
Capitulo 36: Entrega Por etaPas 597
tomática de una lista como un lormato alanzado o una utilidad), su traba-

jo resultará más fáci1 porque só1o tiene que decrdir cuál de los dos temas
es el más apropiado. No tendrá que considerar todas 1as prestaciones frente
a todas las entregas.
Cuando utilice temas. probablemente no será posible entregaf las pres-
taciones con e1 orden de prioridad e\acfo. En su lugar. planihque dar prio-
ridad a los temas por orden de importancia. r'1ueeo entresue los temas en
orden de prioridad.
REFERENCIA El uso de temas no debe tomarse como una invitación a abreviar la
CRUZADA planificación de entre-eas. Determine exactamente 1as prestaciones que
Puede utilizar hitos
m¡niatura para seguir piatrru tener en cada entre-qa. Si no 1o hace, no sabrá exactamente 1o que es-
el progreso durante p..u ..r cada estado de entrega, y disminuirán mucho las ventajas que
cada etapa. Para más
detalles, consulte el
proporciona e1 seguimiento del proyecto en este modelo del ciclo de vida.
Capítulo 27, .Hitos
miniatura..
Tipos de proyectos
La entrega por etapas funciona mejor para los sistemas que se conocen
bien. Si no está seguro de las prestaciones que debería tener su producto,
entonces el método de entrega por etapas no es una buena opción. Tiene
que conocer el producto 1o suficientemente bien para planificar las etapas
cuando termine el diseño de la arquitectura.
La entrega pof etapas funciona especialmente bien cuando ios clien-
tes están deseosos de comenzar auttlizar una parte relativamente pequeña
de 1a funcionalidad del producto. Puede proporcionar un ser\'icio de gran
vaior a sus clientes si puede proporcionar el 20 por 100 de1 producto que
más necesitan en una parte del tiempo de desarrollo necesario para el pro-
ducto completo.
La entrega por etapas es también un métodc aproprado Dafa pro\.ectoS
muy grandes. Planificar una serie de cuatro provectos 'f,e 9 meses e s r-onsi-
derablemente menos arriesgado que planificar un único pio) -u-itr de i años.
Probablemente para un proyecto de ese tamaño tendrá etapas oentr.t de
las etapas; incluso un proyecto de 9 meses es demasiado largo Fara pro-
porcionar una buena visibilidad a los clientes, y se deberia dir idir en \ a-
rias entregas incrementales.
La entrega por etapas sólo funciona bien en sistemas en los que pue ie
desarrollar independientemente subconjuntos útiles del producto. L¿ n;-
yoría de los productos para el usuario final se pueden definir de ta1 ton¿
que se pueden hacer entregas intermedias significativas antes de enirega:
el producto final. Pero los sistemas operativos, algunos tipos de sis::n:s
incorporados, y otros tipos de productos podrían no ser utillzables sin ula
funcionalidad completa o casi completa, para esos tipos de sist¡rnes. -a
entrega por etapas no es apropiada. De forma que si no puecie in:o-;¿r
cómo dividir la entrega de un producto en etapas. la entrega por ii3f ;S :1rr
es ei enfoque apropiado.
36.2. Gestión de los r¡esgos de la entrega por etapas

El apartado anterior podría hacer pensar que la entrega por etapas
na casi siempre, pero recuerde esta restricción.
Cambio de prestaciones. El mayor riesgo asociado a la enrr;¡. ;,ir-

etapas es el riesgo de cambio de prestaciones. cuando los clien:;¡ : l*
mienzan a ufllizar la primera entrega del producto, probablemenre - ¡ü ü
querer cambiar lo que han planificado para las demás entregas.
REFERENCIA La mejor forma de gestionar este riesgo es no utllizar 1a er:::ril
CRUZADA
Para ver una var¡ación
por etapas si no está seguro de las prestaciones que necesita desa::: _;m".
de la entrega por La entrega por etapas pura no ofrece mucha flexibilidad par& re Sl: rriry"
elapas que funciona
a las peticiones de los clientes. La entrega por etapas funciona -t ,i'
mejor cuando los
requer¡m¡entos no son cuando tiene un consenso amplio y profundo sobre 1o que debe inc--_ *
estables, consulte el producto.
Capítulo 20, "Entrega
evolutiva.. Si decide utilizar la entrega por etapas, aún puede reservar tier::,: s
1a planificación para acomodar las prestaciones desconocidas. poú--.
"u-
finir la última etapa como Ia etapa para hacer cambios de últim¿ :.:r-
Asignando ese tiempo, deja claro a los clientes que intenta ser fl¿._:, r¡.
pero también deja claro que espera limitar el número de prestacion--i :É.-
conocidas a implementar. Desde luego, cuando llegue a la última ::;*
puede renegociar la planificación si los clientes desean más presra;.-r**.
de las que se pueden implementar en el tiempo disponible. por en::-,:s,
los clientes tendrán el software funcionando en sus manos, y podn.- -rl-
cidir que su objetivo de planificación inicial no es tan importante ; -,:l*l
parecía en un principio.
Además de estas prácticas específicas parala entrega por etapa_..:r,$-
de utilizar.cualquier otro medio general para gestionar el cambio d=:::-
taciones. Éstos se describen en él Capítulo 14, <Control del coniu-:: ,u
prestaciones>.
36.3. Efectos secundarios de la entrega por etapas
Además de su efecto positivo en la planificación de proyectos. -, =n*

trega por etapas puede beneficiar muchas otras características de_ :¡r-
yecto.
Distribución más uniforme de los recursos de desarrollo y prum.

Los proyectos que utlliza.n la entrega por etapas constan de'arilrs:--rr
ciclos de planificación, análisis de requerimientos, diseño. codi:-:-";,:m
y prueba. El diseño no está aglomerado al principio, la pro-era:::.: :ru
no está aglutinada en la mitad, y la prueba no está concentrada ¿- ----¿,
*-
Puede distribuir los recursos de análisis. programación y prueba más

uniformemente que con los métodos má*s cercanos al modelo de cascada
pura.
Meiora de la calidad del código. En Los enfc'tlr,¡'e> tradicionales, sabe

que <alguien>> tendrá que leer el código v rnantgnerlo. E>to proporciona
una motivación abstracta para escribir un busn cod,igu.. Con la entrega por
etapas, sabe que usted necesitará leer 1' modifrcar el cu-.Jigo muchas r-e-
ces. Esto proporciona una motivación concreta para escribir un buen có-
digo, lo cual es un incentivo más fuerte (Basili y Turner. 19-5 1-
Mayor probab¡lidad de terminar el proyecto. Un proyecto de entre-

ga por etapas no se abandonatá tan fácilmente como un proyecto con el
modelo en cascada. Si el proyecto se enfrenta con problemas de financia-
ción, es menos probable que se cancele si el sistema está completo en un
50 por 100, es operativo en un 50 por 100, y está en manos del usuario
final que si está terminado en un 90 por 100, no funciona nada, y nunca
ha sido probado por nadie fuera del equipo de desarrollo.
Apoyo para trabaiar a¡ustándose a un presupuesto. La premisa

de la entrega por etapas es que hay que entregar algo útil tan pronto como
sea posible. El proyecto estará parcialmente terminado, aunque los clien-
tes se queden sin dinero. Al final de cada estado usted y sus clientes pue-
den examinar el presupuesto y determinar si pueden afrontar el siguiente
estado. De esta manera, aunque se seque la fuente, el producto aún podria
ser bastante utilizable. En muchos casos, el último 10 o 20 por 100 de1
producto consta de posibilidades opcionales que no son parte importante
del producto. Incluso si se pierden unos cuantos adornos, los clientes ob-
tendrán la mayoría de las posibilidades necesarias. Si el dinero se acaba
al llegar al 90 por 100, piense que los clientes estarán más felices con u.n
producto funcionando en su mayor parte que si hubiera utilizadrr el mcrde-
lo de ciclo de vida en cascada pura (y <90 por 100 terminado,, signiLfiu-ara
<0 por 100 operativo>).
36.4. lnteracciones de la entrega por etapas con otros

métodos
Aunque presentan algunas similirudes. la enuega Fror etapa-i Eü es una
forma de prototipado. El prototipado es erploratono. 1 ia enuega pL-¡r eta-
pas no. Su objetivo es hacer risible el proereso. o poner sofrq-are úril en
manos de los clientes con más rapidez. -d diferencia del prototipadLr. se
conoce el resultado final cuando se cornienza el proceso.
Desarrollo y gest¡ón de proyectos informáticos
Si el método de entrega por etapas le proporciona menos il.-,, : rilrrul

de la que necesita, probablemente pueda utllizar en su lu-qar...:¡"ew¡
evolutiva (Capítulo 20) o el prototipado evolutivo (Capítu1o i - : ,mrr
clientes obtienen la entrega de la etapa 1 y ie dicen que 1o que es:: : r!E¡-
ficado para la entrega de la etapa 2 no les interesa, tendría qu. s:: n:il.
testarudo para no cambiar de rumbo. Si conoce lanafuraleza ge_-,:: ü#
sistema que está construyendo, pero aún tiene dudas sobre aigun,:.
'-,Tcl -
tos significativos, no utilice la entrega por etapas.
La entrega por etapas se combina bien con los hitos minia,:, ilr.
pitvlo 27'). En el momento en que alcance cada etapa, debería tene: . -: u,.
mientos suficientes sobre lo que está construyendo para organtzar -.-. r rmlrr,f
con detalle.
El éxito del desarrollo de un conjunto de entregas por etapas c.::rJtu
del diseño de una familia de programas (<Definición de famili&S ,*. :-*
gramas)), en la Sección 19.1). Cuanto más siga este método de :..t, ,
podrá evitar mejor el desastre si los requerimientos resultan fir€rrt-: : rr!.
bles de lo que pensaba.
, Láte¡.r,tregqirpgf retapás,fq-.siémp.r! tigae. que,sei,tan:¡Jgidá ¿¡¡¡¡o'se desclr-h.

en este capítulo. A veces. se desea esquematizar un producto compll-
to, y entregarlo por etapas, como se describe aqui. A veces deseará r¡¡¡
rnayor flexibilidad (definir más rigidamente las etapas iniciales y seel=
con mayor flexibilidad en las erapas sucesivas¡. A veces d"r"aiá t ic<
evolucionar el producto a lo largo de su desarrollo, como en el protoripac!*
evolutir. ó (Capírulo 2 I ).
,,, r €sfe, capíryl¡,,des€iibe la versión más rigida.de,la' enfiega por er&
.p*s:,párarprop0rcionar un contraste claro entré'éllt¿,1é¿tun, extiemo de
la escala) y el prototipado evolutivo (en el olro). para su uso propior_
puede adaptar la enrrega por elapas (o entrega evolutiva o pro,orip"-
do evolut.ivo¡ a las necesidades especificas de su proyecto. y llurn*,
como guste.
36.5. Puntos cruc¡ales de la entrega por etapas

REFERENCIA La base del funcionamiento de la entrega por etapas es que, aunqL-
CRUZADA
Para obtener más
reduce e1 tiempo de desarrollo necesario para construir un proü---
información sobre la software, reduce el riesgo que conlleva la construcción de rn pr.,--.,,
impo¡'tancia de hacer
visible el progreso,
to, y proporciona señales tangibles de progreso, que pueden ser ra: .::.
consulte la Sección 6.3, portantes para el desarrollo rápido como lo es el propio tiempo de;..i-
"Percepción y reaildad.. rrollo.
------!
36.6. Claves para el éxito en el uso de la entrega

etapas
Éstas son las claves para tener éxito en la entrega por etapas:
Asegurarse de que la arquitectura del produc¡s ¿dmite todas las di-

recciones futuras del software que pueda imaginar.
Definir la primera etapa de entrega de forma que pueda entregarla
tan pronto como sea posible.
Definir las etapas de entrega en términos de temas, y asegurarse de
implicar íntimamente a los desarrolladores en la definición de temas
y en las posibilidades específicas de cada tema.
a Entregar los temas en orden de importancia.
a Considerar si 1a entrega por etapas pura proporcionará mayores
beneficios, o si lo haránla entrega evolutiva o el prototipado evo-
lutivo. Considere con cuidado cómo piensa gestionar las peticiones
de cambio de los clientes.
Gilb, Tom: Principles of Sofnuare Engineering Management. Wokingham,
England: Addison-Wesley, i988. Los capítulos 7 y 15 hacen un pro-
fundo tratamiento sobre la entrega evolutiva y la entrega por etapas
(Gilb no hace distinción entra ambas). Gilb fue una de las primeras
personas en hacer hincapié en el valor de los métodos de desarrollo
incremental como los citados. Ha tenido una experiencia directa utili-
zando el método en grandes proyectos, y gran parte del enfoque
de gestión descrito en el resto de su libro está desarrollado partiendo de
su uso.
]
37
Gestión Theory-W
En un proyecto software participan muchos implicados con intereses

ffi
opuestos, incluyendo a los jefes, desarrolladores, usuarios finales, clien-
tes y personas de mantenimiento. Theory-w proporciona un entorno ffi
de tiabajo para la gestión de proyectos orientado a la reconciliación de ffi
intereses opuestos. Se basa en la realización de un esfuerzo explícito
para comprender lo que necesitan para (tener éxito" las diferentes ffi
partes implicadas, negociar conflictos entre las condiciones de éxito
ffi
de los implicados y estructurar el proyecto de forma que todos alcan-
cen sus condiciones de éxito. Theory-w reduce la planificación mejo- ffi
rando la eficiencia en las relaciones laborales, mejorando la visibilidad
del progreso y reduciendo el riesgo.
sffi
.:,.:,: EfiCaCia
Posibilidad de éxito inicial: Excelente
Posibilidad de éxito a largo plazo'- Excelente
',1'ji::t:,,.
Riesgos principales
Ninguno.

. Diseñado para su uso combinado con el modelo de ciclo de vida er
espiral.
. Particularmente efectivo durante las negociaciones de planlfica-
ción.
r Se basa en el uso del método de negociación conveniente
603
{ÉF-
Un enfoque práctico de gestión que ayuda al desarrollo rápidc =. I

nominado <Gestión Theory-W> (Theory-W Management) tB::nm
Ross, 1989). Theory-W toma su nombre de su principio más in:'::;
Make everyone q Winner (Hacer que todos ganen).
La mayoría de los proyectos software comienzan con un -r:-;,1
implicados en el proyecto que tienen objetivos contrapuestos. La T¡:.;i 11.
muestra los implicados y sus objetivos típicos:
Tabla lmplicados en un proyecto y sus objetivos
Clientes Jefes Desarrolladores Usuarios Mant

finales
Planificación Sin Diseño interesante Muchas Sin de-i:--:r

rápida retrasos P res tac ion es
Presupuesto Sin E,xploración de Software Buena

bajo sorpresas nuevas técnicas amigable docum¡:--¡:
para el
usuari o
E,xito en el No tenertrabajo Software Fácilrne:::

proyecto desagradable rápido modit'ic':,:
Vida Software
familiar robusto
Fuente: Adaptado de <Theory-W Softrvare Management: Principles and Er

(Boehm y Ross, 1989).
Como se aprecia en la tabla, muchos de los objetivos entran ¡:, :

flicto. El objetivo de los usuarios finales de tener (muchas presta;'-l
podría chocar fácilmente con los objetivos de los clientes de <planit-::''
rápida> y (presupuesto bajo>. El objetivo de los desarrolladores ;
<diseño interesante> podría chocar con los objetivos de los clie:::.
una <planificación rápida)), y su objetivo de <no tener trabajo desa-er;-':
podría entrar en conflicto con el objetivo de las personas de manten::-:
de <una buena documentación>.
La mayoría de 1os equipos del proyecto no rcalizan un buen::;:üry¡
para reconciliar esos objetivos. Como resultado, a veces un prolic;: lur¡q
para el cliente parece una tortuga sedada, para los desarrolladore: : *lstüur
parecer que lleva un ritmo mortal de desarrollo rápido.
La gestión Theory-W de proyectos software defiende que ha;;: ;ur
todos los impiicados salgan ganando en un proceso de softvu'are .: unrui
condición necesaria y suficiente para que un proyecto software se :-:: ur
con éxito. Los proyectos que definen escenarios donde todos p:;:-,1-r ,n
unos pierdan y otros ganen no tendrán éxito.

CaPítuto 37: Gestión TheorY-W 605
La gestión Theory-\\- apo) a e1 des¿rrollo ráprdo colocando a todos

los implicados en el mismo lado de ia mesa de negociación. Los con-
flictos entre estos grupos son la base cie la rn¿rona de los problemas de
gestión de los proyectós sofnrare. r'ai-ectan a l: ¡osit'rlidad de establecer
y
ios objetivos, áelinir las lechas de entrega. d:: pn..ridad a las tareas
adaptarse a los cambios'
ispecíficamente, ia gestión Theorl-\\-sotrt.,a ei desarrollo ráprdo
en
los siguientes aspectos'
REFERENCIA objetivos más claros del proyecto. Los ob-ie¡i"'t'rs del proveu-ttr e stár
identi-
CRUZADA
claios desde el principro. )-a que un prLr'e cto The'rn -\\- cLlmienza
Para obtener más de los rrrplicados La ne-
información sobre la ficando las condiciones de ,,éritc-¡" de "-aúa'¿no
reiuerza v documenta
importancia de tener gociación que tiene lugar al comienzo de1 prol ecto
clara es pro-
ios objetivÁs del prol'ecto. Establecer los objeti'os de tbrma
objetivos claros,
consulte -Definición de
obietivos", en la bablemente 1a clar'e más importante para moti\'ar a los desarrolladores. 1.
Secc¡ón 11.2
lamotivacióndelosdesarroliadoresesprobablementelaclal.emásim-
portante para ei desarrollo rápido.
Mejoresrelacionesconelcliente.Muchosproyectosseconfigurande
forma qrr" proporcionan ganancias para los clientes y pérdidas
para 1os
cuando
d"rar.oiludores, o viceversa. Es difícil mantener buenas relaciones
mejoran por su
una de las partes está perdiendo. Los proyectos Theory-W
propia naluralezalas rólaciones entre los desanolladores y los clientes, por-
que todos están ahí Pata ganar.
la
REFERENCIA Hay varios ahorios en la velocidad de desarrollo que se deben a
CRUZADA
mejora de las relaciones con el cliente:
Para obtener más
detalles sobre la
utilización de las . Mejora de la eficiencia, debido a 1a mejor comunicación y la mejor
relaciones con los en
clientes para meiorar la coÁprensión por parte del cliente de la función que desempeña
velocidad de el proYecto.
desarrollo, consulte el
CaPítulo 10,
. Disminución del trabajo repetido, porque se realiza mejor la tarea de
.Desarroilo orientado analizar los requerimientos. Las negociaciones sobre los detalles
centra-
de las prestaciones llevan menos tiempo porque todos están
al cliente".
dos en los objetivos principales que desean lograr'

o piani-
Establecerpronto los óbjetivos produce unas expectatir as de 1a
ficación realistas, 1o qué mejora la velocidad de de sarr.'11" ¡ercibida
y elimina los problemas asociados con las planii-l;:c:t'ri! e\ü-si-
vamente oPtimistas'
Reducción del riesgo relacionado con el cliente' Har nuchtrs

riesgos originados por parte de1 cliente ia;n; leiacit-rn de desarroi't'. in-
cluy-endoümbios áe prestacione:. JIi; j\):t-.rniüaüión lenta ) uni {is::ün
a pÁqueña escala. Estatlecer una re,¿.-io:i Theon'-\\-
con e1 cliente :,-uia a
---Gp
minrmízar o eliminar tales riesgos. Ayuda a gestionar los ries:::¡

quedan, ya que tiene a la vista los riesgos relacionados con los ci:=
puede obtener pronto signos de su existencia.
37.1. Utilización de la gestión Theory-W
Cuando uflliza el método de gestión Theory-W, al comienzo del r::.

ha reunido a todo el mundo y ha identificado sus condiciones i¡ :
Luego todos negocian para crear un conjunto de condiciones de ¡
nivel del proyecto que pueden alcanzarse razonablemente. En el resu
proyecto, la gestión consiste en controlar el proyecto para asesui::
cada implicado continúe ganando. Si uno de los implicados
perder, se ajusta el proyecto según coresponda.
Hacer que todos ganen

REFERENCIA El mejor trabajo para desarrollar situaciones en las que todos los imp:
CRUZADA
ganen se ha hecho en el campo de la negociación. A continuación se
sobre la negociación y tra un esquema de un proceso general que puede utllizar para est¿f
los cuatro pasos de una situación de gananc ia a partir de ser positivos (getting to yes t t :
Gett¡ng to Yes, véase
la Sección 9.2, y Ury, 1981):
"Disminución de la
presión de la
planif icación". l. Separar a las personas del problema.
2. Centrarse en los intereses envez de en las posiciones.
3. Inventar opciones para beneficio mutuo.
4. Insistir en el uso de criterios objetivos.
La Tabla 37.2 mtestra un resumen sobre la aplicación de

de éxito global en la gestión Theory-W.
Tabla 37.2. Pasos en la gestión de proyectos Theory-W
1. Establecer un conjunto de precondiciones donde todos ganen ¿¡1s5 ds --rrü[

el proyecto:
r Comprender la forma en que las personas quieren ganar.
r Establecer expectativas razonables por parte de todos los implicac.*
o Adecuar las tareas de las personas con sus condiciones de éxito.
r Proporcionar un entorno que soporte los objetivos del proyecto.
\F
-=F-
Capítulo 37: Gestión Theory-W
Tabla 37.2. (Continuacíón)
2. Estructurar un proceso software donde todos ganen:

a Establecer un plan realista.
a IJttlizar el plan para controlar el proyecto.
a Identificar y gestionar los riesgos donde todos pierden o donde unos pier-
den y otros ganan.
Mantener implicadas a las personas.
3. Estructurar un producto software con el que todos ganen:
¡ Adecuar el producto a las condiciones de éxito de los usuarios finales y de
las personas de mantenimiento.
Fuente: Adaptado de <Theory-W Software Project Management: Principles and Examples>

(Boehm y Ross, 1989).
Los pasos de la Tabla 37.2 se describen en las siguientes secciones.
Paso 1: Establecer las precondiciones donde todos

ganen
En Theory-W, el primer paso consiste en establecer los objetivos del pro-
yecto que va a permitir que todos ganen. En este caso, la palabra (precon-
diciones> se utiliza con el significado de <<criterios de entrada>: si no puede
imaginar cómo hacer que todos ganen, no comience siquiera el proyecto'
Para completar el paso 1, es necesario que comprenda la forma en que
las personas desean ganar, establecer expectativas razonables por parte
de todos los implicados, hacer corresponder las tareas de las personas con
sus condiciones de éxito, y establecer un entorno de apoyo.
Comprender la forma en que las personas desean ganar. Artes

de intentar entender la forma en que las personas desean ganaf, asegúrese de
identificar a todas las personas clave. Muchos proyectos han fracasado
porque un implicado clave (un subcontratado, el departamento de marke-
ting, el grupo de usuarios, o el grupo de soporte del producto) no estaba
incluido.
Póngase en el lugar de los otros implicados para comprender lo que
necesitan para ganaf . comprenda que lo que necesitan los clientes. las
personas de marketing y los usuarios hnales seÉ probablsmente diferente
a lo que usted necesitaria. De estos grupos- el que babitualmente es más
importante de entender (y el que suele estar menos repres€ntado) Es el
de los clientes. Hay que trabajar duro para comprender las condiciones de
éxito de los clientes.
l
El método Theory-W funciona bien, aunque uno de los rr:,: ::
sea un caradura que esté empeñado en aprovecharse de ustei - :l

demás implicados. El objetivo de Theory-W es hacer que todos,r--:n.
no puede estructurar el proyecto de forma que todos ganen. no :;r -i
proyecto. Si puede ganar teniendo un caradura implicado, perfec:: :
no realice el proyecto (no tiene sentido hacerlo si se va a crear L-- :i:
dor). Cuando utilice Theory-W con un caradura en el otro lado d¿ .,
de negociación, podría salir un poco peor que si el Sr. Pérez esr!'..::i
el otro lado de la mesa. El caradura podría conseguir más de i,: :¡'
corresponde, pero eso es perfecto siempre que el resto pueda s;;_i-
canzando sus condiciones de éxito.
Establecer expectativas razonables. E1 segundo subpaso par¿ -!

cer las precondiciones donde todos ganen es establecer unas expe.--¡:'
razonables. No se puede hacer mucho para establecer un proyec:. _.r
todos ganen si los clientes quieren la Luna y la quieren en 6 serl:--ji.

REFERENCIA Si considera que algunas partes tienen expectativas irrazonable." -*
CRUZADA
Para ver sugerencias
a los implicados para identificar las expectativas y resolver los er:,:::,
sobre la negociación los clientes insisten en que se entregue el producto dentro de 6 sen-r;cr
de disconformidades
en Ias expectativas de
los desarolladores están convencidos de que no pueden hacerlo -:
planif icación, véase nos de 6 meses, hay un problema. A menos que pueda alinear las er-:,r
la Sección 9.2, tivas de los clientes y de los desarrolladores, una de las dos parre: sli
"Disminución de la perdiendo en el proyecto, y el proyecto fallará.
presión de la
planif icación". A continuación se muestran algunas acciones que pueden
que las expectativas de las personas cuadren con la realidad:
Hacer que las personas vean los temas desde los puntos de '.,::; üfu
los demás.
REFERENCIA Relacionar las expectativas de las personas con la experienci" _.tu$tu
CRUZADA
Para consultar las referencia a hechos históricos o a la opinión de expertos para ;=i:m
tablas de las 1o que es realista y 1o que no. Si su cliente o su jefe desea des.::: ,lLllu¡
planificaciones más
cortas posible para
un producto en menos tiempo del empleado por la organ: r: ium
proyectos de dislintos normalmente en el desarrollo de un producto de tamaño sil;::,- ¡uL
tamaños y tipos, expectativa es probablemente poco realista. Si desea desarr.-i,; m
consulte la Sección 8.6,
"Estimaciones simples
producto en menos tiempo del empleado hasta ahora en des"::" lirr
de planificación.. un producto de ese tamaño en la industria en general. dei-t:-_:'t¡-
mente es poco realista. Utilice referencias históricas para cü:,:: lil¡[:
las expectativas poco realistas sobre la planificación, funciol", - ru¡r
coste y otros atributos del proyecto o del producto.
o Relacione 1as expectativas de las personas con modelos bi::. :irt-
brados. Si su organización no ha recogido datos de su exper-=::,riL
o si las personas no toman en serio esos datos, utilice los res*_-;u'+,
de un modelo de estimación del software. Esto puede ser es:..:.i,!r!*
mente efectivo porque permite a los implicados ajustar los :.:-:re-
lE.*
Capítulo 37: Gestión TheorY-W 609
tros del proyecto en tiempo real y conocer los posibles efectos en

el funcionamiento del Provecto'
éxito.
Adecuar las tareas de las Pefsonas oon sus c-ondiciones de
MuchasVeces,laspersonasnotieneninfluenciasobrelosaspectosdel
el pro-
proyecto que les permitirán ganar' Esto es desmotivante' 1- aboca
yecto al fracaso.
que puedan con-
En su lugar, asigne las tareas a las perscrna-< de forma
>e muestran al-
seguir sus p-ropias condiciones de érito" -{ ccntinr¡ación
gunos ejemplos sobre cómo podría hacer estct:
g6di$o saan respons¿I-
Hacer que las personas que mant*átr t¡
inicial'
bles de su reviiión y aprobación durante el desrrollo
Encargar a los desarrolladores la estimaciin del
ti€u+t(' que nece-
sitarán paru acabar las tareas que van a talin-

En"urgu, a los usuarios f,rnales la rerisión de }oi
guionñ rniciales
o proátipo. del software para temasde frr-Ill¡d
de wc'-
Iniica, a los desarrolladoies el objetivo erplicito de crrar diseños
que puedan implementarse de forma fiable 1- ripi<irmerne"
qr¡É s€ \ Írn a
Én"árgu, a los clientes de identifrcar las prescimes
incluir y las que se van a excluir para hacer ta pLmincrm
lo más
corta posible.
. Encargar a los clientes el seguimiento del esdo dd ¡ro3-ecto'
El objetivo común es la necesidad de buscar siu¡rrmo crE[rr?s üTdr

todosganen'Algunasdeestassituacionesnecesitaránestnr[E¡relpo-
y"lro á" forma iiusual, pero eso es perfecto' El proyecto ¡fÚfri mes
ér-lto
por ello.
Proporcionar un entorno que soporte los obietivo€ d F@'

de rig dÉ .-a"{2
El tipo de entorno que va a netesitar dependeni del punto
l*ptl"udo. Para los desarrolladores' normalmente signiñca profrüErrroar
fonnación,hardwareacÍualizadoyherramientassoftg.a¡enoderr¡a'<-Para
de Brro-'
los clientes, podría requerir formación en métodos moderncx
gru-u"iOn y utilización de un modelo de ciclo de vida q'* pryF*ffi
signos tangibles de Progreso.
Paso 2: Estructurar un proceso de softwar'e

donde todos ganen
proceso de
El segundo paso importante en Theory-W es la creación de tm
softwáre que hará que todos ganen. Para ello, es necesario
egableer un
plan para conffolar el provecto- iden-
plan realisia del proceso, utilizat el
tificar y gestionar los riesgos en Ios que todos pierden o unoi

otros ganan, y mantener comprometidas a las personas.
Establecer un plan real¡sta. La planificación es cla\,e F'a:;

éxito con el enfoque Theory-W. El plan marca el camino para;:
resultados en los que todos ganen. Recoge el compromiso mu:-r:
implicados en el proyecto sobre un conjunto de condiciones de :
mutuo y con todas las implicaciones de estar de acuerdo para cc,1*l{
Si finalizó el paso l,habrá establecido expectativas razonables. i
que establecer expectativas razonables es una precondición para i¡i¡'-a' n
yecto. Si no puede establecer expectativas razonables, no conri:r:
proyecto. Las expectativas razonables hacen que el trabajo de pla:_*'
resulte mucho más facil, porque le permiten crear un plan realista. \¡
luchar contra las expectativas poco realistas en cada párrafo 1z en cr-:¡
Utilizar el plan para controlar el proyecto. IJnavez que ha ;:

plan, es necesario que lo siga. Hay demasiados planes eu€ S€ cr-r;
en material de archivo. Si se da cuenta de que no está siguiendc :
corrija el proyecto de forma que siga el plan, o revise el plan de i¡--::¿
pueda seguirlo. El plan proporciona un marco de trabajo para detec=
en las condiciones de éxito y rcalizar las correcciones necesan.:" fi
sigue el plan, es probable que no alcance un resultado donde tod¡s
ldentificar y gest¡onar los r¡esgos donde todos p¡erden y

unos pierden y otros ganan. La gestión de riesgos es un asFi;irLl
ve del método Theory-W, y se aplican los seis pasos básicos de la ga
riesgos del Capítulo 5, <Gestión de riesgos>. Para cada una de 1as ci
nes de éxito de los implicados, debería identificar un riesgo de r,: ,,
sus condiciones de éxito. Luego controle ese riesgojunto con los re:
riesgos de su proyecto.
Mantener comprometidas a las personas. Theory-W es un::

orientado a las personas. y es importante mantener comprometidos .
los implicados durante todo el proyecto. Los implicados esrai¡-
preocupados que nadie por sus propias condiciones de éxito, ,v m
comprometidos a los implicados en revisiones, planificación, con:
progreso, negociaciones de cambio en las prestaciones y otras acrii-_
ayudará a conseguir un resultado en el que todos ganen.
Paso 3: Estructurar un producto software

con el que todos ganen
Además de estructurar el proceso para tener éxito, en Theory-\\- r¿-rr,m!l
hay que estructurar el producto para tener éxito. Esto incluye tanrr.
-.;w-
tos externos del producto, qué verán los usuarios finales, como ar-rilm,
Capituto 37: Gestión Theory-W 611
internos, qué verán los desarroliadores r el personal de mantenimiento.

Desde el punto de vista del usuario final. el pro'Jucio será un éxito si es
fácil de aprender, fácil de utllizar r fiable. De>de ei punto de vista del
personal de mantenimiento, el producto deberia esmr trien documentado,
programado con un buen estilo y fácilmente motiit-icable.
Tipos de proyectos que pueden usar Theory-W

La gestión Theory-W se puede comenzar a aplicar durante cualquier t-ase.
aunque resulta más útil cuando se apiica desde el principio de1 provecto.
Si ha tenido unas relaciones dificiles con un cliente. podria desarrollar un
análisis de beneficio mutuo. para localizar las posibles condiciones don-
de todos pierden o donde unos pierden -v otros ganan que son el origen de
las dificultades. Theory-W puede ayudarle a manrener una ejecución flui-
da de un proyecto con éxito, y puede ayudar a recuperar un proyecto que
tiene problemas.
Theory-W funciona mejor cuando es defendido por un directivo supe-
rior o por alguien lo suficientemente alto para utilizarlo con los clientes y
con los restantes implicados. Si no es posible obtener el apoyo de un su-
perior, aún puede utilizarlo a nivel de responsable técnico o de desarro-
llador individual para ver por qué los restantes implicados en el proyecto
actúan de la forma en que lo hacen.
No hay límite en el tamaño o el tipo de proyecto que puede utllizar
Theory-W. No necesita mucho tiempo de gestión, de forma que se puede
utllizar para proyectos pequeños. Los proyectos más grandes tendrán más
implicados y condiciones de éxito más complicadas, y en dichos proyec-
tos 1o más importante será identificar y crear las condiciones de éxito.
Theory-W es tan adecuado para el mantenimiento como para el nuevo
desarrollo, y es tan adecuado para el softu,are <prét-á-porter) como para
el software de gestión o de sistemas. Los implicados específicos cambian,
pero no el valor de encontrar sus condiciones para tener éxito.
Función del directivo

La función del directi'o en Theory-w es diferente de la función de éste
en otras teorías de gestión. En otras teorías, el directivo juega un papel de
jefe, entrenador o repartidor. En Theory-W, los directivos gestionan más
cosas que sus informes directos: también gestionan las relaciones y objeti-
vos de los implicados. En este esquema, el directivo es un negociador con
la responsabilidad de dar soluciones al proyecto que hagan que todos ganen.
Además de esto, el responsable también tiene que establecer los objeti-
vos y controlar su progreso. Día tras día, el responsable busca los conflic-
tos donde todos pierden o donde unos pierden y otros ganan, se enfrenta a
ellos, y los cambia para obtener situaciones donde todos ganen.
I
t-
37.2. Gestión de los riesgos de la gestión Theory-w

REFERENCIA No hay riesgos particulares intrínsecos en el método de gestión
CRUZADA de The¡:, -
W. La gestión Theory-W eleva la posibilidad de que algún implicado
Estas técnicas son las p"=l'
mismas que las resultar perdedor a la categoría de riesgo, y eso da lugar a
utilizadas para dos rie.-.=
controlar los riesgos.
genéricos para un proyecto Theory-W.
Para obtener más
detalles, consulte el
Capítulo 5, .Gestjón una de las partes comienza a entrar en una condición de pérdida
de riesgos". cuando una de las partes comienza a entrar en una condición de pérdr*
la reacción más apropiada es rlevar a cabo un análisis de beneficio
mu..,
cuando se presentan probremas. es fácir hacer correcciones apresurac:i
que den lugar a resultados donde todos pierden o unos pierden
y oir!.:
ganan' Pero normalmente es posibre seguir ros pasos de iheory-w
pa::.
crear acciones correctoras, que hagan que todos ganen o minimicen
i."
pérdidas, comparándolas con otras acciones posibles.
, Las partes implicadas pueden redefinir sus condiciones de éxito cc:-
forme el proyecto va progresando. A continuación se muestra
un ejer-
plo. En un principio, 1os clientes podrían haber establecido la
fecha ¿=
entrega para el 1 de mayo como una de sus condiciones de
éxito. conft-:-
me e1 proyecto ava..za, podrían darse cuenta de que no es posible
enff.-
gar ei proyecto hasta el I de junio, creando una posible
de pe:-
"onái"ión
dida. En ese momento, el criente podría decidir que aún puede
ser un éxi:-
si la fecha de entrega es anterior ar día I de julió, y esto sitúa
de nuevo e
proyecto en una posición donde todos ganan.
vrrq condición
Una vvr¡vrervrr uE pérdida lrega
de pcrr.¡rua inevitable. La premisa
llega a ser rnevrtabrg. premi d; ,L
gestión de proyectos Theory-w rr es
wr que
vuv convertir
lurrvsltll ad todo gl Inunoo en ganac,
LUuu el -u.rdo gana( 't-
es una condición suficiente y necesaria para
el éxito de un proyecto. si ,i-_
la cerfeza de que el proyecto va a fallar, párelo tan rápido
,.u posib,-:
"o*o
37.3. Efectos secundarios de la gestión Theory-w
Dependiendo de las condiciones de éxito de ros impricados,
Theon,-\\
q""-d" proporcionar grandes ventajas de mayor alcance qu" iu eficie::,1
de la planificación. Puede proporcionar mejoras en la faciridad
de *¡:
mantenimiento, satisfacción del cliente y moral del equipo.
Theory-W también proporciona unas bases excelenles para adapi" , ,
metodologías software a un proyecto específico. Muchas metodorc¡,,

tratan menos el <porqué> que el <qué> de las cosas. En Theory_W
ei , :: _
qué> es necesario para crear ganancias para todos ros

impricados. cu"-:
se documentan las condiciones específicas de ganancia
áe ros implic";,,
en la planificación del proyecto, se tiene almacenado de
forma p..r',..-.-
Capítuto 37: Gestión Theory-W 613
te el <porqué>. E,sto proporciona importante información para cuando

adaptar las metodoiogías futuras a circunstancias específicas. También
ayuda a determinar 1a cantidad de cualquier metodología que es suficien-
te para el proyecto. '
37.4. lnteracciones con otros métodos de gestión

Theory-W
La gestión de proyectos Theory-W es particularmente adecuada para ser
uttllzadacon ei modelo de ciclo de vida en espiral (Sección 7.3, <Espiral>'
y Capítulo 35). Puede identificar las condiciones de éxito de los implicados
para'cadaiteración de la espiral al comienzo de 1a iteración. Los implica-
dos pueden modificar sus condiciones de éxito durante cada iteración, 1o
cual mantendrá altos niveles de satisfacción durante el proyecto.
Theory-w es útil durante las negociaciones de planificación (Sec-
ción 9.2). En vez de centrarse en el estilo de negociación tradicional (tres
meses;no,seis;yodigocuatro;no,cinco;deacuerdo,cuatroymedio),
puede dejar claro que, a menos que ambas partes esperen ganar a\ hacer ei
proyecto, laparte que espera perder no tiene una base racional para seguir
el juego.
37,5. Puntos cruciales sobre la gestión Theory-W

No hay datos cuantitativos disponibles sobre el volumen de las reduccio-
nes en la planificación derivadas del uso de Theory-W, pero aparente-
mente Theory-W reduce el riesgo de la planificación y puede mejorar la
velocidad de desarrollo. En los ejemplos de prueba, Theory-w ha funcio-
nado bien (Boehm et a|.,1995).
37.6. Claves para tener éxito en el uso de la gestión

Theory-W
A continuación se muestlan las claves pata utllizat con éxito la gestión
Theory-W:
¡ Entender cómo desean ganar las personas.

o Establecer expectativas razonables para todas las partes implicadas.
. Adecuar las tareas de las personas con sus condiciones de éxito.
o Proporcionar un entorno que soporte los objetivos del pro¡'ecto.
o Establecer un plan realista.
. Utllizr el plan para controlar el proyecto.

o Identificar y gestionar los riesgos donde todos pierden y dono:
pierden y otros ganan.
a Mantener comprometidas a las personas.
a Adecuar el producto a las condiciones de éxito de los usu¿::x
nales y personal de mantenimiento.
Boehm, Barry, y Rony Ross: <Theory-W Software Project Managi?d:
Principles and Examples>>, IEEE Transactions on Software Ens:
ring, julio 1989. Este artículo trata sobre Theory-W. Va acompri
de conclusiones sobre principios de negociación adecuados y la ¡
logía de las relaciones con el cliente. Contiene un ejemplo ercai
que describe un proyecto software típico y analiza cómo se le p;
aplicar Theory-W.
l*- .-
38
Prototi pos desechables
Con los prototipos desechables, se desarrolla código para explorar fac- #ffiTffi
tores críticos para el éxito del sistema, y posteriormente se desecha ffi*hffi
este código. La implementación de los prototipos usa lenguajes de pro- ffi
gramación y/o métodos de desarrollo más rápidos que el lenguaje y
ffi
los métodos definitivos. La interfaz de usuario es generalmente el ele- ffiHWffitrffi
mento más prototipado habitualmente de un sistema, pero hay otras ffi"Yffi
partes de algunos sistemas que también pueden beneficiarse del proto-
ffi
tipado. Usado como herramienta auxiliar de la especificación de requeri- É#"*51i&C!üt!üSl**i*fi g
mientos, el prototipado desechable puede acelerar los proyectos basa-
dos en modelos de ciclo de vida tradicionales, como los proyectos DoD. WEffi
.*ffif"ffiÍgf{*
Puede iniciarse a nivel de directiva o a nivel técnico.
Eficacia
Riesgos principales
o Mantener un prototipo desechable.
. Uso ineficiente deltiempo de prototipado.
. Expectativas poco realistas de planificación y presupuesto.
Interacciones y equilibrios principales

Ninguno.
Los prototipos desechables derir an su mejora en la velocidad de desarrollo

del hecho de que a menudo es posible explorar opciones individuaies de
requerimientos, diseño e implementación, usando lenguajes y técnicas
615
que permiten un desarrollo más rápido del ofrecido por ios i;:;;;r ll
técnicas definitivos de la implementación. Aquí tenemos algunos
=
¡ Necesita comparar aproximadamente cuánto tiempo neL-e :'---li

almacenar y recuperar 10.000 registros usando varios SC:-
tintos, por lo que escribe códigos desechables para probar i: . > -
y comparar su rendimiento.
¡ Sus usuarios finales no acaban de decidirse entre dos esi:-:
terfaz de usuario, por lo que prepara dos interfaces de usual- -
herramientas de desarrollo de interfaces y les ofrece a los .
una demo <en vivo> sin escribir siquiera una línea de coc-
o Desea comprobar la viabilidad de comunicarse con otra a: :.iiiirüml
antes de basar sus decisiones de diseño futuras en esta capar-tJrl rrmr
lo que escribe código de prueba para verificar si esa comui--:idllrm
es posible. El código de prueba no contiene comprobación d; :.-;rmm
y no controla ninguna excepción, y 1o desechará tan pron:: :,l,m
haya comprobado que puede comunicarse de la forma que :.:3 jirül-
Puede usar prototipos desechables en cualquier fase de un p:,- ,:;nr

para clarificar requerimientos, para decidir una cuestión de disenc, : : rr¡i{-
para comparar las opciones de diseño o implementación, o para i.-=.t:"r,,'*
bar la optimización del rendimiento.
38.1. Uso de protot¡pos desechables

Los prototipos desechables pueden ser usados por cualquier miern:: _ Lm
proyecto. Los participantes individuales del proyecto pueden obi-:-: ,irL.
gunos beneficios prototipando áreas de riesgo dentro de sus parcel"r :,,n.
viduales de responsabilidad. Ésa es una lista de las áreas que pueü-- ru-
neficiarse dei prototipado, incluyendo sugerencias sobre el desarr.- - Lm
prototipos simples en dichas áreas:
REFERENCIA c Interfaz de usuario. Prototipe usando una herramienta de l:_:;l-

CFIUZADA
pado o lenguaje de programación visual, o construya un de;::iirü¡'
sobre el prototipado de película en el lenguaje de programación definitivo.
de interfaces de
usuar¡o. consulte
o Formatos de informes. Prototipe usando un tratamiento de ie:,-:,: ,
el Capítulo 42, una herramienta de formato de informes.

"Prototipado de la . Formatos de gráJicos. Prototipe usando una herramienta de t,: _ L
¡nterfaz de usuario..
o una biblioteca de gráficos.
Organización de bases de datos. Prototipe usando un leng;. ; ;s
diseño de bases de datos, un 4GL o una herramienta CASE
Rendimiento de bases de datos. Prototipe usando un 1en-s-'_.: is
diseño de bases de datos, un 4GL o una herramienta CASE
Capítulo 38: Prototipos desechables 617
o Precisión e implementación de cálculos complejos. Prototipe usando

una hoja de cálculo o un lenguaje de carácter matemático, como el
APL.
o Partes con respuesta crítica en el tiempo en sistemas en tiempo
real. Protottpe usando un pequeño programa de prueba en el len-
guaje de programación definitivo.
o Rendimientos de sistemas interactivos. Prototipe usando un peque-
ño programa de prueba en e1 lenguaje de programación definitivo.
o Viabilidad de partes del sistema que van más allá del estqdo del
arte o con las que el equipo de desarrollo no tiene experiencia.
Prototipe usando un lenguaje de programación visual, un pequeño
programa de prueba en el lenguaje de programación definitivo o un
lenguaje de carácter matemático (según sea adecuado).
Como puede ver, puede resultar provechoso prototipar muchas áreas

de un programa. Sin embargo, si comprende bien su programa, no proto-
tipe por el mero hecho de prototipar.
38.2. Gestión de los r¡esgos de los prototipos desechables

Generalmente, los prototipos desechables suelen tener éxito. Sin embar-
go, es necesario estar al tanto de varios riesgos al planificar un proyecto
que va a utilizarlos.
Mantener un protot¡po desechable. Uno de los problemas claves al

desarrollar un prototipo desechable consiste en que el prototipo podría no
ser desechado. A menudo, los directivos deciden que una vez que se ha
desarrollado el prototipo, va a costar mucho <volver a hacer>> el sistema,
e insisten en la evolución del prototipo para obtener el producto final
ERROR CLASICO (Gordon y Bieman, 1995).
¡Evite esta trampa! Entregar un prototipo desechable puede dar lugar
a un mal diseño, poca faciiidad de mantenimiento y un bajo rendimiento.
Si piensa desarrollar un prototipo desechable. asegúrese de que 1a directi-
va y el equipo técnico están de acuerdo en desprenderse de é1. Aseeúrese
de que todo ei mundo comprende que está creando sofru.are de usar r'
tirar, que no es suficienternente robusto tara s3r ¡resto en Droduccicin. rr
suficientemente fuene para serrir cr'rnri--¡ base para ei ::ciuc:¡ r-ilal. \o
está creando sofnvare real.
Si cree que puede erol-t¡cioriar ei p,rr.toirpo en lilga: de ti¡a¡io.:i:nee
desde el principio usar un ¿¡f¡rqui ú\'Lalu::\ o. ,je manera que ei oiseir-i i
la implementación del protoiipo soporren plenamente e1 desarrolio con-
pleto final.
En 1o que respecta a 1a obieción de que desechar el prototipo
mucho, aunque es relativamente cierta, larazínpor la que se cre¿ m

totipo desechable consiste en que es más económico desarrolla¡ u
tipo desechable, aprender las lecciones necesarias con el mínirn¡ ¡
luego implementar el código real con menos errores de aquello: m
que se incurriría si no se cteara inicialmente el prototipo desech¡5r.
piensa que hay algún otro método que va a resultar más eficiente c
to al costo en una situación específica, úselo. En otro caso. en ,".rgm
añadir costes adicionales, los prototipos desechables suponen el
más económico disponible.
REFERENCIA Uso ineficaz del tiempo de prototipado. Como en el p

CRUZADA
evolutivo, a menudo los proyectos pierden tiempo durante el
sobre el uso ef¡ciente desechable, alargando innecesariamente el plan de desarrollo. A
del tiempo de prototipado es por su naturaleza un proceso exploratorio, esto no
prototipado, consulte
"Uso ineficaz del
ca que tenga que ser un proceso sin un período definido.
tiempo de Controle cuidadosamente las actividades de prototipado. Tra=
prototipado", en la
Secc¡ón 20.2. prototipo desechable como un experimento. Desarrolle una hipótesr=
ésta: <Una ordenación basada en disco clasificará 10.000 registros en
de 30 segundos.> Entonces asegúrese de que la actividad de
sigue estando centrada en probar o refutar la hipótesis. No deje cñE
pierda en áreas relacionadas, y asegúrese de que el prototipado se
tan pronto como la hipótesis haya sido probada o rechazada.
REFERENCIA Expectativas poco realistas sobre la planificación y el

CRUZADA
puesto. Como con los restantes tipos de prototipado, cuando los
sobre la creación de directivos o vendedores ven progresos rápidos en un prototipo, a
expectalivas realistas realtzan hipótesis poco realistas sobre la velocidad con la que puedc
respecto a la
planificación y el sarrollarse el producto final. A menudo se subestima ampliamente el
presupuesto, consulte necesario para pasar de la implementación de un prototipo desecFnrlft
la sección
la implementación en el lenguaje definitivo.
"Expectativas poco
realistas sobre la La mejor forma de combatir este riesgo consiste en estimar etr o
planif icación y el
presupuesto", en la rrollo del prototipo y el desarrollo del producto final como pror
Sección 20.2. separados.
38.3. Efectos secundarios de los prototipos desechables

Además de sus ventajas para el desarrollo rápido, los prototipos d
bles producen muchos efectos secundarios, la mayoúa de los cuales
sultan beneficiosos. El prototipado tiende a:
Reducir los riesgos del proyecto (puesto que las áreas con riesgi
exploran pronto).
Mejorar la facilidad de mantenimiento.
Capítulo #: Prototirys desechables 619
¡ Ofrecer resistencia frente al cambio de requerimientos.

¡ Ofrecer una buena opomrni¿lad para formar a programadores sin
experiencia, puesto que el código que escriban será desechado de
todos modos.
38.4. lnteracciones de los protot¡pos desecüables

con otros métodos
Puede usar el prototipado de una u otra clase en la mayoría de tipos de
proyectos, independientemente del resto de métodos usados. Incluso en
los proyectos en los que no se puede usar el prototipado evolutivo com-
pleto (Capítulo 2l), a menudo puede seguir usando prototipos desecha-
bles para explorar las áreas clave que presentan riesgos.
38.5. Puntos cruciales de los prototipos desechables

La mayor contribución de los prototipos desechables a la reducción de la
planificación se debe a su potencia para la reducción de riesgos. Puede
que no reduzcan en absoluto una planificación, pero al explorar pronto
las áreas de alto riesgo, reducen la volatilidad de la planif,rcación. Los
beneficios directos en la planificación derivados de los prototipos dese-
chables dependen del área específica prototipada del producto.
Steven J. Andriole está dedicado a la modelización de requerimien-
tos y al prototipado desde 1980. y es el autor de Rapid ,lpplicarion Pro-
totypíng (Andriole, 1992). Dice que la lección más importante que ha
aprendido en su trabajo es que el método de prototipos desechables.
cuando se usa para clarificar los requerimientos, <<siempre es efectivo res-
pecto al coste y siempre mejora las especificacionesr> (énfasis del autor)
(Andriole, 1994).
38.6. Claves para el éxito en e¡ uso de prototipos

desechables
Éstas son las claves para usar con éxito los prototipos desechables:
o Seleccione su lenguaje o entorno de prototipado basándose en la

velocidad con la que le permitirá crear código desechable.
o Asegúrese de que tanto la directiva como el equipo técnico estan
de acuerdo en desechar el prototipo desechable.
620 Desarrollo y gest¡ón de proyectos informáticas
o Centre los esfuerzos de prototipado en áreas que no sean b:- :

prendidas.
. Trate las actividades de prototipado como expenmentos c 1e:::
y realice un seguimiento Y control cuidadoso de las misr¡:.¿"
Para más información sobre el prototipado, consulte e1 Capítulo 21.
tipado evolutivo>.
+-=-rE
39
Desarrollo en ventanas
temporales
Eldesarrollo en ventanas temporales es un método orientado altiempo

de construcción, que ayuda a infundir un sentido de urgencia en un ffi
equipo de desarrollo, y ayuda a mantener la atención dei proyecto en
ffi
las prestaciones más importantes. El método de desarrollo en ventanas
temporales extrae su ahorro en la planificación redefiniendo el producto
para adaptarse a la planificación, en lugar de redefinir la planifica-
ffiffi
ción para adaptarse al proyecto. Es más aplicable en software interno
ffi
de gestión, pero puede adaptarse para su uso en partes específicas de
proyectos de software
"prét-á-porter> o para clientes. El éxito de las
ventanas temporales depende de su uso exclusivo en tipos apropia-
dos de proyectos, y en la voluntad de los directivos y usuarios de re-
cortar prestaciones en lugar de reducir la planificación.
Eficacia
lfecfo-sobre el riesgo de la planificación: Disminuye el riesgo
Riesgos principales
. lntentar aplicar ventanas temporales a productos donde no resulta
adecuado.
. Sacrificar la calidad en lugar de las prestaciones.

. Depende del uso del prototipado evolutivo.
. sacrifica el control del conjunto de prestaciones a cambio del con-
trol del tiempo de desarrollo.
|,at::'::tül
621
622 Desarrallo y gestión de proyectos informáticos
A menudo se combina con JAD, herramientas CASE y

evolutivo en Proyectos RAD.
Puede combinarse con la entrega evolutiva cuando los plaz: =
:*
entrega son más importantes que el contenido'
Resulta curioso ver la cantidad de cosas que puede hacer el día a:-:'¡
l'
salir de vacaciones. Puede recoger la ropa de la tintoreúa, pagar li; " *-*
recoger el correo y el periódico, comprar ropa nueva para el via-ie '
:-- --
el equipaje, comprar carretes de fotos y dejarles la llave a 1os re' :
tguui O" impresionante resulta ver todas las cosas que no hace a:-'=' -,
salir. Parece que no necesitaría pasar tanto tiempo en la ducha esa ::-'*'
na, o leer el periódico con tanta tranquilidad por la noche. Podri.
.=--:
muchas otras cosas que deseaba hacer ese día. Pero algunas de estas
:- "
ridades diarias caen repentinamente.
El desarrollo ,rantunu, temporales es un medio para trasladar ¡ - -
"n : ::
mo sentido de urgencia que acompaña a la preparación de unas vacac' -
prepara para un trabajo duro! C 'r;
¡exceptuando que generalmente se
,. rigu. e1 método de desarrollo en ventanas temporales, se especr-':- -
cantidad máxima de tiempo que va a dedicar a la construcción de -:- ¡ -
tema software. Puede desarrollar todo 1o que quiera o el tipo de s

:¡*
que quiera, pero tiene que restringir ese desarrollo a una cantidad '" '-1-ú1u'
tiempo. Está sentido de urgencia produce varios resultados que so: -
el desarrollo rápido.
BEFERENCIA Hace énfasis en la prioridad de la planificación. Al convertir ., , -"

CRUZADA nificación en algo absolutamente fijo,lleva la planificación a su Il'i- :l
importancia. El límite de tiempo o <ventana temporal> es tan imp"'::':;
sobre el comprom¡so -
entre recursos Y que anula todas las demás consideraciones. Si el alcance del proyecto : -,--
atr¡butos del producto a
con el límite de tiempo, reducirá el alcance para adaptarse al iín:"' ':
cambio de beneficios en
la planif icación, consulte tiempo. El propio límite de tiempo no puede cambiar'
la Sección 6.6,
"Equilibrio de factores
de la velocidad de Evita el problema del 90-90. Algunos proyectos llegan a un pu:':: ii
desarrollo". el que están terminados en un 90 por 100, y permanecen en este:--: L
-
duránte meses o incluso años. Muchos proyectos pasan una cantida¡ -,.
bida de tiempo en agujeros negros que no hacen avanzar el proyect,;'. :,:'
consumen grandes cantidades de recursos. Primero construye ufls l;--L:
ña versión, y 1a construye rápidamente para pasar a la versión 2 E: :::
de construir una primera versión rica en prestaciones, a menudo:.:-- l.;
más eficaz tener una versión básica funcionando, aprender de l: - :,
.
eRRon clÁstco
riencia, y construir una segunda versión sobre la primera'
Aclara las prioridades de las prestac¡ones. Los ProYectos

emplear una cantidad de tiempo desproporcionada teorizando s L'- : i
prestaciones que al final suponen poca diferencia en la utilidad ¿a :""
Capítulo 39: Desarrollo en ventanas temporales
ducto. <¿Debemos emplear 4 semanas adicionales impiementando la pre-

sentación preliminar a todo color. o basta con teneria en blanco y negro?
¿El borde 3D de nuestros botones debe tener 1 o 2 pixels de ancho? ¿Nues-
tro editor de código debe volver a abrir los archir os de texto en la última po-
sición en 1a que fueron usados o al principro de1 archivo?> En lugar de em-
plear tiempo discutiendo sobre 1a inclusión o no de prestaciones de <muy
baja> o <moderadamente baja> prioridad, 1as restricciones estrictas sobre
el tiempo centran 1a atención sobre 1a parte alta de la lista de prioridades.
REFEBENCIA Limita la meticulosidad por parte del desarrollador' Dentro de ios

CRUZADA
Para ver más detalles
límites especificados, a menudo se puede implementar una determinada
sobre la forma en que prestación de varias formas. Generalmente, existe una versión que nece-
puede producirse sita dos días, dos semanas o dos meses de la misma prestación. En la
¡nvoluniariamente la
meticulosidad, véase ausencia de la presencia clarificadora de una ventana temporal de desa-
"Objetivos poco claros rro11o, 1os desarrolladores pueden seleccionar una implementación basa-
o imposibles", en la
Secc¡ón 14.2. da en sus propios objetivos de calidad, facilidad de uso o nivel de interés
en el diseño e implementación de la prestación. Los límites temporales
aclaran que si existe una versión de una prestación a desarrollar en dos
días, ésa es 1a buena.
ffi
DATOS REALES
Controla el cambio de prestaciones. El cambio de prestaciones es
generalmente una función del tiempo, y se lleva alrededor del 1 por 100
del esfuerzo en muchos proyectos (Jones, 1994). El desarrollo en ven-
tanas temporales le ayuda a controlar el cambio de prestaciones en dos
sentidos. En primer lugar, acorta e1 ciclo de desarrollo, reduciendo el tiempo
de1 que dispone e1 personal para pensar en nuevas prestaciones. En se-
gundo lugar, algunos cambios de prestaciones aparecidos en proyectos
largos se deben a 1os cambios en las condiciones del mercado o en el
entorno de funcionamiento en el que se va a implantar el sistema infor-
mático. Al recortar el tiempo de desarrollo, se reduce el tiempo durante
el que puede cambiar este entorno de mercado o de funcionamiento, y por
tanto se evita la necesidad de los cambios correspondientes en su software.
REFERENCIA Ayuda a motivar a los desarrol¡adores y usuarios finales. Las per-

CRUZADA
sonas desean sentir que el trabajo que realizan es importante, y una sensa-
sobre la motivación. ción de urgencia puede contribuir a que sientan esa importancia. La sen-
véase el Capítulo 11, sación de urgencias puede ser un fuerte factor de motivación.
"
lvlotivación..
39.1. Uso del desarrollo en ventanas temporales

El desarrollo en ventanas temporales es un método de constn.-;
fases. Los desarrolladores implementan primero ias prestacior-s :l--'!
ciales, y luego las menos esenciales según ei tiempo de que .-!: - --,-:
-.*-r
sistema crece como un cebolla, teniendo las funciones esencial¡.

núcleo y las restantes prestaciones en las capas exteriores' La Fiq*:'
ilustra el proceso de las ventanas temporales.
. REFERENCIA En el desarrollo en ventanas temporales, la construcción cont';
CRUZADA el desarrollo de un prototipo y su evolución hasta obtener el sister-.
Para más detalles
sobre este t¡Po de en estado operativo. Generalmente, el uso de ventanas temporaies ::: l;l*-
prototipado consulte el ye una fuerte implicación del usuario final, y revisiones constel:::: l@l
Capítulo 21,
Prototipado sistema en desarrollo.
Las ventanas temporales suelen abarcar entre 60 y 120 días' C - nt*
"
evolutivo".
ríodos más cortos generalmente no se pueden desarrollar siStemas s'=rlí*
cativos. Con períodos más largos, no Se crea la sensación de u:'=lr;¿u
Propuesta
Necesidad de una
mejora del sistema
a gran escala
lmplantar sistema
Figura 39.1. Ciclo de desarrollo en ventanas temporales' EI desa": ': m

ventanas temporales consiste en construir y hacer evolucionar un p';::rtrof
evolutivo con una frecuente interacción con el usuario final.
Capítulo 39: Desarrollo en ventanas temporales 625
generada por centrarse claramente en el tiempo. Los proyectos que resul-

tan demasiado grandes para su desarrollo en un plazo de 120 días pueden
dividirse en ocasiones en varios pro'ecrLrs. pudrendo desarrollar cada uno
de ellos en un plazo incluido entre 6t-r r llCr días.
Tras la fase de construcción. el sisrema es er aluado, y es necesario
seleccionar una de estas tres opcirrnes:
o Aceptar el sistema I'ponerlo ec pro,iu,-;t.in.

o Rechazar el sistema. debido a '::: l¿ii¡ d¿ construcción. puede
teneruna calidad insut-rciente. Lr e- 3r:i:"- de desarrollo quizás
no habría podido implemenrar ia
"-¿::::i¡d mirlma de funcionali-
dad necesaria para el grupo dei s:si¡=.:.- i: es :':. 1a organización
puede lanzar un nue\o estue:2..:;::s:::,.--.'-:t \cntanas tem-
porales.
o Rechazar el sistema debido i ü*i:.ua ¿:-¡:¡ -¿s re,-¿sidades de la
organización que 1o ha consmi:d"." L: ,:,t:3-J:.-: cei sistema básico
identificado antes de corrxerlzar ¿, ies:::.---; ::- l-tr 'rinrana tem-
poral puede ser el resultado ce::e:--¡::: -.'=;,: ..brenido por un
equipo de desarrollo. pero ,os .s-;::-,,s ::-¿:- :::::::inar en este
momento que el sistema n¡-. es ¡:;-:i ---a--, r:_ ii:3 --¡so. el tra-
bajo comienza de nuevo en ,¿ e-:¡ ¿; :=:--:-: - -: ::- s:s:¡na. como
se muestra en la Figura 39.i"
Las personas que er.aiúan ei sister:: -:-:.: tt:=:,"< :.a: -r:t *st-upo que
incluye el promotor ejecutiro. uflü Lr
=1i _-i:- := : .,:.:. i t-ilrisen-
tante de mantenimiento o control rie ca-:-l :- r:p-i:::: j:--,t '" e, personal
de auditoría también pueden eSt3r r':-:-,;¿.i.-,i :: : :-L:- ::',-,-
lndependientemente del resu-t.i¡- :.:: -- --.-::- - ,-:=c' ;lazr-r del
desarrollo en ventanas temporaler:¡.---;:--::: J-=:- s.::-:-:e ei pe-
ríodo de tiempo. La fecha i-lnal d¿ -. --::--::---=r;::- --.- -: .t:l3.rbú/¡ú
comprometida. Es un pla:o lín:::¿. i- ;: ':.- -- :---:- --: ;:- -.3ai3nas
temporales tiene que tener ciaro üi; -u- lri::¡--.: :f::-'-'j:
"- -l;:¿. i.el
período será lo que se ponga ¿n -*:;:-:-1-'-::; : :;:.-.i,: -.: .¡..r{J-
nización ha excedido sus fecha-. -:-::¡ :: ;=:--¿:¿-i ::::.-:"-;s iii rtrtr&S
ocasiones, los desarrolladores lrr] rü3irir- i: r:.: -.
método perderá gran parte de s:: ...-¡:
=;-. -::::r:e. i'el
Criterios de entrad a para el desarrollo en ventanas

temporales
Las ventanas temporales nü :e 3i:.f.'i J iüjL-Is i{-rs dpos iie cie>an-o,j... -\
continuación vamos a dar algur:as ol¡e.-rlces que puede usar pare 3segrr-
rarse de que se adaptan a su prLrvacio"
Lista priorizada de prestaciones. Antes de que pueda cotr-:,:-l- i

construcción en una ventana temporal, es necesario definir e1 :::_-: Lr¿;
las funciones y el diseño del sistema. Los usuarios finales o -..::.-;

necesitan haber priorizado las prestaciones del sistema, para que ,c. :. ,*
rrolladores sepan cuáles son fundamentales y cuáles opcionales. J-:;r:
haber definido un conjunto básico mínimo de prestaciones, que i,:- .-
tar seguro de poder implementar dentro del período correspondie:--: r ;r
ventana temporal. Si no se puede realizar esta priorización, ei sís:---, r
se adapta bien al desarrollo en ventanas temporales.
REFERENCIAS Estimación real¡sta de la planificación creada por elequipo de m*

CRUZADAS
sarrollo en ventanas temporales. El equipo de desarrollo deb¡ ::'-r'
sobre la motivación y una estimación para la construcción dentro de la ventana tempc'-: :
la definición de equipo de construcción necesita estimar tanto el tiempo QUe necc: .: -:
obletivos realistas
consulte "Definición de neralmente entre 60 y 120 días) y la funcionalidad que piensa qu.:-: ;r
objetivos", en la implementar dentro de este período. Desde un punto de vista de ia :.. :-
Sección 11.2, y la
Sección 43.1, .Uso de vación, es esencial que el equipo cree su propia estimación. El des"::.
las horas extras en ventanas temporales es un método ambicioso, y no tendrá éxit.. - .
voluntarias..
presenta simplemente a 1os desarrolladores una combinación imp,.. : ,,
de objetivos de planificación y funcronalidad.
REFERENCIA Tipo apropiado de proyecto. Las ventanas temporales se adaptan .r-

CRUZADA =-:.
a software interno de gestión (software SI). Las ventanas temporale s . r
sobre lenguajes un método de prototipado evolutivo, y deben construirse con leng:,- :
que soporten la para desarrollo rápido, herramientas CASE u otras herramientaS QL- r.-
generación rápida
porten la generación extremadamente rápida de código. Las aplicac,-
de código consulte
el Capítulo 31 , muy personalizadas que requieran codificación manual no suelen re s- r-
'
.Lenguajes para
desarrollo rápido proyectos adecuados para el desarrollo en ventanas temporales. Anr<. :¡
(LDR)". comenzar un proyecto en ventanas temporales, compruebe que puede c:,,-
truir el proyecto con el conjunto de herramientas y el equipo dispon,:-=",
lmplicación suf¡ciente del usuario final. Como en otras activii,:=,

basadas en prototipado, el éxito del desarrollo en ventanas temporales ::-
pende de tener una buena realimentación por parte de los usuarios fln",--
Si no puede lograr la implicación adecuada del usuario final, no use _:-i,
ventana temporal.
Equipo para ventanas temporales

REFERENCIA Un equipo de desarrollo en ventanas temporales puede consistir de -:-, I
CRUZADA
Para más información cinco personas. El <equipo completo de ventanas temporales> tarl-1.:
sobre grupos de trabajo incluye a los usuarios finales que han sido seleccionados para alus:- _
eficaces, consulte el
Capítulo 12, "Equipo equipo de construcción. A menudo, estos usuarios finales están deJ-:.-
de trabalo". dos a tiempo completo a su papel de soporte del equipo de construc;-:
Its=--..-.
Capítulo 39: Desarrollo en ventanas temporales 627
El equipo de ventanas temporales necesita estar formado en el desa-

rrollo de sistemas con el soft$'are de desarrollcr que se yaaufllizar. En un
proyecto desarrollado en \-entanas ienop,--rrales- no har-tiempo para apren-
der a usar un nuevo softr¡'are.
El equipo de ventanas temporales nür-€>iu e:rar rnu\. motivado. La
urgencia creada por el método de desarroll-r ü:l f ilrioa,i iemporales ofrece-
rá por sí misma parte de la motir ación. L¿ c¿l¿;:*Ld de nocrar un nivel de
productividad poco usual dentro dE l3 ¡r¡gpriz¡;ir-rr ij.ebe ofrecer el resto.
Aunque mi conocimiento de la moril-eciurr ,1e -*= ,Jesar"rolladores no
me hace partícipe de sus consejos. Jarnes \hrrin :¡cc:*:eqd-¿ que la moti-
vación implicada en un proyecto en rentans-< r;=t¡:. ¡s -:::bién debe
incluir los siguientes puntos (Martin. l99l r:
Indique a los desarrolladores que :enán r[ertrr ücES].tr:,CLrs sl crean

un sistema que sea aceptado. Desuque que le -!--i,r3 ie *i,¡erzos
de desarrollo en ventanas temporaies tienen ia::¡. 1 ;¿e ¿ilos no
van a ser uno de los pocos casos en los que ¡e :i-:
lndique a los desarrolladores que si tienen iutra ffi :iJrr:]F]ensa-
dos, y que sus esfuerzos se harán llegar a nrrs _ c:- E;¡ ¡endlente
de que reciban las recompensas.
o Diga a los desarrolladores que si tiiai- ¡r-:.-. -..:e.e::aran por
todo lo alto. Realice esa celebracion.
No use los consejos de Martin al pie de -:' -=z s-- tc--: tinelrr la
interacción con su entorno de los tema-. des.'r:;r ;- C.=::*,¡ -,- ,.\fo-
=
tivación>.
Variaciones del desarrollo en yentanas temporales

-.:
Generalmente, las ventanas temporales -e ¿pi:cr:: :s€ "E ¿i.ü¡ 1 !¡-rfl-.r-
trucción de software de aplicación, \orr'.,¿-=f,= :*: r il=ri¡': bl¿n al
desarrollo de productos <prét-á-pomer*- ,ie¡süi ¿ cs -.rg,n :emp¡s de
desarrollo que necesitan. Pero las r ¿r'-;:r. :-fLar:-s l:-c3: :esutrtar
muy útiles como estrategia para el desu:r.-l.- je :¿--- -- r=-:=-. l-i¡ are:
prototipos operativos de interfaces tie us¿-l--.- !a fr]:$:a\ drs.-lrbles en
un proyecto de software <prét-á-prt.ns^"-. La* l-l=:-i ::==r=-;s para
los prototipos son mucho más cona-< ¡u::- -:=::i:.---3--ü¿:.i t3:J:os
sistemas de información, puede que del .-rór óe ¡ ¿ -l ,r¿s ;: ,;gar,Je
60 a 120. El equipo de desarrollo te¡rá ;l:e ¡eir::::¡,i -,i:=:.¿:en¡..rratr
que tenga sentido para el prototirto ü>_:no,-ii.-ü ütie ilrir üttrf,_--:--iir,Jo"
Puede usar ventanas temporaln e! r.rt? san \ aried¿d nje acn"-ld,¿,ies de
implementación: construccion de scüs-ere- generación de pannl,las ,tre a¡u-
da, documentación de usuarirr. prororrF\h d*arrollo de cursos
'lesechables-
de formación, etc.
39.2. Gestión de los r¡esgos del desarrollo en ventanas

temporales
Estos son algunos de los problemas planteados por las ventan¿s:::-t-
porales.
lntentar ajustar en ventanas temporales productos que no sÉ

adaptan. No recomiendo usar ventanas temporales para las acti., -:.:.
DATOS REALES iniciales (o actividades del principio de la cadena alimenticia). ct¡n _ ¡
planificación, análisis de requerimientos o diseño de un proyecro. ,c,-,::r
el trabajo en estas actividades tiene grandes implicaciones en las ---'
posteriores. Un error de 100 dólares en el análisis de requerimientos p _-:r
costar posteriormente hasta 20.000 en su corrección (Boehm 1' P":,--
cio, 1988). El coliseo de los proyectos software está sembrado cr.:_ ..!
huesos de los responsables de proyecto que han intentado acortar las ,::- -
vidades iniciales y han entregado tarde el software debido a que pe;-:-
BIBLIOGRAFIA ños errores iniciales han supuesto grandes costes al final del pro¡-ec:- _
ADICIONAL
Para ver un punto de <ahorro> de tiempo en 1as fases iniciales del proyecto es generalmen:- -i
vista dif erente sobre ahorro lalso.
las ventanas
temporales en Las ventanas temporales resultan efectivas en actividades del final -. _i
actividades iniciales cadena de desarrollo, ya que el perjuicio por el trabajo de baja c¿.-;:
de los proyectos,
véase "Timeboxing. se limita a desechar el trabajo rcalizado en ese período de tiempo '. ---.-
(Zahniser, 1 995). cerlo de nuevo. No se afecta a otros trabajos.
REFERENCIAS Sacrificar la calidad en lugar de las prestaciones. Si su clien:- ..

CRUZADAS
se compromete a la necesidad de recortar prestaciones en lugar de ca.-,-::
sobre los efectos de dentro del método de ventanas temporales, no use una ventana tempr..:
los obletivos
Los desarrolladores lo pasarán mal intentando cubrir objetivos conl-i,:- -
conflict¡vos, véase
"Definición de
vos, y si el cliente insiste en una planificación altamente restringida.
objetivos", en la calidad y grandes cantidades de prestaciones, los desarrolladores nLr :,-
Sección 1 1.2. Para
más información drán alcanzar estos tres objetivos simultáneamente. La calidad se ', i:i
sobre los efectos de la resentida.
mala calidad, véase
la Sección 4.3, "Bases Unavez que la calidad comienza a deteriorarse, la planificación :.:-_-
del control de calidad.. bién sufrirá. El equipo producirá un software con todas las prestacir-:-;:
cuando llegue elplazo final de la ventana temporal, pero la calidad -.=-,
tan mala que se necesitarán varias semanas más para llevar er produc:: .
un nivel aceptable de calidad.
Cuando se emplean correctamente las ventanas temporales. el s. '-
ware es aceptado o rechazado cuando llega el final del período. Esto c=_
suficientemente claro que el nivel de calidad tiene que ser aceptab,;
=
todo momento. El éxito de las ventanas temporales depende de poder c *:
plir planificaciones estrictas limitando el alcance der producto, no sjr ::
1idad.
Capítuio 39: Desarro"'c en ','ectanas temporales
39.3. Efectos secundarios del desarrollo en ventanas

temporales
La influencia del desarrollo en r.ent¿i"s::::::::'-:s :s:: limitada a la re-
ducción de las planificaciones de de s¿i:,r--¡. ,1.:::'-:-;:t:- ito tiene nin-
guna influencia (positiva o nesatirzl Su1r13,";"-,¿=;. -.c:1riad de uso,
funcionalidad u otros atributos del p:l;*;:':'
39.4. lnteracciones del desarrollo en ventanas temporales

con otros métodos
El desarrollo en ventanas temporales es un tipo específico de método de
diseño por planificación (Sección 7 .7). Es una parte esencial del RAD. 1o
que implica que a menudo se combina con JAD (Capítulo 24), herramien-
tas CASE y prototipado evolutivo (Capítulo 21). Como el desarrollo en
ventanas temporales exige un grado poco usual de compromiso por parte
del equipo de desarrollo, también es importante que cada miembro del
equipo esté comprometido (Capítulo 34) con el proyecto.
Las ventanas temporales también pueden combinarse con la entrega
evolutiva (Capítulo 20) si necesita definir cada tipo de entrega más bien
en función del tiempo necesario que de la funcionalidad exacta que entre-
ga. De forma similar, el software <prét-á-porter) y otros tipos de proyec-
BIBLIOGFIAFIA
tos pueden usar ventanas temporales como parte de un enfoque por eta-
ADICIONAL pas, de entrega interna. La entrega del software en intervalos bien definrdos
El proceso de hitos
usado por Microsoft
ayuda a controlar el progreso y la calidad de1 producto en er olución. La
puede considerarse mayoría de productos que usan ventanas temporales de esta lorma no ne-
como un enfoque cesitarán desperdiciar ei trabajo que no se complete al terminar el plazo,
modificado de
ventanas temporales. por lo que no usarán ventanas temporales puras. De iodos modos. pueden
Para más detalles, seguir aprovechando pafie de los benel-icios a nir el de motivación, priori-
véase Microsoft
Sec/"ets (Cusumano y
zación -v control de prestaciones otiecldos por e1 desar¡olio en ventanas
Selby,1995). temporales.
39.5. Puntos cruc¡ales del desarrollo en ventanas

temporales
El desarrollo en ventanas temporales se ha mostrado extremadamente pro-
ductivo en DuPont, donde se desar¡ol1ó inicialmente. DuPont consigue
DATOS REALES
implementar 80 puntos de lunción po: persona y mes con ventanas tem-
porales, en comparación con los i5 a l0 obtenidos con otras metodolo-
gías (Martin, 1991). Además, el desarrollo en ventanas temporales impli-
ca poco riesgo. La evaluación del sistema y su posible rechazo es una
parte explícita del método, pero tras los primeros años iniciales ¿- lm*
cionamiento, DuPont no ha rechazado ningún sistema desarrollac,: : ¡m
ventanas temporales. Scott Shultz, creador de la metodología en Du-::mr*
dice que <todas las aplicaciones fueron terminadas en menos tieni:.: ry
que se habría necesitado sólo para escribir las especificaciones ;. -mui
aplicación en Cobol o Fortran> (Shultz en Martin, 1991).
39.6. Claves para el éxito en el uso del desarrollo

en ventanas temporales
Éstas son las claves para eléxito en el uso de ventanas temporales
Use ventanas temporales sólo en proyectos que pueda termin,: rr

el marco de tiempo de una ventana temporal (generalmente de ¡. ¡
120 días).
Asegúrese de que los usuarios finales y la directiva están de a;,:--
do en un conjunto de prestaciones básicas, que el equipo de c,.cr*
trucción en ventanas temporales cree que puede implementar ;:r*
tro dei marco de tiempo de la ventana temporal. Asegúrese de ;¡.a
las prestaciones han sido priorizadas, y de que podrá descaÍa: r -
gunas ellas del producto si es necesario para cumplir la plan:i:r-"
ción.
Asegúrese de que el equipo de desarrollo en ventanas tempc:-:r
está comprometido con el ambicioso proyecto en ventanas te=:,:-
rales. Ofrezca todo el soporte que necesiten para incremenn-- ¿
motivación.
o Mantenga una alta calidad del software a lo largo de la ven-,,:u
temporal.
o Si es necesario, recorte prestaciones para cumplir erprazo líml¡e
-e
la ventana temporal. No amplíe elplazo límite de una ventana ¡e:-
poral.
Martin, James: Rapid Application Developmenl. New york: Macmi--,-
Publishing company, 1991. El capítulo 1r trata específicament; .
desarrollo en ventanas temporales. El resto del ribro eiplica el conre::::
RAD en el que Martin sugiere el uso de ventanas temporales.
40
Grupo de herramientas
El método del grupo de herramientas consiste en definir un grupo que

es responsable de recoger información sobre la evaluación. coordinación
del uso y difusión de nuevas herramientas dentro de una organiza-
cx
ffre
ción. Un grupo de herramientas permite reducir el esfuerzo de prueba y
error, y minimiza el número de grupos de desarrollo que serán perjudica- *ffi
dos por el uso de herramientas software inadecuadas. prácticamente
ffi
cualquier organización que tenga más de un proyecto software ejecután-
dose simultáneamente puede configurar un grupo de herramientas, ffiffi
aunque en algunos casos el (grupoD podría consistir en una única
ffi
persona trabajando a tiempo parcial.
Eficacia
ffi
Riesgos principales
. Exceso de control burocrático sobre la información y la implantación
de nuevas herramientas.

. Esta misma estructura básica puede ser usada por los gl-upos de
reutilización del software y del proceso de ingenieria oel so,ftware.
Para más información sobre los grupa-i ,ie h¿r.¿mientas. consuite ,.Gru-
po de herramientasD, en la Secció¡¡ J-i.-1.
631
41
Lista de los diez
riesgos principales
La lista de los diez riesgos principales es una henamienta sendlla que le

permite controlar los riesgos de un proyecto software. La lista consta reffir
de los diez riesgos más importantes de un proyecto, ordenados del 1 Gffii
al 10, el estado de cada riesgo, y el plan usado para controlar cada
riesgo. La actualización y revisión semanal de la lista de los diez ries- Grei
gos principales eleva la conciencia de los riesgos y contribuye a su
resolución en el tiempo adecuado.
[re{
lre
r::iiiri¡i:::,ii EfiCaCia
Ere
Reducción potencial de la planificación nominal:
Mejora en la visibilidad del progreso:
Ninguna
Muy buena
sffi
Posibilidad de éxito inicial: Excetente
.::-;;l:.-in"- Riesgos principales

Ninguno.
lir:i,i:::iji lnteracciones y equilibrios principales

r Puede usarse en combinación con prácticarnente cualguier otro
método.
Para más información sobre listas de die: rrei_gcj srri*ci¿u;cs. c,:nsulíe

<Lista de los diez riesgos principales,," en jc S¿;;¡o,: -i--i.
633
42
Prototipado
de la interf az de usuario
En elprototipado de la interfaz de usuario se desarrolla rápidamente la +ffi

interfáz de usuario para explorar el diseño de la misma y los requeri- ffi
mientos delsistema. En ocasiones se utiliza un lenguaje especial para ffi
prototipado; en otros casos, el prototipado se realiza en el lenguaje ww
b" progt"*ación definitivo. Los prototipos de interfaz de usuario son ffi
desechados o desarrollados para obtener el producto final. Una de las ffiffi
claves para tener éxito es etegir adecuadamente entre desarrolla.r el W"W
prototipo o desecharlo. otras claves para el éxito incluyen la implica- wffi
b¡ón de los usuarios finales, mantener las implementaciones W
iniciales de los prototipos lo más simples posibles, y el uso de desarro-
"á""r"da
W
lladores con exPeriencia.
Eficacia
Fleducción potencial de la planificación nominal: Buena
Riesgos princiPales
. Pulido del prototiPo.
. Riesgos del prototipado evolutivo o de los prototipos desechables,
dependiendo de si el prototipo de interfaz de usuario es utilizado
como base o desechado.

. Derivados de los correspondientes al prototipado evolutivo o a ios
prototipos desechables.
635
Los desarrolladores se han dado cuenta de que poner un prototip. ;

cionamiento delante de los usuarios del sistema es la forma más e -
de educir la realimentación del usuario, superando la especit-rca;
papel. El prototipado de la interfaz de usuario soporta el desarroll¡,
de varias formas.
Reducción de riesgos. Sin el prototipado, si la interfaz de usuar: - rl

satisfactoria, ias únicas opciones disponibles consisten en descartar -. -',u
rnterfaz de usuario y comenzar de nuevo, o aguantarse con la mala ,:-::*i
de usuario, independientemente de sus problemas. En cualquiera i= .,':, +
casos, no se descubre la falta de adecuación de la interfaz de usuar- - 'ii
el final del ciclo de desarrollo, y el coste de no haber descub'-- -,l:
error es elevado.
Si prototipa pronto la interfaz de usuario en el ciclo de desarrollo. -: ::,!li¡i
henamientas de desarrollo bien adaptadas a esta tarea, como los lengu: ., llr
programación visual, podrá diseñar rápidamente distintas interfaces d¡ --.*
rio, probarlas con 1os usuarios y modificarlas hasta que encuentre üIt - ¡:trr
aceptable. E,sto supone un recofie de los costes , al rcalizar las diferente. :-u"
bas de diseño de la interlaz de usuario usando implementaciones :..--Lli'
vamente económicas en un lenguaje de programación visual, en 1u¡-- ,lr
realizar implementaciones relativamente caras en el lenguaje definitir,- :- *
bablemente, el prototipado de la interfaz de usuario se adapta mejor a p:: i:;-
tos de software de gestión, en los que los desarrolladores tienen interac: : :d:
frecuentes e informales con los usuarios finales. Pero también se aü::; -
proyectos de software comercial, <prét-á-porter> y de sistemas. s-3 :r:
y cuando pueda implicar a los usuarios finales. Generalmente, la inter':: .n:
del usuario en este tipo de proyectos necesitará ser más formal y estmc-.-:rxi¿
REFERENCIA Sistemas más pequeños. Uno de los efectos inesperados del p:-: , r. "
CRUZADA
pado de latntetfaz de usuario es que tiende al desarrollo de sistem:¡::;*
Esta ventaja puede
verse restring¡da por el pequeños. Las prestaciones que ios desarrolladores piensan que J:-:-r:
riesgo del cambio de los usuarios no son siempre las mismas que desean los usuarios. t:, .':
prestaciones. Para
más detalles, consulte siones, los usuarios insistirán en tener una prestación que parece :-:
la Sección 14.2, sobre el papel, pero no trabaja bien en el sistema en funcionamie:::-
" Proyecto avanzado: prototipado de la interfaz de usuario puede revelar estas prestacio:-. ::T
control de cambios de
las prestaciones". fases iniciales del proyecto, facilitando el recorte del conjunto de::..;-
ciones y la reducción del tiempo de desarrollo.
Sistemas menos complejos. Los desarrolladores tienden a la c..:.: .

jidad. Por ejemplo. en ocasiones los desarrolladores se centran en 1a. .:.ir
más complicadas de un sistema, porque éstas son las más desafiante . ', : r-
tanto las que más ies interesan. Sin embargo, los usuarios finales no ¡ -- :"ir
estar interesados en la complejidad del mismo modo que los des¿::- ri-
dores, de hecho, generalmente huyen de ella. Las partes más comp--:-:;
de un programa (aquellas que resultan más difíci1es de implerrenr¿: :.,r
h¡.- €
Capítulo 42: prototipaoa c. . -:r-.1 :e u,suario 697
generalmente las partes menos deseadas lc: _:. _:_::-ts

-inales. que a
lnenudo están deseosos de sacrifiaul. pur..,.: c: rJ_:_-: :- .:.
,t:3ii?ciones
a cambio de una mayor simplicidad 1 lec--:;": :- __i- :_::triotipado
puede identilicar las prestaciones comple-,is r_:.,. :_: > _:_l.t:io( no
se preocupan en absoluto.
Reducción de los cambios de requerimientos. - -. ::::-,, -,:iores

que han usado el prototipado de la interraz ¿; :_.:-, - :.:_ ::.;-t-irL)
que reduce los cambios de prestaciones. :e;-,-:-::,--:_. - a
"_'-.: ;- ! *:t:
\ -z
realizada la especifrcacrón inrcial de , srs,¡::.. t ::r ;, :::,:::-:::-. .:,s *s*a-
rios tienen un mejor conocimie¡rit'r iitc::, ¿e, _.ts:::::" ¡e- ;.^= :a:tJ.:-:: ii
otro caso, y por tanto solici¡an rt3ltlS :ta,it--;c:J:..nes.
Mejora de la visibilidad. E, desan'ollo de un prototipo ejecutable e n 1a

parte inicral del provecto oliece a 1os directivos y.clientes un signo rangible
de progreso basranre anterior a los mostrados con los métodos tradicio-
nales de desa¡ro11o.
Una variante del prototipado de la interfaz de usuario es el prototipo de

demostración, en eI que se desarrolla un prototipo de inrerfaz de usuario
durante la etapa de propuesta de un producto softu'are. un prototipo de
demostr¿ción ofrece una demostración más vívida der concepio de un pro-
du*o de,la¡ óf?é ida pbr documenlos:E¡,papel:o las presentacioaes basadas
:ur,caplgrardg. imágenáq; y su objetivo es incrementa¡
el aivel de soporte de
la directiva y el cliente para un producfo.
, ,No exi$le ninguta,dif¡renqia técnica inherenre eatre el prototipado de
'.,
la:interfaz de uduarlo y el prototipo de demosrracióa. pero se desarroliaii
con propósitos diferentes, se usan de forma diferenre. r'producen benefi-
iios.dí&r.e11tes; Él.prototipo de interfaz de usuario se desarrolla para cbte-
ner realimentación sobre el conjunto de presracioncs de un producto o el
diseño de su interfaz de usuario, y ofrece ]os beneficios descriros en este
capitufo, u-n prolotipor,de d'emostración puede resulra¡ útil para obrener fi-
natrp,iacioa pata un.prgy.eeto,:,pero no producirá beneficios respecto a la
velocidad de desar¡.o11ol'a'menos que, además de su propósito;nicial, ss
utilice de los modos descritos .it" capirulo.
"n
42,1- uso del prototipado de la interf az de usuar¡o

El prototipado de la interfaz de usuaritr es más adecuado como estrategia
para nuevos proyectos. Puede usarle'r tara e\rraer el conjunto de prestacio_
nes en sí o sólo para diseñar la inrerl'az cie usuario.
¿F-
Desechar o evoluc¡onar
Los prototipos evolutivos y desechables van cambiando en res:
cambios del conjunto de prestaciones o del diseño de la interfaz de
Generalmente deseará que el prototipo sea flexible, de forma q;= :
refinarlo en respuesta a la realimentación del usuario. IJna vez;_.
explorado la funcionalidad del sistema con los usuarios, el prototi:: :
servir como una especificación operativa de los requerimientos :r-r
aspectos visibles del programa.
En algún punto, comenzará a construir el sistema real, y en es:: :
desechará el prototipo de interfaz de usuario y comenzará a conr:iLun
sistema real, o bien irá haciendo evolucionar el prototipo de in¡e:tl;
usuano para que se convierla en código definitivo. La primera de;.; L
tomar con el prototipado de la interfaz de usuario es si va a cons:iür

prototipo desechable o uno que podrá transformar más adelante e: :
definitivo (un prototipo evolutivo). Necesita tomar esta decisi..: :n
momento en el que comience a construir el prototipo, no cuando ;:,m,
ce a construir el sistema real.
La regla básica es la siguiente: si tiene mucha información s,.:rr
requerimientos y ha tenido relativamente pocos conflictos sobre p:
des y equilibrios, use el enfoque del prototipado evolutivo. En or:
habrá demasiados cambios, y deberá utilizar el enfoque de los pr..::
desechables para explorar los requerimientos y el diseño de la inre-:¡,;
usuario.
También podemos tener en cuenta que en los sistemas pequ;¡:r
preferible usar prototipado evolutivo, porque el trabajo necesario pr" :
un prototipo desechable lo hace económicamente indeseable. En s:re
de tamaño medio o grande, puede usar con éxito prototipos desecl-,:
prototipado evolutivo.
También puede prototipar el sistema principal con prototipadc, :
tivo y las partes que implican más riesgos con prototipos dese;:
antes de comenzar el desarrollo completo de estas partes.
Selección de un lenguaje de prototipado

REFERENCIA Si piensa desechar el prototipo de interfaz de usuario podría decir- ,r
CRUZADA
Para ver riesgos y
un lenguaje especial para prototipado. La cuestión principal a la:_:l
ventajas asociados seleccionar un lenguaje es en este caso la velocidad con la que :,r
con los lenguajes de
prototipado, véase
desarrollar la interfaz de usuario. Ni siquiera tiene que uru. ,rn i.*.
el Capítulo 31, de prototipado. una empresa hizo capturas de pantalla de las venr.:,1.:
"Lenguales para producto, las amplió a un tamaño gigante, y las puso en las pa:e::: rúc,
desarrollo rápido
(LDR)". una sala de reuniones. E,ntonces prepararon una (representación &Í-si jr¡u,
e hicieron que las personas circularan por la <galería de arte> e_i::- nn*-
).
ran directamente sus comentarios en los volcados de pantaila. Ai *lu: o,mn¡
-:.-az Ce usuario 639
Si piensa evolucionar el prorra:::J ;= -::::--:- J: -::::.::ara llegar

al sistema final, la consideraci.i: ::;: ::::::.:_-_:- :::. :,-¡;.-tonar un
lenguaje es determinar cl ¡-.::,.. :::.: --:
= .-::-.: -: t:.-:..:i¡ado
soportará el crecimien¡o dei sis.erl:. _{isu:..-! -e:.-:r-:s ¡:-::-::¡os a la
interfaz de usuario olrecen un :-3::j j:s¡r:¡..., ce .:rrer-
=o¡i.-- p.r. -:
faces de usuario. pero un soporre debrl para ei rlesarrc'¡llo ,je bases ie da:os.
comunicaciones. formato de in¡brmes otras áreas dei prosrana. que
pueden consumir como minimo tanio tiempo' como el desarrollo de la rn-
terfaz de usuario. Seleccione un lenguaje basándose en su sopor¡e para
el desarrollo completo del producto, no sólo en su soporte para la interlaz
de usuario.
Decorado de Hollywood
otra clave para tener éxito es recordar que se está prototipando, no desa-
rrollando el sistema real. Existe la posibilidad de que todo el trabajo de
prototipado sea desechado si no les gusta a sus usuarios. Hasta que esté
seguro de la parte del sistema que será implementada o no, intente con-
centrar el 100 por 100 de su esfuerzo en las partes visibles del sistema.
No gaste tiempo en partes que el usuario no puede ver. Trate el prototipo
como el decorado de una película de Hollywood: parece real desde cier-
tos ángulos, pero fuera de elios no es real.
Cuanto más cartón piedra empiee, mejor. Si el prototipo tiene que
mostrar gráficos en color, no implemente ei soporte para gráficos en co-
1or en el código, aunque sea relati-,'amente fácir de hacer. En lugar de ello,
intente buscar una forma más fácil de presentar gráficos .tr .olo, predefi-
nidos. cree los
-eráficos usando un programa de dibujo comercial, y car-
gue cada gráñco predefinido en el momento adecuado. El prototipo debe
ofrecer a los usuarios finales el aspecto de programa definitivo. No tiene
por qué funcionar. Si funciona, es probable que haya empleado n:is tiempo
del necesario. Los cá1culos no tienen que carcurarse: muestre simptremente
los mismos resultados cadavez, o conmute entre dos conjuntos de resul-
tados. Los cambios de formato no tienen por qué reformatear nada, cam-
bie simplemenre un r.oicado de pantalla adecuado por otro. El botón de
imprimir no tiene que realizar la impresión; copie simplemente un archi-
vo de impresión preexistente a la impresora. La conversión de datos de la
antigua versión del producto no tiene por qué convertir los datos; active
simplemente el cursor de espera y muestre la sarida predefinida. Haga
que su grupo piense en formas creativas de ofrecer el aspecto deseado de
la aplicación mientras escribe la menor cantidad de código posible.
No introduzca en la fase de prototipado a programadores recii:

dos. Durante el prototipado. los desarrolladores necesitan tener -- :
sentido delo poco que pueden hacer para explorar las áreas de ne.¡:
las que está diseñado el prototipo.
lmplicación y realimentac¡ón del usuar¡o f¡nal

Aunque el prototipado de la interfaz de usuario generalmente fl1-_i ltn,
usabilidad del software, esto no se traduce necesariamente en un'
satisfacción del usuario. En ocasiones, la implicación inapropiada i:
rio empeora la satisfacción del mismo.
Necesita implicar a los usuarios finales. No alcanzará las ".':
del prototipado si sólo implica a los desarrolladores y a los direcrir x
termedios. Haga que los usuarios prueben el prototipo de inteji:
usuario. E,sto aclarará los requerimientos, le ayudará a revelar los r¿
mientos actuales que programa, mejorará la concordancia entre ;,
ware y las necesidades de los usuarios y mejorará la usabilidad g:
del producto.
Controle e1 acceso al prototipo. Generalmente las expectatir.as
siado altas del usuario son alimentadas por un exceso o falta de ac;:rr
prototipo. Dígales a los usuarios que el propósito de mostrarles el p:;
po es aclarar los requerimientos. Podría desear limitar su uso del pr.-:
a una demostración de ciertas secuencias de volcados de pantalla r-c
ciones, utilizando el prototipo más bien como una herramienta vis:::
como un programa software interactivo.
Tenga presente que los clientes no siempre saben lo que están
=-r-
do cuando ven un prototipo. En una ocasión desarrollé un prototip
un aplicación analítica bajo Microsoft Windows que generaba salid.^ ¡
ficas. En el prototipo, usé gráficos preparados, por 1o que sin impor-;":
números introducidos por el usuario siempre aparecía el mismo _u:"i
Como los gráficos preparados podían generarse instantáneamente, inti-
un retardo de dos segundos para crear la impresión de que el prr.::
estaba rcalizando un acceso a la base de datos y cálculos numéric.-.
tenía que reahzar la aplicación real.
Aun con el retardo de dos segundos, los usuarios estaban encar--¡:rim
con la velocidad con 1a que el prototipo generaba sus gráficos. La pr:-osm
vez que mostré el prototipo, varios usuarios discutían entre sí respectL'\ : .:@
el prototipo para Windows era mucho más rápido que el producto N{ir-nxffi
para MS-DOS que iba a sustituir. Un usuario decía que esto se de:l¿ n
que los gráficos de Windows eran más rápidos que los gráficos en D-t$
Otro decía que era porque el prototipo sólo tenía una base de datos min:'--r'r¡¡
en lugar de la base de datos completa. Otro argumenfaba que el r;-,:,unu
programa estaba utilizando una biblioteca matemática diferente ae, m*
tiguo programa. A nadie se le ocurrió que realmente el prototiN :m
Capítulo 42: Prototipado de la inteñaz de usuario 641
una pura fachada, que no estaba pasando nada deeás del escenario y que
los gráficos necesitarían más tiempo del que estaban tardando en ese mo-
mento.
Si realiza un buen trabajo prototipando el aspecto fi¡al de su produc-
to, es posible que los usuarios se sientan abrumados por una demostración
del software en vivo, estarán tan impresionados qtr no pensarán sobre si
el prototipo incluye toda la funcionalidad deseada- Si es¡i rrsando el pro-
totipo para educir los requerimientos del usuario" asegtrese de que los
usuarios estudian con suficiente detalle el prototipo para criticrto- Erpli-
que algunos de los compromisos de diseño que ha n€cesitado tomar. )-_
asegúrese de que comprenden estos sacrificios y esfrán de rrsdo con
ellos. Desarrolle una lista de comprobación de forma qrc peda Etter tma
entrevista estructurada con 1os usuarios que utilizan el pomripo- Ass-sti-
rese de que observan todo 1o que queremos que obserr-en-
IJnavez haya obtenido una realimentación significarir: & lm usnrftx-
haga evolucionar suficientemente el prototipo para cmfrrmrF he m'
prendido lo que le han dicho. Una de las formas rnáq efecrirx & rrrma
que se han recibido y comprendido sus comentarioscmbccr nr¡+rra{es
un prototipo actualizado con la realimentación recibide Afuis & cmtri-
buir a las buenas relaciones con 1os usuarios, esto ayuda atboefu*r
problema de mala comunicación; le da la opornrnid¡¡l el usrb & &cfu:
<No, esto no es lo que yo quiero decir.>>
El producto terminado
La creación de un decorado de película es una gran es¿tcgia dc fototi-
pado, pero un producto no puede quedarse siempre en r¡m k¡fu- En
algún punto, tendrá que decidir cómo pasar del prototipo d profun final-
En ese momento dispondrá de tres opciones:
r Descartar el prototipo e implementar el proAno rcd ¿¡s¡r¡ el

principio.
o Corregir los defectos del prototipo -v €ffietrlo-
o Usar prototipos desechables para la prime mlh & d f€se-
ción, y prototipos evolutivos para las rcshE¡wmlg. np¡eryr'm
la primera versión de cada pre$acifu qt¡¡¡m d rso de to6
decorados. Unavez se tome la decisüia & snzrom E presul-
ción, deseche el código del prototipo" irylm cl odi3o rceL ¡-
derive el código final a partir dF agi-
Puede usar también métodos distintm pe le fuerfaz de usuario 1- el

resto del sistema. Es posible prototiptr h imcrfaz de usuario. pero desa-
rrollar el resto del sistema usando rm enfoque tradicional-
42.2. Gestión de los riesgos del prototipado de la

interfaz
de usuario
Generalmente, el prototipado de la interfaz de
usuario tiene éri¡-- - :m*
parte muchos de los riesgos de ros prototipos
desechabres o el p:;:---:mr,
d.o evolutivo, dependiendo de si desarrolra Ll prototipo
de inteÁi c- ,iiuh.
rio conto un prototipo desechable o como un prototipo
evolutir o
REFERENCIA si desarrolla la interfaz de usuario como un protoiipo desecha'¡-:
CRUZADA r,m*
Para más detalles
ga presentes estos riesgos:
sobre |os riesgos de los
prototipos desechables,
o Mantener un prototipo desechable.
"Gestión de los riesgos
o Uso inefr.caz del tiempo de prototipado.
de los prototipos
desechables".
o Expectativas poco realistas de presupuesto y planificación.
REFERENCIA Si.desarrolla el prototipo de interlaz de usuario como

CRUZADA
prototipo evolutivo, tenga presentes estos riesgos:
una pani:: rr
Para más detalles
sobre los r¡esgos
del prototipado r Expectativas irrealistas de presupuesto y
¡ Disminución del control sobre ei proyecto.planificación.
evolutivo, consulte la
de los riesgos del
prototipado evolutivo..
o Mala realimentación por parte dei usuario final o cliente.
¡ Bajo rendimiento del producto.
o Expectativas de rendimiento poco realistas.
¡ Diseño defectuoso.
¡ Poca facilidad de mantenimiento.
o Cambio de prestaciones.
o Uso ineficaz del tiempo de prototipado.
42'3. Efectos secundarios del protot¡pado de la interfaz

de usuario
Aparte.de sus ventajas para el desarrollo rápido,
er prototipado de -. :l-
teffaz de usuario tiene muchos efectos lateráres,
tu -uyoriu J. lo, . , *
resultan beneficiosos. Contribuye a:
' una participación más entusiasta del usuario final

y cliente ;: ¡r,
actividades de requerimientos, y una mejor
a en la realimenl": l,r
sobre los requerimientos del sisiema.
Mejorar morar de ros usuarios finales, crientes
¡' Reducir el
'a riesgo del proyecto. debido que
a
y desarrolrac-:::
el área de la in:;::1.;:
de usuario. que implica bastante ries_eo,
se estudia pronto.
o \fe-jorar la facilidad de uso.
ii
-
Capítulo 42: Prototipado de Ia interfaz de usuario
Una mejor correspondencia entre los productos software y las ne-

cesidades del usuario final.
Una realimentación más rápida sobre la aceptación del sistema fi-
nal por parte de los usuarios finales.
a Disminuir el número de prestaciones.
a Establecer una cooperación en lugar de fomentar el anta-sonismo
entre los desarrolladores y sus clientes v usuarios finales.
42.4. lnteracciones del prototipado de la interfaz

de usuario con otros métodos
ffi
DATOS REALES
El prototipado de la interfaz de usuario es un remedio ei-icaz tiente
cambio de prestaciones cuando se usa con otros métodos. Har-un estudio
que ha encontrado que la combinación del prototipado 1 JAD (Capíru-
lo 24) puede mantener el cambio de requerimientos por debajo de un
5 por i00. Los proyectos experimentan habitualmente niveles cercanos
al
al 25 por 100 (Jones, 1994).

El prototipado de la interfaz de usuario interacciona con los pro-
totipos desechables (Capítulo 38) o el prototipado evolutivo (Capítu-
1o 21), dependiendo del tipo de prototipo de interfaz de usuario que
desarrolle.
La definición de metas y objetivos claros (<Definición de objetivos>,
en la Sección I 1.2) o el uso de hitos miniatura (Capítul o 27') para monitori-
zar el progreso son herramientas importantes para mantener centrados los
esfuerzos de prototipado.
42.5. Puntos cruciales del prototipado de la interfaz

de usuario
El prrncipal beneficio derir ado dei prototipado de la inferfaz de usuarto
consiste en que reduce el riesgo de desarrollar una interfaz de usuario ina-
ceptable, el'itando tener que trabaiar en el1o posteriormente. Aparte de esto,
los beneficios derir,ados dei prototipatirr tie la intertaz de usuario dependen
de si está usando prototipos desechable s ü p:iirrirl3do ¿" oiuiir o.
En varios casos estudiados. e1 prototipai.. 3" Lf,l'iiil o ha disrninuido
drásticamente el esfuerzo de desarrolio. de ui ji e un s0 por i00 tGordon
y Bieman, 1995). Por otra parte. los prLrtL-rlitos desechables constitu\-n
DATOS REALES
más bien un método de reducción de nes*qos que un método para ahLrrar
tiempo en sí. Ayudan a mantener las pianif-rcaciones bajo control mas que
a reducirlas.
-
42.6. Claves para el éxito en el uso del prototipado

de la interfaz de usuario
Éstas son las claves para tener éxito en el prototipado de la
usuario:
Definir al principio del proyecto si el prototipo va a ser er.oi-;; -

o va a ser desechado. Asegurarse de que tanto la directir.a : _,¡ur
equipo técnico están de acuerdo en el tipo de camino a se:-::
Utilice implementaciones ficticias de la fachad,a de las n=;;
nes prototipadas que aún no están incluidas definitivame:-:- str
producto, independientemente de que esté utilizando pro:,-::
evolutivo o prototipos desechables.
. Implique a los usuarios finales, solicite activamente su re¿
tación, y limite su interacción con el prototipo a las prestac::,rus
controlar.
Además de estas recomendaciones, asegúrese de seguir las reco:-r¡,m,-

ciones dadas para el prototipado evolutivo o los protótipos desec:-r-:rinn*
dependiendo del tipo de prototipado de interfaz de usuari,o que des;::rilk
Para más información sobre el prototipado, consulte el capítulo i-
totipado evolutivo>.
p
'ti
t;
ffi
Ifi
#
ffi
t_
m
43
Horas extras voluntarias
Las horas extras voluntarias consisten en of recer a los desarrollado- ,#"iffi

res un trabajo significativo. de modo que junto con otras contribucio- :*HYY:ffi
nes a la motivación interna. éstos deseen trabajar más de lo que se les
exige. Las horas extras ofrecen un aumento directo de la productivi-
dad, y la motivación extraordinaria da a los desarrol\adores una agudeza
t;¿t:;li&.eJgb&tu
que se transfiere a sus horas normales de trabaio. Las horas extras :t :-: :r¡:Et:::i:#;x
moderadas y voluntarias pueden usarse prácticamente en cualquier
entorno, pero su aplicabilidad está limitada por el hecho de que las
horas extras excesivas, obligatorias, se utilizan ya bastante a menudo. ;f\lj -.:;*i#l$Stiq!!
'1ti1x\\\!"{f"#
,, 'r"t:¡;i:!!lF!4*
':iS*i.1i.*SSH
Eficacia
ri
I'F: i, *.lllr,ii.ltl#!li

Posibilidad de éxito inicial: Media
Riesgos principales
¡ Penalizaciones sobre la planificación resultantes de una excesiva
presión en la planificación y un exceso de horas extras.
. Reducción de la capacidad de responder a una necesidad de emer-
gencia de más horas de trabajo.

. Requiere el uso de métodos de motivación sincera y sin manipu-
lación.
. Generalmente se requiere como soporte para los hitos miniatura o
modelos de ciclo de vida incrementales y desarrollo en ventanas
temporales: cualquier método de desarrollo que utilice fechas límrte
f recuentes.
645
w
646 Desarrollo.y gestión de proyectos informáticos
Un exceso de horas extras y presión de planificación puede

deten..:.: u
planificación de un desarrollo, p.to unu. cuantas horas
extras ¡-.rrl
incrementar la cantidad de trabájo reahzado.u¿u
r.*un;;;:,..--
increme.--:, .'
motivación. Una cifra de 4 a 8 horas extras cada semana
rendimiento de un l0 aun20 por 100, o incruso más.
una rutii f.,,. ,*
de trabajar un poco más realza la importancia
de un proyecto. Los á-r..=,*
lladores, como el resto de p"ttonua, desean sentirse
importantes. \- :--::ji¡-
jarán más duro cuando se sientan así.
43.1. Uso de las horas extras voluntarias

Generalmente, las horas extras se utilizan mal con bastante
frecu::: i¡-
así que tenga presentes las siguientes directrices si
desea obtener ni:: ;É
40 horas productivas semanales por parte de los miembros
de su ec*,f:
REFERENCIA
use la iniciativa del desarrollador, en lugar de la presión de
CRUZADA la direc-
Para más informac¡ón tiva' Intentar motivar a los desarroiladores puede resultar
como in:¡:'n,
sobre los efectos empujar una cuerda: sería mejor tirar del otro extremo.
perjudiciales de una Gerald !\-er::er
' excesiva pres¡ón de indica que uno de ros mejores resultados conocidos
planificación. véase
en ra investig:-,:m
sobre motivación consiste en que incrementar la presión
"Presión excesiva en
apricada p::,-lx*
la planificación., en la ce un aumento del rendimiento hasta un máximo, y
luego io rleva ¿ :¡¡r
Sección 9.1 . (weinberg, 1971).Indica que la rápida caída en ,.,rJi*i.nto
es:::r*-
"i el desarrollo;.
cialmente observabre en tareas .o-pr";ur, tares como
ware: <<Presionar al desarroilador para que corrija rápidamente -..:
un ;::*rrr-
puede convertirse en la peor estrategia posible qp"ro
ós con diferen::¡ ,¡
más común).>
cuando la motivación es baja, tampoco importa ra cantidad
de rr::::rir
que la gente pasa en el despacho. No obtendrá
40 horas de traba,- r;r
ellos. Ellos estarán allí sólo para mantener las aparierrcias,
o p.;; :: ;
sentirse mal por no cumplir las fechas límite.
como sugiere la Figura 43.l,la motivación de los desarrolladore.
::m
una presión media de planif,rcación es alta. con
un poco más alcanzará e-.:*-
ximo rendimiento. una presión adicional causa una
caída del rendimre:,:_
Resulta adecuado pedir que se trabajen algunas
horas extras. p.:- rLr
hay que pedir demasiadas.
REFERENCIA Por naturaleza, ros desarroiladores están motivados
CFUZADA por sí solc:. :,:,
Para más información 1o que la clave para hacer que trabajen
horas extras es actuar sob:= ;L:
sobre la mot¡vac¡ón de automotivación natural. Cree condicion., qu" res
los desarrolladores, hagan desear ,.::: .*-
más en lugar de tener ganas de irse. En térmlnos
consulte el Capítulo j 1, g.n.ár.r, ror lin.. -i
" Motivación ". tores principales para motivar a los desarrolladorés
son:
¡ Realización. Dé a los desarrolladores una oportunidad

para :_.:::
algo significativo.
Capítulo 43: Horas extras voluntarias 647
Nivel medio
de motivación Zona óptima
MUY alta
Alta
Motivación
deldesarrollador Media
Baja
Muy baja
Muy baja Baia Media Alta MuY alta
Presión de la Planificacion
Figura 43.1 .
Zona óptima de la presión de planificación. con un ligero
inóremento se alcanza la mayor motivación posible' Fuente: Adaptafu &
Applied Software Measuremenls (Jones, 1991).
c Posibilidad de superación.Prcpate el proyecto pala que los desarro'

lladores puedan superarse tanto personal como profesionalmente.
o El trabajo en sí. Asigne tareas de forma que los desarrolladores
encuentren significativo su trabajo, se sientan responsables del re-
sultado y puedan ver el mismo.
¡ Vida personal. Muestre a los desarrolladores que respeta sus i¡te-
reses ajenos al trabajo.
. Oportunidad de supervisión técnica. Dé a cada desarrollador la opor-
tunidad de tener la responsabilidad técnica en algún área'
REFERENCIA Una de las formas más efectivas de motivar a 1os desarrolladores

CRUZADA
es infundir un sentimiento de excitación en todo el equipo de desarro-
sobre la creación de 1lo. Defina una visión clara de lo que se supone que tiene que lograr el
equipos de alto equipo. Ayude al equipo a desarrollar un sentido propio de identidad.
rendimiento, consulte
el Capítulo 12, Y hágale saber al equipo que el resultado es más importante que el tra-
.Equipos de trabajo". bajo duro.
La importancia de centrarse en el resultado es una de las principa-
les razones por las que las horas extras forzadas por el responsahle no
funcionan. Hacer hincapié en el número de horas que una persona pasa
en el despacho pone el énfasis en el estilo en lugar de en el fondo. En un
proyecto de desarrollo rápido necesita centrarse en la cantidad de ra-
bajo que se está realizando. Si las personas están cumpliendo los plazos
límito y la motivación es alta, no importa si pasan 50 o 25 horas en el
despacho.
No exija la realización de horas extras; reduc¡rá el rendimiento

total. Aquí tenemos una de las posibles objeciones a la Figura -13-l:
aa7-
648 Desarroro y gestión de proyectos

informáticos
<Evidentemente la motivación
disminuye al incrementar lai
tras. pero ios desarroliadores
trabajará" ,íá. ,r"'.".,';';,il1.
extra compensará de sobra la pérdida ::,
de motivación. El rendirn
seguirá siendo mayor.> -tl
Para ver el fallo presente en

este argumento, tenga en cuenta
puntos:
. Hay muchos estudios que han nlostrado

más influencia sobre la productividad
que la moti\ ac:.I :_.
que cualquier olr _,
(Boehm, tgBl).
Empujar a los desarroliadores
cuando éstos ya están motivac,-
que la motivación descienda
brur.u_.nt. (Weinberg, 19-,
F.l desarrollador medio ya está
trabajando cerca del nivel r,,., r¡
de motivación (Jones, 19gI).
El problema relacionado con la presión

para exigir más hora. _ :_.,
de las que desean rcalizarro, ¿"ru.riJiu¿'o
motivación .o-i.n,u a caer, no
sóio
-= :-_-
afecta a las 10 0 20'oras extas "o.tT'":::'iü:Tooil:.!l
n'tás las 40 horas normales. cuanc_
siona para realizar más horas --,
.*rr*, perdiendo más produci.,, -
debido a ta presión de ra que "r,¿
muesrra ta reración ". r;;;;;';n horas exrras. La Figu, _. -
enrre ra presión"de prun'i.u.ii;;";r;;;',,.--
das, el rendimienro total y iu _
*otiuu..áiJ.t ¿.ru.rollador.
como podemos ver.en la figura,
pi"oi"r rendimiento totar ct,._-
con el mismo número de horas'por "r
llador' como ra motivación
.";;;;
ie la motivación del cie..- _
r
ti""; ;;;;;lniru.n.i, en ra produ*i'ic,_ -iL
Motivación
Muy alto
Muy alta
Rendlmiento
total
Alto
Medio
-Y .,üi
:.|
l
]
AIta
Motivae,¡,r
Media del desar.o¡@¡¡
Bajo
Baja
Muy bajo
Muy baja
Muy baja Baja Media Atta Muy alta

Presión de planif icación/
noras trabajadas
Figura 43.2. Relacjón
cle ptanificación y las horas
rendimiento tntar , ta traba ::z:
^^r,:.r:?,1:-p::sión
::lT:::',:;:":',,,/?,2'"' Y:"::,!:t!::;;;iel;;:;T':;í"::i:ff::,:',::;1:::
r, eactd uruscamente. como
de motivación es más !:.:"j,;:;i!;;;;;;";;;:;:,ii::;:"::::i:
'rT'1::;::"i::^:."1'l?; :;.: ,;
la c:.:
la ganancia aeo¡Ja-a.ías"n"á'rlr'Z),-r,
rendim¡ento
rendimiento tnrat r.^^;f::rJ:,!r"
total también baja'.
Capítulo 43; Horas extras voluntarias 649
caer la motivación, el rendimiento
rotal cae rambien. \o cae tan brusca_
mente debido a que la caída en
la moti, u.¡ó parcialmen-
te por er incremento en el número
d. ho.u. L:ir:i:r="tda
La implicación de ra Figura 43.2
mero de horas de trabajo empleadas
es.;;.;-: :,-: ¡rcrma der nú_
oo',-ta.r.-.--:r--:-: ¡- :esarroirador
medio. perderá rendimjento,en general
horas extras. No importa cuálesiaun f,, r., ,,.. r:r:, -; -.::,;
nlá j
ru, razLr:,,: . .. .__: j. :-- i_,:r.
ntenos que sus desarrolladores -l
las encuentrc: t;r _. r
,'. _
tt no consigue que compartan sus motirtrs. s-:,-": =_ =,_
-._
e nRoR crÁsrco l_11
lncremento de horas extras se traducirá en un
:: : :::::._, 3-
Todos conocemos circunstancir, ',. ri:_:::.-=_:_
an lu. ora _:_ _.__
paralarealizacióndehoras extras = =.11.,
quelos desar¡t--.:.-=. . ._. __ _- .-..
horas extras a la semana, y en
ocasiona, ar a*n:... 1= __.'_ . -,. :
'::
',: t:t
tivac.ión toca fondo, es posible
a-.:'=.'-t:t -
-_
I
más horas extras. La motlvacio"
mejorar .,';:;=:-l -' -_.
=_ _
vu puJ.^r_;a.:., ,., ..-

_, ._
desan_c,,-,;-:_. _,=,
mentan, así que el rendimiento total"o
de los l. -
En la Figura 43.2. correspondería
a parre del gra_i: _ :-_:-. : -_ I _.._
lra. el área que se encuentra a la
derecha ae fu po._r.r- .= __ : .. _
muyalta. EI problema de esre mérodo.rqu. --=_,-
ge el salvado. EI direcf ivo. extremist,
d.rf.r.l,. l_.__-, -_-.-
qr.-inri.,c ,,: :::.:i _. _:, ,
ganaría más cediendo mucho
qu" up..t*áo un r.-¡___ _:.
leexijaaundesarroltaáo,que'.uuul.*'.]--,...
é1 quiere trabajar. r-o, ¿.ruroii"d;;,;;;"::.,.-..:,',
trt'
;,
predecir hacia dónde irán, exce p;_...., =_ I l
,-.
:::ii Íl'::,.]:" lo n"c
lo..dr. . -=
*TT, ::,:" Í::^":
dimiento, busque1"1
I a
1 gue, I 9' "ñ"^;i
r
una solución di¡;;;;;--'

;"*, ootener m;:
er r¡vus¡rLa
'á "l;;
;
:. :.:-'
..: _
específico de horas r.rnunui., que

,,*f]-lli..ro
.,rmrento maxrmo varía entre,proyectos. Argunos
sc c(ri:_::..::: : _: ___-
motivados alcanzan su rendimilnto o.ru.,.oi;u"ui.r,-a ..-.. .,

máxílo en una jornada raboral de
35 horas semanales. Aigunos pu.a.n
llador medio estadounidénr" .u.1.
n"il; tabajarhasta g0. El desarro-
ui.urrrliir r.n¿r*iento máxim-üajoo entre 44
v 48 horas' como resuita difíc, r"b;. ;;;;tidad
corresponden con er rendimiento de h"; ;" que
óptimo J. un d.rurroliador específico,
clave para er rendimiento
'a
posible, independientemente de
-á^á; ;r üur.u, ia motivación más arta
1a cantidad de horas extras que imprique.
REFERENCIA No use horas extras. para intentar
CRUZADA
yecto. recuperar er contror de un pro-
Para más información Cuando se detecta que un p.oy"",o
está fuera de control, una de
sobre la recuperación las cosas más habituales que ru"l;
del control de h;;;;
de equipo es pedir a ros desarr"u";;;;;;"e
los direcrivos y responsabres
proyectos. consLllte ei
para controrar de nuevo el proyecto. p"ro, ftabajen más horas extras
Capituro I6
"Recuperactcr:e e.r sí mismas, ias horas extras
representan un signo de que
proyec:: s,, un proyecto está fuera A" óoniroi-i",
que están bajo contror no-necesitan p.o_
'ectos que ros desarrolladores rreb:_
IF---
jen horas extras. Algunos desarrolladores podrían frabajar

horas .. ni¡mi,
debido a que están fuertemente interesados en su proyecto, pero
Ít,- r_r,i:H*
sitan trabajar horas extras para cumplir sus plazos de entrega.
Exija una cant¡dad rearista de horas extras. Hay diversaS rri= r,*
nes sobre el tiempo que los desarrolladores pueden
dedióar al traba-ii .-. ms
Boddie, autor de Crunch Mocle, dice que unavezque el proyecto
e>-:¡ tF
marcha' cabe esperar que los miembros del equipo trabajen
hasts r- lirr
ras a la semana, e incluso 100 horas en algunas a.-uná,
determi:,¡,¡ur
(Boddie, 1981). Por otra parte, Steve Maguire, veterano en Micr,:s:':
apunta que la gente que trabaja tantas horas tiende a incluir
sus :::iidri
personales en la jornada laboral. Tardan más tiempo
en comer, hacei . v
cicio, pasean , pagafi facturas, leen revistas informáticas: en otras pai;:_*,
hacen muchas cosas en er trabajo que normalmente harían
,u ,--**'
libre si trabajaran sólo 8 horas al día. Maguire concluye que"n ras pers-:ru:
que pasan 12 horas diarias en la oficina raramente trabajan
realmeni; :ir¡r
de 8 horas, aunque reconoce que una persona motivada por
sí mism. :-1'".
bajaú más ocasionalmente (Maguire, rgg4). otros expertos han coi. ,.,*
do que no pueden esperar tener un promedio superior a g horas
dr;-u,rr,,
(Metzger, 1981; Mills en Metzger, 19g1; DeMaróo y Lister,
19g7: B--¡:r'
y DeMarco, 1994).
Desconozco el efecto de ra presión de pranificación sobre la
can:- r*r
de tiempo empleado por las personas en su trabajo. He visto
a menuc: rr
que describe Maguire. He visto a personas que trabajan
durante 50
a la semana durante meses. ocasionalmente he visto personas
h.r
que ti:r,.h-
jaban tanto como describe Boddie, aunque
sólo por una o dos **u.-.
Si está pidiendo a los desarrolladores que trabajen horas extras , r*
luntarias, observe el tiempo que trabajan en ese momento.
Si las c¡- *
das comienzan a alargarse y la gente iomienza aregar tarde a ras ::;*
niones y anda perdida por ahí, ha pedido más horal extras
BIBLIOGRAFIA de las ;r,:
los desarrolladores están dispuestos a trabajar. Retroceda.
ADICIONAL Está il,;;
Para más información do la motivación de los desarrolladores fuera de la zona
sobre el uso de esle óptima c= ;
tipo de realimentaclón
Figura 43.1.
para geslionar un una alternativa simpre para volver atrás es permitir a ros
proyecto software, desarrc.-r-,
dores cortar en las 40 horas de trabajo, insistiendlo
consulte Ouallfy en que t.uuu¡."
cada una de esas horas. Esta posición es suficiente-.nt"
toi,i
Software Management,
uu.nál-.u.o-,-u-
Vol. 1: Systems ble en un proyecto de.de.sarrollo rápido, y creo que a menudo
Thinking (Weinberg, proc_:,1
1 992), espec¡almente
más horas reales de trabajo que pedii horas extras.
el Capítulo 6,
"Feedback Effects". Tenga cuidado con erexceso de horas extras, independientemen*
del mo_tivo. El mayor problema asociado con ias horas
extras : ¡¡sds¡¿: r
es con diferencia su tendencia a llegar a un exceso
de horas extras. Este
blema es sistemático en cualquiei tipo de horas extras,
::-*
ya sean volu:::-
rras u obligatorias. sin importar si ra presión para
trabajar muchas h¡:',
3": :_ : -lj - j-=s -,:-zs ,,ctiJntar¡as 651
Tras meses de un extras es intema o externa. ii --\--J:. ::- : r:i
estrés en aumento, el - i ,.r-:: , ., _.r._-¡sir.a presión
de planificación que le acompaia if iü*--1 :
entLtsiasmo inicial se - - : :,i_-::,.-i ¡:oblemas de
ha convertido en planificación;
agotamíento y por
último en amargo . Aumento del número de defectos.
cinísmo. Al final, las
personas
o Aumento de las posibilidades de asumit -3j-:-! :__,
desarrollan una o Reducción de la creatividad.
actitltd de disgusto . Incremento del desgaste.
frente a la entrega . Incremento de la movilidad de personai.
en cLrerpo y alma a
un prolecto. r Dispontbilidad de menos tiempo para la formación i
Ruth Wiener Ia organización.
o Reducción de la productividad.
Ayude a los desarrolradores a marcar su propio ritmo.

Aunque nadre
esté forzando a los desarrorladores para que trábajen
demasiaáas horas
extras, ellos pueden forzarse a si mismos a menudo
a frabajar demasiado.
cuando esta presión es inlerna. no tiene un impacto en
ia motiración.
pero es posible que repercuta sobre la efectividad.
_ ¿Ha visto alguna vez a ros sprinter correr ros 100 metros risos? cuan-
do terminan, su pecho y baja, su piel está mojada, y o.urion.,
-sube
incluso se sienten mar. Si "n maratón a
los corrldores tuvieran qu" .o.iá un
ese ritmo, no terminarían.
En las carreras en pista y campo a través, ros corredores
de ibndo
compensan una reducción en ra verocidad media para
tener un mayor ren-
dimiento en largas distancias. como muestra la i'igura
433, Jfoseedo,
del récord mundial de maratón corre sóro la mitad
d-e rápido qu. !t por".-
dor del récord mundial de 100 metros.
- De forma similar. acelerar durante argunas semanas no es una forma
efectiva de comenzar un pro,v-ecto de desarrollo de
soft'uvare imfortante.
T-'os desarrolladores que traba-jan
en un pro\¡ecto de r00.000 1íneas de có-
BIBLIOGRAFíA
digo no son tan rápidos como los desarrorládores que
ADICIONAL trabajan .n un pro-
Para más detalles yecto de 5.000 líneas de códi-so. Ha' más interacción
sobre el efecto del con orros desarro_
lladores, debido a que hay más personas en el equipo.
tamaño en un proyecto i también lui, .nu.rro
de desarrollo, consulte más.trabajo de integración. E1 efecto resurtan¡e
el Capítulo 21 de Code
es que ra productividad
por desarrollador en proyectos de diferentes tamaños
Complete (Mccon¡ell, r aría de forma simi_
993).
lar a las velocidades de ros corredores en direrentes
1
distancias, aunque
tenga desarrolladores de primera clase.
Podría planificar trabajar durante 6 o 7 días a ra
semana si tiene que
acelerar para cumplir un plazo de entrega dentro
de unas semanas. pero si
faltan 6 meses para la,fecha de entrega]es me¡or
que se dedique a buscar
un remedio para el cáncer o a proteger la Tiena
de 10s uruqu., de 10s
invasores del espacio antes que pedii este tipo
de sacrificio. Si 1o hace.
este tipo de sprint será simplemente el preruáio
del agotamiento, de mu-
chos cambios de personal y de una planificación
más-larga.
10,0
400 M
9,0
Velocidad
lmetros oor
'segund'o) 8'0 l:800 M
'it ooau
I An;il^
7.0
6,0 10K 20K 4ryK Maratón

-.
5,0
0 10.000 20.000 30.000 40.000 50.00c
Distancia (metros)
Figura 43.3. Velocidad media de los plusmarqu¡stas mund¡ales en carre:-

de varias distancias. Como en las carreras, los desarrolladores de softvaz
deben llevar ritmos distintos en proyectos largos y cortos.
43.2. Gestión de los r¡esgos de las horas extras voluntarias

Muchos de 1os riesgos asociados con 1as horas extras moderadas están r¡-¡-
cionados con el exceso de horas extras y la presión de planificac:c:
Estos riesgos han sido descritos en la sección anterior. Vamos a citar-:r:
adicional.
Reducción de la capacidad de responder a necesidades de emer-

gencia de más horas. La planificación de las horas extras se alime-:¡
directamente de sus reservas. Si piensa completar su proyecto traba-ia:-r:
40 horas a las semana, puede pedir que se hagan horas extras cuando te:+
problemas. Es probable que pueda pedirlas sin tener que preocuparse sL-r::
su efecto en la motivación. Pero en un proyecto en el que todo el mundo _, l
está haciendo horas extras no puede pedir más sin dañar la motivaciri: I
reducir la productividad, 1o que implica que ya no tiene margen de maniob:"
Para evitar este problema, use las horas extras moderadas sólo co:::
una medida correctora. No planee inicialmente en un proyecto que ---.
desarrolladores trabajen más allá de su programación nominal. Si tre==
problemas posteriormente, podrá acudir a las reservas y poner de nue . :
el proyecto en el buen camino.
43.3. Efectos secundarios de Ias horas extras voluntarias

El uso moderado de horas extras no tiene efectos secundarios sobr: -¡
calidad, facilidad de uso, funcionalidad, u otras características del r::-
yecto o producto.
Capítulo 43: Horas extras voluntarias 653
43.4- lnteracciones de las horas extras voluntarias

con otros métodos
cuando no se usan adecuadamente. las peticiones de trabajar
horas extras
pueden llevar a una excesiva presión de planificación
tvéase <.pr.rió.,
siva en la planificación>>, en la Sección 9- l t todos *s problemas
1-
"^.._
asociados.
Como las horas extras realiz¿rlas ¡ror iniriatira ¿et Oesarrolado¡ (en
lugar de las hechas por presión del responsable I sr:n el ,nico
camino para
tener éxito en el uso de horas extras. eris-te me relacitrn
con los metodos
orientados a la motivación (Capítulo I I l- incl¡ry.endo el erxrprorniso
f Ca_
pítulo 34) y el equipo de trabajo (Capítulo llt-
Generalmente, se requiere er uso de horrs errnrs noderadas para
soportar los hitos miniatura (Capítulo 27 l. el desrrollo en r-rerr¡¡nas
tem_
porales (Capítulo 39),Ia entrega evolutiva (Cepírxlo _10r
el gototipado
evolutivo (capítulo 2l) y otros métodos de desrroüo p. áopuo
r.-
chas límite frecuentes.
43.5. Puntos cruciales de las horas extras rclunhrias

si el desarrollador medio pasa 40 horas sem.meres ca rr oñcin¡- elgrmas
investigaciones indican que sólo 30 de esas hces sm prtrrh;¡s
rJmes.
DATOS REALES 1991). Cuando se le pide a este desarrollador qa tnh+ rnftmüriamstrre
algunas horas extras más, como por ejemplo un l0 pr
iffi rr,. pasan
dos cosas. En primer lugar, el desár¡oiladoi p*se + k*
onis ¡ rr sem¡na
en la oficina, 1o que incrementa las horas produüi¡u$,úc
-lO ¡ -3i. spo_
niendo que la proporción de horas producrir:at reryocto
r hs bores trabaja-
das se mantiene constante. En segundo rug'r- et rtes¡ro¡I¡dr
edquiere
una mayor sensación de urgencia en el trabajo- v ¡ rrFrdñ
trar formas de incrementar er número de ha', r¡qtdrs füde
encon_
6,5 horas o más. Por tanto, las horas prodrrtirzs

¡l dúa de 6 a
s i¡¡¡rr,.mn de j0
a 35 suponiendo un incremento der i g pm rff) de ruüuir:uro
'5, fi¡nte a
un incremento del 10 por 100 en las horas pas¡drs cn ei
d¡srqc+n-
El punto clave de las horas extras r oluntarirs m¡is
ro incremento en las horas trabajadas ar día pr cirr
cnft-un li-ee_
pongamos de un l0 aun20 por 100, resultarágwlmeuc
d. ü ;;d"r-
eri rrn rncre-
mento desproporcionadamente grande en la profoctnided_
Fn los proyectos que empiezan a usar ras bor¡s .-n¡s lolmri¡s
dura-
nte la construcción o la prueba, ras horas exr:rs
la planificación general del proyecfo en un r0 o un
rcfu e¡nda a reduci¡
15 po" rm tJones-
1991), pero por encima de esto entran en jrgo res párd;das
de moti'a-
ción, y no es posibl e alcanzar reducciones Honales
de la planiñceción
empleando horas extras.
6St ;esarrolto y gest¡ón de proyectos informáticos
Desafortunadamente, en muchas organizaciones las horas e\rai -,;-

luntarias son un método recomendable que ya está ampliamente uril-z¿¡:
o es sustituido por horas extras excesivas y obligatorias. En promediu.. - --*
desarrolladores trabajan en Estados Unidos de 48 a 50 horas sema.:-3i
(Jones, 1991; Krantz, 1995). En Canadá y Japón, la situación es sin:.,,--
Esta situación nos lleva a la interesante posibilidad de que las orga::' '-
ciones en general podrían incrementar su rendimiento actual reduci3:.r:
el nivel de horas extras por debajo de 1as actuales.
43.6. Claves para el éxito en el uso de horas extras

voluntarias
Estas son las claves para tener éxito en el uso de horas extras voluntan-.
o Use la iniciativa del desarrollador en lugar de la presión de 1a r-

rectiva,
Actúe sobre las motivaciones del desarrollador, tales como realiz;-
ción, posibilidad de superación, el trabajo en sí, vidapersonal y op'.-r-
tunidades de supervisión técnica para aumentar el volumen de ho¡-.
extras voluntarias que los desarrolladores pueden querer trabaja:.
a Pida una cantidad de horas extras que pueda obtener.
a Tenga cuidado con que los desarrolladores trabajen demasiadas h¡-
ras extras, independientemente del motivo.
DeMarco, Tom, y Timothy Lister: Peopleware: Productive Projects an;
Teams. New York: Dorset House, 1987. El Capítulo 3 describe direc-
tamente problemas relacionados con el exceso de horas extras, y grar
- parte del resto del libro trata el tema desde diferentes ángulos.
Maguire, Steve: Debugging the Development Process. Redmond, Wash-
ington: Microsoft Press, 1994. El Capítulo 8 explora la debilidad de
los argumentos dados más a menudo para exigir grandes cantidade=
de horas extras.
Weinberg, Gerald M.: Quality Software Development, Volume l: Systeni:
Thinking. New York: Dorset House, 1992. Los Capítulos 16y 17 descn-
ben lo que les sucede a los desarrolladores irresponsables cuando esrán
en situaciones de estrés, y qué hacer para resolverlas.
Jones, Capers: Assessment and Control of Sofnvare Risks. Englewood
Cliffs, New Jersey: Yourdon Press, 1994. El Capítulo 13 describe al-
gunos de los problemas asociados con e1 exceso de horas extras.
B¡bliografía
rf tk Joint
Albrecht, Allan J. (1979): <Measuring Application Developmem rrofurry'}-F'lcañg'
S H A R E / G U I D E / I B M Ap p I i c ati o i nii e t o p m ent S¡'mpo sí¡a- ocrú¡e F{1
of Co&- ri lbeüper Effort
Albrecht, A., y J. Gaffney tiSa:)' <Software Functión. Source Lines
Prediction: A Software Science Yalidation>>,IEEE Transactins
orS@u''rErylEq¡' SE-9 t6t:
639-648.
Andriole, Stephen (1992): Rapid Application Prototqlping- Mass': aD Lúrrrylo-teErs- mruo:
Andriole, Stephen tf SSí), nÉust, éh.ap Requirements: Proto't1pe
s Elscl¡ @ SAñP'E-
85-87.
August, Judy (1991): Joint Application Design' Englewood Cliffs-
\J-: Yc¡'fu D¡em
Detcfop F:mgm;- ü4irre
Augustine, Norman R. (1979j:'(Augustine's Laws alnd Major S¡-stem
Systems Management Review: 50-76' Citado en Boehm'
1981'
gabich,w.(l9s6):SoftwareConfigurationManagement.Reading;}-l¡ss.:.{@.
Bach,James (1995): <Enough atát
pro."ts: What We Need -{¡e llero.*r,- EEf Srü*ry¿ rtrrz€r:
96-98.
Baker, F. Terry (1972): <chief Programmer Team Management of
Proüm ltqrugr' IBlls-'s-
tems Jotrnal, vol' 11, núm. l: 56-13.
Baker, F. Terry, y Hartan o. Mills (1973): <Chief Programmer Teamsr.
IMh. lol 19. rLn l]
(diciembre): 58-61.
Basili, Victor R., y Albert J. Turner (1975): <Iterative Enban¡m -r fM Tcrliqr for
Software Development>>, IEEE Transactions on So-ffii'are frgú*.gnrg Sl¡-t- rfu" 4lÓcinnbrel:
390-396.
\-iúü Strrc,Eügine€
Basili, Victor R., y David M. Weiss (19Sa): <A Methodolog¡- fq- Coüctt! -3-ji.8'
, ring Data>, IEEE Transactions on software Engineering sE-10- 6 rmrr*r
--
Basili,iictor R.; Richard W. Selby y David H. Huichens ( 198ór: rEryrrrG¡¡n i S¿*rre Fng;r-
- t¡úc'r T-a--4i-
neering>, IEEE Transactions in Software Engineering SE-l1
Basili, Victor R., y Frank McGarry (1995): <Thi Experience Fectq- Ear
-- n hlú d Rn Ooe''
Tutorial M I , I 7th International Conference on Softn'are Engi&, (.rd¡ tFcfiEr' úlÚil :1'
Baumert, John (1995): (SEPG Spotliglts Maturing Softs-are t¡¡nfvr- trE¡. lúcz' $cFtiÉúbfE:
1 03-104.
Bayer, Sam, y Jim Highsmith <RADical Softr¡-are Dnelqrrcrr- -tb¡Ú &ogmar' ¡u-
nio: 35-42.
Beardsley, Wayne (1995): Comunicación privada: l7 de mrieÑa
Bentley,ion (iSSO): Programming Pearls. Reading' ltas: Afurcsfry
Bentley, Jon (1988): uoí" rrog,;mming Pearls: Conflrs'],r,ts q t C*- fl.@- l{¡sr: -{ddiscn-
Wesley.
Bersoff, Eáward H., y Alan M. Davis (1991): (Impasts ofliftcyct lÚo*
m Softr.a¡e cmfigE-&ron
Management>>,CommunicationsoftheAC\t-rol.}{.nh.tll8u!¡ot:lo4-ltE.
655
I
I
¿tt t_t¿, á d
:':".::: H'- et al (1980): Software ConJigttratíon Management -trnglewood

_- --;::'1 Cliffs. N.J.:pren-
-3 -1: i:rnegie I
i':,:¿::. Jr.hn I 1987): Crunch Mode. New york: yourdon press. Guide,
3¡e:::r' Barry W. (1981): Software Engineeríng Economics. Englewood Cliffs, r,¿¡rol1.
N.J.:prentice Hall. P¿
ts:'elrm' Barry (1987a):
W. <Improving Software Productivity>>,-IEEE Computer, septiembre: Il'all 5
43-57.
Bt-¡ehm' Barry w. (1987b): <Industrial Software Metrics rop to List>¡, IEEE
soJiw)re, vol.4, núm.9 Ihon'. Tst
tseptiembre): 84-85. \Id.: I
Boehm, Barry w. (1988): <A Spiral Model of Software Development Coad. Pete
and Enhancement>>, computer,
mayo:61-72. Conneli. -I
u""lT,"l":1t W. (1991): <Software Risk Management: Principles and pracrices>, IEEE don Pr
software, ene-
ro: J¿-+t. Constantir
B oehm, Barry W., ed. (1989): So;ftware Risk Management.Washtnston, enero:
D.C.: IEEE Computer Society press.
Boehm, Barry W., et al. (1984): <A Software Development Eniironment Constantil
for Improving productivity>,
Computer, 17 (6): 30-44. Constantir
Boehm, Barty, et al. (1995): <Cost Models for Future Software
Life Cycle processes: CoCoMO 2.0), Constantir
Annals of Software Engineering, Special Volume on Software process
and prodttct MeasuremenÍ, Conte. S.
J. D. Arthur y s. M. Henry, eds. Amsterdam: J. c. BaltLer AG,
Science publishers. Pa¡k.
Boehm, Barry W'; T. E._Gray y T. Seewaldt (1984): (PrototypinÁ Costello.
Versus Specifying: A Multiproject
Experiment>, IEEE Transactions on software Engineeriig sÉ-to Engiti
lmayo): 290-303. (También en
Jones 1986b..¡ Curtis. Bi
Boehm, Barry, y F. c. Beiz (1988): <Applying Process Programming
to the Spiral Model>, proceedings Iulio
of the 4th International Software process Ihorkshop, Áayo. Curtis. B
Boehm, Barry w', y Philip N. Papaccio (1988): <understanding Progt
and Controlling Software Cosfs>>,IEEE
Transacrions on software Engineeríng, vor. 14, núm. 10 Curtis. Bi
Boehm, Barry, y Rony Ross (1989): <Theory-w Software Project
lictubre;: r462-14i7.
Management: principles and Exam- Curtis, B
p\es>>' IEEE Transactions on software Engineering
SE-15 (lurio):902-916, dings
Booch, Grady (1994): object oriented Anatyiis ancr Design; r4rlth Cusuma¡
ipprications, 2d ed. Redwood City,
Calif. : Benjamin Cummings. Sofn,
Brady, Sheila, y Tom DeMarco (1994): <Management-Aided Press
Software tngineering>, IEEE Software,
noviembre: 25-32. Davis, Al
Brodman, Judith G.' y Donna L. Johnson (1995): <Return on Investment
(RoI) from Software process Dedene.
Improvement as Measured by uS Industry>>, software process, v)ar€
agosto: 36-47.
Brooks' Frederick P., Jr' (1975): The Mythicát Mai-Month. ReadingjMass.: DeGrace
Addison-wesley.
Brooks, Frederick P', Jr. (1987j: <No Silver Bullets-Essence YouI
an¿ Rici¿ents of Software Engineering>,
Computer, abril: 10- 1 9. DeMarcc
Brooks, Frederick P., Jr. (1995): The Mythical Man-Month, cliff
Anniversary Eclit¡on.Reading, Mass.: Addi-
son-Wesley. DeMarc<
B¡ooks, Ruven (1977): <<Towards a Theory of the cognitive processes
in computer programming>, DeMarc<
International Journal of Man_Machine Studies, vol. 9: 73j-751. Proc
Blrg-rr (199i):TristarPictures.ProducidaporMarkJohnson,BarryLevinsonywarrenBeatty,ydirigi-
Com
da por Barry Levinson.
DeMarcr
Burlton' Roger (1992): <Managing a RAD Project: critical I
Factors for Success>, American program- set
n¡er. diciembre: 22-29. DeMarcr
Bylinskr' Gene r 1967): <Help wanted: 50,000 programmers >>,
FortLme, marzo: 74lff. Prac
card, Darid \' (1987): Sgffware Technology E"valuation p;og.;-;, Int''orntation Dreger,
14
chnologr.. r-ol. 19. núm.
and Software Te-
6 fulio/agosto): zll_loo. Dunn, R
card, David, ¡- Ed comer (r99{: <why Do So Many Reuse programs Dyer, W
Fait?> IEEE software, septiem_
bre: 114-11,1.
Emery, I
for (
Bibtiografía 657
carnegie Mellon University/Software Engineering Institute (1995):
The capability Maturíty Model;
Guidelinesfor Improving the softw,are process. Reading, Mass.:Addison-wesrey.
^
carroll, Paut B' (1990): <creating Nerv Software was Agónizing Task
for Mitch iaporFirm>>, The
Wall Street Journal, l1 de mayo: A1. A5.
Chow, Tsun S', ed' (1985): Tutorial; Softv'are
Quality Assurance: A practical Approach. silverspring,
Md.: IEEE Computer Society press.
Coad, Peter, y Edward Yourdon (1991): object-oriented Design.Englewood
cliffs, N.J.: yourdon press.
Connell, John, y Linda Shafer (1995): objecr-oriented Rapid"Protot"yping.Englewood
Cliffs, N.J.: your-
don Press.
constantine, Larry L. (1990b): <objects. Functions, and Program Extensibility
>>, computer Language,
enero: 34-56.
Constantine, Larry L. (1995a): Constanrine on Peopleware. Englewood
Cliffs, N.J.: yourdon press.
constantine, Larry (1995b): <under pressure>. Softw'are Develápment,
octubre: lll_112.
Constantine, Larry (1996): <Re: A¡chitecnne>r. Softu,are Developmenl,
enero: g7_gg.
Conte, S' D'; H' E. Dunsmore y V. Y. Shen ( 1986): Software Eigineering
Metrics and Models. Menlo
Park, Calif. : Benjamin/Cummings.
Costello, Scott H. (1984): <Softw-are Engineering Under Deadline pressure>>, -tu
ACM Sigsoft SoJtware 'o¡
Engíneeríng Notes, 9..5 octubre: l_í-19.
Curtis, Bill (198 1): <Substantiating Programmer \¡ariability>>, Proceedings -9r
of the IEEE, vol. 69, núm. 7
fiulio): 84ó. -{If
curtis, Bill (1990): <Managin-e rhe Real Leverage in soflware productivity of3
and euality> , American
Programmer, vol. 3, núms. 7-8 tjutio_agosto): 4_14. -lu
Curtis, Bill (1994): <A Mafure \"ier-of the C\L\f)>. American programmer,
septiembre: l9-2g.
Curtis, Bilr, et a/. (1986): <Softxare Pwcholog,w: The Need for anlnterdisciplinary program>, procee-
ea!
díngs of the IEEE, vol.74. núm- g t2gosroi: 1092_l106.
Cusumano, Michael, y fuchard Selb¡- t1995 lr sor
-l,ficrosoft Secrets: How the World,s Most powerJül u3
Software Companl' Creates Technologr- Shapes JIarkets. and Manages people. york: New Free (ol
Press.
Davis,AlanM.(1994):<Rew-ardsofTrkinsrhepaúLessrj¡a:-eleú>.IEEESofnare,julio: SOI
100_101, 103.
Dedene, Guido, y Jean-pierre De Vreeseitgs¡,, *Realities of Off_Shore Reengineering>, IEEE Soft_ ep
ware, enero'.35-45. U?I
DeGrace, Peter, y Leslie stahl (1990): ll-icked Problems. Righreous
Solutions. Englewood cliffs, N.J.:
Yourdon Press.
DeMarco, Tom (I 979): Structured Analysis and Slstens
Wciticarion. Tools and Technique-s. Englewood -ed
Clifls, N.J.: Prentice Hall.
-oI
DeMarco, Tom (1982): Controlling softv'are projecrs- \-eq-york: yourdon press.
DeMarco, Tom, y Timothy Lister (1985): <<Programmer Performance 'ug
and the Effects of the Workplace>, olq
Proceedings of the 8th International Conference on Iv2ftx'are
Engineering. washington, D.C.: IEEE
Computer Society press, 26g-272. soa
ottu:?:' Tom, y Timoty Lister (1987)'. Peopleo*are: Producrire projects and Teams. eu':
New york: Dor-
set House. sol
DeMarco, Tom, y Timothy Lister (1989): <Software Development:
State of the Art vs. State of the
Practice>, Proceedings ofthe Itth International Confereice
on Sofware Engineering; 271-275.
Dreger, Brian (1989): Function point Analysis. Englewood -F
Clitrs- N.J_ prentice Hall.
Dunn, Robert H. (1984): Software Defect Removal. New york:
McGraw-Hill. ue
Dyer, W. G. (1987): Teambuilding. Reading, Mass.: Addison_Wesley.
Emery, Fred, y Merrelyn Emery (1975): Paiticipative Design-work
ott
and community. Canbena:Cenrer -ar
for C ontinuing E ducati on, Australian Nati ónal Univeri=iry,.
ou
a6 I
'a-n
sil!
€FE Fg
4,,-i-
-íd-=
t ali i"e
Bibliografía 659
Do You Motivate Employees?> Harvard Business

Herzberg,Frederick (1987): <one More Time: How
Review, septiembre-octubre: 109-120' i rr,^,r^^r^-. r¡^-. . ñFT'r rnf
Testing,2nd ed' wellesley' Mass': QED Informa-
Hetzel,Bill (1988): Tbe Complete Guíde to software
tion SYstems'
work: Building an Effective Measurement Program'
Helzel,Bill (1993): Making software Measurement
New York: John WileY & Sons' process. Reading, Mass.: Addison-wesley.
Humphrey, watts S. Oii6, u"""ging the software
Engineering. Reading, Mass': Addison-wesley'
Humphrey, watts S. (1gg5j: I D*íiphnefor softror" School Case
Ofhce Bu*siness Uniu' Harvard Business
Iansiti, Marco (1994): <Mícrosoft Corporation:
Harvard Business School'
Study 9-691-033, revisado el 3l de mayo' Boston:
Proiuctivity' New York: McGraw-Hill'
Jones, Capers (1986a): Programming
erogro*iírg Productivity: Issues for the Eighties' 2nd ed' Los
Jones, Capers, ed. (1986b); Tutorial:
Angeles: IEEE Computer Society Press'
Jones,capers(1991):AppliedsoftwareMeasurement:AssuringProductivityandQuality'NewYork:
McGraw-Hill.
Jones,Capers(1994):AssessmentandControlofSoftwareRlsks'EnglewoodCliffs'*:l-l:-I:T1::ttttt junto 3-12'
Jones, Capers (1994b): (Revitalizing Software
r.o¡á.t rtlunu gemenf>-,.American Programmer' -u¡
7th ed" mar-
RÉsearch Piogramming Languages Tubl,t:t'
Jones, Capers (1995a): <Software Ploductivity a la tabla completa vía
U.
Softwu.. pro¿rr.iiuity nt*"u"tttt' (Puede acceder
'4
zo 1995.Burlington, Mass.:
Internet, en la dirección http://www'spr'com/library/langtbl'htm') IEEE Software' -tIt
Jones, Capers tf SSSUI: d;teás of furg.
Soit*ure dysteÁs: Failure and Success) ' o11
marzo: 86-87. -ü
Jones,Capers(1995c):<DeterminingSoftwareSchedules>,IEEESoftware,febrero..T3-75.
So Hard?> IEEE Computer, iuo¡o: 86-87 '
Jones, capers (1gg5d): uwny r, TeÁnology-Transfer
Joos, Rebecc a (1994): <Softíare Reuse at
Motorola>' IEEE Software' septiembre: 42-47 ' e3i
New York: Dorset House' sol
Karten, Naomi (99a): Managing Expectations'
Smith (1993): The Wisdom of Teams.Boston: Harvard Business School Press. ua
Katzenbach, Jon, y Douglas
of Slftware Cost Estimation Models>' Communica-
Kemerer, C. F. (1987);-ue,,empi.l.al íalidation ((o
tíons of the ACM,30 (5):416-429' sol
to Buitd Functional Computer systems
Kerr, James, y RicharJ nol.. Q9g4): Insíde RA.D:_How ::t:l ep
ing0DaysorLess,NewYork:McGraw-Hill.(IncluyeunaentrevistaconScottScholz,entreotras u3
cosas.)
Boston: Atlantic Monthly/Little Brown'
Kidder, Tracy (1981): The soul of a New Machine.
Kitson, David H., y Stephen Masters (1gg3): uÁr,
Árutyrl. of SEI Software Process Assessment Resul-
Conference on Software Enginee- -e(
ts, 1987-1991 >r. En Pro"e"dings of the Fifteenth international
-ot
ring: 68-77. Washington, D'C': IEEE Computer Society Press'
Klepper, Robert, y D;;;i"' É"ck (1995):-<TrriiJ *¿
rouiir Generation Language Productivity Diffe- rq
rences)), Co*muní"Ztion, of tie AiM, vol. 38,
núm' 9 (septiembre): 69-79 ' ¡üÍ
Kohen, Eliyezer (1995): Comunicación privada: 24
dejunio' 5ü
Kohn,Alfie(1993):<whylncentivePlanscannotwork>,HarvardBusinessReview'septiembreloctu- mtr
brel.54-63. 9¡[
<An Empirical Study of Modularity on Program
Korson, Timothy D., y Vijay K. Vaishnavi (1986):
Modifiability>. En Soloway e Iyengar (1986): 168-186'
Weekly Jobs Rated Almanac' New York: John
Krantz,Les (1995): The Natioial iuriies, Empíoyment
WileY & Sons.
Influencing the Performance of Software Develop-
Lakhanpal, B. (1993): <Understanding the Factors
and Software Technolog'-'35 (8):
ment Groups: An Exploratory Group-Lev e1 Analysis>>,Infoimation
468-4',13.
Jilsr+ dtl¡ á/:

-o *éT7
E ité; ñ- e C.9¿
¿
3 c, xgrafia
"!:::,3::3- Lurz -{. (1990): <Software Size Estimation of Object-Oriented Systems>, IEEE Trans¿;-
":r..: :r. So.Ínrare Engineeríng, mayo.
i:{- Carl E.. y Frank M. J. LaFasto (19g9): Teamwork: What Must Go Right; 14/hat Can Go
\:abury Park, Calif.: Sage.
¡,jer:r. -\lbert L., y Jayesh prasad (1992): <Nine Management Guidelines for Better
Cost Estimatins
Communications o;f the ACM, febrero: 5l_59.
Lr.ons. vichael L. (1985): <The Dp psyche>, Datamatir¡n, r5 de
agosto: r03-r09.
\faguire, Steve (1993): wríting sotid code. Redmond, wash.: Miciosoft press.
\laguire, Steve (1994): Debugging the Development Process. Redmond, Wash.:
Microsoft press.
\'larciniak, John J., y Donald J. Reifer (1990): Software Acquísition Managemenr. york:
New Joh:
Wiley & Sons.
lvlarcotty, Michael (1991): software Implententation. New york: prentice
Hall.
'\f artin, James ( i 99
I ) : Rapid Apprication Deveropment. New york:
Macmilan.
\fcCarthy, Jim (1995a): Dynamics of Software Development Redmond, Wash.:
Microsoft press.
McCarthy, Jim (1995b): <Managing Software Milestones at Microsoftr>, American programmer,
febre-
ro: 28-31.
McCarthy, Jim (1995c): <21 Rules of Thumb for Delivering
Quality Software on Time> (disponible er
cinta de audio o vídeo). Copia de una conferencia(.717) zis-oiso (Sesión
04, Conf. #69gD).
Mcconnell, Steve (1993): code comprere. Redmond, wash.: Microsoft press. :.:-.
McCue, Gerald M. ( 1978): <IBM's Santa Teresa Laboratory-Architectural
Design for program Der elt-- -;::- ;
pment), IBM Systems Journal, vol. 17, núm. 1: 4_25.
McGarry, Frank; Sharon waligora y Tim McDermott (1989): <E,xperiences in o:tqz
the Software Engineenns
Laboratory (SEL) Applying Software Measurement>>, Proceidings of the
Fourteenth Anluat So¡¡-
ware Engineering workshop, November 29. Greenbelt, Md.: cÑdard
ment SEL-89-007.
Space Flight c"rrt.., Á.r- p:i r
Metzger' Philip W. (1981): Managing a Programming Project.2d ed. Englewood SOIOU
Cliffs, N.J.: prentrc¿
Hall. ua ¡JC
Millington, Don, y Jennifer stapleton (1995): <Developing a RAD Standar d>>,IEEE
software, enero: 54-5 j (<o\tr
Mills, Harlan D. (1983): software productívíty. Bosion, Mass.: Little, Brown. sounS
71-g1.
Myers, Gienford J. (1978): <A Controlled Experiment in Program testing
and Code walkthrougs,Ins- 3P au
pections>, Communications of the ACM, vol.21, núm. 9:-760-:'6g.
Myers, Glenford J. (1979): The Art of software Testing. New york: u¿i{ s(
John wiley & sons.
Myers, ware ( I 992): <Good software Practices ray oif--or Do They?>,
IEEE software, marzo: 96-9- .
Naisbitt, John (1982): Megatrentls. New york: Warner Books.
-r*aisbitt, John, y Patricia Aburdene (1985): Reinventing the Corporatio¡r. New york: -ed sot
warner Books.
NASA (1990); Manager's Handbookfor SoJtware Developmeni, revisión -OISJE.\
l. Documenro número SEL- .UOIJEl
84-101. Greenbelt, Md.: Goddard Space Flight Center, NASA.
NASA (1994): software Measurement Guidebook. Documento número orque:
sEL-94-002. Greenbelt, Iv1d..
Goddard Space Flight Cenrer, NASA soJOI Ji
o'Brien, Larry (1995): <The Ten commandments of Tool Selection>, ¿u-l
soJtware Development. noviem- s(
bre:38-43.
soganb
o'Grady, Frank (1990): Rude Awakening>, American programmer,.¡ulio/agosto : 44-49.
-<A
olsen' Neil C' (1995): <Survival of the Fasteit: Improving seriice vetocty>, t"tcz so¡t.ore, septiern-
bre:28-38.
Page-Jones' \feilir (1988): The Practícal Guícle to Structurerl -Fc olei
systems Design. Englewood Cliffs. N.J..
Yourdon Press. ua sorql
Parnas, DaYid L' r 1912 ): <on the criteria to Be used in o31e op
Decomposing Systerns into Modules >>, contnr,-
níccttiors o,r'ri¡e -iC-rÍ. r.o1. 5, núm. r2 (diciembre): r053-1'05g. -aJJO3 u
ou SSUO
¡S OU SC
'3J¿.!!JC
\s$\La
-t,¡s}]
O:-iioG
A I !{E >
=
<i.r
Bibtiograf ía 661
-Parnas,DavidL.(1976):<ontheDesignandDevelopmentofProgramFamilies>,IEEETransactions
*-"on'
So1r*ore EngineerinC SE-?' lm:rzol: :-9Ease of Extensron ancI Contraction> , IEEE Transac-
1
d'esigning Software for
Parnas, David L' (f SlSl:
':::K:;^;V!fli¿:.f::XJ,'i 'ü:ií?;Jii;lii, S,ruc'fure orcomplex Svs'fe'
",n:X".l*"r
matzo" 259-266'
ms>>,
Soft**' Eng-íneerin*'
IEEE l''on'o'"'¡ol'- on 183 (8 de manzo' e22-32'
parsons, H. M. (1e74),:;ffi; róened at
Maturitv Modet' version 1
"";il;i;;,"iri"*r",,.,t' /' Software
paulk, M. c.,
*-e"elt..ringet at' ó;;;:'¿;;;;"i:: "!.ii')"ó"p"tttu'
Institute' cMUisEI e3-llii;it*i"11; G. votta (1eea): <People, organizations' and
^
Standenmayer y
e.rry. ó.*uyn. E't Nuntu A'
Process trrrp.o"t*t"ó '
IEEE Soflwye.', julio" 36-45 '
york: A,rred A
íÍ|,"r,ment Revotu,on New
i1*:klil.,ffTf:;#:,:;:IJiIIiiili);l]|:,T
Inc'' abtt'l" 80'
'iíi"árrl
Revista
,*"TJTil (198s): <Letter to the Editon' York: Warner Books'
peters, Tomas J., y R";;;. w;;;*"r,
,;. ttJtrl'
e (199.4a¡:"llttl:Tt?iJáiSott*ut"
Mtutu"tt"t '93: Report from an Ob-
"l.n.celt'ence'New A
-uJg
Pfleeger, Shari Lawrenc
'.,*::'Jki.',flffi:::'r';:;;Xíi,ff,','."".t# at rcSE> (mavo' en So-
'0;¡l
rown, Practitioner value up 'g¡e:
Ji *¡.."".n.g the Sortware Process>>'

sortware -ür[
ftHi*T,,;]ig1;áii;1":¡¡r3;i'i-1"Ji""fi'.'":-l
Practic";";;i:-i' núm' i (mavo/iunio;:29-34' Ninth Annual Pa-
oleq
Engineering: r""t)"íí'í'¡ques' li.tftou"*"nt>>' -n¡3
pietrasanta, Alfred M. (1991a): <A Srrategy";;"t;ffi;'P;;t; Z-A' O'ngoiéonvention
Center' Portland'
Conpr"lr", O""oi"'
ciJic l,{orthwest Sofiware Quality ¿3S r
N.J.:
Ore. Design. Engle*'ood Cliffs,
(i993a): Programming on Purpose: Essa,-s on Softvr,are sorq¡
Plauger, P' J.
ue 3J
Prentice Hall PTR' Engie$ood Cliffs'
programmíng on Purpose II: Essays on So-ifi''are People' ((oN)
plauger, p. J. (1gg3;)i..
soun
Ñ.J.: Prentice Hall PTR'
Pressman,RogerS.(1988):MakingS"ry,'::EngineeringHappen:.lGuide.l.orlnsiruingtheTechno- aP al
A practitioner's Approach
id ed \et York: \rcGrai¡' u¿r.l f
."i,g",*;lS*;;lU*; ::";:;i:::::r:
Hill.
the"sEl Scale>' )Ianaging s-r'sren¡
Pressman,RogerS.(1993):AManager,sGuidetoSoftwareEngineering.Ner*'York:\fcGrarr'-Hil1. -ad sc
putnam, Lawrence i. ltol+,, urt. ¡,.orro*iJlJ".lrMovinfup -orsJa
DeveloPment' julio: 1-6' Reliable Softv'are on Time' .UOIJI
(1992 ): Measures for Excellence:
putnam, Lawrence ii- ,'ñ1.. Myers
'::**":;:^,ití';xi,;liTLi;,'Y;#l'"-"iiyy1'^yptiembre:contraportada olqilE
sü¡cri
Prospects>>' IEEE
,Áto*utic Programmi"g' It{vtltt and E_l
Ricn, cnarles, , *r".iiri"ó."rvíárJ irsasf
i
Computer, agosto' CMUiSEI-,I-ll Pins- rT¡¡cr

Practice>). lnforme cMuisEl-gl-TR-16'
i. Practice>'
--.-^*o¡r in
Stan, y ch;;i;. cox (1g91): <Measurement
Rifkin,
a computer Svstemr' ,rrsi-
rncompetent-But rry Firing
;:;ft.f1 ?,,"rffi11;;Siffi:l?iq:i:!ry, *ui
**o- E¡ IN¡I
IEEE So-tt-
úmr q
il;iliñe-scalebevelopments>'
-
Russelt, Glen w. (1991): <Experience.*t,tfiü#in
^";:¿{;?f;J,i:ff;:'f;:i'*il,-.i?i;y:-y:::T.:".'lii,xli--?¡Íi:,;:::i*::;J,*: i@m¡.
vol' 8' núm' 1 (enero): 25-31'
ware' @m
I,m!
q
u¡
-t¡ti
É
o $-s€Értr Te
f/ -a
ar u)
cd
t ", -.{-
áE v.-s I
n ffiaa
kE, H.- Y/- J- Erikson y E. E. Grant (1968): <Exploratory Experimental Studies Comparing Online
dOffiine Programming Performance> , Communications of the ACM, vol. 11, núm. 1 (.n..ó;, :-t t. €
9
$-c'¡rr, Hmsein, y Scott Hamilton (1995): <Case Studies of Hughes and Raytheon's CMM Efforts>, *
:.
IFFF Computer, enero: 20-21. ¡
Scferr, Allen (1989): <Managing for Breakthroughs in Productivity> , Human Resources Management, I
i
vol.28, núm. 3 (otoño): 403-424.
fr;l'ola.et al. (1994): <Object-Oriented Programming: the Promise and the Reality>, Software practitio-
ner, enero'. 7, 4-7.
Sherman, Roger (1995a): <Balancing Product-Unit Autonomy and Corporate Uniformity>>, IEEE Soft-
ware, eÍero'. 110-111.
Sims, James (1995): <A Blend of Technical and Mediation Skills Sparks Creative Problem-solving>,
IEEE Software, septiembre : 92-95.
smith, P. G., y D. G. Reinertsen (1991): Developing products in Harf the Time. New Van Nos-
trand Reinhold.
Sommerville, Ian (1996): software Engineering,6th ed. Reading, Mass.: Addison-wesley.
Standish Group, The (1994): <Charting the Seas of Information Technology>, Dennis, Mass.: The Stan-
dish Group.
-{rr"3
S¡rmons, Charles (1991): Software Sizing and Estimating: Mk II FPA (Function Point Analysis). Chi- -o3l¡l
chester: John Wiley & Sons.
'9rsr¿
Tesch, Deborah B.; Gary Klein y Marion G. Sobol (1995): <Information System Professionals' Attitu-
des>>, Journal of Systems and Software, enero: 39-47. -ürg i
Thayer, Richard H., ed. (1990): Tutorial: Software Engineering Project Management Los Alamitos, ofeqr
Calif.: IEEE Computer Society Press. -n:3 ¡
Thomsett, Rob (1990): <Effective Project Teams: A Dilemma, A Model, A Solution>, American pro-
grammer, julio-agosto: 25-3 5. eas s
Thomsett, Rob (1993): Third Wave Project Management Englewood Cliffs, N.J.: Yourdon press. sorqu
Thomsett, Rob (1994): <When the Rubber Hits the Road: A Guide to Implementing Self-Managing u3 3lq
Teams>>, American Pro grammer, djciembre: 37 -45. (oND
Thomsett, Rob (1995): <Project Pathology: A Study of Project Failures>, American programmer, julio:
souni
8-16.
Townsend, Robert (1970): up the organization New york: Alfred A. Knopf. eP 31J
Tracz, Will (1995): Confessions of a Used Program Salesman. Reading, Máss.: Addison-Wesley. u?q s(
Udell, John (1994): <Component Software>, Revista Byte, mayo: 45-55.
Valett, J'' y F. E. McGarry (1989): <A Summary of Software Measurement Experiences in the Software
Engineering Laboratory>, Journal of systems and software, 9 (2): r37-14g. -ed sol
Van Genuchten, Michiel (1991): <Why is Software Late? An Empirical Study of Reasons for Delay in -oIs.¡eá
Software Developmentr>,IEEE Transactions on Software Engineering, uoi. 17, núm. 6 'rg!"el
fiunio): 5g2-
590. orqlu¿:
Vosburgh, J ' 8., et al. (1984): <Productivity Factors and Programming Environm ents>>, proceedings
of sosol Ji
the 7th International Conference on Software Engineering, Los Álamitos, Calif.: IEEE Computer
¿un's(
Society: 143-152.
Weinberg, Gerald M. (1971): The Psychology of Computer Programmíng. New york: Van Nostrand souanb
Reinhold.
v/einberg, Gerald (1982): Becoming a Technicar Leader, New york: Dorset House.
weinberg, Gerald M. (1992): Quarity software Management, vorume r: systems Thinking. New -l.rJ of¿i
Dorset House- u3 sorqt
Weinberg, GeraldM- (1993): Quality Software Management, Volume 2: First-Order Measurement.New o8¡e op
York: Dorset House. -3JJOJ U
ou seuo
35 OU sc
'are,tgc
\q\Ñ\IA
-tes31
€!)
"d_ Bibliografía 669
Weinberg, Gerald M. (1994): Qualitl, SofÍware Management, Volume 3; Congruent'Action. New york:
Dorset House.
Weinberg, Gerald M., y Edward L. Schulman (1974): <Goals and Performance in Computer program-
ming>, Human Factors, vol. 16, núm. 1 (febrero): 70-77.
whitaker, Ken (1994): Managing Softv,are Maniacs. New york: John wiley & Sons.
Wiener, Lauren Ruth (1993): Digital I|loes; l{hy Lí¡e Shoulcl Not Depend on Software. Reading. Mass.:
Addison-Wesley.
wirth, Niklaus (1995): <A Plea for Lean Software>, IEEE Computer, febrero:64-6g
Wítness (1985): Paramount Pictures. Producida por Edward S. Feldman y dirigida por Peter \\-eir.
Wood, Jane, y Denise Silver ( 19951: Joint Application Development, 2nd ed. New York: John \\'iler &
Sons.
Yourdon, Edward (1982), ed.: Writings of the Revolution; selected Readings on Softt+,are Engineering.
New York: Yourdon Press.
Yourdon, Edward (1989a): Modern structured Analysls. New york: yourdon press.
Yourdon, Edward (1989b): structured Ll/alk-Throughs, 4th ed. New york: yourdon press.
Yourdon, Edward (1992): Decline & Fall of the American Programmer. Englewood Cliffs. \.J.: \-our-
don Press.
Yourdon, Edward, y Constantine, Larry L. (1979): Structured Design; Fundantenrals o.f-a Distipline o.l
Computer Program and Systems Design. Englewood Cliffs, N.J.: you¡don press.
Yourdon, Edward, ed. (1979): Classics in Software Engineering. Engleu'ood Clilfs. \.J.:\-ourdon Press.
Zachaty, Pascal (1994)'. Showstopper! The BreakneckRace to Creare II'indots J-T and the \-e¡r Gene-
ration at Microsoft. New York: Free Press.
Zahniser, Rick (1995): <Controliing Softu'are Projects u'ith Timeborin_s,,. So/hr'a¡e Detelopnent.marzo.
Zawacki, Robert A. (1993): <Key Issues in Human Resources l\fanasement>t.InJbrmatíon Stsfems J[a-
nagement, invtemo:'7 2-7 5.
Zelkowitz et al. (1984): <Software Engineering Practice in the US and Japan>, IEEE Computer, jumo:
5'7 -66.
ñG é-n 7
872€É:
4.._-{-i
ü Érta"v¿
O-?irc¡cú
O=l5ot>
_ :1:;
lndice
F^
Caracteres especiales August, Judy, 488, 492,499,500

3GL (lenguajes de tercera generación), 396 Australian Computer Society, concurso de
cambio desde un, 390-393 software, 68
4GL (lenguajes de cuarta generación), 396 <<Automatic Programming: Myths and
cambio a un, 390-393 Prospects> (Rich y Waters), 397
90-90, problema,622 automática, programación, 397 -ule
-83r.
autonomía, sensación de
de los miembros del equipo, 309-310
'qja
Aburdene, P atricia, 2'l 9 el trabajo como motivación y, 280 -sry
aglomerados, entornos de trabajo, 48 <Avances en las inspecciones de oisq
agotamiento software>>, 86 -n:3
compromiso (signing-up) y, 586 azar, 1.15
planificación demasiado optimista y, 236 planificación excesivamente optimista y, ¿as
Albrecht, Allan J., 189,203 235 SOIq
alto riesgo, 1 14-1 15 ua al
Amish, equipo para levantar granero, (oNi
295-296, 300, 301, 302, 309, 3 1 1, 3 16 Babich, W.,77 soun
Andriole, Steven 1., 619 Bach, James, 47 eP a:
apego al plan en planificación Baker, F. Terry, 329, 330 u3r{
excesivamente optimista, 230 bases del desarrollo de software, 13,20,
aplicaciones a medida y herramientas para 59-88,427
productividad, 378 bibliografia adicional. 7 5 -7 7 -ad sr
Applied Software Measuremenl (Jones)- control de calidad (téase calidad, control -OISJ:
221, 511 de) 'uoI3l
apreciación (reconocimiento) e-iemplo: falta de fundamentos, 60-63 olqur
fallo de los equipos y falta de, 313 gestion. 63-68 soJoi
falta de, como destructor de la moral.
289
seguir las instrucciones sobre, 86-88
técnicas. 68-75
I eull'
sogJr
motivación y gestos de,284-285 Basili- \'ictor R., 17, 19, 84, 390, 505,
Art of Software Testing, Zfre (Myers), 85 511.599
Assessment and Control of Software Risks Baumert. John. 66
(Jones), 1 18, 175, 221, 210, 400, 654 Ba1-er. Sam. 310 & $c{
asumir riesgos, 108 Becoming a Technical Leader (Weinberg), drm I
Auerbach, Red, 59 293 -@tu6

úfi!
s,@
mü
n
{ü
o
I
a
o
.
É
*s
,1r
i
:: :.:. l,le:edith. 306
fundamentos del, 78_g6
: =-:. : C.. 175 bibliografia adicional sobre. g5_g6
-::-:_;-,'. lon, 77, 472
comprobación, g2
-i -:_¡.. ti Edward H., 7 7
3::inan. James M., 467, 471, 472, módulos propensos a errores. g l
474, revisiones técnicas, g2_g4
175,419,479,617,643
Biggerstaff, Ted, 576 tasas de defectos, 7g_g0
bloqueos, solución en negociaciones objetivos del, l9
cambio
conveniente s, 246
Bock, Douglas, 390
s-- diseño paru (véase diseño para
el
Boddie, John, 339, 365,41g.650 cambio)
gestión de un equipo de alto rendimiento
Boehm._Barry W., 16. t7 . 46.
5l . 52. 7 l, y,3tt-312
gg-83, 93, 104, 117, 136, 175,
cambio de personal
196_199, 209, 220,231, 236,
269, 278, configuración de equipos a largo plazo
2_93, 295, 2gg, 361, 453, 49ó,
52í, y, 317
552, 559, 604,613,64g _*1,
planificación demasiado optimista
Boeing,277 y, 236 'l:.-
cambios, análisis de, 364_365
Booch, Grady,76
Brady, Shelia,585, 650 cambios, grupos de control d,e, 366-36g,
Brodman, Judith G., 512 437
c¿ncelación de proyecto s, 344
Brooks, F¡ederick p., Jr., 47,225,241
, Capability Maturity Model, The (Carnesie
329, 336, 342, 376, 37g,396, 400,
409,446,454, 575 Mellon UniversirylSoFtware
e:s E
Brooks, Ruven, 376 ^ Engineering Institute), 34, 67
Card, David, N., 17, g3,269,'572,5i3
so¡o..1
Bugsy (película), 371 u3 3i(
Building Qualiry Sofrware (Glass). Carnegie Mellon University, 34
(o\i))
Burlton, Roger, 63.464
85 Carroll, paul B., 29,370, i2l
souni
cascada, modelo de ciclo de
búsqu¡la V rescate, modelo de equipo, vida, l4g_l52 ap 31J
332_333
modificado, 155_t59
uuq s,
Butler Cox Foundation, 317 con reducción de riesgos, 15g_159
Bylinsky, Gene,224 con subproyectos, 157_15g
modelo sashimi, 156
-ad so
ventajas e inconvenientes. 170
-oIsJ31
caída de rentabilidad, fecha CASE. herramienras. 393, 3g5.396
fija de, 'uotJ€:
126 casos. estímación basada en.
calidad 196
baja Caswell. Deborah L., 516 _ . ^,- -
a
categorías, estimación por, 193
como enemigo de la moral,29l : -.-- :
coxstrucción y prueba diarias y,440
ciclo de vida, planificación (modelos : --:
de
equrlibrio de factores y, 140 ciclo de vida), 20, 145_i55, lAq-iá5,
medidas de líneas de código, 259. Véanse tqmbién modeios
515 específicos
plan i ticac ión ercesivamen"re '1
¡a r 1. -
optimista Y, codificar y corregir (code_and_fix),
1J- i \ ry
calidad. conrrol de modelo, 152 I

escatimar en. cono error clásico, diseño por herramientas, 165
52 diseño por pianificación. 162
L¡¡dLA. IAts'I
e.l)J¡):.-X-O-
índice
identificación, 128, 260

ciclo de vida, planificación (cont')
riesgos asociados con, 97
ejemplos
selécción eficaz del modelo de ciclo CNA, ComPañía de Seguros, 499
de vida, 112-174 Coad, Peter, 76
selección ineficaz del modelo de ciclo COCOMO, modelo, 198
de vida, 146-148 Code Complete (McConnell), 76, 85, 370'
450,460,468,564
enlrega Por etapas, 16l-162
métoáos de desarrollo incremental, 165
codificar a destajo (code-like hell), método
(enfoque basado en el compromiso)'
modelo en cascada, 148-152
28-30,200
modelo en cascada modificado, 155-159
como error clásico, 53
prototiPado evolutivo, I 59- 160
desventajas, 28-30
selección de, 501
selección del modelo más ráPido,
enfoque ie este libro comparado con, 30
éxitos y ventajas, 28
167 -112
codificar y corregir, modelo de ciclo de
software comercial disponible, 167
vida,152-153
ventajas e inconvenientes, l7 0-l'7 2
ventajas e inconvenientes, 170
ciclos breves de entrega, 366
código fuente, falta de control
<Cláusula de entendimiento) (con
áutomatizado como error clásico' 56
clientes), 350
código, lectura del, 83
Clements, Paul C',460 299
cohe"sión y rendimiento de los equipos'
cliente, desarrollo orientado al, 21,
Comer, Ed,5'72,573
253-268
comercial, definición del software' 27
importancia de los clientes para el
desarrollo ráPido, 251 -259 Communications of the ACM,342
Complete Guide to Software Testing' The
cliente, informes sobre satisfacción del,
(Hetzel), 85
261,262
259-264 <Component Software> (Udell), 580
cliente, métodos orientados aL,
compromiso
análisis de requerimientos, 260-263
con el equiPo, 308
bibliografía adicional, 267
con la selección de herramientas de
construcción, 263-264
productividad, 388
diseño, 263
planificación, 259-260 compromiso (signing uP), 581-588
procedimientos para requerimientos, 364 a nivel de equiPo, 583
cliente, relaciones con el
claves para tener éxito al usar' 53--5SS ; .;rl
gestión TheorY-W Y, 605
planificación excesivamente optimista y, dar una oportunidad a las perscnas para
que adquieran. 581 T: _--
efectos secundarios. 5 i-
231 a----
y construcción y prueba diarias, 441
en diferentes entomos' 5!J
clientes
gestión de los nesg.'s 'ie' 585--;86-
entendimiento entre desarrolladores y, -
interaccioneS itlii otros métodos' 5S-
350
pUntOS Ci':;::;¡S SObre' 587
expectatir-as de los, 264-266
infundadas. 133-134, 264, 265 requiit:rienl¡s inciertos' 5 8-1
\iSrr-rrt r. iSl
fricciones entre desarrolladores y, 48
^ -- : , -71,-gg¡-2 írt
a ::
ar
ó:-"
o¿
lndtce
cLrmrpromiso. enfoque basado en. Véctse área de reserva para el código a añafu
codificar a destajo (code-tike-heil), al desarrollo,444
método (método basado en claves para el éxito,449
compromiso) construcción diaria del producto. -l-:-
comunicación construcción y prueba diarias inclu_*:
entre miembros de un equipo, 309 bajo presión, 446
estructura del equipo y,326 entrega del desarrollo por la mañane_
fallo de los equipos y,313 445_446
Confessions of a (Ised program Salesman exigir a los desarrolladores que
(Tracz), 579 realicen la prueba mínima antes ¡:
confianza añadir código al sistema,444
entre miembros del equipo, 308 fallos de construcción, comprobacior-
fallo en los equipos y falta de,314 441-442
confianza, estimación y factores d,e, l9j grupo de desarrollo, configuración de
confianza mutua, equipo de trabajo y, 30g ,¿n,443
configuración del software, gestión de la -n-F
penalización por fallar al construir.
(scM) 444_445
bibliografía adicional sobre, 77 prueba minima diaria del producto,
:--l
como fundamento del desarrollo, l4-75 442-443

Connell, John,479 tipos de proyectos que permiren usar
. :::
Constantine , Larry L. , 33 , 49 , 68 , j 6, 3lg,
este proceso, 446-441
320,342 Conte, S. D., 517
C onstantine on P eopleware (.Constantine), contratación de personal, métodos de,
33,342 46-47
construcción contratados. Véase también desarrollo
bibliografia adicional sobre,'7 6-77 externo (outsourcing)
como base del desarrollo, i2-'14 fallo de los, como error clásico, 5l
orientada al cliente, 263-264 riesgos asociados con, 98
construcción, configuración de un equipo contratos de desarrollo externos, 53 1,
de,443 533-534,536_538
construcción de un programa,440 control
Véase también construcción y prueba -ed sot
estimación frente a, 184
diarias pérdida de -OISJO1l
construcción y prueba diarias, 439_450 compromiso (signing-up) y, 596 'u9rcu¡
ahorro de tiempo obtenido con,440_441 orq(IIeí
desarrollo externo y, 539-540
bases de, 449 prototipado evolutivo y relajación del, soJoJ J
bibliografía adicional sobre,449 -450 4',72-473
€ufl 's(
efectos secundarios, 448 control de tráfico aéreo, software para soganb
gestión de riesgos en,44l-44g
estación de trabajo, 344
interacción con otros métodos. 44g_ C ontr o I I ing Softw a r e proj e c ts (DeMarco),
449
69, 143,220 -r¡c ol¿
resumen. -139 convergencia prematura o demasiado ue sorq
uso, 441-4-17 frecuente oE¡e op
añadi¡ códieo al desarrollo, 443 como error clásico, 52-53 -aJJO3 u
ou seuo
ás ou s(
'ar€.\\]JC
!s\t\rl
-?¡,iJ
o t-
r J:; ,/. á9
J -=
! =--
oo
la¡.Éti+j:i¡¿.i:;¡i.rii!,*rpri:¡Ltil.,tiiii,:..1:t;:
índice
convergencia Prematura (cont.) defectos, tasa de, 7B-81

planificación demasiado optimista y, de módulos propensos a errores, 81-82
232-234 DeGrace, Peter, 156, 175
convergencia prematura, planificación DeMarco, Tom, 17, 33,47,68, 130, 143,
excesivamente optimista y, 232-234 l8B, 202, 220, 236, 251, 269, 293,
coste 2gg, 31 1, 3 13, 3r7 -320, 342, 360, 546,
más bajo, como apariencia del desarrollo 554, 585, 650,654
rápido,126 Deming, W. Edwards, 286
equilibrio entre producto, planificación demostración, PrototiPo de, 63'7
y,139 deportivo profesional, modelo de equipo,
coste, ratios de, 81 334-335
Costello, Scott H., 225,25I desarrolladores
costes iniciales, configuración de equipos a como malos negociadores, 240
Iargo plazo Y,316 en sesiones JAD, 491
Cox, Charles, 504, 512 estimaciones PreParadas Por, 193
Cray, Seymour, 54 factores de higiene Para,287-288 -IIJE-1
<Creating New Software Was Agonizing fricciones entre clientes Y, 48 "O¿a11l
hitos miniatúra Pata, 522-523 '?¡a¡

Task for Mitch Kapor Firm> (Carroll),
meticulosidad, 54 -uru
310
,
creatividad, equiPo de, 325 motivacione s de, 2'7 1-27 4 oieqr

creatividad y planifi cación demasiado no participar en decisiones que les -r"16'1
optimista, 235-236 afectan, como destructor de la

crisis, hitos miniatura en respuesta a,522 moral,290 33S P
Crunch Mode (Boddie), 419 planificación demasiado optimista y sorgu

cuadernos (storyboards), especificación relaciones entre directivos Y, 236 u3 eic
realimentación de datos medidos, 512 (oN))
mínima y,349
cuarta generación, lenguajes de. Véase recuperación de proyectos y, 409-410 sounE
4GL relación especial con ciertas eP a$
Curtis, Bill,
17, 231,269 prestaciones,353 u?q s(
Cusumano, Michael, 128, 27 6, 292, 294, reutilización Y,576

314, 349, 352, 368, 441, 449, 468, desarrollo externo (outsourcing), 529-542
517 ahorro de tiemPo con, 530-531 -ed sor
bases, 540 -OISJ3¡
bibliografía adicional, 541-542 'uotce¡
Cherlin, M., 317 cambio de prestaciones Y, 530 orqrlrBa
Chow, Tsun S., 85 componentes reutilizables r-. -530 sosoJ J,
et'ectos secundarios de- -i-10 ¿un 'st
especificación de requerimientos- 530 soganb
Davis, Alan M., '71,396 l-leribiiidad del equiPo 1- 530
De Vreese, Jean Pierre, 532, 53't- 5+l eesrion de los nesgos de. 538-540
Debugging the Development Process inter¿cci,¡nes con otros métodos, 540 -;:r ofe
(Maguire), 34,251, 654 pianiticación 1.531 u3 SOrg
Dedene, Guido, 532, 534, 542 resumen- -il9 o31u op
defectos, prevención de, 80 uso. i31-538 -AIIOJ Ü
ou s¡u(
:< --i
d*t¡
:a
o
Cr
670 lrúi@
desarrollo extemo (outsourcing) (cont.) variaciones en los métodos de

claves para el éxito en, 541 desarrollo, l2l-123
comunicación con el vendedor, tipos generales de, 23-26
531-532 desarrollo eficaz, 24-25
consideraciones del contrato, 537-538 desarrollo eftcaz orientado a la mefrr
desarrollo externo en el extranjero, planifrcación, 25
534-s3s desarrollo rápido conjunto, 26
estándares dobles para el trabajo desarrollo, riesgos asociados con el
externo, 533 entorno de,96-97
evaluación del vendedor, 535-536 desarrollo, velocidad de. Véase velociil
gestión de contratos, 53 1 de desarrollo
plan de gestión, incluyendo gestión de Desarrollo Conjunto de Aplicaciones-
riesgos, 53 I Véase JAD (Desarrollo Conjunto &
recursos técnicos, 532 Aplicaciones)
reingeniería de sistemas existentes, Design Objectives and Criteriq (Boeingl
s33 -IIIH
277 'oJp
requerimientos inestable s, 532 despacho, espacio del. Véase entornos -"jg¡{
tipos de acuerdos, 533-534 productivos
desarrollo externo en el extranjero, -ulg
Developing Products in Half the Time
534-535 oieqr
(Smith y Reinertsen), 144
desarrollo rápido total, 26 -Iu¡-
diagnosis de defectos, construcción y l
desarrollo rápido. Véase también velocidad prueba diarias y,440

de desarrollo 8es e
diagnósticos (postmortem) intermedios.
apariencias, 125-121 sorgu
113
definición, 4 ue el(
difuso, inicio, 137 (o\)t
enfoques que contribuyen al, 142-143 ejemplo, 137
equilibrio entre los diferentes enfoques, souni
tiempo perdido durante, 51
t5-16,22-23 aP au
directiva, control insuficiente como effor
formas de alcanzar,4-6 u?q s
clásico, 52
importancia de los clientes para,254- directiva. Véqse también Theory-W,
259 gestión
temas fundamentales, l2l-144 -:d soi
en equipos de alto rendimiento, 3l l-31?
{gr,I3r
inadecuada por falta de cualificación -mt5q
decisiones y compromisos, 138-140 técnica,
en qué se emplea la mayoría del como peligro para la moral, 289 ry@
tiempo, 134-138 úrüf.¡
manipulación por parte de, como
üT
patrón típico de mejora de la
planificación, 140-143
percepción y realidad de la velocidad
destructor de la moral, 2Bg-289
motivaciones de, comparadas con los w
desarrolladores, 27 2-27 3
de desarrollo, 132-134 planifi cación demasiado optimista y
posibilidades de terminar a tiempo, relaciones entre desarrolladores,
-ptrr
t29-132 236
@q
tipo de desarrollo rápido necesario, recuperación de proyectos y, 408 $¡
123-128 responsables técnicos y, 338-340
-GI
trt
SCfl
?k0:
w¡
-¡ltlg
€)
'¿
.J
índice
Dyer, William G., 320

Discipline for Software Engineering' A
(HumphreY),34 Dynamics of Software DeveloPment
(McCarthi- 3a2. 419, 450, 468
diseño para el cambio, 451-460
bases, 459
<efecto sobre el riesgo de la
efectos secundarios, 459
planificación>>' entrada en las tabias
gestión de los riesgos de, 458
interacción con otros métodos, 459
i"ru-"t de métodos recomendabies'
425
resumen, 45 1
eftcacia oPortunista' enfoque de
uso, 452-458
especificación mínima Y' 351
cambio de Planes, 455-456
eficacia por persona, equilibrio de factores'
claves Para el éxito en, 459
140
definición de familias de programas'
456-457 efi ciente, desarrollo, 24-25
diseño orientado a objetos, 45'7-458

dirigido hacia la mejor planificació¡r' 25
rela-ciones con el cliente y,257-258
identificación de áreas propensas a
modificaciones, 453 eficientes, Planes
eiEti
estimaciones simPles, 209 -2ll
ocultación de información, 453-455
planificaciones 1o más cortas posible
diseño por herramientas, modelo de ciclo .1i?q¿
de vida, 165-16'7
y' 2ll -,s
ejecución táciica, equiPo de,325
ventajas e inconvenientes' 171
ejemplos
diseño por planificación, modelo de ciclo " U¡S ¿
gestión efectiva de,369-3'70
de vida, 162-164 "u-biot, sorqu
ventajas e inconvenientes, 171
ciclo de vida, modelos de
u3 eJc
selección eftcaz del modelo de ciclo
diseñ,o. Véase también diseño para el (O]\t ))
de vida, l'72-174
cambio sounE
6 selección ineficaz del, 146-148
bibliografía adicional, 7 5-'7
3P au
equipo de trabajo
.o*o ion""pto básico del desarrollo, uüq s(
equipo de alto rendimiento, 300-301
7l-72
malás dinámicas de grupo' 296-29'7
deficiente y prototipado evolutivo,
4-4',7 5
selección de los miembros del equipo'
4',7 -ed sol
305-306
inadecuado, como error clásico, 52 -OISJAA
equiPo, estructura del
orientado al cliente, 263 'uolop¡
entre los objetivos del
riesgos asociados con, 100 "ot"*pottd"ncia orqtue:
ProYecto Y la estructura del
<Design and Code Inspections to Reduce soJOI Ji
equiPo, 340-341
Errors in Program DeveloPment> ¿u..] 's(
(Fagan), 86 discordancia entre los objetivos dei
del soganb
documentación Proyecto Y la estructura
equiPo. 321-323
orientada a gráficos, 354-355
errores clásicos. 36--13
reutilización Y,575 -¡rc ofe
estimación
Dreger, Bnan' 221 uo sorqi
a ojo- l-8-119
Dunn, Robert H.' 71 o8¡e op
estimación cuidadosa de pror-ectos'
Dunsmore, H. E.. 517 --ll0 -oJJOC U
Dupont, 3I7 - C9-630
I I
ou seuo
es 0u sc
'areatgc
\g\q\la
-t,¡sal
-t:::==t:..,*+i-,1,:=:::.:i:,:::::¡1t-:.:i:!:
=i1:.::i:',:,r::i:t.:i]::1'¡f:i.r-'i;
v t - J !ü
:_ :::-:-¡5 | COnt.) bases, 552-553

-!::Jresia para desarrollo rápido
ciara. 3 1-33 efectos secundarios, 552
clara. ausencia de, l0-12 gestión de riesgos, 549-551
t-alra de conocimientos básicos, 60_63 interacción con otros métodos. 552
gestlón de riesgos resumen, 545
falta de, al contratar, gT-92 uso, 548-549
sistemática, 115-l17 claves para el éxito, 554
herramientas para aumentar la entrega, ciclos cortos de,366
productividad entrega por etapas, modelo de ciclo de
uso eficaz de las herramientas, vida, 161-162, 467, 462, 591, 601
399-400 bases, 600
uso ineficaz de herramienfas. 31 4-31 6 beneficios, 592-594
inicio difuso, 137 bibliografía adicional, 60 1
motivación claves para tener éxito al usar, 601
almuerzo frustrante con el jefe, efectos secundarios de, 598-599
210-211 gestión de riesgos, 598
entorno con fuerte motivación, interacciones con otros métodos, 599-¡,,
29t-293 resumen, 591
planificación, negociación con éxito de rigidez de, 600
la,249-250 uso,594-591
recuperación de proyectos centrado en el desarrollador, 596
recuperación con éxito de un proyecto. dependencias técnicas, 596 iif i
416_419 entregas por temas, 596-59j
'-'r
recuperación fallida de un proyecto, tipos de proyectos, 597 ((Ll\-.,

402_403 ventajas e inconvenientes, l7l
requerimientos, 25 5 -25 6, 266 -267 i,l'-- ;
Elements of Friendly Software Design, The

entregas prematuras, construcción y prue :.
drarias y, 447-448
(Heckel), 342 equilibrio de factores
*a _ :.
Emery, Fred, 310, 3l 1 eficiencia por persona, 140
Emery, Merrelyn, 310, 31 1 entre planificación, coste y producto.
empleados. Véase personal (empleados; 139-140
equipo) calidad, i40
empleo, trabajo como motivación y equipo de trabajo, 295-320
realimentación en el, 280 creación de un equipo de alto
en la sombra, estructura de equipo, 331 rendimiento, 301-312
encapsulación y planificación de la rL-
alto nivel de disfrute, 3l I
reutrlización , 57 4-S'/ 5 características de un equipo de alto
entorno externo, riesgos asociados con el. rendimiento,30l
99
compromiso con el equipo, 30g
entornos de trabajo. Véase también comunicación efectiva, 309
entornos productivos confianza mutua.308
ruidosos. concurridos. 48
configuración de equipos a lar_uo
entornos productir os. 545-554 plazo,3t6-318
O=aLoCc
d *,'É >
=l
LTAdLA
(6 o
indice 673
equipo de trabajo (cont.) modelos de, 328-338

dirección de un equipo de alto equipo en la sombra,33l
rendimiento, 31I-312 equipo SWAT, 333-334
equipo pequeño, 310-3 I 1 equipo de teatro, 335-336
estructura dirigida por resultados, equipo de búsqueda y rescate, 332-333
304-305 equipo atlético profesional, 334-33 5
fallos de los equipos, 312-316 equipo de negocios, 329
interdependencia entre miembros, 309 equipo de prestaciones, 331-332
mezcla de funciones y habilidades, equipo con programador jefe, 329-331
306-301 equipos grandes, 336-338
miembros competentes del equipo, monitorización del rendimiento
30s-301 individual y realimentactón, 326
sentido de identidad del equipo, papeles y detalles claros, 325
303-304 tipos de, 321-325
sentido de autonomía, 309-310 toma de decisiones basada en hechos,
sentido de enriquecimiento, 310 327 -llleJ
trabajo planteado como un estímulo, equipos (equipos de proyecto). Véase .83il1
302-303 también equipo de trabajo .gJs:{
visión u objetivo compartidos, 301-302 diferencias de productividad entre, 17 -ilfg i
diferencia entre grupos y equipos, 298 organizaciónde, 18
ofeqe
ejemplos selección de los miembros, -n:É I
equipo de alto rendimiento, 300-301 Erikson, W. J., 17, 236,269
malas dinámicas de grupo, 296-29'7 Ernst y Young, 69 eas ¿
seiección de los miembros del equipo, error, tasas de. Véqse defectos. tasa de sorqu
305-306 errores clásicos, 13, 35-58 u3 alq
importancia para el desarrollo rápido, concienciación, 56-58 (oN))
298-30 1 ejemplo, 36-43 sounB
resumen de las directrices, 318-3 19 efecto sobre el plan de desarrollo, 43-45 op 3lJ
uso en el software, 297-298 recuperación de proyectos y, 410 usrl s(
equipo de trabajo, identidad del relacionados con el proceso, 50-53
falta de,313 relacionados con el producto, 53-55
sentido de, 303-304 relacionados con la tecnología, 55-56 -ed sor
equipo, estructura del, 321 -3 42 relacionados con las personas, 46-50 .OISJEA
comunicación efectiva y, 326-327 esfuerzo, estimación de, 197-198 'uoIcEl
directivos y responsables técnicos, esfuerzos perdidos, método de orq{uP:
338-340 especificación mínima y evitar. 351 soJoJ x
ejemplos especi fi caciones. V éase requerimientos eu--l "S{:
concordancia entre los objetivos del (análisis o especificaciones de S.og:::0
proyecto y la estructura del requerimientos)
equipo, 340-34I especificaciones minimas. 34ó-355
discordancia entre los obietivos del beneficios de. -l-i0-35 i -+J¡ ü:a
proyecto y la estructura del clar-es para el erito- 354-355 E rmq
equipo. 32I-323 falta de soporte para actividades ú-¡" q
mejor para desarrollo rápido, 327-328 paraleias ¡-- 353
-f.&r
oa ñtF
¡$@s
ra.!,q¡o
wsg
q
6il1 i¡tie
espedficaciones mínim as (c ont.) factores de confianza y,197

razón errónea para usar, 353-354 herramientas software para, 194
riesgos de,351-354 historia de, l'79-187, 240
espiral, modelo de ciclo de I53-155, más o menos, estilo, 195
s89 método de negociación conveniente y,
ventajas e inconvenientes de, 247-249
estadísticas, conftanza excesiva 513 omisión de tareas necesarias como error
estado, informe de, 512-513 clásico, 53
estado, visibilidad del omisión de tareas comunes y, 194
compromiso (signing-up) y, 585-586 planificación basada en compromiso y,
hitos miniatura y, 520 200
medidas y,504 planificación, 198-200
prototipado de la interfaz de usuario y, por categorías, 193
637 por reuniones (walk-through), 193
estatus, productividad perdida por mejoras probabilidad de pérdidas, 103-104
en la oficina orientadas aL,549-551 proyectos previos como base para, 193 -TI¡€J
estimación de la planificación, 198-201 puntos de función, 189-191 'o3¡1e
estimación, gráfico de convergencia de, 182 .t-¡eld
rangos parc, 195
estimacione s, l'77 -221 recalibración de planes, 216-217 -urg:
a bajo nivel de detalle, 193-194 refinamiento , 214-217 oluqer
basada en casos, 196-197 relleno (padding), 199 -n.t61:
basada en el desarrollador, 193 reserva de tiempo para planificar,l92-
bibliografia adicional sobre, 220-221 t93 uas e:
cambio de métodos de, 195 simples de planifi ca ción, 20 I -21 4 sorqul
como concepto básico de desarrollo, 64 planificaciones lo más cortas posible, ua olqt
como proceso de refinamiento gradual, 204-209 (oN).
179-184 planifi caciones efi ciente s, 209 -21 I sount¡
consejos para, 191-195 planificaciones nominal es, 2l l -21 4 ep 3UE
control frente a, 184-185 primer paso a dar,2l4 u¿q so
convergencia entre realidad y, 186 tablas de, 202-214
cooperación y, 185 tamaño, 189-197
cuantificación de riesgos y, 195-196 definición del tamaño, 190 -ad solr
de improviso,l9I-192 estimación de puntos de función, -oIsJe^
descripción general del proceso de, 188 189-191 'uotcell
ejemplo de construcción, 180-181 uso de varias técnicas distintas para,194 orq(usJ
ejemplos volumen de pérdidas, 103 socoJ J3
estimación a o1o, 178-179 estrategia para el desarrollo rápido eun'so
estimación cuidadosa de proyectos, alternativa [método basado en obligación soganb:
217 -220 o codificar a destajo (code-like-
entrega por etapas y,594 hell)],28-30
errores de reestimación, 53 ejemplos -¡-rc olec
esfuerzo, 197-198 ausencia de una c|ara, 10-12 u3 sorql
estilos de presentación para, 195-197 clara, 3I-33 oEIB opr
exactitud fiente a precisión y,187 en general, l2-15 -oJJO3 Ul
ou sauot
as ou so
'a.re.ttgo
\q\\\\t(
-r¡sal
Ét)
indice 675
estrés, errores software Y,234 filtrado (supresión) de prestaciones,

evitar riesgos, 107. Véase también riesgos, 355-356, 565
gestión de firmwarc,27
evolutiva, entrega, 164-165, 461-468 Fisher, Roger, 251,606
bibliografía adicional, 468 formación en el uso de herramientas de
efectos secundarios, 466-467 productividad, 386
gestión de riesgos de,465-466 Fox, Christopher J., 575,576
interacción con otros métodos, 467 Frakes, William 8., 57 5, 5"1 6
resumen, 461 Freedman, Daniel P., 86
uso, 463-465 Freeman, Peter, 580
claves para el éxito,467."468 fricción
cuándo ut1lizat,465 entre desarrolladores y clientes, 48
orden de las entregas, 464-465 relaciones con los clientes y,258-259
ventajas e inconvenientes, 171 funciones claras, estructura de los equipos
exactitud y,325
frente a precisión, 187 Function Point Analysis (Dreget), 22I
-ur3 il
y medida de los datos, 513 fundamentos técnicos, 68-75 .Of,{E¡I
construcción, 72-7 4 '"JTdt
expectativas
irreales, 48 diseño,l1-72
-tl!JJ
de clientes, 133-134 gestión de la configuración del soflware
oleq:l r
después de una sesión IAD,497 (scM),74-75
-nd l+
sobre planificación Y PresuPuesto, gestión de requerimientos, 70-71
prototipos desechables Y, 618 eas
sobre planificación y presupuesto' "¡F
sorqrrrEl
prototiPado evolutivo Y, 41 l-472 Gaffney, 1.,203
ua elqrs
sobre rendimiento, PrototiPado Gates, Bill,226,3l4 (oN) tr:
evolutivo Y,473-474 Gause, Donald C..75
sounS¡y
medidas y,504 gestión, definición del software de,27
ap egBd
Exploring Requirements (Gause Y gestión, fundamentos de la, 67-68
u?q sor(
Weinberg), 75 bibliografia adicional, 67-68
estimación y Planificac ión, 64
medidas, 66
-ad sorqr
Fagan, M. E., 52,86, 135,23I planificación, 64-65
-oISJ3^ 3
fallar al construir (build), penalización por, seguimiento, 65-66
'ugrcu¡uc
444-445 gestión, riesgos de, 96
orqurBc r
Faller, Benoit, 570, 5'7 4 Getting to Yes (Fisher y Ury), 241,251
sosol Je^
familias de programas/productos, 456- Gibbs, W. Wayt, xvii, 19, 344,370
uu¡'sod
457 Gilb, Tom, 54, 67 ,80, 84, 86, 90, 1 18,
soganba<
Federal Aviation Administration (FAA), 221, Z5l, 464, 466, 468, 528, 601
software para estación de control de Glass, Robert L., xxii, 85, 90, 225,234,
tráfico aéreo,344 235, 380, 398,400, 453
-¡rc oleqr
Fenton, Norman, 512 Gordon, V. Scott, 467, 471, 472, 474, 475,
uo sorqul
filosofia, métodos recomendables Y, 478, 479, 617, 643
oE¡e opu
42',7-428 Grady, Robert 8., 516
-aJJO3 Ug,
ou souori
os ou sor
'ateltgos
tqrrst\a{
-t¡s3p
itfu
Graham- Dorothy, 84, 86
hitos
grmdes equipos de trabajo, 336_339
miniatura (véase hitos miniatura)
gftu€ro- construcción de. Véase Amish,
principales, 522
equipo para levantar granero hitos miniatura, 417-413, 5lg_528
Grant, E. 8., 17, 236, 269
bases, 527
granularidad de los datos, 508
bibliografía adicional sobre, 52g
Gray, T. E., 17,236,299
control de grano fino y,527
Griss, 572, 574
efectos secundarios, 525-526
Grove, Andrew S., 68, 296
gestión de riesgos de,525
grupo de medidas, 505-506
interacciones con otros métodos,
grupos, distinción entre equipos y,29g
526_s27
Grupos Internacionales de Usuarios
listas genéricas de tareas frente a,525
sobre Puntos de Función (IFPUG), lg9
motivación y,521
resumen de, 519
riesgo de planificación y, 521
habilidades, trabajo como motivación y -ur"3
uso,521-525 3p
variedad de,279 'a3ilerf,
<<hecho> y <<no hecho) como únicos
Hackman, J. Richard, 279,294 '_s{r¡dr¡
estados, 523
Hall, Tracy, 512 -arg:nl
claves para el éxito en, 527_52g
Hamilton, Scott, l9 conjunto exhaustivo de hitos, 524 oieqzrr
Handbook of Walkthroughs, Inspections -n:É
control del progreso y recalibración o ¡ap
and Technical Reviews (Freedman y
replanifi cac ión, 524_525
Gerald), 86 inicial o en respuesta a una crisis, uas ¿3p
Hatley, Derek J., 75 sorqI'IIea
522
Hawthorne, efecto, 286 ua slqrs
limitación del tamaño, 523
Hawthorne, trabajos de la Western Electric (oN)
minihitos propios de los Jr
Company,285 soun31¡
desarrolladorcs, 522_523
hazañas,47 op ail?d
para planificación a corto plazo,524
Heckel, Paul,342
visibilidad del estado y. 520 u?r{ sor(
Henry, S. M., 5j0, Sj4
horas extras
Herbsleb, James, 578
libres, como parece sugerir el desarrollo
herramientas, grupo de, 63 I -ed sorqr
rápido, 127
adquisición de herramientas para
voluntarias (véase horas extras -OISJ3^ €
incrementar la productividad y,
voluntarias) 'ugrculul
3 83-3 85
horas extras voluntarias, 645-654 orqu¿3 1
resumen de, 63 I
bases, 653-654 soJol Ja¡
Herzberg, Frederick, 274, 2g7, 2g4
bibliografía adicional, 654 eu¡'sod
Hetzel, Bill, 60, 64,65, g5, 3g0
efectos secundarios de, 652 soganbar
H-igh Output Management (Grove), 6g
gestión de riesgos, 652
Highsmith, Jim,3l0
interacciones con otros métodos. 653
higiene, factores de
resumen, 645 -¡rc oleqr
entornos de productividad y, 547 _54g uso,646-651 ue sorqul
moral y, 287-288
cantidad a solicitar, 650 o8¡e opu
motivación y,287-2gg
claves para tener éxtto- 654 -aJJO3 U3
ou seuor:
es ou sor
'eleatgos
\q\a\\a(
-t¡s?}
o
rÉ-
ta :.:a){) ^
c¡ í 5oE
horas extras voluntarias, {cont')
información
iniciativa del desarrollador y del estructura del equiPo Y,326-327
resPonsable, enfoques, 646-64'7 sobre riesgos, 108
las horas extras no deben ser ingeniería del software, bibliografía
obligatorias , 641 -649 adicional sobre, 88
precauciones con el exceso de horas iniciales, escatimar en actividades' 51-52
extras, 650-651 Insíde RAD (Ketr Y Hunter), 283,345
proyectos fuera de control, 649-650 inspecciones, 83-84
HumphreY, Watts S., 34, 5I,230, 54I
integración del código
Huntér, Richard, 283,345-346, 582
construcción y prueba diarias y,440
Hutchens, David H., 84
entrega Por etapas Y,594
<interaóciones y equilibrios principales>>,
entrada en las tablas resumen de
Iansiti, Marco, 128, 225, 251
métodos recomendables, 426
rB}y'r,',79,81, 189 -ixef, 3p lGf
interdependencia entre miembros del
Santa Teresa, oficina de recursos, 549, "03Feilojnl
equipo, 309
553 '_err:d::e :t
interés, grupos de,262
<IBM's Santa Teresa LaboratorY- -ury:nb so
Architectural Design for Program investigáción, desarrollo orientado a la,
54-55 oleqer rm ,
DeveloPment> (McCue), 554 -n€

irreales, exPectativas, 48 ¡ap olt
identidad de las tareas, trabajo como
de los clientes, 133-134
motivación Y,279 €apl
después de una sesión JAD,497 33S e
IEEE Software (tevista), 517, 580
sobre planificación y presupuesto solqures 3[
ilusiones, 49-50 ua a¡qrsod
prototiPos desechables Y, 618
planificaciones Y, 239-240 (oN)
prototiPado evolutivo Y, 47 l-472 JrJ3I
<<Impacts of Life CYcle Models on sounSly's
Software Configuration Management>> ,otr" t.ttdi*iento, prototipado evolutivo
y,473-474 ep euBd'l
(Bersoff Y Davis), 77 uer{ sorqu
implementación, riesgos asociados con la,
100
importancia de 1as tareas, trabajo como JAD (Desarrollo Conjunto de
Aplicacione s), 262,349, 485-500 -ed sorque
motivación Y,279-280 -orsJsA 3p
ahorro obtenido con, 486-487
In Search Of Excellence (Peters Y
'ugrceluarn
Waterman), 268, 284, 294, 342 bases, 499
bibliografía adicional, 500 orq{us3 eE
inactividad, formación de equipos de so30l Ja-\[o
trabajo a largo Plazo Y,3i7-318 efectos secundarios, 498
especificación de requerimientos y, 486' eu¡'sodru
incentivos, motivación Y, 283 -285
499 sogenbad .
incorporado, software, 27
gestión de riesgos, 49'7-498
incremental, prácticas de desarrollo,
165
interacciones con otros métodos' -198+99
uso,48l-497 -¡:c olequr
ineficaces. métodos de desarrollo' 5'
claves Para el éxito' 499-500 uo sorqtIls
Yéase también errores clásicos
ineficaces. métodos orientados a la fase de diseño, 487-488' -19{-+9- o31e opuet
fase de Planificación''13-J9¿ -a.L¡o3 lr,e¡€
planificación- 26
ou sauorJt
es ou sorJt
'ereargos ¡
I se.\q\ta((
L- -tesaP I
_ __JN¡
E asd€ F
=
678 i-c c€
-.-
---':-5trn. Donla L., 5 12 lenguajes de desarrollo rápido (LDR),
-::;r; ,4pplication Design (August), 500 s55-564
-,Í,,,,;nr ,lpplication Development (Wood y bases, 563
Silver), 500 claves para el éxito en, 563-564
Jones. Capers, xvii, xxii, 16,48,52,54, efectos secundarios de, 562
55, 66,75,79-92,90, 1 lg, 136,175, ejemplos, 556
177, lgg, lg4, 200, 209, 221, 225, gestión de riesgos en,560-562
230, 234, 236, 247, 265, 279, 321, interacciones con otros métodos,
330, 334, 343, 351, 364, 366, 310, 562-563
393, 395, 390, 393, 395, 400, 459, uso, 559-560
477, 4gg, 505, 5 13, 517, 546, 553, lenguajes. Véase 3GL (lenguajes de tercera
564, 512, 57 5, 579, 643, 649, 653, 654 generación); 4GL (lenguajes de cuarta
Jones, método de estimación de primer generación); lenguajes de desarrollo
orden, 191,200-201 rápido (LDR)
Joos, Rebeca,572 líneas de código, medidas de, 514-515
JRP (Planificación Conjunta de lista de los 10 riesgos principales, I 1 l-l 13,
Requerimientos), 488 OJJ
Lister, Timothy, l7 , 33 , 48, 236, 251 , 269,
293, 2gg, 3 I 1, 3 13, 317 , 320, 360,
Karten, Naomi, 267 546, 552,554, 595, 650, 654
Katzenbach, Jon, 297, 320 Lyons, Michael L.,274
Kemerer, Chris, 203, 204
Kerr, James, 283,345, 582, 584
Kidder, Tracy, 29,582,585, 586, 588 madurez de las herramientas de
Kitson, David H., 66,70,'74,79 productividad, 386
Klein, Gary,396 Maguire, Steve, 34, 77, 251, 291, 585,
Klepper, Robert, 390 650,654
Kohen, Eliyezer, Tl Manager's Guide to Software Engineering,
Korson, Timothy, 453 I (Pressman), 67,85
Krantz, Les, xxii Managing a Programming Project
(Metzger), 64,68
Managing Expectations (Karten), 267
LaFasto, Frank M. !., 4'1 ,2j7,30I,308, Managing Software Maniacs (Whitaker),
312, 3 1 5, 3 I g, 320, 324, 325, 341 268
Lakhanpal, 8., 46, 299,31i- Managing the Sortware Process
lanzarse a la codificación como error (Humphrey), 541
clásico,51-52 manipulación por la directiva como
Laran-jeira, Luiz, 214 destructor de la moral, 288-289
lar-eo plazo. desarrollo rápido a, 236 mantenimiento, prototipado evolutivo y
Larson. Carl E.. 47 , 277 ,301, 308, 312, pocas facilidades de, 475-4i6
3i5. 318. 320. 324, 325, 341 manual de usuario, como especificación,
LDR. I'éase lenguajes de desarrollo 348-349
rápido Marciniak, John J., 531, 541
Lederer, Alberr L.. rlir. 193.343 Marcotty, Michael, J7
índice 679
márgenes y retraso del proyecto, l0! ^ -

Methodfor Assessing the Software
Engineering CaPabilitY of
Mariin, James, 143, 3l'7, 333, 342, 396'
Contractors, ,4 (HumPhreY Y Sweet)'
488-492,499, 500, 630
54r
Masters, StePhen, 66,'7 0, 1 4, 79 -
meticulosidad
Mayo, Elton, 285 y'
desarrollo con ventanas temporales
MBTI (Indicador de TiPo de MYers-
628
Briggs), Prueba,273
enfoque de esPecificación mínima Y'
Mccartt!,.Jim, 140, 262, 332, 342, 366, 352
368, 4lg, 441, 450, 468, 520
'76, 85,3'70, 450, 460' métodos recomendables para el desarrollo
McConnell, Steve,
rápido, 422-436
468,563,564
Vianse tambíén los métodos específicos
McCue, Gerald M., 554
capítulos de este libro sobre, 422
McDermott, Tim, 5'70, 51 4
organización de, 424-42'7
McGarrY, Frank, 17 , 269 , 299 , 390 ' 505 '
secciones en,426-42'l
512,570,5'74 para'
razones para excluir candidatos
Measures for Excellence (Putnam Y
427 -429
MYers), 221
resumen de los candidatos a métodos
medidas,503-517
recomendables, 42'7 -43 4
bases,515-516
resumen de las evaluaciones de' 434-436
beneficios de su uso, 504-505
tablas resumen sobre
bibliografía adicional, 516'511
<efecto sobre e1 riesgo de 1a
como base del desarrollo, 66 425
Planificación>>, entrada,
efectos secundarios de, 515
ejemPlo de tabia, 422-423
expectativas Y,504
<<interacciones Y equilibrios
gestión de los riesgos de, 513-515 . - 426
PrinciPales>, entrada,
interacciones con otros métodos' 515
u*"jotu en la visibilidad del
uso,505-513 425
Progreso))' enttada,
análisis frente a medida, 51 1-512
upotiUltiAuA de éxito inicial>, entrada'
análisis Pareto, 510
425-426
claves Para el éxito, 516
<posibilidad de éxito alatgo plazo>>'
exactitud de los datos, 513
entrada,426
granularidad, 508-510
<reducción Potencial de la
gruPo de medidas, 505-506 entrada'
informe de línea de base, 512 Planifi cación nominal>>'
424-425
limitaciones, 5 l3
<riesgos principales> , enftada, 426- -
objetivos, Preguntas, métricas' 505
Metzger,-Philip W., 64,68,240, 585' 650
qué medir' 506-510
qué hacer con los datos recopilados'
Microsoft
ejemPlo: motivación de los
5 10-513
áesarrolladores en, 29 1 -293
realimentación de los datos medidos'
recorte de prestaciones al final de-
512
<mejora en la visibilidad del progreso)' ProYecto, 368
<Micrósoft Corporation: Otfice 3 -.' ' " '
Unit> (Iansiti)- 251
]UILE
,l/---¡r5,,1¡i Secrets (Cusumano y Selby), excesiva presión de agenda, 289

:9+. +-+9, 468 factores de higiene, 287-288
\[i'-rosoft Visual C++, 262-263 falta de apreciación para los
\fic¡osoft Windows, desarrollo del árbol desarrolladores, 289
NDS 3.0, 4lg, 443, 584_596 manipulación de la directiva, 288-289
\'licrosoft Word for Windows 1.0 no involucrar a los desarrolladores,
métodos de planificación optimista y, 290
1'J < a'\1I
Z'J-LL participación de directivos sin
Miliington, Don, 254, 354 preparación técnica, 289
Mills, Harlan D., 17, 269, 329, 330, 585, ejemplos
6s0 almuerzo frustrante con el jefe,
Modern Structured Analysis (Yourdon), 75 270-211
<Modular Structure of Complex Systems, entorno altamente motivador, 291-293
The> (Parnas, Clements y Weiss), 460 el trabajo en sí como, 279-281
modularidad, 71 enfoque de especificación mínima y,
módulos propensos a errores, 8l 350-35 1
MOI, modelo,3l2 hitos miniatura y, 521

Moore, Dave,291 método basado en compromiso y,28-29
moral oportunidad de supervisión técnica
construcción y prueba diarias y,44I como, 282-283
definiciót, 27 5 planificación demasiado optimista y, 235
desarrollo externo y, 539 posibilidad de crecimiento como,
enfoque de especificación mínima y, 278-219
350-35 I proyectos piloto y, 285-286
factores que disminuyen, 287 -29 1 recompensas e incentivos como,
medidas y,504 283-285
recuperación de proyecto s y, 407 , 409 revisiones de rendimiento y,286
moral, <presupuesto> en Microsoft subyacentes, como error clásico, 46
(ejemplo),292 vida personal como, 281-282
More Pro gramming Pearls (Bentley), 7 7 motivación (factores de motivación),
motivación(es), l8 269-294
alc,anzar metas como, 278-280 Myers, Glenford, 83, 84, 85
bibliografía adicional, 293 -294 Myers, Ware, 19, 198, 209, 558
campañas duras para mejorar como Myers-Briggs, prueba de Indicador de Tipo
enemigo de la,291 de (MBTI), 273
de los desarrolladorcs, 271-214 Mythical Man-Month, The (Brooks), 329,
definición, 275 342,400,454
desarrollo con ventanas temporales y,
628
destructores de la moral, 287-291 Naisbitt, Iohn, 279, 549
baja calidad,291 NASA,5I6
barreras de la productividad, 290 Laboratorio de Ingeniería del Software,
campañas carsantes de motivación, g3,2gg,390,457,505, 5l 1, 513,
291 570,514
681
negociación (habilidad negociadora) planificación de la reutilización y,

conveniente (v éas e negociación s'7 4-515
conveniente, método de) oficinas ruidosas Y concurridas, 48
estimaciones Y,240 Oldham, Greg R., 2'79,294
separación de las Personas Y el Olsen, Neil, 22
problema, 242-243 <On the Criteria to Be Used in
tirones. 54 Decomposing Systems into Modules>
(Parnas), 460
negociación conveniente, método de,
24r-249,543 <One More Time: How Do You
centrarse en los intereses, no en las Motivate EmPloYees?> (Herzberg),
posiciones, 243-244 294
grados de libertad en la planificación de optimista, planificación excesivamente,
un proyecto software Y,244-246 como error clásico, 50
insistir en usar criterios objetivos, optimista, planificación. Véase
241-249 planifi cación (Programación),
inventar opciones para el beneficio excesivamente oPtimista
mutuo, 244-246 orgamzación de equiPos, 18
separar las personas del Problema, orientada a objetos, Programación,
242-243 39'7-398
negocios, estructura de equiPo, 329 orientado a objetos, diseño
<No Silver Bullets-Essence and Accidents diseño para ei cambio Y, 457-458
of Software Engineering> (Brooks), ocultación de información y, 453-455
316 planificación de reutilización y, 57 4
O'Brien, Larry, 388, 400 Page-Jones, Meilir, 76

O'Grady, Frank, 318 panaceas (síndrome de 1a panacea), 55,
Object Oriented Analysis and Design 393-399,560
(Booch), 76 desmitifi cación, 398-399
Object-Oriented Design (Coad Y identifi cación, 395-398
Yourdon), 76 Papaccio, 52, I 1, 80, 231, 361
Obj ect- Oriented Rapid Prototyping Pareto, análisis, 510
(Connell Y Shafer), 479 Parnas, David L., 453, 456, 458, 460
objetivos participación de los implicados, falta de,
definición, 481-482 49
medidas y. 505 Peat Marwick, 90
motivación por realización -v. 27 6-27 8 penalización por fallar al construir (builQ'
poco claros o imPosibles 444-445
cambios a mitad del ProYecto -v. Peopleware (DeMarco y Lister), 33, 251'
3s8-360 293,554,654
enfoque de esPecificación mínima Y, percepción de la velocidad de desarrollo'
lSl-ii1 132-134
ocultación de intbrmación. 71 superar la percepción de un des¡-'-' --'
diseño para el cambio Y.453-455 lento,134
T*
bióz ': 3a
:,-::::: ,ie cOntrOl planificación (programación; planes),

:.r::,:rLrmiso (signing uP) Y,586 223-25r
:;sarrollo externo y, 539-540 basada en compromiso, 200
P:ri1 . Dewayne E.,514 bibliografía adicional, 25 1
personal (empleados; plantilla). Véas e como base del desarrollo, 64

t ambién personas Qteopleware, temas compromiso entre producto, coste Y,
sobre) 139-140
configuración de equipos a largo plazo desarrollo con ventanas temporales y,
y,316-317 626
débil, 46 ejemplo: negociación con éxito de la
desarrollo externo y flexibilidad de 1a planificación, 249 -250
plantilla, 530 excesivamente oPtimista, 224-239
medidas mal utilizadas para la agotamiento y,236
evaluación de, 514 apego al plany,230
problemas, 46-47 apuestas y,235
fallo de los equipos y,314-316 calidad y, 234-235
recuperación de proyectos Y, 408 calidad de la planificación Cel
riesgos asociados con, 99-100 proyecto y,229-230
personas (peopleware, temas sobre). Véase causas fundamentales de, 22'7-228
también personal (emPleados; convergencia prematura, 232-234
plantilla) creatividad y, 235-236
como dimensión de la velocidad de desarrollo rápido a largo plazo y,236
desarrollo, 1 5, 1 6- 1 8 dispersión de actividades, 23 I
errores clásicos relacionados con, 46-50 efectos de,228-234
recrrperacrón de proyectos y, 4O'7 -4\0 elemp\o de,225-221
Peters, Chris, 2'7 6, 349, 448, 511 exactitud de las planificaciones y,
Peters, Tomas J., 268, 2'78, 284, 286, 293, 228-229
294,342 motivación y,235
Pfleeger, Shari Lawrence, 477, 574-5'77 puntos cruciales, 237 -239
Pietrasanta, Alfred M., 19, 512 reducción del alcance del proyecto y,
Pirbhai, Imfiaz A.,'7 5 23t
planificación (planes), 524 relaciones entre desarrollador y
abandono bajo presión, como error responsable, 236
clásico, 5 1 relaciones con el cliente y,23I-232
cambio, 455-456 excesivamente optimista. como error
como base del desarrollo,64-65 clásico, 50
desarrollo externo y, 53 I método de negociación conveniente y,
gestión de riesgos, 93,107 241-249
insuficiente, como error clásico, 5l probabilidad de cumplir, 129-132
orientada al cliente, 259-260 rotura de la presión de planificación,
planifi cación excesivamente optimista y 239-249
apego a. 230 negociación conr,eniente, 241 -249
planr fi cacrón crcesivamente optimista y planificación. compresión de la,
calidad de. ll9-230 208-209
índice 683
precisión frente a exactitud, 187

planif,rcación, hitos miniatura y riesgos de,
52r predecibilidad, como asPecto del
desarrollo ráPido, 125-126
planificación, métodos orientados a riesgos
premios
de. Véasebases del desarrollo de
software ejemplo: en Microsoft, 291-293
planificación, métodos orientados ala, 5, motivación Y, 283-285
presentación de estimaciones, estilos de,
13, 14. Véanse también velocidad de
desarrollo; visibilidad, métodos
t95-r97
Pressman, Roger S., 67, 85, 88
orientados a la
prestaciones (conjunto de prestaciones)'
centrarse demasiado en un único, 9
343-3',71
centrarse sólo en, 14
tipos de, 6-7
bibliografía adicional, 3'7 0 -37 1
cambi,o (cambio de requerimientos), 54'
planificación, Presión de
136,343 lvéase también
construcción y prueba diarias, incluso
requerimientos (esPecificación o
bajo,446
análisis de requerimientos)]
excesiva, como enemiga de la moral,
desarrollo en ventanas temporales y'
289
628
reducción, 239-249
desarrollo externo Y, 530-531
planificación, recalibración de la, 216-2Il
desarrollo Por versiones, 356
planifi cación conjunta de requerimientos'
entrega Por etaPas Y, 598
Véase jRP (planificación conjunta de
requerimientos)
filtrado (suPresión comPleta) de
1o más cortas posible,
prestaciones, 355-356
planificaciones
prototiPado evolutivo Y, 476
204-209
prototipado de la interfaz de usuario y'
planificaciones eficientes Y, 209
637
planifi caciones nominal es' 2l I -21 4
reducción del conjunto de
planteamiento de visión, y especificación
prestaciones, 345-356
mínima,348
tipos de controles, 345
plantilla. Véase personal (empleados;
plantilla) cambios a mitad del proyecto, 356-368
. 1., 33, '7 5-7 6 causas de cambios, 357
Plauger, P
detención de todos los cambios,
política antes que desarrollo, 49
362-364
<<posibilidad de éxito a largo plazo>>,
efectos de los cambios,36l-362
métodos de control de cambios,
364-368
<posibilidad de éxito inicial>, entrada en
las tablas resumen de métodos objetivos poco claros o imposibles'
3sB-360
recomendables, 425 -426 :=:sii-:"'
síndrome de 1a ,<aplicl;l'in
Practical Guide to Structured Systems
357-358
Design. The (Page-Jones), 76
desarroll.' c:- ' 3:-:::-;: :erncr:':s "'
Practical So.l'ntare tr[etrícs for Proiect
Managentent attd Process
6l-
Improt'entetrr r Grad,v). 5 16
:'e::.:.1 --rs:--':-
:ñciir¡ de ;":::-'
Prasad. Javesl-1. r" r:. 193' 343
6,e4
I r.i-iJ rtrrlSS (C Ont.) papel esencial de las herramientas para

r3Jr'rf€ de prestaciones al final del productividad, 380-38 1
proyecto, 368 uso de, 388-393

recuperación de proyectos y, 473-416 cuándo ponerlas en marcha, 388-389
prestaciones, estructura del equipo de, formación, 389-390
331-332 reducción de la planificación que cabe
presupuesto, prototipado evolutivo y esperar, 390-393
expectativas no realistas sobre, producto, característic as del, 22
471-472 producto, tamaño del, 22
primer orden, método de estimación de producto. Véase también prestaciones
Jones, 200-201 (prestaciones, conjunto de)
Principles of Software Engineering como dimensión de la velocidad de
Managemenl (Gilb), 6J, 80, ll8, 221, desarrollo, 15, 21
251, 464, 466, 468, 528, 601 compromisos entre planificación, coste
priorización de riesgos, 93, 104-10'7 y,739-140
proceso riesgos asociados con, 98-99
abusar de centrarse en, 19 productos, familias de, 456-457
como dimensión de la velocidad de productividad
desarrollo, 15, 1B-21 barreras,290
errores clásicos relacionados con, 50-53 fallo de los equipos y, 313
recuperación de proyectos y, 410-413 compromisos en eficiencia por persona
riesgos asociados con, 100-101 y,140
productividad, herramientas para equipo
incrementar la, 3'7 3 -400 estrategia de equipo permanente, 316
adquisición de, 382-3 B8 variaciones en,299
criterios para selección de effores clásicos y (véase errores
heramientas, 385-3BB clásicos)
persona o grupo herramientas, 383- factores que afectan a,43-45
384 medidas de líneas de código y,574
riesgos de configurar un grupo de motivación y, 46
herramientas, 3 84-3 85 temas sobre personas y,16, 17
bibliografía adicional, 400 variaciones en la, 18
definición, 374 entre grupos (equipos), l7
ejemplos entre personas, 16-17
uso eficaz de herramientas, 399-400 programador jefe, estructura de equipo,
uso ineficaz de herramientas, 3'/4-376 329-331
madurez de, 386 programas, familias de, 456-451
panacea, síndrome de la lvéase panaceas Programming on Purpose (Plauger), 75
(síndrome de la panacea)l Programming on Purpose II (Plauger),33
estrategia para usar, 381-382 Programming Pearls (Bentley), 77
papel en e1 desarrollo rápido, 376-381 <Project Pathology: A Study ofProject
áreas de especial aplicación, 318-379 Failures> (Thomsett), 420
limitaciones de las herramientas para promotor de proyectos efectivo, falta de
productividad. 379-380 un. 49
índice 685
propiedad, motivación por realización y, interacción con otros métodos,477

276 prototipado de interfaces de usuario y,
prototipado de demostración, 637 638
prototipado de la interfaz de usuario, 349, resumetr de.469474
635-644 uso,47G-*71 -
bases, 643 claves para el érito en, 478-479
efectos secundarios, 642-643 vendas e inconvenientes, 170
gestión de riesgos, 642 protonipedo rápido, uso del termino. 470
interacciones con otros métodos, 643 prototipado- t-unse tu¡bién prototipado
resumen, 635 er-olrrir-o, modelo de ciclo de vida;
uso,637-641 ¿esectebtes; prototipado de
claves para el éxito en,644 la imerÉz de usu¡rio
producto terminado, 641 .lFroch¡tltfq #9, 615 420
prototipado evolutivo o desechable, prüdipodo & l¡ imrrñz de usuario y,
638 63t
prototipos como decorados de pro¡dip.e er-oluir o y, 177 17 I
película, 639-640 fuj¡rc$ imo¡¡docr r¡so del desarrollo
realimentación e implicación del rá¡*b pre erim" l5
usuario final,640-641 pro b rct4lcr¡ciah &.- ú'ease
selección de un lenguaje de rcsper¡fin de poyectos
prototipado, 638-639 fo!¡€ffi rctns¡dm. incorporación de
prototipado evolutivo, modelo de ciclo & ¡nil..nümn cn" 4T
vida, 159-160,469-479 fücb.
bases, 478 hi*it,gr.ft ¡dictunal 85-86
bibliografía adicional, 47 9 m k &l deserrollo, 82
efectos secundarios, 477 Fue ntr¡nirrn (snúe test). Yéase
entrega evolutiva y, 461, 462. 46Á7 crñEiiin y gueba diarias
gestión de riesgos, 471-476 Wt of Computer Programming,
bajo rendimiento del producto,473 I¡e (Teinb€rg),293
cambio de prestaciones, 476 po de parrid4 especificación, 348
difi cultades para el mantenimi€rürr, f6 de fimción, estimación, 189-191
47 5-476 bibliografia adicional, 221
disminución del control del polwo- @c de función, multiplicadores,
4't2-473 190-r9l
expectativas poco realistas de n¡tnan, Lawrence H., 19, 198,209,221,
rendimiento, 473474 558
expectativas poco realistas de
presupuesto y planiñcacicn-
4',71-472 fualitySofnuare Managemenr (Weinberg),
mal diseño, 474-475 61,237, 420, 654
. mala realimentación con el us¡rio
final o cliente,473
uso ineficiente del tiempo de RAD (Desanollo Rápido de Aplicaciones),
protolipado,4T6 396-397
---;:" ; .t : g i i c a ti o n D ev el op menr (Martin), refuerzo de los miembros del equipo, 310
,-1_1. i+2. 396, 500 Reifer, Donald 1., 531,541
R-¿¡rd Protoryping: Lessons Leamed>
Reinertsen, D. G., 144
rGordon y Bieman), 479 ReinvenÍing the Corporalion (Naisbitt y
R.a¡theon, 19,26
Aburdene), 279
realimentación
relleno (margen) de estimaciones. 199_200
de los datos medidos, 512
rendimiento
del usuario final o cliente, prototipado
del producto y prototipado evolutivo.
evolutivo y,473
473
estructura del equipo y,326
estructura del equipo y monitorización
<Realities of Off-Shore Reengineering>
deI,326
(Dedene y De Vreese), 542
rendímiento, motivación y revisiones del.
realízación, motivación por, 27 5
286
recalibración de planificaciones, 216_217
requerimientos (análisis o especificación
reconocimie nto. Véas e apreciación
de requerimientos), 70_7 1, 136_137
(reconocimiento)
bibliografía adicional sobre, 75
recuperación de proyectos, 401_420. Véase
cambio (cambio de prestaciones)
tambíén prestaciones (conjunto de fvéase
prestaciones (conjunto de
prestaciones), recorte de prestaciones
prestaciones), cambio (cambio de
al final del proyecto y cambios a mitad
requerimientos)]
del proyecto
desarrollo externo y, 530, 532
características de proyectos con
detallado, 346-348
problemas, 401-402
ejemplos, 255-256, 266-26j
ejemplos
especificación mínima, 34g_355
recuperación con éxito de un proyecto,
beneficios, 350-35 1
416_419
claves para el éxito al usar, 354_355
recuperación fallida de un proyecto,
falta de soporte para actividades
402_403
paralelas,353
filosofia del enfoque de este libro para,
motivos erróneos para el uso de,
404_40s
353-354
métodos básicos para, 404
objetivos poco claros o imposibles,
plan para, 405-416
35 r _352
cuestiones relativas al personal,
omisión de requerimientos clave, 351
407_410
riesgos de,35l-354
primeros pasos, 406-407
filtrado (eliminación completa),
proceso, 410-413
355_356, 565
producto, 413-416
JAD y, 486,499
temporizaci ón, 416
meticulosidad, 54
recursos humanos, codificar a destajo
orientado al cliente, 260_263,364
tcode-[ike-hell) y,29
recuperación de proyecto s y, 413_416
recursos. orientación de los, 20
riesgos asociados con, 9g
',reducción potencial de la planificación resolución de problemas, equipo de,324-325
nominal,,. enrada. 424_425
responsabilidades y estructura del equipo,
:eestimación. errore s de. 53
325
lndice 687
responsable técnico, 338-340 bibliografia adicional. 1 17

responsables (líderes), 306 desarrollo externo y, 53 1
de sesiones JAD, 490-491 desventajas, 90
recuperación de proyectos y, 408 ejemplos, 91-92
restricciones de planifica ción, 124- 125 gestión sistemática de riesgos,
retraso del proyecto, 104 tt5-tl1
reuniones (walkthroughs), 82-83 elementos, 92
estimación por, 193 insuficiente, como effor clásico, 51
reutilización (componentes reutilizables), niveles de,92
567-580 riesgos, identificación de, 94-101
bases sobre, 578-579 lista completa de riesgos en la
bibliografia adicional, 579-580 planificación, 94-101
claves para e1 éxito al usar, 579 riesgos de personal, 99-100
desarrollo externo y, 530 riesgos del proceso, 100-101
efectos secundarios de, 5'77 -578 riesgos del producto, 98-99
gestión de riesgos, 5'/6-577 riesgos de los requerimientos, 98
interacción con otros métodos, 578 riesgos de creación de la planificación,
resumen, 567 9s-96
uso de, 568-576 riesgos de organización y gestión, 96
reutilización oportunista, 5 68 - 57 I riesgos del entorno externo, 99
reutilización planificada, 572-57 6 riesgos del cliente, 97
reutilización planificada, 572-576 riesgos de diseño e implementación,
revisiones técnicas 100
bibliografia adicional. 86 riesgos del entorno de desarrollo,
comentarios sobre. 84 96-91
como fundamento de desarrollo. 82-84 riesgos del usuario frnal,97
Rich, Charles,397 riesgos de contratados, 98
riesgos, 1 14 riesgos generales,94
relacionados con los clienres. 158 riesgos más comunes en la planificación,
riesgos, análisis de, 93- 101-1il-+ 91
riesgos, asumir, 108 nesgos. monitorización de. 93, I I 1-l 14
riesgos, control de, 93, 10?- i I -+ nisgos. planificación de la gestión de,93,
riesgos, cuantificación y esrimacron Ce- I l_t-
195-196 ,.:resEos prilcipales>, entrada en las tablas
riesgos de organización, 96 resumen de métodos recomendables,
riesgos, elementos de estimación de. 9-: 4:6
riesgos en la creación de la planiticacie.:, nesgos. pnonzación de,93, 104-107
95-96 riesgos, resolución de, 93, 107-1 I I
riesgos, encargado de, ll4 riesgos, transferencia de, 107-108
riesgos, exposición a, 101-103 tufkin. Stan, 504, 512
riesgos, gestión de, 13, 20,89-118. I e.¡n¡, Ross. Rony. 522, 560, 614
también las secciones de gesrión ,ie Rothfeder, Jeffrey, 90
riesgos de los capítulos del I7 al :3 Rush. Gary W.,499
sobre métodos recomendables Russell. Glen W., 84
,.,. F
5
- 648
i,;:c:_?r. Í1.. lj. 236, 269 software doméstico, definición de, 2J

S¡::jra:r. Hossein, 19 software interactivo, definición de, 27
.¿.;l:rmi. modelo, 1 5 6- I 57 software mllitar,2T
Scherr. ,\llen, 308, 582, 585 software, tipos de, 27
Scholtz. 398,458,514 Software Ac quisition Management
Schulman, Edward, 17 , 236, 27 6, 299 (Marciniak y Reifer), 531,541
secretario, en sesiones JAD, 49 I Softw ar e C onJi gur ation M ana gem ent
Seewaldt, T., 77, 236, 299 (Babich),77
seguimiento, como fundamento del Software ConJiguration M anagement
desarrollo, 65-ó6 (Bersoff), 77
Selby, Richard, 84, 128, 27 6, 292, 294, Software Engineering (Pressman), 85, 8B
314,349,352,369, 441, 449, 469, 571 Software Engineering (Sommerville), 85,
SGBD, herramientas de productividad y 88
aplicaciones orientadas a, 3JB Software Engineering Economics (Boehm).
Shafer, Linda,479 220
Shaw,4'72 Software Engineering Institute (Instituto de
Shen, V. Y., 517 Ingeniería del Software), 19, 34, 63,
Sherman, Roger, 150 66, 67, J4, 79, 404, 541
Showstopper ! (Zachary), 294, 419 Software Engineering Laboratory (NASA),
Shultz, Scott, 630 83, 2gg, 390, 457 ,505, 5 1 1, 5 I 3, 570,
Silver, Denise, 500 514
simples, estimaciones de planificación, Software Engineering Metrics and Models
201-214 (Conte et al.), 517
planificaciones lo más cortas posible, <Software Engineering Under Deadline
204-209 Pressure> (Costello), 25 I
planificaciones eficiente s, 209 -21 1 So e n t ati o n (Mar c otfy'), 7 7
ftw ar e Imp I em
planificaciones nominal es, 21 1 -2 I 4 Software Inspection (Gilb y Graham), 86
primer paso a realizar con,2l4 S oftwar e Me a s ur em en t Gu id eb o o k
tablas de, 202-204 (NASA),516
Sims, James, 488 Software Metrics (Grady y Caswell), 516
sinergia,22-23 < Software Productivity Research
sistemas anteriores, desarrollo externo de Programming Languages Table>
la reingeniería de, 533 (Jones), 564
Smith, Douglas, 291, 320 Software Risk Management (Boehm), I 17,
Smith, P. G.,144 115
Sobol, Marion G.,396 <Software Risk Management: Principles
software <prét-á-porter>, definici ón de, 2j and Practices> (Boehm), 118
software cientifico, 27 Software Sizing and Estitnatizg (Symons),
softu,are comercial disponible, 167 221
ventajas e inconvenientes, 171 <Software's Chronic Crisis> (Gibbs), 370
soffq'are de sistemas, definición, 27 Sommerville, Ian. 85. 88
softw.are. desarrollo de. Véanse bases del Soul of a Nev, Machine, The (Kidder), 582,
desarrollo del software: desarrollo 5g5,5gg
rápido Stahl. Leslie Hulet. 175
índice 689
xvii, 48,'70, 230, 256, efectos secundarios de' 612-613

Standish GrouP,
gestión de riesgos de,612
264,343-344
interacciones con otros métodos, 613
Stapleton, Jennifer, 255, 354
resumen de, 603
StaudenmaYer, NancY A', 514
Srategies for Real-Tíme SYstem
uso, 606-61 I -
claves para el éxito en, 613-614
Specification (Hatley y Pirbhai), 75
papel del resPonsable, 61 1
Structttred Design (Yourdon Y
paso 2: estructurar un Proceso de
Constantine), 76
softu'are donde todos ganen,
subestimación del alcance, planificación
609-6 1 0
excesivamente oPtimista Y, 231
paso 3: estructurar un Producto
superación, Posibilidad de como
software con el que todos ganen,
motivación. 2'78-2'79
610-61 1
supervisión técnica, oportunidades como
paso 1: estabiecer las precondiciones
mofivación, 282-283
donde todos ganan, 601 -609
SWAT, modelo de equiPo, 333-334
L., tipos de ProYectos que Pueden usar
Sweet, W. 541
xvii, 186, 195,208,221' TheorY-W, 611
Symons, Charles,
380
<Theory-W Software Project Management:
Principles and ExamPles> (Boehm Y
Ross),614
Third Iilave Project Management
tamaño del Producto, 22
(Thomsett), I 18
tamaño, estimación del, 189-197 ll8, 17, 318,
Thomsett, Rob, 49, 274, 3
definición de1 tamaño, 190
342,420
estimación de Puntos de función,
lB9-191 Thriving on Chaos (Peters), 278
tiempo de concentración, entornos
Tectmwork (Larson 1'' LaFasto), 341
productivos Y,546
teatro, modelo de equiPo. 335-336
tiempo perdido en el inicio difuso, 51
técnicos, resPonsables. 338-340
tiempo real, sistemas en,27
tecnología
Townsend, Robert, 310
como dimensión de ia veiocidad de
desarrollo, 15. ll trabajo, definición de la satisfacción en el,
s
errores clásicos relacionados con, 55-56
2',7
trabajo rePetido
tema del producto, especiñcación mínima
cómo evitar, 19
v- 349
\' \ erslones por' relaciones con ios clientes y,257-258
femas, entrega por etapas
596-591
tiempo perdido en, 136
Tracz, Will, 575-577, 579
<Ten Commandments of Tooi Selection'
The> (O'Brien), 400 Tutnet, Albert J., 599
tercera generación, lenguajes oe I ¿¡t¿ 3GL
Ttúorial on Software Design Techniques
(Parnas), 460
Tesch, Deborah B., 396
Tutorial : Software Engineering Proj ect
Thayer, Richard H.,67
Theory-W, gestión, 260,406' 6[l]-¡ ii Managemenr (ThaYer), 67
bases,613
Tutorial: Software Quali4t Asstu'ctttce
(Chow, ed.), 85
brbliografía adicionai, 6 13
__)
-,
¿¿--. -Tt-rhn. _i80 prestaciones, 365-366
L¡¡hress. David, 56 versión 3 de herramientas de
- 11. \\-illiam, 251, 606 productividad, 386
usuarios finales. Véqnse también cliente, versiones, desarrollo por, 356
desarrollo orientado al; clientes vida personal como motivación,
falta de implicación, 49 281-282
riesgos asociados con, 97 visibilidad, métodos orientados a la,
l5
visión
Vaishnavi, Vijay K., 453 compartida, en equipos de alto
Valett, J ., 77 , 269 , 299 , 505 rendimiento, 301-303
Van Genuchten, Michiel , 53,200,216, compromiso y, 582-583
229,524 en la dirección de un equipo de alto
velocidad de desarrollo. Véase tqmbién rendimiento, 312
desarrollo rápido fallo de los equipos y falta de,312-313
dimensiones de, l5-23 Visual C++ ¿s Microsoft, 262-263
importancia relativa de, 26-2j Vosburgh, l. 8., 43, 44, 69, 261, 262, 2j'7 ,
personas, 16-18 343,361
proceso, l8-21 Votta, Lawrence G., 514
producto,2l-22
fecnología,22
errores clásicos y, 43-45 Waligora, Sharon, 570, 51 4
patrón típico de mejora, 140-142 Waterman, Robert H., Jr., 268,284,293,
vendedores. Véase desarrollo externo 294,342
ventajosos para todos (Win-Win), Waters, Richard, 397
proyectos, 260 Weinberg, Gerald M., 17, 4'/ , 6i,'1 5, 86,
ventanas temporales, desarrollo con, 236, 237,240, 276, 293, 2gg, 320,
621-630 420, 646,649,654
bibliografía adicional, 630 Weiss, David M., 460, 505
efectos secundarios de, 629 <What Are the Realities of Software
gestión de riesgos, 628 Productivity/Quality Improvements>
interacciones con otros métodos, 629 (Glass), 400
puntos cruciales sobre, 629-630 <When the Rubber Hits the Road:
uso, 623-627 A Guide to Implementing
claves para tener éxito con, 630 Self-Managing Teams> (Thomsett),
criterios de entrada, 625 342
equipo de ventanas temporales, Whitaker, Ken, 268, 289,596
626-627 l4/hy Does Software Cost So Much?
variaciones, 627 (DeMarco), 251,342
versión I de herramientas de nWhy Is Technology Transfer So Hard?>
productividad, 3 B6 (Jones), 400
versión 2 Wicked Problems, Righteous Solutions
de herramienras de productividad, (DeGrace y Stahl), 175
386 Wiener, Lauren Ruth, 345
-'1 .
-á4
-
lndice
Windows NT 3.0, desarrollo de,4l9,443, lYork Redesqgn (Hackman y Oldham),

584-586 294
WinWord (Microsoft Word Para Wosser, 572,574
Windows) 1.0 lYriting Solid Code (Maguire), 77
métodos de planificación optimista y,
225-22'l
Wirth, Niklaus, 343 Yourdon, Edward, 7 5, 7 6, 83, 363, 460
Wisdom of Teams, The (Katzenbach Y
Smith),297
Witness (película), 295, 320 Zachary, Pascal, 29,293,294, 419, 443,
Wood, Jane, 500 447, 448,584, 586
Word para Windows 1.0, métodos de Zawacki, Robert, xxii, 280, 380
planifi cación optimista y, 225 -227 Zelkowitz, 380

Libro

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Libro

Diunggah oleh

Hak Cipta:

Format Tersedia

Desarrollo y gestión

DERECHOS RESERVADOS A 1997, respecto a la primera edición en por

Traducido de la primera edición en inglés de

Copyright A 1996, por Microsoft Corporation

Publicado por McGraw-Hill/Interamericana de España por acuerdo con el editor

Editora: Mercedes F¡anco Calvo

IMPRESO EN ESPAÑA - PRINTED IN SPAIN

SteveMcConnell es ingeniero jefe de softwareenCmu$fuelil

1. Bienvenido al desarrollo rápido J

1.1. ¿Qué es e1 desarrollo rápido? 4

2. Estrategia para el desarrollo rápido

3.1. Ejemplo de errores clásicos ...................:: 35

4. Bases del desarrollo de software 59

': R¡ses del c,¡ntrol de calidad 18

6. Cuestiones fundamentales para el desarrollo rápido I2t

7. Planificación del ciclo de vida....... 145

Bibliosrat'ía adicional ....... 293

13. Estructura del equiPo 32I

16. Recuperación de proyectos ............ 401

16. l. Opciones generales de recuperación .....'..... 404

Introducción a los métodos recomendables .............. 422

Organización de los capítulos de métodos recomendables ..........'... 424

17. Grupo de control de cambios 437

18. Construcción y prueba diarias 439

t9. Diseño para el cambio 451

20. Entrega evolutiva 461

21. Prototipado evolutivo 469

J) Definición de objetivos ................. 481

23. Inspecciones ................. 483

24. Desarrollo conjunto de aplicaciones (JAD) 48s

)É, Selección del modelo de ciclo de vida 501

35. Modelo de ciclo de vida en espiral 589

37. Gestión Theory-W 603

44. Grupo de herramientas.......... .. 631

2.1. Desarrollo rápido sin una estrategia clara 10

2.1. Características de los enfoques estándar de desarrolio orientado a la planifrcación. 23

Los desarrolladores de software están atrapados entre dos fuegos. Uno de

¿Quién debe leer este libro?

puestos que de hecho son de responsable técnico. Si ésta es su función,

Beneficios fundamentales del libro

Mejora en la velocidad de desarrollo. Puede usar la estrategia y los

El desarrollo ráp¡do se basa en ternas trnÍcioriales. Algunos de los

Enfoque práctico. Para algunas p€rsonas, <<práctico> significa <codi-

Organización para una lectura ág¡1. He hecho todo lo posible para

Una nueva forma de pensar sobre el desarrollo níp¡do. No hay

más interesantes de cada ámbito. combinandL- ¡Lar primera vez información

Por qué se ha escrito este libro

EL RESPONSABLE DE PRODUCTOS ME DIJO que quería desarrollar

l*L ¿0É es el desarrollo rápido?

1.2. Cómo lograr el desarrollo rápido

más, podráhacerlo sin aiterar 1a calidad, e7 coste, el renü,,,iaroo le fuF

o Seleccionar métodos eficaces en lugar de métodos ineficaces.

Figura 1.1. Conjunto de todos los métodos para desarrollo de software.

o Métodos que mejoran la velocidad de desarrollo, permitiendo en-

Los tipos específicos que seleccione de métodos orientados a planifi-

Figura 1.2. Hay tres tipos de métodos orientados a ta ptanificación:

Blenvenido al cesarrollo rápido

= :locidad de desarrollo. Si piensa

SI COGIÉSEMOS lOO MÚSICOS DE PRESTIGIO ANTVEL MUNDIAL

perfectamente, pero si cometemos un error no obtendremos un desarrollo

Ejemplo 2.1 . Desarrollo rápido sin una estrategia clara

ta a tiempo)). dijo John.,<La última vez los desarrolladores estur jcrrrn

cón sus,despachos individuales, sus nuevos ordenadores 1os refrescos,

ata entr3gq de laversión definiriváypronto,de$cubrieron que su programa ,

Ct.. - s¡giEre en la Figura 2. 1 , estas cuatro técnicas ofrecen sopor-

que quizás pod'iu uujiiu u 6'.,.,. <De acuerdo,