Am 22. Mai halte ich auf den Karlsruher Entwicklertagen einen Pecha-Kucha-Vortrag über "Vergangenheit, Gegenwart und Zukunft der Agilität". Hintergrund ist eine umfangreiche Literaturrecherche zur Geschichte der agilen Entwicklung. Als alter Hase hatte ich mich dunkel erinnert, bereits in den 90er-Jahren agil gearbeitet zu haben, ohne dass das damals so hieß. Man nannte das beispielsweise Rapid Application Development. Unter den vorliegenden Umständen einer hoch konzentriert arbeitenden Task Force, die eine schon lange existierende Idee endlich umsetzte, hat das hervorragend geklappt. Trotzdem bin ich kein uneingeschränkter Fan der Agilität, insbesondere aus Sicht des Requirements Engineerings. Ein gutes Konzept ist nämlich auch etwas wert und erspart einige Mehrarbeit bei der Programmierung.
Andrea Herrmann

PS: Die Folien des Vortrags finden Sie nun online hier.

Eine regelmäßige Tätigkeit von mir ist das Begutachten von Hausarbeiten, Bachelorarbeiten, Masterarbeiten und Studienarbeiten. Gerade habe ich mal wieder ein Plagiat erwischt, das sich gewaschen hatte. Außer den Kapitelüberschriften stammte kein einziges Wort vom Autor. Entsprechend fehlten auch alle Teile, die er hätte selbst formulieren müssen, wie z.B. eine Zusammenfassung der Plagiate am Ende der Arbeit.
Ich weiß, es gibt Software, die automatisch Plagiate finden. Bisher habe ich da aber vor allem False Positive Meldungen erhalten. Da hatte ein Student beispielsweise die Firmenbeschreibung der Firma, in der die Fallstudie stattfand, von der Webseite übernommen und auch richtig die Quelle angegeben, oder allgemein-nichtssagende Sätze wie "die Arbeit hat folgenden Aufbau" verwendet, die tatsächlich in anderen Arbeiten auch so vorkommen.
"Von Hand" habe ich aber schon einige freche Fälle entdeckt. Die Plumpheit der Fälschungen ist eine üble Beleidigung an den Gutachter! Folgende Indizien sollten einen Gutachter einer Arbeit hellhörig machen und ihn dazu anregen, eine Suchmaschine zu betätigen. Ich nehme mir dann immer einen etwas außergewöhnlich formulierten Textteil und füge ihn in Anführungszeichen in das Suchfeld der Suchmaschine ein. Und schwupps... da haben wir die Quelle! Hier die Anzeichen:

• Von Absatz zu Absatz ändert sich die Schriftgröße, Schriftart, Zeilenabstand, Sprache (Deutsch versus Englisch), Schreibstil oder die Terminologie. Das passiert, wenn man aus verschiedenen Quellen Text zusammen kopiert und nicht mal das Format vereinheitlicht.
• Mitten in der Zeile finden sich harte Zeilenumbrüche. Dazu kommt es wenn die Webseite, von der der Text stammt, breiter oder weniger breit ist als das Format des Textes.
• Tadellos formulierte Definitionen werden ohne Quellenangabe aneinander gereiht. Online-Quellen zitieren oft keine Quellen. Natürlich kann man online auch wissenschaftliche Texte mit Quellenangaben plagiieren. Dann passt oft das Format der verschiedenen Referenzen nicht zusammen.
• Der Text enthält Anmerkungen wie "Nähere Informationen zu diesem Thema finden Sie unter dem Link rechts oben" oder "Bei weiteren Fragen wenden Sie sich an folgende Adresse: info@firma.de" oder auch Links zu Webseiten.
• Der Inhalt passt nicht so richtig zur Themenstellung. Das allein kann natürlich auch daher rühren, dass der Autor die Fragestellung falsch verstanden hat, war aber bisher bei allen Plagiaten zusätzlich noch der Fall. Da hatte jemand leider im Internet keinen exakt passenden Text gefunden und einfach einen ähnlichen genommen. Hauptsache, die Schlüsselbegriffe stimmen mit der Themenstellung überein. Im aktuellen Fall sollten verschiedene Technologien im Hinblick auf vier Kriterien verglichen werden, aber letztlich wurden nur drei der Kriterien berücksichtigt. Außerdem sollte eine Fallstudie durchgeführt werden. Stattdessen stand da noch ein weiterer Theorieteil, weil es diese Fallstudie so nirgends fertig gab. Ich stelle grundsätzlich keine Themen, bei denen man sämtliche Inhalte aus dem Internet kopieren kann.
• In schlimmen Fällen schafft es der Plagiator nicht einmal, zu den gestohlenen Texten eine sinnvolle Einleitung, Überleitung oder eine Zusammenfassung zu schreiben.

Diese Plumpheit verblüfft mich immer wieder. Da muss jemand wirklich extrem wenig Zeit haben und noch nicht mal das Geld für einen Ghostwriter. Ich hatte auch schon zwei Fälle, wo ich wirklich hohe Summen darauf wetten würde, dass diese Person diesen guten Text niemals selbst geschrieben hat. Wenn ich ihn aber nicht im Internet finde, weil ein Ghostwriter am Werk war oder der Text aus einem Fachbuch abgetippt wurde, kann ich es leider nicht nachweisen. Manchmal sehr ärgerlich, wenn jemand monatelang richtig schlechte Arbeit geleistet hat und am Ende einen vorbildlichen Bericht abliefert. Das verletzt mein Gerechtigkeitsgefühl.

Witzigerweise finde ich beim Plagiatejagen per Suchmaschine fast immer auch heraus, dass irgendeine Firmenwebseite von Wikipedia, IHK oder einem Ministerium Texte gestohlen hat, ebenfalls ohne Quellenangabe. Manche Wikipediatexte findet man auf zehn und mehr Internetseiten von Firmen. Wer "schreibt" eigentlich deren Texte??? Und hat der Geld dafür genommen?

Angesichts der Tatsache, dass die meisten Menschen sich viel Arbeit mit ihren Hausarbeiten machen, ist es nur gerecht, die Textdiebe zu entlarven.

Andrea Herrmann

Clean Coding und Software Craftmanship sind globale Bewegungen, die sich für eine saubere Codierung einsetzen. Diese Idee ist nicht neu, sondern geht zurück auf sehr frühe Vorstellungen von "Pretty Printing" durch Leerzeilen und Einrückungen von Code. Beispiele hierfür finden Sie in Wikipedia.
Manche Autoren sprachen damals von Software-Code als einem literarischen Kunstwerk, das nicht nur für den Compiler Sinn machen muss, sondern auch für einen Menschen angenehm und verständlich lesbar sein muss.

Diese Forderung wurde umso drängender, je mehr verschiedene Personen denselben Code zu verstehen und ändern hatten. Mehrere Organisationen wie z.B. Sun und Google entwickelten Codierrichtlinien, die die Programmierung vereinheitlichen sollten, so dass jeder Programmierer den Code des anderen lesen kann. Schließlich verbringen Wartungsprogrammierer einen Gutteil ihrer Arbeitszeit mit dem Lesen fremden Codes. Eine einheitliche Formatierung beschleunigt das Verstehen und vermeidet Fehler.

Besonders die agile Entwicklung mit ihrer gemeinsamen Codeownership benötigt sauberen Code. Jeder muss jederzeit jeden Codeteil verstehen und weiterentwickeln können. Individueller Schreibstil ist hier nicht hilfreich.

Clean Coding geht über eine übersichtliche Formatierung und einheitliche Variablennamen hinaus. Clean Coding verlangt vom Programmierer eine hohe Professionalität, die beinhaltet, dass er sich über Qualiätseigenschaften der Software, Designmuster und ständige Verbesserung Gedanken macht. Es geht um die Werte hinter der Arbeit am Code und um die Verantwortung für das eigene Werk.

Die Clean-Coding-Initiative hat um sich gegriffen. Es gibt Software Craftmanship Konferenzen,
ein Software Craftmanship-Manifest, eine Clean Coding Developer Google-Gruppe und Clean Coding Regionalgruppen, auch in Stuttgart.

Weitere Informationen finden Sie hier und in dem originalen Buch
Robert C. Martin: Clean Code: A Handbook of Agile Software Craftsmanship. Addison Wesley, 2008, ISBN 0-13-235088-2.

Am Montag den 8. Mai trägt Dipl.-Ing. (BA) Sven Strittmatter (iteratec GmbH) bei der acm/GI-Regionalgruppe über Clean Coding vor:
http://rg-stuttgart.gi.de/veranstaltungen/mo-08052017-clean-coding.html

Ich habe hier einen sehr schönen Wochenkalender für Frauen von Harenberg mit dem Titel "Lebe frei und ungewöhnlich". Jede Woche gibt es eine Postkarte mit einem Zitat einer Frau, die frei und ungewöhnlich lebte. Zwei der Sprüche habe ich mir herausgetrennt, weil sie schön zu mir passen:

• "Unkompliziertheit ist nicht Einfalt, sondern Klarheit." (Anni Albers, deutsch-amerikanische Textilkünstlerin)
• "Ich habe beschlossen, so viel wie möglich zu arbeiten, um endlich aus mir herauszuholen, was in mir steckt." (Sonia Delaunay, ukrainische Malerin)

Beides muss man wissen, um meine Arbeit zu verstehen...
Andrea Herrmann

In dem Buch "Jakob Freund, Bernd Rücker: Praxishandbuch BPMN - Mit Einführung in CMMN und DMN. Hanser, 5. Auflage, 2017" fand ich ein paar schöne Zitate zur Modellierung:

• "Unser Modellierungs-Knigge: Prinzipiell gilt also für strategische Prozessmodelle: eine möglichst korrekte Syntax, zur Not aber eine inkonsistente Semantik." (S. 117)
• "Jedes Prozessmodell ist unvollständig - aber manche sind brauchbar!" (S. 118)
• "Je genauer wir das Zusammenspiel ausmodellieren, desto mehr neue Fragen entstehen bzw. desto mehr Ungenauigkeiten und Inkonsistenzen werden erkennbar." (S. 122)

Neulich habe ich beim Korrigieren einer Prüfung Tränen gelacht. Ein Prüfling hat mit Spatzen auf Kanonen geschossen. Ich habe versucht, mir bildlich vorzustellen, wie das aussieht und warum man das tun sollte, aber es gelang mir nicht so einfach. Unter normalen Umständen würde auch dieser Prüfling so etwas niemals sagen, aber in der Prüfungssituation da verdreht man ganz gerne mal etwas vor Nervosität.

Neulich hat auch jemand meine Sammlung der möglichen Use Case-Beziehungen vervollständigt. Laut Lehrbuch heißen sie ja include und extend . In Prüfungen kommt regelmäßig noch das exclude dazu, was auch irgendwie Sinn machen könnte. Es klingt nach einer Art XOR-Beziehung. Neulich erfuhr ich auch noch von der vierten denkbaren Kombination von Vorsilbe und Verb: intend. Hier wird vermutlich die Absicht dokumentiert. Jetzt haben wir sie also vollständig!
Andrea Herrmann

Theodor Fontane (1819-1898), deutscher Schriftsteller

In dem Seminar Seminar "Software Engineering mit UML für Fortgeschrittene" am 29.+30. Mai 2017 vertiefen wir die Anwendung von UML für Anforderungen und Software-Architektur und beschäftigen uns außerdem mit modellbasierter Entwicklung und der Qualitätssicherung für UML-Modelle. Der Kurs findet an der Technischen Akademie Esslingen statt.

Erwandern Sie sich die Prinzipien des Projektmanagements! Vom Stuttgarter Neuen Schloss zum Bärenschlössle führt uns der Weg, 21 Kilometer von 8 bis 20 Uhr.
Dabei erlernen oder wiederholen Sie die Grundlagen des Projektmanagements und wenden diese auf unsere Wanderung an. Planung, Kontrolle und Risikomanagement, Stakeholdermanagement und Teamarbeit sind unsere Themen.
Sie können sich für diese Wanderung hier anmelden.

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.