The Human Factor in Software Engineering

Momentan läuft die Einreichungsfrist des Workshops Traceability auf der SE 2013 am 26.02.2013 in Aachen.
Die nächsten Termine sind:
Einreichung kurzer Abstract: 18.12.2012
Einreichung der Beiträge: 04.01.2013
Information über Annahme: 21.01.2013
Druckfertiger Beitrag: 10.02.2013

Weitere Informationen zur Veranstaltung finden Sie hier:
https://www.tu-ilmenau.de/sp/forschung/workshop-traceability/

Last week, there was a little... ehm... incident on my computer, which forced me to re-install my computer completely within short time of notice. The blackmailers gave me 48 hours.
This re-installation was something that I should have done for years anyway. Before, I felt like throwing the old thing away because it had become too slow. But now, after re-setup, it became the fastest computer that I ever had.

Well, but... The danger is not over. Although I am now completely up to date in terms of virus scanner, service packs and alike, I have been victim to two or more further Trojan attacks within few days. The same day when I set up the computer, a software named GoogleDesktop.exe installed itself on my computer. I am sure that I did never click "OK" for this installation. I always read carefully before I click on any button.
Where did I get it from and why do I not know about it? As I suspect that my Google searches had led me to the infected page where I downloaded last week´s problem, I now use the Avira search machine. But Google found me, they find us all. I de-installed the GoogleDesktop.exe, but can I be sure that it is gone??? Yes, yes, I know it is this software which allows me to search my disk for files. I do not know why I should need it, as the Windows search does this well enough. In my paranoia I believe that Google Desktop search allows others to more easily search on my computer.

The next Trojan stems from Microsoft. It is called "Installation Assistant for Windows Genuine Advantage". Each time when I start the computer, Microsoft asks me to allow them to verify whether my Microsoft software is genuine or a pirate copy. For my own security, of course. Each time, I click "no". I do not want to have their spy software running on my computer. At least, they ask before doing it. This is more than others do.

When downloading two freeware tools, my virus scan informed me with an angry beep that they contain exe programs that are not recommended to start. Hm, OK, thanks...

Nowadays, one is no longer master of one´s own computer. I am allowed to feed it with electricity and to use it while the Trojans leave some capacity over for my humble needs. But the rest of the time, others search my hard disk, check the actuality of my software and update it, do lots of "maintenance work" on my computer. And really each software, including printer driver software, ask me to allow them to contact their masters and inform them about all my activities and vice versa they want to inform me about their marketing news. No, I do not want this all. I refuse, refuse and refuse.

And by the way: I do not want to get the weather forecast adapted to the town where I am today, nor any other personalized information. I do not want THEM to know so much about me. In the virtual world, one can not be paranoic enough.

I am at the limit of my endurance. I seriously think of converting to Linux (again). Or at least using a Linux computer as my surf station, while the offline computer is for the real work.
I had this before, it was a bit tedious, but still better than the two extremes: (a) everyone looking into my documents, or (b) going offline completely.

Neulich erhielt ich die Bewertungsbögen für meinen Sommerschul-Kurs über Entscheidungen im Software Engineering. Darin fand ich eine interessant-bizarre Bemerkung. Es hieß, der Kurs sei für die Lehre an einer Universität nicht geeignet. Begründung: Man lerne dort Methoden, die nützlich seien für Leute, die in einer Firma wichtige Entscheidungen treffen. Aber für die Entscheidungen, die ein Student während des Studiums trifft, seien diese nicht anwendbar. Abgesehen davon, dass ich mir einbilde, die Kursbeschreibung sei eindeutig formuliert gewesen, fällt mir auf, dass es sich bei dieser falschen Erwartung um eine häufige handelt. In allen meinen Vorlesungen bereite ich auf das Berufsleben vor. Trotzdem erhalte ich immer wieder ähnliches Feedback. Mein aktueller Projektmanagementkurs ist offiziell eine Vorbereitung auf das Praktikum. An einer anderen Hochschule war es der Software Engineering Kurs, der auf das Software Engineering Praktikum vorbereiten sollte. Als die Studierenden darin auch Notationen und Wissen lernen mussten, die sie in einem Studentenprojekt im universitären Umfeld nicht brauchen, waren sie unzufrieden. Und neulich grummelte auch jemand, weil in meinem Kurs "Wissenschaftliches Arbeiten" tatsächlich Inhalte vorkommen und geübt werden, die man nicht für die Durchführung einer Bachelorarbeit braucht. Vielleicht habe ich ja meine Lehrgebiete zu ungeschickt gewählt, denn anscheinend sollen (laut Modulhandbuch) wohl alle meine Vorlesungen nur dazu dienen, die Studierenden für ein anderes Studienfach vorzubereiten. Also ähnlich wie Mathekurse und andere Grundlagenfächer. Nun würde mich aber interessieren: Ist das Entwicklungspraktikum wenigstens etwas, das auf das Berufsleben vorbereitet oder führt dieses einfach nur zum Schein und Studienende?
In Zukunft werde ich bei Vorlesungsbeschreibungen und dem Einführungsteil NOCH MEHR darauf achten, zu betonen, dass ich auf das Leben vorbereite und nicht auf das Studium! Man studiert doch nicht nur, um den Bachelor/ Master zu erreichen und danach all das Wissen aus dem Studium wieder zu vergessen! Da haben die Studis schon eine Professorin, die das Berufsleben kennt und sie darauf vorbereiten möchte. Und dann sowas... Daran arbeite ich noch!

Das Fachgruppentreffen Requirements Engineering war wieder ein tolles Treffen mit interessanten Vorträgen, viel Networking und einer konstruktiven, freundschaftlichen Atmosphäre. Dazu beigetragen hat natürlich auch die großzügige Verpflegung und lückenlose Organisation durch unsere Gastgeber, die Sophisten. Ich selbst bin mit einigen neuen Ideen aus dem Treffen herausgegangen, insbesondere für zukünftige Kooperationen.

Ich möchte hier nur die beiden eingeladenen Vorträge wiedergeben, obwohl die anderen natürlich auch spannend waren.

Chris Rupp (Geschäftsführerin von Sophist) trug vor über "Blitzverblödung und tote Pferde – wie menschliche Verhaltensmuster Projekte prägen". Dabei stellte sie vier Anti-Muster vor, die wir dann auch in Kleingruppen diskutierten:
1.) Totentwicklung eines Systems: Es wird eine Software entwickelt, die keiner (mehr) braucht oder haben will. Trotzdem wird daran weitergearbeitet.
2.) Reportismus/ Managerismus: Man verbringt mehr Zeit mit Dokumentation und Rechtfertigungen als mit produktiver Arbeit.
3.) Kompliziert oder komplex: Software wird unnötig kompliziert, um die komplexe Wirklichkeit abzubilden. Dabei könnte man stattdessen den Benutzern auch ein wenig Intelligenz zutrauen.
4.) Blitzverblödung: Dieselben Themen werden immer wieder neu diskutiert. Selbst wenn bereits eine Entscheidung getroffen und in einem Protokoll dokumentiert worden war.
Diese Muster kannten wir alle, haben auch die eine oder andere Lösung dafür gefunden.

Unsere Key Note von Frau Prof. Bürsner behandelte unser diesjähriges Schwerpunktthema: "Abenteuer RE in KMU – zwischen erfolgreicher KMU-Praxis und methodischer Perfektion". Der Vortrag gab einen tiefgehenden Überblick darüber, wie in KMU Requirements Engineering praktiziert wird und machte auch Vorschläge, wie man Verbesserungen durchführen kann. Unter anderem empfahl Frau Bürsner ein inkrementelles Vorgehen. Besonders hängen geblieben ist bei mir der Begriff "Essenz des RE". Es geht nicht darum, die richtigen Notationen und Vorlagen zu empfehlen, sondern darum, diese Essenz zu vermitteln. Dies ist nun nicht nur ein Beratungs-Thema, sondern eben auch für die Lehre wichtig. Aber was ist denn diese Essenz?? Ich habe davon natürlich meine eigene Vorstellung, die sich in meinen Kursunterlagen bereits findet. Teilweise natürlich zur Verwirrung der Teilnehmer, die auf ihre "Wie soll ich es denn machen?"-Fragen eine Antwort bekommen, die beginnt mit "Es kommt darauf an...". Und dann folgt eine Fallunterscheidung. Wie aber würde ich die Essenz des RE kürzest möglich zusammenfassen? Da fiel es mir wie Schuppen von den Augen: Das gibt´s doch schon im Agilen Manifest! Genau darum geht es: Requirements Engineering unterstützt nur die Kommunikation und den Weg zum Ergebnis. Bei jeder Entscheidung in Bezug auf das RE sind die Prinzipien des Agilen Manifests die Entscheidungskriterien.

Was für ein Freudentaumel! Es ist mir gelungen, mich bei Elster anzumelden! Ich war schon so gut wie sicher, dass mich der Timeout erwischen würde. Der Tod durch Timeout tritt 90 Tage nach Beginn des ersten Anmeldungeschrittes ein. Es sind zwar insgesamt nur zwei Schritte, wie die Webseite verkündet, aber nicht mitgezählt sind unzählige Zwischenschritte, deren richtige und effiziente Reihenfolge ich mühsam durch Trial and Error herausfinden musste. Finanzamt, falls ihr einen Tipp darüber braucht, welche Informationen auf eurer Webseite fehlen, bitte melden, solange mein Trauma noch frisch ist! Ja, das Wissen ist vorhanden. Ich habe jetzt wochenlang immer wieder dieselbe Fehlermeldung erhalten, hartnäckig. Der Trick liegt darin, die beiden Tipps aus dem Benutzer-Forum durchzuführen und auch noch die Tipps der drei Hotline-Mitarbeiter, mit denen ich im Verlauf der letzten Wochen telefonierte. Alles zusammen ergibt die Lösung. Der letzte, zugegeben harmlose Scherz war dann noch dieser: Ich sollte eine PIN wählen, ganz für mich allein. Ich weiß nicht wieso, aber irgendwie dachte ich, PINs seien immer vierstellig. Ich gab also zweimalig meine neue PIN ein und den 12stelligen Aktivierungscode. Die ganze Zeit unter der Drohung, dass wenn ich den Code drei Mal falsch eingebe, doch noch alles vorbei sei. Und was passiert? Eine rote Fehlermeldung, die PIN müsse sechsstellig sein. Das steht da nirgends, Entschuldigung! Also nochmal... PIN, PIN, 12stelliger Aktivierungscode. Gratulation, Frau Herrmann, Sie sind drin!
Oder wie ein früherer Chef von mir stets sagte: "Es ist immer wieder faszinierend. Kaum macht man es richtig, funktioniert es plötzlich." Jawohl, und wie gut sich das anfühlt! Ich hatte allen Ernstes befürchtet, ich müsse einen Steuerberater damit beauftragen, mich bei Elster anzumelden.
Wieder eine Sorge weniger... Darauf einen Kakao!

Am 29.+30.11. findet in Nürnberg das Treffen der GI-Fachgruppe Requirements Engineering statt. Ich bin dort als Organisatorin der Veranstaltung und als Leiterin bzw. Mitglied von drei Arbeitskreisen. Ich freue mich schon darauf. :-)

When I first heard this saying, I thought it is nonsense. When the full bucket pours water into the empty buckets, then there is more growth in the empty buckets. And when the bucket is almost full, how much additional water can be poured into it? There is more free space in empty buckets.
But, finally, knowledge is no material like water. When I pour knowledge into my students, then I do not empty myself. Knowledge, like joy, love, friendship etc. multiplies by sharing. However, it does not multiply by a linear function. Teaching 100 students at a time is not the same as teaching 10. In a small group, each student can learn more than in a large group because in the small group there is less distance between us and I can adapt the training better to each student´s needs. On the other hand, groups can be guided to learn from each other and these synergy effects can scale, using the right exercises. Nevertheless, in a large group, my ability of steering the learning effect diminishes. I do not automatically get feedback about learning progresses and misunderstandings, but must organize such feedback loops intentionally.
I as the trainer do not loose any knowledge by teaching. I just share it. And if done well, I can learn a lot from teaching. While being an expert, I have the head in the skies and philosophise about intellectually fascinating details, my teaching forces me to stay on the earth with my feets. Again and again, I am asked what these methods are good for and how they can/ must be applied in practice. Very trivial practical questions arise like "What material is needed for this method? How many meta plan cards are needed per participant?" Teaching forces me to NOT forget that what I teach is not trivial and not self-explaining. Feedback from exercises and exams teaches me which method is how easy to learn, but also whether my teaching (material) is appropriate. Finally, as I teach the simple bascis, the training MUST allow everyone to learn everything. So, the students teach me to teach. I am only full master of a method when I can teach it, and not only apply it myself. Software engineering is team work, so this is more important in software engineering than in mathematics. One can be a good mathematician without being able to explain one´s work to everyone. But if I can not explain software engineering to all stakeholders from directors to secretaries, then I am no good software engineer. Hard, but true.
The third way how I learn from teaching is that I enter into many exercises with a more or less formal research question in mind. Some exercises are even formally prepared, executed and evaluated as scientific experiments, which not only provide aha experience to me, but also to the scientific world. Most often, the research question is informal. For instance, I was curious to apply Kano requirements prioritization compared to another method, with the same unbiased stakeholders to the same requirements, to experience the difference. For the students, it was just an exercise where we used two different methods for the same task. So, they know them both and can they apply in their job when needed. But for me as an expert, the learning effect was much higher. When prioritizing requirements in categories "low", "average" and "high", we met those difficulties that one always has then. Questions arise like "Whose perspective do we take? The user´s? The manager´s? The developer´s?" And "How high is high? What is our reference?" With Kano prioritization, those questions did not arise at all, because we clearly took the user perspective and the reference is the state of the art/ the market. This made the prioritization extremely fast and the group agreed easily. Differences in opinion could be eliminated by mentioning a competing product that already has a certain feature. It became also clear from our discussion, that when the market advances, the Kano priorities become out-dated, and that a prioritization from other stakeholders´ perspectives must probably be done additionally. This was a clear result, but I am not sure whether the students fully can enjoy this result or whether they think it is trivial. These findings were not unexpected, but as a critical spirit, I had to experience and see it before I fully believe it. In my current software engineering course, we regularly transform one UML model into another (e.g. activity diagram into sequence diagram, state diagram into activity diagram) to experience the difference. I designed these exercises in a way that also I do learn something and this makes my course more interesting for myself. Anyway, I constantly modify my courses in order that they stay interesting and new for myself. I am such a bad comedian. When the course is boring for me, then the participants fall asleep. So, I am in constant search for more exciting stuff, the latest trends, and thrilling exercises. (Well, anyway, as in IT half of the knowledge becomes obsolete within 4 years, the same is true for my training material. Half of the slides become out-dated within 4 years!)
So, yes, the teacher´s strive for learning in his own courses improves the courses.

Es ist zu putzig. Nun habe ich ca. 35 als Hausaufgabe erstellte UML-Diagramme bewertet und weiß immer noch ganz genau, ob ich dieses schon hatte. Wohlgemerkt: Es sollte KEINE Gruppenarbeit sein. Trotzdem bemerke ich gewisse "Produktlinien", d.h. Verwandtschaftsbeziehungen zwischen den Diagrammen. Die Studenten waren immerhin nicht frech genug, mir identische Kopien einzureichen. Der eine sendet in Farbe ein, der andere in Schwarz-weiß. Oder jeder im Viererteam wählt sein eigenes Layout. Oder man hat noch kleine Umbenennungen gemacht. Aus der Bedingung "richtig" wird "korrekt".
Wäre es leicht, das Original von der Kopie zu unterscheiden, dann würde ich nur einer Person die Punkte geben. Nach dem Speicherdatum der Datei mag ich dabei nicht gehen. Vielleicht sollte ich so ein Team gemeinsam entscheiden lassen, wer von ihnen den Punkt bekommt. Früher habe ich dann einfach aufgeteilt. Gab die Aufgabe 2 Punkte und vier Leute haben ein "gemeinsames" Ergebnis eingereicht, dann bekommt jeder eben nur einen halben Punkt. Die liebste Lösung wäre mir, ich könnte die Plagiatoren dazu verdonnern, stattdessen eine ganz eigene Aufgabe zu lösen. Schließlich geht es hier nicht um Punkte oder um Strafen, sondern darum, UML zu lernen!
In der nächsten Vorlesung werde ich dann mal meiner Verblüffung Ausdruck geben, wie weit die Kunst der Gedankenübertragung in diesem Kurs verbreitet ist...