-1-

“Año de la Diversidad Productiva y del Fortalecimiento de la Educación”

“Decenio de las Personas con Discapacidad en el Perú”

TERMINOS DE REFERENCIA

SERVICIO DE DESARROLLO DE UN CAMPO VIRTUAL DE FORMACIÓN CONTINUADA

I. DEPENDENCIA QUE REQUIERE EL SERVICIO

Dirección General de Derechos Fundamentales, Seguridad y Salud en el Trabajo.

II. OBJETO O FINALIDAD QUE JUSTIFICA LA CONTRATACIÓN DEL SERVICIO:

Contar con una plataforma informática moderna, ágil y multicanal considerando un portal

web (administración y visualización de contenidos), aplicaciones multimedia, aplicaciones

interactivas y servicios web, que permita el registro, acceder a participar de los cursos,

seminarios, diplomados entre otros, con la finalidad de fortalecer las capacidades de los

miembros y representantes de los sindicatos u organizaciones sindicales, trabajadores,

empleadores de las empresas del sector privado, que esté disponible para personas con

discapacidad; y proporcione información confiable, útil y oportuna sobre el progreso en la

consecución de los objetivos trazados.

III. OBJETIVOS ESPECÍFICOS:

Diseñar, configurar, personalizar e instalar un entorno virtual de aprendizaje para el

Ministerio de Trabajo y Promoción del Empleo.

a. JUSTIFICACIÓN

En el marco de lo que establece el artículo 52 del Reglamento de la Ley N° 29381, Ley de

Organización y Funciones del Ministerio de Trabajo y Promoción del Empleo, aprobado por

Decreto Supremo N° 004-2014-TR, la Dirección General de Derechos Fundamentales y

Seguridad y Salud en el Trabajo es un órgano de línea responsable de formular las políticas

públicas y funciones sustantivas orientadas a la promoción de la libertad sindical, la

erradicación del trabajo forzoso, la erradicación del trabajo infantil, la igualdad de

oportunidades y no discriminación, entre otros derechos fundamentales en el trabajo; así

como, en materia laboral para el cumplimiento de la regulación en materia de seguridad y

salud en el trabajo. Depende jerárquicamente del Viceministerio de Trabajo.

En el marco de la política del Sector, propone las normas y reglamentos, formula y de ser

el caso emite directivas, lineamientos, mecanismos y procedimientos en el ámbito

nacional, en materia de promoción, protección, respeto y cumplimiento de los Derechos

Fundamentales, así como Seguridad y Salud en el Trabajo.

En ese sentido, la Dirección General de Derechos Fundamentales y Seguridad y Salud en el

Trabajo a la fecha no cuenta con una plataforma informática que le permita gestionar las

políticas públicas, estrategias de acción, normas y reglamentos, directivas, lineamientos,

mecanismos y procedimientos en el ámbito nacional, en materia de promoción,

protección, respeto y cumplimiento de los Derechos Fundamentales Laborales así como en

la Seguridad y Salud en el Trabajo; por lo cual se hace necesario desarrollar e implementar

una plataforma informática moderna y ágil que le permita realizar el registro, accedan a

-2-

participar de los cursos, seminarios, diplomados entre otros con la finalidad de fortalecer

las capacidades de los usuarios y permita realizar el monitoreo contando con información

confiable, útil y oportuna sobre el progreso en la consecución de los objetivos trazados.

b. Público Objetivo

Los beneficiarios del desarrollo de las capacitaciones serán los miembros y representantes

de los sindicatos u organizaciones sindicales, trabajadores, empleadores de las empresas

del sector privado.

IV. FINALIDAD PÚBLICA:

El presente proceso busca abrir un nuevo canal de comunicación para impartir cursos

virtuales, ampliar la cobertura de los mismos, masificar el conocimiento, facilitar el acceso

para que los beneficiarios puedan llevar los cursos remotamente desde cualquier

ubicación geográfica, con sólo la condición de que tenga una conexión a Internet.

V. ALCANCE

Con el objetivo de garantizar la implementación exitosa de la plataforma de cursos

virtuales, en referencia, se ha estimado conveniente, desarrollar el proyecto de acuerdo a

los siguientes alcances que el proveedor deberá desarrollar:

Determinación de requerimientos técnicos de la plataforma, configuraciones,

modos de acceso, uso, políticas de seguridad, etc.

Determinación de requerimientos funcionales de la plataforma e identificación

de las funcionalidades de los módulos contemplados en el presente documento.

Elaboración del documento de análisis y diseño de los módulos priorizados por

el MTPE. Este documento, especifica el modo de funcionamiento del sistema,

documenta la organización de los sub sistemas, módulos, pantallas y reportes del

sistema.

Programación de las funcionalidades de la plataforma.

Pruebas unitarias y pruebas de integración de cada uno de las aplicaciones,

sub sistemas y módulos desarrollados.

Migración o carga de información de acuerdo a lo definido en el documento de

análisis y alcance del proyecto.

Capacitación técnica y funcional.

Despliegue, implementación y puesta en producción de la plataforma.

Monitoreo, seguimiento y control del uso de la plataforma por un período

máximo de (06) seis meses, determinación de requerimientos adicionales y

afinamiento de las políticas de uso, seguridad de la plataforma.

Documentación técnica, manuales de usuario por perfiles.

-3-

VI. CARACTERÍSTICAS DEL SERVICIO A REALIZAR (DESCRIPCIÓN DEL PROYECTO)

A continuación se describe los mínimos módulos que debe contener la plataforma virtual

de aprendizaje, se espera que esta primera identificación sea enriquecida y ampliada por

la propuesta técnica de los proveedores postulantes.

La plataforma virtual, para los cursos online debe ser versátil y de alto rendimiento, como

base se podrá tomar las plataformas E-learning del mercado como: Moodle, Dokeos, etc.

Que en líneas generales contienen:

o Ambientes de formación e intercambio colaborativos, mediante espacios de

intercambio sincrónico y asincrónicos (Chat, foros, Wikis, FAQ, etc.)

o Interfaces para habilitar contenidos y que la herramienta permita incluir

traducciones a varios idiomas y que sea optimizada para casos de personas

con discapacidad.

o Herramientas para acceso a contenidos online, seguimiento al alumno,

tutoriales, evaluaciones, auto-evaluaciones, inscripciones online, foros,

transmisión de clases y contenidos en tiempo real, entre otras como se

detallará más adelante.

Detalle de las principales opciones que debe tener la Plataforma Virtual

Los proveedores postulantes deberán con el área aprobar el Sketch (diseño a mano), luego

pasarán a realizar el wireframing, y luego de aprobado toda la estructura, el diseño en sí.

Todos estos pasos deberán contar con la aprobación del área técnica.

Los consultores podrán proponer mejoras, pero no quitar los detalles mínimos requeridos.

El diseño se debe presentar para aprobación indicando como se visualizarán en TV/Smart

PC/Laptop, en una Tablet y en celular.

1.1. INTERFAZ:

- La interfaz debe ser moderna, responsiva y accesible.

- La aplicación del aula virtual debe contemplar la disponibilidad para personas con

discapacidad. (Esto debe darse para todos los cursos).

- De realizarse una aplicación independiente para el tema de discapacidad esta debe

estar enlazada con el aula virtual – la aplicación gestionará el contenido subido y

mostrará en el tema correspondiente para personas con discapacidad.

- Se podrá modificar el tema (skin, theme) de la plataforma virtual, la cual se

encontrará en el panel administrativo debe tener opción de cargar temas, por

ejemplo para fechas especiales por ejemplo Fiestas Patrias, Aniversario de la

institución, etc.

- Para la parte administrativa:

o Debe mostrar todas las opciones para el administrador, tanto para crear

docentes, matriculas, gestión de archivos, manejos de los temas (máscara de

la interfaz), colocar privilegios, etc. Así mismo de acuerdo a su perfil le cargará

la interfaz.

- En la página principal de acceso público, deberá contener las opciones de Blogs,

Agenda de los cursos a dictarse, etc.

- Para personalizar la interfaz tener en cuenta los colores, de acuerdo a la identidad

institucional.

-4-

1.2. GESTIÓN DE ARCHIVOS

- Debe contemplar la gestión de archivos. Los archivos que se pueden subir a la

plataforma serán los más comunes: doc, docx, xls, xlsx, ppt, pptx, (extensiones de

ofimática open source), zip, rar, 7zip, txt, html, etc.

- El administrador tendrá el control para cambiar el límite de los tamaños de los

archivos que pueden subir. Esto puede ser modificado en el panel del

Administrador.

- La plataforma deberá disminuir el tamaño en kilobytes de los archivos muy

pesados, gestionando el menor tamaño para las imágenes o peticionándolo para

que carguen más rápido.

1.3. GESTIÓN DE USUARIO

- Tener un formulario de registro de usuarios, la cual debe tener acceso de la página

principal de la plataforma virtual.

- La herramienta debe permitir la inscripción de alumnos peruanos y extranjeros al

sistema. En el caso de los nacionales sus datos deben ser validados con los

servicios Webs de la RENIEC (por lo que solo será necesario ingresar su DNI, para

que le cargue sus datos personales); en el caso de los extranjeros solicitara código

de carné de extranjería o pasaporte, el cual será validado con los servicios Web de

Migraciones.

- El administrador asignará los perfiles a los usuarios: Docente, alumno, trabajador

del MTPE, empleado del MTPE, sindicato del MTPE, etc.

- El tutor o docente podrá ser nacional o extranjero.

- Los datos solicitados a la RENIEC y que no podrán ser modificados: Apellidos,

Nombres, Domicilio, Departamento, Provincia, Distrito, Provincia, Edad, Sexo, etc.

- El usuario deberá aceptar los términos y condiciones que imponga el programa, en

el caso que no acepte los términos, no se debe grabar como usuario.

- El usuario no podrá una vez creado su cuenta modificar su perfil, sino sólo el

administrador, el usuario podrá subir una fotografía suya (el tamaño debe estar

limitado en la plataforma), y actualizar su perfil en los campos: nivel educativo,

profesión, ocupación, empresa en la que labora, actividad económica de la

empresa (Esto se debe determinar enlazando a la SUNAT, por lo que bastará

ingresar el RUC para que cargue los datos de la empresa), correo electrónico,

Teléfono Fijo y Celular, Preguntar si es persona con algún tipo de discapacidad.

- Cuando un alumno se registra en un curso debe quedar habilitado también para

usar las herramientas colaborativas de ese curso.

- El administrador podrá agregar más campos en cualquier momento, por lo que la

plataforma virtual debe estar flexible, para este efecto.

- Se debe seleccionar en los usuarios (Roles y Permisos) si son trabajadores,

empleados o representan al sindicato. Esto también se debe de validar con la data

de RRHH.

- El usuario puede estar registrado en la plataforma, pero debe matricularse en

algún curso si desea llevarlo, los cursos podrán ser obligatorios y algunos

opcionales.

-5-

- Debe manejar tipos de usuario, entre los que se necesita a parte de los Docentes o

Tutores, uno de administrador general de la plataforma, un administrador del

curso, además de los solicitado: Sindicatos, empleados y trabajadores.

- Cabe indicar que cada usuario tendrá la vista personalizada según sus permisos.

1.4. GESTIÓN DE MATRICULA

- El administrador apertura un nuevo curso.

- Los usuarios registrados en la plataforma, pueden inscribirse en el curso, pero

necesitarán que sea confirmada por el tutor o el administrador.

- El administrador puede limitar la inscripción o colocar requerimientos especiales

que tienen que cumplir para poder registrarse y se enviará un mensaje al usuario

indicando en el caso que se le impida la inscripción en el curso. (Por ejemplo un

curso puede ser que solo esté dirigido a personas del sindicato, la aplicación

determinará por los datos del usuario, si se acepta al usuario que ha querido

registrarse en el curso).

- Se podría habilitar el acceso a invitados, en este caso el invitado podrá ver el

material pero no podrá participar. En este caso el que da el permiso al invitado

podría indicar las horas o los días que estará habilitado para ingresar como

invitado.

- Los alumnos también podrán ser matriculados mediante algún archivo plano (CSV),

o por XLM.

- Se deberá proveer algún medio de pago, para que en los casos de que la matricula

pueda tener algún costo sea pagado mediante esta plataforma y, esto se pueda

pagar mediante algún medio de pago digital, llámese Paypal, Visa, Mastercard, etc.

Esto debe estar habilitado en las herramientas del administrador al momento de

crear el curso.

- Se confirmará la matrícula del curso elegido mediante el envío de un correo

electrónico al usuario o alumno que se matriculó.

1.5. GESTIÓN DE IDIOMA

- El idioma de la plataforma y de los contenidos, debe ser administrable, pudiendo

configurarse nuevos idiomas, para iniciar se deberá configurar 3 idiomas: Español,

inglés y quechua, por lo que se debe dejar habilitado la posibilidad de incrementar

otros idiomas.

- La herramienta debe contemplar al momento de crear los cursos, en tener

habilitado los tres paneles de idioma (se podría trabajar con los TABs o lenguetas

). Y esto se incremente cuando se adicione otro idioma.

- Para el caso de la interfaz de la aplicación considerar trabajar con los archivos

PO/MO tal como trabaja el WordPress para cambiar de idioma a su interfaz. (U

otra solución que pueda ser una mejor y fácil opción).

- La interfaz cambiará de forma automática cuando se seleccione el idioma

solicitado.

- Los cursos se actualizarán al idioma solicitado solo si este fue cargado en dicho

módulo, caso contrario mostrará los idiomas ¡+del curso, que por defecto será el

español.

1.6. GESTIÓN DE CREACIÓN DE CURSOS

- Los cursos deben pertenecer a una categoría.

-6-

- Los cursos deben estar identificado con un código único.

- En este caso los cursos deben tener las siguientes opciones: Borrador, Pendiente

de Revisión y Publicado.

- Los cursos se podrán exportar, generándose un consolidado de todo (curso, temas,

evaluaciones, foros, chat, etc.) de estos y que puedan ser instalados nuevamente.

- Al momento de crear un curso, se debe enlazar las lecciones parte teórica,

lecciones prácticas, ejercicios, simulación de exámenes, configuración en la agenda

de las fechas y hora de la clase en vivo, apertura de blogs, foro.

- Todos los cursos creados tendrán un medidor de encuesta o comentarios de los

alumnos que han realizado el curso, el cual tendrán la opción de calificarlos hasta

con 5 estrellas.

Imagen referencial

1.7. GESTIÓN DE CREACIÓN DE CONTENIDO (EDITOR DE TEXTO)

- Debe existir un panel con todas las herramientas ofimáticas disponibles para el

tutor y poder incluir en la visualización del alumno.

- Debe manejar la mayor cantidad de las opciones que se maneja en un editor de

texto como Word / open office. (Tipos de fuentes, estilos, alineación, etc.), agregar

tabla, fila, columna, colores de fondo, etc.

- Debe contener plantillas ya elaboradas con hojas de estilo para que el docente

arme su clase, y debe tener la opción de guardar plantillas.

- Por defecto debe tener las siguientes opciones para la creación:

o Lectura de material de apoyo.

o Estudios de casos

o Talleres Vivenciales

o Trabajos grupales

o Trabajos individuales

o Simulación de exámenes

o Exámenes

o Practicas Calificadas

o Charlas de Discusión

o Ejercicios prácticos.

Realización del curso

- Durante el curso cuando se utilice material en video o presentaciones, la

plataforma virtual debe determinar si es que el alumno puede seguir avanzando al

-7-

siguiente tema, esto se da siempre y cuando termine la sesión anterior. El alumno

no podrá avanzar hasta que concluya un tema.

- En el caso de que la clase se componga de un video /ppt, la aplicación debe indicar

cuando ha llegado a visualizar por completo el video, para el caso de habilitar los

siguientes temas. Y debe guardar la ubicación en video de acuerdo al tiempo

transcurrido y proponer al usuario visualizarlo desde donde lo ha dejado en el caso

que se cierre sin haber terminado de visualizar por completo dicho video. (Si por

ejemplo el alumno ha estado visualizando una clase y se ha quedado en el minuto

10 de un video y cierra sesión, luego se conecta desde su celular, el video

aparecerá en la posición donde se ha quedado anteriormente y dando la opción se

reiniciar desde el punto donde se ha quedado.

- El docente tendrá la opción de colocar su curso en Edición, el cual no se podrá ver

por los alumnos hasta que el docente decida publicarlo. (En este caso los cursos

deben tener las siguientes opciones: Borrador, Pendiente de Revisión y Publicado)

- El docente podrá ocultar algún capitulo, esto será usado cuando se repita un curso

ya realizado. (Ejemplo se ha programa un nuevo curso diferido, el administrador

podrá según el cronograma los temas a pesar que el curso ya se encuentra

desarrollado por completo pero la visualización del alumno es por tema.)

- Para un curso se debe programar los días que serán dictado los temas. Esto se

debe enlazar en la agenda (debe quedar registrada en la agenda general).

- El administrador podrá colgar los videos en alguna cuenta pública siempre que el

curso sea de libre acceso al público y no sea de costo.

- Para los cursos privados o pagados el video debe estar cargado en el servidor

propio del Ministerio. Para esto debe tener un reproductor propio. El reproductor

debe tener características de: Poner pantalla completa, maximizada a toda al

tamaño del navegador, además de tener una opción para añadir como favorito,

debe tener una opción para colocar calidad del video que va de 360p hasta

1080p(HD), además contener una opción para ver el video a cierta velocidad de

reproducción: de 0.5x hasta 2.0x.

Imagen Referencial

- En la parte superior izquierda del video, debe estar un enlace para el menú,

cuando se haga clic en el menú este debe aparecer sobre el video, mostrando todo

el temario y resaltar el módulo en que se encuentra.

-8-

Imagen referencial.

1.8. MODULO DE CLASES EN VIVO

- La plataforma debe contener un sistema de Video conferencias, o clases en vivo, el

cual utilizará tecnología streaming que se enviará la señal por internet.

- En la misma pantalla de video de la clase en vivo, se debe mostrar un panel de

chat/audio/video con los alumnos asistentes.

- El docente podrá ver a los alumnos (si es que tienen cámara) en el caso que no

tenga cámara debe mostrar la imagen de su perfil, los cuales podrán pedir permiso

para que realicen consultas en vivo. El docente podrá ceder la palabra activando

sobre su imagen del alumno.

- Para que un alumno pueda hablar tiene primero que solicitarlo y si el moderador

lo aprueba sale el audio para todos. En el panel mostrará un botón rojo esto

indicará quien está pidiendo la palabra.

- Los alumnos pueden preguntar utilizando su micrófono o chat.

- Los videos deben tener una marca de agua del Ministerio en la parte inferior

derecha, esto se debe aplicar a todos los videos e imágenes.

1.9. VISTA DEL ALUMNO

- En la vista del alumno se debe mostrar los Cursos que está matriculado, los cursos

que ha llevado, los cursos concluidos.

- Cuando se esté viendo la clase que puede ser un vídeo al costado derecho debe

aparecer las opciones del índice del curso, algunas descargas adicionales al tema,

una pestaña de la discusión y para que el alumno deje sus apuntes.

- Esto puede ser modificado pero para la mayoría de los cursos de debe manejar la

siguiente estructura:

o Cuando se inicie un tema este debe tener una evaluación de entrada, para

realizar la medición del alumno o estimar el nivel como ingresa a este

tema.

-9-

o Debe continuar con una introducción que puede ser colgado en video o

PPT.

o Seguido vendrá el desarrollo de la clase, que contendrá el material

multimedia.

o Se debe habilitar las herramientas colaborativas como por ejemplo un foro

virtual.

o Se debe indicar si habrá clases en vivo, estas deben tener habilitado al

mismo momento el chat para realizar las consultas al docente.

o Se debe habilitar una opción para práctica (tipo evaluación), esta puede

ser tipo examen o dar la opción de subir un archivo para que sea corregido

por el tutor.

o El curso debe terminar con una evaluación de compresión del tema

desarrollado.

Estructura del Curso:

Presentación: Permitirá dar mayor información del curso, tales como el objetivo,

público objetivo, temario (módulos) los responsables (pedagógica y

administrativa), entre otros.

Guía del Participante: Este documento tiene como objeto guiar para la utilización

del curso virtual, en ella encontrará recomendaciones que ayudarán en el

desarrollo del curso: cómo acceder a la plataforma de formación on-line, navegar

correctamente, una descripción de las actividades a realizar, calendario de

impartición y de información, el sistema de evaluación. En razón a ello, es un

documento importante que se tiene que habilitar para que el participante pueda

acceder al curso.

Cronograma: Herramienta de gestión, el mismo que incluye una lista de

actividades o tareas con las fechas previstas, tiene un inicio y final. Este

documento también tiene que habilitarse para que esté al alcance de los

participantes.

Evaluación de entrada: Se realiza al comienzo del curso virtual, consiste en la

recogida de información del nivel de conocimientos previos al participante. Es

imprescindible para iniciar cualquier mejora, trazar objetivos que se deban

conseguir con el desarrollo del curso, asimismo permitirá valorar el impacto del

proceso de capacitación. Evaluación que tendrá que ser habilitada para el acceso

de los participantes y su calificación debe ser inmediata.

Foro de presentación: Los participantes del curso podrán realizar una pequeña

presentación personal y expresar sus expectativas iniciales frente al curso. Este

foro va a permitir al docente o tutor conocer a los participantes.

Unidades de aprendizaje: Deben ser presentadas en un documento integrado y

organizado que contenga los elementos del proceso enseñanza – aprendizaje de la

temática a disertar, el mismo que debe de estar diseñado con una apariencia

-10-

visual que resulte atractiva, que motive al participante, y que por su relevancia

debe contarse con un bloque para su habilitación. La misma contienen: Objetivo,

Módulo, Lecturas recomendadas, actividades calificadas (foro calificado – trabajo

individual – trabajo grupal – evaluación de proceso entre otros).

Evaluación Inicial: Recogida y valoración de los conocimientos previos con el que

cuenta el participante previo al inicio del curso virtual. Se debe contar con un

aplicativo en la cual los alumnos participen online y la calificación sea automática o

dar la opción de subir un archivo para que sea corregido por el tutor. Dicha

evaluación sólo servirá para de manera informativa para el tutor o docente y tener

una idea de los conocimientos que puedan tener los participantes respecto al

curso de capacitación.

Evaluación Final: Recogida y valoración de los conocimientos adquiridos por el

participante al finalizar el curso virtual, para ellos se debe de habilitar en aplicativo

de capacitación a fin de que los participantes intervengan de manera online y su

calificación sea automática o dar la opción de subir un archivo para que sea

corregido por el tutor.

Calificación del Curso: Forma de cálculo de las evaluaciones a fin de obtener la

nota final del curso.

VISTA DEL ALUMNO

Ejemplo:

Curso: Título del Curso

Tema 02: Título del tema a desarrollar.

Unidad 01: Tema de la unidad a desarrollar

Fecha: Del 01 de junio 2016 hasta el 09 de junio 2016

Al costado de esta pantalla de debe mostrar: Las

discusiones del tema, un botón de anuncio, y otro con la

Logo

Introducción

Logo

Evaluación de

Entrada

Logo

CLASE

Logo

FORO

Logo

PRACTICA

Logo

EVALUACIÓN

SALIDA

+

ADICIONAR

OTROS TEMAS

-11-

lista de los alumnos conectados en ese momento para ese

curso.

Esquema referencial

1.10. CERTIFICACIÓN

- En la aplicación se debe tener la opción para activar si algún curso debe tener

certificación.

- La aplicación debe tener la opción para configurar: en el caso que el alumno haya

sido aprobado debe enviar un certificado (firmado digitalmente) como Aprobado.

- El docente podrá aprobar si habrá o no CERTIFICADO solo como ASISTENTE en el

caso que el alumno no haya salido aprobado en el curso. Ejemplo, los que

asistieron y no dieron examen, se pudo indicar que no se le emitirá certificado o se

le emitirá un certificado como asistente.

- El certificado debe tener una codificación (Recomendable que sea firmado

digitalmente).

- El certificado se enviará de forma automática el email de participante.

- Cualquier entidad que esté registrada, podrá con el código – del certificado

emitido - verificar en la página web si la entidad ha emitido el certificado. (para

esto el proveedor deberá construir una aplicación que sea enlazada en el portal

del ministerio).

- El administrador podrá en cualquier momento obtener una copia de los

certificados emitidos.

1.11. NOTIFICACIONES

- El administrador / docente debe configurar la opción de envíos los cuales pueden

ser, notificación en general que se publique en el blogs, o personales que debe ser

al email, celular, etc.

- Las notificaciones masivas a todos los usuarios deberá realizarlo el Administrador

para toda la plataforma, y el tutor o docente solo para su curso.

- Para los alumnos en el menú de notificaciones le debe aparecer si desea recibir

notificaciones de cursos nuevos. O Cuando el docente actualice los módulos del

curso que está llevando, las tareas que debe presentar en el curso registrado, etc.

Imagen referencial

-12-

1.12. MONITOREO O SEGUIMIENTO DE LOS ALUMNOS.

- La aplicación enviará un reporte del seguimiento de los alumnos a los docentes:

participación en los foros, cuanto tiempo estuvo en la plataforma conectado,

asistió a las clases en vivo, etc.

- Los reportes se podrán generar a solicitud del docente. Para esto la plataforma

debe estar preparada para generar reportes propios.

1.13. MODULO DE REPORTES

- Reporte de lista de comentarios, para determinar cuáles son las que faltan

respuestas, debe además mostrar estadísticas de comentarios contestados, etc.

- Reporte de Lista de copias de respaldo (backup) realizados los cuales debe indicar

la fecha de realizado de la copia de seguridad.

- La aplicación debe estar preparada para poder realizar reportes a medida.

- Algunos reportes que se necesita:

o Número de participantes en los cursos, porcentaje de participantes por

grupo de edad según región.

o Número y porcentajes de participantes por ocupación según sexo.

o Número y porcentajes de participación según actividad económica que

pertenece la empresa.

o Número y porcentajes de participantes por profesión según sexo.

o Número y porcentajes de participantes por nivel educativo según sexo.

o Número y porcentajes de participantes por nivel educativo según grupo de

edad.

o Número y porcentajes de participantes que aprobaron y desaprobaron

según curso virtual.

o Número de participantes con discapacidad por grupo de edad según sexo.

o Número de participantes con discapacidad por región según nivel

educativo.

- Se incluirá una cantidad de reportes que serán definidos con el área funcional,

durante la ejecución del proyecto, cinco (5) reportes en total.

1.14. MÓDULO DE GESTIÓN DE EVALUACIÓN

- La aplicación e-learning debe tener una aplicación integrada para generar

(preguntas para las evaluaciones).

- Las evaluaciones pueden ser: Evaluación de Ingreso (Tema), Práctica, Evaluación

de Salida (Tema), Evaluación del Curso o Final (Para la certificación).

- El docente al momento de crear la evaluación indicará cuál será la respuesta

correcta, y además dejará comentario en cada respuesta (en las correctas e

incorrectas).

- Para la evaluación también el docente podrá ingresar notas por presentación de

trabajos o asignaciones.

- Cuando se muestre al alumno, las alternativas se mostrarán de forma aleatoria.

- Permitir que el tutor elabore evaluaciones que se aplicarán en línea a los alumnos.

En la elaboración de la evaluación debe ser con todas las opciones que se da en

una evaluación escrita, debe ser de selección individual, múltiple, para responder

con texto, para cotejar.

-13-

- Las evaluaciones tendrán una opción (habilitada por el tutor / docente) hasta

cuantas veces se podrá realizar, en ese caso el sistema guardará las notas y los

intentos realizados, y en ese caso tendrá validez la nota más alta.

- También se podrá modificar el tiempo que demora dicha evaluación, considerando

que si se termina el tiempo y no ha concluido la nota debe ser solo hasta donde ha

llegado. Tendrá una opción de habilitar por tanto tiempo si es que el docente cree

conveniente (si es que el alumno justifica la causa).

- Las evaluaciones podrán ser de 10 a 20 preguntas; Si una evaluación tiene 10

preguntas y el docente ha preparado mucho más de 10, las preguntas saldrán

aleatoria a los alumnos, lo mismo que las alternativas tiene que salir de forma

aleatoria.

1.15. ACTIVIDADES Y HERRAMIENTAS COLABORATIVAS

Las herramientas colaborativas que puede crearse en los cursos son:

BLOG.

- Debería contener un blog y debe estar el enlace en la pantalla de inicio, donde

se describe o se publique las últimas novedades.

FOROS

- Los foros (discusiones asincrónicas) se habilitaran con el curso y se recomienda

que se configure por tema, debe estar asociado a calificación de respuestas

como opción del docente.

CHAT

- El Chat se habilitará para la conversación con el docente cuando se realice

Clases en vivo, o en el caso que el docente se encuentre dando tutoría por este

medio, debe ser programáticamente activado.

VIDEO CONFERENCIAS

- Las videoconferencias se harán para el dictado de clases en vivo, además de

estar habilitado el chat, los alumnos podrán hacer sus consultas por

micrófono, siempre que el tutor les habilite el permiso.

WIKIS

- Los mismos alumnos podrán preparar algún material de forma colaborativa,

esto se puede colocar en uno de los cursos en los cuales se puede dejar como

tareas de investigación, deberá tener la opción de ser calificado, esta

funcionalidad es para el docente.

GLOSARIOS

- Son un registro de las palabras complicadas o técnicas que se utilizarán en el

transcurso de la clase a desarrollar, tendrá un apartado por curso.

1.16. AL INGRESAR (DESPUÉS DE LOGEARSE) DASHBOARD

-14-

Permitirá visualizar la estructura del curso que se desarrollará, tanto para el tutor como

para los participantes.

Asimismo, dentro de la opción de “Mis Cursos”, debe estar categorizado por temas que

corresponden a la Dirección General de Derechos Fundamentales y Seguridad y Salud en el

Trabajo, ejemplo:

o Seguridad y Salud en el Trabajo

o Trabajo Infantil

o Trabajo Forzoso

o Igualdad de Género

o Trabajadoras del Hogar

o Sindicalización

Dentro de cada categoría deberán estar los cursos a dictarse.

Agenda:

- Debe contener una agenda interna con las fechas de los cursos que está

registrado, reuniones con el docente, etc.

Anuncios

- Debe contener una sección de anuncios, en donde el docente indicará o colgará las

próximas fechas de curso, de presentación de trabajos, ya se encuentra publicado

un nuevo, etc.

Barra de Progreso:

- Indicadores de colores para, las actividades concluidas, para las actividades que no

se cumplieron y las que falta concluir.

Mensajes:

- Los mensajes que le llega al alumno, puede ser enviados por el tutor, por el

administrador, o por otro alumno de una clase. Ambos tienen que estar

matriculado en la misma clase para que se envíen mensajes.

Seguimientos de actividades.

- En la sección seguimiento de actividades, mostrará: El avance de los cursos en los

que tiene matricula. Los cursos que ya se ha concluido.

Sección de chat.

Sección de Enlaces

Sección de Ejercicios.

Sección de Grupos: Cree y comparta información con grupos de usuarios.

Estadísticas del propio alumno. Como avance, tiempo en la plataforma, cuantos cursos ha

llevado, cuantos le queda por terminar, etc, etc.

-15-

Detalle del curso

- Mostrará una descripción del curso, además de unos temas estadísticos, por

ejemplo: cuántos alumnos matriculados tiene, cuántos alumnos han concluido,

cuántas veces se ha realizado, cuantas estrellas tiene el curso, cuántos alumnos

han comentado acerca del curso, etc.

1.17. ENCUESTA A USUARIO PARA MEJORAS DE LA PLATAFORMA.

- Debe contener tipos de preguntas: simples, compuestas, para marcar checks, etc.

- Debe estar Integrado a un Newsletter.

- Debe Reportar los resultados en tiempo real.

- Deberá permitir generar Informes personalizados.

- Plataforma con seguridad integrada

1.18. POPUP (Paneles modales)

- Debe manejar paneles modales a especie de popups para incentivar el registro de

los usuarios a la plataforma, estos popups deben de salir según se configure:

cuando entre a determinada página o cuando tenga un tiempo navegando el

usuario en nuestra página.

1.19. COPIAS DE SEGURIDAD

- Permitir que el administrador pueda exportar datos por curso, por todo el

contenido y pueda gestionar su re-instalación, cuando se necesite restaurar

nuevamente.

1.20. Módulo de Gestión de Sindicatos

Permitirá el registro, modificación, actualización y eliminación de sindicatos a nivel

nacional con sus respectivos agremiados.

Se deberá registrar los datos requeridos de acuerdo a la normatividad vigente de

acuerdo su estructura jerárquica (confederación, federación, etc.)

Las organizaciones sindicales deben validarse con SUNAT y de sus agremiados con

la RENIEC. Debe evaluarse la posibilidad de integrarse con la Planilla Electrónica del

MTPE a fin de garantizar la consistencia de la organización sindical y de sus

agremiados.

Los documentos de sustento de las organizaciones sindicales deben registrarse en

Alfresco o algún repositorio de archivos especializado.

1.21. Módulo de Gestión de Alertas Tempranas

Permitirá el registro, modificación, actualización y eliminación de alertas

tempranas de paros potenciales que podrían generarse producto de la desatención

de reclamos, realizados por las organizaciones sindicales o incumplimiento de

acuerdos establecidos.

Permitir el escalamiento de alertas a las autoridades competentes o empresas

según correspondan, esto debe ser programáticamente definido.

Deberá permitir la clasificación de los alertas según tipología y prioridad de

atención según política de gobierno y/o normatividad aplicable.

-16-

Deberá presentarse bandejas, gráficos y consultas (semáforos) de seguimiento de

los diferentes estados de las alertas.

1.22. Módulo de Gestión de Pliego de Reclamos

Registro, modificación, actualización y eliminación de reclamos establecidos por

los sindicatos a nivel nacional.

Permitir el escalamiento de reclamos a las autoridades competentes o empresas

según correspondan, esto debe ser programáticamente definido.

Deberá permitir la clasificación de los reclamos según tipología y prioridad de

atención según política de gobierno y/o normatividad aplicable.

Deberá presentarse bandejas, gráficos y consultas (semáforos) de seguimiento de

los diferentes estados de los pliegos de reclamos.

1.23. Módulo de Gestión de Acuerdos

Permitirá el registro, modificación, actualización y eliminación de acuerdos

establecidos entre las organizaciones sindicales y las autoridades competentes o

empresas según correspondan.

Permitir el seguimiento de cumplimiento de acuerdos, deberá presentarse

bandejas, gráficos y consultas (semáforos).

Mostrará bandeja de alertas vía sistema y correo electrónico de fechas

vencimientos a los involucrados

Permitir la negociación y re-negociación de acuerdos

1.24. Módulo de Gestión de Paros

Permitirá el registro, modificación, actualización y eliminación de paros realizados

por los sindicatos y sociedad civil en general.

Deberá presentarse bandejas, gráficos y consultas (semáforos) el seguimiento de

incidencias

Mostrará bandeja de alertas vía sistema y correo electrónico de incidencias criticas

Registro de demandas y necesidades no atendidas

1.25. Requerimientos no funcionales

Código Nombre Descripción

RNF.1 Lenguaje de Programación El lenguaje a utilizar será PHP y Java.

Orientados ambos a objetos.

RNF.2 Sistema Gestor de Base de

Datos

La base de datos utilizará como gestor de

base de datos el motor MySQL y Oracle

RNF.3 Orientada a servicios La solución deberá ser distribuida y orientada

completamente a servicios.

-17-

RNF.4 Interfaz de usuario La interfaz de usuario deberá estar basada en

tecnologías Web. Con plantillas para cada tipo

de interfaz previamente aprobadas.

RNF.5 Interfaz responsiva La interfaz de usuario deberá auto-adaptarse

a cualquier resolución de pantalla.

RNF.6 Capacidad de Carga La solución deberá soportar por lo menos

1000 conexiones concurrentes sin que se vea

afectado el rendimiento e impida o retrase la

operatividad por parte de los usuarios.

RNF.7 Uso racionalizado de memoria

de servidores

La solución deberá utilizar racionalmente la

memoria, sin que se vea colapsada o

degradada con menor carga de la prevista

(RNF.6), deberá utilizar técnicas y

mecanismos optimizados que sólo acceda,

transfiera, manipule, lo que requiere la

interfaz de usuario; en caso exista

procesamiento pesado deberá ser realizado

fuera de línea y por lotes.

RNF.8 Uso racionalizado de acceso a

datos

La solución deberá consultar datos de modo

filtrado, sólo devolviendo resultados

paginados que el usuario visualizará, evitando

transferir por las distintas capas y los servicios

cantidades excesivas de datos que sea

inmanejable y que consuma

innecesariamente recursos de memoria, CPU

y red.

RNF.9 Escalable La solución debe ser escalable bajo la

estrategia scale-up (Añadir más recursos al

servidor) inicialmente y luego scale-out

(Añadir más servidores), según las

necesidades de procesamiento.

RNF. 10 Nivel de acoplamiento La solución debe tener bajo nivel de

acoplamiento y la posibilidad de editar

fácilmente los parámetros que se consideren

-18-

dinámicos y requieran cambios frecuentes,

No existiendo parámetros en código duro.

RNF. 11 Estilo de programación

uniforme

La solución deberá utilizar patrones y

estándares reconocidos en la industria del

software; las interfaces de usuarios y cada

una de las capas deberá seguir el mismo estilo

de programación. Deberá seguir un estándar

previamente aprobado.

RNF. 12 Código fuente comentado El código fuente en cada uno de los archivos

construidos y cada uno de los métodos y

atributos deberá estar descriptivamente

comentado. Deberá seguir un estándar

previamente aprobado

RNF. 13 Tiempo de Respuesta El tiempo de respuesta aceptable para la

solución, inclusive bajo condiciones de

concurrencia descritas en el RNF.6 es de 4

segundos como máximo por cada interacción

que recorra desde la interfaz de usuario hasta

la base de datos de ida y vuelta.

RNF. 14 Reglas de Nombramiento Todos los elementos de código fuente,

archivos, clases, métodos y atributos deberán

estar escritos sólo en castellano. Deberá

seguir un estándar previamente aprobado

RNF. 15 Componentes adquiridos La solución no deberá contar con

componentes comerciales que genere

dependencia con algún fabricante.

RNF. 16 Notificaciones Legales,

Derechos de Autor, y Otras

Los derechos de autor de toda la solución

serán cedidos plenamente al MTPE,

RNF. 17 Estándares aplicables Los estándares aplicables son los siguientes:

Requerimientos 1.1 al 1.19

Apache: 2.2.X o superior

-19-

CentOS: CentOS release 6.X (Final) o superior

Red Hat Linux

MySQL: 5.5.X o superior

PHP: 5.4.45.X o superior

Requerimientos 1.20 al 1.24

Java 6

AngularJS 1.4

Bootstrap 3.3

CSS 2.0

JQuery 1.0

HTML5

Spring 3.1

Log4j 1.0

JPA - Hibernate

Jasper Reports

Oracle 11G

Maven 3.0

JBoss 7.1.1

RNF. 18 Parametrizable La solución deberá ser construida de tal

manera que un cambio en los parámetros de

negocio no obligue la generación de una

nueva versión de la solución o del módulo.

RNF. 19 Errores aceptados La cantidad de errores de programación

aceptada es de cada mil líneas de código

existirán 0.005 errores.

RNF. 20 Entrenamiento Será necesario que se contemple un plan de

sensibilización además del plan de

capacitación a usuarios internos y externos de

todas las sedes, con la cantidad de horas y

sesiones suficientes que garanticen cubrir la

funcionalidad operada por todos los roles del

sistema.

-20-

RNF.21 Ayudas en el sistema La solución deberá proporcionar ayudas en

cada pantalla donde interactúe un usuario.

Además de mostrar micro mensajes

“tooltiptext” en cada opción que dispara una

acción (botones, imágenes, etc.)

1.26. Requerimientos de seguridad

Código Descripción

RNFS.01 El sistema utiliza un aplicativo independiente de la plataforma, inclusive instalado en otro subdominio o de acceso sólo desde una red local, para la Administración de usuarios, para gestionar la creación de usuarios, roles y permisos.

RNFS.02 El sistema contempla el acceso mediante el uso de una cuenta y clave de acceso, diferente para cada usuario.

RNFS.03 El sistema implementa seguridad por roles

RNFS.04 El sistema permite el cambio periódico de las claves de los usuarios y los fuerza a cambiarlo en su primera sesión.

RNFS.05 El sistema cuenta con la facilidad de cambio forzado de la clave de acceso cada X días.

RNFS.06 El sistema permite restringir al usuario de tener más de X sesiones simultáneas abiertas.

RNFS.07 El sistema previene intentos de ingreso no autorizado, después de los X intentos fallidos, la cuenta del usuario se bloquea.

RNFS.08 El sistema permite el bloqueo automático de aquellas claves de acceso que no han realizado ninguna transacción en el sistema por un lapso de tiempo programable.

RNFS.09 El sistema controla que las claves de los usuarios tengan una longitud mínima de X caracteres, y no coincidan con el nombre de la cuenta.

RNFS.10 El sistema mantiene un archivo histórico encriptado de al menos las últimas X claves de acceso utilizadas para cada cuenta, evitando que estas se repitan.

RNFS.11 El sistema tiene la posibilidad de limitar el acceso de los usuarios los días de la semana y horas del día no laborables o fuera de su turno de trabajo.

-21-

RNFS.12 El sistema controla que las claves de los usuarios contengan obligatoriamente caracteres alfanuméricos, y no sólo caracteres alfabéticos.

RNFS.13 La cuenta de más alto privilegio sólo podrá ser usada por un sólo usuario.

RNFS.14 El sistema no contiene en las líneas de código los nombres de los usuarios y/o claves de acceso.

RNFS.15 Ningún desarrollador mantiene su cuenta en el aplicativo cuando éste pasa a producción.

RNFS.16 Las cadenas de conexión a los distintos orígenes de datos y servicios, se encuentran encriptadas, aplica también a puertos y protocolos de comunicación

RNFS.17 Los privilegios sobre la información sensible se concede y controla separando acciones como las de lectura, escritura y eliminación, exportación, etc.

RNFS.18 Las Bases de Datos de las aplicaciones que involucren información crítica, valiosa o confidencial, permanecen encriptadas y su desencriptación se realiza sólo por los sistemas que trabajan con dicha información.

RNFS.19 El repositorio o base de datos de contraseñas se almacenan en forma separada de los datos de los sistemas transaccionales.

RNFS.20 El sistema contempla la desconexión de sesiones por tiempo muerto, luego de X minutos programables.

RNFS.21 El sistema al autenticarse no indica si el usuario o clave es incorrecta, sino sólo muestra un mensaje genérico que indique datos incorrectos.

RNFS.22 El sistema informa al usuario la última fecha y hora de inicio de sesión.

RNFS.23 El sistema informa al usuario la última fecha y hora de intento fallido de autenticación.

RNFS.24 El sistema informa al usuario cuando su usuario ha excedido el límite de intentos fallidos de conexión, adicionalmente notifica el bloqueo a su cuenta a su correo electrónico.

RNFS.25 El sistema posee una opción única de cierre de sesión.

RNFS.26 El sistema diferencia entre bloqueo de usuario administrativo y bloqueo por exceso de intentos fallidos de autenticación.

-22-

RNFS.27 El sistema no expone cualquier parte secreta de la credencial en cookies, cabeceras o campos ocultos.

RNFS.28 El sistema no depende únicamente de la autenticación por sistema operativo o de infraestructura.

RNFS.29 El sistema permite fácilmente el cambio del algoritmo de encriptación unidireccional.

RNFS.30 El sistema habilita la funcionalidad de CAPTCHA en la autenticación de usuarios y en todos los formularios de acceso público. Esta funcionalidad deberá permitir 5 veces los intentos fallidos.

RNFS.31 El sistema deberá permitir el cambio de clave por parte del usuario validando el usuario y clave original. El cambio de clave deberá restringir la repetición de las 03 últimas claves anteriores

RNFS.32 En la autenticación al sistema, solo se deberá permitir 5 intentos fallidos y en el siguiente intento bloquear el usuario por el resto del día, lo cual debe ser explicado mediante un mensaje al usuario.

RNFS.33 El sistema contempla mecanismos de autenticación para exponer servicios web

RNFS.34 El sistema transmite las credenciales de autenticación, utilizando el método HTTP POST

RNFS.35 El sistema no contempla la funcionalidad de recordar contraseña

RNFS.36 El sistema establece un tiempo de vida de sesión de 20 minutos, sin embargo, mientras haya actividad, la sesión se mantiene viva.

RNFS.37 El sistema no permite la autenticación concurrente con el mismo usuario

RNFS.38 Las contraseñas se almacenan en forma cifrada utilizando un algoritmo de cifrado unidireccional.

RNFS.39 El sistema debe verificar los límites de los valores que puede asumir una variable de entrada y rechazará y advertirá el desbordamiento del límite.

RNFS.40 El sistema verifica que los valores de entrada ingresados, corresponde sólo al tipo de dato asociado, rechazará la entrada y advertirá que el valor no es válido

RNFS.41 El sistema verifica en el caso de comparación de rangos, que el rango sea válido, rechaza la entrada y advierte la inconsistencia de los valores.

-23-

RNFS.42 El sistema verifica que no se ingrese registros duplicados, advierte que el registro ingresado es inválido

RNFS.43 El sistema accede a los datos mediante procedimientos almacenados parametrizados con argumentos atómicos por campos y con los valores consistenciados, salvo justificación de mejor opción.

RNFS.44 El sistema utiliza controles que aseguren la validez de los datos ingresados, tan cerca del punto de origen como sea posible.

RNFS.45 El sistema filtra los siguientes caracteres, por considerarlos peligros ‘ - < > ” % & \ / #, entro otros.

RNFS.46 El sistema en caso tenga que usar caracteres considerados peligrosos realiza otras validaciones del dato ingresado, entre otros, valido la longitud.

RNFS.47 El sistema valida los caracteres aceptados, cuando la entrada de datos sea texto multilinea.

RNFS.48 El sistema comprueba y restringe si hay bytes nulos (%00)

RNFS.49 El sistema comprueba y restringe si hay caracteres de nueva línea (%0d, %0a, \r, \n)

RNFS.50 El sistema comprueba y restringe alteraciones de ruta "punto, punto, barra" (../ o ..\)

RNFS.51 El sistema utiliza html encode para las salidas de información en HTML

RNFS.52 El sistema utiliza url encode para la salida de información por URL

RNFS.53 El sistema utiliza expresiones regulares para validar datos de entrada estructurados

RNFS.54 El sistema contempla el registro del log detallado de errores, ocurridos en el curso de la operación y procesamiento, adicionalmente a su visualización en pantalla y adicional al generado por el sistema operativo o el servidor web o de servidor de aplicación.

RNFS.55 El sistema deberá establecer perfiles de elaborador, revisor, aprobador y autorizador, para los procesos que se deriven entre distintos órganos o estadíos de revisión o aprobación.

RNFS.56 El sistema genera y reportar alarmas a través de email para errores críticos en el sistema, exceso de cuotas de recursos y violaciones de seguridad.

-24-

RNFS.57 El sistema no muestra en pantalla al usuario final el detalle técnico de las excepciones o errores.

RNFS.58 El sistema no muestra los identificadores de sesión en la dirección URL, ni siquiera cifrado.

RNFS.59 El sistema no utiliza cookies de sesión, en general no utiliza cookies como almacenamiento temporal.

RNFS.60 El sistema no utiliza frames ni iframes.

RNFS.61 El sistema registra la fecha y hora de inicio y terminación de sesión.

RNFS.62 El sistema registra los intentos exitosos y fallidos de acceso al sistema por cada terminal.

RNFS.63 El sistema verifica los privilegios de acceso a URLs antes de generar los enlaces y antes de cargar la página y antes de ser accedida.

RNFS.64 Las excepciones que puedan ser lanzadas tanto por el sistema operativo como por la aplicación son capturadas y tratadas correctamente.

RNFS.65 Los archivos cargados mediante upload, no se encuentran en las carpetas web públicas.

RNFS.66 Los parámetros pasados entre páginas por HTTP get, siempre se encuentran cifrados.

RNFS.67 Los registros de auditoría incluyen: Identificación del usuario, fecha y hora de acción, identidad o ubicación de la terminal (IP, nombre de equipo), acción realizada.

RNFS.68 El sistema no utiliza ventanas windows pop-up ni windows modal, en su reemplazo utiliza paneles que simulan ventanas modales.

RNFS.69 Se tiene identificado la obsolescencia de la información y se incorpora tareas manuales o automatizadas de traspaso a tablas históricas

RNFS.70 El sistema puede acceder a información actual e información histórica

RNFS.71 Los parámetros de sistema deben manejarse sólo en tablas de parámetros a fin que pueden ser actualizados sin necesidad de modificación del sistema

-25-

RNFS.72 El sistema solicita la reautenticación antes de la realización de operaciones críticas

RNFS.73 El sistema otorga el mínimo privilegio y restringe el acceso de los usuarios solamente a la funcionalidad, datos y sistemas de información que tiene predefinida y que son necesarios para realizar sus tareas.

RNFS.74 El sistema no incluye carpeta de binarios en los directorios de la web

RNFS.75 El sistema deshabilita las funcionalidades de completar automáticamente en los formularios que contiene información sensible, incluyendo la autenticación

RNFS.76 El sistema no difunde información sensible en respuestas de error, incluyendo detalles del sistema, identificadores de sesión o información de la cuenta.

RNFS.77 El sistema utiliza manejadores de errores que no muestran información de debugging o de memoria.

RNFS.78 El sistema implementa mensajes de error adaptados, los errores técnicos se almacenan en un log, pero no se muestran al usuario final.

RNFS.79 El sistema libera espacio de memoria en cuanto una condición de error ocurre.

RNFS.80 El sistema exige una reautenticación antes de permitir la transferencia de un archivo al servidor, salvo mejora funcional.

RNFS.81 El sistema restringe los tipos de archivos transferidos, validando no sólo verifica la extensión sino también verifica la estructura de los encabezados de los archivos

RNFS.82 El sistema no guarda los archivos transferidos en el mismo contexto de la aplicación web, los archivos poseen un repositorio específico.

RNFS.83 El sistema restringe la transferencia de archivos que puedan ser interpretados en el servidor, ejemplo: php, js, etc.

RNFS.84 El sistema nunca muestra rutas absolutas de ningún archivo del servidor al usuario.

RNFS.85 El sistema revisa los archivos transferidos por los usuarios para búsqueda de virus y malware

RNFS.86 El sistema registra la siguiente información en los logs: Registrar todas las fallas de validación de reglas de negocio. Registrar todos los intentos de autenticación, en particular los fallidos. Registrar todas las fallas en los controles de acceso.

-26-

Registrar todos los eventos de intento de evasión de controles, incluyendo cambios en el estado de la información no esperados. Registrar todas las excepciones del sistema. Registrar todas las funciones administrativas, incluyendo cambios en la configuración de seguridad. Registrar todas las fallas de conexión. Registrar las fallas de los módulos criptográficos.

RNFS.87 El sistema incorpora logs de auditorías de todas las opciones críticas.

RNFS.88 Las identidades de los que accesan a los servicios están identificados y acceden mediante autenticación y generación de un token.

RNFS.89 La autorización a los servicios web permite un control granular inclusive de los métodos expuestos.

RNFS.90 Los datos de entrada tienen restricciones y validaciones, por tipo de dato, longitud, formato y rango

RNFS.91 Los datos de entrada se encuentran saneados (sanitization), adicionalmente al punto anterior, se limpian las entradas de tags HTML, Javascript u Estilos, además del reemplazo de caracteres comilla simple, comilla doble, backslash y caracteres null.

RNFS.92 El sistema valida que las entradas de datos XML son validadas mediante un esquema acordado

RNFS.93 El servicio devuelve mensajes de error informativo si la validación falla.

RNFS.94 El sistema restringe con autenticación y autorización a nivel de servicio web y a nivel de método

RNFS.95 El sistema restringe con autorización el acceso a los URL o a los archivos RNFS.96 La autenticación básica se utiliza sobre un canal encriptado de

comunicación RNFS.97 Los servicios web que proveen datos sensibles implementan

autorización RNFS.98 Los datos sensibles en los mensajes de servicios web SOAP está cifrado

mediante el cifrado XML o los mensajes SOAP sólo se pasan a través de canales de comunicación cifrados (por ejemplo, usando SSL.)

RNFS.99 Las excepciones son controladas y pasadas con elementos estructurados en la salida XML

RNFS.100 El detalle de las excepciones es almacenado en logs (exceptuando data privada y contraseñas)

RNFS.101 Las excepciones de servicio web son atrapadas y controladas se tratan adecuadamente, no provoca comportamientos inesperados.

RNFS.102 El sistema registra en los logs las operaciones y transacciones clave RNFS.103 El sistema restringe enviar cantidades muy grandes de datos y sugiere

se dividan en trozos más pequeños. RNFS.104 La capa de servicios no tiene ni requiere el conocimiento de las

entidades de negocio utilizados por la capa de negocio.

1.27 El proveedor deberá realizar la carga en la plataforma de la totalidad del contenido del

primer curso a impartirse, además de la configuración de la totalidad de alumnos y

-27-

docentes, deberá transformar de ser necesario el material provisto por el equipo

funcional de forma que el curso quede listo para su iniciación.

1.28 El proveedor deberá ofrecer cursos de capacitación técnico-pedagógica a los responsables

de administración y gestión de la plataforma, por lo menos 5 personas.

1.29 El proveedor deberá ofrecer curso de capacitación en las herramientas software de

generación de materiales multimedia, por lo menos 5 personas.

1.30 El proveedor deberá realizar el pago del hosting de la herramienta de capacitación virtual

por 12 meses, contados luego del pase a producción, deberá cumplir con el RNF 6, se

sugiere las siguientes condiciones mínimas para los equipos de hosteo.

Servidores en redundancia (dimensionado para cubrir la concurrencia indicada en el RNF 6).

2 CPU Xeon 2.53GHz o superior

Memoria 24GB o superior

Disco 2 x 4TB SATA2 o superior

SW RAID 1

Trafico 20TB / mes

S.O Enterprise Linux Redhat o CentOS

Panel de administración

Soporte 24/7/365

Servicio de copia de respaldo

Servicio de Restauración

Servidor Administrado

VII. PRODUCTOS A OBTENER

El postor después de la firma de contrato deberá entregar los siguientes productos:

Concepción • Plan de Proyecto. • Plan de Desarrollo Software.

Análisis

• Documento Análisis y Especificación de Requerimientos • Documento de Especificaciones de Casos de Uso • Documento de Modelado de Base Datos

Personalización

• Documento de definición del diseño visual. • Fuentes de Implementación de diseño visual (Plantillas). • Documento de Pruebas de usabilidad e interacción con diseño visual

implementado, con usuarios.

-28-

Diseño

• Documento de Arquitectura de Software • Documento de Diagrama de Secuencia • Documento de Diagrama de Componentes • Documento de Prototipo de Interfaz de Usuario

Codificación

• Código fuente comentado. • Documentación código. • Acta de Verificación funcional y Pruebas con usuarios.

Carga de Contenidos de Primer Curso. • Acta de verificación de equipo funcional y técnico.

Pruebas • Documento de Plan de Pruebas (Interfaz, Funcionalidad, Carga,

Seguridad, Stress). • Documento de Resultado de ejecución de pruebas. • Actas de pruebas con usuarios y equipo funcional y técnico. • Manual de instrucción sobre el manejo de la herramienta virtual. • Manuales de usuario por cada tipo de perfil.

Despliegue

• Documento de Diagrama de Despliegue. • Documento de Procedimiento de Despliegue.

VIII. REQUISITOS MÌNIMOS QUE DEBE DE CUMPLIR EL POSTOR

El postor debe tener experiencia demostrable como mínimo Cuatro (04) años en desarrollo e

implementación de soluciones informática de preferencial plataformas de capacitación virtual

de similar magnitud que el presente, deberá acreditar implementaciones de sistemas de

información de magnitud similar al presente servicio.

1 Jefe de Proyecto

Ingeniero de Sistemas, computación o afines, con experiencia en gestión de proyectos

de Tecnologías de Información, con certificación PMP vigente, tres (3) años de

experiencia como mínimo con este rol.

1 Especialista en Implementación de Software de Capacitación Virtual

Ingeniero de Sistemas, computación o afines, con experiencia demostrable en la

implementación de herramientas de capacitación virtual (Deseable con certificación en

la herramienta a implementar), deberá tener los conocimientos para ampliar la

funcionalidad de la herramienta, con experiencia demostrada de no menos de tres 3

implementaciones de herramientas similares de equivalente magnitud.

-29-

1 Especialista de preparación de contenidos multimedia

Ingeniero o Técnico en Diseño Multimedia, o afines, experiencia en la generación de

contenidos multimedia, con experiencia no menor de tres (3) años.

1 Diseñador de Arte Gráfico Web.

Ingeniero, Técnico en Diseño Gráfico, o afines, experiencia en maquetación Web, con

experiencia no menor de tres (3) años en implementación gráfica de sitios web.

1 Especialista en e-learning.

Profesional especialista en gestión de herramientas e-learning, con estudios en

capacitación virtual y e-learning, profesional consultivo durante todo el proceso de

ejecución del proyecto, será el encargado de validar la didáctica de los contenidos a

incorporar en la plataforma, además será encargado de la capacitación en utilización

de la plataforma.

1 Desarrollador PHP.

Ingeniero de Sistemas, técnico en Programación, o afines, con experiencia en

desarrollo de sistemas de información, con experiencia no menor de tres (3) años en

implementación de sistemas de información.

2 Desarrolladores Java.

Ingeniero de Sistemas, técnico en Programación, o afines, con experiencia en

desarrollo de sistemas de información, con experiencia no menor de tres (3) años en

implementación de sistemas de información.

IX. PLAZO DE EJECUCION

El producto será completado en un plazo de 210 días calendarios desde el día siguiente

de notificada la orden de servicio o suscrito el contrato.

a. PRODUCTO 1

A ser presentado como máximo a los 10 días calendario de iniciado el servicio, conteniendo los entregables de la etapa de concepción del apartado VII (Productos a obtener) del presente documento.

b. PRODUCTO 2

A ser presentados a los 40 días calendario de iniciado el servicio, conteniendo la documentación de las etapas de Análisis del apartado VII (Productos a obtener) del presente documento.

-30-

c. PRODUCTO 3

A ser presentados a los 70 días calendario de iniciado el servicio, conteniendo la documentación de la etapa de Personalización del apartado VII (Productos a obtener) del presente documento.

d. PRODUCTO 4

A ser presentados a los 100 días calendario de iniciado el servicio, conteniendo la documentación de la etapa de Diseño del apartado VII (Productos a obtener) del presente documento.

e. PRODUCTO 5

A ser presentados a los 140 días calendario de iniciado el servicio, conteniendo la documentación de la etapa de codificación del apartado VII (Productos a obtener) del presente documento.

f. PRODUCTO 6

A ser presentados a los 170 días calendario de iniciado el servicio, conteniendo la documentación de la etapa de Carga de Contenidos del primer curso del apartado VII (Productos a obtener) del presente documento.

g. PRODUCTO 7

A ser presentados a los 210 días calendario de iniciado el servicio, conteniendo la documentación de la etapa de Pruebas y Despliegue del apartado VII (Productos a obtener) del presente documento.

Nota: Los entregables deberán ser presentados en un original y dos copias y en versión electrónica en CD, presentados 1 juego a la Oficina General de Estadística y Tecnologías de la Información y Comunicaciones y dos ejemplares a la Dirección General de Derechos Fundamentales, Seguridad y Salud en el Trabajo.

-31-

X. FORMA DE PAGO

Pago / Fecha Concepto Monto

1° pago a los cuarenta (40) días calendario desde el día siguiente de notificada la orden de servicio o suscrito el contrato.

Presentación de los productos 1 y 2 del acápite IX y acta de conformidad funcional extendida por la Dirección General de Derechos Fundamentales, Seguridad y Salud en el Trabajo y el acta de conformidad técnica expedida por la OTIC y OGETIC.

20% del monto a contratar

2° pago a los cien (100) días calendario desde el día siguiente de notificada la orden de servicio o suscrito el contrato.

Presentación de los productos 3 y 4 del acápite IX y acta de conformidad funcional extendida por la Dirección General de Derechos Fundamentales, Seguridad y Salud en el Trabajo y el acta de conformidad técnica expedida por la OTIC y OGETIC.

30% del monto a contratar

3° pago al ciento setenta (170) días calendario desde el día siguiente de notificada la orden de servicio o suscrito el contrato.

Presentación de los productos 5 y 6 del acápite IX y acta de conformidad funcional extendida por la Dirección General de Derechos Fundamentales, Seguridad y Salud en el Trabajo y el acta de conformidad técnica expedida por la OTIC y OGETIC.

20% del monto a contratar

4° pago a los doscientos diez (210) días calendario desde el día siguiente de notificada la orden de servicio o suscrito el contrato.

Presentación del producto 7 del acápite IX y acta de conformidad funcional extendida por la Dirección General de Derechos Fundamentales, Seguridad y Salud en el Trabajo y el acta de conformidad técnica expedida por la OTIC y OGETIC.

30% del monto a contratar

-32-

XI. SEGURIDAD Y CONFIDENCIALIDAD

El proveedor se compromete y obliga a no difundir a terceros la información

obtenida, bajo responsabilidad de las acciones legales pertinentes por parte de la

Entidad, en caso suceda lo contrario.

El proveedor mantendrá en forma reservada toda información suministrada por la

Entidad y al término del servicio, devolverá todos aquellos documentos que le

fueron proporcionados. Este incluye tanto material impreso como grabado en

medio magnético y/o digitalizado, asimismo, el proveedor deberá cumplir con

advertir y garantizar la confidencialidad y secreto de la información facilitada por

el MTPE a sus empleados y/o subcontratados, asociados y a cualquier persona

que, por su relación con el proveedor, deba tener acceso a dicha información para

el correcto cumplimiento de las obligaciones.

Toda la información y/o documentación generada como parte del servicio será de

propiedad exclusiva de la Entidad, no pudiendo el proveedor utilizarla fuera del

presente servicio.

El Proveedor deberá tener en cuenta los lineamientos de la Política Interna de

Seguridad de la Información del MTPE.

XII. PROPIEDAD INTELECTUAL

El postor no tendrá ningún título, patente u otros derechos de propiedad en los entregables, tales derechos pasarán plenamente y sin restricciones a ser propiedad del Ministerio de Trabajo y Promoción del Empleo.

XIII. CONFORMIDAD

La conformidad de los productos en cuanto a los requerimientos funcionales estará a cargo de Dirección General de Derechos Fundamentales, Seguridad y Salud en el Trabajo y los aspectos técnicos informáticos a cargo de la Oficina de Tecnologías de la Información y Comunicaciones y de la Oficina General de Estadística y Tecnologías de la Información.

XIV. SISTEMA DE CONTRATACION Sistema de contratación de suma alzada.

XV. RESPONSABILIDAD POR VICIOS OCULTOS El contratista es responsable por la calidad ofrecida y por los vicios ocultos del servicio

ofertado conforme a lo indicado en el Artículo 40° de la Ley 30225 Ley de

Contrataciones del Estado, por un plazo de 01 año contado a partir del día siguiente de

otorgada la conformidad por parte de la Entidad.

-33-

XVI. REQUISITOS DE CALIFICACION

A CAPACIDAD LEGAL – OBLIGATORIO

A.1 REPRESENTACIÓN Requisitos:

Documento que acredite el poder vigente del representante legal, apoderado o mandatario que rubrica la oferta.

En el caso de consorcios, este documento debe ser presentado por cada

uno de los integrantes del consorcio que suscribe la promesa de consorcio.

Promesa de consorcio con firmas legalizadas1, en la que se consigne los integrantes, el representante común, el domicilio común y las obligaciones a las que se compromete cada uno de los integrantes del consorcio así como el porcentaje equivalente a dichas obligaciones. (Anexo Nº 6)

La promesa de consorcio debe ser suscrita por cada uno de sus

integrantes.

Acreditación:

Copia de vigencia de poder expedida por registros públicos con una antigüedad no mayor de treinta (30) días calendario a la presentación de ofertas.

Promesa de consorcio con firmas legalizadas.

B CAPACIDAD TÉCNICA Y PROFESIONAL

B.1 SOPORTE

Requisito:

El postor deberá contar con un centro de gestión (NOC) en Perú el cual deberá poder brindar la atención de soporte técnico las 24 horas, los 365 días calendario.

Acreditación:

Declaración Jurada que cumple con este requerimiento.

C EXPERIENCIA DEL POSTOR

C.1 FACTURACIÓN

Requisito:

El postor debe acreditar un monto facturado acumulado equivalente a S/.

500,000.00 (Quinientos Mil 00/100 Soles), por la contratación de servicios

similares al objeto de la convocatoria y/o en la actividad, durante un periodo no

mayor a ocho (08) años a la fecha de presentación de oferta.

Acreditación:

Copia simple de contratos u órdenes de servicios, y su respectiva conformidad

por la prestación efectuada; o comprobantes de pago cuya cancelación se

acredite documental y fehacientemente, voucher de depósito, reporte de estado

de cuenta, cancelación en el documento, correspondientes a un máximo de

1 En caso de presentarse en consorcio.

-34-

veinte (20) contrataciones.

En caso los postores presenten varios comprobantes de pago para acreditar

una sola contratación, se debe acreditar que corresponden a dicha

contratación; de lo contrario, se asumirá que los comprobantes acreditan

contrataciones independientes, en cuyo caso solo se considerará, para la

evaluación, las veinte (20) primeras contrataciones indicadas en el Anexo Nº 7

referido a la Experiencia del Postor.

En el caso de servicios de ejecución periódica, solo se considera como

experiencia la parte del contrato que haya sido ejecutada a la fecha de

presentación de ofertas, debiendo adjuntarse copia de las conformidades

correspondientes a tal parte o los respectivos comprobantes de pago

cancelados.

En los casos que se acredite experiencia adquirida en consorcio, debe

presentarse la promesa de consorcio o el contrato de consorcio del cual se

desprenda fehacientemente el porcentaje de las obligaciones que se asumió en

el contrato presentado; de lo contrario, no se computará la experiencia

proveniente de dicho contrato.

Asimismo, cuando se presenten contratos derivados de procesos de selección

convocados antes del 20.09.2012, se entenderá que el porcentaje de las

obligaciones equivale al porcentaje de participación de la promesa de consorcio

o del contrato de consorcio. En caso que en dichos documentos no se consigne

el porcentaje de participación se presumirá que las obligaciones se ejecutaron

en partes iguales.

Cuando en los contratos, órdenes de servicios o comprobantes de pago el

monto facturado se encuentre expresado en moneda extranjera, debe indicarse

el tipo de cambio venta publicada por la Superintendencia de Banca, Seguros y

AFP correspondiente a la fecha de suscripción del contrato, de emisión de la

orden de servicios o de cancelación del comprobante de pago, según

corresponda.

Sin perjuicio de lo anterior, los postores deben llenar y presentar el Anexo Nº 7

referido a la Experiencia del Postor.

IMPORTANTE:

En el caso de consorcios, solo se considera la experiencia de aquellos integrantes que ejecutan conjuntamente el objeto materia de la convocatoria, previamente ponderada, conforme a la Directiva N° 002-2016-OSCE/CD “Participación de Proveedores en Consorcio en las Contrataciones del Estado”.