Report aus dem Jahr 2015

Trends & Benchmarks Report Schweiz
Wo stehen wir – wohin geht es?
Software Development 2015
in Zusammenarbeit mit
Prof. Dr. Martin Glinz,
Institut für Informatik der Universität Zürich
Agile
Requirements
Testing
2
How SwissQ Works
Mehr über den SwissQ Culture Desk unter:
www.SwissQ.it/CultureDesk
Inhaltsverzeichnis
Inhalt
Editorial4
Geleitwort5
How SwissQ Works
6
Executive Summary
7
8
Schlüsselergebnisse & Empfehlungen
Empfehlungen9
Schlüsselergebnisse10
Projekte14
Projektvorgehen15
Projekterfolg16
18
Software Entwicklung
Erhebungsgrundlagen19
20
How SwissQ Works
Agile21.
Requirements
31.
Einführung von Agilität
22
Erfolgsfaktoren23
Organisation24
Agilität im Unternehmen
25
Agile Praktiken
26
How SwissQ Works
28
Werkzeuge29
30
How SwissQ Works
Zufriedenheit32
Erfolgsfaktoren und Prioritäten
33
Aufwand
34
Erhebung von Anforderungen
35
Techniken zur Spezifikation
36
Spezifikation und Prüfung
37
Rückverfolgbarkeit (Traceability)
38
Mitarbeiter39
Werkzeuge40
Testing
41.
Zufriedenheit42
Erfolgsfaktoren und Prioritäten
43
Aufwand44
Testverfahren45
Mitarbeiter46
Testmanagement-Tools47
Testautomatisierung48
Automatisierungsgrad49
50
Last- & Performance-Test How SwissQ Works
51
3
4
Editorial
Silvio Moser
CTO SwissQ
Zum siebten Mal in Folge veröffentlicht SwissQ die
jährliche Trends und Benchmarks Studie mit Zahlen
und Fakten zum Stand des SW Developments in der
Schweiz. Der Fokus liegt weiterhin auf den Themenbereichen Agile, Requirements und Testing. Dabei zeigt
sich einmal mehr, wie eng diese Themen miteinander verzahnt sind. Grundlage für die Studie bildet wie
bis anhin eine Online-Umfrage, an der 450 Personen
von unterschiedlichen Unternehmungen, Branchen
und Regionen der Schweiz teilnahmen. Ein herzliches
Dankeschön an alle, die ihre Erfahrungen und ihr Wissen geteilt haben und an unseren Kooperationspartner, das Institut für Informatik der Universität Zürich.
Agile dominiert. So lautet eines der Schlüsselergebnisse der Studie. Zwar haben Wasserfall und Iterative
Vorgehen mit zusammen 52% Anteil, weiterhin einen
festen Platz in der SW-Entwicklung, es findet jedoch
eine starke Vermischung mit Agil statt. Dies gilt übrigens in beide Richtungen. Agile Entwicklungen werden
vermehrt mit traditionellen Vorgehen kombiniert und
finden als sogenannte hybride Modelle ihren Einsatz.
Dies geschieht aus der Erkenntnis heraus, dass die
weitverbreitetste agile Methode Scrum, wenn «bythe-Book» angewandt, sich vor allem für Teams eignet,
welche relativ isoliert ein Produkt entwickeln können.
In der Realität befasst sich jedoch ein Grossteil der Projekte mit Entwicklungen, welche starke Abhängigkeiten
untereinander haben und vielfach auch Schnittstellen
zu Legacy, ERP oder externen Systemen beinhalten. Es
besteht daher ein grosser Bedarf an Aktivitäten wie die
Releaseplanung, die Anforderungserhebung und die
schnittstellen-übergreifenden Tests der verschiedenen
Projekte, Produkte und Komponenten zu koordinieren.
Dabei wird auf die bekannten Wasserfall-orientierten
Vorgehen zurückgegriffen. Leider werden dabei oft die
Nachteile statt die Vorteile kombiniert. Die Skalierung
der Agilität ist denn auch eines der grossen Themen
in der IT und die Unternehmen müssen lernen, wie
sie auch ausserhalb der reinen SW-Entwicklung
agiler werden können. Dies geht nur mit entsprechender Unterstützung seitens des Managements, damit der
notwendige und teilweise schmerzhafte Kulturwandel
stattfinden kann. Diese beiden Punkte werden denn
auch als die grössten Erfolgsfaktoren für die Einführung
von Agil angesehen.
Im Umkehrschluss muss man sich daher auch fragen,
ob der agile Ansatz auf die jetzige Unternehmenskultur
und Mitarbeitenden passt, und die agile Transformation entsprechend angegangen und begleitet wird.
Dabei steht man oft im Clinch zwischen dem Halten
der langjährigen Mitarbeitenden, welche über grosses
Wissen und Erfahrung verfügen aber Veränderungen
naturgemäss skeptisch gegenüberstehen, und dem
Wunsch vieler Jobsuchenden, in einem agilen Umfeld
zu arbeiten. Eine Tatsache die angesichts des weiterhin
anhaltenden Fachkräftemangels nicht einfach ignoriert
werden kann.
Das Know-How der Mitarbeitenden wird auch im
Requirements Engineering/Business Analyse und
im Testing als einer der wichtigsten Erfolgsfaktoren
angesehen. Insbesondere Methoden- und Fachwissen
werden hoch gewertet und durch gute Soft Skills
ergänzt. Es ist selbstsprechend, dass es nicht unendlich viele Fachkräfte gibt, die diese Fähigkeiten in sich
vereinen.
Wenig überraschend werden als wichtigster Erfolgsfaktor im Testen gute Anforderungen angesehen. Diese
erleichtern das Erreichen einer hohen Testabdeckung
und verringern den Testaufwand, da schlechte Anforderungen sowohl die Qualität der Software wie auch
die Fehleranalyse negativ beeinflussen. Somit wächst
die Erkenntnis, dass die beiden Disziplinen enger
zusammenarbeiten müssen. Dazu ist eine frühe Involvierung der Tester angebracht, sowohl beim Review der
Anforderungen wie auch beim Erstellen der Abnahmekriterien.
Damit dieser Aufwand nicht vergebens war, sprich: die
Anforderungen zum Zeitpunkt der Implementierung
weiterhin valide sind und den Wünschen der Kunden
entsprechen, ist eine zeitnahe Umsetzung vonnöten.
Das Stichwort lautet Just-in-Time Specification. Werden
Anforderungen über Monate und Jahre, eventuell auf
verschiedene Arten - von Geschäftsprozessen, über Use
Cases zu User Stories – und verschiedenen Personen
erarbeitet, ist die Chance sehr gross, dass das
ursprüngliche Ziel aus den Augen verloren wird.
Wir hoffen, dass die vorliegenden Trends und Benchmarks Sie dazu inspirieren, sich mit den Veränderungen in der SW Entwicklung zu befassen und die daraus
entstehenden Herausforderungen aktiv anzugehen.
Geleitwort
Professor Dr. Martin Glinz
Institut für Informatik der Universität Zürich
In früheren Zeiten hatten manche Leute einen Wetterfrosch. Das war ein Laubfrosch, welcher in einem
grossen Einmachglas mit einer Leiter darin gehalten
wurde. Man glaubte, aus der Beobachtung, ob der
Frosch auf die Leiter stieg oder nicht, eine Wetterprognose ableiten zu können. Auch im Software Engineering gibt es viele Regeln und Glaubenssätze, die mangels überprüfbarer Daten den Status von Tatsachen
haben – unabhängig von ihrem tatsächlichen Wahrheitsgehalt. Die jährliche Umfrage von SwissQ trägt
dazu bei, hier Abhilfe zu schaffen: sie liefert Daten
über das, was tatsächlich in der IT Praxis geschieht.
Der vorliegende Bericht zeichnet ein aktuelles Bild des
Stands von drei Kernelementen der Softwareentwicklung: Requirements Engineering, Testen und agile Entwicklung. Man mag sich fragen, warum SwissQ gerade
diese drei Themen ausgewählt hat. Dies hat natürlich
etwas damit zu tun, dass die Kernkompetenzen von
SwissQ genau auf diesen drei Gebieten liegen. Wichtiger
jedoch ist, dass zwischen diesen Themen ein starker
Zusammenhang besteht. Insbesondere wenn wir «agil»
zur Frage nach dem Software-Entwicklungsprozess verallgemeinern, so haben wir es mit drei Schlüsselbereichen für den Projekterfolg zu tun:
Requirements Engineering ist eine unabdingbare Voraussetzung für erfolgreiche Projekte. Wer nicht weiss,
was seine Interesseneigner wollen bzw. brauchen,
kann keine erfolgreichen Systeme entwickeln. Dies gilt
notabene auch bei agiler Entwicklung: ohne Ermittlung, Validierung und Verwaltung von Anforderungen
sind weder die Erstellung noch eine systematische Evo-
lution des Produkt-Backlogs möglich. Testen ist nach
wie vor die Schlüsselaktivität zur Sicherung der Qualität
von Software. Dabei hängen Testen und Requirements
Engineering eng zusammen: Wir testen mit dem Ziel,
Fehler zu finden, d.h. Abweichungen des tatsächlichen
Systemverhaltens vom in den Anforderungen spezifizierten Verhalten. Auf der anderen Seite dienen Testfälle dazu, Anforderungen, welche nur grob spezifiziert
sind, präzise und eindeutig zu machen. Der Entwicklungsprozess schliesslich hat entscheidenden Einfluss
auf den Projekterfolg. Mit der zunehmenden Verbreitung von agiler Softwareentwicklung ist es daher mehr
als sinnvoll, auch auf diesem Gebiet Daten zu erheben.
Schaut man sich die Ergebnisse der diesjährigen Umfrage von SwissQ an, so finden sich neben in dieser
Form erwarteten Resultaten auch unerwartete und
neue Befunde. Teilweise lässt sich aus den Zahlen
auch konkreter Handlungsbedarf ableiten. Erwartete Resultate sind wertvoll, weil sie Erfahrungswissen,
welches aus punktuellen Beobachtungen, Lehrbüchern, Faustregeln, etc. stammt, empirisch belegen
und die Gültigkeit solchen Wissens damit bestätigen.
Unerwartete Resultate sind wertvoll, weil sie einerseits
Trends aufzeigen und andererseits dazu beitragen, dass
wir ungeprüft Geglaubtes in Frage stellen und kritisch
reflektieren. Die Nützlichkeit von Zahlen, welche Handlungsbedarf aufzeigen, liegt auf der Hand.
Zu den erwarteten Resultaten gehört für mich beispielsweise die Tatsache, dass der Anteil der Neuentwicklungen am gesamten Projektportfolio nur bei ca. 30 bis
40 Prozent liegt, wenn man die Zahlen der letzten
fünf Jahre betrachtet – in der aktuellen Erhebung sind
es nur noch rund 30 Prozent. Überraschend ist auf der
anderen Seite, dass die Zahl der Migrationsprojekte
sich gegenüber den Vorjahren mehr als verdoppelt
hat. Es bleibt abzuwarten, ob dies einen Trend
signalisiert oder ob es sich um einen statistischen Ausreisser handelt – auf jeden Fall sollte man diese Entwicklung auf dem Radar behalten. Für mich ebenfalls
überraschend, aber sehr erfreulich ist der kontinuierliche Anstieg der Projekte, welche von den Befragten
als erfolgreich angesehen werden. Handlungsbedarf
zeigt sich beispielsweise bei der Testautomatisierung:
Während über 60 Prozent der Befragten Kosteneinsparungen zwischen 10 und 50 Prozent erwarten, liegt der
tatsächliche Automatisierungsgrad bei der Mehrheit
aller untersuchten Projekte nur im Bereich von 0 bis
20 Prozent.
In diesem Sinne wünsche ich Ihnen, den Leserinnen
und Lesern dieses Berichts, dass die Lektüre auch
für Sie wertvolle Erkenntnisse bringt, sowohl in der
Bestätigung von Erwartetem, wie auch in der Entdeckung von Unerwartetem und Neuem.
Martin Glinz ist Professor und Direktor des Instituts für
Informatik an der Universität Zürich. Seine Forschungsinteressen umfassen insbesondere Requirements
Engineering, Modellierung und Qualität.
5
6
How SwissQ Works
Mehr über den SwissQ Culture Desk unter:
www.SwissQ.it/CultureDesk
Executive Summary
Schlüsselergebnisse
8
1
Agil dominiert
Die agilen Vorgehensmodelle wie Scrum, Kanban, SAFe und Co sind nicht nur
die gängigsten, sondern werden auch in 41% der Projekte als vorwiegendes
Modell eingesetzt. Die Wasserfall- und iterativen Modelle sind mit je 26%
erheblich abgeschlagen.
Entsprechend ist Agilität das Hauptthema in vielen IT-Organsiationen und
hat erheblichen Einfluss auf die einzelnen Disziplinen. Nach und nach
machen sich dabei auch die Auswirkungen auf die Organisationsformen und
Führungskultur bemerkbar. Gerade Führungskräfte haben öfters Mühe, ihre
Rolle in der agilen Welt zu finden, respektive alte Gewohnheiten abzulegen
und sich einen neuen Führungsstil anzueignen.
Agilität hat erhebliche Auswirkungen auf
alle IT-Disziplinen.
Viele Spezialisten realisieren langsam, wie stark sich ihr Berufsbild verändert,
dass neue Fähigkeiten gefragt sind und sie ihre Prozesse und Vorgehen
der Veränderung anpassen müssen.
Agile Projekte sind erfolgreicher.
Siehe dazu auch die Detailzahlen im Report.
Vorwiegende Vorgehensart
Agile
Wasserfall
Iterativ
Keine
41%
26%
26%
7%
Führungskräfte haben oft Mühe, ihre Rolle in
einer agilen Organisation zu finden und sperren
sich entsprechend gegen die Veränderung.
Wird in der Praxis vielmals zusammen mit
Wasserfall eingesetzt.
Dabei werden nicht immer die Vorteile der Vorgehen kombiniert.
Empfehlungen
In vielen Unternehmen wird
Agilität halbherzig gelebt.
Wo Agil drauf steht, ist oft nicht Agil
drin, obwohl die interne Wahrnehmung
anders ist.
Die Skalierung von Agilität ist
eine der grössten Herausforderungen.
Empfehlungen
▶ Keine Agilität ohne Disziplin. Lassen
Sie Agilität nicht als Deckmantel für
Chaos zu.
▶ Agilität skaliert nicht von alleine.
Schaffen Sie aktiv die Rahmenbedingungen.
▶ Agil ist nicht gleich agil. «Scrum by
▶ «Culture eats strategy for breakfast».
Beachten Sie Unternehmens- und
Teamkultur sowie Ihre Mitarbeiter. ▶ Agilität muss auf verschiedenen
▶ Agilität löst keine Probleme, fördert
diese jedoch zu Tage. Gehen Sie
diese an.
the book» funktioniert selten.
Agilität im einzelnen Team ist oft
nicht die grosse Sache.
74.2% erhöhen Ihre
Investitionen in Agilität.
Ebenen des Unternehmens stattfinden.
Nur 1% möchte ihre
Ausgaben reduzieren.
▶ Führungskräfte: Werden Sie vom
Manager zum Leader.
Der Einfluss der Agilität auf die
Organisation als Ganzes wird
unterschätzt.
Der notwendige Paradigmen- und
Kulturwandel findet nicht statt.
http://www.scaledagileframework.com
9
10
Schlüsselergebnisse
2
Komplexität
reduziert Erfolg
Projekterfolg
nach
Komplexität
80.0%
80%
60.3%
60%
48.8%
44.7%
40%
Je grösser die Komplexität eines Projektes ist, desto geringer sind seine
Erfolgsaussichten. (Unnötige) Komplexität entsteht dabei nicht nur auf
technischer Ebene, sondern auch aus komplizierten Organisationsformen,
Outsourcing, verteilte Teams, Kultur- und Sprachunterschiede etc.
20%
Statt die Komplexität proaktiv anzugehen, wird die Auseinandersetzung mit
dieser in die Integrations- und Testphase verschoben. «Überraschenderweise»
tauchen dann in technischen und organisationsbezogenen Schnittstellen
Probleme auf, die für Rot-Meldungen im Projektstatus sorgen.
0%
Geringe
Komplexität
Mittlere
Komplexität
Grosse
Komplexität
Sehr grosse
Komplexität
Anteil erfolgreicher Projekte
(in Zeit, in Budget und in Scope)
Grosse Vorhaben sind oft auch Status-Symbole
der Führungskräfte. Fragt sich zu welchem Preis?
Empfehlungen
Eine Führungsfrage
Lieber kleine Vorhaben
Wenn gross, dann agil
Es ist Aufgabe der Führungskräfte die
Komplexität in ihren Projekten bewusst zu
reduzieren, und ihre Mitarbeiter aufzufordern,
täglich Komplexität zu mindern, statt diese noch
zu erhöhen. Beliebte Beispiele sind neue Tools,
neue Prozesse, Outsoucing / Offshoring etc.
Während es verlockend ist, Projekte zu bündeln,
mindert dies die Erfolgsaussichten erheblich.
Lieber nicht alles auf ein Mal, sondern Stein
um Stein abtragen. Dafür muss jedoch ein
Umdenken in den Organisationen stattfinden.
Können Projekte nicht verkleinert werden,
kann Agilität durch kurze Inkremente helfen
auf neue Erkenntnisse zu reagieren, Unnötiges
zu entfernen und geänderte Businessanforderungen zu berücksichtigen.
Schlüsselergebnisse
3
RE sucht seinen
Platz
60%
Investitionen
im RE
●
●
2015
2014
40%
34.0%
20%
RE war auf einem guten Weg sich mittels Rollen, Methoden und Prozesse zu
etablieren. Heute verändert die Agilität disruptiv den Kontext und fordert ein
erhebliches Umdenken. Nicht Wenige sehen bei agilen Vorgehen kein Platz für
dedizierte RE/BA-Rollen. Der Product Owner kann das ja alles im Alleingang
erledigen.
Die Suche nach einem Platz in der IT-Organisation geht für RE von Vorne los.
Der Schlüssel liegt neu mehr in Themen wie Kommmunikation, StakeholderAnalyse etc., und weniger auf Prozess- und tiefem Methodenwissen (wobei
Letzteres durchaus mitgenommen werden dürfte).
53.5%
9.0%
3.5%
0%
Reduzieren
Im gleichen
Umfang lassen
Leicht
erhöhen
Signifikant
erhöhen
RE wird zwar als wichtige Disziplin anerkannt,
doch Wenige geben ihr die Zeit, ihren Wert zu
entfalten.
Empfehlungen
Less is more
Soft Skills, bitte
Just in Time
RE-Aktivitäten sterben oft in Schönheit. Mal
ein Modell oder eine Methode weniger, oder
weniger perfekt verwenden, geht auch.
Das Methoden-Wissen hat sich dank Fachhochschulen und IREB gut etabliert. Doch bei vielen
Spezialisten mangelt es an der weichen Seite:
Kommunikation, Moderationsfähigkeiten, Verhandlungsgeschick, Einfühlungsvermögen etc.
Zur rechten Zeit die Analysen und Spezifikationen
in der jeweils notwendigen Informationstiefe zur
Hand haben. Alles über eine Stange zu brechen ist
vorbei. Vertraut dem Können und dem gesunden
Menschenverstand der Spezialisten (so fern sie die
beiden vorhergehenden Punkte einhalten).
11
Schlüsselergebnisse
12
4
Testen löst sich vom
traditionellen Ansatz
Nach Jahren des Aufbaus von zentralen Testorganisationen und der damit
einhergehenden Professionalisierung kommt nun die Gegenbewegung.
Nicht nur die Agilität fordert wieder eine engere Zusammenarbeit mit der
Entwicklung und ein Ende des reinen Meilenstein- / Teststufen-Denkens,
sondern auch Wasserfall-orientierte wünschen dies.
Testabteilungen sind auf dem Weg, sich wieder enger zu integrieren. Dies mit
dem Ziel, Fehler endlich so früh wie möglich zu finden und späte Teststufen
für ihren wirklichen Zweck nutzen zu können.
Testautomatisierung verbessert sich langsam,
aber stetig.
Der durchschnittliche Anteil von automatisierten Tests steigt auf 31.3%
(Systemtest) .
Fehler werden immer noch zu spät gefunden.
End-2-End Tests werden als wirkungsvollste Tests angesehen.
Empfehlungen
T-Shaped Tester
Projekte
suchen
sogenannte
«T-Shaped
Tester»: Tiefgehendes Testwissen, gepaart mit
der Fähigkeit über viele Disziplinen hinweg
zusammenzuarbeiten (= auf horizontaler Ebene
breit aufgestellt zu sein). Entsprechend müssen
Testorganisationen ihr Skill-Portfolio erheblich
überabreiten und ergänzen.
Mensch vor Prozessen
und Tools
Durch die stärkere Integration des Testings steigt
die Wichtigkeit des Faktor «Mensch». Nicht
alles kann und soll durch Prozesse und Tools
definiert sein. Vertrauen in die Fähigkeiten
des Spezialisten resultiert oft in besseren
Ergebnissen, im Fall von Testing, in höherem
Projekterfolg.
Wertbeitrag erhöhen
Später Fehlerfindung kann nur durch Integration
in RE und SW-Entwicklung begegnet werden.
Früh dabei sein, «Shift Left» im Team leben.
Entsprechend steigt auch der Wertbeitrag.
Widerspricht jedoch der oft propagierten
Separation und Industrialisierung der IT.
Schlüsselergebnisse
5
Leichtgewichtige
Tools
Die leichtgewichtigen Werkzeuge sind stark im Kommen, oder haben wie im
Fall von Jira bereits die Marktführerschaft übernommen.
Getrieben durch die Spezialisierung der IT-Rollen, kamen in der Vergangenheit
Spezialwerkzeuge wie HP QC / ALM oder IBM Rational zum Einsatz. Diese waren
sehr mächtig und entsprechend schwer Hand zu haben. Die Wende zur Agilität
und die damit einhergehende starke Integration der Disziplinen fordert nun
einfachere, leichtere Werkzeuge, die durch Alle eingesetzt werden können.
Dies auf Kosten der fachlichen Tiefe.
Jira ist neu in allen 3 Bereichen das führende Tool.
Agile: 65%
RE: 44%
Testing: 45%
HP QC / ALM kann Marktanteile halten.
Einzig im agilen Bereich verlieren sie etwas. Ihre Antwort mit dem Agile
Manager steht jedoch bereit.
Empfehlungen
Abstriche in Kauf nehmen
Neue übergreifende Tool-Strategie
Die leichtgewichtigen Werkzeuge bieten oft einen Grundbaustein für die
Zusammenarbeit über die verschiedenen Rollen hinweg. Dies auf Kosten der
fachlichen Tiefe. Soll integriert gearbeitet werden, so muss man Abstriche
in der fachlichen Tiefe der Werkzeuge in Kauf nehmen. Entweder horizontal
im Team integriert oder fachlich tief isoliert.
Leichgewichtige Werkzeuge kommen oft auf Teamebene vor. Sollen diese
dann übergreifend eingesetzt werden, so fehlen oft die Sichten auf
Grossprojekte, Programme, Portfolios oder ganze Entwicklungseinheiten.
Eine neue, teamübergreifende Toolstrategie kann helfen, die
Organisationsbedürfnisse zu erkennen und einzubringen. Viele einfache
Werkzeuge haben dann oft Mühe, diese Anforderungen abzudecken. Ziel
sollten Werkzeuge sein, die den einzelnen Teams ihre Flexibilität und
Leichtigkeit lassen, übergreifend aber trotzdem Organisationen abbilden
können.
13
14
Projekte
Projektart
Projektkomplexität
Während der Anteil der Neuentwicklungen seit 2014 leicht zurückgegangen ist, sind die Migrationsprojekte von 7.4% auf 23.1% explodiert.
In mehr als der Hälfte der Projekte wird die Komplexität als gross oder
sehr gross angesehen. Komplexität ergibt sich aus der Anzahl Anforderungen, technischer und/oder organisatorischer Schnittstellen, anhand
des Prozesses, der Technologie, etc.
2.6%
1.6%
4.7%
20%
1.6%
2.4%
36.7%
30.4%
23.1%
●
●
●
●
●
●
●
Neu-Entwicklung
Erweiterung einer
bestehenden Lösung
●
●
●
●
Geringe Komplexität
Mittlere Komplexität
Grosse Komplexität
Sehr grosse Komplexität
38.6%
Migration
Proof of Concept,
Prototyp
Betrieb, Support,
Wartung
Einführung
Standard-Software
Andere
38.4%
Projektgrösse (in CHF)
Fast 80% der Projekte sind in der Grössenordnung bis zu 5 Mio. CHF
angesiedelt.
28.0%
30%
24.0%
17.9%
20%
Keep it SMALL
Auch kleine Projekte können komplex sein,
grosse Projekte sind aber nahezu immer komplex.
Die Projektart scheint dabei übrigens keine
grosse Rolle zu spielen.
11.5%
10%
0%
10.4%
8.2%
bis 100’000
bis 500'000
bis 1 Mio.
bis 5 Mio.
bis 20 Mio.
über 20 Mio.
Projektvorgehen
Vorwiegendes Vorgehen im Projekt
26% Iterativ
Agil
Das weitaus am meisten verwendete agile Vorgehensmodell ist Scrum.
Erst mit grossem Abstand folgt Kanban. Scrum wird teilweise mit
Wasserfall oder Hermes kombiniert.
41% Agile
26% Wasserfall
7% Unklar
48.1%
39.3%
Scrum
Wasserfall
48.6%
31.5%
Wasserfall
80.1%
●
●
●
Alleinig
in Kombination
Total
Wasserfall
16.6%
Hermes 5
10.3%
SAFe
6.3%
Andere
12.6%
9.9%
22.5%
Hermes 5
9.1%
9.8%
18.9%
Kanban
Die meisten Wasserfall-Projekte folgen keinem Standard-Vorgehen, meist
handelt es sich um um firmen- oder projektspezifische Phasenmodelle.
Sowohl Wasserfall- wie auch Hermes-Projekte werden teilweise mit
Scrum kombiniert.
5.7%
1.1%
4.0%
5.1%
Agile UP
Scrum
19.8%
ScrumBan
0.9%
6.3%
7.2%
RUP
87.4%
5.1%
XP
5.1%
Kanban
4.5%
Andere
RUP
DSDM
5.3%
0%
20%
3.4%
40%
60%
80%
100%
1.1%
0%
20%
40%
60%
80%
100%
●
●
●
Alleinig
in Kombination
Total
15
16
Projekterfolg
Projekterfolg über die Jahre
Projekterfolg nach Vorgehen
Über die letzten 5 Jahre hinweg hat sich der Anteil der Projekte, die als
erfolgreich abgeschlossen angesehen werden, stetig erhöht.
Ein agiles Vorgehen erhöht die Chancen auf ein erfolgreiches Projekt.
● Projekt erfolgreich ● Projekt challenged ● Projekt abgebrochen/gestoppt
60%
53.6%
Agil
58.9%
Iterativ
38.8%
40%
35.1%
55.6%
Wasserfall
36.3%
40.0%
51.4%
0%
20%
40%
60%
1.1%
40.7%
3.7%
46.9%
1.8%
80%
100%
Anteil erfolgreicher Projekte (in Zeit, in Budget und in Scope)
23.7%
20%
0%
2011
2012
2013
2014
2015
Anteil erfolgreicher Projekte
(in Zeit, in Budget und in Scope)
Wer AGIL ist hat mehr ERFOLG
Projekte sind erfolgreicher,
wenn sie agil durchgeführt werden.
Projekterfolg
Projekterfolg nach Branche
Projekterfolg nach Grösse (in CHF)
Gemäss der Umfrage sind Projekte in staatlichen und staatsnahen Betrieben erheblich erfolgreicher als der Durchschnitt. Projekte in der Industrie
schneiden dagegen unterdurchschnittlich ab.
Bei Projekten über 1 Mio. CHF sinkt die Chance es erfolgreich abzuschliessen auf unter 50%, bei Projekten über 20 Mio. CHF beträgt sie
sogar nur etwa ein Drittel.
● Projekt erfolgreich ● Projekt challenged ● Projekt abgebrochen/gestoppt
77.1%
80%
64.5%
Finanzen, Versicherungen
53.0%
IT / ICT / Hardware /
Software
51.1%
Industrie
45.5%
Staatliche und
staatsnahe Betriebe
0%
45.3%
45.9%
3.0%
54.5%
0.0%
70.3%
20%
40%
1.7%
29.7%
60%
80%
100%
Projekterfolg nach Komplexität
56.9%
60%
48.7%
42.9%
34.1%
40%
0.0%
20%
0%
bis 100’000
bis 500'000
bis 1 Mio.
bis 5 Mio.
bis 20 Mio.
über 20 Mio.
Anteil erfolgreicher Projekte (in Zeit, in Budget und in Scope)
Je komplexer ein Projekt desto kleiner die Chance auf Erfolg.
80.0%
80%
60.3%
60%
48.8%
44.7%
Keep it SMALL and SIMPLE
Projekte bis 1 Mio. CHF und nicht zu grosser
Komplexität haben die grössten Erfolgschancen.
40%
20%
Wenn GROSS dann AGIL
0%
Geringe
Komplexität
Mittlere
Komplexität
Grosse
Komplexität
Anteil erfolgreicher Projekte
(in Zeit, in Budget und in Scope)
Sehr grosse
Komplexität
Aber: Projekte sind erfolgreicher, wenn sie
agil durchgeführt werden, insbesondere die
Grossen.
17
Software Entwicklung
Verwendete Programmiersprachen
Outsourcing
Java ist die dominierende Programmiersprache, gefolgt von .NET und
Javascript mit grossem Abstand.
Knapp die Hälfte der Unternehmen lagern keine Tätigkeiten an Tochtergesellschaften oder Drittfirmen aus. Teile der Entwicklung und - mit
grossem Abstand - des Testings werden am meisten ausgelagert.
50%
48.5%
40%
38.1%
30%
Java
61.9%
18.8%
20%
9.6%
10%
7.8%
7.5%
3.5%
C++
15.1%
C
7.0%
Cobol
6.5%
PHP
5.4%
tig
es
So
ns
En
gi
ne
er
in
g
In
fra
st
ru
kt
ur
Pr
oz
es
sa
na
ly
se
Be
tri
eb
Te
st
in
g
en
ts
PL/SQL
12.7%
3.5%
0%
Re
qu
ire
m
C#
23.8%
Javascript
27.6%
ic
kl
un
g
.NET
28.4%
Ke
in
e
Andere
29.4%
En
tw
18
Erhebungsgrundlagen
Wirtschaftssektor
Aufgabenbereich
Wie bereits in den Vorjahren stellen IT Unternehmen sowie Finanzen und
Versicherungen die meisten Teilnehmenden.
Etliche Teilnehmende umschreiben ihre Tätigkeit mit mehr als einer
Rolle. Das Spektrum der Befragten ist wie in den Vorjahren sehr breit.
IT / ICT / Hardware /
Software / Consulting
32.1%
Test Manager
29.2%
Finanzen, Versicherungen
27.2%
Test Engineer /
Test Analyst / Tester
22.9%
Staatliche und
staatsnahe Betriebe
8.5%
Projektleiter
21.4%
Industrie
8.0%
Abteilungsleiter /
Bereichsleiter
19.6%
Transport und Verkehr
6.5%
Requirements Engineer
17.4%
MedTech
4.0%
Teamleiter
16.7%
Telekom
2.5%
Berater / Consultant
15.1%
Gesundheitswesen
2.5%
Business Analyst
14.7%
Andere
8.9%
Scrum Master
8.9%
Product Owner
8.9%
Quality Manager /
QS-Verantwortlicher
7.8%
SW Engineer in Test /
Testautomatisierer
7.6%
C-Level (CEO / CIO / ...)
6.9%
Solution/
Software Architekt
4.7%
Softwareentwickler /
Developer
4.2%
Solution Designer
2.9%
Product Manager
2.5%
Andere
4.9%
IT-Mitarbeitende
über 2001
28.3%
501 - 2000
19.4%
251 - 500
15.1%
51 - 250
19.2%
11 - 50
14.9%
1 - 10
3.1%
19
20
How SwissQ Works
Mehr über den SwissQ Culture Desk unter:
www.SwissQ.it/CultureDesk
Agile
Requirements
Testing
22
Einführung von Agilität
Zufriedenheit
0.9%
Gründe für Agilität
Entwicklung in den
Unternehmen
5.3%
(+3.9%)
●
10.5%
(+2.6%)
15.8%
39.7%
(-4.1%)
Erwarteter Nutzen erfüllt
Dauert länger als erwartet
Ist kompliziert
Erfüllt die Erwartungen nicht
Übung abgebrochen
40.7%
Zusammenarbeit zwischen
Business und IT verbessern
31.6%
Entwicklungsprozesse vereinfachen
29.2%
Risiken minimieren
27.8%
(-2.3%)
60%
40%
25.8%
21.5%
20%
1%
0%
Reduzieren
Im gleichen
Umfang
lassen
Leicht
erhöhen
Signifikant
erhöhen
Wartbarkeit und Erweiterbarkeit
von Software erhöhen
Management von verteilten Teams
13.9%
↗
13.4%
10.5%
↑
●
●
2015
2014
17.7%
↑
51.7%
↗
↑
Agile
Entwicklungs-Disziplinen verbessern
↑
25.3%
Sichtbarkeit von Projekten erhöhen
Kosten reduzieren
↗
28.2%
Team-Moral verbessern
Investition in Agile
↑
37.8%
Produktivität erhöhen
↗
↑
( ) = Veränderung zur Umfrage 2014
49.8%
Beschleunigung der Time-to-Market
↑
↑
(+1.3%)
●
●
●
●
●
Läuft alles super keine Probleme
51.7%
Fähigkeit erhöhen, mit sich
ändernden Prioritäten umzugehen
●
●
2015
2014
Erfolgsfaktoren
23
Erfolgsfaktoren
Team
Know-how der Mitarbeiter
Kulturwandel
Disziplin
geeignete Tools
Priorisierung
Ausbildung
Management-Unterstützung
Einbindung des Business
Agile
Schriftgrösse = Verhältnis Anzahl Nennungen
Organisation
24
Besetzung der Rollen
Erfahrung der Mitarbeiter mit Agilität
Scrum Master und Tester sind die beiden Rollen, welche in über 80% der
Fälle dediziert oder für mehrere Teams besetzt sind. Leicht abgeschlagen
folgt der PO.
●
nicht besetzt
●
dediziert im Team
●
●
für mehrere Teams
ausserhalb Team
60%
50.2%
●
●
2015
2014
40%
22.8%
Scrum Master
61.4%
10.2%
Tester
9.8%
Product Owner
54.9%
Agile
12.1% 28.4%
Projektleiter
Test Master/
Test Manager
21.4%
16.7%
IT Architekt
0%
20%
13.0% 16.7%
12.1% 22.3%
40%
60%
14.4%
17.7%
19.5%
23.3%
42.8%
27.9%
80%
15.8%
2.8%
23.7%
31.2%
34.0%
26.0%
37.7%
Release Manager
27.0%
35.8%
27.9%
27.4%
Produkt Manager
25.6%
34.4%
20.9%
20%
25.6%
49.8%
10.2%
Business Analyst /
Requirements Engineer
24.7%
100%
0%
Wird bisher
nicht
angewandt
8.4%
Weniger
als 1 Jahr
1-2 Jahre
2-5 Jahre
Mehr als 5 Jahre
Agilität im Unternehmen
Anteil agiler Projekte
Verankerung der Agilität im Unternehmen
Im Vergleich zu 2014 hat sich der Anteil der agil durchgeführten Projekte
innerhalb der Unternehmen merklich vergrössert. Nur wenige setzen
aber darauf alle ihre Projekte agil durchzuführen – deren Zahl hat sogar
leicht abgenommen.
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.
●
●
28.4%
30%
26.9%
26.5%
20%
8.8%
10%
7.4%
In der
Softwareentwicklung
Im Projektmanagement
1-20%
21-50%
51-80%
81-99%
Anteil agiler Projekte in Unternehmen.
100%
Teilweise
27.9%
23.3%
Im Release
Management
11.4%
40.0%
0%
4.8% 23.1%
26.5%
18.1%
45.7%
42.9%
70.2%
4.3% 26.5%
5.7%
65.9%
60.5%
32.4%
20%
Gar nicht
52.9%
35.1%
Im Portfolio
Management
●
43.7%
13.9%
Im Management
0%
●
Im Product
Management
Im Betrieb
1.8%
0%
2015
2014
Grösstenteils
40%
60%
80%
100%
Agile
● Vollständig ●
40%
25
26
Agile Praktiken
Management Practices
88.6%
Product Backlog
83.9%
Daily Standup
74.9%
Sprint Review /
Product Demo
70.6%
Retrospektiven
64.4%
Burndown Chart
59.2%
Release Planning
56.9%
Story Points
54.0%
Agile
Taskboard
46.5%
Iterative Planung
35.1%
Product Roadmap
28.0%
Velocity Chart
15.2%
Work in Progress
(WiP) Limits
0%
20%
40%
60%
80%
100%
●
●
2015
2014
Agile Praktiken
Testing im Kontext von Agilität
Produkt Backlog
82.9%
Unit Testing
79.7%
User Stories
80.0%
Automatisierung der
funktionalen Tests
63.5%
Epics/Features
58.1%
Continuous Integration
62.2%
Regelmässige Priorisierung
des Backlogs
54.3%
Akzeptanzkriterien
pro User Story
59.5%
Regelmässiges Backlog
Grooming
45.2%
Embedded Testing
(Tester im Team)
58.1%
Release Backlog
39.0%
Definition of Done
52.7%
Iteration Backlog
32.9%
Abnahmetest im Sprint
44.6%
Definition of Ready
25.7%
Test Master
(agiler Test Manager)
39.2%
Vision
22.4%
Test Driven Development
(TDD)
27.0%
Story Mapping
18.1%
Continuous Delivery
23.0%
Personas
15.7%
Pair Programming
17.6%
BA/RE im Team
14.8%
Hardening/Release Sprint
10.8%
On-Site Customer
5.7%
Acceptance Test Driven
Development (ATDD)
9.5%
Just-in-time Design
4.8%
Behavior Driven
Development (BDD)
4.1%
Andere
7.1%
Andere
2.7%
Agile
Requirements Engineering im Kontext von Agilität
27
28
SwissQ Info
Agile
Mehr über den SwissQ Culture Desk unter:
www.SwissQ.it/CultureDesk
Werkzeuge
Verwendete Tools im agilen Umfeld
29
Die grössten Veränderungen zu den Vorjahren
Jira bleibt das weitverbreiteste Werkzeug und hat seinen Marktanteil
nochmals massiv erhöht.
Post-it's
oder Kärtchen
MS Office
(Word, Excel)
67.0%
55.5%
43.3%
Confluence
33.2%
HP QC / ALM
24.2%
MS Team
Foundation Server
19.1%
Bugzilla
7.6%
IBM Rational
Team Concert
6.6%
Polarion
6.2%
Trello
6.2%
Andere
22.8%
80%
67.0%
●
●
●
60%
43.3%
2015
2014
2013
40%
24.2%
19.1%
20%
0%
MS Office
Jira
HP
QC / ALM
MS Team
Foundation
Server
Agile
Jira
30
SwissQ Info
Agile
Mehr über den SwissQ Culture Desk unter:
www.SwissQ.it/CultureDesk
Agile
Requirements
Testing
32
Zufriedenheit
Zufriedenheit mit RE-Prozessen
Ansehen von RE-Tätigkeiten
Die Zufriedenheit ist allgemein nicht sehr hoch und immer unter 50%.
Am besten schneidet die Analyse ab, am schlechtesten die Prüfung.
14.0%
Es ist für den Erfolg
der Organisation strategisch
● Sehr Zufrieden ● Zufrieden ● Mittelmässig ● Unzufrieden
100%
18.3%
14.4%
13.0%
17.3%
19.7%
Es ist ein wichtiger Faktor,
um verlässliche Software
zu produzieren
28.4%
80%
60%
42.8%
43.5%
42.3%
46.2%
51.0%
41.8%
Requirements
0%
14.0%
Die Kosten für
Requirements Engineering
könnten wir uns sparen
36.1%
33.7%
35.6%
5.3%
6.7%
8.7%
2.6%
2.4%
4.8%
RE
Prozess
Allgemein
Erheben
von
Anforderungen
Analysieren
von
Anforderungen
Dokumentieren
von
Anforderungen
Prüfen
von
Anforderungen
Verwalten
von
Anforderungen
33.7%
19.5%
Es ist ein notwendiges Übel
Es hat tiefe Priorität
40%
20%
50.0%
0%
26.9%
●
●
2.5%
20%
40%
25.0%
Investitionen im RE
60%
53.5%
●
●
2015
2014
40%
34.0%
20%
9.0%
3.5%
0%
Reduzieren
Im gleichen
Umfang lassen
Leicht
erhöhen
Signifikant
erhöhen
2015
2014
60%
Erfolgsfaktoren und Prioritäten
33
Erfolgsfaktoren
Know-how der RE/BA
Abnahmekriterien
Einsatz von Templates
Kommunikation
frühzeitiges Review
Traceability saubere Stakeholderanalyse
Modellierung
Ausbildung
definierter Prozess
Prioritäten
Die Korrektheit der Anforderungen steht im Vordergrund, während die formalen Aspekte, mit Ausnahme der Einhaltung der Meilensteine, zweitrangig sind.
1. Korrektheit
der Anforderungen
3. Vollständigkeit
der Anforderungen
2. Meilensteine
erreichen
4. Abnahme der
Anforderungen
5. Kosten
einhalten
6. Vorgaben
einhalten
7. Traceability
konsistent halten
Requirements
Schriftgrösse = Verhältnis Anzahl Nennungen
34
Aufwand
Aufwand RE im Verhältnis zum Gesamtaufwand
30%
24.1%
Aufwand RE im Verhältnis zum Entwicklungsaufwand
30%
24.6%
●
●
21.0%
20%
2015
2014
17.3%
20%
18.4%
17.9%
14.9%
●
●
16.3%
2015
2014
16.3%
10.8%
9.2%
10%
10%
3.6%
4.6%
1.0%
0%
bis 5%
6 - 10%
11 - 15% 16 - 20% 21 - 30% 31 - 50%
darüber
Aufwand RE im Verhältnis zum Gesamtprojektaufwand
0%
bis 5%
6 - 10%
11 - 15% 16 - 20% 21 - 30% 31 - 50%
darüber
Aufwand RE im Verhältnis zum Entwicklungsaufwand
Requirements
Der durchschnittliche RE-Aufwand
im Verhältnis zum Gesamtprojektaufwand
wird auf 11–15% geschätzt.
REAufwand
11-15%
Gesamtprojektaufwand
Der RE-Aufwand im Verhältnis zum
Entwicklungsaufwand wird im
Durchschnitt auf 16-20% geschätzt.
RE-Aufwand
16-20%
Entwicklungsaufwand
Erhebung von Anforderungen
Die grössten Veränderungen zu den Vorjahren
Erfahrungswissen nutzen
60.7%
80%
User Stories
55.4%
60%
Analyse bestehender Systeme
(System-Archäologie)
50.0%
40%
Interview
46.4%
20%
Workshop-Techniken
35.7%
0%
Brainstorming (-Paradox)
26.8%
Prototyping
26.8%
Feld-Beobachtung
19.6%
Storyboard
17.9%
Wiederverwendung
von Anforderungen
16.1%
Szenario
16.1%
On-Site Customer
7.1%
User Walkthrough
7.1%
Design Workshops (JAD)
7.1%
Umfrage / Fragebogen
3.6%
53.7%
Interview
52.2%
Anayse
bestehender
Systeme
54.1%
●
●
●
2015
2014
2013
User Story
Requirements
Techniken zur Erhebung von Anforderungen
35
36
Techniken zur Spezifikation
Techniken zur Erhebung von Anforderungen
Natürliche Sprache (Prosa)
49.5%
Die grössten Veränderungen zu den Vorjahren
60%
43.6%
Mockups / Prototypen /
Screens / UI-Design /
Storyboards (Screenabläufe)
47.5%
User Stories
43.6%
41.7%
47.5%
40%
20.6%
●
●
●
2015
2014
2013
20%
Requirements
Use Case Spezifikationen
41.7%
Handskzizzen / Flipcharts
34.8%
Use Case Diagramme
28.4%
BPMN Diagramme
20.6%
Aktivitätsdiagramme
19.1%
Kontextdiagramme
16.2%
Datenflussdiagramme
15.2%
Glossar
15.2%
Klassendiagramme
14.2%
Sprachschablonen
14.2%
Szenarien beschreiben
12.7%
Sequenzdiagramme
Andere
0%
User Story
Use Case
Mockups /
Spezifikation Prototypen /
Screens /
UI-Design /
Storyboards
BPMN
Modellierung von Geschäftsprozessen
In knapp 40% der Fälle ist die Modellierung vorgeschrieben, ein Grossteil
wendet diese jedoch nur situativ an. Code-Generierung und Round-TripEngineering sind die grosse Ausnahme.
Adhoc, für einzelne Projekte / Aspekte
56.7%
11.3%
Ist vorgeschrieben
38.3%
21.5%
Gar nicht
9.5%
Für Code-Generierung
1.0%
Für Round-Trip Engineering
0.5%
Spezifikationstechniken in agilen Vorhaben
Techniken zur Prüfung von Anforderungen
User Story und Mockups / Prototypen sind die führenden Spezifikationstechniken in Vorhaben, welche vorwiegend ein agiles Vorgehensmodell
einsetzen.
Review und die (frühzeitige) Ableitung von Testfällen sind die meistgebrauchten Techniken.
User Stories
64.2%
Mockups / Prototypen / Screens
UI-Design / Storyboards (Screenabläufe)
58.0%
Natürliche Sprache (Prosa)
50.6%
Handskzizzen / Flipcharts
38.3%
Use Case Spezifikationen
34.6%
Use Case Diagramme
16.1%
Spezifikationstechniken in Wasserfall-Vorhaben
Prosa und die Use Case Spezifikation sind führend bei Vorhaben, welche
vorwiegend Wasserfall-orientiert sind.
Natürliche Sprache (Prosa)
49.1%
Use Case Spezifikationen
47.2%
Mockups / Prototypen / Screens
UI-Design / Storyboards (Screenabläufe)
35.9%
Use Case Diagramme
34.0%
User Stories
32.1%
Handskizzen / Flipcharts
30.2%
BPMN Diagaramme
24.5%
Reviewtechniken
(Inspektionen, Peer-Reviews, ...)
58.0%
Ableiten von Testfällen
43.9%
Prototypen erstellen
22.9%
Checklisten
17.6%
Modellierung
15.6%
Backlog Grooming
11.7%
Definition of Ready (DoR)
10.7%
Konsultationen
9.3%
Keine
8.3%
Andere
6.4%
37
Requirements
Spezifikation und Prüfung
38
Rückverfolgbarkeit (Traceability)
Welche Beziehungen werden definiert?
Wozu werden Beziehungen verwendet?
Anforderungen - Test
71.2%
Anforderungsabdeckung
auf der Testebene
62.9%
Geschäftsanforderungen Systemanforderungen
46.2%
Anforderungsvalidierung
57.3%
Anforderungen Interesseneigner
(Stakeholder)
39.1%
Überwachung des
Projektfortschritts
36.5%
Anforderungen Architektur
26.1%
Auswirkungsanalyse
bei Änderungsanträgen
28.7%
Anforderungen Quellcode
Konformitätsnachweis
19.7%
14.1%
Programmverständnis
11.8%
Anforderungsabdeckung
auf der Architekturebene
11.8%
Änderungspropagierung
10.7%
Anforderungsabdeckung
auf der Quellcode-Ebene
6.2%
Anforderungen Commits im Quellcode
(bei Änderungen)
14.1%
Requirements
Mitarbeiter
Ausbildung
Methoden- und Fachwissen werden als wichtigste Fähigkeiten der RE‘s
und BA‘s genannt. Soft Skills und kommunikative Fähigkeiten kommen
auf der Wunschliste erst gegen Ende vor. Wohl ein Grund, wieso sich
diese Diszplin oft schwer tut.
● Hab ich schon ● Ist geplant
IREB CPRE FL
55.9%
ISTQB Foundation Level
Sprachliche Kommunikation
Formulierung verständlicher
Anforderungen
Methodenwissen
Soft Skills
Erfahrung
Workshop-Moderation
Technische Kenntnisse
Analytische Fähigkeiten
Fachwissen
38.5%
Certified Scrum Master
34.1%
ITIL
34.1%
Projektmanagement
(IPMA, PMI, ...)
30.7%
Certified Product Owner
25.0%
CAS Requirements Engineering
16.3%
21.0%
Hermes 5
15.5%
Agile Requirements
14.3%
IREB CPRE AL Elicitation &
Consolidation
Requirements
Fähigkeiten RE-Mitarbeiter
39
19.8%
DAS/CAS Business Analysis
MAS Business Analysis
Dokumentation von Anforderungs-Spezifikationen
OMG Certified Expert in BPM
(OCEB) Fundamental
Schriftgrösse = Verhältnis Anzahl Nennungen
IIBA CBAP (Certified Business
Analysis Professional)
iSQI Certified
Agile Business Analysis
IREB CPRE AL
Requirements Modeling
23.81%
0%
20%
40%
60%
80%
40
Werkzeuge
Tools im RE
Die grössten Veränderungen zu den Vorjahren
Requirements
Microsoft Office (Word, Excel)
69.4%
80%
Paper & Pencil
52.4%
60%
Microsoft Visio
39.3%
Atlassian Jira
32.0%
Balsamic Mockups
32.0%
Atlassian Confluence
26.2%
Sparx Enterprise Architect
23.3%
HP QC / ALM
19.9%
Microsoft Team Foundation
Server (TFS)
15.5%
Wiki
11.7%
Polarion Requirements
7.8%
IBM Rational DOORS
4.9%
Andere
29.7%
40%
69.4%
●
●
●
32.0%
23.3%
20%
0%
MS Office Atlassian JIRA
(Word, Excel)
Sparx
11.7%
Wiki
2015
2014
2013
Agile
Requirements
Testing
Zufriedenheit
42
Zufriedenheit mit Testaktivitäten
Ansehen des Testens
Mit der Testfallermittlung sind weniger als 50% zufrieden. Die Testdurchführung hingegen schneidet eindeutig am besten ab.
●
Sehr zufrieden
● Zufrieden ●
100
6.7%
6.7%
80
28.7%
30.6%
10.0%
Mittelmässig
●
8.7%
Es ist ein wichtiger Faktor,
um verlässliche Software
zu produzieren
Unzufrieden
5.1%
9.0%
49.0%
25.0%
Es ist ein notwendiges Übel
21.8%
30.6%
20.7%
Es ist für den Erfolg
der Organisation strategisch
Es hat tiefe Priorität
4.4%
31.7%
42.7%
Die Kosten für Tests
könnten wir uns sparen
60
0.7%
0%
40
48.8%
46.1%
46.6%
0
Testing
16.5%
Allgemein
Testmanagement
40%
44.9%
38.2%
20
15.7%
20%
57.2%
11.3%
10.4%
Testplanung
Testfallermittlung
15.8%
14.2%
Testdurchführung
Testauswertung
Investitionen ins Testing
60%
●
●
53.5%
2015
2014
40%
34.0%
20%
9.0%
3.5%
0%
Reduzieren
Im gleichen
Umfang lassen
Leicht
erhöhen
Signifikant
erhöhen
60%
●
●
2015
2014
Erfolgsfaktoren und Prioritäten
43
Erfolgsfaktoren
Qualität
stabile Testumgebung
Know-how der Tester
Zeit und Budget
Gute Anforderungen
Tool
Methodik
frühe Involvierung Planung
Testdaten
Schriftgrösse = Verhältnis Anzahl Nennungen
Testing
Prioritäten
Im Vordergrund stehen die klassischen Ziele des Testens: Testabdeckung, Abnahme erzielen und Fehler finden.
1. Hohe
Testabdeckung
2. Abnahme
des Kunden
erhalten
3. Möglichst viele
Fehler finden
4. Aufwand
reduzieren /
Effizienz erhöhen
5. Vorgaben
einhalten
7. Hoher
Automatisierungsgrad
6. Reproduzierbarkeit
der Tests
Aufwand
44
Testaufwand im Verhältnis zum Gesamtaufwand
●
2012
● 2013 ●
2014
●
Testaufwand im Verhältnis zum
Entwicklungsaufwand
●
2015
40%
2012
● 2013 ●
2014
30%
●
2015
25.5%
32.0%
23.8%
22.4%
30%
23.8%
20%
14.3%
15.3%
18.0%
20%
6.1%
5.4%
10%
5.1%
10%
5.8%
1.0%
1.4%
Testing
0%
0%
bis 5%
6-10%
11-15%
16-20&
21-30%
31-50%
darüber
Testaufwand im Verhältnis zum Gesamtprojektaufwand
Der durchschnittliche Testaufwand
im Verhältnis zum Gesamtprojektaufwand
wird über die Jahre konstant
auf 16–20% geschätzt.
Testaufwand
16-20%
Gesamtprojektaufwand
bis 5%
6-10%
11-15%
16-20&
21-30%
31-50%
darüber
Testaufwand im Verhältnis zum Entwicklungsaufwand
Analog wird der Testaufwand im
Verhältnis zum Entwicklungsaufwand im Durchschnitt stabil
auf 21–30% geschätzt.
Testaufwand
21-30%
Entwicklungsaufwand
Testverfahren
45
Geschätzte Effektivität der Verfahren
Berücksichtigung Nicht-Funktionaler Testaspekte
Konträr zum allgemeinen Trend zum «Shift Left» - der frühen Fehlerfindung durch Verfahren, welche auf der linken Seite des V-Modells zu
finden sind – werden Verfahren als effektiv angesehen, welche rechts
zu finden sind.
Allgemein werden die nicht-funktionalen bzw. qualitativen Aspekte in den
Projekten nicht übermässig gewichtet. Insbesondere die Browser- und Gerätekompatibilität findet wenig Beachtung, obwohl die Zeiten des Standardclients
– auch innerhalb eines Unternehmens – langsam aber sicher der Vergangenheit
angehören.
Mittel
Gross
Sehr
Gross
Keine
Angabe
Klein
End-2-End Test
8.5%
31.7%
48.7%
1%
Testautomatisierung
10.1%
20.5%
30.2%
Strukturierte Testfälle
User Acceptance Test
Unit Tests
Continuous
Integration
2.6%
1.6%
4.2%
2.3%
4.3%
TDD
6.2%
18.0%
40.5%
Gross
Sehr
Gross
13.7%
33.6%
45.3%
21.5%
31.5%
42.0%
18.6%
43.1%
34.6%
24.1%
43.0%
30.3%
25.0%
47.1%
22.4%
7.5%
40.6%
2.6%
Regressionstests
Einhaltung regulatorischer Anforderungen
Mittel
Sicherheit
34.6%
4.9%
4.3%
17.1%
45.7%
31.3%
18.6%
34.2%
36.8%
18.0%
43.9%
27.9%
4.3%
Robustheit
6.2%
Last & Performance
7.9%
Benutzerfreundlichkeit
(Usability)
3.6%
2.6%
5.5%
18.5%
33.8%
28.5%
21.8%
24.4%
24.7%
26.%
Browserkompabilität
24.9%
23.3%
32.2%
19.6%
26.2%
34.8%
26.9%
8.9%
Gerätekompabilität (zb
Smartphones)
29.0%
25.7%
25.4%
19.8%
27.3%
41.1%
23.7%
19.7%
24.3%
13.5%
40.0%
18.0%
14.9%
3.3%
Exploratives Testen
3.3%
Review
4.0%
4.0%
ATTD
37.9%
4.6%
Statische Code Analyse
17.7%
18.7%
5.6%
Testing
Klein
46
Mitarbeiter
Fähigkeiten
Ausbildung
Als wichtigste Skills eines Testmitarbeiters werden eindeutig Fach- und
Methodenwissen angesehen, gefolgt von der Fähigkeit Fehler zu finden
und mit diversen Stakeholdern stufengerecht zu kommunizieren.
● Hab ich schon ● Ist geplant
ISTQB Foundation Level
84.3%
ISTQB Advanced Level
(TM, TA u/o TTA)
Methodenwissen
Testfalldokumentation
Fachwissen
Soft Skills Testplanung
Testing
Finden von Fehlern
Toolerfahrung
Technische Kenntnisse
Kommunikation
Schriftgrösse = Verhältnis Anzahl Nennungen
59.4%
ITIL
40.6%
IREB CPRE FL
32.1%
Projektmanagement
(IPMA, PMI, ...)
28.0%
Certified Scrum Master
26.8%
Agile Testing (ATMS, CAT, ...)
26.3%
Hermes 5
Qualitätsmanagement
(dipl. Quality Manager, ...)
Certified Product Owner
Prozessmanager
ISTQB Expert Level
Agile Requirements
0%
20%
40%
60%
80%
100%
Testmanagement-Tools
47
Die grössten Veränderungen zu den Vorjahren
Testmanagement Tools
Jira konnte sich weiter durchsetzen, was angesichts der starken Verbreitung in der Entwicklung nicht weiter überraschend ist – obwohl Jira
nicht über die gleichen Features wie dedizierte Testmanagement und
ALM-Tools verfügt. Andererseits kommt von Jahr zu Jahr eine grössere
Vielfalt von Tools zum Einsatz.
50.4%
HP QC / ALM
48.6%
MS Office
Jira
51.4%
HP QC / ALM
50.5%
●
●
●
●
2015
2014
2013
2012
51.4%
Jira
14.8%
48.6%
Tricentis Tosca
14.8%
MS TFS Test Manager
11.6%
Eigene Entwicklung
10.3%
HP Sprinter
7.1%
Bugzilla Testopia
5.8%
IBM Rational
Quality Manager
5.5%
Inflectra Spira
4.2%
Polarion QA / ALM
3.5%
Andere
26.1%
Tricentis Tosca
10.3%
Eigenentwicklung
11.6%
MS TFS Test Manager
0%
20%
40%
60%
Testing
MS Office
(Excel, Word, Access)
48
Testautomatisierung
Die grösste Veränderung zum Vorjahr
Testautomatisierungs-Tools
Der Markt ist und bleibt recht stark fragmentiert. Es kommt eine grosse
Zahl verschiedener Tools zum Einsatz, darunter viele Eigenentwicklungen.
Testing
HP QTP / UFT
25.7%
Selenium (RC/WebDriver)
24.9%
xUnit (z.B. jUnit, TestNG, ...)
23.3%
Eigenentwicklung
22.9%
Tricentis Tosca
19.3%
soapUI
18.1%
MS TFS / Visualstudio
11.7%
Ranorex
9.2%
QF Test
7.2%
FitNesse
5.2%
CA Lisa
4.4%
IBM Rational
Functional Tester (RFT)
4.0%
Andere
18.1%
25.7%
HP QTP / UFT
24.9%
●
●
●
●
2015
2014
2013
2012
Selenium (RV/WebDriver)
19.3%
Tricentis Tosca
4%
IMB Rational Tester (RFT)
0%
10%
20%
30%
40%
Kosteneinsparung bei Testautomatisierung
Die Mehrheit geht von Kosteneinsparungen bis 20% aus – oder kann
keine Aussagen dazu machen. Im Bereich über 20% gab es einen
leichten Anstieg.
26.6%
27.4%
30%
16.5%
20%
10%
0%
17.7%
6.5%
Kosten
gestiegen
bis 10 %
bis 20 %
bis 50 %
●
●
●
5.2%
bis 80 %
Keine
Aussage
möglich
2015
2014
2013
Automatisierungsgrad
Automatisierungsgrad
Die grösste Veränderung zum Vorjahr
Der Anteil an automatisierten Systemtests hat sich in den letzten Jahren kontinuierlich gesteigert. Zum Beispiel konnten viele Projekte ihre
Abdeckung von 1 - 10% in den Bereich 11 - 20% oder gar 21 - 50%
erhöhen.
Der Anteil an automatisierten Systemtests hat sich in den letzten Jahrn
kontinuierlich gesteigert. Zum Beispiel konnten viele Projekte ihre
Abdeckung von 1 - 10% in den Bereich 11 - 20% oder gar 21 - 50%
erhöhen.
49
40%
●
●
30%
33.2%
41.5%
11.2%
8.7%
5.4%
Abnahmetest
2015
2014
20%
10%
0%
0%
1 - 10%
11 - 20%
21 - 50%
51 - 80%
über 80%
4.5%
46.3%
25.4%
14.8
9.0%
Systemtest
8.5%
32.6%
18.6%
17.8%
22.5%
Unit-Test
0%
1%-20%
21%-50%
51%-80%
über 80%
Testing
Teststufe
Anteil der automatisierten Systemtests
Abdeckung durch die Testautomatisierung
50
Last- & Performance-Test
Last- & Performance-Test-Tools
Zufriedenheit mit Last- & Performance Tests
LoadRunner von HP ist das meist genutzte verbreitete Performance-TestWerkzeug. Andererseits arbeiten jedoch auch viele Unternehmen mit
Eigenentwicklungen.
Fast 60% sind insgesamt zufrieden oder sogar sehr zufrieden mit den
Last- & Performance-Tests. Dies ist ein leichter Anstieg gegenüber dem
Vorjahr.
Eigenentwicklung
35.9%
HP LoadRunner /
Performance Center
31.5%
Jmeter
17.9%
Dyna Trace
15.8%
Proxy Sniffer
7.6%
Visual Studio Ultimate Edition
(Micrososoft)
6.0%
LoadUI
3.8%
NeoLoad
3.3%
Andere
25.5%
4.7%
16.8%
35.9%
Testing
42.4%
●
●
●
●
Sehr zufrieden
Zufrieden
Mittelmässig
Unzufrieden
How SwissQ Works
Vielen Dank für Ihre Aufmerksamkeit!
Vielen Dank für Ihre Aufmerksamkeit
By the way – we‘re hiring
www.swissq.it/karriere
Gerne stehen wir für Fragen und Präsentationen zu Ihrer Verfügung.
info@swissq.it
51
Die Vollversion des SwissQ Culture Desk
Menschen sind unterschiedlich
Jeder in sich einzigartig
Stattdessen haben wir eine einfache Richtlinie:
Benutze gesunden
Menschenverstand
Foto: Robin Benad
dozieren an
Entsprechend suchen wir immer neu Wege,
Fachhochschulen & Universitäten
DEN
Wir setzen uns herausfordernde Ziele
Wir alle lieben
unsere Freiheit
-EFFEKT
bei unseren Kunden zu erzeugen.
Erhalten Sie unter:
www.SwissQ.it/CultureDesk
© by SwissQ Consulting AG | Zürich
www.SwissQ.it | info@SwissQ.it | Tel +41 43 288 88 40 | Fax +41 43 288 88 39
Twitter: @SwissQ | Facebook: swissqconsulting