ANALISIS DEL INFORME FINAL DE LA OEA SOBRE LOS HALLAZGOS DE

LA AUDORIA PARA DETERMINAR CAUSAS DEL NO

FUNCIONAMIENTO DEL VOTO AUTOMATIZADO ABRIL 2020

INTRODUCCION

Previamente habíamos hecho un documento que, a la luz de cualquier experto en tecnología de

información y en desarrollo de aplicaciones, los eventos que se venían presentando desde el 15 de
febrero del 2020 en horas de la noche y que culminó con la suspensión de las elecciones,
evidenciaba una falla en la cadena de gestión del proceso tanto a nivel técnico como a nivel de
decisión.

Sin embargo, se necesitaba esperar que la OEA evacuara el informe en cuestión para poder
confirmar y validar los todos los detalles que solo las instituciones acreditadas para la auditoria
podrían obtener.

PUNTOS A RESALTAR DEL INFORME

Cita No.1:

La causa raíz del problema puede encontrarse en el software diseñado para la personalización de
las urnas, es decir, el software utilizado para que cada máquina contara con la oferta electoral y
demás datos correspondientes a su mesa. Este software no tenía mecanismos de control de
integridad de la oferta electoral y, por lo tanto, era incapaz de detectar cualquier tipo de problema
que se pudiera haber presentado en el proceso de descarga de las boletas electrónicas.

Comentario:

Los Mecanismos de Control, son REGLAS DE NEGOCIO. Los informáticos no crean solo estos
mecanismos de control para garantizar el comportamiento de la lógica algorítmica y evitar/mitigar
errores de corridas en producción. Estos Mecanismos de Control también de carácter
procedimental. Por eso en ingeniería de Software existe los conceptos de Software Quality
Asssurance - SQA (Que vela por la calidad del código que significa que el software haga lo que se
espera) y se Quality Assurance (Que vela por la calidad con que se lleva el proceso de gestión de
desarrollo o implementación de un software). En esta cita se fallaron tanto en SQA como en QA de
manera tan elemental que, considéralo simples errores, es minimizar un posible hecho doloso o de
negligencia.

Cita No.2:

Sumado a lo anterior, la inexistencia de procedimientos formales de prueba del software, impidió

que se detectase el defecto durante la fase de “testing” (pruebas).
Comentario:

La inexistencia de procedimientos de pruebas de Software (SQA) es la consecuencia de no establecer

procesos formales de desarrollo de software, que en su gran medida existen para garantizar que los
productos se entreguen en: el tiempo esperado, con las funciones esperadas y con los costos
estimados. Como se deja en manos de un proceso como son las votaciones de un país sin una
herramienta de gestión de software, tan vital?

Cita No.3:

El equipo de auditoría pudo comprobar la inexistencia de requerimientos formales en el diseño del

software lo que facilitó, en consecuencia, este error en el desarrollo del mismo (no controlar la
integridad de la oferta electoral).

Comentario:

Los requerimientos formales de diseño del software (Requirements Management (REQM)) tiene
como propósito la Gestión de Requerimientos (REQM). Que significa gestionar los requerimientos
de los diferentes componentes del proyecto (tantos técnicos como de negocio) y garantizar la
gestión de los requerimientos con los planes del proyecto (PMI). En otras palabras, lo que comienza
mal, termina mal. REQM es zapata necesaria para hacer un software y establecer los parámetros de
calidad y satisfacción de los objetivos.

Cita No.4:

La Dirección de Informática de la JCE tenía previsto descargar la oferta electoral a cada una de las
máquinas en su almacén denominado “La Colina”, utilizando para ello una red LAN (Local Area
Network). Al descubrir que, con los recursos que contaban hasta el momento, este proceso llevaría
más tiempo de lo que tenían planeado y, por tanto, no llegarían a finalizarlo antes de la fecha
prevista para el despliegue de las máquinas a los recintos electorales, se decidió utilizar mecanismos
de transferencia de la información que no sólo no estaban previstos, sino que tampoco fueron
evaluados.

Comentario:

Esto necesitaba prorrogar la fecha de las elecciones. Es evidente una mala gestión del plan de
trabajo del proyecto (asumiendo que no fue a propósito) que daría al traste con esta actividad,
teniéndose que realizar otras actividades para usar otros mecanismos de transmisión, creando
brechas de seguridad que pudieron ser explotadas el día de las elecciones o la noche anterior.

Cita No.5:

El sábado 15 de febrero por la tarde, con los kits de votación ya desplegados en los distintos recintos
electorales de los municipios con voto automatizado, de acuerdo a la Dirección de Informática
“...algunos kits de votación no contenían la planilla de candidatos completa”.

Comentario:

NUNCA SE PUEDE PONER UN SISTEMA EN PRODUCCION SIN HABER SIDO APROBADO POR EL
PROCESO DE QA Y SQA
En otras palabras, todo lo que sucede en un sistema donde se viole el procedimiento, es responsable
de todas las cadenas de aprobación, eso incluye la autoridad máxima.

Cita No.6:

En la reunión que la JCE sostuvo con los partidos, se acordó a las 9:40 pm del sábado la suspensión
del operativo para enmendar el problema. Alrededor de la medianoche, resolvieron que sea
realizaría entre las 5:00 a.m. y 7:00 a.m. del día de la elección, en presencia de los delegados de los
partidos políticos.

Sin embargo, el proceso para enmendar la situación en horas de la mañana del domingo de
elecciones no logró corregir los problemas. A la hora contemplada para iniciar la votación, muchos
de los equipos de votación (el número exacto no es revelado en el Informe de la Dirección Nacional
de Informática) no contaban con la oferta electoral completa.

Comentario:

NUNCA SE PUEDE HACER CAMBIOS A UN SISTEMA MIENTRAS EL MISMO ESTE OPERANDO O ESTE
EN PRODUCCION

Desde que se desplegaron los kits, debió estar prohibido cualquier cambio al sistema. No solo del
código fuente (que no es el caso) sino también de la data de la configuración puesto que la misma
forma parte de los insumos del proceso de SQA.

Aunque las configuraciones suelen ser herramientas que facilitan el despliegue de los productos de
software, así como su adaptabilidad al proceso (en este caso, la aplicación usaba datos de
configuración para formar la boleta de la oferta electoral según su demarcación), una vez puestas
en producción solo pueden ser cambiadas mediante un requerimiento salido de un registro de fallo
de la configuración, la cual debe explicar lo que sucedía y bajo qué condiciones. Con esta
información, esto levantaría un requerimiento de cambio el cual a su vez debería ser probado y
luego pasado a producción.

CONCLUSION
En el informe de la OEA esta la sección de Hallazgos la cual presenta 21 puntos lo cuales son todos
muy importantes, solo queremos resaltar aquel que consideramos el núcleo origen de todos los
demás:

Cita:

18. No se cuenta con un proceso formal de desarrollo de software. Si bien el personal que
desarrolla es experimentado y calificado, no cuenta con un procedimiento formal para el
desarrollo, las pruebas ni la liberación del software.

No tener un “procedimiento formal de desarrollo” es como tratar de lanzar un cohete al espacio,

sin un procedimiento para el mismo, el cual no solo cuente con todos los aspectos técnicos para
llevarlo a cabo, sino con todos los pasos para garantizar que esos aspectos técnicos cumplan con
procesos de validación, incluyendo el mismo sistema de gestión. Un error en este ámbito, termina
en gastos millonarios y pérdidas humanas.

En el caso de las votaciones suspendidas del 16 de febrero del 2020, el “Cohete” (voto
automatizado) explotó porque no se previó por parte de todos los niveles de dirección, que algo tan
complejo debió tener un procedimiento que diera garantías, creando oportunidades para el fallo o
error humano y dejando la puerta abierta para que alguien pudiera explotar esta debilidad.