Este es un documento que nos muestra el concepto acuñado como crisis de sw.

1. Rafael David Rincón B.Calidad de Software ©
Calidad de Software
Contenido
1. La crisis del software
2. Calidad de Software
3. Modelos de evaluación del producto
4. Modelos de Evaluación del proceso
5. Proceso de producción de software
6. Gestión de Requisitos
7. Gestión de Configuración
Profesor
Rafael David Rincón Bermúdez
Departamento de Informática y Sistemas
Bloque 18 2º piso, teléfono: 266 05 00 Ext 453
E-mail: rrincon@eafit.edu.co

2. Rafael David Rincón B.Calidad de Software ©
Introducción al curso
• ¿Qué es Calidad de Software?
• ¿Cómo se puede identificar?
• ¿Quién determina los niveles de calidad?
• ¿Para qué sirve la calidad de software?
Algunos paradigmas:
• Calidad de software = Métricas
• Calidad de software = Pruebas
• Calidad de Software = Certificados de calidad

3. Rafael David Rincón B.Calidad de Software ©
La Crisis del Software/ 1
¿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?






4. Rafael David Rincón B.Calidad de Software ©
La Crisis del Software/ 2
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.

5. Rafael David Rincón B.Calidad de Software ©
The Chaos Report
Tipo 1
16%
Tipo 2
53%
Tipo 3
31% Tipo1: Éxito
Tipo 2: Funcionó, pero …
Tipo 3: Se canceló

6. Rafael David Rincón B.Calidad de Software ©
SOAR Report
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.




7. Rafael David Rincón B.Calidad de Software ©
... y aún hay más
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.





8. Rafael David Rincón B.Calidad de Software ©
La crisis
La crisis del software aparece en la segunda era de la evolución de
los sistemas informáticos (alrededor de 1968).
Las actividades de mantenimiento del software (corrección de
fallas, modificación por cambios de requerimientos de usuarios, y
adaptación a nuevos dispositivos) y el esfuerzo empleado en dicho
mantenimiento comenzó a absorber recursos en una medida
alarmante.

9. Rafael David Rincón B.Calidad de Software ©
Desarrollo de Software: Crisis
Usado como fue liberado: 1%
Usado después de cambios: 3%
Se desarrolló nuevamente: 19%
Se pagó y nunca fue liberado: 29%
Se liberó y nunca se usó: 48%

10. Rafael David Rincón B.Calidad de Software ©
La Complejidad del Desarrollo de Software
“Cuanto más complejo es un sistema,
más probable es que se caiga”
Sistemas de Software Simples
• No son complejos
• 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

11. Rafael David Rincón B.Calidad de Software ©
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.