2.1. TAREAS DE LA INGENIERÍA 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.
Implicaciones
La Ingeniería de Requisitos implica todas las actividades del ciclo de vida dedicadas a:
La educción (a veces llamada "elicitación", debido a una mala traducción de "elicitation") de los requisitos de usuario. El análisis y negociación de requisitos para derivar requisitos adicionales. La documentación de los requisitos como especificación. La validación de los requisitos documentados contra las necesidades de usuario. Así como los procesos que apoyan estas actividades.
Fases de implementación
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. 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. 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. 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.
2.3. MODELADO 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íaObjectory(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). El modelo de casos de uso y el propio modelo de requisitos son la base para los demás modelos, como se describió anteriormente en el Capítulo 3 y se resume aquí:
1.- 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.
2.-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.
3.-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.
4.-Implementación: Los casos de uso son implementados mediante el código fuente en el modelo de
implementación.
5.-Pruebas: Los casos de uso son probados a través de las pruebas de componentes y pruebas de integración.
6.-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 externos, al igual que provisiones sobre modularidad y futuras extensiones. En ciertas ocasiones ya se puede incluir aspectos de diseño, como el uso de lenguajes de programación particulares. En la metodología deObjectory, el modelo de requisitos consiste de tres modelos principales, visualmente representado por un diagrama de tres dimensiones.
7.-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 quiénes son sus usuarios. Por ejemplo, conducir un automóvil es distinto a arreglarlo, donde los usuarios también son distintos, el dueño del automóvil y el mecánico, respectivamente.
8.- Actores
Los actores son entidades distintas a los usuarios, en el sentido que los usuarios son las personas reales que utilizan el sistema, mientras que los actores representan un cierto papel que una persona real puede jugar. Utilizando terminología orientada a objetos, se considera al actor como una clase de usuario, mientras que los usuarios se consideran como objetos o instancias de esa clase. Incluso, una misma persona puede aparecer como diferentes instancias de diferentes actores.
Los actores modelan cualquier entidad externa que necesite intercambiar información con el sistema. Los actores no están restringidos a ser personas físicas, pudiendo representar otros sistemas externos al actual. Lo esencial es que los actores representen entidades externas al sistema. Además, cada uno de estos actores podrá ejecutar una o más tareas del sistema.
2.4. HERRAMIENTAS CASE PARA LA INGENIERÍA 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:
1.-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.
2.-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.
3.-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.
4.-OSRMT (Open SourceRequirements 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.
5.-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.
6.-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.
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. 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.
2.3. MODELADO 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íaObjectory(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). El modelo de casos de uso y el propio modelo de requisitos son la base para los demás modelos, como se describió anteriormente en el Capítulo 3 y se resume aquí:
1.- 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.
2.-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.
3.-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.
4.-Implementación: Los casos de uso son implementados mediante el código fuente en el modelo de
implementación.
5.-Pruebas: Los casos de uso son probados a través de las pruebas de componentes y pruebas de integración.
6.-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 externos, al igual que provisiones sobre modularidad y futuras extensiones. En ciertas ocasiones ya se puede incluir aspectos de diseño, como el uso de lenguajes de programación particulares. En la metodología deObjectory, el modelo de requisitos consiste de tres modelos principales, visualmente representado por un diagrama de tres dimensiones.
7.-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 quiénes son sus usuarios. Por ejemplo, conducir un automóvil es distinto a arreglarlo, donde los usuarios también son distintos, el dueño del automóvil y el mecánico, respectivamente.
8.- Actores
Los actores son entidades distintas a los usuarios, en el sentido que los usuarios son las personas reales que utilizan el sistema, mientras que los actores representan un cierto papel que una persona real puede jugar. Utilizando terminología orientada a objetos, se considera al actor como una clase de usuario, mientras que los usuarios se consideran como objetos o instancias de esa clase. Incluso, una misma persona puede aparecer como diferentes instancias de diferentes actores.
Los actores modelan cualquier entidad externa que necesite intercambiar información con el sistema. Los actores no están restringidos a ser personas físicas, pudiendo representar otros sistemas externos al actual. Lo esencial es que los actores representen entidades externas al sistema. Además, cada uno de estos actores podrá ejecutar una o más tareas del sistema.
2.4. HERRAMIENTAS CASE PARA LA INGENIERÍA 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:
1.-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.
2.-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.
3.-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.
4.-OSRMT (Open SourceRequirements 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.
5.-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.
6.-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.
No hay comentarios.:
Publicar un comentario