• No se han encontrado resultados

Durante el desarrollo del proyecto

3 CAPITULO

3.2 Durante el desarrollo del proyecto

- Mantener siempre presente el tipo de usuario a quien va dirigida la aplicación y diferenciarlo del rol del cliente, quien solicita el desarrollo del producto y tiene mayor conocimiento de los requisitos (i.e. entidad de gobierno como alcaldías municipales, secretarías), mientras que el usuario es la persona que interactúa directamente con la aplicación (i.e ciudadano corriente). El contenido y los mapas que se brindan deben ser útiles e interesantes, de manera que cautiven la atención del usuario. El éxito de una aplicación además de estar mediada por el cumplimiento de los requisitos, está relacionada con el provecho que las personas saquen de ella, y en algunos casos por el crecimiento en número de usuarios. La utilización de herramientas disponibles en línea (el caso de ArcGIS Online) es valiosa para hacer demostraciones al cliente y hacer acercamientos con el usuario, que si bien no van a ser parte de la solución final sirven para retroalimentar el desarrollo. Las siguientes imágenes refieren a tres principios a ser tomados en cuenta: en primer lugar, KISS (keep it simple), usabilidad y rendimiento- velocidad de respuesta

Figura 53. KISS, usabilidad y rendimiento. Tomadas de (Anta, 2012 ) (izq) y (Lamas, 2011) (der y abajo) - Priorizar las funcionalidades a implementar: aquellas que tengan valor

significativo para el cliente deben ocupar los primeros lugares.

- Analizar qué calidades sistémicas prevalecerán sobre otras, ya que esto impacta directamente a la arquitectura, por ejemplo, si se requiere de altos niveles de seguridad, el performance se ve afectado; si la disponibilidad es de 7 X 24, se deben contar con mecanismos de redundancia; si el público a quien se dirige la aplicación es no experto, la usabilidad y la experiencia de usuario deben primar.

- Conformar un grupo para la selección de tecnologías, entre los integrantes deben figurar el director y el arquitecto. Las condiciones del proyecto, la experiencia y las pruebas de concepto son determinantes en este proceso. - El punto de partida para la aplicación es generar un esquema de GUI (Interfaz

gráfica de usuario), por ejemplo, la siguiente imagen muestra un layout tradicional:

Figura 54. Layout básico

El mapa es el objeto más importante dentro la aplicación, por ello ocupa buena parte de la página y está centrado. Sobre él se efectuarán la gran mayoría de operaciones, entonces es necesario crear una clase que lo represente y pueda ser compartida por todas las funcionalidades, el concepto se asemeja a un singleton del cual dependen los demás.

Las funcionalidades en el layout presentado, se ubican a la izquierda, se asignan a los desarrolladores, permitiendo la codificación y depuración de forma independiente.

Debe existir un controlador que interprete las acciones del usuario y pueda llamar a la clase responsable de ejecutar la acción determinada. También se encarga de la inicialización y la conexión de las partes en la secuencia correcta.

Esta arquitectura base, en la cual se hace descomposición modular facilitará en gran medida el proceso de integración posterior. Dependiendo del framework se pueden aplicar otros patrones en la construcción de la aplicación. - Configurar el ambiente de desarrollo, de forma que sea un estándar para todo el equipo de trabajo. Algunas herramientas que pueden emplearse son: aptana, notepad++ o Microsoft Visual Web Developer Express. De igual, forma es indispensable contar con un sistema de control de versiones (CVS).

- Dado que la información que se brinde a través del mapa debe estar vigente y ser de interés, se debe generar un plan para la actualización de datos, que contemple la frecuencia, la entidad responsable (empresa desarrolladora, cliente o compartida) y costos aproximados. Por ejemplo: en una aplicación de geomercado se pueden establecer convenios con proveedores especializados para adquirir el levantamiento de información de establecimientos comerciales que se realiza cada dos años.

- Y aunque este último lineamiento no pertenezca al campo técnico, vale mencionar que buena parte del éxito de un proyecto recae sobre las personas, entonces es vital que se incentive un ambiente de buenas relaciones, de cooperación en el que se estimule el trabajo en equipo.

Los siguientes lineamientos se dirigen hacia los desarrolladores:

- Suscribirse a foros y listas de correo es una buena opción tanto para buscar ayuda como para colaborar con otros programadores, tal es el caso de lists.osgeo.org.

- Iniciar buscando los ejemplos con funcionalidad similar a la deseada, si no se encuentra, pasar al trac y/o a la lista de correo y una vez que se tenga una idea de la línea a tomar apoyarse en la documentación del API.

- Es fundamental que para las tareas de depuración cuente con una herramienta, dado que son aplicaciones del lado cliente, el navegador sobre el que está probando debe incluirla. Por ejemplo: Firebug para Firefox, Dragonfly para Opera, el inspector de Google Chrome. Es útil tanto para ubicar errores como para hacer pruebas de rendimiento, al medir cuánto tiempo se demora una función (o trozo de código).

- Hacer de las buenas prácticas una rutina diaria, de manera que se interioricen y se conviertan en hábitos, por ejemplo: evitar variables globales y anidamientos excesivos; optimizar bucles; asignar nombres - ojalá cortos- a las variables y funciones que se auto expliquen; los comentarios deben ser los necesarios; utilizar un analizador de código para comprobar la calidad sintáctica, esto permite identificar problemas potenciales (i.e. faltas de punto y coma, variables globales, defectos en el HTML), ahorrando tiempo en el proceso de depuración y mejorando la integración con los productos de otros desarrolladores (entre las herramientas disponibles está JSLint).

- La minimización y obfuscation de código son alternativas que se deben tener presentes para optimizar tiempos de carga.

Documento similar