Version


[Nota: La siguiente plantilla es provista para su uso con el Rational Unified Process. El texto contenido dentro de corchetes cuadrados y desplegado en italicas azules (estilo = InfoBlue) es incluido para proveer de guía al autor, y debera ser borrado antes de borrar el documento. Un parrafo introducido siguiendo este estilo sera cambiado a normal (estilo = Body Text).]
[Para personalizar campos automaticos (los que despliegan un fondo gris al ser seleccionados, seleccione Archivo>Propiedades y reemplace los campos Titulo, Asunto y Organización con la información apropiada para este documento. Luego de cerrar el dialogo, los campos automaticos seran actualizados a través del documento al seleccionar Edición>Seleccionar todo (o Ctrl-E) y presionar F9, o simplemente presiona en el campo y presiona F9. Esto debe realizarse por separado para encabezados y pies de pagina. Alt-F9 alternara entre desplegar el nombre de los campos y su contenido. Consulta la ayuda de Word para mas información en el trabajo con campos.]

Historial de Revisiones
Fecha
Versión
Descripción
Autor





Tabla de Contenidos
1. Introducción 3
1.1 Propósito 3
1.2 Alcance 3
1.3 Definiciones, acrónimos, y abreviaturas 3
1.4 Referencias 3
1.5 Resumen 3
2. Representación de la arquitectura 4
3. Metas y restricciones de la arquitectura . Vista de casos de uso 4
4.1 Realizaciones de casos de uso 4
5. Vista lógica 4
5.1 Paquetes de diseño significativos en la arquitectura 4
6. Vista de proceso 5
7. Vista de Producción 5
8. Vista de Implementación 5
8.1 Vistageneral 5
8.2 Capas 5
9. Vista de Datos (opcional) 5
10. Tamaño y Prestaciones 5
11. Calidad 5

Documento de arquitectura de Software
1. Introducción
[La introducción del Documento de Arquitectura de Software da un panorama general de la totalidad Documento de Arquitectura de Software. Incluye el propósito, alcance, definiciones, acrónimos, abreviaturas, referencias y una vista general del Documento de Arquitectura de Software.]
1.1 Propósito
Este documento brinda una vista general integral del sistema, usando un número de vistas diferentes de software para describir diferentes aspectos del sistema. Se pretende capturar y transmitir las decisiones importantes de arquitectura que han sido hechas en el sistema

[Esta sección define el rol o propósito del Documento de Arquitectura de software, en la documentación global del proyecto, y describe brevemente la estructura del documento. Se identifica la audiencia específica del documento, con indicaciones de como se espera que utilicen el documento
1.2 Alcance
[Una breve descripción de lo emplea el Documento de Arquitectura de Software, que es afectado o influenciado por este documento.]
1.3 Definiciones, acrónimos, y abreviaturas
[Esta sub-sección brinda definiciones de todos los términos, acrónimos y abreviaturas requeridas para interpretar adecuadamente el Documento de Arquitectura de Software. Esta información puede ser suministrada a través del Glosario del proyecto.]
1.4 Referencias
[Esta sub-sección provee una lista completa de todos los documentos referenciados en algun sitio en el Documento Arquitectura de Software .Identifique cada documento por el titulo del documento,número de reporte (si aplica), fecha y publicación de la organización. Especifique los recursos de las cuales los recursos pueden ser obtenidos .Esta información puede ser provista por referencia en u apéndice o en otro documento.
1.5 Resumen
[Esta sub-sección describe lo que el resto del Documento de Arquitectura de Software contiene y explica como el Documento de Arquitectura de Software esta organizado
2. Representación de la arquitectura
[Esta sección describe la arquitectura de software para el sistema actual y como es representado. De las vistas de Casos de Uso, Lógica, de Procesos, Desarrollo e implementación , enumera las vistas que son necesarias y para cada vista explica qué tipo de elementos de modelos esta contienen.]
3. Metas y restricciones de la arquitectura .
[Esta sección describe los requerimientos de software y objetivos que tienen algún impacto significativo en la arquitectura; por ejemplo, seguridad, privacidad, portabilidad, distribución y reutilización. También captura las limitaciones especiales que se pueden aplicar: estrategia de implementación y diseño, herramientas de desarrollo, estructura del equipo, horarios, estandares de codificación y otros.]
4. Vista de casos de uso
[Esta sección lista los casos de uso o escenarios desde el modelo de casos de uso si ellos representan alguna funcionalidad significativa, central del sistema final, o (si ellos tienen una gran cobertura de la arquitectura – ellos ejercen muchas elementos de la arquitectura o si ellas ilustran un punto específico, delicado de la arquitectura.]
4.1 Realizaciones de casos de uso
[Esta sección ilustra cómo el software actualmentetrabaja por el suministro de unos pocos casos de uso seleccionados (o escenarios) realizaciones, y explica como varios elementos de elementos de diseño contribuyen a su funcionalidad .]

5. Vista lógica
[Esta sección describe las partes de la arquitectura significativas del modelo de diseño, tales como su descomposición dentro de subsistemas o paquetes. Y para cada paquete significativo, su descomposición dentro de clases y utilitarios de clases. Usted debería introducir clases de arquitecturas significativas y describir sus responsabilidades, tanto como cada relación importante operaciones y atributos .]
5.1 Paquetes de diseño significativos en la arquitectura
[Para cada paquete significativo, incluya una sub-sección con su nombre, una breve descripción y un diagrama con todas las clases significativas y paquetes contenidos dentro del paquete
Para cada clase significativa en el paquete, incluya su nombre, breve descripción y opcionalmente, una descripción de sus mayores responsabilidades, operaciones y atributos..]
6. Vista de proceso
[Esta sección describe la descomposición del sistema en procesos pequeños (hilos de control) y procesos pesados (agrupaciones de procesos pequeños). La sección se organiza por grupos de procesos que se comunican o iteractuan. Describe los principales modos de comunicación entre procesos como paso de mensajes, interrupciones y puntos de unión.]
7. Vista de Producción
[Esta sección describe una o mas configuraciones de redes físicas (hardware) en las que el software es puesto en marcha y ejecutado. Es una vista del Modelo de Producción. Como mínimo para cada configuración se debería indicar los nodosfísicos (computadores, CPU’s) que ejecutan el software y sus interconexiones (bus, LAN, punto a punto, y así por el estilo). También se incluye un mapeo de los procesos de la Vista de Procesos en los nodos físicos.]
8. Vista de Implementación
[Esta sección describe la estructura global del modelo de implementación, la descomposición del software en capas y subsistemas en el modelo de implementación, y cualquier componente de arquitectura significante.]
8.1 Vista general
[Esta sub-sección nombra y define las varias capas y sus contenidos, las reglas que gobiernan la inclusión a una determinada capa y los limites entre capa,, Incluye un diagrama de componentes que muestra las relaciones entre capas. ]
8.2 Capas
[Para cada capa, se incluye una sub-sección con su nombre, una enumeración de losl sus-sistemas localizados en la capa y un diagrama de componentes.]

9. Vista de Datos (opcional
[Una descripción de la perspectiva del almacén de datos persistentes de el sistema. Esta sección es opcional si es que hay poco o ningún dato persistente, o si la traducción entre el Modelo de Diseño y el modelo de datos es trivial.]
10. Tamaño y Prestaciones
[Una descripción de las características de mayor dimensión del software que impactan la arquitectura, así como las restricciones de ejecución.]
11. Calidad
[Una descripción de como la arquitectura de software contribuye a todas las capacidades (otras aparte de la funcionalidad) del sistema: extensibilidad, confiabilidad, portabilidad, y así por el estilo. Si estas características tienen significancia especial, como seguridad, implicaciones de privacidad, deben de ser claramente delineadas.]