Arquitectura del sistema

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

Versión Autor DescripciónFecha de

ElaboraciónRevisado por

Fecha de Revisión

<x.x>

<Nombre de la persona que elabora

el documento>

<Detalles> <dd/mm/aa><Persona(s) que revisa(n) el documento

<dd/mm/aa>

Confidencial Oficina Nacional de Procesos Electorales

ONPE - 2008Página 2 de 22


INDICE

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 21

9.1. Diseño de comunicación entre módulos 21

9.2. Interfaz del Usuario 21

10. VISTA DE DATOS 21

10.1. Modelo de Base de Datos Lógico y Físico 21

10.2. Diccionario de Datos 22

11. ESPECIFICACIÓN DE CONSTRUCCIÓN 22

11.1. Especificación del Entorno de Construcción 22

11.2. Definición de Componentes y Subsistemas de Construcción 22




DOCUMENTO DE ARQUITECTURA DEL SISTEMA

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




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:




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 arquitecturaLa 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ónEl lenguaje de programación a emplear para el desarrollo de la capa de presentación será el Microsoft Visual Basic .NET




c. Interfases de integración con ATCA, Sistema de Ahorros DPAH, Sistema de Recaudación RECA y TOLDEl 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 RENIECLa 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ónSe 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




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.




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.

Mostrar Usuarios Activos

Reaperturar Centro de Cómputo

Administración y Seguridad - Modelo General

Usuario_Administrador

Mostrar Módulos

<<extend>>

Consultar Perfi les

Mostrar Parámetros de Acceso

Mantener Usuario

Asignar Usuarios a Modulo

Cerrar Sesiones de Usuario

Realizar Auditoria

Restaurar Base de Datos

Realizar Backup de Base de Datos

Cerrar Centro de Cómputo

<<extend>>

Administrador_Nación

Usuario_Suite

Ingresar a la Suite Electoral

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.




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.

Administrador_Nación

Datos Pre Electorales - Modelo General

Usuario_AdministradorRealizar puesta a cero

Importar datos

<<include>>

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 Electorales

Transmisión y Recepción

Presentación Resultados

Lotización y Digitación

Administración y Seguridad

Registro de Omisos

Reportes y Consultas

Digitalización de Actas




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




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




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




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




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




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




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 SERVICIO

APLICACIÓN FUNCIÓN INICIO USUARIO

Por Ejemplo: Asynchronous JavaScript + XML

Por ejemplo: AJAX

Por ejemplo: Presentación basada en estándares usando XHTML y CSS

Automático Adminservice

<Servicio 1> <Aplicación 1> <Función 1> AutomáticoLocal System Account


<Servicio N> <Aplicación N> <Función 1> AutomáticoLocal System Account

CONFIGURACIÓN DE HARDWARE Y SOFTWARE

Nombre del Sistema OperativoMicrosoft ( R) Windows (R ) Server 200.Enterprise 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



http://adaptivepath.com/publications/essays/archives/000266.php




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

SOFTWARE ADICIONAL

USARIOS CON PERMISOS AL SERVIDOR

RELACION CON OTROS SERVIDORES

8.5.2. Entorno de Pruebas

NOMBRE DEL SERVIDOR Serv_Prueba

IP 1.1.15.50


SERVICIOS

NOMBRE DE SERVICIO



Por ejemplo: AJAX








Version 2.2.3790 Service Pack 2 Build 3790














SMBIOS Version 2.1










Gateway IP 10.203.32.254

DHCP Enabled No




SOFTWARE ADICIONAL



8.5.3. Entorno de Producción

NOMBRE DEL SERVIDOR Serv_Prod

IP 1.1.15.50


SERVICIOS

NOMBRE DE SERVICIO



Por ejemplo: AJAX














Versión 2.2.3790 Service Pack 2 Build 3790








SMBIOS Version 2.1










Gateway IP 10.203.32.254

DHCP Enabled No




SOFTWARE ADICIONAL



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

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

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



Documents

Arquitectura del sistema