Descargar como PDF, PPTX
Más contenido relacionado
Similar a Aseguramiento control calidad-software
Aseguramiento control calidad-software
- 1. Seminario: Introducción ala Gerencia Pública Informática Módulo de Aseguramiento y 1 Módulo de Aseguramiento y Control de calidad de software Instructor: Alfonsina Morgavi Disertante: Alfonsina Morgavi
- 2. Agenda 1. Introducción 2. Quées el Aseguramiento de calidad 3. Qué es el Control de calidad 4. El entorno de la calidad 5. Qué es un modelo de calidad de software 6. Acerca de los modelos y estándares de calidad 7. El enfoque basado en procesos 8. Las metodologías ágiles ¿Qué es la calidad de software? 2 9. ¿Qué es la calidad de software? 10. La perspectiva del usuario 11. El proceso de pruebas como parte del proceso de desarrollo 12. Estadísticas 13. Bibliografía y sites recomendados
- 3. Introducción • El conceptode calidad ha evolucionado a lo largo del tiempo… de Juran y Deming … a la mejora de los procesos de una organización incluyendo a las personas involucradas en dichos procesos. • En la actualidad , la calidad ha pasado a ser una política de gestión empresarial, donde el compromiso de todos los niveles organizativos es un requisito para el éxito. 3 • El objetivo ya no es sólo la ausencia de defectos, sino la adecuación a los requisitos de negocio y del cliente. • Así la calidad está presente en todas las actividades del ciclo de vida de un proyecto de software.
- 4. Introducción Pilares sobre losque se sustentan las actividades de calidad: • infraestructura apropiada de soporte • un grupo de personas especializada en esta disciplina y • procesos alineados con los objetivos de negocio de forma que permitan una mayor industrialización en el desarrollo y mantenimiento. 4 TecnologíaRecursos humanos B Procesos A C D
- 5. Introducción La calidad delsoftware puede gestionarse desde diferentes niveles: • Visión de producto: enfoque en las pruebas a realizar en cada etapa del ciclo de vida del desarrollo, para detectar y corregir los posibles defectos que puedan surgir. • Visión de proceso: se enfoca en gestionar todas las áreas de proceso de una organización mediante la implementación de una metodología de 5 una organización mediante la implementación de una metodología de trabajo. • El enfoque basado en procesos permite obtener mayor información de los procesos, de modo que puedan controlarse y mejorarse, y produzcan así un aumento de la calidad de los productos y servicios relacionados con ellos.
- 6. • Tiene sufoco de atención sobre los procesos • El rol del aseguramiento de calidad es – gestionar la calidad – monitorear y mejorar los procesos de trabajo – establecer el control de calidad a realizar, pero no necesariamente realizarlo ¿Qué es el aseguramiento de calidad? 6 realizarlo – utilizar los resultados del control de calidad para mejorar los procesos • El una actividad “preventiva”
- 7. • Tiene sufoco de atención sobre los productos • El rol del control de calidad es – medir los productos contra estándares ó atributos previamente definidos – identificar defectos, informarlos y verificar sus correcciones – desarrollar tareas de validación y verificación de productos ¿Qué es el control de calidad? 7 – desarrollar tareas de validación y verificación de productos – chequear la calidad de los productos intermedios, como así también la del producto final • El una actividad “detectiva”
- 8. Es un conjuntode buenas prácticas para el ciclo de vida del software, enfocado en los procesos de gestión y desarrollo de proyectos. Los modelos de calidad dicen QUE hacer no COMO hacerlo. ¿Que es un modelo de calidad de software? 8 ¿Porque? • Depende las metodologías que se utilice • Depende de los objetivos de negocio
- 9. • McCall’s QualityModel • Boehm’s Quality Model • FURPS/FURPS+ • Dromey's Quality Model • ISO 9001:2008 • ISO 9126 • Spice ISO/IEC 15504 Acerca los modelos y estándares de calidad 9 • Spice ISO/IEC 15504 • ISO 12207 • Estándares IEEE • CMMI Capability Maturity Model Integration - TSP - PSP • ITIL • Six Sigma • Métrica 3 • Moprosoft • Competisoft • Otros…
- 10. El enfoque basadoen Procesos • La calidad de un producto está directamente influenciada por la calidad de los procesos que se utilizaron para desarrollarlo y mantenerlo • ¿Porqué son importantes los procesos? – Porque los productos derivan de ellos 10 • Enfocándose en el proceso es posible predecir: – Repetitibilidad de los productos intermedios y finales – Tendencias en los proyectos – Características de los productos
- 11. • Los modelosde calidad tradicionales están basados en la mejora de procesos • En general consisten en utilizar las mejores prácticas para el desarrollo y mantenimiento de productos y servicios El enfoque basado en Procesos 11 • Proporcionan un punto de partida y un marco de referencia, para definir las mejoras a realizar en los procesos de una organización • Describen un camino de mejora evolutivo para que las organizaciones pasen de procesos inmaduros a procesos maduros de forma disciplinada
- 12. Actividad Actividad Actividad Objetivos ¿Qué es unproceso? 12 Proceso Actividad Actividad Actividad Infraestructura y recursos SalidasEntradas
- 13. Administrado Cuantitativamente Optimizado 4 5 Foco enla mejora de procesos Proceso medido y controlado Representación en etapas El modelo CMMI 13 Definido Inicial Administrado Proceso impredecible, pobremente controlado y reactivo 2 3 1 Proceso definido por proyecto y generalmente reactivo Proceso definido por la organización, y proactivo SEI original draws from course “Introduction to CMMI Staged representation V1.2” Patents & Trademark Office By Carnegie Mellon University ®
- 14.
- 15. Este modelo decalidad clasifica en la primera parte del estándar, ISO 9126-1, la calidad del software en un conjunto estructurado de características y subcaracterísticas de la siguiente manera: ISO 9126 15
- 16. Las metodologías ágiles •En el 2001 algunos disidentes del desarrollo de software basados en procesos, exponen una nueva metodología denominada XP Extreme Programming. • Nace el término “Métodos Ágiles” para definir a los métodos que estaban surgiendo como alternativa a las metodologías formales a las que consideraban excesivamente “pesadas” y rígidas por su carácter normativo y fuerte dependencia de planificaciones detalladas previas al desarrollo. 16 • Esta nueva alternativa de desarrollo resume su método de trabajo en cuatro postulados. Este postulado ha sido denominado como Manifiesto Ágil. • Son frecuentes las posturas radicales entre los defensores de los modelos de procesos y los defensores de modelos ágiles…
- 17. 1. Valorar mása los individuos y su interacción que a los procesos y las herramientas 2. Valorar más el software que funciona que la documentación exhaustiva 3. Valorar más la colaboración con el cliente que la negociación Los 4 postulados del Manifiesto Ágil 17 3. Valorar más la colaboración con el cliente que la negociación contractual 4. Valorar más la respuesta al cambio que el seguimiento de un plan
- 18. • Nuestra principalprioridad es satisfacer al cliente a través de la entrega temprana y continua de software de valor. • Son bienvenidos los requisitos cambiantes, incluso si llegan tarde al desarrollo • Los procesos ágiles se doblegan al cambio como ventaja competitiva para el cliente. • Entregar con frecuencia software que funcione, en periodos de un par de semanas Los principios del Manifiesto Ágil 1/2 18 • Entregar con frecuencia software que funcione, en periodos de un par de semanas hasta un par de meses, con preferencia en los periodos breves. • Las personas del negocio y los desarrolladores deben trabajar juntos de forma cotidiana a través del proyecto. • Construcción de proyectos en torno a individuos motivados, dándoles la oportunidad y el respaldo que necesitan y procurándoles confianza para que realicen la tarea.
- 19. • La formamás eficiente y efectiva de comunicar información de ida y vuelta dentro de un equipo de desarrollo es mediante la conversación cara a cara. • El software que funciona es la principal medida del progreso. • Los procesos ágiles promueven el desarrollo sostenido. Los patrocinadores, desarrolladores y usuarios deben mantener un ritmo constante de forma indefinida. • La atención continua a la excelencia técnica enaltece la agilidad. Los principios del Manifiesto Ágil 2/2 19 • La atención continua a la excelencia técnica enaltece la agilidad. • La simplicidad como arte de maximizar la cantidad de trabajo que no se hace, es esencial. • Las mejores arquitecturas, requisitos y diseños emergen de equipos que se auto- organizan. • En intervalos regulares, el equipo reflexiona sobre la forma de ser más efectivo y ajusta su conducta en consecuencia
- 20. Proceso creativo 1 Niveldemadurez delosprocesos Skill delos recursos Procesos - Personas 20 Proceso definido 5 Niveldemadurez delosprocesosDefinición de procesos 0% 100% Porcentaje de procesos definidos
- 21. Todo proyecto tienecomo objetivo producir ¿Qué es calidad en software? La calidad del software es una preocupación a la que se dedican muchos esfuerzos. Sin embargo, el software nunca es perfecto. 21 Todo proyecto tiene como objetivo producir software de la mejor calidad posible, que cumpla, y si puede supere las expectativas de los usuarios. ¿Pero qué esperan realmente del software los distintos actores, involucrados en el proceso de desarrollo?
- 22. ¿Qué es calidaden software? IEEEd. 610-1990 “La calidad del software es el grado con el que un sistema, componente o proceso cumple con los requerimientos especificados y las necesidades o expectativas del cliente o usuario”. “Un software de calidad es aquel que cumple con los requerimientos funcionales y de performance, además de ser fácil de mantener, es confiable y aceptable” Un Manager de TI… 22 aceptable” Un Usuario Un software que permite llevar adelante correctamente la operatoria de un negocio en el mundo real, que pueda iniciar y finalizar las operaciones que tengo que realizar sin sorpresas… Otros… • Calidad, es mucho más que ausencia de “Bugs” • La calidad no es un destino final, sino un viaje • La calidad es un concepto multidimensional
- 23. Planificación: • si laplanificación es poco realista… Requerimientos: • si los requerimientos son pobres, confusos, incompletos, demasiado generales y no se pueden testear… Algunos problemas de la industria… 23 Pruebas: • si no se realizan las pruebas adecuadas no se sabrá el verdadero status del software hasta que nos lo diga el usuario final… Comunicación: • si los involucrados en el proceso de desarrollo no conocen qué se espera del software…
- 24. Una organización inmadura Trabajadesde el “matafuegos” en vez de prevenir y controlar Improvisa y actúa en respuesta a las crisis Una organización madura Define Previene Estima basándose en experiencias Tipos de organizaciones… 24 Estima en forma idealista No define la calidad de los productos sobre una base objetiva Estima basándose en experiencias anteriores, reales y cuantificadas Tiene objetivos cuantificables para medir la calidad de sus productos Controla la calidad de los productos que produce No puede predecir la calidad de los productos Puede predecir la calidad de los productos
- 25. Requerimientos • Documentados • Claros •Completos • Alcanzables • Acordados Planificación • Deben planificarse tiempos para: • El diseño • Las pruebas • La corrección de errores: • Nuevas pruebas Pruebas • Planificadas • Diseñadas • Ejecutadas • Informadas Comunicación • Implementar instrumentos de comunicación • Fomentar el trabajo en equipo • Asegurarse de que la información del Algunas soluciones para la industria 25 • Documentar • Y todas las otras actividades a realizar durante el proyecto la información del proyecto esté disponible y actualizada Se trata de implementar prácticas que por experiencia sabemos, mejorarán el proceso de desarrollo y el producto final
- 26. La perspectiva delUsuario 26
- 27. 27 Propaganda TBI –CaliberRM – Magazine Testing and Quality Engineering October 2000
- 28. ¿Qué percibe elUsuario? ¿Si hace que sean más extensos que antes? ¿Si hace que sea necesario definir procesos adicionales, dejando algunos antiguos procesos obsoletos? ¿Y si este software no encaja con los procesos del negocio? ¿Si hace que los procesos sean más complejos o dificultosos que antes? ¿Cubre este software mis necesidades? 28 ¿Cubre este software mis necesidades? ¿Hasta dónde responde a mis requerimientos? ¿Cómo funcionará en mi ambiente real de trabajo?
- 29. ¿Qué percibe elUsuario? 29
- 30. ¿Cuánto dinero gastanlas empresas en batallas entre áreas de la misma Organización? ¿Qué percibe el Usuario? 30 ¿Cuánto dinero gastan las empresas por no haber explicitado los requerimientos adecuadamente?
- 31. Hablemos de costos •Los costos por el incumplimiento son, entre otros, los gastos en los que incurrimos por reparar las cosas que hicimos mal. • Pocas organizaciones calculan, los costos “de tener que volver hacia atrás” • Costo de demandas … 31 • Costo de demandas … ¿ Cuál es el costo del daño de la marca? ¿ Cuál es el costo de la interrupción de un servicio? ¿ Cuál es el costo de un usuario insatisfecho?
- 32. El proceso depruebas como parte del proceso de 32 como parte del proceso de desarrollo de software
- 33. ¿Qué es testear? Esel proceso de analizar los componentes del software para detectar diferencias entre lo existente y las condiciones requeridas y evaluar 33 las características o rasgos de cada componente del mismo. IEEE
- 34. Las pruebas (procesodinámico) implican operar un sistema en condiciones controladas y realizar la evaluación de los resultados. ¿Qué es Testear? Es hacer una investigación empírica, con el objetivo de proveer información objetiva acerca de la calidad de un producto. 34 evaluación de los resultados. Las condiciones controladas deberían incluir tanto condiciones normales como anormales. Es un proceso detectivo
- 35. Modelo V&V Test de Aceptación Visióngeneral del sistema Especificación del sistema Diseño y arquitectura Test de Integración Test del Sistema 35 Verificación Validación arquitectura Diseño detallado Test Unitario Integración Código Proceso de test estático Aplicable a documentos y al código Detecta un alto número de errores Proceso de test dinámico Involucra ejecución Usualmente revela síntomas Verificación y Validación son complementarios “Test” es genérico puede significar verificación, validación ó ambos Históricamente “test” ha significado validación
- 36. Modelo W 36 Validación: consiste mayormenteen la ejecución de código Verificación: algunos definen esta etapa como la del “test humano”, ya que consiste en trabajar sobre documentos “en papel”, trabajo de escritorio
- 37. Modelo W 37 Una vezidentificados los riesgos se especifica los productos que necesitan ser probados, a continuación, seleccione las técnicas de pruebas (estáticas y dinámicas) a continuación, se planifican las actividades de prueba lo más cerca posible a las actividades de desarrollo que generan los productos a testear.
- 38. Test estático -Verificación Se realiza sobre los requerimientos, especificaciones , y todo tipo de documentos ó artefactos generados durante la 1ra etapa del desarrollo. • Revisión de diferentes tipos de documentos tales como: revisiones formales, inspecciones, walkthroughs entre otros. Cada una de estas técnicas tiene su método de trabajo. • Análisis estático de código: se verifica la adherencia del código a normas y estándares predefinidos. Existen herramientas para realizar análisis 38 y estándares predefinidos. Existen herramientas para realizar análisis estático de código… • El test estático detecta errores tempranamente, también errores potenciales. • Realizar tests estáticos brinda una mejor visión y conocimiento del de los objetivos del software , sus fortalezas y debilidades; lo que se deberá reflejar en las previsiones de pruebas dinámicas a realizar en el proceso de validación
- 39. Un auto esun sistema complejo, con muchos componentes. Cada componente individual es inspeccionado y probado. (Pruebas de Unidad) Una vez que todos los componentes son probados individualmente, los Test dinámico - Validación 39 componentes son integrados hasta construir un auto. (Pruebas de Integraciòn) Las Pruebas de Sistema se realizan una vez ensamblado el auto completo para aseguar que el auto trabaja correctamente en varias condiciones. Gentileza de Gesdas IT
- 40. Proceso general detest 40 Proceso general de test
- 41. Capacitación Inicial Planificación PreparaciónEjecución Evaluación final Proceso general de test 41 Inicial (Inducción) Planificación Preparación Ejecución final
- 42. Capacitación Inicial Recopilación dedocumentación existente Verificación de grado de actualización (versión…) Relevamiento a: analistas, usuarios, áreas de negocio 42 Generación de documentación adicional Validación de la documentación generada
- 43. Planificación • Relevamiento funcionalde los circuitos críticos (riesgos) • Diseño del plan de pruebas, (entre otros puntos) se deberá especificar: • Especificación de tipos de Test a realizar y alcance de las pruebas • Definición de procedimientos estándares para las pruebas 43 • Definición de procedimientos estándares para las pruebas • Definición de circuitos de información entre Test y Desarrollo • Definición estándar para la clasificación de defectos • Definición de recursos a utilizar • Objetivos de cada etapa del test (unit, integración, sistema, UAT, otros)
- 44. Planificación • Criterio definalización • Calendarios • Roles y Responsabilidades: • quien diseña, quien ejecuta, quien verifica los casos de prueba… • quien corrige los errores, y ejecuta el test de regresión… • Herramientas a utilizar • Configuraciones especificas de hardware 44 • Configuraciones especificas de hardware • Procedimientos de Seguimiento del proyecto de test • Validación con stakeholders
- 45. Preparación • Diseño decasos de prueba • Carga de inicial de información en la herramienta de gestión • Generación de informes de avance del proyecto 45 • Generación de informes de avance del proyecto • Evaluación preliminar de transacciones a automatizar • Validación con analistas funcionales, ó áreas de negocio
- 46. Ejecución • Ejecución delos casos de prueba • Generación de reportes de defectos • Seguimiento de reportes de defecto 46 • Seguimiento de reportes de defecto • Generación de informes de avance del proyecto • Ajuste de Plan y Casos de prueba • Validación con analistas funcionales / áreas de negocio
- 47. Evaluación final • Generacióndel Informe de final de pruebas • Revisión de informe final con stakeholders • Evaluación general del proyecto y ajustes (definición de pruebas adicionales) 47 pruebas adicionales) Revisión interna • Evaluación de mejoras al proceso de test • Análisis de backlog de defectos • Lecciones aprendidas
- 48. Desarrollo Producción Circuito deTest 48 Versiones a probar Ciclos de Test Versión a implementar
- 49. Ciclo de recorridodel producto Ambiente de Producción Ambiente de Desarrollo Ambiente de Test 49
- 50. Modelos y estándares paratest 50 para test
- 51. TMMI – TestMaturity Model Integration Administrado Cuantitativamente Optimizado 4 5 Foco en la mejora de procesos, y en las herramientas Proceso medido y controlado, objetivos cuantitativos para la calidad del producto y el rendimiento de los procesos 51 Definido Inicial Administrado Proceso caótico, sin definición 2 3 1 Valida que el producto satisface los requerimientos, Solo se realiza test post-codificación Proceso y estándares definidos, proactividad en la mejora de los mismos TMMi® is the registered trademark of the TMMi Foundation.
- 52. TMAP –Test ManagementApproach Plan Ctrl Prep Spec Exec Comp Preparación Especificación Ejecución Evaluación Control Es un estándar para pruebas estructuradas Business Driven Test Management -BDTM. Gestiona los proyectos basándose en 4 aspectos fundamentales: • Tiempo • Costos 52TMap was created by the dutch division of Sogeti which is part of Capgemini. Planificación Plan Infra Prep Spec Exec Comp Setup y mantenimiento de infraestructura • Costos • Riesgos • Resultados Modelo de ciclo de vida de TMAP
- 53. TPI NEXT –Test Process Improvement El modelo TPI ha crecido a partir de la experiencia y proporciona un marco de referencia para determinar los puntos fuertes y débiles del proceso de pruebas y formular acciones concretas y realistas de mejora para este proceso. 53Copyright © 2009 Sogeti or one of its affiliates. All rights reserved TPI® is a registered trademark of Sogeti.
- 54. TPI – TestProcess Improvement Área Clave Inicial Controlado Eficiente Optimizado Organización del Test Métricas 54 Gestión del proceso de Test Otros…
- 55. Otros modelos • TestOrganisation Maturity Model (TOM™ ) • Test Improvement model TIM • Minimal Test Practice Framewok MTPF • Otros 55
- 56.
- 57. ¿Dónde se originanmayormente los defectos? 30% 40% 50% 60% 27% 56% 57Datos publicados con la autorización del Quality Assurance Institute - 57 La mayor parte de los defectos son creadoscreados en las “primeras“primeras etapas”etapas” de los proyectos 0% 10% 20% Código Otros Diseño Requerimientos 7% 10%
- 58. 20% 25% 30% 35% 40% 45% 50% 15% 50% 15% ¿Dónde son utilizadosmás habitualmente los recursos de test? 58 0% 5% 10% 15% Propuestas Requerimientos Diseño Código Test Instalación 3% 10% 7% La mayor parte de los defectos son encontradosencontrados en las “últimas“últimas etapas”etapas” del proyecto. Datos publicados con la autorización del Quality Assurance Institute -
- 59. El lado humanode la calidad 59 “La calidad no está en las cosas, sino en la gente que hace las cosas”
- 60. El lado humanode la calidad Si tuviéramos que dar una descripción de las habilidades que serían necesarias para un tester, deberíamos verlo desde 2 perspectivas: 60 habilidades técnicas y habilidades personales
- 61. El lado humanode la calidad LosLos testerstesters se entrenan, no nacense entrenan, no nacen • Específico, en los distintos aspectos de la actividad En herramientas específicas 61 • En herramientas específicas • En nuevas tecnologías • En aspectos de negocios (finanzas, energía, telcos, etc.etc.)
- 62. El lado humanode la calidad Algunas cualidades personales a desarrollar: • buena comunicación oral y escrita • trabajo en equipo • escucha activa 62 • actitud integradora • visión global • habilidades de negociación • pasión por aprender
- 63. La calidad nuncaes un accidente; siempre es el resultado del esfuerzo inteligente. 63 esfuerzo inteligente. John Ruskin
- 64. Bibliografía recomendada • Ingenieríadel Software – Un Enfoque práctico Roger S. Pressman Mac Graw Hill 4ta. Edición • Effective Methods for Software Testing - William Perry Wiley – QED • Testing Computer Software – Kaner – Falk – Nguyen International Thomson Computer Press • Managing the Testing Process – Rex Black Microsoft Press 64 • Surviving the chalenges of Software Testing William Perry – Randall Rice - Dorset House Publishing • The Journal of the Quality Assurance Institute • Magazine: “Software Testing & Quality Engineering” – STQE Magazine • Magazine: Testing experiences. www.testingexperience.com (la revista de los profesionales de test) • Magazine: Software Guru: www.softwareguru.com.mx
- 65.
- 66. Gracias por suatenciónGracias por su atención Consultas......Consultas...... 66 [email protected]