La Accesibilidad en Ingeniería del Software
En la actualidad, la gran mayoría de los Sistemas de Información de mediana y gran envergadura siguen un proceso de desarrollo por etapas conocido como Ingeniería del Software que cumple con varias normativas ISO para su estandarización:
Lógicamente, todo esta Ingeniería es válida y usada en el desarrollo de Sistemas de Información basados en Web, que son los que especialmente me interesan, aunque se puede enfocar generalmente para cualquier Sistema de Información.
Estas etapas son (por orden cronológico): Especificación, Diseño e Implementación. Os daré una definición propia para cada una de ellas:
Especificación: Son el conjunto de técnicas y/o pautas que se siguen para determinar las funcionalidades y requisitos que el Sistema de Información va a tener, así como los diversos componentes que de él van a formar parte.
Diseño: Se modela la especificación y se crea un mapa conceptual de diseño con los componentes software que forman el proyecto, así como la interacción que seguirán entre ellos. Se establecen también los modos de comunicación, patrones y objetos para el desarrollo del sistema.
Implementación: Tras tener la visión clara y concisa que proporciona el diseño, basta con escoger una plataforma de desarrollo y un lenguaje de programación y codificar literalmente los diagramas de secuencia y operaciones obtenidas del diseño.
El ciclo de vida del software es algo más complejo que lo que aquí explico, cada etapa tiene sus metodologías muy clarificadas y bastante estandarizadas además de existir una realimentación de atrás hacía adelante para el mantenimiento y actualización del Sistema de Información.
Pues bien, ¿Dónde encontramos la Accesibilidad en todo este desarrollo?
De la experiencia que he ido adquiriendo a lo largo de estos últimos meses, podría casi afirmar que la Accesibilidad es parte de la implementación, allí donde se diseñan, gráficamente (no confundir con diseño conceptual) las interfaces de usuario.
Dicho de otra manera: Allí donde se programa usando XHTML y CSS o sea, en Implementación.
La cuestión es: ¿Se pueden aplicar los principios de Accesibilidad en las otras etapas?
A lo que yo mismo me respondo un enorme SÍ.
Posteriormente: ¿Por qué razónes no se aplican entonces?
* Falta de concienciación y conocimiento y/o experiencia en el tema.
* Por el mismo motivo que no siempre se aplica un desarrollo basado en esta metodología. Falta de tiempo, recursos y bagaje analítico.
* Por que los clientes tienen 10 razones por las que no invertir en accesibilidad.
* A saber…
¿Qué perfiles informáticos y en qué fases se podrían hacer cargo de la Accesibilidad?
- El especificador en la Especificación.
- El analista y el diseñador de bases de datos en Diseño.
- El programador y el diseñador gráfico en Implementación.
O sea, todas por las que pasa un sistema software en desarrollo, tienen la posibilidad de aplicar la Accesibilidad en su etapa correspondientes.
Pero no, de todos ellos, es únicamente los programadores y diseñadores gráficos sobre quién recae toda la carga, en cuanto a trabajo, que puede requerir un Sistema Software según las necesidades y los objetivos pactados entre cliente y especificador durante el análisis de requerimientos del sistema.
¿Se obtendría alguna mejora de aplicar los principios de accesibilidad en las diferentes etapas?
Lógicamente sí. Los implementadotes están formados para codificar un modelo estandarizado (p.e en UML- Unified Modeling Language) a su lenguaje de programación. Si el analista que ha modelado el sistema ya ha tenido en cuenta la accesibilidad durante su etapa, el programador solo se deberá a aplicar la accesibilidad a elementos muy propios de la programación, es decir, al código fuente. Ahorrándose así tener que desarrollar nuevos comportamientos y funcionalidades (por iniciativa propia) para obtener la accesibilidad en ciertos requisitos del sistema en los cuales el diseñador no la ha tenido en cuenta.
Pero es más, si a su vez el especificador hubiera especificado con la accesibilidad in mente, el diseñador no habría tenido que averiguar (por iniciativa propia) las funcionalidades que requieren de unos comportamientos diferentes, especiales, para su accesibilidad, o de unos requisitos exigidos por el cliente.
Ahorrándose esto, el diseñador se centrará más en temas de accesibilidad para los elementos básicos de su labor: los componentes del sistema y la interacción entre ellos.
El pez que se muerde la cola como veis.
Distribuir la accesibilidad entre todas las etapas haría que el proceso de “accesibilización” de una página se redujera a aplicar pocos principios en cada una de las etapas, pero el resultado final, sería en el peor de los casos el mismo que tal y como se desarrolla ahora.
Además evitaría el, “Uf, ahora hay que hacer esto accesible” cuando ya está en una versión beta, porque casi sin darse cuenta, todo el proceso se habrá hecho antes.
¿Cómo lograríamos que el especificador y el analista hicieran su labor integrando la accesibilidad como un requisito más del sistema?
Sólo hay una manera: Concienciación y Formación.
¿La teoría queda bastante clara verdad?
Si todos ponemos de lo nuestro, el proyecto sale mejor. Argumentación simple y sencilla.
Pero pongámonos ahora en la piel de cada profesional para ver qué puede aportar él, en su etapa, a la accesibilidad final del Sistema.
El Especificador
Tal vez la labor más primordial, ya no solo del especificador si no de todo el proyecto, es saber captar los requerimientos que el cliente nos solicita. El cliente es un usuario inexperto en informática (por eso requiere nuestro servicio), pero es muy experto en su sector, nos hablará de su visión de negocio, de las funcionalidades que necesita obtener del programa para agilizar el trabajo de sus empleados, de beneficios, gastos… Pero pocas veces se va a dar el caso que sea el cliente que nos diga: esta parte del Sistema necesito que sea accesible para tal motivo o para tal otro.
Pensemos en un ejemplo de requerimiento accesible que no tenga por que estar relacionado con disfunciones físicas o psíquicas de los usuarios. Algo mucho más simple.
Este aspecto concierne al Analisi de Requerimientos que realiza el especificador. Veamos otro caso relacionado con otra sub-etapa de la Especificación.
En este ejemplo aparte de problemas de accesibilidad los hay también de usabilidad, pero vale para ver que en la sub-tarea de definición de Casos de Uso, el especificador puede considerar actores del sistema que no tienen porque seguir el mismo comportamiento que los demás.
El Diseñador
Hemos comentado que el diseñador (conceptual) es el profesional que se encarga de abstraer las necesidades del cliente un nivel por encima, de tal manera que se pueda modelar el concepto en un componente software, entiéndase: objetos y/o funciones. Al final de su etapa el diseñador conceptual hace unos esquemas del diseño gráfico de la aplicación con el fin de indicar los campos y datos que necesita para la ejecución de sus funciones.
Tal vez si el especificador no hubiera documentado nada acerca del Caso de uso “especial” para el empleado discapacitado, el diseñador no habría tenido en cuenta los posibles objetos y funciones que fueran necesarios para desarrollar ese comportamiento diferenciado del de los demás usuarios. Pero esto es un ejemplo acarreado por un fallo del especificador.
Veamos que aspectos debe controlar el diseñador en su etapa por una mejor accesibilidad y/o usabilidad.
Todos sabemos el ámbito de trabajo de este profesional basándose en la codificación y el diseño grafico para proporcionar un front-end amigable, usable y accesible. Así que no hablaremos de él porque la asociación que existe entre accesibilidad y diseño gráfico o programación la conocemos todos y el objetivo era demostrar que se puede hacer un seguimiento de la accesibilidad durante todas las etapas de la Ingeniería del Software.
Esperemos pues, que en un futuro no muy lejano, la accesibilidad se extienda a toda la Ingeniería del Software para una mejora incremental durante el desarrollo de los Sistemas Software del mañana.
· ISO/IEC FDIS 9126-1 (2000): Ingeniería de Software y Calidad de Producto
· ISO 13407 (1999): Procesos de diseño centrado en las personas para sistemas interactivos
· ISO TR 18529 (2000): Ergonomía de la interacción persona-sistema. Descripciones del proceso del ciclo de vida centrado en las personas
Lógicamente, todo esta Ingeniería es válida y usada en el desarrollo de Sistemas de Información basados en Web, que son los que especialmente me interesan, aunque se puede enfocar generalmente para cualquier Sistema de Información.
Estas etapas son (por orden cronológico): Especificación, Diseño e Implementación. Os daré una definición propia para cada una de ellas:
Especificación: Son el conjunto de técnicas y/o pautas que se siguen para determinar las funcionalidades y requisitos que el Sistema de Información va a tener, así como los diversos componentes que de él van a formar parte.
Diseño: Se modela la especificación y se crea un mapa conceptual de diseño con los componentes software que forman el proyecto, así como la interacción que seguirán entre ellos. Se establecen también los modos de comunicación, patrones y objetos para el desarrollo del sistema.
Implementación: Tras tener la visión clara y concisa que proporciona el diseño, basta con escoger una plataforma de desarrollo y un lenguaje de programación y codificar literalmente los diagramas de secuencia y operaciones obtenidas del diseño.
El ciclo de vida del software es algo más complejo que lo que aquí explico, cada etapa tiene sus metodologías muy clarificadas y bastante estandarizadas además de existir una realimentación de atrás hacía adelante para el mantenimiento y actualización del Sistema de Información.
Pues bien, ¿Dónde encontramos la Accesibilidad en todo este desarrollo?
De la experiencia que he ido adquiriendo a lo largo de estos últimos meses, podría casi afirmar que la Accesibilidad es parte de la implementación, allí donde se diseñan, gráficamente (no confundir con diseño conceptual) las interfaces de usuario.
Dicho de otra manera: Allí donde se programa usando XHTML y CSS o sea, en Implementación.
La cuestión es: ¿Se pueden aplicar los principios de Accesibilidad en las otras etapas?
A lo que yo mismo me respondo un enorme SÍ.
Posteriormente: ¿Por qué razónes no se aplican entonces?
* Falta de concienciación y conocimiento y/o experiencia en el tema.
* Por el mismo motivo que no siempre se aplica un desarrollo basado en esta metodología. Falta de tiempo, recursos y bagaje analítico.
* Por que los clientes tienen 10 razones por las que no invertir en accesibilidad.
* A saber…
¿Qué perfiles informáticos y en qué fases se podrían hacer cargo de la Accesibilidad?
- El especificador en la Especificación.
- El analista y el diseñador de bases de datos en Diseño.
- El programador y el diseñador gráfico en Implementación.
O sea, todas por las que pasa un sistema software en desarrollo, tienen la posibilidad de aplicar la Accesibilidad en su etapa correspondientes.
Pero no, de todos ellos, es únicamente los programadores y diseñadores gráficos sobre quién recae toda la carga, en cuanto a trabajo, que puede requerir un Sistema Software según las necesidades y los objetivos pactados entre cliente y especificador durante el análisis de requerimientos del sistema.
¿Se obtendría alguna mejora de aplicar los principios de accesibilidad en las diferentes etapas?
Lógicamente sí. Los implementadotes están formados para codificar un modelo estandarizado (p.e en UML- Unified Modeling Language) a su lenguaje de programación. Si el analista que ha modelado el sistema ya ha tenido en cuenta la accesibilidad durante su etapa, el programador solo se deberá a aplicar la accesibilidad a elementos muy propios de la programación, es decir, al código fuente. Ahorrándose así tener que desarrollar nuevos comportamientos y funcionalidades (por iniciativa propia) para obtener la accesibilidad en ciertos requisitos del sistema en los cuales el diseñador no la ha tenido en cuenta.
Pero es más, si a su vez el especificador hubiera especificado con la accesibilidad in mente, el diseñador no habría tenido que averiguar (por iniciativa propia) las funcionalidades que requieren de unos comportamientos diferentes, especiales, para su accesibilidad, o de unos requisitos exigidos por el cliente.
Ahorrándose esto, el diseñador se centrará más en temas de accesibilidad para los elementos básicos de su labor: los componentes del sistema y la interacción entre ellos.
El pez que se muerde la cola como veis.
Distribuir la accesibilidad entre todas las etapas haría que el proceso de “accesibilización” de una página se redujera a aplicar pocos principios en cada una de las etapas, pero el resultado final, sería en el peor de los casos el mismo que tal y como se desarrolla ahora.
Además evitaría el, “Uf, ahora hay que hacer esto accesible” cuando ya está en una versión beta, porque casi sin darse cuenta, todo el proceso se habrá hecho antes.
¿Cómo lograríamos que el especificador y el analista hicieran su labor integrando la accesibilidad como un requisito más del sistema?
Sólo hay una manera: Concienciación y Formación.
¿La teoría queda bastante clara verdad?
Si todos ponemos de lo nuestro, el proyecto sale mejor. Argumentación simple y sencilla.
Pero pongámonos ahora en la piel de cada profesional para ver qué puede aportar él, en su etapa, a la accesibilidad final del Sistema.
El Especificador
Tal vez la labor más primordial, ya no solo del especificador si no de todo el proyecto, es saber captar los requerimientos que el cliente nos solicita. El cliente es un usuario inexperto en informática (por eso requiere nuestro servicio), pero es muy experto en su sector, nos hablará de su visión de negocio, de las funcionalidades que necesita obtener del programa para agilizar el trabajo de sus empleados, de beneficios, gastos… Pero pocas veces se va a dar el caso que sea el cliente que nos diga: esta parte del Sistema necesito que sea accesible para tal motivo o para tal otro.
Pensemos en un ejemplo de requerimiento accesible que no tenga por que estar relacionado con disfunciones físicas o psíquicas de los usuarios. Algo mucho más simple.
El jefe se pasa la semana fuera de la empresa y todos los días quiere poder acceder desde su PDA a una herramienta de reporting que el sistema llevará integrada.Si el especificador no entrevé un posible problema de accesibilidad en este aspecto, no tomará nota de esto, y todo el posterior proceso de reporting se hará sin tener en cuenta este aspecto.
Este aspecto concierne al Analisi de Requerimientos que realiza el especificador. Veamos otro caso relacionado con otra sub-etapa de la Especificación.
En la empresa hay una persona discapacitada motriz que lleva 30 años trabajando allí y es de muchísimo valor para la empresa dada su experiencia. Esta persona es la encargada de actualizar diariamente las previsiones de ventas para los próximos días. La discapacidad del trabajador impide a este el uso del teclado cómodamente (lo usa con mucha dificultad).
El cálculo de previsiones es un proceso crítico en la empresa, y tras cada operación se requiere una verificación y aceptación de la misma por parte del usuario. El sistema lanza un mensaje tras cada paso pidiendo confirmación.
Pero el usuario discapacitado dada su experiencia, no requiere de una confirmación para saber si está haciendo bien la actualización o no. Ya que por simples cálculos a partir de datos históricos conoce el resultado de dicha actualización de antemano.
Bien, el especificador al no percatarse de que hay un usuario, un “actor del sistema” que requiere un comportamiento “especial” al de los demás usuarios en ese Caso de Uso, está causando que el discapacitado tenga que sobre-esforzarse de manera totalmente innecesaria para llevar a cabo su labor.
En este ejemplo aparte de problemas de accesibilidad los hay también de usabilidad, pero vale para ver que en la sub-tarea de definición de Casos de Uso, el especificador puede considerar actores del sistema que no tienen porque seguir el mismo comportamiento que los demás.
El Diseñador
Hemos comentado que el diseñador (conceptual) es el profesional que se encarga de abstraer las necesidades del cliente un nivel por encima, de tal manera que se pueda modelar el concepto en un componente software, entiéndase: objetos y/o funciones. Al final de su etapa el diseñador conceptual hace unos esquemas del diseño gráfico de la aplicación con el fin de indicar los campos y datos que necesita para la ejecución de sus funciones.
Tal vez si el especificador no hubiera documentado nada acerca del Caso de uso “especial” para el empleado discapacitado, el diseñador no habría tenido en cuenta los posibles objetos y funciones que fueran necesarios para desarrollar ese comportamiento diferenciado del de los demás usuarios. Pero esto es un ejemplo acarreado por un fallo del especificador.
Veamos que aspectos debe controlar el diseñador en su etapa por una mejor accesibilidad y/o usabilidad.
La empresa ya tenía un sistema de indicadores de stock de una versión antigua, a la que los empleados estaban muy acostumbrados tras 10 años de trabajo sobre él. En el nuevo diseño se ha modificado la estructura del formulario, se han cambiado colores, incluso antes era en modo texto y ahora es con ventanas mil colores y formas diferentes. Cuando presentemos esto al usuario, éste se sentirá confuso y habremos provocado un riesgo funcional (riesgo provocado por un funcionamiento no habitual o intuitivo de un sistema) que incluso puede llegar a provocar el rechazo del usuario a la nueva aplicación.El programador
Todos sabemos el ámbito de trabajo de este profesional basándose en la codificación y el diseño grafico para proporcionar un front-end amigable, usable y accesible. Así que no hablaremos de él porque la asociación que existe entre accesibilidad y diseño gráfico o programación la conocemos todos y el objetivo era demostrar que se puede hacer un seguimiento de la accesibilidad durante todas las etapas de la Ingeniería del Software.
Esperemos pues, que en un futuro no muy lejano, la accesibilidad se extienda a toda la Ingeniería del Software para una mejora incremental durante el desarrollo de los Sistemas Software del mañana.
<< Inicio