MANUEL GARCA REYES

UNIDAD 3: MODULO DE

ANLISIS

INTRODUCCIN: El modelo de anlisis es la representacin tcnica de un sistema. Utiliza una mezcla de formato en texto y diagramas para representar los requisitos del software, las funciones y el comportamiento. De esta manera se hace mucho ms fcil de comprender dicha representacin, ya que es posible examinar los requisitos desde diferentes puntos de vista aumentando la probabilidad de encontrar errores de que surjan debilidades y de que se descubran descuidos. 3.1 ARQUITECTURA DE LAS CLASES: El modelo de anlisis tiene como objetivo generar una arquitectura de objetos que sirva como base para el diseo posterior del sistema. Como se discuti en la introduccin del libro, dependiendo del tipo de aplicacin existen diversas arquitecturas que se pueden utilizar, siendo de nuestro inters aquellas arquitecturas especialmente diseadas para el manejo de los sistemas de informacin, las cuales involucran ricas interfaces de usuario y accesos a base de datos como aspectos fundamentales de la arquitectura. En trmino de las propias arquitecturas, stas se distinguen segn la organizacin de la funcionalidad que ofrecen los objetos dentro de ellas o la dimensin de los objetos. Esta dimensin corresponde a los diferentes tipos de funcionalidad que manejan los objetos dentro la arquitectura. Por ejemplo, en el caso de funcionalidad para el manejo de interfaces y base de datos, si existen tipos distintos de objetos para el manejo de cada una de estas por separado, entonces se considera que la arquitectura es de dos dimensiones. Por el contrario, si todos los objetos manejan de manera indistinta los dos tipos de funcionalidades, entonces se considera que la arquitectura es de una sola dimensin. Si aplicamos el concepto de dimensin a los mtodos estructurados, podemos ver que estos consisten de dos dimensiones, correspondientes a funciones y datos. Las funciones representan un eje de comportamiento que no guarda informacin, mientras que los datos se ubican en un eje de informacin que no contiene comportamiento. En general, ejes de funcionalidad pueden corresponder a distintos tipos de funcionalidades, como se ve al contrastar funciones y datos versus manejo de interfaces y bases de datos. Sin embargo, la pregunta ms importante que uno se hace respecto al nmero y tipo de dimensiones es: Si se disea un sistema con mltiples dimensiones, se obtendra un sistema ms robusto y sensible a modificaciones? Ante todo esta pregunta se relaciona con el concepto de modularidad, siendo muy aceptado que cuanto mayor sea la modularidad de un sistema mayor es su robustez y extensibilidad. La respuesta particular a la pregunta tiene que ver con qu tan independiente sea un eje de funcionalidad del otro, ya que en el caso de los mtodos estructurados, usualmente se debe modificar las funciones cada vez que se modifica la estructura de informacin, lo cual no es algo deseable. Si logramos ejes de funcionalidad ortogonales, el efecto de cambios en una dimensin no debe afectar a las otras dimensiones. Y aunque estas dimensiones no son del todo ortogonales, si son lo suficientemente independientes se puede limitar el efecto de posibles cambios. En relacin al nmero de dimensiones, esto depende de la funcionalidad que la arquitectura

debe manejar, algo que a su vez depende del tipo de aplicacin que se est desarrollando. En el caso de los sistemas de informacin, uno de las tipos de arquitecturas ms importantes es la arquitectura MVC Modelo, Vista, Control (Model, View, Control) popularizada por los ambientes de desarrollo de Smalltalk. Esta arquitectura se basa en tres dimensiones principales: Modelo (informacin), Vista (presentacin) y Control (comportamiento) como se muestra en la Figura 7.2.

Figura 7.2 Diagrama de tres dimensiones correspondiente a la arquitectura MVC Modelo, Vista, Control. La vista o presentacin de la informacin corresponde a las interfaces que se le presentan al usuario para el manejo de la informacin, donde por lo general pueden existir mltiples vistas sobre un mismo modelo. Tpicamente la informacin representa el dominio del problema y es almacenada en una base de datos. Por otro lado el control corresponde a la manipulacin de la informacin a travs de sus diversas presentaciones. Y aunque existe cierta dependencia entre estas tres dimensiones se considera que la manera de presentar la informacin es independiente de la propia informacin y de cmo esta se controla. Sin embargo, cada una de ellas probablemente experimente cambios a lo largo de la vida del sistema, donde el control es el ms propenso a ser modificado, seguido de la vista y finalmente el modelo. En el modelo de anlisis descrito aqu utilizaremos como base la arquitectura MVC para capturar estos tres aspectos de la funcionalidad, como se muestra en la Figura 7.3. Es importante notar la correspondencia con las tres dimensiones utilizadas durante el modelo de requisitos. La razn de ser de las tres dimensiones del modelo de requisitos realmente se deriva para lograr una rastreabilidad con la arquitectura que se desarrollar en el modelo de anlisis.

Figura 7.3 Diagrama de tres dimensiones correspondiente a la arquitectura del modelo de anlisis basado en el modelo de casos de uso. La arquitectura para el modelo de anlisis ser implementada mediante tres tipos o estereotipos de objetos como elementos bsicos de desarrollo como veremos a continuacin. Clases con Estereotipos El tipo de funcionalidad o la razn de ser de un objeto dentro de una arquitectura se le conoce como su estereotipo. Para los sistemas de informacin la arquitectura del sistema segn nuestro modelo de anlisis se basa en tres estereotipos bsicos de objetos:

El estereotipo entidad para objetos que guarden informacin sobre el estado interno del sistema, a corto y largo plazo, correspondiente al dominio del problema. Todo comportamiento naturalmente acoplado con esta informacin tambin se incluye en los objeto entidad. Un ejemplo de un objeto entidad es un registro de usuario con sus datos y comportamiento asociados.

El estereotipo interface para objetos que implementen la presentacin o vista correspondiente a las interfaces del sistema hacia el mundo externo, para todo tipo de actores, no slo usuarios humanos. Un ejemplo de un objeto interface es la funcionalidad de interface de usuario para insertar o modificar informacin sobre el registro de usuario.

El estereotipo control para objetos que implementen el comportamiento o control especificando cuando y como el sistema cambia de estado, correspondiente a los casos de uso. Los objetos control modelan funcionalidad que no se liga naturalmente con ningn otro tipo de objeto, como el comportamiento que opera en varios objetos entidad a la vez, por ejemplo, hacer alguna computacin y luego devolver el resultado a un objeto interface. Un ejemplo tpico de objeto control es analizar el uso del sistema por parte de algn usuario registrado y presentar tal informacin posteriormente. Este comportamiento no le pertenece a ningn objeto entidad u objeto interface especfico. Ntese que no hay ninguna restriccin a los diferentes estereotipos que puedan utilizarse, no solamente las tres anteriores. La notacin de UML para un estereotipo se muestra en la Figura 7.4.

<< estereotipo >> Nombre de la Clase

Figura 7.4 Diagrama de clase con estereotipo. Los tres estereotipos correspondientes a las tres dimensiones para la arquitectura del modelo de anlisis se muestran en la Figura 7.5.

Figura 7.5 Diagrama de clase para los tres estereotipo. Considerando que habr interaccin entre los diferentes tipos de objetos, existir cierto traslape en la funcionalidad que los objetos ofrecen. Como se mencion anteriormente, este traslape deber minimizarse para asegurar una buena extensibilidad, donde tpicamente, cada tipo de objeto captura por lo menos dos de las tres dimensiones. Sin embargo, cada uno de ellos tiene cierta inclinacin hacia una de estas dos dimensiones, como se muestra en la Figura 7.6.

Figura 7.6 Diagrama mostrando traslape en los estereotipos de los objetos. Clases para Casos de Uso Cuando se trabaja en el desarrollo del modelo de anlisis, normalmente se trabaja con un caso de uso a la vez. Para cada caso de uso se identifican los objetos necesarios para su implementacin. Se identifican estos objetos segn sus estereotipos para corresponder a la funcionalidad ofrecida en cada caso de uso. Se define explcitamente qu objeto es responsable de cual comportamiento dentro del caso de uso. Tpicamente se toma un caso de uso y se comienza identificando los objetos interface necesarios, continuando con los objetos entidad y finalmente los objetos control. Este proceso se contina a los dems casos de uso. Dado que los objetos son ortogonales a los casos de uso, en el sentido de que un objeto puede participar en varios casos de uso, este proceso es iterativo. Esto significa que cuando un conjunto de objetos ya existe, estos pueden modificarse para ajustarse al nuevo caso de uso. La meta es formar una arquitectura lo ms estable posible, reutilizando el mayor nmero de objetos posible. De tal manera, la descripcin original de los casos de uso se transforma a una descripcin en base a los tres tipos de objetos, como se muestra en la Figura 7.7.

Figura 7.7 La funcionalidad de cada caso de uso es asignada a objetos distintos y de acuerdo a los estereotipos de dichos objetos. Se parte el caso de uso de acuerdo a los siguientes principios:

La funcionalidad de los casos de uso que depende directamente de la interaccin del sistema con el mundo externo se asigna a los objetos interface. La funcionalidad relacionada con el almacenamiento y manejo de informacin del dominio del problema se asigna a los objetos entidad. La funcionalidad especfica a uno o varios casos de uso y que no se ponen naturalmente en ningn objeto interface o entidad se asigna a los objetos control. Tpicamente se asigna a un slo objeto control y si ste se vuelve muy complejo se asignan objetos control adicionales. Por ejemplo, consideremos el caso de uso imprimir archivo, usado como ejemplo en el captulo 6 y que se muestra nuevamente en la Figura 7.8.

Figura 7.8 Caso de uso imprimir archivo. Para el caso de uso imprimir archivo se pueden utilizar los objetos (descritos segn el diagrama de clases correspondiente) que se muestran en la Figura 7.9. Se utilizan dos clases interface: Interface Archivo e Interface Impresora, cinco clases entidad: Cola, Archivo con sus subclases Archiv Texto, Archivo Formateado y Archivo Grfico y una clase control: Servidor Impresora.

Figura 7.9 Objetos identificados para el caso de uso imprimir archivo. La arquitectura se completa generando asociaciones entre las distintas clases como se muestra en la Figura 7.10.

Figura 7.10 Objetos identificados para el caso de uso imprimir archivo mostrando asociaciones entre si aunque omitiendo multiplicidad El desafo para generar esta correspondencia entre objetos o clases y los casos de uso es precisamente decidir cules y cuantos objetos deben utilizarse en dicha correspondencia. 3.2 IDENTIFICACIN DE CLASES SEGN ESTEREOTIPOS Para llevar a cabo la transicin del modelo de requisitos al modelo de anlisis se deben identificar los objetos necesarios para implementar todos los casos de uso. La arquitectura de objetos debe considerar los tres tipos de estereotipos de objetos. Para ello se deben identificar primero las clases borde, las clases entidad y finalmente las de Control. En general, los cambios ms comunes a un sistema son los de funcionalidad y bordes. Los cambios de las interfaces deben afectar solo a los objetos borde. Los cambios a la funcionalidad son ms difciles de administrar, ya que sta

puede abarcar todos los tipos de objetos. Bordes Toda la funcionalidad especificada en las descripciones de los casos de uso que depende directamente de los aspectos externos del sistema, se ubica en los objetos borde, pues a travs de ellos se comunican los actores con el sistema. La tarea de una clase borde es traducir los eventos generados por un actor en eventos comprendidos por el sistema, y traducir los eventos del sistema en una presentacin comprensible para el actor. Las clases borde en otras palabras, describen la comunicacin bidireccional entre el sistema y los actores. Las clases borde son bastante fciles de identificar, donde se cuenta con al menos tres estrategias: 1. Se pueden identificar con base a los actores. 2. Se pueden identificar con base en las descripciones de las interfaces del sistema que acompaan al modelo de requisitos. 3. Se pueden identificar con base en las descripciones de los casos de uso y extraer la funcionalidad especfica a los objetos bordes. Estrategia correspondiente a los actores. Cada actor necesita su propia clase borde para comunicarse con el sistema. En muchos casos un actor puede necesitar de varios objetos borde. Es evidente que los objetos borde no son totalmente independientes de cada uno, ya que, en ciertos casos deben saber la existencia de los dems. Entidad Se utilizan objetos entidad para modelar la informacin que el sistema debe manejar a corto y largo plazo. La informacin a corto plazo existe durante la ejecucin de un caso de uso, mientras que la informacin a largo plazo trasciende los caso de uso, por lo que es necesario guardarla en alguna base de datos o archivos. Durante la identificacin de objeto entidad, se encontrara que objetos que objetos similares aparecen en varios casos de uso. Clases entidad: Validar Usuario: Este casi de uso requiere validar informacin exclusivamente guardada en el registro de usuario, lo que se hace en la clase entidad Registro Usuario, utiliza tambin por el caso de uso Registro Usuario. Ofrecer Servicios: Este caso de uso administra las opciones de servicio y no requiere de ninguna clase entidad. Registrar Usuario: Este caso de uso requiere guardar informacin exclusivamente acerca del usuario, lo que se hace en la clase entidad Registro Usuario. Registrar Tarjeta: Este caso de uso requiere guardar informacin exclusivamente acerca de la tarjeta del usuario lo que hace en la clase entidad Registro Tarjeta. Consultar Informacin: Este casi de uso requiere de toda la informacin relacionada con consultas. Se puede tomar las clases del dominio del problema y quitar aquellas relacionadas con registros y reservaciones. Hacer reservacin: Este caso de uso requiere de la informacin relacionada con reservaciones. Se pueden tomar las clases del dominio del problema y quitar aquellas relacionadas con registros. Pagar Reservacin: Este caso de uso requiere de la informacin relacionada

con reservaciones. Dado que es una extensin al caso de uso Hacer Reservacin, no es necesario volver a repetir todas las clases entidad, sino ms bien especificar cualquier clase adicional. Control En la mayora de los casos de uso, existe un comportamiento que no se puede asignar de forma natural a ninguno de los otros dos tipos de objetos ya vistos. Una posibilidad es repartir el comportamiento entre los dos tipos de objetos, pero la solucin no es buena si se considera el aspecto de extensibilidad. Un cambio en el comportamiento podra afectar varios objetos, dificultando su modificacin. Para evitar estos problemas, tal comportamiento se asigna a objetos control. Es difcil lograr un buen balance en la distribucin del comportamiento del caso de uso entre los objetos entidad, borde y control. Los objetos de control normalmente proveen a administracin de los dems tipos de objetos. 3.3 CLASES Los objetos se representan y agrupan en clases que son ptimas para reutilizarse y darles mantenimiento. Una clase define el conjunto de atributos y comportamientos compartidos por cada objeto de la clase. Por ejemplo, los registros de los estudiantes en la seccin de un curso almacenan informacin similar para cada estudiante. Se podra decir que los estudiantes constituyen una clase. Los valores podran ser diferentes para cada estudiante, pero el tipo De informacin es el mismo. Los programadores deben definir las diversas clases en el programa que escriben. Cuando el programa corre, los objetos se pueden crear a partir de la clase establecida. El trmino instanciar se usa cuando un objeto se crea a partir de una clase. Por ejemplo, un programa podra instanciar a un estudiante llamado Peter Wellington como un objeto de la clase denominada estudiante.

Lo que hace a la programacin orientada a objetos, y por consiguiente al anlisis y diseo orientado a objetos, diferente de la programacin clsica, es la tcnica de poner todos los atributos y mtodos de un objeto en una estructura independiente, la propia clase. sta es una situacin comn en el mundo fsico. Por ejemplo, un paquete con harina para pastel empacado es similar a una clase ya que contiene los ingredientes y las instrucciones para mezclar y hornear el pastel. Un suter de lana es similar a una clase porque incluye una etiqueta con instrucciones del cuidado que advierten que se debe lavarlo a mano y ponerlo a Secar extendido. Cada clase debe tener un nombre que la distinga de todas las dems. Los nombres de clase normalmente son sustantivos o frases cortas y empiezan con una letra mayscula. En la figura 18.1 la clase se llama Renta Auto. En el UML, una clase se representa como un rectngulo. El rectngulo contiene otras dos caractersticas importantes: una lista de atributos y una serie de mtodos. Estos elementos describen una clase, la unidad de anlisis que es una parte principal de lo que llamamos anlisis y diseo orientado a objetos. Un atributo describe alguna propiedad de todos los objetos de la clase. Observe que la clase Renta Auto posee los atributos tamao, color, marca y

modelo. Todos los automviles poseen estos atributos, pero los atributos de cada automvil tendrn diferentes valores. Por ejemplo, un automvil puede ser azul, blanco o de algn otro color. Ms adelante demostraremos que es posible ser ms especfico acerca del rango de valores para estas propiedades. Al especificar atributos, normalmente la primera letra es minscula. Un mtodo es una accin que se puede solicitar a cualquier objeto de la clase. Los mtodos son los procesos que una clase sabe cmo realizar. Los mtodos tambin se llaman operaciones. La clase Renta Auto podra tener los siguientes mtodos: inicio Renta ( ), entrega Autof) y servicio ( ). Al especificar mtodos, normalmente la primera letra es minscula.

3.4 DIAGRAMA DE SECUENCIAS El Diagrama de Secuencia es uno de los diagramas ms efectivos para modelar interaccin entre objetos en un sistema. Un diagrama de secuencia se modela para cada caso de uso. Mientras que el diagrama de caso de uso permite el modelado de una vista 'business' del escenario, el diagrama de secuencia contiene detalles de implementacin del escenario, incluyendo los objetos y clases que se usan para implementar el escenario, y mensajes pasados entre los objetos. Tpicamente uno examina la descripcin de un caso de uso para determinar qu objetos son necesarios para la implementacin del escenario. Si tienes modelada la descripcin de cada caso de uso como una secuencia de varios pasos, entonces puedes "caminar sobre" esos pasos para descubrir qu objetos son necesarios para que se puedan seguir los pasos. Un diagrama de secuencia muestra los objetos que intervienen en el escenario con lneas discontinuas verticales, y los mensajes pasados entre los objetos como vectores horizontales. Los mensajes se dibujan cronolgicamente desde la parte superior del diagrama a la parte inferior; la distribucin horizontal de los objetos es arbitraria.

Figura 5: Diagrama de Secuencia para un escenario Durante el anlisis inicial, el modelador tpicamente coloca el nombre 'business' de un mensaje en la lnea del mensaje. Ms tarde, durante el diseo, el nombre 'business' es reemplazado con el nombre del mtodo que est siendo llamado por un objeto en el otro. El mtodo llamado, o invocado, pertenece a la definicin de la case instanciada por el objeto en la recepcin final del mensaje.

3.5 DICCIONARIO DE CLASES SEGN MDULOS. Esta es la ltima etapa del modelo de anlisis, en esta etapa se actualiza el diccionario de clases segn mdulos, originalmente descrito en el dominio del problema, aunque no es necesario ordenarlos por relevancia, a cada clase y caso de uso se le pueden asignar mdulos adicionales, que estos a su vez pueden tener otros mdulos o paquetes principales de importancia, estos ayudan a analizar de una mejor manera. Los diccionarios de datos proporcionan asistencia para asegurar significados comunes para los elementos y actividades del sistema. Si se examina una muestra de diagramas de flujo de datos para el procesamiento de pedidos, es probable que se tengan pocas dificultades para comprender qu datos representan a la factura y al cheque. Los dos son trminos comunes en el mundo de los negocios y muchas personas conocen su significado. Los diccionarios de datos registran detalles adicionales relacionados con el flujo de datos en el sistema de tal forma que todas las personas participantes puedan localizar con rapidez la descripcin de flujos de datos, almacenes de datos o procesos.

3.6 HERRAMIENTAS DE CASE PARA EL ANLISIS: 1. Borland Caliber Analyst

Se trata de un producto que est compuesto por dos aplicaciones desarrolladas por la compaa Borland. Por un lado est el Caliber DefineIT (la ltima de las herramientas en cuanto a fecha de lanzamiento) que permite definir los requisitos del sistema as como capturar los diferentes escenarios de negocio a travs de diferentes herramientas visuales; es necesario sealar que este software es compatible con gran nmero de herramientas existentes en el mercado. Por el otro est Caliber RM que nos permite gestionar dichos requisitos durante el ciclo de vida del producto, si bien no ayudaba al usuario a visualizar los requerimientos y por lo tanto no resultaba tan efectiva como ellos demandaban. El paquete que incluye ambas aplicaciones nos permitir realizar las siguientes tareas: representar y especificar los escenarios de manera visual, permitiendo el uso de un lenguaje comn; generar diagramas de casos de pruebas y UML, mejorando tanto la velocidad como la exactitud de la definicin de los requisitos; rastrear los requisitos software durante el ciclo de vida del proyecto, respondiendo de manera rpida a cualquier cambio que se produzca. La compaa Seilevel Inc., una de las ms fuertes en cuanto a los servicios relacionados con los requisitos del software, ha seleccionado esta herramienta como la mejor de este tipo. Segn palabras de un directivo de la compaa ven caractersticas nicas en esta herramienta as como una experiencia de usuario excelente y una oportunidad para mejorar el trabajo de sus clientes en cuanto al anlisis y gestin de requisitos se refiere. 2. CASE Spec

Esta herramienta est desarrollada por la empresa Goda Software, siendo esta una aplicacin comercial de uso exclusivo para el sistema operativo Windows. Las principales caractersticas que avalan a esta herramienta son las siguientes: Especificacin: posibilidad de realizar las especificaciones tanto con las tcnicas tradicionales como con los diagramas de casos de uso. Adems, nos permite crear diagramas UML y de flujo de datos.

Seguimiento de los requisitos: a travs del uso combinado de un procesador de textos y una hoja de clculo, el usuario ser capaz de realizar el seguimiento de los requisitos as como hacer un informe acerca de los mismos. Capacidad de rastreo: mediante la existencia de una matriz se representan de manera sencilla las diferentes relaciones existentes entre los requisitos definidos y otra serie de elementos incidentes en el proyecto. Capacidad de importar y exportar archivos. Generacin automtica de la documentacin del proyecto as como posibilidad de realizar amplios informes. 3. IRQA 4

Herramienta desarrollada por Visure y que tiene la meta de servir como aplicacin para proporcionar un soporte integral en la ingeniera de requisitos de un proyecto de informtica. A parte de incluir las tareas ms bsicas de la ingeniera de requisitos (captura, anlisis, modelado, organizacin y seguimiento), esta aplicacin dispones de las siguientes caractersticas: Reutilizacin de requisitos: permite que los requisitos definidos en un proyecto puedan ser utilizados en otros proyectos realizados por la organizacin, a travs del uso de libreras. De esta manera se consigue ofertar una pequea ventaja a la hora de realizar lneas de productos. Vista documental: esta nueva opcin ofrece un agrupamiento de los requisitos que permite al usuario observar una diferenciacin clara entre los mismos as como facilitar toda labor relacionada con estos. Ingeniera de requisitos: adems de la gestin de los requisitos, esta aplicacin proporciona funcionalidades relacionadas con la ingeniera de requisitos, lo que permite centralizar en una sola herramienta todas las actividades relacionadas con los requisitos (incluyendo las pruebas de validacin y aceptacin). Al ser esta una herramienta integrada, se ofrece al usuario la libertad de seleccionar aquellas otras aplicaciones ms adecuadas para la realizacin de otras tareas relacionadas con el ciclo de vida de un proyecto, lo que hace que no se dependa de un solo proveedor de aplicaciones. 4. Tiger Pro

Estamos ante una herramienta shareware desarrollada para facilitar al usuario la tarea de redactar los requerimientos de un proyecto. Este aplicativo es capaz de solucionar algunos de los defectos que aparecen a la hora de definir los requisitos de un programa. Tambin ayuda al usuario a aclarar algunos de los

requerimientos desde el punto de vista de las pruebas a realizar, sealando aquellos requerimientos cuya verificacin pueda resultar complicada. La herramienta, que se va actualizando con el paso del tiempo, permite exportar el trabajo realizado en archivos bajo el formato CSV. Los usuarios que utilicen esta herramienta podrn trabajar en los requisitos tomando como referencia los siguientes conceptos: palabras claves relacionadas con el mismo (hasta 3 palabras para cada requisito), criterio de aceptacin del requisito, seguimiento del mismo (tanto hacia la fuente como hacia otros lugares), prioridad del requerimiento, riesgo que trae consigo el requisito y coste del mismo. Adems, a la hora de realizar los informes correspondientes, la herramienta nos proporcionar la opcin de redactar los mismos en forma textual o bien nos presentar la informacin de forma grfica. 5. GatherSpace

A la hora de realizar la definicin de los requisitos para un proyecto de informtica, el trabajo conjunto de todo el equipo de desarrollo es una parte fundamental para conseguir un buen resultado. Esta herramienta de definicin y gestin de requisitos utiliza Internet como su lanzadera, ya que no es necesario instalar ningn programa para utilizarla: bastar con crear una cuenta en el sitio web de la misma y comenzar a definir el proyecto que se quiere desarrollar. De esta manera, la aplicacin consigue que la colaboracin de todos los miembros del grupo de desarrollo sea posible de una manera mucho ms eficaz. Las caractersticas ms representativas de esta herramienta son las siguientes: Creacin de una jerarqua de requerimientos: permite crear paquetes funcionales para despus relacionarlos con componentes de ms alto nivel para despus permitir asociar casos de uso ms detallados y requisitos del software a dichos componentes. Manipular varios proyectos al mismo tiempo, controlando el acceso de los usuarios para que estos puedan ver solo alguno de los proyectos. Posibilidad de visualizar la documentacin generada a partir de los requisitos en tres formatos diferentes: HTML, PDF y Microsoft Word. Adems de contar con todas estas opciones, la compaa ha dispuesto un buen sistema de seguridad que proteger los datos introducidos en la herramienta. Para asegurar la integridad del trabajo realizado se realizan copias de seguridad diaria de la informacin introducida en la herramienta y adems existe la posibilidad de encriptar los datos introducidos en la misma. Tambin es necesario sealar que el usuario podr descargarse la informacin desde el servidor de la empresa tantas veces como le sea necesario. 6. IBM Rational RequisitePro

Esta herramienta, desarrollada por una de las compaas ms importantes dentro del campo de la informtica, se considera una de las herramientas ms completas y potentes dentro del anlisis y la gestin de los requisitos.

Una de las grandes ventajas que aporta este producto es la compatibilidad existente entre su software y algunos de los programas ms utilizados. Por ejemplo, esta herramienta es capaz de comunicarse de manera muy eficiente con el Microsoft Word, de manera que la realizacin de los informes es ms sencilla al tiempo que se ofrece al usuario una interfaz conocida para el desarrollo de su labor. Adems de esta compatibilidad, el programa tambin se comunica con gran eficiencia con algunos de los sistemas de bases de datos ms utilizados en el mundo de la informtica (DB2 de IBM, Microsoft SQL Server, Microsoft Access y Oracle) de manera tal que se controla el acceso a los datos existentes en el sistema al tiempo que se tiene un repositorio central de datos. Por si esto no fuera suficiente, la comunicacin entre la base de datos utilizada y el Microsoft Word permite al usuario gestionar los requisitos desde la base de datos seleccionada al tiempo que estos se mantienen dentro de su contexto en el procesador de textos. Al igual que la herramienta estudiada anteriormente, Racional RequisitePro ofrece la posibilidad de trabajar mediante acceso Web. De esta manera se logra tener tanto un acceso remoto como un acceso distribuido y adems no se necesita que el software est instalado en el cliente. Tambin es necesario mencionar que la herramienta dispone de una matriz de seguimiento de los requisitos (al igual que la herramienta CASE Spec); en este caso, dicha matriz puede representarse tanto de forma grfica como de forma textual. Adems, en este caso se incorpora al seguimiento de los requisitos la existencia de un rbol de seguimiento global. 7. RaQuest Se trata de la herramienta de gestin de requisitos desarrollada por la empresa Sparx Systems, desarrolladora tambin de la herramienta de anlisis y modelado Enterprise Architect, utilizada en la Escuela. Las caractersticas principales de esta herramienta son las siguientes: Definicin y gestin de los elementos relacionados con los requisitos, entre los que se encuentran el tipo, el estado, la dificultad del requisito, las relaciones existentes entre diferentes requisitos, etc. Creacin de paquetes para gestionar de manera ms sencilla y completa los requisitos. Generacin de documentacin del proyecto (tanto parcial como total) en los siguientes formatos: HTML, CSV, Word, Excel, RTF Adems de estas caractersticas, la herramienta nos ofrece una serie de vistas diferentes, dependiendo de la vista que queramos obtener del proyecto. Estas vistas son: vista del tipo lista (permite ordenar los requisitos, mostrar diferentes listas, filtrar las listas en relacin a diferentes palabras y buscar en el proyecto) y vista del tipo rbol (se pueden mostrar los rboles de proyecto y miembro as como mostrar los rboles por el tipo y por el estado).

Eleccin de la Herramienta a Utilizar Debido a la gran compatibilidad existente con el Enterprise Architect, a la variedad de formatos para generar la documentacin y a las numerosas opciones existentes en cuanto al tipo de vistas y la definicin de los elementos relacionados con los requisitos, me he decantado por utilizar la herramienta RaQuest. Bibliografa books. (s.f.). Obtenido de books: http://books.google.com.mx/books?id=MOviEp0ApQcC&pg=PA254&lpg= PA254&dq=arquitectura+de+clases&source=bl&ots=OWzMnfQrcu&sig= v9SmNjXc0EsCwy4v9ycFhnGDWUA&hl=es&sa=X&ei=W8JpUdaZFMW g2QXfxYHYBA&ved=0CEoQ6AEwBg Kendall, K. &. (s.f.). anlisis de diseo y diseo de sistemas pg. 258- 259. mundokramer. (s.f.). Obtenido de mundokramer: http://mundokramer.wordpress.com/2011/05/20/modelo-de-analisissoftware/ slideshare. (s.f.). Obtenido de slideshare: http://www.slideshare.net/chiki.carito/modelado-del-anlisis