2.2.2 Proceso Unificado (UP)

2.2.2 Proceso Unificado de Desarrollo de Software (UP) La metodología de UP es un método iterativo de diseño de software

Views 199 Downloads 5 File size 90KB

Report DMCA / Copyright

DOWNLOAD FILE

Recommend stories

Citation preview

2.2.2 Proceso Unificado de Desarrollo de Software (UP) La metodología de UP es un método iterativo de diseño de software que describe cómo desarrollar software de forma eficaz, utilizando técnicas probadas en la industria. El Proceso Unificado de Desarrollo de 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, Enfocado en el riesgo, y Por ser iterativo e incremental.

El Proceso Unificado no es simplemente un proceso, sino un marco de trabajo extensible que puede ser adaptado a organizaciones o proyectos específicos. El nombre Proceso Unificado se usa para describir el proceso genérico que incluye aquellos elementos que son comunes a la mayoría de los refinamientos existentes. Es una metodología orientada a conducir el proceso de desarrollo de software en sus aspectos técnicos; los flujos y productos de trabajo de UP no incluyen la administración del proyecto. UP es una versiónlibre y abierta del modelo propuesto por Jacobson, Booch y Rumbaugh UP divide el trabajo de desarrollo de software en cuatro fases: inicio, elaboración, construcción y transición, las cuales se describen a continuación. 

Fase de Inicio en UP

En esta fase corresponde definir el negocio. Es la etapa donde se define la factibilidad del proyecto a realizar, se representa el modelo de negocio, visión y metas del proyecto, se identifican actores, conceptos de dominio y deseos de usuario. Adicionalmente se complementa con la definición de la arquitectura preliminar, y estimaciones (imprecisas, preliminares) de plazos y costos. También se define la viabilidad del proyecto. 

Fase de Elaboración en UP

En la fase de elaboración se obtiene la visión refinada del proyecto a realizar, la implementación iterativa del núcleo central de la aplicación, la resolución de los riesgos más altos, la identificación de nuevos requisitos y nuevos alcances, y estimaciones más ajustadas. A esta

altura existe la posibilidad de detener el proyecto por complejidad técnica. 

Fase de Construcción en UP

La fase de construcción es la implementación iterativa del resto de los requisitos de menor riesgo y elementos más sencillos. Es la evolución hasta convertirse en un producto listo, incluyendo todos los requisitos (100%), para entregarse al Cliente. Al final de esta fase el sistema contiene todos los casos de uso que el cliente y la dirección del proyecto han acordado. La mayoría de los casos de uso que no se desarrollaron en la fase anterior se desarrollan en iteraciones, en grupos de requisitos o casos de uso durante esta fase.



Fase de Transición en UP

Es el periodo donde el producto es completamente entregado al cliente para ser testeado y desplegado (instalado).

Organización de Disciplinas según UP El cuadro siguiente representa cada una de las disciplinas utilizadas en el proceso de desarrollo de software y su nivel de participación en cada una de las fases definidas de UP

Las disciplinas identificadas son modelado de negocios, requisitos, análisis, diseño, implementación y pruebas, como también se identifican las disciplinas de apoyo, tales como: configuración y manejo de proyectos. Todas estas disciplinas son representadas con su correspondiente esfuerzo estimado para cada una de las fases definidas por UP. Algunas características a enunciar según UP son: 1. Los proyectos se organización en una serie de mini-proyectos cortos de duración (2 a 6 semanas), llamados iteraciones, que incluyen un conjunto reducido de requerimientos a implementar. 2. El resultado de cada iteración es un sistema que puede ser probado, integrado y ejecutado. La salida es un subconjunto con calidad de producción final. 3. Rápida retroalimentación y asimilación de los cambios, posibilitada por el tamaño limitado de lo realizado en cada iteración. 4. Se abordan, resuelven y prueban primeramente las decisiones de diseño críticas o de alto riesgo. Ventajas: UP es un buen punto de partida por tratarse de una metodología de desarrollo de software orientada a conducir el proceso de desarrollo de forma eficaz basado en un conjunto de buenas prácticas probadas en la industria del software y muchas de las cuales son conocidas dentro de FIDCOM, disminuyendo el costo de adopción. UP es una versión libre y abierta del modelo propuesto por Jacobson, Booch y Rumbaugh. En otras palabras, es perfectamente posible definir el proceso de ingeniería de una organización sobre la base del UP, sin tener que pagar derechos. Desventajas: Por tratarse de un meta modelo, un proceso genérico que incluye aquellos elementos que son comunes a la mayoría de los refinamientos existentes, por tratarse de un marco de trabajo extensible de metodología de desarrollo de software que debe ser adaptado a organizaciones o proyectos específicos no es apropiado utilizar UP tal cual. UP es una metodología orientada a conducir el proceso de desarrollo de software en sus aspectos técnicos. Los flujos y productos de trabajo de UP no incluyen la administración del proyecto. Por lo tanto, se requiere también que los proyectos se encuentren en un dominio acotado y se requiere flexibilidad, la cual se obtiene con el tiempo.

Ejemplo:

Introducción El objetivo de esta página web es mostrar un ejemplo de desarrollo de software basado en la metodología de Unified Process (UP). El proyecto es el desarrollo de un sistema para la gestión de artículos deportivos de una empresa del sector de ventas de deportes a clientes tanto a mayoristas como a minoristas. Se incluye hasta la segunda iteración de la fase de construcción, según la división establecida en el documento Plan de Desarrollo Software. Por motivos de privacidad no se pueden publicar los datos de la entidad para la que se diseñó el software. Contexto de Desarrollo Este proyecto ha sido desarrollado en el contexto de la asignatura de quinto curso de Ingeniería Informática, Laboratorio de Sistemas de Información (http://www.dsic.upv.es/asignaturas/facultad/lsi/), de la Facultad de Informática (http://www.fiv.upv.es) de la Universidad Politécnica de Valencia bajo la supervisión del profesor Patricio Orlando Letelier Torres (http://www.dsic.upv.es/~letelier). El equipo de desarrollo que ha llevado a cabo este proyecto es el siguiente:

• Jefe del Proyecto: César López Rodríguez ([email protected]) • Arquitecto de Software: José Luis Martínez Herrero ([email protected]) • Analista/Desarrollador: Germán Mira Rico ([email protected]) • Analista/Desarrollador: Miguel Antonio Mascilla Guzmán ([email protected]) • Programador: José Antonio Mocholí Agües ([email protected]) • Programador: Eduardo Bueno Medina ([email protected]) • Tester: Rosa María Ogallar Verjillos ([email protected]) Proyecto

La aplicación se desarrolló bajo el lenguaje de programación Visual Basic 6.0, teniendo que soportar tanto acceso a una base de datos Oracle como a una base de datos Access, dependiendo de la selección del usuario en el arranque del programa. Cabe citar que el equipo de desarrollo estaba limitado a unos conocimientos medios del lenguaje de programación, por lo que las soluciones adoptadas pueden no ser completamente eficientes. En el apartado de Gestión del Proyecto se muestran las planificaciones temporales de desarrollo del proyecto en su fase de inicio y de elaboración, así como el diario de ejecución del proyecto, junto con el diario de construcción de la aplicación y cumplimiento de los plazos estimados. En el apartado de Modelado del Negocio se encuentran los artefactos utilizados de la metodología UP para definir un modelo del negocio, modelos de objetos del negocio y el modelo del dominio. En el apartado Requisitos se muestran todos los enlaces a los documentos en formato word y pdf consultables desde el navegador. Dicha documentación consta de los artefactos definidos según la metodología UP, es decir, el documento plan de desarrollo software, el documento visión, el documento glosario y las especificaciones tanto de los casos de uso como de los casos de pruebas relacionados con estos. También se recoge la gestión del proyecto con la herramienta de Rational, el Requisite Pro, con la que además de llevar el control de toda la documentación, se puede seguir la trazabilidad entre requerimientos de todo el proyecto. En este apartado se muestran las matrices de atributos de todos los requerimientos así como la navegabilidad entre ellos. Por añadidura también se muestran los casos de uso de cada subsistema generado con la herramienta Rational Rose, y desde los cuales también se puede consultar la especificación del caso de uso. En el apartado Análisis/Diseño se muestran tanto el modelo de análisis/diseño (diagrama de clases) como el modelo de datos (modelo entidad - relación), desde los cuales se puede consultar la especificación de los métodos de clase más relevantes o las especificaciones de atributos. En el apartado Implementación se muestran los prototipos de interfaces de usuario de la aplicación, tanto para el sistema de gestión de ventas como para el sistema de gestión de almacén. También en este apartado se muestran los diagramas de componentes y diagrama de despliegue que modela las aplicaciones incorporadas en el proyecto hasta la segunda iteración de la fase de construcción (según la definición de

fases e iteraciones de la metodología RUP) y desde los cuales, a través de los componentes se puede consultar el código fuente de cada uno. Por último, en el apartado Pruebas se encuentran los enlaces a los documentos word de especificación de casos de pruebas funcionales consultables mediante el navegador o bien descargables mediante un enlace en formato zip. Se muestran únicamente los casos de pruebas generados para los casos de uso incorporados hasta la segunda iteración de la fase de construcción.

http://pnfiingenieriadesoftwaregrupocuatro.blogspot.mx/2012/07/proces o-unificado-proceso-unificado-de.html https://mdjesus.wordpress.com/2010/05/19/84/ http://users.dsic.upv.es/asignaturas/facultad/lsi/ejemplorup/