5.- Plan de trabajo del proyecto

5.1.- Iteración 1

5.1.1.- Fase 1 - Análisis del mercado y propuesta funcional

5.1.2.- Fase 2 - Diseño y definición de especificaciones funcionales

En esta fase del desarrollo se ha realizado el análisis de requerimientos funcionales y no funcionales, así como de los casos de uso que pueda presentar el sistema. La accesibilidad es un requisito no funcional pero que se ha considerado junto al resto de requisitos funcionales de la plataforma ya que el objetivo de este proyecto es llegar a todo tipo de usuarios e integrar a grupos de usuarios en peligro de exclusión.

Una vez definidos todos los casos de uso, se realizó una definición de la arquitectura de software a desarrollar. El trabajo se realizó intentando elaborar en la medida de lo posible una plataforma no sólo funcionalmente completa, sino también fácilmente adaptable y escalable.

El diálogo entre los cooperantes del proyecto propició la elaboración de estas tareas de manera completa, aportando robustez a los diseños y definiendo las líneas a seguir para el cumplimiento de todos los objetivos establecidos para el proyecto.

Los resultados de las actividades desarrolladas en esta fase del proyecto se ven plasmados en los documentos "Documento de especificación de requisitos" y "Diseño inicial de la arquitectura software".

5.1.2.1.- Definición de requerimientos funcionales de la aplicación

a) Trabajos desarrollados por FRACTALIA

A partir de los resultados obtenidos en la fase anterior, y de la experiencia de la que ya se disponía, se comenzó el análisis de requerimientos funcionales y no funcionales, así como de los casos de uso que pueda presentar el sistema.

Al conocer de antemano los casos de uso asociados implícitamente al desarrollo de una plataforma Web, se comenzó la definición de los requisitos funcionales asociados a ellos. Esto, junto con las necesidades encontradas durante la fase de análisis anterior, posibilitó la elaboración de una definición de requisitos funcionales que solventara todas las casuísticas encontradas.

Una vez elaborada esta definición, incorporando todos los casos de uso añadidos que necesariamente aparecen durante el análisis exhaustivo que se realiza del sistema, se terminaron de definir todos los requisitos tanto funcionales como no funcionales, detallando en la medida necesaria el funcionamiento de bajo nivel de la plataforma.

El diálogo entre los cooperantes del proyecto propició la elaboración de estas tareas de manera completa, aportando robustez a los diseños y definiendo las líneas a seguir para el cumplimiento de todos los objetivos establecidos para el proyecto.

b) Trabajos desarrollados por CESyA

La Accesibilidad en este proyecto ha sido incluida desde la fase de análisis, debido a que entre los objetivos del proyecto se tiene llegar a todo tipo de usuarios e integrar a grupos de usuarios en peligro de exclusión. El cumplimiento del estándar WCAG tal como marca la normativa vigente es requisito y además, para que los niveles de accesibilidad sean duraderos en el tiempo después del lanzamiento de la plataforma, la accesibilidad y toda la usabilidad que puede dificultar el acceso en el interfaz de usuario final (web, PDA) debe ser tenida en cuenta. La accesibilidad es un Requisito No Funcional pero que debe considerarse en el resto de los Requisitos Funcionales de la plataforma. Para asegurar una sistematización de la accesibilidad hay Requisitos Funcionales a considerar, por lo que se ha llevado a cabo:

1. Un mapa navegacional y estructural para considerar requisitos de navegación de la plataforma.
2. Análisis de los componentes afectados en torno a la accesibilidad en el análisis de requisitos, a saber, inclusión de recursos de ayuda como menús, ayuda, buscador, etc; Mecanismo para que los usuarios puedan poner una queja o sugerencia en relación a barreras y mejoras en la accesibilidad y asegurar que ante existencia en el interfaz de usuario de alguna opción de edición de nuevo contenido al usuario, este sea editado de manera accesible.

c) Trabajos desarrollados por DAEDALUS

Teniendo en cuenta el aspecto multilingüe, es necesario definir los requisitos correspondientes. El contenido del sitio web de la plataforma debe estar disponible en los diferentes idiomas contemplados: español, inglés, francés e italiano, y debe ser posible acceder a sus contenidos en cualquiera de estas lenguas. Esta funcionalidad de búsqueda requiere la inclusión de un proceso de indexación, que obliga a introducir dos tipos de usuario, el administrador, encargado de velar porque la plataforma esté disponible, y el usuario final, que interactuará a través de la plataforma de DISUIPA para obtener acceso a la red. Con esto, se impone los siguientes requisitos desde el punto de vista de las búsquedas multilingües:

1. El usuario final podrá efectuar búsquedas sobre el contenido de la web empleando cualquiera de los cuatro idiomas contemplados.
2. El usuario final sólo recibirá respuestas en el mismo idioma en que ha efectuado la consulta. En el marco definido en este proyecto no tendría sentido una búsqueda croslingüe, en la que un usuario podría recibir respuestas en un idioma diferente al utilizado para expresar su consulta.
3. El usuario final podrá emplear palabras o expresiones semánticamente equivalentes a los términos que aparecen en las páginas de respuesta. Esta es la esencia del buscador semántico, procurar que los usuarios no tengan que utilizar exactamente las mismas palabras que aparecen el contenido sobre el que se busca, pudiendo hacer referencia a conceptos más que a palabras o términos específicos.
4. El administrador del sistema dispondrá de las herramientas necesarias para construir los índices necesarios.

Desde el punto de vista del control de accesos al sitio web de la plataforma, los requisitos a imponer sólo hacen referencia al administrador de la plataforma, puesto que la información sobre el uso del sitio web no atañe a los usuarios finales. Esta funcionalidad se ofrece a través de un servicio, accesible a través de web. Los requisitos funcionales a tener en cuenta en este caso serán.

1. El administrador podrá acceder vía web a distintos informes de tráfico del sitio web.
2. El administrador podrá configurar la herramienta para personalizar los informes en cuanto a periodos de tiempo reflejados y medidas de tráfico a mostrar.

En el apartado 3.6 de esta memoria se ofrece un extenso detalle de las características de los informes que se pueden generar a través del servicio.

5.1.2.2.- Elaboración del diseño inicial de la arquitectura software

a) Trabajos desarrollados por FRACTALIA

El análisis realizado en el hito anterior sobre las funcionalidades a cumplir por parte de la plataforma, así como de los diferentes casos de uso que puedan presentarse, permitió realizar una definición de la arquitectura de software a desarrollar.

Los distintos módulos, así como las interacciones entre ellos, se diseñaron de manera que se adaptasen a los requisitos definidos, teniendo en cuenta el conocimiento aportado por los cooperantes y las necesidades especificadas para la adaptación e interacción con sus definiciones.

El trabajo se realizó intentando elaborar en la medida de lo posible de una plataforma no sólo funcionalmente completa, sino también fácilmente adaptable y escalable.

b) Trabajos desarrollados por CESyA

Hay una dependencia importante de la accesibilidad con la tecnología y arquitectura que va a ser utilizada en la plataforma. Se conseguirá una plataforma accesible que cumpla las WCAG en su nivel AA y AAA dependiendo de qué componentes software y cómo estos se utilicen. Se ha analizado la arquitectura basada en la plataforma .net utilizada. La plataforma .net es una arquitectura de capas que separa la capa de vista de la de la lógica de negocio, característica que favorece la accesibilidad, pero aun así se pueden dar muchas situaciones de excepción con las WCAG. Con el fin de descartar estas situaciones de conflicto con la accesibilidad desde el CESYA se ha asesorado y proporcionado soluciones al respecto.

Se determinaron componentes tecnológicos afectados por la accesibilidad (ver Figura 1) como:

1. Necesidad de incluir en el modelado y almacenamiento de datos el contenido necesario para poder cumplir con las WCAG en las páginas web finales gestionadas de manera dinámica por .asp como: (a) texto alternativo de las imágenes que se vayan a incluir, (b) un marcado para saber qué textos van a ser títulos en las páginas web, (c) un marcado para saber si algo enlaza con un sitio externo o interno, (d) el idioma del contenido a insertar, (e) subtitulado y transcripción para los videos que se incluyan, (f) campos y etiquetas de los que se componen los formularios, etc.
2. Alternativas accesibles para solventar el problema de accesibilidad existente ante la utilización de técnicas de scripting que dejen rastro en el cliente como javascript.
3. Indicar que el diseño e implementación de las hoja/as de estilo deben validarse según los estándares CSS y WCAG.
4. Diseño e implementación de plantillas, es decir, páginas en XHTML estático donde se incluye el contenido de manera dinámica mediante .asp, accesibles según WCAG y validadas con estándar XHTML del W3C.
5. Aspectos a considerar en la implementación en .asp de las reglas de generación de código final de manera dinámica para que valide el código final de las páginas web según los estándares de la W3C como XHTML y CSS, así como de las WCAG. Necesidad de un estudio para confirmar que no hay conflicto con la accesibilidad (por ejemplo, dejar rastro en el código del cliente) al integrar con REMOTING servicios como SMS, PMS, CVV, así como la autenticación con RADIUS.

c) Trabajos desarrollados por DAEDALUS

Los requerimientos referidos a la búsqueda multilingüe y al seguimiento de las visitas al sitio web de la plataforma requieren la incorporación de dos componentes software:

1. Componente de indexación/búsqueda: Este elemento encapsula toda la funcionalidad relativa a búsqueda de información. Proporcionará una interfaz de programación que expondrá las funciones necesarias para parametrizar y ejecutar el proceso de indexación. Durante el proceso se generarán cuatro índices, uno para cada idioma contemplado en el sistema, que se generarán a partir del contenido de las páginas de preguntas frecuentes de la plataforma.
2. Servicio de seguimiento de visitas: Requerirá de la incorporación de una base de datos en la plataforma para almacenar los registros de los accesos de los visitantes del sitio web. La agregación de dichos datos se lleva a cabo por los distintos módulos de análisis que constituyen el servicio, cuyos productos se muestran a través de una interfaz web. El acceso al servicio se realiza a través de HTTP, lo que simplifica la integración del servicio en la plataforma.

5.1.3.- Fase 3 - Desarrollo de módulos básicos

5.1.4.- Fase 4 - Integración y pruebas de la plataforma básica

5.2.- Iteración 2