Resumen

Especificación de Requisitos

2

Andrés Silva (UDIS/FI/UPM)

2

Especificación de Requisitos

Contenido (según SWEBOK)
• • • • • I. Introducción II. El proceso de Requisitos III. Educción de Reqs. IV. Análisis de Reqs. V. Documentación de Reqs. • VI. Validación de Reqs • VII. Gestión de Reqs. • VIII. La IR hoy

8

La organización de estas clases se basa en la organización que,para el área de Ingeniería de Requisitos, es promovida por el proyecto “SWEBOK: Software Engineering Body of Knowledge”. Este proyecto pretende definir un Curriculum básico universal para establecer los programas de formación de los futuros Ingenieros de Software, así como una posible certificación.

Andrés Silva (UDIS/FI/UPM)

8

Especificación de Requisitos

PARTE I Introducción
Lo másdifícil en la construcción de un sistema software es decidir precisamente qué construir... No existe tarea con mayor capacidad de lesionar al sistema, cuando se hace mal... Ninguna otra tarea es tan difícil de rectificar a posteriori... F. P. Brooks, 1987
11

F. P. Brooks es el autor de “The Mythical Man-Month”, quizá el único libro “clásico” de la Ingeniería del Software (Addison-Wesley, 1975).Brooks fue jefe de proyecto del OS/360, el sistema operativo del IBM/360. A lo largo de este enorme proyecto, Brooks padeció todos los males que constituyren lo que habitualmente se conoce como “crisis del software”.

Andrés Silva (UDIS/FI/UPM)

11

Especificación de Requisitos

La evidencia empírica demuestra que
• Los requisitos contienen demasiados errores • Muchos de estos errores nose detectan al principio • Muchos de estos errores podrían ser detectados al principio • No detectar estos errores incrementará los costes (tiempo, dinero) de forma exponencial • Además, los programadores obedecen los requisitos (cuando existen).
12

Fuente: Libro de Alan Davis que figura en la Bibliografía. Experimento de Gause & Weinberg: A cinco equipos de programadores se les proporcionanuna serie de requisitos pero a un grupo se le pide que minimice la memoria utilizada, a otro que elabore un código claro, a otro que optimice el tiempo de ejecución etc. El resto de los requisitos eran idénticos. Finalmente, cada equipo elaboró un producto que satisfacía los requisitos solicitados, demostrando que es falso eso de que “Los programadores no hacen lo que el usuario desea”. Lo queocurre es que los programadores no pueden hacer lo que el usario desea si desconocen esos deseos.

Andrés Silva (UDIS/FI/UPM)

12

Especificación de Requisitos

Consecuencias
• El sistema resultante no satisfará a los usuarios • Se producirán desacuerdos entre usuarios y desarrolladores • Puede ser imposible demostrar si el software cumple, o no, los requisitos • Se gastará tiempo y dineroen construir el sistema equivocado
13

Andrés Silva (UDIS/FI/UPM)

13

Especificación de Requisitos

La complejidad
• OJO: No estamos hablando de sistemas de 15 o 30 requisitos. También hay
– – – – – Sistemas de cientos de requisitos Sistemas de miles de requisitos Sistemas de 5.000 requisitos Sistemas de más de 10.000 Sistemas de incluso 60.000 (!) requisitos
14

Andrés Silva(UDIS/FI/UPM)

14

Especificación de Requisitos

1995/2001: The Chaos Report
http://www.standishgroup.com

• Gasto anual en EEUU: $250 mil millones en unos 175.000 proyectos. • 31,1% (23%) son cancelados • 52,7% (49%) cuestan un 190% más de lo estimado • Un 16,2% (28%) será finalizado a tiempo y dentro del presupuesto, pero el producto final poseerá (aprox.) la mitad de los requisitosiniciales

15

Andrés Silva (UDIS/FI/UPM)

15

Especificación de Requisitos

La crisis del software y los requisitos
• Boehm, 1975: 45% de los errores tienen su orígen en los requisitos y en el diseño preliminar. • DeMarco, 1984: 56% de los errores que tienen lugar en un proyecto Sw. Se deben a una mala Especificación de Requisitos • Chaos Report: Los factores principales que conducen al...