In einem modellverliebten Betäti-gungsfeld wie der Informatik spielen

Designentscheidungen eine zentraleRolle. Ob es um die formale Repräsen-tation eines Problems, die Abbildungvon Informationen in Datenstrukturen,den Entwurf einer Architektur oder gardie Formalisierung ganzer Entwick-lungsprozesse geht – stets gilt es, einDesign zu finden, das dem Wesen derzu lösenden Aufgabe möglichst nahekommt. Ergebnisse, die der Natur desSachverhalts zuwiderlaufen, werdenüblicherweise bestraft – im schlimms-ten Fall spät.

Die Grundregeln guten Designssind, wie alle anderen Mengen vonPrinzipien, zunächst Gegenstand einersubjektiven Wertung. Als solcher unter-liegen sie einem Zeitgeist, sind regio-

nalen Moden ausgesetzt und erfahrenindividuelle Neubewertungen aufgrundkonkreter Erfahrungen Einzelner. Trotz-dem lässt sich erfreulicherweise fest-stellen, dass die Softwaretechnik seitJahrzehnten von einer fruchtbaren Dis-kussion über nützliche Designprin -zipien und Entwurfsregeln begleitetwird. Ungeachtet aller Differenzen kris-tallisieren sich dabei Konzepte her aus,die es ermöglichen, Softwaresystemesteigender Komplexität elegant zu rea-lisieren.

In Anbetracht des Aufwandes undder Leidenschaft, mit denen die diver-sen Grundregeln guten Designs erörtertund unterrichtet wurden, könnte manleicht zu der Erwartung gelangen, diein der Realität eingesetzte Softwaremüsse heute besonders klug strukturiert

sein. Eine genauere Betrachtung desIT-gestützten Alltags zeigt jedoch, dasses gerade die grundsätzlichen und amweitesten akzeptierten Designprinzi-pien sind, die fortwährend verletzt wer-den. Betrachtet man etwa das Konzeptder „Separation of Concerns“, stelltman mit Verwunderung fest, dass esausgerechnet von den der Verbreitungnach erfolgreichsten Programmen mitFüßen getreten wird – und dies auf al-len erdenklichen Ebenen.

Bei den populären grafischen E-Mail-Clients etwa lassen sich gleich mehrereFälle unglücklicher Vermengungen undVerwechslungen beobachten. Da wer-den die lokalen Daten von E-Mailsnicht etwa in einem zentralen Verzeich-nis des Benutzers gespeichert, der dannjederzeit mit einem E-Mail-Client sei-ner Wahl darauf zugreifen könnte, son-dern in einer für den eingesetztenClient spezifischen Weise. Die E-Mailsgehören in diesem Modell nicht demEmpfänger, sondern vielmehr dem Pro-gramm, über das der Anwender sie er-halten oder verschickt hat. Ebenso weniggibt es eine Entkopplung der verschie-denen Aufgaben wie Empfang, Filte-rung, Darstellung, Verwaltung, Nach-bereitung oder Versand. Wer auf einenneuen E-Mail-Client umsteigen undseine bewährten Filterdefinitionen nichtverlieren will, hat Pech gehabt.

Ein noch gravierenderes Beispielfür eklatante Designfehler stellt dieaus dem Büroalltag nicht mehr wegzu-denkende WYSIWYG-Textverarbei-tung dar. Sie beruht auf der vollständi-gen Aushebelung einer Rollenteilung,die sich in der Erstellung von Schrift-stücken seit Jahrhunderten bewährthat: Der Autor als Inhaltsexperte, derTextsetzer als Formexperte, der Leserals Konsument. Bei WYSIWYG be-finden sich Dokumente in einem per-manenten Mischzustand zwischen Er-stellung, Drucklegung und Lektüre.Die hiermit einhergehende Verwischungder Verantwortlichkeiten wird naturge-mäß direkt bestraft: Der Autor – stel-lenweise sogar der Leser – muss auchüber das Layout entscheiden, obwohler nie gelernt hat, was etwa Punzen,Ligaturen und Durchschüsse sind. DasErgebnis ist ein laienhaft gesetztesDokument. Weil Form und Inhalt nichtgetrennt sind, bereiten die Versionie-rung und die parallele Bearbeitungvon Dokumenten große Schwierigkei-ten. Da es außerdem keinen klar defi-nierten Zeitpunkt der Drucklegunggibt, kämpft der Leser permanent mitveralteten Metadaten, inkonsistenten

92 iX 9/2009

REPORT Softwarearchitekturen

Design by DemutDaniel Mölle

Die Auswirkungen von Entwurfsentscheidungen

Gutes Design ist etwas Grundsätzliches, unabhängig von konkreten Lösungswerkzeugen und Technologien. Jede Modellierung, jede Software sollte genau das leisten,was ihre Bestimmung ist, und der Komplexität einer Aufgabeangepasst sein. Die Realität sieht aber meist anders aus.

ix.0909.092-095 10.08.2009 9:53 Uhr Seite 92

© Copyright by Heise Zeitschriften Verlag GmbH & Co. KG. Veröffentlichung und Vervielfältigung nur mit Genehmigung des Heise Zeitschriften Verlags.

Inhaltsverzeichnissen und bedeutungs-freien Indices.

Der IT-gestützte Alltag steckt vollerderartiger Beispiele für ungünstiges De-sign, das den natürlichen Arbeitsabläu-fen, Zuständigkeiten und Intentionenwiderspricht. Unter den zum Teil ver-heerenden Fehlentscheidungen, die sichin diesem Zusammenhang beobachtenlassen, haben nicht selten Millionenvon Anwendern zu leiden. So werdenallen Ernstes Versionierungswerkzeugeverkauft und eingesetzt, die den Zu-stand von Dateien nicht an den Dateienselbst, sondern an Metadaten festma-chen, die sich beliebig weit von derRealität entfernen können. Andere be-treiben ganze Serverfarmen mit Desk-top-Betriebssystemen. Nicht wenigerhäufig trifft man auf behördenartige In-formationssysteme, die ursprünglich zurUnterstützung von Business-Prozessengedacht waren, in Wirklichkeit jedochbewirken, dass die Geschäftsvorgängein einer der Software gefälligen Weiseabzuwickeln sind.

Höher, schneller, weiter und komplexerEine gängige ideelle Vorstellung vonAnforderungen ist die, dass sie vorge-ben, was eine Software leisten soll,aber keine Aussage darüber treffen, wiedas zu geschehen hat. Angesichts die-ser Trennung könnte man sogar zu derAnnahme verleitet sein, Requirementswohnten noch keine Designentschei-dungen inne. Dies ist jedoch aus meh-reren Gründen falsch: Erstens könneninsbesondere nichtfunktionale Anfor-derungen bereits sehr enge Rahmen -bedingungen für das Wie setzen, undzweitens kann schon das Was beliebiggravierende Verstöße gegen die Naturder jeweiligen Domäne enthalten.

Der Umstand, dass im Lauf der Zeitimmer komplexere Softwaresystemerealisierbar werden, führt naturgemäß

zu neuen Wünschen: HochintegrierteSysteme sollen immer umfassendereVorgänge abbilden, begleiten und steu-ern. Die Verlockung ist leicht nach-vollziehbar. Um ein Beispiel aus derGeschäftswelt zu bemühen: Es nimmtwenig Wunder, dass die tiefgreifendeErfassung sämtlicher Business-Prozes-se der Traum manchen Controllers ist.Allerdings gilt im Arbeitsalltag dasselbewie in der Physik: Wenn man noch diekleinsten Details erfassen will, gerätman in eine Situation, in der schon dieMessung selbst das Messobjekt massivbeeinflusst. Der anforderungsinhärenteDesignfehler – die Etablierung schwer-fälliger Erfassungsprozesse bis hinunterauf die Ebene der leichtfüßigsten Ge-schäftsvorgänge – verhindert von An-fang an den Erfolg des Systems.

Mit der wachsenden Komplexität von Software-Systemen nimmt die

Bedeutung von Software-Architektur rapide zu

Beispiele für derartigen Übereifer fin-den sich in beinahe allen Bereichen. Sogibt es heute Automobilhersteller, inderen Werkstätten ein Mechaniker eingutes Drittel seiner Arbeitszeit daraufverwendet, Auftragsdetails und interneLagerbewegungen zu verbuchen – wo-bei seine Performance minutiös doku-mentiert wird. Bei Trivialreparaturenliegt der Overhead für die detaillierteVerbuchung besonders hoch. Erfasstwird somit aber offenkundig nichtmehr die Dauer der eigentlichen Leis-tung, sondern vielmehr die des Erfas-sungsvorgangs. Der Erkenntnisgewinnfür den Controller ist dementsprechendgering, um – anlässlich der durch diepersönliche Distanz provozierten Fehl-interpretationen – nicht von einem Er-kenntnisverlust zu sprechen.

Ähnlich bezeichnend ist das folgen-de Zitat eines höheren Bankangestell-ten: „Mit unserer neuen Software kannman – da bin ich absolut sicher – eineMondlandung vollständig durchplanen;für die Eröffnung von Konten jedochist sie nicht geeignet.“ Es bezieht sichauf ein Softwaresystem, das nach sei-ner Einführung als Gesamtlösung dieeinzig verbleibende Möglichkeit dar-stellte, Geschäftsvorgänge abzuwickeln– insbesondere also die Eröffnung neu-er Konten, die seitdem eben nicht mehrfünf, sondern tatsächlich dreißig Minu-ten dauert.

Rechtzeitig rettend eingreifenDie gute Nachricht lautet: Wer für der-artige Auswüchse von Informationssys-temen sensibilisiert ist, hat gute Chan-cen, bereits bei der Erfassung derAnforderungen für eine neue Softwarerettend einzugreifen. Fordert etwa einKunde eine Oberfläche, die die Ab-wicklung des darzustellenden Vorgangsfalsch wiedergibt, muss man sich trau-en, unbequem zu sein. Möchte jemandzwei grundsätzlich verschiedene Dingeauf gleiche Weise darstellen, sollte manüber die Konsequenzen nachdenkenund sie auf konstruktive Weise darle-gen. Wer eine Überspreizung zwischender tatsächlichen und der anforderungs-induzierten Komplexität eines Vorgangsspürt, sollte den Unterschied messen.

Nebenbei bemerkt können ausufern-de Anforderungen auch ein ethischesProblem darstellen [1]. Computer we-cken allein durch ihre VerfügbarkeitBegehrlichkeiten, weil sie die syste -matische Erfassung und die zügige Ver-arbeitung immenser Datenmengen ge-statten. Diese Verarbeitung wiederumerfolgt anhand eines in Software gegos-senen Modells; über die Sinnhaftigkeitoder gar die Vertretbarkeit dieses Mo-dells ist damit allerdings nichts gesagt.In vielen Fällen lässt sich die Frage, auswelchem Grund eine bestimmte Soft-ware gewünscht wird, erstaunlich ein-fach beantworten: weil man sie schrei-ben kann.

So lassen sich auch die hartnäckigenpolitischen Bestrebungen der letztenJahre, die eine zunehmende Überwa-chung privater Kommunikation zumZiel haben, mühelos erklären. Tatsacheist: Die hierfür benötigten Informatio-nen sind verfügbar, und Massenspei-cher ist heute so billig und schnell, dasses mittlerweile schlichtweg plausibel

iX 9/2009 93

x-TRACT● In der IT gibt es unzählige Beispiele für Software mit ungünstigem Design, das

den gewünschten Arbeitsabläufen eher entgegenwirkt.

● Der Versuch, alle denkbaren Fälle abzudecken, kann zu unangemessener Komplexität führen, die die Ausführung der eigentlichen Aufgaben behindert.

● Elegante Lösungen lassen sich nur dann finden, wenn ein Projektteam die Natur der gestellten Aufgabe verstanden hat und sich nicht von Modeerscheinungen beeinflussen lässt.

ix.0909.092-095 10.08.2009 9:53 Uhr Seite 93

© Copyright by Heise Zeitschriften Verlag GmbH & Co. KG. Veröffentlichung und Vervielfältigung nur mit Genehmigung des Heise Zeitschriften Verlags.

ist, Verbindungsdaten aus der Festnetz-und Mobiltelefonie sowie von Internet-Providern systematisch und langfristigzu archivieren. Die nächsten denkbarenSchritte, etwa die GSM-Ortung oderdie Kennzeichenerfassung, sind tech-nisch ebenfalls bewältigt. Zweitrangigist dabei die konkrete Begründung fürihren Einsatz, und sie lässt sich leichtden aktuellen Trendthemen anpassen;psychologisch entscheidend ist wie sooft die Emotion, hier also der Reiz hin-ter der Idee, eine akribische Erfassungdieser Daten durchzuführen.

Spannend allein bleibt die Frage,wie das Datengebirge tatsächlich ge-nutzt werden wird, wenn es erst mal daist – und die nächsten Begehrlichkeitennach sich gezogen hat. Unter anderemkönnte man sich mit der Frage beschäf-tigen, ob nicht gerade die Nation, derenerste Anwendung maschineller Infor-mationssysteme unter anderem der Ju-denverfolgung diente, heute bei dersystematischen Erfassung und Verwah-rung persönlicher Daten durch außerge-wöhnliche Zurückhaltung und Beson-nenheit glänzen sollte.

Vorsicht mit dem Coolness-FaktorBereits 1972 hat Edsger Dijkstra in al-ler Deutlichkeit festgestellt, dass Be-scheidenheit und Demut in der Weltder Softwareentwicklung ausgespro-chen wünschenswerte Eigenschaftensind [2]. Gemeint hat er damit vor al-lem den Verzicht auf den kryptischenEinsatz verfügbarer Sprachmittel. Esmag möglich und reizvoll sein, ein ge-wünschtes Verhalten unter Ausnutzungerstaunlich komprimierter Anweisun-gen oder gar undokumentierter Seiten-effekte zu realisieren, aber in fast allenFällen ist es in erster Linie eins: bei derFehlersuche und Wartung so hinderlich,dass einigen gesparten Codezeilen undTakt zyklen unverhältnismäßige Folge-kosten gegen überstehen.

Selbstverständlich gibt es Ausnah-men vom Coolness-Verbot – beispiels-weise extrem effiziente Verfahren ausder Welt des „bit fiddling“, die zumTeil ansprechend dokumentiert sind [3],deren Einsatz aber nur an wirklich per-formancekritischen Stellen zu empfeh-len ist. Man bedenke in diesem Zusam-menhang immer, was die Vordenker derZunft über „premature optimization“gesagt haben. Genauso klar ist aberauch, dass eine übertriebene Ausformu-lierung trivialer Programmstücke unbe-

holfen wirkt und irgendwann wiederFehler provoziert, weil einfache Sach-verhalte ins Unübersichtliche ausge-dehnt werden. Das Gebot der Beschei-denheit impliziert keinen Verzicht aufSachverstand oder Intuition. Kurzum,die eleganteste Lösung ist einmal mehrdiejenige, die der Natur des Problemsam nächsten kommt.

Die Grundregeln guten Designs sind,wie alle anderen Mengen von

Prinzipien, zunächst Gegenstand einer subjektiven Wertung

Heute, mehr als dreieinhalb Jahrzehntenach Dijkstras wohlbekanntem Vortrag,zeigt sich bezüglich der von ihm ange-führten Tugenden ein geteiltes Bild –wenn auch in einem etwas anderenZusammenhang, der durch die techno-logische Entwicklung und den Zuwachsan Komplexität in Softwaresystemenbedingt ist.

Einerseits lässt sich in puncto Code-Qualität viel Gutes berichten. Mit Stan-dards wie MISRA-C existieren wohl-durchdachte und breit akzeptierteVereinbarungen darüber, welche be-rüchtigten Fälle von fehleranfälligerund wartungsfeindlicher Programmfor-mulierung zu unterlassen sind. Stati-sche Analysewerkzeuge wie PC-Lintunterstützen das disziplinierte Coding.Neuere Programmiersprachen werdenbewusst darauf ausgerichtet, möglichstfrei von Einladungen zu Zeigerakroba-tik oder zu Zugriffen auf interne Reprä-sentationen zu sein. Überhaupt herrschtunter vielen Entwicklern ein ausgepräg-tes Bewusstsein für den hohen Wert les-barer Quelltexte.

Sich nicht der Mode unterwerfenAndererseits lässt sich häufig beobach-ten, dass es mit der demütigen Zurück-nahme des Egos schnell vorbei ist,wenn es um übergeordnete Designent-scheidungen geht. Während früher zumBeispiel die Ausnutzung spezieller tech-nischer Eigenheiten eines Prozessors alsschick galt, trifft dies heute nicht seltenauf den Einsatz mächtiger Frameworksund betonierter Abstraktionsmechanis-men zu. Allzu häufig werden mit einerumwerfenden Leichtfertigkeit Entschei-dungen für schwergewichtige Techniken

getroffen, weil man diese gerade als mo-dern einstuft. Dabei gilt heute wie da-mals: Die Unterwerfung unter eine Mo-de ist nur dann nützlich, wenn sie demeigentlichen Zweck dient. Der Zweckjedoch ist schlichtweg die Lösung ei-nes Problems, nicht das Abhaken vonBuzzwords.

Je mehr Aufgaben eine Technik demEntwickler abnimmt, desto stärker musser sich ihrer Art unterwerfen, Aufgabendarzustellen und zu bearbeiten. In die-sem Zusammenhang lohnt es sich, diefolgende Frage zu stellen: Bis wohindient die Infrastruktur dem Entwickler,ab wann dient er ihr? Wer sich für eineschwergewichtige Technik entscheidet,gibt Kontrolle und somit Macht an sieab. Eine solche Entscheidung ist umso kritischer, wenn die zu lösendeAuf gabe ihrer Natur nach eher einfachist. (In diesem Kontext sind beispiels-weise die leidenschaftlich geführten De-batten zwischen den Verfechtern vonWS-* und REST interessant.)

Ein typisches Beispiel für eine pro-blematische Technik, die viele verfrühteinsetzen, ist das Multi-Threading. Dieparallelisierte Ausführung von Program-men führt extrem schnell an die Gren-zen dessen, was der menschliche Ver-stand intuitiv zu begreifen in der Lageist, wie aufschlussreiche Anekdoten überfehlerbehaftete Semaphoren in allerDeutlichkeit zeigen [4]. Die Folge sindRace Conditions, die ihrerseits Schutz-mechanismen provozieren, deren un-bedachter Einsatz wiederum leicht zuDeadlocks führt.

Nicht minder fragwürdig sind über-eilte Entscheidungen für komplexeProtokolle und die dafür entworfenenFrameworks. Bei der Abwägung ver-schiedener Kandidaten werden die jeweiligen Features allzu oft mit An-erkennung überhäuft, während der an-fallende Mehraufwand und Risikenkaum Erwähnung finden (wie im „De-sign by Buzzword“ üblich) und kaumjemand auf die Verhältnismäßigkeit dereinzusetzenden Mittel achtet. Der Preisfür das Vertrauen in die Hochglanz -lösung zeigt sich oft erst später, bei-spielsweise wenn das halbe Projekt-team wochenlang damit beschäftigt ist,eine Infrastruktur zu bändigen, die mitder Lösung des eigentlichen Problemskaum etwas zu tun hat.

Mit der wachsenden Komplexitätvon Softwaresystemen nimmt die Be-deutung von Softwarearchitektur rapi-de zu. Das ist kein Wunder: Eine kleine1000-Zeilen-Anwendung verträgt einschlechtes Design wesentlich eher als

94 iX 9/2009

REPORT Softwarearchitekturen

ix.0909.092-095 10.08.2009 9:53 Uhr Seite 94

© Copyright by Heise Zeitschriften Verlag GmbH & Co. KG. Veröffentlichung und Vervielfältigung nur mit Genehmigung des Heise Zeitschriften Verlags.

ein 100ˇ000-Zeilen-Projekt. Aber auchin diesem Kernbereich der Software-technik gilt, dass elegante Lösungennur realisierbar sind, wenn das Teamdie Natur der Aufgabe verstanden hat.Markante Fehleinschätzungen sind kei-ne Seltenheit.

Nützlich, aber keine SensationEin besonders lehrreiches Beispiel sindder Aufstieg und der mittlerweile offendiskutierte Niedergang von SOA (Ser-vice-oriented Architecture). Der Gedan-ke, Modularisierung so weit zu treiben,dass Komponenten unabhängig vonein -ander installiert und erst zur Laufzeitmiteinander verknüpft werden können,ist nützlich, aber keine die Weltordnungauf den Kopf stellende Sensation (zumalsie der seit Jahrzehnten von den Unix-Utilities praktizierten Kultur nach-kommt). Wartbarkeit oder Wiederver-wendbarkeit von Modulen erhöhen sichnicht dadurch, dass man die Kompo-nenten als Services bezeichnet. Schnitt-stellen bleiben Schnittstellen, und Än-derungen an Schnittstellen bleibenunabhängig davon, wie oft man dasWort „interoperabel“ bemüht, schwierig.

Jeder nichttriviale Eingriff in die Au-ßenwirkung eines Moduls bedingt dieAnpassung seiner Nachbarn – wenn eskeine Abhängigkeiten gäbe, existierteauch kein Zusammenhang. Das großePotenzial entkoppelter Anwendungenliegt eher in solchen Aspekten wie derTestbarkeit, etwa durch den Austauschvon Modulen durch Mocks, die Injek-tion von Ereignissen oder die Beobach-tung dadurch ausgelöster Reaktionen.Diese Stärken lassen sich bei gutemDesign allerdings auch in eine zurLaufzeit monolithische Applikationeinbringen. Insofern ist SOA im We-sentlichen nichts anderes als eine hilf-reiche Metapher, und es wäre mehr alsverwunderlich, wenn eine einzige Me-tapher den steinigen Weg zur nächstenGrößenordnung von Systemkomplexi-tät in eine gummierte Rolltreppe ver-wandeln könnte.

Auf ähnliche Weise wird gerne dasMissverständnis bedient, Tugenden wieModularität, Separation of Concerns,Information Hiding und so weiter sei-en der Welt der objektorientierten Spra-chen vorbehalten. Wer einmal eine inrohem C verfasste Firmware für eineingebettetes System im Handumdre-hen auf einen nagelneuen Mikrocon-troller portieren konnte, weil die Firm-

ware so elegant geschnitten war, dasssie neben einer sauberen Kapselung al-ler Hardwarespezifika die Testbarkeitbeliebiger Modulteilmengen garantier-te, der begreift, dass gutes Design et-was Grundsätzlicheres ist. Objektorien-tierung ist (in viel größerem Umfangals die oben erwähnte SOA-Metapher)eine nützliche Art, über Strukturennachzudenken und passende Modellein Software abzubilden – aber ebenauch nur das.

Eine wesentliche Voraussetzung für gute Architekturen ist und bleibt

jenseits aller Strömungen das korrekte Verständnis der Domäne

Eine wesentliche Voraussetzung für gu-te Architekturen ist und bleibt jenseitsaller Strömungen das korrekte Ver-ständnis der Domäne, also einmal mehrdas Erkennen der Natur der zu lösen-den Aufgabe. So gilt in der Software -architektur genau wie in der Algorith-mik, dass die elegantesten Lösungengenau dann entstehen, wenn sie diedem untersuchten Problem zugrundeliegende Struktur präzise erfassen undin der Software ohne künstlichen Ballastwiedergeben. Deshalb kann es jenseitswiederverwendbarer Entwurfsmuster,die sich auf spezielle Teilprobleme be-ziehen, kein Allheilmittel und keine Ein-heitslösung für Architekturfragen geben.

Saisonale Modethemen und Hype-Paradigmen wie SOA, AOP (Aspect-oriented Programming), Softwarepro-duktlinien und so weiter hinken derversprochenen Erlösungswirkung stetshinterher, weil man die entscheidendenErfolgskriterien des Architekturentwurfs– Intuition, Erfahrung, Domänenver-ständnis, Vorausahnung kommender An-forderungsänderungen – einfach nichtformalisieren kann.

Ein Schlusswort über ProzesseDie spannende Welt der Entwicklungs-prozesse enthält mit dem bekanntenWasserfallmodell eines der skurrilstenMissverständnisse der Softwaretechniküberhaupt: Obwohl es in der Literaturursprünglich als Negativ-Beispiel auf-geführt und schon bei seiner ersten for-malisierten Beschreibung als unbrauch-bar herausgestellt wurde [5], ist es in

Tausenden von Projekten zum Einsatzgekommen und selbst Jahrzehnte spä-ter noch unterrichtet worden. Der Kerndes Problems: Das Wasserfallmodellwiderspricht in vielerlei Hinsicht demWesen von Softwareprojekten; insbe-sondere die strenge Sequenzialität derverschiedenen Aufgaben wie Anforde-rungserfassung, Implementierung oderTest ist nicht zu halten.

Von dem entgegengesetzten Extrem– der Anwendung hochgradig komple-xer Prozesse für einfache Projekte – istselbstverständlich in ähnlicher Vehe-menz abzuraten. Wer sein Projektteamzu einer Behörde macht, muss mit be-hördenartiger Effizienz rechnen.

Als einzig vielversprechender Wegbleibt die Verwendung solcher Prozess-modelle, die sich hinsichtlich ihrerKomplexität auf das jeweilige Projektzuschneiden lassen, wie es etwa beimRUP-Tailoring (Rational Unified Pro-cess) geschieht. Die Kombination auseinem angemessenen Entwicklungspro-zess und agilen Methoden ermöglichteine Balance zwischen strukturierenderSystematik und produktiver Dynamik;sie ist wohl die beste derzeit bekannteArt, mit nichttrivialen Aufgaben umzu-gehen, und wird vermutlich noch Auf-stieg und Fall so mancher Modeer-scheinung überdauern. (ka)

DR. DANIEL MÖLLE ist bei der Zühlke Engineering GmbHals Software-Ingenieur mit den Schwerpunkten Eingebettete Systemeund .Net tätig.

Literatur[1]ˇJoseph Weizenbaum; Computer

Power and Human Reason; From Judgement to Calculation; W. H. Freeman, 1976

[2]ˇEdsger W. Dijkstra; The Humble Programmer; ACM Turing Lecture 1972:www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340.html

[3]ˇHenry S. Warren; Hacker’s Delight;Addison-Wesley, 2002

[4]ˇGerard J. Holzmann; The SPIN Model Checker; Primer and Refe-rence Manual; Addison-Wesley, 2003

[5]ˇWinston Royce; Managing the Development of Large Software Systems; Proceedings of IEEE WESCON 26, 1970

iX 9/2009 95

www.ix.de/ix0909092 x

ix.0909.092-095 10.08.2009 9:53 Uhr Seite 95

© Copyright by Heise Zeitschriften Verlag GmbH & Co. KG. Veröffentlichung und Vervielfältigung nur mit Genehmigung des Heise Zeitschriften Verlags.