Todas las entradas de Yoelnis A. Gómez Peña

Acerca de Yoelnis A. Gómez Peña

Universidad de las Ciencias Informáticas-Facultad regional de Granma. Ave. Camilo Cienfuegos s/n,Manzanillo, Granma, Cuba.

01Ene/15

Procedimiento para la realización de pruebas de unidad

Procedimiento para la realización de pruebas de unidad

Resumen

El factor fundamental para el éxito en la producción de software es la calidad y para ello es necesario tener en cuenta una serie de aspectos para que la misma sea óptima. La obtención de un software con calidad implica la utilización de metodologías o procedimientos estándares para el análisis, diseño, programación y prueba del software, que permitan uniformar la filosofía de trabajo en aras de lograr una mayor confiabilidad, mantenibilidad y facilidad de prueba, a la vez que eleven la productividad tanto para la labor de desarrollo como para el control de la calidad del software.

Antes de que el software se le entregue al usuario final es necesario realizar pruebas con el objetivo de detectar errores de la aplicación y la documentación; este proceso resulta de gran importancia ya que da una medida de la calidad del producto siempre que se lleve a cabo de forma apropiada. El presente trabajo se centra en la aplicación de un procedimiento para realizar pruebas de unidad con el objetivo de lograr el nivel de calidad requerido y poder registrar la documentación con los resultados de cada una de las pruebas de unidad realizadas al producto.

PALABRAS CLAVES: Pruebas de unidad, procedimiento de pruebas, calidad de software.

Guidelines for preparing articles for Cuban Journal of Engineering

Abstract

The key factor for success in software production is quality and this requires taking into account a number of areas so that it can be optimal. Obtaining a quality software involves the use of methodologies and standard procedures for analysis, design, programming and testing software, enabling uniform working philosophy in order to achieve greater reliability, maintainability and testability, the time to raise productivity for both development work and quality control software.

Before the software is delivered to the end user a testing is required in order to detect errors in the application and documentation, this process is of great importance as it gives a measure of the provided product quality, only if it is properly done. This work focuses on the implementation of a procedure for testing unit in order to achieve the level of required quality and documentation to record the results of each of the unit tests conducted in this product.

KEYWORDS: Unit testing, testing procedure, software quality.

Introducción

Una de las fases más importantes del ciclo de vida antes de entregar un software para su explotación es la fase de pruebas. Se estima que la mitad del esfuerzo de desarrollo de un programa (tanto en tiempo como en gastos) se consume en esta fase [1], de ahí la importancia de ésta. Las pruebas son de suma importancia para el software y tienen sus implicaciones en la calidad de éste, citando a Deutsch: “El desarrollo de sistemas de software implica una serie de actividades de producción en las que las posibilidades de que aparezca el fallo humano son enormes. Debido a la imposibilidad humana de trabajar y comunicarse de forma perfecta, el desarrollo de software ha de ir acompañado de una actividad que garantice la calidad” [2]. Uno de los pasos para garantizar que el producto final tenga la menor cantidad de errores posibles es el desarrollo de un correcto procedimiento de pruebas de unidad. Para ello se utiliza la metodología RUP, Proceso Unificado de Desarrollo de Software, para lograr una mejor organización en el trabajo. Estas pruebas tienen un impacto importante en el código y la calidad del producto final, por esta razón se ofrece una propuesta de solución para garantizar la realización de este tipo de pruebas.

Desarrollo

1. Procedimiento para realizar pruebas de unidad

La construcción de un sistema software tiene como objetivo satisfacer una necesidad planteada por el usuario. Para asegurar que se han alcanzado los niveles de calidad acordados es necesario evaluar el producto software a medida que se va construyendo. Por lo tanto se hace necesario llevar a cabo, en paralelo al proceso de desarrollo, un proceso de evaluación o comprobación de los distintos productos o modelos que se van generando [3].

1.1 Descripción

El procedimiento para realizar pruebas de unidad definirá de forma detallada los pasos para llevar a cabo estas pruebas. Analiza en detalle cada una de las fases que forma este procedimiento, describiendo, las actividades a realizar y la documentación de entrada y salida que las conforman.

1.2 Alcance

Este procedimiento está dirigido a realizar las pruebas de unidad. ¿Qué se va a probar? Las funciones individuales o métodos: se probarán las entradas y las salidas y se comprobará que los valores obtenidos son los esperados. Es decir, se prueba el código aislado, independiente del resto del sistema

1.3 Objetivos

Este procedimiento describe los objetivos de la realización de las pruebas de unidad, el enfoque a seguir en la realización de las mismas por fases, y una descripción detallada de éstas. Las pruebas unitarias desarrolladas en este procedimiento tienen como objetivo aislar cada parte del programa y mostrar que las partes individuales son correctas. Son fragmentos de unidades estructurales del programa encargados de una tarea en específico. El objetivo principal sería producir las piezas de código de la manera más eficiente y eficaz posible generando pruebas de unidad para las mismas que aseguren su correcto comportamiento.

1.4 Fases del Procedimiento

El presente procedimiento de pruebas de unidad se divide en las siguientes fases: Planificación de las Pruebas – PP, Diseño de las Pruebas – DP, Ejecución de las Pruebas – EP.

Fig1

Fig 1: Fases del procedimiento de la realización de pruebas de unidad.

Para describir este procedimiento, los siguientes epígrafes se dedican a cada fase del proyecto de pruebas, describiendo en cada una las actividades a realizar y las salidas que se generarán.

PP1. Fase de Planificación

En esta fase se planificarán las pruebas unitarias que se le realizarán a la aplicación, así como los roles y los recursos necesarios para realizar este procedimiento. Las actividades de esta fase son:

Fig2

Fig 2: Actividades de la Fase de Planificación de Pruebas.

La documentación de salida es la planificación del proyecto de pruebas que asegure su ejecución en el plazo estimado.

Tabla 1: Salidas de la Fase de Planificación de Pruebas de Unidad.

FaseSalidas
PlanificaciónPlan de Pruebas (.doc)

-Alcance y Estrategia de las Pruebas.

-Roles y Responsabilidades.

-Recursos Necesarios y Herramientas a utilizar.

Análisis de la Documentación: El análisis de la documentación tiene como objetivo la revisión de toda la documentación recibida como entrada para la fase de planificación. Es necesario que se estudie toda la documentación, incluyendo las plantillas elaboradas en el proyecto que se deben conocer antes de realizar las pruebas. Además se debe estudiar el software y el hardware que se vaya a utilizar para la realización de las pruebas, así como todos los detalles de lo que son las pruebas de unidad.

Tabla 2: Descripción de la actividad Análisis de la Documentación.

PP1.1 – Análisis de la Documentación
Objetivo: Estudio de la documentación que sirva de partida para realizar las pruebas unitarias.
Entradas:

Glosario de términos.

Documento de especificación de requerimientos.

Requerimientos mínimos de hardware y software para realizar las pruebas.

Plantilla de Descripción de los Casos de Uso.

Observaciones: Esta actividad debe realizarse al inicio de la fase de planificación de las pruebas.

Roles y Responsabilidades: Durante el procedimiento de pruebas de unidad es necesario asumir 4 roles fundamentales, en la aplicación del procedimiento, se deben especificar todas las responsabilidades de cada trabajador. En la siguiente figura se muestran la relación de los trabajadores con las actividades más importantes a desarrollar.

Fig3

Fig 3: Relación de los roles con sus principales actividades.

Recursos Necesarios: En este paso se especifica el escenario en el que se realizarán las pruebas unitarias, realizando especificaciones de hardware y de software, recogiéndose en una tabla que será llenada en la aplicación del procedimiento.

Definir Estrategia: El objetivo de esta tarea es detallar la estrategia a seguir a lo largo del procedimiento de pruebas de unidad. En este epígrafe se describe el flujo de trabajo que será implementado durante todo el período de realización de las pruebas unitarias, de igual forma se detallan los pasos que serán realizados.

Descripción del flujo de trabajo: El flujo de trabajo se inicia cuando el diseñador de prueba comienza a describir los casos de prueba para su posterior utilización. Se implementan estas pruebas con la ayuda de los casos de prueba. Luego si todas las condiciones están creadas se pasa a la 1ra iteración de pruebas, se ejecutan las pruebas. En la medida que detecten errores, estos serán anotados por el probador que es quien ejecuta las pruebas, y corregidos por el ingeniero de pruebas. En la siguiente figura se muestra el flujo de trabajo de forma general:

Fig4

Fig 4: Descripción del Flujo de Trabajo.

Plan de Pruebas: El documento más importante de la fase de planificación es el Plan de Pruebas, pues es en esta fase donde se genera una primera versión de este plan. Para el diseño del Plan de Pruebas se va a utilizar la Plantilla Plan de Pruebas derivada de la plantilla Plan de Pruebas de RUP. El Plan de Pruebas identificará el propósito, alcance, los elementos de prueba y los recursos necesarios para la ejecución de las pruebas, se va a definir y recomendar la estrategia de prueba [4]. Como se puede apreciar, el Plan de Pruebas de contiene las actividades de la fase de planificación.

Tabla 4: Descripción del documento Plan de Pruebas.

PP1.5 – Plan de Pruebas
Objetivo: Elaborar una primera versión del Plan de Pruebas.
EntradasTareasSalidas
Especificación de Requisitos (.doc)

Prototipo de la Interfaz (.html)

-Determinar la estrategia de las pruebas.

-Especificar herramientas a utilizar.

-Detallar el entorno en que se va a probar.

Documento de Plan de Pruebas (.doc)
Observaciones: Aunque en esta fase se elabora el Plan de Pruebas, éste puede ser modificado a lo largo de la realización de pruebas.

DP1. Fase de Diseño

La fase de diseño comprende la especificación de casos de prueba necesarios para completar el Plan de Pruebas definido en la fase de planificación de pruebas [5]. El siguiente gráfico resume las actividades de esta fase:

Fig5

Fig 5: Actividades Fase de Diseño de Pruebas.

Cada caso de prueba describe cada uno de los pasos a ejecutar para comprobar el correcto funcionamiento de cada una de las funciones o métodos y el cumplimiento de la lógica de negocio.

Tabla 5: Entradas y Salidas de la Fase de Diseño de pruebas.

FASEENTRADASSALIDAS
Diseño-Descripción de los Casos de uso del sistema.

-Plan de Pruebas.

-Especificación de Requisitos de Pruebas.

Plantilla de Casos de Prueba (.doc)

Plan de Pruebas (.doc)(actualizado)

Especificación de casos de prueba: En esta actividad se define el nivel más bajo de cada una de las funcionalidades a probar dentro del Plan de Pruebas.

Tabla 6: Descripción de la actividad Especificación de casos de prueba.

DP1.1 -Especificación de casos de prueba
Objetivo: Se especifican los casos de prueba y las descripciones de los casos de prueba.
EntradasTareasSalidas
Plan de Pruebas

(.doc)

Especificación de Requisitos de Pruebas (.doc).

-Especificar los casos de prueba.

-Describir pasos para automatizar un Caso de Prueba automático.

-Actualizar el Plan de Pruebas.

Plantilla de Casos de Prueba de Unidad (.doc)

Plan de Pruebas Actualizado (.doc).

Observaciones:

A continuación se detalla la información correspondiente al diseño de casos de prueba propuesto y se describe la plantilla del diseño de los casos de prueba.

a. Descripción de la Plantilla Casos de Prueba de Unidad: En muchos proyectos no se cuenta con una Plantilla de Casos de Prueba de Unidad, por lo que en este epígrafe se propone y se describe, para que pueda ser utilizada en el desarrollo de este procedimiento y en cualquier proyecto que lo necesite. La plantilla tiene en su encabezado el nombre del proyecto, del módulo que se va a probar, la versión y el tipo de prueba que se realiza. Luego se detallan el nombre de las funcionalidades que se van a probar del módulo escogido, así como una pequeña descripción de éstas. En la siguiente tabla se detallan los casos de prueba para las funcionalidades descritas. Se recogen los resultados obtenidos después de aplicar aquellos métodos que se utilicen, en dependencia de la herramienta que se esté utilizando para comprobar el correcto funcionamiento de las funcionalidades a probar.

Como parte de la realización del caso de prueba se toma en cuenta en el primer campo (Funcionalidad), el cual corresponde al nombre de la funcionalidad que será comprobada, el segundo (Método utilizado), el tercer campo (Recibe) contiene los parámetros que recibe la funcionalidad al ser comprobada, el cuarto es el resultado que se espera que devuelva el método, en el quinto se escribe el resultado que se espera devuelva la prueba luego de ser ejecutada y la última columna es el valor resultado real que obtuvo finalmente dicha prueba. El resultado es satisfactorio si coinciden los resultados reales de las pruebas con los esperados, en caso de no coincidir es detectado un error. En la aplicación del procedimiento se llenará esta plantilla.

b. Implementar pruebas automáticas: A continuación se explica cómo implementar las pruebas de unidad. En primer lugar se piensa en todos los posibles casos de funcionamiento del método que se quiere probar y se elaboran una serie de entradas de prueba junto con el resultado esperado para cada una [6]. Si se realizan pruebas de unidad automáticamente en dependencia del framework con el que se esté trabajando se realizarán estas pruebas con el código y el formato correspondiente.

EP1. Fase de Ejecución

Se realiza la ejecución de las pruebas implementadas, con la ayuda de los casos de prueba que se hayan identificado anteriormente. El siguiente gráfico muestra las actividades que se deben realizar en esta fase:

Fig6

Fig 6: Actividades Fase de Ejecución de Pruebas.

Estas pruebas pueden ser implementadas y ejecutadas desde la línea de comandos o mediante un Entorno de Desarrollo Integrado (IDE). Para ejecutarse las pruebas unitarias de forma automática, se hace uso de los casos de prueba diseñados. El probador ejecuta las pruebas, actualiza la Plantilla de Casos de Prueba con los resultados de éstas y al mismo tiempo va registrando los fallos que puedan surgir en la ejecución de las pruebas, luego el ingeniero de pruebas corrige los errores encontrados en el código y se vuelven a ejecutar las pruebas hasta no encontrar fallos.

Tabla 8: Entradas y Salidas de la Fase de Ejecución de Pruebas de Unidad.

FASEENTRADASSALIDAS
Ejecución-Especificación de casos de prueba (.doc)

-Plan de Pruebas(.doc)

-Resultado pruebas unitarias (.doc)

Plantilla de Casos de Prueba de Unidad (.doc) (actualizada)

Ejecución de los casos de prueba: Para esta tarea, se recomienda mantener un repositorio de las pruebas implementadas para los casos de pruebas automatizados, a fin de mantener una estructura de almacenamiento de los mismos que permita su reutilización. Para cada uno de los casos de prueba se ejecutan y se registran los resultados de los mismos en la Plantilla de Casos de Prueba de Unidad.

Tabla 9: Descripción de la actividad Ejecución de los casos de prueba.

EP1.1Ejecución de los casos de prueba
Objetivo: Ejecutar los casos de prueba, registrando los resultados en la Plantilla de Casos de Prueba de Unidad.
EntradasTareasSalidas
Especificación de casos de prueba (.doc)

Plan de Pruebas (.doc)

Resultado pruebas unitarias (.doc)

-Ejecutar los casos de prueba especificados.

-Registrar los resultados en Plantilla de Casos de Prueba de Unidad.

Plantilla de Casos de Prueba de Unidad (.doc)

(actualizada con los resultados obtenidos)

Observaciones:

Evaluación de los resultados: Una vez obtenidos los resultados después de ejecutadas las pruebas, el siguiente paso es evaluar la información obtenida en los mismos y si se deben ejecutar nuevamente las pruebas. El objetivo de esta evaluación es la obtención de errores, conclusiones y recomendaciones tras las pruebas.

Tabla 10: Descripción de la actividad Evaluación de Resultados.

EP1.2Evaluación de los resultados
Objetivo: Evaluar los resultados obtenidos y analizar los errores del código encontrados.
EntradasTareasSalidas
Plantilla de Casos de Prueba de Unidad (.doc).-Analizar los resultados obtenidos al ser ejecutadas las pruebas.

-Actualizar los casos de prueba de unidad.

Plantilla de Casos de Prueba de Unidad (.doc)

(Actualizada con los resultados obtenidos)

Observaciones: Se debe tomar la decisión de si realizar una nueva iteración de pruebas o no.

Para mostrar los resultados de las pruebas unitarias realizadas se detallan los errores los cuales son recogidos en una tabla que contiene los reporte de los errores encontrados. La descripción de los errores debe ser clara y precisa. Los errores según la prioridad se clasifican en: crítica (Error que necesita ser solucionado inmediatamente), alta, media y baja. Los reportes de los errores encontrados de las pruebas son recogidos en la Plantilla de Casos de Prueba de Unidad.

Resultados

2. Aplicación del procedimiento

El procedimiento descrito anteriormente fue aplicado al subsistema Mecanismo de Control de Acceso y Autenticación, perteneciente al proyecto Sistema Único de Aduanas, el cual se desarrolla en la Universidad de las Ciencias Informáticas. Este subsistema se encarga de gestionar todo lo referente a la autenticación y control de acceso de los usuarios de la entidad y está compuesto por cinco módulos. Se realizaron pruebas de unidad de forma automática utilizando el framework Symfony. Se realizan este tipo de pruebas a 3 módulos del subsistema Mecanismo de Control de Acceso y Autenticación, los cuales son: suAdminDomain que se encarga de gestionar todo lo referente a los dominios, suAdminRole, el cual gestiona a los roles y suAdminUser que gestiona los usuarios o grupos.

2.1 Fases a desarrollar

PP1. Aplicación Fase de Planificación

Análisis de la Documentación: El subsistema Mecanismo de Control de Acceso y Autenticación, donde se van a realizar las pruebas, tiene documentados los siguientes artefactos dentro del expediente del proyecto, los cuales fueron estudiados: Documento de especificación de requisitos, Especificación de los casos de uso y Glosario de términos. A continuación se muestran los roles con todas las responsabilidades a desarrollar para la realización de las pruebas de unidad, en este caso al Subsistema Mecanismo de Control de Acceso y Autenticación.

Tabla 12: Descripción de la actividad Roles y Responsabilidades.

Recursos Humanos
RolesResponsabilidades Específicas
Jefe de Pruebas– Analizar la documentación.

– Planificar y decidir objetivos de las pruebas.

– Realizar el Plan de Pruebas.

Diseñador de Pruebas– Identificar las herramientas.

– Identificar, priorizar, seleccionar y describir los Casos de Prueba.

Ingeniero de pruebas– Implementar las pruebas automáticas

– Corregir los errores.

Probador– Preparar y ejecutar las Pruebas.

– Verificar la ejecución de las pruebas.

– Evaluar los resultados de las pruebas y conformar documentación.

Recursos Necesarios: En la aplicación del procedimiento para realizar pruebas de unidad se identifica un entorno con las siguientes características:

Tabla 13: Tabla de los Recursos Necesarios.

Recursos del Sistema
RecursosDescripción
Servidor de Base de Datos.– Características del software: Oracle Standard Edition. LINUX.

– Características de hardware: 2 GB de RAM 80 GB de capacidad.

PC Cliente para pruebas.– Características de hardware: 1 GB de RAM y 160 GB en disco duro.

– Características de software: Instalado symfony-1.2.8.

DP2. Aplicación Fase de Diseño

En la fase de diseño se elaboraron casos de prueba para las distintas funcionalidades de 3 de los módulos del sistema Mecanismo de Control de Acceso y Autenticación. Se mostrará a continuación un caso de prueba de uno de los módulos, para que sirva de ejemplo.

Descripción de la Plantilla Casos de Prueba de Unidad: En este paso se prosigue a llenar los datos solicitados en la Plantilla Casos de Prueba de Unidad para el sistema Mecanismo de Control de Acceso y Autenticación. Ver Anexo 1: Caso de prueba del módulo suAdminDomain.

Implementar pruebas automáticas: El Ingeniero de Pruebas es el encargado de implementar las pruebas de unidad de forma automática, con la ayuda de los casos de prueba descritos en el epígrafe anterior. Ver Anexo 2: Vista de las pruebas realizadas a métodos del módulo suAdminDomain.

EP3. Aplicación Fase Ejecución de las pruebas

Ejecución de las pruebas: Se procede a la ejecución de las pruebas, una vez que esté todo listo y bien definido y el probador esté capacitado para proceder con las mismas. En esta fase se realiza la actividad Evaluación de los Resultados, la cual se detalla a continuación.

Evaluación de los resultados: Se le realizaron pruebas a la mayoría de las funcionalidades de los módulos escogidos. Los casos de prueba que se habían definido anteriormente en la Plantilla de Casos de Prueba de Unidad fueron ejecutados satisfactoriamente siguiendo la estrategia que se había planteado. Los distintos errores encontrados fueron clasificados según su prioridad y a través del mecanismo correspondiente fueron informados a los responsables para su corrección. Ver Anexo 3: Reporte errores del módulo suAdminDomain. Luego de recoger los reportes de las pruebas realizadas a los 3 módulos, los errores más frecuentes fueron:

Problemas en las funcionalidades modificar (modificarDominio, modificarGrupo y modificarUsuario) de los 3 módulos que se probaron, porque permite modificar el nombre por una cadena de texto vacía.

Problemas en las funcionalidades buscarDominioPorNombre y buscarGrupoPorNombre, pues donde se esperaba que devolviera un tipo de dato fecha mientras lo que realmente devuelve es un string. Este error es difícil de detectar en otros tipos de pruebas, sin embargo, con la implementación de esta se pudo detectar fácilmente.

Problemas con la funcionalidad cambiarContrasena, pues permite cambiar la contraseña por una cadena de caracteres muy larga y también por una demasiado corta.

Se debe añadir que a estos módulos se le realizaron varios tipos de pruebas antes de aplicarle el procedimiento y a pesar de esto luego de haber ejecutado las 26 pruebas que fueron implementadas en este trabajo, se encontraron 6 funcionalidades con problemas, lo cual representa el 23% del total de las pruebas.

Conclusiones

En este trabajo se realizó la descripción del procedimiento de pruebas de unidad. Este permite una organización del trabajo además de la obtención de resultados satisfactorios para la mejora de la calidad. Además se aplicó el procedimiento al proyecto Sistema Único de Aduanas y dentro de éste al subsistema Mecanismo de Control de Acceso y Autenticación, con el objetivo de demostrar su validez. Esto permitió detectar gran cantidad de errores en código que se programado. Se espera que este trabajo pueda ser utilizado en los distintos proyectos, partiendo de que no existe una iniciativa precedente a la que se expone en este trabajo para la aplicación de pruebas de unidad, ni la existencia de plantillas como la que se propone para la documentación de los casos de prueba de unidad, incluyendo los resultados obtenidos.

Referencias Bibliográficas:

[1] cited; Available from: http://www.lab.dit.upm.es/~lprg/material/apuntes/pruebas/testing.htm

[2] Pressman, R.S., Un enfoque práctico. 2005.

[3] Myers, The art of software testing. John Wiley & Sons ed. 1979.

[4] Ivar Jacobson, G.B., James Rumbaugh, El proceso unificado de desarrollo del software. 2000, Madrid España: Rational Software Corporation

[5] Perry, W. ( 2000). Effective Methods for Software Testing. Segunda edición, Wiley.

[6] Fabien Potencier, F.Z., Symfony la guía definitiva. 2008.

Anexos

Anexo 1: Caso de prueba del módulo suAdminDomain.

Caso de prueba 1: Nombre Módulo: suAdminDomain, Versión: 1.0, Tipo de prueba: Prueba de Unidad.

Funcionalidades a ProbarDescripción
modificarDominioModifica o Actualiza un dominio en la Base de Datos (BD).
obtenerDominiosRetorna un arreglo de Dominios.
buscarDominioPorNombreVerifica que se encuentre en la BD el dominio del nombre especificado.
eliminarDominioDeshabilita el Dominio en la Base de Datos.
insertarDominioInserta un dominio en la Base de Datos.
existeDominioVerifica que exista el dominio especificado.

Casos de Prueba de Unidad

Código del Caso de Prueba: CPU1
Iteración: 1era
Descripción de la prueba: Se realizan pruebas de unidad a las principales funcionalidades del módulo suAdminDomain.
Nombre del encargado: Elizabeth Quintas Sánchez
FuncionalidadMétodo utilizadoRecibeResultado Esperado del métodoResultado Esperado de la pruebaResultado Real de la prueba
SuAdminDomaincan_ok‘toJson’‘toJson’

ok

ok

modificarDominiois1, ”false

not ok

ok

obtenerDominiosisa_ok‘array’

ok

ok

buscarDominioPorNombreisa_ok‘Dominio 1’‘SuAdminGrupo’

ok

ok

buscarDominioPorNombrecmp_ok‘Dominio 1’‘Dominio 1’

ok

ok

buscarDominioPorNombreis‘Dominio 1’true

ok

ok

buscarDominioPorNombreisa_ok‘Dominio 2’‘TIMESTAMP’

ok

not ok

eliminarDominiois1true

ok

ok

insertarDominiois‘Dominio 10’true

ok

ok

existeDominiois‘Dominio 3’true

not ok

not ok

Anexo 2: Vista de las pruebas realizadas a métodos del módulo suAdminDomain.

Fig7

Anexo 3: Reporte errores del módulo suAdminDomain.

Reporte de Prueba Nro. 1
Errores Encontrados: 2
Id Caso de Prueba: CPU1
Funcionalidad ProbadaError EncontradoClasificación del errorObservación
modificar DominioLa funcionalidad permite modificar el dominio cambiándole el nombre por una cadena de texto vacía.MediaEl nombre del dominio no puede ser una cadena de texto vacía.
buscar Dominio Por NombreEl tipo de dato que devuelve esta funcionalidad es string, cuando debería ser de tipo ‘TIMESTAMP’.BajaPara probar esta funcionalidad se realizó llamando al método getCreateAt.’TIMESTAMP’ es del tipo Fecha.
01Ene/15

Portal la Academia Profesional de Artes Plásticas

Portal la Academia Profesional de Artes Plásticas

RESUMEN

El presente trabajo trata sobre la aplicación Web para la gestión de la información de la Academia Profesional de Artes Plásticas Oswaldo Guayasamín de Bayamo, exponiendose el mismo como una necesidad para esta entidad. Se realizó un estudio de las herramientas y metodologías informáticas a utilizar para el desarrollo de la aplicación. Se analizó además el negocio de los procesos que se llevan dentro de la institución para una mayor comprensión del trabajo que realizan. Conjuntamente se implementaron los requerimientos y servicios acordados, mediante el diseño del sistema. Para la realización del portal se utilizó el Sistema de Administración de Contenido (CMS, por sus siglas en inglés) Drupal.

Palabras clave: Artes Plásticas, Aplicación web, Drupal.

ABSTRACT

This paper deals with the Web application for managing the information of the Academy of Fine Arts Oswaldo Guayasamín in Bayamo, exposing himself as a need for this entity. A study of the computer tools and methodologies to be used for application development was carried out. It was also analyzed the business processes that are carried within the institution for a greater understanding the work. In addition it were deployed the requirements and services agreed, by the design of the system. For the realization of the portal it was used the Content Management System (CMS, for its acronym in English) Drupal.

Keywords: Arts, Web application, Drupal.

INTRODUCCIÓN

El protagonismo que ha tenido la vanguardia de nuestros artistas plásticos en la vida política y social del país en los últimos tiempos, ha contribuido a difundir en amplias capas de la población, códigos y referencias en este campo del más alto nivel. Se evidencia un crecimiento en lo que a exposiciones y visitantes se refiere: en ello repercute la utilización de espacios alternativos no sólo en instituciones culturales, sino en escuelas y centros de trabajo, además del funcionamiento de las galerías de arte existentes en los territorios. (Ministerio de Cultura de la República de Cuba 2011)

La Academia Profesional de Artes Plásticas Oswaldo Guayasamín de Bayamo tiene como objetivo fundamental: formar Técnicos Medio en Artes Plásticas, capaces de llevar las diferentes manifestaciones de la cultura a cada rincón de de la provincia Granma. Su visión como una institución cultural es: ser cada vez más reconocidos, como una organización generadora, promotora y defensora de la identidad y cultura nacional

(Yoelnis A. Gómez 2011). En este esfuerzo se plantea la necesidad de llegar a cada rincón de la provincia por todos los medios posibles, así como de tener un espacio en la red donde pueda promocionar sus actividades con la comunidad, eventos realizados por la entidad y publicar avisos de interés para la población y aspirantes a matricular en la Academia. Por lo que se firma un convenio con la Facultad Regional de Granma de la Universidad de las Ciencias Informáticas (FRG) con el fin de desarrollar un portal Web donde se puedan satisfacer las necesidades antes planteadas, además de informatizar otros procesos internos.

MATERIALES Y MÉTODOS

Para el desarrollo de este trabajo se realizó un estudio de diferentes portales para escuelas de arte en Cuba y en el mundo, evidenciándose la necesidad del desarrollo del Portal para la Academia Profesional de Artes Plásticas de Bayamo como medio representativo del centro en la web, tratando que dicha aplicación siempre recogiera los criterios de éxito propuestos en conjunto entre la Academia y la FRG.

En la investigación científica de este trabajo como método teórico se empleó el Analítico-Sintético en el cual se realizó un estudio de la bibliografía referente al desarrollo de portales web específicamente enmarcados al tema de la cultura. Se investigaron diferentes tecnologías actualizadas para este tipo de desarrollo y se estudió la factibilidad de cada una de éstas en la Facultad Regional con el fin de conocer cuáles eran las adecuadas para ganar en tiempo de desarrollo y eficiencia. Como método empírico se utilizó la Entrevista para entrevistar a cada uno de los factores dentro de la Academia que deben interactuar con el portal con el fin de refinar detalles y pulir el entendimiento que este tipo de desarrollo requiere.

La metodología que se utilizó en el desarrollo de esta aplicación web fue Scrum-Extreme Programming (SXP) que no es más que una mezcla entre las metodologías ágiles Scrum para la gestión del proyecto y Extreme Programming (XP) para el desarrollo de software.

Con el fin de conocer qué tan efectiva era la solución que se desarrollaba se decide establecer una serie de criterios de éxito que sirven como parámetros evaluadores de este producto informático los cuales se muestran a continuación:

  • Existencia de un equipo de trabajo capaz de darle continuidad y asistencia técnica a los resultados del proyecto.
  • Eficiente gestión de información de la entidad cliente y sus diferentes trabajadores.
  • Eficiente gestión y actualización de la información publicada en el Portal.

Se desarrolló el portal utilizando el CMS Drupal 6.20, por brindar una plataforma de desarrollo muy cómoda que agiliza los tiempos de producción. Los contenidos son almacenados en una base de datos MySQL 5.1, aparte de ser libre presenta una buena integración con Drupal, Apache 2.0 como servidor web y PHP como lenguaje de programación. La combinación de estas herramientas permite el desarrollo de un sistema muy confiable, de fácil uso y extensivo.

APORTE Y NOVEDAD

El sistema establecido para la difusión del quehacer de la Academia Profesional de Artes Plásticas era muy ineficiente. Las convocatorias de inscripción, de eventos y actividades llegaban a un número reducido de interesados y se tenían que imprimir cientos de hojas con este fin. Los aspirantes a matricular recibían los avisos con poco tiempo para su preparación y la información referente variaba de un territorio a otro, pues dependía del interlocutor. No se conocían los reglamentos del centro ni los planes de estudio.

Con la publicación del Portal para la Academia Profesional de Artes Plásticas, se logran limar todas estas dificultades y limitaciones, pues toda la información se publica y llega de una forma organizada, uniforme y a tiempo a todos los territorios de la provincia donde pueda haber un interesado. También se puede encontrar información sobre los diferentes talleres, eventos y actividades que funcionan en el centro. Se le incluye una biblioteca digital donde los profesores pueden publicar documentos en las diferentes asignaturas de los cuatro años académicos. Cuenta como valor agregado la publicación de noticias culturales, nacionales, internacionales, deportivas, entre otras y un grupo de vínculos a sitios relacionados y de interés de navegación nacional.

Con la puesta en marcha de este portal, sobre un entorno Web, que sirve como instrumento de difusión, abriéndose a las tecnologías de la información y creando nuevas formas de relación con el público. Que es capaz de situar a las instituciones en un lugar privilegiado en la web, no solo por la información que brinda sino también con nuevos servicios que creen espacios de ocio, formación e investigación. El Portal es una aplicación Web desarrollada sobre CMS Drupal, que brinda las opciones necesarias para una eficaz gestión de la información, con los más avanzados conceptos que se manejan en la Web actualmente.

CONCLUSIONES

Con la realización de este trabajo se logró el reconocimiento social de la Facultad Regional de Granma en cuanto a la producción de software relacionados con la cultura local. La mejora de la gestión de la información de la Academia Profesional de Artes Plásticas Oswaldo Guayasamín. Y una buena navegabilidad y usabilidad del portal que representa a esta entidad.

REFERENCIAS

Ministerio de Cultura de la República de Cuba. 2011. Ministerio de Cultura.

http://www.min.cult.cu/loader.php?sec=informe&cont=artes_plasticas.

Yoelnis A. Gómez. 2011. PT. May 5.

http://code.grm.uci.cu/yagomez/Repo/PAPAPv1.0/files/head:/02_Gestion_de_Proyectos/2.4%20Acuerdos%20de%20trabajo/

SÁNCHEZ, J. I. P. Metodología para el Desarrollo de Software. 2005,

www.lcc.uma.es/~jignacio/index_archivos/TEMA4.pdf

TIGRIS.ORG COMMUNITY. Open Source Software Engineering Tools.

http://argouml.tigris.org/

GARCIA, X. C. y ALFONSO, J. M. Introducción a los Sistemas de Gestión de Contenidos (CMS) de código abierto. 2004, 1 p.

http://mosaic.uoc.edu/articulos/cms1204.html.  ISBN 16963296

DRUPAL. Comunidad de usuarios de Drupal.

http://drupal.org/, http://drupal.org.es/