La DGT apuesta por una visión global de la calidad
- Estandariza los desarrollos de software de sus más de 25 proveedores
- El proyecto se basa en los estándares CMMI e ITIL
La Ley 11/2007 de Acceso Electrónico de los Ciudadanos a los Servicios Públicos ha traído consigo una mayor carga para los departamentos de informática ligados de algún modo a la Administración Pública. Es el caso de la DGT, que ha visto cómo la práctica totalidad de los trámites que se venían realizando en las Jefaturas de Tráfico y apuesta por una línea estratégica para que a medio plazo se puedan llevar a cabo también por vía telemática.
Una práctica muy habitual dentro de la administración es colaborar con empresas externas a través de concursos públicos. En el caso de la DGT, más del 70% de los servicios son gestionados por la Dirección General, pero realizados por empresas colaboradoras. Esta situación puede derivar en dos inconvenientes: por un lado, una dependencia excesiva de los proveedores, y por otro lado, incertidumbre en cuanto a las garantías de idoneidad del software que se entrega, cuyas funcionalidades no se ven hasta su entrada en producción.
Este es el escenario en el que se movía la Gerencia de Informática de la DGT y al que hace unos tres años quiso poner solución su subdirector, Luis de Eusebio. Se creó entonces un área de calidad de software, a cuya dirección se encuentra Daniel Cabrero. Una labor nada sencilla considerando que sólo en 2009 hubo 150 proyectos de software vivos, llevados por hasta 25 empresas adjudicatarias con equipos nutridos por más de 350 personas.
En la actualidad, el Área de Calidad (compuesto por dep. de Auditorías, dep. de pruebas, departamento de arquitectura corporativa, dep procesos ITIL y dep CMMI-ACQ) se nutre de algo más de 30 personas. Cabrero puntualiza que “mediante todo este mecanismo se han gestionado más de 100 millones en los últimos 3 años, para no pillarnos las manos. Dado que la inversión ha sido inferior a los 5 millones, y que la duración de muchos desarrollos ha sido reducida a menos de la mitad, creemos que el Retorno de Inversión es altamente positivo. Esto sin contar las aplicaciones cuyos defectos de Calidad o rendimiento han sido corregidos a coste cero. Gracias a este sistema de Calidad han podido reconducirse desarrollos defectuosos por valor de varios millones”.
Proceso de implantación
Daniel Cabrero recuerda los inicios del proceso, “empezando con cosas tan simples como solucionar el hecho de que algunas empresas que trabajan con la Administración no tienen una manera estándar de liberar el trabajo y ponerlo en algún sitio para que la dirección general lo tenga localizado. Así que empezamos con algo tan básico como obligar a poner el software en nuestro sistema de control de versiones bajo una política de Gestión de Configuración (esto incluye herramientas, estructuras, nombres, formatos.. etc)”. Así, el modo en que se compilan y se despliegan las aplicaciones ya no depende de las empresas, sino de la propia DGT, lo que reduce considerablemente la dependencia del proveedor.
En este punto, el siguiente paso fue llegar a una arquitectura común, puesto que a las dificultades ya mencionadas se sumaban otros problemas, como una replicación de funcionalidades comunes muy elevada entre los desarrollos de los diferentes proveedores. Esta arquitectura cuenta con unos 20 componentes comunes que aíslan del entorno tecnológico y cerca de 10 servicios transversales que dan respuesta las necesidades de infraestructura y datos comunes. “Hemos optado por J2EE, con Oracle”, explica el experto, añadiendo que “para la parte de J2EE el departamento de arquitectura es el que lidera qué frameworks son los que se pueden usar o no, habiendo descartado tener uno propio para acceso a datos y, en su lugar, trabajamos con JPA, JSF o SPRING, que ya han probado su escalabilidad y usabilidad a largo plazo en el mercado”.
Paralelamente, uno de los puntos más importantes del área de Calidad viene dado por las auditorías, algo que no es muy común. De hecho, el 90% de los departamentos de calidad define normas, pero no revisa su cumplimiento. Cabrero indica que “a diferencia de cómo se trata la calidad en otras organizaciones, aquí las auditorías son vinculantes para el pago. Para pagar cualquiera de los desarrollos que tenemos hay que pasar auditorías con más de 300 puntos diferentes en cuanto a requisitos, rendimiento, análisis, diseño pruebas, etc. que han de pasar para que se efectúe el pago”.
Una vez estandarizado todo el proceso de Calidad, se precisa un sistema de indicadores para tener una visión del estado y diagnóstico de los proyectos de software. Esta información es muy valiosa, puesto que permite la generación de informes y, no sólo la posterior notificación sobre el estado de los proyecto, sino también la identificación de las mejores prácticas –y las peores- que vayan retroalimentando y mejorando las diferentes políticas de calidad.
El entorno de Pruebas
El departamento de pruebas juega un papel esencial en todo este entramado, puesto que resulta clave “para tener una manera objetiva de probar y asegurar que los desarrollos funcionan como deben y si, una vez que se ha finalizado el contrato, se debe pagar o no”. Para desarrollar este departamento, Gerencia de Informática llevó a cabo un estudio de mercado durante dos meses, llegando a la conclusión de que “las de HP eran las que más tiempo llevaban, las más estables y, desde luego, las que más se adaptaban a lo que queríamos hacer”, señala Cabrero. Entre otras de las opciones barajadas se encontraban Compuware y la suite de IBM de pruebas.
Estas herramientas de HP se relacionan directamente con la parte de procesos y con la arquitectura, “porque hay que probar los elementos de la arquitectura y luego sobre eso hacer agregados de prueba, etc.”. En definitiva, se trata de contar con una visión global de la calidad, para la que es importante disponer de una herramienta muy flexible y probada.
“El proyecto no llevó mucho, un estudio de un par de meses y lanzamos la compra; empezamos a trabajar con los primeros proyectos unos pocos meses después y las pruebas de rendimiento antes de un año ya estaban funcionando”, recuerda el jefe de Calidad.
Cabrero explica que “empezamos primeramente con la parte de rendimiento, para evitar que desarrollemos una aplicación entera y luego darnos cuenta que el rendimiento no nos vale. Un error de funcionalidad en la siguiente versión se puede arreglar, pero un error de rendimiento es muy posible que haya que rehacer la aplicación entera”.
Otros departamentos en la DGT trabajan también con diferentes proveedores. Cabrero apunta que una de las asignaturas pendientes del que se carece en la mayoría de las organizaciones es la interconexión enre herramientas que cubran pruebas, procesos, modelado y SOA. Tener una suite que lo cubriese sería maravilloso, pero la cruda realidad es que no existe. Este hecho hace que aun existiendo buenas soluciones para cada uno de los nichos, sea necesario hacer un esfuerzo adicional en la utilización de herramientas de distintos fabricantes. “En la parte de HP, creo que su herramienta es la que más se está usando en los sitios grandes".
El papel de los estándares
Los estándares por los que ha optado la DGT en este camin
- El proyecto se basa en los estándares CMMI e ITIL
La Ley 11/2007 de Acceso Electrónico de los Ciudadanos a los Servicios Públicos ha traído consigo una mayor carga para los departamentos de informática ligados de algún modo a la Administración Pública. Es el caso de la DGT, que ha visto cómo la práctica totalidad de los trámites que se venían realizando en las Jefaturas de Tráfico y apuesta por una línea estratégica para que a medio plazo se puedan llevar a cabo también por vía telemática.
Una práctica muy habitual dentro de la administración es colaborar con empresas externas a través de concursos públicos. En el caso de la DGT, más del 70% de los servicios son gestionados por la Dirección General, pero realizados por empresas colaboradoras. Esta situación puede derivar en dos inconvenientes: por un lado, una dependencia excesiva de los proveedores, y por otro lado, incertidumbre en cuanto a las garantías de idoneidad del software que se entrega, cuyas funcionalidades no se ven hasta su entrada en producción.
Este es el escenario en el que se movía la Gerencia de Informática de la DGT y al que hace unos tres años quiso poner solución su subdirector, Luis de Eusebio. Se creó entonces un área de calidad de software, a cuya dirección se encuentra Daniel Cabrero. Una labor nada sencilla considerando que sólo en 2009 hubo 150 proyectos de software vivos, llevados por hasta 25 empresas adjudicatarias con equipos nutridos por más de 350 personas.
En la actualidad, el Área de Calidad (compuesto por dep. de Auditorías, dep. de pruebas, departamento de arquitectura corporativa, dep procesos ITIL y dep CMMI-ACQ) se nutre de algo más de 30 personas. Cabrero puntualiza que “mediante todo este mecanismo se han gestionado más de 100 millones en los últimos 3 años, para no pillarnos las manos. Dado que la inversión ha sido inferior a los 5 millones, y que la duración de muchos desarrollos ha sido reducida a menos de la mitad, creemos que el Retorno de Inversión es altamente positivo. Esto sin contar las aplicaciones cuyos defectos de Calidad o rendimiento han sido corregidos a coste cero. Gracias a este sistema de Calidad han podido reconducirse desarrollos defectuosos por valor de varios millones”.
Proceso de implantación
Daniel Cabrero recuerda los inicios del proceso, “empezando con cosas tan simples como solucionar el hecho de que algunas empresas que trabajan con la Administración no tienen una manera estándar de liberar el trabajo y ponerlo en algún sitio para que la dirección general lo tenga localizado. Así que empezamos con algo tan básico como obligar a poner el software en nuestro sistema de control de versiones bajo una política de Gestión de Configuración (esto incluye herramientas, estructuras, nombres, formatos.. etc)”. Así, el modo en que se compilan y se despliegan las aplicaciones ya no depende de las empresas, sino de la propia DGT, lo que reduce considerablemente la dependencia del proveedor.
En este punto, el siguiente paso fue llegar a una arquitectura común, puesto que a las dificultades ya mencionadas se sumaban otros problemas, como una replicación de funcionalidades comunes muy elevada entre los desarrollos de los diferentes proveedores. Esta arquitectura cuenta con unos 20 componentes comunes que aíslan del entorno tecnológico y cerca de 10 servicios transversales que dan respuesta las necesidades de infraestructura y datos comunes. “Hemos optado por J2EE, con Oracle”, explica el experto, añadiendo que “para la parte de J2EE el departamento de arquitectura es el que lidera qué frameworks son los que se pueden usar o no, habiendo descartado tener uno propio para acceso a datos y, en su lugar, trabajamos con JPA, JSF o SPRING, que ya han probado su escalabilidad y usabilidad a largo plazo en el mercado”.
Paralelamente, uno de los puntos más importantes del área de Calidad viene dado por las auditorías, algo que no es muy común. De hecho, el 90% de los departamentos de calidad define normas, pero no revisa su cumplimiento. Cabrero indica que “a diferencia de cómo se trata la calidad en otras organizaciones, aquí las auditorías son vinculantes para el pago. Para pagar cualquiera de los desarrollos que tenemos hay que pasar auditorías con más de 300 puntos diferentes en cuanto a requisitos, rendimiento, análisis, diseño pruebas, etc. que han de pasar para que se efectúe el pago”.
Una vez estandarizado todo el proceso de Calidad, se precisa un sistema de indicadores para tener una visión del estado y diagnóstico de los proyectos de software. Esta información es muy valiosa, puesto que permite la generación de informes y, no sólo la posterior notificación sobre el estado de los proyecto, sino también la identificación de las mejores prácticas –y las peores- que vayan retroalimentando y mejorando las diferentes políticas de calidad.
El entorno de Pruebas
El departamento de pruebas juega un papel esencial en todo este entramado, puesto que resulta clave “para tener una manera objetiva de probar y asegurar que los desarrollos funcionan como deben y si, una vez que se ha finalizado el contrato, se debe pagar o no”. Para desarrollar este departamento, Gerencia de Informática llevó a cabo un estudio de mercado durante dos meses, llegando a la conclusión de que “las de HP eran las que más tiempo llevaban, las más estables y, desde luego, las que más se adaptaban a lo que queríamos hacer”, señala Cabrero. Entre otras de las opciones barajadas se encontraban Compuware y la suite de IBM de pruebas.
Estas herramientas de HP se relacionan directamente con la parte de procesos y con la arquitectura, “porque hay que probar los elementos de la arquitectura y luego sobre eso hacer agregados de prueba, etc.”. En definitiva, se trata de contar con una visión global de la calidad, para la que es importante disponer de una herramienta muy flexible y probada.
“El proyecto no llevó mucho, un estudio de un par de meses y lanzamos la compra; empezamos a trabajar con los primeros proyectos unos pocos meses después y las pruebas de rendimiento antes de un año ya estaban funcionando”, recuerda el jefe de Calidad.
Cabrero explica que “empezamos primeramente con la parte de rendimiento, para evitar que desarrollemos una aplicación entera y luego darnos cuenta que el rendimiento no nos vale. Un error de funcionalidad en la siguiente versión se puede arreglar, pero un error de rendimiento es muy posible que haya que rehacer la aplicación entera”.
Otros departamentos en la DGT trabajan también con diferentes proveedores. Cabrero apunta que una de las asignaturas pendientes del que se carece en la mayoría de las organizaciones es la interconexión enre herramientas que cubran pruebas, procesos, modelado y SOA. Tener una suite que lo cubriese sería maravilloso, pero la cruda realidad es que no existe. Este hecho hace que aun existiendo buenas soluciones para cada uno de los nichos, sea necesario hacer un esfuerzo adicional en la utilización de herramientas de distintos fabricantes. “En la parte de HP, creo que su herramienta es la que más se está usando en los sitios grandes".
El papel de los estándares
Los estándares por los que ha optado la DGT en este camin
