IT IST NICHT GLEICH IT:

EIN PLÄDOYER FÜR EINE

SITUATIONSBEZOGENE

SOFTWAREENTWICKLUNG

zialentwicklungen, die der Fachseite keinenNutzen bringen, vermieden werden. Hierstellt sich etwa die Frage, ob es sich bei dervom Geschäft gewünschten Funktionalitätum Kern- oder Support-Prozesse handelt.Am Ende geht es immer um die Entschei -dung, ob stark volatile Anforderungen füreine bestimmte Anwendung überhauptstrategisch sinnvoll sind. Eine Entschei -dungs hilfe hierfür bietet beispielsweise dieWard-Peppard-Matrix (siehe Abbildung 1).Die Matrix beschreibt unter anderem, wel-che Kriterien herangezogen werden sollten,um die Weiterentwicklung und den Gradder Integration von Anwendungen in

Warum dauert das so lange? Diese Frage kennt vermutlich jeder Informatiker. Aber es gibtauch Ausnahmen, typischerweise auf der grünen Wiese, wo kleine Anwendungen entwickeltwerden, schnell und ohne aufwändige Prozesse. So entstehen nützliche, manchmal gar nichtso kleine Apps in kurzer Zeit, die man für wenig Geld oder gar kostenlos herunterladen kann.Warum sind dann die üblichen IT-Anwendungen so teuer und warum dauert es so lange, sie zu entwickeln oder zu ändern? In diesem Artikel zeigen wir einen Weg auf, um Entwicklungs- auf wände so weit wie möglich zu reduzieren.

m e h r z u m t h e m a :is.uni-paderborn.de/fachgebiete/fg-engels/veroeffentlichungende.capgemini.com/insights/buecher/quasar3.0

52 53

wieder bei der Ausgangsfrage: Was machtdie IT aufwändig und wie können dieseAuf wände reduziert werden?

Mehrere Aufwandstreiber

in der IT

Aufwandstreiber gibt es viele und sie sindvöllig unterschiedlicher Natur: Zum einenbesteht die Notwendigkeit, die Anfor -derun gen mehrerer Fachseiten gleichzeitigin einem Konzept zu vereinigen. Hinzukommen der Wunsch nach hoher Perfor -mance sowie die Anforderung, eine hoheVerfügbarkeit gewährleisten zu müssen.Darüber hinaus besteht die Erwartung,dass die Anwendung auch in fünf Jahrenihre Aufgaben noch zuverlässig erfüllensoll. Und nicht zuletzt ist der Kostendruckoft so hoch, dass die Umsetzung schließlichan kostengünstigere Arbeitskräfte ausgela-gert wird.

Die Liste ließe sich noch endlos fortfüh-ren, die Beispiele machen aber deutlich,dass die Anforderungen der Schlüssel zueinem erfolgreichen IT-Projekt sind.Hierbei können grundsätzlich zwei unter-schiedliche Klassen von Aufwandstreibernunterschieden werden:

1. Aufwandstreiber, die in dem Umfangder zu realisierenden Anwendung, alsodes Produkts, begründet sind und sichz. B. in Function Points messen lassen.

2. Aufwandstreiber, die auf Anforderun -gen basieren, die sich im Entwick lungs -prozess niederschlagen.

In der ersten Klasse der produktbezogenenAufwandstreiber schlummert ein gewalti-ges Einsparungspotenzial, denn Effektivitätberuht darauf, dass ein Projekt auf dasNotwendige beschränkt wird und Spe -

Die Informationstechnologie ist mittlerwei-le so allgegenwärtig geworden, dass sienicht mehr nur Geschäftsprozesse, wie z. B.die Buchhaltung, sondern nahezu alleKernprozesse eines Unternehmens unter-stützt. War früher die IT der Taktgeber fürÄnderungen und mussten die Nutzer dieDinge nehmen, wie sie kommen, so ist heu-te die Fachseite der Taktgeber. Die Fach -abteilungen sind dabei selbst getrieben voneinem sich immer schneller änderndenMarkt, der laufend neue Herausfor derun -gen und Konkurrenz erzeugt. Hierbei müs-sen die Fachabteilungen häufig mit IT-Altbeständen kämpfen, die für den Bestanddes aktuellen Geschäfts notwendig, abernicht immer einfach auf die neuen Belangeanzupassen sind. Mithin verursachen dieseIT-Altbestände hohe Kosten, oder schlim-mer, lange Änderungszeiten und bremsendamit das Geschäft aus.

Dadurch ergibt sich immer wieder dieFrage, wie in der Bestandssituation Pro -zesse beschleunigt und damit auch Kostengesenkt werden können. Der einfachsteWeg, um neue Geschäftsmodelle umzuset-zen, ohne durch die Anpassung bestehen-der Systeme Zeit zu verlieren, ist der paral-lele Neuaufbau von Funktionalität. Dies istaber nur vermeintlich schneller: In demAugenblick, in dem Alt und Neu verbun-den werden, etwa wenn Auswertungenüber gemeinsame Geschäftsobjekte, wieKunde oder Produkt, in den alten und derneuen Anwendung gefahren werden müs-sen, treten die bekannten Probleme wiederauf – also hoher Anpassungsaufwand unddamit hohe Kosten. Gleichzeitig führt dasEinbauen jeder kleinen Änderung in einebestehende Anwendung zu hohen Anfor -derungen an qualitätssichernde Maßnah -men, wie z. B. das Testen. Damit sind wir

Dr. Uwe Dumslaff

(uwe.dumslaff@capgemini.com)

ist Vice President und Chief Technology Officer bei

Capgemini in Deutschland. Er ist Senator der

Deutschen Forschungsgemeinschaft und engagiert

sich in der Gesellschaft für Informatik (GI e. V.).

Prof. Dr. Gregor Engels

(engels@upb.de)

forscht und lehrt im Bereich von Software -

architekturen und modellbasierten Entwicklungs -

methoden an der Universität Paderborn. Dort leitet

er die Technologie-Transfer-Institute C-LAB und

s-lab – Software Quality Lab.

Dr. Marion Kremer

(marion.kremer@capgemini.com)

leitet die CSD Research Abteilung von Capgemini

in Deutschland. Sie beschäftigt sich seit ca.

20 Jahren bei Kunden aus unterschiedlichsten

Branchen mit der Frage nach der richtigen

Entwicklungsmethodik für Software.

d i e au torenf achar t i ke l

5/2012

Anwendungslandschaften strategisch zusteuern (mehr dazu in [War96] und[War02]).

Für die weiteren Betrachtungen legen wirden Fokus auf die zweite Klasse der pro-zessbezogenen Aufwandstreiber, die ineinem IT-Projekt im Nachgang zu der stra-tegischen Entscheidung direkt beeinflusstwerden kann.

Da wir davon ausgehen, dass die System -eigenschaften die Aufwände der Erstellungbeeinflussen, stellen wir im Folgenden denZusammenhang zwischen eben diesenEigenschaften und den daraus resultieren-den Anforderungen an die Entwicklungeines Systems her. Vorab ist jedoch festzu-halten, dass wir mit „Anwendungen“ in

diesem Artikel Softwareanwendungen mei-nen, die betriebswirtschaftliche Aspekteabbilden – insbesondere solche, die einUnter neh men am Markt differenzieren. Einbesseres Beispiel als die oben erwähnteBuch haltung wäre hier ein speziellesBestellsystem, das eine hoch flexible Kon -figuration des Zielprodukts ermöglicht.

Es gibt natürlich auch Anwendungen, diesowohl Standardkomponenten als auchIndividualanteile enthalten. Für die folgen-den Betrachtungen gehen wir davon aus,dass im Vorfeld eine entsprechende Tren -nung stattgefunden hat. Für andere An -wendungsklassen, wie die Steuerung vonProduktionssystemen, mögen noch andereKriterien eine Rolle spielen. Der grundsätz-

Abb. 1: Die Ward-Peppard-Matrix (Quelle: [War96]).

Abb. 2: Die Aufgabe bestimmt Methode und Werkzeuge.

f achar t i ke l

liche Ansatz, dass nicht alle Software -systeme nach der gleichen Methodik undmit den gleichen Werkzeugen entwickeltwerden sollten, ist aber übertragbar.

Situationsabhängige Methoden

Wenn wir den Entwicklungsprozess fürSoftware betrachten und mit Entwick -lungsprozessen in anderen Disziplinen ver-gleichen, wird sehr schnell klar, dass sichauch die IT weiterentwickelt hat. Vom klas-sischen V-Modell über das konfigurierbareV-Modell XT bis hin zu dem konfigurier-baren RUP (Rational Unified Prozess) (vgl.[IBM07], [Kru04]) haben sich in derSoftwaretechnik die Entwicklungsprozess-Modelle weg vom universellen Prozess -modell hin zu differenzierten, situationsab-hängigen Modellen weiterentwickelt –analog zu dem Vorgehen in anderen Inge -nieurs wissenschaften (siehe Abbildung 2).

Die spannende Frage ist nun, wie ineinem konkreten IT-Projekt entschiedenwerden kann, mit welchem Prozessmodellund mit welcher Methodenausprägung einSystem entwickelt werden sollte und wel-che konkreten Methodenausprägungenüberhaupt notwendig sind. Unter „Metho -de“ verstehen wir dabei die Zusammen -stellung von Anleitungen für die Durch -führung einer bestimmten Aufgabe sowiedie entsprechenden Werkzeuge und Halb -fertigzeuge und was immer sonst noch not-wendig ist, um die Aufgabe sinnvoll durch-zuführen.

Manufaktur versus Fabrik

Als extreme Methodenausprägungen ver-wenden wir einen manufakturgeprägtenAnsatz auf der einen Seite und einen starkindustrialisierten auf der anderen.

Die ManufakturBei der Manufaktur steht die einmaligePro blemlösung im Vordergrund. Die Ma -nu faktur symbolisiert einen Entwicklungs -prozess, bei dem herausragende Expertiseund Kreativität des Entwicklers imMittelpunkt stehen. Mit diesen Fähigkeitenist der Entwickler in der Lage, völlig neueProblemstellungen zu bearbeiten, neueWerkzeuge und Methoden zu finden odergar zu erfinden und diese sinnvoll zumEinsatz zu bringen. Natürlich basiert auchdie Manufaktur auf bestehenden Erfah -rungen, Methoden und Werkzeugen. Hinzu

Sinnvollerweise erfolgt das Anfor -derungs management für eine Neu -entwicklung, bei der auch der Fach -bereich noch nicht genau weiß, was erbraucht, ganz anders als im Fall einer1:1-Ablösung. Im ersten Fall ist es sinn-voll, in engem Kontakt mit derFachseite die Funktionalität prototy-pisch zu erarbeiten, im zweiten ist eshäufig angemessener, auf Grundlageder abzulösenden Anwendung diebestehende Funktionalität derart zubeschreiben, dass der Fachbereich nurnoch die Qualität sicherstellen muss.

■ Benötigte Nachhaltigkeit der Archi -tektur: In der Regel ist es nicht sinnvoll,in ein Gewinnspiel, das eine sehr endli-che Lebenszeit von zum Beispiel weni-gen Monaten hat und bei dem einAusfall toleriert werden kann, den glei-chen Aufwand in die Architek tur -entwicklung zu investieren wie in eineAnwendung, die über die nächsten 20 Jahre laufen und dabei anpassbarbleiben muss. Bei letzterer ist insbeson-dere auch zu berücksichtigen, dass sichüber die Wartungszeit auf Grund vonFluk tuationen neue Mitarbeiter einar-beiten müssen. Die Architektur mussdas durch geeignete Separation ofConcerns etc. unterstützen.

■ Benötigte Nachhaltigkeit der Techno -logie: Gerade anspruchsvolle neueOberflächen auf hippen Endgerätenerfordern ein hohes Maß an aktuellerTechnologie im Sinn von Program mier -sprachen etc. Diese Anforderung stehtjedoch in krassem Widerspruch dazu,dass eine Anwendung möglicherweiseeine lange Lebenszeit haben soll, in derjedoch wenig fachliche Änderungen zuerwarten sind. Ein Beispiel für eine sol-che Anwendung wäre etwa dieZahlungsein gangsverarbeitung einerBank.

54 55

Konsequenzen für denEntwicklungsprozessLetztendlich liefert die industrialisierte Pro -duktion ebenso gute Qualität wie dieManufaktur. In beiden Fällen misst sichdiese Qualität an der Erfüllung derAnforderungen an das Ergebnis und denProzess. Im Fall der Manufaktur sind dieseAnforderungen typischerweise andere alsim Fall der Fabrik. Ein Beispiel hierfür istdie Entwicklung von sicherheitskritischerSoftware: Hier ist ein hohes Maß an Nach -weisführung notwendig – etwas, das mitdem hier verwendeten Bild der Manufakturkaum darstellbar ist.

Beide Ansätze haben ihre Daseins -berechtigung in unterschiedlichen Kon -texten (siehe Abbildung 3). Für beide, dieManufaktur und die industrialisierteFabrik, lässt sich nahezu entlang desgesamten Software-Entwicklungsprozesseseine Dif ferenzierung feststellen. Es gibt nurwenige Ausnahmen hiervon, die letztlichdaher rühren, dass bei beiden AnsätzenSystem komponenten aus unterschiedlichenTeilent wicklungsprozessen zusammenge-führt werden müssen. Ein Beispiel für einesolche Gemeinsamkeit in beiden Ansätzenfindet sich im Software-Konfigurations -manage ment, bei dem die Firma Capgeminidafür plädiert, ein grundsätzlich gleicharti-ges Ver fahren und ein Werkzeug für alleEnt wicklungsmodelle zu nutzen.

Eigenschaften des Zielsystems

Ob eine Anwendung oder ein Teil davonmit dem Manufaktur-Ansatz oder demindustrialisierten Ansatz realisiert werdensoll, hängt unserer Erfahrung nach von fol-genden Eigenschaften des Zielsystems ab:

■ Fachlicher Innovationsgrad des Sys -tems: Dies manifestiert sich sowohl imBereich des Anforderungsmanagementsals auch in der Qualitätssicherung.

kommt aber die spezialisierte Anpassungfür eine mindestens zu diesem Zeitpunktneue Aufgabenstellung. Gleich zeitig kannder Entwickler hier problemspezifischeOptimierungen in der Art der Abwicklungvornehmen, die nicht auf andere Projekteübertragbar sind. Für beide Aspekte hat derEntwickler den kompletten Entwicklungs -prozess im Blick und stellt sicher, dass alleTeilschritte zusammenpassen. Dabei wirddem Thema Doku mentation des Entwick -lungsprozesses weniger Rechnung getra-gen, weil die Wie derholbarkeit nicht imVordergrund steht.

Wenn man die Manufaktur auf dasWirkdreieck aus Effektivität, Effizienz undPreisökonomie abbildet, wird deutlich,dass der Manufaktur-Ansatz ein hohesMaß an Effektivität bietet, weil er eine hun-dertprozentig auf die Aufgabenstellungangemessene Lösung erarbeitet, typischer-weise dafür aber hochqualifizierte Kräftebenötigt, die möglichst gemeinsam und mitgeringem Kommunikations-Overhead ar -beiten. Hier gibt es nicht zwangsläufig einsehr starkes Gefälle im Wissen und bei derErfahrung. Dadurch, dass ein wesentlicherTeil der Lösungsfindung im Kopf stattfin-det, wird ein Austausch von Entwicklerndeutlich erschwert.

Die industrialisierte FabrikIn der industrialisierten Fabrik hingegenliegt der Fokus auf Wiederholbarkeit undNachvollziehbarkeit. Durch eine gezielteOptimierung von Einzelschritten werdendie Effizienz und die Preisökonomie opti-miert. Grundlagen dafür sind:

■ Wiederkehrende Teilschritte.■ Dass die dafür notwendigen Methoden

und Werkzeuge identifiziert werdenkönnen.

■ Dass die Effizienz laufend überprüftwird.

Mit dem industrialisierten Ansatz lassen sichhohe Durchsätze erreichen bei relativ gerin-gen Stückkosten, also z. B. „Aufwand proFunction Point“. Gleichzeitig ist der not-wendige Ausbildungsgrad der beteiligtenMitarbeiter typischerweise sehr unterschied-lich. Bei vielen Aufgaben wird darauf geach-tet, dass die Anforderungen an die Expertiseder Mitarbeiter nicht außergewöhnlich sind,um sicherzustellen, dass Mitarbeiter etwa imFall von Fluktuation mit vertretbaremAufwand ausgetauscht werden können. Abb. 3: Manufaktur und industrialisierte Fabrik haben beide ihre Berechtigung.

f achar t i ke l

5/2012

■ Notwendige Dokumentation: Eineabsehbar lange Wartungsphase und eindezentrales Sourcing-Modell erhöhenden Aufwand an benötigter Doku -mentation, da in beiden Fällen Kennt -nisse über das System weitergegebenwerden müssen, sei es an die unter-schiedlichen Entwicklungsstandorteoder an im Laufe der Wartungszeitwechselnde Mitarbeiter.

Scooter versus Zug

Um diese Differenzierung besser greifbar zumachen, haben wir Metaphern entwickelt,die die Extremausprägungen von IT-Systemen entlang den obigen Kriterien ver-deutlichen (siehe Abbildung 4).

Zum einen gibt es den Scooter, das schnel-le, agil zu entwickelnde und anzupassendeSystem, bei dem Nachhaltigkeit und Effi -zienz zugunsten von Ge schwin digkeit zurük-kstehen. Ein Scooter muss nicht viele Perso -nen befördern können und niemand erwartetvon ihm eine extreme Zuverlässig keit. Aller -dings muss auch der Scooter hinreichendsicher sein. Hier können wir State-of-the-Art-Technologien zu lassen, ja sie sind sogar eingewollter zentraler Baustein. Das heißt, wirstellen uns den Scooter typischerweise alsechtes Hightech-Wunder vor, nicht als denkleinen Motorroller, den es tausendfach anjeder Ecke gibt. Die Lebenser war tung desScooters ist geringer, häufig hat er eher denCharakter eines Experiments, das bei Gelin -gen zu seinem großen Bruder wird, dem Zug.Er ist aber der Wegbereiter der Innovationund damit der Agilität im Business.

Das Gegenstück zum Scooter ist der Zug:ein Lastenträger, der mit hoher Effizienzseine Last befördert und dabei hoheAusfallsicherheit und Verlässlichkeit bietet.Er bringt seine Leistung auf wohldefinier-ten Bahnen, Änderungen sind typischer-weise mit hohem Aufwand verbunden, weiler in ein ganzes Netzwerk von anderenAnwendungen eingebunden ist und dasGesamtsystem zuverlässig und mit hohenAbhängigkeiten zwischen den einzelnenZügen erfüllen muss.

Typischerweise sind Anwendungen nichtimmer reine Scooter oder Züge, sondern esexistieren auch Mischformen, wie z. B. Auto,Bus oder der Hub (mehr dazu in [Cap12]).

Für Zug und Scooter lässt sich ein direk-ter Bezug zu den Stars und Cash Cows ausder Matrix in Abbildung 1 (vgl. [War96])herstellen. Das liegt schlicht an der erwar-teten benötigten Nachhaltigkeit. Die Kon -zepte sind jedoch nicht deckungsgleich,weil es auch durchaus Anwendungen gebenkann, die fachlich innovativ sind, für derenEntwicklung aber keine technische Inno va -tion zum Tragen kommen darf, um ebendiese Nachhaltigkeit nicht zu gefährden.Von daher sind die beiden Konzepte vomCharakter her eher additiv als ersetzendund dienen dazu, unterschiedliche Aspekteder Systementwicklung zu steuern.

Fahrzeugtypen und

Softwareentwicklung

In der Softwareentwicklung helfen uns dieverschieden Fahrzeugtypen frühzeitig, d. h.

bereits beim Projektantrag, zu klären, wel-chen Typ wir vor uns haben, und dann zuentscheiden, mit welcher Methode dieseAnwendung entwickelt werden soll. Damitvermeiden wir, dass wir durch Einsatz einersehr auf Nachhaltigkeit und Wissens -transfer bedachten Methode im Fall vonScooter-Anwendungen unnötige Aufwändeproduzieren und damit Zeit für die Ent -wicklung verlieren. Gleichzeitig wird einVerständnis dafür aufgebaut, dass mehrNachhaltigkeit auch mehr Aufwand unddamit Zeit benötigt (siehe Abbildung 5).

Dieses Konzept kann auch im Entwurfvon Anwendungen verwendet werden,sodass durch eine intelligente fachlichgeprägte Architektur die oft gleichzeitigauftretenden Wünsche nach Flexibilitätund geringen Kosten und Nachhaltigkeitgeeignet auf die einzelnen Komponentenabgebildet werden können. Ein typischesBeispiel dafür ist die risikogesteuerteQualitätssicherung: Der häufig zur Anwen -dung kommende Ansatz, eine möglichstgleichmäßige und hohe Testüberdeckunganzustreben, erzeugt in Bereichen, in denenweniger Risiko besteht, zu hohe Aufwände.Gleichzeitig sollte sehr gründlich geprüftwerden, in welchen Bereichen sich dieAutomatisierung von Testfällen lohnt, weildie Änderungshäufigkeit der fachlichenAnforderungen gering ist. Entsprechendesgilt für die Architektur: Nur wenn manweiß, wo häufig fachlich bedingte Ände-

Abb. 4: Fahrzeugtypen dienen als Metapher für unterschiedliche Systemklassen.

f achar t i ke l

Abb. 5: Scooter erfordern eher die Manufaktur, Züge erlauben und brauchen die indu-strialisierte Fertigung.

56 57

rungen auftreten, kann der Aufwand fürdie Konfigurierbarkeit von Anwendungensinnvoll gesteuert werden.

Anwendungen verändern sich

Es ist ein durchaus üblicher Effekt, dass dievermeintlich kurzlebige, hippe Anwendungim Laufe ihres Lebens eine drastischeVeränderung erfährt und vom Scooter zumZug mutiert. Das hat die Konsequenz, dassalle Punkte, aufgrund derer die Ent scheidungbewusst für den Scooter weg vom Zug fiel,wie beispielsweise die Nachhaltigkeit derArchitektur, sich im Nachhinein als ver-meintliche Fehlent schei dungen entpuppen.Hier ist es besonders wichtig, dass die IT-Abteilung sehr deutlich macht, dass aus demScooter vermutlich nie ein Zug gewordenwäre, wenn er nicht als Scooter gestartetwäre, unter anderem weil der Scooter vielschneller zu entwickeln ist als der Zug.Umgekehrt gibt es durchaus auch dieSituation, dass aus einem vermeintlichen Zugschleichend ein Scooter wird, also dass dieAnforderungen an die Anwendungen sich

mindestens für be stimmte Teile schnellerändern als gedacht (siehe Abbildung 6).

Mehr Agilität für das Business

IT und Fachseite müssen proaktiv einenKon sens über ihre Interpretation der obi-gen Metaphern entwickeln, um in demWirkgeflecht zwischen Effektivität, Effi -zienz und Preisökonomie die jeweils richti-

ge situationsgerechte Balance herzustellenund damit, wo sinnvoll und möglich, zumehr Agilität zu gelangen. Häufig bedingtdies eine geänderte Sicht auf die Geschäfts -prozesse und die IT-Landschaft, da dasVorgehen natürlich deutliche Auswirkun -gen auf den Zuschnitt von Geschäftsfunk -tionen und ihre Umsetzung in IT zurKonsequenz hat. Darüber hinaus ist auchklar, dass einmal getroffene Entschei dun -gen unter sich verändernden Randbedin -gungen neu überprüft und gegebenenfallsangepasst werden müssen. Es hat keinenSinn, alles voraus sehen zu wollen.Stattdessen ist ein kontinuierliches gemein-sames Management der Anwendungs -landschaft notwendig, um zu jedem Zeit -punkt das Optimum zu erreichen (mehrhierzu in [War96] und [Eng08]).

Unter [Cap12] kann die ausführlicheBeschreibung des hier andiskutierten Kon -zeptes heruntergeladen werden. ■

Literatur & Links

[Cap12] Capgemini, Quasar 3.0 – A Situational Approach to Software Engineering, 2012, siehe:

de.capgemini.com/insights/buecher/quasar3.0

[Eng08] G. Engels, A. Hess, B. Humm, O. Juwig, M. Lohmann, J.-P. Richter, M. Voß, J. Will -

komm, Quasar Enterprise, dpunkt.verlag 2008

[IBM07] IBM Corporation, IBM Rational Unified Process, 2007, siehe:

http://www-01.ibm.com/software/awdtools/rup/ (besucht Juni 2012)

[Kru04] P. Kruchten, The rational unified process: an introduction (3rd Ed.) Addison-Wesley

2004

[War96] J. Ward, P. Griffiths, Strategic Planning for Information Systems (2. Aufl.), Wiley 1996

[War02] J. Ward, J. Peppard, Strategic Planning for Information Systems (3. Aufl.), Wiley 2002

Abb. 6: Aus Scootern werden Züge und umgekehrt.

f achar t i ke l