Ein Arzt, ein Bauingenieur und ein Softwareentwickler diskutieren darüber, welches der älteste Beruf der Welt ist.

Der Arzt sagte: "Nun in der Bibel steht geschrieben, daß Gott Eva aus der Rippe von Adam schuf. Es ist klar, daß dafür eine Operation notwendig war und so kann ich mit Recht behaupten, daß ich den ältesten Beruf der Welt habe."

Der Bauingenieur unterbrach ihn und sagte: "Aber schon viel früher im Buch Genesis steht geschrieben, daß Gott die Ordnung von Himmel und Erde aus dem Chaos formte. Dies war das erste und spektaktulärste Bauprojekt in der Geschichte. Deshalb mein lieber Doktor, müssen Sie zugeben, mein Beruf ist der älteste der Welt."

Der Softwareentwickler aber lehnte sich zurück und sagte selbstbewußt:
"Aber wer denkt ihr denn, hat das Chaos geschaffen?"

Für nicht Physiker: Entropie ist ein Maß für das Chaos. (Die Definition aus dem Brockhaus war mir zu lang)

Zweiter Hauptsatz der Thermodynamik (Prinzip von der Vermehrung der Entropie):
In einem abgeschlossenen System kann die Entropie (bei einer irreversiblen Veränderung) stets nur zunehmen.

Aus dem zweiten Hauptsatz folgt sofort das
Bestsche Axiom: Entropie braucht keine Wartung.
(Nach Arno Best der mir als erster diese tiefe Wahrheit verkündete)

Wackersches Korollar:
Der Bestsche Satz wird zu häufig auf Software-Systeme angewendet.

Erster Wackerscher Satz:
Der zweite Hauptsatz gilt auch für Softwareprojekte. Egal ob es offene oder geschlossene Systeme sind.

Zweiter Wackerscher Satz:
Die Entropie eines Softwareprojektes steigt exponential mit der Zahl der Entwickler und der Entwicklungszeit.

In den einleitenden Sätzen wollte ich zum Ausdruck bringen, daß das Hauptproblem bei der Entwicklung von Software nicht die virtuose Beherrschung einer Programmiersprache ist, sondern der permanente Kampf gegen das Chaos. Im Prinzip hat man nie eine Change zu gewinnen.
Trotzdem ein paar Tipps um möglichst lange durchzuhalten.

• Teile und Herrsche.
• Der liebe Gott hat die Welt einfach gebaut.

Man wende Punkt Eins solange an, bis Punkt Zwei wahr wird. Dann ist man noch lange nicht aus dem Schneider. Man hat zwar ein kleines und überschaubares Problem. Aber die Tücke des Objektes ist so groß, daß ein Mensch immer noch nicht alle möglichen Unzulänglichkeiten eines Softwareteils überblicken kann. Deshalb programmiert man nicht nur die notwendige Funktionalität, sondern muß auch alle möglichen Fehlerfälle abfangen. Geht dies nicht so ist wieder Punkt Eins anzuwenden, solange bis es geht. Verlassen Sie sich nie darauf, daß eine andere Komponente Ihnen richtige Daten sendet. Implementieren Sie alle möglichen Tests auf dies Daten. Verlassen Sie sich nie auf die Beweise, daß diese Daten richtig sind. Insbesondere, wenn der Softwareentwickler Mathematiker ist.
Will man die geschriebene Software am nächsten Tag auch noch verstehen, so sind die folgenden Punkte zu beachten.

• Verwenden Sie sprechende Namen für alle Objekte: zb. Velocity und nicht V1 für eine Variable, in der die Geschwindigkeit abgespeicher wird.
• Verwenden Sie kleine Sätzchen für Prozedurnamen zb. Calculate_Velocity und nicht cal_vel.
• Dokumentieren Sie Ihre Software.

Das Dirac Projekt:
Die Menge der zu erledigenden Arbeit bleibt gleich. Die Zahl der Entwickler geht gegen Unendlich und die Entwicklungszeit gegen Null.

Termine:
Bei der Planung oder Durchführung eines Projektes werden Terminprobleme durch die Überführung des Projektes in den Dirac Mode gelöst.

Mühlhanssches Theorem:
Eine abgenommene Software ist fehlerfrei.

Problematische Regeln:
Regel 1: "Ein Bild sagt mehr als tausend Worte."
Des weiteren gilt: Von CASE-Tools automatisch generierte Bilder sagen nichts aus.

'Oh Rosie, Oh Girl'
'Steal away now, steal away'
Robert Plant Rockbarde

CASE Computer Aided Software Engineering
Unter CASE-Tools versteht man Software-Produkte, welche die Entwicklung von Software unterstützen. Besonders gerne werden von der Software-Industrie CASE-Tools mit grafischen Modellierungsmöglichkeiten angeboten. Hierbei werden diese Produkte häufig mit dem Wahlspruch verkauft: "Ein Bild sagt mehr als 1000 Worte"

Diese Aussage ist natürlich falsch. Es sind nur 673,42 Worte.

Dabei wird häufig vergessen das bei dem Einsatz von CASE-Tools mit grafischen Modellierungsmöglichkeiten zusätzliche Anforderungen an die Hardware zu stellen sind, die bei dem Projekt erforderlich ist. Die wichtigsten Anforderungen (Requirements) sind:

Requirement 1:
Es wird ein Drucker für das Papierformat A3 benötigt.

Requirement 2:
Es wird ein Drucker für das Papierformat A2 benötigt.

Requirement 3:
Es wird ein Drucker für das Papierformat A1 benötigt.

Requirement 4:
Es wird ein Drucker für das Papierformat A0 benötigt.

Reicht das A0 Format nicht aus, so sind weitere Anforderungen an die Fähigkeiten der Drucker-Utilities des CASE-Tools zu stellen.

Requirement 5:
Die Print-Utility des CASE-Tools muß in der Lage sein ein komplexes Diagramm auf mehrere Blätter aufzuteilen.

Damit ergibt sich dann die Anforderung, daß eine hinreichend große Pinwand vorhanden ist, so daß ein aus mehreren Blättern bestehendes Diagramm an dieser Wand zu einem Bild zusammen gebaut werden kann. Die dafür nötigen Gebäudeform ergibt sich dann aus der Struktur des Software-Projektes.

Requirement 6: ( Variante: Software Architektur mit flacher Hierarchie ) Es ist ein Gebäude zu erstellen, welches einen Raum besitzt, der eine Wand hat die 100m breit ist und 4m hoch.

Requirement 6: ( Variante: hierarchische Software Architektur ) Es ist ein Gebäude zu erstellen, welches einen Raum besitzt, der eine Wand hat die 4m breit ist und 100m hoch.

Da die Wahrheit natürlich zwischen diesen beiden Extremen liegt, baut man am besten eine Wand mit einer Abmessung von 100m*100m. Auch wenn man bei diesen Werten gewisse Redundanzen eingebaut hat ist natürlich Vorsicht geboten, da nun Änderungen an der Software-Architektur Änderungen am Gebäude nach sich ziehen können.
Das man das Software-Team mit Fernrohren, oder zumindest mit Operngläsern ausstatten sollte, ergibt sich von selbst. Eine hydraulische Bühne zum anbringen der Bilder und zum studieren der Details ist selbstverständlich auch notwendig.

Automatische Dokumentengenerierung
Eines der Argumente für den Einsatz von CASE-Tools ist die automatische Dokumentengenerierung. Dabei wird in der Regel vergessen, das Dokumente in der Regel im A4 Format sind. Habe ich komplexe Diagramme, so benötigen diese ein grösseres Format als A4 um eine lesbaren Ausdruck zu erzeugen. CASE-Tools führen aber, bei der automatischen Dokumentengenerierung jedes Diagramm, mit aller Gewalt in das A4 Format über. Das Resultat sind nicht lesbare Diagramme. Ist man sich dieses Problems bewußt, wir oft gefordert, das nur im A4 Format lesbare Diagramme erlaubt sind. Mann spricht dann vom A4 getriebenen Software Design.

Automatische Generierung von Diagrammen aus Sourcecode
Als einer der Vorteile von CASE-Tools wird oft die automatische Generierung von Diagrammen angepriesen. Dabei wird aber nicht gesagt, daß das Layout der auf diese Weise generierten Diagramme Grausam bzw. praktisch unlesbar ist. Will man brauchbare Diagramme erhalten, so ist ein manueller Eingriff in das Layout unabdingbar.
Das schöne an CASE-Tools ist nun, das bei einer erneuten Generierung der Diagramme, die nach einer Änderung der Souren notwendiger weise erforderlich ist, die händisch eingeführten Änderungen am Layout verloren gehen.
Mann hat wieder das gleiche chaotische Layout wie nach der ersten Generierung. Alle händischen Änderungen waren für die Katz und müssen erneut durchgeführt werden.

Automatische Generierung von Sourcecode aus Diagrammen
Hier treten die gleichen Probleme wie bei der Generierung von Diagrammen aus Sourcecode auf, nur mit anderem Vorzeichen. Händische Änderungen werden übergebügelt oder bringen das Generierungstool durcheinander.

Haben Sie genug von Computern und Software und wollen trotzdem etwas ausrechnen? So empfehle ich den Einsatz des folgenden, altbewährten Analogrechners. Früher konnte jeder Ingenieur mit diesen Rechnern virtuos umgehen. Der Einsatz von Computern war nicht notwendig.

Bild: Der Rechenschieber

Wenn Sie etwas schnellere Rechenschieber benötigen so sehen Sie sich doch bitte die folgenden Links einmal an:

Top 500 Die fünfhundert schnellsten Rechenschieber weltweit.
Supercomputer Meeting Heidelberg
ASCI White Der Weltmeister.
Leibniz Rechenzentrum Hier steht der schnellste Rechenschieber Deutschlands.

Weiter historische Computer.