Sistema del 2011 - Trabajos de Grado de la facultad de...

Modelo de arquitectura de sistema para la implementación del voto electrónico en el municipio de Choachí Documento del modelo de Arquitectura de Sistema del voto electrónico en el municipio de Choachí Versión 5.

31

Documento del modelo de Arquitectura de Sistema del voto electrónico en el municipio de Choachí

September 2

2011

Este documento presenta el propósito de realizar esta arquitectura empresarial, el lenguaje que se utilizó para ilustrar los procesos de la línea estratégica del voto en la registraduría municipal de Choachí, y las vistas mediante las cuales se realizó la administración de los procesos de negocio de esta línea estratégica.

DOCUMENTO DE ARQUITECTURA EMPRESARIAL


33

Tabla de Contenido

1. Introducción 3

1.1. Propósito 3 1.2. Alcance 3 1.3. Definiciones, acrónimos y abreviaturas 3

1.3.1. Definiciones 3 1.3.2. Acrónimos 4

1.4. Referencias 4 1.5. Visión General del documento 4 2. Representación de la arquitectura empresarial 5 3. Metas y Restricciones de la arquitectura de sistema 5 3.1. Metas 5

3.2. Restricciones del Sistema 6 4. Capas 6 4.1. Capa de Negocio 6

4.2. Capa de Aplicación 6 4.3. Capa de Tecnología 7 5. Selección de Vistas 7

6. Actores 8 7. Stakeholders 8 8. Selección de Puntos de Vista 9

8.1. Manager 9 8.2. Administrador 10

8.3. Desarrollador 10 8.4. Usuario 11 9. Vista introductoria (Introductory viewpoint) 12

10. Vista de la organización (Organization viewpoint) 15

11. Vista de co-operación de actores (Actor co-operation viewpoint) 17 12. Vista de proceso de negocio (Business Process viewpoint) 18 13. Vista de co-operación del proceso de negocio (Business Process Co-operation viewpoint) 23

14. Vista de Comportamiento de aplicación (Application Behavior viewpoint) 25

15. Vista de Infraestructura (Infrastructure viewpoint) 28 16. Validación 29 16.1. Validación sintáctica realizada por el Ing. Jose C. Niño 30

16.2. Validación semántica realizada por el Registrador municipal de Choachí, Dr. Jorge A. Diaz 32 17. Conclusiones 32 18. Bibliografía 34

19. Anexo A. 0 19.1. Figura 1. Parte A. 0 19.2. Figura 1. Parte B. 1

19.3. Figura 1. Parte C. 2 19.4. Figura 2. 3 19.5. Figura 3. 4 19.6. Figura 4. Parte A. 5 19.7. Figura 4. Parte B. 6


33

19.8. Figura 4. Parte C. 7 19.9. Figura 5. Parte A. 8 19.10. Figura 5. Parte B. 9 19.11. Figura 5. Parte C. 10

19.12. Figura 5. Parte D. 11 19.13. Figura 6. Parte A. 12 19.14. Figura 6. Parte B. 13 19.15. Figura 6. Parte C. 14 19.16. Figura 6. Parte D. 15

19.17. Figura 7. 16


33

Documento de Arquitectura Empresarial

1. Introducción Uno de los desarrollos más importantes dentro de la construcción de una arquitectura de sistema es el desarrollo de la arquitectura empresarial, que permite representar la visión global del negocio y de sus procesos mediante la estructura de la empresa/organización, sirviendo de comunicación entre las personas involucradas en el desarrollo y ayudando a realizar diversos análisis que orienten el proceso de toma de decisiones. Este documento provee al usuario especializado una vista de la arquitectura empresarial del Sistema de votación electrónica para la Registraduría municipal de Choachí.

1.1. Propósito Este documento proporciona una descripción ideal de la arquitectura empresarial del sistema debido a la ausencia de la misma en la Registraduría Nacional del Estado Civil así como en sus sucursales, haciendo uso de diversos puntos de vista arquitectónicos para representar diversos aspectos del sistema. Se realiza con el fin de documentar las decisiones de arquitectura significativas que se han tomado en el sistema.

1.2. Alcance Este documento presenta la arquitectura empresarial en la cual estará basado el Sistema de voto electrónico, definiendo de manera detallada los procesos que se llevan a cabo en la registraduría en las diversas capas que éste presenta, así como una descripción de las componentes a utilizar.

1.3. Definiciones, acrónimos y abreviaturas Se brindan definiciones y acrónimos de términos usados en el presente documento que necesiten de alguna explicación para su correcta interpretación. 1.3.1. Definiciones

Archimate 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.


33

The Open Group Architecture Framework

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.

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

Vista - Archimate

se define como una parte de una descripción de la arquitectura que se ocupa de un conjunto de preocupaciones relacionadas y se dirige a un conjunto de actores

Punto de Vista - Archimate

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

Capa - Archimate

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.3.2. Acrónimos

TOGAF The Open Group Architecture Framework

ADM Architecture Development Method

UML Unified Modeling Language

BPM Business Process Management

1.4. Referencias Las referencias aplicables son:

1. Plan de Proyecto: Modelo de arquitectura de sistema para la implementación del voto electrónico en el municipio de Choachí.

2. Documento Technical estándar Archimate 1.0 specification. 3. Documento de Arquitectura de Software del modelo de arquitectura de

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

1.5. Visión General del documento En las secciones de este documento se detalla la arquitectura Empresarial ideal a desarrollar, ya que en la Registraduría municipal de Choachí como en la Registraduría Nacional del Estado Civil no se tiene un esquema del proceso de votación en ninguna forma Empresarial, así como tampoco una base para desarrollar una herramienta software. Para ello se presenta 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.


33

2. Representación de la arquitectura empresarial La Arquitectura a utilizar es la arquitectura empresarial de Archimate bajo los fundamentos ADM como una aproximación a la representación que permite realizar el Business Process Managamente (BPM). Se busca diseñar una aplicación integrada del proceso de votación, en la que solo se permitirá el acceso a los usuarios registrados en el sistema y a las áreas a las cuales tengan acceso autorizado. La arquitectura se muestra como una serie de puntos de vista -indicados con anterioridad-, usando la aplicación Enterprise Architect y empleando Archimate. La arquitectura se basará en el modelo ‘TOGAF ADM’ que representa Archimate, 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.

3. Metas y Restricciones de la arquitectura de sistema La meta principal de la arquitectura empresarial es mostrar los aspectos principales que influirán en la etapa de diseño y en el prototipado. Se tomarán en cuenta las siguientes metas y restricciones para el diseño de la arquitectura empresarial:

3.1. Metas

1. El Sistema de voto electrónico permitirá a los usuarios utilizar el sistema de votación desde los puntos tecnológicos (también llamados centros de votación) definidos por la Registraduría Nacional del Estado civil.

2. El Sistema de voto electrónico permitirá a los usuarios realizar de forma ágil su voto, evitándole las complicaciones ya manifestadas con respecto a la manipulación de tarjetones.

3. El Sistema de voto electrónico permitirá a los usuarios con discapacidad visual acceder al sistema de votación con mayor facilidad desde cualquier Terminal definido por la Registraduría Nacional del Estado civil, reduciendo la discriminación por discapacidad.

4. El Sistema de voto electrónico permitirá a la Registraduría municipal de Choachí (o en la que se implemente) mejorar el proceso electoral y la calidad de sus resultados.

5. Intentar reducir las falsas inscripciones de electores mediante el aumento parámetros de seguridad desde el proceso de inscripción.

6. Reducir notablemente (más de un 50%) los costos de papelería en los procesos electorales, ayudando con el ambiente evitando el uso indebido del mismo.

7. Otorgar elementos para la auditabilidad del proceso electoral mediante los continuos monitoreos y formas de trazabilidad de todo el proceso.


33

8. Mejorar la seguridad en todo el proceso electoral.

3.2. Restricciones del Sistema

1. Se manejara estrictamente la línea estratégica de Votación de la Registraduría Nacional del Estado Civil (para el caso será en el municipio de Choachí), siendo necesario reconocer que no se integrara dentro del modelo de arquitectura ningún otro proceso ajeno a esta línea estratégica.

2. El sistema de lector biométrico (dactilar) y de código de barras para el prototipado no se manejara en ningún momento debido a las altas políticas de seguridad que maneja la Registraduría Nacional del Estado Civil, por tanto las funciones que se necesiten de este sistema serán simuladas. Se espera que en caso de una posible implementación en la Registraduría, este problema sea solventado por la misma Registraduría y sus políticas internas.

3. El sistema en el momento que se implemente (o en su prototipado) debe ser de forma Web (como un Web Service) debido a las políticas para entes nacionales y a las políticas propias de la Registraduría Nacional del estado civil.

4. Capas En el lenguaje Archimate se definen tres capas para mostrar la totalidad de un proceso o línea estratégica de determinada organización. Estas capas son la capa de negocio, capa de aplicación y capa de tecnología

4.1. Capa de Negocio En la capa de negocio el objetivo es ilustrar como se ofrecen productos y servicios para clientes externos, los cuales son realizados en la organización por procesos de negocios ejecutados por actores de negocio. A nivel de la capa de negocio se manifiesta el dominio de la información, el dominio del producto, el dominio del proceso y el dominio de la organización. En el desarrollo de algún punto de vista de la capa de negocio los elementos de esta capa se representan con color amarillo.

4.2. Capa de Aplicación El objetivo de la capa de aplicación es enseñar cómo mediante aplicaciones (software) se da soporte a la capa de negocios mediante unos elementos llamados servicios de aplicación.

En la capa de aplicación se manifiesta el dominio de los datos y el dominio de la aplicación. En el desarrollo de algún punto de vista de la capa de aplicación los elementos de esta capa se representan con color azul.


33

4.3. Capa de Tecnología El objetivo de la capa de tecnología es mostrar mediante esquemas la infraestructura necesaria (hardware y comunicaciones) para soportar las aplicaciones ilustradas en la capa de aplicaciones mediante servicios de procesamiento, almacenamiento y comunicación. En la capa de aplicación se manifiesta el dominio de la infraestructura técnica. El color que se usa para los elementos de la capa de tecnología en los puntos de vista es el verde.

5. Selección de Vistas Además de las relaciones dentro de cada capa, hay relaciones que permiten la interacción entre las distintas capas, de allí que hallan puntos de vista que incluyan una o varias capas. Hay que aclarar que lo que Archimate maneja como puntos de vista1 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”. Las vistas que se van a presentar en el documento son los más significativos con base a la situación planteada en el planteamiento del proyecto y que son de mayor prioridad para la perspectiva de la ingeniería de sistemas.

Capa Vista (viewpoint según Archimate)

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

Negocio Organización (organization)

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

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

Negocio – Aplicación Co-operación del Proceso de negocio (Business Process co-operation)

Aplicación Comportamiento de la aplicación (Application behavior)

Tecnología Infraestructura (Infrastructure)

1 La definición de punto de vista está en la sección 1.3.1


33

6. 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 también.

Introductorio

Organización

Co-operación de actor

Co-operación de proceso de negocio

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.

Introductorio

Organizació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.

Introductorio

Organización



El juez solo participa como colaborador del registrador para realizar el proceso del escrutinio.

Introductorio

Organización



7. Stakeholders

Stakeholder Descripción Puntos de vista

Administrador

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.

Introductorio

Organización


Usuario El usuario es quien se interesa Introductorio


33

en conocer que mejoras le ofrecerá la arquitectura y con cuales procesos él podrá interactuar.


Manager 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

Introductorio

Organización



Desarrollador El desarrollador es la persona encargada de implementar las aplicaciones necesarias o sugeridas en la arquitectura empresarial

Comportamiento de la aplicación

Infraestructura

Proceso de negocio


8. Selección de Puntos de Vista Según la IEEE, un punto de vista es “una especificación de las convenciones para la construcción y el uso de una vista. Un patrón o plantilla a partir de la cual desarrollar vistas individuales estableciendo los propósitos y la audiencia para una vista y las técnicas para su creación y análisis”.

Los puntos de vista que se presentan en el documento son los siguientes:

8.1. Manager La vista Introductoria le permite conocer a grandes rasgos la magnitud del proyecto a desarrollar, identificar que procesos de gran escala dentro de la empresa van a ser afectados por el proyecto a desarrollar, y poder hacer estimaciones de costos de la implementación global del mismo. La vista de organización al Manager le sirve para conocer y/o verificar su personal interpretando el esquema de organigrama que tenga o que se desee implementar en la empresa de acuerdo a la línea estratégica que se vaya a trabajar. Sirve también para reconocer que parte de su personal debe interactuar con el proyecto permitiéndole planear que formación/capacitación deberá dar a su personal, aparte de conocer los costos que esto le representa a su organización. Además de esto, la vista de organización también le permite al manager conocer que actores pueden crearse o eliminarse de acuerdo a la intención del proyecto y pronosticar su presupuesto futuro a nivel de nómina para el funcionamiento de la línea estratégica sobre la que se va a trabajar la arquitectura de sistema.


33

La vista de co-operación de actor complementa al Manager en su percepción de conocimiento sobre las funciones y la interacción de los actores definidos y reconocidos en la vista de organización con actores externos a la empresa como los clientes, de esta forma puede reconocer si en los procesos de su empresa hay colaboraciones o dependencias con elementos externos a la organización o a la línea estratégica a trabajar. Para finalizar, la vista de Co-operación de proceso de negocio es importante para el Manager ya que le permite asignar administradores operacionales con responsabilidades sobre uno o varios procesos. También le permite al manager identificar relaciones causales entre los procesos de negocio principales de la empresa, además de facilitarle el mapeo de procesos de negocio en las funciones de negocio. En otras palabras, el manager es quien coordina cada servicio con un proceso, evitando el exceso de procesos que no son de la línea estratégica y que se ofrezcan servicios que no van identificados con los procesos actuales o a desarrollar.

8.2. Administrador La percepción del Administrador con respecto a la vista introductoria destaca la necesidad de saber el funcionamiento general de la línea estratégica, para entender posteriormente el funcionamiento del Sistema que se implemente, permitiéndole dar respaldo y revisión periódica a los procesos que dan vida a esa línea estratégica y de esta manera poder gestionar los problemas que se presenten en cualquier parte de la línea y con cualquier actor y/o rol. Ahora, la vista de organización se hace esencial para el administrador, ya que de esta depende que él sepa asignar a el respectivo actor un rol determinado de acuerdo a las funciones que realice sobre la línea estratégica o un proceso definido, de allí que sea importante que el administrador pueda tener claro y en cualquier momento el concepto de competencias, autoridades y responsabilidades de cada actor y/o rol. El punto de vista que puede ofrecer el administrador sobre la vista de Co-operación de proceso de negocio es el de autorizaciones de interacción de un proceso de negocio por los mismos roles o actores, ya que el administrador debe reconocer como se da la realización de los servicios por parte de los procesos de negocio y garantizar que se cumplan los procesos bajo los parámetros establecidos por el Manager. Además, le permite solicitar indicadores para realizar monitoreos continuos o discretos sobre cada proceso.

8.3. Desarrollador Desde la vista del proceso de negocio la opinión del desarrollador debe ser tenida en cuenta, ya que en esta vista es donde se define exactamente cada subproceso y tarea que se debe realizar para cumplir con determinado proceso, de allí que su aporte deba ser tenido en cuenta y tenga peso a la hora


33

de la toma de decisiones, ya que la complejidad con que quede definido cualquier proceso será circunstancial para poder desarrollarlo e implementarlo en algún software. Además, desde la vista de proceso de negocio, el desarrollador empieza a tener en cuenta la clase de archivos que pueden ser requeridos o que van a ser reemplazados de formatos manuales a ser automatizados. El punto de vista que ofrece el desarrollador sobre la vista de comportamiento de la aplicación es obligatoria y esencial, pues desde esta vista es donde se une la arquitectura empresarial con la arquitectura de software. De ahí que recaiga el peso sobre el desarrollador sobre lo que se comprometerá a hacer, ya que es él quien decidirá sobre cómo deben quedar desarrolladas e implementadas las aplicaciones que deben dar soporte no solo a los procesos de negocio sino también a las reglamentaciones estatales para el caso de la Registraduría. A nivel de Infraestructura, es igualmente obligatorio y esencial el punto de vista del desarrollador, ya que basado en las aplicaciones que el piense desarrollar necesitara el entorno adecuado para ejecutar e implementar su software, por eso se hace forzoso que esta decisión al menos a nivel de diseño y estructuración la tome el desarrollador. Ahora, aunque el desarrollador solicitará lo ideal, la decisión final debe obtenerse por consenso entre el desarrollador y el Manager, ya que aunque la infraestructura debe cumplir con los requerimientos solicitados para dar vida a la arquitectura empresarial, la empresa también debe decidir sobre los recursos previstos para el proyecto. Desde la vista Co-operación de actor, el punto de vista del desarrollador es poco influyente pero igualmente necesaria, ya que si bien es cierto que él no puede intervenir en las interacciones que se plantean allí, si debe tener en cuenta las mismas para poder definir las respectivas sesiones y perfiles de usuario que harán parte de las aplicaciones que tenga que desarrollar, y que permitirán posteriormente al administrador asignar a los empleados que trabajen el sistema desarrollado para la línea estratégica.

8.4. Usuario El punto de vista del usuario sobre la vista introductoria es esencial ya que el usuario primero colabora en el reconocimiento de elementos diarios que identifican los procesos de la línea estratégica en general además de los factores de las actividades o tareas que él realiza en ciertos procesos mejorando el diseño de vista que se realice con el Manager; y segundo, no será un factor de imposición el desarrollo de este proyecto ya que el hecho de poder interactuar con esta vista le permitirá entender la necesidad del por qué se hacen las mejoras y como su papel se verá dentro de la nueva organización. El punto de vista del usuario con respecto a la co-operación de proceso de negocio se refleja en el reconocimiento y validación de los servicios que realmente son usados por él y que previamente han sido identificados por el Manager; de allí que la opinión del usuario sea importante para reafirmar la


33

realidad de implementar o sugerir cambiar los servicios y sus procesos en la vista de co-operación de procesos de negocio principalmente y a la vez como evento de cambio sobre la vista de procesos de negocio

9. 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. Cada elemento tiene una descripción que especifica la funcionalidad que representa en la organización. A grandes rasgos en el punto de vista introductorio se puede apreciar los procesos que pueden ser automatizados y reducir tiempos y falencias.

Fig. 1: Vista introductoria. La figura 1 se puede ver completa en el Anexo A. 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í. Mostrando los puntos donde al usar tecnología como en este caso Software se puede colocar parámetros de seguridad mayores a los actuales.

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


33

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


33

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.

c. Registrador El actor registrador ejerce como veedor y como la persona encargada de ejecutar el sistema en los procesos de inscripción candidatos e inscripción elector. 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. 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í.


33

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.

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).

10. 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.


33

Fig. 2: Vista de la organización. La figura 2 se puede ver completa en el Anexo A. 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)

La estructura se ve representada por el registrador nacional quien podría ejercer casi todas las funciones (excepto las de back office, 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


33

transparente con la gente encargada del back office ya que ellos, de igual forma deben tener en cada municipio un actor para servir de apoyo. Aparte de la gente de back office, 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.

11. 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.

Fig. 3: Vista de co-operación de actores. La figura 3 se puede ver completa en el Anexo A. 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. 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


33

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.

12. 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.

Fig. 4: Vista de proceso de negocio. La figura 4 completa la pueden ver en el anexo A. 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


33

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


33

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.

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.


33

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. 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


33

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


33

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.

13. 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.

Fig. 5: Vista de co-operación del proceso de negocio. La figura 5 completa la pueden ver en el anexo A. 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 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


33

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.

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. 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 actor al elector, el cual interactúa con 2 servicios que tienen el soporte de este proceso: servicio de Registrar votación y servicio de entregar certificado votación.


33

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.

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.

14. Vista de Comportamiento de 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.

Fig. 6: Vista de comportamiento de la aplicación. La figura 6 completa la pueden ver en el anexo A.


33

Hay que anotar, que las aplicaciones que se desarrollen serán tipo Web Services debido a las políticas del gobierno nacional para cualquier ente del mismo.

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.

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.


33

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 subfunciones más: votación alcaldía y votación concejo. La subfunció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 subfunció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. La subfunció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


33

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.

15. 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í.

Fig. 7: Vista de co-operación del proceso de negocio. La figura 7 completa la pueden ver en el anexo A. 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.


33

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.

16. Validación 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 [1] 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 [2] 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 [3], 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 [3], 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 la evaluación de los artefactos mediante el suministro de un ambiente artificial para probar su utilidad potencial y por lo tanto la validación de la teoría subyacente

Al ser la forma de dar certeza a una solución propuesta, la validación es requerida en normas sobre sistemas de gestión de la calidad [4], sobre software (ver documento de arquitectura de software) y sobre los procesos de negocio una empresa [5]. Por último, Khatri et. Al, proponen un concepto de validación donde examinaron los efectos del conocimiento del dominio de los sistemas de información y el conocimiento del dominio de aplicación de los mismos en diferentes tipos de tareas de comprensión de esquema: tareas de comprensión sintáctica y semántica y el esquema basado en tareas de resolución de problemas [6]. Para el desarrollo de su estudio, utilizaron la teoría del ajuste cognitivo para establecer las diferencias teóricas en el papel del conocimiento del dominio de aplicación entre los diferentes tipos de tareas de comprensión del esquema


33

La parte sintáctica busca evaluar el tema a la raíz del concepto, es decir, la teoría y metodología; mientras que la parte semántica busca evaluar el tema desde los efectos e implicaciones prácticos y reales del tópico a validar. Cabe aclarar que esta validación semántica es distinta de la que promueve Weber et. al [7]. La última parte, la del esquema basado en tareas de resolución de problemas busca encontrar y evaluar la relación indirecta entre la representación del problema y los requerimientos de una tarea. Como resultado de este estudio, Khatri et al concluyen que mientras el conocimiento del dominio es importante para resolver todo tipo de esquemas conceptuales para la resolución de tareas en ámbitos de aplicación conocidos y desconocidos, la función de los conocimientos del dominio de aplicación surten efecto dependiendo del tipo de tarea bajo investigación. De allí, que sea importante entender que el punto de vista del aspecto real y cotidiano del posible uso de la solución otorgado por gente que lo vaya a emplear o utilizar es un gran complemento del punto de vista de validación de la solución mediante el proceso científico. Para este proyecto se decidió emplear parte de la metodología de validación de Khatri et. al [6] ya que permite analizar de dos formas compuestas la arquitectura empresarial. La validación sintáctica se complementó con el esquema de validación de modelos de madurez de arquitecturas empresariales, el cual fue realizado por un experto en el área de arquitectura empresarial, el Ing. Jose C. Niño; mientras que la validación semántica se complementó con el esquema de validación por un experto quien para este proyecto es el Registrador Municipal de Choachí, Dr. Jorge A. Diaz.

16.1. Validación sintáctica realizada por el Ing. Jose C. Niño Buenos días Daniel, Primero que todo, es necesario entender que los modelos de madurez de arquitectura Empresarial evalúan el nivel de capacidad que tiene una organización, para controlar y gerenciar proyectos de este tipo. Por esta razón muchos de los elementos de un modelo de madurez se pueden evaluar solamente cuando el proyecto se encuentra en desarrollo o implementación. En el modelo de madurez que propone el Carnegie-Mellon, el estado actual de su proyecto puede evaluarse contra los parámetros del nivel 1 de Arquitectura Empresarial, el cual se llama Estado inicial. Dentro de este nivel, Se evalúan: Arquitectura Empresarial: Se debe garantizar que las definiciones se encuentren acordadas: Dentro del documento las definiciones se encuentran especificadas y claramente documentadas, generalmente las definiciones de los elementos las realizan los líderes funcionales. Repositorio de Arquitectura Empresarial:


33

En este nivel puede que solamente el equipo de Arquitectura Empresarial tenga acceso al Repositorio, siempre y cuando le brinde información al proyecto: Dentro del documento se muestra claramente la notación y los puntos de vista (Archimate), los cuales especificaron como insumo para el desarrollo de las aplicaciones. Proceso de desarrollo de Arquitectura Empresarial: En este nivel es suficiente con que el proceso sea utilizado por el equipo de Arquitectura Empresarial: Dentro del documento se especifica que el proceso de desarrollo se Arquitectura se realizará utilizando la metodología ADM y el Framework TOGAF. Objetivo de la Arquitectura Empresarial: En este nivel se deben tener claros los dominios de los servicios, los principios y tener un grado de detalle general de los elementos de la arquitectura Empresarial: Dentro de los puntos de vista que se elaboraron dentro del documento, se pueden observar los servicios planteados a nivel negocio, aplicaciones e infraestructura necesarios para continuar con el proceso de desarrollo de la Arquitectura. En conclusión, considero que la propuesta actual de proyecto de Arquitectura Empresarial se encuentra en la etapa inicial y que es un buen insumo para el desarrollo del mismo. Le recomiendo que haga énfasis en puntos de vista en los cuales pueda detallar un poco más aspectos de seguridad de la solución y que el cálculo de los costos sea justificado por una metodología que le permita tener más claros los valores esperados del proyecto (Especialmente para el desarrollo de las Aplicaciones). Por otra parte, es necesario que el municipio o el líder del proyecto tenga en cuenta que necesita un repositorio para el proyecto y herramientas que soporten TOGAF, Archimate y los elementos de Arquitectura y diseño de Software necesarios para la Arquitectura, diseño, desarrollo y mantenimiento de los elementos que definan (tanto Arquitectura empresarial, como de Software). Con respecto a su solicitud de dar una calificación a cada uno de los siguientes elementos, considero que deben tener la siguiente nota. -Coherencia en los conceptos de arquitectura empresarial (5.0) Los conceptos de Arquitectura expuestos en el documento concuerdan con los definidos en los estándares internacionales.

-Representación de los Procesos del voto de la registraduría municipal de choachi (5.0) Aunque no conozco los procesos definidos por el municipio (El cual debe realizar la validación), se encuentran correctamente diseñados y documentados desde el punto de vista del lenguaje de notación.

-Contenido (4.5) Aunque desde el punto de vista de notación de las vistas y puntos de vista el documento es completo, creo que puede mejorarse con elementos de la metodología y del Framework de Arquitectura Empresarial.

-Calidad del documento.(4.8) Aunque considero que le faltan algunos de los elementos relacionados en el numeral anterior, la calidad del documento presentado es alta.


33

Cordialmente, José Niño.

16.2. Validación semántica realizada por el Registrador municipal de Choachí, Dr. Jorge A. Diaz Choachí, Martes 6 de diciembre de 2011. Ingeniero Daniel Yesid Cáceres Rincón: Reciba Cordial Saludo. Analizando el documento de arquitectura empresarial con respecto al funcionamiento y análisis de los procesos de la registraduría municipal para el voto, presento la validación solicitada en los parámetros asignados por el Ingeniero Daniel Cáceres: -Identificación y Representación de la registraduría municipal dentro del documento: (4.8) El documento representa una situación futura de la registraduría municipal manteniendo su misión y visión, sin vulnerar su identidad ni perder su esencia con la propuesta enseñada. -Identificación y Representación de los Procesos del voto dentro del documento: (5.0) Dentro del contenido del documento se aprecia claramente los procesos actuales, los sugeridos y la función de los mismos propuestos por el ingeniero; Manteniendo coherencia con lo que el ingeniero identifico como línea estratégica del voto electrónico dentro de su propuesta. -Contenido del documento: (4.8) El contenido y tamaño del documento es adecuado para la explicación de la propuesta de arquitectura empresarial desarrollada por el ingeniero Daniel Cáceres -Calidad del documento: (5) El documento es coherente en todas sus descripciones sin llegar a ser demasiado extenso. La calidad desde el punto de vista gramatical y conceptual es correcta. -Claridad del documento: (4.8) El documento de arquitectura empresarial presenta la descripción clara de todos los elementos contenidos sin necesidad de recurrir a tecnicismos de difícil comprensión para ubicar a cualquier lector que no sea solo del área de ingeniería. Atentamente, Jorge Alberto Díaz Duque Registrador Municipal del Estado Civil Municipio de Choachí

17. Conclusiones El desarrollo de la arquitectura empresarial en un ente como la registraduría municipal de Choachí es la representación de la alineación de la tecnología con los procesos cotidianos de la sociedad, permitiendo ser un elemento de mejoría


33

y diferenciador propio de una entidad con ganas de progresar en la calidad de sus servicios. Esta arquitectura empresarial permitirá a la registraduría municipal de Choachí ser dinámica con el paso del tiempo, ya que en la actualidad no se había realizado ningún tipo de metodología para reconocer los procesos, actores y elementos que hacen parte de la línea estratégica de votación, además de realizar modificaciones en sus procesos sin sufrir grandes traumas, esto se debe a que la arquitectura empresarial da la ventaja de reconocer fácilmente los procesos y evitar colapsar toda una línea estratégica. Al ser una propuesta de proyecto no representa ningún compromiso de la Registraduría municipal con la sociedad y por tanto no tiene repercusiones económicas. Dado el caso de implementarlo, efectivamente las implicaciones que trae un proyecto como esto serán elevadas para el municipio, ya que si se aprueba de forma local y no nacional la registraduría municipal correría con todos los gastos sobre el presupuesto asignado, de allí que se pueda mostrar implicaciones fuertes en 3 aspectos: costos, entrenamiento y recursos.

A nivel de costos: se puede desglosar en 2 tipos de costos: desarrollo e infraestructura

o Desarrollo: Los costos a nivel de la sola arquitectura empresarial puede ser valorado como una consultoría y estaría entre los $50.000.000 y $100.000.000 de pesos. Los costos del desarrollo de la aplicación estarían alrededor de los $250.000.000 de pesos.

o Infraestructura: la adquisición de equipos de cómputo para la oficina de la registraduría municipal de Choachí no sería muy cara ya que con 2 o 3 equipos sería suficiente; este valor no pasaría de los $ 4.500.000 de pesos donde fueran 3 equipos. La aplicación MORPHOCHECK no representa ningún costo de adquisición porque ya la posee, lo único a registrar como costos es lo que cobre la empresa SAGEM por permitir el uso de los archivos especificados en la vista de comportamiento de la aplicación. La adquisición de un mainframe más las respectivas licencias de los software necesarios representaría una inversión aproximada a los $25.000.000 de pesos, el pago mensual de internet (dado que para el momento RAVEC no esté en funcionamiento) sería de alrededor $250.000 pesos y los costos de la infraestructura de red en la oficina de la registraduría municipal alrededor de los $200.000 pesos. Ahora, dado que es un proyecto propio de la registraduría municipal en el momento de la votación puede haber patrocinio de la registraduría nacional o no, dado el caso, para Choachí, se manejan 38 mesas de votación, lo que representaría comprar 38 equipos de cómputo, que se compren con las especificaciones requeridas por un precio de $1.500.000 cada uno, sería un costo de $57.000.000 de pesos, más el mainframe para el sitio de votación (votoframe) donde se almacenaran los datos con las respectivas licencias con un costo de alrededor a los $25.000.000 de pesos. Además, hay que agregarle lo que costaría realizar la


33

conexión entre esos equipos al votoframe y a internet para hacer replicación del votoframe al mainframe que estará en la registraduría, lo que representaría un costo alrededor de los $10.000.000 de pesos durante la jornada electoral. Además de esto, hay que sumar los costos de los nuevos actores a nivel de back office que se deben tener (aproximadamente $2.000.000 de pesos por actor por mes).

A nivel de entrenamiento: La implicación del nivel de entrenamiento no solo va ligado a quienes operaran el sistema sino a los actores nuevos que ingresen a la empresa como parte de la reestructuración que se hace en la arquitectura empresarial. El entrenamiento de los usuarios iría dentro de la entrega del software funcionando. Los costos extra estarían si se presenta cambio de personas/actores en la registraduría municipal y estos se establecerían de mutuo acuerdo entre el registrador y el contratista.

A nivel de recursos: los recursos necesarios serán todos los especificados en la vista de infraestructura más los relacionados con el consumo de servicios de los equipos (luz e internet). Hay que hacer la salvedad que no entran los gastos de alquiler de planta física ya que eso es obligatorio de cada registraduría tener una sede.

Basados en la validación semántica del experto, se puede apreciar que desde el punto de vista del registrador se cumple con la identificación clara de los procesos y no se omite ninguno dentro de la concepción de la solución tanto empresarial como previa del software. Como trabajo futuro se espera que basado en la arquitectura empresarial se continúe con el diseño del software (incluido en la vista de comportamiento de la aplicación) que dará soporte a los procesos y la adquisición de los equipos para la fase final de implementación (elementos identificados en la vista de infraestructura). Al ser este documento base de un proyecto de grado, la etapa de la vista de comportamiento de aplicación se realizará como un prototipo de interfaces de usuario, mientras que para la vista de infraestructura no se adquirirá ningún equipo sino que se hará simulado debido a que la entrega software será de un prototipo. Además de eso, se espera que a quien le interese el tema pueda seguir refinando el modelo de arquitectura empresarial de la registraduría y agregarle procesos paralelos de otra línea de estrategia.

18. Bibliografía [1] EURACHEM. The Fitness for Purpose of Analytical Methods. A Laboratory Guide to Method Validation and Related Topics. EURACHEM Guide. 1998. Disponible en http://www.eurachem.ul.pt/. [2] Sistemas de gestión de la calidad – Principios y vocabulario. NMX-CC-9000-IMNC-2001. 2001


33

[3] Gonzalez, Rafael A. "Validation of Crisis Response Simulation within the Design Science Framework". ICIS 2009 Proceedings. Paper 87. 2009. http://aisel.aisnet.org/icis2009/87 [4] Sistemas de gestión de la calidad – Requisitos. NMX-CC-9001-IMNC-2001. 2001 [5] Majewski, M., Han, Q., Wurster, A. “Business Process Validation”. University of Augsburg. 2009 [6] Khatri, V., Vessey, I., Ramesh, V., Clay, P., Park, S. “Understanding conceptual schemas: exploring the role of application and IS Domain knowledge”. Information Systems Research. Vol. 17, Number 1. Pp: 81-99. 2006. [7] Weber, I., Hoffmann, J., Mendling, J. “Semantic Business Process Validation”. In Proc. of International workshop on Semantic Business Process Management. 2008.


31

19. Anexo A.

19.1. Figura 1. Parte A.


33

19.2. Figura 1. Parte B.


33

19.3. Figura 1. Parte C.


33

19.4. Figura 2.


33

19.5. Figura 3.


33



33

19.12. Figura 5. Parte D.


33



33

19.16. Figura 6. Parte D.


33

19.17. Figura 7.

Sistema del 2011 - Trabajos de Grado de la facultad de...

Documents

Transcript of Sistema del 2011 - Trabajos de Grado de la facultad de...