. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. .1 Institut für Softwaretechnik und Interaktive
Systeme
Technologieberatung„Best-Practice Software Engineering“
Backup-Slides
Stefan Biffl Alexander Schatten
Architekturen für agile Software-EntwicklungAutomatisierung im Software-EntwicklungsprozessMethodisches Vorgehen im Qualitätsmanagement
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. .2 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
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. .3 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.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. .4 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– …
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. .5 Institut für Softwaretechnik und Interaktive
Systeme
Value-Based Decision Support (2/2)
Schlüssel-ErgebnisseVerbindungen zwischen
Ergebnissen und Nutzen-vorstellungen der Stakeholder
Ergebnis A
Stakeholder & Erwarteter Nutzen
Abhängigkeiten von Schlüssel-Ergebnissen
Ergebnis B
Ergebnis C
Schritt 1
Forschung
Industrie
Sonstige Stakeholder
...Erwarteter Nutzen A
...
Erwarteter Nutzen C
…
Erwarteter Nutzen B...
...
Erwarteter Nutzen D
(+)
(-)
… (+) ergänzende Ziele
(-) widersprüchliche Ziele
Risiko 1
Risiko 3
Risiko 2
Schritt 2
Schritt 3
Schritt 4
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
Value-Based Decision Support - Beispiel
Schlüssel-ErgebnisseVerbindungen zwischen
Ergebnissen und Nutzen-vorstellungen der Stakeholder
Online System
Stakeholder & Erwarteter Nutzen
Abhängigkeiten von Schlüssel-Ergebnissen
DB Modellierung
Datenbank (DB)
Schritt 1
Anwender
Entwickler
Management
...Einfache Bedienbarkeit
...
Wartbarkeit einfach
…
Transparenter Buchungsvorgang...
...
Plattformunabhängigkeit
(+)
(-)
… (+) ergänzende Ziele
(-) widersprüchliche Ziele
Komplexität
Architektur-entscheidung
Schritt 2
Schritt 3
Schritt 4
Beispiel einer neuen Buchungssoftware (Auszug)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. .7 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.
Req
uire
men
t
Spe
cific
atio
n
SoftwareSpecification
Plan
ning
Des
ign
Impl
emen
tatio
n
Inte
grat
ion
Mai
nten
ance
Ret
irem
ent
Software Design &Implementation
SoftwareValidation
SoftwareEvolution
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. .8 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%.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. .9 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) 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
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
Requirements Elicitation (2/2)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. .12 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
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. .13 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
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. .14 Institut für Softwaretechnik und Interaktive
Systeme
Test Case SelectionResearch 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. ElbaumPutting Your Best Tests ForwardIEEE Software Aug./Sept. 2003
[Ramler, 2006]
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. .15 Institut für Softwaretechnik und Interaktive
Systeme
Testautomation - Motivation
Comparison of test costs regarding manual tests and automated tests
0 1 2 3 4 5 6 7 8 9 10
test cycle
cost
s
Manuell Automatisiert
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. .16 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.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. .17 Institut für Softwaretechnik und Interaktive
Systeme
AutomatedQA
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
Test Framework for MDD
18
Define Test Suite Goals
Translate Test Goal to Scenario
Derive test case from models
Test process for ind. test cases
Test Suitecompleted
Summarize test suite and report
NO
YES
Set-up test case environment
Run test case events
Throw events (failure, belt interruption, etc)
summarizing & reporting
cleanupUnload system configuration file,Cleanup MAS System
Process for single test case
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
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
QA Framework
Embedded Systems
AdministrativeSystems
DependableSystems ...
... Unclear Requirements
QA Strategy 1 QA Strategy 2
Individual Project Application
General Model
Application Domain
Project Risks
Tradeoff Analysis
Generic Level
Business Level
Risk-Based
Project Level
QA Strategy 3
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. .20 Institut für Softwaretechnik und Interaktive
Systeme
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 activities3. Scenario coverage checking4. Prioritization and grouping of scenarios5. Mapping and evaluation of QA strategies regarding prioritized scenarios.6. Sensitivity point analysis: comparison of different QA approaches7. Trade-off determination and 8. Summary of promising QA bundles and definition of an action plan
20
Pos
sibl
e R
isks
Number of defects found during a review
Unclear requirements
Software Processes
Agi
le S
E
Pro
cess
es
Trad
ition
alS
E P
roce
sses
New Team Members
Analytical QA activities
Insp
ectio
n
Test
ing
Rev
iew
s
Constructive SE activities
Pai
r P
rogr
amm
ing
Test
-Driv
en
Dev
elop
men
t
++ - n/a n/a n/a ++ +
n/a n/a + ++ + ++ +
- + + ++ - ++ +
Candidate SE / QA methods
Cut from a Risk-QA method candidate matrix.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. .21 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 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.
Inspection
Pair Programming
RequirementsSpecification
Source Code FragmentsPrirotized Use Cases
GuidelinesDefect Classification
observer role
driver role
roles changefrequ.
Defect detection list
(additional / modified)
Source Code
Dev
elop
men
tP
acka
ge
UBR
Defect / Quality Estimation
Extended / improved product (source code)
Integrated Pair Programming Approach
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. .22 Institut für Softwaretechnik und Interaktive
Systeme
MethodenübersichtLiteraturKontaktpersonenBeispiele….
Prozess-Tailoring: Methodenmatrixfür Wissensmanagement
Produkt
Produkt-gruppe
Aktivität
Aktivitäts-gruppe
Rolle
Rolle
Rolle
verantwortlich
mitwirkend
wendet anerzeugt
Methodenmatrix
Methode
Auswahl wirkungsvoller Methoden Wirkungsvolle Anwendung von Methoden
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. .23 Institut für Softwaretechnik und Interaktive
Systeme
Schritt: Auswahl Projekttyp
Umgebung
Kunde
Projekt
Projektteam
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. .24 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).
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. .25 Institut für Softwaretechnik und Interaktive
Systeme
Detailinformation zu einer Methode
best-practice Methode
Weitere Methoden
Kurzbeschreibung
Literatur
Kontaktdaten
Beispieldokumente
Übersicht
Detail
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. .26 Institut für Softwaretechnik und Interaktive
Systeme
Feedback zur Wirkung der Methode
Verwendete Methode
Kurzfeedback
Anmerkungen
Verwendete Materialien
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. .27 Institut für Softwaretechnik und Interaktive
Systeme
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.
Projektteams
Methodenteam
TrainingCoaching
Methoden-information
Feedback
Top Related