Merge pull request #155 from mverburg/master

Add Dutch translation, a big round of applause to @mverburg

NL/asciidoc/arc42-template.adoc

@@ -0,0 +1,96 @@
+// header file for arc42-template,
+// including all help texts
+//
+// ====================================
+
+= image:arc42-logo.png[arc42] Template
+// toc-title definition MUST follow document title without blank line!
+:toc-title: Inhoudsopgave
+
+//additional style for arc42 help callouts
+ifdef::backend-html5[]
+++++
+<style>
+.arc42help {font-size:small; width: 14px; height: 16px; overflow: hidden; position: absolute; right: 0; padding: 2px 0 3px 2px;}
+.arc42help::before {content: "?";}
+.arc42help:hover {width:auto; height: auto; z-index: 100; padding: 10px;}
+.arc42help:hover::before {content: "";}
+@media print {
+	.arc42help {display:none;}
+}
+</style>
+++++
+endif::backend-html5[]
+
+// configure EN settings for asciidoc
+include::src/config.adoc[]
+
+
+include::src/about-arc42.adoc[]
+
+// horizontal line
+***
+
+[role="arc42help"]
+****
+[NOTE]
+====
+Deze versie van de template bevat hulp en uitleg.
+Het is bedoel om bekend te raken met arc42 en om de concepten te begrijpen.
+Om uw eigen sytemen te documenteren adviseren we om de _kale_ versie te gebruiken.
+====
+****
+
+
+// numbering from here on
+:numbered:
+
+<<<<
+// 1. Introduction and Goals
+include::src/01_introduction_and_goals.adoc[]
+
+<<<<
+// 2. Architecture Constraints
+include::src/02_architecture_constraints.adoc[]
+
+<<<<
+// 3. System Scope and Context
+include::src/03_system_scope_and_context.adoc[]
+
+<<<<
+// 4. Solution Strategy
+include::src/04_solution_strategy.adoc[]
+
+<<<<
+// 5. Building Block View
+include::src/05_building_block_view.adoc[]
+
+<<<<
+// 6. Runtime View
+include::src/06_runtime_view.adoc[]
+
+<<<<
+// 7. Deployment View
+include::src/07_deployment_view.adoc[]
+
+<<<<
+// 8. Concepts
+include::src/08_concepts.adoc[]
+
+<<<<
+// 9. Architecture Decisions
+include::src/09_architecture_decisions.adoc[]
+
+<<<<
+// 10. Quality Requirements
+include::src/10_quality_requirements.adoc[]
+
+<<<<
+// 11. Technical Risks
+include::src/11_technical_risks.adoc[]
+
+<<<<
+// 12. Glossary
+include::src/12_glossary.adoc[]
+
+

NL/asciidoc/src/01_introduction_and_goals.adoc

@@ -0,0 +1,91 @@
+[[section-introduction-and-goals]]
+== Introductie en Doelen
+
+[role="arc42help"]
+****
+Beschrijft de relevante requirements en het krachtenveld waar software architecten en het development team rekening mee moeten houden.
+Die bestaan onder ander uit
+
+* het begrijpen van de achterliggende doelen van de business, 
+* essentiele features,
+* essentiele functionele requirements, 
+* kwaliteits doelen voor de architectuur en
+* relevante belanghebbenden en hun verwachtingen
+****
+
+=== Requirements Overzicht
+
+[role="arc42help"]
+****
+.Inhoud
+Korte beschrijven van de functionele requirements, drijvende krachten, uittreksel (of samenvatting) van de requirements.
+Verwijzing naar de (hopelijk bestaande) requirements documentatie (met versie nummer en informatie waar deze te vinden is).
+
+
+.Motivatie
+Vanuit het perspectief van de eind gebruikers is een systeem ontwikkeld of aangepast om een business activiteit beter te ondersteunen en/of om de kwaliteit van die activiteit te verbeteren.
+
+.Vorm
+Korte textuele beschrijving, mogelijk in use-case tabel formaat.
+Dit overzichts document moet naar het requirements document verwijzen (als dat bestaat).
+
+Houd deze uittreksels zo kort mogelijk. 
+Zoek een evenwicht tussen leesbaarheid van dit document en mogelijke dubbelingen met betrekking tot het requirements document.
+
+.Verdere Informatie
+
+Zie https://docs.arc42.org/section-1/[Introductie en Doelen] in de arc42 documentatie.
+
+****
+
+=== Kwaliteits Doelen
+
+[role="arc42help"]
+****
+.Inhoud
+De top drie (max vijf) kwaliteits doelen aan de architectuur waarvan het behalen van het grootste belang is voor de primaire belanghebbenden.
+
+We bedoelen hier echt kwaliteits doelen voor de architectuur.
+Niet te verwarren met project doelen.
+
+Overweeg dit overzicht met mogelijke onderwerpen (gebaseerd op de ISO 25010 standaard):
+
+image::01_2_iso-25010-topics-EN.png["Categorieen van mogelijke Kwaliteits Requirements"]
+
+.Motivatie
+Het is belangrijk de kwaliteits doelen van je belangrijkste belanghebbenden te kennen omdat deze invloed hebben op fundamentele architectuur keuzes.
+Denk eraan heel concreet te zijn over deze kwaliteiten, vermijd modewoorden.
+Alsof je als architect niet weet hoe de kwaliteit van je werk beoordeeld zal worden...
+
+.Vorm
+Een tabel met kwaliteits doelen en concrete scenarios, gesorteerd op prioriteit.
+****
+
+=== Belanghebbenden
+
+[role="arc42help"]
+****
+.Inhoud
+Expliciet overzicht van belanghebbenden van het systeem, dat wil zeggen alle personen, rollen of oranisaties die
+
+* de architectuur moeten kennen
+* van de architectuur overtuigd moeten worden
+* met de architectuur of code moeten werken
+* de documentatie van de architectuur nodig hebben voor hun werk
+* beslissingen moeten maken over het systeem of de ontwikkeling daarvan
+
+.Motivatie
+Alle partijen die betrokken zijn bij de ontwikkeling of anderzinds geraakt worden door het systeem moeten bekend zijn.
+Anders kan dat later in het ontwikkelings proces tot nare verassingen zorgen.
+Deze belanghebbenden bepalen in een grote mate de omvang en het detail niveau van de werkzaameheden en de resultaten.
+
+.Vorm
+Tabel met de rollen, personen en hun verwachting met betrekking tot de architectuur en haar documentatie.
+****
+
+[options="header",cols="1,2,2"]
+|===
+|Rol/Naam|Contact persoon|Verwachtingen
+| _<Rol-1>_ | _<Contact-1>_ | _<Verwachting-1>_
+| _<Rol-2>_ | _<Contact-2>_ | _<Verwachting-2>_
+|===

NL/asciidoc/src/02_architecture_constraints.adoc

@@ -0,0 +1,23 @@
+[[section-architecture-constraints]]
+== Architectuur Beperkingen
+
+
+[role="arc42help"]
+****
+.Inhoud
+Iedere requirement die de sofware architecten in hun vrijheid met betrekking tot ontwerp, implementatie of het ontwikkel proces beperken.  
+Het kan zijn dat deze beperkingen verder gaan dan de individuele systemen en van toepassing zijn op hele organisaties of bedrijven.
+
+.Motivatie
+Architecten moeten weten waar ze vrij zijn in de ontwerp keuzes en waar ze zich aan beperkingen moeten houden.
+Beperkingen moeten altijd onder ogen worden gezien; echter, het kan zijn dat er over te onderhandelen valt.
+
+.Vorm
+Simpele tabellen met beperkingen en bijbehorende uitleg.
+Zo nodig opgedeeld in technische, organisatorische en politieke beperkingen en conventies (bijv. programmeer of versionering guidelines, documentatie of naamgevings conventies).
+
+.Verdere Informatie
+
+Zie https://docs.arc42.org/section-2/[Architectuur Beperkingen] in de arc42 documentatie.
+
+****

NL/asciidoc/src/03_system_scope_and_context.adoc

@@ -0,0 +1,76 @@
+[[section-system-scope-and-context]]
+== Systeem Scope en Context
+
+
+[role="arc42help"]
+****
+.Inhoud
+De systeem scope en context maakt - zoals de naam suggereert - een onderscheid tussen het eigen systeem (d.w.z. de scope van het systeem dat wordt beschreven) en alle partners waarmee wordt gecommuniceerd (buur systemen en gebruikers, met andere woorden, de context van het systeem).
+Hiermee worden externe interfaces gedefineerd.
+
+Maak, als het nodig is, onderscheid tussen business context (domein specifieke inputs en outputs) en technische context (kanalen, protocollen, hardware).
+
+.Motivatie
+De domein en technische interfaces met communicatie partners horen bij meest kritieke aspecten van het systeem.
+Wees er zeker van dat deze volledig te doorgronden.
+
+.Vorm
+Verschillend opties:
+
+* Context diagrammen
+* Lijst van communicatie partners en bijbehorende interfaces.
+
+
+.Verdere Informatie
+
+Zie https://docs.arc42.org/section-3/[Context en Scope] in de arc42 documentatie.
+
+****
+
+
+=== Business Context
+
+[role="arc42help"]
+****
+.Inhoud
+Specificatie van *alle* communicatie partners (gebruikers, IT-systemen, ...) met uitleg van domein specifieke inputs en outputs of interfaces.
+Het is eventueel mogelijk om domein specifieke formaten of communicatie protocollen toe te voegen.
+
+.Motivatie
+Alle belanghebbenden moeten begrijpen welke data er uitgewisseld wordt met de omgeving van het systeem.
+
+.Vorm
+Alle soorten diagrammen die het systeem als een black box weergeven en die de domein interfaces naar communicatie partners laten zien. 
+
+Een tabel vorm zou als alternatief (of toevoeging) gebruikt kunnen worden.
+De naam van het systeem is de titel van de tabel.
+De drie kolommen bevatten de naam van de communicatie partner, de inputs en de outputs.
+
+****
+
+**<Diagram of Tabel>**
+
+**<optioneel: Uitleg van de externe domein interfaces>**
+
+=== Technische Context
+
+[role="arc42help"]
+****
+.Inhoud
+Technische interfaces (kanalen en mechanismen) die het systeem met haar omgeving verbind.
+Naast een mapping van domein specifieke input/output naar kanalen, dat wil zeggen, een uitleg welke I/O welke kanalen gebruikt.
+
+.Motivatie
+Veel belanghebbenden maken beslisisingen met betrekkeing tot de architectuur gebaseerd op de technische interfaces tussen het systeem en haar context.
+Met name infrastructuur of hardware ontwerpers beslissen aan de hand van deze technische interfaces.
+
+.Vorm
+Bijvoorbeeld UML deployment diagrammen die de kanalen naar naburige systemen beschrijven, gecombineerd met mapping tabellen die de relatie tussen de kanalen en de input/output tonen.
+
+****
+
+**<Diagram of Tabel>**
+
+**<optioneel: Uitleg van technische interfaces>**
+
+**<Mapping Input/Output naar kanalen>**

NL/asciidoc/src/04_solution_strategy.adoc

@@ -0,0 +1,31 @@
+[[section-solution-strategy]]
+== Oplossing Strategie
+
+
+[role="arc42help"]
+****
+.Inhoud
+Een korte samenvatting en uitleg van de fundamentele beslissingen en oplossings strategieen die de systeem architectuur vormen.
+Die bestaan uit onder andere
+
+* beslissingen met betrekking tot technologie
+* beslissingen over de top-level decompositie van het systeem, bijvoorbeeld het gebruik van een architectuur pattern of een design pattern
+* beslissingen over hoe de meest belangrijke kwaliteits doelen behaald zullen worden
+* relevante organisatorische beslissingen, bijvoorbeeld de keuze van een onwikkel proces of het delegeren van bepaalde taken aan derden.
+
+.Motivatie
+Deze beslissingen vormen het fundament van de architectuur.
+Ze vormen de basis waarop vele andere gedetailleerde beslissingen of implemenatie regels worden gebaseerd.
+
+.Vorm
+Hou de uitleg van deze fundamentele beslissingen kort.
+
+Leg de motivatie en reden waarom van de beslissingen zo zijn genomen vast, gebaseerd op een probleem beschrijving, kwaliteitsdoelen en de belangrijkste kaders.
+Verwijs naar details in de volgende secties.
+
+
+.Verdere Informatie
+
+Zie https://docs.arc42.org/section-4/[Solution Strategy] in de arc42 documentatie.
+
+****