lunes, 11 de marzo de 2013

2.1 TAREAS DE INGENIERIA DE REQUERIMIENTOS


En el proceso de la ingeniería de requisitos se ejecutan las tareas de inicio, obtención, elaboración, negociación, especificación, validación y gestión.  Dichas funciones deben adaptarse a las necesidades y particularidades de cada proyecto.
Inicio: tiene por objetivo identificar el ámbito general del proyecto.  Comienza con una serie de conversaciones informales entre los participantes del mismo (cliente, usuarios, grupo de desarrollo).
Esta fase suele estar acompañada de los documentos de definición de la visión global y la visión de dominio del sistema.
Obtención: Sugiere a los ingenieros actividades de recopilación de requisitos de manera organizada.
Elaboración: Los ingenieros de software crean un modelo de análisis con la información obtenida del cliente en las fases de inicio y obtención.   El modelo de análisis define el dominio de la información, las funciones y el compartimiento del problema 
Negociación: Durante esta etapa el ingeniero de requisitos debe negociar con el cliente los alcances y limites del sistema.  De forma iterativa los requisitos se priorizan, modifican, combinan o eliminan buscando acuerdos que beneficien a todas las partes.
Especificación: Es el producto final de la ingeniería de requisitos, y se convierte en la materia prima para las actividades posteriores en el proceso de desarrollo del sistema.  La formalidad y especificación varían dependiendo de la complejidad del proyecto.
Validación: Un equipo de validación toma el producto de la fase de especialización, lo revisa para detectar errores, conflictos u omisiones y los corrige con el fin de garantizar la consistencia de los requisitos. 
Gestión de requisitos: Ayuda al equipo de proyecto a rastrear los requisitos según las características de los mismos, el código fuente relacionado, dependencia entre requisitos, subsistemas e interfaces internas y externas; de forma que pueda identificarse con rapidez para entender como afectará una modificación diferentes aspectos del sistema a construir. 

2.2 TÉCNICAS DE LA INGENIERÍA DE REQUISITOS



El proceso de Ingeniería de Requerimientos describe de manera  detallada  y precisa  cada uno de los aspectos del ciclo de vida de un conjunto de requerimientos. Este proceso presenta dos grandes ramas: Desarrollo de requerimientos. Administración  de requerimientos.
Que tiene como propósito producir y analizarlos requerimientos de cliente, de producto y de componente de producto, incluye las siguientes actividades: Recolección, Análisis, Especificación y Verificación. Recolección: Es el Proceso a través del cual los clientes (compradores y/o usuarios) y el desarrollador (contratista) de un sistema de software; descubren, revisan, articulan, y entienden las necesidades de los usuarios del sistema y las restricciones que se dan sobre el software y el desarrollo del mismo. Algunas de las técnicas y herramientas más importantes para llevar a cabo la recolección de requerimientos son: Entrevistas: método para descubrir hechos y opiniones que tienen los posibles usuarios y otros participantes dentro del sistema que se está desarrollando. A su vez se clasifican en:

Entrevistas cerradas: las preguntas ya están previstas, tienen un orden y una forma de ser planteadas que no pueden ser modificadas por el entrevistador. Es en realidad un cuestionario. 
Entrevistas abiertas: en las cuales no se preparan preguntas concretas, y, por el contrario, se discute con el entrevistado las expectativas que este tiene del sistema. 
Casos de Uso y/o Escenarios: Los casos de uso describen interacciones entre los usuarios y el sistema, enfatizando en lo que el usuario necesita del sistema. Los escenarios son ejemplos de sesiones de interacción entre el sistema y el usuario, donde un solo tipo de interacción entre los dos participantes es simulada y descrita. 
Observación y análisis social: La observación permite a los investigadores observar lo que los usuarios hacen actualmente en un determinado contexto. Esto permite superar problemas con los participantes del proyecto que realizan descripciones idealizadas o demasiado simplificadas de los procesos que se llevan a cabo en sus trabajos.
Lluvia de Ideas: Son sesiones donde todos los participantes brindan sus ideas para obtener una solución a una problemática. Una lluvia de ideas está compuesta de dos fases: la fase de generación y la fase de evaluación. Durante la generación las ideas son recolectadas y es importante que no sean criticadas. Durante la evaluación de las ideas, las propuestas de solución deben ser evaluadas desde diferentes perspectivas. 
Prototipos: Es programa de computador que implementa algunos de los requerimientos de un sistema. Este prototipo puede ser usado para colaborar con la definición de los requerimientos, o para facilitar la evaluación de alternativas de implementación de un sistema. 
Existen dos grandes tipos de prototipos. Los prototipos no funcionales o desechables (Throw away), que sirven para entender la dificultad y aclarar los requerimientos; y los prototipos funcionales o evolutivos (Evolutionary) que permiten construir una aproximación del sistema de manera que se pueda proveer cierta funcionalidad del sistema final y usualmente se convierten en parte del mismo. Análisis: Es el proceso de analizar las necesidades de los clientes y los usuarios   para llegar a una definición de los requerimientos de software. 

Dentro de las prácticas principales se encuentra: JAD (Joint Application Development): Esta práctica se basa en la creación de espacios que permitan celebrar sesiones o reuniones en donde los participantes y directos interesados dentro del desarrollo del proyecto buscan obtener o generar conocimiento alrededor del desarrollo que se va a llevar a cabo. En estas sesiones se trabaja bajo un enfoque común que permite el fácil entendimiento de los temas expuestos por parte de los invitados a la sesión

Modelos: Esquema teórico, generalmente en forma matemática, de un sistema o de una realidad compleja, como la evolución económica de un país, que se elabora para facilitar su comprensión y el estudio de su comportamiento. Existen dos tipos de modelos. - Modelo conceptual: Es el utilizado en la especificación del sistema, representa los conceptos más significativos en el dominio del problema…. Nos describe la parte estática del problema, es una fotografía del mundo real. - Modelo de Comportamiento: Utilizado en la parte de diseño del sistema, define la parte dinámica, es decir, cual debe ser el comportamiento en cada situación y la forma de proceder.
Los diagramas de secuencia y de estados son parte de este modelo. Especificación: Consiste en el desarrollo de un documento que de manera clara y precisa contenga y especifique cada uno de los requerimientos del sistema de software. Verificación: Es el proceso de asegurar que la especificación de requerimientos de software sea acorde con los requerimientos del sistema, conforme a los estándares de documentación de la fase de requerimientos, y que a su vez este documento sea una base sólida para la arquitectura y el diseño.

 Esta actividad representa un punto de control interno y externo; interno, porque se debe verificar internamente lo que se está haciendo, y externo, porque se debe validar con el cliente.

Administración de requerimientos: Es un proceso que tiene por objetivo comprender y controlar los requerimientos. Como todo proceso de administración, inicia con la planeación a la par de la identificación inicial de requerimientos. Este proceso tiene diferentes formas que dependen del proceso de desarrollo de software que se esté empleando, independientemente de esto se deben considerar las siguientes etapas:
 1. Requerimientos duraderos y volátiles. 
2. Planeación de la administración de requerimientos. 
3. Administración del cambio de los requerimientos.

2.3 MODELADO DE REQUISITOS


En esta sección se estudiaran los requisitos, tanto funcionales como no funcionales, que hay que cumplir para que el software funcione correctamente. Para ello se hará uso de los diagramas de caso de uso, que especifica los modos de uso (o requisitos funcionales) que va a tener el sistema, del diagrama de paquetes, que indica cómo se agrupan los casos de uso en diferentes subsistemas, y de los diagramas de secuencia, que indican el flujo a seguir en cada una de las transacciones.

Modelo funcional
En este apartado se muestran, mediante los diferentes casos de uso, los requisitos funcionales que tiene la aplicación, mostrándose también los diferentes subsistemas de la aplicación mediante el diagrama de paquetes.

Alta de Asociación
Caso de Uso: Alta de Asociación

 Usuario anónimo -  administrador de  la herramienta

Modificación de Asociación

Baja de Asociación

Listar Asociaciones

En primer lugar se  incluye los casos de uso que componen cada subsistema, mientras que el segundo diagrama de paquetes únicamente muestra los distintos subsistemas de la aplicación y su relación con los actores.

2.4. HERRAMIENTAS CASE PARA LA INGENIERÍA DE REQUISITO


Las herramientas para la gestión de requisitos de software se limitaban a editores de texto, los cuales hacían de esta tarea una labor tediosa y confusa. Actualmente, se cuenta con múltiples opciones, como las que se mencionan a continuación:

IRQA 43
Herramienta CASE de Ingeniería de Requisitos, diseñada para soportar las actividades realizadas en el proceso de especificación de sistemas. Ésta facilita y formaliza la comunicación entre el cliente, el proveedor y los distintos miembros del equipo de desarrollo.
Facilita la captura, organización y análisis de las condiciones, así como la especificación de la solución mediante el apoyo metodológico adaptable a cada cliente.

RETO
Esta herramienta propone un modelo de requisitos para capturar los aspectos funcionales del sistema; básicamente, mediante tres técnicas complementarias entre sí: la definición de la Misión del Sistema, la construcción del Árbol de Refinamiento de Funciones y el desarrollo del Modelo de Casos de Uso.
Además, se introduce un Proceso de Análisis que permite traducir el Modelo de Requisitos en el Modelo Conceptual, manteniendo la trazabilidad entre ambos y propiciando una representación de la información en el segundo prototipo.

CONTROLA
Herramienta de apoyo al proceso de ingeniería de software en pequeñas empresas. Se creó gracias a la expansión que tuvo el mercado y a la generación de grandes y pequeñas empresas, las cuales requieren un instrumento para el desarrollo de sus proyectos.
Ofrece recursos importantes tales como: Administración de requisitos, administración de casos de uso, administración de casos de prueba y error, planeamiento de liberaciones, administración de implementaciones, control de dependencia entre Implementaciones, matriz de rastreabilidad y rastreabilidad de los requisitos.

OSRMT (Open Source Requirements Management Tool)
Herramienta libre para la gestión de requisitos, cuyas principales características son: trabaja en arquitectura cliente/servidor, desarrollada bajo Java; la versión 1.3 trae un módulo para manejar la trazabilidad y lo introduce para el control de cambios; así mismo, genera la documentación de los requisitos tratados.

JEREMIA
Se trata exclusivamente de una aplicación cliente exclusivamente, lo cual no permite la posibilidad de trabajar en equipo. Ésta, ayuda durante el desarrollo del sistema, especialmente en el seguimiento de cambios de los requisitos a lo largo del ciclo de vida.
Con JEREMIA es posible captar las necesidades, analizarlas y clasificarlas. Implementa un módulo orientado a la generación de la documentación posible de exportar en formato DocBook XML, la cual junto con los requisitos, se almacena en una base de datos en MySQL.
RAMBUTAN
Esta herramienta está basada en XML, realmente consta de un conjunto de aplicaciones para el usuario final, ayudando a los analistas de sistemas en la recopilación y categorización de hechos en un documento de especificación de requisitos. Lo curioso es que tiene un cliente para palm (PDA), el cual se utiliza para recopilar los hechos en el lugar donde está ubicado el cliente mientras que la aplicación de escritorio recibe la información, edita y perfecciona.
Ambas aplicaciones permiten al usuario introducir, modificar y visualizar los datos que componen un documento de especificación de requisitos. Comparada con otras herramientas de gestión de requisitos, Rambutan ofrece las siguientes ventajas competitivas: Aplicación cliente para palm (PDAclass), portabilidad entre plataformas, es independiente de cualquier metodología de especificación de requisitos, y permite distribución libre.
Existen otras herramientas en estudios para la gestión de requisitos. A continuación se mencionan, algunas de las incluidas en el estudio comparativo presentado por El Consejo Internacional sobre la
Ingeniería de Sistemas (INCOSE)7: CaliberRM, REM,
SMART TRACE, SoftREQ, Analyst Real Team System.









BIBLIOGRAFIA
  


Francisca Coronel Hernandez
Ingenieria en Sistemas Computacionales
Modulo 1
 Ma.  Maria Guadalupe  Rivera  Garcia