Proceso unificado

  • 7,127 views
Uploaded on

 

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
7,127
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
220
Comments
1
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. INTRODUCCIÓN En este tema se describe a groso modo el proceso unificado, indicando sus características generales. Por otra pare, en el de este tema, y, en general, en el contexto del proceso de desarrollo de un sistema informático, se entiende por proceso “el conjunto de pasos ordenados que se realizan para alcanzar un objetivo”. El Proceso Unificado (PU) puede verse como una metodología adaptable. Esto quiere decir que se puede modificar para adaptarlo al sistema concreto que se va a desarrollar en cada momento. Por otra parte se puede decir que el PU es una técnica para elaborar modelos1 que se adapta especialmente a UML. Su objetivo es producir un software de calidad. Por definición, PU utiliza buenas prácticas de desarrollo, siendo adaptable a un amplio rango de aplicaciones y sistemas. Este proceso no sólo considera aspectos de desarrollo de un sistema, sino también los de gestión del mismo.
  • 2. PROCESO UNIFICADO El Proceso Unificado es un proceso de desarrollo de software. Un proceso de desarrollo de software es un conjunto de actividades necesarias para transformar los requerimientos del usuario en un sistema de software. 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 más conocido y documentado del Proceso Unificado es el Proceso Unificado de Rational o simplemente RUP. El Proceso Unificado no es simplemente un proceso, sino un marco de trabajo extensible que puede ser adaptado a organizaciones o proyectos específicos. De la misma forma, el Proceso Unificado de Rational, también 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. Características generales del Proceso Unificado - Soporta técnicas orientadas a objeto, por lo que se basa en los conceptos de clase y objeto y las relaciones entre ellos, usando UML como notación común. - Es una metodología que sigue un proceso iterativo e incremental. Propone una descomposición incremental del problema a través de refinamientos sucesivos y una producción incremental de la solución, a través de la realización de varios ciclos. Esta filosofía es lógica cuando se aplica a sistemas grandes ya que “no se puede abarcar todo a la vez”. - El PU (figura 1) tiene 4 fases o incrementos y en cada uno se consideran distintos flujos de trabajo (workflow) o modelos que suponen mayor o menor número de horas de trabajo dependiendo de la fase incremental en la que se encuentre el desarrollo. Cada incremento consta de todos los pasos de un ciclo de vida completo, que se repiten (iteración) hasta obtener el desarrollo exacto del sistema. Para ello se hacen diagramas cada vez más precisos: el proceso es repetitivo – iterativo- y cada vez se amplía y detalla más –incremental. En el apartado 2 se hace un estudio más detallado del ciclo de vida iterativo e incremental. - El PU está dirigido por el riesgo. Esta es una de las características fundamentales del este modelo, y propone identificar, afrontar y resolver los elementos de riesgo lo más pronto posible. En etapas iniciales se desarrollan las funcionalidades con mayor riesgo y las de mayor complejidad. De este modo se mejoran las posibilidades de éxito del proyecto. - Se utilizan modelos gráficos de representación más que documentación, en particular se usan diagramas UML que son representaciones expresivas y pueden aplicarse durante todo el desarrollo. - El PU está centrado en la arquitectura software. La arquitectura del software para el sistema en desarrollo se define al principio y guía su desarrollo. Propone la definición de una arquitectura robusta, lo que facilita el desarrollo del sistema en paralelo, aumentando las posibilidades de reutilización de componentes y el mantenimiento del sistema. El diseño arquitectónico aporta una base sólida sobre la que planificar y gestionar el desarrollo software basado en componentes. Al basarse en la definición de una arquitectura clara y sencilla, el PU sirve de marco común para toda una familia de procesos y que puede acomodarse a distintas situaciones. Para ello, el PU da las guías para configurar el proceso de modo que se adapte a cada situación. - EL PU está dirigido por los casos de uso. Esto es así porque el PU pone gran énfasis en la construcción de sistemas basados en la comprensión de cómo se va a utilizar ese sistema. Así, los casos de uso y los escenarios se usan para guiar el flujo de procesos, desde la definición de los requisitos hasta las pruebas. - El PU es un proceso adaptable a los distintos tipos de desarrollo y se puede configurar dependiendo de las necesidades de cada proyecto (desde los más sencillos a los más complejos). - Control continuo de la calidad. El PU propone llevar un adecuado control de calidad y una adecuada gestión de riesgos. Ambos conceptos están incluidos en el propio proceso, formando parte de sus actividades. - La filosofía del Proceso Unificado es empezar a trabajar en el desarrollo con un conocimiento relativo del problema, a partir de él se hacen los primeros diagramas. A medida que se va conociendo más el problema, los diagramas se hacen más precisos (en cada iteración) para ampliarlos después (incremento). El proceso se repite hasta asegurarse que los diagramas realizados son una expresión exacta del sistema de información a desarrollar.
  • 3. FASES DEL PROCESO UNIFICADO FASE 1. INICIO. El objetivo de esta fase es determinar si merece la pena desarrollar el sistema en estudio (estudiar su viabilidad). Por tanto, durante esta fase se establecen los objetivos del proyecto, se realiza su la planificación y se determina su alcance. Al hacer la planificación hay que considerar: los criterios de éxito del proyecto; hacer una adecuada estimación de recursos; hacer una evaluación del riesgo; y definir un plan de trabajo, identificando los diversos hitos del proyecto. Flujos de trabajo en esta fase: El desarrollo de esta fase supone empezar por el flujo de trabajo (workflow) de requisitos, en cuyo inicio se debe comprender el dominio del problema y luego, construir el modelo de negocio (cómo la empresa realiza los negocios en ese dominio). En esta fase se realiza también el diagrama de casos de usos inicial, dentro del flujo de trabajo de requisitos y del modelo de negocio. Si el sistema es grande también se les da una prioridad en función del riesgo que suponga su desarrollo, de modo que los que sean críticos se consideren antes. Al final de la fase de inicio se examinan los objetivos del proyecto y se determina si se continúa o no. Para ello, es necesario que durante el desarrollo de fase se haya considerado lo siguiente: Estudio de viabilidad del sistema que se va a desarrollar, una estimación de la duración del desarrollo y una estimación de riesgos. Esto se hace también durante el flujo de trabajo de requisitos. Además, una pequeña parte del flujo de trabajo de análisis se realiza también en esta fase. En este apartado, se hace el análisis de los casos de uso críticos, para que pueda empezarse el diseño de la arquitectura. Durante la fase de inicio, igualmente empieza a desarrollarse el flujo de trabajo de implementación, aunque no se suele realizar ninguna codificación. Sin embargo, a veces, se construye un prototipo para probar la viabilidad de parte del sistema propuesto. No es un prototipo rápido construido para asegurar que los requisitos se han determinado con precisión, sino que es más una maqueta de ingeniería, es decir, un modelo a escala para probar la factibilidad de la construcción. El flujo de trabajo de pruebas comienza casi al principio de esta fase. Su objetivo es asegurar que los requisitos se hayan determinado con precisión. Documentación obtenida al final de esta fase: La versión inicial del modelo de dominio. La versión inicial del modelo de negocio. La versión inicial del modelo de los artefactos de los requisitos (diagrama de casos de usos). Una versión preliminar de los artefactos del análisis. Una versión preliminar de la arquitectura. La lista inicial de los riesgos. El plan de trabajo para la fase siguiente. La versión inicial de caso de negocios. FASE 2. ELABORACION. Objetivos de esta fase y flujos de trabajo asociados: El propósito de esta fase es establecer una base arquitectónica sólida para el sistema sobre la que se asentará la fase de construcción. Las decisiones sobre la arquitectura del sistema se deben tomar considerando el proyecto de un modo global. Esto supone describir los requisitos fundamentales del sistema y de mayor peso identificados en fases anteriores. También se tendrá que hacer una evaluación de los riesgos. Para verificar la arquitectura se implementa un sistema (prototipo de la arquitectura) que demuestre las posibilidades de la arquitectura y ejecute los casos de uso más significativos. Los objetivos se pueden enumerar como sigue: 1. Analizar el dominio del problema: esto supone refinar los requisitos iniciales (expresados en el diagrama de casos de uso). Se realiza dentro del flujo de trabajo de requisitos. 2. Eliminar (o resolver) los elementos de más alto riesgo del proyecto: es decir, refinar sus prioridades. Se realiza dentro del flujo de trabajo de análisis. 3. Desarrollar el plan de trabajo para el proyecto. Al final de la fase se examinan el alcance y objetivos del sistema, la arquitectura elegida, y la solución de los riesgos mayores. Igualmente se decide si se pasa a la fase siguiente. Documentación obtenida al final de esta fase: Modelo de dominio terminado. Modelo de negocio terminado. Los artefactos de los requisitos terminados.
  • 4. Los artefactos de análisis terminados. Una versión revisada de la arquitectura. La lista revisada y refinada de los riesgos. El plan de administración del proyecto para el resto de fases. El caso de negocios terminado. FASE 3. CONSTRUCCION. En esta fase se desarrolla iterativamente y de modo incremental un producto completo preparado para la siguiente fase. Esto supone describir los restantes objetivos, los criterios de aceptación, y refinado del diseño. Se completan la implementación y las pruebas. Para ello, se describen los requisitos no desarrollados antes y se completa el desarrollo del sistema basándose en la arquitectura definida. Flujos de trabajo en esta fase: El peso de esta fase lo lleva el desarrollo del flujo de trabajo de implementación y de pruebas. Dentro del flujo de trabajo de implementación se codifican los distintos módulos obtenidos en el diseño detallado. A estos módulos se les aplican las pruebas unitarias (flujo de trabajo de pruebas). Luego los módulos se compilan y se integran para formar subsistemas a los que se les aplican las pruebas de integración. Por otra parte los diversos subsistemas que formen el sistema en desarrollo se combinan para formar el sistema completo, al que se le aplican las pruebas de aceptación. Al final de la fase se obtiene la primera versión operativa y con la calidad suficiente para el sistema desarrollado (a veces se llama versión beta). La carga de trabajo de esta fase la soportan, en su mayoría, los programadores y el equipo de control de calidad, aunque los diseñadores llevan a cabo el rediseño del sistema. Si se detectara algún fallo que requiera modificaciones en los elementos previos de los flujos de trabajo, los analistas también tendrían que intervenir para revisar esos elementos o cambiar los requisitos que han provocado el error. Al final de la fase se decide si todo está preparado para la instalación del sistema (el software acabado, localización del sistema y usuarios preparados). Documentación obtenida al final de esta fase: Manual de usuario inicial y otros manuales necesarios. Todos los artefactos (versión beta). La arquitectura terminada La lista de riesgos actualizada. El plan de administración del proyecto para el resto de fases. El caso de negocios revisado, en caso necesario. FASE 4. TRANSICIÓN. El objetivo de esta fase es asegurar que los requisitos se han cumplido y que el software está disponible para los usuarios finales. Por eso esta fase está dirigida por la retroalimentación de los usuarios, a partir de la información que se deduzca de la versión beta del sistema en funcionamiento. Para ello: Se corrigen los fallos que hubiera para lo cual se realizan las pruebas. Se determinan los elementos que deban ajustarse (problemas no detectados, refinamiento y mejora de algunas características) con un desarrollo adicional. Se actualiza la documentación correspondiente. Se deben descubrir riesgos no detectados anteriormente. Los ajustes que se hagan serán específicos y de corto alcance. Ajustes estructurales mayores debieron haberse resuelto anteriormente en el ciclo de vida y deberán documentarse para futuras ampliaciones. Estando en marcha la versión beta del sistema, se reemplaza por el sistema definitivo que se despliega entre los usuarios. La carga de trabajo de esta fase la soportan los programadores (que hacen los cambios necesarios) y el equipo de control de calidad (que prueba los cambios). Si los fallos que se detecten requieren cambios en los flujos de trabajo de requisitos, del análisis o del diseño, los analistas también tendrían que intervenir. Al final de la fase, se decide si se han cumplido los objetivos previstos y se puede determinar si es necesario empezar otro ciclo de desarrollo. Por otra parte, se anotan las lecciones aprendidas, para aplicarlas en próximos desarrollos. Documentación obtenida al final de esta fase: Todos los artefactos (versión final). Los manuales completos.
  • 5. ANEXOS Figura 1 construcción de un sistema de información con 4 incrementos o fases. BIBLIOGRAFÍA Stephen R. Schach. D. Mc Graw Hill. ISBN 970-10-4982-9. 2005.