CARRERA: Ingeniera en Sistemas computacionalesMATERIA: Fundamentos de Ingeniera SoftwarePROFESORA: Ing. Mara Nancy CastroINTEGRANTES DEL EQUIPO:Jos Luis Bautista Gmez 11320513Sergio Guadalupe Galeana Escobar 11320550Daniel Bautista Pea 11320514Fabin Alejandro Alegra Valencia 11320496Luis Antonio Vizcarra Vazquez 11320693HORARIO: 15:00-16:00AULA: 706CICLO ESCOLAR: Enero-Junio10 de Abril del 2014UNIDAD 2INGENIERIA DE REQUERIMIENTOS

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, adems 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 imaginaramos un mundo sin computadoras, sin tecnologa; es gracias a ello que la ingeniera de software se basa en modelos, mtodos y herramientas que sirven como una gua 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 evaluacin y medicin de los mismos.El propsito de la ingeniera de requisitos es hacer que los mismos alcancen un estado ptimo antes de alcanzar la fase de diseo en el proyecto. Los buenosrequisitosdeben ser medibles, comprobables, sin ambigedades o contradicciones, etc.Entonces, la tarea ms importante que el ingeniero de software hace para el cliente es la extraccin iterativa y el refinamiento de los requerimientos del producto.

INTRODUCCIN

A travs de los aos 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 planeacin, bsicamente en lo que se refiere a las estimaciones de tiempos y costos, as como la definicin de recursos necesarios y la elaboracin de cronogramas que ser uno de los principales mecanismos de control con los que se contar durante la etapa de desarrollo. Adems la especificacin 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 estn cumpliendo las metas trazadas.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 requerimientos. Dentro de esa mala administracin se pueden encontrar factores como la falta de participacin del usuario, requerimientos incompletos y el mal manejo del cambio a los requerimientos.

UNIDAD 2 INGENIERIA DE LOS REQUERIMIENTOSLa Ingeniera de Requerimientos (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 requerimientos en el desarrollo de sistemas.Qu son requisitos requerimientos?Se presenta a continuacin la definicin existente en el glosario de la IEEE de lo que es un Requerimiento: 1. Una condicin o necesidad de un usuario para resolver un problema o alcanzar un objetivo. (Std 610.12-1900, IEEE: 62)2. 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. (Std 610.12-1900, IEEE: 62)Tambin, Ian Sommerville presenta una definicin acerca de lo que es un Requerimiento:3. Un requerimiento es simplemente una declaracin abstracta de alto nivel de un servicio que debe proporcionar el sistema o una restriccin de ste. (Sommerville, 2005: 108)Caractersticas 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 cmo se sabe si se cumpli con l o no? Conciso: Un requerimiento es conciso si es fcil de leer y entender. Su redaccin 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 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.Definicin de Requerimientos Ingeniera de Requerimientos 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. (Pressman, 2006: 155)

BIBLIOGRAFIA 1 Autor: Pressman, Roger S. Ao de Edicin: 2006, Libro: Ingeniera del Software: Un enfoque prctico Sexta edicin, Mxico DF, Editorial McGraw Hill. Pgina:155-165

Ingeniera de requisitos La ingeniera de requerimientos es el proceso de desarrollar una especificacin de software. Las especificaciones pretender comunicar las necesidades del sistema del cliente a los desarrolladores del sistema. (Sommerville, 2005: 82)

Sntesis de Requerimientos En sntesis, el proceso de ingeniera de requerimientos se utiliza para definir todas las actividades involucradas en el descubrimiento, documentacin 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 obtencin y anlisis de requerimientos, su especificacin formal, para finalizar con el subproceso de validacin 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 difciles de expresar en palabras (el lenguaje es ambiguo). La cantidad de requerimientos en un proyecto puede ser difcil 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 Extraccin: 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. Anlisis: se leen los requerimientos, se conceptan, 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. Especificacin: Es el "pasar en limpio" el anlisis realizado previamente aplicando tcnicas y/o estndares de documentacin, como la notacin UML (Lenguaje de Modelado Unificado), que es un estndar para el modelado orientado a objetos, por lo que los casos de uso y la obtencin de requerimientos basada en casos de uso se utiliza cada vez ms para la obtencin de requerimientos. Validacin: 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 descripcin, por lo menos, aceptable del sistema que se debe implementar. Esto implica verificar que los requerimientos sean consistentes y que estn completos. BIBLIOGRAFIA 2 Autor: Sommerville Ian Ao de Edicin: 2005 Libro: Ingeniera del Software Sptima edicin, Mxico DF, Editorial Pearson. Pgina: 82-90

2.1 Tareas de la ingeniera de requisitosLa ingeniera de requisitos proporciona el mecanismo apropiado para entender lo que el cliente quiere, analizar las necesidades, evaluar la factibilidad, negociar una solucin razonable, especificar la solucin sim ambigedades, validar la especificacin, y administrar los requisitos conforme estos se transformar en un sistema operacional. El proceso de la ingeniera de requisitos se lleva a cabo a travs de siete distintas funciones: inicio, obtencin, elaboracin, negociacin, especificacin, validacin y gestin.InicioEn algunos casos, una conversacin informal es todo lo que se necesita para precipitar un esfuerzo importante de ingeniera del software. Pero en general, la mayora de los proyectos comienza cuando se identifica una necesidad de negocios o se descubren un nuevo mercado o servicio potencial.ObtencinDebemos hablar con el cliente y otros interesados de cules 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 da a da.Para ello se debe identificar una serie de problemas que ayudan a entender por qu es difcil la obtencin de requisitos: Problemas de mbito: El lmite del sistema est mal definido o los clientes especifican detalles tcnicos innecesarios que pueden confundir, en lugar de clarificar, los objetivos generales del sistema. Problemas de compresin: Los clientes no estn 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 informacin 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 recopilacin de requisitos.ElaboracinLa informacin conseguida con el cliente durante el inicio y la obtencin se expande y se refina durante la elaboracin. Esta actividad de la ingeniera de requisitos se enfoca en el desarrollo de un modelo tcnico refinado de las funciones, caractersticas y restricciones del software.Negociacin:En esta etapa el ingeniero de requisitos debe negociar con el cliente los alcances y lmites 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.Especificacin:Es el producto final de la ingeniera de requisitos, y se convierte en la materia prima para las actividades posteriores en el proceso de desarrollo del sistema. Una especificacin puede ser un documento escrito, un conjunto de modelos grficos, un modelo matemtico formal, una coleccin de escenarios de uso, un prototipo o cualquier combinacin de estos.ValidacinLa calidad de los productos de trabajo procedentes de la ingeniera de requisitos se evala durante un paso de validacin. La validacin de requisitos se examina la especificacin 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 estndares establecidos para el proceso, proyecto y producto.Gestin de requisitosLa gestin 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 gestin de requisitos comienza con la identificacin. 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 estn las siguientes: De caractersticas: Muestra la manera en que los requisitos se relacionan con las caractersticas 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 estn relacionados entre s. De subsistema: Establece categoras entre los requisitos de acuerdo con los subsistemas que gobiernan. De interfaz: Muestra la forma en que los requisitos se relacin con las interfaces internas y externas del sistema.BIBLIOGRAFIA:Libro: Ingeniera de software un enfoque practicoEdicin: SextaAutor: Roger S. PressmanEditorial: Mc Graw HillPaginas: 157-1622.1 Tareas de la ingeniera de requisitosSe define como un conjunto de actividades en los cuales, utilizando tcnicas y herramientas, se analiza un problema y se concluye con la especificacin de una solucin. La ingeniera de requisitos es el proceso de desarrollar una especificacin de software.Extraccin:Esta fase representa el comienzo de cada ciclo. Extraccin es el nombre comnmente dado a las actividades involucradas en el descubrimiento de los requisitos del sistema.Anlisis:Sobre la base de la extraccin realizada previamente, comienza esta fase en la cual se enfoca en descubrir problemas con los requisitos del sistema identificados hasta el momento.Especificacin:En esta fase se documentan los requisitos acordados con el cliente, en un nivel apropiado de detalle.Validacin:La validacin 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 descripcin, por lo menos, aceptable del sistema que se debe implementar. Esto implica verificar que los requisitos sean consistentes y que estn completos.LINKOGRAFIA:http://ithjuanah.blogspot.mx/

2.2 TCNICAS DE LA INGENIERA DE REQUISITOSINTRODUCCIN Las tcnicas de la ingeniera de requisitos nos permiten recoger informacin sobre el sistema propuesto y los existentes y extraer los requerimientos del usuario y del sistema de esta informacin. Las fuentes de informacin durante la fase del descubrimiento de requerimientos incluyen la documentacin, los stakeholders del sistema y la especificacin de sistemas similares. Los stakeholders son todos aquellos individuos que interactan 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 continuacin se describen tcnicas de descubrimiento de requerimientos entre las que se incluyen entrevistas, escenarios y etnografa.ENTREVISTASLas entrevistas formales o informales con los stakeholders del sistema son parte de la mayora de los procesos de la ingeniera de requerimientos. En estas entrevistas, el equipo de ingeniera 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 ingeniera de requerimientos examina una seria de cuestiones con los stakeholders del sistema y, por lo tanto, desarrolla una mejor comprensin de sus necesidades.

En la prctica, las entrevistas con los stakeholders normalmente son una mezcla de stos.Las entrevistas tambin requieren de un mtodo que podemos establecer en los siguientes pasos: Planificacin de la entrevista (antes de realizar la entrevista): Fijar a quin se debe entrevistar, contando con la aprobacin previa. Se informa al entrevistado con antelacin del contenido de la entrevista, y se rene toda la informacin existente sobre el contenido antes de realizar la entrevista. Finalmente, convenir da, hora y lugar. Realizacin de la entrevista: Deber llevarse a cabo en un ambiente apropiado y lo ms 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 ms 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 tentacin de argumentar, dar consejos o envolver emocionalmente al entrevistado (ya que esto ltimo modificar su actitud de cara a prximas entrevistas). Finalizacin de la entrevista: Verificaremos las notas con la persona entrevistada, le expresaremos nuestro agradecimiento y dejaremos el camino abierto para nuevos contactos. Consolidacin (despus 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 relacin a su contenido y conseguir que el usuario lo apruebe.ESCENARIOSNormalmente, las personas encuentran ms fcil dar ejemplos de la vida real que descripciones abstractas. Pueden comprender y criticar un escenario de cmo interactuar con un sistema software.Los ingenieros de requerimientos pueden utilizar la informacin obtenida de esta discusin para formular los requerimientos reales del sistema.Los escenarios pueden ser especialmente tiles para agregar detalle a un esbozo de la descripcin de requerimientos. Son descripciones de ejemplos de las sesiones de interaccin.Cada escenario abarca una o ms posibles interacciones. Se han desarrollado varias formas de escenarios, cada una de las cuales proporciona diferentes tipos de informacin en diferentes niveles de detalle sobre el sistema.El escenario comienza con un esbozo de la interaccin y, durante la obtencin, se agregan detalles para crear una descripcin completa de esta interaccin. De forma general, un escenario puede incluir:1. Una descripcin de lo que esperan el sistema y los usuarios cuando el escenario comienza.2. Una descripcin del flujo normal de eventos en el escenario.3. Una descripcin de lo que puede ir mal y cmo manejarlo.4. Informacin de otras actividades que se podran llevar a cabo al mismo tiempo.5. Una descripcin del estado del sistema cuando el escenario termina.Los escenarios se pueden redactar como texto, complementados por diagramas, fotografas de las pantallas, etctera.Ejemplo: Suposicin inicial: el usuario a entrado en el sistema LYBSIS y ha localizado la revista que contiene el artculo. Normal: el usuario selecciona el artculo a copiar. El sistema insta al usuario a proporcionar la informacin de suscriptor de la revista o a indicar a un mtodo de pago del artculo. El pago se puede efectuar mediante tarjeta de crdito o citando un nmero de cuenta. Se le solicita entonces al usuario que rellene un formulario de derechos de autor que mantiene los detalles de la transaccin y se enva al sistema LYBSIS. Se verifica el formulario de derechos de autor, y si se aprueba, se descarga la versin en PDF del artculo 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 artculo. Si el artculo es de sola impresin se elimina del sistema del usuario una vez que ste ha confirmado que se ha completado la impresin. 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 correccin. Si el formulario reenviado todava es incorrecto, se rechaza la peticin del artculo por parte del usuario. El sistema puede rechazar el pago, en cuyo caso se rechaza la peticin 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 sesin. Es posible que no pueda imprimir el artculo. Si el artculo no es de solo impresin, se mantiene en el espacio de trabajo del LYBSIS. De lo contrario el artculo se elimina y se lo cargan a la cuenta del usuario los costes del artculo. Otras actividades: descarga simultaneas de artculos. Estado del sistema a la finalizacin: el usuario est dentro del sistema. El artculo descargado se ha borrado del espacio de trabajo del LYBSIS si es de solo impresin.

CASOS DE USOSLos casos de uso son una tcnica que se basa en escenarios para la obtencin de requerimientos que se introdujeron por primera vez en el mtodo Objeiory (Jacobsen et ai., 1993).Actualmente se han convertido en una caracterstica fundamental de la notacin de UML, que se utiliza para describir modelos de sistemas orientados a objetos.

En su forma ms simple, un caso de uso identifica el tipo de interaccin y los actores involucrados. Los actores en el proceso se representan como figuras delineadas, y cada clase de interaccin 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 ms detalle.Segn Fowler (Fowler y Scott. 1997), un caso de uso encierra un conjunto de escenarios, y cada uno de stos es un hilo nico a travs del caso de uso.Los casos de uso son tcnicas eficaces para obtener requerimientos para los puntos de vista de los interactuadores, donde cada tipo de interaccin se puede representar como un caso de uso. Tambin se pueden utilizar conjuntamente con algunos puntos de vista indirectos cuando stos reciben resultados (como un informe de gestin) 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 extensin del ejemplo del LIBSYS y muestra otros casos de uso en ese entorno.ETNOGRAFA La etnografa es una tcnica de observacin 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 estn involucrados. El valor de la etnografa es que ayuda a los analistas a descubrir los requerimientos implcitos que reflejan los procesos reales ms que los formales en los que la gente est involucrada. La etnografa 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 ms que de la forma en la que las definiciones de los procesos establecen que debera trabajar. Por ejemplo, los controladores del trfico areo 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 diseada para asegurar que estos aviones se separarn antes de que ocurran problemas y consideran que la alarma de alerta de conflictos los distrae de su trabajo2. Los requerimientos que se derivan de la cooperacin y conocimiento de las actividades de la gente.. Por ejemplo, los controladores del trfico areo pueden utilizar el conocimiento del trabajo de otros controladores para predecir el nmero de aviones que entrar en su sector de control. Despus modifican sus estrategias de control dependiendo del volumen de trabajo pronosticado. Por lo tanto, un sistema automtico de control del trfico areo debe permitir a los controladores en un sector tener alguna visibilidad del trabajo en los sectores adyacentes.La etnografa se puede combinar con la construccin de prototipos. La etnografa suministra informacin al desarrollo del prototipo de forma que se requieren menos ciclos de refinamiento.

Adems, la construccin de prototipos se centra en la etnografa para identificar problemas y preguntas que se puedan discutir posteriormente con el etngrafo. Ventajas:Los estudios etnogrficos pueden revelar los detalles de los procesos crticos que otras tcnicas de obtencin 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 etnogrficos no siempre pueden identificar nuevas propiedades que se deban agregar al sistema. Por lo tanto, la etnografa no es un enfoque completo para la obtencin de requerimientos por s mismo, y debe utilizarse para complementar otros enfoques, como el anlisis de casos de uso.

REUNIONESCuando los diferentes aspectos en relacin a un tema son conocidos por distintas personas es preciso reunirlas para obtener una informacin lo ms completa posible sobre dicho tema. El responsable de la reunin suele ser el desarrollador.Existen una serie de problemas especficos para la aplicacin de esta tcnica, fundamentalmente los derivados de la dinmica 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 renen de forma intensiva (puede durar desde un da a una semana) para documentar los requisitos. Normalmente un especialista supervisa las reuniones y acta como mediador para promover una mejor comunicacin entre analistas y usuarios. La idea del JAD es: Aprovechar la dinmica de grupos. Aprovechar toda clase de ayudas visuales, de comunicacin y comprensin de soluciones. Realizar un trabajo sistemtico y organizado.El mtodo utilizado se divide en: Preparacin: Seleccionar los participantes, recabar informacin sobre el sistema a construir y organizar la reunin (lugar, fecha, ayudas audiovisuales, redaccin de un documento de trabajo...). Sesin 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. Documentacin: Aunque el documento final debera 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 difcil de llevar a la prctica al tener que disponer de numerosos usuarios simultneamente, lo que puede provocar un parn en la produccin.

EXAMEN DE ARCHIVOSTcnica bsica para obtener informacin cuantitativa: volmenes, frecuencias, tendencias, ratios, etc.Tambin proporciona ayuda para medir el nivel de confianza que se puede depositar en las estimaciones cuantitativas dadas por el usuario.

MUESTREOSEs til cuando se pide informacin 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, debera realizar un muestreo aleatorio simple con un tamao de muestra de 30 individuos.

CUESTIONARIOS Son difciles de disear y de interpretar, por lo que su uso debe restringirse a los casos de localidades remotas o cuando la informacin deba proporcionarla un nmero elevado de personas.

BIBLIOGRAFA N1 Libro: Fundamentos de Ingeniera del Software Autor: Ian Sommerville Editorial: Pearson Capitulo: 7 Pgina: 132-144

2.2 TCNICAS DE LA INGENIERA DE REQUISITOS

El proceso de Ingeniera 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. Administracin de requerimientos.Que tiene como propsito producir y analizarlos requerimientos de cliente, de producto y de componente de producto, incluye las siguientes actividades: Recoleccin, Anlisis, Especificacin y Verificacin. Recoleccin: Es el Proceso a travs 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 tcnicas y herramientas ms importantes para llevar a cabo la recoleccin de requerimientos son:

ENTREVISTAS

Mtodo 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 estn 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 tcnica consiste en analizar distintos sistemas ya desarrollados que estn relacionados con el sistema a ser construido. Por un lado, podemos analizar las interfaces de usuario, observando el tipo de Informacin que se maneja y cmo es manejada, por otro lado tambin 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 interaccin entre el sistema y el usuario, donde un solo tipo de interaccin entre los dos participantes es simulada y descrita.

OBSERVACIN Y ANLISIS SOCIAL

La observacin 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 solucin a una problemtica. Una lluvia de ideas est compuesta de dos fases: la fase de generacin y la fase de evaluacin. Durante la generacin las ideas son recolectadas y es importante que no sean criticadas. Durante la evaluacin de las ideas, las propuestas de solucin 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 definicin de los requerimientos, o para facilitar la evaluacin de alternativas de implementacin 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 aproximacin del sistema de manera que se pueda proveer cierta funcionalidad del sistema final y usualmente se convierten en parte del mismo.

ANLISIS

Es el proceso de analizar las necesidades de los clientes y los usuariospara llegar a una definicin de los requerimientos de software.

Dentro de las prcticas principales se encuentra:

JAD (Joint Application Development)

Esta prctica se basa en la creacin 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 comn que permite el fcil entendimiento de los temas expuestos por parte de los invitados a la sesin

BIBLIOGRAFA N2

http://tecnologicofch.blogspot.mx/2013/03/22-tecnicas-de-la-ingenieria-de.htmlAutor: francis coronel, Publicado: lunes, 11 de marzo de 2013http://ithjuanah.blogspot.mx/Autor: Juana Hernndez Hernndez

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 cmo se organizan los requerimientos dentro de un documento de requerimientos de software. Conocer las principales actividades de la ingeniera de requerimientos: adquisicin, anlisis y validacin, as como las relaciones entre dichas actividades. Analizar por qu es necesaria la administracin de requerimientos y cmo sta apoya otras actividades de la ingeniera de requerimientos.

Casos de UsoLos casos de uso son una tcnica de descubrimiento de requerimientos que se introdujo por primera vez en el mtodo Objectory (Jacobson et al., 1993). Ahora se ha convertido en una caracterstica fundamental del modelado de lenguaje unificado. En su forma ms sencilla, un caso de uso identifica a los actores implicados en una interaccin, y nombra el tipo de interaccin. Entonces, esto se complementa con informacin adicional que describe la interaccin con el sistema. La informacin adicional puede ser una descripcin textual, o bien, uno o ms modelos grficos como una secuencia UML (Lenguaje de Modelado Unificado) o un grfico 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 describirn 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 interaccin se constituye como una elipse con etiqueta. Lneas vinculan a los actores con la interaccin. De manera opcional, se agregan puntas de flecha a las lneas para mostrar cmo se inicia la interaccin. Esto se ilustra en la figura 4.15, que presenta algunos de los casos de uso para el sistema de informacin 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 descripcin vincularse con otros modelos en el UML que desarrollar el escenario con ms 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 ingeniera de requerimientos explora un rango de conflictos con los participantes del sistema y, como resultado, desarrolla una mejor comprensin de sus necesidades.Por dos razones resulta difcil asimilar el conocimiento de dominio a travs de entrevistas: 1. Todos los especialistas en la aplicacin usan terminologa y jerga que son especficos de un dominio. Es imposible que ellos discutan los requerimientos de dominio sin usar este tipo de lenguaje. Por lo general, usan la terminologa en una forma precisa y sutil, que para los ingenieros de requerimientos es fcil de malinterpretar. 2. Cierto conocimiento del dominio es tan familiar a los participantes que encuentran difcil 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 mayora de las personas se muestran renuentes a discutir los conflictos polticos y organizacionales que afecten los requerimientos. Los entrevistadores efectivos poseen dos caractersticas: 1. Tienen mentalidad abierta, evitan ideas preconcebidas sobre los requerimientos y escuchan a los participantes. Si el participante aparece con requerimientos tienen disposicin para cambiar su mentalidad acerca del sistema. 2. Al entrevistado con una pregunta de trampoln para continuar la pltica, 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 informacin til. Encuentran mucho ms sencillo hablar en un contexto definido que en trminos generales.

Las actividades del proceso Descubrimiento de requerimientos: participantes del sistema para descubrir sus requerimientos. Tambin los requerimientos de dominio de los participantes y la documentacin se descubren durante esta actividad. Clasificacin y organizacin de requerimientos: compilacin no estructurada de requerimientos, agrupa requerimientos relacionados y los organiza en grupos coherentes. La forma ms comn de agrupar requerimientos es Usar un modelo de la arquitectura del sistema: para identificar subsistemas y asociar los requerimientos con cada subsistema. En la prctica, la ingeniera de requerimientos y el diseo arquitectnico no son actividades separadas completamente. Priorizacin y negociacin de requerimientos: en diversos participantes, los requerimientos entrarn en conflicto. Esta actividad se preocupa por priorizar los requerimientos, as como por encontrar y resolver conflictos de requerimientos mediante la negociacin. Por lo general, los participantes tienen que reunirse para resolver las diferencias y estar de acuerdo con el compromiso de los requerimientos. Especificacin de requerimientos: Los requerimientos se documentan e ingresan en la siguiente ronda de la espiral.

Espiral de Procesos de Ingeniera 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 operacin e implementacin. Los requerimientos funcionales son enunciados de los servicios que debe proporcionar el sistema, o descripciones de cmo deben realizarse algunos clculos. 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 ingeniera de requerimientos incluye un estudio de factibilidad, adquisicin y anlisis de requerimientos, especificacin de requerimientos, validacin de requerimientos y administracin de requerimientos. La adquisicin y el anlisis de requerimientos es un proceso iterativo que se representa como una espiral de actividades: descubrimiento de requerimientos, clasificacin y organizacin de requerimientos, negociacin de requerimientos y documentacin de requerimientos. La validacin 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 tcnicos conducen inevitablemente a cambios en los requerimientos para un sistema de software. La administracin de requerimientos es el proceso de gestionar y controlar dichos cambios.BIBLIOGRAFIA 11. INGENIERIA DE SOFTWARE ,Ian Somerville, 9 Edicin, Capitulo 4 Ingeniera de Requerimientos pg.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 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.

Herramientas ms Usadas

Entrevistas y cuestionarios:Las entrevistas y cuestionarios se emplean para reunir informacin proveniente de personas o grupos, informacin que se obtiene conversando con el encuestado. Las preguntas suelen distinguirse en dos categoras: abiertas y cerradas. Las preguntas abiertas permiten que los encuestados respondan con su propia terminologa, mientras que las preguntas cerradas predeterminan todas las posibles respuestas y el interrogado elige entre las opciones presentadas. Grabaciones de video y de audio:Bsicamente existen dos formas de utilizar las grabaciones: como registro y apoyo de las entrevistas, y para analizar algn proceso en particular. En cuanto a su funcin de apoyo, es importante porque permite centrar la atencin en la entrevista en s, en vez de distraerse tomando notas de todo lo que se dice. Cuando se trata de analizar algn 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 intencin en su aplicacin es la de generar la mxima 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 concepcin (anlisis)Esta fase tiene como propsito definir y acordar el alcance del proyecto con los patrocinadores, identificar los riesgos potencialesasociados al proyecto, proponer una visin muy general de la arquitectura de software y producir el plan de las fases y el de iteraciones.Fase de elaboracin (diseo)En la fase de elaboracin se seleccionan los casos de uso que permiten definir la arquitectura base del sistema y se desarrollaran en esta fase, se realiza la especificacin de los casos de uso seleccionados y el primer anlisis del dominio del problema, se disea la solucin preliminar.Fase de construccin (implementacin) El propsito 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 transicin (pruebas)El propsito de esta fase es asegurar que el software est disponible para los usuarios finales, ajustar los errores y defectos encontrados en las pruebas de aceptacin, capacitar a los usuarios y proveer elsoporte tcniconecesario. Se debe verificar que el producto cumpla con las especificaciones entregadas por las personas involucradas en el proyecto.

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

1. 2.http://www.utvm.edu.mx/OrganoInformativo/orgJul07/RUP.htm2. 3. http://w ww.infor.uva.es/~mlaguna/is1/apuntes/2-requisitos.pdf

2.4.Herramientas CASE para la Ingeniera de requisitosA medida que pasa el tiempo se logra entenderque el empleo del software es una buena opcinpara agilizar y sistematizar las tareas en el desarrollo de procesos. El desarrollo de software no es laexcepcin; en este caso dichas herramientas se handenominado CASE (Ingeniera De Software AsistidaPor Computador). Estas incluyen un conjunto deprogramas que facilitan la optimizacin de un producto ofreciendo apoyo permanente a los analistas,ingenieros de software y desarrolladores.CASE es la aplicacin de mtodos y tcnicas quedan utilidades a los programas, por medio de otros,procedimientos y su respectiva documentacin.En este post se hace referencia a 3 herramientas que ayudan a la gestin de requisitos;es decir al proceso de identificacin, asignacin yseguimiento de los mismos, incluyendo interfaz, verificacin, modificacin y control de cada requisito,durante el ciclo de vida del proyecto. Los cambios/actualizaciones de requisitos deben ser gestionadospara asegurar que se mantenga la calidad del producto.

IRQAHerramienta CASE de Ingeniera de Requisitos, diseada para soportar las actividades realizadas en elproceso de especificacin de sistemas. sta facilitay formaliza la comunicacin entre el cliente, el proveedor y los distintos miembros del equipo de desarrollo. Facilita la captura, organizacin y anlisisde las condiciones, as como la especificacin de la solucin mediante el apoyo metodolgico adaptablea cada cliente.

CONTROLAHerramienta de apoyo al proceso de ingeniera desoftware en pequeas empresas. Se cre gracias ala expansin que tuvo el mercado y a la generacinde grandes y pequeas empresas, las cuales requieren un instrumento para el desarrollo de sus proyectos. Ofrece recursos importantes tales como: Administracin de requisitos, administracin de casosde uso, administracin de casos de prueba y error,planeamiento de liberaciones, administracin deimplementaciones, control de dependencia entreImplementaciones, matriz de rastreabilidad y rastreabilidad de los requisitos.

RETOEsta herramienta propone un modelo de requisitos para capturar los aspectos funcionales del sistema, bsicamente, mediante tres tcnicas complementarias entre si: la definicin de la misin del sistema, la construccin del rbol de refinamiento de funciones y el desarrollo de modelo de uso.OSRMTHerramienta libre para la gestin de requisitos,cuyas principales caractersticas son: trabaja en arquitectura cliente/servidor, desarrollada bajo Java;la versin 1.3 trae un mdulo para manejar la trazabilidad y lo introduce para el control de cambios; asmismo, genera la documentacin de los requisitostratados. JEREMIASe trata de una aplicacin 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.RAMBUTANEsta herramienta esta basada en XML, realmente consta de un conjunto de aplicaciones para el usuario final ayudando a los analistas del sistema en la recopilacin y la categorizacin de hechos en un documento de especificacin de requisito.En comparacin con otras herramientas la gestin de requisitos rambutn y las ofrecen la