Ei PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE IVAR JACOBSON GRADY BOOCH JAMES RUMBAUGH ; La guia completa del Proceso Unificado escrita por sus creadores Addison Wesley‘The Addison-Wesley Object Technology Series Grady Booch, Ivar Jacobson, and James Rumbaugh, Series Editors Para tener mas informacion consult a sitio web de la serie (hip:/www.awl.comiesengtseries', asi como las paginas de cada libro [hugpwww.awl comieseng1-S-B-NI] (+S -B-N- es el nimero de ISBN del ibro en inglés, ineluyendo los guiones), David Bellin and Susan Suchman Simone, The CRC Cant Book ISBN 0.201-89835-8 Grady Booch, Object Solutions: Manuying the Object-Oriented Project ISUN 0.8053.0594.7 Grady Boosh, Object-Orienred Analysis and Design with Applications, Second Editon ISBN D-KASH-5340.2 Grady Booch, James Rumbaugh, and Ivar facobson, The Unified Modeling Language User Guide ISBN 0.201-57108-4 Don Box, Essential COM ISBN 0-201-63486.5 Daas Bus, Keith Brown, Tim Ewald, and Chri Seis, Aiecrive COM: 50 Wa to nprove Your COM and MTS-hased Applications ISBN 6-201-37968-0 Alistair Cockburn, Surviving Object-Oriemed Panjets A Managers Guide ISBN 0201-49834. Dave Collins, Designing OhjectOriented User Interfaces ISBN 0-8053.5350-X Bruce Powel Douglass, Doing Hand Tine: Designing and Inplemennng Embedded Sostems with UML ISBN 0-201=19837-5 Bruce Powel Douglass, Real-Time Objects for Emheudded Systems ISBN 0:201-325799 ‘Desmond F, D'Souza and Alan Cameron Wills, Objects Components, and Prumeworks vith UML: The Catalvis Approuch ISBN 0-201-31012.0 Matin Fowler, Anaysis Porters: Reusable Object Models ISBN 0-201-89542.0 Manin Fowler with Kendall Scott, UME Dissilled: Applhing the Standard Object Mostetng Langa ISBN 0:201-32563-2 ML: Developing Fsfcient Peter Heinckiens, Building Scaluble Database Applications: Object-Oriented Design, Architectures, and Implementations ISBN 0201-31013. ar Jacobson, Graly Booch, and James Rumbaugh, The Unified Software Development Process ISBN 0201-57169 war Jacobson, Magnus Christerson, Patrik Jonsson, and Gunnar Overgaard, Object-Oriented Software Engineering A.Use Case Driven Approach ISBN 0-201-54435-0 var Jacobson, Marin Ericsson. and Agneta Jacobson, The Object Advantage: Business Process Reeneineering ‘ith Object Technelogy ISBN 0-201-42280-1 Ivar Jacobson, Martin Griss, and Patrik Jonsson, Software Reuse: Architecture, Proves vind Organ for Business Success TSBN 0-201-92476-5 David Jordan, C-+ Object Databases: Programming with the ODMG Standart ISBN 0-201-83488-0 Philippe Kruchten, The Ravional Unified Process: An Introduction ISBN'0-201-60459.0 WilfLaLonde, Discovering Smart ISBN 0-8053-2720-7 Lockheed Manin Advanced Concepts Center and Rational ‘Aware Corporation, Succeeding with the Booch and OMT Methods: Practical approach ISBN 0-8053.2979.5 ‘Thomas Mowbray and William Rub. faside CORBA: Distaduted Object Standards and Applications ISBN 0:201-89540-4 Ia Pohl, Object-Oriented Programming Using C=, Second Eiition ISBN 0-201-89550-1 Rob Pooley and Perita Stevens, Using UML: Software Engineering with Objects and Components ISBN0-201-36067-5 “Temry Quatrani, Visual Modeling with Rational Rose and UML ISBN 0-201-31016-3 BrontE. Rector and Chris Sell, ATL Jaternals ISBN 0°201-60589-8 Doug Rosenberg with Kendall Scat, Ue Case Driven Object Madeling with UML: A Practical approach ISBN 0:201-43289-7 Walker Rayee, Safieure Project Management: 4 Unified Framesork ISBN 0.201-30958-0 Willian Rub, Thomas Herron, and Paul Klinker, JOP Complete Muldleware interoperability and Distributed Object Standards ISBN 0:201-3792: James Rumbaugh, Ivar Jacobson, and Grady Booch, The Unified Modeling Langguaye Reference Manual ISBN 0-201-30998-% Geri Schneider and Jason P. Winters, Appling Use A Practical Gide ISBN 0-201-3098|-5 ‘Yen-Ping Shan and Ralph H. Earle, Emerprise Computing with Objects: From Client Server Environments to rhe Internet ISBN 0-201-32566-7 David N. Smith, [BM Sola: The Language ISBN 0-8053.0908-X Danie! Tkach, Walter Fang. and Andrew So, Fisuat Modeling Technique: Object Technologs Using Vsual Programming ISBN H-80S3-2574-3 Daniel Trach ard Richard Puttick, Object Techinalogy in Application Development. Second Edition ISBN 0-201-49833-2 os Warmer ang Anacke Kleppe, The Object Consaraint “Language: Precive Modeling with UML ISHN 0-201-3794046EL PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE Ivar JACOBSON Grady BOOCH James RUMBAUGH RATIONAL SOFTWARE CORPORATION Traduccién: Salvador Sanchez Universidad Pontificia de Salamanca en Madrid Miguel Angel Sicilia Universidad Pontificia de Salamanca en Madrid Carlos Canal Universidad de Mélaga Francisco Javier Duran Universidad de Malaga Coordinacién de la traducci6n y revisién técnica: Luis Joyanes Director del Departamento de Lenguajes y Sistemas Informéticos Universidad Pontificia de Salamanca en Madrid Ernesto Pimentel Director del Departamento de Lenguajes y Sistemas Informiticos Universidad de Mélaga ADDISON WESLEY Madrid + México + Santafé de Bogoti + Buenos Aires * Caracas * Lima * Montevideo + San Juan San José + Santiago + Sto Paulo * White PlainsNE Reeyerlro - td Datos ds aah actin blondie 1. Jacobson. Bane, J Rumbaugh EL PROCLSO UNIFICADO DE DESARROLLO DE SOFTWARE, PEARSON FDLCACION, S\, Male, 2081 ISBN; EL TADO.NB6 Mar floss 3 Forma 198 % 280 Prgms 408 1. Jacobson, G. Booch, J. Rumbaugh PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE No esté permiida ls eeproduecisn tonal © parcial de esta obra fi su tatamiient 0 transimisin por cualquier medio © método sin auorizacidn eserta de la Editorial DERECHOS RESERVADOS (© 2000 respecto a a primera edicién en espaol por PEARSON EDUCACION, 8. A Nuner de Balboa, 120 28006 Madi ISBN: 84-7829-036-2 Depésito legal: M. 20.385-2000 ADDISON WESLEY ¢s un sello editorial de PEARSON EDUCACION, S. A. Traducido de: ‘THE UNIFIED SOFTWARE DEVELOPMENT PROCESS. Copyright © 1999 Addison Wesley Longman Ine ISBN: 0-201-57169-2 Eddicién en export: Editor: Andrés Otero Asistemte editorial: Ana Isabel Garcla Diseito de cubierta: DIGRAR, S. A. ‘Composicién: COPIBOOK. 8. L, Impreso por: Imprenta FARESO. S. A. IMPRESO EN ESPANA - PRINTED IN SPAIN Fite id rps con papel tineContenido Prefacio . Parte I: El Proceso Uni ado de Desarrollo de Software Capitulo 1: El Proceso Unificado: dirigido por casos de uso, 16. Capitulo 2: Las cuatro “P” en el desarrollo de softwar BRE centrado en la arquitectura, iterativo e incremental. El Proceso Unificado en pocas palabras : EI Proceso Unificado esté dirigido por casos de uso El Proceso Unificado esté centrado en la arquitectura El Proceso Unificado es iterativo e incremental La vida del Proceso Unificado .. 15.1. El producto ........... 1.5.2. Fases dentro de un ciclo Un Proceso integrado Proyecto, Producto y Proceso. Las personas son decisivas . 2.1.1, Los procesos de desarrollo afectan a las personas 2.1.2. Los papeles cambiarin ... 3. Convirtiendo “recursos” en “trabajadores Los proyectos construyen el producto El producto es mas que cédigo ....... 2.3.1 {Qué es un sistema software? ..... 2.3.2. Artefactos xv 15vi CONTENIDO 26. Capitulo 3: Un proceso di bf Eee Capitulo 4: Un proceso centrado en la arquitectura . . 41. 4.2. Un sistema posee una coleccién de modelos {Qué es un modelo? a Cada modelo es una vista autocontenida del sistema .- Dentro de un modelo... Relaciones entre modelos . El proceso dirige los proyectos... 0.0. 0ceeeeeeee eee 2.4.1, El proceso: una plantilla .. an 2.4.2. Las actividades relacionadas Conforman flujos de trabajo 2.4.3. Procesos especializados ........ 2.4.4. Méritos del proceso ...... La herramientas son esenciales en el proceso. vee 2.5.1. Las herramientas influyen en el proceso . .. 2.5.2. El proceso dirige las herramientas . .. : 3. El equilibrio entre el proceso y las herramientas 2.5.4. El modelado visual soporta UML : 2.5.5. Las herramientas dan soporte al ciclo de vida completo Referencias... ...scees Ren jo por casos de uso Desarrollo dirigido por casos de uso en pocas palabras . Por qué casos de uso? ....... 3.2.1. Para capturar los requisites que aportan valor atadido 3.2.2. Para dirigir el proceso ......... 3.3.3. Para idear la arquitectura y més, La captura de casos de uso . 3.3.1. El modelo de casos de uso representa los requi 3.3.2. Los actores son el entorno del sistema .. 3.3.3. Los casos de uso especifican el sistema : Analisis, disefio e implementacién para realizar los casos de uso 3.4.1. Creacién del modelo de andlisis a partir de los casos de uso . . 3.4.2. Cada clase debe cumplir todos sus roles de colaboracién Los subsistemas agrupan a las clases disefio sees Prueba de los casos de uso Resumen Referenci: La Arquitectura en pocas palabras : Por qué es necesaria la arquitectura .. <2... : 4.2.1. Comprension del sistema... 0.2... cece eee 4.2.2. Organizacién del desarrollo. 4.2.3. Fomento de la reutilizacién 4.2.4. Evolucién del sistema ........0500+6 ron Casos de uso y arquitectura 0.0 Los pasos hacia una arquitectura Creacién del modelo de disefio a partir del modelo de andlisis .. Creacién del modelo de implementacién a partir del modelo de 19 20 20 21 21 22 22 22 24 25 25 25 26 27 27 28 29 aL 33 35 35 36 37 38 38 39 39 40 41 45 46 49 50 52 53 54 35 56 58 38 59 5045. 4.6, 47. Capitulo 5. Un proceso iterativo e incremental 5. 5.3, 55, 5.6, 5.7. 58 59 CONTENIDO 4.4.1, La linea base de la arquitectura es un sistema “peque’to y flaco” Utilizacién de patrones arquitecténicos ..........5 Descripeién de la arquitectura . 4.4.4, El arquitecto crea la arquitectura Por fin, una descripeién de la arquitectura oeeeeen 4.5.1, La vista de la arquitectura del modelo de casos de uso. 4.5.2. La vista de la arquitectura del modelo de disefio 4.5.3. La vista de la arquitectura del modelo de despliegue 4.54, La vista de la arquitectura del modelo de implementacién . Tres conceptos interesantes ........ 4.6.1, {Qué es una arquitectura? rrerren 4.6.2. {Comose obtiene? .....0 00sec 4.6.3. (Cémo se describe? ..... Referencias ....... Iterative e incremental en breve 5.1.1. Desarrollo en pequeiios pasos... 5.1.2, Loque noes unaiteracién ...... Por qué un desarrollo iterativo ¢ incremental? « ‘Atenuacién de riesgos .... : Obtencién de una arquitectura robusta. Gestién de requisitos cambiantes Permitir cambios técticos Conseguir una integracién continua 5.2.6. Conseguir un aprendizaje temprano : La aproximacién iterativa es dirigida por los riesgos .. . 5.3.1, Las iteraciones alivian los riesgos técnicos . . 5.3.2. Ladireccién es responsable de los riesgos no téenicos 5.3.3, Tratamiento de los tiesgos ....... La iteracién genérica .......... 5.4.1. Lo que es una iteracién nore 5.4.2. Planificacién de las iteraciones 2.22.2... 5.4.3, Secuenciacién de las iteraciones El resultado de una iteraciGn es un ineremento . Las iteraciones sobre el ciclo de vida. . Los modelos evolucionan con las iteraciones. Las iteraciones desafian a la organizacién Referencias Parte Il: Los flujos de trabajo ftundamentales Capitulo 6: Captura de requisitos: de la vision a los requisitos . . 6.1 6.2. 63. 64. Por qué la captura de requisitos es complicada El objeto del flujo de trabajo de los requisitos VisiGn general de la captura de requisitos .. El papel de los requisitos en el ciclo de vida del software - vu 65 67 69 7 nD 73 4 76 71 78 8 8 18 18 81 82 83 84 85 85 87 87 88 88 90 90 91 93 93 94 94 96 96 07 98 100 101 102 105 106 107 107 lLVII CONTENIDO 6.5. La comprensién del contexto det sistema mediante un modelo del dominio . Soret errr ee 112 6.5.1, ,Quées un modelo del dominio? . 2 6.5.2. Desarrollo de un modelo del dominio ua 6.5.3. Uso del modelo del dominio ........ us 6.6. La comprensidn del contexto del sistema mediante un modelo del negocio, 115 6.6.1. Qué es un modelo del negocio? ...-..--eeeeeeeeeeeer eee US 6.6.2. Cémo desarrollar un modelo del negocio 118 6.6.3. Busqueda de casos de uso a partir de un modelo del negocio .. 120 6.7. Requisitos adicionales ... 121 68. Resumen ......c cece 123 6.9. Referencias . . . 123 Capitulo 7: Captura de requisitos como casos de uso ... 125 7.1. Introdueci6n 125 7.2. Ariefactos ve veces 127 7.2.1. Artefacto: modelo de casos de USO sss eve 127 7.2.2. Artefacto: actor... 2... a 128 7.2.3. Caso de uso ....... 129 7.24, Artefacto: descripcién de la arquitectura (vista del modelo de casos de uso) i Artefacto: glosario Artefacto: prototipo de interfaz de usuario 73. Trabajadores : 7.3.1. Trabajador: analista del sistema... 73.2. Trabajador: especificador de casos de us 7.3.3, Disefiador de interfaces de usuario ........ 7.34, Trabajador: arquitecto ... 7.4, Flujo de trabajo els 7A.1. Actividad: encontrar actores y casos de USO... esses Actividad: priorizar casos de uso. Actividad: detallar un caso de uso : Actividad: prototipar la interfaz de usuario Actividad: estructurar el modelo de casos de uso... 7.5. Resumen del Ajo de trabajo de los requisitos 7.6. Referencias . beens Capitulo 8: Analisis ... 165 8.1. Introduecién . . 165 8.2. El andlisis en pocas palabras : 168 8.2.1. Por qué el analisis no es disenio ni implementacion 168 8.2.2. El objeto del andlisis: resumen . 169 8.2.3. Ejemplos coneretos de cudndo hacer anilisis .......... 170 8.3, El papel del andlisis en el ciclo de vida del software... i71 8.4, Artefactos . 172 84.1. Artefucto: modelo de andlisis 172 8.4.2. Artefacto: clase del andli 173. 8.4.3. Artefacto: realizacién de caso de uso-anilisis 177CONTENIDO IX 8.4.4. Artefucto: paquete del andlisis ...... 18] 84.5, Artefacto: descripeidn de la arquitectura (vista del modelo de andlisis) 0.0... rer nrnaes 183 8.5. Trabajadores fee 184 8.5.1. Trabajador: arquitecto : 184 85.2. Trabajador: ingeniero de casos de uso a cee 185 8.5.3. Trabajador: ingeniero de componentes ...........60.0002. 186 8.6. Flujo de trabajo a et eee 187 8.6.1. Actividad: andlisis de la arquitectura - 187 8.6.2. Actividad: analizar un caso de uso ......-- : . 194 8.6.3. Actividad: analizar una clase 197 8.6.4. Actividad: analizar un paquete . : - 201 8.7. Resumen del andlisis. : bebeteeeeeeeeeeeeees 203 R8. Referencias 204 Capitulo9: Disefio............ an 9.1, Introduccién . eeSeTeTTE : = fio en el ciclo de vida del software seveeeeeeee 207 9.2. El papel del dis 93. Artefactos 2... vetetetetetttteteseereses 208 9.3.1. Artefacto: modelo de disefio . . nee coo 208 9.3.2. Artefacto: clase del diseio osc eeeeeeeeeeeeee 209 9.3.3, Artefacto: realizacién de caso de uso-diseito . 210 9.3.4. Artefacto: subsistema del disefio . . . . . . . 213 9.3.5. Artefacto: interfaz : 215 9.3.6. Artefacto: descripcisn de la arquitectura (vista del modelo de diseno) ——— . 216 9.3.7. Artefacto: modelo de despliegue - nee 217 9.38. Artefacto: deseripeidn de la arquitectura (vista del modelo de despliegue) 9.4, Trabajadores 9.4.1. Trabajador: arquitecto 9.4.2, Trabajador: ingeniero de casos de uso. 2A.3. | Trbjador:ingeniero de component 9.5. Flujo de trabajo a 9.5.1, Actividad: disefio de la arquitectura .. 9.5.2. Actividad: disefiar un caso de uso . 9.5.3, Actividad: disefiar una clase... 9.5.4. Actividad: disenar un subsistema . 9.6. Resumen del diseio 9.7. Referencias Capitulo 10: Implementacién .. 255 10.1. Introduceién .... seve 255 10.2. El papel de la implementacién en el ciclo de vida del sofware 256 10.3. Artefactos ....... Deere 257 10.3.1. Artefacto: modelo de implementacién . 237 10.3.2. Artefacto: componente 257X — CONTENIDO 10.3.3. Artefacto: subsistema de Ia implementacin .............. 260 10.3.4. Antefacto: interfaz ......, 262 10.3.5, Artefacto: descripcién de la angst (vista del modelo de implementacién) veces 263 10.3.6. Artefacto: plan de integracién de construcciones .......... 264 10.4. Trabajadores en ee 265 10.4.1. Trabajador: arquitecto . i sevens 265 10.4.2. Trabajador: ingeniero de componentes 266 10.4.3. Trabajador: integrador de sistemas... 266 10.5. Flujo de trabajo. eeeeed 267 10.5.1. Actividad: implementacién de la arquitectura 268 10.5.2. Actividad: integrar el sistema ......... coves 270 10.5.3. Actividad: implementar un subsistema ......... : 272 10.5.4, Actividad: implementar una clase 274 10.5.5. Actividad: realizar prueba unidad . .. pease 276 10.6. Resumen de la implementacién ........... eee 279 10.7, Referencias... fee eee eeteteeeeeetrenees 219 .Capitulo 11: Prueba ......... . L281 I.L. Introduecién . cevteeeeeees 281 11-2. El papel de la prueba en el ciclo de vida del software . 282 1L3. Artefuctos ....... 283 11.3.1. Artefacto: modelo de pruebus ee 283 11.3.2, Artefacto: caso de prueba . . : betteteeeeeeees 283 11.3.3. Artefacto: provedimiento de pruebas... sss 286 I Artefacto: componente de prueba .......... veveee 287 11.3.5, Artefacto: plan de prueba, ceceeeeeees 288 HW Attefacto: defecto ....... . a - 288 11.3.7. Artefacto: evaluacién de prueba ceveeeeeees 288 11.4. Trabajadores . ce veceeeeeeees 288 L141. Trabajador: disefiador de pruebas. . ceceeeeeeeeee 288 11.4.2. Trabajador: ingeniero de componentes . : cee 289 11.4.3, Trabajador: ingeniero de pruebas de integracién - 289 11.4.4, Trabajador: ingenieto de pruebas del sistema. ceceees 289 ILS. Flujo de trabajo weet eeee ee eeteeeeettreeerer eres 290 115.1. Actividad: planificar prueba . 201 11.5.2, Actividad: disefiar prueba ......... eee 292 11.5.3. Actividad: implementar prueba 0... 60.00.00 cee 295 11.5.4, Actividad: realizar pruebas de integracién 296 11.5.5. Actividad: realizar prueba de sistema... .. sevens 297 11.5.6. Actividad: evaluar prueba Perot hee eee 297 11.6, Resumen de la prueba 0.0 ...0..eeeceeee rere eeeeee - 299 11.7, Referencias ......... : cetteteeeeeereeeereree E! Desarrollo iterativo e incremental Capitulo 12: EI flujo de trabajo de iteracién genérico veces 303 12.1. La necesidad de equilibrio - 304CONTENIDO XT 12.2. Las fases son la primera divisién del trabajo... veveeeee 305 12.2.1. La fase de inicio establece la viabilidad «0.000.000.0225. 305 12.2.2. La fase de elaboracidn se centra en la factibilidad ......... 306 12.2.3. La fuse de construccién construye el sistema ............. 307 12.2.4. La fase de transicién se mete dentro del entorno del us. 12.3. La iteracién genérica 12.3.1. Los flujos de trabajo fundamentales se repiten en cada iteraci6n 12.3.2. Los trabajadores participan en los flujos de trabajo. 12.4, El planificar precede al hacer . heriesdeeeseed 12.4.1, Phanear las cuatro fases 12.4.2. Plan de iteraciones, 12.4.3. Pensar a largo plazo 12.4.4. Planear los criterios de evaluacién Los riesgos influyen en la planificacién del proyecto 12.5.1. Administrarla lista de riesgos -. on 12.5.2, Los riesgos influyen en el plan de iteracion 12.5.3. Planificar la accién sobre los riesg 12.6. Asignacidn de prioridades a los casos de uso a Riesgos espeeificos de un producto particular Riesgo de no conseguir Ia arquitectura correcta Riesgo de no conseguir los requisitos correctos . 12.7, Recursos necesitados 12.7.1. Los proyectos difieren enormemente ... 12.7.2. Un proyecto tipico tiene este aspecto .. : Los proyectos mas grandes tienen mayores hnecesidades ... Una nueva linea de productos requiere experiencia El pago del coste de los recursos utilizados 12.8, Evaluar las iteraciones y las fases 12.8.1. Criterios no aleanzados: 12.8.2. Los criterios mismos ... 12.8.3. La siguiente iteracién 12.8.4. Evolucién del conjunto de modelos Capitulo 13: La fase de inicio pone en marcha el proyecto 13.1 13.2. Al comienzo de la fase de 2.1. Antes de comenzar la fase de inicio Planificacién de la fase de inicio... . Ampliacidn de Ia deseripeisn del sistema « 13.24. Establecimiento de los criterios de evaluaci6n 13.3. Flujo de trabajo arquetipico de una iteracién en la fase de inicio . 13.3.1. Introducci6n a los cinco flujos de trabajo fundamentales 3.2. Ajuste del proyecto al entorno de desarrollo . 13.3.3, Identificacién de los riesgos criticos 13.4. Bjecucién de los flujos de trabajo fundamentals, de requisites apruebas ce 13.4.1. Recopilacién de requisitosxi CONTENIDO. 13.4.2. Anilisis 13.4.3. Diseiio . . 13.4.4. Implementacién 13.4.5. Pruebas bere 13.5. Realizacién del andlisis inicial de nego 13.5.1. Esbozar la apuesta econ6mica ...... 13.5.2. Estimar la recuperaci6n de la inversion : 13.6, Evaluacidn de la iteracién o iteraciones de la fuse de inicio 13.7, PlanificaciGn de la fase de elaboracin 13.8. Productos de la fase de inicio . 0 Capitulo 14: La fase de elaboracién construye la linea base de la arquitectura . esueeleees 14.1. La fase de elaboracién en pocas palabras 14.2. Al comienzo de la fase de elaboracién 14.2.1. Planificacién de la fase de elaboracién 14.2.2. Formacién del equipo 14.2.3. Modificacién del entorno de desarrollo 14.2.4. Establecimiento de criterios de evaluacién 14,3. Flujo de trabajo arquetipico de una iteracién en la fase de elaboracién ...... 14.3.1. Recopilaci6n y refinamiento de la mayor part requisitos : 14 Desarrollo de la Tinea base de la arquitectura 14.3.3. Tterando mientras el equipo es pequeiio. 14.4. Ejecucion de los flujos de trabaje fundamentales, de requisites rte de los a pruebas . 14.4.1. Recopilar los requisitos 14.4.2, Analisis 14.4.3. Diseno . 14.4.4, Implementacién . 14.4.5, Pruebas 14.5. Desarrollo del andii 14.5.1. Preparar Ia del negocio . apuesta econémica .. 14.5.2. Actualizar la recuperacién de la inversion 14.6, Evahtacién de las iteraciones de la fase de elaboracién 14.7, Planificacién de la fase de construccién 14.8, Productos clave Capitulo 15: La construccion lleva a la capacidad operacién inicila 15.1. La fase de construccién en pocas palabras 15.2. Al comienzo de la fase de construccién 15.2.1. Asignacién de personal para la fase 15.2.2. Establecimiento de los criterios de evaluacisn 15.3. Flujo de trabajo arquetipico de una iteracién en la fase de construccion 15.4. Ejecucién de tos flujos de trabajo fundamentales, de requisitos apruebas . . . 15.4.1. Requisitos 337 338 339) 339 340 340 341 341 342 343CONTENIDO XID 154.2. Analisis. : Dee 373 15.4.3. Diseiio Seeenhenenel 374 15.4.4, Implementacién ........ 0+. ne 375 15.4.5. Pruebas ce wen eren 377 15.5. Control det andlisis de negocio seve 3B 15.6. Evalacidn de las iteraciones y de la fase de construccion 0. ..0-. 378 15.7, Planilicacién de la fase de transicién we vee a 379 15.8. Productos clave eee a . 379 Capitulo 16: La transicién completa la version del producto........ 381 16.1. La fase de transicidén en pocas palabras .. oe eeeeee 382 16.2. Al-comienzo de ha fase de tansici6n oe... e eee cece reece 383 16.2.1, Planificacién de la fase de transicién .... beceeeeeee 383 16.2.2. Asignacidn de personal para la fase... on 384 16.2.3, Establecimiento de los criterios de evalua 385 16.3. Los flujos de trabajo fundamentales desempeffan un ape pequeto en esta fase. : 385 164. Lo que se hace en la Tase de wansicign .. - 386 16.4.1. Preparacidn de la versién beta : 387 16.4.2, Instalacidn de la version beta... a 387 16.4.3. Reaccidn a los resultados de las pruebas - 388 164 Adaptacisn del producto a entornos de usuario variados 388 16.4.5, Finalizacién de los artefactos 6.6... severe 300 16.4.6. ,Cusndo acaba el proyecto? .... bitcteeeereeees 300 16.5. FinalizaciGn del andlisis del negocio .......6 eee eee : 301 16.5.1, Control del progres bitteeteteeeereees 301 16.52, Revisidn del plan del negocio... leanne 301 16.6. Evaluacidn de la fase de transicién ee reren 391 16.6.1. Evaluacidn de las iteraciones y de la fase... : 392 16.6.2. Autopsia del proyecto... 302 16.7. Planificacién de li préxima versidn 0 generacién te + 393 16.8. Productos clave . : a os ceceeeeee 303 Capitulo 17; Como hacer que el Proceso Unificado funcione . . 395 17.1. Bl Proceso Unificado ayuda a manejar la compli - . 395 17.1.1. Los objetivos del ciclo de vida. . seceeeees 306 17.1.2. Laarquitectura del ciclo de vida. : : 396 17.1.3. Capavidad operativa inicial . a ee 397 17.14. Lanzamiento del producto 307 17.2. Los temas importantes . - Selene 397 17.3. La direccién lidera la conversién al Proceso Unificado 398, 17.3.1, La necesidad de actuar een + 399 17.3.2. Ladirectriz de reingenieria ..... 309 17.3.3. ImplementaciGn de la transicién 400 17.4. Especializacién del Proceso Unificado 402 174.1. Adaptacién del proceso 402 174.2, Completando ef marco de trabajo del proceso... css... 403 17.5. Relacién con comunidades més amplias . ... ae 403XIV CONTENIDO. 17.6. Obtenga los beneficios del Proceso Unificado 0.2... ... eee 404 17.7. Referencias ........ - : Be eteeeleesens 405 Apéndice A: Vision general del UML ............ ceceeeeeeeees 407 Al. Introduccién ..... 407 ALLL. Vocabulario 408 1.2. Mecanismos de extensibilidad 408 2. Notacién grafica SE goo A2.1, Cosas estructurales . . 409 A2.2. Blementos de comportamiento 0.0.2.2... cece 410 Elementos de agrupacin .... : 4 A.24, Blementos de anotacion 00.6.0... All A.2.5. Relaciones de dependencia feittetttetttteeeeeeee all A.2.6. Relaciones de asociacion ... 2. os it A.2.7. Relaciones de generalizacion 00... eee 412 A.28. Mecanismos de extensibilidad 0.0.0... 2 cee ceeeeeee 412 A.3. Glosario de términos ......... : ee - 412 AA. Referencias oe 418 Apéndice B: Extensiones del UML IL especificas del Proceso Unificado ... B.1. Introduccion B.2._ Estereotipos B.3. Valores etiquetados . B4. Notacién grifica B.S. Referencias . Apéndice C: Glosario general 2... eee eee 425 Cl, Introduccion. * —— 425 C2. Términos... 20. yee ees dee easde oes 425 indice ... 435Prefacio habilidades de individuos altamente cualificados, que saben emo hacer el trabajo y 10 hacen bien, y que raramente necesitan direcci6n sobre las politicas y procedimientos de ta organizacién para la que trabajan. H: gente que cree que las empresas profesionales deberfan organizarse en torno a las Esta creencia es una equivocacién en la mayorfa de los casos, y una grave equivocacién en el caso del desarrollo de software. Por supuesto, los desarrolladores de software estén altamente cualificados, pero Ia profesién es atin joven, En consecuencia, los desarrolladores necesitan direccién organizativa, a la cual, en este libro, llamamos “proceso de desarrollo de software”. ‘Ademés, debido a que el proceso que ponemos en marcha en este libro representa la unin de metodologfas antes separadas, nos sentimos justificados al llamarlo “Proceso Unificado”. No s6lo retine ef trabajo de tres autores, sino que incorpora numerosas aportaciones de otras per- sonas y empresas que han contribuido a UML, asf como un niimero significativo de aportacio- nes fundamentales de personas en Rational Sajiware Corporation, Surge de manera especial de la experiencia directa de cientos de organizaciones que han trabajado en sus oficinas con las primeras versiones del proceso. Un director de una orquesta sinfénica durante un concierto hace poco mas que decir a los, mtisicos cudndo comenzar y ayudarles a tocar juntos. El o ella no puede hacer mas porque hat dirigido a Ta orquesta durante los ensayos y la preparacién de las partituras, y porque cada mui- sico esté muy preparado en su propio instrumento y en realidad lo toca de manera independiente del resto de los otros miembros de la orquesta. Lo que es més importante para nuestros pro- pésitos, cada mtisico sigue un “proceso” diseiado hace mucho tiempo por el compositor. Es la partitura musical la que proporciona el grueso de “la politica y el procedimiento” que guian el concierto. En contraste, los desarrolladores de software no trabajan de manera independiente interaccionan unos con otros y con los usuarios. No tienen una partitura —mientras no tengan un. proceso.XVI PREFACIO La necesidad de un proceso promete hacerse més critica, especialmente en empresas u or- _ganizaciones en las cuales los sistemas software son esenciales, tales como las financieras, las de control de tréfico aéreo, las de defensa y las de sistemas de telecomunicaciones. Con esto que- remos decir que la direccisn con éxito del negocio o la ejecuci6n de fa misién paiblica depende del software que la soporta. Estos sistemas software se hacen més complejos, su tiempo de sa- lida al mercado necesita reducirse, y su desarrollo, por tanto, se hace més dificil. Por razones como éstas, fa industria del software necesita un proceso para guiar a los desarrolladores, al igual que una orquesta necesita la partitura de un compositor para dirigir el concierto. es un proceso de desarrollo de software? Un proceso define quién esté haciendo qué, cudndo, y cémo alcanzar un determinado objetivo. En la ingenieria del software el objetivo es construir un producto software o mejorar uno existente. Un proceso efectivo proporciona normas para el desarrollo eficiente de software de ca- lidad. Captura y presenta las mejores pricticas que el estado actual de la tecnologia permite. En consecuencia, reduce el riesgo y hace el proyecto mis predecible. El efecto global es el fomento de una visién y una cultura comunes, Es necesario un proceso que sirva como gufa para todos los participantes —clientes, usuarios, desarrolladores y directores ejecutivos. No nos sirve ningtin proceso antiguo; necesitamos uno que sea el mejor proceso que la industria pueda reunir en este punto de su historia. Por tltimo, necesitamos un proceso que esté ampliamente disponible de forma que todos los interesados Puedan comprender su papel en el desarrollo en el que se encuentran implicados. Un proceso de desarrollo de software deberfa también ser capaz de evolucionar durante mu- cchos aftos. Durante esta evolucién deberia limitar su alcance, en un momento del tiempo dado, alas realidades que permitan las tecnologias, herramientas, personas y patrones de organizacién. + Tecnologias. BI proceso debe construirse sobre las tecnologias —lenguajes de programa- cidn, sistemas operativos, computadores, estructuras de red, entomos de desarrollo, etc — disponibles en el momento en que se va a emplear el proceso. Por ejemplo, hace veinte afios el modelado visual no era realmente de uso general. Era demasiado caro, En aquellos tiempos, un creador de un proceso practicamente tenfa que asumir que se usarfan diagra- mas hechos a mano. Esa suposicién limitaba mucho el grado en el cual el creador del proceso podfa establecer el modelado dentro del proceso, + Herramientas. Los procesos y las herramientas deben desarrollarse en paralelo. Las herramientas son esenciales en el proceso, Dicho de otra forma, un proceso ampliamente utilizado puede soportar la inversidn necesaria para crear las herramientas que Io soporten * Personas. Un creador del proceso debe limitar el conjunto de habilidades necesarias para trabajar en el proceso a las habilidades que los desarrolladores actuales poseen, o apuntat aquellas que los desarrolladores puedan obtener ripidamente, Hoy es posible empotrar en herramientas software téenivas que antes requerfan amplios conocimientos, como la com- probacin de la consistencia en los diagramas del modelo, + Patrones de organizacién. Aunque los desarrolladores de software no pueden ser expertos tan independientes como los musicos de una orquesta, estén muy lejos de los trabajado- res autématas en Jos cuales Frederick W. Taylor bas6 su “direccién cientifica” hace cien afios. El ereador del proceso debe adaptar el proceso a las realidades del momentoPREFACIO. XVII —hechos como las empresas virtuales; el trabajo a distancia a través de lineas de alta ve- locidad; la mezcla (en empresas pequefias recién montadas) de socios de la empresa, em- pleados asalariados, trabajadores por obra, y subcontratas de outsourcing; y Ia prolongada escasez de desarrolladores de software. Los ingenieros del proceso deben equilibrar estos cuatro conjuntos de circunstancias. Ade- mis, el equilibrio debe estar presente no slo ahora, sino también en el futuro. El creador del proceso debe diseftar el proceso de forma que pueda evolucionar, de igual forma que el desa- rrollador de software intenta desarrollar un sistema que no s6lo funciona este affo, sino que evo- luciona con éxito en los afios venideros. Un proceso debe madurar durante varios afios antes de alcanzat el nivel de estabilidad y madurez que le permitiré resistir a los rigores del desarrollo de productos comerciales, manteniendo a la vez un nivel razonable de riesgo en su wilizacién. El desarrollo de un producto nuevo es bastante arriesgado en si mismo como para aftadirle el ries- go de un proceso que esté poco validado por ta experiencia de su uso. En estas circunstancias, un proceso puede ser estable. Sin este equilibrio de tecnologtas, herramientas, personas y organi- zacién, el uso del proceso serfa bastante arriesgudo. Objetivos de este libro Este libro presenta el proceso de desarrollo que estuvo constantemente en nuestras cabezas mientras desarrollabamos el Lenguaje Unificado de Modelado. Aunque UML nos ofrece un modo esténdar de visualizar, especificar, construir, documentar y comunicar los artefactos de un sistema muy basado en el software, por supuesto somos conscientes de que un lenguaje como éste debe utilizarse en el contexto de un proceso de software completo. UML es un medio, y no un fin. El objetivo final es una aplicaci6n software robusta, flexible y escalable. Es necesario tanto un proceso como un lenguaje para poder obtenerla, y el objetivo de este libro es mostrar la parte del proceso. Aunque proporcionamos un breve apéndice sobre UML, no pretende ser com- pleto ni detallado, Para un tutorial detallado sobre UML, remitimos a BI Lenguaje Unificado de Modelado, traduecién de la Guta de Usuario del Lenguaje Unificado de Modelado [11]. Para una referencia completa de UML remitimos al Lenguaje Unificado de Modelado Manual de Re- ferencia (12) Audiencia Este libro esté destinado a cualquier persona implicada en el desarrollo de software. Se dirige principalmente a miembros del equipo de desarrollo que se dedican a las siguientes actividades, del ciclo de vida: requisitos, andlisis, diseito, implementacién y pruebas —es decir, a trabajos que producen modelos UML. Asf, por ejemplo, este libro es titil para analistas y usuarios finales (que especifican la estructura y comportamiento requeridos por el sistema), para desarrolladores de aplicaciones (que disefian los sistemas que satisfacen esos requisitos), para programadores (que convierten esos disefios en cédigo ejecutable), para ingenieros de prueba (que verifican y validan la estructura y comportamiento del sistema), para desarrolladores de componentes (que crean y catalogan componentes), y para directores de proyecto y de producto. Este libro presupone un conocimiento basico de conceptos de orientacién a objetos, También 8 ttil, pero no se requiere, experiencia en desarrollo de software y en algtin lenguaje orientado a objetos.XVII PREFACIO. Método del libro Hemos dedicado la mayoria del espacio de este libro a aquellas actividades —requisitos, andli- sis y disefio— sobre las cuales UML hace mayor hincapié. Es en esas dreas de mayor énfasis en Jas que el proceso desarrolla la arquitectura de sistemas software complejos. Sin embargo, tra- tamos el proceso completo, aunque con menos detalle, No en vano, es el programa ejecutable el que se ejecuta finalmente. Para llegar hasta él, un proyecto depende de los esfuerzos de cada miembro del equipo, asf como del soporte de los usuarios. Como se vera, el proceso descansa en una tremenda variedad de actividades. Es necesario producir y hacer el seguimiento de muchos artefactos. Todas las actividades deben gestionarse. E1 tratamiento completo del ciclo del ciclo de vida queda fuera de la intencién de cualquier libro. Un libro que lo hiciese tendria que cubrir normas de disefo, plantillas para los artefactos, indicadores de calidad, gestidn del proyecto, gestiGn de la configuraci6n, métricas y mas, jmu- cho més! Con el desarrollo del acceso interactivo, ese “més” esta hoy disponible, y puede ac- tualizarse segiin dicten los nuevos avances, Por esto, remitimos al lector al Proceso Unificado de Rational, un producto software que puede utilizarse desde la Web, que orienta a los equipos de desarrollo hacia précticas de desarrollo de software més efectivas. (Consultar para mas infor- macién http://www.rational.com.) Al cubrir el ciclo de vida completo, el Proceso Unificado de Rational extiende el Proceso Unificado més alld de las dreas descritas en este libro y ofrece flu- {jos de trabajo adicionales que este libro no cubre © que menciona s6lo de pasada, como el mo- delado del negocio, la gestién del proyecto, y Ia gestion de la configuracién Historia del Proceso Unificado El Proceso Unificado esté equilibrado por ser el producto final de tres décadas de desarrollo y uso prictico. Su desarrollo como producto sigue un camino (véase la Figura P.1) desde el Pro- ceso Objectory (primera publicacién en 1987) pasando por el Proceso Objectory de Rational (publicado en 1997) hasta el Proceso Unificado de Rational (publicado en 1998). Su desarrollo / ‘Otras fuentes EI método de Rational uM El método de Ericsson Figura P.1. El desarrollo del Proceso Unificado (las versiones del producto se muestran en rectangulos coloreados en gris)PREFACIO XIX ha reeibido influencias de muchas fuentes. No pretendemos tratar de identificarlas todas (real- mente no sabemos cules son todas), trabajo que dejamos a Ia investigacién de los arqueslogos del software. Sin embargo, describiremos la influencia sobre el producto de los métodos de Ericsson y de Rational, asf como el de varias otras fuentes. EI método de Ericsson El Proceso Unificado posee raices profundas. En palabras de Peter F. Drucker, es una “innova- cién basada en el conocimiento”. EI nos informa de que “hay un lapso de tiempo prolongado en tre la emergencia del nuevo conocimiento y su destilacién en tecnologia utilizable”. “Entonce: sucede otro largo periodo antes de que esta nueva tecnologia aparece en el mercado en produc- tos, procesos o servicios.” [1] ‘Un motivo para este largo tiempo de aparicién es que la innovacion basada en el conoci miento se cimienta en la unién de muchos tipos de conocimiento, y esto lleva su tiempo. Otra raz6n es que las personas que tienen que hacer efectiva la nueva idea necesitan tiempo para digerirla y comunicarla a los demas. Como primer paso hacia el alumbramiento del desarrollo del Proceso Unificado, nos re- ‘montaremos a 1967 para esbozar los logros de Eriesson [14], [15], [16}. Ericsson modelaba el sistema entero como un conjunto de bloques interconectados (en UML, se los conoce como “subsistemas” y se implementan mediante “‘componentes”). Después, ensamblaba los bloques de mais bajo nivel en subsistemas de mas alto nivel, para hacer el sistema més manejable. Identifi aban los bloques estudiando los casos de negocio —hoy conocides como “casos de uso”—, pre- viamente especificados. Para cada caso de uso, identificaban los bloques que debian cooperar para realizarlo, Con el conocimiento de las responsabilidades de cada bloque, preparaban su es: pecificacién. Sus actividades de disefio producfan un conjunto de diagramas de bloques estaticos con sus interfaces, agrupados en subsistemas. Estos diagramas de bloques se corresponden di rectamente con una versién simplificada de los diagramas de clases 0 paquetes de UML —sim- plifieados en que slo mostraban las asociaciones que se utilizaban para comunicaciones. El primer producto del trabajo de las actividades de disefio era una descripcién de arquitec- ura software. Se basaba en la comprensién de los tequisitos més criticos, y deseribia breve- mente cada bloque y su agrupamiento en subsistemas. Un conjunto de diagramas de bloques describian a los bloques y a sus interconexiones. Sobre las interconexiones se comunicaban se- jiales, es decir, un tipo de mensaje. Todos los mensajes quedaban descritos, uno por uno, en una biblioteca de mensajes. La descripcidn de la arquitectura software y la biblioteca de mensajes eran los documentos fundamentales que guiaban el trabajo de desarrollo, pero también se utili- in para presentar el sistema a los clientes. En aquellos momentos (1968) los clientes no estaban acostumbrados a que les presentasen los productos software por medios similares a los datos de proyectos de ingenierfa Para cada caso de uso, los ingenieros preparaban bien un diagrama de secuencia o bien un diagrama de colaboracién (hoy desarrollados adicionalmente en UML). Estos diagramas mos traban cémo los bloques se comunicaban dindmicamente para llevar a cabo el caso de uso. Pre- paraban una especificacién en forma de grafo de estados (que inclufa s6lo estados y transiciones) y un grafo de transicién de estados (una versién simplificada de los diagramas de actividad de UML), Este método, el disefiar a partir de bloques con interfaces bien definidos, fue la clave del éxito. De ese modo, se podia crear una nueva configuracién del sistema —por ejemplo, para un cliente nuevo —intercambiando un bloque por otro que proporcionase las mismos interfacXX PREFACIO| Por tanto, los bloques no eran s6lo subsistemas y componentes de e6digo fuente; se compi- laban en bloques ejecutables, se instalaban en La maquina destino uno por uno, y se comproba- ba que funcionaban con el resio de Ios blogues ejecutables. Es mis, debia ser posible instalar cada bloque ejecutable, nuevo 0 modificado, sobre la marcha en un sistema en ejecucién, mientras éste gestionaba Ilamadas de sistemas de telefonia en operacién durante el 100 por ciento del tiempo. No se puede parar sistemas de ese tipo s6lo para hacer cambios. Serfa como, cambiar las ruedas a un coche que circula a 100 kilémetros por hora En esencia, el método que utilizaban era el que hoy conocemos como desarrollo hasado en componentes. Ivar Jacobson fue el creador de este método de desarrollo. £ dirigié su evolucién hacia un proceso de desarrollo de software durante muchos aiios en el periodo anterior a Objectory. El Lenguaje de Descripcién y Especificacién Un avance significativo durante este periodo fue la publicacién en 1976 por parte del CCITT, el organismo internacional para la estandarizaci6n en el area de las telecomunicaciones, del Len- guaje de Especificacién y Descripcién (Specification and Description Language, SDL) para el comportamiento funcional de los sistemas de telecomunicacién, Este estindar, influenciado sig nificativamente por el método de Eriesson, es ba un sistema como un conjunto de blo- ques interconectados que se comunicaban unos con otros Gnicamente a través de mensajes (Itamados “sefiales” en el estindar). Cada bloque posefa un conjunto de “procesos”, que era el término SDL para designar las clases activas. Un proceso posefa instancias de manera muy pa- recida a cémo lo hacen las clases en términos de oris 1 objetos, Las instancias de los pro- cesos interactuaban mediante mensajes. SDL propor nas que cran especializaciones de Jo que hoy UML Ilama diagramas de clases, diagramas de actividad, diagramas de colaboracién ydi gramas de Secuencia. Por tanto, SDL era un estindar de modelado de objetos especializado. Se actualiza periddi- camente, y todav{a lo utilizan mas de 10.000 desarrolladores y cuenta con el soporte de varios fabricantes de herramientas. Fue desarrollado inicialmente hace veinte alos, y estaba muy por delante de su tiempo. Sin embargo, se desarrollé en un momento en el cual el modelado de ob- jetos no habia madurado. Probablemente, SDL seré sustituido por UML, que se estandarizé en 1997. Objectory En 1987 Ivar Jacobson dejé Eriesson y fuundé Objectory AB en Estocolmo, Durante tos si- guicntes ocho afios, él y sus colaboradores desarrollaron un proceso denominado Objectory (Objectory” es una abreviatura de “Object Factory”, fbrica de objetos). Extendieron su uso en otras industrias adem de las de telecomunicaciones, y en otros patses aparte de Suiza. Aungue el concepto de caso de uso habia estado presente en el trabajo de Ericsson, ahora se Je habia dado un nombre (que se presents en la conterencia OOPSLA de 1987), se habia desa- rrollado una técnica de representacién, y la idea se habfa ampliado para abarcar una variedad de aplicaciones. Es decir, los casos de uso que dirigfan el desarrollo se hicieron mas claros. Dicho de otro modo, la arquitectura que conduce a los desarrolladores ¢ informa a los usuarios co- menzé a destacar.PREFACIO. XT Los flujos de trabajo sucesivos se representaron en una serie de modelos: requisitos-casos de uso, andlisis, disefto, implementaci6n y prueba. Un modelo es una perspectiva del sistema, Las relaciones entre los modelos de esta serie eran importantes para los desarrolladores como forma de hacer el seguimiento de una caracteristica de un extremo a otro de la serie de modelos. De he- cho, la trazabilidad se convirtié en un pretrequisito del desarrollo dirigido por casos de uso. Los desarrolladores podian seguir la traza de un caso de uso a través de la secuencia de modelos has- ta el cédigo fuente o bien, cuando surgian problemas, volver hacia atré El desarrollo del proceso Objectory continus en una serie de versiones, desde Objectory 1.0 en 1988 « la primera versi6n interactiva, Objectory 3.8, en 1995 (puede consultarse una visi6n general de Objectory en [2}). Es importante hacer notar que el propio producto Objectory Hegé a ser visto como un siste- ma, Esta forma de descrihir un proceso —como un producto en forma de sistema— proporcio- haba una manera mejor de desarrollar una nueva versién de Objectory a partir de una anterior Este modo de desarrollar Objectory hizo mis facil el ajustarlo para cubrir las necesidades es- pecificas de diferentes organizaciones de desarrollo. El hecho de que el propio proceso de de- surtollo de software Objectory era un producto de ingenierfa era una caracteristica tinica, La experiencia en el desarrollo de Objectory también aports ideas sobre e6mo diseftar los procesos generules sobre los cuales opera un negocio. Eran aplicables los mismos principios y estos se recogieron en un libro en 1995 [3] El método de Rational Rational Software Corporation compré Objectory AB a finales de 1995 y la tarea de unificar los Principios bisicos subyacentes en los procesos de desarrollo existentes adquirié una ungencia es- pecial. Rational habéa desarrollado algunas prcticas de desarrollo de software, la mayoria de ellas complementarias a las contenidas en Objectory. Por cjemplo, como recordaron James E. Archer Junior y Michael T. Devlin en 1986 [4]. “En 1981, Rational se dispuso a crear un entorno interactivo que mejorarfa la productividad en el de- sarrollo de grandes sistemas software”. A continuacién dijeron que en este esfuerzo, eran niportantes el disco orientade a objetos, la abstraceidn, la ocultaciGn de ta informaciGn, lar tilizacién y el prototipado. Muchos libros, articulos y documentos internos detallan los desarrollos de Rational desde 1981. pero quiza las dos contribuciones mas importantes al proceso fueron los énfasis en la arquitectura y en el desarrollo iterativo, Por ejemplo, en 1990, Mike Devlin escribié un artic lo introductorio sobre un proceso de desarrollo iterativo dirigido por la arquitectura. Philippe Kruchten, a cargo de la divisidn de Pricticas de Arquitectura en Rational, firmé articulos sobre la iteraci6n y la arquitectura, Mencionaremos uno de ellos, un articulo sobre una representaci6n de la arquitectura con cua tro vistas: la vista légica, la vista de procesos, la vista fisica, y la vista de desarrollo, mas una vis- ta adicional que ilustraba las primeras cuatro vistas mediante casos de uso 0 escenarios [6]. La idea de tener un conjunto de vistas, en lugar de tratar de meter todo en un Gnico tipo de diagra- ma. nacié de la experiencia de Kruchten en varios proyectos grandes, Las vistas multiples permitieron encontrar, tanto a los usuarios como a los desarrolladores, lo que necesitaban para sus diferentes objetivos con la vista adecuada,