Sistema Electoral Nacional

Oficina Nacional de Procesos Electorales

Documento de Arquitectura del Sistema
<Nombre del Proyecto>
<Código del Proyecto>
Versión <x.x>

Elaborado por: Revisado por: Aprobado por:

Fecha: / / Fecha: / / Fecha: / /

<Nombre del Proyecto> Versión: <x.x>
Documento de Arquitectura del Sistema Fecha:<dd/mm/yyyy>
<Nombre del archivo>

HISTORIAL DE REVISIONES

Fecha de Fecha de
Versión Autor Descripción Revisado por
Elaboración Revisión
<Nombre de
la persona <Persona(s)
<x.x> que elabora <Detalles> <dd/mm/aa> que revisa(n) <dd/mm/aa>
el el documento
documento>

INDICE

© Oficina Nacional de Procesos Electorales
Confidencial Página 2 de 23
ONPE - 2008


1. INTRODUCCIÓN 4
1.1. Propósito 4
1.2. Alcance 4
1.3. Definiciones, acrónimos y abreviaturas 4
1.3.1. Definiciones 4
1.3.2. Acrónimos 4
1.3.3. Abreviaturas 4
1.4. Referencias 5
1.5. Visión General 5
2. VISTA GENERAL DE LA ARQUITECTURA 5
2.1. Capa de presentación 6
2.2. Capa de Lógica de Negocio 6
2.3. Capa de acceso a datos 6
3. RESTRICCIONES DE LA ARQUITECTURA 6
4. VISTA FUNCIONAL 8
4.1. Casos de Uso – Administración y Seguridad 8
4.2. Casos de Uso – Carga de Data Pre Electoral 9
5. VISTA LÓGICA DEL SISTEMA 10
5.1. Paquetes del Sistema 11
5.1.1. <Nombre del Paquete 1> 11
5.1.2. <Nombre del Paquete n> 11
5.2. <Nombre del Paquete 1> 11
5.3. <Nombre del Paquete n> 13
6. VISTA DE IMPLEMENTACIÓN 14
7. VISTA DE DESPLIEGUE 14
8. VISTA DE INTEGRACIÓN DEL SOFWTARE 15
8.1. Diagrama de Integración de Interfaces 15
8.2. Criterios para el diseño y selección de interfaces 15
8.3. Criterios de Integración del Software 15
8.4. Secuencia de Integración 16
8.5. Entorno Necesario para la Integración 16
9. DISEÑO DE LA ARQUITECTURA DE MÓDULOS DEL SISTEMA 22
9.1. Diseño de comunicación entre módulos 22
9.2. Interfaz del Usuario 22
10. VISTA DE DATOS 23
10.1. Modelo de Base de Datos Lógico y Físico 23
10.2. Diccionario de Datos 23
11. ESPECIFICACIÓN DE CONSTRUCCIÓN 23
11.1. Especificación del Entorno de Construcción 23
11.2. Definición de Componentes y Subsistemas de Construcción 23

DOCUMENTO DE ARQUITECTURA DEL SISTEMA

ONPE - 2008


Nota: Los puntos a los que se hace referencia en el presente documento, no
necesariamente deben ser aplicados, se desarrollarán de acuerdo al tipo de proyecto.
El texto encerrado en corchetes [ ] es sólo una referencia. Cabe resaltar que lo que
se encuentra de color azul es sólo un ejemplo.

1. INTRODUCCIÓN
[Describir de manera breve el contenido del documento, que incluya propósito,
alcance, definiciones, acrónimos, abreviaturas, referencias y la visión general de la
arquitectura del sistema.]

1.1. Propósito
[Proporcionar una visión general de la arquitectura del sistema, empleando
vistas en los diferentes aspectos del sistema.]

“Este documento tiene como propósito exponer la vista general de la
arquitectura de la Suite Electoral, para lo cual se utilizan diferentes vistas
que proporciona UML en el Rational Unified Process”

1.2. Alcance
[Describir de manera breve el alcance que tendrá la arquitectura del sistema
a desarrollar.]

“El alcance de este documento es presentar la base de la arquitectura del
sistema para la implementación de la Suite Electoral.

Este documento ha sido desarrollado en base al modelo de análisis y diseño
elaborado en Rational Rose.”

1.3. Definiciones, acrónimos y abreviaturas
[Proporcionar las definiciones, acrónimos y abreviaturas que se utilizarán en
el documento.]

1.3.1. Definiciones
[Definir las definiciones que se utilizaran en el desarrollo del
documento.]

1.3.2. Acrónimos
[Definir los acrónimos que se utilizarán en el desarrollo del
documento.]

1.3.3. Abreviaturas
[Definir las abreviaturas que se utilizarán en el desarrollo del
documento.]

ONPE - 2008


1.4. Referencias
[Elaborar una lista de los documentos que hacen referencia al diseño
Detallado del software DAS.]

“Los documentos que hacen referencia a la Arquitectura del Sistema del
<Nombre del Sistema> son:

Nº Nombre del Documento Código
1 Acta de Constitución del Proyecto AC-047- v.1.5
2 Plan de Gestión PG-047-v 1.0
3 Alcance del Proyecto AP-047-v 1.0
4 Reglas del Negocio RN-047-v 1.4
5 Reglamento del Voto Electrónico RVE-047-v 1.1
6 Especificación de Requerimientos del Software ERS-047-v 1.0
7 Especificación de Casos de Uso ECU-047-v 1.5

1.5. Visión General
[Describir de manera breve como esta organizado el documento.]

“El presente documento empieza por mostrar una vista general de la
arquitectura del sistema. Luego, se presenta la vista funcional que está
representada por el modelo de casos de uso. Más adelante, se muestra la
vista lógica del sistema que contiene el modelo de datos, donde están
incluidos los diagramas de clases y paquetes. Luego, la vista de
implementación que está representada mediante el diagrama de
componentes del sistema, la vista de despliegue...”

2. VISTA GENERAL DE LA ARQUITECTURA
[Realizar la distribución de la Arquitectura del Sistema, teniendo cuenta capas y
niveles de arquitectura.]

Ejemplo:

ONPE - 2008


La figura muestra la distribución de los módulos del software que tendrá el
sistema, además de brindar una visión general del sistema. En el gráfico, se
observa la distribución en tres capas de la arquitectura, las cuales se describen a
continuación:

2.1. Capa de presentación
En esta capa se encuentra la aplicación Web dedicada a la presentación de
resultados de la Suite Electoral, la cual estará conformada por las pantallas
de presentación al usuario, tales como: resumen de proceso, resumen
distrital, resultados en votos distrital, detalle del acta, avance de actas
procesadas,… Estas aplicaciones Web serán páginas PHP.

2.2. Capa de Lógica de Negocio
Esta capa provee todo lo que es la lógica del negocio, es decir la
funcionalidad del sistema, ya sea la Carga de Data Pre-Electoral,
Administración y Seguridad, Digitalización de Actas, Lotización y Digitación
de Actas, Reportes y Consultas, Registro de Omisos, y la Transmisión y
Recepción.

2.3. Capa de acceso a datos
Esta capa provee los servicios y conexiones a la base de datos requeridos
por la capa de lógica de Negocio. Por otro lado, el manejador de base de
datos utilizado para este sistema será Oracle 9i.

3. RESTRICCIONES DE LA ARQUITECTURA
[Describir los requerimientos de software que tienen un impacto significativo sobre
la arquitectura; por ejemplo: seguridad, privacidad de uso del producto,
portabilidad, distribución y reuso. También se puede describir las restricciones que
quizás apliquen en: la estrategia de diseño e implementación, herramientas de
desarrollo, estructura del equipo, cronograma, legal y otros.]

Por ejemplo:

Se han identificado los siguientes requerimientos no funcionales que definen las
metas y restricciones arquitectónicas:

1. Requerimientos no funcionales:

a. Estructura en capas de la arquitectura
La arquitectura del producto deberá diseñarse de acuerdo a la arquitectura
en 3-capas: Presentación (Web), Aplicación (HIS), Acceso a Datos
(Oracle).

b. Lenguaje de programación
El lenguaje de programación a emplear para el desarrollo de la capa de
presentación será el Microsoft Visual Basic .NET

ONPE - 2008


c. Interfases de integración con ATCA, Sistema de Ahorros DPAH,
Sistema de Recaudación RECA y TOLD
El tráfico de información con ATCA se realizará a través de componente
software implementado a través de la biblioteca para comunicación con
Host a través del Host Integration Server (HIS)

d. Interfases de integración con RENIEC
La comunicación con RENIEC se deberá realizar a través de dos
elementos, el primero WebSphere Business Integration (WBI)
específicamente a través de su componente de administración de colas MQ
Series; y el segundo el componente SIX/CT que actúa como gateway.

2. Riesgos Principales

a. R002 El uso de tecnología nueva podría ocasionar retrasos y/o baja
calidad del producto.
Debido a que no han existido experiencias anteriores respecto a la
generación de aplicativos en línea en Internet, así como teniendo en cuenta
que el personal no posee mucha experiencia en ese aspecto, se corre el
riesgo de no cumplir las metas señaladas y/o que el producto resultante no
tenga la calidad mínima exigible

b. R003 La poca o nula experiencia en el desarrollo de Sistemas que
involucren simultáneamente la utilización de recursos Hardware y
Software de plataforma HOST así como de la plataforma OPEN, podría
generar problemas de Integración y por tanto un pobre
aprovechamiento de recursos.
Debido a que el aplicativo utilizará tanto la plataforma HOST, como la
Plataforma OPEN, existe el riesgo de interacción o falta de integración
entre ambas, lo que redundaría en el incumplimiento de metas señaladas y/
o que el producto resultante no tenga la calidad mínima exigible.

3. Restricciones especiales

a. Estrategias de diseño e implementación
Se ha definido una arquitectura de capas que incluya una capa de
presentación, una capa de negocio, una capa de integración y una capa de
datos. Adicionalmente el sistema Pago de Servicios a través de Internet
(POLI) esta formado por dos subsistemas el sistema Principal y el Sistema
de Constancias. Esto significa que en cada una de las capas mencionadas
anteriormente tendrá implementaciones para ambas plataformas.

b. Código legado a ser considerado y demás.
Existen componentes que puede ser reusados, se han definido los
siguientes componentes como potenciales códigos a reutilizar:

• PCLVESNET
• DESASALDOS
• HBDESAPAGSERVINTERBDORAV4

ONPE - 2008


4. VISTA FUNCIONAL
[Realizar la distribución de los paquetes del sistema. A su vez, realizar una
descripción del modelo de casos de uso agrupados en paquetes.]

A continuación se muestra el diagrama del modelo de casos de uso agrupados en
paquetes.

El modelo de casos de uso se ha dividido en 8 paquetes para un mejor análisis, los
casos de uso del Módulo “Administración y Seguridad”, contiene los perfiles de los
usuarios de la Suite Electoral para la Consulta Popular de Revocatoria del
Mandato de Autoridades Municipales 2008; los casos de uso del Módulo “Carga de
Datos Pre-Electorales, que contiene la actualización de los datos iniciales en la
tablas maestras de la Suite Electoral; los casos de uso del Módulo “Lotización y
Digitación”, que permite el ingreso de las actas y resoluciones para llevar acabo
las elecciones; …

En las siguientes secciones se mostrará el modelo de casos de uso que están
incluidos en los paquetes “Casos de Uso – Administración y Seguridad”, “Casos de
Uso Carga de Data Pre Electoral”…, los cuales son de interés para la
implementación del Software. Así también, se detallará más sobre la funcionalidad
de estos casos de uso.

4.1. Casos de Uso – Administración y Seguridad
El objetivo de este módulo es asegurar que el sistema cuente con el
adecuado soporte en cuanto a seguridad y control de acceso a las
diferentes funcionalidades del sistema.

Se tiene definidos los siguientes parámetros de acceso al sistema:

• Permite tres (3) intentos de ingreso al sistema.
• La vigencia de la clave es de veinte (7) días.
• Se dará aviso al usuario tres (3) días antes de la expiración de su clave.

ONPE - 2008


• Permitirá cambiar el número de clave máximo diez (10) veces. De
requerirse un nuevo cambio deberá solicitarse la clave asociada a un PIN
(Personal Identification Number) de autorización a la oficina principal de
ONPE.
• La longitud de la clave es de ocho (8) caracteres con una letra como
mínimo en su contenido.
• La clave se almacena encriptada con una longitud de (16) caracteres
alfanuméricos.

Los parámetros de acceso y los perfiles son establecidos por la ONPE.

Administración y Seguridad - Modelo General

<<ext en d> >

Most rar Mód ul os Mostrar Usuarios Activos

Consultar Perfiles

Mostrar Parámetros de Acceso

Mantener Usuario

Asi gn ar Usua rios a Mo du lo

Usuario_Administrador Administrador_Nación

Ce rra r S esio ne s d e Usua rio

Usuario_Suite

Realizar Auditoria

Resta urar Ba se de Dat os
Ingresar a la Suite Electoral

Realizar Backup de Base de Datos

<<extend>>

Cerrar Centro de Cómputo Reaperturar Centro de Cómputo

4.2. Casos de Uso – Carga de Data Pre Electoral
El objetivo es permitir cargar la información Pre Electoral requerida para el
procesamiento de los votos.

La información Pre-electoral requerida proviene de:

• Padrón Electoral aprobado por el JNE.
• Relación de Listas, Símbolos y Candidatos de las Organizaciones
Políticas aprobadas y proporcionadas por la GGE.
• Estructuras de las ODPE: ubigeos de distritos y provincias que la
conforman, locales de votación, distribución de mesas y mesas
agrupadas – GPDE. Incluye mesas en el extranjero.
• Resultado del sorteo de miembros de mesa.

ONPE - 2008


El sistema permitirá un listado de todas las mesas correspondientes a los
ubigeos que conforman la ODPE, quebrado por departamento, provincia,
distritos, indicando los números de mesa (mesas de sufragio y mesas
agrupadas), cantidad de electores hábiles.

Datos Pre Electorales -
Modelo General

Import ar datos

<<include>>

Usuario_Administrador Administrador_Nación
Realizar puesta a cero

Generar Reportes

5. VISTA LÓGICA DEL SISTEMA
[Realizar una descripción de cada una de las vistas lógicas de la arquitectura del
sistema, tales como la descomposición de subsistemas y paquetes Para cada
paquete definir las responsabilidades de las clases.]

Nota: En el caso que el proyecto sea de gran magnitud listar y especificar los
objetivos y funcionalidad que comprenden cada uno de los paquetes. De lo
contrario realizar una breve descripción de cada caso de uso.

Datos Pre
Elect orales

Digitalización Presentación
de Act as Resultados

Transmisión y
Recepción
Administración y
Seguridad
Lotización y
Digitación

Registro de Reportes y
Omisos Consultas

ONPE - 2008


5.1. Paquetes del Sistema
5.1.1.<Nombre del Paquete 1>
[Breve descripción de la funcionalidad del paquete 1]

5.1.2.<Nombre del Paquete n>
[Breve descripción de la funcionalidad del paquete n]

5.2. <Nombre del Paquete 1>
[Breve descripción de la función del paquete 1.]

[Definir la responsabilidad que cumple cada clase del paquete 1. A su vez
capturar las clases que forman parte del mismo.]

[Para cada clase significativa del paquete, indique: nombre, breve
descripción, atributos y operaciones.]

5.2.1. <Caso de Uso 1>
1. <Clase 1>
• Clases
[Identificar un grupo de clases, teniendo en cuenta:

• Cada interfaz identificada en el análisis afecta en el diseño
con una clase que proporcione esa interfaz.
• El conjunto de clases del diseño, que puede modificarse
en función a la tecnología de desarrollo y mecanismos
genéricos de diseño.]

• Atributos de las clases
[Identificar y describir, una vez determinado el entorno de
desarrollo, los atributos de las clases.]

[Definir para cada atributo: tipo, formato y restricciones
asociadas.]

• Operaciones de las clases
[Definir las operaciones de cada clase de diseño.]

[Describir cada operación por: nombre, parámetros y
visibilidad (pública, privada, protegida).]

• Asociaciones y agregaciones
[Analizar la secuencia de mensajes entre los objetos
correspondientes en el diagrama de secuencia de los
escenarios.]

ONPE - 2008


[Definir las asociaciones, teniendo en cuenta:

• Características de la asociación: rol que desempeña,
multiplicidad, etc.
• Relaciones bidireccionales que se transforman en
unidireccionales, para simplificar la implementación del
sistema.
• Modelización de las rutas de acceso.]

5.2.2. <Caso de Uso n>
1. <Clase 1>
• Clases
[Identificar un grupo de clases, teniendo en cuenta:

• Cada interfaz identificada en el análisis afecta en el diseño
con una clase que proporcione esa interfaz.
• El conjunto de clases del diseño, que puede modificarse
en función a la tecnología de desarrollo y mecanismos
genéricos de diseño.]

• Atributos de las clases
[Identificar y describir, una vez determinado el entorno de
desarrollo, los atributos de las clases.]

[Definir para cada atributo: tipo, formato y restricciones
asociadas.]

ONPE - 2008


• Operaciones de las clases
[Definir las operaciones de cada clase de diseño.]

[Describir cada operación por: nombre, parámetros y
visibilidad (pública, privada, protegida).]

• Asociaciones y agregaciones
[Analizar la secuencia de mensajes entre los objetos
correspondientes en el diagrama de secuencia de los
escenarios.]

[Definir las asociaciones, teniendo en cuenta:

• Características de la asociación: rol que desempeña,
multiplicidad, etc.
• Relaciones bidireccionales que se transforman en
unidireccionales, para simplificar la implementación del
sistema.
• Modelización de las rutas de acceso.]

5.3. <Nombre del Paquete n>
[Breve descripción de la función del paquete n.]

[Definir la responsabilidad que cumple cada clase del paquete n. A su vez
capturar las clases que forman parte del mismo.]

[Para cada clase significativa del paquete, indique: nombre, breve
descripción, atributos y operaciones.]

ONPE - 2008


6. VISTA DE IMPLEMENTACIÓN
[Describir la estructura del modelo de implementación, la descomposición del
software entre capas y subsistemas del modelo de implementación.]

7. VISTA DE DESPLIEGUE
[Describir una o más configuraciones de redes de trabajo físicas (hardware), en el
que el software sea desplegado y ejecutado.]

ONPE - 2008


8. VISTA DE INTEGRACIÓN DEL SOFWTARE
8.1. Diagrama de Integración de Interfaces

8.2. Criterios para el diseño y selección de interfaces
[Identificar los criterios para el diseño y selección de interfaces que se debe
tener en cuenta para el desarrollo del sistema.]

Ejemplo:

Para la selección y el diseño de las diferentes alternativas de las interfaces
se evaluarán los siguientes criterios:

• Facilidad de Construcción
• Tiempo de Respuesta
• Otros

8.3. Criterios de Integración del Software
[Identificar los criterios de integración del software que deben tenerse en
cuenta.]

Ejemplo:

Para la óptima integración del Software se deberán tener que cumplir,
considerar y evaluar los siguientes criterios:
• Antes de realizar la integración todos los componentes deberán haber
pasado por pruebas unitarias.
• Antes de realizar la integración, todas las incidencias, errores u otras no
conformidades encontradas durante las pruebas unitarias deberán estar

ONPE - 2008


cerradas.
• Se deberá tener preparado los ambientes y entornos para la integración
(Entorno de Desarrollo o Entorno de Integración).
• Deberá haberse inicializado y migrado data consistente previa a la
integración.
• Otros Criterios que apoyen a que la integración resulte un éxito.

8.4. Secuencia de Integración
[Describir la secuencia adecuada para realizar la integración del software.]

Ejemplo:

Para que el Software se integre totalmente se seguirá la siguiente secuencia
de integración:

• Realizar las pruebas unitarias a todos los componentes desarrollados
(De todos los módulos).
• Levantar todos los errores e incidencias encontradas en las pruebas
unitarias (De todos los módulos).
• Realizar revisión de pares al código fuente y levantar las no
conformidades.
• Asegurarse que todos los componentes del Sistema estén
completamente corregidos (Realización de nuevas pruebas sobre los
errores encontrados).
• Validar que el entorno de integración este listo.
• Validar que la data haya sido migrada satisfactoriamente.
• Iniciar la integración
o Integrar Modulo 1 y Modulo 2 - Realizar pruebas de integración
entre ambos módulos.
o Integrar Modulo 1 y Modulo 2 y Modulo3 - Realizar pruebas de
integración entre módulos.
o Integrar Modulo 1 y Modulo 2 y Modulo n - Realizar pruebas de
integración entre módulos.
• Finalizada la Integración entre módulos, realizar la integración con
aplicativos externos al sistema en desarrollo.
o Integrar Sistema en desarrollo con Sistema Externo1 (Aplicativo
Externo) y Realizar Pruebas.
o Integrar Sistema en desarrollo con Sistema Externo2 (Aplicativo
Externo) y Realizar Pruebas.
• Finalmente realizar las pruebas del Sistema y luego de ellas las Pruebas
de Aceptación con los Usuarios Finales.

8.5. Entorno Necesario para la Integración
[Identificar y especificar los diversos entornos que se usarán o que están
involucrados en la integración del Software.]

ONPE - 2008


8.5.1. Entorno de Desarrollo

NOMBRE DEL SERVIDOR Serv_Desa
IP 1.1.15.50
DESCRIPCION Y OBJETIVO DEL SERVIDOR
En este servidor se almacenará el código fuente, en este entorno trabajaran los
desarrolladores. Aquí se realizarán las pruebas unitarias.
SERVICIOS
NOMBRE DE
APLICACIÓN FUNCIÓN INICIO USUARIO
SERVICIO
Por ejemplo:
Por Ejemplo: Presentación
Asynchronous Por ejemplo: basada en
Automático Adminservice
JavaScript + AJAX estándares
XML usando XHTML
y CSS
Local System
<Servicio 1> <Aplicación 1> <Función 1> Automático
Account
Local System
Account
Local System
<Servicio N> <Aplicación N> <Función 1> Automático
Account
CONFIGURACIÓN DE HARDWARE Y SOFTWARE
Microsoft ( R) Windows (R ) Server 200.Enterprise
Nombre del Sistema Operativo
Edition
Version 2.2.3790 Service Pack 2 Build 3790
Proveedor del Sistema Operativo Microsoft Corporation
Nombre del Sistema DEIPSBATCH
Proveedor del Sistema IBM
Modelo del Sistema -[865811Y]-
Tipo del Sistema X86 – based PC
Procesador x86 Family 6 Model 8 Stepping 3 Genuineintel - 664
BIOS Version/Date IBM ILKT44AUS, 20/09/2001
SMBIOS Version 2.1
Total de Memoria Física 2,047.49 MB
Promedio de Memoria Física 1.37 GB
Total de Memoria Virtual 3.86 GB
Promedio de Memoria Virtual 3.47 GB
Tipo de Adaptador Ethernet 802.3
Tipo de Producto IBM Netfinity Fault Tolerante PCI Adapter
Nombre del Servicio PCNet5
Dirección IP 10.203.32.9

ONPE - 2008


Máscara de Sub Red IP 255.255.255.0
Gateway IP 10.203.32.254
DHCP Enabled No
DHCP Server Not Available
MAC Address 00:06:29:D5:38:0F
Memory Address 0XFEB7FC00-0XFEB7FC1F
SO
FT
WA
RE
ADI
CIO
NA
L
US
ARI
OS
CO
N
PE
RMI
SO
S
AL
SE
RVI
DO
R
REL
ACI
ON
CO
N
OT
RO
S
SE
RVI
DO
RE
S

8.5.2. Entorno de Pruebas

NOMBRE DEL SERVIDOR Serv_Prueba
IP 1.1.15.50

SERVICIOS

ONPE - 2008


NOMBRE DE
SERVICIO
Por ejemplo:
XML usando XHTML
y CSS
Local System
Account
Local System
Account
Local System
Account
Edition
Version 2.2.3790 Service Pack 2 Build 3790
SMBIOS Version 2.1
Gateway IP 10.203.32.254
DHCP Enabled No

ONPE - 2008


SO
FT
WA
RE
ADI
CIO
NA
L
US
ARI
OS
CO
N
PE
RMI
SO
S
AL
SE
RVI
DO
R
REL
ACI
ON
CO
N
OT
RO
S
SE
RVI
DO
RE
S

8.5.3. Entorno de Producción

NOMBRE DEL SERVIDOR Serv_Prod
IP 1.1.15.50

SERVICIOS
NOMBRE DE
SERVICIO
Por ejemplo:
XML usando XHTML
y CSS
<Servicio 1> <Aplicación 1> <Función 1> Automático Local System

ONPE - 2008


Account
Local System
Account
Local System
Account
Edition
Versión 2.2.3790 Service Pack 2 Build 3790
SMBIOS Version 2.1
Gateway IP 10.203.32.254
DHCP Enabled No
SO
FT
WA
RE
ADI
CIO
NA
L
US
ARI

ONPE - 2008


OS
CO
N
PE
RMI
SO
S
AL
SE
RVI
DO
R
REL
ACI
ON
CO
N
OT
RO
S
SE
RVI
DO
RE
S

9. DISEÑO DE LA ARQUITECTURA DE MÓDULOS DEL SISTEMA
[Definir los módulos del sistema y la manera en que van a interactuar unos con
otros, intentando que cada módulo tenga una interfaz sencilla. Se pueden
identificar características o comportamiento comunes relacionados con accesos a
la base de datos, llamadas a módulos, gestión de errores, etc.]

9.1. Diseño de comunicación entre módulos
[Definir las interfaces entre módulos de cada subsistema, incluyendo tanto la
comunicación de control como los datos propios del sistema, de acuerdo a
las características del entorno tecnológico. A su vez, definir interfaces
sencillas que permitan reducir la complejidad de comunicación entre los
distintos módulos, especialmente con las comunicaciones entre
subsistemas.]

9.2. Interfaz del Usuario
[Realizar el diseño detallado de la interfaz de usuario, tanto de pantalla como
impresa, a partir de la Especificación de Requerimientos de Software, de
acuerdo al entorno tecnológico seleccionado. Se deberá revisar la
navegación entre ventanas y la información adecuada para la ejecución de
cada diálogo, identificando relaciones de dependencia entre los datos para
establecer una secuencia de presentación apropiada.]

ONPE - 2008


10. VISTA DE DATOS
[Describir la perspectiva de persistencia del sistema, incluyendo el modelo lógico y
físico de datos]

10.1. Modelo de Base de Datos Lógico y Físico
[Incluir el modelo lógico y físico de base de datos.]

BNSERV_EMPRESA

PK IDEMPRESA
BNSERV_SERVICIO
DESCRIPCION
PK IDSERVICIO
FULT_ACTUALIZA
PK,FK1 IDEMPRESA

DESCRIPCION
NSERVICIO BNSERV_TIPODOC
FULT_ACTUALIZA
PK IDTIPODOC

DESCRIPCION

BNSERV_AFILIACION

PK,FK1 IDSERVICIO
PK,FK1 IDEMPRESA BNSERV_OPERACION
PK NCUENTA
PK NSERVICIO PK,I1 FOPERACION
PK SECUENCIA PK NOPERACION

EMAIL GLOSA
FULTMODIFICACION FULT_ACTUALIZA
CODCIUDAD I2 NCUENTA
ESTADO I3 NDOCUMENTO
FELIMINACION NTRIBUTO
NREFERENCIA
IP
ABONADO
MONTO
MONTOME
FK1 IDTIPODOC

10.2. Diccionario de Datos
[Hacer referencia al Diccionario de Datos.]

11. ESPECIFICACIÓN DE CONSTRUCCIÓN
[Definir la construcción del sistema a partir de las unidades básicas de
construcción (componentes).]

11.1. Especificación del Entorno de Construcción
[Definir de manera general el entorno necesario para la construcción de los
componentes del sistema.]

[La especificación deberá comprender:

• Entorno tecnológico: hardware, software y comunicaciones.
• Herramientas de construcción, generadores de código, compiladores,
etc.
• Restricciones técnicas del entorno.
• Requisitos de operación y seguridad del entorno de construcción.]

11.2. Definición de Componentes y Subsistemas de Construcción
[Definir los componentes mediante la agrupación de elementos del diseño de
detalle de cada subsistema de diseño.]

ONPE - 2008

Sistema Electoral Nacional

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Sistema Electoral Nacional

Similaire à Sistema Electoral Nacional (20)

Plus de pierre R.

Plus de pierre R. (18)

Sistema Electoral Nacional