View
87
Download
0
Category
Preview:
Citation preview
LA INGENIERIA DE REQUERIMIENTOS
INTRODUCCIÓN
a) Presentación y contextualizaciónEl alumno desarrolla una actitud analítica y critica que le permita valorar la importancia la ingeniería de Requerimientos en el desarrollo de sistemas de información para la organización. Aprenderá los conceptos principales de la ingeniería de requisitos, y su relación con los sistemas de información.Se explica el proceso de la IR, con sus respectivas fases o etapas, en la cual aprenderá las actividades que debe llevar a cabo en cada una de ellas.
b) Competencia (Logro)
Analiza y reconoce la importancia de la ingeniería de requisitos en el desarrollo de sistemas de información organizacionales.
c) Capacidades
1. Comprende los conceptos fundamentales de la ingeniería de requisitos.2. Comprende la importancia del proceso de ingeniería de requisitos.3. Entiende y aplica las actividades que tiene que tener cada una de las fases del
proceso de ingeniería de requisitos.4. Comprende, relaciona y clasifica los distintos tipos de requisitos.
d) Actitudes
Desarrolla una actitud emprendedora mediante la toma de iniciativas, promoción de actividades y toma de decisiones en relación a la actividad asignada.
Actúa con responsabilidad personal, al cumplir con los horarios establecidos y el respeto a las normas de convivencia.
Cumple con la presentación de los trabajos encomendados de manera individual y en equipo, respetando la iniciativa y aportes de los integrantes.
Desarrolla la creatividad, la innovación, la actitud emprendedora y el respeto a la honestidad intelectual.
e) Presentación de ideas básicas y contenido esenciales de la Unidad
La Unidad de Aprendizaje 1: Introducción a la ingeniería de requisitos, comprende el desarrollo de los siguientes temas:
TEMA 01: LA INGENIERÍA DE REQUERIMIENTOS
TEMA 02: PROCESO DE LA INGENIERÍA DE REQUISITOS.
TEMA 03: PROCESO DE LA INGENIERÍA DE REQUISITOS (CONTINUACIÓN).
TEMA 04: CLASIFICACIÓN Y CAPTURA DE REQUISITOS
1
Tema 01
TEMA 01: LA INGENIERIA DE REQUERIMIENTOS
INGENIERÍA DE REQUISITOS
La base de la ingeniería de
requisitos, radica en conocer
cuáles son las necesidades,
especificaciones y
requerimientos del cliente,
parece muy fácil llegar a cumplir
este objetivo, no obstante el
principal problema en el diseño
de los sistemas de información,
incluso el diseño de base de
datos, es la mala especificación
de los requerimientos del
cliente, por la sencilla razón que
muchas veces ni el cliente
mismo sabe lo que necesita, en
consecuencia la ingeniería de
requisitos, es una rama de la
ingeniería del software, que nos
ayuda a entender al cliente y
capturar mejor los
requerimientos.
Me entendió Claro, si , si,… entiendo
En el prologo a un libro de Ralph Young sobre las prácticas efectivas en los requisitos, el autor de este libro escribió:
Es tu peor pesadilla. Un cliente entra en tu oficina, se sienta, te mira directo a
los ojos, y dice:”Yo sé que usted piensa que entiende lo que digo, pero lo
que usted no entiende es que lo que digo no es realmente lo que quiero
decir”.
2
Esto sucede de manera invariable cuando
el proyecto está avanzado, después de
que han realizado los compromisos
relativos al tiempo de entrega, las
reputaciones están en juego y el dinero
está en serio peligro.
Todos los que hemos trabajado en el negocio de los sistemas y el software
por más de unos cuantos años hemos vivido esta pesadilla, y solo unos
pocos de nosotros hemos aprendido a continuar aun con esta
circunstancia.
Nosotros tenemos dificultades cuando tratamos de obtener requisitos de nuestros clientes. Tenemos problemas al comprender la información que adquirimos.
Permitimos que el cambio nos controle en
lugar de establecer mecanismos para
controlarlo.
Con frecuencia, registramos los requisitos de una manera desorganizada e invertimos muy poco tiempo en verificar lo que registramos.
En resumen, se falla al establecer un cimiento sólido para el sistema o software. Cada
uno de estos problemas representa un reto. Cuando estos se combinan, la imagen es
desalentadora incluso para los gerentes y profesionales del software más
experimentados. Pero existen soluciones.
Para PRESSMAN, Roger S. La ingeniería de requisitos proporciona el mecanismo apropiado para entender:
3
Lo que el cliente quiere, analizar las
necesidades.
Evaluar la factibilidad.
Negociar una solución razonable
Especificar la solución sin ambigüedades.
Validar la especificación
Administrar los requisitos conforme éstos se
transforman en un sistema operacional.
El proceso de la ingeniería de requisitos se lleva a cabo a través de siete distintas
funciones:
Inicio, Obtención, Elaboración, Negociación, Especificación, Validación y Gestión.
Según F.P.Brooks dice:
Lo más difícil en la construcción de un sistema de 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.
La evidencia empírica demuestra que:
Los requisitos contienen demasiados errores
Muchos de estos errores no se 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).
El no capturar los requisitos correctamente conlleva:
Como mínimo en un
incremento de costos y
La posible pérdida del
proyecto
A continuación se describe otras consecuencias, que es necesario analizarlas
con detenimiento:
4
o El sistema resultante no satisfará a los
usuarios.
o Se producirán desacuerdos entre usuarios y
desarrolladores.
o Puede ser imposible demostrar si el
software cumple, o no, los requisitos.
o Se gastará tiempo y dinero en construir el
sistema equivocado
En cuanto a la cantidad de requisitos que tiene un sistema de información es
variada, podemos hablar de sistemascon 10 requisitos o 30 requisitos, pero
también podemos tener sistemas con cientos de requisitos, miles de requisitos,
5000 requisitos o más de 50000 requisitos.
En EEUU $250 mil millones de dólares en unos 175.000 proyectos
aproximadamente, de ese conjunto la realidad es la siguiente:
– 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 requisitos iniciales.
Fuente: http://www.standishgroup.com
Es alarmante prácticamente un porcentaje
muy bajo de proyectos terminan a tiempo y
dentro del presupuesto, pero no con todos los
requisitos iniciales.
La crisis del software y los requisitos:
o Boehm, 1975: 45% de los errores tienen su orígen en los requisitos y en el
diseño preliminar.
o DeMarco, 1984: 56% de los errores que tienen lugar en un proyecto Sw. Se
deben a una mala Especificación de Requisitos.
o Chaos Report: Los factores principales que conducen al fracaso en los
proyectos Sw.
5
Otras historias de terror relacionadas con la mala especificación en
los requisitos de un software de computadora.
Uno de los estudios más conocidos es el de la General Accounting Office (GAO)
de EEUU. Este estudio de 1979 reveló que 47% del dinero empleado en
proyectos software se destinó a sistemas que no llegaron a utilizarse. Otro 29%
se empleó en proyectos que no llegaron a finalizar. Otro 19% se empleó en
software que tuvo que ser profundamente modificado tras su entrega.
Finalmente, tan sólo un 2% del dinero se empleó en proyectos software que sí
cumplieron con sus requisitos, pero se trataba de proyectos más bien
pequeños o de poca envergadura.
En 1981, Victor Basili encontró cerca de 88 errores en una ERS de 400 páginas
para el proyecto “A-7E Operational Flight Program”. Esta ERS había sido
escrita por un grupo de expertos en especificación de requisitos.
Recientemente, la NASA ha sufrido varios accidentes espectaculares cuyo origen
se atribuye a problemas durante la definición de los requisitos.
Cuánto cuesta el solucionar errores en el proceso de software:
Etapa Coste de reparación
Requisitos 1-2
Diseño 5
Codificación 10
Pruebas unitarias 20
Pruebas sistema 50
En producción 200
Acumulación de los errores:
6
Como se observa, los errores cometidos en los requisitos son
los más peligrosos, pues sus consecuencias contaminan todas
las restantes fases del ciclo de vida.
¿Qué podemos hacer?
o Tomar conciencia del problema. Estar a la defensiva.
o No conocemos todas las respuestas, pero conocemos muchas de las preguntas.
Tenemos experiencia.
o Podemos minimizar el impacto de los errores en los requisitos
o Podemos tratar de organizar mejor las tareas relacionadas con los requisitos
o Más recursos para la fase de requisitos.
Existen soluciones definitivas
o No se ha encontrado solución universalmente válida.
o Hay serias dudas acerca de si dicha solución existe:
7
Nos movemos en la frontera socio-técnica de los sistemas: borrosa, voluble e
inconsistente
Los requisitos es donde lo formal se encuentra con lo informal (M.Jackson)
Los requisitos están vivos: emergen, interactúan, cambian, desaparecen.
o Desconfíen de quien ofrezca la solución definitiva a estos problemas
Ingeniería de Requisitos
Para remediar en lo posible los problemas antes descritos surge la ingeniería de
requisitos.
La IR trata de los principios, métodos, técnicos y herramientas que permiten descubrir,
documentar y mantener los requisitos para sistemas basados en computadoras, de
forma sistemática y repetible.
¿Qué son los requisitos?
Información acerca del problema a solucionar. Propiedades y comportamiento del sistema. Restricciones de diseño y fabricación del producto. Descripciones acerca de cómo el futuro sistema ayudará a sus usuarios a realizar
mejor sus tareas. Restricciones acerca de la tecnología que será utilizada en la construcción del
sistema (protocolos, SSOO, COTS, etc.).
Restricciones acerca de las propiedades emergentes del sistema (requisitos no funcionales).
8
Recommended