Fixed List Items.

isaqb-org · Jan 20, 2024 · 64b2a7f · 64b2a7f
1 parent c3f92a8
commit 64b2a7f
Show file tree

Hide file tree

Showing 7 changed files with 101 additions and 99 deletions.
diff --git a/docs/01-themenspeicher/00-structure.adoc b/docs/01-themenspeicher/00-structure.adoc
@@ -2,7 +2,7 @@
 // (c) iSAQB e.V. (https://isaqb.org)
 // ====================================================
 
-:sectnums!:
+:sectnums:
 // tag::DE[]
 == Themenspeicher
 // end::DE[]
@@ -11,8 +11,7 @@
 == Topic Backlog
 // end::EN[]
 
-:sectnums:
-
+<<<
 include::01-auswirkungen-ddd-unternehmen.adoc[{include_configuration}]
 
 <<<

diff --git a/docs/01-themenspeicher/02-dokumentation-sw-architekuren.adoc b/docs/01-themenspeicher/02-dokumentation-sw-architekuren.adoc
@@ -14,11 +14,11 @@ Was sind Qualitätsmerkmale für eine gute Dokumentation der Architektur und wie
 
 Folgende Fragen sollen behandelt werden:
 
-- Welche Formen eignen sich für die Dokumentation von SW-Architekturen (Format, Ablageort, Struktur, verwendete Notationen)?
-- Wie nutzt man Dokumentation als Kommunikationsmittel und nicht als Ablage?
-- Wie werden Entscheidungen und Prinzipien dokumentiert?
-- Wie können die Artefakte der SW-Architekturdokumentation mit anderen Artefakten (Anforderungen, Fehlerberichte, Testfälle, ...) verknüpft werden (Traceability)?
-- Wie identifiziert man die notwendigen Inhalte und bestimmt den Detaillierungsgrad der Dokumentation?
+* Welche Formen eignen sich für die Dokumentation von SW-Architekturen (Format, Ablageort, Struktur, verwendete Notationen)?
+* Wie nutzt man Dokumentation als Kommunikationsmittel und nicht als Ablage?
+* Wie werden Entscheidungen und Prinzipien dokumentiert?
+* Wie können die Artefakte der SW-Architekturdokumentation mit anderen Artefakten (Anforderungen, Fehlerberichte, Testfälle, ...) verknüpft werden (Traceability)?
+* Wie identifiziert man die notwendigen Inhalte und bestimmt den Detaillierungsgrad der Dokumentation?
 
 ==== Referenzen
 
@@ -52,11 +52,11 @@ What are the quality characteristics of good architectural documentation, and ho
 
 The following questions should be addressed:
 
-- What forms are suitable for the documentation of software architectures (format, storage location, structure, used notations)?
-- How is documentation used as a means of communication and not just as a repository?
-- How are decisions and principles documented?
-- How can the artifacts of software architecture documentation be linked with other artifacts (requirements, bug reports, test cases, etc.) (traceability)?
-- How to identify the necessary contents and determine the level of detail of the documentation?
+* What forms are suitable for the documentation of software architectures (format, storage location, structure, used notations)?
+* How is documentation used as a means of communication and not just as a repository?
+* How are decisions and principles documented?
+* How can the artifacts of software architecture documentation be linked with other artifacts (requirements, bug reports, test cases, etc.) (traceability)?
+* How to identify the necessary contents and determine the level of detail of the documentation?
 
 ==== References
 

diff --git a/docs/01-themenspeicher/03-einsatz-nosql-datenbanken-projekt.adoc b/docs/01-themenspeicher/03-einsatz-nosql-datenbanken-projekt.adoc
@@ -8,18 +8,20 @@ Status: Freigegeben
 NoSQL-Datenbanken sind längst kein Novum mehr. In vielen Projekten sind sie Standard, in vielen aber auch nicht. 
 
 Wer bislang nur mit relationalen Datenbanken zu tun hatte, kann sich oft nicht vorstellen, wie der Einsatz von NoSQL-Datenbanken gelingen kann:
-- Welche Möglichkeiten stecken in solchen Datenbanken und was bringen sie für einen Gewinn?
-- Welche Typen von NoSQL Datenbanken gibt es und wofür können sie eingesetzt werden?
-- Gibt es Gefahren, auf die man achten sollte?
+
+* Welche Möglichkeiten stecken in solchen Datenbanken und was bringen sie für einen Gewinn?
+* Welche Typen von NoSQL Datenbanken gibt es und wofür können sie eingesetzt werden?
+* Gibt es Gefahren, auf die man achten sollte?
 
 Das Thema ist interessant für Architekten, Entwicklung, Betrieb, DB-Administratoren
 
 ==== Aufgabenstellung
 Es sollen diese Fragen beantwortet werden:
-- Welche Probleme lassen sich mit NoSQL-Datenbanken lösen und welche neuen Probleme bekomme ich?
-- Wie kann man den besten Nutzen aus NoSQL-Datenbanken ziehen?
-- Welche Fähigkeiten und Wissen sind erforderlich?
-- Wie müssen NoSQL-Datenbanken in die Architektur berücksichtigt werden?
+
+* Welche Probleme lassen sich mit NoSQL-Datenbanken lösen und welche neuen Probleme bekomme ich?
+* Wie kann man den besten Nutzen aus NoSQL-Datenbanken ziehen?
+* Welche Fähigkeiten und Wissen sind erforderlich?
+* Wie müssen NoSQL-Datenbanken in die Architektur berücksichtigt werden?
 
 Weitere Themen in diesem Zusammenhang sind Event Sourcing, Eventually Consistency, Skalierbarkeit, Ausfallsicherheit, Lizenzen oder BASE
 
@@ -43,19 +45,19 @@ NoSQL databases are no longer a novelty. In many projects, they are standard, bu
 
 For those who have only dealt with relational databases, it's often hard to imagine how the use of NoSQL databases can be successful:
 
-- What possibilities do these databases offer and what benefits do they bring?
-- What types of NoSQL databases are there and what can they be used for?
-- Are there dangers one should be aware of?
+* What possibilities do these databases offer and what benefits do they bring?
+* What types of NoSQL databases are there and what can they be used for?
+* Are there dangers one should be aware of?
 
 This topic is of interest to architects, developers, operations, DB administrators.
 
 ==== Assignment
 These questions should be answered:
 
-- What problems can be solved with NoSQL databases and what new problems might arise?
-- How can one get the best use out of NoSQL databases?
-- What skills and knowledge are required?
-- How must NoSQL databases be considered in the architecture?
+* What problems can be solved with NoSQL databases and what new problems might arise?
+* How can one get the best use out of NoSQL databases?
+* What skills and knowledge are required?
+* How must NoSQL databases be considered in the architecture?
 
 Other topics in this context include Event Sourcing, Eventual Consistency, Scalability, Fail-Safety, Licenses, or BASE.
 

diff --git a/docs/01-themenspeicher/06-frontend-entwicklung-große-Projekte.adoc b/docs/01-themenspeicher/06-frontend-entwicklung-große-Projekte.adoc
@@ -28,12 +28,12 @@ Dazu gehören u. a. Folgende:
 
 ==== Referenzen
 
-- Micro Frontends, https://micro-frontends.org/
-- Self Contained Systems, https://scs-architecture.org/
-- Backends for Frontends Pattern - Cloud Design Patterns, https://docs.microsoft.com/en-us/azure/architecture/patterns/backends-for-frontends
-- Angular Material, https://material.angular.io/
-- Nx Monorepo, https://nx.dev/
-- Webpack Module Federation, https://webpack.js.org/concepts/module-federation/
+* Micro Frontends, https://micro-frontends.org/
+* Self Contained Systems, https://scs-architecture.org/
+* Backends for Frontends Pattern - Cloud Design Patterns, https://docs.microsoft.com/en-us/azure/architecture/patterns/backends-for-frontends
+* Angular Material, https://material.angular.io/
+* Nx Monorepo, https://nx.dev/
+* Webpack Module Federation, https://webpack.js.org/concepts/module-federation/
 
 ==== Gruppengröße
 
@@ -69,12 +69,12 @@ This includes, among others:
 
 ==== References
 
-- Micro Frontends, https://micro-frontends.org/
-- Self Contained Systems, https://scs-architecture.org/
-- Backends for Frontends Pattern - Cloud Design Patterns, https://docs.microsoft.com/en-us/azure/architecture/patterns/backends-for-frontends
-- Angular Material, https://material.angular.io/
-- Nx Monorepo, https://nx.dev/
-- Webpack Module Federation, https://webpack.js.org/concepts/module-federation/
+* Micro Frontends, https://micro-frontends.org/
+* Self Contained Systems, https://scs-architecture.org/
+* Backends for Frontends Pattern - Cloud Design Patterns, https://docs.microsoft.com/en-us/azure/architecture/patterns/backends-for-frontends
+* Angular Material, https://material.angular.io/
+* Nx Monorepo, https://nx.dev/
+* Webpack Module Federation, https://webpack.js.org/concepts/module-federation/
 
 ==== Group Size
 

diff --git a/docs/01-themenspeicher/07-maschinelles-lernen-in-der-praxis.adoc b/docs/01-themenspeicher/07-maschinelles-lernen-in-der-praxis.adoc
@@ -16,11 +16,11 @@ Der Beitrag soll Mut machen, einen Einstieg in dieses Thema zu finden.
 
 Es gibt viele Dinge zu klären:
 
-- Welche Probleme lassen sich mit ML lösen?
-- Welcher Aufwand steckt dahinter?
-- Welche Fähigkeiten und Wissen sind bei der Umsetzung erforderlich?
-- Welche rechtlichen Einflüsse müssen beachtet werden?
-- Was sind die Erfolgsfaktoren?
+* Welche Probleme lassen sich mit ML lösen?
+* Welcher Aufwand steckt dahinter?
+* Welche Fähigkeiten und Wissen sind bei der Umsetzung erforderlich?
+* Welche rechtlichen Einflüsse müssen beachtet werden?
+* Was sind die Erfolgsfaktoren?
 
 ==== Referenzen
 
@@ -48,11 +48,11 @@ The contribution should encourage finding an entry point into this topic.
 
 There are many things to clarify:
 
-- What problems can be solved with ML?
-- What effort is involved?
-- What skills and knowledge are required for implementation?
-- What legal considerations must be taken into account?
-- What are the success factors?
+* What problems can be solved with ML?
+* What effort is involved?
+* What skills and knowledge are required for implementation?
+* What legal considerations must be taken into account?
+* What are the success factors?
 
 ==== References
 

diff --git a/docs/01-themenspeicher/09-modellierungssprachen.adoc b/docs/01-themenspeicher/09-modellierungssprachen.adoc
@@ -13,21 +13,22 @@ Die Verwendung von Modellierungssprachen ist nicht immer beliebt. Sie werden oft
 ==== Aufgabenstellung
 
 Die Themenarbeitsgruppe soll folgende Fragen diskutieren und die Erkenntnisse aufbereiten:
-- Welche Erfahrungen wurden in den eigenen Projekten mit UML und deren Alternativen gemacht?
-- Wann reichen informelle Modelle und wann ist eine formelle Modellierungssprache zu empfehlen?
-- Wie lassen sich Entwicklungsteams davon überzeugen zumindest teilweise UML zu verwenden?
-- Welche bewährte Praktiken gibt es beim Einsatz von UML?
+
+* Welche Erfahrungen wurden in den eigenen Projekten mit UML und deren Alternativen gemacht?
+* Wann reichen informelle Modelle und wann ist eine formelle Modellierungssprache zu empfehlen?
+* Wie lassen sich Entwicklungsteams davon überzeugen zumindest teilweise UML zu verwenden?
+* Welche bewährte Praktiken gibt es beim Einsatz von UML?
 
 ==== Referenzen
 
-- UML (Unified Modelling Language), https://www.uml.org/
-- C4 model, https://c4model.com/
-- FMC (Fundamental Modelling Concepts), http://www.fmc-modeling.org
-- ArchiMate, https://www.opengroup.org/archimate-forum/archimate-overview
-- Semantics of a Foundational Subset for Executable UML Models (fUML)
-- Action Language for Foundational UML (ALF)
-- Precise Semantics of UML Composite Structures (PSCS)
-- Precise Semantics of UML State Machines (PSSM)
+* UML (Unified Modelling Language), https://www.uml.org/
+* C4 model, https://c4model.com/
+* FMC (Fundamental Modelling Concepts), http://www.fmc-modeling.org
+* ArchiMate, https://www.opengroup.org/archimate-forum/archimate-overview
+* Semantics of a Foundational Subset for Executable UML Models (fUML)
+* Action Language for Foundational UML (ALF)
+* Precise Semantics of UML Composite Structures (PSCS)
+* Precise Semantics of UML State Machines (PSSM)
 
 ==== Gruppengröße
 
@@ -50,21 +51,21 @@ The use of modeling languages is not always popular. They are often seen as too
 
 The working group should discuss the following questions and prepare the findings:
 
-- What experiences have been made with UML and its alternatives in their own projects?
-- When are informal models sufficient, and when is a formal modeling language recommended?
-- How can development teams be convinced to use at least some UML?
-- What are the proven practices in the use of UML?
+* What experiences have been made with UML and its alternatives in their own projects?
+* When are informal models sufficient, and when is a formal modeling language recommended?
+* How can development teams be convinced to use at least some UML?
+* What are the proven practices in the use of UML?
 
 ==== References
 
-- UML (Unified Modelling Language), https://www.uml.org/
-- C4 model, https://c4model.com/
-- FMC (Fundamental Modelling Concepts), http://www.fmc-modeling.org
-- ArchiMate, https://www.opengroup.org/archimate-forum/archimate-overview
-- Semantics of a Foundational Subset for Executable UML Models (fUML)
-- Action Language for Foundational UML (ALF)
-- Precise Semantics of UML Composite Structures (PSCS)
-- Precise Semantics of UML State Machines (PSSM)
+* UML (Unified Modelling Language), https://www.uml.org/
+* C4 model, https://c4model.com/
+* FMC (Fundamental Modelling Concepts), http://www.fmc-modeling.org
+* ArchiMate, https://www.opengroup.org/archimate-forum/archimate-overview
+* Semantics of a Foundational Subset for Executable UML Models (fUML)
+* Action Language for Foundational UML (ALF)
+* Precise Semantics of UML Composite Structures (PSCS)
+* Precise Semantics of UML State Machines (PSSM)
 
 ==== Group Size
 

diff --git a/docs/01-themenspeicher/10-solid-versus-cupid.adoc b/docs/01-themenspeicher/10-solid-versus-cupid.adoc
@@ -8,27 +8,27 @@ Status: Freigegeben
 
 In den letzten Jahren gab es vermehrt Stimmen, die behaupteten, dass die SOLID-Prinzipien nicht mehr zeitgemäß wären. So sorgte etwa 2021 Dan North für Aufregung, als er behauptete, jedes einzelne SOLID-Prinzip wäre falsch. Nach etwas Zeit legte er nach und schlug als Alternative seine sogenannten „CUPID-Properties“ vor:
 
-- Composable
-- Unix Philosophy
-- Predictable
-- Idiomatic
-- Domain-based
+* Composable
+* Unix Philosophy
+* Predictable
+* Idiomatic
+* Domain-based
 
 ==== Aufgabenstellung
 
 Die Themenarbeitsgruppe soll folgende Fragen klären:
 
-- Welche Kritikpunkte gibt es an SOLID und können sie wissenschaftlich bestätigt werden?
-- Erfüllt CUPID alle Anforderungen, um als Orientierung bei der Software-Entwicklung zu dienen?
-- Gibt es Gemeinsamkeiten zwischen SOLID und CUPID?
-- Gibt es Einsatzgebiete, die sich besonders für SOLID oder für CUPID eignen?
-- Gibt es auch andere Sammlungen von Prinzipien, an denen sich Entwickler orientieren können?
+* Welche Kritikpunkte gibt es an SOLID und können sie wissenschaftlich bestätigt werden?
+* Erfüllt CUPID alle Anforderungen, um als Orientierung bei der Software-Entwicklung zu dienen?
+* Gibt es Gemeinsamkeiten zwischen SOLID und CUPID?
+* Gibt es Einsatzgebiete, die sich besonders für SOLID oder für CUPID eignen?
+* Gibt es auch andere Sammlungen von Prinzipien, an denen sich Entwickler orientieren können?
 
 ==== Referenzen
 
-- Principles Of Object Oriented Design, http://wiki.c2.com/?PrinciplesOfObjectOrientedDesign
-- CUPID—the back story, https://dannorth.net/2021/03/16/cupid-the-back-story/
-- CUPID—for joyful coding, https://dannorth.net/2022/02/10/cupid-for-joyful-coding/
+* Principles Of Object Oriented Design, http://wiki.c2.com/?PrinciplesOfObjectOrientedDesign
+* CUPID—the back story, https://dannorth.net/2021/03/16/cupid-the-back-story/
+* CUPID—for joyful coding, https://dannorth.net/2022/02/10/cupid-for-joyful-coding/
 
 ==== Gruppengröße
 
@@ -45,27 +45,27 @@ Status: Approved
 
 In recent years, there have been increasing voices claiming that the SOLID principles are no longer contemporary. For instance, in 2021, Dan North caused a stir when he claimed that every single SOLID principle was wrong. After some time, he followed up and proposed his so-called "CUPID-Properties" as an alternative:
 
-- Composable
-- Unix Philosophy
-- Predictable
-- Idiomatic
-- Domain-based
+* Composable
+* Unix Philosophy
+* Predictable
+* Idiomatic
+* Domain-based
 
 ==== Assignment
 
 The working group should clarify the following questions:
 
-- What are the criticisms of SOLID, and can they be scientifically validated?
-- Does CUPID meet all the requirements to serve as a guide in software development?
-- Are there commonalities between SOLID and CUPID?
-- Are there areas of application that are particularly suitable for SOLID or for CUPID?
-- Are there other collections of principles that developers can follow?
+* What are the criticisms of SOLID, and can they be scientifically validated?
+* Does CUPID meet all the requirements to serve as a guide in software development?
+* Are there commonalities between SOLID and CUPID?
+* Are there areas of application that are particularly suitable for SOLID or for CUPID?
+* Are there other collections of principles that developers can follow?
 
 ==== References
 
-- Principles Of Object-Oriented Design, http://wiki.c2.com/?PrinciplesOfObjectOrientedDesign
-- CUPID—the back story, https://dannorth.net/2021/03/16/cupid-the-back-story/
-- CUPID—for joyful coding, https://dannorth.net/2022/02/10/cupid-for-joyful-coding/
+* Principles Of Object-Oriented Design, http://wiki.c2.com/?PrinciplesOfObjectOrientedDesign
+* CUPID—the back story, https://dannorth.net/2021/03/16/cupid-the-back-story/
+* CUPID—for joyful coding, https://dannorth.net/2022/02/10/cupid-for-joyful-coding/
 
 ==== Group Size