PDF de programación - Un modelo de plan estratégico para Migrar al Software Libre

GNU/LinuX

““Un modelo de
Un modelo de
plan estratégico para
plan estratégico para
Migrar al Software Libre”
Migrar al Software Libre”

… … Socialmente Justo,
Socialmente Justo,
Tecnológicamente Sustentable y
Tecnológicamente Sustentable y

Económicamente Viable …
Económicamente Viable …


www.somoslibres.org
www.somoslibres.org
Grupo de Usuarios de Software Libre Perú
Grupo de Usuarios de Software Libre Perú

Ms.C. Daniel Alejandro Yucra Sotomayor
Ms.C. Daniel Alejandro Yucra Sotomayor

[email protected]
[email protected]

Latinoware 2008
Foz do Iguazu Brasil

GNU/LinuX

Contenido Temático
Z I. Fundamentos Básicos
Z II. Proceso de Migración
Z III. Metodología

I. Fundamentos Básicos

Antecedentes
Antecedentes

Algunas Preguntas respecto al

tema:

¿ Cuál es impacto sobre el proceso de
migración de algunos sistemas a la
alternativa libre?

¿ Existe un modelo estratégico para

migrar al software libre?

¿ Cuál es la función y responsabilidad

política del estado para adoptar y
migrar al software libre?

I. Fundamentos Básicos

1.1 Introducción
1.1 Introducción

Más Preguntas:
¿Por qué debemos hacer una estrategia para
migrar al software libre y quienes deben ser
los protagonistas?

¿ Conoce las amenazas, fortaleza, riegos,

debilidades y oportunidades que se tiene al
migrar al software libre?

¿Por qué el sector publico y de gobierno

deben migrar al software libre?
El Software Libre en los gobiernos representa
independencia, ecnológica , seguridad, sostenibilidad y
desarrollo de un país.
Economicamente viable, tecnologicamente sustentable y

socialmente justo

I. Fundamentos Básicos

1.2 Propósito
1.2 Propósito

Z Ayudar a los Administradores a

decidir si se debe emprender
una migración a alternativas
como el Software Libre.

Z Describir en lenguaje técnico

como deben aplicar modelo de
migración al Software Libre.

I. Fundamentos Básicos

1.3. Justificación
1.3. Justificación

La importancia de aplicar un modelo estratégico

al software libre se sustenta por:

- Analizar sus Fortalezas, Oportunidades,

Amenazas y Debilidades,

- Necesidad de utilizar normas abiertas para la

administración electrónica,

- Nivel de seguridad que proporciona el

modelo del Software Libre,

- La eliminación de migraciones

forzadas y el coste que puede incurrir en
migrar.

1.4. Problemas Principales
Problemas Principales
1.4.

I. Fundamentos Básicos

Z Desconocimiento
Z Modelos propios
Z Equivalencias
Z Tiempos
Z Costos
Z Capacitación
Z Adaptabilidad


II. Proceso de Migración

2.1 Porqué Migrar?
2.1 Porqué Migrar?

Z Con o Sin ley debemos de migrar
Z Costo de Licencias de Software No Libre
Z Presupuesto ajustados por el Gobierno
Z Por que ser libre no tiene precio
Z Independencia Tecnológica

II. Proceso de Migración

2.2 Cómo Migrar ?
2.2 Cómo Migrar ?

Z Definir una metodología
Z Debe existir interés y voluntad política para

hacerlo

Z Dejar el miedo y las excusas de lado
Z Fomentar los grupos, comités y talleres de

migración en equipo.

Z Aprender a Desaprender

2.3 Quienes estan involucrados?
2.3 Quienes estan involucrados?

II. Proceso de Migración

Z Software, Hardware y Comunicaciones
Z Usuarios, Desarrolladores, Gerentes de TI.
Z Política de la institución o del Estado

2.4 Migración: Visión General
2.4 Migración: Visión General

II. Proceso de Migración

Premisas:
Z Migrar desde un entorno No Libre a un entorno

Software Libre es en gran medida similar a cualquier
otra migración

Z Toda migración deben basarse en una cuidadosa

Z Toda migración debe pasar las pruebas de

planificación.

funcionamiento

II. Proceso de Migración

2.5 Aspectos a considerar
2.5 Aspectos a considerar

1. Crear un equipo con la capacitación y el respaldo de

gestión adecuados. (Ejem. Apoyo de gestión de lo
contrario habrá resistencia a un cambio)

2. Entender el entorno final, tanto el software libre como
la arquitectura básica, junto con las diferentes opciones
y posibilidades disponibles.( Ejem. Formar al personal,
contratar personal o recurrir a consultores)

3. La migración es una oportunidad de revisar la

arquitectura de base así como el software de
aplicaciones. (Ejem. Puede Haber ciertos costes al
hacer el cambio, y hay que tenerlos en cuenta.)
4. Tener claro cuáles son las implicaciones de las

licencias para el Software Libre especialmente si se
considera que la Administración va a distribuir los
cambios de software.

II. Proceso de Migración

2.5 Aspectos a considerar
2.5 Aspectos a considerar

5. Tener en cuenta las diferencias entre las distintas

distribuciones, de acuerdo a evaluación y desarrollo.

6. Los GTI deben determinar qué nivel de apoyo es

necesario.

7. Estudiar los sistemas existentes. Estos datos no solo
serán necesarios para hacer la migración en sí, sino que
muchos de ellos serán también muy necesarios para
construir un modelo de coste total de propiedad para
un caso concreto de negocio.

8. Analizar la seguridad de los sistemas existentes
9. Elaborar un caso detallado de migración, que se basará

en los datos recogidos

II. Proceso de Migración

2.5 Aspectos a considerar
2.5 Aspectos a considerar

10. Consultar a los usuarios. Explicar las razones que hay
detrás de la migración y cómo les afectará. Estudie sus
preocupaciones con seriedad y permítales que
practiquen con la tecnología sin pérdida de tiempo.
Cuanto antes se impliquen los usuarios mejor será.

11. Comenzar con proyectos piloto a pequeña escala, de

preferencia en un entorno auto-contenido con pocos
usuarios.

12. Decidir sobre la velocidad del proceso de migración

una vez iniciado.

13. Supervisar la respuesta de los usuarios y tomar nota

de los problemas que surjan.

3.1 Consideraciones de la Metodología
3.1 Consideraciones de la Metodología

III. Metodología

Z Cuando se posea una metodología seria y

reponsable. Los éxitos de una migración depende
fundamentalmente de como se planifican las
tareas, definiendo objetivos, metas, conociendo el
recurso humano, reglamentos, etc

Z Las metodologías difieren en lo general de donde

se aplican.

Z Se debe considerar al menos: Diagnóstico,

Ejecución y Control

3.2 FODA Software Libre
3.2 FODA Software Libre

III. Metodología

Fortalezas:
- Herramientas y sistemas operativos libre de licencias costosas
- Disponibilidad de herramientas para varias áreas, sectores y

Soluciones maduras.

- Varias interfaces Gráficas (GUI).
- Paquetes de ofimática completa.
- Herramientas para desarrollo en Internet casi Maduras
- Interés Mayor en: Gobierno, Industria, Empresas, Pymes, Salud,

Educación quieren Software Libre.

- Estabilidad y Fiabilidad
- Rápida Solución de Incidencias
- Cobertura por comunidades como (SomosLibres.org)

3.2 FODA Software Libre
3.2 FODA Software Libre

III. Metodología

Oportunidades:
- Modelo para promover estándares en el gobierno.
- Modelo para Desarrollo de Aplicaciones a medida,

adoptado a su medida.

- Modelo para promover aplicaciones para sectores

del gobierno, educación, Ciencia y Tecnología.

- Capaz de adaptarse para cualquier solución

informática.

- Promueve innovación, investigación y desarrollo

alrededor del software libre

3.2 FODA Software Libre
3.2 FODA Software Libre

III. Metodología

Debilidades:
- Curva de aprendizaje
- Ausencia de un canal comercial
- Escasez de aplicaciones verticales
- Arquitectura inadecuada
- Falta de Programadores de Software Libre en el Peru
- Carencia de Aplicaciones y Modelos Peruanos propios
- Falta de difusión, promoción de su uso y desarrollo.
- Desinterés del Gobierno y Autoridades del País

3.2 FODA Software Libre
3.2 FODA Software Libre

III. Metodología

Amenazas:
- Carencia de sustitutos libres en algunas aplicaciones más usadas.
- Carancia de homologación (control de calidad).
- Falta de estandarización: No es trivial intercambiar una aplicación

libre por otra equivalente (también libre).

- Los proyectos de software Libre son gestionados por

programadores.

- Los programadores se mueren por escribir su propia

implementación desde cero.

- Los programadores se olvidan con facilidad de la ética del
servicio: trabajan para sí mismos y no para el usuario final.
- Falta promocionar los productos de software libre peruano.

III. Metodología
3.3 Un buen modelo de Migración
3.3 Un buen modelo de Migración

Z 1. Una fase de definición del proyecto y de recopilación

de datos

Z 2. Una justificación de la migración, incluido el coste

asociado a la misma

Z 3. Una o más fases piloto preparadas para probar si el

plan y la justificación funcionan.

Z 4. Despliegue del plan
Z 5. Seguimiento de la experiencia real en relación con el

plan.

3.4 Etapas Fundamentales
3.4 Etapas Fundamentales

III. Metodología

Z Diagnostico
Z Ejecución
- Capacitación
- Pruebas
- Instalaciones
- Migración
Z Control
Z Validación

III. Metodología

3.5 Diagnostico
3.5 Diagnostico

Z Establecer un cronograma de trabajo.
- Fijar Metas a corto, mediano y largo plazo.
Z Definir las áreas a Migrar.
- Esto es importante para buscar aliados líderes en cada área

manteniendo así el sentido de pertinencia.

Z Conocer: (Cuantificar)
- Sistemas Propietarios utilizados.
- Aplicaciones de oficina.
- Aplicaciones de Ingeniería.
- Niveles de adiestramiento del personal involucrado.
- Características de tecnología de los equipos existentes.
- Centros de impresión.


III. Metodología

3.5 Diagnostico
3.5 Diagnostico
Z Busqueda de Software Sustituto bajo GPL.
- Análisis de requerimientos de hardware.
- Verificar si estos pueden usarse con el hardware
disponible. Proponer repotenciación si es el caso.

- Verificar si los datos del sistema propietario pueden ser

exportados al menos a los formatos estándar txt, csv,
dxf,