lunes, 11 de marzo de 2013

2.1 TAREAS DE LA INGENIERIA DE REQUISITOS

En la ingeniería de sistemas y la ingeniería de software, la Ingeniería de requisitos o Ingeniería de requerimientos comprende todas las tareas relacionadas con la determinación de las necesidades o de las condiciones a satisfacer para un software nuevo o modificado, tomando en cuenta los diversos requisitos de los inversores, que pueden entrar en conflicto entre ellos.

Muchas veces se habla de requerimientos en vez de requisitos; esto se debe a una mala traducción del inglés. La palabra requirement debe ser traducida como requisito, mientras que requerimiento se traduce al inglés como request.
El propósito de la ingeniería de requisitos es hacer que los mismos alcancen un estado óptimo antes de alcanzar la fase de diseño en el proyecto. Los buenos requisitos deben ser medibles, comprobables, sin ambigüedades o contradicciones, etc.



Desde un punto de vista conceptual, las actividades son de cinco clases. Obtener requisitos: a través de entrevistas o comunicación con clientes o usuarios, para saber cuáles son sus expectativas. Analizar requisitos: detectar y corregir las falencias comunicativas, transformando los requisitos obtenidos de entrevistas y requisitos, en condiciones apropiadas para ser tratados en el diseño. Documentar requisitos: igual que todas las etapas, los requisitos deben estar debidamente documentados. Verificar los requisitos: consiste en comprobar el correcto funcionamiento de un requisito en la aplicación. Validar los requisitos: comprobar que los requisitos implementados se corresponden con lo que inicialmente se pretendía.

2.2 TECNICAS DE LA INGENIERIA DE REQUISITOS

Técnicas principales
La ingeniería de requisitos puede ser un proceso largo y arduo para el que se requiere de habilidades psicológicas. Los nuevos sistemas cambian el entorno y las relaciones entre la gente, así que es importante identificar a todos los actores involucrados, considerar sus necesidades y asegurar que entienden las implicaciones de los nuevos sistemas. Los analistas pueden emplear varias técnicas para obtener los requisitos del cliente. Históricamente, esto ha incluido técnicas tales como las entrevistas, o talleres con grupos para crear listas de requisitos. Técnicas más modernas incluyen los prototipos, y utilizan casos de uso. Cuando sea necesario, el analista empleará una combinación de estos métodos para establecer los requisitos exactos de las personas implicadas, para producir un sistema que resuelva las necesidades del negocio.

Entrevistas
Las entrevistas son un método común. Por lo general no se entrevista a toda la gente que se relacionará con el sistema, sino a una selección de personas que represente a todos los sectores críticos de la organización, con el énfasis puesto en los sectores más afectados o que harán un uso más frecuente del nuevo sistema. Los requisitos que surgen de las entrevistas a menudo se contradicen unos a otros o se formulan desde la ignorancia de los detalles del funcionamiento del sistema, sus potencialidades, interdependencias o limitaciones; por lo que se debe trabajar con los mismos para corregir sus fallos.Las entrevistas pueden ser personales o grupales.

 Talleres
Los requisitos tienen a menudo implicaciones cruzadas desconocidas para las personas implicadas individuales y que a menudo no se descubren en las entrevistas o quedan incompletamente definidas durante la misma. Estas implicaciones cruzadas pueden descubrirse realizando en un ambiente controlado, talleres facilitados por un analista del negocio, en donde las personas implicadas participan en discusiones para descubrir requisitos, analizan sus detalles y las implicaciones cruzadas. A menudo es útil la selección de un secretario dedicado a la documentación de la discusión, liberando al analista del negocio para centrarse en el proceso de la definición de los requisitos y para dirigir la discusión.

Forma de contrato
En lugar de una entrevista, se pueden llenar formularios o contratos indicando los requisitos. En sistemas muy complejos éstos pueden tener centenares de páginas.
Objetivos medibles
Los requisitos formulados por los usuarios se toman como objetivos generales, a largo plazo, y en cambio se los debe analizar una y otra vez desde el punto de vista del sistema hasta determinar los objetivos críticos del funcionamiento interno que luego darán forma a los comportamientos apreciables por el usuario. Luego, se establecen formas de medir el progreso en la construcción, para evaluar en cualquier momento qué tan avanzado se encuentra el proyecto.

Prototipos
Un prototipo es una pequeña muestra, de funcionalidad limitada, de cómo sería el producto final una vez terminado. Ayudan a conocer la opinión de los usuarios y rectificar algunos aspectos antes de llegar al producto terminado.

Casos de uso
Un caso de uso es una técnica para documentar posibles requisitos, graficando la relación del sistema con los usuarios u otros sistemas. Dado que el propio sistema aparece como una caja negra, y sólo se representa su interacción con entidades externas, permite omitir dichos aspectos y determinar los que realmente corresponden a las entidades externas. El objetivo de esta práctica es mejorar la comunicación entre los usuarios y los desarrolladores, mediante la prueba temprana de prototipos para minimizar cambios hacia el final del proyecto y reducir los costes finales.
Los prototipos pueden ser: diagramas, aplicaciones operativas con funcionalidades sintetizadas. Los diagramas, en los casos donde se espera que el software final tenga diseño gráfico, se realizan en una variedad de documentos de diseño gráficos y a menudo elimina todo el color del diseño del software (es decir utilizar una gama de grises). Esto ayuda a prevenir la confusión sobre la apariencia final de la aplicación.

2.3._ MODELADO DE REQUISITO

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.

Requisitos no funcionales
Los requisitos no funcionales detectados son los siguientes:
El entorno de desarrollo inicial del proyecto es un entorno LAMP (Linux+Apache+MySQL+ PHP), aunque este entorno debe de ser adaptable lo máximo posible. Específicamente, se deben de poder integrar en el futuro otras SGBD (Sistema de Gestión de Base de Datos) distintas a MySQL, y debe de ser independiente del sistema operativo y del servidor web a utilizar.
Siempre que haya alguno disponible, se debe de hacer uso de los estándares abiertos disponibles en el mercado, teniendo que validar el sistema resultante en el caso de que haya herramientas para hacerlo. Éste es el caso del código (X)HTML generado, que debe de estar validado mediante las herramientas que dispone el W3C.
Al manejar datos sensibles de personas físicas y jurídicas, la herramienta debe de tener en especial consideración el cumplimiento de la Ley de Retención de Datos durante su desarrollo.
La aplicación debe de ser multilingüe, debiendo de incorporar un sistema de traducción a varios idiomas basado en gettext.
El sistema utilizará una codificación de caracteres UTF-8.
Se utilizará un sistema de registro de todas las transacciones que se hagan en el sistema que garantice el uso legal de ésta información. Para ello, las transacciones deben de estar almacenadas en la base de datos y se debe de generar regularmente un fichero de logs, el cual debe de estar firmado con MD5.


2.4 HERRAMIENTAS CASE PARA LA INGENIERIA 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 iníciales 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 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 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.


Cita bibliográfica:



Elaboró: Zeferino Guerrero Hernández
Carrera: ing. En sistemas computacionales
Semestre y Grupo: 4to mod_1
Revisó: Ing. María Guadalupe Rivera Gracia