OBSERVACIONES NO SUBSANADAS POR INETUM DEL

ENTREGABLE 1.1.4
PROYECTO RENTESEG

09 de mayo de 2023
 I. CRONOGRAMA DEL PROYECTO

ÍNDICE II. RESUMEN DE LAS REITERACIONES DE OBSERVACIONES:

• ESCALABILIDAD
• FUNCIONALES
• OPERACIÓN DEL SISTEMA
III. RESUMEN DE FUNCIONALIDADES NECESARIAS NO
INCLUIDAS EN LAS BASES
 CRONOGRAMA DEL PROYECTO
Etapa: 1.1.1 Planificación

20 días 2 Periodos de Penalidad:

Observaciones
Inicio Entrega Aprobación S/ 27 000
6/7/2022 26/7/2022 30/9/2022

Etapa: 1.1.2 Análisis y Diseño

35 días 2 Periodos de
Inicio Entrega Observaciones Aprobación
6/7/2022 10/8/2022 12/10/2022

Etapa: 1.1.3 Documentación Penalidad:

35 días 3 Periodos de Aprobación S/ 9 800
Inicio Entrega
6/7/2022 10/8/2022 Observaciones 23/11/2022

Etapa: 1.1.4 Desarrollo e Implementación INETUM tiene plazo

90 días hasta el 16/05/2023
(En Ejecución) + retraso Observaciones 1ra Reiteración 2da Reiteración
Inicio Entrega 23/02/2023 29/03/2023 05/05/2023
13/10/2022 10/02/2023

Etapa: 1.1.5 Capacitación 10 días

(día siguiente de conformidad al 1.1.4) Inicio Entrega

Etapa: 1.2.1 Pruebas 30 días

(día siguiente de conformidad al 1.1.5)
Inicio Entrega
 RESUMEN REITERACIÓN DE OBSERVACIONES - Escalabilidad
1. Plan de Escalabilidad:

INETUM, en sus entregables, manifiesta reiteradamente que cualquier crecimiento (por ejemplo: agregar
nuevos concesionarios móviles, nuevas entidades públicas e incremento de usuarios) conllevaría a un
control de cambios.

Consecuencia: Riesgo de incurrir en control de cambios y adendas de contrato (posible pago adicional) por
el dimensionamiento del sistema por parte del contratista.
 RESUMEN REITERACIÓN DE OBSERVACIONES - Funcionales (1/4)
2. Reportes Inoperativos/Lista Negra/Lista Blanca:
Respecto al funcionamiento de lista negra, se detectó que un IMEI reportado como inoperativo se
encuentra en lista blanca y lista negra a la vez.

Consecuencia: Se generan errores en el funcionamiento, por ejemplo, en el proceso de Validación

Diaria y Altas Nuevas (un IMEI reportado como inoperativo funcionaría en la red).

3. Reportes SPR:
Respecto al funcionamiento del proceso en línea para el reporte de terminales sustraídos, perdidos y
recuperados, se realizó la prueba con un “IMEI no registrado en lista blanca”, que es reportado como
sustraído, luego reportado como recuperado; observándose que dicho IMEI se registra en lista
blanca.

Consecuencia: Filtración de terminales que no fueron registrados en lista blanca, y luego de una
recuperación se insertan en dicha lista (Un
IMEI que nunca se registró en lista blanca ingresaría a esta lista solo por el hecho de ser recuperado).
 RESUMEN REITERACIÓN DE OBSERVACIONES - Funcionales (2/4)
4. Lista Blanca:
No se evidencia la implementación del proceso de regularización por no registro en lista blanca, tanto por
registro de terminales importados como de terminales adquiridos en el extranjero.

Consecuencia: Usuarios que adquieran legamente un equipo terminal móvil en una casa comercializadora o
empresa operadora (que por algún error el importador no registró dicho equipo) no podrían regularizar el
registro. El equipo nunca podría salir de lista negra y tampoco se podría regularizar el
registro en la Lista Blanca.

5. Registro de Abonados:
INETUM no ha considerado la realización de las pruebas mínimas necesarias que garanticen el
funcionamiento correcto para los casos de cambio de número de servicio móvil.

Consecuencia: No sería posible tener el número original antes de dicho cambio y contar con información
para la trazabilidad.
 RESUMEN REITERACIÓN DE OBSERVACIONES - Funcionales (3/4)

6. Módulo de Consulta de Entidades del Estado:

INETUM aún no implementa el formato descargable en PDF para emitir constancia de las consultas en el
Módulo de Entidades del Estado.

Consecuencia: Entidades del Estado no podrán descargar un formato que contenga los datos consultados,
así como los datos del consultante, la fecha y hora de la consulta. Este formato será ingresado a las
carpetas de investigación de las entidades.

7. Módulo de Administración de Usuarios:

Se requiere la corrección de las observaciones (funcionales, no funcionales) reportadas.
Existen funcionalidades que no fueron consideradas y el proveedor esta evaluando para implementarlas.

Consecuencia: No tendremos una correcta administración del sistema desarrollado.

 RESUMEN REITERACIÓN DE OBSERVACIONES - Funcionales (4/4)

8. Seguridad de Información:

 Se observa que después de la creación del usuario, se envía en texto claro la contraseña por correo,
lo cual no es una buena práctica. En su lugar debe de enviársele un link que le permita establecer su
contraseña.
 El enlace de restablecimiento no debe poder ser usado más de una vez.
 La página de restablecer contraseña también debe contar con un control captcha.
 Dentro de las opciones del módulo de auditoría debe incluirse la opción de descargar en Excel de los
registros visualizados.

Consecuencia: Omisión de buenas prácticas de seguridad de la información para la implementación del

sistema que pudieran conllevar a una exposición de información o un acceso no autorizado.
 RESUMEN REITERACIÓN DE OBSERVACIONES - Operación (1/2)
9. Base de datos:
No se evidencia implementación de registro de cambios en la Base de datos del RENTESEG.

Consecuencia: No se cuente con información de cambios (creación, modificación y borrado) realizados

directamente en base de datos, ni se registre la interacción con los datos personales lo cual es requerido
por la Ley de Protección de Datos Personales.

10. Back Up del Sistema RENTESEG:

Se observa en la información presentada por INETUM, que el periodo de retención para los backs up será
de 6 días; sin embargo, en la política de seguridad de la información se determina que los respaldos
diarios se deben conservar 30 días, las copias de respaldo semanales son conservadas por 4 semanas y las
copias de respaldo mensual son conservadas de forma indefinida.

Consecuencia: Omisión de política de seguridad de la información que debe cumplir el contratista según el
contrato suscrito. De existir un caso en que se requiera contar con información de más de 6 días, se
generaría un escenario de perdida de información.
 RESUMEN REITERACIÓN DE OBSERVACIONES - Operación (2/2)

11. Migración de la Información de Fase 2:

Respecto al informe de migración de información histórica, INETUM señala que la migración de ficheros
RENTESEG Fase 2 debe realizarla OSIPTEL; ya que INETUM señala que en uno de los documentos de
plan de migración se incluyó que esta actividad sería realizada por OSIPTEL.

Consecuencia: OSIPTEL incurriría en costos adicionales al tener que desarrollar un programa de

migración y contratar personal adicional para realizar dicha actividad.
PUNTOS SOBRE LOS QUE NO SE REITERÓ OBSERVACIONES, PERO SON NECESARIOS
PARA LA OPERACIÓN

1.
Reemplazo de ficheros solicitado por los concesionarios móviles por haber
detectado algún error en dicho fichero. Ejemplo: el concesionario móvil no podría
corregir ficheros que remitió anteriormente.

2.
Notificaciones por correo electrónico por archivos procesados correctamente. Solo se
notifica cuando exista errores o no presenta reporte. Ejemplo: el concesionario móvil
y el OSIPTEL no seria notificado del procesamiento correcto de sus archivos.

Definir cuotas para órdenes de bloqueo de IMEI clonado o no registrado en lista

3. blanca, de manera que la cantidad de bloqueos diarios se pueda configurar en el

sistema.
Se estima que al inicio de la Tercera fase, se ordenaría el bloqueo de 500 000
terminales móviles (solo detectados como clonados intrared).
SOLICITUDES DE INETUM DE PRESTACIONES ADICIONALES (1/2)
1era solicitud de prestación adicional - migración de data de la fase 2 a la fase 3

Postura OSIPTEL: No es una prestación adicional (la cifra consignada en las bases corresponde a 2 reportes a migrar
y no a todos los reportes a migrar – EIR/Listas de Vinculación).
 
En las bases se indica que deben migrar un listado (más de 10 fuentes: Registro de Abonados, Reporte de equipos
robados, IMEI inválido, EIR, Listas de Vinculación, entre otros). Se consignó en los TDRs de forma referencial el
detalle de 1400 millones de registros que corresponden al Registro de Abonados y Reporte de Equipos robados.

Acciones de INETUM: Se está considerando en los planes de Migración.

2da solicitud prestación adicional - Procesamiento de información del Registro de Abonados (100 millones
diarios).

Postura OSIPTEL: Se ha pedido que se estrese su programa con 50 millones de registros, ello no corresponde a un
requerimiento funcional básico por parte del CT del RENTESEG. Este requerimiento es parte de una prueba y no
parte de una necesidad del sistema. 

Acciones de INETUM: ha modificado el sistema para el procesamiento de hasta 50 millones de registros.

SOLICITUDES DE INETUM DE PRESETACIONES ADICIONALES (2/2)

3era Solicitud de prestación adicional - Regularización de IMEI bloqueados por no estar en Lista Blanca
regularizados

Postura OSIPTEL: El Comité Técnico del RENTESEG advirtió la casuística de qué ocurriría con los “IMEI que
fueron bloqueados por no estar en Lista Blanca y que luego son regularizados” y solicitó a INETUM se
considere la casuística considerando lo siguiente:
• En las bases se especifica que si un IMEI está en lista blanca no puede estar en Lista Negra y en este caso
no se cumple esta validación.
• En las bases se indica que el contratista debe realizar todo tipo de validaciones a fin de asegurar la
consistencia de la información.
• En un documento ya presentado por INETUM (Manual de operatividad) está incluido el caso de
desbloqueo justificado.

En consecuencia, no es una prestación adicional sino una característica propia del Sistema.

Acciones de INETUM: No lo ha implementado pero ya lo ha agregado al Diseño del Sistema.

Escalabilidad

Plan de Escalabilidad

Regresar
Reportes Inoperativos/Lista Negra/Lista Blanca

Regresar
Reporte SPR

Regresar
Regularización no registro en Lista Blanca

Regresar
Regularización no registro en Lista Blanca

Reporte con error para cambio de número móvil, sin embargo no se observa un caso exitoso.

Regresar
Registro de cambios en la Base de datos

Regresar
Registro de cambios en la Base de datos

Regresar
Migración de la Información de Fase 2