PA MODELO DE ARQUITECTURA DE SISTEMA DEL VOTO ELECTRÓNICO EN EL MUNICIPIO DE CHOACHÍ DANIEL YESID CACERES RINCON

Transcripción

1 PA 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

2

3 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Modalidad de Profundización PA 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 PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERIA MAESTRÍA EN INGENIERIA DE SISTEMAS Y COMPUTACIÓN BOGOTÁ, D.C. Enero, 2012 Preparado por el Grupo Investigación Istar- Versión /03/2008 Página i

4 Ingeniería de Sistemas Grupo de Investigación ISTAR PA 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 ii

5 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Modalidad de Profundización 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 Preparado por el Grupo Investigación Istar- Versión /03/2008 Página iii

6 Ingeniería de Sistemas Grupo de Investigación ISTAR PA 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 registrador 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 desarrollo del proyecto. Página iv

7 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Modalidad de Profundización Contenido INTRODUCCIÓN...1 I - OBJETIVOS OBJETIVOS Objetivo General Objetivos Específicos Definiciones Acrónimos... 4 II MARCO TEÓRICO...5 III - MÉTODO...6 IV MODELO DE ARQUITECTURA DE SISTEMA MODELO DE ARQUITECTURA EMPRESARIAL Selección de Vistas Actores Stakeholders Vista Introductoria (Introductory Viewpoint) Vista de la Organización (Organization Viewpoint) Vista de Co-operación de Actores (Actor Co-operation viewpoint) Vista de Proceso de Negocio (Business Process Viewpoint) Vista de Co-operación del Proceso de Negocio (Business Process Co-operation Viewpoint) Vista de Comportamiento de la Aplicación (Application Behavior Viewpoint) Vista de Infraestructura (Infrastructure Viewpoint) MODELO DE ARQUITECTURA DE SOFTWARE Identificación y Selección de Patrones de Negocio Introducción al Patrón de Arquitectura N-Tier Identificación y Selección de Patrones de Diseño DISEÑO DE LA BASE DE DATOS PARA EL VOTO ELECTRÓNICO Diseño Lógico de la Base de Datos para el Proceso de Inscripción de Electores y Candidatos Diseño Lógico de la Base de Datos para el Proceso de Votación V PROTOTIPO Y VALIDACIÓN PROTOTIPO...51 Preparado por el Grupo Investigación Istar- Versión /03/2008 Página v

8 Ingeniería de Sistemas Grupo de Investigación ISTAR PA VALIDACIÓN DE LA ARQUITECTURA EMPRESARIAL Validación Sintáctica realizada por el Ing. José C. Niño Validación Semántica realizada por el Registrador municipal de Choachí, Dr. Jorge A. Díaz VALIDACIÓN DE LA ARQUITECTURA DE SOFTWARE Validación según ATAM Validación TAM VI - CONCLUSIONES...60 VII TRABAJO FUTURO...63 VIII BIBLIOGRAFÍA...64 IX ANEXOS ANEXO A ANEXO B ANEXO C ANEXO D ANEXO E ANEXO F ANEXO G ANEXO H Página vi

9 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Modalidad de Profundización Lista de Tablas Tabla 1. Definiciones... 4 Tabla 2. Acrónimos... 4 Tabla 3. Capas y vistas Tabla 4. Actores Tabla 5. Stakeholders Tabla 6. Arquitectura empresarial: Stakeholders vs Actores Tabla 7. Mapeo de Actores CU actual vs Actores Arquitectura Empresarial vs Actores CU E- Vote Tabla 8. Procesos de la registraduría municipal de Choachí vs Procesos según BPTrends. Autor: Daniel Cáceres Tabla 9. Patrones de negocio de Forster vs Procesos de negocio de la Registraduría municipal de Choachí. Autor: Daniel Cáceres Tabla 10. Patrones de negocio de Forster vs Procesos de negocio de la Registraduría municipal de Choachí. Autor: Daniel Cáceres Tabla 11. Patrones de negocio de Kim et Al. vs Procesos de negocio de la Registraduría municipal de Choachí. Autor: Daniel Cáceres Tabla 12. Aplicaciones vs Atributos de calidad Tabla 13. Aplicaciones vs Atributos de Calidad según Khosravi y Guéhéneuc Tabla 14. Aplicación Registro Candidato vs Patrones de diseño Tabla 15. Aplicación registro elector vs Patrones de diseño Tabla 16. Aplicación votación vs Patrones de diseño Tabla 17. Aplicación resultados escrutinio vs Patrones de diseño Preparado por el Grupo Investigación Istar- Versión /03/2008 Página vii

10 Ingeniería de Sistemas Grupo de Investigación ISTAR PA Tabla 18. Relación de patrones en el nivel 1 de diseño Tabla 19. Resumen Aplicación de ATAM sobre la arquitectura de sistema del voto electrónico Tabla 20. Patrón Service Factory - CU Almacenar formularios en DB Tabla 21. Patrón Service Factory CU Almacenar registro electores Tabla 22. Resultados registrador TAM Tabla 23. Resultados ciudadanos TAM Tabla 24. Descripción de los patrones de Web Services Tabla 25. Elector Tabla 26. Cierre proceso electoral Tabla 27. Inicio proceso Electoral Tabla 28. Proceso electoral Tabla 29. Municipio Tabla 30. Departamento Tabla 31. Inscripción elector Tabla 32. Inscripción candidato Tabla 33. Cargo candidato Tabla 34. Aval Tabla 35. Partido político Tabla 36. Tipo Aval Tabla 37. Puesto Tabla 38. Mesa Tabla 39. Boletín Tabla 40. Cargo jurado Tabla 41. Jurado Página viii

11 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Modalidad de Profundización Tabla 42. Participantes Tabla 43. Otro tipo Tabla 44. Inscrip Tabla 45. Candidato Tabla 46. Partido Tabla 47. Candidato consulta Tabla 48. Voto alcaldía Tabla 49. Voto concejo Tabla 50. Voto consulta Tabla 51. Voto Tabla 52. Corporación Tabla 53. Casos de Uso y atributos de calidad para validación ATAM Tabla 54. Patrón Service Factory - CU Almacenar formularios en DB Tabla 55. Patrón Service Factory - CU Almacenar registro candidatos Tabla 56. Patrón Service Factory - CU Almacenar registro electores Tabla 57. Patrón Business Process (Composition) - CU Almacenar conteo preliminar Tabla 58. Patrón Business Process (Composition) - CU Almacenar reports Tabla 59. Patrón Business Process (Composition) - CU Almacenar votos del sistema 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 Tabla 62. Patrón Business Process (Composition) - CU Bajar servicios de validación biométrica y código de barras Tabla 63. Patrón Business Process (Composition) - CU Cerrar jornada post-elección Tabla 64. Patrón Business Process (Composition) - CU Cerrar jornada de votación Tabla 65. Patrón Service Factory - CU Cerrar proceso de inscripciones candidatos Preparado por el Grupo Investigación Istar- Versión /03/2008 Página ix

12 Ingeniería de Sistemas Grupo de Investigación ISTAR PA Tabla 66. Patrón Service Factory - CU Cerrar proceso de inscripciones electores Tabla 67. Patrón Business Process (Composition) - CU Crear DB de registro Tabla 68. Patrón Business Process (Composition) - CU Crear DB de votos Tabla 69. Patrón Business Process (Composition) - CU Crear formularios E-24/E Tabla 70. Patrón Service Factory - CU Crear una DB de registro candidatos Tabla 71. Patrón Service Factory - CU Crear una DB de registro electores Tabla 72. Patrón Business Process (Composition) - CU Generar certificado electoral Tabla 73. Patrón Business Process (Composition) - CU Generar certificado inscripción alcaldía Tabla 74. Patrón Business Process (Composition) - CU Generar certificado inscripción concejo Tabla 75. Patrón Business Process (Composition) - CU Generar certificado inscripción electoral Tabla 76. Patrón Business Process (Composition) - CU Habilitar acceso a la interface de votación Tabla 77. Patrón Service Factory - CU Iniciar proceso inscripciones candidatos Tabla 78. Patrón Service Factory - CU Iniciar proceso inscripciones electores Tabla 79. Patrón Business Process (Composition) - CU Iniciar jornada de votación Tabla 80. Patrón Business Process (Composition) - CU Iniciar servicio jornada votación Tabla 81. Patrón Business Process (Composition) - CU Iniciar servicios jornada post-elección Tabla 82. Patrón Business Process (Composition) - CU Iniciar servicio jornada post-elección Tabla 83. Patrón Business Process (Composition) - CU Iniciar servicio de validación biométrica y código de barras 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 Página x

13 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Modalidad de Profundización Tabla 86. Patrón Service Factory - CU Validar mediante lector biométrico y código de barras en jornada de inscripción Lista de Figuras Figura 1. Modelo de la Ciencia basada en el diseño. Fuente: [38] Figura 2. Vista introductoria (previa) Figura 3. Vista de la organización (previa) Figura 4. Vista de co-operación de actores (previa) Figura 5. Vista de proceso de negocio (previa) Figura 6. Vista de co-operacion del proceso de negocio (previa) Figura 7. Vista de comportamiento de la aplicación (previa) Figura 8. Vista de Infraestructura (previa) Figura 9. Estado actual de la registraduría municipal de Choachí con respecto al voto (previa) Figura 10. Estado deseado del voto electrónico en el municipio de Choachí (previa) Figura 11. Diseño de alto nivel: Patrón arquitectónico general N-Tier para el voto electrónico Figura 12. Tabla de comparación atributos de calidad vs patrones de diseño. Autor: Khosravi y Guéhéneuc. Modificada por: Anónimo Figura 13. Mapeo de aplicaciones a patrones GOF y a patrones de Web Services Figura 14. Diseño detallado (nivel 1): Patrón N-Tier más Patrones Web Services Figura 15. Diseño detallado (nivel 2) del voto electrónico Figura 16. Modelo lógico del proceso de inscripción de candidatos y electores Figura 17. Modelo lógico del proceso de votación Preparado por el Grupo Investigación Istar- Versión /03/2008 Página xi

14 Ingeniería de Sistemas Grupo de Investigación ISTAR PA Figura 18. Modelo BPMN del subproceso de Inscripción de candidatos y electores Figura 19. Inscripción del candidato Figura 20. Modelo de Aceptación de la Tecnología. Fuente: Davis [69] Figura 21. Vista introductoria parte A Figura 22. Vista introductoria parte B Figura 23. Vista introductoria parte C Figura 24. Vista de la organización Figura 25. Vista de co-operación de actor Figura 26. Vista del proceso de negocio parte A Figura 27. Vista del proceso de negocio parte B Figura 28. Vista del proceso de negocio parte C Figura 29. Vista de co-operación del proceso de negocio parte A Figura 30. Vista de co-operación del proceso de negocio parte B Figura 31. Vista de co-operación del proceso de negocio parte C Figura 32. Vista de co-operación del proceso de negocio parte D Figura 33. Vista del comportamiento de la aplicación parte A Figura 34. Vista del comportamiento de la aplicación parte B Figura 35. Vista del comportamiento de la aplicación parte C Figura 36. Vista del comportamiento de la aplicación parte D Figura 37. Vista de infraestructura Figura 38. Estado actual de la registraduría municipal de Choachí para el voto Figura 39. Estado ideal de la registraduría municipal de Choachí para el voto electrónico Figura 40. Modelo BPMN del proceso electoral Figura 41. Modelo BPMN del subproceso de inscripción Página xii

15 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Modalidad de Profundización Figura 42. Modelo BPMN del subproceso de inscripción de candidatos Figura 43. Modelo BPMN del subproceso de inscripción de electores Figura 44. Modelo BPMN del subproceso de votación Figura 45. Modelo BPMN del subproceso de votación para alcaldía Figura 46. Modelo BPMN del subproceso de votación para concejo Preparado por el Grupo Investigación Istar- Versión /03/2008 Página xiii

16 Ingeniería de Sistemas Grupo de Investigación ISTAR PA 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 proyecto definidos por la registraduría y la población, y ligándolas a la construcción de la propuesta desde el ámbito empresarial como el ámbito software. Página xiv

17 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Modalidad de Profundización RESUMEN EJECUTIVO El presente documento describe la totalidad del 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. 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 reconocimiento 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 Registradurí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 població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 empresariales como de software, se constituyó el modelo de arquitectura de sistema para el voto electró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 desarrollo de este proyecto, nos indujo como parte esencial del proceso que se debía realizar validaciones 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 empresarial 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 ciudadanos para la posterior validación del modelo de arquitectura, permitiendo reflejar que los proyectos 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. Preparado por el Grupo Investigación Istar- Versión /03/2008 Página xv

18 Ingeniería de Sistemas Grupo de Investigación ISTAR PA 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, documentos de validación de la arquitectura de sistema (desglosado en validación de la arquitectura empresarial así como de la arquitectura de software) y un prototipo de interfaces funcional 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 concepción de que hay que construir siempre dispositivos Hardware para soportar el voto electró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 registraduría municipal de Choachí y nacional (en caso de implementarse). Conjuntamente, el modelo de arquitectura de sistema desarrollado permitiría reducir el impacto ambiental 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, 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 organizació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 estructuras 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 xvi

19 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Modalidad de Profundización líneas estratégicas de la registraduría que no fueron analizadas en el presente proyecto (ya que no eran afines). Preparado por el Grupo Investigación Istar- Versión /03/2008 Página xvii

20

21 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Modalidad de Profundización INTRODUCCIÓN La evolución en la forma de votar de ciertos países del mundo ha cambiado hacia el desarrollo 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 sufrieron 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 desconfianza de la gente al uso sin capacitación de estas herramientas ya que el factor de transparencia siempre fue puesto en duda, y en Luxemburgo los problemas que se dieron fueron el hecho 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 introduzca, 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 electró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 representa 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 Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 1

22 Ingeniería de Sistemas Grupo de Investigación ISTAR PA de sistema 1, la cual es la integración de la arquitectura empresarial (descripción de la estructura 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 evolución de una empresa [16]) y la arquitectura de software, ya que mediante ésta se espera construir 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 2

23 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Modalidad de Profundización I - OBJETIVOS El problema de estudio que se planteó en este proyecto era 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 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 implementació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 tema, experiencias y políticas de organismos internacionales con los sistemas ya implementados en países como Brasil, Estados Unidos, la Unión Europea (o Suiza), 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 població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 Choachí 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ónico 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. Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 3

24 Ingeniería de Sistemas Grupo de Investigación ISTAR PA Definiciones Archimate The Open Group Architecture Framework Actor Vista - Archimate Punto de Vista - Archimate Capa Archimate Tabla 1. Definiciones Es un lenguaje que complementa TOGAF, ya que proporciona un conjunto de conceptos independiente del proveedor, incluyendo una representació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. TOGAF es un marco de trabajo estándar de arquitectura para la industria 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. Alguien o algo externo al sistema que interactúa con él. 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 Establece los conceptos, modelos, técnicas de análisis, y visualizaciones que son proporcionados por la vista. Clasificación que se da en el lenguaje Archimate para agrupar servicios según su funcionalidad especificando 3 partes del diseño: capa de negocio, capa de aplicación, capa de tecnología. 1.4 Acrónimos TOGAF ADM UML BPM Tabla 2. Acrónimos The Open Group Architecture Framework Architecture Development Method Unified Modeling Language Business Process Management Página 4

25 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Modalidad de Profundización 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 computadora 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 "votació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 referencia 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 oficial [26]. Este concepto será el que usaremos de guía para el desarrollo del modelo de arquitectura 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 desarrollo 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 primera 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 mejoras 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 votante (VVPAT) [35][36][37]. En la era de las tecnologías de la información, Colombia ha progresado paulatinamente desarrollando políticas nacionales y algunas modificaciones a ciertas leyes. A pesar de eso, Colombia 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 Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 5

26 Ingeniería de Sistemas Grupo de Investigación ISTAR PA 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 capacidad 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 democracia 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 6

27 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Modalidad de Profundización 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 necesidades del negocio como son percibidas por la gente dentro de la organización. Tales percepciones 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 contexto de las estrategias organizacionales, estructura, cultura y procesos existentes del negocio. Ellas son ubicadas con relación a la infraestructura tecnológica existente, aplicaciones, arquitecturas 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 interactúan con el entorno. Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 7

28 Ingeniería de Sistemas Grupo de Investigación ISTAR PA 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 cabo. D. Definición, reconocimiento y descripción de la tecnología disponible a nivel de infraestructura, aplicaciones, arquitecturas de comunicación y capacidades de desarrollo. E. Captura de los requerimientos funcionales y no funcionales de los stakeholders mediante entrevistas. F. Definición y validación de los requerimientos (por ejemplo, utilizando técnicas de recolecció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 investigación. Para el desarrollo de esta fase se realizaron las siguientes actividades: A. Desarrollo del documento de requerimientos del modelo de arquitectura del sistema. B. Definición y clasificación de los fundamentos del voto electrónico y de las arquitecturas (tanto empresariales como de software) en: teorías, conceptos, metodologías, métodos, instanciaciones. C. Definición del proceso metodológico para la votación electrónica: modelos actuales 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 descripción de arquitecturas (TOGAF, ZACKMAN, estilos arquitectónicos, patrones arquitectónicos y/o de diseño), modelos para escenarios de arquitectura (por ejemplo FAAM), formalismos, métricas y criterios de validación de las arquitecturas (por ejemplo SACAM, modelo de madurez para arquitecturas empresariales, evaluación con expertos, Feature comparison), métodos para la prueba de arquitecturas (por ejemplo Technology Acceptance Model (TAM)). E. Definición del proceso metodológico para el desarrollo de prototipos (por ejemplo, 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 aplicación adecuada de los fundamentos y metodologías existentes. Para el desarrollo de esta fase se realizaron las siguientes actividades: Página 8

29 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Modalidad de Profundización 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 evaluació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 conocimiento, 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 principalmente 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 aumentar 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 tampoco 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áficos 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 representativos a nivel de diseño. Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 9

30 Ingeniería de Sistemas Grupo de Investigación ISTAR PA Selección de Vistas Hay que aclarar que lo que Archimate maneja como puntos de vista 2 se ajustara para la compresió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 ingeniería de sistemas. Capa Negocio Aplicación Tecnología Negocio Negocio Negocio Aplicación Negocio Aplicación Aplicación Tecnología Vista (viewpoint según Archimate) Introductorio (introductory) Organización (organization) Co-operación de actores (actor co-operation) Proceso de negocio (Business Process) Co-operación del Proceso de negocio (Business Process co-operation) Comportamiento de la aplicación (Application behavior) 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 10

31 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Modalidad de Profundización 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 resultado final junto con el juez. También puede ejercer de jurado en alguna mesa de votación El elector es quien interactúa con el proceso inscripción elector. Posterior a esto, el elector es el único que puede realizar una votación en el sistema. El juez solo participa como colaborador del registrador para realizar el proceso del escrutinio. El auxiliar es una persona que puede ser asignada en determinados momentos por el registrador para realizar 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. El jurado es la persona encargada de autorizar durante proceso de votación el ingreso del elector al dispositivo de votación El personal de back office es el encargado de dar soporte sobre la administración del sistema de voto electrónico. Dentro de esto se considera que debe haber una persona para todo el sistema, una para el control de electores y otra para el control de candidatos Introductorio Organización Co-operación de actor Co-operación de proceso de negocio Proceso de negocio Introductorio Organización Co-operación de actor Co-operación de proceso de negocio Introductorio Organización Co-operación de actor Co-operación de proceso de negocio Introductorio Organización Co-operación de actor Co-operación de proceso de negocio Introductorio Co-operación de proceso de negocio Organización Co-operación de actor Proceso de negocio Co-operación de proceso de negocio Infraestructura Comportamiento de la aplicación Página 11 Preparado por el Grupo Investigación Istar- Versión /03/2008

32 Ingeniería de Sistemas Grupo de Investigación ISTAR PA El desarrollador es el encargado de implementar el sistema de voto electró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 Co-operación de proceso de negocio Infraestructura Comportamiento de la aplicació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 Usuario Manager Desarrollador El administrador es el encargado de ejercer un monitoreo continuo a los procesos y de solucionar inconvenientes en tiempos cortos que se presenten sobre la arquitectura empresarial. Además de esto, es quien asigna los tipos de perfiles a los usuarios. El usuario es quien se interesa en conocer que mejoras le ofrecerá la arquitectura y con cuales procesos él podrá interactuar. El manager es la figura dentro de la empresa que apoya totalmente el desarrollo de la arquitectura, a la vez que es el encargado de aprobar tanto las soluciones como el presupuesto destinado para el proyecto de arquitectura empresarial El desarrollador es la persona encargada de implementar las aplicaciones necesarias o sugeridas en la arquitec- Introductorio Organización Co-operación de proceso de negocio Comportamiento de la aplicación Introductorio Co-operación de proceso de negocio Introductorio Organización Co-operación de actor Proceso de negocio Co-operación de proceso de negocio Comportamiento de la aplicación Infraestructura Comportamiento de la aplicación Infraestructura Proceso de negocio Página 12

33 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Modalidad de Profundización Tabla 5. Stakeholders tura empresarial Co-operación de Proceso de negocio Co-operación de actor Teniendo en cuenta los stakeholders, los actores y a la vez su asociación con las vistas definidas, la relación entre ellos queda plasmada de la siguiente forma: STAKEHOLDERS Administrador Usuario Manager Desarrollador ACTORES Jefe Back Office, Administrador electores, Administrador candidatos Elector, Juez, Jurado, Candidato, Registrador, Registrador Municipal, Auxiliar/Secretaria Registrador, Registrador Municipal 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 adquiridos 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 auditabilidad, 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. Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 13

34 Ingeniería de Sistemas Grupo de Investigación ISTAR PA 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 candidato, entregar certificación candidatura; y un servicio ligado al proceso Inscripción elector: 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 candidato partiendo del subproceso de validar candidato, el cual se lleva acabo sobre la aplicación MorphoCheck de la empresa SAGEM, la cual utiliza la validación biométrica y de código 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 prosigue 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 registradurí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 inscripció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 14

35 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Modalidad de Profundización 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 modificar 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 certificados. b. Elector Con respecto al actor Elector, él interactúa con 4 servicios de negocios repartidos en 2 procesos: Los servicios de Registrar inscripción elector y Entregar certificado inscripción pertenecen 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 almacenan los datos otorgados por el Elector. Esta aplicación funcionaria sobre el mainframe ubicado en la Registraduría municipal de Choachí. Después del registro, el subproceso de confirmación si ha sido satisfactorio el registro mostrara un mensaje de confirmación para dar continuación al subproceso de certificación inscripció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 Electores. Si el registro existe, se da inicio al subproceso de realizar votación donde el elector interactú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 confirmación le saldrá en pantalla un mensaje de confirmación sobre las opciones que acaba de realizar, colocando en decisión del elector, seguir o volver a votar. Cuando decida seguir, el subproceso 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 votació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 derecho a ejercer su voto, por tanto se considerara un elector más. Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 15

36 Ingeniería de Sistemas Grupo de Investigación ISTAR PA 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 facultades 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 proceso 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 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 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 genera 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 16

37 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Modalidad de Profundización 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 Choachí. 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 guardaran 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 resultados. A nivel de infraestructura se aprecia que tanto el servidor MORPHOCHECK, el nodo Mainframe, 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: primero 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 encargado 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. Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 17

38 Ingeniería de Sistemas Grupo de Investigación ISTAR PA Vista de la Organización (Organization Viewpoint) Esta vista es una expresión sobre el organigrama que se reconoce en la registraduría municipal 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 ciertos 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 procesos 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 debieran 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 18

39 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Modalidad de Profundización 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 color, que corresponde a la capa de aplicaciones otro tipo de personal). Como un subempleado, quien ejercería las veces de Registrador bajo ciertas jurisdicciones está el registrador municipal 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 autorice 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 implementar 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 auxiliar/secretaria pueden relacionarse con el elector mediante la interacción directa con él, definiendo 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 Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 19

40 Ingeniería de Sistemas Grupo de Investigación ISTAR PA 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 candidato 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 electró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 automatizar 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 auditorias 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 20

41 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Modalidad de Profundización 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 candidaturas, 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 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 candidato. 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 residencia, 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 pertenezcan 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 subproceso 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ó satisfactoriamente el registro y mostrando luego en pantalla un mensaje de confirmación. Automáticamente 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 Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 21

42 Ingeniería de Sistemas Grupo de Investigación ISTAR PA 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 candidato 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 cuando 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 candidato 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 candidatos 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 subproceso 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 registro 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 22

43 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Modalidad de Profundización 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 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 validar el usuario satisfactoriamente, se inicia el subproceso verificación final candidatos. 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 analizador es un componente estándar que evita bugs y acelera el desarrollo de aplicaciones, porque 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 seguridad. Al generar el archivo XML, se da inicio al subproceso envío de candidatos 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. 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 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 validar el usuario satisfactoriamente, se inicia el subproceso verificación final electores, 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ándolo a las 4pm del mismo día. Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 23

44 Ingeniería de Sistemas Grupo de Investigación ISTAR PA 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 información del candidato por alcaldía que selecciono; mientras que la acción votar concejo genera 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 alcaldí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 generara 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 tomados 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 24

45 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Modalidad de Profundización 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 escrutinio concejo file y escrutinio alcaldía file en archivos formato XML con las respectivas normas 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 subproceso 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 mejoraron con aplicaciones software en el diseño para la votación electrónica en Choachí. Esto permite 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 inscripció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. Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 25

46 Ingeniería de Sistemas Grupo de Investigación ISTAR PA 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 Servicio 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 inscripció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 municipal 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 validació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. Este servicio esta soportado por todo el proceso, y se empieza desde el subproceso de validación de usuario. Página 26

47 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Modalidad de Profundización 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 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 interactúa con el servicio de habilitar jornada electoral, el cual consiste de permitir al sistema iniciarse 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 Registrar 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. Este servicio esta soportado por todo el proceso, y se empieza desde el subproceso de validación de usuario. El subproceso de validación de usuario esta soportado en el servicio de aplicación llamado 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 resultados 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. Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 27

48 Ingeniería de Sistemas Grupo de Investigación ISTAR PA 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 primero, 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 informació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 manipulació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 servicio 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 registradurí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 aumentar la seguridad en el proceso del voto. De esta aplicación solamente se utilizara a los archivos 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 aplicació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 28

49 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Modalidad de Profundización 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 candidato 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 almacenarlo 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 votación por alcaldía en el menú que se despliegue, seguidamente el elector en Escoger candidato/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 concejo 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. Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 29

50 Ingeniería de Sistemas Grupo de Investigación ISTAR PA 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 funcionara 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, 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-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 seguridad estimadas por este ente Vista de Infraestructura (Infrastructure Viewpoint) Esta vista ilustra la infraestructura necesaria para dar cumplimiento a los requisitos identificados 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 30

51 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Modalidad de Profundización 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 representara 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 almacenar 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 composició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ébiles 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 como son: MORPHOCHECK, registro de candidatos, registro de electores, votación, y escrutinio 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 interface para integrar los datos que se requieran de esta aplicación para el resto del modelo de arquitectura 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. Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 31

52 Ingeniería de Sistemas Grupo de Investigación ISTAR PA 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 32

53 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Modalidad de Profundización 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 posteriormente a su relación en la implementación de la arquitectura de software. ACTORES CASOS DE USO VOTACION ACTUAL ACTORES ARQUITECTURA EMPRESARIAL Registrador Registrador Registrador Elector Elector Elector Juez Juez Juez Candidato Candidato Candidato Auxiliar Auxiliar Auxiliar Jurado Jurado Sistema Alcalde Testigo Desarrollador Back Office ACTORES CASOS DE USO E-VOTE2 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 tampoco 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 puede 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 difieren dependiendo del rol. Página 33 Preparado por el Grupo Investigación Istar- Versión /03/2008

54 Ingeniería de Sistemas Grupo de Investigación ISTAR PA 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 34

55 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Modalidad de Profundización 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 municipal 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. Proceso de inscripción de candidato Proceso inscripción de electores Proceso cierre de candidatos Proceso cierre de electores Procesos intensivos en sistemas Proceso de votación x x Proceso de escrutinio de resultados x x x x x Procesos intensivos en personas x x x Procesos intensivos en decisión x x Procesos intensivos en documentos 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 previo 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íficamente 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. Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 35

56 Ingeniería de Sistemas Grupo de Investigación ISTAR PA 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 sincronizació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 modelo de arquitectura empresarial de mayor influencia para el diseño según la definición de cada patrón de negocio. Proceso de inscripción de candidato Proceso inscripción de electores Proceso cierre de candidatos Proceso cierre de electores Proceso de votación Proceso de escrutinio de resultados Patrones básicos de control de flujo Omitir validación usuario (registrador) Omitir validación usuario (registrador) Omitir publicación resultados físicos patrones estructurales Morphocheck Morphocheck Morphocheck Patrones avanzados de ramificación y sincronización patrones de múltiples instancias 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 definidos en la arquitectura empresarial por mayor cantidad de procesos relacionados son los Patrones 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 primero 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 36

57 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Modalidad de Profundización categoría: Patrones de extensión/borrado de actividad, Patrones de fusión/cambio de actividad, 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 definidos en sus artículos previamente citados. PATRONES DE FORSTER PATRONES DE KIM ET AL Patrones básicos de control de flujo Patrones avanzados de ramificación y sincronización patrones estructurales patrones de múltiples instancia Patrones de extensión/borrado de actividad Patrones de fusión/cambio de actividad Patrones de fusión/cambio de actividad 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. Proceso inscripción candidato ins- de Proceso cripción electores de de Patrones de fusión/cambio de actividad Proceso cierre de candidatos Proceso cierre de electores Patrones de extensión/borrado de actividad Patrón de borrado/desvió de actividad Patrón de borrado/desvió de actividad Patrón de cambio de contenido de actividad Patrón de cambio de contenido de actividad Patrones de división/cambio de actividad. Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 37

58 Ingeniería de Sistemas Grupo de Investigación ISTAR PA Proceso votación Proceso escrutinio resultados de de de Patrón de borrado/desvió de actividad Patrón de cambio de contenido de actividad Tabla 11. Patrones de negocio de Kim et Al. vs Procesos de negocio de la Registraduría municipal 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 clasificación de patrones diferentes como lo son el "fusión/cambio de actividad y el extensión/borrado de actividad, se buscó dentro de la base del conocimiento la forma de asociarlos 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 service. 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ógica 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 38

59 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Modalidad de Profundización 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 requerimientos) 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 atributos 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 : 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, cumplimiento 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 expectativas 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 habla 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 programació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 modelo nutshell de Khosravi y Guéhéneuc [56] que será el modelo que usaremos para nuestros 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 patrones 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 asignaba un patrón de diseño. Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 39

60 Ingeniería de Sistemas Grupo de Investigación ISTAR PA 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 calificaron 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 Excellent (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 obtenida mediante la entrevista con el Registrador municipal, los atributos de calidad del documento 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 40

61 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Modalidad de Profundización Registro candidato Registro electores Voto 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 Expendability 3 (1) E E E E Tabla 12. Aplicaciones vs Atributos de calidad Resultados 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 coincidencias entre características y atributos de las cuatro aplicaciones a trabajar (registro candidato, registro electores, voto, resultado) 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 Se deja el término en ingles ya que no tiene una traducción clara para el lector. Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 41

62 Ingeniería de Sistemas Grupo de Investigación ISTAR PA Decorator E E G F G G G G F Iterator E E G F G F F G G 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 Abstract 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 características del candidato puedan cambiar pero sin importar estos cambios su forma de interpretació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 electores Patrón E E G E E E E F G probabilidad de acierto Abstract Factory E E G G G G G G G Decorator E E G F G G G G F Iterator E E G F G F F G G 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 proceso de registro candidatos, salvo que los registros de los electores no pueden modificarse. Aplicación votación Patrón E E G E E E E E E probabilidad de acierto Abstract Factory E E G G G G G G G Decorator E E G F G G G G F Iterator E E G F G F F G G 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 concejo. Página 42

63 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Modalidad de Profundización Resultados escrutinio Patrón E E G E E E E E E probabilidad de acierto Abstract Factory E E G G G G G G G Decorator E E G F G G G G F Iterator E E G F G F F G G 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 durante 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 lenguaje 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 complementado con la especificación de propiedad intelectual que se hizo de la propuesta completa donde 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 patrones 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ódigo 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 trabajando que se adhiera a la interface común de la aplicación. Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 43

64 Ingeniería de Sistemas Grupo de Investigación ISTAR PA 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 negocio. 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 registro electores comparten el mismo patrón GOF como de Web Services, de igual forma la aplicació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 estructura del patrón Service Factory y al lado derecho se aprecia la figura del patrón Business Process (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 44

65 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Modalidad de Profundización Application Application Capa Cliente InterfaceService Interface Business Activity BusinessProcessImpl Capa presentación ServiceFactory InterfaceBusinessProcess Capa Negocio Directory (ServiceLocator) BusinessActivityImpl LinkedListActivitySequence Capa persistencia ServiceImplA ServiceImplB 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: La clase Application con el patrón Intercepting Filter La clase InterfaceService con el patrón Front Controller La clase ServiceFactory con el patrón Service to worker La clase Directory con el patrón Service Locator Para el Business Process (composition) la clase Application con el patrón Intercepting Filter la clase InterfaceBusinessActivity con el patrón Front Controller la clase InterfaceBusinessProcess con el patrón Front Controller la clase BusinessProcessImpl con el patrón Dispatcher View La clase ServiceImplA y ServiceImplB con la clase BusinessActivityImpl con el patrón Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 45

66 Ingeniería de Sistemas Grupo de Investigación ISTAR PA 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 manera: Página 46

67 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Modalidad de Profundización 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 Intercepting Filter Entrega el control a CAPA DE CLIENTE Intercepting Filter Entrega el control a Front Controller Front Contoller 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 Controla procesamiento de interfaz gráfica Service To Worker CAPA DE PRESENTACIÓN Despacha control De procesamiento Liviano para que múltiples Usuarios puedan Acceder al sistema sin demoras Dispatcher View Accede a objetos de negocio Localiza Servicios Business Delegate Accede a lista de negocio Service Locator CAPA DE NEGOCIO Service Locator 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 sincrónico procesamiento Service Activator Transfer Object CAPA DE INTEGRACIÓN Encapsula datos Value List Handler Maneja la Granularidad a los Componentes De negocio Composite Entity Figura 15. Diseño detallado (nivel 2) del voto electrónico Página 47 Preparado por el Grupo Investigación Istar- Versión /03/2008

68 Ingeniería de Sistemas Grupo de Investigación ISTAR PA 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 interacció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 arquitectura de software ya diseñada y teniendo en cuenta aspectos como el material electoral (cartillas 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 experiencia 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 interconectados 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 continuación se presenta el modelo lógico de la base de datos para el proceso de inscripción de electores 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 atributos 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 corporación se da para los cargos a escoger que hayan: presidencia, referendos, consultas partidistas, 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 48

69 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Modalidad de Profundización Figura 16. Modelo lógico del proceso de inscripción de candidatos y electores Página 49

70 Ingeniería de Sistemas Grupo de Investigación ISTAR PA Figura 17. Modelo lógico del proceso de votación Página 50

71 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Modalidad de Profundización V PROTOTIPO Y VALIDACIÓN Según la ciencia basada en el diseño, la forma de instanciar el resultado propuesto es mediante 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 empresarial se interpretaron las vistas desarrolladas en Archimate y se mapearon mediante el modelado de Business Process Modeling Notation versión 2.0 (BPMN 2.0). A continuación se presentan 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 estables 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 seleccionado. Además, Bizagi permite la asignación de roles y usuarios para aumentar parámetros 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: Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 51

72 Ingeniería de Sistemas Grupo de Investigación ISTAR PA Figura 19. Inscripción del candidato El video del prototipo de interfaces se puede apreciar en los siguientes sitios web: 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 convenio 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 como 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 prevista. Según Kuechler [62], en la ciencia basada en el diseño, la relación de un artefacto diseñado con la teoría que lo soporta es de extensión y refinamiento. De allí que Gonzá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 Página 52