Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

................................................. Institut für Softwaretechnik und Interaktive Systeme 1 Technologieberatung „Best-Practice Software Engineering“

Ähnliche Präsentationen


Präsentation zum Thema: "................................................. Institut für Softwaretechnik und Interaktive Systeme 1 Technologieberatung „Best-Practice Software Engineering“"—  Präsentation transkript:

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

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

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

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

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

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

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

10 Institut für Softwaretechnik und Interaktive Systeme 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 Institut für Softwaretechnik und Interaktive Systeme 11 Requirements Elicitation (2/2)

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

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

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

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

17 Institut für Softwaretechnik und Interaktive Systeme 17 Automated QA 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 re- testing software systems  Notification of system behavior during system operation (run-time). QA Aspects: Simulation Testing Test Framework Logging Log Analysis and Test Reporting

18 Institut für Softwaretechnik und Interaktive Systeme 18 Test Framework for MDD 18  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.

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

20 Institut für Softwaretechnik und Interaktive Systeme 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. 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 Cut from a Risk-QA method candidate matrix.

21 Institut für Softwaretechnik und Interaktive Systeme 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).  Comparison of best-practice inspection and the new integrated PP approach according to defect detection capability in an empirical study. Integrated Pair Programming Approach

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

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

24 Institut für Softwaretechnik und Interaktive Systeme 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 Institut für Softwaretechnik und Interaktive Systeme 25 Detailinformation zu einer Methode best-practice Methode Weitere Methoden Kurzbeschreibung Literatur Kontaktdaten Beispieldokumente Übersicht Detail

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

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


Herunterladen ppt "................................................. Institut für Softwaretechnik und Interaktive Systeme 1 Technologieberatung „Best-Practice Software Engineering“"

Ähnliche Präsentationen


Google-Anzeigen