Desarrollo de requisitos generales para la migración de datos
Como parte del desarrollo de los requisitos generales de migración de datos, el analista empresarial debe definir una estrategia de migración de datos. Según las necesidades del negocio, se debe seleccionar el modo de operación de la organización del cliente, la migración del "big bang" o la migración suave.
Al elegir una estrategia de "gran explosión", se debe determinar el tiempo que la empresa puede dedicar al tiempo de inactividad durante la migración de datos. Después de determinar la cantidad de tiempo que una empresa puede pasar inactiva durante una migración de datos, se puede elaborar un cronograma de migración de datos. Al programar una migración de datos, se debe reservar un día o días libres para volver a migrar en caso de errores graves.
Al elegir una estrategia de migración fluida, todos los usuarios comerciales del sistema de destino deben dividirse en grupos para los cuales se debe elaborar un cronograma de cambio para trabajar con el sistema de destino. Después de dividir a los usuarios comerciales en grupos, se deben definir sus correspondientes conjuntos de datos y entidades. Al distribuir usuarios comerciales en grupos, las relaciones de estos grupos deben tenerse en cuenta dentro del proceso comercial que se automatiza en el sistema de destino.
Paralelamente a la elección de una estrategia para realizar la migración de datos, la gestión del proyecto y/o el analista comercial deben identificar los riesgos típicos de la migración de datos. Para cada riesgo identificado, se debe seleccionar una estrategia de gestión de riesgos (métodos) y desarrollar un conjunto de medidas de prevención de riesgos. La estrategia de prevención de riesgos puede ser una de las siguientes:
La Tabla 1 proporciona una matriz de riesgos típicos de migración de datos y cómo lidiar con cada uno de estos riesgos. Las celdas de la matriz proporcionan ejemplos de actividades para tratar cada uno de los riesgos dentro de cada método de prevención de riesgos.
Al compilar la tabla, se asumió que la estrategia de "Rechazo" no es aceptable para el equipo del proyecto, ya que el requisito previo para el estudio es la necesidad de realizar un trabajo de migración. Por lo tanto, no hay posibilidad de exclusión total o parcial de dichas obras del alcance del proyecto.
Tabla 1 Matriz de riesgos y posibles estrategias para enfrentar los riesgos de la fase de migración
|
Estrategia de gestión de riesgos |
rechazar |
Transmisión |
Adopción |
|
|
Riesgos de la elaboración de una especificación técnica |
Elaboración de requisitos de migración junto con el negocio, dueños y consumidores de los datos migrados |
Participación de consultores en la elaboración de especificaciones técnicas |
Formación de una reserva de presupuesto y tiempo en el proyecto para trabajar con posibles solicitudes de cambio. |
|
|
Riesgos de prueba |
Desarrollo de planes de prueba y escenarios que involucren a usuarios comerciales |
Transferir un paquete de prueba a un equipo separado con condiciones predeterminadas para aceptar sus resultados |
Formación de una reserva de tiempo y presupuesto para potenciales trabajo adicional debido a pruebas incompletas del software de migración y los datos alojados |
|
|
Riesgos en el proceso de obtención y carga de datos |
Elaboración de requisitos para prueba de descarga. Realización de una migración de "prueba" mediante una carga de prueba |
Formación de una reserva de presupuesto y tiempo para recepción repetida de descargas y descargas iterativas |
||
|
Estrategia de gestión de riesgos |
rechazar |
Transmisión |
Adopción |
|
|
Riesgos asociados con el trabajo del equipo del proyecto |
||||
|
Riesgos de colocar datos en el sistema de destino |
Desarrollo paralelo de los modelos de datos "tal cual" y "to be" para nivelar las diferencias en formatos y métodos de trabajo con datos en el origen y el destino |
Formación de una reserva de tiempo y presupuesto para mejoras en la funcionalidad del sistema receptor. |
Organización de la planificación de la migración de datos
La entrada para el desarrollo de planes de trabajo de migración es la estrategia de migración de datos formulada como parte del desarrollo de los requisitos generales de migración de datos.
El resultado de la planificación del trabajo de migración de datos debe ser un conjunto de artefactos de diseño que registren la secuencia de pasos para implementar la migración de datos. Los resultados de la fase de planificación son los siguientes artefactos del proyecto: el plan de trabajo de migración y el plan de comunicaciones para la fase de migración de datos.
El plan de trabajo de migración define un conjunto de tareas y los responsables de su implementación, distribuidos utilizando la matriz RACI. El plan de trabajo del proyecto para la migración debe contener tareas y paquetes de trabajo para cada una de las etapas de la migración: desde la etapa de trabajo preparatoria hasta la posterior a la migración. Teniendo en cuenta los resultados del análisis de la experiencia del proyecto, la WBS se desarrolló para evitar riesgos y corresponder a los enfoques teóricos de "referencia" para la organización de la migración de datos.
Se muestra en la figura. 3 estructura de trabajo cubre todas las etapas de la migración y se puede rastrear a las líneas del plan de trabajo del proyecto. Como parte del plan de trabajo del proyecto, se deben indicar los plazos para la implementación de cada tarea y los resultados de cada tarea. Al elaborar un plan de trabajo para cada tarea, se debe definir una condición, cuyo cumplimiento determinará sin ambigüedades que la tarea se complete.
Un artefacto de diseño igualmente importante de la fase de migración de datos es el plan de comunicaciones. El plan de comunicación en la etapa de migración define los objetivos y los tipos de interacción entre los miembros del equipo del proyecto, así como entre los miembros del equipo del proyecto y los empleados del cliente: usuarios comerciales.
El diseño del plan de comunicación dentro de la fase de migración debe basarse en el plan de trabajo elaborado anteriormente. Para cada tarea dentro del plan del proyecto, se deben definir los siguientes atributos:
¿Quién debe participar en la comunicación? ¿Qué son los grupos de roles?
En la Tabla 2 a continuación (Tabla 2) se muestra una plantilla para un plan de comunicaciones para la fase de migración de datos.
Tabla 2 Plantilla de plan de comunicación para la fase de migración de datos
|
Tema de comunicación |
indica el problema principal o tarea para la cual es necesaria esta comunicación, la sección de requisitos de migración, objetos de datos |
|
Miembros del equipo del proyecto |
se indican grupos de roles y roles |
|
La necesidad de interactuar con los negocios. |
etiquetado sí o no |
|
Participantes del lado comercial |
se indica la unidad funcional y el empleado responsable |
|
Tipo de interacción |
se indica el tipo de interacción, por ejemplo: escrita, reunión, taller |
Desarrollar y documentar los requisitos comerciales para la migración de datos.
El desarrollo y la documentación de los requisitos de migración de datos deben llevarse a cabo en varias etapas. Como parte de la metodología que se está desarrollando, la etapa de desarrollo de requisitos comerciales para la migración de datos también incluirá el paso de realizar y documentar los resultados de una encuesta de la organización del cliente. El propósito de la fase de desarrollo de los requisitos comerciales para la migración de datos es desarrollar paquete completo requisitos de software especializado para la migración de datos, así como para la composición de los datos migrados al sistema de destino.
1. Inspección del sistema de información operado
La inspección del sistema de información operativo cronológicamente debe ser la primera etapa de trabajo en el desarrollo de requisitos para la migración de datos.
El examen del sistema de información existente como parte del desarrollo de los requisitos de migración de datos puede llevarse a cabo como parte de la encuesta empresarial de todo el proyecto de implementación de PI. La encuesta, como parte del desarrollo de los requisitos de migración de datos, debe tener como objetivo crear un modelo de datos "tal cual". El modelo de datos "tal cual" permitirá preparar los requisitos para la composición de los datos que se migrarán desde el sistema de origen al de destino. sistema.
El modelo de datos 'tal cual' describe todos los objetos de datos que se utilizan en el sistema operativo. Después de compilar dicho modelo, será más fácil para el cliente seleccionar una lista de objetos de datos para transferir al sistema receptor. En tal modelo , se deben indicar los nombres de las entidades, y se debe describir su composición de atributos y relaciones entre entidades, indicando su cardinalidad.
Además del modelo de datos del sistema operativo, la fase de encuesta debe elaborar diagramas de procesos comerciales que utilicen los objetos de datos seleccionados para transferirlos al sistema de destino. Los modelos de procesos de negocios le permitirán identificar los objetos de datos faltantes si se perdieron al analizar el modelo de datos.
Además de compilar el modelo de datos "tal cual", en la etapa de encuesta, se deben describir las reglas para trabajar con diccionarios y libros de referencia en el sistema operativo. En particular, se deben describir los siguientes puntos para cada diccionario:
El formato de la especificación de requisitos para migrar diccionarios del sistema de origen al sistema de destino se proporciona en la tabla y se proporciona un ejemplo de cómo completar dicha especificación.
2. Desarrollo de requisitos de perfiles de datos para la migración
El desarrollo de los requisitos de creación de perfiles de datos para la migración debe involucrar a grupos de usuarios comerciales clave de acuerdo con el plan de comunicaciones desarrollado durante la planificación de la migración de datos. Una plantilla de documento y un ejemplo de llenado para registrar los resultados de la encuesta se muestran en la Tabla 4 (Tabla 4).
Los usuarios comerciales son fuentes para responder las siguientes preguntas de perfil de datos para la migración de datos:
La respuesta a esta pregunta debe ser una descripción de los objetos de datos del sistema de origen con una descripción de las características de trabajar con el objeto de datos durante el período de tiempo durante el cual se migran los datos.
7) ¿Qué unidad funcional o usuarios específicos son propietarios de los datos? La respuesta a esta pregunta debería ser una tabla de correspondencia entre los objetos de datos y los empleados del cliente.
El departamento de TI es la fuente para responder las siguientes preguntas sobre el perfil de datos para la migración:
El personal de TI y los usuarios comerciales deben trabajar juntos para evaluar la criticidad de los posibles errores al transferir datos de un sistema de origen a un sistema de destino. En particular, los usuarios comerciales y los departamentos de TI deben analizar la relación de los objetos de datos en el nivel de la base de datos utilizada para determinar la lista de posibles controles de integridad de datos al migrar al sistema de destino.
El desarrollo de requisitos para un perfil de datos para la migración debe completarse obteniendo una descarga de prueba de datos del sistema de origen (sistemas de origen) de acuerdo con el perfil de datos desarrollado. La carga de prueba resultante se utilizará para depurar el software de migración y evaluar la calidad de los datos proporcionados.
Después de desarrollar los requisitos para el perfil de datos para la migración, es necesario desarrollar reglas para limpiar o transformar los datos descargados de los sistemas de origen para su correcta ubicación en el sistema de destino. Para ello, es necesario correlacionar los requisitos de negocio con el modelo de datos del sistema diseñado y la descripción del modelo de datos del sistema en funcionamiento.
Con el fin de determinar el nivel de calidad de los datos, se deben aplicar los siguientes tipos de controles lógicos dentro de cada objeto de datos en migración:
Los requisitos para las comprobaciones lógicas deben documentarse en la especificación funcional de la utilidad de migración de datos.
Las inconsistencias identificadas en los datos para descargar se pueden eliminar de una de las siguientes maneras: los datos se pueden eliminar de la carga si no tienen valor comercial o se pueden convertir usando algoritmos específicos.
Para la ubicación correcta de los datos en el sistema de destino, se pueden desarrollar algoritmos de transformación de los siguientes tipos para objetos de datos:
Los requisitos para los algoritmos de limpieza y transformación de datos, así como los tipos de objetos de datos a los que se aplicarán, deben fijarse en la especificación funcional de la utilidad de migración de datos.
2) Requisitos para nombrar entidades en el sistema receptor
Los requisitos para el desarrollo de algoritmos para nombrar entidades en el sistema de destino deben desarrollarse en caso de que no sea posible en el sistema de destino aplicar los algoritmos utilizados para nombrar entidades en el sistema o sistemas de origen.
Se deben desarrollar algoritmos para nombrar y numerar objetos de datos en los siguientes casos:
Los requisitos para los algoritmos para generar nombres y números de entidades migradas deben fijarse en la especificación funcional de la utilidad de migración de datos.
3) Requisitos para la migración de datos de registro
Para realizar un seguimiento del estado del proceso de migración de datos, la utilidad de migración debe admitir el registro de la carga de datos en el sistema de destino. Al mismo tiempo, el registro de la utilidad de migración debe reflejar información sobre todas las comprobaciones lógicas realizadas y la eliminación de datos del conjunto de datos para cargarlos en el sistema de destino.
Los requisitos para el registro de la herramienta de migración deben documentarse en la especificación funcional de la herramienta de migración.
El registro de la utilidad de migración debe poder rastrear cada operación como parte del proceso de carga de datos en el sistema de destino.
Cada entrada del registro de migración de datos debe tener al menos el siguiente conjunto de atributos:
El atributo Descripción del error refleja un mensaje parametrizado de la utilidad de migración de datos si la utilidad de migración no pudo cargar el objeto de datos en el sistema de destino.
Si se establece un indicador para un objeto de datos: el objeto se eliminó de los datos migrados, entonces el atributo "Motivo de excepción de eliminación del objeto de datos" debe reflejar un mensaje parametrizado que describa el algoritmo de limpieza de datos, según el cual este objeto se eliminó de la datos migrados.
En el Apéndice 4 se proporciona un fragmento del registro de la utilidad de migración (Apéndice 4 - Fragmento del registro de la utilidad de migración).
Pruebas como parte del trabajo de migración de datos
El trabajo de prueba consta de los siguientes paquetes de trabajo:
A continuación se muestra una secuencia de pasos que debe seguir el equipo del proyecto para llevar a cabo cada una de las etapas de prueba.
Las pruebas iniciales del software de migración deben identificar y eliminar fallas técnicas y defectos en la utilidad de migración desarrollada. Estas pruebas deben ser realizadas por el equipo de pruebas de acuerdo con los casos de prueba desarrollados. Al mismo tiempo, después de las mejoras del software, en caso de errores identificados, es obligatorio realizar pruebas de regresión de la utilidad.
Las pruebas comerciales del software de migración para el cumplimiento de los requisitos comerciales y los algoritmos de transformación de datos deben realizarse utilizando el registro de la utilidad de migración para garantizar la integridad de las comprobaciones y pruebas. El procedimiento para las pruebas comerciales puede ser el siguiente:
Los errores registrados durante las pruebas deben registrarse de tal manera que sea posible determinar sin ambigüedades la fuente de su ocurrencia: un algoritmo o una regla que funcionó incorrectamente.
Para las pruebas comerciales de la utilidad de migración, se pueden utilizar herramientas de prueba automatizadas. En su defecto, el conjunto de pruebas unitarias debería cubrir todos los posibles tipos de objetos de datos que se han migrado al sistema de destino, así como todos los controles y mecanismos de transformación diseñados para cada tipo.
Prueba de limpieza y carga de datos implica trabajar con datos obtenidos después del desarrollo de un paquete de requisitos para el perfil de datos migrados. La carga de prueba debe ser una herramienta para probar las siguientes características del software de migración:
Trabajar con la carga de prueba es la etapa final de probar el software de migración. Después de procesar la carga de prueba por parte de la utilidad de migración, es posible estimar el tiempo planificado necesario para descargar toda la matriz de datos migrados. La colocación exitosa de la carga de prueba en el sistema de destino debe significar la aceptación interna de la utilidad de migración y la capacidad de continuar con el trabajo de descargar la producción: carga completa desde el sistema de origen al sistema de destino.
La limpieza de prueba y la carga de datos en el sistema de destino implica realizar todas las operaciones necesarias para la migración de datos al sistema de destino, incluida la prueba de la funcionalidad del sistema de destino. Esta etapa de prueba se describe con más detalle a continuación.
Probar la funcionalidad del sistema de destino debe brindar la oportunidad de verificar que todas las funciones del sistema que usan contenido migrado funcionan como se espera. En este caso, dicha prueba se puede llevar a cabo en dos etapas:
Para probar el estado del sistema receptor, inmediatamente después de que se complete el arranque, se debe escribir un breve script de prueba que indique exactamente qué se debe probar para la operatividad, por ejemplo:
La prueba detallada de la funcionalidad del sistema de recepción implica el lanzamiento de todos los procesos comerciales automatizados para los cuales los datos de entrada son datos migrados. Si los datos cargados incluyen más de un tipo de objetos de datos, se deben proporcionar scripts de prueba para cada tipo de datos migrados. Los resultados de las pruebas de funcionalidad del sistema receptor deben registrarse en el registro de pruebas.
De acuerdo con el estándar ANSI, el registro de prueba de migración de datos (log) debe tener la siguiente estructura:
La descripción de la operación dentro del caso de prueba debe incluir:
a) Datos de entrada para la operación;
b) resultados esperados;
c) Resultados obtenidos;
d) Fecha y hora de la operación;
e) El número de intentos para realizar la operación;
f) Miembros del equipo de proyecto responsable de las pruebas;
g) Ambiente de operación dentro del caso de prueba.
En el Apéndice 5 se proporciona un fragmento del registro para probar la funcionalidad del sistema receptor (Apéndice 5 - Registro para probar los resultados de la migración).
Migrar a software libre es como migrar a un sistema operativo más nuevo. Como ejemplo, podemos mencionar la aparición de las primeras versiones de Windows en nuestro país. Un ejemplo igualmente llamativo es la migración a Windows NT, la ideología de trabajo en la que difería marcadamente de Windows 9x. Se puede dar un ejemplo más: cada nueva versión del paquete de MS Office difiere de la anterior no solo en las diferencias en la interfaz, sino también en los formatos de archivo. Por lo tanto, la tarea de migración es relevante incluso en el caso de que se utilice software de un solo fabricante.
Este artículo ofrece una descripción general de la metodología de migración con aspectos destacados de los puntos esenciales. El principio general de la migración es la implementación reflexiva y cuidadosa del proceso a través de cambios incrementales. La migración consta de varias secciones lógicamente integrales, etapas.
creación de un grupo de trabajo (quién lo hace)
Al implementar la migración, es necesario prever la solución de problemas de naturaleza técnica y no técnica.
Es importante considerar los problemas legales que recientemente se han vuelto extremadamente actuales para algunos países de la CEI, en particular, Ucrania. En algunos casos, tiene sentido discutir las tareas administrativas de la relación empleador-usuario-administrador. Históricamente, estas relaciones no han sido adecuadamente reguladas por normas e instrucciones corporativas internas.
Durante la elaboración del material se realizaron entrevistas a profesionales en el campo de la seguridad, derecho informático y administradores de sistemas. La gran mayoría manifestó la necesidad de documentar las reglas para que los usuarios trabajen con el sistema de información de la organización.
La planificación adecuada también incluye el manejo de asuntos financieros. Es necesario evaluar los costos de legalizar el sistema de información existente, el costo de introducir uno nuevo y evaluar el costo de propiedad en el futuro previsible.
Cualquier proyecto, incluido un proyecto de migración, puede enfrentarse a una subestimación del factor humano. Naturalmente, se requerirá la aplicación de métodos de gestión de recursos humanos. La mayoría de los administradores de sistemas y gerentes de TI conocidos por el autor no son especialistas en los campos de administración de personal o finanzas. Una tarea tan compleja no puede ser resuelta por un solo departamento de TI.
La primera tarea en el camino para migrar a un nuevo sistema de destino es crear un grupo de trabajo de planificación de la migración. Este grupo es el encargado de realizar la migración y, por tanto, debe tener facultades bastante amplias.
El objetivo del proyecto es construir una infraestructura de TI económicamente viable. Un buen candidato para el puesto de jefe del grupo de trabajo sería un alto directivo de una empresa u organización, por ejemplo, un director financiero. Naturalmente, este grupo incluye al jefe del departamento de TI, quien posee la visión de toda la infraestructura de TI, tanto en el presente como en el futuro. Como parte del grupo, se requiere un administrador de sistemas con experiencia, preferiblemente con experiencia en la operación de software libre. No se puede estimar el tamaño del grupo; en algunos casos, otros empleados de la empresa están involucrados si es necesario. Es posible involucrar a un consultor externo con experiencia o una empresa especializada en este tipo de soluciones. El resultado del trabajo de este grupo es un plan de migración detallado con una estimación del costo de la migración. O - explicaciones de la ineficiencia de la migración a soluciones gratuitas para la organización.
investigar (que es)
El primer paso debe ser una auditoría: una descripción del sistema existente (heredado).
No es ningún secreto que, con los años de informatización de "emergencia" aplicada sin tener en cuenta la recuperación de los fondos gastados en software, el resultado, por regla general, no solo fue económicamente, sino también tecnológicamente sistemas desequilibrados. Auditoría software empresa es una auditoria programas instalados, determinando el cumplimiento de sus requisitos de negocio.
El resultado del proceso de auditoría es:
Descripción especificaciones software instalado;
Lista de riesgos identificados asociados con el uso de software sin licencia;
Cálculo del costo de adquisición de licencias para el software instalado;
Cálculo del costo de eliminar e instalar software con licencia sin licencia;
Determinación de la conveniencia de un uso posterior del software;
Lista de riesgos identificados asociados con el uso del software;
inventario de software
Algunos estudios muestran que la mayoría de los líderes de las organizaciones prestan más atención a la funcionalidad del software que utilizan y mucho menos a respetar los derechos de los productos que utilizan.
Desafortunadamente, la mayoría de las organizaciones carecen de una cultura de TI. A veces, incluso los representantes del servicio de TI no saben realmente qué y dónde está instalado en las computadoras de los empleados, y los empleados comunes deciden e instalan de forma independiente productos de software obtenidos de fuentes dudosas.
El inventario de software ayuda a identificar el software sin licencia en una organización. Cabe destacar que este evento siempre es rentable. El resultado del inventario se puede utilizar para estimar los costos de legalizar el software utilizando tanto software libre como no libre.
Los líderes de las organizaciones a menudo están interesados en una planificación financiera clara de los costos de uso y desarrollo de software. El interés de los altos directivos en tal detalle es bastante comprensible: la alta dirección de las empresas está interesada en convertir el software en un activo de las empresas, que se contabiliza, controla y desarrolla de manera similar a otros tipos de activos.
La auditoría de software es un procedimiento que, por regla general, lleva mucho tiempo, requiriendo personal altamente calificado y conocimiento de varias informaciones específicas en la etapa de análisis de la información. La recomendación puede ser contactar con una empresa especializada en estos servicios. Sin embargo, es bastante posible realizar una auditoría por parte del departamento de TI.
En algunas organizaciones, es inconveniente (a menudo imposible) realizar un inventario de software a gran escala al mismo tiempo. Las razones pueden ser el tamaño de la organización o la política de seguridad. Es necesario encontrar un compromiso entre la efectividad del inventario y los factores que complican tal proceso.
Hay dos opciones para la auditoría. La primera opción es una auditoría completa, que examina todas las instalaciones informáticas, red local y periferias. La ventaja de este método es alta precisión, la desventaja es el alto costo, el alto consumo de tiempo y las molestias para los usuarios. Las ventajas adicionales de este método son la capacidad de identificar el software instalado por los propios usuarios y estudiar los requisitos de software de los usuarios en sus lugares de trabajo utilizando cuestionarios especialmente preparados. La segunda opción es una auditoría de algunas instalaciones informáticas típicas, red local y periféricos. En este caso, la elección de los objetos de auditoría está dictada, por regla general, por las responsabilidades funcionales de los usuarios. Este método de aproximación reduce significativamente el costo del inventario, pero tiene un gran error.
Las organizaciones pequeñas pueden auditar e ingresar manualmente información sobre computadoras y servidores, así como el software instalado en ellos, en una hoja de cálculo simple. En este caso, debe indicar la presencia o ausencia de las licencias, certificados de autenticidad y acuerdos de derechos de autor necesarios para cada uno de los productos de software encontrados.
Para medianas y grandes, puede recomendar el uso de software especializado o invitar a una organización de terceros que se especialice en dichos servicios. En el proceso de elaboración del documento se trabajó en la revisión de las herramientas de inventario automático de software y hardware (se conocen los programas GASP, inventario de PC, MSIA). El eXponent Navigator (http://www.e-x.ru/pages/expnav.html), producido por eXponent, puede convertirse en una recomendación.
Navegador de exponentes
El producto está destinado a la revisión de hardware y software a través de la red. La información sobre las computadoras incluye información sobre los componentes (procesador, tarjeta madre, discos duros, módulos de memoria, tarjeta de video, tarjetas de red, impresoras y otros dispositivos), sistema operativo, controladores y software.
Según los creadores del programa, después de organizar la recopilación automática de información sobre las computadoras, es posible ver y organizar esta información, preparar informes impresos y publicaciones web, cargar datos en Microsoft Excel, XML y otros formatos. Capacidades:
Diagnósticos automáticos de configuración informática;
Recopilación automática de información sobre computadoras a través de la red;
Definición de equipos instalados;
Identificación de programas instalados;
Definición de características del archivo;
Clasificación avanzada, búsqueda y selección de datos;
Preparación de informes impresos;
Exportación de datos a MS Excel;
Generación automática de publicaciones web.
Existe una limitación en la versión gratuita del programa: representa hasta 25 computadoras; el costo de la licencia es de $1 por 1 computadora.
diseñamos (lo que queremos)
Los resultados procesados del estudio del sistema existente son la base para modelar un nuevo sistema objetivo. Esta pregunta es extremadamente importante y compleja. Lo que complica la consideración de este problema es la histórica falta de familiaridad con el software libre, en particular Linux, por parte de la mayoría de los administradores de TI y administradores de sistemas.
Hay mucha literatura, incluso en ruso, sobre Linux, que describe las ventajas de esta plataforma desde un punto de vista tecnológico. Sin embargo, todas estas ventajas son importantes, junto con el problema principal: la existencia de una amplia gama de software de aplicación en diferentes direcciones. El mito de que existe una cantidad limitada de software de aplicación para uso corporativo, incluida la ofimática, se ha difundido mucho durante mucho tiempo y está muy extendido. La gran mayoría de estos mitos son creados y alimentados por los creadores y vendedores de software propietario y tienen poco que ver con la realidad. Desacreditar este mito no es el objetivo principal de este libro. Sin embargo, vale la pena señalar que, por ejemplo, la amplitud del software de aplicación es un fantasma absoluto, teniendo en cuenta los estándares históricamente establecidos para el intercambio de documentos. Entonces, por ejemplo, el editor de oficina estándar de facto es Microsoft Office, el editor de gráficos de trama es Adobe Photosop y Corel Draw es extremadamente común como gráficos vectoriales.
Otro problema suele ser la excesiva funcionalidad de los productos patentados, dictada no por las necesidades del mercado, sino por la opinión de los especialistas en marketing. Y por este exceso de funcionalidad, el usuario paga bastante dinero: el costo de una licencia por el derecho a usar programas, mayor complejidad de operación y mayores requisitos de hardware.
Recientemente, la situación ha cambiado: hay mucha información sobre la aplicación de Linux. Probablemente el mejor material sería este documento :-), que está planeado para cubrir muchos temas administrativos y técnicos.
Sin embargo, por el momento el documento solo se está creando y la información se puede encontrar en varias fuentes. Es imposible pasar por alto los materiales de Valery V. Kachurov, Nesov Artem "Análogos de los programas de Windows en Linux: una tabla de correspondencias". (http://linuxshop.ru/linuxbegin/win-lin-soft/). Este recurso contiene mucha información valiosa. Desafortunadamente, los autores parecen haber abandonado este trabajo. Esta sección del sitio normalmente no está disponible, pero se puede encontrar una copia de la hoja de cálculo en http://www.blif.net/modules.php?name=LinWin. Puede aconsejar los recursos de la Open Source Applications Foundation
(http://www.osafoundation.org/), especialmente http://www.osafoundation.org/desktop-linux-overview.pdf.
El resultado es:
Creación de un prototipo de estaciones de trabajo;
Cálculo del costo de las licencias para el software propuesto;
Entrenamiento de usuario;
Creación de un cronograma aproximado de implementación;
Lista de riesgos en la implementación de software libre;
Soporte para soluciones gratuitas;
Cálculo de la eficiencia económica del nuevo sistema hasta por cinco años.
proyecto piloto (prueba por combate)
Debido a la gran cantidad de factores en un sistema heredado, la gran cantidad de usuarios potencialmente afectados por la migración, se recomienda que la migración se pruebe a pequeña escala. Esta etapa es necesaria para probar y ajustar los planes de migración y el prototipo del nuevo sistema. Es el proyecto piloto que es la base para tomar una decisión sobre la introducción de un nuevo sistema de información basado en software de código abierto. El segundo valor del proyecto piloto es la oportunidad de informar a los usuarios sobre el nuevo sistema, para obtener comentarios de los usuarios. El tercer argumento a favor de un proyecto piloto será la posibilidad de determinar experimentalmente el costo del proyecto con mayor precisión.
Al elegir un objeto de prueba, es necesario encontrar una media dorada. Primero, el objeto seleccionado debe proporcionar datos confiables para la evaluación. En segundo lugar, la realización de un proyecto piloto no debería tener un impacto crítico en la forma de hacer negocios.
En esta etapa también se capacita a los administradores del sistema y usuarios finales: se entrega un prototipo de materiales metodológicos, documentación y recursos de Internet. Se recomienda que los usuarios que participen en el proyecto piloto “descarguen” y den la oportunidad de utilizar parte del tiempo para dominar el nuevo sistema.
La etapa experimental es especialmente demandada:
Si no se ha probado la posibilidad de migrar usuarios de un sistema heredado a un nuevo sistema;
Si hay escepticismo del usuario, eso podrá ralentizar el proceso de migración;
La organización carece de una cultura corporativa (que, lamentablemente, es común en la CEI);
Si hay recursos limitados para la migración a gran escala;
La organización es grande y el proyecto piloto no involucra a muchos usuarios;
Si los sistemas propietarios heredados han evolucionado rápidamente tanto en términos técnicos como en reducción de costos;
El efecto económico de la migración no se ha dilucidado completamente.
Para tener éxito, el proyecto piloto:
No debe referirse a un área crítica del negocio;
Debe ser lo suficientemente importante para el negocio;
No debe requerir un recurso excesivo de personas que ya están limitadas en el tiempo;
Debe tener un grupo de apoyo sustancial;
Debe ser provisto Retroalimentación con los usuarios (sistemas de mesa de ayuda);
No debe haber un período limitado en el ámbito de los demás (por ejemplo, un período importante para los negocios).
Dependiendo del tamaño de la organización, es posible una o más etapas experimentales para determinar con mayor precisión las cadenas y los costos de migrar a lo gratuito. Es importante evaluar sus resultados y determinar si la visión y las metas son prácticas o si deben cambiarse o incluso abandonarse. Los datos de estos proyectos piloto deben usarse para ajustar los planes y calcular el costo final. En el transcurso del experimento, es necesario aclarar las preguntas:
Descripción de las estaciones de trabajo prototipo;
Descripción de la configuración específica del usuario:
Costos promedio para implementar tipos de estaciones;
Transferir datos de un sistema heredado a uno nuevo;
Entrenamiento de usuario;
Cálculo del costo de implementación del software;
Soporte para soluciones gratuitas.
planificación (qué y cómo)
1. Cree un plan de migración. El plan de migración debe responder a las preguntas:
Descripción de las fases de construcción del sistema;
Identificación de necesidades de apoyo;
Descripción de la finalización de la migración.
De hecho, se toma la decisión final sobre cómo se llevará a cabo la migración. Se aprueba el costo estimado de la migración.
2. Descripción de las fases de construcción del sistema. Se debe realizar una evaluación de las fases de construcción del sistema que mejor respalden las necesidades prioritarias de los usuarios.
El plan debe responder a las siguientes preguntas:
¿En qué medida y en qué etapas se debe instalar e implementar el sistema para satisfacer mejor las necesidades del usuario?
¿Qué se requiere para cada fase de la migración a un nuevo sistema por parte de los clientes y usuarios del sistema de la organización?
¿Cuál será el impacto y el riesgo de usar el sistema en cada paso del incremento?
Las etapas de implementación del sistema deben estar claramente definidas en el plan de migración; los clientes, desarrolladores y usuarios deben ser conscientes. Las evaluaciones de riesgos deben completarse antes de completar el plan de construcción del sistema. Se debe asegurar que las estimaciones de planificación sean razonables, que el enfoque esté bien concebido de acuerdo con las prioridades de la organización y que el impacto potencial en los clientes y usuarios sea aceptable.
3. Determinación de las necesidades de apoyo. Se debe proporcionar un nivel óptimo de soporte para ayudar a los usuarios a utilizar el nuevo sistema. Además, los usuarios a menudo requieren el servicio de asistencia técnica para ayudarlos a comprender las capacidades generales del sistema de destino.
Los problemas que se abordarán incluyen:
¿Qué capacitación y asistencia operativa requerirán los usuarios?
¿Cuál es el nivel general de soporte de migración que los usuarios necesitarán para garantizar una migración exitosa?
¿Cómo lograr la aceptación del usuario del sistema de destino y evitar la resistencia del usuario a la implementación del nuevo sistema?
¿Cómo se notificará a los clientes y usuarios sobre los cambios inminentes en las funciones y servicios del sistema?
¿Es posible que una solución gratuita sea soportada por el departamento de TI de la organización, o la subcontratación sería la mejor opción?
El plan de migración debe centrarse en abordar estos problemas mediante la planificación de la asistencia al usuario en las áreas de:
Sistema de notificación de problemas;
Servicios de asistencia técnica para nuevos sistemas;
Asistencia técnica a usuarios que migran a nuevos sistemas;
Guías de usuario para la transición y más allá;
Capacitación para que los usuarios aprendan y se adapten al nuevo sistema, para realizar el mismo tipo de tareas;
Capacidad para probar el uso de nuevos sistemas;
Demostraciones sobre el uso de nuevos sistemas para mostrar a los usuarios existentes de sistemas heredados cómo funciona el nuevo sistema y cómo pueden realizar tareas comparables;
Superación de los problemas operativos actuales.
Durante la fase de educación del usuario, preste especial atención a aquellos que están comprometidos con el antiguo sistema y/o se oponen a los nuevos sistemas.
4. Descripción de la finalización de la migración. Después del final de cada nueva fase de implementación y capacitación, los desarrolladores e implementadores deben asegurarse de que los usuarios migren al nuevo sistema de destino de la manera más cómoda posible. El plan de migración debe permitir acelerar el esfuerzo de migración y eliminar el sistema heredado lo antes posible.
Es necesario prever el esfuerzo adicional que puede ser necesario para los "adoptadores más recientes" y otros usuarios que experimentan problemas imprevistos. Otro aspecto de esta actividad es evaluar el tiempo y el costo para completar la transición de todos los usuarios al nuevo sistema y eliminar los sistemas antiguos basados en software propietario sin licencia.
Los líderes organizacionales, los desarrolladores y los implementadores deberían considerar incorporar varios enfoques para ayudar a migrar usuarios de sistemas heredados:
Informar a cada grupo de usuarios cómo y cuándo deben migrar sus tareas a nuevos sistemas, cómo cambia la carga de trabajo durante el período de migración desde sistemas heredados;
Establecer incentivos para pasar completamente a un nuevo sistema gratuito y eliminar las dependencias de los sistemas heredados;
Brindar asistencia (software y personal adicional) para convertir los datos heredados al nuevo sistema; - procedimientos para el desmantelamiento de sistemas heredados;
Archivo de datos de sistemas heredados y su almacenamiento.
migración (hacer)
Todo lo que queda en la última etapa es trabajar de acuerdo con el plan.
Gestione y controle activamente los procesos de migración:
Establecer criterios de medición y realizar un seguimiento de los pasos de migración y los costos de recursos para la migración;
Hacer revisiones periódicas de la situación y ponerlas en conocimiento, de acuerdo con el mandato y la política organizacional, a las personas involucradas (gerencia, gerentes de proyecto y patrocinador);
Establezca un sistema de seguimiento para administrar el progreso del proceso (progreso), los problemas, las resoluciones y otros problemas comerciales relacionados con la planificación de la migración y los planes de implementación.
Vadim Mashkov, UA-FOSS, [correo electrónico protegido]
Serguéi Berdachuk, 1.0 2006.12.01
Parecería que la presencia de un sistema de información (SI) ya existente debería simplificar y acelerar el desarrollo de un nuevo SI basado en el antiguo, pero en la práctica todo suele suceder exactamente al contrario. En primer lugar, dado que era necesario crear un nuevo IS, esto significa que el IS creado anteriormente se creó con fallas significativas y está repleto de varios errores.
Por lo general, de una IP que ha sido escrita a lo largo de los años por varios desarrolladores. Al mismo tiempo, la documentación del proyecto a menudo se encuentra en un estado miserable y, a veces, está completamente ausente. Los programadores "reales" no escriben documentación, y mucho menos documentan código. Por qué, porque todo es simple y transparente. Sin embargo, cuando observa su propio código después de medio año, es bastante difícil averiguar qué se hizo allí. Especialmente si se han realizado varios otros proyectos durante este tiempo.
Además, cada nuevo desarrollador generalmente no se molesta en estudiar cuidadosamente ni el código ni la arquitectura del sistema. Dado que los plazos siempre están "ardiendo", los "gadgets" simplemente se escriben para una solución temporal a un problema urgente. El resultado es una "gacha de avena" que consta de muchos módulos variopintos y, de alguna manera, tecnologías acopladas milagrosamente que a veces no son compatibles entre sí. La situación se ve agravada por el uso de sistemas de administración de bases de datos (DBMS) heredados para el almacenamiento de datos, como dbase-III, FoxPro o Clipper. La ausencia del concepto de transacción, y con un diseño e integridad referencial ineptos, conduce a numerosas violaciones de la integridad de los datos. Se puede considerar afortunado si el antiguo sistema usaba un DBMS, a veces hay creaciones que usan archivos de texto para almacenar datos (al migrar uno de estos sistemas, el autor tuvo que escribir un controlador especial para acceder a dicha base de datos).
Quizás el único punto positivo es la experiencia acumulada en la formación de requisitos para un IS recién desarrollado. Por otro lado, la experiencia de comunicarse con el antiguo sistema puede convertirse en un freno importante para la introducción de un nuevo producto. En la mayoría de los casos, esto ocurre debido a las diferencias en la construcción de la interfaz visual y las teclas de función utilizadas para realizar ciertas operaciones. Por lo tanto, el sistema operativo puede reservar algunas de las teclas de función para realizar ciertas acciones. Un ejemplo típico es el uso de la tecla "Enter" para pasar al siguiente elemento de un formulario editable en los circuitos integrados de DOS más antiguos. En las interfaces gráficas se suele utilizar la tecla “Tab” para este fin. Como resultado, recibimos una fuerte oposición de los usuarios al implementar nueva versión producto. Por supuesto, es posible emular el comportamiento de la interfaz UI (interfaz de usuario) del sistema anterior, pero es mejor hacerlo de manera opcional. Aquellos. introducir la capacidad de configurar el comportamiento del sistema en el módulo de configuración IS y, de forma predeterminada, utilizar la configuración correspondiente al sistema operativo actual. De lo contrario, el producto recién desarrollado será difícil de aprender para los nuevos usuarios que esperan que el programa se comporte de acuerdo con los estándares actuales.
En cuanto a trabajar con los datos almacenados del antiguo sistema, la situación es aún peor. La decisión de la dirección de utilizar parte de los módulos del antiguo sistema tendrá las consecuencias más graves. Por ejemplo, cuando nos enfrentamos a la tarea de desarrollar una nueva versión de la contabilidad del almacén, y la solución de otras tareas (contabilidad, etc.) será abordada por la versión anterior de IS. En este modo de operación, surge el problema de la migración de datos en modo de tiempo "real". Los gastos generales de mantener el trabajo de todos los módulos como un todo pueden exceder el costo de desarrollar una nueva versión de todos los módulos. Además, los costos pueden diferir en órdenes de magnitud, teniendo en cuenta las posibles pérdidas por las deficiencias del antiguo sistema y los errores en el intercambio y conversión de datos. Entonces, uno debe evaluar cuidadosamente la condición del antiguo IS y su viabilidad. Y lo que es más interesante, en la práctica, este problema generalmente no se ve afectado, hasta que ocurre: "Aquí crearemos un nuevo sistema y luego nos ocuparemos del acoplamiento con otro software y migraremos los datos".
Pero luego llega el momento en que el problema está maduro, el nuevo sistema está escrito y es hora de convertir y transferir datos al nuevo sistema. Al analizar la experiencia de migración de datos de una gran cantidad de diversos sistemas de información, se puede destacar un procedimiento típico de migración de datos, que incluye:
La opción más sencilla suele ser crear un programa intermedio. Debe comunicarse con las bases de datos de origen y destino y realizar las transformaciones necesarias.
Arroz. 1. Opción con middleware para migración de datos
Una desventaja significativa de esta solución puede ser la carga de la red durante la transferencia de datos. Si la cantidad de datos es significativa, la comunicación de la red puede afectar en gran medida el rendimiento.
Una mejor solución podría ser precargar los datos antiguos en las tablas temporales del nuevo DBMS. Los DBMS modernos (por ejemplo, Oracle) generalmente contienen utilidades especiales que permiten la descarga muy rápida de datos externos en varios formatos. El propio módulo de migración está escrito en lenguajes de procedimiento integrados en el DBMS (por ejemplo, PL/SQL o Java). Puede aumentar significativamente la velocidad del procedimiento de migración debido al hecho de que los lenguajes de programación incorporados funcionan en su entorno "nativo", están optimizados para el DBMS de destino y no hay costos generales para el intercambio de datos a través de la red. .
Arroz. 2. Opción de migración de datos usando DBMS
A partir de la experiencia práctica de escribir dichos programas, me gustaría llamar la atención sobre el uso de métodos SQL por lotes que son compatibles con la mayoría de DBMS y lenguajes de programación (por ejemplo, los métodos addBatch() y executeBatch() en Java). La ejecución de una sola instrucción INSERT o UPDATE para una matriz de datos en lotes de 100 a 200 registros brinda una mejora significativa en el rendimiento, en comparación con la ejecución de esta instrucción en un bucle para cada registro por turno.
Las empresas modernas a menudo enfrentan la necesidad de migrar sus sistemas de información. Sin embargo, la implementación de este procedimiento debe estar precedida por una preparación cuidadosa, ya que hay muchos obstáculos en el camino.
Puede haber muchas razones para comenzar la transición a un nuevo sistema de información (IS), incluida la reducción de los riesgos asociados con la operación de plataformas obsoletas, llevar los sistemas de información a los estándares internacionales y aumentar la eficiencia de los procesos comerciales. Pero no importa cuál sea la tarea que tiene por delante la empresa, la transición de un SI a otro debe planificarse y prepararse cuidadosamente.
Cuando se trata de la migración de sistemas transaccionales, como ERP, facturación, procesamiento o ABS, la transición a un nuevo sistema es muy problemática. El punto es que los profesionales de TI deben garantizar la migración precisa de grandes cantidades de datos, manteniendo la operación paralela del sistema antiguo y nuevo para la reconciliación y el análisis de resultados.
Por ejemplo, tuve una experiencia de proyecto en uno de los bancos más grandes, donde se llevó a cabo la transición del sistema transaccional de la plataforma Informix, que ya no tiene soporte, a la plataforma Oracle. Al mismo tiempo, fue necesario llevar a cabo un análisis exhaustivo de los procesos comerciales, transferir repetidamente datos del sistema anterior al nuevo y verificar el cumplimiento de los resultados del trabajo de los sistemas nuevo y antiguo, teniendo en cuenta la duración de las normas del proceso. Es por eso que el período de migración fue de 14 meses. A veces, la operación paralela de dos sistemas puede continuar por más tiempo, pero incluso cuando se limita a varios meses, para garantizar la operación de un nuevo SI, es necesario asignar potencia de cómputo adicional y tiempo significativo para los empleados de la empresa. realizar simultáneamente tareas en dos sistemas.
A menudo, la propiedad intelectual se actualiza como parte de la globalización y la centralización. Esto le permite reducir significativamente el costo de mantenimiento y actualización de los sistemas de software. De hecho, mantener una plataforma única que sirva a todos los empleados es mucho más fácil que mantener herramientas separadas para cada departamento. Por ejemplo, la migración exitosa de un sistema de control de inventario puede traer varios miles de departamentos de una gran organización a una sola plataforma y proporcionar una reducción significativa en los costos de TI. Sin embargo, debe recordarse que la mayor parte de la preparación en este caso recae en la coordinación de datos en varios formatos y representaciones, el desarrollo de nuevas regulaciones y la construcción de nuevos modelos de interacción de los empleados.
Otro aspecto importante- interfaces de integración con otros SI empresariales, especialmente los propios y específicos. Los problemas asociados con ellos pueden no ser tan notorios en la primera etapa, pero se identifican al establecer la interacción de varios departamentos con el sistema general. Y si para el antiguo sistema dichas interfaces ya se han implementado de forma programática u organizativa, entonces para el nuevo sistema es posible que deban desarrollarse de nuevo.
Debe recordarse que los pensamientos sobre la expansión de la funcionalidad del sistema pueden surgir ya durante la implementación del proyecto, al igual que el apetito surge al comer. Y esto significa que se requerirá mucho trabajo adicional.
La experiencia de las actividades del proyecto de migración del sistema muestra que cualquier proyecto de este tipo requiere una preparación cuidadosa y debe ir acompañado de un plan individual. Sin embargo, independientemente del tipo de sistemas que se migren, el software, el tamaño de la base de datos, etc., el esquema general parece casi idéntico.
En la primera etapa, es necesario realizar una auditoría detallada, averiguando todos los requisitos para el modo de operación del nuevo sistema, entrevistando a todos los usuarios clave. Es importante entender cuántos datos, qué tipo de carga está involucrada, solo así los expertos podrán ofrecer la estrategia de migración correcta.
Los procedimientos en sí también deben pensarse cuidadosamente e incluir elementos tan importantes como las reglas para el acceso de los usuarios a los sistemas durante la migración, los procedimientos de reversión en caso de fallas y la interacción de varios especialistas involucrados en estos procesos.
Después de un acuerdo con el cliente, generalmente se elabora un plan detallado, que involucra varias etapas, a saber: copia de datos, su verificación, operación paralela de dos sistemas y una transición completa a una nueva plataforma. En mi opinión, lo principal en una migración de sistema organizada profesionalmente es la fluidez de este proceso para los usuarios que pueden comenzar a trabajar gradualmente, sin estrés, en un nuevo sistema automatizado.
Sin embargo, incluso una preparación minuciosa no siempre le evita subestimar los costos de mano de obra al transferir usuarios a los “nuevos rieles”. Este proceso incluye tanto la formación de los empleados de la compañía como su apoyo durante el periodo de adaptación al nuevo sistema.
En este artículo, nos gustaría sistematizar nuestra experiencia en la realización de migraciones de datos en grandes proyectos corporativos relacionados con la transición de Clientes para trabajar en configuraciones 1C:Enterprise 8.
Al mismo tiempo, el énfasis principal del artículo se pondrá, en primer lugar, en el componente tecnológico del proceso de migración. El componente organizativo también se ve afectado, pero en menor medida.
La migración de datos se entiende comúnmente como una secuencia final de trabajo, un proyecto destinado a un movimiento masivo de datos de una sola vez desde los sistemas de origen (sistemas históricos) a un sistema receptor. Al mismo tiempo, se cancela la operación de estos datos en los sistemas de origen.
La migración de datos debe distinguirse de la integración de datos. La integración, a diferencia de la migración, es una parte permanente de la arquitectura de TI y es responsable del flujo de datos entre diferentes sistemas y almacenes de datos, y es un proceso, no una actividad de proyecto.
El esquema de migración en general se ve así:
Arroz. una
Sistemas históricos- bases de datos de la empresa del Cliente, que se prevé sustituir total o parcialmente durante la implantación del nuevo sistema.
Sistema receptor- sistema de destino, configuración arbitraria "1C:Enterprise 8".
Datos iniciales- datos descargados de sistemas históricos en un formato de archivo xls arbitrario. En este caso, el formato xls parece ser uno de los más convenientes, ya que la capacidad de cargar en un archivo xls está presente en muchos sistemas de contabilidad de "generación anterior".
Como alternativa moderna, es posible considerar el formato de archivos xml como un medio de transporte.
También hay opciones para usar una base de datos intermedia.
Transformación, conversión- el proceso de convertir datos sin procesar en datos para descargar. La transformación de datos se produce de acuerdo con las plantillas para la carga. El resultado de la transformación son los datos a cargar.
datos para descargar- datos a cargar en el sistema receptor. En este artículo, además de los datos de origen, se considera el formato xls.
Descargar plantillas de datos- descripción de las tablas de datos que se cargarán en el sistema de destino.
Considere el proceso de preparación y realización de la migración paso a paso.
Las etapas organizativas de la migración incluyen los siguientes elementos:
· Definir la estrategia de migración. En esta etapa, el Contratista y el Cliente acuerdan la tecnología del trabajo de migración;
· Determinación de la composición del grupo de trabajo sobre migración. El grupo de trabajo debe incluir especialistas tanto del Contratista como del Cliente, que estén suficientemente familiarizados con la operación de los sistemas históricos (por parte del Cliente) y el sistema objetivo (por parte del Contratista);
· Plan preliminar de migración. El plan de migración se ajustará repetidamente durante el transcurso del proyecto;
· Periodos de fechas de descarga de datos de sistemas históricos, volúmenes de datos. Períodos de corte de datos para migraciones, fechas de prueba y migraciones finales. Esta informacion puede atribuirse al plan de migración;
· Composición de los datos a migrar. Datos de referencia, clasificadores, datos transaccionales, saldos, rotaciones, etc.;
· Cuestiones de comprobación de la calidad, corrección e integridad de los datos durante y después de la migración;
· Problemas de reversión al estado anterior en caso de fallas.
Detengámonos con más detalle en las etapas tecnológicas de la migración.
Arroz. 2
La plantilla de carga de datos contiene descripciones técnicas de las tablas de datos que se cargarán, algoritmos y reglas de carga para la plantilla actual.
Cada plantilla generalmente está destinada a una o más tablas relacionadas en el sistema de destino.
La plantilla especifica:
Descripción de todos los campos del archivo de datos xls a cargar, incluyendo:
o Nombre del campo
o Señal de campo obligatorio
o Ejemplo de llenado de campo
Nota
Descripción de las reglas de carga de la tabla del sistema de destino en función de los datos a cargar (orden en el caso de varias tablas relacionadas, algoritmos de búsqueda de campos clave, etc.)
· Descripción del llenado de los campos de las tablas del sistema de destino directamente en caso de que se prevea algo diferente a la transferencia de datos uno a uno desde el archivo de datos para la carga. Relevante para campos de referencia, por ejemplo.
En el curso de los trabajos en esta etapa, el Contratista también debe preparar un cargador de archivos de datos para la carga. En el caso de trabajar con archivos xls, esta tarea no es especialmente difícil.
Este paso puede comenzar junto con el paso anterior “1. Elaboración de plantillas de carga de datos”.
Como parte de esta etapa, los especialistas del Cliente determinan desde qué sistemas y qué datos se pueden cargar. También es necesario determinar qué datos Quizás puede ser necesario.
Como regla general, en proyectos de migración grandes, la identificación de una lista completa y exhaustiva de fuentes de datos puede llevar bastante tiempo y ocurre a medida que se realiza el trabajo en las etapas posteriores.
No es raro que se produzcan situaciones en las que, para garantizar la integridad de la información en el futuro, algunos datos deben transferirse desde fuentes impresas (digitalizadas) o incluso ingresarse en tablas a partir de las palabras de empleados clave del Cliente.
Sin embargo, en esta etapa, debe tratar de identificar la mayor cantidad posible de datos necesarios.
El proceso de descarga de datos de los sistemas históricos puede llevar una cantidad de tiempo suficiente, especialmente si hay muchos sistemas, son diferentes y diferentes departamentos del Cliente son responsables de ellos. Es necesario tener en cuenta este momento durante las migraciones de prueba y finales.
La opción más conveniente parece ser subir a archivos xls. Muchos sistemas de TI antiguos admiten esta opción.
También puede haber opciones para cargar en formato csv, dbf, xml y otros.
Cabe señalar que, por una u otra razón (problemas de seguridad, por ejemplo), ¡el Cliente no siempre puede proporcionar la carga de datos completa en esta etapa! Solo una estructura de datos y algunas posiciones de prueba. Por lo tanto, puede surgir una situación en la que durante las cargas de prueba y finales, se encuentren datos de baja calidad en las tablas de origen, lo que conducirá a errores no planificados.
Para minimizar este problema, los volúmenes de descargas de prueba de los sistemas históricos deben especificarse con anticipación.
Mapeo (mapeo de datos) - en el caso general, el proceso de comparar datos de sistemas históricos y el sistema receptor. Es decir, los datos de origen y los datos a cargar.
La etapa de asignación es la etapa que consume más tiempo y puede ocupar más del 50 % de todo el trabajo de la tarea de migración.
En esta etapa, todo el grupo de trabajo del proyecto sobre migración está completamente involucrado.
En el proceso de mapeo de datos, es necesario distinguir las subetapas de mapeo de tablas y mapeo de campos.
· Mapeo de tablas, o mapeo de plantillas - comparación de tablas de datos iniciales y plantillas de datos para carga. La correspondencia puede ser 1:1 o N :N . Como resultado de este trabajo, se compila y mantiene un registro de mapeo de tablas. Este subpaso es necesario para el siguiente subpaso de mapeo de campos y para realizar un seguimiento del progreso general del mapeo.
|
Plantilla grupo 1C |
Nombre de la plantilla 1C |
Nombre del archivo- fuente |
Reglas para generar un archivo fuente |
Responsable |
Estado |
Nota |
|
NSI |
Muestra_ Nomenclatura |
Nomenk latura.xls |
En la selección de conjuntos del sistema N |
Ivanov II |
En el trabajo |
· Asignación de campos: comparación de campos de tablas dentro de una asignación de tablas ya definida. El resultado de este trabajo es un registro de mapeo de campo.
|
N.º págs. |
cl. campo |
Requerido |
Nombre de campo de plantilla 1C "Template_Nomenclature" |
Descripción |
Nombre de campo "Nomenclatura.xls" |
Algoritmo de relleno |
||||||||
|
El código |
Código de elemento de directorio |
El código |
||||||||||||
|
Nombre |
Nombre |
|||||||||||||
|
Sí |
Este grupo |
Contiene uno de los siguientes valores: |
Si la longitud del código = 11 caracteres y los últimos 4 caracteres<>"0000", entonces este elemento es "0", de lo contrario el grupo es "1". |
|||||||||||
|
Nombre completo |
Nombre del elemento de directorio |
Nombre |
If ThisGroup =1 , Then "", ElseIf ThisGroup=0, then Name. |
|||||||||||
Como parte de esta etapa, también se deben realizar posibles trabajos de normalización de datos.
A diferencia de las etapas anteriores, esta etapa es técnica e involucra el trabajo del desarrollador del Contratista.
Con base en los registros de mapeo de campo acordados, los especialistas del Contratista desarrollan reglas de transformación de datos.
Para el trabajo operativo durante las etapas preparatorias de la migración y más allá, durante las migraciones de prueba y finales, es importante que haya un entorno conveniente para desarrollar reglas de transformación de datos (scripts) y un entorno para convertir los datos iniciales en datos para cargar.
Los requisitos para este entorno incluyen:
· Conveniencia y velocidad de desarrollo de las reglas de transformación;
· Velocidad de conversión de datos. ¡Los archivos de entrada y salida pueden tener cientos de miles de líneas!
· Capacidad para trabajar con múltiples archivos de entrada simultáneamente;
· Capacidad para guardar reglas de transformación en archivos separados.
Para nuestros proyectos de migración, hemos desarrollado una estación de trabajo de desarrollador especializada, basada en el procesamiento estándar de la "Consola de solicitudes" 1C.
Se ha mejorado el manejo de la "Consola de consultas" para permitir solicitudes directas a archivos xls.
Aquí hay un ejemplo de la combinación de dos archivos fuente xls Empleados.xls
|
Código de empleado |
Apellido |
Nombre |
segundo nombre |
Fecha de nacimiento |
|
2423 |
Ivánov |
Iván |
ivanovich |
17.11.1992 |
|
1523 |
Petrov |
Albahaca |
Alexandrovich |
04.02.1991 |
|
4363 |
Sidorov |
cirilo |
Nikoláyevich |
01.05.1995 |
|
Denisov |
Denis |
Denisovich |
01.01.1990 |
y Operaciones.xls con paginas:
cancelaciones
|
Código de empleado |
la fecha |
Suma |
|
2423 |
01.02.2014 |
|
|
1523 |
02.02.2014 |
|
|
4363 |
03.02.2014 |
|
|
04.02.2014 |
100000 |
|
|
2423 |
05.02.2014 |
|
|
1523 |
06.02.2014 |
|
|
4363 |
07.02.2014 |
2356 |
|
08.02.2014 |
140000 |
|
|
2423 |
09.02.2014 |
|
|
1523 |
10.02.2014 |
|
|
4363 |
11.02.2014 |
23523 |
|
12.02.2014 |
80000 |
y Ingreso:
|
Código de empleado |
la fecha |
Suma |
||
|
01.05.2004 |
||||
|
02.05.2004 |
||||
|
03.05.2004 |
||||
|
04.05.2004 |
||||
|
2423Fecha de nacimiento |
Cantidad recibida |
cantidad de cancelación |
||
|
Ivánov Iván Ivánovich |
2423 |
17.11.1992 |
1341234 |
1010 |
|
Petrov Vasili Alexandrovich |
1523 |
04.02.1991 |
245245 |
|
|
Denisov Denis Denisovich |
01.01.1990 |
380000 |
320000 |
|
|
Sidorov Kirill Nikolaevich |
4363 |
01.05.1995 |
613382 |
26336 |
|
TOTAL: |
2579861 |
347842 |
Tenga en cuenta que el ejemplo es artificial, especialmente seleccionado para demostrar todas las etapas posibles de la transformación de la fuente de datos.
La secuencia tecnológica de las operaciones de transformación aquí es la siguiente:
Con el lenguaje de consulta de Access SQL (que proporciona características adicionales significativas en comparación con el lenguaje de consulta de 1C), se crea una consulta inicial que recupera datos del archivo xls en el entorno de 1C. Al mismo tiempo, en esta etapa ya son posibles varias comprobaciones y normalizaciones de datos.
La tecnología de acceso a datos ADO proporciona alta velocidad trabajar.
Arroz. 3
2. Solicitud en lenguaje 1C: la solicitud principal que implementa el algoritmo de mapeo de campos. Y también: enriquecimiento de los datos descargados con datos de la base de datos 1C, reagrupación, fusión con los resultados de consultas a otros archivos fuente xls, etc.
3. Posprocesamiento del resultado de la solicitud 1C, en caso de ser necesario. Se implementa mediante un script en lenguaje 1C.
Por ejemplo, aquí se implementa la adición de la línea "TOTAL" para las columnas de montos.
4. Grabación del conjunto de datos final en un archivo xls.
En el caso general, en la salida obtenemos los archivos finales para cargarlos en la base de datos 1C de destino.
Además, esta herramienta le permite guardar las reglas de conversión de datos en un archivo xml separado:
Además, es posible trabajar en por lotes, que es especialmente importante con una gran cantidad de datos migratorios heterogéneos.
En el transcurso de las etapas anteriores, finaliza la parte preparatoria del trabajo en su conjunto: se identifican todas las fuentes de datos, se descargan los datos iniciales de las fuentes, se preparan plantillas para cargar en la base de datos de destino, se prepara el mapeo de datos y, finalmente, se desarrollan scripts de transformación de datos.
Cabe señalar que antes de la migración final, definitivamente debe realizar varias pruebas. Durante las migraciones de prueba, el Contratista junto con los Clientes identifican:
errores de conversión, errores de carga de datos
llevar a cabo una evaluación preliminar de la calidad de los datos cargados en el sistema de destino
Con base en los resultados de las migraciones de prueba, elaboran/actualizan el plan de migración final
La verificación de la calidad de los datos descargados debe realizarse tanto después de las migraciones de prueba como al final de la migración final. Durante la conciliación, se pueden verificar los siguientes indicadores:
· Coincidencia de totales para saldos, para documentos;
Coincidencias cuantitativas, como el número de OS;
· Corrección del llenado de entidades selectivas separadas;
Tenga en cuenta que ciertas comprobaciones de la migración de datos y los problemas de normalización de datos deben abordarse en todos los procesos de migración. Siempre debe preguntarse qué se debe hacer en la etapa actual para evitar errores en las etapas posteriores.
Por ejemplo:
· Comprueba si hay duplicados por campos clave. Es posible y necesario realizar todavía sobre los datos iniciales;
· Tipos de campos de fundición;
· Integridad referencial;
· Inconsistencias matemáticas. Por ejemplo, la comprobación de campos numéricos vacíos, que se prevé dividir durante la transformación;
· En general, verificar el llenado obligatorio de los campos;
· Sustitución de caracteres incorrectos. Por ejemplo, caracteres ingleses en campos cirílicos ("o", "a", "e", etc.) ¡Esto es especialmente cierto para los campos clave!
Verificación de los valores de los campos de cadena para el cumplimiento de los tipos del sistema receptor (restricciones de longitud)
Una vez completada la migración final, de acuerdo con una estrategia de migración y un plan de migración predeterminados, se toma una decisión sobre el funcionamiento posterior de los sistemas heredados.
A menudo, la operación se completa inmediatamente después de la conciliación final de los datos y el éxito de la migración: los usuarios del nuevo sistema ya no mantienen registros en paralelo en dos sistemas, sino que cambian por completo al nuevo sistema. Al mismo tiempo, el acceso al antiguo sistema se conserva en modo lectura.
En algunos casos, la operación paralela de dos sistemas puede ocurrir durante el período de operación de prueba (OE) e incluso más que este período. La cuestión del trabajo paralelo de los usuarios en dos sistemas está estrechamente relacionada con la cuestión de la posibilidad de una reversión al antiguo sistema, si la migración (¡o, en general, la operación del nuevo sistema!) se considera insatisfactoria.
En conclusión, me gustaría señalar que cuando se trata de la migración de grandes sistemas transaccionales, que incluyen muchas configuraciones de 1C:Enterprise, la transición a un nuevo sistema puede llevar mucho tiempo.
Por lo tanto, debe recordarse que cualquier proyecto de este tipo requiere una preparación cuidadosa y debe ir acompañado de un plan individual. Sin embargo, independientemente del tipo de sistemas que se migren, el volumen de las bases de datos, etc., el esquema general de migración parece casi idéntico.
