Herramienta para Migración de Datos Registrados en Biblioteca (MiDaReUNLa)

Herramienta para Migración de Datos Registrados en Biblioteca (MiDaReUNLa) Alan Cartannilica, Gastón Fighera, Gerónimo Tondato Cátedra Proyecto de Software Licenciatura en Sistemas 2011

2 Cartannilica, Alan - Fighera, Gastón - Tondato, Gerónimo Índice 1. Proceso de Selección de un Modelo de Ciclo de vida del Producto 3 2. Procesos de Gestión del Proyecto...4 2.1. Proceso de Iniciación del Proyecto.4 2.2. Proceso de seguimiento y control del proyecto.6 2.3. Proceso de gestión de la calidad del software 7 3. Proceso de Pre Desarrollo..11 3.1. Procesos de exploración de conceptos..11 3.2. Procesos de asignación del sistema..11 4. Procesos Orientados al desarrollo del software 13 4.1. Proceso de requisitos..13 4.2. Proceso de diseño...14 4.3. Proceso de Implementación 22 5. Procesos de Post Desarrollo 31 5.1. Proceso de Instalación 31 6. Procesos Integrales del Proyecto 32 6.1. Plan de verificación y validación 32 6.2. Plan de Pruebas...32 1. Anexo: Cómo Utilizar los Scripts de conversión?...33 1.1. Exportación del catálogo de datos de la Biblioteca almacenados en el software In-Magic...33 1.2. Exportación del catálogo de usuarios de la Biblioteca almacenados en el software In-Magic..33

Herramienta para Migración de los datos registrados en la Biblioteca De la Universidad Nacional de Lanús (MiDaReUNLa) 3 1. Proceso de Selección de un Modelo de Ciclo de vida del Producto El modelo de ciclo de vida seleccionado es Cascada debido a que los requisitos especificados por el usuario, son claros, concisos y se sabe que no sufrirán cambios a lo largo del proyecto, el producto terminando no requiere de interfaz grafica, por lo cual no habrá interacción del usuario con el producto (de esta manera descartamos el modelo de ciclo de vida prototipado), además nos permitirá controlar y seguir los progresos de un modo más exacto. 2. Procesos de Gestión del Proyecto 2. 1. Proceso de Iniciación del Proyecto El proyecto que se llevara a cabo será gestionado teniendo en cuenta la duración y el esfuerzo requerido para cumplir con las cinco fases principales de nuestro proyecto de software, las cuales son requisitos, diseño, codificación y pruebas necesarias para garantizar la calidad del mismo. Para el trabajo contamos con los recursos humanos de tres personas cada uno de nosotros se encargara de cumplir en tiempo y forma con los hitos entregables establecidos. Serán empleadas técnicas de diseño como los DFD, diagramas UML y diagramas de secuencia. Prestando especial atención a las características inherentes a este proyecto detectamos tres partes fundamentales que hacen a la integridad del artefacto de software, la primera consta de la especificación de un formato de datos de entrada apto para ser procesado posteriormente, la segunda hace referencia al procesamiento en sí de esos datos, generando de esta manera un set de datos apto para ser insertado en la base de datos final, y la tercera y última etapa es la inserción de los datos generados previamente. El artefacto a desarrollar, contara con una entrada de usuario, y procesara 1 archivo a la vez, en total procesara 15 archivos. Mediante estos datos podemos calcular los

4 Cartannilica, Alan - Fighera, Gastón - Tondato, Gerónimo puntos de función que nos permitirán hacer una estimación aproximada del tamaño del software en líneas de código (LDC). Archivos 1 *15 15 Entrada de usuario 1 *3 3 Total 17 PF=17*(0.65+0.01*6*7)=18.19 Java 1 punto de función = 53 líneas de código LDC=18.19*53=964.07 Cálculo de esfuerzo (E) E = 3,2 x (0.964)1,05 x 0,4 = 1,23 3,2-1,5-0,4 son los coeficientes para los sistemas categorizados como Orgánicos relativamente sencillos y con menos de 50 KLDC. Cálculo de tiempo (T) T = 1,23 / 3 = 0,41 meses = 13 días 3 es la cantidad de personas asociadas a la tarea de codificación. Cálculo de horas (H) H = 13 x 4 = 52 horas 4 son las horas promedio de trabajo por día.

Herramienta para Migración de los datos registrados en la Biblioteca De la Universidad Nacional de Lanús (MiDaReUNLa) 5 Para la codificación del software se utilizara la tecnología Java brindada por Oracle en su versión J2SE debido a su amplio uso en diversos proyectos y a su probada robustez. Nuestro equipo de trabajo se organiza de forma Descentralizada Democrática, con lo cual no hay posiciones jerárquicas establecidas ni comunicación vertical entre los integrantes del equipo, si bien se puede designar a fin de coordinar cada tarea un coordinador. Recursos Humanos: Se cuenta con tres personas que se desempeñan en los siguientes roles: Cartannilica, Alan: Analista/Desarrollador Fighera, Gastón: Analista/Desarrollador Tondato, Gerónimo Luciano: Analista/Desarrollador. Recursos Físicos: Tres computadoras de escritorio que cumplen con los siguientes requisitos mínimos: Frecuencia CPU: 2,0 Ghz Frecuencia RAM: 800 Mhz Capacidad RAM: 2 GB Espacio libre en disco: 20 GB Lector de CD/DVD: En funcionamiento. Recursos lógicos: (Tres de cada uno) S.O Windows XP, JRE (Java Runtime Enviroment), IDE Eclipse, BD MySQL, DB SQL server 2000, Inmagic, KOHA, copias de la base de datos original. Asignación de recursos proyecto Dado el marco académico al que está sujeto este proyecto todos los recursos descriptos anteriormente serán utilizados conjuntamente por el equipo durante todas las etapas del desarrollo del artefacto de software.

6 Cartannilica, Alan - Fighera, Gastón - Tondato, Gerónimo NOTA: Se adjunta el mapa de actividades, y el Diagrama Gantt del proyecto software. 2. 2. Proceso de seguimiento y control del proyecto Análisis de riesgos Dadas las características de nuestro proyecto y ante la necesidad de contar con las herramientas necesarias para realizar la migración exitosamente, se detecta como riesgo la imposibilidad de adquirir un servidor de migración de datos con personal disponible en un horario apto para realizar dicha tarea, ya que es considerado una buena práctica realizar las migraciones en horarios en los que el servidor está inactivo. Otro posible riesgo es que dada la envergadura del proyecto es posible que sea aplazado o rechazado y nunca se llegue a implementar. Además se detecta como riesgo la posibilidad de un corte del suministro de energía eléctrica durante el proceso de migración. Plan de Contingencia Con respecto a los dos primeros riesgos representados en el documento de análisis de riesgos, dada la naturaleza de los mismos escapa a nuestras posibilidades brindar posibles soluciones en caso de su ocurrencia. Como plan de contingencia sugerimos a la universidad la realización de back-ups de toda la información que involucran al proyecto. 2. 3. Proceso de gestión de la calidad del software Plan de Garantía de Calidad del software Para garantizar la calidad del software producido por nuestro equipo, durante todo el ciclo de vida del mismo, se realizaran revisiones formales a todos los procesos que se

Herramienta para Migración de los datos registrados en la Biblioteca De la Universidad Nacional de Lanús (MiDaReUNLa) 7 llevaran a cabo para la construcción del software.el diseño además de contener los diagramas pertinentes asociados a esta actividad, contarán con un reporte detallado de comportamiento que se espera para el software. Como principal medida de calidad, todas las pruebas a realizar sobre la codificación serán de caja blanca, por la naturaleza de nuestro proyecto lo errores no serán admitidos, ya que una conversión equivocada de los datos podría llevar a la inutilidad de la base de datos, o lo que consideramos peor aun, que estos se migren de manera errónea. Como metodología de documentación del código generado se empleará el estándar Javadoc. @author Tag Descripción Uso @deprecated @param @return @see @throws Nombre desarrollador. del Indica que el método o clase es antigua y que no se recomienda su uso porque posiblemente desaparecerá en versiones posteriores. Definición de un parámetro de un método, es requerido para todos los parámetros del método. Informa de lo que devuelve el método, no se puede usar en constructores o métodos "void". Asocia con otro método o clase. Excepción por el método lanzada nombre_autor descripción nombre_parametro descripción descripción referencia (#método(); clase#método(); paquete.clase; paquete.clase#método()). nombre_clase descripción

8 Cartannilica, Alan - Fighera, Gastón - Tondato, Gerónimo @version Versión del método o clase. versión Tabla 2.3.1.Metodología documentación JavaDoc. Los errores identificados durante las pruebas, se registraran de la siguiente manera: Numero de Planilla Nombre quien detecto el defecto o error Estado y Versión del proyecto Identificación del defecto Resultado esperado Resultado obtenido Descripción En el caso de los errores encontrados durante el proceso de codificación se registraran de manera similar teniendo en cuenta los siguientes puntos: Numero de Planilla Nombre quien detecto el defecto o error Estado y Versión del proyecto Identificación del defecto Numero de línea de código donde se encontró el error Líneas de código antes de solucionar el error Líneas de código luego de solucionar el error Tiempo total de corrección Descripción Condición de línea base

Herramienta para Migración de los datos registrados en la Biblioteca De la Universidad Nacional de Lanús (MiDaReUNLa) 9 0001 Especificación de los casos de prueba 07/092011 Proyecto: MiDaReUnla Fecha emisión Programa: Migrator autor: C.F.T Especificación de los casos de prueba: Ítem Objetivo Acción Entrada Resultado Esperado 1 2 3 Exportar un archivo csv con el catalogo de inmagic Exportar un archivo xml con los usuarios de inmagic Transformar el csv en un mrk Exportar catalogo Exportar lista de usuarios Ejecutar el script de conversión de java Archivo csv Archivo mrk Archivo csv generado Archivo xml generado 4 Transformar el archivo xml en un archivo csv Ejecutar script de python Archivo xml Archivo csv 5 6 7 Transformar el archivo mrk en un archivo mrc Importar archivo mrc a Koha Importar archivo csv a Koha Ejecutar marcedit Archivo mrk Archivo mrc Activar la interfaz de importación Koha Archivo mrc Importación exitosa Activar la interfaz de importación Koha Archivo csv Importación exitosa Tabla 2.3.2. Especificación de los casos de Prueba.

10 Cartannilica, Alan - Fighera, Gastón - Tondato, Gerónimo Al finalizar las etapas de Requisitos y codificación, serán establecidas como líneas base, por lo cual cualquier cambio o modificación que se requiera realizar deberán ser evaluadas por el Comité de control de cambios (en este caso los mismos integrantes del grupo de desarrollo). Los pedidos contendrán los siguientes datos: Numero de pedido de cambio Responsable Motivos de cambio (error, mejora, cumplimiento de estándares) En caso de ser aprobado se agregaran los siguientes ítems: Tiempo total de cambio Que resolvió En caso de cambios de codificación se adjuntan los últimos 4 campos, correspondientes al documento de identificación de errores de codificación anteriormente descripto. Métricas de calidad Con el fin de obtener indicadores de calidad y líneas base para proyectos futuros: Se contabilizará la cantidad de horas-hombre por cada 50 lineas de código. Se medirá la cantidad de errores por cada 50 líneas de código. Se contabilizará la cantidad de horas-hombre empleadas en la corrección de errores. Se contabilizara la cantidad de defectos (fallas que surgen durante la utilización del producto terminado ) encontrados. Se contabilizará la cantidad de horas-hombre empleadas en la corrección de defectos.

Herramienta para Migración de los datos registrados en la Biblioteca De la Universidad Nacional de Lanús (MiDaReUNLa) 11 3. Proceso de Pre - Desarrollo 3. 1. Procesos de exploración de conceptos Formulación de soluciones potenciales Desarrollar el artefacto de software por nuestros propios medios con las herramientas disponibles. Comprar un software de migración de datos ya desarrollado. Estudios de viabilidad Dado las características de este proyecto y en el marco académico en el que se desarrolla nos vemos obligado a descartar la posibilidad de adquirir el software de un tercero, quedando así como único camino viable el de desarrollar por cuenta propia el artefacto de software pertinente. 3. 2. Procesos de asignación del sistema Especificación de Requisitos funcionales 1. Exportar un archivo csv con el catalogo de libros Inmagic. 2. Exportar un archivo xml con los datos de los usuarios de Inmagic. 3. Transformar el archivo exportado en el punto numero uno, en un archivo.mrk 4. Transformar el archivo exportado en el punto numero dos, en un archivo.csv. 5. Convertir el archivo.mrk en un mrc, a través del software MarcEdit.

12 Cartannilica, Alan - Fighera, Gastón - Tondato, Gerónimo 6. Importar el archivo.mrc del punto 5 (cinco) al software KOHA. 7. Importar el archivo.xml del punto 4 (cuatro) al software KOHA. Especificación de los requisitos funcionales del hardware 1. El proyecto deberá contar una computadora para el proceso de migración. 2. La computadora de migración deberá cumplir los siguientes requisitos de acuerdo al calculo de métricas, y el conjunto de requisitos mínimos para utilizar el software de las bases de datos:.cpu: AMD Phenom II X6 1055T de 2.8 ghz..ram: GSKill DDR III 2X2GB 1600 MHZ..MOTHER: ASUS M4A87TD 870..Disco Rígido: Western Digital 1 TB 64 mb de buffer Caviar Black. Descripción funcional del sistema El sistema está compuesto por tres scripts, dos de los cuales se encuentra desarrollados en python, y el tercero en java. Este último se encarga de aplicar un proceso de transformación al archivo previamente exportado (.csv), del software de administración de bibliotecas INmagic con el fin de generar un segundo archivo.mrk de texto plano, apto para ser convertido al binario.mrc, utilizando el software MarcEdit, siendo este importable a través de la interfaz del software KOHA. El primer script de python es el encargado de tomar el archivo.xml, y distinguir entre nombres y los apellidos para generar un nuevo archivo.xml donde estos estén discriminados. Este es procesado por el segundo script de python el cual se encarga de generar el archivo.csv con los datos de los usuarios para luego ser importado por KOHA.

Herramienta para Migración de los datos registrados en la Biblioteca De la Universidad Nacional de Lanús (MiDaReUNLa) 13 Arquitectura del sistema La arquitectura del artefacto software será representada a través de un diagrama de componentes, en el cual el servidor en el que se encuentra instalado el software Inmagic y la base de datos SQL Server, nos proporcionara un archivo.csv y un.xml, que es la entrada esperada por el sistema de migración MiDaRe UNLa, para finalmente importar el.csv y el.mrc al servidor con software KOHA. 4. Procesos Orientados al desarrollo del software 4. 1. Proceso de requisitos Especificación de requisitos del software Convertir el archivo exportado en formato.csv, en un archivo.mrk apto para ser utilizado en el software MarcEdit. Luego, transformar el archivo.xml exportado de InMagic en un archivo.csv. Por último convertir el archivo.mrk, en un.mrc que puede ser importado por el software KOHA. Requisitos del interfaz con otro software La comunicación entre las distintos sistemas de administración de biblioteca se dará a través de archivos.csv,.xml,.mrk y.mrc.

14 Cartannilica, Alan - Fighera, Gastón - Tondato, Gerónimo 4. 2. Proceso de diseño Descripción del diseño software Para la tarea de diseño del software que nos compete, dado que hemos elegido un ciclo de vida en cascada y siguiendo los mecanismos que corresponden al diseño estructura decidimos utilizar como herramientas los diagramas que se describen a continuación considerando que estos satisfacen plenamente las necesidades de diseño del artefacto de software a producir: Diagrama de contexto. Tabla de eventos. Diagrama de flujo de datos. Diagrama de entidad relación (de la base de datos actual). Diagrama de componentes. Descripción de los algoritmos. Descripción de la arquitectura del software La figura 4. 2. 1. representa la arquitectura del artefacto software a construir. La misma cuenta con el software Inmagic sobre una estructura de base de datos SQL Server de la cual se va a exportar un archivos.csv y.xml. Ambos serán procesados por los scripts dando como resultado un archivo.csv y un archivo.mrk. Este último será convertido a.mrc a través del software MarcEdit. Para finalizar, ambos archivos serán importados a KOHA a través de la interfaz que este brinda.

Herramienta para Migración de los datos registrados en la Biblioteca De la Universidad Nacional de Lanús (MiDaReUNLa) 15 Figura 4. 2. 1. Descripción de la Arquitectura del Software.

16 Cartannilica, Alan - Fighera, Gastón - Tondato, Gerónimo Diagrama de Contexto (DC) Figura 4. 2. 2. Diagrama de Contexto referente a las descripción del flujo de la información.

Herramienta para Migración de los datos registrados en la Biblioteca De la Universidad Nacional de Lanús (MiDaReUNLa) 17 Diagrama de Flujo de Datos (DFD) Figura 4. 2. 3. Diagrama de flujo de datos referente a las descripción del flujo de la información.

18 Cartannilica, Alan - Fighera, Gastón - Tondato, Gerónimo Diagrama de Clases Figura 4. 2. 4. Diagrama de clases del software para la migración de datos.

Herramienta para Migración de los datos registrados en la Biblioteca De la Universidad Nacional de Lanús (MiDaReUNLa) 19 Descripción de la base de datos La descripción de la base de datos al momento de comenzar el proyecto se encuentra representada en la figura 4. 2. 5. La base de datos con estructura de SQL Server no presenta ningún tipo de relación entre las distintas entidades, ya que el software Inmagic lo permite. La misma cuenta con las siguientes entidades. Usuario: Solicita el préstamo o reserva de uno o varios libros. Cuenta con los atributos nombre, teléfono, dirección, y DNI. Reserva: Contiene el id de la reserva, la fecha, hora, el libro, y el usuario que reservo ese libro. Proveedor: Contiene el id del proveedor, el nombre, teléfono, dirección y se relaciona con la manera de adquirir los libros. Préstamo: Contiene el id del préstamo, fecha, hora de inicio de préstamo y fin de préstamo, y que usuario se llevó el libro, y que libro se llevó. Ofertas: Contiene el id de oferta, sobre qué libro es la oferta, y su precio, y contiene la fecha de inicio y fin de la oferta. Existencia: El atributo libro disponibles, nos informa si se encuentra o no disponible el libro en la biblioteca. Catalogo: Informa sobre qué tema trata el libro, referenciándose a qué libro. Adquisición: Contiene qué libro se adquirió y su fecha e id de adquisición. Libro: Contiene el id del libro, el tema, el título, el autor, y el año de emisión.

20 Cartannilica, Alan - Fighera, Gastón - Tondato, Gerónimo Figura 4. 2. 5. Representación del estado de la Base de datos al comenzar el proyecto del software Inmagic (no presenta relaciones).

Herramienta para Migración de los datos registrados en la Biblioteca De la Universidad Nacional de Lanús (MiDaReUNLa) 21 Descripción de los algoritmos Paso 1 Script Java: 1. Leer archivo.csv 2. Filtrar Campos 3. Generar plantilla en formato.mrk 4. Imprimir plantilla en un archivo de texto plano. Paso 2 Script Python: 5. Leer archivo.xml 6. Discriminar Nombre y Apellido. 7. Imprimir archivo.xml modificado Paso 3 Script Python 2: 8. Leer archivo.xml 9. Adaptar el archivo a formato.csv 10. Imprimir resultado en archivo.csv

22 Cartannilica, Alan - Fighera, Gastón - Tondato, Gerónimo 4. 3. Proceso de Implementación Datos para las pruebas

Herramienta para Migración de los datos registrados en la Biblioteca De la Universidad Nacional de Lanús (MiDaReUNLa) 23

24 Cartannilica, Alan - Fighera, Gastón - Tondato, Gerónimo

Herramienta para Migración de los datos registrados en la Biblioteca De la Universidad Nacional de Lanús (MiDaReUNLa) 25

26 Cartannilica, Alan - Fighera, Gastón - Tondato, Gerónimo

Herramienta para Migración de los datos registrados en la Biblioteca De la Universidad Nacional de Lanús (MiDaReUNLa) 27

28 Cartannilica, Alan - Fighera, Gastón - Tondato, Gerónimo

Herramienta para Migración de los datos registrados en la Biblioteca De la Universidad Nacional de Lanús (MiDaReUNLa) 29

30 Cartannilica, Alan - Fighera, Gastón - Tondato, Gerónimo

Herramienta para Migración de los datos registrados en la Biblioteca De la Universidad Nacional de Lanús (MiDaReUNLa) 31 Plan de integración El plan de integración no se llevará a cabo durante el proceso de construcción del artefacto software debido a que su funcionamiento es independiente al software In- Magic y al KOHA, a pesar de que su entrada y salida se relacione con los mismos. 5. Procesos de Post Desarrollo 5. 1. Proceso de Instalación Plan de instalación del Software 1. Instalar el Software In-Magic 1. 1. Tener instalado el SQL Server 2000. 1. 2. Ejecutar el instalador del software In-Magic. 1. 3. Seleccionar la opción Install CS/Textworks. 1. 4. Seleccionar la carpeta donde se va a instalar el software. 1. 5. Seleccionar I already have MSDE 2000 installed. 1. 6. Instalar. 2. Instalar el Software KOHA 2. 1. Tener instalado el sistema operativo Ubuntu 9.4. 2. 2. Tener instalador el Apache Server. 2. 3. Descargar y ejecutar la serie de comandos para instalar el KOHA. 3. Instalar Java Deveplment Kit (JDK) 4. Instalar el Software Eclipse 5. Montar el código fuente en el Software Eclipse 6. Instalar MarcEdit 7. Montar el catálogo de la Base de Datos en el motor MySQL

32 Cartannilica, Alan - Fighera, Gastón - Tondato, Gerónimo 6. Procesos Integrales del Proyecto 6. 1. Plan de verificación y validación Se utilizará el set de datos de pruebas para generar los archivos de datos correspondientes que serán insertados al sistema KOHA a través de la interfaz de importación que el mismo provee. Verificando de esta manera la correcta integración de los datos a través del artefacto de software. Abarca la planificación y la realización de todas las tareas de verificación, incluyendo pruebas de verificación, revisiones y auditorias, y todas las tareas de validación, incluyendo pruebas de validación, que se ejecutan durante el ciclo de vida del software para asegurar que se satisfacen todos los requisitos del software. 6. 2. Plan de Pruebas En primera instancia haremos una prueba del software utilizando los datos usados en la documentación, de esta manera podremos verificar los resultados son iguales. El sistema está compuesto por tres scripts, dos de los cuales se encuentra desarrollados en python, y el tercero en java. Este último se encarga de aplicar un proceso de transformación al archivo previamente exportado (.csv), del software de administración de bibliotecas INmagic con el fin de generar un segundo archivo.mrk de texto plano, apto para ser convertido al binario.mrc, utilizando el software MarcEdit, siendo este importable a través de la interfaz del software KOHA. El primer script de python es el encargado de tomar el archivo.xml, y distinguir entre nombres y los apellidos para generar un nuevo archivo.xml donde estos estén discriminados. Este es procesado por el segundo script de python el cual se encarga de generar el archivo.csv con los datos de los usuarios para luego ser importado por KOHA.

Herramienta para Migración de los datos registrados en la Biblioteca De la Universidad Nacional de Lanús (MiDaReUNLa) 33 Anexo: Cómo Utilizar los Scripts de conversión? 1. Exportación del catálogo de datos de la Biblioteca almacenados en el software In-Magic. 1. 1. Ejecutar el Script GeneradorMRK sobre Eclipse, seleccionando la dirección del archivo.csv 1. 2. Se generará un archivo llamado catalogo.mrk que se encuentra dentro de la carpeta raíz del proyecto de Java. 2. Exportación del catálogo de usuarios de la Biblioteca almacenados en el software In-Magic. 2. 1. Ejecutar el Script de Python XMLGenerator.py, que va a crear el archivo usuarios.xml. 2. 2. Ejecutar el Script