10 de Abril del 2014

INTRODUCCION GENERAL

Con el paso del tiempo el software ha sufrido cambios radicales, que han ido marcando momentos importantes en la historia de la humanidad, es gracias al software que nuestras tareas cotidianas se facilitan, además las empresas pueden producir en mayor cantidad y llevar un mejor control de sus empleados, es por el que se han desarrollado formas de ayudar al mundo, sin duda esto ha revolucionado nuestra forma de vivir y pensar, no imaginaríamos un mundo sin computadoras, sin tecnología; es gracias a ello que la ingeniería de software se basa en modelos, métodos y herramientas que sirven como una guía para los ingenieros del software durante el proceso de desarrollo, con la finalidad de mejorar la calidad de los proyectos, procesos y productos mediante la evaluación y medición de los mismos.

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.

Entonces, la tarea más importante que el ingeniero de software hace para el cliente es la extracción iterativa y el refinamiento de los requerimientos del producto.

INTRODUCCIÓN

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.

Además la especificación de requerimientos es la base que permite verificar si se alcanzaron o no los objetivos establecidos en el proyecto ya que estos son un reflejo detallado de las necesidades de los clientes o usuarios del sistema y es contra lo que se va a estar verificando si se están cumpliendo las metas trazadas.

Es muy frecuente escuchar entre los conocedores del desarrollo de software (programas de computadoras), que un gran número de los proyectos de software fracasan por no realizar una adecuada definición, especificación, y administración de los requerimientos.

Dentro de esa mala administración se pueden encontrar factores como la falta de participación del usuario, requerimientos incompletos y el mal manejo del cambio a los requerimientos.

UNIDAD 2 INGENIERIA DE LOS REQUERIMIENTOS

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.

¿Qué son requisitos ó requerimientos?

Se presenta a continuación la definición existente en el glosario de la IEEE de lo que es un “Requerimiento”:

1. “Una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo”. (Std 610.12-1900, IEEE: 62)

2. “Una condición o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estándar, especificación u otro documento formal”. (Std 610.12-1900, IEEE: 62)

También, Ian Sommerville presenta una definición acerca de lo que es un “Requerimiento”:

3. “Un requerimiento es simplemente una declaración abstracta de alto nivel de un servicio que debe proporcionar el sistema o una restricción de éste”. (Sommerville, 2005: 108)

Características de un requerimiento

• Especificado por escrito: Como todo contrato o acuerdo entre dos partes.

•   Posible de probar o verificar. Si un requerimiento no se puede comprobar, entonces ¿cómo se sabe si se cumplió con él o no?

•   Conciso: Un requerimiento es conciso si es fácil de leer y entender. Su redacción debe ser simple y claro para aquellos que vayan a consultarlo en un futuro.

•   Completo: Un requerimiento está completo si no necesita ampliar detalles en su redacción, es decir, si se proporciona la información suficiente para su comprensión.

•   Consistente: Un requerimiento es consistente si no es contradictorio con otro requerimiento.

•   No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretación. El lenguaje usado en su definición, no debe causar confusiones al lector.

Definición de Requerimientos

• “Ingeniería de Requerimientos ayuda a los ingenieros de software a entender mejor el problema en cuya solución trabajarán. Incluye el conjunto de tareas que conducen a comprender cuál será el impacto del software sobre el negocio, qué es lo que el cliente quiere y cómo interactuarán los usuarios finales con el software”.

(Pressman, 2006: 155)

BIBLIOGRAFIA 1

• Autor: Pressman, Roger S.

• Año de Edición: 2006,

• Libro: “Ingeniería del Software: Un enfoque práctico”

• Sexta edición, México DF, Editorial McGraw Hill.

• Página:155-165

Ingeniería de requisitos

• “La ingeniería de requerimientos es el proceso de desarrollar una especificación de software. Las especificaciones pretender comunicar las necesidades del sistema del cliente a los desarrolladores del sistema”.

(Sommerville, 2005: 82)

Síntesis de Requerimientos

• En síntesis, el proceso de ingeniería de requerimientos se utiliza para definir todas las actividades involucradas en el descubrimiento,

documentación y mantenimiento de los requerimientos para un producto de software determinado, donde es muy importante tomar en cuenta que el aporte de la IR vendrá a ayudar a determinar la viabilidad de llevar a cabo el software (si es factible llevarlo a cabo o no).

• Pasando posteriormente por un subproceso de obtención y análisis de requerimientos, su especificación formal, para finalizar con el subproceso de validación donde se verifica que los requerimientos realmente definen el sistema que quiere el cliente.

Dificultades para definir los requerimientos

• Los requerimientos no son obvios y vienen de muchas fuentes.

•   Son difíciles de expresar en palabras (el lenguaje es ambiguo).

•   La cantidad de requerimientos en un proyecto puede ser difícil de manejar.

•   Un requerimiento puede cambiar a lo largo del ciclo de desarrollo.

•   El usuario no puede explicar lo que hace

•   Tiende a recordar lo excepcional y olvidar lo rutinario

•   Hablan de lo que no funciona

•   Los usuarios tienen distinto vocabulario que los desarrolladores.

Actividades de los requerimientos

• Extracción: 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.

• Análisis: 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.

• 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: 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.

BIBLIOGRAFIA 2

• Autor: Sommerville Ian

• Año de Edición: 2005

• Libro: “Ingeniería del Software”

• Séptima edición, México DF, Editorial Pearson.

• Página: 82-90

2.1 Tareas de la ingeniería de requisitos

La ingeniería de requisitos proporciona el mecanismo apropiado para entender lo que el cliente quiere, analizar las necesidades, evaluar la factibilidad, negociar una solución razonable, especificar la solución sim ambigüedades, validar la especificación, y administrar los requisitos conforme estos se transformar en un sistema operacional. El proceso de la ingeniería de requisitos se lleva a cabo a través de siete distintas funciones: inicio, obtención, elaboración, negociación, especificación, validación y gestión.

Inicio

En algunos casos, una conversación informal es todo lo que se necesita para precipitar un esfuerzo importante de ingeniería del software. Pero en general, la mayoría de los proyectos comienza cuando se identifica una necesidad de negocios o se descubren un nuevo mercado o servicio potencial.

Obtención

Debemos hablar con el cliente y otros interesados de cuáles son sus objetivos para el sistema o producto, que es lo que se debe lograr, de que forma el producto satisface las necesidades del negocio y por ultimo como se utilizara el sistema o producto día a día.

Para ello se debe identificar una serie de problemas que ayudan a entender por qué es difícil la obtención de requisitos:

Problemas de ámbito: El límite del sistema está mal definido o los clientes especifican detalles técnicos innecesarios que pueden confundir, en lugar de clarificar, los objetivos generales del sistema.

Problemas de compresión: Los clientes no están seguros por completo de que es lo que se necesita, comprenden poco acerca de las capacidades y limitaciones de su ambiente de computo, no comprenden del todo el dominio del problema, tienen dificultades al comunicar necesidades al ingeniero de sistemas, omiten información que se consideraban “obvia”, especifican requisitos que chocan con las necesidades de otros clientes, o especifican requisitos inestables.

Problemas de volatilidad: Los problemas cambian conforme transcurre el tiempo.

Para ayudar a superar estos problemas, los ingenieros de requisitos deben realizar en forma organizada la actividad de recopilación de requisitos.

Elaboración

La información conseguida con el cliente durante el inicio y la obtención se expande y se refina durante la elaboración. Esta actividad de la ingeniería de requisitos se enfoca en el desarrollo de un modelo técnico refinado de las funciones, características y restricciones del software.

Negociación:

En esta etapa el ingeniero de requisitos debe negociar con el cliente los alcances y límites del sistema. De forma iterativa los requisitos se prioriza, modifican, combinan o eliminan buscando acuerdos que beneficien a todas las partes. Se identifican y analizan los riesgos asociados con cada requisito.

Especificación:

Es el producto final de la ingeniería de requisitos, y se convierte en la materia prima para las actividades posteriores en el proceso de desarrollo del sistema. Una especificación puede ser un documento escrito, un conjunto de modelos gráficos, un modelo matemático formal, una colección de escenarios de uso, un prototipo o cualquier combinación de estos.

Validación

La calidad de los productos de trabajo procedentes de la ingeniería de requisitos se evalúa durante un paso de validación. La validación de requisitos se examina la especificación para asegurar que todos los requisitos de software se han establecido de manera precisa; que se han detectado las inconsistencias, omisiones y errores y que estos han sido corregidos, y que los productos de trabajo cumplen con los estándares establecidos para el proceso, proyecto y producto.

Gestión de requisitos

La gestión de requisitos es un conjunto de actividades que ayudan al equipo de proyecto a identificar, controlar y rastrear los requisitos y los cambios a estos en el cualquier momento mientras se desarrolla el proyecto.

La gestión de requisitos comienza con la identificación. Cada requerimiento se asigna a un solo identificador. Una vez identificados los requisitos se desarrollan las tablas de rastreabilidad.

Entre las muchas tablas de rastreabilidad posibles están las siguientes:

• De características: Muestra la manera en que los requisitos se relacionan con las características del producto o sistema observables para el cliente.

• De fuente: Identifica la fuente de cada requisito.

• De dependencia: Indica la forma en que los requisitos están relacionados entre sí.

• De subsistema: Establece categorías entre los requisitos de acuerdo con los subsistemas que gobiernan.

• De interfaz: Muestra la forma en que los requisitos se relación con las interfaces internas y externas del sistema.

BIBLIOGRAFIA:

Libro: Ingeniería de software un enfoque practico

Edición: Sexta

Autor: Roger S. Pressman

Editorial: Mc Graw Hill

Paginas: 157-162

2.1 Tareas de la ingeniería de requisitos

Se define como un conjunto de actividades en los cuales, utilizando técnicas y herramientas, se analiza un problema y se concluye con la especificación de una solución. La ingeniería de requisitos es el proceso de desarrollar una especificación de software.

Extracción: Esta fase representa el comienzo de cada ciclo. Extracción es el nombre comúnmente dado a las actividades involucradas en el descubrimiento de los requisitos del sistema.

Análisis: Sobre la base de la extracción realizada previamente, comienza esta fase en la cual se enfoca en descubrir problemas con los requisitos del sistema identificados hasta el momento.

Especificación: En esta fase se documentan los requisitos acordados con el cliente, en un nivel apropiado de detalle.

Validación: La validación es la etapa final de la IR. Su objetivo es, ratificar los requisitos, es decir, verificar todos los requisitos que aparecen en el documento especificado para asegurarse que representan una descripción, por lo menos, aceptable del sistema que se debe implementar. Esto implica verificar que los requisitos sean consistentes y que estén completos.

LINKOGRAFIA:

http://ithjuanah.blogspot.mx/

2.2 TÉCNICAS DE LA INGENIERÍA DE REQUISITOS

INTRODUCCIÓN

Las técnicas de la ingeniería de requisitos nos permiten recoger información sobre el sistema propuesto y los existentes y extraer los requerimientos del usuario y del sistema de esta información.

Las fuentes de información durante la fase del descubrimiento de requerimientos incluyen la documentación, los stakeholders del sistema y la especificación de sistemas similares.

Los stakeholders son todos aquellos individuos que interactúan con un sistema; los cuales abarcan desde los usuarios finales del sistema hasta los gerentes y stakeholders externos como los reguladores quienes certifican la aceptabilidad del sistema.

A continuación se describen técnicas de descubrimiento de requerimientos entre las que se incluyen entrevistas, escenarios y etnografía.

ENTREVISTAS

Las entrevistas formales o informales con los stakeholders del sistema son parte de la mayoría de los procesos de la ingeniería de requerimientos. En estas entrevistas, el equipo de ingeniería de requerimientos hace preguntas a los stakeholders sobre el sistema que utilizan y el sistema a desarrollar. Los requerimientos provienen de las respuestas a estas preguntas.

Las entrevistas pueden ser de dos tipos:

1.- Entrevistas cerradas donde los stakeholders responden a un conjunto predefinido de preguntas.

2.- Entrevistas abiertas donde no hay un programa predefinido. El equipo de la ingeniería de requerimientos examina una seria de cuestiones con los stakeholders del sistema y, por lo tanto, desarrolla una mejor comprensión de sus necesidades.

En la práctica, las entrevistas con los stakeholders normalmente son una mezcla de éstos.

Las entrevistas también requieren de un método que podemos establecer en los siguientes pasos:

Planificación de la entrevista (antes de realizar la entrevista): Fijar a quién se debe entrevistar, contando con la aprobación previa. Se informa al entrevistado con antelación del contenido de la entrevista, y se reúne toda la información existente sobre el contenido antes de realizar la entrevista. Finalmente, convenir día, hora y lugar.

Realización de la entrevista: Deberá llevarse a cabo en un ambiente apropiado y lo más exento posible de interrupciones. Conviene ser puntual, identificarse y explicar el objetivo de la entrevista.

En el desarrollo, se debe ir de lo general a aspectos más detallados, empezando por:

• Funciones - entradas - salidas (lo que hace).

• Salidas - funciones - entradas (los documentos que maneja).

Se debe utilizar un estilo apropiado y evitar la tentación de argumentar, dar consejos o envolver emocionalmente al entrevistado (ya que esto último modificará su actitud de cara a próximas entrevistas).

Finalización de la entrevista: Verificaremos las notas con la persona entrevistada, le expresaremos nuestro agradecimiento y dejaremos el camino abierto para nuevos contactos.

Consolidación (después de la entrevista): Se debe organizar y completar si fuera preciso las notas recogidas, elaborar un acta que debe ser entregada a todos los participantes, recabar cuantas consideraciones sean precisas en relación a su contenido y conseguir que el usuario lo apruebe.

ESCENARIOS

Normalmente, las personas encuentran más fácil dar ejemplos de la vida real que descripciones abstractas. Pueden comprender y criticar un escenario de cómo interactuar con un sistema software.

Los ingenieros de requerimientos pueden utilizar la información obtenida de esta discusión para formular los requerimientos reales del sistema.

Los escenarios pueden ser especialmente útiles para agregar detalle a un esbozo de la descripción de requerimientos. Son descripciones de ejemplos de las sesiones de interacción.

Cada escenario abarca una o más posibles interacciones. Se han desarrollado varias formas de escenarios, cada una de las cuales proporciona diferentes tipos de información en diferentes niveles de detalle sobre el sistema.

El escenario comienza con un esbozo de la interacción y, durante la obtención, se agregan detalles para crear una descripción completa de esta interacción. De forma general, un escenario puede incluir:

1. Una descripción de lo que esperan el sistema y los usuarios cuando el escenario comienza.

2. Una descripción del flujo normal de eventos en el escenario.

3. Una descripción de lo que puede ir mal y cómo manejarlo.

4. Información de otras actividades que se podrían llevar a cabo al mismo tiempo.

5. Una descripción del estado del sistema cuando el escenario termina.

Los escenarios se pueden redactar como texto, complementados por diagramas, fotografías de las pantallas, etcétera.

Ejemplo:

Suposición inicial: el usuario a entrado en el sistema LYBSIS y ha localizado la revista que contiene el artículo.

Normal: el usuario selecciona el artículo a copiar. El sistema insta al usuario a proporcionar la información de suscriptor de la revista o a indicar a un método de pago del artículo. El pago se puede efectuar mediante tarjeta de crédito o citando un número de cuenta.

Se le solicita entonces al usuario que rellene un formulario de derechos de autor que mantiene los detalles de la transacción y se envía al sistema LYBSIS.

Se verifica el formulario de derechos de autor, y si se aprueba, se descarga la versión en PDF del artículo al área de trabajo de LYBSIS en la computadora del usuario y se informa al usuario que está disponible. Se le pide al usuario que seleccione una impresora y se imprime una copia del artículo. Si el artículo es de “sola impresión” se elimina del sistema del usuario una vez que éste ha confirmado que se ha completado la impresión.

Que puede salir mal: el usuario puede rellenar el formulario de derechos de autor incorrectamente. En este caso, se le debe de volver a mostrar el formulario para su corrección. Si el formulario reenviado todavía es incorrecto, se rechaza la petición del artículo por parte del usuario.

El sistema puede rechazar el pago, en cuyo caso se rechaza la petición del usuario.

La descarga del articulo puede fallar, haciendo que el sistema lo reintente hasta que lo consiga o hasta que el usuario termine la sesión.

Es posible que no pueda imprimir el artículo. Si el artículo no es de “solo impresión”, se mantiene en el espacio de trabajo del LYBSIS. De lo contrario el artículo se elimina y se lo cargan a la cuenta del usuario los costes del artículo.

Otras actividades: descarga simultaneas de artículos.

Estado del sistema a la finalización: el usuario está dentro del sistema. El artículo descargado se ha borrado del espacio de trabajo del LYBSIS si es de solo impresión.

CASOS DE USOS

Los casos de uso son una técnica que se basa en escenarios para la obtención de requerimientos que se introdujeron por primera vez en el método Objeiory (Jacobsen et ai., 1993).Actualmente se han convertido en una característica fundamental de la notación de UML, que se utiliza para describir modelos de sistemas orientados a objetos.

En su forma más simple, un caso de uso identifica el tipo de interacción y los actores involucrados.

Los actores en el proceso se representan como figuras delineadas, y cada clase de interacción se representa como una elipse con su nombre.

Los casos de uso identifican las interacciones particulares con el sistema. Pueden ser documentadas con texto o vinculadas a modelos UML que desarrollan el escenario en más detalle.

Según Fowler (Fowler y Scott. 1997), un caso de uso encierra un conjunto de escenarios, y cada uno de éstos es un hilo único a través del caso de uso.

Los casos de uso son técnicas eficaces para obtener requerimientos para los puntos de vista de los interactuadores, donde cada tipo de interacción se puede representar como un caso de uso. También se pueden utilizar conjuntamente con algunos puntos de vista indirectos cuando éstos reciben resultados (como un informe de gestión) del sistema. Sin embargo, debido a que se centran en las interacciones, no son tan eficaces para obtener restricciones y requerimientos de negocio y no funcionales de alto nivel de puntos de vista indirectos o para descubrir requerimientos del dominio.

Ejemplo: Casos de uso para el sistema de biblioteca:

En esta figura se muestra una extensión del ejemplo del LIBSYS y muestra otros casos de uso en ese entorno.

ETNOGRAFÍA

La etnografía es una técnica de observación que se puede utilizar para entender los requerimientos sociales y organizacionales. Un analista se sumerge

por sí solo en el entorno laboral donde se utilizará el sistema. Observa el trabajo diario y anota las tareas reales en las que los participantes están involucrados.

El valor de la etnografía es que ayuda a los analistas a descubrir los requerimientos implícitos que reflejan los procesos reales más que los formales en los que la gente está involucrada.

La etnografía es especialmente efectiva para descubrir dos tipos de requerimientos:

1. Los requerimientos que se derivan de la forma en la que la gente trabaja realmente más que de la forma en la que las definiciones de los procesos establecen que debería trabajar.

Por ejemplo, los controladores del tráfico aéreo pueden desconectar un sistema de alerta de conflictos que detecta aviones que cruzan las trayectorias de vuelo, aun cuando los procedimientos de control normales especifican que debe utilizarse. Su estrategia de control está diseñada para asegurar que estos aviones se separarán antes de que ocurran problemas y consideran que la alarma de alerta de conflictos los distrae de su trabajo

2. Los requerimientos que se derivan de la cooperación y conocimiento de las actividades de la gente..

Por ejemplo, los controladores del tráfico aéreo pueden utilizar el conocimiento del trabajo de otros controladores para predecir el número de aviones que entrará en su sector de control. Después modifican sus estrategias de control dependiendo del volumen de trabajo pronosticado. Por lo tanto, un sistema automático de control del tráfico aéreo debe permitir a los controladores en un sector tener alguna visibilidad del trabajo en los sectores adyacentes.

La etnografía se puede combinar con la construcción de prototipos.

La etnografía suministra información al desarrollo del prototipo de forma que se requieren menos ciclos de refinamiento.

Además, la construcción de prototipos se centra en la etnografía para identificar problemas y preguntas que se puedan discutir posteriormente con el etnógrafo.

Ventajas:

Los estudios etnográficos pueden revelar los detalles de los procesos críticos que otras técnicas de obtención de requerimientos a menudo olvidan.

Desventajas:

Sin embargo, puesto que se centran en el usuario final, este enfoque no es apropiado para descubrir los requerimientos organizacionales o del dominio.

Los estudios etnográficos no siempre pueden identificar nuevas propiedades que se deban agregar al sistema. Por lo tanto, la etnografía no es un enfoque completo para la obtención de requerimientos por sí mismo, y debe utilizarse para complementar otros enfoques, como el análisis de casos de uso.

REUNIONES

Cuando los diferentes aspectos en relación a un tema son conocidos por distintas personas es preciso reunirlas para obtener una información lo más completa posible sobre dicho tema. El responsable de la reunión suele ser el desarrollador.

Existen una serie de problemas específicos para la aplicación de esta técnica, fundamentalmente los derivados de la dinámica de grupos.

JAD (Joined Application Development, Desarrollo Conjunto de Aplicaciones)

Surgen con fuerza para resolver dos de los problemas que presentan las entrevistas:

Los conflictos entre requisitos al entrevistar por separado a distintos usuarios y el alargamiento en el tiempo debido a las numerosas entrevistas.

Un JAD es una alternativa a las entrevistas, que consiste en un proceso acelerado de reuniones en el cual todos los usuarios y analistas se reúnen de forma intensiva (puede durar desde un día a una semana) para documentar los requisitos. Normalmente un especialista supervisa las reuniones y actúa como mediador para promover una mejor comunicación entre analistas y usuarios.

La idea del JAD es:

Aprovechar la dinámica de grupos.

Aprovechar toda clase de ayudas visuales, de comunicación y comprensión de soluciones.

Realizar un trabajo sistemático y organizado.

El método utilizado se divide en:

Preparación: Seleccionar los participantes, recabar información sobre el sistema a construir y organizar la reunión (lugar, fecha, ayudas audiovisuales, redacción de un documento de trabajo...).

Sesión JAD: Consiste en diversas reuniones bien estructuradas y organizadas donde se parte de un documento de trabajo que hay que analizar para completar los requisitos del sistema, documento que deberá ser aprobado por los presentes. El jefe del JAD es el responsable de conseguir que las reuniones sean productivas y de mantener el orden.

Documentación: Aunque el documento final debería estar terminado al final de las sesiones JAD, lo cierto es que es preciso completarlo, organizarlo, etc., para tener el documento es su forma final.

El JAD es difícil de llevar a la práctica al tener que disponer de numerosos usuarios simultáneamente, lo que puede provocar un parón en la producción.

EXAMEN DE ARCHIVOS

Técnica básica para obtener información cuantitativa: volúmenes, frecuencias, tendencias, ratios, etc.

También proporciona ayuda para medir el nivel de confianza que se puede depositar en las estimaciones cuantitativas dadas por el usuario.

MUESTREOS

Es útil cuando se pide información relativa a un gran volumen de documentos o actividades que se repiten con mucha frecuencia. En este caso es aceptable examinar documentos o actividades escogidas al azar.

Por lo menos, debería realizar un muestreo aleatorio simple con un tamaño de muestra de 30 individuos.

CUESTIONARIOS

Son difíciles de diseñar y de interpretar, por lo que su uso debe restringirse a los casos de localidades remotas o cuando la información deba proporcionarla un número elevado de personas.

BIBLIOGRAFÍA N°1

Libro: “Fundamentos de Ingeniería del Software”

Autor: Ian Sommerville

Editorial: Pearson

Capitulo: 7

Página: 132-144

2.2 TÉCNICAS DE LA INGENIERÍA DE REQUISITOS

El proceso de Ingeniería de Requerimientos describe de manera  detallada  y precisa  cada uno de los aspectos del ciclo de vida de un conjunto de requerimientos. Este proceso presenta dos grandes ramas: Desarrollo de requerimientos. Administración  de requerimientos.Que tiene como propósito producir y analizarlos requerimientos de cliente, de producto y de componente de producto, incluye las siguientes actividades: Recolección, Análisis, Especificación y Verificación. Recolección: Es el Proceso a través del cual los clientes (compradores y/o usuarios) y el desarrollador (contratista) de un sistema de software; descubren, revisan, articulan, y entienden las necesidades de los usuarios del sistema y las restricciones que se dan sobre el software y el desarrollo del mismo. Algunas de las técnicas y herramientas más importantes para llevar a cabo la recolección de requerimientos son:

ENTREVISTAS

Método para descubrir hechos y opiniones que tienen los posibles usuarios y otros participantes dentro del sistema que se está desarrollando. A su vez se clasifican en:

Entrevistas cerradas: las preguntas ya están previstas, tienen un orden y una forma de ser planteadas que no pueden ser modificadas por el entrevistador. Es en realidad un cuestionario. 

Entrevistas abiertas: en las cuales no se preparan preguntas concretas, y, por el contrario, se discute con el entrevistado las expectativas que este tiene del sistema. 

SISTEMAS EXISTENTES

Esta técnica consiste en analizar distintos sistemas ya desarrollados que estén relacionados con el sistema a ser construido. Por un lado, podemos analizar las interfaces de usuario, observando el tipo de Información que se maneja y cómo es manejada, por otro lado también es útil analizar las distintas Salidas que los sistemas producen (listados, consultas, etc.), porque siempre pueden surgir nuevas ideas sobre la base de estas.

CASOS DE USO Y/O ESCENARIOS

Los casos de uso describen interacciones entre los usuarios y el sistema, enfatizando en lo que el usuario necesita del sistema. Los escenarios son ejemplos de sesiones de interacción entre el sistema y el usuario, donde un solo tipo de interacción entre los dos participantes es simulada y descrita. 

OBSERVACIÓN Y ANÁLISIS SOCIAL

La observación permite a los investigadores observar lo que los usuarios hacen actualmente en un determinado contexto. Esto permite superar problemas con los participantes del proyecto que realizan descripciones idealizadas o demasiado simplificadas de los procesos que se llevan a cabo en sus trabajos.

LLUVIA DE IDEAS

Son sesiones donde todos los participantes brindan sus ideas para obtener una solución a una problemática. Una lluvia de ideas está compuesta de dos fases: la fase de generación y la fase de evaluación. Durante la generación las ideas son recolectadas y es importante que no sean criticadas. Durante la evaluación de las ideas, las propuestas de solución deben ser evaluadas desde diferentes perspectivas. 

PROTOTIPOS 

Es programa de computador que implementa algunos de los requerimientos de un sistema. Este prototipo puede ser usado para colaborar con la definición de los requerimientos, o para facilitar la evaluación de alternativas de implementación de un sistema. 

Existen dos grandes tipos de prototipos:Los prototipos no funcionales o desechables (Throw away), que sirven para entender la dificultad y aclarar los requerimientos.

Los prototipos funcionales o evolutivos (Evolutionary) que permiten construir una aproximación del sistema de manera que se pueda proveer cierta funcionalidad del sistema final y usualmente se convierten en parte del mismo.

ANÁLISIS

Es el proceso de analizar las necesidades de los clientes y los usuarios   para llegar a una definición de los requerimientos de software. 

Dentro de las prácticas principales se encuentra:

JAD (Joint Application Development)

Esta práctica se basa en la creación de espacios que permitan celebrar sesiones o reuniones en donde los participantes y directos interesados dentro del desarrollo del proyecto buscan obtener o generar conocimiento alrededor del desarrollo que se va a llevar a cabo. En estas sesiones se trabaja bajo un enfoque común que permite el fácil entendimiento de los temas expuestos por parte de los invitados a la sesión

BIBLIOGRAFÍA N°2

http://tecnologicofch.blogspot.mx/2013/03/22-tecnicas-de-la-ingenieria-de.html

Autor: francis coronel,

Publicado: lunes, 11 de marzo de 2013

http://ithjuanah.blogspot.mx/

Autor: Juana Hernández Hernández

2.3. Modelado de Requisitos

Objetivos del Modelado de Requisitos:

Entender los conceptos de requerimientos del usuario y del sistema, así como por qué tales requerimientos se deben escribir en diferentes formas.

Comprender las diferencias entre requerimientos de software funcional y no funcional.

Reconocer cómo se organizan los requerimientos dentro de un documento de requerimientos de software.

Conocer las principales actividades de la ingeniería de requerimientos: adquisición, análisis y validación, así como las relaciones entre dichas actividades.

Analizará por qué es necesaria la administración de requerimientos y cómo ésta apoya otras actividades de la ingeniería de requerimientos.

Casos de Uso

Los casos de uso son una técnica de descubrimiento de requerimientos que se introdujo por primera vez en el método Objectory (Jacobson et al., 1993). Ahora se ha convertido en una característica fundamental del modelado de lenguaje unificado. En su forma más sencilla, un caso de uso identifica a los actores implicados en una interacción, y nombra el tipo de interacción. Entonces, esto se complementa con información adicional que describe la interacción con el sistema. La información adicional puede ser una descripción textual, o bien, uno o más modelos gráficos como una secuencia UML (Lenguaje de Modelado Unificado) o un gráfico de estado.

Los casos de uso se documentan con el empleo de un diagrama de caso de uso de alto nivel. El conjunto de casos de uso representa todas las interacciones posibles que se describirán en los requerimientos del sistema. Los actores en el proceso, que pueden ser individuos u otros sistemas, se representan como figuras sencillas. Cada clase de interacción se constituye como una elipse con etiqueta. Líneas vinculan a los actores con la interacción. De manera opcional, se agregan puntas de flecha a las líneas para mostrar cómo se inicia la interacción. Esto se ilustra en la figura 4.15, que presenta algunos de los casos de uso para el sistema de información del paciente.

Los casos de uso identifican las interacciones individuales entre el sistema y sus usuarios u otros sistemas. Cada caso de uso debe documentarse con una descripción vincularse con otros modelos en el UML que desarrollará el escenario con más detalle.

Captura de Requerimientos (La Entrevista)

Los requerimientos se derivan de las respuestas a dichas preguntas. Las entrevistas son de dos tipos:

• 1. Entrevistas cerradas, donde los participantes responden a un conjunto de preguntas preestablecidas.

• 2. Entrevistas abiertas, en las cuales no hay agenda predefinida. El equipo de ingeniería de requerimientos explora un rango de conflictos con los participantes del sistema y, como resultado, desarrolla una mejor comprensión de sus necesidades.

Por dos razones resulta difícil asimilar el conocimiento de dominio a través de entrevistas:

• 1. Todos los especialistas en la aplicación usan terminología y jerga que son específicos de un dominio. Es imposible que ellos discutan los requerimientos de dominio sin usar este tipo de lenguaje. Por lo general, usan la terminología en una forma precisa y sutil, que para los ingenieros de requerimientos es fácil de malinterpretar.

• 2. Cierto conocimiento del dominio es tan familiar a los participantes que encuentran difícil de explicarlo, o bien, creen que es tan fundamental que no vale la pena mencionarlo. Por ejemplo, para un bibliotecario no es necesario decir que todas las adquisiciones deben catalogarse antes de agregarlas al acervo. Sin embargo, esto quizá no sea obvio para el entrevistador y, por lo tanto, es posible que no lo tome en cuenta en los requerimientos.

En general, la mayoría de las personas se muestran renuentes a discutir los conflictos políticos y organizacionales que afecten los requerimientos. Los entrevistadores efectivos poseen dos características:

• 1. Tienen mentalidad abierta, evitan ideas preconcebidas sobre los requerimientos y escuchan a los participantes. Si el participante aparece con requerimientos tienen disposición para cambiar su mentalidad acerca del sistema.

• 2. Al entrevistado con una pregunta de trampolín para continuar la plática, dar una propuesta de requerimientos o trabajar juntos en un sistema de prototipo. Cuando se pregunta al individuo “dime qué quieres” es improbable que alguien consiga información útil. Encuentran mucho más sencillo hablar en un contexto definido que en términos generales.

Las actividades del proceso

• Descubrimiento de requerimientos: participantes del sistema para descubrir sus requerimientos. También los requerimientos de dominio de los participantes y la documentación se descubren durante esta actividad.

• Clasificación y organización de requerimientos: compilación no estructurada de requerimientos, agrupa requerimientos relacionados y los organiza en grupos coherentes. La forma más común de agrupar requerimientos es

• Usar un modelo de la arquitectura del sistema: para identificar subsistemas y asociar los requerimientos con cada subsistema. En la práctica, la ingeniería de requerimientos y el diseño arquitectónico no son actividades separadas completamente.

• Priorización y negociación de requerimientos: en diversos participantes, los requerimientos entrarán en conflicto. Esta actividad se preocupa por priorizar los requerimientos, así como por encontrar y resolver conflictos de requerimientos mediante la negociación. Por lo general, los participantes tienen que reunirse para resolver las diferencias y estar de acuerdo con el compromiso de los requerimientos.

• Especificación de requerimientos: Los requerimientos se documentan e ingresan en la siguiente ronda de la espiral.

Espiral de Procesos de Ingeniería de Requerimientos

Puntos Clave para el Modelado de Requerimientos

• Los requerimientos para un sistema de software establecen lo que debe hacer el sistema y definen las restricciones sobre su operación e implementación.

• Los requerimientos funcionales son enunciados de los servicios que debe proporcionar el sistema, o descripciones de cómo deben realizarse algunos cálculos.

• Los requerimientos no funcionales restringen con frecuencia el sistema que se va a desarrollar y el proceso de desarrollo a usar. Éstos pueden ser requerimientos del producto, requerimientos organizacionales o requerimientos externos. A menudo se relacionan con las propiedades emergentes del sistema y, por lo tanto, se aplican al sistema en su conjunto.

• El documento de requerimientos de software es un enunciado acordado sobre los requerimientos del sistema. Debe organizarse de forma que puedan usarlo tanto los clientes del sistema como los desarrolladores del software.

• El proceso de ingeniería de requerimientos incluye un estudio de factibilidad, adquisición y análisis de requerimientos, especificación de requerimientos, validación de requerimientos y administración de requerimientos.

• La adquisición y el análisis de requerimientos es un proceso iterativo que se representa como una espiral de actividades: descubrimiento de requerimientos, clasificación y organización de requerimientos, negociación de requerimientos y documentación de requerimientos.

• La validación de requerimientos es el proceso de comprobar la validez, la consistencia, la totalidad, el realismo y la verificabilidad de los requerimientos.

• Los cambios empresariales, organizacionales y técnicos conducen inevitablemente a cambios en los requerimientos para un sistema de software. La administración de requerimientos es el proceso de gestionar y controlar dichos cambios.

BIBLIOGRAFIA 1

1. INGENIERIA DE SOFTWARE ,Ian Somerville, 9ª Edición, Capitulo 4º Ingeniería de Requerimientos pág.82

2.3. Modelado de Requisitos

Objetivos del 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). El modelo de casos de uso y el propio modelo de requisitos son la base para los demás modelos.

Herramientas más Usadas

Entrevistas y cuestionarios: Las entrevistas y cuestionarios se emplean para reunir información proveniente de personas o grupos, información que se obtiene conversando con el encuestado. Las preguntas suelen distinguirse en dos categorías: abiertas y cerradas. Las preguntas abiertas permiten que los encuestados respondan con su propia terminología, mientras que las preguntas cerradas predeterminan todas las posibles respuestas y el interrogado elige entre las opciones presentadas.

Grabaciones de video y de audio: Básicamente existen dos formas de utilizar las grabaciones: como registro y apoyo de las entrevistas, y para analizar algún proceso en particular. En cuanto a su función de apoyo, es importante porque permite centrar la atención en la entrevista en sí, en vez de distraerse tomando notas de todo lo que se dice. Cuando se trata de analizar algún proceso en particular, su ayuda es inestimable (sobre todo

las filmaciones de video) porque permite ver y analizar en detalle ese proceso la cantidad de veces que sea necesario.

Brainstorming (tormenta de ideas): Este es un modelo que se usa para generar ideas. La intención en su aplicación es la de generar la máxima cantidad posible de requisitos para el sistema. No hay que detenerse en pensar si la idea es o no del todo utilizable.

Fases del Modelado de Requisitos

Fases del Modelado de Requisitos

Fase de concepción (análisis)Esta fase tiene como propósito definir y acordar el alcance del proyecto con los patrocinadores, identificar los riesgos potenciales asociados al proyecto, proponer una visión muy general de la arquitectura de software y producir el plan de las fases y el de iteraciones.

Fase de elaboración (diseño)En la fase de elaboración se seleccionan los casos de uso que permiten definir la arquitectura base del sistema y se desarrollaran en esta fase, se realiza la especificación de los casos de uso seleccionados y el primer análisis del dominio del problema, se diseña la solución preliminar.

Fase de construcción (implementación) El propósito de esta fase es completar la funcionalidad del sistema, para ello se

deben clarificar los requerimientos pendientes, administrar los cambios de acuerdo a las evaluaciones realizados por los usuarios y se realizan las mejoras para el proyecto.

Fase de transición (pruebas)El propósito de esta fase es asegurar que el software esté disponible para los usuarios finales, ajustar los errores y defectos encontrados en las pruebas de aceptación, capacitar a los usuarios y proveer el soporte técnico necesario. Se debe verificar que el producto cumpla con las especificaciones entregadas por las personas involucradas en el proyecto.

 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.

1. 2.http://www.utvm.edu.mx/OrganoInformativo/orgJul07/RUP.htm

2. 3. http://w ww.infor.uva.es/~mlaguna/is1/apuntes/2-requisitos.pdf

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 este post se hace referencia a 3 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.  

IRQA

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.

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.

RETO

Esta herramienta propone un modelo de requisitos para capturar los aspectos funcionales del sistema, básicamente, mediante tres técnicas complementarias entre si: la definición de la misión del sistema, la construcción del árbol de refinamiento de funciones y el desarrollo de modelo de uso.

OSRMT

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.  

JEREMIA

Se trata de una aplicación cliente exclusivamente, lo cual no permite la posibilidad de trabajar en equipo. Esta herramienta ayuda durante el desarrollo del sistema, especialmente con el seguimiento de cambio de los requisitos a lo largo del ciclo de vida.

RAMBUTAN

Esta herramienta esta basada en XML, realmente consta de un conjunto de aplicaciones para el usuario final ayudando a los analistas del sistema en la recopilación y la categorización de hechos en un documento de especificación de requisito.

En comparación con otras herramientas la gestión de requisitos rambután y las ofrecen la<s siguientes ventajas competitivas: aplicación del cliente (PDA- class) portabilidad entre plataformas, independiente a cualquier metodología de especificación de requisitos herramientas de distribución libre.

Fuente:

http://unidad2requerimientos.blogspot.mx/

2.4 Herramientas CASE para la ingeniería de requisitos

Borland Caliber Analyst

Se trata de un producto que está compuesto por dos aplicaciones desarrolladas por la compañía Borland.

Por un lado está el Caliber DefineIT (la última de las herramientas en cuanto a fecha de lanzamiento) que permite definir los requisitos del sistema así como capturar los diferentes escenarios de negocio a través de diferentes herramientas visuales; es necesario señalar que este software es compatible con gran número de herramientas existentes en el mercado.

CASE Spec

Esta herramienta está desarrollada por la empresa Goda Software, siendo esta una aplicación comercial de uso exclusivo para el sistema operativo Windows.

Las principales características que avalan a esta herramienta son las siguientes:

Especificación: posibilidad de realizar las especificaciones tanto con las técnicas tradicionales como con los diagramas de casos de uso. Además, nos permite crear diagramas UML y de flujo de datos.

Seguimiento de los requisitos: a través del uso combinado de un procesador de textos y una hoja de cálculo, el usuario será capaz de realizar el seguimiento de los requisitos así como hacer un informe acerca de los mismos.

Capacidad de rastreo: mediante la existencia de una matriz se representan de manera sencilla las diferentes relaciones existentes entre los requisitos definidos y otra serie de elementos incidentes en el proyecto.

IRQA 4

Herramienta desarrollada por Visure y que tiene la meta de servir como aplicación para proporcionar un soporte integral en la ingeniería de requisitos de un proyecto de informática.

A parte de incluir las tareas más básicas de la ingeniería de requisitos (captura, análisis, modelado, organización y seguimiento).

Tiger Pro

Estamos ante una herramienta shareware desarrollada para facilitar al usuario la tarea de redactar los requerimientos de un proyecto. Este aplicativo es capaz de solucionar algunos de los defectos que aparecen a la hora de definir los requisitos de un programa. También ayuda al usuario a aclarar algunos de los requerimientos desde el punto de vista de las pruebas a realizar, señalando aquellos requerimientos cuya verificación pueda resultar complicada.

GatherSpace

A la hora de realizar la definición de los requisitos para un proyecto de informática, el trabajo conjunto de todo el equipo de desarrollo es una parte fundamental para conseguir un buen resultado. Esta herramienta de definición y gestión de requisitos utiliza Internet como su lanzadera, ya que no es necesario instalar ningún programa para utilizarla: bastará con crear una cuenta en el sitio web de la misma y comenzar a definir el proyecto que se quiere desarrollar.

IBM Rational Requisite Pro

Esta herramienta, desarrollada por una de las compañías más importantes dentro del campo de la informática, se considera una de las herramientas más completas y potentes dentro del análisis y la gestión de los requisitos.

Bibliografía:http://ldc.usb.ve/~abianc/materias/ci4712/apuntes3.pdfhttp://www.rodolfoquispe.org/blog/que-es-la-ingenieria-de-requisitos.php