INFORME DEL TERCER PRODUCTO DE LA CONSULTORÍA · 2.1.1 Dimensionamiento de la carga de usuarios y transaccionalidad del SIIGETH 2 ... para ser finalmente presentados en el cuarto

INFORME DEL TERCER PRODUCTO DE LACONSULTORÍA

Dimensionamiento del SIIGETH

Listado de integraciones y modelo esencial de integración

Directrices arquitectónicas y tecnológicas el modelo esencial de integración

Recomendaciones de estrategia de implementación de la solución

Especificación de los componentes que deberá implementar el SIIGETH

Recomendaciones para el despliegue de las fases

Requerimientos técnicos de la solución

Presentada por:

Ing. Dustin Ghia, CSD

INFORME TÉCNICO, AGOSTO 2015

Contenido

1 Introducción ................................................................................................................ 1

2 Dimensionamiento del SIIGETH ................................................................................. 2

2.1 Dimensionamiento estimado con base en proyecciones...................................... 2

2.1.1 Dimensionamiento de la carga de usuarios y transaccionalidad del SIIGETH

2

2.1.2 Dimensionamiento del volumen de los datos que almacenará el SIIGETH en

relación al volumen de datos almacenados del SIITH............................................... 10

2.1.3 Dimensionamiento de la infraestructura física que deberá soportar al

SIIGETH ................................................................................................................... 11

2.1.4 Definición de las capacidades de conectividad del SIIGETH ...................... 14

2.1.5 Definición del software base y de los lineamientos para la calidad del

producto15

2.1.6 Resumen del dimensionamiento del SIIGETH con base en la estimación

realizada sobre las fuentes levantadas ..................................................................... 16

2.2 Dimensionamiento presentado por proveedores de paquetes comerciales y de

infraestructura .............................................................................................................. 17

2.3 Análisis y comparación del dimensionamiento estimado con respecto al realizado

por los proveedores...................................................................................................... 18

2.4 Requisitos para las opciones de aprovisionamiento de la infraestructura .......... 21

3 Listado de integraciones y modelo esencial de integración....................................... 24

3.1 Listado de integraciones.................................................................................... 24

3.2 Modelo esencial de datos e integración............................................................. 29

4 Recomendaciones de estrategia de implementación de la solución.......................... 32

5 Componentes y requisitos técnicos de la solución .................................................... 33

5.1 Definición de los componentes que debe implementar el SIIGETH ................... 33

5.1.1 Componentes comunes.............................................................................. 33


5.1.2 Componentes para acceso a datos ............................................................ 34

5.1.3 Componentes core ..................................................................................... 34

5.1.4 Componentes para ruteo y transformación de mensajes internos............... 35

5.1.5 Componentes para ejecución de procesos de negocio automatizados....... 36

5.1.6 Componentes para ejecución de reglas de negocio.................................... 36

5.1.7 Componentes de publicación...................................................................... 36

5.1.8 Componente gestor de documentos ........................................................... 36

5.1.9 Herramientas.............................................................................................. 36

5.2 Directrices tecnológicas Generales.................................................................... 38

6 Elaboración de las recomendaciones para la entrega y despliegue por fases del

SIIGETH .......................................................................................................................... 40

7 Elaboración de los requerimientos técnicos del SIIGETH ......................................... 44

8 Anexos ..................................................................................................................... 45

8.1 Propuestas enviadas por los proveedores de infraestructura............................. 45

8.1.1 COMWARE ................................................................................................ 45

8.1.2 ANDEAN-TRADE ....................................................................................... 47

8.1.3 SINERGY-HARD ........................................................................................ 50

8.2 TABULACION_FINAL_DE_ECUESTAS (formato digital) .................................. 51

8.3 COMPARACION_TECNICA_DE_OPCIONES-v1.2.xlsx (formato digital) .......... 52

8.4 ESTIMACION_Y_ANALISIS_DE_COSTOS-v1.6.xlsx (formato digital) .............. 52

8.5 ANALISIS_RIESGO-v1.3.xlsx (formato digital) .................................................. 52

8.6 COMPARACION_ALTERNATIVAS_IMPLANTACION_SIIGETH-v1.10.pptx

(formato digital) ............................................................................................................ 52

8.7 TDR-1.0 (formato digital) ................................................................................... 52

8.8 PRIORIZACION_PROCESOS_SIIGETH-v2.0.xlsx (formato digital) .................. 52

8.9 MATRIZ_INFRAESTRUCTURA_SIITH.xlsx (formato digital) ............................. 52

8.10 CALCULO_DE_DIMIENSIONAMIENTO-v1.1.xlsx (formato digital) ................... 52

8.11 Choosing_the_right_fron_end_framework-2013.pdf (formato digital) ................. 52


8.12 Perfiles mínimos recomendados para los equipos de desarrollo para la opción de

desarrollo a medida de la solución ............................................................................... 52


1

1 IntroducciónLa definición formal del Ministerio de Trabajo para la implementación e implantación del

SIIGETH es que sea desarrollado por un contratista externo en estrecha colaboración con una

contraparte institucional, este lineamiento constituye la base angular de los trabajos

subsiguientes, como es el caso de lo desplegado en el presente informe.

La arquitectura referencial para el proyecto se encuentra definida en el segundo informe de la

presente consultoría, mientras que los lineamientos tecnológicos a considerarse para

dimensionar al SIIGETH han sido un insumo intercambiado entre el proyecto y proveedores de

soluciones, infraestructura y plataforma, de los cuales se han recibido dimensionamientos y

propuestas técnicas y económicas.

Se define un modelo esencial de integración que incluye lineamientos de implementación y

para la tecnología subyacente.

La especificación de componentes que el SIIGETH deberá incluir se encuentra inicialmente

propuesta en el segundo informe, mientras que en el presente documento se establecen dichos

componentes como un lineamiento a considerarse dentro de los términos de referencia no

funcionales.

Con base en la información presentada en las secciones anteriores y en los informes

anteriores, se establece los términos de referencia no funcionales iniciales del SIIGETH, los

cuales serán completados y perfeccionados a través de intercambios y talleres de trabajo con

posibles oferentes, para ser finalmente presentados en el cuarto y último informe de la presente

consultoría.


2

2 Dimensionamiento del SIIGETH

2.1 Dimensionamiento estimado con base en proyeccionesEl dimensionamiento de sistemas de información se determina por dos variables:

1. Tecnología y funciones de las aplicaciones

2. Carga con la que van a trabajar dichas aplicaciones

Tomando en cuenta estos dos factores y las métricas definidas en el primer producto de la

consultoría, en este producto se dimensiona al SIIGETH en función del SIITH1. La estimación

se realiza para proyectar:

• La carga de usuarios y transaccionalidad del SIIGETH (2.1.1)

• Volumen de almacenamiento de datos (2.1.2)

• Infraestructura física (2.1.3)

• Condiciones de conectividad y calidad de servicio (2.1.4)

Además de las estimaciones indicadas, se plantean los tópicos de base sobre los cuales se

debe elaborar el requerimiento no funcional del SIIGETH con respecto a la Calidad del producto

de software.

Los insumos para realizar el dimensionamiento del SIIGETH fueron:

• La matriz de infraestructura (Anexo MATRIZ_INFRAESTRUCTURA_SIITH-v2.0.xlsx

(formato digital))

• Las encuestas realizadas a 174 instituciones públicas (Anexo

TABULACION_FINAL_DE_ECUESTAS (formato digital))

2.1.1 Dimensionamiento de la carga de usuarios y transaccionalidad del SIIGETH

2.1.1.1 Comparación del número de procesos implementados por el SIITH en relación alos que implementará el SIIGETH

Para determinar los procesos que implementará el SIIGETH en relación a los que implementa

el SIITH, se toma como insumo el Anexo PRIORIZACION_PROCESOS_SIIGETH-v2.0.xlsx

(formato digital).

1 El SIITH es un conjunto de aplicaciones JEE5 sobre bases de datos PostgreSQL. Un análisis amplioacerca de las características del SIITH se despliega en el segundo informe de la presente consultoría.


3

2-1 Mapeo de procesos SIITH y SIIGETH

ID DENOMINACIÓN TIPO SIITH SIIGETH1 GESTIÓN DE REGISTRO DE LA INFORMACIÓN INSTITUCIONAL SUBSISTEMA 9 162 GESTIÓN DE CATASTRO INSTITUCIONAL MÓDULO 4 53 Registro de Institución COMPONENTE 1 1

Creación y Validación de Institución COMPONENTE 0 14 Registro y Actualización de institución y unidad desconcentrada/ejecutora COMPONENTE 1 15 Actualización de información de la Institución COMPONENTE 1 16 Eliminación de la Institución COMPONENTE 1 17 GESTIÓN DE ESTRUCTURA ORGANIZACIONAL MÓDULO 2 68 Elaboración del proyecto de estatuto de gestión organizacional COMPONENTE 0 19 Reforma de estatuto de gestión organizacional COMPONENTE 0 1

10 Aprobación y registro del proyecto de estatuto orgánico COMPONENTE 0 111 Registro de estatuto de gestión organizacional COMPONENTE 1 112 Carga masiva de estatuto de gestión organizacional COMPONENTE 0 113 Actualización de información de estatuto de gestión organizacional COMPONENTE 1 114 GESTIÓN DE EXPEDIENTE MÓDULO 3 515 Registro de ficha personal COMPONENTE 1 116 Carga masiva de ficha personal COMPONENTE 1 117 Registro de historia laboral COMPONENTE 1 118 Actualización automática de carga laboral - IESS y otras instituciones cambio trabajo COMPONENTE 0 119 Generación de certificados de trabajo COMPONENTE 0 120 GESTIÓN DE PLANEACIÓN DEL TTHH SUBSISTEMA 1 1521 DESCRIPCIÓN, VALORACIÓN Y CLASIFICACIÓN DE PUESTOS MÓDULO 0 622 Elaboración del proyecto de descripción del perfil de puestos COMPONENTE 0 123 Elaboración del proyecto de valoración y clasificación de puestos COMPONENTE 0 124 Aprobación del proyecto de descripción, valoración y clasificación de puestos COMPONENTE 0 125 Registro de manual de puestos COMPONENTE 0 126 Actualización del manual de descripción, valoración y clasificación de puestos COMPONENTE 0 127 Implementación del manual de descripción, valoración y clasificación de puestos COMPONENTE 0 128 PLANIFICACIÓN DE TALENTO HUMANO MÓDULO 1 929 Diagnóstico de la situación actual de talento humano COMPONENTE 0 130 Elaboración de la plantilla óptima COMPONENTE 0 1


4

31 Elaboración de la planificación de talento humano COMPONENTE 0 132 Aprobación de la planificación de talento humano COMPONENTE 0 133 Elaboración del plan de desvinculación COMPONENTE 0 134 Actualización de la planificación de talento humano COMPONENTE 0 1

Registro de puestos COMPONENTE 1 135 Creación de puestos (Dispara evento para ingreso de información básica en

descripción, valoración y clasificación, y se recupera el puesto para actualización )COMPONENTE 0 1

36 Supresión de puestos COMPONENTE 0 137 GESTIÓN DE EMPLEO SUBSISTEMA 3 2438 SELECCIÓN DE PERSONAL MÓDULO 1 339 CONCURSOS COMPONENTE 1 140 SELECCIÓN SERVICIOS OCASIONALES COMPONENTE 0 141 SELECCIÓN NJS, SERVICIOS OCASIONALES Y C.T., OTROS COMPONENTE 0 142 VINCULACIÓN DE PERSONAL MÓDULO 1 543 Validación de requisitos COMPONENTE 0 1

Registro de vinculación COMPONENTE 1 144 Elaboración y registro del documento de vinculación laboral COMPONENTE 0 145 Registro y notificación a sistemas de otras instituciones COMPONENTE 0 146 Ejecución de la inducción COMPONENTE 0 147 DESVINCULACIÓN DE PERSONAL MÓDULO 1 848 Registro de la desvinculación COMPONENTE 1 148 Supresión de puestos COMPONENTE 0 149 Retiro obligatorio (jubilación) COMPONENTE 0 150 Retiro voluntario COMPONENTE 0 151 Compra de renuncia COMPONENTE 0 152 Renuncia voluntaria COMPONENTE 0 153 Aprobación de documentación de desvinculación COMPONENTE 0 154 Ejecución del proceso de desvinculación COMPONENTE 0 155 MOVIMIENTOS DE PERSONAL MÓDULO 0 856 Comisiones de servicios con y sin remuneración COMPONENTE 0 157 Subrogaciones y encargos COMPONENTE 0 158 Traslado administrativo COMPONENTE 0 159 Traspaso de puestos COMPONENTE 0 160 Cambio administrativo COMPONENTE 0 161 Vacaciones COMPONENTE 0 1


5

62 Licencias y permisos con y sin remuneración COMPONENTE 0 163 Intercambio voluntario de puestos COMPONENTE 0 164 GESTIÓN DEL RENDIMIENTO Y DESARROLLO SUBSISTEMA 0 1465 EVALUACIÓN DE DESEMPEÑO MÓDULO 0 566 Planificación de la evaluación del desempeño COMPONENTE 0 167 Ejecución de la evaluación del desempeño COMPONENTE 0 168 Apelación de la evaluación del desempeño COMPONENTE 0 169 Elaboración de plan de acción COMPONENTE 0 170 Seguimiento de planes de acción COMPONENTE 0 171 FORMACIÓN Y CAPACITACIÓN MÓDULO 0 872 Elaboración del plan de formación y capacitación COMPONENTE 0 173 Ejecución de plan de formación y capacitación COMPONENTE 0 174 Ejecución de eventos no programados COMPONENTE 0 175 Control de ausencia por capacitación y asistencia COMPONENTE 0 176 Evaluación de la eficacia de la capacitación COMPONENTE 0 177 Convenios de devengación COMPONENTE 0 178 Registro de capacitadores y operadoras de capacitación COMPONENTE 0 179 Pago de honorarios de instructores y capacitadores COMPONENTE 0 180 PLAN CARRERA COMPONENTE 0 181 GESTION DE RELACIONES HUMANAS Y SOCIALES SUBSISTEMA 0 282 Evaluación al clima organizacional COMPONENTE 0 183 Elaboración e implementación de planes de acción para apoyo al clima

organizacionalCOMPONENTE 0 1

84 GESTION DISCIPLINARIA SUBSISTEMA 0 485 Elaboración del reglamento interno de administración del talento humano COMPONENTE 0 186 Registro y actualización de sanciones administrativas y/o jurídicas COMPONENTE 0 187 Gestión de sanciones disciplinarias internas COMPONENTE 0 188 Gestión de la ética COMPONENTE 0 189 GESTIÓN DE LA COMPENSACIÓN, BIENESTAR Y SALUD SUBSISTEMA 2 2490 GESTIÓN DEL TIEMPO MÓDULO 0 591 Administración de jornadas de trabajo COMPONENTE 0 192 Control de asistencia COMPONENTE 0 193 Carga masiva de control de asistencia COMPONENTE 0 194 Cálculo y aprobación de horas suplementarias y extraordinarias COMPONENTE 0 1


6

95 Cálculo de saldos de días de ausencia COMPONENTE 0 196 RETRIBUCIÓN MONETARIA Y NO MONETARIA MÓDULO 2 1697 Cálculo de nómina COMPONENTE 0 198 Indemnización, compensación y liquidación de haberes COMPONENTE 0 199 Ingresos Complementarios COMPONENTE 0 1

100 Décimos COMPONENTE 0 1101 Registro de valores por viáticos, subsistencias y movilización COMPONENTE 0 1102 Gestión de Viáticos, subsistencias y movilización COMPONENTE 0 1103 Horas suplementarias y extraordinarias COMPONENTE 0 1104 Subrogaciones y encargos COMPONENTE 0 1105 Honorarios de capacitación COMPONENTE 0 1106 Remuneración variable por eficiencia COMPONENTE 1 1107 Registro de valor de RVE COMPONENTE 1 1108 Viáticos por residencia COMPONENTE 0 1109 Beneficios no monetarios COMPONENTE 0 1110 Fondos de reserva COMPONENTE 0 1111 Indemnización por accidente de trabajo o enfermedad profesional COMPONENTE 0 1112 Bonificación geográfica COMPONENTE 0 1113 SEGURIDAD Y SALUD EN EL TRABAJO MÓDULO 0 0114 Elaboración de la planificación de seguridad y salud COMPONENTE 0 0115 Aprobación del reglamento de seguridad y salud en el trabajo COMPONENTE 0 0116 Diagnóstico de la condición de trabajo, salud y vida del centro de Trabajo. COMPONENTE 0 0117 Condición de salud y vida COMPONENTE 0 0118 Prevención, promoción y protección COMPONENTE 0 0119 Exámenes pre ocupacionales y determinación de epidemiología laboral COMPONENTE 0 0120 Monitoreo de procesos peligrosos en la fuente, medio y trabajador COMPONENTE 0 0121 Seguimiento al ambiente de trabajo seguro y saludable, e investigación de

accidentesCOMPONENTE 0 0

122 Generación de reportes de accidentes de trabajo COMPONENTE 0 0123 BIENESTAR LABORAL MÓDULO 0 3124 Registro de ficha de bienestar laboral COMPONENTE 0 1125 Elaboración y ejecución del plan de bienestar laboral COMPONENTE 0 1126 Reconocimientos y estímulos COMPONENTE 0 1127 GESTIÓN DE CONTROL Y SEGUIMIENTO MDT SUBSISTEMA 0 11128 Evaluación del riesgo MÓDULO 0 3


7

129 Identificación del Riesgo COMPONENTE 0 1130 Análisis de riesgos COMPONENTE 0 1131 Evaluación de riesgo COMPONENTE 0 1132 Planificación del control MÓDULO 0 3133 Determinación del perfil de riesgos críticos COMPONENTE 0 1134 Definición de sujetos de control COMPONENTE 0 1135 Planificación del control COMPONENTE 0 1136 Tratamiento del control MÓDULO 0 2137 Inspección de campo y de escritorio COMPONENTE 0 1138 Elaboración de planes de mejora regulatorios COMPONENTE 0 1139 Gestión de resultados MÓDULO 0 2140 Seguimiento de planes de mejora COMPONENTE 0 1141 Elaboración de informes y comunicación de resultados COMPONENTE 0 1142 Gestión de la calidad MÓDULO 0 1143 Certificación de la calidad COMPONENTE 0 1


8

El conteo derivado de la tabla 2-1 Mapeo de procesos SIITH y SIIGETH, indica que el número

de procesos/subprocesos totales cubiertos por el SIITH es 15, mientras que para el SIIGETHes 110, de los cuales únicamente 99 son globales, pues los 11 procesos de control sólo

se implementan en el MDT por ser el ente rector a nivel nacional.

2.1.1.2 Dimensionamiento de la carga de usuarios potenciales del SIIGETHAsí como se requiere establecer la cantidad de procesos que implementará el SIIGETH en

relación a los actualmente implementados por el SIITH, se necesita establecer el número de

usuarios potenciales de la solución, para lo cual se usan como insumos el alcance del SIIGETH

indicado en el Modelo Conceptual, y las encuestas realizadas a las instituciones públicas para

obtener información sobre el uso actual del SIITH.

En el alcance del SIIGETH, se indica la composición y número de usuarios esperados para la

solución, lo cual se muestra en la taba 2-2 Clasificación de usuarios esperados para el

SIIGETH, en donde se indica además el tiempo neto de conexión (uso) que cada tipo de

usuario le daría al SIIGETH. Esta información fue compartida a los proveedores de paquetes

comerciales y de infraestructura que participaron en el estudio de mercado que se expone en la

sección Dimensionamiento presentado por proveedores de paquetes comerciales y de

infraestructura.

2-2 Clasificación de usuarios esperados para el SIIGETH

Tipo Descripción Número de usuariosestimados

Uso neto en tiempo deconexión

Gestores Servidores miembros de las UATHinstitucionales 5245 100%

Administradores Administradores del SIIGETH encada UATH 174 25%

AprobadoresServidores con responsabilidad deaprobación de trámitesgenerados

19000 75%

Estratégicos Máximas autoridades de cadainstitución 400 5%

Tácticos Nivel jerárquico que no incluye alas máximas autoridades 700 2%

Autoservicio Servidores públicos de cadainstitución 524595 3%

Aparte de la información dada como alcance del SIIGETH (tabla 2-2 Clasificación de usuarios

esperados para el SIIGETH), a fin de estimar la carga y uso transaccional que podría llegar a


9

tener el SIIGETH, se tomaron en cuenta los resultados de las encuestas realizadas a 132

instituciones públicas, de las cuales únicamente 75 contestaron la información solicitada en

relación al uso y número de usuarios de los aplicativos que el MDT proporciona.

Los resultados de las encuestas (Anexo TABULACION_FINAL_DE_ECUESTAS (formato

digital)) indican que en las 75 instituciones, existirían aproximadamente 1402 conexiones

concurrentes a las aplicaciones del SIITH, lo cual se contrasta con el número de servidores de

las UATH de las 75 instituciones citadas, el cual es 1183 (de acuerdo a la base de instituciones

que mantiene el equipo de SIIGETH en el MDT). Esta aparente diferencia indica que los

usuarios de las UATH se conectan indistintamente a las aplicaciones del SIITH sin considerar

que se trata del mismo sistema de información, por lo cual parece que el uso concurrente del

SIITH es mayor al número de usuarios posibles.

Por lo expuesto, se determina que para realizar las estimaciones de infraestructura y devolumen de datos del SIIGETH, lo más apropiado es usar el número total de servidoresde las UATH como número de usuarios recurrentes /conectados del SIITH (1183 x 174 /75 = 2744.56), y que el número total de usuarios dados como alcance del SIIGETH sería elnúmero de usuarios recurrentes (conectados) que la solución tendrá.

Finalmente, para poder usar la información de la tabla 2-2 en los cálculos subsiguientes, se

debió establecer una relación entre el tipo de usuario del SIITH y los tipos de usuario del

SIIGETH, lo cual se consigue bajo la premisa de que 1 usuario del SIITH equivale a unusuario gestor en la clasificación de usuarios del SIIGETH, puesto que un usuario del

SIITH conectado al 100% (tabla 2-2) equivale a un usuario conectado al 100% en el SIIGETH

(gestor). Establecida esta equivalencia, se procede a ponderar los otros tipos de usuario del

SIIGETH a usuarios gestores, tomando en cuenta el tiempo de conexión que los otros tipos de

usuario normalmente tendrían (tabla 2-3):

2-3 Ponderación de usuarios del SIIGETH a usuarios gestores

Tipo Número de usuariosestimados

Uso neto en tiempode conexión

Usuarios SIIGETH ponderadosa usuarios gestores

Gestores 5245 100% 5245Administradores 174 25% 43.5Aprobadores 19000 75% 14250


10

Estratégicos 400 5% 20Tácticos 700 20% 140Autoservicio 524595 3% 15737.85

Total 30191.35

Para completar la equivalencia entre usuarios SIITH y usuarios SIIGETH, se calcula en

términos de usuarios gestores el número de usuarios Administradores, Aprobadores,

Estratégicos, Tácticos y de Autoservicio que el SIITH tendría si abarcase toda la funcionalidad

del SIIGETH. Estos números son útiles para la posterior estimación de la infraestructuradel SIIGETH.

2-4 Usuarios del SIITH y SIIGETH ponderados a un mismo tipo de usuario (gestor)

TipoNúmero de

usuariosestimados

Uso neto entiempo deconexión

Usuarios SIIGETHponderados a usuarios

gestores

Usuarios SIITHponderados a

usuarios gestores

Gestores 5245 100% 5245 2744.56Administradores 174 25% 43.5 22.76Aprobadores 19000 75% 14250 7456.62Estratégicos 400 5% 20 10.47Tácticos 700 2% 140 73.26Autoservicio 524595 3% 15737.85 8235.17

Total 30191.35 18542.84

2.1.2 Dimensionamiento del volumen de los datos que almacenará el SIIGETH enrelación al volumen de datos almacenados del SIITH

De manera análoga a lo indicado en las secciones anteriores, para dimensionar el volumen de

los datos que almacenará el SIIGETH se usan como insumos:

• El volumen de los datos almacenados por el SIITH, tomado de la Matriz de

infraestructura que se encuentra en el Anexo MATRIZ_INFRAESTRUCTURA_SIITH-

v2.0.xlsx (formato digital)

• El tiempo que se estima esté en producción el SIIGETH en relación al tiempo que ha

estado en producción el SIITH.


11

Las variables para este cálculo se muestran en la tabla 2-5 Cálculo del número del volumen de

datos que almacenará el SIIGETH:

2-5 Cálculo del número del volumen de datos que almacenará el SIIGETH

Tiempo deoperación

en años

Procesos degestores

Totalusuariosgestores

Disco en GB

SIITH 4 15 2744.56 69.00SIIGETH 10 99 30191.35 24421.79

El volumen del almacén de datos del SIIGETH se obtiene con una proporción lineal compuesta

mediante el siguiente cálculo:

21111

22212 FF

UPT

UPTDD ××

××××

×=

En donde:

• D2 (volumen de datos del SIIGETH) = 24421.79 [GB]

• D1 (volumen de datos del SIITH) = 69 [GB]

• T2 (tiempo que se estima está en producción el SIIGETH) = 10

• T1 (tiempo que lleva en producción el SIITH) = 4

• P2 (número de procesos cubierto por el SIIGETH) = 99

• P1 (número de procesos que cubre el SIITH) = 15

• U2 (número de usuarios ponderados a gestores que tendría el SIIGETH) = 30191.35

• U1 (número de usuarios ponderados a gestores que tendría el SIITH) = 2744.56

• F1 (factor de ajuste por los recursos necesarios para una copia de contingencia) = 1.5

• F2 (factor de ajuste por los recursos necesarios para los ambientes de desarrollo,

pruebas y QA) = 1.3

2.1.3 Dimensionamiento de la infraestructura física que deberá soportar alSIIGETH

Por infraestructura física debe entenderse la capacidad de procesamiento (número de cores) y

la memoria real que deberá tener la plataforma de hardware para soportar al SIIGETH. Para

dimensionar estos valores con base en la información existente para el SIITH se tienen como

insumos:


12

• Los recursos de procesador y memoria usados por el SIITH, tomados de la Matriz de

infraestructura que se encuentra en el Anexo MATRIZ_INFRAESTRUCTURA_SIITH-

v2.0.xlsx (formato digital).

Las variables para el cálculo de los cores necesarios para el SIIGETH, tomando en cuenta sólo

los usuarios gestores, se muestran en la tabla 2-6 Cálculo del número de cores necesario para

soportar al SIIGETH:

2-6 Cálculo del número de cores necesario para soportar al SIIGETH

Procesos Usuariosgestores Cores AS Cores BDD Cores

dedicadosSIITH 15 2744.56 8 12 20.00SIIGETH 99 5245.00 252.26

El número de cores del SIIGETH para soportar usuarios gestores se obtiene con una

proporción lineal compuesta mediante el siguiente cálculo:

11

2212 UP

UPCC

×××=

Dónde:

• C2 (número de cores del SIIGETH para usuarios gestores) = 252

• C1 (número de cores del SIITH para usuarios conectados equivalentes a gestores) = 20

• P1 (número de procesos-componentes implementados por el SIITH) = 15

• U1 (número de usuarios del SIITH) = 2744.56

• P2 (número de procesos-componentes que implementará el SIIGETH) = 99

• U2 (número de usuarios conectados ponderados que tendrá el SIIGETH) = 5245

Para calcular el número de cores estimado para el SIIGETH en su totalidad, se usan las

variables de la tabla 2-7 Estimación del total de cores para el SIIGETH:


13

2-7 Estimación del total de cores para el SIIGETH

Usuariosgestores

proyectadospara elSIIGETH

Coresproyectados pornúmero de tipo

de usuario

Factor decorrección por

funciones(procesos) usados

Cores estimados parael SIIGETH por númerode usuarios y procesos

Gestores 5245.00 252.26 1.00 252.26Administradores 43.50 2.09 0.10 0.21Aprobadores 14250.00 685.36 0.20 137.07Estratégicos 20.00 0.96 0.05 0.05Tácticos 140.00 6.73 0.10 0.67Autoservicio 15737.85 756.91 0.15 113.54

Total cores 503.80Total cores corregido 458.46

Los cores debidos a la carga de cada tipo de usuario se calculan con reglas de tres simples,

con lo cual se obtiene como subtotal 503.80 cores. Este último valor se debe corregir con dos

factores:

• Factor de 0.7 por la mejora de desempeño de la tecnología Intel Haswell de 22 nm

sobre la tecnología Westmere de 32 nm.

• Factor de 1.3 por los recursos necesarios para los ambientes de desarrollo, pruebas y

QA)

El resultado final es 458 cores para soportar los usuarios y procesos dados comoalcance para el SIIGETH, tomando como base de proyección la carga actual del SIITH y la

tecnología subyacente, que es JEE.

Finalmente, para calcular la memoria RAM necesaria para el SIIGETH, se usan las variables de

cálculo de la tabla:

2-8 Cálculo de la memoria requerida para el SIIGETH

Procesos degestores

Total usuariosgestores

RAMconfigurada RAM BDD RAM en GB

SIITH 15 2744.56 52 32SIIGETH 99 30191.35 2205.15


14

La memoria estimada para que el SIIGETH soporte los usuarios y procesos dados como

alcance se obtiene con proporciones lineales compuestas mediante el siguiente cálculo:

31

212

11

2211

1

212 F

U

UMF

PU

PUMF

U

UMM BDDSS ×

×+

×

×××+

×

×=

Dónde:

• M2 (memoria estimada para el SIIGETH) = 2205 [MB]

• M1S (memoria de servidor usada por los usuarios del SIITH) = 52 [MB]

• M1BDD (memoria de servidor de BDD usada por los usuarios del SIITH) = 32 [MB]

• P2 (número de procesos cubierto por el SIIGETH) = 99

• P1 (número de procesos que cubre el SIITH) = 15

• U2 (número de usuarios ponderados a gestores que tendría el SIIGETH) = 30191.35

• U1 (número de usuarios ponderados a gestores que tendría el SIITH) = 2744.56

• F1 (factor de ajuste por la menor cantidad de memoria requerida por las tecnologías de

front end indicadas en la arquitectura esencial, con respecto a la memoria requerida por

la tecnología de las aplicaciones del SIITH) = 0.7

• F2 (factor de ajuste dado por la relación (1 a 4) entre la memoria permanente y la

memoria heap de la JVM; la mayor cantidad de definiciones de procesos sólo afecta a la

memoria permanente) = 0.25

• F3 (factor de ajuste por los recursos necesarios para los ambientes de desarrollo,

pruebas y QA) = 1.3

2.1.4 Definición de las capacidades de conectividad del SIIGETH

Las capacidades de conectividad que deberá tener la plataforma del SIIGETH están

determinadas por la infraestructura implementada por los centros de datos que posiblemente

alojarán la solución, es decir, el centro de datos de CNT y el centro de datos del MDT.

En cualquier caso, el ancho de banda necesario para la operación del SIIGETH puede

estimarse con base en el ancho de banda ocupado por el SIITH proyectado por un factor que

guarde proporción con los procesos que implementará el SIIGETH y el número de usuarios

conectados ponderado.

Actualmente el canal ocupado por el SIITH y por otras aplicaciones tiene un ancho de 75

[Mbps], con lo cual y simplificando la estimación a una proyección lineal entre la carga de


15

usuarios conectados al 100% (gestores) del SIITH y del SIIGETH (tabla 2-4), se establece que

el ancho de banda necesario para el SIIGETH sería:

1

212 Q

QAA ×=

Donde:

• A2 (Ancho de banda necesario para el SIIGETH) = 122.11 [Mbps]

• A1 (Ancho de banda necesario actual del SIITH) = 75 [Mbps]

• Q2 (Número de usuarios conectados al 100% estimada para el SIIGETH) = 30191.35

• Q1 (Número de usuarios conectados al 100% del SIITH) = 18542.84

2.1.5 Definición del software base y de los lineamientos para la calidad delproducto

El software base que debe soportar al SIIGETH deberá ser propuesto por los oferentes bajo las

siguientes condiciones y lineamientos:

• En caso de que la solución sea desarrollada, su implementación debe guiarse por la

arquitectura esencial de indicada en el segundo informe de la presente consultoría.

• En caso de que la solución sea adquirida como un paquete comercial, este debe tener

la capacidad de integrarse con otros sistemas mediante servicios web y otros

mecanismos siguiendo una filosofía SOA.

• El software de plataforma debe ser de tipo empresarial, capaz de soportar la magnitud

del SIIGETH establecida en el dimensionamiento realizado en el presente documento.

En cuanto a los lineamientos que determinan la calidad del SIIGETH como un producto, se

deben tomar como referencia las características indicadas por el estándar ISO/IEC-

25010:2011:

1. Idoneidad funcional (Functional Suitability): grado en que un producto o sistema

proporciona las funciones requeridas cuando se lo utiliza en condiciones especificadas.

2. Confiabilidad (Reliability): grado en el que un sistema, producto o componente realiza

determinadas funciones en condiciones determinadas por un período de tiempo

especificado.

3. Desempeño (Peformance efficiency): rendimiento en relación con la cantidad de

recursos utilizados en condiciones especificadas.


16

4. Operabilidad (Operability): grado en que un producto o sistema tiene atributos que lo

hacen fácil de operar y controlar.

5. Seguridad (Security): grado en que un producto o sistema protege la información y los

datos para que las personas u otros productos o sistemas tengan el grado de acceso a

los datos apropiado según sus tipos y niveles de autorización.

6. Compatibilidad (Compatibility): grado en que un producto, sistema o componente

puede intercambiar información con otros productos, sistemas o componentes, y / o

llevar a cabo sus funciones requeridas, mientras comparten el mismo entorno de

hardware o software.

7. Mantenibilidad (Maintainability): grado de eficacia y eficiencia con que un producto o

sistema pueden modificarse para ser mejorado, corregido o adaptado a cambios en el

medio ambiente y en los requerimientos.

8. Transferibilidad (Transferability): grado en el cual un producto o sistema puede ser

instalado o adaptado a un ambiente de hardware o software.

Junto con las recomendaciones de los estándares de diseño de interfaces y aplicaciones web

ISO 9241-151:2008, ISO 9241-20:2008 y WCAG 2.0, y al menos las recomendaciones de los

estándares para comunicaciones, mensajes y seguridad: RFC 4158 (guías para la construcción

de X.509 public-key certification paths), RFC 5055 (implementación de Server-Based Certificate

Validation Protocol (SCVP)), RFC 5280 (define políticas de CRL para certificados X.509), ISO

20022:2013, y las mejores prácticas recomendadas por OWASP para administración de

contraseñas.

2.1.6 Resumen del dimensionamiento del SIIGETH con base en la estimaciónrealizada sobre las fuentes levantadas

2-9 Dimensionamiento del SIIGETH con base en las mediciones sobre el SIITH

Tiempo deoperación

en añosProcesos

Usuariosconectados

según elalcance del

SIIGETH

Usuarios deautoservicio

según elalcance del

SIIGETH

Coresdedicados

RAM enGB

Disco enGB

10 110 25509 524595 458 2205.15 24421.79

El dimensionamiento del SIIGETH realizado mediante la proyección del dimensionamiento del

SIITH brinda una referencia para analizar y comparar el dimensionamiento que los proveedores


17

de paquetes comerciales y de infraestructura incluyeron en sus expresiones de interés. Este

trabajo se realiza en la sección 2.3.

2.2 Dimensionamiento presentado por proveedores de paquetescomerciales y de infraestructura

Los dimensionamientos incluidos en las propuestas presentadas en las expresiones de interés

de proveedores de paquetes comerciales, y los dimensionamientos presentados por

proveedores de infraestructura, pueden ser analizados y comparados tomando en cuenta los

resultados presentados en la sección Resumen del dimensionamiento del SIIGETH.

En todos los casos los dimensionamientos presentados por los proveedores incluyeron

ambientes de producción, control de calidad QA, pruebas y desarrollo.

La tabla 2-10 Dimensionamiento proveedores de paquetes comerciales presenta la

infraestructura necesaria para la implementación del SIIGETH bajo la modalidad de una

supuesta compra de solución comercial:

2-10 Dimensionamiento proveedores de paquetes comerciales

PROCESAMIENTO (CORES) MEMORIA (GB) ALMACENAMIENTO (GB)

FREEBALANCE 48 896 5000

PEOPLE SOFT 206 660 6800

SAP 116 624 7130

Por su parte, el dimensionamiento de los proveedores de infraestructura se realizó tomando en

cuenta las directrices de tecnología de la sección 5.2 y los siguientes insumos:

1. Alcance del SIIGETH

2. Arquitectura referencial (SOA)

3. Modelo conceptual del SIIGETH

4. Dimensionamiento referencial obtenido de los proveedores de paquetes comerciales

Los proveedores de infraestructura a los cuales se entregaron los insumos listados y de

quienes se recibieron los respectivos dimensionamientos fueron contactados por referencias de

casos previos de implementación para el gobierno. COMWARE por su parte realizó una

implementación previa en el MDT, mientras que ANDEAN-TRADE cuenta con


18

implementaciones exitosas en los Ministerios de Turismo y Educación. La validación de los

insumos y de la información recibida se realizó por correo electrónico y por conferencias

telefónicas.

Con base en el Anexo Propuestas enviadas por los proveedores de infraestructura, se presenta

a continuación un resumen de las propuestas de los proveedores de infraestructura que

colaboraron con el estudio:

2-11 Dimensionamiento proveedores de infraestructura

PROCESAMIENTO (CORES) MEMORIA (GB) ALMACENAMIENTO (GB)

ANDEAN-TRADE 282 1716 17000COMWARE 324 2304 18000SINERGY HARD 80 2048 28800

2.3 Análisis y comparación del dimensionamiento estimado conrespecto al realizado por los proveedores

Como se puede observar en la tabla 2-11 Dimensionamiento proveedores de infraestructura, el

dimensionamiento de los proveedores de infraestructura es similar al dimensionamiento basado

en la carga actual del SIITH de la sección 2.1.6, pero difiere del de las propuestas de los

proveedores de paquetes comerciales:

2-12 Cuadro comparativo final de dimensionamientos

FUENTE PROCESAMIENTO(CORES)

MEMORIA(GB)

ALMACENAMIENTO(GB) TIPO

ANDEAN-TRADE 282 1716 17000 INFRAESTRUCTURA

COMWARE 324 2304 18000 INFRAESTRUCTURA

SINERGY HARD 80 2048 28800 INFRAESTRUCTURA

PROYECCIÓN SIITH 458 2205 24421 ESTIMACIÓN

FREEBALANCE 48 896 5000 PAQUETE

PEOPLE SOFT 206 660 6800 PAQUETE

SAP 116 624 7130 PAQUETE

Los resultados de la tabla 2-12 Cuadro comparativo final de dimensionamientos se pueden

visualizar como gráficos de barras:


19

2-1 Comparación del dimensionamiento de la capacidad de procesamiento

2-2 Comparación del dimensionamiento de la memoria real

050

100150200250300350400450500

PROCESAMIENTO (CORES)

0

500

1000

1500

2000

2500


19



PROCESAMIENTO (CORES)

PROCESAMIENTO(CORES)

MEMORIA (GB)

MEMORIA (GB)


19



PROCESAMIENTO(CORES)

MEMORIA (GB)


20

2-3 Comparación del dimensionamiento del volumen de datos que deberá almacenarse en 10 años

La cercanía entre el dimensionamiento estimado basado en la carga del SIITH y el

dimensionamiento realizado por los proveedores de infraestructura se debe a la similitud de las

tecnologías subyacentes (JEE y base de datos relacional), y a la experiencia de estos

proveedores en proyectos semejantes al SIIGETH en el contexto ecuatoriano / sector público.

Por otra parte, la diferencia apreciable entre el dimensionamiento de los proveedores de

infraestructura y el dimensionamiento realizado por los proveedores de paquetes comerciales

puede deberse a la diferencia entre las tecnologías subyacentes (JEE vs. tecnologías

propietarias) y posiblemente a la falta de experiencia de estos proveedores en proyectos

semejantes al SIIGETH en el contexto ecuatoriano / sector público (se recomienda indagar

sobre el desarrollo y estado del proyecto de implantación del ERP en CNT).

Por lo expuesto, la recomendación final sobre el dimensionamiento del SIIGETH es incluir en el

TDR lo siguiente:

• Que la solución debe soportar la carga de usuarios indicada en la sección 0, con un

margen de seguridad de 20%.

• Que la solución debe implementar al menos los procesos descritos en la sección

2.1.1.1, con un margen de flexibilidad por procesos adicionales con un peso funcional

de hasta un 20% del establecido para los procesos actualmente identificados.

05000

1000015000200002500030000

ALMACENAMIENTO (GB)


20













TDR lo siguiente:






ALMACENAMIENTO (GB)

ALMACENAMIENTO (GB)


20













TDR lo siguiente:






ALMACENAMIENTO (GB)


21

• Que la infraestructura y plataforma de la solución deben diseñarse de forma que puedan

almacenar el volumen de datos indicado en la sección 2.1.2, el cual incluye un 50%

para copia pasiva y otros medios de recuperación, y está estimado para 10 años de

operación.

Y la recomendación final sobre este tema para los trabajos subsiguientes, es:

• Considerar a los dimensionamientos realizados por los proveedores de infraestructura

como un marco de referencia válido para evaluar las propuestas de infraestructura que

se califiquen al momento de contratar el proyecto como un desarrollo a la medida.

• Solicitar a los proveedores de paquetes comerciales un sustento detallado del

dimensionamiento de infraestructura de sus ofertas, a fin de reducir el riesgo de una

posible estimación mal realizada.

• Contratar el aprovisionamiento de la infraestructura de forma que se implantación se

realice gradualmente, de forma que se valide en la medida de lo posible que aquello

que se compra e instala esté siendo utilizado y aprovechado efectivamente.

2.4 Requisitos para las opciones de aprovisionamiento de lainfraestructura

Las opciones de implantación de la infraestructura que se establecieron en el primer informe

son:

• Infraestructura como servicio

• Infraestructura alojada en el centro de datos de CNT

• Infraestructura alojada en el centro de datos del MDT

Para cada opción se describen a continuación (2-13 Requisitos para el aprovisionamiento de la

infraestructura) las condiciones o requisitos que se deben tomar en cuenta para hacer viable la

aplicación de la opción en caso de que el SIIGETH se implemente con un paquete comercial, o

que el SIIGETH se implemente con un desarrollo a la medida:


22

2-13 Requisitos para el aprovisionamiento de la infraestructura

Opción deaprovisionamiento

Requisitos que deben considerarse para aplicar laopción de aprovisionamiento de infraestructura

Apl

ica

para

paq

uete

Apl

ica

para

des

arro

llo

Infraestructura comoservicio provisionada por

CNT

El proveedor de la infraestructura DEBE facilitar la virtualización de

la plataforma de la solución usando las herramientas/productos de

virtualización particulares que los fabricantes requieren para

licenciar su software base y su software para gestión del talento

humano.

X

El proveedor de la infraestructura DEBE contar con la capacidad

requerida por el dimensionamiento indicado en la sección 2.3.X X

El proveedor de la infraestructura DEBE asegurar alta disponibilidad

para la infraestructura provisionada.X X

El proveedor de la infraestructura DEBE asegurar alta disponibilidad

y redundancia para la infraestructura provisionada utilizada para los

almacenes de datos y documentos.

X X

El proveedor de la infraestructura DEBE incorporar los

componentes de seguridad físicos y lógicos necesarios para

proteger a la plataforma de la solución como una nube privada.

X X

Infraestructura alojada en elcentro de datos de CNT

El proveedor de la infraestructura DEBE contar con la capacidad

para alojar el hardware de la solución, el cual será instalado

gradualmente.

X X

El proveedor de la infraestructura DEBE contar con la capacidad de

conectividad requerida según el dimensionamiento indicado en la

sección 2.1.4.

X X

El proveedor de la infraestructura DEBE facilitar la instalación de los

componentes de seguridad físicos y lógicos necesarios para

proteger la infraestructura de la solución de manera independiente.

X X

Infraestructura alojada en elcentro de datos del MDT

El centro de datos del MDT DEBE contar con la capacidad para

alojar el hardware de la solución, el cual será instalado

gradualmente.

X X

El centro de datos del MDT DEBE garantizar la seguridad de la

solución mediante el uso de componentes físicos y lógicos.X X


23

El MDT DEBE contar con el personal técnico necesario para brindar

soporte a la infraestructura según los acuerdos de niveles de

servicios que se establezcan para la solución, los cuales al menos

indicarán una disponibilidad total garantizada para la jornada

convencional diaria.

X X

Los requisitos descritos en la tabla 2-13 Requisitos para el aprovisionamiento de la

infraestructura se deben validar mediante comunicación y solicitación formal de información por

parte de la gerencia del SIIGETH, trabajo cuyos resultados se tomarán en cuenta para la

elaboración del informe final de la presente consultoría.


24

3 Listado de integraciones y modelo esencial deintegración

3.1 Listado de integracionesLas integraciones que el SIIGETH deberá contemplar se indican, a nivel de negocio, en el

Modelo Conceptual del sistema. Dichas integraciones también deben ser consideradas en el

modelado de procesos previo al desarrollo de la solución, puesto que los modelos de procesos

son un insumo para la especificación funcional del SIIGETH.

En la tabla 3-1 Integraciones con instituciones externas - tomado del Modelo Conceptual del

SIIGETH se indica para cada caso el tipo de integración que se ha usar, o implementar en caso

de no existir un servicio previamente construido.


25

3-1 Integraciones con instituciones externas - tomado del Modelo Conceptual del SIIGETH

Descripción de la integración Institución que seintegra

Tipo de integración WSDL/WADL de los servicios implementados (deexistir)

Recuperar los datos personales sobre losservidores que ingresen al sector públicocon la digitación del número de cédula.

1. Registro Civil Servicio web SOAP https://www.bsg.gob.ec/sw/RC/BSGSW02_Consultar_Nombre?wsdl

Validación de existencia de RUC de lasinstituciones al momento de su registro,empleadores y capacitadores.

2. Servicio deRentas Internas

Servicio web SOAP https://www.bsg.gob.ec/sw/SRI/BSGSW01_Consultar_RucSRI?wsdl

Validación de número de QUIPUX (memou oficio) de las personas a quienes hasido asignado un trámite.

3. Secretaría de laAdministraciónPública

Servicio web SOAP https://www.bsg.gob.ec/sw/STI/BSGSW03_Consultar_DocumeQUI?wsdl

Validación de Firma electrónica,certificado o medio por el cual la entidademisora avale la responsabilidad sobre laautenticación de un trámite.

4. Banco Centraldel Ecuador

Servicio web SOAP https://www.bsg.gob.ec/sw/STI/BSGSW10_Verificar_ValidezCFE?wsdl

Recuperación de la historia laboral de unservidor a través de su número de cédula,con el fin de mantener una trazabilidad desu trayectoria.

5. InstitutoEcuatoriano deSeguridad Social

Servicio web SOAP N/A

Recuperación del código único de puestopara la asociación a la remuneración ydemás características inherentes almismo, validación de partida ycertificación presupuestaria.

6. Ministerio deFinanzas


Recuperación a través de número decédula de la trayectoria académica delservidor registrada en esta entidad.

7. Instituto de AltosEstudiosNacionales


www.bsg.gob.ec/sw/RC/BSGSW02_Consultar_

www.bsg.gob.ec/sw/SRI/BSGSW01_Consultar

www.bsg.gob.ec/sw/STI/BSGSW03_Consultar_

www.bsg.gob.ec/sw/STI/BSGSW10_Verificar_


26

Recuperación a través de número decédula sobre capacitaciones recibidas eneste centro por el servidor.

8. ServicioEcuatoriano deCapacitaciónProfesional


Recuperación de notas por proceso detoma de pruebas en los procesos deselección de persona.

9. Instituto Nacionalde la Meritocracia

Servicio web SOAP https://www.bsg.gob.ec/sw/INM/BSGSW01_Consultar_NotasINM?wsdl

Consulta de registros oficialesrelacionados a los temas antes citados.

10. DirecciónNacional deRegistro de DatosPúblicos


Recuperación de información sobreinstrucción formal a partir del número decédula de un ciudadano, adicionalrecuperación de catálogos sobreUniversidades registradas, carreras, etc.

11. SecretariaNacional deEducaciónSuperior, Ciencia,Tecnología eInnovación

Servicio web SOAP https://www.bsg.gob.ec/sw/SENESCYT/BSGSW01_Consultar_Titulos?wsdl

Información sobre si un ciudadanoadeuda un préstamo quirografario,hipotecario, con su respectivo saldo yvalor a ser descontado mensualmente,esto como control al ingresar o salir deuna institución pública.

12. Banco delInstitutoEcuatoriano deSeguridad Social


Verificación o registro de una nuevainstitución.

13.Superintendenciade Compañías


Recuperación de datos a través delingreso del número de cédula sobre laeducación básica de un ciudadano.

14. Ministerio deEducación


Verificar a través del número de cédula si 15. Ministerio de Servicio web SOAP https://www.bsg.gob.ec/sw/MSP/BSGSW01_Consulta

www.bsg.gob.ec/sw/INM/BSGSW01_Consultar

www.bsg.gob.ec/sw/SENESCYT/BSGSW01_C


27

una persona posee o no discapacidad ysu grado.

Salud r_Discapacidad?wsdl

Recuperación del documento de base decreación de las instituciones, a través delnombre de la institución, número de RUCo número de decreto.

16. Registro Oficial Servicio web SOAP N/A

Registro de préstamos para becas oestudios en general otorgados a unservidor.

17. InstitutoEcuatoriano deCrédito Estudiantil


Recuperación de información sobreadeudamiento de préstamos, a través delingreso del número de cédula.

18. CorporaciónFinancieraNacional


Recuperación de información sobreadeudamiento de préstamos, a través delingreso del número de cédula.

19. Banco Nacionalde Fomento


Validación de estar o no afiliado a estainstitución a través del ingreso del númerode cédula.

20. Instituto deSeguridad Socialde la Policía

Servicio web SOAP https://www.bsg.gob.ec/sw/ISSPOL/BSGSW03_Consultar_EstadoIsspol?wsdlhttps://www.bsg.gob.ec/sw/ISSPOL/BSGSW01_Consultar_AfiliadoIsspol?wsdl

Validación de estar o no afiliado a estainstitución, a través del ingreso delnúmero de cédula.

21. Instituto deSeguridad Socialde las FuerzasArmadas

Servicio web SOAP https://www.bsg.gob.ec/sw/ISSFA/BSGSW01_Consultar_AfiliadoIssfa?wsdl

Consulta de causas o sentencias dealimentos o ejecutoriales, a través delingreso del número de cédula.

22. Consejo de laJudicatura


Validación de pasaporte de losciudadanos extranjeros

23. Ministerio deRelacionesExteriores.


www.bsg.gob.ec/sw/MSP/BSGSW01_ConsultaINFORME

www.bsg.gob.ec/sw/ISSPOL/BSGSW03_Cons

www.bsg.gob.ec/sw/ISSPOL/BSGSW01_Cons

www.bsg.gob.ec/sw/ISSFA/BSGSW01_Consult


28

Verificación de aprobación de declaraciónjuramentada.

24. ControlaríaGeneral del Estado


Verificación de licencia 25. AgenciaNacional deTransito

Servicio web SOAP https://www.bsg.gob.ec/sw/ANT/BSGSW01_Consultar_MatriculaLic?WSDL

Verificación de licencia 26. Comisión deTránsito delEcuador


Los contratos (WSDL) que no se han incluido en la tabla 3-1 Integraciones con instituciones externas - tomado del Modelo

Conceptual del SIIGETH, por no encontrarse disponibles para el público en general, serán solicitados formalmente a las

instituciones respectivas a fin de incluir este detalle en el informe final de la consultoría.

www.bsg.gob.ec/sw/ANT/BSGSW01_Consultar


29

3.2 Modelo esencial de datos e integraciónLas integraciones del SIIGETH con las instituciones públicas de las cuales consume y a las

cuales publica datos, relativos y transversales a la gestión del talento humano, deberán

implementarse acorde a las siguientes directrices:

1. Las integraciones deben realizarse a través del componente de integración externa

indicada en la arquitectura de referencia incluida en el segundo informe. Dicho

componente puede implementarse como un bus o mediante servicios de integración

desplegados en un servidor o en un contenedor (Figure 3-1 Componente para

integración externa del SIIGETH).

2. Las integraciones deben implementarse preferiblemente bajo patrones SOA tomando en

consideración los siguientes casos:

3-2 Aplicación de los tipos de integración

Tipo de integración Cuándo se debe aplicar

Servicio web SOAP Por defecto para toda integración que se realice hacia una

institución a través del bus de servicios del gobierno.

Servicio web REST Cuando no se trate de una integración a través del bus de

servicios del gobierno y la información que se vaya a enviar o

recibir no requiera un esquema de validación. Por ejemplo, se

recomienda usar servicios web REST para habilitar la consulta

de datos puntuales.

ETL Cuando en una integración el proveedor de información

entregue los datos en texto plano o en respaldos de bases de

datos, y, no exista una manera viable de regularizar la

integración a través de servicios web o el volumen de los datos

cada carga de datos se encuentre en el orden de MB.

Replicación de bases de datos Cuando en una integración el origen de datos es una estructura

tabular compleja que se actualiza en línea afectando múltiples

registros a la vez, y existe un canal dedicado asegurado para

acceder directamente desde el SIIGETH hacia tablas o vistas

del proveedor de información, y cuando el tamaño de las tablas

o vistas que se replican no es significativo (no es mayor al 10%

del 20% del total de datos transaccionales almacenados) en

relación al volumen de datos propios del SIIGETH.


30

3. Las integraciones mediante servicios web a través del bus del gobierno deben

coordinarse con la SNAP, la cual regula el uso del bus de integración del Gobierno. Por

tal razón las políticas de nombres y esquemas de nombres deberán ser recibidos de, o

al menos deben ser acordados con la SNAP.

4. Los servicios web implementados para integración deben registrarse en el repositorio de

servicios UDDI indicado en la arquitectura base propuesta para el SIIGETH.

5. Los servicios de negocio y los servicios de integración del SIIGETH deben estar

identificados y documentados.

6. Finalmente, las integraciones a implementarse se deben especificar de acuerdo a los

modelos de procesos de negocio levantados para el SIIGETH, es decir, se debe

guardar coherencia entre la nomenclatura y funcionalidad de los servicios de

integración, con las integraciones definidas en los modelos de procesos de negocios del

SIIGETH.


31

Figure 3-1 Componente para integración externa del SIIGETH


32

4 Recomendaciones de estrategia de implementaciónde la solución

Para recomendar la alternativa más apropiada para la implementación e implantación del

SIIGETH de entre las opciones:

• Compra de un paquete comercial

• Desarrollo de una solución a medida

Se realizó un análisis que considera:

1. El contexto actual del SIIGETH

2. El análisis y comparación de las fortalezas y debilidades técnicas de las alternativas

3. El análisis y comparación del costo estimado de implementación e implantación de las

alternativas

4. El análisis y comparación del riesgo inherente a cada alternativa

Los productos de este análisis de anexan a este informe en formato digital, correspondiendo a

las secciones:

• COMPARACION_TECNICA_DE_OPCIONES-v1.2.xlsx (formato digital)

• ESTIMACION_Y_ANALISIS_DE_COSTOS-v1.6.xlsx (formato digital)

• ANALISIS_RIESGO-v1.3.xlsx (formato digital)

Del trabajo realizado se obtiene la siguiente recomendación:

Se recomienda el desarrollo a medida del SIIGETH, por cuanto es una alternativa acordea la necesidad del proyecto, y que implica menos riesgo en su implementación eimplantación dentro del marco administrativo, presupuestario y tecnológico existente.Se recomienda además el desarrollo del SIIGETH debido a la transferencia tecnológica

subyacente, la cual enriquecerá al estado del arte de la industria de software nacional,

partiendo desde el sector público y pasando gradualmente hacia el sector privado.

Al respecto, con base en el dimensionamiento realizado en el presente documento y

considerando factores/riesgos externos presentes a la fecha de emisión del presente informe,

se recomienda que en caso de que el MDT ejecute la implementación del SIIGETH como un

desarrollo a la medida, contrate dos consultorías complementarias:


33

• Una consultoría complementaria para guiar/supervisar la debida construcción de los

cimientos tecnológicos y arquitectónicos del SIIGETH.

• Una consultoría complementaria para guiar/supervisar la metodología de

implementación y entrega del SIIGETH.

Sin embargo, ha de acotarse que la alternativa de compra de un paquete comercial debe

considerarse la opción más conveniente en caso de que el contexto presupuestario del

proyecto mejore y asegure el financiamiento total necesario para la implementación e

implantación de un paquete comercial.

5 Componentes y requisitos técnicos de la soluciónLa definición del MDT, es que el SIIGETH sea desarrollado por un contratista experto, de forma

que se asegure la calidad de la solución final y además se transfiera tecnología y conocimiento

al Ministerio, y por ende a todo el sector público y posteriormente a toda la industria de software

nacional.

La especificación de los componentes que deberá incluir el SIIGETH y las directrices

arquitectónicas para la implementación del SIIGETH se establecieron en el segundo informe de

la presente consultoría. En el presente documento se recapitulan los componentes que la

solución deberá implementar, y se presentan las directrices tecnológicas que complementan los

lineamientos arquitectónicos, y que deben tomarse en cuenta para la definición de los

requerimientos técnicos.

5.1 Definición de los componentes que debe implementar el SIIGETHArquitectónicamente, los componentes que deberá incluir la solución son:

5.1.1 Componentes comunes

Implementan funcionalidad común y transversal en la solución, como:

• Autenticación y autorización: componentes que implementan la autenticación al

SIIGETH con single sign-on (acceder a múltiples aplicaciones con un mismo usuario y

contraseña, con una sola operación de login) y que autorizan a los usuarios mediante

roles y perfiles el acceso y uso de componentes y funciones del sistema.

• Registro de logs de eventos y excepciones: componentes que registran eventos

clave del sistema, como su inicio, reconfiguración, reinicio, etc., y que registran


34

excepciones en su funcionamiento. Los registros (logs) se deben registrar en archivos

de texto legibles por un ser humano.

• Auditoría: Componentes que implementan la auditoría de los cambios/actualizaciones

de datos sensibles en el sistema. La existencia de estos componentes de auditoría no

implica que no se requiera un mecanismo de auditoría a nivel de base de datos; de

hecho, lo más apropiado es combinar la auditoría a nivel de base de datos con la

auditoría implementada por las aplicaciones.

• Monitoreo: Componentes desarrollados o de terceros que permitan monitorear en

tiempo real el funcionamiento (usuarios conectados, operaciones en ejecución,

transacciones realizadas) del sistema, así como su desempeño (recursos consumidos,

sesiones de bases de datos, accesos a datos, etc.)

5.1.2 Componentes para acceso a datos

Implementan el acceso a los repositorios de datos y de documentos de la solución, incluido el

acceso e integración con el gestor documental indicado en la arquitectura esencial de la

solución.

5.1.3 Componentes core

Implementan la lógica transaccional de la automatización de la gestión del talento humano e

implementan características no funcionales propias de la solución. Los subsistemas

conceptuales y procesos de gestión del talento humano que los componentes core deberán

soportar se listan a continuación:

Componentes del subsistema de gestión del talento humano:

1. Gestión de la comunicación

2. Organizaciones

3. Parametrización

4. Gestión de catastro institucional

5. Gestión de estructura organizacional

6. Gestión de expediente

7. Descripción, valoración y clasificación de puestos

8. Planificación de talento humano

9. Selección de personal - concursos

10. Selección de personal - servicios ocasionales


35

11. Gestión del tiempo

12. Gestión del conocimiento

13. Vinculación

14. Desvinculación

15. Movimientos de personal

16. Vacaciones

17. Gestión disciplinaria

18. Retribución monetaria y no monetaria - compensaciones

19. Retribución monetaria y no monetaria - ingresos complementarios

20. Retribución monetaria y no monetaria - remuneración variable

21. Retribución monetaria y no monetaria - viáticos, fondos de reserva, indemnizaciones,

bonificaciones geográficas

22. Retribución monetaria y no monetaria - cálculo de nómina

23. Autoservicio

24. Reportes generales y para toma de decisiones

25. Evaluación de desempeño

26. Formación y capacitación

27. Seguridad y salud en el trabajo

28. Bienestar laboral

Componentes del subsistema de control y seguimiento:

1. Control y seguimiento - evaluación de riesgos

2. Control y seguimiento - planificación del control

3. Control y seguimiento - tratamiento del control y gestión de resultados

4. Gestión de la calidad de los procesos implementados por el SIIGETH

5.1.4 Componentes para ruteo y transformación de mensajes internos

1. Un componente para ruteo y transformación de mensajes entre componentesinternos del SIIGETH: el cual puede implementarse como un ESB o mediante una

estrategia SOA equivalente.

2. Un componente para ruteo e integración: el cual puede implementarse como un ESB

o mediante una estrategia SOA equivalente. El componente debe contar con las

interfaces necesarias para administrar y configurar los servicios web que integran

aplicaciones al SIIGETH.


36

5.1.5 Componentes para ejecución de procesos de negocio automatizados

1. Un componente para ejecución de procesos de negocio con sus respectivasorquestaciones: el cual puede implementarse con un motor de procesos comercial o

de plataforma abierta, capaz de automatizar y ejecutar los procesos definidos durante la

especificación funcional del SIIGETH.

5.1.6 Componentes para ejecución de reglas de negocio

1. Un componente de gestión y ejecución de reglas de negocio: el cual puede

implementarse con un BRMS (business rules management system) comercial o de

plataforma abierta, o con un componente/mecanismo equivalente que permita

configurar mediante parámetros el funcionamiento del sistema en cuanto a reglas de

validación, comparación, equivalencia, etc.

5.1.7 Componentes de publicación

Componentes que implementan el front end solución en los canales web y móvil. El front end

debe implementarse con el menor acoplamiento posible hacia la lógica transaccional, buscando

interoperabilidad y desempeño.

5.1.8 Componente gestor de documentos

Implementa la gestión del repositorio documental, el cual puede implementarse con un

componente que cumpla el estándar CMIS y que ofrezca una API que facilite su integración con

la solución. La autenticación al repositorio de documentos debe ser proporcionada por el mismo

proveedor del servicio de autenticación que use la solución.

5.1.9 Herramientas

1. Herramienta para modelado de procesos: útil para diseñar y diagramar los procesos

de negocio del SIIGETH en lenguaje BPMN 2; puede implementarse con una solución

comercial o de plataforma abierta. Los diagramas de procesos diseñados con esta

herramienta serán de utilidad para implementar la automatización de los procesos de

negocio que la solución debe soportar.

2. Herramienta para modelado de reglas: útil para diseñar las reglas de negocio que el

componente manejador de reglas debe ejecutar; puede implementarse con una solución

comercial o de plataforma abierta. La inclusión del modelador de reglas y el uso de un

componente que ejecute reglas de negocio es opcional en la solución.


37

3. Repositorio y sistema de control de versiones de código fuente: almacena el

código fuente de la solución desarrollada, o en su defecto, el código fuente de las

soluciones complementarias y personalizaciones para el caso de compra de un paquete

comercial; puede implementarse con una solución comercial o de plataforma abierta.

4. Repositorio y sistema de control de versiones de artefactos o componentesconstruidos: almacena los binarios construidos desde el código fuente del repositorio

de código fuente; puede implementarse con una solución comercial o de plataforma

abierta. El objetivo de contar con repositorios de fuentes y artefactos, es habilitar el uso

de un servidor de integración continua.

5. Repositorio y sistema de control de versiones de los modelos de procesos:almacena los diseños y diagramas de los procesos de negocio que se automatizan con

la solución; puede implementarse con una solución comercial o de plataforma abierta.

6. Repositorio y sistema de control de versiones de las reglas de negocio: almacena

las definiciones de las reglas de negocio que se automatizan con el gestor de reglas

implementado; puede implementarse con una solución comercial o de plataforma

abierta.

7. UDDI: catálogo de servicios de negocios de la solución para Internet, Universal

Description, Discovery and Integration (UDDI) es una iniciativa industrial abierta

(sufragada por la OASIS - Organization for the Advancement of Structured Information

Standards) entroncada en el contexto de los servicios Web; puede implementarse con

una solución comercial o de plataforma abierta, o mediante una

estrategia/implementación equivalente.

8. Servidor de integración continua: herramienta para la construcción integrada y

continua de la solución (en caso de desarrollo a medida) o de las aplicaciones

complementarias (en caso de paquete comercial); puede implementarse con una

solución comercial o de plataforma abierta.

9. Herramientas de BI: herramientas para explotación de la información consolidada en la

base de datos del SIIGETH; puede implementarse con una solución comercial o de

plataforma abierta. La herramienta debe ser de características empresariales y debe

certificar su funcionamiento e integración con la base de datos data warehouse de la

solución. La herramienta debe al menos generar vistas, cubos, reportes dinámicos,

diagramas, estadísticos y tableros de control que faciliten el análisis de la información

almacenada por el SIIGETH.


38

10. Herramientas ETL y herramientas para migración: herramientas para carga y

transformación de datos que además deberán utilizarse para migrar la información de

las bases de datos del SIITH a la base de datos del SIIGETH; puede implementarse con

una solución comercial o de plataforma abierta.

5.2 Directrices tecnológicas GeneralesConsiderando el estado del arte del software puesto al servicio del sector gubernamental

ecuatoriano, la legislación y políticas ecuatorianas, y considerando el estado de la industria

actual del software, se plantean las siguientes directrices claves para la implementación de la

solución, sea que se opte por un desarrollo a medida, o se adquiera un paquete comercial:

Directriz Ámbito

Paqu

ete

Des

arro

llo

La plataforma de desarrollo debe ser de

código abierto para todos los componentes de

la solución que son susceptibles de

implementación.

Plataforma/Software base X

Los componentes de front end de la solución

deberán desarrollarse usando tecnologías

para web y dispositivos móviles de plataforma

abierta, como Ruby, Rails, Grails, JSF,

HTML5, Dojo, AngularJS, etc.

Ingeniería/Arquitectura X

Los componentes que no son de front end

deberán desarrollarse usando tecnologías

empresariales Java.

Ingeniería/Arquitectura X

La solución de infraestructura/plataforma debe

plantearse como una nube privada para el

MDT.

Plataforma/Software base X X

La infraestructura soportante debe brindar

redundancia para almacenamiento de datos.Confiabilidad/Tolerancia a fallos X X

La infraestructura soportante debe tener

arquitectura Intel.Plataforma/Hardware X X


39

La infraestructura/plataforma soportante de los

servidores de aplicaciones, debe brindar alta

disponibilidad.

Confiabilidad/Disponibilidad X X

La plataforma soportante debe incluir una

solución de virtualización que gestione a las 4

ambientes definidos (desarrollo, pruebas,

calidad y producción)


La base de datos del SIIGETH debe ser de

clase mundial, como por ejemplo Oracle 12c

de edición empresarial.



solución de copia pasiva de la base de datos

de producción.

Confiabilidad/Tolerancia a fallos X X


solución de almacenamiento para

recuperación en caso de desastre y una

solución de almacenamiento de archivo a

largo plazo (cinta).

Confiabilidad/Tolerancia a fallos X X

Los sistemas operativos de la plataforma

soportante deben ser Linux. Se recomienda

que incluyan soporte.


Los servidores de aplicaciones y

contenedores que se utilicen para desplegar

los componentes de la solución deben ser de

plataforma abierta y de capacidades

empresariales, como por ejemplo JBoss EAP.

Plataforma/Software base X

La solución de infraestructura/plataforma debe

incluir un elemento de seguridad que proteja

la nube privada del MDT, aun cuando sus

comunicaciones trabajen sobre canales

dedicados y el anillo inter ministerial (supuesto

de infraestructura).



40

6 Elaboración de las recomendaciones para laentrega y despliegue por fases del SIIGETH

La entrega y despliegue del SIIGETH debe realizarse de manera progresiva, para lo cual se

recomienda:

1. Priorizar los subsistemas y proceso de gestión del talento humano según su valorde negocio: la priorización de la implementación y de la implantación de los

módulos/aplicaciones del SIIGETH es una definición de negocio, que debe ajustarse a

la estrategia organizacional vigente y a la operatividad existente.

Una primera aproximación sobre la forma en la cual deben desplegarse los

componentes se indica en el anexo PRIORIZACION_PROCESOS_SIIGETH-v2.0.xlsx

(formato digital), en concordancia con las siguientes recomendaciones de esta sección.

2. Establecer dos etapas para la ejecución del proyecto: a fin de reducir el riesgo

inherente al gran alcance propuesto para el proyecto, se recomienda establecer dos

etapas para su ejecución:

• Primera etapa - Pilotos: en esta etapa se debe implementar la funcionalidad

total del SIIGETH y se lo debe implantar en un conjunto de instituciones públicas

pilotos, que caractericen o representen la gran mayoría de casos de

implantación. Al término de la primera etapa, la solución debe ser estable

(totalmente operacional y disponible según el LSA establecido) en todos los

pilotos.

• Segunda etapa - Expansión: en esta etapa, con base en la experiencia

adquirida durante la implantación y estabilización de los pilotos de la primera

etapa, se debe proceder a implantar y estabilizar la solución en las demás

instituciones públicas.

Una propuesta para la implantación progresiva de la solución se incluye en el anexo

PRIORIZACION_PROCESOS_SIIGETH-v2.0.xlsx (formato digital), cuyo resumen se

muestra en la tabla 6-1. Como se puede observar en el anexo, la opción de

implantación de una solución a la medida se desfasa con un semestre respecto a la

opción de implantación de un paquete comercial, lo cual se ha considerado al valorar el


41

riesgo de sobrepasar plazos incluido en el análisis realizado en el anexo

ANALISIS_RIESGO-v1.3.xlsx (formato digital).

6-1 Tiempos requeridos para implantar y estabilizar la solución

Alternativa

Tiempo total requerido paracompletar la puesta enproducción de todos lospilotos

Tiempo total requerido paracompletar la estabilizaciónde todos los pilotosincluido el tiempo requeridopara completar la puesta enproducción (columnaanterior)

Implantación de un paquetecomercial

5 [semestres] 6 [semestres]

Implantación de unasolución desarrollada a lamedida

6 [semestres] 7 [semestres]

Aparte del tiempo indicado para las dos opciones de la tabla 6-1, debe tomarse encuenta el tiempo necesario para la etapa de expansión, el cual se estima en 3semestres adicionales.Finalmente, ha de considerarse esta estrategia de ejecución del proyecto al momento

de estimar su costo total para las dos opciones definidas, principalmente en cuanto a los

costos de licenciamiento.

3. Combinar las mejores prácticas de la gestión de proyectos con un método ágilpara ejecutar la primera etapa del proyecto: la gestión administrativa, financiera,

logística, del cambio, de la comunicación, y de la expectativa, debe realizarse usando

las mejores prácticas de marcos de referencia el PMI (PMBOK y PMI-ACP), mientras

que el trabajo de implementación/implantación debe realizarse bajo un marco formal

ágil, siendo muy recomendable Scrum. La combinación de un marco formal de gestión

con un marco ágil para la implementación/implantación, se puede plasmar en un ciclo

de vida de 4 fases:

• Inicio:


42

Se realizan todas las acciones administrativas, legales y financieras necesarias

para arrancar el proyecto. Además, se conforma la contraparte institucional y se

habilitan las facilidades e instalaciones requeridas por el implementador y por la

contraparte institucional para realizar su trabajo.

• Elaboración y análisis:Se elaboran la especificación de requerimientos y los modelos arquitectónicos

mínimos necesarios para arrancar el proyecto (modelo de procesos, modelo de

arquitectura y tecnologías, modelo esencial de datos, modelo de navegación,

modelo de despliegue).

Además se establecen y socializan los estándares a considerarse en la

implementación, así como las prácticas y rituales que la metodología para

implementación/implantación indique.

Se conforman los equipos de desarrollo/implantación, se instalan las

herramientas para administrar el proyecto y para gestionar/realizar el trabajo

técnico, se realizan pruebas de concepto para validar la arquitectura y

plataforma de la solución propuesta, y se inicia la implementación/configuración

de los componentes comunes y transversales de la solución.

• Implementación e implantación:Se implementan y/o implantan de manera iterativa e incremental la plataforma,

las herramientas y los componentes tecnológicos de la solución, y a la par se

efectúa la gestión del cambio institucional en los pilotos.

Esta fase termina con la puesta en producción de los pilotos establecidos en el

modelo de gestión del proyecto.

• Estabilización:En esta fase se estabilizan las implantaciones de los pilotos, se enriquece la

base de conocimiento para gestión de incidencias y cambios, y se culmina la

transferencia de conocimiento desde el implementador hacia la contraparte

institucional, con base en lo cual finalmente se planifica la expansión o

implantación nacional de la solución.

La figura 6-1 Desarrollo de las fases a lo largo del tiempo, muestra el desarrollo de las

fases en el transcurso del tiempo (T), debiendo notarse la relación existente en la

duración de cada fase y la intensidad del trabajo (I) que cada fase implica, y debiendo

considerarse que las 4 fases aplican para la ejecución total del proyecto en los pilotos.


43

6-1 Desarrollo de las fases a lo largo del tiempo

4. No se recomienda la elaboración de un cronograma global sumamente detallado:el detalle debe delegarse a la microgestión de los subproyectos relativos a la

implementación, implantación y estabilización de cada subsistema o componente, para

que de esa forma el cronograma global del proyecto mantenga su propósito de

seguimiento y control estratégico.

5. Indicar en el contrato que los pagos se realizarán contra entrega de los productosprogramados en el plan de entrega: esto con el objeto de motivar al contratista a

entregar valor por valor, manteniendo un ritmo sostenido de trabajo, así como un

financiamiento también sostenido.

6. Indicar en el contrato que el plan de entrega puede ser perfeccionado por acuerdoentre el MDT y el contratista: el contrato y el TDR relativo no deben ser una camisa de

fuerza, sino una directriz clara y perfectible, lo cual aplica a la planificación de las

entregas, las cuales deben ejecutarse siempre en pos de brindar al MDT el mayor valor

posible dentro de un alcance acordado, flexible y factible.

7. Indicar explícitamente en los TDR los perfiles requeridos para los equipos dedesarrollo (en caso de desarrollo de la solución): la calidad y disponibilidad de los

recursos de los equipos de desarrollo deben ser comprobadas durante la calificación de

las ofertas. Un esbozo inicial de este requerimiento se incluye en el Anexo Perfilesmínimos recomendados para los equipos de desarrollo.


44

7 Elaboración de los requerimientos técnicos delSIIGETH

Los requerimientos técnicos iniciales del SIIGETH se anexan al presente informe en formato

digital: TDR-2.0 (formato digital)

Los requerimientos técnicos preparados son un insumo inicial que debe ser validado y

perfeccionado hasta la entrega del cuarto producto de la consultoría. Para realizar este trabajo

se requiere la definición de cuál de las alternativas de implementación es indicada por el MDT.


45

8 Anexos8.1 Propuestas enviadas por los proveedores de infraestructura

8.1.1 COMWARE

CON RESPECTO A LA INFRAESTRUCTURA:


46


47

CON RESPECTO AL LICENCIAMIENTO:

8.1.2 ANDEAN-TRADEAMBIENTE COMPONENTES SOFTWARE VIRTUALIZADO #

CORES

(vCPU)

MEMORIA

RAM (GB)

ALMACENAMIENTO

(TB)

PRODUCCIÓN

HCM RHEL SI

150 900 9

Gestión de Contenidos RHEL SI

Gestión de Accesos RHEL SI

Análisis de Inteligencia de

Negocios

RHEL SI

BPMN RHEL SI

Motor de reglas RHEL SI

SingleSingOn RHEL SI

Bus de Servicios RHEL SI


48

Portal de Auto-Servicio RHEL SI

ETL RHEL SI

Herramientas de Testing

(Carga, estrés, funcional)

RHEL SI

Elearning RHEL SI

Base de Datos RHEL

Oracle (Por

procesador)

SI

AMBIENTE COMPONENTES SOFTWARE VIRTUALIZADO #

CORES

(vCPU)

MEMORIA

RAM (GB)

ALMACENAMIENTO

(TB)

PRE

PRODUCCIÓN

HCM RHEL SI

50 300 3




Negocios

RHEL SI

BPMN RHEL SI





ETL RHEL SI



RHEL SI

Elearning RHEL SI

Base de Datos RHEL

Oracle (Por usuario

nombrado)

SI


CORES

(vCPU)

MEMORIA

RAM (GB)

ALMACENAMIENTO

(TB)

PRUEBAS

HCM RHEL SI

50 300 3




Negocios

RHEL SI

BPMN RHEL SI


49





ETL RHEL SI



RHEL SI

Elearning RHEL SI

Base de Datos RHEL

Oracle (Por usuario

nombrado)

SI


CORES

(vCPU)

MEMORIA

RAM (GB)

ALMACENAMIENTO

(TB)

DESARROLLO

HCM RHEL SI

32 216 2




Negocios

RHEL SI

BPMN RHEL SI





ETL RHEL SI



RHEL SI

Elearning RHEL SI

Base de Datos RHEL

Oracle (Por usuario

nombrado)

SI


50

8.1.3 SINERGY-HARD


51

8.2 TABULACION_FINAL_DE_ECUESTAS (formato digital)1. Se recibieron encuestas de 77 instituciones que atendieron a la solicitud de información

formulada por el MDT.

2. Para proceder a la tabulación de las encuestas se trasladó la información recibida a un

archivo Excel, y se realizó la extracción de la información por pregunta.

3. Se incorporó la respuesta de cada una de las instituciones diferenciándolas por su

nombre a cada pregunta en una hoja de cálculo separada.

4. Una vez organizada la información se obtienen las siguientes hojas:

a. Contactos

b. Desconcentración

c. Carga

d. Sistemas Internos

e. Sistemas MDT

f. Frecuencia Procesos

5. Para cada hoja de las mencionadas se creó una tabla dinámica que resume la

tabulación a cada una de las preguntas por institución, con excepción de la hoja

contactos que simplemente se queda con la información proveniente de cada una de las

instituciones.

6. Por último se tiene la aplicación de la calificación a cada institución dependiendo de sus

respuestas a cada una de las preguntas y obteniendo la calificación final por institución,

esto lo encontramos en la hoja resumen.


52

8.3 COMPARACION_TECNICA_DE_OPCIONES-v1.2.xlsx (formatodigital)

8.4 ESTIMACION_Y_ANALISIS_DE_COSTOS-v1.6.xlsx (formatodigital)

8.5 ANALISIS_RIESGO-v1.3.xlsx (formato digital)

8.6 COMPARACION_ALTERNATIVAS_IMPLANTACION_SIIGETH-v1.10.pptx (formato digital)

8.7 TDR-2.0 (formato digital)

8.8 PRIORIZACION_PROCESOS_SIIGETH-v2.0.xlsx (formato digital)

8.9 MATRIZ_INFRAESTRUCTURA_SIITH-v2.0.xlsx (formato digital)

8.10CALCULO_DE_DIMIENSIONAMIENTO-v1.3.xlsx (formato digital)

8.11Choosing_the_right_fron_end_framework-2013.pdf (formatodigital)

8.12Perfiles mínimos recomendados para los equipos de desarrollopara la opción de desarrollo a medida de la solución

8-1 Perfiles mínimos recomendados para los equipos de desarrollo

Perfil Experiencia Formación y capacitación

Líder de desarrollo (1) 5 años en la construcción

(hands-on) de sistemas de

información empresariales.

5 años en la conducción de

proyectos de desarrollo y/o

implantación de sistemas de


Título de segundo o tercer nivel en Ingeniería

o Ciencias, y 200 horas de capacitación

debidamente certificada en los siguientes

tópicos:

• Gestión de proyectos

• Metodologías

• Ingeniería de requerimientos


53

Es deseable que la

experiencia sea para sector

público.

• Análisis de requerimientos

• Tecnologías de desarrollo

• Patrones de diseño

• Programación en JEE

Arquitecto (1) 3 años en la construcción



3 años en diseño,

arquitectura e integración



Es deseable que la


público.




tópicos:

• Integración de plataformas

• Arquitecturas empresariales

• SOA


• Diseño de soluciones

• Desarrollo de soluciones en

tecnologías de plataforma abierta

basadas en Java

Analista de negocio /Dueño del producto (1)

3 años participando en la

implementación o

implantación de sistemas de

información empresariales,

con responsabilidad en la

definición, especificación y

aceptación funcional de

aplicaciones.

Es deseable que la


público.

Título de segundo o tercer nivel en

Ingeniería, Administración u otras carreras

de perfil técnico/social, y 100 horas de

capacitación debidamente certificada en los

siguientes tópicos:

• Metodologías


Desarrollador sénior (3) 3 años en el diseño y

desarrollo (hands-on) de

sistemas de información

empresariales.

Es deseable que la


público.




tópicos:

• Metodologías de desarrollo de

software




54

• Tecnologías empresariales para

desarrollo de software de plataforma

abierta



plataforma Java (JEE, Scala, etc.)

• Diseño y elaboración de pruebas

automatizadas de caja blanca y caja

negra

• Diseño, elaboración y ejecución de

pruebas funcionales y de pruebas de

desempeño

• Desarrollo en tecnologías de

plataforma abierta para front-end,

como: Ruby, Rails, Grails, JSF,

AngularJS, etc.

Desarrollador junior (3) 2 años en el diseño y

desarrollo (hands-on) de

sistemas de información.

Egresados o titulados de segundo o tercer

nivel en Ingeniería o Ciencias, y 100 horas

de capacitación debidamente certificada en

los siguientes tópicos:

• Tecnologías de desarrollo


• Elaboración de pruebas

automatizadas de caja blanca y caja

negra

• Elaboración y ejecución de pruebas

funcionales y de pruebas de

desempeño


tecnologías de plataforma abierta

Java (JEE, Scala, etc.)

• Desarrollo en tecnologías de

plataforma abierta para front-end,

como: Ruby, Rails, Grails, JSF,

AngularJS, etc.

Documents

INFORME DEL TERCER PRODUCTO DE LA CONSULTORÍA · 2.1.1 Dimensionamiento de la carga de usuarios y transaccionalidad del SIIGETH 2 ... para ser finalmente presentados en el cuarto