MARZO DE 2012
311 223 2534 - [email protected] Material preparado por Diego Hernan Sánchez
DH
SB
–2
01
0 -
RU
P®
es u
na m
arc
a r
egis
trada p
or
IBM
®
Periodo de tiempo que
comienza al concebir la idea de
un nuevo sistema de
software, y termina cuando este
se retira y deja de funcionar.
Ciclo de vida del software
311 223 2534 - [email protected] Material preparado por Diego Hernan Sánchez
DH
SB
–2
01
0 -
RU
P®
es u
na m
arc
a r
egis
trada p
or
IBM
®
Proceso de análisis y gestión de
requerimientos
Proceso de Diseño
Proceso de construcción
Proceso de pruebasProceso de entrega
versiones a PTI (Release)
Proceso de implantación
Proceso de desmonte de aplicativos
Gestionar ciclo de vida de las
aplicaciones
Ciclo de vida de Aplicaciones
311 223 2534 - [email protected] Material preparado por Diego Hernan Sánchez
DH
SB
–2
01
0 -
RU
P®
es u
na m
arc
a r
egis
trada p
or
IBM
®
Por qué el ciclo
de vida de
aplicaciones?
311 223 2534 - [email protected] Material preparado por Diego Hernan Sánchez
DH
SB
–2
01
0 -
RU
P®
es u
na m
arc
a r
egis
trada p
or
IBM
®
Básicamente, la crisis del software serefiere a la dificultad en escribirprogramas libres de defectos,fácilmente comprensibles, y que seanverificables. Las causas son, entre otras,la complejidad que supone la tareade programar, y los cambios a los que setiene que ver sometido un programa paraser continuamente adaptado a lasnecesidades de los usuarios.
Crisis de software
311 223 2534 - [email protected] Material preparado por Diego Hernan Sánchez
DH
SB
–2
01
0 -
RU
P®
es u
na m
arc
a r
egis
trada p
or
IBM
®
Este problema se identificó por primeravez en 1968, año en el que la OTANdesarrolló la primera conferencia sobredesarrollo de software, y en la que seacuñaron los términos “crisis delsoftware” para definir a los problemasque surgían en el desarrollo desistemas de software.
Crisis de software
311 223 2534 - [email protected] Material preparado por Diego Hernan Sánchez
DH
SB
–2
01
0 -
RU
P®
es u
na m
arc
a r
egis
trada p
or
IBM
®
1. El problema no es nuevo.
2. No somos los primeros en tener
este tipo de problemas.
3. Existen técnicas y herramientas
para enfrentarlo.
311 223 2534 - [email protected] Material preparado por Diego Hernan Sánchez
DH
SB
–2
01
0 -
RU
P®
es u
na m
arc
a r
egis
trada p
or
IBM
®
Continuemos con
algunas cifras.
311 223 2534 - [email protected] Material preparado por Diego Hernan Sánchez
DH
SB
–2
01
0 -
RU
P®
es u
na m
arc
a r
egis
trada p
or
IBM
®
Crisis de software
El proyecto se aborta o el sistema no se llega a utilizar
Aumento de costos, agenda. Las funcionalidades no cubren las expectativas.
Proyecto realizado en el tiempo previsto, con los costes previstos, con la
funcionalidad esperada y ofreciendo un funcionamiento correcto.
Fuente: Standish Group Survey,
Proyectos para el desarrollo de sistemas de software
31%
40%
28%
23%
15%
18%
19%
24%
53%
33%
46%
49%
51%
53%
46%
44%
16%
27%
26%
28%
34%
29%
35%
32%
0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%
1994
1996
1998
2000
2002
2004
2006
2009
311 223 2534 - [email protected] Material preparado por Diego Hernan Sánchez
DH
SB
–2010 -
RU
P®
es u
na m
arc
a r
egis
trada p
or
IBM
®
Evolución
0%
10%
20%
30%
40%
50%
60%
1994 1996 1998 2000 2002 2004 2006 2009
Fracasos 0%
10%
20%
30%
40%
50%
60%
1994 1996 1998 2000 2002 2004 2006 2009
Inferior
0%
10%
20%
30%
40%
50%
60%
1994 1996 1998 2000 2002 2004 2006 2009
Éxito
CVA
311 223 2534 - [email protected] Material preparado por Diego Hernan Sánchez
DH
SB
–2
01
0 -
RU
P®
es u
na m
arc
a r
egis
trada p
or
IBM
®
Importancia de los requisitos
¿Porqué fracasan los proyectos?
Requisitos incompletos: 13%
Cambios en requisitos: 9%
No implicación de usuarios: 12%
Expectativas no realistas: 10%
Producto no necesario: 8%
TOTAL: 52%
311 223 2534 - [email protected] Material preparado por Diego Hernan Sánchez
DH
SB
–2010 -
RU
P®
es u
na m
arc
a r
egis
trada p
or
IBM
®
Importancia de los requisitos
Fase en la que se inyecta el
error
Costo de la
correcciónRequisitos
Arquitectura
Diseño detallado
Construcción
Requisitos Arquitectura Diseño detallado construcción Producción
50-200X
1X
Fase en la que se soluciona el error
100-200X
1X
311 223 2534 - [email protected] Material preparado por Diego Hernan Sánchez
DH
SB
–2010 -
RU
P®
es u
na m
arc
a r
egis
trada p
or
IBM
®
Siempre7%
Frecuentemente13%
Algunas veces16%
Rara Vez19%
Nunca45%
Características / funciones usadas en un sistema típico
311 223 2534 - [email protected] Material preparado por Diego Hernan Sánchez
DH
SB
–2010 -
RU
P®
es u
na m
arc
a r
egis
trada p
or
IBM
®
REQUISITOS
Sus defectos repercuten en todas las fases
Estimación Planificación Diseño Construcción V & V
Validación y
verificación:
Terminado el
desarrollo del
sistema, si las
especificaciones
tienen errores de
bulto, o peor
aún, no están
reflejadas en una
especificación de
requisitos, no será
posible validar el
producto con el
cliente.
Los errores en los requisitos se comportan como una enfermedad contagiosa que
siempre repercute en todas las fases del proyecto.
Estimación:
No es posible
estimar con
rigor costos y
recursos
necesarios
para
desarrollar
algo que no
se conoce.
Planificación
: No se puede
confiar en la
planificación
para el
desarrollo de
algo que no
se sabe bien
como es.
Diseño: Los
errores en
requisitos, las
modificaciones
frecuentes, las
deficiencias en
restricciones o
futuras
evoluciones, prod
ucen
arquitecturas que
más tarde se
confirmarán
como erróneas y
serán
modificadas.
Construcción:
Las deficiencias
en los requisitos
obligan a
programar en
ciclos de prueba y
error que
derrochan horas y
paciencia de
programación
sobre patrones de
“recodificación
continua” y
“programación
heroica”.
311 223 2534 - [email protected] Material preparado por Diego Hernan Sánchez
DH
SB
–2010 -
RU
P®
es u
na m
arc
a r
egis
trada p
or
IBM
®
Los defectos comunes en los
requisitos y sus consecuencias.
Implicación insuficiente
del cliente
Requisitos crecientes
y cambiantes
Requisitos ambiguos
Requisitos
innecesarios
Requisitos mínimos
(insuficientes)
Requisitos mínimos
(insuficientes)
Omisión de las necesidades
de grupos de usuarios
Problemas en la validación
del producto obtenido
Degradación de la estructura
y arquitectura del producto
Pérdida de tiempo en
re-codificación
Trabajo innecesario
Error en la estimación
y planificación
Usuarios insatisfechos
311 223 2534 - [email protected] Material preparado por Diego Hernan Sánchez
DH
SB
–2
01
0 -
RU
P®
es u
na m
arc
a r
egis
trada p
or
IBM
®
- Tiempo del usuario final
explicando nuevamente
que es lo que necesita.
- Tiempo del analista de
Requerimientos
, ajustando los
requerimientos.
- Tiempo de los
desarrolladores, ajustand
o programas.
- Tiempo de los Analistas
de pruebas, Volviendo a
probar.
- Tiempo de los usuarios
probando.
- Impacto al negocio.
- Costo de solucionar
errores en producción.
311 223 2534 - [email protected] Material preparado por Diego Hernan Sánchez
DH
SB
–2
01
0 -
RU
P®
es u
na m
arc
a r
egis
trada p
or
IBM
®
APL311 223 2534 - [email protected] Material preparado por Diego Hernan Sánchez
DH
SB
–2010 -
RU
P®
es u
na m
arc
a r
egis
trada p
or
IBM
®
Acuerdo entre desarrolladores, clientes y usuarios sobre el trabajo
que debe realizarse.
Unos requisitos bien elaborados y validados con el cliente evitan
descubrir al terminar el proyecto que el sistema no era lo que se
pedía.
Acuerdo entre desarrolladores, clientes y usuarios sobre los
criterios que se emplearán para su validación.
Resulta muy difícil demostrar al cliente que el producto
desarrollado hace lo que el pidió si su petición no está
documentada y validada por él.
Base objetiva para la estimación de recursos (coste, personal en
número y competencias, equipos y tiempo)
Si los requisitos no comprenden necesidades reales, las
estimaciones no dejan de ser elementales apuestas. Las
estimaciones en el fondo son cálculos de probabilidad que siempre
implican un margen de error; por esta razón disponer de la mayor
información posible reduce el error.
Beneficios de los buenos requisitos.
311 223 2534 - [email protected] Material preparado por Diego Hernan Sánchez
DH
SB
–2010 -
RU
P®
es u
na m
arc
a r
egis
trada p
or
IBM
®
Definición clara de los atributos de calidad
(ergonomía, mantenibilidad, etc.)
Más allá de funcionalidades precisas, los requisitos
recogen atributos de calidad necesarios que en
ocasiones son desconocidos por los
desarrolladores, produciendo finalmente sistemas
sobredimensionados o con serias deficiencias de
rendimiento.
Eficiencia en el consumo de recursos: reducción de
la re-codificación, reducción de omisiones y
malentendidos.
Tener un conocimiento preciso de lo que hay que hacer
evita la prueba y error, repetición de partes ya
desarrolladas, etc.
Beneficios de los buenos requisitos.
311 223 2534 - [email protected] Material preparado por Diego Hernan Sánchez
DH
SB
–2010 -
RU
P®
es u
na m
arc
a r
egis
trada p
or
IBM
®
• Las pruebas de software son una parte importante
pero muy costosa del proceso de desarrollo de
software. Pueden llegar a representar entre el 30 y
50% del costo total del desarrollo del software
[Myers, 2004]
• Sin embargo, los costos de las fallas en un software
en operación pueden llegar a ser mucho mayores
(catastróficos)
Importancia de las Pruebas de
Software
311 223 2534 - [email protected] Material preparado por Diego Hernan Sánchez
DH
SB
–2
01
0 -
RU
P®
es u
na m
arc
a r
egis
trada p
or
IBM
®
Basado en encuestas a desarrolladores de software
usuarios nacionales, los costos anuales de una
infraestructura inadecuada para las pruebas de
software se estima que oscila entre US$ 22,2 a US$
59,5 miles de millones.
Tenga en cuenta que las estimaciones de impacto no
reflejan los "costos“ asociados con el software de misión
crítica donde un fallo puede llevar a costos muy
elevados, como la pérdida de vida o una falla catastrófica. La
cuantificación de los costes esta fuera del alcance del
estudio.The Economic Impacts of Inadequate Infrastructure for
Software Testing - May 2002
Costo de No probar
311 223 2534 - [email protected] Material preparado por Diego Hernan Sánchez
DH
SB
–2010 -
RU
P®
es u
na m
arc
a r
egis
trada p
or
IBM
®
Comparación No probar Vs. Probar
The Economic Impacts of Inadequate Infrastructure for
Software Testing - May 2002
311 223 2534 - [email protected] Material preparado por Diego Hernan Sánchez
DH
SB
–2
01
0 -
RU
P®
es u
na m
arc
a r
egis
trada p
or
IBM
®
Tiempo de afectación de clientes internos yexternos por fallas en los aplicativos y por lo tantoel tiempo de improductividad que esto genera.
Tiempo que los usuarios deben invertir enpruebas de aceptación.
Costos ocultos, como los generados por la pérdidade tiempo de los clientes y usuarios de losaplicativos y costos y tiempos de estabilización delos mismos.
Incidentes y solicitudes en la MIS relacionadoscon el mal funcionamiento de los aplicativos.
311 223 2534 - [email protected] Material preparado por Diego Hernan Sánchez
DH
SB
–2
01
0 -
RU
P®
es u
na m
arc
a r
egis
trada p
or
IBM
®
APL
311 223 2534 - [email protected] Material preparado por Diego Hernan Sánchez
DH
SB
–2010 -
RU
P®
es u
na m
arc
a r
egis
trada p
or
IBM
®
Beneficios de los buenas pruebas.
Beneficios de los buenas pruebas
Detectar fallos.
Evitar software de baja calidad.
Evitar baja productividad e
insatisfacción al cliente.
Verificar que todos los requisitos se
han implementado correctamente.
Identificar y asegurar que los
defectos encontrados se han
corregido antes de entregar el
software al cliente
311 223 2534 - [email protected] Material preparado por Diego Hernán Sánchez
DH
SB
–2
01
0 -
RU
P®
es u
na m
arc
a r
egis
trada p
or
IBM
®
Top Related