Am 8. Oktober 2009 war ich wieder bei den »Hot Spots der Software-Entwicklung — HSE« an der TU München.
Die Reihe wurde im Jahre 2002 im Rahmen des VSEK-Projektes begründet und findet seither jährlich an der Technischen Universität München statt. Ziel der Veranstaltungen ist es, eine Plattform zum Erfahrungsaustausch zu aktuellen Themen des Software- Engineering zu schaffen.
Auf der Hot-Spots-Seite der TUM kann man ausführlich die Tagungen nachlesen. Eine sehr empfehlenswerte Seite, mit gründlicher Erläuterung der Tagungsthemen und einem Tagungsband zu jedem Thema. Auch die Folien der verschiedenen Beiträge sind in der Regel dort verfügbar. Insgesamt eine exzellente Sache.
Das Thema war diesmal Requirement Engineering …
Die Tagung war wieder einmal recht spannend, vielleicht auch weil das Thema “Requirement Engineering” ein ganz besonderes ist.
Ich konnte aus zeitlichen Gründen nicht die gesamte Tagung begleiten, hier aber trotzdem ein paar Anmerkungen zum Thema und den Vorträgen:
- Requirement Engineering versus Design/Architektur
Die Themen müssen sauber getrennt werden. Leider habe ich auch auf der Tagung gemerkt, wie leicht auch ein erfahrener “Requirement Engineer” nur zu leicht und nahezu automatisch in die Konstruktion des Produktes rein rutschen kann und dabei seine eigentliche Aufgabe vergisst, die Anforderungen an ein Produkt kritisch zu hinterfragen und dann sauber zu definieren. - Divide et impera!
Schon im alten Rom haben die Herrscher diesen Spruch beherzigt: Teile und (be)herrsche die Dinge. Das ist sicherlich ein vernünftiges Vorgehen, um Zugang zu komplexen Situationen zu finden. Es setzt aber voraus, dass man weiß, was man will und dies sauber von oben nach unten zerlegen kann. Die Herausforderung beim Requirement Engineering ist aber gerade, dass man eben meistens nicht weiß, was man oder der Kunde will, sondern dies erst gemeinsam finden und beschreiben muss. - Dialektik und Logik
Saubere Definition, Suche nach Bedingungen, Bilden eines Syllogismus, Erstellen von “Fahnen”, alles sind wichtigste Themen in der menschlichen Kommunikation, die schon vor 2.500 Jahren eine zentrale Rolle gespielt haben. Gerade Requirement Engineering erfordert die Anwendung dieser Disziplinen mit hoher Präzision und Akkuranz. So klingt es dann schon fast lustig, wenn hier im Requirement Engineering versucht wird, das “Rad neu zu erfinden”. - “Cheap Design”
Vermisst habe ich einen Beitrag, welchen Beitrag Requirement Engineering haben könnte, um auch die Anforderungen an ein Produkt einfach zu halten. Einfach im Sinne von Rolf Pfeifer, hier im Interview. Rolf Pfeifer ist Gründer und Leiter des Artificial Intelligence Laboratory, Department of Informatics, University of Zurich unter anderem Autor des Buches “How the Body Shapes the Way We Think: A New View of Intelligence” (Bradford Books). Er hat den Begriff “cheap design” kreiert und bekannt gemacht. - Kreative Produkte
Da vermisse ich zur Gänze vernünftige Ansätze im Requirement Engineering. Wie kann man kreativ die Anforderungen finden, für Produkte, die es noch gar nicht gibt? “Top down”-Ansätze werden hier sicherlich nicht funktionieren, fehlt doch das “Top”. Und iterative Methoden sehe ich hier auch noch nicht. - Werkzeug-Gläubigkeit
Mein Eindruck war, dass mancher der Vortragenden meinte, man könnte Komplexität mit dem Einsatz von Werkzeugen bewältigen. Das halte ich für sehr kühn. Man stelle sich vor, die Philosophie würde sich bei ihrer Arbeit auf Werkzeuge wie z.B. UML-Technologien abstützen!
Insgesamt habe ich den Eindruck, dass wir mittlerweile auch schon beim Requirement Engineering versuchen, mit einem Overkill von Prozessen und Werkzeugen die Dinge zu “entkomplizieren”. Leider funktioniert das überhaupt nicht, sondern führt nur zu oft zum Gegenteil. Es wäre gut, sich dies einzugestehen und wieder das alte Prinzip “KISS” (keep it simple and stupid) zu beherzigen.
RMD
Wird geladen ...
3 Antworten
This is another area where compromises work best. “Bottom up” is a bad design method, but “top down” is not the whole answer. Innovation is driven partly by recognition of requirements, but also by recognition of what can be done.
Incidentally, the KISS principle in English is usually spoken as “Keep it simple, stupid”, (compare http://en.wikipedia.org/wiki/KISS_principle with the German version). This indicates that the one spoken to has been stupid enough to propose a complex solution. English humour is more brutal than German.
Ich wuerde der Aufzaehlung von Roland Duerre gerne noch das Folgende hinzufuegen:
Bei aller Suche nach moeglichst einfachen Loesungen muss auch immer die Angemessenheit der Loesung beruecksichtigt werden. D.h. die Komplexitaet der Loesung muss in einem angemessen Verhaeltnis, zur Komplexitaet des Problems stehen. Im Zweifelsfall aber immer erst mal der einfacheren Loesung den Vorzug geben.
I do not see a simple relationship between the complexity of a problem and that of its solution.
The problems in the relationship between a man and his wife may be very complicated; the solution can be just a push while walking in the mountains.
It is known that a mountain in the Canary Islands threatens to fall into the ocean, creating a wave that will drown much of New York. This seems a fairly simple problem, but any solution will be very complicated.