propuesta para trabajo de grado - trabajos de grado de la...

PA111-01 MODELO DE ARQUITECTURA DE SISTEMA DEL VOTO ELECTRÓNICO EN EL

MUNICIPIO DE CHOACHÍ

DANIEL YESID CACERES RINCON

PONTIFICIA UNIVERSIDAD JAVERIANA

FACULTAD DE INGENIERIA

MAESTRÍA EN INGENIERÍA DE SISTEMAS Y COMPUTACIÓN

BOGOTÁ, D.C.

2012

Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización

Página i

Preparado por el Grupo Investigación Istar- Versión 1.0 – 12/03/2008

PA111-01

MODELO DE ARQUITECTURA DE SISTEMA DEL VOTO ELECTRÓNICO EN

EL MUNICIPIO DE CHOACHÍ

Autor:

Daniel Yesid Cáceres Rincón

MEMORIA DEL TRABAJO DE GRADO REALIZADO PARA CUMPLIR UNO

DE LOS REQUISITOS PARA OPTAR AL TITULO DE

MAGÍSTER EN INGENIERÍA DE SISTEMAS Y COMPUTACIÓN

Director

Ing. Rafael Andrés González Rivera, PhD.

Comité de Evaluación del Trabajo de Grado

Ing. Diego Torres, MA.

Ing. Miguel Torres, Msc.

Página web del Trabajo de Grado

http://pegasus.javeriana.edu.co/~PA111-01

PONTIFICIA UNIVERSIDAD JAVERIANA

FACULTAD DE INGENIERIA

MAESTRÍA EN INGENIERIA DE SISTEMAS Y COMPUTACIÓN

BOGOTÁ, D.C.

Enero, 2012

Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01

Página ii

PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERIA

CARRERA DE INGENIERIA DE SISTEMAS

Rector Magnífico

Joaquín Emilio Sánchez García S.J.

Decano Académico Facultad de Ingeniería

Ingeniero Luis David Prieto Martínez

Decano del Medio Universitario Facultad de Ingeniería

Padre Sergio Bernal Restrepo S.J.

Director Maestría en Ingeniería de Sistemas y Computación

Ingeniero Enrique González Guerrero

Director Departamento de Ingeniería de Sistemas

Ingeniero César Julio Bustacara Medina


Página iii


Artículo 23 de la Resolución No. 1 de Junio de 1946

“La Universidad no se hace responsable de los conceptos emitidos por sus alumnos en sus

proyectos de grado. Sólo velará porque no se publique nada contrario al dogma y la moral

católica y porque no contengan ataques o polémicas puramente personales. Antes bien, que

se vean en ellos el anhelo de buscar la verdad y la Justicia”


Página iv

AGRADECIMIENTOS

Quiero dar agradecimientos muy especiales en primer lugar a mis padres, por permitirme tener la oportunidad de realizar esta maestría, a mi director de proyecto quien me guio durante todo el tiempo para poder lograr la meta de este proyecto. De igual forma, agradezco al registra-dor municipal de Choachí Dr. Jorge Díaz, al personero de Choachí Dr. Diego Julián Pardo Rincón, a los ingenieros Julio Carreño y José Niño quienes estuvieron siempre muy colaboradores conmigo y con el desarro-llo del proyecto.


Página v


Contenido

INTRODUCCIÓN ..............................................................................................................1

I - OBJETIVOS ................................................................................................................3

1. OBJETIVOS ..................................................................................................................3 1.1 Objetivo General ........................................................................................................... 3 1.2 Objetivos Específicos..................................................................................................... 3 1.3 Definiciones ................................................................................................................... 4 1.4 Acrónimos ...................................................................................................................... 4

II – MARCO TEÓRICO ...................................................................................................5

III - MÉTODO .................................................................................................................6

IV – MODELO DE ARQUITECTURA DE SISTEMA ...........................................................9

1. MODELO DE ARQUITECTURA EMPRESARIAL ...............................................................9 1.1 Selección de Vistas ...................................................................................................... 10 1.2 Actores ......................................................................................................................... 10 1.3 Stakeholders ................................................................................................................ 12 1.4 Vista Introductoria (Introductory Viewpoint) ............................................................. 13 1.5 Vista de la Organización (Organization Viewpoint) ................................................... 18 1.6 Vista de Co-operación de Actores (Actor Co-operation viewpoint) ........................... 19 1.7 Vista de Proceso de Negocio (Business Process Viewpoint) ...................................... 20 1.8 Vista de Co-operación del Proceso de Negocio (Business Process Co-operation

Viewpoint) ......................................................................................................................... 25 1.9 Vista de Comportamiento de la Aplicación (Application Behavior Viewpoint) .......... 27 1.10 Vista de Infraestructura (Infrastructure Viewpoint) ................................................. 30

2. MODELO DE ARQUITECTURA DE SOFTWARE .............................................................31 2.1 Identificación y Selección de Patrones de Negocio ..................................................... 35 2.2 Introducción al Patrón de Arquitectura N-Tier .......................................................... 38 2.3 Identificación y Selección de Patrones de Diseño ....................................................... 39

3. DISEÑO DE LA BASE DE DATOS PARA EL VOTO ELECTRÓNICO ..................................48 3.1 Diseño Lógico de la Base de Datos para el Proceso de Inscripción de Electores y

Candidatos......................................................................................................................... 48 3.2 Diseño Lógico de la Base de Datos para el Proceso de Votación .............................. 48

V – PROTOTIPO Y VALIDACIÓN ..................................................................................51

1. PROTOTIPO ................................................................................................................51


Página vi

2. VALIDACIÓN DE LA ARQUITECTURA EMPRESARIAL ..................................................52 2.1 Validación Sintáctica realizada por el Ing. José C. Niño ........................................... 53 2.2 Validación Semántica realizada por el Registrador municipal de Choachí, Dr. Jorge

A. Díaz ............................................................................................................................... 54

3. VALIDACIÓN DE LA ARQUITECTURA DE SOFTWARE ..................................................54 3.1 Validación según ATAM .............................................................................................. 54 3.2 Validación TAM .......................................................................................................... 57

VI - CONCLUSIONES ....................................................................................................60

VII – TRABAJO FUTURO ..............................................................................................63

VIII – BIBLIOGRAFÍA ..................................................................................................64

IX – ANEXOS ................................................................................................................69

1. ANEXO A ..................................................................................................................69

2. ANEXO B ...................................................................................................................89

3. ANEXO C ...................................................................................................................90

4. ANEXO D ..................................................................................................................93

5. ANEXO E ...................................................................................................................98

6. ANEXO F .................................................................................................................105

7. ANEXO G ................................................................................................................107

8. ANEXO H ................................................................................................................108


Página vii


Lista de Tablas

Tabla 1. Definiciones ................................................................................................................ 4

Tabla 2. Acrónimos ................................................................................................................... 4

Tabla 3. Capas y vistas............................................................................................................ 10

Tabla 4. Actores ...................................................................................................................... 12

Tabla 5. Stakeholders .............................................................................................................. 13

Tabla 6. Arquitectura empresarial: Stakeholders vs Actores .................................................. 13

Tabla 7. Mapeo de Actores CU actual vs Actores Arquitectura Empresarial vs Actores CU E-

Vote2 ....................................................................................................................................... 33

Tabla 8. Procesos de la registraduría municipal de Choachí vs Procesos según BPTrends.

Autor: Daniel Cáceres. ............................................................................................................ 35

Tabla 9. Patrones de negocio de Forster vs Procesos de negocio de la Registraduría municipal

de Choachí. Autor: Daniel Cáceres ......................................................................................... 36

Tabla 10. Patrones de negocio de Forster vs Procesos de negocio de la Registraduría

municipal de Choachí. Autor: Daniel Cáceres ........................................................................ 37

Tabla 11. Patrones de negocio de Kim et Al. vs Procesos de negocio de la Registraduría

municipal de Choachí. Autor: Daniel Cáceres. ....................................................................... 38

Tabla 12. Aplicaciones vs Atributos de calidad ...................................................................... 41

Tabla 13. Aplicaciones vs Atributos de Calidad según Khosravi y Guéhéneuc ..................... 41

Tabla 14. Aplicación Registro Candidato vs Patrones de diseño ............................................ 42

Tabla 15. Aplicación registro elector vs Patrones de diseño .................................................. 42

Tabla 16. Aplicación votación vs Patrones de diseño ............................................................. 42

Tabla 17. Aplicación resultados escrutinio vs Patrones de diseño .......................................... 43


Página viii

Tabla 18. Relación de patrones en el nivel 1 de diseño .......................................................... 46

Tabla 19. Resumen Aplicación de ATAM sobre la arquitectura de sistema del voto

electrónico ............................................................................................................................... 56

Tabla 20. Patrón Service Factory - CU Almacenar formularios en DB .................................. 57

Tabla 21. Patrón Service Factory – CU Almacenar registro electores ................................... 57

Tabla 22. Resultados registrador TAM ................................................................................... 59

Tabla 23. Resultados ciudadanos TAM .................................................................................. 59

Tabla 24. Descripción de los patrones de Web Services ........................................................ 90

Tabla 25. Elector ..................................................................................................................... 90

Tabla 26. Cierre proceso electoral .......................................................................................... 90

Tabla 27. Inicio proceso Electoral .......................................................................................... 90

Tabla 28. Proceso electoral ..................................................................................................... 91

Tabla 29. Municipio ................................................................................................................ 91

Tabla 30. Departamento .......................................................................................................... 91

Tabla 31. Inscripción elector ................................................................................................... 92

Tabla 32. Inscripción candidato .............................................................................................. 92

Tabla 33. Cargo candidato ...................................................................................................... 92

Tabla 34. Aval ......................................................................................................................... 92

Tabla 35. Partido político ........................................................................................................ 93

Tabla 36. Tipo Aval ................................................................................................................ 93

Tabla 37. Puesto ...................................................................................................................... 93

Tabla 38. Mesa ........................................................................................................................ 93

Tabla 39. Boletín ..................................................................................................................... 94

Tabla 40. Cargo jurado ........................................................................................................... 94

Tabla 41. Jurado ...................................................................................................................... 94


Página ix


Tabla 42. Participantes ............................................................................................................ 94

Tabla 43. Otro tipo .................................................................................................................. 95

Tabla 44. Inscrip ..................................................................................................................... 95

Tabla 45. Candidato ................................................................................................................ 95

Tabla 46. Partido ..................................................................................................................... 96

Tabla 47. Candidato consulta .................................................................................................. 96

Tabla 48. Voto alcaldía ........................................................................................................... 96

Tabla 49. Voto concejo ........................................................................................................... 96

Tabla 50. Voto consulta .......................................................................................................... 96

Tabla 51. Voto ........................................................................................................................ 97

Tabla 52. Corporación ............................................................................................................ 97

Tabla 53. Casos de Uso y atributos de calidad para validación ATAM ............................... 112

Tabla 54. Patrón Service Factory - CU Almacenar formularios en DB ................................ 113

Tabla 55. Patrón Service Factory - CU Almacenar registro candidatos ............................... 114

Tabla 56. Patrón Service Factory - CU Almacenar registro electores .................................. 114

Tabla 57. Patrón Business Process (Composition) - CU Almacenar conteo preliminar ....... 114

Tabla 58. Patrón Business Process (Composition) - CU Almacenar reports ........................ 115

Tabla 59. Patrón Business Process (Composition) - CU Almacenar votos del sistema ........ 115

Tabla 60. Patrón Business Process (Composition) - CU Bajar servicio jornada de votación 116

Tabla 61. Patrón Business Process (Composition) - CU Bajar servicio post-elección ......... 116

Tabla 62. Patrón Business Process (Composition) - CU Bajar servicios de validación

biométrica y código de barras ............................................................................................... 116

Tabla 63. Patrón Business Process (Composition) - CU Cerrar jornada post-elección ........ 117

Tabla 64. Patrón Business Process (Composition) - CU Cerrar jornada de votación ........... 117

Tabla 65. Patrón Service Factory - CU Cerrar proceso de inscripciones candidatos ............ 118


Página x

Tabla 66. Patrón Service Factory - CU Cerrar proceso de inscripciones electores .............. 118

Tabla 67. Patrón Business Process (Composition) - CU Crear DB de registro .................... 118

Tabla 68. Patrón Business Process (Composition) - CU Crear DB de votos ........................ 119

Tabla 69. Patrón Business Process (Composition) - CU Crear formularios E-24/E-26 ....... 119

Tabla 70. Patrón Service Factory - CU Crear una DB de registro candidatos ...................... 120

Tabla 71. Patrón Service Factory - CU Crear una DB de registro electores ......................... 120

Tabla 72. Patrón Business Process (Composition) - CU Generar certificado electoral ........ 120

Tabla 73. Patrón Business Process (Composition) - CU Generar certificado inscripción

alcaldía .................................................................................................................................. 121


concejo .................................................................................................................................. 121


electoral ................................................................................................................................. 121

Tabla 76. Patrón Business Process (Composition) - CU Habilitar acceso a la interface de

votación ................................................................................................................................. 122

Tabla 77. Patrón Service Factory - CU Iniciar proceso inscripciones candidatos ................ 122

Tabla 78. Patrón Service Factory - CU Iniciar proceso inscripciones electores ................... 123

Tabla 79. Patrón Business Process (Composition) - CU Iniciar jornada de votación ........... 123

Tabla 80. Patrón Business Process (Composition) - CU Iniciar servicio jornada votación .. 123

Tabla 81. Patrón Business Process (Composition) - CU Iniciar servicios jornada post-elección

.............................................................................................................................................. 124

Tabla 82. Patrón Business Process (Composition) - CU Iniciar servicio jornada post-elección

.............................................................................................................................................. 124

Tabla 83. Patrón Business Process (Composition) - CU Iniciar servicio de validación

biométrica y código de barras ............................................................................................... 124

Tabla 84. Patrón Business Process (Composition) - CU Monitorear el sistema de votación 125

Tabla 85. Patrón Service Factory - CU Validar el elector en jornada de votación ............... 125


Página xi


Tabla 86. Patrón Service Factory - CU Validar mediante lector biométrico y código de barras

en jornada de inscripción ...................................................................................................... 126

Lista de Figuras

Figura 1. Modelo de la Ciencia basada en el diseño. Fuente: [38]. .......................................... 7

Figura 2. Vista introductoria (previa) ..................................................................................... 14

Figura 3. Vista de la organización (previa) ............................................................................. 18

Figura 4. Vista de co-operación de actores (previa) ............................................................... 19

Figura 5. Vista de proceso de negocio (previa) ...................................................................... 20

Figura 6. Vista de co-operacion del proceso de negocio (previa) ........................................... 25

Figura 7. Vista de comportamiento de la aplicación (previa) ................................................. 28

Figura 8. Vista de Infraestructura (previa) .............................................................................. 30

Figura 9. Estado actual de la registraduría municipal de Choachí con respecto al voto (previa)

................................................................................................................................................ 32

Figura 10. Estado deseado del voto electrónico en el municipio de Choachí (previa) ........... 34

Figura 11. Diseño de alto nivel: Patrón arquitectónico general N-Tier para el voto electrónico

................................................................................................................................................ 38

Figura 12. Tabla de comparación atributos de calidad vs patrones de diseño. Autor: Khosravi

y Guéhéneuc. Modificada por: Anónimo. ............................................................................... 40

Figura 13. Mapeo de aplicaciones a patrones GOF y a patrones de Web Services ................ 44

Figura 14. Diseño detallado (nivel 1): Patrón N-Tier más Patrones Web Services ................ 45

Figura 15. Diseño detallado (nivel 2) del voto electrónico ..................................................... 47

Figura 16. Modelo lógico del proceso de inscripción de candidatos y electores .................... 49

Figura 17. Modelo lógico del proceso de votación ................................................................. 50


Página xii

Figura 18. Modelo BPMN del subproceso de Inscripción de candidatos y electores ............. 51

Figura 19. Inscripción del candidato ....................................................................................... 52

Figura 20. Modelo de Aceptación de la Tecnología. Fuente: Davis [69] ............................... 58

Figura 21. Vista introductoria parte A. ................................................................................... 70

Figura 22. Vista introductoria parte B .................................................................................... 71

Figura 23. Vista introductoria parte C .................................................................................... 72

Figura 24. Vista de la organización ........................................................................................ 73

Figura 25. Vista de co-operación de actor .............................................................................. 74

Figura 26. Vista del proceso de negocio parte A .................................................................... 75

Figura 27. Vista del proceso de negocio parte B .................................................................... 76

Figura 28. Vista del proceso de negocio parte C .................................................................... 77

Figura 29. Vista de co-operación del proceso de negocio parte A .......................................... 78

Figura 30. Vista de co-operación del proceso de negocio parte B .......................................... 79

Figura 31. Vista de co-operación del proceso de negocio parte C .......................................... 80

Figura 32. Vista de co-operación del proceso de negocio parte D .......................................... 81

Figura 33. Vista del comportamiento de la aplicación parte A ............................................... 82

Figura 34. Vista del comportamiento de la aplicación parte B ............................................... 83

Figura 35. Vista del comportamiento de la aplicación parte C ............................................... 84

Figura 36. Vista del comportamiento de la aplicación parte D ............................................... 85

Figura 37. Vista de infraestructura .......................................................................................... 86

Figura 38. Estado actual de la registraduría municipal de Choachí para el voto .................... 87

Figura 39. Estado ideal de la registraduría municipal de Choachí para el voto electrónico ... 88

Figura 40. Modelo BPMN del proceso electoral .................................................................... 98

Figura 41. Modelo BPMN del subproceso de inscripción ...................................................... 99


Página xiii


Figura 42. Modelo BPMN del subproceso de inscripción de candidatos ............................. 100

Figura 43. Modelo BPMN del subproceso de inscripción de electores ................................ 101

Figura 44. Modelo BPMN del subproceso de votación ........................................................ 102

Figura 45. Modelo BPMN del subproceso de votación para alcaldía ................................... 103

Figura 46. Modelo BPMN del subproceso de votación para concejo ................................... 104


Página xiv

ABSTRACT

This document describes the process that took place during the project in order to build a

viable electronic voting system architecture to implement in the municipality of Choachí,

understanding the needs of the project environment defined by the Registraduría and the

population, and linking them to the construction of the proposal from the business as the

software field.

RESUMEN

El presente documento describe todo el proceso que se llevó a cabo durante el desarrollo del

proyecto para lograr construir una arquitectura de sistema viable para implementar en el

municipio de Choachí el voto electrónico, entendiendo las necesidades del entorno del pro-

yecto definidos por la registraduría y la población, y ligándolas a la construcción de la pro-

puesta desde el ámbito empresarial como el ámbito software.


Página xv


RESUMEN EJECUTIVO

El presente documento describe la totalidad del proceso que se llevó a cabo durante el desa-

rrollo del proyecto para lograr construir una arquitectura de sistema viable para implementar

en el municipio de Choachí el voto electrónico.

Factores como el hecho de que Colombia no tuviera implementado nada con respecto al voto

electrónico a pesar de la connotación que esta ha tenido en el mundo, la ausencia electoral

reconocida por la población como diferencias al actual sistema de votación, necesidad de

complementar las leyes que se han creado para reducir el fraude y la corrupción electoral, la

consideración de ampliar el marco electoral para los discapacitados sin restringirlos a su re-

conocimiento con un tiempo demasiado lejano de la fecha electoral y reducir o abolir los

problemas judiciales post-electorales por incertidumbre en la calidad de los escrutinios son

elementos que hicieron dar cabida a plantear este proyecto

De ahí, que la problemática que se planteara se contemplara en 2 partes: por un lado se debía

analizar la capacidad del municipio de Choachí para implementar un sistema de voto electró-

nico basado en la legislación actual colombiana así como en los parámetros de la Registradu-

ría Nacional del Estado Civil; y por el otro lado, se debía reconocer cual sería la arquitectura

de mayor viabilidad a nivel de seguridad, auditabilidad y usabilidad para desarrollarla en el

municipio.

Entendiendo las necesidades del entorno del proyecto, definidos por la registraduría y la po-

blación, y luego analizando distintos elementos teóricos del voto electrónico (así como los

desarrollos actuales – arquitecturas - que se han planteado para el mismo en los países donde

se ha implementado) como metodologías para la construcción de arquitecturas tanto empresa-

riales como de software, se constituyó el modelo de arquitectura de sistema para el voto elec-

trónico que se expone a lo largo de este documento.

El uso de la metodología de la ciencia basada en el diseño, que sirvió de método para el desa-

rrollo de este proyecto, nos indujo como parte esencial del proceso que se debía realizar vali-

daciones de cualquier proceso que se desarrollara, así como de cualquier resultado que se

obtuviera. Este paso permitió no solo garantizar sino aumentar la relevancia y rigor de la

propuesta gracias a las validaciones que se implementaron tanto en la arquitectura empresa-

rial como en la arquitectura de software.

Aspectos como la amplia colaboración del personero municipal y del registrador municipal

de Choachí hicieron factible interactuar y hacer profundidad en la captura de información

necesaria para la constitución de este modelo, así como la colaboración de algunos ciudada-

nos para la posterior validación del modelo de arquitectura, permitiendo reflejar que los pro-

yectos desarrollados en la academia pueden tener un impacto positivo en la población desde

que se tenga en cuenta sus necesidades y no se impongan soluciones por mas validez teórica

que tengan, ya que esa validez no da soporte a que la población acepte esas propuestas bajo

presión y/o por obligación.


Página xvi

Cabe resaltar que los resultados (documentos) obtenidos durante el transcurso del proyecto

tuvieron varias iteraciones o revisiones, destacando que fue un proceso auto evaluativo, a

pesar que la cantidad de iteraciones del proyecto como conjunto fue una sola debido a la

complejidad de realizar mas sobre el modelo, ya que se salía del alcance planteado dentro del

mismo.

Como resultado final de este proyecto, se obtuvo un modelo de arquitectura de sistema, do-

cumentos de validación de la arquitectura de sistema (desglosado en validación de la arqui-

tectura empresarial así como de la arquitectura de software) y un prototipo de interfaces fun-

cional del proceso de inscripción de candidatos y electores así como del proceso de votación.

Las conclusiones obtenidas de este proyecto permiten destacar que el modelo de arquitectura

de sistema realizado es una solución que integra no solo la forma de implementar el voto sino

su relación con el entorno organizacional que lo controla, demostrando que esta solución es

nueva desde cualquier perspectiva de ingeniería, así como para Colombia, eliminando la con-

cepción de que hay que construir siempre dispositivos Hardware para soportar el voto elec-

trónico. A la vez, esta arquitectura de sistema permite ser una guía de los procesos y de la

forma de dar soporte, a nivel tecnológico y organizacional, al dinamismo propio de la regis-

traduría municipal de Choachí y nacional (en caso de implementarse).

Conjuntamente, el modelo de arquitectura de sistema desarrollado permitiría reducir el im-

pacto ambiental que producen las elecciones, al ahorrar en el consumo de papel para los tarje-

tones electorales y reducir la cantidad de tinta utilizada en los mismos, también como en la

reducción de los costos de transporte, fomentando un efecto positivo sobre el medio ambiente

Interpretando la arquitectura de sistema por partes permite concluir: primero, desde el punto

de vista de la arquitectura empresarial que la creación de ésta, permitirá a la registraduría

municipal de Choachí ser eficiente con el paso del tiempo, ya que en la actualidad no se había

realizado ningún tipo de metodología para reconocer los procesos, actores y elementos que

hacen parte de la línea estratégica de votación. Además, facilitará generar puntos de medición

o indicadores sobre actividades, tareas o procesos para permitir llevar un control de la organi-

zación y su evolución mediante análisis cuantitativos, análisis de brechas entre otras formas

de medición.

Segundo, desde la arquitectura de software, ésta se diseño mediante un esquema basado en

patrones para dar fortaleza conceptual y practica a la solución ya que trabaja sobre unas es-

tructuras que se plantearon para dar solución a problemas precisos, permitiendo analizar y

detectar problemas en otros ámbitos que no cubren los patrones desde su diseño y mejorando

la trazabilidad del proyecto.

Adjunto a esta disposición, se concluye también que la decisión de implementar servicios

web para la constitución de las aplicaciones es una ventaja para cualquier proceso electoral,

ya que facilita que los puestos de votación sean desplazables y accesibles desde cualquier

lugar donde se tenga conexión a internet gracias a la ligereza que ofrecen los servicios web en

la construcción de cualquier aplicación. Asimismo, los servicios web son un impulso para la

registraduría, en caso de implementar este modelo, para permitir la implementación de una

arquitectura orientada a servicios que permita maximizar la eficiencia y eficacia de las otras


Página xvii


líneas estratégicas de la registraduría que no fueron analizadas en el presente proyecto (ya

que no eran afines).


Página 1


INTRODUCCIÓN

La evolución en la forma de votar de ciertos países del mundo ha cambiado hacia el desarro-

llo de soluciones para mejorar los procesos electorales con ayuda de la ingeniería de sistemas

y la ingeniería electrónica, de allí que aparezca el concepto de voto electrónico (en inglés e-

voting o e-vote [1][2][3]) como los mecanismos diseñados para emitir y contar los sufragios

en un único acto, a través de algún sistema informático, instalado y en funcionamiento en el

lugar mismo donde el elector concurre a expresar su voluntad política [4].

Desde 1960 se han creado herramientas para el voto electrónico como el sistema de votación

automatizado mediante tarjetas perforadas, el sistema de escaneo de papeletas de votación

[5], el sistema de votación de Registro o Grabación Electrónica Directa [6] y el sistema de

votación por internet [7]. La generación de estas formas de votación electrónica no representó

solo soluciones sino también conflictos. Países como Holanda, Luxemburgo e Irlanda sufrie-

ron problemas con estos sistemas y desistieron de seguirlos usando por los altos costos que

les represento construir en la mayoría de ellos las urnas electrónicas, en otros casos la descon-

fianza de la gente al uso sin capacitación de estas herramientas ya que el factor de transparen-

cia siempre fue puesto en duda, y en Luxemburgo los problemas que se dieron fueron el he-

cho de que no se ofrecía calidad en la seguridad de la información de los votantes ni claridad

en el manejo de este sistema para la comunidad electoral.

Colombia planteó la implementación del voto electrónico a través del plan de Gobierno en

Línea [8] pero a la fecha no ha mostrado avance alguno en eso. Los múltiples problemas de

administración de políticas estatales, los vacíos en la legislación colombiana con respecto a la

informática, los problemas de la Registraduría y la omisión de las desigualdades entre los

distintos municipios que conforman al país han sido limitantes para que este sistema se intro-

duzca, implemente y ponga en marcha. A pesar de estos sucesos, han ocurrido pilotos de

votación electrónica en Colombia [9][10].

Las metodologías de desarrollo y los modelos de arquitecturas de software de votación elec-

trónica publicados no han considerado explícitamente la agilidad de uso ni la agilidad del

proceso pre-electoral debido a que no le han dado suficiente importancia a técnicas efectivas

en el manejo de seguridad y usabilidad [11] en la etapa pre-electoral, ni a técnicas en agilidad

para la captura de los votos y la interacción de los usuarios con estos sistemas como ocurrió

en los Estados Unidos con el caso de Diebold, donde esta empresa generó unas máquinas

para el voto electrónico fraudulentas sin los respectivos procedimientos de prueba antes de su

salida a venta del producto, lo que le genero diversas demandas por ejemplo del estado de

California hacia la empresa Diebold Inc. [12][13][14].

Por eso es importante entender que implementar una arquitectura de software es insuficiente

para satisfacer las necesidades del voto electrónico, ya que la arquitectura de software es solo

el conjunto de estructuras necesarias para razonar sobre el sistema, que comprende elementos

de software, las relaciones entre ellos y las propiedades de ambos [15]. Es decir que represen-

ta una solución que no mide el impacto que pueda tener en la comunidad con la que debe

interactuar ni en las entidades encargadas de este servicio, ya que deben restructurarse para

darle la debida importancia al proceso. De allí que sea fundamental construir una arquitectura


Página 2

de sistema1

, la cual es la integración de la arquitectura empresarial (descripción de la estruc-

tura de la empresa, la composición de los componentes empresariales y sus relaciones con el

ambiente externo, y los principios guías para los requerimientos –análisis-, diseño y evolu-

ción de una empresa [16]) y la arquitectura de software, ya que mediante ésta se espera cons-

truir el soporte del servicio ofrecido reconociendo procesos, roles, apoyo organizacional,

implicaciones de la legislación, de la seguridad y de la calidad en general, y no solo el hecho

de construir un software para los votos sin el respectivo análisis de su impacto. Para el caso,

arquitectura empresarial se refiere a la Registraduría municipal de Choachí y el proceso de

negocio a la votación electrónica.

1

Es una respuesta a las dificultades conceptuales y prácticas de la descripción y el diseño de sistemas complejos.

La Arquitectura de Sistemas ayuda a describir de manera coherente y eficiente el diseño de sistemas complejos,

tales como: a) un sistema industrial, b) una infraestructura de TI, (Arquitectura empresarial/ software), c) una

organización (la Arquitectura Organizacional), d) un negocio (Arquitectura de negocio), e) un proyecto (Proyecto

de Arquitectura) [39]


Página 3


I - OBJETIVOS

El problema de estudio que se planteó en este proyecto era analizar la capacidad del munici-

pio de Choachí para implementar un sistema de voto electrónico basado en la legislación

actual colombiana así como en los parámetros de la registraduría nacional del estado civil.

Este problema se describió con los siguientes objetivos:

1. Objetivos

1.1 Objetivo General

Diseñar una arquitectura de sistema que pueda ser adoptada como modelo para la implemen-

tación del voto electrónico en el municipio de Choachí (Cundinamarca).

1.2 Objetivos Específicos

• Identificar el concepto y el estado del arte del Voto electrónico (e-vote o e-

voting), relacionando los conceptos de diferentes autores e investigadores del te-

ma, experiencias y políticas de organismos internacionales con los sistemas ya

implementados en países como Brasil, Estados Unidos, la Unión Europea (o Sui-

za), y Australia, principalmente, analizando el impacto económico y social que se

ha venido presentando donde se ha implementado el voto electrónico.

• Analizar las distintas arquitecturas disponibles del voto electrónico en los países

nombrados o en otros

• Identificar las necesidades tanto de la registraduría municipal como de la pobla-

ción (una muestra selectiva) del municipio de Choachí

• Diseñar un modelo de arquitectura de sistema para la implementación del voto

electrónico que cumpla con las necesidades identificadas del municipio de Choa-

chí

• Desarrollar componentes funcionales (interfaces de usuario y modelos de datos)

como complemento del modelo de arquitectura de sistema de voto electrónico

En consecuencia se debería determinar cuál sería la arquitectura de sistema de voto electróni-

co de mayor viabilidad a nivel de seguridad, agilidad y usabilidad para desarrollarlo en el

municipio [17]. Ésta arquitectura también deberá servir de guía para la implementación del

voto electrónico en municipios del mismo tipo de categoría a nivel nacional.


Página 4

1.3 Definiciones

Archimate Es un lenguaje que complementa TOGAF, ya que proporciona un con-

junto de conceptos independiente del proveedor, incluyendo una repre-

sentación gráfica, que ayuda a crear un modelo coherente e integrado

"por debajo de la línea de flotación", que puede ser representado en la

forma de puntos de vista de TOGAF.

The Open

Group Archi-

tecture Frame-

work

TOGAF es un marco de trabajo estándar de arquitectura para la indus-

tria que puede ser utilizado libremente por cualquier organización que

desee desarrollar una arquitectura de sistemas de información para su

uso dentro de una organización.

Actor Alguien o algo externo al sistema que interactúa con él.

Vista - Archi-

mate

se define como una parte de una descripción de la arquitectura que se

ocupa de un conjunto de preocupaciones relacionadas y se dirige a un

conjunto de actores

Punto de Vista

- Archimate

Establece los conceptos, modelos, técnicas de análisis, y visualizacio-

nes que son proporcionados por la vista.

Capa – Archi-

mate

Clasificación que se da en el lenguaje Archimate para agrupar servi-

cios según su funcionalidad especificando 3 partes del diseño: capa de

negocio, capa de aplicación, capa de tecnología.

Tabla 1. Definiciones

1.4 Acrónimos

TOGAF The Open Group Architecture Framework

ADM Architecture Development Method

UML Unified Modeling Language

BPM Business Process Management

Tabla 2. Acrónimos


Página 5


II – MARCO TEÓRICO

La evolución se presenta en varios aspectos, de allí que se presenten desarrollos de soluciones

para mejorar los procesos electorales con ayuda de la ingeniería de sistemas y la ingeniería

electrónica. Estos desarrollos hacen que aparezca el concepto de voto electrónico (en inglés

e-voting o e-vote) [18][19][20][21][22].

La definición más clásica de voto electrónico la podemos ver por ejemplo en la enciclopedia

británica, la cual dice que el voto electrónico “es una forma de votación mediada por compu-

tadora en la cual los votantes hacen sus selecciones con la ayuda de un computadora” [23].

Entidades como la Red de Conocimientos electorales ACE define el e-voting como la "vota-

ción electrónica" y hace alusión a la opción de utilizar medios electrónicos para votar en los

referendos y las elecciones” [24]. El argentino Busaniche define el voto electrónico como

“los mecanismos diseñados para emitir y contar los sufragios en un único acto, a través de

algún sistema informático, instalado y en funcionamiento en el lugar mismo donde el elector

concurre a expresar su voluntad política” [25].

Según el observatorio electoral latinoamericano, define el voto electrónico como “la referen-

cia a todos los actos electorales factibles de ser llevados a cabo apelando a la tecnología de

la información. Estos incluyen el registro de los ciudadanos, la confección de mapas de los

distritos electorales, la gerencia, administración y logística electoral, el ejercicio del voto en

sí mismo, culminando con los escrutinios, la trasmisión de resultados y su certificación ofi-

cial” [26]. Este concepto será el que usaremos de guía para el desarrollo del modelo de arqui-

tectura del sistema para la implementación el voto electrónico en el municipio de Choachí.

Ahora, teniendo claro el concepto de voto electrónico debemos tener en cuenta que el desa-

rrollo de este proyecto en cualquier lugar del mundo tiene que ser tan libre, secreto, fiable y

seguro como los sistemas de votación que no implican el uso de medios electrónicos.

El progreso del voto electrónico se ha visto desarrollado desde 1960 donde aparece por pri-

mera vez el sistema de votación automatizado con tarjetas perforadas [27] y del cual han

seguido apareciendo variedad de herramientas o sistemas con el pasar de los años y las mejo-

ras de tecnología: tarjeta perforada votomatic [27], tarjeta perforada datavote [27], sistemas

de escaneo de papeletas de votación [27][28], sistemas de votación de registro o grabación

electrónica directa (DRE) [27][29], sistema de votación por internet [27][30], votación SMS

[31][32], sistema de votación mediante tecnología de respuesta interactiva de voz (IVR)

[32][33][34], y sistemas DRE con comprobante de auditoria de papel verificado por el votan-

te (VVPAT) [35][36][37].

En la era de las tecnologías de la información, Colombia ha progresado paulatinamente desa-

rrollando políticas nacionales y algunas modificaciones a ciertas leyes. A pesar de eso, Co-

lombia no ha tenido en ningún momento ningún sistema de votación electrónica, lo único que

el país tiene es la publicación de los resultados vía internet, proceso posterior al conteo que se


Página 6

hace por cada mesa. Esta publicación de los resultados se hace pasando las planillas con los

resultados a mano que entrega cada presidente de mesa al encargado del puesto de votación.

Si bien es cierto que con su aparición el voto electrónico presento problemas de auditabilidad,

seguridad y usabilidad, es cierto también que los desarrollos que se han presentado con el

tiempo han tratado de solucionar estos problemas. Grandes soluciones se han generado, pero

el factor delimitante que no permite verlos en ejecución en la vida real la mayoría de veces

son los altos costos de su implementación.

Ahora, algo muy radical con respecto al voto electrónico seria delimitar el progreso de alguna

de estas herramientas; es decir, cerrar la apertura intelectual generando una ley que obligue a

desarrollar solo un tipo de sistema para el voto electrónico. Esta decisión generaría unos pros

y unos contras, a nivel de pros el más impactante se daría en que el mundo científico estaría

enfocado a solucionar una sola serie de problemas propios del sistema que se haya definido,

pero en los contras el más relevante sería que se generarían monopolios de construcción de

estos sistemas. Además, los costos estarían ligados solo a ese sistema lo que limitaría la capa-

cidad de países en desarrollo a adquirir estos sistemas. Es por eso que mantener una apertura

en la votación electrónica aunque tarde un poco en la corrección de los respectivos problemas

permite a todo el mundo motivarse a pasar a estos sistemas, manteniendo claro que la demo-

cracia es de todos y no de unos pocos.

III - MÉTODO

El diseño del modelo de arquitectura de sistema para la implementación del voto electrónico

en el municipio de Choachí se dividirá en 3 fases principales consecutivas:

• Análisis del entorno.

• Análisis de la base del conocimiento.

• Construcción y evaluación de la arquitectura de sistema.

Estas fases se articulan entre sí y con los objetivos específicos nombrados anteriormente, todo

fundamentado en la ciencia basada en el diseño [38], donde el objetivo de la ciencia basada

en el diseño es la solución de problemas del mundo real utilizando conocimiento disciplinar y

que esta solución hecha mediante la construcción y evaluación iterativa sea útil, haciendo

aclaración en que el origen del problema no es disciplinar.


Página 7


Figura 1. Modelo de la Ciencia basada en el diseño. Fuente: [38].

En la fase del entorno se define el problema del espacio donde se encuentra el fenómeno de

interés. Para este trabajo de grado, el entorno se compone de la gente, organizaciones (de

negocio) y sus tecnologías existentes o planeadas en el municipio de Choachí. En el problema

de interés se encuentran las metas, tareas, problemas y oportunidades que definen las necesi-

dades del negocio como son percibidas por la gente dentro de la organización. Tales percep-

ciones están moldeadas por las funciones, capacidades y características de las personas dentro

de la organización.

Además se busca que las necesidades del negocio sean juzgadas y evaluadas dentro del con-

texto de las estrategias organizacionales, estructura, cultura y procesos existentes del negocio.

Ellas son ubicadas con relación a la infraestructura tecnológica existente, aplicaciones, arqui-

tecturas de comunicación y capacidades de desarrollo. Todas estas necesidades definen la

necesidad del negocio o el “problema” como lo percibe el investigador.

Para el desarrollo de esta fase se realizaron las siguientes actividades:

A. Definición del problema con relación al entorno.

B. Definición de las funciones, capacidades, y características de las personas que inter-

actúan con el entorno.


Página 8

C. Definición de la organización donde se va a resolver el “problema”, reconociendo las

estrategias que tiene, la estructura y contexto cultural, y los procesos que lleva a ca-

bo.

D. Definición, reconocimiento y descripción de la tecnología disponible a nivel de infra-

estructura, aplicaciones, arquitecturas de comunicación y capacidades de desarrollo.

E. Captura de los requerimientos funcionales y no funcionales de los stakeholders me-

diante entrevistas.

F. Definición y validación de los requerimientos (por ejemplo, utilizando técnicas de re-

colección de requerimientos y herramientas como UML).

La fase del análisis de la base del conocimiento provee la materia prima mediante la cual se

lleva a cabo la investigación. La base del conocimiento está compuesta de fundamentos y

metodologías. Lo más importante de la investigación y los resultados de las disciplinas de

referencia es que provee teorías fundamentales, marcos, instrumentos, conceptos, modelos,

métodos e instanciaciones que serán usados en la etapa de desarrollo/construcción de la in-

vestigación.


A. Desarrollo del documento de requerimientos del modelo de arquitectura del sis-

tema.

B. Definición y clasificación de los fundamentos del voto electrónico y de las arqui-

tecturas (tanto empresariales como de software) en: teorías, conceptos, metodo-

logías, métodos, instanciaciones.

C. Definición del proceso metodológico para la votación electrónica: modelos ac-

tuales de votación electrónica, formalismos, métricas y criterios de validación de

los modelos publicados sobre votación electrónica (si existen, de lo contrario

ajustarlo con base a la validación que se aplica al gobierno electrónico).

D. Definición del proceso metodológico para arquitectura: modelos para la descrip-

ción de arquitecturas (TOGAF, ZACKMAN, estilos arquitectónicos, patrones ar-

quitectónicos y/o de diseño), modelos para escenarios de arquitectura (por ejem-

plo FAAM), formalismos, métricas y criterios de validación de las arquitecturas

(por ejemplo SACAM, modelo de madurez para arquitecturas empresariales, eva-

luación con expertos, Feature comparison), métodos para la prueba de arquitectu-

ras (por ejemplo Technology Acceptance Model (TAM)).

E. Definición del proceso metodológico para el desarrollo de prototipos (por ejem-

plo, OPM, metodología de creación de prototipos).

F. Desarrollo del documento del estado del arte del voto electrónico.

La fase de construcción y evaluación del modelo de arquitectura de sistema se desarrolla

basado en las metodologías seleccionadas en la etapa anterior que proporcionan los criterios a

usar en la fase de justificación/evaluación. El rigor de esta fase se logra mediante la aplica-

ción adecuada de los fundamentos y metodologías existentes.



Página 9


A. Diseño y descripción de la arquitectura empresarial.

B. Evaluación de la arquitectura empresarial (comparación con modelos propuestos

identificados en la base del conocimiento a nivel empresarial o mediante la evalua-

ción de un experto) (iterativo con el punto A.).

C. Diseño y descripción de la arquitectura de software.

D. Evaluación de la arquitectura de software mediante triangulación (comparación con

modelos de arquitectura de software propuestos identificados en la base del conoci-

miento, y evaluación del usuario sobre aceptabilidad del modelo) (iterativo con el

punto C.).

E. Desarrollo del documento de integración de arquitectura del sistema de voto electró-

nico (arquitectura empresarial y arquitectura de software).

F. Desarrollo de los prototipos de la arquitectura de software que instancian una prueba

de concepto de la arquitectura de sistema diseñada (interfaces y modelo de datos).

En la ciencia del diseño, los métodos computacionales y matemáticos son usados principal-

mente para evaluar la calidad y efectividad de los artefactos, sin embargo, las técnicas empí-

ricas también pueden ser empleadas.

.

IV – MODELO DE ARQUITECTURA DE SISTEMA

La propuesta desarrollada en este proyecto conocida como Arquitectura de Sistema, busca

ofrecer un esquema completo de voto electrónico para el municipio de Choachí mediante la

integración de los modelos de arquitectura empresarial y arquitectura de software para au-

mentar la fortaleza de la solución.

1. Modelo de Arquitectura Empresarial

La Registraduría municipal de Choachí así como la Registraduría Nacional del Estado Civil

no tienen un esquema del proceso de votación en ninguna forma Empresarial, así como tam-

poco una base para desarrollar una herramienta software. Por esta razón, se desarrolló de

manera clara el modelo que más representa la arquitectura empresarial ideal que integre un

software para agilizar los procesos, empleando un lenguaje sencillo y directo, así como gráfi-

cos y puntos de vista de acuerdo a la metodología utilizada.

La arquitectura se basará en el modelo ‘TOGAF ADM’ que representa Archimate [40], el

cual contendrá las capas de negocio, aplicación y tecnología, y los puntos de vista más repre-

sentativos a nivel de diseño.


Página 10

1.1 Selección de Vistas

Hay que aclarar que lo que Archimate maneja como puntos de vista2

se ajustara para la com-

presión de los lectores como vistas según la definición de la IEEE: “Una representación de

todo un sistema desde la perspectiva de un conjunto relacionado de las preocupaciones”

[41].

Las vistas que se trabajaron y se presentan en este documento son los más significativos con

base a problemática del proyecto y que son de mayor prioridad para la perspectiva de la inge-

niería de sistemas.

Capa Vista (viewpoint según Archimate)

Negocio – Aplicación – Tecnología Introductorio (introductory)

Negocio Organización (organization)

Negocio Co-operación de actores (actor co-operation)

Negocio – Aplicación Proceso de negocio (Business Process)

Negocio – Aplicación Co-operación del Proceso de negocio (Business Pro-

cess co-operation)

Aplicación Comportamiento de la aplicación (Application beha-

vior)

Tecnología Infraestructura (Infrastructure)

Tabla 3. Capas y vistas

1.2 Actores

Actor Descripción Puntos de vista

El candidato es quien interactúa con

el proceso inscripción candidato

para registrar su candidatura en un

municipio y hacerla oficial ante la

registraduría municipal y nacional.

Cabe aclarar que al registrase el

candidato pasa a ser un elector tam-

Introductorio

Organización

Co-operación de actor

Co-operación de proceso de

negocio

2

Establece los conceptos, modelos, técnicas de análisis, y visualizaciones que son proporcionados por la vista


Página 11


bién.

El registrador es quien valida las

inscripciones tanto de candidatos

como de electores. Además es quien

realiza el escrutinio para dar el resul-

tado final junto con el juez. También

puede ejercer de jurado en alguna

mesa de votación

Introductorio

Organización



negocio

Proceso de negocio

El elector es quien interactúa con el

proceso inscripción elector. Poste-

rior a esto, el elector es el único que

puede realizar una votación en el

sistema.

Introductorio

Organización



negocio

El juez solo participa como colabo-

rador del registrador para realizar el

proceso del escrutinio.

Introductorio

Organización



negocio

El auxiliar es una persona que puede

ser asignada en determinados mo-

mentos por el registrador para reali-

zar solamente la tarea de inscribir

electores en la etapa de inscripción.

En la etapa del proceso de votación

el auxiliar puede ejercer de jurado,

autorizando el ingreso del elector al

dispositivo de votación.

Introductorio

Organización



negocio

El jurado es la persona encargada de

autorizar durante proceso de vota-

ción el ingreso del elector al disposi-

tivo de votación

Introductorio


negocio

El personal de back office es el en-

cargado de dar soporte sobre la ad-

ministración del sistema de voto

electrónico. Dentro de esto se consi-

dera que debe haber una persona

para todo el sistema, una para el

control de electores y otra para el

control de candidatos

Organización


Proceso de negocio


negocio

Infraestructura

Comportamiento de la apli-

cación


Página 12

El desarrollador es el encargado de

implementar el sistema de voto elec-

trónico y las peticiones nuevas que

se le soliciten al sistema por parte

del registrador nacional del estado

civil representado por el registrador

municipal.

Proceso de negocio


negocio

Infraestructura

Comportamiento de la apli-

cación

Tabla 4. Actores

Se debe considerar también que un momento dado en el sistema, el elector puede ser Jurado

como puede ser candidato. Las relaciones entre actores se presentan a continuación:

• Un jurado puede ser elector en el proceso de votación

• Un candidato puede ser elector en el proceso de votación

• Un auxiliar puede ejecutar como jurado en el proceso de votación

• Un auxiliar puede ser elector en el proceso de votación

1.3 Stakeholders

Stakeholder Descripción Puntos de vista

Administrador

El administrador es el encargado de

ejercer un monitoreo continuo a los

procesos y de solucionar inconvenien-

tes en tiempos cortos que se presenten

sobre la arquitectura empresarial.

Además de esto, es quien asigna los

tipos de perfiles a los usuarios.

Introductorio

Organización

Co-operación de proceso

de negocio

Comportamiento de la

aplicación

Usuario El usuario es quien se interesa en co-

nocer que mejoras le ofrecerá la arqui-

tectura y con cuales procesos él podrá

interactuar.

Introductorio


de negocio

Manager El manager es la figura dentro de la

empresa que apoya totalmente el desa-

rrollo de la arquitectura, a la vez que

es el encargado de aprobar tanto las

soluciones como el presupuesto desti-

nado para el proyecto de arquitectura

empresarial

Introductorio

Organización


Proceso de negocio


de negocio


aplicación

Infraestructura

Desarrollador El desarrollador es la persona encar-

gada de implementar las aplicaciones

necesarias o sugeridas en la arquitec-


aplicación

Infraestructura

Proceso de negocio


Página 13


tura empresarial Co-operación de Proceso

de negocio


Tabla 5. Stakeholders

Teniendo en cuenta los stakeholders, los actores y a la vez su asociación con las vistas defini-

das, la relación entre ellos queda plasmada de la siguiente forma:

STAKEHOLDERS ACTORES

Administrador Jefe Back Office, Administrador electores, Administrador candidatos

Usuario Elector, Juez, Jurado, Candidato, Registrador, Registrador Munici-

pal, Auxiliar/Secretaria

Manager Registrador, Registrador Municipal

Desarrollador Desarrollador

Tabla 6. Arquitectura empresarial: Stakeholders vs Actores

Cabe destacar que durante la creación de la vistas se tuvo en cuenta no solo la opinión de los

stakeholders, sino también la del director del proyecto y los conceptos estudiados y adquiri-

dos sobre arquitectura empresarial, el lenguaje Archimate así como del lenguaje BPMN por

el autor del proyecto; todo las decisiones fueron soportadas en los atributos de calidad que se

plasmaron en el documento de casos de uso y requerimientos dando prioridad a la auditabili-

dad, seguridad y usabilidad.

1.4 Vista Introductoria (Introductory Viewpoint)

El diagrama de vista introductoria representa la forma general de cómo un cliente opera con

alguno de los servicios ofrecidos por la registraduría y el soporte que tiene de forma global

cada proceso para poderse llevar acabo.

A grandes rasgos en el punto de vista introductorio se puede apreciar los procesos que pueden

ser automatizados y reducir tiempos y falencias.


Página 14

Figura 2. Vista introductoria (previa)

La figura 2 se puede ver completa en el Anexo A figuras 27, 28 y 29.

En este punto de vista se puede tener una apreciación de alto nivel de toda la línea estratégica

de votación dentro de la registraduría municipal de Choachí.

a. Candidato

Aquí se aprecia que el Candidato interactúa con 3 servicios de negocio ligados a un proceso

llamado Inscripción Candidato: registrar inscripción candidato, modificar inscripción can-

didato, entregar certificación candidatura; y un servicio ligado al proceso Inscripción elec-

tor: entregar certificación inscripción.

Proceso de inscripción de candidato

El servicio de Registro de inscripción de candidato ejecuta el proceso de inscripción de can-

didato partiendo del subproceso de validar candidato, el cual se lleva acabo sobre la aplica-

ción MorphoCheck de la empresa SAGEM, la cual utiliza la validación biométrica y de códi-

go de barras sobre la cedula del candidato gracias a la conexión que tiene con el servidor

MorphoCheck de Bogotá para solicitar esta información. Si la validación es correcta, se pro-

sigue con el subproceso de registrar candidato, el cual usa una aplicación llamada aplicación

registro candidatos en la cual se hace captura de los datos solicitados por la registraduría para

validar la inscripción (esta aplicación funcionara sobre el mainframe ubicado en la registradu-

ría municipal de Choachí). Luego el sistema debe generar un aviso de confirmación que se da

dentro del subproceso de confirmación, para terminar con el subproceso de certificación ins-

cripción candidato, el cual genera a partir de los datos capturados por la aplicación registro

candidatos el certificado de inscripción de candidato que se entregara mediante el servicio

entregar certificación candidatura.

Además de esto, en el momento de confirmar el registro como candidato se habilita de forma

transparente tanto para el candidato como para el registrador el registro del candidato como

elector (registrar elector), el cual también ejecuta una confirmación y posterior certificación

de inscripción como elector (certificación inscripción elector) que se le entregara a la par con

la certificación de candidatura al candidato


Página 15


El otro servicio con el que interactúa el candidato es el de modificar inscripción candidato, el

cual solo está habilitado durante un lapso de tiempo definido por el registrador y puede modi-

ficar su registro bajo unas políticas de la Registraduría. Si cumple con esto, el registrador

podrá accesar al sistema y modificar el registro del candidato y generar sus nuevos certifica-

dos.

b. Elector

Con respecto al actor Elector, él interactúa con 4 servicios de negocios repartidos en 2 proce-

sos: Los servicios de Registrar inscripción elector y Entregar certificado inscripción perte-

necen al proceso Inscripción elector; mientras que Registrar votación y entregar certificado

votación pertenecen al proceso Votación.

Proceso Inscripción elector

Cuando el elector interactúa con el servicio de Registrar inscripción elector se ejecuta el

proceso Inscripción elector, dentro del cual se inicia el subproceso Validar elector que invoca

a la aplicación MorphoCheck para validar que la identidad del elector que se va a registrar

sea la verdadera. Después de validar la identidad, se activa el subproceso Registrar Elector el

cual accede a la aplicación de registro llamada aplicación registro elector donde se almace-

nan los datos otorgados por el Elector. Esta aplicación funcionaria sobre el mainframe ubica-

do en la Registraduría municipal de Choachí.

Después del registro, el subproceso de confirmación si ha sido satisfactorio el registro mos-

trara un mensaje de confirmación para dar continuación al subproceso de certificación ins-

cripción elector, donde se generara el certificado de inscripción con los datos ingresados por

el elector para entregárselos a través del servicio Entregar certificado votación.

Proceso Votación

A nivel del proceso de votación, el elector interactúa con el servicio de Registrar Votación.

Este servicio inicia dentro del proceso de votación el subproceso de validación elector/mesa,

el cual compara los datos del elector con los almacenados en la Aplicación Registro Electo-

res. Si el registro existe, se da inicio al subproceso de realizar votación donde el elector in-

teractúa con la Aplicación votación conectada al nodo voto-frame en la cual podrá realizar su

votación por alcalde como por concejal. Al terminar la votación, en el subproceso confirma-

ción le saldrá en pantalla un mensaje de confirmación sobre las opciones que acaba de reali-

zar, colocando en decisión del elector, seguir o volver a votar. Cuando decida seguir, el sub-

proceso de certificación jornada electoral recurrirá a la Aplicación votación para generar el

certificado respectivo y entregárselo al elector mediante el servicio Entregar certificado vota-

ción.

Es importante reconocer que el rol de candidato para el proceso de votación no existe, ya que

un candidato por más que realice su registro y sea una figura de elección popular tiene dere-

cho a ejercer su voto, por tanto se considerara un elector más.


Página 16

c. Registrador

El actor registrador ejerce como veedor y como la persona encargada de ejecutar el sistema

en los procesos de inscripción candidatos, inscripción elector, votación. Además tiene facul-

tades para realizar las inscripciones de candidatos y electores, así como de ejercer de jurado

en el proceso de votación.

Los servicios con los cuales el registrador interactúa con el sistema son: Cerrar inscripción

candidatos del proceso cierre inscripción candidatos; Cerrar inscripción electores del proce-

so cierre inscripción electores; Habilitar jornada electoral del proceso votación.

Proceso cierre inscripción de candidatos

El registrador interactúa con el servicio Cerrar inscripción candidatos el cual da inicio al

proceso de cierre inscripción de candidatos activando el subproceso de validación de usua-

rio, mediante el cual se valida la identidad del Registrador con la base de datos propia del

sistema de votación conocida como Aplicación usuarios sistema la cual está conectada al

Mainframe ubicado en la Registraduría municipal de Choachí.

Después de confirmar la validación del registrador, se da inicio al subproceso de verificación

final candidatos donde se cierra el ingreso de datos a la aplicación registro candidatos y se

genera un reporte con la totalidad de candidatos registrados. Luego de generar este reporte, se

inicia el subproceso Envío de candidatos a la registraduría nacional del estado civil (Bogotá)

donde se envía el reporte vía web al servidor de la Registraduría Nacional del Estado Civil.

Proceso cierre inscripción electores

Además, el registrador interactúa también con el servicio Cerrar inscripción electores el cual

da inicio al proceso de cierre inscripción de electores activando el subproceso de validación

de usuario, mediante el cual se valida la identidad del Registrador con la base de datos propia

del sistema de votación conocida como Aplicación usuarios sistema la cual está conectada al

Mainframe ubicado en la Registraduría municipal de Choachí.

Después de confirmar la validación del registrador, se da inicio al subproceso de verificación

final electores donde se cierra el ingreso de datos a la aplicación registro electores y se gene-

ra un reporte con la totalidad de electores registrados. Luego de generar este reporte, se inicia

el subproceso Envío de electores a la registraduría nacional del estado civil (Bogotá) donde

se envía el reporte vía web al servidor de la Registraduría Nacional del Estado Civil.

Proceso votación

A nivel del proceso de votación, el registrador interactúa con el servicio de Habilitar jornada

electoral. Este servicio inicia y finaliza todo el proceso de votación, ya que es el registrador

quien tiene la potestad de autorizar que funcione el sistema de voto electrónico el día de las

elecciones así como de determinar cuando se finaliza la jornada electoral.


Página 17


d. Registrador y Juez

Proceso escrutinio de resultado

El servicio realizar escrutinio debe ser ejecutado tanto por el Registrador como por el Juez

en paralelo. Este servicio da inicio al proceso escrutinio de resultado, el cual empieza con el

subproceso de validación de usuario, donde se verifica la identidad del Registrador y del

Juez con la base de datos propia del sistema de votación conocida como Aplicación usuarios

sistema, la cual está conectada al Mainframe ubicado en la Registraduría municipal de Choa-

chí. Luego de la validación exitosa, se inicia el subproceso conteo de votos, el cual utiliza los

votos registrados y almacenados que están asociados con la aplicación votación para generar

los resultados mediante unas consultas sencillas.

Al generar los resultados se activa el subproceso Confirmación/Aprobación donde se guarda-

ran estos resultados para ser posteriormente enviados en el subproceso envío de resultados a

la registraduría nacional del estado civil (Bogotá) vía web, y luego imprimirlos como parte

del subproceso publicación de resultados y concluir con el proceso de escrutinio de resulta-

dos.

A nivel de infraestructura se aprecia que tanto el servidor MORPHOCHECK, el nodo Main-

frame, el nodo voto-frame están enlazados mediante conexión a internet o dado el momento

de la implementación mediante la Red de Alta Velocidad del Estado Colombiano (RAVEC).

e. Auxiliar / Secretaria y Jurado

Proceso votación

El auxiliar/secretaria o Jurado interactúan con 2 subprocesos del proceso de votación: prime-

ro con el subproceso de validación elector/mesa y luego con el subproceso de certificación

jornada electoral. Desde el subproceso de validación elector/mesa el auxiliar/secretaria o

jurado es quien verifica que el elector que se acercó al puesto de votación a realizar su voto si

este apto para votar en ese puesto, revisando la identidad del elector (cedula y validación

biométrica) contra la base de electores inscritos del municipio. Posteriormente de eso y al

finalizar el elector de ejercer su derecho al voto, el auxiliar/secretaria o jurado será el encar-

gado de revisar el certificado electoral, imprimirlo y entregarlo.

f. Auxiliar / Secretaria

Proceso inscripción elector

El auxiliar/secretaria esta encargado de supervisar todo el proceso de inscripción de electores,

permaneciendo pendiente de todas las actividades que realiza el sistema. El no interactúa con

ninguno de los servicios de este proceso como agente iniciador sino como guía del desarrollo

del mismo.


Página 18

1.5 Vista de la Organización (Organization Viewpoint)

Esta vista es una expresión sobre el organigrama que se reconoce en la registraduría munici-

pal de Choachí y el nuevo rol que se agregaría en el mismo como es el del back office. La

importancia de reconocer los roles del organigrama y su interacción permitirá establecer las

políticas necesarias para controlar los procesos y subprocesos a los cuales serán asignados,

además de identificar y establecer acciones coordinadas entre los roles en algún momento y

sobre algún proceso o subproceso.

Figura 3. Vista de la organización (previa)

La figura 3 se puede ver completa en el Anexo A figura 30.

Además, la estructuración de esta vista es significativa, ya que el hecho de automatizar cier-

tos procesos de la línea estratégica de votación, debe incluir tener gente capacitada para dar

solvencia rápida a cualquier situación que se presente, además de resaltar quienes estarían

directamente trabajando con el sistema.

De allí, que se haga este diseño organizacional para establecer:

• Primero, cada rol tenga su asignación de tarea y/o proceso

• Segundo, exista una jerarquía dentro de la organización, que permita reconocer

líderes o jefes de proceso como líderes o jefes de estrategia, permitiendo que no

halla anarquía e irresponsabilidades laborales sobre las tareas, subprocesos o pro-

cesos que estén asignados y permitiendo ejercer labores de control; de esta forma

se permite tener control estricto sobre quienes interactúan en el sistema, en caso

de detectar manipulaciones del sistema para beneficiar agentes externos.

• Tercero, halla coordinación por tareas o metas, permitiendo reconocer que roles

pueden ser reubicados, reasignados o eliminados con base a las metas que debie-

ran realizar sobre cada tarea o subproceso (esta perspectiva se realiza de acuerdo

a los procesos que existan y lo que busque la empresa lograr con ellos. Se puede

asignar o aclarar dentro de la vista de procesos de negocio)


Página 19


La estructura se ve representada por el registrador nacional quien podría ejercer casi todas las

funciones (excepto las de back office y desarrollador, de allí que estén resaltadas en otro co-

lor, que corresponde a la capa de aplicaciones – otro tipo de personal). Como un subemplea-

do, quien ejercería las veces de Registrador bajo ciertas jurisdicciones está el registrador mu-

nicipal quien sería el jefe y supervisor del sistema y quien debe tener una conversación e

interacción transparente con la gente encargada del back office y desarrollo ya que ellos, de

igual forma deben tener en cada municipio un actor para servir de apoyo.

Aparte de la gente de back office y desarrollo, el registrador tiene relación horizontal con el

juez quien solo podrá intervenir en el sistema dado el momento de realizar el escrutinio de

resultados, para todo lo demás es un agente que no debe intervenir en el sistema.

Debajo del registrador municipal esta auxiliar/secretaria quien podrá ejecutar unas acciones

asignadas por el registrador municipal e informadas a la gente de back office para que autori-

ce el uso del sistema en dichas acciones, pero que en todo momento pueden ser supervisadas

por el registrador municipal.

1.6 Vista de Co-operación de Actores (Actor Co-operation viewpoint)

El valor de esta vista es identificar la interacción entre los actores y los agentes externos a la

organización, complementando la vista de organización (explicado en el punto anterior) para

ver claramente cómo y con quien interactúa cada rol, permitiendo identificar cada rol a im-

plementar para mejorar la seguridad. Además de esto, permite ejercer una auditabilidad clara

y precisa sobre cada rol sin confundir u omitir ninguna de sus actividades.

Figura 4. Vista de co-operación de actores (previa)

La figura 4 se puede ver completa en el Anexo A figura 31.

En esta vista se puede apreciar por una parte que tanto el registrador municipal como auxi-

liar/secretaria pueden relacionarse con el elector mediante la interacción directa con él, defi-

niendo esta interfaz como charla, a través de la cual realizaran la captura de los datos que se

necesiten en los respectivos procesos donde intervenga el elector. A la vez se puede apreciar

que la asignación de un jurado esta ligado la mayoría de veces a que sea el mismo elector y la


Página 20

comunicación con los jurados por parte del registrador o el auxiliar/secretaria se da de la

misma forma que con elector: de forma oral.

Además, el registrador es el único que puede interactuar con el candidato para la captura de

los datos necesarios donde este participa mediante 2 tipos de interfaz que son habilitados

como políticas de la registraduría: uno vía charla que es la interacción frente a frente entre

registrador-candidato, y la otra opción es mediante vía teléfono. Hay que hacer la salvedad

que la vía del teléfono es solo bajo condiciones especiales, puesto que el registro del candida-

to de primera vez nunca será permitido por este medio.

Con respecto al personal de back office, la colaboración entre ellos con los demás roles se da

en la siguiente manera:

• Entre el registrador municipal y el actor de back office, la interacción entre ellos

se da mediante el flujo bidireccional de intercambio de formatos de registro elec-

trónico de los electores, así como el de candidatos.

• Entre auxiliar/secretaria y el actor de back office, la interacción se da solamente

con el flujo bidireccional de intercambio de formatos de registro de electores.

• Entre desarrollador y back office se da mediante la entrega de actualizaciones,

mientras que entre back office y desarrollador se da mediante la solicitud de

creación y actualización de reportes así como peticiones para la asignación de

servicios.

Para concluir esta vista, esta la relación del desarrollador con la organización: el desarrollador

se relaciona con el registrador municipal mediante el envío de actualizaciones intermediadas

con el personal de back office, mientras que la relación del registrador municipal hacia el

desarrollador se da mediante el envío de requerimientos para el sistema.

1.7 Vista de Proceso de Negocio (Business Process Viewpoint)

Esta vista refleja al detalle los procesos y subprocesos que se alinearon y que se podrían au-

tomatizar para mejorar la calidad de la votación en Choachí. Además establece que clase de

archivos se deben generar para aumentar la seguridad del proceso y a su vez facilitar audito-

rias posteriores con los registros de cada archivo mediante la verificación de historiales de

acceso, modificación y creación.

Figura 5. Vista de proceso de negocio (previa)

La figura 5 completa la puede ver en el anexo A figuras 32, 33 y 34.


Página 21


Los procesos que se llevan a cabo en esta línea estratégica son 6: Inscripción de candidatos,

inscripción de electores, votación, cierre de inscripción candidatos, cierre de inscripción

electores, escrutinio de resultado.

a. Proceso Inscripción candidato

Este proceso se da inicio por un evento que se denota como habilitación inscripción candida-

turas, el cual se programa según las fechas entregadas por la Registraduría Nacional del Esta-

do Civil. Estas fechas son las mismas para cualquier registraduría municipal, por tanto son las

que permitirán que cuando se solicite el servicio si están las fechas activas lo permita hacer,

de lo contrario no.

Al ejecutarse habilitación inscripción candidaturas se activa el subproceso de validar candi-

dato. Este subproceso esta a su vez conformado de 2 subprocesos más: Validar identidad y

validar Aval. Validar identidad es el subproceso encargado de comparar mediante el uso de

lector biométrico y de código de barras la identidad del candidato con la almacenada en el

sistema MORPHOCHECK. Aquí se deberá generar un archivo temporal que permita verificar

los datos ingresados por el sistema para comparar con MORPHOCHECK y que permita su

posterior lectura para generar el registro del candidato evitando redundancia en la recaptura

de datos.

Después de Validar la identidad, se pasa al subproceso de validar aval donde se verifica de

forma manual que lleve el certificado de aceptación de un partido o movimiento político y de

igual forma el pasado judicial actualizado. Si todos los requisitos están completos se concluye

el subproceso validar candidato y se activa el subproceso Registrar candidato.

En el subproceso Registrar candidato se lee el archivo temporal generado por

MORPHOCHECK para crear dos archivos: un nuevo archivo llamado candidato file donde se

guardara el registro del candidato (nombre, apellido, edad, partido político, lugar de residen-

cia, cedula, nacionalidad) -se generaran n archivos candidato file donde n es el número de

candidatos que vayan a registrarse-. El otro nuevo archivo llamado registro candidato tendrá

los datos del candidato almacenados en el archivo candidato file más un numero seriado de

registro, más un atributo que cuente las veces que ha modificado su registro, más el número

que le quedara asignado según el número de candidatos inscritos previamente que pertenez-

can a su partido político integrando de esta manera los datos que trae el formato manual de

inscripción de candidato más unos datos extra para mejorar la seguridad y auditabilidad del

proceso.

Estos archivos pueden ser modificados en caso que el candidato lo solicite bajo las políticas

establecidas por la Registraduría Nacional del Estado Civil.

Luego de crear los archivos, se finaliza el subproceso Registrar Candidato y se inicia el sub-

proceso Confirmación donde para poder confirmar el sistema debe leer el archivo candidato

file y el archivo registro candidato, verificando de esta manera que se efectuó satisfactoria-

mente el registro y mostrando luego en pantalla un mensaje de confirmación. Automática-

mente al mostrar el mensaje de confirmación, deberá copiar los datos del archivo candidato

file que sean iguales a los que solicita el sistema para crear el archivo Elector File, de esta


Página 22

manera con el registro de una persona como candidato automáticamente hará el de elector

evitando la redundancia de procesos y validaciones.

Al mostrar este mensaje, se da por finalizado el subproceso de Confirmación y se activa el

último subproceso que es Certificación inscripción candidato. En este subproceso lo que se

hace es leer el archivo candidato file para generar un nuevo archivo llamado certificado can-

didato file, el cual tendrá aparte de los datos de candidato file la fecha, hora, municipio y un

número seriado de certificación.

b. Proceso Inscripción elector

Este proceso se da inicio por el evento habilitación inscripción votantes, el cual se programa

según las fechas entregadas por la Registraduría Nacional del Estado Civil. Estas fechas son

las mismas para cualquier registraduría municipal, por tanto son las que permitirán que cuan-

do se solicite el servicio si están las fechas activas lo permita hacer, de lo contrario no.

Al ejecutarse habilitación inscripción votantes se activa el subproceso de validar elector.

Este subproceso está compuesto del subproceso Validar identidad, el cual se encarga de

comparar mediante el uso de lector biométrico y de código de barras la identidad del candida-

to con la almacenada en la aplicación MORPHOCHECK. Aquí se deberá generar un archivo

temporal (al igual que con el proceso inscripción candidato) que permita verificar los datos

ingresados por el sistema para comparar con MORPHOCHECK y que permita su posterior

lectura para generar el registro del elector evitando redundancia en la recaptura de datos.

En el subproceso Registrar elector se lee el archivo temporal generado por

MORPHOCHECK para crear dos archivos: un nuevo archivo llamado elector file donde se

guardara el registro del elector (nombre, apellido, edad, cedula, nacionalidad, un atributo de

lugar de residencia) -se generaran n archivos candidato file donde n es el número de candida-

tos que vayan a registrarse-. El otro nuevo archivo llamado registro candidato tendrá los

datos del elector almacenados en el archivo elector file más un numero seriado de registro, un

atributo de último lugar donde voto y un atributo de mesa donde quedo inscrito, integrando

de esta manera los datos que trae el formato manual de inscripción de elector más unos datos

extra para mejorar la seguridad y auditabilidad del proceso.

Luego de crear los archivos, se finaliza el subproceso Registrar elector y se inicia el subpro-

ceso Confirmación donde para poder confirmar el sistema debe leer el archivo elector file y el

archivo registro elector, verificando de esta manera que se efectuó satisfactoriamente el re-

gistro y mostrando luego en pantalla un mensaje de confirmación.

Al mostrar este mensaje, se da por finalizado el subproceso de Confirmación y se activa el

último subproceso que es Certificación inscripción elector. En este subproceso lo que se hace

es leer el archivo elector file para generar un nuevo archivo llamado certificado elector file, el

cual tendrá aparte de los datos de elector file la fecha, hora, municipio y un número seriado

de certificación.


Página 23


c. Proceso Cierre inscripción candidatos

El proceso se da inicio gracias al evento Finalización jornada inscripción candidatos, el cual

ocurre como una política de la Registraduría Nacional del Estado civil para limitar el proceso

de inscripciones y que no quede activo siempre. Al ocurrir este evento, se da activa el proceso

cierre inscripción candidatos, el cual comienza por el subproceso validación de usuario. Este

subproceso lo que hace es validar el usuario del sistema (registrador y auxiliar/secretaria)

frente a un archivo de registro previo que tiene el sistema llamado usuario file para garanti-

zar perfiles de acceso aumentando los niveles de seguridad del proceso, evitando que perso-

nas externas a los identificados dentro del punto de vista organización puedan interactuar con

el sistema.

Luego de validar el usuario satisfactoriamente, se inicia el subproceso verificación final can-

didatos. Este subproceso lo que hace es leer el archivo de Registro Candidato y traerlo como

un archivo XML (se usa XML porque es un lenguaje universal, es extensible, porque el anali-

zador es un componente estándar que evita bugs y acelera el desarrollo de aplicaciones, por-

que en caso de cambios a nivel de los desarrolladores este archivo es sencillo de entender en

su estructura y procesarla) junto con algunas consultas con las respectivas políticas de seguri-

dad. Al generar el archivo XML, se da inicio al subproceso envío de candidatos a la registra-

duría nacional del estado civil (Bogotá) en el cual el archivo XML generado es enviado vía

Web al servidor de la Registraduría Nacional del Estado Civil.

d. Proceso Cierre inscripción electores

El proceso se da inicio gracias al evento Finalización jornada inscripción electores, el cual

ocurre como una política de la Registraduría Nacional del Estado civil para limitar el proceso

de inscripciones y que no quede activo siempre. Al ocurrir este evento, se da activa el proceso

cierre inscripción electores, el cual comienza por el subproceso validación de usuario. Este

subproceso lo que hace es validar el usuario del sistema (registrador y auxiliar/secretaria)

frente a un archivo de registro previo que tiene el sistema llamado usuario file para garanti-

zar perfiles de acceso aumentando los niveles de seguridad del proceso, evitando que perso-

nas externas a los identificados dentro del punto de vista organización puedan interactuar con

el sistema.

Luego de validar el usuario satisfactoriamente, se inicia el subproceso verificación final elec-

tores, el cual lo que hace es leer el archivo de Registro elector y traerlo como un archivo

XML junto con algunas consultas con las respectivas políticas de seguridad. Al generar el

archivo XML, se da inicio al subproceso envío de electores a la registraduría nacional del

estado civil (Bogotá) en el cual el archivo XML generado es enviado vía Web al servidor de

la Registraduría Nacional del Estado Civil.

e. Proceso votación

El proceso votación se da inicio por el evento habilitación jornada electoral, el cual está

asignado/programado según el cronograma de la Registraduría Nacional del Estado Civil. La

duración de este evento es de 1 día empezando la recepción de votos a las 7am y finalizándo-

lo a las 4pm del mismo día.


Página 24

Al activarse este evento se inicia el subproceso Validación elector/mesa, el cual lo que hace

es verificar que la persona que se está presentando al puesto de votación si este registrado en

el archivo elector file. Si se confirma que está registrado y que está en la mesa de votación

pertinente se pasa al siguiente subproceso llamado Realizar votación.

El subproceso Realizar votación consta de 2 acciones: votar por alcaldía y por concejo. La

acción votación alcaldía genera el archivo Votación alcaldía file, el cual almacena la infor-

mación del candidato por alcaldía que selecciono; mientras que la acción votar concejo gene-

ra otro archivo llamado votación concejo file, el cual almacena la información del candidato

por concejo. Paralelo a eso, se crea un archivo llamado Registro votación el cual recopilaría

la información que traen los formularios tarjetón alcaldía y tarjetón concejo para compilarlos

en un solo archivo. Es decir el archivo Registro votación llevaría los datos de votación alcal-

día file y votación concejo file más unos atributos extras como un numero seriado de voto por

mesa de votación, el número de mesa, la hora, la fecha.

Al finalizar la creación de estos 3 archivos, se pasa al subproceso Confirmación donde el

sistema debe intentar leer los archivos previamente generados, si los lee satisfactoriamente

presentara en pantalla un mensaje de aprobación para finalizar este subproceso.

Luego, se inicia el ultimo subproceso llamado Certificación Jornada electoral, el cual gene-

rara un documento que certifique que el elector si ejerció su derecho. La generación de este

documento se da mediante la lectura del archivo elector file para abstraer los datos necesarios

y crear un nuevo archivo llamado certificado votación file, el cual, además de los datos toma-

dos de elector file, tendrá fecha, hora, numero de votante de esa mesa y la mesa de votación

como atributos extra; esto será la fuente para imprimir el certificado de votación.

f. Proceso Escrutinio de resultado

Este último proceso se inicia bajo el evento jornada electoral finalizada, quien se programa a

dar inicio después de que pasa el evento habilitación jornada electoral, es decir después de las

4pm del día de elecciones puede ejecutarse este proceso.

Se comienza con el subproceso de validación de usuario, el cual lo que hace es validar el

usuario del sistema (registrador y juez) frente a un archivo de registro previo que tiene el

sistema llamado usuario file para garantizar perfiles de acceso aumentando los niveles de

seguridad del proceso, evitando que personas externas a los identificados dentro del punto de

vista organización puedan interactuar con el sistema.

Luego de esto, se inicia el subproceso conteo de votos, el cual consta de accesar la base de

datos donde se encuentran los archivos votación concejo file y votación alcaldía file, leerlos y

generar un script para realizar el conteo respectivo por partido político y por candidato. Antes

de finalizar el subproceso se crea el archivo Registro Escrutinio el cual recopila los datos que

trae el formulario E-24 y E-26 (formato e-24 y formato E-26) de manera manual. Al finalizar

ese script se da inicio al subproceso confirmación/aprobación donde los resultados generados

por el script se almacenan por separado en 2 archivos nuevos aparte del archivo Registro

escrutinio: escrutinio concejo file y escrutinio alcaldía file. Luego de generados, saldrá en


Página 25


pantalla al registrador y juez si están de acuerdo con los resultados generados, de ser así, se

finalizara el subproceso Confirmación/aprobación y se pasara al siguiente subproceso.

Luego de confirmación/aprobación se inicia automática el subproceso envío de resultados a

la registraduría nacional del estado civil (Bogotá) donde se transforman los archivos escruti-

nio concejo file y escrutinio alcaldía file en archivos formato XML con las respectivas nor-

mas de seguridad para ser enviado vía Web a los servidores de la Registraduría Nacional del

Estado Civil en Bogotá. Concluido este envío, se finaliza el subproceso y se iniciara el sub-

proceso de Publicación de resultados en el cual, se mostrara la información resumida del

archivo Registro escrutinio.

1.8 Vista de Co-operación del Proceso de Negocio (Business Process Co-operation Viewpoint)

Esta Vista refleja claramente que actores interactúan con cual servicio, a la vez, como cada

servicio es soportado por los procesos y subprocesos que se reconocieron y cuales se mejora-

ron con aplicaciones software en el diseño para la votación electrónica en Choachí. Esto per-

mite definir los tipos de perfiles a generar y sus alcances dentro del sistema mejorando la

seguridad de voto.

Figura 6. Vista de co-operacion del proceso de negocio (previa)

La figura 6 completa la puede ver en el anexo A figuras 35, 36, 37, 38.

En esta vista los procesos que se llevan a cabo son los mismos que se ilustraron en la vista

anterior: Inscripción de candidatos, inscripción de electores, votación, cierre de inscripción

candidatos, cierre de inscripción electores, escrutinio de resultado.

a. Proceso inscripción candidato

Este proceso es solicitado bajo 3 servicios de negocio con los cuales interactúa solamente el

actor candidato: el servicio de registrar inscripción candidato, el servicio de modificar ins-

cripción candidato y el servicio de entregar certificación candidatura.

Cuando el candidato solicita el servicio de registrar inscripción candidato se corre el proceso

inscripción de candidato desde el comienzo con el subproceso validar candidato.

Si el candidato solicita el servicio de modificar inscripción candidato no es necesario realizar

todo el subproceso de validar candidato ya que solo necesita verificar la identidad y seguir

con el subproceso de Registrar candidato ya que el candidato ya debe estar registrado.


Página 26

Si el candidato solicita el servicio entregar certificación candidatura solo interactuara con el

ultimo subproceso llamado Certificación inscripción candidato.

El subproceso de validar candidato esta soportado en el servicio de aplicación llamado Servi-

cio MORPHOCHECK. Los subprocesos Registrar candidato y Certificación inscripción

candidato están soportados en el servicio de aplicación Servicio registro candidato.

b. Proceso Inscripción elector

El proceso de inscripción electores recibe los servicios ejecutados por el actor elector. En este

proceso hay 2 servicios de negocio que son ofrecidos al elector: el servicio de registrar ins-

cripción elector y el servicio entregar certificado inscripción.

El servicio Registrar inscripción elector esta soportado por todo el proceso de inscripción

elector iniciando desde el subproceso de validad elector. Mientras que, el servicio entregar

certificado inscripción esta soportado solo en el último subproceso llamado certificación

inscripción elector.

A su vez, el subproceso validar elector tiene el soporte del servicio de aplicación llamado

Servicio MORPHOCHECK, mientras que los subprocesos registrar elector y certificación

inscripción elector tienen el soporte del servicio de aplicación Servicio registro elector.

Se resalta que la función de guía de este proceso lo puede ejecutar tanto el registrador muni-

cipal como el auxiliar/secretaria.

c. Proceso Cierre inscripción candidatos

En este proceso solo interactúa el actor registrador mediante el único servicio de negocio que

se ofrece: cierre inscripción candidatos.

Este servicio esta soportado por todo el proceso, y se empieza desde el subproceso de valida-

ción de usuario.

El subproceso de validación de usuario esta soportado en el servicio de aplicación llamado

servicio usuarios sistema; mientras que el subproceso de verificación final candidatos esta

soportado en el servicio de aplicación Servicio registro candidato.

d. Proceso Cierre inscripción electores

En este proceso solo interactúa el actor registrador mediante el único servicio de negocio que

se ofrece: cierre inscripción electores.


ción de usuario.


Página 27



servicio usuarios sistema; mientras que el subproceso de verificación final electores esta

soportado en el servicio de aplicación Servicio registro elector.

e. Proceso votación

El proceso de votación tiene como actores al registrador y al elector. El registrador interac-

túa con el servicio de habilitar jornada electoral, el cual consiste de permitir al sistema ini-

ciarse y finalizarse según lo pauta la registraduría nacional del estado civil bajo la acción del

registrador. Este servicio se encarga de que el resto de subprocesos pueda inicializarse.

El elector interactúa con 2 servicios que tienen el soporte de este proceso: servicio de Regis-

trar votación y servicio de entregar certificado votación.

El servicio de registrar votación ejecuta la totalidad del proceso votación, iniciando por el

subproceso de validación elector/mesa; mientras que el servicio entregar certificado votación

solo utiliza el ultimo subproceso llamado certificación jornada electoral.

El subproceso de validación elector/mesa esta soportado en el servicio de aplicación llamado

servicio registro elector. Los subprocesos realizar votación y certificación jornada electoral

están soportados por el servicio de aplicación llamado servicio votación.

Los actores encargados de supervisar dentro de la ejecución los subprocesos de validación

elector/mesa y certificación jornada electoral son el auxiliar/secretaria y el jurado.

f. Proceso Escrutinio de resultado

En este proceso interactúa en paralelo tanto el actor registrador como el juez mediante el

único servicio de negocio que se ofrece: Realizar escrutinio.


ción de usuario.


servicio usuarios sistema; el subproceso de conteo de votos esta soportado en el servicio de

aplicación Servicio votación y los subprocesos de confirmación/aprobación, envío de resul-

tados a la registraduría nacional del estado civil (Bogotá) y publicación de resultados están

soportados en el servicio de aplicación llamado Servicio resultados.

1.9 Vista de Comportamiento de la Aplicación (Application Behavior Viewpoint)

Esta vista es el elemento integrador de la arquitectura empresarial con la arquitectura de

software, ya que desde aquí, se puede apreciar dentro del proceso que desarrollo software

serviría para soportar los procesos que posee la empresa o que se han diseñado para mejorar

el rendimiento de la empresa en búsqueda de cumplir con la estrategia de la empresa.


Página 28

Figura 7. Vista de comportamiento de la aplicación (previa)

La figura 7 completa la puede ver en el anexo A figuras 39, 40, 41 y 42.

En este punto, debido a que se darían las pautas para seguir la construcción de la arquitectura

de software, se escoge que el lenguaje para el intercambio de información a emplear en el

sistema de voto electrónico será el XML. La decisión se toma basada en 2 aspectos: el prime-

ro, que el lenguaje XML no necesita un desarrollo específico de aplicaciones para que los

datos contenidos en los documentos sean comprendidos por la persona que maneja la infor-

mación. Los mismos datos XML pueden ser presentados tanto en un browser WEB como en

una aplicación interna (asumiendo que existe una interfaz de aplicación) sin ninguna manipu-

lación adicional o programa especial; y segundo porque dentro de los márgenes legales que

rigen a las entidades del estado se desarrollo un estándar para la comunicación entre dichos

entes llamado GEL-XML [42]. Esta política se constituyo gracias al proyecto de Gobierno En

Linea (GEL) de la presidencia de la república de Colombia, en el cual se estipula la creación

del estándar GEL-XML para el intercambio de información entre entidades del estado con

determinados parámetros de seguridad.

A partir de este punto, hay que anotar que las aplicaciones que se desarrollen serán tipo Web

Services para permitir desarrollos ligeros y de fácil compenetración con el lenguaje XML

definido previamente.

a. Aplicación MORPHOCHECK

Esta aplicación ya la tiene creada la Registraduría municipal de Choachí y da soporte al ser-

vicio de aplicación Servicio MORPHOCHECK. Fue adquirida por la registraduría nacional

del estado civil para facilitar la verificación de identidades y es utilizado en las distintas regis-

tradurías municipales para garantizar la entrega de documentos a los verdaderos dueños. Hay

que aclarar que ni el candidato ni el elector podrán solicitar interactuar con la aplicación ni

con el servicio MORPHOCHECK a ningún nivel, debido a que esos actores solo interactúan

con los servicios de negocio y no con el resto de procesos o servicios que se dan en las capas

de aplicación y tecnología. Además, MORPHOCHECK (en todas sus formas: en capa de

aplicación y/o de tecnología) es de uso privativo de la registraduría y se utilizara para aumen-

tar la seguridad en el proceso del voto. De esta aplicación solamente se utilizara a los archi-

vos Petición cedula data, huella dactilar data, y el ID persona file que es donde se almacena

toda la información de los ciudadanos.

Su uso será el siguiente: el registrador solicita la cedula del elector/candidato, lee el código

de barras de la cedula con el dispositivo de lectura biométrica y de código de barras, la apli-

cación MORPHOCHECK confirma el número y los datos parciales, el registrador solicita al

elector/candidato colocar su huella digital en el dispositivo y luego la aplicación

MORPHOCHECK confirma que la huella leída es de la persona que está en el documento.


Página 29


b. Aplicación Registro Candidatos

Esta aplicación debe ser creada, y daría soporte al servicio de aplicación Servicio Registro

Candidato. Esta aplicación debe cumplir con 2 funciones: la función de creación registro

candidato y actualización registro candidato. La función de creación registro candidato se

encargara de validar los datos leídos de la persona en ID Persona File, crearle un registro en

el archivo candidato data y almacenarlo en el archivo registro candidato file data.

Por otra parte, la función actualización registro candidato para poder accesar al registro y

modificarlo deberá leer el archivo ID Persona File, para luego modificarlo en el archivo can-

didato data y finalmente almacenar esta modificación en el archivo registro candidato file

data

c. Aplicación Registro electores

Esta aplicación debe ser creada, y dará soporte al servicio de aplicación Servicio Registro

Elector. Esta aplicación debe cumplir con la función de creación registro elector. La función

de creación registro elector se encargara de validar los datos leídos de la persona mediante la

lectura del archivo ID Persona file, crearle un registro en el archivo elector data y almacenar-

lo en el archivo registro elector file data.

d. Aplicación votación

Esta aplicación debe crearse y dará soporte al servicio de aplicación Servicio votación. Esta

aplicación consta de 2 funciones: una llamada validación de identidad que usara el archivo

Registro Elector File Data para garantizar que la persona que se acerca a la mesa de votación

es quien está registrada. La otra función es votación.

A la vez, la función votación está compuesta de 2 sub-funciones más: votación alcaldía y

votación concejo. La sub-función votación alcaldía inicia por seleccionar la opción de vota-

ción por alcaldía en el menú que se despliegue, seguidamente el elector en Escoger candida-

to/Partido por alcaldía seleccionara sobre la lista de candidatos inscritos su favorito, esto se

almacenara en un archivo llamado alcaldía data. Seguidamente la aplicación en confirmación

voto por alcaldía deberá mostrar una pantalla pidiendo al elector confirmar su opción. Al

confirmar la opción, su voto se almacenara (almacenar voto alcaldía) en el archivo Votación

alcaldía file data.

Al finalizar esta opción, se volverá al menú de selección, solo que la opción Votación por

alcaldía saldrá deshabilitada al ya haberse realizado.

La sub-función votación concejo inicia por seleccionar la opción de votación por concejo en

el menú que se despliegue, seguidamente el elector en Escoger candidato/Partido por conce-

jo seleccionara sobre la lista de candidatos inscritos su favorito, esto se almacenara en un

archivo llamado concejo data. Seguidamente la aplicación en confirmación voto por concejo

deberá mostrar una pantalla pidiendo al elector confirmar su opción. Al confirmar la opción,

su voto se almacenara (almacenar voto concejo) en el archivo Votación concejo file data.


Página 30

La sub-función Votación se finalizara generando el certificado electoral para el elector.

e. Aplicación Resultados Escrutinio

Esta aplicación solo podrá ser accesada después de finalizada la jornada electoral y revisando

que se hallan realizados votos. Esta aplicación también deberá ser creada como la mayoría de

aplicaciones y dará soporte al servicio de aplicación Resultados escrutinio.

La aplicación tiene una función llamada conteo/confirmación votos. Esta aplicación funciona-

ra ejecutando primero un script de consulta sobre la base de datos para contar votos, luego de

estos, los resultados se generaran en un formato similar al formato manual E-24, estos datos

quedaran almacenados en el archivo E-24 data. Luego de generado este formato aparecerá

una pantalla con la vista de cómo quedo generado el formato y saldrá un mensaje solicitando

confirmación del formato generado, si se aprueba se almacenara en un archivo llamado E-24

file data.

Luego de aprobar el formato E-24, se generan los resultados respectivos al antiguo formulario

manual E-26, estos datos quedaran en un archivo llamado E-26 data. Posterior a esto, apare-

cerá una pantalla con la vista de cómo quedo generado el formato y saldrá un mensaje solici-

tando confirmación del formato generado, si se aprueba se almacenara en un archivo llamado

E-26 file data. Finalizado este archivo, se enviaran vía Web el archivo E-24 file data y el E-

26 file data a la registraduría nacional del estado civil con las respectivas políticas de seguri-

dad estimadas por este ente.

1.10 Vista de Infraestructura (Infrastructure Viewpoint)

Esta vista ilustra la infraestructura necesaria para dar cumplimiento a los requisitos identifi-

cados dentro del diseño de procesos de negocio que se generó, para poder llevar acabo (en el

debido momento) la implementación del voto electrónico en el municipio de Choachí.

Figura 8. Vista de Infraestructura (previa)


Página 31


La figura 8 completa la puede ver en el anexo A figura 43.

A nivel de la registraduría de Choachí se requieren: 2 equipos de cómputo que ya se tienen,

una conexión a Internet o en su defecto a la Red de Alta Velocidad del Estado Colombiano

(RAVEC) y un mainframe donde estará el software para manejo de bases de datos DBMS, un

software para el manejo de mensajes Message Queing y el software de la aplicación Registro

Web Service y Escrutinio

A nivel de zona electoral, se debe tener n equipos de cómputo, donde cada equipo representa-

ra una estación o mesa para votar. Además de esto, un mainframe que se llamará votoframe,

el cual tendrá el software Votación, el software Escrutinio y el software DBMS para almace-

nar los votos. Estos equipos y el votoframe deben estar conectados a internet o en su defecto

a RAVEC para permitir el proceso de escrutinio posterior y generar replicación de la DBMS

al mainframe de la registraduría para aumentar la seguridad de la información.

Los demás elementos son ajenos a la implementación pero se hace una suposición de la com-

posición de estos para una futura simulación.

2. Modelo de Arquitectura de Software

El proceso de diseño de unas aplicaciones para dar vida al voto electrónico en el municipio de

Choachí no puede ser un proceso improvisado y mucho menos empírico. Es por eso, que

como elemento innovador e integrador se vio necesario reconocer previamente la estructura

de la línea estratégica del voto en la Registraduría municipal de Choachí para reconocer cada

uno de los procesos que componen esta línea, su funcionamiento e identificar los puntos débi-

les o de mejora que se podían trabajar dentro de esta línea estrategia.

Este elemento lo trabajamos como la Arquitectura empresarial de la Registraduría municipal

de Choachí (documento anterior), en la cual se identificaron todos los procesos propios del

voto, además de pensarse y posteriormente establecerse en la vista de comportamiento de la

aplicación una serie de aplicaciones necesarias para soportar las mejoras en los procesos co-

mo son: MORPHOCHECK, registro de candidatos, registro de electores, votación, y escruti-

nio de resultados. Cabe resaltar que, de estas aplicaciones se descarta la creación de

MORPHOCHECK ya que es un producto adquirido por la Registraduría Nacional del Estado

Civil, la cual en el momento de implementación de este modelo de Arquitectura de Sistema,

le podría solicitar a la empresa SAGEM (creadora de MORPHOCHECK) diseñar una interfa-

ce para integrar los datos que se requieran de esta aplicación para el resto del modelo de ar-

quitectura de software para el voto electrónico en el municipio de Choachí.

Basado en la vista de comportamiento de la aplicación, se hace un proceso de valoración del

estado actual de la registraduría al estado deseado mediante el proceso de diseño de casos de

uso, para poder apreciar lo que se necesita, como se necesita y quienes interactuarían con la

herramienta a desarrollar.


Página 32

Figura 9. Estado actual de la registraduría municipal de Choachí con respecto al voto (previa)

Para la figura completa, vea el anexo A figura 44.

En el caso de uso actual, se puede apreciar que todos los procesos que se llevan a cabo en

Choachí son de forma manual, no hay ninguno con soporte tecnológico o automatizado, e

influyen muchos actores.

Basado en el estado actual, se plantea un estado deseado para el voto, donde ya no será el

voto de forma manual sino se busca obtener el voto electrónico para el municipio.

A partir del modelo de caso de uso votación actual se planteó la re-estructuración del modelo

para poder acoplar el voto electrónico de acuerdo a la reglamentación actual de la Registradu-


Página 33


ría Nacional del Estado Civil. Dentro de los elementos que se modificaron con este modelo

As Is – To Be, donde el As Is representa el estado actual (CU votación actual) y el To Be el

ideal para el voto electrónico (CU E-vote2), se destaca no solo la inclusión de nuevos casos

de uso sino las modificaciones a nivel de actores donde se eliminaron algunos de ellos y se

crearon otros en equilibrio del ideal planteado para el voto electrónico en el municipio de

Choachí. Se tiene en cuenta que para definir los actores finales, quienes están en el CU E-

vote2, se migró de los actores actuales a los necesarios por la arquitectura empresarial, y pos-

teriormente a su relación en la implementación de la arquitectura de software.

ACTORES CASOS DE USO

VOTACION ACTUAL

ACTORES

ARQUITECTURA

EMPRESARIAL

ACTORES CASOS DE

USO E-VOTE2

Registrador Registrador Registrador

Elector Elector Elector

Juez Juez Juez

Candidato Candidato Candidato

Auxiliar Auxiliar Auxiliar

Jurado Jurado Sistema

Alcalde Desarrollador

Testigo Back Office

Tabla 7. Mapeo de Actores CU actual vs Actores Arquitectura Empresarial vs Actores CU E-

Vote2

La función del testigo la puede asumir cualquier elector por lo cual es innecesaria. De

igual forma, la presencia del alcalde para el antiguo traslado del arca triclave tampo-

co será necesaria, por tanto su presencia como actor definido no es necesaria.

Por otra parte, el actor Jurado desaparece físicamente a nivel del diseño de software a

pesar que se mantiene en la arquitectura empresarial, esto se da a que un elector pue-

de ser jurado asignándolo no como un actor sino como un rol que puede desempeñar.

El desarrollador y los cargos de Back office son asignados en el actor sistema y difie-

ren dependiendo del rol.


Página 34

Figura 10. Estado deseado del voto electrónico en el municipio de Choachí (previa)

Para ver la figura completa ver anexo A figura 45.

Para el estado deseado del voto electrónico, se espera mejorar la seguridad de los procesos

que constituyen esta línea estratégica y otorgarle nuevas formas de auditabilidad a los mismos

en cualquier momento. Además de intentar mejorar el funcionamiento de estos procesos me-


Página 35


diante la automatización o implementación de herramientas tecnologías para cumplir con el

voto.

2.1 Identificación y Selección de Patrones de Negocio

Con base en la arquitectura empresarial definida anteriormente, se puede establecer según la

metodología BPTrends [43], una relación de los procesos que tiene la Registraduría munici-

pal de Choachí contra el uso los mismos como procesos intensivos definidos como procesos

intensivos en sistemas, procesos intensivos en personas, procesos intensivos en decisión y

procesos.

Procesos intensi-

vos en sistemas

Procesos

intensivos en

personas

Procesos

intensivos en

decisión

Procesos

intensivos en

documentos

Proceso de inscrip-

ción de candidato

x x

Proceso inscripción

de electores

x x

Proceso cierre de

candidatos

x x

Proceso cierre de

electores

x x

Proceso de votación x x

Proceso de escruti-

nio de resultados

x x

Tabla 8. Procesos de la registraduría municipal de Choachí vs Procesos según BPTrends. Autor:

Daniel Cáceres.

Este mapeo entre procesos y procesos intensivos sirve como elemento de identificación pre-

vio para poder establecer que si sea necesario automatizar algunos procesos o reorganizarlos.

Según se aprecia en la tabla 8, se ve que los procesos de la registraduría si pueden ser aptos

para ser automatizados lo que a su vez trae el reorganizar algunos.

Teniendo claro que según el análisis de BPTrends la arquitectura empresarial (específicamen-

te la vista de comportamiento de la aplicación) tiene toda la viabilidad, se debe buscar una

forma de relacionar ese modelo a un diseño de arquitectura de software.

La mejor forma de hacerlo, es mediante la identificación de patrones de negocio (los cuales

darán mayor fortaleza a la arquitectura empresarial) que posteriormente puedan ser mapeados

a patrones de software (tanto de arquitectura como de diseño) ligándola directamente a la

arquitectura empresarial con la arquitectura de software.


Página 36

Forster plantea en [44] unos patrones de mejora de los procesos de negocio que se clasifican

en 4 tipos: Patrones básicos de control de flujo, Patrones avanzados de ramificación y sincro-

nización, patrones estructurales y patrones de múltiples instancias. Según Forster, describe

estos patrones de mejora de procesos de negocio como un intento para describir soluciones

satisfactorias para modelar los pasos de mejora operacionales de un proceso de negocio.

Basado en este concepto, los procesos de negocio del voto electrónico fueron mapeados a

estos patrones, identificándolos mediante el subproceso perteneciente a cada proceso del mo-

delo de arquitectura empresarial de mayor influencia para el diseño según la definición de

cada patrón de negocio.

Patrones básicos

de control de

flujo

Patrones avanza-

dos de ramifica-

ción y sincroni-

zación

patrones

estructurales

patrones

de múlti-

ples ins-

tancias

Proceso de inscrip-

ción de candidato

Morphocheck

Proceso inscripción

de electores

Morphocheck

Proceso cierre de

candidatos

Omitir validación

usuario (registra-

dor)

Proceso cierre de

electores

Omitir validación

usuario (registra-

dor)

Proceso de votación Morphocheck

Proceso de escruti-

nio de resultados

Omitir publicación

resultados físicos

Tabla 9. Patrones de negocio de Forster vs Procesos de negocio de la Registraduría municipal de

Choachí. Autor: Daniel Cáceres

Según el mapeo, los patrones de negocio que reflejan las necesidades de los procesos defini-

dos en la arquitectura empresarial por mayor cantidad de procesos relacionados son los Pa-

trones básicos de control de flujo y los patrones estructurales.

El problema que trae estos patrones, es que para llevarlos a un nivel más bajo hay que estar

ligado obligatoriamente al Framework de Forster. Dada esta situación, se buscó unos patrones

de negocio más específicos, situación que nos llevó a encontrar en la base del conocimiento

información de Kim et. Al. Según Kim et al. en [45] comentan que los patrones de Forster

pueden ser ajustados a un nivel de detalle más concreto sin emplear su framework. Lo prime-

ro que plantean Kim et al es que se le cambie el término de patrones de mejora de procesos de

negocio por patrones de cambio de procesos de negocio, y luego definen 3 nuevas categorías

con base a los patrones definidos anteriormente por Forster y los patrones asociados a cada


Página 37


categoría: Patrones de extensión/borrado de actividad, Patrones de fusión/cambio de activi-

dad, y patrones de división/cambio de actividad.

Dentro del documento de Kim et al, no presenta una relación directa con los patrones de

Forster, solo dice que los tomo como base. Para este documento, el autor realiza una relación

de los patrones de Forster con los de Kim et al basándose en los conceptos y términos defini-

dos en sus artículos previamente citados.

PATRONES DE FORSTER PATRONES DE KIM ET AL

Patrones básicos de control de flujo Patrones de extensión/borrado

de actividad

Patrones avanzados de ramificación y

sincronización

Patrones de fusión/cambio de

actividad

patrones estructurales Patrones de fusión/cambio de

actividad

patrones de múltiples instancia patrones de división/cambio de

actividad

Tabla 10. Patrones de negocio de Forster vs Procesos de negocio de la Registraduría municipal

de Choachí. Autor: Daniel Cáceres

El resultado de esta tabla refleja que los procesos de negocio de la Registraduría municipal de

Choachí con respecto a la línea estrategia del voto según el esquema de Kim et al, estarían

reflejados en los patrones de extensión/borrado y fusión/cambio de actividad. Basado en esta

comparación, para ir a un nivel de detalle más específico y no mantener la generalidad que

representaba los patrones de Forster, se presenta la siguiente tabla donde se mapearan los

procesos de negocio de la registraduría versus los patrones de Kim et. Al, identificando el

patrón especifico de negocio de cada clasificación con el respectivo proceso de negocio.

Patrones de exten-

sión/borrado de acti-

vidad

Patrones de fu-

sión/cambio de acti-

vidad

Patrones de

división/cambio

de actividad.

Proceso de

inscripción de

candidato

Patrón de cambio de

contenido de actividad

Proceso ins-

cripción de

electores



Proceso cierre

de candidatos

Patrón de borra-

do/desvió de actividad

Proceso cierre

de electores

Patrón de borra-



Página 38

Proceso de

votación



Proceso de

escrutinio de

resultados

Patrón de borra-


Tabla 11. Patrones de negocio de Kim et Al. vs Procesos de negocio de la Registraduría munici-

pal de Choachí. Autor: Daniel Cáceres.

Debido a que los patrones de negocio identificados son el Patrón de cambio de contenido de

actividad y el patrón de borrado/desvió de actividad, pertenecientes a dos categorías de clasi-

ficación de patrones diferentes como lo son el "fusión/cambio de actividad” y el “exten-

sión/borrado de actividad”, se buscó dentro de la base del conocimiento la forma de asociar-

los al diseño del software. Vistos estos patrones y debido a la diferencia entre ellos dada su

clasificación, se encontró que la implementación de estos patrones de negocio en software

sólo se puede hacer mediante un patrón arquitectónico definido como el patrón layers [46] o

Layered architecture pattern [47].

Considerando que el patrón layers su objetivo es descomponer en su-btareas la estructura del

software donde cada sub-tarea tiene una función especificada, se utilizará el patrón N-Tier

[48] como la aproximación más clara de este patrón para su implementación en un web servi-

ce.

2.2 Introducción al Patrón de Arquitectura N-Tier

El patrón N-Tier es una generalización de la arquitectura de tres capas. La arquitectura de 3

capas consiste en una capa de presentación, una de negocio y una de bases de datos y la lógi-

ca asociada es ésta, cuando se intenta incorporar en este arquitectura de 3 capas la parte de los

servicios web se presentan problemas de flexibilidad con la arquitectura. Esto hace que se

requiera incorporar una capa adicional de tal suerte que surge la arquitectura N-Ter como se

muestra continuación:

Cliente

Presentación / Web

Lógica de negocio

Persistencia

Figura 11. Diseño de alto nivel: Patrón arquitectónico general N-Tier para el voto electrónico

Ya con un patrón de arquitectura definido para el software, podemos empezar a ir a un nivel

de más detalle.


Página 39


2.3 Identificación y Selección de Patrones de Diseño

Hay muchas formas para poder usar e interpretar los casos de uso (y sus respectivos requeri-

mientos) para llegar a su implementación. Una de las formas que tiene mayor solicitud por la

calidad en que se desarrolla la solución es mediante el mapeo de estos casos de uso a atribu-

tos de calidad. Pero, ¿a qué nos referimos con calidad? Definiciones hay muchas, pero la que

mayor representación tiene en el mundo de la ingeniería de sistemas (en especial la ingeniería

del software) es la definición que da la IEEE en el Standard 729-1983:

“La totalidad de los rasgos y las características de un producto de software que le

confieren la capacidad de satisfacer determinadas necesidades: por ejemplo, cum-

plimiento de las especificaciones.

El grado en que el software posee una combinación deseada de atributos.

El grado en que un cliente o un usuario percibe que el software cumple con sus ex-

pectativas compuesto.

Las características de composición de un software que determinan el grado en que el

software en uso complacerá las expectativas del cliente”.

De estos conceptos de la IEEE, el enfoque se hará sobre la segunda definición, donde se ha-

bla de la combinación deseada de atributos. Basados en este concepto, deducimos que los

atributos de calidad son características que tienen relación directa con el lenguaje de progra-

mación y el entorno para el cual se va a implementar el producto software.

Distintos modelos de los atributos de calidad han sido inventados como el modelo de McCall

[49], el modelo de Boehm [50], el modelo FURPS [51], el estándar ISO/IEC 9126 [52], el

modelo Dromey [53], el modelo de estrella [54], el modelo de redes bayesianas [55] y el mo-

delo “nutshell” de Khosravi y Guéhéneuc [56] que será el modelo que usaremos para nues-

tros atributos de calidad.

Pero reconocer estos atributos de calidad no significa que el desarrollo ya sea de calidad. De

allí, que diversos autores buscaran la forma de crear algún tipo de estándar en el desarrollo

software para mejorar la producción del mismo, y uno de esos autores fue Eric Gamma y su

grupo quienes crearon los “Patrones de diseño” [57].

Posteriormente, diversos autores generaron vínculos entre los atributos de calidad y los patro-

nes de diseño. Para este desarrollo se tomó en cuenta la tabla de comparación de Khosravi y

Guéhéneuc sin los atributos de independencia del software ni independencia del hardware,

donde dependiendo de la calificación de todos los atributos del modelo “Nutshell” se le asig-

naba un patrón de diseño.


Página 40

Figura 12. Tabla de comparación atributos de calidad vs patrones de diseño. Autor: Khosravi y

Guéhéneuc. Modificada por: Anónimo.

Basado en estos conceptos, se reconocieron los atributos de calidad del software para voto

electrónico a desarrollar y se les asigno una calificación. Para ser más específico, se califica-

ron los atributos de calidad por cada aplicación para poder mirar que tipo de patrón se puede

identificar como esencial por aplicación. La clasificación se hace con los parámetros de Exce-

llent (E), Good (G), Fair (F), Bad (B), y Poor (P) que define Khosravi y Guéhéneuc.

La asignación de calificación por atributo de calidad se hace con base en la información obte-

nida mediante la entrevista con el Registrador municipal, los atributos de calidad del docu-

mento de casos de uso y requerimientos, junto con el conocimiento adquirido mediante la

base del conocimiento en la interpretación de las definiciones de los atributos de calidad que

aglomera Khosravi y Guéhéneuc en su artículo.


Página 41


Registro

candidato

Registro

electores

Voto Resultados

Usabilidad (6) E E E E

Formación (5) E E E E

Simplicidad (2) E E E E

Tolerancia al error (9) G G E E

Capacidad de expansión (8) G F E E

Generalidad (3) G G G G

Modularidad (4) E E E E

Operatividad (7) E E E E

Expendability3

(1) E E E E

Tabla 12. Aplicaciones vs Atributos de calidad

Después de haber calificados los atributos, se busca cual patrón de diseño se puede acoplar.

Para este proyecto se trabajará con patrones base por aplicación a pesar de las múltiples coin-

cidencias entre características y atributos de las cuatro aplicaciones a trabajar (registro candi-

dato, registro electores, voto, resultado).

1 2 3 4 5 6 7 8 9

Registro candidato E E G E E E E G G

Registro electores E E G E E E E F G

Voto E E G E E E E E E

Resultado E E G E E E E E E

Tabla 13. Aplicaciones vs Atributos de Calidad según Khosravi y Guéhéneuc

Según esto, no hay un patrón que acierte en su totalidad con cada aplicación. Los parecidos

son:

Registro candidato E E G E E E E G G

Patrón probabilidad

de acierto

Abstract Factory E E G G G G G G G 0.55555556

3

Se deja el término en ingles ya que no tiene una traducción clara para el lector.


Página 42

Decorator E E G F G G G G F 0.44444444

Iterator E E G F G F F G G 0.55555556

Tabla 14. Aplicación Registro Candidato vs Patrones de diseño

El patrón para la aplicación de registro de candidatos que se va a utilizar en el diseño es Abs-

tract Factory debido a que es un patrón de creación que abstrae el tipo concreto de objeto

producido es decir no cambia si el objeto a crear es de otro tipo. En nuestro caso las caracte-

rísticas del candidato puedan cambiar pero sin importar estos cambios su forma de interpreta-

ción será la misma. No obstante se ve reflejado el patrón Iterator en la aplicación debido a

que ésta también debe soportar el proceso de cierre de candidatos en el cual se bloquea el

ingreso de nuevos registros y se genera un conteo de la totalidad de los candidatos inscritos.

Registro electo-

res

E E G E E E E F G


de acierto




Tabla 15. Aplicación registro elector vs Patrones de diseño

El registro de electores es Abstract Factory debido a la similitud de este proceso con el proce-

so de registro candidatos, salvo que los registros de los electores no pueden modificarse.

Aplicación vota-

ción

E E G E E E E E E


de acierto




Tabla 16. Aplicación votación vs Patrones de diseño

El patrón que se escoge para el proceso de votación es el Iterator debido a que este patrón

facilita el recorrido de la selección de opción por candidato, es decir permitirá que el elector

pueda fácilmente anular o devolver una opción seleccionada ya sea por alcaldía o por conce-

jo.


Página 43


Resultados escruti-

nio

E E G E E E E E E


de acierto




Tabla 17. Aplicación resultados escrutinio vs Patrones de diseño

Por cada uno de los candidatos como por partido se deben hacer recorridos sobre los registros

almacenados para generar los resultados de la votación, es por esto que el patrón Iterator es

quien permite realizar ésta navegación.

Definidos los patrones de diseño por aplicación, hay que hacer una aproximación de estos a

los patrones para Web Services debido a que el diseño de este sistema de voto electrónico

debe ser diseñado y en su momento implementado para Web Services debido a la ligereza

que ofrece las aplicaciones construidas con web services, ademas de las políticas nacionales

de sitios web definidos dentro de la Registraduría Nacional del Estado Civil y en el programa

Gobierno en línea, proceso que fue narrado en el documento de arquitectura empresarial du-

rante la construcción de la vista de comportamiento de la aplicación, donde se justifica el uso

del lenguaje XML para el intercambio de información y la orientación hacia los web services.

Considerando esta restricción y entendiendo que los patrones de diseño pueden ser utilizados

en lenguajes de programación como C++, C# y Java con sus respectivos cambios ajustados al

lenguaje, se escoge para este proyecto diseñar la arquitectura de software con base en el len-

guaje Java debido a la fortaleza en seguridad y las estructuras a nivel de patrones que para

Web Services ofrece Java [48][58][59], situación que no ofrece Microsoft; esto complemen-

tado con la especificación de propiedad intelectual que se hizo de la propuesta completa don-

de se especificó el uso de software libre con licencia GPL versión 3, aceptada tanto por el

director de la tesis como por el evaluador de la propuesta.

Según Monday [48], los patrones que se acercan al Abstract Factory y al Iterator de los patro-

nes GOF son: El patrón Service Factory y el Business Process (Composition).

El patrón Service Factory es un patrón que tiene sus raíces el patrón GOF Abstract Factory.

La idea de este patrón es simple: debe aislar los puntos de la variabilidad en bloques de códi-

go de contenido fácilmente. Es decir, el uso de este patrón es para abstraer su aplicación fuera

de los detalles de escoger un servicio web socio. La responsabilidad del Service Factory es

seleccionar una de las implementaciones de servicio y retornar una implementación trabajan-

do que se adhiera a la interface común de la aplicación.


Página 44

El patrón Business Process (Composition) es un patrón cuya intención es ilustrar y proveer

una guía para combinar las actividades de negocio en un único y consumible Web Service

con una interface bien definida. Este patrón también es un intento para cambiar la mentalidad

de la perspectiva orientada a objetos del lenguaje java a una perspectiva de procesos de nego-

cio.

Siguiendo estos conceptos, la relación de las aplicaciones a los patrones de diseño y luego a

los patrones de Web Services se ilustra en la figura 13.

Basados en la figura 13, se puede apreciar que las aplicaciones de registro candidato y regis-

tro electores comparten el mismo patrón GOF como de Web Services, de igual forma la apli-

cación Votación con la aplicación Resultado Escrutinio. Con base a esto, se integran estos

patrones de web services al patrón arquitectónico definido anteriormente, el cual es el N-Tier.

La figura 14 ilustra la integración de estos patrones Web Services. Esta figura nos permite

observar del lado izquierdo el nombre de cada una de las capas, en el centro se ve la estructu-

ra del patrón Service Factory y al lado derecho se aprecia la figura del patrón Business Pro-

cess (composition).

Aplicación Registro

candidato

Aplicación

Registro electores

Aplicación votación

Aplicación resultado escrutinio

Abstract Factory Abstract Factory Iterator Iterator

Service Factory(Web

Service Pattern)

Service Factory(Web

Service Pattern)

Business Process (Composition

pattern)

Business Process (Composition

pattern)

Figura 13. Mapeo de aplicaciones a patrones GOF y a patrones de Web Services


Página 45


Capa Negocio

Capa presentación

Capa persistencia

Capa Cliente

Application

InterfaceBusinessProcess

Interface Business ActivityBusinessProcessImpl

Directory (ServiceLocator)

Application

ServiceFactory

InterfaceService

ServiceImplA ServiceImplB

BusinessActivityImpl

LinkedListActivitySequence

data

Figura 14. Diseño detallado (nivel 1): Patrón N-Tier más Patrones Web Services

Profundizando el diseño, relacionamos también más patrones dentro de cada uno de los de

Web services ya definidos. De allí, que se relacionen de la siguiente forma:

Para el Service Factory: Para el Business Process (composition)

La clase Application con el patrón Intercep-

ting Filter

la clase Application con el patrón Intercepting

Filter

La clase InterfaceService con el patrón

Front Controller

la clase InterfaceBusinessActivity con el pa-

trón Front Controller

La clase ServiceFactory con el patrón Ser-

vice to worker

la clase InterfaceBusinessProcess con el pa-

trón Front Controller

La clase Directory con el patrón Service

Locator

la clase BusinessProcessImpl con el patrón

Dispatcher View

La clase ServiceImplA y ServiceImplB con la clase BusinessActivityImpl con el patrón


Página 46

el patrón Service Activator. Business Delegate

la clase LinkedListActivitySequence con el

patrón Value List Handler

la clase Data con el patrón Transfer Object y

el Composite Entity

Tabla 18. Relación de patrones en el nivel 1 de diseño

La descripción de los patrones se presenta en el anexo B.

De esta manera, el diseño más detallado, a nivel 2, quedaría construido de la siguiente mane-

ra:


Página 47


CAPA DE INTEGRACIÓN

CAPA DE CLIENTE

CAPA DE PRESENTACIÓN

CAPA DE NEGOCIO

Intercepting Filter

Entrega el control a

FrontContoller

Front Controller

DispatcherView

ServiceTo Worker

Business Delegate

ServiceLocator

Value List

Handler

Composite Entity

TransferObject

ServiceActivator

El front Controller con el intercepting

DECORA en contenido la

interfaz y el front controler decide como se quiere

decorar si añadiendo objetos

compuestos a la interfaz o

mostrando ayudas contextuales, según

la acción del usuario

Se ITERA a través de los servicios y existe

la positibilidad de despachar a quien

lo requiera por medio del front

controller o también la posibilidad de

buscar un servicio en caso que se

tengan elementos tercerizados con

servicios y para ello es el patrón Service

To worker

Si se requiere un objeto de la lista es el patrón Transfer Object el que se

encarga de decidir a que objeto de datos

decirle y en este sentido se acceden a los objetos de datos

a través de una referencia única,

actuando esta parte en un todo como un singletón en el cual no se sabe como se produjo el objeto. De otra parte si los

objetos que se van a obtener tienen una

única forma para darle sentido de

SINGLETON o ABSTRACT FACTORY cuando se accede a

los servicios es usando el Service

Activator

Despacha controlDe procesamiento

Liviano para que múltiples Usuarios puedan

Acceder al sistema sin demoras

Controla procesamiento de

interfaz gráfica

Accede a objetos de negocio

LocalizaServicios

Encapsula datos

Maneja la Granularidad a los

ComponentesDe negocio

Despacha sincrónico procesamiento

Accede a lista de negocio

Intercepting Filter

Entrega el control a

ServiceLocator

Figura 15. Diseño detallado (nivel 2) del voto electrónico


Página 48

3. Diseño de la Base de Datos para el Voto Electrónico

El diseño de la base de datos se crea teniendo en cuenta los actores y elementos de interac-

ción para el sistema de voto electrónico.

El modelo de Bases de datos se construyo bajo la necesidad de dar mayor soporte a la arqui-

tectura de software ya diseñada y teniendo en cuenta aspectos como el material electoral (car-

tillas de preparación de jurados), información de la registraduría municipal (como los tipos

de formularios que se emplean en la línea estratégica de votación), información adquirida

mediante documentación de la registraduría nacional del estado civil en su pagina web y ex-

periencia tanto del registrador municipal así como del autor.

A continuación se muestran los elementos que se interpretaron para la construcción del dise-

ño lógico de base de datos tanto para el proceso de inscripciones como para el proceso de

votación, donde se bosquejó un estado ideal donde los partidos políticos estén interconecta-

dos con la registraduría para la asignación de avales de candidatos y el diagrama lógico de la

base de datos planteada:

3.1 Diseño Lógico de la Base de Datos para el Proceso de Inscripción de Electores y Candidatos

La descripción de las entidades y los atributos se puede apreciar en el anexo C. A continua-

ción se presenta el modelo lógico de la base de datos para el proceso de inscripción de electo-

res y candidatos (Figura 16).

3.2 Diseño Lógico de la Base de Datos para el Proceso de Votación

Debido a que el modelo lógico de base de datos para votación utiliza algunas de las tablas que

se emplearon en el modelo de inscripción se presenta una breve descripción de las entidades

que se creen necesarias aclarar. La totalidad de las descripciones de las entidades y sus atribu-

tos se encuentran en el anexo D.

La entidad inscrip se crea como una copia de la entidad inscripción_elector solo que no con la

totalidad de los atributos. La entidad Inscripcion_candidato del modelo de votación es la

misma entidad inscripcion_candidato del modelo de inscripción, solo que no se dibujó con

sus respectivas conexiones para facilidad de entendimiento.

La entidad partido se duplica ya que en el momento de la jornada de votación pueden haberse

realizado alianzas que no estaban cuando se realizó la inscripción pero que posteriormente se

efectuaron bajo coordinación de la registraduría en su sede central (Bogotá).

La tabla Corporación se crea para poder facilitar la consulta de boletines. El término de cor-

poración se da para los cargos a escoger que hayan: presidencia, referendos, consultas parti-

distas, alcaldía, concejo, gobernación, asamblea, cámara y senado.

Según la descripción presentada, se ilustra el modelo lógico del proceso de votación en la

figura 17.


Página 49


Figura 16. Modelo lógico del proceso de inscripción de candidatos y electores


Página 50

Figura 17. Modelo lógico del proceso de votación


Página 51


V – PROTOTIPO Y VALIDACIÓN

Según la ciencia basada en el diseño, la forma de instanciar el resultado propuesto es median-

te un artefacto, el cual para este proyecto fue un prototipo de interfaces de usuario para el

proceso de inscripción de electores y candidatos así como para el proceso de votación.

1. Prototipo

Este prototipo se llevó a cabo implementando tanto la parte de la arquitectura empresarial

como la arquitectura de software. Para poder implementar la parte de la arquitectura empresa-

rial se interpretaron las vistas desarrolladas en Archimate y se mapearon mediante el modela-

do de Business Process Modeling Notation versión 2.0 (BPMN 2.0). A continuación se pre-

sentan algunos modelos BPMN desarrollados para el prototipo, la totalidad de modelos se

pueden apreciar en el anexo E.:

Figura 18. Modelo BPMN del subproceso de Inscripción de candidatos y electores

Posterior al diseño de los procesos, se desarrollaron Web services para emplear de forma

práctica la arquitectura empresarial así como el manejo de bases de datos. Este prototipo se

hizo empleando la herramienta Bizagi debido a que es de las herramientas gratuitas mas esta-

bles que se encuentran para el manejo de procesos de negocio (BPMS). Bizagi se utilizó para

orquestar los procesos de negocios junto con los web services desarrollados y el DBMS se-

leccionado. Además, Bizagi permite la asignación de roles y usuarios para aumentar paráme-

tros de seguridad y mejorar la auditoria sobre quien manda cada proceso y/o subproceso

A continuación se presentan una imagen del prototipo de interfaces:


Página 52

Figura 19. Inscripción del candidato

El video del prototipo de interfaces se puede apreciar en los siguientes sitios web:

http://pegasus.javeriana.edu.co/~PA111-01-eVoto/video/videoprototipo.avi

http://sites.google.com/site/danielcaceresrincon/schedule/videoprototipo.mp4

La validación del proyecto se realizó en 2 partes: la validación de la arquitectura empresarial

y la validación de la arquitectura de software.

2. Validación de la Arquitectura Empresarial

La percepción personal del autor de validación sea que científicamente, cualquier solución

que se plantee debe ser evaluada en su entorno bajo unos criterios que se establecen por con-

venio en las entidades que dirigen el desarrollo de propuestas de cierta área del conocimiento.

Así como el autor tiene una percepción personal de validación, hay muchas definiciones co-

mo se muestra a continuación:

La guía EURACHEM [60] establece que la validación de métodos es el proceso de

verificar que un método es apropiado para un propósito dado, es decir, para usarse en

la solución de un problema analítico particular.

La versión más reciente de la definición de validación se presenta en la norma ISO

9000:2000 [61] donde establece que la validación es “la confirmación y provisión de

evidencia objetiva de que se cumplen los requisitos para un uso o aplicación previs-

ta”.

Según Kuechler [62], en la ciencia basada en el diseño, la relación de un artefacto di-

señado con la teoría que lo soporta es de extensión y refinamiento. De allí que Gon-

zález [62], plantee que la validación científica basada en el diseño puede ser lograda

mediante artefactos de simulación, aclarando que la validación y evaluación de un

artefacto debe verse desde el punto de vista de la simulación, donde se puede apoyar

http://pegasus.javeriana.edu.co/~PA111-01-eVoto/video/videoprototipo.avi

http://sites.google.com/site/danielcaceresrincon/schedule/videoprototipo.mp4


Página 53


la evaluación de los artefactos mediante el suministro de un ambiente artificial para

probar su utilidad potencial y por lo tanto la validación de la teoría subyacente

Al ser la forma de dar certeza a una solución propuesta, la validación es requerida en normas

sobre sistemas de gestión de la calidad [63], sobre software (ver documento de arquitectura

de software) y sobre los procesos de negocio una empresa [64].

Por último, Khatri et. Al, proponen un concepto de validación donde examinaron los efectos

del conocimiento del dominio de los sistemas de información y el conocimiento del dominio

de aplicación de los mismos en diferentes tipos de tareas de comprensión de esquema: tareas

de comprensión sintáctica y semántica y el esquema basado en tareas de resolución de pro-

blemas [65]. Para el desarrollo de su estudio, utilizaron la teoría del ajuste cognitivo para

establecer las diferencias teóricas en el papel del conocimiento del dominio de aplicación

entre los diferentes tipos de tareas de comprensión del esquema

La parte sintáctica busca evaluar el tema a la raíz del concepto, es decir, la teoría y metodo-

logía; mientras que la parte semántica busca evaluar el tema desde los efectos e implicaciones

prácticos y reales del tópico a validar. Cabe aclarar que esta validación semántica es distinta

de la que promueve Weber et. al [66]. La última parte, la del esquema basado en tareas de

resolución de problemas busca encontrar y evaluar la relación indirecta entre la representa-

ción del problema y los requerimientos de una tarea.

Como resultado de este estudio, Khatri et al concluyen que mientras el conocimiento del

dominio es importante para resolver todo tipo de esquemas conceptuales para la resolución de

tareas en ámbitos de aplicación conocidos y desconocidos, la función de los conocimientos

del dominio de aplicación surten efecto dependiendo del tipo de tarea bajo investigación. De

allí, que sea importante entender que el punto de vista del aspecto real y cotidiano del posible

uso de la solución otorgado por gente que lo vaya a emplear o utilizar es un gran complemen-

to del punto de vista de validación de la solución mediante el proceso científico.

Para este proyecto se decidió emplear parte de la metodología de validación de Khatri et. al

[65] ya que permite analizar de dos formas compuestas la arquitectura empresarial permitien-

do presentar mayor punto de calidad en el resultado esperado y permitiendo ver la validación

desde 2 puntos de vista diferentes. La validación sintáctica se complementó con el esquema

de validación de modelos de madurez de arquitecturas empresariales, el cual fue realizado por

un experto en el área de arquitectura empresarial, el Ing. José C. Niño; mientras que la vali-

dación semántica se complementó con el esquema de validación por un experto quien para

este proyecto es el Registrador Municipal de Choachí, Dr. Jorge A. Díaz.

2.1 Validación Sintáctica realizada por el Ing. José C. Niño

Del análisis realizado por el Ing. José Niño (ver anexo F) se rescatan como elementos para

modificar en una segunda iteración del sistema generar el restante de los puntos vistas para

aumentar la calidad del detalle permitiendo justificar mejor los costos del desarrollo de las

aplicaciones. Tambien considera importante analizar la arquitectura empresarial desde algun

framework de arquitectura empresarial como otra forma de validación aumentando la calidad

de las metodologías ya presentadas. Por utlimo, como consejo ve necesario integrar al muni-


Página 54

cipio directamente en el proyecto para que se tengan en cuenta aspectos como un repositorio

para el proyecto y la adquisición de herramientas para dar pleno soporte a la arquitectura

desarrollada.

2.2 Validación Semántica realizada por el Registrador municipal de Choachí, Dr. Jorge A. Díaz

Por parte del Registrador municipal en el análisis de su validación (anexo G), se puede apre-

ciar que a pesar de ser una primera propuesta este modelo, cumple con los requisitos del voto

sin alterar ninguno de los estamentos de la registraduría nacional del estado civil. Las suge-

rencia del registrador municipal se da hacia el punto de revisar los costos para poderlo hacer

mas accesible, debido a que si el proyecto es iniciado por la registraduría municipal solamen-

te, sin apoyo de ningún otro ente nacional, departamental o municipal, seria un costo alto de

pagar para la registraduría municipal.

3. Validación de la Arquitectura de Software

La validación de la arquitectura de software nos debía garantizar que lo realizado en el diseño

cumplía con alguna guía internacional para la construcción de software, conjuntamente, debi-

do a que fue construido un artefacto que representara esa arquitectura se debía realizar no

solo de forma teórica sino también practica la validación de la arquitectura. Además, era

necesario fundamentar lo robusto que fueron los resultados en cada arquitectura, desde los

conceptos tenidos en cuneta hasta los diseños finales.

De allí, que dentro de la búsqueda en la base del conocimiento y evaluando entre los distintos

tipos de validación que existen para arquitecturas de software se empleara la validación según

ATAM, pues era la que de forma teórica nos permitía evaluar a fondo la calidad del diseño.

No obstante, para validar el prototipo se encontró dentro de las múltiples opciones para vali-

dación de artefactos, que la más adecuada para el prototipo de interfaces funcional creado era

la validación TAM, la cual permitía acercar a los futuros usuarios a la primera iteración real

de la arquitectura.

3.1 Validación según ATAM

El método Architecture Tradeoff Analysis Method – ATAM - según Clements et. Al [67]

[68], es un método que evalúa las consecuencias de las decisiones arquitectónicas a la luz de

los requisitos de los atributos de calidad. ATAM trabaja sobre tres áreas: la noción de estilos

arquitectónicos, las comunidades de análisis de atributos de calidad, y el método de análisis

de arquitecturas de software (Software Architecture Analysis Method – SACAM).

Una de las implicaciones de usar ATAM es que puede ser aplicado al principio del ciclo de

desarrollo de software. De allí que las mayores metas de ATAM sean:

a) Obtener y refinar una declaración precisa del manejo de los requisitos de los atributos

de calidad de la arquitectura.


Página 55


b) Obtener y refinar una declaración precisa de las decisiones de diseño arquitectónico.

c) Evaluar las decisiones de diseño arquitectónico para determinar si dan una respuesta

satisfactoria a las exigencias de calidad.

3.1.1 Presentación de los factores de negocio

Identificando los requerimientos iniciales del sistema se puede visualizar la relación entre

estos requerimientos, los atributos de calidad del sistema y los elementos que están relaciona-

dos con la consecución de estos atributos a nivel de la arquitectura. Este trabajo dará luces

para establecer los escenarios que se tendrán para cada factor de negocio. Lo importante del

método es que una vez se tenga formalizado que el diseño global de la arquitectura ha sido

completamente válido a la luz de los requerimientos, se procede a elaborar los elementos de

diseño para verificar que siguen cumpliendo las especificaciones originales y para este paso

se puede aplicar nuevamente y recursivamente el método. Sin embargo, este tipo de situacio-

nes generalmente se acostumbran a dejar cuando se está haciendo implementaciones modula-

res y se tienen que modificar diseños concretos específicos del lenguaje de programación en

el que se implemente.

Debido a la extensión de los requerimientos del sistema, el análisis se realizara sobre los ca-

sos de uso que reúnen muchos de los requerimientos del sistema. Para ver la tabla completa ir

al anexo H.

Casos de uso Atributo de cali-

dad asociado al

requerimiento

inicial. El que

más prima

Proceso de

negocio que se

relaciona con

dicho requeri-

miento

Elementos de

arquitectura

que intervie-

nen en el

sistema.

Escenarios más relevan-

tes al interior

Almacenar for-

mularios en DB

Modularidad Aplicación Re-

gistro candidato

Service Fac-

tory Pattern

Esc1: Al momento de in-

gresar el formulario otro

usuario desea consultarlo y

modificarlo al mismo tiem-

po

Esc2: En caso de migrarse

la DB a la que acceden los

servicios

Almacenar repor-

tes

Capacidad de ex-

pansión

Aplicación re-

sultado escruti-

nio

Business Pro-

cess

Esc1: Antes de haber ce-

rrado la jornada de inscrip-

ciones de candidatos o de

electores, se requiere tener

un informe sobre los regis-

tros efectuados

Almacenar votos Simplicidad Aplicación vo- Business Pro- Esc1: Se da inicio a la jor-


Página 56

del sistema tación cess nada de votación y se pre-

senta un elector que no está

inscrito en el municipio

Bajar Servicio

Jornada de Vota-

ción

Tolerancia al error Aplicación vo-

tación

Business Pro-

cess

Esc1: Se presentan alterca-

dos de orden público en el

puesto de votación y se

requiere bajar los servicios

antes de la hora estipulada

CerrarProcesoDe

Inscripciones

electores

Operatividad Aplicación Re-

gistro elector

Service Fac-

tory Pattern

Esc1: Intento de ingreso

del nuevo registro de elec-

tor después de cerrar el

proceso

Crear formulario

E-24/E-26

Usabilidad Aplicación re-

sultado escruti-

nio

Business Pro-

cess

Es1: Generar un formulario

de un proceso no estipula-

do

Generar certifica-

do electoral

Expendability Aplicación re-

sultado escruti-

nio

Business Pro-

cess

Esc1: Un usuario que se

inscribió pero no votó re-

clame el certificado electo-

ral

Validar el elector

en jornada de

votación

Generalidad Aplicación Re-

gistro elector

Service Fac-

tory Pattern

Esc1: Se presenta un elec-

tor con una cedula falsa y

pretende votar

Validar mediante

lector biométrico

y de código de

barras en jornada

de inscripción

Formación Aplicación vo-

tación

Service Fac-

tory Pattern

Esc1: Se presenta un elec-

tor con una cedula falsa y

pretende inscribirse.

Tabla 19. Resumen Aplicación de ATAM sobre la arquitectura de sistema del voto electrónico

3.1.2 Análisis de resultados

Con base en la tabla anterior, se procede a dar explicación de cómo la arquitectura y los atri-

butos de calidad definidos si son importantes para la mayoría de escenarios propuestos:

Patrón Service Factory Pattern

Caso de uso Almacenar formularios en DB


Página 57


Lo que permite

el patrón

Permite utilizar el patrón me-

diador para mitigar las diferen-

cias entre servicios

Cuando el tiempo para una transición

llega usted podría configurar la factoría

para localizar el nuevo sistema de persis-

tencia de los datos

Situaciones

Excepcionales

Al momento de ingresar el

formulario otro usuario desea

consultarlo y modificarlo al

mismo tiempo

En caso de migrarse la DB a la que acce-

den los servicios

Justificación Las diferencias en los servicios

de consulta y de modificación

pueden ser mitigadas mediante

el patrón mediator

Lo formularios acceden a una factoría

que permite localizar el nuevo sistema de

persistencia de datos

Resultado Tanto las consultas como las

modificaciones pueden ser

realizadas desde dos usuarios

diferentes

El sistema se libera de tener dependencia

con respecto a la localización de la base

de datos y esto permite agilidad en futu-

ras migraciones de los sistemas de per-

sistencia

Tabla 20. Patrón Service Factory - CU Almacenar formularios en DB


Caso de uso Almacenar Registro Electores

Lo que permite Se podría usar para relacionar objetos de negocio con colecciones de obje-

tos

Situaciones

Excepcionales

La creación de un registro de elector que ya existe

Justificación

El Service Factory permite establecer relaciones directas con la colección

de objetos creados previamente evitando crear redundancias en la capa de

persistencia

Resultado La aplicación del Service Factory permite bajos niveles de redundancia en

los registros de la base de datos

Tabla 21. Patrón Service Factory – CU Almacenar registro electores

El resto de tablas de explicación de los patrones ajustados a los casos de uso se presentan en

el anexo F.

3.2 Validación TAM

El Modelo de Aceptación de la Tecnología (Technology Acceptance Model - TAM) de Davis

[69] es una teoría de los sistemas de información que modela cómo los usuarios llegan a

aceptar y utilizar una tecnología. El modelo sugiere que cuando a los usuarios se les presenta


Página 58

una nueva tecnología, una serie de factores influyen en su decisión sobre cómo y cuándo la

van a utilizar, dicho de otra forma, sirven de base para determinar las actitudes enfocadas al

uso del sistema. Estos factores son:

• PU (Perceived usefulness, Utilidad Percibida): “el grado en que una persona cree que el

uso de un determinado sistema mejora su rendimiento en el trabajo”.

• FUP (Perceived ease-of-use, Percepción de facilidad de uso): “el grado en que una persona

cree que utilizando un sistema en particular, podrá liberarse del esfuerzo que le conlleva

realizar un trabajo” [70].

Variables

externas

Utilidad

percibida

Facilidad de uso

percibida

Intención de

comportamiento

Uso del sistema

actual

Figura 20. Modelo de Aceptación de la Tecnología. Fuente: Davis [69]

Para este proyecto, el usuario elegirá entre dos sistemas con funciones idénticas: el sistema de

registro tradicional y votación de la registraduría municipal de Choachí y el sistema propues-

to en el proyecto representado mediante el prototipo funcional de interfaces de usuario de

inscripción de electores y candidatos.

La forma de realizar esta validación se dio mediante el siguiente formulario de encuesta que

se presentó al registrador municipal, al personero municipal y a un ciudadano al azar. Se to-

mó como guía el tipo de encuesta realizado por Orantes [71], con respectivos ajustes para el

entorno en el cual se va a aplicar, además de controlar las opciones de votación de 7 opciones

como maneja orantes a 5 (totalmente de acuerdo - 5, de acuerdo - 4, ni acuerdo ni desacuerdo

- 3, en desacuerdo - 2, totalmente en desacuerdo - 1):

Hay que aclarar que de las 14 preguntas, solo el registrador debía contestarlas todas. Las otras

dos personas al solo interactuar como quienes recibían la inscripción y como votantes res-

pondieron solo las preguntas de facilidad de uso y de actitud hacia el uso.

El resultado por parte del registrador fue:

¿Es fácil aprender a operar el nuevo sistema? 5

¿Es fácil acceder al sistema para hacer lo que deseo? 4

¿Es fácil aumentar mi experiencia gracias al uso del nuevo sistema? 5

¿El nuevo sistema es fácil de utilizar? 5


Página 59


¿Sería fácil llegar a ser un experto en el manejo del sistema 4

¿El uso del nuevo sistema me ayuda a hacer las tareas más rápido? 5

¿El uso del nuevo sistema mejoraría el funcionamiento de mi trabajo dentro de la

registraduría?

5

¿El uso del nuevo sistema aumenta mi productividad dentro de la registraduría? 5

¿El uso del nuevo sistema incrementa mi efectividad dentro de la registraduría? 4

¿El nuevo sistema es de utilidad dentro de la registraduría? 4

¿Usar el nuevo sistema es una buena idea? 4

¿Usar el nuevo sistema es una inteligente idea? 4

¿Me gusta la idea de usar el nuevo sistema? 4

¿Usar el nuevo sistema me parece (placentero/no-placentero)? 3

Tabla 22. Resultados registrador TAM

El resultado del Personero (Diego Pardo) y de un votante de las pasadas elecciones en el mu-

nicipio (Benedicta Rincón) fue:

Preguntas Diego Pardo Benedicta Rincón

¿Es fácil aprender a operar el nuevo sistema? 5 5

¿Es fácil acceder al sistema para hacer lo que deseo? 4 4

¿Es fácil aumentar mi experiencia gracias al uso del

nuevo sistema?

5 5

¿El nuevo sistema es fácil de utilizar? 5 5

¿Sería fácil llegar a ser un experto en el manejo del

sistema

4 4

¿Usar el nuevo sistema es una buena idea? 4 4

¿Usar el nuevo sistema es una inteligente idea? 4 4

¿Me gusta la idea de usar el nuevo sistema? 4 4

¿Usar el nuevo sistema me parece (placentero/no-

placentero)?

3 3

Tabla 23. Resultados ciudadanos TAM

Las validaciones realizadas para toda la arquitectura nos llevan a deducir que aunque esta

propuesta de voto electrónica dentro de esquemas complejos o mundiales sea una fase inicial

o de estudios guías, se presenta como el camino o pauta para poder implementar una solución

tecnológica manteniendo la coherencia de la solución con el problema desde donde se origi-

na, ya que en Colombia, no se ha presentado modelo de arquitectura similar (solo pilotos


Página 60

sobre aplicaciones). Factores como la comprensión de la realidad colombiana y de su ente

gestor de las elecciones, así como la presentación de un prototipo y un nivel de aceptación

aceptable del mismo por parte de los futuros usuarios permite entender que este proyecto sea

visto una vía de innovación real no muy lejana para Colombia.

VI - CONCLUSIONES

El hecho de presentar una propuesta que integre no solo la forma de implementar el voto sino

su relación con el entorno organizacional que lo controla es nueva desde cualquier perspecti-

va de ingeniería, así como para Colombia, ya que no se ha presentado modelo de arquitectura

similar como se apreció durante el estudio del estado del arte del voto electrónico mundial y

en Colombia.

De forma general, se puede apreciar que el desarrollo de esta arquitectura de sistema permite

ser una guía de los procesos y de la forma de dar soporte, a nivel tecnológico y organizacio-

nal, al dinamismo propio de la registraduría municipal de Choachí y nacional, permitiendo

identificar claramente cómo funcionan sus procesos, la dependencia de sus actividades y

presentando una solución que incluye, por una parte nueva tecnología y por otra, identificar y

mejorar las aplicaciones y/o soluciones tecnologías que ya se tenga para la mejora y agilidad

de ciertos procesos relacionados a la línea estratégica del voto. El hecho de desarrollar una

arquitectura de sistema como solución integrada fortalece la propuesta de votación electróni-

ca, porque permite mantener coherencia entre la realidad del voto y una solución propuesta

que ya se empieza a ver como una prioridad, como lo manifestó el Registrador Nacional Car-

los Ariel Sánchez Torres después de las elecciones del día 30 de octubre donde expreso que

la implementación del voto electrónico en Colombia debe ser gradual, como se hizo en Bra-

sil, en donde comenzó su utilización en algunas elecciones de tipo local y fue expandiéndose

paulatinamente [72].

Igualmente, La comunidad a la que aplica el proyecto contaría con una herramienta que per-

mitiría disminuir el ausentismo electoral y brindaría en un futuro mayor cobertura a los dis-

capacitados, debido a las facilidades que este modelo otorgaría remplazando los antiguos

tarjetones electorales.

A nivel de detalle, esta arquitectura empresarial permitirá a la registraduría municipal de

Choachí ser dinámica con el paso del tiempo, ya que en la actualidad no se había realizado

ningún tipo de metodología para reconocer los procesos, actores y elementos que hacen parte

de la línea estratégica de votación. Al mismo tiempo, permitirá realizar modificaciones en sus

procesos sin sufrir grandes traumas, debido a que la arquitectura empresarial da la ventaja de

reconocer fácilmente los procesos y evitar colapsar toda una línea estratégica. Asimismo, esta

arquitectura facilita generar puntos de medición o indicadores sobre actividades, tareas o

procesos para permitir llevar un control de la organización y su evolución mediante análisis

cuantitativos, análisis de brechas entre otras formas de medición, factor que actualmente no


Página 61


se tiene debido a lo artesanal que es esta línea estratégica, elemento que no permitía tener

históricos de análisis en tiempo real como ningún control de proceso ni cuantitativo ni cuali-

tativo.

Basados en la validación semántica del experto, se puede apreciar que desde el punto de vista

del registrador se cumple con la identificación clara de los procesos y no se omite ninguno

dentro de la concepción de la solución tanto empresarial como previa del software. Esto per-

mite al lector entender que la viabilidad conceptual en la representación de la línea estratégica

del voto con esta arquitectura (el elemento empresarial) tiene un soporte adecuado para la

realidad colombiana, en este caso para la realidad de un municipio de categoría sexta como

Choachí.

Desde el punto de la validación sintáctica también podemos concluir que a pesar de que es

una primera muestra de cómo se puede realizar el voto electrónico en el municipio, cumple

con las condiciones necesarias para implementarse y poder ser evaluada a futuro como lo

manifiesta la validación que tuvo esta arquitectura según el modelo de madurez de arquitectu-

ras empresariales.

A nivel del detalle de la arquitectura de software, se puede concluir que el desarrollo del di-

seño propuesto permite dar solidez conceptual y estructural a la propuesta de Votación elec-

trónica y su futura implementación, ya que al plantear un desarrollo mediante un esquema

basado en patrones desde el inicio, se trabaja sobre unas estructuras que se plantearon para

dar solución a problemas precisos, además permite analizar y detectar problemas en otros

ámbitos que no cubran los patrones desde su diseño ahorrando los costos futuros de solución

si ya se ha implementado, debido a que se llegaría al punto específico del problema gracias a

la trazabilidad que permite este diseño.

Igualmente, el uso de servicios web como forma de implementación para la futura aplicación

es una ventaja para cualquier proceso electoral que se lleve a cabo en Choachí o en la nación,

ya que facilita que los puestos de votación sean desplazables y accesibles desde cualquier

lugar donde se tenga conexión a internet (alámbrica, inalámbrica, satelital o móvil). Además,

el hecho de implementarse de forma electrónica (empleado desde cualquier equipo de cómpu-

to designado por la registraduría municipal o nacional con unos requisitos mínimos) permite

aumentar la capacidad de auditoria de todo el proceso electoral, así como la seguridad, por-

que se implementarían controles sobre cada una de las acciones que se realicen sobre el sis-

tema como: control de acceso de usuarios gracias a la integración propuesta con el sistema

morphocheck, logs de inserción, modificación y borrado de datos, entre otros, elementos que

serán de respaldo en el momento de realizar cualquier jornada de votación electrónica.

Otra ventaja de usar servicios web como forma de implementación del voto electrónico es el

manejo de la información electoral, porque el uso de servicios web permite que la informa-

ción almacenada no este solamente en el equipo donde se realiza sino que se pueda almacenar

en un servidor externo físicamente del lugar de votación, garantizando la calidad de los votos

y rompiendo vulnerabilidades físicas, gracias a que la información no va a estar solo en un

lugar, factor que implícitamente mejora la seguridad y auditabilidad del proceso en cualquier

momento. Dentro del proceso de diseño de la propuesta software con Servicios Web, se es-


Página 62

cogió como lenguaje de programación Java, porque a la fecha es el lenguaje de programa-

ción en servicios web que mayor fortaleza a nivel de seguridad ofrece frente a Microsoft.

Además, el hecho de desarrollar e implementar Web services como parte de la arquitectura

propuesta tiene gran valor ya que es un paso importante para permitir la implementación de

una futura arquitectura orientada a servicios (SOA) [73] que permita la maximización y glo-

balización de la propuesta mediante la integración con las otras líneas estratégicas de la regis-

traduría. Esto se da porque los web services proveen un acercamiento a la computación dis-

tribuida para integrar aplicaciones extremadamente heterogéneas sobre internet ya que es

independiente del lenguaje de programación, sistema operativo y hardware.

Como complemento de esto, se plantea también el diseño del modelo de la base de datos ideal

para la propuesta de diseño de software presentada, dando coherencia a los conceptos mane-

jados en la arquitectura empresarial y empleando el conocimiento adquirido dentro del desa-

rrollo del proyecto para aumentar las fortalezas de la presente propuesta.

Al ser un proyecto de grado, la arquitectura de sistema se implementó como un prototipo de

interfaces de usuario, el cual para no perder la concepción de sistema se implementó usando

Bizagi para el modelado de los procesos integrándolo con web services y el respectivo mane-

jo de bases de datos. A pesar de ser solo un prototipo de interfaces de usuario su aceptación

por parte de los futuros usuarios fue más que aceptable como lo demuestra la validación

TAM realizada, lo que permite pensar que el camino recorrido con este proyecto no fue en

vano y que puede servir de pauta para nuevas propuestas que arranquen de cero como pro-

puestas que decidan mejorar el presente proyecto. Asimismo, este proyecto no representa

ningún compromiso de la Registraduría municipal con la sociedad y por tanto no tiene reper-

cusiones económicas. Dado el caso de implementarlo, las implicaciones que trae un proyecto

como este serían elevadas para el municipio si se aprueba de forma local y no nacional debi-

do a que la registraduría municipal correría con todos los gastos sobre el presupuesto asigna-

do, de allí que se tenga implicaciones fuertes en 3 aspectos: costos de adquisición, entrena-

miento y recursos.

Por ende, el modelo de arquitectura generado, si se llegara a implementar por la Registraduría

Nacional del Estado Civil o por la registraduría municipal, permitiría reducir el impacto am-

biental que producen las elecciones, al ahorrar en el consumo de papel para los tarjetones

electorales y reducir la cantidad de tinta utilizada en los mismos, además de la reducción en

los costos de transporte, fomentando un efecto positivo sobre el medio ambiente.

Analizando este modelo, así como entendiendo todas las pautas y políticas que con el paso

del tiempo se han presentado para que Colombia pueda tener voto electrónico, lo importante a

tener en cuenta es el impacto social que puede tener el mismo y que la forma en que se im-

plemente el voto electrónico no aumente la brecha digital que ya existe en Colombia pasando

a vulnerar el derecho a votar de cualquier ciudadano colombiano por ignorancia o rechazo a

la herramienta.


Página 63


VII – TRABAJO FUTURO

Como trabajo futuro se espera que basado en la arquitectura empresarial planteada se extien-

dan de las 7 vistas propuestas a las 14 vistas empresariales que trae Archimate para aumentar

la calidad del soporte conceptual. Además de eso, se espera que a quien le interese el tema

pueda seguir refinando el modelo de arquitectura empresarial de la registraduría y agregarle

procesos paralelos de otra línea de estrategia.

Desde el punto de vista de implementación (recordando que el artefacto construido fue un

prototipo de interfaces de usuario) se puede mejorar la asignación de usuarios y/o roles para

las cargas dentro de los procesos de la línea estratégica de votación, ya sea utilizando los

modelos BPMN generados en este proyecto y mejorándolos sobre Bizagi o utilizando los

modelos BPMN y mejorándolos sobre JBPMN.

También se puede plantear a nivel de arquitectura de software realizar el mapeo del diseño

actual de Java Web Services a Microsoft Web Services buscando identificar posibles mejoras

en seguridad desde el modelo en Microsoft, o confirmando la fortaleza del modelo en Java o

validándolo mediante una comparación directa con el modelo propuesto en este proyecto.

Asimismo, se espera integrar la parte de avales de los partidos políticos con la registraduría

municipal mediante el uso de servicios web para reducir los pocos aspectos físicos planteados

que pueden ser vulnerables de falsificación dentro del modelo propuesto.


Página 64

VIII – BIBLIOGRAFÍA

[1] CALTECH-MIT Voting Technology Project. “Voting: What is, what could be”. Massa-

chusetts Institute of Technology. USA. 2001.

[2] Rössler, T. “e-Voting A Survey and Introduction”. Secure Information Technology Center

- Austria.2005.

[3] Smith, E., Macintosh, A. “E-Voting: Powerful Symbol of e-Democracy”. ELECTRONIC

GOVERNMENT: Lecture Notes in Computer Science. Volume 2739. 2003.

[4] Busaniche, B., Heinz F., Rezinovskyt, A. “Voto electrónico: los riesgos de una ilusión”.

Fundación Vía Libre. 1ra edición. 2008.

[5] Chaum, D., Carback, R., Clark, J., Essex, A., Popoveniuc, S., Rivest, R., Ryan, P., Shen,

E., Sherman, A. “Scantegrity II: End-to-End Verifiability for Optical Scan Election Systems

using Invisible Ink Confirmation Codes”. EVT'08 Proceedings of the conference on Electron-

ic voting technology. USENIX Association Berkeley. USA. 2008.

[6] Davis III, J., Thomas, S. “Direct recording electronic voting machine and voting pro-

cess”. Election Products, Inc., ILT Corp. USA. 2001. Disponible en:

http://www.freepatentsonline.com/5583329.html.

[7] Kiayias, A., Korman, M., Walluck, D. “An Internet Voting System Supporting User Pri-

vacy”. in Proc. of the 22nd Annual Computer Security Applications Conference (ACSAC

'06). Pp: 165-174. 2006.

[8] Ministerio de Tecnologías de la Información y las Comunicaciones. “Manual para la

implementación de la Estrategia de Gobierno en línea”. Reglamentado mediante el Decreto

1151. 2008.

[9] Alvarez, R.M., Katz, G., Llamosa, R., Martinez, H.E. “Assessing voters' attitudes towards

electronic voting in latin america: Evidence from Colombia's 2007 E-voting pilot”. Lecture

Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and

Lecture Notes in Bioinformatics) 5767 LNCS. Pp: 75-91. 2009

[10] Periódico El Tiempo. “Implementarán plan piloto de voto electrónico en elecciones en

Bolívar”. Artículo. 2010. Disponible en:

http://www.eltiempo.com/colombia/cartagena/ARTICULO-WEB-

NEW_NOTA_INTERIOR-8162702.html

[11] Alonso, L. "Aspectos tecnológicos del voto electrónico". Documento de trabajo #17.

ONPE. Lima. 2007.

[12] Fitrakis, B. “Diebold, Electronic Voting and the Vast Right-Wing Conspiracy”. Free

Press. USA. 2004. Disponible en: http://www.commondreams.org/views04/0225-05.htm.


Página 65


[13] Lockyer, B. “CA Sues Diebold For E-Vote Machine False Claims”. San Francisco

Reuters. 2004. Disponible en: http://www.rense.com/general57/machine.htm.

[14] Lemos, R. “Diebold voting systems critically flawed”. SecurityFocus. 2006. Disponible

en: http://www.securityfocus.com/news/11391.

[15] Clements, P., Bachmann, F., Bass, L., Garlan, D., Ivers, J., Little, R., Merson, P., Nord,

R., Stafford, J. “Documenting Software Architectures: Views and Beyond”. Second Edition.

Boston: Addison-Wesley. 2010.

[16] Weill, P. “Innovating with information systems: what do the most agile firms in the

world do?”. Sixth e-Business Conference – MIT Sloan School of Management. Spain. 2007.

[17] Oostveen, A., Van den Besselaar, P. “Internet voting technologies and civic participa-

tion, the users perspective”. Javnost / The Public. Vol. XI, No.1. Pp: 61-78. 2004

[18] Rössler, T. “e-Voting A Survey and Introduction”. Secure Information Technology Cen-

ter - Austria. 2004.

[19] Duong, D., Nguyen, P., Pham, J., Wheeler, T. “eVoting Survey Analysis”. Portland State

University. 2004.

[20] Clowers, J. “I E-vote, U I-vote, Why Can’t We All Just Vote?!: A Survey of the Changing

Face of the American Election”. Gonzaga Law Review - HeinOnline. 2006

[21] Smith, E., Macintosh, A. “E-Voting: Powerful Symbol of e-Democracy”.

ELECTRONIC GOVERNMENT: Lecture Notes in Computer Science. Volume 2739. 2009

[22] CALTECH-MIT Voting Technology Project. “Voting: What is, what could be”. Massa-

chusetts Institute of Technology. USA. 2001.

[23]Encyclopædia Britannica. "Electronic voting". Encyclopædia Britannica Online.

EncyclopædiaBritannica. 2011. Disponible en:

http://www.britannica.com/EBchecked/topic/1472946/electronic-voting

[24] Red de Conocimiento Electoral ACE. “Definición e-voting”. 2011. Disponible en:

http://aceproject.org/ace-es/focus/fo_e-voting/fo_e-voting-what-is-e-voting

[25] Busaniche, B., Heinz F., Rezinovskyt, A. “Voto electrónico: los riesgos de una ilusión”.

Fundación Vía Libre, 1ra edición. 2008.

[26] Rial, J. “Definición del voto electrónico (4.)”. Observatorio Electoral Latinoamericano.

2011. Disponible en: http://www.observatorioelectoral.org/biblioteca/?bookID=26&page=1

[27] Red de Conocimiento Electoral. “Modelos de Sistemas de Votación Computarizados”.

2011. Disponible en: http://aceproject.org/main/espanol/em/emf02.htm


Página 66

[28] Chaum, D., Carback, R., Clark, J., Essex, A., Popoveniuc, S., Rivest, R., Ryan, P., Shen,

E., Sherman, A. “Scantegrity II: End-to-End Verifiability for Optical Scan Election Systems

using Invisible Ink Confirmation Codes”. EVT'08 Proceedings of the conference on Electron-

ic voting technology. USENIX Association Berkeley. USA. 2008

[29] Davis III, J., Thomas, S. “Direct recording electronic voting machine and voting pro-

cess”. Election Products, Inc., ILT Corp. USA. 2002. Disponible en

http://www.freepatentsonline.com/5583329.html.

[30] Kiayias, A., Korman, M., Walluck, D. “An Internet Voting System Supporting User Pri-

vacy”. In Proc. of the 22nd Annual Computer Security Applications Conference (ACSAC

'06). Pp: 165-174. 2006.

[31] Gloversure. “Gloversure: sms voting, sms Vote”. 2010. Disponible en:

http://www.gloversure.co.uk/sms_vote.html

[32] Joaquim, R., Zúquete, A., Ferreira, P. “REVS – A Robust Electronic Voting System”.

IADIS International Journal of WWW/Internet. Volume 1. Issue: 2. 2003.

[33] Xenakis, A., Macintosh, A. “Procedural Security in Electronic Voting”. Proceedings of

the 37th Hawaii International Conference on System Sciences. 2004

[34] Wikipedia. “Definición de Interactive Voice Response”. Wikipedia. 2011. Disponible

en: http://es.wikipedia.org/wiki/Interactive_Voice_Response

[35] Mercuri, R. “A better ballot box?”. Spectrum, IEEE. Volume: 39 Issue:10. Pp:46 – 50.

2002. ISSN: 0018-9235

[36] Mercuri, R. “Facts About Voter Verified Paper Ballots”. Voter Verified Paper allots --

An Informational Brochure. 2011. Disponible en:

http://www.notablesoftware.com/evote.html

[37] Goggin, S., Byrne, M. “An Examination of the Auditability of Voter Verified Paper Audit

Trail (VVPAT) Ballots”. USENIX/ACURATE Electronic Voting Tecnhology Workshop

2007.

[38] Hevner, A., March, S., Park, J., Ram, S. “Design Science in Information Systems Re-

search”. MIS Quarterly. Volume 28. Issue :1. Pp. 75-105. 2004.

[39] Golden, B. "What is systems Architecture?". Article for Complex Systems Design &

Management. 2010. Disponible en:

http://www.lix.polytechnique.fr/~golden/systems_architecture.html

[40] The Open Group Archimate. “Archimate 1.0 Technical standard specification”. The

Open Group. 2009. Disponible en: http://www.opengroup.org/archimate/doc/ts_archimate/

http://www.opengroup.org/archimate/doc/ts_archimate/


Página 67


[41] Institute of Electrical and Electronics Engineers. “1471-2000 – IEEE Recommended

Practice for Architectural Description for Software-Intensive Sysyems”. IEEE Standards

Association. 2000. Disponible en: http://standards.ieee.org/findstds/standard/1471-2000.html

[42] Ministerio de Tecnologías de la Información y las Comunicaciones. “GEL-XML: Len-

guaje estándar de intercambio de información: notas explicativas a la arquitectura de da-

tos”. República de Colombia. 2009. Disponible en:

http://programa.gobiernoenlinea.gov.co/apc-aa-

fi-

les/5854534aee4eee4102f0bd5ca294791f/GEL_MV_RG_002_Notas_Arquitectura_Datos_V

5.2.pdf

[43] Harmon, P. “Business Process Methodologies”. BPTrends - Business Process Trends.

Volumen 5. Number 20. 2007

[44] Forster, F. “The Idea behind Business Process Improvement: Toward a Business Process

Improvement Pattern Framework”. BPTrends – Business Process Trends. 2006

[45] Kim, D., Kim, M., Kim, H. “Dynamic Business Process Management based on Process

Change Patterns”. International Conference on Convergence Information Technology. Pp:

1154 – 1161. 2007.

[46] Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., Stal, M. “Pattern-Oriented

Software Architecture Volume 1: a system of patterns”. Wiley. Vol 1. Pp: 31. 1996

[47] United States Government. “US treasury architecture development guidance (TADG)”.

Sección 7. 2002. Disponible en: http://www.ustreas.gov/teaf/tadg.pdf.

[48] Monday, P. “Web Services Patterns: Java Edition”. Apress. 1 Edition. 2003

[49] Lawrence Pfleeger, S. “Software Engineering Theory and practice”. Beohm McCall

ISO Model. Prentice Hall. 2001.

[50] Boehm, B.W., Brown, J.R., Lipow, M. “Quantitative evaluation of software quality”.

International Conference on Software Engineering, Proceedings of the 2nd international con-

ference on Software engineering (2nd). Pp: 592-605. 1976.

[51] Grady, R., Caswell, D. “Software Metrics: Establishing a Company-wide Program”.

Prentice Hall. Pp: 159. 1987. ISBN 0138218447.

[52] ISO/IEC 9126-1. “Software engineering – product quality – Part 1: Quality Model”.

First edition. 2001.

[53] Dromey, R.G. “A model for software product quality”. IEEE Transactions on Software

Engineering 21. Volumen 2. 1995.

http://standards.ieee.org/findstds/standard/1471-2000.html

http://programa.gobiernoenlinea.gov.co/apc-aa-files/5854534aee4eee4102f0bd5ca294791f/GEL_MV_RG_002_Notas_Arquitectura_Datos_V5.2.pdf





Página 68

[54] Fitzpatrick, R. “Software quality definitions and strategic issues”. Staffordshire Univer-

sity. 1996.

[55] Neil, M., Fenton, N. “Predicting software quality using bayesian belief networks”.

NASA/Goddard Space Flight Centre. 1996.

[56] Khosravi, K., Gueheneuc, Y.G. “A Quality Model for Design Patterns”. Technical Re-

port 1249. University of Montreal. 2004.

[57] Gamma, E., Helm, R., Johnson, R., Vlissides, J. “Design Patterns Elements of Reusable

Object-Oriented Software”. Addison-Wesley Pub Co. 1995

[58] Nagappan, R., Skoczylas, R., Sriganesh, R.P. “Developing Java Web Service: Architect-

ing and developing secure web services using java”. Wiley Publishing. ISBN 0-471-23640-3.

2003.

[59] Lakshminarayanan, S. “Oracle Web Services Manager: securing your web services”.

Packt publishing. First published. 2008. ISBN 978-1-847193-83-4.

[60] EURACHEM. “The Fitness for Purpose of Analytical Methods: A Laboratory Guide to

Method Validation and Related Topics”. EURACHEM Guide. 1998. Disponible en:

http://www.eurachem.ul.pt/

[61] Sistemas de gestión de la calidad. “Principios y vocabulario”. NMX-CC-9000-IMNC-

2001. 2001

[62] Gonzalez, Rafael A. "Validation of Crisis Response Simulation within the Design Sci-

ence Framework". ICIS 2009 Proceedings. Paper 87. 2009. Disponible en:

http://aisel.aisnet.org/icis2009/87

[63] Sistemas de gestión de la calidad. “Requisitos”. NMX-CC-9001-IMNC-2001. 2001

[64] Majewski, M., Han, Q., Wurster, A. “Business Process Validation”. University of

Augsburg. 2009

[65] Khatri, V., Vessey, I., Ramesh, V., Clay, P., Park, S. “Understanding conceptual sche-

mas: exploring the role of application and IS Domain knowledge”. Information Systems

Research. Vol. 17, Number 1. Pp: 81-99. 2006.

[66] Weber, I., Hoffmann, J., Mendling, J. “Semantic Business Process Validation”. In Proc.

of International workshop on Semantic Business Process Management. 2008.

[67] Clements, P., Kazman, R., Klein, M. “Evaluating software Architectures: methods and

case studies”. Addison-Wesley Professional. 1st edition. 2001.

[68] Clements, P., Kazman, R., Klein, M. “ATAM: Method for architecture evaluation –

Technical Report”. Technical Report . CMU/SEI-2000-TR-004. 2000.


Página 69


[69] Davis, F.D. “User acceptance of information technology: system characteristics, user

perceptions and behavioural impacts”. International Journal of Man-Machine Studies. Vol-

ume 38. Pp: 475-487. 1993

[70] Davis, F.; Bagozzi, R.; and Warshaw, R. “User Acceptance of Computer Technology: A

Comparison of Two Theoretical Models”. Management Science. Volume 35. Pp: 982-1003.

1989

[71] Orantes Jiménez, S.D. “Viabilidad del Modelo de Aceptación de la Tecnología en las

empresas mexicanas. Una aproximación a las actitudes y percepciones de los usuarios de las

tecnologías de la información”. Revista Digital Universitaria. Volumen 12. Número 1. 2011.

ISSN: 1067-6079

[72] Sánchez Torres, C. “Registraduría está lista para el voto electrónico, pero han faltado

recursos”. Revista Electrónica Nuestra Huella Digital. Edición No. 57. Año V. 2011. Dispo-

nible en:

http://www.registraduria.gov.co/rev_electro/2011/rev_elec_nov/revista_nov2011.html#06

[73] Endrei, M., Ang, J., Arsanjani, A., Chua, S., Comte, P., Krogdahl, P., Luo, M., Newling,

T. "Patterns: Service-oriented architecture and web services". IBM. International Technical

support organization. 2004

IX – ANEXOS

1. Anexo A


Página 70

Figura 21. Vista introductoria parte A.


Página 71


Figura 22. Vista introductoria parte B


Página 72

Figura 23. Vista introductoria parte C


Página 73


Figura 24. Vista de la organización


Página 74

Figura 25. Vista de co-operación de actor


Página 75


Figura 26. Vista del proceso de negocio parte A


Página 76

Figura 27. Vista del proceso de negocio parte B


Página 77


Figura 28. Vista del proceso de negocio parte C


Página 78

Figura 29. Vista de co-operación del proceso de negocio parte A


Página 79


Figura 30. Vista de co-operación del proceso de negocio parte B


Página 80

Figura 31. Vista de co-operación del proceso de negocio parte C


Página 81


Figura 32. Vista de co-operación del proceso de negocio parte D


Página 82

Figura 33. Vista del comportamiento de la aplicación parte A


Página 83


Figura 34. Vista del comportamiento de la aplicación parte B


Página 84

Figura 35. Vista del comportamiento de la aplicación parte C


Página 85


Figura 36. Vista del comportamiento de la aplicación parte D


Página 86

Figura 37. Vista de infraestructura


Página 87


Figura 38. Estado actual de la registraduría municipal de Choachí para el voto


Página 88

Figura 39. Estado ideal de la registraduría municipal de Choachí para el voto electrónico


Página 89


2. Anexo B

CAPA DEL CLIENTE

Decorating Filter

/ Intercepting

Filter

Un objeto que está entre el cliente y los componentes Web. Este procesa

las peticiones y las respuestas.

CAPA DE PRESENTACION

Front Controller/

Front Component

Un objeto que acepta todos los requerimientos de un cliente y los direc-

ciona a manejadores apropiados. El patrón Front Controller podría divi-

dir la funcionalidad en 2 diferentes objetos: el Front Controller y el Dis-

patcher. En ese caso, El Front Controller acepta todos los requerimientos

de un cliente y realiza la autenticación, y el Dispatcher direcciona los

requerimientos a manejadores apropiada.

Service To Wor-

ker

Es como el patrón de diseño MVC con el Controlador actuando como

Front Controller pero con una cosa importante: aquí el Dispatcher (el

cual es parte del Front Controller) usa View Helpers a gran escala y ayu-

da en el manejo de la vista.

Dispatcher View Es como el patrón de diseño MVC con el controlador actuando como

Front Controller pero con un asunto importante: aquí el Dispatcher (el

cual es parte del Front Controller) no usa View Helpers y realiza muy

poco trabajo en el manejo de la vista. El manejo de la vista es manejado

por los mismos componentes de la Vista.

CAPA DE NEGOCIO

Business Delega-

te

Un objeto que reside en la capa de presentación y en beneficio de los

otros componentes de la capa de presentación llama a métodos remotos

en los objetos de la capa de negocios.

Value List Han-

dler/ Page-by-

Page Iterator/

Paged List

Es un objeto que maneja la ejecución de consultas SQL, caché y proce-

samiento del resultado. Usualmente implementado como beans de se-

sión.

Service Locator Consiste en utilizar un objeto Service Locutor para abstraer toda la utili-

zación JNDI y para ocultar las complejidades de la creación del contexto

inicial, de búsqueda de objetos home EJB y recreación de objetos EJB.

Varios clientes pueden reutilizar el objeto Service Locutor para reducir

la complejidad del código, proporcionando un punto de control.

CAPA DE PERSISTENCIA

Service Activator Se utiliza para recibir peticiones y mensajes asíncronos de los clientes.

Cuando se recibe un mensaje, el Service Activator localiza e invoca a los

métodos de los componentes de negocio necesarios para cumplir la peti-

ción de forma asíncrona.


Página 90

Value Object/

Data Transfer

Object/ Replicate

Object

Un objeto serializable para la transferencia de datos sobre la red.

Aggregate Entity

/ composite entity

Un bean entidad que es construido o es agregado a otros beans de enti-

dad.

Tabla 24. Descripción de los patrones de Web Services

3. Anexo C

Entidad Elector

Num_cedula (PK) Integer

Nombres Varchar(50)

Apellidos Varchar(50)

Lugar_exp_ced Varchar(50)

Direccion_residencia Varchar(50)

Teléfono Integer

Es_jurado Boolean (1)

Tabla 25. Elector

Entidad Inicio_Proceso_electoral

Fecha_inicio Date

Hora_inicio Time

Num_proc_elec (PF) Integer

Tabla 27. Inicio proceso Electoral

Entidad Cierre_Proceso_electoral

Fecha_cierre Date

Hora_cierre Time


Tabla 26. Cierre proceso electoral


Página 91


Entidad Proceso_electoral

Nombre_proc_elec Varchar(50)

Num_proc_elec (PK) Integer

Tabla 28. Proceso electoral

Entidad Municipio

Cod_mpio (PK) Integer

Nom_mpio Varchar (50)

Cod_dpto (PF) Integer

Num_hab Integer

Tabla 29. Municipio

Entidad Inscripcion_elector

Num_form_insc_elector (PK) Integer

Ultimo_lugar_votacion Varchar (50)

Num_cedula (F) Integer

Cod_mpio (PF) Integer


Entidad Departamento

Cod_dpto (PK) Integer

Nombre_dpto Varchar (50)

Prom_votantes NUMERIC (9,2)

Pot_elect Integer

Region Varchar(50)

Tabla 30. Departamento


Página 92


Num_proc_elec1 (PF) Integer

Tabla 31. Inscripción elector

Entidad Inscripcion_candidato

Num_form_insc_candidato (PK) Integer

Certificado_residencia_notarial Boolean (1)


Cod_mpio (PF) Integer



Num_proc_elec1 (PF) Integer

Id_cargo (PF) Integer

Ultimo_lugar_votacion Varchar (50)

Num_aval (PF) Integer

Tabla 32. Inscripción candidato

Entidad Cargo_Candidato

Id_cargo Integer

Nombre_cargo Varchar (50)

Tabla 33. Cargo candidato

Entidad Aval

Fecha_aval Date

Hora_aval Time

Num_tipo (FK) Integer

Num_aval (PK) Integer

Num_partido (FK) Integer

Tabla 34. Aval


Página 93


Entidad Partido_politico

Num_partido Integer

Nombre_partido Varchar (50)

Tabla 35. Partido político

4. Anexo D

Entidad Puesto

Cod_pto (PK) Integer

Nombre_pto NVarchar

Cod_mpio1 (PF) Integer

Cod_dpto1 (PF) Integer

Zona Integer

Tabla 37. Puesto

Entidad Mesa

Num_mesa (PK) Integer

Pot_votantes Integer

Cod_pto1 (PF) Integer



Tabla 38. Mesa

Entidad Tipo_Aval

Num_tipo Integer

Nombre_aval Varchar (50)

Tabla 36. Tipo Aval


Página 94

Entidad Boletín

Numero_boletin (PK) Integer

Hora Time

Fecha Date

Num_mesa (PF) Integer




Mesa_informadas Integer

Id_corporacion (F) Integer

Tabla 39. Boletín

Entidad Cargo_jurado

Id_cargo (PK) Integer

Nombre_cargo Varchar (50)

Tabla 40. Cargo jurado

Entidad Jurado

Material Varchar

Hora_entrada Time

Hora salida time

Id_cargo (PF) Integer

Fecha Date

Tabla 41. Jurado

Entidad Participantes

Cedula (PK) Integer

Nombre Varchar(50)

Num_participante Integer

Tabla 42. Participantes


Página 95


Entidad Otro_tipo

Id_otrotipo (PK) Integer

Nombre_puesto Varchar(50)

Tabla 43. Otro tipo

La entidad inscrip se crea como una copia de la entidad inscripción_elector solo que no con la

totalidad de los atributos.

Entidad Inscrip






Num_form_insc_elector (PK) Integer

Tabla 44. Inscrip

La entidad Inscripcion_candidato del modelo de votación es la misma entidad inscrip-

cion_candidato del modelo de inscripción, solo que no se dibujó con sus respectivas conexio-

nes para facilidad de entendimiento.

Entidad Candidato

Num_candidato (PK) Integer

Cod_partido (PF) Integer

Num_form_insc_candidato (F) Integer

Cod_mpio (F) Integer

Cod_dpto (F) Integer

Id_cargo (F) Integer

Num_aval (F) Integer

Tabla 45. Candidato

La entidad partido se duplica ya que en el momento de la jornada de votación pueden haberse

realizado alianzas que no estaban cuando se realizó la inscripción pero que posteriormente se

efectuaron bajo coordinación de la registraduría en su sede central (Bogotá).


Página 96

Entidad Partido

Cod_partido (PK) Integer

Nombre partido Varchar (50)

Tabla 46. Partido

Entidad Candidato_consulta

Cod_candidato_con (PK) Integer

Tabla 47. Candidato consulta

Entidad Voto_alcaldia


Num_candidato (PF) Integer

Tabla 48. Voto alcaldía

Entidad Voto_Concejo


Num_candidato (PF) Integer

Tabla 49. Voto concejo

Entidad Voto_consulta

Cod_candidato_con (PF) Integer

Tabla 50. Voto consulta

Entidad Voto

Num_voto (PK) Integer

Voto_blanco Boolean (1)



Página 97





Id_corporacion (PF) Integer

Fecha Date

hora Time

Tabla 51. Voto

La tabla Corporación se crea para poder facilitar la consulta de boletines. El término de cor-

poración se da para los cargos a escoger que hallan: presidencia, referendos, consultas parti-

distas, alcaldía, concejo, gobernación, asamblea, cámara y senado.

Entidad Corporacion

Id_corporacion (PK) Integer

Tipo_corporacion Varchar (50)

Tabla 52. Corporación


Página 98

5. Anexo E

Figura 40. Modelo BPMN del proceso electoral


Página 99


Figura 41. Modelo BPMN del subproceso de inscripción


Página 100

Figura 42. Modelo BPMN del subproceso de inscripción de candidatos


Página 101


Figura 43. Modelo BPMN del subproceso de inscripción de electores


Página 102

Figura 44. Modelo BPMN del subproceso de votación


Página 103


Figura 45. Modelo BPMN del subproceso de votación para alcaldía


Página 104

Figura 46. Modelo BPMN del subproceso de votación para concejo


Página 105


6. Anexo F

Validación Sintáctica realizada por el Ing. José C. Niño

Buenos días Daniel,

Primero que todo, es necesario entender que los modelos de madurez de arquitectura Empre-

sarial evalúan el nivel de capacidad que tiene una organización, para controlar y gerenciar

proyectos de este tipo.

Por esta razón muchos de los elementos de un modelo de madurez se pueden evaluar sola-

mente cuando el proyecto se encuentra en desarrollo o implementación.

En el modelo de madurez que propone el Carnegie-Mellon, el estado actual de su proyecto

puede evaluarse contra los parámetros del nivel 1 de Arquitectura Empresarial, el cual se

llama Estado inicial.

Dentro de este nivel, Se evalúan:

Arquitectura Empresarial:

Se debe garantizar que las definiciones se encuentren acordadas: Dentro del documento las

definiciones se encuentran especificadas y claramente documentadas, generalmente las defi-

niciones de los elementos las realizan los líderes funcionales.

Repositorio de Arquitectura Empresarial:

En este nivel puede que solamente el equipo de Arquitectura Empresarial tenga acceso al

Repositorio, siempre y cuando le brinde información al proyecto: Dentro del documento se

muestra claramente la notación y los puntos de vista (Archimate), los cuales especificaron

como insumo para el desarrollo de las aplicaciones.

Proceso de desarrollo de Arquitectura Empresarial:

En este nivel es suficiente con que el proceso sea utilizado por el equipo de Arquitectura

Empresarial: Dentro del documento se especifica que el proceso de desarrollo se Arquitectu-

ra se realizará utilizando la metodología ADM y el Framework TOGAF.

Objetivo de la Arquitectura Empresarial:

En este nivel se deben tener claros los dominios de los servicios, los principios y tener un

grado de detalle general de los elementos de la arquitectura Empresarial: Dentro de los

puntos de vista que se elaboraron dentro del documento, se pueden observar los servicios

planteados a nivel negocio, aplicaciones e infraestructura necesarios para continuar con el

proceso de desarrollo de la Arquitectura.


Página 106

En conclusión, considero que la propuesta actual de proyecto de Arquitectura Empresarial

se encuentra en la etapa inicial y que es un buen insumo para el desarrollo del mismo.

Le recomiendo que haga énfasis en puntos de vista en los cuales pueda detallar un poco más

aspectos de seguridad de la solución y que el cálculo de los costos sea justificado por una

metodología que le permita tener más claros los valores esperados del proyecto (Especial-

mente para el desarrollo de las Aplicaciones).

Por otra parte, es necesario que el municipio o el líder del proyecto tenga en cuenta que

necesita un repositorio para el proyecto y herramientas que soporten TOGAF, Archimate y

los elementos de Arquitectura y diseño de Software necesarios para la Arquitectura, diseño,

desarrollo y mantenimiento de los elementos que definan (tanto Arquitectura empresarial,

como de Software).

Con respecto a su solicitud de dar una calificación a cada uno de los siguientes elementos,

considero que deben tener la siguiente nota:

Coherencia en los conceptos de arquitectura empresarial (5.0)

Los conceptos de Arquitectura expuestos en el documento concuerdan con los defini-

dos en los estándares internacionales.

Representación de los Procesos del voto de la registraduría municipal de Choachí

(5.0)

Aunque no conozco los procesos definidos por el municipio (El cual debe realizar la

validación), se encuentran correctamente diseñados y documentados desde el punto

de vista del lenguaje de notación.

Contenido (4.5)

Aunque desde el punto de vista de notación de las vistas y puntos de vista el docu-

mento es completo, creo que puede mejorarse con elementos de la metodología y del

Framework de Arquitectura Empresarial.

Calidad del documento.(4.8)

Aunque considero que le faltan algunos de los elementos relacionados en el numeral

anterior, la calidad del documento presentado es alta.

Cordialmente,

Ing. José Niño.


Página 107


7. Anexo G

Validación Semántica realizada por el Registrador municipal de Choachí, Dr. Jorge A.

Díaz

Ingeniero Daniel Yesid Cáceres Rincón:

Reciba Cordial Saludo.

Analizando el documento de arquitectura empresarial con respecto al funcionamiento y aná-

lisis de los procesos de la registraduría municipal para el voto, presento la validación solici-

tada en los parámetros asignados por el Ingeniero Daniel Cáceres:

Identificación y Representación de la registraduría municipal dentro del documento:

(4.8)

o El documento representa una situación futura de la registraduría municipal

manteniendo su misión y visión, sin vulnerar su identidad ni perder su esen-

cia con la propuesta enseñada.

Identificación y Representación de los Procesos del voto dentro del documento: (5.0)

o Dentro del contenido del documento se aprecia claramente los procesos ac-

tuales, los sugeridos y la función de los mismos propuestos por el ingeniero;

Manteniendo coherencia con lo que el ingeniero identifico como línea estra-

tégica del voto electrónico dentro de su propuesta.

Contenido del documento: (4.8)

o El contenido y tamaño del documento es adecuado para la explicación de la

propuesta de arquitectura empresarial desarrollada por el ingeniero Daniel

Cáceres

Calidad del documento: (5)

o El documento es coherente en todas sus descripciones sin llegar a ser dema-

siado extenso. La calidad desde el punto de vista gramatical y conceptual es

correcta.

Claridad del documento: (4.8)

o El documento de arquitectura empresarial presenta la descripción clara de

todos los elementos contenidos sin necesidad de recurrir a tecnicismos de di-

fícil comprensión para ubicar a cualquier lector que no sea solo del área de

ingeniería.

Atentamente,

Jorge Alberto Díaz Duque

Registrador Municipal del Estado Civil

Choachí, Cundinamarca


Página 108

8. Anexo H

Casos de uso Atributo de cali-

dad asociado al

requerimiento

inicial. El que

más prima

Proceso de

negocio que se

relaciona con

dicho requeri-

miento

Elementos de

arquitectura

que intervie-

nen en el

sistema.

Escenarios más

relevantes al

interior

Almacenar for-

mularios en DB


gistro candidato

Service Fac-

tory Pattern

Esc1: Al momen-

to de ingresar el

formulario otro

usuario desea

consultarlo y

modificarlo al

mismo tiempo

Esc2: En caso de

migrarse la DB a

la que acceden los

servicios

Almacenar regis-

tro candidatos en

DB


gistro candidato

Service Fac-

tory Pattern

Esc1: Al momen-

to de ingresar el

registro, otro

usuario desea

consultarlo y

modificarlo al

mismo tiempo

Esc2: Al momen-

to de ingresar el

registro, otro

usuario desea

consultarlo y

modificarlo al

mismo tiempo

Almacenar regis-

tro electores en

DB


gistro elector

Service Fac-

tory Pattern

Esc1: La creación

de un registro de

elector que ya

existe

Almacenar repor-

tes

Capacidad de ex-

pansión

Aplicación re-

sultado escruti-

nio

Business Pro-

cess

Esc1: Antes de

haber cerrado la

jornada de ins-

cripciones de

candidatos o de

electores, se re-


Página 109


quiere tener un

informe sobre los

registros efectua-

dos

Almacenar con-

teo preliminar

Capacidad de ex-

pansión

Aplicación re-

sultado escruti-

nio

Business Pro-

cess

Esc1: Antes de

haber cerrado la

jornada de vota-

ciones se requiere

tener un informe

sobre los votos

hasta ahora escru-

tados

Almacenar votos

del sistema

Simplicidad Aplicación vo-

tación

Business Pro-

cess

Esc1: Se da inicio

a la jornada de

votación y se

presenta un elec-

tor que no está

inscrito en el

municipio

Bajar Servicio

Jornada de Vota-

ción


tación

Business Pro-

cess

Esc1: Se presen-

tan altercados de

orden público en

el puesto de vota-

ción y se requiere

bajar los servicios

antes de la hora

estipulada

Bajar Servicio

Post-Elección

Tolerancia al error Aplicación re-

sultado escruti-

nio

Business Pro-

cess

Esc1: Alternados

de orden público

mientras se hace

el conteo de los

votos

Bajar servicio de

validación biomé-

trica y código de

barras


tación

Business Pro-

cess

Esc1: El sistema

SAGEM tiene

fallos o hay re-

portes de error del

sistema SAGEM

Cerrar Jornada

Post-Elección

Operatividad Aplicación re-

sultado escruti-

nio

Business Pro-

cess

Esc1: El servicio

jornada de vota-

ción fue abierto

después de su

cierre


Página 110

Cerrar Jornada de

Votación

Operatividad Aplicación vo-

tación

Business Pro-

cess

Esc1: Intento de

ingreso de datos a

la aplicación des-

pués de cerrada la

jornada

Cerrar Proceso

De Inscripciones

candidatos


gistro candidato

Service Fac-

tory Pattern

Esc1: Intento de

ingreso del nuevo

registro de candi-

dato después de

cerrar el proceso

CerrarProcesoDe

Inscripciones

electores


gistro elector

Service Fac-

tory Pattern

Esc1: Intento de

ingreso del nuevo

registro de elector

después de cerrar

el proceso

Crear DB de re-

portes

Modularidad Aplicación re-

sultado escruti-

nio

Business Pro-

cess

Esc1: Se necesita

una nueva base de

datos para una

nueva jornada

electoral.

Crear DB de vo-

tos

Modularidad Aplicación vo-

tación

Business Pro-

cess

Esc1: Se necesita

una nueva base de

datos para una

nueva jornada

electoral

Crear formulario

E-24/E-26

Usabilidad Aplicación re-

sultado escruti-

nio

Business Pro-

cess

Es1: Generar un

formulario de un

proceso no estipu-

lado

Crear una DB de

registro electores


gistro elector

Service Fac-

tory Pattern

Esc1: Intento de

copia de registro

de elector

Crear una DB de

registro candida-

tos


gistro candidato

Service Fac-

tory Pattern

Esc1: Un candi-

dato se va a regis-

trar como elector

en otro municipio

Generar certifica-

do electoral


sultado escruti-

nio

Business Pro-

cess

Esc1: Un usuario

que se inscribió

pero no votó re-

clame el certifi-

cado electoral


Página 111


Generar certifica-

do inscripción

alcaldía


sultado escruti-

nio

Business Pro-

cess

Esc1: Un elector

que se inscribió

reclama el certifi-

cado de inscrip-

ción alcalde

Generar certifica-

do inscripción

concejo


sultado escruti-

nio

Business Pro-

cess

Esc1: Un elector

que se inscribió

reclama el certifi-

cado de inscrip-

ción concejo

Generar certifica-

do inscripción

electoral


sultado escruti-

nio

Business Pro-

cess

Esc1: Un elector

que no se inscri-

bió reclama el

certificado de

inscripción elec-

toral

Habilitar acceso a

la interface de

votación


tación

Business Pro-

cess

Esc1: Un usuario

no registrado

intenta acceder a

la interface de

votación de forma

remota

Iniciar proceso

Inscripciones

candidatos

Usabilidad Aplicación Re-

gistro candidato

Service Fac-

tory Pattern

Esc1: Se realiza

la inscripción de

un candidato,

pero la registradu-

ría que la inscrip-

ción de electores

aún no había ini-

ciado

Iniciar Proceso

Inscripciones

Electores

Usabilidad Aplicación Re-

gistro elector

Service Fac-

tory Pattern

Esc1: Un candi-

dato desea ser

registrado con sus

datos de elector

Iniciar Jornada de

Votación


tación

Business Pro-

cess

Esc1: Se intenta

iniciar la jornada

de votación sin

haber cerrado el

proceso de regis-

tro de candidatos

y registro de elec-

tores


Página 112

Iniciar Servicio

Jornada Votación


tación

Business Pro-

cess

Esc1: Se intenta

acceder al servi-

cio web de jorna-

da de votación sin

haber iniciado el

proceso jornada

votación

Iniciar Jornada

Post-Elección


sultado escruti-

nio

Business Pro-

cess

Esc1: Se intenta

iniciar la jornada

post-elección sin

haber cerrado la

jornada de vota-

ción

Iniciar Servicio

Jornada Post-

Elección


sultado escruti-

nio

Business Pro-

cess

Esc1: Se intenta

acceder al servi-

cio web de jorna-

da post-elección

sin haber iniciado

el proceso jornada

post-elección

Iniciar servicio de

validación biomé-

trica y de código

de barras


tación

Business Pro-

cess

Esc1: Se intenta

registrar un elec-

tor sin validar su

identidad

Monitorear el

sistema de vota-

ción


tación

Business Pro-

cess

Esc1: Hay un

puesto de vota-

ción que está

fallando.

Validar el elector

en jornada de

votación

Generalidad Aplicación Re-

gistro elector

Service Fac-

tory Pattern

Esc1: Se presenta

un elector con

una cedula falsa y

pretende votar

Validar mediante

lector biométrico

y de código de

barras en jornada

de inscripción

Formación Aplicación vo-

tación

Service Fac-

tory Pattern

Esc1: Se presenta

un elector con

una cedula falsa y

pretende inscri-

birse.

Tabla 53. Casos de Uso y atributos de calidad para validación ATAM


Página 113



Caso de uso Almacenar formularios en DB

Lo que permite

el patrón




Cuando el tiempo para una transición

llega usted podría configurar la factoría

para localizar el nuevo sistema de persis-

tencia de los datos

Situaciones

Excepcionales


formulario otro usuario desea


mismo tiempo

En caso de migrarse la DB a la que acce-

den los servicios

Justificación Las diferencias en los servicios

de consulta y de modificación

pueden ser mitigadas mediante

el patrón mediator

Lo formularios acceden a una factoría

que permite localizar el nuevo sistema de

persistencia de datos

Resultado Tanto las consultas como las

modificaciones pueden ser

realizadas desde dos usuarios

diferentes

El sistema se libera de tener dependencia

con respecto a la localización de la base

de datos y esto permite agilidad en futu-

ras migraciones de los sistemas de per-

sistencia

Tabla 54. Patrón Service Factory - CU Almacenar formularios en DB


Caso de uso Almacenar Registro candidatos

Lo que permite




Implica que se deben mantener estánda-

res para permitir el desarrollo de interfa-

ces propias como para los clientes

Situaciones

Excepcionales


registro, otro usuario desea


mismo tiempo

Al momento de ingresar el registro, otro

usuario desea consultarlo y modificarlo

al mismo tiempo

Justificación

Las diferencias en acceso y

modificación pueden ser miti-

gadas mediante el patrón me-

diator

Mediante interfaces se puede independi-

zar el acceso a la consulta del registro y a

la modificación


Página 114

Resultado

Tanto el acceso como las modi-

ficaciones pueden ser realizadas

desde dos usuarios diferentes

No restringe el rendimiento de un servi-

cio cuando acceda ya sea para consulta o

modificación

Tabla 55. Patrón Service Factory - CU Almacenar registro candidatos


Caso de uso Almacenar Registro Electores

Lo que permite Se podria usar para relacionar objetos de negocio con colecciones de obje-

tos

Situaciones

Excepcionales

La creación de un registro de elector que ya existe

Justificación El Service Factory permite establecer relaciones directas con la colección

de objetos creados previamente evitando crear redundancias en la capa de

persistencia

Resultado La aplicación del Service Factory permite bajos niveles de redundancia en

los registros de la base de datos

Tabla 56. Patrón Service Factory - CU Almacenar registro electores

Patrón Business Process (Composition) Pattern

Caso de uso Almacenar Conteo Preliminar

Lo que permite Tiene un tipo de modelo proxy para conectar las representaciones de datos a

través de una red y para acceder a los datos el cliente del web service debe

recrear el modelo de objeto en el servidor en su propio lenguaje

Situaciones

Excepcionales

Antes de haber cerrado la jornada de votaciones se requiere tener un infor-

me sobre los votos hasta ahora escrutados

Justificación Los clientes haciendo uso de las capacidades del patrón pueden generar

copias del modelo de objetos del servidor

Resultado Se pueden obtener copias temporales aprovechando el uso del patrón

Tabla 57. Patrón Business Process (Composition) - CU Almacenar conteo preliminar


Caso de uso Almacenar Reportes


Página 115





Situaciones

Excepcionales

Antes de haber cerrado la jornada de inscripciones de candidatos o de elec-

tores, se requiere tener un informe sobre los registros efectuados

Justificación Los clientes haciendo uso de las capacidades del patrón pueden generar

copias del modelo de objetos del servidor que contengan información sobre

los registros efectuados

Resultado Se pueden obtener reportes temporales aprovechando el uso del patrón

Tabla 58. Patrón Business Process (Composition) - CU Almacenar reports


Caso de uso Almacenar votos del sistema

Lo que permite Hay pasos o entradas en los proceso de negocio que involucran la coordina-

ción de procesos y actividades previas

Situaciones

Excepcionales

Se da inicio a la jornada de votación y se presenta un elector que no está

inscrito en el municipio

Justificación Para poder ejecutar el almacenamiento del voto de cualquier elector antes

que este acceda al sistema de votación se debe verificar en la base de datos

de inscripción de electores que el elector se halla inscrito en el municipio

Resultado El sistema almacena el voto siempre y cuando el elector haya sido validado

Tabla 59. Patrón Business Process (Composition) - CU Almacenar votos del sistema


Caso de uso Bajar Servicio Jornada de Votación

Lo que permite Un proceso de negocio en los servicios web es una composición de las acti-

vidades de negocio que pueden o no pueden ser otros servicios web. / La

intención del patrón es ilustrar y proveer una guía para combinar las activi-

dades de negocio en un único y consumible servicio web con una interface

bien definida

Situaciones

Excepcionales

Se presentan altercados de orden público en el puesto de votación y se re-

quiere bajar los servicios antes de la hora estipulada

Justificación Las actividades y procesos que componen la aplicación de votación deben

ser tenidas en cuenta para bajar el servicio de la jornada de votación


Página 116

Resultado Los servicios que se encuentren en ejecución se cierran adecuadamente y

posteriormente el sistema cierra la aplicación de votación

Tabla 60. Patrón Business Process (Composition) - CU Bajar servicio jornada de votación


Caso de uso Bajar Servicio Post-Elección

Lo que permite La intención del patrón es ilustrar y proveer una guía para combinar las

actividades de negocio en un único y consumible servicio web con una

interface bien definida

Situaciones

Excepcionales

Alternados de orden público mientras se hace el conteo de los votos

Justificación Dado que se puede acceder mediante un único servicio web no importa que

el lugar de acceso al servicio no esté físicamente donde se presentan los

problemas de orden público y donde se encuentra la base de datos donde se

van a almacenar los datos

Resultado Se puede realizar el conteo de los votos desde otro lugar

Tabla 61. Patrón Business Process (Composition) - CU Bajar servicio post-elección


Caso de uso Bajar servicio de validación biométrica y código de barras


ción de procesos y actividades externas

Situaciones

Excepcionales

El sistema SAGEM tiene fallos o hay reportes de error del sistema SAGEM

Justificación Si no se está usando la validación con el sistema SAGEM mantener cone-

xiones con dicho sistema baja el rendimiento

Resultado Mejoramiento del rendimiento

Tabla 62. Patrón Business Process (Composition) - CU Bajar servicios de validación biométrica y

código de barras


Caso de uso Cerrar Jornada Post-Elección


Página 117



vidades de negocio que pueden o no pueden ser otros servicios web

Situaciones

Excepcionales

El servicio jornada de votación fue abierto después de su cierre

Justificación Para poderse cerrar la jornada post-elección tuvo que haberse ejecutado el

servicio jornada post-elección que depende directamente de haber cerrado

el servicio jornada de votación

Resultado El sistema anularía cualquier modificación realizada sobre la base de datos

después de la primera fecha de cierre del servicio jornada de votación

Tabla 63. Patrón Business Process (Composition) - CU Cerrar jornada post-elección


Caso de uso Cerrar Jornada de Votación


ción de procesos y actividades externas

Situaciones

Excepcionales

Intento de ingreso de datos a la aplicación después de cerrada la jornada

Justificación El hecho de realizar el cierre de la jornada evita fraudes en la jornada elec-

toral ya que esta acción de cierre de la jornada funcionara como impedi-

mento de seguridad ante los próximos eventos de ingreso de datos después

de cerrada la jornada

Resultado El sistema no permite ingresos de nuevos registros a la base de datos una

vez cerradas las jornadas electorales

Tabla 64. Patrón Business Process (Composition) - CU Cerrar jornada de votación


Caso de uso Cerrar Proceso De Inscripciones candidatos

Lo que permite Aislar la selección de servicios y la lógica de instanciación

Situaciones

Excepcionales

Intento de ingreso del nuevo registro de candidato después de cerrar el pro-

ceso

Justificación Usando el patrón Service Factory se facilita la restricción de acceso al ser-

vicio web, en este caso sería el servicio de registro de candidato, por lo

tanto no habría forma de ingresar nuevos registros de candidatos


Página 118

Resultado El sistema no permite después del cierre del proceso el almacenamiento de

nuevas inscripciones o modificaciones del candidato

Tabla 65. Patrón Service Factory - CU Cerrar proceso de inscripciones candidatos


Caso de uso Cerrar Proceso De Inscripciones electores


Situaciones

Excepcionales

Intento de ingreso del nuevo registro de elector después de cerrar el proceso

Justificación Usando el patrón Service Factory se facilita la restricción de acceso al ser-

vicio web, en este caso sería el servicio de registro de elector, por lo tanto

no habría forma de ingresar nuevos registros de electores

Resultado El sistema no permite después del cierre del proceso el almacenamiento de

nuevas inscripciones de elector

Tabla 66. Patrón Service Factory - CU Cerrar proceso de inscripciones electores


Caso de uso Crear DB de reportes

Lo que permite Una faceta del proceso de negocio direcciona la estructura de un proceso de

negocio y la otra faceta direcciona como estandarizar las interfaces para los

proceso de negocio

Situaciones

Excepcionales

Se necesita una nueva base de datos para una nueva jornada electoral

Justificación El hecho de crear una nueva base de datos no afecta la estructura lógica del

proceso de negocio

Resultado La BD creada es fácilmente direccionable por los servicios gracias al mane-

jo del patrón business process composition

Tabla 67. Patrón Business Process (Composition) - CU Crear DB de registro


Caso de uso Crear DB de votos


Página 119




proceso de negocio

Situaciones

Excepcionales

Se necesita una nueva base de datos para una nueva jornada electoral

Justificación El hecho de crear una nueva base de datos no afecta la estructura lógica del

proceso de negocio

Resultado La BD creada es fácilmente direccionable por los servicios gracias al mane-

jo del patrón business process composition

Tabla 68. Patrón Business Process (Composition) - CU Crear DB de votos


Caso de uso Crear formulario E-24/E-26

Lo que permite El proceso de negocio es una abstracción de la lógica compleja de negocio

que consiste de uno o más actividades de negocio. La lógica y el flujo de las

actividades y el flujo que los datos toman a través de proceso de negocio

Situaciones

Excepcionales

Generar un formulario de un proceso no estipulado

Justificación El patrón permite ajustar dentro del flujo de los procesos de negocio que

actividad o subproceso puede ser automatizado como es el caso de un for-

mulario

Resultado El sistema no permite la generación de formularios que no estén definidos y

vinculados dentro del flujo de los procesos de negocio

Tabla 69. Patrón Business Process (Composition) - CU Crear formularios E-24/E-26


Caso de uso Crear una DB de registro candidatos

Lo que permite Cuando el tiempo para una transición llega usted podría configurar la facto-

ría para localizar el nuevo sistema de persistencia de los datos

Situaciones

Excepcionales

Un candidato se va a registrar como elector en otro municipio

Justificación El patrón permite hacer la replicación de datos gracias a a configuración de

una factoría para el registro desde la aplicación registro candidato a la apli-

cación registro elector


Página 120

Resultado Cuando se cree la BD de candidato se permita replicar parte de la informa-

ción de este registro a la base de datos de electores. Por tanto el candidato

que desee registrarse como elector en otro municipio no lo podrá hacer

Tabla 70. Patrón Service Factory - CU Crear una DB de registro candidatos


Caso de uso Crear una DB de registro electores


Situaciones

Excepcionales

Intento de copia de registro de elector

Justificación Este patrón permite que solo la información que se usa en el servicio pueda

ser empleada para crear el registro del elector, evitando que esta informa-

ción pueda ser duplicada o solicitada en otro servicio externo como si lo

hace el registro candidato

Resultado Solo mediante el servicio de registrar elector se puede crear dicho registro

Tabla 71. Patrón Service Factory - CU Crear una DB de registro electores


Caso de uso Generar certificado electoral



Situaciones

Excepcionales

Un usuario que se inscribió pero no votó reclame el certificado electoral

Justificación Gracias al patrón se puede establecer que el servicio de generar certificado

sea una composición del servicio registrar elector y el servicio votación

Resultado El sistema no permite la generación de certificados electorales a personas

que no hayan sido registrados en el municipio para votar y que no hayan

realizado la acción de votar

Tabla 72. Patrón Business Process (Composition) - CU Generar certificado electoral


Caso de uso Generar certificado inscripción alcaldía


Página 121




Situaciones

Excepcionales

Un elector que se inscribió reclama el certificado de inscripción alcalde


sea una composición del servicio registrar candidato

Resultado El sistema no permite la generación de certificados de inscripción de candi-

dato a la alcaldía a personas que no hayan sido registrados como candidatos

Tabla 73. Patrón Business Process (Composition) - CU Generar certificado inscripción alcaldía


Caso de uso Generar certificado inscripción concejo



Situaciones

Excepcionales

Un elector que se inscribió reclama el certificado de inscripción concejo


sea una composición del servicio registrar candidato

Resultado El sistema no permite la generación de certificados de inscripción de candi-

dato al concejo a personas que no hayan sido registrados como candidatos

Tabla 74. Patrón Business Process (Composition) - CU Generar certificado inscripción concejo


Caso de uso Generar certificado inscripción electoral



Situaciones

Excepcionales

Un elector que no se inscribió reclama el certificado de inscripción electoral


sea una composición del servicio registrar elector

Resultado El sistema no permite la generación de certificados de inscripción electoral

a personas que no hayan sido registrados como electores

Tabla 75. Patrón Business Process (Composition) - CU Generar certificado inscripción electoral


Página 122


Caso de uso Habilitar acceso a la interface de votación



proceso de negocio

Situaciones

Excepcionales

Un usuario no registrado intenta acceder a la interface de votación de forma

remota

Justificación El acceso de un usuario no registrado no está direccionado dentro de la

estructura del proceso de negocio, ni mucho menos estandarizado para usar

las interfaces del proceso

Resultado El sistema no permite el acceso del usuario no registrado

Tabla 76. Patrón Business Process (Composition) - CU Habilitar acceso a la interface de votación


Caso de uso Iniciar proceso Inscripciones candidatos

Lo que permite Permite utilizar el patrón mediador para mitigar las diferencias entres servi-

cios

Situaciones

Excepcionales

Se realiza la inscripción de un candidato, pero la registraduría que la ins-

cripción de electores aún no había iniciado

Justificación El patrón service factory da flexibilidad en la integración del patrón media-

tor

Resultado Dado el servicio de inscripción de candidato se pueda utilizar información

parcial de su registro para usarla en el registro de elector mediante el patrón

mediator

Tabla 77. Patrón Service Factory - CU Iniciar proceso inscripciones candidatos


Caso de uso Iniciar Proceso Inscripciones Electores


Situaciones

Excepcionales

Un candidato desea ser registrado con sus datos de elector

Justificación El hecho que un elector se registre no implica que tenga que hacer un regis-

tro como candidato, por lo tanto el registro para electores estará definido

dentro de la temporalidad de duración del proceso


Página 123


Resultado El servicio web que realiza el registro del elector crea solamente en la base

de datos de electores este registro

Tabla 78. Patrón Service Factory - CU Iniciar proceso inscripciones electores


Caso de uso Iniciar Jornada de Votación



Situaciones

Excepcionales

Se intenta iniciar la jornada de votación sin haber cerrado el proceso de

registro de candidatos y registro de electores

Justificación La jornada de iniciación de jornada de votación no se puede realizar si no se

ha llevado a cabo el proceso de registro de candidatos y de electores

Resultado El sistema no debe permitir el inicio de la jornada de votación

Tabla 79. Patrón Business Process (Composition) - CU Iniciar jornada de votación


Caso de uso Iniciar Servicio Jornada Votación



proceso de negocio

Situaciones

Excepcionales

Se intenta acceder al servicio web de jornada de votación sin haber iniciado

el proceso jornada votación

Justificación Debido a que no se ha iniciado el proceso de negocio de jornada votación

(elemento esencial de la estructura de proceso) no se puede dar cabida a

invocar el servicio web que permite iniciar la jornada de votación

Resultado No se permite invocar el servicio web

Tabla 80. Patrón Business Process (Composition) - CU Iniciar servicio jornada votación


Caso de uso Iniciar Jornada Post-Elección




Página 124

Situaciones

Excepcionales

Se intenta iniciar la jornada post-elección sin haber cerrado la jornada de

votación

Justificación Hasta que no se ha cerrado la jornada de votación no se puede iniciar la

jornada post-elección

Resultado El sistema no debe permitir el inicio de la jornada post-elección

Tabla 81. Patrón Business Process (Composition) - CU Iniciar servicios jornada post-elección


Caso de uso Iniciar Servicio Jornada Post-Elección



proceso de negocio

Situaciones

Excepcionales

Se intenta acceder al servicio web de jornada post-elección sin haber inicia-

do el proceso jornada post-elección

Justificación Debido a que no se ha iniciado el proceso de negocio de jornada post-

elección (elemento esencial de la estructura de proceso) no se puede dar

cabida a invocar el servicio web que permite iniciar la jornada post-elección

Resultado No se permite invocar el servicio web

Tabla 82. Patrón Business Process (Composition) - CU Iniciar servicio jornada post-elección


Caso de uso Iniciar servicio de validación biométrica y de código de barras




Situaciones

Excepcionales

Se intenta registrar un elector sin validar su identidad

Justificación Dado que el patrón permite establecer la conexión con el servidor SAGEM

para la aplicación morphocheck mediante un modelo proxy, si no establece

la conexión el sistema no deberá permitir el registro de ningún elector

Resultado No se permite el registro del elector

Tabla 83. Patrón Business Process (Composition) - CU Iniciar servicio de validación biométrica y

código de barras


Página 125



Caso de uso Monitorear el sistema de votación



Situaciones

Excepcionales

Hay un puesto de votación que está fallando

Justificación El patrón business process composition permite el uso a nivel de diseño de

patrones como el observer que son útiles para el monitoreo de los objetos

de negocio

Resultado La acción de monitorear refleja los puntos que tienen fallos en el sistema

Tabla 84. Patrón Business Process (Composition) - CU Monitorear el sistema de votación


Caso de uso Validar el elector en jornada de votación


tos

Situaciones

Excepcionales

Se presenta un elector con una cedula falsa y pretende votar

Justificación La identificación del usuario se maneja como un objeto de negocio el cual

se compara con la colección de objetos de negocio almacenados en el servi-

dor SAGEM de la aplicación morphocheck

Resultado El sistema para permitir la votación debe validar la identificación del elec-

tor

Tabla 85. Patrón Service Factory - CU Validar el elector en jornada de votación


Caso de uso Validar mediante lector biométrico y de código de barras en jornada de

inscripción


tos

Situaciones

Excepcionales

Se presenta un elector con una cedula falsa y pretende inscribirse


Página 126

Justificación La identificación del usuario se maneja como un objeto de negocio el cual

se compara con la colección de objetos de negocio almacenados en el servi-

dor SAGEM de la aplicación morphocheck

Resultado El sistema para registrar al elector no permite la creación del registro si la

validación es falsa

Tabla 86. Patrón Service Factory - CU Validar mediante lector biométrico y código de barras en

jornada de inscripción

propuesta para trabajo de grado - trabajos de grado de la...

Documents