SlideShare ist ein Scribd-Unternehmen logo
Trends & Benchmarks Report Schweiz
Wo stehen wir – wohin geht es?
Software Development 2014
In Kooperation mit
Agile
Requirements
Testing
Trends & Benchmarks in Software Development 2014 | 2Inhaltsverzeichnis
Inhalt	 	
Editorial	3
Das Richtige schnell und richtig liefern	 4
Projekte	5
Vorgehen	6
Maturität	7
Ansehen	8
Investition	9
Erhebungsgrundlagen	10	
Agile	11.
Das Missverständnis im Management	 12
Verwendung agiler Modelle	 13
Wissen im Unternehmen	 14
Erfahrung mit Agilität	 15
Zufriedenheit	16
Agile Praktiken	 17
Einführung	18
Grösste Hürden	 19
Werkzeuge	20
Agile Trend Wave	 21
Requirements	 23.
RE Prozess	 24
Aufwand	25
Qualität von Anforderungen	 26
Agilität	27
Erheben von Anforderungen	 28
Spezifikation	29
Rollen	30
Quellen und Stakeholder	 31
Mitarbeiter und Ausbildung	 32
Herausforderung	33
RE Management	 34
Werkzeuge	35
Requirements Trend Wave	 36
Testing	 37.
Testprozess	38
Das Missverständnis im Management	 39
Ein typisches Projekt	 40
Aufwand	41
Zufriedenheit	42
Herausforderung	43
Agilität	44
Wissen und Fähigkeiten	 45
Organistation	46
Testmanagement	47
Testautomatisierung	48
Last & Performance Test	 49
Testing Trend Wave	 50
Trends & Benchmarks in Software Development 2014 | 3Editorial
In den letzten Jahren / im letzten Jahrzehnt haben
sich die Disziplinen Requirements Engineering
und Testing weiterentwickelt und zunehmend
professionalisiert. Vor allem im Testing hat es einen
grossen Schub nach Vorne gegeben. Im Zuge
dessen hat sich der Druck auf das Requirements
Engineering erhöht, weil der Ursprung des viel-
fach sehr hohen Testaufwandes oft bei den unge-
nügenden Anforderungen zu finden ist. So gaben
58% der Teilnehmenden an der Umfrage dies
als die grösste Herausforderung im Testing an.
Die Erkenntnis wächst, dass man sich dieser Her-
ausforderungen nur stellen kann, wenn die
beiden Disziplinen nicht mehr nacheinander oder
schlimmstenfalls gegeneinander arbeiten,
sondern wenn sie dies miteinander tun. Zwar braucht
es weiterhin Spezialisten auf dem jeweiligen
Gebiet. Die weiterhin wachsende technische und
fachliche Komplexität setzt voraus, dass man
einen gut gefüllten Methodenrucksack hat, und
diesen projektspezifisch und pragmatisch auf die
jeweilige Situation anpassen kann – ohne das
die Qualität darunter leidet. Die eierlegende
Wollmilchsau die dies in verschiedenen Disziplinen
professionell tun kann, gibt es aber nur all
zu selten. Um so wichtiger ist es, dass die
Requirements Engineering und Testing Experten
Seit unterdessen 6 Jahren veröffentlicht SwissQ jährlich die Trends und Benchmarks Studie, mit Zahlen und Fakten zum Stand
des SW Developments in der Schweiz. Was mit den Testing Trends angefangen hat, wurde später um die Themenbereiche Requi-
rements und Agile ergänzt. Was bisher als separate Reports veröffentlicht wurde, haben wir in diesem Jahr zu einem vereint.
Grundlage dafür bildet wie bis anhin eine Online-Umfrage an der gut 500 Personen aus unterschiedlichen Firmen, Branchen und
Regionen der Schweiz teilnahmen. Zusätzlich wurden um die 25 Executive Interviews durchgeführt. Ein herzliches Dankeschön
an alle, die ihre Erfahrungen und ihr Wissen geteilt haben und an unseren Kooperationspartner, das Institut für Technologiema-
nagement der Universität St. Gallen (HSG).
kollaborieren und interdisziplinär denken. Die
anhaltende Bewegung zur Agilität, dazu zählen
auch die immer vermehrter auftretenden agilen
Wasserfall Hybriden, verstärkt das Zusammen-
wirken der beiden Disziplinen nur noch.
Als Themenführer in den Disziplinen Requirements
Engineering und Testing, mit Fokus auf Agilität,
tragen wir diesem Trend Rechnung und haben unsere
bisher separat publizierten Trends und Benchmarks
in einer Broschüre vereint. Dadurch wollen wir
einen Beitrag leisten, damit die jeweils andere
Disziplin ein grösseres Verständnis für die Prob-
leme und Herausforderungen der anderen hat.
Idealerweise können so, mit Unterstützung des
übergreifend agierenden Managements, diese
gemeinsam angegangen und gelöst werden.
Der Report beginnt mit einem übergreifenden Teil.
Danach folgen die Zahlen zu den drei Themen-
bereichen Agile, Requirements und Testing. Pro
Themenbereich werden einerseits die Benchmarks
und andererseits die SwissQ Trend Wave® präsen-
tiert. Die Benchmark Grafiken ermöglichen es, sich
im Vergleich mit den anderen Unternehmen zu
positionieren. Die Trend Waves hingegen zeigen
auf, wie sich einzelne Trends entwickeln. Dadurch
lässt sich der Einfluss der Marktveränderungen
auf das eigene Unternehmen abschätzen und es können,
falls notwendig, geeignete Vorhaben initiiert werden.
Wir hoffen, dass die vorliegenden Trends und Bench-
marks Sie dazu inspirieren, neue Herausforderungen
aktiv anzugehen und die aktuell besten Massnahmen
in Ihrem Unternehmen zu ergreifen.
Trends & Benchmarks in Software Development 2014 | 4Das Richtige schnell und richtig liefern
e
%
Doing the right things fast and right
Source: Michael Drupnikov, www.TargetProcess.com
Doing the right things fast and right
Mehr unter: www.SwissQ.it/fastSource: Michael Drupinow, www.TargetProcess.com
Trends & Benchmarks in Software Development 2014 | 5
Projekterfolg
Der Anteil der erfolgreich beendeten Projekte hat sich nochmals leicht erhöht,
andererseits ist auch der Anteil der gestoppten Projekte gestiegen.
Projektart
Im letzten Jahr hatte sich der Anteil der Neuentwicklung auf 25% verringert.
Dies zu Gunsten von mehr Erweiterungen und Wartungsprojekten. Die Baisse ist
bereits wieder überwunden. Es wird wieder vermehrt in Neues investiert.
Projekte
n Erweiterung einer
bestehenden Lösung
n Neu-Entwicklung
n Migration
n Betrieb, Support,
Wartung, Re-Design
n Einführung Standard-
Software
n Andere
4.2%
5.2%
7.4%
7.4%
37.5%
38.2%
Projektgrösse (in CHF)
15%
10%
5%
0%
über 20 Mio.
5.2%
10.8%
12.9%
9.7%
n 2011
n 2012
n 2013
n 2014
bis
100‘000
bis
500‘000
bis
1 Mio.
bis
5 Mio.
bis
20 Mio.
über
20 Mio.
20%
10%
30%
8.1%
19.4%
17.8%
27.2%
17.8%
9.7%
0%
Projekt in Zeit,
Budget,
Funktionalität
beendet
Projekt im
Rahmen,
über Budget und/
oder Zeit
Projekt
verlängert/neu
geplant
Projekt mit grossen
funkt. Änderungen
Projekt gestoppt
0%
10%
20%
30%
40%
38.8%
25.6%
18.1%
12.6%
4.9%
n 2011
n 2012
n 2013
n 2014
Trends & Benchmarks in Software Development 2014 | 6Vorgehen
Angewandte Vorgehensmodelle
71.1%
setzen ein agiles Vorgehensmodell ein.
Somit ist Agile weiter verbreitet als die
anderen Modelle.
Agiles
Vorgehen
Wasserfall-
modell
V-Modell
Iteratives
Vorgehen
Hermes
RUP
Keines
15.8% 55.3%
45.7%
40.4%
29.7%
15.0%
14.5%
71.1%
52.3%
48.4%
31.7%
20%
4%
0% 10% 20% 30% 40% 50% 60% 70% 80%
17.5%
n Alleinig
n In Kombination
Einhaltung der Vorgehensweise
n Wird grösstenteils eingehalten
n Wird teilweise eingehalten
n Wird vollständig eingehalten
n Wird nicht eingehalten
52.2%39.6%
3.7%
4.5% « Ehrlich gesagt,
arbeiten wir noch nach Wasserfall.
Einige Aspekte davon sind dann agil.
Aber klar, viele nennen dies dann gerne
gleich agil. »
Direktor eCommerce, Handel
Trends & Benchmarks in Software Development 2014 | 7Maturität
30.1%
Reifegrad Requirements
n Ausgezeichnet
n Sehr gut
n Gut
n Mittelmässig
n Schwach
12.9%
40.1%
35.3%
10.7%
1.1%
46% der Unternehmen bewerten die Reife ihrer Requirement-
Aktivitäten als mittelmässig oder gar schwach.
Reifegrad Testing
n Ausgezeichnet
n Sehr gut
n Gut
n Mittelmässig
n Schwach
22.7%
37.0%
33.1%
6.2%
1.0%
Eine deutliche Mehrheit (60.7%) bewertet die Reife des Testings
als gut, sehr gut oder gar ausgezeichnet.
Reifegrad Agile
n Läuft alles super
- keine Probleme
n Erwarteter Nutzen erfüllt
n Dauer - länger als erwartet
n Ist kompliziert
n Erfüllt die Erwartungen nicht
n Übung abgebrochen
38.4%
19.9%
7.9%
1.4%2.3%
Als relativ junge Disziplin tun sich die Unternehmen mit Agilität noch
schwer. Bei nur 1.4% läuft es super, sprich ohne wesentliche Probleme.
Trends & Benchmarks in Software Development 2014 | 8Ansehen
Ansehen des Testens
Es ist für den Erfolg der Organisation
strategisch
Es ist ein wichtiger Faktor, um verlässliche
Software zu produzieren
Es ist ein notwendiges Übel
Es hat tiefe Priorität
Die Kosten für Tests könnten wir uns sparen
15.9%
53.9%
23.1%
4.9%
2.3%
0% 20% 40% 60%
Ansehen von RE-Tätigkeiten
Es ist für den Erfolg der Organisation
strategisch
Es ist ein wichtiger Faktor, um verlässliche
Software zu produzieren
Es ist ein notwendiges Übel
Es hat tiefe Priorität
Die Kosten für RE könnten wir uns sparen
0% 20% 40% 60%
51.8%
19.5%
18.8%
8.1%
1.8%
« Die Entwicklung der RE/BA Disziplin
steht bei uns einige Jahre hinter jener des Testings.
Diese wurde früher als eigene Thematik
erkannt und gefördert. »
Department Head, Transport und Verkehr
Trends & Benchmarks in Software Development 2014 | 9Investition
0%
Pläne bezüglich Agilität
Mit 67.1% wollen zwei Drittel leicht oder signifikant in Agilität investieren.
Dies ist bedeutend mehr als in den anderen Disziplinen.
n Signifikant erhöhen
n Leicht erhöhen
n Im gleichen Umfang lassen
n Reduzieren
43.5%
23.6%
30.1%
2.8%
10%
20%
30%
40%
50% 50%
Pläne bezüglich Testing
Fast die Hälfte will die Testaktivitäten im gleichen Umfang belassen. Gleichzeitig
wollen fast so viele die Testaktivitäten leicht bis signifikant erhöhen.
n Signifikant erhöhen
n Leicht erhöhen
n Im gleichen Umfang lassen
n Reduzieren
34.1%
12.0%
48.1%
5.8%
0%
10%
20%
30%
40%
Pläne bezüglich Requirement
Mehr als die Hälfte will leicht oder signifikant in die RE Disziplinen
investieren. Allerdings wollen fast gleich viele Unternehmen
die Aktivitäten auf dem selben Stand belassen oder gar reduzieren.
n Signifikant erhöhen
n Leicht erhöhen
n Im gleichen Umfang lassen
n Reduzieren
0%
10%
20%
30%
40%
50%
41.6%
9.3%
44.2%
4.8%
Trends & Benchmarks in Software Development 2014 | 10Erhebungsgrundlagen
Wirtschaftssektor
Wie bereits in den Vorjahren stellen IT Unternehmen sowie Finanzen und
Versicherungen den grössten Teil der Teilnehmenden.
Aufgabenbereich
Viele Teilnehmende umschreiben ihre Tätigkeit mit mehr als einer Rolle.
Das Spektrum der Befragten ist insgesamt sehr breit.
IT-Mitarbeitende
0% 10% 20% 30% 40%
IT
Finanzen, Versicherungen
Industrie
Staatliche und staatsnahe
Betriebe
Transport und Verkehr
MedTech
Telekom
Andere
32.3%
30.7%
9.1%
8.1%
6.9%
30%
2.2%
6.6%
3.9%
2001 - …
501 - 2000
251 - 500
50 - 250
11 - 50
1 -10
0% 10% 20% 30% 40%
33.9%
15.7%
12.4%
17.5%
15.4%
5.1%
30%20%10%0%
Test Manager
Test Engineer / Test Analyst / Tester
Requirements Engineer
Projektleiter
Business Analyst
Berater / Consultant
Teamleiter
Abteilungsleiter / Bereichsleiter
Quality Manager / QS-Verantwortlicher
SW Engineer in Test / Testautomatisierer
C-Level (CEO / CIO / ...)
Scrum Master
Product Owner
Softwareentwickler / Developer
Solution/Software Architekt
Product Manager
Betrieb / Support
Solution Designer
Andere
24.4%
23.0%
19.9%
18.5%
18.5%
16.7%
16.3%
13.2%
9.1%
7.1%
6.7%
6.7%
6.7%
6.5%
4.9%
2.8%
2.2%
1.0%
2.8%
Agile
Requirements
Testing
Agile - Trends & Benchmarks in Software Development 2014 | 12Das Missverständnis im Management
Das Dilemma
Bei den agilen Vorgehen ergeben sich spannende Unterschiede, in der
Wahrnehmung wenn man die Antworten des Managements mit den
Antworten der Entwickler vergleicht (inklusive PO und Scrum Master).
Die Zahlen zeigen auf, dass das Management die Verankerung der Agilität
im Unternehmen und allgemein den Kenntnisstand viel positiver
einschätzt. Offensichtlich unterschätzt das Management die Herausfor-
derungen, welche mit der Einführung agiler Vorgehen verbunden sind.
Gründe für das Scheitern agiler Methoden
Externer Druck einem
klassischen Vorgehen zu folgen
42.5%
28.8%
Fehlende Unterstützung
durch das Management
42.7%
57.7%
Unpassendes Projekt
25.0%
15.4%
n Sicht Management n Sicht Entwickler
So sehen die Entwickler die fehlende Unterstützung durch die Führungs-
kräfte auch als einer der Hauptgründe für das Scheitern. Das Management
selber übrigens auch, einfach nicht im gleichen Ausmass. Ähnliche
Divergenzen ergeben sich bei den Gründen die für Agilität sprechen. Inte-
ressanterweise denken die Entwickler eher als die Manager, dass Agilität
dazu dient, die Produktivität zu erhöhen. Das entspricht der Wahrneh-
mung, dass Entwickler oft überfordert sind vom ständigen Druck Ergebnisse
liefern zu müssen.
Verankerung der Agilität im Unternehmen
Manager schätzen die vollständige Verankerung der Agilität in der Soft-
wareentwicklung positiver ein, als die Entwickler.
Management Entwickler40.4%
26.4%
Kenntnissstand agiler Methoden
Manager überschätzen die sehr guten Kenntnisse der Softwareentwickler
bezüglich agiler Methoden.
Management Entwickler29.3%
18.9%
Gründe für agile Methoden
Produktivität erhöhen
40.5%
50.9%
Zusammenspiel
Business und IT verbessern
57.1%
47.2%
Sichtbarkeit von
Projekten erhöhen
28.6%
37.7%
Entwicklungsdisziplinen
verbessern
n Sicht Management n Sicht Entwickler
21.4%
11.3%
Agile - Trends & Benchmarks in Software Development 2014 | 13Verwendung agiler Modelle
41.5%
der Unternehmen führen 1 - 20% der
Projekte agil durch. Somit findet eine
Verbreitung statt, wobei sich die Firmen
zögernd an das Thema annähern.
Verteilung agiler Projekte in den Unternehmen
Es wird erst ein kleiner Teil der Projekte agil durchgeführt. Unternehmen wagen
sich somit langsam an das Thema heran und prüfen erst, ob sich der breitere
Einsatz wirklich lohnt. Wenige Unternehmen (32.8%) setzen in mehr als der
Hälfte der Projekte agil Vorgehen ein.
0% 1-20% 21-50% 51-80% 81-99% 100%
20%
10%
30%
8.1%
41.5%
23.1%
16.6%
7.9% 8.3%
0%
40%
50%
Anzahl agiler Projekte im Unternehmen
41.9%
haben Scrum alleinig und somit in „Ur-Form“ im Ein-
satz. In den gleichen Unternehmen, aber einer anderen
Einheit, sind oft auch weitere Modelle wie Kanban
oder Lean Development anzutreffen.
Angewandte agile Vorgehensmodelle
Wird der rein agile Markt betrachtet (= Unternehmen, welche agile Vor-
gehensmodelle im Einsatz haben), ist Scrum der deutliche Marktführer
vor Kanban.
0% 20% 40% 60%
41.9% 55.3%Scrum
Kanban
Lean Development
SAFe
Extreme Programming (XP)
Feature Driven Development (FDD)
ScrumBan
Agile Unified Process (AgileUP)
DSDM
DAD
80% 100%
35.9%
97.2%
42.8%
13.8%
3.7%
16.6%
6.9%
12.4%
7.4%
0.5%
1.4%
n Alleinig
n In Kombination
Agile - Trends & Benchmarks in Software Development 2014 | 14Wissen im Unternehmen
Wer kennt sich mit Agilität aus?
Das Wissen über agile Methoden wird in den Unternehmen als hoch ein-
geschätzt. Dies im Gegensatz zu den Erfahrungen aus dem Alltag, wo oft
oberflächliches Wissen anzutreffen ist.
Scrum Master
Product Owner
Softwareentwickler / Developer
Teamleiter
Projektleiter
Solution / Software Architekt
QA / Tester
Test Manager
Business Analyst /
Requirements Engineer
Abteilungsleiter / Bereichsleiter
C-Level (CEO / CIO /...)
Business / Fachbereich
36.9%
36.2%23.2% 23.2%
40.8%19.6%
41.0%
22.8%
41.6%15.9% 26.5% 13.3%
15.2% 44.6% 29.5%
42.2% 22.9%
40.4% 32.4% 9.8%
37.9% 32.6% 10.3%
39.0% 31.8% 12.1%
31.3% 29.5% 25.9%
17.8% 34.2% 29.3%
16.3% 33.9% 35.3%
0% 20% 40% 60% 80% 100%
n Sehr gut n Gut n Gering n Sehr gering n Weiss nicht
Verankerung der Agilität im Unternehmen
Agilität scheint nur in der IT ein Thema zu sein. Für die anderen Bereiche
ist es nur bedingt relevant. Entsprechend tun sich viele IT-Organisationen
in Zusammenarbeit mit der Fachseite oder den Kunden schwer.
n Vollständig n Grösstenteils n Teilweise n Gar nicht
18.0% 38.8% 31.7%
46.4%35.6%14.0%
12.2% 39.2% 44.1%
49.5%
46.0%
58.3%
34.1%
41.5%
30.9%
12.3%
10.7%
9.0%
0% 20% 40% 60% 80% 100%
In der Software-
entwicklung
Im IT
Management
Im Product
Management
Im IT Portfolio
Management
Im Fachbereich
Im Betrieb
« Intern arbeiten wir agil,
nach aussen gemäss V-Modell,
weil „agil“ beim Kunden nicht gern gehört wird »
Bereichsleiter, staatsnahe Betriebe
Agile - Trends & Benchmarks in Software Development 2014 | 15Erfahrung mit Agilität
Persönlicher Kenntnisstand agiler Methoden
Sehr erfahren
(seit Jahren
praktisch im
Einsatz)
Wenig erfahren
(theoretisches
Wissen)
Erfahren
(bereits erste
Projekte
durchgeführt)
Keine
Erfahrung
29.7%
48.9%
18.8%
2.6%
n 2012
n 2013
n 2014
0%
10%
20%
40%
Wird bisher
nicht
angewandt
Weniger als
1 Jahr
1-2 Jahre 2-5 Jahre Mehr als
5 Jahre
20%
10%
30%
0%
40%
50%
6.6%
9.2%
26.4%
46.5%
7.4%
Erfahrung der Unternehmen mit Agilität
Die Unternehmen weisen meist sehr wenig Erfahrung im Umgang mit Agilität
auf. Dies wird auch bestätigt durch die immer noch kleine Anzahl an agilen
Projekten.
« Je länger wir nun agil arbeiten, desto weniger
kommunizieren die Teammitglieder miteinander.
Fast wie ein Rückfall in alte Zeiten! »
Head Software Development, Industrie
« Unsere Prozesse und Methoden sind für
Organisationen mit tausenden von IT-lern ausgelegt.
Wir sind jedoch nur einige hundert.
Wir müssen etwas schlankeres, flexibleres haben. »
CIO, Energie
Agile - Trends & Benchmarks in Software Development 2014 | 16Zufriedenheit
Hauptgründe für das Scheitern agiler Projekte
52%
Unternehmens-
philosophie nicht mit
agilen Werten verknüpfbar
(Theorie mit Praxis nur
schwer vereinbar)
49%
Fehlende Erfahrung
mit agilen
Vorgehensmethoden43%
Fehlende Unterstützung
durch das Management
31%
Fehlende/
ungenügende
Schulung/
Coaching
26%
Externer Druck
weiter einem
klassischen
Modell zu folgen
24%
Fehlende
Verbindung
zwischen den
Organisationsein-
heiten
25%
Unpassendes Projekt
für Einführung
Zufriedenheit
n Läuft alles super
- keine Probleme
n Erwarteter Nutzen erfüllt
n Dauer länger als erwartet
n Ist kompliziert
n Erfüllt die Erwartungen nicht
n Übung abgebrochen
( ) = Veränderung zu Umfrage 2013
30.1%
(+0.8%)
38.4%
(-5.2%)
19.9%
(+7.9%)
7.9%
(-0.7%)
1.4%
(-5.0%)
2.3%
(k.A.)
Im Vergleich zum Vorjahr
Läuft alles
super -
keine
Probleme
Erwarteter
Nutzen
erfüllt
0%
20%
30%
40%
10%
38.4%
1.4%
6.4%
43.6%
n2013
n2014
12.0%
19.9%
ist
kompliziert
Agile - Trends & Benchmarks in Software Development 2014 | 17Agile Praktiken
Management Practices
Daily Standup
Backlog Management
Sprint Review / Product Demo
Burndown Chart
Definition of Done
Retrospektiven
Release Planning
Iterative Planung
Taskboard
Planning Poker
Dedicated Product Owner
Product Roadmap
Velocity Chart
Definition of Ready
Priority Poker
Work in Progress (WiP) Limits
Co-Location
On-Site Customer
n Werte aus 2014
n Werte aus 2013
78.6%
75.0%
73.2%
65.9%
65.0%
62.7%
56.8%
54.5%
54.1%
40.5%
34.1%
30.9%
28.6%
27.7%
15.5%
15.0%
11.4%
8.6%
0% 20% 40% 60% 80%
Engineering Practices
Unit Testing
Continuous Integration
Automated Build
Issue/Bug Tracker
Refactoring
Test Driven Development (TDD)
Pair Programming
Acceptance Test Driven
Development (ATDD)
Automated Acceptance Testing
Collective Ownership
Behavior Driven Development (BDD)
Andere
72.3%
60.5%
54.5%
53.6%
40.5%
34.1%
29.5%
17.3%
16.8%
16.8%
6.4%
4.5%
n Werte aus 2014
n Werte aus 2013
0% 20% 40% 60% 80%
« Wir sehen Agilität als Werkzeugkasten,
nicht als die ultimative Lösung. »
Bereichsleiter, Industrie
Agile - Trends & Benchmarks in Software Development 2014 | 18Einführung
Gründe für agile Methoden
Fähigkeit erhöhen, mit sich
ändernden Prioritäten umzugehen
Beschleunigung der
Time-to-Market
Zusammenarbeit zwischen
Business und IT verbessern
Teammoral verbessern
Risiken minimieren
Produktivität erhöhen
Entwicklungsprozesse
vereinfachen
Wartbarkeit und Erweiterbarkeit
von Software erhöhen
Kosten reduzieren
Sichtbarkeit von Projekten
erhöhen
Management von
verteilten Teams
Entwicklungs-Disziplinen
verbessern
58.0%
50.9%
50.0%
41.0%
34.4%
31.1%
28.3%
25.0%
17.5%
15.1%
13.2%
8.0%
0% 20% 40% 60%
58%
sehen den grössten Vorteil
im einfacheren Umgang
mit sich ändernden
Prioritäten.
50.9%
sehen in agilen Vorgehen
kürzere Projektlaufzeiten
und schnellere Reaktionen
auf Kunden- bzw. Markt-
bedürfnisse.
17.5%
und damit weniger als
im letzten Jahr, möchten
Agilität einsetzen, um
Kosten zu sparen.
« Durch die Umstellung auf Agil
konnten wir die Motivation und Zufriedenheit
unserer Mitarbeiter steigern und dies, obwohl
die Entwicklung extern durchgeführt wird. »
Bereichsleiter Online, Bank & Versicherungen
Agile - Trends & Benchmarks in Software Development 2014 | 19Grösste Hürden
0% 10% 20% 30% 40%
Kontrollverlust
Widerstand im Management
Mangel an Dokumentation
Mangel an vorbereitender
Planung
Kunde (intern / extern) kann
nicht mithalten
Projekte zu gross oder
zu komplex
Mangel an Vorhersehbarkeit
Einhalten von regulatorischen
Vorgaben (Compliance)
Zu wenig Zeit für eine
nachhaltige Veränderung
Zu wenig Zeit für eine
nachhaltige Veränderung
Nicht verträglich
mit Outsourcing / Offshoring
Kosten
Nicht skalierbar
39.2%
33.5%
32.1%
30.2%
27.8%
26.4%
22.2%
20.8%
17.9%
13.7%
13.2%
6.6%
6.1%
Die grössten Hürden bei der Einführung
39.2%
Kontrollverlust wird als grösste
Hürde bei der Einführung von
Agilität gesehen.
33.5%
sehen grossen Widerstand im
Management. Dies bestätigt die
Aussage, dass die fehlende Unter-
stützung durch das Management
einer der Hauptgründe für das
Scheitern agiler Projekte sei.
32.1%
sehen als grosse Hürde den
Mangel an Dokumentation. Dies-
bezügliche (interne?) Vorgaben
scheinen vielen Agilisten immer
noch das Leben schwer zu machen.
Über Sinn und Unsinn wird sich
gut diskutieren lassen.
« Es entstehen oft dort Probleme,
wo Teams aufeinander treffen
und Verantwortung übergeben werden muss. »
Leiter Technologie, Medienbranche
Agile - Trends & Benchmarks in Software Development 2014 | 20Werkzeuge
Verwendete Tools im agilen Umfeld
Atlassion JIRA / Greenhopper ist das Werkzeug mit dem grössten Marktanteil
und hat das erste Mal MS Office an der Spitze abgelöst.
Atlassian JIRA / Greenhopper
MS Office (Word, Excel)
HP QC / ALM
Confluence
MS Team Foundation Server
Bugzilla
HP Sprinter
Polarion
Eigene Entwicklung
IBM Rational Team Concert
Rally Software Development
Inflectra Spira
Scrumy
Version One
Andere
0% 20% 40% 60%
51.4%
43.6%
38.2%
27.7%
19.1%
6.8%
6.4%
6.4%
3.6%
3.2%
2.3%
1.8%
1.8%
0.5%
11.8%
Die grössten Veränderungen zum Vorjahr
MS
Office
0%
40%
Atlassian
JIRA /
Green-
hopper
HP QC /
ALM
MS Team
Foundation
Server
60%
80%
51.4%
38.2%
19.1%
n2012
n2013
n2014
20%
43.6%
« Alleine der übergreifende „Compile“
und die Systemintegration dauert 2 Tage.
Da können wir von 2 Wochen Sprints nur träumen. »
Head Software Development, staatsnahe Betriebe
Agile - Trends & Benchmarks in Software Development 2014 | 21Agile Trend Wave
INTRODUCTION GROWTH MATURITY DECLINEPRIORITY
TIME
Management 3.0
Soft Skill Awareness
Taskboard
Stand Ups
User Stories
Story Points
Release Planning
Agile Portfolio Management
Agile Planning Tools
Definition of Ready
Embedded Test
3-4 Wochen Sprints
Scrum
Definition of Done
SAFe
Agile Transformation
Wasserfall / Scrum Hybrid
Kanban
ATDD
2 Wochen Sprints
Retrospectives
Planning Poker
Dedizierter PO
Priorisierung und Backlog Mgmt
INTRODUCTION– Das Thema wurde erkannt
und einige Unternehmen arbeiten an ers-
ten Umsetzungen. Es ist allerdings nicht
absehbar, ob sich dieser Trend positiv
weiterentwickelt und das Testing tatsäch-
lich erheblich beeinflussen wird.
GROWTH – Das Thema wird immer mehr
anerkannt und viele Unternehmen
gehen darauf ein. Es entstehen die
ersten Werkzeuge und Beratungsfirmen
bieten Dienstleistungen dazu an. Mit der
fehlenden Erfahrung bei der Umsetzung
gehen oft diverse Risiken einher.
MATURITY – Die meisten Unternehmen
arbeiten an der Umsetzung oder haben
diese bereits abgeschlossen. Das Wissen
zu dem Thema ist oft sehr verbreitet,
wobei häufig auch Unterarten dazu ent-
stehen.
DECLINE – Das Thema wurde von den
meisten Unternehmen, mit Ausnahme
einzelner Nachzügler, bereits umgesetzt.
Wissen in diesen Bereichen neu aufzu-
bauen generiert oft keinen Nutzen mehr,
da dieses in Kürze obsolet wird.
Agile - Trends & Benchmarks in Software Development 2014 | 22
«Agilität löst die Probleme nicht,
zeigt diese aber früher auf.»
Agile
Requirements
Testing
Requirements - Trends & Benchmarks in Software Development 2014 | 24RE-Prozess
4. Prüfen
5. Verwalten
RE Zufriedenheit
Unzufrieden
Mittelmässig
Zufrieden
1. Erheben
38.6%
11.8%
49.6%
3. Dokumentieren
29.4%
21.0%
49.6%
20.6%
24.3%
55.1%
21.7%
29.4%
48.9%
2. Analysieren
40.4%
13.6%
46.0%
5
4
3
2
1
61.4%
der Projekte sind mit der
Erhebung von Anforderun-
gen mittelmässig oder gar
nicht zufrieden.
70.6%
sind mit dem Dokumen-
tieren von Anforderun-
gen unglücklich. Die oft
gelobten Notationen und
Werkzeuge scheinen
nicht zu befriedigen.
20.6%
sind mit dem Prüfen von
Anforderungen nur zu-
frieden. Je später eine
Aktivität im RE-Prozess
stattfindet, desto unzu-
friedener sind die Un-
ternehmen mit diesen.
Unterwegs scheint die
Energie und eventuell der
Fokus verloren zu gehen.
Requirements - Trends & Benchmarks in Software Development 2014 | 25Aufwand
Aufwand RE im Verhältnis
zum Gesamtaufwand
0%
10%
20%
30%
bis 5% 6-10% 11-15% 16-20% 21-30% 31-50% darüber
RE-Aufwand im Verhältnis zum Gesamtprojektaufwand
12.4%
18.2%
27.5%
15.1%
18.6%
5.8%
2.3%
n2013 n2014
bis 5% 6-10% 11-15% 16-20% 21-30% 31-50% darüber
RE-Aufwand im Verhältnis zum Entwicklungsaufwand
0%
10%
20%
30%
Gesamt-
aufwand
Entwicklungs-
aufwand
Der durchschnittliche
RE-Aufwand im Verhältnis
zum Gesamtprojektaufwand
wird über die Jahre konstant
auf 16 – 20% geschätzt.
Der RE-Aufwand im
Verhältnis zum Entwick-
lungsaufwand wird im
Durchschnitt auf 16-20%
geschätzt.
RE-Aufwand
16-20%
RE-Aufwand
11-15%
17.1%
8.2%
18.2%
21.6%
16.7%
13.4%
4.8%
Aufwand RE im Verhältnis
zum Entwicklungsaufwand
Requirements - Trends & Benchmarks in Software Development 2014 | 26Qualität von Anforderungen
Gründe für ungenügende Anforderung
Massnahmen zur Qualitätsverbesserung
Missverständnisse in der Kommunikation
Stetig wachsende oder ändernde Anforderungen
Falsche oder keine Priorisierung von Anforderungen
Unvollständige/falsche Quellen (Stakeholder) als
Basis für Anforderungen verwendet
Zu wenig Zeit für RE vorhanden
(Kosten-/Termindruck)
Sprachliche Fehler: Unverständlichkeit,
Missverständlichkeit, Unquantifizierbarkeit
Inhaltliche Fehler: Falsche Sachverhalte,
Unvollständigkeit, zu abstrakte Formulierungen
Mangelhaftes Know-How
Änderung der Randbedingungen
(Priorisierung, Budgetierung, Marketingstrategie, etc.)
Systematische Fehler: Fehlender Business Value /
Nutzen für das Projekt
Logische Fehler: Widersprüchlichkeit,
Redundanz
Machbarkeit falsch eingeschätzt
Pilotbetrieb, Prototypen, Analysen, zusätzliche
Know-How-Träger, etc. führen zu neuen Erkenntnissen
Änderung der Stakeholder-Zusammensetzung
Fehlende oder falsche Unterscheidung zwischen
funktionalen und nicht-funktionalen Anforderungen
20% 40% 60%0%
52.8%
46.8%
37.5%
36.8%
35.7%
24.2%
24.2%
23.8%
20.4%
17.5%
14.5%
13.8%
7.8%
6.7%
5.2%
Interne Aus- und Weiterbildung
Etablierung interner Vorlagen
und Normen
Gezieltes Einstellen von Requirements
Engineers / Business Analysten
Etablierung interner Standard RE Prozesse
(inkl. Rollen)
Etablierung von Standard Tools
Einkauf von externen Spezialisten
Systematische Ausbildung nach IREB
Definierte Fachlaufbahn für Require-
ments Engineers / Business Analysten
Systematische Ausbildung nach IIBA
0% 20% 40% 60% 80% 100%
71.5%
52.0%
55.2%
57.3%
26.6%
29.3%
31.3%
18.3%
24.0%
20.1%28.0%
28.2%
39.8%
41.3%
44.8%
50.2%
28.5%
53.6%
16.7%
14.2%
33.6%
29.3%
23.9%
31.5%
22.4%
n Umgesetzt n Geplant n Nicht geplant
« Unser Top-Thema 2014: Die Balance halten zwischen
Planbarkeit einfordern und Flexibilität behalten. »
Head of R&D, Industrie
Requirements - Trends & Benchmarks in Software Development 2014 | 27
Requirements Engineering im Kontext von Agilität
Agilität
31.5%
glauben immer noch,
dass ein formaler Change
Request Prozess benötigt
wird! Dies im Vergleich zu
40.7% im 2013.
50%
sind einverstanden,
dass der Umfang der
Spezifikationen deutlich
geringer geworden ist.
46.3%
sehen keine Unsicherheit
bei den BA‘s und RE‘s.
Dies im Gegensatz zu den
Aussagen der IT- Executives.
70.6%
spezifizieren (fast) nur
Anforderungen im Detail,
welche dann auch umge-
setzt wurden.
56.5%
sehen grundsätzlich
User Stories als Doku-
mentationsform. Dies
ist eine starke Ab-
nahme zu 71.3%
im 2013.
91.2%
sehen den Bedarf
von Requirements
Engineering in agilen
Projekten.
Der Product Owner priorisierte das
Product-Backlog regelmässig
Man hat jederzeit den Überblick,
was gerade implementiert wird
Die Stakeholder sind stärker involviert
Änderungen im (Product-)Backlog brauchen
keinen formalen Change Prozess mehr
Es wurden (fast) nur Anforderungen im Detail
spezifiziert, welche umgesetzt wurden
Jedes Team organisiert sich selbstständig
und macht RE ein bisschen anders
Der Umfang der Spezifikation ist
deutlich geringer geworden
Die Dokumentationsform ist neu in User Stories
Die Unsicherheit der Business Analysten /
Requirements Engineers ist grösser geworden,
da die Prozesse unklar sind
Es gibt keine formalen Vorgaben mehr bezüglich
Dokumentation von Anforderungen
Mit der Einführung des Produktes war stets auch
eine saubere Dokumentation vorhanden
Es braucht kein Requirements Engineering mehr
39.2% 40.6%
40.8%38.0% 15.0%
44.9%24.8% 21.5%
36.6%20.7% 31.5%
51.9%18.7% 17.8%
42.1%17.3% 28.5%
38.7% 39.2%
45.8% 34.6%
29.0% 46.3%
23.9% 62.9%
91.2%
36.8% 45.8%
15.9%
0% 20% 40% 60% 80% 100%
n Voll einverstanden n Mehrheitlich einverstanden n Nicht einverstanden n Kann ich nicht beurteilen
Requirements - Trends & Benchmarks in Software Development 2014 | 28Erheben von Anforderungen
Techniken zur Erhebung
von Anforderungen
Verbesserungspotenzial bei Erhebung
von Anforderungen
Interview
Analyse bestehender Systeme
(System Archeology)
User Stories
Workshop-Techniken
Prototyping
Erfahrungswissen nutzen
Wiederverwendung von
Anforderungen
Brainstorming (-Paradox)
Storyboard
Umfrage / Fragebogen
Szenario
On-Site Customer
User Walkthrough
Feldbeobachtung
Design Workshops (JAD)
Apprenticing
Contextual Inquiry
Perspektivenbasierte Lesen
Analogietechniken
6 Hut Denken
Methode 635
Osborn Checkliste
Andere
75.5%
50.5%
46.3%
41.5%
34.6%
33.5%
29.8%
22.8%
19.9%
19.1%
19.1%
18.4%
18.0%
17.3%
20%0% 40% 60% 80%
Vereinfachung der visuellen Kommunikation
(Bsp. Visualisierung anstelle von UML Modellen)
Einbezug von Fachvertretern
Einbezug von IT
Bereitschaft, Anforderungen während einem
Kaffeegespräch zu formulieren
Wechsel der Dokumentationsform während der
Erhebungsphase
Gruppenarbeiten mit Rollenspielen
n Sehr Hoch n Hoch n Mittel n Ungeplant
20.5%
20.4%
44.4%
43.4%
25.4%
30.2%
45.9%31.6%
30.3% 38.2% 13.2%
26.5% 42.8% 25.8%
19.4% 41.1% 32.1%
20%0% 40% 60% 80% 100%
« Unseren Mitarbeitenden fehlt oft der methodische
Rucksack, um die Priorität der einzelnen Requirements
einzufordern. »
Head of R&D, Industrie
Requirements - Trends & Benchmarks in Software Development 2014 | 29Spezifikation
Techniken zur Spezifikation von Anforderungen
Prosa ist immer noch die am meisten verwendete Spezifikationstechnik.
Modernere Techniken holen erst langsam auf.
Reviewtechniken
(Inspektionen, Peer-Reviews, ...)
Ableiten von Testfällen
Prototypen erstellen
Checklisten
Modellierung
Konsultationen
Simulationen
Toolgestützte Methoden
Andere
Keine
65.9%
47.8%
35.2%
21.5%
15.2%
9.3%
4.1%
4.1%
1.1%
9.3%
20%0% 40% 60% 80%
Techniken zur Prüfung von Anforderunngen
Natürliche Sprache (Prosa)
Use Case Spezifikationen
Mockups / Prototypen / Screens / UI-Design /
Storyboards (Screenabläufe)
Handskzizzen / Flipcharts
Aktivitätsdiagramme
User Stories
Use Case Diagramme
Glossar
Datenflussdiagramme
Business Rules
BPMN Diagramme
Szenarien beschreiben
Kontextdiagramme
Klassendiagramme
Sequenzdiagramme
Sprachschablonen
Zustandsautomaten
Planguage
EPKs
Andere
53.5%
48.3%
40.2%
35.8%
35.1%
33.9%
33.2%
22.9%
19.9%
19.6%
16.6%
14.8%
14.0%
12.9%
12.2%
6.6%
3.7%
2.6%
0.7%
3.3%
20%0% 40% 60%
« Wir betrachten die Anforderungsspezifikationen
erst als abgeschlossen,
wenn Entwicklung und Testing beendet sind. »
Bereichsleiter, Industrie
Requirements - Trends & Benchmarks in Software Development 2014 | 30
Aufgabenträger von RE/BA Tätigkeiten
Rollen
Verwendete Rollenbegriffe
Business Analyst
Requirements Engineer
Business Engineer
Requirements Manager
System Engineer
Sonstiges
58.7%
53.1%
19.6%
12.5%
10.7%
11.4%
20%0% 40% 60%
74.7%
Die Rolle des Requirements
Engineers bzw. Business
Analysten ist im Markt der
meistgenannte Aufgabenträger
von RE/BA Tätigkeiten.
74.7% 31.7% 25.3% 23.1% 21.7% 17.8% 7.8%
RequirementsEngineer/
BusinessAnalyst
Projektleiter
Fachvertreter/Kunde
ProductOwner
ProductManager
Entwickler
Tester
KeinedezidierteRolle
Andere
3.9% 2.1%
Requirements - Trends & Benchmarks in Software Development 2014 | 31Quellen und Stakeholder
Anforderungsquellen
Es werden oft verschiedene Quellen von Anforderungsquellen eingesetzt.
Da diese oft aus dem eigenen Umfeld kommen, finden keine grossen
Veränderungen statt. (welche z.B. durch externe Experten oder Lieferanten
entstehen könnten).
Aufwand Stakeholder-Analyse
Direkte und indirekte
Anwender
Sponsoren und
Auftraggeber
Bestehendes Produkt/
Software
Regulatorien und gesetzliche
Bestimmungen
Designer und Entwickler
Berater und Experten
Lieferanten
64.1%
63.3%
56.9%
40.2%
18.9%
10.3%
2.8%
n kein Aufwand, die Stakeholder
sind vorgegeben
n Weniger als 1 Personentag
n 1-5 Personentage
n Mehr als 5 Personentage
( ) = Veränderung zu Umfrage 2013
23.1%
(-4.1%)
31.3%
(+4.6%)
32.0%
(-4.4%)
13.5%
(+3.8%)
« Die Projektleiter geben uns oft vor,
welche Stakeholder wir abholen sollen und welche nicht.
Kein Wunder haben wir öfters blinde Flecken. »
BA, Transport und Verkehr
Requirements - Trends & Benchmarks in Software Development 2014 | 32Mitarbeiter und Ausbildung
AusbildungFähigkeiten RE-Mitarbeiter
Der Eindruck trügt. Ein Drittel der Unternehmen ist mit den Fähigkeiten der
RE-Mitarbeitenden nicht zufrieden. Fachwissen ist zwar oft vorhanden,
der methodische Teil leidet jedoch sehr.
Tool Erfahrung
Workshop-Moderation
Methodenwissen
Strukturierung und
Vorbereitung von Workshops
Dokumentation von
Anforderungsspezifikationen
Prozesswissen
Technisches Wissen (IT)
Konsensbildung
Formulierung verständlicher
Anforderungen
Sprachliche Kommunikation
Fachwissen (des jeweiligen Bereichs)
IREB® Cert. Professional for Requirements Engineering
(Foundation Level)
ISTQB Foundation Level
ITIL
Projektmanagement (IPMA, PMI, ...)
Certified Scrum Master
Agiles Requirements Engineering
Certified Product Owner
CAS Requirements Engineering
Qualitätsmanagement (dipl. Quality Manager, ...)
MAS Business Analysis
IREB® Cert. Professional for Requirements Engineering
(Advanced Level Elicitation & Consolidation)
IIBA CBAP (Certified Business Analysis Professional)
IREB® Cert. Professional for Requirements Engineering
(Advanced Level Requirements Modeling)
43.1%
34.8%
20%0% 40% 60%
39.8%
37.0%
35.5%
32.8%
32.6%
34.6%
32.9%
30.4%
32.0%
19.5%
57.3%
39.4%
44.9%
41.2%
47.8%
47.3%
49.6%
47.5%
56.2%
50.9%
61.0%
31.3%
18.4%
20%0% 40% 60% 80% 100%
n Eher nicht n Mässig n Gut n  Sehr Gut
n Bereits erworben n Ist geplant
80%
36.4%
28.0%
26.1%
16.3%
14.1%
14.4%
12.9%
Requirements - Trends & Benchmarks in Software Development 2014 | 33Herausforderung
Herausforderungen im RE
Sicherstellung der Rückverfolgbarkeit
(Traceability)
Behandlung von Qualitätsanforderungen
(nicht funktionalen Anforderungen)
Fähigkeiten/skills des RE / BA
Verwaltung von > 500 Anforderungen
pro Projekt / Produkt
Anforderungserhebung
in verteilten Teams
Nachhaltige Dokumentation von
Anforderungen in agilen Projekten
Anerkennung der RE/BA Tätigkeiten
Abgrenzung natürlichsprachlicher
Anforderungen vs. Use Cases
Rückführung von Projektanforderungen
in Produktanforderungen
Requirements Engineering
in agilen Projekten
Umgang mit
Usability Anforderungen
Umgang mit sich steigernder Erstellung
von Anforderungen in agilen Projekten
Integration / Zusammenarbeit
verschiedener Tools
Schneiden von User Stories
(Von Epics zu User Stories)
Andere
Erfolgsfaktoren für gutes RE
45.7%
Die sozialen Fähigkeiten
eines RE‘s/BA‘s ist der meist
genannte Erfolgsfaktor,
direkt vor dem Methoden-
wissen. Leider sind diese
nicht oft anzutreffen, auch
wenn gerade die Kombi-
nation beider gewünscht/
erwünscht ist.
10%0% 20% 30% 40%
34.0%
29.5%
28.7%
28.4%
26.9%
25.0%
18.7%
16.8%
16.8%
16.0%
14.9%
14.6%
13.1%
10.4%
4.9%
Soziale Fähigkeiten des RE/BA
(Kommunikation, Empathie, Konfliktmanagement, ...)
Methodenwissen des RE/BA
(Elicitaiton-, Dokumentations-, Reviewtechniken, ...)
Modellierung der Anforderungen
(z.B. mittels Use Cases)
Erstellen von Abnahmekriterien
Saubere Stakeholderanalyse
Verwendung eines definierten RE Prozesses
Branchen-Knowhow des RE/BA
(Domänenwisssen, Produktwissen)
Strukturierte Reviews
0% 10% 20% 30% 50%40%
45.7%
31.1%
30.3%
28.8%
28.5%
23.6%
22.8%
21.0%
Requirements - Trends & Benchmarks in Software Development 2014 | 34
Meilensteine erreichen
Vorgaben einhalten
Reviews durchführen
Einhalten von Prozessen
Entscheidungen herbeiführen
Bei neuen Erkenntnissen
Vorgehen anpassen
Scope aktiv führen
Anforderungssteller
bewusst begleiten
Methodisch korrekt
vorgehen
Traceability konsistent halten
Modelle weiterverwenden
1 Soziale Fähigkeiten des RE/BA
(Kommunikation, Empathie, Konflikt-Management,...)
2 Methodenwissen des RE/BA
(Elicitation-, Dokumentations-, Reviewtechniken,...)
3 Modellierung der Anforderungen
(z.B. mittels Use Cases)
45.7%
31.1%
30.3%
1
Unwichtig
2
Sekundär
3
Wichtig
4
Sehr wichtig
0
3.33%
2.97%
2.88%
2.86%
2.86%
2.64%
2.61%
2.50%
2.44%
2.33%
2.21%
RE Management
Die RE Prioritäten in den Unternehmen
In vielen Unternehmen ist es wichtiger Meilensteine zu erreichen, als das Vorgehen
neuen Erkenntnissen anzupassen.
« Die grosse Herausforderung besteht im Zu-
sammenspiel der einzelnen Disziplinen.
Einzeln geht es gut. Sobald jedoch integriert
gearbeitet werden soll, wird es schwierig. »
Bereichsleiter, Finanzen & Versicherungen
« Wir nutzen das V-Modell
als Entscheidungsmodell,
nicht als Vorgehensmodell. »
Bereichsleiter, Industrie
Erfolgsfaktoren für gutes RE
Requirements - Trends & Benchmarks in Software Development 2014 | 35
Tools im RE
Die grössten Veränderungen zum Vorjahr
0%
20%
40%
60%
80%
100%
n 2012
n 2013
n 2014
MS Office
(Word, Excel)
Atlassian JIRA Sparx Wiki
66.3%
28.2%
23.4%
16.1%
Microsoft Office (Word, Excel)
Microsoft Visio
Stift und Papier
Atlassian Jira
Balsamiq Mockups
Sparx Enterprise Architect
HP QC / ALM
Atlassian Confluence
Wiki
Polarion Requirements
Microsoft Team
Foundation Server (TFS)
Eigene Entwicklung
IBM Rational DOORS
IBM Rational Requisite Pro
Google Docs
IBM Rational
Requirements Composer
Serena Requirements Manager
Visure Requirements (ex IrQA)
Andere
0% 20% 40% 60% 80%
41.8%
30.0%
28.2%
25.3%
23.4%
22.3%
17.9%
16.1%
9.5%
66.3%
9.2%
5.9%
4.8%
4.4%
2.6%
2.2%
2.2%
0.7%
13.9%
Werkzeuge
Requirements - Trends & Benchmarks in Software Development 2014 | 36
PRIORITY
TIME
INTRODUCTION GROWTH MATURITY DECLINE
Requirements Trend Wave
JAD
Priority Poker
Workshop
RE Tools
Prosa
IREB AL
Storyboards
Agile RE
Sprachschablonen
Scrum
IREB FL
Backlog Management
Facilitator
User Stories
Modelling Tools
Business Value
Interviews
RE Competence Center
Reviews
Visual Facilitation
BPMN
UX
Traceability
ALM Tools
Use Cases
INTRODUCTION– Das Thema wurde erkannt
und einige Unternehmen arbeiten an ers-
ten Umsetzungen. Es ist allerdings nicht
absehbar, ob sich dieser Trend positiv
weiterentwickelt und das Testing tatsäch-
lich erheblich beeinflussen wird.
GROWTH – Das Thema wird immer mehr
anerkannt und viele Unternehmen
gehen darauf ein. Es entstehen die
ersten Werkzeuge und Beratungsfirmen
bieten Dienstleistungen dazu an. Mit der
fehlenden Erfahrung bei der Umsetzung
gehen oft diverse Risiken einher.
MATURITY – Die meisten Unternehmen ar-
beiten an der Umsetzung oder haben die-
se bereits abgeschlossen. Das Wissen zu
dem Thema ist oft sehr verbreitet, wobei
häufig auch Unterarten dazu entstehen.
DECLINE – Das Thema wurde von den
meisten Unternehmen, mit Ausnahme
einzelner Nachzügler, bereits umgesetzt.
Wissen in diesen Bereichen neu aufzu-
bauen generiert oft keinen Nutzen mehr,
da dieses in Kürze obsolet wird.
Agile
Requirements
Testing
Testing - Trends & Benchmarks in Software Development 2014 | 38Testprozess
4. Testdurchführung
5. Testauswertung
Zufriedenheit mit
den Testaktivitäten
Unzufrieden
Mittelmässig
Zufrieden
1. Testmanagement
51.0%
10.0%
39.0%
3. Testfallermittlung
38.1%
11.3%
50.6%
58.1%
6.1%
35.8%
40.1%
11.0%
2. Testplanung
41.7%
10.4%
47.9%
5
4
3
2
1
49.9%
Über alle Testaktivitäten hinweg
gesehen, ist die Bewertung eher
bescheiden. Eine „Kundenzufrie-
denheit“ von 50% und darunter
zeigt auf, dass Verbesserungsbe-
darf besteht und sich die Testmit-
arbeiter stärker auf nutzbringende
Aktivitäten fokusieren müssen.
61.9%
sind mit der Testfallermittlung
nicht zufrieden. Somit gilt dies
als die Aktivität mit der schlech-
testen Bewertung. Die notwendi-
gen Fähigkeiten scheinen in den
Unternehmen noch nicht wirklich
vorhanden zu sein.
58.1%
Testdurchführung ist die Testakt-
vität mit der besten Bewertung,
was wahrscheinlich auch damit
zu tun hat, dass fassbare Resulta-
te geliefert werden.
Testing - Trends & Benchmarks in Software Development 2014 | 39Das Missverständnis im Management
Unterschiedliche Einschätzung des Projekterfolgs
Wahrnehmung «Testen als notwendiges Übel»
Das Dilemma
Tester schätzen den Erfolg von Projekten (in Zeit, Budget und Funktionalität
beendet) deutlich positiver ein als das Management.
Tester schätzen die Wahrnehmung der Organisation bezüglich Testing
deutlich negativer ein als das Management.
39.7%
30.8%
Management Tester
10.9%
24.7%Management Tester
Einschätzung der Fähigkeiten der Testspezialisten
Vergleicht man die Antworten des Managements mit denen der Testmitar-
beitenden, so ergeben sich spannende Unterschiede in der Wahrnehmung.
Die Zahlen zeigen auf, dass das Management die Maturität und das fachliche
Wissen im Testbereich viel positiver einschätzt. Entsprechend ist in der
Führungsebene auch weniger Bereitschaft vorhanden, die (tatsächlich vor-
handenen) Missstände anzugehen und die notwendigen Investitionen zu
tätigen. Eine grosse Herausforderung stellt auch die (zu) positive Einschätzung
Sehr gut in Testmanagement
und Planung
27.8%
19.4%
Sehr gutes Methodenwissen
25.9%
15.6%
Sehr gute Kommunikation
20.8%
13.2%
n Sicht Management n Sicht Tester
Die grössten Herausforderungen
Mangelhafte oder unvoll-
ständige Anforderungen
47.3%
71.8%
Zu späte Lieferung
der Software
25.5%
57.5%
Verfügbarkeit
der Testumgebung
21.8%
37.9%
Zu späte Involvierung
der Test-Erforderungen
45.5%
51.1%
n Sicht Management n Sicht Tester
der Fähigkeiten der Testmitarbeitenden dar. So werden anspruchsvolle
Testaufgaben unbewusst an Tester zugewiesen, welche das notwendige
Wissen und die benötigte Erfahrung nicht mitbringen. Entsprechend oft
steht dann Testen in der Kritik und der Nutzen wird durch den Auftrag-
geber in Frage gestellt. Dies kann zu einer starken Reduktion des Testbudgets
oder Auflösung der Testorganisation führen. Die Testmitarbeitenden sind
somit gefordert, ihrem Management die Problembereiche und gleichzeitig
aber auch den Nutzen des Testings viel prägnanter aufzuzeigen.
Testing - Trends & Benchmarks in Software Development 2014 | 40Ein typisches Projekt
Die grössten Herausforderungen
58% Mangelhafte Anforderungen
48% Zu späte Lieferung der Software
46% Testing zu spät involviert
Testaufwand
Der durchschnittliche Testaufwand
im Verhältnis zum Gesamtprojekt-
aufwand beträgt 16 – 20%.
Developer Tester Verhältnis
Typische Developer-Tester Ratio
liegt zwischen 3:1 und 5:1.
 
3:1 <> 5:1
16-20%
Gesamt-
aufwand
Testverantwortung
Unit Tests
Systemtests
Abnahmetests
Testautomatisierung
Last & Performance Tests
84% Entwickler
52% IT Tester
48% Fachbereich Endbenutzer
56% IT Tester
52% IT Tester
Entwickler
RE / BA
IT Tester
Niemand
Fachbereich
Endbenutzer
Testing - Trends & Benchmarks in Software Development 2014 | 41Aufwand
Testaufwand im Verhältnis
zum Gesamtaufwand
Testaufwand im Verhältnis
zum Entwicklungsaufwand
n 2011 n 2012 n 2013 n 2014
0%
10%
20%
30%
bis 5% 6-10% 11-15% 16-20% 21-30% 31-50% darüber
7.0%
14.3%
22.5%
27.3%
20.6%
5.7%
Gesamt-
aufwand
Der durchschnittliche
Testaufwand im Verhältnis
zum Gesamtprojektaufwand
wird über die Jahre konstant
auf 16–20% geschätzt.
Analog wird der Testauf-
wand im Verhältnis zum
Entwicklungsaufwand im
Durchschnitt stabil auf
21–30% geschätzt.
Testaufwand im Verhältnis zum Entwicklungsaufwand
Testaufwand
21 – 30%
n 2011 n 2012 n 2013 n 2014
0%
10%
20%
30%
bis 5% 6-10% 11-15% 16-20% 21-30% 31-50% darüber
5.7%
20.3%
26.3%
27.6%
13.7%
5.1%
Testaufwand im Verhältnis zum Gesamtprojektaufwand
Testaufwand
16 – 20%
Entwicklungs-
aufwand
Testing - Trends & Benchmarks in Software Development 2014 | 42Zufriedenheit
Zufriedenheit mit Testaktivitäten
Die Testfallermittlung wird eindeutig am schlechtesten bewertet. Auch
Testplanung und Testauswertung werden eher gering geschätzt.
Angewandte Techniken
Ein Grossteil wendet Anforderungsbasiertes und/oder exploratives Testen an.
Bei den nicht-funktionalen Testarten ist vor allem das Last & Performance
Testing mit fast 50% verbreitet.
Testm
anagem
ent
Testplanung
Testfallerm
ittlung
Testdurchführung
Testausw
ertung
51.0%
41.7% 38.1%
58.1%
40.1%
48.9%55.6%
35.8%
47.9%
39.0%
10.0% 10.4% 11.3% 6.1% 11.0%
0%
20%
40%
60%
80%
100%
n Unzufrieden
n Mittelmässig
n Zufrieden
85.7%
62.2%
49.8%
47.6%
46.0%
32.1%
18.1%
17.1%
10.5%
7.6%
5.7%
5.1%
2.9%
0% 40% 60% 80%20% 100%
Anforderungsbasiertes Testen
Exploratives Testen /
Session Based Test Management
Load & Performance Testing
Risikobasiertes Testen
Black-Box Verfahren
Usability Testing
Security / Penetration Testing
TDD (Test Driven Development)
ATDD
(Acceptance Test Driven Development)
Model Based Testing
Pair Testing
BDD (Behaviour Driven Development)
Sonstiges
« Wir müssen das Safety Net unserer
Tests noch enger machen. »
Bereichsleiter, Industrie
Testing - Trends & Benchmarks in Software Development 2014 | 43Herausforderung
Die grössten Herausforderungen
( ) = Werte Umfrage 2013
Management
Attention
32%
(17%)
Tester zu spät
involviert
46%
(30%)
Auto-
matisierung
34%
(22%)
Anforderungen
mangelhaft
58%
(58%)
zu wenig
Budget/
Ressourcen
36%
(29%)
Testdaten
37%
(19%)
Zu späte
Lieferung
der SW
48%
(26%)
Testumgebung
35%
(21%)
Testing - Trends & Benchmarks in Software Development 2014 | 44Agilität
Testing im Kontext von Agilität
29.1%
also jeder Dritte glaubt
immer noch an grosse
zentrale Vorgaben.
69.3%
sehen weiter formale
Vorgaben bezüglich Do-
kumentation von Tests als
erforderlich. Entsprechend
schwer tun sich die agilen
Teams mit der Effizienz.
85.8%
sehen weiterhin Bedarf
nach Testspezifikationen
und Testfällen.
43.6%
setzen auf Embedded Testing.
Dies im Vergleich zu 50% im
Jahr 2013. In der Realität ist
Embedded Testing komplexer
als allgemein angenommen.
62.8%
glauben eher an die Berech-
tigung eines Test Managers.
Der Rest startet jedoch lang-
sam mit dem Test Master.
70.4%
sehen nicht ein, dass agile
Projekte auch mit deutlich
weniger Testaufwand aus-
kommen können.
Wir wenden Embedded Testing an
Man hat jederzeit den Überblick,
was gerade getestet wird
Jedes Team organisiert sich selbstständig
und macht Testing ein bisschen anders
Die Abnahmetests erfolgen direkt im Sprint
Die Unsicherheit der Tester ist grösser geworden,
da die Prozesse unklar sind
Die Rolle Test Manager gibt es nicht mehr
Wir arbeiten ausschliesslich mit Akzeptanzkriterien
Es gibt keine formalen Vorgaben mehr
bezüglich der Testdokumentation
Es braucht deutlich weniger Aufwand für das Testing
Es werden keine Testspezifikationen /
Testfälle mehr benötigt
Wir testen nur explorativ
18.0% 25.6%
50.9%17.5% 18.9%
40.8%14.6% 29.1%
43.6%13.7% 30.3%
50.2%21.8% 16.6%
62.8%19.5%
41.3% 42.3%
15.1% 69.3%
70.4%
85.8%
13.2% 71.2%
14.1%
25.6% 30.8%
15.5%
14.2%
0% 20% 40% 60% 80% 100%
n Absolut einverstanden n Mehrheitlich einverstanden n Nicht einverstanden n Kann ich nicht beurteilen
Testing - Trends & Benchmarks in Software Development 2014 | 45Wissen und Fähigkeiten
Fähigkeiten der Testmitarbeiter
Die Testmanager verfügen am ehesten über Anwender-, Test- und Fachwissen.
Methodenwissen und Tool-Erfahrung hingegen, schneiden am schlechtesten ab.
82%
attestieren den Testmit-
arbeiter gutes oder sehr
gutes Anwenderwissen.
Ein tolles Kompliment an
die Testspezialisten.
50.9%
Nur jeder Achte attestiert
den Testmitarbeitern sehr
gute kommunikative
Fähigkeiten. Was eigentlich
eine Schlüsselfähigkeit sein
sollte, wird zur Schlappe.
n Eher nicht n Mässig n Gut n Sehr gut
15.8%
18.7%
18.4%
21%
22.5%
25.8%
26.9%
26.6%
31.7%
53.9%
51.9%
45.8%
55.7%
51.1%
58.7%
50.0%
49.4%
46.9%
27.4%
27.1%
32.9%
19.1%
23.5%
12.3%
18.6%
16.3%
15.2%
0% 20% 40% 60% 80% 100%
Anwenderwissen
Allgemeines Testwissen
Fachwissen (des jeweiligen Bereichs)
Kollaboration
Technisches Wissen (IT)
Kommunikation
Testmanagement und -planung
Tool Erfahrung
Methodenwissen
79%
Vier von fünf Personen
schätzen das allgemeine
Testwissen als gut ein.
Nur 21% scheinen Defizite
aufzuweisen.
37.9%
Das grösste Verbesserungs-
potential liegt im metho-
dischen und konzeptio-
nellen Bereich. Über ein
Drittel sieht erheblichen
Aufholungsbedarf.
« Durch hohe Vorgaben an Prozesse und Methoden wird
der Faktor Mensch nicht mehr als wichtig erachtet.
Entsprechend negativ sind die Auswirkungen auf Motivation,
Verhalten und schnelle Wechsel der Mitarbeitenden. »
Head Testing, Versicherungen
Testing - Trends & Benchmarks in Software Development 2014 | 46Organisation
Ausbildung
Erstaunlicherweise haben ITIL und IREB Cert. Professional for Requirements
Engineering (FL) eine erhebliche Verbreitung im Testing gefunden. Agilität
scheint zur Zeit das aktuellste Thema zu sein.
0% 20% 60%40%
n Habe ich schon n Ist geplant
52.6%
37.4%
35.5%
28.5%
31.7%
24.2%
28.0%
21.6%
13.6%
6.5%
Testverantwortung
Unit Tests
87% Entwickler
51% IT Tester
56% IT Tester
52% Fachbereich / Endnutzer
52% IT Tester
Entwickler IT Tester RE / BA NiemandFachbereich
Endnutzer
Systemtests
Abnahmetests
Testautomatisierung
Last & Performance Tests
« Technisches Wissen im Testen wird
immer wichtiger werden,
zum Beispiel als Embedded Tester. »
Head Testing, Finanz & Versicherungen
Testing - Trends & Benchmarks in Software Development 2014 | 47Testmanagement
52%
HP QC / ALM ist weiter der
unangefochtene Markt-
führer. Jedoch setzen viele
Unternehmen langsam auf
verschiedene Testmanage-
ment-Tools.
+50%
Mit fast einer Verdoppelung
legt der Microsoft TFS Test
Manager stark zu. Viele
Firmen schätzen die direkte
Integration.
41%
Die Beliebtheit von Jira
zeigt sich nun auch im
Testing. Zwei von fünf Pro-
jekten setzen Jira bereits
fürs Testing ein.
Testmanagement Tools
Nachdem letztes Jahr Tricentis Tosca sich in der Liste der Tools etablieren
konnte, hat nun Jira Einzug gehalten. Obwohl nicht ein Testmanagement-
Tool im eigentlichen Sinne, wird es - dank der grossen Verbreitung in der
Entwicklung - auch im Testing vermehrt eingesetzt. Wie bis anhin kommen
oft mehrere Tools zum Einsatz (namentlich die MS Office Palette).
40%20%0%
HP QC / ALM
MS Office
(Excel, Word, Access)
Jira
Tricentis Tosca
MS TFS Test Manager
Eigene Entwicklung
Inflectra Spira
IBM
Rational Quality Manager
Bugzilla Testopia
Polarion QA / ALM
TestLink
Imbus Testbench
52%
46%
41%
15%
13%
12%
6%
5%
5%
4%
3%
1%
60%
HP QC / ALM
MS Office
Jira
Tricentis Tosca
Eigene Entwicklung
MS TFS Test Manager
40%20%0% 60%
n2012 n2013 n2014
80%
Testing - Trends & Benchmarks in Software Development 2014 | 48Testautomatisierung
Testautomatisierungs-Tools
Der Markt ist und bleibt recht stark fragmentiert. Es kommt eine grosse Zahl
verschiedener Tools zum Einsatz, darunter viele Eigenentwicklungen.
Automatisierungsgrad
Ein Grossteil (fast zwei Drittel) hat maximal 20% der fachlichen Tests auto-
matisiert. Einige wenige erreichen einen Automatisierungsgrad von über 80%.
Kosteneinsparung bei Testautomatisierung
Knapp über 50% gehen von Kosteneinsparungen bis 20% aus. Weniger als ein
Fünftel von mehr als 20%.
HP Quick Test Professional (QTP) /
Unified Functional Testing (UFT)
Eigenentwicklung
Selenium (RC/WebDriver)
xUnit (z.B. jUnit, TestNG, ...)
Tricentis Tosca
soapUI
MS TFS / Visualstudio
IBM Rational Functional Tester
(RFT)
Ranorex
FitNesse
Lisa
QF Test
Canoo Webtest
Andere
20%10%0%
30%
2%
29%
26%
24%
19%
17%
12%
8%
8%
7%
6%
5%
20%
30%
HP QTP / UFT
Eigen-
entwicklung
Tricentis Tosca
Selenium
(RC/WebDriver)
40%20%0%
n 2012 n 2013 n 2014
60%
40%
20%
0%
0-10% 11-20% 21-50% 51-80% >80%
38.0%
24.8%
19.2%
12.0%
6.0%
n 2011
n 2012
n 2013
n 2014
keine
Aussage
möglich
bis 80%bis 50%bis 20%bis 10%Kosten
gestiegen
30%
20%
10%
0%
40%
n 2012
n 2013
n 2014
12.0%
26.0%
24.8%
14.8%
2.0%
28.8%
« Wenn wir das Testen nicht vermeiden
können, dann automatisieren wir. »
Head Testing, Finanzen und Versicherungen
Testing - Trends & Benchmarks in Software Development 2014 | 49Last & Performance Test
Zufriedenheit mit Last & Performance Tests
Last & Performance Test Tools
LoadRunner von HP ist das weit verbreiteste Performance-Test-Werkzeug.
Erstaunlicherweise arbeiten jedoch auch viele Unternehmen mit Eigen-
entwicklungen. Dies erklärt eventuell, wieso Ergebnisse in diesem Bereich
oft in Frage gestellt werden.
Die grössten Herausforderungen Last & Performance
Die genannten Herausforderungen haben hohe Zustimmung erhalten. Dies
entspricht der Erfahrung aus der Praxis: Last & Performance Tests sind mit
diversen Schwierigkeiten behaftet und können oft nicht genügend durchge-
führt werden.
55.0%
47.4%
33.0%
23.9%
23.4%
19.6%
17.2%
14.4%
12.4%
0% 20% 40% 60%
Fehlende oder unklare
Anforderungen und Testziele
Zu späte/schlechte Planung von
Test und Ressourcen
Fehlendes Know-How
im Team
Unzureichende praktische
Erfahrungen
Fehlende Methodik /
Vorgehen
Keine Zeit
Fehlendes Wissen und Erfahrungen
mit jeweiligem Test-Tool
Fehlendes oder
ungeeignetes Test-Tool
Sonstiges
0%
38.3%
35.4%
17.1%
6.2%
6.2%
3.3%
2.9%
2.4%
8.1%
10% 20% 30% 40%
LoadRunner
Eigene Entwicklung
JMeter (auch BlazeMeter)
Proxy Sniffer
Visual Studio Ultimate Edition
Rational Performance Tester
Lisa
NeoLoad
Silk Performer
Sonstiges 12.4%
12.0%
3.8%
38.3%
n Sehr zufrieden
n Zufrieden
n Mittelmässig
n Unzufrieden
45.9%
Testing - Trends & Benchmarks in Software Development 2014 | 50
PRIORITY
TIME
INTRODUCTION GROWTH MATURITY DECLINE
Testing Trend Wave
Test Master
Business Driven Test Automation
Test Competence Center
Traceability
ATDD
Crowd Testing
Virtualisation
Test Infrastructure Management
Load & Performance Testing
ALM Tools
Agile Tester Certification
Soft Skills in Testing
Security Testing
Session Based Testing / SET
Interviews
Systematische
Testtechniken
ISTQB FL & AL
Continuous Integration
Mobile Testing
Embedded Testing
Scrum (but) Test Management
INTRODUCTION– Das Thema wurde erkannt
und einige Unternehmen arbeiten an ers-
ten Umsetzungen. Es ist allerdings nicht
absehbar, ob sich dieser Trend positiv
weiterentwickelt und das Testing tatsäch-
lich erheblich beeinflussen wird.
GROWTH – Das Thema wird immer mehr
anerkannt und viele Unternehmen ge-
hen darauf ein. Es entstehen die ersten
Werkzeuge und Beratungsfirmen bieten
Dienstleistungen dazu an. Mit der fehlen-
den Erfahrung bei der Umsetzung gehen
oft diverse Risiken einher.
MATURITY – Die meisten Unternehmen ar-
beiten an der Umsetzung oder haben die-
se bereits abgeschlossen. Das Wissen zu
dem Thema ist oft sehr verbreitet, wobei
häufig auch Unterarten dazu entstehen.
DECLINE – Das Thema wurde von den
meisten Unternehmen, mit Ausnahme
einzelner Nachzügler, bereits umgesetzt.
Wissen in diesen Bereichen neu aufzu-
bauen generiert oft keinen Nutzen mehr,
da dieses in Kürze obsolet wird.
Testing - Trends & Benchmarks in Software Development 2014 | 51
«Nach Jahren von Prozessen,
Methoden und Konzepten
muss Testen wieder lernen, zu liefern.»
ÜBER UNS
© by SwissQ Consulting AG | Stadthaus-Quai 15 | CH-8001 Zürich
www.SwissQ.it | info@SwissQ.it | Tel +41 43 288 88 40 | Fax +41 43 288 88 39
Twitter: @SwissQ | Facebook: swissqconsulting
SwissQ unterstützt ihre Kunden in den Themen Requirements, Testing und Agilität.
Wir stellen dabei sicher, dass die richtige Funktionalität schnell und richtig geliefert
wird. Dies durch das Bereitstellen von Expertise, Ressourcen, Assessments, Methoden
und Trainings.
Unsere Vision ist es, die Wertsteigerung in der IT durch perfektes Requirements
Engineering, professionelles Software Testing und den bewussten Einsatz von
agilen Methoden zu verbessern. Nebst der Erbringung von hochqualitativen Services,
verfolgen wir diese Vision durch die Schaffung von unabhängigen Plattformen wie
dem Swiss Testing Day, Agile Leadership Day und dem Swiss Requirements Day, die
den Wissens- und Erfahrungsaustausch ermöglichen. Ausserdem helfen wir hellen
Köpfen, ihr Wissen durch unsere Schulungen zu erweitern.

Weitere ähnliche Inhalte

Andere mochten auch

ingenieria del software
ingenieria del softwareingenieria del software
ingenieria del software
Evelio Hipuchima
 
Social Software und Web 2.0: Semantic Wikis, Social Tagging und eLearning 2.0
Social Software und Web 2.0: Semantic Wikis, Social Tagging und eLearning 2.0Social Software und Web 2.0: Semantic Wikis, Social Tagging und eLearning 2.0
Social Software und Web 2.0: Semantic Wikis, Social Tagging und eLearning 2.0
Sebastian Schaffert
 
Open Source Software im geschäftskritischen Einsatz
Open Source Software im geschäftskritischen EinsatzOpen Source Software im geschäftskritischen Einsatz
Open Source Software im geschäftskritischen Einsatz
Matthias Stürmer
 
Projektmanagement 2.0: Social Software für die Projektkommunikation
Projektmanagement 2.0: Social Software für die ProjektkommunikationProjektmanagement 2.0: Social Software für die Projektkommunikation
Projektmanagement 2.0: Social Software für die Projektkommunikation
Kommunikation-zweinull
 
Risiken von Open Source Software
Risiken von Open Source SoftwareRisiken von Open Source Software
Risiken von Open Source Software
Matthias Stürmer
 
Das Potential von freier Software (Open Source) für KMUs
Das Potential von freier Software (Open Source) für KMUsDas Potential von freier Software (Open Source) für KMUs
Das Potential von freier Software (Open Source) für KMUs
Matthias Stürmer
 
Mia-Software at MD Day 2010
Mia-Software at MD Day 2010Mia-Software at MD Day 2010
Mia-Software at MD Day 2010
fmadiot
 
Software Craftsmanship : en Pratique - AgileTour
Software Craftsmanship : en Pratique - AgileTourSoftware Craftsmanship : en Pratique - AgileTour
Software Craftsmanship : en Pratique - AgileTour
Jean-Laurent de Morlhon
 
Lean Software Development et pratiques Agiles
Lean Software Development et pratiques AgilesLean Software Development et pratiques Agiles
Lean Software Development et pratiques Agiles
Eric Le Merdy
 
Crm Software Salesboom.com Salesforce.com
Crm Software Salesboom.com Salesforce.comCrm Software Salesboom.com Salesforce.com
Crm Software Salesboom.com Salesforce.com
guest43084e
 
Planificacion De Proyectos De Software
Planificacion De Proyectos De SoftwarePlanificacion De Proyectos De Software
Planificacion De Proyectos De Software
Iván Sanchez Vera
 
Ingenieria De Software Para Dummies
Ingenieria De Software Para DummiesIngenieria De Software Para Dummies
Ingenieria De Software Para Dummies
Sorey García
 
Tecnicas de estimacion de costos de proyecto software
Tecnicas de estimacion de costos de proyecto softwareTecnicas de estimacion de costos de proyecto software
Tecnicas de estimacion de costos de proyecto software
antonio
 
Introduction au génie logiciel
Introduction au génie logicielIntroduction au génie logiciel
Introduction au génie logiciel
Mohamed Diallo
 
Calidad del producto ISO 9126
Calidad del producto ISO 9126Calidad del producto ISO 9126
Calidad del producto ISO 9126
JekittaB
 
Proyecto de tesis sobre software educativo
Proyecto de tesis sobre software educativoProyecto de tesis sobre software educativo
Proyecto de tesis sobre software educativo
Nelly Huayta Alvarez
 
Tipos de pruebas de software
Tipos de pruebas de softwareTipos de pruebas de software
Tipos de pruebas de software
Guillermo Lemus
 
LRA_presentation2011[1]
LRA_presentation2011[1]LRA_presentation2011[1]
LRA_presentation2011[1]
Nathon Chacon
 
Citizens of the World: Finding Joy through International Picture Books
Citizens of the World: Finding Joy through International Picture BooksCitizens of the World: Finding Joy through International Picture Books
Citizens of the World: Finding Joy through International Picture Books
treyveazey
 

Andere mochten auch (20)

ingenieria del software
ingenieria del softwareingenieria del software
ingenieria del software
 
Social Software und Web 2.0: Semantic Wikis, Social Tagging und eLearning 2.0
Social Software und Web 2.0: Semantic Wikis, Social Tagging und eLearning 2.0Social Software und Web 2.0: Semantic Wikis, Social Tagging und eLearning 2.0
Social Software und Web 2.0: Semantic Wikis, Social Tagging und eLearning 2.0
 
Open Source Software im geschäftskritischen Einsatz
Open Source Software im geschäftskritischen EinsatzOpen Source Software im geschäftskritischen Einsatz
Open Source Software im geschäftskritischen Einsatz
 
Projektmanagement 2.0: Social Software für die Projektkommunikation
Projektmanagement 2.0: Social Software für die ProjektkommunikationProjektmanagement 2.0: Social Software für die Projektkommunikation
Projektmanagement 2.0: Social Software für die Projektkommunikation
 
Risiken von Open Source Software
Risiken von Open Source SoftwareRisiken von Open Source Software
Risiken von Open Source Software
 
Das Potential von freier Software (Open Source) für KMUs
Das Potential von freier Software (Open Source) für KMUsDas Potential von freier Software (Open Source) für KMUs
Das Potential von freier Software (Open Source) für KMUs
 
Mia-Software at MD Day 2010
Mia-Software at MD Day 2010Mia-Software at MD Day 2010
Mia-Software at MD Day 2010
 
Software Craftsmanship : en Pratique - AgileTour
Software Craftsmanship : en Pratique - AgileTourSoftware Craftsmanship : en Pratique - AgileTour
Software Craftsmanship : en Pratique - AgileTour
 
Lean Software Development et pratiques Agiles
Lean Software Development et pratiques AgilesLean Software Development et pratiques Agiles
Lean Software Development et pratiques Agiles
 
Software Craftsmanship: En pratique
Software Craftsmanship: En pratiqueSoftware Craftsmanship: En pratique
Software Craftsmanship: En pratique
 
Crm Software Salesboom.com Salesforce.com
Crm Software Salesboom.com Salesforce.comCrm Software Salesboom.com Salesforce.com
Crm Software Salesboom.com Salesforce.com
 
Planificacion De Proyectos De Software
Planificacion De Proyectos De SoftwarePlanificacion De Proyectos De Software
Planificacion De Proyectos De Software
 
Ingenieria De Software Para Dummies
Ingenieria De Software Para DummiesIngenieria De Software Para Dummies
Ingenieria De Software Para Dummies
 
Tecnicas de estimacion de costos de proyecto software
Tecnicas de estimacion de costos de proyecto softwareTecnicas de estimacion de costos de proyecto software
Tecnicas de estimacion de costos de proyecto software
 
Introduction au génie logiciel
Introduction au génie logicielIntroduction au génie logiciel
Introduction au génie logiciel
 
Calidad del producto ISO 9126
Calidad del producto ISO 9126Calidad del producto ISO 9126
Calidad del producto ISO 9126
 
Proyecto de tesis sobre software educativo
Proyecto de tesis sobre software educativoProyecto de tesis sobre software educativo
Proyecto de tesis sobre software educativo
 
Tipos de pruebas de software
Tipos de pruebas de softwareTipos de pruebas de software
Tipos de pruebas de software
 
LRA_presentation2011[1]
LRA_presentation2011[1]LRA_presentation2011[1]
LRA_presentation2011[1]
 
Citizens of the World: Finding Joy through International Picture Books
Citizens of the World: Finding Joy through International Picture BooksCitizens of the World: Finding Joy through International Picture Books
Citizens of the World: Finding Joy through International Picture Books
 

Ähnlich wie Software Development 2014: Trends & Benchmarks in Agile, Requirements and Testing

Testing Trends und Benchmarks 2013 De
Testing Trends und Benchmarks 2013 DeTesting Trends und Benchmarks 2013 De
Testing Trends und Benchmarks 2013 De
SwissQ Consulting AG
 
Netzwoche: Trends und Hürden im Requirements Engineering
Netzwoche: Trends und Hürden im Requirements EngineeringNetzwoche: Trends und Hürden im Requirements Engineering
Netzwoche: Trends und Hürden im Requirements Engineering
SwissQ Consulting AG
 
Testing Trends und Benchmarks 2013
Testing Trends und Benchmarks 2013Testing Trends und Benchmarks 2013
Testing Trends und Benchmarks 2013
SwissQ Consulting AG
 
Netzwoche: Agil versus Wasserfall
Netzwoche: Agil versus WasserfallNetzwoche: Agil versus Wasserfall
Netzwoche: Agil versus Wasserfall
SwissQ Consulting AG
 
Agiles Lieferantenmanagement, Manage Agile 2013
Agiles Lieferantenmanagement, Manage Agile 2013Agiles Lieferantenmanagement, Manage Agile 2013
Agiles Lieferantenmanagement, Manage Agile 2013
Josef Scherer
 
Innovation ASG
Innovation ASGInnovation ASG
Innovation ASG
accenture
 
SAP Trends 2013 - die Entscheider kennen sollten ...
SAP Trends 2013 - die Entscheider kennen sollten ...SAP Trends 2013 - die Entscheider kennen sollten ...
SAP Trends 2013 - die Entscheider kennen sollten ...
IT-Onlinemagazin
 
Agile and Requirements Trends &amp; Benchmarks 2012 (Deutsch)
Agile and Requirements Trends &amp; Benchmarks 2012 (Deutsch)Agile and Requirements Trends &amp; Benchmarks 2012 (Deutsch)
Agile and Requirements Trends &amp; Benchmarks 2012 (Deutsch)
SwissQ Consulting AG
 
Framework zur agilen Reifegradmessung
Framework zur agilen ReifegradmessungFramework zur agilen Reifegradmessung
Framework zur agilen Reifegradmessung
Alexander Krieg
 
Continuous Documentation statt Endless Specification - Fokus auf die nachhalt...
Continuous Documentation statt Endless Specification - Fokus auf die nachhalt...Continuous Documentation statt Endless Specification - Fokus auf die nachhalt...
Continuous Documentation statt Endless Specification - Fokus auf die nachhalt...
HOOD Group
 
Vorstellung SAP Services
Vorstellung SAP ServicesVorstellung SAP Services
Vorstellung SAP Services
careerloft
 
Provadis Nr. 12 Oktober 2016
Provadis Nr. 12 Oktober 2016Provadis Nr. 12 Oktober 2016
Provadis Nr. 12 Oktober 2016
Natasha Senn
 
Digitale Transformation - Herausforderungen und Ansatzpunkte
Digitale Transformation - Herausforderungen und AnsatzpunkteDigitale Transformation - Herausforderungen und Ansatzpunkte
Digitale Transformation - Herausforderungen und Ansatzpunkte
Nicolas Schobinger
 
IT-Projektmanagement, Christian Thiel
IT-Projektmanagement, Christian Thiel IT-Projektmanagement, Christian Thiel
IT-Projektmanagement, Christian Thiel
IPM-FHS
 
Status quo (scaled) agile 2020
Status quo (scaled) agile 2020Status quo (scaled) agile 2020
Status quo (scaled) agile 2020
Ayelt Komus
 
Warum ein traditioneller Ausschreibungsprozess (RFP) nicht mehr zeitgemäß ist.
Warum ein traditioneller Ausschreibungsprozess (RFP) nicht mehr zeitgemäß ist.Warum ein traditioneller Ausschreibungsprozess (RFP) nicht mehr zeitgemäß ist.
Warum ein traditioneller Ausschreibungsprozess (RFP) nicht mehr zeitgemäß ist.
TechDivision GmbH
 
Projektmanagement agil, hybrid, evidenzbasiert, lean und fehlerbejahend - neu...
Projektmanagement agil, hybrid, evidenzbasiert, lean und fehlerbejahend - neu...Projektmanagement agil, hybrid, evidenzbasiert, lean und fehlerbejahend - neu...
Projektmanagement agil, hybrid, evidenzbasiert, lean und fehlerbejahend - neu...
Ayelt Komus
 
Aus Innovationen Werte schaffen | Accenture
Aus Innovationen Werte schaffen | AccentureAus Innovationen Werte schaffen | Accenture
Aus Innovationen Werte schaffen | Accenture
accenture
 
Aus Innovationen Werte schaffen | Accenture
Aus Innovationen Werte schaffen | AccentureAus Innovationen Werte schaffen | Accenture
Aus Innovationen Werte schaffen | Accenture
accenture
 

Ähnlich wie Software Development 2014: Trends & Benchmarks in Agile, Requirements and Testing (20)

Testing Trends und Benchmarks 2013 De
Testing Trends und Benchmarks 2013 DeTesting Trends und Benchmarks 2013 De
Testing Trends und Benchmarks 2013 De
 
Netzwoche: Trends und Hürden im Requirements Engineering
Netzwoche: Trends und Hürden im Requirements EngineeringNetzwoche: Trends und Hürden im Requirements Engineering
Netzwoche: Trends und Hürden im Requirements Engineering
 
Testing Trends und Benchmarks 2013
Testing Trends und Benchmarks 2013Testing Trends und Benchmarks 2013
Testing Trends und Benchmarks 2013
 
Netzwoche: Agil versus Wasserfall
Netzwoche: Agil versus WasserfallNetzwoche: Agil versus Wasserfall
Netzwoche: Agil versus Wasserfall
 
Agiles Lieferantenmanagement, Manage Agile 2013
Agiles Lieferantenmanagement, Manage Agile 2013Agiles Lieferantenmanagement, Manage Agile 2013
Agiles Lieferantenmanagement, Manage Agile 2013
 
Innovation ASG
Innovation ASGInnovation ASG
Innovation ASG
 
SAP Trends 2013 - die Entscheider kennen sollten ...
SAP Trends 2013 - die Entscheider kennen sollten ...SAP Trends 2013 - die Entscheider kennen sollten ...
SAP Trends 2013 - die Entscheider kennen sollten ...
 
YAVEON_Jahrbuch_2015
YAVEON_Jahrbuch_2015YAVEON_Jahrbuch_2015
YAVEON_Jahrbuch_2015
 
Agile and Requirements Trends &amp; Benchmarks 2012 (Deutsch)
Agile and Requirements Trends &amp; Benchmarks 2012 (Deutsch)Agile and Requirements Trends &amp; Benchmarks 2012 (Deutsch)
Agile and Requirements Trends &amp; Benchmarks 2012 (Deutsch)
 
Framework zur agilen Reifegradmessung
Framework zur agilen ReifegradmessungFramework zur agilen Reifegradmessung
Framework zur agilen Reifegradmessung
 
Continuous Documentation statt Endless Specification - Fokus auf die nachhalt...
Continuous Documentation statt Endless Specification - Fokus auf die nachhalt...Continuous Documentation statt Endless Specification - Fokus auf die nachhalt...
Continuous Documentation statt Endless Specification - Fokus auf die nachhalt...
 
Vorstellung SAP Services
Vorstellung SAP ServicesVorstellung SAP Services
Vorstellung SAP Services
 
Provadis Nr. 12 Oktober 2016
Provadis Nr. 12 Oktober 2016Provadis Nr. 12 Oktober 2016
Provadis Nr. 12 Oktober 2016
 
Digitale Transformation - Herausforderungen und Ansatzpunkte
Digitale Transformation - Herausforderungen und AnsatzpunkteDigitale Transformation - Herausforderungen und Ansatzpunkte
Digitale Transformation - Herausforderungen und Ansatzpunkte
 
IT-Projektmanagement, Christian Thiel
IT-Projektmanagement, Christian Thiel IT-Projektmanagement, Christian Thiel
IT-Projektmanagement, Christian Thiel
 
Status quo (scaled) agile 2020
Status quo (scaled) agile 2020Status quo (scaled) agile 2020
Status quo (scaled) agile 2020
 
Warum ein traditioneller Ausschreibungsprozess (RFP) nicht mehr zeitgemäß ist.
Warum ein traditioneller Ausschreibungsprozess (RFP) nicht mehr zeitgemäß ist.Warum ein traditioneller Ausschreibungsprozess (RFP) nicht mehr zeitgemäß ist.
Warum ein traditioneller Ausschreibungsprozess (RFP) nicht mehr zeitgemäß ist.
 
Projektmanagement agil, hybrid, evidenzbasiert, lean und fehlerbejahend - neu...
Projektmanagement agil, hybrid, evidenzbasiert, lean und fehlerbejahend - neu...Projektmanagement agil, hybrid, evidenzbasiert, lean und fehlerbejahend - neu...
Projektmanagement agil, hybrid, evidenzbasiert, lean und fehlerbejahend - neu...
 
Aus Innovationen Werte schaffen | Accenture
Aus Innovationen Werte schaffen | AccentureAus Innovationen Werte schaffen | Accenture
Aus Innovationen Werte schaffen | Accenture
 
Aus Innovationen Werte schaffen | Accenture
Aus Innovationen Werte schaffen | AccentureAus Innovationen Werte schaffen | Accenture
Aus Innovationen Werte schaffen | Accenture
 

Mehr von SwissQ Consulting AG

NEW: Prioritize ruthlessly: Priority Poker with Business Value Alignment
NEW: Prioritize ruthlessly: Priority Poker with Business Value AlignmentNEW: Prioritize ruthlessly: Priority Poker with Business Value Alignment
NEW: Prioritize ruthlessly: Priority Poker with Business Value Alignment
SwissQ Consulting AG
 
Prioritize ruthlessly: Priority Poker with Business Value Alignment
Prioritize ruthlessly: Priority Poker with Business Value AlignmentPrioritize ruthlessly: Priority Poker with Business Value Alignment
Prioritize ruthlessly: Priority Poker with Business Value Alignment
SwissQ Consulting AG
 
SwissQ Culture Code
SwissQ Culture CodeSwissQ Culture Code
SwissQ Culture Code
SwissQ Consulting AG
 
SwissQ Culture Desk - Intro
SwissQ Culture Desk - IntroSwissQ Culture Desk - Intro
SwissQ Culture Desk - Intro
SwissQ Consulting AG
 
SwissQ Culture Desk - Kapitel 5: Wir alle haben Freiheiten - und tragen Veran...
SwissQ Culture Desk - Kapitel 5: Wir alle haben Freiheiten - und tragen Veran...SwissQ Culture Desk - Kapitel 5: Wir alle haben Freiheiten - und tragen Veran...
SwissQ Culture Desk - Kapitel 5: Wir alle haben Freiheiten - und tragen Veran...
SwissQ Consulting AG
 
Der Test Manager ist tot - lang lebe der Test Master
Der Test Manager ist tot - lang lebe der Test MasterDer Test Manager ist tot - lang lebe der Test Master
Der Test Manager ist tot - lang lebe der Test Master
SwissQ Consulting AG
 
GTD 2013 Adrian Zwingli - Der einsame Tester
GTD 2013 Adrian Zwingli - Der einsame TesterGTD 2013 Adrian Zwingli - Der einsame Tester
GTD 2013 Adrian Zwingli - Der einsame Tester
SwissQ Consulting AG
 
GTD 2013 Stephan Wiesner - Wenn Tester Apps entwickeln
GTD 2013 Stephan Wiesner - Wenn Tester Apps entwickelnGTD 2013 Stephan Wiesner - Wenn Tester Apps entwickeln
GTD 2013 Stephan Wiesner - Wenn Tester Apps entwickeln
SwissQ Consulting AG
 
Agile Trends and Benchmarks 2013 EN
Agile Trends and Benchmarks 2013 ENAgile Trends and Benchmarks 2013 EN
Agile Trends and Benchmarks 2013 EN
SwissQ Consulting AG
 
Scrum Rocks, Testing Sucks ?! RELOADED
Scrum Rocks, Testing Sucks ?! RELOADEDScrum Rocks, Testing Sucks ?! RELOADED
Scrum Rocks, Testing Sucks ?! RELOADED
SwissQ Consulting AG
 
Scrum Rocks, Testing Sucks?! (de)
Scrum Rocks, Testing Sucks?! (de)Scrum Rocks, Testing Sucks?! (de)
Scrum Rocks, Testing Sucks?! (de)
SwissQ Consulting AG
 
Computerworld: Mehr Kommunikation, bitte! by Stephan Adler SwissQ
Computerworld: Mehr Kommunikation, bitte! by Stephan Adler SwissQComputerworld: Mehr Kommunikation, bitte! by Stephan Adler SwissQ
Computerworld: Mehr Kommunikation, bitte! by Stephan Adler SwissQ
SwissQ Consulting AG
 
Introduction Priority Poker (En)
Introduction Priority Poker (En)Introduction Priority Poker (En)
Introduction Priority Poker (En)
SwissQ Consulting AG
 
Einführung Priority Poker (De)
Einführung Priority Poker (De)Einführung Priority Poker (De)
Einführung Priority Poker (De)
SwissQ Consulting AG
 
Swiss Requirements Day 2013 - Vom Spieltrieb zur Systematik
Swiss Requirements Day 2013 - Vom Spieltrieb zur SystematikSwiss Requirements Day 2013 - Vom Spieltrieb zur Systematik
Swiss Requirements Day 2013 - Vom Spieltrieb zur Systematik
SwissQ Consulting AG
 
Netzwoche: Agile Methoden allein reichen nicht
Netzwoche: Agile Methoden allein reichen nichtNetzwoche: Agile Methoden allein reichen nicht
Netzwoche: Agile Methoden allein reichen nicht
SwissQ Consulting AG
 
SwissQ Testing Trends & Benchmarking 2011
SwissQ Testing Trends & Benchmarking 2011SwissQ Testing Trends & Benchmarking 2011
SwissQ Testing Trends & Benchmarking 2011
SwissQ Consulting AG
 
Agile Trends und Benchmarks 2013
Agile Trends und Benchmarks 2013Agile Trends und Benchmarks 2013
Agile Trends und Benchmarks 2013
SwissQ Consulting AG
 
Digital Marketing - Reduktion von technischen Risiken
Digital Marketing - Reduktion von technischen RisikenDigital Marketing - Reduktion von technischen Risiken
Digital Marketing - Reduktion von technischen Risiken
SwissQ Consulting AG
 
SwissQ Testing Trends & Benchmarks 2012 (Deutsch)
 SwissQ Testing Trends & Benchmarks 2012 (Deutsch) SwissQ Testing Trends & Benchmarks 2012 (Deutsch)
SwissQ Testing Trends & Benchmarks 2012 (Deutsch)
SwissQ Consulting AG
 

Mehr von SwissQ Consulting AG (20)

NEW: Prioritize ruthlessly: Priority Poker with Business Value Alignment
NEW: Prioritize ruthlessly: Priority Poker with Business Value AlignmentNEW: Prioritize ruthlessly: Priority Poker with Business Value Alignment
NEW: Prioritize ruthlessly: Priority Poker with Business Value Alignment
 
Prioritize ruthlessly: Priority Poker with Business Value Alignment
Prioritize ruthlessly: Priority Poker with Business Value AlignmentPrioritize ruthlessly: Priority Poker with Business Value Alignment
Prioritize ruthlessly: Priority Poker with Business Value Alignment
 
SwissQ Culture Code
SwissQ Culture CodeSwissQ Culture Code
SwissQ Culture Code
 
SwissQ Culture Desk - Intro
SwissQ Culture Desk - IntroSwissQ Culture Desk - Intro
SwissQ Culture Desk - Intro
 
SwissQ Culture Desk - Kapitel 5: Wir alle haben Freiheiten - und tragen Veran...
SwissQ Culture Desk - Kapitel 5: Wir alle haben Freiheiten - und tragen Veran...SwissQ Culture Desk - Kapitel 5: Wir alle haben Freiheiten - und tragen Veran...
SwissQ Culture Desk - Kapitel 5: Wir alle haben Freiheiten - und tragen Veran...
 
Der Test Manager ist tot - lang lebe der Test Master
Der Test Manager ist tot - lang lebe der Test MasterDer Test Manager ist tot - lang lebe der Test Master
Der Test Manager ist tot - lang lebe der Test Master
 
GTD 2013 Adrian Zwingli - Der einsame Tester
GTD 2013 Adrian Zwingli - Der einsame TesterGTD 2013 Adrian Zwingli - Der einsame Tester
GTD 2013 Adrian Zwingli - Der einsame Tester
 
GTD 2013 Stephan Wiesner - Wenn Tester Apps entwickeln
GTD 2013 Stephan Wiesner - Wenn Tester Apps entwickelnGTD 2013 Stephan Wiesner - Wenn Tester Apps entwickeln
GTD 2013 Stephan Wiesner - Wenn Tester Apps entwickeln
 
Agile Trends and Benchmarks 2013 EN
Agile Trends and Benchmarks 2013 ENAgile Trends and Benchmarks 2013 EN
Agile Trends and Benchmarks 2013 EN
 
Scrum Rocks, Testing Sucks ?! RELOADED
Scrum Rocks, Testing Sucks ?! RELOADEDScrum Rocks, Testing Sucks ?! RELOADED
Scrum Rocks, Testing Sucks ?! RELOADED
 
Scrum Rocks, Testing Sucks?! (de)
Scrum Rocks, Testing Sucks?! (de)Scrum Rocks, Testing Sucks?! (de)
Scrum Rocks, Testing Sucks?! (de)
 
Computerworld: Mehr Kommunikation, bitte! by Stephan Adler SwissQ
Computerworld: Mehr Kommunikation, bitte! by Stephan Adler SwissQComputerworld: Mehr Kommunikation, bitte! by Stephan Adler SwissQ
Computerworld: Mehr Kommunikation, bitte! by Stephan Adler SwissQ
 
Introduction Priority Poker (En)
Introduction Priority Poker (En)Introduction Priority Poker (En)
Introduction Priority Poker (En)
 
Einführung Priority Poker (De)
Einführung Priority Poker (De)Einführung Priority Poker (De)
Einführung Priority Poker (De)
 
Swiss Requirements Day 2013 - Vom Spieltrieb zur Systematik
Swiss Requirements Day 2013 - Vom Spieltrieb zur SystematikSwiss Requirements Day 2013 - Vom Spieltrieb zur Systematik
Swiss Requirements Day 2013 - Vom Spieltrieb zur Systematik
 
Netzwoche: Agile Methoden allein reichen nicht
Netzwoche: Agile Methoden allein reichen nichtNetzwoche: Agile Methoden allein reichen nicht
Netzwoche: Agile Methoden allein reichen nicht
 
SwissQ Testing Trends & Benchmarking 2011
SwissQ Testing Trends & Benchmarking 2011SwissQ Testing Trends & Benchmarking 2011
SwissQ Testing Trends & Benchmarking 2011
 
Agile Trends und Benchmarks 2013
Agile Trends und Benchmarks 2013Agile Trends und Benchmarks 2013
Agile Trends und Benchmarks 2013
 
Digital Marketing - Reduktion von technischen Risiken
Digital Marketing - Reduktion von technischen RisikenDigital Marketing - Reduktion von technischen Risiken
Digital Marketing - Reduktion von technischen Risiken
 
SwissQ Testing Trends & Benchmarks 2012 (Deutsch)
 SwissQ Testing Trends & Benchmarks 2012 (Deutsch) SwissQ Testing Trends & Benchmarks 2012 (Deutsch)
SwissQ Testing Trends & Benchmarks 2012 (Deutsch)
 

Software Development 2014: Trends & Benchmarks in Agile, Requirements and Testing

  • 1. Trends & Benchmarks Report Schweiz Wo stehen wir – wohin geht es? Software Development 2014 In Kooperation mit Agile Requirements Testing
  • 2. Trends & Benchmarks in Software Development 2014 | 2Inhaltsverzeichnis Inhalt Editorial 3 Das Richtige schnell und richtig liefern 4 Projekte 5 Vorgehen 6 Maturität 7 Ansehen 8 Investition 9 Erhebungsgrundlagen 10 Agile 11. Das Missverständnis im Management 12 Verwendung agiler Modelle 13 Wissen im Unternehmen 14 Erfahrung mit Agilität 15 Zufriedenheit 16 Agile Praktiken 17 Einführung 18 Grösste Hürden 19 Werkzeuge 20 Agile Trend Wave 21 Requirements 23. RE Prozess 24 Aufwand 25 Qualität von Anforderungen 26 Agilität 27 Erheben von Anforderungen 28 Spezifikation 29 Rollen 30 Quellen und Stakeholder 31 Mitarbeiter und Ausbildung 32 Herausforderung 33 RE Management 34 Werkzeuge 35 Requirements Trend Wave 36 Testing 37. Testprozess 38 Das Missverständnis im Management 39 Ein typisches Projekt 40 Aufwand 41 Zufriedenheit 42 Herausforderung 43 Agilität 44 Wissen und Fähigkeiten 45 Organistation 46 Testmanagement 47 Testautomatisierung 48 Last & Performance Test 49 Testing Trend Wave 50
  • 3. Trends & Benchmarks in Software Development 2014 | 3Editorial In den letzten Jahren / im letzten Jahrzehnt haben sich die Disziplinen Requirements Engineering und Testing weiterentwickelt und zunehmend professionalisiert. Vor allem im Testing hat es einen grossen Schub nach Vorne gegeben. Im Zuge dessen hat sich der Druck auf das Requirements Engineering erhöht, weil der Ursprung des viel- fach sehr hohen Testaufwandes oft bei den unge- nügenden Anforderungen zu finden ist. So gaben 58% der Teilnehmenden an der Umfrage dies als die grösste Herausforderung im Testing an. Die Erkenntnis wächst, dass man sich dieser Her- ausforderungen nur stellen kann, wenn die beiden Disziplinen nicht mehr nacheinander oder schlimmstenfalls gegeneinander arbeiten, sondern wenn sie dies miteinander tun. Zwar braucht es weiterhin Spezialisten auf dem jeweiligen Gebiet. Die weiterhin wachsende technische und fachliche Komplexität setzt voraus, dass man einen gut gefüllten Methodenrucksack hat, und diesen projektspezifisch und pragmatisch auf die jeweilige Situation anpassen kann – ohne das die Qualität darunter leidet. Die eierlegende Wollmilchsau die dies in verschiedenen Disziplinen professionell tun kann, gibt es aber nur all zu selten. Um so wichtiger ist es, dass die Requirements Engineering und Testing Experten Seit unterdessen 6 Jahren veröffentlicht SwissQ jährlich die Trends und Benchmarks Studie, mit Zahlen und Fakten zum Stand des SW Developments in der Schweiz. Was mit den Testing Trends angefangen hat, wurde später um die Themenbereiche Requi- rements und Agile ergänzt. Was bisher als separate Reports veröffentlicht wurde, haben wir in diesem Jahr zu einem vereint. Grundlage dafür bildet wie bis anhin eine Online-Umfrage an der gut 500 Personen aus unterschiedlichen Firmen, Branchen und Regionen der Schweiz teilnahmen. Zusätzlich wurden um die 25 Executive Interviews durchgeführt. Ein herzliches Dankeschön an alle, die ihre Erfahrungen und ihr Wissen geteilt haben und an unseren Kooperationspartner, das Institut für Technologiema- nagement der Universität St. Gallen (HSG). kollaborieren und interdisziplinär denken. Die anhaltende Bewegung zur Agilität, dazu zählen auch die immer vermehrter auftretenden agilen Wasserfall Hybriden, verstärkt das Zusammen- wirken der beiden Disziplinen nur noch. Als Themenführer in den Disziplinen Requirements Engineering und Testing, mit Fokus auf Agilität, tragen wir diesem Trend Rechnung und haben unsere bisher separat publizierten Trends und Benchmarks in einer Broschüre vereint. Dadurch wollen wir einen Beitrag leisten, damit die jeweils andere Disziplin ein grösseres Verständnis für die Prob- leme und Herausforderungen der anderen hat. Idealerweise können so, mit Unterstützung des übergreifend agierenden Managements, diese gemeinsam angegangen und gelöst werden. Der Report beginnt mit einem übergreifenden Teil. Danach folgen die Zahlen zu den drei Themen- bereichen Agile, Requirements und Testing. Pro Themenbereich werden einerseits die Benchmarks und andererseits die SwissQ Trend Wave® präsen- tiert. Die Benchmark Grafiken ermöglichen es, sich im Vergleich mit den anderen Unternehmen zu positionieren. Die Trend Waves hingegen zeigen auf, wie sich einzelne Trends entwickeln. Dadurch lässt sich der Einfluss der Marktveränderungen auf das eigene Unternehmen abschätzen und es können, falls notwendig, geeignete Vorhaben initiiert werden. Wir hoffen, dass die vorliegenden Trends und Bench- marks Sie dazu inspirieren, neue Herausforderungen aktiv anzugehen und die aktuell besten Massnahmen in Ihrem Unternehmen zu ergreifen.
  • 4. Trends & Benchmarks in Software Development 2014 | 4Das Richtige schnell und richtig liefern e % Doing the right things fast and right Source: Michael Drupnikov, www.TargetProcess.com Doing the right things fast and right Mehr unter: www.SwissQ.it/fastSource: Michael Drupinow, www.TargetProcess.com
  • 5. Trends & Benchmarks in Software Development 2014 | 5 Projekterfolg Der Anteil der erfolgreich beendeten Projekte hat sich nochmals leicht erhöht, andererseits ist auch der Anteil der gestoppten Projekte gestiegen. Projektart Im letzten Jahr hatte sich der Anteil der Neuentwicklung auf 25% verringert. Dies zu Gunsten von mehr Erweiterungen und Wartungsprojekten. Die Baisse ist bereits wieder überwunden. Es wird wieder vermehrt in Neues investiert. Projekte n Erweiterung einer bestehenden Lösung n Neu-Entwicklung n Migration n Betrieb, Support, Wartung, Re-Design n Einführung Standard- Software n Andere 4.2% 5.2% 7.4% 7.4% 37.5% 38.2% Projektgrösse (in CHF) 15% 10% 5% 0% über 20 Mio. 5.2% 10.8% 12.9% 9.7% n 2011 n 2012 n 2013 n 2014 bis 100‘000 bis 500‘000 bis 1 Mio. bis 5 Mio. bis 20 Mio. über 20 Mio. 20% 10% 30% 8.1% 19.4% 17.8% 27.2% 17.8% 9.7% 0% Projekt in Zeit, Budget, Funktionalität beendet Projekt im Rahmen, über Budget und/ oder Zeit Projekt verlängert/neu geplant Projekt mit grossen funkt. Änderungen Projekt gestoppt 0% 10% 20% 30% 40% 38.8% 25.6% 18.1% 12.6% 4.9% n 2011 n 2012 n 2013 n 2014
  • 6. Trends & Benchmarks in Software Development 2014 | 6Vorgehen Angewandte Vorgehensmodelle 71.1% setzen ein agiles Vorgehensmodell ein. Somit ist Agile weiter verbreitet als die anderen Modelle. Agiles Vorgehen Wasserfall- modell V-Modell Iteratives Vorgehen Hermes RUP Keines 15.8% 55.3% 45.7% 40.4% 29.7% 15.0% 14.5% 71.1% 52.3% 48.4% 31.7% 20% 4% 0% 10% 20% 30% 40% 50% 60% 70% 80% 17.5% n Alleinig n In Kombination Einhaltung der Vorgehensweise n Wird grösstenteils eingehalten n Wird teilweise eingehalten n Wird vollständig eingehalten n Wird nicht eingehalten 52.2%39.6% 3.7% 4.5% « Ehrlich gesagt, arbeiten wir noch nach Wasserfall. Einige Aspekte davon sind dann agil. Aber klar, viele nennen dies dann gerne gleich agil. » Direktor eCommerce, Handel
  • 7. Trends & Benchmarks in Software Development 2014 | 7Maturität 30.1% Reifegrad Requirements n Ausgezeichnet n Sehr gut n Gut n Mittelmässig n Schwach 12.9% 40.1% 35.3% 10.7% 1.1% 46% der Unternehmen bewerten die Reife ihrer Requirement- Aktivitäten als mittelmässig oder gar schwach. Reifegrad Testing n Ausgezeichnet n Sehr gut n Gut n Mittelmässig n Schwach 22.7% 37.0% 33.1% 6.2% 1.0% Eine deutliche Mehrheit (60.7%) bewertet die Reife des Testings als gut, sehr gut oder gar ausgezeichnet. Reifegrad Agile n Läuft alles super - keine Probleme n Erwarteter Nutzen erfüllt n Dauer - länger als erwartet n Ist kompliziert n Erfüllt die Erwartungen nicht n Übung abgebrochen 38.4% 19.9% 7.9% 1.4%2.3% Als relativ junge Disziplin tun sich die Unternehmen mit Agilität noch schwer. Bei nur 1.4% läuft es super, sprich ohne wesentliche Probleme.
  • 8. Trends & Benchmarks in Software Development 2014 | 8Ansehen Ansehen des Testens Es ist für den Erfolg der Organisation strategisch Es ist ein wichtiger Faktor, um verlässliche Software zu produzieren Es ist ein notwendiges Übel Es hat tiefe Priorität Die Kosten für Tests könnten wir uns sparen 15.9% 53.9% 23.1% 4.9% 2.3% 0% 20% 40% 60% Ansehen von RE-Tätigkeiten Es ist für den Erfolg der Organisation strategisch Es ist ein wichtiger Faktor, um verlässliche Software zu produzieren Es ist ein notwendiges Übel Es hat tiefe Priorität Die Kosten für RE könnten wir uns sparen 0% 20% 40% 60% 51.8% 19.5% 18.8% 8.1% 1.8% « Die Entwicklung der RE/BA Disziplin steht bei uns einige Jahre hinter jener des Testings. Diese wurde früher als eigene Thematik erkannt und gefördert. » Department Head, Transport und Verkehr
  • 9. Trends & Benchmarks in Software Development 2014 | 9Investition 0% Pläne bezüglich Agilität Mit 67.1% wollen zwei Drittel leicht oder signifikant in Agilität investieren. Dies ist bedeutend mehr als in den anderen Disziplinen. n Signifikant erhöhen n Leicht erhöhen n Im gleichen Umfang lassen n Reduzieren 43.5% 23.6% 30.1% 2.8% 10% 20% 30% 40% 50% 50% Pläne bezüglich Testing Fast die Hälfte will die Testaktivitäten im gleichen Umfang belassen. Gleichzeitig wollen fast so viele die Testaktivitäten leicht bis signifikant erhöhen. n Signifikant erhöhen n Leicht erhöhen n Im gleichen Umfang lassen n Reduzieren 34.1% 12.0% 48.1% 5.8% 0% 10% 20% 30% 40% Pläne bezüglich Requirement Mehr als die Hälfte will leicht oder signifikant in die RE Disziplinen investieren. Allerdings wollen fast gleich viele Unternehmen die Aktivitäten auf dem selben Stand belassen oder gar reduzieren. n Signifikant erhöhen n Leicht erhöhen n Im gleichen Umfang lassen n Reduzieren 0% 10% 20% 30% 40% 50% 41.6% 9.3% 44.2% 4.8%
  • 10. Trends & Benchmarks in Software Development 2014 | 10Erhebungsgrundlagen Wirtschaftssektor Wie bereits in den Vorjahren stellen IT Unternehmen sowie Finanzen und Versicherungen den grössten Teil der Teilnehmenden. Aufgabenbereich Viele Teilnehmende umschreiben ihre Tätigkeit mit mehr als einer Rolle. Das Spektrum der Befragten ist insgesamt sehr breit. IT-Mitarbeitende 0% 10% 20% 30% 40% IT Finanzen, Versicherungen Industrie Staatliche und staatsnahe Betriebe Transport und Verkehr MedTech Telekom Andere 32.3% 30.7% 9.1% 8.1% 6.9% 30% 2.2% 6.6% 3.9% 2001 - … 501 - 2000 251 - 500 50 - 250 11 - 50 1 -10 0% 10% 20% 30% 40% 33.9% 15.7% 12.4% 17.5% 15.4% 5.1% 30%20%10%0% Test Manager Test Engineer / Test Analyst / Tester Requirements Engineer Projektleiter Business Analyst Berater / Consultant Teamleiter Abteilungsleiter / Bereichsleiter Quality Manager / QS-Verantwortlicher SW Engineer in Test / Testautomatisierer C-Level (CEO / CIO / ...) Scrum Master Product Owner Softwareentwickler / Developer Solution/Software Architekt Product Manager Betrieb / Support Solution Designer Andere 24.4% 23.0% 19.9% 18.5% 18.5% 16.7% 16.3% 13.2% 9.1% 7.1% 6.7% 6.7% 6.7% 6.5% 4.9% 2.8% 2.2% 1.0% 2.8%
  • 12. Agile - Trends & Benchmarks in Software Development 2014 | 12Das Missverständnis im Management Das Dilemma Bei den agilen Vorgehen ergeben sich spannende Unterschiede, in der Wahrnehmung wenn man die Antworten des Managements mit den Antworten der Entwickler vergleicht (inklusive PO und Scrum Master). Die Zahlen zeigen auf, dass das Management die Verankerung der Agilität im Unternehmen und allgemein den Kenntnisstand viel positiver einschätzt. Offensichtlich unterschätzt das Management die Herausfor- derungen, welche mit der Einführung agiler Vorgehen verbunden sind. Gründe für das Scheitern agiler Methoden Externer Druck einem klassischen Vorgehen zu folgen 42.5% 28.8% Fehlende Unterstützung durch das Management 42.7% 57.7% Unpassendes Projekt 25.0% 15.4% n Sicht Management n Sicht Entwickler So sehen die Entwickler die fehlende Unterstützung durch die Führungs- kräfte auch als einer der Hauptgründe für das Scheitern. Das Management selber übrigens auch, einfach nicht im gleichen Ausmass. Ähnliche Divergenzen ergeben sich bei den Gründen die für Agilität sprechen. Inte- ressanterweise denken die Entwickler eher als die Manager, dass Agilität dazu dient, die Produktivität zu erhöhen. Das entspricht der Wahrneh- mung, dass Entwickler oft überfordert sind vom ständigen Druck Ergebnisse liefern zu müssen. Verankerung der Agilität im Unternehmen Manager schätzen die vollständige Verankerung der Agilität in der Soft- wareentwicklung positiver ein, als die Entwickler. Management Entwickler40.4% 26.4% Kenntnissstand agiler Methoden Manager überschätzen die sehr guten Kenntnisse der Softwareentwickler bezüglich agiler Methoden. Management Entwickler29.3% 18.9% Gründe für agile Methoden Produktivität erhöhen 40.5% 50.9% Zusammenspiel Business und IT verbessern 57.1% 47.2% Sichtbarkeit von Projekten erhöhen 28.6% 37.7% Entwicklungsdisziplinen verbessern n Sicht Management n Sicht Entwickler 21.4% 11.3%
  • 13. Agile - Trends & Benchmarks in Software Development 2014 | 13Verwendung agiler Modelle 41.5% der Unternehmen führen 1 - 20% der Projekte agil durch. Somit findet eine Verbreitung statt, wobei sich die Firmen zögernd an das Thema annähern. Verteilung agiler Projekte in den Unternehmen Es wird erst ein kleiner Teil der Projekte agil durchgeführt. Unternehmen wagen sich somit langsam an das Thema heran und prüfen erst, ob sich der breitere Einsatz wirklich lohnt. Wenige Unternehmen (32.8%) setzen in mehr als der Hälfte der Projekte agil Vorgehen ein. 0% 1-20% 21-50% 51-80% 81-99% 100% 20% 10% 30% 8.1% 41.5% 23.1% 16.6% 7.9% 8.3% 0% 40% 50% Anzahl agiler Projekte im Unternehmen 41.9% haben Scrum alleinig und somit in „Ur-Form“ im Ein- satz. In den gleichen Unternehmen, aber einer anderen Einheit, sind oft auch weitere Modelle wie Kanban oder Lean Development anzutreffen. Angewandte agile Vorgehensmodelle Wird der rein agile Markt betrachtet (= Unternehmen, welche agile Vor- gehensmodelle im Einsatz haben), ist Scrum der deutliche Marktführer vor Kanban. 0% 20% 40% 60% 41.9% 55.3%Scrum Kanban Lean Development SAFe Extreme Programming (XP) Feature Driven Development (FDD) ScrumBan Agile Unified Process (AgileUP) DSDM DAD 80% 100% 35.9% 97.2% 42.8% 13.8% 3.7% 16.6% 6.9% 12.4% 7.4% 0.5% 1.4% n Alleinig n In Kombination
  • 14. Agile - Trends & Benchmarks in Software Development 2014 | 14Wissen im Unternehmen Wer kennt sich mit Agilität aus? Das Wissen über agile Methoden wird in den Unternehmen als hoch ein- geschätzt. Dies im Gegensatz zu den Erfahrungen aus dem Alltag, wo oft oberflächliches Wissen anzutreffen ist. Scrum Master Product Owner Softwareentwickler / Developer Teamleiter Projektleiter Solution / Software Architekt QA / Tester Test Manager Business Analyst / Requirements Engineer Abteilungsleiter / Bereichsleiter C-Level (CEO / CIO /...) Business / Fachbereich 36.9% 36.2%23.2% 23.2% 40.8%19.6% 41.0% 22.8% 41.6%15.9% 26.5% 13.3% 15.2% 44.6% 29.5% 42.2% 22.9% 40.4% 32.4% 9.8% 37.9% 32.6% 10.3% 39.0% 31.8% 12.1% 31.3% 29.5% 25.9% 17.8% 34.2% 29.3% 16.3% 33.9% 35.3% 0% 20% 40% 60% 80% 100% n Sehr gut n Gut n Gering n Sehr gering n Weiss nicht Verankerung der Agilität im Unternehmen Agilität scheint nur in der IT ein Thema zu sein. Für die anderen Bereiche ist es nur bedingt relevant. Entsprechend tun sich viele IT-Organisationen in Zusammenarbeit mit der Fachseite oder den Kunden schwer. n Vollständig n Grösstenteils n Teilweise n Gar nicht 18.0% 38.8% 31.7% 46.4%35.6%14.0% 12.2% 39.2% 44.1% 49.5% 46.0% 58.3% 34.1% 41.5% 30.9% 12.3% 10.7% 9.0% 0% 20% 40% 60% 80% 100% In der Software- entwicklung Im IT Management Im Product Management Im IT Portfolio Management Im Fachbereich Im Betrieb « Intern arbeiten wir agil, nach aussen gemäss V-Modell, weil „agil“ beim Kunden nicht gern gehört wird » Bereichsleiter, staatsnahe Betriebe
  • 15. Agile - Trends & Benchmarks in Software Development 2014 | 15Erfahrung mit Agilität Persönlicher Kenntnisstand agiler Methoden Sehr erfahren (seit Jahren praktisch im Einsatz) Wenig erfahren (theoretisches Wissen) Erfahren (bereits erste Projekte durchgeführt) Keine Erfahrung 29.7% 48.9% 18.8% 2.6% n 2012 n 2013 n 2014 0% 10% 20% 40% Wird bisher nicht angewandt Weniger als 1 Jahr 1-2 Jahre 2-5 Jahre Mehr als 5 Jahre 20% 10% 30% 0% 40% 50% 6.6% 9.2% 26.4% 46.5% 7.4% Erfahrung der Unternehmen mit Agilität Die Unternehmen weisen meist sehr wenig Erfahrung im Umgang mit Agilität auf. Dies wird auch bestätigt durch die immer noch kleine Anzahl an agilen Projekten. « Je länger wir nun agil arbeiten, desto weniger kommunizieren die Teammitglieder miteinander. Fast wie ein Rückfall in alte Zeiten! » Head Software Development, Industrie « Unsere Prozesse und Methoden sind für Organisationen mit tausenden von IT-lern ausgelegt. Wir sind jedoch nur einige hundert. Wir müssen etwas schlankeres, flexibleres haben. » CIO, Energie
  • 16. Agile - Trends & Benchmarks in Software Development 2014 | 16Zufriedenheit Hauptgründe für das Scheitern agiler Projekte 52% Unternehmens- philosophie nicht mit agilen Werten verknüpfbar (Theorie mit Praxis nur schwer vereinbar) 49% Fehlende Erfahrung mit agilen Vorgehensmethoden43% Fehlende Unterstützung durch das Management 31% Fehlende/ ungenügende Schulung/ Coaching 26% Externer Druck weiter einem klassischen Modell zu folgen 24% Fehlende Verbindung zwischen den Organisationsein- heiten 25% Unpassendes Projekt für Einführung Zufriedenheit n Läuft alles super - keine Probleme n Erwarteter Nutzen erfüllt n Dauer länger als erwartet n Ist kompliziert n Erfüllt die Erwartungen nicht n Übung abgebrochen ( ) = Veränderung zu Umfrage 2013 30.1% (+0.8%) 38.4% (-5.2%) 19.9% (+7.9%) 7.9% (-0.7%) 1.4% (-5.0%) 2.3% (k.A.) Im Vergleich zum Vorjahr Läuft alles super - keine Probleme Erwarteter Nutzen erfüllt 0% 20% 30% 40% 10% 38.4% 1.4% 6.4% 43.6% n2013 n2014 12.0% 19.9% ist kompliziert
  • 17. Agile - Trends & Benchmarks in Software Development 2014 | 17Agile Praktiken Management Practices Daily Standup Backlog Management Sprint Review / Product Demo Burndown Chart Definition of Done Retrospektiven Release Planning Iterative Planung Taskboard Planning Poker Dedicated Product Owner Product Roadmap Velocity Chart Definition of Ready Priority Poker Work in Progress (WiP) Limits Co-Location On-Site Customer n Werte aus 2014 n Werte aus 2013 78.6% 75.0% 73.2% 65.9% 65.0% 62.7% 56.8% 54.5% 54.1% 40.5% 34.1% 30.9% 28.6% 27.7% 15.5% 15.0% 11.4% 8.6% 0% 20% 40% 60% 80% Engineering Practices Unit Testing Continuous Integration Automated Build Issue/Bug Tracker Refactoring Test Driven Development (TDD) Pair Programming Acceptance Test Driven Development (ATDD) Automated Acceptance Testing Collective Ownership Behavior Driven Development (BDD) Andere 72.3% 60.5% 54.5% 53.6% 40.5% 34.1% 29.5% 17.3% 16.8% 16.8% 6.4% 4.5% n Werte aus 2014 n Werte aus 2013 0% 20% 40% 60% 80% « Wir sehen Agilität als Werkzeugkasten, nicht als die ultimative Lösung. » Bereichsleiter, Industrie
  • 18. Agile - Trends & Benchmarks in Software Development 2014 | 18Einführung Gründe für agile Methoden Fähigkeit erhöhen, mit sich ändernden Prioritäten umzugehen Beschleunigung der Time-to-Market Zusammenarbeit zwischen Business und IT verbessern Teammoral verbessern Risiken minimieren Produktivität erhöhen Entwicklungsprozesse vereinfachen Wartbarkeit und Erweiterbarkeit von Software erhöhen Kosten reduzieren Sichtbarkeit von Projekten erhöhen Management von verteilten Teams Entwicklungs-Disziplinen verbessern 58.0% 50.9% 50.0% 41.0% 34.4% 31.1% 28.3% 25.0% 17.5% 15.1% 13.2% 8.0% 0% 20% 40% 60% 58% sehen den grössten Vorteil im einfacheren Umgang mit sich ändernden Prioritäten. 50.9% sehen in agilen Vorgehen kürzere Projektlaufzeiten und schnellere Reaktionen auf Kunden- bzw. Markt- bedürfnisse. 17.5% und damit weniger als im letzten Jahr, möchten Agilität einsetzen, um Kosten zu sparen. « Durch die Umstellung auf Agil konnten wir die Motivation und Zufriedenheit unserer Mitarbeiter steigern und dies, obwohl die Entwicklung extern durchgeführt wird. » Bereichsleiter Online, Bank & Versicherungen
  • 19. Agile - Trends & Benchmarks in Software Development 2014 | 19Grösste Hürden 0% 10% 20% 30% 40% Kontrollverlust Widerstand im Management Mangel an Dokumentation Mangel an vorbereitender Planung Kunde (intern / extern) kann nicht mithalten Projekte zu gross oder zu komplex Mangel an Vorhersehbarkeit Einhalten von regulatorischen Vorgaben (Compliance) Zu wenig Zeit für eine nachhaltige Veränderung Zu wenig Zeit für eine nachhaltige Veränderung Nicht verträglich mit Outsourcing / Offshoring Kosten Nicht skalierbar 39.2% 33.5% 32.1% 30.2% 27.8% 26.4% 22.2% 20.8% 17.9% 13.7% 13.2% 6.6% 6.1% Die grössten Hürden bei der Einführung 39.2% Kontrollverlust wird als grösste Hürde bei der Einführung von Agilität gesehen. 33.5% sehen grossen Widerstand im Management. Dies bestätigt die Aussage, dass die fehlende Unter- stützung durch das Management einer der Hauptgründe für das Scheitern agiler Projekte sei. 32.1% sehen als grosse Hürde den Mangel an Dokumentation. Dies- bezügliche (interne?) Vorgaben scheinen vielen Agilisten immer noch das Leben schwer zu machen. Über Sinn und Unsinn wird sich gut diskutieren lassen. « Es entstehen oft dort Probleme, wo Teams aufeinander treffen und Verantwortung übergeben werden muss. » Leiter Technologie, Medienbranche
  • 20. Agile - Trends & Benchmarks in Software Development 2014 | 20Werkzeuge Verwendete Tools im agilen Umfeld Atlassion JIRA / Greenhopper ist das Werkzeug mit dem grössten Marktanteil und hat das erste Mal MS Office an der Spitze abgelöst. Atlassian JIRA / Greenhopper MS Office (Word, Excel) HP QC / ALM Confluence MS Team Foundation Server Bugzilla HP Sprinter Polarion Eigene Entwicklung IBM Rational Team Concert Rally Software Development Inflectra Spira Scrumy Version One Andere 0% 20% 40% 60% 51.4% 43.6% 38.2% 27.7% 19.1% 6.8% 6.4% 6.4% 3.6% 3.2% 2.3% 1.8% 1.8% 0.5% 11.8% Die grössten Veränderungen zum Vorjahr MS Office 0% 40% Atlassian JIRA / Green- hopper HP QC / ALM MS Team Foundation Server 60% 80% 51.4% 38.2% 19.1% n2012 n2013 n2014 20% 43.6% « Alleine der übergreifende „Compile“ und die Systemintegration dauert 2 Tage. Da können wir von 2 Wochen Sprints nur träumen. » Head Software Development, staatsnahe Betriebe
  • 21. Agile - Trends & Benchmarks in Software Development 2014 | 21Agile Trend Wave INTRODUCTION GROWTH MATURITY DECLINEPRIORITY TIME Management 3.0 Soft Skill Awareness Taskboard Stand Ups User Stories Story Points Release Planning Agile Portfolio Management Agile Planning Tools Definition of Ready Embedded Test 3-4 Wochen Sprints Scrum Definition of Done SAFe Agile Transformation Wasserfall / Scrum Hybrid Kanban ATDD 2 Wochen Sprints Retrospectives Planning Poker Dedizierter PO Priorisierung und Backlog Mgmt INTRODUCTION– Das Thema wurde erkannt und einige Unternehmen arbeiten an ers- ten Umsetzungen. Es ist allerdings nicht absehbar, ob sich dieser Trend positiv weiterentwickelt und das Testing tatsäch- lich erheblich beeinflussen wird. GROWTH – Das Thema wird immer mehr anerkannt und viele Unternehmen gehen darauf ein. Es entstehen die ersten Werkzeuge und Beratungsfirmen bieten Dienstleistungen dazu an. Mit der fehlenden Erfahrung bei der Umsetzung gehen oft diverse Risiken einher. MATURITY – Die meisten Unternehmen arbeiten an der Umsetzung oder haben diese bereits abgeschlossen. Das Wissen zu dem Thema ist oft sehr verbreitet, wobei häufig auch Unterarten dazu ent- stehen. DECLINE – Das Thema wurde von den meisten Unternehmen, mit Ausnahme einzelner Nachzügler, bereits umgesetzt. Wissen in diesen Bereichen neu aufzu- bauen generiert oft keinen Nutzen mehr, da dieses in Kürze obsolet wird.
  • 22. Agile - Trends & Benchmarks in Software Development 2014 | 22 «Agilität löst die Probleme nicht, zeigt diese aber früher auf.»
  • 24. Requirements - Trends & Benchmarks in Software Development 2014 | 24RE-Prozess 4. Prüfen 5. Verwalten RE Zufriedenheit Unzufrieden Mittelmässig Zufrieden 1. Erheben 38.6% 11.8% 49.6% 3. Dokumentieren 29.4% 21.0% 49.6% 20.6% 24.3% 55.1% 21.7% 29.4% 48.9% 2. Analysieren 40.4% 13.6% 46.0% 5 4 3 2 1 61.4% der Projekte sind mit der Erhebung von Anforderun- gen mittelmässig oder gar nicht zufrieden. 70.6% sind mit dem Dokumen- tieren von Anforderun- gen unglücklich. Die oft gelobten Notationen und Werkzeuge scheinen nicht zu befriedigen. 20.6% sind mit dem Prüfen von Anforderungen nur zu- frieden. Je später eine Aktivität im RE-Prozess stattfindet, desto unzu- friedener sind die Un- ternehmen mit diesen. Unterwegs scheint die Energie und eventuell der Fokus verloren zu gehen.
  • 25. Requirements - Trends & Benchmarks in Software Development 2014 | 25Aufwand Aufwand RE im Verhältnis zum Gesamtaufwand 0% 10% 20% 30% bis 5% 6-10% 11-15% 16-20% 21-30% 31-50% darüber RE-Aufwand im Verhältnis zum Gesamtprojektaufwand 12.4% 18.2% 27.5% 15.1% 18.6% 5.8% 2.3% n2013 n2014 bis 5% 6-10% 11-15% 16-20% 21-30% 31-50% darüber RE-Aufwand im Verhältnis zum Entwicklungsaufwand 0% 10% 20% 30% Gesamt- aufwand Entwicklungs- aufwand Der durchschnittliche RE-Aufwand im Verhältnis zum Gesamtprojektaufwand wird über die Jahre konstant auf 16 – 20% geschätzt. Der RE-Aufwand im Verhältnis zum Entwick- lungsaufwand wird im Durchschnitt auf 16-20% geschätzt. RE-Aufwand 16-20% RE-Aufwand 11-15% 17.1% 8.2% 18.2% 21.6% 16.7% 13.4% 4.8% Aufwand RE im Verhältnis zum Entwicklungsaufwand
  • 26. Requirements - Trends & Benchmarks in Software Development 2014 | 26Qualität von Anforderungen Gründe für ungenügende Anforderung Massnahmen zur Qualitätsverbesserung Missverständnisse in der Kommunikation Stetig wachsende oder ändernde Anforderungen Falsche oder keine Priorisierung von Anforderungen Unvollständige/falsche Quellen (Stakeholder) als Basis für Anforderungen verwendet Zu wenig Zeit für RE vorhanden (Kosten-/Termindruck) Sprachliche Fehler: Unverständlichkeit, Missverständlichkeit, Unquantifizierbarkeit Inhaltliche Fehler: Falsche Sachverhalte, Unvollständigkeit, zu abstrakte Formulierungen Mangelhaftes Know-How Änderung der Randbedingungen (Priorisierung, Budgetierung, Marketingstrategie, etc.) Systematische Fehler: Fehlender Business Value / Nutzen für das Projekt Logische Fehler: Widersprüchlichkeit, Redundanz Machbarkeit falsch eingeschätzt Pilotbetrieb, Prototypen, Analysen, zusätzliche Know-How-Träger, etc. führen zu neuen Erkenntnissen Änderung der Stakeholder-Zusammensetzung Fehlende oder falsche Unterscheidung zwischen funktionalen und nicht-funktionalen Anforderungen 20% 40% 60%0% 52.8% 46.8% 37.5% 36.8% 35.7% 24.2% 24.2% 23.8% 20.4% 17.5% 14.5% 13.8% 7.8% 6.7% 5.2% Interne Aus- und Weiterbildung Etablierung interner Vorlagen und Normen Gezieltes Einstellen von Requirements Engineers / Business Analysten Etablierung interner Standard RE Prozesse (inkl. Rollen) Etablierung von Standard Tools Einkauf von externen Spezialisten Systematische Ausbildung nach IREB Definierte Fachlaufbahn für Require- ments Engineers / Business Analysten Systematische Ausbildung nach IIBA 0% 20% 40% 60% 80% 100% 71.5% 52.0% 55.2% 57.3% 26.6% 29.3% 31.3% 18.3% 24.0% 20.1%28.0% 28.2% 39.8% 41.3% 44.8% 50.2% 28.5% 53.6% 16.7% 14.2% 33.6% 29.3% 23.9% 31.5% 22.4% n Umgesetzt n Geplant n Nicht geplant « Unser Top-Thema 2014: Die Balance halten zwischen Planbarkeit einfordern und Flexibilität behalten. » Head of R&D, Industrie
  • 27. Requirements - Trends & Benchmarks in Software Development 2014 | 27 Requirements Engineering im Kontext von Agilität Agilität 31.5% glauben immer noch, dass ein formaler Change Request Prozess benötigt wird! Dies im Vergleich zu 40.7% im 2013. 50% sind einverstanden, dass der Umfang der Spezifikationen deutlich geringer geworden ist. 46.3% sehen keine Unsicherheit bei den BA‘s und RE‘s. Dies im Gegensatz zu den Aussagen der IT- Executives. 70.6% spezifizieren (fast) nur Anforderungen im Detail, welche dann auch umge- setzt wurden. 56.5% sehen grundsätzlich User Stories als Doku- mentationsform. Dies ist eine starke Ab- nahme zu 71.3% im 2013. 91.2% sehen den Bedarf von Requirements Engineering in agilen Projekten. Der Product Owner priorisierte das Product-Backlog regelmässig Man hat jederzeit den Überblick, was gerade implementiert wird Die Stakeholder sind stärker involviert Änderungen im (Product-)Backlog brauchen keinen formalen Change Prozess mehr Es wurden (fast) nur Anforderungen im Detail spezifiziert, welche umgesetzt wurden Jedes Team organisiert sich selbstständig und macht RE ein bisschen anders Der Umfang der Spezifikation ist deutlich geringer geworden Die Dokumentationsform ist neu in User Stories Die Unsicherheit der Business Analysten / Requirements Engineers ist grösser geworden, da die Prozesse unklar sind Es gibt keine formalen Vorgaben mehr bezüglich Dokumentation von Anforderungen Mit der Einführung des Produktes war stets auch eine saubere Dokumentation vorhanden Es braucht kein Requirements Engineering mehr 39.2% 40.6% 40.8%38.0% 15.0% 44.9%24.8% 21.5% 36.6%20.7% 31.5% 51.9%18.7% 17.8% 42.1%17.3% 28.5% 38.7% 39.2% 45.8% 34.6% 29.0% 46.3% 23.9% 62.9% 91.2% 36.8% 45.8% 15.9% 0% 20% 40% 60% 80% 100% n Voll einverstanden n Mehrheitlich einverstanden n Nicht einverstanden n Kann ich nicht beurteilen
  • 28. Requirements - Trends & Benchmarks in Software Development 2014 | 28Erheben von Anforderungen Techniken zur Erhebung von Anforderungen Verbesserungspotenzial bei Erhebung von Anforderungen Interview Analyse bestehender Systeme (System Archeology) User Stories Workshop-Techniken Prototyping Erfahrungswissen nutzen Wiederverwendung von Anforderungen Brainstorming (-Paradox) Storyboard Umfrage / Fragebogen Szenario On-Site Customer User Walkthrough Feldbeobachtung Design Workshops (JAD) Apprenticing Contextual Inquiry Perspektivenbasierte Lesen Analogietechniken 6 Hut Denken Methode 635 Osborn Checkliste Andere 75.5% 50.5% 46.3% 41.5% 34.6% 33.5% 29.8% 22.8% 19.9% 19.1% 19.1% 18.4% 18.0% 17.3% 20%0% 40% 60% 80% Vereinfachung der visuellen Kommunikation (Bsp. Visualisierung anstelle von UML Modellen) Einbezug von Fachvertretern Einbezug von IT Bereitschaft, Anforderungen während einem Kaffeegespräch zu formulieren Wechsel der Dokumentationsform während der Erhebungsphase Gruppenarbeiten mit Rollenspielen n Sehr Hoch n Hoch n Mittel n Ungeplant 20.5% 20.4% 44.4% 43.4% 25.4% 30.2% 45.9%31.6% 30.3% 38.2% 13.2% 26.5% 42.8% 25.8% 19.4% 41.1% 32.1% 20%0% 40% 60% 80% 100% « Unseren Mitarbeitenden fehlt oft der methodische Rucksack, um die Priorität der einzelnen Requirements einzufordern. » Head of R&D, Industrie
  • 29. Requirements - Trends & Benchmarks in Software Development 2014 | 29Spezifikation Techniken zur Spezifikation von Anforderungen Prosa ist immer noch die am meisten verwendete Spezifikationstechnik. Modernere Techniken holen erst langsam auf. Reviewtechniken (Inspektionen, Peer-Reviews, ...) Ableiten von Testfällen Prototypen erstellen Checklisten Modellierung Konsultationen Simulationen Toolgestützte Methoden Andere Keine 65.9% 47.8% 35.2% 21.5% 15.2% 9.3% 4.1% 4.1% 1.1% 9.3% 20%0% 40% 60% 80% Techniken zur Prüfung von Anforderunngen Natürliche Sprache (Prosa) Use Case Spezifikationen Mockups / Prototypen / Screens / UI-Design / Storyboards (Screenabläufe) Handskzizzen / Flipcharts Aktivitätsdiagramme User Stories Use Case Diagramme Glossar Datenflussdiagramme Business Rules BPMN Diagramme Szenarien beschreiben Kontextdiagramme Klassendiagramme Sequenzdiagramme Sprachschablonen Zustandsautomaten Planguage EPKs Andere 53.5% 48.3% 40.2% 35.8% 35.1% 33.9% 33.2% 22.9% 19.9% 19.6% 16.6% 14.8% 14.0% 12.9% 12.2% 6.6% 3.7% 2.6% 0.7% 3.3% 20%0% 40% 60% « Wir betrachten die Anforderungsspezifikationen erst als abgeschlossen, wenn Entwicklung und Testing beendet sind. » Bereichsleiter, Industrie
  • 30. Requirements - Trends & Benchmarks in Software Development 2014 | 30 Aufgabenträger von RE/BA Tätigkeiten Rollen Verwendete Rollenbegriffe Business Analyst Requirements Engineer Business Engineer Requirements Manager System Engineer Sonstiges 58.7% 53.1% 19.6% 12.5% 10.7% 11.4% 20%0% 40% 60% 74.7% Die Rolle des Requirements Engineers bzw. Business Analysten ist im Markt der meistgenannte Aufgabenträger von RE/BA Tätigkeiten. 74.7% 31.7% 25.3% 23.1% 21.7% 17.8% 7.8% RequirementsEngineer/ BusinessAnalyst Projektleiter Fachvertreter/Kunde ProductOwner ProductManager Entwickler Tester KeinedezidierteRolle Andere 3.9% 2.1%
  • 31. Requirements - Trends & Benchmarks in Software Development 2014 | 31Quellen und Stakeholder Anforderungsquellen Es werden oft verschiedene Quellen von Anforderungsquellen eingesetzt. Da diese oft aus dem eigenen Umfeld kommen, finden keine grossen Veränderungen statt. (welche z.B. durch externe Experten oder Lieferanten entstehen könnten). Aufwand Stakeholder-Analyse Direkte und indirekte Anwender Sponsoren und Auftraggeber Bestehendes Produkt/ Software Regulatorien und gesetzliche Bestimmungen Designer und Entwickler Berater und Experten Lieferanten 64.1% 63.3% 56.9% 40.2% 18.9% 10.3% 2.8% n kein Aufwand, die Stakeholder sind vorgegeben n Weniger als 1 Personentag n 1-5 Personentage n Mehr als 5 Personentage ( ) = Veränderung zu Umfrage 2013 23.1% (-4.1%) 31.3% (+4.6%) 32.0% (-4.4%) 13.5% (+3.8%) « Die Projektleiter geben uns oft vor, welche Stakeholder wir abholen sollen und welche nicht. Kein Wunder haben wir öfters blinde Flecken. » BA, Transport und Verkehr
  • 32. Requirements - Trends & Benchmarks in Software Development 2014 | 32Mitarbeiter und Ausbildung AusbildungFähigkeiten RE-Mitarbeiter Der Eindruck trügt. Ein Drittel der Unternehmen ist mit den Fähigkeiten der RE-Mitarbeitenden nicht zufrieden. Fachwissen ist zwar oft vorhanden, der methodische Teil leidet jedoch sehr. Tool Erfahrung Workshop-Moderation Methodenwissen Strukturierung und Vorbereitung von Workshops Dokumentation von Anforderungsspezifikationen Prozesswissen Technisches Wissen (IT) Konsensbildung Formulierung verständlicher Anforderungen Sprachliche Kommunikation Fachwissen (des jeweiligen Bereichs) IREB® Cert. Professional for Requirements Engineering (Foundation Level) ISTQB Foundation Level ITIL Projektmanagement (IPMA, PMI, ...) Certified Scrum Master Agiles Requirements Engineering Certified Product Owner CAS Requirements Engineering Qualitätsmanagement (dipl. Quality Manager, ...) MAS Business Analysis IREB® Cert. Professional for Requirements Engineering (Advanced Level Elicitation & Consolidation) IIBA CBAP (Certified Business Analysis Professional) IREB® Cert. Professional for Requirements Engineering (Advanced Level Requirements Modeling) 43.1% 34.8% 20%0% 40% 60% 39.8% 37.0% 35.5% 32.8% 32.6% 34.6% 32.9% 30.4% 32.0% 19.5% 57.3% 39.4% 44.9% 41.2% 47.8% 47.3% 49.6% 47.5% 56.2% 50.9% 61.0% 31.3% 18.4% 20%0% 40% 60% 80% 100% n Eher nicht n Mässig n Gut n  Sehr Gut n Bereits erworben n Ist geplant 80% 36.4% 28.0% 26.1% 16.3% 14.1% 14.4% 12.9%
  • 33. Requirements - Trends & Benchmarks in Software Development 2014 | 33Herausforderung Herausforderungen im RE Sicherstellung der Rückverfolgbarkeit (Traceability) Behandlung von Qualitätsanforderungen (nicht funktionalen Anforderungen) Fähigkeiten/skills des RE / BA Verwaltung von > 500 Anforderungen pro Projekt / Produkt Anforderungserhebung in verteilten Teams Nachhaltige Dokumentation von Anforderungen in agilen Projekten Anerkennung der RE/BA Tätigkeiten Abgrenzung natürlichsprachlicher Anforderungen vs. Use Cases Rückführung von Projektanforderungen in Produktanforderungen Requirements Engineering in agilen Projekten Umgang mit Usability Anforderungen Umgang mit sich steigernder Erstellung von Anforderungen in agilen Projekten Integration / Zusammenarbeit verschiedener Tools Schneiden von User Stories (Von Epics zu User Stories) Andere Erfolgsfaktoren für gutes RE 45.7% Die sozialen Fähigkeiten eines RE‘s/BA‘s ist der meist genannte Erfolgsfaktor, direkt vor dem Methoden- wissen. Leider sind diese nicht oft anzutreffen, auch wenn gerade die Kombi- nation beider gewünscht/ erwünscht ist. 10%0% 20% 30% 40% 34.0% 29.5% 28.7% 28.4% 26.9% 25.0% 18.7% 16.8% 16.8% 16.0% 14.9% 14.6% 13.1% 10.4% 4.9% Soziale Fähigkeiten des RE/BA (Kommunikation, Empathie, Konfliktmanagement, ...) Methodenwissen des RE/BA (Elicitaiton-, Dokumentations-, Reviewtechniken, ...) Modellierung der Anforderungen (z.B. mittels Use Cases) Erstellen von Abnahmekriterien Saubere Stakeholderanalyse Verwendung eines definierten RE Prozesses Branchen-Knowhow des RE/BA (Domänenwisssen, Produktwissen) Strukturierte Reviews 0% 10% 20% 30% 50%40% 45.7% 31.1% 30.3% 28.8% 28.5% 23.6% 22.8% 21.0%
  • 34. Requirements - Trends & Benchmarks in Software Development 2014 | 34 Meilensteine erreichen Vorgaben einhalten Reviews durchführen Einhalten von Prozessen Entscheidungen herbeiführen Bei neuen Erkenntnissen Vorgehen anpassen Scope aktiv führen Anforderungssteller bewusst begleiten Methodisch korrekt vorgehen Traceability konsistent halten Modelle weiterverwenden 1 Soziale Fähigkeiten des RE/BA (Kommunikation, Empathie, Konflikt-Management,...) 2 Methodenwissen des RE/BA (Elicitation-, Dokumentations-, Reviewtechniken,...) 3 Modellierung der Anforderungen (z.B. mittels Use Cases) 45.7% 31.1% 30.3% 1 Unwichtig 2 Sekundär 3 Wichtig 4 Sehr wichtig 0 3.33% 2.97% 2.88% 2.86% 2.86% 2.64% 2.61% 2.50% 2.44% 2.33% 2.21% RE Management Die RE Prioritäten in den Unternehmen In vielen Unternehmen ist es wichtiger Meilensteine zu erreichen, als das Vorgehen neuen Erkenntnissen anzupassen. « Die grosse Herausforderung besteht im Zu- sammenspiel der einzelnen Disziplinen. Einzeln geht es gut. Sobald jedoch integriert gearbeitet werden soll, wird es schwierig. » Bereichsleiter, Finanzen & Versicherungen « Wir nutzen das V-Modell als Entscheidungsmodell, nicht als Vorgehensmodell. » Bereichsleiter, Industrie Erfolgsfaktoren für gutes RE
  • 35. Requirements - Trends & Benchmarks in Software Development 2014 | 35 Tools im RE Die grössten Veränderungen zum Vorjahr 0% 20% 40% 60% 80% 100% n 2012 n 2013 n 2014 MS Office (Word, Excel) Atlassian JIRA Sparx Wiki 66.3% 28.2% 23.4% 16.1% Microsoft Office (Word, Excel) Microsoft Visio Stift und Papier Atlassian Jira Balsamiq Mockups Sparx Enterprise Architect HP QC / ALM Atlassian Confluence Wiki Polarion Requirements Microsoft Team Foundation Server (TFS) Eigene Entwicklung IBM Rational DOORS IBM Rational Requisite Pro Google Docs IBM Rational Requirements Composer Serena Requirements Manager Visure Requirements (ex IrQA) Andere 0% 20% 40% 60% 80% 41.8% 30.0% 28.2% 25.3% 23.4% 22.3% 17.9% 16.1% 9.5% 66.3% 9.2% 5.9% 4.8% 4.4% 2.6% 2.2% 2.2% 0.7% 13.9% Werkzeuge
  • 36. Requirements - Trends & Benchmarks in Software Development 2014 | 36 PRIORITY TIME INTRODUCTION GROWTH MATURITY DECLINE Requirements Trend Wave JAD Priority Poker Workshop RE Tools Prosa IREB AL Storyboards Agile RE Sprachschablonen Scrum IREB FL Backlog Management Facilitator User Stories Modelling Tools Business Value Interviews RE Competence Center Reviews Visual Facilitation BPMN UX Traceability ALM Tools Use Cases INTRODUCTION– Das Thema wurde erkannt und einige Unternehmen arbeiten an ers- ten Umsetzungen. Es ist allerdings nicht absehbar, ob sich dieser Trend positiv weiterentwickelt und das Testing tatsäch- lich erheblich beeinflussen wird. GROWTH – Das Thema wird immer mehr anerkannt und viele Unternehmen gehen darauf ein. Es entstehen die ersten Werkzeuge und Beratungsfirmen bieten Dienstleistungen dazu an. Mit der fehlenden Erfahrung bei der Umsetzung gehen oft diverse Risiken einher. MATURITY – Die meisten Unternehmen ar- beiten an der Umsetzung oder haben die- se bereits abgeschlossen. Das Wissen zu dem Thema ist oft sehr verbreitet, wobei häufig auch Unterarten dazu entstehen. DECLINE – Das Thema wurde von den meisten Unternehmen, mit Ausnahme einzelner Nachzügler, bereits umgesetzt. Wissen in diesen Bereichen neu aufzu- bauen generiert oft keinen Nutzen mehr, da dieses in Kürze obsolet wird.
  • 38. Testing - Trends & Benchmarks in Software Development 2014 | 38Testprozess 4. Testdurchführung 5. Testauswertung Zufriedenheit mit den Testaktivitäten Unzufrieden Mittelmässig Zufrieden 1. Testmanagement 51.0% 10.0% 39.0% 3. Testfallermittlung 38.1% 11.3% 50.6% 58.1% 6.1% 35.8% 40.1% 11.0% 2. Testplanung 41.7% 10.4% 47.9% 5 4 3 2 1 49.9% Über alle Testaktivitäten hinweg gesehen, ist die Bewertung eher bescheiden. Eine „Kundenzufrie- denheit“ von 50% und darunter zeigt auf, dass Verbesserungsbe- darf besteht und sich die Testmit- arbeiter stärker auf nutzbringende Aktivitäten fokusieren müssen. 61.9% sind mit der Testfallermittlung nicht zufrieden. Somit gilt dies als die Aktivität mit der schlech- testen Bewertung. Die notwendi- gen Fähigkeiten scheinen in den Unternehmen noch nicht wirklich vorhanden zu sein. 58.1% Testdurchführung ist die Testakt- vität mit der besten Bewertung, was wahrscheinlich auch damit zu tun hat, dass fassbare Resulta- te geliefert werden.
  • 39. Testing - Trends & Benchmarks in Software Development 2014 | 39Das Missverständnis im Management Unterschiedliche Einschätzung des Projekterfolgs Wahrnehmung «Testen als notwendiges Übel» Das Dilemma Tester schätzen den Erfolg von Projekten (in Zeit, Budget und Funktionalität beendet) deutlich positiver ein als das Management. Tester schätzen die Wahrnehmung der Organisation bezüglich Testing deutlich negativer ein als das Management. 39.7% 30.8% Management Tester 10.9% 24.7%Management Tester Einschätzung der Fähigkeiten der Testspezialisten Vergleicht man die Antworten des Managements mit denen der Testmitar- beitenden, so ergeben sich spannende Unterschiede in der Wahrnehmung. Die Zahlen zeigen auf, dass das Management die Maturität und das fachliche Wissen im Testbereich viel positiver einschätzt. Entsprechend ist in der Führungsebene auch weniger Bereitschaft vorhanden, die (tatsächlich vor- handenen) Missstände anzugehen und die notwendigen Investitionen zu tätigen. Eine grosse Herausforderung stellt auch die (zu) positive Einschätzung Sehr gut in Testmanagement und Planung 27.8% 19.4% Sehr gutes Methodenwissen 25.9% 15.6% Sehr gute Kommunikation 20.8% 13.2% n Sicht Management n Sicht Tester Die grössten Herausforderungen Mangelhafte oder unvoll- ständige Anforderungen 47.3% 71.8% Zu späte Lieferung der Software 25.5% 57.5% Verfügbarkeit der Testumgebung 21.8% 37.9% Zu späte Involvierung der Test-Erforderungen 45.5% 51.1% n Sicht Management n Sicht Tester der Fähigkeiten der Testmitarbeitenden dar. So werden anspruchsvolle Testaufgaben unbewusst an Tester zugewiesen, welche das notwendige Wissen und die benötigte Erfahrung nicht mitbringen. Entsprechend oft steht dann Testen in der Kritik und der Nutzen wird durch den Auftrag- geber in Frage gestellt. Dies kann zu einer starken Reduktion des Testbudgets oder Auflösung der Testorganisation führen. Die Testmitarbeitenden sind somit gefordert, ihrem Management die Problembereiche und gleichzeitig aber auch den Nutzen des Testings viel prägnanter aufzuzeigen.
  • 40. Testing - Trends & Benchmarks in Software Development 2014 | 40Ein typisches Projekt Die grössten Herausforderungen 58% Mangelhafte Anforderungen 48% Zu späte Lieferung der Software 46% Testing zu spät involviert Testaufwand Der durchschnittliche Testaufwand im Verhältnis zum Gesamtprojekt- aufwand beträgt 16 – 20%. Developer Tester Verhältnis Typische Developer-Tester Ratio liegt zwischen 3:1 und 5:1.   3:1 <> 5:1 16-20% Gesamt- aufwand Testverantwortung Unit Tests Systemtests Abnahmetests Testautomatisierung Last & Performance Tests 84% Entwickler 52% IT Tester 48% Fachbereich Endbenutzer 56% IT Tester 52% IT Tester Entwickler RE / BA IT Tester Niemand Fachbereich Endbenutzer
  • 41. Testing - Trends & Benchmarks in Software Development 2014 | 41Aufwand Testaufwand im Verhältnis zum Gesamtaufwand Testaufwand im Verhältnis zum Entwicklungsaufwand n 2011 n 2012 n 2013 n 2014 0% 10% 20% 30% bis 5% 6-10% 11-15% 16-20% 21-30% 31-50% darüber 7.0% 14.3% 22.5% 27.3% 20.6% 5.7% Gesamt- aufwand Der durchschnittliche Testaufwand im Verhältnis zum Gesamtprojektaufwand wird über die Jahre konstant auf 16–20% geschätzt. Analog wird der Testauf- wand im Verhältnis zum Entwicklungsaufwand im Durchschnitt stabil auf 21–30% geschätzt. Testaufwand im Verhältnis zum Entwicklungsaufwand Testaufwand 21 – 30% n 2011 n 2012 n 2013 n 2014 0% 10% 20% 30% bis 5% 6-10% 11-15% 16-20% 21-30% 31-50% darüber 5.7% 20.3% 26.3% 27.6% 13.7% 5.1% Testaufwand im Verhältnis zum Gesamtprojektaufwand Testaufwand 16 – 20% Entwicklungs- aufwand
  • 42. Testing - Trends & Benchmarks in Software Development 2014 | 42Zufriedenheit Zufriedenheit mit Testaktivitäten Die Testfallermittlung wird eindeutig am schlechtesten bewertet. Auch Testplanung und Testauswertung werden eher gering geschätzt. Angewandte Techniken Ein Grossteil wendet Anforderungsbasiertes und/oder exploratives Testen an. Bei den nicht-funktionalen Testarten ist vor allem das Last & Performance Testing mit fast 50% verbreitet. Testm anagem ent Testplanung Testfallerm ittlung Testdurchführung Testausw ertung 51.0% 41.7% 38.1% 58.1% 40.1% 48.9%55.6% 35.8% 47.9% 39.0% 10.0% 10.4% 11.3% 6.1% 11.0% 0% 20% 40% 60% 80% 100% n Unzufrieden n Mittelmässig n Zufrieden 85.7% 62.2% 49.8% 47.6% 46.0% 32.1% 18.1% 17.1% 10.5% 7.6% 5.7% 5.1% 2.9% 0% 40% 60% 80%20% 100% Anforderungsbasiertes Testen Exploratives Testen / Session Based Test Management Load & Performance Testing Risikobasiertes Testen Black-Box Verfahren Usability Testing Security / Penetration Testing TDD (Test Driven Development) ATDD (Acceptance Test Driven Development) Model Based Testing Pair Testing BDD (Behaviour Driven Development) Sonstiges « Wir müssen das Safety Net unserer Tests noch enger machen. » Bereichsleiter, Industrie
  • 43. Testing - Trends & Benchmarks in Software Development 2014 | 43Herausforderung Die grössten Herausforderungen ( ) = Werte Umfrage 2013 Management Attention 32% (17%) Tester zu spät involviert 46% (30%) Auto- matisierung 34% (22%) Anforderungen mangelhaft 58% (58%) zu wenig Budget/ Ressourcen 36% (29%) Testdaten 37% (19%) Zu späte Lieferung der SW 48% (26%) Testumgebung 35% (21%)
  • 44. Testing - Trends & Benchmarks in Software Development 2014 | 44Agilität Testing im Kontext von Agilität 29.1% also jeder Dritte glaubt immer noch an grosse zentrale Vorgaben. 69.3% sehen weiter formale Vorgaben bezüglich Do- kumentation von Tests als erforderlich. Entsprechend schwer tun sich die agilen Teams mit der Effizienz. 85.8% sehen weiterhin Bedarf nach Testspezifikationen und Testfällen. 43.6% setzen auf Embedded Testing. Dies im Vergleich zu 50% im Jahr 2013. In der Realität ist Embedded Testing komplexer als allgemein angenommen. 62.8% glauben eher an die Berech- tigung eines Test Managers. Der Rest startet jedoch lang- sam mit dem Test Master. 70.4% sehen nicht ein, dass agile Projekte auch mit deutlich weniger Testaufwand aus- kommen können. Wir wenden Embedded Testing an Man hat jederzeit den Überblick, was gerade getestet wird Jedes Team organisiert sich selbstständig und macht Testing ein bisschen anders Die Abnahmetests erfolgen direkt im Sprint Die Unsicherheit der Tester ist grösser geworden, da die Prozesse unklar sind Die Rolle Test Manager gibt es nicht mehr Wir arbeiten ausschliesslich mit Akzeptanzkriterien Es gibt keine formalen Vorgaben mehr bezüglich der Testdokumentation Es braucht deutlich weniger Aufwand für das Testing Es werden keine Testspezifikationen / Testfälle mehr benötigt Wir testen nur explorativ 18.0% 25.6% 50.9%17.5% 18.9% 40.8%14.6% 29.1% 43.6%13.7% 30.3% 50.2%21.8% 16.6% 62.8%19.5% 41.3% 42.3% 15.1% 69.3% 70.4% 85.8% 13.2% 71.2% 14.1% 25.6% 30.8% 15.5% 14.2% 0% 20% 40% 60% 80% 100% n Absolut einverstanden n Mehrheitlich einverstanden n Nicht einverstanden n Kann ich nicht beurteilen
  • 45. Testing - Trends & Benchmarks in Software Development 2014 | 45Wissen und Fähigkeiten Fähigkeiten der Testmitarbeiter Die Testmanager verfügen am ehesten über Anwender-, Test- und Fachwissen. Methodenwissen und Tool-Erfahrung hingegen, schneiden am schlechtesten ab. 82% attestieren den Testmit- arbeiter gutes oder sehr gutes Anwenderwissen. Ein tolles Kompliment an die Testspezialisten. 50.9% Nur jeder Achte attestiert den Testmitarbeitern sehr gute kommunikative Fähigkeiten. Was eigentlich eine Schlüsselfähigkeit sein sollte, wird zur Schlappe. n Eher nicht n Mässig n Gut n Sehr gut 15.8% 18.7% 18.4% 21% 22.5% 25.8% 26.9% 26.6% 31.7% 53.9% 51.9% 45.8% 55.7% 51.1% 58.7% 50.0% 49.4% 46.9% 27.4% 27.1% 32.9% 19.1% 23.5% 12.3% 18.6% 16.3% 15.2% 0% 20% 40% 60% 80% 100% Anwenderwissen Allgemeines Testwissen Fachwissen (des jeweiligen Bereichs) Kollaboration Technisches Wissen (IT) Kommunikation Testmanagement und -planung Tool Erfahrung Methodenwissen 79% Vier von fünf Personen schätzen das allgemeine Testwissen als gut ein. Nur 21% scheinen Defizite aufzuweisen. 37.9% Das grösste Verbesserungs- potential liegt im metho- dischen und konzeptio- nellen Bereich. Über ein Drittel sieht erheblichen Aufholungsbedarf. « Durch hohe Vorgaben an Prozesse und Methoden wird der Faktor Mensch nicht mehr als wichtig erachtet. Entsprechend negativ sind die Auswirkungen auf Motivation, Verhalten und schnelle Wechsel der Mitarbeitenden. » Head Testing, Versicherungen
  • 46. Testing - Trends & Benchmarks in Software Development 2014 | 46Organisation Ausbildung Erstaunlicherweise haben ITIL und IREB Cert. Professional for Requirements Engineering (FL) eine erhebliche Verbreitung im Testing gefunden. Agilität scheint zur Zeit das aktuellste Thema zu sein. 0% 20% 60%40% n Habe ich schon n Ist geplant 52.6% 37.4% 35.5% 28.5% 31.7% 24.2% 28.0% 21.6% 13.6% 6.5% Testverantwortung Unit Tests 87% Entwickler 51% IT Tester 56% IT Tester 52% Fachbereich / Endnutzer 52% IT Tester Entwickler IT Tester RE / BA NiemandFachbereich Endnutzer Systemtests Abnahmetests Testautomatisierung Last & Performance Tests « Technisches Wissen im Testen wird immer wichtiger werden, zum Beispiel als Embedded Tester. » Head Testing, Finanz & Versicherungen
  • 47. Testing - Trends & Benchmarks in Software Development 2014 | 47Testmanagement 52% HP QC / ALM ist weiter der unangefochtene Markt- führer. Jedoch setzen viele Unternehmen langsam auf verschiedene Testmanage- ment-Tools. +50% Mit fast einer Verdoppelung legt der Microsoft TFS Test Manager stark zu. Viele Firmen schätzen die direkte Integration. 41% Die Beliebtheit von Jira zeigt sich nun auch im Testing. Zwei von fünf Pro- jekten setzen Jira bereits fürs Testing ein. Testmanagement Tools Nachdem letztes Jahr Tricentis Tosca sich in der Liste der Tools etablieren konnte, hat nun Jira Einzug gehalten. Obwohl nicht ein Testmanagement- Tool im eigentlichen Sinne, wird es - dank der grossen Verbreitung in der Entwicklung - auch im Testing vermehrt eingesetzt. Wie bis anhin kommen oft mehrere Tools zum Einsatz (namentlich die MS Office Palette). 40%20%0% HP QC / ALM MS Office (Excel, Word, Access) Jira Tricentis Tosca MS TFS Test Manager Eigene Entwicklung Inflectra Spira IBM Rational Quality Manager Bugzilla Testopia Polarion QA / ALM TestLink Imbus Testbench 52% 46% 41% 15% 13% 12% 6% 5% 5% 4% 3% 1% 60% HP QC / ALM MS Office Jira Tricentis Tosca Eigene Entwicklung MS TFS Test Manager 40%20%0% 60% n2012 n2013 n2014 80%
  • 48. Testing - Trends & Benchmarks in Software Development 2014 | 48Testautomatisierung Testautomatisierungs-Tools Der Markt ist und bleibt recht stark fragmentiert. Es kommt eine grosse Zahl verschiedener Tools zum Einsatz, darunter viele Eigenentwicklungen. Automatisierungsgrad Ein Grossteil (fast zwei Drittel) hat maximal 20% der fachlichen Tests auto- matisiert. Einige wenige erreichen einen Automatisierungsgrad von über 80%. Kosteneinsparung bei Testautomatisierung Knapp über 50% gehen von Kosteneinsparungen bis 20% aus. Weniger als ein Fünftel von mehr als 20%. HP Quick Test Professional (QTP) / Unified Functional Testing (UFT) Eigenentwicklung Selenium (RC/WebDriver) xUnit (z.B. jUnit, TestNG, ...) Tricentis Tosca soapUI MS TFS / Visualstudio IBM Rational Functional Tester (RFT) Ranorex FitNesse Lisa QF Test Canoo Webtest Andere 20%10%0% 30% 2% 29% 26% 24% 19% 17% 12% 8% 8% 7% 6% 5% 20% 30% HP QTP / UFT Eigen- entwicklung Tricentis Tosca Selenium (RC/WebDriver) 40%20%0% n 2012 n 2013 n 2014 60% 40% 20% 0% 0-10% 11-20% 21-50% 51-80% >80% 38.0% 24.8% 19.2% 12.0% 6.0% n 2011 n 2012 n 2013 n 2014 keine Aussage möglich bis 80%bis 50%bis 20%bis 10%Kosten gestiegen 30% 20% 10% 0% 40% n 2012 n 2013 n 2014 12.0% 26.0% 24.8% 14.8% 2.0% 28.8% « Wenn wir das Testen nicht vermeiden können, dann automatisieren wir. » Head Testing, Finanzen und Versicherungen
  • 49. Testing - Trends & Benchmarks in Software Development 2014 | 49Last & Performance Test Zufriedenheit mit Last & Performance Tests Last & Performance Test Tools LoadRunner von HP ist das weit verbreiteste Performance-Test-Werkzeug. Erstaunlicherweise arbeiten jedoch auch viele Unternehmen mit Eigen- entwicklungen. Dies erklärt eventuell, wieso Ergebnisse in diesem Bereich oft in Frage gestellt werden. Die grössten Herausforderungen Last & Performance Die genannten Herausforderungen haben hohe Zustimmung erhalten. Dies entspricht der Erfahrung aus der Praxis: Last & Performance Tests sind mit diversen Schwierigkeiten behaftet und können oft nicht genügend durchge- führt werden. 55.0% 47.4% 33.0% 23.9% 23.4% 19.6% 17.2% 14.4% 12.4% 0% 20% 40% 60% Fehlende oder unklare Anforderungen und Testziele Zu späte/schlechte Planung von Test und Ressourcen Fehlendes Know-How im Team Unzureichende praktische Erfahrungen Fehlende Methodik / Vorgehen Keine Zeit Fehlendes Wissen und Erfahrungen mit jeweiligem Test-Tool Fehlendes oder ungeeignetes Test-Tool Sonstiges 0% 38.3% 35.4% 17.1% 6.2% 6.2% 3.3% 2.9% 2.4% 8.1% 10% 20% 30% 40% LoadRunner Eigene Entwicklung JMeter (auch BlazeMeter) Proxy Sniffer Visual Studio Ultimate Edition Rational Performance Tester Lisa NeoLoad Silk Performer Sonstiges 12.4% 12.0% 3.8% 38.3% n Sehr zufrieden n Zufrieden n Mittelmässig n Unzufrieden 45.9%
  • 50. Testing - Trends & Benchmarks in Software Development 2014 | 50 PRIORITY TIME INTRODUCTION GROWTH MATURITY DECLINE Testing Trend Wave Test Master Business Driven Test Automation Test Competence Center Traceability ATDD Crowd Testing Virtualisation Test Infrastructure Management Load & Performance Testing ALM Tools Agile Tester Certification Soft Skills in Testing Security Testing Session Based Testing / SET Interviews Systematische Testtechniken ISTQB FL & AL Continuous Integration Mobile Testing Embedded Testing Scrum (but) Test Management INTRODUCTION– Das Thema wurde erkannt und einige Unternehmen arbeiten an ers- ten Umsetzungen. Es ist allerdings nicht absehbar, ob sich dieser Trend positiv weiterentwickelt und das Testing tatsäch- lich erheblich beeinflussen wird. GROWTH – Das Thema wird immer mehr anerkannt und viele Unternehmen ge- hen darauf ein. Es entstehen die ersten Werkzeuge und Beratungsfirmen bieten Dienstleistungen dazu an. Mit der fehlen- den Erfahrung bei der Umsetzung gehen oft diverse Risiken einher. MATURITY – Die meisten Unternehmen ar- beiten an der Umsetzung oder haben die- se bereits abgeschlossen. Das Wissen zu dem Thema ist oft sehr verbreitet, wobei häufig auch Unterarten dazu entstehen. DECLINE – Das Thema wurde von den meisten Unternehmen, mit Ausnahme einzelner Nachzügler, bereits umgesetzt. Wissen in diesen Bereichen neu aufzu- bauen generiert oft keinen Nutzen mehr, da dieses in Kürze obsolet wird.
  • 51. Testing - Trends & Benchmarks in Software Development 2014 | 51 «Nach Jahren von Prozessen, Methoden und Konzepten muss Testen wieder lernen, zu liefern.»
  • 52. ÜBER UNS © by SwissQ Consulting AG | Stadthaus-Quai 15 | CH-8001 Zürich www.SwissQ.it | info@SwissQ.it | Tel +41 43 288 88 40 | Fax +41 43 288 88 39 Twitter: @SwissQ | Facebook: swissqconsulting SwissQ unterstützt ihre Kunden in den Themen Requirements, Testing und Agilität. Wir stellen dabei sicher, dass die richtige Funktionalität schnell und richtig geliefert wird. Dies durch das Bereitstellen von Expertise, Ressourcen, Assessments, Methoden und Trainings. Unsere Vision ist es, die Wertsteigerung in der IT durch perfektes Requirements Engineering, professionelles Software Testing und den bewussten Einsatz von agilen Methoden zu verbessern. Nebst der Erbringung von hochqualitativen Services, verfolgen wir diese Vision durch die Schaffung von unabhängigen Plattformen wie dem Swiss Testing Day, Agile Leadership Day und dem Swiss Requirements Day, die den Wissens- und Erfahrungsaustausch ermöglichen. Ausserdem helfen wir hellen Köpfen, ihr Wissen durch unsere Schulungen zu erweitern.