Repblica Bolivariana de Venezuela Ministerio del Poder Popular para la Educacin Universitaria Aldea Universitaria Comandante Ramn Bentez

Misin Sucre Los Arroyos Municipio Bentez

Profesor: Modesto Gmez

Bachilleres: Rina Bravo C.I.: 20.124.018 Irene Flores C.I.: 14.635.408

Noviembre, de 2.013

Procesos Modificados del Desarrollo

1.- Metodologa Empleada. La metodologa del proceso unificado, es un mtodo iterativo de diseo de software que describe cmo desarrollar software de forma eficaz, utilizando tcnicas probadas en la industria.

Proceso Unificado al Desarrollo. 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 especficos.

El nombre Proceso Unificado se usa para describir el proceso genrico que incluye aquellos elementos que son comunes a la mayora de los refinamientos existentes. Es una metodologa orientada a conducir el proceso de desarrollo de software en sus aspectos tcnicos; los flujos y productos de trabajo de UP no incluyen la administracin del proyecto.

2.- Fases de Desarrollo. Disciplinas, Introduccin a los Procesos Agiles de Desarrollo, Fundamentos de los Procesos. a. Fases. Se divide en cuatro fases:

Fase de Inicio. Es la fase ms pequea del proyecto e, idealmente, debe realizarse tambin en un periodo de tiempo pequeo (una nica iteracin).

El hecho de llevar a cabo una fase de inicio muy larga indica que se esta realizando una especificacin previa excesiva, lo que responde ms a un modelo en cascada.

Objetivos:

Establecer una justificacin para el proyecto. Establecer el mbito del proyecto. Esbozar los casos de uso y los requisitos clave que dirigirn las decisiones de diseo.

Esbozar las arquitecturas candidatas. Identificar riesgos. Preparar el plan del proyecto y la estimacin de costes.

Fase de Elaboracin. Durante esta fase se capturan la mayora de los requisitos del sistema. Los objetivos principales de esta fase sern la identificacin de riesgos y establecer y validar la arquitectura del sistema.

Base de Arquitectura Ejecutable: La arquitectura se valida a travs de la implementacin de una Base de Arquitectura Ejecutable: se trata de una implementacin parcial del sistema que incluye los

componentes principales del mismo.

Al final de la fase de elaboracin la base de arquitectura ejecutable debe demostrar que soporta los aspectos clave de la funcionalidad del sistema y que muestra la conducta adecuada en trminos de rendimiento, escalabilidad y coste.

Al final de la fase se elabora un plan para la fase de construccin.

El hito arquitectura del ciclo de vida marca el final de la fase.

Fase de construccin. Es la fase ms larga de proyecto. El sistema es construido en base a lo especificado en la fase de elaboracin.

Las caractersticas del sistema se implementan en una serie de iteraciones cortas y limitadas en el tiempo. El resultado de cada iteracin es una versin ejecutable de software.

El hito de capacidad operativa inicial marca el final de la fase.

Fase de transicin. En esta fase el sistema es desplegado para los usuarios finales. La retroalimentacin recibida permite incorporar refinamientos al sistema en las sucesivas iteraciones.

Esta iteracin tambin cubre el entrenamiento de los usuarios para la utilizacin del sistema.

El hito de lanzamiento del producto marca el final de la fase.

Cada fase finaliza en un hito. Cada hito se determina por la disponibilidad de un conjunto de artefactos, es decir un conjunto de modelos o documentos que han sido desarrollados hasta alcanzar un estado predefinido.

b. Disciplinas. Cada disciplina es un conjunto de actividades relacionadas (flujos de trabajo) vinculadas a un rea especfica dentro del proyecto total. Las ms importantes son:

Modelado del negocio. El objetivo es establecer un canal de comunicacin entre los ingenieros del negocio y los ingenieros del software.

Los ingenieros del software deben conocer la estructura y dinmica de la organizacin objetivo (el cliente), los problemas actuales y sus posibles mejoras.

Se plasma en la identificacin del modelo del dominio en el que se visualizan los aspectos bsicos del dominio de aplicacin.

Requisitos. El objetivo es describir que es lo que tiene que hacer el sistema y poner a los desarrolladores y al cliente de acuerdo en esta descripcin. Anlisis y diseo. Describe como el software ser realizado en la fase de implementacin.

Se plasma en un modelo de diseo que consiste en una serie de clases (agrupadas en paquetes y subsistemas) con interfaces bien definidos.

Tambin

contiene descripciones de

cmo

los

objetos

colaboran para realizar las acciones incluidas en los casos de uso.

Implementacin. Se implementan las clases y objetos en trminos de componentes (ficheros fuentes, binarios, ejecutables, entre otros).

Prueba. Se comprueba que el funcionamiento es correcto analizando diversos aspectos: los objetos como unidades, la integracin entre objetos, la implementacin de todos los requisitos, entre otros.

Despliegue. Se crea la versin externa del producto, se empaqueta, se distribuye y se instala en el lugar de trabajo. Tambin se da asistencia y ayuda a los usuarios.

Gestin de configuraciones y cambios. Gestiona aspectos como los sistemas de control de versiones.

Controla las peticiones de cambios clasificndolas segn su estado (nueva, registrada, aprobada, asignada, completa, entre otros).

Los datos se almacenan en una base de datos y se pueden obtener informes peridicos.

Herramientas como Rational ClearQuest o Bugzilla.

Gestin del proyecto. Encargada de definir los planes del proyecto global, los planes de fase y los planes de iteracin.

Entorno. Se centra en las actividades necesarias para configurar el proceso de un proyecto.

El objetivo es proveer a la organizacin de desarrollo software de un entorno de trabajo (que incluye procedimientos y herramientas) que soporten al equipo de desarrollo.

El cuadro siguiente representa cada una de las disciplinas utilizadas en el proceso de desarrollo de software y su nivel de participacin en cada una de las fases definidas del proceso unificado.

Las disciplinas identificadas son modelado de: negocios, requisitos, anlisis, diseo, implementacin y pruebas, como tambin se identifican las disciplinas de apoyo, tales como: configuracin y manejo de proyectos. Todas estas disciplinas son representadas con su correspondiente esfuerzo estimado para cada una de las fases definidas por UP (Proceso Ubificado).

c. Introduccin a los Procesos giles de Desarrollo. El desarrollo gil de software es un marco de trabajo conceptual de la ingeniera de software que promueve iteraciones en el desarrollo a lo largo de todo el ciclo de vida del proyecto. Existen muchos mtodos de desarrollo gil; la mayora minimiza riesgos desarrollando software en cortos lapsos de tiempo.

El software desarrollado en una unidad de tiempo es llamado una iteracin, la cual debe durar de una a cuatro semanas. Cada iteracin del ciclo de vida incluye: planificacin, anlisis de requerimientos, diseo, codificacin, revisin y documentacin.

Una iteracin no debe agregar demasiada funcionalidad para justificar el lanzamiento del producto al mercado, pero la meta es tener un demo (sin errores) al final de cada iteracin. Al final de cada iteracin el equipo vuelve a evaluar las prioridades del proyecto.

Los mtodos giles enfatizan las comunicaciones cara a cara en vez de la documentacin. La mayora de los equipos giles estn localizados en una simple oficina abierta, a veces llamadas "plataformas de lanzamiento" (bullpen en ingls).

La oficina debe incluir revisores, escritores de documentacin y ayuda, diseadores de iteracin y directores de proyecto. Los

mtodos giles tambin enfatizan que el software funcional es la primera medida del progreso. Combinado con la preferencia por las comunicaciones cara a cara, generalmente los mtodos giles son criticados y tratados como "indisciplinados" por la falta de documentacin tcnica.

d. Fundamentos de los Procesos giles de Desarrollo. El auge de la tecnologa, y el objetivo de agilizar y

automatizar los procesos en el desarrollo de software, llevan a la necesidad de implantar Metodologas de Desarrollo de Software que ayuden a entregar un producto de calidad en tiempo y costo estimados, las metodologas giles desarrollo de software

han despertado inters gracias a que proponen simplicidad y velocidad para crear sistemas.

Entre los Elementos claves de los procesos giles de desarrollo tenemos:

Anlisis como una actividad constante. Simplicidad. Poca documentacin. Testeos diarios. Integraciones. Diseo evolutivo. Algunos mtodos giles de desarrollo de software:

Crystal Clear. Proceso Unificado de Rational (RUP), Essential Unified Process (EssUP), Feature Driven Development (FDD).

Mtodos giles.

3.- Introduccin al modelado. El Lenguaje de Modelamiento Unificado (UML - Unified Modeling Language) es un lenguaje grfico para visualizar, especificar y documentar cada una de las partes que comprende el desarrollo de software. El 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.

Caractersticas: Iterativo e Incremental. Dirigido por los casos de uso. Enfocado en los riesgos. Centrado en la arquitectura.

El Lenguaje de Modelado Unificado (UML). Una exigencia de la gran mayora de instituciones dentro de su Plan Informtico estratgico, es que los desarrollos de software bajo una arquitectura en Capas, se formalicen con un lenguaje estndar y unificado.

Es decir, se requiere que cada una de las partes que comprende el desarrollo de todo software de diseo orientado a objetos, se visualice, especifique y documente con lenguaje comn.

Se necesitaba un lenguaje que fuese grfico, a fin de especificar y documentar un sistema de software, de un modo estndar incluyendo aspectos conceptuales tales como procesos de negocios y funciones del sistema.

Este lenguaje unificado que cumple con estos requerimientos, es ciertamente UML, el cual cuenta con una notacin estndar y semnticas esenciales para el modelado de un sistema orientado a objetos.

El lenguaje de modelado es la notacin (principalmente grfica) que usan los mtodos para expresar un diseo. El proceso indica los pasos que se deben seguir para llegar a un diseo. La estandarizacin de un lenguaje de modelado es invaluable, ya que es la parte principal del proceso de comunicacin que requieren todos los agentes involucrados en un proyecto informtico.

Si se quiere discutir un diseo con alguien ms, ambos deben conocer el lenguaje de modelado y no as el proceso que se sigui para obtenerlo.

Una de las metas principales de UML es avanzar en el estado de la integracin institucional proporcionando herramientas de interoperabilidad para el modelado visual de objetos. Sin embargo para lograr un intercambio exitoso de modelos de informacin entre herramientas, se requiri definir a UML una semntica y una notacin.

La notacin es la parte grfica que se ve en los modelos y representa la sintaxis del lenguaje de modelado. Por ejemplo, la notacin del diagrama de clases define como se representan los elementos y conceptos como son: una clase, una asociacin y una multiplicidad.

El lenguaje est dotado de mltiples herramientas para lograr la especificacin determinante del modelo, pero en nuestro caso se trabaja en forma simplificada sobre:

Moldeamiento de Clases Casos de Uso

Moldeamiento de Clases Un diagrama de clases sirve para visualizar las relaciones entre las clases que involucran el sistema, las cuales pueden ser asociativas, de herencia, de uso y de contenimiento.

Un diagrama de clases est compuesto por los siguientes elementos:

Clase: atributos, mtodos y visibilidad. Relaciones: Herencia, Composicin, Agregacin, Asociacin y Uso.

Elementos Clase.

Es la unidad bsica que encapsula toda la informacin de un Objeto (un objeto es una instancia de una clase). A travs de ella podemos modelar el entorno en estudio (una Casa, un Auto, una Cuenta Corriente, entre otros).

Casos de uso: Rrepresenta la forma en como un Cliente (Actor) opera con el sistema en desarrollo, adems de la forma, tipo y orden en como los elementos interactuan (operaciones o casos de uso). Un diagrama de casos de uso consta de los siguientes elementos:

Actor. Casos de Uso. Relaciones de Uso, Herencia y Comunicacin.

Elementos

Actor:

Una definicin previa, es que un Actor es un rol que un usuario juega con respecto al sistema. Es importante destacar el uso de la palabra rol, pues con esto se especifica que un Actor no necesariamente representa a una persona en particular, sino ms bien la labor que realiza frente al sistema. Como ejemplo a la definicin anterior, tenemos el caso de un sistema de ventas en que el rol de Vendedor con respecto al sistema puede ser realizado por un Vendedor o bien por el Jefe de Local.

Caso de Uso:

Es una operacin/tarea especfica que se realiza tras una orden de algn agente externo, sea desde una peticin de un actor o bien desde la invocacin desde otro caso de uso.

Relaciones:
o o

Asociacin Es el tipo de relacin ms bsica que indica la invocacin desde un actor o caso de uso a otra operacin (caso de uso). Dicha relacin se denota con una flecha simple.

Dependencia o Instanciacin

Es una forma muy particular de relacin entre clases, en la cual una clase depende de otra, es decir, se instancia (se crea). Dicha relacin se denota con una flecha punteada.
o

Generalizacin Este tipo de relacin es uno de los ms utilizados, cumple una doble funcin dependiendo de su estereotipo, que puede ser de Uso (<<uses>>) o de Herencia (<<extends>>). Este tipo de relacin esta orientado exclusivamente para casos de uso (y no para actores). Extends: Se recomienda utilizar cuando un caso de uso es similar a otro (caractersticas). Uses: Se recomienda utilizar cuando se tiene un conjunto de caractersticas que son similares en ms de un caso de uso y no se desea mantener copiada la descripcin de la caracterstica. De lo anterior cabe mencionar que tiene el mismo paradigma en diseo y modelamiento de clases, en donde esta la duda clsica de usar o heredar.

Referencia Electrnica

Consultado en la siguiente pgina web: Google

Enlaces:

http://procesodedasarrolo.blogspot.com/2011/11/introduccion-los-procesosagiles-de.html

http://joseluisperezc92.blogspot.com/2011/07/fundamentos-de-losprocesos-agiles-de.html

http://procesodedasarrolo.blogspot.com/2011/11/proceso-unificado-dedesarrollo.html

http://noqualityinside.com.ar/nqi/nqifiles/XP_Agil.pdf

http://ingsoftware072301.obolog.com/up-proceso-unificado-2010775

Introduccin

En la ingeniera del software el trmino fases de desarrollo expresa cmo ha progresado el desarrollo de un software y cunto desarrollo puede requerir. Existen numerosas propuestas de metodologa para desarrollar software. Tradicionalmente estas metodologas se centran en el control del proceso, estableciendo rigurosamente las actividades, herramientas y notaciones al respecto, dado estas reglas estas metodologas se caracterizan por ser rgidos y dirigidos por la documentacin que se genera en cada una de las actividades desarrolladas. El Proceso Unificado de Desarrollo Software o simplemente Proceso Unificado es un marco de desarrollo de software que se caracteriza por estar dirigido porcasos de uso, centrado en la arquitectura y por ser iterativo e incremental. El refinamiento ms conocido y documentado del Proceso Unificado es el Proceso Unificado de Rational o simplemente RUP.

Conclusin

El nombre Proceso Unificado se usa para describir el proceso genrico que incluye aquellos elementos que son comunes a la mayora de los refinamientos existentes. El Proceso Unificado no es simplemente un proceso, sino un marco de trabajo extensible que puede ser adaptado a organizaciones o proyectos especficos. Las disciplinas identificadas son modelado de: negocios, requisitos, anlisis, diseo, implementacin y pruebas, como tambin se identifican las disciplinas de apoyo, tales como: configuracin y manejo de proyectos. Todas estas disciplinas son representadas con su correspondiente esfuerzo estimado para cada una de las fases definidas por UP.