Ingeniería de Requerimientos #1

CAPÍTULO 1

Ricardo Antonio Bermúdez Osorio

DOCENTE

Ingeniero de sistemas y computación

Universidad Tecnológica de Pereira, 2008

 

Especialista en ingeniería del software
Universidad Autónoma de Manizales, 2012

tusk@utp.edu.co

Objectivos

  • Modelado de requerimientos mediante diagramas de actividades
  • Clasificar, evaluar y priorizar requerimientos de un sistema de información
  • Especificar requerimientos de software
  • Revisar y conocer estándares para la gestión de requisitos de software

 

Introducción

  • 1969: Se crea el término "Ingeniería del Software"
  • 1993: Se crea el término Ingeniería de Requerimientos (RE por sus siglas en inglés)

Algo de historia

Introducción

“El grado en que un producto, proceso o sistema cumple con sus requerimientos” (IEEE 610.12)

Definiciones

“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)

Introducción

Reporte CHAOS

El reporte CHAOS presenta la causa raíz del rendimiento del proyecto de software. El informe también incluye datos clásicos de CHAOS en diferentes formas con muchos gráficos. La mayoría de los datos provienen de la base de datos CHAOS de más de 50,000 perfiles de proyectos detallados año tras año.

Introducción

Reporte CHAOS

Introducción

  • 1969: Se crea el término "Ingeniería del Software"
  • 1993: Se crea el término Ingeniería de Requerimientos (RE por sus siglas en inglés)

Algo de historia

Introducción

  • Involucrar al usuario
  • Apoyo de directivos
  • Clara definición de requerimientos

Factores clave para éxito de proyectos

  • Requerimientos o especificaciones incompletas

Factores de reto en los proyectos

The standish group "Report CHAOS", 1995

Introducción

  • Como muchos requerimientos se escriben en lenguaje natural, los directivos a menudo piensan que cualquier persona puede hacer ingeniería de requerimientos
  • Pero en realidad:

“ … Obtener un buen conjunto de requerimientos es un proceso muy difícil.”

Introducción

  • Debemos entender que vamos a desarrollar antes de desarrollarlo.
  • Las estadísticas muestran que esto todavía no se cumple

Deb Jacobs, CrossTalk, 2006

Introducción

Se han hecho grandes avances en Ingeniería del software

  • Estándares, como UML
  • Metodologías formales y métodos ágiles
  • Modelos de calidad, como CMMI
  • Herramientas para automatizar procesos de desarrollo

Pero...

Estamos desarrollando el software correcto?

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. 

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!

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)

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

Made with Slides.com