Instituto Tecnológico De Tuxtepec             Materia: Fundamentos de la Ingeniería del             Software.Catedrático: ...
Introducción:La ingeniería de requisitos es una herramienta fundamental para los Ingenieros enSistema Computacionales, ya ...
El objetivo del proceso de la ingeniería de requisitos es darle a todas las partesuna explicación escrita del problema. Es...
identifica una necesidad de negocios o se descubre un nuevo mercado o serviciopotencial. Cabe aclarar que toda esta inform...
iniciales los participantes escriben una solicitud de producto de una o 2 paginasen la cual se fija un lugar, una hora y u...
Requisitos esperados: están implícitos en el producto o sistema y pueden parecertan obvios, aunque son fundamentales, que ...
Y dentro de esta misma fase se encuentra el modelo de análisis en el cual suobjetivo es describir los dominios requeridos ...
Elementos orientados al flujo: cuando la información fluye a través de un sistemabasado en computadora, esta se transforma...
Validación:Al crear cada elemento del modelo de análisis, este se examina para conocer suconsistencia, omisiones y ambigüe...
Conclusión.Como ya se vio anteriormente para la creación o desarrollo de algún sistemaantes que nada es necesario entender...
Referencias.(Pressman, 2008).
Próxima SlideShare
Cargando en…5
×

TAREAS DE LA ING. DE REQUISITOS

2.373 visualizaciones

Publicado el

1 comentario
0 recomendaciones
Estadísticas
Notas
  • Sé el primero en recomendar esto

Sin descargas
Visualizaciones
Visualizaciones totales
2.373
En SlideShare
0
De insertados
0
Número de insertados
573
Acciones
Compartido
0
Descargas
0
Comentarios
1
Recomendaciones
0
Insertados 0
No insertados

No hay notas en la diapositiva.

TAREAS DE LA ING. DE REQUISITOS

  1. 1. Instituto Tecnológico De Tuxtepec Materia: Fundamentos de la Ingeniería del Software.Catedrático: María De Los Ángeles Morales MartínezTrabajo: Investigación de las tareas de la ingeniería de requisitosAlumnos: Cynthia Del Carmen Barrera Villa Raziel Iván Peña Calderón Aradi Pineda Barranca Axel Huerta Morales Ivonne Ángeles Ideaquiz Ismael De Jesús Contreras RebolledoGrado & Grupo: I.S.C. 5° ‘A’Fecha de Entrega:Miércoles 18/septiembre/2012
  2. 2. Introducción:La ingeniería de requisitos es una herramienta fundamental para los Ingenieros enSistema Computacionales, ya que mediante ella podemos analizar mejor elproblema que tenemos y de esta manera es más sencillo hallar una soluciónóptima en la cual se trabajara.La importancia que tiene la Ingeniería de Requisitos es alta dado a que sin ella nose debe de comenzar a trabajar en el proyecto debido a que uno no sabe conexactitud que es lo que e cliente en realidad requiere.Las fases de la ingeniería de requisitos comienza por la fase del inicio en la cualse define el ámbito y la naturaleza del problema a resolver, posteriormente laobtención la cual es una tarea que ayuda al cliente a definir sus necesidades,sigue la elaboración en la cual se refinan y modifican los requisitos básicos, y unavez que ha definido ya el problema viene a cabo lo que es la negociación dondese definen cuales son las prioridades cuales aspectos son esenciales y elmomento en el cual se requieren, y por ultimo el problema se especifica de algunamanera y después es validado y revisado para asegurar la concepción delproblema que tiene el ingeniero de software coincide con la percepción del cliente.
  3. 3. El objetivo del proceso de la ingeniería de requisitos es darle a todas las partesuna explicación escrita del problema. Esto se puede lograr por medio de variosproductos de trabajo como lo son escenarios de uso, listas de funciones ycaracterísticas, modelos de análisis o alguna especificación.La ingeniería de requisitos debe adaptarse a las necesidades del proceso, elproyecto, el producto y a las personas que realizan el trabajo. La ingeniería derequisitos esuna acción de la ingeniería de software la cual se comienza durante laactividad de la comunicación y dicha continua en la actividad de modelado. Enalgunos casos se elige un enfoque abreviado, aunque en otros casos cada unade las tareas es definida para poder comprender los requisitos los cuales sellevan de manera muy rigurosa, en el cual el equipo de software debe adaptarseal enfoque de la ingeniería de requisitos, en el cual dicho equipo debe entenderlos requisitos del problema antes de intentar resolverlo.La ingeniería de requisitos proporciona el mecanismo apropiado para entender loque el cliente quiere y así analizar las necesidades, evaluar la factibilidad,negociar una solución razonable, especificar la solución sin ambigüedades,validar las especificaciones y administrar los requisitos conforme a estos setransforme en el sistema operacional. El proceso de la ingeniería de requisitos selleva a cabo a través de 7 distintas funciones las cuales son: Inicio, obtención,elaboración, negociación, especificación validación y gestión. Las cuales estándirigidas a definir lo que el cliente quiere y todas sirven para establecer una basesolida con respecto al diseño y la construcción de lo obtendrá el cliente.Comencemos por plantear cada una de las fases de ingeniería de requisitos.Inicio:Al inicio del proyecto los ingenieros de software hacen una seriede preguntaslibres de contexto en las cuales, su objetivo es establecer una comprensión básicadel problema, la comunicación preliminar entre el cliente y el desarrolladorpermite que los clientes expongan su problema y con ello dar paso a unasolucióndeseada. Por lo general la mayoría de los proyectos comienzan cuando se
  4. 4. identifica una necesidad de negocios o se descubre un nuevo mercado o serviciopotencial. Cabe aclarar que toda esta información esta sujeta a cambios, sinembargo estas conversaciones se van adecuando a la ingeniería del software.En el inicio el desarrollador de software debe identificar a los interesados loscuales son, aquellas perdonas que van a interactuar de forma directa con elsistema que se desarrollara o aquellas personas que obtienen beneficios de este.Posteriormente preguntar a los interesados sus puntos de vista y después entretodos elegir un conjunto de requisitos para el sistema y de esta manera el sistemasea consistente. Ya que se tiene esto se procede a identificar las áreas en común(requisitos en los que todos los interesados están de acuerdo) y las áreas deconflicto, lo cual es un gran desafío.Ya que se tiene esto se pasa a la formulación de preguntas en la cuales lainformación proporcionada será de gran importancia ya que depende de ellasconocer la metas generales así como los beneficios.Las preguntas nos ayudaran a romper el hielo y nos permitirán iniciar laconversación inicial para la obtención exitosa, pero estas preguntas solo debenser utilizadas en el principio, en caso denecesitar mas información en lassiguientes fases de la construcción del software se deben de remplazar por unformato de obtenciónde requisitos.Obtención:La obtención de requisitos es mas detallada, como ya se menciono anteriormentela sesión de preguntas y repuestas solo debe de ser utilizada para el primerencuentro, y después debe de remplazarse por un formato de obtención derequisitos que combine elementos como lo son la resolución, elaboraciónnegociación y especificación del problema.Durante la fase del inicio la preguntas y repuestas básicas establecen un ámbitodel problema y la percepción global de la solución, fuera de estas reuniones
  5. 5. iniciales los participantes escriben una solicitud de producto de una o 2 paginasen la cual se fija un lugar, una hora y una fecha para una reunión y se seleccionaun moderador, en la cual los miembros del equipo de software y otrasorganizaciones interesadas son invitadas a asistir. La solicitud de producto sedistribuye a todos los asistentes antes de la fecha de reunión para así tengantiempo de revisarla y así hacer una lista de los objetos que son parte del ambienteque rodea al sistema, otros objetos que este producirá y objetos que utiliza parasus funciones, así como también una lista de servicios que manipulas ointeractúan con los objetos y por ultimo la lista con restricciones y criterios derendimiento. Y se le informa a los asistentes que la lista debe de reflejar lapercepción de cada persona sobre el sistema. Cuando se inicia la reunión elprimer tópico que se trata de la necesidad y la justificación para el nuevo producto,en el cual todos los participantes debende estar de acuerdo en que la necesidaddel producto se justifica, una vez establecido el acuerdo cada participantepresenta sus listas para examinarlas. Después de que las listas se hallanpresentado el grupo crea una lista combinada para todas las áreas en los distintostópicos, tal lista se reduce o se incrementa dependiendo de como se apropia elproducto/sistema que se desarrollara.Teniendo todo esto se puede proseguir con el despliegue de la función de lacalidad(QFD por sus siglas en ingles), la cual es una técnica que traduce lasnecesidades del cliente en requisitos técnicos para el software, y este seconcentra en aumentar la satisfacción del cliente desde el proceso de laingeniería del software, para lograr esto, el QFD resalta una comprensión de loque es valioso para el cliente y después despliega estos valores durante elproceso de ingeniería en el cual el QFD identifica 3 tipos de requisitos.Requisitos normales: Reflejan los objetivos y metas establecidos para un productoo sistema durante las reuniones con e cliente. Si dichos requisitos estánpresentes, el cliente estará satisfecho.
  6. 6. Requisitos esperados: están implícitos en el producto o sistema y pueden parecertan obvios, aunque son fundamentales, que el cliente no los establece de maneraexplicita. Su ausencia causaría una insatisfacción significativa.Requisitos estimulantes: reflejan las características que van masallá de lasexpectativas del cliente y que prueban ser muy satisfactorias cuando estánpresentes.En la actualidad el QFD barca la totalidad del proceso de la ingeniería. Sinembargo muchos conceptos del QFD son aplicables a la actividad de obtenciónde requisitos.A los ingenieros les resulta difícil entender como aplicaran las funciones ycaracterísticas los usuarios finales por lo cual los desarrolladores y usuariosfinales crean un conjunto de escenarios que identifican una cadena para el usodel sistema a construir. Los escenarios llamados con frecuencia casos de usoproporcionan una descripción de como se usara el sistema.Los productos de trabajo producidos como consecuencia de la obtención derequisitosvaria de acuerdo con el tamaño del sistema o producto que se valla aconstruir. Y cada una de los trabajos los revisa toda la gente que ha participado enla obtención de requisitos.Elaboración:Dentro de esta fase se encuentra el desarrollo de casos que es en esencia unahistoria estilizada de la manera en que un usuario final interactúa con el sistemaen un conjunto especifico de circunstancias. Para poder llevarloa cabo primeroque nada se debe definir el conjunto de actores que estarán involucrados en lahistoria. Cabe destacar que un actor y un usuario final no son necesariamente lomismo. Después de la revisión cuidadosa de los requisitos el software de controlrequiere de 4 diferentes modos para su interacción de los cuales son, modo deprogramación, modo de prueba, modo monitoreo y modo de resolución deproblemas.
  7. 7. Y dentro de esta misma fase se encuentra el modelo de análisis en el cual suobjetivo es describir los dominios requeridos de información, funcionamiento ycomportamiento para un sistema basado en computadoras. Conforme el modelode análisis evoluciona ciertos elementos se volverán relativamente estables porlo cual proporcionaran una base solida para las tareas de diseño.Los elementos del modelo de análisisExiste una gran diversidad de maneras de buscar los requisitos para un sistemabasado en una computadora. Los elementos específicos del modelo de analisislos determina el método de modelado, sin embargo existe un conjunto deelementos genéricos común a la mayoría de los modelos de análisis que son lossiguientes:Elementos basados en escenarios: en este el sistema se describe, desde el puntode vista del usuario, por medio de un enfoque basado en escenarios, loselementos del modelo de análisis basados en escenario con frecuencia son losprimeros que se desarrollan en la elaboración del modelo. Y en este se muestranlas actividades o funciones que han sido definidas como parte de la tarea deobtención de requisitos. Los modelos en esta categoría pueden definirse demanera iterativa.Elementos basados en clases: en cada escenario se utiliza un conjunto de objetoslos cuales se clasifican en clases, una colección de atributos similares ycomportamientos en común.Elementos de comportamiento: el comportamiento de un sistema basado enunacomputadora puede tener un profundo efecto sobre el diseño que se elija, asícomo el enfoque de implementación que se aplique. Por lo tanto el modelo deanálisis debe proporcionar elementos de modelado que muestren elcomportamiento. El diagrama de estado es un método para representar elcomportamiento de un sistema al mostrar sus estados y los eventos queocasionan que dicho sistema cambie de estado. Un estado es cualquier forma decomportamiento observable.
  8. 8. Elementos orientados al flujo: cuando la información fluye a través de un sistemabasado en computadora, esta se transforma. El sistema acepta la entrada envariedad de formas, aplica funciones para transformarla y produce una salidatambién en formas diferentes.Patrones de análisis son aquellascosas que suceden de manera recurrente entodos los proyectos dentro de un dominio de aplicación que puede reutilizarse almodelar muchas aplicaciones. Los patrones de análisis se integran al modelorespectivo mediante una referencia al nombre del patrón, estos también seencuentran almacenados en un depósito para que los ingenieros de requisitospuedan utilizar los servicios de búsqueda y así encontrarlos y reutilizarlos.Negociación:En un contexto ideal de la ingeniería de requisitos, las tareas de inicio, obtencióny elaboración determinan requisitos con el suficiente detalle como paraemprender los pasos subsecuentes de la ingeniería del software.Desafortunadamente esto sucede muy rara vez, pues el cliente y el desarrolladorentran en un proceso de negociación, en el cual se le debe pedir al cliente unbalance de la funcionalidad el rendimiento y otras características del sistema oproducto frente al costo y el tiempo de colocación en el mercado. El objetivo deesta negociación, es desarrollar un plan de proyecto que satisfaga lasnecesidades del cliente al mismo tiempo que refleja las restricciones del mundoreal, alas cuales esta sometido el equipo de software.Las mejores negociaciones son aquella que buscan un resultado del tipo ganar-ganar. Esto es, el cliente gana al obtener el sistema o producto que satisface lamayoría de sus necesidades, y el equipo de software gana al trabajar conpresupuestos y limites de tiempos realistas y alcanzables.
  9. 9. Validación:Al crear cada elemento del modelo de análisis, este se examina para conocer suconsistencia, omisiones y ambigüedades. A los requisitos que representa elmodelo el cliente les da la jerarquía y se agrupan en paquetes de requisitos que seimplementan como incrementos de software y se le entregan. Una revisión delmodelo de análisis se enfoca en las siguientes preguntas: ¿cada requisito es consistente con el objetivo general del sistema/producto? ¿todos los requisitos han sido especificados con el grado apropiado de abstracción? ¿el requisito es necesario en realidad o representa una característica agregada irrelevante para el objetivo del sistema? ¿cada requisito esta limitado y no es ambiguo? ¿cada requisito tiene una atribución? ¿algunos requisitos entran en conflicto con otros? Cada requisito es alcanzable en el ambiente técnico que recibirá al sistema o producto? ¿cada requisito se puede probar una vez que este haya sido implementado? ¿el modelo de requisitos refleja de manera apropiada la información, la función y el comportamiento del sistema que será construido? ¿el modelo de requisitos se ha sometido a partición para que se exponga en forma progresiva información mas detallada acerca del sistema? ¿se han usado patrones de requisitos par simplificar el modelo de requisitos?,¿todos los patrones se han validado de manera apropiada?, ¿todos los patrones son consistentes en los requisitos del cliente?Estas y otras preguntas deben realizarse y contestarse para asegurar que elmodelo de requisitos es el reflejo exacto de las necesidades del clientey queproporciona una base solida para el diseño.
  10. 10. Conclusión.Como ya se vio anteriormente para la creación o desarrollo de algún sistemaantes que nada es necesario entender los requisitos del cliente. Esto se lograrealizando la serie de tareas de la ingeniería de requisitos mencionadasanteriormente, las cuales se llevan a cabo durante las actividades decomunicación con el cliente y modelado que han sido definidas para el procesogenérico del software. Los miembros del equipo de software realizan 7 funcionesdistintas dentro de la ingeniería de requisitos: las cuales son: inicio, obtención,elaboración negociación, especificación validación y gestión. Como ya se vio lastareas de la ingeniería de requisitos son de tal importancia debido a que gracias aella obtenemos información gran importancia para desarrollar el software, debidoa que sin la ayuda de estas tareas los ingenieros de software no sabrían amanera concreta que es lo que desea el cliente y como lo quiere estructurado, laingeniería de requisitos no es nada fácil debido a que se debe de realiza un sinfínde movimientos antes de comenzar a desarrollar el software, lo cual tambiénnecesitad e prueban ante los usuarios finales y ver cuales son las fallas que tieneo características con mayor importancia.
  11. 11. Referencias.(Pressman, 2008).

×