Embed Size (px)
Citation preview
Víctor García Lodares
Pedro Castejón Silvo
David Contreras Bárcena
A mis padres..
II
Mi más sincero agradecimiento a todas las personas que se han
cruzado conmigo a lo largo de mi carrera y han aportado algo a mi vida.
Gracias a mi director de proyecto, Pedro, por confiar en mí y hacer
posible este proyecto.
A los que confiaron en mí y creyeron que algún día lo conseguiría.
Al coordinador de proyectos por su trabajo.
III
RESÚMEN
IV
Este proyecto tiene como objetivo principal ampliar y mejorar la funcionalidad
del gestor documental de la Fundación Entreculturas (Gesdoc v.1), para una mejor
explotación y clasificación de los datos que son administrados por este.
Entreculturas es una ONG de desarrollo promovida por la Asociación Fe y
Alegría, en colaboración con la Compañía de Jesús. Su finalidad es impulsar y promover
iniciativas para el desarrollo integral de los sectores más desfavorecidos, a través de la
educación, usando esta como camino para romper el círculo de la pobreza.
Gesdoc v.1 es el resultado del Proyecto Fin de Carrera: “PROYECTO
INFORMÁTICO PARA LA REALIZACIÓN DE UN GESTOR DOCUMENTAL PARA LA ONG
ENTRECULTURAS” desarrollado por mi mismo al término de la Ingeniería Técnica de
Sistemas.
Se pretende ahora desarrollar una nueva versión del gestor documental,
denominada Gesdoc v.2, la cual implemente todas las nuevas necesidades y mejoras
encontradas durante los tres años que la versión 1 lleva en explotación.
La idea de crear un entorno como Gesdoc nace de una doble necesidad por
parte de Entreculturas. Una era la de poder catalogar y archivar titulares o noticias
publicadas en los medios, que el departamento de comunicación considerase
interesantes, para posteriormente difundirlas entre sus socios y colaboradores a través
de un boletín informativo que se enviase periódicamente.
La otra necesidad relevante era la de catalogar todas las apariciones en prensa
de los anuncios de la fundación, para su posterior escrutinio y control con el fin de
hacer más eficiente el gasto invertido en publicidad.
V
Teniendo en cuenta que para una ONG, como es la Fundación Entreculturas, los
fondos para sus proyectos de desarrollo provienen de las donaciones que los socios y
colaboradores aporten, y que dichos colaboradores mayoritariamente llegan a conocer
la labor de la fundación a través de la publicidad que aparece en los medios , el buen
funcionamiento de la herramienta Gesdoc repercute directamente en la consecución
de fondos para el mantenimiento y promoción de los proyectos de desarrollo que la
ONG compromete alrededor del mundo.
Dada la influencia positiva que Entreculturas ejerce en el desarrollo de los
sectores más desfavorecidos de la sociedad, la correcta consecución de los objetivos
que en este proyecto se exponen, va a suponer una mejora en la eficiencia de la labor
desempeñada.
Las necesidades de mejora del aplicativo Gesdoc v1 encontradas por el
departamento de comunicación de Entreculturas, y que son el objeto de este proyecto,
consisten entre otros, en el desarrollo de nueva funcionalidad como la implementación
del boletín informativo, la realización de ciertas modificaciones y cambios , la mejora
de la usabilidad y la navegabilidad de la aplicación para hacer Gesdoc v2 mas intuitivo
y la adaptación de los contenidos ya registrados en Gesdoc v1 a la nueva versión.
VI
ABSTRACT
VII
This project has as main objective, to expand and improve the functionality of
the documental manager of the Entrecuturas Foundation (Gesdoc v.1), in order to
better develop and classify the data which are managed by it.
Estreculturas is a non governmental organization being part of the worldwide
"Fe y Algeria" (Faith and Happiness) Organization, sponsored by the Jesuits. Its aim is
to impel and promote initiatives for the integral development of the underprivileged
sectors, by means of the education and using it as a path to break the poverty cycle.
Gesdoc v.1 is to be considered the result of the Final Degree Project
named ”PROYECTO INFORMÁTICO PARA LA REALIZACIÓN DE UN GESTOR
DOCUMENTAL PARA LA ONG ENTRECULTURAS ", carried out by the author and as the
result of the final work of " Ingeniería Técnica de Sistemas ".
The aim is to develop a new version of the Documental Manager, identified as
Gesdoc V.2 that serves to implement all new needs and better alternatives
(improvements) found during the three years that the version has been actually in
place.
The idea to create an environment like Gesdoc is originated by a double need
identified by Entreculturas. The first one was the need to rank and file all the headlines
and general news, published by the media and that the communication department
would consider interesting. Later this information will be broadcasted to the
memberships and collaborators through an Informative Bulleting to be handled out
periodically.
The second relevant need was to rank all the advertisements originated from
the Foundation and published by the general news papers. The objective is to further
VIII
monitor the mentioned ranking with the objective being to control the donations
invested on propaganda.
Taking into consideration that an NGO such as Entreculturas Foundation, the
donations utilized in the corresponding development projects are coming from the
money collected from the memberships and collaborators, the fact that the excellent
job done by the Foundation can be announced and communicated to them in the
general media is a key element to maintain the interest and good collaboration in all
respects. For that, the proper functioning of a tool such as GESDOC, has a direct impact
on the funds to be collected and needed for the promotion and maintenance of the
developing projects that the NGO is currently undertaking around the World.
It is well known the positive influence of Entreculturas on the development of
the most unfavoured sectors of the society, therefore the correct achievement of the
objectives proposed in this project, it is bound to exert a noticeable improvement on
the efficiency of the job to be done.
The needs to improve the program Gesdoc v1 found by the communication
department of Entreculturas, being the subject of this project, consists of the
development of a new functionality in regards to the implementation of the
informative bulleting, the undertaking of some modifications and changes, the better
workability and handling of the application to make Gesdoc v1 more intuitive and the
fitting of the contents already registered in Gesdoc to the new version.
IX
ÍNDICE
X
RESÚMEN .................................................................................................................... III
ABSTRACT .................................................................................................................. VI
ÍNDICE ......................................................................................................................... IX
CAPÍTULO 1: INTRODUCCIÓN ................................................................................ 1
1.1 Introducción del Proyecto ................................................................................................ 2
1.2 Fundación Entreculturas.................................................................................................. 3
1.3 Motivación ......................................................................................................................... 6
1.4 Objetivos del Proyecto ...................................................................................................... 8
CAPITULO 2: DISEÑO DEL PROYECTO ............................................................... 10
2.1 Metodología y Tecnología de la Aplicación ................................................................... 11
2.1.1 Metodología de Trabajo ................................................................................... 11
2.1.2 Tecnología de la Aplicación: ........................................................................... 14
2.2 Identificación de Necesidades (IDN) .............................................................................. 15
2.2.1 Objetivos Empresariales o Económicos del Sistema ....................................... 15
2.2.2 Alcance del Sistema ......................................................................................... 16
2.2.3 Tipología de Usuarios Finales ......................................................................... 20
2.2.4 Restricciones del proyecto ............................................................................... 22
2.2.5 Motivos de Mecanización ................................................................................ 26
2.3 Análisis de Requisitos (ARQ) ......................................................................................... 28
2.3.1 Estudio del Sistema Actual ............................................................................. 28
2.3.2 Requisitos ....................................................................................................... 30
2.4 Estudio de Arquitectura (DAT) ...................................................................................... 39
2.4.1 Soluciones al problema planteado .................................................................. 39
2.4.2 Selección de Alternativa ................................................................................. 45
XI
2.5 Diseño Externo (DEX) .................................................................................................... 47
2.5.1 Plan de Actuación ............................................................................................ 47
2.6 Diseño Interno (DIN) ....................................................................................................... 49
2.7 Programación (PRO) ...................................................................................................... 63
2.7.1 Introducción al ASP (Active Server Pages) .................................................... 63
2.7.2 Introducción a JavaScript ............................................................................... 65
2.7.3 Código ............................................................................................................ 66
2.8 Pruebas del Sistema (PRU) ............................................................................................. 75
2.8.1 El Entorno de Pruebas o Certificación ............................................................. 76
2.9 Implantación (IMP) ......................................................................................................... 79
2.10 Estudio de Usabilidad ................................................................................................... 82
2.10.1 Estándares de Usabilidad .............................................................................. 83
2.10.2 Objetivos de los test de usabilidad ................................................................ 87
2.10.3 Tipos de test de usabilidad ............................................................................ 89
2.10.4 Entornos De Test Predefinidos ..................................................................... 91
2.10.5 Limitaciones de los test de usabilidad .......................................................... 96
2.10.6 Técnicas alternativas para evaluación ........................................................... 97
2.10.7 Ciclo de vida de la usabilidad ....................................................................... 99
2.10.8 Cuestionario de Usabilidad ......................................................................... 103
2.10.9 Valoración del cuestionario ........................................................................ 104
2.10.10 Realización y Evaluación de los Test ....................................................... 110
2.11 Mantenimiento ............................................................................................................. 112
CAPÍTULO 3: PLANIFICACIÓN ............................................................................. 113
CAPÍTULO 4: VALORACIÓN ECONÓMICA ........................................................ 115
CAPÍTULO 5: CONCLUSIONES ............................................................................. 118
XII
CAPÍTULO 6: BIBLIOGRAFÍA Y RECURSOS WEB ............................................ 122
6.1 Bibliografía ..................................................................................................................... 123
6.2 Recursos WEB ............................................................................................................... 124
ANEXO A: MANUAL DE USUARIO ...................................................................... 125
A.1 ADMINISTRACIÓN DE DATOS GEOGRÁFICOS ............................................... 126
A.1.1 Gestión de Continentes: .............................................................................. 126
A.1.2 Gestión de Países ......................................................................................... 130
A.1.3 Gestión de Provincias .................................................................................. 133
A.2 GESTIÓN DE CATEGORÍAS ................................................................................... 139
A.2.1 Gestión de Categoría .................................................................................... 141
A.2.2 Gestión de Tipo de Categoría ...................................................................... 143
A.2.3 Gestión de Subtipo de Categoría ................................................................. 143
A.2.4 Búsqueda de Categorías: .............................................................................. 144
A.3 ADMINISTRACIÓN BBDD ........................................................................................ 151
A.3.1 Gestión Ediciones ........................................................................................ 151
A.3.2 Gestión Secciones ........................................................................................ 152
A.3.3 Gestión de Tamaños .................................................................................... 153
A.3.4 Gestión Tipo de Enlace ................................................................................ 154
A.3.5 Gestión Tipo de Titulares o Noticias ........................................................... 155
A.4 TITULARES/NOTICIAS ............................................................................................ 158
A.4.1 Alta Titular: ................................................................................................. 159
A.4.2 Búsqueda de Titulares: ................................................................................ 173
A.5 ANUNCIOS .................................................................................................................. 184
A.6 BOLETÍN INFORMATIVO ........................................................................................ 186
1
CAPÍTULO 1: INTRODUCCIÓN
2
1.1 INTRODUCCIÓN DEL PROYECTO
A raíz de un uso continuado y diario del gestor documental de la fundación
Entreculturas GESDOC (desarrollado con anterioridad como el proyecto fin de carrera:
“Proyecto Informático para la Realización de un Gestor Documental para la ONG
Entreculturas”), por parte del departamento de comunicación de la Fundación
Entreculturas se ha detectado la necesidad de desarrollar unas nuevas funcionalidades
para la mejor explotación de los datos administrados por este entorno.
Estas nuevas necesidades se centran en una serie de mejoras funcionales y
visuales así como de usabilidad para una explotación de los datos más adaptada a las
necesidades de los usuarios finales y a su vez la finalización del desarrollo del
generador de boletines para la posterior distribución de la información almacenada en
el gestor.
3
1.2 FUNDACIÓN ENTRECULTURAS
Entreculturas es una ONG de desarrollo promovida por la Asociación Fe y
Alegría, en colaboración con la Compañía de Jesús. Su finalidad es impulsar y promover
iniciativas para el desarrollo integral de los sectores más desfavorecidos.
Se centra en una apuesta por una educación gratuita de calidad para todos y
todas, fomentando la participación de los sectores populares en procesos de
desarrollo sostenible, estructuras democráticas y proyectos productivos que ayuden a
mejorar su calidad de vida para romper con el círculo de la pobreza.
Entreculturas nace en España en 1986, como Fe y Alegría España. 1999 es un
año clave para la organización que apuesta por una nueva imagen y un nuevo nombre.
ENTRECULTURAS se adapta mejor a su misión en el campo de la cooperación
internacional, enfocada en la búsqueda de nuevos caminos de justicia en un mundo
global de mezcla de culturas y de convivencia.
También promueven campañas de sensibilización en países occidentales para la
comprensión de un mundo interdependiente, que sigue sin acortar las distancias entre
ricos y pobres. Forma parte de una red internacional, la Federación Fe y Alegría
Internacional promovida por la Compañía de Jesús y que lleva más de 45 años
fomentando su labor educativa en las zonas más empobrecidas.
Fe y Alegría es un movimiento de Educación Popular que nace en Venezuela en
1955. Promueve la formación de hombres y mujeres protagonistas de su propio
desarrollo, favoreciendo el acceso a la educación de niños, niñas y jóvenes de las
barriadas populares y zonas desfavorecidas latinoamericanas.
4
Entreculturas realiza acciones de cooperación con contrapartes del Sur, que
tienen por objetivo contribuir a aquellas transformaciones sociales que promuevan la
existencia de comunidades de solidaridad, particularmente entre las poblaciones
excluidas social, económica, política y/o culturalmente. Para ello ponen el acento en la
promoción de la justicia y la centralidad de la persona en todo el proceso de
desarrollo, desde una perspectiva integral de la misma que contempla tanto las
necesidades materiales, culturales, sociales y políticas como su dimensión espiritual.
La educación es el instrumento fundamental para lograr estas transformaciones
y cambios sociales. Por ello, Entreculturas apoya prioritariamente acciones que
contengan esta dimensión de educación popular, entendida en sentido amplio y no
solo como sector de trabajo.
Esta ONGD, en coherencia con su misión, siempre trabaja en colaboración con
instituciones locales. De acuerdo con el estilo institucional, colabora con instituciones
plurales y diversas con las que comparte objetivos y principios, y de manera preferente
con aquellas vinculadas con la Compañía de Jesús.
En particular, Entreculturas mantiene una relación de asociación y un
compromiso muy profundo con Fe y Alegría, de cuya Federación son miembros y con
quien establecen una vinculación de pertenencia.
Concibe la relación construida con Fe y Alegría como una referencia en la
relación con otras instituciones, en particular con el Servicio Jesuita de Refugiados que
constituye su socio prioritario en África. Valora especialmente la cercanía con las
comunidades populares y la capacidad de asumir innovaciones y retos. Trabaja con
organizaciones con capacidad y estructura adecuadas para la colaboración propuesta.
En coherencia con todo lo anterior las acciones de cooperación de
Entreculturas son, en su mayoría, proyectos concretos de desarrollo. Además esta
5
ONGD quiere apoyar la realización de otras acciones de cooperación diferentes que
respondan al tipo de relación que establecemos con las contrapartes (fortalecimiento
institucional, apoyo técnico, etc.). En todas estas acciones, además de los criterios
generales de estilo de la institución, valoran especialmente la participación de la
población, la calidad técnica, la sostenibilidad y la dimensión de género.
6
1.3 MOTIVACIÓN
Partiendo de la base que la primera versión de la aplicación GESDOC fue
desarrollada en el año 2006 como Proyecto Fin De Carrera por mí, he obtenido
resultados medibles del impacto de la misma en la Fundación Entreculturas que, a día
de hoy, se sigue utilizando y explotando.
Alguno de estos resultados pueden verse reflejados tanto en la captación de
socios como en el incremento de las donaciones realizadas por ellos, gracias a una
inversión eficaz en aquellos medios de comunicación de los cuales se obtiene una
mayor influencia. Así, estas aportaciones se convierten en nuevos proyectos sociales
en los sectores más desfavorecidos de la sociedad.
Actualmente Entreculturas está presente en 14 países de América Latina y en El
Chad (África), llegando a más de un millón de beneficiarios entre niños y adultos. Ha
sido declarada de interés social por la UNESCO y está presente en los principales foros
internacionales de las Naciones Unidas.
Debido a estos resultados satisfactorios y como consecuencia de la utilización
de la aplicación durante estos últimos tres años, el departamento de Comunicación de
la Fundación Entreculturas propuso una serie de mejoras y de nuevas funcionalidades
para la optimización de la explotación y administración tanto del modelo de datos
como de la interfaz. Estas mejoras serán utilizadas por toda la Organización
Entreculturas a lo largo de todo el mundo donde actúa.
Por tanto, dado que conozco la aplicación desde el inicio hasta la finalización de
la primera versión y dado que he podido comprobar la labor de la Fundación y su
impacto a lo largo del mundo, es para mi motivación suficiente para hacer de este
7
proyecto el reflejo de mis conocimientos adquiridos durante el segundo ciclo de
Ingeniería en Informática.
Además de este reflejo, veo la ocasión de mejorar y adquirir nuevos
conocimientos tanto en la materia de la Fundación, como en realizar nuevas versiones
de una aplicación que ya se encuentra en el entorno de producción.
Así puedo continuar satisfaciendo los requisitos anteriormente planteados
añadiendo y superando nuevos objetivos, necesidades… continuando el trabajo sin
pasar por alto aquellos nuevos objetivos que veremos realizados en este proyecto.
Tras la satisfacción del usuario final ante el proyecto anterior y ante las nuevas
necesidades planteadas gracias a la aplicación de los nuevos conocimientos teórico
prácticos adquiridos durante la carrera y la etapa profesional, esto supone para mí un
nuevo reto que cumple con las expectativas de haber seguido estudiando después del
primer ciclo en Ingeniería Informática.
Aparte de las necesidades contractuales que pueda tener Entreculturas, este
proyecto nace de una motivación personal por enfocar el proyecto fin de carrera desde
una perspectiva social, con el objetivo de ayudar a que la informática se convierta en
una herramienta de cooperación y desarrollo.
8
1.4 OBJETIVOS DEL PROYECTO Los principales objetivos del proyecto se enumeran a continuación.
Posteriormente en siguientes apartados se detallarán en profundidad.
Desarrollar nueva funcionalidad.
A lo largo de la explotación de la aplicación durante tres años se han
detectado nuevos requisitos que atañen a la funcionalidad del
aplicativo, tanto de mejora como el resultado del crecimiento de la
Fundación que tiene como consecuencia directa el aumento de la
cantidad de información.
Realizar modificaciones, cambios y mejoras.
Dentro del uso diario de la aplicación se han recogido cambios, no de
aumento de la funcionalidad, sino alteraciones de la especificación
inicial de requisitos de la versión 1 de la aplicación.
Mejorar la usabilidad y navegabilidad de la aplicación.
Debido a que los usuarios iniciales eran identificados en un segmento
concreto de la Fundación y actualmente la aplicación se ha ampliado a
todas las sedes, se han recogido nuevos requisitos respecto a la
navegabilidad de la aplicación. Se llevará a cabo, por tanto, un estudio
de la usabilidad al personal del departamento de Comunicación de la
Fundación.
Adaptar los contenidos del sistema gestor de base de datos a la nueva
versión.
9
En una parte más técnica del proyecto se realizarán todos los cambios
relativos a las bases de datos y a los datos que las contienen, tratando
de minimizar el impacto en el usuario final dado que se trata de un
entorno en producción.
10
CAPITULO 2: DISEÑO DEL PROYECTO
11
2.1 METODOLOGÍA Y TECNOLOGÍA DE LA APLICACIÓN
2.1.1 Metodología de Trabajo
El paradigma del ciclo de vida del Software del proyecto será la metodología
lineal o en cascada. Su principal característica consiste en que, tras la finalización de
cada fase del sistema, la fase siguiente toma como datos de entrada los resultados de
la fase anterior. En cada fase se introduce más detalle hasta obtener un código
ejecutable. El funcionamiento de las aplicaciones finales no se observará de forma
exacta hasta la finalización de la fase de implantación, pero sí se apreciará la apariencia
y la forma de la aplicación a medida que las etapas se vayan completando.
La razón principal por la que se lleva a cabo la creación del proyecto con esta
metodología es el estudio minucioso de las divisiones del proyecto informático, para
una perfecta comprensión y documentación del mismo.
Este paradigma es el más extendido y utilizado en proyectos de gestión
medianos y grandes. Sobre este paradigma de han desarrollado metodologías
estructuradas, basadas en la dualidad de modelos de datos y de procesos: SSADM,
METHOD/1, MÉTRICA.
La metodología consta de las siguientes etapas o fases:
Identificación de necesidades: En esta etapa se define el problema a resolver y se
fijan las normas a seguir para la dirección del proyecto. Se establecen los límites
del proyecto fijando qué partes del sistema pueden cambiarse y cuales escapan a
nuestro control. Cuanta más información esté a disposición del proyecto, más
sencillo resultará abordar el desarrollo del mismo.
12
Análisis de requisitos: El objetivo de esta etapa es alcanzar un conocimiento
suficiente del sistema, definiendo las necesidades, problemas y requisitos de las
aplicaciones, para expresarlo mediante los modelos de procesos y de datos.
Estudio de arquitectura: El objetivo de esta etapa es definir las posibles soluciones
de arquitectura que satisfagan tanto los requisitos como las restricciones. Para ello,
se definen esas posibles soluciones, se someten a un estudio de viabilidad y se
elige la más adecuada, para ser desarrollada e implementada. Se abordará una vez
estén cubiertas las dos etapas anteriores, puesto que no puede realizarse una
especificación clara de las posibles soluciones que se proponen si aún no se
conocen los requisitos.
Diseño externo: Esta etapa abarca el método y las técnicas a utilizar para encontrar
la mejor solución. El proceso de diseño del sistema es mucho más costoso y
creativo que el análisis. Resulta difícil encontrar el mejor diseño para el nuevo
sistema, ya que dependerá de su propio entrono y de la cantidad de factores que lo
rodean. El objetivo principal de esta etapa es crear un sistema a implementar sobre
la plataforma Hardware y Software específica.
Diseño interno: En esta etapa se identifican y diseñan los diversos componentes
Software del sistema informático, describiendo detalladamente sus
especificaciones físicas. Dependiendo de la arquitectura elegida para el sistema
final, estos componentes pueden tener una naturaleza muy diversa.
Programación: El objetivo de esta etapa es alcanzar la transformación del sistema
en un conjunto de programas que puedan ser ejecutados correctamente, bajo
criterios de calidad. La dificultad estriba en cómo realizar esta transformación de la
mejor manera posible, ya que va a depender de factores como el lenguaje de
programación a utilizar, herramientas y utilidades Software disponibles, y el equipo
de programación. No sólo se necesita la creación de un buen diseño del sistema
13
informático, sino también existe la necesidad de realizar una construcción de
calidad, fiable y que funcione eficientemente, facilitando y disminuyendo el
mantenimiento futuro.
Pruebas: El objetivo de esta etapa es someter al sistema desarrollado y a sus
componentes, a una serie de verificaciones encaminadas a garantizar un nivel de
fiabilidad aceptable. Por lo tanto, una vez desarrollado y probado cada uno de los
programas y componentes Software, deben realizarse una serie de pruebas para
conseguir integrar todo el sistema, de acuerdo al plan de pruebas establecida en la
fase de Diseño Interno. Esta etapa es crítica y debe por lo tanto ser planificada,
diseñada y realizada con el mismo rigor y control con el que se realiza el desarrollo
del sistema informático. Si las pruebas no son satisfactorias habrá que volver al
diseño y a la programación para solucionar los problemas encontrados. Una vez las
pruebas hayan sido satisfactorias se procederá a la implantación del sistema
informático.
Implantación: Esta etapa consiste en transferir el software del pc de desarrollo al
servidor dedicado para llevar a cabo la explotación del sistema. Esta transferencia
debe prever la migración necesaria del Software configurado a cada uno de las
estaciones de trabajo.
Mantenimiento: El ciclo de desarrollo del sistema se completa con la implantación y
entrega del sistema. Pero esta entrega necesita de una garantía de funcionamiento
y un servicio técnico que realice el mantenimiento posterior del sistema
informático implantado.
14
2.1.2 Tecnología de la Aplicación:
Aplicación intranet desarrollada en formato Web, para ser utilizada en la
intranet corporativa.
Base de datos en SQL: Requiere de servidor SQL. Para los nuevos desarrollos se
adaptará la antigua base de datos. Se utilizará para los nuevos desarrollo
MICROSOFT SQL SERVER 2005.
La Aplicación puede instalarse en cualquier PC que pueda hacer las veces de
servidor, preferiblemente en un servidor con Windows 2000 Server o superior.
Es requisito indispensable que disponga de un disco duro de gran capacidad
para almacenar los documentos que se registren.
La Base de datos podrá ser instalada en un Servidor SQL propio (en la propia
oficina usuaria) o en un servidor de la Federación visible para la FyA usuaria a
través de Internet. Es mejor la primera opción: la aplicación funciona más
rápido, hay acceso permanente a los datos y no se requiere conexión
permanente a Internet.
Una vez instaladas la Aplicación y la Base de Datos, los PCS de la red interna de
cada FyA podrán acceder a la aplicación a través de un explorador como
Internet Explorer u otro.
La Tecnología de programación se basa en la utilización de componentes o
Assembly’s programados en Visual Basic para el acceso a datos y para las
páginas Web se utilizara ASPX con scripts en Javascript y VBscript.
15
El entorno de desarrollo, Microsoft Visual Studio 2005, tiene una tecnología
basada en 3 capas:
Capa de Interfaz: desarrollos hechos en asp.net, aspx, javascript, xml, html y parte de visualBasic.net.
Capa de Proceso: para esta capa se utilizarán componentes externos o assemblys desarrollados íntegramente en visualBasic.net.
Capa de datos: incluye todos los procesos realizados directamente sobre la base de datos.
2.2 IDENTIFICACIÓN DE NECESIDADES (IDN)
2.2.1 Objetivos Empresariales o Económicos del Sistema
Figura 2.1
16
Dado que nuestra aplicación está desarrollada sobre una plataforma sin ánimo
de lucro como es una ONG, en este caso los objetivos comerciales de lucro propio no
tienen cabida. Si bien esta aplicación, una vez finalizada ayudará a la organización a
gestionar sus contenidos, y controlar sus apariciones en prensa. Teniendo en cuenta
que las apariciones en prensa para una ONG es su principal manera de conseguir
socios y con ello fondos, se podría decir entonces que el objetivo económico de
Gesdoc V.2.0 es el de obtener fondos para nuevos proyectos de ayuda a los más
desfavorecidos.
2.2.2 Alcance del Sistema
El nuevo sistema ha de abordar las siguientes funcionalidades, cambios y
mejoras:
Con respecto a las Categorías:
Mejorar la gestión de categorías: Debido a la gran cantidad de información
que se ha de gestionar en el apartado de categorías, se considerado
oportuno dividirlas en tres niveles de jerarquía para la mejor
taxonomización o categorización de la información del sistema gestor
documental.
Mejorar las opciones de búsqueda de categorías: Se ha de desarrollar un
nuevo formulario emergente desde los formularios de alta y búsqueda de
contenidos (anuncios y titulares), el cual incluye todas las nuevas opciones
de búsqueda como la nueva jerarquía de categorías, así como búsqueda
múltiple y selección múltiple de resultados.
Mejorar las opciones de búsqueda de categorías II: Se ha de incorporar el
campo subtipo de categoría en la búsqueda de categorías, es decir, se ha de
17
poder filtrar los resultados de la búsqueda además de por categoría, por
subtipo de ésta.
Mejorar las opciones de búsqueda de categorías III: Se hace necesario para
la mejor gestión de los datos de categorías, un formulario desde el cual se
puedan buscar categorías para posteriormente consultarlas, borrarlas o
modificarlas.
Mejora: Opción de vinculación de categorías a datos geográficos.
La vinculación de categorías a ubicación geográfica (anteriormente
obligatoria) ahora queda a decisión del usuario.
Con respecto a Contenidos (tanto Titulares/Noticias como Anuncios):
Solo se mostrarán los datos geográficos si el usuario lo desea.
Cuando se consulte un contenido (titular, anuncio) se mostrarán los datos
geográficos sólo si existiesen datos geográficos asociados, ocultándose en
caso contrario.
Mejora: Visualización de las categorías asociadas a un contenido al ser éste
consultado.
Mejora: si el usuario desea hacer uso de las categorías pulsará sobre el
botón “búsqueda de categorías” que lanzará un formulario de búsqueda.
Mejora: facilitar el uso al usuario devolviendo el foco a donde el usuario lo
preferiría.
Incluir campos nuevos a las páginas de contenidos.
18
Nuevo formulario de búsqueda de campañas que facilita al usuario la
selección de campañas.
Los datos del buscador de campañas se recuperarán de Gesco (Gestor de
Colaboradores)
Mejora: cambiar la manera de mostrar los datos de los resultados que
devuelve la búsqueda de contenidos, mostrando las distintas categorías
separadas por comas.
Mejora: Se puedan realizar búsquedas por varios tipos y subtipos de
categoría al mismo tiempo.
Añadir listas de elección múltiples al formulario de búsqueda de categoría.
Otros desarrollos
Se desea que los resultados que devuelve una búsqueda sean exportados a
un fichero excel para ser guardados.
Se ha de mejorar el importado de ficheros para que este almacene copias
de los ficheros originales en un servidor dedicado y se han de añadir
diversas validaciones a los ficheros.
Los ficheros al ser almacenados en el servidor , éstos deberán quedar
vinculados al contenido por un nombre hash y perderán su nombre original.
Facilitar al usuario el retorno a los datos que utilizó para la búsqueda.
Incluir un botón que al pulsarlo limpie el grid de resultados allá donde haya
grid de resultados.
19
Boletín informativo
Se necesita generar un boletín informativo de manera automática a partir
de la información contenida en la base de datos (GESDOC).
Semanalmente se enviará a los usuarios, registrados en la base de datos de
Colaboradores (GESCO), un boletín informativo que incorpore las ultimas
noticias o por lo menos las más importantes.
Dicho boletín debería generarse automáticamente, solo indicando los
contenidos que se quieren incluir.
El proceso ha de ser lo más intuitivo posible, permitiendo la inclusión de
hipervínculos en el mismo y ha de facultar al usuario el uso de la libreta de
direcciones del servidor de correo interno (Exchange).
Mejorar la usabilidad y navegabilidad de la aplicación.
Se ha de realizar un estudio de la usabilidad de la página web a los usuarios
finales para dar lugar a un interfaz más sencilla, intuitiva y menos lioso para
los usuarios.
Todas las nuevas funcionalidades, formularios, campos y relaciones
implicarán un estudio y un análisis de la situación actual y de la futura para
convertir y adaptar la base de datos de Gesdoc V1 a las nuevas
funcionalidades y mejoras de Gesdoc V2.
20
2.2.3 Tipología de Usuarios Finales
Partiendo de la base que los usuarios de Gesdoc v2 serán los mismos que
vienen utilizando Gesdoc v1 se puede afinar la definición de los usuarios finales más
que en la versión anterior, pues por entonces era una incógnita. A día de hoy los
usuarios de Gesdoc v2 son el departamento de comunicación de Entreculturas,
compuesto mayoritariamente por periodistas y personal relacionado con los medios
de comunicación, así como un diseñador gráfico. Por tanto el departamento de
comunicación en su totalidad tiene conocimientos informáticos pues son sus
principales herramientas de trabajo. Si se suma a esta ventaja que todos ellos, por el
hecho de ser personal de Entreculturas, están muy familiarizados con otros entornos
como GesCo y GesPro que comparten con Gesdoc su estructura y diseño, hacen de
Gesdoc un entorno fácil de utilizar para los usuarios finales.
En cualquier caso, se puede tratar de personas las cuales no tienen por qué
tener grandes conocimientos de informática. De hecho, a falta de personal del
departamento de comunicación, cualquier persona acreditada podrá hacer uso de la
aplicación. Si bien, cabría comentar que las personas que en un futuro podrán ser
potenciales usuarios, serán voluntarios de la fundación, el perfil de los voluntarios
destinados a estas labores de recopilación de datos y funciones muy mecánicas suele
ser el de los voluntarios de avanzada edad, y aunque no se puede generalizar, suele
darse esta situación. Digamos que los voluntarios de temprana edad están más
vinculados con las nuevas tecnologías y con la informática, no así los de más avanzada
edad, por tanto este detalle hay que tenerlo en cuenta a la hora del nuevo diseño del
entorno a utilizar, y a la hora de documentar el proyecto habrá que acompañarlo de un
manual de usuario para personal no relacionado con la informática.
21
Por tanto cualquier usuario de la fundación que requiera información solo
tendrá que logearse previamente y pasar el control de seguridad de la aplicación,
impuesto por la fundación, y podrá hacer uso de esta aplicación y realizar todas las
búsquedas que desee, ya que al tratarse de una hemeroteca digital, es un software
muy útil para cualquier personal del centro. Incluso, si alguna persona de la institución
le apetece compartir algún artículo, podrá ella misma registrar dicho artículo para que
los demás usuarios puedan disfrutar de él vía intranet.
Resumiendo, los usuarios finales de la aplicación informática no tienen
características en común salvo la pertenencia a la asociación, por tanto el
conocimiento informático no tiene por qué ser el mismo.
22
2.2.4 Restricciones del proyecto
Las restricciones que se tuvieron en cuenta en la versión 1 de Gesdoc no han
cambiado, sin embargo se han incluido nuevas restricciones.
El Presupuesto: Esta suele ser una de las principales restricciones de todo proyecto.
En este caso se puede decir que no es lo que más preocupa, dado que se trata de
una ONG, se suelen conseguir donaciones de todo tipo. Es decir, para desarrollar el
software son necesarios una serie de recursos humanos y hardware, así como
software. Para los primeros, los humanos, se suele recurrir a estudiantes que estén
realizando su proyecto de fin de carrera o a voluntarios de la fundación, los cuales
obviamente emplean su tiempo a cambio de una remuneración inmaterial, o en su
defecto, también se puede recurrir a donaciones en consultaría que empresas de
consulting hacen a esta fundación.
Por otro lado, para los recursos hardware que se pudieran necesitar y que
supondrían un aumento considerable del presupuesto, también se recurre a
donaciones que otras empresas o personas han hecho a la fundación. Cuando una
empresa realiza una actualización de ordenadores en ocasiones dona sus
ordenadores “viejos” o “desactualizados” (en ocasiones con menos de un año de
vida) a organizaciones de este tipo. Aun así hay recursos hardware, como por
ejemplo servidores o main frames, que son difícilmente conseguibles por estos
medios, pero si se tiene en cuenta que el servidor dedicado donde se hospedará
esta aplicación, es también lugar de hospedaje de otras aplicaciones corporativas
de la fundación, no supone un gasto como tal, sino un porcentaje del gasto. Por
otro lado, y si fuese necesario esta aplicación se podría alojar en local en un
ordenador, por lo que ya no se requeriría un servidor.
23
Para los recursos software, hay dos maneras de evitar “gastos” por así
decirlo, ya que o bien se podría recurrir a software libre fácilmente asequible en
Internet. En este caso, y dado que esta aplicación se ensamblará en un conjunto de
aplicaciones corporativas de la fundación, se ha optado por desarrollar el software
con el mismo software que el resto de ellas. Microsoft dona anualmente licencias
para todo tipo de programas que desarrolla, para todo tipo de ONG’s. En este caso
se utilizará Microsoft Visual Studio. Net 2005, Microsoft SQL Server 2005 y otras
tantas aplicaciones de desarrollo donadas por el Gigante Americano del software.
De tal manera, que dada la situación o el ámbito en el que se desarrollará
este software, el presupuesto no será una de las mayores restricciones.
Suponiendo que el presupuesto óptimo fuera el más reducido, sería
imprescindible tener, al menos, presupuesto para poder contratar un coordinador
de proyecto, un informático, una persona con alto nivel de programación y ligada
al entorno de la ONG, con un alto conocimiento de las aplicaciones corporativas
con las que se vaya a ensamblar esta aplicación. Dicha persona será imprescindible
en el devenir de la aplicación, ya que sin una persona que pueda instruir y guiar al
programador afectaría negativamente la calidad del producto final, e incluso podría
no llegar a realizarse. Si bien, habría que matizar que dicho profesional intervendría
en multitud de proyectos, no solo en este, de tal manera que el gasto se dividiría
entre todos los proyectos, o se computaría por hora trabajada en su defecto.
Los Usuarios: Como se ha citado anteriormente, la tipología de usuario no tiene
porque ser la de un usuario con alto conocimiento en informática, por lo que se
hace imprescindible una constante evaluación por parte de los usuarios finales
para ver su conformidad con su entorno. A su vez serán necesarios unos menús
intuitivos, grandes y el desarrollo de un manual de usuario con especificaciones de
todos los pasos que hay que dar de manera escrupulosa y perfeccionista, de tal
24
forma que una persona con poco conocimiento informático pueda desenvolverse
con la aplicación.
La Privacidad de la Información: Se ha de tener en cuenta, que como todo gestor
documental, se va a tratar con todo tipo de documentos, los cuales serán
almacenados en nuestro servidor, o serán referenciados en destino. Esto puede
traer consecuencias negativas, como resultado de la violación de alguna ley sobre
derechos de autor o copyright. Véase que por ejemplo se quiere registrar un
artículo de el diario El País, y en lugar de escanear el articulo en formato papel, se
recurre a simplemente crear un enlace a su homologo en Internet,
www.elpaisdigital.com . En tal caso, dependerá del origen del artículo. Bastaría con
comprobar la declaración de privacidad que toda página web posee, y observar si
dicha pagina puede ser referenciada o no.
La Caducidad de la Información: Esto nos lleva a otro posible problema, si se opta
por referenciar páginas web en lugar de crear copias en nuestro servidor, el
problema que se nos podría plantear seria que estos enlaces o referencias
caducasen con el paso del tiempo, y en una futura búsqueda de dicho artículo, no
se encontrasen los datos buscados. Para ello lo más recomendable seria generar
siempre copias de los documentos en nuestro servidor dedicado. Lo que nos lleva a
la siguiente restricción.
Alojamiento o “Hosting” de los documentos: Se nos plantea la siguiente restricción.
Como se ha comentado en la restricción anterior, la mejor opción para evitar la
posible pérdida de los datos por la caducidad de los mismos, sería la opción de
alojar en el servidor dedicado toda la información posible, pero se habla de una
cantidad inmensa de datos. Aparentemente un documento, el cual contiene
únicamente texto, no debería ocupar mucho espacio en disco, pero no es así si se
habla de documentos con imágenes, videos, archivos pdf... Estos archivos pueden
llegar a saturar el servidor. Si además se tiene en cuenta, que todos los
25
documentos previamente registrados antes de la generación de esta aplicación, los
cuales se pretenden digitalizar e incluir en Gesdoc, se habla de una gran cantidad
de información. De tal manera que va a haber que restringir el “peso” de los
archivos que se suban al servidor.
26
2.2.5 Motivos de Mecanización
En la anterior versión de la aplicación este apartado tenía más sentido,
teniendo en cuenta que previo a la aplicación no existía ningún tipo de sistema
mecanizado que realizara las funciones de Gesdoc.
Sin embargo, en la actualidad, el motivo del proyecto va enfocada a una mejora
de la funcionalidad (descrita por los requisitos) y a la optimización de la parte
existente. En dichos apartados se describirá la justificación de la realización de las
mejoras.
Como motivo de la mecanización en la primera versión de Gesdoc, se dieron las
siguientes razones:
El principal problema o motivo por el que se planteó la realización de un gestor
documental que archivase y gestionase todos los documentos de prensa de interés
general para la organización es porque hasta la fecha se utilizaba un sistema muy
rudimentario, el cual suponía un coste, en tiempo, infinitamente mayor, a la par que
suponía un importante consumo de espacio físico en cuadernos de carga.
Hasta la fecha se disponía de una rudimentaria aplicación generada en
Microsoft Access, que se basaba únicamente en una base de datos donde se
almacenaba algún dato característico del articulo y su ubicación física, es decir, en que
cuaderno de que estantería de que mueble se encontraba el recorte del articulo.
La pérdida de tiempo se basaba principalmente en el almacenado. Para
registrar un artículo había que introducirlo en la base de datos, recortarlo o en su
defecto fotocopiarlo, plastificarlo y guardarlo en un archivador.
27
Tras la generación de la aplicación, la persona o voluntario que se encargaba de
este costoso trabajo, no tendrá que levantarse de su asiento, se registrará cada artículo
digitalmente en cuestión de segundos.
El coste monetario, temporal y ecológico descendería considerablemente, lo
cual es el principal motivo de la mecanización.
La automatización del proceso facilita a cualquier persona para realizar
registros, y lo más importante, cualquier persona tendrá acceso a la información sin
necesidad de preguntar al encargado de las noticias, y sin necesidad de abrir ningún
archivador. Hasta la fecha, cuando alguien se interesaba por cualquier tipo de
información, esta estaba obligada a ponerse en contacto con el voluntario encargado
de la hemeroteca, y esta persona tenía que hacer una ardua labor de búsqueda para
facilitarle dicha información. Tras la mecanización, cualquiera podría acceder a Gesdoc
desde su puesto de trabajo y hacer todas las búsquedas que quisiera sin tener que
molestar a nadie. De esta manera también, el voluntario encargado de la hemeroteca
se podrá dedicar únicamente a registrar la información, y no ya a facilitarles la
información a los demás usuarios.
28
2.3 ANÁLISIS DE REQUISITOS (ARQ)
2.3.1 Estudio del Sistema Actual
Actualmente el sistema utilizado por Entreculturas para la gestión y
catalogación de las apariciones en prensa de la fundación, así como de los titulares y
noticias que por algún motivo quieren registrar, esta llevada a cabo por Gesdoc v1.
Tras dos años y medio de uso y explotación del gestor documental se han encontrado
ciertas mejoras a realizar puesto que o bien han cambiado las necesidades o bien no se
realizó un análisis exhaustivo del diseño interno de Gesdoc v1.
En primer lugar se ha detectado que la versión 1 de Gesdoc no es del todo
usable, es decir, la manera de ordenar los menús no son intuitivos y fáciles para según
qué usuarios, encontrándolo alguno de ellos incluso difícil de utilizar.
Algunos formularios tienen demasiada cantidad información, desconcertando
al usuario. Véase por ejemplo, en la versión 1 de Gesdoc, el buscador de categorías
estaba incluido en los formularios de alta de contenidos, ocupando una gran parte de
la pantalla y obligando al usuario a utilizar el scroll vertical de las páginas. Se pretende
externalizarlo a una ventana que emerja desde los formulario y aliviando un tanto así
las páginas de alta de contenidos.
Se ha observado que la relación de las categorías con los datos geográficos no
es útil, tras dos años de uso se ha observado que en muy pocos casos se ha asociado
una categoría a una ubicación geográfica, sin embargo se considera útil aplicar a un
contenido directamente, por tanto habrá de ser un dato de mayor nivel.
29
La aplicación Gesdoc v1 se realizó con la intención de que todos los contenidos
que fueran dados de alta como titulares y noticias fueran luego difundibles a través de
un boletín informativo el cual nunca se llegó a incorporar a la versión 1 de Gesdoc. Por
tanto uno de los principales motivos por los que se desarrolló Gesdoc quedaba
pendiente en aquella ocasión. Es prioritario el desarrollo del boletín informativo en
esta versión de Gesdoc.
Se han detectado ciertos campos que ya no se consideran útiles y por contra se
ha detectado la necesidad de incorporar nuevos campos en ciertos formularios.
Por estos y por otros tantos motivos Gesdoc v1 requiere una remodelación, un
cambio de aspecto, una mejora en la funcionalidad y en definitiva una nueva versión
para facilitar el trabajo al personal del departamento de comunicación y para una
mejor explotación de los datos.
30
2.3.2 Requisitos
Muchos de los requisitos impuestos por la fundación para la versión 1 del
gestor documental se mantienen, pero evidentemente esta nueva versión de Gesdoc
cuenta con los suyos propios que se detallan a continuación:
Relativo a Categorías
Se desea que la estructura de categorías esté organizada en 3 niveles, para facilitar
la clasificación y las búsquedas:
Tipo de Categoría
Subtipo de Categoría
Categoría
De tal manera que no se puedan registrar categorías sin vincularlas a “subtipos de
categorías”, ni subtipos de categorías sin vincularlos a “tipos de categorías”.
La vinculación de los Contenidos (noticias, artículos, anuncios, apariciones,…) con
las Categorías, tanto en el alta como en la modificación, será a través de un
formulario de búsqueda, es decir la búsqueda de Categorías solo se harán visibles
cuando el usuario lo requiera. Se ha de desarrollar una nueva ventana de búsqueda
independiente que muestre sólo las Categorías seleccionadas.
El campo “Subtipo de Categoría” debe aparecer como parámetro de búsqueda en
el formulario de Búsqueda de Categorías.
31
La vinculación de las categorías con una ubicación geográfica será opcional, es
decir los datos geográficos serán opcionales y solo se harán visibles cuando el
usuario lo pida, o lo que es lo mismo se pulse encima del enlace “Datos
Geográficos” del formulario de Categorías.
En este formulario se deberá seleccionar un Operador Lógico (“Y”,”O”) en relación
con las Categorías y los Datos Geográficos, es decir que se puede buscar si se
selecciona el operador “Y” por la categoria1 Y la categoria2 Y…. la categoriaN Y
datos geográficos y si se selecciona el operador “O” por la categoria1 O la
categoria2 O…. la categoriaN O datos geográficos. Pero siempre con el mismo
Operador Lógico.
En los formularios de alta de titulares y anuncios dicho operador lógico no debe
aparecer, pues si se decidiera introducir datos geográficos habría que pulsar sobre
dicho botón y se incluirían en tal caso siempre.
Se requiere una página que tenga un buscador de categorías donde se puedan
gestionar altas, bajas y modificaciones de las mismas de un modo fácil.
En el formulario de Búsqueda de Categorías al que se accede desde los formularios
de Contenidos, al seleccionar un tipo de Categoría automáticamente se rellenara
una lista desplegable con los Subtipos de Categoría pertenecientes al Tipo de
Categoría seleccionado. Y a su vez al seleccionarse un Subtipo de Categoría se
rellenara automáticamente una lista de elección múltiple con las Categorías
pertenecientes a ese Subtipo de Categoría.
Relativo a Contenidos
32
De igual manera la vinculación de los Contenidos (noticias, artículos, anuncios,
apariciones,…) con una ubicación geográfica será opcional, es decir los datos
geográficos serán opcionales y solo se harán visibles cuando el usuario lo desee.
Por tanto, cuándo el formulario de Contenidos se muestre en modo consulta, es
decir al consultar o borrar un Contenido, solo deben mostrarse los datos
geográficos si el Contenido consultado los tuviera.
Por tanto, cuándo el formulario de Contenidos se muestre en modo consulta, es
decir al consultar o borrar un Contenido, solo deben mostrarse los datos
geográficos si el Contenido consultado los tuviera.
Cuándo el formulario de Contenidos se muestre en modo consulta, es decir al
consultar o borrar un Contenido, solo deben mostrarse las Categorías
seleccionadas (si el Contenido consultado las tuviera).
En la búsqueda de Contenidos solo se harán visibles las Categorías cuando el
usuario lo requiera. Mostrándose la búsqueda de Categorías en una ventana
independiente a la del formulario de Búsqueda.
En los formularios de Alta, Modificación o Búsqueda de Contenidos, al registrar
Datos Geográficos, Categorías o cualquier otro dato de la parte inferior del
formulario, mantener el foco en el campo correspondiente evitando que el
formulario pase el foco al principio del mismo como ocurre actualmente.
Agregar la Campaña y la Sección como parámetros de Búsqueda en el formulario
de alta de Contenidos.
Agregar la sección y la fecha del suceso en los formularios de Alta y Modificación
de Contenidos que no aparezcan.
33
En los formularios de Contenidos que la selección de las Campañas sea a través de
un Buscador de Campañas, que se abra en una página independiente al formulario
de Contenidos en que se esté al pulsar en un botón de Búsqueda de Campañas.
Los campos del Buscador de Campañas: Tipo Campaña, Modalidad, Fecha Alta y
Fecha Vigencia, así como todos los demás datos referentes de las Campañas se
obtendrán de GESCO.
En el formulario de Búsqueda de Contenidos hay que añadir al listado de
resultados de la búsqueda los campos: fecha de publicación/aparición, sección y las
Categorías o los Datos Geográficos de cada Contenido. Las Categorías se mostraran
en la misma celda del listado de resultados de la búsqueda separadas por comas.
En el formulario de Búsqueda de Categorías se podrá buscar además de por el
numero de Categorías distintas que se quiera, aunque tenga distinto Tipo y Subtipo
de Categoría, por varios Subtipos de Categoría al mismo tiempo.
Habilitar en el formulario de Búsqueda por Categorías, al que se accede desde el
formulario de Búsqueda de Contenidos, una lista de elección múltiple para
seleccionar el Subtipo de Categoría.
Otros desarrollos
En los formularios de Búsqueda de Contenidos y Búsqueda de Categorías, el
resultado de la búsqueda además de mostrarse por pantalla, debe ser exportable a
Excel. La exportación se realizará pulsando en el botón Exportar a Excel.
Es necesario finalizar el desarrollo correspondiente al enlace del material
documental (Web, documento digitalizado, PDF, imagen,…) con el Contenido en la
34
base de datos que le corresponde. Este se llevara a cabo en los formularios de Alta
o Modificación de Contenido a través del campo Enlace (URL, Fichero).
Se cree oportuno que cuando lo que se importa es un fichero, esta copia del
fichero pierda su nombre original y se le asigne algún tipo de nombre referencia al
contenido, de esta manera se ahorrarán muchos problemas con nombres de
fichero con caracteres extraños.
En el retorno a los formularios de Búsqueda de Contenidos y Búsqueda de
Categorías desde otros formularios deben quedar seleccionados en el resultado, el
Contenido o la Categoría del que se retorna, y en los parámetros de búsqueda, los
utilizados justo antes para encontrar el Contenido o la Categoría del que se
retorna.
En los formularios de búsqueda tanto de titulares como de anuncios se requiere un
botón que limpie el formulario de resultados.
Nuevos desarrollos y funcionalidades: Boletín informativo
Se necesita generar un boletín informativo de manera automática a partir de la
información contenida en la base de datos (GESDOC).
Semanalmente se enviará a los usuarios, registrados en la base de datos de
Colaboradores (GESCO), un boletín informativo que incorpore las ultimas noticias o
por lo menos las más importantes.
Dicho boletín debería generarse automáticamente, solo indicando los contenidos
que se quieran incluir.
35
El proceso ha de ser lo más intuitivo posible, permitiendo la inclusión de
hipervínculos en el mismo y ha de facultar al usuario el uso de la libreta de
direcciones del servidor de correo interno (Exchange).
Corporativismo:
Dado que la aplicación Gesdoc, se incorporará y ensamblará a la web corporativa
utilizada en la intranet de la fundación, se ha de mantener el diseño e imagen de la
corporación. Se han de mantener la topología “Tahoma” con las iniciales de las
palabras en minúscula, letras blancas, fondos rojos etc., como los que se pueden
observar en el emblema de la ONG.
Entorno amigable:
Puesto que los usuarios finales de la aplicación serán muchos, y de variables
conocimientos en informática, se hace indispensable que el diseño y funcionalidad
de la aplicación sea “user friendly”. El principal usuario de la aplicación será la
persona voluntaria que se encargue de dar de alta los titulares o anuncios, pero a
la hora de la búsqueda de información, cualquier usuario de la corporación tendrá
acceso a la misma, por tanto, se ha de contar con ello a la hora de diseñar la web y
la aplicación embebida en ella. La navegabilidad deberá ser intuitiva y se impondrá
el uso de controles de confirmación a la hora de realizar modificaciones y bajas,
informando al usuario de lo que van a realizar y cuestionando en todo momento la
conformidad con la acción que van a llevar a cabo.
Manual de Recurrencia:
36
Por el mismo motivo que la aplicación ha de tener un entorno amigable dado
que los usuarios no serán expertos, o por lo menos no tienen por qué serlo, se ha
considerado de vital importancia por parte de la organización , que la aplicación se
acompañe de un manual de usuario minucioso y completo para poder recurrir en
caso de duda. Este manual estará siempre accesible por el usuario mediante un
botón de ayuda dentro de la aplicación, que podrá encontrar en cualquier ventana
en la que le pueda surgir una duda. En la siguiente figura se puede hacer una idea
de cómo será:
Fácil gestión de datos:
Fácil uso para usuario y programador.
Visión lógica de los datos. Relaciones, tablas, atributos.
Accesible mediante lenguajes sencillos y potentes.
Redundancia mínima que garantice la integridad de los datos y la no repetición de
los mismos.
Figura 2.2
37
Condiciones de integridad: Se da el nombre de las restricciones o condiciones de
integridad a las que se imponen a los valores de los atributos para asegurar la
consistencia de la Base de Datos:
Integridad de entidad:
En una relación no puede haber ningún registro en el que el valor del
atributo clave, o el de algún atributo que forme parte de la clave (si
ésta es compuesta), sea nulo.
La clave nunca se puede repetir, por la definición propia de la clave.
Esta restricción se conoce también con el nombre de integridad de
las claves principales.
Integridad referencial:
Todo valor, no nulo, de una clave externa debe ser un valor de la
clave correspondiente en otra relación, (o en la misma), y debe
existir en alguno de los registros de esta última relación.
Posibles acciones en casos de modificación de los atributos:
De una clave externa en algún registro:
Inserción.
Eliminación.
Actualización del valor de la clave externa en el registro.
De la clave correspondiente en el registro de su relación:
38
Inserción.
Eliminación.
Actualización del valor de la clave.
Control de concurrencias a los datos.
Protección de datos ante accesos no autorizados.
Utilidades de administración de Bases de Datos (backups, gestores,…).
39
2.4 ESTUDIO DE ARQUITECTURA (DAT)
2.4.1 Soluciones al problema planteado
Se ha intentado definir las posibles soluciones que satisfagan tanto los
requisitos impuestos por la organización como las restricciones de diseño. Antes de
configurar las distintas alternativas se ha realizado un filtro, con el objetivo de
desechar aquellas aplicaciones, software y configuraciones que desde un principio no
cumplen los requisitos.
Requisitos HW / SW impuestos:
La red que se va a utilizar para conectar los ordenadores de la
organización en todas las alternativas va a ser una intranet de área local
(LAN).
En cuanto a equipos/ordenadores no se ha impuesto ningún requisito,
se utilizarán los equipos de que se dispone en la organización, la
mayoría de ellos donaciones de otras empresas, pero no por ello
equipos obsoletos. La mayoría de ellos son PIV o . Lo único que sí se
impone es que al menos uno, el servidor donde se aloje la aplicación, ha
de ser más potente, para poder gestionar todas las conexiones sin
riesgo a saturaciones o caídas.
La base de datos ha de ser de entorno Cliente/Servidor, y el servidor se
instalará en el servidor central donde se alojan todas las bases de datos
de las distintas aplicaciones.
40
De entre todos los lenguajes que se han barajado se llegó a la decisión
de que sería alguno de código abierto o software libre con generador de
código fácilmente descargable de Internet o alguno de la familia
Microsoft.
Alternativa 1
Alternativa Opensource
Dado que nos encontramos en una ONG, se planteo la posibilidad de usar
código abierto tanto en lenguaje de programación como en bases de datos.
Tecnología Hardware
Cliente: cualquier ordenador con una tarjeta de red, una cuenta
configurada con acceso a la intranet corporativa y con un mínimo de
memoria RAM como para soportar una conexión a Internet podría valer
para la funcionalidad que va a desempeñar. Dado que la aplicación
estará embebida en formato web, cualquier ordenador con unos
mínimos requisitos podría valer.
Servidor: para alojar la aplicación y dar servicio a tantas peticiones como
personal pueda haber en Entreculturas, se necesita un buen equipo con
un sistema operativo diseñado para ese cometido como podría ser un
Windows 2000 Server, fiable ante caídas y exceso de conexiones. Por
tanto como servidor sería recomendable usar uno de al menos un
procesador de doble núcleo con al menos un par de gigas de RAM, un
disco duro suficientemente grande para albergar todos los futuros
documentos que se vayan registrando en nuestro gestor documental.
Sería recomendable instalar un par de terabytes para evitar una pronta
41
falta de espacio. Además es de tener en cuenta que en GESDOC el nivel
de cantidad de información siempre irá en aumento, ya que según se
van registrando los titulares con sus correspondientes documentos
adjuntos se van almacenando todos en el servidor dedicado, sin vistas a
ser borrados, al menos en un futuro próximo. también se ha de tener en
cuenta que las bases de datos con todas las tablas que GESDOC utiliza se
alojarán también en este servidor dedicado con la carga de transiciones
que esto conlleva.
Tecnología Software
Lenguaje de desarrollo de la aplicación: se emplearía Visual Java, a
través del compilador de código abierto Eclipse.
Sistema de BBDD: Cliente/Servidor con base de datos centralizada.
S.G.B.D.: se utilizará una vez más código abierto: MySQL Server.
Sistema Operativo: para continuar con la dinámica de código abierto, se
plantea Linux Knopix.
Tecnología de Comunicaciones
Conexión entre equipo cliente y servidor: ambas estaciones estarían
conectadas entre sí a través de la red de área local (LAN) de la intranet corporativa.
Los costes de esta alternativa rondarían los 1200€ suponiendo un solo
ordenador cliente y un servidor, y teniendo en cuenta que no hay ningún gasto
en cuanto a licencias se refiere y contando con componentes físicos (hub y
cables).
42
43
Alternativa 2
Alternativa “Microsoft”
Tecnología Hardware
La tecnología Hardware no tiene posibilidad de cambio, ha sido impuesta por el
personal de la organización, dado que al ser un gestor documental con una base de
datos común para toda la organización no hay posibilidad de instalarla en local.
Tecnología Software
Lenguaje de desarrollo de la aplicación: se emplearía Aspx, con
conexiones a base de datos por medio de Componentes o Assemblys
programados en Visual Basic, también se requeriría Java Scripts de tal
manera que se emplearía para todo esto el paquete Visual Studio.net de
Microsoft.
Sistema de BBDD: Cliente/Servidor con base de datos centralizada.
S.G.B.D.: se utilizará SQL Server de Microsoft.
Sistema Operativo: el S.O. escogido sería el Windows XP de Microsoft.
Tecnología de Comunicaciones
44
Idéntica tecnología de Comunicaciones que en la alternativa 1.
Los costes de esta alternativa superarían los 3000€ suponiendo un solo
ordenador cliente y un servidor, teniendo en cuenta que el gasto en cuanto a
licencia se refiere es alto.
45
2.4.2 Selección de Alternativa
Teniendo en cuenta que se trata de una ampliación de la funcionalidad de un
desarrollo ya realizado en un entorno íntegramente Microsoft, finalmente se ha
optado por seleccionar la alternativa número dos, la “alternativa Microsoft”. Aunque
por temas de coste, y teniendo en cuenta que en una ONG los costes suponen un peso
importante en la decisión, se ha optado por esta alternativa dado que precisamente
por su situación de Organización no Gubernamental , Entreculturas recibe anualmente
licencias para productos Microsoft a modo de donación. Y una vez eliminado el coste
de cada alternativa de la ecuación y dado que la tecnología hardware es, por
circunstancias la misma en ambas posibles configuraciones se empieza a evaluar el
resto de componentes de cada alternativa.
En cuanto a sistema operativo, no hay lugar para Linux en una organización en
la que se ha funcionado desde sus comienzos con Windows, y sobre todo hay que
tener en cuenta que supondría un cambio para toda la organización si es que se desea
usar esta aplicación. Y la robustez de Windows 2000 server en el servidor no se ha
conseguido igualar por ningún otro sistema operativo destinado a servidores.
En cuanto a bases de datos, se opta también por Microsoft dado que el resto de
aplicaciones corporativas usan el mismo servidor de bases de datos y la base de datos
de GESDOC pasaría a ser una mas gestionada por el servidor dedicado que se tiene
para tal cometido.
Con respecto al programa compilador para generar la aplicación una vez más se
recurre a Microsoft. Dado que el resto de los programas corporativos GESPRO y
GESDOC ya se programaron en su día en .Net, la manera de mantener una similitud
entre ellos es usando las hojas de estilo que en su día se generaron para la primera
46
aplicación que se hizo, GESPRO. Las comodidades que .NET ofrece a la hora de
programar y que ningún programa “open source” ofrece no pasaron desapercibidas a
la hora de decantarse por .NET. A su vez .NET engloba todos los entornos de
programación que se van a utilizar, por tanto no había cabida para otra alternativa.
47
2.5 DISEÑO EXTERNO (DEX)
2.5.1 Plan de Actuación
Para desarrollar los productos informáticos del proyecto se han seguido los
siguientes pasos:
I. Escoger una metodología para realizar el proyecto según las
características del mismo. (En este caso metodología lineal o en
cascada), y estudiar los conceptos propios de la discapacidad intelectual
II. Identificar las necesidades del sistema a desarrollar.
III. Analizar los requisitos necesarios para satisfacer las necesidades del
sistema.
IV. Estudiar la arquitectura que dé solución a los requisitos planteados.
V. Diseñar una estrategia de planes para pruebas, conversión, formación e
implantación.
VI. Diseñar los cuestionarios acorde con las necesidades del estudio
posterior.
VII. Programar los diferentes elementos Software, necesarios para soportar
la cumplimentación y posterior envío de la información recogida.
48
VIII. Realizar un estudio de la usabilidad del sistema anterior.
IX. Realizar pruebas que aseguren el buen funcionamiento del software.
X. Realizar el mantenimiento de la instalación y recepción de la
información de los cuestionarios.
49
2.6 DISEÑO INTERNO (DIN) Gran parte de las nuevas funcionalidades que conforman el alcance de este
proyecto implican cambios en el diseño interno de Gesdoc v1. A continuación se
muestra el estado en de la base de datos de partida:
tbl_Tipo_Contenido
CP Id_Tipo_Contenido int
Des_Tipo_Contenido char(50)
tbl_Contenido
CP Id_Contenido int
CE1 Id_tipo_Contenido intCE2 Id_tipo_Titular_Noticia intCE5 Id_Campania intCE3 Id_Edicion intCE4 Id_Tamaño intCE6 Id_Medio int Fecha_Alta datetime Fecha_Publicacion datetime Fecha_Suceso datetime Titulo char(100) Comentario char(255) Signatura char(10) Enlace char(120)
tbl_Tipo_Titular_Noticia
CP Id_Tipo_Titular_Noticia int
Des_Tipo_Titular_Noticia char(10)
tbl_Edicion
CP Id_Edicion int
Des_Edicion char(10) Ejemplares char(10)
tbl_Tamaño
CP Id_Tamaño int
Des_Tamaño char(10)
tbl_Campania
CP Id_Campania int
Des_Campania char(50)
tbl_Tipo_Categoria
CP Id_Tipo_Categoria int
Des_Tipo_Categoria char(30)
Categoria
CP Id_Categoria intCP,CE1 Id_Tipo_Categoria int
CE2 Id_Region char(3)CE3 Id_Pais char(3) Poblacion char(3)CE4 Id_Continente int Des_Categoria char(50)
tbl_Continente
CP Id_Continente int
Des_Continente char(15)
tbl_Pais
CP Id_Pais char(3)
Des_Pais char(15)CE1 Id_Continente int
tbl_Region
CP Id_Region char(3)
Des_Region char(25)CE1 Id_Pais char(3)
tbl_Medio
CP Id_Medio int
Des_Medio char(50)
tbl_Tipo_Medio
CP Id_Tipo_Medio char(10)
Des_Tipo_Medio char(10)CE1 Id_Medio char(10)
tbl_Cont_Cat
CP,CE1 Id_Contenido intCP,CE2 Id_Tipo_Categoria intCP,CE2 Id_Categoria int
Estos valores se tomaran de
Gesco
Figura 2.3
50
Y a continuación se procede a mostrar cómo ha de quedar la base de
datos de Gesdoc v2 a su finalización.
Figura 2.4
51
El esqueleto de nuestra nueva base de datos GESDOC v2, como se puede
observar en la figura es la tabla tbl_Contenido, la cual incluye tanto los titulares y
noticias como los anuncios. A raíz de esta tabla van surgiendo todas las ramificaciones
de las que depende, ya que la tabla tbl_Contenido se alimenta del resto de las tablas,
las cuales tendrán su propio mantenimiento como tal. Una de las principales arterias
del cuerpo de esta nueva base de datos es la que enlaza la tabla tbl_Contenido con la
tabla tbl_Categoría. Ésta última a su vez se alimenta de varias tablas, como la tabla
tbl_Sub_Tipo_Categoria, tbl_Tipo_Categoría o las relativas a los datos geográficos
como tbl_Continente, tbl_Pais o tbl_Provincia. En este diagrama se puede observar
que algunas de las tablas no pertenecen directamente a la base de datos de GESDOC
sino que se accede a la base de datos de GESCO para llegar hasta ellas. Son las tablas
sombreadas de amarillo.
Ahora se procede a explicar cada tabla por separado. En la siguiente figura se
puede observar la nueva base de datos GESDOC v2con todas sus tablas al completo.
52
TBL_CATEGORIA: supone una de las principales tablas de GESDOC ya que
enlaza varias de las tablas.
Id_Categoria: id único identificativo de cada categoría y clave primaria
de la tabla.
Id_Tipo_Categoria: id del tipo de categoría a la que pertenece. Clave
primaria de la tabla. Ya no enlaza tbl_Categoria con tbl_Tipo_Categoria.
Ahora el enlace entre dichas tablas se realiza a través de la tabla
tbl_Sub_Tipo_Categoria.
Figura 2.6
53
Des_Categoria: nombre de la categoría.
Descripción: breve descripción de la categoría.
Id_Continente: id del Continente a la que está asociada la Categoría.
Enlaza Tbl_Categoria con Tbl_Continente. (Clave extranjera)
Id_Pais: id del País al que pertenece la Categoría en cuestión. Enlaza
Tbl_Categoria con Tbl_Pais. (Clave extranjera)
Id_Provincia: id de la Provincia a la que está asociada la Categoría.
Enlaza Tbl_Categoria con Tbl_Provincia. (Clave extranjera)
Población: población a la que pertenece la Categoría.
Id_Subtipo_Categoría: id del Subtipo de la Categoría. Enlaza
tbl_Categoría con tbl_Contenido. (Clave extranjera)
TBL_CONT_CAT: tabla que enlaza a cada Contenido (Titular o Noticia) con las
categorías que se le asocian. Consta de tres claves primarias:
Id_Contenido: id del Titular o Noticia
Figura 2.7
54
Id_Categoria: id de la Categoría asociada al Titular o Noticia.
El Id_Contenido se repetirá tantas veces como categorías asociadas a cada
titular o noticia haya.
TBL_EDICIÓN: tabla que almacena los distintos tipos de edición. Contiene:
Id_Edición (Clave Primaria)
Des_Edición: nombre del tipo de edición.
TBL_CONTENIDO: es la tabla principal de GESDOC ya que es la que contiene
la información de los Titulares y Noticias. Es el esqueleto de la base de datos y
enlaza directa o indirectamente con todas las demás tablas de GESDOC.
Id_Contenido: Clave primaria que identifica a cada documento.
Id_Tipo_Titular_Noticia: enlaza Tbl_Contenido con
Tbl_Tipo_Titular_Noticia (Clave Extranjera).
Figura 2.8
Figura 2.9
55
Id_Campaña: enlaza Tbl_Contenido con GESCO_Tbl_Campanias. (Clave
Extranjera)
Id_Edición: enlaza Tbl_Contenido con Tbl_Ediciónes. (Clave Extranjera)
Id_Tamanio: enlaza Tbl_Contenido con Tbl_Tamanios. (Clave Extranjera)
Id_Medio: enlaza Tbl_Contenido con GESCO_Tbl_Medios. (C. Extranjera)
tipo_colab_medio: tipo de medio, traída de GESCO_Tbl_Medios.
Fecha_Alta: campo tipo fecha. Fecha en que se registró el documento.
Fecha_Publicación: campo tipo fecha. día en que se publicó el
documento en el medio correspondiente.
Fecha_Suceso: campo tipo fecha. día en que aconteció lo narrado en el
documento.
Titulo: campo tipo texto. Titulo que describe el artículo. Palabras claves
para su futura búsqueda.
Comentario: campo de hasta 255 caracteres para que el usuario haga
alguna anotación personal o incluso describa el documento.
Enlace: campo destinado a almacenar el link a la pagina donde reside el
articulo o bien para que se almacene la ruta absoluta del archivo que
contiene el documento en el servidor.
Id_Tipo_Contenido: campo que determina si el contenido es un titular o
bien un anuncio.
56
Ejemplares: campo numérico que alberga la tirada que tiene el medio.
Id_Tipo_Enlace: contiene únicamente el valor del tipo de enlace que
posee un documento. Es decir, si es un link a una página o una ruta a un
archivo.
Id_Sección: contiene el nombre de la sección en la que se ha publicado
el Anuncio Entreculturas.
Figura 2.10
57
Donación: campo de tipo buleano, almacena el dato de si el anuncio ha
sido publicado de manera gratuita a modo de donación por parte de la
editorial.
Pagado: campo de tipo buleano, almacena el dato de si el anuncio ha
sido publicado de manera gratuita a modo de donación por parte de la
editorial.
Id_Continente: id del Continente a la que está asociada el Contenido.
Enlaza Tbl_Contenido con Tbl_Continente. (Clave extranjera)
Id_Pais: id del País al que pertenece la Categoría en cuestión. Enlaza
Tbl_Contenido con Tbl_Pais. (Clave extranjera)
Id_Provincia: id de la Provincia a la que está asociada la Categoría.
Enlaza Tbl_Contenido con Tbl_Provincia. (Clave extranjera)
Población: nombre de la población.
Num_Pagina: número de página en el que fue publicado el contenido en
caso de ser prensa escrita
TBL_CONTINENTE: tabla que contiene los Continentes. Consta de:
Id_Continente (Clave Primaria)
Des_Continente: Nombre del Continente.
58
TBL_PAIS: tabla que contiene los Países, y mantiene la asociación con el
Continente al que pertenecen. Consta de:
Id_Pais (Clave Primaria)
Des_Pais: nombre del País.
Id_Continente: id del Continente al que pertenece dicho país. Este
campo enlaza Tbl_Pais con Tbl_Continente. (Clave extranjera)
TBL_PROVINCIA: tabla que contiene las Provincias que se hayan dado de
alta. Esta tabla enlaza Tbl_Provincia con Tbl_Pais. Contiene:
Id_Provincia (Clave Primaria)
Des_Provincia: nombre de la Provincia en cuestión.
Id_Pais: id del País que contiene a dicha Provincia. (Clave extranjera)
Figura 2.11
Figura 2.12
59
TBL_TAMANIO: tabla que contiene los distintos tamaños de Anuncio. Consta
de:
Id_Tamanio (Clave Primaria)
Des_Tamanio: Descriptor del Tamaño de Anuncio.
TBL_CATEGORIA: tabla que contiene los tipos de Categoría existentes.
Consta de:
Id_Tipo_Categoria (Clave Primaria)
Des_Tipo_Categoria: Nombre del Tipo de Categoría
Figura 2.13
Figura 2.14
Figura 2.15
60
TBL_TIPO_CONTENIDO: tabla que contiene los tipos de Contenido
existentes. Como por ejemplo Titulares o Anuncios. Consta de:
Id_Tipo_Contenido (Clave Primaria)
Des_Tipo_Contenido: Nombre del Tipo de Contenido
TBL_TIPO_TITULAR_NOTICIA: tabla que contiene los tipos de Titulares o
Noticia existentes. Consta de:
Id_Tipo_Titular_Noticia (Clave Primaria)
Des_Tipo_Titular_Noticia: Nombre del Tipo de Titular o Noticia.
TBL_TIPO_ENLACE: tabla que contiene los distintos tipos de enlace al
contenido que hay. Consta de:
Id_Tipo_Enlace (Clave Primaria)
Figura 2.16
Figura 2.17
61
Des_Tipo_Enlace: Descriptor del Tipo de enlace.
TBL_SECCION: tabla que contiene los distintas secciones de una publicación.
Consta de:
Id_Sección (Clave Primaria)
Des_Sección: Descriptor de la sección.
TBL_SUBTIPO_CATEGORIA: tabla que contiene los subtipos de categoría
que se hayan dado de alta. Esta tabla enlaza tbl_Tipo_Categoria con Tbl_Categoria.
Contiene:
Id_Subtipo_categoria (Clave Primaria)
Id_Tipo_Categoria: Id del tipo de categoría al que pertenece. (Clave
extranjera).
Des_subtipo_Categoria : descriptor del subtipo de categoría.
Figura 2.18
Figura 2.19
62
Figura 2.20
63
2.7 PROGRAMACIÓN (PRO)
2.7.1 Introducción al ASP (Active Server Pages)
ASP o lenguaje de páginas activas de Microsoft estaría englobado dentro de los
lenguajes ISS (Include Server Side) de 2ª generación, es decir, que ASP es una evolución
de los CGI’s (Common Gateway Interface).
ASP no define un lenguaje de programación con sus sentencias de control, sus
estructuras de almacenamiento,... sino que define una serie de objetos de servidor, los
cuales tienen una serie de métodos que se podrán utilizar para cosas como acceso a
base de datos, lectura de ficheros,...
ASP se ayuda de dos lenguajes de script, como son JavaScript y VBScript para
implementar toda la parafernalia necesaria para que se vea ASP como un lenguaje de
programación.
En nuestra aplicación se utilizará VBScript en la parte servidor y JavaScript en la
parte cliente.
El esquema de funcionamiento de ASP sería; una maquina cliente realiza una
petición de una página ASP. Esta petición llega a una maquina servidor la cual
interpreta el código de esa página ASP. Dicho código puede tener accesos a ficheros o
bases de datos (Base de Información).
El resultado de interpretar la página ASP es una página HTML, la cual se le envía
al usuario. Es decir, el usuario no llega a ver el código ASP, sino que ve el resultado de
interpretar dicho código: una página HTML.
64
En conclusión se podría decir que una aplicación en ASP tiene como objetivo
diseñar una página web. Todas las salidas de información que se realicen en una
página ASP serán de código HTML o texto.
Dentro de una página ASP se puede encontrar:
Código ASP, se devolverá aquel código que sea susceptible de cambiar, o el
encargado de acceder a una base de datos.
Código HTML, partes del código HTML que permanezcan inmutables, esas
partes de código se incluirán sin más, como si de una página HTML se
tratara.
Ambos códigos se mezclarán dentro de la página ASP sin ningún orden. En
ASP los bloques de sentencias irán entre los caracteres <% y %>.
Para incluir un comentario dentro de los bloques de sentencias se puede
hacer de dos formas. Una sería anteponiendo una comilla o bien mediante
la palabra REM.
Las páginas ASP se encuentran dentro de un servidor, dicho servidor
deberá de contener el intérprete de ASP (asp.exe) y sus librerías asociadas.
Es por ello que para poder ver el resultado de nuestras páginas ASP se
tendrá que tener instalado un servidor. Para ello se dispone de dos
opciones: IIS (Internet Information Server) si se está trabajando sobre una
plataforma Windows NT o bien el PWS (Personal Web Server) si se está
trabajando sobre una plataforma Windows 9x o Windows 2000.
Una vez instalados el servidor se deberá de alojar la página ASP en algún
directorio que tenga permisos de ejecución.
65
2.7.2 Introducción a JavaScript
Javascript es un lenguaje de programación utilizado para crear pequeños
programitas encargados de realizar acciones dentro del ámbito de una página web.
Con Javascript se pueden crear efectos especiales en las páginas y definir
interactividades con el usuario. El navegador del cliente es el encargado de interpretar
las instrucciones Javascript y ejecutarlas para realizar estos efectos e interactividades,
de modo que el mayor recurso, y tal vez el único, con que cuenta este lenguaje es el
propio navegador.
Javascript es el siguiente paso, después del HTML, que puede dar un
programador de la web que decida mejorar sus páginas y la potencia de sus proyectos.
Es un lenguaje de programación bastante sencillo y pensado para hacer las cosas con
rapidez, a veces con ligereza. Incluso las personas que no tengan una experiencia
previa en la programación podrán aprender este lenguaje con facilidad y utilizarlo en
toda su potencia con sólo un poco de práctica.
Entre las acciones típicas que se pueden realizar en Javascript hay dos
vertientes. Por un lado los efectos especiales sobre páginas web, para crear contenidos
dinámicos y elementos de la página que tengan movimiento, cambien de color o
cualquier otro dinamismo. Por el otro, javascript nos permite ejecutar instrucciones
como respuesta a las acciones del usuario, con lo que se pueden crear páginas
interactivas con programas como calculadoras, agendas, o tablas de cálculo.
Javascript es un lenguaje con muchas posibilidades, permite la
programación de pequeños scripts, pero también de programas más grandes,
orientados a objetos, con funciones, estructuras de datos complejas, etc. Toda esta
potencia de Javascript se pone a disposición del programador, que se convierte en el
verdadero dueño y controlador de cada cosa que ocurre en la página.
66
2.7.3 Código
Dado que es imposible mostrar todos los cambios que se han realizado en el
código desde la ampliación de funcionalidad de Gesdoc v1 a Gesdoc v2 y dada la
extensión de la programación de este proyecto, que contiene más de 15 formularios
ASPX, 7 componentes o assembly codificados en Visual Basic y otras tantas páginas con
funciones en Java Script, se van a resaltar algunas pinceladas de la programación
utilizada en alguna de las nuevas funcionalidades.
Para exportar a MS Excel® los resultados de los grid que se llenan al hacer
búsquedas en los formularios de búsquedas de contenidos se desarrolló código,
muestra del cual se expone a continuación:
67
Para externalizar la búsqueda de categorías a un formulario aparte para
descargar al formulario principal de contenidos, se hubo de desarrollar un nuevo
formulario en aspx el cual se muestra a continuación:
Los menús que se encuentran en la página principal y que han sido modificados
de la versión 1.0 de Gesdoc a la 2.0 después del estudio de usabilidad llevado a cabo al
personal del departamento de comunicación de Entreculturas, se muestran a
continuación.
Dichos menús han sido programados en XML como se muestra a
continuación:
Figura 2.21
Figura 2.22
68
Para las gestiones de datos geográficos: continentes, países, provincias, así
como para el resto de filtros de búsqueda: tipo de categorías, tipo de contenidos etc.
se ha utilizado únicamente un formulario: gc_admin_BBDD.
Figura 2.23
69
Para ello, se han modificado en función del modo de acceso todas las etiquetas,
botones y nombres de los combos dinámicamente. Se hacían requests al QueryString
que nos devolvía el nombre del menú seleccionado, así como la tabla a la que se debía
acceder. Con estos datos se podía decorar el formulario en función de cada menú
seleccionado.
Para ocultar dinámicamente los dropdownlist, textbox, labels y demás
componentes del formulario en función del modo de acceso se ha recurrido a llamadas
a funciones javaScript embebidas.
Para mantener los colores y apariencia corporativa de la Organización se ha
recurrido a hojas de estilo css.
70
En Gesdoc v2 se decidió que al pulsar sobre el botón calendario para
seleccionar una fecha, pongamos la fecha de suceso, en función de su ubicación en el
formulario, la ventana emergente del calendario se abriese hacia arriba o hacia la
izquierda. Para ello se recurre a las funciones programadas en javascript que se
muestran a continuación:
Para llenar todos los dropdownlist de la aplicación se ha programado una
única función que los llene válida para cualquier dropdownlist. La función
71
LlenarCombo:
La cual, recibe como parámetros de entrada, la tabla de la que tiene que
recoger la información, el nombre de la columna id de esa tabla, el nombre de la
columna descripción de esa tabla, el combo que ha de rellenar, una variable sError por
referencia por si tiene que devolverle algún valor de error, y a modo opcional también
se le pasa a esta función un valorId por si necesitase hacer una llenado condicionado.
Por ejemplo el combo de países solo se llenaría en función de un valor id de
continente.
Para comunicarse con la base de datos se utilizan Componentes, Assemblys o
Dll’s programadas en Visual Basic. Es en ellas en las que se accede directamente a la
base de datos. En la siguiente figura se puede observar como se llama a la función
bReferencia que está dentro del componente gdTipos. La función bReferencia que esta
72
En el componente gdTipos llena el dataTable dtReferencia que se le ha pasado
en modo referencia con los resultados que ha recibido tras ejecutar la query
pertinente.
73
Public Function bReferencia(ByVal sCadenaConexion As String, _
ByRef dtResultados As DataTable, ByVal nTabla As String, ByVal vstCampos As stCampos, _
ByRef sError As String, Optional ByVal valorID As String = "0") As Boolean
Try
Dim sQuery As String
Dim objBD As New GESDOC.GC_AccesoBD
objBD.sCadenaConexion = sCadenaConexion
If nTabla = "vmedios" Then
If valorID = "0" Then
' sQuery = "select distinct tipo_medio,tipo_medio_id from vmedios"
sQuery = "select distinct tipo_medio_id,tipo_medio from gesco_ec.dbo.vMedios"
Else
sQuery = "select colaborador_id, nombre_comercial, tipo_medio_id from
gesco_ec.dbo.vMedios where tipo_medio_id = " & valorID
End If
ElseIf nTabla = "vcampanias" Then
sQuery = "select campania_id,campania from gesco_ec.dbo.vCampanias"
Else
74
Los Titulares y los Anuncios acceden a la misma tabla de la base de datos de
Gesco, la tabla tbl_Contenido, y ambos reciben un id que el propio sistema genera
secuencialmente en función del último documento registrado.
Para dar un alta de titular o anuncio, la función aTitular comprueba cual ha sido
el número del último titular registrado en la tabla tbl_Contenido, para ello se introduce
el contenido de la tabla en un datatable, y luego se chequea el número de filas que
este datatable tiene. Si el número de filas es 0, se le dará el id 1 al titular, y si hay más
de 1 fila se le añadirá 1 al número de filas y se asignará ese id. Posteriormente se
procede a insertar el valor hallado junto con el resto de datos recibidos como
parámetros.
75
2.8 PRUEBAS DEL SISTEMA (PRU)
Una vez desarrollados y probados cada uno de los programas y componentes
que forman el software, deben realizarse una serie de pruebas para conseguir integrar
todo el sistema, de acuerdo al Plan de Pruebas establecido.
El objetivo global de esta fase es someter al sistema desarrollado y a sus
componentes, a una serie de verificaciones encaminadas a garantizar un nivel de
fiabilidad aceptable.
Si los resultados de las pruebas son aceptables, se procederá a la aceptación de
las mismas y a la implantación de las mismas. En caso contrario habrá que subsanar las
anomalías encontradas y esto conlleva revisar el código creado.
El ciclo de pruebas recoge las distintas pruebas a las que puede someterse el
software, desde las pruebas de encadenamiento entre programas, hasta las pruebas
de estrés para diagnosticar el rendimiento del sistema ante condiciones extremas.
Como consecuencia de las pruebas realizadas sobre un entorno parecido al de
producción se desarrollará el manual de instalación y configuración, determinándose
qué componentes deben instalarse en cada equipo.
76
2.8.1 El Entorno de Pruebas o Certificación
En el Plan de Pruebas se fijó la necesidad de un entorno apropiado para
ejecutar las pruebas de software.
El entorno tanto software como hardware debe ser similar o en lo posible
idéntico al entorno final donde se explotará la aplicación.
El plan de pruebas debe establecer los requisitos tanto hardware, software,
recursos humanos y herramientas de pruebas que deben utilizarse.
El Entorno de Pruebas suele adaptarse y configurarse antes de realización de las
pruebas, de modo que se consiga simular el entorno final donde va a ser explotada la
aplicación.
Será necesario un mínimo de volumen de aplicación para llevar a cabo cada
prueba, para cerciorarse de la fiabilidad de la aplicación.
El equipo de pruebas podrá estar formado por personas ajenas al proyecto
pero, en este caso, el programador de la aplicación será el encargado de llevar a cabo
las diferentes pruebas.
Para la realización de las pruebas se utilizarán todas las herramientas software
necesarias para verificar el buen funcionamiento del sistema y de la aplicación.
Para comprobar el rendimiento del programa se utilizarán simuladores, que
permiten simular un chorro de transacciones para comprobar el comportamiento del
sistema ante los diferentes estados por los que pueda pasar.
77
Las pruebas realizadas al sistema son las siguientes:
Pruebas de encadenamiento: garantizan la buena comunicación entre los
componentes de la aplicación.
Pruebas de integración: una vez verificados la buena comunicación entre los
diversos módulos de la aplicación se procederá a integrar todos sus componentes:
bases de datos, ficheros y ventanas.
La integración de todos los componentes se puede llevar a cabo de una sola
vez o ir dividiéndola según las necesidades de negocio facilitando la integración de
todo el sistema.
En este caso la integración de los componentes se ha ido dividiendo según
la lógica de negocio para llegar a una integración de los módulos más específica.
Pruebas de explotabilidad del sistema: estas pruebas van encaminadas a garantizar
la facilidad que tiene el sistema para su explotación u operación.
Pruebas de seguridad: se comprobarán los mecanismos de seguridad referentes a la
eficacia y accesibilidad del sistema. Además se comprobará que se cumplen los
requisitos que determinan qué acciones pueden realizar los diferentes tipos de
usuarios.
Pruebas de sobrecarga: estas pruebas permiten verificar la agilidad del sistema
cuando se le somete a grandes volúmenes de tareas.
Pruebas de recuperación: verificarán la recuperación de los datos en caso de caída
del sistema o daños en la misma. Los casos más frecuentes donde se puso a prueba
78
la aplicación fueron por fallos del sistema operativo que obligaron a cerrar la
aplicación de una forma inesperada y fallos en el suministro eléctrico.
Pruebas de usabilidad: el objetivo de esta prueba es autentificar que el sistema es
de fácil acceso y manejabilidad por parte del usuario final garantizando que cumple
todos los requisitos esperados por éste.
Pruebas de rendimiento: en este tipo de aplicación no se pueden diseñar procesos
aperiódicos para gestionar las anomalías, en caso de que éstas se produzcan,
debido a que, dotar a los procesos de recuperación, sería una tarea muy costosa, la
cuál sería inviable para el desarrollo del proyecto.
Pruebas de regresión: dichas pruebas se realizan para detectar anomalías o errores
de software, que pueden estar provocados por un mal diseño o una mala
codificación.
Al añadir cualquier mejora al sistema, deberán volverse a repetir las
pruebas realizadas hasta la fecha, porque será necesario comprobar que dichos
cambios no han alterado el buen funcionamiento de la aplicación.
Pruebas de aceptación de usuario: estas pruebas son realizadas por el usuario final
desde el ordenador personal donde va a hacer uso de la aplicación. El objetivo
principal de esta prueba es comprobar que el sistema operativo acepta la
aplicación y que no se produce ningún tipo de incidencia. Esta prueba únicamente
acredita la aceptación por parte del usuario final, ya que éste comprobará la
funcionalidad del sistema en su entorno final de trabajo, es decir, su puesto de
trabajo o bien su ordenador personal de casa.
79
2.9 IMPLANTACIÓN (IMP)
Una vez probada la integridad del software del sistema y especificada su
instalación y configuración, se debe transferir el software producto en el Centro de
Desarrollo para llevar a cabo la explotación del sistema.
Esta transferencia debe prever la migración necesaria del software a un
número elevado de estaciones cliente. El conjunto de las actividades a desarrollar en
esta fase ha sido previsto en las planificaciones realizadas anteriormente siendo en
esta fase donde se realiza la materialización de los mismos.
Las actividades a desarrollar son diversas y distintas entre sí, no existiendo
secuencia de ejecución en las mismas exceptuando las establecidas en el plan de
implantación.
Todo ello obliga a realizar un gran esfuerzo de coordinación.
El software deberá competir con otros programas de aplicación para utilizar los
recursos necesarios de procesadores, memoria, discos de almacenamiento
secundarios y red.
Las pruebas de sobrecarga y rendimiento han determinado el umbral de hasta
donde se puede ralentizar el sistema según la sobrecarga de este.
Una vez certificadas estas pruebas, el cliente dará por aceptado su sistema y se
cerrará el ciclo de desarrollo del proyecto, debiéndose documentar el proyecto en
base a todos los entregables generados a lo largo del ciclo de vida.
80
Pruebas de implantación: las realiza el personal encargado de la implantación, en
este caso el encargado será también el programador de la aplicación y lo hará junto
al usuario para poder comprobar que todo funciona correctamente. Garantiza el
correcto funcionamiento del software, su explotación, funcionamiento y
distribución.
Las herramientas de gestión de configuración proporcionarán la seguridad
de que el software que se está migrando a las diferentes máquinas de producción
es software probado en el entorno de pruebas.
Una vez instalado el software se realizarán básicamente dos pruebas, una
de ellas tiene como objetivo certificar el correcto funcionamiento de la aplicación
compitiendo por sus recursos de máquina y red.
La otra prueba necesaria será la aceptación del usuario, el cuál indicará
desde su puesto de trabajo y bajo los diferentes perfiles en los que pueda operar,
el correcto funcionamiento de la aplicación.
Superada esta prueba el sistema quedará abierto a los usuarios, haciendo
un seguimiento de las peticiones de éstos y las reacciones del sistema ante las
diversas peticiones.
Plan de Contingencias: al desplegar el software de la aplicación sobre las equipos
de explotación y realizar las pruebas de implantación, se podrían encontrar una
serie de disconformidades que hacen inviable la implantación en este estado. Para
dar marcha atrás, es necesario dejar el sistema tal como estaba antes de iniciar la
implantación.
Las actividades a llevar a cabo quedan recogidas en el plan de
contingencias.
81
Suele aportarse como anexo al plan de implantación, en aquellos módulos
de la aplicación que resulten críticos bien para la organización o bien para los
interfaces externos con los que dialoga y se actualiza.
Documentación final del proyecto: la experiencia vivida durante el desarrollo del
proyecto puede resultar beneficiosa para otros proyectos o equipos de trabajo. Si
se inicia otro proyecto para la misma área de conocimiento en la organización, se
tendrá terreno ganado con los modelos de datos y los procesos realizados.
Si es un nuevo proyecto para un área diferente pero una misma
problemática, pueden reutilizarse multitud de componentes de este proyecto.
Una buena documentación del software desarrollado es muy importante
para el mantenimiento de la aplicación, puesto que simplifica enormemente los
imprevistos que puedan surgir. Normalmente los equipos de mantenimiento
suelen quejarse de la documentación existente de los diversos sistemas que se
desarrollan, puesto que para realizar modificaciones sobre el código de un
programa es muy importante tener en cuenta el funcionamiento de todos los
módulos de la aplicación.
Existen herramientas software que realizan de una manera inteligente la
documentación del proyecto, pero por restricciones económicas no fueron viables.
Esta herramienta permite capturar, organizar, mantener, recuperar y compartir el
conocimiento de una organización.
82
2.10 ESTUDIO DE USABILIDAD
La fase de implantación desarrollada en el capítulo anterior finaliza con la
aceptación por parte del usuario final. Para asegurar la calidad del software
desarrollado y mejorar el interfaz grafico de usuario de la aplicación para ser más
agradable fácil e intuitiva se ha realizado un estudio de usabilidad que a continuación
se describe.
El objetivo de este capítulo es realizar un análisis de usabilidad mediante las
técnicas definidas en los estándares ISO para el sistema GESDOC que desarrolla el
presente proyecto.
El concepto usabilidad tiene una doble definición oficial establecida por la
Organización Internacional para la Estandarización (ISO):
La usabilidad se refiere a la capacidad de un software de ser comprendido,
aprendido, usado y ser atractivo para el usuario, en condiciones específicas de
uso.
Usabilidad es la eficiencia y satisfacción con la que un producto permite
alcanzar objetivos específicos a usuarios específicos en un contexto de uso
específico.
En la primera definición se hace énfasis en los atributos del producto, los cuales
contribuyen a su funcionalidad y eficiencia. La usabilidad depende tanto del producto
como del usuario.
Por ello un producto no es en sí usable, sólo tendrá la capacidad de ser usado
en un contexto particular y por usuarios en particular.
83
La segunda definición en cambio se centra en el concepto de calidad, a cómo el
usuario realizará tareas específicas en escenarios concretos y con un grado de
efectividad.
La Ingeniería del Software aún se sigue centrando casi exclusivamente en
atributos del software relacionados con el rendimiento o la fiabilidad. Actualmente el
software está dirigido a un público cada vez más amplio, por ello la usabilidad es un
concepto fundamental para el éxito de un producto software.
La usabilidad es un concepto en auge en el desarrollo de software y muy
extendido en el desarrollo de sistemas y aplicaciones web, sin embargo la usabilidad
tiene también muchas otras acepciones, es un término que abarca un gran abanico de
palabras relacionadas entre sí. Por ejemplo, algunos autores describen que la
usabilidad se refiere al grado de eficacia del probable uso de la documentación por
parte de sus usuarios finales durante la ejecución de tareas dentro de las restricciones
y requerimientos del entorno.
Los conceptos de efica cia y satisfacción del usuario, se relacionan
respectivamente con los conceptos de uso y utilidad. La usabilidad también se asocia al
grado de aceptación que un producto software tiene por parte de los usuarios finales.
La norma ISO 9241-11, define un aspecto de la usabilidad como: hasta qué
punto un producto puede usarse por usuarios específicos para lograr los objetivos
específicos con eficacia, eficiencia y satisfacción en un contexto específico de uso.
2.10.1 Estándares de Usabilidad
La preocupación de la comunidad internacional sobre la definición de
estándares, no solo para procedimientos y procesos, sino también para requerimientos
y atributos de productos y servicios, ha permitido la creación de la International
Standard Organization, comúnmente conocida por el nombre de ISO.
84
La organización ISO ha diseñado diversos estándares que tratan los aspectos
ergonómicos de sistemas informáticos y específicamente el diseño centrado en el
usuario. La European Usability Support Centres clasifica los estándares internacionales
relacionados con el diseño centrado en el usuario en dos grupos:
Estándares internacionales orientados a proceso, estos estándares especifican
los requerimientos para el diseño de procedimientos y procesos.
Estándares internacionales orientados a producto, estos estándares especifican
los atributos requeridos para el diseño y desarrollo de interfaces de usuario. En
algunos casos los requerimientos son definidos en términos de desempeño.
85
En la siguiente tabla se describen resumidamente los estándares relacionados
con la usabilidad establecidos por la ISO:
Figura 2.24
86
87
2.10.2 Objetivos de los test de usabilidad
Los test de usabilidad se definen como los procedimientos de análisis aplicados
a los usuarios potenciales de un producto software, en los cuales se verifica si dicho
producto ha sido desarrollado de acuerdo con los requerimientos predeterminados de
usabilidad.
El objetivo principal de los test es identificar y rectificar deficiencias de
usabilidad existentes. El público objetivo al que van a ser dirigidos dichos test serán
usuarios divididos en tres niveles definidos a continuación:
Usuario profesional: usuario que dedica su actividad laboral a la gestión e
implementación de bases de datos. Se identificarán como: usuario experto.
Usuarios avanzados: usuarios que no tienen su actividad laboral centrada en la
administración de bases de datos pero han usado o tienen conocimiento en
dicho área. Se identificarán como: usuario avanzado.
Usuarios básicos: usuarios que disponen de conocimientos teóricos sobre bases
de datos y que tienen experiencia previa en la utilización de herramientas de
gestión, aunque haya sido de forma esporádica.
Los test de usabilidad se caracterizan por la flexibilidad con la que pueden ser
aplicados a diversos entornos. Su aplicación puede ser realizada tanto de manera
formal como informal, donde cada uno de los métodos posee sus ventajas e
inconvenientes.
En este caso, se hará uso del método formal de test de usabilidad. Dicho
método se caracteriza por la fiabilidad y validez de los procedimientos de test. Es
necesario que los test sean aplicados a un grupo de usuarios (preestablecido en
principio en mínimo 3 y máximo 12 personas). Debe ser un grupo compuesto por una
88
distribución homogénea de entre la tipología expuesta con anterioridad dentro de un
entorno controlado que debe ser previamente seleccionado. Este entorno puede ser
tanto el centro real de trabajo de los usuarios como una sala acondicionada para tal fin
en ese centro o una sala ajena al centro. Es preferible que el usuario se desenvuelva
con soltura en el entorno y se sienta cómodo.
Complementariamente a la información que los test de usabilidad
proporcionan, es recomendable guardar otro tipo de información que se genera
durante la realización de las pruebas como por ejemplo las preguntas de los usuarios
antes de la realización de los test, comportamiento del grupo de usuarios, incidencias
ocurridas en el proceso o la duración de las pruebas.
Para tal fin se pueden emplear diversos mecanismos de grabación tanto de
audio como de video, según se estime necesario. A su vez se pueden emplear
aplicaciones software que guarden la operativa de los usuarios en los ordenadores
para visualizar con posterioridad los procesos de trabajo. Es recomendable informar
con antelación al grupo de usuarios que las pruebas van a ser grabadas o se va a
emplear algún modo de grabación. Se pretende evitar que el usuario se sienta
incómodo o que el usuario pueda percatarse que las pruebas están siendo grabadas
durante la realización de las mismas y afecte de manera significativa al resultado.
Con los datos obtenidos mediante los test y la información complementaria,
deben ser analizados y en último término interpretados para generar las conclusiones
oportunas. Estas conclusiones deben llevar a la elaboración de las directrices de
modificación de la herramienta software testeada para que cumpla con los requisitos
definidos por la usabilidad.
89
2.10.3 Tipos de test de usabilidad
Dentro de la diversa tipología de test disponibles, se definen cuatro tipos de
test principales asociados a diferentes fases del ciclo de vida clásico de desarrollo de
una aplicación, permitiendo la aplicación de las distintas directrices propuestas para la
mejora del programa, por parte de cada test.
Los cuatro tipos de test se describen a continuación:
Exploratorio.
Evaluación de operaciones y aspectos del producto.
Validación.
Comparativos.
En la siguiente tabla se muestra un resumen de los cuatro tipos de test
propuestos.
90
Figura 2.25
91
2.10.4 Entornos De Test Predefinidos
Para la realización de los test de usabilidad se requieren entornos altamente
preparados, debido a la existencia de factores tales como el cambio en la mentalidad
del grupo de usuarios que realizan los test que afectan directamente a los resultados
que aportan y las propuestas de cambio generadas.
También es necesario realizar una elevada inversión en la información sobre la
usabilidad a los grupos de trabajo para que tengan en cuenta la importancia que esta
ciencia tiene posibilitando que el usuario de una prueba se implique de forma
significativa en la misma.
Los test requieren una infraestructura tecnológica para ser realizados, la cual
forma parte de la propia definición de los test. La sofisticación de los entornos en los
que se realizan los test afectan directamente al resultado de dichos test.
A continuación se describen los entornos físicos propuestos.
92
Habitación simple (complejidad simple):
Configuración de entorno más sencillo y barato, debido a las necesidades del
proceso de test determinadas por el grupo de trabajo y por la infraestructura
tecnológica necesaria para realizarlos.
Las ventajas de esta configuración consisten en:
Buena percepción del usuario que realiza el test.
Mayor interacción entre el equipo de trabajo durante el proceso de test.
El usuario de test no se siente solo durante el proceso de test.
Las desventajas consisten en:
El testeador puede influir en el comportami ento del usuario de test,
debido al reducido espacio físico.
Dicho espacio no proporciona un entorno de trabajo confortable.
Habitación simple (complejidad mediana):
Esta configuración determina que el espacio requerido será un poco mayor,
debido a la necesidad de la infraestructura tecnológica y de soporte usada en el test.
93
Las ventajas de esta configuración consisten en:
La libertad que el testeador tiene para realizar sus apuntes u otro tipo
de registro sin molestar al usuario de test.
El usuario de test no estará solo durante el sesión de test.
El usuario de test podrá llevar a cabo métodos de colecta de datos.
Las desventajas consisten en:
La pérdida de la proximidad con el usuario de test.
El usuario puede sentirse solo, aunque que no lo esté.
Habitación doble (complejidad mediana):
Esta configuración, denominada de sala de observación electrónica, implica
altos costes, debido a la necesidad de separación espacial de los observadores
respecto al testeador y al grupo de usuarios de test. Se necesita más infraestructura
tecnológica y de soporte. También se recomienda la entrega de un manual al usuario
del test para la realización de posibles consultas.
Las ventajas de esta configuración consisten en:
Se garantiza todas las ventajas expuestas en la configuración de
Habitación simple.
94
Se puede realizar una observación total, incluyendo registros y
conversaciones entre los observadores, sin interferencias en el usuario
de test.
Las desventajas consisten en:
El testeador puede influir en el comportamiento del usuario de test.
La no disponibilidad de espacio físico para el entorno de desarrollo de
las pruebas.
Habitación doble (complejidad alta):
Esta configuración se caracteriza por la distribución de dos salas dedicadas a los
procesos de test, lo que implica en una inversión elevada para el entorno. En la
primera sala, se ubica el usuario de test. En el segundo, se observa y controla el
proceso de test, aunque el testeador puede estar en la primera sala con el usuario de
test. Se requiere el uso de una infraestructura tecnológica compleja para llevar a cabo
el proceso de test.
Las ventajas de esta configuración consisten en:
La posibilidad de colecta paralela de datos.
La posibilidad de comunicación entre el equipo de test sin causar
interferencia en el usuario de test.
La posibilidad de ubicar diversos observadores en la segunda sala
durante el proceso de test.
95
Las desventajas consisten en:
La posibilidad de que se genere un entorno muy impersonal, lo que
puede influir al usuario de test.
La imposibilidad de ver todas las acciones del usuario de test.
Entorno móvil
Esta configuración es una alternativa a los tipos de configuración descritos
anteriormente, debido a que no está asociado a un espacio determinado. De esta
manera, se puede usar la infraestructura tecnológica que se crea más apropiada en
lugar de la disponible en el entorno fijo. Para esta configuración, no se necesita una
elevada inversión.
Las ventajas de esta configuración consisten en:
Es una solución donde la relación coste/eficacia es muy buena.
La portabilidad de la infraestructura.
Se usa poco tiempo, debido al fácil montaje del entorno.
Las desventajas consisten en:
Necesidad de garantizar la adaptabilidad del entorno.
96
Para la realización de los test de usabilidad del sistema GESDOC se ha optado
por un entorno simple de complejidad baja. No va a ser grabada la sesión con ningún
tipo de herramienta o aplicación puesto que no se ve necesario y no aportaría
información relevante y tampoco se va a hacer uso de un manual de usuario para las
pruebas, ya que uno de los objetivos y aspectos a estudiar es determinar si el software
es lo suficientemente intuitivo.
2.10.5 Limitaciones de los test de usabilidad
El objetivo principal de los test de usabilidad es intentar evaluar si un producto
ha sido desarrollado según los requisitos predeterminados de la usabilidad. No
obstante, dichos test no podrán garantizar en un 100% el éxito del producto si se
utilizará de forma efectiva. Las limitaciones que la usabilidad tiene se describen a
continuación:
En el proceso de recogida de datos, la generalización de los resultados puede
estar afectada por la carencia de control sobre variables no previstas durante la
realización de los test.
En la mayoría de los casos, se realizan los procedimientos de test considerando
técnicas alternativas de evaluación de usabilidad o técnicas formales, lo que podría
suponer una situación artificial afectando a los resultados.
Aunque se obtengan resultados significativos en los test, no se puede garantizar
que el producto será usado de forma eficiente.
No se puede garantizar que los usuarios que participan en los test representan
completamente los usuarios destino de la aplicación.
97
En general, la posibilidad de usar técnicas equivocadas durante la realización de
los test conlleva a la reducción de la precisión de los resultados y el aumento de costes
y tiempo de realización.
Considerando las posibles limitaciones que pueden afectar los procedimientos
de test, se recomienda un exhaustivo, cuidadoso y preciso planeamiento previo de los
test de usabilidad de acuerdo con los objetivos planteados.
2.10.6 Técnicas alternativas para evaluación
A continuación se comentan técnicas de evaluación de usabilidad que se
pueden utilizar como herramientas alternativas a los métodos formales que van a ser
usados en este proyecto.
Dichas técnicas tienen como principal ventaja el permitir la reducción del coste
del proceso de test debido a la infraestructura necesaria para llevarlo a cabo. Las
técnicas de evaluación son las siguientes:
Evaluación heurística.
Revisión de guías y reglas.
Seguimiento inter-disciplinar.
Inspección de consistencia.
Inspección basada en estándares.
Seguimiento cognitivo.
98
Inspecciones formales de usabilidad.
Inspección de características.
De forma general, la inspección de usabilidad se caracteriza por un conjunto de
reglas basadas en el juicio de los inspectores de usabilidad que la llevan a cabo
respecto a los aspectos relacionados con la interfaz de usuario. Estos inspectores
pueden desempeñar distintas funciones en el desarrollo del software, incluso pueden
realizar el papel de usuarios de la aplicación. Por ello, se hace vital garantizar la
fiabilidad de los resultados de la evaluación de esos inspectores sobre lo que se está
probando.
Para la aplicación de estas técnicas se requiere una experiencia dilatada en el
tiempo por parte del inspector que realiza el estudio, no son técnicas que puedan y
deban ser aplicadas por personas con poca experiencia puesto que los resultados
obtenidos podrían ser falseados emitiendo conclusiones erróneas y afectando
negativamente al resultado final de la herramienta si los cambios propuestos se
llevasen a término.
Por ello, dichas técnicas son desechadas y se ha decidido hacer uso del método
formal aplicando los test a usuarios predefinidos que este método aporta.
99
2.10.7 Ciclo de vida de la usabilidad
A continuación se muestra una descripción de cada una de las etapas que
componen el ciclo de vida de la usabilidad:
Análisis del perfil del usuario:
Se obtiene el perfil de los usuarios potenciales a través de herramientas como
los cuestionarios y las entrevistas. Una vez obtenidos los datos, se realiza su análisis
con el objetivo de describir los factores más relevantes de impacto sobre la Usabilidad
del producto como son el tipo de uso que se le va a dar, la cantidad de horas dedicadas
al uso y el nivel de experiencia previa.
Análisis de tareas:
En fase del ciclo de vida se describen las actividades realizadas actualmente por
los usuarios sus flujos de trabajo, los cuales se originan de sus esquemas mentales y las
necesidades de información para realizar su trabajo. El objetivo perseguido es llegar a
identificar:
Qué es lo que el usuario hace.
Cómo lo hace.
Qué necesita para hacerlo.
Con ello se logra el entendimiento conceptual de las tareas que deberán formar
parte del sistema en desarrollo.
Definición de los objetivos de Usabilidad:
100
Este proceso es responsable de la especificación de los objetivos cualitativos y
cuantitativos de usabilidad. Estos se relacionan con los resultados obtenidos en las
fases anteriores y con la especificación de requisi tos de satisfacción por parte del
usuario.
En este sentido, los objetivos de usabilidad serán utilizados como parámetros
clave durante la realización de los test al grupo de trabajo.
Diseño del sistema:
Este proceso consiste en un conjunto de actividades compuestas básicamente
por el análisis estructurado del sistema: se diseña su modelo conceptual considerando
la organización y el flujo de trabajo de la funcionalidad del producto.
Definición y diseño de interfaces del sistema:
Para llevar a cabo este proceso se utilizan, por una parte, los resultados del
análisis de tareas y, por otra, los objetivos predeterminados en la usabilidad.
Implementación de prototipos:
Este proceso consiste en un estudio experimental de determinados aspectos
del sistema. Su propósito es reducir el tiempo y coste de desarrollo del producto,
permitiendo la realización de los test con los usuarios elegidos para componer el grupo
de trabajo.
La implementación de prototipos es más rápida y más barata y, por tanto, se
puede llevar a cabo cuantas veces sean necesarias, generalmente haciendo uso de un
proceso en espiral.
101
El uso de prototipos permite tanto la verificación de los aspectos funcionales
del sistema como la validación de las interfaces propuestas.
Realización de test:
En esta fase del ciclo de vida se verifi ca y validan los prototipos creados. A su
vez, se hace una evaluación en paralelo de su usabilidad.
Usando el procedimiento formal de test o técnicas alternativas mencionadas
con anterioridad. Este proceso también puede ser realizado con la versión final de l
producto, no necesariamente con una versión alfa en desarrollo o una versión beta en
fase de pruebas, lo que permite aplicarlo sin ninguna restricción Al sistema GESDOC,
tratado en este proyecto.
102
Rediseño:
Más que una fase, el rediseño se caracteriza por ser un indicador de decisión
basado en los resultados de los análisis de los test. Por tanto, si se identifica que el
producto no cumple con los requisitos preestablecidos, se desvía el flujo normal del
ciclo de desarrollo a la definición de los objetivos para verificar su validez.
Implementación del producto:
Después de la evaluación de los prototipos, en el caso de haber partido de una
versión en desarrollo, se inicia la implementación del producto con su funcionalidad y
prestaciones completas.
Retroalimentación del usuario:
Como última fase del ciclo, cuando se ha realizado la instalación del producto,
se obtienen nuevas informaciones complementarias del usuario con el propósito de
usarlas para mejorar el diseño del sistema en futuras versiones o en el desarrollo de
paquetes de actualización del software.
103
2.10.8 Cuestionario de Usabilidad
El objetivo de este test es el de establecer el grado de fuerza de los criterios
empleados por la usabilidad y la tipología de usuario que realizará tanto este test
general como el test específico. Este test se compone de tres partes, separadas en
páginas.
En primer lugar se recoge información sobre el usuario que va a utilizar la
herramienta. Se le pregunta desde su nivel de estudios hasta sus conocimientos sobre
herramientas diversas de informática. También se le realizan cuestiones sobre
conocimientos generales de Internet, así como su trato con diversas tecnologías,
algunas de ellas relacionadas con la informática y otras no, lo que puede determinar el
grado de implicación de este usuario con nuevas tecnologías.
En la segunda parte del test se realiza un cuestionario completo sobre el
sistema GESDOC. Se busca una visión general de la herramienta software. Su
estructura consta de los siguientes bloques:
Estructura de la aplicación.
Operación de la aplicación.
Sistema de ayuda y mensajes.
Apariencia.
En la tercera parte del test, estrechamente relacionada con la segunda, se
busca preguntar por una visión en profundidad de la herramienta preguntando
directamente por el contenido de la aplicación y por los sistemas de evaluación (si
dispone de ellos). En la parte final se realizan preguntas enfocadas al usuario,
relacionadas con su experiencia tras el uso de la aplicación.
104
El test específico de usabilidad para la herramienta GESDOC debe crearlo un
profesional en este área que tenga experiencia previa en la realización y composición
de estos test. Por ello, este test no va a ser recogido en este proyecto. Se cree
suficiente con la información que aporta un test de usabilidad general.
2.10.9 Valoración del cuestionario
La primera parte está dedicada al análisis del perfil de usuario, donde se
recogen cuatro calificadores que van a tenerse en cuenta a la hora de realizar la
valoración:
Calificador 1: Nivel de escolaridad.
Calificador 2: Horas diarias de trabajo con ordenador.
Calificador 3: Tipos de actividades que el usuario realiza con el
ordenador.
Calificador 4: Software que el usuario ha usado en los últimos seis
meses o conoce.
Para dichos calificadores se asignan unos pesos, que denotan su importancia.
Dichos pesos se asignan basándose en la experiencia del calificador y en los objetivos
que se persiguen. Para el caso aquí tratado se han usado unos pesos genéricos
predeterminados.
105
Los pesos asignados se recogen en la siguiente tabla:
Valoración de Calificadores Calificador Peso
Calificador 1: Nivel de escolaridad 1
Calificador 2: Horas de trabajo 1
Calificador 3: Tipos de actividad 1
Calificador 4: Software conocido 2
En la siguiente tabla se recogen los valores asignados a cada nivel de usuario
definido para realizar los test:
Valoración de Usuarios Usuario Valor
Profesional 5
Avanzado [3,4]
Básico [1,2]
Dentro del usuario avanzado y del usuario profesional se pueden asignar dos
niveles, basándose en los conocimientos que estos usuarios tienen. Se podría asignar
un único valor para cada nivel de usuario pero esto aporta una mayor libertad al
evaluador a la hora de valorar los conocimientos que un usuario tiene. En el caso del
usuario profesional se ha optado por un único nivel de conocimientos, establecido en
el máximo. Este test no tiene como objeto evaluar el nivel de un profesional, por ello
se le supone el máximo.
106
A continuación se describe la ecuación que obtendrá la valoración del usuario
para la primera parte del test general de usabilidad:
ValUser = W j ⋅ Califii=1
4
∑
Para obtener la valoración del usuario se debe multiplicar el peso del ítem
calificador (Wi) establecido por su correspondiente calificador (Califi). Considerando
ahora la ecuación de cada calificador, se tiene:
Calif = factork ⋅ valoropción seleccionada
Definiendo de esta forma un factor asociativo (factork) para cada una de las
opciones que se van seleccionando.
A continuación se recoge una tabla que resume los factores asociativos
correspondientes a cada uno de los calificadores tratados:
Valoración de Calificadores Calificador Factor Asociativo
Calificador 1: Nivel de escolaridad 1/6
Calificador 2: Horas de trabajo 1/5
Calificador 3: Tipos de actividad 1/6
Calificador 4: Software conocido 1/51
Resumiendo todo lo tratado anteriormente, la ecuación que valora al usuario
quedaría de la siguiente forma:
107
ValUser =1⋅ 16 ⋅ValorEscolaridad( )+1⋅ 1
5 ⋅ValorDedicación( )+1⋅ 16 ⋅ValorUso( )+ 2 ⋅ 1
51⋅ValorSoftware( )
El valor para el calificador 1 y el calificador 2 se establece directamente,
sacando el valor del test. Pero en el caso de los calificadores 3 y 4 esto no puede
realizarse de la misma manera puesto que en estos calificadores se permite la
respuesta múltiple, algo que no sucede en los dos primeros. Por tanto valorUso y
valorSoftware deben calcularse usando otro método.
Para establecer el valor es estos dos últimos calificadores es necesario realizar
una suma ponderada de las múltiples opciones seleccionadas. En el caso de estos
calificadores es necesario hacer uso de una ecuación adicional:
Calificador 3 - Tipos de actividad:
ValorUso = pesoopcióni
∑
Calificador 4 – Software conocido:
ValorSoftware = 13 ⋅ValorSub Opción( )⋅ pesoSub Opción
1
20
∑
Aplicando todas las ecuaciones aquí recogidas se obtiene una valoración para el
usuario que realiza el test de usabilidad.
Para la evaluación de la segunda parte del test se utiliza la escala psicométrica
Likert creada para la respuesta de test. Se compone de 5 puntos de valoración
posibles:
1. En desacuerdo
108
2. Parcialmente en desacuerdo
3. Indiferente
4. Parcialmente de acuerdo
5. De acuerdo
Para valorar esta segunda parte se hace uso de la media de los valores
propuestos por la escala Likert considerando todas las preguntas realizadas en esta
segunda parte como representativas. De no considerar todas las respuestas como
representativas habría que utilizar un factor de importancia para deseche las
respuestas que no se consideren importantes.
109
A los cinco puntos de valoración establecidos por la escala de Likert, se les
asigna un valor de la siguiente forma:
Valoración Escala Valor
En Desacuerdo 1
Parcialmente en Desacuerdo 2
Indiferente 3
Parcialmente de Acuerdo 4
Totalmente de Acuerdo 5
Se realizará un sumatorio para cada una de las 4 subpartes en que se encuentra
dividida la segunda parte del test y finalmente se realiza un sumatorio total de la parte
segunda.
Para la evaluación de la tercera parte del test se utiliza de nuevo la escala
Likert. Esta parte se encuentra muy relacionada con la parte anterior y por ello se hace
uso de la misma escala y una calificación final idéntica.
Una vez finalizada la valoración de los test de usabilidad es necesario tratar los
valores obtenidos y hacer un análisis de los resultados para alcanzar una visión de esta
ciencia de la herramienta GESDOC y poder realizar las recomendaciones oportunas en
caso de ser necesarias.
110
2.10.10 Realización y Evaluación de los Test
Una vez realizados los test al grupo seleccionado de trabajo se pasa a realizar la
evaluación de dichos test que permitan obtener una visión global sobre la usabilidad
de la herramienta software desarrollada y su aceptación por parte de los usuarios.
A continuación se muestran la evaluación de los test para dos usuarios.
Evaluación de los Test: Usuario 1 Tipología Profesional Edad 24 Sexo Varón Parte I – Perfil de Usuario Escolaridad 0,83 Horas de Dedicación 0,6 Uso del Computador 1 Software Utilizado 0,5176 Valoración Parte I 2,9476 Parte II – Características Estructura de la Aplicación 30 Operación de la Aplicación 22 Sistema de Ayuda y Mensajes 22 Apariencia 37 Valoración Parte II 111 Parte III – Contenido de la AME Contenido 40 Evaluación y Aprendizaje de Usuario 4 Experiencia del Usuario 14 Valoración Parte III 58 Valoración Total 171,948 76,89%
El resultado obtenido para el usuario 1 en los test de usabilidad indica que le
reporta una satisfacción de aproximadamente el 77%, es decir, que percibe la
aplicación software como útil, intuitiva y fácil de usar. Puede considerarse como una
puntuación alta para la aplicación.
111
Evaluación de los Test: Usuario 2 Tipología Básico Edad 44 Sexo Mujer Parte I – Perfil de Usuario Escolaridad 0,83 Horas de Dedicación 0,6 Uso del Computador 0,5 Software Utilizado 0,5176 Valoración Parte I 2,4476 Parte II – Características Estructura de la Aplicación 30 Operación de la Aplicación 23 Sistema de Ayuda y Mensajes 21 Apariencia 35 Valoración Parte II 109 Parte III – Contenido Contenido 37 Evaluación y Aprendizaje de Usuario 3 Experiencia del Usuario 14 Valoración Parte III 54 Valoración Total 165,448 73,99%
El resultado obtenido para los test realizados por el usuario 2 indica un
resultado similar al reportado por el anterior usuario. En este caso la utilidad es
ligeramente inferior, pero se sigue obteniendo un 74% sobre la máxima puntuación
posible, la total utilidad. Destacar que se trata de un usuario de tipología básico, con
menos conocimientos que otros tipos de usuarios, por tanto su punto de vista para el
análisis de la herramienta será tomado en cuenta en menor medida, pues el objetivo
de este proyecto es el análisis de la aplicación para su uso profesional.
112
2.11 MANTENIMIENTO
Se continuará con el mismo procedimiento para la consecución del buen
mantenimiento de la aplicación.
El mantenimiento de esta aplicación informática se realiza por medio de
comunicaciones bien vía telefónica o bien vía correo electrónico, aunque no se
descarta el mantenimiento por medio de reuniones en caso de que existan dificultades
en la comunicación. Este último procedimiento aumenta los costes del proyecto, pero
el proceso de implantación está diseñado de forma que no sea preciso reunirse con
todos las delegaciones, o al menos no para el mantenimiento.
Por lo tanto, se les ofrece directamente la aplicación informática, un correo
electrónico de ayuda y, en caso de que no se pueda realizar comunicación alguna, se le
ofrecerá un teléfono de contacto al director de proyecto.
El mantenimiento tiene que realizarse de forma que se pueda ofrecer ayuda
tanto técnica como informática, puesto que son los dos conocimientos que se
requieren para resolver los problemas que puedan surgir. Por este tema, es
imprescindible realizar un manual de usuario tan completo y aclarativo que el proceso
de mantenimiento sirva de referencia en caso de que surja algún problema.
El seguimiento del mantenimiento también es una pieza clave para realizar
correctamente el estudio, puesto que influye de forma decisiva el número de quejas o
problemas que se encuentren los usuarios a la hora de utilizar la aplicación
informática.
113
CAPÍTULO 3: PLANIFICACIÓN
114
A continuación se pasa a describir la secuencia temporal de las diferentes
tareas de las que se ha compuesto el proyecto:
115
CAPÍTULO 4: VALORACIÓN ECONÓMICA
116
Realizar un proyecto con un buen estudio de viabilidad económica es
fundamental para que éste sea implantado. En este caso, los beneficios que se pueden
obtener de implantar este proyecto en la vida real son beneficios sociales, es decir
intangibles, puesto que no supone ningún ingreso económico. Por el contrario, el
beneficio fundamental de este proyecto es el del valor de la información, puesto que
se pueden realizar múltiples estudios e informes de situación de la organización, que
proporcionen un análisis completo a la organización.
Es indispensable, por tanto, realizar un estudio del coste económico real que
supone implantar éste proyecto. Los recursos adicionales hardware que se necesitan,
son básicamente nulos, puesto que con respecto a los ordenadores cliente, bastaría
con usar los que ya dispone la organización, y en cuanto al equipo servidor sí que se
requeriría un buen equipo capaz de gestionar todas las peticiones que reciba la
aplicación. Por suerte también se dispone de un servidor muy potente en la actualidad
que puede dar servicio a GESDOC, así como a GESCO y GESPRO, por tanto esto
tampoco supondría un gasto adicional. Si se requeriría un disco duro de gran capacidad
para albergar todos los documentos que se van a asociar a los artículos y noticias que
se registren.
En cuanto a los recursos software, es necesario disponer de licencias de
Windows para los ordenadores cliente, ya disponibles, y licencias de Windows 2000
Server y SQL Server para el equipo Servidor, también disponibles, por lo que parte
fundamental del presupuesto se destina al equipo trabajo dedicado al desarrollo,
implantación y mantenimiento de la aplicación.
Por tanto y con la intención de hacer un presupuesto estimado si estas
circunstancias no se hubieran dado y no se tratase de una ONG con equipos y software
117
donado y con programadores realizando su proyecto de fin de carrera, el resultado
sería este:
Recursos Humanos Perfil Horas €/Hora Total
Análisis Nueva Base de Datos Analista 30 50 1.500 €
Análisis Nuevas Funcionalidades Analista 40 50 2.000 €
Desarrollo Nueva Base de Datos Programador 80 30 2.400 €
Desarrollo Nuevas Funcionalidades Programador 160 30 4.800 €
Subtotal 350 10.700 €
Recursos Hardware Precio
(*)Servidor P-IV DUAL CORE, 4 GB RAM, 2 TeraBytes HDD, Router, Switch. 1.500 €
Subtotal 1.500 €
Recursos Software Precio
Ms Windows 2000 Server 150 €
Ms SQL Server 2005 Standard Edition 6.000 €
Ms Visual Studio.NET v2005 800 €
Subtotal 6.950 €
PRESUPUESTO TOTAL 14.300 €
(*) Se ha estimado el precio de un servidor, ya que no se puede estimar el
número de ordenadores cliente que se van a utilizar.
118
CAPÍTULO 5: CONCLUSIONES
119
Las principales conclusiones que he obtenido de este proyecto son:
Importancia de una buena documentación: tras haber tenido que tratar con
desarrollos pasados, programados íntegramente por mí, me he percatado de la
importancia de tratar con código bien documentado y bien modularizado. Siendo
crítico con mi trabajo pasado, quizá no dediqué el tiempo necesario de incluir
comentarios explicativos que pudieran haber ayudado al siguiente programador
que se encontrase con mi código. En ocasiones he tenido que dedicar largas horas
a “descifrar” lo que yo mismo codifiqué años atrás. Hubiera sido de gran ayuda una
buena documentación técnica de mi anterior proyecto así como de unos buenos
comentarios explicativos dentro del código.
Ventajas de un buen diseño: del mismo modo que critico mi anterior falta de
documentación, he de alabar el tiempo invertido en realizar un buen diseño de la
base de datos anterior. Al anterior diseño de la base de datos hubo que prestarle
especial interés y dedicación pues éste iba a estar interactuando con otras bases de
datos del entorno de gestión de la Fundación. Por este mismo motivo, al volver a
tratar con la anterior base de datos, el esfuerzo requerido para modificar y adaptar
la base de datos antigua a la nueva versión ha sido mucho inferior a lo estimado a
priori.
Ventajas de la modularidad: Al trabajar en diferentes módulos ha sido posible
desarrollar diferentes funcionalidades en paralelo y que estas se comuniquen entre
sí sin tener código fuente en común. Este método de trabajo es imprescindible en
el desarrollo de grandes aplicaciones y prepara además las aplicaciones para
futuras ampliaciones.
120
Ventajas de Trabajar para una ONG: Tras haberme incorporado a un mundo
laboral como es el de la consultoría informática, ha sido para mí muy gratificante
volver a un mundo laboral como es el de una ONG. Ese mundo agresivo y
competitivo de las consultoras informáticas desaparece en cuanto entras por las
puertas de Entreculturas. Si bien hay que dedicar las mismas o más horas al trabajo
se puede percibir un ambiente mucho más calmado y sosegado de trabajo. Por
desgracia el mundo de la cooperación y el voluntariado no cumple con las
expectativas salariales de la mayoría de las personas, pero de no ser por esto, esta
opción laboral es mucho más gratificante que la que nos se pueden encontrar en
una gran consultora.
Necesidad de mantenimiento: nunca se ha de dar por finalizado un desarrollo, tras
la finalización de la versión 1 de Gesdoc parecía que se daba por zanjado el
desarrollo y nada más lejos de la realidad, tres años después he observado la
infinidad de modificaciones, errores, incidencias y nuevas funcionalidades que se
han detectado. En esta ocasión la sensación es la misma, es decir, puede uno
pensar que la versión 2 es la definitiva excepto por algún posible error no
contemplado, pero la experiencia me dice que volverán a recurrir a mí para futuras
versiones.
Diferentes puntos de vista entre el diseñador y el usuario: Una de las conclusiones
más importantes que he sacado de este proyecto es que el usuario final y el
diseñador o desarrollador de la aplicación ven las cosas de manera distinta, esto ha
sido posible gracias a que el proyecto está en fase de explotación en un entorno
real. Las primeras especificaciones que aporta el usuario no son probablemente las
definitivas, bien porque ha expresado mal sus deseos, bien porque los has
entendido mal o bien porque ha cambiado de idea tras probarlo, esto hace que
haya que hacer diferentes pruebas del funcionamiento de la aplicación hasta que el
usuario está completamente (o suficientemente) satisfecho con el funcionamiento
de la misma.
121
Alto coste de las aplicaciones propietarias: Uno de los objetivos del proyecto era
conseguir independizar a GESDOC de las aplicaciones propietarias, pues las
licencias son caras y en muchas ocasiones no se explotan estas aplicaciones
adecuadamente pues solo se utiliza la funcionalidad de la aplicación parcialmente,
además esta funcionalidad es general y no está adaptada a las necesidades
concretas de la aplicación. Mientras que por un lado se ha conseguido evitar el uso
de aplicaciones propietarias, PORTFOLIO en el caso del servidor de imágenes, por
otro lado el desarrollo de GESDOC se ha realizado en un entorno Microsoft, lo cual
ha hecho subir el presupuesto del proyecto, probablemente en el futuro los
administradores de GESDOC deberían plantearse la migración a un entorno de
software libre. Esto sería costoso y complicado en el momento de la migración,
pero a la larga se abaratarían los costes.
122
CAPÍTULO 6: BIBLIOGRAFÍA Y RECURSOS WEB
123
6.1 BIBLIOGRAFÍA
[BARR94] Barranco de Areba, Jesús, “Metodología del análisis estructurado
de sistemas”; Universidad Pontificia Comillas, Madrid 1994.
[POWE02] Powell, Thomas A. Javascript. Manual de Referencia, 1ª Edición
McGraw-Hill, Febrero 2002.
[BOBA99] Bobadilla, Jesús. HTML dinámico, ASPX y JavaScript a través de
ejemplos, 1ª Edición, RAMA, 1999
[ACCE02] Informe funcionamiento Entreculturas., Accenture, 2006.
[MONI99] Moniz, Joseph. ENTERPRISE APPLICATION ARCHITECTURE WITH
VB, ASP & MTS, 1ª Edición 1999
[PERE04] Pérez, César, “Administración y Análisis de Bases de Datos”;
RA-MA, 2004.
[ALON05] I.Alonso, E.Rivero, L.Martínez, “Bases de Datos relacionales:
fundamentos y diseño lógico”. Universidad Pontificia de Comillas, Madrid 2005.
124
6.2 RECURSOS WEB
http://www.elguille.info/
http://www.unav.es/cti/manuales/TutorialJavaScript/
http://www.asptutor.com
http://msdn1.microsoft.com/
http://www.aspfacil.com/
http://www.w3schools.com
http://html.conclase.net/
125
ANEXO A: MANUAL DE USUARIO
126
Con el fin de disponer de un manual de usuario completo y definitivo sobre el
aplicativo Gesdoc, se procede a explicar en profundidad el funcionamiento de la
aplicación definitiva y no únicamente las mejoras realizadas desde la última versión.
A.1 ADMINISTRACIÓN DE DATOS GEOGRÁFICOS
La administración de datos geográficos gestiona uno de los principales criterios
de búsqueda de nuestro gestor documental. En ocasiones bastará con incluir en la
búsqueda el continente o país del cual se desee información si se desea una búsqueda
de información a gran escala. Este apartado incluye tanto la gestión de continentes
como la de países y a su vez la gestión de provincias. Por razones obvias hay que tratar
estos datos con cuidado dada su estrecha relación. Obviamente para dar de alta una
provincia se tiene que haber dado de alta previamente el país que contiene dicha
provincia, y a su vez para dicho país tiene que estar dado de alta en un continente. Por
este motivo hay que tener especial cuidado en las relaciones que entre estos tipos de
datos se genera puesto que el sistema es incapaz de rechazar una relación errónea
creada por el usuario, y por tanto de equivocarse éste dando de alta los datos el
sistema lo almacenará como información correcta.
A.1.1 Gestión de Continentes:
Figura A.1
127
En esta ventana se cargará una lista desplegable con los continentes que
previamente hayan sido introducidos, en caso de no haber sido dado de alta ningún
continente se mostrará únicamente la opción de nueva pues no se podrá borrar ni
modificar selección alguna.
En caso de haber datos dados de alta previamente aparecerá en la lista
desplegable preseleccionada la opción en blanco, y aparecerán los botones nueva,
modificar y borrar visibles y habilitados. Si se intenta modificar estando seleccionada la
opción en blanco la aplicación interrumpirá con el siguiente cuadro de error:
Si se intenta, por otro lado borrar en idénticas condiciones el mensaje de error
será el siguiente:
Por tanto la única opción viable en este caso es la de dar de alta un continente
mediante el botón nueva. Si se pulsa dicho botón se muestra un cuadro de texto en el
cual se ha de escribir el nombre del nuevo continente y se deshabilita la lista
desplegable continentes para no permitir así seleccionar nada, a su vez se mostrarán
128
los botones de aceptar y cancelar para grabar o volver atrás. Tras darle al botón
aceptar se mostrará por pantalla el siguiente cuadro de confirmación:
Automáticamente, en el momento en que se acepta, el nuevo continente se
inserta en la base de datos y en la lista desplegable, y la aplicación vuelve
directamente a la ventana inicial de Administración de datos geográficos para que se
siga trabajando.
Desde el momento en que se da de alta el primer continente se podría
modificar dicha inserción pulsando el botón modificar.
Cuando se pulsa el botón modificar se muestra por pantalla un cuadro de texto
con el nombre del continente a modificar para su posterior modificación, en todo
momento se podrá cambiar la selección de la lista desplegable y automáticamente se
mostrará la selección en el cuadro de texto. Después de hacer las modificaciones
pertinentes se podrá pulsar el botón aceptar o el cancelar. En caso de aceptar se
mostrará el siguiente cuadro de confirmación:
129
Tras pulsar el botón aceptar la aplicación nos llevaría nuevamente a la ventana
principal de administración de datos geográficos, gestión de continentes. También una
vez dado de alta el primer elemento se podría borrar dicho elemento pulsando el
botón borrar. En tal caso, aparecería nuevamente un cuadro de confirmación:
De igual manera después de aceptar o cancelar, la aplicación nos redirecciona a
la página principal de gestión de continentes, pero si se ha aceptado, lo que implica
que se ha borrado un continente (sin países dependientes), dicho continente no
aparecerá en la lista desplegable.
Si por algún motivo se intenta borrar un continente conteniendo éste países
asociados, la aplicación no nos lo permitirá, ya que antes se deberían eliminar uno por
uno los países que dependen de dicho continente para poder eliminarlo. Nos
informará por medio del siguiente mensaje de error:
130
A.1.2 Gestión de Países
En esta ventana se mostrará únicamente en principio una lista desplegable
continentes, y no se mostrará si quiera un botón, dado que para poder acceder a
gestionar los países se ha de seleccionar primero el continente que contiene o va a
contener el país a gestionar. Una vez que se ha seleccionado un continente se llenará
automáticamente la lista desplegable países, conteniendo únicamente los países
pertenecientes al continente seleccionado y a su vez se mostrarán los botones de
nueva, modificar y borrar, dado que ya se podrán gestionar los países de la lista
desplegable países.
A.1.2.1 Altas
Mediante el botón alta, y después de haber seleccionado un continente, se
procede a dar de alta un nuevo país. Para ello se habilitarán dos cuadros de texto, uno
de ellos para el nombre del país, y otro para el id del país, que en este caso será
decisión del usuario, en vez de ser generado automáticamente por la aplicación, y es
de esta manera, ya que es un id compuesto por tres letras. En principio se podría haber
optado por rellenarlo automáticamente con las tres primeras letras del nombre del
país, pero se desecho esta idea, dado que se podrían dar duplicados de id, perdiendo
la integridad referencial.
131
Como se puede observar en la figura anterior, si el sistema se encargase de
asignar un id de país en base a las tres primeras letras del país se daría el caso de que
Eslovenia y Eslovaquia tendrían el mismo id_Pais rompiendo de esta manera la
integridad referencial.
También se deshabilitará la lista desplegable continente, para evitar que se
puedan cambiar de continente y que se asocie un país a un continente que no lo
contiene.
Si se diese la circunstancia de que el usuario introdujera un nombre de país o
un id de país repetido dentro de ese mismo continente, la aplicación no nos permitiría
continuar, y después del mensaje de confirmación nos aparecería este mensaje de
error:
Figura A.2
132
Y la aplicación nos llevaría a la página inicial de gestión de países dejando ya
seleccionados el continente y país previamente seleccionado.
A.1.2.2 Modificaciones
Exactamente este mismo comportamiento se daría si se pulsase el botón
modificar. Es decir, si se pulsa el botón modificar después de haber seleccionado un
continente y un país, se mostrarían el cuadro de texto nombre del país, e id del país,
estando esta vez previamente rellenados con el nombre e id del país seleccionado. Si
Figura A.3
133
una vez modificado el nombre o id de dicho país, se pulsa el botón aceptar, se
mostraría el cuadro de confirmación de la figura, pero si por un casual el nombre o
id_pais después de haberlo modificado, coincide con el nombre o el id de otro país del
mismo continente se mostraría el siguiente mensaje de error:
El cual, y tras haber pulsado Aceptar nos dirigiría una vez más a la pagina inicial
de gestión de países con el continente y país anteriores ya seleccionados.
A.1.2.3 Bajas
No habría nada que añadir, ya que es idéntico al comportamiento de baja de un
continente.
A.1.3 Gestión de Provincias
Cuando se accede a la ventana de gestión de provincias desde el menú de
Administración de datos geográficos, únicamente se podrá ver la lista desplegable
continentes, sin botón alguno que pulsar, ya que para poder gestionar una provincia es
imprescindible ubicarla primero en un continente y después en un país. Tras
seleccionar un continente, se mostrará la lista desplegable países ya rellenada con los
países del continente seleccionado. Al seleccionar también un país, aparecerá a su vez
la lista desplegable con las provincias que contenga dicho país, si es que tiene, (se ha
134
de recordar que en caso de no tener provincias no se mostrará etiqueta alguna,
simplemente permanecerá la lista vacía). También estarán disponibles para su uso los
botones nueva, modificar y borrar.
Para dar de alta una nueva provincia, se ha de pulsar en el menú principal la
opción de Administración de datos Geográficos, y dentro de ella se ha de seleccionar la
opción de gestión de provincias. Una vez situado en el menú principal de gestión de
provincias, en él únicamente se encuentra habilitada la lista desplegable continentes,
esto obliga a que para poder empezar a gestionar (en este caso, dar de alta) una
provincia se haya de encuadrar dicha provincia en un continente y su correspondiente
país. Si por un casual, la provincia que se desea dar de alta está ubicada en un
continente o país que no aparezca en las correspondientes listas desplegables,
entonces habrá que dirigirse a gestión de continentes o de país para darlos de alta y
posteriormente volver al menú de gestión de provincias.
Es requisito indispensable para poder dar de alta una provincia que el
continente y el país que la contengan hayan sido previamente dados de alta.
Tras haber escogido continente, se mostrara la lista desplegable países, aun no
se habilitará ningún botón. Es después de haber seleccionado continente y país que se
mostrará la lista desplegable provincias y a su vez los comandos de nueva, modificar y
borrar.
135
Es una vez aquí y no antes cuando se podrá dar de alta una provincia. Se pulsa
el botón nueva y se mostrará dicha ventana:
Figura A.5
Figura A.4
136
Como se puede observar aparecen dos cuadros de texto, dedicados al nombre
de la provincia y al Id de dicha provincia, el cual estará compuesto por tres letras que
identifiquen unívocamente dicha provincia. Este proceso se ha dejado en manos del
usuario en lugar de hacerlo digitalmente, ya que en ocasiones se pueden dar
duplicados en ids, lo cual rompería la integridad de la base de datos. Véase por
ejemplo como en las antiguas matriculas de los coches españoles, estas comenzaban
por una o dos letras, en función de la ciudad, y se estipuló que los coches matriculados
en la provincia de Albacete se marcasen con las letras AB, dado que AL, que son las dos
primeras ya estaban dedicadas a los coches matriculados en Almería. En este caso el
criterio a utilizar se determinaba en función del número de habitantes (o bien de
coches a matricular) de una provincia. Como no se puede saber a priori que criterio
desea utilizar el usuario para identificar las provincias, se ha decidido no otorgarle al
sistema informático la labor de identificar las provincias, esta decisión también se
adoptó para identificar los países (que se identifican de igual manera, con tres
caracteres).
Una vez rellenados ambos campos de texto, se procede a aceptar la operación.
En este mismo instante, dicha provincia con su correspondiente id pasarán a la base de
datos, asociándolo por medio de su id al país al que pertenece, del mismo modo dicho
país está relacionado internamente con el continente al que pertenece por su
correspondiente id de país.
Tanto si se acepta como si se cancela, sendos mensajes de confirmación serán
mostrados por pantalla y la aplicación nos conduciría a la ventana anterior. En caso de
haber aceptado y haber introducido por error el nombre o el id de alguna provincia
previamente registrada, la aplicación no nos lo permitirá y nos devolverá el siguiente
mensaje de error:
137
Si lo que se desea es modificar una provincia se sigue el mismo procedimiento
para encuadrar geográficamente la provincia en cuestión, y solo si ha sido previamente
registrada dicha provincia, se selecciona en la lista desplegable provincias la deseada y
se pulsa el botón modificar, en este caso a diferencia de cuando se da un alta, los
cuadros de texto estarán inicializados con los datos de la provincia previamente
seleccionada. Tras modificar los datos pertinentes se pulsaría el botón aceptar y tras
aceptar de nuevo el cuadro de confirmación se quedaría modificado en la base de
datos, a menos que se diese el caso de que o el nombre de la provincia recién
modificada o su id coincida ahora con algún otro nombre o identificador que estuviese
previamente registrado, en cuyo caso la aplicación nos informaría del problema y no
realizaría la actualización del registro.
Figura A.6
138
Para borrar una provincia se habría de seleccionar el botón borrar una vez
seleccionada la provincia que se desea eliminar, y en este caso, aparentemente no
debería dar conflictos en el borrado ya que en principio nada depende de una
provincia, pero ya se verá más adelante en el apartado de gestión de categorías que
efectivamente las provincias pueden tener a su vez poblaciones asociadas. No se ha
considerado oportuno incluir un submenú para la gestión de poblaciones ya que estas
solo estarán asociadas a las provincias pero será únicamente en la gestión de
categorías donde se podrá hacer uso de ellas. En tal caso se mostraría por pantalla
mediante un mensaje de error.
En caso de borrarse sin conflictos, la aplicación volvería al menú principal de
gestión de provincias con el país y continente de la entrada recién borrada
seleccionados.
139
A.2 GESTIÓN DE CATEGORÍAS
Introducción:
Para facilitar la búsqueda de artículos en nuestra “hemeroteca” se ha de ir
acotando los filtros de búsqueda. Con vistas a posteriormente afinar la búsqueda se
crean las categorías. Una categoría es por así decirlo una manera de taxonomizar la
información. Es decir, antes de llegar a la búsqueda de artículos en la sección de
gestión de titulares/noticias o gestión de anuncios, se deberían de haber creado
previamente la categoría o categorías asociadas a dicho artículo. Hay un término de
reciente creación que ha tenido mucho éxito en internet, el término tag o etiqueta.
Bien, pues una categoría a efectos haría las funciones de una etiqueta o tag.
Una categoría consta de varias características:
Id de Categoría: es el identificador de cada categoría, consta de un número de
hasta 4 dígitos que la aplicación genera secuencialmente, partiendo desde la
categoría 0001 y añadiendo una unidad en función de las nuevas categorías que se
van generando.
Nombre de Categoría: nombre descriptor de cada categoría, campo alfanumérico
de hasta 50 caracteres.
Tipo de Categoría: descriptor que engloba a todas las categorías de la misma clase.
Estos datos deben haber sido previamente registrados en el menú Administración
Datos Categorías, submenú Gestión de Tipo de Categoría.
Subtipo de Categoría: nuevo campo creado para definir y clasificar aún más la
categoría. Dicho dato ha de haber sido dado de alta con anterioridad en el menú
Administración Datos Categorías, submenú Gestión de Tipo de Subcategoría.
140
Descripción: campo bastante extenso, de 350 caracteres, con espacio como para
dar una breve explicación o descripción de la categoría.
Modelo De Una Categoría:
Para poder explicar mejor en qué consiste una categoría, se hará uso de un
ejemplo. En Gesdoc V.1.0 se tomó como referencia a Hugo Chaves, en aquella versión
hubo que matizar que una categoría no tenía por qué ser una persona, que podía
tratarse también de una institución (Cáritas), empresa (Accenture), grupo político
(PNV) o grupo terrorista (ETA). Bien, en Gesdoc 2.0 este problema desaparece, pues al
añadir un nuevo campo en la gestión de categorías, el campo subtipo de categoría,
ahora cambiaría la manera de registrarlo.
El Id de Categoría, como se ha explicado previamente lo genera la propia
aplicación, así que pongamse que es el id 0012, esto no cambia.
El Nombre de la Categoría seguiría siendo obviamente Hugo Chaves.
En Tipo de Categoría, donde antes se hubiera escogido la más
relacionada, entonces era Presidente, ahora quedaría mejor clasificado
si se clasifica como tipo de categoría Personaje y subtipo de categoría
Político, o Jefe de Estado.
En Descripción de la Categoría se podría por ejemplo dar una breve
explicación de quien se trata, en este caso podría ser: Máximo
mandatario Venezolano. Sería interesante dar una descripción por
pequeña que fuese ya que, si se habla de “Hugo Chaves” o “George
Bush”, cualquiera conoce su existencia, pero si se hablase por ejemplo
de Anesbad convendría dar una descripción, como por ejemplo:
“Organización no Gubernamental dedicada a erradicar la lepra en los
141
países en los que aun se padece” podría sacar de dudas a muchos
usuarios.
En el menú de Administración Datos Categorías se pueden encontrar cuatro
opciones:
A.2.1 Gestión de Categoría
Tras pulsar en el menú Categorías, opción Alta Categoría, aparece la ventana
con el mismo nombre, y en ella se tendrán que rellenar todos los datos de la nueva
categoría. El cuadro de texto id de categoría se encuentra deshabilitado, ya que, como
se ha dicho este dato lo genera el sistema. Se escribiría el nombre de Categoría, se
seleccionaría en la lista desplegable tipo de categoría, aquel que más se aproxime
según nuestro criterio, a nuestra categoría. Si se da el caso de no encontrar ninguno
que se ajuste a nuestra categoría, bastaría con dar nosotros mismos una en el menú
Administración de categorías, submenú Tipo de Categoría. (Previamente explicada). De
igual modo, si se desea afinar más la clasificación de la categoría se podría seleccionar
Figura A.7
142
además un subtipo de categoría que previamente debería haber sido dada de alta en
el menú Categorías, opción Alta Subtipo de Categoría. En cualquier caso la decisión de
seleccionar un subtipo de categoría queda a la elección del usuario, pues para
Tras esto, se daría una breve explicación de nuestra nueva categoría, dato que
en el futuro puede ayudar a futuros usuarios a hacerse una idea de quién o qué se
habla.
Tras haber rellenado todos los campos, o por lo menos los obligatorios, que son
aquellos con el fondo sombreado en amarillo, se pulsa el botón grabar, acto seguido el
programa nos informa con el siguiente mensaje de confirmación:
Si hay alguna de los dos campos obligatorios, Nombre y Tipo de Categoría, sin
rellenar, la aplicación no nos permitiría continuar, y nos advertiría con el siguiente
mensaje de error:
Y si no se ha seleccionado el Tipo de Categoría, el sistema nos advertirá de la
siguiente manera:
143
Si se ha rellenado todo correctamente y no hay ningún error, ni duplicado, el
sistema nos dirigiría a la ventana de búsqueda de categorías, la cual se explicará más
adelante, y aparecería seleccionada la categoría recién registrada.
A.2.2 Gestión de Tipo de Categoría
Para gestionar tipos de categoría se debe acceder al formulario de
Gestión de Tipo de Categorías a través del menú administración datos categorías. Una
vez en el formulario se observa que ya hay una lista desplegable cargada con todos los
valores ya dados de alta, los cuales si se desean modificar o borrar solo se tendría que
seleccionar uno en concreto en dicha lista desplegable y pulsar sobre el botón que se
desee.
A.2.3 Gestión de Subtipo de Categoría
Según se accede a este formulario se ve únicamente una lista desplegable de
tipos de categoría, pues todo subtipo de categoría está asociado a un tipo de
Figura A.8
144
categoría, no se concibe un subtipo de categoría sin un tipo de categoría padre.
Cuando se ha seleccionado ya un tipo de categoría automáticamente se cargará una
lista desplegable de subtipos de categoría ya dados de alta.
Una vez cargada dicha lista desplegable se podrá bien borrar dicho subtipo de
categoría, modificar o crear un nuevo subtipo de categoría. La mecánica es sencilla e
idéntica a la gestión de datos geográficos vista anteriormente, con una salvedad, en
subtipo de categoría, al dar de alta uno nuevo, no se le requiere al usuario indicar el id
de subtipo de categoría, pues lo genera el sistema automáticamente.
A.2.4 Búsqueda de Categorías:
Este es el corazón de la gestión de las categorías. Una vez se han dado de alta
por separado los distintos tipos de categorías, subtipo de categorías y categorías (en
ese orden), desde este formulario se puede tanto buscar cómo gestionar las distintas
categorías dadas de alta. Primeramente se buscarían las categorías en función de sus
Figura A.9
145
criterios tipo y subtipo de categorías y posteriormente una vez seleccionada la
categoría deseada se procedería a modificar, consultar o borrar dichas categorías.
Resaltar que desde este formulario también se podría dar de alta una nueva
categoría. Para acceder a este formulario se habría de acceder a través del menú
Administración Datos Categorías, submenú Búsqueda de Categorías.
El procedimiento para realizar una búsqueda de categorías es el siguiente:
primeramente se seleccionaría un tipo de categoría, en este momento si se pulsase el
botón buscar ya habría información suficiente para generar resultados, pero si se
desea afinar más la búsqueda, entonces se recurre a los subtipos de categoría.
Figura A.10
146
Al seleccionar un tipo de categoría de la lista desplegable automáticamente se
llena una lista de selección múltiple llamada Subtipo de Categoría. De dicha lista se
pueden seleccionar tantos valores como se desee. Una opción sería seleccionar uno
por uno los valores deseados y pulsar el botón añadir con cada uno de los valores
seleccionados y en caso de querer seleccionarlos todos también existe la posibilidad de
pulsar sobre el valor Todos el cual arrastraría todos los valores a la parte de valores
seleccionados.
Si por un casual se ha equivocado añadiendo un valor a la parte derecha del
formulario, siempre se podrá rectificar pulsando el botón Quitar o incluso el botón
Quitar Todos en caso de desear limpiar la lista de valores seleccionados.
La utilidad de añadir al formulario una lista de selección múltiple es la de poder
realizar búsquedas múltiples como se muestra en la figura a continuación:
Figura A.11
Figura A.12
147
Al pulsar el botón buscar los resultados estarán relacionados con estos tres
subtipos de categorías. Lo cual optimiza mucho la búsqueda en comparación con la
versión 1.0 de Gesdoc.
En la anterior figura se puede observar como los resultados de la
búsqueda han quedado filtrados por los tres criterios (subtipos de categoría)
seleccionados. Una vez que se selecciona la categoría que se estaba buscando, si es
que se ha encontrado se procedería a tratarla como se desee. Desde esta ventana se
podrá Borrar dicha categoría, Consultarla o bien Modificarla. Si se desea también
desde este formulario se puede dar de alta una nueva categoría. Este botón Nueva nos
llevaría al mismo formulario que si se accede al menú Administración Datos Categorías
submenú Gestión Tipo de Categoría.
A.2.4.1 Modificación/Consulta/Borrado de Categoría:
Si tras seleccionar un elemento en la rejilla que nos aparece tras darle al botón
buscar en la ventana de búsqueda de categorías, se pulsa sobre el botón modificar, se
accederá a la página de modificación de categoría.
Figura A.13
148
Una vez aquí se observa que los campos de la categoría están habilitados y que
se nos permite la modificación en ellos excepto en el campo Id de Categoría, por un
motivo, si se modificase este campo se perdería la referencia de la categoría y podría
dar lugar a conflicto de datos. Por lo demás se puede modificar absolutamente todo.
Como se puede comprobar en la figura, una de las opciones que se podría utilizar es la
de introducir campos que no han sido creados en el campo descripción, el cual tiene
una gran capacidad, y podría albergar datos de todo tipo.
Desde esta ventana se da la opción de cancelar la modificación, si el usuario ha
decidido no modificar nada, o de aceptar en caso contrario. Si se acepta, aparecerá el
siguiente mensaje de confirmación
Figura A.14
149
Tras el cual el usuario decide si está seguro de lo que va a realizar.
Tras aceptar, en caso de que se acepte la aplicación nos redirigirá a la ventana
de búsqueda da categorías con la búsqueda ya realizada y con el elemento recién
modificado seleccionado.
Si en la ventana de búsqueda de categorías, tras seleccionar una categoría de la
rejilla de resultados de la búsqueda se pulsa el botón borrar, aparecerá la siguiente
pantalla, para informar al usuario de la categoría que se va a borrar. En este caso
tampoco se permitirá al usuario modificar los datos, dado que si se borra una categoría
se borra con todos sus campos incluido el id.
150
Lo único que esta ventana nos permitirá hacer seria cancelar la operación
mediante el botón cancelar y borrar la categoría, pero no sin antes pasar por la
confirmación correspondiente.
Tras cuya confirmación, el sistema nos redirigiría a la ventana de búsqueda de
categorías pero sin ninguna búsqueda realizada, dado que al haber borrado el articulo
ya no se conocen los criterios de búsqueda que se utilizaron para encontrar este
último.
Figura A.15
151
A.3 ADMINISTRACIÓN BBDD
En esta nueva versión de Gesdoc, la versión 2.0, han sido creados nuevos
campos de clasificación y búsqueda, los cuales también requieren sus propios
formularios de gestión y administración. Tras la realización del estudio de usabilidad al
que se sometió a los usuarios finales de Entreculturas se optó por esta nueva
organización en la que todos estos criterios se agrupasen en un nuevo menú creado a
tal efecto. Este menú incluye los siguientes formularios:
A.3.1 Gestión Ediciones
Criterio que alberga los posibles tipos de edición existentes o bien los
necesarios para la gestión de las noticias o titulares que requiera Entreculturas.
Ejemplos de ediciones podrían ser: matinal, vespertina, dominical, semanal, diaria,
mensual,etc..
Las opciones que ofrece este formulario son las ya conocidas alta, baja y
modificación de edición. Siempre que se pulse el botón Nueva , aparecerá un nuevo
campo en blanco y la lista desplegable pasará a estar sombreada pues no se podrá
modificar mientras se esté dando de alta un nuevo elemento.
Figura A.16
152
Al pulsar el botón Modificar se debería haber seleccionado antes un elemento
en la lista desplegable, si se pulsase sobre ese botón sin haber seleccionado
previamente un elemento de la lista, nos saldría el siguiente error:
De igual modo, para borrar un elemento, se ha de seleccionar previamente un
elemento de la lista y pulsar el botón borrar.
A.3.2 Gestión Secciones
La sección de un anuncio o titular, corresponde a la sección dentro de la
publicación en la que aparece, es decir, en cuál de las diferentes partes de una
publicación aparece el contenido que se está dando de alta. Ejemplos de Secciones
podrían ser: internacional, finanzas, portada, deportes, opinión etc.
153
Se ofrece en este formulario la opción de dar de alta, de baja y modificar una
sección. Para dar de baja o modificación se requiere haber seleccionado previamente
un elemento de la lista desplegable, para dar de alta una nueva sección, por el
contrario basta con pulsar el botón nueva.
A.3.3 Gestión de Tamaños
Los tamaños corresponden a las dimensiones que ha ocupado el titular o
anuncio en la publicación donde ha aparecido, esta dimensión se puede denominar de
muchas maneras, véase por ejemplo la relación que ocupa el anuncio frente a la
página completa, es decir media página, cuarto de página, toda página. También
podría ser directamente las dimensiones largo por ancho que ha ocupado el titular, en
cuyo caso habría que escribir al darlo de alta simplemente 15*30, o 20*15.
Figura A.17
154
A.3.4 Gestión Tipo de Enlace
El tipo de enlace de un contenido (titular o anuncio) corresponde a la manera
de acceder al titular o anuncio. Cuando el usuario dé de alta un contenido, ha de
incorporar a toda la información con la que ha clasificado la información, una manera
de acceder a ella. Esta manera de acceder a la información puede ser a través de un
link o enlace URL, o bien a través de un fichero, pero en un futuro puede considerarse
necesario incluir algún tipo de enlace a la información, como por ejemplo incrustando
un video, una imagen etc..
Figura A.18
155
Una vez más, se encontrarán con las tres mismas opciones que anteriormente,
alta, baja y modificación de tipo de enlace.
A.3.5 Gestión Tipo de Titulares o Noticias
Un tipo de Titular o Noticia es como su propio nombre indica cómo se cataloga
ese titular o noticia respecto al género periodístico con el que fue escrito. Éste puede
ser un artículo, un reportaje, una carta al director etc..
Figura A.19
156
Desde este formulario se tiene la opción de modificar, borrar y dar de alta un
nuevo tipo de titular o noticia. Cabe resaltar que para dar de alta uno nuevo no se
requiere haber seleccionado ningún elemento en la lista desplegable, pero si, por el
contrario para el caso de una modificación o un borrado. Si se intentase borrar o
modificar un elemento sin haber seleccionado previamente uno, el mensaje que nos
saldría sería el siguiente:
Figura A.20
157
158
A.4 TITULARES/NOTICIAS
Este es el corazón de la aplicación, la gestión de titulares y noticias. Todas las
administraciones de criterios de búsqueda anteriormente detalladas tienen como
finalidad esta gestión.
Figura A.21
159
Antes de comenzar se ha de explicar que difiere entre un titular o noticia y un
artículo, pues bien, el primero engloba a cualquier tipo de artículo, reportaje, crónica
que se haya realizado en cualquier tipo de medio, ya sea prensa escrita, Internet,
Televisión, y trate sobre algún tema que se haya considerado de interés para la
organización. Los temas pueden tratar de cualquier tema, no tiene por qué haber
ningún tipo de criterio. Por otro lado, un anuncio supone cualquier tipo de aparición en
prensa de nuestra organización. También es independiente el tipo de medio en el que
aparezca pero a los anuncios les unifica un criterio en común, todos ellos están
relacionados con la organización. Es publicidad que algún medio, ya sea pagando o por
donación realiza de Entreculturas. Los anuncios comprenden otro tipo de campos que
los titulares o noticias, como por ejemplo, el campo sección, que representa el tipo de
sección en el que el anuncio ha sido colocado, en caso de que el anuncio se haya
publicado en prensa escrita. También se encontrarían con los campos “Es donación” y
“Es pagado”, que como sus propios nombres indican, denotan si el anuncio ha sido una
donación que se ha hecho a la fundación o se trata de alguna suscripción que
Entreculturas pague al diario. La edición y el número de ejemplares son otros de los
campos que difieren entre unos y otros. Todos estos campos son de mucho interés
para la organización, porque gracias a ellos luego se podrán realizar estudios, ver la
influencia mediática. Hay que tener en cuenta que gracias a este tipo de publicidad es
como se da a conocer la organización, y a mayor conocimiento de la gente, mayor
concienciación y puede repercutir en un aumento en las donaciones que luego se
destinarán a los países mas subdesarrollados. Es por tanto importante llevar un
exhaustivo control de esta materia. Se procederá ahora a explicar cómo funcionan los
mantenimientos de Titulares y Anuncios.
A.4.1 Alta Titular:
160
Esta es la ventana de alta de titular, se ha accedido a ella mediante el menú
principal, Titulares/Noticias, alta titular.
Bien, en esta ventana se hayan una serie de campos que son de obligada
cumplimentación, dado que a través de ellos luego se realizarán las búsquedas y son
registros clave de la base de datos, esto implica que no se podrán dar de alta dos
titulares con los mismos campos obligatorios. El sistema se encarga de ello ya que al
menos un campo clave como es el id de titular lo asigna él automática, secuencial e
incrementalmente. Entre ellos están:
Tipo de Titular/Noticia que comprende si el titular es un reportaje, o se trata de un
artículo de interés o bien es una entrevista... Los datos que en esta lista
desplegable se muestran se pueden gestionar desde gestión de BBDD/ gestión de
Tipo Titular.
Tipo de Medio (Televisión, Internet, Radio, Grupo Mediático, Periódico..) .La lista
desplegable tipo de medio se alimenta de la Base de Datos de Gesco (gestión de
colaboradores), por tanto, este criterio vendrá ya prefijado sin posibilidad de
gestión alguna por parte del usuario, a menos que se acceda a Gesco.
Medio, el nombre del medio (pongase por ejemplo, La Vanguardia, o Radio
Nacional de España). Al igual que el campo Tipo de Medio, el campo Medio, o
mejor dicho su lista desplegable, se alimenta de la base de datos de Gesco, ya que
los medios de que se dispone son a su vez colaboradores de la organización, y
como tal, son entradas en la base de datos de colaboradores. Esto implica que no
hay posibilidad por parte del usuario de gestionar este campo, a menos eso si que
se acceda a Gesco.
Fecha de Publicación: es la fecha en la que se publicó el artículo. No
necesariamente tiene que tratarse del mismo día de la fecha de alta, ni tampoco de
161
la fecha de suceso, ya que se puede registrar (fecha de alta) un articulo días o
meses después de haberse publicado. Esta fecha es considerada la más útil de las
tres fechas que se dispone, y por ello será por esta que en el apartado de
búsquedas se puedan realizar las búsquedas. Es un campo “date” y por tanto se
deberá rellenar con el formato correspondiente dd/mm/aaaa, en caso de que no se
rellene de esta manera un error como el de la figura siguiente emergerá.
Para facilitar toda esta problemática con las fechas se ha dispuesto a este campo
una ventana adicional con un calendario, que emerge cuando se pulsa el botón
contiguo al campo fecha de publicación. La ventana que emerge es la de la figura
siguiente:
Figura A.22
162
En ella el usuario podrá ir cambiando de mes pulsando sobre el mes anterior o
posterior. Una vez encontrado el mes se pulsa el día, y entonces el botón aceptar
aparecerá, el cual tras ser pulsado, transmite al formulario anterior (Alta Titular) el
día seleccionado en el formato adecuado validando de esta manera la fecha. De
esta manera se evita que se introduzcan erróneamente las fechas.
Titulo: breve descripción del artículo, que viene siendo habitual usar la cabecera
del titular como tal, ya que es, en pocas palabras, el resumen del articulo.
Enlace: es el campo dedicado a incluir la ruta de acceso al documento, para el
cual, se habrá de haber seleccionado previamente el tipo de enlace (archivo o
enlace a una página web).
Tipo de Enlace: hay dos opciones, acceso al archivo por medio de link o enlace
Enlace: link a la página web o servidor URL donde se encuentra el documento.
Archivo: ruta de acceso al documento, el cual estará alojado en nuestro servidor
dedicado. Una vez que se selecciona Archivo como tipo de enlace
automáticamente cambiará el formato del campo enlace,
aparecerá un nuevo botón, Explorar, el cual tras pulsarlo nos abrirá un explorador
de Windows como el de la figura inferior.
163
Tras abrirse esta ventana, se navega por el sistema de archivos hasta
encontrar el archivo pdf, fotografía o clip de video que contenga el documento. La
aplicación automáticamente, tras acabar de rellenar todos los campos que se
desean rellenar y pulsar el botón Guardar somete al fichero a un control de tamaño
máximo de archivo, estipulado en 20 MegaBytes, genera una copia del mismo, y lo
aloja en el servidor. A esta nueva copia que se genera se le asigna un nombre de
archivo distinto al original, y siguiendo un criterio de nomenclatura numérica
secuencial, para poder gestionarlo internamente. Tras haber seleccionado el archivo
y haber presionado el botón abrir, la nueva ruta, junto con el nuevo nombre del
documento se mostrará en el campo de texto contiguo al botón examinar (Figura
adjunta).
Este será la ruta absoluta al archivo en cuestión, y será esta la ruta
Figura A.23
164
Que se guarde en la base de datos. En ningún caso se guardará la ruta
original del archivo dado que este dato carece de interés para la organización. Con
este sistema, se consigue que desde cualquier delegación de Fe y Alegría a lo largo
del mundo se pueda seleccionar un archivo en local y que se genere una copia en el
servidor dedicado de Entreculturas Madrid. De esta manera se centraliza y se
gestionan mejor los contenidos.
Además de los mencionados campos obligatorios, se tienen los siguientes
campos que aportan más información al titular pero que se consideran de menor
trascendencia como para hacerlos campos obligatorios:
Edición: puede ser una edición matinal, vespertina... Este es uno de los campos
que se puede gestionar desde el menú Administración BBDD submenú gestión de
ediciones. De tal manera que el usuario puede incluir en este campo lo que
considere oportuno. Si prefiere gestionarlo desde el punto de vista de una edición
diaria, semanal, mensual, bimensual, solo tiene que dirigirse al menú mencionado
y dar las correspondientes altas.
Tamaño: este campo carece de interés en los titulares, no por el contrario en los
anuncios. Describe el tamaño que en caso de tratarse de un anuncio en la prensa
escrita, hubiese ocupado, por ejemplo: media página, portada... Los datos que en
esta lista desplegable se muestran se pueden gestionar desde gestión de BBDD/
gestión de Tamaños.
Campaña: tipo de campaña a la que pertenece el titular, si es que pertenece a
alguna. Este es un campo que carece de valor en el apartado de titulares, pero que
se llena de él en el apartado de Anuncios de Entreculturas. La lista desplegable
campañas se alimenta de la tabla tbl_Campanias, dentro de la base de datos de
Gesco (Gestión de Colaboradores). En la nueva versión Gesdoc 2.0 se ha agregado
165
un buscador de campañas, el que se utiliza en el sistema gestor de colaboradores
GESCO.
En este buscador, el usuario ha de incorporar los criterios de búsqueda que desee
para encontrar la campaña deseada más fácilmente o bien simplemente pulsar el
botón buscar sin ningún criterio seleccionado lo cual dará como resultado todas las
campañas registradas en el sistema.
Sección: La sección de un anuncio o titular, corresponde a la sección dentro de la
publicación en la que aparece, es decir, en cuál de las diferentes partes de una
publicación aparece el contenido que se está dando de alta. Ejemplos de Secciones
podrían ser: internacional, finanzas, portada, deportes, opinión etc.
Número de Página: ayuda a encontrar con facilidad el titular dentro de una
publicación, este campo solo es útil si se refiere a prensa escrita.
Figura A.24
166
Fecha de Alta: se trata de la fecha en la que el titular o anuncio se da de alta, la
genera la aplicación, cogiendo la fecha del sistema. Mantiene el formato
dd/mm/aaaa. Es un campo que el usuario no debe ni puede rellenar, ya que lo
hace el sistema.
Fecha de Suceso: se trata de la fecha en la que aconteció lo relatado en el artículo.
En principio se podría pensar que es un dato carente de utilidad, sobre todo
habiendo otro dato que es Fecha de Publicación, pero en ocasiones, se publica un
artículo cuyo argumento o acontecimiento data de tiempo atrás. Si se da el caso de
que la fecha de suceso y de publicación es idéntica, este campo se puede quedar
sin rellenar, ya que más tarde, las búsquedas se realizarán a través de la fecha de
publicación. Este es un dato meramente informativo carente de valor para una
futura búsqueda. En esta ocasión también se trata de un campo tipo fecha con su
correspondiente formato dd/mm/aaaa, pero también en esta ocasión se dispone
de una ventana calendario adjunta al campo, como el mostrado en el punto
anterior.
Comentario: este es un campo destinado a que el usuario que introduzca el
documento, deje alguna anotación que considere oportuna. Es un campo de texto
con espacio suficiente para albergar cualquier tipo de texto. Si se diese el caso de
que solo se disponga de un documento tipo fotografía, sin un texto que la
acompañe, sería en el campo Comentario, donde se podría introducir el texto
relativo a la fotografía que se adjunte.
Además de los mencionados campos, se ha integrado un nuevo marco dentro de
esta página destinado a englobar la gestión de las categorías y de los datos
geográficos.
167
Dicho marco incluye, a priori, un enlace a los datos geográficos, un botón de
Búsqueda de categorías con el que se accede al formulario de búsqueda de
categorías y un list box donde se mostrarán las categorías que se hayan
seleccionado en el citado formulario.
Cuando el usuario lo desee, con pulsar sobre el link azul de Datos geográficos, se
desplegarán los campos relacionados con dichos datos, quedando el marco de la
siguiente manera:
Una vez desplegados los campos, se han de seleccionar los campos por orden de
precisión, dado que la lista desplegable de País no se llenará hasta que no se haya
seleccionado un Continente del desplegable de Continentes. Lo mismo ocurre con
la lista desplegable de Provincia/Región, es decir, mientras no se hayan
seleccionado previamente un continente y un país dicha lista no se llenará. Cabe
Figura A.25
Figura A.26
168
resaltar que así como los continentes han sido ya dados de alta en su totalidad en
el menú de gestión de datos geográficos, gestión de continentes, los países
asociados a cada continente habrán de ser dados de alta según vayan
necesitándose. Del mismo modo, las Provincias/Regiones no han sido dadas de alta
en su totalidad, es el usuario, el que, si lo necesita, deberá hacerlo previamente a
dar de alta un titular o un anuncio. La población no requiere que se dé de alta
previamente, este campo es un campo de texto normal, es decir, si se necesita
llegar a tanta precisión simplemente se escribe y este se guarda.
Se ha de recalcar, que en la versión anterior de Gesdoc, la versión 1, los datos
geográficos estaban directamente relacionados con las categorías, pero por
motivos prácticos, esta relación ya no existe. Actualmente, en Gesdoc v2 los datos
geográficos estarán asociados, si se desea, al propio titular o anuncio.
Para acceder al formulario de categorías se pulsaría sobre el botón rojo de
Búsqueda de categorías. Al hacer esto emergería una nueva ventana como la
siguiente:
169
En ella se engloba, en esta nueva versión de Gesdoc, todo la gestión de búsqueda
de categorías. Primeramente se selecciona un Tipo de Categoría, automáticamente
se rellenarán en el list box los Subtipos de Categoría asociados a ese tipo. Vease un
ejemplo:
Figura A.27
170
En este caso al seleccionar el Tipo de Categoría Personaje, el list box inferior nos
muestra todas los Subtipos de Categoría asociados. El usuario ahora puede
seleccionar los resultados de uno en uno, seleccionándolo y presionando el botón
Añadir o bien pulsando el Subtipo de Categoría: Todos, el cual a todos los efectos
supone seleccionar todos uno por uno.
En este caso se han seleccionado dos elementos, y como se puede observar en la
figura, al pasar al listbox de la derecha automáticamente dejan de estar en el
listbox de la izquierda. Si se desean eliminar elementos de la búsqueda, se puede
Figura A.28
Figura A.29
171
seleccionar el elemento que se desea eliminar y pulsar el botón Quitar o bien
directamente pulsar el botón Quitar Todos, el cual limpia el listbox de la derecha.
Una gran ventaja de utilizar listboxes es la de que se pueden seleccionar varios
elementos incluso aunque provengan de distinto Tipo de Categoría, vease el
ejemplo:
Como se observa en la figura, en el listbox de la derecha esta Subtipos de Categoría
seleccionados que provienen de distintos Tipos de Categoría.
Una vez se han seleccionado todos los elementos que se desea que sean criterios
de búsqueda se ha de pulsar en el botón buscar para que nos devuelva las
categorías que cumplen con esos criterios.
172
Y el sistema nos devolverá los siguientes resultados, la categoría “Anesbad”
proviene del Tipo “Instituciones”, Subtipo “ONG”, y la categoría “Silvio Berlusconi”
proviene del Tipo “Personaje” subtipo “Político”.
Una vez que se seleccione los resultados de las categorías seleccionadas del grid, se
pulsa el botón Seleccionar y este formulario devolverá las categorías seleccionadas
al formulario desde el que se le llamó, en este caso Alta de Titulares.
Figura A.30
173
Tras haber introducido todos los datos que se deseen en el formulario de alta, al
pulsar el botón Grabar se dará de alta el titular mostrando un mensaje de
confirmación como el siguiente:
Y al aceptar se dará por finalizado el proceso de alta de un titular.
A.4.2 Búsqueda de Titulares:
Esta es la ventana en la cual aquel usuario aunque no esté acreditado como
administrador o como encargado tendrá acceso. El noventa por ciento de los
usuarios accederán en modo consulta, y esta será la ventana a la que accederán
únicamente, ya que no tendrán derecho ni permisos suficientes para dar de alta
artículos.
Figura A.31
174
En esta ventana se realizan las búsquedas de titulares. Para ello se deberá incluir
algún criterio de búsqueda, pudiendo dejar todos en blanco si así se desea, a
sabiendas únicamente que no habrá ningún tipo de filtro en la búsqueda y que los
resultados serán todos los habidos en la base de datos. En caso contrario se tendrá
opción de buscar por todos los criterios que en el momento de su alta fueron de
obligada cumplimentación:
Figura A.32
175
Tipo de Titular/Noticia
Tipo de Medio
Medio
ID de Titular. Así como en el alta, este campo no estaba habilitado ya que era el
sistema el que lo rellenaba, con un sistema de nomenclatura secuencial, para la
búsqueda específica de algún documento es esencial. Con la pega única de que el
usuario ha de conocer tal número. El id introducido ha de ser completo para su
búsqueda, es decir no se buscará por partes del ID, ya que se ha considerado que
los resultados no guardarían ninguna relación entre ellos.
Titulo. Por el contrario, si se desea buscar por el título del artículo, el usuario no
tendría más que recordar o intuir una parte del título. Es decir si quiere buscar el
titular “Campaña contra el hambre en Rwanda” bastaría con que introdujese en el
campo titulo una fracción de la frase como por ejemplo “hambre” para que ese
titular apareciese entre los resultados. De hecho con una fracción de la palabra
bastaría, pero no es recomendable porque el número de resultados puede ser
desconcertante a la hora de encontrar el buscado.
Fecha de Publicación: para tal función se han habilitado de dos campos, uno
llamado Fecha Desde y otro llamado Fecha Hasta, y como son campos tipo fecha,
también en este caso se les ha provisto de su correspondiente botón calendario. En
caso de que solo se rellene el campo Fecha Desde, aparecerían todos los artículos
con fecha de publicación posterior a la introducida. Y por otro lado, si únicamente
se introdujese el campo Fecha Hasta, el sistema devolvería todos los titulares con
fecha de publicación anterior a la fecha introducida.
Categorías: también en la búsqueda se ha dado al usuario la posibilidad de filtrar
por categorías. Para tal uso, se ha de realizar una pequeña búsqueda interna,
176
dentro de la propia página, a través de Tipo de Categoría y de Datos Geográficos.
Tras pulsar el botón búsqueda de Categorías, se llenaría una lista con las categorías
que cumplen esos criterios, y de entre las que aparecen, el usuario ha de
seleccionar las que considere oportunas mediante el botón Añadir, y podría si
fuese necesario desechar alguna que hubiese introducido por error mediante el
botón Quitar.
Tras haber introducido los criterios de búsqueda deseados así como el filtro por
Categorías pertinente el usuario debe pulsar el botón búsqueda de Titulares, tras el
cual y si hay algún artículo que cumple los criterios, se llenara una rejilla o
cuadrícula con los resultados obtenidos. Si no se encuentra ningún resultado, el
sistema informará mediante el correspondiente diálogo. Y para la información del
usuario, si no se cumplimenta ningún criterio de búsqueda y ningún filtro por
Categorías, el sistema devolverá absolutamente todos los titulares que haya en su
haber. Por tanto no se obliga al usuario a introducir ningún tipo de criterio si así lo
desea, aunque la labor de búsqueda de entre todos los artículos habidos en el
sistema puede resultar desconcertante por la elevada cantidad de ellos, así que se
recomienda usar como mínimo un filtro de búsqueda.
177
Una vez esté llenada la tabla con los resultados, si se desea se puede pulsar sobre
el link Limpiar formulario que se encuentra en la parte superior izquierda del grid.
Al pulsar este botón se vaciaría el formulario, dando opción a una nueva búsqueda.
A su vez, en esta nueva versión de Gesdoc, la v2 se ha añadido la funcionalidad de
poder exportar a Excel los resultados de una búsqueda realizada cualquiera. Para
ello, se realiza la búsqueda de titulares o anuncios y con los resultados llenando el
grid se pulsa sobre el botón Exportar Excel y el siguiente mensaje se mostrará por
pantalla:
Figura A.33
178
Si luego se desea consultar dicho archivo Excel generado, habrá de buscarse en la
carpeta de informes que se encuentre en el servidor. El fichero que genera se
muestra a continuación:
Volviendo al grid de resultados, el usuario podrá seleccionar el titular que desee, y
automáticamente se habilitarán los botones antes deshabilitados de borrar,
consultar y modificar. El usuario decide si desea hacer alguna de las tres opciones
que se le ofrecen o simplemente podría dar al link que hay habilitado en la rejilla o
tabla. Los datos de la columna enlace tienen la peculiaridad de ser enlaces directos
al documento, sin necesidad de entrar a consultar el archivo se podría acceder
directamente a él. Lo que sucederá se puede observar en la figura adjunta:
Figura A.34
179
En caso de ser un enlace a un archivo, se lanzará la siguiente ventana
Figura A.35
180
Pudiendo el usuario abrir el fichero directamente, guardarlo o cancelar y no hacer
nada.
Si el usuario se decide por otro tipo de gestión o mantenimiento del artículo
seleccionado no tendrá más que pulsar cualquiera de los tres botones disponibles
para su gestión: borrar, consultar y modificar.
A.4.1.1 Consulta de Titulares:
En esta ventana se puede observar todos los datos con los que el articulo fue dado
de alta el día que se registró. Pero el usuario no podrá tocar ningún campo, ya que
están deshabilitados en el modo consulta.
Figura A.36
181
En esta ventana la única opción que se le deja al usuario es la de aceptar después
de haber consultado los datos del titular. La pagina será redirigida a la página de
búsquedas con el artículo que se acaba de consultar seleccionado.
A.4.1.2 Borrado de Titular:
Cuando después de haber seleccionado un artículo en la ventana de búsquedas en
la rejilla de resultados, se pulsa el botón Borrar, el sistema pasará antes de borrarlo
directamente por una ventana en la que se muestran todos los datos pero con los
Figura A.37
182
campos deshabilitados, es decir en modo consulta. Se hace esto con la intención de
que el usuario se cerciore de que es ese realmente el artículo que desea borrar. Si
esta conforme debe presionar el botón aceptar, tras el cual se le pedirá
confirmación con el correspondiente dialogo y ya finalmente si acepta quedará
totalmente borrado, y el sistema dirigirá al usuario a la ventana anterior, es decir la
de búsquedas y hará la búsqueda que se realizó para encontrar el archivo que se
acaba de borrar, aunque en esta búsqueda obviamente no estará el documento
recién borrado.
A.4.1.3 Modificación de Titular:
Esta ventana es muy similar a la ventana de consulta, pero con una clara diferencia,
esta ventana contiene sus campos habilitados, para que el usuario modifique lo
que necesite, con una salvedad, el Id del titular permanecerá deshabilitado por
razones de seguridad, ya que si se modificase dicho dato, se perdería toda
referencia con el documento inicial. Tampoco estaría habilitada a la modificación la
fecha de alta del artículo ya que este es un dato no sujeto a cambio.
183
Además de poder modificar los datos habilitados, se podrá también cambiar el
documento asignado mediante el botón examinar y seleccionando otro. También
se podrían modificar los datos asociados al filtro por categorías. En el caso de la
figura esta seleccionada la categoría Cooperación, esta se podría quitar y añadir
otra en su lugar, o no asociar ninguna categoría si así se desease.
En el momento en que el usuario pulse el botón grabar, el sistema chequearía su
conformidad mediante un dialogo de confirmación y si este es aceptado el articulo
quedaría modificado.
Figura A.38
184
A.5 ANUNCIOS
Todos los menús de Altas , Búsquedas, Bajas, Consultas y Modificaciones son
idénticos que en la gestión de Titulares, con una salvedad, hay 3 campos que
difieren entre los menús de Titulares y los de menús de Anuncios. Hay que tener en
cuenta que los Titulares engloban cualquier tipo de documento de interés general,
mientras que los Anuncios son apariciones en prensa de Enteculturas, por tanto
tienen otro tipo de interés.
Como se puede observar en la figura, los campos que difieren son:
Figura A.39
185
Tipo de Titular/Noticia ha desaparecido.
Fecha de Suceso también ha desaparecido.
Se ha añadido el campo Número de Página, el cual será útil si la aparición ha sido
en prensa escrita, dado que facilitará a aquel que busque dicho anuncio la
búsqueda.
Se han añadido dos checkbox, Anuncio Pagado y Donación. En ellos el usuario debe
seleccionar uno de los dos. Si el anuncio es una donación de la editorial se marcaría
como donación, si el anuncio se ha pagado, se marcaría como pagado. Este es un
dato que le sirve a la fundación para hacer sus estudios de mercado.
En lo relativo a todo lo demás los menús son exactamente iguales. De hecho la
tabla donde se almacenan los anuncios es la misma donde se almacenan los
titulares. Es la tabla tbl_contenido.
186
A.6 BOLETÍN INFORMATIVO
Desde la página web corporativa (publica) de la Fundación Entreculturas, cualquier
usuario que acceda a la página alrededor del mundo puede darse de alta en el
boletín informativo de Entreculturas.
Simplemente deberá pulsar sobre el link “boletín electrónico aquí” que se
encuentra en la parte inferior izquierda de la figura.
Tras pulsar sobre él, la página se redirigirá a una nueva página en la que se dan de
alta los interesados en el boletín.
Figura A.40
187
Ya en esta página, el usuario deberá pulsar sobre el link “Suscríbete” situado en el
centro de la página en letras rojas. Una vez que se pulse dicho link, una ventana
emergente de Microsoft Outlook aparecerá:
Figura A.41
188
En ella ya vienen por defecto insertados los datos necesarios para que el usuario
únicamente tenga que pulsar el botón Enviar.
Una vez enviado dicho mail, el departamento de comunicación recibirá dicho e-
mail en el buzón Noticias, y ellos mismos se encargarán de incluir el mail del
usuario que envión dicho mail, pasando éste a formar parte del listado RSS de
contactos de Outlook a los cuales se les envía periódicamente el correo/boletín
informativo de la fundación.
Una vez hecho esto, el personal del departamento de comunicación de la
fundación cuando lo considere oportuno, desde la página principal de Gesdoc
podrá acceder al nuevo desarrollo Boletín Informativo:
Al pulsar sobre el icono de RSS automáticamente se lanzará una ventana emergente de
Outlook como la siguiente:
Figura A.42
189
El empleado no tendrá más que pulsar el botón enviar para que el boletín llegue a
todos los usuarios que se hayan dado de alta en el servicio.
Figura A.43
