1 / 65

Universidad Autónoma de Manizales

Universidad Autónoma de Manizales. Especialización en Ingeniería de Software. Ingeniería de Requerimientos. Introducción. Temas. Presentaciones Introducción Definiciones Relación con modelos de calidad. Presentaciones. Cada participante Experiencia con requerimientos Inquietudes

brock-diaz
Download Presentation

Universidad Autónoma de Manizales

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Universidad Autónoma de Manizales Especialización en Ingeniería de Software

  2. Ingeniería de Requerimientos Introducción

  3. Temas • Presentaciones • Introducción • Definiciones • Relación con modelos de calidad

  4. Presentaciones • Cada participante • Experiencia con requerimientos • Inquietudes • Docente • Sandra Victoria Hurtado Gilshurtado@autonoma.edu.co • Ingeniera de Sistemas, Magíster en Ingeniería de Sistemas y Computación – énfasis en construcción de software

  5. Presentaciones • Objetivos procedimentales • Utilizar los casos de uso y los diagramas de actividades para modelar los requerimientos • Clasificar, evaluar y priorizar los requerimientos de un sistema de información • Elaborar una especificación de requerimientos de software, siguiendo un formato estándar • Elaborar un modelo básico para administración de requerimientos en una organización

  6. Temas • Presentaciones • Introducción • Definiciones • Relación con modelos de calidad

  7. Introducción • Algo de historia • Cuando se creó el término “Ingeniería de Software”, en 1969, no se mencionaban los requerimientos • El término Ingeniería de Requerimientos (RE, por sus siglas en inglés) empezó a utilizarse en 1993.

  8. Introducción • Una definición de CALIDAD es: “El grado en que un producto, proceso o sistema cumple con sus requerimientos” (IEEE 610.12) • Si los requerimientos no están bien definidos no se obtendrá un producto de Calidad

  9. Introducción • El porcentaje de defectos que se originan durante la ingeniería de requerimientos se estima en un 50% Karl Wiegers, 2001 • Los analistas reportan que cerca del 71% de los proyectos de software que fracasan, lo hacen por un pobre manejo de los requerimientos CIO Magazine, 2005

  10. Introducción • Éxito en proyectos de software, según el reporte CHAOS (http://www.standishgroup.com/)

  11. Introducción • Factores para el éxito de proyectos • Involucrar al usuario • Apoyo de los directivos • Clara definición de los requerimientos • Factores de reto en los proyectos • Requerimientos y especificaciones incompletas THE STANDISH GROUP REPORT (CHAOS),1995

  12. Introducción • Como muchos requerimientos se escriben en lenguaje natural, los directivos a menudo piensan que cualquier persona puede hacer ingeniería de requerimientos Donald Firesmith, 2003 • Pero en realidad: “ … Obtener un buen conjunto de requerimientos es un proceso muy difícil.” EdMeagher, GovernmentComputer News, 2003

  13. Introducción • Debemos entender qué vamos a desarrollar antes de desarrollarlo • Las estadísticas muestran que esto todavía no se cumple DebJacobs, CrossTalk, 2006

  14. Introducción • Se han hecho grandes avances en Ingeniería de Software: • Estándares, como UML • Metodologías formales y métodos ágiles • Modelos de calidad, como CMMI • Herramientas para automatizar procesos de desarrollo

  15. Introducción • En general • Se está mejorando el desarrollo de software • Pero… • ¿Estamos desarrollando el software correcto?

  16. Introducción • Todavía hay dificultades en los procesos relacionados con requerimientos: • Pobre trabajo al especificar qué se desea. • Los requerimientos a menudo son ambiguos, incompletos o poco claros. • La mayoría de las veces los desarrolladores adivinan o suponen lo que se desea.

  17. Introducción • Una falla en los requerimientos afecta la gestión del proyecto, la arquitectura, el diseño, la implementación, el aseguramiento de calidad, la capacitación,… • ¡Pueden causar muchas fallas en el proyecto!

  18. Introducción • Algunos beneficios de los buenos requerimientos: • Acuerdo entre desarrolladores, clientes y usuarios sobre el trabajo que se debe realizar y los criterios de aceptación del sistema • Tener elementos básicos para mejores estimaciones • Mejoras en atributos de software (los “ilities”). • Alcanzar los objetivos con los recursos justos (pocas omisiones, menos malentendidos y menos cambios)

  19. Introducción • Cada aplicación de software tiene usuarios que confían en ella para mejorar sus vidas. El tiempo que se pasa entendiendo las necesidades de los usuarios es una inversión de alto nivel en el éxito del proyecto. Karl Wiegers, 2001

  20. Introducción ¡Invertir en los procesos de requerimientos vale la pena!

  21. Temas • Presentaciones • Introducción • Definiciones • Relación con modelos de calidad

  22. Glosario • Elicitation • Traduce “Sonsacar”. Se usa esta palabra en lugar de capturar o adquirir requerimientos para resaltar que no se trata simplemente de recolectar información. En este material se traducirá, por lo general, como “adquisición”.

  23. Glosario • Stakeholder • Traduce “poseedor de acciones”. Hace referencia a la persona que tiene algún interés en el sistema, no sólo los usuarios. Incluye los clientes, los afectados por el sistema, los entes reguladores, entre otros. En este material se traducirá como “persona interesada” o “interesado”.

  24. Glosario • Allocation • Traduce “Asignar”. Se utiliza cuando un requerimiento de alto nivel se relaciona con requerimientos más detallados. De esta forma se puede determinar cuáles requerimientos de bajo nivel son necesarios para alcanzar los de más alto nivel.

  25. ¿Qué es un requerimiento de software?

  26. Requerimiento • Glosario de IEEE (1997): • Una condición o capacidad que necesita un usuario para resolver un problema o lograr un objetivo • Una condición o capacidad que debe tener un sistema o un componente para satisfacer un contrato, especificación u otro documento formalmente impuesto. • Una representación documentada de una condición o capacidad, como en 1 o 2.

  27. Requerimiento • Alan Davis: • Una necesidad del usuario, o una característica, función o atributo necesario en un sistema, que puede ser percibido desde un punto externo a dicho sistema • SWEBOK (Software EngineeringBody of Knowledge): • Una propiedad que debe presentar el software, para resolver un problema del mundo real

  28. Requerimiento • Los requerimientos están en la cabeza de las personas • Los diferentes documentos y modelos son representaciones • Se debe llegar a un entendimiento compartido por todos los interesados

  29. Requerimiento • Diferentes niveles de detalle, perspectivas y tipos de requerimientos • De usuario • De sistema • De negocio • Técnicos • Funcionales • No funcionales • …

  30. Niveles de Requerimientos

  31. Requerimientos • Del negocio • Objetivos generales de la organización o los clientes • ¿Por qué se está implementando el sistema? • Del usuario • Objetivos del usuario • Lo que usuario debe poder hacer con la aplicación • Del software • Funciones detalladas • Lo que el desarrollador debe construir

  32. Niveles de Requerimientos Requerimientos de negocio Documento de visión Requerimientos del usuario Doc. Casos de uso Requerimientos no funcionales Otros Requerimientos funcionales Especificación Requerimientos

  33. Requerimientos • Funcionales • Funciones o servicios del sistema • Especifican la funcionalidad que se debe construir – Comportamiento • Describen las interacciones entre el sistema y su ambiente

  34. Requerimientos • No funcionales • Aspectos visibles del sistema, que no se relacionan en forma directa con el comportamiento funcional del sistema • Califican los servicios que debe ofrecer el sistema • Estándares, regulaciones • Interfaces externas, desempeño, precisión, etc.

  35. No es un requerimiento • Detalles de diseño o de implementación (el “cómo”) • Excepto restricciones impuestas • Información sobre pruebas • Información sobre planeación • Presupuesto • Tiempos del proyecto

  36. Requerimiento • No todas las personas interesadas tienen la misma noción de qué es un requerimiento • Se debe tener un glosario básico, y se debe compartir con los interesados

  37. Buenos requerimientos • Completos • Correctos • Necesarios • No ambiguos • Verificables • Se pueden implementar

  38. ¿Qué es ingeniería de requerimientos?

  39. Ingeniería de Requerimientos Eficiente y rigurosamente adquiere, organiza, revisa, evalúa, prioriza y documenta lo que un conjunto de diversas personas interesadas desean – y las ayuda a ponerse de acuerdo en la especificación de una solución. Ian Alexander

  40. Ingeniería de Requerimientos La construcción de requerimientos incluye un análisis de factibilidad del sistema deseado, la adquisición y análisis de las necesidades de las personas interesadas, la creación de una descripción precisa de lo que el sistema debe y no debe hacer, junto con cualquier restricción en su operación e implementación, y la validación de esta descripción o especificación por las personas interesadas. Software EngineeringCurriculumGuidelines

  41. Ingeniería de Requerimientos El área de requerimientos de software se ocupa de la adquisición, análisis, especificación y validación de requerimientos de software.El término “ingeniería de requerimientos” es ampliamente usado para denotar el manejo sistemático de los requerimientos. SWEBOK

  42. Ingeniería de Requerimientos • Elementos claves • Descubrir el objetivo del sistema • Identificar las personas interesadas y sus necesidades • Documentar, de manera que se facilite su análisis y validación • Validar

  43. Adquisición Desarrollo Análisis Especificación Validación Control de Cambios Administración Control de Versiones Seguimiento Áreas Ingeniería de Requerimientos

  44. Actividades de Desarrollo • Obtener requerimientos concisos y claros, que permitan tener una visión precisa del sistema que se desea desarrollar. • Involucra todas las actividades relacionadas con la obtención, evaluación y documentación de los requerimientos.

  45. Adquisición Análisis Especificación Validación Actividades de Desarrollo

  46. Actividades de Desarrollo

  47. Actividades de Desarrollo • Cerca del 15% de la vida del proyecto debe invertirse en actividades de desarrollo de requerimientos, antes de construir cualquier entregable Howard Rubin, 1999

  48. Control de cambios Control de versiones Rastreo Seguimiento Estado Métricas Actividades de Administración Administración de requerimientos

  49. Actividades de Administración • Es un proceso dinámico • Se mantiene, actualiza y rastrea el conjunto de requerimientos del proyecto • Afecta todas las fases del desarrollo de software, incluyendo el mantenimiento

  50. Requerimientos Actividades de Desarrollo Analizar, Documentar,Revisar, Negociar … Línea Base de los Requerimientos Revisiones/Cambios Actividades de Administración Solicitudes de cambios Proceso de cambio Actividades

More Related