Vous êtes sur la page 1sur 14

UNIVERSIDAD INCA GARCILASO DE LA VEGA FACULTAD DE INGENIERIA DE SISTEMAS, CMPUTO Y TELECOMUNICACIONES PROGRAMA DE EDUCACION A DISTANCIA

_______________________________________________________
TAREA ACADEMICA 2012 3

Proceso Unificado de Desarrollo de Software


APELLIDOS NOMBRES CODIGO DE ALUMNO CARRERA PROFESIONAL SISTEMAS Y COMPUTO DATOS DE LA ASIGNATURA ASIGNATURA PROFESOR FECHA DE PRESENTACIN : Anlisis de Sistemas : ---------------------: DD/MM/AA : : : PEREZ JUAN 00000000 : INGENIERIA DE

Tabla de contenido
1. Introduccin.......................................................................................................3 2. Qu es un proceso de desarrollo de software?.................................................4 2.1 Necesidad y beneficios del proceso en el desarrollo de Software.................4 2.2 Modelos de Proceso de Desarrollo de Software existente ........................4

3. Qu es el Proceso Unificado Rational (RUP).....................................................5 3.1. Por qu RUP se dice Dirigido por Casos de uso? ......................................5 3.2. Por qu RUP se dice Centrado en arquitectura?........................................7 3.3. Por qu RUP se dice Iterativo e incremental?...........................................8 4. Qu es el Ciclo de Vida del RUP?.....................................................................9 4.1 Fases del Ciclo de vida del RUP....................................................................9 4.1.1 Qu se desarrolla en la fase de Inicio?.....................................................9 4.1.2 Qu se especfica en la fase de elaboracin?.......................................9 4.1.3 Qu se crea en la fase de Construccin?..............................................9 4.1.4 Qu cubre en la fase de transicin?....................................................10 5. Qu son los flujos de trabajo fundamentales del RUP?..................................10 5.1 Qu se desarrolla flujo modelado del negocio?.........................................10 5.2 Qu se define en el flujo de requerimientos?............................................10 5.3 Qu se describe en el flujo de anlisis? ...................................................10 6. Qu es un modelo?........................................................................................11 6.1. Cuntos son, cules son y cmo se relacionan los modelos fundamentales a construir en cada flujo de trabajo fundamental del proceso RUP?.................................................................................................................11 6.1.1 Qu representa el modelo de Casos de uso negocios (del flujo modelado del negocio)? ...............................................................................12 6.1.2 Qu representa el modelo de Casos de uso de dominio (del flujo de requerimientos)?...........................................................................................12 7. Qu es un UML?.............................................................................................12 7.1 Explique la relacin entre RUP y UML, respecto a los modelos...................12

7.2 Establezca la diferencia entre modelos estticos y modelos dinmicos y elabore una lista de los modelos estticos de UML y otra de los modelos dinmicos. .......................................................................................................13 8. Conclusiones....................................................................................................13 9. Referencia Bibliogrfica...................................................................................14

1. Introduccin Las diferentes ramas de ingeniera o arquitectura ha encontrado til desde hace mucho tiempo la representacin de los diseos de forma grfica. Desde los inicios de la informtica se han estado utilizando distintas formas de representar los diseos de una forma ms bien personal o con algn modelo grfico. La falta de estandarizacin en la manera de representar grficamente un modelo impeda que los diseos grficos realizados se pudieran compartir fcilmente entre distintos diseadores. Se necesitaba por tanto un lenguaje no slo para comunicar las ideas a otros desarrolladores sino tambin para servir de apoyo en los procesos de anlisis de un problema. Con este objetivo se cre el proceso de desarrollo de software, RUP(Rational Unified Process), que junto con el Lenguaje Unificado de Modelado(Unified Modeling Language), constituye la metodologa estndar ms utilizada para el anlisis, implementacin y documentacin de sistemas orientados a objetos. UML se ha convertido en ese estndar tan ansiado para representar y modelar la informacin con la que se trabaja en las fases de anlisis y, especialmente, de diseo. El lenguaje UML tiene una notacin grfica muy expresiva que permite representar en mayor o menor medida todas las fases de un proyecto informtico: desde el anlisis con los casos de uso, el diseo con los diagramas de clases, objetos, etc., hasta la implementacin y configuracin con los diagramas de despliegue.

2. Qu es un proceso de desarrollo de software?


Un proceso de desarrollo de software tambin se le puede denominar como ciclo de vida del desarrollo de software, que vendra hacer la estructura aplicada para el desarrollo de un producto de software. El proceso de desarrollo de software define el qu, quin, cundo y cmo del desarrollo de software. Encontramos varios modelos a seguir para el establecimiento de un proceso para el desarrollo de software, cada uno de los cuales describe un enfoque diferente para diferentes actividades que tienen lugar durante el proceso. Pressman (2002) considera al Proceso como un marco de trabajo que define las tareas a realizar para desarrollar software de alta calidad. 2.1 Necesidad y beneficios del proceso en el desarrollo de Software. La necesitad de establecer el proceso de desarrollo, es incrementar la calidad del software a travs de una mayor transparencia y control sobre el proceso. Para obtener calidad en el producto final, es fundamental producir lo esperado en tiempo y costo estimados. Este desarrollo de procesos no va a permitir desarrollar software con el menor nmero de fallos, adecuado a las necesidades del cliente y entregar a tiempo el producto, la produccin de software debe convertirse en un proceso disciplinado. 2.2 Modelos de Proceso de Desarrollo de Software existente A continuacin se presentan 04 modelos para el desarrollo de software:

Modelo Cascada

de

El ciclo de desarrollo de software. Este modelo tiene una secuencia ordenada. El trabajo de una etapa previa es la entrada del siguiente proceso. Provee de un gran control sobre las fechas de entrega y entregables.

Modelo en V

Una reexaminacin del modelo del ciclo de vida desde el punto de vista de aseguramiento de calidad. Cuando cada proceso termina su producto, las especificaciones de prueba para las pruebas de los procesos estn tambin completas.

Modelo prototipos

de

Modelo espiral

Es un mtodo menos formal de desarrollo. El prototipo es una tcnica para comprender las especificaciones. Un prototipo puede ser eliminado. Un prototipo puede llegar a ser parte del producto final. Los productos de software son creados a travs de mltiples repeticiones del proceso del ciclo de vida. Se rompen un mini-proyectos. Estos modelos han sido aplicados al desarrollo de software. Aun no han madurado al punto de ser aplicados como modelos de desarrollo con tiempos y limitaciones de costos.

3. Qu es el Proceso Unificado Rational (RUP)


Las siglas RUP en ingles significa Rational Unified Process 1 (Proceso Unificado de Rational), habitualmente resumido como RUP, es un producto del proceso de ingeniera de software que proporciona un enfoque disciplinado para asignar tareas y responsabilidades dentro de una organizacin del desarrollo. Su meta es asegurar la produccin del software de alta calidad que resuelve las necesidades de los usuarios dentro de un presupuesto y tiempo establecidos. Segn Jacaboson, I., Booch, G., Rumbaugh J. (1998)2.- 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. Tambin permite evitar problemas legales ya que Proceso Unificado de Rational o RUP son marcas registradas por IBM (desde su compra de Rational Software Corporation en 2003). Segn Grady Booch(2000)23 un reflejo de lo que hemos visto en el trabajo con literalmente decenas de miles de proyectos en los ltimos 20 aos, la codificacin de lo que funciona en las organizaciones exitosas y lo que est notablemente ausente en los fallidos. 3.1. Por qu RUP se dice Dirigido por Casos de uso? Segn Kruchten, P. (2000)4, los Casos de Uso son una tcnica de captura de requisitos que fuerza a pensar en trminos de importancia para el usuario y no slo en trminos de funciones que sera bueno contemplar.
1 2 3

Desarrollado por la empresa Rational Software actualmente propiedad de IBM Jacaboson, I., Booch, G., Rumbaugh J., El Proceso Unificado de Desarrollo de Software, 2000 Addison Wesley

Grady Booch, iseador de software, un metodologista de software y entusiasta de diseo de patrones. Es director cientfico de Rational Software (ahora parte de IBM) y editor de una serie de Benjamin/Cummings 4 Kruchten, P., The Rational Unified Process: An Introduction, 2000 Addison Wesley

Se define un Caso de Uso como un fragmento de funcionalidad del sistema que proporciona al usuario un valor aadido. Los Casos de Uso representan los requisitos funcionales del sistema. En RUP los Casos de Uso no son slo una herramienta para especificar los requisitos del sistema. Tambin guan su diseo, implementacin y prueba. Los Casos de Uso constituyen un elemento integrador y una gua del trabajo Debemos tener en cuenta que un sistema de software se crea para servir a sus usuarios. Por lo tanto, para construir un sistema exitoso se debe conocer qu es lo que quieren y necesitan los usuarios prospectos. El trmino usuario no se refiere solamente a los usuarios humanos, sino a otros sistemas. En este contexto, el trmino usuario representa algo o alguien que interacta con el sistema por desarrollar. Los Casos de Uso no slo inician el proceso de desarrollo sino que proporcionan un hilo conductor, permitiendo establecer trazabilidad entre los artefactos que son generados en las diferentes actividades del proceso de desarrollo. Basndose en los Casos de Uso se crean los modelos de anlisis y diseo, luego la implementacin que los lleva a cabo, y se verifica que efectivamente el producto simplemente adecuadamente cada Caso de Uso. Todos los modelos deben estar sincronizados con el modelo de Casos de Uso.

Figura 1. Modelo de Casos de Uso

Este modelo reemplaza la tradicional especificacin funcional del sistema. Una especificacin funcional tradicional se concentra en responder la pregunta: Qu se supone que el sistema debe hacer? La estrategia de casos de uso puede ser definida agregando tres palabras al final de la pregunta: por cada usuario? Estas tres palabras tienen una implicacin importante, nos fuerzan a pensar en trminos del valor a los usuarios y no solamente en trminos de las funciones que sera bueno que tuviera. Sin embargo, los casos de uso no son solamente una herramienta para especificar los requerimientos del sistema, tambin dirigen su diseo, implementacin y pruebas, esto es, dirigen el proceso de desarrollo.

An y cuando los casos de uso dirigen el proceso, no son elegidos de manera aislada. Son desarrollados a la par con la arquitectura del sistema, esto es, los casos de uso dirigen la arquitectura del sistema y la arquitectura del sistema influencia la eleccin de los casos de uso. Por lo tanto, la arquitectura del sistema y los casos de uso maduran conforme avanza el ciclo de vida. 3.2. Por qu RUP se dice Centrado en arquitectura? La arquitectura de un sistema es la organizacin o estructura de sus partes ms relevantes, lo que permite tener una visin comn entre todos los involucrados (desarrolladores y usuarios) y una perspectiva clara del sistema completo, necesaria para controlar el desarrollo [Kru00]. La arquitectura involucra los aspectos estticos y dinmicos ms significativos del sistema, est relacionada con la toma de decisiones que indican cmo tiene que ser construido el sistema y ayuda a determinar en qu orden. Adems la definicin de la arquitectura debe tomar en consideracin elementos de calidad del sistema, rendimiento, reutilizacin y capacidad de evolucin por lo que debe ser flexible durante todo el proceso de desarrollo. La arquitectura se ve influenciada por la plataforma software, sistema operativo, gestor de bases de datos, protocolos, consideraciones de desarrollo como sistemas heredados. Muchas de estas restricciones constituyen requisitos no funcionales del sistema.
En el caso de RUP adems de utilizar los Casos de Uso para guiar el proceso se presta especial atencin al establecimiento temprano de una buena arquitectura que no se vea fuertemente impactada ante cambios posteriores durante la construccin y el mantenimiento. Cada producto tiene tanto una funcin como una forma. La funcin

corresponde a la funcionalidad reflejada en los Casos de Uso y la forma la proporciona la arquitectura. Existe una interaccin entre los Casos de Uso y la arquitectura, los Casos de Uso deben encajar en la arquitectura cuando se llevan a cabo y la arquitectura debe permitir el desarrollo de todos los Casos de Uso requeridos, actualmente y en el futuro. Esto provoca que tanto arquitectura como Casos de Uso deban evolucionar en paralelo durante todo el proceso de desarrollo de software. Es conveniente ver el sistema desde diferentes perspectivas para comprender mejor el diseo por lo que la arquitectura se representa mediante varias vistas que se centran en aspectos concretos del sistema, abstrayndose de los dems. Para RUP, todas las vistas juntas forman el llamado modelo 4+1 de la arquitectura segn Kruchten, P.(19986), el cual recibe este nombre porque lo forman las vistas lgica, de implementacin, de proceso y de despliegue, ms la de Casos de Uso que es la que da cohesin a todas.

Figura 2. Evolucin de la Arquitectura del Sistema

El papel del arquitecto de sistemas es similar en naturaleza al papel que el arquitecto desempea en la construccin de edificios. El edificio se mira desde

diferentes puntos de vista: estructura, servicios, plomera, electricidad, etc. Esto le permite al constructor ver una radiografa completa antes de empezar a construir. Similarmente, la arquitectura en un sistema de software es descrita como diferentes vistas del sistema que est siendo construido. 3.3. Por qu RUP se dice Iterativo e incremental? Jacaboson, I., Booch, G., Rumbaugh J.(2000)95, el equilibrio correcto entre los Casos de Uso y la arquitectura es algo muy parecido al equilibrio de la forma y la funcin en el desarrollo del producto, lo cual se consigue con el tiempo. Para esto, la estrategia que se propone en RUP es tener un proceso iterativo e incremental en donde el trabajo se divide en partes ms pequeas o mini proyectos. Permitiendo que el equilibrio entre Casos de Uso y arquitectura se vaya logrando durante cada mini proyecto, as durante todo el proceso de desarrollo. Cada mini proyecto se puede ver como una iteracin (un recorrido ms o menos completo a lo largo de todos los flujos de trabajo fundamentales) del cual se obtiene un incremento que produce un crecimiento en el producto. Una iteracin puede realizarse por medio de una cascada como se muestra en la Figura 6. Se pasa por los flujos fundamentales (Requisitos, Anlisis, Diseo, Implementacin y Pruebas), tambin existe una planificacin de la iteracin, un anlisis de la iteracin y algunas actividades especficas de la iteracin. Al finalizar se realiza una integracin de los resultados con lo obtenido de las iteraciones anteriores. El proceso iterativo e incremental consta de una secuencia de iteraciones. Cada iteracin aborda una parte de la funcionalidad total, pasando por todos los flujos de trabajo relevantes y refinando la arquitectura. Cada iteracin se analiza cuando termina. Se puede determinar si han aparecido nuevos requisitos o han cambiado los existentes, afectando a las iteraciones siguientes. Durante la planificacin de los detalles de la siguiente iteracin, el equipo tambin examina cmo afectarn los riesgos que an quedan al trabajo en curso. Toda la retroalimentacin de la iteracin pasada permite reajustar los objetivos para las siguientes iteraciones. Se contina con esta dinmica hasta que se haya finalizado por completo con la versin actual del producto. Las primeras iteraciones (en las fases de Inicio y Elaboracin) se enfocan hacia la comprensin del problema y la tecnologa, la delimitacin del mbito del proyecto, la eliminacin de los riesgos crticos, y al establecimiento de una baseline de la arquitectura.

Jacaboson, I., Booch, G., Rumbaugh J., El Proceso Unificado de Desarrollo de Software, 2000 Addison Wesley

Figura 3. Iteracin RUP

Para cada iteracin se selecciona algunos Casos de Uso, se refina su anlisis y diseo y se procede a su implementacin y pruebas. Se realiza una pequea cascada para cada ciclo. Se realizan tantas iteraciones hasta que se termine la implementacin de la nueva versin del producto.

4. Qu es el Ciclo de Vida del RUP?


El ciclo de vida de RUP se refiere a las fases secuenciales del proyecto de desarrollo del software, cada cual concluye con un producto intermedio. Una evaluacin satisfactoria permite que el proyecto se mueva a la prxima fase. 4.1 Fases del Ciclo de vida del RUP El ciclo de vida consiste en una serie de ciclos, cada uno de los cuales produce una nueva versin del producto, cada ciclo est compuesto por fases y cada una de estas fases est compuesta por un nmero de iteraciones, estas fases son: 4.1.1 Qu se desarrolla en la fase de Inicio? El objetivo general de esta fase es establecer un acuerdo entre todos los interesados acerca de los objetivos del proyecto. Define el mbito y objetivos del proyecto Se define la funcionalidad y capacidades del producto. Es significativamente importante para el desarrollo de nuevo software, ya que se asegura de identificar los riesgos relacionados con el negocio y requerimientos. Para proyectos de mejora de software existente, esta fase es ms breve y se centra en asegurar la viabilidad de desarrollar el proyecto.

4.1.2 Qu se especfica en la fase de elaboracin? Tanto la funcionalidad como el dominio del problema se estudian en profundidad Se define una arquitectura bsica Se planifica el proyecto considerando recursos disponibles. La arquitectura debe abarcar todas las consideraciones de mayor importancia de los requerimientos y una evaluacin del riesgo.

4.1.3 Qu se crea en la fase de Construccin? El objetivo de la fase de construccin es clarificar los requerimientos faltantes y completar el desarrollo del sistema basados en la arquitectura base. El producto se desarrolla a travs de iteraciones donde cada iteracin involucra tareas de anlisis, diseo e implementacin. Las fases de estudio y anlisis que slo dieron una arquitectura bsica, en esta fase es refinada de manera incremental conforme se construye (se permiten cambios en la estructura). Gran parte del trabajo es programacin y pruebas.

Se documenta tanto el sistema construido como el manejo del mismo.

4.1.4 Qu cubre en la fase de transicin? Esta fase se enfoca en asegurar que el software est disponible para sus usuarios. Se puede subdividir en varias iteraciones, adems incluye pruebas del producto para poder hacer el entregable del mismo, as como realizar ajuste menores de acuerdo a ajuste menores propuestos por el usuario. En este punto, la retroalimentacin de los usuarios se centra en depurar el producto, configuraciones, instalacin y aspectos sobre utilizacin. Se libera el producto y se entrega al usuario para un uso real Se incluyen tareas de marketing, empaquetado atractivo, instalacin, configuracin, entrenamiento, soporte, mantenimiento, etc.

5. Qu son los flujos de trabajo fundamentales del RUP?


Los flujos de trabajo son una secuencia de pasos para la culminacin de cada disciplina, estas disciplinas se dividen en dos grupos: Primarias.- son las necesarias para la realizacin de un proyecto de software, aunque para proyectos no muy grandes se pueden omitir algunas; entre ellas se tienen: Modelado del Negocio, Requerimientos, Anlisis y Diseo, Implementacin, Pruebas, Despliegue. Apoyo.- como su nombre lo indica sirven de apoyo a las primarias y especifican otras caractersticas en la realizacin de un proyecto de software; entre estas se tienen: Entorno, Gestin del Proyecto, Gestin de Configuracin y Cambios. 5.1 Qu se desarrolla flujo modelado del negocio? Desarrolla la estructura y la dinmica de la organizacin, comprende los problemas actuales e identifica posibles mejoras, comprende los procesos de negocio. Utiliza el Modelo de Casos de Uso del Negocio para describir los procesos del negocio y los clientes, el Modelo de Objetos del Negocio para describir cada Caso de Uso del Negocio con los Trabajadores, adems utilizan los Diagramas de Actividad y de Clases. 5.2 Qu se define en el flujo de requerimientos? Se define lo que el sistema debe hacer (Especificar Requisitos), definir los lmites del sistema, y una interfaz de usuario, realizar una estimacin del costo y tiempo de desarrollo. Utiliza el Modelo de Casos de Usos para modelar el Sistema que comprenden los Casos de Uso, Actores y Relaciones, adems utiliza los diagramas de Estados de cada Caso de Uso y las especificaciones suplementarias.

5.3 Qu se describe en el flujo de anlisis? Se describe la arquitectura del sistema y tiene como objetivos trasladar requisitos en especificaciones de implementacin, al decir anlisis se refiere a transformar CU en clases, y al decir diseo se refiere a refinar el anlisis para poder implementar los diagramas de clases de anlisis de cada CU, los diagramas de colaboracin de de cada CU, el de clases de diseo de cada CU, el

de secuencia de diseo de CU, el de estados de las clases, el modelo de despliegue de la arquitectura.

6. Qu es un modelo?
Podemos conceptualizar modelo en diferentes reas desde el arte hasta la parte ms abstracta y cientfica, tratando de ser objetivo podemos describir que modelo: es una representacin de un objeto, sistema o idea, de forma diferente al de la entidad misma. Los modelos son muy tiles para describir, explicar o comprender mejor la realidad, cuando es imposible trabajar directamente en la realidad en s. 6.1. Cuntos son, cules son y cmo se relacionan los modelos fundamentales a construir en cada flujo de trabajo fundamental del proceso RUP? En RUP se han agrupado las actividades en grupos lgicos definindose 9 flujos de trabajo principales, los 6 primeros son conocidos como flujos de ingeniera y los tres ltimos como flujos de apoyo. Modelo del Negocio: Describe los procesos de negocio, identificando quines participan y las actividades que requieren automatizacin. Requerimiento: Define qu es lo que el sistema debe hacer, para lo cual se identifican las funcionalidades requeridas y las restricciones que se imponen. Anlisis y Diseo: Describe cmo el sistema ser realizado a partir de la funcionalidad prevista y las restricciones impuestas (requerimientos), por lo que indica con precisin lo que se debe programar. Implementacin: Define cmo se organizan las clases y objetos en componentes, cules nodos se utilizarn y la ubicacin en ellos de los componentes y la estructura de capas de la aplicacin. Prueba (Testeo): Busca los defectos a los largo del ciclo de vida. Instalacin o despliegue: Produce relase del producto y realiza actividades (empaque, instalacin, asistencia a usuarios, etc.) para entregar el software a los usuarios finales. Administracin del proyecto: Involucra actividades con las que se busca producir un producto que satisfaga las necesidades de los clientes. Administracin de configuracin y cambios: Describe cmo controlar los elementos producidos por todos los integrantes del equipo de proyecto en cuanto a: utilizacin/actualizacin concurrente de elementos, control de versiones, etc. Ambiente: Contiene actividades que describen los procesos y herramientas que soportarn el equipo de trabajo del proyecto; as como el procedimiento para implementar el proceso en una organizacin.

6.1.1 Qu representa el modelo de Casos de uso negocios (del flujo modelado del negocio)? Representa los procesos de negocio, describe los procesos del negocio y los clientes. Cada uno de los procesos identificados puede ser un Casos de Uso del Negocio. Para desarrollar el Diagrama de Casos de Uso del Negocio se debe estudiar los estereotipos de Casos de Uso del Negocio y el de Actor del Negocio. Estos dos estereotipos son suficientes para la creacin del Diagrama de Casos de Uso del Negocio. El Modelo de Caso de Uso del Negocio implicar la determinacin de los Actores y Casos de Uso del Negocio 6.1.2 Qu representa el modelo de Casos de uso de dominio (del flujo de requerimientos)? Representa el contexto del problema, explica cuales son y cmo se relacionan los conceptos relevantes en la descripcin del problema.

7. Qu es un UML?
(Unified Modeling Language - Lenguaje Unificado de Modelado). popular lenguaje de modelado de sistemas de software. Se trata de grfico para construir, documentar, visualizar y especificar un software. Entre otras palabras, UML se utiliza para definir un software. UML es un un lenguaje sistema de sistema de

Posee la riqueza suficiente como para crear un modelo del sistema, pudiendo modelar los procesos de negocios, funciones, esquemas de bases de datos, expresiones de lenguajes de programacin, etc. 7.1 Explique la relacin entre RUP y UML, respecto a los modelos. Mientras que UML es slo un lenguaje visual y de modelado, RUP es un proceso de desarrollo de software. RUP se basa en el desarrollo iterativo e incremental. Y este proceso es relativamente complicado si no lleva una adecuada documentacin. Para hacer ms fcil el trabajo, dividen a las actividades en disciplinas y dentro de stas proponen el uso de modelos. Cada disciplina atacar cierta actividad o tarea desde un punto de vista. Es aqu donde entra UML. Como UML ofrece un amplio conjunto de diagramas para representar las ideas desde diferentes, y complementarios, punto de vista, RUP aprovecha esta ventaja y adoptan a UML como una herramienta ms para realizar, disear y documentar el desarrollo de sistemas. En sntesis, RUP propone usar UML para llevar la documentacin del sistema, facilitar la etapa del diseo y posterior construccin o desarrollo, transmitir ideas y ayudar al equipo a comunicarlas. Ahora bien, UML tiene mayor sentido cuando se est hablando de un anlisis, diseo y programacin bajo el paradigma OO (Orientado a Objetos), aunque uno

puede, si as lo desea, extrapolar el concepto de un diagrama para transmitir una idea fuera del paradigma OO. Como por ej., el diagrama de actividad que en ocasiones se lo emplea para representar el flujo de informacin y los procesos de un rea o departamento de una empresa. Recordar que como proceso, RUP no impone el uso del paradigma de programacin. Si bien el concepto UP naci para facilitar los proyectos que hacan uso de la orientacin a objetos, nada impide seguir otro paradigma. Los modelos o procesos de desarrollo slo se limitan a ofrecer un marco de trabajo y una forma de estructurar las actividades. 7.2 Establezca la diferencia entre modelos estticos y modelos dinmicos y elabore una lista de los modelos estticos de UML y otra de los modelos dinmicos. Los sistemas estticos que no cambia en el tiempo, como es una piedra, una montaa, un vaso de plstico, etc. En los sistemas estticos no existen a lo que llamamos entradas y salidas, mientras que en los sistemas dinmicos si existen. Mientras que los sistemas dinmicos que cambian en el tiempo, como el universo, tomo, la tierra, un hongo, etc. Es decir en estos sistemas se presenta un cambio o una evolucin de su estado en un tiempo, este estado se puede caracterizar determinando los lmites del sistema, los elementos y sus relaciones; de esta forma se pueden elaborar modelos que buscan representar la estructura del mismo sistema. Dentro del enfoque de sistemas se centran los anlisis en los sistemas dinmicos. Una caracterstica que comparten ambos sistemas, es la complejidad la cual se caracteriza por 2 factores: La variedad de elementos, dotados de funciones especficas y organizadas en niveles jerrquicos. Interaccin de los elementos entre s y con el medio; en general, interacciones no lineales

8. Conclusiones
El desarrollo de un Sistema de Informacin comprende varios componentes o pasos llevados a cabo durante la etapa del anlisis, el cual ayuda a traducir las necesidades del cliente en un modelo de Sistema que utiliza uno ms de los componentes: Software, hardware, personas, base de datos, documentacin y procedimientos. En una organizacin o Empresa, el anlisis y Diseo de Sistemas, es el proceso de estudiar su Situacin con la finalidad de observar cmo trabaja y decidir si es necesario realizar una mejora; el encargado de llevar a cabo estas tareas es el analista de sistemas.

Antes de comenzar con el desarrollo de cualquier proyecto, se conduce un estudio de Sistemas para detectar todos los detalles de la situacin actual de la empresa. La informacin reunida con este estudio sirve como base para crear varias estrategias de Diseo. Los administradores deciden que estrategias seguir. Los Gerentes, empleados y otros usuarios finales que se familiarizan cada vez ms con el uso de computadoras estn teniendo un papel muy importante en el desarrollo de sistemas. Todas las organizaciones son Sistemas que actan de manera reciproca con su medio ambiente recibiendo entradas y produciendo salidas. Los Sistemas que pueden estar formados por otros Sistemas de denominan subsistemas y funcionan para alcanzar los fines de su Implantacin. Es por eso que existen varios modelos o mtodos para la realizacin del anlisis y diseo de un sistema.

9. Referencia Bibliogrfica
http://www.ctic.uni.edu.pe/files/insoft01.pdf http://www.buenastareas.com/ensayos/Ventajas-y-Desventajas-Del-ProcesoDe/1514346.html http://www.qualitrain.com.mx/Beneficios-de-un-buen-Proceso-de-Desarrollo-deSoftware.html http://revista.eia.edu.co/articulos8/Art.10.pdf http://www.portaleducativo.hn/pdf/AplicandoModelosProcesosSoftwareHipermedi a.pdf http://alarcos.inf-cr.uclm.es/doc/ISOFTWAREI/Tema04.pdf http://www.ecured.cu/index.php/Modelo_de_desarrollo_r %C3%A1pido_de_aplicaciones http://es.wikipedia.org/wiki/Metodolog %C3%ADa_de_desarrollo_de_software#Rapid_Application_Development_.28RAD. 29 http://es.wikipedia.org/wiki/Proceso_Unificado_de_Rational http://www.monografias.com/trabajos-pdf4/metodologia-rup-unapuno/metodologia-rup-una-puno.pdf http://www.usmp.edu.pe/publicaciones/boletin/fia/info49/articulos/RUP%20vs. %20XP.pdf http://es.answers.yahoo.com/question/index?qid=20070516074647AAd0Mvn http://www.ecured.cu/index.php/Proceso_Unificado_de_Desarrollo http://www.utvm.edu.mx/OrganoInformativo/orgJul07/RUP.htm
ITSA ,Metodologas De Desarrollo De Software, Faces De Desarrollo Del Software Pag. 60-70

http://www.kybele.etsii.urjc.es/docencia/IS_LADE/2010-2011/Material/%5BISLADE-2010-11%5DTema4c.IntroPUD.pdf

Vous aimerez peut-être aussi