Traducción documentación a español

docs/index.adoc

@@ -49,51 +49,51 @@ For documentation of your own system you use better the _plain_ version.
 :numbered:
 
 <<<<
-// 1. Introduction and Goals
+// 1. Introducción y Metas
 include::src/01_introduction_and_goals.adoc[]
 
 <<<<
-// 2. Architecture Constraints
+// 2. Restricciones de la Arquitectura
 include::src/02_architecture_constraints.adoc[]
 
 <<<<
-// 3. System Scope and Context
+// 3. Alcance y Contexto del Sistema
 include::src/03_system_scope_and_context.adoc[]
 
 <<<<
-// 4. Solution Strategy
+// 4. Estrategia de solución
 include::src/04_solution_strategy.adoc[]
 
 <<<<
-// 5. Building Block View
+// 5. Vista de Bloques
 include::src/05_building_block_view.adoc[]
 
 <<<<
-// 6. Runtime View
+// 6. Vista de Ejecución
 include::src/06_runtime_view.adoc[]
 
 <<<<
-// 7. Deployment View
+// 7. Vista de Despliegue
 include::src/07_deployment_view.adoc[]
 
 <<<<
-// 8. Concepts
+// 8. Conceptos Transversales (Cross-cutting)
 include::src/08_concepts.adoc[]
 
 <<<<
-// 9. Architecture Decisions
+// 9. Decisiones de Diseño
 include::src/09_architecture_decisions.adoc[]
 
 <<<<
-// 10. Quality Requirements
+// 10. Requerimientos de Calidad
 include::src/10_quality_requirements.adoc[]
 
 <<<<
-// 11. Technical Risks
+// 11. Riesgos y deuda técnica
 include::src/11_technical_risks.adoc[]
 
 <<<<
-// 12. Glossary
+// 12. Glosario
 include::src/12_glossary.adoc[]
 
 

docs/src/01_introduction_and_goals.adoc

@@ -1,18 +1,16 @@
 ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-introduction-and-goals]]
-== Introduction and Goals
+== Introducción y Metas
 
 [role="arc42help"]
 ****
-Describes the relevant requirements and the driving forces that software architects and development team must consider. 
-These include
-
-* underlying business goals, 
-* essential features, 
-* essential functional requirements, 
-* quality goals for the architecture and
-* relevant stakeholders and their expectations
+Describe los requerimientos relevantes y las directrices que los arquitectos de software y el equipo de desarrollo
+deben considerar. Entre estas se incluyen:
+
+* Objetivos empresariales subyacentes, características esenciales y requerimientos funcionales para el sistema
+* Metas de calidad para la arquitectura
+* Las partes interesadas pertinentes y sus expectativas
 ****
 
 Nuestro equipo de desarrollo ha sido contratado por la empresa HappySW para la creación de una aplicación de preguntas y respuestas similar al programa de RTVE "Saber y Ganar". Nuestro objetivo para este proyecto será:
@@ -21,31 +19,28 @@ Nuestro equipo de desarrollo ha sido contratado por la empresa HappySW para la c
 * Los usuarios podrán crear sus propia cuenta para acceder al historial de sus partidas.
 
 
-=== Requirements Overview
+=== Vista de Requerimientos
 
 [role="arc42help"]
 ****
-.Contents
-Short description of the functional requirements, driving forces, extract (or abstract)
-of requirements. Link to (hopefully existing) requirements documents
-(with version number and information where to find it).
-
-.Motivation
-From the point of view of the end users a system is created or modified to
-improve support of a business activity and/or improve the quality.
-
-.Form
-Short textual description, probably in tabular use-case format.
-If requirements documents exist this overview should refer to these documents.
-
-Keep these excerpts as short as possible. Balance readability of this document with potential redundancy w.r.t to requirements documents.
-
-
-.Further Information
-
-See https://docs.arc42.org/section-1/[Introduction and Goals] in the arc42 documentation.
-
+.Contenido
+Descripción corta de los requerimientos funcionales, motivaciones, extracto (o resumen) de los 
+requerimientos. Ligar a los documentos de requerimientos determinados (Con número de versión e
+información de donde encontrarla). 
+
+.Motivación
+Desde el punto de vista de los usuarios finales un sistema es creado o modificado para
+mejorar el soporte a una actividad de negocio o incrementar su calidad
+
+.Forma
+Descripción corta textual, probablemente en un formato de caso de uso tabular.
+Si existen documentos de requerimientos esta vista debe referir a dichos requerimientos
+
+Mantenga estos extractos tan cortos como sea posible. Encuentre el balance entre la legibilidad y 
+la redundancia de este documento respecto a los documentos de requerimientos que se encuentren 
+relacionados.
 ****
+
 A continuación se muestran los requisitos de alto nivel para el desarrollo del juego.
 
 |===
@@ -62,27 +57,24 @@ A continuación se muestran los requisitos de alto nivel para el desarrollo del
 
 Para información más detallada, se puede consultar el documento completo proporcionado por la empresa https://docs.google.com/document/d/1pahOfYFY--Wi7_9bbxiKOGevB_9tOSyRm78blncgBKg/edit[aquí] .
 
-=== Quality Goals
+=== Metas de Calidad
 
 [role="arc42help"]
 ****
-.Contents
-The top three (max five) quality goals for the architecture whose fulfillment is of highest importance to the major stakeholders. 
-We really mean quality goals for the architecture. Don't confuse them with project goals.
-They are not necessarily identical.
-
-Consider this overview of potential topics (based upon the ISO 25010 standard):
-
-image::01_2_iso-25010-topics-EN.drawio.png["Categories of Quality Requirements"]
-
-.Motivation
-You should know the quality goals of your most important stakeholders, since they will influence fundamental architectural decisions. 
-Make sure to be very concrete about these qualities, avoid buzzwords.
-If you as an architect do not know how the quality of your work will be judged...
-
-.Form
-A table with quality goals and concrete scenarios, ordered by priorities
+.Contenido
+Las tres metas de calidad principales (o hasta cinco) cuyo cumplimiento sea de la mayor importancia para las
+principales partes interesadas. Nos referimos a las metas de calidad para la arquitectura. No confundir
+con las metas del proyecto. No necesariamente son idénticas.
+
+.Motivación
+Debe conocer las metas de calidad de las partes interesadas más importantes, ya que ellos influenciarán
+las decisiones arquitectónicas principales. Asegúrese de ser muy concreto con las descripciones, evitando buzzwords.
+Si como arquitecto no conoce la calidad de su trabajo, será juzgado...
+
+.Forma
+Una tabla con metas de calidad y escenarios concretos, ordenados por prioridades
 ****
+
 [options="header",cols="1,2"]
 |===
 |Atributo de calidad|Descripción
@@ -93,7 +85,29 @@ A table with quality goals and concrete scenarios, ordered by priorities
 |Seguridad| Los datos personales del usuario serán guardados de manera segura
 |===
 
-=== Stakeholders
+=== Partes interesadas (Stakeholders)
+
+[role="arc42help"]
+****
+.Contenido
+Vista detallada de las partes intersadas del sistema, es decir, toda persona, rol u organización que:
+
+* Debe conocer la arquitectura
+* Debe estar convencida de la arquitectura
+* Tiene que trabajar con la arquitectura o con el código
+* Necesitan la documentación de la arquitectura para su trabajo
+* Intervienen en las decisiones acerca del sistema o su desarrollo 
+
+.Motivación
+Debe conocer a todas las partes involucradas en el desarrollo del sistema o que son afectadas
+por el sistema. De otro modo, se topará con sorpresas desagradables durante el proceso de desarrollo.
+Estas partes relacionadas o stakeholders determinarán la extensión y el nivel de detalle del trabajo
+y sus resultados
+
+.Forma
+Tabla con nombres de los roles, personas, y sus expectativas con respecto a la arquitectura y su 
+documentación
+****
 
 [options="header",cols="1,2,2"]
 |===

docs/src/02_architecture_constraints.adoc

@@ -1,29 +1,24 @@
 ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-architecture-constraints]]
-== Restricciones de arquitectura
+== Restricciones de la Arquitectura
 
-[role="arc42help"]
 
+[role="arc42help"]
 ****
-.Contents
-Any requirement that constraints software architects in their freedom of design and implementation decisions or decision about the development process. These constraints sometimes go beyond individual systems and are valid for whole organizations and companies.
-
-.Motivation
-Architects should know exactly where they are free in their design decisions and where they must adhere to constraints.
-Constraints must always be dealt with; they may be negotiable, though.
-
-.Form
-Simple tables of constraints with explanations.
-If needed you can subdivide them into
-technical constraints, organizational and political constraints and
-conventions (e.g. programming or versioning guidelines, documentation or naming conventions)
-
-
-.Further Information
-
-See https://docs.arc42.org/section-2/[Architecture Constraints] in the arc42 documentation.
-
+.Contenido
+Cualquier requerimiento que restrinja a los arquitectos de software en la libertad de diseño y la toma de decisiones
+sobre la implementación o el proceso de desarrollo. Estas restricciones a veces van más allá de sistemas individuales
+y son validos para organizaciones y compañías enteras.
+
+.Motivación
+Los arquitectos deben saber exactamente sus libertades respecto a las decisiones de diseño y en donde deben apegarse
+a restricciones. Las restricciones siempre deben ser acatadas, aunque en algunos casos pueden ser negociables.
+
+.Forma
+Tablas de restricciones con sus explicaciones.
+Si se requiere, se pueden subdividir en restricciones técnicas, organizacionales y/o políticas y convenciones
+(por ejemplo, guías de versionado o programación, convenciones de documentación o nombrado)
 ****
 
 === Restricciones técnicas

docs/src/03_system_scope_and_context.adoc

@@ -1,52 +1,53 @@
 ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-system-scope-and-context]]
-== System Scope and Context
+== Alcance y Contexto del Sistema
 
 
 [role="arc42help"]
 ****
-.Contents
+.Contenido
+El alcance y contexto del sistema - como lo sugiere el nombre - delimita al sistema (es decir, el alcance) de todos sus
+socios de comunicación (Usuarios y sistemas vecinos, es decir, el contexto del sistema). 
 System scope and context - as the name suggests - delimits your system (i.e. your scope) from all its communication partners
-(neighboring systems and users, i.e. the context of your system). It thereby specifies the external interfaces.
+(neighboring systems and users, i.e. the context of your system). Con ello se especifican las interfaces externas.
 
-If necessary, differentiate the business context (domain specific inputs and outputs) from the technical context (channels, protocols, hardware).
+Si es necesario, diferenciar el contexto de negocio (Entradas y salidas específicas del dominio) del contexto técnico
+(canales, protocolos, hardware).
 
-.Motivation
-The domain interfaces and technical interfaces to communication partners are among your system's most critical aspects. Make sure that you completely understand them.
+.Motivación
+Las interfases de dominio y las interfases técnicas a los socios de comunicación son de los aspectos más críticos del sistema.
+Se debe asegurar el entendimiento de ellos.
 
-.Form
-Various options:
-
-* Context diagrams
-* Lists of communication partners and their interfaces.
-
-
-.Further Information
-
-See https://docs.arc42.org/section-3/[Context and Scope] in the arc42 documentation.
+.Forma
+Varias opciones:
 
+* Diagramas de contexto
+* Listas de socios de comunicación y sus interfases.
 ****
 
 
-=== Business Context
+=== Contexto de Negocio
 
 [role="arc42help"]
 ****
-.Contents
-Specification of *all* communication partners (users, IT-systems, ...) with explanations of domain specific inputs and outputs or interfaces.
-Optionally you can add domain specific formats or communication protocols.
-
-.Motivation
-All stakeholders should understand which data are exchanged with the environment of the system.
+.Contenido
+La especificación de *todos* los socios de comunicación (usuarios, sistemas, ...) con explicaciones de las entradas y salidas
+específicas del dominio o interfases.
+Opcionalmente puede agregar formatos específicos de dominio o protocolos de comunicación
 
-.Form
-All kinds of diagrams that show the system as a black box and specify the domain interfaces to communication partners.
+.Motivación
+Todas las partes interesadas deben entender que datos son intercambiados con el ambiente del sistema.
 
-Alternatively (or additionally) you can use a table.
-The title of the table is the name of your system, the three columns contain the name of the communication partner, the inputs, and the outputs.
+.Forma
+Cualquier forma de diagramas que muestren al sistema como una caja negra y especifiquen las interfases de dominio a los
+socios de comunicación.
 
+De manera alternativa (o adicional) se puede utilizar una tabla.
+El título de la tabla es el nombre del sistema, las tres columnas contienen el nombre del socio de comunicación, las
+entradas y las salidas
 ****
+
 image::Business_Context.png[Contexto de negocio] 
 
 |===
@@ -56,20 +57,22 @@ image::Business_Context.png[Contexto de negocio]
 | API Wikidata | Recibe una consulta relacionada con la pregunta a construir| Envía los datos que la aplicación ha pedido para la pregunta
 |===
 
-=== Technical Context
+=== Contexto Técnico
 
 [role="arc42help"]
 ****
-.Contents
-Technical interfaces (channels and transmission media) linking your system to its environment. In addition a mapping of domain specific input/output to the channels, i.e. an explanation which I/O uses which channel.
-
-.Motivation
-Many stakeholders make architectural decision based on the technical interfaces between the system and its context. Especially infrastructure or hardware designers decide these technical interfaces.
-
-.Form
-E.g. UML deployment diagram describing channels to neighboring systems,
-together with a mapping table showing the relationships between channels and input/output.
-
+.Contenido
+Las interfases técnicas (medios de transmisión y canales) enlanzando al sistema con su ambiente. De manera adicional
+el mapeo de las entradas/salidas específicas del dominio a los canales, es decir, una explicación acerca de que entrada/salida
+utiliza cual canal.
+
+.Motivación
+Muchas partes relacionadas realizan decisiones arquitectónicas basadas en las interfases técnicas entre el sistema y 
+su contexto. Especialmente los diseñadores de infraestructura o hardware deciden estas interfases técnicas.
+
+.Forma
+Por ejemplo, diagramas UML de despligue describiendo los canales a sistemas vecinos, junto con una tabla de 
+mapeo mostrando las relaciones entre los canales y las entradas/salidas.
 ****
 
 image::Technical_Context.png[Contexto técnico]