Unidad 2
Ingeniería de requisitos…
2.1.- TAREA DE LA INGENIERIA DE REQUISITOS…
La
Ingeniería de Requisitos (IR) cumple un papel primordial en el proceso
de producción de software, ya que se enfoca un área fundamental: la definición
de lo que se desea producir. Su principal tarea consiste en la
generación de especificaciones correctas que describan con claridad, sin
ambigüedades, en forma consistente y compacta, las necesidades de los usuarios
o clientes; de esta manera, se pretende minimizar los problemas relacionados
por la mala gestión de los requisitos en el desarrollo de sistemas.
- La Ingeniería de Requisitos ayuda a los ingenieros de software a entender mejor el problema en cuya solución trabajarán. Incluye el conjunto de tareas que conducen a comprender cuál será el impacto del software sobre el negocio, qué es lo que el cliente quiere y cómo interactuarán los usuarios finales con el software. [Pressman, 2006: 155]
- La Ingeniería de Requisitos es el proceso de desarrollar una especificación de software. Las especificaciones pretender comunicar las necesidades del sistema del cliente a los desarrolladores del sistema. [Sommerville, 2005: 82]
- La Ingeniería de Requisitos se define, como un conjunto de actividades en las cuales, utilizando técnicas y herramientas, se analiza un problema y se concluye con la especificación de una solución (a veces más de una). [Ortas 1997]
Actividades de la Ingeniería
de Requisitos:
- Extracción: Esta fase representa el comienzo de cada ciclo. Extracción es el nombre comúnmente dado a las actividades involucradas en el descubrimiento de los requisitos del sistema.
- Análisis: Sobre la base de la extracción realizada previamente, comienza esta fase en la cual se enfoca en descubrir problemas con los requisitos del sistema identificados hasta el momento.
- Especificación: En esta fase se documentan los requisitos acordados con el cliente, en un nivel apropiado de detalle.
- Validación: La validación es la etapa final de la IR. Su objetivo es, ratificar los requisitos, es decir, verificar todos los requisitos que aparecen en el documento especificado para asegurarse que representan una descripción, por lo menos, aceptable del sistema que se debe implementar. Esto implica verificar que los requisitos sean consistentes y que estén completos.
2.2.- TECNICAS DE INGENIERIA DE REQUISITOS
Los
requerimientos de software pueden dividirse en 2 categorías: requerimientos
funcionales y requerimientos no funcionales.
Los
requerimientos funcionales son los que definen las funciones que el sistema
será capaz de realizar, describen las transformaciones que el sistema realiza
sobre las entradas para producir salidas. Es importante que se describa el
¿Qué? y no el ¿Cómo? se deben hacer esas transformaciones. Estos requerimientos
al tiempo que avanza el proyecto de software se convierten en los algoritmos,
la lógica y gran parte del código del sistema.
Por otra
parte los requerimientos no funcionales tienen que ver con características que
de una u otra forma puedan limitar el sistema, como por ejemplo, el rendimiento
(en tiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema,
disponibilidad de equipo), mantenimiento, seguridad, portabilidad, estándares, etc.
Características
de un Requerimiento
Es
importante no perder de vista que un requerimiento debe ser:
Especificado por escrito: Como
todo contrato o acuerdo entre dos partes.
Posible de probar o verificar. Si un
requerimiento no se puede comprobar, entonces ¿cómo se sabe si se cumplió con
él o no?
Conciso: Un requerimiento es
conciso si es fácil de leer y entender. Su redacción debe ser simple y clara
para aquellos que vayan a consultarlo en un futuro.
Completo: Un requerimiento está
completo si no necesita ampliar detalles en su redacción, es decir, si se
proporciona la información suficiente para su comprensión.
Consistente: Un requerimiento es
consistente si no es contradictorio con otro requerimiento.
No ambiguo: Un requerimiento no
es ambiguo cuando tiene una sola interpretación. El lenguaje usado en su
definición, no debe causar confusiones al lector.
2.4
Dificultades para definir los requerimientos
Durante la
etapa de especificación de requerimientos se pueden presentar muchos inconvenientes
los cuales son importantes de identificar y prevenir, a continuación se
presenta un listado con los problemas más comunes en este proceso:
Los requerimientos no son obvios y vienen de
muchas fuentes.
Son difíciles de expresar en palabras (el lenguaje
es ambiguo).
La cantidad de requerimientos en un proyecto
puede ser difícil de manejar.
Un requerimiento puede cambiar a lo largo del
ciclo de desarrollo.
El usuario no puede explicar lo que hace
Tiende a recordar lo excepcional y olvidar lo
rutinario
Hablan de lo que no funciona
Los usuarios tienen distinto vocabulario que
los desarrolladores.
Usan el mismo término con distinto
significado
2.3.- MODELO DE REQUISITOS
El
modelo de requisitos tiene como objetivo delimitar el sistema y capturar la
funcionalidad que debe ofrecer desde la perspectiva del usuario. Este modelo
puede funcionar como un contrato entre el desarrollador y el cliente o usuario
del sistema, y por lo tanto proyecta lo que el cliente desea según la percepción
del desarrollador. Por lo tanto, es esencial que los clientes puedan comprender
este modelo.
Descripción
del Problema
La
descripción del problema es una descripción muy preliminar de necesidades que
sirve únicamente como punto de inicio para comprender los requisitos del
sistema. Se trata aquí de simular una descripción preparada por un cliente la
cual debe evolucionar por medio del modelo de requisitos para lograr la
especificación final del sistema a desarrollarse. La descripción del problema debe
ser una descripción de necesidades y no una propuesta para una solución. La
descripción inicial puede ser incompleta e informal. No hay razón para esperar
que la descripción inicial del problema, preparada sin un análisis completo,
sea correcta.
Modelo
de Casos de Uso
El modelo
de casos de uso describe un sistema en término de sus distintas formas de
utilización, cada uno de estas formas es conocida como un caso de uso.
Cada caso de uso o flujo se compone de una secuencia de eventos iniciada por el
usuario. Dado que los casos de uso describen el sistema a desarrollarse,
cambios en los requisitos significarán cambios en los casos de uso. Por
ejemplo, un caso de uso para manejar un automóvil sería la secuencia de eventos
desde que el conductor entra en el coche encendiendo el motor hasta llegar a su
destino final. Por lo tanto, para comprender los casos de uso de un sistema
primero es necesario saber quienes son sus usuarios.
Modelo
de Interfaces
El
modelo de interfaces describe la presentación de información entre los
actores y el sistema. Se especifica en detalle como se verán las interfaces de
usuario al ejecutar cada uno de los casos de uso. Si se trata de InterfazHumano
Computadora (“HCI - Human Computer Interface”) se puede usar esquemas de
cómo vería el usuario las pantallas cuando se ejecuta cada caso de uso. También
se puede generar una simulación más sofisticada usando un Sistema Manejador
de Interfaces de Usuario (“UIMS - User Interface Management System”).
Normalmente, un prototipo funcional de requisitos mostrando las interfaces de
usuario es una estrategia importante. Esto ayuda al usuario a visualizar los
casos de uso según serán mostrados por el sistema a ser construido. Tal enfoque
elimina muchas posibilidades de malos entendimientos.
Actores
y Casos de Uso para el Sistema de Reservaciones de Vuelos
Tomando
como ejemplo el sistema de reservaciones de vuelo mostraremos la documentación
de los actores y casos de uso junto con el diseño de las interfaces que serán
usadas como prototipo del sistema. Estos diseños pueden hacerse en papel o
aprovechar una herramienta que simplifique la tarea del diseño de pantallas. El
objetivo primordial es la lógica de “navegación” la cual debe basarse en el
modelo de casos de uso más que la sofisticación del diseño gráfico.
2.4.- HERRAMIENTAS CASE PARA LA
INGENIERIA DE REQUISITOS
Actores y Casos
de Uso para el Sistema de Reservaciones de Vuelos
Tomando
como ejemplo el sistema de reservaciones de vuelo mostraremos la documentación
de los actores y casos de uso junto con el diseño de las interfaces que serán
usadas como prototipo del sistema. Estos diseños pueden hacerse en papel o
aprovechar una herramienta que simplifique la tarea del diseño de pantallas. El
objetivo primordial es la lógica de “navegación” la cual debe basarse en el
modelo de casos de uso más que la sofisticación del diseño gráfico.
HERRAMIENTAS CASE HACIA UNA
INGENIERIA DE REQUISITOS
Son
un conjunto de programas que facilitan la optimización de un producto software
ofreciendo a los analistas, ingenieros de software y de desarrolladores durante
los pasos del ciclo de vida.
IRQA4:
Diseñada para soportar las actividades realizadas en el proceso de
especificación de sistemas, mediante tres técnicas.
RETOS:
propone un modelo de requisitos para capturar los aspectos funcionales del
sistema, mediante tres técnicas, 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.
CONTROLA:
Herramientas de apoyo al proceso de ingeniería de software en pequeñas
empresas, se creo gracias a la expansión que tuvo el mercado y la generación.
OSRMT:
herramienta libre para la gestión de requisitos, algunas de sus principales
características es que trabajan en arquitecturas cliente/servidor, desarrollado
bajo Java.
JEREMIA:
se trata de una aplicación cliente exclusivamente, lo cual no permite la
exclusividad de trabajar en equipo.
RAMBUTAN:
Esta herramienta se basa en XML, realmente consta de un conjunto de
aplicaciones para usuario final ayudando a los analistas de sistemas en la
recopilación y categorización de echos de un documento de especificaciones de
registro.
No hay comentarios:
Publicar un comentario