Ingeniería de requisitos

Ingeniería de Requisitos,[object Object],MSc(c): Pablo Ruiz,[object Object],Fundación Universitaria de Popayán,[object Object],Septiembre 2011,[object Object]

Agenda,[object Object],Los requisitos de software,[object Object],Ingeniería de requisitos ,[object Object],Técnicas de ingeniería de requisitos,[object Object]

¿Qué son los requisitos?,[object Object],Un requisito es una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo [IEEE],[object Object],Una condición o capacidad que debe ser atendida por el sistema [RUP].,[object Object],Algo que el sistema debe hacer o una cualidad que el sistema debe poseer [Robertson – Robertson].,[object Object]

Problemas,[object Object],Los usuarios no saben lo que quieren.,[object Object],Un sistema tiene muchos usuarios y ninguno tiene una visión de conjunto.,[object Object],No saben cómo hacer más eficiente la operación en su conjunto,[object Object],No saben qué partes de su trabajo pueden transformarse en software.,[object Object],No saben detallar lo que saben de forma precisa.,[object Object]

Solución tradicional: analistas,[object Object],Labores,[object Object],obtener una lista de requisitos de cada usuario,[object Object],adquirir una visión de conjunto,[object Object],componer una especificación completa, correcta y estable,[object Object],Desventajas,[object Object],listas de requisitos son difíciles de comprender y de hacer bien,[object Object],difíciles de transformar en especificaciones de diseño e implementación,[object Object]

Objetivos generales,[object Object],Enumerar los requisitos candidatos,[object Object],Comprender el contexto del sistema,[object Object],Capturar requisitos funcionales,[object Object],Capturar requisitos no funcionales,[object Object]

Requisitos funcionales,[object Object],Definen lo que el sistema tiene que hacer, los servicios que debe proporcionar al usuario,[object Object],Describen la funcionalidad del sistema,[object Object]

Requisitos no funcionales,[object Object],Delimitan las condiciones en que el sistema presta servicios a los usuarios ,[object Object],Velocidad de respuesta,[object Object],Ancho de banda requerido,[object Object],Espacio en memoria o en disco,[object Object],....,[object Object]

Características de un Requisito,[object Object],Especificado por escrito: como todo contrato o acuerdo entre dos partes.,[object Object],Posible de probar y verificar. Si un requerimiento no se pude comprobar . Entontes ¿ Cómo se sabe que si se cumplió con él o no?,[object Object],Conciso: un requisito es conciso si es fácil de leer y entender. Su redacción debe ser simple para las personas que lo vayan a consultar en el futuro.,[object Object]

Completo: Un requisito es completo si no necesita ampliar detalles en su redacción, es decir se proporciona la información suficiente para su comprensión,[object Object],Consistente: Un requisito es consistente si no es contradictorio con otro requisito ,[object Object],No ambiguo: Un requisito no es ambiguo cuando tienen una sola interpretación . El lenguaje usado en su definición no debe causar confusión al lector.,[object Object],Características de un Requisito,[object Object]

Ingeniería de Requisitos,[object Object],Ingeniería de Requisitos 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 clientequiere y cómo interactuarán los usuarios finales con el software. [Pressman],[object Object]

Ingeniería de Requisitos,[object Object],Es el proceso mediante el cual se intercambian diferentes puntos de vistapara recopilar y modelar lo que el sistema va a realizar. Este proceso utiliza una combinación de métodos, herramientas y actores, cuyo producto es un modelo del cual se genera un documento de requerimientos. [Leite89] ,[object Object],Definición de lo que se desea hacer o producir ,[object Object]

Importancia de la ingeniería de Requisitos,[object Object],Permite gestionar las necesidades del proyecto en forma estructurada.,[object Object],Mejora la capacidad de predecir cronogramas de los proyectos, así como sus resultados.,[object Object],Disminuye los costos y retrasos del proyecto,[object Object],Mejora la calidad del software,[object Object],Mejora la comunicación entre equipos ,[object Object],Evita rechazos de los usuarios finales,[object Object]

Ingeniería de Requisitos,[object Object],El proceso de ingeniería de requisitos puede ser descrito en 4 :,[object Object]

Identificación de Requisitos, I,[object Object],Elicitación de los requisitos,[object Object],El propósito de la elicitación de requisitos es ganar conocimientos relevantes del problema.,[object Object],En esta actividad es donde los analistas de requisitos deben trabajar junto con el cliente para descubrir el problema que el sistema debe resolver.,[object Object], Debe existir una buena comunicación entre desarrolladores y clientes; de esta comunicación con el cliente depende que entendamos sus necesidades,[object Object],Se debe descubrir los diferentes servicios que el sistema debe prestar y las restricciones .,[object Object]

Análisis,[object Object],Se trabaja sobre la base de la anterior actividad.,[object Object],Actividad la cual se enfoca a descubrir problemas con los requisitos del sistema identificados hasta el momento.,[object Object],Por lo general se hace un análisis luego de haber producido un bosquejo inicial del documento de requisitos.,[object Object],Se conceptúan los requisitos, se investigan, se intercambian ideas con el resto del equipo, se resaltan los problemas, se buscan alternativas y soluciones,[object Object]

Especificación ,[object Object],Se documentan los requisitos acordados con el cliente en un nivel apropiado de detalle. En la práctica esta actividad se va realizando conjuntamente con el análisis.,[object Object],Se pude decir que la especificación es el “pasar en limpio ” el análisis realizado previamente aplicando técnicas o estándares de documentación como UML.,[object Object]

Validación ,[object Object],La validación es la actividad que certifica que el modelo de los requisitos es consistente con las intenciones de los clientes y los usuarios.,[object Object],Se verifica que los requisitos sean consistentes y que estén completos,[object Object]

Técnicas de ingeniería de Requisitos,[object Object],El análisis de requisitos siempre comienza con una comunicación entre dos o más partes. ,[object Object],Un cliente tiene un problema al que puede encontrar una solución basada en computadora. ,[object Object],El desarrollador responde a la petición del cliente. La comunicación ha comenzado. Pero,el camino entre la comunicación y el entendimiento está lleno de baches.,[object Object]

Antes de mantener las reuniones con los clientes y usuarios e identificar los requisitos es fundamental conocer el dominio del problema. ,[object Object],Mantener reuniones con clientes y usuarios sin conocer las características de su actividad hará que probablemente no se entiendan sus necesidades.,[object Object],Para conocer el dominio del problema se puede obtener información de fuentes externas al negocio del cliente,[object Object],Técnicas de ingeniería de Requisitos,[object Object]

Normalmente clientes y analistas se enfrascan en el proyecto de forma unilateral y no en equipo. Cada parte define su propio “territorio” ,[object Object],Este enfoque no es muy efectivo, abundan los malentendidos, se pierde información importante y nunca se establece una relación de trabajo satisfactoria.,[object Object],Técnicas de ingeniería de Requisitos,[object Object]

Con los anteriores problemas, se han desarrollado numerosas técnicas para tratar de superarlos ,[object Object],Cada técnica puede aplicarse en una o más actividades de la ingeniería de requerimientos; en la práctica, la técnica más apropiada para cada actividad dependerá del proyecto que esté desarrollándose.,[object Object],Técnicas de ingeniería de Requisitos,[object Object]

Entrevistas,[object Object],Las entrevistas son la técnica de elicitación más utilizada, y de hecho son prácticamente inevitables en cualquier desarrollo. ,[object Object],En las entrevistas se pueden identificar claramente tres fases [Piattini]: preparación, realización y análisis,[object Object]

Preparación de entrevistas: Las entrevistas no deben improvisarse, por lo que conviene realizar las siguiente tareas previas:,[object Object],Estudiar el dominio del problema,[object Object],Seleccionar a las personas a las que se va a entrevistar(top–down),[object Object],Determinar el objetivo y contenido de las entrevistas,[object Object],Planificar las entrevistas,[object Object],Entrevistas,[object Object]

Realización de entrevistas: se distinguen tres etapas [Piattini]:,[object Object],Apertura,[object Object],Desarrollo,[object Object],Terminación,[object Object],Análisis de las entrevistas ,[object Object], Reorganizar la información, contrastarla con otras entrevistas o fuentes de información. ,[object Object],Validar con el entrevistado para confirmar los contenidos. ,[object Object],Entrevistas,[object Object]

Brainstorming,[object Object],El brainstorming o tormenta de ideas es una técnica de reuniones en grupo cuyo objetivo es la generación de ideas en un ambiente libre de críticas o juicios [Raghavan].,[object Object],Las sesiones de brainstormingformadas de cuatro a diez participantes, uno de los cuales es el jefe de la sesión.,[object Object]

Fases del brainstorming,[object Object],Preparación,[object Object],Selección de participantes ,[object Object],Preparación logística,[object Object],Generación ,[object Object],Jefe de proyecto expone un enunciado general del problema , que hace de semilla para que se generen ideas.,[object Object],Los participantes generan nuevas ideas de forma aleatoria,[object Object],Reglas,[object Object],Se prohíbe la critica de ideas,[object Object],Se fomentan las ideas más avanzadas y se estimula a los participantes a generar nuevas ideas,[object Object],Se debe generar un gran número de ideas,,[object Object],Se debe alentar a los participantes a combinar o completar las ideas de otros participantes,[object Object]

Consolidación: en esta fase se deben organizar y evaluar las ideas generadas durante la fase anterior. Se suelen seguir tres pasos:,[object Object],Revisar ideas: se revisan para clarificarlas,[object Object],Descartar ideas.,[object Object],Priorizar ideas.,[object Object],Documentación: el jefe produce la documentación oportuna conteniendo las ideas priorizadas y comentarios generados durante la consolidación. ,[object Object],Fases del brainstorming,[object Object]

Casos de Uso,[object Object],Los casos de uso son una técnica para la especificación de requerimientos funcionales propuesta inicialmente en por Jacobson y actualmente forma parte de la propuesta de UML [Booch99].,[object Object],[object Object],Un caso de uso es la descripción de una secuencia de interacciones entre el sistema y uno o más actores en la que se considera al sistema como una caja negra.,[object Object],Los actores son personas u otros sistemas que interactúan con el sistema cuyos requerimientos se están describiendo. Un actor puede participar en varios casos de uso y un caso de uso puede estar relacionado con varios actores,[object Object]

Los Casos de Uso facilitan la elicitación de requisitos y son fácilmente comprensibles por los clientes y usuarios. ,[object Object],Sirven de base a las pruebas del sistema y a la documentación para los usuarios.,[object Object],Los más reconocidos especialistas en métodos Orientados a Objetos coincidieron en considerar a los casos de uso como una excelente forma de especificar el comportamiento externo de un sistema,[object Object],Se escriben, generalmente, en lenguaje natural,[object Object],No hay descripción interna del sistema, solo la interacción con el mismo,[object Object],Casos de Uso,[object Object]

Casos de Uso,[object Object],Ventajas y desventajas,[object Object],Caracterización detallada de todas las posibles interacciones con el sistema,[object Object],Ayuda en el dibujo de los límites del sistema, y con el alcance de los requerimientos,[object Object],Los casos de uso no captura en dominio del conocimiento,[object Object],Un caso de uso no es especificación precisa, solo es la representación de un problema puntual,[object Object]

Usando casos de Uso,[object Object],[object Object]

Identificar los actores fuera de los límites del sistema que interactúan con él

Identificar los posibles casos de uso

Establecer escenarios concretos para ilustrar cada caso de uso

Ingeniería de requisitos

Ingeniería de requisitos

Recomendados

Más contenido relacionado

Was ist angesagt?

Was ist angesagt?(20)

Similar a Ingeniería de requisitos

Similar a Ingeniería de requisitos(20)

Último

Último(13)

Ingeniería de requisitos