Technologieberatung Best-Practice Software Engineering Backup-Slides Stefan Biffl Alexander

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 1. . . Institut für Softwaretechnik und Interaktive Systeme

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 2. . . Institut für Softwaretechnik und Interaktive Systeme

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. . . Institut für Softwaretechnik und Interaktive Systeme

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. . . Institut für Softwaretechnik und Interaktive Systeme

Value-Based Decision Support (2/2) 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. . . Institut für Softwaretechnik und Interaktive Systeme

Value-Based Decision Support - Beispiel 6. . . Institut für Softwaretechnik und Interaktive Systeme

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. 7. . . Retirement Software Evolution Maintenance Integration Software Validation Implementation Design Software Design & Implementation Planning Specification Requirement Software Specification Institut für Softwaretechnik und Interaktive Systeme

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. . . Institut für Softwaretechnik und Interaktive Systeme

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) 4) 5) 6) … Developing wrong software functions. Developing the wrong user interfaces. Gold plating. Continuing stream of requirement changes. Software Processes help to address requirements elicitation. 9. . . Institut für Softwaretechnik und Interaktive Systeme

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 10. . . Institut für Softwaretechnik und Interaktive Systeme

Requirements Elicitation (2/2) 11. . . Institut für Softwaretechnik und Interaktive Systeme

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. . . Institut für Softwaretechnik und Interaktive Systeme

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 13. . . Institut für Softwaretechnik und Interaktive Systeme

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 Putting Your Best Tests Forward 14 . . . Aug. /Sept. . IEEE. Software. . . 2003 . . . . [Ramler, 2006] Institut für Softwaretechnik und Interaktive Systeme

Testautomation - Motivation 15. . . Institut für Softwaretechnik und Interaktive Systeme

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 the area of MASS. 16. . . Institut für Softwaretechnik und Interaktive Systeme

QA Aspects: Simulation Testing MASS Simulation § 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. § Automated QA – Measurement of system performance (logging, log analysis) – Test automation to lower the effort for retesting software systems § Automated QA Test Framework Logging Notification of system behavior during system operation (run-time). Log Analysis and Test Reporting 17. . . Institut für Softwaretechnik und Interaktive Systeme

Test Framework for MDD § 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 Systeme

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 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 Systeme

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

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 Pair Programming Approach Integrated PP approach: § More systematic defect detection approach. § Active support with reading techniques and guidelines. § Focus on most important use cases (prioritization). Ü Comparison of best-practice inspection and the new integrated PP approach according to defect detection capability in an empirical study. 21. . . Institut für Softwaretechnik und Interaktive Systeme

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

Schritt: Auswahl Projekttyp Umgebung Kunde Projektteam 23. . . Institut für Softwaretechnik und Interaktive Systeme

Methodenüberblick § Grün: Abgrenzung des allgemeinen Prozessablaufes. § Braun: Empfohlener Status des Produktes zum definierten Entscheidungspunkt. § Weiss: Weitere Informationen zu anwendbaren Methoden (web-basiert). 24. . . Institut für Softwaretechnik und Interaktive Systeme

Detailinformation zu einer Methode Übersicht Detail best-practice Methode Kurzbeschreibung Weitere Methoden Literatur Kontaktdaten Beispieldokumente 25. . . Institut für Softwaretechnik und Interaktive Systeme

Feedback zur Wirkung der Methode Verwendete Methode Kurzfeedback Verwendete Materialien Anmerkungen 26. . . Institut für Softwaretechnik und Interaktive Systeme

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. . . Institut für Softwaretechnik und Interaktive Systeme