Skip to content

Commit

Permalink
Merge remote-tracking branch 'origin/main'
Browse files Browse the repository at this point in the history
  • Loading branch information
gernotstarke committed Oct 13, 2024
2 parents 3cadc31 + 53fe34d commit f93c13e
Show file tree
Hide file tree
Showing 7 changed files with 14 additions and 15 deletions.
6 changes: 3 additions & 3 deletions docs/04-documentation/01-documentation-duration-terms.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -13,7 +13,7 @@ Außerdem lernen die Teilnehmer:innen, wichtige Architekturentscheidungen, Schni

=== Wesentliche Begriffe

(Architektur-)Sichten; Strukturen; (technische) Konzepte; Dokumentation; Kommunikation; Beschreibung; zielgruppen- oder stakeholdergerecht; Meta-Strukturen und Templates zur Beschreibung und Kommunikation; Kontextabgrenzung; Bausteine; Bausteinsicht; Laufzeitsicht; Verteilungssicht; Knoten; Kanal; Verteilungsartefakte; Mapping von Bausteinen auf Verteilungsartefakte; Beschreibung von Schnittstellen und Architekturentscheidungen; UML; Werkzeuge zur Dokumentation
(Architektur-)Sichten; Strukturen; (technische) Konzepte; Dokumentation; Kommunikation; Beschreibung; Ausrichtung an Zielgruppen und Stakeholder-Anliegen; Meta-Strukturen und Templates zur Beschreibung und Kommunikation; Kontextabgrenzung; Bausteine; Bausteinsicht; Laufzeitsicht; Verteilungssicht; Knoten; Kanal; Verteilungsartefakte; Mapping von Bausteinen auf Verteilungsartefakte; Mapping von Verteilungsartefakten auf Knoten; Beschreibung von Schnittstellen und Architekturentscheidungen; UML; Werkzeuge zur Dokumentation

// end::DE[]

Expand All @@ -26,9 +26,9 @@ Außerdem lernen die Teilnehmer:innen, wichtige Architekturentscheidungen, Schni

=== Purpose
The purpose of this section is to enable participants to document and communicate software architectures in a way that meets the needs of important stakeholders and supports the development process.
The focus is on understanding the essential requirements of technical documentation, using appropriate models and notations to describe architectures, and applying key architectural views.
The focus is on understanding the essential requirements for technical documentation, using appropriate models and notations to describe architectures, and applying key architectural views.
Additionally, participants will learn to document key architectural decisions, interfaces, and cross-cutting concerns, ensuring clear, correct, and stakeholder-relevant documentation.

=== Relevant Terms
(Architectural) Views; structures; (technical) concepts; documentation; communication; description; stakeholder-oriented, meta structures and templates for description and communication; system context; building blocks; building-block view; runtime view; deployment view; node; channel; deployment artifacts; mapping building blocks onto deployment artifacts; description of interfaces and design decisions; UML, tools for documentation
(Architectural) Views; structures; (technical) concepts; documentation; communication; description; alignment with target-groups and stakeholder concerns; structures and templates for description and communication; system context; building blocks; building-block view; runtime view; deployment view; node; channel; deployment artifacts; mapping building blocks onto deployment artifacts; mapping deployment artifacts onto nodes; description of interfaces and design decisions; UML; tools for documentation
// end::EN[]
4 changes: 2 additions & 2 deletions docs/04-documentation/LG-04-01.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -14,10 +14,10 @@ Sie wissen, dass Verständlichkeit technischer Dokumentation nur von deren Zielg
// tag::EN[]
[[LG-04-01]]
==== LG 04-01 [previously LG 3-01]: Explain and Consider the Requirements of Technical Documentation (R1)
Software architects know the requirements of technical documentation and can consider and fulfil them when documenting systems:
Software architects know the essential requirements for technical documentation and can consider and fulfil them when documenting systems:

* understandability, correctness, efficiency, appropriateness, maintainability
* form, content, and level of detail tailored to the stakeholders
* form, content, and level of detail tailored to the target group of the documentation

They know that only the target audiences can assess the understandability of technical documentation.

Expand Down
2 changes: 1 addition & 1 deletion docs/04-documentation/LG-04-02.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -33,7 +33,7 @@ Software architects are able to (R1):

* document and communicate architectures for corresponding stakeholder concerns, thereby addressing different target groups, e.g. management, development teams, QA, other software architects, and possibly additional stakeholders
* consolidate and harmonise the style and content of contributions from different groups of authors
* develop and implement measures to support the convergence of written and verbal communication, and balance one against the other appropriately
* develop and implement measures to support the consistency of written and verbal communication, and balance one against the other appropriately

Software architects know (R1):

Expand Down
3 changes: 1 addition & 2 deletions docs/04-documentation/LG-04-03.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -35,9 +35,8 @@ Software architects know alternative notations to UML diagrams, for example: (R3

* Archimate
* SysML
* Entity-relationship diagrams, see <<erd>>
* C4, see <<brownc4>>

* Entity-relationship diagrams, see <<erd>>
* for runtime views for example flow charts, numbered lists or business-process-modeling-notation (BPMN).

// end::EN[]
Expand Down
2 changes: 1 addition & 1 deletion docs/04-documentation/LG-04-09.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -24,7 +24,7 @@ Software architects know:
** ISO/IEC/IEEE 42010,
** arc42,
** C4, see <<brownc4>>
* ideas and examples of checklists for the creation, documentation, and testing of software architectures
* ideas and examples of checklists for the creation, documentation, and review of software architectures
* possible tools for creating and maintaining architectural documentation

// end::EN[]
Expand Down
8 changes: 4 additions & 4 deletions docs/05-evaluation/01-evaluation-duration-terms.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -9,12 +9,12 @@
=== Zielsetzung
In diesem Abschnitt sollen Softwarearchitekt:innen die Fähigkeiten und Kenntnisse vermittelt werden, die sie für eine effektive Architekturanalyse benötigen.
Sie lernen, Risiken zu erkennen, die Konformität mit Architekturentscheidungen zu bewerten und die Gesamtqualität eines Systems auf der Grundlage seines Designs und seiner Implementierung zu beurteilen.
Durch das Verständnis verschiedener Analysemethoden wie Abnahmetests, Architekturmetriken und Kosten-Nutzen-Analysen können Architekt:innen sicherstellen, dass eine Softwarearchitektur den Anforderungen der Stakeholder entspricht und mit dem beabsichtigten Design übereinstimmt.
Durch das Verständnis verschiedener Analysemethoden wie Abnahmetests, Architekturmetriken, szenariobasierte Analyse und Kosten-Nutzen-Analysen können Architekt:innen sicherstellen, dass eine Softwarearchitektur den Anforderungen der Stakeholder entspricht und mit dem beabsichtigten Design übereinstimmt.


=== Wesentliche Begriffe

Architekturanalyse; Risikoidentifikation; Qualitätsanalysemethoden; Szenarien; Metriken; Tool-gestützte Analyse
Architekturanalyse; Risikoidentifikation; Qualitätsanalysemethoden; Szenarien; szenariobasierte Analyse; Metriken; Tool-gestützte Analyse


// end::DE[]
Expand All @@ -29,9 +29,9 @@ Architekturanalyse; Risikoidentifikation; Qualitätsanalysemethoden; Szenarien;
=== Purpose
The purpose of this section is to equip software architects with the skills and knowledge needed to effectively perform architecture analysis.
They learn to identify risks, evaluate conformance to architectural decisions, and assess the overall quality of a system based on its design and implementation.
By understanding various analysis methods, such as acceptance testing, architecture metrics, and cost-benefit analysis, architects can ensure that a software architecture meets stakeholder requirements and is aligned with the intended design.
By understanding various analysis methods, such as acceptance testing, architecture metrics, scenario-based analysis, and cost-benefit analysis, architects can ensure that a software architecture meets stakeholder requirements and is aligned with the intended design.

=== Relevant Terms

Architecture analysis; Risk identification; Quality analysis methods; Scenarios; Metrics; Tool-supported analysis
Architecture analysis; Risk identification; Quality analysis methods; Scenarios; Scenario-based analysis; Metrics; Tool-supported analysis
// end::EN[]
4 changes: 2 additions & 2 deletions docs/05-evaluation/LG-05-02.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -10,7 +10,7 @@ Softwarearchitekt:innen
** Analyse der Ergebnisse von Akzeptanztests (R1)
** quantitative Messung von Laufzeitverhalten (R1)
** qualitative Auswertung durch Interviews, Umfragen, Penetrationstests etc. (R1)
** Szenarien (R1)
** szenariobasierte Analyse (R1)
** Architektur-Metriken für Kopplung wie der Grad eingehender und
ausgehender Abhängigkeiten (R1)
** Kosten-Nutzen-Analyse (R3)
Expand Down Expand Up @@ -40,7 +40,7 @@ Software architects
** analysis of the results of acceptance testing (R1)
** quantitative measurement of run-time behaviour (R1)
** qualitative evaluation via interviews, surveys, penetration tests etc. (R1)
** scenarios (R1)
** scenario-based analysis (R1)
** architecture metrics for coupling such as the degree of inbound and outbound dependencies (R1)
** cost-benefit analysis (R3)
** Architecture Trade-Off Analysis Method <<bass>> (R3)
Expand Down

0 comments on commit f93c13e

Please sign in to comment.