ESPECIFICACIONES TÉCNICAS

Requerimientos Técnicos
Para garantizar el éxito del proyecto, el proveedor debe demostrar que cuenta con los requerimientos técnicos y experiencia necesarios
para llevar a cabo la construcción del Portal Público de la CCB. Por lo que la propuesta debe detallar aspectos como los siguientes.

A nivel de desarrollo:
● Experiencia previa en proyectos bajo metodologías ágiles, específicamente Scrum.
● Experiencia previa en construcción de sitios web responsive.
● Experiencia previa en el desarrollo de software con frameworks basados en JavaScript, Angular, React, Next.js, etc.
● Experiencia previa en el desarrollo con una plataforma CMS, específicamente con el CMS Headless Contentful.
● Experiencia previa en el desarrollo de APIs REST, específicamente con Node.js y siguiendo las mejores prácticas para el diseño de
APIs, testing y desarrollo seguro con OWASP (Open Web Application Security Project).
ESPECIFICACIONES TÉCNICA
2.3.1 Requerimientos Funcionales

Los requerimientos funcionales que guían la visión del rediseño incluyen:

➔ Gestión de Contenido:

Necesidad:

La Cámara de Comercio de Bogotá publica información sobre sus servicios y trámites a través del Portal Público, pero adicional y muy
importante, el portal es una gran biblioteca de documentación de interés para los empresarios en distintas áreas. Por lo que la gestión
de contenido del sitio web se vuelve crucial para su posicionamiento, implicando las siguientes necesidades puntuales:
● Gestión de un alto volumen de contenido.
● Páginas de contenido que incluyen distintos tipos de elementos como formularios, tablas de datos, gráficos, audio, video, mapas,
pdfs, etc.
● Páginas de contenido de estructura y navegación compleja, y densas en cantidad de información.
● Procesos de revisión y aprobación de contenido a publicar.
● Mecanismos ágiles de actualización y liberación de cambios de contenido al sitio web en producción.
● Mecanismos de detección de broken links y baja de contenido desactualizado.
ESPECIFICACIONES TÉCNICAS
Estrategia:
● Una arquitectura desacoplada que permita aislar el contenido de la presentación por agilidad, y para que puedan evolucionar de
manera independiente.
● Una plataforma de contenido flexible que permita definir estructuras de contenido, con campos de información de distintos tipos
que puedan ser consumidos del lado del sitio web.
● Una plataforma de contenido con procesos rápidos de edición, aprobación y publicación, que pueda lanzar actualizaciones directas
del software en producción con mecanismos automatizados.
● Una infraestructura del lado del sitio web que soporte procesos de construcción y despliegue automatizados (CI/CD), con sus
procesos de aprobación, seguridad, monitoreo y auditoría pertinentes.
➔ Búsqueda Avanzada y Personalización:

Necesidad:
Es necesario optimizar la experiencia que hoy tienen los usuarios del Portal Público para encontrar rápidamente la
información de su interés “Right Content for the Right People at the Right Time”, por lo que el portal debe proveer
un mecanismo de búsqueda avanzada que permita:
ESPECIFICACIONES TÉCNICAS

● Búsquedas por palabras claves sobre el total del contenido publicado en www.ccb.org.co.
● Las palabras clave deben cubrir el contenido, pero también las categorías y niveles de navegación de la información.
● Las búsqueda debe considerar diferentes tipos de filtros, incluyendo categorías puntuales.
● Los criterios de priorización y ordenamiento de resultados en las búsquedas deben ser configurables.
● Los usuarios deben tener la posibilidad de marcar como favoritos elementos de la lista de resultados de las búsquedas y páginas
de contenido mientras están navegando, para que sean priorizados en búsquedas subsecuentes.
● Cuando los usuarios hayan respondido las preguntas de perfilamiento, su perfil debe ser considerado en los resultados de las
búsquedas, personalización en las búsquedas.
● Las búsquedas deben estar optimizadas y deben lograr tiempos de respuesta bajos que no impacten la experiencia del usuario.

Estrategia:
● Diseño de entidades de contenido pensando en los campos que van a ser indexados para las búsquedas.
● Una plataforma de búsqueda flexible que permita configurar los diferentes criterios y parámetros considerados en el
proceso de ranking de resultados y ordenamiento.
● Una plataforma de búsqueda que se integre con la plataforma de contenido y permite indexar contenido
automáticamente al ser publicado.
ESPECIFICACIONES TÉCNICAS
● Una plataforma de búsqueda que soporte personalización permitiendo hacer re-ranking dinámico a partir de un evento disparado
por el usuario (selección de un favorito o perfilamiento).
● Una plataforma de búsqueda SaaS, de alta disponibilidad y alto performance que garantice la ejecución de búsquedas optimizadas
con bajos tiempos de respuesta.
● Una plataforma de búsqueda que genere métricas que agreguen valor al negocio, identificando tópicos tendencia en las
búsquedas, volumen de búsquedas, contenido favorito y palabras clave que no están generando resultados, entre otros.
➔ Personalización de Contenido:

Necesidad:
La comunidad de usuarios del Portal Público incluye una amplia diversidad de empresarios enmarcados en diferentes industrias,
sectores económicos, tamaños de empresa, y que se encuentran en diferentes estadios en su proceso de emprendimiento y
fortalecimiento con CCB, entre otros aspectos. Estos aspectos marcan tanto su contenido de interés, como la elección de los servicios a
los que acceden dentro de la Cámara, por lo que es necesario implementar mecanismos que permitan presentar contenido
personalizado mientras los usuarios navegan por el sitio, teniendo en cuenta las siguientes premisas:
ESPECIFICACIONES TÉCNICAS

● Las métricas (Analytics) capturadas del sitio web son uno de los principales insumos para identificar tendencias y patrones en el
comportamiento de los usuarios navegando por el sitio web.
● El equipo de Marketing de CBB a través del DMP (Data Management Platform) realiza un análisis para obtener insights de las métricas
recolectadas y segmentar los usuarios de acuerdo a su comportamiento, en categorías que tienen sentido para el negocio.
La segmentación de audiencias dará la pauta para definir la relevancia del contenido que verá cada usuario dentro del sitio, creando una
experiencia personalizada que evoluciona a medida que el usuario presenta un nivel de engagement más alto con el Portal Público.

Estrategia:
● Garantizar la calidad de las métricas reportadas desde el sitio web a través de Google Analytics y Google Tag Manager.
● Identificar bloques de contenido personalizable en la estrategia de contenido, que puedan ser configurados en la plataforma de
contenido CMS.
● Implementar una integración desde el sitio web hacia el DMP, a través de API Rest, para obtener información de segmentación de los
usuarios y presentar el contenido segmentado en el CMS, que corresponda.
ESPECIFICACIONES TÉCNICAS
➔ Dashboard de Zona Privada:

Necesidad:

CCB se encuentra adelantando un proyecto llamado MAUC (Modelo de Autenticación Única de Cliente) para centralizar los servicios de
autenticación y administración de cuentas de usuario, de tal manera que todas las aplicaciones internas de CCB progresivamente vayan
usando MAUC para autenticar e identificar a sus usuarios, y para permitirles acceso a los servicios transaccionales autenticados. MAUC
provee interfaces gráficas y una vez el usuario es autenticado, deja los datos de autenticación en una Cookie que las demás
aplicaciones pueden leer.

El Portal Público, por ser el punto principal de entrada a los servicios CCB, debe incluir los links de acceso a login/logout y servicios de
administración de cuenta, así como un Dashboard que será el mapa de navegación de acceso a los servicios autenticados resueltos en
las diferentes aplicaciones internas de CCB. Este Dashboard debe incluir información relevante de la historia del usuario en CCB, así
como CTAs de acceso a los servicios principales en las diferentes aplicaciones, que por redirección desde el Dashboard le permitirán
navegar directamente a los servicios de su interés.
ESPECIFICACIONES TÉCNICAS
Estrategia:
● Los servicios de login/logout y administración de cuenta de usuario serán accesibles desde el Portal Público, desde el componente
de navegación en el header, y harán redirecciones web a las pantallas de MAUC para completar los flujos de autenticación y
administración de cuenta.
● Una vez el usuario haya sido autenticado correctamente, se redirigirá al Dashboard de Zona Privada. La Cookie de autenticación
dispuesta por MAUC permitirá identificar datos básicos del usuario autenticado.
● El Dashboard de Zona Privada será diseñado para que sea el mapa de navegación principal de un usuario que ya tiene una historia
en CCB, proporcionando una vista integrada y ordenada de los principales servicios a los que puede acceder.
● La construcción del Dashboard implica la integración con las aplicaciones principales de CCB, no definidas aún, pero dando especial
importancia a:
○ CRM: Por mantener una vista 360 del cliente, es la fuente de datos principal de los datos de los usuarios, su afiliación
empresarial e historial de acceso a los servicios CCB. Del CRM se consultará información del usuario que será presentada en el
Dashboard de Zona Privada.
○ SIREP: Historial de los usuarios a los servicios registrales. De esta aplicación se consultará la interacción previa del usuario con
los servicios registrales.
○ Avanza: Plataforma que marca la ruta de emprendimiento y fortalecimiento de los empresarios. De esta plataforma se
consultará la relación previa del usuario con CCB en su ruta de emprendimiento y fortalecimiento.
ESPECIFICACIONES TÉCNICAS
➔ Generador de Formularios Dinámicos:

Necesidad:

Los diferentes servicios ofrecidos por CCB requieren capturar información de los usuarios para diversos fines como “contáctenos”,
registros y suscripción a eventos y conferencias, gestión de procesos internos, etc. Para algunos de estos formularios, la información
debe viajar a diferentes sistemas empresariales internos especializados de CCB que van a darle solución o seguimiento al caso
particular. Formularios de Marketing que no son tramitados a través de sistemas empresariales internos, seguirán siendo embebidos
en el sitio web directamente.

Los editores de contenido deben disponer de un lugar centralizado para el diseño de los diferentes formularios, sus campos de datos y
la elección del sistema al que deben viajar. Y que estos sean fácilmente integrados a las diferentes páginas de contenido del portal.

Estrategia:
● Apalancarse en la plataforma de contenidos para el diseño y creación de formularios dinámicos y su configuración de campos,
validaciones, así como el sistema de destino al que viajan sus datos.
● Implementación de integraciones desde el backend a los diferentes sistemas que reciben información desde
formularios en el Portal Público.
● Las integraciones actuales para formularios dinámicos que deben ser migradas, incluyen:
ESPECIFICACIONES TÉCNICAS
○ CRM Microsoft Dynamics 365: A nivel de ibexa (EZ Publish), plataforma de contenido actual, está implementado el “Módulo
de Procesos”, para la creación y administración de formularios que envían datos al CRM.
○ ARTBO Feria: A nivel de ibexa (EZ Publish), plataforma de contenido actual, se realiza el envío de datos capturados en
formularios generados por el aplicativo ARTBO Feria.
○ OnBase: A nivel de ibexa (EZ Publish), plataforma de contenido actual, se realiza el envío de datos capturados en formularios
hacia el gestor documental OnBase para recursos administrativos, certificado personas privadas de la libertad y derechos de
petición.

➔ Accesibilidad:

Necesidad:
Los empresarios que acceden a los servicios de la Cámara de Comercio de Bogotá pertenecen a poblaciones diversas, por lo que el sitio
web se enfrenta a esta diversidad en diferentes niveles como cultura, industria, edad, nivel de educación, acceso a las tecnologías, así
como también a diferentes limitaciones o dificultades.
Para que el Portal Público sea un “sitio para todos”, el sitio web debe cumplir con altos niveles de accesibilidad y
promover el uso de herramientas que mejoren la experiencia de los usuarios con algún tipo de dificultad.
ESPECIFICACIONES TÉCNICAS
Estrategia:
● Velar por que el markup HTML producido a nivel de desarrollo cumple con todos los estándares para hacer el sitio web accesible, y
permitir la correcta lectura del contenido por los “screen readers” y la correcta navegación de los elementos de la página a través
del teclado.
● Velar por que la implementación a nivel UI garantice los niveles de contraste de color y tamaño de fuentes adecuados, e
idealmente se incluya captions para audio y video, y/o audio description.
● Garantizar que el sitio web sea al menos AA en la calificación WCAG (Web Content Accessibility Guidelines) en Accesibilidad, y
realizar continuo monitoreo de la calificación.
● Desarrollo a la medida de un plugin web que permita la configuración en vivo de diferentes opciones que aumenten la
accesibilidad bajo ciertas circunstancias (cambio de tamaño de fuentes, contraste, guía de lectura, dislexia friendly, etc).
ESPECIFICACIONES TÉCNICAS
Requerimientos No Funcionales

Los requerimientos no funcionales guían la Arquitectura para garantizar su usabilidad y efectividad.

● Seguridad: Todos los mecanismos que garanticen la seguridad de la plataforma end-to-end, incluyendo todos sus componentes y
capas, así como plataformas externas usadas (SaaS/PaaS), plataforma cloud interna, encriptación de data sensible en transmisión y
almacenamiento, certificados SSL, VPCs, subredes privadas y VPNs dado el caso , externalización de propiedades de aplicación y
encriptación de propiedades con data privada y sensible.
● Confiabilidad: Todos los mecanismos que garanticen la disponibilidad de la aplicación y su correcto funcionamiento en su tiempo
al aire, teniendo en cuenta picos de tráfico, estos mecanismos son auto-escalamiento, monitoreo continuo, alertas y reacción ante
fallos, y mecanismos de recuperación de desastres, entre otros.
● Performance: Todos los mecanismos que garanticen tiempos de respuesta adecuados que no afecten la experiencia de usuario en el
sitio web. Las pruebas de carga y stress ayudan a determinar los tiempos de respuesta de la aplicación con cierta configuración de
infraestructura provisionada, lo que permitirá tomar acción realizando optimizaciones sobre el código de la aplicación, verificar los
mecanismos de auto-escalamiento y proyectar el tamaño de la infraestructura en picos de alto tráfico, asegurando que no se degrade
el desempeño de la aplicación en estos escenarios.
ESPECIFICACIONES TÉCNICAS
● Mantenibilidad: Todos los mecanismos y mejores prácticas desde el diseño que permiten hacer más fácil introducir cambios o
nuevas funcionalidades sobre la aplicación en operación, sin que ello implique gran complejidad o largos tiempos. Una
Arquitectura desacoplada promueve la reutilización y mantenibilidad, así como la automatización de pruebas y las prácticas de
CI/CD que garantizan el despliegue y liberación de código de manera automatizada y continua a los diferentes ambientes.
● Escalabilidad: Todos los mecanismos para garantizar la continuidad del negocio antes picos de alto tráfico sin evidencia de una
degradación en el desempeño de la aplicación. Plataformas nube con mecanismos de auto-escalamiento permite el
crecimiento/decrecimiento automático de la infraestructura en respuesta al tráfico, y con las pruebas de performance se garantiza
el correcto funcionamiento de este mecanismo, y la no-degradación del desempeño bajo estas circunstancias.
● Usabilidad: Todos los mecanismos que garanticen que el sitio web sea fácilmente usable, permitiendo a los usuarios una
interacción sencilla, intuitiva, agradable y segura. Varios factores influyen en la Usabilidad y deben ser optimizados continuamente,
factores como la estructura y relevancia del contenido, diseño gráfico adecuado, sencillo y consistente en diferentes dispositivos,
accesibilidad, facilidad de navegación, facilidad en la interacción con acciones que el usuario identifique de manera intuitiva, y
desempeño del sitio web con tiempos de respuesta adecuados. Las Pruebas de Usabilidad permitirán medir qué tan usable es la
plataforma y realizar cambios de manera continua en vía de su optimización, y las pruebas de performance permitirán mejorar los
tiempos de respuesta.
ESPECIFICACIONES TÉCNICAS
● Extensibilidad: Todos los mecanismos para garantizar que la aplicación es altamente extensible y mantenible, que se pueda
adaptar fácilmente en el futuro a iniciativas nivel macro como una arquitectura de microservicios en el backend y micro-frontends
en el front-end, para construir aplicaciones web más granulares que permitan crecer en módulos, páginas y contenido más
fácilmente.
● Trazabilidad: Todos los mecanismos que garanticen trazabilidad al interior de cada uno de los componentes de la arquitectura.
Desde la capa de front-end con Google Analytics y Google Tag Manager, a nivel de back-end con logs de aplicación, desde las
aplicaciones third-party SAAS con sus herramientas propias, y a nivel de infraestructura con Dashboards que permitan tener una
visión de la salud del sistema, uso de recursos, log de actividades, etc.
● Monitoreo: Todos los mecanismos que garanticen el monitoreo continuo de la aplicación, y proporcionen el nivel de visibilidad
requerido para detectar fallos, actuar y recuperarse rápidamente.
● Recuperación: Todos los mecanismos a nivel de infraestructura y aplicación que permitan recuperarse ante fallos rápidamente
para poder reducir el RTO (Recovery Time Objective). El monitoreo continuo es un factor clave para reducir el RTO, así como
mecanismos de replicación de la infraestructura en diferentes zonas de disponibilidad, definición y aplicación de políticas
adecuadas de backups y prácticas de CI/CD e IaaC para poder reaccionar rápidamente ante un incidente.
ESPECIFICACIONES TÉCNICAS
Backlog de alto nivel
El Backlog de alto nivel incluye las siguientes Épicas:
1. UI Foundations: Implementación de componentes UI de estructura, incluyendo header y footer, y componentes internos links (con
texto e imagen), CTAs, social media links, SEO meta-tags, navegación de primer y segundo nivel, FAQs, aceptación de cookies,
manejo de errores, etc.
2. Homepage y Buscador: Incluye los siguientes temas:
a. Homepage, gurú del home, dock flotante (bot, contáctenos, línea de atención, agendamiento, asesoría).
b. Buscador avanzado: Indexación automática de contenido, implementación del buscador avanzado, configuración Algolia y
Personalización.
c. Dashboard CCB, secciones, contenido relacionado, FAQs.
3. Empresarial: Dashboard Empresarial, cree su empresa, apoyo y sostenibilidad, círculo de afiliados, sector empresarial y trámites.
4. Trámites y Servicios: Dashboard, servicios registrales, servicios generales.
5. Formación: Dashboard, buscador de cursos y eventos, integración con Avanza y redirección a la plataforma de pagos.
6. Contenido de Interés: Noticias, blogs, información especializada, transforma Bogotá, biblioteca.
7. Observatorio: Publicación de estudios de seguimiento y análisis sobre el comportamiento económico y social de Bogotá y
Cundinamarca. Incluye datos, gráficos embebidos, tablas, etc.
8. Formularios Dinámicos: Módulo de formularios dinámicos en el CMS, implementación e integraciones con CRM, ARTBO y OnBase.
9. Zona Privada: Dashboard de zona privada como punto de redirección a los servicios autenticados, integración MAUC login/logout
en navegación, identificación de usuario autenticado a través de cookies, integraciones con CRM, SIREP y Avanza.
ESPECIFICACIONES TÉCNICAS
10 Personalización de Contenido: Configuración de sets de componentes con personalización por audiencias, e integración con DMP.
El proveedor dispondrá de los diseños expresados como Wireframes y prototipos de Alta Fidelidad en la herramienta Figma, de las
pantallas maestras diseñadas (alrededor de más de 70 páginas maestras). Aunque cabe aclarar que el desarrollo debe ser lo
suficientemente flexible para permitir la creación de nuevas páginas y nuevo contenido usando un set de componentes gráficos
disponibles a través de la plataforma de contenido.

Diseño de la solución
Arquitectura de alto nivel:
La siguiente es la visión de alto nivel de la arquitectura propuesta para soportar el nuevo Portal Público:
ESPECIFICACIONES TÉCNICAS
La plataforma de Contenido Contentful y el Search Engine Algolia son plataformas externas SaaS que deben ser integradas a la
aplicación web construida a través del llamado por API, SDK o directamente usando componentes UI disponibles desde las
herramientas.

Las plataformas Core son aplicaciones CCB internas a las que el Portal Público también debe integrarse a través de diversos
mecanismos (API Rest, SOAP, Queues, etc.). Las capas frontend (React ó Angular, Next.js) y backend (Proxy APIs, sugeridas en
Next.js/Express), así como la capa de integración con API Gateways de acceso a las capas internas, serán desplegados sobre
infraestructura propia AWS administrada y mantenida por CCB.
ESPECIFICACIONES TÉCNICAS
Front-End
● Framework basado en JavaScript como eje principal, React ó Angular.
● En caso del uso de React como framework, se recomienda el uso de Next.js como suite completa para construir una aplicación
React lista para producción, con optimizaciones y soporte de pre-rendering para mejoras en SEO y performance.
● Component driven development para el diseño y construcción de componentes UI reutilizables, opcionalmente administrados y
versionados con bit.dev (herramienta opcional). Esta estrategia permitirá mantener una experiencia consistente a través de
múltiples sites y ayudará a estar preparados para evolucionar hacia un approach basado en micro-frontends en el futuro.
● Responsive web design con las librerías CSS-in-JS más usadas.
● Implementación de integraciones a nivel web, componentes UI disponibles o SDK para la integración desde la capa web con el CMS
Headless Contentful, Search Engine Algolia y API Calls al backend a través de API Gateway, implementación de analytics con Google
Analytics y GTM, social network plugins, etc.

Integración
● API Gateway para administrar el acceso desde el front-end hacia el back-end.
● Un API Gateway específico para los API Calls hacia el back-end, CMS Headless para actualización de contenido, Search Engine en
caso de indexaciones por API, y otras integraciones que deban ser orquestadas.
● Con API Gateway los accesos del front-end hacia el back-end estarán asegurados a través de API Key, IP Restriction, o con
autorizadores custom.
ESPECIFICACIONES TÉCNICAS
Back-End
● Sistemas que requieran consumir/actualizar contenido en Contentful lo podrán hacer a través de un API Gateway asegurado para
externos, con acceso al Content Management API, además del Content Delivery API.
● Sistemas que requieran indexar contenido en el Search Engine Algolia lo podrán hacer a través de un API Gateway asegurado para
externos, con acceso al API de Indexación.
● Integraciones a través de API hacia los sistemas internos de CCB, estas integraciones estarán construidas sobre una capa Proxy API,
sugerida en Next.js/Express, que expondrá un API Rest para el front-end.
● Se recomienda Next.js para habilitar el pre-rendering de las páginas del lado del servidor para mejorar SEO y performance.
ESPECIFICACIONES TÉCNICAS
Infraestructura
La siguiente es la infraestructura propuesta en AWS para soportar la arquitectura:
ESPECIFICACIONES TÉCNICAS
● Repositorio de Componentes: Diseño de componentes JS reutilizables en un esquema de desarrollo orientado a componentes. Los
componentes pueden ser versionados con bit.dev (herramienta opcional).
● CMS Headless Contentful: Plataforma de contenido headless Contentful con acceso a través de API REST promueve el contenido
reutilizable entre múltiples canales.
● WAF (Web Application Firewall): Firewall de aplicaciones Web que permite proteger cualquier petición HTTP/HTTPS hacia
CloudFront, API Gateway o un Load Balancer, de diferentes ataques DDoS, SQL/Script Injection, XSS, TOP 10 de OWASP, etc.
● DNS y CDN: AWS Route53 es el servicio DNS web escalable y de alta disponibilidad, AWS CloudFront es el servicio CDN que
distribuye contenido en múltiples geografías, con baja latencia y alta velocidad de transferencia.
● API Gateway: Creación, publicación, mantenimiento y monitoreo de APIs que son la puerta de entrada a capas internas de la
aplicación. API Gateway controla la administración de tráfico (rate-limit), CORS, y control de autorizaciones, acceso,
versionamiento y documentación.
ESPECIFICACIONES TÉCNICAS
● VPC, Subredes Públicas y Privadas:
○ Recursos completamente aislados de Internet a través de una Nueva Privada Virtual (VPC), y publicados en diferentes zonas
de disponibilidad.
○ Subredes públicas para los recursos que requieren ser visibles desde Internet.
○ Subredes privadas para los recursos que deben estar aislados de Internet.

● Elastic Load Balancing: Distribuye tráfico de aplicaciones entrante en múltiples zonas de disponibilidad hacia diferentes destinos
como instancias EC2, contenedores en un Cluster ECS o funciones Lambda. Cuenta con alta disponibilidad y escalabilidad
automática.
● Cluster ECS:
○ Cluster de contenedores Docker que pueden ser instancias EC2, o pueden ser serverless con AWS Fargate, evitando el
mantenimiento de sistema operativo, parches y seguridad de las instancias tradicionales. La alternativa a esta opción es la
versión de Kubernetes AWS EKS.
○ Auto-escalamiento con un mínimo y máximo número de instancias para soportar picos de tráfico.
ESPECIFICACIONES TÉCNICAS
○ Los contenedores son imágenes Docker nginx y Node.js, se sugiere Next.js sirviendo API Rest al front-end para las
integraciones hacia otros sistemas (Proxy APIs), y para soportar pre-rendering de páginas generando el html del lado del
servidor con el fin de mejorar SEO y performance. Los llamados subsecuentes desde el front-end hacia el back-end suceden
como llamados API a través de peticiones AJAX pasando por el API Gateway. La generación de páginas (pre-rendering) no pasa
a través del API Gateway. Se sugiere nginx como reverse proxy y para la implementación de redirects.
● Redis Cache: Almacén de datos en memoria, es un servicio de caching externo increíblemente rápido.

2.4.3 Integraciones

Integraciones Existentes:

Las integraciones existentes en el Portal Público deben ser migradas al nuevo portal garantizando que los procesos actualmente
implementados con los proveedores correspondientes no requieren cambios adicionales, y por lo tanto no requieren adiciones a nivel
de presupuesto.

Las siguientes son las integraciones existentes en el actual Portal Público:

ESPECIFICACIONES TÉCNICAS
1. CRM Microsoft Dynamics 365: A nivel de ibexa (EZ Publish) está implementado el “Módulo de Procesos”, para la creación y
administración de formularios que notifican el cliente a través de correo electrónico, y envían los datos capturados hacia el CRM a
través de un mensaje en una cola en Amazon SQS. El CRM también permite integración por API REST con OData.

2. ARTBO Feria: A nivel de ibexa (EZ Publish) se realiza el envío de datos capturados en formularios generados por el aplicativo
ARTBO Feria, a través del consumo de un API Rest en un API Gateway en AWS que atrás invoca una función serverless Lambda.
Esta función accede a una base de datos en MongoDB donde se encuentra la información de los formularios.

3. OnBase: A nivel de ibexa (EZ Publish) se realiza el envío de datos capturados en formularios hacia el gestor documental OnBase
para recursos administrativos, certificado personas privadas de la libertad y derechos de petición. Los datos son enviados a OnBase
a través del consumo de servicios SOAP.

4. SICOMPITE: A nivel de ibexa (EZ Publish) se encuentra implementada una integración desde SICOMPITE, para la carga en el CMS de
cursos y eventos registrados en esta plataforma, a través de colas en AWS SQS. SICOMPITE se encuentra en proceso de reemplazo
por la nueva plataforma Avanza, por lo que se deberá implementar esta integración con Avanza.
ESPECIFICACIONES TÉCNICAS
Integraciones Nuevas:

Las integraciones nuevas surgen de requerimientos específicos para soportar funcionalidades que harán parte de la nueva experiencia
del Portal Público. Estas integraciones incluyen:

1. CRM Microsoft Dynamics 365:

● En el CRM Microsoft Dynamics 365 se mantiene la data 360 de clientes, incluyendo personales y de empresa básicos, si es afiliado
al Círculo de Afiliados, inscripción y asistencia a cursos y eventos, asesoría, PQRS, etc.
● Desde el Portal Público se considera integración para la consulta de datos del CRM con el fin de incluir información del cliente en el
Dashboard del Zona Privada.
● La integración se realizará a través de llamadas al API Rest.

2. SSO con MAUC:

● Plataforma SSO CCB para autenticación de usuarios cross aplicaciones, implementa las páginas web de login/logout, creación de
cuenta, recordar y actualizar contraseña. En el login inicia una sesión de usuario válida manteniendo los datos a través de una
Cookie para que las demás aplicaciones puedan identificar la autenticación.
ESPECIFICACIONES TÉCNICAS
● El Portal Público incluirá links para creación de cuenta, recordar y actualizar contraseña, login/logout. Tras el login, deberá redirigir
al Dashboard de Zona Privada que se va a construir en el Portal Público. Para el logout se deberá invocar el API Rest disponible de
MAUC.
● El Portal Público deberá manejar el tiempo de sesión de usuario con un timeout configurable, y notificaciones al usuario indicando
el tiempo de expiración de la sesión. MAUC provee endpoints REST para login obteniendo un token de autenticación JWT válido,
así como opciones para refrescar e invalidar el token.

3.SIREP Servicios Registrales:

● Plataforma misional, Sistema de Información de Registros Públicos con información de los servicios registrales a los que ha
accedido un empresario.
● El Dashboard de Zona Privada podrá incluir información de esta plataforma, si así se define, por lo que la información de usuario
deberá ser consultada de SIREP. Forma de integración por servicios SOAP.

4.Avanza Ruta del Emprendimiento:

● Nueva plataforma de gestión de la ruta de emprendimiento y fortalecimiento de los empresarios CCB, en reemplazo de
SICOMPITE.
● El Dashboard de Zona Privada podrá incluir información de esta plataforma, si así se define.
● Parte de la información de cursos y eventos es obtenido actualmente de la plataforma anterior a Avanza, SICOMPITE, por lo que es
necesario evaluar traer cursos y eventos de Avanza.
ESPECIFICACIONES TÉCNICAS
5. DMP Data Xpand:
● Para personalización de contenido en el sitio web, se debe consultar la información de segmentación de un usuario particular en el
DMP.
● Integración con el DMP a través de API REST.

2.5 Desarrollo de Software

A nivel de desarrollo el proveedor deberá encargarse de la configuración de los ambientes de desarrollo, gestión de los equipos de
desarrollo, implementación backend, frontend, DevOps, pruebas, teniendo en cuenta los siguientes aspectos.

A nivel de gestión de contenido:

● Creación de content types y content entries en Contentful para soportar los diferentes componentes gráficos incluidos en las
páginas a implementar.
● Un equipo designado por CCB realizará el alistamiento y preparación de contenido para las páginas incluidas en cada sprint de
desarrollo. El proveedor debe coordinar con el equipo de contenido las entregas, de acuerdo al Backlog, y deberá cargar el
contenido final entregado en la plataforma CMS Contentful. Una vez el portal se encuentre en operación, el equipo de CCB podrá
cargar/aprobar contenido directamente sobre la plataforma CMS, a través de los roles de Editor y Administrador disponibles.
ESPECIFICACIONES TÉCNICAS
● Creación de scripts de migración de content models y content entries para ambientes altos con contentful-cli, en caso de ser
necesario.
● Configuración de Webhooks necesarios para lanzar los pipelines CI/CD de manera automática antes publicaciones de contenido, así
como Webhooks de indexación de contenido automáticamente hacia el Search Engine Algolia, y otros Webhooks de integración
con otras herramientas, que sean requeridos.

A nivel de desarrollo:
● Análisis automático de código y vulnerabilidades a nivel de seguridad con SonarQube, en alineación con el equipo de DevOps de
CCB.
● Mejores prácticas en el desarrollo de software, uso de patrones de diseño (strategy, factory, repository, composite, MVC, etc.),
patrones de diseño cloud (backends for frontends, publisher/subscriber, etc.), mejores prácticas en la definición de APIs REST, clean
code, etc.
● Cobertura de pruebas mayor o igual al 80%.

A nivel de desarrollo front-end:

● Garantizar que los componentes gráficos UI en el framework basado en JavaScript (React o Angular) son desarrollados de manera
desacoplada, para promover su reutilización.
● Garantizar que cada página desarrollada incluya meta-tags de SEO correctamente.
ESPECIFICACIONES TÉCNICAS
● Garantizar que cada página desarrollada siga buenas prácticas de accesibilidad.
● Garantizar que todas las URLs existentes en el portal actual tienen redirecciones correspondientes en las páginas publicadas en el
nuevo portal. Por lo que es importante hacer el proceso de redirecciones para SEO, se deben hacer redirecciones 301 de las URLs
del portal antiguo a las nuevas URLs para evitar la generación de errores 404. El proveedor contará con un documento listando
todas las redirecciones que deben ser configuradas.
● Garantizar que cada página desarrollada reporte eventos de Analytics a través de GA (Google Analytics) y GTM (Google Tag
Manager) de acuerdo a las definiciones del lado de CCB. Por lo que el equipo de desarrollo deberá instalar en todas las páginas (en
el header y un noscript en el body) el script de seguimiento de GTM para obtener data básica desde el Dashboard de Google
Analytics. Igualmente, el proveedor contará con los correspondientes planes de tagging, para los casos particulares en los que se
defina hacer seguimiento específico de eventos dentro del sitio web a través del push de eventos al dataLayer, estos eventos
específicos son capturados en GTM y enviados posteriormente a Google Analytics.
● Ejecutar las tareas necesarias para asegurar el posicionamiento del portal y la no disminución del tráfico existente.

A nivel de procesos de desarrollo de software, el proveedor debe detallar en la propuesta:

● Configuración de equipos de desarrollo que ejecutará la implementación de acuerdo con la estimación de alto nivel del Backlog
proporcionado, detallando roles y responsabilidades.
● Roles requeridos del lado de la CCB para soportar el desarrollo.
ESPECIFICACIONES TÉCNICAS
● Propuesta de posibles ajustes al Plan de Implementación y Configuración de Releases proporcionado, si así lo considera.
● Herramientas de gestión de proyectos, de desarrollo y de comunicación usadas para soportar el proceso de desarrollo de software.
● Además de la propuesta para la implementación del Portal Público, se debe incluir la propuesta de continuidad operativa,
mantenimiento, soporte técnico y monitoreo, dado que la implementación, operación, monitoreo y gestión de la plataforma estará
a cargo del proveedor, de manera continua. La propuesta de soporte técnico se debe estimar para un período de 3 años, para el
soporte evolutivo a modo bolsa de horas.

2.6 Infraestructura y DevOps

El equipo de DevOps del proveedor debe construir la infraestructura como IaC (Infrastructure as Code) con CloudFormation, y debe
implementar los pipelines de CI/CD usando las herramientas de Azure DevOps.

A nivel de las herramientas de Azure DevOps, el proveedor debe contar con las licencias de Azure DevOps necesarias para suscribirse a
los repositorios privados de código de los que dispone CCB. Igualmente aplica para el acceso a Azure Pipelines para la configuración de
pipelines de construcción y despliegue de artefactos finales en Amazon Web Services. Por lo que se requiere del lado del proveedor,
por cada miembro del equipo desarrollador, una suscripción activa de Visual Studio Professional o Enterprise con MSDN.
ESPECIFICACIONES TÉCNICAS
A los pipelines configurados en Azure Pipelines se debe integrar SonarQube para el análisis de código y detección temprana de
vulnerabilidades a nivel de seguridad. En esta configuración es necesario alinearse con el equipo de DevOps de CCB que ya cuenta con
una solución de Sonar habilitada, y varios “Quality Gates” definidos.

El proveedor se encargará de implementar, operar, mantener y monitorear todos los ambientes de desarrollo, productivos y no
productivos (desarrollo, calidad, staging), en la nube de Amazon Web Services. Se solicita al proveedor garantizar que la infraestructura
y servicios usados nativos de nube están diseñados para cumplir con la siguiente disponibilidad ponderada mensual: SLA de uptime del
99,9% de la infraestructura propia del Portal Público en AWS. La CCB podrá hacer seguimiento de estos indicadores en línea basado en
la información que le proporciona el informe de gestión u otra herramienta que considere pertinente.

El proveedor debe incluir en la propuesta un costo fijo para los servicios de administración de plataforma cloud AWS y la operación,
monitoreo y gestión. Y una vez que la infraestructura empiece a ser aprovisionada, para los diferentes ambientes, debe incluir el costo
ajustado por los servicios AWS efectivamente utilizados mensualmente para la operación del portal.

La infraestructura sobre AWS aprovisionada y entregada por el proveedor, debe entenderse como un todo, por lo que el proveedor
tendrá a su cargo la administración, operación y monitoreo de todos los componentes internos de la solución, incluyendo: Recursos
Cloud en AWS para alojar la plataforma del portal, servicios de monitoreo, administración y soporte de plataforma Cloud, sistema
operativo y todos los componentes del portal, aplicaciones SaaS requeridas para el correcto funcionamiento del portal, CMS
Contentful, Search Engine Algolia como mínimo, y las demás herramientas definidas entre el proveedor y la CCB.
ESPECIFICACIONES TÉCNICAS
El proveedor deberá provisionar en una cuenta de Amazon Web Services independiente, toda la infraestructura necesaria para el
funcionamiento y disponibilidad del portal productivo y cada uno de los ambientes no productivos (desarrollo, calidad, staging). Esta
cuenta de AWS tendrá conectividad con la infraestructura actual de CCB, a través de un servicio Transit Gateway.
ESPECIFICACIONES TÉCNICAS
Para las diferentes liberaciones de código a los diferentes ambientes, el proveedor deberá alinearse con los procesos internos definidos
por el equipo de DevOps de CCB, proporcionando manuales de configuración y despliegue para cada release, y siguiendo los procesos
definidos para la configuración de pipelines y workflow de aprobaciones por diferentes roles y de acuerdo al ambiente al que se realiza
el despliegue.

El proveedor debe estar en la capacidad de realizar liberaciones de software al cierre de cada Sprint, o de acuerdo a la programación
de releases específicos acordados previamente con el equipo de DevOps de CCB y los principales Stakeholders.

El proveedor deberá tener en cuenta lo siguientes aspectos específicos respecto a la configuración, aprovisionamiento, administración
y monitoreo de la infraestructura en Amazon Web Services:
● El proveedor deberá tener presente que el valor mensual estimado del servicio corresponderá a un costo variable teniendo en
cuenta que los ambientes NO productivos podrán apagarse para optimizar los costos de facturación mensual relacionados con la
IaaS.
● Para evitar recursos innecesarios en la nube, el proveedor deberá indicar la estrategia de balanceo de carga y auto escalamiento
definidas, para que no surjan sobrecostos. Velando siempre por obtener el costo más bajo posible relacionado con la Iaas, sin
afectar los criterios de disponibilidad y rendimiento del portal.
● El proveedor deberá definir el esquema de alta disponibilidad para recuperación ante desastres con base en la activación del
servicio multizona.
ESPECIFICACIONES TÉCNICAS
● El proveedor deberá informar a CCB cualquier modificación en el portal, que represente una variación representativa en los costos
mensuales asociados a la infraestructura AWS (Iaas).
● El proveedor debe incluir la instalación, configuración, despliegue de servidores en nube y puesta en marcha de los servicios, Iaas y
SaaS que incluya en el diseño de la solución.
● Esquema de copias de seguridad. Actualmente la Cámara de Comercio de Bogotá, tiene el siguiente esquema de respaldos: Backup
full semanales, mensuales y anuales, diarios (incrementales). El proveedor deberá implementar los procesos de backup automático
en la nube, de forma que el esquema de respaldos que hoy se tiene se pueda emular.
● El proveedor deberá realizar toda configuración de redes y seguridad (VPC, Firewall, Gateway), así como toda configuración,
cambio, ajuste a los servicios / servidores desplegados (almacenamiento, cuotas de recursos, snapshots, usuarios de consola).
● El proveedor deberá configurar y supervisar el método de acceso de administración a la plataforma y a los correspondientes
servidores/Servicios.
● El proveedor deberá monitorear y configurar métricas y alertas sobre CloudWatch, que permitan visibilidad del comportamiento
de los recursos contratados.
● El proveedor deberá brindar un acceso a un reporte o dashboard, donde se puedan visualizar las métricas configuradas.
● El proveedor deberá aplicar los parches de seguridad críticos o prioritarios para todos los sistemas administrados dentro de la
arquitectura del portal, así como actualizaciones del sistema operativo, servidores de aplicación y cualquier software utilizado, si
da lugar a ello.
ESPECIFICACIONES TÉCNICAS
2.7 Seguridad
A nivel de Seguridad el proveedor debe alinearse con el equipo interno de Seguridad de CCB, seguir todos los lineamientos de
seguridad dispuestos, y evaluar durante la fase de Discovery la existencia de herramientas transversales de Seguridad dispuestas por
CCB que reemplacen/complementen componentes de seguridad en la arquitectura/infraestructura propuesta, para realizar las
modificaciones/configuraciones respectivas.

Ver “ANEXO 2 - Requerimientos de Seguridad de la Información.pdf”, para mayor detalle.

2.8 Calidad de Software

Haciendo especial énfasis en los procesos internos de calidad, el proveedor debe detallar su estrategia de calidad de software,
considerando:
● Tipos de pruebas en código realizadas como parte de cada ciclo de desarrollo de software, pruebas unitarias, de integración, E2E,
sean manuales o automatizadas. Las pruebas unitarias deben cumplir una cobertura igual o superior al 80%.
● Tener en cuenta que el proveedor deberá realizar 2 rondas de pruebas de performance, carga y stress, una primera hacia la mitad
del desarrollo, y una segunda tanda previo al primer release a producción, para el inicio de la fase de Friends & Family.
● Tener en cuenta que el proveedor deberá realizar chequeos de SEO y Accesibilidad de todas las páginas publicadas en el nuevo
Portal Público, y deberá comunicar los resultados para análisis.
ESPECIFICACIONES TÉCNICAS
● Herramientas de testing utilizadas.
● Mecanismos de comunicación continua de evidencias de las pruebas ejecutadas, reportes de las herramientas de análisis de
código y estadísticas respecto al número de defectos reportados y solucionados por Sprint.

Procesos de Certificación:

Se deberán implementar los siguientes procesos de verificación de calidad en las diversas instancias del proceso de desarrollo.

Al cierre de cada Sprint:

● Desk Check con el equipo de Diseño y Contenido para verificar que la implementación cumple con los lineamientos de diseño
gráfico UI expresados en los Wireframes y Prototipos de Alta Fidelidad, y que el contenido final se vea correctamente. Este proceso
es una reunión corta donde el Desarrollador presenta la implementación y realiza ajustes, antes de iniciar el ciclo de pruebas
interno de cada historia de usuario.
● Al finalizar el ciclo de pruebas interno de una historia de usuario, CCB realizará pruebas de aceptación de usuario UAT (User
Acceptance Testing) que incluyen la verificación y aceptación de la implementación final, con verificaciones de diseño y contenido.
Las pruebas UAT se deben realizar con contenido real productivo que debe ser alimentado en el CMS Contentful por el proveedor,
de acuerdo al contenido preparado y entregado por CCB.
● Cualquier hallazgo durante las pruebas de UAT será reportado directamente a los líderes del proyecto del lado del proveedor para
que sean gestionados de acuerdo con su criticidad.
ESPECIFICACIONES TÉCNICAS
● El PO del lado del proveedor dará cierre final a cada historia de usuario, capturando el feedback y aprobaciones resultado de las
pruebas de UAT, así como la aprobación final del Líder de Proyecto del lado de CCB.

Al cierre de cada Release:

● Previo al release, CCB realizará una verificación final de las funcionalidades incluidas en el release y dará su aprobación final para la
liberación del software en los ambientes altos (Staging / PROD).
● El proveedor deberá realizar verificación de SEO y Accesibilidad, y compartir los resultados con CCB.
● El proveedor deberá realizar pruebas de carga y estrés, y compartir los resultados con CCB.
● Previo al release masivo, y para el inicio de la fase de Friends & Family, CCB programará una prueba de PenTest Ethical Hacking, y
compartirá los resultados con el proveedor para la respectiva implementación de los ajustes requeridos.

2.9 Gestión de Contenido

La Cámara de Comercio de Bogotá se encargará del alistamiento y preparación del contenido para las páginas incluidas en cada sprint
de desarrollo, y el proveedor se encargará de la carga del contenido entregado por CCB en Contentful. Incluyendo la creación de
content types, así como de content entries con contenido final. Una vez el Portal Público se encuentre en operación, y después del
cierre de la implementación, al último release, CCB continuará las labores de actualización de contenido, con la carga, aprobación y
publicación de contenidos directamente.
ESPECIFICACIONES TÉCNICAS
Parte del contenido que la CCB preparará para cada sprint de desarrollo, incluirá el contenido para la versión en Inglés, de cada página.
Aunque no se espera tener una versión en Inglés para la totalidad de las páginas publicadas, sí es necesario que cada página soporte
habilitar una versión en Inglés, si así se requiere. Se estima que aproximadamente un 50% de las páginas publicadas en el nuevo portal
tendrán una versión en Inglés para la fase de implementación.

Se debe incluir en el alcance, la configuración total de la plataforma de contenido Contentful, incluyendo Webhooks, indexación de
contenido publicado automáticamente hacia el buscador Algolia, creación de scripts de migración de content types y content entries
para ambientes altos en caso de ser necesario, usando contentful-cli, entre otras configuraciones.

2.10 Plan de Implementación y Releases

El Plan de Implementación estima los siguientes sprints de desarrollo:

 ESPECIFICACIONES TÉCNICAS
SPRINT PROPÓSITO
● Preparar entornos en los diferentes frentes para iniciar el desarrollo.
Sprint 0 - Setup Inicial ● Configuración de ambientes DEV y QA como dependencia para iniciar desarrollo
(aunque no estén 100% automatizados).

● Implementación de elementos básicos del template de cualquier página de

contenido (header, footer, navegación), componentes básicos (content cards,
faqs) y componentes de soporte (SEO, cookies, sitemap, errores, etc).
Sprint 1 - Homepage e Integración CRM ● Implementación del Homepage.
● Configuración del API Gateway e integración con CRM para formularios
dinámicos.

● Implementación gurú del home (preguntas de perfilamiento para

personalización de contenido), y dock flotante (bot, contáctenos, línea de
atención, agendamiento, asesoría).
Sprint 2 - Gurú del Home e Integración OnBase
● Integración OnBase en backend, consumo de servicios SOAP para formularios
dinámicos.

Implementación del buscador con Algolia , páginas La CCB.

Sprint 3 - Buscador, La CCB e Integración ARTBO Integración ARTBO en backend para formularios dinámicos.
 ESPECIFICACIONES TÉCNICAS
SPRINT PROPÓSITO
● Implementación de páginas Empresarial.
● Construcción de componentes UI para formularios dinámicos.
Sprint 4 - Empresarial y Formularios Dinámicos 1 ● Máximo hacia Sprint 4 se debe tener habilitado y funcionando el ambiente de
Staging para pruebas UAT.

● Implementación páginas sección empresarial.

Sprint 5 - Trámites y Servicios, y Formularios ● Validaciones y Captcha para formularios dinámicos.
Dinámicos 2 ● Envío de datos de formularios dinámicos a los diferentes sistemas.

● Implementación de páginas de formación.

Sprint 6 - Formación ● Construcción del buscador de cursos y eventos.
Triage y solución de bugs pendientes, estabilización de ambientes altos e
infraestructura para release de MVP.
Sprint 7 - Estabilización Friends & Family Configuraciones finales del ambiente PROD para dar inicio a la fase de Friends &
Family.

Implementación de páginas de contenido de interés.

Sprint 8 - Contenido de Interés y CRM para Zona Integración con CRM para obtener información de usuario para el dashboard de
Privada zona privada.
 ESPECIFICACIONES TÉCNICAS
SPRINT PROPÓSITO
Sprint 9 - Noticias y Blogs ● Implementación de páginas de noticias y blogs y buscador.
● Triage y solución de bugs pendientes, feedback Friends & Family y preparación
Sprint 10 - Estabilización Release 2 final para release 1 a producción.
● Implementación homepage de Observatorio, página de sección, detalle de
estudio, publicaciones y encuestas.
● Buscador del Observatorio.
Sprint 11 - Observatorio y SIREP para Zona Privada
● Integración con SIREP para obtener información de usuario para el dashboard de
zona privada.

Implementación dashboard de zona privada.

Sprint 12 - Dashboard de Zona Privada Integraciones con MAUC y Avanza.

Sprint 13 - Personalización ● Implementación de personalización de secciones de contenido.

 ESPECIFICACIONES TÉCNICAS
Y los siguientes releases propuestos:
RELEASE PROPÓSITO AUDIENCIA AMBIENTES
Primer release del Portal Público Audiencia controlada Friends & DEV: Debe habilitarse durante
incluyendo homepage, gurú del home, Family. Sprint 0 como dependencia para
buscador avanzado, consulta de cursos y Pruebas de Performance y Seguridad. iniciar desarrollo (aunque no sea
eventos, y las páginas de los servicios Check de SEO y Accessibility. aún 100% automatizado).
principales como La CCB, Empresarial, QA: Debe habilitarse durante Sprint
Trámites y Servicios, y el generador de 0 como dependencia para iniciar
formularios dinámicos enviando desarrollo (aunque no sea aún
información a los diferentes sistemas. 100% automatizado).
Staging: Debe habilitarse máximo
MVP - RELEASE 1 hacia el final de Sprint 4, para
FRIENDS & FAMILY iniciar pruebas UAT (las pruebas
UAT anteriores a S4 se pueden
realizar sobre el ambiente de QA).
PROD: Debe habilitarse máximo
hacia Sprint 7 de estabilización para
el inicio de F&F.
ESPECIFICACIONES TÉCNICAS
Y los siguientes releases propuestos:
RELEASE PROPÓSITO AUDIENCIA AMBIENTES
Habilitar secciones de contenido de Release masivo. DEV/QA/Stating/PROD habilitados.
RELEASE 2 interés, información especializada, Solución de hallazgos durante Friends
clusters, biblioteca, noticias y blogs. & Family.

RELEASE 3 Observatorio Actualización de release masivo. DEV/QA/Stating/PROD habilitados.

Dashboard de zona privada y Actualización de release masivo. DEV/QA/Stating/PROD habilitados.
RELEASE 4 personalización de secciones de
contenido.

Para un timeline de liberaciones aproximado, de 27 semanas y 4 releases, como el siguiente:

ESPECIFICACIONES TÉCNICAS

2.11 Capacitación y Entrega

El proveedor deberá realizar un proceso de entrega formal de acuerdo al alcance y entregables definidos en la introducción de la sección 2
de este documento “Alcance del Proyecto y Entregables”.

El proveedor tendrá a cargo el Plan de Capacitación para garantizar la continuidad operativa del Nuevo Portal Público, y deberá diseñar un
plan de capacitación teniendo en cuenta lo siguiente:
● Capacitación a los editores de contenido en el CMS Headless Contentful, cubriendo tareas de modelamiento, edición de contenido,
flujo de aprobación y publicación, creación de nuevas páginas de contenido, personalización de contenido, creación de formularios
dinámicos, así como de los procesos de liberación de nuevos cambios.
● Capacitación y guía a los usuarios de Marketing que estarán haciendo seguimiento de las métricas del buscador interno del sitio web
en Algolia, incluyendo configuración de los parámetros de búsqueda, personalización, seguimiento de analytics, etc.
● Documentación y creación de manuales de la infraestructura aprovisionada y arquitectura como un plan de comunicación para las
áreas internas de TI de CCB, que detalle la solución construida.
ESPECIFICACIONES TÉCNICAS
2.12 Mantenimiento
El proveedor tendrá a cargo el desarrollo, pruebas, puesta en marcha, gestión, operación, mantenimiento y monitoreo de la solución
completa. Por lo que deberá incluir como parte de la propuesta la estrategia para la continuidad operativa del sitio web, incluyendo
tareas de mantenimiento, soporte técnico y monitoreo continuo y evolutivo, por un período de tres (3) años.

Para nuevos desarrollos, o actualizaciones, posterior al cierre de la implementación, el proveedor debe incluir como parte de la
propuesta el costo por hora para mantenimiento evolutivo y operativo.

3. Duración de los servicios y garantía

Es importante aclarar que, para la Cámara de Comercio de Bogotá, el servicio completo está planteado en dos lapsos de tiempo
importantes, como sigue:
● Proyecto de construcción del Nuevo Portal Público y Dashboard de Zona Privada de la Cámara de Comercio de Bogotá: Máximo 8
meses.
● Servicio de recursos Cloud (Iaas, Saas), incluyendo su administración completa, gestión y monitoreo: 12 Meses.

El proveedor posterior al proceso de construcción del Nuevo Portal Público y cada una de las integraciones, dará una garantía sobre
las actividades realizadas y el cumplimiento de los requerimientos técnicos y del producto, por seis (6) meses a partir de la salida en
producción, al último release, la cual consistirá en atender y solucionar los problemas que puedan presentarse.
ESPECIFICACIONES TÉCNICAS
El proveedor deberá presentar un informe mensual detallando el estado del proyecto/servicio, durante la implementación, y
posterior a la salida a producción, y debe incluir avance de la implementación, costos facturados por infraestructura, costos
facturados por terceros, informe de gestión de monitoreo, incidentes reportados y solucionados, u otros datos relevantes de acuerdo
a la fase del proyecto en ejecución.

3.1 Facturación
El proveedor deberá facturar mensualmente, tanto los costos propios de la operación en curso (implementación y mantenimiento),
como de los costos transferidos a la Cámara de Comercio de Bogotá por pagos a terceros (Amazon Web Services, Contentful, Algolia,
etc.).

El proveedor se encargará de realizar las respectivas suscripciones con los terceros para las integraciones third-party (Contentful y
Algolia), y con Amazon Web Services. Por lo que los costos de estos servicios deben ser pagados directamente por el proveedor, y
transferidos mensualmente a la Cámara de Comercio de Bogotá.

Para el servicio de Amazon Web Services, por funcionar bajo un esquema “pay as you go”, donde se facturan los servicios
consumidos, el proveedor mensualmente deberá transferir los costos facturados por la plataforma AWS, a la Cámara de Comercio de
Bogotá.
ESPECIFICACIONES TÉCNICAS
Para el CMS Headless Contentful, el proveedor podrá iniciar con una suscripción en el Plan Team - Medium Space, con la posibilidad
de paso requerido por volúmen de content entries y/o assets a un Plan Team - Large Space. El proveedor mensualmente deberá
transferir los costos facturados por el plan actual + costos de consumos variables, a la Cámara de Comercio de Bogotá.

Para el servicio de Algolia, por funcionar bajo un esquema “pay as you go”, donde se factura por la cantidad de API Calls al API de
Búsqueda, y por el número de registros indexados. El proveedor mensualmente deberá transferir los costos facturados por Algolia, a
la Cámara de Comercio de Bogotá. El costo real variará de acuerdo al uso de los diferentes buscadores publicados en el sitio, pero se
estima un rango de 100K - 320K requests/mes, y 100K - 320K registros indexados, que equivale a 135 - 432 USD / mes.

Para otros servicios por suscripción previamente acordados entre el proveedor y la Cámara de Comercio de Bogotá, el proveedor
deberá mensualmente transferir cualquier costo adicional facturado.

El proveedor deberá diligenciar el formato detallado en el “ANEXO 3 - PROPUESTA ECONÓMICA”, para indicar en detalle el desglose
de costos relacionados.