Implementación

Este apartado y el siguiente contienen dos actividades del modelo de proceso que no por ser menos importantes están menos desarrollados que las anteriores. Se trata de las actividades de la implementación (en este punto) y del lanzamiento del sistema (en el siguiente). El motivo de la menor extensión dedicada a ellas se debe a que el desarrollo de sistemas interactivos centrados en los usuarios el trabajo importante de comprensión de los conceptos relativos se ha realizado y consolidado durante todas las etapas anteriores, mientras que las actividades de estas fases pertenecen mayoritariamente a la Ingeniería Software.

De todas maneras, el MPIu+a sí que incide en la necesidad de continuar realizando constantes evaluaciones de prototipos o versiones preliminares del sistema final (en momentos próximos al lanzamiento) con implicación directa de usuarios e implicados representativos.
La fase de implementación es conocida también como fase de codificación, pues supone todo el proceso de escribir el código software necesario que hará posible que el sistema finalmente implementado cumpla con las especificaciones establecidas en la fase de análisis de requisitos y responda al diseño del sistema descrito en la fase anterior.

Habitualmente esta fase es la que requiere de mayor dedicación en cuanto a recursos personales, no obstante, este factor se ve minimizado si se sigue el proceso aquí descrito, pues el impacto del cambio se ve minimizado por el buen trabajo previamente realizado.

A pesar de que tanto desde la óptica más clásica de la Ingeniería del Software como de la visión de la Ingeniería de la Usabilidad o de los estándares de calidad del Software se remarca la necesidad de profundizar en las fases anteriores en realidad la mayoría de proyectos que actualmente se desarrollan en la industria suelen basarse solamente en esta fase de codificación, lo que provoca innumerables cambios que responden a los cambios de las necesidades de los clientes o a los cambios derivados de malas interpretaciones de dichas necesidades.

Comentario a título personal: Cuento en mi experiencia laboral con más de una década desarrollando procesos y proyectos software para varias empresas, así como un elevado número de colaboraciones con empresas del sector informático especializado en servicios y desarrollo software. Ello me permite asegurar que la mayoría de proyectos de sistemas software interactivos parten de una pobre definición de requisitos funcionales para pasar directamente a la fase de codificación y a partir de las primeras líneas de código que los programadores escriben se va forjando el resto del código del sistema final. Y normalmente, estas primeras líneas de código permanecen en él durante el resto de su vida útil… causando innumerables problemas difícilmente justificables.

Esta fase agrupa toda la programación del software necesario para concretar la aplicación junto con todos los procesos necesarios para el ensamblaje entre los módulos y dispositivos.

Cuando se llega a esta fase del modelo de proceso ya se han determinado el o los lenguajes de programación a utilizar para la implementación del proyecto, las bases de datos correspondientes que se precisen, los sistemas de intercomunicación de procesos, y en general toda la tecnología subyacente.

Así que todo lo que en este punto debería tratarse no deja de ser lo que la ingeniería clásica del software trata de por sí, con especial inciso en remarcar que para garantizar la usabilidad y la accesibilidad del sistema final no debemos olvidar realizar durante esta fase cuantos prototipos sean necesarios con sus correspondientes evaluaciones.

La propuesta del modelo de proceso de la Ingeniería de la Usabilidad y la Accesibilidad, como se ha venido repitiendo, ofrece una metodología destinada a conseguir la usabilidad y accesibilidad del producto interactivo, no de cómo éste debe ser programado y qué tecnología utilizar.

En esta fase son recomendables realizar prototipos software en los estados iniciales de implementación para evaluarlos con usuarios finales cuanto antes mejor.

Las aportaciones de evaluar en esta fase son altamente valiosas para no malgastar tiempo en desarrollar software que después deberá, sin ninguna duda, ser cambiado.

Para acabar, es muy recomendable al final de esta fase y antes de empezar la etapa de lanzamiento evaluar el sistema mediante el método de la evaluación heurística para comprobar la consistencia global del producto justo antes de su puesta en escena.

A %d blogueros les gusta esto: