Está en la página 1de 13

Informtic II

Angel Alberto Melchor Gonzlez Grupo 9291

Licenciatura en Informtica

1.

Introduccin

1.1. Concepto de Sistema de Informacin (SI)


Un sistema de informacin (SI) es un conjunto de elementos o componentes interrelacionados para recolectar (entrada), manipular (procesamiento) y diseminar (salida) datos e informacin, que cuenta adems con un mecanismo de retroalimentacin para el cumplimiento de un objetivo.

1.2. Metodologa de un Sistema de Informacin (SI)


Las metodologas son sistemas completos de tcnicas que incluyen procedimientos paso a paso, productos resultantes, funciones, herramientas y normas de calidad para la terminacin del ciclo de vida completo del desarrollo de sistemas. Los objetivos de las metodologas son: Definir actividades a llevar a cabo en un proyecto de SI. Unificar criterios en la organizacin para el desarrollo de SI. Proporcionar puntos de control y revisin.

1.3. Tipos de Sistemas de Informacin (SI)


Los sistemas de informacin se desarrollan con diversos propsitos, segn las necesidades de la empresa. 1.3.1. Sistemas de Informacin de transacciones Los sistemas de procesamiento de transacciones (TPS, Transaction Processing Systems) son sistemas de informacin computarizada creados para procesar grandes cantidades de datos relacionadas con transacciones rutinarias de negocios, como las nminas y los inventarios. Un TPS elimina el fastidio que representa la realizacin de transacciones operativas necesarias y reduce el tiempo que una vez fue requerido para llevarlos a cabo de manera manual, aunque los usuarios an tienen que capturar datos en los sistemas computarizados. Los TPS expanden los lmites de la organizacin dado que le permiten interactuar con entornos externos. Es importante para las operaciones cotidianas de un negocio, que estos sistemas funcionen sin ningn tipo de interrupcin, puesto que los administradores recurren a los datos producidos por los TPS con el propsito de obtener informacin actualizada sobre el funcionamiento de sus empresas. 1.3.2. Sistemas de informacin gerencial Los sistemas de informacin gerencial (MIS, Management Information Systems) no reemplazan a los sistemas de procesamiento de transacciones, ms bien, incluyen el procesamiento de transacciones. Los MIS son sistemas de informacin computarizados cuyo propsito es contribuir a la correcta interaccin entre los usuarios y las computadoras. Debido a que requieren que los usuarios, software y el hardware funcionen de manera coordinada, los sistemas de informacin gerencial dan apoyo a un espectro de tareas organizacionales mucho

ms amplio que los TPS, como el anlisis y la toma de decisiones. Para acceder a la informacin, los usuarios de un MIS comparten una base de datos comn. sta almacena datos y modelos que ayudan al usuario a interpretar y aplicar los datos. Los MIS producen informacin que se emplea en las tomas de decisiones. Un MIS tambin puede contribuir a unificar algunas de las funciones de informacin computarizadas de una empresa, a pesar de que no existe como una estructura individual en ninguna parte de sta. 1.3.3. Sistemas de apoyo para la toma de decisiones Los sistemas de apoyo para la toma de decisiones (DSS, Decision Support Systems) constituyen una clase de alto nivel de sistemas de informacin computarizada. Los DSS coinciden con los sistemas de informacin gerencial en que ambos dependen de una base de datos para abastecerse de datos. Sin embargo, difieren en que el DSS pone nfasis en el apoyo a la toma de decisiones en todas sus fases, aunque la decisin definitiva es responsabilidad exclusiva de l apersona o grupo que utiliza a los MIS tradicionales. En ocasiones se hace referencia a ellos como sistemas que se enfocan en la inteligencia de negocios. 1.3.4. Sistemas de informacin ejecutiva Los sistemas de apoyo a ejecutivos (ESS, Executive Support Systems) ayudan a estos ltimos a organizar sus actividades relacionadas con el entorno externo ,mediante herramientas grficas y de comunicaciones, que por lo general se encuentran en salas de juntas o en oficinas corporativas personales. A pesar de que los ESS dependen de la informacin producida por los TPS y los MIS, ayudan a los usuarios a resolver problemas de toma de decisiones no estructuradas, que no tienen una aplicacin especfica, mediante la creacin de un entorno que contribuye a pensar en problemas estratgicos de una manera bien informada. Los ESS amplan y apoyan las capacidades de los ejecutivos al darles la posibilidad de comprender sus entornos.

1.4. Concepto de Ingeniera de Software (IS)


La ingeniera de software es la aplicacin de un enfoque sistemtico, disciplinado y cuantificable al desarrollo, operacin y mantenimiento de software, es decir, es la aplicacin de la ingeniera al software. 1.4.1. Modelos y filosofas de desarrollo de software Los modelos de proceso prescriptivo fueron propuestos originalmente para poner orden en el caos del desarrollo del software. Estos modelos dan cierta estructura til al trabajo de ingeniera de software y constituyen un mapa razonablemente eficaz para los equipos de software. 1.4.1.1. Modelo en cascada Tambin llamado ciclo de vida clsico, sugiere un enfoque sistemtico y secuencial para el desarrollo del software, que comienza con la especificacin de los requerimientos por parte del cliente y avanza a travs de planeacin, modelado, construccin y despliegue, para concluir con el apoyo del software terminado. El modelo de la cascada es el paradigma ms antiguo de

la ingeniera del software, ltimamente se ha cuestionado su eficacia, ya que surgen problemas al aplicar este modelo, como: 1. Es raro que los proyectos reales sigan el flujo secuencial propuesto por el modelo. Como resultado, los cambios generan confusin conforme se avanza con el proyecto. Es difcil para el cliente enunciar en forma explcita todos los requerimientos. El cliente debe tener paciencia. No dispondr de una versin funcional del programa hasta que el proyecto est muy avanzado.

2. 3.

1.4.1.2. Modelo de prototipos Pertenece a los modelos de proceso evolutivo, estos modelos son iterativos. Se caracterizan por la manera en la que permiten desarrollar versiones cada vez ms completas del software. El paradigma de hacer prototipos comienza con comunicacin. Se renen todos los participantes para definir los objetivos generales del software, identificar los requerimientos y detectar las reas en las que es imprescindible una mayor definicin. Se plantea rpidamente una iteracin para hacer el prototipo, y se lleva a cabo el modelado (en forma de diseo rpido), ste se entrega y es evaluado por los participantes, que dan retroalimentacin para mejorar los requerimientos. No obstante, hacer prototipos llega a ser problemtico por las siguientes razones: 1. Los participantes ven los que parece una versin funcional del software, sin darse cuenta de que el prototipo se obtuvo de manera caprichosa, no perciben que en la prisa por hacer que funcionara, no se consider la calidad general del software o la facilidad de darle mantenimiento a largo plazo. Como ingeniero de software, es frecuente que llegue a compromisos respecto de la implementacin a fin de hacer que el prototipo funcione rpido.

2.

Aunque puede haber problemas, hacer prototipos es un paradigma eficaz para la ingeniera de software, todos los participantes deben de estar de acuerdo en que el prototipo servir como el mecanismo para definir los requerimientos. 1.4.1.3. Modelo en espiral Es un modelo evolutivo del proceso del software y se acopla con la naturaleza iterativa de hacer prototipos con los aspectos controlados y sistmicos del modelo de cascada. Tiene el potencial para hacer un desarrollo rpido de versiones ms completas. Con el empleo del modelo en espiral, el software se desarrolla en una serie de entregas evolutivas. Durante las primeras iteraciones, lo que se entrega puede ser un modelo o prototipo. En las iteraciones posteriores se producen versiones cada vez ms completas del sistema cuya ingeniera se est haciendo. Pero, como otros paradigmas, el modelo en espiral tiene sus desventajas. Es difcil convences a los clientes de que el enfoque evolutivo es controlable. Demanda mucha

experiencia en la evaluacin del riesgo y se basa en ella para llegar al xito. No hay duda de que habr problemas si algn riesgo importante no se descubre y administra. 1.4.1.4. Desarrollo por etapas Es similar al modelo de prototipos, ya que se muestra al cliente el software en diferentes estados sucesivos de desarrollo, se diferencia en que las especificaciones no son conocidas en detalle al inicio del proyecto y por lo tanto se van desarrollando simultneamente con las diferentes versiones del cdigo. Pueden distinguirse las siguientes fases: Especificacin conceptual. Anlisis de requisitos. Diseo inicial. Diseo detallado, codificacin, depuracin y liberacin.

Estas diferentes fases se van repitiendo en cada etapa del diseo. 1.4.1.5. Modelo iterativo e incremental Este modelo combina elementos del modelo en cascada aplicado en forma iterativa. El modelo incremental aplica secuencias lineales de manera escalonada conforme avanza el tiempo en el calendario. Cada secuencia lineal produce incrementos del software, es decir, se le van aadiendo nuevas caractersticas o funciones. A menudo, al utilizar un modelo incremental el primer incremento es un producto esencial. Es decir, se incorporan los requisitos bsicos, pero muchas caractersticas suplementarias no se incorporan. El producto esencial queda en manos del cliente para su evaluacin. Como resultado de la evaluacin se desarrolla un plan para el incremento siguiente. Este proceso se repite despus de la entrega de cada incremento mientras no se haya elaborado el producto completo. El modelo de proceso incremental, al igual que la construccin de prototipos y otros enfoques evolutivos, es iterativo por naturaleza. Pero a diferencia de los prototipos, el modelo incremental se enfoca en la entrega de un producto operacional con cada incremento. Los primeros incrementos son versiones incompletas del producto final, pero proporcionan al usuario la funcionalidad que necesita y una plataforma para evaluarlo. 1.4.1.6. Desarrollo concurrente Tambin llamado ingeniera concurrente, permite que un equipo de software represente elementos iterativos y concurrentes de los modelos anteriormente descritos. Por ejemplo, la actividad de modelado definida para el modelo en espiral se logra por medio de invocar una o ms de las siguientes acciones de software: hacer prototipos, anlisis y diseo. Todas las actividades de ingeniera de software existen de manera concurrente, pero se hallan en diferentes estados. Por ejemplo, la actividad de comunicacin termina su primera iteracin al principio de un proyecto y existe en el estado de cambios en espera. La actividad de modelado exista en estado inactivo mientras conclua la comunicacin inicial, ahora hace una transicin al estado en desarrollo. Sin embargo, si el cliente indica que deben hacerse cambios

en los requerimientos, la actividad de modelado pasa de en desarrollo al de cambios en espera. El modelado concurrente es aplicable a todos los tipos de desarrollo de software y proporciona un panorama apropiado del estado actual del proyecto, en lugar de confinar las actividades, acciones y tareas de ingeniera de software a una secuencia de eventos, define una red del proceso. Cada actividad, accin o tarea de la red existe simultneamente con otras actividades, acciones o tareas. Los eventos generados en cierto punto de la red del proceso desencadenan transiciones entre los estados. 1.4.1.7. Proceso unificado El Proceso Unificado es un marco de trabajo genrico que puede especializarse para una gran variedad de sistemas software, para diferentes reas de aplicacin, diferentes tipos de organizaciones, diferentes niveles de aptitud y diferentes tamaos de proyecto. Est basado en componentes, lo cual quiere decir que el sistema software en construccin est formado por componentes software interconectados a travs de interfaces. El Proceso Unificado utiliza el Lenguaje Unificado de Modelado (Unified Modeling Language, UML) para preparar todos los esquemas de un sistema software. No obstante, los verdaderos aspectos definitorios del Proceso Unificado se resumen en tres fases clave: 1. Dirigido por casos de uso: Un sistema software est diseado para dar servicio a los usuarios. Por lo tanto, para construir un sistema con xito debemos conocer lo que sus futuros usuarios necesitan y desean. Aunque es cierto que los casos de uso guan el proceso, no se desarrollan aisladamente. Se desarrollan a la vez que la arquitectura del sistema. Por tanto, tanto la arquitectura del sistema como los casos de uso maduran segn avanza el ciclo de desarrollo. Centrado en la arquitectura: El concepto de arquitectura de software incluye los aspectos estticos y dinmicos ms significativos del sistema. La arquitectura surge de las necesidades de la empresa, como las perciben los usuarios y los inversores, y se refleja en los casos de uso. Sin embargo, tambin se influida por muchos otros factores, como la plataforma en la que tiene que funcionar el software (arquitectura hardware, sistema operativo, sistema de gestin de base de datos, protocolos para comunicacin en red), los bloques de construccin reutilizables de que se dispone, consideraciones de implantacin, sistemas heredados y requisitos no funcionales. La arquitectura es una vista des diseo completo con las caractersticas ms importantes resaltadas, dejando a un lado los detalles. Es iterativo e incremental: El desarrollo de un software supone un gran esfuerzo que puede durar entre varios meses hasta posiblemente un ao o ms. Es prctico dividir el trabajo en partes ms pequeas o mini proyectos. Cada mini proyecto es una iteracin que resulta en un incremento. Las iteraciones hacen referencia a pasos en el flujo de trabajo, y los

2.

3.

incrementos, al crecimiento del producto. Para una efectividad mxima, las iteraciones deben estar controladas, esto es, deben seleccionarse y ejecutarse de una forma planificada. Es por esto por lo que son mini proyectos. 1.4.1.8. RUP como modelo El Proceso Unificado de Rational (Rational Unified Process, RUP) es un proceso de desarrollo de software creado por la empresa Rational Software. Junto con el Lenguaje Unificado de Modelado (UML), constituye la metodologa estndar ms utilizada para el anlisis, diseo, implementacin y documentacin de sistemas orientados a objetos. Su meta principal es asegurar la produccin de software de alta calidad que cumpla con las necesidades de los usuarios, con una planeacin y presupuesto predecible.

1.5. Concepto de requerimiento (requeriments) en ingeniera de software


Normalmente, un tema de la Ingeniera de Software tiene diferentes significados, las siguientes definiciones aparecen en el glosario de la IEEE. 1. 2. Un requerimiento es una condicin o necesidad de un usuario para resolver un problema o alcanzar un objetivo. Una condicin o capacidad que debe estar presente en un sistema o componentes del sistema para satisfacer un contrato, estndar, especificacin u otro documento formal.

1.6. Enfoque orientado a objetos en SI


El enfoque orientado a objetos se centra en la elaboracin de clases de diseo que provienen tanto del dominio del problema como de la infraestructura. 1.6.1. Clases y objetos Una clase es una descripcin generalizada de una coleccin de objetos similares. Por definicin, los objetos son instancias de una clase especfica y heredan sus atributos y las operaciones que estn disponibles para manipular esos atributos. Una superclase (con frecuencia llamada clase base) es una generalizacin de un conjunto de clases que se relacionan con ella. Una subclase es una especializacin de la superclase. 1.6.2. Mtodos y atributos Los atributos se vinculan a las clases y describen la clase en alguna forma. Un atributo puede tomar un valor definido por un dominio numerado. En la mayora de los casos, un dominio es simplemente un conjunto de valores especficos. Los mtodos son funciones/procedimientos que acceden y/o modifican los atributos de un objeto.

1.6.3. Caractersticas Las caractersticas (valores de dominio) pueden aumentar al asignar un valor por defecto (caracterstica) a un atributo. 1.6.3.1. Encapsulamiento El encapsulamiento implica el tratamiento de un grupo de propiedades, mtodos y otros miembros como una nica unidad u objeto. Los objetos pueden controlar el modo en que se cambian las propiedades y se ejecutan los mtodos. Por ejemplo, un objeto puede validar valores antes de permitir cambios en propiedades. El encapsulamiento facilita tambin el cambio de implementacin posterior al permitir ocultar los detalles de implementacin de los objetos (ocultacin de informacin). 1.6.3.2. Polimorfismo El polimorfismo es una caracterstica que reduce enormemente el esfuerzo requerido para extender el diseo de un sistema orientado a objetos existente. Implica la posibilidad de tener varias clases que se pueden usar de forma intercambiable, incluso si cada clase implementa las mismas propiedades o mtodos de formas distintas. El polimorfismo es esencial para la programacin orientada a objetos, ya que permite usar elementos con los mismos nombres sin importar que objeto est en uso en ese momento. 1.6.3.3. Herencia La herencia es uno de los diferenciadores clave entre sistemas convencionales y orientados a objetos. Una subclase Y hereda todos los atributos y operaciones asociadas con su superclase X. Esto significa que todas las estructuras de datos y algoritmos originalmente diseados e implementados para X estn disponibles de inmediato para Y, no se necesita hacer ms trabajo. La reutilizacin se logra inmediatamente. Cualquier cambio a los atributos u operaciones contenidos dentro de una superclase se hereda inmediatamente a las subclases, adems de que se puede personalizar con propiedades y mtodos adicionales. 1.6.3.4. Abstraccin La abstraccin es un mtodo que est definido, pero no tiene cuerpo, es decir, se le declara el nombre, los parmetros y el tipo de devolucin pero no se le declara lo que va entre llaves {}, es ms, ni siquiera se le pone llaves.

1.7. Concepto de UML


El Lenguaje Unificado de Modelado (UML, Unified Modeling Language) es un lenguaje grfico para visualizar, especificar, construir y documentar los artefactos de un sistema con gran cantidad de software. UML proporciona una forma estndar de representar los planos de un sistema, y comprende tanto elementos conceptuales, como los procesos del negocio y las funciones del sistema, cuanto elementos concretos, como las clases escritas en un lenguaje de programacin especfico, esquemas de bases de datos y componente software reutilizables.

1.7.1. Definicin de RUP El Proceso Unificado de Rational (Rational Unified Process, RUP) es un proceso de desarrollo de software creado por la empresa Rational Software. Junto con el Lenguaje Unificado de Modelado (UML), constituye la metodologa estndar ms utilizada para el anlisis, diseo, implementacin y documentacin de sistemas orientados a objetos. Su meta principal es asegurar la produccin de software de alta calidad que cumpla con las necesidades de los usuarios, con una planeacin y presupuesto predecible. 1.7.2. Tipos de diagramas en UML Un diagrama es la representacin grfica de un conjunto de elementos, visualizado la mayora de veces como un grafo conexo de nodos (elementos) y arcos (relaciones). Los diagramas se dibujan para visualizar un sistema desde diferentes perspectivas, de forma que un diagrama es una proyeccin de un sistema. UML incluye trece tipos de diagramas: 1. 2. 3. 4. Diagrama de clases: muestra un conjunto de clases, interfaces y colaboraciones, as como sus relaciones. Diagrama de objetos: muestra un conjunto de objetos y sus relaciones. Diagrama de componentes: representa la encapsulacin de una clase, junto con sus interfaces, puertos y estructura interna. Diagrama de estructura compuesta: muestra la estructura interna de una clase y las colaboraciones que esta estructura hace posibles. Esto puede incluir partes internas, puertas mediante las cuales, las partes interactan con cada una de las otras o mediante las cuales, instancias de la clase interactan con las partes y con el mundo exterior, y conectores entre partes o puertas. Diagrama de casos de uso: muestra un conjunto de uso y actores (un tipo especial de clases) y sus relaciones. Diagrama de secuencia: muestra una interaccin, que consta de un conjunto de objetos o roles, incluyendo los mensajes que pueden ser enviados entre ellos. Diagrama de comunicacin: es un diagrama de interaccin que resalta la organizacin estructural de los objetos o roles que envan y reciben mensajes. Diagrama de estados: muestra una mquina de estados, que consta de estados, transiciones, eventos y actividades. Diagrama de actividades: muestra la estructura de un proceso u otra computacin como el flujo de control y datos paso a paso en la computacin. Diagrama de despliegue: muestra la configuracin de nodos de procesamiento en tiempo de ejecucin y los artefactos que residen en ellos. Diagrama de paquetes: muestra la descomposicin del propio modelo en unidades organizativas y sus dependencias.

5. 6.

7.

8. 9.

10. 11.

12.

13.

Diagrama de tiempos: es un diagrama de interaccin que muestra los tiempos reales entra diferentes objetos o roles, en oposicin a la simple secuencia relativa de mensajes. Diagrama de visin global de interacciones: es un hbrido entre un diagrama de actividades y un diagrama de secuencia.

1.7.3. Diagramas de estructura Los diagramas de estructura son representaciones grficas de la jerarqua existente entre los mdulos de un programa, y las estructuras de programacin utilizadas para controlar la operacin de esos mdulos. Cada mdulo se representa como un rectngulo. Los mdulos a su vez se pueden componer de otros, o ser mdulos primitivos. Un mdulo primitivo se encarga de desarrollar el procesamiento de los datos, mientras que un mdulo no primitivo se encarga de administrar a otros mdulos. 1.7.4. Diagramas de comportamiento Los diagramas de comportamiento de UML se emplean para visualizar, especificar, construir y documentar los aspectos dinmicos de un sistema. Se pueden ver los aspectos dinmicos de un sistema como aquellos que representan sus partes mutables, los aspectos dinmicos de un sistema software involucran cosas tales como el flujo de mensajes a lo largo del tiempo y el movimiento fsico de componentes en una red. Los diagramas de comportamiento de UML se organizan en: Diagramas de casos de uso. Diagramas de secuencia. Diagramas de comunicacin. Diagramas de estados. Diagramas de actividades. 1.7.5. Diagramas de interaccin Se utilizan para modelar los aspectos dinmicos de los sistemas. Un diagrama de interaccin muestra una interaccin, que consiste en un conjunto de objetos y sus relaciones, incluyendo los mensajes que se pueden enviar entre ellos. La mayora de las veces, esto implica modelar instancias concretas o prototpicas de clases, interfaces, componentes y nodos, junto con los mensajes enviados entre ellos. Los tipos de diagramas de interaccin son: Diagramas de secuencia. Diagramas de comunicacin.

1.8. RUP (Rational Unified Process)


El RUP (Proceso Unificado de Rational), es una metodologa que busca mejorar las prcticas que se implementan en el desarrollo de software, basndose en requerimiento comprobados a nivel comercial, y que, en el mbito de oferta y demanda actual cumpla con los requerimientos obtenidos. 1.8.1. Definicin de RUP El Proceso Unificado de Rational (Rational Unified Process, RUP) es un proceso de desarrollo de software creado por la empresa Rational Software. Junto con el Lenguaje Unificado de Modelado (UML), constituye la metodologa estndar ms utilizada para el anlisis, diseo, implementacin y documentacin de sistemas orientados a objetos. Su meta principal es asegurar la produccin de software de alta calidad que cumpla con las necesidades de los usuarios, con una planeacin y presupuesto predecible. 1.8.2. Principios de RUP Como filosofa RUP maneja 6 principios clave: 1. Adaptacin del proceso: El proceso deber adaprse a las caractersticas propias de la organizacin. El tamap del mismo, as como las regulaciones que lo condicionen, influirn en su diseo especifico. Tambin se deber tener en cuenta el alcance del proyecto. Balancear prioridades: Los requerimientos de los diversos clientes a los cuales se les realiza el proyecto, pueden ser diferentes, contradictorios o disputarse recursos limitados. Debe encontrarse un balance que satisfaga los deseos de todos. Colaboracin entre equipos: El desarrollo de software no lo hace una nica persona sino mltiples equipos. Debe haber una comunicacin fluida para coordinar requerimientos, desarrollo, evaluaciones, planes, resultados, etc. Demostrar valor iterativamente: Los proyectos se entregan aunque sea de un modo interno, en etapas iteradas. En cada iteracin se analiza la opinin de los inversores, la estabilidad y calidad del producto, y se refina la direccin del proyecto as como tambin los riesgos involucrados. Elevar el nivel de abstraccin: Este principio dominante motiva el uso de conceptos reutilizables tales como patrn del software, lenguajes 4GL o esquemas (frameworks) por nombrar algunos. Estos se pueden acompaar por las representaciones visuales de la arquitectura, por ejemplo con UML. Enfocarse en la calidad: El control de calidad no debe realizarse al final de cada iteracin, sino en todos los aspectos de la produccin.

2.

3.

4.

5.

6.

1.8.3. Ciclo de vida de RUP El ciclo de vida de RUP es una implementacin del desarrollo en espiral. Fue creado ensamblando los elementos en secuencias semiordenadas. El ciclo de vida organiza las tareas en fases e iteraciones.

1.8.4. Caractersticas de RUP Caractersticas esenciales que definen al RUP: Proceso dirigido por los casos de uso: Utiliza los casos de uso para el desenvolvimiento y desarrollo de las disciplinas con los artefactos, roles y actividades necesarias. Los casos de uso son la base para la implementacin de las fases y disciplinas del RUP. Proceso iterativo e incremental: Es el modelo utilizado por RUP para el desarrollo de un proyecto de software. Este modelo plantea la implementacin del proyecto a realizar en iteraciones, con lo cual se pueden definir objetivos por cumplir en cada iteracin y as poder ir completando todo el proyecto, iteracin por iteracin. Proceso centrado en la arquitectura: Define la arquitectura de un sistema, y una arquitectura ejecutable construida como un prototipo evolutivo. Arquitectura de un sistema es la organizacin o estructura de sus partes ms relevantes. Una arquitectura ejecutable es una implementacin parcial del sistema, construida para demostrar algunas funciones y propiedades. RUP establece refinamientos sucesivos de una arquitectura ejecutable, construida como un prototipo evolutivo. Alcance de la metodologa RUP: La metodologa RUP es ms apropiada para proyectos grandes, tambin pequeos, dado que requiere un equipo de trabajo capaz de administrar un proceso complejo en varias etapas. En proyectos pequeos, es posible que no se puedan cubrir los costos de dedicacin del equipo de profesionales necesarios. 1.8.5. Fases de RUP (Requisitos) Una fase es el intervalo de tiempo entre dos hitos importantes del proceso durante la cual se cumple un conjunto bien definido de objetivos, se completan artefactos y se toman las decisiones sobre si pasar a la siguiente fase. El RUP consta de las cuatro fases siguientes: 1. 2. 3. 4. Concepcin: Establecer la visin, el alcance y el plan inicial del proyecto. Elaboracin: Disear, implementar y probar una arquitectura correcta, y completar el plan del proyecto. Construccin: Construir la primera versin operativa del sistema. Transicin: Entregar el sistema a los usuarios finales.

1.8.6. Actividades del proceso de requerimientos de RUP Una actividad describe las tareas (pasos de concepcin, realizacin y revisin) que llevan a cabo los trabajadores para crear o modificar los artefactos, junto con las tcnicas y guas para ejecutar las tareas, incluyendo posiblemente el uso de herramientas para ayudar a automatizar algunas de ellas. Un artefacto es algn documento, informe o ejecutable que se produce, se manipula o se consume.

Cada actividad del Proceso Unificado de Rational lleva algunos artefactos asociados, bien sean requeridos como entradas, bien sean generados como salidas. Algunos artefactos se utilizan como entradas directas en las actividades siguientes, se mantienen como recurso de referencia en el proyecto, o se generan en algn formato especfico, en forma de entregables definidos en el contrato. 1.8.7. Plan de administracin de requerimientos, basado en RUP RUP describe como obtener los requerimientos, organizarlos, documentar requerimiento de funcionalidad y restricciones, rastrear y documentar decisiones, captar y comunicar requerimientos del negocio. Los casos de uso y los escenarios indicados por el proceso han probado ser una buena forma de captar requerimientos y guiar el diseo, la implementacin y las pruebas. Un requerimiento es una condicin o capacidad con el que un sistema debe conformarse. La administracin de requerimientos es una aproximacin sistemtica para la bsqueda, documentacin, organizacin y seguimientos de los cambios en los requerimientos de un sistema. El manejo de los requerimientos de software debe ser dinmico, debe esperarse que estos cambien durante la vida de un proyecto de software.

Fuentes:
E. KENDALL, KENNETH y E. KENDALL, JULIE, Anlisis y diseo de sistemas. Sexta edicin. PEARSON EDUCACIN, Mxico, 2005. S. PRESSMAN, ROGER, Ingeniera del software: un enfoque prctico, 6a ed. Mxico, D.F.: McGraw-Hill Interamericana, c2005 I. JACOBSON, G. BOOCH, J. RUMBAUGH, El proceso unificado de desarrollo de software. 1ra edicin. PEARSON EDUCATION, Madrid, 2000 GRADY BOOCH, El lenguaje unificado de modelado 2.0 PEARSON, Espaa, 2006.