Unidad 2 Ingenieria De Requisitos

[Escriba aquí]

GLOBALTEC UNIDAD 2 Ingeniería de Requisitos

Integrantes del Equipo: Cinthia Guadalupe Ramírez Montes Lezly Susette Reyes Norman Franklin Iztcoatl Monreal Cristerna Bernardo Dávila Jiménez Alfredo Pablo Hernández

GlobalTec Fundamentos de Ingeniería del Software

UNIDAD 2

Contenido 2.1

Tareas de la Ingeniería de Requisitos ............................................................................... 4

Actividades de la ingeniería de requerimientos ....................................................................... 4 Extracción ...................................................................................................................................... 4 Análisis ........................................................................................................................................... 4 Especificación ............................................................................................................................... 5 Validación....................................................................................................................................... 5 2.2

Técnicas de la Ingeniería de Requisitos ........................................................................... 5

Entrevistas ..................................................................................................................................... 6 Lluvia de Ideas .............................................................................................................................. 7 Prototipos ....................................................................................................................................... 8 Proceso de Análisis Jerárquico (AHP) ...................................................................................... 8 Casos de uso ................................................................................................................................ 9 Talleres ......................................................................................................................................... 10 Forma de contrato ...................................................................................................................... 10 Objetivos medibles ..................................................................................................................... 10 2.3

Modelado de Requisitos .................................................................................................... 11

2.4

Herramientas CASE para la Ingeniería de Requisitos ................................................. 13

Referencias ..................................................................................................................................... 17

Ingeniería en Sistemas Computacionales

Página 3 de 17

GlobalTec Fundamentos de Ingeniería del Software

UNIDAD 2

2.1 Tareas de la Ingeniería de Requisitos A través de los años se ha podido constatar que los requerimientos o requisitos son la pieza fundamental en un proyecto de desarrollo de software, ya que marcan el punto de partida para actividades como la planeación, básicamente en lo que se refiere a las estimaciones de tiempos y costos, así como la definición de recursos necesarios y la elaboración de cronogramas que será uno de los principales mecanismos de control con los que se contará durante la etapa de desarrollo. La Ingeniería de Requerimientos (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 requerimientos en el desarrollo de sistemas. Actividades de la ingeniería de requerimientos Se dice que dentro de la IR existen cuatro actividades básicas que se tienen que llevar a cabo para completar el proceso. Estas actividades ayudan a reconocer la importancia que tiene para el desarrollo de un proyecto de software realizar una especificación y administración adecuada de los requerimientos de los clientes o usuarios. Las cuatro actividades son: extracción, análisis, especificación y validación. 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 requerimientos del sistema. Aquí, los analistas de requerimientos deben trabajar junto al cliente para descubrir el problema que el sistema debe resolver, los diferentes servicios que el sistema debe prestar, las restricciones que se pueden presentar, etc. Es importante, que la extracción sea efectiva, ya que la aceptación del sistema dependerá de cuan bien éste satisfaga las necesidades del cliente. Análisis Sobre la base de la extracción realizada previamente, comienza esta fase en la cual se enfoca en descubrir problemas con los requerimientos del sistema identificados hasta el momento. Usualmente se hace un análisis luego de haber producido un bosquejo inicial del documento de requerimientos; en esta etapa se leen los requerimientos, se conceptúan, se investigan, se intercambian ideas con el resto del equipo, se resaltan los problemas, se buscan alternativas y soluciones, y luego se van fijando reuniones con el cliente para discutir los requerimientos.

Ingeniería en Sistemas Computacionales

Página 4 de 17

GlobalTec Fundamentos de Ingeniería del Software

UNIDAD 2

Especificación En esta fase se documentan los requerimientos acordados con el cliente, en un nivel apropiado de detalle. En la práctica, esta etapa se va realizando conjuntamente con el análisis, se puede decir que la especificación es el "pasar en limpio" el análisis realizado previamente aplicando técnicas y/o estándares de documentación, como la notación UML (Lenguaje de Modelado Unificado), que es un estándar para el modelado orientado a objetos, por lo que los casos de uso y la obtención de requerimientos basada en casos de uso se utiliza cada vez más para la obtención de requerimientos. Validación La validación es la etapa final de la IR. Su objetivo es, ratificar los requerimientos, es decir, verificar todos los requerimientos 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 requerimientos sean consistentes y que estén completos. Se puede apreciar que el proceso de ingeniería de requerimientos es un conjunto estructurado de actividades, mediante las cuales se obtiene, se valida y se logra dar un mantenimiento adecuado al documento de especificación de requerimientos, que es el documento final, de carácter formal, que se obtiene de este proceso. Es necesario recalcar que no existe un proceso único que sea válido de aplicar en todas las organizaciones. Cada organización debe desarrollar su propio proceso de acuerdo al tipo de producto que se esté desarrollando, a la cultura organizacional, y al nivel de experiencia y habilidad de las personas involucradas en la ingeniería de requerimientos. Hay muchas maneras de organizar el proceso de ingeniería de requerimientos y en otras ocasiones se tiene la oportunidad de recurrir a consultores, ya que ellos tienen una perspectiva más objetiva que las personas involucradas en el proceso.

2.2 Técnicas de la Ingeniería de Requisitos

Ingeniería en Sistemas Computacionales

Página 5 de 17

GlobalTec Fundamentos de Ingeniería del Software

UNIDAD 2

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 y cuestionarios son un método común y se emplean para reunir información proveniente de personas o de grupos. Durante la entrevista, el analista conversa con el encuestado; el cuestionario consiste en una serie de preguntas relacionadas con varios aspectos de un sistema. Por lo común, los encuestados son usuarios de los sistemas existentes o usuarios en potencia del sistema propuesto. En algunos casos, son gerentes o empleados que proporcionan datos para el sistema propuesto o que serán afectados por él, e incluso aquellas personas que harán un uso más frecuente del nuevo sistema. Las preguntas que deben realizarse en esta técnica, deben ser preguntas de alto nivel y abstractas que pueden realizarse al inicio del proyecto para obtener información sobre aspectos globales del problema del usuario y soluciones potenciales. Las preguntas pueden ser enfocadas específicamente a un elemento del sistema como por ejemplo: Hacia el usuario    

¿Quién es el cliente? ¿Quién es el usuario? ¿Son sus necesidades diferentes? ¿Cuáles son sus habilidades, capacidades, ambiente?

Hacia el proceso    

¿Cuál es la razón por la que se quiere resolver este problema? ¿Cuál es el valor de una solución exitosa? ¿Cómo usted resuelve el problema actualmente? ¿Qué retrasos ocurren o pueden ocurrir?

Hacia el producto Ingeniería en Sistemas Computacionales

Página 6 de 17

GlobalTec Fundamentos de Ingeniería del Software

   

UNIDAD 2

¿Qué problemas podría causar este producto en el negocio? ¿En qué ambiente se usará el producto? ¿Cuáles son sus expectativas para los conceptos fácil de usar, confiable, rendimiento? ¿Qué obstáculos afectan la eficiencia del sistema?

Lluvia de Ideas Este método comenzó en el ámbito de las empresas, aplicándose a temas tan variados como la productividad, la necesidad de encontrar nuevas ideas y soluciones para los productos del mercado, encontrar nuevos métodos que desarrollen el pensamiento creativo a todos los niveles, etc. Pero pronto se extendió a otros ámbitos, incluyendo el mundo de desarrollo de sistemas; básicamente se busca que los involucrados en un proyecto desarrollen su creatividad, promoviendo la introducción de los principios creativos. Principios de la lluvia de ideas Aplazar el juicio y no realizar críticas, hasta que no agoten las ideas, ya que actuaría como un inhibidor. Se ha de crear una atmósfera de trabajo en la que nadie se sienta amenazado. Cuantas más ideas se sugieren, mejores resultados se conseguirán: "la cantidad produce la calidad". Las mejores ideas aparecen tarde en el periodo de producción de ideas, será más fácil que encontremos las soluciones y tendremos más variedad sobre la que elegir. La producción de ideas en grupos puede ser más efectiva que la individual. Tampoco debemos olvidar que durante las sesiones, las ideas de una persona, serán asociadas de manera distinta por cada miembro, y hará que aparezcan otras por contacto. El equipo en una lluvia de ideas debe estar formado por:   

El Director: es la figura principal y el encargado de dirigir la sesión. El secretario: registra por escrito las ideas según van surgiendo. Los participantes: pueden ser habituales o invitados; cualquier involucrado en el proyecto entra en esta categoría.

Fases de aplicación de la lluvia de ideas: 

Descubrir hechos: Se determina el problema, delimitándolo, precisándolo y clarificándolo.

Ingeniería en Sistemas Computacionales

Página 7 de 17

GlobalTec Fundamentos de Ingeniería del Software

 

UNIDAD 2

Producir ideas: Se busca producir una gran cantidad de ideas, aplicando los principios de la lluvia de ideas. Descubrir soluciones: Se elabora una lista definitiva de ideas, para seleccionar las más interesantes.

Prototipos Los prototipos permiten al desarrollador crear un modelo del software que debe ser construido. Es una pequeña muestra, de funcionalidad limitada, de cómo sería el producto final una vez terminado. El prototipo es evaluado por el cliente y el usuario y utilizado para refinar los requerimientos del software a ser desarrollado. Un proceso de iteración tiene lugar a medida que el prototipo es "puesto a punto" para satisfacer las necesidades del cliente y permitiendo al mismo tiempo una mejor comprensión del problema por parte del desarrollador. Además ayudan a conocer la opinión de los usuarios y rectificar algunos aspectos antes de llegar al producto terminado. Existen principalmente dos tipos de prototipos: Prototipo rápido (o concept prototype): El prototipado rápido es un mecanismo para lograr la validación pre-compromiso. Se utiliza para validar requerimientos en una etapa previa al diseño específico. En este sentido, el prototipo puede ser visto como una aceptación tácita de que los requerimientos no son totalmente conocidos o entendidos antes del diseño y la implementación. El prototipo rápido puede ser usado como un medio para explorar nuevos requerimientos y así ayudar a "controlar" su constante evolución. Prototipo evolutivo: Desde una perspectiva diferente, todo el ciclo de vida de un producto puede ser visto como una serie incremental de detallados prototipos acumulativos. El punto de vista evolutivo del ciclo de vida del software considera a la primera entrega como un prototipo inicial en el campo. Modificaciones y mejoras subsecuentes resultan en nuevas entregas de prototipos más maduros. Este proceso continúa hasta que se haya desarrollado el producto final. La adopción de esta óptica elimina la distinción arbitraria entre desarrollo y mantenimiento, resultando en un importante cambio de mentalidad que afecta las estrategias para la estimación de costos, enfoques de desarrollo y adquisición de productos. Proceso de Análisis Jerárquico (AHP) Esta técnica tiene por objetivo resolver problemas cuantitativos, para facilitar el pensamiento analítico y las métricas. Consiste en una serie de pasos a saber:    

Encontrar los requerimientos que van a ser priorizados. Combinar los requerimientos en las filas y columnas de la matriz n x n de AHP. Hacer algunas comparaciones de los requerimientos en la matriz Sumar las columnas

Ingeniería en Sistemas Computacionales

Página 8 de 17

GlobalTec Fundamentos de Ingeniería del Software

 

UNIDAD 2

Normalizar la suma de las filas Calcular los promedios

Estos pasos pueden aplicarse fácilmente a una cantidad pequeña de requerimientos, sin embargo, para un volumen grande, esta técnica no es la más adecuada.

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. Es una forma de expresar cómo alguien o algo externo a un sistema lo usa. Cuando decimos "alguien o algo" hacemos referencia a que los sistemas son usados no sólo por personas, sino también por otros sistemas de hardware y software. 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 casos de uso tienen las siguientes características:   

 

Están expresados desde el punto de vista del actor. Se documentan con texto informal. Describen tanto lo que hace el actor como lo que hace el sistema cuando interactúa con él, aunque el énfasis está puesto en la interacción. Son iniciados por un único actor. Están acotados al uso de una determinada funcionalidad del sistema, claramente diferenciada.

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.

Ingeniería en Sistemas Computacionales

Página 9 de 17

GlobalTec Fundamentos de Ingeniería del Software

UNIDAD 2

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.

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.

Ingeniería en Sistemas Computacionales

Página 10 de 17

GlobalTec Fundamentos de Ingeniería del Software

UNIDAD 2

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í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. Ingeniería en Sistemas Computacionales

Página 11 de 17

GlobalTec Fundamentos de Ingeniería del Software

UNIDAD 2

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 de Objectory, el modelo de requisitos consiste de tres modelos principales, visualmente representado por un diagrama de tres dimensiones. 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. Es importante resaltar que esta separación en tres ejes de modelado independientes es la base para una mayor estabilidad en el desarrollo del sistema, permitiendo minimizar los efectos de cada uno sobre los otros dos.

Ingeniería en Sistemas Computacionales

Página 12 de 17

GlobalTec Fundamentos de Ingeniería del Software

UNIDAD 2

2.4 Herramientas CASE para la Ingeniería de Requisitos De acuerdo con Kendall y Kendall la Ingeniería de Sistemas asistida por computadora es la aplicación de tecnología informática a las actividades, las técnicas y las metodologías propias de desarrollo, su objetivo es acelerar el proceso para el que han sido diseñadas, en el caso de CASE para automatizar o apoyar una o mas fases del ciclo de vida del desarrollo de sistemas. Cuando se hace la planificación de la base de datos, la primera etapa del ciclo de vida de las aplicaciones de bases de datos, también se puede escoger una herramienta CASE que permita llevar a cabo el resto de tareas del modo mas eficiente y efectivo posible. Una herramienta CASE suele incluir:

  

Herramientas de diseño para dar apoyo al análisis de datos. Herramientas que permitan desarrollar el modelo de datos corporativo, así como los esquemas conceptual y lógico. Herramientas para desarrollar los prototipos de las aplicaciones.

Con el ánimo de facilitar las tareas del desarrollo de software, surgen herramientas informáticas que agilizan la labor en la IR. Dichas herramientas son denominadas CASE (Ingeniería de software asistida por computador), y sirven de apoyo para los desarrolladores, desde el principio hasta el final del proceso. Para el caso particular de esta investigación, son de especial interés aquellos instrumentos que se encargan de actividades como: extraer, analizar, documentar, revisar, negociar y validar los requisitos del sistema objeto de estudio.

Ingeniería en Sistemas Computacionales

Página 13 de 17

GlobalTec Fundamentos de Ingeniería del Software

UNIDAD 2

Herramientas CASE, hacia una Ingeniería de Requisitos computarizada 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 y 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.

Ingeniería en Sistemas Computacionales

Página 14 de 17

GlobalTec Fundamentos de Ingeniería del Software

UNIDAD 2

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

Ingeniería en Sistemas Computacionales

Página 15 de 17

GlobalTec Fundamentos de Ingeniería del Software

UNIDAD 2

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. Existen otras herramientas en estudios para la gestión de requisitos. A continuación se mencionan, algunas de las incluidas en el estudio comparativo presentado por El Consejo Internacional sobre la Ingeniería de Sistemas (INCOSE)7: CaliberRM, REM, SMART TRACE, SoftREQ, Analyst Real Team System (ARTS), CARE 3.2, CORE 5.1, Cradle 5.2, Envision VIP, Gatherspace, IBM Rational RequisitePro, KollabNet Editor 2005, PACE, RaQuest 3.0, RMTrak, RTM, SLATE REquire 6.5, SoftREQ, UGS Teamcenter 2005, truereq product desktop, XTie-RT, Specification Analysis Tool (SAT), ECM, Banyan2.2, Contour, Projectricity 3.5, FeaturePlan 2.6, analyst pro, ChangeWare 2.0, aligned elements, Dassault Systemes CSE 4.0, Polarion ALM for Subversion 3.0, Telelogic DOORS, Accept 360.

Ingeniería en Sistemas Computacionales

Página 16 de 17

GlobalTec Fundamentos de Ingeniería del Software

UNIDAD 2

Referencias http://www.cannes.itam.mx/Alfredo/Espaniol/Publicaciones/MINT/Requisitos.pdf http://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_requisitos#T.C3.A9cnicas_principales http://www.monografias.com/trabajos6/resof/resof2.shtml#teec http://redalyc.uaemex.mx/pdf/666/66661111.pdf

Titulo: Ingeniería de Requerimientos Autor: Diana Santofimio Ariza Fecha: Agosto del 2009 Web: http://es.vbook.pub.com/doc/19083744/INGENIERIA-DE-REQUERIMIENTOS

Titulo: Herramientas CASE para Ingeniería de Requisitos Autor: Instituto de Investigaciones Científicas Fecha: 2008 Web: http://www.revistasjdc.com/main/index.php/ccient/article/view/37/36

Ingeniería en Sistemas Computacionales

Página 17 de 17

GlobalTec Fundamentos de Ingeniería del Software

Ingeniería en Sistemas Computacionales

UNIDAD 2

Página 18 de 17