INSTITUTO TECNOLGICO DE HUEJUTLA

INGENIERIA DE REQUISITOS

PROFESOR: M. EN C. MARIA GUADALUPE RIVERA GARCIA

ALUMNO: Edgardo Ortega Delgado

SEMESTRE: IV

MODULO: 1 ENERO JUNIO 2013

ING. EN SISTEMAS COMPUTACIONALES

HUEJUTLA DE REYES HGO

EDGARDO ORTEGA DELGADO

Introduccin:
La consecuencia del proceso de ingeniera de sistemas es la especificacin de un sistema o producto basado en computadora que se describe genricamente, en diferentes niveles. Pero el desafo de la ingeniera del sistema (y de los ingenieros del software) es importante: Cmo podemos asegurar que hemos especificado un sistema que recoge las necesidades del cliente y satisface sus expectativas? No hay una respuesta segura a esta difcil pregunta, pero un slido proceso de ingeniera de requisitos es la mejor solucin de que disponemos actualmente. La ingeniera de requisitos facilita el mecanismo apropiado para comprender lo que quiere el cliente, analizando necesidades, confirmando su viabilidad, negociando una solucin razonable, especificando la solucin sin ambigedad, validando la especificacin y gestionando los requisitos para que se transformen en un sistema operacional. El proceso de ingeniera de requisitos puede ser descrito en 5 pasos distintos: Identificacin de Requisitos, Anlisis de Requisitos y Negociacin, Especificacin de Requisitos, Modelizado del Sistema, Validacin de Requisitos y Gestin de Requisitos. La ingeniera de requisitos del software es un proceso de descubrimiento, refinamiento, modelado y especificacin. Se refinan en detalle los requisitos del sistema y el papel asignado al software. Tanto el desarrollador como el cliente tienen un papel activo en la ingeniera de requisitos un conjunto de actividades que son denominadas anlisis El cliente intenta replantear un sistema confuso, a nivel de descripcin de datos, funciones y comportamiento, en detalles concretos. El desarrollador acta como interrogador, como consultor, como persona que resuelve problemas y como negociador. El anlisis y la especificacin de requisitos pueden parecer una tarea relativamente sencilla, pero las apariencias engaan. El contenido de comunicacin es muy denso. Abundan las ocasiones para malas interpretaciones o falta de informacin. Es muy probable que haya ambigedad. El dilema al que se enfrenta el ingeniero de software puede entenderse muy bien repitiendo la famosa frase de un cliente annimo: S que cree que entendi lo que piensa que dije, pero no estoy seguro de que se d cuenta de que lo que escuch no es lo que yo quise decir. El anlisis de requisitos es una tarea de ingeniera del software que cubre el hueco entre la definicin del software a nivel sistema y el diseo de software. El anlisis de requerimientos permite al ingeniero de sistemas especificar las caractersticas operacionales del software (funcin, datos y rendimientos), indica la interfaz del software con otros elementos del sistema y establece las restricciones que debe cumplir el software.

EDGARDO ORTEGA DELGADO

Es muy frecuente escuchar entre los conocedores del desarrollo de software (programas de computadoras), que un gran nmero de los proyectos de software fracasan por no realizar una adecuada definicin, especificacin, y administracin de los requisitos. Dentro de esa mala administracin se pueden encontrar factores como la falta de participacin del usuario, requisitos incompletos y el mal manejo del cambio a los requisitos. La Ingeniera de Requisitos (IR) cumple un papel primordial en el proceso de produccin de software, ya que se enfoca un rea fundamental: la definicin de lo que se desea producir. Su principal tarea consiste en la generacin de especificaciones correctas que describan con claridad, sin ambigedades, en forma consistente y compacta, las necesidades de los usuarios o clientes; de esta manera, se pretende minimizar los problemas relacionados por la mala gestin de los requisitos en el desarrollo de sistemas. Definicin: Requisito

Una condicin o necesidad de un usuario para resolver un problema o alcanzar un objetivo. Una condicin o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estndar, especificacin u otro documento formal. Un requisito es simplemente una declaracin abstracta de alto nivel de un servicio que debe proporcionar el sistema o una restriccin de ste.

Definicin: Ingeniera de Requisitos

La Ingeniera de Requisitos ayuda a los ingenieros de software a entender mejor el problema en cuya solucin trabajarn. Incluye el conjunto de tareas que conducen a comprender cul ser el impacto del software sobre el negocio, qu es lo que el cliente quiere y cmo interactuarn los usuarios finales con el software. La Ingeniera de Requisitos es el proceso de desarrollar una especificacin de software. Las especificaciones pretender comunicar las necesidades del sistema del cliente a los desarrolladores del sistema. La Ingeniera de Requisitos se define, como un conjunto de actividades en las cuales, utilizando tcnicas y herramientas, se analiza un problema y se concluye con la especificacin de una solucin (a veces ms de una).

EDGARDO ORTEGA DELGADO

2.1-Tareas de la ingeniera de requisitos

Desde un punto de vista conceptual, las actividades son las siguientes:
Obtener requisitos: a travs de entrevistas o comunicacin con clientes o usuarios,

para saber cules 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 diseo.
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 aplicacin.
Validar los requisitos: comprobar que los requisitos implementados se

corresponden con lo que inicialmente se pretenda. Los requerimientos puedes dividirse en requerimientos funcionales y requerimientos no funcionales. Los requerimientos funcionales definen las funciones que el sistema ser capaz de realizar. Describen las transformaciones que el sistema realiza sobre las entradas para producir salidas. Los requerimientos no funcionales tienen que ver con caractersticas 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, estndares, etc. Caractersticas de los requerimientos: Las caractersticas de un requerimiento son sus propiedades principales. Un conjunto de requerimientos en estado de madurez, deben presentar una serie de caractersticas tanto individualmente como en grupo. A continuacin se presentan las ms importantes. Necesario: Un requerimiento es necesario si su omisin provoca una deficiencia en el sistema a construir, y adems su capacidad, caractersticas fsicas o factor de calidad no pueden ser reemplazados por otras capacidades del producto o del proceso. Conciso: Un requerimiento es conciso si es fcil de leer y entender. Su redaccin debe ser simple y clara para aquellos que vayan a consultarlo en un futuro.

EDGARDO ORTEGA DELGADO

Completo: Un requerimiento est completo si no necesita ampliar detalles en su redaccin, es decir, si se proporciona la informacin suficiente para su comprensin. Consistente: Un requerimiento es consistente si no es contradictorio con otro requerimiento. No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretacin. El lenguaje usado en su definicin, no debe causar confusiones al lector. Verificable: Un requerimiento es verificable cuando puede ser cuantificado de manera que permita hacer uso de los siguientes mtodos de verificacin: inspeccin, anlisis, demostracin o pruebas. Dificultades para definir los requerimientos
Los requerimientos no son obvios y vienen de muchas fuentes. Son difciles de expresar en palabras (el lenguaje es ambiguo). Existen muchos tipos de requerimientos y diferentes niveles de detalle. La cantidad de requerimientos en un proyecto puede ser difcil de manejar. Nunca son iguales. Algunos son ms difciles, ms riesgosos, ms importantes

que otros. Los requerimientos estn relacionados unos con otros, y a su vez se relacionan con otras partes del proceso. Cada requerimiento tiene propiedades nicas y abarcan reas funcionales especficas. Un requerimiento puede cambiar a lo largo del ciclo de desarrollo. Son difciles de cuantificar, ya que cada conjunto de requerimientos es particular para cada proyecto. Ingeniera de Requerimientos: El proceso de recopilar, analizar y verificar las necesidades del cliente para un sistema es llamado Ingeniera de Requerimientos. La meta de la ingeniera de requerimientos (IR) es entregar una especificacin de requisitos de software correcta y completa. "Ingeniera de Requerimientos es la disciplina para desarrollar una especificacin completa, consistente y no ambigua, la cual servir como base para acuerdos comunes entre todas las partes involucradas y en dnde se describen las funciones que realizar el sistema". "Ingeniera de Requerimientos es el proceso por el cual se transforman los requerimientos declarados por los clientes , ya sean hablados o escritos, a especificaciones precisas, no ambiguas, consistentes y completas del comportamiento del sistema, incluyendo funciones, interfaces, rendimiento y limitaciones". "Es el proceso mediante el cual se intercambian diferentes puntos de vista para recopilar y modelar lo que el sistema va a realizar. Este proceso utiliza una combinacin de mtodos, herramientas y actores, cuyo producto es un modelo del cual se genera un documento de requerimientos" Leite 1987.

o ms estables

EDGARDO ORTEGA DELGADO

"Ingeniera de requerimientos es un enfoque sistmico para recolectar, organizar y documentar los requerimientos del sistema; es tambin el proceso que establece y mantiene acuerdos sobre los cambios de requerimientos, entre los clientes y el equipo del proyecto" Rational Software Importancia de las tareas de la Ingeniera de Requerimientos: Los principales beneficios que se obtienen de la Ingeniera de Requerimientos son:
Permite

gestionar las necesidades del proyecto en forma estructurada: Cada actividad de la IR consiste de una serie de pasos organizados y bien definidos. Mejora la capacidad de predecir cronogramas de proyectos, as como sus resultados: La IR proporciona un punto de partida para controles subsecuentes y actividades de mantenimiento, tales como estimacin de costos, tiempo y recursos necesarios. Disminuye los costos y retrasos del proyecto: Muchos estudios han demostrado que reparar errores por un mal desarrollo no descubierto a tiempo, es sumamente caro; especialmente aquellas decisiones tomadas durante la RE. Mejora la calidad del software: La calidad en el software tiene que ver con cumplir un conjunto de requerimientos (funcionalidad, facilidad de uso, confiabilidad, desempeo, etc.). Mejora la comunicacin entre equipos: La especificacin de requerimientos representa una forma de consenso entre clientes y desarrolladores. Si este consenso no ocurre, el proyecto no ser exitoso. Evita rechazos de usuarios finales: La ingeniera de requerimientos obliga al cliente a considerar sus requerimientos cuidadosamente y revisarlos dentro del marco del problema, por lo que se le involucra durante todo el desarrollo del proyecto.

EDGARDO ORTEGA DELGADO

2.2.-Tcnicas de la ingeniera de requisitos

La ingeniera de requisitos puede ser un proceso largo y arduo para el que se requiere de habilidades psicolgicas. 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 tcnicas para obtener los requisitos del cliente. Histricamente, esto ha incluido tcnicas tales como las entrevistas, o talleres con grupos para crear listas de requisitos. Tcnicas ms modernas incluyen los prototipos, y utilizan casos de uso. Cuando sea necesario, el analista emplear una combinacin de estos mtodos para establecer los requisitos exactos de las personas implicadas, para producir un sistema que resuelva las necesidades del negocio. Entrevistas: Las entrevistas son un mtodo comn. Por lo general no se entrevista a toda la gente que se relacionar con el sistema, sino a una seleccin de personas que represente a todos los sectores crticos de la organizacin, con el nfasis puesto en los sectores ms afectados o que harn un uso ms 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 seleccin de un secretario dedicado a la documentacin de la discusin, liberando al analista del negocio para centrarse en el proceso de la definicin de los requisitos y para dirigir la discusin. 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 pginas. 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 crticos del funcionamiento interno que luego darn forma a los comportamientos apreciables por el usuario. Luego, se establecen formas de medir el progreso

EDGARDO ORTEGA DELGADO

en la construccin, para evaluar en cualquier momento qu tan avanzado se encuentra el proyecto.

Prototipos: Un prototipo es una pequea muestra, de funcionalidad limitada, de cmo sera el producto final una vez terminado. Ayudan a conocer la opinin de los usuarios y rectificar algunos aspectos antes de llegar al producto terminado. Casos de uso: Un caso de uso es una tcnica para documentar posibles requisitos, graficando la relacin del sistema con los usuarios u otros sistemas. Dado que el propio sistema aparece como una caja negra, y slo se representa su interaccin con entidades externas, permite omitir dichos aspectos y determinar los que realmente corresponden a las entidades externas. El objetivo de esta prctica es mejorar la comunicacin 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 tcnica 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 diseo final. al comenzar otra vez.

Los diseadores tienden a reutilizar el cdigo de los prototipos por temor a perder el tiempo Los Los

prototipos ayudan principalmente a las decisiones del diseo y de la interfaz de usuario. Sin embargo, no proporcionan explcitamente cules son los requisitos. diseadores y los usuarios finales pueden centrarse demasiado en el diseo 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 diseo grfico, se realizan en una variedad de documentos de diseo grficos y a menudo elimina todo el color del diseo del software (es decir utilizar una gama de grises). Esto ayuda a prevenir la confusin sobre la apariencia final de la aplicacin.

EDGARDO ORTEGA DELGADO

Es importante determinar quin tiene el problema realmente, considerar dicho problema desde una variedad de perspectivas y explorar muchas soluciones desde diferentes puntos de vista. Veamos la siguiente necesidad: "El cliente se queja mucho por la enorme fila que debe formar para realizar una transaccin bancaria". Perspectiva del cliente = Perspectiva del banco = Posibles prdidas de clientes Prdida de tiempo

Posibles soluciones pueden ser, determinar por qu demoran los cajeros, colocar una nueva caja (implica contratacin de nuevos cajeros), abrir una nueva sucursal (involucra personal nuevo y estudio de mercado), realizar transacciones por otros medios (telfono, internet, mediante cajeros automticos, autobancos, etc.). Como puede verse, mltiples soluciones aplican para el mismo problema, sin embargo, slo una de ellas ser la ms factible. Las soluciones inciales, deben ser definidas tomando en cuanta tanto la perspectiva tcnica como la del negocio. Construir un vocabulario comn: Debe confeccionarse un glosario en dnde se definan todos los trminos que tengan significados comunes (sinnimos) y que sern utilizados durante el proyecto. Por ejemplo, las palabras pignoracin, retencin, valor en suspenso, custodia, garanta, entre otras, son utilizadas para referirse a la accin de dejar una prenda (puede ser cualquier forma de ahorros) como garanta de una deuda adquirida. La creacin de un glosario es sumamente beneficiosa ya que reduce los trminos ambiguos desde el principio, ahorra tiempo, asegura que todos los participantes de una reunin estn en la misma pgina, adems de ser reutilizable en otros proyectos. Identificar a los afectados por el sistema: Identificar a todos los afectados evita que existan sorpresas a medida que avanza el proyecto. Las necesidades de cada afectado, son discutidas y sometidas a debate durante de ingeniera de requerimientos, aunque esto no garantiza que vaya a estar disponible toda la informacin necesaria para especificar un sistema adecuado. Para saber quines son las personas, departamentos, organizaciones internas o externas que se vern afectadas por el sistema, debemos realizar algunas preguntas.
Quin usar el sistema que se va a construir? Quin desarrollar el sistema? Quin probar el sistema? Quin documentar el sistema? Quin dar soporte al sistema? Quin dar mantenimiento al sistema? Quin mercadear, vender, y/o distribuir el sistema? Quin se beneficiar por el retorno de inversin del sistema?

Como vemos, debe conocerse la opinin de todo aqul que de una u otra forma est involucrado con el sistema, ya sea directa o indirectamente. Definir los lmites y restricciones del sistema: Este punto es importante pues debemos saber lo que se est construyendo, y lo que no se est construyendo, para as entender la estrategia del producto a corto y largo plazo. Debe determinarse cualquier restriccin ambiental, presupuestaria, de tiempo, tcnica y de factibilidad que limite el sistema que se va a construir.

EDGARDO ORTEGA DELGADO

2.3.- Modelacin de requisitos:

Modelo de Pohl: Modelo iterativo con cuatro actividades. Aunque el orden puede ser cualquiera, se asume una secuencia: Se obtienen los requisitos, se negocian con los participantes, se integran con el resto de la documentacin y finalmente se validan y verifican. Modelo espiral: Modelo iterativo basado en la dificultad de establecer un punto de terminacin, debido a que los requisitos nunca llegaran a ser perfectos. En el modelo asume la existencia de una actividad de gestin de requisitos, realizada durante todo el proyecto y que gestiona la obtencin incremental de requisitos y los cambios a los que estn sujetos. El modelo consta de tres partes: La e licitacin de requisitos, el anlisis-validacin de requisitos y la negociacin de requisitos. Modelo SWEBOK: Forma parte del rea novena (ingeniera de requisitos) del proyecto SWEBOK que es un proyecto para producir un cuerpo de conocimiento sobre ingeniera de software que siente las bases sobre dicha ingeniera como una profesin. El modelo consiste en cuatro actividades: E licitacin de requisitos, anlisis y negociacin de requisitos, documentacin de requisitos y validacin de requisitos. Modelo de madurez del proceso REAIMS: Es el resultado de un proyecto europeo que lleva su nombre y va orientado a los procesos de ingeniera de requisitos que deben manejar las organizaciones. El modelo tiene 3 niveles de madurez: Inicial (Orientado a aquellas organizaciones que desarrollan proyectos y que no tienen definido un proceso de Ingeniera de Requisitos), repetible (este nivel pertenecen todas aquellas organizaciones que han definido ciertas normas, estndares para sus documentos de requisitos, as como tambin para su descripcin) y definido (las organizaciones ya tienen un proceso de Ingeniera de Requisitos definido). Evolucin de los requerimientos: Los requerimientos son una manera de comprender mejor el desarrollo de las necesidades de los usuarios y cmo los objetivos de organizacin pueden cambiar, por lo tanto, es esencial planear posibles cambios a los requerimientos cuando el sistema sea desarrollado y utilizado. La actividad de evolucin es un proceso externo que ocurre a lo largo del ciclo de vida del proyecto. Los requerimientos cambian por diferentes razones. Las ms frecuentes son:
Porque al analizar el problema, no se hacen las preguntas correctas a las personas correctas. Porque cambi el problema que se estaba resolviendo. Porque los usuarios cambiaron su forma de pensar o sus percepciones. Porque cambi el ambiente de negocios. Porque cambi el mercado en el cual se desenvuelve el negocio.

EDGARDO ORTEGA DELGADO

Cambios a los requisitos involucra modificar el tiempo en el que se va a implementar una caracterstica en particular, modificacin que a la vez puede tener impacto en otros requerimientos. Por esto, la administracin de cambios involucra actividades como establecer polticas, guardar histricos de cada requerimiento, identificar dependencias entre ellos y mantener un control de versiones. Tener versiones de los requerimientos es tan importante como tener versiones del cdigo, ya que evita tener requerimientos emparchados en un proyecto Entre algunos de los beneficios que proporciona el control de versiones estn:
Prevenir cambios no autorizados. Guardar revisiones de los documentos de requerimientos. Recuperar versiones previas de los documentos. Administrar una estrategia de "releases". Prevenir la modificacin simultnea a los requisitos.

En vista que las peticiones de cambios provienen de muchas fuentes, las mismas deben ser enrrutadas en un solo proceso. Esto se hace con la finalidad de evitar problemas y conseguir estabilidad en los requerimientos. 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 segn la percepcin 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 formacin de todos los dems modelos en el desarrollo de software. En general, el cualquier cambio en la funcionalidad del sistema es ms fcil de hacer, y con menores consecuencias, a este nivel que posteriormente. El modelo de requisitos que desarrollaremos se basa en la metodologa Objectory (Jacobson et al. 1992), basada principalmente en el modelo de casos de uso. Actualmente esta metodologa 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 dems modelos, como se describi anteriormente en el Captulo 3 y se resume aqu: Requisitos: El modelo de casos de uso sirve para expresar el modelo de requisitos, el cual se desarrolla en cooperacin con otros modelos como se ver ms adelante. Anlisis: La funcionalidad especificada por el modelo de casos de uso se estructura en el modelo de anlisis, que es estable con respecto a cambios, siendo un modelo lgico independiente del ambiente de implementacin. Diseo: La funcionalidad de los casos de uso ya estructurada por el anlisis es realizada por el modelo de diseo, adaptndose al ambiente de implementacin real y refinndose an ms. Implementacin: Los casos de uso son implementados mediante el cdigo fuente en el modelo de implementacin.

EDGARDO ORTEGA DELGADO

Pruebas: Los casos de uso son probados a travs de las pruebas de componentes y pruebas de integracin. Documentacin: 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 administracin, etc. El diagrama de la Figura 6.1 ilustra los distintos modelos. Describiremos los detalles y la notacin ms adelante.

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 presentacin o modelo de interfaces o borde especifica cmo interacta el sistema con actores externos al ejecutar los casos de uso, en particular, en los sistemas de informacin ricos en interaccin con el usuario, especifica cmo se vern visualmente las interfaces grficas y que funcionalidad ofrecer cada una de ellas. El modelo de informacin o modelo del dominio del problema especifica los aspectos estructurales del sistema. Este modelo conceptualiza el sistema segn los objetos que representan las entidades bsicas de la aplicacin. Aunque en muchas metodologas 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 ms ayuda como apoyo al modelo de casos de uso y no como una entidad totalmente independiente. Es importante resaltar que esta separacin 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. Para ilustrar el modelo de requisitos y el desarrollo de los modelos posteriores, utilizaremos el ejemplo del Sistema de Reservaciones de Vuelo como se mencion anteriormente. Para tal meta, mostraremos inicialmente una descripcin del problema. A partir de esta descripcin inicial se describirn los tres modelos bsicos del modelo de requisitos.

EDGARDO ORTEGA DELGADO

2.4.- Herramientas case para la ingeniera de requisitos

Herramientas de la ingeniera de la informacin. Estas herramientas CASE modelan la informacin de negocios cuando sta se transfiere entre distintas entidades organizativas en el seno de una compaa. El objetivo primordial de las herramientas de esta categora consiste en representar objetos de datos de negocios, sus relaciones, y ayuda a comprender mejor la forma en que fluyen estos objetos de datos entre distintas zonas de negocio en el seno de la compaa. Estas herramientas proporcionan una ayuda importante cuando se disean nuevas estrategias para los sistemas de informacin y cuando los mtodos y sistemas no satisfacen las necesidades de la organizacin. Modelado de procesos y herramientas de administracin. Se utilizan para representar los elementos clave del proceso de modo que sea posible entenderlo mejor. Estas herramientas tambin pueden proporcionar vnculos con descripciones de procesos que ayuden a quienes estn implicados en el proceso de comprender las tareas que se requieren para llevar a cabo ese proceso. Las herramientas de administracin de procesos pueden proporcionar vnculos con otras herramientas que proporcionen un apoyo para actividades de proceso ya definidas. Herramientas de planificacin de proyectos. Las herramientas de esta categora se concentran en dos reas primordiales:
Estimacin

de esfuerzos de proyecto y de costes de software. Calculan el esfuerzo estimado, la duracin del proyecto y el nmero recomendado de personas. Planificacin de proyectos. Capacitan al administrador para definir todas las reas del proyecto (la estructura de desglose de tareas), para crear una red de tareas (normalmente empleando una entrada grfica), para representar las interdependencias entre tareas y para modelar la cantidad de paralelismo que sea posible para ese proyecto. Herramientas de anlisis de riesgos Las herramientas de anlisis de riesgos capacitan al administrador el proyecto para construir una tabla de riesgos proporcionando una gua detallada en la identificacin y anlisis de riesgos. Herramientas de administracin de proyectos. La planificacin del proyecto y el plan del proyecto deben seguirse y de monitorizarse de forma contina. Adems, el gestor deber de utilizar las herramientas que recojan mtricas que en la ltima instancia proporcionen una indicacin de la calidad el producto del software. Las herramientas de esta categora suelen ser extensiones de herramientas de planificacin de proyectos.

EDGARDO ORTEGA DELGADO

Herramientas de seguimiento de requisistos Cuando se desarrollan grandes sistemas, el sistema proporcionado suele no satisfacer los requisitos especificados por el cliente. El objetivo de las herramientas de seguimiento de requisitos es proporcionar un enfoque sistemtico para el aislamiento de requisitos, comenzando por las especificaciones del cliente. Las herramientas de trazado de requisitos tpicos combinan una evaluacin de textos por interaccin humana, con un sistema de gestin de bases de datos que almacena y categora todos y cada uno de los requisitos del sistema que se "analizan" a partir de las especificaciones originales. Herramientas de mtricas y gestin. Las mtricas del software mejoran la capacidad del administrador para controlar y coordinar el proceso del software y la capacidad del ingeniero para mejorar la calidad del software que se produce. Las herramientas mtricas actuales se centran en procesos, proyectos y caractersticas del producto. Las herramientas orientadas a la gestin capturan mtricas especificas del proyecto (por ejemplo: LDC/personamos, defectos por punto de funcin) que proporcionan una indicacin global de productividad o de calidad. Las herramientas orientadas tcnicamente determinan mtricas tcnicas que proporcionan una mejor visin de la calidad del diseo o del cdigo. Muchas de las herramientas mtricas avanzadas mantiene una base de datos de medidas de medias de la industria. Basndose en caractersticas de proyectos y de productos proporcionados por el usuario, estas herramientas califican los nmeros locales frente a los valore medios de la industria (y frente al rendimiento local anterior) y sugieren estrategias para llegar a mejoras. Estas herramientas utilizan un sistema experto para sugerir el orden en el que se debe llevar a cabo un proyecto. Herramientas de documentacin Las herramientas de produccin de documentos y autoedicin prestan su apoyo a casi todos los aspectos de la ingeniera del software, y representan una importante oportunidad de aprovechamiento para todos los desarrolladores del software. La mayor parte de las organizaciones dedicadas al desarrollo de software invierte una cantidad de tiempo considerable en el desarrollo de documentos, y en muchos casos el proceso de documentacin en si resulta bastante deficiente. No es raro que una organizacin de desarrollo de software invierta hasta en un 20 o 30 pro ciento de su esfuerzo global de desarrollo de software en la documentacin. Por esta razn, las herramientas de documentacin suponen una oportunidad importante para mejorar la productividad. Herramientas de software de sistema. CASE es una tecnologa de estaciones de trabajo. Por tanto, el entorno CASE debe adaptase a un software de sistema en redes de alta calidad, al correo electrnico, a los boletines electrnicos y a otras capacidades de comunicaciones.

EDGARDO ORTEGA DELGADO

Herramientas de control de calidad. La mayor parte de las herramientas CASE que afirman que tiene como principal inters el control de calidad son en realidad herramientas mtricas que hace una auditoria del cdigo fuente para determinar si es justa o no a ciertos estndares del lenguaje. Otras herramientas extraen mtricas tcnicas como base para medir la calidad del software que se esta construyendo. Herramientas de gestin como base de datos. El software de gestin de bases de datos sirve como fundamentos para establecer una base de datos CASE. Dado el nfasis acerca de los objetos de configuracin, las herramientas de gestin de bases de datos para CASE pueden evolucionar a partir de los sistemas de gestin de bases de datos relacionales (SGBDR) para transformarse en sistemas de gestin de bases de datos orientadas a objetos (SGBDOO). Herramientas de codificacin de cuarta generacin. Los sistemas de consulta de bases de datos, los generadores de cdigo y los lenguajes de cuarta generacin han cambiado la forma en que se desarrollan los sistemas. Idealmente, estas herramientas de generacin de cdigo no solo traducen la descripcin de un sistema operativo, sino que tambin ayudan a verificar la correccin de la especificacin del sistemas de tal forma que la salida resultante satisfaga los requisitos del usuario. Los lenguajes de cuarta generacin se usan ampliamente en aplicaciones de sistemas de informacin. Aunque los lenguajes de cuarta generacin, los generadores de cdigo y los generadores de aplicaciones, permiten que un ingeniero de software especifique un sistema a un nivel muy alto de abstraccin; cada una de estas herramientas difiere en aspectos importantes. Herramientas de mantenimiento Las herramientas CASE para el mantenimiento de software abarcan una actividad que actualmente ocupa, aproximadamente, el 70% del esfuerzo total dedicado al software. La categora de herramientas de mantenimiento puede subdividirse de la siguiente forma:
Herramientas de

ingeniera inversa a especificaciones. Toman el cdigo fuente como entrada y generan modelos de diseo y anlisis estructurado, listas de utilizacin y otra informacin con el diseo. Herramientas de reestructuracin y anlisis de cdigo. Analizan la sintaxis del programa, generan un grafo de flujo de control y un programa estructurado. Herramientas interactivas de reingeniera de sistema. Se utilizan para modificar sistemas de base de datos. Estas herramientas estn limitadas a lenguajes de programacin especficos y requieren cierto grado de interaccin con el ingeniero de software.

EDGARDO ORTEGA DELGADO

Herramientas de gestin de configuracin de software. La gestin de configuracin de software (GCS) se encuentra en el ncleo de todos los entornos CASE. Las herramientas pueden ofrecer su asistencia en las cinco tareas principales de GCS: identificacin, control de versiones control de cambios, auditorias y contabilidad de estados. La base de datos CASE proporciona un mecanismo para identificar todos los elementos de configuracin y relacionarlo con otros elementos; un acceso sencillo a los elementos de configuracin individuales facilita el proceso de auditora; las herramientas de comunicacin CASE pueden mejorar enormemente la contabilidad de estados (ofreciendo informacin acerca de los cambios a todos aquellos que necesiten conocerlos). Herramientas de anlisis y diseo. Las herramientas de anlisis y diseo capacitan al ingeniero del software para crear modelos del sistema que haya que construir. Los modelos contienen una representacin de los datos, de la funcin y del comportamiento (en el nivel de anlisis), as como caracterizaciones del diseo de datos, arquitectura, procedimientos e interfaz. Al efectuar una comprobacin de la consistencia y validez del modelo, las herramientas de anlisis y diseo proporcionan al ingeniero del software un cierto grado de visin en lo tocante a la representacin del anlisis, y le ayudan a eliminar errores antes de que se propaguen al diseo, o lo que es peor, a la propia implementacin. Herramientas pro/sim. Las herramientas PRO/SIM (de prototipos y simulacin) proporcionan al ingeniero del software la capacidad de predecir el comportamiento de un sistema en tiempo real antes de llegar a construirlo. Adems, capacitan al ingeniero del software para desarrollar simulaciones del sistema de tiempo real que permitirn al cliente obtener ideas acerca de su funcionamiento, comportamiento y respuesta antes de la verdadera implementacin. Herramientas de desarrollo y diseo de interfaz. Las herramientas de desarrollo y diseo de interfaz son en realidad un conjunto de primitivas de componente de programas tales como mens, botones, estructuras de ventanas, iconos, mecanismos de desplazamiento, controladores de dispositivos, etc., Sin embargo, estos conjuntos de herramientas se estn viendo sustituidos por herramientas de generacin de prototipos de interfaz que permiten una rpida creacin en pantalla de sofisticadas interfaces de usuario, que se ajustan al estndar de interfaz que se haya adoptado para el software. Herramientas de generacin de prototipos. Se puede utilizar toda una gama de herramientas de generacin de prototipos. Los generadores de pantallas permiten al ingeniero de software definir rpidamente la disposicin de pantalla para aplicaciones interactivas. Otras herramientas de prototipos CASE mas sofisticadas permiten la creacin de un diseo de datos, acoplado con las disposiciones de la pantalla y de los informes simultneamente. Muchas herramientas de anlisis y diseo proporcionan extensiones que ofrecen alguna opcin de generacin de prototipos. Las herramientas PRO/SIM generan un esqueleto de cdigo fuente en Ada y C para las aplicaciones

EDGARDO ORTEGA DELGADO

de ingeniera (en tiempo real). Por ultimo, una gama de herramientas de cuarta generacin poseen tambin caractersticas de generacin de prototipos. Herramientas de programacin. La categora de herramientas de programacin abarca los compiladores, editores y depuradores que estn disponibles para prestar su apoyo en la mayora de los lenguajes de programacin convencionales. Adems, los entornos de programacin orientados a objetos (OO), los lenguajes de cuarta generacin, los entornos de programacin grfica, los generadores de aplicaciones y los lenguajes de consulta de bases de datos residen tambin en esta categora. Herramientas de integracin y comprobacin. En su directorio de herramientas de comprobacin de software, software QualityEngineering define las siguientes categoras de herramientas de comprobacin:
Adquisicin

de datos: herramientas que adquieren datos que se utilizaran durante la comprobacin. Medida esttica: herramientas que analizan el cdigo fuente sin ejecutar casos de prueba. Medida dinmica: herramientas que analizan el cdigo fuente durante la ejecucin. Simulacin: herramientas que simulan las funciones del hardware o de otros elementos externos. Administracin de comprobaciones: herramientas que prestan su asistencia en la planificacin, desarrollo y control de las comprobaciones. Herramientas de funcionalidad cruzada: se trata de herramientas que cruzan los limites de las categoras anteriores. Debera tenerse en cuenta que muchas de las herramientas de comprobacin poseen caractersticas que abarcan dos o ms de las categoras anteriores. Herramientas de anlisis esttico. Las herramientas de anlisis esttico prestan su asistencia al ingeniero del software a efectos de derivar casos prcticos. Se utilizan tres tipos distintos de herramientas estticas de comprobacin en la industria: herramientas de comprobacin basadas en cdigo, lenguajes de comprobacin especializados, y herramientas de comprobacin basadas en requisitos. Las herramientas de comprobacin basadas en cdigo admiten un cdigo fuente (o PDL) como entrada y efectan un cierto nmero de anlisis que can lugar a la generacin de casos de prueba. Los lenguajes de comprobacin especializados (por ejemplo: ATLAS) capacitan al ingeniero del software para escribir detalladas especificaciones de comprobacin que describirn todos los casos de prueba y la logstica de su ejecucin. Las herramientas de comprobacin basadas en requisitos aslan requisitos especficos del usuario y sugieren casos de prueba (o clases de comprobaciones) que ejerciten estos requisitos.

EDGARDO ORTEGA DELGADO

Herramientas de anlisis dinmico. Las herramientas de anlisis dinmico interactan con un programa que se est ejecutando, comprueban la cobertura de rutas, comprueban las afirmaciones acerca del valor de variables especificas y en general instrumentan el flujo de ejecucin del programa. Las herramientas dinmicas pueden ser bien intrusivas, bien no intrusivas. Las herramientas intrusivas modifican el software que hay que comprobar mediante sondas que se insertan (instrucciones adicionales) y que efectan las actividades mencionadas anteriormente. Las herramientas de comprobacin no intrusivas utilizan un procesador hardware por separado que funciona en paralelo con el procesador que contenga el programa que se est comprobando. Herramientas de gestin de comprobacin. Las herramientas de gestin de comprobacin se utilizan para comprobar y coordinar la comprobacin de software para cada uno de los pasos principales de comprobacin. Las herramientas de esta categora administran y coordinan la comprobacin de regresiones, efectan comparaciones que determinan las diferencia s entre la salida real y la esperada, y efectan comprobaciones por lotes de programas con interfaces interactivas entre hombre y maquina. Adems de las funciones indicadas anteriormente, muchas herramientas de gestin de comprobaciones sirven tambin como controladores de comprobacin genricos. Un controlador de comprobacin lee uno o mas casos de prueba de algn archivo de pruebas, da formato a los datos de prueba para que se ajusten a las necesidades del software que se esta probando, e invoca entonces al software que sea preciso comprobar. Herramientas de comprobacin clientes/servidor. El entorno C/S existe unas herramientas de comprobacin especializadas que ejerciten la interfaz grfica de usuario y los requisitos de comunicaciones en red par el cliente y el servidor. Herramientas de reingeniera. La categora de herramientas de reingeniera se pueden subdividir en las funciones siguientes:
Herramientas

de ingeniera inversa para producir especificaciones: se toma el cdigo fuente como entrada y se generan modelos grficos de anlisis y diseo estructurados, listos de utilizacin y otras informaciones de diseo. Herramientas de reestructuracin y anlisis de cdigo: se analiza la sintaxis del programa, se genera una grfica de control de flujo y se genera automticamente un programa estructurado. Herramientas de reingeniera para sistemas en lnea: se utilizan para modificar sistemas de bases de datos en lnea (por ejemplo: para convertir archivos IDMS o DB2 traducindolos a un formato de entidades y relaciones). Muchas de las herramientas anteriores estn limitadas a lenguajes de programacin especficos (aun cuando se abarcan la mayora de los lenguajes principales) y requieren un cierto grado de interaccin con un ingeniero del software.

EDGARDO ORTEGA DELGADO

Las herramientas de ingeniera inversa y progresiva de la prxima generacin harn un uso mucho mayor de tcnicas de inteligencia artificial, aplicando una base de conocimientos que se a especifica del dominio de la aplicacin (esto es, un conjunto de reglas de descomposicin que se aplicaran a todos los programas de una cierta zona de aplicacin tal como el control de fabricacin o la avinica). El componente de inteligencia artificial asistir en la descomposicin y reconstruccin de los sistemas, pero seguir requiriendo una interaccin con un ingeniero de software a lo largo del ciclo de la reingeniera.

EDGARDO ORTEGA DELGADO

FUENTES DE CONSULTA:

McConnell, Steve (1996). Rapid Development: Taming Wild Software Schedules, 1st ed.,

Redmond, WA: Microsoft Press.

Wiegers,

Karl E. (2003). Software Requirements 2: Practical techniques for gathering and managing requirements throughout the product development cycle, 2nd ed., Redmond: Microsoft Press. Cambridge, MA: O'Reilly Media.

Andrew Stellman and Jennifer Greene (2005). Applied Software Project Management.

IEEE Std 830-1998 IEEE Recommended Practice for Software Requirements Specifications

Description

EDGARDO ORTEGA DELGADO