CONTROL DE LAS MODIFICACIONES.

...

- Adjuntar el esquema topológico de la solución especificando la distribución sugerida de módulos de software.

Cumple, se toma conocimiento.

[pic 4]

- Indicar licenciamiento y tipo requerido para soportar la aplicación. Por ejemplo, si la aplicación usa una base de datos SQL indicar si es STD o ENT.

La aplicación usa un motor de base de datos open source (PostgreSQL) pero puede utilizar MS SQL Server si TASA provee las licencias necesarias.

- Especificar los requerimientos de conectividad y seguridad para dar soporte y mantenimiento a la aplicación. Por ejemplo, nivel de privilegio de los usuarios para acceso a la base de datos.

Se debe tener la posibilidad de acceder de manera remota a las máquinas virtuales en donde se aloje la aplicación para poder dar soporte y mantenimiento a la misma. También se deberá tener privilegios de administrador de base de datos e igual acceso remoto a la maquina virtual en donde se encuentre alojada.

Cabe destacar que para poder realizar la integración con la solución de comunicaciones unificadas (Unify) la aplicación deberá tener acceso a la ip y puerto en donde se exponga el servicio de CTI.

- Especificar parámetros de crecimiento de almacenamiento. Por ejemplo, relación de GB/cantidad de transacciones según aplique.

Cumple, se toma conocimiento.

Estimamos un catálogo limitado a 2 Gb por cliente, en el caso que éste requiera mayor capacidad se podrá configurar mayor espacio en la aplicación dependiendo del storage con el que cuente Telefónica.

Se estima que cada transacción (en este caso llamada entrante) impacte en un crecimiento de 25 Kb de la base de datos.

3.2. Arquitectura de la solución

Se deberá proveer una aplicación web cliente/servidor con tecnología escalable.

Cumple, se toma conocimiento.

La aplicación utiliza tecnología Web Cliente/ Servidor y la misma es escalable

Deberá poder integrarse con:

- Integración con GIS, para búsqueda de calles y visualización de tickets en un mapa.

Cumple, se toma conocimiento.

La aplicación posee la capacidad de integración con GIS, para la búsqueda de calles y visualización de tickets en un mapa.

Existen dos maneras de integración con GIS:

1.- A través de Google Maps, para la cual se deberá contar con conexión a internet.

2.- Utilizando Open Street Maps, la misma no requiere conexión a internet.

- Integración con comunicaciones unificadas (Central Telefónica virtual) Unify

Cumple, se toma conocimiento.

La aplicación se integrará a la plataforma que TASA defina. Importante, para realizar la integración TASA deberá proveer las APIs necesarias y asegurar la disponibilidad, la maqueta de pruebas y el soporte del proveedor de la solución de comunicaciones unificadas Unify.

NOTA: Se solicita especificar además de lo expuesto anteriormente, el costo de la solución con equipo de comunicación

Detalla SOFLEX

[pic 5]

[pic 6]

3.3. Alcance General y consideraciones

Alcance

La aplicación deberá

- Registrar las consultas o reclamos de los ciudadanos recibidas telefónicamente, web, sms, redes sociales

Cumple, se toma conocimiento.

La aplicación registra la consulta o reclamos de los ciudadanos recibidas telefónicamente, web, y otros canales.

- Asignar automáticamente un número a cada reclamo (#ticket) en el sistema y contemplar tipificación del caso para asignarlo a un área del municipio (Obras, Salud, Seguridad, etc), además se registran datos del caso y del ciudadano, tipo de problema, nombre del ciudadano, número de teléfono, dirección física del problema, etc.

Cumple, se toma conocimiento.

La aplicación asigna automáticamente un número unívoco a cada reclamo (ticket generado), pudiéndose registrar la tipificación del caso, datos del caso y del ciudadano (nombre, número de teléfono, dirección) y tipo de problema.

- Mantener un registro de la fecha, hora, operador de atención de cada reclamo así como detalle de las gestiones asociadas al mismo

Cumple, se toma conocimiento.

La aplicación mantiene un registro de la fecha y hora de la creación del reclamo como así también los datos del operador que atendió dicho reclamo y toda la gestión que se realice sobre el mismo.

- Permitir configurar la tipificación de reclamos (tipo y subtipo o demás subclasificaciones de forma jerárquica), para brindar flexibilidad y adaptabilidad a cada instalación y caso particular, desde un nivel de administración disponible para el cliente (municipio o pyme).

Cumple, se toma conocimiento.

La aplicación permite la configuración de tipificaciones de reclamos de forma jerárquica de modo tal que cada cliente pueda administrar sus propias clasificaciones.

Esta acción la podrá realizar un usuario con rol de administrador dentro de la plataforma.

- Contempla la posibilidad de registrar llamados anónimos cuando el ciudadano no desea identificarse.

Cumple, se toma conocimiento.

La aplicación contempla la posibilidad de registrar llamados anónimos cuando el ciudadano o cliente no desea identificarse.

- Brindar funcionalidad para consultar historial de cada caso