Explicación del camino que ha recorrido la Diputación Foral de Bizkaia en cuanto a la adopción de software de fuentes abiertas en sus sistemas de información, desde que en 2003 las Juntas Generales instaron al gobierno foral “a priorizar la industria y el uso de programas informáticos basados en software libre sobre aquellos que requieran el pago de licencias” hasta la actualidad. Autor: Valentín Garcia Souto (Jefe del Departamento de Desarrollo e Innovación. Lantik. Diputación Foral de Bizkaia). Librecon.io

1. Momentos de Transformación. Construyendo una Nueva Realidad.
Valentin Garcia Souto
Ongi Etorri
Bienvenidos
Benvidos
Benvinguts
Jefe de Departamento de Desarrollo e Innovación
Lantik, Bizkaiko Foru Aldundia – Diputación Foral de Bizkaia

2. Ayuntamientos

3. Infraestructura

4. Or i g e n
El 30 de octubre de 2003, el Pleno de las Juntas
Generales de Bizkaia aprobó una Proposición No de
Norma que incluía el siguiente párrafo:
“Las Juntas Generales instan al gobierno foral a
priorizar la industria y el uso de programas
informáticos y sistemas operativos basados en
software libre sobre aquellos que requieran el
pago de licencias.”

5. SW d e f u e ntes abiertas vs SW propietario
SUSCRIPCIÓN
Incluye:
- Certificación
- Software compilado
- Mantenimiento
- Soporte
SOFTWARE
FUENTES
ABIERTAS
LICENCIA
+
MANTENIMIENTO
+
SOPORTE
SOFTWARE
PROPIETARIO

6. Al g u n o s h itos relevantes
• 2005 Prueba piloto de OpenOffice
Con la participación en el piloto de todos los departamentos
de Lantik.
• 2008 Acuerdo de colaboración Lantik-BFA y ESLE
“Están interesadas en colaborar para promover acciones
conjuntas, para contribuir al fomento y desarrollo de la
Sociedad de la Información en el ámbito de sus respectivas
funciones, y con la misión de que no se produzca
discriminación de cara a la ciudadanía por su elección
tecnológica.”
• 2010 Programa de Ayuda (Modelos 110-111)
Correspondientes al ejercicio fiscal 2010.
• 2012 Despliegue de Red Hat Linux en servidores:
EL uso de Linux en servidores comienza en 2002, con la
instalación de Linux Centos V 4.8 en el servidor de Call
Center WebCall, pero es en 2012 cuando se inicia el
despliegue de Red Hat Enterprise Linux x64 en proyectos
estratégicos.

7. Pe r i o d o 2 012 – 2014 (Tres entornos y dos CPD)

8. Migración I
SPRINT (DATOS)
Nº  Número de Sprint (1 a 22).
APLI  Número de aplicaciones por cada Sprint.
INICIO - FIN  Fecha de inicio y fin de cada Sprint.
ENTREGA DOC  Entrega de documentación y fuentes.
ENTREGA  Entrega del código fuente migrado.

9. Migración II
APLICACIÓN
APLI  Nombre interno de la Aplicación.
Entorno Pruebas  Si se puede probar en el entorno de pruebas.
Código fuente  Igualdad entre los entornos DESA y PRO del código fuente de la aplicación.
ClearCase  Estado de la aplicación en ClearCase (bloqueado o no bloqueado).
Horas resp-R  Numero de horas que emplea el responsable de la aplicación.
Horas emp-R  Número de horas que emplea la empresa encargada.
Empresa  Nombre de la empresa encargada de migrar la aplicación.
Horas resp-G  Horas planificadas para el responsable de Lantik.
Horas emp-L  Horas estimadas por Lantik que realizará la empresa.
Horas emp-P Horas que estima Lantik que la empresa destinará.
Horas realizadas  Horas realizadas por la empresa.
Criticidad  Criticidad de la aplicación a migrar (Alto, Bajo, Medio, Standby).
Porcentaje  Esfuerzo estimado para migrar la aplicación (En porcentaje).
Horas  Horas de esfuerzo estimadas por Lantik para la migración.
NO INICIO - NO FIN  Periodos en los que no se puede migrar la aplicación.
SIN TOCAR  Tiempo que puede estar la aplicación sin actualizar datos.
EQUIPO – RESPONSABLE  Nombre del responsable en Lantik de la aplicación y equipo al que pertenece.
DISPONIBILIDAD RESP - DISPONIBILIDAD EMP - VACACIONES VERANO - VACACIONES OTROS - SUSTITUTO -
VACACIONES  Previsiones de disponibilidad y vacaciones de las personas implicadas en la migración.

10. Migración III
DESA
Pruebas
INICIO – FIN  Fecha de inicio y fin de la etapa DESA (puesta en desarrollo)
Incidencias
Nº inc  Número de incidencias registradas durante la etapa
ENVIO  Fechas de envío de las incidencias
RESPUESTA  Fechas de respuestas a las incidencias
VB LANTIK  Visto bueno para pasar a la siguiente fase

11. Migración IV
PRO
Pruebas
DESPLIEGUE JBOSS(INICIO-FIN)  Fecha de despliegue en entorno jBoss.
Redirección  Fecha de redirección la aplicación.
Incidencias
COD  Código de incidencia.
ENVIO  Fecha de envío a RedHat de la incidencia.
RESPUESTA  Fecha de respuesta a la incidencia.
VB LANTIK  Visto bueno por parte de Lantik a la aplicación en el entorno.

12. Migración V
DEPENDENCIAS
Orden de migración de las aplicaciones, si una incidencia posee dependencias con otra aplicación
se deberá migrar antes que la otra.
DEPENDENCIAS CLASSES
CLASS1 CLASS2 CLSS3 CLASS4 CLASS5 CLASS6
DEPENDENCIAS WS
WS1WS2
DEPENDENCIAS EJB
EJB1 EJB2 EJB3 EJB4 EJB5 EJB6
DEPENDENCIAS DE CLASE
Contiene_EJB Llama_EJB Contiene_WS Llama_WS

13. Resumen ejecutivo

14. Eskerrik Asko
Muchas Gracias
Moltes Gràcies
Moitas Grazas
valentin.garcia@bizkaia.net