Introducción a la Ingeniería de Requerimientos

Introducción a la Ingeniería de
Requerimientos
Parte 1: Qué es y Porqué.
Parte 2: Fundamentos.
Parte 3: Entregables
(Repaso)
La Ingeniería de Software
• Se ocupa de construir un producto de software
de alta calidad bajo restricciones de tiempo y
presupuesto.
• Sus dos problemáticas fundamentales son:
– Lidiar con la escala y complejidad de sistemas de
software actuales.
– Identificar que significa alta calidad
• Requiere (como todas las ingenierías)
– Rigor, creatividad, documentación y gestión.
Sebastian Uchitel
2
Calidad ~ Cumplimiento con Propósito
• Software se desarrolla para un propósito
• El propósito es relativo a actividades humanas
– E.g. El propósito de un sistema bancario se relaciona con los
negocios de un un banco y las necesidades de sus clientes.
• El propósito es generalmente complejo.
• Mucha gente y actividades involucradas
• Intereses contrapuestos
• ...
• Ingeniería de Requerimientos trata (en parte) con la
identificación del propósito.
Sebastian Uchitel
(transparencia adaptada de Steve Easterbrook)
3
Qué es Ingeniería de Requerimientos?
No es una fase
o etapa!
Comunicación
es tan importante
como la recolección
y análisis
Calidad signifíca
que cumple con su
propósito.
No se puede decir
nada acerca de
calidad si no se
entiende el
propósito.
Sebastian Uchitel
Requirements Engineering (RE) is a
set of activities concerned with
identifying and communicating the
purpose of a software-intensive
system, and the contexts in which it
will be used. Hence, RE acts as the
bridge between the real world needs
of users, customers, and other
constituencies affected by a software
system, and the capabilities and
opportunities afforded by softwareintensive technologies
Diseñadores
necesitan saber
cómo y donde el
sistema será
utilizado.
Requerimientos
tratan en parte de
lo que se necesita…
…y en parte de lo
que es posible
Necesidad de indentificar todas las
partes involucradas - no sólo el usario y
cliente
(transparencia de Steve Easterbrook)
4
El Software siempre está embebido
• Si la calidad del software depende del grado de cumplimiento de su
propósito, entonces debemos considerar el software como
embebido...
• Embebido en Hardware
– Propiedades de hardware?
– Obvio, pero a veces olvidado...
• Embebido en actividad humana
– Propiedades?
• Embebido en un mundo físico
– Propiedades?
• En este curso hablaremos de Sistemas Intensivos en Software (o
“Sistema”) para referirnos a Software + Hardware + Entorno
• Ingeniería de Requerimientos de Sistemas (Intensivos en Software)
Sebastian Uchitel
5
La voz de la experiencia...
• Poor requirements are ubiquitous ...
"requirements need to be engineered
and have continuing review & revision"
(Bell & Thayer, empirical study, 1976)
• RE is hard & critical ...
"hardest, most important function of SE is the iterative
extraction & refinement of requirements"
(F. Brooks, 1987)
• Prohibitive cost of late correction ...
"up to 200 x cost of early correction"
(Boehm, 1981)
Sebastian Uchitel
(transparencia de Emmanuel Letier)
6
Costo Relativo de Correción de Errores
El Costo de Corrección Tardía (Boehm, 1981)
200
50
1
5
10
20
o
os eño
d
to
ón
g
t
i
a
i
n
n
c
id
a
ie
is
e
od
i
t
n
D
m
C
p
U
e
ni
rim
c
e
e
e
d
A
u
nt
t
e
q
s
a
d
M
Re
t
Te
s
Te
Sebastian Uchitel
El costo de un error
depende del numero de
decisiones que luego se
hacen sobre él
Errores cometidos al
entender los
requerimientos tienen
el potencial de ser los
de mayor costo, porque
muchas decisiones de
diseño dependen de
estos.
(transparencia de Emmanuel Letier)
7
(transparencia de Miguel Felder)
Problemas de Desarrollo: Un ejemplo regional...
Sebastian Uchitel
8
El Problema de los Requerimientos:
(más recientemente...)
• Relevamiento de proyectos de software en EEUU por el
Standish Group
•
1994
1998
Exitosos
16%
26%
Con problemas
53%
46%
Cancelados
31%
28%
Causa percibida de éxito y fracaso (Top 3)
Exitoso
Con problemas
Cancelado
1.
Usuarios involucrados
Falta de input de
los usuarios
Requerimientos
incompletos
2.
Apoyo de gerencia
ejecutiva
Requerimientos
incompletos
Falta de input de
los usuarios
3.
Clara descripción de
requerimientos
Requerimientos
cambiantes
Falta de recursos
Sebastian Uchitel
(transparencia de Emmanuel Letier)
9
Factores que ponen en problemas un proyecto
1.
Falta de input de los usuarios
12.8%
2.
Requerimientos y Especificaciones
Incompletos
12.3%
3.
Requerimientos y Especificaciones cambiantes 11.8%
4.
Falta de apoyo de gerencia ejecutiva
7.5%
5.
Incompetencia técnica
7.0%
6.
Falta de recursos
6.4%
7.
Expectativas no realistas
5.9%
8.
Objetivos poco claros
5.3%
9.
Tiempos poco realistas
4.3%
10.
Tecnología nueva
3.7%
Otros
23.0%
Posiblemente anecdótico pero da una indicación de los
problemas percibidos en el desarrollo de software
Sebastian Uchitel
(transparencia de Emmanuel Letier)
10
Factores que causan una cancelación
1.
Requerimientos incompletos
13.1%
2.
Falta de involucramiento de usuarios
12.4%
3.
Falta de recursos
10.6%
4.
Expectativas no realistas
9.9%
5.
Falta de apoyo gerencial
9.3%
6.
Requerimientos y Especificaciones
cambiantes
8.7%
7.
Falta de planificación
8.1%
8.
“Ya no lo necesitabamos”
7.5%
9.
Falta de gestión
6.2%
10. Incompetencia Tecnológica
Otros
Sebastian Uchitel
4.3%
9.9%
(transparencia de Emmanuel Letier)
11
Factores que contribuyen al éxito
Sebastian Uchitel
1.
Involucramiento de Usuarios
15.9%
2.
Apoyo de Gerencia Ejecutiva
13.9%
3.
Descripción de Requerimientos Clara
13.0%
4.
Planificación Apropiada
9.6%
5.
Expectativas realistas
8.2%
6.
Entregas (milestones) mas pequeñas
7.7%
7.
Personal competente
7.2%
8.
Ownership
5.3%
9.
Visión y Objetivos claros
2.9%
10.
Otros
13.9%
(transparencia de Emmanuel Letier)
12
Resultados similares en otros estudios ...
• Relevamiento de 3800 organizaciones
europeas, 17 países
Los problemas mayores en software son...
– Especificación de requerimientos
> 50% respuestas
– Gestión de requerimientos
> 50% respuestas
(European Software Institute, 1996)
Sebastian Uchitel
(transparencia de Emmanuel Letier)
13
Porqué IR es tan difícil?
• Sistemas compuestos: Gente + Software + Dispositivos
físicos.
– Modos de interacción: complejos, de larga duración, iniciativa
híbrida, iniciativa mixta, social.
– Software le da forma a la actividad humana de manera
compleja.
• Muchos de los problemas que queremos resolver son
“difíciles”
–
–
–
–
–
Sebastian Uchitel
Formulación definitiva del problema?
Correctitud de Soluciones no suele ser blanco o negro
Cada problema es único hasta cierto punto
Cada problema puede ser tratado como síntoma de otro
Problemas suelen tener dimensiones políticas, éticas y y/o
profesionales de peso.
14
Porqué IR es tan difícil?
• Múltiples sistemas coexisten:
–
–
–
–
sistema actual,
múltiples propuestas de sistema a construir,
familia de sistemas,
posibles evoluciones del sistema
• Múltiples niveles de abstracción:
– de objetivos de negocios a detalles operativos
• Múltiples aspectos
– Funcional, calidad, desarrollo
– aspectos duros y blandos
• Stakeholders (partes interesadas) con antecedentes e intereses
diversos
– clientes, usuarios, expertos del dominio, desarrolladores, ...
→ conflictos
Sebastian Uchitel
(transparencia adapteda de A. van Lamsweerde)
15
Qué hace un Ingeniero de Requerimientos? (1)
• “Elicitar” Información
– Objetivos, contexto y alcance
Elicit: to evoke or draw out (a response,
answer, or fact) from someone in
reaction to one's own actions or
questions
– Conocimiento del Dominio y Requerimientos
• Modelado y Análisis
– Objetivos, objetos, casos de uso, escenarios, ...
• Comunicar requerimientos
– resultados del análisis (Feedback), Documento de
Especificación de Requerimientos, prototipos, ...
Sebastian Uchitel
(transparencia adapteda de E. Letier)
16
Qué hace un Ingeniero de Requerimientos? (1)
• Negociación y acuerdo de requerimientos
– Manejo de conflictos y riesgos
– Ayuda en selección y priorización de requerimientos
• Gestión y Evolución de Requerimientos
– Trazabilidad de requerimientos
– Gestión de pedidos de cambios a requerimientos y sus
impactos
Sebastian Uchitel
(transparencia adapteda de E. Letier)
17
El rol central de modelos de requerimientos
Modelos de Requerimientos
generación de
entregables
stakeholders
elicitación
y modelado
sistemas
existentes
Especificación
de Requerimientos
documentos
análisis
y validación
Sebastian Uchitel
(transparencia adapted de E. Letier)
18
Resumen de Parte 1
• Definición de Ingeniería de Requerimientos
• Importancia y dificultades de IR en el
desarrollo de sistemas
• Actividades del Ingeniero de Requerimientos
• Rol central de modelos en IR
Sebastian Uchitel
19