Conference Journal 2013

Transkript

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

2 Editor / Herausgeber Software Quality Lab GmbH Gewerbepark Urfahr Linz Austria info@software-quality-lab.com Published by Software Quality Lab GmbH, January 2013 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 Wartung im skalierten agilen Umfeld 5 Ingo Kreienbrink und Andreas Becker Modellbasiertes Testen in der Datenverarbeitung 8 Werner Märkl und Hans-Peter Möller Eliminate and Automate 12 Colin Hood Software Product Management 17 Fritz Stallinger and Robert Neumann Vermitteln Sie Wissen und Werte mit Stories 24 Dr. Andrea Herrmann und Anne Hoffmann Copy & Paste & Bug? 31 Dr. Elmar Jürgens und Dr. Nils Göde Test Data Management in Practice 35 Klaus Haller Advanced JUnit 46 Michael Tamm How to Quantify Quality: Finding Scales of Measure 51 Tom Gilb Requirements Engineering Tools 57 Markus Unterauer From Knowledge to Skills 61

4 14 16 January, Vienna We are pleased to invite you to the Software Quality Days 2014 Practical tracks + Scientific track + Solution Provider Forum Top keynote speakers Lectures Workshops and tutorials HIGHLIGHTS: Tool Challenge Best Quality Tool Award We look forward to welcoming you again in 2014! Register now! registration@software-quality-days.com

5 Wartung im skalierten agilen Umfeld Wartung im skalierten agilen Umfeld Scrum und Kanban müssen sich nicht gegenseitig ausschließen Agile Entwicklung basierend auf Scrum oder Kanban nimmt stark an Bedeutung zu. Das Scrum-Framework wird tendenziell bei der Weiterentwicklung von Software verwendet, Kanban in den meisten Fällen zur Wartung genutzt. In unserem Beitrag haben wir den Fokus auf die Kombination beider agilen Methoden gelegt. Laut Scrum Theorie werden Fehler als Item in das Product Backlog aufgenommen. Fehler und Anforderungen werden nicht explizit unterschieden. Die theoretischen Ansätze haben in der Praxis Vor- und Nachteile, die vor allem bei hohen Altlasten zum Tragen kommen: Wie verhält man sich in der Praxis, wenn eine hohe Fehleranzahl und dadurch eine mangelhafte Qualität der Software vorliegen? Wie verhält sich die Abarbeitung von großen Fehlerbergen auf die Velocity und die Motivation des Teams? Dieser Ansatz hat noch weitere Schwächen, die im folgenden Beitrag näher beleuchtet werden sollen. Einleitung und Vorstellung des Kontexts Unser Kunde aus dem Gesundheitswesen entwickelt Software in einem regulierten Umfeld durch gesetzliche Vorgaben und setzt sich aus einem Zusammenschluss mehrerer gesetzlicher Krankenversicherer zusammen. Dieser Kunde entwickelt und betreibt die wesentlichen Informationssysteme für über 100 Krankenversicherungsunternehmen für ca Anwender zur Verwaltung von ca. 19 Millionen Versicherten. Der bisherige Softwareentwicklungsprozess basiert auf dem Wasserfallmodell und wird im Rahmen eines Projektes durch agile Methoden abgelöst. Neben den Herausforderungen die Organisation umzustellen, das Management von einem ständigen Kontrollzwang abzubringen und die Selbstorganisation und direkte Kommunikation zwischen den Beteiligten zur etablieren, hat sich aus der Zeit vor der Umstellung zur agilen Entwicklung einer hoher Fehlerbestand angesammelt, der kontinuierlich abgebaut werden muss. Dazu kommen neue Fehler, die behoben werden müssen. In diesem Artikel wollen wir die Kombination aus Scrum und Kanban vorstellen, um die Vorteile der agilen Weiterentwicklung zu nutzen und gleichzeitig die Wartung nicht zu vernachlässigen. Theoretische Ansätze Im Folgenden werden die verschiedenen Ansätze aus der Literatur bzw. aus dem Scrum Guide betrachtet und vorgestellt. Fehler als Items in das Product Backlog Im Scrum Guide von Ken Schwaber und Jeff Sutherland [SS11] werden Fehler als Item in das Product Backlog aufgenommen. Fehler und Anforderungen werden nicht explizit unterschieden. Eine Anforderung im Product Backlog wird allerdings vor einer geplanten Umsetzung geschätzt und priorisiert, anders als ein Fehler. Diese ungeplant auftretenden Fehler müssen trotzdem beseitigt werden, da sie sonst zu ungewollten Fehlerbergen anwachsen können. Einen Fehler zu schätzen kann ein Team häufig ohne eine Voranalyse nicht leisten. Eine Schätzung würde außerdem dem Prinzip der technischen Schuld widersprechen, da ein Team Storypoints einkassiert, welche es bei der Umsetzung von der Anforderung schon bekommen hat. Ohne Schätzung kann ein Product Owner allerdings keine plausiblen Aussagen anhand der Teamvelocity treffen. Abb. 1: Fehler als Items in das Backlog einfügen Fehler an User Storys anhängen Ein alternatives Vorgehen nach [Wir11] sieht vor, Fehler an User Stories anzuhängen. Dieses Vorgehen hat den Vorteil, dass Fehler nicht geschätzt werden müssen und trotzdem eine Priorität vorgegeben ist. Es wird eine konstante Anzahl von Fehlern pro Sprint abgearbeitet und eine User Story ist erst fertig, wenn auch die daran hängenden Fehler erledigt worden sind. Der wesentliche Nachteil dieses Vorge- Software Quality Days

6 Wartung im skalierten agilen Umfeld Abb. 2: Fehler an User Storys anhängen hens ist, das der Product Owner sehr häufig in Erklärungsnot kommen wird, warum ein bestimmter Fehler an einer User Story hängt und warum diese nicht ohne diesen Fehler auch fertig sein kann. Vor- bzw. Nachteile beiden Methoden Beide Vorgehen haben in der Praxis Vor- und Nachteile, die vor allem bei hohen Altlasten zum Tragen kommen. Wie verhält man sich in der Praxis, wenn eine hohe Fehleranzahl und dadurch eine mangelhafte Qualität der Software vorliegen? Akzeptanz in der Praxis durch die Teams Wie verhält sich die Abarbeitung von großen Fehlerbergen auf die Velocity und die Motivation des Teams? Das Problem mit den Fehlern Wartung benötigt kurze Planungszeiträume, denn die entstehenden Fehlertickets von Kunden, nachgelagerten Teststufen oder anderen Teams müssen ggf. unmittelbar beseitigt werden und können nicht das Sprintende abwarten, um entsprechend eingeplant zu werden. Während User Stories geschätzt werden müssen, um dem Product Owner di e Möglichkeit der Planung und Priorisierung zu geben, müssen Fehler im Allgemeinen nicht geschätzt werden, sondern müssen anhand ihrer Kritikalität und Dringlichkeit abgearbeitet werden. Was heißt Kanban in diesem Umfeld? Kanban bedeutet in unserem Zusammenhang, dass der Prozess zum kontinuierlichen Fehlerabbau an einem Kanban-Board visualisiert wird und nach dem Ansatz folgt nur was man sehen kann, kann auch verbessert werden. Durch diese Visualisierung werden Engpässe und Blockierungen unmittelbar sichtbar. Die Menge an aktuell zu behebenden Fehlern werden durch Limits begrenzt, damit die parallel durchgeführte Arbeit begrenzt wird und fokussiert an den wichtigen Elementen gearbeitet und Arbeitsschritte abgeschlossen werden, bevor neue begonnen werden. Die durchschnittliche Zeit, um ein Element - in unserem Fall ein Fehlerticket fertigzustellen, wird gemessen. Der Prozess wird so optimiert, dass diese Durchlaufzeit so kurz und vorhersagbar wie möglich wird. Die zu behebenden Fehlern werden nicht im Voraus fest eingeplant, sondern richten sich nach der Schwere eines Fehlern und die Priorisierung der Behebung wird durch die Rangfolge am Kanban-Board sichtbar. Der visualisierte Prozess kann im Fall der Wartung sehr einfach gehalten werden und kann beispielsweise nur aus den Arbeitsschritten - und damit die Spaltenbezeichnungen am Kanban-Board - to do, doing und done bestehen. Kanban sieht keine Rollen vor, die mit Scrum vergleichbar sind. Es hat sich in unserem Umfeld aber bewährt einen BoardMaster zu benennen, der in Analogie zu Scrum besprechende Aufgaben übernimmt überwacht den Prozess, moderiert Meetings, schützt das Team oder den Entwickler vor Aufgaben, die nichts mit Wartung zu tun haben, coacht das Team und räumt Hindernisse aus dem Weg. Sprints sind in Kanban nicht vorgeschrieben, daher gibt die übergeordnete Releaseplanung die Taktung auch für Kanban vor, um die Fehlerbehebungen mit der Weiterentwicklung integrieren zu können. Der Nachschub an Fehlern wird über eine priorisierte und in eine Rangfolge gebrachtes Fehlerbacklog geregelt, für das auch der Product Owner verantwortlich ist. Lösungsansätze Scrum und Kanban mit verschiedenen Teams Weiterentwicklung und Wartung von einem Produkt kann durch die Trennung eines größeren Teams durchgeführt werden. Ein oder mehrere Weiterentwicklungsteams, die nach der agilen Methode Scrum neue Funktionalitäten umsetzen und ein Wartungsteam, das nach Kanban arbeitet und neue entdeckte Fehler und ggf. Altbestände an Fehler behebt, die noch aus der Zeit vor der Umstellung auf agile Methoden stammen. Bei dieser Vorgehensweise stehen die kritischsten Fehler mit der höchsten Priorität am Kanban-Board an oberster Stelle und werden anhand dieser Kritikalität behoben. Software Quality Days

7 Wartung im skalierten agilen Umfeld Scrum und Kanban in einem Team Um Weiterentwicklung und Wartung zu kombinieren, besteht die Möglichkeit eine oder mehrere Entwickler, je nach Größe des Teams und der abzuarbeitenden Fehler, von der Kapazität eines Scrum-Teams abzuziehen und innerhalb eines Sprint im Kanban- Modus die Wartung übernehmen zu lassen. Dies kann von Sprint zu Sprint in einem festen rotierenden Verfahren erfolgen, so dass jedes Teammitglied regelmäßig für die Fehlerbehebung verantwortlich ist. Eine weitere Möglichkeit besteht darin, im Sprint den Entwickler mit dem größten Know-How zur anstehenden Fehlerbeseitigung in den Kanban- Modus wechseln zu lassen. Die Sprintplanung muss dabei berücksichtigen, dass die Kapazität von einem Entwickler nicht zur Verfügung steht. Dies ist dann nicht an eine Person gebunden sein, sondern an eine Rolle, die von verschiedenen Entwicklern aber immer nur von der vorher fest definierten Anzahl von Entwicklern übernommen wird. Auch bei dieser Vorgehensweise stehen die kritischsten Fehler mit der höchsten Priorität am Kanban-Board an oberster Stelle und werden zeitnah behoben. Alternative: Wartung im Scrum-Team ohne Kanban Kommt die Kombination aus Scrum und Kanban nicht in Betracht, kann die Wartung auch weiterhin im Scrum-Team durchgeführt werden. Dies ist z.b. dann sinnvoll, wenn das Entwicklungsteam aus wenigen Entwicklern besteht oder die Anzahl an zu behebenden Fehlern gering ist. Board Scrum, Fastlane und Kanban Da agile Teams i.d.r. mit Boards arbeiten, kann das Scrum Board auch mit Kanban kombiniert werden. In Abb. 3 wird ersichtlich, dass zwischen der Weiterentwicklung im Scrum-Modus, der Bearbeitung von kritischen Fehlern mittels Fastlane und dem kontinuierlichen Abbau von Fehlern z.b. aus den Altbeständen vor der Umstellung auf Scrum, erfolgen kann. Fazit Scrum ist eine agile Methode, die sich für die Softwareweiterentwicklung hervorragend eignet. In einem Umfeld, indem nicht nur Weiterentwicklung erfolgt, sondern auch Wartungsaspekte berücksichtigt werden müssen, kann die Kombination aus Kanban und Scrum zum Erfolg führen. Die Integration mit Kanban gleicht die Unsicherheit der Sprintplanung aus, stabilisiert die Velocity und gewährleistet trotzdem einen kontinuierlichen Fehlerabbau. Literaturverzeichnis [Wir11] Scrum mit User Stories, Ralf Wirdemann, Hanser Verlag, 2. Auflage, 2011 [SS11] The Official Scrum Rulebook, Ken Schwaber and Jeff Sutherland, Die Autoren Ingo Kreienbrink (Diplom Informatiker) Ingo Kreienbrink ist Senior Consultant im Ressort Consulting der Line of Business Health der adesso AG, einem der führenden unabhängigen IT-Dienstleister im deutschsprachigen Raum. Die adesso AG konzentriert sich dabei mit Beratung sowie individueller Softwareentwicklung auf die Kerngeschäftsprozesse von Unternehmen. Herr Kreienbrink hat langjährige Erfahrung in der agilen Softwareentwicklung unter anderem in der Rolle des Scrum Product Owners. ingo.kreienbrink@adesso.de Andreas Becker (Dipl.-Wi.-Ing. & BA in C.S.) Andreas Becker beschäftigt bei der Firma HOOD GmbH ist als Senior Consultant, Coach und Lehrbeauftragter für agile und klassische Software-Entwicklung tätig. andreas.becker@hood-group.com Abb. 3: Scrum Board kombiniert mit Kanban und Fastlane Software Quality Days

8 Modellbasiertes Testen in der Datenverarbeitung Modellbasiertes Testen in der Datenverarbeitung Die Durchführung und Auswertung von Testfällen mit Hilfe von Modellen automatisieren. Viele Manager beklagen die ihrer Meinung nach zu hohen Aufwände beim Test einer Software in Relation zu den Gesamtkosten eines Projektes. Andererseits wollen Sie auf Qualität nicht verzichten, denn unentdeckte Fehler können zu noch viel höheren Kosten führen. Dieser Beitrag stellt eine Lösung vor, die die Kosten der Testdurchführung stark reduziert und nebenbei positive Auswirkungen auf die Qualität hat. Die Methode hat sich bereits mehrfach in der Praxis bewährt und kann in vielen Projekten eingesetzt werden, in denen Daten verarbeitet werden. Das Thema modellbasiertes Testen (MBT) hat viele Facetten und das Thema ringt noch um eine allseits akzeptierte Definition. Viele Definitionen legen den Schwerpunkt auf die frühen Phasen im Test: Modellbasiertes Testen (MBT) ist ein Oberbegriff für die Nutzung von Modellen zur Automatisierung von Testaktivitäten Generierung von Testartefakten im Testprozess. Darunter fällt insbesondere die Generierung von Testfällen aus Modellen (z.b. unter Verwendung der UML), die das Sollverhalten des zu testenden Systems beschreiben. (Quelle: Wikipedia) Die Generierung von Testartefakten stellt einen Teilaspekt von MBT dar. Die maschinelle Erzeugung von Testfällen und/oder Testdaten aus einem fachlichen Modell heraus trägt zu einer effizienteren Automatisierung in der Testvorbereitung bei. Der größte Nutzen von MBT besteht in der Möglichkeit, die sich ständig wiederholende Testdurchführung hochgradig automatisieren zu können. Bevor wir die konkrete Vorgehensweise an einem Praxisprojekt Schritt für Schritt erläutern, empfiehlt sich zuerst der Blick auf das große Bild. Modellbasiertes Testen Das große Bild Die folgende Grafik eignet sich sehr gut, die Einbettung von MBT in den Entwicklungsprozess von Software darzustellen und zu erläutern. Es handelt sich dabei um eine für technische Systeme modifizierte Form des sogenannten wissenschaftlichen Erkenntnisprozesses, der sich in den empirischen Wissenschaften seit Jahrhunderten bewährt. Der wissenschaftliche Erkenntnisprozess setzt allerdings ein reales System voraus (z.b. Planetenbahnen, Atomkerne etc.). Daher beschreibt die Abbildung ein analoges Vorgehen für Systeme, die erst noch entwickelt und aufgebaut werden sollen. Solche Systeme können z.b. ein Aufzug in einem Hochhaus oder ein Softwareprogramm sein. (Abb.1) Anforderungen Alle Eigenschaften, die das technische System am Schluss besitzen soll, müssen zu Beginn möglichst präzise vorliegen. Das Requirements Engineneering sammelt und spezifizert alle funktionalen und nicht funktionalen Anforderungen. Konstruktionsplan Der Konstruktionsplan muss so vollständig sein, dass sich aus diesen Angaben das technische System eindeutig aufbauen lässt. Technisches System Das aufgebaute System wird üblicherweise in ein umgebendes System integriert. Sobald das aufgebaute System innerhalb einer Systemumgebung lauffähig ist, können an diesem System Experimente durchgeführt werden. Das System wird über Impulse angeregt und reagiert entsprechend. Systemdaten Durch Experimente am technischen System lassen Software Quality Days

9 Modellbasiertes Testen in der Datenverarbeitung Abb. 1: Modellierung technischer Systeme sich Input-/Output-Zusammenhänge gewinnen. Die Systemdaten eines technischen Systems dienen in der Folge dazu, das Systemverhalten mit den gestellten Anforderungen zu vergleichen. Stimmt das anhand der Systemdaten ermittelte Systemverhalten nicht mit den Anforderungen überein, sind Anpassungen am Konstruktionsplan oder beim Aufbau des technischen Systems vorzunehmen. Diese iterativen Veränderungen am technischen System und das wiederholte Testen des Systems sind sehr kostenintensiv und verzögern die Freigabe. Modellbasiertes Testen ist eine demgegenüber deutlich vorteilhaftere Vorgehensweise! Das MBT ist im Diagramm grün hervorgehoben. Abstraktes Modell Ausgehend von dem Konstruktionsplan basiert das Vorgehen auf einem abstrakten Modell. Wie alle Modelle entsteht auch dieses durch Abstraktion und Idealisierung. Das abstrakte Modell ist ein vereinfachter Konstruktionsplan. Simulationsmodell (Referenzimplementierung) Das abstrakte Modell dient als Vorlage für den Aufbau eines Simulationsmodell. Der Begriff eines Simulationsmodells stammt aus dem wissenschaftlichen Erkenntnisprozess und sollte im Kontekt von MBT besser Referenzimplementierung heißen. Die Verifikation stellt sicher, ob das Simulationsmodell fehlerfrei aus dem abstrakten Modell entstanden ist. Modelldaten Die Referenzimplementierung ist ein lauffähiges Simulationsmodell. Das Verhalten des Modells ergibt sich aus dem durch Experimente gewonnenem Antwortverhalten. Die Validierung eines Modells kann nur durch einen Abgleich zwischen Systemdaten und Modelldaten erfolgen. Sofern das abstrakte Modell aus mathematischen Formeln oder Gleichungen besteht, ermöglicht die Deduktion direkt eine analytische Ermittlung der Modelldaten (eher selten). Einsatzmöglichkeiten Modellbasiertes Testen kann in grundsätzlich zwei verschiedene Szenarien zum Einsatz kommen. Software Quality Days

10 Modellbasiertes Testen in der Datenverarbeitung Szenario A: Das technische System ist noch nicht aufgebaut. Das technische System befindet sich in der Planung, existiert aber noch nicht. Daher stehen auch keine Systemdaten zur Verfügung. Ein Fachmann muss die Modelldaten mit den Anforderungen vergleichen und plausibilisieren. Wenn die Modelldaten zeigen, dass nicht alle Anforderungen erfüllt sind, sind Änderungen am Konstruktionsplan oder am abstrakten Modell durchzuführen. Sobald ein Fachmann die Korrektheit des Modells bestätigt, kann mit dem Aufbau des technischen Systems begonnen werden. Sobald das technische System einsatzfähig ist, kommt zusätzlich Szenario B für die Testautomatisierung zum Einsatz. Szenario B: Das technische System exisitert bereits Das technische System ist vorhanden und steht für Experimente zur Ermittlung von Systemdatem bereit. Die Modelldaten aus dem Simulationsmodell stellen das Soll-Verhalten für das technische System dar. Die gleichen Experimente (gleicher Anreiz) können parallel auf dem technischen System und dem Simulationsmodell durchgeführt werden. Für jedes durchgeführte Experiment (=Test) müssen Systemdaten und Modelldaten übereinstimmen, es sei denn das technische System ist falsch oder unvollständig. Da das abstrakte Modell durch Idealisierung und Abstraktion eine Vereinfachung darstellt, sind tolerierbare Abweichungen zwischen System- und Modelldaten innerhalb eines bestimmten Intervalls zu berücksichtigen. Die im Diagramm dargestellte Modellierung technischer Systeme ist sehr gut auf die IT Branche anwendbar. Das folgende Beispiel wird das bestätigen. Praxisbeispiel: Abgeltungsteuer Die Umsetzung der ab 2009 geltenden neuen Gesetzgebung zur Abgeltung von Kapitalerträgen brachte viele Änderungen in den Prozessen der Geschäftsvorgangsbehandlung und im Berichtswesen der Banken mit sich. Die manuelle Überprüfung der Jahressteuerbescheinigungen und Erträgnisaufstellungen hätte jeden Zeit- und Kostenrahmen gesprengt. Die IT setzte die gemäß Fachkonzept (Word) geforderten Anforderungen in der Programmiersprache Cobol um und stellte das Programm nach jedem Än- derungszyklus auf einer Testumgebung bereit (Szenario B). Als Testdaten für die ca. 500 Testfälle kamen jeweils produktionsnahe, anonymisierte Daten zum Einsatz. Im verwendeten Testmanagementsystem waren den Testfällen keine erwarteten Ergebnisse zugeordnet. Es war daher essientiell, dass A. das Simulationsmodell (=Referenzimplementierung) das erwartete Ergebnis ( Soll ) berechnen kann. B. die Fachabteilung dem Soll-Ergebnis vertraut. Regelwerke Das MBT-Team hat in einem ersten Schritt das Fachkonzept in eindeutige Regeln übersetzt. In einer Excel Arbeitsmappe standen nach mehreren Iterationen mit der Fachabteilung alle funktionalen Anforderungen als Regeln der Form Wenn -> Dann zur Verfügung. Das abstrakte Modell, bestehend aus insgesamt knapp 200 solcher Regeln, stand nach 4 Wochen fest und ermöglichte es einer Standardsoftware (=Simulationsmodell) für einzelne Kunden die Beträge auf einer Jahresteuerbescheinigung oder Erträgnisaufstellung zu ermitteln ( Soll ). Da die Standardsoftware als Businesslogik ausschließlich die Regelwerke heranzog, spielte die Verifikation in diesem konkreten Beispiel keine Rolle. Über eine Verprobung (Validierung) von sehr vielen Modelldaten stellte sich jedoch heraus, dass das mit der Fachabteilung ausgearbeitete abstrakte Modell nicht fehlerfrei war. Dies machte Änderungen am Regelwerk erforderlich. Meistens war davon auch das Fachkonzept (Word) selbst betroffen, was die Cobol- Programmierer dann parallel für Änderungen zum Anlass nahmen. In regelmässigen Abständen wurde das gesamte Testfallportfolio automatisiert getestet. Die dafür benötigte Zeit und die Kosten gingen sofort dramatisch zurück. Die Anzahl der Defekte reduzierte sich jedoch nur langsam und die Regressionsfehler häuften sich. Das Managment hat daraufhin beschlossen, die von der Fachabteilung abgenommenen Regelwerke als verbindliche Vorgabe für die IT zu machen (Szenario A). Die eindeutigen Regeln konnten von den Cobol- Programmierern sehr effizient umgesetzt werden, da diese keinen Spielraum für Interpretationen zuliessen. Innerhalb von nur einer Kalenderwoche waren alle Testfälle passed und keine Defekte mehr offen, die sich auf die Ermittlung der Beträge bezogen. Das Projekt Abgeltungsteuer befindet sich nun bereits im vierten Jahr der Entwicklung. Der erfolgreiche Einsatz von MBT hat dazu geführt, dass das Software Quality Days

11 Modellbasiertes Testen in der Datenverarbeitung abstrakte Modell für die Ermittlung der Beträge zum festen Bestandteil des Kontruktionsplanes wurde (Szenario A). Dadurch sinken seitdem nicht nur die Kosten für den Test sondern auch die Kosten in der Entwicklung. Vorteile durch MBT MBT findet Fehler im Konstruktionsplan noch bevor die technische Umsetzung beginnt (Szenario A) Die Referenzlösung lässt sich viel einfacher nachjustieren und die Kommunikation mit dem Fachbereich ist mit Modellen einfacher zu bewerkstelligen als das mit dem Zeigen von Programmzeilen in einer Programmiersprache der Fall wäre. Die Referenzlösung kann von einem Fachmann sehr effizient validiert werden. Die Testdaten führen schnell und ohne Umwege zu protoypischen Ergebnissen. Testdaten können aus dem Modell generiert werden oder alternativ aus der systematischen Testfallfallermittlung verwendet werden. Die Umsetzung der Software auf Basis eines validierten Konstruktionsplanes führt zwangsläufig zu weniger Fehlern in der zu erstellenden Software. Sobald die Software im Einsatz ist, kann diese hochgradig automatisiert getestet werden. Die Referenzimplementierung fungiert dabei als absolut zuverlässiges Testorakel in der Testdurchführung und Testauswertung. Eine hohe Softwarequalität wird mit geringerem Aufwand dauerhaft sichergestellt. Die Autoren Dipl.-Inf. Werner Märkl Werner Märkl ist Geschäftsführer der FI- NARIS GmbH ( und Produktmanager für die RapidRep Test Suite ( Seit mehr als 10 Jahren ist er beratend tätig in Projekten der Finanzbranche. Seine fachlichen Schwerpunkte sind das Kreditrisiko und das Meldewesen. Technische Schwerpunkte sind Datenbanken und Testautomatisierung. Dipl.-Kfm. Hans-Peter Möller Hans-Peter Möller leitet in der Deka- Bank die Einheit IT-Management Kredit & Konzernrisiko und ist zertifizierter Senior Projektmanager (IPMA Level B). Seit mehr als 10 Jahren leitet er Großprojekte in Banken. Sein fachlicher Schwerpunkt ist die Banksteuerung aus ökonomischer und regulatorischer Sicht. Technische Schwerpunkte sind In-Memory-Computing und Testautomatisierung. Fazit Model Based Testing wird den Softwareentwicklungsprozess maßgeblich beeinflussen, denn die sich daraus ergebenden Vorteile sind unübersehbar. Die FINARIS GmbH hat mit Hilfe der RapidRep Test Suite bereits in mehreren Projekten den Kundennutzen, den MBT mit sich bringt, sehr erfolgreich unter Beweis gestellt. Damit hat MBT aus unserer Sicht den Hype Status längst verlassen. Software Quality Days

12 Eliminate and Automate Eliminate and Automate How to save time and effort when developing requirements The presentation shows how to save time and money by eliminating work that is often done but is not necessary, and by automating work that is necessary when specifying requirements for embedded software and electronics systems. We cannot master complexity, we must avoid it. Henning Butz 2011 To increase quality, do as little as possible and as much as necessary. Colin Hood 1989 Everything should be as simple as possible, but not simpler. Albert Einstein Any intelligent fool can make things bigger and more complex It takes a touch of genius, and a lot of courage to move in the opposite direction. Albert Einstein Aims To suggest and explain some ways to save time and increase quality when producing specifications. To make some people a little uncomfortable so they might think beyond their normal boundaries. The reader is referred to the introduction of this paper which is written to remind us to keep an open mind. Introduction Structure of this Document Chapter 1 defines the aims of this paper. Chapter 2 explains how this document is structured, and the importance of keeping an open mind to consider some radical ideas that have been proved in real projects. Chapter 3 considers writing textual requirements, and how some tasks can be automated or even eliminated. Chapter 4 considers traceability. The paper considers how some tasks to achieve traceability can be automated. The question is posed whether traceability could be eliminated? Original Work The advice contained in this paper is not copied from work done by others, but based upon many projects where the real savings have been documented. Due to the nature of the author s work, these projects are secret and cannot be referenced. The main direction given in this paper is to reduce the amount of work needed in creation of, and more particularly, in maintaining requirements specifications. This is to be achieved by no longer doing some things we may previously have thought necessary, and to automate those things we need to do to reduce effort and increase accuracy. Opening our Minds In order to do this we have to humble ourselves, and realise that there is much more information that we do not yet know. An observed affect in learning is that we start out by realising that the subject is large and we know just a small black corner of the whole. This is represented by the left square below. Over time we learn and more of the area becomes known and understood, represented above by the increasing area of black as we progress from left to right over time. Eventually our knowledge (the black) covers almost all of the entire subject area (blue), until just a small corner is left for us to master. But as we progress and we investigate the last details, we realise that the subject area we perceived earlier, is in fact just a small corner of the real extent of the subject area. So we start again from the small corner of what we now realise is a larger area. Software Quality Days

13 Eliminate and Automate Writing Textual Requirements Introduction to Writing Textual Requirements This chapter considers first how we can save money and improve quality by automating some tasks to write textual requirements, and then considers how we might avoid writing some requirements to save even more money and avoid mistakes. Automating Writing Requirements Text The intention here is not to create requirements out of nothing, but to automate some manual tasks, such as checking, ensuring good sentence construction, and converting information from one form to another. Supporting Writing of Template Based Textual Requirements: lessons learned from the last 30 years These ideas are not new. There has been major development over the last thirty years. For instance, in 1979 I worked with a design and development department to create a domain specific language with which to programme control systems in a more comfortable way than assembler code. Although the specifications could easily be read like a specification, it needed skilled programmers to create. In 1985 I and others produced a human readable specification which was so formal that code could be generated directly from the specification. Technically the project was a great success but we failed to create an environment which benefited those who used it. In 1993 a language was created for specifying the behaviour of washing machines. This language was easily used and reduced software development time from about one hundred man-weeks to about twenty man-weeks. However, following the initial euphoria developers wondered why they had not been working to such a level of productivity. This created negative psychological feelings and had a disruptive effect. In 1998 Richard Stevens templates for writing requirements were implemented in DOORS. As in 1985, only syntactically correct sentences could be created. Unfortunately what this attempt also had in common with those over the preceding twenty years was the lack of widespread user acceptance due to lack of appreciation of the human factors involved. In 2008 a movement started within one organisation to try to overcome the difficulties in producing a consistent and correct requirements specification. The main difference with this attempt at writing requirements based upon automated templates was the time taken to support users in seeing the benefits. Summary: Using Templates The practice of using templates to specify requirements has been around for over thirty years. The major obstacle to using this technique successfully is introducing the idea in a way acceptable to those who have to use it. Automatically Producing Requirements Text from Diagrams Since 1985, CASE tools (Computer Aided Software Engineering tools) have had the function to produce a textual description directly from a diagram. For years this has been used as the basis for a structure for producing software manually. More recently software has been produced automatically directly from diagrams. So it is a small step to expect a diagram that is used to specify required behaviour, to automatically produce textual requirements from specifications represented as diagrams. Automatically Producing Requirements Text from Tables Tables such as State Transition Tables and Truth Tables provide some advantages over diagrams, in that they provide a great basis for helping to create a specification that considers all combinations of various possibilities. Because the tables are regular and use little text, they are easy and fast to produce, they are easy and fast to check, but sometimes do not provide such an easy to understand overview as a diagram sometimes can. Because the tables are so regular, by following simple rules each table can easily be converted into a set of textual descriptions. This can be automated to produce textual requirements with high quality. Summary: Automating Writing Requirements Text This paper does not propose the automation of requirements creation, rather the automation of tasks that are manual and prone to error. Requirements can be translated automatically from one form to another. Requirements text can be created by translating information from a database or set of diagrams. By automating a task the output should have a high and reproducible quality. However this does not assure that the content is correct, we still need the inspiration of humans. Software Quality Days

14 Eliminate and Automate Eliminating Writing Textual Requirements Another way to improve requirements specifications is to avoid writing requirements. Do as little as possible, and as much as necessary. I do not intend to upset anyone although this paper is deliberately not following the received wisdom. I merely intend to make some people a little uncomfortable so they might think beyond their normal boundaries. Roles Some projects organise the distribution of work only on traditional roles such as System Architect and System Analyst. This leads people to wait for each other; they either say I do not know what to do, as they wait for the specification at the previous level to be approved, or they do not wait and just write whatever they guess is correct so all levels of specification are produced at the same time with no traceability or relation with each other. Level 1: Customer Requirements The purpose of Customer Requirements is to communicate the wishes of a variety of stakeholders to a variety of potential suppliers. There are no hardand-fast rules about how much or how little the specification can constrain the solution. Just do not constrain more than necessary. In the automotive industry, by the time the contract is awarded many design decisions have been made and the customer requirements define a solution that the customer wants to buy. This solution is often the result of a lot of work done by the customer and supplier together. I do know that some of you reading this will be throwing your hands in the air at the thought of this. But do not fret. If the customer does the systems engineering work this does not make it incorrect. In the automotive industry customers and suppliers have a close working relationship over many years. Normally the customer requirements specification is in fact a systems requirements specification that is proved and improved by use of prototypes and cooperation between customer and suppliers. Other industries work differently. Some industries are combative and some are cooperative. Level 2: System Requirements The purpose of system requirements specification is to specify all requirements that a supplier is committing to supply. This is used both by a customer to accept or reject an offer, and also by the development team as a definite specification of what is to be supplied. By introducing the idea of Function Owner (see diagram above), we agree and allocate responsibility to people or teams of people for specifying and implementing functions across all levels of the information model. This is more efficient as no-one is waiting for each other. It is more efficient as the Function Owner is likely to stop creating requirements as soon as they are fit-for-purpose. The Chief Requirements Engineer is responsible for the complete left-hand side of the V model. The Chief Requirements Engineer will ensure that the specification of requirements and design will be done in a consistent way with minimal repetition of requirements. Requirements Fit for Purpose Concentrate on why we produce requirements specifications at different levels. Do not just blindly do things out of habit. Level 3: System Architecture The purpose of the system architecture is to produce a set of specifications for the parts of the system that taken together will satisfy the system requirements. In many cases the work needed to be done by the system architect is to allocate the system requirements to parts of the system, and to define interfaces between the parts of the system. Level 4: Sub-system Requirements (for instance software requirements) The main difference between level 3 sub-system specifications and the level 4 sub-system specifications is the commitment to supply by the sub-system suppliers. Level 5: Sub-system Architecture (for instance software architecture) The purpose of the sub-system architecture is to produce a set of specifications for the parts of the Software Quality Days

15 Eliminate and Automate sub-system that taken together will satisfy the subsystem requirements. In many cases the work needed to be done by the sub-system architect is to allocate the sub-system requirements to parts of the sub-system, and to define interfaces between the parts of the sub-system. Parts of the sub-system could be, for instance, software modules in the case that the sub-system under consideration is software. Summary: Eliminating Writing Textual Requirements Very often the requirements do not need to vary from one level to another, but the interfaces do because the scope does i.e. system, sub-system, component. At the Customer Requirements level the interface could be a definition of pins on the plug of an electronic control unit. The pins are allocated, for instance as inputs from buttons, and outputs to motors. As we move down the levels we need to specify the pins of the microcontroller that are the interface from the electronics to the software. At a lower level the Software Module Design needs to know which parameters or variables are used to represent the states of the buttons and the states of the motors. But the requirement text does not need to change so long as the interfaces for each level are clearly defined. Due to lack of application of the simple concept of Fit-for-purpose, many requirements are changed unnecessarily because some people think they have to do something. Using simple database solutions to specify requirements, many requirements can be written once and displayed more than once. In the above diagram the sections labelled Customer Requirements, and System Interface represent information supplied by the customer. All other areas represent information that has to be created during the development of the various specifications that describe the product. Traceability Introduction to Traceability Traceability is the ability to track requirements and related information across a network of dependencies. Although creating the possibility to do this takes a lot of time, money, and introduces errors, it is necessary to be able to follow requirements in order to judge the completeness and correctness of requirements; the cost, time, effort, and risk of making changes; how much re-testing is necessary; and also the level of process conformity. Eliminating Traceability One organisation does not trust documented traceability because in their experience it was always imperfect and the users did not know where the mistakes were. They chose to use meaningful names, keep a stable team of developers, and rely on the memories of their highly trained people. So far this works well, and certainly better than their previous attempts at traditional documentation of dependencies. The main risks associated with this strategy would appear to be: the time taken for a new person to be able to work in the team without support is longer than would be the case if people had documented dependencies; the system does not scale well; that is a team cannot successfully grow quickly; the effects of changes can apparently not be calculated; and assessors might not look favourably on such a a system. But in practice the system works well with small systems and small teams. So perhaps one solution is to split large systems into small systems, and large teams into small teams? This idea is not new, and it does work. And the risk that it might take a long time to be able to understand the system of meaningful names also appears not to be a problem in practice. Consider the scopes of each Feature Owner to be like a small project. Look at the statistics e.g. the Standish Group Chaos Report, that show the relative success of large verses small system development, and large verses small teams. The organisation in question considers that the benefits of their approach outweigh any disadvantages. Automating Traceability Many people document dependencies manually, for instance in DOORS by creating a link, or documenting a reference in an attribute. What about the possibility of creating this documentation automatically? This automation will obviously save time, but does it save effort and produce quality documentation? Software Quality Days

16 Eliminate and Automate Traceability via Name One example is the dependencies between requirements and interface information. For every 1000 requirements in embedded electronics development we will need to reference an interface or item of data around 50% of the time (statistic from many practical projects). By carefully ensuring that we use standardised names, we can follow the dependencies by hand between the requirement and the definition of the data being referenced. The automation is there, for instance, to create a link from the data written by the requirements author in the requirement, and the definition of the data. We call this traceability via name, as the name used is the key to the traceability. Traceability via Object Another method of documenting dependencies between levels of requirements is to use exactly the same requirement on various levels. Take a simplified example of the need to open a window in a car: When the open window button is pressed and the ignition is on, the window opens for maximum 4 seconds. This requirement can be found at all levels from customer requirement, through the system levels, to software requirement as input to design. Many people write this requirement many times, each time a little differently, in the mistaken belief that it is necessary. With a modern requirements management tool we can classify this requirement as valid for various levels and produce documentation using views of the database. The requirement is written once and displayed many times. We call this traceability via object, as the object used is the key to the traceability. Traceability via Reference We can reference another piece of information by making a note of its identity, perhaps in an attribute. This method is one of the oldest. In the days of large leather bound volumes of information there was a column for this information. This is translated into modern tools as an attribute or a database field that might be displayed as a column. Traceability via Link The more normal way to document dependencies is via links. This has advantages and disadvantages. Advantages of using links include: automatic display in one or more places a piece of information stored in one place; there can be lots of work to create and check links; and often far too many links are made Disadvantages of using links include: links are not always intuitive; and it is not always easy to see the meaning of a link Summary: Traceability Traceability is necessary and cannot be eliminated. But unnecessary work in creating, checking, and maintaining traceability can be eliminated. Traceability can be automated to reduce effort and increase quality. Consider Traceability by Name, Object, Reference, and by Link. Summary: Eliminate and Automate Many problems occur because people do too much work. By organising the project roles only horizontally (System Analyst, System Architect, Sub-System Analyst), people tend to do unnecessary work because they do not feel comfortable with just approving the requirements and making no changes. Changing requirements unnecessarily causes an explosion in work to create, check, and maintain requirements, links and attributes. To save time and increase quality when producing specifications, do as little as possible, and as much as necessary. References This new work is based upon many projects that have proved the value of these ideas in practice. Due to the commercial nature of these projects they are secret and cannot be referenced. Bibliography includes: ISO Automotive SPICE process assessment model Richard Stevens et.al - Systems Engineering Ian Alexander et al. - Discovering Requirements Colin Hood et.al. - Requirements Management Colin Hood et. al. - Optimieren von Requirements Management und Engineering The Author Colin Hood, BSc (Hons), DMS, MBA info@colinhood-se.com Colin Hood supports customers world-wide to successfully improve quality and delivery through system engineering techniques. Colin Hood Systems Engineering Ltd., 4 Summerhouse Road, Northampton NN3 6BJ, Great Britain. Software Quality Days

17 Software Product Management Best Practices Software Product Management Best Practices Guidance towards Excellence in Product-oriented Software Engineering Software engineering often reaches its limits when faced with increased complexity and variability of the required software solutions or with the ongoing customer or market side requests for continuous enhancements and product innovations. Approaches towards establishing productoriented software engineering like software product lines promise to successfully tackle such challenges. Nevertheless, for harvesting their benefits, the integration of business and product related goals with core software engineering and software life cycle activities is vital. Software product management is expected to provide this function and empirical research confirms the positive effect of mature software product management practices.however, the various frameworks available as well as established software process improvement approaches lack a comprehensive and complete coverage of product management practices. This article presents a process reference model for software product management that consolidates and extends industry best practices and is capable to guide and support organizations towards successful implementation of productoriented software engineering. Introduction Software developing organizations are increasingly challenged with the need to develop and maintain their software as a product (cf. e.g. [1]). Traditionally, they have been used to work in project-oriented ways and develop individual solutions for specific customers. However, the ever increasing demand for higher functionality, variability, quality, etc. and constant time and productivity pressure together with the need to satisfy broader market or multiple customers needs let such approaches reach their limits. An essential goal in the required transition towards product-orientation is to harvest the benefits of predefined and ideally pre-developed products or product components while still satisfying individual customers needs. A promising engineering approach to realize such benefits of reuse in software development is software product line engineering (SPLE) (cf. [2], [3], [4]), which generally enables software developing organizations to gain significant improvements with respect to development and enhan- cement costs, time-to-market, and product quality. With advancing product-orientation the need arises for systematically managing the various products an organization offers to markets and its customers. Product management as the discipline providing this function is well established mainly in domains like consumer products or mass products. It is commonly defined as the planning, organising, executing, and controlling of all tasks, which aim at a successful conception, production, and marketing of the products offered by a company [3]. In the context of SPLE, product management aims to define the products that will constitute the product line as a whole [4]. According to these definitions, product management aims at identifying the major commonalities and variabilities among the products in the product line and realizing product portfolio planning accompanied by major economic analyses of the products. Product management is considered a key element in the transition towards product-oriented software engineering. It is expected to bridge the gap between software life cycle activities and the business, economic, and strategy related goals to ensure the success of the products on the market. Why Software Product Management? To fully exploit the potential of product- and reusefocused development approaches, core software engineering activities, e.g. requirements engineering, architecture engineering, or quality assurance, have to be closely linked and aligned with strategic and economic product aspects that are typically related to the overall business or strategic goals of the organization. Generally, product management is considered to provide this link. Empirical research confirmed the positive effect of mature software product management practices on key software development performance indicators; e.g. [5] concludes that em- Software Quality Days

18 Software Product Management Best Practices powering software product management results in significant improvements in terms of e.g. schedule predictability, quality, and project duration. Further potential benefits of mature product management include (cf. [6]): faster company growth and higher earnings compared to competitors; higher market or customer orientation in product development; more intensive dealing with customer problems and better knowledge of the needs and processes of customers compared to competitors; higher degree of innovation with respect to technical solutions, services, and market presence; better implementation of the innovation process phases and the capability to combine strategic basic developments with customer-specific adaptations; and the capability to launch more successful products in shorter time spans than competitors. Challenges in Establishing Software Product Management The transition towards product-oriented software engineering and the implementation of software product management typically implies a change in the whole organization. It requires the consideration of additional stakeholders and their potentially diverging views, perceptions, and needs. Further, the importance of business and market considerations is generally stressed in order to complement technological considerations. Specific challenges include [7]: the coverage of the needs and expectations of many different existing and potentially new customers with the developed products and services, the alignment of the products and services to specific markets or market segments, the handling of increased functionality, variability, and complexity of products, the selection of an appropriate product architecture, the development of product variants by reusing existing solutions, the enhancement of products in alignment with a product portfolio, and the coordination of interdependent and interacting software products or of software as part of other products, e.g. mechatronic systems. Existing Software Product Management Frameworks and Models A first step in the development of our process reference model for software product management comprised the analysis of existing product-oriented models and frameworks as foundation for the identification of essential software product management activities. The frameworks analyzed in this context included (cf. [7]): The reference framework for software product management developed by van de Weerd et al. [8]: This framework is based on literature research and field interviews with experienced product management practitioners from software product companies in the Netherlands. It describes the product management domain by means of four process areas and sub-functions, and provides their relations with internal and external stakeholders as well as information flows within the domain. The framework was validated in a case study. The Framework for Software Product Line Practice [9] provided by the Software Engineering Institute (SEI): It captures the latest information on successful software product line practices in technical and organizational areas. The provided information is constantly updated based on studies of and direct collaboration with organizations that have built product lines or are involved with software product lines otherwise, and with leading practitioners. The software product line engineering framework by Pohl et al. [3]: It captures the concepts of traditional product line engineering and differentiates between the two processes domain engineering and application engineering. A particular characteristic of this framework is the incorporation of product management as a key sub-process of the domain engineering process. The Microsoft Solutions Framework [10]: It aims to support organizations in successfully delivering information technology solutions and technology projects. Within this Software Quality Days

19 Software Product Management Best Practices framework, the MSF Team Model defines roles and responsibilities of teams and their members and covers interdependent multidisciplinary roles within such information technology projects, of which one is product management. The analyzed frameworks lack a comprehensive and complete coverage of product management practices. They have distinct foci, are often tightly coupled with specific development paradigms, or lack completeness or integration with core software engineering activities. The reference framework for software product management of van de Weerd et al. [8], for example, focuses on the core activities of product management. Although it provides high-level links to other involved stakeholders more detailed descriptions of these relationships and the required practices are missing. The Framework for Software Product Line Practice [9] as well as the software product line engineering framework [3] both are specifically linked to the development paradigm software product line engineering and focus on the specific concepts and activities involved therein. The Microsoft Solutions Framework [10], describes the product management role in terms of responsibilities and relationships with other roles, thus lacking the integration with core software engineering activities. On the other hand, core software engineering activities are described in various software life cycle process models. ISO/IEC [11], as a major international standard for software life cycle processes, was therefore analyzed for its coverage of product management related topics. We compared the detailed descriptions of the derived key product management activities against the description of ISO/ IEC processes and process outcomes. The results are shown in Table 1 together with the identification of the source frameworks of the key software product management activities. The last column describes their coverage with ISO/IEC using an N-P-L-F-scale (none, partially, largely, fully covered) and highlights a lack of major software product management activities within the standard. Compilation of Software Product Management Best Practices The analysis of the above described frameworks revealed those topics that are explicitly associated with product management, and additionally the SPLE-related topics that were considered relevant for product management. It resulted in the compilation of 14 key product management activities (cf. Table 1). These activities are shortly described in the following. More detailed information can be found in [7] and [12]. Product Portfolio Management is about making decisions on the set of products offered by an organization, which includes existing and in-development products. It is a strategic function and includes the identification, evaluation, selection, and prioritization of products, as well as decisions on the products life cycles [3], [8]. Product Life Cycle Management is a comprehensive approach for product-related information and knowledge management within an enterprise, including planning and controlling of processes that are required for managing data, documents and enterprise resources throughout the entire product life cycle [13]. Product Roadmapping outlines the products in the portfolio and their long-term plans and expectations as far as they are foreseeable. A roadmap describes the major common and variable product features and a schedule of their planned release dates [3]. Release Planning deals with the definition of product releases, i.e. the prioritization and selection of the product requirements to be implemented in each specific release [8]. Product Planning covers strategic and technical product planning, i.e. it outlines and determines productrelated goals, strategies, intermediate objectives, activities to be performed, and resources to be allocated [9]. It includes the selection of new product ideas for realization and the definition of the envisioned product in terms of its major features [3]. Product Controlling is concerned with monitoring and control of product related efforts in order to ensure the successful achievement of product goals as well as the organization s goals and objectives [9]. Market Monitoring is the observation and analysis of external factors that determine the success of a Software Quality Days

20 Software Product Management Best Practices product in the marketplace [9], [14], e.g. trends and buying patterns within a market segment. Key Product Management Activities by Category Software Product Management Source Frameworks van de Weerd et al. [8] SEI [9] Pohl et al. [3] MSF [10] Coverage by ISO/ IEC [11] Product Portfolio Management x x P Product Life Cycle Management x x F Product Roadmapping x x x N Release Planning x x N Product Planning x x x x N Product Controlling x x P Software Product Management Support Market Monitoring x x x x N Customer Interface Management x x x P Funding x N Product Innovation x N Cross-functional Communication x P Software Engineering Lifecycle Requirements Engineering x x L Domain and Product Line Scoping x x x L Asset Identification x x F Table 1: Key software product management activities, source frameworks, and coverage by ISO/IEC (cf. [12]). Customer Interface Management comprises the understanding of customers and the management of commitments between an organization and its customers [9]. It is also referred to as partnering and contracting, e.g. in [8]. Funding aims to plan and establish appropriate financing of software development efforts within the organization. This includes for example the identification of funding sources and the definition of funding requirements and models. The acquired funds must be sufficient in order to achieve the desired quality of results [9]. Product Innovation is concerned with the extension of the product portfolio by means of new or enhanced products that satisfy customer needs. There are different strategies and sources for idea generation that can be utilized [3]. Cross-functional Communication addresses the role of product management as an intermediary between various stakeholders or business functions [10], e.g. customers, development and project teams, management, sales, marketing, research and development, or customer support. Requirements Engineering comprises the elicitation, ana- lysis, specification, verification, and management of user and product requirements in a systematic and repeatable way. It aims to ensure the completeness, correctness, consistency, and relevance of all requirements [9]. Domain and Product Line Scoping aims to determine the relevant entities within the domain, the domain s boundaries, and how the products will interact with these entities. It also establishes product commonalities and sets limits to the product variability [9]. Asset Identification is concerned with the identification and definition of particular assets and components that cover the commonalities of products and that are used within multiple products [8], [9]. With regard to the development of a process reference model for software product management, the in depth analysis of the frameworks resulted in the compilation of an initial set of key software product management activities in terms of best practices. A Software Product Management Process Reference Model Based on the identified key product management activities and the initial set of respective best practices, we propose a process reference model for software product management (cf. Fig. 1) that is conformant with the requirements for process reference models as defined in ISO/IEC [15]. This model provides the general structure and content of software product management from a process perspective and serves as a means for the integration of the identified best practices. The key software product management activity Cross-functional Communication, which emphasizes the role of product management as an intermediary between all the involved stakeholders, was not considered as a separate process when defining the process reference model. The respective best practices were integrated on outcomelevel into the other processes, where appropriate. Software Product Management Processes Product Portfolio Management Process Product Life Cycle Management Process Product Roadmapping Process Product Planning Process Release Planning Process Product Controlling Process Software Quality Days

21 Software Product Management Best Practices Software Product Management Support Processes Market Monitoring Process Customer Interface Management Process Funding Process Product Innovation Process Software Engineering Lifecycle Processes Requirements Engineering and Management Process Domain and Product Line Scoping Process Asset Identification Process Figure 1: Overview of the Software Product Management Process Reference Model (cf. [16]) With the industry best practices for software product management gathered and systematically structured in a process reference model, organizations are enabled to assess their current practice and capabilities and establish a baseline for future improvement efforts. The process reference model also provides a basis for establishing a common language between the various involved stakeholders and thus enables and improves communication and avoids misunderstandings. Organizations can further choose to assess the broad range of topics or focus on specific elements. Overall, applying the proposed model leads to comparable results and the actual effects of improvement endeavors can be made better visible. As a consequence, applying a process reference model or respective assessment model calls for experts that understand the model and its implications. Typically, such models are used in long-term improvement efforts, which require proper recognition and support by senior management. In turn, benefits and improvements must be properly reported in order to secure management support. In order to support the link of software product management activities to the core software engineering activities, the proposed process reference model is applicable in conjunction with ISO/IEC covering the project and software engineering specific processes. Since both models are conformant to ISO/ IEC 15504, integrated applicability is supported. Reference Model Application and Experiences We applied the proposed process reference model at a software engineering organization, that provides software solutions in the domain of industrial automation and production plants. Its core business comprises the development of software products for shop-floor management and data collection, engineering support for production planning, data engineering and IT concept development, and the integration of in-house and externally developed software products for the development of individual customer solutions. Software is, on the one hand, provided to customers in form of separate and typically customized products with accompanying services. On the other hand, software is developed as part of industrial solutions which are provided to individual customers by other business units and typically include hardware, machinery, control systems, etc. As part of a long-term improvement effort, the establishment of software product management was set as an important goal. The assessment against the reference model for software product management aimed to provide a baseline and an understanding about the current capabilities regarding product management related practices within the organization (cf. Fig. 2). Process Capability CL1 CL2 CL3 Dimension Process Dimension PA1.1 PA2.1 PA2.2 PA3.1 PA3.2 Software Product Management Processes Product Portfolio Management Process P N N N N Product Life Cycle Management Process L N N N N Product Roadmapping Process N N N N N Product Planning Process P P N N N Release Planning Process F F L P P Product Controlling Process P P P N N Software Product Management Support Processes Market Monitoring Process L P N N N Customer Interface Management Process L P P P P Funding Process L P N N N Product Innovation Process L N N N N Software Engineering Lifecycle Processes Requirements Engineering and Management Process L L L L P Domain and Product Line Scoping Process L P N N N Asset Identification Process P L P N N Figure 2: Sample Results of an Assessment against the Software Product Management Process Reference Model [17] The structured interviews focused on the assessment of capability level 1 (CL1) and process attribute 1.1 (PA1.1) which evaluate to which degree the process outcomes are achieved. In conformance with ISO/IEC 15504, an NPLF-scale (not, partially, largely, or fully achieved) was used for evaluation. Achievement of capability levels two and three was judged by the assessors based on the information gathered in course of the interviews and knowledge about the organization s workflows and practices from recent Software Quality Days

22 Software Product Management Best Practices projects, but due to time constraints was not systematically assessed. The application of the model showed, that the process purposes and outcomes appropriately support the understanding and evaluation of the topics related to software product management. Misunderstandings could be revealed early in the discussions, which also contributed to the high acceptance of the assessors evaluation results by the organization s representatives. Feedback discussions with the organization s representatives revealed no major product management related topics missing in the model with respect to the organization s practices and needs. del comprise its further validation through, on the one hand, analyses against other software product management frameworks (e.g. [18],[19]) that focus more on the role of the software product manager and, on the other hand, through the continuing application of the model in real-world software product management contexts. A further major step consists in the detailed definition of a respective process assessment model and assessment method that in particular consider the cross-cutting and interdisciplinary role of software product management and reflect our experiences gained so far in applying and mapping the model to real-world software product engineering and management scenarios. Results and Conclusions Software product management plays a vital role for the success of product- and reuse-oriented software engineering organizations. Existing frameworks and models that aim to support organizations in establishing software product management practices often lack completeness or integration with core software engineering activities, or are closely linked with specific software development paradigms. On the other hand, traditional software process improvement approaches and respective underlying best practice-based process models comprehensively cover software engineering activities, but generally lack the provision of explicit software product management practices. Our proposal of a process reference model for software product management comprises the key processes and best practices for software product management. They were distilled from selected software product management and software product line frameworks and further consolidated and completed and their relationship to the processes and practices of ISO/IEC as a major international standard on software life cycle processes identified. First experiences from application of the model confirm its applicability to assess and measure the software product management capability of an organization from a process perspective and its usefulness in deriving and defining systematic improvement measures. The application of the model also indicates a satisfactory completeness and maturity of the model at its current state of development. Major next steps for enhancing the proposed mo- References 1. Stallinger, F., Neumann, R., Schossleitner, R., Kriener, S.: Migrating towards evolving software product lines: challenges of an SME in a core customer-driven industrial systems engineering context. Proceedings of the 2nd International Workshop on Product Line Approaches in Software Engineering. pp ACM, New York, NY, USA (2011) 2. Clements, P., Northrop, L.: Software Product Lines: Practices and Patterns. The SEI Series in Software Engineering, Addison-Wesley (2002) 3. Pohl, K., Böckle, G., van der Linden, F.: Software Product Line Engineering Foundations, Principles, and Techniques. Springer, Berlin (2005) 4. van der Linden, F., Schmid, K., Rommes, E.: Software Product Lines in Action. Springer, Berlin (2007) 5. Ebert, C.: The impacts of software product management. The Journal of Systems and Software 80, pp (2007) 6. Kairies P.: Produktmanager in der Elektronikbranche, E&E-Kompendium 2008/2009, Management- und Technologietrends, net. (2008) 7. Stallinger, F., Neumann, R., Schossleitner, R., Zeilinger, R.: Linking Software Life Cycle Activities with Product Strategy and Economics: Extending ISO/IEC with Product Management Best Practices. In: O Connor, R.V., Rout, T., McCaffery, F., and Dorling, A. (eds.) Software Process Improvement and Capability Determination. pp Springer Berlin Heidelberg, Berlin, Heidelberg (2011) 8. van de Weerd, I., Brinkkemper, S., Nieuwenhuis, R., Versendaal, J., Bijlsma, L.: Towards a Reference Software Quality Days

23 Software Product Management Best Practices Framework for Software Product Management. In: 14th IEEE International Requirements Engineering Conference, pp , IEEE Computer Society, Minneapolis/ST. Paul, Minnesota, USA (2006) 9. A Framework for Software Product Line Practice, Version 5.0, productlines/frame_report/index.html 10. Microsoft Solutions Framework, microsoft.com/de-de/library/bb aspx 11. ISO/IEC 12207:2008: Systems and software engineering Software life cycle processes. International Standards Organization (2008) 12. Stallinger, F., Neumann, R.: Extending ISO/ IEC with Software Product Management: A Process Reference Model Proposal. In: Mas, A., Mesquida, A., Rout, T., O Connor, R.V., and Dorling, A. (eds.) Software Process Improvement and Capability Determination. pp Springer Berlin Heidelberg (2012) 13. van de Weerd, I., Brinkkemper, S., Nieuwenhuis, R., Versendaal, J., Bijlsma, L.: On the Creation of a Reference Framework for Software Product Management: Validation and Tool Support. International Workshop on Software Product Management, IWSPM 06. pp (2006) 14. Sabisch, H.: Produkte und Produktgestaltung. In: W. Kern, H.-H. Schröder, J. Weber (Eds.): Handwörterbuch der Produktionswirtschaft, pp , Schäffer-Poeschel, Stuttgart, (1996) 15. ISO/IEC : Information Technology Process Assessment. International Standards Organization (2003) 16. Stallinger, F., Neumann, R.: From software to software system products: An add-on process reference model for enhancing ISO/IEC with product management and system-level reuse. In Cortellessa, V., Muccini, H., Demirors, O. (editors). Proceedings of the 38th Euromicro Conference on Software Engineering and Advanced Applications (SEAA 2012), pp , IEEE Computer Society (2012) 17. Stallinger, F., Neumann, R.: Assessing Software Product Management Capability: An Industry Validation Case Study, Submitted to: 13th International SPICE Conference on Process Improvement and Capability determination in Software, Systems Engineering and Service Management, 5 6 June, Bremen, Germany (2013) 18. Ebert, C.: Software Product Management. Crosstalk, Vol. 22, No. 1, pp (Jan. 2009) 19. Kittlaus, H.-B., Clough, P.N.: Software Product Management and Pricing: Key Success Factors for Software Organizations. Springer, Berlin (2009) The Authors Fritz Stallinger Fritz Stallinger works as Key Researcher and Project Developer for Process and Quality Engineering at the Software Competence Center Hagenberg, Austria ( His working areas and interests in the fields of software and systems engineering include process and quality management, component-based development, reuse, architecture, requirements, and product management. fritz.stallinger@scch.at Robert Neumann Robert Neumann works as industrial researcher at the Software Competence Center Hagenberg, Austria ( for the area of Process and Quality Engineering. He focuses on the development of new concepts and methods for software quality and process management. robert.neumann@scch.at Software Quality Days

24 Vermitteln Sie Wissen und Werte mit Stories Vermitteln Sie Wissen und Werte mit Stories Geschichten zu erzählen und anzuhören macht Spaß und die meisten Menschen können dies stundenlang tun, weltweit und seit Jahrtausenden. Geschichten sind die natürlichste Form von Wissen, Gedächtnis und Kommunikation [Schank]. Im beruflichen Alltag lernt man fachlich und menschlich enorm aus den Geschichten erfahrener Kollegen. Über Geschichten erfährt man auch, welche moralischen Werte in einer Firma herrschen. Umgekehrt können Sie Geschichten nutzen, um Wissen und Werte weiterzugeben. Begabte Geschichtenerzähler erzählen ganz intuitiv immer genau richtig. Worin liegt ihr Geheimnis? Die wissenschaftliche Forschung hat untersucht, wie Stories im beruflichen Umfeld am besten wirken. Hinzu kommt das mehrere tausend Jahre alte Wissen der Kunst darüber, wie man einen Leser oder Zuhörer fesselt. Dieser Artikel beschreibt, was eine gute Geschichte enthalten muss, wie man sie spannend aufbaut und wie man mit Improvisationstheater unterhaltsam und effizient das Erzählen lernen kann. Was muss eine gute Geschichte enthalten? Eine gute Geschichte muss vollständig sein, in der richtigen Reihenfolge und der richtigen Form erzählt werden. Wie Sie dies erreichen, wird in den drei Kapiteln dieses Artikels behandeln. Hier beginnen wir mit den notwendigen Inhalten einer Geschichte. Was muss eine Geschichte beinhalten, damit sie von den Zuhörern als gut oder vollständig wahrgenommen wird? Unsere Quellen sind jeweils die Forschung über das Geschichtenerzählen ( Storytelling ) als Kommunikationsmittel, die Kenntnisse der Literaten und des Improvisationstheathers. Forschung Jede vollständige Geschichte muss die fünf W-Fragen beantworten. Die folgende Auflistung fasst die Ergebnisse mehrerer Forscher ([Gruen], [Lombardo], [Lowenthal], [Turner]) zusammen: Wo und wann? Was ist das Umfeld der Geschichte? Wo und wann spielt sie? Wer? Entscheidend dafür, wie sehr den Leser / Zuhörer die Geschichte interessiert, sind die handelnden Personen. Die müssen glaubwürdig und lebensecht sein, wobei Hauptpersonen genauer be- schrieben sein müssen als Nebenpersonen. Außer den physischen Merkmalen wie Alter, Größe, Haar-, Augen- und Hautfarbe sowie Statur interessieren den Leser insbesondere die moralischen Werte und Ziele der Personen, was diese antreibt im Leben. Identifikation und emotionale Anteilnahme an der Geschichte entsteht durch eine Ähnlichkeit mit dem Leser / Zuhörer. Um möglichst viele Menschen anzusprechen, sollten Sie auch die Nebenpersonen ansprechend gestalten. Laut dem BDI-Modell besteht eine Person aus Beliefs about the world, Desires (or goals) und Intentions (i.e. commitment to action plans aimed at achieving goals) [Lombardo]. Warum/wozu? Hierzu gehört der Auslöser der Geschichte und die (emotionalen / moralischen) Ziele, welche die handelnden Personen verfolgen, aber auch die Hindernisse, welche diese daran hindern, ihre Ziele problemlos zu erreichen. Die letzte Ursache von allem ist jedoch ein zu lösender Konflikt, der den Zuhörer interessiert. Das Ziel der Geschichte muss nicht übereinstimmen mit dem Ziel der Hauptperson. Die Unternehmenskommunikation [Pallas] erzählt vier Geschichtentypen: Sales Stories, Product Stories, Financial Stories, Organizational Stories. Was? Die Handlung verknüpft die Ausgangslage, das auslösende Ereignis und den Schluss durch eine Folge von Ereignissen. Wie Sie den Spannungsbogen führen, erfahren Sie weiter unten. Wie? Der Zuhörer will nicht nur eine Zusammenfassung einer Geschichte, sondern die Geschichte selbst mit illustrierenden Details. Requisiten mit symbolischem Gehalt transportieren zwischen den Zeilen zusätzliche Botschaften. Die Erzählperspektive muss klar sein und zur Botschaft der Geschichte passen, ebenso die Position des Erzählers und die Frage, ob (grammatikalisch) in der dritten oder ersten Person erzählt wird. Literatur Ein gutes literarisches Werk behandelt durchgängig ein bestimmtes Thema und übermittelt eine Botschaft. Während sich verschiedene Genres durch ihr Personal und die Requisiten unterscheiden, haben Software Quality Days

25 Vermitteln Sie Wissen und Werte mit Stories sie doch einiges gemeinsam: Starke, unter die Haut gehende Geschichten behandeln diejenigen Fragen, die alle oder viele Menschen beschäftigen, und auf die es keine abschließende allgemein akzeptierte Antwort gibt. Beispielsweise die Frage Wie kommen die Löcher in den Käse? ist leicht zu beantworten. Aber der Kampf zwischen Gut und Böse ist ein nicht enden wollendes Thema. Auch die Frage, wie große Opfer man für seine eigenen Überzeugungen bringen würde, stellt sich für die meisten Menschen immer wieder. Freundschaft und Verrat, Liebe und Tod, das sind die niemals langweilig werdenden Themen. Außer dieser schweren Kost mögen die Menschen aber auch Witze (=Geschichten, die überraschen), Rätselgeschichten (auch Krimis gehören dazu) oder Abenteuergeschichten, bei denen der Leser an exotische Orte entführt wird und eventuell etwas lernt über London 1805, den internationalen Handel des fünfzehnten Jahrhunderts oder darüber, was hinter den Kulissen eines Theaters vor sich geht. Gerade bei Geschichten, die in einem Umfeld spielen, das dem Leser fremd ist (exotische Länder oder vergangene Zeiten) muss der Autor mehr Details beschreiben und soll dies auch, weil der Leser über diese fremde Welt etwas lernen will. Ein schwerer Fehler sind ungenügende Recherchen, die oft genug von kompetenten Lesern aufgedeckt werden und deren Freude an der Geschichte zerstören. Auf andere Weise herausfordernd ist das Wo und Wann für fiktive Orte und Zeiten (in Science Fiction und Fantasy). Hier muss eine gesamte Welt neu erfunden werden. Zumeist lehnt man sich dabei an einer real existierenden Welt an und entwickelt diese weiter. Der Leser muss einen Nutzen davon haben, dieser Geschichte Zeit zu widmen. Wie baut man eine Geschichte auf? Literatur Fast alle Literaturgattungen kennen die drei Akte : Einleitung, Hauptteil und Schluss. Theaterstücke haben manchmal auch fünf (Einführung der Charaktere, steigende Spannung, Höhepunkt, abfallende Spannung und Schluss [Freytag]), aber die Dreiteilung ist am häufigsten. Jeder Akt besteht aus einzelnen Szenen. Im Einzelnen enthalten die drei Akte einer Geschichte: 1. Akt Der erste Akt gibt einen kurzen Einblick in die Ausgangslage. Diese Welt befindet sich in einem mehr oder weniger angenehmen Gleichgewicht. Dann passiert das auslösende Ereignis, das die Handlung ins Rollen bringt. Eine Frage wird gestellt, ein Konflikt entsteht, eine Aufgabe oder ein Rätsel muss gelöst werden, eine Bedrohung abgewendet. Ab dem auslösenden Ereignis steigert sich die Spannung bis zum ersten Wendepunkt. Die Welt wie sie bisher war, gerät aus dem Gleichgewicht. Soll der Held am Ende siegen, dann erleidet er am ersten Wendepunkt (auch Plot-Point auf Englisch) seine erste größere Niederlage. Oft muss zu diesem Zeitpunkt eine Nebenperson sterben, um die Gefährlichkeit der Situation zu verdeutlichen. Es kommt zu einer Krise: Bisherige Lösungen funktionieren nicht mehr, der Held erscheint zu schwach, die Lage ausweglos, Selbstzweifel kommen auf. Vielleicht denkt der Held sogar ans Aufgeben oder weigert sich, seine Aufgabe anzunehmen. Es gibt jedoch keinen Ersatz für ihn, er kann nur kämpfen oder untergehen. Handelt es sich dagegen um eine Geschichte, bei der die Hauptperson am Ende untergehen wird (z.b. eine Tragödie oder einen Stephen King Thriller), wird sie hier einen ersten Erfolg erzielen und Hoffnung schöpfen, dass sich das schwerwiegende Problem doch lösen lässt. Damit ist die Einleitung abgeschlossen. Der Leser kennt die Ausgangslage, das zu lösende Problem und auch die Schwierigkeiten, die dabei auftreten. Alle entscheidenden Personen sind eingeführt und die Lösung ist meist schon angedeutet auch beim Krimi oder in der Rätselgeschichte. 2. Akt Im Hauptteil findet der Hauptteil der Handlung statt. Der Held muss viele Prüfungen bestehen, die immer schwerer werden. Er gerät immer wieder an seine Grenzen, wächst aber mit seinen Aufgaben, arbeitet an seinen Schwächen und entwickelt sich sichtbar weiter. Während sich zunächst die Spannung steigerte, fühlt man sich nun immer sicherer, dass der Held siegen wird. Am zweiten Wendepunkt werden die Hoffnungen enttäuscht, der Held erlebt seine schwerste Niederlage. Doch es gibt kein Zurück, er kann nur sterben oder weiterkämpfen. In der Tragödie (oder im Stephen King Roman) kann die zum Scheitern verurteilte Hauptperson hier nochmal einen großen Sieg erringen und danach scheint alles gewonnen und Friede einzukehren. Oft fragt man sich am zweiten Wendepunkt, warum das Buch noch weitere 80 Seiten hat oder man im Theater nach der Pause wiederkommen soll. Die Geschichte scheint bereits entschieden. Oder nicht? Software Quality Days

26 Vermitteln Sie Wissen und Werte mit Stories 3. Akt Im dritten Akt geht es direkt auf das Ende zu. Da am zweiten Wendepunkt die Geschichte eigentlich schon zu Ende schien, muss der Leser nun noch überrascht werden. Aber nicht wirklich! Nebenpersonen oder Bemerkungen, die man zuvor für unwichtig hielt, entpuppen sich nun als entscheidend. Jede Überraschung wurde durch vorherige Tipps vorbereitet, aber diese waren raffiniert versteckt. Beim Krimi kann es sein, der Täter war bereits verdächtigt worden, jedoch aus irgendeinem Irrtum heraus für unschuldig gehalten. Nun jedoch offenbart sich seine perfide Raffinesse (und die des Erzählers!). Der dritte Akt beantwortet die anfangs gestellten Fragen, löst alle Rätsel, die Bösen werden bestraft und die Guten belohnt. Die Welt oder der Held hat sich verändert. Der dritte Akt überbringt damit die Botschaft wie Freundschaft ist das Wichtigste im Leben oder Es ist nichts so fein gesponnen es kommt doch an die Sonnen. Aber auch Dieses Produkt / diese Methode löst Ihre Probleme bei der automatischen Qualitätssicherung oder Wir können Ihnen dazu verhelfen, dass alle Internet-User Ihren Namen kennen! Beispiel Dieser Aufbau gilt sowohl für epische Werke wie 1200-Seiten-Romane als auch für Kurzprosa. Sie können die drei Akte auf drei Powerpoint-Folien unterbringen oder in einer kurzen Firmenansprache am warmen Buffet. Hier ein Beispiel für eine Helden- Geschichte wie aus dem Lehrbuch: Text Liebe Mitarbeiterinnen und Mitarbeiter! Erinnern Sie sich noch an vor einem Jahr? Die Geschäfte liefen schlecht und dann kam auch noch die Weltwirtschaftskrise dazu! Sie alle, wir alle machten Überstunden ohne Lohnausgleich doch dann mussten wir im Januar 50 Mitarbeiter entlassen. Rolle dieses Textteils in der Geschichte Ausgangslage auslösendes Ereignis Die Spannung steigt, das Problem soll durch bewährte Lösungen gelöst werden erste Niederlage = erster Wendepunkt Text Wir haben aber nicht aufgegeben, haben neue Produkte entwickelt, der Juniorchef fuhr für uns nach Ungarn, nach Japan und in die USA, um neue Kunden zu gewinnen. Doch trotz unserer Bemühungen entschied sich unser Hauptkunde für einen Billiganbieter aus China. Liebe Mitarbeiterinnen und Mitarbeiter, wie oft saß ich abends um Mitternacht noch hier im Büro mit meinem Sohn, dem Juniorchef, und wir spielten alle Möglichkeiten durch, die uns noch blieben. Wir standen vor der schwierigen Entscheidung, ob wir die Firma schließen müssen. Wir waren kurz davor, diesen Messestand in Japan wieder abzusagen, der uns doch nur viel Geld kosten würde, ohne etwas einzubringen. Doch mein Sohn gab nicht auf und flog hin. Er nahm einen Prototypen des X17A mit, den unsere Entwicklungsabteilung mit ihrem überragenden Einsatz noch rechtzeitig fertig brachte Und dieser unscheinbare graue Roboterarm, den ich hier in der Hand halte, wurde zur Sensation der Messe. Sie wissen es selbst: Die Hälfte unserer heutigen Produktion stellt nichts anderes her als den X17A, den wir nun in alle Welt exportieren. Unsere japanischen Kunden haben neulich ihre Bestellung verdoppelt. Und so kann ich Ihnen heute mitteilen, dass wir alle entlassenden Mitarbeiter wieder einstellen können. Und dies alles dank Ihrer treuen und engagierten Mitarbeit und nicht zuletzt der Beharrlichkeit des Juniors! Rolle dieses Textteils in der Geschichte Der Held zieht in die Welt hinaus und probiert neue Lösungen. zweite Niederlage = zweiter Wendepunkt Ende des 2. Aktes: Alles scheint verloren, trotz aller Bemühungen. Scheinbar ist die Geschichte zu Ende. die Helden bringen allerhöchsten Einsatz 3. Akt: Die Rettung passiert unerwartet, aber nicht aus unerwarteter Richtung, denn die Überstunden, die Kontakte nach Japan und der Juniorchef waren zuvor schon erwähnt worden Die Opfer werden gerettet, das verloren gegangene Gleichgewicht wird wieder hergestellt. Software Quality Days

27 Vermitteln Sie Wissen und Werte mit Stories Text Ich denke, nun ist auch der richtige Augenblick gekommen, um die Firmenleitung an meinen Sohn zu übergeben, denn er hat seine Feuertaufe bestanden! Rolle dieses Textteils in der Geschichte Der Held wird belohnt. Die Welt hat sich verändert. Oder kürzer, da die Zuhörer die Geschichte ja schon kennen: 1. Akt: Erinnern Sie sich, wie wir vor einem Jahr 50 Mitarbeiter entlassen mussten wegen der Wirtschaftskrise? 2. Akt: Trotz Ihres Engagements lief es jedoch immer schlechter, bis wir kurz davor waren aufzugeben. 3. Akt: Doch dann hat der X17A die Wende gebracht, wir exportieren ihn heute in alle Welt und können die entlassenen Mitarbeiter wieder einstellen! Dies scheint alles sehr einfach zu sein, doch wenn Sie darauf achten, werden Sie bemerken, dass alle guten Geschichten dieser klaren Linie folgen. Umgekehrt können Sie auch sicher sein, dass wenn eine Geschichte nicht gut ankommt, ein wesentliches Element fehlte oder irrelevante Elemente die Zuhörer langweilten oder auf falsche Fährten lockten. Einen ganz vergleichbaren Aufbau sollte jeder Ihrer Vorträge haben. Wenn Sie ein Produkt beschreiben wollen, dann beschreiben Sie das Problem und die Arbeitsweise, die man ohne Ihr Produkt erleiden muss, die Niederlagen und Risiken, die der Alltag einem zufügt. Ihr Produkt taucht dann auf wie der Held im Märchen, passt sich gegebenenfalls den schwierigsten Situationen an und führt zur Rettung auch in hoffnungslosen Situationen. Die Geschichte kann eine wahre Begebenheit erzählen oder fiktiv sein Sie sollten nur nicht erfundene Geschichten als Wahrheit ausgeben. Die Schwerpunkte einer Geschichte Wichtig ist das richtige Erzähltempo und vor allem auch, die Redezeit einzuhalten. Ein Zwanzigminuten-Vortrag darf nur 20 Minuten dauern und auch für Romane gibt es praktische Obergrenzen. Nur wenige geniale Erzähler können einen Spannungsbogen über mehr als 1000 Seiten straff in den Händen halten! Akt 1 und Akt 3 sollen vor allem informieren, die wichtigsten Daten enthalten und durch ihren Inhalt fesseln. In Akt 2 dürfen Sie sich mehr Zeit lassen, ruhig auch ein wenig ausholen und gemütlich werden. Bei 20 Minuten Vortrag entfallen maximal 5 Minuten auf den ersten und den dritten Akt, die restliche Zeit ist für Akt 2. Diese darf in Abschnitte unterteilt sein. Es gibt verschiedene Arten von Geschichten, aber lange nicht so viele wie Sie vermutlich glauben. Auf einer abstrakten Ebene gibt es nur ein paar Dutzend Plots, also Strukturen für Geschichten. Jeder dieser Plots hat ein anderes Ziel, bringt dem Leser einen anderen Nutzen und folgt seinen eigenen Gesetzen darüber, was in den drei Akten jeweils zu geschehen hat und worauf beim Erzählen der Schwerpunkt liegen soll. Rudyard Kipling ging von 69 Plots aus, laut Aristoteles gibt es nur Tragödien und Komödien. In dem Buch 20 Masterplots [Tobias] werden 20 beschrieben. Dieses Buch wird aktuell von Schriftstellern als Handbuch verwendet. In unserem Beispiel handelt es sich um den Plot Die Rettung. Im Rettungs-Plot kommt es hierauf an: Der Held muss in die Welt hinaus ziehen, oft sogar bis ans Ende der Welt (eventuell auch im übertragenen Sinne). Es gibt ein Opfer, das oft im ersten Akt vom Helden getrennt wird und das der Held zielstrebig rettet (hier die entlassenen Mitarbeiter). Die äußere Handlung ist wichtiger als die innere Entwicklung der Personen, der Held wird gefeiert, sein Gegner verkörpert das Problem (hier der untreue Kunde). Schwarz-weiß-Malerei und Übertreibung sind beim Rettungs-Plot erlaubt. Die moralische Botschaft des Rettungs-Plots besteht darin, dass der Zuhörer dem Helden nacheifern soll. Diejenige Tugend, die zur Rettung führte, wird zur Nachahmung empfohlen. In unserem Beispiel sind das Fleiß (Überstunden), Leistungswille und dass man die Hoffnung nie aufgibt. Forschung Zum Einlesen in die Feinheiten der Konstruktion einer Geschichte empfehlen wir [Damiano] und [Propp]. Diese zu diskutieren würde hier jedoch zu weit gehen. Das Wie des Geschichtenerzählens In den vorigen beiden Kapiteln haben Sie erfahren, welche Inhalte die Geschichte haben muss und in welcher Reihenfolge die Handlung geschieht. Doch selbst Geschichten, die einen ähnlichen Inhalt und Aufbau haben, können sich qualitativ stark unterscheiden. In letzter Zeit konnte man dies sehr an- Software Quality Days

28 Vermitteln Sie Wissen und Werte mit Stories schaulich beobachten anhand einiger Neuverfilmungen altbekannter Märchen. Selbst eine Geschichte, die man bereits kennt, kann immer wieder neu fesseln, aber auch durch einen schlechten Erzähler geradezu zerredet werden. Einheit von Handlung, Ort und Zeit: Jede Geschichte darf nur ein Hauptthema haben, nur eine einzige Frage beantworten oder eine einzige Botschaft überbringen. Wenn Sie Ihre Geschichte überfrachten, irritiert dies den Leser. Die Geschichte darf sich auch nicht selbst wiedersprechen. So darf nicht der Schurke für seine Untreue geköpft werden, während der Held selbst durch Verrat siegt. Auch was Ort und Zeit angeht, sollten Sie so wenig wie möglich springen, auch wenn Sie außerhalb des Theaters nicht durch Umbauzeiten beschränkt sind. Insbesondere ist es unnötig, extra nach Rio de Janeiro zu fliegen, damit die beiden Hauptpersonen drei Sätze wechseln können. Ein Telefonat, das in eine andere Szene eingebunden ist, erfüllt denselben Zweck. Zielgruppenadressierung: Nicht jede Geschichte funktioniert vor jedem Publikum. Im Gegenteil. Ich verwende fast nie einen Vortrag vollständig mehrmals, er wird immer angepasst. Die Geschichte muss auf jeden Fall ein Problem lösen, welches das Publikum kennt oder haben könnte. Aber auch die Lösung sollte für die Zielgruppe geeignet sein (z.b. nicht zu teuer). Mit der Einleitung stellen Sie die Ausgangslage dar, vermitteln aber auch das nötige Vorwissen, damit die Zuhörer das Problem, dessen Schwierigkeiten und die Lösung verstehen können. Daher muss die Einleitung je nach Publikum länger oder kürzer sein. Verwenden Sie nur Beispiele aus dem Erfahrungsbereich der Zuhörer und sprechen Sie deren Sprache. Dieselbe Sache heißt in verschiedenen Kreisen oft unterschiedlich. Ganz wichtig ist es aber auch, die moralischen Normen der Zielgruppe zu respektieren. Medien: Das älteste Medium für das Geschichtenerzählen ist die Stimme und gerade diese kommt erneut in Mode und löst immer mehr die Schriftform wieder ab in Form von Webcasts, Hörbüchern und Handbüchern in Videoform. Optische Medien sind ansprechend und helfen der Vorstellung auf die Sprünge beispielsweise Fotos der behandelten Personen oder dem Ort der Handlung. Bilder brauchen keine Übersetzung. Wenn Sie über eine physische Sache sprechen, beispielsweise eine Maschine, so bringen Sie doch ein Exemplar oder ein tragbares Teil davon mit und reichen Sie es zum Anfassen durch das Pub- likum. Je mehr Sinne die Geschichte anspricht, umso besser. Natürlich können Sie auch mit Ihren Händen die Umrisse eines Gegenstands darstellen (z.b.: Der X17A ist so groß, also etwa einen Kopf größer als ein Mensch, aber doppelt so schwer. ) und dessen Oberflächenbeschaffenheit mit Worten beschreiben. Auch die Sprache kann Bilder, Gerüche, Temperaturen und Tasteindrücke vermitteln. Glaubwürdigkeit: Die Geschichte muss logisch und realistisch sein. Selbst wenn sie erfunden ist, muss sie zumindest so stattgefunden haben können. Und auch dann wenn sie in einer erfundenen Welt spielt (Fantasy, Science Fiction), muss sie innerhalb der Gesetze dieser Welt logisch sein. Improvisationstheater Improvisationstheater ist ein eigenständiges Bühnenformat im Theater, welches sich insbesondere in den letzten Jahren mehr und mehr Beliebtheit erfreut. Beim Improvisationstheater geht es darum, dass die Schauspieler auf der Bühne Szenen aufführen, die sie improvisieren, das heißt zuvor nicht einstudiert haben. Dies steht im Gegensatz zum klassischen Theater, wo jede Szene und jeder einzelne Satz auswendig gelernt und exakt einstudiert sind. Das Improvisationstheater (Impro) kennt verschiedene Formen, auch Formate genannt. Allen ist identisch, dass das Thema der Handlung erst durch das Sich-Begegnen der Schauspieler auf der Bühne entschieden wird. Durch sogenannte Vorgaben entscheidet das Publikum je nach Format über Ort der Handlung, behandeltes Thema o.ä.. Die Spieler können jedoch auch ganz auf Vorgaben verzichten, dann entstehen Geschichte und Handlung ausschließlich aus der Situation in der sich die Charaktere dargestellt durch die Schauspieler auf der Bühne begegnen. Es mag der Eindruck entstehen, dass Improvisationstheater die hohe Kunst des Theaters ist, sodass nur erfahrenste Schauspieler beim Impro teilnehmen können. Dies ist mitnichten der Fall. Improvisatonstheater bietet einen für Laienschauspieler und Neulinge des Theaterspielens extrem interessanten Einstieg, da der zentrale Grundsatz lautet: Es gibt keine falschen Handlungen! Der von Improspielern meist zitierte Satz ist vermutlich das Prinzip des Spaß am Scheitern! Software Quality Days

29 Vermitteln Sie Wissen und Werte mit Stories Und in der Tat kommen die Zuschauer nicht zum Improvisationstheater, um perfekt einstudierte Geschichten nach den oben geschilderten Prinzipien zu sehen, sondern um die Schauspielern bei ihrer Improvisation und ihrem Scheitern in alltäglichen Situationen zu beobachten. Am anschaulichsten ist dies vielleicht an dem Beispiel des sogenannten ABC-Spiels. Das ABC-Spiel ist ein Spiel für zwei Spieler, welches eine Regel festlegt, wie die Spieler den Dialog zu führen haben: Jeder Spieler muss seinen Satz mit dem nächsten Buchstaben beginnen, der auf den Buchstaben des Satz vom Mitspieler im Alphabet folgt. Hierbei ist immer wieder die Freude des Publikums zu beobachten, wenn ein Schauspieler beweist, dass er das Alphabet nicht beherrscht indem er (oder sie) mit einem falschen Buchstaben weiterspielt. Gutes Improvisationstheater lebt also vom Scheitern der Schauspieler und dem daraus resultierenden Spaß beim Publikum. Darüber hinaus ist es aber wichtig, dass die gespielten (und erzählten) Geschichten der Szene Sinn ergeben und sich für das Publikum sinnvoll und intuitiv richtig anfühlen. Gutes Improvisationstheater zeichnet sich also durch gute Geschichten aus, die die Schaupieler auf die Bühne bringen. Gutes Improvisieren kann und wird von den Improspielern trainiert. Dabei gibt es verschiedene Trainingsformate. Ein Teil fokussiert auf das intuitive Erzählen von Geschichten, die gut ankommen, also von Geschichten, die funktionieren und das Publikum begeistern. Ein guter Improspieler ist also in der Lage, in einer unplanbaren ad-hoc-situation, die zudem für den einen oder anderen stressig erscheinen mag, gute Geschichten zu erzählen. Dies erfolgt oft nicht, indem er selbst lange Monologe hält (vgl. [Vlcek], S.76), sondern sich im Kontext seiner Umgebung kongruent und nachvollziehbar verhält. Aus Sicht des zuvor beschriebenen Wie des Geschichtenerzählens bedeutet dies nichts anderes, als dass der Improspieler schnell und intuitiv in der Lage ist, im Spiel die notwendigen fehlenden Elemente sinnvoll und einfach zu ergänzen sodass sich eine Geschichte mit allen Elementen des guten Geschichtenerzählens ergibt. Die Trainingsformate machen sich dabei die spielerische Natur des Schauspielens zu nutze. Es ist das kontinuierliche Anwenden und Ausprobieren mit anderen Spielern, welches nach und nach die Intu- ition und das Gespür für gute Geschichten erzeugt. Dabei ist das Gespür letztendlich nichts anderes als Erfahrung gesammelt aus dem Feedback während des Trainierens und den Auftritten. Da Improvisationstheater auf Spaßhaben und ohne Bewertung funktioniert, ist von vornherein eine risikoarme Situation gewährleistet. Diese Situation kann paradoxerweise gerade erst dadurch entstehen, dass das Scheitern, welches sonst das vermiedene Verhalten ist, ausdrücklich erwünscht, gar provoziert wird. Ausblick Sie haben nun in Kürze erfahren, welche Elemente eine Geschichte enthalten soll, wie Sie diese Geschichte aufbauen, was Improvisationstheater zum Erlernen des Erzählens beiträgt und worauf Sie noch zu achten haben. Natürlich kann dieser Artikel nur eine knappe Einführung geben. Es gibt jedoch umfangreiche Literatur zum Geschichtenerzählen, gerade Schriftstellerhandbücher und Forschungsartikel zum Geschichtenerzählen in der Berufspraxis für verschiedene Zwecke. Für das Improvisationstheater sei insbesondere auf Keith Johnstone und seine beiden bekanntesten Bücher verwiesen. Keith Johnstone gilt als der Begründer des Theatersports und seine Bücher führen anhand von Spielen in die Welt des Improvisierens [Johnstone2010, Johnstone2011]. Literatur [Damiano] Rossana Damiano, Vincenzo Lombardo, Antonio Pizzo: Formal Encoding of Drama Ontology. G. Subsol (Ed.): VS 2005, LNCS 3805, pp , Springer-Verlag Berlin Heidelberg 2005 [Freytag] G. Freytag: Die Technik des Dramas. Autorenhaus Verlag, Berlin, 2003 [Gruen] Dan Gruen, Thyra Rauch, Sarah Redpath & Stefan Ruettinger: The Use of Stories in User Experience Design. International Journal of Human-Computer Interaction, Volume 14, Issue 3-4, 2002, pp [Johnstone2010] Keith Johnstone: Improvisation und Theater, Alexander Verlag, 2010 [Johnstone2011] Keith Johnstone: Theaterspiele: Spontaneität, Improvisation und Theatersport, Alexander Verlag, 2011 Software Quality Days

30 Vermitteln Sie Wissen und Werte mit Stories [Vlcek] Radim Vlcek: Praxis Buch Workshop Improvisationstheater: Übungs- und Spielesammlung für Theaterarbeit, Ausdrucksfindung und Gruppendynamik, Auer Verlag ISBN-13: [Lombardo] Vincenzo Lombardo and Rossana Damiano: Ontology-based annotation of narrative segments. 5th International Conference on Semantic and Digital Media Technologies (SAMT 2010), Saarbrücken, December 2010 [Lowenthal] P.R. Lowenthal: Digital storytelling: An emerging institutional technology? In K. McWilliam & J. Hartley (Eds.), Story circle: Digital storytelling around the world. Wiley-Blackwell, 2009 [Pallas] Josef Pallas: Talking Organizations - A Narrative Analysis of Corporate Press Releases an Institutional View. Doctoral Thesis, Uppsala, 2007 [Propp] Propp, Vladimir., In: Morphology of the Folktale nd ed. Trans. Lawrence Scott. Austin: U of Texas P, (1968) [Schank] Roger C. Schank, Robert P. Abelson: Knowledge and Memory: The Real Story. Robert S. Wyer, Jr (ed) Knowledge and Memory: The Real Story. Hillsdale, NJ. Lawrence Erlbaum Associates cogprints.org/636/00/knowledgememory_ SchankAbelson_d.html [Tobias] Ronald B. Tobias: 20 Masterplots Woraus Geschichten gemacht sind, Zweitausendeins. [Turner] Susan Turner, Phil Turner, Cedric Raguenaud and Jessie Kennedy: Telling tales: narratives of classification and control in the design of taxonomic software. Design Studies, Volume: 24, Issue: 6, Publisher: Elsevier, Pages: , 2003 Die Autoren Dr. Andrea Herrmann ist freiberufliche Software Engineering Trainerin. Nebenberuflich schreibt und rezensiert sie Belletristik-Romane. Sie ist Privat-Dozentin für Informatik an der Universität Heidelberg und stellvertretende Sprecherin der Fachgruppe Requirements Engineering der Gesellschaft für Informatik. Anne Hoffmann bringt 10 Jahre Berufserfahrung als Consultant, Requirements Engineer und Projektleiterin mit wurde sie beim Young Project Manager Award der Internationalen Projektmanagement Gesellschaft (IPMA) als Preisträgerin für ihre Leistungen ausgezeichnet. Zurzeit leitet Anne Hoffmann ein Team von Requirements Engineers für strategische IT-Projekte im Energy Sektor der Siemens AG. In ihrer Freizeit ist sie begeisterte Improvisations-Spielerin. Daraus hat sie Workshopformate zur Vermittlung von Softskills im Projektumfeld entwickelt. Software Quality Days

31 Copy & Paste & Bug? Copy & Paste & Bug? Consequences of - and Coping with - Copy & Paste Programming in Practice Code clones are a major quality defect and constitute a serious problem for the maintenance of a system. Various clone-related defects are frequently found in productive software. Without appropriate countermeasures, redundant code increases the maintenance costs of the system and the risk of introducing unwanted inconsistencies which may result in serious defects. This article describes which problems are caused by clones and outlines an approach based on the freely available ConQAT tool suite to manage and reduce the redundancy in a system. Code Clones Code clones are similar fragments of source code, typically created through copy & paste. There are different reasons for the use of copy and paste. One of the most common reasons to copy code is to use existing code as a template to implement new functionality which is, however, very similar to already existing functionality. In such a case, the existing code is copied and modified afterwards to implement the new functionality. Other reasons beyond templating are, for example, making functionality available in a different place, or branching code for trying things out. Figure 1: Code clones from a Java open source system Clone-Related Problems Although cloning has some short-term benefits like increasing the development pace, it commonly causes serious problems in the long run. One of the more obvious problems is that clones unnecessarily in- crease the size of the code base and make the program larger than it needs to be. In certain domains like embedded systems, for example, this may result in more expensive hardware that is required to run the software. Beyond that, a larger code base also increases the maintenance costs in general as more code needs to be understood, managed, and maintained. Another problem that we frequently observe in practice is that a copied code fragment, that is used as a template, is not correctly adapted to its new context. Having multiple copies of a particular code fragment also multiplies the maintenance costs when one of these fragments needs to be changed. Even if the other fragments do not need to be changed in the end, they have at least to be read, understood, and inspected whether they would also require the change. Needless to say that this requires knowledge where all the clones of a particular code fragment are located inside the code base. Clones thus introduce is the risk of unwanted inconsistent changes which occur when developers are not aware of all the copies that exist of the code fragment that they are currently modifying. In such situations, for example, a bug fix may be made in one of the defective code fragments, but not propagated to all of its copies. Figure 1 displays such a case. The problem of unintentional inconsistencies becomes worse when developers copy code from each other and are, consequently, not aware of all the copies that were potentially made from their code. The above-mentioned problems are not only of theoretical nature, but are commonly observed in practice. As part of our consulting work, we regularly assess the quality of industrial software. We found clone-related problems in many of these systems. In order to quantify the problem and put our experiences on more solid ground, we have conducted a large-scale case study [1] and investigated inconsistent clones in different industrial systems deve- Software Quality Days

32 Copy & Paste & Bug? loped by the Munich Re and the LV All of the investigated clones were not identical, but similar with more or less subtle differences. Each clone was assessed by an expert who was familiar with the system in which the clone was found. The results show that 28% of all inconsistencies are unintentional and should have been consistent. Even worse, every second unwanted inconsistency has been found to be a defect. In total, 107 defects of all severity levels (including 17 critical defects) have been found in production software. These numbers illustrate the threat and the problems that clones cause without appropriate countermeasures. Cloning in Practice An indication of how severe the clone-related problems are in a particular system is the amount of redundancy that can be found in the corresponding code base. While it is hardly feasible to reach a state without any redundancy, the existing redundancy should be kept as low as possible. A general recommendation is to keep the amount of redundant code below 10% with very good systems reaching levels below 5%. In most systems we analyze, and which have not used clone analysis before, we measure initial redundancy values between 20% and 40% with recognizable effects on the maintainability and correctness of the source code. In individual cases, we have measured values of up to 80%. Such systems are several times larger than they need to be. A tree map is a valuable visualization to get an impression of the cloning situation in a system. It provides a high-level overview and can be used to identify hot spots of cloning inside a system. An example for a middle-sized Java system is shown in Figure 2. Each rectangle represents a file of the system and the area of the rectangle corresponds to the lines of code contained in the corresponding file. The color is used to indicate the clone coverage, the percentage of the file that is covered by clones. The color ranges from white (no clones) to intense red (completely covered by clones). In our sample tree map, files with high clone coverage occur everywhere in the system. The subsystem at the bottom s center has an aboveaverage concentration of clones. Figure 2: Distribution of clones in a sample system Countermeasures The general approach to counter clone-related problems involves two major steps. The first part consists of creating an awareness for the redundancy that exists in the code base. This includes knowledge about the overall cloning situation in terms of aggregated values as well as detailed information about which code fragments are similar to each other. The aggregated values allow to estimate the severity of the problem and to monitor the improvement progress. The more detailed information helps developers to locate all copies of a code fragment which they are about to change and which might need to be changed as well. After creating an awareness for the cloning situation, the second step involves stepwise removal of the existing redundancy. Despite information about the redundancy, clones exhibit a certain threat potential as long as they exist. Therefore, they should be removed at some point. Due to the comparatively high number of clones in most systems, immediate and aggressive removal of all clones is not a viable strategy. Instead, the redundancy should be removed step by step in a controlled manner. In any case, mitigating clone-related problems requires adequate tool support. Clone Detection Due to the variety of problems that clones can cause in software maintenance, an active research community has evolved around this topic [3]. One of the central research areas is the automated detection of clones inside the code base of a program. By now, Software Quality Days

33 Copy & Paste & Bug? a large number of algorithms exist, which can be roughly categorized according to the program representation upon which they operate. The simplest approaches are text-based without any understanding of the language in which the analyzed code is written. Among the advantages is the universal applicability to arbitrary character sequences. One of the disadvantages is that differences in layout and comments may lead to clones not being detected as such. Because the clone detection is implemented as part of the ConQAT suite, it can be configured like any other ConQAT analysis based on the pipes and filters concept. Figure 3 shows a sample clone detection in the Eclipse-based editor for ConQAT blocks. Making use of the ConQAT infrastructure, the analysis results can, for example, be easily integrated into the HTML dashboard including automatically generated and interactive tree maps as the one shown in Figure 2. The next category of approaches is token-based and has a basic understanding of the language that is analyzed. This basically refers to information about which tokens exist in that language (keywords, identifiers, operators,...). After scanning the source code, clones are detected based on the scanned token sequences. The advantages include robustness against differences in layout and comments as well as the possibility to abstract from certain things like the names of identifiers. Please note that these approaches are no strictly limited to using tokens in their original sense. For example, some tools use a heuristic to merge several tokens into a single statement and detect clones based on these statement sequences. Beyond token-based algorithms, other approaches add even more knowledge about the programming language and detect clones based on the abstract syntax tree or the program dependency graph. While these approaches are able to detect clones which cannot be detected using token-based approaches, this advantage comes at the cost of a significantly increased runtime which makes them useless for larger systems. In addition, they require the source code to be well-formed and complete. Considering all categories of approaches, token-based approaches offer the best trade-off between performance and the quality of the results. The Open-Source Toolkit ConQAT To support clone analysis in practice, we have developed an open-source clone detection tool which is part of the ConQAT [2] tool suite. The tool is published under the Apache License 2.0 and free for academic or commercial use. The tool implements a tokenbased clone detection approach and offers a variety of configuration options that allow the analysis to be tailored to the system that is analyzed. It supports the detection of identical clones as well as the detection of inconsistent clones where certain tokens exist in only one of the copies. Figure 3: A sample clone detection configuration in ConQAT In addition to visualizing the results of the clone detection in the dashboard, the results can also be saved in XML format for further analysis. Apart from the clone detection tool, ConQAT also provides an Eclipse plug-in, which can be used to inspect the results in detail. The central perspective visualizes two code fragments, which are clones of each other, side by side in their respective files. This view can, for example, be used to inspect any inconsistencies that might need to be resolved. A snapshot of the Eclipse plug-in is shown in Figure 4. Professional Support by CQSE Although clones occur in every system, there is hardly an default configuration for an analysis. One of the reasons is that cloning has different characteristics for each system. Furthermore, clone detection tools usually offer a variety of parameters which need to be filled with sensible values. A misconfiguration of the detection can either lead to many relevant clones not being detected or many irrelevant code Software Quality Days

34 Copy & Paste & Bug? Figure 4: Clone inspection using the Eclipse plug-in fragments being reported as clones. Both of these situations hide the full potential of clone analysis and prevent clone-related problems from being adequately solved. To prevent this from happening, we as CQSE offer our expertise to guide the whole process from clone detection up to the analysis of the results. We have many years of expertise in clone analysis and are still actively participating in the research community. We have substantial experience in clone analysis within an industrial context from various projects with our clients. References 1. E. Juergens, F. Deissenboeck, B. Hummel, and S. Wagner. Do code clones matter? In Proceedings of the 31st International Conference on Software Engineering. IEEE Computer Society, ConQAT R. Koschke. Survey of research on software clones. In R. Koschke, E.Merlo, and A.Walenstein, editors, Duplication, Redundancy, and Similarity in Software, number in Dagstuhl Seminar Proceedings, Dagstuhl, Germany, Internationales Begegnungs- und Forschungszentrum für Informatik (IBFI), Schloss Dagstuhl, Germany. The Authors Dr. Elmar Jürgens and Dr. Nils Göde Elmar Jürgens and Nils Göde work as consultants for the CQSE GmbH. Both have written their PhD thesis on code cloning and have several years of experience on employing clone detection techniques in industry. Software Quality Days

35 Test Data Management in Practice Test Data Management in Practice Problems, Concepts, and the Swisscom Test Data Organizer Do you have issues with your legal and compliance department because test environments contain sensitive data outsourcing partners must not see? Do your testers have idle time because test data are missing or test environments have inconsistent data? If any of these challenges applies to your situation, the concepts of this paper can help. The first concept is database-application-aware test cases. They enforce that test cases for business applications provide all information needed for repeatable execution. Second, a type concept eases the test case maintenance and preparation of test data for a test start without delays. Third, a test data catalogue lists database objects for the various types. Finally, architectural patterns describe various ways to set up test environments with production and/or synthetic test data. This paper focuses on integrating these concepts into the daily test process. This includes the tool aspect, which we illustrate with our Swisscom Test Data Organizer. Motivation Over the last decades, IT systems have become increasingly complex. The same holds true for testing them. Today, testers need an in-depth understanding of IT architectures and testing methodologies. A sample mobile app illustrates the phenomenon. The app enables bank customers to do intra-day trading in equities. The app runs on various smartphones. It sends trades to the bank s core banking system, which forwards the trades to a stock exchange. Endto-end tests for such architectures are challenging. First, testing must consider various mobile platforms and smartphone types. Second, many interfaces must be tested. Third and often overlooked, testers need consistent test data on the smartphone, the core-banking system, and the trading server. How to manage such test data efficiently is the focus of this paper. Test data management covers all concepts and tools for ensuring that the data in the databases of a system-under-test fulfill the preconditions of test cases. Is there a test user in the core-banking system? Is the tester allowed to trade certain financial instruments? Is the account balance of his account sufficient? Getting the precondition for a test case right can be more challenging than its execution. This paper provides answers for the following questions: Why and when does test data management matter? What are the benefits? What are the main test data management concepts? How can the concepts improve processes and make the daily work more efficient? The answers are based on three pillars. Pillar one is our conceptual work on testing database applications throughout their life cycle [1][2][3][4]. Pillar two is a vendor s perspective on developing and testing database applications [5]. Pillar three is made of our insights from various consulting projects [6]. The three pillars together allow us to formulate today s best practices in test data management. The structure of the paper is as follows: after a short discussion of related work (page 33), the paper explains aims and approaches of test data management projects (page 34f). This is followed by the various concepts for test data management (page 35ff) and the system architecture of Swisscom s Test Data Organizer (page 39f). After discussing the test data management related tasks and roles in the testing process (page 40ff), the paper concludes with a short summary (page 42f). Related Work Test data management and testing databases are highly relevant for many companies. However, it is only a niche topic in research and on conferences. Thus, only limited related work exists. The related work falls mainly into three groups: 1. Testing in general. Much literature exists on how to test. Perry [7] is a profound example. His book spans from the various testing stages or process aspects to testing data warehousing and web applications. Other examples are books preparing for certifications such as from ITSQB [8]. They introduce a common terminology, discuss testing techniques, and describe a general process Software Quality Days

36 Test Data Management in Practice for testing. Test data management or even testing database applications is, if it exists at all, a side aspect. 2. Papers on test automation of database applications. These focus (mostly) on unit or unit integration tests and describe test frameworks. Examples are the AGENDA prototype (Deng, et al. [9]) and the work of Dai and Chen [10]. More theoretical work comes from Willmor and Embury [11]. There are also commercial tools for testing business logic in the database, such as the Quest Code Tester for Oracle [12]. Obviously, testing Oracle PL/SQL code demands dealing with (test) data in the database. 3. Provisioning techniques for test data. A straightforward concept for populating a database is analyzing its schema. A random generator then populates the tables with suitable data (Houkjær et al. [13]). This might help for unit tests or load and performance tests for non-complex data constellations. Binning et al. [14] suggest a more sophisticated approach. They create a database state based on one or more constraints respectively queries. Suárez-Cabal and Tuya provide a concept helpful for data warehouse tests. It remove rows from large data sets that do not contribute to test coverage [15]. Finally, there are techniques to anonymize (test) data [16][17]. All techniques (besides anonymization) are especially helpful in early test stages (unit tests, unit integration tests), which is common for academic papers. This paper complements the existing work. It combines industry experience and organizational success factors (e.g., processes) while focusing on late test stages. Writing a Business Case: Aims & Approaches Managers invest in test data management projects only if there is a business case. The business case defines, first, the aim of the project. This is the need of the business the project wants to address. Second, a business case sketches the technical approach used to achieve the aim. Finally, the business case provides a high level project plan and cost estimations. Costs and project plans are project-specific, while the aims and approaches are generic. This section explains the important aims and approaches. A test data management business case aims to optimize the testing or/and to improve data privacy. Business cases built around data privacy do not argue with cost savings. They focus on regulation, reputation, and trade secrets. Regulation means that e.g. laws (e.g., data protection acts, bank secrecy) demand the protection of certain data. Noncompliance can result in law suits and interventions of regulatory bodies. Reputation focuses on how customers, employees, society, etc., perceive the company. If, for example, customer data become public and the media pick it up, current and potential customers question the reliability of the company. This happened with Lufthansa when frequent flyer data of German politicians found their way to the press [18]. Finally, trade secrets can be a reason to invest into test data management, too. Examples are customer lists or production process details. If competitors get copies of such data, it can ruin the company. Today, IT departments are aware that production databases store sensitive data, so access control mechanisms are in place. Business users see only data they need for their work. In contrast, IT departments often ignore the risk of test servers. Many contain production or production near data. The data are copied periodically or on request from production to the test servers. Such data eases (or might even be a prerequisite for) system tests, system integration tests, and user acceptance tests. As a result, many developers and testers can potentially access production data on test servers. They might even have access rights and tools to extract large data sets (e.g., by running an SQL-queries for all customers). This is a high risk for data loss. An aim of a test data management project can be to mitigate this risk. Optimizing the testing by ensuring repeatable tests, relevant test execution, and efficient data provisioning is the second potential aim for test data management projects. Relevance means that a test execution reflects the purpose of the test case. A test case might be that a US citizen who lives in Singapore buys bonds at the London Stock Exchange. This test case must not be executed with a US citizen living in the US. Executing tests with wrong data is useless and a waste of time and money. Repeatability is closely related. Testing and bug-fixing make a chain of actions. When a tester finds a bug, he reports the bug to the developers, who fix the bug. Then the tester re-tests to see whether the bug-fix solves the bug. Repeatability requires that the re-test after the bugfix can be done with data/databases semantically Software Quality Days

37 Test Data Management in Practice equivalent to the one being processed when the bug occurred. Efficient test data provisioning appears on the agenda when test organizations have mastered the basics. One challenge can be the logical distance between test data creation and consumption. It is common for system integration tests that testers need data created in applications, modules, or by batch jobs they do not know. Then the data flow via other modules and applications to get finally to the system under test. Test data management projects can optimize how testers get data from logical far away applications. When test centers already use anonymous or synthetic test data, they might want to improve the efficiency. Such test data provisioning might require tool knowhow or that only dedicated persons are to be allowed to do tasks such as anonymizing production data. This demands an optimal organization to keep costs low and prevent delays in test projects. Optimization and data privacy are the two main aims for test data management projects. There are four main approaches a business case can propose to reach them. Anonymization promises to take production data as input and, by masking or shredding data or swapping values, to produce sanitized data. In reality, it is more obfuscation or veiling than true anonymization (see [3] for more details). Synthetic test data. This data are not derived (neither anonymized nor non-anonymized) from production data. They are defined and hand-made for concrete test cases. Database application test tools. Test case management tools must reflect the specifics of testing database applications and IT landscapes. This might require new tools or, as is often easier to achieve, customizing tools already in use. Processes & Organization. Databaseapplication-specific tools and anonymization tools bring only benefit to the organization when aligned with the daily work (i.e., the testing process and the organization). Figure 1 summarizes the suitable approaches for concrete projects. If the aim is data privacy, the approaches of anonymization and synthetic test data help. Certainly processes & organization must be addressed too. The aims relevance and repeatability require improved tools and adjusted processes & organizations. In contrast, improving test data provision requires working on processes & organization first. Certainly, better tools might bring benefits, too. Database Applications & Application Landscapes TDM Project Aims: Why to invest? Data Privacy Reputation Regulation Trade Secrecy Relevance Repatability Provisioning Test Optimization TDM Approaches: What to invest in? Anonymization Techniques Synthetic Test Data DB Application-specific Test Tools Processes & Organization Budget & Timeline PROJECT TDM Phase 1 Internal External Phase 2 Internal Exteral PROJECT TDM Phase 1 Phase 2 Figure 1: Business Cases for Test Data Management Projects Test Data Management Concepts Fig 01 A successful test data management project implements three concepts: database-application-aware test cases, test object types, and a test catalogue. This section describes them and brings them together in one UML class diagram. Furthermore, it discusses architectural patterns. They describe how to set up test environments focusing on what test data are used. This is a need if the business case aims for data privacy. Database-Application-aware Test Cases Database applications incorporate one or more databases. The state of the database (i.e., its data) impacts the test result. So a test case must specify the database state precisely. Then the test case execution is repeatable. Such test cases are named database-application-aware test cases (Figure 2; see [3] for a detailed discussion). Many test cases for database applications do something with one object, the database test object. The one object can be a US citizen living in Singapore when testing tax reports. The one object can be a debit card when testing ATM withdrawals. However, the one object alone is not sufficient to run the test case. ERP systems, for example, have hundreds or thousands of tables. They must contain clients, accounts, branches, etc. The data must be consistent enough that the system runs and does not cause false positives. Only few data items really matter, e.g., the system date for testing end-of-year batch jobs. All tables together with their data form the database test system state. To formulate it in a more prosaic way, the database test system state sets the stage for a play. The play is the test case. The database test object is the main actor. Software Quality Days

38 Test Data Management in Practice Certainly, test cases must define the normal test case attributes as well. These are the test steps, the GUI input, and expected GUI-output. If the test cases provide all this information, database-applicationaware test cases ensure repeatability. (GUI) input parameter values Database test object Database test system state Test case steps to be executed Application Logic & GUI Database System under test Figure 2: Database-application-aware test cases Expected output parameter values Test Object Types Database test objects are often complex and have many attributes. Test object types make clear which attributes really matter. A type definition consists of: Name and Description. They ease using and maintaining a type for testers. Semantically mandatory attributes. When a database test object of this type is created, all semantically mandatory attributes must have the values as specified in the database object type definition. This has implications for writing test cases too. If a test case needs an US client living in Singapore, the test case must use a database test object type with these attributes. If none is available, testers must define a new type. Consistency mandatory attributes. These attributes ease the test data creation but must not be relied upon while defining and executing test cases. GUIs or databases often demand attributes to be filled out that are not relevant for the test case. An address might require a city and a ZIP code, even if the test case only needs the country. Consistency mandatory attributes are a way to write down suitable values and value combinations work (e.g., ZIP code 8001 and city Zurich ) to smooth the test data creation. Testers can never rely on any of these values. Irrelevant attributes. They are not relevant for the test case and are not required by the system. They can have an arbitrary value or remain empty/null. Reusability flag. The flag defines how objects Fig 02 of this type can be used. When the flag is set to reusable, test cases must not modify the values of semantically mandatory attributes. Test centers or projects must manage their test object types. A straightforward way is with an Excel sheet, as in Figure 3. The Excel sheet lists five types plus the relevance of and values for certain attributes. When a tester writes a test case, he might need a customer with the country of residence CH. During the test execution, the country changes to AU. Then a suitable test object type must consider two requirements. First, the type must have a semantically mandatory attribute Country of residence with the value CH. In Figure 3, three test object types fulfill the requirement: Credit Rating Tests 5, Credit Rating Tests 6. and Swiss Wealth Management. The second requirement is that the test object type must not be flagged as reusable, because the test case changes the semantically mandatory attribute Country of residence. After the execution of the test case, the used object is destroyed. The object cannot be used for rerunning the test case, since the country is now AU. The second requirement, nonreusable, narrows down the list of suitable test object types for the sample test case to Swiss Wealth Management. Before the execution of the test case, an object of the type Swiss Wealth Management must be created or found in the existing data. Both the country of residence and the customer type are fixed ( CH / Wealth Management ). All other attributes can get any value. A suggestion provided by the definition is to use CH as nationality. A simple Excel sheet, as in Figure 3, looks like a solution for one tester. However, all testers of a project (or even complete test centers) can collaborate if the Excel document is put on a Sharepoint server. The Excel sheet comes to its limit when database test object types are complex. Sketching a diagram as a specification is one solution (Figure 4). The figure exemplifies a type with a US client living in Austria having one safekeeping account with two specific equities. Certainly, a tool-based solution is possible instead of Excel sheets. The Swisscom Test Data Organizer described later is an example. Tools can ease the integration of the type management into the test process. Software Quality Days

39 Test Data Management in Practice Figure 3: Simple Test Object Types for Clients (grey cells: semantically mandatory, white cells: consistency mandatory, empty cells: irrelevant) The benefits of test object types are improved maintenance, clear communication, and delay-free starts of testing. 1 Improved maintenance addresses that objects in a database change, whereas regression test cases are often stable for years. A test case might define that it should be tested using the client with ID # The reason is that this client lives in Switzerland. Some months later, the client moves to Australia. The test case still points to the client though he is not useful any more. Any tests run with this client are worthless; nobody might notice that. Test object types solve this. A test object type defines the kind of object needed when writing the test case. It defers the selection of a concrete object until the test execution. Clear communication is a side-effect of test object types. A test case stating, Use suitable US customer, is not clear for anyone besides perhaps the person who writes the test case. A test case specified as in Figure 3 is clear. This improves collaboration and know-how transfer. This helps in two scenarios: if testers in a project change or if one tester writes the test case and a second tester executes the test case, potentially in a country time zones away. Delay-free starts of testing means that the start of a test is not blocked by missing test data. A test manager derives from the test cases what test data he needs. He can do this well before the start of testing. He plans which testers provide the data, or he contacts other teams from which he needs data. This is important if the data cannot be created ad-hoc but requires, for instance, one or two overnight batch jobs to run beforehand. 1 While test object types are helpful, there is no need for a type concept for database test system states. A state should be described in detail to understand its purpose (e.g., end of year test 2013). However, one file with the database export is sufficient. It can be imported into as many test environments as needed. Account AcD: NUMBER(12) Currency: VARCHAR2(3) Customer CusID: NUMBER(12) Name: VARCHAR2(100) Nationality: VARCHAR2(3) Country of residence: VARCHAR2(3) US AT Safekeeping Account SkAID: NUMBER(12) Currency: VARCHAR2(3) EUR Safekeeping Account Position PosID: NUMBER(20) Equity: VARCHAR2(12) SCMN UBSN Quantity: NUMBER(20,2) Figure 4: Complex Test Object Type Specification Fig 4 Test Data Catalogue When a tester is asked to execute a test case, she opens the test case definition, e.g., in Jira or HP Quality Center. She sees the test steps she has to execute. She sees the database test system state and the database test object type. Next, she must find a concrete object in the database that fits to the database object type, e.g., a US citizen. To find a suitable client, she can query the database and its tables. This works if all testers can access the databases on an SQL level and the queries are not too complex. Also, tests should not interfere if, by chance, various tests use the same objects. The mentioned criteria can be met, but probably only seldom. Then a database test object catalogue helps which provides a list of suitable objects for each database test object type; and allows reserving database test objects for testers. Figure 5 contains a sample test data catalogue realized in an Excel sheet. Again, if put on a Sharepoint server, even complete teams can work with this one catalogue. A more advanced concept is a dynamic catalogue on the level of a test center. It is updated based on querying the database for fitting objects. These queries can be submitted in an ad-hoc mode (the database is queried when a tester looks for an object) or run as overnight batch job. Later, this paper sketches an implementation. Software Quality Days

40 Conference Journal 2013 Test Data Management in Practice Figure 5: Excel-Based Test Data Catalogue UML Class Model for Test Data Management The UML class diagram for test data management (Figure 6) unites the three concepts of databaseapplication-aware test cases, test object types, and a test data catalogue. It is the base for our Swisscom Test Data Organizer (described later) and can also guide other test centers when incorporating test data management into their tool chain. The class diagram has three areas. The upper area represents typical functionality of test management tools: Test Case Definition. This class represents a test case/test case definition. Test Case Execution. This class represents one execution/result of a test case execution. The only extension compared to normal test case executions is a reference to the database object that was used when running the test. The lower area represents the database of the system under test. Database Object. This represents a data item (or a combination of data items) in the database of the system under test. The middle area contains all classes specific for test data management. Today s test management systems usually do not provide this functionality. Database Test System State. This class models a state as a database export, e.g., an Oracle database export file. The class stores the name and the location of the export file plus links to the database from which the export comes. Thus, one repository can manage all exports from various databases of a test center. Test States Repository. This class is responsible for managing the database test system states of the various applications. Test Data Catalogue. This class manages a list of entries and provides the Update() method that update the entries. Entry. An entry links to an actual object in the database and states for which database test object type it could be used. The database object can be locked for exclusive use by a tester. This prevents various persons using the same object and interfering. Database test object type. Test cases can have one database test object type. It has common attributes such as a name and a description plus the reusable flag (see page 36). As an abstract class, only its two subclasses can be initialized: - Static DB test object type. A static type is a user-defined list that links to suitable database objects. - Dynamic DB test object type. The class has two attributes, a database connection string and an SQL query. The SQL query is used by the Update() method of the class Test Data Catalogue to query the database and to update its entries. The connection string identifies the concrete database from which to pull the data. Test Case Definition 1 0..* 0..* 0..* Test States DB Test System State Repository Name Description DumpRepository 1 DumpFilename 0..* Dynamic DB Test Object Type SQLQuery ConnectionString Test Case Execution Static DB Test Object Type Generic Object Model for Testing Test Data Management Specifics DB Test Object Type Name 1 Test Data Catalogue Description Entry Update() Reusable 0..1 Reserved for 1 Reserved till 0..* 0..* 0..* DB Object Figure 6: Object Model Test Data Management System under Test Fig 6 Data-privacy Aware Test Environments When data privacy issues are a reason for a test data management project, it raises the question: should test environments have production data? Various patterns exist that differ when it comes to using production and/or synthetic data for testing. Figure 7 illustrates the main patterns. The classic pattern copies all data from production to the test environment. There are no restrictions in place to prevent testers and developers from seeing production data. The on-top pattern protects production data to a certain degree. The test environment is a copy from production. It is enriched with synthetic test data. There is, for example, one tenant of the application working with the synthetic data. So (certain) testers test on the tenant with synthetic data. If they have no database access, these testers do not see production data. Software Quality Days

41 Test Data Management in Practice The castrate & inject pattern sanitizes the database from critical data by deleting critical data ( - ) or masking/anonymizing it ( *M* ). This is can be done on a table, column, or row level. So names, such as IBAN account numbers and booking texts, or rows of customers from a specific country are deleted. If testers need some kind of data that is completely eliminated (e.g., IBAN numbers), synthetic data are inserted into the tables ( Synth ). Finally, the isolated towers pattern provides maximum data protection. The production and the test environments do not exchange any data. The test environment contains only synthetic data. Software vendors rely on this pattern, if their customers are not willing to provide database copies for them or if they want to build up a controlled data set for testing and demonstration purposes. This pattern is expensive for late-testing stages, such as system integration test environments or even system test environments for complex applications. However, it might be the only option for vendors or in the case of cross-border regulation issues. Classic On-top Castrate & Inject Isolated Towers B C D A A B C D Prod Prod Prod Prod Prod Prod Prod Prod Prod Prod A Z A Z Prod Prod Synth Prod Prod Synth A X Y A X Y Prod Copy Prod Prod Copy Prod Prod Prod Prod Prod Prod Prod *M* Prod Prod Prod Synth Synth Synth PROD TEST PROD TEST PROD TEST PROD TEST Figure 7: Production and Synthetic Test Data in Test Environments - Four Patterns (The eye symbolizes data testers can see.) Swisscom Test Data Organizer: The System Architecture Fig 7 Currently, most test management tools do not support test data management well. Thus, test centers can either invent or invest in additional tools or try to integrate the missing aspects in their existing tool chain. Obviously, the latter is less expensive and less risky. It allows the user to focus on solving the test data management challenges and to rely on industry best practices for everything else. Consequently, the Swisscom Test Data Organizer builds on top of HP Quality Center. It was chosen for three reasons: 1. Process-focus. Quality Center supports the complete testing process from test cases and test execution to test reports Openness. HP is a vendor that supports tool 2 Many potentially better known tools, such as Selenium, JUnit, and HP Quick Test Professional, do not meet this requirement. They are test automation and not test management tools. extensions. This is a technical decision, but it has a strong foundation in HP s partner-friendly business model. 3. Relevance. Quality Center has a relevant penetration in the financial industries in Switzerland. The Swisscom Test Data Organizer extends two Quality Center modules, TestPlan and TestLab. Test engineers, analysts, and managers can specify and manage test cases in TestPlan. Test managers can define test sets in TestLab. A high level understanding of a test set is that it contains a set of test cases. They might belong to one software release and, thus, are tested together. TestLab documents also the test results. The Swisscom Test Data Organizer uses three options for parameterizing Quality Center: Adding new attributes and buttons to existing GUI masks. Implementing new functionality in Visual Basic Script. The code is triggered e.g., when pushing buttons Accessing Quality Center data via the Quality Center API Open Test Architecture (OTA) with a web application The driving architectural principle is to implement as much as possible in Quality Center. Thus, the Test Data Organizer has three components (Figure 8), TDO-EXT, TDO-CUS, and TDO-SCHEMA. TDO-EXT is a web application. It implements the test data type management and the test data catalogue in Visual Basic. These features are too complex for Quality Center internal extensions. TDO-EXT runs outside Quality Center in a Microsoft IIS. TDO-CUS contains the parameterization of Quality Center: new buttons, lists and Visual Basic Script code running within Quality Center. This covers the test case extensions for database test system states, test object types, and recording the concrete database object used in tests. It also implements links to TDO-EXT. TDO-SCHEMA is a database schema. Its tables store data that cannot be pressed into the Quality Center data structure. One example is of the database test object types. The types are not a simple list of type names (this would be easy to implement in Quality Center). The types also have additional attributes such as SQL queries (see Figure 6), which do not fit to the Quality Center schema. All tables, Quality Center tables and TDO-EXT and TDO-CUS tables, reside in the same Oracle database on which Quality Center Software Quality Days

42 Test Data Management in Practice runs. This prevents access problems. The following section provides some screenshots of the tool and explains the roles of various GUIs in the test process. Microsoft IIS TDO- EXT QC OTA Library HP Quality Center Test Plan Test Lab TDO-CUS Oracle DB TDO Schema QC Schema Figure 8: System Architecture Test Automation System under Test Test Data Management in the Testing Process Managers invest in projects to achieve sustainable improvements. Sustainable improvements for test data management means, first, to integrate the test data management tasks into the test process and, second, to clarify roles and responsibilities. This section explains the best practices following a high level test process (Figure 9). Specify Test Cases Specify Test Case Choose Test Data Type Choose System State Plan Test Compile Test Cases Order Test Data Test Data Provisioning Manual creation Script-based creation Execute Tests Execute Test Case Select Matching DB Object Fig 8 base test object type and the database test system state. Figure 10 contains a screenshot from HP Quality Center with the two additional attributes. They are implemented in the TDO-CUS module. Step Plan Test When all test cases are defined, the test manager can start planning (Figure 9, ). She compiles the test case set to be executed. It contains newly defined ones plus older regression test cases. This is done in Quality Center. The test manager plans the staffing and defines milestones. She orders the needed infrastructure: servers, databases, or mobile devices. Her new test data management task is to plan the test data activities, which can be done by her testing team. If a centralized test data team exists, the test manager can order her test data with them. This can require some previous coordination. The test data ordering itself is done with the test data order form (Figure 11). It runs outside Quality Center in the TDO-EXT module. TDO-EXT retrieves the list of database test object types. This list is based on the test case set compiled in Quality Center. Next, TDO-EXT queries the system-under-test to get the number of existing objects per test object type. Then the test manager can decide how many test data objects of which type she wants to order. Her test order triggers the actual test data provisioning. Manage Types & States Figure 9: Test Data Management and the Testing Process Step Specify Test Cases The first step in the high level test process is the spe- Fig 9 cify test case step (Figure 9, ). The tester takes the software specification, analyses it, and writes the test cases. No single line of code might exist at this point in time. The tester has to fill out two additional attributes per test case. The attributes are the data- Figure 10: Test Case in HP Quality Center with extensions Database Test System State and Database Test Object Type Software Quality Days

43 Test Data Management in Practice Figure 11: Test Data Order Form Step Test Data Provisioning Test data provisioning is the umbrella term for creating or identifying test data (Figure 9, ). Identifying test data can be done by querying the database. This might need more time in a complex IT landscape without federated database schema, but it is often a viable option. The second option is to create test data. This can be a manual data input via the GUI or by some GUI-level test automation in QTP or Selenium. It can be an input file for batch jobs, or data might be loaded on the database level using SQL, too. The various options are discussed in more detail in [3]. The management has to make two organizational decisions. First, responsibilities have to be defined. Three options exist. Each tester takes care of his data. One team member takes care of all data of the team. Finally, a centralized test data management team can provide the data. The choice depends on the complexity of the environment or needed tool know-how and governance decisions in case of test data anonymization. The second management decision is the process integration in case of dedicated persons or teams providing test data. The orders have to be tracked and assigned to test data provisioning engineers. This can be done by , but a ticketing system such as Jira is preferable. Step Test Execution When the application is ready for testing, test engineers test manually or start the test scripts (Figure 9, ). In any case, the test case defines the test object type. It does not point to a concrete test data object. The test data catalogue helps by listing all database test data objects of the needed type. The Swisscom Test Data Organizer implements this functionality in the TDO-EXT module. Quality Center calls it at the start of the test case execution. TDO-EXT queries the TDO-SCHEMA for fitting objects for the type specified in the test case. In the example in Figure 12, the test case is CH Customer. TDO-EXT identifies 10. Schmid, Florina as the only suitable object. When pushing the OK button, the object is pushed back into Quality Center. Thus, the test report contains the full information which data were used for the test execution. This eases analyzing bugs and retesting them. Fig 11 Software Quality Days

44 Test Data Management in Practice Figure 12: DB Test Object Selection GUI Figure 13: Managing and Adding Test Object Types Task Manage Types & States Managing database test object types and database system states impacts all test cases and all projects in a particular area. Properly done, there are synergies between projects and testers if types and states are coordinated. Then various projects use the same scripts for creating objects of a certain type. This reduces analysis, automation, and maintenance costs. Figure 13 shows the GUI implemented in TDO-EXT for the type management. It allows adding new test object types, static and dynamic, reusable or nonreusable, as described earlier. Roles and Responsibilities We conclude this section with a table listing all roles test engineers, test managers, test analysts, and test data providers and their tasks (Table 1). This provides a good overview of what test data management means in practice. Role Test Engineer TDM tasks Define the database test object type for each test case Define the database test system state for each test case Choose and document chosen test objects for manual test execution Test Data Provisioning Engineer *) Create and manage database test objects Create and manage database test states Table 1. Roles and test data management related-tasks *) might be taken over by test engineers themselves. Summary Test centers that deal with many business and database applications invest in test data management for two reasons: improving data privacy, i.e. having less or no production data in test environments, and/or making testing more efficient. This paper describes four concepts to reach the aims: 1. Database test object types. They are an easy-to-maintain way to specify with which kind of object a test case is executed. The key point is that the test object type is stable over years, whereas objects in the database change frequently. 2. Database-application-aware test cases. They require the specification of test object types and database system states in test cases. This ensures repeatable tests. Test Analyst Test Manager Manage test object type definitions Manage system state definitions Identify test data needs/order test data 3. Test data catalogues. They point to concrete objects that implement a test object type. 4. Privacy-aware test environments. They reduce or remove exposure of production data to testers and developers. Software Quality Days