El Proceso Unificado de Desarrollo - Jacobson Et Al

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-3794046EL 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 PlainsNE 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 tineContenido 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 15vi 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 5045. 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 lLVII 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 177CONTENIDO 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 257X — 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 - 304CONTENIDO 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 requisitosxi 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 343CONTENIDO 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 403XIV 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 ... 435Prefacio 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 personas y empresas que han contribuido a UML, asf como un niimero significativo de aportaciones 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 queremos 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 salida 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 calidad. 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 diagramas 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 trabajadores 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 momentoPREFACIO. 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 desarrollador 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 riesgo 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 completo 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, andlisis 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 modelado 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 (realmente 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 productos, 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 brevemente 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 interfacXX 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 bloques 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 procesos 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 objetos 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 desarrollado 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 hecho, 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 hasta 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 sistema, 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 especificas 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 especial. 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 desarrollo 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 vista 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 diagrama. 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,XXU PREFACIO Hay gente que percibe el desarrollo iterativo como algo castico 0 anérquico. Bl método de cuatro fases (comienzo, elaboracidn, construccin y transicién) se disefié para estructurar mejor y controlar el proceso durante las iteraciones. La planificaci6n detallada de las fases y Ia orde- nacidn de las iteraciones dentro de las fases fue un esfuerzo conjunto entre Walker Royce y Rich Reitman, junto con la participacién continua de Grady Booch y Philippe Kruchten, Booch estaba presente desde los principios de Rational, y en 1996 en uno de sus libros men- cion6 dos “principios fundamentales” sobre fa arquitectura y la iteracién + °Un estilo de desarrollo dirigido por la arquitectura es normalmente la mejor aproximaci para la creacién de la mayoria de los proyectos complejos muy basados en el software.” + “Para que un proyecto orientado a objetos tenga éxito, debe aplicarse un proceso iterativo e incremental.” (7] El Proceso Objectory de Rational: 1995-1997 El Lenguaje Uni En el momento de la fusién, Objectory 3.8 habfa demostrado que se puede crear y modelar un proceso de desarrollo software como si fuese un producto. Habja disefiado la arquitectura original de un proceso de desarrollo software. Habia identificado un conjunto de modelos que documentaban el resultado del proyecto. Estaba correctamente desarrollado en areas como el modelado de casos de uso, andlisis y disefio, aunque en otras areas —gestidn de requisitos aparte de los casos de uso, implementacién y pruebas—no estaba tan bien desarrollado. Ademas, decia poco sobre gestién del proyecto, gestidn de la configuracién, distribucién, y sobre la preparacién del entorno de desarrollo (obtencién del proceso y las herramientas), Por ello se le atadieron la experiencia y précticas de Rational para formar el Proceso Objectory de Rational 4.1. Se afiadieron, en concreto, las fases y la aproximacién iterativa con- rrolada. Se hizo explicita la arquitectura en forma de una descripcién de ta arquitectura —la iblia”™ de la organizaci6n de desarrollo de software Se desarrollé una definicidn precisa de Ia arquitectura, considerada como lt parte mas sig- nificativa de la organizacién del sistema. Representaba la arquitectura como vistas arquitects- nicas de los modelos. Se amplié el desarrollo iterativo, pasando de ser un concepto relativamente general a ser un método dirigido por los riesgos que consideraba la arquitectura en primer lugar. En estos momentos, UML estaba en fase de desarrollo y se incorporé como el lenguaje de modelado de! Proceso Objectory de Rational (Rational Objectory Process, ROP). Los autores de este libro colaboraron como creadores originales de UML. E] equipo de desarrollo del proceso, liderado por Philippe Kruchten, corrigid algunas de tas debilidades del ROP reforzando, por ejemplo, la gestién del proyecto, basada en aportaciones de Royce [8]. ado de Modelado Era evidente desde hace algtin tiempo Ia necesidad de un lenguaje de modelado visual y con- sistente, en el cual expresar los resultados de las bastante numerosas metodologias de orientacién a objetos existentes a principios de los noventa, Durante este petiodo, Grady Booch, por ejemplo, era el autor del método Booch [9], y James Rumbaugh era el desarrollador principal de OMT (Object Modelling Technique) (10] creado enPREFACIO. XXIII el Centro de Investigacién y Desarrollo de General Electric. Cuando este timo se incorpors a Rational en Octubre de 1994, los dos comenzaron el trabajo de unificar sus métodos, en coor dinacién con muchos de los clientes de Rational. Publicaron la versién 0.8 del Método Unificado en Octubre de 1995, casi en el mismo momento de la incorporacién de Ivar Jacobson a Rational. Los tres, trabajando juntos, publicaron la versién 0.9 del Lenguaje Unificado de Modelado, El esfuerzo se amplié para incluir a otros metodologistas, asf como a diversas empresas, que in- clufan a IBM, HP y Microsoft, cada una de las cuales contribuyé al esténdar en evolucién. En noviembre de 1997, después de pasar por el proceso de estandarizaciGn, el Object Management Group publics como esténdar la versi6n 1.1 del Lenguaje Unificado de Modelado. Remitimos a la Guia de Usuario (11) y al Manual de Referencia |12) para obtener informacién detallada. El Proceso Objectory de Rational utiliz6 UML en todos sus modelos, El Proceso Unificado de Rational Durante este periodo, Rational compré o se fusioné a otras empresas fabricantes de herramientas. Cada una de ellas aport6 a la mezcla su experiencia en dreas del proceso que ampliaron mas atin el proceso Ohjectory de Rational + Requisite Inc, aports su experiencia en gestién de requisitos + SQA Inc, habia desarrollado un proceso de prueba para acompafar a su producto de pruebas, y lo ailadié a la ditatada experiencia de Rational en este campo. * Pure-Atria aiadié su experiencia en gestién de configuracién a la de Rational. + Performance Awareness aftadié las pruebas de rendimiento y las de carga. + Vigortech afiadié su experien: a en ingenierfa de datos. El proceso también se ampli6 con un nuevo flujo de trabajo para el modelado del negocio, basado en [3], que se utiliza para obtener los requisitos a partir de los procesos de negocio que el software va a cubrit. También se extendié con diseiio de interfaces de usuario dirigido por los casos de uso (basado en el trabajo de Objectory AB). A mediados de 1998 el Proceso Objectory de Rational se habia convertido en un proceso hecho y derecho, capaz de soportar el ciclo de vida del desarrollo en su totalidad, Para ello, in- tegraba una amplia variedad de aportaciones, no s6lo de los tres autores de este libro, sino de muchas fuentes sobre las cuales sobre las cuales se basaron Rational y UML. En junio, Rational Publics una nueva versidn del producto, el Proceso Unificado de Rational 5.0 [13]. En ese momento, por primera vez, se pusieron a disposicién del péblico en general muchos elementos de ese proceso propietario a través de este libro, El cambio de nombre refleja el hecho de que la unificacién ha tenido lugar en muchas di- mensiones: unificaci6n de técnicas de desarrollo, a través del Lenguaje Unificado de Modelado, Y unificacién del trabajo de muchos metodologistas —no slo en Rational sino también en las. ficinas de los cientos de clientes que Hevaban utilizando el proceso muchos afios, Agradecimientos Un proyecto de esta magnitud es el fruto del trabajo de mucha gente, y nos gustaria dar las gracias personalmente a tantos como sea posible,XXIV PREFACIO Por aportaciones a este libro Birgitte Lonvig prepars el ejemplo del sistema Interbank y lo desarroll6 en todos los modelos. Este es el ejemplo principal que utilizamos a lo largo del libro. Patrik Jonsson extrajo material de la documentacién del Proceso Objectory de Rational y lo dispuso en el orden de los capitulos propuestos. También ayuds en la preparacién de los ejemplos, aportando muchas ideas sobre Ia mejor manera de presentar el Proceso Unificado. Ware Myers participé en el desarrollo de este libro desde ef esquema inicial en adelante. Con- virti6 los primeros borradores preparados por el autor principal en prosa inglesa més legible. De los revisores agradecemos especialmente a Kurt Bittner, Cris Kobryn y Earl Ecklund, Jr Ademis, agradecemos prineipalmente las revisiones de Walker Royce, Philippe Kruchten, Dean Leffingwell, Martin Griss, Maria Ericsson y Bruce Katz. También fueron revisores Pete MeBreen, Glenn Jones, Johan Galle, N. Venu Gopal, David Rine, Mary Loomis, Marie Lenzi, Janet Gardner, y algunos revisores andnimos, a todos los cuales queremos dar las gracias. Terry Quatrani de Rational mejoré el inglés de los Capitulos 1 al 5. Karen Tor el libro entero. Nuestros agradecimientos para ambos, h corrigis, Queremos dar las gracias en particular a Stefan Bylund que revis6 a conciencia los borradores y sugirié mejoras detalladas, muchas de las cuales se han incorporado. Sus aportaciones, han aumentado considerablemente la calidad del libro. Durante los afos ‘También queremos dar las gracias a bastantes personas que nos han ayudado a “mantener al dia el proceso” y que han apoyado el trabajo de diversas maneras. En concreto, queremos dar las gracias a las siguientes personas: Stefan Ahlquist, Ali Ali, Gunilla Andersson, Kjell S. Andersson, Sten-Erik Bergner, Dave Bernstein, Kurt Bittner, Per Bjork, Hans Brandtberg, Mark Broms, Stefan Bylund, Ann Carlbrand, Ingemar Carlsson, Margaret Chan, Magnus Christerson, Geoff Clemm, Catherine Connor, Hakan Dahl, Stephane Desjardins, Mike Devlin, Hakan Dyrhage, Susanne Dyrhage, Staffan Ehnebom, Christian Ehrenborg, Maria Eriesson, Gunnar M. Eriksson, lain Gavin, Carlo Goti, Sam Guckenheimer, Bjorn Gullbrand, Sunny Gupta, Marten Gustafsson, Bjorn Gustafsson, Lars Hallmarken, David Hanslip, Per Hedfors, Barbara Hedlund, Jorgen Hellberg, Joachim Herzog, Kelli Houston, Agneta Jacobson, Sten Jacobson, Paer Jansson, Hakan Jansson, Christer Johansson, Ingemar Johnsson, Patrik Jonsson, Dan Jonsson, Bruce Katz, Kurt Katzeff, Kevin Kelly, Anthony Kesterton, Per Kilgren, Ru- di Koster, Per Kroll, Ron Krubeck, Mikael Larsson, Bud Lawson, Dean Leffingwell, Rolf Leidhammar, Hakan Lidstrom, Lars Lindroos, Fredrik Lindstrom, Chris Littlejohns, Andrew Lyons, Jas Madhur, Bruce Malasky, Chris McClenaghan, Christian Meck, Sue Mickel, Jorma Mobrin, Christer Nilsson, Rune Nilsson, Anders Nordin, Jan-Erik Nordin, Roger Oberg, Benny Odenteg, Erik Ornulf, Gunnar Overgaard, Karin Palmkvist, Fabio Peruzzi, Janne Pettersson, Gary Pollice, Tonya Prince, Leslee Probasco, Terry Quatrani, Anders Rockstrom, Walker Royce, Goran Schefte, Jeff Schuster, John Smith, Kjell Sorme, lan Spence, Bir- gitta Spiridon, Fredrik Stromberg, Goran Sundelof, Per Sundquist, Per-Olof Thysselius, Mike ‘Tudball, Karin Villers, Ctirad Vrana, Stefan Wallin, Roland Wester, Lars Wetterborg, Brian White, Lars Wiktorin, Charlotte Wranne, y Jan Wunsche,PREFACIO -XXV ‘Ademés, las siguientes personas han ofrecido al autor principal su apoyo personal durante ‘afos, por lo cual me siento muy agradecido: Dines Bjorner, Tore Bingefors, Dave Bulman, Larry Constantine, Goran Hemdal, Bo Hedfors, Tom Love, Nils Lennmarker, Lars-Olof Noren, Dave ‘Thomas, y Lars-Erik Thorelli Por ultimo, queremos dar las gracias en particular ‘A Mike Devlin, presidente de Rational Software Corporation, por su confianza en el proceso Objectory como un producto que ayudard a todos los desarrolladores de software del mundo, y or su apoyo constante en el uso de un proceso de software eficaz como guia para el desarrollo de herramientas. Y por tiltimo, queremos dar las gracias a Philippe Kruchten, director del Proceso Unificado de Rational, y a todos los miembros del equipo del proceso Rational por haber integrado lo mejor de Objectory con las mejores técnicas le Rational y con UML, manteniendo a la ver. sus. valores individuales. Ademas, no podsfamos haber conseguido este objetivo sin contar con el compromiso personal de Philippe y con su perseverancia en la tarea de construir, sencillamen- te, el mejor proceso de software nunca visto en el mundo. El proceso se abre camino A lo largo de este libro, y del resto de los libros, versiones interactivas y herramientas relacio- nados, el proceso de desarrollo de software se hace mayor. El Proceso Unificado tomé su ins- piracis ‘én de muchas fuentes, y ya esta ampliamente difundido. Proporciona un sustruto comin de comprensién del proceso del cual pueden partir los desarrolladores, los directores y Jos usuarios. Todavfa queda mucho trabajo por hacer. Los desarrolladores deben aprender maneras uni- ficadas de trabajar. Los clientes y los directivos deben apoyarlas. Para muchas empresas de desurrollo, el adelanto es slo potencial. Usted puede hacerlo real, Ivar Jacobson Palo Alto, California Diciembre de 1998 ivar@rational.com Referencias [1] Peter F. Drucker, “The Discipline of Innovation,” Harvard Business Review, May-lune, 1985: reprinted Nov.-Dec. 1998, pp. 149-157. {2} Ivar Jacobson, Magnus Christerson, Patrik Jonsson, and Gunnar Overgaard, Object- Oriented Software Engineering: A Use-Case Driven Approach, Reading, MA: Addison- Wesley, 1992 [3] Ivar Jacobson, Maria Ericsson, and Agneta Jacobson, The Object Advantage: Business Process Reengineering with Object Technology, Reading, MA: Addison-Wesley, 1995. [4] James E. Archer Jr. and Michael T. Devlin, “Rational’s Experience Using Ada for Very Large Systems,” Proceedings of the First International Conference on Ada Programming Language Applications for the NASA Space Station, Tune, 1986.XXVI PREFACIO, [6] Philippe B. Kruchten, “The 4 + 1 View Model of Architecture”, /EEE Software, November 1995, pp. 42-50. 17] Grady Booch, Object Solutions: Managing the Object-Oriented Project, Reading, MA: Addison-Wesley, 1996. [8] Walker Royce, Software Project Management: A Unified Framework, Reading, MA: Addison-Wesley, 1998 [9] Grady Booch, Object-Oriented Analysis and Design with Applications, Redwood City, CA: Benjamin/Cummings, 1994 [10] James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy, and William Lorensen, Object-Oriented Modeling and Design, Englewood Cliffs, NJ: Prentice Hall, 1991. [11] Grady Booch, James Rumbaugh, and Ivar Jacobson, The Unified Modeling Language User Guide, Reading, MA: Addison-Wesley, 1998, [12] James Rumbaugh, Ivar Jacobson, and Grady Booch, The Unified Modeling Language Reference Manual, Reading, MA: Addison-Wesley, 1998, [13] Philippe Kruchten, The Rational Unified Process: An Introduction, Reading, MA: Addison-Wesley, 1998. [14] Ivar Jacobson, Concepts for Modeling Large Real Time Systems, Chapter 2, Dissertation, Department of Computer Systems, The Royal Institute of Technology, Stockholm, Sept. 1985. [15] Ivar Jacobson, “Object-Orientation as a Competitive Advantage”, American Programmer, Oct. 1992. {16] Ivar Jacobson, “A Large Commercial Success Story with Objects, Succeeding with Ob- jects”, Object Magazine, May 1996.Parte I El! Proceso Unificado de Desarrollo de Software est Parte [ presentamos las ideas fundamentales. E El Capitulo 1 describe el Proceso Unificado de Desarrollo de Software brevemente, centrandose en su caricter dirigido por los casos de uso, centrado en la arquitectura, iterativo & incremental. EI proceso utiliza el Lenguaje Unificado de Modelado (UML), un lenguaje que pro- Guce dibujos comparables en sus objetivos a los esquemas que se utilizan desde hace mucho tiempo en otras disciplinas técnicas. El proceso pone en préctica el basar gran parte del proyecto de desarrollo en componentes reutilizables, es decir, en piezas de software con una interfaz bien definida. El Capitulo 2 introduce las cuatro “P”: personas, proyecto, producto, y proceso, y describe sus relaciones, que son esenciales para la comprensi6n del resto del libro. Los conceptos clave necesarios para comprender el proceso que cubre este libro son: artefacto, modelo, trabajador y flujo de trabajo. El Capitulo 3 trata el concepto de desarrollo dirigido por casos de uso con mayor detalle. Los ‘casos de uso son tun medio para determinar los requisitos correctos y utilizarlos para condueir el proceso de desarrollo. El Capitulo 4 describe el papel de la arquitectura en el Proceso Unificado. La arquitectura establece lo que se tiene que hacer; esquematiza los niveles significativos de la organizacién del software y se centra en el armazén del sistema, FI Capitulo 5 enfatiza la importancia de adoptar una aproximacién iterativa e incremental en el desarrollo de software. En la prictica, esto se traduce en atacar primero las partes del sistema2 BL PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE cargadas de riesgo, obteniendo pronto una arquitectura estable, y completando después las partes mis rutinarias en iteraciones sucesivas, cada una de las cuales lleva a un ineremento del progreso hasta la versién final En la Parte II profundizaremos mds. Dedicamos un capitulo a cada flujo de trabajo funda- yental: requisitos, andlisis, disento, implementacion y prueba, Estos flujos de trabajo se utilizar‘in después en la Parte III como actividades importantes en los diferentes tipos de iteracién durante las cuatro fases en las que dividimos el proceso. En la Parte TIT desertbimos en conereto cdmo se Heva a cabo el trabajo en cada fase: en la de inicio para obtener un aniilisis del negocio, en la de elaboracidn para crear la arquitectura y hacer un plan, en la de construccién para aumentar la arquitectura hasta conseguir un sistema entregable, y en la de transicién para garantizar que cf sistema funciona correctamente en el entorno del usuario, En esta parte, volvemos a utilizar los flujos de trabajo fundamentals y los combinamos de un modo ajustado # cada fase de manera que seamos capaces de aleanzar los resultados deseados, La intenci6n subyacente de una organizacién no es, sin embargo, tener un software bueno, sino administrar sus procesos de negocio, o sistemas empotrados, de forma que le permita producir rapidamente bienes y servicios de alta calidad con costes razonables, en respuesta a las. demandas del mercado. El software es el arma estratégica con el cual las empresas o los go- biernos pueden conseguir enormes reducciones en costes y tiempos de produecién tanto par bienes como para servicios. Es imposible reaccionar con rapidez frente al dinamismo del mercado sin unos buenos procesos de organizacién establecidos. En el entorno de una economi global que opera veinticuatro horas al dfa, siete dias a la semana, muchos de esos procesos no pueden funcionar sin el software. Un buen proceso de desarrollo de software es, por tanto, un elemento critico para el éxito de cualquier organizacién.Capitulo 1 El Proceso Unificado: dirigido por casos de uso, centrado en la arquitectura, iterativo e incremental complejos. Esto es debido en parte al hecho de que los computadores son mas potentes cada aio, y los usuarios, por tanto, esperan mas de ellos. Esta fendencia también se ha vis- to afectada por el uso creciente de Internet para el intercambio de todo tipo de informacién —de texto sin formato a texto con formato, fotos, diagramas y multimedia, Nuestro apetito de software ain més sofisticado crece a medida que vemos cémo pueden mejorarse los productos de una versin a otra, Queremos un sofiware que esté mejor adaptado a nuestras necesidades, pero esto, a su vez, simplemente hace el software més complejo. En breve, querremos mis. | a tendencia actual en el software Heva a la construccién de sistemas més grandes y mas ‘También Io queremos més rapido. El tiempo de salida al mercado es otro conductor importante. Conseguirlo, sin embargo, es dificil. Nuestra demanda de software potente y complejo no se corresponde con como se desarrolla el software. Hoy, la mayoria de la gente desarrolla software mediante los mismos métodos que llevan utilizandose desde hace 25 afios. Esto es un problema. A menos que renovemos nuestros métodos, no podremos cumplir con el objetive de desarrollar el software complejo que se necesita actualmente. EI problema del software se reduce a la dificultad que afrontan los desarrolladores para coordinar las méltiples cadenas de trabajo de un gran proyecto de software. La comunidad de desarrolladores necesita una forma coordinada de trabajar. Necesita un proceso que integre las niltiples facetas del desarrollo, Necesita un método comiin, un proceso que:4) EL PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE 1.1. * Proporcione una guia para ordenar las actividades de un equipo. * Dirija las tareas de cada desarrollador por separado y del equipo como un todo. + Especifique los artefactos que deben desarrollarse. * Ofrezea criterios para el control y fa mediciGn de los productos y actividades del proyecto. La presencia de un proceso bien definido y bien gestionado es una diferencia esencial entre proyectos hiperproductivos y otros que fracasan. (Véase la Seccidn 2.4.4 para més motivos por los cuales es necesario un proceso.) El Proceso Unificado de Desarrollo —el resultado de mas de 30 afios de experiencia— es una solucién al problema del software. Este capitulo proporciona una visiGn general del Proceso Uniticado completo. En posteriores capitulos, examinaremos cada elemento del proceso en detalle. El Proceso Unit icado en pocas palabras En primer lugar, e! Proceso Unificado es un proceso de desarrollo de software. Un proceso de desarrollo de software es el conjunto de actividades necesarias para transformar los requisitos de Un usuario en un sistema software (véase la Figura 1.1), Sin embargo, el Proceso Unificado es mas que un simple proceso: es un marco de trabajo genérico que puede especializarse para una gran variedad de sistemas software, para diferentes areas dle aplicacién, diferentes tipos de or- gunizaciones, diferentes niveles de aptitud y diferentes tamaiios de proyecto, El Proceso Unificado esta basudo en componentes, lo cual quiere decir que el sistema software en construccidn estd formado por componentes software (Apéndice A) interconectados a través de interfaces (Apéndice A) bien definidas, EI Proceso Unificado utiliza el Lenguaje Unificado de Modelado (Unified Modeling Lan- guage, UML) para preparar todos los esquemas de un sistema software. De hecho, UML es una parte esencial del Proceso Unificado —sus desarrollos fueron paralelos. No obstante, los verdaderos aspectos definitorios del Proceso Unificado se resumen en tres frases clave —dirigido por casos de uso, centrado en la urquitectura, e iterativo e incremental. Esto es lo que hace tinico al Proceso Unificado. En las tres secciones siguientes describiremos esas tes frases clave. Después, en el resto del capitulo, daremos una breve visién general del proceso: su ciclo de vida, fases, versiones, iteraciones, flujos de trabajo, y artefactos. Toda la motivacién de este capftulo es la de presentar las ideas més importantes y dar una “vista de péjaro” del proceso en su totalidad. Después de este capitulo, el lector deberia conocer, pero no necesariamente comprender en su totalidad, de Qué trata el Proceso Unificado. Ei resto del libro cubrira los detalles. En el Capitulo 2 estable- cemos el contexto de las cuatro “P* del desarrollo de software: personas, proyecto, producto ¥ proceso, Después, dedicamos un capitulo a cada una de las tres ideas clave antes mencionadas. Todo esto constituird la primera parte del libro, Las Partes Il y IIT —el grueso del libro— describirsin los distintos flujos de trabajo del proceso en detalle. —— Proceso de desarrollo equistos de Software dl usuario Figura 11. Un proceso de desarrollo de software.EL PROCESO UNIFICADO: DIRIGIDO POR CASOS DE USO, CENTRADO EN LA ARQUITECTURA... 5 1.2. El Proceso Unificado esta dirigido por casos de uso Un sistema software ve la luz. para dar servicio a sus usuarios. Por tanto, para construir un tema con éxito debemos conocer lo que sus futuros usuarios necesitan y desean. El término usuario no sélo hace referencia a usuarios humanos sino a otros sistemas. En este sentido, el término usuario representa alguien o algo (como otro sistema fuera del sistema en consideracién) que interactia con el sistema que estamos desarrollando. Un ejemplo de inte~ raccién seria una persona que utiliza un cajero automatico. B (0 ella) inserta la tarjeta de pla tico, responde a las preguntas que le hace Ia maquina en su pantalla, y recibe una suma de dinero. En respuesta a la tarjeta del usuario y a sus contestaciones, el sistema lleva a cabo una secuencia de acciones (Apéndice A) que proporcionan al usuario un resultado importante, en este caso, la retirada del efectivo. Una interacci6n de este tipo es un caso de uso (Apéndice A; véase también el Capitulo 3). Un caso de uso es un fragmento de funcionalidad del sistema que proporciona al usuario un resultado importante. Los casos de uso representan los requisitos funcionales. Todos los casos de uso juntos constituyen el modelo de casos de uso (Apéndice B; véase también la Seccién 2.3), el cual describe la funcionalidad total del sistema. Puede decirse que una especiticaci6n fun- ional contesta a la pregunta: ;Qué debe hacer el sistema?. La estrategia de los casos de uso puede describirse afiadiendo tres palabras al final de esta pregunta: ;...para cada usuario? Estas tres palabras albergan una implicaci6n importante. Nos fuerzan a pensar en términos de importancia para el usuario y no sélo en términos de funciones que seria bueno tener. Sin embargo, los casos. de uso no son sélo una herramienta para especificar los requisitos de un sistema. También guian su disefo, implementacién, y prueba; esto es, guian el proceso de desarrollo. Basandose en el modelo de casos de uso, los desurrolladores crean una serie de modelos de disefio e im- plementacién que Ievan a cabo Jos casos de uso, Los desarrolladores revisan cada uno de los sucesivos modelos para que sean conformes al modelo de casos de uso. Los ingenieros de prueba prueban la implementacién para garantizar que los componentes del modelo de implementacion implementan correctamente los casos de uso. De este modo, los casos de uso no sélo inician el proceso de desarrollo sino que le proporcionan un hilo conductor. Dirigido por casos de uso quiere decir que el proceso de desarrollo sigue un hilo —avanza a través de una serie de flujos de trabajo que parten de los casos de uso. Los casos de uso se especifican, se disefian, y los ca~ sos de uso finales son la fuente a partir de la cual los ingenieros de prueba construyen sus casos. de prueba. Aunque es cierto que los casos de uso gufan el proceso, no se desarrollan aisladamente. Se desarrollan a la vez que la arquitectura del sistema. Es decir, los casos de uso gufan la arquitectura del sistema y la arquitectura del sistema influye en la seleccién de los casos de uso. Por tanto, tanto la arquitectura del sistema como los casos de uso maduran segtin avanza el ciclo de desarrollo. 1.3. El Proceso Unificado esta centrado en la arquitectura El papel de Ja arquitectura software es parecido al papel que juega la arquitectura en Ia cons- trucciGn de edificios. El edificio se contempla desde varios puntos de vista: estructura, servicios, conduccién de la calefaccién, fontanerfa, electricidad, etc. Esto permite a un constructor ver una imagen completa antes de que comience la construccién. Andlogamente, la arquitectura en un sistema software se describe mediante diferentes vistas del sistema en construccién.6 EL PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE El concepto de arquitectura software incluye los aspectos estiticos y dindmicos mas signi- ivos del sistema. La arquitectura surge de las necesidades de la empresa, como las perciben usuarios y los inversores, y se refleja en los casos de uso. Sin embargo, también se ve in- Aluida por muchos otros factores, como la plataforma en la que tiene que funcionar el software (arquitectura hardware, sistema operativo, sistema de gestién de base de datos, protacolos para comunicaciones en red), los bloques de construccién reutilizables de que se dispone (por ejemplo, un marco de trabajo (Apéndice C) para interfaces grificas de usuario), consideraciones de implantacién, sistemas heredados, y requisitos no funcionales (por ejemplo, rendimiento, fia- bilidad). La arquitectura es una vista del disefio completo con las caracteristicas mas importantes resaltadas, dejando los detalles de lado. Debido a que lo que es significative depende en parte de una valoracién, que a su vez, se adquiere con la experiencia, el valor de una arquitectura depende de las personas que se hayan responsabilizado de su creacién. No obstante, el proceso ayuda al arquitecto a centrarse en los objetivos adecuados, como la comprensibilidad, la capacidad de adaptaci6n al cambio, y la reutilizaci6n. 4 COmo se relacionan fos casos de uso y la arquitectura? Cada producto tiene tanto una fun- Gn como una forma. Ninguna es suficiente por si misma, Estas dos fuerzas deben equilibrarse para obtener un producto con éxito, En esta situacién, la funcién corresponde a los casos de uso y la forma a la arquitectura, Debe haber interaccidn entre los casos de uso y Ia arquitectura, Es un problema del tipo “el huevo y la gallina”. Por un lado, los casos de uso deben encajar en la arquitectura cuando se llevan a cabo. Por otro lado, la arquitectura debe permitir el desarrollo de todos los casos de uso requeridos, ahora y en el futuro. En realidad, tanto la arquitectura como los casos de uso deben evolucionar en paraleto, Por tanto, los arquitectos moldean el sistema para darle una forma. Es esta forn tectura, la que debe disefiarse para permitir que el sistema evolucione, no sélo en su desarrollo inicial, sino también a lo largo de Jas futuras generaciones. Para encontrar esa forma, los ar- -ctos deben trabajar sobre la comprensién general de las funciones clave, es decir, sobre los casos de uso claves del sistema, Estos casos de uso clave pueden suponer solamente entre el 5 y el 10 por ciemto de todos Jos casos de uso, pero son los significativos, los que constituyen lis funciones fundamentales del sistema. De manera resumida, podemos decir que el arquitecto. Ja arqui- * Crea un esquema en borrador de la arquitectura, comenzando por la parte de la arquitectura que no es especifica de los casos de uso (por ejemplo, la plataforma). Aunque esta parte de la arquitectura es independiente de fos casos de uso, el arquitecto debe poseer una comprensién general de Jos casos de uso antes de comenzar la creacién del esquema arquitect6nico. * A continuacién, el arquitecto trabaja con un subconjunto de los casos de uso especificados, con aquellos que representen las funciones clave del sistema en desarrollo. Cada caso de seleccionado se especifica en detalle y se realiza en términos de subsistemas (Apén- dice A; véase también Secci6n 3.4.4), clases (Apéndice A), y componentes (Apéndice A). * A medida que los casos de uso se especifican y maduran, se descubre mas de la arquitec~ tura. Esto, a su vez, lleva a la maduracin de mas casos de uso. Este proceso contintia hasta que se considere que la arquitectura es estable. 1.4. El Proceso Unificado es iterativo e incremental El desarrollo de un producto software comercial supone un gran esfuerzo que puede durar entre varios meses hasta posiblemente un aito 0 mas. Es priictico dividir el trabajo en partes masEL PROCESO UNIFICADO: DIRIGIDO POR CASOS DE USO, CENTRADO EN LA ARQUITECTURA.... 7 pequeiias © miniproyectos. Cada miniproyecto es una iteracién que resulta en un increment, Las iteraciones hacen referencia a pasos en el flujo de trabajo, y los incrementos, al crecimien- to del producto, Para una efectividad méxima, lus iteraciones deber estar controladas; esto es, deben seleccionarse y ejecutarse de una forma planificads. Es por esto por lo que son mini-proyectos. Los desarrolkadores basan la seleccién de lo que se implementaré en una iteraci6n en dos fac tores. En primer lugar, la iteracién trata un grupo de casos de uso que juntos amplfan la utilidad del producto desarrollado hasta ahora. En segundo lugar, la iteraci6n trata los riesgos mas importantes. Las iteruciones sucesivas se construyen sobre los artefactos de desarrollo tal como quedaron al final de la dltima iteraciGn, Al ser miniproyectos, comienzan con los casos de uso y continian a través del trabajo de desarrotio subsiguiente —andlisis, disefio, implementaci6n y prueba—, que termina convirtiendo en cédigo ejecutable los casos de uso que se desarrollaban en la iteracién. Por supuesto, un incremento no necesariamente es aditivo. Especialmente en las primeras fases del ciclo de vida, los desarrolladores pueden tener que reemplazar un disefio superficial por uno mas dle- tallado 0 sofisticado. En fases posteriores, los inerementos son tipicamente aditivos. En cada iteracién, los desarrolladores identifican y especitican los casos de uso relevantes, crean un disefio utilizando la arquitectura seleccionada como gufa, implementan el disefio mediante componentes, y verifican que los componentes satisfacen los casos de uso. Si una itera cién cumple con sus objetivos —como suele suceder— el desarrollo continda con la siguiente iteraci6n. Cuando una iteraci6n no cumple sus objetivos, los desarrolladores deben revisar sus decisiones previas y probar con un nuevo enfoque Para alcanzar el mayor grado de economia en el desarrollo, un equipo de proyecto intentara seleccionar s6lo las iteraciones requeridas para lograr el objetivo del proyecto. Intentard se- cuenciar las iteraciones en un orden Idgico. Un proyecto con éxito se ejecutard de una forma directa, s6lo con pequeitas desviaciones del curso que los desarrolladores planificaron ini- jalmente. Por supuesto, en ki medida en que se afiadan iteraciones o se altere el orden de las mismas por problemas inesperados, el proceso de desarrollo consumira mas esfuuerzo y tiempo. Uno de los objetivos de la reduccisn del riesgo es minimizar los problemas inesperados. Son muchos los beneficios de un proceso iterative controlado: + La iteracién controlada reduce el coste del riesgo a los costes de un solo increment. Si los desurrolladores tienen que repetir la iteraci6n, la organizacidn sélo pierde el esfuerzo mal empleado de la iteracién, no el valor del producto entero, * La iteracién controlada reduce el riesgo de no sacar al mercado e! producto en el calendario previsto, Mediante la identificacidn de riesgos en fases tempranas del desarrollo, el tiempo que se gasta en resolverlos se emplea al principio de la planificacién, cuando la gente est menos presionada por cumplir los plazos. En el método “tradicional”, en el cual los problemas complicados se revelan por primera vez en la prueba del sistema, el tiempo ne- cesurio para resolverlos normalmente es mayor que el tiempo que queda en la planifica- in, y casi siempre obliga a retrasar la entrega, + La iteracién controlada acelera el ritmo det esfuerzo de desarrollo en su totalidad debido a que los desarrolladores trabajan de manera mds eficiente para obtener resultados claros a corto plazo, en lugar de tener un calendario largo, que se prolonga eternamente. * La iteracidn controlada reconoce una realidad que a menudo se ignora —que las necesidades del usuario y sus correspondientes requisitos no pueden definirse completamente al8 EL PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE 1.5. principio, Tipicamente, se refinan en iteraciones sucesivas. Esta forma de operar hace més fécil la adaptacisn a los requisitos cambiantes. Estos conceptos —los de desarrollo dirigido por los casos de uso, centrado en la arquitec~ tura, iterativo e ineremental— son de igual importancia. La arquitectura proporciona la estructura sobre la cual guiar las iteraciones, mieniras que los casos de uso definen los objetivos y dirigen el trabajo de cada iteraci6n. La eliminaciGn de una de las tres ideas reduciria drasti- camente el valor del Proceso Unificado, Es como un taburete de tres patas. Sin una de ellas, el taburete se cae, Ahora que hemos presentado los tres conceptos clave, es el momento de echar un vistazo al proceso en su totalidad, su ciclo de vida, artefactos, flujos de trabajo, fases e iteraciones. La vida del Proceso Unificado El Proceso Unificado se repite a lo largo de una serie de ciclos que constituyen Ia vida de un sistema, como se muestra en la Figura 1.2, Cada ciclo concluye con una versién del producto (Apéndice C; véase también el Capitulo 5) para los clientes. Cada ciclo consta de cuatro fases: inicio', elaboracién, construccién y transicién. Cada fase (Apéndice C) se subdivide a su vez.en iteraciones, como se ha dicho antériormente. Véase la Fi- gura 13. Nacimianto Muerte A Tape Los ciclos concluyen con una version Figura 1.2. La vida de un proceso consta de ciclos desde su nacimiento hasta su: muerte ‘Versiones. Figura 1.3. Un ciclo con sus fases eiteraciones, 1 del T. Tambien se sue ullizareltérming “fase de comiEL PROCESO UNIFICADO: DIRIGIDO POR CASOS DE USO, CENTRADO EN LA ARQUITECTURA.... 9 1.5.1. El producto Cada ciclo produce unt nueva version del sistema, y cada versidn es un producto preparado para su entrega. Consta de un cuerpo de cédigo fuente incluido en componentes que puede compi- larse y cjecutarse, ademas de manuales y otros productos asociados. Sin embargo, el producto terminado no s6lo debe ajustarse a las necesidades de los usuarios, sino también a las de todos los interesados. es decir, toda la gente que trabajaré con el producto. El producto software deberfa ser algo mas que el c6digo maquina que se ejecuta, El producto terminado incluye los requisitos, casos de uso, especificaciones no funcionales y casos de prueba. Incluye el modelo de la arquitectura y el modelo visual —artefactos mo- delados con el Lenguaje Unificado de Modelado. De hecho, incluye todos los elementos que hemos mencionado en este capitulo, debido a que son esos elementos los que permiten a los interesados— clientes, usuarios, analistas, diseftadores, programadores, ingenieros de prueba, y directores —especificar, disefar, implementar, probar y utilizar un sistema, Es mis, son esos elementos los que permiten a los usuarios utilizar y modificar el sistema de generacién en generacién, Aunque os componentes ejecutables sean los artefactos mas importantes desde a perspectiva del usuario, no son suficientes por sf solos. Esto se debe a que el entomo cambia, Se mejoran los, sistemas operatives, los sistemas de bases de datos y las méquinas que los soportan. A medida que el objetivo del sistema se comprende mejor, los propios requisitos pueden cambiar, De he- ccho, el que los requisitos cambien es una de las constantes del desarrollo de software, Al final, los desarrolladores deben afrontar un nuevo ciclo, y los directores deben financiarlo, Para llevar a cabo el siguiente ciclo de manera eficiente, los desarrolladores necesitan todas las represen- taciones del producto software (Figura 1.4) * wosgensee sae SE Oo. 2 ! woe dediveto =, =] vetiato por zl * | Ney] | vee
You might also like
Her Body and Other Parties: Stories
From Everand
Her Body and Other Parties: Stories
Carmen Maria Machado
Rating: 4 out of 5 stars
4/5 (821)
Sing, Unburied, Sing: A Novel
From Everand
Sing, Unburied, Sing: A Novel
Jesmyn Ward
4/5 (1104)
The Sympathizer: A Novel (Pulitzer Prize for Fiction)
From Everand
The Sympathizer: A Novel (Pulitzer Prize for Fiction)
Viet Thanh Nguyen
Rating: 4.5 out of 5 stars
4.5/5 (122)
Magazines
Podcasts
Sheet music
Devil in the Grove: Thurgood Marshall, the Groveland Boys, and the Dawn of a New America
From Everand
Devil in the Grove: Thurgood Marshall, the Groveland Boys, and the Dawn of a New America
Gilbert King
4.5/5 (266)
John Adams
From Everand
John Adams
David McCullough
4.5/5 (2409)
The Perks of Being a Wallflower
From Everand
The Perks of Being a Wallflower
Stephen Chbosky
4.5/5 (2104)
Brooklyn: A Novel
From Everand
Brooklyn: A Novel
Colm Toibin
3.5/5 (1946)
The Light Between Oceans: A Novel
From Everand
The Light Between Oceans: A Novel
M.L. Stedman
4.5/5 (789)
A Tree Grows in Brooklyn
From Everand
A Tree Grows in Brooklyn
Betty Smith
4.5/5 (1929)
A Man Called Ove: A Novel
From Everand
A Man Called Ove: A Novel
Fredrik Backman
4.5/5 (4610)
Fear: Trump in the White House
From Everand
Fear: Trump in the White House
Bob Woodward
3.5/5 (738)
Rise of ISIS: A Threat We Can't Ignore
From Everand
Rise of ISIS: A Threat We Can't Ignore
Jay Sekulow
3.5/5 (137)
Team of Rivals: The Political Genius of Abraham Lincoln
From Everand
Team of Rivals: The Political Genius of Abraham Lincoln
Doris Kearns Goodwin
4.5/5 (234)
Wolf Hall: A Novel
From Everand
Wolf Hall: A Novel
Hilary Mantel
4/5 (3811)
A Heartbreaking Work Of Staggering Genius: A Memoir Based on a True Story
From Everand
A Heartbreaking Work Of Staggering Genius: A Memoir Based on a True Story
Dave Eggers
3.5/5 (231)
The Woman in Cabin 10
From Everand
The Woman in Cabin 10
Ruth Ware
3.5/5 (2521)
Little Women
From Everand
Little Women
Louisa May Alcott
4/5 (104)
The Art of Racing in the Rain: A Novel
From Everand
The Art of Racing in the Rain: A Novel
Garth Stein
4/5 (4203)
Hidden Figures: The American Dream and the Untold Story of the Black Women Mathematicians Who Helped Win the Space Race
From Everand
Hidden Figures: The American Dream and the Untold Story of the Black Women Mathematicians Who Helped Win the Space Race
Margot Lee Shetterly
4/5 (897)
The Constant Gardener: A Novel
From Everand
The Constant Gardener: A Novel
John le Carré
3.5/5 (104)
The Outsider: A Novel
From Everand
The Outsider: A Novel
Stephen King
4/5 (1850)
The Unwinding: An Inner History of the New America
From Everand
The Unwinding: An Inner History of the New America
George Packer
4/5 (45)
Angela's Ashes: A Memoir
From Everand
Angela's Ashes: A Memoir
Frank McCourt
4.5/5 (440)
The Yellow House: A Memoir (2019 National Book Award Winner)
From Everand
The Yellow House: A Memoir (2019 National Book Award Winner)
Sarah M. Broom
4/5 (98)
Yes Please
From Everand
Yes Please
Amy Poehler
4/5 (1898)
The Emperor of All Maladies: A Biography of Cancer
From Everand
The Emperor of All Maladies: A Biography of Cancer
Siddhartha Mukherjee
4.5/5 (271)
The World Is Flat 3.0: A Brief History of the Twenty-first Century
From Everand
The World Is Flat 3.0: A Brief History of the Twenty-first Century
Thomas L. Friedman
3.5/5 (2259)
Manhattan Beach: A Novel
From Everand
Manhattan Beach: A Novel
Jennifer Egan
3.5/5 (792)
Shoe Dog: A Memoir by the Creator of Nike
From Everand
Shoe Dog: A Memoir by the Creator of Nike
Phil Knight
4.5/5 (537)
The Little Book of Hygge: Danish Secrets to Happy Living
From Everand
The Little Book of Hygge: Danish Secrets to Happy Living
Meik Wiking
3.5/5 (401)
The Glass Castle: A Memoir
From Everand
The Glass Castle: A Memoir
Jeannette Walls
4.5/5 (1716)
Grit: The Power of Passion and Perseverance
From Everand
Grit: The Power of Passion and Perseverance
Angela Duckworth
4/5 (590)
Elon Musk: Tesla, SpaceX, and the Quest for a Fantastic Future
From Everand
Elon Musk: Tesla, SpaceX, and the Quest for a Fantastic Future
Ashlee Vance
4.5/5 (474)
Bad Feminist: Essays
From Everand
Bad Feminist: Essays
Roxane Gay
4/5 (1016)
On Fire: The (Burning) Case for a Green New Deal
From Everand
On Fire: The (Burning) Case for a Green New Deal
Naomi Klein
4/5 (74)
The Subtle Art of Not Giving a F*ck: A Counterintuitive Approach to Living a Good Life
From Everand
The Subtle Art of Not Giving a F*ck: A Counterintuitive Approach to Living a Good Life
Mark Manson
4/5 (5807)
The Hard Thing About Hard Things: Building a Business When There Are No Easy Answers
From Everand
The Hard Thing About Hard Things: Building a Business When There Are No Easy Answers
Ben Horowitz
4.5/5 (346)
The Gifts of Imperfection: Let Go of Who You Think You're Supposed to Be and Embrace Who You Are
From Everand
The Gifts of Imperfection: Let Go of Who You Think You're Supposed to Be and Embrace Who You Are
Brené Brown
4/5 (1091)
Never Split the Difference: Negotiating As If Your Life Depended On It
From Everand
Never Split the Difference: Negotiating As If Your Life Depended On It
Chris Voss
4.5/5 (842)
Principles: Life and Work
From Everand
Principles: Life and Work
Ray Dalio
4/5 (599)
Steve Jobs
From Everand
Steve Jobs
Walter Isaacson
4.5/5 (806)
Economia - Sector Externo
Document19 pages
Economia - Sector Externo
Ivan Mok
No ratings yet
UML y Patrones
Document265 pages
UML y Patrones
Ivan Mok
No ratings yet
Economia - SectorPúblico
Document8 pages
Economia - SectorPúblico
Ivan Mok
No ratings yet
RESUMEN FINAL ACO vFINAL
Document44 pages
Ivan Mok
No ratings yet
Document45 pages
Ivan Mok
No ratings yet
Deserción Escolar en La Comunidad de Madrid
Document2 pages
Deserción Escolar en La Comunidad de Madrid
Ivan Mok
No ratings yet

El Proceso Unificado de Desarrollo - Jacobson Et Al

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

El Proceso Unificado de Desarrollo - Jacobson Et Al

Uploaded by

Copyright:

Available Formats

You might also like