You are on page 1of 14

Prctica 1 Anlisis y especificacin de Sistemas Multimedia

El proceso unificado
Ksenia Belova Alejandro Martn Mlaga Kevin Garca Guilabert

16/02/2012

ndice

Introduccin Caractersticas Elementos del Proceso o o o Fases Disciplinas Artefactos

3 3 5 6 6 8 12 14

Herramientas y Refinamientos Bibliografa

Introduccin
El Proceso Unificado de desarrollo de software es adaptable a los distintos tipos de desarrollo y puede ser configurado de forma independiente segn la complejidad del proyecto. Esto ayuda a los equipos encargados de un proyecto a la hora de administrar el desarrollo de un modo controlado y equilibrando los requerimientos del negocio, los riesgos del proyecto y el tiempo de mercado. Este tipo de desarrollo se basa en los conceptos de clase y objeto y las relaciones que puedan existir entre ellos.

Caractersticas
Iterativo e Incremental El Proceso Unificado es un marco de desarrollo de software iterativo, que se divide en varios mini-proyectos, e incremental, cada mini-proyecto amplia el producto, que est formado por 4 fases distintas: Inicio, Elaboracin, Construccin, Transicin. Cada una de estas iteraciones o mini-proyectos se divide a su vez en varias partes que recuerdan a las definidas en el ciclo de vida clsico o cascada. Estas partes son anlisis de requisitos, diseo, implementacin y prueba. Lo que permite tener productos desarrollados que pueden ser probados, integrados y ejecutados.

Dirigido por los casos de uso Los casos de uso, descripcin del conjunto de operaciones que se deben realizar para conseguir finalizar un determinado proceso, se utiliza para encontrar los requisitos y contenidos que debe completar cada iteracin. Se trata de conseguir que cada iteracin resuelva una serie de situaciones y desarrolle las distintas disciplinas (anlisis de requisitos, diseo, implementacin y prueba). Con esto conseguimos que en cada iteracin se mejore y aada algo al sistema. De esta forma se va avanzando a la siguiente iteracin mientras se cumplan los requisitos marcados. Este tipo de direccin se da principalmente en RUP.

Centrado en la arquitectura La arquitectura es la base de un sistema de software. Esta tiene que ser construida pensado en el presente y el futuro, para evitar posibles problemas. Es decir que debe ser sencilla y bien estructurada para poder permitir su mantenimiento y actualizacin. En los procesos unificados, se asume que no existe una sola arquitectura que agrupe a todos los componentes del sistema. Es decir que se pueden dar distintas estructuras que resuelven los mismos problemas, por tanto se debe pensar ms de una solucin.

Enfocado en los riesgos Se trata de que el equipo de trabajo se centre primero en resolver las tareas segn la dificultad y los riesgos. Resolviendo el riesgo mayor peligro en las primeras etapas del ciclo de vida del proyecto, pudiendo reaccionar antes y evitar problemas mayores.

Elementos del proceso


Todo Proceso Unificado est formado por una serie de elementos: Fases, Disciplinas, Artefactos e Hitos.

Las Fases de un Proceso Unificado son las etapas del mtodo, son cuatro: Inicio, Elaboracin, Construccin, Transicin. El conjunto de artefactos obtenidos despus de terminar una fase corresponde a un hito. Los hitos tienen muchos objetivos distintos, principalmente son usados para que los directores decidan si continan con la siguiente fase o se revisa esta. Otra de las funciones es controlar la direccin y progresos del trabajo, y poner analizar la duracin que ha llevado cada fase. Los Procesos Unificados estn organizados por disciplinas, cada una es un conjunto de actividades relacionadas vinculadas a un rea especfica del proyecto total. Algunas de estas son Requerimientos, Anlisis, Diseo, Codificacin El resultado de cada disciplina recibe el nombre de artefacto, y puede darse distintos formatos como texto, cdigo, diagrama

Fases del proceso


Cada fase se divide en varias iteraciones que ofrecen un incremento del producto que mejora las funcionalidades del sistema. A su vez, las iteraciones estn divididas en una serie de disciplinas. Inicio Es la fase ms corta del proyecto. Su funcin principal es establecer los objetivos del proyecto y determinar su viabilidad. Determinando el mbito del proyecto, los requisitos clave identificando riesgos y preparando el plan del proyecto con la estimacin de costes. El hito final de la fase se denomina Hito Objetivo del Ciclo de Vida. Elaboracin Esta fase consiste en construir un ncleo central de la arquitectura del sistema. En esta etapa se definen las capacidades que ha de tener un sistema con las componentes de software que las implementarn. Tambin se eliminan los riesgos ms importantes del desarrollo. El Hito Arquitectura del Ciclo de Vida marca el final de la fase. Construccin Es la fase ms larga del proyecto. Las caractersticas del sistema se implementan en una serie de iteraciones cortas y limitadas en el tiempo. El resultado de cada una de ellas forma una versin ejecutable del software. El final de la fase se llama Hito de Capacidad Operativa Inicial. Transicin En esta fase se despliega el sistema para los usuarios finales. La retroalimentacin permite incorporar refinamientos en las iteraciones, adems cubre el entrenamiento de usuarios para la utilizacin del sistema. El Hito de Lanzamiento del Producto marca el final.

Disciplinas
El proceso unificado se organiza en disciplinas, es un conjunto de actividades realizadas en un rea determinada del proyecto. Facilita la compresin del proyecto desde la perspectiva tradicional del modelo en cascada. Modelado del negocio Su objetivo es establecer un canal de comunicacin entre los ingenieros del negocio y los ingenieros del software. Estos ltimos deben conocer la estructura y dinmica de los clientes, los problemas actuales y sus mejoras. Se identifica el dominio en el que se visualizan los aspectos bsicos de aplicacin.

Requerimientos Se trata de describir qu es lo que tiene que hacer el sistema y establecer un acuerdo entre los desarrolladores y el cliente. Anlisis y diseo Describe la realizacin del software. Se basa en un diseo que consiste en una serie de clases agrupadas en subsistemas con interfaces bien definidos. Contiene descripciones de cmo colaboran los objetos para realizar las acciones incluidas en los casos de uso. Implementacin Se implementan las clases y objetos en trminos de componentes (ficheros fuente, binarios). Pruebas Se comprueba el bien funcionamiento analizando los objetos, su integracin y la implementacin de los requisitos. Despliegue Se crea la versin externa del producto, se empaqueta, se distribuye y se instala con asistencia y ayuda a los usuarios. Gestin de configuraciones y cambios Gestiona sistemas de control de versiones. Controla las peticiones segn su estado (nueva, aprobada...). Se almacena en una base de datos y se obtienen informes peridicos. Gestin del proyecto Se definen los planes del proyecto global, de fase y de iteracin. Entorno Se centra en actividades de configuracin del proceso de un proyecto. Su objetivo es proveer a la organizacin de desarrollo software de un entorno de trabajo que soporten al equipo de desarrollo.

Artefactos
Un artefacto es un producto tangible resultante del proceso de desarrollo de software. Algunos artefactos como los casos de uso, diagrama de clases u otros modelos UML ayudan a la descripcin de la funcin, la arquitectura o el diseo del software. Otros se enfocan en el proceso de desarrollo en s mismo, como planes de proyecto, casos de negocios o enfoque de riesgos. El cdigo fuente compilado para el testeo se suele considerar un artefacto, ya que el ejecutable es necesario para el plan de testeo. Casos de uso Un caso de uso es una descripcin de los pasos o las actividades que debern realizarse para llevar a cabo algn proceso. Los personajes o entidades que participarn en un caso de uso se denominan actores. En el contexto de ingeniera del software, un caso de uso es una secuencia de interacciones que se desarrollarn entre un sistema y sus actores en respuesta a un evento que inicia un actor principal sobre el propio sistema. Los diagramas de casos de uso sirven para especificar la comunicacin y el comportamiento de un sistema mediante su interaccin con los usuarios y/u otros sistemas.

Pasos para la Definicin de un Caso de Uso: ID NOMBRE REFERENCIAS CRUZADAS CREADO POR ULTIMA ACTUALIZACION POR FECHA DE CREACION FECHA DE ULTIMA ACTUALIZACION ACTORES DESCRIPCION TRIGGER PRE-CONDICION POST-CONDICION FLUJO NORMAL FLUJOS ALTERNATIVOS INCLUDES FRECUENCIA DE USO REGLAS DE NEGOCIO REQUERIMIENTOS ESPECIALES NOTAS Y ASUNTO

Ventajas La tcnica de caso de uso tiene xito en sistemas interactivos, ya que expresa la intencin que tiene el actor (su usuario) al hacer uso del sistema. Como tcnica de extraccin de requerimiento permite que el analista se centre en las necesidades del usuario, qu espera ste lograr al utilizar el sistema, evitando que la gente especializada en informtica dirija la funcionalidad del nuevo sistema basndose solamente en criterios tecnolgicos. A su vez, durante la extraccin (elicitation en ingls), el analista se concentra en las tareas centrales del usuario describiendo por lo tanto los casos de uso que mayor valor aportan al negocio. Esto facilita luego la priorizacin del requerimiento

Diagrama de clases Un diagrama de clases es un tipo de diagrama esttico que describe la estructura de un sistema mostrando sus clases, atributos y las relaciones entre ellos. Los diagramas de clases son utilizados durante el proceso de anlisis y diseo de los sistemas, donde se crea el diseo conceptual de la informacin que se manejar en el sistema, y los componentes que se encargaran del funcionamiento y la relacin entre uno y otro.

UML Lenguaje Unificado de Modelado (UML) es el lenguaje de modelado de sistemas de software ms conocido y utilizado en la actualidad. Es un lenguaje grfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estndar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio, funciones del sistema, y aspectos concretos como expresiones de lenguajes de programacin, esquemas de bases de datos y componentes reutilizables. UML no puede compararse con la programacin estructurada, pues UML significa Lenguaje Unificado de Modelado, no es programacin, solo se diagrama la realidad de una utilizacin en un requerimiento. Mientras que, programacin estructurada, es una forma de programar como lo es la orientacin a objetos, sin embargo, la programacin orientada a objetos viene siendo un complemento perfecto de UML, pero no por eso se toma UML slo para lenguajes orientados a objetos. Artefactos en la fase de inicio Visin y Anlisis del Negocio Describe los objetivos y las restricciones de alto nivel, el anlisis del negocio y proporciona un informe para la toma de decisiones. Modelo de casos de uso Describe los requisitos funcionales y los no funcionales relacionados. Especificacin complementaria Describe otros requisitos. Glosario Terminologa clave del dominio. Lista de Riesgos & Plan de Gestin del Riesgo Describe los riesgos del negocio, tcnicos, recursos, planificacin, y las ideas para mitigarlos o darles respuesta. Prototipos y pruebas de conceptos Para clarificar la visin y validar las ideas tcnicas. Plan de iteracin Describe qu hacer en la primera iteracin de la elaboracin. Plan de Fases & Plan de Desarrollo de Software Estimacin de poca precisin de la duracin y esfuerzo de la fase de elaboracin. Herramientas, personas, formacin y otros recursos. 10

Marco de Desarrollo Una descripcin de los pasos del UP y los artefactos adaptados para el proyecto. El UP siempre debe adaptarse al proyecto.

Artefactos en la fase de Elaboracin Modelo del Dominio Visualizacin de los conceptos del dominio. Modelo de Diseo Diagramas descriptivos del diseo lgico, sin referencias al modo de implementacin. Comprende los diagramas de clase del software, diagramas de interaccin, diagrama de paquetes y otros. Documento de Arquitectura Escribe la correlacin entre los componentes de software y los requerimientos. Es un resumen de las ideas principales del diseo. Modelo de Datos Comprende esquemas de bases de datos, estrategias de transformacin entre objetos y no objetos. Modelo de Pruebas Descripcin de lo qu se probar y cmo se probar, compara el resultado obtenido contra el resultado esperado. Modelo de Implementacin Cdigo fuente, ejecutables, bases de datos, otros. Prototipos UI, Guiones de Casos de Uso Construccin de prototipos de la interfaz de usuario. Modelos de facilidad de uso, navegacin dentro del sistema.

11

Herramientas y Refinamientos
Rational Method Composer Es una plataforma para la gestin de procesos que se usa para gestionar, por ejemplo, rup. La herramienta no es gratuita pero la versin de prueba permite generar el sitio web con toda la informacin disponible del rup en sus versiones classic, mdium y small, adems incluye guas, plantillas, ejemplos, etc. Que te ayudan a realizar un seguimiento del rup. Eclipse process framework Es el equivalente libre del rational method composer, siendo muy similares incluso sus interfaces. Incluye como refinamiento del proceso unificado el openup.

Open up
El OpenUP es un proceso mnimo y suficiente, lo que significa que solo el contenido fundamental y necesario es incluido. Por lo tanto no provee lineamientos para todos los elementos que se manejan en un proyecto pero tiene los componentes bsicos que pueden servir de base a procesos especficos. La mayora de los elementos de OpenUP estn declarados para fomentar el intercambio de informacin entre los equipos de desarrollo y mantener un entendimiento compartido del proyecto, sus objetivos, alcance y avances. Principios del OpenUP Colaborar para sincronizar intereses y compartir conocimiento. Este principio promueve prcticas que impulsan un ambiente de equipo saludable, facilitan la colaboracin y desarrollan un conocimiento compartido del proyecto. Equilibrar las prioridades para maximizar el beneficio obtenido por los interesados en el proyecto. Este principio promueve prcticas que permiten a los participantes de los proyectos desarrollar una solucin que maximice los beneficios obtenidos por los participantes y que cumple con los requisitos y restricciones del proyecto. Centrarse en la arquitectura de forma temprana para minimizar el riesgo y organizar el desarrollo. Desarrollo evolutivo para obtener retroalimentacin y mejoramiento continuo. Este principio promueve prcticas que permiten a los equipos de desarrollo obtener retroalimentacin temprana y continua de los participantes del proyecto, permitiendo demostrarles incrementos progresivos en la funcionalidad.

12

RUP
El Proceso Unificado de Rational (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 con las 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. 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, 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).

13

Bibliografa

http://www.slideshare.net/pabloto/el-proceso-unificado http://www.mitecnologico.com/Main/ElModeloProcesoUnificado http://iie.fing.edu.uy/ense/asign/desasoft/Teorico2/ProcesoUnificado.pdf http://es.wikipedia.org/wiki/Proceso_Unificado http://www.slideshare.net/Sofylutqm/el-proceso-unificado-3943047 http://es.wikipedia.org/wiki/Arquitectura_de_software ftp://190.5.199.3/jjurado/Ingenieria%20de%20Software%20I/04_B_FASES_INICIO.pdf http://quegrande.org/apuntes/EI/OPT/PAI/teoria/07-08/tema_2_-_el_proceso_unificado.pdf http://www.utim.edu.mx/~pmendoza/ftp/rup.pdf

14

You might also like