1. Congreso de Ingeniería de Software
y Nuevas Tecnologías
Calidad de Software como un
gobierno para ALM

2. Objetivos
• Cifras
• Evolución del software
• ALM
• Pruebas
• ISTQB
• TMMi

3. Cifras
• 89% de las empresas solicitan herramientas para
Software Testing y SDLC;
• 42% de las empresas están utilizando tecnologías
Web 2.0 como AJAX, Flash, etc;
• 44% de todos los proyectos de software se
entregan tarde, por encima de presupuesto o con
menos funciones;
• 2/3 partes de las empresas de TI encuestadas
dicen que la detección de defectos se realizan al
final del proceso de desarrollo teniendo un
impacto crítico o significativo en producción;

4. Cifras (continuación)
• 24% de los proyectos de software se cancelan antes de la
finalización o entrega y nunca son utilizados.
• 59% de las empresas encuestadas dicen que la dificultad de
administrar equipos de desarrollo de aplicaciones distribuidos
causan un impacto significativo en la productividad.
• Más del 60% de las empresas encuestadas que los proyectos
ágiles de TI son más difíciles de ejecutar.

5. Cifras (continuación)
• El Software es culpable por los problemas de
negocio más importantes que cualquier otro
producto construido por el hombre.

6. THE STANDISH GROUP
• En Estados Unidos se gastan $250 billiones cada año en
24% de los proyectos de software se cancelan
antes de la finalización o entrega y nunca son
utilizados. 32% 24%
44% de todos los proyectos de software se
entregan tarde, por encima de presupuesto o con
menos funciones produciendo costos del 189%
44%
más.
2% de los proyectos de software son
completados a tiempo y dentro del presupuesto.

7. Evolución del Software
• “La criticidad del software para el negocio, el incremento en
la complejidad de las aplicaciones de software y los
sistemas y las fuertes presiones del negocio por la calidad,
productividad y mejores tiempos para alcanzar el mercado
han sido fuerzas positivas en el pasado y lo continuarán
siendo…”

8. Failur
e
• Fallas limitadas a un reducido conjunto de aplicaciones
• Los riesgos eran limitados, consecuencia del alcance de las fallas
Lógica Lógica Lógica Lógica
de de de de
Negocio Negocio Negocio Negocio
CRM Operaciones e-Commerce Finanzas
CIO

9. En el Pasado hacer TI era más Simple
• Tecnologías de Software
– Ausencia de middlewares
– Construcción de las aplicaciones sobre el S.O.
– Poca Portabilidad
– Bases de datos centralizadas
– Mayor foco en la tecnología
– Programación estructurada

10. En el Pasado hacer TI era más Simple
• Las Aplicaciones
– Enfocadas a un solo proceso/vertical o función de
negocio
– Interconectividad limitada entre aplicaciones
– Riesgos limitados o reducidos
– Consecuencias de las fallas manejables y acotadas
– Interfaces de Usuario limitadas a texto
– Poca gestión de la calidad de los productos

11. En el Pasado hacer TI era más Simple
• Los Servicios TI para el Negocio
– Poca gestión de la demanda estratégica y operativa
– Gestión de infraestructuras más sencillas
– Servicios TI organizados en silos
– Los servicios de negocio se manejaban únicamente desde
la perspectiva TI
– Gestión ausente o muy limitada de la calidad de los
servicios (monitoreo)
– El monitoreo de los servicios presentaba métricas TI, no
métricas de negocio

12. HOY: Gran Incremento de la Complejidad en TI
SOA, Services Compartidos, Web
2.0, Enterprise 2.0
Crecientes
Equipos Failur
presiones de
e
Distribuidos y tiempo y costo
Externos
Procesos de
Capacidades de negocio nuevas y ágiles negocio
Servicios de Negocio integrados
Complejidad
creciente
?
Las ramificaciones de una falla simple pueden ser desastrosas
CRM Operaciones e-Commerce Finanzas
12 12.08.12

13. HOY: Gran Incremento de la Complejidad en TI
• Tecnologías de Software
– Importante uso de middlewares y tecnologías de
integración
– Las aplicaciones son más independientes del S.O.
– Portabilidad de las soluciones
– Tecnologías Cliente / Servidor, Web, Web 2.0
– Base de datos relacionales, distribuidas y/u orientadas a
objetos
– Coexistencia de Programación Estructurada, Orientada a
Objetos y Orientada a Aspectos

14. HOY: Gran Incremento de la complejidad en TI
• Las Aplicaciones
– Aplicaciones complejas integran diferentes procesos de negocio
– Alto grado de interconexión (punto a punto, uso de middlewares)
– Separación de la lógica de las aplicaciones
– Mayor riesgo
– Consecuencias de las fallas imponderables
– Interfaces de Usuario Sofisticadas
– Nuevas Arquitecturas
– Entrega de funcionalidad y contenido a dispositivos móviles
– Imperativo: Gestión de la Calidad de los Productos

15. HOY: Gran Incremento de la complejidad en TI
• Los Servicios
– Gestión de infraestructuras complejas
– Imperativos debido a la nueva complejidad:
• Gestión de la demanda estratégica y operativa
• Gestión integrada de los silos TI
• Perspectiva de los servicios según el negocio
• Gestión de la calidad de los servicios (monitoreo

16. ALM (Application Lifecycle Management

17. Pruebas
• Si funciona mejor no tocar
• Procesos eternos de implementacion
• Solo falta integrar
• 3 meses de desarrollo y 6 corrigiendo incidencias
• Arreglo una incidencia y meto 10
• En mi maquina si funciona
• LAS TAREAS SE TERMINAN CUANDO LA FUNCIONALIDAD ESTA
PROBADA

18. Pruebas
• Caracteristicas
– Se deben poder ejecutar sin necesidad de intervencion
manual
– Tienen que poder repetirse tantas veces como uno quiera
– Cubrir casi la totalidad del codigo
– Ejecutarse independientemente del estado del entorno
– La ejecucion de una prueba no debe de afectar la
ejecucion de otra
– Debe tener un objetivo claro y conciso

19. ISTQB (International Software Testing Qualification
Board)

20. ¿Por qué es necesario hacer las pruebas?
• Las pruebas contribuyen a evitar y
rectificar los errores y las fallas.
• Es necesario comenzar con las
pruebas tan pronto como se
empiezan a generar errores, es decir
al inicio del proceso de desarrollo.
• Un software incorrecto puede
afectar a:
– Personas
– Compañías
– Ambiente

21. ¿Qué son las Pruebas?
• Testing and debugging.
• Pruebas estáticas y pruebas dinámicas.
• Pruebas como un proceso.
• Pruebas como un conjunto de Técnicas
Pruebas es una actividad utilizada para reducir
riesgos y mejorar la calidad por medio del
descubrimiento de los defectos

22. ¿Qué son las Pruebas?
Una situación puede clasificarse de incorrecta, solo
después de que sabemos cuál es la situación correcta
esperada, por lo tanto un fracaso es un incumplimiento de
un requerimiento específico, es una discrepancia entre el
resultado real o el comportamiento identificado en la
ejecución de las pruebas, contra el definido en los
requisitos.
Una prueba que ha encontrado un defecto, ha
creado una oportunidad de mejora para la
calidad del producto de software

23. Principios Generales de las Pruebas
• Las Pruebas muestran la presencia de errores.
• Las Pruebas exhaustivas pueden llegar a ser posibles.
• Pruebas en etapas tempranas (al inicio del SDLC).
• Agrupación de defectos (principio de Pareto).
• La paradoja del pesticida.
• Las Pruebas dependen del contexto.
• La falacia de la ausencia de errores.

24. Costo de los Errores

25. Modelo V - Niveles de Pruebas

26. Tipos de Pruebas
• Pruebas Funcionales (specificacition-based testing)
– Flujo de Procesos
– Modelos de transición de estados
– Modelos de amenazas
• Pruebas no Funcionales
– Modelos de desempeño
– Modelos de usabilidad
• Pruebas estructurales
– Modelos de control de flujo
– Modelos de estructura de menús
• Pruebas después del que el código ha sido modificado
– Retesting
– Pruebas de regresión

27. La Necesidad de un Modelo de Madurez para Pruebas
• Los esfuerzos para mejorar la calidad
del Software han estado enfocados en
mejorar los procesos de desarrollo
– Se han usado estándares como CMM y
CMMI
– Estos estándares dedican poca atención al proceso de pruebas
• La respuesta de la comunidad de pruebas ha sido la
creación de un estándar complementario a CMMI
– TMMI (Test Maturity Model Integration) es un modelo
detallado para la mejora de los procesos de pruebas

28. Definición de Probar según TMMI
• El proceso que contempla todas aquellas
actividades del ciclo de vida de las
aplicaciones (estáticas o dinámicas)
relacionadas con la planificación,
preparación y evaluación de productos de
software y entregables relacionados para
determinar que satisfacen los requerimientos,
demostrar que se ajustan al propósito por el cual
se construyeron y encontrar defectos.

29. ¿Qué Plantea el TMMI?
• Un marco de trabajo a ser usado
como modelo de referencia para
la mejora de procesos de pruebas
• Utiliza el concepto de niveles de
madurez para la evaluación y
mejora de procesos de pruebas
• Identifica áreas de procesos,
objetivos y prácticas
• Cambiar el foco de la ejecución de las pruebas desde
detección a prevención de defectos
• Un complemento del CMMI (Capability Maturity Model
Integration) usado para mejorar los procesos de desarrollo

30. Optimizado
•Estrategia y •La organización de
Política de pruebas •Métricas de
Pruebas •Programa de desempeño
•Planificación, entrenamiento para
monitoreo y pruebas
control de •Integración y ciclo
Administrado
pruebas de vida de las Cuantitativa-
•Diseño y pruebas mente
ejecución de
pruebas Definido
•Prevención de
Gerenciado defectos
•Caos •Optimización del
•No hay procesos proceso de pruebas
•Esfuerzos •Control de la
heroicos calidad
•Pruebas no •Evaluación de la
funcionales calidad del
Inicial •Ambiente de •Evaluación por Software
pruebas pares •Evaluación
•Automatizar la •Automatización de avanzada por
Gestión de Pruebas pares
Pruebas

31. Beneficios
• KMD, ahorra 2200 horas de trabajo en pruebas al año
• Global Financing, automatizando las pruebas logro un
ahorro de $21 millones acumulados en 4 años.
• JetBlue, aceleró los tiempos de los ciclos de prueba en un
40%.
• T-Mobile EE.UU. Logro un ahorro del 50% del tiempo de
pruebas por año.
• Legg Mason, aceleró el tiempo de entrega de las
aplicaciones críticas para el negocio en un 50%.
• JetBlue pudo reducir los costos de las pruebas en un 73%

32. GRACIAS
Ing. Douglas Quintero
dquintero@maint.com.ec