Pautas del IDA para la migración al Código Abierto

Transcripción

1 Pautas del IDA para la migración al Código Abierto netproject Ltd 124 Middleton Road Morden, Surrey SM4 6RW Tel: +44 (0) Fax: +44 (0) de octubre, 2003 European Communities 2003 Ref: OSPL/EEC Versión. 1.0 Página 1

2 Las opiniones expresadas en este documento son puramente las de los autores y no pueden, en ningunas circunstancias, ser interpretadas como confirmación de una posición oficial de la Comisión Europea. La Comisión Europea no garantiza la exactitud de la información incluida en este estudio, ni acepta cualquier responsabilidad del uso del mismo. Refiriéndose a cualquier producto específico, especificaciones, proceso, o servicio por el nombre comercial, marca registrada, fabricante, o de otra manera, no necesariamente constituye o implica su endoso, recomendación, o favor de la Comisión Europea. Los autores se han tomado todo el cuidado para asegurarse de que han obtenido, donde sea necesario, permiso para utilizar cualquier parte de los documentos incluyendo ilustraciones, mapas, y gráficos, en los cuales existen derechos de propiedad intelectual por parte del titular(s) de tales derechos o de su representante legal. Versión. 1.0 Página 2

3 0.1. Histotial del documento Fecha Versión Autor Cambios 11/02/03 0,1 S. Hnizdur Borrador Inicial 13/04/03 0,2 S. Hnizdur Reorganización y Adicionales 14/05/03 0,3 S. Hnizdur Reorganización y Adicionales 20/05/03 0,4 S. Hnizdur Preparación del Borrador para la reunión PMB 21/05/03 0,5 S. Hnizdur Inclusión de comentarios de la V0.4 31/05/03 0,6 S. Hnizdur Inclusión de comentarios de la V0.5 30/06/03 0,7 S. Hnizdur Inclusión de comentarios de la V0.6 y aplicaciones del servidor MS 16/07/03 0,8 S. Hnizdur Inclusión de comentarios de la V0.7 y Escenario Unix 17/07/03 0,9 S. Hnizdur Inclusión de comentarios de la V0.8 y aplicaciones del escritorio de Windows 10/08/03 0,91 S. Hnizdur Inclusión de comentarios de la V0.9 27/08/03 0,92 C.P.Briscoe-Smith Correciones e inclusiones de algunos comentarios de la V /09/03 0,93 C.P.Briscoe-Smith Correcciones. 08/09/03 0,94 C.P.Briscoe-Smith Posteriores correcciones e inclusión de comentarios 14/09/03 0,95 S. Hnizdur Reorganización posterior a la reunión PMB. 25/09/03 0,96 S. Hnizdur Correcciones. 07/10/03 0,97 S. Hnizdur Borrador Final 10/10/03 1 S. Hnizdur Edición de la versión Distribución netproject Ltd Frequentous Consultants Ltd Comisión Europea (para la difusión a las Administraciones miembras) x1 x2 x Términos de Marca Registrada Las marcas registradas se han utilizado en este documento únicamente para propósitos de identificación. Los autores reconocen la propiedad de estas marcas registradas Copyright Comunidades Europeas. Se autoriza la reproducción a condición de reconocer la fuente Índice 1. Prólogo 12 Versión. 1.0 Página 3

4 1.1 Abreviaturas y terminología Audiencia Autores Reconocimientos 13 PARTE 1 Introducción y Sumario 2. Introducción Sumario Metodología 18 PARTE 2 Pautas de dirección 5. Descripción de la Migración Asuntos Humanos Haciendo fácil la vida Introducción de nuevas aplicaciones en un entorno familiar Hacer las cosas fáciles primero Pensar a continuación 28 PARTE 3 Pautas Técnicas 8. Referencias de Arquitectura Arquitecturas Genéricas Referencia base de la Arquitectura Grupos Funcionales Grupos Principales Office Correo Calendarios y Groupware Accesos Web y servicios Manejo de documentos Base de Datos Los Grupos Subsidiarios Consideraciones Generales El modelo de referencia-sumario El Escritorio Office Correo Calendarios y Groupware 41 Versión. 1.0 Página 4

5 Acceso Web Control de documentos Bases de datos Los Servidores Correo Calendarios y Groupware Servicios Web Control de documentos Bases de datos Aplicaciones - Principales Grupos Office OpenOffice.org y StarOffice Koffice Gnome Office Correo MTA Bandeja de correo MUA Antivirus Otras Herramientas Problemas Conocidos Calendarios y Groupware Calendarios personales y agendas Calendarios Grupo Organización de reuniones Sincronización PDA Servicios Web Buscador Servicios Web Portal / Contenido Control de documentos Registro y recuperación Trabajo en grupo Bases de datos 56 Versión. 1.0 Página 5

6 Bases de datos centrales basadas en aplicaciones Bases de datos personales mantenidas centralizada o localmente Conectividad en bases de datos Funcionamiento Aplicaciones - Grupos Subsidiarios Sistema Operativo Interfaz de Usuario Controlador de Escritorio look and feel (mira y siente) Lenguaje Seguridad Encriptación de datos 60 Datos en proceso 60 Datos almacenados Autentificación Autorización Control de Virus Servidor Proxy Firewalls Virtual Private Networks o VPN (Red Privada Virtual) 61 OpenVPN 61 SWAN Libre 61 CIPE Control Control de usuarios Control de la Configuración 62 Mantenimiento de la Configuración Manual 62 Cfengine 63 Configurador del Sistema Control del Software 63 Instalación del Sistema 63 Mantenimiento del Software Control del Hardware y supervisión del sistema 67 MRTG y Snmpd 67 Nagios 68 Versión. 1.0 Página 6

7 smartd Control de la impresora 68 LPRng 68 Sistema de Impresión Unix común 68 Kprint y GnomePrint Copia de Seguridad y recuperación Volcado y recuperacion Amanda Otros Servicios Servidores de hora Infraestructura de servidores de red 70 Enrutado _ 70 DNS 70 DHCP Servidores de archivos 70 NFS 70 Samba 71 Netatalk 71 OpenAFS, CODA e Intermezzo Servicios de Directorio Soporte Legítimo 72 Emulación de terminal 72 Terminal remoto 72 Emulación Migración de aplicaciones Repaso Aplicaciones propietarias con un OSS equivalente Aplicaciones propietarias que se ejecutan en un entorno OSS Software accesible desde un terminal remoto Software que se ejecutará en un emulador Emulación del Hardware Emulación del Software Software recompilable en OSS Escenario 1 Windows Planificando la migración 78 Versión. 1.0 Página 7

8 14.2. Dominios Modelo Windows workgroup Dominio Windows NT Dominio del Active Directory de Windows Descripción de posibles rutas de migración Asuntos Generales Nombre de usuario y contraseñas 81 Nombre de usuario 82 Peculiaridades de las contraseñas Servicios de Autentificación Archivos 83 Contenido y formato 84 Nombres de Archivo 84 Acceso Dual Herramientas Samba OpenLDAP NSS y PAM Acceso a archivos mediante SMBFS GNU/Linux Winbind Migrando el entorno del sistema operativo Añadir servidores individuales GNU/Linux a dominios existentes Windows NT Ejecutar escritorios GNU/Linux en dominios Windows NT 89 Instalación simple para un pequeño número de máquinas 89 Instalaciones más elegantes para mayores complejos Ejecutar escritorios GNU/Linux en dominios Active Directory Reemplazar Windows NT PDC/BDC con Samba+LDAP Reemplazar Windows 2000 Active Directory con LDAP Usar infraestructuras paralelas GNU/Linux y migrar usuarios en grupos 94 Reemplazo de todos los clientes Windows con GNU/Linux 94 Mantener algunos clientes Windows Aplicaciones de migración del lado del servidor Servidores Web: pasar de IIS a Apache 96 Versión. 1.0 Página 8

9 Migración 96 Migrando una website estática 98 Una configuración WebDAV simple Pasar de Access y de SQLServer a MySQL o PostgresSQL 101 Migando bases de datos Access 102 Migrando bases de datos de SQL Server 103 Cuestiones sobre migración de bases de datos Groupware: pasando desde Exchange 104 Aspectos generales 104 Cuestiones sobre el correo 105 Cuestiones sobre la lista de direcciones 105 Cuestiones sobre el calendario Migrando aplicaciones de escritorio a OSS Office 106 Conversión de documentos 106 Conversión de Plantillas 106 Conversión de macros 106 Procesadores de texto 107 Publicación 107 Hojas de calculo 108 Presentaciones 108 Manipulación de gráficos e imágenes 108 Generación de PDF Correo Calendarios y Groupware 110 Calendarios 111 Administración de contactos Navegación web Bases de datos personales Migración de servicios de impresión a OSS El modelo de impresión de Windows El modelo de impresión Unix y GNU/Linux Instalación de un servicio de impresión basado en OSS Imprimir desde clientes de windows a impresoras unidas a GNU/Linux 115 Versión. 1.0 Página 9

10 Utilización del protocolo lpr 115 Utilización de impresoras compartidas 115 Utilización de la configuración Point and Print Esquemas de migración de la parte de impresión Problemas Potenciales Más información sobre impresión Aplicaciones Legítimas Protección contra virus Referencias Escenario 2 Unix Escenario 3 Mainframe Escenario 4 Cliente fino 123 Versión. 1.0 Página 10

11 Apéndices Apéndice A 125 Apéndice B 128 Apéndice C 134 Apéndice D 144 Apéndice E 152 Apéndice F 166 Apéndice G 174 Versión. 1.0 Página 11

12 1. Prólogo 1.1. Abreviaciones y Terminología Siempre que sea posible, la primera vez que se empleemos una abreviatura se incluirá también la versión ampliada. Un glosario de términos está proporcionado en el apéndice G. Cuando aparezca un término del glosario por primera vez se presentará en este estilo: Glosario. Los términos de Programas con Código Abierto (Open Source Software) y los de Software Libre (Free Software) tienen cada uno sus ventajas. En este informe utilizamos el Open Source Software o OSS para significar que el software descrito tiene las características implícitas en ambos, tanto en términos del Open Source Software y del software libre. Para obtener mas información sobre estos términos ver en y Los nombres de productos serán presentados con este estilo: Nombre del Producto (Product Name). Los términos del sistema operativo tales como nombres del archivo serán presentados en este estilo: Nombre de fichero (File Name). El código del programa será presentado en este estilo: Código (Code) Audiencia Este documento está planteado para directores de IT en administraciones públicas de Europa. El término Administración se utiliza siguiendo las pautas para significar a una administración pública europea y el término Administradores para significar a este grupo de gente Autores El informe ha sido producido por netproject Ltd conjuntamente con Frequentous Consultants Ltd. El contenido fue producido por un número de consultores entre los que se incluyen: - Steve Hnizdur - Keith Matthews - Eddie Bleasdale - Alain Williams - Andrew Findlay - Sean Atkinson - Charles Briscoe-Smith 1.4. Reconocimientos netproject quisiera agradecer la ayuda prestada a : - Agradecer a los muchos miembros del consejo del Project Management Borrad Versión. 1.0 Página 12

13 (Discusión sobre dirección de proyectos), en particular a netproject por las discusiones animadas e informativas de todos los meses mes. - Thomas Krupp y Heiko Thede (Mecklenburg-Vorpommern) - Frank M ller (Landesrechnungshof Mecklenburg-Vorpommern) - Mru Patel (Sun Microsystems) - Graham Taylor (Open Forum Europe) - Richard Heggs (Nottingham City Council) - Andy Lack (City University London) - David Amos (BSS Group) - Steven Pennant (London Borough of Newham) - Andy Trevor (Total Solutions) - Geoff Gunton (Northern Rock) Versión. 1.0 Página 13

14 PARTE 1 Introducción y Sumario Versión. 1.0 Página 14

15 2. Introducción El propósito de estas pautas es doble: 1. Ayudar a decidir a los Administradores si una migración a OSS debe ser emprendida. 2. Describir en amplios términos técnicos de cómo tal migración podría ser realizada. Las pautas están pensadas para ser de uso práctico para administradores, así que deben ser relevantes y exactas y a la vez accesibles y comprensibles. No son un manual de referencia técnico detallado. La estructura está pensada para permitir que se realizen cambios en el futuro a medida que las Administraciones van ganando experiencia y se producen cambios en los productos disponibles. Para alcanzar estos objetivos es imprescindible que el contenido este actualizado hasta la fecha y que cualquier error este eliminado. Con este fin, se anima a los lectores a hacers comentarios y a contribucir sobre cualquier parte de las pautas. Envíe por favor los comentarios a gposs@cec.eu.int. Las pautas ni tratan el OSS en general ni comentan los méritos de las diferentes licencias. Esto, junto con otra información, se puede encontrar en los siguientes documentos del IDA: 1. La hoja de hechos OSS: 2. El Informe de uso de OSS: 3. Informe sobre estructuras de mercado y asuntos relacionados con procedimientos públicos: (Los tres documentos se pueden encontrar en: nce&documentid=333/ y en otros formatos además de PDF.) La francesa Agence pour le Développement de l'administration Electroniqu, ADAE, ha producido una buena guía sobre licencias, también disponible en inglés en: 5&letype=0. Versión. 1.0 Página 15

16 3. Sumario Estas pautas son para directores de IT que están planeando o haciendo una migración a Open Source Software o OSS (Software de código abierto). Se basan en la experiencia práctica de los autores y del contenido de un número limitado de estudios disponibles públicamente. Han validado la migración a OSS contra la Junta de Auditores, Schwerin en Mecklenberg Vorpommern. Existen muchas razones para que las administraciones migren a OSS. Éstas incluyen: la necesidad abrir estándares para el e-gobierno; el nivel de la seguridad que OSS proporciona; la eliminación de cambios forzados; el coste del OSS. Todos estos beneficios hacen que los gastos en IT sean mucho más bajos. Las pautas recomiendan: - antes de comenzar tener una comprensión clara de las razones de emigrar; - asegúrese de que haya soporte activo para el cambio realizado por el personal y usuarios de IT; - cerciórese de que haya una referencia para el cambio - cuanto más arriba en la organización mejor; - acumule experiencia y relaciones con el movimiento OSS; - comience con los sistemas no críticos; - asegúrese de que cada paso en la migración sea factible. Migrar los sistemas IT proporciona una oportunidad para reformarse y así resolver las nuevas demandas puestas en ellos. Las preguntas que necesitan ser tratadas incluyen: - cómo asegurar la interoperabilidad de sistemas; - cómo dar soporte a usuarios de móviles; - cómo identificar con seguridad a usuarios remotos; - cómo construir los sistemas que sean manejables. Sobretodo cómo asegurarse de que la seguridad esté diseñada desde el comienzo y no dejarla para algo posterior. Para computación en servidores, OSS es comprensible y está extensivamente desarrollado. La migración de los servidores a OSS se pueden hacer generalmente sin tener efectos adversos en los usuarios. Es normalmente el primer lugar a comenzar. Desplegar OSS en el escritorio para la mayoría de las organizaciones ofrece los mayores ahorros de coste. Al migrar el escritorio las nuevas aplicaciones de OSS tendrán que interactuar con las aplicaciones ya existentes. Al reemplazar las plantillas del software, se debe comprobar que produzcan la salida correcta. Las macros necesitan ser reescritas preferiblemente como scripts. Las aplicaciones para las cuales no hay equivalentes de OSS se pueden ejecutar en thin client. Con el tiempo las aplicaciones de escritorio se pueden substituir por equivalentes de OSS. Versión. 1.0 Página 16

17 Aunque las pautas asumen un cambio completo a OSS lo más probable es que un entorno heterogéneo sea construido particularmente como una migración de millares de pc s de escritorio que llevará tiempo. La mezcla de OSS y aplicaciones propietarias son también posibles ya que las aplicaciones OSS para su reemplazo pueden no siempre estar disponibles o funcionales. Actualmente esto es particularmente cierto en el reemplazo de la función del groupware Microsoft Exchange. Sin embargo hay suficientes aplicaciones OSS de suficiente calidad para que se realize la migración. Es importante cerciorarse de que las decisiones ahora tomadas, aunque no se relacionen directamente con una migración, no deben atar posteriormente a una administración a los formatos de archivo y protocolos propietarios. OSS es una tecnología diferenciadora. Permite un cambio fundamental a la manera que las organizaciones proporcionan los servicios IT. Es un distanciamiento de una industria basada tanto en productos como en servicios. No es costoso instalar el software de OSS. El asunto es donde conseguir el soporte. Existe un número de terceras compañías de soporte así como los distribuidores. Sin embargo si su actitud respecto a IT es a quien acudo cuando las cosas van mal? entonces quizás OSS no es para usted. Es necesaria una comprensión de la dinámica de movimiento de OSS. Saber acudir a la comunidad OSS es recomendable. Versión. 1.0 Página 17

18 4. Metodología Cualquier ejercicio de migración debe constar en general de: 1. Una fase de recopilación de datos y definición del proyecto incluyendo: A. Una descripción del sistema de condiciones iniciales relevantes que consisten en, por ejemplo: a. arquitectura(s) de sistemas, b. aplicaciones y sus datos asociados, c. protocolos y estándares usados, d. hardware, e. el entorno físico, tal como el ancho de banda de la red, localización, f. los requisitos sociales tales como lenguaje(s) y conjunto de habilidades del personal; B. Un conjunto de condicionantes del objetivo al detalle, C. Una descripción de cómo llegar de las existentes a las condiciones previstas; 2. Una justificación para la migración incluyendo el coste asociado a ella, 3. Una o más fases piloto diseñadas para probar el plan y la justificación. Los datos de estos pilotos pueden ser entonces reutilizarse en el modelo de costes usado en el plan, 4. Salir del plan, 5. Comparar la experiencia real con el plan. El contenido del punto 1 arriba define algo llamado en estas pautas Escenario y las pautas describen cómo migrar a OSS en tales circunstancias. Sin embargo, para que las pautas sean legibles y útiles en la práctica tienen que asumirse algunas simplificaciones, si no el número total de combinaciones posibles llegaría a ser irrealizable. Hemos elegido uno de los muchos diversos entornos objetivo (1B arriba) y hemos simplificado la descripción de los entornos iniciales (1A arriba). El entorno objetivo se discute en la sección 8.2. Con este entorno objetivo estándar asumido, un escenario se define como referencia al entorno inicial simplificado y a la trayectoria de la migración de él al objetivo. Nuevos capítulos se pueden agregar a este documento cuando sea necesario en el futuro. Comenzando con el capítulo 14, cada capítulo proporciona una descripción razonablemente detallada de un escenario, describiendo cómo migrar al objetivo incluyendo el comentario de migraciones parciales. Cada capítulo se debe poner al día a medida según se gana experiencia en migraciones reales. Versión. 1.0 Página 18

19 Además, hay una hoja de cálculo asociada a ayudar con el punto 2 arriba. En esta hoja de cálculo, el coste de cada escenario se pueden comparar al coste del objetivo y el coste de migración. El detalle disponible en los estudios de casos públicos es muy limitado. Solamente se encontró un número pequeño de tales estudios (se da una lista en el apéndice A) que proporcionó cualquier detalle de todos con excepción de un lanzamiento de prensa general. Esto significa que la mayoría de las pautas están basadas en la experiencia del netproject y de sus consultores y sus discusiones con la gente que ha hecho una migración pero no ha publicado sus resultados. El enorme número de diversas combinaciones de condiciones iniciales y finales, junto con las muchas y diversas maneras de conseguir llegar de una a la otra, hace que sea imposible para un sistema de pautas cubrir todas las posibilidades. Las pautas deben por lo tanto ser consideradas como una indicación de lo que se puede hacer más que de lo que debe ser hecho. Deben ser utilizadas como un punto de partida en el proceso de la migración. No se debe esperar que proporcionen una respuesta en todas las circunstancias. La migración se asume para tener un objetivo, que es un entorno totalmente de OSS en lo posible, sin embargo, puede haber muchas razones para que los sistemas propietarios seanmantenidos o utilizarlos. La posibilidad de una migración parcial también se contempla. Versión. 1.0 Página 19

20 PARTE 2 Utilización de Pautas Versión. 1.0 Página 20

21 5. Descripción de la Migración Mucho de lo que se necesita para migrar de un entorno propietario a OSS es igual para cualquier migración - por ejemplo de Windows NT a Windows Incluso en tales movimientos del mismo vendedor, no puede ser asumido que los formatos de archivo, por ejemplo, sean manejables, y será necesaria la prueba conveniente antes de que se realice cualquier cambio extenso. Todas las migraciones se deben basar en un planteamiento cuidadoso. Estas pautas no están pensadas para ser un manual para el director del proyecto y se asume que la administración tiene suficientes recursos para poder manejar la migración correctamente. La descripción abajo está pensada para destacar los puntos que son salientes en una migración a OSS. El proceso de migración ideal debe consistir en las siguientes partes. Algunas de ellas se pueden hacer en paralelo como la 2, 3 y 4. Observe que la información encontrada puede indicar que sean requeridas modificaciones al entorno actual antes de que una migración a OSS pueda ser concebida. Esta es la razón por la cual incluso las administraciones que no tienen ningún plan inmediato para la migración, pero que desean mantener esta opción disponible, se les recomienda requerir solamente de estándares multi-vendedor abiertos y determinar su infraestructura en torno a esto (véase también el capítulo 7.3 debajo "pensar hacia delante"). 1. Cree un equipo con las habilidades apropiadas y preparación en dirección. Es importante que haya apoyo desde la dirección o de otra manera surgirá la resistencia a un movimiento lejos de la norma de sistemas de propietarios. Esta ayuda tendrá que ser la suficiente para permitir por lo menos la construcción de pilotos representativos, así que será necesario producir un caso básico de negocio quizás más detallado más adelante cuando estén más datos disponibles. 2. Entienda el entorno objetivo, el software de OSS y la arquitectura base (véase el capítulo 8), junto las dsitintas opciones y elecciones disponibles. Esto significa entrenar al personal existente, reclutando, o usando a consultores. Esto requerirá un cierto coste inicial y así que requiere el suficiente apoyo de la dirección. Hay a veces una expectativa de que el software que está libre puede ser entendido y utilizado sin coste. Éste no es el caso. 3. La migración es una oportunidad de repasar la arquitectura base así como el software de las aplicaciones. La arquitectura recomendada en el capítulo 8 es una basada en un control centralizado y tiene una serie de ventajas discutidas en el capítulo 8. Pueden haber implicaciones de coste al realizar este cambio que deben ser consideradas. 4. Es muy importante que se entienda OSS. Hay una serie de asuntos que necesitan ser considerados completamente antes de tomar cualesquier decisión. A. Se han de clarificar las implicaciones de las licencias de OSS, particularmente si la administración podría ser juzgada por distribuir cualquier cambios del software. Vea los documentos mencionados en la introducción para más detalles. Versión. 1.0 Página 21

22 B. Donde hay varias opciones para cualquier función, por ejemplo hay por lo menos tres hojas de cálculo OSS de calidad OSS disponibles, los administradores han de entender los pros y contras de cada producto. C. Las diferencias entre las varias distribuciones deben ser consideradas. Algunas distribuciones están apoyadas por compañías comerciales que proporcionan soporte y arreglos. Algunos tienen características distintas, por ejemplo Gentoo proporciona una distribución basada en el código fuente permitiendo a la administración modificar más fácilmente el software para sus propias necesidades específicas. Todas estas diferencias necesitan ser estudiadas antes de que se elija una opción. Los administradores deben determinar qué nivel de soporte se requiere. El Soporte comercial puede ser obtenido de los creadores de la aplicación y de la distribución en caso de ofrecerla. Si no, los terceros pueden proporcionar el soporte ya que el código fuente está disponible. Esto es la gran diferencia del mercado del software propietario, donde el soporte detallado puede ser proporcionado solamente por esas compañías privilegiadas que tengan el acceso al fuente. Esto es importante si el vendedor propietario deja el negocio sin lanzar el código fuente. Si todo esto falla, la mayoría de aplicaciones tienen listas de correo activas envían preguntas o peticiones de ayuda, las cuales serán contestadas por alguien con interés en esa aplicación. La presencia de una comunidad de usuarios y de una lista de correo activa es, a menudo, uno de los primeros criterios en la selección de componentes software. 5. Audite los sistemas existentes. Estos datos no serán sólo necesarios para hacer la migración, además también serán necesarios para construir un coste del modelo del propietario para un caso detallado del negocio. Obtenga inventarios de: A. Para cada aplicación usada: a. El nombre de la aplicación, el número de versión y el punto de contacto para contestar a consultas. b. Cuántos usuarios requieren acceso a él. c. Que sistema operativo se esta utilizando. Bajo qué sistemas operativos puede la aplicación funcionar, incluyendo entornos tales como Citrix. d. Qué otras aplicaciones se requieren, tanto en el cliente como en el servidor, para que la aplicación pueda funcionar. e. Que hardware se requiere. Necesita un hardware no estándar o último modelo. f. Qué protocolos utiliza para comunicarse con otras aplicaciones. g. Qué formatos del archivo requiere. h. Cual es su internacionalización y localización. Pueden requerirse multiples Versión. 1.0 Página 22

23 lenguajes y concurrencias. B. Requisitos de los datos. Esto se debe interpretar en el sentido amplio que incluye, por ejemplo, documentos de procesamiento de textos y hojas de cálculo, los datos de sonido/voz y los datos visuales así como las bases de datos regulares. En general, cualquier cosa pensada para ser procesada por una computadora. a. Cuáles son las restricciones en la interconexión con sistemas o usuarios externos a la dirección de la administración? b. Qué requisitos hay para guardar datos y poder procesarlos en un futuro? Hay un depósito de datos heredados que tiene que ser soportados? Si es así, requiere aplicaciones específicas para procesarlo? i. Divida los datos en las categorías siguientes: ii.los datos que es necesario guardarlos y se pueden tirar. Tirelos. iii. Los datos que se deben guardar y están actualmente en un formato abierto tal como pdf o Postscript, o fácilmente traducible a uno. El coste de la traducción ha de estar determinado. iv. Los datos que deben ser guardados pero que están en un formato cerrado de propietario, y que no se pueden traducir fácilmente a uno abierto. Estos datos pueden necesitar copias de la aplicación específica de propietario para ser guardados. El coste de estas aplicaciones deberá asumirse. El número requerido de copias de la aplicación se puede determinar por el grado datos que son necesarios. Por ejemplo, si los datos son raramente usados una sola copia en una máquina central puede ser suficiente. Puede también ser necesario mantener hardware específico para ejecutar dichas aplicaciones. C. Requisitos de seguridad a. Cuál es el sistema actual para asignar nombres y contraseñas al usuario? Los nombres del usuario tienen una estructura y si es así cuál es? Cuál es la política para las actualizaciones de la contraseña? b. Existen sistemas que requieran la autentificación en vez de una petición simple de nombre y contraseña del usuario? c. Qué políticas administrativas y de gobierno hay referente al uso de computadoras? Por ejemplo, hay restricciones en el uso de Internet y del ? d. Existen las modificaciones de seguridad que requieren el uso de hardware o software específico? 6. Haga un caso detallado del negocio para la migración. Estará basado en los datos recopilados arriba y consistirá en varias secciones incluyendo: A. El coste del entorno existente durante un periodo de tiempo razonable, como 5 Versión. 1.0 Página 23

24 años con las medidas apropiadas a la administración. B. El coste de entornos alternativos y el coste de migración a cada uno de ellos en el mismo período. C. Las fuerzas y las debilidades del entorno actual y las alternativas. La hoja de cálculo asociada ayudará a hacer la comparación de costes. 7. Consulte con los usuarios. Explique el razonamiento dentro de la migración y los efectos que tendrá en ellos. Tome sus preocupaciones seriamente y permita que jueguen con la tecnología cuanto antes. Cuanto antes se impliquen los usuarios mejor. Esto puede ser un requisito legal en algunos países pero se debe hacer en cualquier caso para facilitar la introducción de lo que pueda ser un cambio significativo en las prácticas de funcionamiento. Cree un puesto de información que pueda contestar a cuestiones del usuario.. Cree una intranet con los trucos y una sección de como-hacerlo, que puedan poner al día los propios usuarios. Es importante que los usuarios se sientan incluidos y el site también dará al que ayuda información de la clase de problemas que tienen los usuarios. 8. Asumiendo que se ha hecho el caso del negocio, comience con proyectos experimentales a pequeña escala, preferiblemente en un entorno autónomo con un pequeño número de usuarios. Esto proporcionará, entre otras cosas: A. Datos para más precisos modelos de coste de la propiedad. B. La reacción del usuario que se podrá utilizar para facilitar la introducción de otros sistemas. C. Validación o modificación de la arquitectura objetivo y del caso del negocio. 9.Decida la velocidad del proceso de migración una vez comenzada. Las opciones principales son: A. Big Bang: Todos los usuarios se cambian del viejo sistema al nuevo el mismo día. Esto es en la práctica significa programar el cambio para una fecha de fin de semana o día de fiesta nacional. La ventaja es que no son necesarias provisiones de acceso dual y el personal no se encuentra yendo y viniendo de un sistema a otro. Las desventajas incluyen el alto riesgo y los grandes requisitos de recursos durante el cambio. Este esquema de migración es solamente probable para llevar a cabo en las administraciones pequeñas. En cualquier caso, en todo lo posible EVITE LA MIGRACIÓN BIG BANG. Las migraciones Big Bang tienen tantas variables a controlar que fallan casi siempre. Si lo hacen así es poco probable que sea debido a una fallo de OSS sino de la dirección. B. Transición en grupos por fases: Mueven a los usuarios del viejo sistema al nuevo en grupos. Es probable que muevan a los grupos funcionales completos juntos, para reducir al mínimo el compartir datos y para agrupar problemas de trabajo. Los riesgos pueden ser controlados y los recursos manejados eligiendo tamaños apropiados del grupo. Se puede hacer un reemplazo de hardware en abundancia de los PC de sobremesa al mismo tiempo, mejorando las máquinas quitadas de un grupo Versión. 1.0 Página 24