ARQUITECTURA DE APLICACIÓN, DE DATOS Y DE TECNOLOGÍAS DE INFORMACIÓN DE LA PLATAFORMA

NECESIDADES INSTITUCIONALES ESPECIFICACIONES FUNCIONALES

Arquitectura de aplicaciones

La plataforma puede ejecutase sobre los siguientes middleware (Capa aplicacional):

 IIS

 Oracle Web Logic

 IBM WebSphere

 Jboss

 Tomcat

 Apache

 Motor PHP

La plataforma debe ejecutarse de forma centralizada en una sola instalación para todas las IEs y no una instancia por cada IE.

Referente a la arquitectura de aplicación, de datos y de tecnologías de información de la plataforma se hace referencia al requerimiento para la plataforma de Software que será implementado sobre el servicio de nube provista por CNT EP y por esta razón no se mencionan caracterizas físicas y técnicas de hardware.

Arquitectura de datos

 Almacenamiento sobre un motor de base de datos con características de:

 Alta disponibilidad;

 Alto rendimiento;

 Debe llegar a soportar alta transaccionalidad de al menos 200.000 peticiones concurrentes;

71

 Debe proveer balanceo de carga e integración a la capa de aplicaciones.

 Soportar encripción de columnas y/o atributos críticos;

 Capacidad de terminar y recuperar en cualquier momento sin implicaciones de transacciones incompletas (Rollbacks, Integridad transaccional) en todas sus transacciones que modifiquen datos;

 Integrarse a una tecnología de almacenamiento de datos (SAN).

 Contar con APIs SQL para llamado a los datos en cumplimiento de las mejores prácticas;

 Conexión a la base de datos de manera agnóstica;

 La plataforma debe tener un solo modelo de datos y una sola instancia para toda la información de la institución educativa (o de múltiples instituciones).

Reportería ad-hoc de información transaccional e histórica

La plataforma debe contar con herramientas propias de reportería que permitan la generación de reportes en diferentes formatos.

Disponibilidad de 99,95% del servicio de la plataforma.

La plataforma debe estar configurada en alta disponibilidad configuración para:

Alto desempeño Alta disponibilidad

Alta capacidad de respuesta de la plataforma

 La plataforma deberá garantizar el consumo del ancho de banda consumido por cada usuario que acceda a la plataforma a través de internet.

 El ancho de banda consumido por cada sesión abierta debe ser de máximo 10 Kbps.

 El tiempo de respuesta de una transacción estándar, no ejecute procesos batch en ambiente de producción debe ser de al menos 3 segundos.

 El tiempo de acceso a la plataforma debe ser de al menos 5 segundos. En caso de ser superior el fabricante presentará el plan para su mejora y optimización.

Administrar la publicación de contenido de acuerdo a los perfiles permitidos

 Configurar perfiles y accesos para publicación de contenido en la plataforma.

 Soportar protocolos de comunicación para envío de correo y notificaciones SMS personalizable, individual y masivo a los usuarios de la plataforma de manera masiva.

 La plataforma deberá presentar las funcionalidades de controles de formato y extensiones de archivos adjuntos que se incorporen a los procesos establecidos.

Acceso independiente del navegador de internet.

Acceso a la plataforma si necesidad de usar habilitador web Puede ejecutarse sobre los siguientes navegadores en versiones actualizadas :

- Internet Explorer - Firefox

- Chrome - Opera El acceso a las diferentes funcionalidades

debe estar basado en el perfil de usuario

La plataforma debe permitir que las pantallas de cada usuario sean basadas en perfiles.

Disponibilizar reportes comunes para usuarios y grupos de usuarios

Capacidad de diseñar reportes estandarizados para toda la aplicación y disponibilizarlos para usuarios o grupos de usuarios.

72 La plataforma debe permitir el uso de

herramientas analíticas

Proveer un punto de acceso único para las herramientas analíticas (Gráficos, Reportes, herramientas de exploración de datos, etc.)

Manejo de errores y excepciones de la plataforma

Manejo estructurado de errores y mensajes entendibles en español

Punto único de acceso para toda la

plataforma y sus diferentes módulos Portal único de acceso a toda la plataforma y sus servicios

Arquitectura de alta disponibilidad

La tecnología de la plataforma debe ser montada en clusters de servidores con "Bulit-in load balancing" dentro de la arquitectura planteada

Soporta una configuración de base de datos de alta disponibilidad.

Configurar la capacidad de redireccionar, ante fallas, a los usuarios a otros servidores.

Proveer capacidades de carga balanceada en la capa de aplicación (con detección de fallos).

Realizar procesamiento paralelo para cada uno de las capas de la arquitectura planteada.

Configurar en cluster diferentes servidores sin necesidad de instalar otros componentes de hardware.

Proveer facilidades de recuperación automática que no requieren la participación de los administradores.

Tener procedimientos de "restart", recuperación ante fallas y backups.

Realizar migraciones y actualizaciones de los diferentes componentes mientras se encuentre funcionando, previo ventana de mantenimiento.

Proveer capacidades de escalabilidad sobre la infraestructura propuesta para los servidores de aplicación (Por ejemplo, crecer Número de procesadores o los recursos de memoria), adaptarse sin perder la calidad del servicio.

Proveer diferentes opciones de escalamiento para cada una de las capas de la arquitectura (Aplicaciones, Base de datos, etc.)

Permitir un escalamiento planeado (planeación de la capacidad) para soportar el crecimiento del Ministerio. La plataforma debe integrarse a un directorio de usuarios central basado en estándares de Internet (LDAP). Debe integrarse al directorio activo del MINEDUC

La plataforma debe tener niveles de seguridad dentro de la aplicación parametrizables por usuario y por roles.

73 transmisión de contraseñas con conexiones SSL y HTTPS La plataforma debe permitir definir qué datos se deberían encriptar a través de la parametrización de parámetros. Debe permitir tener accesos CORBA.

La plataforma debe tener un punto de acceso único a toda la arquitectura enrutando a otros sistemas o hubs según las prestaciones sean requeridas.

La plataforma para el acceso a la arquitectura debe usar agentes remotos para el acceso a los motores de bases de datos.

La plataforma debe soportar el concepto de Single Sign On. La plataforma debe tener la capacidad de integrarse con un IDM (Identity Management).

La plataforma debe permitir que los usuarios no vean campos bloqueados a través de funcionalidades de parametrización a través de una consola administrativa. La plataforma no debe permitir que los usuarios que no tienen acceso a ciertas roles del sistema, no puedan acceder, observar, manipular esos roles (menús, opciones, programas, módulos, transacciones, reportes, etc.)

La plataforma debe permitir manejar el concepto de firmas digitales.

La plataforma debe presentar en la arquitectura de datos que sus modelos presenten tablas normalizadas en nivel 3. La plataforma debe tener integridad y transaccional absoluta.

La plataforma debe proveer APIs para la integración con otras aplicaciones de manera nativa.

La plataforma debe proveer capacidades de workflow que integren procesos y actores (ejecutores de los procesos, Humanos, maquinas, etc.) de fácil funcionalidad.

La plataforma debearticular datos y funcionalidades desde Web Services expuestos por otras aplicaciones que se integren.

La plataforma debe soportar estándares web services (SOAP, WDSL, etc.)

La plataforma debe usar mecanismos de Integración al menos: COM, CORBA, SAP IDOC, SAP BAPI, Oracle OI. La plataforma debe exponer funcionalidad a través de web services.

La plataforma debe tener el estándar EDI para integración con otras aplicaciones.

74 La plataforma debe tener el estándar XML para integración con otras aplicaciones

La plataforma debe incluir herramientas middleware.