Gestern schon stank es zum Himmel. Wie aus tausend Schloten, die gleichzeitig ausgesottet wurden. Quelle des üblen Geruches scheint diesmal eine brennende Mülldeponie in Bernau zu sein.

Feuer über Bernau - Quelle: Mein Berlin

Via Hauptstadtblog

Für T3D, als Ersatzbefriedigung, weil er sich keinen iPod nano zulegen kann/darf Martin dürfte es genauso spannend finden: Processing, eine Programmiersprache zum Beispiel für 3D Skizzenbücher.

Gefunden über futurezone.orf.at

Seit Freitag ist es in der Wohnung und ich darf es nicht auspacken: Fraus nagelneues, originalverpacktes iBook.

Software entwickeln ist einfach! Zumindest ist das ein weitverbreiteter Irrglaube, der all diejenigen befällt, die keine Software entwickeln. So wie viele Menschen denken, dass Grafikdesign einfach ist. Bis auf Grafikdesigner. Dieses Muster lässt sich auf fast alle Berufe und Fachrichtungen übertragen.

Die schlimmsten Probleme treten dann auf, wenn Menschen, die ein bischen was von einem Fach verstehen einem in die eigene Arbeit hineinreden können und wollen. Die langerprobte Pattern aus Ignoranz über Bord schmeissen, nur um nach etlichen Fehlversuchen dann genau das über Bord geschmissene Pattern als Lösung finden. Danke, das hätten man auch einfacher und billiger haben können. Sie wissen jetzt aber wenigstens wie Pattern entstehen: Versuch und Irrtum. Pattern sind eine Möglichkeit Erfahrungen einfach für andere zugänglich zu machen. Meiner Meinung nach ein wichtiger Baustein im Wissensmanagement.

Fachleute kennen eine ganze Menge solcher Mustern. Das macht sie als Fachleute aus.

Laien kommen auf die abstrusesten Ideen. Meistens funktionieren diese Ideen am Anfang auch. Das Problem an Software ist allerdings, dass die Anforderungen im Laufe der Zeit wachsen. Ich habe es noch nie erlebt, dass eine Software in ihrer Funktionalität beschnitten werden sollte. Die kleine, schnell hingeschusterte Lösung ist dann schnell vom Design überfordert und erfordert ein ausgewachsenes Refactoring. Ausgewachsen bedeutet dann leider meistens neu schreiben. Es nicht einfach möglich einer Excel-Tabelle das Verhalten einer relationalen Datenbank beizubringen. Sicherlich ist das über die eingebaute Programmiersprache irgendwie möglich. Sinnvoll ist es trotzdem nicht. Neu schreiben kann dann auch übersetzt werden mit: Das wird teuer

Spannend ist es auch, wenn Laien Lösungen für Softwareentwicklungsprobleme suchen sollen. Ist es möglich sowohl einen Rich Client als auch einen Webclient zu bauen, der die lästige Doppelentwicklung vermeidet? Sicher. Flash ist die Lösung. Wir entwickeln einen Flashclient fürs Web und betten diesen dann über das, von Eclipse verwendete HTML-Widget in Eclipse als Rich Client ein. Geht sicherlich. Ist man mit der Umsetzung fertig heisst es dann, dass wir das jetzt beim Kunden B in dessen Portal einbauen müssen. Natürlich nur die Funktionalität C, erreichbar über eine einzige Eingabezeile, die dann das ganze Portlet aufgehen lässt. Ich bin kein Flash-Experte, kann also nicht beurteilen, ob man in Flash komponentenbasiert entwickeln kann, um dieses Problem zu lösen. Und da ist das Schlüsselwort gefallen. Diejenigen, die solche Ideen haben sind es auch nicht.

Anforderungen beschreiben

Gerade bei Projekten, bei denen man schon zu Beginn weiss, dass sie umfangreicher werden, ist eine gute Vorbereitung unabdingbar. Dazu gehört eine sauberes, textuelles erfassen der Anforderungen. Eines meiner Erfahrungsmuster besagt:

Das abbilden der Anforderungen in abstrakten Diagrammen, wie sie z.B. UML ist für Laien aus der Fachabteilung, für die die Anwendung entwickelt werden soll, unverständlich. Sie müssen diese Fachsprache nicht verstehen. Es ist nicht ihre Aufgabe. Werden sie trotzdem mit dieser konfrontiert, dann fühlen sie sich schnell eingeschüchtert, fehl am Platz und verlieren schnell das Interesse. Damit ist der Kern des scheitern des Projektes gelegt.

Auch Oberflächenscribble, und seien sie noch so chic, eigenen sich nicht ausschliesslich für die Beschreibung der Anforderungen. Ein Bild sagt zwar mehr als tausend Worte. Diese Abstraktion geht allerdings zu weit. Scribble sind, wie auch UML Diagramme, nur ein Hilfsmittels, um die textuelle Beschreibung zu unterstützen. Dabei müssen Scribble als das verstanden werden, was ihre Übersetzung bezeichnet: Kritzeleien. Zu ausgefeilte Scribbles lenken von der eigentlichen Problemstellung ab und eignen sich höchstens als Marketinginstrumente.

Textuelle Erfassung ist hierbei allerdings noch nicht die allumfassend glücklich machende Lösung. Jeder hat andere Vorstellungen darüber wie die Texte für Anforderungen auszusehen haben. Aus diesem Grund sollte es formale Regeln und Pattern geben, an die sich die niedergeschriebenen Anforderungen zu halten haben. Dies vermeidet schon viele Fehler. Trotzdem, die Sprache ist die Quelle der Missverständnisse (Antoine de Saint-Exupéry, Der kleine Prinz) und ersetzt nicht die direkte Kommunikation der Teammitglieder untereinander. Wenn diese nicht statt findet ist es sinnlos sich über Anforderungen überhaupt Gedanken zu machen.

Fazit

Das Erfassen und Managen von Anforderungen kann man auch als Culture Clash angesehen werden. Aus diesem Grund sollte das Anforderungsmanagement in grösseren Softwareprojekten eine zentrale Stellung einnehmen. Leider wird es heute noch immer häufig vernachlässigt. Die Gründe sind unterschiedlich und hier zum Teil beschrieben. Ist dies der Fall, stehen die Chancen gut, dass das Projekt scheitert.