Calidad del Software en la DGT 27 de Marzo de 2012

Índice Introducción Organización Metodología de trabajo Beneficios y Retos

Problemática de las AAPP Introducción Problemática de las AAPP Externalización masiva de servicios de TI, en muchos casos superando el 70%. Modernización de un gran número de servicios al ciudadano debido a la Ley 11/2007

+ de 150 proyectos vivos En Desarrollo Software: En números: LA DGT Introducción LA DGT En números: 60 millones de activos sólo en Vehículos y Conductores. 25 millones de trámites anuales. Trámites abiertos a la totalidad de los ciudadanos Colaboración con 4.000 AAPP y entidades colaboradoras En Desarrollo Software: + de 150 proyectos vivos + de 25 empresas + de 350 profesionales

Objetivos de un Sistema de Calidad Introducción Objetivos de un Sistema de Calidad Evitar dependencia de los proveedores Garantizar que los trabajos son “correctos” Obtener un conjunto HOMOGÉNEO de TI

Introducción 2007 Creación del Área de Calidad en la Gerencia de Informática de la DGT Primera versión Guía de Desarrollo Creación de los equipos de Auditorías, Pruebas (Rendimiento) y Arquitectura 2008 Primeros Resultados Liberación de la Arquitectura DGT 1.0 Diciembre 2008: 120 aplicaciones recepcionadas siguiendo los estándares y procesos de Calidad definidos 2009 Evolución el Modelo Pruebas Funcionales Inicio trabajos en CMMI-ACQ 2010 Consolidación del Modelo Arquitectura DGT 2.0 Implantación CMMI-ACQ N2 2011 Certificación Implantación y Certificación CMMI-ACQ N3

Organización – Gerencia de Informática Área de Desarrollo Área de Desarrollo Área de Desarrollo Área de Desarrollo Área de Calidad SW Área de Explotación y Sistemas Área de Atención al Usuario Área de Telecomunicaciones

Organización Interna Organización Aseguramiento de la Calidad de los desarrollos hechos por las empresas adjudicatarias: Grupo de Arquitectura Grupo de Auditorías Grupo de Pruebas Aseguramiento de la Calidad de los procesos internos: Procesos internos de gestión de desarrollos SW (basados en CMMI-ACQ)

Grupo de Arquitectura y Sw Común Metodología de Trabajo Grupo de Arquitectura y Sw Común Objetivos: Evitar replicaciones de funcionalidad Homogeneizar aplicaciones Aspecto, accesibilidad Tecnologías internas utilizadas (asegurar compatibilidad) Desarrollo Rápido de Trámites Se compone de: Especificaciones (seguridad, Acceso a Datos..) Componentes y Servicios comunes Directrices de Arquitectura comunes

Auditorías y Pruebas Metodología de Trabajo Grupo de Auditorías: Más de 300 chequeos en todos los niveles del ciclo de vida Requisitos, diseño, código… Despliegues y pases entre entornos (Desarrollo – Preproducción – Producción), coherencia entre entornos. Grupo de Pruebas: Pruebas de Rendimiento Pruebas Funcionales (manuales y automatizadas) INFORME POSITIVO para pagar el expediente

Guía de desarrollo Metodología de Trabajo Documento de referencia Describe la metodología DGT definida Uso obligatorio por contrato para los proveedores de desarrollo sw Todo publicado en www.dgt.es Se revisa y mejora anualmente Auditorías basadas en lo descrito en la guía

Herramientas de apoyo Metodología de Trabajo Gestión Diseño y Código SVN (Repositorio único y común. Versionado de código y documentación asociada.) Diseño y Código RSA + Plugins MAVEN Pruebas HP Quality Center (Portal documentación y gestión) HP Load Runner (Pruebas de Rendimiento) HP Quick Test (Pruebas Funcionales Automáticas)

Beneficios obtenidos Beneficios y Retos Calidad producto final muy controlada Unificación de la forma de trabajo con los proveedores Dependencia del proveedor controlada Homogeneización del software desarrollado  mas fácil de explotar y mantener

Retos de mejora (previo a la certificación CMMI) Beneficios y Retos Retos de mejora (previo a la certificación CMMI) Gestión interna distribuida (4 áreas desarrollo, aprox. 20 Jefes de Proyecto)  compartir conocimientos y experiencia Riesgos por la gran dependencia entre proyectos Conflictos de gestión con el proveedor  se trataban de forma independiente Procedimientos de contratación:  Residía en las personas  No documentado  No existía procedimiento para comunicar y conocer cambios y novedades  Los procesos de contratación se alargaban, por no conocer los últimos requisitos de los agentes implicados (Comisión Ministerial de Administración Electrónica, gestión económica, abogacía del estado, intervención, patrimonio)

Gracias por su atención Katia Kalinova ekalinova@dgt.es