Neues von der REFSQ Requirements Engineering: Foundation for Software Quality
Essen, 27. Februar bis 2. März
Drei Tage Konferenz mit parallelen Sitzungen fasst man nicht mal schnell in fünf Zeilen zusammen. Ich habe darum das herausgesucht, was auch aus praktischer Sicht handfest nützlich ist. Auf einer wissenschaftlichen Tagung werden ja auch vorläufige Ergebnisse, Forschungsvorschauen, Ideen und Meinungsbeiträge veröffentlicht.
Grundsätzlich scheint der Trend im Requirements Engineering in Richtung Automatisierung zu gehen. Das widerspricht nicht unserer Vision eines kreativen Requirements Engineering, denn es gibt genug unkreative Tätigkeiten in diesem Bereich. Jede langweilige, routinemäßige Tätigkeit ruft ja geradezu nach Automatisierung, um den Kopf für neue Ideen frei zu halten.

Ein guter Teil der Automatisierung betrifft die Identifikation und Analyse von natürlichsprachlichen Anforderungen. Nachdem diese eigentlich chaotische Art der Anforderungsspezifikation in der Praxis immer noch vorherrscht, machen wir das Beste daraus.

• Prof. Lionel C. Briand gab in seinem Keynote-Vortrag "Analyzing Natural-Language Requirements: The Not-Too-Sexy and Yet Curiously Difficult Research that Industry Needs" eine Übersicht über die automatisierte Bearbeitung von Text allgemein und Anforderungen im Speziellen. Ziel der Textanalyse ist beispielsweise die Übersetzung, Qualitätsprüfung, aber auch die Impact Analyse, d.h. herauszufinden, welche anderen Textstellen noch zu ändern sind, wenn qeine Anforderung sich ändert. Nähere Informationen zum Tool RETA (für Vorlagen-Compliance-Prüfung) finden Sie hier. Das Werkzeug Narcia führt eine Change Impact Analyse durch.
• Martin Wilmink, Christoph Bockisch: On the Ability of Lightweight Checks to Detect Ambiguity in Requirements Documentation. pp. 327-343. Natürlichsprachliche Anforderungen leiden unter anderem unter dem Nachteil, dass sie uneindeutiger sind als Modelle. Diese Arbeit hat ein Werkzeug namens tactile check entwickelt, das Mehrdeutigkeiten in Anforderungen automatisch findet. Nähere Informationen zum Werkzeug bei Github.
• Garm Lucassen, Fabiano Dalpiaz, Jan Martijn E.M. van der Werf, and Sjaak Brinkkemper:
  Improving User Story Practice with the Grimm Method: A Multiple Case Study in the Software Industry. pp. 235-252. Hier wird die Qualitätssicherung von User Stories automatisiert mit Hilfe des computerlinguistischen Werkzeugs Automatic Quality User Story Artisan (AQUSA). Die Kombination von AQUSA mit dem Quality User Story (QUS) Framework nennt sich die Grimmsche Methode. Ausprobiert wurde die Methode von 30 Praktikern in drei Firmen für zwei Monate. Die Qualität der User Stories verbesserte sich tatsächlich messbar, die Teilnehmer fanden die Unterschiede jedoch weniger wichtig.
• Paul Hübner, Barbara Paech: Using Interaction Data for Continuous Creation of Trace Links Between Source Code and Requirements in Issue Tracking Systems. pp. 291-307. Diese Arbeit kümmert sich um das Stiefkind Traceability. Da diese üblicherweise händisch nur nachlässig gepflegt werden, verspricht die automatische Identifikation von Traceability-Verknüpfungen praktische Hilfe. In einer Fallstudie wurden solche Links automatisch im Issue Tracker System (ITS) gefunden und angelegt.
• Carles Farré, Xavier Franch, and Tudor Ionescu: State of the Practice on Software Release Planning. Dieser Beitrag aus dem PrioRE-Workshop untersuchte die Fähigkeiten von Release-Planungs-Werkzeugen und verfolgte dabei die Idee zu prüfen, wie weit Algorithmen aus der künstlichen Intelligenz dort bereits eingesetzt werden. Ihre frühere Literaturstudie hatte gezeigt, dass von den vielen entsprechenden Forschungsansätzen nur einer den Sprung zum kommerziellen Werkzeug geschafft hatte. Nun untersuchten sie umgekehrt, was sich in real existierenden Werkzeugen befindet. Den Artikel finden Sie online hier.
• Norbert Seyff, Melanie Stade, Farnaz Fotrousi, Martin Glinz, Emitza Guzman, Martina Kolpondinos-Huber, Denisse Munante Arzapalo, Marc Oriol, Ronnie Schaniel: End-user Driven Feedback Prioritization. Dieser Beitrag aus dem PrioRE-Workshop beschäftigt sich, wie man das Feedback von Endnutzern einer Software automatisiert auswerten und bewerten kann, ohne dass ein Mitarbeiter die Textfülle lesen und sortieren muss. Die Autoren können noch keine fertige Lösung präsentieren, zeigen jedoch erste Ideen für Lösungswege auf. Den Artikel finden Sie online hier.

Weitere handfeste Ergebnisse lieferten folgende empirischen Studien:

• Irum Inayat, Sabrina Marczak, Siti Salwah Salim, and Daniela Damian: Patterns of Collaboration Driven by Requirements in Agile Software Development Teams -
  Findings from a Multiple Case Study. pp. 131-147. Hier wurden in mehreren Fallstudien die Kommunikationsmuster innerhalb verteilten agilen Teams untersucht. Das erstaunlichste Ergebnis besteht darin, dass die Entfernung keine Rolle zu spielen scheint. Ältere Studien legen eher nahe, dass jede Treppenstufe schon die Kommunikationshäufigkeit und -qualität mindert. Allerdings kann ich mir gut vorstellen, dass hier zwei Faktoren dazu führen, dass es in modernen agilen Teams besser läuft: Erstens wird in agilen Teams die Kommunikation sehr stark betont und geregelt und zweitens ist es für uns heute völlig normal, mit Menschen zusammen zu arbeiten - oder auch privat befreundet zu sein - die sich weit entfernt befinden.
• Katsiaryna Labunets, Fabio Massacci, and Federica Paci: On the Equivalence Between
  Graphical and Tabular Representations for Security Risk Assessment . pp. 191-208. In zwei Experimenten wurden zwei alternative Notationen für Sicherheitsrisiken miteinander
  verglichen: graphische Notationen und Tabellen. Beide erwiesen sich als gleichwertig
  bezüglich ihrer Effektivität.

CreaRE 2017: Sixth International Workshop on Creativity in Requirements Engineering

Das wichtigste Event im Februar war für mich die REFSQ-Tagung, bei der ich seit 2005 Teilnehmerin und meist auch Mitorganisatorin bin. Dieses Jahr bestand mein Beitrag darin, zum sechsten Mal den CreaRE-Workshop zu organisieren. Er fand am 27. Februar in Essen statt. Das Programm bestand aus drei Vorträgen und einer interaktiven Sitzung.

• Luisa Mich, Victoria Sakhnini and Daniel Berry: Downsizing EPMcreate to Lighter Creativity Techniques for Requirements Elicitation. EPMCreate ist eine kreative Methode, um Requirements zu erheben durch den definierten Wechsel der Perspektive. Die Methode umfasst in ihrer ursprünglichen Form 16 Schritte, was sich als recht aufwändig herausgestellt hat. Darum verfolgte dieser Vortrag die Frage, wie man aus den 16 Schritten einschrittige, zweischrittige, dreischrittige usw. Methoden entwickeln kann und welche davon schon existierenden Kreativitätstechniken entsprechen. Am Ende sollen alle Perspektiven abgedeckt sein.
• Eduard C. Groen, Matthias Koch and Andreas Maier: Vicus – A Persona for Towns:
  Die Autoren beschäftigen sich damit, Anforderungen für den Bereich Smart Towns zu erheben. Hier sind die Bedingungen etwas anders als sonst im Requirements Engineering. Nicht einzelne Stakeholder oder Gruppen sollen betrachtet werden, sondern ganze Städte oder Dörfer als Gemeinschaft. Darum verwenden die Autoren hier Personas, um eine ganze Stadt zu charakterisieren. Dabei verwenden sie eine entsprechende Vorlage.
• Nils Kubischok: Imagining the future: A social science approach to the importance of visions in the software development process. Die Sozialwissenschaften wissen, wie erwartungsformend und handlungsweisend Visionen auf Menschen wirken. Im Requirements Engineering wird dies bisher nur erahnt. Dieser State of the Art Artikel zeigt dies in einer Übersicht und begründet die Bedeutung von Visionen im Requirements Engineering.
• Kristian Beckers, Veronika Fries, Eduard C. Groen and Sebastian Pape: Creativity Techniques for Social Engineering Threat Elicitation: A Controlled Experiment (interactive session): Für dieses Experiment wurden wir in drei Gruppen aufgeteilt. Alle Gruppen verfolgten das Ziel, Social Engineering Bedrohungen zu finden, die einer Konferenz gefährlich werden können. Die einen spielten ein Kartenspiel, ein Serious Game, die anderen sammelten per Brainstorming jeweils Listen von Opfern (victims), Werten (assets), Angriffskanälen (channels), psychologischen Prinzipien (psychological principles), Angriffen (attacks) und Angreifern (attacker) und kombinierten mit Hilfe der Technik Morphological Forced Connections diese miteinander zu konkreten Angriffsszenarien.

Ich war in der zweiten Gruppe. Da wir für jede Kategorie jeweils ungefähr 10 Ergebnisse fanden, überschlug ich schnell, dass wir im Prinzip bis zu einer Million Szenarien bilden können. Das fühlte sich etwas frustrierend an. Womit beginnen? Grundsätzlich glaube ich aber, dass wir so ziemlich alles gefunden haben, was man sich nur denken kann.
Die Gruppe "Kartenspiel" berichtete von Spielspaß und dem Vergnügen, hinterhältig zu sein.
Sie fanden die Karten hilfreich, gerade für Nicht-Experten, die sich über Social Engineering
zuvor noch keine Gedanken gemacht haben, um in die Thematik sehr anschaulich hinein
zu kommen.
Die Ergebnisse der beiden Gruppen werden im Nachgang wissenschaftlich miteinander verglichen. Ich bin gespannt, was dabei herauskommen wird!

Die Vortragsfolien können Sie von der Workshop-Webseite herunterladen unter "Workshop Program" und die zugehörigen Proceedings sind hier online.
Hier finden Sie auch die Proceedings der anderen REFSQ-Workshops.

Neues von den Software Quality Days SQD
Die SQD fand am 17. bis 20. Januar in Wien statt. Auf dieser eher praxisorientierten Konferenz werden Best Practices und Erfahrungen ausgetauscht. Ich selbst hielt am 20. Januar einen Workshop über Ethische Entscheidungen im Software Engineering ab.

Von den Vorträgen gefielen mir diese am besten, weil sie wirklich Neues und Nützliches brachten:

• die beiden Vorträge von den Herren Jürgen und Pagano über Test Gap Analyse:
  "Haben wir das Richtige getestet? Erfahrungen mit Test-Gap-Analyse im Hotfix-Test, Iterationstest und Releasetest in der Praxis" und "Oh nein, morgen ist Release! - Test-Gap-Analyse live am Beispiel".
  Es handelt sich dabei um die Visualisierung von zwei unterschiedlichen Aspekten derselben Software als Tree Map: Die Information, welche Codestellen geändert wurden, und welche bei Tests ausgeführt wurden. Besonders kritisch sind diejenigen, die zwar geändert, aber nicht getestet wurden. So offenbart sich Nachholbedarf. Natürlich macht man diese Auswertungen nicht von Hand, sondern mit dem Werkzeug TeamScale, das sich momentan noch in der Pilotphase befindet und kostenlos erhältlich ist. Noch.
  Die Folien des ersten Vortrags mit Screenshots stellen die Autoren hier zur Verfügung.
• Und mal wieder ein Sneedscher Vortrag über die COBOL-Java-Migration:
  Harry M. Sneed, Chris Verhoef: Validating converted Java Code via Symbolic Execution.
  Wie findet man eigentlich heraus, dass der Java-Code exakt dasselbe tut wie der COBOL-Code? Man hat ihn ja idealerweise bei der Migration restrukturiert! In meiner Vorlesung lehre ich eigentlich, dass es praktisch unmöglich ist, zwei Computerprogramme exakt miteinander zu vergleichen. Behaupten die Theoretischen Informatiker. Sneed ist es trotzdem gelungen: Er vergleicht die Kontroll- und Datenflüsse beider Programme durch symbolic execution.