Ingeniería de requisitos

5,803 views

Published on

Published in: Devices & Hardware
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
5,803
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
289
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Ingeniería de requisitos

  1. 1. Ingeniería de Requisitos<br />MSc(c): Pablo Ruiz<br />Fundación Universitaria de Popayán<br />Septiembre 2011<br />
  2. 2. Agenda<br />Los requisitos de software<br />Ingeniería de requisitos <br />Técnicas de ingeniería de requisitos<br />
  3. 3.
  4. 4. ¿Qué son los requisitos?<br />Un requisito es una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo [IEEE]<br />Una condición o capacidad que debe ser atendida por el sistema [RUP].<br />Algo que el sistema debe hacer o una cualidad que el sistema debe poseer [Robertson – Robertson].<br />
  5. 5. Problemas<br />Los usuarios no saben lo que quieren.<br />Un sistema tiene muchos usuarios y ninguno tiene una visión de conjunto.<br />No saben cómo hacer más eficiente la operación en su conjunto<br />No saben qué partes de su trabajo pueden transformarse en software.<br />No saben detallar lo que saben de forma precisa.<br />
  6. 6. Solución tradicional: analistas<br />Labores<br />obtener una lista de requisitos de cada usuario<br />adquirir una visión de conjunto<br />componer una especificación completa, correcta y estable<br />Desventajas<br />listas de requisitos son difíciles de comprender y de hacer bien<br />difíciles de transformar en especificaciones de diseño e implementación<br />
  7. 7. Objetivos generales<br />Enumerar los requisitos candidatos<br />Comprender el contexto del sistema<br />Capturar requisitos funcionales<br />Capturar requisitos no funcionales<br />
  8. 8. Requisitos funcionales<br />Definen lo que el sistema tiene que hacer, los servicios que debe proporcionar al usuario<br />Describen la funcionalidad del sistema<br />
  9. 9. Requisitos no funcionales<br />Delimitan las condiciones en que el sistema presta servicios a los usuarios <br />Velocidad de respuesta<br />Ancho de banda requerido<br />Espacio en memoria o en disco<br />....<br />
  10. 10. Características de un Requisito<br />Especificado por escrito: como todo contrato o acuerdo entre dos partes.<br />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?<br />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.<br />
  11. 11. 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<br />Consistente: Un requisito es consistente si no es contradictorio con otro requisito <br />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.<br />Características de un Requisito<br />
  12. 12. Agenda<br />Los requisitos de software<br />Ingeniería de requisitos <br />Técnicas de ingeniería de requisitos<br />
  13. 13. Ingeniería de Requisitos<br />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]<br />
  14. 14. Ingeniería de Requisitos<br />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] <br />Definición de lo que se desea hacer o producir <br />
  15. 15. Importancia de la ingeniería de Requisitos<br />Permite gestionar las necesidades del proyecto en forma estructurada.<br />Mejora la capacidad de predecir cronogramas de los proyectos, así como sus resultados.<br />Disminuye los costos y retrasos del proyecto<br />Mejora la calidad del software<br />Mejora la comunicación entre equipos <br />Evita rechazos de los usuarios finales<br />
  16. 16. Ingeniería de Requisitos<br />El proceso de ingeniería de requisitos puede ser descrito en 4 :<br />
  17. 17. Identificación de Requisitos, I<br />Elicitación de los requisitos<br />El propósito de la elicitación de requisitos es ganar conocimientos relevantes del problema.<br />En esta actividad es donde los analistas de requisitos deben trabajar junto con el cliente para descubrir el problema que el sistema debe resolver.<br /> Debe existir una buena comunicación entre desarrolladores y clientes; de esta comunicación con el cliente depende que entendamos sus necesidades<br />Se debe descubrir los diferentes servicios que el sistema debe prestar y las restricciones .<br />
  18. 18. Análisis<br />Se trabaja sobre la base de la anterior actividad.<br />Actividad la cual se enfoca a descubrir problemas con los requisitos del sistema identificados hasta el momento.<br />Por lo general se hace un análisis luego de haber producido un bosquejo inicial del documento de requisitos.<br />Se conceptúan los requisitos, se investigan, se intercambian ideas con el resto del equipo, se resaltan los problemas, se buscan alternativas y soluciones<br />
  19. 19. Especificación <br />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.<br />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.<br />
  20. 20. Validación <br />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.<br />Se verifica que los requisitos sean consistentes y que estén completos<br />
  21. 21. Agenda<br />Los requisitos de software<br />Ingeniería de requisitos <br />Técnicas de ingeniería de requisitos<br />
  22. 22. Técnicas de ingeniería de Requisitos<br />El análisis de requisitos siempre comienza con una comunicación entre dos o más partes. <br />Un cliente tiene un problema al que puede encontrar una solución basada en computadora. <br />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.<br />
  23. 23. Antes de mantener las reuniones con los clientes y usuarios e identificar los requisitos es fundamental conocer el dominio del problema. <br />Mantener reuniones con clientes y usuarios sin conocer las características de su actividad hará que probablemente no se entiendan sus necesidades.<br />Para conocer el dominio del problema se puede obtener información de fuentes externas al negocio del cliente<br />Técnicas de ingeniería de Requisitos<br />
  24. 24. Normalmente clientes y analistas se enfrascan en el proyecto de forma unilateral y no en equipo. Cada parte define su propio “territorio” <br />Este enfoque no es muy efectivo, abundan los malentendidos, se pierde información importante y nunca se establece una relación de trabajo satisfactoria.<br />Técnicas de ingeniería de Requisitos<br />
  25. 25. Con los anteriores problemas, se han desarrollado numerosas técnicas para tratar de superarlos <br />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.<br />Técnicas de ingeniería de Requisitos<br />
  26. 26. Entrevistas<br />Las entrevistas son la técnica de elicitación más utilizada, y de hecho son prácticamente inevitables en cualquier desarrollo. <br />En las entrevistas se pueden identificar claramente tres fases [Piattini]: preparación, realización y análisis<br />
  27. 27. Preparación de entrevistas: Las entrevistas no deben improvisarse, por lo que conviene realizar las siguiente tareas previas:<br />Estudiar el dominio del problema<br />Seleccionar a las personas a las que se va a entrevistar(top–down)<br />Determinar el objetivo y contenido de las entrevistas<br />Planificar las entrevistas<br />Entrevistas<br />
  28. 28. Realización de entrevistas: se distinguen tres etapas [Piattini]:<br />Apertura<br />Desarrollo<br />Terminación<br />Análisis de las entrevistas <br /> Reorganizar la información, contrastarla con otras entrevistas o fuentes de información. <br />Validar con el entrevistado para confirmar los contenidos. <br />Entrevistas<br />
  29. 29. Brainstorming<br />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].<br />Las sesiones de brainstormingformadas de cuatro a diez participantes, uno de los cuales es el jefe de la sesión.<br />
  30. 30. Fases del brainstorming<br />Preparación<br />Selección de participantes <br />Preparación logística<br />Generación <br />Jefe de proyecto expone un enunciado general del problema , que hace de semilla para que se generen ideas.<br />Los participantes generan nuevas ideas de forma aleatoria<br />Reglas<br />Se prohíbe la critica de ideas<br />Se fomentan las ideas más avanzadas y se estimula a los participantes a generar nuevas ideas<br />Se debe generar un gran número de ideas,<br />Se debe alentar a los participantes a combinar o completar las ideas de otros participantes<br />
  31. 31. Consolidación: en esta fase se deben organizar y evaluar las ideas generadas durante la fase anterior. Se suelen seguir tres pasos:<br />Revisar ideas: se revisan para clarificarlas<br />Descartar ideas.<br />Priorizar ideas.<br />Documentación: el jefe produce la documentación oportuna conteniendo las ideas priorizadas y comentarios generados durante la consolidación. <br />Fases del brainstorming<br />
  32. 32. Casos de Uso<br />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].<br /><ul><li>Una descripción de una secuencia de acciones que el sistema debe llevar a cabo para obtener un resultado observable para un actor particular [Booch]</li></ul>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.<br />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<br />
  33. 33. Los Casos de Uso facilitan la elicitación de requisitos y son fácilmente comprensibles por los clientes y usuarios. <br />Sirven de base a las pruebas del sistema y a la documentación para los usuarios.<br />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<br />Se escriben, generalmente, en lenguaje natural<br />No hay descripción interna del sistema, solo la interacción con el mismo<br />Casos de Uso<br />
  34. 34. Casos de Uso<br />Ventajas y desventajas<br />Caracterización detallada de todas las posibles interacciones con el sistema<br />Ayuda en el dibujo de los límites del sistema, y con el alcance de los requerimientos<br />Los casos de uso no captura en dominio del conocimiento<br />Un caso de uso no es especificación precisa, solo es la representación de un problema puntual<br />
  35. 35. Usando casos de Uso<br /><ul><li>Dibujar los límites
  36. 36. Identificar los actores fuera de los límites del sistema que interactúan con él
  37. 37. Para cada actor
  38. 38. Identificar los posibles casos de uso
  39. 39. Establecer escenarios concretos para ilustrar cada caso de uso
  40. 40. Agrupar escenarios similares en casos de uso si son una variación sobre un tema</li></li></ul><li>Usando casos de Uso<br /><ul><li>Para cada caso de uso
  41. 41. Escribirlo
  42. 42. Especificar reglas para elección del mismo y para interactuar con él
  43. 43. Considerar alternativas
  44. 44. Ver posibles superposiciones de casos de uso</li></ul>Template de caso de uso:<br />Nombre:Resumen:Actores:Precondiciones:Descripciones:Excepciones:Postcondiciones:<br />
  45. 45. Un ejemplo de caso de uso<br /><ul><li>Nombre: Orden de pedido
  46. 46. Precondición: un usuario válido está conectado al sistema
  47. 47. Descripción:</li></ul>El caso de uso comienza con un pedido del cliente<br />El cliente entra su nombre y dirección<br />Si el cliente entra solo el código postal, el sistema debe agregar la ciudad y la provincia.<br />El cliente entrará todos los código de los productos deseados y la cantidad solicitada<br />El sistema indicará el nombre del producto y el precio unitario del mismo<br />El sistema totalizará la cantidad de productos pedidos y el total de la venta<br />El cliente indicará la forma de pago, si es tarjeta el número de la misma<br />El cliente apretará la tecla enviar<br />El sistema verificará la información, guardará la orden de pedido como pendiente y la forma de pago<br />Una vez confirmado el pago, la orden se cambiará a confirmada y se le indica esto al cliente, el caso de uso finaliza<br /><ul><li>Excepciones:
  48. 48. En el paso 9, si hay información incorrecta, el sistema le preguntará al cliente que quiso poner
  49. 49. Postcondiciones:
  50. 50. La orden fue salvada en el sistema y fue marcada como confirmada</li></li></ul><li>Un ejemplo de caso de uso<br />
  51. 51. Los Casos de Uso y UML<br />La notación de los casos de uso fue incorporada al lenguaje estándar de modelado UML y fue avalada por las principales empresas que desarrollan software en el mundo. <br />La mejor forma de empezar a entender un sistema es a partir de los servicios o funciones que ofrece a su entorno<br />

×