Arquitectura del sistema

8,798 views

Published on

guía de arquitectura del sistema

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
8,798
On SlideShare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
375
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Arquitectura del sistema

  1. 1. 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: / /
  2. 2. <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 deVersió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
  3. 3. <Nombre del Proyecto> Versión: <x.x>Documento de Arquitectura del Sistema Fecha:<dd/mm/yyyy><Nombre del archivo>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 52. 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 63. RESTRICCIONES DE LA ARQUITECTURA 64. VISTA FUNCIONAL 8 4.1. Casos de Uso – Administración y Seguridad 8 4.2. Casos de Uso – Carga de Data Pre Electoral 95. 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> 136. VISTA DE IMPLEMENTACIÓN 147. VISTA DE DESPLIEGUE 148. 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 169. 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 2210. VISTA DE DATOS 23 10.1. Modelo de Base de Datos Lógico y Físico 23 10.2. Diccionario de Datos 2311. 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 © Oficina Nacional de Procesos Electorales Confidencial Página 3 de 23 ONPE - 2008
  4. 4. <Nombre del Proyecto> Versión: <x.x>Documento de Arquitectura del Sistema Fecha:<dd/mm/yyyy><Nombre del archivo>Nota: Los puntos a los que se hace referencia en el presente documento, nonecesariamente 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 quese 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.] © Oficina Nacional de Procesos Electorales Confidencial Página 4 de 23 ONPE - 2008
  5. 5. <Nombre del Proyecto> Versión: <x.x>Documento de Arquitectura del Sistema Fecha:<dd/mm/yyyy><Nombre del archivo> 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: © Oficina Nacional de Procesos Electorales Confidencial Página 5 de 23 ONPE - 2008
  6. 6. <Nombre del Proyecto> Versión: <x.x>Documento de Arquitectura del Sistema Fecha:<dd/mm/yyyy><Nombre del archivo> 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 © Oficina Nacional de Procesos Electorales Confidencial Página 6 de 23 ONPE - 2008
  7. 7. <Nombre del Proyecto> Versión: <x.x>Documento de Arquitectura del Sistema Fecha:<dd/mm/yyyy><Nombre del archivo> 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 © Oficina Nacional de Procesos Electorales Confidencial Página 7 de 23 ONPE - 2008
  8. 8. <Nombre del Proyecto> Versión: <x.x>Documento de Arquitectura del Sistema Fecha:<dd/mm/yyyy><Nombre del archivo>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. © Oficina Nacional de Procesos Electorales Confidencial Página 8 de 23 ONPE - 2008
  9. 9. <Nombre del Proyecto> Versión: <x.x>Documento de Arquitectura del Sistema Fecha:<dd/mm/yyyy><Nombre del archivo> • 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. © Oficina Nacional de Procesos Electorales Confidencial Página 9 de 23 ONPE - 2008
  10. 10. <Nombre del Proyecto> Versión: <x.x>Documento de Arquitectura del Sistema Fecha:<dd/mm/yyyy><Nombre del archivo> 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 Reportes5. 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 © Oficina Nacional de Procesos Electorales Confidencial Página 10 de 23 ONPE - 2008
  11. 11. <Nombre del Proyecto> Versión: <x.x>Documento de Arquitectura del Sistema Fecha:<dd/mm/yyyy><Nombre del archivo> 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.] © Oficina Nacional de Procesos Electorales Confidencial Página 11 de 23 ONPE - 2008
  12. 12. <Nombre del Proyecto> Versión: <x.x>Documento de Arquitectura del Sistema Fecha:<dd/mm/yyyy><Nombre del archivo> [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.] © Oficina Nacional de Procesos Electorales Confidencial Página 12 de 23 ONPE - 2008
  13. 13. <Nombre del Proyecto> Versión: <x.x>Documento de Arquitectura del Sistema Fecha:<dd/mm/yyyy><Nombre del archivo> • 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.] © Oficina Nacional de Procesos Electorales Confidencial Página 13 de 23 ONPE - 2008
  14. 14. <Nombre del Proyecto> Versión: <x.x>Documento de Arquitectura del Sistema Fecha:<dd/mm/yyyy><Nombre del archivo>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.] © Oficina Nacional de Procesos Electorales Confidencial Página 14 de 23 ONPE - 2008
  15. 15. <Nombre del Proyecto> Versión: <x.x>Documento de Arquitectura del Sistema Fecha:<dd/mm/yyyy><Nombre del archivo>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 © Oficina Nacional de Procesos Electorales Confidencial Página 15 de 23 ONPE - 2008
  16. 16. <Nombre del Proyecto> Versión: <x.x>Documento de Arquitectura del Sistema Fecha:<dd/mm/yyyy><Nombre del archivo> 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.] © Oficina Nacional de Procesos Electorales Confidencial Página 16 de 23 ONPE - 2008
  17. 17. <Nombre del Proyecto> Versión: <x.x>Documento de Arquitectura del Sistema Fecha:<dd/mm/yyyy><Nombre del archivo> 8.5.1. Entorno de DesarrolloNOMBRE DEL SERVIDOR Serv_DesaIP 1.1.15.50DESCRIPCION Y OBJETIVO DEL SERVIDOREn este servidor se almacenará el código fuente, en este entorno trabajaran losdesarrolladores. Aquí se realizarán las pruebas unitarias.SERVICIOS NOMBRE DE APLICACIÓN FUNCIÓN INICIO USUARIO SERVICIO Por ejemplo:Por Ejemplo: PresentaciónAsynchronous Por ejemplo: basada en Automático AdminserviceJavaScript + AJAX estándaresXML usando XHTML y CSS Local System<Servicio 1> <Aplicación 1> <Función 1> Automático Account Local System<Servicio 2> <Aplicación 2> <Función 2> Automático 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.EnterpriseNombre del Sistema Operativo EditionVersion 2.2.3790 Service Pack 2 Build 3790Proveedor del Sistema Operativo Microsoft CorporationNombre del Sistema DEIPSBATCHProveedor del Sistema IBMModelo del Sistema -[865811Y]-Tipo del Sistema X86 – based PCProcesador x86 Family 6 Model 8 Stepping 3 Genuineintel - 664BIOS Version/Date IBM ILKT44AUS, 20/09/2001SMBIOS Version 2.1Total de Memoria Física 2,047.49 MBPromedio de Memoria Física 1.37 GBTotal de Memoria Virtual 3.86 GBPromedio de Memoria Virtual 3.47 GBTipo de Adaptador Ethernet 802.3Tipo de Producto IBM Netfinity Fault Tolerante PCI AdapterNombre del Servicio PCNet5Dirección IP 10.203.32.9 © Oficina Nacional de Procesos Electorales Confidencial Página 17 de 23 ONPE - 2008
  18. 18. <Nombre del Proyecto> Versión: <x.x>Documento de Arquitectura del Sistema Fecha:<dd/mm/yyyy><Nombre del archivo>Máscara de Sub Red IP 255.255.255.0Gateway IP 10.203.32.254DHCP Enabled NoDHCP Server Not AvailableMAC Address 00:06:29:D5:38:0FMemory 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 PruebasNOMBRE DEL SERVIDOR Serv_PruebaIP 1.1.15.50DESCRIPCION Y OBJETIVO DEL SERVIDORSERVICIOS © Oficina Nacional de Procesos Electorales Confidencial Página 18 de 23 ONPE - 2008
  19. 19. <Nombre del Proyecto> Versión: <x.x>Documento de Arquitectura del Sistema Fecha:<dd/mm/yyyy><Nombre del archivo> NOMBRE DE APLICACIÓN FUNCIÓN INICIO USUARIO SERVICIO Por ejemplo:Por Ejemplo: PresentaciónAsynchronous Por ejemplo: basada en Automático AdminserviceJavaScript + AJAX estándaresXML usando XHTML y CSS Local System<Servicio 1> <Aplicación 1> <Función 1> Automático Account Local System<Servicio 2> <Aplicación 2> <Función 2> Automático 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.EnterpriseNombre del Sistema Operativo EditionVersion 2.2.3790 Service Pack 2 Build 3790Proveedor del Sistema Operativo Microsoft CorporationNombre del Sistema DEIPSBATCHProveedor del Sistema IBMModelo del Sistema -[865811Y]-Tipo del Sistema X86 – based PCProcesador x86 Family 6 Model 8 Stepping 3 Genuineintel - 664BIOS Version/Date IBM ILKT44AUS, 20/09/2001SMBIOS Version 2.1Total de Memoria Física 2,047.49 MBPromedio de Memoria Física 1.37 GBTotal de Memoria Virtual 3.86 GBPromedio de Memoria Virtual 3.47 GBTipo de Adaptador Ethernet 802.3Tipo de Producto IBM Netfinity Fault Tolerante PCI AdapterNombre del Servicio PCNet5Dirección IP 10.203.32.9Máscara de Sub Red IP 255.255.255.0Gateway IP 10.203.32.254DHCP Enabled NoDHCP Server Not AvailableMAC Address 00:06:29:D5:38:0FMemory Address 0XFEB7FC00-0XFEB7FC1F © Oficina Nacional de Procesos Electorales Confidencial Página 19 de 23 ONPE - 2008
  20. 20. <Nombre del Proyecto> Versión: <x.x>Documento de Arquitectura del Sistema Fecha:<dd/mm/yyyy><Nombre del archivo> 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ónNOMBRE DEL SERVIDOR Serv_ProdIP 1.1.15.50DESCRIPCION Y OBJETIVO DEL SERVIDORSERVICIOSNOMBRE DE APLICACIÓN FUNCIÓN INICIO USUARIOSERVICIO Por ejemplo:Por Ejemplo: PresentaciónAsynchronous Por ejemplo: basada en Automático AdminserviceJavaScript + AJAX estándaresXML usando XHTML y CSS<Servicio 1> <Aplicación 1> <Función 1> Automático Local System © Oficina Nacional de Procesos Electorales Confidencial Página 20 de 23 ONPE - 2008
  21. 21. <Nombre del Proyecto> Versión: <x.x>Documento de Arquitectura del Sistema Fecha:<dd/mm/yyyy><Nombre del archivo> Account Local System<Servicio 2> <Aplicación 2> <Función 2> Automático 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.EnterpriseNombre del Sistema Operativo EditionVersión 2.2.3790 Service Pack 2 Build 3790Proveedor del Sistema Operativo Microsoft CorporationNombre del Sistema DEIPSBATCHProveedor del Sistema IBMModelo del Sistema -[865811Y]-Tipo del Sistema X86 – based PCProcesador x86 Family 6 Model 8 Stepping 3 Genuineintel - 664BIOS Version/Date IBM ILKT44AUS, 20/09/2001SMBIOS Version 2.1Total de Memoria Física 2,047.49 MBPromedio de Memoria Física 1.37 GBTotal de Memoria Virtual 3.86 GBPromedio de Memoria Virtual 3.47 GBTipo de Adaptador Ethernet 802.3Tipo de Producto IBM Netfinity Fault Tolerante PCI AdapterNombre del Servicio PCNet5Dirección IP 10.203.32.9Máscara de Sub Red IP 255.255.255.0Gateway IP 10.203.32.254DHCP Enabled NoDHCP Server Not AvailableMAC Address 00:06:29:D5:38:0FMemory Address 0XFEB7FC00-0XFEB7FC1F SO FT WA RE ADI CIO NA L US ARI © Oficina Nacional de Procesos Electorales Confidencial Página 21 de 23 ONPE - 2008
  22. 22. <Nombre del Proyecto> Versión: <x.x>Documento de Arquitectura del Sistema Fecha:<dd/mm/yyyy><Nombre del archivo> OS CO N PE RMI SO S AL SE RVI DO R REL ACI ON CO N OT RO S SE RVI DO RE S9. 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.] © Oficina Nacional de Procesos Electorales Confidencial Página 22 de 23 ONPE - 2008
  23. 23. <Nombre del Proyecto> Versión: <x.x>Documento de Arquitectura del Sistema Fecha:<dd/mm/yyyy><Nombre del archivo>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.] © Oficina Nacional de Procesos Electorales Confidencial Página 23 de 23 ONPE - 2008

×