Materia: Fundamentos de Ingeniería de Software. Catedrático: Lic. María de los Ángeles Martínez Morales.

Actividad: Investigación sobre las Técnicas que se implementan En la Ingeniería de Requisitos

Semestre: 5

Grupo: A

Unidad 2. Ingeniería de Requisitos Dirección del blog:

http://teleysoft.blogspot.mx/

Integrantes:
Cruz Díaz Estela Morales de la Cruz Miguel Ángel Moreno Serrano Ana Karen Osorio Leyva Mizraim Sánchez Enríquez Francisco de Jesús Villanueva Arroyo Eydi Reyes Montes Eduardo

San Juan Bautista Tuxtepec, Septiembre 19, 2012

CONTENIDO

En la presente investigación se reúnen las técnicas más usuales que se aplican en las diversas tareas de la ingeniería de requisitos, para ello, este texto se divide en varias secciones para una mejor comprensión, esto claro siguiendo una rúbrica de trabajo, proporcionada con anterioridad. El trabajo se divide en introducción, donde se explica en forma concreta las ideas más relevantes de toda la investigación, además está el desarrollo que es la parte más importante, ya que es donde se expone la investigación misma, y también se presenta una conclusión, en donde se muestra lo aprendido del trabajo, sin mencionar que como toda investigación formal, también se anexan las referencias, las cuales son los sitios web de donde se obtuvo la información. Esperamos que esta investigación sea fácil de comprender.

INTRODUCCIÓN

Desde el surgimiento del desarrollo de sistemas de cómputo se ha podido constatar que los requerimientos o requisitos son una pieza fundamental en un proyecto de desarrollo de software, ya que marcan el punto de partida para actividades como la planeación, 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. Con ayuda de los requerimientos se logra establecer si se alcanzaron o no los objetivos establecidos en el proyecto, puestos que estos son 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. De hecho es muy frecuente que un proyecto de software fracase si no se realiza una adecuada definición, especificación, y administración de los requerimientos, los cuales obviamente son especificados por el que será usuario del sistema. Afortunadamente existen técnicas que permiten entender con mayor claridad los requerimientos del usuario, para de este modo minimizar los problemas relacionados por la mala gestión de los requisitos en el desarrollo de sistemas, algunas de estas técnicas son las que serán el punto de este texto.

Existen varias técnicas para la IR propuestas para ingeniería de requerimientos, las cuales se expondrán a continuación. Es importante resaltar que estas técnicas pueden ser aplicables a las distintas fases del proceso de la IR, haciendo la salvedad de que hay que tomar en cuenta las características propias del proyecto en particular que se esté desarrollándose para aprovechar al máximo su utilidad.

Entrevistas y Cuestionarios
Las entrevistas y cuestionarios se emplean para reunir información proveniente de personas o de grupos. Durante la entrevista, el analista conversa con el encuestado; el cuestionario consiste en una serie de preguntas relacionadas con varios aspectos de un sistema. Por lo común, los encuestados son usuarios de los sistemas existentes o usuarios en potencia del sistema propuesto. En algunos casos, son gerentes o empleados que proporcionan datos para el sistema propuesto o que serán afectados por él. Las preguntas que deben realizarse en esta técnica, deben ser preguntas de alto nivel y abstractas que pueden realizarse al inicio del proyecto para obtener información sobre aspectos globales del problema del usuario y soluciones potenciales. Las preguntas pueden ser enfocadas a un elemento del sistema, tales como usuarios, procesos, etc. El siguiente ejemplo muestra algunos tipos de preguntas abiertas: Del usuario     ¿Quién es el cliente? ¿Quién es el usuario? ¿Son sus necesidades diferentes? ¿Cuáles son sus habilidades, capacidades, ambiente?

Del proceso  ¿Cuál es la razón por la que se quiere resolver el problema?

  

¿Cuál es el valor de una solución exitosa? ¿Cómo usted resuelve el problema adecuadamente? ¿Qué retrasos ocurren o pueden ocurrir?

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

El éxito de esta técnica, depende de la habilidad del entrevistador y de su preparación para la misma.

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.

Lluvia de ideas (Brainstorm)
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 requerimientos para el sistema. No hay que detenerse en pensar si la idea es o no del todo utilizable. La intención de este ejercicio es generar, en una primera instancia, muchas ideas. Luego, se irán eliminando en base a distintos criterios como, por ejemplo, "caro", "impracticable", "imposible", etc.

Las reglas básicas a seguir son:  Aplazar el juicio y no realizar críticas, hasta que no se agoten las ideas, ya que actuaría como un inhibidor. Se debe crear una atmosfera de trabajo en la que nadie se sienta amenazado.  Los participantes deben pertenecer a distintas disciplinas y,

preferentemente, deben tener mucha experiencia. Esto trae aparejado la obtención de una cantidad mayor de ideas creativas.  Conviene suspender el juicio crítico y se debe permitir la evolución de cada una de las ideas, porque si no se crea un ambiente hostil que no alienta la generación de ideas.  Cuantas más ideas se sugieren, mejores resultados se conseguirán: “La cantidad produce la calidad”. Las mejores ideas aparecen tarde en el periodo de producción de ideas, será más fácil que se encuentren las soluciones y se tendrá más variedad sobre la que hay que elegir  Por más locas o salvajes que parezcan algunas ideas, no se las debe descartar, porque luego de maduradas probablemente se tornen en un requerimiento sumamente útil.   A veces ocurre que una idea resulta en otra idea, y otras veces podemos relacionar varias ideas para generar una nueva. Escribir las ideas sin censura.

Una de las fases de aplicación más importante de la lluvia de ideas es la creación de prototipos, esto debido a que durante la actividad de extracción de requerimientos, puede ocurrir que algunos de estos no estén demasiado claros o que no se esté muy seguro de haber entendido correctamente los requerimientos obtenidos hasta el momento, todo lo cual puede llevar a un desarrollo no eficaz del sistema final. Entonces, para validar los requerimientos hallados, se construyen prototipos. Los prototipos son simulaciones del posible producto, que luego son utilizados por el usuario final, permitiéndonos conseguir una importante retroalimentación en

cuanto a si el sistema diseñado con base a los requerimientos recolectados le permite al usuario realizar su trabajo de manera eficiente y efectiva. El desarrollo del prototipo comienza con la captura de requerimientos. Desarrolladores y clientes se reúnen y definen los objetivos globales del software, identifican todos los requerimientos que son conocidos, y señalan áreas en las que será necesaria la profundización en las definiciones. Luego de esto, tiene lugar un “diseño rápido”. El diseño rápido se centra en una representación de aquellos aspectos del software que serán visibles al usuario (por ejemplo, entradas y formatos de las salidas). El diseño rápido lleva a la construcción de un prototipo.

Proceso de análisis jerárquico
Esta técnica tiene por objetivo resolver problemas cuantitativos, para facilitar el pensamiento analítico y las métricas. Consiste en una serie de pasos, a saber:       Encontrar los requerimientos que van a ser priorizados. Combinar los requerimientos en las filas y columnas de la matriz n x n de AHP. Hacer algunas comparaciones de los requerimientos de la matriz. Sumar las columnas. Normalizar la suma de las filas. Calcular los promedios.

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

Casos de Uso
Los casos de uso son una técnica para especificar el comportamiento de un sistema: “Un caso de uso es una secuencia de interacciones entre un sistema y alguien o algo que usa alguno de sus servicios”.

Todo sistema de software ofrece a su entorno una serie de servicios. Un caso de uso es una forma de expresar cómo alguien o algo externo a un sistema lo usa. Cuando se dice “alguien o algo” se hace referencia a que los sistemas son

usados no solo por personas, sino también por otros sistemas de hardware y software. Por ejemplo, un sistema de ventas, si pretende tener éxito, debe ofrecer un servicio para ingresar un nuevo pedido de un cliente. Cuando un usuario accede a este servicio, podemos decir que está “ejecutando” el caso de uso ingresando pedido. Los Casos de Uso fueron introducidos por Jacobson en 1992. Sin embargo, la idea de especificar un sistema a partir de su interacción con el entorno es original de Mc Menamin y Palmer, dos precursores del análisis estructurado, que escribieron en 1984 un excelente libro cuya lectura recomendamos. En ese libro, se define un concepto muy parecido al del caso de uso: el evento. Para Mc Menamin y Palmer, un evento es algo que ocurre fuera de los límites del sistema, ante lo cual el sistema debe responder. Siguiendo con nuestro ejemplo anterior, nuestro sistema de ventas tendrá un evento “Cliente hace Pedido”. En este caso el sistema deberá responder al estímulo que recibe –el pedido– procesándolo. Los casos de uso permiten entonces describir la posible secuencia de interacciones entre el sistema y uno o más actores, en respuesta a un estímulo inicial proveniente de un actor, es una descripción de un conjunto de escenarios, cada uno de ellos comenzado con un evento inicial desde un actor hacia el sistema. La mayoría de los requerimientos funcionales, sino todos, se pueden expresar con casos de uso. Según el autor Sommerville, los casos de uso son una técnica que se basa en escenarios para la obtención de requerimientos. Actualmente, se han convertido en una característica fundamental de la notación UML (Lenguaje de modelado unificado), que se utiliza para describir modelos de sistemas orientados a objetos.

CONCLUSIÓN
Con lo expuesto anteriormente se ha demostrado claramente que sin las técnicas apropiadas no sería capaz de obtener los requerimientos necesarios del cliente o usuario del sistema a desarrollar. Con ayuda de estas técnicas es posible obtener y comprender de manera precisa las necesidades del usuario, ya que muchas veces esta se vuelve confusa, ya sea por el hecho de que el mismo no supo especificarse o porque el desarrollador de software no fue capaz de comprender las indicaciones proporcionadas. Además cabe recordar, que sin los requerimientos no sería posible construir un sistema, ya que no hay forma de saber cuál es la función deseada para este, es ahí donde se demuestra la importancia de aplicar correctamente las técnicas de la Ingeniería de Requisitos.

REFERENCIAS

Ceria, S. (s.f.). ingeniería de software I. Recuperado el 16 de 09 de 2012, de ingeniería de software I: http://www-2.dc.uba.ar/materias/isoft1/2001_2/apuntes/CasosDeUso.pdf

Hernández, L. L. (2005). universidad autonoma del estado de hidalgo. Recuperado el 16 de 09 de 2012, de universidad autonoma del estado de hidalgo: http://dgsa.uaeh.edu.mx:8080/bibliotecadigital/bitstream/231104/415/1/Ingenieria%20d e%20requerimientos.pdf

Silvia Mónica Aranguren, M. E. (2012). sedici. Recuperado el 16 de 09 de 2012, de sedici: http://sedici.unlp.edu.ar/bitstream/handle/10915/19098/Documento_completo.%20Nue vas%20estrategias.pdf?sequence=1