Conference Journal 2014

Transkript

1 2014 Interesting Insights into Professional Practice Papers of Lecturers at the Software Quality Days 2014

2 Impressum Publisher / Herausgeber Software Quality Lab GmbH Gewerbepark Urfahr Linz Austria info@software-quality-lab.com Published by Software Quality Lab GmbH, January 2014 Disclaimer The editor does not accept any liability for the information provided. The opinions expressed within the articles and contents herein do not necessarily express those of the editor. Only the authors are responsible for the content of their articles. The editor takes pains to observe the copyrights of the graphics, audio documents, video sequences and texts used, to use his own graphics, audio documents, video sequences and texts, or to make use of public domain graphics, audio documents, video sequences and texts. Any trademarks and trade names possibly protected by third parties and mentioned are subject to the provisions of the respectively applicable trademark law and the property rights of the respectively registered owners without restriction. It cannot be inferred from the mere mention of trademarks alone that these are not protected by third-party rights! The copyrights for published materials created by Software Quality Lab GmbH remain the exclusive rights of the author. Any reproduction or use of graphics and texts (also excerpts) without explicit permission is forbidden. Haftungsausschluss Der Herausgeber übernimmt keinerlei Gewähr für die bereitgestellten Informationen. Die in den Artikeln und Inhalten dargestellte Meinung stellt nicht notwendigerweise die Meinung des Herausgebers dar. Die Autoren sind alleine verantwortlich für den Inhalt ihrer Beiträge. Der Herausgeber ist bestrebt, in allen Publikationen die Urheberrechte der verwendeten Grafiken, Tondokumente, Videosequenzen und Texte zu beachten, von ihm selbst erstellte Grafiken, Tondokumente, Videosequenzen und Texte zu nutzen oder auf lizenzfreie Grafiken, Tondokumente, Videosequenzen und Texte zurückzugreifen. Alle genannten und ggf. durch Dritte geschützten Marken- und Warenzeichen unterliegen uneingeschränkt den Bestimmungen des jeweils gültigen Kennzeichenrechts und den Besitzrechten der jeweiligen eingetragenen Eigentümer. Allein aufgrund der bloßen Nennung ist nicht der Schluss zu ziehen, dass Markenzeichen nicht durch Rechte Dritter geschützt sind! Das Copyright für veröffentlichte, vom Autor selbst erstelltes Material bleibt allein beim Autor der Seiten. Eine Vervielfältigung oder Verwendung von Grafiken und Texten (aus auszugsweise) ist ohne ausdrückliche Zustimmung nicht gestattet.

3 Content Transformation zur Agilen Organisation in der Praxis 5 Christopher Brezlan Effizient vom Start zum richtigen Ziel 11 Anis Ben Hamidene Software-Test für Embedded Systems 17 Stephan Grünfelder Requirements Insights from LEGO Bricks (Literally) 20 Stefan Holtel Measuring Value 25 Gunther Verheyen, Ralph Jocham Agile & Testing & Mobile 28 Rares Irimies Intuitionsfallen der Projektarbeit 32 Peter Siwon Was machen unsere Anwender eigentlich so? 35 Markus Unterauer Modellbasiertes Testen einmal ohne Test-Automatisierung 38 Stephan Christmann Funktionale Sicherheit Modellbasiert? 42 Gudrun Neumann

4 20 th 22 nd January, 2015 Vienna Submit your papers for the Software Quality Days! You are kindly requested to submit your application for a presentation, tutorial or workshop to be included as part of the conference. Workshop Day: 20 th January, 2015 Conference Days: 21 st 22 nd January, 2015 Submit your application now! only until may 31 We look forward to welcoming you in 2015! Key topic: Software and Systems Quality in Distributed and mobile Environments Practical tracks + Scientific track + Solution Provider Forum Top keynote speakers Topics: Requirements, testing, automation, agile, project management, quality management, processes, techniques and methods Lectures HIGHLIGHTS: Workshops and tutorials Tool Challenge Best Quality Tool Award

5 Transformation zur Agilen Organisation in der Praxis Transformation zur Agilen Organisation in der Praxis Erfahrungen aus der Software Produktentwicklung In Unternehmen, in denen heute Software Entwicklung stattfindet gehört das Schlagwort der agilen Projektabwicklung mittlerweile zum Status Quo bzw. zumindest zum guten Ton. So unterschiedlich der Begriff der Agilität heute verwendet und verstanden wird, so unterschiedlich präsentieren sich auch die konkreten Implementierungen in der Praxis. Beginnend mit der schlichten Einführung einzelner agiler Elemente, wie z.b. Daily SCRUM Meetings in weitestgehend traditionell gemanagte Projekte, bis hin zu weitreichenden agilen Transformationen gesamter Organisationen. Dabei ist heute in jedem Fall der jeweilige Linien Manager gefordert, die Analyse, Entwicklungs- und Testeinheiten neu auszurichten, aber vor allem bei sich selbst mit Veränderung zu beginnen. Basierend auf Erfahrungen aus der Software Produktentwicklung bietet dieser Artikel praxisnahe Lösungsvorschläge zu Problemstellungen, die sich bei der konkreten Umsetzung agiler Transformationsschritte bis hin zu einer agileren Organisation aufgetan haben. Somit kann sowohl der agilerprobte, als auch der agil-noch-unerfahrene Leser profitieren und viele praxisnahe Impulse mitnehmen. Von einer Studie zur Praxis Im Juni 2012 hat die Fachhochschule Koblenz 226 deutsche Unternehmen aller Größenordnungen aus 19 verschiedenen Branchen befragt und in einer Studie Status Quo Agile untersucht, wie die Verbreitung agiler Methoden in der Projektpraxis nun tatsächlich aussieht. an, Projekte durchgängig klassisch zu managen, d.h. immer noch gänzlich auf agile Ansätze zu verzichten. Immerhin fast zwei Drittel der befragten Unternehmen führten an, bereits erste Schritte auf dem Agilen Transformationspfad gesetzt zu haben. Der erste Cluster an Unternehmen führen Projekte gemischt durch, d.h. traditionell gemanaged, jedoch angereichert mit agilen Elementen, wie z.b. Daily SCRUM Meetings, Pair Programming etc. Der zweite Cluster managed einen Teil ihrer Vorhaben sowohl traditionell als auch einen anderen Teil des Projektportfolios vollständig agil (z.b. SCRUM basiert). Die kleinste Gruppe der Befragten bilden Firmen, die alle ihre Projekte durchgängig agil durchführen, d.h. agile Ansätze werden im Projektmanagement flächendeckend eingesetzt. Bemerkenswert ist, dass somit für mehr als drei Viertel der befragten Unternehmen zumindest in der Projektabwicklung Agilität tatsächlich bereits eine Rolle spielt. Inwieweit die befragten Unternehmen agile Ansätze jedoch über die Projektgrenzen hinaus tragen, d.h. auch das organisatorische Umfeld, in denen IT-Projekte nun einmal stattfinden, an agilen Leitlinien ausrichten, behandelt diese Studie jedoch nicht. Diese organisatorischen Rahmenbedingungen rücken jedoch in der Praxis immer stärker in den Vordergrund, je weiter man sich auf dem agilen Transformationspfad bewegt. In vielen Bereichen werden zu starre, unangepasste Rahmenbedingungen, die für die Hebung der Potential agil durchgeführter Projekte sogar zum ultimativen Showstopper werden können. Abb 1. Studie Status Quo Agile der FH Koblenz (Juni 2012) durchgängig klassisch -> Projekte werden ausschließlich traditionell gemanagt gemischt -> traditionell geführter Projekte angereichert mit agilen Elementen, wie z.b. Daily Standups sowohl als auch -> Projekte werden etnweder klassisch oder agil geführt durchgängig agil -> Projekte werden ausschließlich auf Basis agiler Methoden gemanaged, z.b. SCRUM-based Knapp ein Viertel der befragten Unternehmen gab Einführung von Agilität in (Projekt-) Teams und Organisation In der Praxis stellt sich bei der Einführung agiler Projektmethoden somit relativ schnell die Frage, wie sich diese nunmehr agil durchgeführten Projekte denn in die etablierte, typischerweise klassische Projektorganisation integrieren, die sich z.b. an Standards wie PMI oder IPMA orientiert. Eine wei- Software Quality Days

6 Transformation zur Agilen Organisation in der Praxis tere dominante Bestimmungsgröße ist zweifelsohne auch die Linienorganisation, deren Steuerungsmechanismen unter Umständen agilen Projekten die Luft zum Atmen nehmen können. Auch hier gilt es, ein optimales Zusammenspiel zu finden. Somit tun sich mit der Einführung von Agilität in der Praxis (mindestens) zwei grundsätzliche Aufgabenstellungen auf, nämlich 1. Wie führen wir agile Methoden in unsere Projekte ein und bringen diese effizient zur Anwendung? 2. Wie schaffen wir eine optimale Einbettung unserer agilen Projekte in das organisatorische Umfeld? Beide Fragestellungen beeinflussen sich wechselseitig und müssen bei der Einführung agiler Ansätze jedenfalls explizit und praxisnahe adressiert werden, bedingen jedoch durchaus unterschiedliche Maßnahmen und Transformationspfade. Die folgende Abbildung soll dies grafisch verdeutlichen. Abb 2. Agile Teams (hier SCRUM-based) im Spannungsfeld zur klassischen Projekt- und Linienorganisation 1. Agile Team Organisation In unserem Praxisbeispiel wird davon ausgegangen, dass agile Teams einen SCRUM-based Ansatz verfolgen, d.h. unter anderem die zentralen Rollen des SCRUM Masters und Product Owners etabliert sind. 2. Project Organisation Agile Teams finden sich oft in einem klassischen Projekt Management Rahmen wieder, welcher auf Standards wie PMI oder IPMA basiert und als eine treibende Rolle den (zertifizierten) Projekt Manager eingesetzt hat. 3. Linien Organisation Die Linien Organisation gibt mit ihren typischerweise hierarchisch organisierten Einheiten und Linien Managern die generellen Rahmenbedingungen vor, in denen Projekte innerhalb eines Unternehmens durchgeführt werden. Einbettung agiler Projekte in den Rahmen einer Projekt- und Linienorganisation Im Folgenden wird der Fokus nun auf wichtige Aspekte einer optimalen Einbettung agiler Projekte in den Rahmen einer Projekt- und Linienorganisation gelegt. An diesen Schnittstellen ist in der Praxis mit (mindestens) folgenden Herausforderungen zu rechnen: Zentral (nach Engineering-Disziplinen) versus dezentral (nach fachlichen Domänen) orientierte Organisationsaufstellung ǿǿ Agile Teams orientieren sich am Produkt bzw. Geschäftsfeld und nicht an Engineering-Disziplinen. D.h. je nach etablierter Organisationsaufstellung gestalten sich agile Transformationsschritte unterschiedlich. ǿǿ Agile Ansätze forcieren cross-functional Teams. ǿǿ Agile Teams verfolgen (wie andere Teams auch) eine Lernkurve und werden produktiver, je länger sie stabil gehalten werden können Agile Methodik versus klassisches Projekt Management ǿǿ Teile des klassischen Aufgabenbereichs eines Projektmanagers überlappen in vielen Bereichen mit dem eines SCRUM Masters und Product Owners. ǿǿ Speziell Aufgaben, wie teamübergreifende Koordinationsbedarfe, zentrale Release- Steuerung etc. werden von agilen Ansätzen in der Regel nur schlecht abgedeckt, d.h. der Bedarf an einem zentralen Projekt Management bleibt in vielen Aspekten trotz agil organisierter Teams bestehen ǿǿ Die Kommunikationsschnittstelle zwischen agilem Team und klassischem Projektmanager gestaltet sich mitunter schwierig, da z.b. in Bereichen, wie der Ermittlung von Leistungsfortschritten, Arbeitsweise und sonstigen Reporting Mechanismen oft konträre Paradigmen verfolgt werden Agile ( selbstorganisierte ) Teams versus klassisches Linien Management ǿǿ Klassische Linien Manager agierend nach dem Muster Command&Control werden sich in einem Spannungsfeld mit den auf Selbstorganisation und Empowerment ausgerichteten agilen Teams wiederfinden. ǿǿ Ähnlich wie beim Rollenprofil des Projekt Managers kommt es mit der Einführung der agilen Rollen des SCRUM Masters und Product Owners speziell im operativen Aufgabenbereich eines klassischen Team Leiters Software Quality Days

7 Transformation zur Agilen Organisation in der Praxis Schritt eins: Die Grundidee von SCRUM-based arbeitenden Teams ist, sich in sogenannten cross-functional Teams aufzustellen, in denen neben dem SCRUM Master und dem Product Owner alle für die zu erreichenden Ziele notwendigen Skillprofile vorhanden sind. Der puristische SCRUM-Ansatz sieht vor, dass es im SC- RUM Team selbst keine weiteren spezifischen Rollen mehr gibt, was zweifelsfrei diverse Vorteile mit sich bringen würde, sich in der Praxis jedoch oft als nur schwer umsetzbar herausstellt. So behalten die Team Mitglieder meist ihren Rollenfokus eines z.b. Software Engineers, Test Engineers oder Software Architekten bei. Der wesentlichere Aspekt bei der Bildung cross-funktionaler Teams ist es jedoch, dieauch zu Überlappungen. Dies kann zu erheblichem Konfliktpotential führen. Agile Rollen versus klassisches HR Management ǿǿ Die Rollen SCRUM Master und Product Owner werden durch agile Transformationen zu zentralen Key Playern, sind üblicherweise jedoch noch nicht in den klassischen HR Strukturen installiert und oft fehlt es sozusagen an offiziellem Gewicht. ǿǿ Das Performance Management findet sich im Spannungsfeld von kollektiv zu erreichenden Teamzielen agiler Teams, mit der jedoch weiterhin notwendigen individuellen Performancebeurteilung einzelner Teammitglieder wieder. Um diese potenziellen Problemfelder bei der Einführung agiler Projektteams aufzulösen, bedarf es Anpassungen. Natürlich sollen agile Methoden niemals puristisch eingeführt werden, sondern müssen immer auch entsprechend den Unternehmensspezifika und der Projektkultur ge-customized werden. Stellt man sich jedoch die Frage der Effektivität über die Projektgrenzen hinaus, wird man schnell zum Schluss kommen, dass v.a. auch die organisatorischen Rahmenbedingung einer Anpassung bedürfen. Ziel muss es also sein, einen optimalen Rahmen für die agilen Mechanismen der Teams zu finden, in dem die agilen Teams auch atmen können. Der Wille, das vollständige Potential agiler Teams auch zu realisieren ist letztendlich ein starker Motivator, auch die organisatorischen Rahmenbedingungen einer Transformation in Richtung mehr Agilität zu unterziehen. Im nächsten Abschnitt dieses Artikels wird nun weniger auf das Zusammenspiel agiler Teams mit dem Projekt Management eingegangen, sondern vielmehr versucht, einen praxisnahen Lösungsansatz für eine mögliche Einbettung agiler Teams in die Linienorganisation zu skizzieren. Die Transformation zur Agil(er)en Organisation Einer der ersten wesentlichen Schritte besteht darin, die zentralen Teamrollen klar zu definieren, mit Aufgaben, Verantwortungen und Kompetenzen auszustatten, voneinander abzugrenzen und v.a. auch die handelnden Personen zu trainieren und zu coachen. Diese Rollen müssen klar fokussiert sein, um eine effektive operative Steuerung zu garantieren. Ein wichtiger Aspekt dabei ist, den neu eingeführten agilen Rollen (SCRUM Master, Product Owner) eine Entsprechung in der HR Job Struktur zu geben, da- mit auch die agilen Rollenbilder zu offizialisieren und daran z.b. Entwicklungspfade und Trainingsbzw. Zertifizierungsprogramme anzuknüpfen. Eine weitere wichtige Voraussetzung für die Effektivität agiler Teams ist es, die Aufgabenschwerpunkte des Linien Managements ( Manage the System ) und die des Team Managements ( Manage the Product ) klar zu definieren. In klassischen Organisationsformen werden auf unterster Hierarchieebene beide Aufgabenbereiche typischerweise der Funktion eines Teamleiters zugeordnet, d.h. dieser deckt die Linienaufgaben im engeren Sinne ab, wie z.b. Personelles, Jahreszielvorgaben, etc. und übernimmt auch die operative Steuerung des Teams, d.h. macht inhaltliche Vorgaben, priorisiert, gibt Unterstützung bei operativen Hindernissen und verteilt Aufgaben oft im command & control Modus. Bei einer genaueren Betrachtung dieses Rollenprofils fällt jedoch schnell auf, dass der operative Teil der Teamsteuerung gänzlich bzw. zumindest zu einem sehr hohen Grad mit den Aufgaben eines SCRUM Masters und Product Owners überlappen. Dies birgt nicht nur ein Synergiepotential, sondern kann wenn nicht klar adressiert - im Worst Case sogar in kontraproduktive (Kompetenz-)Konflikte führen. Somit ist dies einer der kritischsten Erfolgsfaktoren für das Gelingen einer Agilen Transformation. Im letzten Abschnitt dieses Artikels wird somit eine mögliche praxiserprobte Vorgehensweise skizziert, die, zugegeben, stark vereinfacht, im Kern auf 3 wesentliche Schritte reduziert wurde. Wesentliche Schritte beim Aufbau einer Agil(er)en Organisation Software Quality Days

8 Transformation zur Agilen Organisation in der Praxis se Teams nicht nur als temporäre Einheiten zu sehen, sondern vielmehr zu versuchen, diese auch im organisatorischen Sinne über einen längeren Zeitraum stabil zu halten und funktional auf wesentliche und stabil bleibende Produkt(gruppen), Software Module oder Geschäftsfelder etc. auszurichten. Je nach Ausgangslage der Linienorganisation (zentral vs dezentral) fällt dieser Transformationsschritt mehr oder weniger aufwändig aus. Speziell in einer auf den Markt orientierten Software Produktentwicklung bietet sich die Einführung cross-funktionaler Teams, die z.b. nach Produktgruppen oder Geschäftsfeldern ausgerichtet sind, regelrecht an. Schritt zwei: Im Zuge der Bildung dieser cross-functional Teams sollte man sich auch relativ bald im Klaren darüber werden, wie denn künftig die Rolle des operativen Team Leiters positioniert ist. Aufgrund der weiter oben skizzierten und in der Regel sehr hohen Überlappung der operativen Aufgaben eines Team Leiters mit den agilen Rollen des SCRUM Masters bzw. Product Owners könnte somit ein nächster Schritt darin bestehen, die operativen Aufgaben des Team Managements entsprechend der Rollendefinition an den Product Owner (z.b. inhaltliche Führung des Teams) und an den SCRUM Master (z.b. Auflösung operativer Hindernisse) permanent zu übertragen. Die Linienaufgaben (z.b. Personelles, Zielvorgaben etc.) hingegen können eine Organisationsebene höher (hier: dem Department Head ) zugeordnet werden. Die Linienaufgaben bekommen somit auf dieser Position ein noch stärkeres Gewicht, deren Ausübung jedoch in vielen Aspekten an die darunterliegende, nun nicht mehr von Team Leitern getragene Teamstruktur angepasst werden muss. Hierarchie-Manager werden zu Agilen Linien Manager. Durch dieses Empowerment der Teams wird die Hierarchie flacher, die mögliche Führungsspanne grösser und gleichzeitig Komplexität beherrschbarer, weil die operative Teamsteuerung auf die Rollen übertragen wurden, die in diesen Bereichen auch ihre Expertise fokussieren können. Die inhaltliche Steuerung übernimmt somit der Product Owner, die architektur/design-technische Verantwortung liegt beim (Software) Architekten und die koordinierende, unterstützende bzw. coachende Rolle übernimmt der SCRUM Master. Personell gesehen sind es oft die klassischen Team Leiter, die je nach ihren Fähigkeiten und Schwerpunkten im Zielszenario eine dieser zentralen Teamrollen übernehmen. Abbildung 3 und 4 sollen die ersten beiden Transformationsschritte grafisch verdeutlichen. Abb. 3 Teams in klassischer funktional ausgerichteter Linienorganisation (gesteuert über operativ fokussierte Team Leiter) Abb. 4 Agile cross-functional Teams in einer agilen Linienorganisation (gesteuert über zentrale Rollen wie Scrum Master und Product Owner). Software Quality Days

9 Transformation zur Agilen Organisation in der Praxis Abb. 5 Einbettung Agiler Teams in ein agilisiertes organisatorisches Umfeld Schritt 3 Die ideale Organisationsaufstellung gibt es nicht. So hat natürlich auch dieser dezentrale Organisationsansatz Nachteile, die es gilt, so gut wie möglich zu entschärfen. So läuft man in diesem Setup eben leicht in das Problem, dass nötige Standardisierungen zu kurz kommen und damit z.b. Technologie-Stacks, Tool-Landschaften und Gesamt-Architekturen aus dem Ruder laufen. Und das drückt natürlich auf die Effizienz der Organisation. Weiters braucht es in diesem dezentralen Organisationsansatz auch an Zusatzmechanismen, die die (Engineering-)Diszipline, wie Architektur/Design, Software Engineering, Requirements Engineering etc. im Sinne von mehr Effektivität weiterentwickeln und für einen Informationsaustausch unter den Peer-Gruppen sorgen. Ein Treiber dafür kann die Schaffung von entsprechenden Communities of Practice sein, in denen z.b. alle Architekten tourlich unter der Klammer eines Enterprise Architekten(teams) zusammengefasst werden, dabei Architektur und Design Standards definieren und verabschieden, Best Practices austauschen und Know-How Transfer betreiben. Zusätzlich können diverse Reviewprozesse festlegen, dass wesentliche Architektur/Design Entscheidungen vom zentralen Enterprise Architekten im Hinblick auf eine effiziente Gesamtarchitektur reviewed werden müssen. Ähnliche Communities of Practice können und sollen auch für Product Owner, Test Engineers etc. etabliert werden. Abbildung 5 zeigt nun den Zustand nach Durchführung der 3 Transformationsschritte mit einer, über die Projektgrenzen hinausgehenden agileren Organisation, die es erlaubt, die Vorteile agiler Ansätze nicht nur innerhalb von Projekten zu generieren, sondern diese Potenziale auch im Zusammenspiel mit dem größeren organisatorischen Rahmen zu heben. Alle diese Ausführungen basieren auf Erfahrungen und Erkenntnissen, die bei der praktischen Umsetzung eines agilen Transformationsprojektes in der Software Produktentwicklung gewonnen wurden. Gerade deshalb kann ein solcher Transformationsprozess auch nicht in der exakt gleichen Form in einem anderen Unternehmensumfeld angewendet werden, sondern muss vielmehr entsprechend an die jeweilige Ausgangslage, Unternehmenskultur, Rahmenbedingungen etc. des angepasst werden. Viel Erfolg bei Ihrer Agilen Transformation! Literaturverzeichnis Studie Status Quo Agile, Fachhochschule Koblenz, 06/2012 ( Autor Christopher Brezlan Mag. Christopher Brezlan leitet den Bereich Research & Development bei AGFA Health- Care am Standort Wien und ist für ca. 35 MitarbeiterInnen und 5 Entwicklungsteams verantwortlich. Die Hauptaufgabe des Standorts ist die Entwicklung von zentralen Modulen des KI-Systems ORBIS. christopher.brezlan@agfa.com Software Quality Days

10

11 Effizient vom Start zum richtigen Ziel Effizient vom Start zum richtigen Ziel Wie werden Requirements entwickelt, so dass die Lösung auch zum Problem passt? So habe ich das nicht gemeint!. Eine sonst unkritische Aussage, die für das Team vernichtend ist, wenn sie erst während des Sprint-Reviews vom Product Owner ausgesprochen wird. Und das, obwohl das Team agil unterwegs war. Aber was helfen die besten qualitätssichernden Maßnahmen und effizienzsteigernden Methoden und Disziplinen, wenn am Ende das Falsche entwickelt wurde? Was ist die Ursache, dass solche und ähnliche Fälle in der Praxis immer wieder auftreten? Und wie kann man frühzeitig und systematisch dafür sorgen, dass die Lösung später passt? Was bringt die tollste und bestdokumentierte Software wenn sie am Ende das Falsche macht? Falsch kann sich dabei auf die Anforderungen des Auftraggebers/Stakeholders oder aber auch auf die Erwartungen des Endanwenders beziehen. Agile Methoden, vor allem Scrum, helfen uns mit den vorgegebenen kurzen Entwicklungszyklen und den Inspektionswerkzeugen solche Falschentwicklungen um einiges früher zu erkennen als mit klassischen Vorgehensmodellen. Nichts desto trotz ist jedes falsch umgesetzte Feature verlorene Arbeit und Zeit, die nicht nur das Projektbudget vergeuden, sondern tragen erfahrungsgemäß zur Demotivation des Teams bei. Das Ergebnis ist eine sinkende Gesamtperformance der Teams. Ist es dann nicht möglich diese Missverständnisse schon vor der Umsetzung zu erkennen und zu beseitigen? Die meisten agilen Methoden sind grundsätzlich als Frameworks konzipiert, die per Definition nur einen globalen Rahmen festlegen. Konkrete Vorgaben für Detailfragen sucht man dort vergebens. Dazu gehört beispielsweise der Umgang mit Anforderungen oder mit der Dokumentation. Das ist aber sicherlich sinnvoll, da sie kontextabhängig sind. Und Effizienz kann nur dann erhöht werden, wenn der unnötige Ballast vermieden wird, indem spezifische und speziell auf den eigenen Rahmenbedingungen maßgeschneiderten Lösungen angewandt werden. Getrieben durch den Erfolg und Verbreitung der Agilität hat aber genau dieser Ansatz unseres Erachtens zur Entstehung einer Fülle von Methoden und Techniken geführt, die versuchen die Lücken der agilen Methoden zu füllen. Dazu gehören Specification By Example, Session Based Testing, Exploratives Tes- ting, Feedback Based Testing und viele andere. Die größte Herausforderung bleibt aber immer noch, diese Werkzeuge effizient in den eigenen Entwicklungsprozess zu integrieren, um die angesprochenen Ziele zu erreichen. Die Ursachen Missverstandene Anforderungen und Falschentwicklungen sind Stolpersteine, die wir immer wieder in unseren Projekten beseitigen mussten. Bevor wir Lösungen ausgearbeitet haben, war es zunächst wichtig die eigentlichen Ursachen für diese Probleme zu erkennen und zu analysieren. Die Ursachen waren vielfältig in der Art und Kritikalität. Im Kern konnten folgende Hauptprobleme ausgemacht werden: Eine fehlende oder schwache Teamidentifikation: Meistens haben die Teammitglieder einzeln agiert und nicht zusammen an einen Strang gezogen. Zwischen den einzelnen Expertengruppen (Fachbereich, Tester, Entwickler, Architekten..) waren Mauern vorhanden, die sowohl physikalischer Natur waren wie im Falle einer räumlichen Trennung- oder auch zwischenmenschlich aufgebaut waren. Die Falle des Offensichtlichen: Hier verzichtet das Product Owner Team bzw. der Fachbereich auf eine Detaillierung der Spezifikation, weil sie annehmen, dass das was sie spezifiziert haben offensichtlich und selbsterklärend ist. Die Begrifflichkeiten: (Miss)Verständnisprobleme entstehen wenn die involvierten Teammitglieder (Product Owner, Entwickler, Architekten, Tester...) entweder unterschiedliche Begriffe für das Gleiche oder aber auch einen Begriff für unterschiedliche Sachen verwenden. Unterschiedliche Ablageorten für die Spezifikationsrelevanten Artefakte: Probleme entstehen auch wenn die einzelnen Rollen verschiedene Ablageorte und formate verwenden. So werden Anforderungen und Testfälle getrennt verwaltet. Gleiches gilt für die Produktdokumentation. Software Quality Days

12 Effizient vom Start zum richtigen Ziel Die Methodenkiste Aufgrund der Vielfältigkeit der Ursachen müssen sie mit unterschiedlichen Mitteln angegangen werden. In den vergangenen Jahren entwickelte sich eine Fülle von Methoden und Techniken die die die einzelnen Problematiken ansprechen und die aus diesem Grund im Folgenden kurz vorgestellt werden Impact Mapping: Impact Mapping wurde von Gojko Adzic auf der Basis von verschiedenen Methoden wie Effect Mapping, Impact Maps und Feature Injection entwickelt (Adzic, 2012). Sie bietet Werkzeuge zur Ermittlung der effizientesten Lösungsalternativen, die den erwünschten Mehrwert für den Endkunden generieren. Der Fokus liegt dabei auf Effizienz und Mehrwert (Impact). Der erste Schritt ist die Ermittlung und die Ausformulierung des eigentlichen Geschäftsziels. Dann werden kollaborativ Lösungswege skizziert, in dem folgende Fragen in der Reihenfolge beantwortet werden: Ermittlung der Akteure: Wer kann bei der Erreichung des erwünschten Mehrwerts unterstützen bzw. hinderlich sein? Ermittlung der erwünschten Effekte: Wie soll das Verhalten der ermittelten Akteuren beeinflusst werden? Wie können sie uns dabei helfen die erwünschten Ziele zu erreichen? Ermittlung des Umfangs bzw. der Liefergegenstände: Was kann den erwünschten Effekt generieren? User Story Mapping: User Story Mapping ist eine von Jeff Patton entwickelte Technik um User Stories aus einem Produktbacklog so zu priorisieren und in Releases zu gruppieren, um den maximalen Mehrwert und Akzeptanz beim Endanwender zu generieren (Patton, 2005). Die Aktivität findet in sogenannten Story Mapping Workshops statt, zu denen alle notwendigen Experten eingeladen werden (Fachbereich, Tester, Entwickler, Architekten). In einem ersten Schritt werden die User Stories in kleinen Karten erfasst, die nur wenige Grundinformationen beinhalten: Kurze Beschreibung der Story, zugehörige Anwenderrolle, Frequenz der Nutzung und Kritikalität. Danach werden die User Stories auf einer großen Wand nach Benutzungsreihenfolge und Kritikalität für den Anwender sortiert. Wichtig für den Erfolg ist die Diskussion zwischen den Teilnehmern, die motiviert werden sollen Fragen zu stellen und ein gemeinsames Verständnis zu schaffen. In einem abschließenden Schritt sollen horizontale Scheiben aus der entstandenen Story Karte identifiziert werden. Diese Scheiben beinhalten Stories, die kritisch sind und mehrere Benutzungsbereiche abdecken. Sie bieten dadurch einen zusammenhängenden Satz an Funktionalitäten für den Endanwender, und eigenen sich deswegen als Releases.. Abbildung 2 Story Maps Abbildung 1 Impact Maps Specification By Example: Specification By Example wurde von Gojko Adzic auf der Basis von anderen Konzepten wie Behaviour Driven Development (BDD) und Acceptance Test Driven Development (ATDD) entworfen (Adzic, 2011) Sie definiert eine Reihe von Patterns mit dem Ziel Verständnisprobleme bei der Spezifikation von gewünschten Änderungen so früh zu möglich zu erkennen und zu vermeiden. Im Kern geht es dabei um folgende Aspekte: Entwicklung eines gemeinsamen Verständnisses der Anforderungen unter allen Beteiligten, in dem sie motiviert werden enger zu kollaborie- Software Quality Days

13 Effizient vom Start zum richtigen Ziel ren und miteinander zu kommunizieren. Dabei helfen Werkzeuge wie Specification Workshops und die gemeinsamen Ausarbeitung von Schlüsselbeispielen. Etablierung einer Single Source Of Truth also einer zentralen Ablage, die sowohl die Anforderungsspezifikation, die zugehörigen und abgestimmten Testfälle und eine Produktdokumentation vereint. Daraus entsteht eine sogenannte lebende Dokumentation, die für alle Beteiligten verständlich und erreichbar ist, und die jederzeit gegen das aktuelle System automatisiert validiert werden kann. Exploratives Testing: James Bach definiert Exploratives Testing wie folgt (Bach, 2003). Exploratory testing ist simultanes Lernen, Testdesign und ausführung Es ist eine wichtige Testdisziplin mit dem Ziel die Grenzen des Systems zu erkunden. Sie lebt von der Kreativität und den Talenten des Testers, und kann deswegen per Definition nicht automatisiert werden. Sie stellt aber ein notwendige Ergänzung zur Testautomatisierung dar. Die Tests laufen dabei außerhalb von festen Testplänen und erwarteten Testresultaten ab. Agile Quality LifeCycle: unser Lösungskonzept Unsere Erfahrungen haben gezeigt, dass die erwünschten Ziele am besten durch die richtige Mischung und die sinnvolle Integration der vor- Abbildung 3 Der Agile Quality LifeCycle gestellten Techniken und Methoden in den zugrundeliegenden Entwicklungsprozess. Die Voraussetzungen Agile Prinzipien Agile Prinzipien & Werkzeuge stellen die notwendigen Rahmenbedingungen für die erfolgreiche Umsetzung der vorgestellten Methoden und Techniken. Dazu gehören vor allem ǿǿ kurze Entwicklungszyklen: Um ein schnelles Feedback über die umgesetzten Änderungen zu erhalten und schnell auf Änderungen reagieren zu können ǿǿ regelmäßige Kommunikation zwischen den Beteiligten ǿǿ sinnvolle und von allen Beteiligten abgesegnete Definitions Of Done, die auch eingehalten werden ǿǿ Akzeptanz und Bereitschaft für Änderungen Das Team Der Mensch steht nicht ohne Grund im Zentrum der agilen Philosophie.. Teammitglieder sind der eigentliche Garant für den Erfolg. Sie müssen engagiert und motiviert sein, und sie müssen natürlich über die notwendigen Skills verfügen. Interesse am Erfolg ist eine weitere und mindestens genau so wichtige Voraussetzung, die durch geeignete Maßnahmen wie Transparenz erfüllt werden kann. Deswegen muss Vieles in die Team-Bildung investiert werden. Qualität muss darüber hinaus Teamverantwortung sein. Sie kann nicht vorgeschrieben werden. Das Modell Abbildung 3 zeigt ein mittlerweile ausgereiftes Vorgehensmodell, das wir in unseren Projekten entwickelt haben und ständig optimieren und anpassen. Es vereint alle im letzten Abschnitt aufgezeigten Techniken und Methoden und bildet diese zu den geeigneten Phasen und Rollen ab. Deutlich erkennbar ist die Verzahnung der Planungsaktivitäten (im linken Kreis) mit der Implementierung der erwünschten Änderungen Software Quality Days

14 Effizient vom Start zum richtigen Ziel (im rechten Kreis). Das gilt nicht nur für die behandelten Artefakte sondern für die Einbindung der verschiedenen Experten in den meisten Phasen. So sind Entwickler und Tester während der Planung und der Product Owner beziehungsweise die Business Experten während der Implementierung involviert. Umfanganalyse (Impact Analysis) Jede Arbeitsminute, die für die Entwicklung einer für den Endanwender ungeeigneten oder unerwünschten Funktionalität investiert wurde, ist verlorene Zeit. Dies gilt sowohl für die Spezifikation als auch für die Umsetzung der betroffenen Änderungen. Deswegen muss die Ausarbeitung des optimalen Produktumfangs sehr gut durchdacht und umgesetzt werden. Auf der anderen Seite muss die Spezifikation so leichtgewichtig sein, dass sie eine schnelle Umsetzung und Auslieferung des Produkts ermöglicht. Monate- oder gar jahrelange Analysen und Untersuchungen sind nicht tragbar und zeitgemäß. Ein gutes Werkzeug zur Entschärfung von dieser Problematik sind Impact Maps. Sie fördern die Skizzierung von verschiedenen Lösungsalternativen und bieten eine einfache aber effiziente Möglichkeit zur Visualisierung der zugrundeliegenden Annahmen sowie die betroffenen Akteure und die möglichen Liefergegenstände. Im folgenden Schritt werden die ausgearbeiteten Lösungen als User Stories definiert und priorisiert. Hierbei soll die Sicht der Endanwender stets berücksichtigt werden. Eine reine geschäftszielbasierte Priorisierung könnte nämlich die Akzeptanz beim Endanwender beeinträchtigen. So könnte eine auf dem ersten Blick unwichtige Funktionalität ein wichtiges Bindeglied zweier Anderen sein und ihr Fehlen könnte die Bedienbarkeit stören. Aus diesem Grund ist es hilfreich das Gesamtbild (Big Picture) ständig im Auge zu behalten. Helfen dabei können sogenannte User Story Maps, die sowohl den Nutzen für den Anwender als auch die geschäftliche Kritikalität sichtbar machen. Beste Ergebnis- se werden hierbei durch die Einbindung möglichst vieler Experten erreicht. Product Manager kennen den Markt und seine Entwicklung. Tester und Fachbereichsexperten kennen die Fachlichkeit. Architekten und Entwickler können gut einschätzen, wie aufwändig die Umsetzung sein kann. Es ist wichtig darauf zu achten, dass die User Stories zu diesem Zeitpunkt nur grob definiert werden müssen. Ausreichend ist meistens ein Satz pro User Story, in dem Ziel, Rolle und Lösungsidee zusammengefasst sind. Beispiel: Um das Auto ausreichend betankt zurückzugeben, kann ich als Werkstattserviceberater den Tankfüllstand bei der Fahrzeugannahme erfassen. Specification Workshops Bevor User Stories für die Umsetzung eingeplant werden, müssen sie um weitere Details angereichert werden. Wichtig dabei sind die Akzeptanzkriterien, die anhand von Schlüsselbeispielen oder Szenarien konkretisiert werden. Diese erweiterten User Stories sollen dann von ausgesuchten Experten mit den notwendigen Skills in zeitbegrenzten Meetings besprochen und bei Bedarf um weitere Details ergänzt werden. In Scrum eignen sich die Anforderungsverfeinerungsmeetings dazu (früher Groomings genannt). Es hat sich bewährt diese Meetings am Anfang des Sprints vor der Umsetzung zu halten. Sollten irgendwelche Punkte unbeantwortet bleiben, dann werden die User Stories zur Klärung aus der Planung rausgenommen. Sprintplanungsmeeting In diesem Meeting werden wie in Scrum üblich die User Stories für den neuen Sprint eingeplant und in Tasks aufgeteilt. Wichtig ist im Zusammenhang mit diesem Artikel die Einplanung von Tasks für die Abstimmung und Automatisierung der bereits spezifizierten Akzeptanztestszenarien und Beispiele. Für jede User Story wird außerdem ein Finalisierungstask (s.u.) angelegt. Software Quality Days

15 Effizient vom Start zum richtigen Ziel Abbildung 4 User Story LifeCycle User Story LifeCycle Es ist wichtig zu erkennen, dass eine User Story nur dann abgeschlossen ist, wenn alle zugehörigen Tasks fertig sind. Dies gilt sowohl für die eigentliche Implementierung der Änderungen als auch für die Automatisierung der definierten Tests und die Bereitstellung der benötigten Testdaten und Artefakte. Es hat sich bei uns bewährt einen letzten Quality-Gate-Task anzulegen, in dem ein letzte Abstimmung mit dem Product Owner bezüglich des Umfangs sowie der notwendigen Testszenarien und beispiele sowie die Art deren Umsetzung (UI, API oder manuell) stattfindet. Für die Spezifikation der Tests orientieren wir uns an Behaviour Driven Development, in dem wir eine menschenlesbare Syntax verwenden und die Dokumente zentral zur Verfügung stellen. So werden für das Verständnis der Tests keine besonderen Tools oder technischen Kenntnisse benötigt. Dadurch kann jeder jederzeit erfahren, welche Akzeptanztests zur Abnahme der Story eingesetzt werden. Zur Herstellung eines gemeinsamen Verständnisses innerhalb des Teams sowie zur Förderung des Know-How Austauschs zwischen den Teammitgliedern hat sich das relativ neue Verfahren Feedback Based Development bewährt (Bouillet & Maucher, 2014). Die Grundidee ist einfach aber sehr mächtig. Eine Änderung am Produktiv- oder Testcode darf nur dann ins Code-Repository integriert werden, falls eine zweite Person sie nach der geltenden Definition Of Done geprüft hat. Die Abnahme der Story findet statt, sobald alle zu- gehörigen Tasks abgeschlossen wurden. Dazu legen wir einen sogenannten Finalisierungstask an, in dem die Umsetzung bzw. den Fertigstellungsstand der Story zusammen mit dem Product Owner geprüft wird. Zur Abnahme gehört selbstverständlich ein explorativer Test. Regelmäßige Validierung Die im Rahmen der Umsetzung der User Story automatisierten Akzeptanztests haben eine weitere wichtige Rolle: Sie dienen als Regressionstests, die prüfen, ob Änderungen in bereits getesteten Teilen der Software keine neue Fehler verursachen. Damit dieser Feedback zeitnah erfolgt, werden diese Tests in die zentrale Continuous Integration Umgebung eingebunden. Living Documentation Spezifikationen die nach dem vorgestellten Muster entstehen, weisen folgende Eigenschaften auf: Sie beschreiben den aktuellen Stand der umgesetzten Features in einer für alle verständlichen Sprache Sie beinhalten alle abnahmerelevanten Informationen zu den umgesetzten Features einschliesslich Akzeptanzkriterien und -Tests Sie werden im Rahmen der Umsetzung von Änderungen aktualisiert beziehungsweise erweitert Sie werden zentral zur Verfügung gestellt Sie werden regelmäßig automatisiert geprüft Software Quality Days

16 Effizient vom Start zum richtigen Ziel Dadurch eigenen sie sich als Dokumentation des Systems, die nachweisbar aktuell und vollständig ist. In Specification By Example wird sie deswegen zurecht als Living Documentation bezeichnet. Session Based Testing Session Based Testing ist in Werkzeug, das es erlaubt innerhalb einer kurzen Zeit eine Anwendung ausführlich zu testen. Die Idee ist genauso so einfach wie effizient. Sie schreibt vor, dass sich das gesamte Team für einen festen Zeitraum (Timebox) am besten ein oder zwei Tage vor Sprintende zusammensetzt und einen aktuellen Stand der Anwendung gleichzeitig explorativ testet. Bewährt hat sich bei uns eine Timebox von 2 Stunden. Teilnehmen kann grundsätzlich jede interessierte Person. Verpflichtend ist es vor allem für das Scrum Team. Protokolliert werden dabei nur die auftretenden Fehler. Fazit Durch die geeignete Mischung aus den vorgestellten Methoden und ihre durchdachte Integration in den Entwicklungszyklus entstand ein Vorgehensmodell, das Entwicklungsteams unterstützt, die richtigen Features mit dem erhofften Mehrwert für den Endbenutzer effizient und möglichst ohne Falschentwicklungen umzusetzen. Das Modell zielt auf die frühzeitige Herstellung eines gemeinsamen Verständnisses der Ziele und Anforderungen und lebt aus diesem Grund von einer sinnvollen Kommunikation zwischen allen Experten und ihrer frühzeitige Einbindung im Entwicklungsprozess. Wichtige Voraussetzungen für den Erfolg sind aber grundsätzlich Disziplin, Mut zum Neuen und die ständige Lernbereitschaft. Denn alle Praktiken müssen von Allen angewandt und regelmäßig geprüft und bei Bedarf angepasst werden. Dann steht nichts mehr im Wege für zufriedene Endanwender und Stakeholder! Literaturverzeichnis Live-Deployment Das beste Feedback können Sie nur von echten Endanwendern unter realistischen Bedingungen erhalten. Aus diesem Grund empfiehlt es sich die Releasezyklen soweit es möglich ist zu kürzen. Continuous Delivery ist bereits bei vielen Firmen Realität und bringt enorme Vorteile für die Unternehmen mit. So können neue Features viel schneller an den Kunden gebracht werden, was einen Marktvorteil bedeutet. Die Kundenbindung wird dadurch auch erhöht. Validierung (Observe & Learn) Diese Phase spielt eine zentrale Rolle im geschäftlichen Erfolg des Produkts. Denn hier wird der wertvolle Input für die Gestaltung der Zukunft des Produkts aufgebaut. Dazu muss Feedback aus den Erfahrungen der Endanwender mit der produktiven Anwendung gesammelt und ausgewertet werden. Sehr wichtig ist auch die Validierung der während der Impact Analyse getroffenen Annahmen. Adzic, G., Specification by Example - How Successful Teams Deliver the Right Software. s.l.:s.n. Adzic, G., Impact Mapping: Making a big impact with software products and projects. s.l.:provoking Thoughts. Bach, J., Exploratory Testing Explained. [Online] Available at: Bouillet, P. & Maucher, D., Feedback Based Development. ObjektSpektrum, Band 1. Hendrickson, E., Explore It!: Reduce Risk and Increase Confidence with Exploratory Testing. s.l.:s.n. Patton, J., It s All In How You Slice It. Better Software. Autor Anis Ben Hamidene Anis Ben Hamidene ist Managing Consultant und Leiter der Competence Area Agile Quality Engineering in der NovaTec Consulting GmbH. Er beschäftigt sich seit über 12 Jahren vornehmlich mit den Themen JEE-Architektur sowie Agile Quality Engineering in den Branchen egovernment und Automotive. Er ist zudem als Coach und Trainer in den Themen Agile Testing, Specification By Example bzw. Agile Requirements Engineering tätig. Software Quality Days

17 Software-Test für Embedded Systems Software-Test für Embedded Systems Testtechniken und Literatur im Vergleich zu reinen Software-Produkten Bücher über das Testen von Software sind meistens für das Umfeld von Software-Produkten geschrieben. Embedded Systems werden zum Beispiel in der ISTQB-Literatur zwar angesprochen, doch ist man sehr weit weg von einer umfassenden Darstellung der Testtechniken, bei denen sich der Test von eingebetteter Software vom Test von reinen Software- Produkten deutlich unterscheidet. Dieser Beitrag diskutiert kurz diese Unterschiede und stellt Fragen, die in der meisten Software-Testliteratur nicht beantwortet werden. Danach wird Fachliteratur für den Test von Embedded Software vorgestellt, die diese Fragen beantwortet. Software eines eingebetteten Systems ist Teil eines Produkts. Das Produkt ohne funktionierende Software ist zumindest stark im Wert gemindert, wenn nicht wertlos. Die Software ohne die dafür vorgesehene Elektronik ist typischerweise völlig wertlos. Ganz im Gegensatz zum Software-Produkt, das man sich z.b. für den PC kauft. Der Marktwert des PCs ist unverändert, wenn ein gekauftes Software- Produkt nicht so funktioniert, wie gewünscht. Software-Mängel bei eingebetteten Systemen können ein großer Kostenfaktor werden, wenn das Produkt vom Markt genommen werden muss. Und der Markt ist riesig. Alleine im deutssprachigen Raum 20 Mrd Euro. Die Auswahl an Testliteratur wird der Marktgröße aber nicht gerecht. Gerade einmal zwei Bücher gibt es am deutssprachigen Markt zu kaufen, die sich ausschließlich mit Software-Tests für eingebettete Systeme beschäftigen [1,2]. Dabei gäbe es viele Gründe, die mehr Spezialliteratur wünschenswert machen, wie die folgenden Absätze zeigen. Data Races und Deadlocks Viele Testwerkzeuge am Markt unterstützen zwar den Test von Software-Produkten, aber von Natur aus nicht gerade den Test von Embedded Software. So gibt es zum Beispiel eine Reihe von Analyse- und Testwerkzeugen, die automatisch Deadlocks und Data Races aufspüren. Schon davon gelesen? Die meiste Testliteratur macht um dieses Thema oh- nehin einen Bogen, wie z.b. [2,3,4,5,6]. Und selbst wenn dem nicht so wäre: Diese Werkzeuge bedienen die API der Threading-Bibliotheken von Unix und Windows und sind daher nicht einfach einzusetzen, wenn man Software für ein Echtzeitbetriebssystem hat. Wie kann man dann vorgehen? Ressourcentests Viele eingebettete Systeme haben nur begrenzt RAM zur Verfügung und daher spielt der Speicherverbrauch eine wichtige Rolle. So wird der Verbrauch an dynamischem Speicher (Stack, Heap) oft im Rahmen von Tests gemessen. Schon je davon in einem Buch gelesen, das sich mit Tests von PC-Software beschäftigt? Die in Tests gemessenen Werte sind leider fast nie der garantierte worst case. Um diesen zu ermitteln, ist der Einsatz von Analysewerkzeugen notwendig. Wie funktionieren diese? Welche gibt es da? Stresstests Stresstests für Softwareprodukte unterscheiden sich oft erheblich von Stresstests von Embedded- Produkten. Schon der Begriff Stress wird in einschlägiger Literatur anders verstanden. So definiert der Rational Unified Process den Stresstest für Software-Produkte als einen Performance Test um Fehler zu finden, die bei geringem Ressourcenangebot und unter Wettbewerb um Ressourcen auftreten: geringe Speicherreserven, eine (fast) volle Festplatte, oder ein Kampf um Datenbank-Locks. In der EN definiert man für Embedded Systems Stress anders: als Überlast. Wenn das System ereignisgesteuert ist, so ist Stress z.b. eine geringfügig höhere Ereignisrate als die maximal spezifizierte Rate. Bei Systemen mit hohen Integritätsanforderungen kommt beim Test noch eine andere Art von Stress hinzu: Stress für die Hardware, etwa durch elektro- Software Quality Days

18 Software-Test für Embedded Systems statische Entladungen oder durch elektromagnetische Strahlung. In Tests wird man ermitteln, ob die Software Fehler erkennt, die durch den Hardware- Stress ausgelöst wurden (z.b. ein Einlesen unplausibler Sensorwerte oder Checksummenfehler beim Empfang von Botschaften) und entsprechende Ersatzreaktionen anbietet. Schon jemals ein Buch über Stresstests bei eingebetteten Systemen gesehen? Echtzeit Spielt die Rechtzeitigkeit von Berechnungen eine Rolle, z.b. bei Regelungsaufgaben, so ist auch die Erfüllung der Deadlines zu verifizieren. Auch hier ergeben Messungen nur seltenen Fällen zuverlässig die längstmögliche Antwortzeit. Um diese zuverlässig zu ermitteln, ist eine aufwändige WCET-Analyse (Analyse der Worst Case Execution Time) notwendig. Schon jemals davon in einem Buch über Software-Tests gelesen? Wie funktioniert diese Analyse? Unter welchen Bedingungen kann man auf die Analyse verzichten und den Testdaten trauen? Schedulability Wenn die Abarbeitung der in der WCET-Analyse untersuchten Code-Blöcke nebenläufig passiert und im schlimmsten Fall an beliebiger Stelle unterbrochen werden kann, etwa durch Interrupts oder durch einen präemtiven Scheduler, dann muss man auch das Scheduling und den Einfluss der Unterbrechungen und Kontextwechsel untersuchen. Das ist die Aufgabe der Schedulability-Analyse, die auf die WCET-Analyse aufbaut. Mit ihr kann man nicht nur das Scheduling von Aufgaben auf einer CPU, sondern auch z.b. das Scheduling von Botschaften auf einem gemeinsam genutzen Bussystem, z.b. den CAN-Bus in einem Kfz, untersuchen. Ohne diese Analyse gibt es in nebenläufigen Systemen mit dynamischem Scheduling keine garantierten Antwortzeiten. Für die Automobilindustrie z.b. kann das eine sehr wichtige Frage sein, auf die sie bis vor kurzem in deutschsprachiger Software-Test-Literatur keine Antwort fand. Testliteratur für eingebettete Software Spezialliteratur für den Test von embedded Software ist dünn gesäät. Daher kann die folgende Auflistung mit gutem Gewissen als einigermaßen vollständig bezeichnet werden. Software-Test für Embedded Systems Das im Mai 2013 erschienene Buch Software-Test für Embedded Systems von Stephan Grünfelder beantwortet alle hier im Artikel gestellten Fragen. Es beschreibt Komponententests, HW/SW- und SW/SW- Integrationstests, funktionale Systemtests, Stresstests, Lasttests, Failover-Tests sowie die Echtzeitverifikation und alle angesprochenen Analysen auf 370 Seiten [1]. Die mehrheitlich technischen Themen werden um je ein Kapitel zum Thema Qualitätsmanagement, Testmanagement und gesetzliche Haftung sowie ein Überblickskapitel zum Modellbasierten Test ergänzt. Zu jedem Kapitel gibt es praxisrelevante Übungsaufgaben mit Lösungen sowie eine Erwähnung bzw. Diskussion von kommerziellen und freien Testwerkzeugen. Persönliche Erfahrungsberichte, mehrheitlich aus der Automobilindustrie, lockern den Stoff auf und zeigen, wie die vorgestellten Techniken in konkreten Projekten eingesetzt werden. Das Buch richtet sich somit vor allem an Tester, in zweiter Linie an Entwickler und technische Projektleiter. Testen von Software und Embedded Systems Vom Titel her ähnlich aber doch mit anderem Inhalt erschien 2010 im gleichen Verlag die zweite Auflage von Testen von Software und Embedded Systems von Uwe Vigenschow [3]. Die etwa 340 Seiten des Buchs beschäftigen sich ein wenig abstrakter mit dem Thema Test als das erstgenannte Buch. Die Darstellung der Data-Race-Analyse ist nicht am neusten Stand der Technik, bei der Diskussion von Echtzeittests werden wichtige Unsicherheitsfaktoren beim Test von Architekturen mit Cache nicht diskutiert. Dafür beschäftigt sich das Buch seinem Untertitel professionelles Vorgehen mit modellbasierten und objektorientierten Ansätzen enstsprechend viel stärker mit Objektorientierung in eingebetteten Systemen und mit dem Modellbasierten Test. Die Sprache TTCN-3 und das UML Testing Profile, in [1] gerade einmal kurz erwähnt, werden vorgestellt und fast 40 Seiten des Buchs widmen sich der Lösung von organsiatorischen Problemen. Übungsaufgaben findet man im Buch zwar nicht separat ausgewiesen, doch einige ausführliche Beispiele im Text selbst. Testing Embedded Software Viele Jahre war das Buch Testing Embedded Software des holländischen Teams Broekman und Notenboom [2] das einzige Buch seiner Art am Markt. Das Buch erschien 2003 und wurde unverändert in den Jahren 2004, 2005 und 2008 neu aufgelegt. Kern des Buchs ist die Präsentation der TEmb-Methode zum Aufsetzen eines Testprozesses. Auf 320 Seiten Software Quality Days

19 Software-Test für Embedded Systems geben die Autoren dabei einen Überblick über Strategieentwicklung, Testdesign, Sicherheitsanalyse, Testautomation, die Verwendung von Checklisten und mögliche Testinfrastruktur. Der Fokus liegt dabei bei Steuergeräten für Automobile. So wird auch zum Beispiel die Problematik von Toleranzen beim Mixed Signals Test erläutert, ein Thema, das speziell bei automotiven Steuergeräten von Bedeutung ist. Die im Buch zu lesenden Hinweise zur Verifikation von harten Echtzeitschranken gelten heute als überholt verzeihlich, denn immerhin hat das Buchs mehr als 10 Jahre auf dem Buckel. Die Themen Schedulability, Data Races und Deadlocks werden nicht behandelt. Übungsaufgaben findet man im Buch nicht. Am Klappentext des Buchs sind zwar Testingenieure als erste Leserzielgruppe angeführt, dennoch kann man den Eindruck bekommen, dass viele Passagen des Buchs für das Qualitäts- und Prozessmanagement geschrieben wurden. Referenzen [1] Stephan Grünfelder: Software-Test für Embedded Systems. Dpunkt-Verlag, [2] Bart Broekman, Edwin Notenboom: Testing Embedded Software. Addison-Wesley, [3] Uwe Vigenschow: Testen von Software und Embedded Systems. 2. Auflage, Dpunkt-Verlag, [4] Andreas Spillner, Tilo Linz: Basiswissen Softwaretest, Aus- und Weiterbildung zum Certified Tester Foundation Level nach ISTQB-Standard. Dpunkt-Verlag, 4. Auflage, [5] G. Bath, J. McKay: Praxiswissen Softwaretest Test Analyst und Technical Test Analyst. Dpunkt-Verlag, [6] Peter Liggesmeyer: Softwarequalität. Testen, Analysieren und Verifizieren von Software. Spektrum Akademischer Verlag, 2. Auflage Autor Stephan Grünfelder Stephan Grünfelder ist selbständiger Trainer für Software-Testing und Requirements Engineering. Software Quality Days

20 Requirements Insights from LEGO Bricks (Literally) Requirements Insights from LEGO Bricks (Literally)»Thinking with Hands«as an Approach to Improved Software Specifications In a 2002 press briefing about the Afghan war U.S. Secretary of Defense Donald Rumsfeld mumbled:»but there are also unknown unknowns... the ones we don t know we don t know.«what seems to be a concern in serious affairs of war is even often the case in the early phases of requirements engineering: customers are often not capable to express requirements issues because they are not even conscious about that they actually have them until those are sometimes introduced by developers or were»discovered«by chance outside the established project frame. How can we earlier detect those issues and make them an integral part of the specification dialogue within the given project? We address this problem by making use of the dense interaction between brain thinking and hand motion while still in the initial steps of the requirements elicitation process. This idea is implemented by a methodology called LEGO Serious Play that stimulates requirements from customers that might exist on a subconscious level but would remain unspoken wishes otherwise or would be unveiled much to late to integrate them from an economical point of view. We have conducted a small case study and will report preliminary results. Introduction One of the problems in a valuable requirements engineering process arises from the observation that customers often cannot imagine how a not yet known software system might look like. They miss a deeper insight in either general technological possibilities or how such a system might change their working environments, working habits, or even cognitive styles of thinking once the still to-be-defined»cognitive tool«[1, 2] becomes a reality. Customers have a lack of understanding so-called»unknown unknowns«[3] - those issues they are not capable to express because they even don t know that they don t know about them (Figure 1). This often leads to unfavorable outcomes in software specifications and means additional costs [4]. This phenomenon is called the»dunning-kruger-effect«and has its reasoning in further research on cognitive bias [5]. Figure 1: The phenomenon of»unknown unknowns«[6] Misleading software requirements are a major concern in software development processes and are under consideration for decades [7 9]. We think it is necessary to bring back the»unknown unknowns«of customer requirements to light for the ultimate purpose to dramatically improve requirements engineering efforts due to early detection and acceptance of crucial requirements that would otherwise appear in later stages of a software development and would often mean increased costs and increased frustration. Although we saw some promising efforts to rethink the software specification elicitation process behind a mere technical requirements specifications approach [10] we still see a need to get more insight in what customers really think even those issues customers don t know that they don t know. But how can we stimulate customers to increase their level of awareness to express more of their»real needs«? We think, one possible approach is to complement customers»cognitive thinking«(done by their brains) by»emotional thinking«(done by their hands). Requirements Elicitation by Means of LEGO Bricks We suggest to step back from software specification elicitation by just requesting requirements from customers in a pure straightforward verbal manner. Software Quality Days

21 Requirements Insights from LEGO Bricks (Literally) We think in such a way many important details will be missed that might ultimately decrease quality of outcomes in the project. Instead, we assume it is helpful to clarify two criticial issues at the earliest possible stage of any requirements elicitation process: What is the»big picture«of the software under consideration from the point of view of the customer? And much more important: What are motivational key factors that will ultimately underly and drive any discussion between customers and developers during the project usually after detailed requirements specification have been written down? Thus, we do not claim to skip the»descriptive«specification sheet in the requirements engineering process. But we think that solely»verbally expressed«requirements will lead to a crucial lack of understanding. We suggest that clients and developers need a»lingua franca«that helps them to reflect their ideas and integrate those in a bigger picture of understanding the role of software under consideration. For such a purpose we think LEGO Serious Play might be a methodology that can be customized to the specific purposes of software requirements engineering. What is LEGO Serious Play? LEGO Serious Play is a facilitated process that matches the advantages of just»playing out«serious issues in business and project management. The methodology can be utilized by organisations, teams and individuals for many different purposes and is poised to stimulate ideas, improve communication between people, and accelerate problem resolution [11]. crisis analysis. Facilitation of a LEGO Serious Playinspired workshop should usually be conducted by a certified and experienced LEGO Serious Play trainer who steers the process in an effort that participants achieve their goals in time [13]. Why does LEGO Serious Play Work? LEGO Serious Play encompasses a number of principles that make it work [11]. First, it draws some ideas from»constructionism«[14] which means that learning happens when people engage in constructing something tangible and external to themselves such as a sand castle, a mechanical machine, or a painting. LEGO bricks offer a possibility to construct such»externalities«with less effort and in short time. Second, LEGO Serious Play is based on the core idea of»metaphors«[15] which means people build models from LEGO bricks that represent something different in a figurative sense. Third, LEGO bricks help people especially adults to express something of their identity. Adults do not just play, they often pursue a specific goal and compete against each other. Building with LEGO bricks offers them a way to tell about a serious issue in a way that would be much more difficult or even impossible to express otherwise, e.g. verbally. But, how do these principles actually help to customize LEGO Serious Play for the purposes of improving the serious, sometimes boring and in any case - lenghty matter of software requirements elicitation? We have conducted a small case study on how to utilize LEGO Serious Play for the purpose of more effective and efficient requirements engineering and will report our preliminary results. Explorative Case Study Figure 2: An archetypical LEGO Serious Play session [12] Workshops that are tightly facilitated by the LEGO Serious Play methodology can cope with many possible challenges, ranging from business modeling to business strategies, team collaboration, or even We report of a case study where we will show how LEGO Serious Play can be utilized for the purpose of more effective and efficient software requirements elicitation. We will report preliminary results from a case study conducted in our company. To our knowledge at the moment there is only one effort to use LEGO Serious Play for purposes of software requirements elicitation, esp. in the realm of human centered design [16]. Our approach instead is meant to serve as a complementary methodology to state-of-the-art software requirements specification approaches. It addresses the very early stages of the software requirements elicitation process and can be considered as an effort to decrease the ubiquitous risks of missing any Software Quality Days

22 Requirements Insights from LEGO Bricks (Literally) important requirements, resolving inconsistencies between competing requirements, and ranking requirements according to their absolute priorities especially from a customer s point of view. Setting the Scene In early 2013 we were in a situation that our former company Tieto was in the process to sell several international departments to a new financial investor. Part of the transition to the new company was confirming or reestablishing the IT infrastructure environment that should help to accomplish business goals after the transition. Thus, we decided to take the chance to ask a couple of experienced project managers from our company to review their given project management platform with regard to their requests on how to improve the given project management software that would have to be established for the new company. We invited the group to a three hours LEGO Serious Play workshop to»play out«their ideas on what a new project management software should provide for the new company with lessons learned from the existing solution in mind. Workshop Set-Up Due to working constraints the overall time frame for the workshop was only three hours which is less beyond recommendations for a workshop agenda with participants not experienced in the LEGO Serious Play methodology [13]. Nevertheless we made the effort to run the session with this time frame in mind. We invited three participants to the workshop. None has had any experiences so far with the methodology LEGO Serious Play. Thus, we had to run through some»skill building«activities to give them an understanding and a first tangible experience about the methodology for one hour. These exercises are crucial to help LEGO newbies (usually ver few) to proceed with the task to follow on the same level of competence [13]. As an integral part of skill building activities, we introduced the general stages a LEGO Serious Play session would run through (present a challenge, build individual model, share its meaning) [13]. After the skill building phase we introduced the»serious challenge«in the format of a so-called»postmortem«review of our company s existing project management software at that time [17]. The challenge was introduced by addressing the participants as follows:»you have made some experiences with the existing project management platform in our company. Imagine you could improve that so- lution: how would the best project management software look like from your point of view?«. In the next step, any participant was asked to create a couple of individual metaphor models of which each would describe a dedicated issue that might be important for improving the project software at hand. Actually, usually one model here represented a specific requirements issue expressed as a metaphor. In a final step the participants were asked to identify relationships between their individual models. The models should be positioned and related in a spatial manner that would give the red line for an overall story that would tell about the software requirements for an outsider. After internal discussion the group built a model that integrated all individual models and one participant told a story in two to three minutes that explained the overall model and how its pieces were fitting together. Preliminary Results We were surprised that participants which had roughly a one hour introduction to the LEGO Serious Play methodology at all and doing some skill building activities were already capable to focus on a»serious task«afterwards. Figure 1 presents some of the models, the first picture explains that the software should provide an easy access even from office abroad (the metaphor being an entrance gate), the second picture represents a rocket as a metaphor that the software should run very fast, and the third picture offers a transparent window metaphor which should mean that project data should be available and accessable from different points of view. Figure 3: Some models built by participants of the LEGO Serious Play workshop to unveil requirements for a new project management software (labels added to illustrate metaphors in use) Software Quality Days

23 Requirements Insights from LEGO Bricks (Literally) The participants created 11 metaphorical models all together that were finally arranged in a way that all models represented a spatial overview that would finally become the guideline to tell a fluent story about the software under consideration (Figure 4). 4). The final story unveiled again that all participants were suffering from insufficient performance of the given project management software and, thus, explicitely expressed their wishes that performance improvements ranked outstanding in comparison to all other requirements. The participants concluded that resolving performance issues would by far exceed any promises of further additional functionalities. We think this is the most interesting insight of that small case study: the methodology unveiled that a non-functional issue might become a possible major show stopper for the whole specification process. Although other elicitation methodologies would have taken this issue for granted but would on the other hand not rank it as crucial for progress of the whole specification process. With LEGO Serious Play we were capable to highlight the relevance of this issue for the software development process at the earliest possible point in time. We have already clarified that LEGO Serious Play is not a substitution for existing well-working requirements elicitation methodologies like e.g. use cases [18]. But well prepared and facilitated it opens up a complementary view especially in the earliest stages of software specification and development and, thus, provides a kind of a highly-efficient risk management tool. Figure 4: The LEGO group model that explains requirements for a new project management software (labels added to illustrate metaphors in use) All participants discussed how a coherent story should look like that would tell positioning, relationship, and weigh of dedicated requirements. Finally, one group member verbally explained the story for the purposes of documentation by running through the LEGO model. Critical Discussion Due to a stringent and forced facilitation process (which is an inherent part of the LEGO Serious Play methodology) everbody was immersed and involved in the process at any time, and seemed to be engaged and highly motivated to share his individual thoughts that were expressed by different metaphoric models and were eager to pursue the given task. Surprisingly we saw that non-functional requirements were seen as very important for all participants (see the cluster in the upper section of Figure Conclusions and Future Work LEGO Serious Play can be adjusted as a complementary approach to requirements elicitation to increase the level of detail and understanding in the process of early stages in software specification. It works in a way that it can improve and enhance the quality of interim results. We see two ways to proceed with our approach. First, we think of creating a pattern language [19, 20] that would describe on how to exactly apply the methodology to requirements engineering for even non-experts in LEGO Serious Play. Second, we will experiment with the idea of introducing a general»cognitive framework«[21] that could serve as a general framework to support customers when creating metaphors and building models. Acknowledgements We would like to say thank you to our stressed project managers that spare three hours of their valua- Software Quality Days

24 Requirements Insights from LEGO Bricks (Literally) ble time to have some fun playing with LEGO bricks but at the same time coping with a serious issue that had to be resolved and, thus, provided some data for a qualitative case study in LEGO Serious Play for requirements engineering purposes. Bibliography [1] Pea, R. D.: Beyond Amplification: Using the Computer to Reorganize Mental Functioning. In: Educational Psychologist 20 (1985) 4, S [2] Salomon, G.: On the nature of Pedagogic Computer Tools: The Case of the Writing Partner. In: Lajoie, S. P.; Derry, S. J. (Hrsg.): Computers as cognitive tools. Hillsdale, NJ [etc.] [3] YouTube: Donald Rumsfeld Unknown Unknowns. Abrufdatum [4] Bray, I. K.: An introduction to requirements engineering. Harlow [5] Dunning, D.; Johnson, K.; Ehrlinger, J.; Kruger, J.: Why people fail to recognize their own incompetence. In: Current Directions in Psychological Science 12 (2003) 3, S [6] Wikipedia: There are known knowns. URL: knowns. Abrufdatum [7] Bell, T.; Thayer, T.: Software Requirements: Are They Really a Problem? Redondo Beach, CA [8] Boehm, B. W.: Software engineering economics. Englewood Cliffs, N.J [9] Boehm, B.; Abts, C.; Chulani, S.: Software development cost estimation approaches - A Survey. In: Annals of Software Engineering 10 (2000), S [10] Gause, D. C.; Weinberg, G. M.: Exploring requirements. Quality before design. New York, NY [11] Rasmussen Consulting: The Science of LEGO Serious Play. Play Construction Imagination. Abrufdatum [12] webatelier.net: URL: User Requirements with Lego. URL: [13] Kristiansen, P.: LEGO Serious Play Facilitator s Manual [14] Harel, I.; Papert, S. (Hrsg.): Constructionism. Research reports and essays, Norwood, N.J [15] Lakoff, G.; Johnson, M.: Metaphors We Live By. In: O Brian, J. (Hrsg.): The Production of Reality: Essays and Readings on Social Interaction [16] Cantoni, L.; Botturi, L.; Fare, M.; Bolchini, D.: Playful Holistic Support to HCI Requirements Using LEGO Bricks: Proceedings of HCI International [17] Dingsøyr, T.: Postmortem reviews: purpose and approaches in software engineering. In: Information and Software Technology 47 (2005) 5, S [18] Bittner, K.; Spence, I.: Use case modeling. Boston, MA [19] Alexander, C.: The Timeless Way of Building. New York [20] Alexander, C.: The Origins of Pattern Theory, the Future of the Theory, And The Generation of a Living World. San Jose, CA [21] Anderson, L. W.; Krathwohl, D. R.: A Taxonomy for learning, teaching, and assessing. A revision of Bloom s taxonomy of educational objectives, Abridged ed. New York, London op Author Stefan Holtel Stefan Holtel is lurking for sophisticated and avantgarde methodologies to dramatically improve requirements engineering esp. in the early stages of the software specification process. Thus, he stimulates business modeling workshops by means of improvisation theater games or elicitates software requirements by means of LEGO bricks. He is often surprised how easy it is sometimes to increase quality in requirements engineering by even minor tweaks in rules of common sense. Software Quality Days

25 Measuring Value Measuring Value Measuring And Implementing Sustainable Business Practices For Competitive Advantage Our aim is to deliver valuable software, is a great principle and has put value at the centre of the agile movement and many agile talks. But if we don t find actionable ways to deal with value it might remain meaningless, another buzz word, another way of getting people to think it s time to move on to the next hype. Although value in itself is hardly quantifiable, it is imperative to think in terms of value in software development. Although value in itself is hardly quantifiable, we can absolutely measure whether we are delivering value (effectively). What we thought defined success For many years we were tricked into believing that software development can be considered a success if, at the end, 3 criteria are met: all promised requirements are delivered within the planned time, and respecting the budget we allocated to do so. It is reflected in the famous iron triangle of software development (see figure). That in turn tricked us into believing that, in order to be successful (the ultimate goal!), we had to exhaustively analyse, detail and describe all requirements upfront, and get formal approval and sign off over them before the actual development can be done. This big, upfront gathered information then becomes the input to a careful and exhaustive calculation of time and budget for the delivery part, often with the addition of some contingency (because maybe we aren t too sure after all?). The result is poured into a plan, often complemented by risk mitigation strategies and other exception procedures (because maybe we aren t too sure after all?). When this plan and all its components and clauses is approved and signed off, development can -finally- start. And then, obviously, it is just a matter of following the plan, to be successful. Deviations from the plan, seemingly happening sometimes, are unlikely to cause any real problems, because it s what change request instances are for (meetings, documents, approvals, and sign offs). Unfortunately, this was (and at many places still is) believed to be the only way we can ensure the success of software development. Yet, things aren t that easy. Many projects are plainly cancelled (29% according to the Chaos Report by the Standish Group of 2011) or in the end fail against the widely accepted success criteria of scope+time+budget (57%). Some however were actually successful in delivering according to the 3 planned predictions (14%). But then, success doesn t take into account that often quality was lowered to unacceptable levels in order to live up to the success criteria; reason why it s good to add that as a fourth variable to the iron triangle. Success doesn t take into account that the elapsed time might be according to plan, but may business-wise be extremely slow. Note that is not unusual for projects to deliver software months after the start. Success doesn t take into account that by the time the software actually becomes available for use, nobody really sees much value in the features anymore, at all or in the way the features are created. More innovative ideas for them have emerged, or improved technological ways to implement them are discovered. It lead to the finding that 64% of features, produced in this way, are rarely or never used. The 3 factors they told us defined success, fail in doing just that. And even if they do reflect success, they still only reflect how successful delivery of the software to the market is, not how the software is being received or appreciated by the market place. The 3 factors fail in showing how valuable the software is; it only says we got a version of software out the door at certain predicted conditions. What we say determines success The agile movement stresses the importance of active business involvement in development work and the need to continuously collaborate and communicate; over traditional, upfront predictions. The agile movement stresses the need for frequent releases to learn what actually works and what actually is appreciated; over big upfront descriptions. There is no better risk mitigation than regular feedback from actual users. Scrum, as leading framework for agile software development, is designed upon the foundation that software development is too complex for a predictive approach. Scrum implements empiricism in software development, thriving on frequent inspections to make adaptations. The subject of adaptations are the software, but also the engineering practices, budget, scope, Software Quality Days

26 Measuring Value time. Scrum does not care about the abused notion of project. The concept of project generally only serves the idea that success is possible if software is delivered on time, within budget and has all the predicted features. Scrum focuses on the software product (having an owner and a backlog) and incremental sustenance. The foundational belief to this is that the success of software development is defined by the capability to satisfy and impress the consumers of the features, at a reasonable price, a cost that has an effective return at some point in time, with creation happening in a way that is sustainable for the people in the ecosystem of the product. transparency we need to identify the areas where adaptation has the most impact. Think in terms of business metrics like employee satisfaction and customer satisfaction, revenues, investment in agile, etc. Think in terms of delivery capability metrics like cycle time, release frequency, defects, etc. All metrics are consolidated into an overall Agility Index for the organization. This Agility Index is an indication how effective the organization is in delivering value. One Agility Index is bound to time, place and context. The exact figure is of no importance. The evolution is of importance. The underlying set of metrics is of importance. The insights gained from the metrics, as a source of improvement, is of importance. Yes, We can measure If value defines success, how can we then measure whether we are successful? The value of software itself is difficult to calculate. It depends on context, time, technology, market, business domain. It cannot be reduced to one parameter. Predicting value doesn t make much sense either, since it can only be validated by the market place. The success of an organisation, in terms of survival, prosperity and leadership nowadays increasingly depends on their agility, i.e. their overall capability to deliver value against a background of constant change, evolution, innovation, improvement and re-invention. Scrum.org has developed the Agility Path framework to help organisations increase their agility and move toward a value-driven existence. With Agility Path we focus not on the illusive goal of calculating and predicting value or similar magic. With Agility Path we measure the outcome of an organization s work to help them think about the way that outcome is achieved. Organizations get a clear indication on whether they are delivering value or not. If not, they have many areas and domains to inspect, and do adaptations by installing, removing or improving practices. We inspect in order to adapt. Metrics provide the No magic, just hard work There is no magical formula to calculate value, and even if you would succeed in calculating value to steer your development priorities, it is still an assumption that remains to be validated (or contradicted) when you actually go to market. You can never be sure. The best we can do is measure the results of our actions, and measure regularly so we can detect trends and patterns (and prefer that over a naked, singular figure), and relate it back to how we work, change how we work, and measure the change in outcome. Endlessly and relentlessly. Continuously improve by learning and adapting, and getting the most out of what we do. This flexibility in the end will help organizations (1) respond to change, shown openness to change over ignoring or blocking it; (2) discover different options to respond, thereby embracing change and, finally, (3) innovate, be ahead and cause change (for the others to follow). Because we want to harness change for the customer s competitive advantage. Software Quality Days

27 Measuring Value Author Gunther Verheyen Gunther Verheyen has been in IT and software development since he graduated in His Agile journey started with extreme Programming and Scrum in Through years of dedication, working with several teams and organisations doing Scrum, Gunther became the driving force behind some large-scale enterprise Agile transformations as from Gunther currently partners with Ken Schwaber, Scrum co-creator, at Scrum.org. He directs the Professional series of Scrum.org and is co-developing Agility Path, a framework to improve an organisation s Agility. Gunther is the author of the highly appraised Scrum - A Pocket Guide (A Smart Travel Companion), that was published by Van Haren on November 4, It is available in our webshop in different formats. Co-Author Ralph Jocham Ralph has over 15 years of global (DE, UK, USA, CH) development experience in various technologies and blue chip business domains. Since 2000, when he came in contact with XP, Ralph considers himself as test infected and believes that state of the art development practices and a clear business value focus are crucial for the ROI. In 2003 Ralph combined XP with Scrum. Since then he has been a Scrum evangelist. He is a CSM (2005), CSP (2008), PSM I & II (2009), PSPO I & II (2011) and Professional Scrum Trainer and Engagement Manager for Scrum.org. Before founding effective agile. he worked for Zühlke in Switzerland, ThoughtWorks in San Francisco, USA and Oracle in the UK. Ralph is a lecturer at the University of Applied Sciences in Bern, where he teaches an agile living case in the medical technology department. Der neue Agile Testing Expert Lehrgang ISTQB Certified Tester Foundation Level , Wien, Linz und Graz , Lustenau und München Certified Agile Tester , Wien, Linz, Graz, Lustenau und München GUI-Testautomatisierung , Wien, Linz, Graz, Lustenau und München MIT FRÜH- BUCHER- RABATT Continuous Integration und Delivery , Wien, Linz, Graz, Lustenau und München Nutzen Sie den preislichen Vorteil eines Lehrgangs und buchen Sie noch heute: [E] info@software-quality-lab.com [T] Software Quality Days LINZ / WIEN / GRAZ / LUSTENAU / MÜNCHEN

28 Agile & Testing & Mobile Agile & Testing & Mobile Three converging Concepts The present article focuses on methods of determining the area of testing and develops on the topic of testing environment and types. Consequently, the proposed testing strategy is based on a succession of key steps including defining the testing purpose, continuous alignment to scope change, risk assessment, mitigation strategy and continuous feedback. Establishing a correct strategy regarding test types and environments is a crucial process, since it can lighten the workload, cut costs and help identify possible testing problems in advance. A modern overview of the IT universe reveals mobile technology as a particularly dynamic domain. This market sector is presently disputed between three major competitors, namely Apple, Nokia and the extended family of Android devices (Samsung, Motorola, Sony-Ericsson, etc.). Until recently, mobile devices only offered users access to basic applications ( , browsers, calculator and rudimentary games), yet nowadays we are bombarded with financial, health and insurance applications, advanced graphics games and personal assistant. These applications have quickly determined us to use our mobile phones or tablets throughout the day even for the least important tasks. As customer needs evolved, mobile application developers have shifted their focus from the qualitative aspect, favoring the complexity of their product. Increasing customer demands have led to frequent problems related to time allocation for the development and testing of applications. A solution for this issue could be identified by discussing the development methodology best suited for customer needs and which requires as less time and resources as possible. Standards shall be established at company level and will have to be adjusted and implemented so as to respect both customer demands and the product for delivery. By following the Agile methodology, the company that I work for has managed to define a set of guidelines that ensure the product will correspond to the customer s vision and market ideal. These basic principles are: defining the testing strategy defining the testing objective constant adaptation to objective changes identifying risks and establishing a prevention strategy continuous feedback We shall further discuss each of these principles targeting the mobile application universe and analyzing their individual impact upon product development. Defining the testing strategy Even though we cannot predict the obstacles we could come across during testing, it is essential to establish the basic testing strategy from the very beginning. We shall therefore need to: establish the area of testing determine the testing environment define the types of testing to be applied Area of testing The customer plays a very important role in establishing the area of testing (devices, operating systems, platform combinations, browsers etc). The QA (Quality Assurance) team has to inform the customer about the risks presented by a reduced area of testing or about likely risks once the application is being developed. To gather this information, the team needs to prospect the market so as to establish which are the most commonly used devices and operating systems. During a customer-team discussion, the following aspects must be agreed upon: which platforms are targeted in development which devices and operating system combinations testing should be focused on how likely it is that mobile phone operators or device producers have implemented common functionalities upon which the application would rely on Due to limited time or budget, actual testing will not be able to cover sufficient devices and operating system versions to considerably reduce the incidence of bugs. In this event, it is recommended that the most frequently used device-operating system combinations be tested, as well as the devices with the highest bug report. Another major step in establishing the area of testing is positioning the application on the market (games, social, banking, health etc.), since we will be able to decide which devices to use for testing according to the market segment the application is intended for. For ex- Software Quality Days

29 Agile & Testing & Mobile After defining the testing environment, the team has to decide which testing types to resort to. Be it manual or automated, the testing process must be adapted to the project complexity, allocated resource budget as well as the amount of time available. Consequently, when comparing manual with automation testing, we must take the listed aspects into account: Which is the best testing method? Manual testing is 100% effective, since it is easily able to mimic user behavior and should be used for at least 70% of the entire project. Automation testing is only 60-70% effective because the scripts applied cannot be fully complete or correct. Presently, the question of Manual vs. Automation is highly debated and most conclusions state that automation is not able to substitute manual testing. What are the costs of each method? To provide a short answer, we need to consider the complexity of the application and the amount of time allocated for testing. Automation testing is more costly in the initial phase, in which time and resources are consumed by developing automated scripts, setting up and using a Continuous Integration environment. Still, this method will prove useful in the regression testing stage. On the other hand, manual testing is able to isolate bugs in the earliest stage of product development, but presupposes higher costs in terms of the physical devices required. What are the advantages of this testing method? Automation testing can prove very useful in the regression testing stage by saving a great deal of testing execution time and plays a leading role in load testing or performance testing for the entire project. Certainly, as previously stated, the possibility of integrating automaample, we would need to cover as many devices as possible for a banking application to ensure easy access for users, whereas for games we would focus on devices mostly used by children (ipod, ipad, Android tablet). Another problem that may occur during the development of a complex application is using APIs provided by existing applications (Facebook, Twitter, etc) or by third-party libraries (TapJoy, iad etc). The customer needs to be aware that integrating these components may push the deadline back or may have a notable impact upon the application s stability (third-party bugs that cannot be fixed in due time or the avoidance of which could unpleasantly affect the application s functionality). Testing environment Once the area of testing has been established, the testing environment needs to be defined. We shall consider the following aspects: which testing types to use the costs of obtaining the specific environment the testing effectiveness on such an environment can the generated environment be used for testing other applications We can thus make a comparison between the following testing environments: emulators, physical devices and shared infrastructure. Emulators Emulators are convenient to use, but a series of characteristics specific to emulator testing have to be taken into account if they are used as the main testing environment: effective in: Sanity testing, Compatibility testing, Functional testing, Smoke testing free download 40% of testing can be executed on the emulator device-operating system combinations can be obtained not fully effective for day-to-day scenarios relatively slow testing environments intensely used in automation testing Shared infrastructure This alternative has a few features worthy of mention: effective in: Exhaustive testing, Compatibility testing, Interruption testing, Functional testing, Regression testing not free (DeviceAnywhere, PerfectoMobile) testing can cover a wide array of device-operating system combinations slow because internet connection is required effective for reproducing day-to-day scenarios Physical Devices Testing in such an environment can be considered the closest to the authentic experience, since user behavior can be perfectly simulated. The features important to remember are: effective in: Functional testing, Smoke testing, Acceptance testing, Regression testing, Bug fix testing accurate for reproducing problems occurred while using the device 50% has to be conducted on a physical device Effective in automation testing Offers quick and precise results Testing types Software Quality Days

30 Agile & Testing & Mobile tion testing into a Continuous Integration system (ex. Bamboo, Jenkins/Hudson etc.) should be considered. The main testing methods for manual execution are Functional and Bug-fix testing and the objectives are: a. user interface (fonts, colors, navigation from one screen to the next) b. b. basic application functionalities c. Usability testing buttons such as Home or Back in each screen; d. download, installation or uninstallation of the application e. Interruption testing application behavior when it runs in the foreground and the user receives a text message or phone call f. Monkey testing chaotically inserting characters or images in order to test the application s resistance to stress Aside from manual and automation testing, increasingly more companies resort to Crowd sourcing services, which serve to establish if the product is correctly built by transferring it to a group of future users (Alfa testing). Testing Strategy Having detailed the previous three testing components (area, environment and type), a four-step mobile application testing strategy can be conceived: Plan a. Understanding the documentation and requirements b. establishing the devices and combinations with operating systems c. describing the emulators or the physical devices to be used in testing d. describing the testing type to be used (manual or automation) Design a. finding adequate tools (for Automation, Test Case Management, Continuous Integration) b. procuring the devices c. establishing test scenarios Development a. creating test data b. creating test scenarios Execution a. configuring the test environment b. actual testing c. bug reports d. Execution Matrix Defining the testing purpose In the Agile-Scrum methodology, the QA process unfolds throughout the entire project, in each sprint. At the end of each sprint, all applications must have a compilable code which can be tested. Given that the generally allocated time for QA is 2-4 days, the test plan needs to be very clear and has to define the degree of quality of the code when the Demo is ready. During the first sprints (where new functionalities are generally implemented), the tester will only be able to validate the happy flow. As the code becomes more stable, automation testing, performance testing and negative testing scenario will be possible. Depending on the complexity of the product, the manager needs to allocate 1-2 sprints for testing and bug-fixing before the product is installed on the production environment and becomes public. Continuous alignment to scope change This rule is rather uncomfortable for most testers. Since in Agile, the priorities and functionalities of the application may change, the test plan has to be constantly upgraded to reflect the occurred changes. For example, the decision to allow users access to the backend part of the application is made, in order for them to add or delete other user accounts. This, however, has not been mentioned in the initial documentation of the application. In this case, new methods of testing will be integrated into the test plan: Security testing (depending on the user s role, access to the data base is granted or denied) Load testing (checking behavior in the event that multiple users access the database at the same time) This is a mere example, but openness towards a constant shift of purpose and methodology is permanently welcome. Risk assessment and mitigation strategy It is highly important that the test plan foresee and include risks that may arise during the development and testing stage. For example, in order to test a more complex functionality, additional testing time is required. The approach and risk prevention strategy could consist in allocating more resources for a short period of time to allow testing as many risk scenarios that may be executed by a user or, alternatively, could mean reducing the number of tests and prioritizing them depending on how they affect the application. Software Quality Days

31 Agile & Testing & Mobile Continuous feedback Perhaps most importantly in order to obtain feedback, a permanent open dialogue needs to be carried between the QA team and the customer. When striving for quality, it is essential that new functionalities or major changes brought to the application be discussed with each individual involved in the project. These modifications have a great impact upon the test plan and quality of the existing product. For this reason, the QA team has to be involved when these decisions are made by the customer or the development team. To support this rule, one could also bring into discussion the idea of testing in the early stages of the project and a high degree of implication on behalf of the testers and the product manager in the quality assurance process. The quality of the product needs to be ensured collaboratively and the development team must, in this sense, be aware of the quality they produce. Conclusions Testing mobile applications will be increasingly dif- ficult with the passing of time, as products become more complex and customers grow more pretentious. Opting for the correct strategy regarding testing types and environments lightens the workload, cuts costs and may help identify possible problems in advance. Perhaps the most important ingredient is not being reluctant towards change and the ability to adapt to an ever-changing purpose. Testing mobile applications has in itself become a challenge since the mobile environment is the most dynamic of its times. Author Rares Irimies I currently work for 3Pillar Global outsourcing company, in Cluj-Napoca, Romania as QA Lead on a network security application. I am involved in several mobile testing projects, providing advice on methods and area of testing, a domain I am passionate about. Phone: Personal rares_irimies@yahoo.com Work rares.irimies@3pillarglobal.com Mit agilen Methoden kommen Sie weiter. NovaTec unterstützt Ihr Unternehmen dabei, die richtige Software für Ihre Endanwender richtig umzusetzen. Von der Auswahl und effizienten Spezifikation geeigneter Features, über den Einsatz richtiger Techniken und Toolings, bis hin zur Prüfung und Gewährleistung der erwünschten Qualität. Wir bringen die Dinge zum Ende - und zum Erfolg! Schulungstermine Agile Requirement Engineering Optimierung Ihrer Spezifikationsprozesse und -schritte mit den hierfür notwendigen Techniken und Werkzeugen Die ein- bis dreitägigen Schulungen können bei Ihnen vor Ort oder in den Räumlichkeiten der NovaTec stattfinden. Gerne passen wir die Inhalte an Ihre individuellen Wünsche an. Agile Testing Leinfelden-Echterdingen Agile Testing Entwicklung und Umsetzung einer zielorientierten Testing Strategie, Auswahl und Umsetzung geeigneter Patterns und Frameworks für die Testautomatisierung, Einführung geeigneter Testautomatisierungstools Specification By Example Leinfelden-Echterdingen Agile Testing Leinfelden-Echterdingen Specification By Example Leinfelden-Echterdingen Agile Quality LifeCycle Effiziente Integration bewährter Techniken und Methoden in Ihr Produkt und Entwicklungs-LifeCycle aqe.novatec-gmbh.de Software Quality Days NovaTec Consulting GmbH Dieselstraße 18/1, Leinfelden-Echterdingen Tel.: Mail: info@novatec-gmbh.de

32 Intuitionsfallen der Projektarbeit Intuitionsfallen der Projektarbeit Ökonomie des Denkens: Fluch und Segen Dieser Vortrag zeigt anhand kleiner Experimente, unterhaltsamer Beispiele und verständlicher Erklärungen, wie und warum wir in Projekten in Denkfallen tappen, die den Projekterfolg in Gefahr bringen. Er macht klar, warum Menschen so oft in Projekten gegen besseres Wissen handeln und ihren Verstand oft mehr dazu nutzen sich und anderen etwas vorzumachen. Es werden Tipps gegeben, wie Projektteams sich vor diesen Intuitionsfallen schützen können. Wenn Sie die perfekte Ausrede für gescheiterte Projekte suchen, dann werden Sie jetzt fündig. Ob Fehleinschätzungen, übersehene Fehler, vernachlässigte Tests, schlampige Dokumentation, alles hat seine Ursache in - Achtung jetzt kommt ein Begriff, den Sie sich unbedingt merken sollten - der Ökonomie des Denkens. Vereinfacht ausgedrückt bedeutet Ökonomie des Denkens folgendes: Wir denken nur nach, wenn es sich lohnt oder wenn wir nichts besseres zu tun haben. Wann lohnt sich Denken für unser Gehirn? Ich meine, so richtig bewusst nachdenken! Es lohnt sich nur dann, wenn wir in eine Situation geraten, die für uns neu ist oder uns vor eine Wahl stellt. UND das Nachdenken muss mit hoher Wahrscheinlichkeit in einer angemessenen Zeit zu einem brauchbaren Ergebnis führen. Andernfalls ist es entweder Energieverschwendung oder Zeitverschwendung. Beides ist unökonomisch. chen kein Erbsenzähler, wenn es um Details geht. Es wäre ja wenig sinnvoll, wenn Sie nur auf rote Autos reagieren, die Ihnen die Vorfahrt nehmen. Es automatisiert alle Abläufe, die sich häufig wiederholen, so dass kein Nachdenken mehr notwendig ist, um sie auszulösen und auszuführen. Die enorme Bedeutung des Spielens von Kindern oder des intensiven Übens wichtiger Abläufe wird vor diesem Hintergrund klar. Es sorgt in brenzligen Situationen dafür, dass erst gar nicht nachgedacht werden kann, indem es mit Hilfe von hormonell gesteuerten Denkblockaden Grübeleien einfach unterbindet. Was nutzt es, wenn auf dem Grabstein steht: Er hat nachgedacht. In vielen gefährlichen Situationen ist es tatsächlich besser, gedankenlos zu überleben als nachdenklich zu sterben. Als Softwareentwickler müssten Ihnen diese Strategien bekannt vorkommen. Um nicht jedes Mal das Rad von neuem Erfinden zu müssen, verwenden Sie Design Patterns. Für häufig wiederkehrende Abläufe bauen Sie sich Funktionen oder Objekte, die Sie mit Hilfe von Variablen flexibel einsetzen können. Wenn ein wichtiges Ereignis auftritt, unterbrechen Sie per Interrupt alles was die Reaktion darauf verzögern könnte. Ökonomie des Denkens Vergegenwärtigen Sie sich kurz, was die wichtigste Eigenschaft einer Reaktion in lebensbedrohlichen Situationen ist, z.b. ein Sturz oder eine gefährliche Verkehrssituation. Es ist das sehr schnelle Abrufen automatisierter Bewegungsabläufe. Da der Faktor Zeit wie kein anderer über Leben und Tod entscheidet, wendet unser Gehirn sehr zielorientierte Strategien an, um Zeit zu sparen. Da Nachdenken eine, wie wir alle wissen, eher gemächliche Angelegenheit ist, spart unser Gehirn gerne an dieser Stelle. Es versucht, so schnell wie möglich herauszufinden, ob sich Nachdenken lohnt, d.h. ob die Situation unbekannt ist oder eine Wahl erfordert. Damit dies funktioniert, obwohl keine Situation der anderen vollständig gleicht, ist unser Oberstüb- Abbildung 1: Ein Softwerker würde den Ablauf, nach dem unser Gehirn entscheidet, ob sich nachdenken lohnt, etwa so visualisieren. Software Quality Days

33 Intuitionsfallen der Projektarbeit Außer Zeit spart unser Gehirn auch gerne Energie. Es verbraucht für sein vergleichsweise kleines Volumen, das bei mir (Größe: 1,90m, Gewicht: geschmeichelte 90 kg) nur etwa 1,5 % meines Körpergewichts ausmacht, etwa 20% der Energie. So gesehen ist die Redensart mir raucht der Kopf vom Denken zwar übertrieben aber keineswegs abwegig. Auch könnte man auf die Idee kommen, durch intensives Grübeln abzuspecken. Auch das funktioniert, wenn man vor allem über seine Ernährungsgewohnheiten nachdenkt. Aber Spaß beiseite. Denken ist ein unglaublich komplizierter Vorgang, der von einer Unzahl von chemischen Prozessen begleitet wird. Die Energie dazu wird in den Zellen aus hochwertigster Glukose und Sauerstoff gewonnen. Da die Menschen über viele Jahrtausende keine Supermärkte hatten und die Beschaffung sehr hochwertiger Nahrung mit großem Aufwand und Risiko verbunden war, war es nicht ratsam, geistige Energie einfach zu verschwenden. Die meisten Softwareentwickler in Deutschland haben zwar derzeit kein Ernährungsbeschaffungsproblem, doch unsere Gene gehen hier auf Nummer sicher. Der Haken So weit so gut. Aber wo Licht ist, ist auch Schatten. Die Sache hat, wie fast alles, nicht nur einen, sondern gleich mehrere Haken: Die Entscheidung, ob sich Nachdenken lohnt, muss notgedrungen fallen, bevor wir bewusst nachdenken können. Unser Verstand kann bestenfalls noch die Notbremse ziehen, wenn ihm noch Zeit bleibt und die Stresshormone nicht bereits zur Denkblockade führen. Viele Automatismen wurden bereits in unserer Kindheit angelegt oder sehr stark von Lebenssituationen geprägt, die mit komplexer Projektarbeit wenig zu tun hatten. Es ist auch möglich, dass über Jahre Methoden und Abläufe perfektioniert wurden, die aufgrund neuer Technologien und Erkenntnisse ihre Bedeutung verloren haben. Die Gefahr, dass ungeeignete Automatismen abgerufen werden, ist allgegenwärtig. Den Stresshormonen ist es egal, ob Sie bergsteigen, Auto fahren oder programmieren. Der Evolution war das Thema komplexe technische Projekte über viele Jahrtausende fremd, und auch bei unserer persönlichen Entwicklung spielte es lange Zeit keine Rolle. Leider gibt es kein Sinnesorgan, das dem Gehirn sagt: Das ist jetzt Projektstress, bleib cool und denke nach. Ein kleines Experiment bei einem ADAC-Sicherheits- training ließ mich diese Zusammenhänge eindrucksvoll erleben. Die Aufgabe lautete: Fahren Sie flott auf ein Hindernis zu und weichen Sie in die Richtung aus, in die der ADAC-Sicherheitstrainer NICHT mit dem Arm zeigt. Meine intuitive Reaktion auf einen Fingerzeig war stärker! Ich habe es mehrfach versucht, doch es ist mir nicht gelungen, den nicht gerade komplexen Denkschritt ich muss anders fahren als er zeigt rechtzeitig zu vollziehen. Mein Trost war, dass es den meisten anderen nicht besser erging. So führt die Ökonomie des Denkens dazu, dass wir in komplexen Projekten gerade unter Zeitdruck Automatismen einsetzen, die uns möglicherweise mehr schaden als nutzen. Haben wir also den perfekten Sündenbock für gescheiterte Projekte gefunden: die Evolution? Nein, so einfach lasse ich Sie nicht davonkommen! Da Sie jetzt gerade keinen Stress haben, denn sonst würden Sie ja meinen Artikel nicht lesen, können Sie das tun, was die Evolution für den Fall wichtiges Problem identifiziert und Zeit vorhanden vorgesehen hat: Sie denken bewusst nach. Ich weiß, dass man sich gerne davor drückt, indem man verzweifelt nach einer neuen Stressquelle sucht. Lassen Sie das mal ausnahmsweise bleiben. Also, was können Sie tun, um diese Nachteile zumindest weitgehend zu vermeiden? Wenn Sie sich Ihre eigenen Gedanken gemacht haben, lesen Sie unter Nachdenkliches zu Projekten, was ich mir gedacht habe. Nachdenkliches zu Projekten Hab ich es mir doch gedacht. Sie haben aus ökonomischen Gründen gleich weitergelesen. Ich zolle meinen Respekt allen, denen ich jetzt Unrecht tue. Zurück zum Thema: Offensichtlich gibt es mehrere Auslöser, die zu ökonomischem Denken mit unökonomischem Projektergebnis führen: Zeitdruck, ungeeignete Automatismen und Stress. Wo liegen nun die tieferen Ursachen für diese Auslöser? Zeitdruck entsteht vor allem durch unrealistische Projektplanung. Eine wichtige Ursache dafür liegt wieder in der Ökonomie des Denkens. Da unser Gehirn automatisch versucht, alle Wahrnehmungen möglichst schnell zu vereinfachen, neigen wir dazu, Komplexität zu unterschätzen. Dies ist besonders bei Softwareprojekten sehr ausgeprägt. Außerdem ist bürokratische Planung vielen Menschen ein Graus. Es ist viel schöner loszulegen, um schnell Erfolgserlebnisse zu erfahren. Software Quality Days

34 Intuitionsfallen der Projektarbeit Unsere Psyche liebt den schnellen Lustgewinn und vermeidet unangenehme Grübeleien. Aufgrund fehlender Routine und verbindlicher Regeln werden uneffektive Automatismen wie Vom-Kopf-in-die-Tastatur-Programmierung oder Läuft-es-passt-es-Tests eingesetzt. Die o.g. Ursachen führen über kurz oder lang zu Projektstress, der wiederum Automatismen begünstigt, die panikartige Reaktionen wie Versteckspielen oder Aggression auslösen. Unpassende Automatismen und Stress schaukeln sich so gegenseitig hoch und führen in einen Teufelskreis. Das Lösungsprinzip Diese Ursachen stoßen uns schon fast mit der Nase auf die Lösung. Da wir die grundsätzliche Funktionsweise des Gehirns nicht verändern können, müssen wir im Projekt geeignete Automatismen einsetzen und dafür sorgen, dass an kritischen Stellen die Zeit zum Nachdenken verfügbar ist und unnötiger Druck vermieden wird. Kurz: Es geht um Lernen, Üben und Projektgestaltung. Die Lösung liegt gerade bei Softwareprojekten darin, der Verführung des Loswurstelns und der überhasteten Implementierung zu widerstehen und sich kompetent, planvoll und geregelt von der Idee zur Lösung vorzutasten. Der Erfolg eines Projekts wird dabei maßgeblich durch folgende Ausgangsbedingungen bestimmt: Eine fundierte Ausbildung, in der intensiv geübt wird, schafft die Basis für sinnvolle Automatismen. Gerade wenn bislang bewährte aber mittlerweile veraltete Methoden oder Prozesse durch neue ersetzt werden, ist intensives Üben unerlässlich, um den Rückfall in alte Denkmuster zu vermeiden. Hier gilt: Das Schwierigste daran, etwas Neues zu lernen, ist das alte zu verlernen. Die übersichtliche Strukturierung der Aufgabenstellung und des zeitlichen Ablaufs macht Nachdenken lohnenswert, weil sinnvolle Ergebnisse in akzeptabler Zeit erreichbar sind. Gutes Projektmanagement und lebbare Prozesse schaffen diese Voraussetzungen. Stop&Think-Punkte sorgen an den Schlüsselstellen des Projektes dafür, dass wirksame Impulse für das lohnende Nachdenken gegeben werden. Die hier durchgeführten Maßnahmen müssen allerdings eine möglichst realistische Einschätzung der Situation unterstützen. Resümee Diese Grundprinzipien des Projekterfolgs sind unabhängig von dem gewählten Prozessmodell. Allerdings wird die Ausprägung und Gestaltung dieser Prinzipien bei jedem Projekt anders aussehen. Die Lösungen sind nichts Neues. Aber vielleicht lohnt es sich, über diese Lösungen unter dem Blickwinkel Ökonomie des Denkens nochmals nachzudenken. Er zeigt uns, dass wir nur dann in Projekten erfolgreich sein können, wenn wir die Besonderheiten menschlichen Denkens und Handelns mit all seinen Vor- und Nachteilen für die Projektarbeit berücksichtigen. Entdecken Sie die menschliche Seite des Projekterfolgs. Literaturverzeichnis Peter Siwon, Die menschliche Seite des Projekterfolgs, dpunkt-verlag 2010 Peter Siwon, Denkanstöße für den Projekterfolg, Vogel Verlag 2008 Autor Peter Siwon Peter Siwon ist Business Development Manager bei der MicroConsult GmbH, die sich auf Training und Consulting für Embedded Software Engineering spezialisiert hat. Außerdem ist er freiberuflicher Trainer, Coach und Autor von Kolumnen und Fachbüchern mit dem Schwerpunkt Die menschliche Seite des Projekterfolgs. Seit 2008 ist er als Lehrbeauftragter an mehreren Hochschulen tätig. Software Quality Days

35 Was machen unsere Anwender eigentlich so? Was machen unsere Anwender eigentlich so? BPMN 2.0 als einfache Modellierungssprache für fachliche Prozesse Software soll den Anwender bei seinen täglichen Abläufen unterstützen. Je besser das Projektteam die fachlichen Prozesse kennt, desto besser kann es die Anforderungen der Anwender umsetzen. Gefragt ist hier eine einfache Methode, wie Geschäftsprozesse strukturiert erhoben und übersichtlich dokumentieren können. BPMN dient dabei als flexible Modellierungssprache, um die Prozesse übersichtlich darzustellen und die zahlreichen Varianten und Unschärfen in den Griff zu bekommen. Die gelieferten Projektergebnisse stimmen oft nicht mit den Bedürfnissen der Anwender überein In vielen Softwareprojekten tritt man an, die Probleme des Anwenders zu lösen und sein Leben leichter zu machen. Leider aber ist das Ergebnis oft weit weg von dem, was die Anwender wirklich gebraucht hätten (siehe Abbildung 1). Anforderungen fehlen, sind unvollständig oder falsch umgesetzt oder die Bedienung ist umständlich. Insgesamt passt die gelieferte Software nicht recht zu den täglichen Abläufen und Problemen der Anwender. Das Resultat ist, dass die Systeme entweder gar nicht eingesetzt werden, oder viele Nacharbeiten und Change Requests notwendig sind, damit die Anwender schlussendlich zumindest irgendwie damit arbeiten können. Ursache für die große Abweichung zwischen dem was geliefert wird und dem was die Anwender gebraucht hätten ist, dass zu wenig bekannt ist, wie die Anwender eigentlich mit der neuen Software arbeiten werden. Das Projektteam weiß oft gar nicht, welche Ziele die Anwender haben, in welchem fachlichen Kontext die neue Software eingebettet ist und daraus abgeleitet, welche Anforderungen sie haben. In den meisten Projekten können die Anwender auch nicht wirklich sagen, was sie brauchen. Sie wissen es schlichtweg selbst nicht. Entscheidend für den Erfolg der Projekte ist hier, dass das Team in der Anforderungsspezifikationsphase die richtigen Fragen stellt und die Anwender zu ihren Anforderungen hinführt. Abbildung 1: Gelieferte Software entspricht nicht den Bedürfnissen des Kunden Je besser das Projektteam den fachlichen Kontext kennt, desto besser wird das Ergebnis sein Dies führt auch schon zur Lösung des Problems. Noch bevor zu Beginn des Projektes die Funktionen des Systems spezifiziert werden, müssen die Ziele der Anwender erhoben werden. Die wichtigste Frage ist hierbei die Frage nach dem Warum?, also nach dem Nutzen, den die Anwender aus dem Einsatz der Software ziehen wollen. Ebenso wichtig ist es, den fachlichen Kontext zu kennen, in dem die Systeme eingesetzt werden sollen. Welche Prozesse bearbeiten unsere Anwender? und Welche Schritte in den Prozessen können wir am besten mit Software unterstützen? sind hier die leitenden Fragen für die Analyse. Je besser das Team den Kontext und die fachliche Welt der Anwender kennt, desto eher ist es in der Lage, die richtigen Fragen zu stellen. Je mehr Wissen über die tägliche Arbeit und die Geschäftsprozesse rund um die Software vorhanden ist, desto besser werden die erhobenen Anforderungen mit den tatsächlichen Bedürfnissen der Anwender übereinstimmen. Dieses Wissen über die Prozesse der Anwender muss strukturiert erhoben und dokumentiert werden. Nur so kann es im weiteren Projektverlauf zielführend eingesetzt werden. Software Quality Days

36 Was machen unsere Anwender eigentlich so? BPMN als flexible neue Sprache zur Modellierung von Geschäftsprozessen Zur Dokumentation von fachlichen Prozessen gibt es viele unterschiedliche Modellierungswerkzeuge und Modellierungssprachen. Eine der neuesten von ihnen ist BPMN (Busines Process Modelling and Notation) [1]. Diese Modellierungssprache wurde als Bindeglied zwischen der fachlichen Welt der Anwender und der technischen Welt der IT geschaffen. Sie bietet gute Möglichkeiten, die flexiblen und oft nicht vollständig strukturierten Abläufe in der täglichen Arbeit der Anwender darstellen zu können. Ebenso bietet sie alle Konzepte, die für eine exakte Modellierung technischer Systemabläufe benötigt werden. Abbildung 2 zeigt ein BPMN Modell eines einfachen Prozesses zur Freigabe eines Artikels. Verschiedene Aufgabentypen, beispielsweise: Allgemeine Aufgabe Senden von Nachrichten Benutzeraufgabe Automatische Skriptaufgabe Verschiedene Verzweigungen, beispielsweise: Allgemeine Exklusives Oder Inklusives Oder Und Komplexe Verzweigung nach Regeln oder Formeln Verschiedene Zwischenereignisse, bei denen ein Prozess auf etwas wartet und erst fortsetzt, wenn das Ereignis eintritt, beispielsweise: Allgemeines Zwischenereignis Warten auf einen Zeitpunkt oder für eine Dauer Warten auf eine Eskalation Warten auf eine Nachricht Abbildung 2: Flexible Modellierung von Geschäftsprozessen mit BPMN Die Stärken von BPMN liegen zum einen in der Möglichkeit, flexible und variantenreiche Prozesse und Prozessteile gut darstellen zu können. Nicht immer sind Abläufe in der fachlichen Welt so klar strukturiert und laufen immer nach demselben Muster ab. Vielfach werden Schritte in anderer Reihenfolge ausgeführt, wiederholt oder gänzlich weggelassen. In BPMN ist all dies übersichtlich und klar darstellbar. BPMN bietet hierfür eine ganze Reihe von Konstrukten an: Verschiedene Startereignisse, die einen Prozess anstoßen, beispielsweise: Allgemeines Start Ereignis Start durch Empfang einer Nachricht Start durch Erreichen eines Zeitpunkts Bedingter Start durch Erfüllung von Regeln Ad-Hoc Unterprozesse, die verschiedene Aufgaben enthalten können. Die Aufgaben im Unterprozess können in beliebiger Reihenfolge beliebig oft ausgeführt oder auch komplett weggelassen werden. Mittlerweile gibt es eine Reihe von guten Werkzeugen für die Erstellung von BPMN Modellen. Das Modell in Abbildung 2 wurde beispielsweise mit dem kostenlosen Tool ARIS Express [2] erstellt. Vorgehensweise bei der Modellierung Die Modellierung von Geschäftsprozessen ist in der Praxis eine sehr anspruchsvolle Aufgabe. Anwender sind oft nicht gewohnt, ihre tägliche Arbeit strukturiert und Schritt für Schritt zu beschreiben. Bittet man als Analyst die Anwender darum, zu beschreiben, wie ihre Prozesse aussehen, so trifft man oft auf Ratlosigkeit. Zu vielfältig scheinen aufs erste die Tätigkeiten, stark zersplittert und mit vielen Ausnahmen versehen. Entsprechend fallen dann auch die Beschreibungen aus, die man erhält: Ich schreibe einfach den Artikel und gebe ihn dann dem Chef zum Prüfen. Außer es ist was ganz dringendes, dann Software Quality Days