Semana_5_ Unidad_2_Tema_3_4 by gris rodriguez

Fundamentos de Ingeniería de Software

Educación a distancia

Ingeniería en Sistemas Computacionales Fundamentos de Ingeniería de Software

Semana 5. Unidad 2. Ingeniería de requisitos. 2.3. Modelado de requisitos 2.4 Herramientas CASE para la Ingeniería de requisitos.

Antología realizada por: M.C. Gricelda Rodríguez Robledo

Semana 5

Educación a distancia

Fundamentos de Ingeniería de Software

C ONTENIDO

Tema 2.3

Modelado de Requisitos......................................................................................................... 1

2.3.1 ¿Qué son los Casos de Uso? .......................................................................................................... 1 2.3.1.1 Los Casos de Uso y UML.......................................................................................................... 3 2.3.1.2 El Proceso de Ingeniería de Requerimientos con Casos de Uso ........................................... 10 2.4 Herramientas CASE para la Ingeniería de requisitos. ...................................................................... 12 2.4.1 Herramientas automatizadas para la Administración de Requerimientos .................................. 12 2.4.2 Herramientas automatizadas para la Administración de Requerimientos .................................. 13 2.4.2.1 Herramientas de la ingeniería de la información. ................................................................ 13 2.4.2.2 Modelado de procesos y herramientas de administración. ................................................ 13 2.4.2.3 Herramientas de planificación de proyectos. ....................................................................... 13 2.4.2.4 Herramientas de análisis de riesgos ..................................................................................... 14 2.4.2.5 Herramientas de administración de proyectos. ................................................................... 14 2.4.2.6 Herramientas de seguimiento de requisistos ....................................................................... 14 2.4.2.7 Herramientas de métricas y gestión. .................................................................................... 14 2.4.2.8 Herramientas de documentación ......................................................................................... 15 2.4.2.9 Herramientas de software de sistema. ................................................................................. 15 2.4.2.10 Herramientas de control de calidad. .................................................................................. 15 2.4.2.11 Herramientas de gestión como base de datos. .................................................................. 15 2.4.2.12 Herramientas de codificación de cuarta generación. ......................................................... 16 2.4.2.13 Herramientas de mantenimiento ....................................................................................... 16 2.4.2.14 Herramientas de gestión de configuración de software. ................................................... 16 2.4.2.15 Herramientas de análisis y diseño. ..................................................................................... 17 2.4.2.16 Herramientas pro/sim......................................................................................................... 17 2.4.2.15 Herramientas de desarrollo y diseño de interfaz. .............................................................. 17 2.4.2.16 Herramientas de generación de prototipos. ...................................................................... 17 2.4.2.17 Herramientas de programación. ......................................................................................... 18 i

Semana 5

Educación a distancia

Fundamentos de Ingeniería de Software

2.4.2.18 Herramientas de integración y comprobación. .................................................................. 18 2.4.2.19 Herramientas de análisis estático. ..................................................................................... 18 2.4.2.20 Herramientas de análisis dinámico. ................................................................................... 19 2.4.2.21 Herramientas de gestión de comprobación. ...................................................................... 19 2.4.2.22 Herramientas de comprobación clientes/servidor. ............................................................ 19 2.4.2.23 Herramientas DE reingeniería............................................................................................. 19 Referencias ............................................................................................................................................... 21

Semana 5

Fundamentos de Ingeniería de Software

Educación a distancia

Competencia específica a desarrollar Desarrollar las habilidades para identificar las diferentes técnicas que se aplican para la obtención de requerimientos de software. .

Intención didáctica.



Documentar en un caso de desarrollo las distintas tareas de la ingeniería de requerimientos.



Investigar y documentar sobre las distintas técnicas que se implementan dentro de las tareas de la ingeniería de requerimientos.



Desarrollar y aplicar las distintas técnicas para cada tarea dentro del caso propuesto a desarrollar.



Investigar sobre las aplicaciones del modelado y sus especificaciones. Aplicar al menos una herramienta CASE para la identificación de requerimientos.

Semana 4

iii

Fundamentos de Ingeniería de Software

Educación a distancia

T EMA 2.3 M ODELADO DE R EQUISITOS

2.3.1 ¿Q UÉ

SON LOS

C ASOS

U SO ?

Los casos de uso son una técnica para especificar el comportamiento de un sistema: "Un caso de uso es una secuencia de interacciones entre un sistema y alguien o algo que usa alguno de sus servicios." “La perspectiva que proporcionan los Casos de Uso refuerza el objetivo último de la Ingeniería del Software: la creación de productos que permitan a los clientes realizar un trabajo útil” (Wieger, 1997) Todo sistema de software ofrece a su entorno una serie de servicios. Un caso de uso es una forma de expresar cómo alguien o algo externo a un sistema lo usa. Cuando decimos "alguien o algo" hacemos referencia a que los sistemas son usados no sólo por personas, sino también por otros sistemas de hardware y software. Por ejemplo, un sistema de ventas, si pretende tener éxito, debe ofrecer un servicio para ingresar un nuevo pedido de un cliente. Cuando un usuario accede a este servicio, podemos decir que está "ejecutando" el caso de uso ingresando pedido. Los Casos de Uso son las funciones que proporciona un sistema para añadir valor a sus usuarios Especifican el comportamiento deseado del sistema No se especifica cómo se implementan Proporcionan un medio para que los desarrolladores, los usuarios finales y los expertos del dominio lleguen a una compresión común del sistema. Ayudan a validar la arquitectura y a verificar el sistema Conforme se desarrolla el sistema, los casos de uso son realizados por colaboraciones, cuyos elementos cooperan para realizar los casos de uso Los Casos de Uso fueron introducidos por Jacobson en 1992 [Jacobson92]. Sin embargo, la idea de especificar un sistema a partir de su interacción con el entorno es original de McMenamin y Palmer, dos precursores del análisis estructurado, que en 1984 definieron un concepto muy parecido al del caso de uso: el evento. Para McMenamin y Palmer, un evento es algo que ocurre fuera de los límites del sistema, ante lo cual el sistema debe responder. Siguiendo con nuestro ejemplo anterior, nuestro Semana 4

Fundamentos de Ingeniería de Software

Educación a distancia

sistema de ventas tendrá un evento "Cliente hace Pedido". En este caso el sistema deberá responder al estimulo que recibe.

Sin embargo, existen algunas diferencias entre los casos de uso y los eventos. Las principales son: Los eventos se centran en describir qué hace el sistema cuando el evento ocurre, mientras que los casos de uso se centran en describir cómo es el diálogo entre el usuario y el sistema. Los eventos son "atómicos": se recibe una entrada, se la procesa, y se genera una salida, mientras que los casos de uso se prolongan a lo largo del tiempo mientras dure la interacción del usuario con el sistema. De esta forma, un caso de uso puede agrupar a varios eventos. Para los eventos, lo importante es qué datos ingresan al sistema o salen de él cuando ocurre el evento (estos datos se llaman datos esenciales), mientras que para los casos de uso la importancia del detalle sobre la información que se intercambia es secundaria. Según esta técnica, ya habrá tiempo más adelante en el desarrollo del sistema para ocuparse de este tema. Los casos de uso combinan el concepto de evento del análisis estructurado con otra técnica de especificación de requerimientos bastante poco difundida: aquella que dice que una buena forma de expresar los requerimientos de un sistema es escribir su manual de usuario antes de construirlo. Esta técnica, si bien ganó pocos adeptos, se basa en un concepto muy interesante: al definir requerimientos, es importante describir al sistema desde el punto de vista de aquél que lo va a usar, y no desde el punto de vista del que lo va a construir. De esta forma, es más fácil validar que los requerimientos documentados son los verdaderos requerimientos de los usuarios, ya que éstos comprenderán fácilmente la forma en la que están expresados. Los casos de uso inician el proceso de desarrollo y lo enlazan

REQUISITOS

Semana 4

ANÁLISIS

DISEÑO

IMPLEMENTACION

PRUEBAS

Fundamentos de Ingeniería de Software

Educación a distancia

ƒLas Clases consisten en la descripción de los Casos Uso ƒ Las Interfaces de Usuario son la entrada del proceso de pruebas ƒLos Casos de Uso ayudan a los jefes de proyecto a planificar, asignar y controlar las tareas de desarrollo ƒ Se consideran a los Casos de uso un mecanismo importante para la trazabilidad de requisitos

2.3.1.1 L O S C A S OS

USO

UML

A partir de la publicación del libro de Jacobson, gran parte de los más reconocidos especialistas en métodos Orientados a Objetos coincidieron en considerar a los casos de uso como una excelente forma de especificar el comportamiento externo de un sistema. De esta forma, la notación de los casos de uso fue incorporada al lenguaje estándar de modelado UML (Unified Modeling Language) propuesto por Ivar Jacobson, James Rumbaugh y Grady Booch, tres de los precursores de las metodologías de Análisis y Diseño Orientado a Objetos, y avalado por las principales empresas que desarrollan software en el mundo. UML va en camino de convertirse en un estándar para modelado de sistemas de software de amplia difusión. A pesar de ser considerada una técnica de Análisis Orientado a Objetos, es importante destacar que los casos de uso poco tienen que ver con entender a un sistema como un conjunto de objetos que interactúan, que es la premisa básica del análisis orientado a objetos "clásico". En este sentido, el éxito de los casos de uso no hace más que dar la razón al análisis estructurado, que propone que la mejor forma de empezar a entender un sistema es a partir de los servicios o funciones que ofrece a su entorno, independientemente de los objetos que interactúan dentro del sistema para proveerlos. Como era de esperar, es probable que en el futuro los métodos de análisis y diseño que prevalezcan hayan adoptado las principales ventajas de todos los métodos disponibles en la actualidad (estructurados, métodos formales, métodos orientados a objetos, etc.). Definiciones y Notaciones

ACTORES Un actor es una agrupación uniforme de personas, sistemas o máquinas que interactúan con el sistema que estamos construyendo de la misma forma. Por ejemplo, para una empresa que recibe pedidos en forma telefónica, todos los operadores que reciban pedidos y los ingresen en un sistema de ventas, si pueden Semana 4

Educación a distancia

Fundamentos de Ingeniería de Software

hacer las mismas cosas con el sistema, son considerados un único actor: "Empleado de Ventas". Los actores son externos al sistema que vamos a desarrollar. Por lo tanto, al identificar actores estamos empezando a delimitar el sistema, y a definir su alcance. Definir el alcance del sistema debe ser el primer objetivo de todo analista, ya que un proyecto sin alcance definido nunca podrá alcanzar sus objetivos. Es importante tener clara la diferencia entre usuario y actor. Un actor es una clase de rol, mientras que un usuario es una persona que, cuando usa el sistema, asume un rol. De esta forma, un usuario puede acceder al sistema como distintos actores. La forma más simple de entender esto es pensar en perfiles de usuario de un sistema operativo. Una misma persona puede acceder al sistema con distintos perfiles, que le permiten hacer cosas distintas. Los perfiles son en este caso equivalentes a los actores. Otro sistema que interactúa con el que estamos construyendo también es un actor. Por ejemplo, si nuestro sistema deberá generar asientos contables para ser procesados por el sistema de contabilidad, este último sistema será un actor, que usa los servicios de nuestro sistema. También puede ocurrir que el actor sea una máquina, en el caso en que el software controle sus movimientos, o sea operado por una máquina. Por ejemplo, si estamos construyendo un sistema para mover el brazo de un robot, el hardware del robot será un actor, asumiendo que dentro de nuestro sistema están las rutinas de bajo nivel que controlan al hardware. Los actores se representan con dibujos simplificados de personas, llamados en inglés "stick man" (hombres de palo).

Si bien en UML los actores siempre se representan con "hombres de palo", a veces resulta útil representar a otros sistemas con alguna representación más clara.

Semana 4

Educación a distancia

Fundamentos de Ingeniería de Software

Las flechas, que existían en la propuesta original de Jacobson, pero que desaparecieron del modelo semántico de UML, pueden usarse para indicar el flujo de información entre el sistema y el actor. Si la flecha apunta desde el actor hacia el sistema, esto indica que el actor está ingresando información en el sistema. Si la flecha apunta desde el sistema hacia el actor, el sistema está generando información para el actor. Identificar a los actores es el primer paso para usar la técnica de casos de uso. Por ejemplo, en el sistema de pedidos nombrado anteriormente, sin conocer prácticamente ningún detalle sobre cómo funcionará, podemos decir que: El grupo de usuarios que ingrese pedidos al sistema será un actor. El grupo de usuarios que haga otras operaciones con los pedidos, como por ejemplo autorizarlos, cancelarlos y modificar sus plazos de entrega, será un actor. Todo grupo de usuarios que reciba ciertos informes del sistema, como por ejemplo estadísticas de ventas, será un actor. Es común que los distintos actores coincidan con distintas áreas de la empresa en la que se implementará el sistema, o con jerarquías dentro de la organización (empleado, supervisor y gerente son distintos actores, si realizan tareas distintas). Todos los actores participan de los casos de uso. Ahora bien, es lógico que existan intersecciones entre lo que hacen los distintos actores. Por ejemplo, un supervisor puede autorizar pedidos, pero también puede ingresarlos. Veremos más adelante cómo, definiendo actores abstractos, podemos especificar este comportamiento común para evitar redundancia.

C A SO S D E U S O Como mencionamos anteriormente, un caso de uso es una secuencia de interacciones entre un sistema y alguien o algo que usa alguno de sus servicios. Un caso de uso es iniciado por un actor. A partir de ese

Semana 4

Educación a distancia

Fundamentos de Ingeniería de Software

momento, ese actor, junto con otros actores, intercambian datos o control con el sistema, participando de ese caso de uso. El nombre de un caso de uso se expresa con un verbo en gerundio, seguido generalmente por el principal objeto o entidad del sistema que es afectado por el caso. Gráficamente, los casos de uso se representan con un óvalo, con el nombre del caso en su interior.

Es importante notar que el nombre del caso siempre está expresado desde el punto de vista del actor y no desde el punto de vista del sistema. Por eso el segundo caso de uso se llama "Recibiendo información de pedidos" y no "Generando información de pedidos". Los casos de uso tienen las siguientes características: Están expresados desde el punto de vista del actor. Se documentan con texto informal. Describen tanto lo que hace el actor como lo que hace el sistema cuando interactúa con él, aunque el énfasis está puesto en la interacción. Son iniciados por un único actor. Están acotados al uso de una determinada funcionalidad del sistema, claramente diferenciada. El último punto es tal vez el más difícil de definir. Uno podría, después de todo, decir que todo sistema tiene un único caso de uso denominado "Usando el Sistema". Sin embargo, la especificación resultante sería de poco utilidad para entenderlo; sería como implementar un gran sistema escribiendo un único programa. La pregunta importante es: ¿Qué es una "funcionalidad claramente diferenciada"? Por ejemplo, ¿ingresar pedidos es un caso de uso y autorizarlos es otro? ¿Cancelar los pedidos, es otro caso de uso, o es parte del caso de uso referido al ingreso de pedidos?

Semana 4

Educación a distancia

Fundamentos de Ingeniería de Software

Si bien se pueden encontrar argumentos válidos para cualquiera de las dos alternativas, en principio la respuesta a todas estas preguntas es que todos son casos de uso distintos. Lamentablemente, si en la programación los criterios para dividir la funcionalidad en programas suelen ser difusos, los criterios para dividir la funcionalidad de un sistema en casos de uso son aún más difusos, y por esto se hace importante usar el sentido común en estas decisiones. En principio, podríamos decir que la regla general es: una función del sistema es un caso de uso si se debe indicar explícitamente al sistema que uno quiere acceder a esa función. Por ejemplo, si uno quiere dar de alta un pedido, accederá a la funcionalidad de "alta de pedidos del sistema". Sin embargo, si uno quiere dar de alta un campo del pedido, no debe indicar al sistema que quiere acceder a esa función. Dar de alta un campo de un pedido es una función que forma parte de un caso de uso mayor: "dar de alta un pedido". Cuando pensamos en el grado de detalle de la división de los casos de uso también resulta útil imaginar que uno está escribiendo el manual del usuario del sistema. A nadie se le ocurriría escribir un manual de usuario con un solo capítulo en el que se describe toda su funcionalidad. De la misma forma, no se debe escribir una especificación con un solo caso de uso.

E X T E N SI O N E S (E X T E N D S ) Muchas veces, la funcionalidad de un caso de uso incluye un conjunto de pasos que ocurren sólo en algunas oportunidades. Supongamos que estamos especificando un sistema en el cual los clientes pueden ingresar pedidos interactivamente, y que dentro de la funcionalidad del ingreso de pedidos el usuario puede solicitar al sistema que le haga una presentación sobre los nuevos productos disponibles, sus características y sus precios. En este caso, tengo una excepción dentro del caso de uso "Ingresando Pedido". La excepción consiste en interrumpir el caso de uso y pasar a ejecutar el caso de uso "Revisando Presentación de Nuevos Productos". En este caso decimos que el caso de uso "Revisando Presentación de Nuevos Productos", extiende el caso de uso "Ingresando Pedido" y se representa por una línea de trazos desde el caso que ‘extiende a’ al caso que es ‘extendido’.

Semana 4

Educación a distancia

Fundamentos de Ingeniería de Software

Las extensiones tienen las siguientes características: Representan una parte de la funcionalidad del caso que no siempre ocurre. Son un caso de uso en sí mismas. No necesariamente provienen de un error o excepción.

U SO S (U SE S ) Es común que la misma funcionalidad del sistema sea accedida a partir de varios casos de uso. Por ejemplo, la funcionalidad de buscar un producto puede ser accedida desde el ingreso de pedidos, desde las consultas de productos, o desde los reportes de ventas por producto. ¿Cómo hago para no repetir el texto de esta funcionalidad en todos los casos de uso que la acceden? La respuesta es simple: sacando esta funcionalidad a un nuevo caso de uso, que es usado por los casos de los cuales fue sacada. Este tipo de relaciones se llama relaciones de uso y se representa por una línea punteada desde el caso que ‘usa a’ al caso que es ‘usado’. Decimos, por ejemplo, que el caso de uso "Obteniendo reporte de ventas por producto", usa al caso de uso "Buscando producto".

Este concepto no es novedoso, es simplemente el concepto de la subrutina o subprograma usado en un nivel más alto de abstracción. Las características de las relaciones de uso son: Aparecen como funcionalidad común, luego de haber especificado varios casos de uso. Los casos usados son casos de uso en sí mismos. El caso es usado siempre que el caso que lo usa es ejecutado. Esto marca la diferencia con las extensiones, que son opcionales.

ABSTRACCIÓN

Semana 4

Educación a distancia

Fundamentos de Ingeniería de Software

Al identificar relaciones de uso y extensión, puede ser que extraigamos casos de uso que son accedidos por varios actores. Por ejemplo, el caso de uso "buscando datos de producto" es accedido por muchos actores (el empleado de ventas que ingresa un pedido, el gerente que quiere obtener estadísticas por producto, el supervisor que quiere consultar la información de algún producto, etc.). Ahora bien, como el caso de uso nunca se ejecuta fuera del contexto de otro caso de uso, decimos que es un caso de uso abstracto. Lo llamamos abstracto porque no es implementable por sí mismo: sólo tiene sentido como parte de otros casos. De la misma forma, el actor que participa de este caso de uso, que reúne características comunes a todos los actores de los casos de uso que lo usan, es un actor abstracto. En nuestro ejemplo, podemos decir que tenemos un actor abstracto "Buscador de Datos de Producto". Los actores abstractos, entonces, son necesarios para no dejar sin actores a los casos de uso abstractos.

HERENCIA La duda ahora es cómo relacionar este actor abstracto con los actores concretos: los que sí existen en la realidad y ejecutan casos de uso concretos, como "ingresando pedido" y "obteniendo estadísticas de ventas". Para esto podemos usar el concepto de herencia, uno de los conceptos básicos de la orientación a objetos. Como todos los actores concretos también ejecutan el caso "buscando datos de producto", a través de la relación de uso, podemos decir que los actores concretos heredan al actor abstracto.

Semana 4

Fundamentos de Ingeniería de Software

Educación a distancia

La relación de herencia no necesariamente implica la existencia de un caso abstracto. Puede ocurrir que un actor ejecute todos los casos que ejecuta otro actor, y algunos más. En nuestro sistema, el supervisor de ventas puede hacer todo lo que hace el empleado de ventas, pero además puede autorizar pedidos. En este caso, podemos decir que el Supervisor de Ventas hereda al Empleado de Ventas, aunque el Empleado de Ventas no sea un actor abstracto. De esta forma, toda la funcionalidad que está habilitada para el Empleado de Ventas también lo está para el Supervisor.

2.3.1.2 E L P R O CE S O

DE INGENIERÍA DE

R E Q U E R I M I E NT O S

C ON

C A S OS

USO

A continuación, se describen los pasos a seguir para aplicar la técnica con casos de uso a la IR. Identificar los Actores Si la primera pregunta que un analista debe hacer a sus usuarios es ¿Para qué es este sistema?, la segunda es claramente ¿Para quiénes es este sistema? Como mencionamos al hablar sobre los actores, identificar a todos ellos es crítico para un buen análisis de requerimientos. Por lo tanto, antes de avanzar con los casos de uso, debo tratar de identificar todos los tipos de usuario diferentes que tiene el sistema. Si el sistema será implementado en una empresa, debo preguntar cuáles de las áreas afectadas usarán o actualizarán su información. A pesar de hacer una identificación inicial de los actores, también debo repetirla a medida que empiezo a describir los casos de uso, ya que al conocer más detalles del sistema, pueden aparecer nuevos tipos de usuarios.

I D E N T I F I C A R L O S P R I N C I P A L E S C A SO S D E U SO D E C AD A A C T O R El siguiente paso es enunciar los nombres de los principales casos de uso de cada uno de los actores que se identificaron en el paso anterior. No es necesario especificar cuáles son las acciones dentro del caso de uso. Tampoco debo preocuparme si no aparecen muchos casos, ya que existen técnicas para encontrar nuevos casos de uso a partir de los existentes.

IDENTIFICAR NUEVOS CASOS A PARTIR DE LOS EXISTENTES Uno de los principales errores que se pueden cometer al identificar requerimientos es algo que parece obvio, pero que muchas veces ocurre: ¡olvidarse de algún requerimiento! Como los requerimientos Semana 4

Educación a distancia

Fundamentos de Ingeniería de Software

están en la cabeza de los usuarios, el éxito de esta tarea depende de la habilidad del analista. Para ayudarnos a identificar nuevos casos de uso a partir de los casos existentes, podemos aplicar las mismas técnicas utilizadas para identificar eventos según el análisis estructurado. Algunas de las preguntas que debemos hacernos son: ¿Cuáles son las tareas de un actor? ¿Necesita el actor estar informado de ciertas ocurrencias del sistema? ¿Necesita el actor informar al sistema de cambios externos súbitos? ¿Proporciona el sistema el comportamiento correcto al negocio? ¿Pueden ser todos los requerimientos funcionales, desarrollados por los casos de uso? ¿Qué casos de uso soportarán y mantendrán al sistema? ¿Qué información debe ser modificada o creada?

DOCUMENTACIÓN DE CASOS DE USO Una vez que identificamos todos los casos de uso, empezamos a documentar sus pasos; este documento se crea para cada caso de uso, detallando lo que el sistema debe proporcionar al actor cuando el caso de uso es ejecutado. Esta tarea no es estrictamente secuencial de la anterior: es posible que, mientras empezamos a documentar los casos, sigamos buscando otros nuevos. Un contenido típico de un documento de caso de uso sería: Describir cómo comienza el caso de uso y cómo termina. Realizar un flujo normal de eventos. Realizar un flujo alterno de eventos. Detallar las excepciones al flujo de eventos.

DEFINIR PRIORIDADES Una vez documentados los casos de uso, es conveniente definir las prioridades de los distintos requerimientos, expresados como casos de uso. Para los escenarios claves y los casos de uso que serán analizados en su iteración, se debe: Representar la funcionalidad central de cada caso de uso. Cubrir varios aspectos de arquitectura. Poner bajo estrés un punto delicado de la arquitectura. Semana 4

Fundamentos de Ingeniería de Software

Educación a distancia

GRÁFICOS A UTILIZAR Dependiendo del tamaño del sistema, es probable que un único gráfico con todos los casos de uso nos quede chico. No olvidemos que los modelos gráficos son para aclarar el texto, y no para confundir. Si el gráfico de casos de uso es una maraña indescifrable, no está cumpliendo su objetivo. Por lo tanto, podemos usar las siguientes reglas para incluir gráficos de casos de uso dentro de la SRS. Un gráfico de casos de uso no debe mostrar más de 15 casos Si es necesario particionar el gráfico, debe hacerse por actor. La primera partición debe separar los casos centrales de los casos auxiliares, ya que probablemente les interesen a personas distintas. Si las relaciones de uso y las extensiones entran en el diagrama principal, sin dejar de cumplir con la regla 1, debo dejarlas ahí. Lo mismo se aplica a los actores abstractos. Si las relaciones de uso no entran en el diagrama principal, debo mostrarlas en gráficos teniendo en cuenta que siempre debo mostrar todos los casos de uso que usan a otro en un mismo diagrama. Si tengo un caso de uso que es usado por gran parte de los otros casos, como por ejemplo el caso de uso "Identificándose ante el sistema", debo evitar mostrarlo en el gráfico principal, ya que las flechas serán imposibles de organizar. Es probable que no haga falta mostrar esta relación de uso en un gráfico.

2.4

H ERRAMIENTAS CASE PARA LA I NGENIERÍA DE REQUISITOS .

2.4.1 H ERRAM IENTAS R EQUERIMIENTOS

AUTOMATI ZAD AS

PARA

A DMINISTRACIÓN

Hoy en día, la Ingeniería de Software cuenta con una serie de herramientas automatizadas destinadas a diferentes propósitos. Dentro de las herramientas CASE que sirven de apoyo a los procesos de Ingeniería de Software, están las especializadas en la administración de requisitos. Estas herramientas se concentran en capturar requerimientos, administrarlos y producir una especificación de requisitos. Las ventajas que nos proporcionan la herramientas automatizadas para IR son: Semana 4

Fundamentos de Ingeniería de Software

Educación a distancia 

Permiten un mayor control de proyectos complejos.



Permiten reducir costos y retrasos en la liberación de un proyecto.



Permiten una mayor comunicación en equipos de trabajo.



Ayudan a determinar la complejidad del proyecto y esfuerzos necesarios. Principales herramientas CASE del mercado y su uso

2.4.2 H ERRAM IENTAS R EQUERIMIENTOS

2.4.2.1 H E R R A M I E N T A S

AUTOMATI ZAD AS

PARA

A DMINISTRACIÓN

D E LA I N G E N I E R Í A D E LA I NF OR M A CI ÓN .

Estas herramientas CASE modelan la información de negocios cuando ésta se transfiere entre distintas entidades organizativas en el seno de una compañía. El objetivo primordial de las herramientas de esta categoría consiste en representar objetos de datos de negocios, sus relaciones, y ayuda a comprender mejor la forma en que fluyen estos objetos de datos entre distintas zonas de negocio en el seno de la compañía. Estas herramientas proporcionan una ayuda importante cuando se diseñan nuevas estrategias para los sistemas de información y cuando los métodos y sistemas no satisfacen las necesidades de la organización.

2.4.2.2 M OD E LA D O

D E P R O CE SO S Y HE R R A M I E N T A S D E A D M I NI ST R A CI Ó N .

Se utilizan para representar los elementos clave del proceso de modo que sea posible entenderlo mejor. Estas herramientas también pueden proporcionar vínculos con descripciones de procesos que ayuden a quienes estén implicados en el proceso de comprender las tareas que se requieren para llevar a cabo ese proceso. Las herramientas de administración de procesos pueden proporcionar vínculos con otras herramientas que proporcionen un apoyo para actividades de proceso ya definidas.

2.4.2.3 H E R R A M I E N T A S

D E P LA N I FI CA C I Ó N D E P R OY E CT O S .

Las herramientas de esta categoría se concentran en dos áreas primordiales: Estimación de esfuerzos de proyecto y de costes de software. Calculan el esfuerzo estimado, la duración del proyecto y el numero recomendado de personas. Planificación de proyectos. Capacitan al administrador para definir todas las áreas del proyecto (la estructura de desglose de tareas), para crear una red de tareas (normalmente empleando una entrada Semana 4

Fundamentos de Ingeniería de Software

Educación a distancia

gráfica), para representar las interdependencias entre tareas y para modelar la cantidad de paralelismo que sea posible para ese proyecto.

2.4.2.4 H E R R A M I E N T A S

D E A N Á LI SI S D E R I E S G O S

Las herramientas de análisis de riesgos capacitan al administrador el proyecto para construir una tabla de riesgos proporcionando una guía detallada en la identificación y análisis de riesgos.

2.4.2.5 H E R R A M I E N T A S

D E A D M I N I ST R A CI Ó N D E P R OY E CT O S .

La planificación del proyecto y el plan del proyecto deben seguirse y de monitorizarse de forma continua. Además, el gestor deberá de utilizar las herramientas que recojan métricas que en la última instancia proporcionen una indicación de la calidad el producto del software. Las herramientas de esta categoría suelen ser extensiones de herramientas de planificación de proyectos.

2.4.2.6 H E R R A M I E N T A S

D E SE G U I M I E NT O D E R E Q U I SI ST O S

Cuando se desarrollan grandes sistemas, el sistema proporcionado suele no satisfacer los requisitos especificados por el cliente. El objetivo de las herramientas de seguimiento de requisitos es proporcionar un enfoque sistemático para el aislamiento de requisitos, comenzando por las especificaciones del cliente. Las herramientas de trazado de requisitos típicos combinan una evaluación de textos por interacción humana, con un sistema de gestión de bases de datos que almacena y categoría todos y cada uno de los requisitos del sistema que se "analizan" a partir de las especificaciones originales.

2.4.2.7 H E R R A M I E N T A S

D E M É T R I C A S Y G E ST I ÓN .

Las métricas del software mejoran la capacidad del administrador para controlar y coordinar el proceso del software y la capacidad del ingeniero para mejorar la calidad del software que se produce. Las herramientas métricas actuales se centran en procesos, proyectos y características del producto. Las herramientas orientadas a la gestión capturan métricas especificas del proyecto (por ejemplo: LDC/personamos, defectos por punto de función) que proporcionan una indicación global de productividad o de calidad. Las herramientas orientadas técnicamente determinan métricas técnicas que proporcionan una mejor visión de la calidad del diseño o del código. Muchas de las herramientas métricas avanzadas mantiene una base de datos de medidas de medias de la industria.

Semana 4

Fundamentos de Ingeniería de Software

Educación a distancia

Basándose en características de proyectos y de productos proporcionados por el usuario, estas herramientas califican los números locales frente a los valore medios de la industria (y frente al rendimiento local anterior) y sugieren estrategias para llegar a mejoras. Estas herramientas utilizan un sistema experto para sugerir el orden en el que se debe llevar a cabo un proyecto.

2.4.2.8 H E R R A M I E N T A S

D E D O CU M E NT A CI ÓN

Las herramientas de producción de documentos y autoedición prestan su apoyo a casi todos los aspectos de la ingeniería del software, y representan una importante oportunidad de aprovechamiento para todos los desarrolladores del software. La mayor parte de las organizaciones dedicadas al desarrollo de software invierte una cantidad de tiempo considerable en el desarrollo de documentos, y en muchos casos el proceso de documentación en si resulta bastante deficiente. No es raro que una organización de desarrollo de software invierta hasta en un 20 o 30 pro ciento de su esfuerzo global de desarrollo de software en la documentación. Por esta razón, las herramientas de documentación suponen una oportunidad importante para mejorar la productividad.

2.4.2.9 H E R R A M I E N T A S

D E S OFT W A R E D E SI ST E M A .

CASE es una tecnología de estaciones de trabajo. Por tanto, el entorno CASE debe adaptase a un software de sistema en redes de alta calidad, al correo electrónico, a los boletines electrónicos y a otras capacidades de comunicaciones.

2.4.2.10 H E R R A M I E N T A S

D E C ON T R O L D E CA L I D A D .

La mayor parte de las herramientas CASE que afirman que tiene como principal interés el control de calidad son en realidad herramientas métricas que hace una auditoria del código fuente para determinar si es justa o no a ciertos estándares del lenguaje. Otras herramientas extraen métricas técnicas como base para medir la calidad del software que se esta construyendo.

2.4.2.11 H E R R A M I E N T A S

D E G E ST I Ó N C OM O B A S E D E D A T O S .

El software de gestión de bases de datos sirve como fundamentos para establecer una base de datos CASE. Dado el énfasis acerca de los objetos de configuración, las herramientas de gestión de bases de datos para CASE pueden evolucionar a partir de los sistemas de gestión de bases de datos relacionales (SGBDR) para transformarse en sistemas de gestión de bases de datos orientadas a objetos(SGBDOO).

Semana 4

Fundamentos de Ingeniería de Software

Educación a distancia 2.4.2.12 H E R R A M I E N T A S

D E C OD I F I C A CI Ó N D E C U A R T A G E NE R A CI ÓN .

Los sistemas de consulta de bases de datos, los generadores de código y los lenguajes de cuarta generación han cambiado la forma en que se desarrollan los sistemas. Idealmente, estas herramientas de generación de código no solo traducen la descripción de un sistema operativo, sino que también ayudan a verificar la corrección de la especificación del sistemas de tal forma que la salida resultante satisfaga los requisitos del usuario. Los lenguajes de cuarta generación se usan ampliamente en aplicaciones de sistemas de información. Aunque los lenguajes de cuarta generación, los generadores de código y los generadores de aplicaciones, permiten que un ingeniero de software especifique un sistema a un nivel muy alto de abstracción; cada una de estas herramientas difiere en aspectos importantes.

2.4.2.13 H E R R A M I E N T A S

D E M A N T E NI M I E NT O

Las herramientas CASE para el mantenimiento de software abarcan una actividad que actualmente ocupa, aproximadamente, el 70% del esfuerzo total dedicado al software. La categoría de herramientas de mantenimiento puede subdividirse de la siguiente forma: Herramientas de ingeniería inversa a especificaciones. Toman el código fuente como entrada y generan modelos de diseño y análisis estructurado, listas de utilización y otra información con el diseño. Herramientas de reestructuración y análisis de código. Analizan la sintaxis del programa, generan un grafo de flujo de control y un programa estructurado. Herramientas interactivas de reingeniería de sistema. Se utilizan para modificar sistemas de base de datos. Estas herramientas están limitadas a lenguajes de programación específicos y requieren cierto grado de interacción con el ingeniero de software.

2.4.2.14 H E R R A M I E N T A S

D E G E ST I Ó N D E CO N FI G U R A CI Ó N D E S OFT WA R E .

La gestión de configuración de software (GCS) se encuentra en el núcleo de todos los entornos CASE. Las herramientas pueden ofrecer su asistencia en las cinco tareas principales de GCS: identificación, control de versiones control de cambios, auditoria y contabilidad de estados. La base de datos CASE proporciona un mecanismo para identificar todos los elementos de configuración y relacionarlo con otros elementos; un acceso sencillo a los elementos de configuración individuales facilita el proceso de auditoria; las Semana 4

Fundamentos de Ingeniería de Software

Educación a distancia

herramientas de comunicación CASE pueden mejorar enormemente la contabilidad de estados (ofreciendo información acerca de los cambios a todos aquellos que necesiten conocerlos).

2.4.2.15 H E R R A M I E N T A S

D E A N Á LI SI S Y D I SE Ñ O .

Las herramientas de análisis y diseño capacitan al ingeniero del software para crear modelos del sistema que haya que construir. Los modelos contienen una representación de los datos, de la función y del comportamiento (en el nivel de análisis), así como caracterizaciones del diseño de datos, arquitectura, procedimientos e interfaz. Al efectuar una comprobación de la consistencia y validez del modelo, las herramientas de análisis y diseño proporcionan al ingeniero del software un cierto grado de visión en lo tocante a la representación del análisis, y le ayudan a eliminar errores antes de que se propaguen al diseño, o lo que es peor, a la propia implementación.

2.4.2.16 H E R R A M I E N T A S

P R O / SI M .

Las herramientas PRO/SIM (de prototipos y simulación) proporcionan al ingeniero del software la capacidad de predecir el comportamiento de un sistema en tiempo real antes de llegar a construirlo. Además, capacitan al ingeniero del software para desarrollar simulaciones del sistema de tiempo real que permitirán al cliente obtener ideas acerca de su funcionamiento, comportamiento y respuesta antes de la verdadera implementación.

2.4.2.15 H E R R A M I E N T A S

D E D E SA R R OL LO Y D I SE ÑO D E I N T E R F A Z .

Las herramientas de desarrollo y diseño de interfaz son en realidad un conjunto de primitivas de componente de programas tales como menús, botones, estructuras de ventanas, iconos, mecanismos de desplazamiento, controladores de dispositivos, etc., Sin embargo, estos conjuntos de herramientas se están viendo sustituidos por herramientas de generación de prototipos de interfaz que permiten una rápida creación en pantalla de sofisticadas interfaces de usuario, que se ajustan al estándar de interfaz que se haya adoptado para el software.

2.4.2.16 H E R R A M I E N T A S

D E G E N E R A CI ÓN D E P R OT OT I P OS .

Se puede utilizar toda una gama de herramientas de generación de prototipos. Los generadores de pantallas permiten al ingeniero de software definir rápidamente la disposición de pantalla para aplicaciones interactivas. Otras herramientas de prototipos CASE mas sofisticadas permiten la creación de un diseño de datos, acoplado con las disposiciones de la pantalla y de los informes simultáneamente. Muchas herramientas de análisis y diseño proporcionan extensiones que ofrecen alguna opción de generación de prototipos. Las herramientas PRO/SIM generan un esqueleto de código fuente en Ada y C Semana 4

Fundamentos de Ingeniería de Software

Educación a distancia

para las aplicaciones de ingeniería (en tiempo real). Por ultimo, una gama de herramientas de cuarta generación poseen también características de generación de prototipos.

2.4.2.17 H E R R A M I E N T A S

D E P R OG R A M A CI ÓN .

La categoría de herramientas de programación abarca los compiladores, editores y depuradores que están disponibles para prestar su apoyo en la mayoría de los lenguajes de programación convencionales. Además, los entornos de programación orientados a objetos (OO), los lenguajes de cuarta generación, los entornos de programación gráfica, los generadores de aplicaciones y los lenguajes de consulta de bases de datos residen también en esta categoría.

2.4.2.18 H E R R A M I E N T A S

D E I N T E G R A CI Ó N Y CO M P R O B A C I Ó N .

En su directorio de herramientas de comprobación de software, software Quality Engineering define las siguientes categorías de herramientas de comprobación: Adquisición de datos: herramientas que adquieren datos que se utilizaran durante la comprobación. Medida estática: herramientas que analizan el código fuente sin ejecutar casos de prueba. Medida dinámica: herramientas que analizan el código fuente durante la ejecución. Simulación: herramientas que simulan las funciones del hardware o de otros elementos externos. Administración de comprobaciones: herramientas que prestan su asistencia en la planificación, desarrollo y control de las comprobaciones. Herramientas de funcionalidad cruzada: se trata de herramientas que cruzan los limites de las categorías anteriores. Debería tenerse en cuenta que muchas de las herramientas de comprobación poseen características que abarcan dos o más de las categorías anteriores.

2.4.2.19 H E R R A M I E N T A S

D E A N Á LI SI S E ST Á T I C O .

Las herramientas de análisis estático prestan su asistencia al ingeniero del software a efectos de derivar casos prácticos. Se utilizan tres tipos distintos de herramientas estáticas de comprobación en la industria: herramientas de comprobación basadas en código, lenguajes de comprobación especializados, y herramientas de comprobación basadas en requisitos. Las herramientas de comprobación basadas en código admiten un código fuente (o PDL) como entrada y efectúan un cierto numero de análisis que can lugar a la generación de casos de prueba. Los lenguajes de comprobación especializados (por ejemplo: ATLAS) capacitan al ingeniero del software para escribir detalladas especificaciones de comprobación que Semana 4

Fundamentos de Ingeniería de Software

Educación a distancia

describirán todos los casos de prueba y la logística de su ejecución. Las herramientas de comprobación basadas en requisitos aíslan requisitos específicos del usuario y sugieren casos de prueba (o clases de comprobaciones) que ejerciten estos requisitos.

2.4.2.20 H E R R A M I E N T A S

D E A N Á LI SI S D I NÁ M I C O .

Las herramientas de análisis dinámico interactúan con un programa que se esté ejecutando, comprueban la cobertura de rutas, comprueban las afirmaciones acerca del valor de variables especificas y en general instrumentan el flujo de ejecución del programa. Las herramientas dinámicas pueden ser bien intrusivas, bien no intrusivas. Las herramientas intrusivas modifican el software que hay que comprobar mediante sondas que se insertan (instrucciones adicionales) y que efectúan las actividades mencionadas anteriormente. Las herramientas de comprobación no intrusivas utilizan un procesador hardware por separado que funciona en paralelo con el procesador que contenga el programa que se está comprobando.

2.4.2.21 H E R R A M I E N T A S

D E G E ST I Ó N D E COM P R OB A CI ÓN .

Las herramientas de gestión de comprobación se utilizan para comprobar y coordinar la comprobación de software para cada uno de los pasos principales de comprobación. Las herramientas de esta categoría administran y coordinan la comprobación de regresiones, efectúan comparaciones que determinan las diferencia s entre la salida real y la esperada, y efectúan comprobaciones por lotes de programas con interfaces interactivas entre hombre y maquina. Además de las funciones indicadas anteriormente, muchas herramientas de gestión de comprobaciones sirven también como controladores de comprobación genéricos. Un controlador de comprobación lee uno o mas casos de prueba de algún archivo de pruebas, da formato a los datos de prueba para que se ajusten a las necesidades del software que se esta probando, e invoca entonces al software que sea preciso comprobar.

2.4.2.22 H E R R A M I E N T A S

D E C OM P R OB A CI ÓN C LI E NT E S / SE R V I D O R .

El entorno C/S existe unas herramientas de comprobación especializadas que ejerciten la interfaz gráfica de usuario y los requisitos de comunicaciones en red para el cliente y el servidor.

2.4.2.23 H E R R A M I E N T A S DE

R E I N G E NI E R Í A .

La categoría de herramientas de reingeniería se pueden subdividir en las funciones siguientes:

Semana 4

Educación a distancia

Fundamentos de Ingeniería de Software

Herramientas de ingeniería inversa para producir especificaciones: se toma el código fuente como entrada y se generan modelos gráficos de análisis y diseño estructurados, listas de utilización y otras informaciones de diseño. Herramientas de reestructuración y análisis de código: se analiza la sintaxis del programa, se genera una gráfica de control de flujo y se genera automáticamente un programa estructurado. Herramientas de reingeniería para sistemas en línea: se utilizan para modificar sistemas de bases de datos en línea (por ejemplo: para convertir archivos IDMS o DB2 traduciéndolos a un formato de entidades y relaciones). Muchas de las herramientas anteriores están limitadas a lenguajes de programación específicos (aun cuando se abarcan la mayoría de los lenguajes principales) y requieren un cierto grado de interacción con un ingeniero del software. Las herramientas de ingeniería inversa y progresiva de la próxima generación harán un uso mucho mayor de técnicas de inteligencia artificial, aplicando una base de conocimientos que se a especifica del dominio de la aplicación (esto es, un conjunto de reglas de descomposición que se aplicarían a todos los programas de una cierta zona de aplicación tal como el control de fabricación o la aviónica). El componente de inteligencia artificial asistirá en la descomposición y reconstrucción del sistemas, pero seguirá requiriendo una interacción con un ingeniero de software a lo largo del ciclo de la reingeniería.

Semana 4

Educación a distancia

Fundamentos de Ingeniería de Software

R EFERENCIAS Senn, James A. (1992) "Análisis y Diseño de Sistemas de Información". Segunda Edición. McGraw Hill. Fowler, Martín (1999). "UML Gota a Gota". Primera edición. Addison Wesley Longman. Brackett, Jhon W.(1990) "Software Requirements". Software Engineering Institute Education Program – Carnegie Mellon University. Saiedian, H.; Dale, R. (1999) "Requirements Engineering: Making the connection between the software developer and customer". Department of Computer Science – University of Nebraska. Oberg, Roger (1998); Probasco Leslee; Ericsson, Maria. "Applying Requirements Management with Use Cases". Rational Software Corporation. Hofmann, Hubert. (1993) "Requirements Engineering". Institute for Informatics – University of Zurich. Object Management Group. (1999)"OMG Unified Modeling Language Specification". Malan, Ruth.(1999). "Functional Requirements and Use Cases". Hewlette-Packard Company. International Council of Systems Engineering. "INSIGTH – Requirements Sharing the Vision". Volumen 4. INCOSE. 2000. IEEE Task Force on Requirements Engineering. http://www.shu.ac.uk/tfre/web.links.html Software Engineering Resources by Roger S. Pressman & Associates Inc. http://www.rspa.com/spi/index.html Lizka Johany Herrera J.(s.f.) Ingeniería De Requerimientos de Software http://www.monografias.com/trabajos6/resof/resof2.shtml#teec

Semana 4