3. La crisis del software (1)
La crisis del software aparece en la segunda era de la
evolución de los sistemas informáticos (alrededor de
1968).
Crecimiento desmedido en
Las actividades de mantenimiento del software
corrección de fallas,
modificación por cambios de requerimientos de
usuarios,
adaptación a nuevos dispositivos
Esfuerzo empleado en dicho mantenimiento comenzó
a absorber recursos en una medida alarmante.
4. La crisis del software (2)
¿Por qué toma tanto tiempo desarrollar software?
¿Por qué es tan elevado su costo?
¿Por qué no se puede entregar programas libres de
errores?
¿Por qué es tan costoso su mantenimiento?
¿Por qué resulta tan difícil constatar el progreso del
desarrollo de software?
5. La crisis del software (3)
Son los sucesivos fracasos de las distintas metodologías
para:
Dominar la complejidad del software, lo que implica el
retraso de los proyectos de software
Las desviaciones por exceso de los presupuestos
fijados y la existencia de deficiencias respecto a los
requisitos del cliente.
6. El Reporte GAO (1979)
Usado tal
como se
entregó
2%
Usado
despues de
cambios
3%
Usado pero
amplimente
reelaborado o
abandonado
después
19%
Pagado pero
no entregado
29%
Entregado
pero nunca
usado
satisfactoriam
ente
47%
7. El Reporte CHAOS (1995)
Terminado y
operativo pero
fuera de
presupuesto y
sin satisfacer
todos los
requisitos
53%
Terminado
dentro de
plazo y
presupuesto
cumpliendo
todos los
requisitos
16%
Cancelado
durante el
desarrollo
31%
8. State Of the Art Report (SOAR 2003)
Las compañías desarrolladoras de software están liberando
productos a sus clientes con 15% de defectos en el producto.
Muchas compañías de desarrollo se gastan entre 30% y 40%
de su tiempo y dinero en correcciones y ajustes a los productos.
Sólo un50% de las compañías emplean cronogramas.
Alrededor del 25% de los proyectos de software son
cancelados.
El costo de obtener y mantener el software en los 80´s fue el
doble de lo que costó su desarrollo.
Durante los 90´s el costo de licenciamiento y mantenimiento se
incrementó en un 30% más que en los 80´s.
La mitad de los proyectos de software se pasaron del
cronograma definido.
Las tres cuartas partes de todo el software liberado para uso
por el cliente tiene fallas.
10. Uso real de las funciones requeridas
Nunca
45%
Raramente
19%
Algunas veces
16%
Frecuente-
mente
13%
Siempre
7%
James Johnson from the Standish Group (XP 2002)
11. Sistemas de Software Simples
Suelen estar construidos y
mantenidos por una sola
persona
Ciclo de vida corto
Pueden construirse
aplicaciones alternativas en
un período razonable de
tiempo
No requieren grandes
esfuerzos en análisis y diseño
Sistemas de Software Complejos
Software de dimensión
industrial
Difícil o imposible que pueda
un desarrollador individual
comprender todas las
sutilezas de su diseño
La complejidad es una
propiedad esencial, que
puede dominarse, pero no
eliminarse
La Complejidad del Desarrollo de Software
12. La Complejidad del dominio del problema
Gran cantidad de requisitos que compiten entre sí, incluso
contradiciéndose
La forma habitual de especificar los requisitos consiste en
grandes cantidades de texto con unos pocos dibujos
Desacoplamiento de impedancias entre usuarios del sistema y
desarrolladores
Los usuarios suelen tener ideas vagas de lo que desean
Dificultades de comunicación
Distintas perspectivas de la naturaleza del problema
Modificación de los requisitos con el paso del tiempo, pues los
usuarios y desarrolladores comienzan a compenetrarse mejor
Mantenimiento de software (cuando se corrigen errores)
Evolución del software (cuando se responde a requisitos que
cambian)
Conservación del software (se emplean medios extraordinarios
para mantener en operación un elemento software anticuado y
decadente
13. Un Ejemplo
Robots en Marte:
Utilizo las técnicas de validación mas complejas
conocidas hasta el momento
100’000.000 de líneas de código
7 actualizaciones mayores al software del sistema
durante el viaje
Fallo en controlador de memoria flash nada mas
haber iniciado su operación
14. El costo de la mala calidad del software
IEEE Spectrum, Sep. 2005
