Technologieberatung Best-Practice Software Engineering Backup-Slides

Transkript

1 1 Technologieberatung Best-Practice Software Engineering Backup-Slides Stefan Biffl Alexander Schatten Architekturen für agile Software-Entwicklung Automatisierung im Software-Entwicklungsprozess Methodisches Vorgehen im Qualitätsmanagement

2 2 Backup-Slides Herstellung qualitativ hochwertiger Produkte Value-Based Decision Support (zur initialen Risikobewertung vor Projektstart) Sicht des Gesamtprojektes. Software Prozesse Requirements Elicitation Risk Management Strategische Methodenauswahl Methodenmatrix Fehlererkennung Software Testen Testautomatisierung Software Engineering Automation Software Produkt- und Prozessverbesserung

3 Herstellung qualitativ hochwertiger Produkte Motivation Absicherung einer durchgängig hohen Produktqualität während des gesamten Entwicklungsprozesses, u.a. durch integrierte QS-Methoden. Softwareprodukte umfassen ALLE Produkte im Rahmen der Softwareentwicklung z.b. Spezifikation, Code, Testfälle, Protokolle). Software Prozesse unterstützen die Entwickler durch eine systematische und strukturierte Vorgehensweise. Unterschiedliche Projekte benötigen jedoch angepasste Vorgehensweisen (verschiedene Software Prozesse bzw. Vorgehensmodelle). Software Prozesse orientieren sich am Produkt-Life-Cycle Prozess jedoch mit unterschiedlichem Schwerpunkt. 3

4 Value-Based Decision Support (1/2) Identifikation der Schlüssel-Ergebnisse eines Projektes Identifikation der maßgeblichen Stakeholder (in das Projekt involvierte Rollen) Finden des erwarteten Nutzens (aus der Sicht der jeweiligen Stakeholder) Value Proposition. Ermittlung ergänzender / widersprüchlicher Ziele Beitrag jedes Schlüssel-Ergebnis zum erwarteten Nutzen Nicht berücksichtigte Stakeholder Ergebnisse ohne Nutzenbeitrag Ermittlung des Risikos (durch Verbindung von Ergebnis zu Stakeholder) Risikoabschätzung und prävention 4

5 Value-Based Decision Support (2/2) Schlüssel-Ergebnisse Verbindungen zwischen Ergebnissen und Nutzenvorstellungen der Stakeholder Stakeholder & Erwarteter Nutzen Schritt 2 Ergebnis A Risiko 2 Forschung... Erwarteter Nutzen A Ergebnis B Risiko 3 Erwarteter Nutzen B... Ergebnis C (+) Industrie (-) Schritt 3 Abhängigkeiten von Schlüssel-Ergebnissen Risiko 1 Erwarteter Nutzen C Erwarteter Nutzen D Sonstige Stakeholder Schritt 1 Schritt 4 (+) ergänzende Ziele (-) widersprüchliche Ziele Schritt 1: Definition der Schlüsselergebnisse und wechselseitigen Abhängigkeiten. Schritt 2: Identifikation der Key Stakeholder Gruppen und des jeweils erwarteten Nutzens. Schritt 3: Abhängigkeiten des erwarteten Nutzens der jeweiligen Stakeholder: ergänzende Ziele (+) oder widersprüchliche Ziele (-). Schritt 4: Identifikation des Nutzenbeitrags jedes Schlüsselergebnisses. Daraus können Risiken, unberücksichtigte Stakeholderinteressen, Win conditions ermittelt werden. Finden geeigneter Maßnahmen zur Risikoprävention. 5

6 6 Value-Based Decision Support - Beispiel Beispiel einer neuen Buchungssoftware (Auszug) Schritt 1 Schlüssel-Ergebnisse Online System DB Modellierung Datenbank (DB) Abhängigkeiten von Schlüssel-Ergebnissen Verbindungen zwischen Ergebnissen und Nutzenvorstellungen der Stakeholder Architekturentscheidung Komplexität Schritt 4 Stakeholder & Erwarteter Nutzen Anwender... Einfache Bedienbarkeit Transparenter Buchungsvorgang... (+) Schritt 2 Entwickler... (-)... Wartbarkeit einfach Plattformunabhängigkeit Management (+) ergänzende Ziele (-) widersprüchliche Ziele Schritt 3

7 7 Software Prozesse (Life-Cylce) Ein Software Prozess ist eine Abfolge von Schritten (Phasen) mit all seinen Aktivitäten, Beziehungen und Ressourcen. Der Software Life-Cycle beschreibt ein Basiskonzept für Software Engineering Prozesse. Software Specification Software Design & Implementation Software Validation Software Evolution Requirement Specification Planning Design Implementation Integration Maintenance Retirement

8 Defect Reduction Heuristics Boehm and Basili; Software defect reduction report [Boehm and Basili, 2001] Finding and fixing a software problem after delivery is often 100 times mores expensive than finding and fixing it during the requirements and design phase. Current software projects spend about 40 to 50% of their effort on avoidable rework. About 80% of avoidable rework comes from 20% of the defects. About 80% of the defects com from 20% of the modules, and about half of the modules are defect free. About 90% of the downtime comes from, at most, 10% of the defects. Peer reviews (i.e., inspections) catch 60% of the defects. Perspective-based reviews catch 35% more defects than non-directed review. Disciplined personal practices can reduce defect introduction rates by up to 75%. 8

9 Impact of Requirements Reasons for project interruption - survey including 365 industrial responses (8.380 applications) [Chaos Report, 1994]: 1. Incomplete requirements (13.1%) 2. Lack of User Involvement (12.4%) 6. Changing Requirements and Specifications (8.7%) Selection of Top-Ten risk items for project failure [Boehm, 1991] 3) Developing wrong software functions. 4) Developing the wrong user interfaces. 5) Gold plating. 6) Continuing stream of requirement changes. Software Processes help to address requirements elicitation. 9

10 10 Requirements Elicitation (1/2) Many stakeholders Hundreds of win conditions Detailed analysis of priorities and conflicts Tool support good for high-volume stakeholder value proposition collection and negotiation

11 Requirements Elicitation (2/2) 11

12 Requirements Tracing Support Integrated tool support for IDEs Developed in cooperation with and applied at Siemens IT Solutions and Services Benefits Integrated traceability support for developers Tracing effort reduction Continuous status reporting for project managers 12

13 13 Challenge: Balancing External and Internal Dimensions of QA External dimension: Market view of quality Stakeholder win conditions define project scope and constraints. Stakeholder value and risk attitude Internal dimension: scope of QA manager how to organize SE & QA. Translate QA goals into planning QA activities. Effective from customer and user points of view Efficient resource usage from project point of view

14 Test Case Selection Research Studies Random (un-prioritized) Coverage (measured in terms of total number of functions) Change (measured in terms of additional modified functions covered) Optimal (upper bound on prioritization effectiveness) Rothermel G. and S. Elbaum [Ramler, 2006] Putting Your Best Tests Forward 14 IEEE.. Software... Aug./Sept Institut für Softwaretechnik und Interaktive

15 15 Testautomation - Motivation Comparison of test costs regarding manual tests and automated tests costs test cycle Manuell Automatisiert

16 Example: QA in Multi-Agent Systems Scope: Complex Systems Multi-Agent Software Systems (MASS) Safety-Critical Systems (e.g., in manufactoring systems) Target group: Practitioners: Faster delivery of high-quality products. Researchers: Experience in MDD in theareaof MASS. 16

17 17 QA Aspects: Simulation Testing To improve MASS software quality by appropriately monitoring both software and the development process to ensure full compliance with the established standards and procedures. Manual QA for V&V during design time. MASS Simulation Automated QA Measurement of system performance (logging, log analysis) Test automation to lower the effort for retesting software systems Notification of system behavior during system operation (run-time). Test Framework Automated QA Log Analysis and Test Reporting Logging

18 Test Framework for MDD Define Test Suite Goals Translate Test Goal to Scenario Derive test case from models Test process for ind. test cases Test Suite completed YES Summarize test suite and report NO Process for single test case Set-up test case environment Run test case events summarizing & reporting cleanup Throw events (failure, belt interruption, etc) Unload system configuration file, Cleanup MAS System Test Cases are based on models and designs. Test cases follow the systems requirements (acceptance view) Test cases follow and drive the implementation (architecture / design view) Types of test case: Normal case: Assertions for successful termination and time-out Simplest: sending one pallet to an index station Advanced: Assembling product of two parts Failures case: Conveyor breakdown, junction breakdown. 18 Institut für Softwaretechnik und Interaktive

19 Strategische Methodenauswahl Quality Assurance Tradeoff Analysis Method (QATAM) focuses on the analysis of an agreed set of QA approaches in a SE project regarding project risk and tradeoffs. QATAM is a vehicle to support Quality Assurance Planning activities General Model QA Framework Generic Level Application Domain Embedded Systems Administrative Systems Dependable Systems... Business Level Project Risks... Unclear Requirements Risk-Based Tradeoff Analysis QA Strategy 1 QA Strategy 2 QA Strategy 3 Project Level Individual Project Application QATAM is based on SEI s ATAM (architecture tradeoff analysis methods) which assesses different architecture variants against the product requirements ( product variants ). QATAM supports decision makers in selecting QA strategies ( process variants ). 19 Institut für Softwaretechnik und Interaktive

20 Example Application Adaptation of ATAM steps. 9 Steps of QATAM 0. Planning & information exchange 1. Scenario brainstorming: definition of win conditions measures for success criteria exit criteria. Cut from a Risk-QA method candidate matrix. 2. Initial selection of candidate bundles of QA activities 3. Scenario coverage checking 4. Prioritization and grouping of scenarios 5. Mapping and evaluation of QA strategies regarding prioritized scenarios. 6. Sensitivity point analysis: comparison of different QA approaches 7. Trade-off determination and 8. Summary of promising QA bundles and definition of an action plan 20 Institut für Softwaretechnik und Interaktive

21 21 Pair Programming with Inspection Pair Programming PP involves 2 persons (driver/observer), Driver: implementation role. Observer: supporting role. Roles may change frequently. sharing a common development environment (screen, keyboard, mouse). Integrated PP approach: More systematic defect detection approach. Active support with reading techniques and guidelines. Focus on most important use cases (prioritization). Integrated Pair Programming Approach Comparison of best-practice inspection and the new integrated PP approach according to defect detection capability in an empirical study.

22 22 Prozess-Tailoring: Methodenmatrix für Wissensmanagement Auswahl wirkungsvoller Methoden Wirkungsvolle Anwendung von Methoden Produktgruppe Aktivitätsgruppe Rolle verantwortlich Produkt erzeugt Methodenübersicht Literatur Kontaktpersonen Beispiele. wendet an Aktivität Methode Rolle mitwirkend Rolle Methoden matrix

23 23 Schritt: Auswahl Projekttyp Umgebung Kunde Projekt Projektteam

24 24 Methodenüberblick Grün: Abgrenzung des allgemeinen Prozessablaufes. Braun: Empfohlener Status des Produktes zum definierten Entscheidungspunkt. Weiss: Weitere Informationen zu anwendbaren Methoden (web-basiert).

25 25 Detailinformation zu einer Methode Übersicht Detail best-practice Methode Weitere Methoden Kurzbeschreibung Literatur Kontaktdaten Beispieldokumente

26 26 Feedback zur Wirkung der Methode Verwendete Methode Kurzfeedback Verwendete Materialien Anmerkungen

27 Wissensmanagent zu wirkungsvollen Methoden Verbesserung durch Feedback Sammlung der Wirkungen von Methoden auf Projekt- und Produktqualität. Ergänzung und Verbesserung der Methodensammlung. Methodenteam bietet Training, Coaching, Methodeninformation. Projektteams geben Feedback zum Methodeneinsatz. Erfolgsfaktoren Schnelles, einfaches Feedback. Umfassende Kommunikation der Feedback-Verwendung. Feedback-Aufbereitung und Einarbeitung in neue Version der Methodenmatrix. 27