UNFV - FACULTAD DE INGENIERIA INDUSTRIAL Y DE SISTEMAS

MATERIAL DE LECTURA SESIN N 2

Escuela Profesional: Ingeniera de Sistemas. Ciclo: SEXTO Docente: Ing. Ivan Crispn Sanchez Asignatura: Ingeniera de Software I. Semestre Acadmico: 2013 - II

Sesin 2: ANLISIS Y DISEO ORIENTADO A OBJETOS

ESQUEMA DE CONTENIDOS 1. CRISIS DEL SOFTWARE 2. LENGUAJE UNIFICADO DE MODELAMIENTO (UML) 3. PROCESO UNIFICADO RATIONAL (RUP)

1. CRISIS DEL SOFTWARE 1.1. RESEA HISTRICA. En 1965, Gordon Moore predijo que la densidad de transistores en un chip semiconductor podra duplicarse cada 18 meses, de tal manera que la velocidad del procesador, la memoria, el ancho de banda, la capacidad de almacenamiento, entre otros, deberan tener un incremento del doble cada 1.5 aos. Esta regla, conocida como la ley de Moore, se ha cumplido durante cuatro dcadas y se vislumbra que ser vlida al menos durante una dcada ms. Lo expresado anteriormente plantea un problema pues los primeros ordenadores cumplan una nica programacin que estaba definida en los componentes elctricos que formaban el ordenador. La idea de que el ordenador hiciera varias tareas (ordenador programable o multipropsito) hizo que se idearan las tarjetas perforadas. En ellas se utilizaba cdigo binario, de modo que se hacan agujeros en ellas para indicar el cdigo 1 o el cero.

Estos primeros programas lgicamente servan para hacer tareas muy concretas. La llegada de ordenadores electrnicos ms potentes hizo que los ordenadores se convirtieran en verdaderas mquinas digitales que seguan utilizando el 1 y el 0 del cdigo
Sesin 02 Pag. 1

UNFV - FACULTAD DE INGENIERIA INDUSTRIAL Y DE SISTEMAS

binario pero que eran capaces de leer miles de unos y ceros. Empezaron a aparecer los primeros lenguajes de programacin que escriban cdigo ms entendible por los humanos que posteriormente era convertido al cdigo entendible por la mquina. Inicialmente la creacin de aplicaciones requera escribir pocas lneas de cdigo en el ordenador, por lo que no haba una tcnica especificar a la hora de crear programas. Cada programador se defenda como poda generando el cdigo a medida que se le ocurra. Poco a poco las funciones que se requeran a los programas fueron aumentando produciendo miles de lneas de cdigo que al estar desorganizada hacan casi imposible su mantenimiento. Slo el programador que haba escrito el cdigo era capaz de entenderlo y eso no era en absoluto prctico. La llamada crisis del software ocurri cuando se percibi que se gastaba ms tiempo en hacer las modificaciones a los programas que en volver a crear el software. La razn era que ya se haban codificado millones de lneas de cdigo antes de que se definiera un buen mtodo para crear los programas es decir, en la creacin del software no se obtenan los resultados deseados, adems de un gran costo, prdida de tiempo y poca flexibilidad. La Crisis del Software Es un trmino informtico acuado en 1968, en la primera conferencia organizada por la OTAN (Organizacin del Tratado del Atlntico Norte) sobre desarrollo de software, de la cual naci formalmente la rama de la ingeniera de software. Bsicamente, la crisis del software se refiere a la dificultad de escribir programas libres de defectos, fcilmente comprensibles, y que sean verificables. Las causas son, entre otras, la complejidad que supone la tarea de programar, y los cambios a los que se tiene que ver sometido un programa para ser continuamente adaptado a las necesidades de los usuarios. Adems, no existan todava herramientas que permitan estimar de una manera exacta, antes de comenzar el proyecto, cul es el esfuerzo que se necesitar para desarrollar un programa. Este hecho provoca que la mayora de las veces no sea posible estimar cunto tiempo llevar un proyecto, ni cunto personal ser necesario, ni el costo en que se incurrir y muchos menos la calidad del producto final. De esta crisis se pudo sacar en claro una serie de sucesos que se venan observando en los proyectos de desarrollo de software: Los proyectos no terminaban en plazo. Los proyectos no se ajustaban al presupuesto inicial. Los proyectos tenan sobrecostos excesivos. Baja calidad del software generado. Software que no cumpla las especificaciones. Cdigo inmantenible que dificultaba la gestin y evolucin del proyecto. La solucin a esta crisis ha sido la definicin de la ingeniera del software como un oficio que requera un mtodo de trabajo similar al del resto de ingenieras. La bsqueda de una metodologa de trabajo que elimine esta crisis parece que an no est resuelta, de hecho los mtodos de trabajo siguen redefinindose una y otra vez. Aunque se han propuesto diversas metodologas para intentar subsanar los problemas mencionados, lo cierto es que todava hoy no existe ningn mtodo que haya permitido estimar de manera fiable el coste y duracin de un proyecto antes de su comienzo.
Sesin 02 Pag. 2

UNFV - FACULTAD DE INGENIERIA INDUSTRIAL Y DE SISTEMAS

1.2. SITUACIN ACTUAL En el ao 2006, John Avellanet utiliz un estudio realizado por la empresa ACCENTURE (www.accenture.com) para establecer los puntos necesarios que se requieren para alcanzar el xito de un proyecto. Los datos sobre el entorno en el desarrollo de proyectos de TI era desalentador, desafortunadamente del 2006 a la fecha, las cosas no han cambiado en mucho. Solo el 27% de los proyectos de TI puede ser considerado un xito. Los proyectos de TI sobrepasan su costo en un 56%. Se estima que los proyectos sobrepasan su calendario en un 84%. El 31.1% de los proyectos son cancelados antes de que sean terminados. Lo anterior son nmeros rojos alarmantes, que sin embargo, no son nada nuevos, estos nmeros han existido desde un inicio. 1.3. ALGUNOS DESASTRES INFORMTICOS Si bien la tecnologa casi nunca es la culpable, hay gran cantidad de ejemplos de fallos de software, hardware o humanos que han costado caro a empresas o administraciones, tanto financieramente como en trminos de reputacin y que han resultado verdaderos bombazos informativos. Aclarando que el orden es subjetivo segn sus autores, vamos con ellos: a) El sistema de alerta temprana de la Unin Sovitica estuvo a punto en 1983 de causar la III Guerra Mundial cuando un error en el software indic que cinco misiles balsticos haban sido lanzados por los Estados Unidos. b) La red de AT&T se hundi en 1990 y dej sin respuesta a 75 millones de llamadas por un error en una sola lnea de cdigo. c) Un software mal diseado fue el responsable en 1996 de la explosin de la lanzadera europea Ariane-5 el 4 de Junio de 1996, cuando a 40 segundos despus de la iniciacin de la secuencia de vuelo, la lanzadera se desvi de su ruta, se parti y explot. d) Algunos de los problemas y retrasos del lanzamiento del avin ms grande del mundo, el Airbus A380, se debieron a la incompatibilidad de las diferentes versiones usadas del software de diseo CATIA. Mientras los socios franceses utilizaban la ltima versin, la factora alemana haban empleado otra. e) Un error en la navegacin de la nave espacial Mars Polar Lander hizo que volara demasiado baja y se estrellara. El fallo fue debido a un subcontratista que confundi el sistema de medidas americano y el europeo. f) Un fallo en la actualizacin del software empleado en el Ministerio de Trabajo y Pensiones britnico por la empresa de tecnologas de la informacin EDS, cost a los contribuyentes ms de mil millones de libras en 2004.

g) El efecto 2000 (Error del milenio) y los miles de millones gastados para evitar el temido desastre que afortunadamente no sucedi.

Sesin 02 Pag. 3

UNFV - FACULTAD DE INGENIERIA INDUSTRIAL Y DE SISTEMAS

h) Un nuevo sistema informtico de Siemens implantado en 1999 sin probarse suficientemente y sin personal cualificado para su manejo, amarg las vacaciones a medio milln de britnicos. i) En el ao 2005. Hudson Bay Co. (Canada), Problemas en el sistema de inventario conducen a un prdida de 33.3 millones. Entre 2004 - 2005. UK Inland Revenue (UK), errores de software condujeron a pagos excesivos (tax-credit overpayments), por valor de 3.45 mil millones.

j)

k) En el ao 2004. Avis Europe PLC (UK), sistema ERP cancelado tras invertir en l unos 54.5 millones. l) En el ao 2004. Ford Motor Co. El sistema de compras es abandonado tras gastarse en l unos 400 millones.

m) En el ao 2004. Hewlett-Packard Co. Problemas en el sistema de ERP contribuyen a una prdida de 160 millones. n) 2002. McDonalds Corp.: Sistema de gestin de compras cancelado tras gastarse 170 millones. o) 2001. Nike Inc.: Problemas con el sistema de SCM llevan a una prdida de 100 millones. La lista de desastres sera muy extensa de mostrar, pero estos casos expuestos nos dan una idea de que la crisis del software todava existe en la actualidad. 1.4. CAUSAS DE LA CRISIS ACTUAL DEL SOFTWARE Las causas son diversas. Varios especialistas e investigadores de diversas universidades de prestigio, atribuye el fracaso de un proyecto de TI a las siguientes razones: No se toma en cuenta la participacin de los usuarios Psimo registro claro de las necesidades de los usuarios No existe una adecuada planificacin Se desea programar antes de anlisis o disear el sistema Las expectativas no son realistas Falta de personal competente No existe una visin clara y menos se conocen a ciencia cierta los objetivos del desarrollo La evolucin de las necesidades y requerimientos de los usuarios no se abordaron La falta de la debida documentacin La falta de una adecuada distribucin de funciones y responsabilidades Inadecuada planificacin de controles Mala gestin de requisitos Pobres datos de diseo Inadecuada eleccin de la tecnologa Insuficiente apoyo a la gestin Falta de comunicacin del proyecto Inadecuada formacin de los usuarios El cambio frecuente en el equipo del usuario El conflicto entre las partes interesadas
Sesin 02 Pag. 4

UNFV - FACULTAD DE INGENIERIA INDUSTRIAL Y DE SISTEMAS

1.5. MITOS DEL SOFTWARE Actualmente permanecemos en esta crisis del software y desafortunadamente los profesionistas siguen sin hacer uso de metodologas o herramientas CASE que actualmente se comercializan y las cuales nos alejan de ciertos mitos que suelen escucharse y se extienden en tres partes: de gestin, del cliente, y del desarrollador. De forma general estos mitos son: Ya tenemos el mejor libro para construir el software Tenemos lo ltimo en ordenadores para desarrollar Metodologas de desarrollo de software?, es mucho esfuerzo para un sistema Poco importa la planificacin Analizar y disear?, mejor programamos directamente pues tenemos experiencia Slo basta conocer el problema de forma general Si requiere un cambio el sistema el software fcilmente lo har Hasta que se ponga en uso el programa se ve la calidad de este Slo es necesario entregar el programa funcionando. 2. LENGUAJE UNIFICADO DE MODELAMIENTO 2.1. INTRODUCCIN Lenguaje Unificado de Modelado (UML, por ingls, Unified Modeling Language) es el modelado de sistemas de software ms utilizado en la actualidad; est respaldado (Object Management Group). sus siglas en lenguaje de conocido y por el OMG

Es un lenguaje que permite modelar, construir y documentar los elementos que forman un sistema software orientado a objetos. Se ha convertido en el estndar de facto de la industria, debido a que ha sido impulsado por los autores de los tres mtodos ms usados de orientacin a objetos: Grady Booch, Ivar Jacobson y Jim Rumbaugh. Estos autores fueron contratados por la empresa Rational Software Co. para crear una notacin unificada en la que basar la construccin de sus herramientas CASE. En el proceso de creacin de UML han participado, no obstante, otras empresas de gran peso en la industria como Microsoft, Hewlett-Packard, Oracle o IBM, as como grupos de analistas y desarrolladores.

Sesin 02 Pag. 5

UNFV - FACULTAD DE INGENIERIA INDUSTRIAL Y DE SISTEMAS

Es un lenguaje grfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estndar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio y funciones del sistema, y aspectos concretos como expresiones de lenguajes de programacin, esquemas de bases de datos y componentes reutilizables.

Es importante resaltar que UML es un "lenguaje de modelado" para especificar o para describir mtodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que est descrito el modelo. El UML no es una metodologa de desarrollo de sistemas de informacin.

Sesin 02 Pag. 6

UNFV - FACULTAD DE INGENIERIA INDUSTRIAL Y DE SISTEMAS

Uno de los objetivos principales de la creacin de UML era posibilitar el intercambio de modelos entre las distintas herramientas CASE orientadas a objetos del mercado. Para ello era necesario definir una notacin y semntica comn. UML cuenta con varios tipos de diagramas, los cuales muestran diferentes aspectos de las entidades representadas. 2.2. IMPORTANCIA DEL UML En los tiempos que corren, el software tiene la tendencia de ser grande y complejo. Los usuarios demandan interfaces cada vez ms completas y funcionalidades ms elaboradas, todo ello influyendo en el tamao y la complejidad del producto final. Por ello, los programas deben ser estructurados de manera que puedan ser revisados, corregidos y mantenidos, rpida y eficazmente, por gente que no necesariamente ha colaborado en su diseo y construccin, permitiendo acomodar nueva funcionalidad, mayor seguridad y robustez, funcionando en todas las situaciones que puedan surgir, de manera previsible y reproducible. Ante problemas de gran complejidad, la mejor forma de abordar la solucin es modelar. Modelar es disear y estructurar el software antes de lanzarse a programar y es la nica forma de visualizar un diseo y comprobar que cumple todos los requisitos para l estipulados, antes de que la flotilla de programadores comience a generar cdigo. Modelando, los responsables del xito del producto pueden estar seguros de que su funcionalidad es completa y correcta, que todas las expectativas de los usuarios finales se cumplen, que las posibles futuras ampliaciones pueden ser acomodadas, todo ello mucho antes de que la implementacin haga que los cambios sean difciles o imposibles de acomodar. Modelando, se abstraen los detalles esenciales de un problema complejo y se obtiene diseos estructurados que, adems, permiten la reutilizacin de cdigo, reduciendo los tiempos de produccin y minimizando las posibilidades de introducir errores. UML es un lenguaje grfico que sirve para modelar, disear, estructurar, visualizar, especificar, construir y documentar software. UML proporciona un vocabulario comn para toda la cadena de produccin, desde quien recaba los requisitos de los usuarios, hasta el ltimo programador responsable del mantenimiento. Es un lenguaje estndar para crear los planos de un sistema de forma completa y no ambigua. Hoy en da, UML est consolidado como el lenguaje estndar en el anlisis y diseo de sistemas de cmputo orientados a objetos. Mediante UML es posible establecer la serie de requerimientos y estructuras necesarias para plasmar un sistema de software previo al proceso intensivo de escribir cdigo. En otros trminos, as como en la construccin de un edificio se realizan planos previo a su construccin, en Software se deben realizar diseos en UML previa codificacin de un sistema, ahora bien, aunque UML es un lenguaje de modelado, ste posee ms caractersticas visuales que programticas, mismas que facilitan a integrantes de un equipo multidisciplinario participar e intercomunicarse fcilmente con los usuarios e interesados del sistema (stakeholders), siendo estos integrantes del equipo los analistas, diseadores, especialistas de rea y desde luego los programadores.

Sesin 02 Pag. 7

UNFV - FACULTAD DE INGENIERIA INDUSTRIAL Y DE SISTEMAS

2.3. VISTAS EN UML Un enfoque en la presentacin de un sistema en UML es conocida como 4+1 vistas. Esta forma de documentar nuestros modelos y divide lo que sabemos de l en cinco reas:

a) Vista de Casos de Uso. Uso Que ue contiene requisitos desarrollados en las restantes vistas. b) Vista Lgica. Muestra la estructura esttica del sistema. c) Vista Fsica. Muestra el despliegue de la aplicacin en la red de computadoras. d) Vista de Procesos. Muestra los hilos y procesos de ejecucin as como la comunicacin entre estos. e) Vista de Desarrollo. Muestra la estructura en modelos del cdigo del sistema. Estas vistas se presenta tradicionalmente en una figura de cuatro cajas con un ovalo central que representa al modelo de casos de uso. Dicho grfico no es UML pero al ser tan conocido no puedo se puede dejar de incluir en este documento. documento El enfoque 4+1 vistas fue desarrollado originalmente por Philippe Kruchten en 1995, el artculo original puede ser encontrado en la Internet en: http://www.cs.ubc.ca/~gregor/teaching/papers/4+1view architecture.pdf http://www.cs.ubc.ca/~gregor/teaching/papers/4+1view-architecture.pdf De acuerdo al Sr. Kruchten, las distintas vistas del enfoque responden a las necesidades de las distintas partes interesadas: clientes, programadores, administradores, etc. Para cada uno de estos, se presenta una visin resumida del sistema con la informacin que requieren para satisfacer sus necesidades. Es as que la vista de desarrollo le dice al programador como iniciar y organizar su cdigo; la vista ta fsica ayuda a los administradores de sistemas a decidir la infraestructura que se ha de dedicar al sistema; la vista de procesos es til para realizar anlisis de integridad y tomar decisiones de integracin con otros sistemas; finalmente, siempre de acuerdo a con el Sr. Kruchten, la vista lgica le sirve a los usuarios y clientes a visualizar la funcionalidad que el sistema les provee. Este enfoque es uno de los ms extendidos en la literatura, sin embargo su aplicacin es de alcance limitado en los tiempos tiempos modernos, donde las aplicaciones tradicionales han dejado su lugar a sistemas basados en Web. Es entonces un enfoque digno de estudio aunque es

Sesin 02 Pag. 8

UNFV - FACULTAD DE INGENIERIA INDUSTRIAL Y DE SISTEMAS

probable que en nuestros proyectos sigamos otras aproximaciones para la organizacin y presentacin de nuestros modelos. 2.4. DIAGRAMAS EN UML A continuacin se muestra los diagramas que existen en para el modelamiento de sistemas mediante UML.

2.5. QU NO ES UML? a) UML no es un mtodo de desarrollo. No te va a decir cmo pasar del anlisis al diseo y de este al cdigo. No son una serie de pasos que te llevan a producir cdigo a partir de unas especificaciones. b) UML al no ser un mtodo de desarrollo es independiente del ciclo de desarrollo que vayas a seguir, puede encajar en un tradicional ciclo en cascada, o en un evolutivo ciclo en espiral o incluso en los mtodos giles de desarrollo. 2.6. RELACIN ENTRE MODELOS Y DIAGRAMAS EN UML Un modelo captura una vista de un sistema del mundo real. Es una abstraccin de dicho sistema, considerando un cierto propsito. As, el modelo describe completamente aquellos aspectos del sistema que son relevantes al propsito del modelo, y a un apropiado nivel de detalle. Por su parte un diagrama, es una representacin grfica de una coleccin de elementos de modelado, a menudo dibujada como un grafo con vrtices conectados por arcos. Un proceso de desarrollo de software debe ofrecer un conjunto de modelos que permitan expresar el producto desde cada una de las perspectivas de inters. El cdigo fuente del sistema es el modelo ms detallado del sistema (y adems es ejecutable).

Sesin 02 Pag. 9

UNFV - FACULTAD DE INGENIERIA INDUSTRIAL Y DE SISTEMAS

Sin embargo, se requieren otros modelos. Cada modelo es completo desde su punto de vista del sistema, sin embargo, existen relaciones de trazabilidad entre los diferentes modelos. Por otro lado, los diagramas expresan grficamente partes de un modelo. 3. PROCESO UNIFICADO RATIONAL 3.1. INTRODUCCIN El Proceso Unificado Rational (Rational Unified Process en ingls, habitualmente resumido como RUP) es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodologa estndar ms utilizada para el anlisis, diseo, implementacin y documentacin de sistemas orientados a objetos. El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologas adaptables al contexto y necesidades de cada organizacin. Tambin se conoce por este nombre al software desarrollado por Rational, hoy propiedad de IBM, el cual incluye informacin entrelazada de diversos artefactos y descripciones de las diversas actividades. 3.2. PRINCIPALES CARACTERSTICAS El RUP presenta tres caractersticas muy marcadas e importantes que son las siguientes: a) Dirigido por casos de uso. Un sistema de software se crea para servir a sus usuarios. Por lo tanto, para construir un sistema exitoso se debe conocer qu es lo que quieren y necesitan los usuarios prospectos. El trmino usuario se refiere no solamente a los usuarios humanos, sino a otros sistemas. En este contexto, el trmino usuario representa algo o alguien que interacta con el sistema por desarrollar. Un caso de uso es una pieza en la funcionalidad del sistema que le da al usuario un resultado de valor. Los casos de uso capturan los requerimientos funcionales. Todos los casos de uso juntos constituyen el modelo de casos de uso el cual describe la funcionalidad completa del sistema. Este modelo reemplaza la tradicional especificacin funcional del sistema. Una especificacin funcional tradicional se concentra en responder la pregunta: Qu se supone que el sistema debe hacer? La estrategia de casos de uso puede ser definida agregando tres palabras al final de la pregunta: por cada usuario? Estas tres palabras tienen una implicacin importante, nos fuerzan a pensar en trminos del valor a los usuarios y no solamente en trminos de las funciones que sera bueno que tuviera. Sin embargo, los casos de uso no son solamente una herramienta para especificar los requerimientos del sistema, tambin dirigen su diseo, implementacin y pruebas, esto es, dirigen el proceso de desarrollo. An y cuando los casos de uso dirigen el proceso, no son elegidos de manera aislada. Son desarrollados a la par con la arquitectura del sistema, esto es, los casos de uso dirigen la arquitectura del sistema y la arquitectura del sistema influencia la eleccin de los casos de uso. Por lo tanto, la arquitectura del sistema y los casos de uso maduran conforme avanza el ciclo de vida. b) El Proceso Unificado est centrado en la arquitectura. El papel del arquitecto de sistemas es similar en naturaleza al papel que el arquitecto desempea en la construccin de edificios. El edificio se mira desde diferentes puntos de vista:
Sesin 02 Pag. 10

UNFV - FACULTAD DE INGENIERIA INDUSTRIAL Y DE SISTEMAS

estructura, servicios, plomera, electricidad, etc. Esto le permite al constructor ver una radiografa completa antes de empezar a construir. Similarmente, la arquitectura en un sistema de software es descrita como diferentes vistas del sistema que est siendo construido. El concepto de arquitectura de software involucra los aspectos estticos y dinmicos ms significativos del sistema. La arquitectura surge de las necesidades de la empresa, tal y como las interpretan los usuarios y otros stakeholders, y tal y como estn reflejadas en los casos de uso. Sin embargo, tambin est influenciada por muchos otros factores, tales como la plataforma de software en la que se ejecutar, la disponiblidad de componentes reutilizables, consideraciones de instalacin, sistemas legados, requerimientos no funcionales (ej. desempeo, confiabilidad). La arquitectura es la vista del diseo completo con las caractersticas ms importantes hechas ms visibles y dejando los detalles de lado. Ya que lo importante depende en parte del criterio, el cual a su vez viene con la experiencia, el valor de la arquitectura depende del personal asignado a esta tarea. Sin embargo, el proceso ayuda al arquitecto a enfocarse en las metas correctas, tales como claridad (understandability), flexibilidad en los cambios futuros (resilience) y reuso. Cmo se relacionan los casos de uso con la arquitectura? Cada producto tiene funcin y forma. Uno slo de los dos no es suficiente. Estas dos fuerzas deben estar balanceadas para obtener un producto exitoso. En este caso funcin corresponde a los casos de uso y forma a la arquitectura. Existe la necesidad de intercalar entre casos de uso y arquitectura. Es un problema del huevo y la gallina. Por una parte, los casos de uso deben, cuando son realizados, acomodarse en la arquitectura. Por otra parte, la arquitectura debe proveer espacio para la realizacin de todos los casos de uso, hoy y en el futuro. En la realidad, ambos arquitectura y casos de uso deben evolucionar en paralelo. c) El Proceso Unificado es Iterativo e Incremental. Desarrollar un producto de software comercial es una tarea enorme que puede continuar por varios meses o aos. Es prctico dividir el trabajo en pequeos pedazos o mini-proyectos. Cada mini-proyecto es una iteracin que finaliza en un incremento. Las iteraciones se refieren a pasos en el flujo de trabajo, los incrementos se refieren a crecimiento en el producto. Para ser ms efectivo, las iteraciones deben estar controladas, esto es, deben ser seleccionadas y llevadas a cabo de una manera planeada. Los desarrolladores basan su seleccin de qu van a implementar en una iteracin en dos factores. Primero, la iteracin trata con un grupo de casos de uso que en conjunto extienden la usabilidad del producto. Segundo, la iteracin trata con los riesgos ms importantes. Las iteraciones sucesivas construyen los artefactos del desarrollo a partir del estado en el que fueron dejados en la iteracin anterior. En cada iteracin, los desarrolladores identifican y especifican los casos de uso relevantes, crean el diseo usando la arquitectura como gua, implementan el diseo en componentes y verifican que los componentes satisfacen los casos de uso. Si una iteracin cumple sus metas y usualmente lo hace el desarrollo contina con la siguiente iteracin. Cuando la iteracin no cumple con sus metas, los desarrolladores deben revisar sus decisiones previas y probar un nuevo enfoque. Otras caractersticas del RUP son las siguientes:
Sesin 02 Pag. 11

UNFV - FACULTAD DE INGENIERIA INDUSTRIAL Y DE SISTEMAS

Administracin eficiente y eficaz de requisitos Forma disciplinada de asignar tareas y responsabilidades (quin hace qu, cundo y cmo) Pretende implementar las mejores prcticas en Ingeniera de Software Uso de arquitectura basada en componentes Control de cambios Modelado visual del software Verificacin de la calidad del software Incluye artefactos (que son los productos tangibles del proceso como por ejemplo, el modelo de casos de uso, el cdigo fuente, etc.) y roles (papel que desempea una persona en un determinado momento, una persona puede desempear distintos roles a lo largo del proceso). 3.3. MEJORES PRCTICAS APLICADAS POR RUP a) Desarrollo de software en forma iterativa. Dada la complejidad de los sistemas de software modernos no es posible definir el problema entero en forma secuencial, disearlo en su totalidad, construirlo y testearlo. El enfoque iterativo permite ir creciendo en el entendimiento del problema. A travs de refinamientos sucesivos. Esto tambin permite introducir cambios tcticos en los requerimientos, caractersticas del sistema o en los tiempos. b) Gestin de requerimientos. Las nociones de casos de uso y escenarios resultaron ser una forma excelente de capturar requerimientos funcionales y de asegurar que estos rijan el diseo, la implementacin y el testeo de software; haciendo ms probable que el sistema final cumpla exactamente con lo que pidi el cliente. c) Uso de arquitecturas basadas en componentes. RUP apoya el desarrollo de software basado en componentes. Los componentes son mdulos no triviales, subsistemas que satisfacen una funcin definida. RUP proporciona un acercamiento sistemtico definiendo una arquitectura usando componentes nuevos y existentes. stos estn montados en una arquitectura bien definida, o bien ad hoc, o en una infraestructura de componentes reutilizables tal como el Internet, el CORBA, y J2EE. d) Modelizacin visual del software. El proceso le demuestra cmo modelar visualmente software para capturar la estructura y el comportamiento de arquitecturas y de componentes. Esto permite que usted oculte los detalles y que escriba cdigo usando bloques de construccin grficos. Las abstracciones visuales le ayudan a comunicar diversos aspectos del software, ayudan a mantener la consistencia entre un diseo y su puesta en marcha; y favorecen la comunicacin inequvoca. El UML es la base de esta modelizacin visual. e) Verificacin de calidad del software. Una performance y una confiabilidad pobres son los factores comunes que inhiben dramticamente la aceptabilidad de los usos del software hoy en da. Por lo tanto, la calidad se debe revisar con respecto a los requerimientos basados en la confiabilidad, funcionalidad, performance de la aplicacin y del sistema. RUP le asiste en el planeamiento, el diseo, la puesta en marcha, la ejecucin, y la evaluacin de estos tipos de pruebas. El estudio de la calidad est incorporado como parte del proceso, en todas las actividades, implicando a todos los participantes, usando medidas y criterios objetivos, y no se trata de una actividad separada realizada por otro grupo.
Sesin 02 Pag. 12

UNFV - FACULTAD DE INGENIERIA INDUSTRIAL Y DE SISTEMAS

f)

Control de cambios. La capacidad de manejar los cambios - asegurndose que cada cambio sea aceptable, y pudiendo continuar con los mismos- es esencial en un ambiente en el cual el cambio es inevitable. El proceso describe cmo controlar, seguir y supervisar cambios para permitir el desarrollo iterativo acertado. Tambin gua sobre cmo establecer los espacios de trabajo seguros para cada desarrollador proporcionando el aislamiento de los cambios realizados en otros espacios de trabajo y controlando los cambios de todos los dispositivos de software (modelos, cdigo, documentos, etc.). Describiendo cmo automatizar la integracin, hace que el equipo trabaje como una sola unidad.

3.4. CICLO DE VIDA El ciclo de vida del RUP, como se conoce al trazado de las actividades de desarrollo en el tiempo, est dividido en 4 fases que son: Inicio, Elaboracin, Construccin y Transicin, que corresponden a los 4 hitos principales de RUP: Proyecto, Arquitectura, Versin Beta () y Entregable (release). En trminos de habilidades y conocimiento, el RUP est dividido en principios clave. Cada uno de ellos corresponde a distintos aspectos del desarrollo de software que generalmente requieren habilidades especficas; esto se refleja en los roles y las actividades definidas para cada principio. Cada fase cambia el foco del equipo de trabajo para alcanzar cada uno de los hitos y es llevada a cabo en forma iterativa. Esto quiere decir que la fase se fragmenta en pequeos proyectos que recorren todas las disciplinas y producen un ejecutable en el sentido de software. Dicho producto es la forma ms efectiva de verificar el progreso del proyecto y de reducir los riesgos inherentes. El proceso se puede describir en dos dimensiones: El eje horizontal representa tiempo y demuestra el aspecto dinmico del proceso, se expresa en trminos de ciclos, de fases, de iteraciones, y de hitos o milestones. El eje vertical representa el aspecto esttico del proceso: cmo se describe en trminos de actividades, de dispositivos, de trabajadores y de workflows. . El ciclo de vida del software est particionado en ciclos, cada ciclo trabaja en una nueva generacin del producto. El RUP divide un ciclo de desarrollo en cuatro fases consecutivas. Fase de inicio Fase de elaboracin Fase de construccin Fase de transicin Cada fase constituye un eslabn bien definido, un punto en el tiempo en el cual ciertas decisiones crticas deben tomarse, y por lo tanto afinar metas debe haber sido alcanzadas.

Sesin 02 Pag. 13

UNFV - FACULTAD DE INGENIERIA INDUSTRIAL Y DE SISTEMAS

a) Fase de Inicio. Durante la fase del inicio, se establece el caso de negocio para el sistema y delimita el alcance del proyecto. Para lograr esto debe identificar todas las entidades externas con las cuales el sistema interacte (los actores) y definir la naturaleza de esta interaccin a un nivel alto. Esto implica identificar todos los casos de uso y describir slo los ms significativos. El caso de negocio incluye criterios de xito, la evaluacin de riesgos, y la estimacin de los recursos necesarios, y un plan de la fase que muestre las fechas previstas e hitos importantes. El resultado de la fase del inicio es: Un documento de la visin: una visin general de los requerimientos bsicos del proyecto, de las caractersticas dominantes, y de las restricciones principales. Un modelo inicial de casos de uso (10%-20% completo). Un glosario inicial del proyecto (opcionalmente puede ser expresado como modelo de dominio). Un caso inicial de negocio, que incluye contexto del negocio, los criterios del xito (proyeccin del rdito, reconocimiento del mercado, etctera), y pronstico financiero. Una estimacin de riesgo inicial. Un plan de proyecto, demostrando fases e iteraciones. Un modelo de negocio, en caso de necesidad. Uno o ms prototipos. 1er. Hito: Objetivos del Ciclo de vida Los objetivos del ciclo de vida en el final de la fase del inicio son el primer hito principal del proyecto: el hito de los objetivos del ciclo de vida. Los criterios de la evaluacin para la fase del inicio son:

Sesin 02 Pag. 14

UNFV - FACULTAD DE INGENIERIA INDUSTRIAL Y DE SISTEMAS

Participacin de los involucrados en la definicin del alcance y estimaciones de costo y tiempos. Entendimiento de los requerimientos segn la fidelidad de los casos de uso primarios. Estimaciones de costos/tiempos, de las prioridades, de los riesgos, y del proceso del desarrollo crebles. Cobertura de cualquier prototipo arquitectnico que se desarroll. Gastos reales contra gastos planeados. El proyecto puede ser cancelado o ser repensado considerablemente si no puede pasar este hito. b) Fase de Elaboracin. El propsito de la fase de elaboracin es analizar el dominio del problema, establecer una fundacin arquitectnica sana, desarrollar el plan del proyecto, y eliminar los elementos del riesgo ms alto del proyecto. Para lograr estos objetivos, usted debe tener una visin completa del sistema. Las decisiones arquitectnicas tienen que tomarse con una comprensin cabal del sistema: su alcance, funcionalidad importante y requerimientos no funcionales tales como requerimientos de performance. Es fcil argumentar que la fase de elaboracin es la ms crtica de las cuatro fases. En el final de esta fase, la ingeniera dura se considera completa y el proyecto experimenta su da ms importante: la decisin sobre si o no confiar en las fases de la construccin y de la transicin. Para la mayora de los proyectos, esto tambin corresponde a la transicin de una fase de operatoria mvil, ligera y gil, poco arriesgada, a una de alto-costo, riesgo elevado con una inercia substancial. Mientras que el proceso siempre debe acomodarse a los cambios, las actividades de la fase de elaboracin aseguran que la arquitectura, los requerimientos y los planes sean bastante estables, y que los riesgos se atenan lo suficiente, as usted puede determinar el costo y fecha de terminacin del desarrollo en forma bastante certera. Durante fase de elaboracin, se construye un prototipo ejecutable de la arquitectura en unas o ms iteraciones, dependiendo del alcance, del tamao, del riesgo, y de la novedad del proyecto. Este prototipo debe tratar por lo menos los casos de uso mas crticos identificados en la fase del inicio, que exponen tpicamente los mayores riesgos tcnicos del proyecto. Mientras que un prototipo evolutivo de un componente de calidad es siempre la meta, no excluye el desarrollo de unos o ms prototipos exploratorios, desechables, para atenuar riesgos especficos. El resultado de la fase de elaboracin es: Un modelo de caso de uso (por lo menos 80% completo) - todos los casos de uso y actores deben haber sido identificados-, y se han desarrollado la mayora de las descripciones de casos de uso. Requerimientos suplementarios que capturan los requerimientos no funcionales o cualquier requerimiento que no se asocie a un caso de uso especfico. Una descripcin de la arquitectura del software. Un prototipo arquitectnico ejecutable. Una lista revisada del riesgo y un caso de negocio revisado.

Sesin 02 Pag. 15

UNFV - FACULTAD DE INGENIERIA INDUSTRIAL Y DE SISTEMAS

Un plan de desarrollo para el proyecto total, incluyendo el plan de grano grueso del proyecto, demostrando iteraciones y los criterios de la evaluacin para cada iteracin. Un caso actualizado del desarrollo que especifica el proceso que se utilizar. Un manual preliminar del usuario (opcional). 2do. Hito: La arquitectura del ciclo de vida La arquitectura del ciclo de vida en el final de la fase de elaboracin es el segundo hito importante del proyecto. En este punto, se examinan los objetivos y el alcance detallado del sistema, la opcin de la arquitectura, y la resolucin de los riesgos principales. Los criterios principales de la evaluacin para la fase de elaboracin implican las respuestas a estas preguntas: Que tan estable es la visin del producto? La arquitectura es estable? La demostracin ejecutable muestra que se han tratado y resuelto los rincipales elementos de riesgo? El plan para la fase de la construccin esta suficientemente detallado? Se cuenta con una base creble de estimaciones? Todos los involucrados en el proyecto estn de acuerdo en que la visin actual se puede alcanzar si el plan actual se ejecuta para desarrollar el sistema completo, en el contexto de la arquitectura actual? La diferencia entre los gastos reales y previstos es aceptable? El proyecto puede ser abortado o ser repensado considerablemente si no puede pasar este hito. c) La fase de la Construccin. Durante la fase de la construccin, todos los componentes y caractersticas restantes se desarrollan, se integran en el producto, y se prueban a fondo. La fase de la construccin es, en cierto sentido, un proceso de fabricacin donde el nfasis se pone en manejar los recursos y controlar las operaciones para optimizar costos, tiempos y calidad. Una arquitectura robusta y un plan comprensible estn ntimamente relacionados. Es decir, una de las cualidades crticas de la arquitectura es su facilidad de la construccin. sta es una razn por la que durante la fase de elaboracin.se pone el nfasis en el desarrollo equilibrado de la arquitectura y del plan. El resultado de esta fase es un producto listo para poner en las manos de los usuarios finales. Como mnimo, consta de: El producto de software integrado en las plataformas adecuadas. Los manuales del usuario. Una descripcin del la versin o release actual. 3er. Hito: La capacidad operacional inicial El final de la fase de construccin es el tercer hito principal del proyecto En este punto, se decide si el software, los sitios, y los usuarios estn operativos, sin exponer el proyecto a demasiados riesgos. Este lanzamiento a menudo se llama un lanzamiento

Sesin 02 Pag. 16

UNFV - FACULTAD DE INGENIERIA INDUSTRIAL Y DE SISTEMAS

beta. Los criterios de la evaluacin para la fase de la construccin implican el contestar de estas preguntas: Esta versin es lo suficientemente estable y madura para entregar al usuario? Todos los involucrados estn listos para la transicin del producto a produccin? La diferencia entre los gastos reales versus los planeados es an aceptable? La transicin puede tener que ser pospuesta si el proyecto no puede alcanzar este hito. d) Fase de la Transicin. El propsito de la fase de la transicin es justamente la transicin del producto de software al ambiente de produccin. Una vez que el producto se haya entregado al usuario final, surgen algunos temas que llevan al desarrollo de nuevas versiones, a corregir errores, o a terminar algunas caractersticas que haban sido pospuestas. Se ingresa a esta fase cuando el producto est lo suficientemente maduro para comenzar a pasar a produccin. Esto requiere que un cierto subconjunto del sistema se encuentre en un nivel aceptable de la calidad y que la documentacin del usuario est disponible de modo que la transicin proporcione resultados positivos para todas las partes. Esto incluye: La prueba beta para validar el nuevo sistema contra las expectativas del usuario Operacin en paralelo con un sistema anterior que el nuevo sistema est sustituyendo La conversin de las bases de datos operacionales Entrenamientos y capacitacin de los usuarios y la gente de mantenimiento Lanzar el producto a los equipos de marketing, distribucin y ventas La fase de transicin se centra en las actividades requeridas para poner el software en manos de los usuarios. Tpicamente, esta fase incluye varias iteraciones, incluyendo lanzamientos beta, lanzamientos de disponibilidad general, as como la reparacin de errores y el lanzamiento de versiones mejoradas. Un esfuerzo considerable se realiza en la documentacin orientada al usuario final, en entrenar a los mismos, en brindar apoyo en las primeras etapas del uso, y en reaccionar al feedback que generen los mismos usuarios. En este punto del ciclo de vida, sin embargo, el feedback del usuario se debe centrar sobre todo en el ajuste fino del producto, la configuracin , instalacin, y a las cuestiones de usabilidad. Esta fase puede variar -segn el proyecto- de ser muy simple a muy compleja. Por ejemplo una nueva versin de un procesador de texto puede ser muy simple, mientras que substituir el sistema de control de trfico areo de un pas sera muy complejo. 4to. Hito: Lanzamiento del Producto En este, se decide si los objetivos fueron alcanzados, y si se comienza otro ciclo de desarrollo. En algunos casos, este hito puede coincidir con el final de la fase del inicio para el ciclo siguiente. Los criterios primarios de la evaluacin para la fase de la transicin implica las respuestas a estas preguntas: El usuario est satisfecho? Los gastos reales versus los planeados son aun aceptables?
Sesin 02 Pag. 17

UNFV - FACULTAD DE INGENIERIA INDUSTRIAL Y DE SISTEMAS

Sesin 02 Pag. 18