Oficina de Calidad y Pruebas

Presentación del tema: "Oficina de Calidad y Pruebas"— Transcripción de la presentación:

1 Oficina de Calidad y Pruebas
27 de Marzo de 2012

2 Oficina de Calidad y Pruebas
INDICE Antecedentes DTIC Misión de la Oficina de Calidad y Pruebas Objetivos de la Oficina de Calidad y Pruebas L1 – Política de Calidad L2.1 – Pruebas de Rendimiento L2.2 – Pruebas de Seguridad L2.3 – Pruebas Funcionales Automatizadas Datos Implantación Calidad Principales Tareas en Progreso Consecución de los Objetivos

3 PROYECTOS Antecedentes DTIC RECIENTE CREACION RAPIDO CRECIMIENTO
TIEMPO DIFERENTES CRITERIOS PROYECTOS 1 DITI como unidad joven que experimentó un crecimiento rápido en un periodo. ( Lo que lleva consigo, fundamentalmente: -Diferentes empresas -Diferentes equipos de trabajo Y en un marco, el de la ley 11/2007, de fuertes compromisos de aplicaciones de uso potencialmente masivo de cara al ciudadano) Entre las líneas estratégicas lanzadas se encuentran, por su importancia estructural, las de consolidación y profesionalización de los servicios. Esto incluyó: -Consolidación de equipos de trabajo y sus implicaciones en contratación -Consolidación de infraestructuras -Identificación de la necesidad de un servicio de procedimientación y formalización de todos los procesos -Identificación de la necesidad de cuidar el rendimiento de las nuevas aplicaciones nacidas a la luz de la Ley 11 De aquí surge la misión Reciente creación de la DTIC Rápido crecimiento. En solo X años se ha incrementado el personal de Y a Z (XXX% de crecimiento) Variedad de empresas proveedoras + Personal funcionario nuevo incorporado => Disparidad de criterios al trabajar, ya que no existían unas guías o políticas establecidas. Los proyectos sufren retrasos, incrementos de costes y alto número de errores ERRORES COSTES

4 Misión de la Oficina de Calidad y Pruebas
Aseguramiento de la calidad de los procesos y proyectos de desarrollo SW en la DTIC 2 principales líneas de actuación: Implantación de la Política de Calidad Ejecución de Pruebas Pruebas de Rendimiento Pruebas de Seguridad Pruebas Funcionales Automatizadas ¿Por qué la Oficina de Calidad y Pruebas? Para garantizar la calidad se necesita un ente objetivo e imparcial sin intereses directos en los proyectos, que realice pruebas y auditorias. Dotarle de capacidades de decisión con el respaldo de la dirección Coordinador y mediador de las relaciones entre departamentos para conseguir el éxito en los proyectos La calidad del proceso implica directamente en la calidad de los proyectos => hay que asegurar también la calidad de los procesos El enfoque es global: -Una parte metodológica de procedimentación y otra parte operativa desde el primer momento de testing. Esto es el proyecto lleva 2 velocidades: estratégica y operativa. Política de Calidad Ejecución de Pruebas (de varios tipos: Rendimiento, Seguridad, Funcionales Automatizadas, etc…)

5 Objetivos de la Oficina de Calidad y Pruebas
Mejorar la Calidad de los Proyectos Incrementar la Productividad en el Desarrollo SW Facilitar la Mantenibilidad de los Proyectos Acciones para conseguir los objetivos: Definición e implantación de una Política de Calidad Ejecución de Pruebas a los Proyectos Realización de Auditorias de Calidad Calidad de los Proyectos: Reducir el numero de errores Mejorar la imagen del Ministerio Incrementar la Productividad: Productividad = Proyectos-Funcionalidad / Recursos utilizados Reducir recursos utilizados. Recursos = tiempo, dinero, personas Establecer métricas y SLAs a los proveedores en próximos contratos Facilitar la Mantenibilidad: Varias empresas proveedoras => Mejorar la transferencia de conocimiento El conocimiento debe quedar en la organización => documentar, formación Establecer arquitectura tecnológica homogénea para todos los desarrollos a nivel de desarrollo y sistemas

6 L1 – Política de Calidad I
Organización COORDINACIÓN ESTRATÉGICA APROBACIÓN Dirección Jefes de Área COORDINACIÓN OPERATIVA Oficina de Calidad y Pruebas VALIDACIÓN 1 x Jefe de Servicio 5 x Personal Externo Jefes de Servicio Jefes de Proyecto GRUPOS DE TRABAJO Organización basada en 3 niveles: Definición, Validación y Aprobación para que todo el mundo participe. Implicación e impulso directo desde las capas directivas de la DTIC. Se involucra a todo el personal de la DTIC. Se establecen Grupos de Trabajo con objetivos claros donde participan integrantes de cada una de las áreas de la DTIC. Se selecciona a los mejores especialistas de cada área. Los procesos se establecen buscando el consenso de toda la DTIC, no la imposición. Se percibe como algo de todos y no impuesto. Se aprovechan sinergias. Se facilita la difusión de políticas, procesos y conocimientos avanzados. La Oficina de Calidad y Pruebas coordina toda la definición y resuelve los conflictos justificando y explicando las decisiones. Para la evolución y mejora continua de la Política de Calidad, se van creando nuevos Grupos de Trabajo según las necesidades. JIRA -> Gestión de incidencias, bugtracking, peticiones y solicitudes. Subversion -> Repositorio de Código Fuente y de Documentación de los Proyectos Maven -> Gestión Técnica de los Proyectos. Son scripts que automatizan las tareas de enlazado de librerías, compilación, tests unitarios, empaquetado y despliegue en los diferentes entornos. Hudson -> Plataforma de Integración Continua: De forma automática, se conecta a Subversion, se baja el código, lo compila, empaqueta y despliega con Maven, le lanza las pruebas automáticas de JUnit y Selenium (funcionales), le pasa test de Cobertura de pruebas unitaria, le pasa test de calidad de código (Sonar) y saca informes de todo esto como cuadros de mando. Envía un al Jefe de Proyecto para avisarle del resultado. Guarda histórico de todos datos obtenidos para ver la evolución de cada proyecto. Su lanzamiento se programa de diferentes formas: todas las noches, siempre que hay un commit, etc… Selenium -> Para realizar scripts con las pruebas funcionales que deben pasar los proyectos. La ejecución de dichos scripts realiza la verificación funcional de la aplicación, y se debe realizar como prueba de regresión de forma automática al añadir código a un proyecto, ya sea por evolución del desarrollo normal o por mantenimientos evolutivos / correctivos. DEFINICIÓN GT 1 GT 2 GT 3 GT 4 GT 5 GT 6 GT n …

7 L1 – Política de Calidad II
Metodologías, herramientas y procesos DTIC Metodologías Herramientas REPOSITORIO CÓDIGO FUENTE Y DOCUMENTACION GESTIÓN TECNICA DE PROYECTO INTEGRACIÓN CONTINUA DESARROLLO [IDE] GESTIÓN INCIDENCIAS Y SOLICITUDES Procesos POLÍTICA GENERAL / ESTRUCTURA ORGANIZATIVA / CICLO DE VIDA / MANUALES . / PLANTILLAS GESTIÓN CÓDIGO FUENTE J2EE . Fases PRUEBAS INTEGRACIÓN PRUEBAS RENDIMIENTO PRUEBAS UNITARIAS REQUISITOS ANÁLISIS DISEÑO CONSTRUCCIÓN PRUEBAS EXPLOTACIÓN FUNCIONALES ACEPTACIÓN USUARIO PRUEBAS SEGURIDAD Enfoque metodológico. Definición de la Política aplicando las mejores prácticas de varias metodologías y modelos de referencia en diferentes ámbitos TI. Se realiza un MIX de las metodologías particularizado para el Ministerio. Se selecciona lo que se considera más interesante de cada metodología. Buen gobierno TI, Cuadros de Mando, Métricas, Leyes: Cobit Desarrollo SW: CMMi (modelo de procesos): Se implantan las principales áreas de procesos de los niveles 2 y 3 del modelo. Metodologías Ágiles: Filosofía de integración continua, trocear la funcionalidad del desarrollo en fases acotadas, adaptabilidad al cambio, búsqueda de implicación del usuario final, adelantar la ejecución de pruebas a fases tempranas del desarrollo, automatización. RUP y Métrica 3: desarrollo por iteraciones, fases definidas con tareas acotadas, documentación, procesos. Servicios TI: ITIL: Marco de referencia para los servicios TI. Formación del personal actualmente en ITIL v3. Tecnologías “opensource” como soporte a la implantación de los procesos. Herramientas de referencia en su campo, estables, integrables y ampliamente adoptadas y probadas en la comunidad open source y en importantes empresas/proyectos. Introducción de los nuevos entornos de Integración y Calidad. Los entornos facilitan paralelizar tareas => reducción de tiempos en los proyectos. Entorno de Calidad para garantizar los niveles mínimos de calidad exigidos. Entornos DESARROLLO PREPRODUCCIÓN PRODUCCIÓN INTEGRACIÓN CALIDAD

8 L1 – Política de Calidad III
Ciclo de Vida de los Proyectos J2EE Ciclo de vida definido para los proyectos Explicación de esta transparencia en función del tiempo de la presentación Aunque esta pintada muy secuencial para simplificar el dibujo, realmente las fases se ejecutadas en paralelo (los diferentes entornos permiten esta ejecución en paralelo) y solapadas. El desarrollo se realiza por fases de funcionalidad acotada de no mas de 3 meses de duración. Si no se plantea así el proyecto, no pasa la auditoría. Las pruebas unitarias deben tener una cobertura del 50% como mínimo. Calidad coordina la evolución de todo el ciclo de vida, pero sobre todo participa en los hitos de auditoria (puntos verde) y realizando todas las pruebas del entorno de calidad y las de rendimiento en el entorno de pre. Mas detalle de todo el ciclo de vida en el documento PRO_CAL_CicloVidaJ2EE.doc que hemos realizado

9 L1 - Gestión del Código Fuente
Antes Después Localización PC Usuario Servidor Ficheros Versiones Ramas cod_Proyecto-X.Y.Z Versiones Ramas

10 L1 - Gestión de la Documentación
Antes Después Localización 50% Proyectos documentados PC Usuario Servidor Ficheros Estructura Directorios Nomenclatura Documentos Versiones Nomenclatura Versiones

11 L1 - Política de Calidad y Procesos establecidos
Antes Después Procesos definidos e implantados No hay Procesos Diferentes criterios 70 Proyectos controlados Auditorías

12 L1 - Entornos Tecnológicos
Antes Después Desarrollo local Desarrollo local Integración Calidad Preproducción Preproducción Producción Producción Paralelizar tareas Adelantar pruebas y aceptaciones Facilitar despliegues Pre/Pro

13 L1 - Madurez Desarrollo SW
Antes Después IDE Diferentes criterios Ciclo de Vida y bugtracking Ciclo de Vida Repositorios Librerías Herramientas Empaquetado y despliegue

14 L2.1 – Pruebas de Rendimiento
SISTEMA ……….. ……….. ……….. MONITORIZACIÓN Y ANÁLISIS Gestión de incidencias detectadas Análisis y recomendaciones para solucionar los problemas detectados Procedimiento de pruebas de rendimiento: Estimar la carga basado en datos reales o previsiones Configuración de scripts con las navegaciones más habituales Activación de la monitorización en los diferentes sistemas Lanzamiento de la carga desde JMeter Recogidas de logs, análisis Informe de resultados: Identificación de problemas, análisis causas Recomendaciones para solucionar los problemas Coordinación de la resolución hasta que son resueltos Soporte en la herramienta JIRA para el control y gestión de los errores encontrados Casos de Éxito Certali: La aplicación funcionaba con pocos usuarios y tras las pruebas de rendimiento se solucionaron los problemas hasta poder soportar la carga estimada. Portales: Estabilización de la nueva plataforma. Tunning y optimización de Sistema Operativo, Servidor Web, Servidor de Aplicaciones, JVM, Gestor de Contenidos, Sistemas de Cache, Balanceo de peticiones, etc… hasta llegar a soportar puntualmente un pico de 5 x Carga Máxima detectada en el 2010. VisualVM herramienta para monitorizar las áreas de memoria de la JVM (Maquina Virtual Java) Una prueba de carga se realiza generalmente para observar el comportamiento de una aplicación bajo una cantidad de peticiones esperada. Esta carga puede ser el número esperado de usuarios concurrentes utilizando la aplicación y que realizan un número específico de transacciones durante el tiempo que dura la carga. Esta prueba mostrará los tiempos de respuesta de todas las transacciones importantes de la aplicación. Al monitorizar base de datos, servidor de aplicaciones y servidor web se pueden detectar los cuellos de botella de la aplicación. Duración 12 horas con la carga máxima detectada en la aplicación. Una prueba de estabilidad se realiza para determinar si la aplicación puede aguantar una carga esperada de forma continuada. Generalmente se realiza para determinar si hay alguna fuga de memoria en la aplicación. Duración adecuada 1 semana, con la carga media que soporta la aplicación. Una prueba de estrés se realiza para forzar la aplicación hasta conseguir llegar a un límite en el que la carga provoque la caída de la aplicación. Se va doblando el número de usuarios que se agregan a la aplicación y se ejecuta una prueba de carga hasta conseguir que la aplicación se caiga. Este tipo de prueba se realiza para determinar la solidez de la aplicación en los momentos de carga extrema y ayuda a los administradores a determinar el rendimiento de la aplicación en caso de que la carga real supere a la carga esperada. INFORME

15 L2.1 - Pruebas de Rendimiento
Antes Después Pruebas rendimiento aplicaciones para el ciudadano Carga No se realizaban pruebas Estabilidad Tipos Pruebas Pico Estress Dimensionamiento memoria JVM Validación migraciones tecnológicas

16 L2.2 – Pruebas de Seguridad
APLICACIÓN WEB Ataque automatizado Gestión de incidencias detectadas ATAQUE JBOSS / APACHE ATAQUE ANÁLISIS Ataque manual INFORME Análisis y recomendaciones para solucionar los problemas detectados ATAQUE LINUX / WINDOWS Procedimiento de pruebas de seguridad: Ataques manuales y automatizadas para detectar vulnerabilidades Pruebas de concepto para explotar las vulnerabilidades Informe de resultados: Identificación de problemas, análisis causas Recomendaciones para solucionar los problemas Coordinación de la resolución hasta que son resueltos Soporte en la herramienta JIRA para el control y gestión de los errores encontrados Casos de Éxito Cereci.- Suplantación de identidad y Cross Site Exovi.- Cross Site Nombres de las herramientas utilizadas para las pruebas automáticas: WebScarab, Paros, Nikto, Nessus…

17 L2.2 - Pruebas de Seguridad
Antes Después Pruebas seguridad aplicaciones para el ciudadano e internas Inyección código No se realizaban pruebas Suplantación identidad Vulnerabilidades detectadas y solucionadas Elevación privilegios Revelación info confidencial Configuraciones inseguras Ataques fuerza bruta Análisis de informes del CCN Análisis forense ataques web

18 L2.3 – Pruebas Funcionales Automatizadas
GRABACIÓN EJECUCIÓN ¿OK? Script Selenium CALIDAD ……….. ……….. ……….. Script Selenium Como SGTIC el entorno es el de múltiples desarrollo de pocos usuarios en muchos casos. No se puede asumir la gestión de pruebas funcionales, pero sí, el soporte a la automatización, para mejorar los ciclos de evolutivos de las aplicaciones. Las pruebas funcionales automáticas facilitan las pruebas de regresión durante el desarrollo y los mantenimientos evolutivos y correctivos. Dentro de la automatización que proporciona Maven y Hudson, también se incluyen la ejecución automática de Pruebas Unitarias y de herramientas de control de la cobertura de dichas pruebas unitarias (Cobertura, JCoverage…) ……….. INFORME ……….. ………..

19 Datos Implantación Calidad
70 Proyectos gestionados con JIRA Proyectos nuevos gestionados: 100% Proyectos antiguos gestionados: 50% 45 Proyectos auditados por Calidad Proyectos nuevos auditados: 100% Proyectos antiguos auditados: 30% 15 Proyectos desarrollados con Maven Proyectos nuevos con Maven: 100% 20 Pruebas de rendimiento realizadas Proyectos al Ciudadano: 80% 35 Auditorias de Seguridad realizadas Proyectos al Ciudadano: 70% Proyecto Internos: 10%

20 Principales Tareas en Progreso
Política de Calidad 2.0 Cuadro de Mando Calidad de Código Pruebas Funcionales Automatizadas Integración Continua

21 Consecución de los Objetivos
Objetivo 1: Mejorar la Calidad Detección y resolución de importantes vulnerabilidades en el 90% de los proyectos auditados. Verificación de que las aplicaciones al ciudadano cumplen las expectativas de rendimiento. Reducción del número de errores en las entregas. Objetivo 2: Incrementar la Productividad Reducción de los tiempos en la puesta en producción. ALM “Open Source” que reduce significativamente el TCO. Objetivo 3: Facilitar la Mantenibilidad Proyectos documentados y controlados. El conocimiento queda en el Ministerio no en las personas externas. Algunos costes de herramientas propietarias (licencias + configuración inicial): Microsoft TFS: € HP Quality Center: € CA Clarity PPM: € (PPM = Portfolio & Project Management -> herramienta para gestión de productos y proyectos: tareas, recursos, costes, imputaciones, seguimiento, cuadros de mando, etc… Numero 1 mundial según Gartner y Forrester.) Visure IrQA: € (IrQA es una Herramienta para gestión de requisitos. Compite directamente con IBM Doors que es la referencia) Contactos y referencias AGE preparación concurso ISDEFE: SGNTJ: encomienda de gestión contando con un equipo para el área de seguridad, calidad y pruebas y un equipo de pruebas funcionales de MINERVA Thales: MEH Sopra: Tribunal de Cuentas: verificación de entregas; testing de documentación; testing de calidad de código fuente; testing de seguridad FNMT: auditoría de seguridad del sistema tacógrafo digital GFI:       - Earnst&Young: - Presupuesto anual del equipo de € (sin IVA)

22