domingo, 5 de octubre de 2014

UNIDAD 2 INGENIERÍA DE REQUISITOS

2.1 Tareas de la ingeniería de requisitos


Se define como un conjunto de actividades en los cuales, utilizando técnicas y herramientas, se analiza un problema y se concluye con la especificación de una solución. La ingeniería de requisitos es el proceso de desarrollar una especificación de software.
 Inicio:
Tiene por objetivo identificar el ámbito del proyecto general. Comienza con una serie de conversaciones informales entre los participantes del mismo. Esta fase suele ser acompañada de los documentos de definición de la visión global y la visión del dominio del sistema. Se inicia muchas veces por: se descubre un nuevo mercado y se descubre un nuevo servicio.
 Obtención:
Se sugiere a los ingenieros recopilar requisitos de manera organizada, preguntando a los usuarios y otros interesados cuales son os objetivos para el sistema o producto, que es lo que se debe lograr, de que forma el producto satisface las necesidades del negocio y como se utilizara el producto día d día. Se identifican una serie de problemas que ayudan a entender porque es difícil la obtención de requisitos:
  1.  Problema de ámbito
  2. Problema de comprensión
  3.  Problemas de volatilidad

 Elaboración:
Se crea un modelo de análisis con la información obtenida del cliente en las fases de inicio y obtención. La información conseguida con el cliente durante el inicio y obtención se expande y se refina durante la elaboración. Esta actividad se enfoca en el desarrollo de un modelo técnico refinado de las funciones, características y restricciones del software. La elaboración se conduce mediante la creación y refinamiento de escenarios del usuario que describan la forma en que el usuario final y otros actores interactúan con el sistema.
Negociación:
En esta etapa el ingeniero de requisitos debe negociar con el cliente los alcances y límites del sistema. De forma iterativa los requisitos se prioriza, modifican, combinan o eliminan buscando acuerdos que beneficien a todas las partes. Se identifican y analizan los riesgos asociados con cada requisito.
 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. Una especificación puede ser un documento escrito, un conjunto de modelos gráficos, un modelo matemático formal, una colección de escenarios de uso, un prototipo o cualquier combinación de estos.
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 requisitos. La validación de requisitos examina la especificación para asegurar que todos los requisitos de software se han establecidos de manera precisa; que se han detectado las inconsistencias omisiones y errores y que estos han sido corregidos y que el producto de trabajo cumple con los estándares establecidos para el proceso, proyecto y producto.
 Gestión de requisitos:
Ayuda 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 afectara una modificación diferentes aspectos del sistema a construir. Es un conjunto de actividades que ayudan al equipo de proyecto a identificar, controlar y rastrear los requisitos y los cambios a estos en cualquier momento mientras se desarrolla el proyecto.







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 (Throwaway), 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 (JointApplicationDevelopment): 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.


Modelado de requisitos nos sirve y tiene como propósito comprender completamente el problema y todo lo que éste implica y conlleva. Su objetivo principal es delimitar el sistema y capturar la funcionalidad que debe ofrecer desde la perspectiva del usuario. Además el modelo de requisitos captura las principales características del sistema de software que se desea construir. Por medio de él representamos los requisitos del sistema de forma sencilla, para que de esta manera cualquier usuario pueda revisarlo y además entenderlo, sin necesidad de tener conocimientos previos al modelo e información. Intervienen en el los modelos de caso de uso, que desempeñan un papel importante de gran relevancia. En el estudio del modelo de requisitos se encuentran los funcionales y no funcionales. Cabe mencionar que los requisitos determinan lo que hará el sistema, es decir, como funcionará además, las restricciones sobre su operación e implementación. La e licitación, análisis y especificación de requisitos es el proceso del estudio de las necesidades de los usuarios para llegar a una definición de los requisitos del sistema. Un requisito es una condición o capacidad que necesita el usuario para resolver un problema o conseguir un objetivo determinado. Puede verse como una declaración abstracta de alto nivel de un servicio que el sistema debe proporcionar. Los requisitos funcionales: son la característica requerida del sistema que expresa una capacidad de acción del mismo, una funcionalidad; generalmente expresada en una declaración en forma verbal. No todo lo que necesitaremos en nuestro sistema es funcionalidad pura; por el contrario a veces se necesitan otras cualidades, si se quieren generalidades, que no son objeto decodificación si bien es cierto que pueden llegar a afectar a esta. Pueden ser frases muy generales sobre lo que el sistema debería hacer.

Los requisitos no funcionales pueden clasificarse en:

Requisitos del producto.
Requisitos organizacionales.
Requisitos externos.

Además existen los requisitos de usuarios que nos dice que el sistema debe permitir representar y acceder a archivos externos creados por otras herramientas.


2.4 HERRAMIENTAS CASE PARA LA INGENIERÍA DE REQUISITOS


El desarrollo de software ha ocupado un lugar importante en la Ingeniería, pero al igual que otras disciplinas, aún presenta fallas. Debido a esto se han planteado técnicas y métodos para minimizar los problemas identificados en la crisis del software. Es así como surge la Ingeniería de Software, presentando distintos modelos de procesos que se ajustan a las necesidades y proyectos requeridos. La mayoría de ellos involucran en sus fases iniciales tareas como planeación, levantamiento de información, determinación de las características que debe cumplir el software, agrupadas en lo que hoy se conoce como Ingeniería de Requisitos (IR). 

 IRQA 43
Herramienta CASE de Ingeniería de Requisitos, diseñada para soportar las actividades realizadas en elproceso 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 Mo- delo 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)4
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.

JEREMIA5
Se trata exclusivamente de una aplicación cliente exclusivamente, lo cual no permite la posibilidad de trabajar en equipo. Ésta, ayuda durante el desarrollo 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.

RAMBUTAN6
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.