Your SlideShare is downloading. ×
0
Calidad de Software como un gobierno para ALM
Calidad de Software como un gobierno para ALM
Calidad de Software como un gobierno para ALM
Calidad de Software como un gobierno para ALM
Calidad de Software como un gobierno para ALM
Calidad de Software como un gobierno para ALM
Calidad de Software como un gobierno para ALM
Calidad de Software como un gobierno para ALM
Calidad de Software como un gobierno para ALM
Calidad de Software como un gobierno para ALM
Calidad de Software como un gobierno para ALM
Calidad de Software como un gobierno para ALM
Calidad de Software como un gobierno para ALM
Calidad de Software como un gobierno para ALM
Calidad de Software como un gobierno para ALM
Calidad de Software como un gobierno para ALM
Calidad de Software como un gobierno para ALM
Calidad de Software como un gobierno para ALM
Calidad de Software como un gobierno para ALM
Calidad de Software como un gobierno para ALM
Calidad de Software como un gobierno para ALM
Calidad de Software como un gobierno para ALM
Calidad de Software como un gobierno para ALM
Calidad de Software como un gobierno para ALM
Calidad de Software como un gobierno para ALM
Calidad de Software como un gobierno para ALM
Calidad de Software como un gobierno para ALM
Calidad de Software como un gobierno para ALM
Calidad de Software como un gobierno para ALM
Calidad de Software como un gobierno para ALM
Calidad de Software como un gobierno para ALM
Calidad de Software como un gobierno para ALM
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Calidad de Software como un gobierno para ALM

409

Published on

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
409
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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 cancelanantes de la finalización o entrega y nunca sonutilizados. 32% 24%44% de todos los proyectos de software seentregan tarde, por encima de presupuesto o conmenos funciones produciendo costos del 189% 44%más.2% de los proyectos de software soncompletados 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 eDistribuidos y tiempo y costo Externos Procesos de Capacidades de negocio nuevas y ágiles negocio Servicios de Negocio integradosComplejidad 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 correctaesperada, por lo tanto un fracaso es un incumplimiento deun 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 laheroicos 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. GRACIASIng. Douglas Quinterodquintero@maint.com.ec

×