1 / 27

Technologieberatung „Best-Practice Software Engineering“ Backup-Slides

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. Backup-Slides.

temira
Download Presentation

Technologieberatung „Best-Practice Software Engineering“ Backup-Slides

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  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ätwä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 Projektebenötigen jedoch angepasste Vorgehensweisen(verschiedene Software Prozesse bzw. Vorgehensmodelle). • Software Prozesse orientieren sich am Produkt-Life-Cycle Prozess jedoch mit unterschiedlichem Schwerpunkt.

  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. 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. Value-Based Decision Support - Beispiel

  7. Software Software Design & Software Software Specification Implementation Validation Evolution n t o n e n t i n c o t n e g i a o n t e n n i t m a a t g i n m a c n n i e e i s r e r e f n i g i m r e t u a c i e n t D l e e q i t e P l a n p e p R I M S R m I 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. 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. Impact of Requirements • Reasons for project interruption - survey including 365 industrial responses (8.380 applications) [Chaos Report, 1994]: • Incomplete requirements (13.1%) • Lack of User Involvement (12.4%) … • 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. 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)

  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. 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. 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) Test Case SelectionResearch Studies Rothermel G. and S. Elbaum Putting Your Best Tests Forward IEEE Software Aug./Sept. 2003 [Ramler, 2006]

  15. Testautomation - Motivation

  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. QA Aspects: Simulation Testing MASS Simulation Automated QA Logging Test Framework Log Analysis and Test Reporting • 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).

  18. 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

  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. Example Application Cut from a Risk-QA method candidate matrix. • Adaptation of ATAM steps. • 9 Steps of QATAM 0. Planning & information exchange • Scenario brainstorming: • definition of win conditions • measures for success criteria • exit criteria. • Initial selection of candidate bundles of QA activities • Scenario coverage checking • Prioritization and grouping of scenarios • Mapping and evaluation of QA strategiesregarding 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

  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. Aktivitäts-gruppe Methode Produkt-gruppe verantwortlich Produkt Aktivität mitwirkend Rolle Rolle Rolle Methodenmatrix Prozess-Tailoring: Methodenmatrixfür Wissensmanagement • Auswahl wirkungsvoller Methoden • Wirkungsvolle Anwendung von Methoden Methodenübersicht Literatur Kontaktpersonen Beispiele …. erzeugt wendet an

  23. Schritt: Auswahl Projekttyp Umgebung Kunde Projekt Projektteam

  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. Detailinformation zu einer Methode Übersicht Detail best-practice Methode Kurzbeschreibung Weitere Methoden Literatur Kontaktdaten Beispieldokumente

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

  27. Wissensmanagent zu wirkungsvollen MethodenVerbesserung 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.

More Related