PA2_U3_ Diferentes tareas y técnicas que se utilizan en la ingeniería de requisitos para el desarrollo de software

 “Ingeniería de requisitos”

La ingeniería de requisitos es el conjunto de actividades y tareas del proceso de desarrollo de sistemas software que tiene como objetivos:

 Definir, con la mejor calidad posible, las características de un sistema software que satisfaga las necesidades de negocio de clientes y usuarios y que se integre con éxito en el entorno en el que se explote. La definición de dicho sistema se realiza mediante lo que se conoce como una especificación de requisitos.

 Gestionar las líneas base y las peticiones de cambios que se vayan produciendo en la especificación de requisitos, manteniendo la trazabilidad entre los requisitos y otros productos del desarrollo.

“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: el descubrimiento de un nuevo mercado y 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 priorizan, 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.

“Técnicas de la ingeniería de requisitos”

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.

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

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.

 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. Esta técnica se enfrenta a los siguientes peligros potenciales.

o A los directivos, una vez que ven un prototipo, les cuesta comprender que queda mucho trabajo por hacer para completar el diseño final.

o Los diseñadores tienden a reutilizar el código de los prototipos por temor a “perder el tiempo” al comenzar otra vez.

o Los prototipos ayudan principalmente a las decisiones del diseño y de la interfaz de usuario. Sin embargo, no proporcionan explícitamente cuáles son los requisitos.

o Los diseñadores y los usuarios finales pueden centrarse demasiado en el diseño de la interfaz de usuario y demasiado poco en producir un sistema que sirva el proceso del negocio.