ndice

PROCESO UNIFICADO RACIONAL DEFINICIN ERROR! BOOKMARK NOT DEFINED.

HISTORIA DEL MODELO DE CASCADA ERROR! BOOKMARK NOT DEFINED. PRINCIPIOS BSICOS DEL MODELO DE CASCADA FASES DEL MODELO DE CASCADA INGENIERA Y ANLISIS DEL SISTEMA: ERROR! BOOKMARK NOT DEFINED. ERROR! BOOKMARK NOT DEFINED. ERROR! BOOKMARK NOT DEFINED.

ANLISIS DE LOS REQUISITOS DEL SOFTWARE:ERROR! BOOKMARK NOT DEFINED. DISEO: LA ETAPA DE DISEO CODIFICACIN: PRUEBA: MANTENIMIENTO: MODELO EN CASCADA PURO O SECUENCIAL ERROR! BOOKMARK NOT DEFINED. ERROR! BOOKMARK NOT DEFINED. ERROR! BOOKMARK NOT DEFINED. ERROR! BOOKMARK NOT DEFINED. ERROR! BOOKMARK NOT DEFINED. ERROR! BOOKMARK NOT DEFINED. Bookmark not

Modelo en cascada realimentado para el ciclo de vidaError! defined. Modelos Modificados de Cascada El modelo Sashimi Modelo en Cascada Bennington 1956: La metodologa en cascada es esencialmente: Argumentos a favor del modelo de cascada Ventajas Desventajas Problemas del modelo de cascada El fracaso del modelo de cascada Uso La crtica del modelo de cascada

Error! Bookmark not defined. Error! Bookmark not defined. Error! Bookmark not defined. Error! Bookmark not defined. Error! Bookmark not defined. Error! Bookmark not defined. Error! Bookmark not defined. Error! Bookmark not defined. Error! Bookmark not defined. Error! Bookmark not defined. Error! Bookmark not defined.
i

ndice

Conclusin MAPA CONCEPTUAL CUESTIONARIO BIBLIOGRAFIA

Error! Bookmark not defined. 21 Error! Bookmark not defined. 23

ii

Contenido

EL PROCESO UNIFICADO RACIONAL

Introduccin El Proceso Unificado Racional (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, 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. Est incluido en el Rational Method Composer (RMC), que permite la personalizacin de acuerdo a necesidades. Originalmente se dise un proceso genrico y de dominio pblico, el Proceso Unificado, y una especificacin ms detallada, el Rational Unified Process, que se vendiera como producto independiente. Historia La Figura 1 ilustra la historia de RUP. El antecedente ms importante se ubica en 1967 con la Metodologa Ericsson (Ericsson Approach) elaborada por Ivar Jacobson, una aproximacin de desarrollo basada en componentes, que introdujo el concepto de Caso de Uso. Entre los aos de 1987 a 1995 Jacobson fund la compaa Objectory AB y lanza el proceso de desarrollo Objectory (abreviacin de Object Factory).

Contenido

Posteriormente en

1995

Rational Software Corporation adquiere Objectory se desarrolla Rational Objectory Process (ROP) a y del Enfoque Rational (Rational Approach)

AB y entre 1995 y 1997 partir de Objectory 3.8

adoptando UML como lenguaje de modelado. Desde ese entonces y a la cabeza de Grady Booch, Ivar Jacobson y James Rumbaugh, Rational Software desarroll e incorpor diversos elementos para expandir ROP, destacndose especialmente el flujo de trabajo conocido como modelado del negocio. En junio del 1998 se lanza Rational Unified Process. Ampliandon la historia del RUP, los orgenes de RUP se remontan al modelo espiral original de Barry Boehm. Ken Hartman, uno de los contribuidores claves de RUP colabor con Boehm en la investigacin. En 1995 Rational Software compr una compaa sueca llamada Objectory AB, fundada por Ivar Jacobson, famoso por haber incorporado los casos de uso a los mtodos de desarrollo orientados a objetos. El Rational Unified Process fue el resultado de una convergencia de Rational Approach y Objectory (el proceso de la empresa Objectory AB). El primer resultado de esta fusin fue el Rational Objectory Process, la primera versin de RUP, fue puesta en el mercado en 1998, siendo el arquitecto en jefe Philippe Kruchten. Generalidades y aportes: Proceso de desarrollo propuesto por Rational Software Corporation resultado del esfuerzo de las tres ltimas dcadas en desarrollo de software y de la experiencia desus creadores Ivar Jacobson, Grady Booch y James Rumbaugh. Orgenes El antecedente ms importante lo ubicamos en 1967 con la Metodologa Ericsson (Ericsson Approach), sta es una aproximacin de desarrollo basada en componentes, que introdujo el concepto de caso de uso; entre los aos de 1987 a 1995 Jacobson funda la compaa Objectory AB y lanza el proceso de desarrollo Objectory (abreviacin de Object Factory), posteriormente en 1995 Rational Software Corporation adquiere Objectory AB y es entre 1995 y 1997 que se desarrolla Rational Objectory Process (ROP) fruto del encuentro y evolucin de
2

Contenido

Objectory 3.8 y la Metodologa Rational (Rational Approach) que adopta por primera vez UML como lenguaje de modelamiento. A principios de los noventas, la guerra de los mtodos hizo evidente la necesidad de unificar criterios, es as como Grady Booch autor del mtodo Booch y James Rumbaugh (desarrollador para General Electric) se unieron en Rational en 1994, despus en 1995 se une Jacobson y gracias al esfuerzo de varias compaas y metodologistas evolucion UML hasta ser un estndar en 1997, el cual es adoptado en todos los modelos del ROP. Desde ese entonces y a la cabeza de Booch, Jacobson y Rumbaugh, Rational ha desarrollado e incorporado diversos elementos para expandir el ROP, destacndose especialmente el flujo de trabajo conocido como modelamiento del negocio, es as como en junio del 1998 se lanza Rational Unified Process 5.0 evolucionado hasta el momento de elaboracin de este documento bajo el nombre de RUP. La evolucin y orgenes de este proceso de desarrollo se pueden visualizar mejor en la siguiente figura

Principios de desarrollo El RUP est basado en 6 principios clave que son los siguientes:
3

Contenido

Adaptar el proceso El proceso deber adaptarse a las necesidades del cliente ya que es muy importante interactuar con l. Las caractersticas propias del proyecto u organizacin. El tamao del mismo, as como su tipo o las regulaciones que lo condicionen, influirn en su diseo especfico. Tambin se deber tener en cuenta el alcance del proyecto en un rea subformal. Equilibrar prioridades Los requisitos de los diversos participantes pueden ser diferentes, contradictorios o disputarse recursos limitados. Debe encontrarse un equilibrio que satisfaga los deseos de todos. Gracias a este equilibrio se podrn corregir desacuerdos que surjan en el futuro. Demostrar valor iterativamente Los proyectos se entregan, aunque sea de un modo interno, en etapas iteradas. En cada iteracin se analiza la opinin de los inversores, la estabilidad y calidad del producto, y se refina la direccin del proyecto as como tambin los riesgos involucrados Colaboracin entre equipos El desarrollo de software no lo hace una nica persona sino mltiples equipos. Debe haber una comunicacin fluida para coordinar requisitos, desarrollo, evaluaciones, planes, resultados, etc. Elevar el nivel de abstraccin Este principio dominante motiva el uso de conceptos reutilizables tales como patrn del software, lenguajes 4GL o marcos de referencia (frameworks) por nombrar algunos. Esto evita que los ingenieros de software vayan directamente de los requisitos a la codificacin de software a la medida del cliente, sin saber con certeza qu codificar para satisfacer de la mejor manera los requisitos y sin comenzar desde un principio pensando en la reutilizacin del cdigo. Un alto nivel de abstraccin tambin permite discusiones sobre diversos niveles y soluciones arquitectnicas. stas se pueden acompaar por las representaciones visuales de la arquitectura, por ejemplo con el lenguaje UML. Enfocarse en la calidad
4

Contenido

El control de calidad no debe realizarse al final de cada iteracin, sino en todos los aspectos de la produccin. El aseguramiento de la calidad forma parte del proceso de desarrollo y no de un grupo independiente. Ciclo de vida

Esfuerzo en actividades segn fase del proyecto. El ciclo de vida RUP es una implementacin del Desarrollo en espiral. Fue creado ensamblando los elementos en secuencias semi-ordenadas. El ciclo de vida organiza las tareas en fases e iteraciones. RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en nmero variable segn el proyecto y en las que se hace un mayor o menor hincapi en las distintas actividades. En la Figura muestra cmo vara el esfuerzo asociado a las disciplinas segn la fase en la que se encuentre el proyecto RUP. Las primeras iteraciones (en las fases de Inicio y Elaboracin) se enfocan hacia la comprensin del problema y la tecnologa, la delimitacin del mbito del proyecto, la eliminacin de los riesgos crticos, y al establecimiento de una baseline (Lnea Base) de la arquitectura. Durante la fase de inicio las iteraciones hacen mayor nfasis en actividades de modelado del negocio y de requisitos. En la fase de elaboracin, las iteraciones se orientan al desarrollo de la baseline de la arquitectura, abarcan ms los flujos de trabajo de requisitos, modelo de negocios (refinamiento), anlisis, diseo y una parte de implementacin orientado
5

Contenido

a la baseline de la arquitectura. En la fase de construccin, se lleva a cabo la construccin del producto por medio de una serie de iteraciones. Para cada iteracin se selecciona algunos Casos de Uso, se refina su anlisis y diseo y se procede a su implementacin y pruebas. Se realiza una pequea cascada para cada ciclo. Se realizan tantas iteraciones hasta que se termine la implementacin de la nueva versin del producto. En la fase de transicin se pretende garantizar que se tiene un producto preparado para su entrega a la comunidad de usuarios. Como se puede observar en cada fase participan todas las disciplinas, pero que dependiendo de la fase el esfuerzo dedicado a una disciplina vara. Principales caractersticas Forma disciplinada de asignar tareas y responsabilidades (quin hace qu, cundo y cmo) Pretende implementar las mejores prcticas en Ingeniera de Software Desarrollo iterativo Administracin de requisitos Uso de arquitectura basada en componentes Control de cambios Modelado visual del software Verificacin de la calidad del software El RUP como ya se hizo mencin en prrafos anteriores, es un producto de Rational (IBM). Se caracteriza por ser iterativo e incremental, estar centrado en la arquitectura y guiado por los casos de uso. 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). Fases Establece oportunidad y alcance Identifica las entidades externas o actores con las que se trata
6

Contenido

Identifica los casos de uso RUP comprende 2 aspectos importantes por los cuales se establecen las disciplinas: Proceso: Las etapas de esta seccin son: Modelado de negocio Requisitos Anlisis y Diseo Implementacin Pruebas Despliegue Soporte: En esta parte nos encontramos con las siguientes etapas: Gestin del cambio y configuraciones Gestin del proyecto Entorno La estructura dinmica de RUP es la que permite que ste sea un proceso de desarrollo fundamentalmente iterativo, y en esta parte se ven inmersas las 4 fases descritas anteriormente: Inicio(Tambin llamado Incepcin o Concepcin) Elaboracin Desarrollo(Tambin llamado Implementacin, Construccin) Cierre (Tambin llamado Transicin) Fase de Inicio: Esta fase tiene como propsito definir y acordar el alcance del proyecto con los patrocinadores, identificar los riesgos asociados al proyecto, proponer una visin muy general de la arquitectura de software y producir el plan de las fases y el de iteraciones posteriores. Fase de elaboracin: En la fase de elaboracin se seleccionan los casos de uso que permiten definir la arquitectura base del sistema y se desarrollaran en esta fase, se realiza la especificacin de los casos de uso seleccionados y el primer anlisis del dominio del problema, se disea la solucin preliminar. Fase de Desarrollo: El propsito de esta fase es completar la funcionalidad del sistema, para ello se deben clarificar los requisitos pendientes, administrar los
7

Contenido

cambios de acuerdo a las evaluaciones realizados por los usuarios y se realizan las mejoras para el proyecto. Fase de Cierre: El propsito de esta fase es asegurar que el software est disponible para los usuarios finales, ajustar los errores y defectos encontrados en las pruebas de aceptacin, capacitar a los usuarios y proveer el soporte tcnico necesario. Se debe verificar que el producto cumpla con las especificaciones entregadas por las personas involucradas en el proyecto. Artefactos xxx RUP en cada una de sus fases (pertenecientes a la estructura esttica) realiza una serie de artefactos que sirven para comprender mejor tanto el anlisis como el diseo del sistema (entre otros). Estos artefactos (entre otros) son los siguientes: Inicio: Documento Visin Especificacin de Requisitos Elaboracin: Diagramas de caso de uso Construccin: Documento Arquitectura que trabaja con las siguientes vistas: Vista Lgica Diagrama de clases Modelo E-R (Si el sistema as lo requiere) Vista de Implementacin Diagrama de Secuencia Diagrama de estados Diagrama de Colaboracin Vista Conceptual Modelo de dominio Vista fsica Mapa de comportamiento a nivel de hardware. Comentarios sobre Alcance del RUP
8

Contenido

La metodologa RUP es ms apropiada para proyectos grandes (Aunque tambin pequeos), dado que requiere un equipo de trabajo capaz de administrar un proceso complejo en varias etapas. En proyectos pequeos, es posible que no se puedan cubrir los costos de dedicacin del equipo de profesionales necesarios. Comentarios sobre Metodologa 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 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. El Rational Unified Process o Proceso Unificado de Racional. Es un proceso de ingeniera de software que suministra un enfoque para asignar tareas y responsabilidades dentro de una organizacin de desarrollo. Su objetivo es asegurar la produccin de software de alta calidad que satisfaga la necesidad del usuario final dentro de un tiempo y presupuesto previsible. Es una metodologa de desarrollo iterativo enfocada hacia los casos de uso, manejo de riesgos y el manejo de la arquitectura. El RUP mejora la productividad del equipo ya que permite que cada miembro del grupo sin importar su responsabilidad especfica acceda a la misma base de datos de conocimiento. Esto hace que todos compartan el mismo lenguaje, la misma visin y el mismo proceso acerca de cmo desarrollar software. CICLO DE VIDA En el ciclo de vida RUP veremos una implementacin del desarrollo en espiral. Con el ciclo de vida se establecen tareas en fases e iteraciones. El RUP maneja el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en nmero variable Las primeras iteraciones (en las fases de Inicio y Elaboracin) se enfocan hacia la comprensin del problema y la tecnologa, la delimitacin del mbito del proyecto, la eliminacin de los riesgos crticos, y al establecimiento de una base de inicio Fases
9

Contenido

Fase de inicio Durante esta fase de inicio las iteraciones se centran con mayor nfasis en las actividades de modelamiento de la empresa y en sus requerimientos Fase de Elaboracin Durante esta fase de elaboracin, las iteraciones se centran al desarrollo de la base de la diseo, encierran ms los flujos de trabajo de requerimientos, modelo de la organizacin, anlisis, diseo y una parte de implementacin orientada a la base de la construccin Fase de construccin Durante esta fase de construccin, se lleva a cabo la construccin del producto por medio de una serie de iteraciones las cuales se seleccionan algunos Casos de Uso, se redefine su anlisis y diseo y se procede a su implantacin y pruebas. En esta fase se realiza una pequea cascada para cada ciclo, se

realizan tantas iteraciones hasta que se termine la nueva implementacin del producto. Fase de Transicin Durante esta fase de transicin busca garantizar que se tiene un producto preparado para su entrega al usuario. Principales Caractersticas Forma disciplinada de asignar tareas y responsabilidades (quin hace qu, cundo y cmo) Pretende implementar las mejores prcticas en Ingeniera de Software Desarrollo iterativo Administracin de requisitos Uso de arquitectura basada en componentes Control de cambios Modelado visual del software Verificacin de la calidad del software El RUP es un producto de Rational (IBM). Se caracteriza por ser iterativo e incremental, estar centrado en la arquitectura y guiado por los casos de uso. Incluye artefactos (que son los productos tangibles del proceso como por ejemplo,
10

Contenido

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). Especificacin de las Fases Establece oportunidad y alcance Identifica las entidades externas o actores con las que se trata Identifica los casos de uso

RUP comprende 2 aspectos importantes por los cuales se establecen las disciplinas: Disciplinas Proceso: Las etapas de esta seccin son: Modelado de negocio Requisitos Anlisis y Diseo Implementacin Pruebas Despliegue

Soporte: En esta parte nos conseguimos con las siguientes etapas: Gestin del cambio y configuraciones Gestin del proyecto Entorno

La estructura dinmica de RUP es la que permite que este sea un proceso de desarrollo fundamentalmente iterativo, y en esta parte se ven inmersas las 4 fases descritas anteriormente: Inicio(Tambin llamado Incepcin) Elaboracin Desarrollo(Tambin llamado Implementacin, Construccin) Cierre (Tambin llamado Transicin)

Artefactos RUP en cada una de sus fases (pertenecientes a la estructura esttica) realiza una serie de artefactos que sirven para comprender mejor tanto el anlisis como
11

Contenido

el diseo del sistema estos artefactos son los siguientes: Inicio: Documento Visin Especificacin de Requerimientos

Elaboracin: Diagramas de caso de uso

Construccin: Documento Arquitectura que trabaja con las siguientes vistas: Vista Lgica: Diagrama de clases Modelo E-R (Si el sistema as lo requiere) Vista de Implementacin: Diagrama de Secuencia Diagrama de estados Diagrama de Colaboracin Vista Conceptual: Modelo de dominio Vista fsica: Mapa de comportamiento a nivel de hardware.

Implementacin del RUP para proyectos La metodologa RUP es ms apropiada para proyectos grandes (Aunque tambin pequeos), dado que requiere un equipo de trabajo capaz de administrar un proceso complejo en varias etapas. En proyectos pequeos, es posible que no se puedan cubrir los costos de dedicacin del equipo de profesionales necesarios. Diagrama General de RUP

12

Contenido

Acerca de la Figura En el eje horizontal se representa el tiempo y muestra los aspectos del ciclo de vida del proceso. Representa el aspecto dinmico del proceso a travs de las fases, iteraciones y productos intermedios. El eje vertical representa las disciplinas que agrupan actividades por su naturaleza. Representa el aspecto esttico del proceso a travs de componentes, disciplinas, actividades, flujos de trabajo, artefactos y roles. Ciclo de Vida de RUP En cuanto a tiempo el ciclo de vida de RUP se descompone en 4 fases secuenciales, cada cual concluye con un producto intermedio. Al terminar cada fase se realiza una evaluacin para determinar si se ha cumplido o no con los objetivos de la misma. Las fases son: Inicio (Inception), Elaboracin, Construccin y Transicin. Fases de Ciclo de Vida 1. Inicio (Inception) El objetivo general de esta fase es establecer un acuerdo entre todos los interesados acerca de los objetivos del proyecto. Esta fase es significativamente primaria para el desarrollo de nuevo software, ya que se asegura de identificar los riesgos relacionados con el negocio y requerimientos. Para proyectos de mejora de software existente esta fase es ms breve y se centra en asegurar que vale la pena y es posible, desarrollar el proyecto. 2. Elaboracin El objetivo en esta fase es establecer la arquitectura base del sistema para proveer bases estables para el esfuerzo de diseo e implementacin en la siguiente fase. La arquitectura debe abarcar todos las consideraciones de mayor importancia de los requerimientos y una evaluacin del riesgo. 3. Construccin
13

Contenido

El objetivo de la fase de construccin es clarificar los requerimientos faltantes y completar el desarrollo del sistema basados en la arquitectura base. Vista de cierta forma esta fase es un proceso de manufactura, en el cual el nfasis se torna hacia la administracin de recursos y control de las operaciones para optimizar costos, tiempo y calidad. 4. Transicin Esta fase se enfoca en asegurar que el software est disponible para sus usuarios. Esta fase se puede subdividir en varias iteraciones, adems incluye pruebas del producto para poder hacer el entregable del mismo, as como realizar ajuste menores de acuerdo a ajuste menores propuestos por el usuario. En este punto, la retroalimentacin de los usuarios se centra en depurar el producto, configuraciones, instalacin y aspectos sobre utilizacin. Disciplinas Una disciplina es una coleccin de actividades relacionadas con un rea de atencin dentro de todo el proyecto. El grupo de actividades que se encuentran dentro de una disciplina principalmente son una ayuda para entender el proyecto desde la perspectiva clsica de cascada. Las disciplinas son: Modelado de Negocios, Requerimientos, Anlisis y Diseo, Implementacin, Pruebas, Transicin, Configuracin y Administracin del Cambio Administracin de Proyectos y Ambiente. 1. Modelado de Negocios Los propsitos que tiene el Modelo de Negocios son: Entender los problemas que la organizacin desea solucionar e identificar mejoras potenciales. Medir el impacto del cambio organizacional. Asegurar que clientes, usuarios finales, desarrolladores y los otros participantes
14

Contenido

tengan un entendimiento compartido del problema. Derivar los requerimientos del sistema de software, necesarios para dar soporte a los objetivos de la organizacin. Entender como el sistema a ser desarrollado entra dentro de la organizacin. 2. Requerimientos Esta disciplina tiene el propsito de: Establecer y mantener un acuerdo con los clientes y los otros interesados acerca de que debe hacer el sistema. Proveer a los desarrolladores del sistema de un mejor entendimiento de los requerimientos del sistema. Definir los lmites (o delimitar) del sistema. Proveer una base para la planeacin de los contenidos tcnicos de las iteraciones. Proveer una base para la estimacin de costo y tiempo necesarios para desarrollar el sistema. Definir una interfaz de usuario para el sistema, enfocada en las necesidades y objetivos del usuario. 3. Anlisis y Diseo El propsito del Anlisis y Diseo es: Transformar los requerimientos a diseos del sistema. Desarrollar una arquitectura robusta para el sistema. Adaptar el diseo para hacerlo corresponder con el ambiente de implementacin y ajustarla para un desempeo esperado. 4. Implementacin El propsito de la implementacin es: Definir la organizacin del cdigo, en trminos de la implementacin de los subsistemas organizados en capas. Implementar el diseo de elementos en trminos de los elementos (archivos fuente, binarios, ejecutables y otros) Probar los componentes desarrollados como unidades. Integrar los resultados de los implementadores individuales en un sistema
15

Contenido

ejecutable. La disciplina de implementacin limita su alcance a como las clases individuales sern probadas. Las pruebas del sistema son descritas en futuras disciplinas.

5. Pruebas Esta disciplina acta como un proveedor de servicios a las otras disciplinas en muchos aspectos. Pruebas se enfoca principalmente en la evaluacin y aseguramiento de la calidad del producto, desarrollado a travs de las siguientes prcticas: Encontrar fallas de calidad en el software y documentarlas. Recomendar sobre la calidad percibida en el software. Validar y probar las suposiciones hechas durante el diseo y la especificacin de requerimientos de forma concreta. Validar que el software trabaja como fue diseado. Validar que los requerimientos son implementados apropiadamente. 6. Transicin Esta disciplina describe las actividades asociadas con el aseguramiento de la entrega y disponibilidad del producto de software hacia el usuario final. Existe un nfasis en probar el software en el sitio de desarrollo, realizacin de pruebas beta del sistema antes de su entrega final al cliente. 7. Administracin y Configuracin del Cambio Consiste en controlar los cambios y mantener la integridad de los productos que incluye el proyecto. Incluye: Identificar los elementos configurables. Restringir los cambios en los elementos configurables. Auditar los cambios hechos a estos elementos. Definir y mantener las configuraciones de estos elementos. Los mtodos, procesos y herramientas usadas para proveer la administracin y configuracin del cambio pueden ser consideradas como el sistema de administracin de la configuracin.
16

Contenido

8. Administracin de Proyectos El propsito de la Administracin de Proyectos es: Proveer un marco de trabajo para administrar los proyectos intensivos de software. Proveer guas prcticas para la planeacin, soporte, ejecucin y monitoreo de proyectos. Proveer un marco de trabajo para la administracin del riesgo. 9. Ambiente Se enfoca en las actividades necesarias para configurar el proceso al proyecto. Describe las actividades requeridas para desarrollar las lneas guas de apoyo al proyecto. El propsito de las actividades de ambiente es proveer a las organizaciones de desarrollo de software del ambiente necesario (herramientas y procesos) que den soporte al equipo de desarrollo. Otro de los comentarios de esta metodologa, se refiere a que es una de las metodologas pesadas ms conocidas y utilizadas. Metodologa RUP (Rational Unified Process) que divide el desarrollo en 4 fases que definen su ciclo de vida: - Inicio: El objetivo es determinar la visin del proyecto y definir lo que se desea realizar. - Elaboracin: Etapa en la que se determina la arquitectura ptima del proyecto. - Construccin: Se obtiene la capacidad operacional inicial. - Transmisin: Obtener el producto acabado y definido. Filosofa RUP. La metodologa RUP tiene 6 principios clave: - Adaptacin del proceso: El proceso debe adaptarse a las caractersticas de la organizacin para la que se est desarrollando el software. - Balancear prioridades: Debe encontrarse un balance que satisfaga a todos los inversores del proyecto. - Colaboracin entre equipos: Debe haber una comunicacin fluida para coordinar requerimientos, desarrollo, evaluaciones, planes, resultados, etc.,...
17

Contenido

- Demostrar valor iterativamente: Los proyectos se entregan, aunque sea de una forma interna, en etapas iteradas. En cada iteracin se evaluar la calidad y estabilidad del producto y analizar la opinin y sugerencias de los inversores. - Elevar el nivel de abstraccin : Motivar el uso de conceptos reutilizables. - Enfocarse en la calidad: La calidad del producto debe verificarse en cada aspecto de la produccin. Disciplina de desarrollo de RUP. Determina las etapas a realizar durante el proyecto de creacin del software. - Ingeniera o modelado del negocio: Analizar y entender las necesidades del negocio para el cual se est desarrollando el software. - Requisitos: Proveer una base para estimar los costos y tiempo de desarrollo del sistema. - Anlisis y diseo: Trasladar los requisitos analizados anteriormente a un sistema automatizado y desarrollar una arquitectura para el sistema. - Implementacin: Crear software que se ajuste a la arquitectura diseada y que tenga el comportamiento deseado. - Pruebas: Asegurarse de que el comportamiento requerido es correcto y que todo lo solicitado est presente. - Despliegue: Producir distribuciones del producto y distribuirlo a los usuarios. Disciplina de soporte RUP. Determina la documentacin que es necesaria realizar durante el proyecto. Configuracin y administracin del cambio: Guardar todas las versiones del proyecto. Administracin del proyecto: Administrar los horarios y recursos que se deben de emplear. Ambiente: Administrar el ambiente de desarrollo del software. Distribucin: Hacer todo lo necesario para la salida del proyecto. Elementos del RUP. Actividades: Procesos que se han de realizar en cada etapa/iteracin. Trabajadores: Personas involucradas en cada actividad del proyecto. Artefactos: Herramientas empleadas para el desarrollo del proyecto.
18

Contenido

Puede ser un documento, un modelo, un elemento del modelo, etc.,... Por otra parte cabe sealar que Rational Unified Process es una infraestructura flexible de desarrollo de software que proporciona prcticas recomendadas probadas y una arquitectura configurable. Es un Proceso Prctico Las mejores prcticas del Rational Unified Process, (RUP), son un conjunto de procesos web-enabled de ingeniera de software que dan gua para conducir las actividades de desarrollo del equipo. Como una plataforma de procesos que abarca todas las prcticas de la industria, el RUP permite seleccionar fcilmente el conjunto de componentes de proceso que se ajustan a las necesidades especficas del proyecto. Se podrn alcanzar resultados predecibles unificando el equipo con procesos comunes que optimicen la comunicacin y creen un entendimiento comn para todas las tareas, responsabilidades y artefactos. Desde un nico sitio web centralizado de intercambio, el Software Rational, las plataformas, herramientas y expertos de dominios proveen los componentes de proceso necesarios para el xito. Rational Unified Process Unifica al equipo El Rational Unified Process unifica todo el equipo de desarrollo de software y optimiza su comunicacin proveyendo a cada miembro de una aproximacin al desarrollo de software con una base de conocimiento on-line customizable de acuerdo a las necesidades especficas del proyecto. Usando la navegacin online del browser, cada miembro del equipo tiene acceso instantneo a la base de conocimiento y gua de procesos del RUP desde su desktop. La base de conocimiento unifica an ms al equipo identificando y asignando

responsabilidades, artefactos y tareas de forma que cada miembro del equipo comprenda su contribucin al proyecto. Unificando al equipo, se simplifica la comunicacin, asegurando la asignacin de recursos en forma eficiente, la entrega de los artefactos correctos, y el cumplimiento de los tiempos lmite. Entrega del software operativo con confianza El RUP mantiene al equipo enfocado en producir incrementalmente software operativo a tiempo, con las caractersticas requeridas y con la calidad requerida. Las mejores prcticas probadas en la industria, contenidas en el RUP, incorporan
19

Contenido

las lecciones aprendidas de cientos de lderes de la industria y miles de proyectos. Ya no hay necesidad de re-inventar soluciones a desafos de la ingeniera de software bien conocidos. Siguiendo el acercamiento al desarrollo iterativo del RUP, es posible entregar a tiempo y con confianza el software. Control de nuevas herramientas y tecnologas La plataforma del Rational Unified Process permite controlar nuevas herramientas y tecnologas en un nico ambiente a travs de contenido Plug-In customizado, mentores de herramientas y ayuda. Los Plug-Ins tecnolgicos permiten actualizar el proceso de desarrollo y customizarlo a medida que la tecnologa, herramientas y plataformas evolucionan. Para controlar completamente las nuevas tecnologas e incrementar la eficiencia en el uso de las herramientas, RUP provee mentores especficos on-line para las mismas que muestran cmo implementarlas en el nuevo ambiente. Caractersticas y Beneficios No existen dos proyectos de desarrollo de software que sean iguales. Cada uno tiene prioridades, requerimientos, y tecnologas muy diferentes. Sin embargo, en todos los proyectos, se debe minimizar el riesgo, garantizar la predictibilidad de los resultados y entregar software de calidad superior a tiempo. Rational Unified Process, o RUP, es una plataforma flexible de procesos de desarrollo de software que ayuda proveyendo guas consistentes y y personalizadas de procesos para todo el equipo de proyecto. Las mejores prcticas ms probadas de la industria - Son las mejores prcticas de desarrollo adoptadas en cientos proyectos mundialmente y enseadas como parte de la currcula en cientos de universidades, la metodologa RUP se convirti rpidamente en el estndar de facto para el proceso de desarrollo en la industria de software. Proceso hecho prctico - Diferente que otras metodologas comerciales, la plataforma RUP hace que el proceso sea prctico con bases de conocimiento y guas para ayudar en el despegue de la planificacin del proyecto, integrar rpidamente a los miembros del equipo y poner en accin el proceso personalizado.
20

Contenido

Se adapta a las necesidades de los proyectos - Solo la plataforma RUP proporciona un framework de proceso configurable que permite seleccionar e implantar los componentes especficos de proceso necesarios para proporcionar un proceso consistente y customizado para cada equipo y proyecto. Una de las mejores prcticas centrales de RUP es la nocin de desarrollar iterativamente. Rational Unified Process organiza los proyectos en trminos de disciplinas y fases, consistiendo cada una en una o ms iteraciones. Con esta aproximacin iterativa, el nfasis de cada workflow variar a travs del ciclo de vida. La aproximacin iterativa ayuda a mitigar los riesgos en forma temprana y continua, con un progreso demostrable y frecuentes releases ejecutables. Sistemas Operativos y Plataformas de Hardware Apropiadas HP-UX Linux Sun Solaris Windows 2000 Windows NT Windows XP Conclusiones Es un proceso de ingeniera de softwarey un producto de softwarepara producir software de calidad, flexible, y en plazos y presupuestos predecibles incorpora las mejores prcticas de desarrollo de software validadas

comercialmente: p.ej., desarrollo incremental guiado por casos de uso y centrado en la arquitectura ayuda a alcanzar el Nivel de Madurez 2 del CMM es usado exitosamente en diversos escenarios puede implementarse paulatinamente en una organizacin

21

Contenido MAPA CONCEPTUAL

MODELO CASCADA

HISTORIA

Fases del modelo de cascada

Modelos Modificados de Cascada

En 1970 Royce propuso lo que actualmente se conoce como el modelo de cascada como un concepto inicial, un modelo que segn l era defectuoso.

1. Anlisis de requisitos 2. Diseo del sistema 3. Diseo del programa 4. Codificacin 5. Pruebas 6. Implantacin 7. Mantenimiento

La expresin "modelo de cascada" rpidamente lleg a referirse no a la final de Royce, el diseo interactivo, sino ms bien a su modelo puramente un orden secuencial.

El modelo Sashimi Fue creado por Peter Degrace . A veces es referido como "el modelo de cascada con retroalimentacin". Modelo en Cascada Bennington 1956: El ms conocido, esta basado en el ciclo convencional de una ingeniera

Ventajas y desventajas

Ventajas Permite la departamentalizacin y control de gestin. El horario se establece con los plazos adecuados Entrega el proyecto a tiempo. Es sencilla y facilita la gestin de proyectos.

Desventajas Poco tiempo para corregir fallas Depuracin complicada El cliente podra detectar un error El proceso es lento y pesado

22

Contenido

BIBLIOGRAFIA

http://es.wikipedia.org/wiki/Proceso_Unificado_de_Rational http://www.rational.com.ar/herramientas/rup.html http://www.slideshare.net/dersteppenwolf/la-ingeniera-de-software-y-rup/download http://yaqui.mxl.uabc.mx/~molguin/as/RUP.htm http://users.dsic.upv.es/asignaturas/facultad/lsi/ejemplorup/ http://www.slideshare.net/msch/utilizando-metodologia-rup-parte1/download

23