technologieberatung „best-practice software engineering“ backup-slides

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


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

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


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.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


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– …

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


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.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


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)

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


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

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


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

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


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.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


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

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Systeme

Requirements Elicitation (2/2)

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


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

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


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

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


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]

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


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

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


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.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


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

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


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.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


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

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


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.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


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

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


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

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Systeme

Schritt: Auswahl Projekttyp

Umgebung

Kunde

Projekt

Projektteam

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


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

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Systeme

Detailinformation zu einer Methode

best-practice Methode

Weitere Methoden

Kurzbeschreibung

Literatur

Kontaktdaten

Beispieldokumente

Übersicht

Detail

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Systeme

Feedback zur Wirkung der Methode

Verwendete Methode

Kurzfeedback

Anmerkungen

Verwendete Materialien

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


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

technologieberatung „best-practice software engineering“ backup-slides

Documents