El suministro deberá incluir todos aquellos ítems que no hubiesen sido expresamente indicados en la presente sección, pero que pueda inferirse razonablemente que son necesarios para satisfacer el requisito de suministro indicado, por lo tanto, dichos bienes serán suministrados por el proveedor como si hubiesen sido expresamente mencionados, salvo disposición contraria en el contrato.

Los bienes suministrados deberán ajustarse a las especificaciones técnicas y las normas estipuladas en este apartado. En caso de que no se haga referencia a una norma aplicable, la norma será aquella que resulte equivalente o superior a las normas oficiales de la República del Paraguay. Cualquier cambio de dichos códigos o normas durante la ejecución del contrato se aplicará solamente con la aprobación de la contratante y dicho cambio se regirá de conformidad a la cláusula de adendas y cambios.

El proveedor tendrá derecho a rehusar responsabilidad por cualquier diseño, dato, plano, especificación u otro documento, o por cualquier modificación proporcionada o diseñada por o en nombre de la contratante, mediante notificación a la misma de dicho rechazo.

1. 1. Servicios Requeridos

El objetivo es de Diseño y Desarrollo de los Sistemas Informaticos de Trazabilidad de Procesos Judiciales

En base a los antecedentes del MTESS, se presentan a continuación los objetivos generales del proyecto.

Objetivos Generales

Diseño, desarrollo e implementación de un sistema de Gestión de Fiscalización

Diseño, desarrollo e implementación de un sistema de Sumarios administrativos en el Viceministerio de Trabajo del MTESS.

Diseño, desarrollo e implementación de un sistema de Procesos Judiciales en asesoría Jurídica como la generación de Multas y su cobro electrónico.

Objetivos Específicos

Se presentan a continuación los servicios esperados que corresponden a los objetivos específicos del servicio requerido

Servicios a ser efectuados	Descripción	Respaldo del Servicio	Personal Requerido para el servicio
Gestión Integral de las Fiscalizaciones in situ, por medio de una plataforma electrónica de las empresas y su situación actual en el MTESS, así como el seguimiento, legajos de intervenciones anteriores, enviando por un gestor documental para el proceso sumarial	Consiste en las intervenciones que hace la Dirección de Fiscalización, por diversas situaciones, que puede ser a pedido del Viceministerio por incumplimientos denunciados, intervenciones solicitadas por las autoridades, y que luego deben ser autorizadas en forma electrónica, por la cual este sistema deberá estar conectada online con el sistema  de Obrero patronal, Gremios, IPS e identificaciones y así poder cotejar in situ la situación actual de la empresa, elaborar actas, alzar documentos respaldatorios y proveer de estados del proceso en todo momento.	Documento digital con reportes, funcionamiento y operado por el personal ya capacitado de MTESS, incluyendo datos generados desde la base POSTGRESQL El documento deberá incluir las pruebas de generación de reportes, de al menos 10 días, de todos los procesos solicitados.	Expertos en SQL, PHP, Framework PhpRunner de al menos la versión 10.4 en adelante, experiencias en Webservices
Desarrollo de un sistema de sumarios administrativos que permitirá la trazabilidad en una plataforma electrónica de los expedientes que llegan desde diferentes lugares y poder emitir un certificado a las empresas de tener o no un sumario en la Web, en el Viceministerio de Trabajo.	Se refiere a todas las solicitudes de procesos de verificación y judiciales, tanto las anteriores como las denuncias hechas al mismo, verificando los antecedentes constatados por fiscalización, que acercará los documentos y este sistema estará conectado con todos los procesos hechos en las intervenciones hechas por los fiscalizadores, como así también acceder al sistema de fiscalización para verificar dichas evidencias. Además, deberá recibir otros documentos de denuncias, mediaciones y gremios para los procesos correspondientes para cada situación, teniendo como resultado un dictamen o resolución firmado electrónicamente, pasando por todas las dependencias que deben revisar y firmar, con la finalidad que el solicitante de un certificado de poseer o no un sumario administrativo, pueda obtener en forma electrónica desde la Web	Documento digital con la firma de las pruebas satisfactorias de los flujos integrados	Expertos en SQL, PHP, JavaScript, Framework PhpRunner de al menos la versión 10.4 en adelante, experiencias en Webservices, y Jasper Report
Gestión integral de los procesos judiciales de la asesoría Jurídica del MTESS	Consiste en recibir electrónicamente los procesos de los sistemas anteriores, ya sea por viceministerio, denuncias, fiscalización, para los procesos judiciales, debiendo dar seguimiento al mismo y luego retornar a las direcciones correspondientes con un dictamen electrónico firmado, que permita mayor fluidez en los procesos y en caso de existir cobro por multas, estas se puedan cargar, generando un extracto que luego se cobrara por medios de pagos electrónicos.	Integración con otros sistemas, dictámenes electrónicos, multas generadas y pagos por medios electrónicos.	Conocimiento de Entorno Web, PHP, Webservices, POSTGRESQL, Framework PhpRunner, Java, Rest API
Integración de Bases de datos del REOP, IPS e IDENTIFICACIONES	Esta integración consiste en conectar las otras bases de datos por medio de WebServices, al Servicio de Intercambio de Información por medio de la MITIC y a las bases de datos locales, para integrarlo en la plataforma	Documentación de los WebService, Manuales y el los Apis operando.	Webservices, POSTGRESQL, Framework PhpRunner, Java, Rest API
Integración del sistema de Gestión documental de expedientes de la mesa de entrada	Consiste en integrar al sistema de gestión de expediente que actualmente se encuentra funcionando, desde la mesa de entrada, para de esta manera aprovechar el seguimiento del expediente desde el recurrente	Por lo menos 3 Workflows	Desarrollador con experiencia en implementaciones de Workflow en PHPRUNNER
Implementación de un tablero de seguimiento y situaciones de los tramites	Elaboración y puesta en marcha de tableros que permitan el control de los tramites en líneas en proceso y finiquitaos, para de esta forma tomar decisiones correctas y oportunas	Por lo menos 5 WorkFlows	Desarrollador con experiencia en implementaciones de Tableros en PHPRUNNER

 

Actividades Incluidas en los servicios mencionados anteriormente para la prestación del servicio:

Todas las actividades deberán registrarse en los informes respectivos los cuales deberán ser aprobados por el contratante.

Para cada uno de los servicios de integración y actualización (servicios más arriba detallados), se deberá ejecutar considerando las siguientes condiciones:

 

Documentos de Planeación de cada Servicio y validación con el MTESS.

 

1. Documento con la especificación de los trabajos a ser realizados en cada Servicio incluyendo lugar de trabajo, horario en caso necesario, forma de registro de actividades, de registro de migraciones, de reportes de trabajo, de horas utilizadas y otros relevantes para lograr el adecuado registro de la volumetría y los Indicadores de éxito de cada Servicio.  Este documento deberá incluir el relevamiento de información sobre los sistemas a ser instalados incluyendo las documentaciones de las reuniones, visitas de campo, y documentos de los sistemas para avanzar en los entregables.

2. Documento con los requerimientos de acceso a Internet, muebles en caso que apliquen, pedidos de acceso a los sistemas, tablas, bases de datos y otros que requiere para realizar su trabajo.

3. Documento por cada Servicio con los casos de uso acordados, flujos, pantallas de experiencia de usuario, reportes acordados, módulos de control y log s de acceso.

4. Formulario de validación de los componentes de infraestructura ya existentes en el proyecto para su utilización para cada Servicio, el resultado de la validación deberá presentarse al contratante con el plan de mitigación en caso de presentarse observaciones o requisitos adicionales. De existir componentes faltantes de infraestructura, estos no deberían ser causales de interrupción del proyecto.

5. Documento con el plan de cumplimiento de niveles mínimos de servicio especificados y KPI de adopción o uso de los servicios respectivos.

6. Documento con el plan de capacitación a funcionarios usuarios del sistema una vez puesto en marcha el sistema.

7. Documento con Matriz de responsabilidades del proveedor y el MTESS

8. Documento con el cronograma de Trabajo con fechas, responsables y entregables concretos
9. Documento con los nombres y perfil del personal a ser designados, incluyendo su hoja de vida, experiencia en proyectos similares y disponibilidad de tiempo en hs dentro del cronograma.

 

1. 2. Requerimientos para el desarrollo de los sistemas de Trazabilidad de Procesos Judiciales

El oferente deberá desarrollar la solución  de tal manera que:

1. 1. 1. Tenga las siguientes características fundamentales:

Los distintos componentes solicitados deberán estar basados en las últimas versiones de las tecnologías para cada caso, así como las mejores prácticas de la industria.  

Para los servicios donde se solicitan desarrollos, una aplicación servidor en el backend escrita en un lenguaje de alta performance, pensada para este tipo de escenarios y usada en los sitios más importantes de Internet con un nivel de carga importante. El lenguaje a elegir deberá ser PHP y PHPRUnner en sus versiones 10.4 en adelante, explotando sus capacidades de concurrencia y al máximo. Deberá contar con la ayuda de un servidor HTTP. Se deberá escribir un conjunto de Web Services de tipo REST para evitar el overhead que impone el SOAP. Este backend deberá ser capaz de acceder a la información residente en base de datos relacionales (en principio PostgreSQL). Se debe usar HTTPS como protocolo de transporte de tal manera que las sesiones sean encriptadas con el protocolo TLS o SSL y autenticadas. Usará WebSockets de manera transparente. Además, para interacciones entre módulos independientes se deberá usar REDIS, para el intercambio de mensajes de carácter prioritario, y un bróker AMQP para los mensajes que puedan ser tratados en forma de cola. Es deseable el uso de GraphQL en el modelado final para que la mensajería con el frontend sea más eficiente.

La aplicación de frontend, que corre en el browser del cliente, debe estar escrita en PHP, HTML5, CSS, JavaScript, y consumirá las APIs de tipo REST que el backend dispone. Todos los gráficos, tablas y listados deberán usar librerías estándares de tal manera que los upgrades, o actualizaciones, posteriores puedan realizarse sin mayores inconvenientes. Esta aplicación deberá ser de tipo SPA (Single Page Application). Deberá disponer, además, de un canal Websocket para intercambio de mensajes de carácter prioritario.

El desarrollo de la solución debe ser realizado localmente y poseer soporte local especializado de tal manera que los tiempos de respuestas, en eventuales casos de problemas o en casos de necesidad de cambios urgentes, sean muy bajos. Como esta solución está disponiendo información que se producirá en línea y en tiempo real. Los conceptos de multithreading y/o non-blocking operations deben ser manejados de tal manera que esta plataforma no sea un cuello de botella para la solución completa una vez integrada a la plataforma de transacciones electrónicas.

Para los servicios donde aplique, los sistemas a desarrollar deberán ser modulares y escalables. Se deberán poder agregar módulos de información sin que esto afecte los módulos ya existentes. Se deberá poder mantener la performance si la carga de uso se triplica con respecto a la existente. Esto implica una relación muy estrecha del software de backend, principalmente, con el hardware, sistema operativo y fine tunning del servidor. Los recursos hardware deberán ser elegidos cuidadosamente para tal efecto. Además, en los servicios donde aplique, se solicita el uso de un sistema operativo open source de tipo Linux, Centos 6.9 o Ubuntu 16, toda vez que sea la última versión de la misma y este optimizada para el servicio que se va a prestar. Así también, el ancho de banda a requerir por el servicio deberá ser elegido de tal manera que complemente el servicio completo con relación a la performance.

 

Para los servicios donde aplique, se deberá proveer una solución de infraestructura de microservicios basada en Arquitectura Apache, con balanceo de carga del sistema, esperada o evaluada en tiempo real.

Para los servicios donde aplique, para la infraestructura tecnológica se deberán usar todas herramientas de open source.

El estilo de arquitectura provea lo siguiente:

 

1. 1. 1. 1. Escalabilidad de la interacción con los componentes. Para los servicios donde aplique, la solución debe poder crecer exponencialmente sin degradar su rendimiento. Una variedad de clientes deberán poder acceder ya sea desde estaciones de trabajo, o dispositivos móviles, etc.
         2. Generalidad de interfaces. Para los servicios donde aplique, cualquier cliente deberá poder interactuar con el servidor HTTP sin ninguna configuración especial.
         3. Puesta en funcionamiento independiente. Donde aplique, la solución deberá prever que los clientes y servidores puedan ser puestos en funcionamiento a lo largo de años. Por tanto, la solución deberá permitir que los servidores antiguos sean capaces de entenderse con clientes actuales y viceversa. Se debe utilizar un protocolo que permita este tipo de características.
         4. Compatibilidad con componentes intermedios. Para los servicios que aplique, la solución deberá ser compatible con los más populares intermediarios, como lo son varios tipos de proxys para Web. En especial aquellos que se utilizan para mejorar el rendimiento u otros que permiten reforzar las políticas de seguridad, como firewalls o gateways (o pasarelas que permiten encapsular sistemas No Web). Ésta compatibilidad con intermediarios deberá permitir reducir la latencia de interacción, reforzar la seguridad y encapsular otros sistemas.

Acceso a las bases de datos debe considerar:

Para el acceso a las bases de datos relacionales se deberá usar un ORM (Object Relational Mapping) y para las bases de datos NoSQL debe usarse un ODM (Object Document Mapping).

Creación, temprana, de un mapa de base de datos para identificar los dueños de los datos o tablas, temas de sintaxis y semántica. El mismo deberá ser parte obligatoria del entregable final como parte de la documentación técnica del proyecto.

 

Para los servicios donde aplique, el modelado de las APIs:

Los APIs deberán ser modelados de acuerdo a los métodos HTTP más importantes, que son PUT, GET, POST y DELETE. Suelen ser comparados con las operaciones asociadas a la tecnología de base de datos, operaciones CRUD: CREATE, READ, UPDATE, DELETE. Las acciones (verbos) CRUD se diseñan para operar con datos atómicos dentro del contexto de una transacción con la base de datos. REST se diseña alrededor de transferencias atómicas de un estado más complejo, tal que puede ser visto como la transferencia de un documento estructurado de una aplicación a otra.

El protocolo HTTP separa las nociones de un servidor y un navegador. Esto permite a la implementación de cada uno variar uno del otro, basándose en el concepto cliente/servidor. Cuando utilizamos REST, HTTP no tiene estado. Cada mensaje contiene toda la información necesaria para comprender la petición cuando se combina el estado en el recurso. Como resultado, ni el cliente ni el servidor necesita mantener ningún estado en la comunicación. Cualquier estado mantenido por el servidor debe ser modelado como un recurso.

La restricción de no mantener el estado puede ser violada mediante cookies que mantienen las sesiones pero se advierte sobre el riesgo a la privacidad y seguridad que frecuentemente surge de su uso, así como la confusión y errores que pueden resultar de las interacciones entre cookies y el uso del botón Go back del navegador. Se debe evitar el uso de cookies, salvo justificación plena.

1. 1. 5. Para los servicios donde aplique, las pautas a seguir en el diseño de estos servicios Web solicitados basados en REST:

• Identificar todas las entidades conceptuales que se desean exponer como servicio.

• Crear una URL para cada recurso. Los recursos deberían ser nombres no verbos (acciones). Por ejemplo no utilizar esto: http://www.service.com/entities/getEntity?id=001. Como podemos observar, getEntity es un verbo. Mejor utilizar el estilo REST, un nombre: http://www.service.com/entities/001.

• Categorizar los recursos de acuerdo con si los clientes pueden obtener una representación del recurso o si pueden modificarlo. Para el primero, se debe hacer los recursos accesibles utilizando un HTTP GET. Para el último, se debe hacer los recursos accesibles mediante HTTP POST, PUT y/o DELETE.

• Todos los recursos accesibles mediante GET no deberían tener efectos secundarios. Es decir, los recursos deberían devolver la representación del recurso. Por tanto, invocar al recurso no debería ser el resultado de modificarlo.

 

Acción	HTTP	SQL	Copy&Paste	Unix Shell
Create	PUT	Insert	Pegar	>
Read	GET	Select	Copiar	<
Update	POST	Update	Pegar después	>>
Delete	DELETE	Delete	Cortar	Del/rm

 

• Ninguna representación debería estar aislada. Es decir, es recomendable poner hipervínculos dentro de la representación de un recurso para permitir a los clientes obtener más información.

• Especificar el formato de los datos de respuesta mediante un esquema (DTD,W3C Schema, ). Para los servicios que requieran un POST o un PUT es aconsejable también proporcionar un esquema para especificar el formato de la respuesta.

• Describir como nuestro servicio ha de ser invocado, mediante un documento WSDL/WADL o simplemente HTML.

 

En la documentación, las APIs deben ser presentadas de esta forma:

 

Titulo

El nombre de la llamada API

Ejemplo: Mostrar Todos Los Usuarios

 

URL

La estructura de la URL (solo el path)

/users or /users/:id or /users?id=:id

 

Método

El tipo de petición

GET | POST | DELETE | PUT

 

Parámetros de la URL

Requerido:

id=[entero]

ejemplo: id=12

Opcional:

photo_id=[alfanumerico]

ejemplo: photo_id=2345kj3

 

Parámetros de Datos (en el cuerpo)

Ejemplo:

{

 u : {

 email : [cadena],

 name : [cadena],

 current_password : [alfanumerico]

 password : [alfanumerico],

 password_confirmation : [alfanumerico]

 }

}

{

 u : {

 email : "john@smith.com",

 name : "John",

 current_password : "apassw0rd"

 password : "anewpassw0rd",

 password_confirmation : "anewpassw0rd"

 }

}

Respuesta Exitosa

Que valores esperar.

Example:

Code: 200

Content: { id : 12 }

Respuesta de Error

Que valores esperar.

Example:

Code: 401 NO AUTORIZADO

Content: { error : "Autenticacion" }

OR

Code: 422 Input no procesable

Content: { error : "Email invalido" }

 

Como deben ser los datos de entrada y salida:

 

En todos los casos los datos deben ser expresados en el formato JSON, que es un formato para el intercambio de datos. Básicamente JSON describe los datos con una sintaxis dedicada que se usa para identificar y gestionar los datos. Una de las mayores ventajas que tiene el uso de JSON es que puede ser leído por cualquier lenguaje de programación. Por lo tanto, puede ser usado para el intercambio de información entre distintas tecnologías.

 

JSON Nombre/Par de Valores

Para asignar a un nombre un valor se deberá usar los dos puntos ‘:’, este separador es el equivalente al igual ('=') de cualquier lenguaje.

 

"Nombre": Juan Pedro"

 

Valores JSON

Los tipos de valores que podemos encontrar en JSON son los siguientes:

 

Un número (entero o float)

Un string (entre comillas simples)

Un booleano (true o false)

Un array (entre corchetes [] )

Un objeto (entre llaves {})

Null

 

Objetos JSON

Los objetos JSON se identifican entre llaves

{ "NombreFruta":"Manzana", "Cantidad":20 }

 

Arrays JSON

En un JSON se pueden incluir arrays, para ellos el contenido del array debe ir entre corchetes []:

{

"Frutas": [

{ "NombreFruta":"Manzana", "cantidad":10 },

{ "NombreFruta":"Pera", "cantidad":20 },

{ "NombreFruta":"Naranja", "cantidad":30 }

]

}

 

Requerimientos para el desarrollo Tableros o Dashboards:

1. 1. Cada dashboard debe ser diseñado para un público específico,
   2. Cada dashboard debe proveer una vista de un área o tema específico,
   3. Cada dashboard debe proveer un entendimiento relevante para el público para el cual fue creado,
   4. Cada dashboard debe ser del tipo (estratégico, analítico u operacional), de acuerdo al público para el cual fue creado,
   5. Cada dashboard debe poder visualizarse en una única pantalla.
   6. El diseño de cada dashboard deberá estar basado en la importancia de cada reporte incluido en él, y ordenado, de mayor a menor, según su relevancia.
   7. El dashboard debe ser fácil de entender por el público para el cual fue creado.
   8. Se debe asegurar la consistencia en la información desplegada en los diversos dashboards, y
   9. Se debe asegurar la veracidad y confiabilidad  por medio de una certificación de los datos presentados en todos los dashboards.

 

 

UNIDAD SOLICITANTE: Ing. Ruben González, Director de la TIC's del Ministerio del Trabajo Empleo y Seguridad Social.

NECESIDAD: Se requiere sistematizar los procesos a fin de permitir un registro y ordenamiento de los procesos del area de Procesos Sumarios y Judiciales del MTESS:

PLANIFICACION: La presente es el resultado de procesos sucesivos efectuados por el MTESS en el area de sistemas.

JUSTIFICACION DE EETT: Están establecidas y desarrolladas en base al requerimiento institucional y producto de un analisis de los servicios disponibles en el mercado.

NO APLICA

SEGUN ORDEN DE SERVICIO EMITIDA POR EL DIRECTOR DE TIC'S CONJUNTAMENTE CON EL DIRECTOR GENERAL DE LA DGAF. LOS SERVICIOS DEBERAN INICIARSE COMO MAXIMO A LAS 48 HORAS DE LA RECEPCION DE LA ORDEN DE SERVICIO RESPECTIVA.

No aplica

No aplica

No aplica

Planificación de indicadores de cumplimiento:

INDICADOR	TIPO	FECHA DE PRESENTACIÓN PREVISTA (se indica la fecha que debe presentar según el PBC)
Informe de Ejecución 1	Informe Interno	a los 6 Meses del Inicio de los Servicios
Informe de Ejecución 2	Informe Interno	Como máximo a los 5 dias posteriores a la finalizacion del servicio

 

La convocante adjudicará el contrato al oferente cuya oferta haya sido evaluada como la más baja y cumpla sustancialmente con los requisitos de las bases y condiciones, siempre y cuando la convocante determine que el oferente está calificado para ejecutar el contrato satisfactoriamente.

1. La adjudicación en los procesos de contratación en los cuales se aplique la modalidad de contrato abierto, se efectuará por las cantidades o montos máximos solicitados en el llamado, sin que ello implique obligación de la convocante de requerir la provisión de esa cantidad o monto durante la vigencia del contrato, obligándose sí respecto de las cantidades o montos mínimos establecidos.

2. En caso de que la convocante no haya adquirido la cantidad o monto mínimo establecido, deberá consultar al proveedor si desea ampliarlo para el siguiente ejercicio fiscal, hasta cumplir el mínimo.

3. Al momento de adjudicar el contrato, la convocante se reserva el derecho a disminuir la cantidad requerida, por razones de disponibilidad presupuestaria u otras razones debidamente justificadas. Estas variaciones no podrán alterar los precios unitarios u otros términos y condiciones de la oferta y de los documentos de la licitación.

En aquellos llamados en los cuales se aplique la modalidad de contrato abierto, cuando la convocante deba disminuir cantidades o montos a ser adjudicados, no podrá modificar el monto o las cantidades mínimas establecidas en las bases de la contratación.

La comunicación de la adjudicación a los oferentes será como sigue:

1. Dentro de los cinco (5) días corridos de haberse resuelto la adjudicación, la convocante comunicará a través del Sistema de Información de Contrataciones Públicas, copia del informe de evaluación y del acto administrativo de adjudicación, los cuales serán puestos a disposición pública en el referido sistema. Adicionalmente el sistema generará una notificación a los oferentes por los medios remotos de comunicación electrónica pertinentes, la cual será reglamentada por la DNCP.

2. En sustitución de la notificación a través del Sistema de Información de Contrataciones Públicas, las convocantes podrán dar a conocer la adjudicación por cédula de notificación a cada uno de los oferentes, acompañados de la copia íntegra del acto administrativo y del informe de evaluación. La no entrega del informe en ocasión de la notificación, suspende el plazo para formular protestas hasta tanto la convocante haga entrega de dicha copia al oferente solicitante.

3. En caso de la convocante opte por la notificación física a los oferentes participantes, deberá realizarse únicamente con el acuse de recibo y en el mismo con expresa mención de haber recibido el informe de evaluación y la resolución de adjudicación.

4. Las cancelaciones o declaraciones desiertas deberán ser notificadas a todos los oferentes, según el procedimiento indicado precedentemente.

5. Las notificaciones realizadas en virtud al contrato, deberán ser por escrito y dirigirse a la dirección indicada en el contrato.

Una vez notificado el resultado del proceso, el oferente tendrá la facultad de solicitar una audiencia a fin de que la convocante explique los fundamentos que motivan su decisión.

La solicitud de audiencia informativa no suspenderá ni interrumpirá el plazo para la interposición de protestas.

La misma deberá ser solicitada dentro de los dos (2) días hábiles siguientes en que el oferente haya tomado conocimiento de los términos del Informe de Evaluación de Ofertas.

La convocante deberá dar respuesta a dicha solicitud dentro de los dos (2) días hábiles de haberla recibido y realizar la audiencia en un plazo que no exceda de dos (2) días hábiles siguientes a la fecha de respuesta al oferente.