proceso unificado n.teamberry

5/13/2018 Proceso Unificado N.Teamberry - slidepdf.com

http://slidepdf.com/reader/full/proceso-unificado-nteamberry 1/13

· Álvaro Yuste Torregrosa ·· Carlos Sanchís Server ·

· Carlos Meca López ·· Javier Sánchez Riquelme ·

Universidad de Alicante – Ingeniería Multimedia

EL PROCESO UNIFICADOEL PROCESO UNIFICADO



El Proceso Unificado

0. Introducción:

El Proceso Unificado del Software o UP es un conjunto de metodologías de

desarrollo de software caracterizado por su flexibilidad, es decir, que no cuenta conpasos establecidos y por tanto es capaz de especializarse según el problema quedeseemos resolver, de ahí su popularidad.

Los orígenes del Proceso Unificado se remontan a 1988, cuando la empresaObjectory AB desarrolla un software como herramienta de diseño orientado aobjetos. Objectory AB es comprada en 1995 por Rational Software, evolucionandodicho software y popularizándolo. Esta herramienta proporciona el lenguaje detrabajo en equipo, y mezclado con un lenguaje donde los procesos de desarrolloson el núcleo de la evolución del desarrollo de los productos, forman el ProcesoUnificado.

A día de hoy el UP es la metodología más utilizada para el desarrollo de software, ytambién en la que más variaciones o refinamientos podemos encontrar en funciónde las necesidades del producto, siendo el Proceso Unificado Racional el másconocido.

1. Características del Proceso Unificado:

Una de las características más importantes del proceso unificado es el llamado

desarrollo iterativo o incremental. Se basa en dividir el proyecto en variasrepeticiones homólogas en las fases, para conseguir un avance progresivo yescalonado que mejorará y avanzará el producto en cada interacción. Es evidenteque si a la hora de desarrollar un producto únicamente necesitamos la definición deuna solo iteración, podremos concentrar nuestros esfuerzos y simplificar de manerasignificativa la planificación y el seguimiento de las tareas a realizar.

Como veremos posteriormente, el proceso unificado se compone de cuatro fasesdenominadas Inicio, Elaboración, Construcción y Transición, y es dentro de cada unade estas donde se realizan las dichas insistencias (aunque la de inicio únicamentese itera en procesos considerablemente grandes o de una profundidad especial). En

todo caso, cada iteración se lleva a cabo en un periodo de tiempo limitadonormalmente comprendido entre dos y seis semanas, para conservar la agilidad yfrescura en el avance.

http://www.enterpriseunifiedprocess.com/essays/history.html

http://www.enterpriseunifiedprocess.com/essays/history.html



A su vez, cada uno de los incremento dentro de las fases posee sus propiasdisciplinas, que también analizaremos en profundidad más adelante, y que son elAnálisis de requisitos, el Diseño, la Implementación y a Prueba; las cuales vanrepresentando un mayor o menor peso respecto del resto según avanza el proyectorecorriendo las diferentes etapas de su elaboración. Así, para desarrollar el producto

de una iteración se elige un subconjunto de los requisitos globales, se diseñan,implementan, y prueban. Todo ello para originar un resultado susceptible a ser integrado y ejecutado con calidad de producto final, y que se proporcionará al clientecomo muestra del trabajo realizado hasta el momento.

Independientemente, el verdadero potencial de este tipo de desarrollo reside en laposibilidad de ofrecer de manera periódica al cliente una “muestra” del producto, unaaplicación con prestaciones parciales, que se completarán con nuevasfuncionalidades en sucesivas fases. El cliente puede ver pasos del desarrollo, conalgunos tributos limitados, mientras se desarrollan las otras. Así en este tipo deprogreso se llevan a cabo dos sistemas que funcionan en paralelo:

oSistema Operacional: Ya en posesión y uso del cliente. Es la implementación

parcial que se entrega como muestra, en una fase intermedia del desarrolloglobal, para que el demandante del software se haga una idea de cual estásiendo el avance llevado a cabo por el desarrollador. Puede basarse en unamejora o modificación de versiones anteriores, o una nueva versión con partesde las versiones antiguas.

oSistema en Desarrollo: El producto que se está desarrollando con el fin de

mejorar el sistema operacional, y suministrárselo al cliente para sustituir a esteen la futura iteración del desarrollo. Es sobre el que verdaderamente se trabaja yse aplican las disciplinas nombradas, dado que, como hemos dicho, el otrosistema ya se encuentra en manos del cliente.

Otra de las ventajas que ofrece el desarrollo iterativo es la fácil retroalimentación (ya

que como hemos visto, el subproyecto de una etapa se nutre la mayoría de vecesdel resultado des subproyecto anterior). A su vez también garantiza una correctaasimilación de cambio ya que las modificaciones o retrasos pueden tratarse en la



siguiente iteración a la actual, sin provocar cambios en la fecha de entrega delproducto y agilizando el proceso. En el supuesto de que el progreso fuerasecuencial, podría ser desastroso tener que modificar el plan en mitad del desarrollo.

Para monitorizar los requisitos funcionales de la programación del software ydescribir el contenido y el conunto de tareas de cada iteración, se utilizan los casos

de uso, de manera que cada incremento toma un conjunto de ellos. Así, la definiciónde un caso de uso se puede perfilar, en el contexto de la ingeniería software, comouna secuencia de interacciones entre las personas o entidades y el sistema en elque participan, como respuesta a un conjunto de eventos. Son muy útiles en el casode software desarrollado con programación orientada a objetos, que es dode seoriginaron. Además se suelen representar en diagramas deonde se describe lacomunicación entre los consumidores y el producto. Con ellos, en la extracción derequerimientos, se consigue centrar el análisis en las necesidades del usuario ydejar de guiar la evolución de este en los requisitos tecnológicos.

2. Fases del Proceso Unificado:

Un proyecto basado en UP tiene 4 fases (inicio, elaboración, construcción,transición) que iteran sobre 5 flujos de trabajo y en las que se distribuyen todo elproceso de desarrollo del sistema desde que se acuerda el proyecto hasta que seentrega:

- Requisitos:Encontrar cual es la siguiente acción que el sistema debe implementar.

- Análisis:

Conseguir un conocimiento más preciso acerca de los requisitos del sistema.

- Diseño:Comprender los requisitos no funcionales y adaptar los requisitos funcionales para quepuedanser implementados.

- Implementación:Se implementan las clases y se realizan pruebas individuales a cada una para lograr una mayor eficiencia y eficacia. Se distribuyen las funciones asignándolas a nodos.

- Prueba:Se crean y ejecutan pruebas que permitan mostrar debilidades y errores en el sistema.

Además, después de cada etapa deberán de actualizarse documentos y realizar unanálisis sobre los costes, esfuerzos y beneficios de la siguiente etapa además deanalizar el trabajo de la etapa anterior, además de seleccionar de las personas delequipo primordial a los más capacitados para desarrollar las actividades de la actualfase.

Las fases del Proceso Unificado son las siguientes:



Inicio:

• En este momento se produce la comunicación con el cliente y se dejan claras

las necesidades de este, junto a los compromisos del negocio y los acuerdostanto económicos como de fechas.

• Se buscan soluciones al problema y se crea una idea de los requisitos tendrá el

producto.-Se establecerá de manera básica cuál será el esfuerzo requeridopara realizar el proyecto.

• Llevar a cabo un subproceso de planificación que se encargue de asimilar

información y buscar a la gente que está capacitada para llevar a cabo elproyecto y encontrar algún hueco que rellenar en caso de ser necesario.

• Deben de revisarse los equipos y el software para observar si cumple los

requisitos necesarios además de fuentes de información variadas sobre el

contexto en el que se encontrará el sistema.

• Obtener software de ventas, programación o que complete las necesidades de

otras áreas de la empresa.

• Analizar el contexto en el que se ejecutará la aplicación basándose en la

arquitectura de los equipos que la ejecutarán y sus recursos.

• Esbozar una serie de bocetos de diseño para el proyecto, junto con esquemas

de como irán las cosas.

• Tras analizar el proyecto se creará una lista de riegos críticos y no,

comprendiendo los niveles de prioridad, en caso de no hacerse seguramentelos riesgos aparecerán antes o después y es una manera de solventarlos demanera más eficaz.

• Los riesgos pueden estar relacionados con varios factores y hay que tenerlos

en cuenta todos: arquitectura, tecnología usada, requisitos del sistema y otrosrequisitos no funcionales como la seguridad de los datos o la fiabilidad.

•En caso de solicitarse incluirá un pequeño proyecto que dará lugar a unprototipo que ayudará a la empresa a mostrar al cliente que el sistema podrásuplir sus necesidades.

Elaboración:

• En esta fase el núcleo del sistema se desarrolla de manera iterativa.

Comenzando con cada problema a resolver.

• Se establecen las medidas de calidad y los factores que intervienen: tiempos de

ejecución, seguridad, fiabilidad…

• Se crea un informe sobre los datos detallados de las arquitecturas sobre las que



ejecutar y del sistema final.

• Se desarrollan prototipos de las interfaces del sistema.

• Se estructuran los modelos de los casos de uso de la aplicación.

• Hay que realizar un análisis de la arquitectura candidata, los recursoscompartidos y de las clases, los módulos y los paquetes del sistema.

• Implementar la mayor parte de los nodos y módulos del sistema.

• La mayoría de los requerimientos son identificados y, en su medida,

solucionados.

• Los problemas que hayan ido apareciendo deberán de redirigirse y se

resolverse en orden de prioridad con respecto a la funcionalidad.

• En esta fase normalmente se realiza la mayor parte del esfuerzo.

• Se realizan unas nuevas estimaciones más ajustadas junto al establecimiento

de nuevos requisitos.

Construcción:

• Se desarrollan el resto de elementos de menor urgencia, riesgo y necesidad del

sistema.

• Se realiza un equilibrio de costes de desarrollo intentando dejarlo todo abierto yno cerrado para que en caso de error no hay que repetir todo el trabajo de unaparte.

• Alcanzar niveles de calidad y versiones medianamente útiles y estables del

sistema (alpha, beta…) de manera rápida y eficaz.

• Conseguir unas condiciones de aceptación buenas.

• En esta fase se crean los manuales de usuario, la descripción de la versión

actual y se evalúan los posibles riesgos para el software y los usuarios.

Transición:

• Beta-testing con ayuda de los usuarios. (se prueba la aplicación en busca de

posibles errores a la hora del uso).

• Se comprueba el nivel de autosuficiencia que alcanzan los usuarios a la hora de

usar la aplicación.

• Debe de realizarse una versión final del sistema de la manera más económica y

fiable posible, atendiendo a toda la información adquirida en las fases anterioresy en las pruebas con los usuarios, solucionando las dificultades presentadas.



• Comprobar que el producto cumple las especificaciones establecidas en la fase

de inicio y que no presenta errores en su uso, en caso contrario nueva iteración.

• Estimar si el consumo por parte de la aplicación es el esperado.

• Despliegue del producto (entrega, instalación y configuración de este).

3. Disciplinas del Proceso Unificado:

Las disciplinas son un conjunto de actividades relacionadas (flujos de trabajo)

vinculadas a un área específica dentro del proyecto total. Se llevan a cabo en cadaiteración, pero no se tienen porque realizar todas en una misma iteración. Por ejemplo, en esta imagen se van realizando todas conforme se suceden lasiteraciones (además en este diagrama se observa el trabajo dedicado a cadadisciplina en cada iteración)

Las más importantes son:

Requisitos: Flujo de trabajo fundamental cuyo propósito es orientar aldesarrollador hacia el sistema correcto. Esto se lleva a cabo mediante ladescripción de los requisitos del sistema de forma tal que se pueda llegar a unacuerdo entre el cliente (incluyendo los usuarios) y los desarrolladores del sistema,acerca de lo que el sistema debe hacer y lo que no.



Análisis: Flujo de trabajo fundamental cuyo propósito principal es analizar losrequisitos descritos en la captura de requisitos, mediante su refinamiento yestructuración. El objetivo de esto es:

• Entender de una manera mas precisa de los requisitos

• Obtener una descripción de los requisitos que sea fácil de mantener y que

nos ayude a dar estructura al sistema en su conjunto incluyendo su

arquitectura.

Diseño: Flujo de trabajo fundamental cuyo propósito principal es la de formular modelos que se centran en los requisitos no funcionales y el dominio de la solucióny que prepara para la implementación y pruebas del sistema.

Implementación: Flujo de trabajo fundamental cuyo propósito esencial esimplementar el sistema en términos de componentes, es decir código fuenteguiones, ficheros binarios, ejecutables, etc.

Prueba: Flujo de trabajo fundamental cuyo propósito esencial es comprobar el

resultado de la implementación mediante las pruebas de cada construcción,incluyendo tanto construcciones internas como intermedias, así como las versionesfinales del sistema que van a ser entregadas a terceras personas.

Conclusión: Las disciplinas de manera reducida son: un conjunto de actividadesrelacionadas con un área especifica, que todas ellas tienen en común, dentro de unproyecto.

Las disciplinas mas importantes se pueden resumir de la siguiente manera:

•

Capturar, definir y validar los casos de uso (Requisitos)• Realizar los casos de uso (Análisis, diseño e implementación)

• Verificar que se satisfacen los casos de uso (Pruebas)

4. Artefactos del Proceso Unificado

En el Proceso Unificado, un artefacto es tanto un producto final como intermedioque es producido, modificado o usado por un proceso durante el proyecto. Losartefactos se usan para captar y transportar información del proyecto. Son,básicamente, los elementos que se van obteniendo y usando hasta obtener elproducto final.

Los distintos tipos de artefactos son los documentos, las bases de datos (u otrasfuentes de información tabulada), los códigos fuente y ejecutables, el modelo y elelemento modelo. Estos dos últimos tienen una serie de información que puede ser extraída llamada informe, que representa un artefacto o una serie de artefactos,que a su vez tienen guías que los describen con detalle.

Los artefactos se organizan en secciones según sus disciplinas. En caso de que unartefacto tenga más de una será asignado a la misma que lo produjo en unprincipio.

Los artefactos del Proceso Unificado y su relación entre ellos.



Pasamos a enumerar y explicar los grupos de artefactos:

• Modelo Empresarial, que engloba a los artefactos que toman y presentan el

contexto empresarial del sistema. Son la entrada y referencia para losrequerimientos del sistema.

• Requerimientos, toma y presenta la información usada en la definición de las

capacidades requeridas del sistema.

• Análisis y Diseño, que contienen información relacionada con la solución a los

problemas indicados en el conjunto de Requerimientos.

• Implementación son aquellos que desarrollan la solución proporcionada por la

categoría de Análisis y Diseño.

• Pruebas, los que evalúan los resultados de las actividades anteriores.

• Artefactos de Despliegue son los relacionados con la captura y presentación

de la información relacionada con la transición del sistema presentada en elgrupo de Implementación dentro del entorno de producción.

• Gestión de Proyecto es el grupo toma los artefactos asociados al proyecto y la

planificación y ejecución del proceso.



• Gestión de Configuración y Cambios se encarga de tomar y presentar

información relacionada con la disciplina de configuración y cambios delproyecto.

• Grupo Ambiental de Artefactos presenta los artefactos que se utilizan como

dirección en el desarrollo del sistema para asegurar el estado coherente detodos los artefactos.

Normalmente los artefactos no son documentos de texto, a diferencia de muchosde los procesos donde la documentación suele ser incluso en papel.

Obsérvese que “artefacto” es el término usado en el RUP para describir lo quedenotan otros procesos usando términos tales como producto del trabajo, unidadde trabajo, y así sucesivamente. En RUP, los productos a entregar se consideransolamente ser el subconjunto de todos los artefactos que terminen para arriba laentrega en las manos de los clientes y de los usuarios finales, generalmente como

parte de una entrega.

5. Especializaciones del Proceso Unificado:

RUP (Rational Unified Process) :Es el proceso unificado que utiliza la corporación Rational Software, unadivisión de IBM originada en 2003. Realmente es lo mismo que el procesounificado común (UP) la única diferencia es el nombre que es distinto parano violar los derechos de Rational Software.

AUP (Agile Unified Process):Basándose en técnicas aún válidas en RUP el AUP responde a una versiónsimplificada de este. Describe un enfoque de desarrollo de software mássimple y fácil de entender que en el RUP.Su base se centra en desarrollar cada iteración del ciclo del proceso dedesarrollo originando un software estable entregable, que será entregado alos clientes para obtener su opinión y el cual se someterá a otro ciclo de laiteración y así hasta que el proyecto esté acabado.Al usar menos tiempo en la fase de análisis y establecimiento de losrequisitos lo que se hace es aprovechar ese tiempo en otras fases como laconstrucción, traslación y sus pruebas.

Está pensado para equipos pequeños de unos 10 desarrolladores, ya que sedemuestra que a más gente en el equipo más parece fallar esteprocedimiento.



Open UP (Open Unified Process):Es un Framework de procesos de desarrollo de software de código abierto.Se basa en el RUP creado por IBM, pero no coincide en todos los puntos.Está pensado para pequeños equipos de desarrollo que valoran losbeneficios de la colaboración y de los involucrados con el resultado delproyecto que prefieren olvidarse de formalidades innecesarias.Provee de un simple conjunto de contenidos, fundamentalmenterelacionados con orientación, puestos de trabajo, roles y tareas. Quesimplifican el reparto de los esfuerzos.El Open UP se basa en cuatro principios interrelacionados:

- Colaboración para unificar intereses y compartir conocimientos.

-Equilibrio de prioridades competentes con el fin de maximizar el valor de los involucrados con el desarrollo del proyecto.

- Enfoque de la articulación de la arquitectura.- Desarrollo continuo para obtener realimentación y, de esta manera,

realizar las mejoras necesarias.Al articular la arquitectura se produce una mejora de la colaboración técnica,reducir el riesgo y minimizar los sobresfuerzos durante el desarrollo.OpenUP desarrolla un ciclo de vida interactivo que reduce el riesgo a tiempoy permite mostrar resultados al cliente durante el curso del proyecto.Forma parte del Eclipse Process Framework desarrollado por EclipseFoundation. Su forma más simple y ligera es el Open UP/Basic tambiénllamado Basic Unified Process o BUP donado por IBM.



EssUP (Essential Unified Process):Creado por Ivar Jacobson Solutions es una colección de practicas que juntas

forman un conocimiento esencial del ciclo de vida del proceso de desarrollode software.Integra satisfactoriamente principios del proceso unificado, ágil y campos demadurez de procesos, aprovechando sus diferentes propiedades ycapacidades como la estructura, la agilidad y la mejora de los procesos.Se basa en diferencias los problemas de manera más simple haciendo másfácil la tarea de repartir y adaptar el proyecto ajustándolo a las prioridadestemporales y a las necesidades de la empresa.Según el experto de desarrollo ágil de software Dave Thomas EssUPprovee de una nueva forma de aproximarse a la mejora del desarrollo desoftware. Es mucho más simple y mucho más flexible y extensible que las

anteriores definiciones del UP. Se presenta como ligero y amigablehaciéndose fácil de aprender.Según fuentes varias parece ser que IBM, Microsoft Visual y Eclipse loaceptarán.



6. Bibliografía:

http://www.utim.edu.mx/~pmendoza/ftp/rup.pdf

http://en.wikipedia.org/wiki/Unified_Process

http://iie.fing.edu.uy/ense/asign/desasoft/Teorico2/ProcesoUnificado.pdf

http://es.wikipedia.org/wiki/Proceso_Unificado

http://www.rodolfoquispe.org/blog/que-es-el-proceso-unificado-de-desarrollo-de-

software.php

http://www.slideshare.net/Sofylutqm/el-proceso-unificado-3943047

http://audiemangt.blogspot.com/2010/05/metodologia-agil-proceso-unificado-de.html

http://www.ambysoft.com/unifiedprocess/agileUP.html

http://www.info-ab.uclm.es/asignaturas/42541/pdf/m1tema4.pdf http://ccollins.wordpress.com/2008/06/11/unified-process-vs-agile-processes/

http://cbasqa.wordpress.com/2008/09/02/proceso-de-desarrollo-openu

https://sites.google.com/site/ingsoportelogico/home/essential-unified-process-essup

http://students.mimuw.edu.pl/~zbyszek/posi/ibm/RUP_Eval/manuals/intro/kc_artifact.htm





http://www.rodolfoquispe.org/blog/que-es-el-proceso-unificado-de-desarrollo-de-software.php





http://www.info-ab.uclm.es/asignaturas/42541/pdf/m1tema4.pdf

http://ccollins.wordpress.com/2008/06/11/unified-process-vs-agile-processes/













http://www.info-ab.uclm.es/asignaturas/42541/pdf/m1tema4.pdf

http://ccollins.wordpress.com/2008/06/11/unified-process-vs-agile-processes/




proceso unificado n.teamberry

Documents