diff --git a/docs/05-approaches/02-learning-goals.adoc b/docs/05-approaches/02-learning-goals.adoc index e55fed0..899323d 100644 --- a/docs/05-approaches/02-learning-goals.adoc +++ b/docs/05-approaches/02-learning-goals.adoc @@ -12,17 +12,17 @@ [[LZ-5-2]] ==== LZ 5-2: Verbesserungsmaßnahmen im Quellcode -* Für Technologien/Programmiersprachen typische Refactorings (bedeutungserhaltende Vereinfachungsmassnahmen im Quellcode) kennen und anwenden können. In Schulungen sollten bei Bedarf entsprechende Übungen durchgeführt werden. +* Für Technologien/Programmiersprachen typische Refactorings (verhaltenserhaltende Vereinfachungsmaßnahmen im Quellcode) kennen. * Technologien besser nutzen und bessere Technologie einführen (Technologiewechsel). * Zusammenhang zwischen technischen Schulden und Refactoring erklären können. -* Maßnahmen und Muster zur Reduktion von Kopplung in Quellcode kennen und anwenden können. -* Maßnahmen und Muster zur Verbesserung der Verständlichkeit von Quellcode kennen und anwenden können, beispielsweise Clean-Code-Prinzipien. +* Maßnahmen und Muster zur Reduktion von Kopplung in Quellcode kennen und beurteilen können. +* Maßnahmen und Muster zur Verbesserung der Verständlichkeit von Quellcode kennen, beispielsweise Clean-Code-Prinzipien. [[LZ-5-3]] ==== LZ 5-3: Möglichkeiten des automatisierten Tests zur Reduktion von Änderungsrisiken -* Automatisierte Tests (Unit-, Integrations-, Akzeptanz-, Regressionstests) als Mittel zur Früherkennung von Fehlern in Änderungs- oder Verbesserungsprojekten kennen und selbständig anwenden können (In Schulungen sollten bei Bedarf entsprechende Übungen durchgeführt werden). -* Selbständig identifizieren können, an welchen Stellen/Schnittstellen/Komponenten die Einführung automatisierter Tests für bestimmte Änderungsszenarien angemessen ist. +* Anwendungsmöglichkeiten von automatisierten Tests (Unit-, Integrations-, Akzeptanz-, Regressionstests) als Mittel zur Früherkennung von Fehlern in Änderungs- oder Verbesserungsprojekten kennen. +* Identifizieren können, an welchen Stellen/Schnittstellen/Komponenten die Einführung automatisierter Tests für bestimmte Änderungsszenarien angemessen ist. [[LZ-5-4]] ==== LZ 5-4: Automatisierung als Mittel zur Reduktion von Änderungsrisiken @@ -74,17 +74,17 @@ Grundlegende Möglichkeiten zur systematischen Verbesserung von technischer Doku [[LG-5-2]] ==== LG 5-2: Improvement measures for source code -* Know and being able to apply typical technology/programming language-specific refactorings (semantics preserving simplification measures in source code). Training should conduct exercises if required. +* Know and assess typical technology/programming language-specific refactorings (semantics preserving simplification measures in source code). * Better use of technology or use better technology (change of technology). * Explain the connection between technical debts and refactoring. -* Know and be able to apply measures and patterns to reduce coupling at source code level. -* Know and be able to apply measures and patterns to make source code more comprehensible, e.g., Clean Code principles. +* Know and be able to assess measures and patterns to reduce coupling at source code level. +* Know measures and patterns to make source code more comprehensible, e.g., Clean Code principles. [[LG-5-3]] ==== LG 5-3: Possible approaches for automated testing to reduce risks of change -* Know and being able to autonomously apply automated tests (unit-, integration-, acceptance-, regression-tests) as a means of early detection of defects in change or improvement projects. (Training should provide exercises if required.) -* Being able to autonomously identify adequate locations/interfaces/components where the introduction of automated tests will be suitable for specific change scenarios. +* Know how to apply automated tests (unit-, integration-, acceptance-, regression-tests) as a means of early detection of defects in change or improvement projects. +* Being able to identify adequate locations/interfaces/components where the introduction of automated tests will be suitable for specific change scenarios. [[LG-5-4]] ==== LG 5-4: Automation as a means of reducing risks of changes diff --git a/docs/06-examples/01-duration-terms.adoc b/docs/06-examples/01-duration-terms.adoc index 5181236..409271e 100644 --- a/docs/06-examples/01-duration-terms.adoc +++ b/docs/06-examples/01-duration-terms.adoc @@ -7,11 +7,11 @@ **Anmerkung**: === Begriffe und Konzepte -Innerhalb jeder lizenzierten Schulung muss mindestens ein Beispiel für IMPROVE vorgestellt werden. +Innerhalb jeder lizenzierten Schulung muss mindestens ein Beispiel für eine zu verbessernde Softwarearchitektur vorgestellt werden. Beispiele für Verbesserungsprojekte realer Systeme können von Trainer:innen und Schulungsanbietern individuell ausgewählt werden und werden vom iSAQB^(R)^ e. V. nicht vorgegeben. -Beispiele für Verbesserungsprojekte realer Systeme können durch Trainer und Schulungsanbieter individuell ausgesucht werden und werden seitens iSAQB nicht vorgegeben. +Hinweis: Das Hauptziel von IMPROVE ist es, Ideen zur Verbesserung von Softwarearchitekturen und nicht nur von Code zu liefern. Die Beispiele können Code und andere Low-Level-Artefakte enthalten, sollten sich aber nicht primär auf reine Refactorings bestehender Codebasen (z.B. durch den Einsatz von IDEs) konzentrieren. -Aufgrund der bei realen IT-Systemen oftmals geltenden Geheimhaltungs- oder Vertraulichkeitsregelungen stellt der iSAQB e. V. Schulungsanbietern und Trainern frei, Beispiele abstrahiert oder nur auszugsweise in Schulungen zu zeigen. +Aufgrund der bei realen IT-Systemen oftmals geltenden Geheimhaltungs- oder Vertraulichkeitsregelungen stellt der iSAQB^(R)^ e. V. Schulungsanbietern und Trainern frei, Beispiele abstrahiert oder nur auszugsweise in Schulungen zu zeigen. // end::DE[] @@ -25,10 +25,10 @@ Aufgrund der bei realen IT-Systemen oftmals geltenden Geheimhaltungs- oder Vertr === Terms and concepts -At least one example of IMPROVE must be presented within each licensed course. +At least one example of a software architecture to be improved must be presented within each licensed course. Examples for improvement projects of real systems can be individually selected by trainers and training providers and are not specified by the iSAQB^(R)^ e. V.. -Examples for improvement projects of real systems can be individually selected by trainers and training providers and are not specified by iSAQB. +Note: The main goal of IMPROVE is to deliver ideas for improving software architectures and not just code. The examples can include code and other low-level artifacts, but should not primarily focus on pure refactorings of existing code bases (e.g. by using IDEs). -Due to the secrecy or confidentiality regulations that often apply to real IT systems, iSAQB e. V. allows training providers and trainers to show examples in abstract or only in extracts in training courses. +Due to the secrecy or confidentiality regulations that often apply to real IT systems, iSAQB^(R)^ e. V. allows training providers and trainers to show examples in abstract or only in extracts in training courses. // end::EN[]