Desarrolladores fae Metodos agiles Ce aaar » Modelos y procesos de desarrollo ESE em » Metodologias tradicionales Peer lilal le Bve-le]1 6 » Programacién extrema Paclaat ina) » Calidad del software, pruebas y evaluacién Una alternativa real y competitiva a los procesos tradicionales de desarrolloCONECTESE CON LOS 1 DE COMPUTACION & usershop.redusers.comEn nuestro sitio puede obt en forma gratuita, un capitulo de cada uno de los libros: 4) redusers.com @)ReauseRs UTS ese e CUE SR tr omc ec (ale oee-See Be Som ele gece UCC oe ejercicios, glosarios, atajos de teclado y todos los elementos necesarios para asegurar un apren- dizaje exitoso y estar conectado con el mundo de la tecnologia. THEM HOM IST Cts) > ARGENTINA © (O11) 410.8700 | CHILE © (2) 810.7400 | ESPANA © (93) 635.4120 = usershop@redusers.com @® redusers.comut IEEE ei Ts A a Coto DESI) Ty eer) To) ED) Peo eee eee een ey la ley 11728. Todos los derechos reservados. No se permite la reproduccién parcial Ree geo ea Ree eu ee sd libro, on cualquier forma o por cualquier medio, sea olectrénico © mecénico, mediante fotocopias,digitalzacién u otros métodas, sin el permiso previo y escrito Soe Cae eC na oe asume responsabilidad alguna por cualquier consecuencia derivada de la Ce een Oe Ce een ed describen y/o analizan. Todas las marcas mencionadas en este libro son propiedad exclusiva de sus respectivos duefios. Impreso en Argentina. Libro de edicién argentina. Primera impresisn realizada en Sevagraf, Costa Rica 5226, Grand Bourg, ea eee TS De REIL Priolo, Sebastian Maétodos giles. - 1a ed, - Banfield - Lomas de Zamora : Gradi, 2009. Vv. 165, 396 p. ; 24x17 cm. - (Manual users) ISBN 978-987-1347-97-1 1. Informatica. | TituloMetodos agiles Una alternativa real y competitiva a los procesos tradicionales de desarrolloPRELIMINARES. Sebastian Miguel Priolo Es ingeniero en Sistemas Informaticos. Se dedica a la consul- toria, al desarrollo y a la implementacién de sistemas y tam- bign a la docencia ¢ investigacién. Ha dictado cursos y confe- rencias, principalmente sobre programacién y metodologias de disefio y desarrollo. Su interés en los métodos agiles surge de la necesidad de desarrollar ¢ implementar software de calidad en ambientes empresariales, con equipos reducidos y en cortos lapsos de tiempo. Actualmente, se encuentra aplicando la filosofia del desarrollo gil y algunas metodologias en particular en proyectos desti- nados a pequefias y medianas empresas. Bajo estos modelos ha generado recientemente algunos software biométricos y de con- trol de produccién basados en férmulas de composicién Ante cualquier duda, sugerencia 0 comentario, el autor puede ser contactado a su direccién de correo electrénico. Agradecimientos Agradezco a aquellas personas que considero especiales, en par- ticular a mi familia. Dedicatoria Dedicado a la inteligencia, a la incertidumbre, a la timidez perfecta, al amor insensato, ala belleza, en fin, dedicado a Gabo.Prélogo PROLOGO Mi acercamiento a las metodologias giles se produjo hace ya varios afios cuando como participante en un desarrollo de software me tocé realizar su evaluacién. En ese momento, mis herramientas de andlisis se circunscribfan al Modelo estructurado de Ed Yourdon y a muchas técnicas de documentacién y modelado altamente estrictas y arbitrarias. A lo largo de rodo un afio intenté utilizar de la mejor manera estos elementos, dandome cuenta de que pasaba més tiempo trabajando sobre las herramientas y estandares que sobre el problema mismo. Al finalizar el proyecto y pasado un tiempo, comencé a sacar conclusiones sobre los esfuerzos realizados y qué porcién de estos habria sido realmente necesaria en caso de ver el desarrollo desde otro punto de vista. Alli comenzé mi busqueda por metodologias o paradigmas diferentes que me permitieran enfocarme al problema y brindar soluciones satisfactorias para el usuario. Inmediatamente, los conceptos de documentacién cero, entregas periédicas y clien- te en el equipo me llamaron la atencién y me condujeron a recolectar gran canti- dad de informacién sobre el tema. Luego de algunos afios de estudio, y cuando al fin tuve la posibilidad de decidir sobre los desarrollos, comencé a poner en précti- ca algunos de los principios sugeridos, principalmente, por la programacién extre- ma y por Scrum. Su uso en mis proyectos fue progresivo aunque inmediatamente me percaté de que la cercanfa al usuario y el mejor humor de los desatrolladores au- mentaba la productividad sin incluir mayores dificultades. Hace algin tiempo, después de una serie de conferencias, surgié la idea de armar unas exposiciones simples para poder presentarle al piblico en general la filosofla gil. La gran cantidad de asistentes altamente capacitados llamé mi atencién y me incliné a realizar algunos apuntes para mis cursos. Este libro tiene la intencién de mostrar un panorama amplio del desarrollo de software, sus problematicas y las distintas formas que tenemos de encarar un proyecto. Al igual que en otros escri- tos, el principal objetivo es contribuir a la difusién de las metodologias —no a su desarrollo presentando en un solo volumen los contenidos necesarios, al menos, para dar el primer paso y acercarse a ellas con énimo de conocerlas, pero también aplicarlas en nuestro trabajo diario. Quedan todos formalmente invitados a recorrer las siguientes paginas para aden- trarse en este maravilloso mundo, y ser participes de las tendencias més actuales en desarrollo de software. Ing. Sebastidn Priolo sebastianpriolo@gmail. comPRELIMINARES. EL LIBRO DE UN VISTAZO Es nuestra intencién que el lector conozca los sistemas y sus propiedades, ya que el acercamiento al software permitira describir t odo su pr oceso. La sel eccién de una met odologia puede es tar relacionada con los antecedentes y el pr oyecto. La intr oduccién ala ges tién y las met odologias giles tienen el objetivo de que Los profesionales podamos utilizarlas en casos reales, obteniendo todas las ventajas que nos ofrecen. Capitulo 1 SISTEMAS Y SOFTWARE El software, como elemento complejo, ocupa un espacio cada vez mas destacado en la industria mundial. Conocer su profundidad y las definiciones de sistema nos ayudan en ta comprensién de este fenémeno. El desarrollo del software presenta similitudes con otros productos, pero sus caracteristicas propias dificultan los procesos de creacién. Capitulo 2 PARADIGMAS Y SOFTWARE Las dificultades con las que los desarrolladores, se han encontrado al momento de producir software que funcione han dado lugar a Los distintos paradigmas y metodologias. El desarrollo orientado a objetos como paradigma de construccién nos presenta una visién mas acabada de la realidad. La Ingenieria de Software y su busqueda de mejores practicas pueden facilitarnos el camino. Capitulo 3 SOFTWARE Para finalizar con la crisis desatada en los afios 70 aparecieron metodologias de desarrollo orientadas tanto al proceso de construccién como a la gestién del proyecto. La estratificacién, la divisién de tareas y el fuerte hincapié en la planificacién y la documentacién son las caracteristicas esenciales de este tipo de desarrollo. Capitulo 4 GESTION AGIL La gestién de proyectos tradicional ha demostrado sus fundamentos; sin embargo, las nuevas tendencias y herramientas de programacién, sumadas a las nuevas imposiciones del mercado, obligan a buscar alternativas adaptables y flexibles. Las metodologias dgiles pueden ser la respuesta Capitulo 5 PROGRAMACION EXTREMA Algunas metodologias giles aparecieron con gran aceptacién por parte de los desarrolladores. La difusién y las practicas que propone han hecho de la programacién extrema la mas destacada, Las mejores practicas llevadas al extremo son iitiles no sélo en forma conjunta sino como marco de trabajo en otro tipo de proyectos. Capitulo 6 SCRUM Scrum como metodologia se basa en principios conocidos por otras ramas de la Ingenieria Las fases ¢ iteraciones nos dan una idea general del método. Su crecimiento rapido y sostenido, sumado a las organizaciones que lo han puesto en practica, han despertado la curiosidad de los desarrolladores acerca de sus verdaderas posibilidades. Veremos que, gracias a sus pocos roles y elementos, es simple familiarizarse con esta metodologiaEl libro de un vistazo Capitulo 7 TRADICIONAL Y AGIL Existen metodologias o marcos de trabajo que pueden ser utilizados tanto de forma predictiva como agil, y RUP es uno de ellos. El proceso unificado de desarrollo ha demostrado ser consistente y itil en empresas con altos requisitos y estandares de calidad. El uso de RUP de forma agil puede ofrecernos los beneficios del mundo agil y del predictivo. Capitulo 8 PRUEBAS Y CALIDAD El objetivo de las practicas metodolégicas y los procesos de desarrollo es asegurar la calidad del software. Intentaremos acercarnos a una definicién valida de calidad y conoceremos los elementos clave para tratar de alcanzarla. Las mediciones y la utilizacién de la informacién que podemos obtener son algunos de los temas criticos en el proyecto. Capitulo 9 HERRAMIENTAS Para poder controlar y gestionar nuestros proyectos debemos contar con herramientas adecuadas. Las metodologias agiles nos permiten utilizar elementos simples para su ejecucién y control; sin embargo, existe una gran cantidad de aplicaciones que pueden adaptarse a una 0 mas metodologias seleccionadas, permitiendo un seguimiento mas amigable Apéndice UML. El lenguaje unificado de modelado, conocido masivamente con el nombre UML, se ha convertido en el esténdar para el desarrollo de sistemas de software. Su correcta difusién y su relacién con marcos de trabajo y metodologias (como por ejemplo RUP) hacen de UML una opcién atractiva. En este apartado conoceremos las bases del Lenguaje y también sus posibles usos. Servicios al lector En esta iiltima seccién encontraremos el indice tematico, un listado de sitios que podemos visitar para mantenernos informados 0 aprender més y la bibliografia consultada TE iyrormacion coMPLEMENTARIA Alo largo de este manual encontrard una serie de recuadros que le brindaran informacién complementaria: curiosidades, trucos, ideas y consejos sobre los temas tratados. Cada recuadro esta identificado con uno de los siguientes iconos: CURIOSIDADES ATENCION. E IDEAS Ga SITIOS WEB Ol DATOS UTILES Y NOVEDADESJEVA DIMENSION E @)RedusERs MATERIAL ADICIONAL Ejemplos, cédigo fuente, planillas y otros elementos para descargar. Mejoran su experiencia de lectura y le ahorran tiempo de tipeado. Guia ‘Una completa guia con sitios ‘web, para acceder a mas informacién y recursos utiles ‘que le permitiran profundizar sus conocimientos. SOFTWARE Las mejores aplicaciones, relacionadas con el contenido del libro, comentadas ylstas para bajar. Ceres a Lo redusers.comContenido CONTENIDO Sobre el autor 4 Metodologia y paradigma 36 Prélogo 5 El proceso de software 37 Ellibro de un vistazo 6 Modelo en cascada 38 Informacién complementaria 7 Modelos evolutivos 45 Introduccién 14 Prototipos e incremental 46 Modelo en espiral 48 Modelo de desarrollo de SISTEMAS Y SOFTWARE componentes 48 {Qué es un sistema? 16 Paradigmas de desarrollo 4“ Pardmetros de los sistemas 18 Desarrollo orientado a objetos 50 {Qué es un sistema informatico? 19 El modelo de objetos 51 {Qué es el software? 20 —_Elobjeto como base 56 Clasificaciones de software 21 Programacién orientada a objetos 56 Caracteristicas del software 22 Resumen 57 Complejidad inherente Actividades 58 al software 26 Elementos de la complejidad 25 Dorninar la complejidad 27 SOFTWARE Desarrollo de software 60 Metodologias tradicionales 61 Desarrollo de sistemas Jackson 63 Ingenieria de la informacién 64 ies de cortguacion Método de analisis y disefio estructurado 65 cacao” drut | os — X a Ingenieria del Software 4 Crisis del software 32 t Situacién actual del desarrollo 33 | Resumen 33 co eo Actividades 34 rd Métrica 67 PARADIGMAS Y SOFTWARE Estructura 69 ws, 9PRELIMINARES. Roles y perfiles PMBOK Comprender el problema Identificar la solucién Desarrollar la solucién Composicién del equipo y jefe de proyecto Planificacién y gestién del riesgo Control y seguimiento Cierre del proyecto Lanzamiento del proyecto PRINCE2 Procesos y componentes Metodologias agiles Programacién extrema (XP] Scrum Crystal Clear Feature Driven Development (FDD] Adaptive Software Development [ASD] Seleccionar una metodologia Resumen Actividades Cees GESTION AGIL Proyectos Gestién de proyectos Nuevo escenario [esse] Cassis) [nee] [ee] [irene] rr | | corti Requisitos impredecibles Gestidn agil de proyectos Crystal Clear Principios Forma de desarrollo Prioridades 10 73 8 7 8 8 92 5 96 7 7 101 103 103 104 Propiedades 105 Practicas 0 técnicas 107 Feature Driven Development (FDD) 107 Ciclo de vida de FDD 108 Roles 110 ‘Adaptive Software Development (ASD) 113 Ciclo de vida 113 DSDM (Dynamic Systems Development Method) 115 Fases de desarrollo 116 Précticas 7 Roles 118 Lean Development (LD) y Lean Software Development (LSD) 119 Evolutionary Project Management (Evo) 119 Resumen 121 Actividades 122 Ce PROGRAMACION EXTREMA i Qué es XP? 124Contenido Historia de XP 125 Cuando utilizar XP 125 Promesas de la programacién extrema 127 Objetivos de la programacién extrema 127 Valores de XP 128 Simplicidad 128 Comunicacién 129 Retroalimentacién (feedback) 130 Coraje 131 Practicas de la programacién extrema 131 Actividades basicas 134 El proceso XP 135 Exploracién 136 Planificacién de la entrega 137 Iteraciones 138 Produccién 139 Mantenimiento 139 Muerte del proyecto 140 Equipo 140 Roles en XP 141 Cliente 141 Programador 142 Encargado de pruebas (tester) 143 Encargado de seguimiento {tracker} 143 Entrenador (coach) 143 Gestor (big boss) 144 Artefactos de XP 144 Historias de usuario 144 Tareas de ingenieria 145 Pruebas de aceptacién 146 Tarjetas CRC 147 Las balas de plata 148 Programacién en pares 149 Pruebas en XP 149 Solucionar problemas 151 Criticas a XP Resumen Actividades Cee SCRUM EQué es Scrum? 156 Historia 157 Ventajas de Scrum 159 Valores de Scrum 159 Modelo de desarrollo 160 Roles 161 Artefactos 164 Actividades 167 Ciclo de vida de un proyecto 172 Fase de preparacién (sprint 0) 172 Sprint 1 [comienzo del proyecto) 172 Sprint 2 178 Dificultades de implementacién 179 Seleccién y formacién de los recursos 179 Realizacién de las reuniones 179 Confeccién de los documentos 180 Recursos dedicados 180PRELIMINARES. Roles Serum } lan og ey La gestién del riesgo en Scrum Ampliacién descontrolada de caracteristicas Obtencién de requisitos errénea Calidad insuficiente Plazos de entrega equivocados Disefio inadecuado Sindrome de la bala de plata [silver bullet) Desarrollo e investigacién Personal inadecuado 181 181 181 182 182 182 182 183 183 Resumen Actividades 183 184 Crees TRADICIONAL Y AGIL Rational Unified Process (RUP] Caracteristicas esenciales Principios 12 186 186 188 Roles 189 Ciclo de vida 201 RUP y la agilidad 204 AUP 204 Ciclo de vida 205 Roles 206 Disciplinas 207 Test Driven Development 208 Microsoft Solutions Framework (MSF 209 Historia 210 Principios a Estructura 212 Roles 213 OpenuP 214 Resumen 217 Actividades, 218 Cer) PRUEBAS Y CALIDAD Calidad del software 220 Gestidn de la calidad 223 Aseguramiento de la calidad 224 El control de la calidad 225 Sistema de gestién de calidad 225 Medir la calidad del software 226 Métricas 229 Métricas de calidad 231 Métricas técnicas 231 Métricas de tamafio 231 Métricas sobre personal 231 Métricas de productividad 232 Métricas orientadas a la funcién 232 Metricas agiles 234 CMM - CMMI (Capability Maturity Model) 236 Gestidn de requisitos © requerimientos 239 Planificacién de proyectos 239 Monitorizacién y control de proyectos 239Contenido Medicién y analisis 240 Operadores 280 Aseguramiento de la calidad 241 Estructuras 281 Gestién de la configuracién 241 Bloques 284 Pruebas 262 Cadenas 284 Plan de pruebas 26h Tipos de pruebas 246 4 Documentacién de los errores 251 — Saar DONS CCAUDAD T REALZADA Satan CAUDAD CALIDAD omaiie| |p aean PROGRAMADA\ } NECESARIA fac ch ‘inser Resumen 251 Modelo de objetos 285 Actividades 252 Clases 285 Métodos 287 Constructores de clase 289 HERRAMIENTAS Herencia 290 Aplicaciones agiles 254 Redefinir métodos 291 ScrumDesk 254 Control de acceso 292 Scrum for Tear System 258 Polimorfismo 296 AgileTrack 259 Patrones de disefio 295 DevPlanner 261 Resumen 303 ExtremePlanner 262 Actividades 304 Project Planning and Tracking system (PTS) 265 Bugzilla 266 LENGUAJE DE MODELADO Servidor web 269 UML 306 Servidor de base de datos 271 Historia 307 Modelo relacional 272 Definicién de UML 308 Modelo orientado a objetos 274 Modelo conceptual 309 Gestores de base de datos 274 Diagramas de UML 312 MySQL. 274 Microsoft SQL Server 25 PostgreSQL 276 indice tematico 322 Ruby 277 Sitios web 325 Datos y asignacién 278 —_Bibliografia 331PRELIMINARES. INTRODUCCION Luego de escribir mi anterior libro sobre lenguaje Ruby recib{ buenos comentarios respecto a la decisién de no centrar el tema en algtin elemento en particular, sino intentar ampliar los horizontes del lector. Debido a esto y a mi interés personal en que asi sea, este manual tiene por objetivo presentar las metodologias agiles dentro de un contexto global de desarrollo, en el que las tecnologias evolucionan. Comenzaremos nuestro recortido analizando los sistemas y, en particular, los siste- mas de software, los factores que provocan su complejidad y las posibles soluciones que un desarrollador debe conocer. A través del modelo orientado a objetos expli- caremos las diferencias entre metodologia y paradigma. También comentaremos, de forma amena y prictica, todos aquellos elementos que acompafiaron el desarrollo de software, que ya lleva muchos afios entre nosotros. Entre estos, algunas de las metodologias tradicionales mas destacadas, ya sean puramente orientadas al soft- ware o a la gestién de procesos, nos serdn titiles para comprender la filosofia dgil y el gtan cambio que ésta propone. A partir de las bases obtenidas en los primeros capitulos nos encontraremos en si- tuacidn de poder estudiar los métodos heterodoxos, no sélo como una variacién si- no como el complemento necesatio en los procesos que se llevan a cabo en una in- dustria en transformacién, que debe idades de una co- munidad global cambiante y dinémica. La presentacién de cada metodologfa se realiza pensando en un contenido teérico correcto y, a la vez, acercandonos al lector de forma que los conceptos le sean fami- liares y pueda implementarlos en sus desarrollos. Por tltimo, veremos algunas he- rramientas tiles para la gestién de proyectos Al finalizar el libro esperamos que el lector se encuentre en condiciones de diferen- ciar las metodologias, conocer su filosofia y poder verificar si sus principios y prac- ticas le son titiles, dependiendo de sus gustos y particularidades. En resumen, el objetivo principal de esta obra es convertirse en un texto introduc- torio, que pueda guiarnos para comenzar a usar las metodologias Agiles con seguri- dad y sin temor de cometer ertores tar en linea con las necé 14Métodos agiles Sistemas y software En este primer capitulo nos acercaremos a las definiciones de sistema y de software, y conoceremos sus caracteristicas esenciales, Presentaremos al software como un proceso intelectual y a su vez como un producto de consumo SERVICIO DE ATENCION AL LectoR: lectores@redusers.com Qué es un sistema? Parémetros de ls sistemas Qué es un sistema informatica? ius es el software? Clasifcaciones de software Caracterstcas del software Complejidad inherente al software Elementos de fa complejidad Dominar la complejidad Ingenieria del Software Crisis del software Situacin actual del desarrollo Resumen Actividades 16 18 1 20 a 2 a a a a 32 3 3 41. SISTEMAS Y SOFTWARE EQUE ES UN SISTEMA? Antes de introducirnos en los sistemas computacionales, debemos conocer algunos conceptos basicos que nos serviran de plataforma para nuestros aprendizajes futu- ros. Primero es necesario saber delimitar un sistema y conocer su definicién, sus ca- racteristicas y sus principios. Decimos que un sistema es un conjunto de elemen- tos interrelacionados que operan en combinacién para obtener un resultado dese- ado (propésito). Esto significa que est4 compuesto por partes que se conectan en una forma definida o determinada Todo sistema tiene una estructura y una légica internas, como asi también meca- nismos que permiten la comunicacién entre los elementos constituyentes. Mas ade- lante veremos que no s6lo es importante mejorar los componentes aisladamente, si- no también su interaccién y formas de comunicacién. La alteracién de uno de los elementos afecta a todas las partes (globalismo o totali- dad) y el conjunto final resultante es diferente. Como consecuencia, los ingenieros tra- bajan para construir sistemas que sean menos susceptibles a las fallas en el caso de la modificacién de un componente, Otta de las dificultades es la fijacién de limites, ya que las pequefias diferencias en las determinaciones provocan grandes errores en el andlisis del problema. Aunque aqu{ apenas comentamos estos detalles, son el centro de muchos de los inconvenientes del desarrollo de sistemas de software. Segtin la definicién antes propuesta y lo declarado por Ludwig von Bertalanffy (bié- logo austriaco), decimos que los sistemas tienen las siguientes caracteristicas: + Propésito: toda la estructura del sistema se conforma para lograr un objetivo. En la mayorfa de los casos existe mas de un propésito definido y las prioridades de esos objetivos forman parte esencial de las respuestas del sistema * Totalidad: los cambios en los elementos repercuten en el resto del sistema, pro- duciendo alteraciones de diversa indole. + Entropia: es la tendencia de los sistemas a desgastarse o desintegrarse. Es directa- mente proporcional al lapso de vida del sistema, es decir que aumenta con el tiem- po transcurtido. Segiin algunas teorfas, el elemento que permite disminuir 0 con- trolar la entropfa es la informacién (negentropia). ID sistemas apaptastes La adaptabitidad es el proceso por el cual un sistema se organiza, adquiere informacién, la pro- cesa y aprende para poder resistir a su destruccién. En el caso de los sistemas informaticos, es- to no es sencillo de imitar. La busqueda de sistemas adaptables ha hecho posible no sélo la cre- acién de métodos originales sino de nuevas disciplinas dentro de los equipos de desarrollo. 16 aaaQué es un sistema? + Homeostasis: ¢s el equilibrio existente entre las partes del sistema. La adaptacién para [a supervivencia hace que el sistema se modifique, que se organice interna- mente a partir de sus elementos para resistir a las alteraciones externas. Los sistemas pueden ser clasificados segtin su constitucién en: * Sistemas fisicos: conformados por elementos y objetos concretos, reales. * Sistemas abstractos: se refieren a conceptos, ideas, hipdtesis. Son generalmente representados mediante simbolos que reflejan sus atriburos. Entropia (S) Nimero de estados (W) Figura 1. Representacién grafica del aumento de la entropia de acuerdo al nimero de estados de un sistema. ) exis- Ademis de observar la composicién, de acuerdo a la interaccién (0 natural ten dos tipos de sistemas: * Cerrados: no se relacionan con elementos situados fuera de ellos. $i aceptamos esta definicién, debemos decir que carecen de conexién con elementos externos. Dado que es dificil pensar que no haya ningiin tipo de intercambio, muchas ve- ces se hace uso de este término para destacar a aquellos sistemas que son ritmi- cos, como por ejemplo un reloj. EG sistemas asiertos Es muy importante destacar que en esta instancia de nuestro aprendizaje, al hablar del término temas abiertos lo hacemos para referirnos a la descripcién de las caracteristicas de un sis- tema y no a los sistemas de software abiertos que estudiaremos mas adelante en el libro y que n con el concepto aqui tratado no tienen relaci1. SISTEMAS Y SOFTWARE * Abiertos: son los sistemas que tienen un intercambio con el exterior en forma de entradas y salidas de materia o energfa. Figura 2. Posible representaci6n de un sistema ablerto y uno cerrado. Parametros de los sistemas Todos los sistemas tienen parametros en comtin, que veremos a continuacién: Entrada: es el material o energfa, comtinmente denominado input, que permite el inicio de la operacién del sistema. Salida: es l producto objetivo resultante para el cual fue creado el sistema. Se denomina output. * Proceso: es el conjunto de operaciones que realiza el sistema para convertir la entrada en salida Feedbacle: ¢s la funcién de retroalimentacién del sistema, que puede ser sobre el producto o la comparacién de éste con un criterio determinado. + Entorno: es el ambiente en el cual esté inmerso el sistema. Opera en muchos ca- sos junto a él, aunque puede hacerlo también en forma contraria. Como hemos visto, todo sistema presenta constante interaccién con su medio. EG sistema inrormArico Las distintas definiciones de sistema informatico varian, principalmente, por ubicar al usuario 0 a las personas dentro o fuera de él. Este punto, aunque simple, puede ser muy importante ala hora de considerar una equivocacién humana como error del sistema o del ambiente, cambian- do las condiciones del andlisis y del disefio. 18Qué es un sistema? Entorno Sistema Entrada fr aneda rocesos Entorno Salida Figura 3. Vemos que la etapa de proceso que nos interesa en principio es interna al sistema. 2Qué es un sistema informatico? Conociendo los elementos basicos, comenzaremos a introducirnos en el tema cen- tral. Un sistema informético es el conjunto de recursos disponibles para la resolu- cién de problemas, la simulacién de la realidad, el almacenaje de informacién, el procesamiento de datos y otro tipo de tareas mediante el uso de las ciencias de la computacién. Todo sistema informatico se compone de: * Personas hasta los usuarios finales. Hardware: computadoras, periféricos, circuitos electrénicos, dispositivos técnicos. Software: sistemas operativos, software de aplicacién, controladores. todos los que interacttan con el sistema, desde los desarrolladores + Documentos: reglas sobre el uso, normas y otro tipo de documentacién técnica. Hardware (la computadora) Datos. (informacién) Personas (usuarios) Software (programas) Figura 4, Un sistema informético esté compuesto por elementos de hardware y de software, personas y documentos. 191. SISTEMAS Y SOFTWARE EQUE ES EL SOFTWARE? nn este momento no discutiremos sobre cudndo nacié el software o si puede exis- tir independientemente del hardware, pero debemos establecer de forma clara a qué nos referimos con el rérmino. Repasemos dos definiciones alternativas: * El software es el conjunto de instrucciones que posibilitan y son responsables de que el hardware realice su tarea. + Segiin la definicién del IEEE, “software es la suma total de los programas de orde- nadot, procedimientos, reglas, la documentacién asociada y los datos que pertenecen a un sistema de cémputo”, Actualmente, se acepta la definicién més amplia (que incluye a la documentacién, en- tre ottas cosas, dentro del software), y todas las practicas de ingenieria se desprenden de ella. Pero el software no son sélo ios programas sino todos los documentos asocia- dos, la configuracién y el conjunto de datos necesarios para lograr que los programas operen correctamente. Entonces, el sistema de software estaré compuesto por: * Programas. * Archivos de configuracién asociados. * Documentacién del desarrollo. * Documentacién para el usuario final. Sistema de software Archivos de configuracién Progamas ) [=] = SI l= Documentacién _Documentacién de desarrollo de usuario Figura 5. Todo lo incluido en el sistema de software también debe ser desarrollado en el proyecto. 20£Qué es el software? Clasificaciones de software Como ingenieros, nos gusta clasificar las cosas de acuerdo a distintos criterios, y lo mismo podemos hacer con el software. La divisién més simple que podemos realizar es a partir del destino o utilidad que tiene el producto final. De acuerdo a esto observamos lo siguiente: * Software de sistemas: son los programas que permiten a otros poder operar. En general, estén construidos para interactuar con el hardware disponible y respon- der a las peticiones de software de mayor nivel. Su desarrollo suele set critico y de acuerdo a esto se podra obtener mayor rendimiento del hardware. Un ejemplo de este tipo de software son los sistemas operativos * Software tiempo real: son programas que interactan de manera natural con el ambiente. Accionan y responden relacionados con sucesos del mundo real a me- dida que estos aparecen. La tolerancia a fallas y la velocidad de respuesta son dos de sus elementos destacados. Su correcto funcionamiento depende no sélo de la respuesta sino de la velocidad en que la desarrolla y entrega. Este tipo de softwa- re generalmente se encuentra en ambientes de produccién, ventas y gestién, aun- que todos los programas que estamos acostumbrados a utilizar hoy en dia podri- an caer, en mayor o menor medida, en esta definicién. * Software ingenieria: es el software de asistencia a précticas de ingenierfa o cienti- ficas. Son herramientas que facilitan la toma de datos, los cilculos, la generacin de imagenes, el modelado de objetos y otro tipo de apoyo. * Sofware embebido: esta instalado en otros elementos o productos industria- les, comiinmente conocido como software empotrado. Su profundidad 0 sen- cillez dependen del destino dado. Incorpora elementos de software en tiempo real, de sistemas y de aplicacién. Usuario final Programas de aplicaciones Utlidades Sistema operativo Hardware de computadora Figura 6. Vemos claramente cémo el software de sistemas © de bajo nivel (por su ubicacién) soporta al resto.1. SISTEMAS Y SOFTWARE Caracteristicas del software Ahora que hemos tenido un acercamiento a la realidad del software, nos debemos interesar por sus caracteristicas distintivas. Actualmente, las mas aceptadas son las que define Roger Pressman en su libro Ingenieria del Software. Estas son: + El software se desarrolla, no se fabrica. * El software no se estropea. + La mayor parte del software se hace a medida. Falls infantiles Fallos normales | Fallos de + desgaste Tasa de fallos_ X i | Tiempo t Figura 7. Curva de baiiera, representando al desarrollo normal de componentes. EI software se desarrolla Las diferencias entre la produccién de un objeto y el desarrollo de un software son notables, y la falta de percepcién de éstas hace que muchos de los proyec- tos sean mal administrados, Mientras que el valor del producto se centra en la fabricacién, del software puede decirse que ésta es econdmica pero tiene grandes costos en su proceso de ingenieria. A pesar de esto, si existen productos a los Go INSTITUTE OF ELECTRICAL AND ELECTRONICS ENGINEERS ELIEEE o Instituto de Ingenieros en Electricidad y Electrénica es la sociedad técnica profesio- nal mas grande del mundo y se dedica a fomentar la innovacién tecnolégica y a contribuir al de- sarrollo profesional. Continuamente, podemos encontrar documentacién de valor en su sitio web, cuya direccién es www.ieee.org. 22£Qué es el software? que el software se asemeja en el proceso de elaboracién y a los cuales puede imi- tar para lograr el éxito. Las mayores similitudes se dan con aquellos que tienen un alto grado de innovacién. Al mencionar que el costo de fabricacién es despreciable, hacemos referencia a la tendencia que considera la elaboracién del software como el proceso de creacién del ejecutable, que como todos sabemos es casi gratuito. El verdadero costo del software se ubica, mucho antes, en el proceso y tiene que ver con los conocimien- tos y recursos que se deben destinar a él EI software no se estropea Los errores en el software tienen distinto impacto y su manifestacién no es igual que en el hardware. Generalmente, el software no es susceptible a los males del entorno que si provocan destruccién o deterioro en otros elementos (hardware). La posibilidad de correccién de fallas en el software no lo deja exento de volver a sufrir problemas, ya sea por viejos errores no conocidos o por los nuevos crea- dos en su mantenimiento y correccién. Vemos, una vez mas, que la necesidad de un software desacoplado es indispensable para evitar la introduccién de ele- mentos basura en el cédigo. La alta cohesién de los componentes es vital para que el desacople se dé como un proceso natural del desarrollo A medida que iteremos en el ciclo de vida apareceran nuevos detalles de cons- truccién, que pueden ser mejor identificados y ubicados en aquel software cuyos desarrolladores se han tomado el trabajo, desde un principio, de pensar en un di- sefio que sea susceptible de ser mantenido La mayor parte del software se hace a medida Casi todo el software se desarrolla para situaciones muy especificas y, por lo tan- to, se hace a medida o se lo modifica para adaptarlo a la realidad. No existen los componentes esténdar a los que un arquitecto o ingeniero pueda recurrir y de los cuales ya se tienen referencias y especificaciones aceptables Esto transforma el proceso de desarrollo en un conjunto de pasos casi artesana- les donde un lider con mayor capacidad puede marcar una diferencia entre el éxi- to y el fracaso. Actualmente, todas las metodologias y tendencias de desarrollo TD conesion v AcopLaMiENTo Cuando hablamos de cohesién nos estamos refiriendo al grado de cercania entre dos o mas. elementos. Es un conjunto de caracteristicas que los une y, por lo tanto, los agrupa bajo un mismo denominador. Por su parte, el acoplamiento mide el grado de dependencia que exi entre dos o mas elementos. te1. SISTEMAS Y SOFTWARE apuntan y preparan el escenario para tener un conjunto de componentes que pue- dan ser altamente reutilizados. El desarrollo orientado a objetos ha sido uno de los pilares de este tipo de premisas Incremento del indice de fallas por efectos laterales cambio indice de fallas Curva real Curva idealizada Tiempo Figura 8. Toda correccién del software puede provocar el desajuste de estructuras previas, introduciendo errores. Estas caracteristicas descriptas, junto con los temas que veremos a continuacién, son los factores principales que provocan la alta tasa de fracasos en el desarrollo de soft- ware a nivel empresarial. Teniendo presente estos elementos, corremos menos fies- gos y podremos alterar el circuito sin insertar posibles puntos débiles. Complejidad inherente al software Dentro del mundo de los profesionales del software existe una frase que aparece repetidamente en la bibliografia existente: la complejidad inherente al softwa- re, Con esta expresin tratamos de escudarnos ante posibles fracasos, pero no es menos real que el software, gracias a sus caracteristicas, posee dificultades de com- prensién que deben ser minimizadas. EI software de grandes dimensiones o de tareas criticas tiene un conjunto muy rico de comportamientos, y estos deben ser tratados particularmente pero tam- bin en forma global. A esta integracién corresponden muchas de las tareas que hoy en dfa se desempefian en un proceso de desarrollo de software. Este tipo de sistemas de software posee las siguientes caracter{sticas: * Analisis de requisitos complejo: todo sistema de volumen industrial o de alta in- novacién pondré al desarrollador frente al cliente y a las limitantes que éste im- 24 aaa£Qué es el software? ponga para su sistema. Esto, sumado a las tareas que deberé cumplir el sistema, dificulta el conocimiento de todo el dominio. * Ciclo de construccién largo: la naturaleza del sistema hace que el desarrollo re- quiera de varios meses o incluso afios para completarse. * Ciclo de vida largo: desde el comienzo de desarrollo hasta el estado de obsoles- cencia pasan varios ciclos tecnolégicos. + Amplia cantidad de usuarios: es importante sefialar que, por lo general, la can- tidad de usuarios del sistema se medird en decenas y ademés supondré distintos niveles de conocimiento, interaccién y acceso. * Distinto tipo de profesionales en su desarrollo: la interaccién de distintos tipos de disciplinas es comtin y puede dar como resultado dificultades de co- municacién de tipo técnicas o interpersonales. Sistema X € Usuario 1 9 Responsable Figura 9. Representacién de dos actores con distintos roles frente a un caso del sistema. Podemos observar las diferentes categorias de usuarios con las que el sistema interactia. Seguin Grady Booch, “la caracteristica del software de dimensién industrial es que re- sulta samamente dificil para el desarrollador comprender todas las sutilezas de su dise- fio”. En este caso, la capacidad intelectual humana se ve desbordada por los peque- fios mecanismos necesarios existentes para que el software funcione y lo haga realmente como los usuarios esperan. Para minimizar los problemas que comienzan a aparecer ante estas dificultades, se han creado disciplinas que nos permiten anali- zar, gestionar, desarrollar y entregar sisternas de software de forma eficiente. De es- to hablaremos mas adelante a lo largo de este libro. Elementos de la complejidad Siguiendo con nuestra tendencia de citar a Booch, decimos que existen cuatro ele- mentos que hacen que la complejidad sea esencial en el software: ane 251. SISTEMAS Y SOFTWARE Complejidad del dominio del problema Dificultad de gestionar el proceso de desarrollo. Flexibilidad alcanzable a través del software. Problemas de la caracterizacién del comportamiento de sistemas discretos. A continuacién, veremos con mayor detalle cada uno de estos elementos. La complejidad del dominio del problema Cuando trasladamos escenarios o problemas de la vida real al ambiente compu- tarizado, no s6lo nos encontramos con las limitaciones propias existentes sino que aparecen infinitos requerimientos que generalmente se contradicen. Los términos como facilidad de uso, costo, fiabilidad y adaptabilidad son elementos exter- nos que se introduciran en el proyecto. Ademés, estaremos obligados a trabajar con usuarios que dominan el problema en el ambiente real pero cuyos conoci- mientos sobre el software pueden ser deficientes. Es necesario crear metodologi- as, modelos o simbolos que permitan acercar las visiones y no introducir precon- ceptos en el anilisis del dominio del problema. Dificultad de gestionar el proceso de desarrollo La creacién de un software de gran alcance puede requerir de distintos especialistas que conformaran grupos heterogéneos, y por eso no sélo nos estaremos enfrentan- do continuamente a los requerimientos de un elemento abstracto sino que tendre- mos que lidiar con los pormenores de la administracién de los recursos humanos encargados de desarrollar el software. En todo sistema de gran tamafio los tiempos de respuesta ante el error plantean un inconveniente que tinicamente puede ser ata- cado mediante un desarrollo que se enfoque en la reusabilidad, la fiabilidad y la transparencia, Sin embargo, elaborar un aplicativo que ademds de funcionar bien contemple estos elementos puede ser critico y agregar mayor dificultad al proceso Flexibilidad alcanzable a través del software E] software generalmente sera introducido en ambientes donde coexistira con otros elementos de hardware o software ajenos a él y a sus desarrolladores. [DD sravy soocx Disefiador de software muy conocido por su método denominadoBooch para el desarrollo orien- tado a objetos y, ademés, por ser uno de los padres dellenguaje unificado de modelo (UML) jun- toa Ivar Jacobson y James Rumbaugh. El UML ha evolucionado y ha dejado de ser utilizado sé- lo por la informatica para representar también otro tipo de sistemas. 26£Qué es el software? La existencia de estos elementos hace que el software no sdlo deba adaptarse a la situacién problemética puntual sino a un conjunto de variables que limitaran su operacién y por lo tanto su desarrollo. Problemas de la caracterizacién del comportamiento de sistemas discretos El estado de una aplicacién depende de la conjuncién de miles de variables con valores mds todos los procesos. Al ser un sistema discreto, los estados posibles son finitos y pueden ser alterados por los eventos externos. Esto posibilita que un evento cambie el estado de un sistema produciendo una respuesta indeseada por el solo hecho de que sus desarrolladores olvidaron introducir un comporta- miento esperado a dicho suceso. Los distintos esquemas de pruebas que veremos més adelante tienen esta descripcién como realidad ¢ intentan hacer todo lo po- sible para recorrer todos los caminos de un software. Dominar la complejidad A pesar de que la complejidad esencial del software no puede ser eliminada, si se puede combatir. Para comprender mejor esto, podemos analizar lo que dice Eds- ger Dijkstra: “La técnica de dominar la complejidad se conoce desde tiempos remo- tos, divide et impera (divide y venceras)”. Esto quiere decir que un problema con cierta complejidad debe ser atacado di- vidiéndolo en pequefias partes que puedan ser inteligibles, con menor compleji- dad, y resueltas por separado para luego volver a componer el todo. La separa- cién en el desarrollo se puede materializar mediante: Descomposicién algoritmica: este tipo de divisién implica que los procesos del sistema serén representados en pequefias partes altamente cohesionadas. Los mé- todos de andlisis y disefio estructurado son los que se utilizan para este caso. El principal objetivo es centrarnos en los procesos y los flujos de datos del sistema: entradas, internos (entre procesos) y salidas. Generalmente, este tipo de des- composicién nos lleva a un desarrollo utilizando lenguajes imperativos [Eg macazine de software Software Development Magazine [www.sdmagazine.com) es una revista virtual que ofrece una serie de articulos y contenidos actualizados sobre desarrollo y tendencias de software. Mucha de la informacién publicada luego es utilizada por los usuarios para discutir sobre la posibilidad o no de la introduccién en el ambiente real. La revista se unié a Dr. Dobb's Journal ww.ddj.com]1. SISTEMAS Y SOFTWARE NSN I~ Oooocd Figura 10. Descomposicién algoritmica tradicional en un enfoque estructurado. Descomposicién orientada a objetos: se identifica de forma seméntica el dominio del problema, que intentard ser representado mediante un conjunto de elementos independientes, Esto se observa en el disefio y la programacién orientados a obje- tos. Los objetos interacttian mediante un protocolo 0 paso de mensajes que puede set familiarizado con el flujo de datos que mencionamos anteriormente, Se utilizan lenguajes declarativos y, por supuesto, orientados integramente a objetos. Figura 11. Los objetos trabajando en conjunto corresponden con la idea que tenemos de sistema. _ A pesar de que a simple vista estos conceptos puedan parecer contradictorios, en reali dad son complementarios en niveles bajos de abstraccién. Todos los objetos que reco- nozcamos también tendran, tarde o temprano, algiin tipo de descomposicién algorit- mica aunque en un alcance diferente. Como veremos més adelante, las metodologias, en mayor o menor medida, hacen uso de la descomposicién y el refinamiento. Cohesién y acoplamiento Sabemos que tenemos que dividir el problema para ser capaces de resolverlo. Existen ctiterios que debemos seguir para evitar tener tantos fragmentos que se hagan impo- sibles de manejar. Para entender qué es lo que se quiere conseguir, es necesario acla- 28 aaa£Qué es el software? rar dos conceptos: cohesién y acoplamiento. Una méxima técnica dice que todo buen software pose alta cohesi6n y bajo acoplamiento. La cohesién se refiere a la manera en que agrupamos unidades de software en unidades mayores. El término uni- dades de software se utiliza, actualmente, para denominar a una parte de software que realiza una o més funciones ficilmente identificables. Tradicionalmente, una uni- dad de software es un médulo, una clase, una librerfa, etcétera. De acuerdo al criterio que se tome para agrupar funcionalidad en la unidad, podemos hablar de: Cohesién funcional: los elementos se agrupan en una unidad (0 varias unidades) pensando principalmente en el tipo de funcién que cumplen y sus resultados di- rectos. Es la clase de cohesién mas buscada por los desarrolladores. Cohesién secuencial: se utiliza para dividir un problema, teniendo como maxi- ma que la salida del proceso es el ingreso de la etapa siguiente. Cohesién de datos: todas las unidades seleccionadas necesitan el mismo conjun- to de datos para operar correctamente. Cohesién ldgica: se agrupan de esta manera cuando todas las unidades realizan la misma operatoria desde el punto de vista lgico; por ejemplo, las bibliotecas graficas, las matematicas, las de input, etcétera. * Cohesion temporal: las unidades son agrupadas tomando como pardmetro el tiempo en que deben ser ejecutadas, como en el caso en que deben ser ejecutadas en paralelo, de forma secuencial, etcétera. Cohesién casual: se agrupa segiin cl gusto del desartollador, cuando ninguno de los criterios anteriores son vilidos. Es el tipo de cohesién que hay que evitar. Sistema X Alto acoplamiento Desacoplado O Figura 12. Observemos que un subsistema muy acoplado seré dificil de modificar sin interferir con otros subsistemas. El acoplamiento se refiere al grado de dependencia que existe entre las unida- des de software. Si observamos dos unidades de software que pueden trabajar in- dependientemente, sin necesitar a la otra, decimos que se encuentran desaco- pladas. Un desarrollo de este tipo es ideal aunque improbable, ya que siempre ane 291. SISTEMAS Y SOFTWARE alguna de nuestras unidades dependera de otra. Sin embargo, se busca minimi- zat esa subordinacién para lograr que la alteracién de una de las unidades de soft- ware no produzca efectos adversos en las otras. Al igual que en la cohesién, exis- ten distintos tipos de acoplamiento: + Acoplamiento ideal (desacopladas): estos métodos son los que producen re- sultados independiente static int suma(int a, int b) { return a + static int resta(int a, int b) { return a - b; + Acoplamiento normal: donde un método es dependiente de la ejecucién y re- sultado del otro. Pueden darse casos en los que esto sea vilido para uno o para los dos. En el ejemplo, el método multiplica es dependiente del método resta, pero éste puede operar por s{ mismo. static int multiplica(int a, int b) { int ¢ = resta(a, b); ; return 2 * c; static int resta(int a, int b) { return a - * Acoplamiento de datos: las unidades de software se encuentran acopladas cuan- do requieren y utilizan el mismo conjunto de datos. * Acoplamiento por control: es un tipo de acoplamiento poco deseable, la unidad de software es dependiente, basicamente, del resultado de otra, en base al cual se determinard la accién que tomara ésta. 30Ingenieria del Software + Acoplamiento global y por contenido: son los tipos que no deben aparecer en el software y casi siempre es posible evitarlos, tomando las medidas necesarias. El acoplamiento global implica que las unidades de software trabajan sobre un con- junto de datos en comiin sin pasirselos entre métodos sino accediendo a ellos di- rectamente. El acoplamiento por contenido supone que un desarrollador que quie- re modificar una unidad determinada deberé conocer a fondo otras unidades que no tienen relacién directa con el problema o con su solucién. Cualquier software que se analice y desarrolle con base en la calidad obtendré la cohesién y el acoplamiento adecuados. En muchos casos, cuando se hace a con- ciencia, el refinamiento permite que el software se adecue a las mejores practicas, permitiendo que las unidades sean reinterpretadas o modificadas para facilitar el desarrollo y fururo mantenimiento INGENIERIA DEL SOFTWARE El término ingenieria del software aparece al final de los afios 60 para referirse al desarrollo para computadoras, Segiin Bauer, “la Ingenieria del Software es el estable- cimiento y uso de firmes principios y métodos de ingenierfa para la obtencién econémi- ca de software fiable y que funcione en maquinas reales”. Por otro lado, Bauen nos dice que “la Ingenierfa de Software es la aplicacién de la ciencia y las mateméticas mediante la cual la capacidad de los equipos computacionales se hace teil al hombre a través de programas de computador, procedimientos y la docu- mentacién asociada”, Para simplificar, concluiremos que la Ingenieria del Softwa- re se encarga de analizar situaciones para resolverlas, utilizando técnicas que facili- ten su manejo y el del desarrollo del futuro escenario. fenieR cance es Coc ern arcs IEE IEEE Eeebrande 70 Aios elbrting 125 Yoore Figura 13, El IEEE (www.leee.org.ar) es la sociedad técnica profesional mas grande del mundo. Es el organismo representante de los estandares. 311. SISTEMAS Y SOFTWARE Como todo inicio, el del software no estuvo exento de problemas. En los primeros desarrollos se confiaba demasiado en las capacidades del programador y el andlisis de las situaciones probleméticas era bastante pobre. A pesar de los esfuerzos para la introduccién de técnicas més avanzadas, el desarrollo de software siguié topandose con dificultades. A fines de los afios 60, la mayoria de los proyectos encarados por las grandes industrias tendfa al fracaso. En ese contexto aparecié lo que se denomi- né crisis del software a principios de los afios 70. Basicamente, los lideres de los proyectos y la comunidad cientifica se preguntaban: 4Cémo debemos estimar los costos y los tiempos? jPor qué las desviaciones en el proceso son tan grandes? jCémo se debe detectar el error? ZA qué se debe la alta tasa de fallas? jCémo responder a los requerimientos del cliente? jCémo manejar requisitos volétiles? Las respuestas a estos interrogantes surgirfan de la introduccién de elementos que aportaron rigurosidad cientifica al desarrollo de software, y con esto estaba co- menzando lo que denominamos Ingenieria del Software. Crisis del software La etapa mencionada como erisis del software sigue siendo, en la actualidad, un punto de inflexién a partir del cual han surgido muchas de las metodologfas que se utilizan hoy en dia y se han creado las bases para métodos y herramientas que atin no se han materializado a nivel practico, pero cuyo marco tedrico ha crecido desde ese momento. Decimos que la crisis del software puede ser dividida en cinco fases. + Primera fase, los albores (1945-1955): se desarrolla, bésicamente, con len- guaje maquina o ensamblador. El software es basico y s6lo permite realizar las minimas tareas para darle utilidad al hardware. * Segunda fase, el florecimiento (1955-1965): los desarrollos pretenden ganar alcance y como resultado de esto aparecen distintos lenguajes de programa- cién para facilitar la tarea de desarrollo y minimizar los errores. * Tercera fase, la crisis (1965-1970): en esta etapa sucede la gran crisis que provoca que mateméticos, ingenieros y cientificos en general comiencen a investigar no sélo las causas sino los efectos de todas las actividades relacionadas con el software. La ma- yoria de los desarrollos fracasan por distintos motivos y se hace esencial la btisqueda de refinamientos. Se plantean grandes desafios pero ninguno de estos proyectos pa- rece llegar a buen puerto. La gran cantidad de errores en el software y la ineficacia para su gestién hacen que muchas empresas opten por detener sus futuros proyectos. 32 aaaIngenieria del Software * Cuarta fase, innovacién conceptual (1970-1980): los fundamentos de progra- macién empiezan a ser establecidos formalmente, en conjunto con metodologi- as estructuradas que permiten la representacién de los sistemas complejos como analisis de requisitos y mejoras del disefio. Los conceptos sobre pruebas comien- zan a semejarse a los que manejamos hoy en dfa. Aparecen las primeras tenden- cias 0 ideas académicas que en la actualidad son pilares de la industria. * Quinta fase, el disefio es el problema (1980-2): el modelado o manejo de los requisitos y su posterior andlisis ya no presentan tantos inconvenientes. El pe- so de los proyectos comienza a caer en el disefio. Los desarrollos empiezan a limitarse por términos tales como fiabilidad, jerarquia, redundancia, reuti- lizacién, modularidad. Las mejoras en los entornos de desarrollo y los len- guajes de alto nivel favorecen a los grandes grupos de programadores. Se in- troduce la POO (Programacién orientada a objetos). Situacion actual del desarrollo Las metodologfas tradicionales han perdido impulso, por la cantidad de herramien- tas que han mejorado la produccién de cédigo, haciendo que muchos esquemas no puedan adaptarse a la realidad. El conocimiento de estas metodologias resulta til por la facilidad con que pueden ser interpretadas y aplicadas en distintos Ambitos de desarrollo y porque es mejor que carecer de metodologia de desarrollo. En el proximo capitulo estudiaremos las metodologias y en el siguiente veremos los enfoques més tradicionales. Es bueno destacar que ninguno de estos ha logrado so- lucionar de manera concluyente los problemas de desarrollo. Es por eso que las nue- vas metodologias harén uso de los avances en distintas disciplinas, desde matemati- cas hasta psicologfa, para poder mitigar las antiguas falencias. BW Resumen Cualquier elemento de software es un sistema y por lo tanto posee las caracteristicas de éste. Conocer la teoria de sistemas y construir en base a ella puede ser de gran ayuda en los momentos en que las metodologias no nos alcanzan. El desarrollo de software es una de las industrias con mayor crecimiento, que en sus inicios pasé por momentos criticos, superados ‘s6lo parcialmente. Su evolucién ha permitido que en la actualidad podamos elegir diversas formas de producir, desarrollar, distribuir y mantener software con cierto éxito.ACTIVIDADES PREGUNTAS TEORICAS 1 {Qué entendemos por sistema? 2 (Aqué denominamos software? 3 {Qué papel tiene el conocimiento del problema en el desarrollo? 4 (En qué se diferencia un software empotrado del resto? 5 {Qué elementos caracterizan al software? 6 {En qué se distingue el desarrollo de software del de otros productos? 7 (Aqué se debe la complejidad del software? 8 {Cudles son los métodos mas utilizados para atacar la complejidad? ¥ (A qué se denomina crisis del software? 10 {Cudles fueron las consecuencias de la crisis del software? 34 EJERCICIOS PRACTICOS 1 Investigue acerca de las diferencias entre sistemas abiertos y cerrados. 2 Proponga alternativas para la clasificacién de sistemas. 3 Enumere posibilidades para dominar la complejidad. & Investigue acerca de los métodos de desarrollo y sus principios basicos. 5 Busque informacién sobre la conocida bala de plata en el desarrollo. essaMétodos agiles Paradigmas y software Ahora que tenemos las bases, presentaremos un cuadro mas terminado sobre la Ingenieria de Software, los problemas a los que se enfrenta y las practicas y métodos que utiliza para sortearlos SERVICIO DE ATENCION AL LectoR: lectores@redusers.com Metodologta y paradigma El proceso de software Modelo en cascada Modelos evolutivos Protatipos e incremental Modelo en espiral Modelo de desarrollo de componentes Paradigmas de desarrollo Desarrollo orientado a objetos El modelo de objetos Elabjeto como base Programacién orientada a objetos Resumen Actividades 36 7 38 45 6 4B 4B 43 50 51 56 56 57 582. PARADIGMAS Y SOFTWARE METODOLOGIA Y PARADIGMA Antes de comenzar con los contenidos centrales, es importante que comentemos al- gunos temas que suelen prestarse a confusién. Estos contenidos son ignorados en la mayor parte de la bibliografia basica y luego los descubrimos cuando tenemos una cantidad de conocimientos suficiente para que las diferencias apenas se noten en nuestra practica diaria, cosa que puede llevar a problemas tipicos de desarrollo. Comencemos diciendo que el proceso de creacién del software es ciclico. Es asi como todo software tiene su propio ciclo y cada proyecto, contenido en uno 0 va- rios procesos, también. Notemos en primera instancia que diferenciamos el softwa- re, el proceso y el proyecto. En algunos casos, proyecto y proceso de software se utilizan como sinénimos aunque es conveniente saber que el proyecto de creacién puede tener ejecutandose uno o més procesos que interacttian o no entre si. EI proceso de software es la vista de mas alta abstraccién bajo la cual organiza- remos las tareas de ingenieria para obtener un software de calidad. Los proyec- tos de desarrollo incluyen a estos procesos y también a otros que pueden tener que ver con las tareas relacionadas, como por ejemplo las econémicas y los arreglos de contratos con clientes y trabajadores. Ahora que tenemos delimitado el uso de los términos, pasaremos a un punto cru- cial en la formacién de los ingenieros y desarrolladores. Constantemente se nos bombardea con términos como metodologia, practica, método o paradigma y muchas veces se los usa como sinénimos cuando en realidad, en la construccién de un software, no lo son Existe un ciclo de vida del software que puede ser dividido en fases. Cada una de ellas debe set completada mediante la aplicacién de tareas, técnicas y herramientas. Una me- todologia es el elemento que nos enuncia cudles son las herramientas que se van a usar, quiénes realizaran las tareas, en qué momento y cudles son consideradas tareas criticas, entre otras cosas. Existen innumerables metodologias y cada una posee sus ventajas y desventajas, lo que hace necesario tomar la decisién de cudl utilizar para cada desarro- Ilo en particular. Mas adelante iremos describiendo estas metodologias. Al referirnos a paradigma, damos como opciones el estructurado o el orienta- do a objetos (entre otros). Estos no son otra cosa que la forma de desarrollar 0 Ey Paravicmas Un articulo muy simple para entender cudl es el estado actual de los paradigmas y qué es lo que se espera de estos es el denominado “In Praise of a Theoretical Basis for New Software Paradigms’ El texto, escrito por Wolfgang Reisig, puede ser descargado de www.informatics-europe.org/ ECSS08/papers/WReisig.pdf. 36El proceso de software ver el problema. No definen el ciclo de vida ni las tareas concretas a realizarse ni el momento en que se efectiian. A continuacién comenzaremos a ver los procesos de software que nos aclararén algunos conceptos. EL PROCESO DE SOFTWARE El proceso de software es el conjunto definido, limitado y coherente de activi- dades que permiten el desarrollo de software. Como sabemos y hemos destacado en el capitulo 1, el software posee cierta complejidad que aumenta con todos los requisitos que trae aparejados (cumplir con calendarios, respetar costos, tratar con personas). A lo largo de la historia del desarrollo se han presentado cuatro fases caracteristicas de todo proces Requerimientos Construccién Validacién Evolucién Requerimientos |—- | Construccién Validacién Eyolucién Requerimientos Construceién Validacién Evolucién Figura 1. La evolucién de un sistema supone la creacién de un proceso que contiene todas las fases. Estas etapas representan el ciclo de vida de un proyecto y pueden ser ordenadas de acuerdo a un modelo. Un modelo es una representacién simplificada de la realidad y, en este caso, es el marco de los pasos que hay que seguir para que el desarrollo alcance buen término. En resumen, en un proceso de software, el mo- delo nos aporta lo siguiente: * Define las tareas necesarias para el correcto funcionamiento por etapa y en general. * Describe y delimita las fases. ane 372. PARADIGMAS Y SOFTWARE Permite la ubicacién en proyecto. Facilita la estimacién de tiempos y costos. Ubica a los recursos en un momento dado y en una tarea determinada. Herramientas Figura 2. Vemos que las herramientas ocupan el ultimo eslabén en el proceso. Basicamente, podemos dividir los modelos en tres tipos: + Lineales: representados en cascada, cada etapa esté determinada y se sigue una secuencia definida esperando resultados anteriores. + Evolutivos: son de diversa indole, aunque se destacan el exploratorio y el de- sechable, haciendo hincapié en el resultado rapido y su confrontacién con los deseos del cliente. + Componentes: desarrollo de introduccién posterior en el mundo del software aunque muy conocido en otras industrias. Se apoya en el concepto de utilizar par- tes estandarizadas para lograr la construccién final. Cada modelo tiene sus particularidades y ventajas, pero no hay que olvidar que aquellos que corrigen los puntos débiles de otro poseen los propios. Por eso, en la practica real estos tipos de modelos 0 modelos concretos no son excluyentes sino que trabajan en conjunto para lograr excelentes resultados. Ademis, el inge- niero con experiencia aplicaré su criterio profesional antes que cualquier con- junto de reglas establecidas cuando de verdad crea que éstas no son las més ade- cuadas para un acontecimiento. Modelo en cascada Cuando nos acercamos por primera vez a los desarrollos se nos ensefia el modelo en cascada. Este existe desde hace mas de 35 afios y sigue siendo el pilar para tener no- cién sobre cules son las etapas que se requiere cumplir antes de tener un entrega- ble (del inglés deliverable) de minima funcionalidad. 38 aaaEl proceso de software Requisitos -> Aanétsis | dseto | Codificacién > Pruebas: > Mantenimiento Figura 3. La delimitacién de fases fue un avance notorio en el desarrollo de software. Como se observa en la imagen, el desarrollo es dividido en fases secuenciales y con metas bien definidas. Se pueden encontrar diferencias de acuerdo a la bibliografia, pero en general las etapas son las que analizaremos a continuacién. Especificacion Esta etapa es comtinmente denominada recoleccién de requisitos 0 especifica- cidn de requisitos, aunque en algunos entornos sc la llama ingenieria de sistema. En esta fase necesitamos definir el dominio del software que vamos a desarrollar, comprender sus fines, utilidad y limitaciones, al menos en grandes rasgos. Para esto, recolectaremos informacién que debe ser facil de estructurar y almacenar porque seré fundamental a lo largo de todo el desarrollo y los problemas o falen- cias en esta etapa pueden llevar al fracaso. Bajo este modelo, la especificacién de requisitos es tan vital para el proyecto que alo largo de los afios han aparecido y se han depurado técnicas que intentan acer- car dos posiciones tan diferentes como la del desarrollador y la del cliente. La asociacién entre cliente y desarrollador es imprescindible debido a que el pri mero conoce su negocio, las necesidades y los objetivos, y el segundo sabe por su formacién y experiencia qué es posible hacer y cual es la mejor forma de concre- tarlo desde el punto de vista técnico. Fay PRocRAMACION ORIENTADA A OBJETOS La programacién orientada a objetos no es una rama diferente de la informatica sino que es un tipo de desarrollo fundamentado en el AOO (Anélisis orientado a objetos) y DOO (Disefio orientado a objetos). Los objetos son representaciones y, en la practica, implementaciones de una clase que los agrupa.2. PARADIGMAS Y SOFTWARE Datos | | Informacién Informacién Recolectar Procesar Evaluar Almacenar Figura 4, La recoleccidn de informacién correspondiente al sistema supone un conjunto de pasos posteriores para facilitar la consulta. Anilisis En esta ctapa se determinan los objetivos y limites a partir de la informacién adqui- rida anteriormente, intentando profundizarla antes de pasar al disefio. Se deben de- terminar las tareas que realizard el sistema y sus estructuras, procesos criticos y se- cundarios. Una vez que tengamos una idea acabada del objetivo, comenzaremos a diagramar el sistema, aplicando alguna de las metodologias de anélisis que conside- remos adecuada al proyecto en cuestién. A medida que adquirimos experiencia, la etapa de anilisis tendra menos componentes tedticos porque estos seran reemplaza- dos por la carga de conocimientos que le pueda aportar el equipo. Por sus propie- dades, las tareas del andlisis son denominadas: * Conceptualizacién: el objetivo es obtener una vista de alto nivel de abstraccién. Se focaliza en el sistema y sus partes teniendo en cuenta los elementos externos. + Andlisis funcional: se trata de identificar y describir los procesos internos del Eq andusis Las fases en que hemos dividido el desarrollo, al igual que las etapas del analisis, han sido se- leccionadas para facilitar la lectura y aumentar la comprensién del tema. En la bibliografia mas tradicional nos encontraremos con dos clasificaciones que no tienen relacién, aunque si exami- namos bien el tema veremos que cualquiera de éstas es perfectamente descriptiva. 40El proceso de software sistema, Una vez establecido el proceso, lo seleccionamos y realizamos su refina- miento obteniendo los flujos de datos ingresantes y salientes (que seran ingresos de otros procesos 0 egresos de nuestro sistema objeto) + Andlisis de condiciones: especificacién de las restricciones de nuestro sistema. Las limitaciones pueden ser de tipo técnico, fisico, econémico o humano. + Aplicar la metodologia: luego de las etapas anteriores aplicaremos algiin proce- so de diagramacién. Esta creacién para poder modelar el andlisis realizado incor- poraré toda la informacién recopilada anteriormente, como as{ también todas las restricciones y detalles que aparezcan en la ejecucién de esta fase. Aclaremos que se construye un modelo o representacién y no el sistema propiamente dicho. * Validacién: si nuestro andlisis es correcto deberemos pasar a la etapa siguiente (di- sefio), pero para asegurarnos tenemos que someter este andlisis a una completa va- lidacién para evitar las inconsistencias, las ausencias de informacién y la pro- pagacién de errores o defectos. Es de destacar que todos los documentos producidos en esta etapa determinan qué es lo que debe hacer el futuro sistema pero no cémo debe hacerlo, ya que eso es tarea de los disefiadores del sistema. Disefio En el disefio aplicamos practicas de ingenieria para definir de forma técnica los procesos, elementos y datos del sistema. El disefio profundiza y completa la vi- sién del software, pero ademés le agrega los componentes técnicos. Toda la eta- pa se realiza utilizando un tipo de modelado definido. El resultado de la fase de disefio sera la base para el comienzo de la construccién del software. La docu- mentacién serd entendida por los técnicos y estaremos dejando de lado la visién de alto nivel proporcionada por el cliente en las entrevistas y andlisis, para deta- lar cada uno de los componentes o partes integrales. Seguin las definiciones tra- dicionales, en el disefio se materializan los requerimientos del cliente. En ge- neral podemos identificar tres etapas: * Disefio de estructuras: el disefio arquitecténico es el eje de la construccién, * Disefio de estructura de datos: se definen y documentan todos los datos que se- én utilizados por el sistema. Se especifican todas las entradas, salidas y almacena- jes. Las estructuras de almacenaje y la definicién técnica sobre sus formas son cons- truidas 0 al menos simuladas. * Disefio de interfaz: se decide desde un punto de vista técnico formal el tipo de interfaz que utilizaremos y cualquier otro elemento con el que debemos interac- tuar, incluido el usuario. Se busca la realizacién de las interfaces de nuestro siste- ma con todos los externos con los cuales se debe compartir informacién. No que- da exento en este punto el disefio de las interfaces entre los subsistemas. ane 442. PARADIGMAS Y SOFTWARE Codificacion En la fase de disefio se definieron uno 0 mds lenguajes de programacién en los cua- les se esctibird el sistema. En esta etapa debemos destinar recursos para que el siste- ma que ya ha sido analizado y disefiado pueda comenzar a set una realidad. Las ta- reas de codificacién son amplias y se realizan siguiendo cronogramas o patrones de trabajo establecidos. Cabe destacar que la generacidn de los modelos de datos y su estructura estan incluidos en lo que denominamos codificacién, aunque estas tate- as no son siempre llevadas a cabo por el mismo equipo de trabajo Pruebas La prueba del software es un conjunto de practicas que se llevan a cabo para loca- lizar, identificar y eliminar errores y mejorar el producto. En general, cuando nos planteamos desarrollos de gran envergadura, un plan de pruebas adecuado pue- de ser la diferencia entre un software robusto y un software deficiente. Hay que re- marcar que el objetivo de la prueba no sélo debe ser la localizacién del error sino que debe servir para anticiparse a los potenciales requerimientos futuros, asegu- rar la fiabilidad y presentar datos objetivos sobre el rendimiento y la calidad. Durante algtin tiempo, y atin hoy en dfa, se crefa necesario tener una etapa especial y delimitada para la realizacién de pruebas. En los desarrollos actuales, debemos alentar las buenas practicas de preparar pruebas y generar resultados en todo el ciclo de vida de un proyecto, incentivando el uso de herramientas de asistencia y pardmetros reales de la industria. Etapat +] Etapa2 =| Etapa3 +} Etapad = | +} EtapaN i t t Pruebas (Planeamiento y ejecucién) Figura 5. Esté comprobado que acompafar todo el desarrollo con pruebas favorece la calidad final. Ee pruceas El avance en los desarrollos ha obligado a mejorar las técnicas y procesos de prueba. En ba- se a esto, los desarrolladores tienen nociones basicas de todas las etapas y los tipos de tes- teo de software. Un buen documento para comenzar es el paper de Ram Chillarege, que po- demos descargar de www.chillarege.com/authwork/TestingBestPractice.pdf. 42El proceso de software Mantenimiento Luego de que el sistema ha sido probado e implementado y su funcionamiento es el correcto, debemos intentar realizar tareas que permitan prolongar su vida til. Las operaciones de mantenimiento proponen lograr que el sistema manten- ga el nivel de ejecucién satisfactorio que obtuvo en las pruebas. Dentro del man- tenimiento podemos observar: * Monitoreo: es el conjunto de procesos que evalian la calidad del control en el tiempo y permiten al sistema reaccionar en forma dindmica. * Mantenimiento correctivo: es la reparacién de errores en el momento en que estos aparecen + Mantenimiento preventivo: también denominado mantenimiento planificado Consiste en la correccién de fallas de forma programada o la ejecucién de tareas para que éstas no aparezcan Para facilitar el entendimiento hemos intentado agrupar todas las tareas del proce- so de software en cuatro etapas (aunque a veces se use otra divisién). Nos gustaria reflejar aquf una serie completa de las actividades que se realizan habitual mente: Revisién del sistema: se evaltia a nivel macro el sistema que realizaremos y el es- tado actual de los sistemas relacionados. * Toma de requisitos: el cliente presenta sus condiciones y los desarrolladores inter- pretan y utilizan técnicas para acercarse al verdadero deseo del cliente. * Analisis de requisitos: luego de la obtencién de informacién, ésta se cataloga, ordena y utiliza para generar la documentacién que se utilizara para dar inicio a la siguiente fase. * Analisis de procesos: evaluacién de los procesos administrativos y organizacio- nales del cliente o su empresa. + Reingenierfa de procesos: una vez, que estan identificados los procesos inefica- ces o ineficientes, se intenta modificarlos a fin de obtener mejores practicas ad- ministrativas y operacionales. * Disefio: etapa de disefio del sistema que se encuentra en desarrollo. TD tencuases de PROGRAMACION A pesar de que los principios de la programacién orientada a objetos son lo suficientemente cla- ros, cada lenguaje ha decidido de qué forma adoptarlos. Es asi que existen lenguajes con herencia simple, mientras que otros permiten la herencia miltiple. Es conveniente estudiar las caracteris- ticas del Lenguaje que las herramientas nos brindan para poder realizar nuestros programas.2. PARADIGMAS Y SOFTWARE * Programacién: codificacién en uno o més lenguajes determinados. + Integracién: en esta etapa se realiza la unién de los componentes de software entre si y con los sistemas heredados. * Pruebas: desarrollo de planes de prueba, ejecucién y resultados de las pruebas. + Explotacién: fase de utilizacién del sistema por parte del cliente. * Mejora: es la correccién de fallas existentes. + Ampliacién: fase de agregado de nuevas caracteristicas. Requisitos I> Anaisis_ J Disefio I> Codificacién an Pruebas Mantenimiento| Figura 6. La posibilidad de mayor interaccién entre fases brinda ventajas frente al modelo solamente secuencial. El modelo tradicional en cascada presenta la gran ventaja de delimitar las tareas y ofte- cet un marco de trabajo claro y simple que puede ser utilizado en proyectos de distin- to tamafio, costo y recursos. Sin embargo, también pose numerosas y profundas des- ventajas, entre las cuales se destacan los elevados costos y la alta carga de esfuerzo para hacer la documentacién. Los elevados costos residen en que para la ejecucién de las fa- ses posteriores se debe terminar la precedente, haciendo que los cambios en ésta alte- ren todo el proceso. Principalmente, se visualiza este problema en el anilisis de requi- [Eq PRocRAMACION ORIENTADA A OBJETOS Para saber mas sobre la programacién orientada a objetos, en www.research.att.com/~bs/ whatis.pdf podemos leer el articulo de Bjarne Stroustrup denominado “gQué es la Programacién Orientada a Objetos?”. Aunque tiene varios afios, puede aclarar los conceptos vistos en el capitulo, Stroustrup es un reconocido cientifico de la computacién, y el Lenguaje C++ es uno de sus aportes. 44El proceso de software sitos (ya que en la préctica estos han demostrado ser cambiantes) que obliga a retroce- der o replantear el andlisis y el disefio. La alta carga de esfuerzo en la documentacién aparece como contraposicién a la desorganizacién previa. El modelo tradicional inten- 16 conferir de mayor calidad a los procesos aumentando el nivel de documentacién en cada fase, Esto provoca que mucha documentacién termine siendo redundante e inne- cesaria y en lugar de aportar conocimiento sélo es tomada como un gasto innecesario. Comienzo del disefio de un sistema Compilacién de la primera versién de un programa Si NO Implementacién Conformidad Correccién del del programa del usuario respecto programa no terminado del sistema aprobado Figura 7. Los modelos anteriores al de cascada basaban su desarrollo en el error. Entonces, con el modelo en cascada tenemos un marco de trabajo que establece que una etapa debe finalizar antes de comenzar la siguiente. Desde un punto de vista te- érico esto puede parecer viable, sin embargo en Ia prictica las etapas son comtin- mente superpuestas a fin de acelerar los tiempos de produccién y reducir los costos. También se trabaja generalmente de una forma conocida como modelo en casca- da con retroalimentaci6n, en el que el resultado total o parcial de una etapa pos- terior es utilizado retrocediendo y alterando la anterior. Es importante destacar que a pesar de que el modelo nos da un marco, nunca nos menciona qué herramientas debemos utilizar en cada etapa. Debido a esto, tenemos que ser capaces de seleccionar las herramientas que utilizaremos y en las cuales confiaremos parte del éxito. Modelos evolutivos Los modelos evolutivos suponen la confrontacién de lo desarrollado con los deseos de los clientes. Obteniendo la respuesta del cliente més las mejoras que aporta el equi- po de desarrollo se refina y valida el sistema a fin de alcanzar los objetivos propuestos. Dentro de lo que se denominan modelos evolutivos encontramos distintas variacio- ane 452. PARADIGMAS Y SOFTWARE nes aunque el principio es el de acercar las posiciones entre el cliente y el desarrollador sobre una estructura construida para mejorar en la siguiente aproximacién. Prototipos e incremental El modelo de prototipado es un modelo evolutivo que establece iteraciones cor- tas de forma tal de mostrarle los avances al cliente. A fin de poder acelerar el desa- rrollo para contrastar resultados, muchos de los prototipos son construidos hacien- do hincapié en caracterfsticas visibles (pero secundarias para la arquitectura) como las interfaces, los reportes o la carga de datos. La principal diferencia que puede tener con otros modelos evolutivos es que se acep- ta desechar (prototipo desechable) todo el producto construido a fin de progresar en la siguiente iteracién. Este uso de descarte es una medida muy util cuando se quiere mejorar la calidad. Una vez alcanzada la madurez suficiente en el conoci- miento del problema, se descarta el sistema y se construye con enfoque en practicas de calidad. Algunas de las ideas de los modelos evolutivos serdn luego utilizadas en metodologias menos tradicionales. ‘A pesar de que el modelo por prototipos presenta suficientes ventajas (mayor conoci- miento del sistema por parte de clientes y usuarios y menos problemas de interaccién de fases erréneas), uno de los mayores riesgos es que los desarrolladores (durante tan- to tiempo concentrados en cuestiones secundarias) utilicen los prototipos como siste- mas finales, ya sea para cumplir con un calendario de entregas o un plan de costos. Requerimiento del cliente Desarrollo El cliente prueba Figura 8, La respuesta del cliente frente al prototipo presentado es fundamental para la siguiente construccién. El modelo incremental presenta grandes parecidos con el modelo de prototipado. Se busca satisfacer al cliente desarrollando un conjunto de todos los requisitos que I solicits al equipo de trabajo. En el modelo evolutivo se busca incorporar la nue- 46 aaael proceso de software va funcionalidad de la iteracién sobre la estructura desarrollada. Esto obliga a que cada uno de los desarrollos, a pesar de estar orientado a satisfacer al cliente desde la superficie del sistema, tenga el sustento suficiente para que el agregado de caracte- risticas pueda incorporarse sin inconvenientes. Lineamientos Si Identificar necesidades basicas Desarrollar un modelo funcional I Demostracién dentro del contexto, obtener Tefinamientos, etcétera Hacer correcciones sobre el prototipo zlmpacto NO Enfoque de especificacion rigurosa Ze necesita ‘componentes de detalle? Afinar el prototipo y el documento 2 rigurosa Componentes de la especificacién Si Figura 9. Observamos que el proceso de construccién del prototipo Incluye distintos pasos y alternativas. 472. PARADIGMAS Y SOFTWARE Modelo en espiral s un modelo mixto propuesto por Barry Boehm que conjuga las practicas del modelo clasico junto a tendencias evolutivas. El resultado es un modelo con el cual se desarrollan versiones de software con mayor funcionalidad por iteracién. Se definen cuatro actividades: Planificacién: se entrevista al cliente y se obtiene la informacién importante para el resto de la iteracién. Anilisis de riesgo: se evalia en base a la composicién del equipo de desarrollo, del proyecto y los nuevos requisitos, las posibles amenazas y debilidades del proyecto. * Construccién: fase propiamente dicha de desarrollo, construccién del sistema en base al andlisis y a los objetivos para esta etapa. Evaluacién: el cliente realiza un relevamiento critico del entregable y en base a esto se inicia una nueva iteracién. Validacién Pianifieacién Construccién Analisis, Figura 10. En el modelo en espiral los requisitos del cliente son tomadbs al andlisis de cada iteracion. Modelo de desarrollo de componentes El modelo de desarrollo de componentes es un intento de mejora sobre el modelo de construccién en espiral. Se puede materializar en la practica gracias a los para- digmas de andlisis, disefio y programacidn orientada a objetos. Con sus caracteris- ticas esenciales, los lenguajes orientados a objetos permiten generar componentes denominados clases. De esta manera se obtienen elementos que pueden ser estan- darizados, evaluados y alterados para aplicarlos a un proyecto en particular. El pro- ceso de creacién de clases consta de tres etap 48Paradigmas de desarrollo * Identificacién del componente necesario. + Buisqueda del componente en nuestra biblioteca de clases. * Creacién 0 uso del componente: si el componente se encuentra disponible lo uti- lizamos, de otra forma se pasaré a un proceso de creacién de las clases. Las clases que se encuentren disponibles deben ser adaptadas. Un punto importante del modelo es que los componentes que més tiempo Ilevan dentro de la biblioteca se encuentran més depurados y por lo tanto los resultados finales pueden alcanzar gran calidad. Estos procesos se ubican en la fase de ingenierfa del modelo en espiral. Se puede decir que los desarrollos actuales usan algunas de las caracteristicas del desarrollo de componentes aunque sea utilizando otros proceso de software, pe- ro aplicando la reutilizacién de objetos. La industria actual ha entendido que es- tandarizar y distribuir objetos que puedan ser usados por desarrolladores permi- ten estructuras de confianza a la vez que promocionan los productos que posibi- litan mejoras bajo este sistema. A) v we US C Figura 11. Podemos asemejar el desarrollo por componentes con un rompecabezas. PARADIGMAS DE DESARROLLO Comentamos, al iniciar el capitulo, las diferencias entre metodologia y paradigma. El desarrollo estructurado y el orientado a objetos son paradigmas o modelos de desarro- Ilo. A pesar de coexistir en el ambiente real, la programacién estructurada ha perdido fuerza debido, principalmente, a que el paradigma de objetos, junto con las metodo- logias de desarrollo que lo utilizan o recomiendan, han podido solucionar las princi- ane 492. PARADIGMAS Y SOFTWARE pales falencias del desarrollo estructurado en especial en productos industriales 0 con alta escalabilidad. Es conveniente conocer los principios del desarrollo orientado a ob- jetos independientemente del lenguaje que se piense utilizar para implementarlo DESARROLLO ORIENTADO A OBJETOS EI software presenta caracteristicas particulares que hacen que su complejidad al- cance niveles importantes. A través de los afios, los investigadores, ingenieros y de- sarrolladores han intentado minimizar esa dificultad incorporando distintas ideas de otros Ambitos al del software. Entre los paradigmas de desarrollo actuales mas des- tacados encontramos el orientado a objetos y el orientado a estructuras. Evolucién de la Metodologia de la Programacién Cédigo Programacién Programacién espagueti estructurada ovientada a objetos Figura 12. Podemos observar el ejemplo clésico de la evolucién de los paradigmas de desarrollo y programacién. Detras de estos paradigmas se encuentran distintas visiones de cémo se puede disminuir la complejidad y obtener software de calidad. Cada uno incorpora una serie de técnicas particulares y tiene una visién distinta de cémo puede enfocar- se un desarrollo. El paradigma orientado a objetos plantea que un sistema pue- de ser visto como objetos que tienen ciertas caracteristicas y que colaboran entre ellos para realizar una tarea. Este simple acercamiento nos da las bases para po- der explicar conceptos mas avanzados [ey Lencuases De PROGRAMACION El lenguaje de programacién Smalltalk, considerado el primer lenguaje de objetos, es una ver- dadera plataforma de elementos. Todo en Smalltalk es un objeto, incluida la misma plataforma Para aprender mas del lenguaje podemos visitar el sitio oficial en la direcciswww.smalltalk.org lel contenido de este sitio web se encuentra en inglés). 50Desarrollo orientado a abjetos Subprogamas Programa principal Figura 13. Programa orientado a las estructuras del paradigma denominado estructurado. El modelo de objetos El modelo de objetos no es slo una forma de programar sino que nos brinda los cimientos para poder desarrollar todo tipo de soluciones bajo sus principios. Mu- chas de las premisas de este paradigma han sido obtenidas de otras ingenierfas y ac- tividades. La Ingenierfa Civil y la Aeronautica han servido de gufa para la incorpo- racién de elementos al software. La principal razén que hace atractivo a este mode- lo es la capacidad que tiene para combatir la complejidad inherente y disminuir los riesgos en el desarrollo. Otros paradigmas también tienen sus éxitos en estos pun- tos pero el modelo de objetos no se resiente tanto en proyectos de gran alcance. La escalabilidad no lo afecta de forma tan profunda como a otros paradigmas. | Estructura de clases Modelo légico Estructura de objetos Arquitectura de médulos Modelo fisico Arquitectura de procesos Figura 14, Modelado de software disefiado bajo el paradigma orlentado a objetos. Podemos observar la pequefia frontera entre el modelo y la practica.2. PARADIGMAS Y SOFTWARE El modelo orientado a objetos presenta algunos elementos que son denomina- dos fandamentales (cabe aclarar que existen diversos desarrolladores que son pi- lares de la teorfa de objetos, en nuestro caso utilizaremos un modelo adaptado al que presenta Grady Booch): * Jerarquia + Abstraccién * Modularidad * Encapsulamiento Si cualquiera de estos elementos esté ausente, no podemos considerar al paradigma como modelo de objetos. Ademés, existen otros elementos opcionales: * Tipos (tipificacién) * Concurrencia * Persistencia Estos elementos brindan mayor robustez al modelo sin que su ausencia sea defi- nitoria. Cabe destacar que estos componentes son discutidos de acuerdo a distin- tos marcos y enfoques tedricos, pero el esquema que presentamos primero es el tradicionalmente aceptado. Hemos visto los elementos, ahora intentaremos explicar, de manera simple, a qué nos referimos con cada uno, recordando que no es nuestra intencién abordar el mo- delo de forma teérica sino ser capaces de utilizarlo. Jerarquia La jerarquia no es més que la posibilidad de realizar un ordenamiento en niveles de lo que deseamos representar. De manera practica, esa jerarqufa se ve representada por la herencia, que puede ser de distintos tipos. Entre las mas frecuentes encontramos la simple, la multiple y la restrictiva. Todos los lenguajes orientados a objetos (OO ) mo- dernos nos brindan la posibilidad de heredar comportamiento. [Dy tpavo Fuerte Los lenguajes de tipado fuerte especifican las restricciones que deben aplicarse sobre las ope- raciones que involucran valores que poseen diferentes tipos de datos. Generalmente, todos los Lenguajes de programacién determinan ciertas limitaciones, pero los que se consideran de tipa- do fuerte son aquellos que controlan esas restricciones de forma estricta. 52Desarrollo orientado a abjetos Vehiculos Autos Camiones Motos Motor a nafta Diesel Figura 15. Ejemplo de jerarquia donde observamos relaciones aparentes entre elementos. Abstraccion Este término es quizés el més simple de entender, pero el que mas problemas pre- senta a la hora de ser puesto en practica. La abstraccién es un proceso intelec- tual humano por el cual somos capaces de concentrarnos particularmente en las caracterfsticas que nos interesan para la solucién de una situacién. Al atacar un problema, intentamos resolverlo mediante la aplicacién de pasos que hemos uti- lizado previamente y que sabemos (0 creemos) que funcionardn. Al presentarse un caso nuevo, 0 que aparenta serlo, lo que hacemos es obtener de él todas las simi- litudes con casos anteriores y a su vez tratar de ver cudles son las particularidades que pucden interesarnos. Este proceso es especifico de cada problema y de cada disefio, y en algunas ocasiones las caracteristicas menos pensadas son las relevan- tes para la resolucién de la dificultad, Modularidad Este concepto no es propio de la OO, sino que es uno de los que més se ha desa- rrollado en la Ingenierfa de Software. El objetivo final es la divisién de un proble- ma complejo en unidades més pequefias y casi siempre més sencillas. A su vez, la separacién en médulos crea fronteras artificiales que permiten que los grupos de- sarrollen soluciones por separado integrandolas con mayor facilidad. Los médulos [Dy Astraccion Generalmente, un mayor nivel de abstraccién en el lenguaje se traduce en unas instrucciones més potentes y, por lo tanto, menos lineas de cédigo. Como contrapartida, el desarrollador deja de estar en control de muchas actividades y los compiladores deben agregar gran cantidad de cédigo auxiliar para poder ejecutar ese cédigo fuente.2. PARADIGMAS Y SOFTWARE interactitan entre ellos y pueden ser transportados a otros proyectos en caso de ne-~ cesidad. La reutilizacién es uno de los pilares del modelo orientado a objetos. Médulo 1 Mt Médulo 2 Médulo 2.1 J+] Médulo2.2 J++) Médulo 2.3 i Médulo 3 Médulo 3.1 Médulo 3.2 Figura 16. Una aplicacién dividida en méduios permite mayor facilidad a la hora del mantenimiento. Encapsulamiento El encapsulamiento es el ocultamiento de la informacién de forma tal que sdlo esté disponible para interactuar con un objeto sin la necesidad de conocer cémo se com- porta internamente. Este factor hace que los objetos sean facilmente reutilizables. Ade- més, junto con los conceptos vistos anteriormente, crea la estructura precisa para una reduccién de la complejidad. Muchas veces al encapsulamiento se lo relaciona correc- tamente con el término caja negra. Un ejemplo sencillo ocurre cuando somos capaces de manejar algtin artefacto sin saber exactamente qué es lo que ocurre internamente En este caso, el ocultamiento de informacién nos facilita la interaccién. Hasta aqui hemos definido los cuatro componentes esenciales y podemos obser- var cémo estan intimamente relacionados al punto de ser casi indispensables las DJ moputarivan El concepto de modularidad ha acompafiado a toda la evolucién de la Ingenieria del Software. Desde miiltiples puntos de vista es siempre conveniente descomponer el problema y hacer coin- cidir esas partes con médulos de cédigo. Esto requiere el dominio de las técnicas de analisis y disefio correspondientes. 54Desarrollo orientado a abjetos prestaciones de uno para que el otro se pueda comportar de la forma adecuada y brindar las facilidades necesarias. A continuacién, luego de la siguiente ima- gen, comentaremos los tres elementos restantes. a YS Figura 17. Vernos un objeto en cuyo centro se encuentran los atributos, los cuales s6lo pueden ser accedidos mediante los métodos. Tipos ( Los tipos permiten representar las abstracciones de forma adecuada. Es ms senci- Ilo ejemplificar el concepto diciendo que si realizamos una suma de dos ntimeros enteros esperamos obtener otro mimero entero y no uno decimal Concurrencia La concurrencia supone que en la solucién de un problema se manejan toda clase de eventos y muchas veces algunos interacttan de manera asincrénica, pero tam- bign pueden hacerlo simultaneamente. Es por esta posibilidad (en realidad es fre- cuente la simultaneidad de eventos) que debemos incorporar mecanismos para la correcta operacién en casos de interaccién concurrente. Entre estos podemos citar el manejo de las sobrecargas y la prioridad de accesos. Objeto 1 7 Objeto 3 Figura 18, La interaccién entre objetos facilita la solucién del problema. ane 552. PARADIGMAS Y SOFTWARE Persistencia La persistencia es lo que posibilita que trabajemos guardando informacién du- rante el tiempo que necesitamos operar con ella. Decimos que un objeto ocupa un espacio en memoria y existe 0 permanece en ella durante cierto lapso de tiem- po. La persistencia nos permite mantener el estado del objeto. El objeto como base Légicamente, la orientacién a objetos presenta muchas caracterfsticas comunes a otro tipo de prdcticas. Lo que la distingue es que pone el énfasis en definir y ca- racterizar de forma clara los componentes del sistema, dotandolos de sus capaci- dades. En el objeto se unen los datos y los algoritmos. Es asi como se transfor- ma en la piedra fundamental de esta estructura. Un objeto debe poser cualidades que lo definan en esencia, es decir, tendra pro- piedades invariantes que lo caracterizan a él y a su forma de actuar. Para com- prenderlo mejor, podemos pensar en cualquier elemento. Veremos que nos apa- recerén aparecerén muchos rasgos sin los cuales es imposible concebir la idea de éste como una representacién de la realidad. Por ejemplo, no podemos imaginar un objeto auto sin su potencial capacidad para desplazarse o un perro sin la fa- cultad del ladrido. Estas caracterfsticas forman parte intrinseca del objeto y se- rdn seguramente representadas cuando modelemos Programacién orientada a objetos Si queremos definir qué es exactamente la programacién orientada a objetos (también conocida como OO) y qué no es, nos encontraremos en serias dificul- tades. La explicacién podrfa tornarse trivial 0, muy por el contrario, alcanzar gran cantidad de confusas expresiones Una excelente definicién que nos permite solucionar el problema de explicar qué es la programacién orientada a objetos es la utilizada por los seguidores del de- sarrollador e ingeniero de software Grady Booch, incluida en su libro Andlisis y disefio orientado a objetos, que citamos a continuacién [DD cusses ¥ obsetos Las clases permiten la agrupacién de objetos que comparten las mismas propiedades y compor- tamientos. Si bien clase y objeto suelen usarse como sinénimos, no lo son. El esfuerzo de los de- sarrolladores ante una aplicacién orientada a objetos se centra en la identtficacién de las clases, sus atributos y operaciones asociadas. 56Desarrollo orientado a abjetos “La programacién orientada a objetos es un método de implementacidn en el que los programas se organizan como colecciones cooperativas de objetos, cada uno de los cua- les representa una instancia de alguna clase, y cuyas clases son, todas ellas, miembros de una jerarquia de clases unidas mediante relaciones de herencia”. Objeto 4 Objeto 6 Odjeto 3 Objeto 5 Objeto 1 Figura 19. Un simple gréfico de objetos puede presentarnos una idea de la interaccién de los componentes. BW Resumen En este capitulo hemos presentado ta di Repasamos estos tiltimos teniendo en cuenta su aparicién en el mundo del software. El ciclo de vida clasico es el que tenemos como referencia para definir y estructurar los desarrollos de software. Paradigmas como el estructurado o el orientado a objetos conviven actualmente, aunque la industria ha adoptado el desarrollo orientado a objetos por sus particularidades y la forma en que pretende resolver los problemas del trabajo diario. ncia entre paradigma y modelo de desarrollo. SERS | 87ACTIVIDADES PREGUNTAS TEORICAS 1 (Qué es una metodologia? 2 {Qué paradigmas de desarrollo conoce? 3 {Qué es el proceso de software? 4 ;Cémo podemos dividir los modelos? 5 {Cudles son las fases del ciclo de vida en cascada? 6 {Qué es el desarrollo basado en componentes? 7 En que industrias aplicaria el desarrollo basado en componentes? 8 {Qué es el disefio orientado a objetos? 9 (Aqué se denomina clase? 10 ,Cémo explicaria el concepto de modularidad? 58 EJERCICIOS PRACTICOS 1 Investigue acerca de otros paradigmas de desarrollo, 2 Mencione elementos que eviten los problemas de concurrencia. 3 Enumere posibilidades para dominar la complejidad. & Investigue acerca de las clasificaciones de abstraccién 5 Investigue las ventajas y desventajas de la programacién orientada a objetos. essaMétodos agiles Software Ahora que conocemos acerca de los sistemas, el software y los procesos de desarrollo tradicionales, avanzaremos sobre las metodologjas tradicionales, sus inconvenientes, los problemas de gestidn y las metodologias Agiles SERVICIO DE ATENCION AL LectoR: lectores@redusers.com Desarrollo de software Metodologias tradicionales Desarrollo de sistemas Jackson Ingenierfa dela informacién Método de andliss y disefio estructurado Nétrica Estructura Roles y perfiles PMBOK Comprender el problema \dentificar la solucion Desarolla la solucién Composicién del equipo y jefe de proyecto Planficacion y gestion de riesgo Control y seguimiento Cierre del proyecto Lanzamiento del proyecto PRINCE? Procesos y componentes Metodologias dgiles Programacién extrema (XP) Serum Crystal Clear Feature Driven Development (FDD) Adaptive Software Development (ASD) Seleccionar una metodologia Resumen Actividades 60 1 8 4 65 a1 9 B 5 1 8 8 18 19 a1 82 2 8 8 “4 5 86 86 7 a7 49 49 903. SOFTWARE DESARROLLO DE SOFTWARE El desarrollo de software ha pasado a ser una industria destacada, con practicas y metodologias propias. Todo proyecto de software debe obedecer a pautas preesta- blecidas. Existe una rama de la Ingenierfa denominada Ingenieria de Software que designa el conjunto de técnicas destinadas a la produccién de software. La Inge- nieria de Software se encuentra formada por muchas disciplinas, desde ciencias de la computacién hasta matemética, y constantemente interactia con éstas. Ademés, la gestién de proyectos es uno de los elementos clave en el desarrollo de software y como tal no puede ser dejada de lado en ningtin estudio serio sobre éste. Todo proyecto de software sigue una metodologia especifica seleccionada por sus desarrolladores. Dentro de las metodologias de software podemos encontrar una gran divisién entre las tradicionales y las no tradicionales. La mayoria de los cambios en ciclos de vida en cascada La mayoria de los cambios en ciclos de vida J iterativos 2 Tiempo Figura 4. La introduccién de cambios es més costosa a medida que el proyecto avanza. Las distintas metodologias pueden mitigarlo. Las metodologias denominadas tradicionales hacen referencia al conjunto de practicas que se aplican con cierto éxito desde hace muchos afios y en las cuales encontramos la tendencia a ocuparse y centrar esfuerzos en la documentacién, las précticas bien delimitadas, los avances o progresos prefijados. Estas meto- dologias intentan reducir el riesgo mediante una fuerte recoleccién de requisitos y una planificacién detallada para no dejar lugar a los imprevistos. Como con- traparte, las metodologias Agiles prefieren optar por un esquema més realista, 60 aaaMetodologfas tradicionales partiendo de la base que el imprevisto no puede set anulado, que no se puede predecir, el cambio ocurrira y es bueno adaptarse a éste. De todas maneras, el objetivo final de toda metodologia debe ser la maximizacién de los recur- sos y el aseguramiento de la calidad. Para continuar con nuestro estudio veremos algunas de las metodologias tradi- cionales, luego estudiaremos los principios de gestién tradicional y gil y para fi- nalizar veremos una introduccién a las metodologias dgiles, que luego seran de- talladas en los siguientes capitulos METODOLOGIAS TRADICIONALES Ante la crisis del software se buscaron posibles soluciones orientadas a ordenar los proyectos bajo distintos procesos y darles herramientas a los desatrolladores y ges- tores. Los dos enfoques metodoldgicos se distinguen principalmente por: Tee TEs El cliente se relaciona con el equipo, El cliente es parte integral del equipo de desarrollo pero no participa, Se selecciona una arquitectura al comienzo Se redefine la arquitectura a medida que del proyecto. el proyecto avanza. El individuo esté definido de acuerdo Se valoriza al individuo y sus capacidades. a su posicién y rol. Se intenta disminuit las posibilidades de cambio. Se sabe que el cambio ocurrird y se lo espera. Destinado a proyectos de todo tamafio, Generalmente aplicable en proyectos pequefios. Grandes cantidades de artefactos y elementos Pocos elementos para modelar y documentar. de documentacién. Tabla 1. Principales diferencias entre metodologias tradicionales y agiles. La tabla anterior es sélo una tendencia y no debe tomarse como una ley, sino sim- plemente como la prioridad de cada enfoque. Veamos una tabla cronolégica que nos muestra el momento de aparicién de algunas metodologias: 1968 Concepcién sobre la programacién estructurada de DUKDTRA. 1974 Técnicas de programacién estructurada de WARNIER y JACKSON. 1975 — Primeros conceptos sobre disefio estructurado de MYERS y YOURDON. 1977 — Primeros conceptos sobre el andlisis estructurado de GANE y SARSON. 1978 Analisis estructurado: DEMARCO y WIINBERG. Nace MERISE. 1981 SSADM. Information Engineering. SERS | 613. SOFTWARE 1985 — Anilisis y disefio estructurado para sistemas de tiempo real de WARD y MELLOR. Modificacién a la SSDAM. 1986 SSADM versién 3. 1987 Andlisis y disefio estructurado para sistemas de tiempo real de HATLEY Y PIRHBAY. 1989 Métrica 1990 SSADM versién 4 1993 Métrica versién 2 1995 — Métrica versidn 2.1 Tabla 2. A pesar de ser las mas destacadas, existen muchas otras metodologias. Se han desarrollado y atin se desarrollan infinidad de metodologias tradicionales. Muchas de ellas comienzan en el marco teérico hasta que luego son rescatadas por la industria, mientras que otras no pasan de la primera etapa. Veamos aho- ra algunas metodologias tradicionales: * Desarrollo de sistemas Jackson (JSD) Ingenieria de la informacin * Método de andlisis y disefio estructurado (SSADM) * Métrica * PMBOK * PRINCE2 * MSF x Gq Entre las que seleccionamos, existen algunas que posiblemente no sean considera- das metodologfas, sino marcos de trabajo o procesos de gestién (PRINCE2) y otras que pueden acercarse a las metodologias agiles (MSF y RUP). Sin embargo, preferimos esta clasificacién para dar una visién mas general y dejar su uso y ubi- cacién a criterio del lector. Debemos destacar que la denominacién metodologias tradicionales no se toma desde un punto de vista cronolégico, sino solamente en base a los principios que son esenciales para cada una de ellas. Ee nrovas Si queremos conocer mas acerca de las metodologias tradicionales, es recomendable que vi- sitemos el sitio de Infolab de la Universidad de Standford, en donde podremos localizar arti- culos de interés sobre el desarrollo de cada una y su impacto en la industria. La direccién del sitio es http://infolab.stanford.edu/. 62Desarrollo de sistemas Jackson DESARROLLO DE SISTEMAS JACKSON El Desarrollo de sistemas Jackson (JSD) es una metodologia clésica, secuencial, sur- gida en los afios 80 y desarrollada por Michael Jackson y John Cameron. Actual- mente se encuentra en desuso, aunque algunas de sus ideas sitven de base para me- todologias mas modernas. La estructura de la metodologia puede ser dividida en tres fases, correspondientes a modelado, disefio ¢ implementacién. En la fase de mo- delado se crean diagramas de entidad que representan a las entidades dentro del sis- tema y las acciones que éstas realizan. No se especifican notaciones especiales ni ca- racteristicas para representar, quedando éstas a criterio del desarrollador. En la fase de disefio se representa el sistema completo con sus interconexiones, Se identifican los datos y el proceso genérico. En la fase de implementacién se convierten las re- presentaciones en un sistema real fisico. Desarrollo Analisis modelo procesos Figura 2. El desarrollo del modelo y el andlisis de procesos se realizan utilizando herramientas simples. El ciclo de vida no es muy complejo, proponiéndose estas etapas: Se desarrolla un modelo. Se analizan los procesos necesarios para construir la solucién. * Se construyen estos procesos. La implementacién de las soluciones ¢s total, sin estados intermedios. Dy rv El Rational Unified Process 0 Proceso Unificado de Desarrollo de Software constituye la meto- dologfa estandar més utilizada para el analisis, implementacién y documentacién de sistemas orientados a objetos. Puede ser utilizado para una gran cantidad de tipos de sistemas de soft- ware, para diferentes areas de aplicacién y diferentes clases de organizaciones.3. SOFTWARE EL JSD utiliza sélo un par de herramientas, siendo las més importantes el cono- cido diagrama de entidad (ESD, Entity Structure Diagram) y el diagrama de red (ND, Network Diagram). Vemos que el JSD es una metodologia muy sim- ple que casi no nos aporta informacién sobre la realizacién de los procesos, las métricas, los costos, la gestidn, etcétera. Es por esto que ha sido reemplazado por metodologias més evolucionadas. Entidad Figura 3. A pesar de que los ESD pueden ser graficados de distinta forma, siempre muestran la entidad con sus actividades. INGENIERIA DE LA INFORMACION La Ingenierfa de la informacién o, en inglés, Information Engineering Methodology (LEM) cs una metodologia para disefiar y desarrollar sistemas de informacién. Su historia se remonta a los aftos 70 y los 80, en donde fue definida como un con- junto de técnicas y tareas que mejoran la organizacién y permiten desarrollar los recursos, procedimientos y sistemas para lograrlo. Se puede decir que los crea- dores de esta metodologia son James Martin y Clive Finkelstein. La Ingenieria de la informacién se compone de fases y técnicas. Entre las primeras, podemos encontrar siete fases 0 etapas, denominadas: + Fase de planeamiento estratégico: en esta etapa se debe desarrollar un plan ade- cuado de implementacién. * Anilisis de contexto del negocio: se analiza una seccién y se contemplan las tare- as que se van a incluir para cubrir las necesidades del area de negocios. * Anilisis detallado del negocio: se proveen los modelos detallados necesatios. * Disefio del sistema: se construyen las especificaciones funcionales del sistema con téc- nicas 0 notacién que permitan el detalle y eliminen la ambigiiedad. 64Método de andlisis y disefio estructurado * Disefio técnico: las especificaciones funcionales dan pie a la construccién de los detalles técnicos necesarios para producir el sistema final. * Construccién: en base a las especificaciones creadas y de acuerdo a lo pautado se pasa a la etapa de codificacién 0 desarrollo del producto. * Transicién: es la etapa en la cual el sistema nuevo reemplaza al implementado. Las herramientas 0 técnicas utilizadas por la Ingenieria de la informacién son: * Anilisis de datos: se recolecta informacién sobre los datos utilizados por el area de negocios, por el sistema actual y sobre los posibles datos que manejaré el nuevo desarrollo. Se usan técnicas formales para hacer este anilisis, asi como también notaciones textuales. * Anilisis de entidades: identifica todos los elementos de interaccién como la re- lacién entre ellos. * Anélisis funcional: se desglosan las funciones de la empresa en un conjunto de funciones mas chicas a fin de reconocer la interaccién entre areas y procesos. * Dependencia de procesos: se estudian los intercambios de informacién entre los procesos y el pasaje de datos entre ellos. METODO DE ANALISIS Y DISENO ESTRUCTURADO EI SSADM es una metodologfa producida por el Reino Unido y desarrollada a partir de varias metodologfas estructuradas (Método estructurado de Yourdon, Progra- macién estructurada de Jackson y Andlisis estructurado de DeMarco). Tiene tres herramientas principales, las cuales representan al sistema de forma gréfica + Modelo légico de datos: se trata de documentar los datos requeridos por el sis- tema de informacin. Un modelo de légica de datos es similar a un diagrama de entidad-relacién, se representan las entidades y las relaciones entre ellas. Cliente Orden Figura 4, Ademas de representar las entidades, con el modelo de datos podemos ver la cardinaildad mediante los conectores.3. SOFTWARE + Modelo de flujo de datos: el flujo de datos ¢s un punto principal de todo el modela- do estructurado. Los datos son transformados a lo largo del sistema de informacién y el analisis de estas tranformaciones permite conocer mas sobre los procesos objeto. Cciente > Genera recamos Valida cliente Genera reporte Modifica saldo — Reportes Figura 5. En este tipo de grafico podemos observar al usuario, su accién, cémo el sistema responde a la accién y dénde almacena datos. * Modelo de evento, entidad: se localizan y documentan los eventos del sistema. Es importante destacar que la secuencialidad de eventos tiene que ser precisa. ‘Almacenaje Entidad externa Flujo de datos Proceso Figura 6. El DFD propuesto por Yourdon es el que tradicionalmente se utiliza en el andlisis de sistemas estructurado. Dy metovoosias Observamos que las primeras metodologias no se ocupan de tareas tan relevantes hoy en dia, co- mo el control de calidad, la gestién de los recursos y el analisis del negocio. Estas metodologias eran por lo general marcos de trabajo muy cercanos a las practicas de los desarrolladores. Las herra~ mientas utilizadas por estos métodos son general mente graficas y orientadas a la codificacién. 66Métrica La metodologia est4 estructurada en cinco fases fuertemente estructuradas. Cada una de estas fases puede ser desglosada en médulos o niveles. Las fases son: Estudio de viabilidad: son estudios de alto nivel de abstraccién concernientes a la factibilidad técnica, operativa y econémica. El objetivo es asegurarse que la inversién que se debe realizar es correcta de acuerdo a la solucién otorgada y al area de negocio objetiva. ‘Andlisis de requerimientos: es la etapa que hemos identificado anteriormente co- mo recoleccién de requisitos. Se utilizan herramientas conocidas como los DED (Diagramas de flujos de datos). La fase se realiza de forma exploratoria, aumen- tando el nivel de abstraccién en cada momento. Especificacién de requerimientos y especificacién ldgica: se incrementa el detalle de los requerimientos, con anilisis técnicos. Se empiezan a vislumbrar las tareas necesarias para llevar las ideas a la realidad. Disefio fisico: las especificaciones de requerimientos y Iégica son convertidas en un disefio fisico del sistema. on J El negocio t xa Figura 7. Los distintos tipos de graficos permiten acercarnos a la visién total del negocio. METRICA Matrica es una metodologia creada por algunos ministerios y organismos de la administracién de Espafia. Esta destinada a la planificacién, andlisis, disefio y construccién de sistemas de informacién. Presenta distintas versiones, siendo ane 673. SOFTWARE la versién 3 la utilizada actualmente, basada en el modelo de procesos ISO/IEC 12207 y en la norma ISO/IEC 15504. Es utilizada por los proyectos de la ad- ministracién publica y sus objetivos son: + Satisfacer las necesidades de los usuarios enfatizando el uso de andlisis de requisitos. + Aumentar el rendimiento de los departamentos de Sistemas y Tecnologia. + Establecer canales adecuados de intercambio de informacién entre los partici- pantes del proyecto. + Determinar roles, tareas y responsabilidades adecuadas y productivas. * Generar un marco de trabajo adecuado independientemente de la complejidad y grado de innovacién del proyecto. — METRICA. VERSION 3 Metodologia de Planificacion, Desarrollo y Mantenimiento de sistemas de informacion ‘Sepresntn en ra pigra ks dbaumer 412 conpanen Is matali ERICA VERSION 3 ICA vrs 9 ce se nde Hiei cin rca sein de carla Gar de prope inicio eck, ol Mri de 1. ESTRUCTURA PRINCIPAL 2. INTERFACES, ener dala Caldad ie contgracén ehrovatoe Figura 8. En el sitio de Métrica versién 3 podemos leer Jos documentos que componen la metodologia. Eq setovotosias En el sitio www.csae.map.es/csi/metrica3/index.html podemos consultar toda la documen- tacién correspondiente a Métrica versién 3 con las diferentes versiones y los cambios entre ellas. Ademés, alli nos ofrecen una gran cantidad de documentacién concerniente a proyec- tos realizados con esta metodologia con sus pormenores. 68Métrica Estructura Métrica tiene la particularidad de establecer niveles jerérquicos para el proyecto. Todo proceso o fase se divide en actividades y éstas en tareas. Se utiliza un tipo de notacién especial para poder identificar una tarea. De esta forma, tenemos que la denominacién F2 A2 T1 corresponde a la tarea 1 de la actividad 2 de la fase 2. Las fases son absolutamente secuenciales, no pudiendo empezar la 2 hasta no finalizar la fase 1. En cambio, las tareas pueden ser modificadas y realizadas en distinto or- den, En el caso de las actividades vemos cierta flexibilidad ya que siempre y cuan- do no se necesite el resultado de una actividad, ésta puede ser reordenada. Se defi- nen tres procesos principales: * Planificacién de sistemas de informacién: es el marco estratégico para los sistemas de informacién (PSI). * Desarrollo de sistemas de informacién: compuesto por las actividades necesarias para la generacién del software. Esté dividido en subprocesos denominados: ~ Estudio de viabilidad del sistema (EVS). ~ Analisis del sistema de informacién (ASI). ~ Disefio del sistema de informacién (DSI). ~ Construccién del sistema de informacién (CSD) - Implantacién y aceptacién del sistema (IAS). * Mantenimiento de sistemas de informacién: mantenimiento correctivo y evolu- tivo del software. Desarrollo Planificacién aS Mantenimiento de sistemas de de sistemas de informacién ASL informacion DSI PSI Msi CSI TAS Aseguramiento Gestion de Gestién de de calidad proyectos. configuracién Seguridad Figura 9, Con Métrica versién 3 es posible gestionar proyectos orlentados a objetos y proyectos estructurados.3. SOFTWARE Planificacion de sistemas de informacion (PSI) Se planifica y genera la documentacién necesaria para establecer a los sistemas de informacién como soporte pata las operaciones de la empresa. Como resultado de la ejecucién de esta fase, el equipo obtiene documentacién respecto a la situacién actual, los nuevos requerimientos y el conjunto de acciones que se realizarin. Se compone de nueve actividades bésicas: * PSI 1 - Inicio del PSI. * PSI 2 - Definicién y organizacién del PSI. * PSI 3 - Estudio de la informacién relevante. + PSI 4 - Identificacién de requisitos. * PSI 5 - Estudio de los sistemas de informacién actuales. * PSI 6 - Disefio del modelo de sistemas de informacién. + PSI 7 - Definicién de la arquitectura tecnolégica. + PSI 8 - Definicién del plan de accién. + PSI9 - Revisién y aprobacién del PSI. Estudio de viabilidad del sistema (EVS) El estudio de viabilidad parte de la situacién actual a la cual le suma el andlisis de requisitos, En base a esto evaltia las posibilidades para brindar una solucién y la factibilidad. De acuerdo a las investigaciones realizadas se decide continuar con el proyecto o detener su evolucién, Se describe la solucién adoptada y las opciones presentadas, las caracteristicas de cada una y los criterios de seleccién Esté integrada por seis actividades: EVS 1 - Establecimiento del alcance del sistema. * EVS 2 - Estudio de la situacién actual. VS 3 - Definicién de requisitos del sistema. * EVS 4 - Estudio de alternativas de solucién EVS 5 - Valoracién de las alternativas. + EVS 6 - Seleccién de la solucién. Anlisis del sistema de informacion (ASI) En este subproceso se especifican los requerimientos y se generan los modelos ne- cesarios: casos de uso, clases, datos y procesos. Se compone de once actividades, que vemos a continuacidn: * ASI 1 - Definicién del sistema. * ASI 2 - Establecimientos de requisitos. * ASI 3 - Identificacién de los subsistemas de andl * ASI 4 - Andlisis de los casos de uso. 70Métrica * ASI 5 - Analisis de clases. + ASI6 - Elaboracién del modelo de datos. + ASI7 - Elaboracién del modelo de procesos. + ASI 8 - Definicién de interfaces de usuario. + ASI 9 - Anilisis de consistencia. * ASI 10 - Especificacién del plan de pruebas. * ASI 11 - Aprobacién del andlisis del SI. € Redactor Editor Crear contenido Y proponer su publicacién Navegar por contenidos Autorizar publicacién de contenidos Mantener el contenido publicado Figura 10. Los casos de uso son una de las herramientas seleccionadas por Métrica para la representacién del sistema. Disefio del sistema de informacion (DSI) El disefto espera la generacién de las especificaciones relativas al desarrollo y cons- truccién del sistema. Se desarrollan los modelos de arquitectura, los casos de uso, las clases y el disefto de la interfaz de usuario. Los planes de implementacién y prue- ba también son creaciones de esta fase. A continuacién veremos una lista de las ac- tividades que constituyen esta fase. DST 1 - Definicién de la arquitectura del sistema. DSI 2 - Disefio de la arquitectura de soporte. DSI 3 - Disefio de casos de uso reales. DSI 4 - Disefio de clases, DSI 5 - Disefio arquitecténico. DSI 6 - Disefio fisico de datos. 743. SOFTWARE + DSI 7 - Verificacién y aceptacién de la arquitectura del sistema. + DSI 8 - Generacién de especificaciones de construccién. + DSI 9 - Disefio de la migracién y carga inicial de datos. + DSI 10 - Especificacién técnica del plan de pruebas. + DSI 11 - Establecimiento de los requisitos de implantacién. + DSI 12 - Aprobacién del disefio del SI. Construccion del sistema de informacion (CSI) La construccién y la prueba se llevan a cabo en esta fase, generando como resul- tado no sdlo el cédigo, los ejecutables y la documentacién final, sino todos los resultados para las pruebas de aceptacién, unitarias y de integracién. Las activi- dades son nueve: * CSI 1 - Preparacién del entorno de construccién. * CSI 2 - Generacién del cédigo de los componentes y procedimientos. * CSI 3 - Pruebas unitarias. * CSI 4 - Pruebas de integracién. * CSI 5 - Pruebas del sistema. * CSI 6 - Elaboracién de los manuales de usuario. * CSI 7 - Definicién de la formacién de los usuarios finales. + CSI 8 - Generacién del cddigo de los componentes. + CSI9 - Aprobacién del sistema de informacién Implantacion y aceptacién del sistema (IAS) Se hace la entrega, la implementacién del sistema en los ambientes reales y el resulta- do final de la fase es el sistema funcionando. Se compone de las siguientes actividades: + IAS 1 - Establecimiento del plan de implantacién. + IAS 2 - Formacién necesaria para la implantacién. + IAS 3 - Incorporacién del sistema al entorno de operacién. + IAS 4 - Carga de datos en el entorno de operacién. + IAS 5 - Pruebas de implantacién del sistema. + IAS 6 - Pruebas de aceptacién del sistema. + IAS 7 - Preparacién del mantenimiento del sistema. + IAS 8 - Establecimiento del acuerdo del nivel de servicio + IAS 9 - Presentacién y aprobacién del sistema + IAS 10 - Paso a produccién. Mantenimiento de sistemas de informacién (MSI) Como hemos comentado, el tipo de mantenimiento contemplado en la metodolo- gia incluye el corrective y el preventivo, quedando el adaptative por fuera de ésta. 72 eaeMétrica Los registros de cambios y actividades de control para el mantenimiento se llevan a cabo en esta fase. Se encuentra formada por las siguientes actividades: MST 1 - Registro de la peticién. MSI 2 - Anilisis de la peticién. MST 3 - Preparacién de la implementacién de la modificacién. MSI 4 - Seguimiento y evaluacién de los cambios hasta la aceptacién. Usuario Set imagenes Nombre Nombre Pass 1 Deseripeién Apelido 1 _, [imagen Foto Descripcién Titulo Figura 11. La mayoria de los proyectos realizados con la metodologia siguen el paradigma de objetos y, por Io tanto, se nutren de herramientas como el diagrama de clases. Roles y perfiles Teniendo en cuenta que la metodologfa Métrica est pensada para el Ambito pu- blico, los perfiles son bien delimitados y su entrenamiento, caracteristicas y respon- sabilidades estan, también, bajo el estandar. Veamos, en las préximas paginas, las caracteristicas de cada uno de ellos. Directivo Es personal con poder de decisién en la organizacién, tiene visién general y estra- régica del negocio. Dentro de esta categoria tenemos: * Comités de direccién y seguimiento: son los que proven o garantizan los recursos necesarios y tienen capacidad de solucionar inconvenientes respecto al proyecto: * Directores de usuarios: representan a los usuarios finales, determinan los re- quisitos y los deseos de estos * Usuarios expertos: poseen conocimientos acabados sobre la materia y pueden guiar el desarrollo o establecer requisitos a distinto nivel que los usuarios finales. ane 33. SOFTWARE Directivos Jefe de proyecto Jefe de proyecto Consultor Analistas Analistas Analistas | | Desarrolladores Figura 12. Los roles y catgos definidos por Métrica son bastante estructurados y estén de la mano del tipo de proyecto al cual estén destinados. Jefe de proyecto El jefe de proyecto tiene las atribuciones y responsabilidades tradicionales para este tipo de rol. Es el encargado de dirigir los recursos humanos, coordinar la co- municacién, establecer las metas y los calendarios. Existen otras tareas de igual nivel cuyo responsable puede ser el mismo jefe de proyecto o un especialista con poder de gestién. Entre estos encontramos a los responsables de seguridad, cali- dad, implementacién y mantenimiento. Consultor Los consultores externos o internos brindan su conocimiento y apoyo a fin de faci- litar la decisién de los jefes de proyecto. Existen distintos perfiles de consultor que pueden participar de un proyecto, desde los puramente financieros hasta los técni- cos con aplicacién en tareas de bajo nivel. Analista Los analistas divididos en distintos cargos realizan la tarea de recoleccién de re- quisitos y andlisis de contexto. A su vez, luego son los encargados de bajar el ni- vel de los anilisis efectuados para generar la documentacién que utilizaran los desarrolladores en las siguientes etapas. Los perfiles pueden ser separados en: ana- lista, administrador de bases de datos, instructores, analistas de seguridad, so- portes técnicos, aseguramiento de la calidad. 74 aaaPMBOK Programador Los programadores desarrollan el proyecto, generan las estructuras y escriben todo el cédigo necesario para finalizar el proyecto. Vemos que, sin indagar a fondo, ya tenemos mas de cincuenta actividades deli- mitadas. La metodologia define también, para cada fase, los documentos de en- trada y la salida producida (aqui comentada brevemente). Una de sus ventajas es que puede ser consultada libremente y que su amplia difusién hace que tenga las revisiones y actualizaciones necesarias. La rigidez del proceso y su poca agili- dad no la hacen menos titil en los tipos de proyectos a los que apunta (grandes proyectos ptiblicos), en donde la generacién de pautas y normas puede influir en las decisiones y producir grandes beneficios. Las herramientas utilizadas gene- ralmente son las que corresponden al tipo de implementacién seleccionado, sien- do UML la notacién preferida en la actualidad, En las proximas paginas conoceremos dos metodologias que si bien no son de software y estan orientadas a la gestién de proyectos, actualmente son esenciales en los proyectos informéticos. PMBOK Project Management Book of Knowledge (PMBOK) es un conjunto de herra- mientas y buenas prdcticas para la gestién de proyectos. Es mantenido por el Pro- ject Management Institute (PMI) y se encuentra orientado a la gestién predic- tiva de proyectos. A grandes rasgos, se presenta al proyecto en diversas fases se- cuenciales que una vez finalizadas no podran ser modificadas. El alcance y la planificacién de las tareas se determinan al inicio del proyecto. PMBOK establece nueve areas de conocimiento en todos los proyectos, que enu- meramos a continuacién: Gestién de la integracién de proyectos. Gestién del alcance en proyectos. Gestién del tiempo en proyectos, Gestién de la calidad en proyectos. Gestin de costos en proyectos. Gestién del riesgo en proyectos. Gestién de recursos humanos en proyectos. Gestién de la comunicacién en proyectos. Gestin de la procura (logistica) en proyectos. ane 53. SOFTWARE Planear Hacer Inicio — > Planeaciin >} >> Ejecuciin > —+> Cierre Supervisin y control Revisary actuar Figura 13, Las acciones de planeamiento y eJecucién se encuentran siempre bajo acciones de supervisién y control Todos los procesos son descriptos mediante: entradas, herramientas, técnicas y sa- lidas. El ciclo de vida que nos propone PMBOK se compone de cuatro fases: Inicio: es la fase que recolecta informacién sobre el proyecto y la solucién que se va a construir, ademas de realizar la evaluacién sobre la justificacién del proyecto. Planificacidn: se construye la arquitectura sin detalles y la solucién a alto nivel. Se realiza la definicién de tareas y las estimaciones. Ejecucién: se produce el proyecto y se monitoriza y ajustan las estimaciones. * Cierre: se contrasta la construccién con los requisitos. Durante el ciclo de vida de PMBOK se realizan los siguientes procesos: Identificacién del problema o la oportunidad. Identificacién y definicién de las soluciones. Estimacién de las tareas. Estimacién de los recursos. Anilisis de riesgos. Gestién de la comunicacién. Gestién de la finalizacién del proyecto. DI Provectos Para Project Management Body of Knowledge (PMBOK) un proyecto da una solucién a un pro- blema, es temporal, posee incertidumbre y consume recursos. En base a esta definicién es que la metodologia fue desarrollada. Se hace hincapié en la administracién de los recursos, la ges- ién del riesgo y el control de las desviaciones. 76PMBOK En la fase de definicién del proyecto encontramos diferentes etapas con caracte~ risticas y prioridades muy distintas. Podemos identificar las que veremos de for- ma derallada en las proximas paginas Comprender el problema Se intenta identificar el problema estableciendo la solucién adecuada. PMBOK mar- ca la diferencia entre solucién y necesidad diciendo que una necesidad describe el de- seo del cliente, especifica metas, objetivos. La necesidad surge de un problema de ne- gocio. Una solucién otorga una respuesta, establece las estrategias y define los medios para resolver la dificultad. Luego de las reuniones y procedimientos adecuados para la comprensién del problema, el equipo genera el documento de requerimientos del proyecto, que describe la dificultad e incorpora los siguientes items: Impacto del problema. Identificacién de los actores. * Ventajas de obtener la solucién. * Riesgos. + Amenazas internas y externas. * Informacién de proyectos anteriores relacionados Con esta informacién y otra relacionada se realizan los anilisis de factibilidad ope- rativa, técnica y econémica que justifican la ejecucidn 0 no del proyecto. Requisitos Tiempo Figura 14. Las dimensiones de cada proyecto son los requisitos, el costo y el tiempo.3. SOFTWARE Identificar la solucién La fase de identificacién es exploratoria y pretende aumentar el conocimiento sobre el problema para poder ofrecer distintas opciones. Se pueden realizar reu- niones informales para establecer soluciones candidatas, que luego seran filtra- das efectuando anilisis técnicos, Basicamente los anilisis realizados son finan- cieros (costos/beneficios) y no financieros (atributos y caracter{sticas). También pueden hacerse pequefios prototipos para interesar al cliente o tener mas cono- cimientos sobre los problemas tipicos de esa construccién. En esta etapa también incluimos otros andlisis relacionados con la organizacién, como los de amenazas, ventajas comerciales y fortalezas. Desarrollar la solucion Se especifica la solucién seleccionada y para esto se utiliza un esquema bésico de definicién del proyecto llamado logframe. Este se compone de niveles y especifi- ciones y, generalmente, tiene cuatro niveles: objetivos, propésito, resultados y actividades. En cada uno encontramos una especificacién: * Riesgos. * Medios de informacién para indicadores. * Indicadores de avance. Ademés del logframe, y con el objetivo de anticiparnos a los conflictos, debemos efectuar el andlisis de los stakeholders. Una vez realizada la documentacién pa- samos a generar la definicién de proyecto en la cual se establece: * Trabajo a realizar + Limites y tareas. + Evaluaciones y criterios de éxito. Composicién del equipo y jefe de proyecto En PMBOK se establecen las propiedades y las caracteristicas que debe poser nuestro jefe de proyecto como también las fases y elementos que hay que tener en cuenta en la formacién de un equipo de trabajo. En cada equipo podemos ob- servar cuatro fases de desarrollo, que describimos a continuacién. Formacién: el equipo atin no tiene los conocimientos necesarios y depende de la informacién y formacién propuesta por el jefe de proyecto. Reaccién: el equipo es capaz de responder a los interrogantes sobre el proyecto y ya tiene asumidos sus roles dentro de éste. 78 aaaPMBOK Normalizacién: en esta fase se crean notmas de conducta para separar tareas y responsabilidades. Se intenta potenciar las relaciones interpersonales y aumentar la capacitacién individual. Accién: el equipo es independiente del jefe y sélo lo requiere como facilitador. Su integracién en el proyecto es buena y pueden actuar correctamente. Equipo = -_-——* Formacién Eventos Normalizacién Equipo Reaccién formado Figura 15. El equipo atraviesa etapas de manera ciclica dentro del proyecto. El jefe de proyecto es una figura clave y la evolucién del proceso depende exclusi- vamente de él, Entre sus responsabilidades encontramos: * Gestién de costos, funciones y calidad * Manejo y administracién de la informacién. * Gestién de los recursos humanos. Planificaci6n y gestion del riesgo La metodologfa nos sugiere que la planificacién de tareas y actividades se realice me- diante la construccién de un Work Breakdown Structure (WBS). El WBS es un grafico simple, estructurado y jerarquizado, que se compone utilizando una lis- ta de tareas que son traspasadas a ese formato. [DD stakctoubers PMBOK considera stakeholders a aquellas personas 0 instituciones que destinan fondos o re- cursos para el proyecto. También encontramos a quienes trabajan activamente en la solucién. ‘Aquellos individuos que aunque no participan directamente se pueden ver afectados por el re- sultado del proyecto también son incluidos en esta clasificacién.3. SOFTWARE Figura 16. La definicién de tareas es uno de los pasos criticos en la construccién. Una vez finalizado el WBS debemos agregar la informacién necesaria para completar la duracién, el costo, el responsable y los recursos. Estos datos son insertados en otra documentacién, como por ejemplo la Responsibility Assignment Matrix (RAM), una matriz que incorpora datos sobre actividades y responsables. La informacién com- pilada ser4 luego trasladada al reporte con més trascendencia, denominado Diagra- ma de Red. Este es una suma del WBS y la RAM, en el cual aparecen las actividades, sus responsables, las estimaciones de tiempo, las actividades previas y posteriores La gestién del riesgo no sélo se alimenta de toda la informacién del proyecto sino de todos los factores externos relacionados. La identificacién de las amenazas, su posibilidad de suceder y el impacto que tienen es un acercamiento serio al conoci- miento del riesgo asociado al proyecto. La metodologia propone la utilizacién de herramientas gréficas para poder gestionar el riesgo. Ey cestion ve riesco En www.riskmetrics.com/pdf/RMGuide.pdf podemos encontrar una interesante gufa produ- cida por RiskMetrics. Este documento incluye definiciones y modelos de back testing y stress testing. Recomendamos su atenta lectura y mencionamos que su descarga es gratuita, aun- que requiere que nos registremos previamente. 80PMBOK = = = ees = = Figura 17. En base a las tareas y la determinacién de la carga se genera el gréfico de red. Control y seguimiento El control del proyecto supone encontrar los elementos eriticos y los que producen desviaciones de las estimaciones iniciales. A su vez, la constante revisién de las va- riaciones posibles puede acercarnos y anticiparnos a los problemas de planificacién. Las tareas que se van a ejecutar deben poder anticiparse a las desviaciones futuras. La informacién necesaria para el control esté relacionada con: * Calidad * Tareas * Calendario * Costos Las técnicas de recopilacién de informacién son las tradicionales, siendo las més co- nocidas las reuniones formales ¢ informales y las representaciones gréficas. Ante el reconocimiento de una desviacién, se emplearan algunas de las técnicas propuestas por el jefe de proyecto junto con los gestores de la solucién. 813. SOFTWARE Cierre del proyecto Los cierres de proyecto suelen acarrear ciertos problemas como la pérdida de recur- sos, la desmotivacién de los miembros del equipo y la dificultad para conocer si los ctiterios aplicados son los adecuados. Se propone realizar ciertas tareas a fin de eje- cutar un correcto cierre de proyecto: * Obtener informacién sobre el nivel de satisfaccién del resultado. * Reconocer méritos. * Sugerencias de mejora. + Transferir el conocimiento adquirido durante el proyecto. Lanzamiento del proyecto Antes del lanzamiento se obtiene su aprobacién definitiva y se conforma el equipo de trabajo. Se elabora el documento de propuesta que contiene: + Descripcién del proyecto. * Necesidades y recursos. + Factores criticos del éxito. Los niveles de éxito que un proyecto puede alcanzar son cuatro, como podemos ver en el listado que aparece a continuaciéi * Nivel 1. Alcanzar los objetivos del proyecto. * Nivel 2. Eficiencia del proyecto, s Ilevé a cabo con control de riesgos, cumpliendo expectativas y mejorando lo propuesto. * Nivel 3. Utilidad para el cliente final. El cliente obtiene beneficios razonables de la utilizacién de la solucién. * Nivel 4, A partir del éxito del proyecto se da una mejora institucional, aumen- tando los conocimientos que podran ser aplicados en un futuro. Cada nivel implica que se han alcanzado los anteriores y supone una mejora, DD prince Si investigamos acerca del uso de PRINCE, nos encontramos con que ha sido utilizada como com- plemento de PMBOK tanto para proyectos tradicionales como en vertientes més agiles, en don- de algunas de las practicas de estos dos han sido recortadas para adaptarse a las iteraciones cortas y las entregas rapidas. Es bueno investigar casos de éxito de estos componentes. 82 aaaPRINCE2 PRINCE2 Al hablar de PRINCE2 es importante destacar que este concepto esté mucho mas ligado con una metodologia de gestién y organizacién de proyectos que de de- sarrollo. Hace referencia a la administracién, el control y la organizacién de un proyecto. Es, desde el afio 1989, un estandar del Reino Unido para la gestion de proyectos, PRINCE no puede ser vista como una metodologia de desarrollo com- pleta, sino que es utilizada como un complemento de gestién de proyectos. Procesos y componentes Se observan un conjunto de procesos que son realizados en forma secuencial, aunque algunos de ellos se ejecutan de forma paralela al resto * Arranque del proyecto (Starting up a Project): confirmacién y disefio del pro- yecto y construccién de los recursos técnicos y humanos necesarios. * Direccién del proyecto (Directing a Project): durante todo el proyecto el je- fe de proyecto puede decidir sobre la viabilidad y el estado, teniendo que re- currir a los directivos en caso de que sea necesario. * Iniciacién del proyecto (Initiating a Project): cteacién del PID (documento de inicio del proyecto) en el cual se definen requerimientos y elementos criticos. * Gestién de los limites de las etapas (Managing Stage Boundaries): pedido de autori- zacién a los responsables del proyecto para concluir una etapa y pasar a la posterior. Puede solicitarse un cambio de dominio de la etapa que se encuentra en ¢jecucién. * Control sobre una etapa (Controlling a Stage): realizacién de las tareas de con- trol sobre todas las tareas en ejecucidn. Es responsabilidad del jefe del proyec- to, pudiendo recurrir a elementos externos. * Gestién de la entrega del producto (Managing Product Delivery): autoriza- cidn de los entregables y gestién de los trabajos correspondientes a cada uno. Cierre del proyecto (Closing a Project): evaluacién del cumplimiento de re-~ quisitos, efectuando el cierre del proyecto. * Planificacién (Planning): creacién de calendarios de entrega y finalizacién. PRINCE separa al proyecto en un conjunto de componentes que se relacionan entre ellos. Los ocho elementos bisicos son: * Business Case: fase anterior al comienzo del proyecto. Se retine la documenta- cién relacionada a los objetivos y caracterfsticas del proyecto * Organizacién: en esta fase se realiza la creaci6n de documentacién relaciona- da con los recursos necesarios para el proyecto. * Planes: planificacién de la totalidad del proyecto. ane 833. SOFTWARE Controles: se intenta construir todos los elementos necesarios para asegurar que lo determinado en el Business Case pueda ser ejecutado sin desviaciones. Gestién del riesgo: en esta fase se lleva a cabo la realizacién de los anilisis de riesgo y los planes para su correcta ejecucién. Gestion de la calidad: en esta fase se realiza la construccién de la documen- tacién que fija los requerimientos de calidad. Gestion de configuraciones: se ocupa de la configuracién y gestién de los entre- gables y el seguimiento del proyecto Gestién del cambio: verifica impacto de cambios potenciales en Business Case. No desarrollaremos RUP y MSF ya que serdn tratadas en un capitulo especifico. Aho- ra nos adentraremos en las metodologias dgiles mediante una breve presentacién. METODOLOGIAS AGILES Son un conjunto de metodologias, a veces denominadas livianas o ligeras, que uti- lizan précticas similares, basadas en los resultados, la gente y la interaccién. De- bido a que existfan distintas practicas con caracteristicas andlogas, sus fundadores decidieron organizarse y unificar criterios. Con esta idea es que surgid el manifies- to agil. Este tiene cuatro postulados, y lo citamos a continuacién debido a que una buena lectura puede darnos una idea acerca de las metodologtas dgiles. “Estamos poniendo al descubierto mejores métodos para desarrollar software, haciéndo- Io y ayudando a otros a que lo hagan. Con este trabajo hemos Ilegado a valorar: * A los individuos y su interaccién, por encima de los procesos y las herramientas * El software que funciona, por encima de la documentacién exhaustiva. * La colaboracién con el cliente, por encima de la negociacién contractual. * La respuesta al cambio, por encima del seguimiento de un plan. ‘Aunque hay valor en los elementos de la detecha, valoramos mds los de la izquierda. TD Fikmantes Det MaNiFiesto Conviene conocer que el manifiesto fue firmado por los principales representantes de las metodo- logias: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Ro- bert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland y Dave Thomas. 84Metodologgas dgiles Estos postulados pueden Ilevarse a la préctica aplicando los principios giles, que son los que podemos ver a continuacién: “* Nuestra principal prioridad es satisfacer al cliente a través de la encrega tem- prana y continua de software de valor. * Son bienvenidos los requisitos cambiantes, incluso si Ilegan tarde al desa- rrollo. Los procesos agiles se doblegan al cambio como ventaja competitiva para el cliente. * Entregar con frecuencia software que funcione, en periodos de un par de se- manas hasta un par de meses, con preferencia en los periodos breves. Las personas del negocio y los desarrolladores deben trabajar juntos de forma cotidiana a través del proyecto. * Construccién de proyectos en torno a individuos motivados, dandoles la oportunidad y el respaldo que necesitan y procurandoles confianza para que realicen la tarea La forma més eficiente y efectiva de comunicar informacién de ida y vuelta dentro de un equipo de desarrollo es mediante la conversacién cara a cara, El software que funciona es la principal medida del progreso. * Los procesos dgiles promucven el desarrollo sostenido. Los patrocinadores, desarrolladores y usuarios deben mantener un ritmo constante de forma in- definida La atencién continua a la excelencia técnica enaltece la agilidad. La simplicidad como arte de maximizar la cantidad de trabajo que no se hace es esencial * Las mejores arquitecturas, requisitos y disefios emergen de equipos que se au- to-organizan En intervalos regulares, cl equipo reflexiona sobre la forma de ser mds cfectivo ¥y ajusta su conducta en consecuencia.” Existen varias metodologias égiles, siendo las mas conocidas las que veremos a con- tinuacién. Algunas de ellas las conoceremos en detalle més adelante. Programacién extrema (XP) Posiblemente Extreme Programming sea una de las metodologias agiles que mas trascendencia tiene en la actualidad. Esto se debe principalmente al gran impul- so que le han dado en la comunidad de desarrolladores y a los libros de su prin- cipal referente, Kent Beck. La programacién extrema se compone de pricticas dinamicas que no intentan ser predictivas, integran al cambio continuamente, produciendo software con mejoras. Ademés, incorpora al cliente al equipo de tra- bajo y adopta la programacién en pares. ane 853. SOFTWARE Desarrollo guiado por pruebas Programacién - en pares Refactorizacin Disefio simple Figura 18. Las tareas en XP se complementan de manera precisa. Scrum Tkujiro Nonaka y Hirotaka Takeuchi crearon un modelo para desarrollo de pro- ductos. Afios més tarde, Jeff Sutherland lo modificé para adaptarlo a la creacién de software. Podemos observar que Scrum no es una metodologia de desarrollo, sino una forma de gestién de los equipos. Implica la interaccién de todos los progra- madores para decidir sobre los tiempos y formas de los trabajos. Generalmente, es complementado con otras metodologias dgiles. El nombre proviene de la similitud que presentaron los autores en la forma de tra- bajo en equipo con la formacién que se adopta en el rugby. Crystal Clear Es una metodologfa égil muy flexible creada por Alistair Cockburn. Posee tres con- ceptos como principios para el desarrollo: Habitabilidad: implica que debemos buscar metodologfas que nos agraden al igual que el equipo y el proyecto. Eficiencia: refinar y mejorar proyecto a proyecto. Seguridad para el proyecto: cumplir las expectativas de los clientes. Foy PRocRAMACION EN PARES La programacién en pares supone el hecho de que dos desarrolladores serdn mas productivos jun- tos que separados; por lo tanto intenta ubicarlos en una estacién de trabajo o relacionarlos a tra~ vés de sus tareas. A pesar de que es una practica difundida, sus resultados no son concluyentes, y segtin el caso puede ser un beneficio ono. 86Metodologfas dgiles Iteracién, F-—A Requisitos Figura 19. Las constantes iteraciones son una de las claves de las metodologias dgiles. Feature Driven Development (FDD) Enfatiza cuestiones de calidad y define claramente entregas tangibles y formas de evaluacién del progreso. Consiste en cinco procesos secuenciales durante los que se disefia y construye el sistema: 1. Desarrollo del modelo general. 2. Construccién de la lista de rasgos. 3. Planeamiento por rasgo 4. Disefio por rasgo. 5. Construccién por rasgo. A diferencia de otros procesos giles, no cubre todo el ciclo de vida sino sélo las fases de disefio y construccién, Adaptive Software Development (ASD) Su impulsor es Jim Highsmith. Se basa en la adaptacién continua a circunstan- cias cambiantes. No tiene determinado un ciclo de planificacién-disefio-cons- [I metopotosias Acites Para comenzar a introducirnos en las nuevas metodologias, es muy recomendable leer un ex- celente articulo producido por Carlos Reynoso, que lleva como titulo Métodos Heterodoxos en Desarrollo de Software . Dentro de este material de lectura, podremos encontrar una imtere- sante introduccién a cada una de las metodologias agiles.3. SOFTWARE truccién del software, sino que se trata de especular-colaborar-aprender. Sus ca- racteristicas se pueden resumir en las siguientes * Orientada a los componentes. * Tolerante a los cambios. Su ciclo de vida tiene tres etapas: 1. Especulacié 2. Colaboracié ¢ inicia el proyecto y se planifican las caracteristicas del software. se desarrollan las caracteristicas. 3. Aprendizaje: se revisa su calidad y se entrega al cliente. Proceso de desarrollo de aplicaciones de software Anélisis det dominio 7 Especiticacién de Una iteracién (Implantacion Fequerimientos. Figura 20. En las practicas modernas se busca gran interaccién entre las posibles fases. Eq metovotosias Ascites Si accedemos al sitio web Programacién Extrema, en www.programacionextrema.org, encon- traremos un proyecto que intenta reunir informacién en espafol sobre las diversas metodologi- as. También podemos encontrar enlaces a las distintas comunidades y a los tiltimos articulos de difusién de tecnologias, entre otros contenidos disponibles. 88Seleccionar una metodologta Cada una de estas metodologfas presenta distintas formas de llevar a la préctica su filosofia y contenido, pero todas respetan el manifiesto gil, los principios y las préc- ticas, por lo tanto en realidad no difieren en los objetivos y apenas en las formas. SELECCIONAR UNA METODOLOGIA A pesar de que el resto del libro tratardé mayormente sobre las metodologias agiles, no se pretende decir que éstas sean mejores ni mas utiles que las tradicionales, To- das las metodologfas presentan grandes casos de éxito y de fracasos como para rea- lizar investigaciones y tener una idea acerca de cual adoptar y por qué razones. De hecho, muchas de las metodologias presentadas, sean tradicionales o giles, son per- fectamente complementarias o al menos integrables en algunas de sus pricticas. De- bemos recordar que el objetivo de la Ingenieria de Software y de la gestién de pro- yectos es la calidad y que ésta sélo es alcanzada cuando el proceso que se sigue pre- senta todas las caracteristicas deseadas por estas disciplinas. No hay que quedarse en ningiin extremo, nuestro critetio personal y profesional de- be ser lo que guie el desarrollo. El estudio y puesta en préctica de distintas meto- dologias favoreceré el éxito de acuerdo a los parmettos de plazo, alcance y costo y ademés aumentaré la formacién del equipo, entonces seremos capaces de responder mejor en los proyectos futuros BM Resumen El papel principal de las metodologias es esencial en un proyecto. La cantidad de ellas y sus variantes quizas hacen dificil seleccionar ta indicada. Hemos repasado algunas metodologias tradicionales y principalmente las formas de gestién y control que proponen. Las metodologias agiles intentan darnos otras respuestas a nuestros problemas, acercéndonos al cliente y fomentando algunas capacidades creativas y profesionales de los integrantes. 89ACTIVIDADES PREGUNTAS TEORICAS 1 {Qué disciplinas integran la Ingenieria de Software? 2 jEn que metodologias se basa el Método de anilisis y disefio estructurado? 3 (Qué tipos de gréficos se usan para representar un sistema desde el punto de vista estructurado? 4 {Qué significa que una metodologia sea predictiva? 5 {Qué ventajas encontramos en una metodologia predictiva? 6 {En qué tipo de proyecto aplicaria cada una de las metodologias mencionadas? 7 (Son las metodologias una forma de disminuir la complejidad en la construccién de software? 8 {Qué ventajas obtiene el desarrollador al encontrarse con etapas claramente delimitadas? ¥ {Como utilizaria PRINCE2? 10 ,Qué metodologia elegiria y por qué? 90 EJERCICIOS PRACTICOS 1 Investigue y mencione al menos cinco metodologias tradicionales no comentadas en el capitulo. 2 Proponga herramientas para utilizar en PMBOK. 3 Investigue acerca de los tipos de DFO, para qué se utilizan y cuales son las herramientas informaticas para generarlos. 4 Destaque qué perfiles de conocimientos debe tener un jefe de proyecto en cada tipo de metodologia 5 Investigue acerca del rendimiento de los desarrolladores en cada metodologia essaMétodos agiles G ti on a il Estudiaremos aqui algunos conceptos sobre la gestién tradicional y la gestion Agil de proyectos. Luego de esta introduccién comenzaremos a ver algunas de las metodologias dgiles gue podemos adoptar para nuestros desarrollos. SERVICIO DE ATENCION AL LectoR: lectores@redusers.com Proyectos Gestién de proyectos Nuevo escenario Requisitos impredecibles Gestién dg de proyectos Crystal Clear Principios Forma de desarrollo Prioridades Propiedades Practicas o técnicas Feature Driven Development (FDD) Ciclo de vida de FDD Roles ‘Adaptive Software Development (ASD) Ciclo de vida DSM (Dynamic Systems Development Method) Fases de desarrallo Practicas Roles Lean Development (LD) y Lean Software Development (LSD) Evolutionary Project Management (Evo) Resumen Actividades 92 35 96 7 37 101 103 103 104 105 107 107 108 i) 113 113 115 16 17 118 113 113 121 1224, GESTION AGIL PROYECTOS Comencemos el capitulo observando las caracteristicas de los proyectos para luego llegar a la forma de gestidn tradicional y la posterior teorfa agil. Esto nos permitiré tener una visién mas acabada del contexto en el cual se desarrollan los proyectos de software con sus procesos bajo la metodologia seleccionada. Veremos que la meto- dologfa es sélo uno de los elementos dentro de un panorama més amplio que debe estar acorde a las necesidades. Un proyecto es un conjunto de actividades relacionadas que utilizan recursos para cumplir con un objetivo deseado dentro de un plazo de tiempo delimitado. Las actividades son las tareas que se deben realizar para el cumplimiento del obje- tivo, mientras que los recursos son los elementos requeridos para cumplit las pri- meras. Todo proyecto tiene limitantes que pueden ser de orden econdmico, técni- co, operativo, etcétera. Presentan las siguientes caracteristicas: Fecha de inicio y fin. Definicién de tareas y calendario. Sucesién de actividades. Necesidad de recursos. Produccién de un resultado tinico. Decimos que un proyecto es exitoso cuando: Se termina dentro del tiempo pactado, con el presupuesto comprometido y con la funcionalidad deseada. El cliente se siente satisfecho con el producto. El producto oftece las ventajas comerciales esperadas. El equipo del proyecto cree que su participacién fue valiosa El proyecto eleva el nivel de conocimiento y permite mejorar a futuro. “ey Recursos =) alt Figura 1. Cada solucién, resultado de un proyecto, es un producto distinto. 92 aaaProyectos Por otro lado, lo consideramos un fracaso cuando: Se exceden los costos o los tiempos. El proyecto no cumple con lo prometido. El cliente no se encuentra satisfecho. El proyecto cumple a nivel técnico, pero no oftece soluciones al negocio. Los factores que influyen en el fracaso son multiples e infinitos, pudiendo resu- mirse en los que mencionamos a continuacién: Falta de personal capacitado Error en la seleccidn de recursos. Falta de capacidad administrativa. Falta de comunicacién. Incompleto anilisis de requisitos. Problemas técnicos de disefio. Fallas en el planeamiento. Fallas en la ejecucién de tareas. Figura 2. Muchos de los fracasos en los desarrollos son producto de las formaciones rigidas de los profesionales. Lamentablemente, en el mundo informético los proyectos suelen presentar més fracasos que éxitos. Recientemente, John Avellanet utilizé un estudio realizado por Accenture para demostrar la situacién actual de los proyectos de software y establecer los puntos que considera necesarios para alcanzar el éxito. A partir de eso, podemos decir lo siguient En los proyectos de IT sdlo el 29% es un éxito. El costo previsto es sobrepasado en un 56%. El tiempo es excedido en un 84% ane 934, GESTION AGIL 44% Costo 56% planificado Costo excedido Figura 3. El exceso en los costos nos demuestra la dificultad a la hora de presupuestar un software. Las técnicas que se pueden utilizar para lograr el éxito nos sonardn familiares y vere- mos que muchas de ellas son cercanas a las metodologias que estamos conociendo: 1. Dividir en fases cortas para que cada una oftezca un beneficio inmediato al negocio. 2. Las estimaciones deben ser realistas, considerando dias de 6 horas reales de tra- bajo y meses de 15 dias, por ejemplo. 3. Los proyectos son realizados por recursos humanos para personas, por lo tanto debemos realizar estas tare * Seleccionar personal adecuado. + Tomar decisiones cuando el proyecto tiene problemas internos. * Orientar al equipo para conseguir objetivos concreto: + Validar con frecuencia y en intervalos regulares la calidad de los resultados. 4, La comunicacién es un factor realmente fundamental, la transparencia y la exactitud deben ser corrientes. 90 4 80 70 60 50 40 30 20 10 84% 16% Tiempo Tiempo excedido comprometido Figura 4. El exceso de tiempo seria alarmante en otras industrias. ‘Sin embargo, parece que en la del software se convive con é! 94Proyectos 5. Aplicar el esfuerzo en el lugar adecuado, incrementando funcionalidad 6. La fase beta debe realizarse por duplicado, la primera con personal local y la otra con todos los equipos del proyecto. ‘A medida que los proyectos crecieron y se profesionalizaron, fue necesario crear un conjunto de disciplinas relacionadas para planificar, controlar y asegurar el éxito. Transparente —Fiable _—_Accesible Figura 5. La comunicacién es uno de los valores fundamentales de las metodologias heterodoxas. Gestion de proyectos La gestién de proyectos es la disciplina encargada de organizar y administrar recursos para poder llevar a cabo los proyectos cumpliendo con las restricciones pactadas. La administracién de proyectos es una tarea compleja con gran canti- dad de variables originadas principalmente por el resultado, tinico producto del proyecto. El origen de la gestién de proyectos como lo conocemos actualmente puede ser situado en los afios 50, donde se desarrollaron algunas técnicas mate- miticas que comenzaron a aplicarse a la ejecucién de estos. Los modelos mate- maticos denominados PERT (Program Evaluation and Review Technique, en es- pafiol técnica para evaluar y revisar programas) y CPM (Critical Path Method, método de ruta critica) son atin utilizados. Al mismo tiempo que se aplicaban nuevas técnicas, las herramientas para la gestién de costos y el control de calidad estaban madurando. En 1969 se cred el Project Management Institute (PMI) para difundir y mejorar las técnicas de gestion de Dy err El método PERT (Program Evaluation and Review Technique] fue desarrollado por a Armada de los Estados Unidos, en 1957, para controlar los tiempos de ejecucién de los proyectos aeroes- paciales. Se lo utilizé en el plan Polaris. Hoy en dia, este método sigue siendo implementado por varias agencias gubernamentales y es difundido como una herramienta valida para gestién4, GESTION AGIL proyectos y colaborar con una industria cada vez més exigente. Paralelamente, en uuropa aparecfa la Internacional Project Management Association (IPMA). Ac- tualmente, el PMI sigue siendo el organismo que dicta los conocidos estandares. Nuevo escenario La posibilidad de nuevos productos y la velocidad del cambio junto con los ade- lantos tecnolégicos hicieron necesario que las metodologias de gestién pasaran a ser mas dindmicas. Las diferencias entre las predictivas y las modernas son noto- rias. La incertidumbre, cada vez mayor como consecuencia de la velocidad, no posibilita los desarrollos en donde la previsién y el planteamiento inicial sean lo mds importante, debido a que estos deben ser desechados continuamente al igual que el esfuerzo en andlisis y disefio. En este nuevo escenario competitive, las va- riables mds importantes, siguiendo a Juan Palacio en su libro Hlexibilidad con Scrum, son las siguientes: Retroalimentacién del producto y el entorno. * Mayor innovacién del producto. Reduccién de tiempos. Salida inmediata al mercado. Los productos deben evolucionar, no estén terminados. Bajo este esquema, que prioriza la utilidad del producto en menor tiempo y don- de una vez que éste ve la luz sus caracteristicas deben ser modificadas para adaptar- se a un entorno cambiante, nos damos cuenta de que el tipo de gestién que se ne- cesita debe ser adaptable o agil. Innovacién Competitividad Plazos més cortos Retroalimentacién, Figura 6. Las nuevas tecnologias y la velocidad condicionan los tipos de desarrollo. 96 aaaProyectos Requisitos impredecibles Aunque todo desarrollador es formado bajo la premisa de que los requisitos son pre- decibles, podemos afirmar que salvo excepciones, como por ejemplo los proyectos aeroespaciales (que consumen muchos recursos, tiempo y dinero), todos los demas tienen requisitos cambiantes. Ante esta situacién, uno de los peores escenarios es el desconocimiento de la posibilidad del cambio 0, aun peor, la idea de que creer que los requisitos no cambian hard que estos verdaderamente sean estaticos. Hemos hablado de que por las propiedades del software es dificil realizar estimaciones cer- teras, entonces, suponiendo que no podemos dar soluciones si no detectamos el problema, debemos pensar en técnicas que nos permitan salvar este inconveniente. Notaremos que en general las metodologias agiles promueven: Iteraciones (generalmente cortas). Reutilizacién de componentes. Equipos altamente integrados (el cliente forma parte) Facilitacién de la comunicacién. Aprendizaje continuo Gestion agil de proyectos La gestién gil intenta convivir con la idea, y a la vez fomentarla, de que no exis- ten productos finales. Todos los productos son versiones beta en constante me- jora. La anticipacién y la adaptacién se erigen entonces como los pilares de es- te nuevo enfoque. Por lo tanto, la gestién gil intenta responder ante los cuatro nuevos valores de la industria: valor, tiempo, fiabilidad y agilidad. Dar un ma- yor valor al producto es fundamental en ambientes muy competitivos, y este fac- tor se encuentra compuesto por la innovacién y la flexibilidad. Los valores de la industria son cumplidos mediante la aplicacién de distintas practicas, entre las que se observan repetidamente: + Fases de desarrollo superpuestas * Inctementos de funcionalidad. Dc El método CPM (Critical Path Method) fue desarrollado por un centro de investigacién de ope- raciones en 1957 para distintas empresas comerciales, buscando el control de los costos de operacién de los proyectos. Con CPM se intenta mejorar el planeamiento y, de esta manera, optimizar los costos.4, GESTION AGIL + Entrega temprana del producto. * Mayor contacto con el cliente. El desarrollo gil es un proceso iterativo que presenta, en menor 0 mayor detalle, las fases que mencionamos a continuacién: + Concepto + Especulacién + Exploracién * Revisién * Cierre Requisitos impredecibles Producto Proceso / Aprendizaje Componentes f ) 8 a ™~“N — Iteraciones Reutilizacién Equipo Figura 7. La retroalimentaci6n y el aprendizaje sobre el producto terminado son fundamentales. Concepto A partir de los descos 0 requerimientos del cliente y mediante la interaccién y par- ticipacién con el equipo, se desarrolla la visién del producto. Se define el alcance inicial y el equipo que lo llevaré a cabo 98Proyectos Especulacion La fase de especulacién permite que el equipo realice distintos avances sobre las posibles construcciones y sus limitaciones. Esta fase se repite continuamente a lo largo del desarrollo, con las ventajas de que en cada iteracién los conocimientos del equipo sobre el producto suelen ser mayores. En esta etapa se llevan a cabo las siguientes tareas: * Detalle del producto. ‘Armado de requisitos. Determinacién de tareas * Determinacién del plan de entrega. * Determinacién de los responsables de las tarcas Exploracién En la fase de exploracién todos los integrantes del equipo desarrollan sus tareas, mientras pueden aparecer inconvenientes que son atendidos también de forma inmediata. El objetivo de la fase es el incremento de funcionalidad propuesto en la etapa anterior. Revision Con la finalizacién de la ejecucién de las tarcas se alcanza el producto real, que de- be ser utilizado y comparado con la propuesta inicial. En base a los objetivos al- canzados y propuestos se fijan las nuevas metas. Cierre Se llega al fin de la iteracin y se entrega el producto pactado, el cual puede seguir siendo desarrollado con las mismas técnicas. De acuerdo a estas caracterfsticas y fases de desarrollo, podemos pensar que el desarrollo y la gestién Agil pueden adaptarse mejor a ambientes complejos. Las diferencias entre estos ambientes y los controlados o simples pueden verse en la tabla que vemos en la proxima pagina. Fey Accance bEL Proyecto Elalcance de un proyecto puede ser definido como la suma total de todos los productos y sus re~ quisitos o caracteristicas. Este alcance es lo que continuamente decimos que cambia a lo largo del proceso. Sin embargo, en la mayoria de los métodos de estimacién, al aleance o dom liza como una constante a pesar de que en la realidad esto no se ve reflejado. se lo.uti-4, GESTION AGIL [rs mr Certeza Duda Entradas observables Algunas entradas ocultas Deterministico No deterministico Repetible Unico No existen otros actores Conviven otros actores (o.no son contemplados) Estatico Dindmico Discreto Continuo Tabia 1. Las diferencias entre los ambientes simples y complejos condicionan el desarrollo. Ademaés de todos los elementos que han impactado en el desarrollo de software, tra~ dicionalmente se han utilizado pautas que no siempre son reales, denominadas mi- tos del desarrollo ortodoxo. Entre ellas encontramos: * Mito de la especificacién: una vez que tengamos el andlisis de requisitos com- pleto comenzaremos a disefiar. Esta clase de pensamiento atraigado en los desa- rrolladores es uno de los componentes més importantes que guian el proyecto hacia el fracaso. * Mito del mantenimiento: cl mantenimiento es necesario para corregir el softwa- re, Debemos remarcar que el software no tiene desgaste ni degradacién en sf mismo, lo que sucede es que el ambiente es cambiante y repercute en él. Ade- mas del contexto técnico, tenemos que tener en cuenta los cambios de negocio que se producen alrededor de un software que se encuentra implementado * Mito de la caja negra: si el software ofrece una salida correcta a mi entrada, el problema esté solucionado. Es fundamental tener en cuenta en los desarrollos ac- tuales que no slo debemos considerar al software como un emisor de res- puestas, sino que sus procesos deben ser refinados a fin de incrementar su ca- lidad y con esto obtener ventajas competitivas. La creencia en estos mitos y otros similares es el marco de trabajo ideal para seguir utilizando metodologias tradicionales y hace que la decantacién por técnicas giles DD Frases Las fases mencionadas como concepto, especulacién, exploracién, revisién y cierre son de- nominadas de distinta forma en las metodologias. Sin embargo, es bueno observar que lue- go de estudiar las diferentes variantes, las fases siempre aparecen o, cuando no es asi, exis- te algtin otro elemento que complementa su tarea. 100Crystal Clear no sea prioritaria. Pero en los contextos de cambio surgieron las metodologfas gi les, que hasta el dia de hoy se siguen expandiendo y asentando. Dentro de éstas en- contramos (al igual que en las tradicionales) algunas orientadas al desarrollo y otras, ala gestién de todo el proceso. Veamos un pequefio resumen de algunas de las me- todologias que ya hemos presentado. a ce RUP Lenta Ato soporte Alto soporte Iconx Répida ‘Algin soporte disponible ‘Algin soporte disponible xP Répida No mencionado Agtn soporte disponible ‘SCRUM Répida No mencionado Algin soporte disponible Tabla 2. Las curvas de aprendizaje pueden determinar la metodologia que se va a adoptar. CRYSTAL CLEAR Crystal es un conjunto de metodologias con un cédigo genético comin para de- sarrollo de software, difundidas por Alistair Cockburn. Plantea que un desarrollo de software es “un juego ccondmico de cooperacién, basado en objetivos, buscando un equilibrio entre la ambicién (terminar el proyecto pronto) y la inversion (activi- dades pensando en el futuro)”. Es decir, que tenemos reglas establecidas, un equi- po y un negocio, y el proceso de software debe centrarse en estos elementos. En Crystal se miden los proyectos de acuerdo a tamafio y complejidad, y el obje- tivo es tener un marco de trabajo para cada tipo de proyecto. Es asi que, de acuer- do a estos parametros, Cockburn menciona: * Criticidad: este concepto hace referencia a la dimensién de las pérdidas que ocasionarfa un mal funcionamiento del sistema + Dimensién: determinacién del tamafio del sistema por el nimero de personas empleadas en su desarrollo (6, 20, 40, 80). J mos En este caso hemos tratado los mitos del desarrollo. Por otro lado, un autor conocido y respe- tado como Roger Pressman ha escrito, desde hace ya mucho tiempo, sobre los mitos de la pro- gramacién. Es interesante observar cémo distintos especialistas marcan la diferencia entre la realidad del desarrollo y lo que los desarrolladores creen o piensan. 1014, GESTION AGIL Crystal es una metodologia Agil que da fundamental importancia a las personas que componen el equipo de un proyecto, y por lo tanto sus puntos de estudio estan relacionados con los integrantes del equipo y las relaciones profesionales de estos con sus pares. Los incentivos a la comunicacién Agil, al igual que la de- terminacién de los correctos ambientes de trabajo, son otras preocupaciones ademés de las siguientes: Aspecto humano del equipo. Tamafio de un equipo (ntimero de integrantes). + Comunicacién entre los componentes. Distintas politicas a seguir. Espacio fisico de trabajo. * Caracteristicas del equipo Crystal. Existen algunas caracterfsticas particulares de la metodologla que pueden resultar- nos de interés, como las que vemos a continuacién: * Se basa en la observacién de una gran cantidad de equipos exitosos en lugar de proyectos puntuales. + Puede ser utilizado tanto con contratos fijos como con tipos de contratos mas dgi- les. Esto quiere decit que podemos poner en prictica Crystal aun en empresas con una politica de contratos rigida. * Las técnicas de Crystal no necesitan ser adoptadas en su totalidad, pudiendo in- corporar sdlo las que creamos utiles. En Crystal los proyectos tienden a desarrollarse como juegos cooperativos, téc- nica por la cual se intenta darle a la construccién de un proyecto un cariz hidi- co. Cada juego tiene sus metas particulares, pero el objetivo final es entregar el producto. Esta forma de dividir el desarrollo podriamos compararla con un sprint de Scrum (que estudiaremos en el capitulo 6). Las ventajas se deben a que al disminuir el alcance del proyecto, los problemas pueden ser atacados sin el pre- cio de la complejidad total. [DD curvas de APRENDIZAJE La curva de aprendizaje no deberia ser tomada en cuenta como el factor determinante para la in- corporacién de una metodologia. Sin embargo, en momentos en que los proyectos deben ser reali- zados y los tiempos son ajustados, es uno de los elementos mas observados para la decisién. Re- cordemos que en casi la totalidad de los casos es mejor adoptar una metodologia que no tenerla. 102 aeCrystal Clear Comunicacién Resultados Figura 8. Compartir informacion e intentar colaborar para atacar el problema nos enfoca en la solucién. Principios Los principios fomentados por Crystal tienen que ver con la alta adaptacién al pro- yecto y al entorno. Es as{ que se busca reducir la documentacién a lo necesario pa- ra el proyecto en particular. No descartamos la documentacién ni tenemos limites fijos para respetar, sino que nuestro criterio profesional debe actuar para saber qué volumen est justificado. Esta referencia remite tanto a la cantidad como a la pro- fundidad de su desarrollo. Generalmente, a medida que el equipo madura, conoce y comprende muchas de las tareas bdsicas en un proyecto. En estos casos es perfec- tamente aceptable no aumentar el nivel de detalle en los documentos. El equipo adaptable es otra de las intenciones de Crystal, en donde los miembros se ajustan no sélo al proyecto sino a la forma de trabajar de los otros, cambiando asi sus practicas profesionales y también sus actitudes interpersonales. Forma de desarrollo Al tener iteraciones cortas y un continuo incremento de la funcionalidad, Crys- tal favorece el desarrollo desde un esqueleto. Este puede ser una interfaz grafica con dos o tres elementos acordes al deseo del cliente como tambign un conjunto de complejos algoritmos. La profundidad depende del proyecto que se va a enca- Fy covor y comptesipap En Crystal, mediante el color, podemos obtener cierta idea sobre el tipo de proceso de desarro- lo la estructura de la metodologia. El color mas oscuro representa proyectos mayores o de gran criticidad. Existen otros colores, como el azul, el marrén, etcétera, que pretenden abarcar proyectos de un tamafio superior, aunque su difusién no es importante al menos actualmente. hE 1034, GESTION AGIL rar y del compromiso o conocimiento de las partes. Desde este esquema inicial se realiza un incremento, denominado rearquitectura incremental. Este tipo de proceso debe proveer funcionalidad desde el principio, destacando el valor apun- tado al negocio del cliente. Estas victorias tempranas pueden modificar el esta- do general del proyecto y condicionar su éxito. oe Figura 9. La construccién en Crystal se puede asemejar a una obra arquitecténica en cuanto a la construcci6n de la estructura para luego agregar detalles. Prioridades Acompaiiando la serie de principios y apuntalandolos, se nos presentan las tres prio- ridades que tiene Crystal: + Habitabilidad: el equipo discute y define una s trabajo. S ie de pautas de convivencia y deben implementar medidas a efectos de que esas normas sean respe- tadas por todos los miembros del equipo. En caso de que deban ser modificadas, es una ver més el equipo, en conjunto, quien decide o promueve el cambio. Los responsables externos deben estar de acuerdo con esta forma de trabajo + Eficiencia en el desarrollo: los proyectos deben desarrollarse con marcos de ca- lidad claros, observando que cada problema encontrado impacta directamente en los recursos que se van a utilizar y que toda solucién extra tiene un costo. [Dy ner be berate Los requisitos pueden ser expresados con cualquier nivel de detalle, siempre que nos permita comenzar a trabajar. La técnica de modelado para generar los documentos no puede ser un im- pedimento de la agilidad del método, sino que tiene que favorecer su velocidad. Los modelos que requieren mucho tiempo para la representacién de ideas simples deberian dejarse de lado. 104Crystal Clear * Seguridad en la entrega: las entregas parciales comprometidas con el cliente de- ben ser totalmente operativas, incrementando no sélo la confianza del cliente en el producto sino del equipo con su trabajo. Crystal Habitaidad eficiencia Seguridad Comunizacién Pruebas (ee Le Estindares Figura 10. Las prioridades de Crystal brindan el enfoque general de casi todas las metodologias giles. Propiedades Existen algunas propiedades que todo proyecto en Crystal debe tener. A éstas las llamamos esenciales y son: + Crecimiento reflexivo: los ajustes ben ser continuos. Para poder lograr estos objetivos, el grupo debe reunirse y tratar temas nuevos, como también conversar acerca de lo ocurrido para mejo- rar en los préximos juegos + Frecuencia en las entregas: el usuario debe recibir un producto con un incre- mento de funcionalidad real cada dos semanas, de ser posible. En casos de pro- yectos més complejos o extensos, intentaremos que las entregas no pasen el mes de trabajo. Dejamos en claro que la entrega al usuario debe ser funcional. y las adaptaciones que realiza el equipo de- Ey propicpapes Las propiedades esenciales deben ser apuntaladas por las practicas. Si esto no sucede, no se es- t@ aplicando la metodologia. En algunos relevamientos en empresas de desarrollo se detecté que muchas de ellas creiz no decian aplicar metodologias sélo por el hecho de seguir algunas ideas al azar sobre el manual oficial de la metodologia, sin comprometerse realmente con ella hE 1054, GESTION AGIL * Comunicacién: se debe offecer al equipo todos los elementos necesarios para que la comunicacién sea transparente y fluida. El uso de pizarras, wikis 0 técnicas de comunicacién es recomendado y fomentado. Proyecto Iteracién Iteracién integracién | integracién integracién integracién dia_|aia dia_|dia dia_| dia dfa_|dia psd: ck}s}dc abi Js |e dc] s|ac ae} [sled] |s |ocrae]s ots clef Ciclos anidados de Crystal Clear (Coc02) Figura 11. El cicio de vida de Crystal nos muestra sus fases de desarrollo anidados. Otras propiedades que se pueden incorporar en los proyectos son: * Acceso de usuarios: en las etapas avanzadas del proyecto el usuario debe ser més participativo, indicando aquellos puntos que pueden prestarse a confusién, como también alentando a la correccidn de los pequefios errores 0 inconsistencias. Esta participacién del usuario debe ser alentada por los desarrolladores, que deben fa- cilitarle al cliente el acceso al equipo de desarrollo, ya sea integrandolo mediante reuniones o participando con él de muestras del producto. + Bienestar personal: cada participante del proyecto debe sentirse a gusto con sus tareas, su posicidn y estado. Las técnicas de coaching o liderazgo coopera- tivo pueden ser aplicadas. * Concentracién: la delimitacién de las tareas divididas por iteraciones y el enfoque particular de un problema logran evitar las dispersiones habituales en el desarrollo, al mismo tiempo que alivian la presién de tener que cumplir con todo el proyecto. + Infraestractura de desarrollo: las pruebas automatizadas, al igual que los exé- menes de integracién y el control de versiones favorecen el desarrollo de for- ma tal que deben ser incorporadas en los proyectos. Ty Procramacion extREMA En http://2005.guadec-es.org/download/articulos/ podemos encontrar un listado de articulos de diferentes autores sobre desarrollo y herramientas libres. En particular, es interesante el ti- tulado “Métodos y herramientas de desarrollo en comunidad ”, escrito por José Dapena. En él podremos ver cémo XP se utiliza en entornos abiertos. 106Feature Driven Development (FDD) Lejos del acuerdo Caos g Complejidad z 3 & $3 “be z a4, € % Simple Cerca del Cerca dela Tecnologia _Lejos de la certeza certeza Figura 12. El nivel de dificultad del proyecto puede ser medido de acuerdo a la tecnologia y al cambio de los requerimientos. Practicas 0 técnicas Crystal nos propone muchas técnicas que pueden ser utilizadas para llevar a cabo nuestros proyectos. Sin embargo, es conveniente destacar que en este aspecto tam- bign podemos ser flexibles y no es necesario aplicarlas todas. Las mas destacadas, y que no deben faltar son aquéllas que apuntan a mejorar las relaciones interper- sonales, aumentar la confianza y capacitacién del desarrollador como las que pretenden hacer progresar el proceso productivo. Para finalizar la presentacién del tema y continuar con otras metodologfas, destaca- mos que Crystal esta orientada a proyectos pequefios, con equipos de tamafio redu- cido en donde la adaptabilidad es fundamental. Promueve las condiciones personales para poder aplicar todos los beneficios de un programador a gusto con el desarrollo. FEATURE DRIVEN DEVELOPMENT (FDD) Feature Driven Development (desarrollo dirigido por rasgos) es una metodologia que combina el desarrollo dirigido por modelos con el desarrollo gil. Se comple- menta con otras metodologias y no requiere un modelo especifico de proceso. Po- ne énfasis en alcanzar la calidad, define entregas periédicas y establece formas para la evaluacién del progreso. En sus inicios fue mencionada por varios autores, pero posteriormente fueron DeLuca, Coad y Palmer los que la desarrollaron y difundie- ron. Suele utilizarse como complemento de otras metodologias debido a que no cu- bre todo el ciclo de vida sino sélo el disefio y la construccién del software. hE 1074, GESTION AGIL Es conocida como orientada a rasgos, siendo estos las funcionalidades deseadas por el cliente y relevadas por el analista. La lista de funcionalidad fue uno de los aspectos mas trabajados por Coad en base a su conocimiento del trabajo de Ed Yourdon sobre el desarrollo de sistemas estructurados. Todo producto contiene una serie de features (Funcionalidades) que deben ser desarrolladas, y éstas serdn agrupadas de acuerdo a la relevancia que el cliente les dé y la posibilidad de su evolucién. Se agrupan en lo que se denomina Feature Set y luego son utilizadas para trabajar y poder incorporar fun- cionalidad en un lapso corto de tiempo. Ciclo de vida de FDD El ciclo de vida de FDD puede ser visto como un conjunto de procesos secuencia- les de desarrollo. El proceso es iterative, con pequefias entregas. A diferencia de otras metodologias, no se requiere la presencia del cliente en el equipo. Las fases de desarrollo son las que veremos a continuacién. Inspeccion = de diseio = Disefio Coditicacion ——™™ Prueba Conjuntos, Grupos . Lae unidad de rasgos [—~] de rasgos Disefo / iteracién Por rasgo “| Integracién Examen de = e6igo Construceln is principal Figura 13. En el ciclo de vida de FDD vemos como agrupamos por rasgos antes de desarrollar. [By Peter coap Peter Coad es un ingeniero de software reconocido principal mente por sus aportes continuos a dis- tintos tipos de desarrollo, desde el estructurado hasta el mas moderno orientado a objetos. Ac- tualmente, se dedica a métodos de aprendizaje enfocados a distintos niveles de estudiantes. En es- ta tarea sigue aplicando los principios de desarrollo gil. 108Feature Driven Development (FDD) Desarrollo de un modelo general Los expertos de dominio se encargan de realizar tareas de relevamiento y de lle- var a cabo la recoleccién de requisitos de forma tal de conocer la dimensién del problema. Estos expertos generan documentacién técnica de alto nivel para brin- dar informacién al equipo de desarrollo y a sus jefes. Una vez formulado ese and- lisis se pasa a explotarlo dividiéndolo en partes ms pequefias, y se detalla técni- camente cada una de ellas. Se construyen modelos de objetos para cada elemen- to y para el sistema en general. Construccién de la lista de rasgos La documentacién proporcionada sirve para construir una lista de funcionali- dad 0 rasgos sobre la que se continuard trabajando. Los rasgos deben estar ex- presados de forma tal que el cliente los comprenda y tienen que ser elementos que él pueda percibir; por lo que su nivel de abstraccién sera elevado. No in- cluiremos un aspecto muy técnico como podria ser una optimizacién en una buis- queda o una mejora en una clase (al menos en este momento). Los rasgos puc- den requerir de gran cantidad de recursos para completarse, por lo que serén di- vididos en otros més pequefios. Planeamiento por rasgos La fase de plancamiento es mas rigida de lo esperado para una metodologia 4gil. Se intenta desarrollar un plan que abarque todos los rasgos analizados, dan- do preferencia a los de mayor prioridad (funcional 0 técnica). La dependencia entre tareas debe ser contemplada para evitar las secuencias imposibles de llevar a cabo por falta de tareas intermedias que son planificadas para realizarse poste- riormente. Una vez generado un plan acorde al proyecto, se pasa a la siguiente etapa, donde se aplicars Disefio por rasgos Sobre la totalidad de los rasgos obtenidos se eligen algunos (en base al tiempo, el esfuerzo y los recursos) de acuerdo a su prioridad, y los propietarios de clases los asignan a los equipos, que son dispuestos u ordenados por rasgos. TI] rascos Un rasgo es un elemento distintivo de un objeto. Con esto identificamos las herramientas y los lenguajes mas adecuados al desarrollo por rasgos. Los lenguajes orientados a objetos de tipo dindmico ofrecen muchos beneficios en este tipo de desarrollos. Los lenguajes orientados a as- pectos [atin en evolucién] pueden ser la bala de plata del desarrollo por rasgos. eae 1094, GESTION AGIL } Producto 3 Producto 2 Producto 1 e@ oa _— Proy.3 Nuevo Componente Componente componente A general A general B Nuevo Nuevo Figura 14, El desarrollo por rasgos es similar a la rearquitectura de software. Construccién por rasgos De forma iterativa se escribe el cédigo necesario para poder producir los rasgos comprometidos. Las iteraciones tienden a ser cortas, intentando no excederse de dos semanas. El proceso completo de construccién comprende las tareas norma- les de desarroll * Revision de cédigo * Codificacién * Pruebas * Integracién Roles Hemos mencionado algunos roles que no han sido descriptos, por lo que a conti- nuacién veremos cuéles son los que define la metodologia. FDD establece roles mas rigidos y mas estratificados, al contrario de otras metodologias Agiles. Se observan varias clases de acuerdo a su tipo de participacién: clave, soporte y adicionales. Roles clave Los roles clave son los que deben encontrarse como minimo para que la meto- dologia pueda ser aplicada. En algunos casos, no contamos con el personal ne- cesario para poder cubrir todos los puestos y podemos tener personas que Ileven a cabo las tareas de mas de un rol, pero siempre teniendo en cuenta que no exis- tan problemas de contraposicin de intereses 1140Feature Driven Development (FDD) Gerente del proyecto: al igual que en metodologfas tradicionales, el gerente es el responsable y, por lo tanto, es quien tiene el poder de decisién sobre la visién del proyecto, sus objetivos, los recursos, las fechas de entrega, etcétera. * Arquitecto: cuenta con el soporte gerencial para poder desarrollar tareas de ese ni- vel y tomar decisiones técnicas sobre el producto y su construccién. Gerente de desarrollo: ve acotado su dominio al equipo de desarrollo, teniendo el poder de decisién dentro de éste. Programador jefe: realiza el anilisis de requisitos o tiene una fuerte incidencia en él. Decide sobre las caracteristicas y la funcionalidad que se desarrollaran y entre- gardn en la préxima iteracién Propietarios de clases: trabajan de acuerdo a lo requerido por el programador je- fe. Realizan el disefio, la codificacién, la prueba y la documentacién del software. Experto de dominio: es la persona que conoce el problema y la propuesta que se va a desarrollar. Puede ser un cliente, un analista o un consultor. Roles de soporte Los roles de soporte son asi mencionados porque a pesar de no tener tareas directa- mente orientadas al desarrollo del producto éstas son indispensables para el proce- so. En un momento dado, las tareas eran Ilevadas a cabo por un perfil de profesio- nal con conocimientos gencrales; pero, hoy en dia, cada una de éstas requicre de una profunda especializacién. Administrador de entrega: encargado de controlar el avance del proyecto. Re- porta al gerente de proyecto e integra a todas las partes. Desarrolladores expertos: conocen cl lenguaje y las tecnologfas, son consulta- dos 0 requeridos en los casos necesarios. Desarrollador de herramientas: construye elementos que son usados por el equipo, mantiene actualizados las bases de conocimiento del proyecto y los datos. Actual- mente, también es el encargado de poner al dia las herramientas de seguimiento del proyecto, como por ejemplo un sitio web. ‘Administrador del sistema: es la persona responsable de los servidores, los equi- pos y la infraestructura de red. TD Prortsionaces En muchas de las metodologias observamos distintas posiciones 0 roles en el equipo. Es im- portante destacar que el rol de una persona en el equipo tiene que ver no s6lo con su forma- cién profesional, sino también con aquellas caracteristicas personales que lo hacen atractivo para el puesto y las funciones que va a realizar. hE iit4, GESTION AGIL iteracién 0 | | tteracién 1 tteracién 2 | } tteracién 3 | | tteracién 4 Fin iy Figura 15. El avance en las iteraciones incrementa la funcionalidad. En caso contrario, debemos preguntarnos qué esté ocurriendo. Roles adicionales Las tareas anexas al proyecto son responsabilidad de los roles adicionales y co- mtinmente se realizan en un momento muy especifico del proceso. Existe una gran cantidad de labores que deben Ilevarse a cabo y aunque muchas de ellas se hacen de forma mecdnica, es conveniente delimitarlas y poder asignarlas al me- jor recurso disponible para que las efectue + Encargado de pruebas: genera los planes de prueba, los evaltia (en caso de que ya existan) y es el tltimo responsable del estado de los errores del producto + Escritores: claboran la documentacién técnica del producto Algunas de las criticas que recibe FDD como metodologia dgil se debe a su fuer- te definicién de roles, muy cercana a los tradicionales de las metodologias mas ortodoxas. Sin embargo, estos roles pueden ser desempefiados por més de una persona, al mismo tiempo que un solo recurso puede ejecutar las tareas propias de més de un rol definido. Dy rows Apesar de que en todas las metodologias observamos roles, en la mayoria de los casos estos no son determinantes y una persona puede realizar mas de uno de ellos. Es bueno conocerlos a fon- doy evitar los problemas de oposicién de intereses al asignar las responsabilidades en peque- ios equipos en los que no se pueden individualizar los roles. 142Adaptive Software Development (ASD) ADAPTIVE SOFTWARE DEVELOPMENT (ASD) Adaptive Software Development (desarrollo de software adaptable) es una me- todologia creada por Jim Highsmith y Sam Bayer que propone el trabajo con- tinuo sobre el problema, as{ como la adaptacién constante. Por sus caracteristicas de aprendizaje en fases, es propuesta como una solucién para desarrollos comprometedores en aspectos técnicos. Actualmente, sin em- bargo, se la utiliza como una metodologia destinada a proyectos de corto alcan- ce. Sus caracteristicas principales son las siguientes: + Enfocada a objetivos * Orientada a componentes * Iterativa * Tolerante a los cambios. * Gestién de riesgo. Ciclo de vida Las fases en ASD son iterativas e incrementales, no sélo desde el punto de vis- ta del producto sino también desde su fase de aprendizaje que esta orientada a controlar la calidad del trabajo y de los integrantes. Sus fases solapadas permiten el desarrollo en paralelo. De acuerdo con Highs- mith: “Los resultados son imprevisibles y toda desviacibn debe acercarnos a la solu- cién”. Se pueden observar los siguientes estados: Especulacion Al utilizar el término especulacién en lugar de planificacién, se nos da una idea acerca del objetivo que tiene la fase y la real creencia sobre la continua modifi- cacién de requisitos. La fase se divide en cinco pasos y a continuacién veremos un breve resumen de sus caracteristicas * Inicio: en este paso se determinan los objetivos y la misién del proyecto en cuestién, No se hace necesario un tipo determinado de documentacién ni for- mato para expresar las ideas. Fijacién: este paso tiene por objeto determinar los marcos temporales del pro- yecto, teniendo en cuenta lo que se ha determinado en el paso anterior. + Determinacién de la iteracién: en este paso se hace la seleccién del ntimero de iteraciones que se van a realizar y su duraci6n. Objetivos: se determinan los objetivos propios de las iteraciones. * Asignacién de funcionalidad: para terminar, a cada iteracién se le define la cantidad de funciones que va a incorporar. SERS | 1134, GESTION AGIL Bucle de aprendizaje Iniciacion Plan’ |] Ingenieria tl) Revision |_.] Qa tfinal de proven adaptativo concurrente de ‘de calidad vy entoga de ciclo componentes Especular 1 Colaborar Aprender Figura 16, De acuerdo a Highsmith, en las fases de especular, colaborar y aprender se encuentra una gran cantidad de actividades. Colaboracion En la fase de colaboracién de ASD se realizan las tareas propias de desarrollo: se incorpora la funcionalidad pactada en el software y se desempefian las activida- des técnicas paralelas. Aprendizaje La fase de aprendizaje supone la revisién de lo desarrollado asi como la critica del producto y del proceso realizado. Esta etapa puede suponer un conflicto de intereses, por lo tanto las técnicas de desarrollo personal y la facilitacién de la co- municacién se hacen mds vitales que nunca. Si el producto est libre de errores y es funcional, es evaluado bajo la visién del cliente. Ey caracitacion En general, en las capacitaciones a pequefios equipos es posible observar que la curva de apren- dizaje en las metodologias dgiles suele ser menor que en las tradicionales. Sin embargo, al mo- mento de realizar la aplicacién, los tiempos parecen revertirse principalmente por la falta de los mérgenes y los limites necesarios en todo comienzo. 114DSDM (Dynamic Systems Development Method) Existen ciertas tecnologias que permiten que ASD pueda operar con este ciclo de vida y cumplir las expectativas. Las tecnologfas estén relacionadas tanto con el desarrollo como con la infraestructura. + Lenguajes de programacién dinémicos: estos lenguajes son especialmente ap- tos para ambientes cambiantes; por eso se utilizan con frecuencia en simula- ciones y modelado. Utilizando este tipo de lenguaje, el desarrollador tiene la posibilidad de introducir cambios de forma répida y efectuar una evaluacién sobre las modificaciones. No es necesario que el desarrollo final sea realizado en un lenguaje dindmico, pero s{ es muy titil en el proceso de desarrollo. Ade- mis, estos lenguajes actuales tienen las mismas posibilidades de desarrollo que los estaticos tradicionalmente utilizados * Tecnologias de agentes: un agente es un elemento que tealiza una tarea y lo ha- ce de acuerdo a la eleccién de otto. En un desarrollo de software deseamos que los agentes realicen las tareas de forma adecuada; sin embargo, esto ¢s dificil y pue- de crear conflictos. Desde el punto de vista técnico debemos responder a todos aquellos programas que alterarn el ambiente de ejecucién del software. * Teoria de la decisién: intenta disefiar un modelo adecuado para representar las preferencias del usuario (teoria de la utilidad) en un ambiente incierto (te- oria probabilistica). Decimos que la teorfa de la decision es el lenguaje me- diante el cual podemos describir, construir y comunicar el software. + Aprendizaje: cl aprendizaje mediante técnicas de aproximacién nos permite acercarnos al problema y, luego de una exploracién adecuada, brindar solucio- nes cada vex més inmediatas a la deseada + Redes de probabilidad: las redes bayesianas ofrecen la posibilidad de reali- zat la representacién grafica de distribuciones de probabilidad. Se pueden ob- servar las variables y su dependencia. DSDM (DYNAMIC SYSTEMS DEVELOPMENT METHOD) El DSDM (Dynamic Systems Development Method 0 Método de desarrollo de sistema dindmico) es una metodologfa creada por un conjunto de grandes em- presas britanicas a principios de los afios 90 para el desarrollo rapido de aplica- ciones. Actualmente pose un gran soporte y certificaciones, gracias a la difusién lograda por la autora Jennifer Stapledon. Es uno de los métodos con més tradi- cién, aunque debido a su origen y forma de transmisién es mucho més utiliza- do en su pais de origen que en el resto del mundo. ane 1154, GESTION AGIL Fases de desarrollo Es importante destacar que el método de desarrollo de sistema dindmico sostie- ne la necesidad de mantener el tiempo y el costo como constantes y que la va- riable debe ser la fancionalidad. Veamos a continuacién un detalle de las cin- co fases de desarrollo de esta metodologia. Estudio de viabilidad Este estudio tiene una duracién de semanas y quiz hasta un par de meses. Las tareas que se realizan son similares a las de un método clasico: se definen los ries- gos del proyecto y se analizan los requisitos y la visién bésica del sistema. Por tl- timo, se genera informacién pertinente sobre las opciones disponibles y la selec cién de Dynamic Systems Development Method. Estudio del negocio Este estudio pretende poner al equipo en contacto con los requisitos reales del cliente y el andlisis de una solucién. Se utilizan diversos métodos de modelado a fin de poder representar los procesos, su ejecucién y sus relaciones. Se realiza la definicién de arquitectura del sistema y el plan de prototipado. Todos estos cle- mentos se encuentran en un alto nivel de abstraccién y luego pueden ser modi- ficados. También los tiempos de esta fase suelen ser mayores que lo comtinmente aceptado en las metodologias vistas. Iteraciones funcional y de disenio Estas dos etapas son iterativas aunque con pequefias diferencias. En un primer momento los desarrolladores trabajan sobre el modelo y lo ponen a prueba con los clientes. En la iteracién de disefio es donde se desarrolla realmente Implementacion E] sistema desarrollado en su estado actual es Ilevado al ambiente real, en donde se confronta con los requerimientos y las planificaciones realizadas. De acuerdo a los resultados obtenidos y a la profundidad del cambio se realizara una itera- cién que puede ser desde la fase funcional o de disefio. Ty estupio de viasitipap El estudio de viabilidad presenta las mismas caracteristicas que en desarrollos mas ortodoxos, pero la cantidad de tiempo asignada a él es mucho menor. Ademés, todo el equipo tiene incor- porado en su filosofia y forma de trabajo que, a pesar de realizar este paso, no es seguro que se mantengan estables en el proceso de desarrollo. 116DSDM (Dynamic Systems Development Method) Acordar plan Implementar Identficar prototipo funcional Crear prototipo funcional Entrenar usuarios Revision de negocios Pen) uy Cenc) 2 Revisar prototipo ‘Aprobacién de usuarios lineamientos de usuarios Identiicar prototipos de disefio Revisar prototipo de disefio Acordar plan fon disefio y salud Crear prototipo de disefio Figura 17. Los estudios técnicos y de viabilidad son el inicio del proyecto, como observamos en el grafico de DSDM Consortium (www.dsdm.org). Practicas En DSDM se tienen nueve précticas, las cuales intentan mantener en conereto su filosofia de desarrollo. Veamos cada una de ellas. + Compromiso del usuario: el desarrollo con las fases iteradas sobre el final re- quiere de un alto nivel de compromiso del usuario para poder conocer las debili- dades del proyecto y actuar de acuerdo a ello. + Equipos con toma de decisién: a pesar de que los roles pueden ser determinan- tes en la toma de decisién, se espera que el equipo se organice por sf mismo, ges- tione su proceso de desarrollo, y que el resultado sea producto de sus decisiones. + Entrega frecuente: las iteraciones cortas permiten actuar sobre el producto de forma temprana. La ventaja de esto es que se puede mejorar el producto antes de que el problema sea demasiado grande y su solucién muy compleja. hE 1174, GESTION AGIL Desarrollo incremental: los cambios y las modificaciones son agregadas al software Conocer el negocio: la aceptacién de un entregable debe ser siempre de acuerdo al beneficio que éste le puede brindar al negocio del cliente. Cambios reversibles: asi como incrementamos la funcionalidad, también debe- mos poder deshacer los cambios. + Requerimientos de alto nivel: la definicién de requerimientos debe ser re- presentada de forma tal de que el conocimiento pueda ser difundido y luego se profundice lo necesario Pruebas integradas: se hacen pruebas de integracién y regresién en todo el proceso. Colaboracién: se relacionan los desarrolladores y los usuarios para poder ob- tener los mayores beneficios. Roles Los roles mas destacados definidos por la metodologia son: Coordinador técnico: es el responsable de la calidad del proyecto. Debe estar familiarizado y en contacto no sélo con las especificaciones técnicas y funcio- nales sino con el desarrollo diario y sus métodos * Usuario embajador: cs un usuario experto con conocimientos suficientes co- mo para poder asumir diferentes puntos de vista y trasladar ese conocimiento al desarrollo. * Visionario: conoce los objetivos y se encarga de comunicar su cumplimiento El usuario embajador y el visionario pueden ser la misma persona, aunque no es conveniente que asf suceda * Patrocinador ejecutivo: es el responsable financiero del proyecto y, por lo tan- to, es quien en ultima instancia toma todas las decisiones concernientes a él + Facilitador: es el encargado de ofrecer lo necesario a fin de mejorar e incenti- var la comunicacién del equipo * Desarrolladores: todos los analistas, disefiadores, DBA (Data Base Adminis- trators), programadores, etcétera son agrupados bajo esta denominacién, que puede ser de dos niveles: desarrollador o desarrollador senior. Ey practicas Alo largo del capitulo hemos visto técnicas y practicas que parecen sencillas. No debemos en- gafiarnos y tenemos que profundizar en cada una antes de sacar conclusiones. Una practica tan sencilla como la colaboracién puede ir desde la confeccién de una planilla en donde se anotan tareas hasta el uso de técnicas sobre pensamiento y simulaciones de roles. 118Lean Development (LD) y Lean Software Development (LSD) LEAN DEVELOPMENT (LD) Y LEAN SOFTWARE DEVELOPMENT (LSD) Lean es una metodologia para la mejora de la calidad y la productividad. Sus va- riantes mas conocidas son Lean Product Development y Lean Software Develop- ment. La segunda se aplica especificamente al desarrollo de software. Su origen se debe a Mary y Tom Poppendieck, quienes presentaron las primeras ideas para apli- car Lean al desarrollo informatico y crearon una serie de herramientas utiles. Lean ha sido utilizada principalmente en empresas de manufacturas y logistica, mejorando la finalizacién de los proyectos. El comportamiento propuesto por los autores de LSD esta directamente relacionado con sus observaciones sobre dis- tintas empresas asidticas. El método esta inspirado en la produccién automovilis- tica con JIT (Just in Time), que produce sélo lo necesario en el tiempo adecua- do, y los controles de TQM (Total Quality Management), control de calidad total donde se ataca el error en el sitio. Lean no pretende guiar el desarrollo desde el punto de vista técnico, sino cono- cer el negocio en profundidad. El foco esté en la gestidn y los aspectos técnicos se dejan de lado. Esto requiere de un equipo de desarrollo muy capaz ademas de la integracién de profesionales de distintas areas relacionadas con el proyecto. Te- nemos doce valores de gestién de acuerdo a Jim Highsmith * Satisfacer al cliente es la maxima prioridad * Proporcionar siempre el mejor valor por la inversién El éxito depende de la activa participacién del cliente. Cada proyecto LD es un esfuerzo de equipo. Todo se puede cambiar. Soluciones de dominio, no puntos. Completar, no construir. Una solucién al 80% hoy, en vez de una al 100% mafiana El minimalismo es esencial. La necesidad determina la tecnologfa. + El crecimiento del producto es el incremento de sus prestaciones, no de su tamaiio. * Nunca empujar LD més allé de sus limites. EVOLUTIONARY PROJECT MANAGEMENT (EVO) Evo es la metodologia dgil mas antigua, Fue creada por Tom Gilb y cuenta con mu- chos proyectos importantes en su haber. Ha sido utilizada con éxito por las mas gran- eae 1194, GESTION AGIL des empresas, as{ como también por instituciones de diferentes paises, Cabe destacar su aplicacién en desarrollos criticos, en los que rindié sin problemas. Los diez princi- pios fundamentales de EVO son, de acuerdo a Tom y Kai Gilb, los siguientes: Entregar resultados verdaderos de forma temprana, * La siguiente entrega debe proporcionar mayor valor. * Los requerimientos son desarrollados de forma evolutiva. Intentar descubrir y anticiparse a los requerimientos para entregar més valor. Satisfacer al cliente, no sélo desarrollar correctamente. Integrar a los participantes y mantener una arquitectura lo més abierta posible. Usilizar los recursos y energias en el evento actual. Aprender de los errores, mejorar los procesos y oftecer valor real. Se logra una entrega temprana por la forma de trabajo y porque el continuo apren- dizaje permite evolucionar en la manera de hacer bien las cosas. Los procesos de trabajo que funcionan mal deben ser desechados. Los elementos de EVO son sencillos y pueden ser identificados como: * Metas y costos: objetivos claros y cantidad de recursos necesatios para alcanzarlos. Soluciones: base de conocimiento de opciones para lograr objetivos con los recursos. Estimacién de impacto: se evalian ideas y se verifica si estan acordes a lo pensado. Plan evolutivo: el plan evoluciona junto con el producto. Funciones: describen las tareas. Deben mantenerse en el minimo nivel posible. Metas y valores Soluciones Estimacién de impacto Plan R-evolutivo Atributos de Disefiar ideas Cuan bien las soluciones | | Incrementos de 2% al costo y calidad | | para satisfacer metas satisfacen las metas 5% del total del proyecto Funciones, subfunciones y definiciones Figura 18. Los elementos de EVO, de acuerdo a Tom Giib, nos muestran cémo las ideas existen para satisfacer las metas propuestas. Hemos visto hasta este momento diversas metodologias giles. Como conclusién, podemos decir que todas siguen los mismos principios presentados en el manifies- to, aunque cada una tiene practicas, roles y costumbres que las emparenta (0 no) con otras. A pesar de que es dificil determinar cual metodologfa es més convenien- te o gil, queremos mostrar un cuadro generado por Jim Highsmith en donde pun- tda del 1 al 5 a cada metodologia en distintos aspectos, de forma tal de obtener al- guna conclusién sobre su agilidad. 120 GeaEvolutionary Project Management (EVO) [C Em Sistema como 1 5 4 3 3 4 5 5 algo cambiante Colaboracién, 2 5 5 4 4 4 4 4 Caracteristicas de la metadologia Resultados 2 5 5 4 4 4 5 5 Simplicidad 1 4 4 3 5 3 5 5 ‘Adaptabilidad 2 5 5 3 3 4 4 3 Excelencia técnica 4 3 3 4 4 4 3 4 Practicas de colaboracién 2 5 5 4 3 3 4 5 Media CM 22 44 44 36 38 36 42 44 Media Total 47.4845 868689 Tabla 3. Los puntos de agilidad obtenidos deben ser interpretados culdadosamente. Esta presentacién de metodologias no pretendié ser exhaustiva ni determinante. Sim- plemente queremos dar a conocer otras opciones que un equipo puede incorporar a la hora de un desarrollo, Recomendamos que cada una de ellas sea repasada y que se cues- tionen todos los puntos que consideramos criticos. La consulta a la documentacion oficial de la metodologfa, al igual que la revisién de papers y documentacidn dispo- nible en la Web, podra darnos ideas mas acabadas de cada una de ellas. en valores humanos y técnicos, apuntan al desarrollo realy no a la creacién de herramientas de contexto para sostener el desarrollo. La variedad de metodologias y las diferencias entre ellas marcan que el éxito puede ser alcanzado de muchas maneras y que lo importante es saber cémo hacerlo. La eleccién de una en particular es sélo el primer paso. Su conocimiento, aplicacién y constante mejora del proceso son las claves de nuestra superacién y del alcance de la calidad deseada. ae 124ACTIVIDADES PREGUNTAS TEORICAS 1 {Cudles son los elementos que hacen de la gestién una tarea destacada? 2 {Qué es un proyecto? 3 {Qué entendemos por gestién agil? 4 (Aqué denominamos ambiente complejo? 5 {Son siempre impredecibles los requisitos? 6 {Cémo se miden los proyectos en Crystal? 7 (Existe una actividad més importante en un ciclo de vida? 8 {Qué son los mitos de desarrollo? 9 (Qué es ASD? 10 ,Qué fases particulares incorpora ASD respecto de otras metodologias? 122 EJERCICIOS PRACTICOS 1 Mencione al menos tres metodologias giles ademas de las presentadas. 2 Seleccione alguna metodologia, estiidiela a fondo y proponga algunos cambios 0 mejoras, 3 Investigue acerca de los lenguajes dindmicos y su actual uso. 4 Busque informacién acerca de las dificultades de implementacién de las metodologias giles. 5 Destaque los elementos por los cuales seleccionaria una metodologia. essaMétodos agiles Programacion extrema La programacién extrema es la metodologia mas destacada dentro de las denominadas agiles y se ha ganado este espacio gracias a sus buenas practicas, su difusién y sus excelentes resultados. Aqui intentaremos explicar de forma amena sus componentes teéricos. SERVICIO DE ATENCION AL LectoR: lectores@redusers.com Qué es XP? Historia de XP Cuéndo utilizar XP Promesas de la programacién extrema Objetivos de la programacién extrema Valores de XP Simplicidad Comunicacién Retroalimentacin (feedback) Coraje Practicas dela programacin extrema Actividades basicas El proceso XP Exploracién Planificacion dela entrega Iteraciones Produccién Mantenimiento Muerte del proyecto Equipo Roles en XP Cliente Programador Encargado de pruebas (tester) Encargado de seguimiento (tracker) Entrenadar (coach) Gestor (big boss) Attefactos de XP Historias de usuario Tareas de ingenieria Pruebas de aceptaciin Tarjetas CRC Las balas de plata Programacién en pares Pruebas en XP Solucionar problemas Critics a XP Resumen Actividades 124 125 125 127 127 128 128 129 130 11 11 134 135 136 137 138 139 139 140 140 141 M1 12 13 143 13 144 144 146 M5 6 7 148 i) 143 151 152 153 1545, PROGRAMACION EXTREMA EQUE ES XP? La programacién extrema o XP (Extreme Programming) es una metodologia 4gil de desarrollo de software que intenta potenciar las relaciones entre los integrantes del proyecto y se concentra en la adaptabilidad como clave para el éxito del desa- rrollo, Segtin Kent Beck: “XP es un proceso ligero, de bajo riesgo, flexible, predecible, ciencffico y divertido de desarrollo de software”. Es denominada extrema debido a que, como enuncia Beck, “lleva un conjunto de récnicas y principios de sentido comiin a ni- veles extremos”. Las practicas que generaron cierta desconfianza y rechazo cuando la metodologfa fue difundida son: + Programacién en pares. + Pruebas unitarias. + Pruebas continuas + Refactorizacién, Hablaremos de éstas en el presente capitulo y trataremos de dar una visién objeti- va al respecto. Mientras tanto, diremos que XP esté basada en algunos valores y un conjunto de pricticas definidas y complementarias que se pondran en uso durante todo el ciclo de vida del proyecto. A diferencia de las metodologfas tradicionales, XP esté orientada al desarrollador, al usuario, al resultado real y al inctemento de funcionalidad. También debernos aclarar que este método por sus propuestas innovadoras dividié a los desarrollado- res, principalmente en cuanto a los conceptos que maneja sobre la documentacién, su real utilidad y la cantidad de recursos que se destinan a su creacién. member Programaciér Figura 1. El sitio www.programacionextrema.org es una referencia en castellano obligada para todo aquél que quiera conocer XP. 124Qué es xP? Historia de XP La programacién extrema fue creada por Kent Beck, Ward Cunningham y Ron Jeffries mientras trabajaban en un proyecto de néminas de la compatifa Chrys- ler. Desde hacfa afios se venia desarrollando esa aplicacién con grandes retrasos y dificultades. En 1996, Beck Ilegé a la empresa y observé que los problemas del desarrollo estaban basados en las estructuras y las metodologias. Sus ideas originales sobre un buen desarrollo distaban demasiado de los modelos rigidos utilizados que hacfan gran hincapié en el uso de extensa y refinada documenta- cién, En 1999 Beck publicé el libro Extreme Programming Explained, que di- fundié y atrajo la atencidn sobre la metodologia. Desde ese momento, XP se ha convertido en la principal metodologia 4gil de desarrollo, siendo atractiva para todo tipo de desarrollador Cuando utilizar XP A pesar de que podemos observar casos de éxito de diferentes magnitudes y carac- teristicas, la programacién extrema fue concebida pensando en desarrollos que pre- sentan las siguientes caracteristicas: * Proyectos con requisitos variables, cambiantes: casi todos los proyectos reales de software podrian entrar dentro de esta categoria, debido a que es muy poco frecuen- te que el establecimiento de requisitos sea extenso, detallado, profundo y lo suficien- temente fiable para que no se deban introducir cambios en medio del proceso * Proyectos de alto riesgo: aquellos proyectos que proponen soluciones con ca- lendarios realmente ajustados suponen un riesgo para su cumplimiento. Lo mis- mo sucede en proyectos altamente innovadores que no permiten utilizar lineas base o conocimientos anteriores directamente sobre el proceso, sino que implican crear nuevos caminos a medida que avanzamos en el desarrollo. * Proyecto con pocos programadores: las organizaciones con poco personal ge- neralmente no pueden estructurarse de forma tal de dotar a todas las areas de los profesionales adecuados. En esos casos, muchas deciden directamente no aplicar una metodologia. XP permite que equipos de entre 2 y 12 desarrolladores puedan [Dy kent ceck Kent Beck es uno de los creadores de la programacién extrema. Como consecuencia de todos sus articulos y libros se ha logrado difundir ta metodologia hasta convertirla en la mas destaca- da de la actualidad. Por otro lado, Beck es, ademas, uno de los creadores del framework de pruebas llamado Junit, uno de los mas desarrollados hoy en di eae 1255, PROGRAMACION EXTREMA seguir perfectamente un proceso controlado, con normas de calidad y mejores practicas sin necesidad de mayor cantidad de recursos humanos. El tamafio del proyecto y el equipo han sido objeto de muchos estudios y pruebas de la metodologfa. En el afio 2001, Michael Lauer presenté una investigacién so- bre el uso de XP en proyectos propios en donde se trabajé con mas de cuarenta de- sarrolladores, excediendo lo que se recomienda. Lauer propone lo siguiente: + Adoptar XP cambiando la metéfora de sistema por un disefio confiable que de- berd obtenerse al inicio * Contar con un equipo de arquitectos que definan y disefien la arquitectura de componentes. Eliminar la programacién en pares, la semana de 40 horas y el cliente en el sitio. Acortar todos los ciclos de desarrollo propuestos por XP. * Capacitar continuamente al equipo de desarrolladores. Eliminar el mito de mes-hombre. A pesar de que los estudios de Lauer estan basados en desarrollos realizados con Ja- va exclusivamente, esto demuestra que XP puede ser adoptada ¢ incluso responder bien si le realizamos los pequefios ajustes que creamos necesarios. Debemos pensar en las metodologias agiles como practicas que pueden o no ser compartidas, pero que dan pautas claras sobre como debe ser el desarrollo moderno No tenemos Requisitos Equipo Proyectos metodologia cambiantes pequefio equerios Figura 2. Si alguno de estos elementos esta presente en nuestro proyecto, ya tenemos una buena excusa para usar XP. DD riexisiuivan A pesar de que la metodologia esta destinada y orientada a equipos pequefios, las experien- cias demuestran que la flexibilidad permite encarar proyectos mas grandes. Es importante que notemos que no se hace referencia a la dificultad del proyecto ni tampoco a la industria ala cual se dirige el software. 126Qué es xP? Promesas de la programacion extrema Este tipo de metodologia hace un esfuerzo por promover la relacién entre los miem- bros del equipo, dindoles un trabajo justo y prometiéndoles que obtendrén ciertas ventajas por su implementacién. Promesas a los clientes y gestores * Obtencién del maximo valor en cada semana de desarrollo. * Progresos concretos. * Modificacién de requisitos sin asumir costos prohibitivos. Promesas a los desarrolladores * Trabajar en Jo que realmente importa. + Estarén acompafiados por el quipo en las situaciones crfticas. * Mucho margen de accién en el desarrollo * Se enfocardn en el aspecto que les interesa (técnico) del proyecto. USAN promete Desarrolladores promete Méximo valor Trabajo estimulante Progreso Aecién Cambio de requisitos Libertad Figura 3. Una forma simple de saber si XP esté funcionando es ver si estas promesas se cumplen. Objetivos de la programaci6n extrema Al igual que toda metodologfa, el objetivo de la programacién extrema esta centra- do en el resultado. Sin embargo, a diferencia de otras, en XP se hace foco en la sa- tisfaccién del cliente. Se intenta desarrollar el producto de acuerdo a las expecta- [I PRuceas be inTEGRACION Una vez realizadas las pruebas unitarias, suponemos que los elementos han sido testeados in- dividualmente. Si estas pruebas son satisfactorias, deberos evaluar cémo operan juntos varios componentes. Para esto es que existen las pruebas de integracién, en donde intentamos juntar las piezas para tener una visién mas acabada. Gea 1275, PROGRAMACION EXTREMA tivas del usuario, no s6lo respecto a la funcionalidad sino también en tiempo y for- ma. Ademés, el cliente puede sentirse libre de realizar cambios en sus especificacio- nes sin que éstas alteren el desarrollo del proyecto, produzcan crisis interpersonales ni provoquen un descenso de la calidad. La programacién extrema intenta cumplir con los puntos del manifiesto gil minimizando los elementos y sin incrementar la curva de aprendizaje de la metodologia. Productos. procesos Productos personas Figura 4. Las practicas y formas de XP se justifican si tenemos en cuenta que esté orientado al producto. VALORES DE XP Cada vez que observamos un proyecto, encontramos que los involucrados tienen diferentes ideas sobre qué es lo mas importante de él y cudles son las claves de su construccién. En las metodologias giles existe un conjunto de valores criticos y necesarios para que éstas cumplan las expectativas. La programacién extrema clige algunos valores y los promueve pensando, principalmente, en los aspectos humanos sobre los técnicos. Simplicidad La base de la programacién extrema es la simpleza. Se espera que afrontemos ca- da problema preguntandonos: :qué es lo mas simple que nos pueden dar los re- sultados esperados? La simpleza propuesta por XP se refiere a evitar cualquier gasto innecesario, y esto incluye la forma de desarrollar, las herramientas usa- das y la cantidad de documentacién necesaria. En el aspecto técnico se promue- ve el disefio simple, el cual garantiza agilizar los tiempos de desarrollo y man- tenimiento. Los disefios complejos pueden ser reinventados para, con un poco 128 aeValores de XP de esfuerzo, volverlos accesibles. Las ventajas de la simpleza son més evidentes a medida que crece el proyecto. La refactorizacién, el codigo compartido y la programacién en pares son algunas de las practicas que se utilizan para poder mantener el valor de la simpleza como esencia en XP. Inicio Test unitario (No compila) Test unitario (No pasa el test) Test unitario (Pasa el test) Figura 5. La refactorizacién se encuentra intimamente ligada a la prueba. EI momento de refactorizar debe ser el indicado. Comunicacion La comunicacién es una parte vital del proceso. En esta metodologfa, el valor co- municacién se sustenta en practicas muy especfficas, como por ejemplo la do- cumentacién del cédigo. Todo desarrollador debe comentar el cédigo estable ys de esta forma, evitar los documentos externos, La comunicacién sin barre- ras (cara a cara) y constante permite encontrar a la gente adecuada para el pro- DJ sivecicioan La idea de generar soluciones simples (al menos dentro de lo posible] deberia estar arraiga~ da en los desarrolladores. Sin embargo, en la practica esto no es del todo observable. Es por eso que la metodologia incorpora este valor como esencial. Generar soluciones simples tie- ne un costo de disefio que no debe ser despreciado a la hora de plantear un desarrollo. ae 1295, PROGRAMACION EXTREMA blema, evitando las inaccesibles cadenas de solicitaciones. La programacién en pares con el cliente en el sitio es otra de las pricticas que se esfuerza por mante- ner la cooperacién y la unidad en el proyecto. e Reunion € € Figura 6. Desde un punto de vista ideal, el documento establece una barrera entre los integrantes. Los que se han reunido han obtenido mejor comunicacién. Documento i & Retroalimentacién (feedback) Todo proyecto cambia constantemente y, por supuesto, cuanto antes percibi- mos la variacién y podemos responder a ella, tanto mejor serd para el proceso to- tal y para la calidad del producto. Se hace evidente que la retroalimentacién que se consigue al tener al cliente en el sitio para poder interactuar con él, asi co- mo evitar barreras entre integrantes del equipo, favorece la realizacién de las tareas y el cumplimiento de los objetivos propuestos. Todos los clientes, desa- rrolladores y miembros del equipo tienen que poder responder en todo momen- to sobre qué es lo que se est4 haciendo, de qué manera y qué se quiere conseguir con ello. De no ser asf, sabemos que la comunicacién y la retroalimentacién no son las indicadas o sugeridas para el proceso. Equipo generar resultados | Ambiente c retroalimentarse Précticas Figura 7. Sacar conclusiones rapidamente sobre todos los elementos favorece al desarrollo y aumenta el nivel de conocimiento del equipo. 130 GeaValores de XP Coraje El coraje y la valentfa son dos de los atributos necesarios en los directivos del pro- yecto. Muchas de las prdcticas que propone la programacién extrema se encuentran alejadas de las tradicionales y cuesta obtener indicadores reales sobre su rendimien- to o creer en ellas (a menos que ya se hayan probado), haciendo dificil su adopcién. Es necesario no sélo estar convencido de su utilidad sino tener la valentia para Ile- varlas adelante. Ademis, los miembros deben ser capaces de expresar sus opiniones y valoraciones sobre todo lo concerniente al proyecto. Por tiltimo hacemos notar que uno de los valores que siempre se destacan es el res- peto, ya que un equipo que no respete a los otros miembros o al proyecto esté des- tinado a fracasar en sus emprendimientos. Comunicacién a ‘Simpleza Feedback Coraje Figura 8. La comunicacién es el valor que sustenta a todos los otros o puede lograr conseguirlos. Practicas de la programacién extrema Ya mencionamos que una de las metodologias agiles ms utilizadas es la programa- cién extrema, Ahora conoceremos sus doce pricticas, agrupadas en cuatro categorfas. Retroalimentacion a escala fina Los procesos cambiantes suponen una flexibilidad y una adaptacién al cambio sos- tenidas. El aprendizaje continuo, al igual que la obtencién de constante retroali- mentacién del proceso y de su ejecucién, nos permite ajustar en poco tiempo aque- Ilos elementos que nos pueden estar perjudicando, como también obtener benefi- cticas de XP tratan estos temas. cios, Muchas de las pr + El principio de pruebas: es deseable que se establezcan objetivos claros para alcanzar. Por lo tanto, se genera un plan de pruebas real que debe poder ser automatizado y permitir una visidn realista sobre el estado del proyecto. Se uti- lizan ambientes de automatizacién (Unit Testing Framework), como pot ejem- plo JUnit (www.junit.org) hE 1345, PROGRAMACION EXTREMA * Proceso de planificacién: el cliente crea las historias de usuario, documentos donde plasma sus requisitos, que se utilizaran para generar los planes de libera- cidn del software. Las continuas reuniones entre el equipo y el cliente hacen que esta etapa sea productiva, ya que en ella se asignan las priotidades. Ademés, de- bemos reconocer que el proceso de desarrollo forma al usuario de manera tal que, a medida que avanza, los requisitos se tornan mas importantes desde el punto de vista técnico y el refinamiento necesario es mayor, * Cliente en el sitio: el cliente trabaja en el lugar con el equipo de desarrollo, pu- diendo interactuar directamente con los programadores. De esta forma, se mini- mizan las famosas barreras ocasionadas por la documentacién. Actualmente, con las nuevas tecnologias, muchos proyectos pueden realizarse con el cliente o los de- sarrolladores operando en forma remota. Lo que hay que destacar es que la inte- raccién entre las partes debe ser continua y transparente, permitiendo el inter- cambio de tareas, los puntos de vista y las responsabilidades. + Programacién en parejas: dos desarrolladores trabajan, codifican juntos en una sola estacién de trabajo, tesricamente reduciendo errores y ganando en tiempo de desarrollo. La programacién en parejas es uno de los puntos con mayor resis- tencia y lo trataremos mds adelante en este capitulo Cliente en el lugar ee / Paneamiero Semana de 40 horas \ Disefio simple Metafora Refactorizacién Entregas tempranas Pruebas ees temp Progamacién en parejas Estandares de codificacién ZEN / Integracién continua Propiedad colectiva Figura 9. La relacién entre las practicas de XP es notoria a medida que avanza un proyecto. 132Valores de XP Proceso continuo en lugar de por lotes En XP, en lugar de tener bloques de proceso que deben ser ejecutados con un estricto orden y con dependencias secuenciales, tenemos un conjunto de practi- cas que se realizan a lo largo del ciclo de vida del producto. Las que figuran a continuacién nos acercan al desarrollo gil y al manejo del proceso: * Integracién continua: se generan versiones nuevas continuamente a lo largo del proceso de desarrollo, la constante reescritura del cédigo evita los proble- mas posteriores de integracién. + Refactorizacién: se realizan evaluaciones continuas del cédigo y se reescribe la funcionalidad, mejorando el disefio. Este progreso impacta naturalmente en la calidad del producto. + Entregas pequefias: establecidas dentro de las 4 semanas, donde se tiene una pequefia aplicacién que funciona y es vista en el ambiente real Entendimiento compartido Podriamos argumentar que el equipo es practicamente el elemento que tiene el va- lor esencial del proceso. Un buen grupo con conocimiento, predisposicién al tra- bajo y enfocado en un objetivo produce més y mejor. Compartir la informacién y el cédigo posibilita que todos conozcan las tareas ac- tuales y los esfuerzos necesarios para desarrollar. * Disefio simple: intenta evitar la funcionalidad innecesaria, manteniendo el producto en un nivel de sencillez aceptable que cumpla con los requisitos que ha efectuado el cliente. Metéfora: cs la visién que los desarrolladores ¢ integrantes del equipo tienen del sistema completo. La metéfora puede ser mejorada ¢ incrementada a me- dida que el desarrollo avanza Propiedad colectiva del cédigo: todos poseen acceso al cédigo y esto permite que, al ser visualizado por més gente, posea menos errores. Estandar de codificacién: de forma tal de producir cédigo como si fuera es- crito por una sola persona. EG etemenros xp En XP se utilizan unas fichas denominadas tarjetas CRC (clase, responsabilidad y colabora- cién), que permiten que los desarrolladores conozcan las clases, qué prioridad tienen y con qué otros elementos del proyecto se relacionan. En distintos desarrollos también podemos apreciar que se incorporan o quitan documentos. eae 133