SISTEMAS
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.
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. Esta técnica se enfrenta a los siguientes
peligros potenciales.
- A los directivos, una vez que ven un prototipo, les cuesta comprender que queda mucho trabajo por hacer para completar el diseño final.
- Los diseñadores tienden a reutilizar el código de los prototipos por temor a “perder el tiempo” al comenzar otra vez.
- 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.
- 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.
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.
TAREA DE INGENIERIA DE REQUISITOS
Requerimiento: Es una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo.
*Una condición o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estándar, especificación u otro documento formal
Tipos de requerimientos: requerimientos funcionales y requerimientos no funcionales.
Ingeniería 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.
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.
MODELOS 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.
El
modelo de requisitos es el primer modelo a desarrollarse, sirviendo de base
para la formación de todos los demás Modelos en el desarrollo de software. En
general, el cualquier cambio en la funcionalidad del sistema es más fácil de hacer,
y con menores consecuencias, a este nivel que posteriormente.
El modelo de
requisitos que desarrollaremos se basa
en la metodología Objectory (Jacobson et al. 1992), basada principalmente en el
modelo de casos de uso.
Actualmente
esta metodología es parte del Proceso Unificado de Rational (RUP).
REQUISITOS:
El modelo de casos de uso sirve para expresar el modelo de requisitos, el cual
se desarrolla en cooperación con otros modelos como se verá más adelante.
ANÁLISIS: La funcionalidad especificada por el
modelo de casos de uso se estructura en el modelo de análisis, que es estable
con respecto a cambios, siendo un modelo lógico independiente del ambiente de
implementación.
DISEÑO: La funcionalidad de los casos de uso
ya estructurada por el análisis es realizada por el modelo de diseño,
adaptándose al ambiente de implementación real y refinándose aún más.
IMPLEMENTACIÓN: Los casos de uso son
implementados mediante el código fuente en el modelo de implementación.
PRUEBAS: Los casos de uso son probados a
través de las pruebas de componentes y pruebas de integración.
DOCUMENTACIÓN:
El modelo de casos de uso debe ser documentado a lo largo de las diversas
actividades, dando lugar a distintos documentos como los manuales de usuario,
manuales de administración, etc.
El
propósito del modelo de requisitos es comprender completamente el problema y
sus implicaciones. Todos los modelos no solamente se verifican contra el modelo
de requisitos, sino que también se desarrollan directamente de él. El modelo de
requisitos sirve también como base para el desarrollo de las instrucciones
operacionales y los manuales ya que todo lo que el sistema deba hacer se
describe aquí desde la perspectiva del usuario. El modelo de requisitos
no es un proceso mecánico, el analista debe interactuar constantemente con el
cliente para completar la información faltante, y así clarificar ambigüedades e
inconsistencias.
El analista debe separar entre los requisitos
verdaderos y las decisiones relacionadas con el diseño e implementación. Se
debe indicar cuales aspectos son obligatorios y cuales son opcionales para
evitar restringir la flexibilidad de la implementación. Durante el diseño se
debe extender el modelo de requisitos con especificaciones de rendimiento y
protocolos de interacción con sistemas.
El
modelo de comportamiento, basado directamente en el modelo de casos de uso,
especifica la funcionalidad que ofrece el sistema desde el punto de vista del
usuario. Este modelo utiliza dos conceptos claves: actores para representar los
distintos papeles que los usuarios pueden jugar con el sistema, y casos de uso
para representar qué pueden hacer los actores con respecto al sistema El modelo de presentación o modelo de
interfaces o borde especifica cómo interactúa el sistema con actores externos
al ejecutar los casos de uso, en particular, en los sistemas de información
ricos en interacción con el usuario, especifica cómo se verán visualmente las
interfaces gráficas y que funcionalidad ofrecerá cada una de ellas. El modelo de información o modelo del dominio
del problema especifica los aspectos estructurales del sistema. Este modelo conceptualiza
el sistema según los objetos que representan las entidades básicas de la
aplicación. Aunque en muchas metodologías se permite especificar la
funcionalidad completa del sistema utilizando el modelo del dominio del
problema, incluyendo operaciones formales sobre los objetos correspondientes a
un como apoyo al modelo de casos de uso y no como una entidad totalmente
independiente.
El
modelo de comportamiento, basado directamente en el modelo de casos de uso,
especifica la funcionalidad que ofrece el sistema desde el punto de vista del usuario.
Este modelo utiliza dos conceptos claves: actores para Representar los
distintos papeles que los usuarios pueden jugar con el sistema, y casos de uso
para representar qué pueden hacer los actores con respecto al sistema El modelo
de presentación o modelo de interfaces o borde especifica cómo interactúa el
sistema con actores externos al ejecutar los casos de uso, en particular, en
los sistemas de información ricos en interacción con el usuario,
especifica cómo se verán visualmente las interfaces gráficas y que
funcionalidad ofrecerá cada una de ellas.
El
modelo de información o modelo del dominio del problema especifica los aspectos
estructurales del sistema. Este modelo conceptualiza el sistema según los
objetos que representan las entidades básicas de la aplicación. Aunque en
muchas metodologías se permite especificar la funcionalidad completa del
sistema utilizando el modelo del dominio del problema, incluyendo operaciones
formales sobre los objetos correspondientes a un modelo de requisitos expresado
sin casos de uso, el modelo del dominio del problema será de mucha más ayuda
como apoyo al modelo de casos de uso y no como una entidad totalmente
independiente.
HERRAMIENTA CASE PARA LA INGENIERIA DE REQUISITOS
A
medida que pasa el tiempo se logra entender que el empleo del software es una
buena opción para agilizar y sistematizar las tareas en el desarrollo de
procesos. El desarrollo de software no es la excepción; en este caso dichas
herramientas se han denominado CASE (Ingeniería De Software Asistida Por
Computador).
Estas incluyen un conjunto de programas que facilitan la
optimización de un producto ofreciendo
apoyo permanente a los analistas, ingenieros de software y desarrolladores.
CASE
es la aplicación de métodos y técnicas que dan utilidades a los programas, por
medio de otros, procedimientos y su respectiva documentación. En esta
investigación se hace referencia a las herramientas que ayudan a la gestión de
requisitos; es decir al proceso de identificación, asignación y seguimiento de
los mismos, incluyendo interfaz, verificación, modificación y control de cada
requisito, durante el ciclo de vida del proyecto. Los cambios/ actualizaciones
de requisitos deben ser gestionados para asegurar que se mantenga la calidad
del producto.
Hasta
hace poco tiempo 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)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
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.
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.
Publicar un comentario
0 Comentarios