Repblica Bolivariana de Venezuela Ministerio del Poder Popular Para la Educacin Aldea Simn Rodrguez Misin Sucre Mencin:

Informtica Ctedra: Sistema II Trayecto III. Periodo I

Facilitador: Nstor Garca

Alumna: Mara Rondn

Ciudad Bolvar, Junio de 2013

ndice

Introduccin ........................................................................................................................................ 3 PROCESO DE DESARROLLO DEL SOFTWARE ............................................................. 5 MODELOS TRADICIONELES DE LOS SISTEMAS DE INFORMACION .................... 8

FASES: REQUISITOS, ANALISIS, DISEO, IMPLEMENTACION, MANTENIMIENTO Y RETIRO. ................................................................................................. 11 Los requisitos ................................................................................................................................ 11 Anlisis ......................................................................................................................................... 11 Diseo ........................................................................................................................................... 12 Implementacin ............................................................................................................................ 12 EL PROCESO UNIFICADO RATIONAL ........................................................................... 12 HISTORIA DEL PROCESO UNIFICADO ......................................................................... 13 METODO ERICSSON ........................................................................................................... 14 EL LENGUAJE DE DESCRIPCION Y ESPECIFICACION ............................................ 15 MODELO RATIONAL .......................................................................................................... 16

CARACTERISTICAS DEL PROCESO UNIFICADO DE DESARROLLO DEL SOFTWARE (DIRIGIDAS A CASO DE USOS, CENTRADO EN LA ARQUITECTURA, INTERACTIVO E INCREMENTAL) .......................................................................................... 17 o o o Dirigido por los casos de uso ................................................................................................ 17 Centrado en la arquitectura ................................................................................................... 17 Iterativo e Incremental .......................................................................................................... 17

CICLO DE VIDA DEL PROCESO UNIFICADO Y FASES DEL CICLO DE VIDA (INICIO, ELABORACION Y TRANSICION) ............................................................................ 18 Fase de Inicio ............................................................................................................................... 18 Fase de Elaboracin..................................................................................................................... 19 Fase de Transicin ....................................................................................................................... 19 Conclusin......................................................................................................................................... 20 Anexos............................................................................................................................................... 21

Introduccin

Un sistema informtico est compuesto por hardware y software. En cuanto al hardware, su produccin se realiza sistemticamente y la base de conocimiento para el desarrollo de dicha actividad est claramente definida. La fiabilidad del hardware es, en principio, equiparable a la de cualquier otra mquina construida por el hombre. Sin embargo, respecto del software, su construccin y resultados han sido histricamente cuestionados debido a los problemas asociados, entre ellos podemos destacar los siguientes: los sistemas no responden a las expectativas de los usuarios, los programas fallan con cierta frecuencia, los costes del software son difciles de prever y normalmente superan las estimaciones, la modificacin del software es una tarea difcil y costosa, y as infinidades de problemas. El primer reconocimiento pblico de la existencia de problemas en la produccin de software tuvo lugar en la conferencia organizada en 1968 por la Comisin de Ciencias de la OTAN en Garmisch (Alemania), dicha situacin problemtica se denomin crisis del software. En esta conferencia, as como en la siguiente realizada en Roma en 1969, se estipul el inters hacia los aspectos tcnicos y administrativos en el desarrollo y mantenimiento de productos software. Se pretenda acordar las bases para una ingeniera de construccin de software. Segn Fritz Bauer lo que se necesitaba era establecer y usar principios de ingeniera orientados a obtener software de manera econmica, que sea fiable y funcione eficientemente sobre mquinas reales. Esta definicin marcaba posibles cuestiones tales como: Cules son los principios robustos de la ingeniera aplicables al desarrollo de software de computadora? Cmo construimos el software econmicamente para que sea fiable? Qu se necesita para crear programas de computadora que funcionen eficientemente no en una mquina sino en diferentes mquinas reales? Sin embargo, dicho planteamiento adems deba incluir otros aspectos, tales como: mejora de la calidad del software, satisfaccin del cliente, mediciones y mtricas, etc. A principios de los 90, surgi la necesidad de un lenguaje de modelado visual y consistente, que permitiera expresar los resultados de las extensas variedades de metodologas Objeto Orientadas que existan.
3

Por esta razn, Grady Booch, Autor del mtodo Booch y James Rumbaugh, desarrollador principal de OMT (Object Modeling Technique), quienes trabajaban juntos en rational, comenzaron a unificar sus metodologas. El fruto de esta unin es la versin 0.8 del Mtodo Unificado (Unified Modeling Language UML), publicado en Octubre de 1995. Casi en el mismo momento, Ivar Jacobson se incorpora a laborar en Rational y se une para la produccin de la versin 0.9 de UML. El esfuerzo de unin inclua a otros expertos en el rea e involucr empresas como IBM, HP y Microsoft. Luego de pasar por el proceso de estandarizacin el OMT (Object Management Group) publica en noviembre de 1997 la versin estndar de UML. Por todas estas razones los procesos han venido evolucionando y a continuacin sern explicados todos estos cambios.

 PROCESO DE DESARROLLO DEL SOFTWARE Un proceso de desarrollo de software tiene como propsito la produccin eficaz y eficiente de un producto software que rena los requisitos del cliente. Dicho proceso, en trminos globales se muestra en la Figura 1. Este proceso es intensamente intelectual, afectado por la creatividad y juicio de las personas involucradas. Aunque un proyecto de desarrollo de software es equiparable en muchos aspectos a cualquier otro proyecto de ingeniera, en el desarrollo de software hay una serie de desafos adicionales, relativos esencialmente a la naturaleza del producto obtenido. A continuacin se explican algunas particularidades asociadas al desarrollo de software y que influyen en su proceso de construccin. Un producto software es intangible y por lo general muy abstracto, esto dificulta la definicin del producto y sus requisitos, sobre todo cuando no se tiene precedentes en productos software similares. Esto hace que los requisitos sean difciles de consolidar tempranamente. As, los cambios en los requisitos son inevitables, no slo despus de entregado en producto sino tambin durante el proceso de desarrollo. Adems, de las dos anteriores, siempre puede sealarse la inmadurez de la ingeniera del software como disciplina, justificada por su corta vida comparada con otras disciplinas de la ingeniera. Sin embargo, esto no es ms que un intil consuelo.

Requisitos nuevos o modificados

Proceso de Desarrollo de Software

Sistema nuevo o modificado

Figura1: proceso de desarrollo de software.

El proceso de desarrollo de software no es nico. No existe un proceso de software universal que sea efectivo para todos los contextos de proyectos de desarrollo. Debido a esta diversidad, es difcil automatizar todo un proceso de desarrollo de software. A pesar de la variedad de propuestas de proceso de software, existe un conjunto de
5

actividades fundamentales que se encuentran presentes en todos ellos: 1. Especificacin de software: Se debe definir la funcionalidad y restricciones operacionales que debe cumplir el software. 2. Diseo e Implementacin: Se disea y construye el software de acuerdo a la especificacin. 3. Validacin: El software debe validarse, para asegurar que cumpla con lo que quiere el cliente. 4. Evolucin: El software debe evolucionar, para adaptarse a las necesidades del cliente. Adems de estas actividades fundamentales, Pressman menciona un conjunto de actividades protectoras, que se aplican a lo largo de todo el proceso del software. Ellas se sealan a continuacin:

Seguimiento y control de proyecto de software. Revisiones tcnicas formales. Garanta de calidad del software. Gestin de configuracin del software. Preparacin y produccin de documentos. Gestin de reutilizacin. Mediciones. Gestin de riesgos.

Pressman caracteriza un proceso de desarrollo de software como se muestra en la Figura 2. Los elementos involucrados se describen a continuacin:

Un marco comn del proceso, definiendo un pequeo nmero de actividades del marco de trabajo que son aplicables a todos los proyectos de software, con independencia del tamao o complejidad.

Un conjunto de tareas, cada uno es una coleccin de tareas de ingeniera del software, hitos de proyectos, entregas y productos de trabajo del software, y puntos de garanta de calidad, que permiten que las actividades
6

del marco de trabajo se adapten a las

caractersticas del proyecto de software y los requisitos del equipo del proyecto.

Las actividades de proteccin, tales como garanta de calidad del software, gestin de configuracin del software y medicin, abarcan el modelo del proceso. Las actividades de proteccin son independientes de cualquier actividad del marco de trabajo y aparecen durante todo el proceso.

Figura 2: Elementos del proceso del software Otra perspectiva utilizada para determinar los elementos del proceso de desarrollo de software es establecer las relaciones entre elementos que permitan responder Quin debe hacer Qu, Cundo y Cmo debe hacerlo.

Figura 3: Relacin entre elementos del proceso del software En la Figura 3 se muestran los elementos de un proceso de desarrollo de software y sus

relaciones. As las interrogantes se responden de la siguiente forma: Quin: Las Personas participantes en el proyecto de desarrollo desempeando uno o

ms Roles especficos. Qu: Un Artefacto es producido por un Rol en una de sus Actividades. Los

Artefactos se especifican utilizando Notaciones especficas. Las Herramientas apoyan la elaboracin de Artefactos soportando ciertas Notaciones. Cmo y Cundo: Las Actividades son una serie de pasos que lleva a cabo un Rol

durante el proceso de desarrollo. El avance del proyecto est controlado mediante hitos que establecen un determinado estado de terminacin de ciertos Artefactos. La composicin y sincrona de las actividades est basada en un conjunto de Principios y Prcticas. Las Prcticas y Principios enfatizan ciertas actividades y/o la forma como deben realizarse, por ejemplo: desarrollar iterativamente, gestionar requisitos, desarrollo basado en componentes, modelar visualmente, verificar continuamente la calidad, gestionar los cambios, entre otros. MODELOS TRADICIONELES DE LOS SISTEMAS DE INFORMACION Hay varios modelos para perfilar el proceso de desarrollo, cada uno de las cuales cuenta con pros y contras. El proyecto debera escoger el ms apropiado para sus necesidades. En ocasiones puede que una combinacin de varios modelos sea apropiado. o Modelo de cascada El modelo de cascada muestra un proceso donde los desarrolladores han de seguir las siguientes fases de forma sucesiva: Especificacin de requisitos Diseo del software Construccin o Implementacin del software Integracin Pruebas (o validacin) Despliegue (o instalacin)
8

Mantenimiento

Siguiendo el modelo de cascada de forma estricta, slo cuando se finaliza una fase, comienza la otra. En ocasiones se realiza una revisin antes de iniciar la siguiente fase, lo que permite la posibilidad de cambios (lo que puede incluir un proceso de control formal de cambio). Las revisiones tambin se utilizan para asegurar que la fase anterior ha sido totalmente finalizada; los criterios para completar una fase se conocen frecuentemente con el trmino ingls "gate" (puerta). Este modelo desaconseja revisitar y revisar fases que ya se han completado. Esta falta de flexibilidad en un modelo de cascada puro ha sido fuente de crtica de los defensores de modelos ms flexibles. o Modelo de espiral La principal caractersticas del modelo en espiral es la gestin de riesgos de forma peridica en el ciclo de desarrollo. Este modelo fue creado en 1988 por Barry Boehm, combinando algunos aspectos clave de las metodologas del modelo de cascada y del desarrollo rpido de aplicaciones, pero dando nfasis en un rea que para muchos no jug el papel que requiere en otros modelos: un anlisis iterativo y concienzudo de los riesgos, especialmente en el caso de sistema complejos de gran escala. La espiral se visualiza como un proceso que pasa a travs de algunas iteraciones con el diagrama de los cuatro cuadrantes representativos de las siguientes actividades: 1. crear planes con el propsito de identificar los objetivos del software, seleccionados para implementar el programa y clarificar las restricciones en el desarrollo del software; 2. Anlisis de riesgos: una evaluacin analtica de programas seleccionados, para evaluar como identificar y eliminar el riesgo; 3. la implementacin del proyecto: implementacin del desarrollo del software y su pertinente verificacin; Modelo de espiral con nfasis en los riesgos, haciendo hincapi en las condiciones de las opciones y limitaciones para facilitar la reutilizacin de software, la calidad del software puede ayudar como una meta propia en la integracin en el desarrollo del producto. El nfasis se sita en el anlisis de riesgo, y por lo tanto requiere de clientes que acepten
9

este anlisis y acten en consecuencia. Para ello es necesaria confianza en los desarrolladores as como la predisposicin a gastar ms para solventar los temas, por lo cual este modelo se utiliza frecuentemente en desarrollo interno de software a gran escala. Si la implementacin del riesgo de anlisis afectar de forma esencial los beneficios del proyecto, no debera utilizarse este modelo. Los desarrolladores de software han de buscar de forma explcita riesgos y analizarlos de forma exhaustiva para que este modelo funcione. La primera fase es la bsqueda de un plan para conseguir los objetivos con las limitaciones del proyecto para as buscar y eliminar todos los riesgos potenciales por medio de un cuidadoso anlisis, y si fuera necesario incluyendo la fabricacin de un prototipo. Si es imposible descartar algunos riesgos, el cliente ha de decidir si es conveniente terminar el proyecto o seguir adelante ignorando los riesgos. Por ltimo, se evalan los resultados y se inicia el diseo de la siguiente fase. Desarrollo iterativo e incremental El desarrollo iterativo recomienda la construccin de secciones reducidas de software que irn ganando en tamao para facilitar as la deteccin de problemas de importancia antes de que sea demasiado tarde. Los procesos iterativos pueden ayudar a desvelar metas del diseo en el caso de clientes que no saben cmo definir lo que quieren. Desarrollo gil El desarrollo gil de software utiliza un desarrollo iterativo como base para abogar por un punto de vista ms ligero y ms centrado en las personas que en el caso de las soluciones tradicionales. Los procesos giles utilizan retroalimentacin en lugar de planificacin, como principal mecanismo de control. La retroalimentacin se canaliza por medio de pruebas peridicas y frecuentes versiones del software. Hay muchas variantes de los procesos giles: En el caso de la programacin extrema (XP), las fases se realizan en pasos muy cortos (o "continuos") con respecto al anterior. El primer paso (intencionalmente incompleto) por los pasos puede ocurrir en un da o en una semana, en lugar de los meses o aos de cada paso completo en el modelo en cascada. En primer lugar, se crean pruebas automatizadas para
10

proveer metas concretas al desarrollo. Despus se programa el cdigo, que ser completo cuando todas las pruebas se superan sin errores, y los desarrolladores ya no sabran como mejorar el conjunto de pruebas necesario. Codificacin y correccin El desarrollo de codificacin y correccin (en ingls "Code and fix") es, ms que una estrategia predeterminada, el resultado de una falta de experiencia o presin que se ejerce sobre los desarrolladores para cumplir con una fecha de entrega. Sin dedicar tiempo de forma explcita para el diseo, los programadores comienzan de forma inmediata a producir cdigo. Antes o despus comienza la fase de pruebas de software (a menudo de forma tarda) y los inevitables errores que se encuentran han de eliminarse antes de poder entregar el software. FASES: REQUISITOS, ANALISIS, DISEO, IMPLEMENTACION,

MANTENIMIENTO Y RETIRO. Los requisitos La captura de los requisitos en algunas oportunidades resulta un poco complicada, esta es la accin de descubrir, luego de realizar ciertas averiguaciones, lo que los usuarios desean que los desarrolladores de software construyan. El flujo de trabajo de los requisitos tiene como objetivo fundamental guiar el desarrollo hacia el sistema correcto. Esto mediante una buena descripcin de los requisitos del problema que permite un buen entendimiento entre los clientes o usuarios y los desarrolladores del sistema. Anlisis En este flujo se representa el anlisis de los requisitos que se describen en la captura de los requisitos. El propsito de realizar esta accin es conseguir la comprensin de los requisitos ms precisa y una descripcin de estos que nos ayude a estructurar mejor el sistema entero. En el anlisis se utiliza un lenguaje que se basa en un modelo de objetos conceptual, al cual se le llama modelo de anlisis. El modelo de anlisis permite refinar los requisitos y razonar sobre los aspectos internos del sistema.

11

Una de las razones por las cuales es importante analizar los requisitos en la forma de un modelo de anlisis es que el modelo de anlisis estructura los requisitos de un modo que facilita su comprensin, su preparacin, su modificacin y en forma general, su mantenimiento. Diseo El diseo no es ms que la modelacin del sistema en la cual encontramos su forma para que soporte todos los requisitos. El resultado del anlisis, es decir, el modelo de anlisis representa una entrada esencial en el diseo. Entre los objetivos del diseo encontramos los siguientes: obtener una comprensin en profundidad de los requisitos y restricciones relacionadas con los lenguajes de programacin, componentes reutilizables, sistemas operativos, tecnologas de distribucin y concurrencia, tecnologa de interfaz de usuario, tecnologas de gestin de transacciones, entre otras. Implementacin Aqu se toma en cuenta el resultado del diseo y se realiza la implementacin del sistema en trminos de componentes, es decir, ficheros de cdigo fuente, scripts, ficheros de cdigos binarios, ejecutables y similares. La implementacin tiene varios propsitos entre los cuales se pueden citar los siguientes: Planificar las integraciones de sistema necesarias en cada iteracin. Asignar componentes ejecutables a nodos en el diagrama de despliegue para distribuir el sistema. Implementar las clases y subsistemas encontrados durante el diseo. Probar los componentes individualmente, y a continuacin integrarlos compilndolos y enlazndolos en uno o ms ejecutables, antes de ser enviados para ser integrados y llevar a cabo las comprobaciones del sistema. EL PROCESO UNIFICADO RATIONAL Es un proceso de desarrollo de software desarrollado por la empresa Rational Software, actualmente propiedad de IBM. Junto con el Lenguaje Unificado de Modelado UML, constituye la metodologa estndar ms utilizada para el anlisis, diseo, implementacin y
12

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, tambin desarrollado por Rational, que incluye informacin entrelazada de diversos artefactos y descripciones de las diversas actividades. Est incluido en el Rational Method Composer (RMC), que permite la personalizacin de acuerdo con las necesidades.

HISTORIA DEL PROCESO UNIFICADO El PUD es el resultado de 30 aos de desarrollo y uso prctico. Se puede dividir el transcurso de su desarrollo en tres etapas: desde la publicacin de Objectory Method publicado en 1987 como resultado del xito del mtodo Ericsson, pasando por el Objectory Rational Process (Desarrollado por IBM Rational entre 1996-1997) hasta el Proceso Unificado de Rational (publicado en 1998). El Proceso Unificado de Desarrollo Software o simplemente Proceso Unificado es un marco de desarrollo de software que se caracteriza por estar dirigido por casos de uso, centrado en la arquitectura y por ser iterativo e incremental. El refinamiento ms conocido y documentado del Proceso Unificado es el Proceso Unificado de Rational o simplemente RUP. Es el producto principal de la unin de los mtodos de Rumbaugh, Booch y Jacobson aunque hay otros aportes de diversas fuentes. Segn sus autores, son tres dcadas de desarrollo para llegar a lo actual. En su historia han influido: El Mtodo de Ericsson El Lenguaje de Descripcin y Especificacin de la CCITT Objectory El Mtodo de Rational El Proceso Objectory de Rational

13

El Lenguaje de Modelado Unificado (UML) El Proceso Unificado de Rational

El Proceso Unificado no es simplemente un proceso, sino un marco de trabajo extensible que puede ser adaptado a organizaciones o proyectos especficos. De la misma forma, el Proceso Unificado de Rational, tambin es un marco de trabajo extensible, por lo que muchas veces resulta imposible decir si un refinamiento particular del proceso ha sido derivado del Proceso Unificado o del RUP. Por dicho motivo, los dos nombres suelen utilizarse para referirse a un mismo concepto. METODO ERICSSON El estudio del origen del PUD, se remonta a 1967, donde la compaa Ericsson modelaba un sistema entero como una serie de bloques interconectados. Los bloques de ms bajo nivel se incorporaban a subsistemas de mayor nivel, con lo que se lograba que el sistema fuera ms manejable. Los bloques, eran identificados estudiando los Casos de Negocio (actuales casos de uso) que se definan con anterioridad. Cada caso de negocio permita detallar los bloques que deban cooperar para llevarlo a cabo. Al tener adjudicada la responsabilidad de cada bloque, se preparaba su especificacin. Las actividades de diseo generaban un conjunto de diagramas de bloques estticos con sus interfaces, agrupados en subsistemas (su semejante en la actualidad son los diagramas de clases paquetes de UML). El producto primognito de las actividades de diseo radica en la descripcin de la arquitectura de software, la cual consista en la comprensin de los requisitos ms crticos, junto con una breve descripcin de cada bloque y el agrupamiento de ste en subsistemas. Luego, eran representadas en diagramas la descripcin e interconexiones de los bloques. El mtodo era adelantado a su tiempo, ya que los clientes no acostumbraban a que se representaran los productos de software en forma similar a los datos de proyectos de ingeniera. El mtodo Ericsson es esencialmente el que actualmente se conoce como desarrollo basado en componentes. Comprob su efectividad de diseo modular al brindar la posibilidad de instalar cada bloque ejecutable o modificado sobre la marcha de un sistema
14

de telecomunicaciones en ejecucin el 100 por ciento de su tiempo (era sumamente improductivo detener un sistema de tal magnitud simplemente para hacer cambios). EL LENGUAJE DE DESCRIPCION Y ESPECIFICACION En el contexto la computacin y ramas afines, un lenguaje de especificacin o lenguaje de descripcin es un lenguaje formal o semi-formal cuya funcin es construir modelos de los sistemas que se desea elaborar. A diferencia de los lenguajes de programacin, que son lenguajes interpretables o traducibles por una computadora hacia una representacin ejecutable, los lenguajes de especificacin no son por lo general utilizados para implementar el sistema, sino para especificarlo, conceptualizarlo o incluso validarlo, aunque tambin suelen ser legibles para un programa de computadora, que puede asistir en el proceso de validacin. Las especificaciones hechas en un lenguaje de descripcin no suelen ser interpretables o ejecutables, sin embargo existen algunos ambientes de desarrollo basados en lenguajes de descripcin, que permiten la generacin del sistema a partir del modelo. Los lenguajes de especificacin pueden dividirse en semi-formales y formales. Algunos lenguajes de especificacin: Alloy, lenguaje de especificaciones que utiliza la lgica de primer orden y se basa en el uso de relaciones. Autmatas formalismo utilizado para modelar sistemas discretos en general. B, lenguaje de descripcin formal basado en la lgica de predicados. Clculo Pi, lenguaje de especificacin para sistemas distribuidos y paralelos. CCS, lenguaje formal basado en el lgebra de procesos. CSP, lenguaje formal basado en el lgebra de procesos Estelle, lenguaje formal basado en autmatas de estado finito para la especificacin de sistemas distribuidos. Larch, familia de lenguajes formales de especificacin. Lotos, lenguaje formal basado en el lgebra de procesos.
15

Promela, lenguaje formal basado en la lgica temporal lineal y los autmatas de Buchi.

Redes de Petri formalismo equivalente a los autmatas, utilizado para la especificacin de sistemas discretos paralelos o distribuidos.

SDL, lenguaje visual para el diseo de sistemas distribuidos basado en autmatas. UML, notacin semiformal para modelar programas orientados a objetos. VHDL, lenguaje de descripcin (e implantacin) de circuitos electrnicos. Z, lenguaje de descripcin formal basada en la prueba automtica de teoremas usando la lgica.

Z.120, estndar semiformal de la ITU-T para diagramas de flujo.

MODELO RATIONAL Rational es un agrupamiento de metodologas y herramientas que abarca todos los aspectos del desarrollo de software, desde su concepcin hasta la elaboracin del producto. La metodologa de RATIONAL propone el desarrollo de software basado en las mejores prcticas recopiladas en innumerables proyectos exitosos. Esta metodologa esta compilada en proceso de desarrollo Rational Unified Process. Para ayudar en la implementacin del proceso Rational ha desarrollado un conjunto de herramientas integradas que permiten desarrollar las actividades del proceso y obtener una sinergia al integrarse entre las distintas herramientas permitiendo a todo el equipo de desarrollo compartir y utilizar la informacin necesaria en el momento adecuado. Rational provee herramientas para las siguientes fases del desarrollo de software: Gestin de requerimientos. Modelado visual de sistemas basado en UML. Desarrollo de aplicaciones Web y Java. Pruebas de software. Gerenciamiento de la configuracin y el cambio. Por otro lado, en lo que se refiere a la metodologa esta comprende tres fases claves: Dirigido por los casos de uso, centrado en la

16

arquitectura, iterativo e incremental. En lo referente a dirigido por los casos de uso, est enfocado hacia el cliente y se utilizan con algunas modificaciones tal vez, hasta la disciplina de pruebas, en la cual, un caso de uso puede a su vez tener uno o ms casos de prueba. CARACTERISTICAS DEL PROCESO UNIFICADO DE DESARROLLO DEL SOFTWARE (DIRIGIDAS A CASO DE USOS, CENTRADO EN LA ARQUITECTURA, INTERACTIVO E INCREMENTAL) o Dirigido por los casos de uso En el Proceso Unificado los casos de uso se utilizan para capturar los requisitos funcionales y para definir los contenidos de las iteraciones. La idea es que cada iteracin tome un conjunto de casos de uso o escenarios y desarrolle todo el camino a travs de las distintas disciplinas: diseo, implementacin, prueba, etc. El proceso dirigido por casos de uso es el rup. Nota: en UP se est Dirigido por requisitos y riesgos de acuerdo con el Libro UML 2 de ARLOW, Jim que menciona el tema. o Centrado en la arquitectura El Proceso Unificado asume que no existe un modelo nico que cubra todos los aspectos del sistema. Por dicho motivo existen mltiples modelos y vistas que definen la arquitectura de software de un sistema. La analoga con la construccin es clara, cuando construyes un edificio existen diversos planos que incluyen los distintos servicios del mismo: electricidad, fontanera, etc. o Iterativo e Incremental El Proceso Unificado es un marco de desarrollo iterativo e incremental compuesto de cuatro fases denominadas Inicio, Elaboracin, Construccin y Transicin. Cada una de estas fases es a su vez dividida en una serie de iteraciones (la de inicio puede incluir varias iteraciones en proyectos grandes). Estas iteraciones ofrecen como resultado un incremento del producto desarrollado que aade o mejora las funcionalidades del sistema en desarrollo. Cada una de estas iteraciones se divide a su vez en una serie de disciplinas que recuerdan a las definidas en el ciclo de vida clsico o en cascada: Anlisis de requisitos, Diseo, Implementacin y Prueba. Aunque todas las iteraciones suelen incluir trabajo en casi todas
17

las disciplinas, el grado de esfuerzo dentro de cada una de ellas vara a lo largo del proyecto.

CICLO DE VIDA DEL PROCESO UNIFICADO Y FASES DEL CICLO DE VIDA (INICIO, ELABORACION Y TRANSICION) El Proceso Unificado se repite a lo largo de una serie de ciclos que constituyen la vidade un sistema. Cada ciclo constituye una versin del sistema. Fases: Cada ciclo constas de cuatro fases: inicio, elaboracin, construccin, y transicin. Fase de Inicio Durante la fase de inicio se desarrolla una descripcin del producto final, y se presenta el anlisis del negocio. Esta fase responde las siguientes preguntas: Cules son las principales funciones del sistema para los usuarios ms importantes? Cmo podra ser la mejor arquitectura del sistema? Cul es el plan del proyecto y cuanto costar desarrollar el producto? En esta fase se identifican y priorizan los riesgos ms importantes. El objetivo de esta fase es ayudar al equipo de proyecto a decidir cules son los verdaderos objetivos del proyecto. Las iteraciones exploran diferentes soluciones posibles, y diferentes arquitecturas posibles. Puede que todo el trabajo fsico realizado en esta fase sea descartado. Lo nico que normalmente sobrevive a la fase de inicio es el incremento del conocimiento en el equipo. Los artefactos que tpicamente sobreviven a esta fase son: - Un enunciado de los mayores requerimientos planteados generalmente como casos de uso. - Un boceto inicial de la arquitectura. - Una descripcin de los objetivos del proyecto. - Una versin muy preliminar del plan del proyecto.

18

- Un modelo del negocio. La fase de inicio finaliza con el Hito de Objetivos del Ciclo de Vida.

Fase de Elaboracin Durante la fase de elaboracin se especifican en detalle la mayora de los casos de uso del producto y se disea la arquitectura. Las iteraciones en la fase de elaboracin: - Establecen una firme comprensin del problema a solucionar. - Establece la fundacin arquitectural para el software. - Establece un plan detallado para las siguientes iteraciones. - Elimina los mayores riesgos. El resultado de esta fase es la lnea base de la arquitectura. En esta fase se construyen tpicamente los siguientes artefactos: - El cuerpo bsico del sw en la forma de un prototipo arquitectural. - Casos de prueba - La mayora de los casos de uso (80%) que describen la funcionalidad del sistema. - Un plan detallado para las siguientes iteraciones. La fase de elaboracin finaliza con el hito de la Arquitectura del Ciclo de Vida. Fase de Transicin La fase de transicin cubre el perodo durante el cual el producto se convierte en la versin beta. Las iteraciones en esta fase continan agregando caractersticas al software. Sin embargo las caractersticas se agregan a un sistema que el usuario se encuentra utilizando activamente. Los artefactos construidos en esta fase son los mismos que en la fase de construccin. El equipo se encuentra ocupado fundamentalmente en corregir y extender la funcionalidad del sistema desarrollado en la fase anterior. La fase de transicin finaliza con el hito de Lanzamiento del Producto.

19

Conclusin El desarrollo del software y la programacin es uno de los pilares fundamentales de la informtica y al cual se dedican muchas horas de esfuerzos en empresas, colegios, academias y universidades. Conforme a la tecnologa va avanzando, van apareciendo nuevas soluciones, nuevas formas de programacin, nuevos lenguajes y un sin fin de herramientas que intentan realizar el trabajo del desarrollador un poco ms fcil. La programacin orientadas a objetos o los compiladores basados en maquinas virtuales (en muchos casos, multiplataforma), tambin a sus puestos unas renovacin en la manera de programar. El Proceso Unificado est dirigido por casos de usos. Todos los casos de uso juntos constituyen el modelo de casos de uso; los casos de uso no son slo una herramienta para especificar los requisitos de un sistema: Tambin guan su diseo, implementacin, y prueba; esto es, guan el proceso de desarrollo. El Proceso Unificado est dirigido a casos de uso, centrado en la arquitectura y es interactivo e incremental. En cuanto a los ciclos de vida de estos procesos tenemos que, el desarrollo de un ciclo se realiza a lo largo del tiempo. Segn Booch, Rambaugh y Jacobson, (2000) Cada ciclo se divide a su vez en 4 fases, las cuales son: inicio, elaboracin y transicin.

20

Anexos

Modelo de desarrollo en cascada.

21

Modelo de desarrollo en Espiral

Diferentes procesos unificados

22

Bibliografa Cangnova, R (2004) Editorial [Documento en lnea]. Disponible: http://www.arcride.edu.ar/appei/revistas/r26a4.htm [Consulta: 2004, Octubre 17]

Guerrero, L. (2003) Clase 23 - Proceso Unificado de Desarrollo [Documento en lnea]. Disponible: http://www.dcc.uchile.cl/~luguerre/cc51h/clase23.html [Consulta: 2004, Octubre 10]
23

24