Cómo contratar un geoportal SIG: requisitos y criterios de aceptación
Una guía para convertir la compra de un visor geográfico en requisitos verificables de datos, tareas, interoperabilidad, accesibilidad y operación.
Un geoportal no se debería contratar como una colección de pantallas o un mapa con capas encendidas. Se debería contratar como la capacidad de que una persona identificada complete una decisión o trámite con datos trazables, en un tiempo y bajo condiciones de operación acordadas.
Esa diferencia cambia el pliego. Una demostración puede verse bien con datos de muestra y aun así fallar al actualizar una capa, restringir información sensible, explicar una fuente o soportar una consulta recurrente. Antes de escoger una plataforma, defina qué debe quedar probado al cierre del proyecto.
La consultoría de geoportales y visores SIG de GeoSAT puede estructurar ese alcance. Para decidir la arquitectura por capas, lea también WebGIS sostenible.
Empiece por la decisión, no por la marca
Pida a las áreas usuarias que describan tareas completas. Por ejemplo: localizar un predio, revisar una restricción, descargar el dato permitido, reportar una inconsistencia o publicar una versión aprobada. Para cada tarea, registre:
- Quién la realiza y con qué nivel de acceso.
- Qué datos, fecha de corte y fuente necesita.
- Qué resultado permite tomar una decisión o continuar un proceso.
- Qué ocurre si el dato no está disponible, está vencido o tiene una observación.
- Qué evidencia debe conservarse.
Después se puede decidir si el portal consume ArcGIS, QGIS Server, GeoServer, PostGIS, servicios OGC o una combinación. Invertir ese orden suele convertir una preferencia tecnológica en un requisito que nadie puede comprobar.
Convierta el alcance en pruebas de aceptación
Cada requisito debería responder tres preguntas: qué se probará, con qué datos y qué evidencia demuestra el resultado. Esta matriz sirve como punto de partida:
| Área | Criterio verificable | Evidencia de aceptación |
|---|---|---|
| Datos | Una persona autorizada encuentra la capa por título, tema o territorio y ve fuente, responsable y corte. | Prueba registrada sobre un conjunto acordado y enlaces a metadatos. |
| Consulta | Un usuario completa una búsqueda, identifica la entidad correcta y entiende las unidades y límites del resultado. | Guion de prueba, capturas o video y resultados esperados. |
| Publicación | Una actualización aprobada llega al entorno público sin copiar manualmente datos ni ocultar la versión anterior. | Flujo ejecutado, registro de versión y plan de reversión. |
| Integración | Los sistemas consumidores usan un contrato documentado, con identificadores, filtros, límites y manejo de errores conocidos. | Inventario de consumidores y prueba contra el servicio publicado. |
| Seguridad | Los perfiles ven únicamente las capas y operaciones autorizadas; el acceso queda auditado cuando corresponde. | Matriz de roles y evidencia de pruebas positivas y negativas. |
| Accesibilidad | Las tareas prioritarias funcionan con teclado, foco visible, mensajes comprensibles y tamaños de pantalla acordados. | Revisión manual sobre los flujos críticos; no solo una declaración de conformidad. |
| Operación | Hay responsables, monitoreo, copia, prueba de recuperación y procedimiento ante una fuente caída. | Bitácora de una recuperación o simulación acordada. |
No existe un tiempo de respuesta universal que sirva para todos los portales. El contrato debe fijar métricas para las consultas, volúmenes y condiciones reales del proyecto, incluidos los servicios externos de los que dependa.
Separe descubrimiento, implementación y operación
Un único entregable llamado “geoportal terminado” suele ocultar decisiones que deben validarse antes. Una contratación más controlable separa al menos tres momentos:
- Descubrimiento y prototipo. Inventario de fuentes, roles, riesgos, tareas y un flujo representativo con datos reales o una muestra autorizada.
- Implementación y migración. Modelo de publicación, interfaz, integraciones, metadatos, permisos, pruebas y transferencia de conocimiento.
- Operación y evolución. Correcciones, parches, observabilidad, copias, soporte, cambios de contenido y revisión periódica de dependencias.
El prototipo no reemplaza la aceptación final. Sirve para descubrir si el flujo, el volumen de datos, las reglas de acceso y las dependencias caben en la solución propuesta antes de comprometer el alcance completo.
Exija portabilidad donde importa
Un portal puede usar componentes comerciales, abiertos o propios. La pregunta útil es si la entidad puede conservar y reutilizar sus activos si cambia un componente o proveedor. Incluya como entregables:
- Modelo de datos, diccionario, catálogos de dominios y metadatos.
- Repositorios, dependencias, instrucciones de despliegue y licencias aplicables.
- Inventario de servicios, rutas, esquemas, consumidores y responsables.
- Exportación documentada de datos, adjuntos, estilos y configuraciones que pertenezcan a la entidad.
- Plan de transición y recuperación probado sobre un flujo crítico.
Portabilidad no significa que toda sustitución sea inmediata o sin costo. Significa que las restricciones, los trabajos pendientes y los activos disponibles están documentados antes de una renovación o una salida.
Incluya accesibilidad y seguridad desde la maqueta
La accesibilidad no se resuelve al final con un auditor automático. Si el mapa, el panel de resultados o el formulario crítico no se puede recorrer con teclado o no comunica estados, la persona usuaria pierde una tarea esencial. Las WCAG 2.2 describen criterios comprobables y recomiendan evaluar páginas completas, incluidas sus variantes responsivas.
De la misma forma, “tiene usuarios y contraseña” no describe una política de acceso. Defina las categorías de información, perfiles, acciones permitidas, trazas requeridas, responsables y cómo se revoca el acceso. Una capa pública, una capa interna y una capa con información personal no deberían heredar la misma regla por comodidad.
Haga una aceptación que resista el día siguiente
La prueba final debe usar una fecha de corte, un entorno y un conjunto de casos acordados. Ejecute las tareas críticas con usuarios que las conocen, pruebe perfiles sin permiso, simule al menos una fuente no disponible y confirme que las ayudas, la fuente y los límites siguen visibles.
Conserve el resultado: versión desplegada, datos usados, incidencias, responsables, decisiones de aceptación y asuntos pendientes. Así el portal deja de ser una entrega visual y se convierte en una capacidad operable.
Si necesita preparar un alcance antes de publicar un proceso o renovar una plataforma, GeoSAT puede elaborar el inventario de flujos, arquitectura y matriz de aceptación. Compare primero el alcance con cuánto cuesta un geoportal: el costo depende de la responsabilidad operativa que se contrata, no solo de la primera interfaz.