Do 8.4. Gut Genug? Bewerten Sie schon, oder raten Sie noch? Gernot Starke

Transkript

1 Do 8.4 January 2-25, 2008, Munich, Germany ICM - International Congress Centre Munich Gut Genug? Bewerten Sie schon, oder raten Sie noch? Gernot Starke

2 Gut genug? Bewerten Sie schon, oder raten Sie noch? Dr. Gernot Starke OOP 2008 Foto: Inhalt - Qualität im Kontext von Software-Architektur - quantitative versus qualitative Bewertung - Szenarien konkretisieren Qualität - Bewertung jenseits der reinen Architektur

3 Dr. Gernot Starke Schwerpunkte: Software-Architekturen Entwurf, Entwicklung, Management Mentoring und Coaching Definition, Analyse, Optimierung von Entwicklungsprozessen Reviews, Audits, Retrospektiven Dr. Gernot Starke Doing IT Right +49 (0) Blog: it-and-more.blogspot.com Architektur: Tätigkeiten Tätigkeiten: - Klären - Entwerfen - Entscheiden - Implementieren - Dokumentieren - Kommunizieren - Balancieren - Überwachen - Bewerten

4 Architektur braucht Iterationen Quantitative Bewertungen - Abbildung Software/Artefakte Zahl - Messen, d.h. Vergleichen mit bekannten Grössen - Tom DeMarco: You can neither predict nor control what you cannot measure. - Maßstäbe: #Zeilen, Abhängigkeiten, Komplexität etc. - Versuch: ISO (internal metrics) - praxisfern :-( - Problemfälle: - Strukturen und Dokumente

5 Wichtiger: Qualität! Qualitative Bewertung: - Gut genug? - Zeigt Erreichung nichtfunktionaler Anforderungen - Identifikation von Risiken - Identifikation von Nicht-Risiken Bewerten hilft Entscheiden

6 Qualität ist relativ - Kein absolutes Maß für Qualität - Stakeholder haben spezifische Qualitätsanforderungen - Beispiele: - Manager und Auftraggeber: Kosteneffizienz und Flexibilität - Endanwender: Performance, Benutzbarkeit. - Projektleiter: Einfachheit, Testbarkeit. - Betreiber: Administrierbarkeit, Sicherheit. Bewerte (und entwerfe!) nach spezifischen Qualitätszielen Qualität konkretisieren - So wird Qualität konkret(er):

7 Beispiele von Szenarien - System geht in < PJahr mit neuem Layout produktiv - Operator kann System in < 0 min neu zu starten - Report aller neuen Buchungen in < 5 min - Gesamte tägl. Batchverarbeitung läuft in <60min - Bei CPU-Ausfall ist Hot-Spare-System in <5min online Qualität durch Szenarien beschreiben - Interaktionen eines Stakeholders mit dem System - Beschreiben, wie System auf Stimulus reagiert - Operationalisieren und konkretisieren Qualitätsmerkmale - Anwendungsszenarien ( U se-case Scenario ) - Stakeholder wenden System an - Änderungsszenarien ( Change S cenario) - Stakeholder modifiziert Teil des Systems oder dessen unmittelbare Umgebung

8 Qualitätsbaum mit Prioritäten - Ziel: Stelle Qualitätsanforderungen an Projekt/Produkt dar: - operationalisierbar - prioritisierbar - Nach Geschäftswert (High, Medium, Low H, M, L) - Nach Schwierigkeit (High, Medium, Low H, M, L) - Höchste Prio: (H,H), (H,M) und (M,H) - Top-Down Verfeinerung der projekt- oder produktspezifischen Qualität Szenarien priorisieren Notwendig: Zwei Dimensionen:.) Wichtigkeit ( Business ) 2.) Schwierigkeit ( Technik )

9 2 Dimensionen bringen Fokus Vorgehen bei Architekturbewertung nach ATAM

10 Vorgehen bei Architekturbewertung - Vorbereitungsphase - Festlegen der Bewertungsziele - Identifizieren der (maßgebenden) Stakeholder - Kickoff - Vorstellen der Bewertungsmethode - Vorstellen der Systemziele - Erarbeiten der Qualitätsziele - Vorstellen der Software-/Systemarchitektur - Prioritisieren der Qualitätsziele - Erstellen von Szenarien - Bewertungsphase - Identifizieren von Architekturansätzen für Qualitätsziele - Bewerten der Architektur hinsichtlich Szenarien - Bewerten der gegenseitigen Beeinflußung von Q-Merkmalen - Identifizieren von Risiken und Nicht-Risiken - Identifizieren und bewerten von Handlungsempfehlungen - Abschluß - Vorstellen der Ergebnisse Bewertungsphase Beteiligt: Bewertungsteam, Architekten - Analysiere die Architekturansätze - Welche Ansätze verfolgt die Architektur hinsichtlich Q-Merkmalen? - Fokus: (hoch prioritisierte) Szenarien (H,H), (H,M), (M,H) - Detailierte Diskussion/Walkthrough der Szenarien - (über ATAM hinaus) - Bewertung von Quellcode, Fehlern und Fehlerursachen, erwarteten Änderungen und Tests

11 Bewertungsphase (2) - Bewerten hinsichtlich Szenarien - Berücksichtigung von Alternativen - Welche Auswirkung hätte eine Alternative auf Q- Merkmal? NABUME * - Gegenseitige Beeinflussung der Qualitätsmerkmale erarbeiten - Welche Kompromisse wurden geschlossen? - Welche Auswirkungen haben Architekturentscheidungen auf Qualitätsmerkmale? - Welche Architekturentscheidungen betreffen mehrere Q- Merkmale? Einschub: NABUME No Algorithm BUt Magic and Experience - Es gibt keinen Algorithmus für (qualitative) Bewertung - Häufig ist Bewertung von Bewertungsteam abhängig - Kein Grund, auf Bewertung zu verzichten: - Andere Disziplinen handeln ebenso: - Medizin, Immobilienwesen, Marketing und andere! - Gemeinsames Merkmal aller publizierten Bewertungsmethoden - ATAM, SAAM, CBAM: Bei Bewertung einzelner Faktoren spielt Einschätzung zentrale Rolle!

12 Bewertung jenseits von Architekur - Verständlichkeit als wichtiges Entwurfsziel! - Bestimmt durch alle Artefakte - Architektur ( Struktur ) - Quellcode - Metriken, Inspe ktionen, Tests - Dokumentation Nutzen Sie Checklisten... - Bewerten Sie Dokumentation! - Vorschlag: - Dokumentation in fester, vorgegebener Struktur - etwa: arc42 - Kriterienkatalog zur Erstellung und Bewertung!

13 Auszug Kriterienkatalog : 2: 3: 4: 5: 6: 7: 8: 9: 0: : 2: 3: 4: 5: 6: 7: 8: 9: 20: 2: 22: 23: : 2: 3: 4: 5: USE AGREED-UPON DOCUMENT FORMATS AND TOOLS NO STRUCTURAL MODIFICATION OF DOCUMENTATION ARCHITECTURE DOCUMENTATION PER RELEASE RELEASE NOTES & CHANGE HISTORY FOR ARCHITECTURE DOCUMENTATION KEEP REQUIREMENTS TRACEABLE IN ARCHITECTURE AND CODE MAINTAIN INDEX OF IMPORTANT TOPICS INCLUDE VERSION INFORMATION IN DIAGRAMS INCLUDE LEGEND IN ALL DIAGRAMS WITH NON-STANDARD UML CONSTRUCTS TEXTUAL DESCRIPTION OF NON-STANDARD UML CONSTRUCTS DESCRIBE CURRENT GOALS AND CONSTRAINTS DESCRIBE CURRENT STAKEHOLDERS DOCUMENT COMPLETE SYSTEM CONTEXT DOCUMENT ALL EXTERNAL CHANNELS DESCRIBE EVERY BUILDING BLOCK USE DIAGRAMS TO DESCRIBE WHITEBOX-VIEWS DESCRIBE PURPOSE, INTERFACES AND VARIABILITY OF EVERY BLACKBOX DESCRIBE MAPPING OF BUILDING BLOCKS TO MAJOR CODE ARTIFACTS DOCUMENT USE-CASES, EXTERNAL PROTOCOLS AND ERROR-CONDITIONS DOCUMENT TYPICAL CHANGE-SCENARIOS DESCRIBE DEPLOYMENT ARTIFACTS ASSOCIATE DEPLOYMENT ARTIFACTS WITH BUILDING BLOCKS INCLUDE CONFIGURATION FILES IN DEPLOYMENT ARTIFACTS DOCUMENT MAJOR DESIGN DECISIONS ALL ARTIFACTS CONTAIN DOCUMENTATION HEADER NO DUPLICATE CODE INLINE DOCUMENTATION FOR CENTRAL CLASSES UNIFORM HANDLING OF RECURRING IMPLEMENTATION ASPECTS USE CODE METRICS AS INDICATOR FOR POTENTIAL RISKS Download: Action Step : Qualität definieren - Brainstorming: Was ist für UNS gut genug? - Szenarien, Qualitätsmerkmale, Qualitätsbaum

14 Action Step 2: Priorisieren - Qualitätsmerkmale & Szenarien priorisieren - Difficulty & Business-Value - Szenarien hinsichtlich Risiken bewerten Action Step 3: Bewerten & steuern... - Maßnahmen zur Verbesserung identifizieren - Nächste Iteration steuern...

15 Mehr dazu... - Kapitel 0: Gut genug? als (pdf) Download ( - Clements et. al: Evaluating Software Architectures. Addision-Wesley,