Der Software auf den Zahn gefühlt - Einstieg in die Architekturbewertung

125.11.2020
„Der Software auf den Zahn gefühlt“
Einstieg in die Architekturbewertung

225.11.2020
Sprecher
Hendrik Lösch
Senior Consultant
@HerrLoesch
hendrik.loesch@zeiss.com
hendrik-loesch.de
https://www.linkedin.com/learning/instructors/hendrik-losch

325.11.2020
ZEISS Gruppe
Zukunft gestalten
Sparten
der ZEISS Gruppe
Semiconductor Manufactoring
Technology
 Semiconductor Manufactoring
Optics
 Semiconductor Mask Solutions
 Process Control Solutions
Industry Quality & Research
 Industrial Quality Solutions
 Research Microscopy Solutions
Medical Technology
 Ophthalmic Devices
 Microsurgery
Consumer Markets
 Vision Care
 Consumer Products

425.11.2020
ZEISS Digital Innovation
Strategische Synergien schaffen
Innovative Digitalisierungsprojekte mit und für die Kunden von ZEISS
Sparten
der ZEISS Gruppe
Semiconductor Manufactoring
Technology
Industry Quality & Research Medical Technology Consumer Markets

625.11.2020
Ziel des Workshops
Methodisches Handwerkszeug der
Architekturbewertung vermitteln.

725.11.2020
Softwarearchitektur

825.11.2020
Einflussfaktoren auf Softwarearchitektur
Nichtfunktional
e
Anforderungen
Funktionale
Anforderungen

925.11.2020
Anpassbarkeit
Business Value
Featureentwicklung mit
geringem Qualitätsanspruch
Featureentwicklung
unter hohem Zeitdruck
Umfassende
Restrukturierung inkl.
neuer Features
Einsatz von
Refactoring
Start der
Entwicklung
Anpassbarkeit

1025.11.2020
Development Costs
Operating Costs
Costs
t
Close
Down
ServicingEvolutionInitial Development Phase Out
Kosten

1125.11.2020
Architekturbewertung?

1225.11.2020
Nachvollziehbar
Angemessen
Anpassbar
Konsistent
Was wird bewertet?

1325.11.2020
Transparenz &
Dokumentation
Risiken erkennen &
bewerten
Planungsgrundlagen
schaffen
Effizienz steigern
Ziele
Ziele einer Bewertung

1425.11.2020
Risiko
gering hoch
mittel
Risikomanagement

1525.11.2020
Kontext
herstellen
Risiken
identifizieren
Risiken
analysieren
Risiken
bewerten
Risiken
behandeln
Überwachen
&Prüfen
Architekturbewertung
Basierend auf ISO 31000
Vorgehen des Risikomanagements

1625.11.2020
Unbewusst Bewusst Definiert Gemanagt Etabliert
Reifegrad
Reifegrade des Risikomanagements

1725.11.2020
Transparenz &
Dokumentation
Risiken erkennen &
bewerten
Planungsgrundlagen
schaffen
Effizienz steigern
Ziele
Ziele einer Bewertung

1825.11.2020
Transparenz Risiken
Planung Effizienz
Transparenz Risike
n
Planung Effizienz
Transparenz Risiken
Planung Effizienz
Transparenz Risiken
Planung
Transparenz Risiken
Planu
ng Effizienz

2125.11.2020
Risiko Konzept Umsetzung Sollzustand
1
2
3
4
5
…

2225.11.2020
Basierend auf IBM Issue BasedConsulting
Vorbereitung

2325.11.2020
Vorbereitung Analyse

2425.11.2020
Vorbereitung Analyse Bewertung

2525.11.2020
Vorbereitung Analyse Bewertung Empfehlung

2625.11.2020
Vorbereitung Analyse Bewertung Empfehlung Abschluss

2725.11.2020

2825.11.2020

3025.11.2020
Stakeholder
Basierend auf: https://de.wikipedia.org/wiki/Stakeholder
Externe
Stakeholder
Interne
Stakeholder
Lieferanten
Gesellschaft
Unternehmen Staat
Gläubiger
Kunden
Mitarbeiter
Manager
Eigentümer

3125.11.2020
Stakeholder
„Der Stakeholder ist […] jemand, dessen Einsatz
auf dem Spiel steht und der daher ein Interesse
an Wohl und Wehe dieses Einsatzes hat.“
Quelle: https://de.wikipedia.org/wiki/Stakeholder

3225.11.2020
Team
Extern
Team
Intern
Stakeholder in einem Softwareprojekt
Productowner
Support
Software Nutzer
Sales
Management
Entwickler
Architekten
Tester

3325.11.2020
Anpassbarkeit vs. Business Value
Innere Qualität /
Anpassbarkeit
Business Value
Featureentwicklung mit
geringem Qualitätsanspruch
Featureentwicklung
unter hohem Zeitdruck
Entfernen fehlerhafter
Bestandteile
Umfassende
Restrukturierung inkl.
neuer Features
Einsatz der
Pfadfinderregel
Start der
Entwicklung

3425.11.2020
Stimmungen beachten
Begeisterung Interesse Desinteresse Abneigung

3525.11.2020
Stimmungen beeinflussen
Abneigung
Desinteresse
Begeisterung
Interesse

3625.11.2020
Vertrauen
Investment
Feedback
Erwartungen lenken

3725.11.2020
Stimmungen lenken

3825.11.2020
Hierarchien und Tragweite

3925.11.2020
Restrukturierung
Migration Portierung Sanierung
Refactoring

4025.11.2020
Architecture-Driven Modernization: Transforming the Enterprise, Dr. Vitaly Khusidman, Wiliam Ulrich 2017

4125.11.2020
IT Domain
Quelle: Architecture-Driven Modernization: Transforming the Enterprise, Dr. Vitaly Khusidman, Wiliam Ulrich 2017

4225.11.2020
Business Domain
IT Domain

4325.11.2020
Business Architecture
Application & Data Architecture
Technical Architecture
Business Domain
IT Domain

4425.11.2020
B
A
T
B
A
T
Business Domain
IT Domain

4525.11.2020
B
A
T
Target SolutionExisting Solution
B
A
T
Business Domain
IT Domain

4625.11.2020
B
A
T
B
A
TTechnical Architecture-Driven

4725.11.2020
B
A
T
B
A
T
Application/Data Architecture-Driven

4825.11.2020
B
A
T
B
A
T

4925.11.2020
B
A
T
B
A
T
Business Architecture-Driven

5025.11.2020
B
A
T
B
A
T

5125.11.2020
B
A
T
B
A
T
Application/Dara Architecture-Driven
Technical Architecture-Driven

5225.11.2020
B
A
T
B
A
T
Code Restrukturierung
&
Refactorings

5325.11.2020
B
A
T
B
A
T
Code Restrukturierung
&
Refactorings

5425.11.2020
Je mehr Personen integriert werden, desto höher die
Erwartungshaltung!

5725.11.2020
Stakeholder-Map
Realbeispiel

5825.11.2020
Stakeholder Map
Meet their needs
Keep satisified
Key player
Engage closely
Least important
Monitor
Show consideration
Keep informed
Basierend auf: Mendelow, A. L. (1981) ‘Environmental Scanning: The Impact of the Stakeholder Concept’
Influence
Interest

5925.11.2020
Stakeholder Map
Keep satisified Key player
Monitor Show consideration
Influence
Interest

6125.11.2020
Stakeholder Map
Im Falle von wertsteigernden Maßnahmen
Influence
Interest
Controlling
Vertrieb
Einkauf
PO
Personal
Entwicklungsteam
Gruppenleiter

6225.11.2020
Stakeholder Map
Im Falle von werterhaltenden Maßnahmen
Influence
Interest
Gruppenleiter
Controlling
Vertrieb
Einkauf
PO
Personal
Entwicklungsteam

6425.11.2020
Für Nutzer nicht direkt sichtbar
ISO25010

6525.11.2020
ISO25010

6625.11.2020
Benutzbarkeit
ISO 25010
Erlernbarkeit
Bedienbarkeit
Ästhetik
Barrierefreiheit

6725.11.2020
Funktionalität
Benutzbarkeit
ISO 25010
Angemessenh
eit
Korrektheit
Vollständigkeit

6825.11.2020
Zuverlässigkeit
Funktionalität
Benutzbarkeit
ISO 25010
Ausgereiftheit
Verfügbarkeit
Fehlertoleranz
Wiederherstell
-barkeit

6925.11.2020
Effizienz
Zuverlässigkeit
Funktionalität
Benutzbarkeit
ISO 25010
Antwortzeitverhalte
n
Ressourceneinsatz
Kapazität

7025.11.2020
Wartbarkeit
Effizienz
Zuverlässigkeit
Funktionalität
Benutzbarkeit
ISO 25010
Analysierbarkeit
Modifizierbarkeit
Modularität
Wiederverwendbarke
it

7125.11.2020
Kompatibilität
Wartbarkeit
Effizienz
Zuverlässigkeit
Funktionalität
Benutzbarkeit
ISO 25010
Interoperabilität
Koexistenz

7225.11.2020
Kompatibilität
Wartbarkeit
Effizienz
Zuverlässigkeit
Funktionalität
Benutzbarkeit
Übertragbarkeit
ISO 25010
Anpassungsfähigk
eit
Installierbarkeit
Austauschbarkeit

7325.11.2020
Kompatibilität
Wartbarkeit
Effizienz
Zuverlässigkeit
Funktionalität
Benutzbarkeit
Sicherheit
Übertragbarkeit
ISO 25010
Authenzität
Integrität
Nachweisbarkeit
Vertraulichkeit

7425.11.2020
Benutzbarkeit Sicherheit

7525.11.2020
Benutzbarkeit
Sicherheit

7625.11.2020
Benutzbarkei
t
Sicherheit

7725.11.2020
Wartbarkeit Effizienz

7825.11.2020

7925.11.2020

8025.11.2020
Kompatibilität
Wartbarkeit
Effizienz
Zuverlässigkeit
Funktionalität
Benutzbarkeit
Sicherheit
Übertragbarkeit
ISO 25010

8125.11.2020
Kompatibilität
Wartbarkeit
Effizienz
Zuverlässigkeit
Funktionalität
Benutzbarkeit
Sicherheit
Übertragbarkeit
ISO 25010

8225.11.2020
Qualitätsmerkmale
Functionality
• This characteristic represents the
degree to which a product or
system provides functions that
meet stated and implied needs
when used under specified
conditions.
Efficiency
performance relative to the amount
of resources used under stated
conditions.
Compatibility
• Degree to which a system or
component can exchange
information with other systems or
components, and/or perform its
required functions, while sharing
the same hardware or software
environment.
Usability
• Degree to which a product or
system can be used by specified
users to achieve specified goals
with effectiveness, efficiency and
satisfaction in a specified context of
use.
Reliability
• Degree to which a system,
product or component performs
specified functions under specified
conditions for a specified period of
time.
Security
• Degree to which a product or
system protects information and
data so that persons or other
products or systems have the
degree of data access appropriate
to their types and levels of
authorization.
Maintainability
degree of effectiveness and
efficiency with which a product or
system can be modified to improve
it, correct it or adapt it to changes
in environment, and in
requirements.
Portability
• Degree of effectiveness and
efficiency with which a system,
product or component can be
transferred from one hardware,
software or other operational or
usage environment to another.

8525.11.2020
Situations-
beschreibun
g
Anwendungs
beschreibun
g
Akzeptanz-
kriterien
Qualitäts-
szenario
Qualitätsszenarien

8625.11.2020
Nutzungsszenarien
Änderungsszenarien
Stressszenarien
Qualitätsszenarien

8725.11.2020
„Änderungen an den Daten müssen sofort
zur Verfügung stehen!“
Qualitätsszenarien

8825.11.2020
Qualitätsszenarien
 Stimulus
 Quelle
 Umgebung
 Artefakt
 Antwort
 Antwortmaß
Quelle: Rick Kazman, Paul Clements, Len Bass - Software Architecture in Practice, Third
Inhalte

8925.11.2020
„Die Verfügbarkeit muss sofort
ermittelt werden!“
Qualitätsszenarien

9025.11.2020
Effizienz
„Bei einer Bestellung durch einen Kunden
muss das System in 10 Sekunden einen
Abgleich mit der Lagerverwaltung vornehmen
und eine Aussage über die Verfügbarkeit
erstellen.“
Qualitätsszenarien

9125.11.2020
Stimulus
erstellen.“
Qualitätsszenarien

9225.11.2020
Quelle
erstellen.“
Qualitätsszenarien

9325.11.2020
Umgebung
erstellen.“
Qualitätsszenarien

9425.11.2020
Artefakt
erstellen.“
Qualitätsszenarien

9525.11.2020
Antwort
erstellen.“
Qualitätsszenarien

9625.11.2020
Antwortmaß
erstellen.“
Qualitätsszenarien

9725.11.2020
Qualitätsszenarien & Qualitätsbaum
# Merkmal Kurzbeschreibung
S1 Effizienz Bestellung in 10 Sekunden bestätigt
S2 Effizienz Verarbeitung von 100.000 Bestellungen pro Tag
S3 Wartbarkeit Einarbeitung neuer Softwareentwickler
S4 Wartbarkeit Erweiterung um neue Produktkategorie
S5 Benutzbarkeit Einarbeitung neuer Nutzer
S6 Zuverlässigkeit Wiederherstellung nach Totalausfall
S7 Zuverlässigkeit Verfügbar 98,999% des Jahres
…

9825.11.2020
Qualität
Funktionalität
Zuverlässigkeit
Effizienz
Wartbarkeit
Kompatibilität
Benutzbarkeit
Übertragbarkeit
Sicherheit

9925.11.2020
Qualität
Funktionalität
Zuverlässigkeit
Effizienz
Wartbarkeit
Kompatibilität
Benutzbarkeit
Übertragbarkeit
Sicherheit
S5
S6
S7
S1
S2
S3
S4

10025.11.2020
# Merkmal Kurzbeschreibung Stimmen
S1 Effizienz Bestellung in 10 Sekunden bestätigt 4
S2 Effizienz Verarbeitung von 100.000 Bestellungen pro Tag 3
S3 Wartbarkeit Einarbeitung neuer Softwareentwickler 9
S4 Wartbarkeit Erweiterung um neue Produktkategorie 8
S5 Benutzbarkeit Einarbeitung neuer Nutzer 2
S6 Zuverlässigkeit Wiederherstellung nach Totalausfall 5
S7 Zuverlässigkeit Verfügbar 98,999% des Jahres 5
…

10125.11.2020
Qualität
Zuverlässigkeit
Effizienz
Benutzbarkeit
Funktionalität
Kompatibilität
Wartbarkeit
Übertragbarkeit
Sicherheit
S5
S6
S7
S1
S2
S3
S4

10225.11.2020
Problemwahr-
scheinlichkeit
Wichtigkeit
äußerst wichtig
sehr wichtig
wichtig
unwichtig
keine gering mittel hoch

10325.11.2020
Qualität
Zuverlässigkeit
Effizienz
Benutzbarkeit
Funktionalität
Kompatibilität
Wartbarkeit
Übertragbarkeit
Sicherheit
S5
S6
S7
S1
S2
S3
S4

10425.11.2020
Übersicht
Problemwahr-
scheinlichkeit
Wichtigkeit
äußerst wichtig
sehr wichtig
wichtig
unwichtig
keine gering mittel hoch
S
1
S
4
S
2
S
3
S
5
S6
&
S7
S1 Bestellung in 10 Sekunden bestätigt
S2 Verarbeitung von 100.000 Bestellungen pro
Tag
S3 Einarbeitung neuer Softwareentwickler
S4 Erweiterung um neue Produktkategorie
S5 Einarbeitung neuer Nutzer
S6 Wiederherstellung nach Totalausfall
S7 Verfügbar 98,999% des Jahres

10525.11.2020
Befragen Brainstorming Mindmaps
Quellen

10725.11.2020
Maßnahmen
Entwicklung
Weiter-
entwicklung
Weiter-
entwicklung
Weiter-
entwicklung
Stabilisierung
Optimierung
Sanierung
Stabilisierung
Stabilisierung
Optimierung
t in Jahren
Wertsteigernd
Werterhaltend
Basierend auf: Tom Gilb, Evolutionary Delivery vs Waterfall Model, ACM Software Engineering Notes, Juli 1985

10825.11.2020
Ursprünglich geplante Restrukturierungs-Roadmap
1 2 3 4

10925.11.2020
Roadmap während der Restrukturierung
!
!
!
!
!
!
!
!
!
!
!
!

11025.11.2020
Der Lösungsraum

11125.11.2020
Der Lösungsraum
!

11225.11.2020
Strategische Roadmap
1
2
3
4

11325.11.2020
Strategische Roadmap
1
2
3 4

11425.11.2020
Issue-Backlog
Quelle: https://www.merriam-webster.com/dictionary/issue

11525.11.2020
Issue Auswirkungen Betroffene Stakeholder
Keine Zielarchitektur
vorhanden
Änderungen werden unstrukturiert vorgenommen. Unterschiedliche Muster
werden eingesetzt. Es besteht eine beschleunigt Architekturerrosion.
Entwicklungsteams werden in ihrer direkten Arbeit
behindert.
Fachabteilungen merken, dass ähnliche Vorgänge sehr
unterschiedliche Arbeitsabläufe aufweisen.
Geringe Testabdeckung Sehr hoher Testaufwand. IT Abteilung bindet Ressourcen die in der Entwicklung
gebraucht werden.
Fachabteilungen müssen Personal für den Test abstellen.
Viele Fehler schlagen bis in die Produktivumgebungen durch. Entwicklungsteams brauchen lange um Fehler zu
beheben und verlieren Leistungsfähigkeit.
Fachabteilungen werden in ihrer Arbeit behindert.
Entwickler verbringen
viel Zeit mit Bugfixing.
Es besteht kaum strukturierte Weiterentwicklung weshalb Anforderungen
als Service Requests formuliert werden.
Fachabteilungen verlieren Zeit, da sie für Kernaufgaben
die IT konsultieren müssen.
Entwicklungsteams werden mit zusätzlichen SRs
blockiert.
… … …
Issue-Table

11625.11.2020
vorhanden
behindert.
gebraucht werden.
blockiert.
… … …
Issue-Table

11725.11.2020
vorhanden
behindert.
gebraucht werden.
blockiert.
… … …
Issue-Table

11825.11.2020
vorhanden
werden eingesetzt. Es besteht eine beschleunigte Architekturerrosion.
behindert.
gebraucht werden.
blockiert.
… … …
Issue-Table

11925.11.2020
vorhanden
behindert.
Geringe Testabdeckung Sehr hoher Testaufwand. IT-Abteilung bindet Ressourcen, die in der Entwicklung
gebraucht werden.
blockiert.
… … …
Issue-Table

12025.11.2020
vorhanden
behindert.
gebraucht werden.
Viele Fehler schlagen bis in die Produktivumgebungen durch. Entwicklungsteams brauchen lange, um Fehler zu
beheben, und verlieren Leistungsfähigkeit.
blockiert.
… … …
Issue-Table

12125.11.2020
vorhanden
behindert.
gebraucht werden.
viel Zeit mit Bugfixing
Es besteht kaum strukturierte Weiterentwicklung, weshalb Anforderungen
Entwicklungsteams werden mit zusätzlichen Service
Requests blockiert.
… … …
Issue-Table

12225.11.2020
vorhanden
behindert.
gebraucht werden.
viel Zeit mit Bugfixing
Requests blockiert.
… … …
Issue-Table

12325.11.2020
vorhanden
behindert.
gebraucht werden.
Requests blockiert.
… … …
Issue-Table

12425.11.2020
vorhanden
behindert.
Geringe (< 5 %)
Testabdeckung
Sehr hoher (10 PT pro Release) Testaufwand. IT-Abteilung bindet Ressourcen, die in der Entwicklung
gebraucht werden.
Viele (ca. 5 pro Sprint) Fehler schlagen bis in die Produktivumgebungen
durch.
Entwicklungsteams brauchen lange, um Fehler zu
viel Zeit mit
Bugfixing (48 Story
Points für Bugs &
Incidents)
Es besteht kaum (12 Story Points je Sprint für Features) strukturierte
Weiterentwicklung, weshalb Anforderungen als Service Requests formuliert
werden.
Requests blockiert.
… … …
Issue-Table

12525.11.2020
Issue Auswirkungen Betroffene Stakeholder Maßnahmen
Keine
Zielarchitektur
vorhanden
Änderungen werden unstrukturiert vorgenommen.
Unterschiedliche Muster werden eingesetzt. Es
besteht eine beschleunigte Architekturerrosion.
Entwicklungsteams werden in ihrer
direkten Arbeit behindert.
Fachabteilungen merken, dass ähnliche
Vorgänge sehr unterschiedliche
Arbeitsabläufe aufweisen.
Erstellen einer Zielarchitektur mit
Modulschnitt.
Geringe (< 5 %)
Testabdeckung
Sehr hoher (10 PT pro Release) Testaufwand. IT-Abteilung bindet Ressourcen, die in
der Entwicklung gebraucht werden.
Fachabteilungen müssen Personal für
den Test abstellen.
Definition eines Prozesses für manuelle
Tests.
Modulschnitt.
Durchführung eines Workshops zum
Thema Testautomatisierung.
Viele (ca. 5 pro Sprint) Fehler schlagen bis in die
Produktivumgebungen durch.
Entwicklungsteams brauchen lange, um
Fehler zu beheben, und verlieren
Leistungsfähigkeit.
Fachabteilungen werden in ihrer Arbeit
behindert.
Entwickler
verbringen viel
Zeit mit Bugfixing
(48 Story Points
für Bugs &
Incidents)
Es besteht kaum (12 Story Points je Sprint für
Features) strukturierte Weiterentwicklun,g weshalb
Anforderungen als Service Requests formuliert
werden.
Fachabteilungen verlieren Zeit, da sie für
Kernaufgaben die IT konsultieren
müssen.
Entwicklungsteams werden mit
zusätzlichen Service Requests blockiert.
Einsetzen eines Product Owners, der die
Anfragen vorqualifiziert.
… … …
Issue-Table

12625.11.2020
Issue Auswirkungen Betroffene Stakeholder Maßnahmen
Keine
Zielarchitektur
vorhanden
Änderungen werden unstrukturiert vorgenommen.
Unterschiedliche Muster werden eingesetzt. Es
besteht eine beschleunigte Architekturerrosion.
Entwicklungsteams werden in ihrer
direkten Arbeit behindert.
Fachabteilungen merken, dass ähnliche
Vorgänge sehr unterschiedliche
Arbeitsabläufe aufweisen.
Modulschnitt.
Geringe (< 5 %)
Testabdeckung
Sehr hoher (10 PT pro Release) Testaufwand. IT-Abteilung bindet Ressourcen, die in
der Entwicklung gebraucht werden.
Fachabteilungen müssen Personal für
den Test abstellen.
Definition eines Prozesses für manuelle
Tests.
Modulschnitt.
Durchführung eines Workshops zum
Thema Testautomatisierung.
Viele (ca. 5 pro Sprint) Fehler schlagen bis in die
Produktivumgebungen durch.
Entwicklungsteams brauchen lange, um
Fehler zu beheben, und verlieren
Leistungsfähigkeit.
Fachabteilungen werden in ihrer Arbeit
behindert.
Entwickler
verbringen viel
Zeit mit Bugfixing
(48 Story Points
für Bugs &
Incidents)
Es besteht kaum (12 Story Points je Sprint für
Features) strukturierte Weiterentwicklung, weshalb
Anforderungen als Service Requests formuliert
werden.
Fachabteilungen verlieren Zeit, da sie für
Kernaufgaben die IT konsultieren
müssen.
Entwicklungsteams werden mit
zusätzlichen Service Requests blockiert.
Einsetzen eines Product Owners, der die
Anfragen vorqualifiziert.
… … …
Issue-Table

12725.11.2020
Wie lautet die konkrete Beauftragung?
Keine falschen Erwartungen wecken!
Issue-Table

12925.11.2020
Issues
Issue-Map

13025.11.2020
Issues
Architektur Kein nachvollziehbares
Bootstrapping
Issue-Map

13125.11.2020
Issues
Architektur
Issue-Map
Laufzeit-
verhalten Anwendung braucht lange, um zu
starten
Kein nachvollziehbares
Bootstrapping
Benutzbarkeit Reporterstellung dauert
lang
Funktionalität Es gibt keinen CSV-
Export
Software stürzt gelegentlich
ab

13225.11.2020
Issues
Architektur
Issue-Map
Laufzeit-
verhalten
Software stürzt
gelegentlich ab
Anwendung braucht
lange, um zu starten
Bootstrapping
Benutzbarkeit
Reporterstellung dauert
lang
Funktionalität
Es gibt keinen CSV-
Export
Lädt nicht benötigte Bestandteile
Es treten Fehler bei der
Initialisierung auf
Muss neu gestartet
werden
Datenverlust tritt auf
Mehraufwand durch
erneute Eingabe

13325.11.2020
Issues
Architektur
Issue-Map
Laufzeit-
verhalten
Software stürzt
gelegentlich ab
Anwendung braucht
Bootstrapping
Benutzbarkeit
lang
Funktionalität
Es gibt keinen CSV-
Export
Initialisierung auf
Muss neu gestartet
werden
Mehraufwand durch
erneute Eingabe

13425.11.2020
Issues
Architektur
Issue-Map
Laufzeit-
verhalten
Software stürzt
gelegentlich ab
Anwendung braucht
Bootstrapping
Benutzbarkeit Reporterstellung dauert lang
Export
Initialisierung auf
Muss neu gestartet
werden
Mehraufwand durch
erneute Eingabe
5 von 100 Starts
Im Schnitt 93 Sekunden
2000 (Nutzer) * 1,05 (durch Abstürze) * 93 (Sekunden) = 54h pro Tag!

13525.11.2020
Issue-Map
Es sind zu viele Prozessschritte auszuführen, um einen Datensatz
anzulegen.
Einzelrechnungen werden ungeachtet einer Marginalgrenze
verschickt.
Passwörter in der Datenbank werden nicht verschlüsselt.
Jeder dritte Datenexport enthält ungültige Formatierungen.
Einsparungen erwartbar
Aktueller Zustand verursacht unnötige
Kosten
Risiko ohne aktuelle Auswirkungen
Fehler, die sich aktuell bereits
auswirken

13625.11.2020
Issue-Map
Einsparungen erwartbar
Aktueller Zustand verursacht unnötige
Kosten
Risiko ohne aktuelle Auswirkungen
Fehler, die sich aktuell bereits
auswirken
Hoch
Mittel
Gering

13725.11.2020
Issues
Architektur
Issue-Map
Laufzeit-
verhalten
Software stürzt gelegentlich ab
Anwendung braucht lange, um
zu starten
Kein nachvollziehbares Bootstrapping
Export

13825.11.2020
Issue-Map
Gefällt
Nicht auffällig
Gefällt nicht
Problematisch

13925.11.2020
Issue-Map
Gefällt
Nicht auffällig
Gefällt nicht
Problematisch
Entwicklung
Geschäfts-
führung
Support
Fachabteilung

14025.11.2020
Issues
Architektur
Issue-Map
Laufzeit-
verhalten
zu starten
Export

14125.11.2020
Issues
Architektur
Issue-Map
Laufzeit-
verhalten
zu starten
Export

14225.11.2020
Issues
Architektur
Issue-Map
Laufzeit-
verhalten
Software stürzt
gelegentlich ab
Anwendung braucht
Bootstrapping
Benutzbarkeit
lang
Funktionalität
Es gibt keinen CSV-
Export
Trennung schreibender und
lesender Zugriffe CQRS
Implementierung eines CSV-
Exports
Startreihenfolge modifizieren

14325.11.2020
Issue-Map
Hoher Änderungsaufwand
Geringer Änderungsaufwand
Mittlerer Änderungsaufwand
Keine Änderung vorgesehen

14425.11.2020
Issues
Architektur
Issue-Map
Laufzeit-
verhalten
Software stürzt
gelegentlich ab
Anwendung braucht
Bootstrapping
Benutzbarkeit
lang
Funktionalität
Es gibt keinen CSV-
Export
Trennung schreibender und
lesender Zugriffe CQRS
Exports
Startreihenfolge modifizieren

14525.11.2020
1. Restrukturierung des
Bootstrapping
2. Optimierung der Reporterstellung
Wird nicht umgesetzt:
Reports
Issue-Map

14625.11.2020
Issue-Map
Komplexbeispiel ohne Auswirkungen und Maßnahmen

14725.11.2020
Issue Map
Komplexbeispiel mit Auswirkungen und Maßnahmen

14825.11.2020
Wie lautet die konkrete Beauftragung?
Issue-Backlog

14925.11.2020
Work-Item-Analyse

15025.11.2020
Work-Item-Analyse
WIP DoneTODO

15125.11.2020
Work-Item-Analyse
WIP DoneTODO

15225.11.2020
Work-Item-Analyse
WIP DoneTODO

15325.11.2020
Work-Item-Analyse
WIP DoneTODO

15425.11.2020
Work-Item-Analyse
WIP DoneTODO

15525.11.2020
Work-Item-Analyse
WIP DoneTODO

15625.11.2020
Work-Item-Analyse
WIP DoneTODO

15725.11.2020
Work-Item-Analyse
WIP DoneTODO

15825.11.2020
Work-Item-Analyse
WIP DoneTODO

15925.11.2020
Work-Item-Analyse
WIP DoneTODO

16025.11.2020
Work-Item-Analyse
WIP DoneTODO

16125.11.2020
Work-Item-Analyse
WIP DoneTODO

16225.11.2020
Work Item
=
Arbeitsaufgabe
Work-Item-Analyse

16325.11.2020
SCRUM
Work-Item-Analyse

16425.11.2020
IT Infrastructure Library
Work-Item-Analyse

16525.11.2020
Capability Maturity Model Integration
Work-Item-Analyse

16625.11.2020
Work Item
=
Arbeitsaufgabe
Work-Item-Analyse
Change Request

16725.11.2020
Work-Item-Analyse
=
Analyse der Arbeitsaufgaben
Work-Item-Analyse

16825.11.2020
Feature
Wertsteigernde Maßnahmen, durch die die
Software an Funktionalität gewinnt.
Work-Item-Analyse

16925.11.2020
Defect
Eine Unzulänglichkeit oder ein Mangel in
einem Arbeitsergebnis, sodass es seine
Anforderungen oder Spezifikationen nicht
erfüllt.
Work-Item-Analyse
Quelle: http://glossar.german-testing-board.info/v3.21/#fehlerzustand

17025.11.2020
Service Request
Anfrage eines Anwenders nach Hilfestellung.
Work-Item-Analyse
Quelle: https://wiki.de.it-processmaps.com/index.php/Request_Fulfilment

17125.11.2020
Incident
Eine plötzliche Unterbrechung oder
Qualitätsminderung, die möglichst schnell
beseitigt werden muss.
Work-Item-Analyse
Basierend auf: https://wiki.de.it-processmaps.com/index.php/Incident_Management

17225.11.2020
Adjustment
Werterhaltende Maßnahmen, die sich nicht in
zusätzlicher Funktionalität widerspiegeln oder
aufgrund von Fehlverhalten notwendig wird.
Work-Item-Analyse

17325.11.2020
80%
20%
Work-Item-Analyse
Defect
Incident
Service Request
Feature
Adjustment

17425.11.2020
Work-Item-Analyse
28%
18%
22%
32%
Defect
Incident
Service Request
Feature
Adjustment

17525.11.2020
Work-Item-Analyse
8
19
4
11
3
9
26 19
7
2
6
2
0
5
10
15
20
25
30
35
40
45
50
Sprint 7 Sprint 8 Sprint 9
Defect
Incident
Service Request
Feature
Adjustment

17625.11.2020
Work-Item-Analyse
21
30
26
106
120
48
127
150
74
0
20
40
60
80
100
120
140
160
Sprint 7 Sprint 8 Sprint 9
Velocity
Wert steigernd Wert erhaltend kumulierte Velocity

17725.11.2020
Vergleichstabellen und Bewertungsmatrizen

17825.11.2020
Vergleichsaspek
t
Alternative 1 Alternative 2 Alternative n

17925.11.2020
Vergleichsaspek
t
Alternative 1 Alternative 2 Alternative n
Macht wach
Macht nicht dick
Ist verfügbar
Schmeckt gut

18025.11.2020
Vergleichsaspek
t
Kaffee Tee Energy-Drinks
Macht wach
Macht nicht dick
Ist verfügbar
Schmeckt gut

18125.11.2020
Kriterien Kaffee Tee Energy-Drinks
Macht wach
Macht nicht dick
Ist verfügbar
Schmeckt gut

18225.11.2020
Macht wach
Macht nicht dick
Ist verfügbar
Schmeckt gut
Bewertung Bedeutung
--
-
o
+
++
trifft überhaupt nicht zu
trifft nicht zu
keine Angaben
trifft bedingt zu
trifft unbedingt zu

18325.11.2020
Macht wach + + ++
Macht nicht dick
Ist verfügbar
Schmeckt gut
Bewertung Bedeutung
--
-
o
+
++
trifft nicht zu
keine Angaben
trifft bedingt zu
trifft unbedingt zu

18425.11.2020
Macht wach + + ++
Macht nicht dick + ++ --
Ist verfügbar
Schmeckt gut
Bewertung Bedeutung
--
-
o
+
++
trifft nicht zu
keine Angaben
trifft bedingt zu
trifft unbedingt zu

18525.11.2020
Macht wach + + ++
Ist verfügbar ++ + o
Schmeckt gut
Bewertung Bedeutung
--
-
o
+
++
trifft nicht zu
keine Angaben
trifft bedingt zu
trifft unbedingt zu

18625.11.2020
Macht wach + + ++
Schmeckt gut ++ + --
Bewertung Bedeutung
--
-
o
+
++
trifft nicht zu
keine Angaben
trifft bedingt zu
trifft unbedingt zu

18725.11.2020
Macht wach + + ++
Schmeckt gut ++ + --
Bewertung Bedeutung
--
-
o
+
++
trifft nicht zu
keine Angaben
trifft bedingt zu
trifft unbedingt zu

18825.11.2020
Macht wach 1 1 2
Macht nicht dick 1 2 -2
Ist verfügbar 2 1 0
Schmeckt gut 2 1 -2
Bewertung Bedeutung
-2
-1
o
1
2
trifft nicht zu
keine Angaben
trifft bedingt zu
trifft unbedingt zu

18925.11.2020
Macht wach 1 1 2
Schmeckt gut 2 1 -2
Bewertung Bedeutung
-2
-1
o
1
2
trifft nicht zu
keine Angaben
trifft bedingt zu
trifft unbedingt zu

19025.11.2020
Macht wach 1 1 2
Schmeckt gut 2 1 -2
Ergebnis 6 5 -2
Bewertung Bedeutung
-2
-1
o
1
2
trifft nicht zu
keine Angaben
trifft bedingt zu
trifft unbedingt zu

19125.11.2020
Bewertungskriterium
Mindestens 2 Bewertungsmöglichkeiten
Negativbewertung führt nicht zum sofortigen Ausschluss
Ausschlusskriterium
Nur 2 Bewertungsmöglichkeiten
Negativbewertung führt zum sofortigen Ausschluss

19225.11.2020
Macht wach 1 1 2
Schmeckt gut 2 1 -2
Ergebnis 6 5 -2
Bewertung Bedeutung
-2
-1
o
1
2
trifft nicht zu
keine Angaben
trifft bedingt zu
trifft unbedingt zu

19325.11.2020
Schmeckt gut Ja Ja Nein
Macht wach 1 2
Macht nicht dick 1 2
Ist verfügbar 2 1
Ergebnis 4 4
Bewertung Bedeutung
-2
-1
o
1
2
trifft nicht zu
keine Angaben
trifft bedingt zu
trifft unbedingt zu

19425.11.2020
Gewichtung
Erhöht oder senkt die Bedeutung einzelner Kriterien

19525.11.2020
Gewichtung Kriterien Kaffee Tee Energy-Drinks
Schmeckt gut Ja Ja Nein
50% Macht wach 1 1
40% Macht nicht dick 1 2
10% Ist verfügbar 2 1
Ergebnis 1,1 1,4
Bewertung Bedeutung
-2
-1
o
1
2
trifft nicht zu
keine Angaben
trifft bedingt zu
trifft unbedingt zu

19625.11.2020

19925.11.2020
R1 – Datenverlust durch häufige Abstürze
R2 – Fehlerhafte Rechnungsstellung aufgrund falscher Angaben
R3 – Nutzer können auf die Daten anderer Nutzer zugreifen
Risikomatrix

20025.11.2020
Risikomatrix
Wahrscheinlichkeit
Auswirkung
mittel hochgering
geringmittelhoch Behandlung
unbedingt
notwendig
Überwachung
und Behandlung
notwendig
Überwachung
notwendig
Behandlung
notwendig
Behandlung
empfohlen
Risiko wird
akzeptiert,
Überwachung ist
aber notwendig
Wird
behandelt
Risiko akzeptiert,
bedarf aber ggf.
Behandlung
Akzeptierbares
Risiko

20125.11.2020
Risikomatrix
Schweregrad
Wahrscheinlichkeit
unwahrscheinlich
zukünftig möglich
selten
gelegentlich
häufig
Incidental Minor Serious Major Catastrophic

20225.11.2020
Risikomatrix

20325.11.2020
Risikomatrix
Schweregrad
Wahrscheinlichkeit
unwahrscheinlich
zukünftig möglich
selten
gelegentlich
häufig
R1

20425.11.2020
Risikomatrix

20525.11.2020
Risikomatrix
Schweregrad
Wahrscheinlichkeit
unwahrscheinlich
zukünftig möglich
selten
gelegentlich
häufig
R1
R2

20625.11.2020
Risikomatrix

20725.11.2020
Risikomatrix
Schweregrad
Wahrscheinlichkeit
unwahrscheinlich
zukünftig möglich
selten
gelegentlich
häufig
R1
R2
R3

20825.11.2020
G1 – Implementierung von Echtzeit-Tracing
G2 – Beseitigung der Instabilität
Risikomatrix

20925.11.2020
Risikomatrix
Schweregrad
Wahrscheinlichkeit
unwahrscheinlich
zukünftig möglich
selten
gelegentlich
häufig
R1
R2
R3

21025.11.2020
Risikomatrix
Schweregrad
Wahrscheinlichkeit
unwahrscheinlich
zukünftig möglich
selten
gelegentlich
häufig
R1 R2
R3

21125.11.2020
G1 – Implementierung von Echtzeit-Tracing
G2 – Beseitigung der Instabilität
G3 – Visuelle Prüfung vor dem Rechnungsversand
Risikomatrix

21225.11.2020
Risikomatrix
Schweregrad
Wahrscheinlichkeit
unwahrscheinlich
zukünftig möglich
selten
gelegentlich
häufig
R1 R2
R3

21325.11.2020
Risikomanagement ist eigentlich die Aufgabe anderer
Rollen.
Fokussierung auf Risiken im Bereich der IT/Architektur.
Risikomatrix

21425.11.2020
Informationen zusammen fassen

21525.11.2020
Blocker Behindern aktiv
Critical Deuten auf schwerwiegende Probleme
Considerable Können sich langfristig negativ auswirken
Minor Unschön aber ohne direkte Auswirkungen
Zusammenfassung
Issue Kategorien

21625.11.2020
Blocker
Zu geringe Testabdeckung
Technische Schulden
Unzureichender Anforderungsprozess
Critical
Fehlende Ziel-Architektur
Fehlende Modularisierung
Unzureichend gelebter Entwicklungsprozess
Considerable
Broken Unit Tests
Unzureichende Entwicklungsrichtlinien & Analysen
Keine Verwendung gängiger Patterns (z.B. MVP)
Fehlende Code-Reviews
Minor
Veraltetes UI-Design / Usability
Zusammenfassung
Kategorien mit Beispielen

21725.11.2020
Blocker
Zu geringe Testabdeckung (L)
Technische Schulden (XL)
Unzureichender Anforderungsprozess (M)
Critical
Fehlende Ziel-Architektur (S)
Fehlende Modularisierung (XL)
Unzureichend gelebter Entwicklungsprozess (M)
Considerable
Broken Unit Tests (S)
Unzureichende Entwicklungsrichtlinien & Analysen (S)
Keine Verwendung gängiger Patterns (z.B. MVP) (M)
Fehlende Code-Reviews (XS)
Minor
Veraltetes UI-Design / Usability (XL)
Zusammenfassung
Kategorien mit Beispielen und Aufwandsschätzungen

21825.11.2020
Aufwand
Impact
Blocker
Critical
XS S M L XL
Considerable
Minor
Zusammenfassung
Kritische Punkte
13
6
7
4
2
1. Testabdeckung
2. Technische Schulden
3. Anforderungsprozess
4. Ziel-Architektur
5. Modularisierung
6. Entwicklungsprozess
7. Broken Tests
8. Entwicklungsrichtlinien
9. Pattern
10. Code-Reviews
11. UI-Design/Usability
8
5
910
11

21925.11.2020
Kurzfristig
Mittelfristig
Langfristig
Weitere
Vorschläge
Dinge die frühzeitig begonnen werden sollten, aber langläufig sein können.
Dinge die in den nächsten Wochen begonnen werden sollten.
Dinge die in den nächsten Monaten begonnen werden sollten.
Generelle Anmerkungen und Hinweise.
Zusammenfassung
Nächste Schritte

22025.11.2020
Kurzfristig
Mittelfristig
Langfristig
Weitere
Vorschläge
Entwicklung einer Zielarchitektur entsprechend dem gewählten Lösungsweg
Aufnahme von Anforderungen (Analyse)
Etablieren des Entwicklungsprozesses
Umsetzung eines Modulkonzeptes
Herstellung der Testbarkeit
Verwendung von Patterns/Frameworks
Behebung der technischen Schulden
Schreiben von Unit-Tests
Einführung von Tools zur Entwicklerunterstützung und statischen Code-Analyse
Coaching der Mitarbeiter im Prozess
Evaluierung von Frameworks
Zusammenfassung
Nächste Schritte mit Beispielen

22225.11.2020
 Agenda
 Personenkreis
 Zeitspanne
Die Einladung
 Moderieren
 Protokollieren
 Diskutieren
 Rekapitulieren
Der Termin
 Ausformulieren
 Versenden
 Um Feedback bitten
Die Nachbereitung
Termine planen

22325.11.2020
 Agenda
 Personenkreis
 Zeitspanne
Die Einladung
 Moderieren
 Protokollieren
 Diskutieren
 Rekapitulieren
Der Termin
 Ausformulieren
 Versenden
 Um Feedback bitten
Die Nachbereitung
Termine planen

22425.11.2020
Moderator Teilnehmer Protokollant
Termine planen

22525.11.2020
{Datum}
{Teilnehmer}
{Protokollant}
{Betreff}
{Agenda}
Meeting-
protokolle

22625.11.2020
Art
I – Information
B – Beschluss
A – Aktivität
{Datum}
{Teilnehmer}
{Protokollant}
{Betreff}
{Agenda}
# Beschreibung Art Verantwortliche
1 I
B
A
2
3
.
.
.
n
Meeting-
protokolle

22725.11.2020
Art
I – Information
B – Beschluss
A – Aktivität
22. Februar 2222Karl (Protokollant)
Peter
Hendrik
Betreff - Kaffee
Agenda
1. Problem beschreiben
2. Lösung finden
# Beschreibung Art Verantwortliche
1 „Es gibt keinen
Kaffee mehr!“
(Karl)
I
2 Zukünftig eher
Bescheid
geben.
B Team
3 Neuen Kaffee
kaufen.
A Hendrik Lösch
(30. Februar)
Meeting-
protokolle

22825.11.2020
 Rollen bestimmen und bekannt geben.
 Zeiträume effektiv gestalten.
 Agenda mit der Einladung verschicken.
 Protokoll von Teilnehmern bestätigen lassen.
 Folgetermin schon im Meeting abstimmen.
Termine planen

22925.11.2020
Checklisten und Fragebögen

23025.11.2020
Checklisten und Fragenbögen
Offene
Gespräche
Brainstorming Befragung
+ viele Hintergrund-
informationen
- kann schnell chaotisch
werden
+ neue Ideen
+ Zugriff auf großen
Wissensschatz
- kann schnell chaotisch
werden
+ strukturierter Ablauf
- wenig Raum für
Entfaltung

23125.11.2020
Teilnehmer begrüßen
Vorstellungsrunde
Protokollant benennen
Agenda vorstellen
[…]
Protokoll verlesen
Folgetermin vereinbaren
Verabschiedung
grobeAbfolge
Beginn
Hauptteil
Abschluss
Beispiel
https://www.immonet.de/service/fileadmin/
pdf/Immonet-Checkliste-
Objektbesichtigung.pdf

23225.11.2020
Generelle Fragen
 Welche Ziele verbinden Sie mit der Untersuchung?
 Welche Softwaresysteme sollen betrachtet werden? (Nennung und
kurze Erklärung)
 Wie lange ist die Software schon im produktiven Einsatz?
 Wie viele Nutzer verwenden die Anwendung(en)?
 Wie hoch ist die Anzahl von Use Cases, Eingabemasken und
Wizards? (grobe Schätzung)

23325.11.2020
Fachliche Zusammenhänge
 Um welche fachliche Domäne handelt es sich? (Medizintechnik,
Industrielle Produktion, Verwaltung, …)
 Welche Gesetze und Standards müssen berücksichtigt werden?
 Welche besonderen Anforderungen gibt es an die Geschäftsregeln?

23425.11.2020
Strukturelle Zusammenhänge
 Mit welchen Drittsystemen wird kommuniziert?
 Über welche Schnittstellen erfolgt die Kommunikation?
 Welche Protokolle werden zum Austausch mit Drittsystemen
verwendet?
 Welche Technologien kommen in den Softwaresystemen zum
Einsatz?

23525.11.2020
Softwareentwicklungsprozess
 Wie werden Anforderungen erfasst?
 Wie viele Entwickler sind an der Umsetzung der Software beteiligt?
 Gibt es Coding Guidelines?
 Wo findet man die Coding Guidelines?
 Werden Code-Reviews durchgeführt? Wie und wann?

23925.11.2020
Fragenkatalog != Fragebogen

24025.11.2020
Was?
Wann?
Wie?
Warum?
Von wem?
Wo?

24125.11.2020
 Die Reihenfolge ist der Leitfaden.
 Zusammenhängende Punkte gruppieren.
 Platz für Anmerkungen lassen.
 Beteiligte und Datum vermerken.
 Offene und geschlossene Fragen gezielt einsetzen.

24225.11.2020
Fragenkatalog != Fragebogen

24325.11.2020
Verschieden Stakeholder
=
Verschiedene Perspektiven
Zielgruppen beachten

24425.11.2020
Entwickler
Codequalität
Testbarkeit
Wartbarkeit
Sicherheit

24525.11.2020
Nutzer
Benutzbarkeit
Zuverlässigkeit
Funktionale Korrektheit

24625.11.2020
Management
Funktionale Korrektheit
Time-To-Market
Investitionsschutz

Der Software auf den Zahn gefühlt - Einstieg in die Architekturbewertung

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (7)

Ähnlich wie Der Software auf den Zahn gefühlt - Einstieg in die Architekturbewertung

Ähnlich wie Der Software auf den Zahn gefühlt - Einstieg in die Architekturbewertung (20)

Mehr von Hendrik Lösch

Mehr von Hendrik Lösch (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (6)

Der Software auf den Zahn gefühlt - Einstieg in die Architekturbewertung