Blog

Inversion of Control

2012-04-17T11:42:00Z

Vergleichbar mit der Konstruktion eines Wolkenkratzers, müssen bei der Erstellung einer Software Architektur-Richtlinien definiert und berücksichtigt werden. Wird dies nicht befolgt, stürzt die Konstruktion über kurz oder lang ein.
Inversion of Control gibt dem Entwickler ein effektives Tool an die Hand, um Software auf Klassenebene so solide zu bauen, dass auch bei größeren Umbaumaßnahmen oder langjähriger Weiterentwicklung die Architekturaspekte Erweiterbarkeit, Wiederverwendbarkeit, Testbarkeit nicht in Mitleidenschaft geraten.

Große Softwaresysteme bestehen üblicherweise aus mehreren Modulen mit unterschiedlichen Aufgaben. Typischerweise sind solche Module ineinander verschachtelt und hängen voneinander ab. Auch die Klassen in einem Modul sind von anderen Klassen unterschiedlich stark abhängig. Aus der dadurch entstehenden starken Verwobenheit von Klassen resultiert oft die Notwendigkeit bei Änderungen in einer Klasse, deren abhängige Klassen auch anpassen zu müssen. Das macht ein großes System schwierig erweiter- und wartbar - und verursacht letztendlich höhere Kosten.

Um dieses Problem zu vermeiden und eine höhere Software-Qualität zu erreichen, werden Klassen und Module so gebaut, dass eine möglichst lose Kopplung zwischen den unterschiedlichen Komponenten vorherrscht. Dadurch wird vermieden, Klassen anpassen zu müssen, die nicht angefasst werden wollten.

Wie kann man also eine losere Kopplung erreichen? Genau hier kommt das Prinzip „Inversion of Control“ zu Hilfe.

Beispiel-Szenario

Um das Problem genauer zu betrachten, wird im Folgenden ein einfaches Beispiel-Szenario vorgestellt, für das zwei Implementierungsansätze in Java vorgestellt werden.

Anforderungen

Dokumente sollen durchsuchbar sein
Die FAST-Suchmaschine soll verwendet werden
evtl. soll dieses Jahr auf eine andere Suchmaschine geschwenkt werden
Zur Qualitätssicherung sollen Unit-Tests geschrieben werden

Man könnte die Umsetzung der Anforderungen in zwei Module aufgeteilt umsetzen. Ein Modul, das die Implementierungen der verschiedenen Suchanbieter zur Verfügung stellt (SearchProvider) und ein zweites Modul (SearchService), das den Suchservice implementiert und das einen der implementierten Suchanbietern benutzt und damit von dem SearchProvider abhängig ist.

Implementierungsansatz 1 (enge Kopplung - so besser nicht)

Beim ersten Ansatz werden die Anforderungen mit enger Kopplung zwischen den beiden Modulen umgesetzt. Die folgenden Code-Ausschnitte skizzieren die Implementierungen in den beiden Modulen:

SearchProvider

SearchService

Der SuchService hängt direkt von dem FAST-SearchProvider ab, die Erstellung des SearchProviders wird also direkt im SearchService durchgeführt. Genau dadurch entsteht eine enge Kopplung zwischen diesen Modulen.

Die direkte Abhängigkeit führt dazu, dass bei einem späteren Austausch des SearchProviders auch des SearchService-Modul angepasst werden muss. An diesem Beispiel sieht die Anpassung in den beiden Modulen ziemlich einfach aus, aber bei einem komplexeren System könnte dies zu zusätzlichen Aufwänden führen wie z.B. Deployment von mehreren Komponenten oder Durchführung von mehreren Tests, was weitere Risiken und Aufwände mitbringen könnte.

Unit-Tests zum Suchservice:

Ein anderes Problem taucht auf, wenn man die implementierte Funktionalität testen möchte. Bei einem Unittest ist das Ziel nur eine Unit automatisiert zu testen. An dem Code-Beispiel ist die Unit der SearchService. Um den SearcService als Unit zu testen, sollte der SearchProvider durch einen MockSearchProvider ersetzt werden. Dies ist über Anpassungen der SearchProviders möglich. Wird das nicht gemacht, schlägt der Unit-Test auf die Suchmaschine durch und wird zu einem Integrationstest bei dem der Suchserver erreichbar sein muss.

Was ist aber die wirkliche Ursache für die angedeuteten Probleme?

Die Ursache ist eigentlich die direkte Abhängigkeit des SearchService von dem FAST-SearchProvider.

Wer den Code genauer anschaut, erkennt, dass diese direkte Abhängigkeit nicht zwingend notwendig ist. Die Variable, die auf die SearchProvider-Implementierung referenziert, wird eigentlich als eine Instanz von dem SearchProvider-Interface deklariert, d.h. als eine Abstraktion von dem SearchProvider. In dem restlichen Codeabschnitt, wo diese Variable verwendet wird, werden Funktionalitäten genau aus der Definition der Abstraktion aufgerufen. Das heißt, dass der FAST-SearchProvider dort überhaupt nicht bekannt ist oder sein sollte und eigentlich nur bei der Initialisierung der Variable referenziert wird.

Wenn die Initialisierung der Variable außerhalb des SearchServices stattfinden könnte, würde er nicht mehr von der konkreten Implementierung - dem FAST-SearchProvider - abhängen, sondern nur von der definierten Abstraktion.

Eine solche Lösung würde den Austausch von dem SearchProvider vereinfachen, da in diesem Fall der SearchService nicht angepasst werden muss. Die Einbindung des MockServices im Unittest wäre dann einfach.

Implementierung 2 (losere Kopplung - so ist besser)

Der folgende Implementierungsansatz zeigt, wie man die Anbindung von dem SearchService zu einem konkreten SearchProvider außerhalb von dem SearchService auslagern könnte. Dabei kommt das Inversion of Control Framework Google Guice zur Hilfe.

Mit Guice sieht die Implementierung des SearchServices so aus:

Die Annotation @Inject gibt dem Framework den Hinweis, dass hier ein SearchProvider angebunden (injected) werden sollte. Die Anbindungsdefinition geschieht dann außerhalb von dem SearchService in einer separaten Klasse, z.B. für den MockSearchProvider wie folgt:

Man kann im Code die Anbindungskonfiguration verwenden, um den entsprechenden Service zu benutzen, z.B. um in den Unittests für den SearchService den MockSearchProvider statt den echten SearchProvider anzuwenden:

Bei diesem Ansatz wurde die Kontrolle der Erzeugung von dem konkreten SearchProvider von dem SearchService an das Framework übergeben („Inversion of Control“). Damit könnte man dann Anbindungen umdefinieren oder austauschen und dies, ohne den SearchService anpassen zu müssen. Dadurch wird die lose Kopplung zwischen dem SearchService-Modul und dem SearchProvider-Modul erreicht.

Fazit - was bringt Inversion of Control?

Trennung zwischen Nutzung und Erzeugung von Objekten

- > losere Kopplung

Einfache Austauschbarkeit
Fokus auf das Design
Sicht nur auf gebrauchte Funktionalität
Schneller und leichter Austausch von Komponenten
Weniger Nebeneffekte

-> bessere Testbarkeit

Verwendung von Mocks
Schwerpunkt auf das Testen von dem Klassenverhalten
Keine Tests von Abhängigkeiten
Keine Nebeneffekte

Herausforderungen

Bei der Betrachtung von Klassen die Guice nutzen, wird die Zuordnung zu den verwendeten Implementierungen undurchsichtiger. Hier muss dann in das entsprechende Modul geschaut werden, in dem den Interfaces die konkrete Implementierung zugeordnet ist. Dies erschwert z.B. die Fehleranalyse, wenn Konzept und Framework nicht verstanden wurden.

Hmm..why should I care?

Bei der Konstruktion von Gebäuden ist die Einhaltung von Architekturvorgaben unverzichtbar. Genauso selbstverständlich sollten sich Softwareentwickler Prinzipien wie „Inversion of Control“ aneignen, um die Qualität der Software signifikant zu steigern. Eine losere Kopplung und eine bessere Testbarkeit dient nicht dem Selbstzweck, sondern führt zu einer verständlicheren, leichter erweiterbar und automatisiert testbarenr Software. Refactorings lassen sich dadurch kontrollierter durchführen. Dies resultiert in Systemen an denen länger Entwickelt nicht nur in einer Kostenersparnis, sondern erhöht die Kundenzufriedenheit signifikant.

Autoren: Robert Süggel u. Mihail Tsvyatkov

Automatisierte Tests über Weboberflächen

2012-03-19T09:21:00Z

Fast jeder kennt das Problem. Man implementiert neue Funktionalität, führt eventuell noch paar Code-Optimierungen durch und lässt anschließend Unit-Tests laufen. Obwohl alle Tests erfolgreich sind, ist man trotzdem nicht immer sicher, ob eigene Änderungen keine Seiteneffekte verursacht haben, die erst beim manuellen Testen der Applikation über die Oberfläche ersichtlich werden. Ganz schlimm wird es, wenn diese Fehler ganz übersehen werden. Meistens ist es nicht der Fall. Doch wer sicher sein will, sollte sich über Testautomatisierung der Benutzeroberflächen (GUI-Testing) Gedanken machen.

Wozu GUI-Tests?

Unit-Tests alleine sind im Bereich der Softwarequalität nicht ausreichend, da bei dieser Art des Tests die Software nur aus der Codeperspektive betrachtet und getestet wird (s.g. White-Box Tests). Dabei wird eine zentrale Sicht auf das Produkt nicht ausreichend berücksichtigt – die Anwendersicht. Der Anwender verwendet die Applikation grundsätzlich anders als Unit-Test. Für diesen ist die Anwendung eine Black Box, die über die Oberfläche bedient wird. In Folge dessen, wird er mit anderen Problemen und Fehlern konfrontiert. Besonders bei Webapplikationen entstehen zusätzlich Probleme durch unterschiedliche Browsertypen und Betriebssystemen.

Aus diesem Grund werden GUI-Tests in Softwareprojekten durchgeführt. Manuelle Testdurchführung über Oberflächen ist meist sehr aufwändig, zeitintensiv und teuer. Besonders bei Regressionstests, bei denen immer wieder die gleichen Testszenarien durchgeführt werden, um die Grundfunktionalität der Software zu gewährleisten.

Automatisierte GUI-Tests?

Die Notwendigkeit der Automatisierung von Testabläufen steht in den meisten Softwareprojekten außer Frage. Nicht nur der Buildprozess und die Unit-Tests Läufe, sondern auch GUI-Tests lassen sich inzwischen sehr zuverlässig und stabil automatisieren.

Testautomatisierung über die Benutzeroberflächen kann weitgehend die Unit-Test ergänzen und auch dazu beitragen, dass die Qualitätsprobleme und Seiteneffekte so früh wie möglich erkannt werden. Dadurch können eine bessere Produktqualität erreicht, die Entwicklungs-, Fehlerlokalisierungszeiten verkürzt und somit die Kosten reduziert werden. Insbesondere bei Regressionstests.

Die Erstellung und Wartung von automatisierten GUI-Tests ist natürlich auch mit Aufwand verbunden und steht somit nicht immer im Verhältnis zwischen Kosten und Nutzen. Wenn man sich für die Testautomatisierung entscheidet, sollte folgendes beachtet werden:

Man sollte nicht versuchen, alles zu automatisieren. Testerstellung, Wartung und Durchführung müssen im Verhältnis zu den manuellen Tests stehen.
Wenn eine Funktion mit Unit-Test getestet werden kann, dann wird mit Unit-Test getestet und nicht über die Oberfläche. „Don’t write Front-End Tests“ [2].
Bei der Testerstellung muss auf Wartbarkeit und Wiederverwendbarkeit geachtet werden.

Automatisierte GUI-Tests bei der it-economics GmbH

Eines der wichtigsten Themen in unserer Firma ist die Qualität der Software. Da die automatisierten GUI-Tests die Unit-Test hervorragend ergänzen und somit zur Erreichung besserer Softwarequalität führen, wollen wir auch auf diesem Themengebiet unser Wissen ausbauen.

Bei uns werden Web-Anwendungen entwickelt und erweitert, die sehr sensible Daten verarbeiten. Deswegen ist es für uns besonders wichtig, dass die Qualität in diesem Bereich bestens gesichert ist. Zu diesem Zweck haben wir letztes Jahr eine konkrete Aufgabe im Rahmen einer Bachelorarbeit definiert: Ziel war geeignete Werkzeuge für diesen Zweck systematisch zu ermitteln und nach unseren Kriterien zu evaluieren. Das „Sieger-Werkzeug“ soll zukünftig in unserem Unternehmen für die Automatisierung von Oberflächentests von Web-Anwendungen eingesetzt werden.

Mittels einer Marktanalyse wurden über 90 Produkte ermittelt. Nach der Erstfilterung anhand von „Muss“-Kriterien, blieben nur noch 12 Tools übrig, die daraufhin anhand von „Wunsch“-Kriterien genauer evaluiert und einzeln bewertet wurden. Die höchste Bewertung erhielt Selenium WebDriver (Selenium 2) und stellte sich als insgesamt sehr überzeugendes Werkzeug heraus, natürlich auch weil das Java basierende Open Source Tool perfekt in unseren Unternehmenskontext passt."

Selenium WebDriver

Selenium ist schon lange eine gute Alternative zu schwergewichtigen, proprietären und v.a. teuren Lösungen. Heute wird es von Firmen wie Ford Motors, Deutsche Bank, Adobe und Google eingesetzt [1]. Neben wenigen Schwächen in der Dokumentation und im Reporting, hat dieses Produkt viele Vorteile, die für it-economics GmbH eine wichtige Rolle spielen, u.a.:
ausgezeichnete Integrität in den Unternehmenskontext

hohe Zukunftssicherheit
große Community
Erweiterbarkeit
Übersichtlichkeit, Wiederverwendbarkeit und Wartbarkeit von Tests
GUI-Test in Form von JUnit-Test und dadurch die Möglichkeit der Anbindung der Testausführung an Continuous-Integration-Systeme (CI-Systeme) wie beispielweise Jenkins[3].

Mit Selenium WebDriver wurden im Rahmen der Bachelorarbeit vereinbarte Testszenarien exemplarisch umgesetzt, die Testausführung in ein CI-System integriert und somit der gesamte Testablauf beispielhaft automatisiert.

Ausblick

Im nächsten Schritt werden wir die gewonnenen Erkenntnisse auf unsere Infrastruktur anwenden, unser Know-How im diesem Bereich weiter ausbauen und letztendlich dieses Wissen unseren Kunden zur Verfügung stellen.

Quellen:
[1] Java Magazin 9/2011, Seite 100.
[2] http://wn.com/GTAC_2010_The_Future__of_Front-End_Testing (Minute 3)
[3] http://www.jenkins-ci.org

PMP/PMI für Projektleiter

2012-03-07T00:56:00Z

Fast jeder Projektleiter wurde in seinem Berufsleben des Öfteren befragt, über welche Fähigkeiten er verfügen muss, um seine Arbeit erfolgreich auszuführen. Neben sehr guten kommunikativen und menschlichen Fähigkeiten, den sog. Social Skills muss er über hervorragende Methodenkenntnisse des Projektmanagements verfügen. Diese hat er normalerweise über die praktische Ausübung seiner Tätigkeit erlernt und wendet sie alltäglich bewusst oder auch unbewusst erfolgreich an. Diese Methodik wird in der Regel durch die Unternehmen, in denen die Projekte durchgeführt werden vorgegeben. Eine übergreifende Projektmethodik, die internationale Anerkennung genießt, ist der PMI (Project Management Institute) Standard, der durch das PMP (Project Management Professional) zertifiziert wird. Die in dieser Zertifizierung abgefragte Projektmethodik beschreibt die Prozess- und Werkzeugkenntnisse eines Projektleiters, die zur erfolgreichen Ausübung der Projektmanagementtätigkeit notwendig sind. Hierbei beschränkt sich das PMP für PMI nicht nur auf die Softwareindustrie, sondern erfreut sich z. B. auch in den Bereichen der klassischen Ingenieurwissenschaften hoher Anerkennung. Dieser Blog enthält zum Thema PMP/PMI für Projektleiter folgende Inhalte:

PMP Zertifizierung/ Prüfung nach PMI– Was ist das?
Welche Zertifizierungsvoraussetzungen gibt es und wo melde ich mich an?
Was muss ich wissen bzw. wie bereite ich mich vor?
Was folgt nach der Zertifizierung?
Fazit zur PMP Zertifizierung nach PMI

PMP Zertifizierung/ Prüfung nach PMI– Was ist das?

Das Project Management Institute (PMI) ist ein weltweit tätiger US-amerikanischer Projektmanagementverband. Das PMI bietet mehrere Zertifizierungen an. Hierbei ist das PMP das Bekannteste. Das PMP steht für Project Management Professional und bezeichnet die Prüfung bzw. Zertifizierung, die die Projektmanagementkenntnisse nach PMI-Standard überprüft. Es wird von fast allen Industrien anerkannt als Zertifizierung für Projektleiter. In den Vereinigten Staaten ist das PMP beispielsweise ein notwendiges Kriterium, um eine Funktion als Projektleiter im öffentlichen Bereich auszuüben. Im Januar 2011 gab es über 500.000 Project Management Professionals (PMPs) in über 185 Ländern.

Die Prüfung zur PMP Zertifizierung hat folgendes Format:

Die Prüfung dauert 4 Stunden (inklusive optionaler Pausen).
Sie besteht aus 200 Multiple Choice Fragen. Jede Frage besteht aus 4 Auswahlmöglichkeiten, wobei nur jeweils eine davon richtig ist.
Von den 200 Fragen werden 175 für die finale Bewertung herangezogen (25 davon – die nicht gesondert gekennzeichnet sind – werden nicht für die finale Bewertung herangezogen, sondern sind in der Regel potentielle zukünftige Fragen, die von PMI evaluiert werden)
Die Prüfung gilt als bestanden, sobald 61% der Fragen richtig beantwortet wurden (d.h. also mindestens 106 von 175)
Die Prüfung wird in autorisierten und video-überwachten Prometric Testcentern durchgeführt.
In die Prüfungszimmer dürfen weder Unterlagen noch Verpflegung mitgenommen werden.

Welche Zertifizierungsvoraussetzungen gibt es und wo melde ich mich an?

Die PMP Zertifizierung ist ausgerichtet auf berufstätige Projektleiter, die eine zusätzliche Qualifikation erhalten wollen, in dem sie ihre Methodenkenntnisse nach dem PMI Standard innerhalb der PMP Prüfung zertifizieren lassen. Die PMP Zertifizierung ist daher strengen Zugangsvoraussetzungen unterworfen:

Ein Bewerber muss über eine spezifische Ausbildung verfügen (i. d. Regel – aber nicht ausschließlich - ist dies ein abgeschlossenes Studium)
Zudem muss der Bewerber - je nach Ausbildung – über einschlägige Erfahrungen über mindestens 3 Jahre/4500h bzw. 5 Jahre/7500h (innerhalb der letzten 8 Jahre) im Bereich Projektmanagement vorweisen. Aus eigener Erfahrung ist diese Zugangsvoraussetzung sehr sinnvoll, da eine Abbildung der in der Vergangenheit erworbenen Projektmanagementkenntnisse das Erlernen der PMI-Methodik stark vereinfacht.
Des Weiteren muss der Bewerber vorweisen, dass er Projektmanagement Schulungen in einem Umfang von 35 Stunden besucht hat

Die Anmeldung erfolgt über die offizielle PMI Website https://www.pmi.org/default.aspx. Dort ist ebenfalls der Anmeldeprozess detailliert beschrieben.

Was muss ich wissen bzw. wie bereite ich mich vor?

Die PMP Zertifizierung überprüft die Projektmanagementkenntnisse nach PMI-Standard. Um die Prüfung bestehen zu können, müssen diese Werkzeuge, Nomenklaturen und Vorgehensweisen verinnerlicht werden. Die PMI-Standards sind detailliert beschrieben in „A GUIDE TO THE PROJECT MANAGEMENT BODY OF KNOWLEDGE (PMBOK® GUIDE)“ PMBOK.

Die Projektmanagementmethodik wird unterteilt in sog. „Prozessgruppen“ und „Knowledge Areas“ eines Projektablaufs.

1) PMI unterscheidet hierbei in folgende „Prozessgruppen“ als Teilbereiche eines Projektes:

Initiating
Planning
Executing
Monitoring & Controlling
Closing

2) Des Weiteren unterscheidet PMI in folgende „Knowledge Areas“ eines Projektablaufs:

Integration
Scope
Time
Cost
Quality
Human Resource
Communications
Risk
Procurment

Beide Bereiche kreieren in der PMI-Methodik eine Matrix, in der die unterschiedlichen Projektprozesse definiert sind, die innerhalb eines Projektablaufs (Initiating -> Closing) für die unterschiedlichen „Knowledge Areas“ (Integration -> Procurement) durchzuführen sind.

Folgende Abbildung beschreibt alle PMI Projekt Prozesse innerhalb einer „Prozessgruppen – Knowledge Area“ Matrix:

Abbildung 1 Projektmanagement Prozesse - Mapping der Prozessgruppen und Knowledge Areas (Quelle: PMBOK)

Der Prozess „Develop Project Charter“ ist somit Teil der Prozessgruppe „Initiating“ und Teil des Knowledge Areas „Integration“ Die Bestandteile der so aufgebauten Matrix sind Prozesse, die im Laufe eines Projektes durchschritten werden. Jeder Prozess basiert hierbei auf Eingaben (Inputs), die Ergebnisse (Outputs) anderer Prozesse sein können. Des Weiteren benützt jeder Prozess Werkzeuge (die sog. Tools & Techniques), die ihn dabei unterstützen, die Ergebnisse zu erstellen.

Eine Anmeldung zur Prüfung ist dann sinnvoll,

wenn dem Prüfungsteilnehmer sowohl die Position des Prozesses innerhalb der „PMI-Matrix“ vertraut ist, als auch der eigentliche Inhalt bzw. die notwendigen Aktivitäten.
Zudem müssen die Inputs und Outputs bzw. auch die Tools & Techniques zu allen Prozessen bekannt sein.
Schließlich muss das Wissen durch zahlreiche Multiple Choice Tests gefestigt werden. Hierbei ist es vor allem wichtig, dass der Prüfungsteilnehmer mit den PMI Fragetechniken vertraut wird. Testfragen mit Beispieltests lassen sich im Internet finden.

Aus eigener Erfahrung empfehle ich, einen professionellen Vorbereitungskurs zu belegen. Dies hat vor allem den Vorteil, dass man sich Full-Time auf den Prüfungsstoff vorbereiten kann. Des Weiteren empfehle ich, nicht allzu viel Zeit zwischen Vorbereitungskurs und Prüfungstermin vergehen zu lassen. Idealerweise sollte ein Wochenende dazwischenliegen, die Dauer zwischen Ende des Vorbereitungskurses und Prüfungstermin sollte allerdings nicht länger als eine Woche betragen.

Was folgt nach der Zertifizierung?

Sobald die PMP Zertifizierung bestanden ist, darf man den Titel PMP nach PMI 3 Jahre lang führen. Darüber hinaus muss ein PMP ständigen Zertifizierungsanforderungen genügen, um seine Zertifizierung aufrechtzuerhalten. Diese Rezertifizierungen stehen alle drei Jahre an.
Um die Zertifizierung nach 3 Jahren erneuern zu lassen, benötigt man 60 Professional Development Units (sog. PDUs). Diese PDUs erhält man beispielsweise durch folgende Aktivitäten:

Schulungen:
a.   Teilnahme an Projektmanagement Schulungen, die durch PMI angeboten werden
b.   Teilnahme an Projektmanagement Schulungen, die durch Universitäten bzw. Trainingsorganisationen angeboten werden
c.   Selbstständige Weiterbildung

Aktives Lehren/ Anweisen:
d.   Durch Erstellung von Projekt Management Knowhow
e.   Freiwillige (unentgeltliche) Erbringung von Projektmanagement Diensten
f.   Arbeit als Projektleiter

Hierbei wird jeder Dauer einer Aktivität ein PDU Wert zugeschlüsselt. Hierbei gilt als Faustformel, dass ein PDU einer Arbeitsstunde/ Schulungsstunde/ Lehrstunde etc. entspricht (a) – e)). Für den Bereich f) erhält ein Projektleiter 5 PDUs, wenn er 12 Monate als Projektleiter tätig ist, sodass also max. 15 PDU für die Tätigkeit als Projektleiter innerhalb der 3 Jahre geltend gemacht werden dürfen.
Genauere Details zu den PDUs und dem Rezertifizierungsverfahren kann ebenfalls dem PMBOK entnommen werden.

Fazit zur PMP Zertifizierung nach PMI

Die Vorbereitung zur Prüfung stellt zwar einen sehr hohen Aufwand dar. Zudem dauert die Prüfung selbst mit 4 Stunden relativ lange. Trotzdem überwiegen meiner Meinung nach die positiven Aspekte und ich kann die PMP Zertifizierung nach PMI auf jeden Fall empfehlen.
Ich empfand es als sehr interessant, die Methoden und Prozesse des Projektmanagements im Rahmen des PMI Standards kennenzulernen und diese mit den Projektvorgehensweisen mit den mir bekannten Modellen bzw. Methoden zu vergleichen. Die PMI Projektmethodik gibt hier einen guten Überblick über das Projektmanagement und so manche Aufgabe, die man im Berufsleben eher unbewusst anwendet, findet hier sehr oft ein entsprechendes Mapping in einen der PMI Projekt Prozesse bzw. Aktivitäten. Zudem ist es von Vorteil mit einer Methodik vertraut zu sein, die nicht nur in der Softwareentwicklung anerkannt ist, sondern auch von anderen Disziplinen wie z.B. den klassischen Ingenieurwissenschaften geschätzt wird. Die Zertifizierung macht m. E. nur dann Sinn, wenn bereits mehrere Jahre Projektexpertise gesammelt wurden. Deshalb ist eine der Zugangsvoraussetzungen der Nachweis des Zeitraums der bereits als Projektleiter erbrachten Tätigkeiten. Der größte Vorteil der PMP Zertifizierung nach PMI ist jedoch die Steigerung des Marktwerts. Einerseits erhöht sich natürlich der Marktwert des Projektleiters, der über diese Zertifizierung verfügt. Andererseits verbessert sich ebenfalls der Marktwert der Beratungsfirma, indem das Unternehmen über zertifizierte Projektleiter verfügt, die auch aktiv von Kunden nachgefragt werden.

IT Projekt und Portfolio-Management, Folge 1 Einführung und praktische Erfahrungen

2012-02-01T16:07:00Z

Da gerade in den letzten Jahren das „IT Projekt & Portfolio-Management“ (kurz IT-PPM) durch die stetige Steigerung der Flexibilität in den einzelnen Organisationseinheiten enorm an Bedeutung gewonnen und mittlerweile ein festes Kerngebiet bei der Steuerung einer Multi-Projektorganisation bildet, wollen wir Ihnen mit unserer Blog-Reihe die theoretischen Ansätze des IT-PPMs näher bringen und Ihnen einen Einblick in unsere praktischen Erfahrungen in diesem Themenumfeld aufzeigen. Die Reihe wird aus mehreren Folgen bestehen und in unserem Blog bereitgestellt. Unter anderem sind bis dato folgende Themen geplant:

Folge 1: Einführung und praktische Erfahrungen
Folge 2: Einblicke in die breite Softwarelandschaft
Folge 3: Vertiefung mit Hilfe eines ausgewählten Softwareprodukts

Was versteht man unter „IT Projekt & Portfolio-Management“?

Ein Projektportfolio wird durch die Gesamtheit aller alleinstehenden und zu Programmen zusammengefasster Projekte einer strategischen Geschäftseinheit gebildet. Durch die ständige Neupriorisierung, den Abschluss bzw. das Verwerfen von Projekten und Programmen und den strategischen Änderungen eines Unternehmens unterliegen die Projektportfolios einer ständigen Veränderung. Dabei steuert und kontrolliert das IT Projekt & Portfolio-Management innerhalb eines projektorientierten Unternehmens alle Projekte und Programme und stellt sicher, dass Unternehmen zum richtigen Zeitpunkt mit den geeignetsten Ressourcen und finanziellen Mitteln die relevanten Programme und Projekte durchführt.

Aus langjähriger Erfahrung bei diversen Kunden kristallisierten sich bestimmte Kernaufgaben heraus, die das IT-PPM charakterisieren und vom Projekt- bzw. Programmmanagement abgrenzen:

Abb.1: Charakteristische Kernaufgaben des IT-PPM - Quelle: © it-economics GmbH

Im Gegensatz zum Programmmanagement fokussiert sich das IT-PPM auf die Prioritäten und Ziele des Unternehmens die vorhandenen Ressourcen sinnvoll und gezielt einsetzen zu können. Die Umsetzung und operative Kontrolle der jeweiligen Projekte erfolgt im Programm- bzw. Projektmanagement.

Wie funktioniert „IT Projekt & Portfolio-Management“?

Der Prozess des IT Projekt & Portfolio-Managements setzt sich aus drei Phasen zusammen:

Abb.2: Die drei Phasen des IT-PPM - Quelle: © it-economics GmbH

1. Initiierungsphase

In der Initiierungsphase werden geeignete Projektvorhaben erstmalig fachlich genauer beleuchtet und mit einer ersten groben Aufwandsschätzung versehen. Thematisch zusammenhängende Projektvorhaben werden zu geeigneten Projekten zusammengefasst um beurteilungsfähige Projektanträge erstellen zu können.

Gerade in dieser Phase werden die Weichen für den Erfolg des geplanten Portfolios gestellt. Aus eigenen Erfahrungen lassen sich in dieser Phase oftmals bereits Über- bzw. Unterplanungen gezielt aufdecken und können auf Grund des frühen Zeitpunkts noch relativ leicht ausgeglichen werden. Es ist wichtig in dieser Phase bereits das Angebot (Unternehmensressourcen) und die Nachfrage (Anforderungen) im Auge zu behalten um im späteren Verlauf auf keine unerwarteten Situationen ad hoc reagieren zu müssen. Umso feiner die Granularität bereits ist, desto leichter lassen sich die gewünschten Unternehmensziele verfolgen und die verfügbaren Ressourcen beplanen und später auf die einzelnen Projekte aufteilen. Oftmals wird in dieser Phase jedoch nicht dediziert genug auf die verfügbaren Ressourcen geachtet wodurch im weiteren Verlauf Planungsenpässe auftreten und das Portfolio in Schieflage geraten kann.

2. Planungsphase

Während der Planungsphase werden anhand von vorgegebenen Priorisierungen und Auswahlkriterien des Unternehmens die gestellten Projektanträge genauer bewertet und mit dem notwendigen Budget und den damit verbundenen Ressourcen versorgt. Im Anschluss werden die selektierten Projektvorhaben in eine ganzheitliche Projektportfolioplanung mit den bereits laufenden Projekten zusammengefasst. Dieser Auswahlprozess ist ein ständig wiederkehrender Prozess. Abschließend wird das zusammengestellte Projektportfolio freigegeben.

Dabei ist in dieser Phase wichtig, den Blick nicht nur auf die geplanten Projektvorhaben zu richten sondern die bereits laufenden Projekte im Auge zu behalten. Denn Ressourcen, die bereits in den laufenden Projekten verplant sind, können für die folgenden Projektvorhaben ggf. nicht wie gewünscht eingesetzt werden. Gerade in Shared Service Unternehmen, in denen die Planungs- und Steuerungseinheiten sowie die liefernden Einheiten getrennt und eigenständig agieren, wird oft der Fehler gemacht, nur in einzelnen Bereichen statt ganzheitlich übergreifend die Umsetzungsmöglichkeiten zu beachten. Dadurch kann oftmals das Projektportfolio nur in einzelnen Shared Service Einheiten umgesetzt werden, in anderen aber nicht mit den benötigten Mitarbeitern besetzt werden. Die Folge sind immer wieder kehrende Repriorisierungsrunden. Es ist aus diesem Grund essentiell wichtig, dass die planungsverantwortliche Einheit entweder vollständige Transparenz über alle Ressourcen hat. Alternativ kann auch dezentraler Prozess aufgesetzt werden, bei dem die Shared Service Einheiten Umsetzungszusagen machen. So oder so - eine enge Verzahnung der Bereiche ist in der Planungsphase wie auch in der darauf folgenden Umsetzungsphase der Grundstein für ein erfolgreiches Portfolio.

3. Controllingphase

Im Gegensatz zu der Initiierungs- und Planungsphase, die sequenziell ablaufen, wird in der Controllingphase permanent das aktuell freigegebene Projektportfolio überwacht und darauf geachtet, dass die Unternehmensziele in den Bereichen Leistungsumfang, Qualität, Kosten, Ressourcen und Zeit (SQERT) eingehalten werden. Im Falle von Auffälligkeiten werden die Risiken bewertet und entschieden wie diese Problemfälle am besten gelöst werden können.

In den meisten Unternehmen wird schon zur Jahresmitte damit begonnen, für das Folgejahr eine Jahresplanung aufzusetzen, in der das geplante Projektportfolio erstellt wird. Da aber während eines Geschäftsjahres, zum Beispiel auf Grund von gesetzlichen Anpassungen, immer wieder ad hoc in das definierte Projektportfolio eingegriffen werden muss, ist ein genaues Controlling der aktuell abzuwickelnden Projekte zwingend erforderlich, da nur so Budget-, Ressourcen- oder Terminkonflikte schnell und effizient entdeckt und eskaliert werden können. Gerade durch ein ständiges und effizientes Reporting der aktuellen Begebenheiten können die diversen Organisationseinheiten sich einen übergreifenden Blick über den aktuellen Fortschritt des Portfolios und der darin enthaltenen Projekte machen und schnell und effizient auf ggf. auftretende Abweichungen aus dem strategischen Unternehmenszielen eingreifen. Auch hier ist, wie in der Planungsphase, eine Verzahnung der einzelnen Bereiche notwendig um ein aussagekräftiges und ganzheitliches Bild zu erhalten. Insbesondere dann, wenn keine Shared Service übergreifende Projektleitung installiert ist.

Welches Ziel verfolgt „IT Projekt & Portfolio-Management“?

Ziel des IT Projekt & Portfolio-Managements ist durch eine dauerhafte Planung, Beurteilung, Priorisierung, Steuerung und Überwachung die Unternehmensinvestitionen in den Projekten gezielt zu optimieren. Dabei ist darauf zu achten, dass die Prozesse ständig gelebt werden um eine ganzheitliche, aussagekräftige und valide Planungsgrundlage zu erhalten. Um dies zu erreichen, sollte sich das Unternehmen immer wieder folgende Kernfragen vor Augen halten:

Verfolgen wir mit unserem Portfolio die angestrebte Unternehmensstrategie?
Besteht unser Portfolio aus der richtigen Zusammensetzung zwischen kurz-, mittel- und langfristigen Erfolgsmöglichkeiten?
Sind die eingegangenen Risiken bekannt und welche Auswirkungen haben diese?

Neben den unternehmensweiten Fragen sollte auch auf Ebene des Projektportfolios genau analysiert werden, ob der richtige Weg eingeschlagen wurde. Dabei helfen folgende Fragen:

Wie stabil ist unser Portfolio in Anbetracht auf den Fortschritt der darin enthaltenen Projekte?
Wurde das Portfolio richtig geschnitten und liefert es den erwarteten Nutzen?
Können noch weitere Projekte umgesetzt werden ohne das gesamte Portfolio zu gefährden?
Wie entwickeln sich die Aufwände und Kosten der einzelnen Projekte innerhalb unseres Portfolios?
Sollten Konflikte auftreten, welche Projekte innerhalb des Portfolios sollen priorisiert werden?

Fragen zum Unternehmen und unserem Portfolio sind nun gestellt, aber was ist mit unseren Mitarbeitern? Auf folgende Fragen sollte man hier jedenfalls Antworten haben:

Sind unsere Mitarbeiter richtig für die angestrebten Projekte qualifiziert?
Können wir mit unserer Belegschaft das definierte Portfolio stemmen, decken sich Angebot und Nachfrage?
Wie werden die einzelnen Mitarbeiter auf die jeweiligen Projekte verteilt?

Hat man all diese Themengebiete und Fragen im Blick, sollte man abschließend die Aussagekräftigkeit und Ergebnisse genausten analysieren, um den erhofften Nutzen aus den Antworten ziehen zu können.

Im zweiten Teil dieser Blogserie werden wir Ihnen im März anhand von renommierten Marktforschungsunternehmen einen Einblick in den weitläufigen Markt kleiner wie auch namhafter Softwarehersteller bieten und Ihnen aufzeigen, wie das Zusammenspiel zwischen der reinen Theorie und den Tools gemeistert werden kann und welche Herausforderungen es dabei zu bewältigen gilt.

Anbindung von Bankenperipheriegeräten in virtuellen Umgebungen

2012-01-20T19:41:00Z

Mehrwert einer Virtualisierung

Die Schlagworte „Virtualisierung“ und „Cloud“ sind derzeit im Bereich IT-Architektur oft zu hören und „ohne“ scheint es keinen Weg in die Zukunft zu geben.
Inhaltlich verbirgt sich dahinter die Verlagerung des Betriebs von Software und Rechenleistung in entfernte Systeme. Eine Konzentration von Leistungen im Rechenzentrum (RZ) bietet eine ganze Reihe von Vorteilen, denen wir uns nicht entziehen können. Allem voran sind hier die Einsparpotentiale durch Vereinheitlichung der Prozesse sowie die Zusammenlegung und bessere Ausnutzung von Rechenleistung zu nennen. Die Anwendungen werden zentral verwaltet und die Komplexität sowie Kosten der IT reduziert. Der Auslastungsgrad der Hardware kann zudem gezielt erhöht werden.

Virtualisierung von Bankenperipheriegeräten

Aber was verbirgt sich genau hinter der Virtualisierung und was bedeutet dies für ein so komplexes Umfeld wie das einer Bankfiliale? Hier steht nicht nur die Arbeit mit einer Anwendung im Mittelpunkt, sondern das Tagesgeschäft eines Bankmitarbeiters mit Ein- und Auszahlungen über Kassentresore.
Aber fangen wir vorne am Arbeitsplatz an und schauen uns zunächst nur die Virtualisierung des Clients an:
Grundsätzlich ist Client-Virtualisierung ein Verfahren, um Benutzern gleichzeitig und unabhängig voneinander die Ausführung von Anwendungsprogrammen auf einem entfernten Server zu ermöglichen.
Bei der Betrachtung der Bank verschieben wir also den Betrieb unserer Bankanwendung vom Filial-Client ins Rechenzentrum. Der Client verliert damit seine eigentliche Aufgabe und muss zukünftig nur noch das Bild der Anwendung aus dem Rechenzentrum anzeigen – im Grunde die Funktionalität eines Fernsehers. Wir brauchen somit keinen Fat-Client mit eigener Anwendungssoftware, sondern nur noch einen Thin-Client mit geringer Softwareausstattung.
Das Rechenzentrum bietet uns die Software als Service. Dies kennen wir in ähnlicher Form vom „Office 365“ von Microsoft, das uns z.B. Word und Excel in der „Cloud“ anbietet. Auch hier wird uns die Anwendung auf einem (bzw. mehreren) entfernten Servern angeboten.
Die Virtualisierung von Anwendungen gehört in den IT-Projekten inzwischen zu den gängigen Aufgaben und es gibt auch schon viele Erfahrungen in dem Bereich. Bei einem kompletten Schalter-Kasse-Betrieb in der Bank, müssen wir aber unsere Peripheriegeräte in der Filiale aus dem Rechenzentrum heraus ansteuern, da dort unsere Anwendungen laufen.

Die folgende Skizze soll dies veranschaulichen:

Problemfelder bei der Bankenperipherie

Hier stehen wir nun vor einigen Problemen:

Aus dem Rechenzentrum heraus kommunizieren wir via TCP/IP, die Kassentresore z.B. werden aber – von den neuesten Modellen abgesehen – über eine serielle Schnittstelle angesprochen.
Es muss sichergestellt werden, dass wir mit dem richtigen Kassentresor in der Bankfiliale kommunizieren. Sowohl Rechenzentrum als auch Peripheriegerät in der Bank müssen sich authentifizieren.
Die Kommunikation zwischen Rechenzentrum (RZ) und Bank muss verschlüsselt sein.

Da die Verbindung zwischen RZ und Peripheriegerät in der Filiale das grundlegendste Problem darstellt, fokussieren wir uns zunächst auf den ersten Punkt.

Lösungsansätze

Betrachten wir die Kommunikation in Rechnernetzen vom ISO-OSI-Modell ausgehend, bieten uns die unterschiedlichen Schichten verschiedene Ansatzpunkte, um eine Kommunikation zwischen RZ-Server und Bankperipherie zu etablieren. Von der Bitübertragungs- bis zur Anwendungsschicht können wir theoretisch auf jeder Schicht aufsetzen. Die Lösungsmöglichkeiten sind vielfältig, da es für jede Schicht auch wiederum verschiedene Protokolle gibt. Des Weiteren können wir uns für ein Kaufprodukt oder eine Eigenbaulösung entscheiden. Eine Liste aller Lösungsansätze würde recht lang werden und jeden Ansatz zu verproben, wäre sicher zu aufwendig.
Es sollten daher zunächst grundsätzliche Entscheidungen getroffen werden, z.B. Aufsetzen auf der Applikationsschicht oder eher Bitübertragungsschicht oder ob wir ein Kaufprodukt oder eher eine Eigenbaulösung einsetzen wollen.

Beim Eigenbau einer solchen Lösung hätten wir auf der einen Seite eine sehr hohe Flexibilität und könnten das Produkt exakt auf unsere Wünsche zuschneiden, aber auf der anderen Seite müssten wir alle Anforderungen aus bankfachlicher als auch betriebs- und sicherheits-technischer Sicht selber definieren und implementieren. Neben unseren fachlichen Anforderungen, müssen wir auch Umsetzung, Betrieb, Sicherheit, Support und Weiterentwicklung im Auge behalten. Insbesondere im Betrieb tun sich weit mehr Fragen und Anforderungen auf, als man zunächst vermutet, z.B. Monitoring, Remote Operations, zentrale Logs, Software-Versorgung, Zertifikatsmanagement, Zukunftssicherheit usw. Diese Aufgaben werden zu Beginn eines Projektes gern unterschätzt, da häufig die Fachlichkeit im Fokus steht und weniger der technische Betrieb.
Der Aufwand bei solch umfangreichen Projekten erreicht schnell eine beachtliche Größe und benötigt zusätzlich noch einen verhältnismäßig großen Risikopuffer. Denn in der Regel betritt das Unternehmen bei der Eigenentwicklung Neuland und muss die Erfahrungen, z.B. eines bereits am Markt bestehenden Produktanbieters, erst noch sammeln. Zudem besteht die Gefahr die Architektur nicht variabel genug zu konzipieren, so dass bei einer späteren Integration eines weiteren Softwareprodukts oder einer Hardware-Komponente die gesamte Architektur geändert werden muss.
Der langfristige Support und Betrieb eines solchen Systems wiegt aber ebenfalls schwer. Beim Eigenbau einer Lösung müssten wir im Fehlerfall bis auf die Bit-Schicht herunter um den Fehler zu analysieren, die Zuständigkeit in unserer verteilten Architektur festzustellen und zu beheben.

Im Gegensatz zur Eigenbaulösung steht die Integration eines Kaufproduktes. In unserem Fall der Bankenperipherieanbindung würde diese Software / Appliance in der Bank die TCP/IP-Befehle empfangen und als serielles Signal an die Peripheriegeräte weiterleiten. Bei der Lösung der Betriebsthemen würden die eigenen Anforderungen nur gegen die Möglichkeiten des Produkts gehalten und die Differenzen wären vom Anbieter aufzuarbeiten. Es wäre sicherlich sinnvoll sich von dem Kaufprodukt klar abzugrenzen und es nur als „Blackbox“ zu sehen. Es soll auf der einen Seite unsere fachlichen Vorgaben umsetzen und sich betriebstechnisch integrieren können, aber auf der anderen Seite die Verantwortlichkeit beim Hersteller belassen – „das Produkt muss einfach funktionieren“.
Die Kosten beim Kauf eines Kaufproduktes sind sicher nicht unwesentlich, bieten uns aber ein höheres Maß an Kostensicherheit als der komplette Eigenbau. Auch würde sich der Betrieb und Support deutlich vereinfachen, da uns die verschlüsselte TCP/IP-Kommunikation nicht vor große Anforderungen stellt und die technische Ansteuerung der Peripheriegeräte dann beim Produkt liegt. Es böte sich sogar die Möglichkeit dem Kaufprodukt die fachlichen Funktionen vollständig zu überlassen. Am Beispiel einer Auszahlung könnte dies bedeuten, dass wir nur den Befehl „Auszahlung 100€ / Stückelungskennzeichen 1“ senden und alle weiteren technischen Aufgaben der Kaufsoftware im Sinne einer „Blackbox“ überlassen. Bei einem automatischen Kassentresor (AKT) wären dies unter anderem das Sperren des AKTs für die Transaktion, die Auswahl der Geldrollen (Kassetten) zur Auszahlung, die Auszahlung selbst und die abschließende Freigabe des AKTs.

Alles komplett selber zu steuern und zu entwickeln, gibt einem (fast) immer ein gutes Gefühl, man sollte aber die Risiken bei einem Eigenbau im Auge behalten. Wir haben im Falle der Anbindung der Bankenperipherie den Kauf eines Produktes empfohlen und in die Systemarchitektur des Kunden integriert. Damit haben wir die Kontrolle über die grundsätzliche Architektur und die Schnittstellen behalten und den Hersteller der Blackbox in einer zentralen Komponente unserer Architektur in die Verantwortung genommen.

Unsere Lösung

So könnte vereinfacht eine Lösung zur Virtualisierung von Bankenperipheriegeräten aussehen:

Virtualisierung von Bankenarbeitsplätzen wird spätestens mit der Anbindung der Peripheriegräte zu einer echten Herausforderung. Die Kommunikation aus dem Rechenzentrum in die Filiale hinein kann auf unterschiedlichste Weisen gelöst werden.
Wir haben auf den Bau einer kompletten Eigenlösung verzichtet und stattdessen ein Kaufprodukt empfohlen mit entsprechender Aufgaben- und Verantwortungsverteilung. Wir profitieren dabei nicht nur durch das Produkt des Herstellers, sondern partizipieren auch von dessen Erfahrung bei anderen Geldhäusern. Zudem werden Aufwand und Risiko deutlich minimiert.

Workflow Engines – Das Mittel gegen unflexible und teure Geschäftsprozesse

2012-01-16T20:10:00Z

Vor Ferien oder Brückentagen muss der Urlaub noch beantragt werden. Denn bevor man seine freien Tage genießen kann, sind viele organisatorische Schritte notwendig: Der Vorgesetzte muss dem Antrag zustimmen, die Personalabteilung muss informiert werden, ein Stellvertreter muss gefunden und in die Abwesenheitsnotiz im Outlook eingetragen werden. Ziemlich viele Aufgaben. Da kann es schon mal passieren, dass man etwas vergisst. Aber es wäre ärgerlich, wenn wegen einer Unachtsamkeit der Urlaub ins Wasser fiele.

Um dem entgegenzuwirken setzen viele Unternehmen IT-Systeme ein, die den Arbeitnehmern bei der Ausführung des „Urlaubsprozesses“ helfen sollen. Diese Software ist allerdings oft unflexibel und muss bei Änderungen am Prozess mühsam angepasst werden.

Was können Workflow Management Systeme was andere nicht können?

Die kontinuierliche Verbesserung von Geschäftsprozessen ist nach Gartner eine der Top-4-Einsatzszenarien für Business Process Management Systeme (BPMS). Business Process Management Systeme oder Workflow Management Systeme (WFMS), wie der Oberbegriff lautet, dienen hierbei als gemeinsame Anlaufstelle für alle Geschäftsprozesse. Ziel dieser Software ist es, Änderungen an Prozessen nicht zu implementieren, sondern zu modellieren. WFMS bilden dabei das Bindeglied zwischen dem Management und der IT-Abteilung einer Firma. Der Workflow, der letztendlich zur erfolgreichen Beantragung eines Urlaubs führt, wird dabei nach dem Baukastenprinzip in einzelne Aufgaben unterteilt. Die Aufgaben stellen vorgefertigte Bausteine dar, die von der IT-Abteilung bereitgestellt und vom Management zu einem Geschäftsprozess zusammengefügt werden. Wenn man unser Beispiel in eine Prozesssprache übersetzt und in einzelne Aufgaben aufteilt, könnte das wie folgt aussehen:

Abbildung 1: Exemplarischer Workflow zur Beantragung von Urlaubstagen

Wie mancher vielleicht bemerkt, ist dieser Prozess nicht perfekt und kann verbessert werden. Das WFMS bietet die nötige Flexibilität, um Änderungen am Prozess einfach zu modellieren und kann so auf fast alle erdenklichen Situationen reagieren. Da alle Schritte vom System überwacht werden, können auch keine Aufgaben vergessen werden. Das gewährleistet eine kurze Bearbeitungszeit. Workflow Engines helfen dadurch sogar die Kosten für einen Geschäftsprozess zu senken. WFMS eigenen sich nicht nur für die Verbesserung von Prozessen, sondern auch für firmenspezifische Prozesslösungen eines Problems oder für das service-orientierte Re-Design einer bestehenden Anwendung. Sie kommen besonders bei regelbasierten oder entscheidungsintensiven Prozessen zum Einsatz und eignen sich so z.B. für die Einführung neuer Produkte im Kreditgeschäft von Banken. Die Vorteile von WFMS liegen auf der Hand und auch Gartner hat im Jahr 2006 die Empfehlung zur Einführung solcher Systeme gegeben.

Wie finde ich die „richtige“ Workflow Engine?

Unternehmen, die sich jetzt für den Einsatz einer Workflow Engine entscheiden, stehen vor der schwierigen Aufgabe aus der Vielzahl von Anbietern das richtige Produkt zu finden. Es gibt weit mehr als 100 verschiedene Systeme mit unterschiedlichen Stärken und Schwächen. Nicht einmal Gartner lässt sich zu einer Aussage über die Anzahl aller Workflow Engines bewegen, sondern gibt nur einen kleinen Einblick über die Marktführer, solche die es werden wollen, und die Nischenprodukte.

Abhandlungen, wie man die richtige Software für seine Zwecke findet, gibt es viele. Eine haben wir bereits in unserem Blog vorgestellt [Vendor Selection Process].

Bei WFMS sollte man vor allem darauf achten, welche Art von Workflow Engine benötigt wird. Man unterscheidet hierbei zwischen integration-centric, human-centric, document-centric und system-centric WFMS:

Wenn man Probleme hat die Anforderungen des neuen Systems zu definieren, sollte man sich Gedanken über den Fokus der neuen Anwendung machen. Man sollte sich z.B. folgende Fragen stellen:

Welchen wirtschaftlichen Triebfaktoren unterliegt mein Unternehmen?
Welche Unternehmensstrategie habe ich?
Was sind die Ziele, Schwächen und Möglichkeiten meiner Firma?
Welche Risiken gibt es?

Für den erfolgreichen Einsatz und eine große Akzeptanz der Workflow Engine ist es außerdem wichtig zu wissen, wer die Stakeholder der neuen Technologie sind und wer in deren Konkurrenz tritt. Meist wird man in den betroffenen Organisationseinheiten des Unternehmens sehr schnell fündig. Um nach der Einführung eines WFMS das neue System zu rechtfertigen und seinen positiven Nutzen herauszustellen, sollte man die Key Performance Indicators auf die neue eingesetzte Software anwenden.

Workflow Engines – Das Non plus Ultra der Prozessoptimierung?

Die Vorteile, die ein WFMS verspricht, sind viel versprechend. Alles soll besser, schneller, flexibler und günstiger werden. Die Möglichkeit eines up-to-the-minute Reportings ist für jeden Manager ein Traum. Workflow Engines bergen aber auch Gefahren, besonders wenn die Nutzer die neue Technologie nicht akzeptieren und eher als Überwachungsorgan des Managements empfinden. Die stetige Verbesserung und Neueinführung von Prozessen kann zu Overmanagement führen und das Unternehmen unflexibler machen. Es ist, wie so oft, nötig einen gesunden Mittelweg zu finden, um Workflow Engines erfolgreich einzusetzen.

Quellen:

http://www.bpminstitute.org/articles/article/article/what-is-scope.html

http://www.progress.com/docs/whitepapers/gated/savvion/understing_usage_patterns-wp.pdf

http://www.gartner.com/technology/media-products/reprints/oracle/article161/article161.html

Effektives und effizientes Selbstmanagement, Teil 1 Grundlagen

2012-01-02T20:51:00Z

Wer kennt sie nicht diese Situation: Man sitzt in einem Restaurant, hat dem Kellner seine Bestellung klar und deutlich mitgeteilt – Ein Bier, einen gemischten Salat und danach eine Pizza Salami. Die Kollegen hatten ebenso bestellt. Der Kellner geht, und die Bestellung wird wie gewünscht ausgeliefert – oder? Das wird nur klappen, wenn wir es mit einem robust organisierten Betrieb(sprozess) zu tun haben, in dem jeder Mitarbeiter in der Wertschöpfungskette seine Arbeitsaufgaben zuverlässig erledigt. Notiert z.B. der Kellner nicht alles präzise, wird die Küche etwas anderes ausliefern, als der Kunde gewünscht hat. Und wenn das häufiger passiert, verliert der Kellner seinen Job.

Das ist ein Beispiel aus der Gastronomie. In Branchen wie der unsrigen, in denen Wissensarbeiter tätig sind, verhält es sich nicht anders. Zwar sind unsere Arbeitsschritte und Aufgabenbereiche komplexer und weniger klar umrissen als im obigen Beispiel. Die Erwartungshaltung der bestellenden Kollegen / Kunden gegenüber dem Wissensarbeiter entspricht jedoch der oben genannten. Man erwartet, dass der Auftrag ausgeführt wird – in Time, in Scope, in Quality und in Budget – egal wie klein oder groß er ist.

Nun ist das Problem, dass wir im täglichen Arbeits- und Privatleben nicht nur eine sondern sehr viele „Bestellungen“, d.h. Aufgaben haben. Sie prasseln täglich -gefühlt unendlich- häufig auf uns ein: E-Mails, SMS, Voicemails, Chats, Anrufe, Meetings, Statusprotokolle, usw., usw. Und so stehen wir – täglich – vor der Herausforderung, das alles zu verwalten und priorisiert abzuarbeiten. Doch vielen von uns – und das ist tatsächlich verblüffend – fehlt ein klares Konzept, wie damit umzugehen ist.
Die umfangreiche Literatur zum Thema Selbstmanagement bietet grundsätzlich zwei Ansätze, wie das Problem angegangen werden kann: „Top down“ oder „Bottom up“.

Bekanntester Vertreter des erstgenannten Ansatzes ist Steven Covey. Er entwickelte das Konzept der Uhr und des Kompasses [Covey, S., First Things First, London 1994]. Der Kompass steht für die großen Ziele, die individuelle Himmelsrichtung nach der sich der einzelne ausrichten möchte. Ist diese bestimmt gilt es, alle (täglichen) Arbeiten daran auszurichten, durch entsprechend sinnvolle Planung und Priorisierung:

Abb.1: Top Down Planung auf basierend auf Steven Covey - Quelle: © it-economics GmbH

Auch Lothar Seiwert vertritt den Top Down Ansatz in ähnlicher Form. Er schlägt in seinem Buch „Wenn Du es eilig hast, gehe langsam“ auch konkrete Schritte zur Umsetzung vor:

Abb.2: Top Down Planung auf basierend auf Lothar Seiwert - Quelle: © it-economics GmbH

So logisch und schlüssig diese Konzept erscheinen, so schwierig ist (zumindest für mich persönlich) die Operationalisierung. In einer Welt, in der kaum vorhersagbar ist, was die nächsten 3-5 Jahre passieren wird, konnte ich zwar mein persönliches Leitbild erarbeiten. Aber auf dieses hinzuarbeiten, indem ich Jahresziele und Wochenplanungen erstelle, erschien mir schwierig. Täglich änderten sich Aufgaben und Prioritäten und die wirkliche Herausforderung für mich war, diese sauber zu managen. Also schaute ich mich nach anderen Konzepten um.

In David Allens „Getting Things Done (GTD)“ fand ich einen Ansatz, der sich (zunächst) um das Management der täglichen Herausforderung kümmert. All das Zeug, das einem im Kopf herumschwirrt, soll geordnet abgearbeitet werden können. Er entwirft ein robustes System, in dem nichts mehr verloren gehen kann. Denn: Wenn man nicht all des Zeugs Herr wird, braucht / kann man sich auch keine Gedanken über die großen Ziele machen. Man hat den Kopf einfach nicht frei dafür.

Abb.3: Alles Zeug raus aus dem Kopf und rein in den Eingangskorb

Ist erst mal alles im Eingangskorb erfasst, geht es darum, diesen abzuarbeiten. Das Konzept ist aktionsorientiert. Das bedeutet, man soll sich fragen, was als nächstes genau zu tun ist. Kann man mit der E-Mail, dem Brief, Zettel, etc. nichts tun, dann wandert es entweder in den Müll oder in eine Wiedervorlage oder beim Referenzmaterial.
Kann etwas getan werden und sind mehrere Schritte nötig, um das ToDo zu erledigen, wird ein Projekt dafür angelegt. Ist es nur ein Schritt, und dauert dieser weniger als 2 Minuten (nur dann!), wird das ToDo sofort erledigt. Ein Tipp: Man sollte die Zeit stoppen. Es ist überraschend, wie sehr man sich hier verschätzt! Dauert die Erledigung mehr als 2 Minuten, dann ist zu prüfen, ob man es delegieren kann. Nach dem Übertragen der Aufgabe, landet das ToDo in einem Ordner „Warten auf“.
Muss man es selbst erledigen, so packt man das ToDo entweder in den Terminkalender (wenn es zu einem bestimmten Zeitpunkt erledigt sein muss) oder man legt es in einen Ordner „nächste Schritte (so bald als möglich).

Und so arbeitet man sich für jedes ToDo durch den Eingangskorb:

Quelle: Wikipedia

Im Ergebnis hat man nun alles kategorisiert und in Ordner verteilt. David Allen schlägt diverse Gruppierungsmöglichkeiten vor, aus denen man sich eine geeignete aussuchen kann.

All diese Organisationsarbeit bringt allerdings nichts, wenn man das System nicht am Leben hält. Man muss sich also – wie beim Zähneputzen – dazu zwingen, das alles regelmäßig durchzusehen und aktuell zu halten. Und das war für mich die Achillesferse des Konzepts. Man hat es nämlich schnell mit mehr als 10-20 Listen zu tun (vgl. Punkt 3 „Organisieren“ – „Grundkategorien“):

Quelle: Wikipedia

„Zeug“ kann in elektronischer Form und in papierhafter Form vorliegen. Entsprechend sind die verschiedenen Listen und Kategorien auch nicht auf Papier bzw. E-Mails beschränkt. So multiplizieren sich die Aufwände zum Durchsehen entsprechend. Das System lähmt dann eher, und ich hatte das Gefühl, dass ich mehr Zeit mit Kategorisieren und Durchsehen verbrachte, als mit dem Abarbeiten der Aufgaben.
Und so entwarf ich mein eigenes System, über das ich im nächsten Blog berichten werde…

Kanban in der Wartung

2011-12-16T09:09:00Z

Das Jahr neigt sich dem Ende zu. Die Weihnachtsfesttage haben begonnen und viele freuen sich auf besinnliche Stunden mit der Familie. Insbesondere für Entwicklungsteams eine Zeit, in der die Möglichkeit besteht, zur Ruhe zu kommen und die vielen Aufgaben zu vergessen. Der tägliche Terminstress, kommt im nächsten Jahr bestimmt wieder.
Doch das muss nicht sein und ich möchte diesen Blog nutzen, einen Entwicklungsansatz vorzustellen, der überlasteten Teams die Ruhe und damit auch eine erhöhte Teamleistungsfähigkeit zurückbringen kann.

Kanban – Warum noch ein Agiler Ansatz?

In einem Wartungs-/Entwicklungsprojekt kommt man oft an einen Punkt, an dem sich die ursprünglichen Aufgaben verändern und mehr Verantwortung auf das Team zukommt, als man zu Beginn erwarten konnte. Speziell in Wartungsteams, können neben dem Tagesgeschäft auch weitere Themengebiete dazukommen.

In meinem aktuellen Projekt, stehen wir vor einer solchen Herausforderung:

Es gibt mehrere Produktbestandteile die in der Wartung betreut werden
Probleme im Systemumfeld führen zu Analyseaufwand, obwohl die Fehlerbehebung von einem anderen Team geleistet wird
Für alle Bestandteile gibt es in regelmäßigen Abständen Erweiterungswünsche
Es wurde eine komplette Neuentwicklung übernommen, die bis zur produktiven Einführung begleitet wurde, jetzt steht die Übernahme der Wartungsaufgabe an

All diese Aufgaben müssen durch das Team parallel bearbeitet werden und es muss immer die Möglichkeit bestehen, besonders kritische Probleme sofort bearbeiten zu können. Jedes Teammitglied arbeitet also an vielen Dingen gleichzeitig, ohne dass nach außen eine Transparenz bestand, welche Themen da sind.

Um dies transparenter, sowohl für das Team als auch für Außenstehende zu gestalten, überdachten wir unser Vorgehensmodell und stießen mit Kanban auf eine Methodik, die uns am Besten für das breit gefächerte Aufgabengebiet geeignet erschien.
Methoden, die spontane Änderungen ausschließen und eine komplette Umstellung der etablierten Vorgehensweisen erfordern, kamen für uns nicht in Frage. Insbesondere, da in einem Kundenprojekt der Kunde den Takt und die Randparameter vorgibt. In einem solchen Umfeld muss man sich in einen großen Prozess einfügen und gleichzeitig für das eigene Team den effektivsten Weg wählen.

Kanban – Ein paar Hintergrundinformationen

Der Begriff Kanban (Kan ban = japanisch für Signalkarte) wird oft zusammen mit dem Kaizen Prozess (Prozess der kontinuierlichen Verbesserung) und der Lean Production bzw. Development („Verschlankungsprozess“) betrachtet, da Kanban insbesondere den Kaizen Prozess in einem Unternehmen fördern kann. Das Ziel ist, den Mitarbeitern die Möglichkeit zu geben, sich selber zu verbessern und gleichzeitig die Zeit, die eine Aufgabe zur Bearbeitung benötigt, zu verringern.

Dabei setzt Kanban auf die etablierten Prozesse in einem Team auf, ohne Änderungen an diesen zu erzwingen. Zentrales Mittel ist die Visualisierung der Arbeitsabläufe, das es ermöglicht, Engpässe zu erkennen, damit diese genauer analysiert werden können. Diese Visualisierung kann elektronisch geschehen, verbreiteter ist jedoch die Verwendung eines sogenannten „Kanban Boards“, auf dem der Durchlauf einer Aufgabe durch das System vom einem Startpunkt bis zu einem definierten Endpunkt erfolgt.
In unserem Fall, nimmt dieses Board zwei große Whitebordwände ein und visualisiert unsere einzelnen Arbeitsschritte:

Abbildung 1: Kanban Board

Die Einführung des Boards war für uns der erste Schritt und für uns auch die größte sicht- und spürbare Änderung. Gerade da Kanban keine Änderungen erzwingt, war die Akzeptanz im Team von Beginn an sehr hoch. Schnell bestätigte sich das, was wir bislang nur vermutet haben: Ein Engpass in der Analyse- und der Testphase.

Wir entschieden uns dafür, Kanban sanft einzuführen, d.h. wir nutzen nicht alle Methoden und Maßnahmen die Kanban für den Kaizenprozess zur Verfügung stellt. Da wir zuerst ein besseres Verständnis für die Auslastung eines jeden Teammitglieds erhalten wollten, verzichteten wir z.B. auf die Limitierung der Aufgabenkarten pro Arbeitsschritt.
Wie sich jedoch schnell zeigte, beschränkt sich der Nutzen von Kanban dann sehr schnell auf die Visualisierung. Eine echte Verbesserung der Arbeitsauslastung der Teammitglieder kann sich so noch nicht einstellen. Aus diesem Grund werden wir jetzt in weiteren Schritten die Möglichkeiten von Kanban weiter ausschöpfen.

Kanban – Mittel und Wege zum Kaizen Prozess

Gerade die Limitierung der Auslastung pro Arbeitsschritt ist ein wichtiger Steuerungshebel, um jedem Teammitglied eine bessere Fokussierung auf die aktuelle Aufgabe zu ermöglichen. Durch dieses Limit, auch Work In Progress (WIP) Limit genannt, wird sichergestellt, dass jeder nur so viele Aufgaben bearbeitet, wir er auch wirklich mit einer hohen Qualität erledigen kann.

Abbildung 2: Kanban Board mit WIP Limits

Ist eine Aufgabe erledigt, steht sie dem nächsten Arbeitsschritt zur Verfügung und wenn sie in diesen verschoben wurde, kann eine neue Aufgabe begonnen werden. Damit entsteht ein sogenanntes „Pull-System“. In diesem, hat jeder Arbeitsschritt einen vorgelagerten Puffer, aus dem er sich bedienen kann. Das ist immer dann zulässig, wenn der WIP die Möglichkeit dazu bietet. Dieser Puffer kann ein Puffer im klassischen Sinne sein (z.B. am Startpunkt), oder eben ein vorgelagerter Arbeitsschritt.

Eine weitere Möglichkeit zur Optimierung der Abläufe, ist die Einführung von Serviceklassen. Damit ermöglicht es Kanban, bei einzelnen Aufgaben eine Priorisierung vorzunehmen. Damit war es uns möglich, die Abarbeitung von Prio1 Tickets vorzusehen, obwohl ein WIP Limit dieses verhindert hätte.

Kanban – Die Lösung?

Zusammenfassend kann man Kanban die Fähigkeit bescheinigen, dass es sich gut auf bestehende Prozesse abbilden lässt. Es erzwingt keine Anpassung, einen echten Gewinn bringt es jedoch erst, wenn man wirklich die (wenigen) „Regeln“ befolgt. Bei deren Einführung gibt Kanban keine Geschwindigkeit vor, sondern ermöglicht eine Eingewöhnungsphase, in der man sich langsam an die für das eigene Team passende Variation heranarbeitet.

In dem Wartungsprojekt, in dem ich gerade arbeite, ist Kanban für die Transparenz unserer Aufgaben sehr hilfreich. Wir haben uns dafür entschieden Kanban erst einmal auszuprobieren und gerade am Anfang hat das Kanban-Board einige Änderungen erfahren. Jetzt steht die Einführung eines WIP Limits an, ein Schritt den wir bislang noch nicht durchgeführt haben. Damit kommen dann auch die Serviceklassen und es wird spannend sein, die Auswirkungen zu beobachten.

IPv6 - Das Internet im Wandel

2011-11-21T20:20:00Z

Als das Internet in den siebziger Jahren ersonnen wurde, hatte niemand damit gerechnet, dass es solch eine überwältigende Popularität erreichen würde. Das einfache IPv4 Protokoll, welches 1981 erfunden wurde, war vollkommen ausreichend. Mit der Verbreitung der PCs und der Entstehung des World Wide Web (WWW) wurde aber schon Mitte der neunziger Jahre klar, dass es früher oder später zu einer Verknappung der IP-Adressen im IPv4 Format kommen würde. Deswegen wurde 1995 das Internet Protocol Next Generation ins Leben gerufen. Dieses Protokoll wurde später in Internet Protocol version 6 oder kurz IPv6 umbenannt. 1998 wurde das Protokoll schließlich standardisiert. Anstatt eine rasante Verbreitung zu finden und schnell das Protokoll IPv4 zu verdrängen, wird es auch heute noch nur sporadisch eingesetzt. Das Abwarten hat nun ein Ende. Seit Februar 2011 gibt es keine freien IPv4 Adressen mehr. Eine Vergrößerung des Adressraums ist nun also nicht mehr eine Option sondern eine Notwendigkeit. Der Blog befasst sich mit dem Aufbau von IPv6, den Gründen für den zögerlichen Einsatz und einem Fazit zum Einsatz von IPv6.

Aufbau der IPv6 Adresse

Das IPv6 Protokoll besitzt einen Adressraum von 2^128 Adressen. Im Gegensatz zu den 2^32, also etwa 4 Milliarden Adressen von IPv4 könnten wir praktisch alles im Universum mit einer eigenen Adresse versehen. Um diese Adresse einigermaßen übersichtlich darzustellen, wurde auf die Dezimalschreibweise von IPv4 verzichtet und die Hexadezimal-Schreibweise eingesetzt.

2a01:4f80:1310:c200:0000:dead:beef:cafe

Gehen wir etwas näher auf den Aufbau der IPv6 Adresse ein. Die Adresse wird zunächst in zwei Teile gespalten. Der erste Teil der Adresse, das sog. Präfix wird vom Provider und von der RIR (Regional Internet Registry) vergeben. Der zweite Teil der Adresse erstellt sich der Rechner selbst. Deswegen heißt dieser Teil auch Interface Identifier. Zur Erstellung des Interface Identifiers kommen wir später zu sprechen. In unserem obigen Beispiel wäre das Präfix also

2a01:4f80:1310:c200/64

Dementsprechend wäre

0000:dead:beef:cafe/64

der Interface Identifier.

Der Provider bekam dabei vom RIR wahrscheinlich

2a01:4f80/32

Der Endkunde bekam möglicherweise

2a01:4f80:1310/48

oder nur

2a01:4f80:1310:c200/56.

Der Rechner muss diesen Teil im Netz erfragen. Dazu schickt er eine Multicast Abfrage, die sich Router Solicitation nennt, ins Netz und wartet auf die Antwort. Die Antwort auf eine Router Solicitation nennt sich Router Advertisement und die Router schicken sie in regelmäßigen Abständen. Der Rechner merkt sich nämlich die nächsten Router und verschickt über sie die Pakete. Falls sich ein Router für längere Zeit nicht meldet, wird er aus der Liste der möglichen Router entfernt.

Hierbei ist es wichtig zu erwähnen, dass IPv6 unbedingt das Internet Control Message Protocol (ICMP) benötigt. Über das ICMP Protokoll werden die Adressen ausgehandelt. Falls die lokale Firewall das ICMP blockt, kann der Rechner keine Adresse erhalten und die Adressvergabe wird scheitern.

Kommen wir nun zum zweiten Teil der Adresse. Normalerweise wird der Interface Identifier mit Hilfe der Hardware Adresse der Netzwerkkarte, auch MAC Adresse genannt, erstellt. Die MAC Adresse hat nur 48 Bit. Deswegen werden die restlichen 16 Bit als ff:fe auch fest vorgegeben. Nachdem die Adresse erstellt wurde, muss nun sichergestellt werden, dass die Adresse nicht schon existiert. Dieses Vorgehen wird auch Neighbour Solicitation genannt. Der vermeintliche Nachbar wird direkt angesprochen, d. h. wir sprechen hierbei von Unicast. Zu diesem Zeitpunkt würde unser Rechner in einem IPv4 Netzwerk einen Broadcast absenden, um den DHCP Server im Netz zu finden. Dadurch senkt sich die Netzwerkbelastung beträchtlich.

Falls die Adresse nun doch vergeben ist, dann vergrößert der Rechner die Adresse einfach um eins und versucht es noch einmal. Im Normalfall heißt das, der Rechner muss irgendwie in das Netz eingesetzt werden. Den Rest erledigt das Netz vollautomatisch.

Dual Stack

Das IPv6 Protokoll hat bisher keine große Verbreitung gefunden. Die Gründe dafür sind verschieden. Zum Teil müssen viele Router und Server umgestellt werden. Weiterhin muss auch die Software IPv6 fähig gemacht werden. Deswegen wurde das Dual Stack erfunden. Dual Stack ist die gleichzeitige Nutzung von IPv4 und IPv6. Ein Rechner bekommt also gleichzeitig eine IPv4 und IPv6 Adresse zugewiesen. Dadurch ist es in der Übergangsphase möglich, den Rechner in beiden Netzen zu betreiben. Der Grund für diese Dual Stack Phase ist, dass das Ende der IPv4 Phase nicht eindeutig definiert ist. Der Übergang soll langsam erfolgen.

Mobile IPv6 und Privacy Extensions

Mobile IPv6

Die IPv6 bringt einige interessante Neuerungen mit. Die erste nennt sich Mobile IPv6 und kann in mobilen Geräten eingesetzt werden. Der Grundgedanke bei diesem Feature ist, dass das mobile Geräte (Notebook, Handy) jederzeit mit seiner lokalen Adresse aufgerufen werden kann. Dadurch kann das Gerät immer gefunden werden, unabhängig davon in welchem Netz es sich zur Zeit befindet.

Wie funktioniert das?
Das Notebook befindet sich im lokalen Netz zu Hause und ist mit seiner eindeutigen 128 Bit IPv6 Adresse erreichbar. Nun geht der Besitzer mit dem Rechner aus dem Haus und zur Arbeit. An der Arbeitsstätte angekommen, wird das Notebook im Arbeitsnetz angesteckt und bekommt eine neue Adresse. Das Notebook meldet jetzt dem sog. Home Agent die neue Adresse und er verbreitet die Information weiter im Netz. Nun weiß jeder Kommunikationspartner, in welchem Netz das Notebook zu finden ist.

Dieses Feature ist nur soweit gegeben, so lange die Firmenfirewall mitspielt. Wenn die Firewall fremde Netze blockt, kann Mobile IPv6 nicht eingesetzt werden.

Privacy Extensions

Ein weiteres Feature sind die Privacy Extensions. Im Gegensatz zu Mobile IPv6 setzt PE auf Privatsphäre. Die Vergabe des Interface Identifiers ist nämlich eindeutig und dadurch kann das Gerät verfolgt werden. Um das zu unterbinden, wird dieser Teil der Adresse zufällig erstellt. Außerdem handelt es sich hierbei um eine zeitlich begrenzte Adresse, die regelmäßig neu erstellt wird. Interessanterweise unterstützen die meisten Betriebssysteme diese Möglichkeit, aber bei einigen ist sie einfach nicht eingeschaltet. Während es bei Serversystemen, wie z. B. Windows Server oder Linux sinnvoll ist, auf diese Möglichkeit zu verzichten, sollten gerade die Betriebssysteme der Smartphones die Privacy Extensions nutzen, um die Nutzer vor Verfolgung zu schützen. Dies ist aber nicht immer gegeben. iOS und Android unterstützen, diese Möglichkeit, aber beim iOS sind Privacy Extensions erst ab der Version 4.3 aktiviert. Beim Android sind sie auch standardmäßig deaktiviert.

Vorteile von IPv6

Die Vorteile von IPv6 sind offensichtlich. Durch die Autokonfiguration ist eine einfache Möglichkeit der Adressvergabe gegeben. Dadurch dass kein NAT benutzt werden muss, werden nicht nur die lokalen, sondern auch die großen Router im Netz deutlich entlastet. Es ist nämlich absehbar, dass die Backbones in der Zukunft immer mehr Arbeit haben werden, weil sie den IPv4 Adressraum mittels NAT künstlich vergrößern müssen. Dadurch wird es immer teurer, die IPv4 Adressen zu nutzen, was hoffentlich den Übergang beschleunigen wird.
Im privaten Rahmen wird es außerdem noch möglich sein, z. B. einen privaten Mailserver einzurichten. Zur Zeit ist das wegen der sich ständig ändernden Adresse nicht möglich. Solche Mailserver werden automatisch auf eine Sperrliste („Blacklist“) gesetzt.

Gefahren von IPv6

Neben den enormen Vorteilen, müssen natürlich auch die Bedenken geäußert werden. Durch die eindeutige Adresse ist eine Verfolgung im Internet möglich. Personalisierte Werbung und Spam könnten die Folge sein.

Eine weitere Gefahr liegt in Mobile IPv6. Wenn man im Netz immer die gleiche Adresse hat, dann können auch die Privacy Extensions hier nur begrenzt helfen.
Das Fehlen von NAT könnte auch als eine Einschränkung der Privatsphäre angesehen werden. Durch NAT war zwar eine Ende-zu-Ende Verbindung nicht möglich. Auf der anderen Seite konnten die Pakete nur bis zum Router verfolgt werden. Weiter war es nicht möglich zu erkennen, welcher Rechner die Anfrage gesendet hat. Ein Ende-zu-Ende Protokoll hätte in diesem Fall also auch Nachteile.

Fazit

IPv6 kommt mit großen Schritten, da IPv4 an seine Grenzen gestoßen ist. Die Betriebssysteme sind dafür bereit. Es kann sein, dass einige Anwendungen in der Entwicklung noch hinterherhinken, aber das ist nicht das größte Problem. Die Änderungen in der Privatsphäre durch Ende-zu-Ende Protokolle, Mobile IPv6, Eindeutigkeit usw. sind die größten Gefahren. Diese müssen zunächst an die Benutzer kommuniziert werden, damit sie dagegen gewappnet sind. Deswegen ist es vielleicht gut, dass wir noch ein paar Jahren warten müssen, bevor das IPv4 komplett abgeschaltet wird.

Weiterführende Quellen:
http://tools.ietf.org/html/rfc4487
http://www.ripe.net/ripe/docs/ripe-512#assignment_size

Legacy Code unter Kontrolle - Folge 3, JMockit für Fortgeschrittene

2011-11-07T12:20:00Z

Im ersten Blog-Eintrag dieser kleinen Serie habe ich erzählt, warum JMockit eine so wichtige Rolle spielt, wenn es darum geht, eine Legacy-Anwendung zu testen. Im nächsten Eintrag habe ich das wichtigste API von JMockit, das Expectations-API vorgestellt. Als Abschluss zeige ich an zwei konkreten Beispielen aus der Praxis, wie JMockit einem auch in schwierigen Fällen einen Unit-Test möglich macht.

Hier nochmal der Überblick über die ganze Serie:
•    Folge 1: Vorstellung von JMockit
•    Folge 2: Die Grundkonzepte von JMockit. Ein erster Test, der ohne JMockit nur schwer zu erstellen wäre.
•   Folge 3: Zwei schwierige Fälle aus der Praxis: Ein Schaltjahresproblem und ein Singleton-Factory-Lindwurm.

Recap: JMockit-Mocks

Das Grundprinzip eines JMockit-Mocks ist das Folgende: Deklariert man mittels der Annotation @Mocked eine Klasse als Mock, so wird ab sofort an keiner Stelle im System mehr der Originalcode ausgeführt. Alle Klassenmethoden sind ebenso gemockt wie alle Konstruktoren und alle Instanzmethoden. Dies gilt für neu erzeugte Instanzen ebenso wie für alle bereits im System existierenden Instanzen! Alle non-void-Methoden geben Standard-Werte wie 0, false, null, etc. zurück.
Nun kann man Expectations formulieren, d.h. Erwartungen, dass das System-Under-Test (SUT) bestimmte Methoden auf einem solchen Mock aufruft. Dies ist wichtig für verhaltensbasierte Tests.

Und man kann mittels NonStrictExpectations vorgeben, dass bestimmte Methoden eines Mocks andere als die Standard-Werte zurückgeben, ohne dass damit eine Erwartung verbunden wäre, dass bzw. in welcher Reihenfolge die Aufrufe erfolgen. Dies wird vor allem eingesetzt, um das SUT aus seiner Umgebung herauszulösen und in einen testbaren Zustand zu versetzen.

Mit dieser Funktionalität kann man nun verblüffende Tests schreiben, die ohne JMockit nur möglich wären, indem man zuerst das zu testende System anpasst – eine Änderung, die in einem Legacy-System ohne ein Sicherheitsnetz aus Unit-Tests recht heikel sein kann.

As Time goes by …

Mein erstes Beispiel ist die Hilfsklasse DateUtility, die unter anderem auch die Zahl der Tage im aktuellen Monat zurückgibt. Zu testen ist nun, ob das auch im Februar eines Schaltjahres korrekt funktioniert. Leider verwendet die Routine lastDayOfMonth() einen direkten Aufruf von new Date() (bzw. inzwischen new GregorianCalendar()), um das aktuelle Datum zu ermitteln. Und die Systemzeit lässt sich von Java aus nicht einfach setzen. Vorgefunden habe ich etwa folgenden Test:

    @Test     public void lastDayOfMonthUsesLeapYear()     {         if (new Date().getMonth() == 1) {             if (DateUtility.isLeapYear()) {                 assertEquals(29, DateUtility.lastDayOfMonth());             }         }     }

Auf meinen Hinweis, dass der Schaltjahrestest aber nur alle 4 Jahre einen Monat lang ausgeführt wird, bekam ich vom Entwickler zur Antwort: „Tja, besser als gar nichts. Anders lässt sich das nicht testen!“

Gemeinsam haben wir dann unter Einsatz von JMockit folgende Tests erarbeitet:

   private static Calendar FEB_01_2012 = new GregorianCalendar(2012, FEBRUARY, 1); private static Calendar FEB_01_2009 = new GregorianCalendar(2009, FEBRUARY, 1);

    @Test     public void leapYearFebruaryHas29Days()     {         modifySystemDate(FEB_01_2012);         assertEquals(29, DateUtility.lastDayOfMonth());     }     @Test     public void nonLeapYearFebruaryHas28Days()     {         modifySystemDate(FEB_01_2009);         assertEquals(28, DateUtility.lastDayOfMonth());     }     private void modifySystemDate(final Calendar newDate)     {         new NonStrictExpectations(System.class) {{             System.currentTimeMillis(); result = newDate.getTimeInMillis();         }};     }

Der Test macht sich zunutze, dass Date und GregorianCalendar intern die Methode System.currentTimeMillis() aufrufen, um die aktuelle Zeit zu bestimmen. In der privaten Hilfsmethode modifySystemDate(…) wird daher die Klasse System teilweise gemockt. Siehe dazu auch im JMockit-Tutorial den Abschnitt „4.14.2 Dynamic partial mocking“:
http://jmockit.googlecode.com/svn/trunk/www/tutorial/BehaviorBasedTesting.html#dynamicPartial

Von Fabriken und Lindwürmern

Ein anderes, in Legacy Code oft zu findendes Konstrukt ist das Factory-Singleton, gerne kombiniert mit einem Getter-Lindwurm. In meinem aktuellen Projekt findet sich z.B. an einer Stelle der Aufruf

File dir = RuntimeFactory.getInstance().getFileSystemUtilities().getUserHomeDirectory();

Hier der relevante Ausschnitt aus dem Code von RuntimeFactory:

public class RuntimeFactory { private static RuntimeFactory instance; public static RuntimeFactory getInstance() { if (instance == null) { instance = new RuntimeFactory(); } return instance; } public FileSystemUtilities getFileSystemUtilities() { if (SystemProperties.getRuntimeInfo().isClient()) { return new ClientFileSystemUtilities(); } else { return new ServerFileSystemUtilities(); } } }

Hier fällt einem als erstes auf, dass man aufgrund des Singleton-Patterns dem SUT nicht einfach eine andere Klasse unterschieben kann. Als zweites erkennt man, dass in getFileSystemUtilities()der Spaß in eine weitere Runde geht. Hier wird ermittelt, ob man sich auf einem Client befindet, und zwar mit Hilfe eines weiteren Factory-Singletons SystemProperties, in das man ebenso wenig eingreifen kann.

JMockit greift uns in einer solchen Situation mit einer besonderen Art von Mocks unter die Arme, sogenannten kaskadierenden Mocks. Sie unterscheiden sich von normalen Mocks nur durch ein leicht verändertes Standardverhalten bei Methoden, die Objekte liefern. Solche Methoden liefern bei einem kaskadierenden Mock nicht null, sondern ebenfalls einen kaskadierenden Mock. Und damit lässt sich nun folgende elegante Lösung stricken:

@Test public void checkDir() { new NonStrictExpectations() { @Cascading RuntimeFactory rf; { RuntimeFactory.getInstance().getFileSystemUtilities().getUserHomeDirectory(); result = new File("E:\\home"); } }; assertEquals("Homedir: E:\\home", new SUT().checkDir()); }

Siehe dazu auch im JMockit-Tutorial den Abschnitt „4.15 Cascading mocks“: http://jmockit.googlecode.com/svn/trunk/www/tutorial/BehaviorBasedTesting.html#cascading

Der Test ist grün, und was nun?

Mit JMockit findet man meiner Erfahrung nach praktisch immer auch in scheinbar untestbarem Code einen Weg, eine Unit aus dem System zu isolieren und einen Test dafür zu schreiben. Das Legacy Code Dilemma „Du musst den Code ändern, um einen Test schreiben zu können. Und du musst einen Test schreiben, um den Code ändern zu können“ lässt sich so durchbrechen.

Was ist also der nächste Schritt? Das Sicherheitsnetz ist gespannt. Nun beginnt die eigentliche Arbeit! Wir ändern in kleinen Schritten den Code, so dass die Klassen und Module auch ohne „JMockit-Magie“ entkoppelt sind. In meinem zweiten Beispiel könnte das Ziel z.B. ein SUT sein, das ein UserHomeDirectory oder wenigstens die FileSystemUtilities per Dependency Injection gesetzt bekommt. Und ja, man kann mit JMockit auch einfach einen Mock für ein Interface erzeugen.

Fazit

Um Legacy Systeme wieder testbar und damit wartbar und erweiterbar zu machen, ist nach wie vor äußerst mühsam und langwierig. Aber JMockit kann Wege öffnen, die vorher versperrt waren, und so Alternativen zu der höchst riskanten und ebenfalls sehr teuren Komplett-Neuentwicklung ermöglichen. Das sollte meine kleine Blog-Serie verdeutlichen.

Und natürlich reicht JMockit alleine nicht aus. Das Refactoring von Legacy-Systemen erfordert von Entwicklern und Architekten eine hohe technische Expertise, oft detailliertes Fachwissen, sowie große Disziplin und ein hohes Qualitätsbewusstsein. Und es verlangt ein kluges Management, das einerseits Verständnis für das schwer greifbare technische Thema hat, aber andererseits den Return-on-Invest nicht aus den Augen verliert. Gerade bei Refactoring-Maßnahmen von Legacy-Systemen ist es wichtig, Fokuspunkte und Prioritäten zu setzen, Ziele zu definieren und Fortschritte sichtbar zu machen.

Lucene und Hibernate Search

2011-10-21T12:19:00Z

Searching oder Retrieving Information ist nach wie vor eine der wichtigsten Anforderungen in der aktuellen Entwicklung von JEE-Anwendungen. Der Content eines JEE-Projekts, bzw. einer Webanwendung wird meistens in relationalen Datenbanken gespeichert. Wie kann der Content suchfähig gemacht werden? Wie kann beim Suchen über große Datenmengen eine effiziente Performanz erreicht werden, wenn es sich hier um komplexe Texte handelt? Verwendet man den traditionellen LIKE oder JOIN Operator im SQL, konzentriert man sich auf SQL Statements und es führt dazu, dass die Persistenzschicht schnell komplex, umständlich in der Entwicklung und schwierig zu warten ist. Auf der anderen Seite ist die Transparenz des Zugriffs der Anwendung auf in der relationale Datenbank gespeicherten Content nicht möglich und es ergibt sich ein Performanceverlust bei großen Datenmengen.

Um diese oben genannten Probleme zu lösen gibt es verschiedene Möglichkeiten. Die meistverwendetste Lösung ist die Kombination von Hibernate, Lucene und Hibernate Search. Um die Transparenz zu ermöglichen wird Hibernate zur Realisierung der Persistenzschicht eingesetzt. Um die Anwendung suchfähig zu machen, werden Lucene zusammen mit Hibernate Search verwendet.

Lucene ist eine von Apache Jakarta Gruppe entwickelte Open Source Bibliothek für Volltextsuche. Lucene wird in Java implementiert und bietet zahlreiche Funktionen für die Abfrage von Informationen aus Textdokumenten an.

Hibernate Search ist ein Open Source Projekt, der Hibernate und Lucene verwendet, um die Volltextsuche über persistente Domänenmodelle anzubieten. Mit Hilfe von Hibernate Search kann Lucene leicht in die Hibernate Schicht integriert werden. Hibernate Search läuft über Lucene und ermöglicht die Indexierung durch Annotation über die Domänenklassen. Ohne den Einsatz von Hibernate Search müssen wir die Synchronisierung von Datenbank und Index übernehmen. Hibernate Search bietet eine explizite API an, um manuelle Indexierung oder Entfernung einer Entität von dem Index aufzurufen. Dies ist sehr hilfreich, wenn Content schon vorhanden aber noch nicht indiziert ist, welcher auf die Volltextsuche-Funktionen aber aufgefordert werden soll.

Um die Integration der Volltextsuche zu realisieren müssen folgende Schritte durchgeführt werden:

Die Domänenmodell-Objekte annotieren
Directory Provider auswählen
Pfad zum Index angeben
Indexierung einschalten
Suchen

Domänenmodell-Objekte nach dem Hinzufügen der Annotation:

Die Domänenmodell-Objekte annotieren

Jedes zu indizierende Domänenobjekt muss mit der @Indexed – Annotation gekennzeichnet werden. Die Id des Objekts wird als IndexID mit @DocumentId annotiert. Diese IndexId muss innerhalb eines Index eindeutig sein. Die Felder Name, Vorname, Geburtsdatum, Strasse, Hausnummer und PLZ werden mit dem Parameter index=Index.TOKENIZED annotiert, damit die Inhalte dieser Felder von dem Tokenizer analysiert werden. Alle Felder werden mit dem Parameter store.NO annotiert. Der Parameter store.NO gibt an, dass die indizierten Inhalte nicht im Index abgespeichert werden.

Hibernate Search bietet auch an, die Beziehung 1:1, 1:n und m:n nachzuvollziehen. In diesem Fall wird in der Adresse person mit der Annotation @IndexedEmbedded annotiert. Dies führt dazu, dass alle in der Person zur Indizierung annotierten Felder auch mit in dem Index Adresse aufgenommen.

Directory Provider und Pfad zum Index angeben

Nachdem alle Domänenmodell-Objekte mit Hibernate Search Annotation bereitgestellt werden, wird das Dateisystem als Directory Provider zur Speicherung von Index angegeben Und anschließend der Pfad zum Index. Das ist das Verzeichnis, in dem sich die Indexe aller Domänenobjekte der Anwendung befinden.

Indexierung einschalten

Es ist möglich, jedes Domänenobjekt oder eine Liste von Domänenobjekten zu indizieren.

Nach dem Indizieren haben wir im Ordner home/phungq/index zwei Verzeichnisse
. luc.bsp.entity.Person
. luc.bsp.entity.Adresse
wobei jedes die Index Dateien enthält

Suchen

Das Suchen fängt mit der Erzeugung der FullTextSession an. Danach wird der MultiFieldQueryParser mit zwei Parametern initialisiert, einem Array, bestehend aus den zu suchenden Feldern, und dem Analyzer. Mit dem MultiFieldQueryParser ist es möglich, mehrere Felder gleichzeitig in eine Suchanfrage zu kombinieren. Dieser Parser ruft die parse Methode mit dem übergegebenem Suchmuster auf. Für das Suchmuster stehen viele Möglichkeiten der Lucene Query Syntax zur Verfügung. Anschließend wird eine Volltextsuche-Anfrage mit Hilfe der createFullTextQuery-Methode erstellt und in Form einer Hibernate-Anfrage zurückgegeben.

Eine Suchmaschine ist eine unverzichtbare Anforderung in der modernen JEE-Anwendung. Sie kann mit Lucene und Hibernate Search leicht in der JEE-Anwendung integriert werden. Ich persönlich finde, dass die Kombination zwischen Lucene und Hibernate Search den Entwicklern eine flexible, leicht zu implementierende und mächtige Lösung für die Volltextsuche anbietet, wenn es sich bei dem Inhalt um umfangreiche Texte handelt.

Das Ziel, des in diesem Blog eingeführten Beispiels ist es zu zeigen, wie bereits in einem frühen Stadium der Implementierung eine einfache Integration der Volltextsuche mit Lucene und Hibernate Search möglich ist. Weitere Informationen sind auf folgenden Webseiten zu erhalten:

Apache Lucene: http://lucene.apache.org/
Hibernate Search: http://www.hibernate.org/subprojects/search.html

Legacy Code unter Kontrolle - Folge 2, Die Grundkonzepte von JMockit

2011-10-10T08:27:00Z

In meinem letzten Blog-Eintrag habe ich erläutert, warum JMockit bei meinem aktuellen Kunden eine so wichtige Rolle spielt, wenn es darum geht, eine Legacy-Anwendung testbar zu machen und so änderbar zu halten.
In der Folge 2 will ich heute darstellen, wie man konkret Unit-Tests mit JMockit schreibt und welche Konzepte dabei eine Rolle spielen. Es entsteht ein Test für eine Stück Legacy Code, das ohne JMockit nur sehr schwer zu testen wäre.

Hier nochmal der Überblick über die ganze Serie:

Folge 1: Vorstellung von JMockit
Folge 2: Die Grundkonzepte von JMockit. Ein erster Test, der ohne JMockit nur sehr schwer zu erstellen wäre.
Folge 3: Zwei schwierige Fälle aus der Praxis: Ein Remote-Service-Call und eine Schaltjahresregelung.

Recap: Die Struktur eines Unit-Tests

Die meisten Unit-Tests folgen einer einfachen Struktur.

Vorbereiten des System-under-Test (SUT).
Aufruf der zu testenden Funktionalität im SUT
Prüfen, ob das erwartete Ergebnis erreicht ist.

Bei jedem der drei Schritte erwarten uns in einem Legacy-System z.T. erhebliche Herausforderungen, die aber oft mit Konzepten von JMockit zu meistern sind.

Schritt 1: Die Vorbereitung des SUT

Beginnen wir mit Schritt 1, der Vorbereitung des SUT. Hier ist als erstes zu klären, woraus das zu testende System aus Sicht des Tests überhaupt besteht. Typischerweise handelt es sich hier um eine einzelne Instanz einer Klasse. Schon die direkten „Collaborators“, die Objekte, auf die zu testende Klasse zugreift, gehören nicht mehr dazu. Sie müssen nur ihre Rolle spielen, damit das SUT wie gewünscht funktionieren kann.

Daraus ergeben sich zwei Herausforderungen:

Erzeugen einer Instanz der zu testenden Klasse
Diese Instanz in eine geeignete Umgebung (Kontext) einbetten, in der die zu testende Funktionalität ausführbar ist.

Nehmen wir als Beispiel wieder unseren hypothetischen InvoiceUpdateRecorder aus der letzten Folge. Er protokolliert neu erstelle Rechnungen und liefert unter anderem einen Report dazu. Diese Report-Erstellung, die in der Methode getInvoiceReport implementiert ist, wollen wir testen. Hier der Code unseres SUT sowie eines Collaborators, der Klasse DbConnection:

public class InvoiceUpdateRecorder { private DbConnection dbConnection; public InvoiceUpdateRecorder() { dbConnection = new DbConnection(); // ... Viele weitere Zeilen unverständliche Initialisierung } public String getInvoiceReport() { String result = ""; // ... Viele Zeilen unverständlicher Code List invoices = dbConnection.fetchAllInvoices(); if (invoices.isEmpty()) { result = "no invoices found"; } else { // Ihr wollt nicht wissen, was hier alles passiert } return result; } } public class DbConnection { Connection jdbcConnection; public DbConnection() { // Holen der JDBC-Connection vom globalen Connection-Manager jdbcConnection = JDBCConnectionManager.currentJdbcConnection(); // weiterer Initialisierungscode } public List fetchAllInvoices() { List result = null; // JDBC-Code, um Liste aus DB zu holen return result; } }

Beginnen wir mit einem besonders einfachen Unit-Test, der prüft, ob als Report „no invoices found“ kommt, wenn die DbConnection keine Invoices liefert. Was ist also unser SUT? Offensichtlich nur die Klasse InvoiceUpdateRecorder, ohne die Klasse DbConnection. Ganz offensichtlich gehört auch nicht JDBC-Connection der DbConnection dazu und schon gar nicht Datenbank selbst mit ihren Inhalten. Beginnen wir also mit dem Schreiben unseres Tests, indem wir das SUT erzeugen:

@Test public void newInvoiceUpdateRecorderHasNoInvoices() { // System-Under-Test vorbereiten. InvoiceUpdateRecorder recorder = new InvoiceUpdateRecorder(); }

Wenn wir diesen Test ausführen, wird uns sofort die (nicht einmal zu unserem SUT gehörende) Klasse JDBCConnectionManager eine eigenartige Fehlermeldung um die Ohren hauen, die besagt, dass sie nicht in einem Zustand ist, dass sie eine JDBC-Connection liefern kann. Aber was tun? Ein Blick in den Konstruktur unseres InvoiceUpdateRecorder zeigt, dass dort hart kodiert eine neue Instanz der Klasse DbConnection erzeugt wird. Und diese wiederum enthält im Konstruktor den fatalen Aufruf eines globalen Singletons, das uns entweder eine gültige JDBC-Connection oder eine Exception liefert. Wenn wir den Code des SUT nicht ändern wollen, scheitert bereits hier unser Versuch, einen Unit-Test zu schreiben. Und wir haben die zu testende Funktionalität noch nicht einmal aufgerufen!

Wie kann uns nun JMockit weiterhelfen?

Das meiner Meinung nach wichtigste Konzept von JMockit ist wird über das sogenannte Expectations API bereitgestellt. Damit kann man bestimmte Typen zu gemockten Typen zu machen. Jeder Referenz-Typ kommt dafür in Frage, also konkrete Klassen (wie DbConnection) und Interfaces (wie z.B. List), aber auch abstrakte oder finale Klassen (wie z.B. java.lang.System), nicht aber primitive Typen wie boolean oder int.

Wenn ein Typ gemockt ist, werden alle Aufrufe aller seiner Methoden abgefangen. Es wird nicht die Originalimplementierung ausgeführt (sofern es eine gibt). Stattdessen tut der Mock einfach nichts, allenfalls liefert er noch einen Wert zurück. Standardmäßig ist das null, 0, false, EMPTY_LIST, … . Und das funktioniert für ALLE Methoden, also auch für als private, static, final oder native markierte Methoden, für geerbte Methoden, und auch für die Konstruktoren (die nun Mocks liefern). Und es funktioniert auch für alle Instanzen des Typs, für zum Zeitpunkt des Mockens bereits bestehende und für später erzeugte.

Die Deklaration eines Typs als „gemockt“ geschieht durch die Angabe der Annotation @Mocked vor einer Variablendefinition. Das ist nicht überall, sondern nur an folgenden Stellen erlaubt, die sich durch den Gültigkeitsbereich des Mocks unterscheiden:

Bei der Definition einer Instanzvariable in der Testklasse.
Bei der Deklaration eines Parameters für eine Testmethode (ja, das geht!).
Innerhalb eines Expectation Blocks in einer Testmethode. Das ist die Variante, die uns in unserem Beispiel weiterhilft.

Das Expectations API deckt zwei wichtige Aufgaben ab: erstens man kann Erwartungen an die Interaktion zwischen dem SUT und seiner Umgebung formulieren, also etwa „Ich erwarte, dass im Test ein Konstruktoraufruf erfolgt und dann genau dieser weitere Methodenaufruf, wobei übrigens folgender Wert zurückgegeben werden soll“. Aufrufe anderer Methoden oder eine falsche Aufrufreihenfolge werden dabei als Fehler angesehen. Man verwendet für die Definition dieser Erwartungen Expectation Blocks des Typs Expectations. Daher stammt auch der Name für das API. Zweitens man kann lediglich Rückgabewerte für Methoden vorgeben. Ob überhaupt, wie oft, und in welcher Reihenfolge die Methoden aufgerufen werden, ist dabei unerheblich. Für die Definition solcher Erwartungen an das Verhalten des Mocks verwendet man Blocks des Typs NonStrictExpectations. Diese zweite Aufgabe tritt nach meiner Erfahrung wesentlich häufiger auf als die erste. Auch in unserem Beispiel hilft uns solch ein NonStrictExpectations Block weiter.

Die Syntax von Expectation Blocks

Was hat es nun mit diesen Blocks auf sich? Schauen wir uns den Block an, den wir in unserem Beispiel benötigen:

@Test public void newInvoiceUpdateRecorderHasNoInvoices() { … new NonStrictExpectations() { @Mocked DbConnection anyDbConnectionMock; { anyDbConnectionMock.fetchAllInvoices(); result = Collections.EMPTY_LIST; }}; … }

Syntaktisch haben wir hier die Erzeugung einer Instanz einer anonymen Subklasse der Klasse Expectations vor uns, die eine Instanzvariable und einen statischen Initializer enthält. Die so erzeugte Instanz wird dann umgehend dem Garbage Collector übergeben. Und das soll sinnvoll sein? Puh!

Für JMockit bedeutet dieser Block (grob gesagt):

Der Typ DbConnection ist für den Rest der Ausführung der Testmethode gemockt. D.h., ALLE Methodenaufrufe auf bereits existierenden Instanzen in der Software greifen nun nicht mehr auf den Original-Code zu, sondern auf den Mock. Ein new DbConnection() Aufruf erzeugt nun einen Mock. Statische Methoden in DbConnection sind ebenfalls gemockt.
Der Mock ist nicht-strikt. Aufrufe aller seiner Methoden sind im Rest des Tests beliebig oft möglich und liefern die Standard-Werte.
Im Initializer befindet sich der Mock im Aufzeichnungsmodus. Aufrufe und zugehörige Rückgabewerte werden aufgezeichnet. Im Beispiel wird festgelegt, dass Aufrufe der Instanz-Methode fetchAllInvoices() immer eine leere Collection liefern sollen. Achtung: anders als z.B. bei Mockito oder EasyMock müssen diese Aufrufe NICHT unbedingt auf der Instanz anyDbConnectionMock erfolgen! Jeder Aufruf, egal auf welcher Instanz, liefert nun den vorgegebenen Rückgabewert. Die Variable anyDbConnectionMock ermöglicht es uns nur

Die eigenartige Syntax hat übrigens meiner Meinung nach einige erwähnenswerte Vorteile:

Innerhalb des Initializers stehen die gemockten Aufrufe nackt ohne jegliche, die Lesbarkeit behindernde „Verzierungen“ da, also kein when(…).thenReturn(…) oder doThrow(…).when(…).… wie z.B. mit Mockito.
Die Syntax ist immer dieselbe, egal ob sich um Aufrufe von Methoden mit Rückgabe-Werten, void-Methoden, finalen Methoden oder Konstruktoren handelt.
In IDEs kann man den ganzen Expectations Block einfach zusammenfalten und sich so beim Lesen des Tests auf das Wesentliche konzentrieren.
Es ist kein zusätzliches Kommando nötig, um aus dem Aufzeichnungs- und den Abspielmodus zu kommen. Trotzdem ist der Aufzeichnunsmodus optisch und logisch deutlich getrennt vom Abspiel-Modus.

Zurück zu unserem Test, nun erweitert um den Expectations Block:

@Test public void newInvoiceUpdateRecorderHasNoInvoices() { // System-Under-Test vorbereiten. new NonStrictExpectations() { @Mocked DbConnection anyDbConnectionMock; { anyDbConnectionMock.fetchAllInvoices(); result = Collections.EMPTY_LIST; }}; InvoiceUpdateRecorder recorder = new InvoiceUpdateRecorder(); }

Nun bekommen wir beim Ausführen den gewünschten grünen Balken, da nicht mehr der Original-Konstruktor von DbConnection aufgerufen wird, der den „bösen“ JDBCConnectionManager aufruft. Stattdessen wird einfach nur ein Mock erzeugt und in der Instanzvariablen dbConnection von InvoiceUpdateRecorder abgelegt. Damit haben wir Schritt 1, die Vorbereitung des SUT erledigt.

Schritt 2: Der Aufruf des SUT

Der zweite Schritt ist recht einfach und kurz. Wir ergänzen den Test um den Aufruf.

String result = recorder.getInvoiceReport();

Manchmal muss man bei diesem Aufruf noch einen oder mehrere Parameter-Objekte in das SUT hineinreichen. Wenn diese gemockt werden müssen, genügt es nicht, den Mock innerhalb des Expectation Blocks zu definieren, sondern man muss den Mock als Parameter in die Testmethode hineinreichen, oder gleich als Instanzvariable der ganzen Testklasse definieren.

Schritt 3: Die Überprüfung des Ergebnisses

In unserem Fall ist dies einfach. Wir haben eine Funktion aufgerufen, die keine Seiteneffekte hat, sondern einfach ein Ergebnis liefert. Dieses können wir im Test prüfen, hier bereits in der neuen, eingängigeren JUnit 4-Syntax:

assertThat(result, is("no invoices found"));

Unser Test sieht damit so aus:

@Test public void newInvoiceUpdateRecorderHasNoInvoices() { // Schritt 1: System-Under-Test vorbereiten. new NonStrictExpectations() { @Mocked DbConnection anyDbConnectionMock; { anyDbConnectionMock.fetchAllInvoices(); result = Collections.EMPTY_LIST; }}; InvoiceUpdateRecorder recorder = new InvoiceUpdateRecorder(); // Schritt 2: SUT aufrufen String result = recorder.getInvoiceReport(); // Schritt 3: Ergebnis prüfen assertThat(result, is("no invoices found")); }

Manchmal muss man allerdings auch die Interaktion des SUT mit seiner (typischerweise gemockten) Umgebung prüfen. Dafür setzt man entweder Expectations ein. Das führt allerdings dazu, dass man deutlich mehr Wissen über Implementationsdetails in den Test steckt. Ich habe es schon oft erlebt, dass der Test dann überspezifisch wird und fehlschlägt, wenn sich die Implementierung ändert, obwohl das Ergebnis, das ich eigentlich testen wollte, unverändert geblieben ist.

Das Expectations API bietet eine Fülle weiterer Features für fast alle denkbaren Fälle an. So kann man mit Hilfe von Argument Matchers vorgeben, dass z.B. ein Aufruf einer Methode mit einem beliebigen String, der „foo“ enthält, einen bestimmten Wert zurückgeben soll. Um eine Überspezifizierung eines Tests zu vermeiden, kann man nachträglich in einem Verifications Block prüfen, dass einzelne Aufrufe, die man vorher in einem NonStrictExpectations Block ermöglicht hat, stattgefunden haben.

Spiegelt sich das Ergebnis eines SUT-Aufrufs nur in einem veränderten Zustand (z.B. dem Wert der privaten Instanzvariablen secret) des SUT wider, so kann man z.B. mit folgendem Code die Prüfung dennoch vornehmen:

String result = Deencapsulation.getField(sut, "secret"); assertEquals("expected result", result);

Fazit

Und damit sind wir auch schon am Ende der zweiten Folge meiner Blog-Einträge zum Thema JMockit angekommen. Wir haben einen einfach lesbaren Test für ein Legacy-System vorgenommen, in dem Collaborators vom SUT selbst unkontrollierbar erzeugt und verwendet werden. Dazu haben wir das Expectations API von JMockit eingesetzt, das inzwischen so mächtig geworden ist, dass man das noch flexiblere Mockup API, mit dem man Klassen durch Mock-Klassen teilweise ersetzen kann, nur noch in absoluten Außnahmefällen zu Hilfe nehmen muss.

Leider konnte ich trotz der Länge des Blogs nur an der Oberfläche des Expectation APIs kratzen. Weitere Details dazu liest man am besten nach unter http://jmockit.googlecode.com/svn/trunk/www/tutorial/BehaviorBasedTesting.html.

Wer sich dafür interessiert, wie JMockit sein anscheinend magisches Verhalten implementiert, der kann hier weiterforschen: es basiert auf dem Java SE5 Feature Instrumentation API (siehe http://download.oracle.com/javase/6/docs/api/java/lang/instrument/package-summary.html) und nutzt intern die ASM Library (siehe http://asm.ow2.org/), um Bytecode zur Laufzeit zu modifizieren.

Im nächsten und letzten Teil werde ich dann beispielhaft einige weitere typische Problemfälle, die in Legacy-Code vorkommen, vorstellen und eine Lösung mit JMockit präsentieren, darunter Factory-Singletons, Remote-Service-Calls und eine datumsabhängige Funktionalität.

SEPA Direct Debits

2011-09-19T11:11:00Z

Wer ist der Initiator

Auf Initiative des European Payment Council (EPC) mit Sitz in Brüssel wurde im Januar 2008 SEPA (Single EURO Payment Area) auf den Weg gebracht. Laut EPC soll seit dem Start der SEPA nicht mehr zwischen nationalen und anderen europäischen Staaten unterschieden werden. Dieser regulative Schritt ist aus Sicht Brüssels notwendig, um einen einheitlichen Binnenmarkt zu verwirklichen und die zersplitterten nationalen Zahlungssysteme zu vereinheitlichen. In Ergänzung wurde vorab eine eigene europaweite einheitliche Kontonummer (IBAN) und Bankidentifikation (BIC) eingeführt.
Das Ziel von SEPA ist vor allem die Harmonisierung der Zahlungsabwicklung von grenzüberschreitenden Zahlungen sowohl bei Überweisungen als auch Lastschriften. Dies ist eine Voraussetzung für ein effektives und kostengünstiges Settlement bei allen beteiligten Institutionen.

Mengengerüste und Verbreitung

SEPA (Single EURO Payment Area) steht für den einheitlichen Euro-Zahlungsverkehrsraum, in dem alle ausschließlichen EURO Zahlungen innerhalb der EU27 Länder, die drei Länder des übrigen europäischen Wirtschaftsraums (EWR) sowie die Schweiz und Monaco wie inländische Zahlungen behandelt werden. Kurzum für den Bereich, der für ca. 90% aller innerhalb Europas vorgenommen Zahlungen steht.

Seit November 2010 müssen auf Betreiben des EPC alle europäischen Banken zumindest passiv SEPA Zahlungen empfangen können. Somit ist Erreichbarkeit über SEPA im ganzen SEPA Raum gegeben.

Funktionsweise

Die Hauptverfahren innerhalb von SEPA sind neben der SEPA-Card zum einen die Anfang 2008 eingeführte SEPA-Überweisung, auch SEPA Credit Transfer (SCT) genannt, und zum anderen die 2009 eingeführte SEPA-Lastschrift, auch SEPA Direct Debit (SDD) genannt, in zwei Ausführungen:

SDD B2B, die dem deutschen Abbuchungsauftrag entspricht (ohne Rückgabemöglichkeit, nur für Firmenkunden, Verpflichtung der Zahler-Bank, das Mandat zu prüfen)
SDD Core oder B2C entspricht dem Einzugsermächtigungsverfahren (mit Rückgabemöglichkeit, für Privatkunden und auch Firmen)

Für die Teilnahme an SDD muss der Händler eine eindeutige ID, z.B. für Deutschland bei der Bundesbank beantragen (https://extranet.bundesbank.de/scp/lizenz.do) und ein schriftliches oder elektronisches Mandat mit Mindestinformationen (Bank Identifier Codes (BIC), International Bank Account Number (IBAN), Mandats ID etc.) vom Schuldner erhalten. Für andere Länder kann die Creditor ID bei der jeweilgen Hausbank beantragt werden.
Das Mandat hat eine Gültigkeit von 36 Monaten und verlängert sich, falls es in dem Zeitraum genutzt wird. Eine Reduzierung der schriftlichen Vorankündigung von 14 Tagen vor dem Fälligkeitstag kann der Händler mit dem Kunden vereinbaren. Im Gegensatz zum nationalen Verfahren, das eine Zahlung bei Sicht vorsieht, geht SEPA von einem festen Fälligkeitstag („Due Date“) aus, was eine bessere Liquiditätsplanung ermöglicht. Im Folgenden ist ein papierhaftes Beispiel Mandat gezeigt. Dieses kann aber auch optisch vom jeweiligen Händler verändert werden muss aber bestimmte Mindestinformationen vorweisen.

SEPA basiert auf dem Creditor Mandate Flow (CDF), der im Gegensatz zu den Gepflogenheiten südlicher Euroteilnehmern (Debtor Mandate Flow (DMF), sehr dem deutschen Verfahren ähnelt, bei dem der Gläubiger der Initiator und Verwalter der bislang papierhaften Dokumente ist und der Kunde nach Kauf ein papierhaftes Mandat dem Gläubiger zuschicken muss.

Für das e-Payment im Rahmen eine e-Commerce Handels ist dieses Verfahren nur sehr bedingt geeignet. Daher wurde 2009 ein sogenanntes e-Mandate als Additional Optional Service (AOS) vom EPC veröffentlicht, das erst die Eignung von SEPA für den e-Commerce Handel schaffte. Daher wird im Weiteren vor allem in diesem Blog das e-Mandate Verfahren näher vorgestellt.

Das e-Mandate basiert auf dem ISO20022 XML Format und gilt sowohl für SEPA Core und B2B. Das EPC hat dazu Implementation Guidelines und ein Operating Model bereits 2009 vorgestellt.

Vorstellung des Ablaufs einer e-Mandates Vergabe
(Quelle: EPC e-Operating Model V1.5 31 März 2009)

Die wesentlichen Schritte für das auf encrypted Internet Technologien angesiedelte EPC e-Operating Model bei der Generierung eines E-Mandates sind:

Der Debtor geht auf seinem Rechner auf die Website des Creditors. Er wählt die e-Mandate Option statt z.B. Kartenzahlung. Er bekommt eine Maske angezeigt, in der er die Pflichtinformationen eingibt (vor allem IBAN, BIC des Debtors, oder als Übergangsvorschlag noch die BLZ/Kontonummer und diese mittels eines geeigneten Services (z.B. Bankverlag) werden in IBAN/BIC transferiert)
Die Creditor Website erzeugt das e-Mandat und schickt dieses zum „Routing Service“ (kann von einer Bank selbst oder einem externen Dienstleister dieser Bank sein) Nach einer Überprüfung der BIC/IBAN wird mittels der angegebenen BIC der entsprechende Validation Service der Debtor Bank rausgesucht.
Der Routing Service schickt das e-Mandate zum sogenannten „Validation Service“ der Debtor Bank. Des Weiteren wird die Website auf die Debtor Bank Website umgeleitet.
Die von der Debtor Bank bereitgestellte Validation Service Website fragt den Debtor nach den Online Credentials seiner Online Kontenverbindung.
Dieser gibt alle Zugangsdaten ein und wird von der Bank authentifiziert.
Nach einer erfolgreichen Authentifizierung wird ihm das e-Mandate angezeigt und er kann es bestätigen. Ggf. kann die Debtor Bank alle für das e-mandate fehlende Informationen als Service für den Debtor automatisch hinzufügen, die er dann nicht eingeben muss. Die Debtor Bank speichert das Mandat
Die Debtor Bank schickt das signierte e-Mandate an den Routing Service der Creditor Bank, schliesst ggf. die Session und leitet wieder auf die Creditor site um.
Anschliessend bestätigt die Creditor Website dem Debtor die erfolgreiche Bestätigung des e-Mandates und speichert das e-Mandat. Somit ist der Verkauf abgeschlossen und es kann im Folgenden eine Lastschrift eingezogen werden.

Rechtlicher Rahmen

Mit der EU-Richtlinie über Zahlungsdienste (ZAG) im Binnenmarkt (Payment Services Directive; PSD) wurde am 1. November 2009 durch das Europäische Parlament (EC) nun auch ein einheitlicher Rechtsrahmen für Eurozahlungen innerhalb der Europäischen Union geschaffen. SEPA basiert auf den Ideen der PSD und wurde vor allem auf Verbraucherschutz ausgerichtet.

Zusätzliche Schutzfunktionen und Absicherungen

Der Schuldner hat ein „no questions asked“ Käuferschutz Recht um Zahlungen innerhalb von 8 Wochen zurückzugegeben. Im Fall einer juristisch nachweislich gefälschten oder nicht vorhandenen oder authorisierten Lastschrift hat er sogar ein Recht bis zu 13 Monate nach Fälligkeitstag. Durch den Einsatz eines e-Mandates kann eine Reduzierung des Ausfallrisikos für den Händler auf 8 Wochen erreicht werden.
In Deutschland ist eine sechswöchige Rückgabefrist bereits etabliert und gut akzeptiert. Daher ist die Verlängerung auf 8 Wochen eher akademisch zu sehen, da die allermeisten Rückgaben tatsächlich innerhalb der ersten fünf Tage eingehen. Eine Auswirkung durch die Verlängerung um zwei Wochen ist in Deutschland kaum zu befürchten.
Der Gläubiger muss sich bei einer zentralen Institution seines Landes (z.B. Bundesbank) eine eindeutige Creditor ID besorgen, so dass für den Einkäufer gesichert ist, dass nur ein dort registrierter Gläubiger auch tatsächlich den Einzug macht.
Auch wird die eindeutige Mandatsreferenznummer immer zusammen mit der Creditor ID zu einer eindeutigen Identifizierung und ggf. einer Prüfung eines e-Mandates führen. Viele Banken haben ihre Kunden vor unberechtigten Ersteinzügen durch SEPA DD geschützt in dem sie deren Konten nur auf Anforderung des Kunden freischalten. Einige Lösungen unterscheiden hierbei auch B2C oder B2B.
Der Debtor Kunde hat verschiedene Möglichkeiten einzelne oder wiederkehrende Lastschriften auch vorab für bestimmte Creditoren oder bestimmte Zahlungen eines Creditors abzulehnen.

Kosten für SEPA

Mit der PSD dürfen die Banken z.B. innerhalb von SEPA nicht mehr die Gebühren für SEPA Zahlungen verlangen wie bei entsprechenden nationalen Zahlungen. Es ist stark davon auszugehen, dass SEPA für Geschäftskunden und den Handel grundsätzlich günstiger angeboten werden könnte als z.B. bei Kreditkarten oder anderen Zahlverfahren. Dies bedeutet natürlich im Umkehrschluss auch, dass die Erträge aus dem Transaction Banking vor allem im AZV im Zuge der Harmonisierung in SEPA sinken werden und durch weitere Effizienzsteigerungen aufgefangen werden müssen.

Hindernisse und Risiken

Der Start von SEPA, und dort vor allem bei SDD, ist eher schleppend in Deutschland verlaufen, da viele Unternehmen aus Kosten- und Mandatsumstellungsgründen (Austausch aller im Bestand liegender Einzugsermächtigungen) auf den weiterhin gültigen nationalen Zahlungssystemen beharren. Gerade Versicherungen scheuen neben der Umstellung auf IBAN/BIC den immensen Aufwand. Auch das e-Mandate Verfahren erfreut sich offensichtlich derzeit keines Interesses bei den Banken noch bei den Händlern oder Einkäufern.
Daher hat die EU 2010 eine Roadmap für den Ausstieg aus den nationalen Verfahren vorgestellt. Laut diesem Fahrplan sollen die letzten nationalen Überweisungen bis Ende 2012 und die letzten nationalen Lastschriften ein Jahr später aus dem Verkehr gezogen werden. Dabei setzt die EU vor allem auf staatliche und gemeinschaftliche Institutionen, die dort vorangehen sollen.
Dazu kommt noch, dass die meisten kleineren Unternehmen sich noch nicht oder nur rudimentär über SEPA informiert haben oder die Auswirkungen kennen. Es wird daher erwartet, dass erst 2012/2013 viele Unternehmen ihre Systeme auf SEPA aufrüsten werden.

Auch einige Banken haben die Auswirkungen von SEPA noch nicht voll erkannt oder scheuen die weiteren Investitionen. So haben sehr viele Banken nur die Grundfunktionalitäten von SEPA implementiert und sind tatsächlich nur passiv erreichbar.

Legacy Code unter Kontrolle Folge 1 Vorstellung von JMockit

2011-09-06T11:19:00Z

Bei meinem aktuellen Kunden setzen wir das Tool „JMockit“ so erfolgreich ein, dass es inzwischen einen wichtigen Platz in meiner „virtuellen Werkzeugkiste“ bekommen hat. Auch wenn sich die Entwickler in meinem Team größte Mühe gegeben haben, ordentlichen Code mit einem sauberen Design zu erstellen, so schlagen wir uns nun dennoch durch inzwischen weit über 1 Million Zeilen Java-Code, aus denen uns die Fehlentscheidungen der letzten 10 Jahre „entgegenmüffeln“. Wir kämpfen mit Legacy Code. Hier helfen uns Unit-Tests. Und JMockit spielt bei der Erstellung dieser Tests eine entscheidende Rolle.

Da JMockit noch recht neu und unbekannt ist, möchte ich es Ihnen hier in einer lockeren Folge von Blog-Einträgen näherbringen:

Folge 1: Vorstellung?
Folge 2: Die Grundkonzepte von JMockit. Ein erster Test, der ohne JMockit nur sehr schwer zu erstellen wäre.
Folge 3: Zwei schwierige Fälle aus der Praxis: Ein Remote-Service-Call und eine Schaltjahresregelung.

Warum Unit-Tests für Legacy Code?

Michael Feathers hat in seinem meiner Meinung nach hervorragenden Buch „Working Effectively With Legacy Code“ eine wichtige Erkenntnis formuliert: es reicht nicht aus, das Degenerieren der Code-Qualität verhindern zu wollen! Dieses Bemühen wird immer unvollkommen sein. Denn trotz bester Absichten macht man gelegentlich Fehler, die sich über die Zeit ansammeln und zu einem stetigen Abnehmen der Codequalität führen. Daher gilt es, aktiv gegenzusteuern: ständig muss man Schritte hin zu einem einfacheren, verständlicheren, besser strukturierten System machen.

Eine zentrale Technik für diese Schritte ist der Einsatz von automatisierten Regressionstests. Denn bei jeder noch so kleinen Verbesserung der Struktur muss ja sichergestellt sein, dass nicht versehentlich etwas „kaputtgemacht“ wurde. Besonders wichtig sind an dieser Stelle schnell laufende, vollautomatische Tests, die das Ein-/Ausgabeverhalten der vielen, vielen kleinen Einheiten, aus denen ein System besteht, in Isolation überprüfen, die sogenannten Unit Tests. Nach jeder kleinen Verbesserung können wir diese Tests laufen lassen und so prüfen, dass wir nicht versehentlich das Verhalten verändert haben. Ein fehlschlagender Unit Test deutet auf ein lokales, klar identifiziertes Problem in einer der Einheiten hin.

Das Legacy Code Dilemma

Nur lassen sich leider aufgrund der mangelhaften Struktur der Software die einzelnen Einheiten oft nicht in Isolation testen. Und hier beißt sich die Katze in den Schwanz: Um die Struktur mit gutem Gewissen zu verbessern, werden Unit-Tests benötigt. Und um Unit-Tests erstellen zu können, muss erst mal die Struktur verbessert werden. Das Legacy-Code-Dilemma.

Warum ist es denn so schwierig, Unit-Tests für Legacy Code zu schreiben? Wir haben doch inzwischen jahrelange Routine darin und außerdem komfortable Mocking-Frameworks wie EasyMock oder Mockito. Auch Unit-Tests, in denen Teile des Systems durch Platzhalter ersetzt werden, sind doch damit leicht möglich. Hier ein hypothetischer InvoiceUpdateRecorder, dessen Methode getInvoiceReport wir testen möchten, sowie die DbConnection, die er benötigt (die Import-Statements lasse ich aus Platzgründen aus):

public class InvoiceUpdateRecorder { private DbConnection dbConnection; InvoiceUpdateRecorder(DbConnection aDbConnection) { dbConnection = aDbConnection; // ... Viele weitere Zeilen unverständliche Initialisierung } public String getInvoiceReport() { String result = ""; // ... Viele Zeilen unverständlicher Code List invoices = dbConnection.fetchAllInvoices(); if (invoices.isEmpty()) { result = "no invoices found"; } else { // Ihr wollt nicht wissen, was hier alles passiert } return result; } } public class DbConnection { Connection jdbcConnection; public DbConnection(Connection ourJdbcConnection) { jdbcConnection = ourJdbcConnection; // weiterer Initialisierungscode } public List fetchAllInvoices() { List result = null; // JDBC-Code, um Liste aus DB zu holen return result; } }

Und so sähe beispielsweise eine Testmethode mit Mockito dafür aus:

@Test public void newInvoiceUpdateRecorderHasNoInvoices() { // Mock für benachbarte Systemkomponente erzeugen und Verhalten vorgeben DbConnection mockedDbConnection = mock(DbConnection.class); when(mockedDbConnection.fetchAllInvoices()).thenReturn(Collections.EMPTY_LIST); // System-Under-Test erzeugen InvoiceUpdateRecorder recorder = new InvoiceUpdateRecorder(mockedDbConnection); // SUT arbeiten lassen String result = recorder.getInvoiceReport(); // Ergebnis prüfen assertTrue(result.contains("no invoices found")); }

Wir erzeugen einen InvoiceUpdateRecorder, dem wir eine gemockte Datenbank-Verbindung untergeschieben, die immer eine leere Liste von Invoice-Objekten zurückgibt. So können wir leicht den Fall herbeigeführen, der uns interessiert, ohne tatsächlich eine Datenbank-Verbindung aufbauen zu müssen. Nachdem das SUT seine Arbeit getan hat, prüfen wir, ob das Ergebnis wie erwartet aussieht.
Und in gut strukturierten Systemen, in denen sich wie in meinem Beispiel das abhängige Objekt so einfach in das SUT per Dependency Injection hineinreichen lässt, funktioniert dieser Proxy-Ansatz auch wunderbar. Leider hat er einige, im Kontext von Legacy Code besonders nachteilige Einschränkungen:

Es können nur Abhängigkeiten des SUTs gemockt werden, die von außen (er)setzbar sind, denn irgendwie muss ja der im Test erzeugte Mock seinen Weg in das SUT finden. Oft erzeugen in Legacy-Systemen Klassen aber die Objekte, von denen sie abhängen, selbst, oder sie holen sie sich, indem sie statische Methoden konkreter Klassen aufrufen. Das Singleton-Pattern spielt hier oft eine unrühmliche Rolle.
Allgemein können mit dem Proxy-Ansatz statische, finale oder private Methoden, die das SUT aufruft, nicht gemockt werden.
Auch finale Klassen können nicht gemockt werden. Darunter sind auch viele Systemklassen, wie z.B. java.lang.System.

JMockit: Das Schweizer Messer unter den Test-Tools für Legacy Code

JMockit bietet eine erstaunliche Alternative ohne diese Einschränkungen. Gemockt werden hier grundsätzlich Klassen und alle ihre Instanzen, egal wer sie erzeugt. Und auch wenn die Syntax anfangs etwas gewöhnungsbedürftig ist, so ist sie doch verblüffend konsistent und mächtig.
Hier ein einfaches Beispiel, in dem wir einen etwas widerspenstigeren InvoiceUpdateRecorder testen wollen, nämlich einen, der seine DbConnection selbst erzeugt. Hier der relevante Ausschnitt aus unserem SUT:

public class LegacyInvoiceUpdateRecorder { private DbConnection dbConnection; public LegacyInvoiceUpdateRecorder() { // ACHTUNG: Wir erzeugen uns die DbConnection selbst über einen Konstruktor-Aufruf! dbConnection = new DbConnection(); // ... } // getInvoiceReport() wie wie oben }

Und hier der entsprechende Test mit JMockit, der so mit Mockito nicht möglich wäre:

@Test public void newInvoiceUpdateRecorderHasNoInvoicesWithJMockit() { new NonStrictExpectations() { @Mocked DbConnection mockedDbConnection; { // Liefere bei Aufrufen dieser Methode eine leere Liste mockedDbConnection.fetchAllInvoices(); result = Collections.EMPTY_LIST; }}; // System-Under-Test erzeugen. Dieses erzeugt selbst seine DbConnection über // new DbConnection(), bekommt aber dank JMockit nur einen Mock. LegacyInvoiceUpdateRecorder recorder = new LegacyInvoiceUpdateRecorder(); // SUT arbeiten lassen. Dabei wird die Methode fetchAllInvoices aufgerufen String result = recorder.getInvoiceReport(); // Ergebnis prüfen assertTrue(result.contains("no invoices found")); }

In diesem Test geschieht folgendes: Zunächst wird für die Dauer des Tests die Klasse DbConnection gemockt. Alle Aufrufe von Konstruktoren von DbConnection liefern nun Mocks. So auch der hier nicht sichtbare Aufruf innerhalb des Konstrukturs von InvoiceUpdateRecorder. Außerdem liefern nun alle Aufrufe von Klassen- oder Instanzmethoden von DbConnection Default-Werte: null, false, 0,… . Nur fetchAllInvoices() liefert das explizit vorgegebene Ergebnis (Bitte nicht stören lassen durch die eigenartige Syntax, in der diese Vorgabe erfolgt. In der nächsten Folge dieser kleinen Serie erkläre ich, was es damit auf sich hat und warum das gar keine so schlechte Idee ist). Der Rest entspricht 1:1 dem vorigen Beispiel: wieder rufen wir das SUT auf und prüfen das Ergebnis.

Für erste eigene Experimente mit JMockit empfehle ich die Lektüre des Getting-Started Artikel auf der JMockit-Homepage unter http://jmockit.googlecode.com/svn/trunk/www/gettingStarted.html.

Mein Fazit

Die Ausrede „Dieser Code ist untestbar!“ gilt mit JMockit nicht mehr. In den allermeisten Fällen lassen sich Abhängigkeiten in Java-basierten Legacy-Systemen damit aufbrechen. So war es uns in vielen Fällen möglich, die für eine verantwortliche Umstrukturierung erforderlichen Unit-Tests zu erstellen, ohne in den eigentlichen Code des SUT eingreifen zu müssen Dank JMockit konnten wir tatsächlich den langen, mühsamen Weg aus der Legacy-Code-Hölle in Angriff nehmen.

In der nächsten Folge schauen wir uns dann einige zentrale Konzepte von JMockit und seine verblüffende Syntax etwas näher an.

Vendor Selection Process

2011-08-15T09:57:00Z

Die Auswahl des richtigen Anbieters eines bestimmten Produkts wird in einem immer komplexer werdenden Markt zunehmend schwieriger. Glaubt man den diversen Anbietern, bieten ihre Produkte dem Kunden alle technischen Möglichkeiten und erfüllen alle nur erdenklichen Anforderungen. Zudem sind sie in der Regel robust, bieten eine innovative Architektur und sind natürlich absolut sicher. Wenn die Produkte aber bezüglich Funktionsumfang, Qualität und Stabilität alles bieten, bleibt als Differenzierungsmöglichkeit nur der Preis – oder?

Natürlich nicht! Man muss sich allerdings die Zeit nehmen, die Produkte eingehend zu prüfen und die Angaben des Anbieters kritisch zu hinterfragen. Das ist nicht immer ganz einfach und nicht ohne einen gewissen Zeitaufwand möglich…

Ausgehend von meinen Erfahrungen bei der Auswahl eines Gerätecontrollers für die Steuerung von automatisierten Kassentresoren und Druckern im Schalter/Kasse-Bereich von Banken, möchte ich den Auswahlprozess einmal eingehend betrachten. Dieses Beispiel eignet sich ganz gut, da es sich hierbei um keinen Massenmarkt handelt und wir bei der Betrachtung mit nicht allzu vielen Anbietern konfrontiert sind.

Ziel unserer Voruntersuchung war der Nachweis, dass die Schalter-/Kasse-Anwendung der Bank im WAN betreibbar ist. Als zentrales Element unserer Lösungsarchitektur kristallisierte sich der Gerätetreiber der Bank heraus, über den die verschiedenen Gerätetypen angesprochen werden. Über dieses Gerät müssen nicht nur alle aktuellen und zukünftigen Geräte angesprochen werden, sondern diese auch ausfallsicher, störungsfrei und zugriffssicher betrieben werden können.

Wie finden wir nun das zu uns passende Produkt?

1.Schritt: von der Evaluierung der Anforderungen zur Longlist

Der wichtigste Schritt und das Fundament der Untersuchung besteht zunächst darin, die eigenen Anforderungen aufzuschreiben und entsprechend zu gewichten. Dies bringt Übersichtlichkeit und Struktur in die eigenen Gedanken und schützt davor, sich bei der späteren Entscheidung von Gefühlen leiten zu lassen. Zudem macht es den gesamten Entscheidungsprozess auch für Außenstehende transparent

Die Anforderungen und deren Gewichtung sollten bereichsübergreifend stattfinden. Die Sichtweise eines Support-Mitarbeiters weicht unter Umständen gravierend von der eines Kollegen der IT-Sicherheit ab.

In unserem Fall bildeten wir mit Kollegen aus den Bereichen Betrieb, IT-Sicherheit und Anwendungsentwicklung ein Team. Die erarbeiteten Kriterien hatten nicht nur differenzierte Gewichtungen, sondern beinhalteten auch klare Ausschlusskriterien.

Mit dieser abgestimmten Liste hatten wir nun den Grundstock für eine klare Produktentscheidung gelegt. Was wir jetzt noch brauchten, war eine Aufstellung (möglichst) aller Hersteller und eine erste Bewertung auf Grundlage der Herstellerbeschreibung. Bei der Betrachtung des Marktes stellten wir fest, dass es sich – wie schon eingangs erwähnt – um keinen Massenmarkt handelt und es somit allenfalls eine Handvoll Anbieter geben würde.

2.Schritt: von der Longlist zur Shortlist

Bei einer breiteren Angebotspalette als in unserem Fall, z.B. bei CMS-Produkten, wird man bei dem Versuch, alle Anbieter auf Grundlage der eigenen Kriterien zu bewerten, schnell feststellen, dass es im Grunde zu viele Anbieter gibt. Der Zeitaufwand würde einfach zu groß werden. Es ist daher völlig legitim, bereits hier eine Vorauswahl für die Longlist zu treffen, z.B. nach Kriterien wie Bekanntheit des Produktes oder Produkt-Feedback von Kollegen.

Diese Longlist mit Produkten und Kriterien ist jetzt systematisch abzuarbeiten. Hierzu sollten Sie alle Möglichkeiten nutzen, die Ihnen zur Verfügung stehen, z.B. Herstellerangaben (Request for Information), Internetrecherche, Feedback von Kollegen, Besuch von Messen usw.

Ziel ist es, die Liste so weit zu reduzieren, dass man die Möglichkeit hat, bei den verbliebenen Produkten in die Tiefe zu gehen.

Sollte Ihnen dies nicht im ersten Versuch gelingen, gehen Sie ruhig noch einmal zu Schritt 1 zurück und überprüfen Sie Ihre Kriterien. Denn manchmal ändern sich die Meinungen zu den Gewichtungen auch im Laufe des Prozesses…. Es ist sehr wichtig, dass alle Einstufungen und Entscheidungen immer gut dokumentiert sind, damit sie später noch nachvollziehbar sind. Nur eine einzige Note einzutragen, wirft später meist mehr Fragen auf als Antworten zu geben und beraubt Sie der Möglichkeit, diese noch zu ändern oder zu ergänzen.

In unserem Fall hatten wir es in diesem Punkt denkbar einfach – es gab nur zwei Produkte und beide schienen zu passen.

3.Schritt: Produkttests und Workshops mit dem Hersteller

Ihre Liste sollte mittlerweile übersichtlicher sein, und Sie haben vermutlich auch schon ein grundsätzliches Gefühl für die Produkte. Eine Entscheidung werden Sie aber sicher auch jetzt noch nicht treffen können

Den Herstellerangaben in deren Infoblättern kann man zwar vertrauen, muss man aber nicht… Und eine nachhaltige Entscheidung sollte auch nicht allein von Herstellerversprechen abhängig gemacht werden.

Daher wird man nicht umhin kommen, sich das Produkt live anzuschauen, zu testen und die Herstellerangaben bewusst in Frage zu stellen.

In unserem Fall hatten wir die beiden Anbieter zunächst jeweils zu einem ganztägigen Workshop eingeladen. Ziel war es, sowohl den Hersteller persönlich kennen zu lernen als auch dem Produkt inhaltlich näherzukommen. Hierfür wurden die Hersteller gebeten, uns entsprechende Testsysteme vor Ort zur Verfügung zu stellen.

Spätestens in den Workshops sollte die Frage nach Referenzkunden und Ansprechpartner kommen. Ein Produkt, das am Markt erfolgreich ist, wird hier sicher glänzen können. Ist der Hersteller eher zurückhaltend mit Auskünften, sollte nachgebohrt werden. Ein Besuch beim Referenzkunden ist auf jeden Fall anzustreben.

Die Workshops bilden meines Erachtens die Grundlage für eine erfolgreiche Produktauswahl, sie schaffen eine Kommunikationsplattform und geben auch dem Hersteller die Möglichkeit, die Anforderung des Kunden besser zu verstehen und darauf einzugehen. Sie werden aber auch hier feststellen, dass Fragezeichen bleiben werden. In unserem Fall war uns z.B. die Anbindung der Drucker nicht ausreichend geklärt – Versprechen und Zusagen der Hersteller sind zwar schön, hinterlassen bei einer Untersuchung aber immer auch ein Fragezeichen. Daher sind wir dazu übergegangen, das Produkt mit kleinen selbst gebauten Prototypen zu testen. Hierdurch erreicht man eine Konkretisierung, die einem einen deutlich tieferen Einblick in das Produkt ermöglicht.

Am Schluss der Workshops sollte neben der fachlichen und technischen Bewertung immer auch eine grobe Kostenplanung stehen

Folgende Ergebnisse lagen uns am Ende dieses Schritts vor:

Testergebnisse der Produkte
implementierte Prototypen
persönlicher Eindruck vom Hersteller
Referenzkunden
Einschätzung der Hersteller-API
Preisindikation

4.Schritt: Entscheidung

Nachdem alle Fragen mit den Herstellern geklärt sind, muss eine Produktentscheidung gefällt werden. Auch hier sollte die Basis der Entscheidung die Anforderungsliste sein. Gehen Sie alle Anforderungen und Gewichtungen noch einmal kritisch durch.

In unserem Fall lagen die beiden Produkte recht nahe beieinander, beide Produkte hatten Stärken und Schwächen. Für uns war es positiv, dass wir die Entscheidung nicht selbst zu treffen hatten, sondern die Ergebnisse mit einer Empfehlung zu präsentieren hatten. Dadurch standen wir vor der Aufgabe, die Ergebnisse gegenüber einem Dritten verteidigen und auch kritischen Fragen standhalten zu müssen. Diese Situation sollte man zumindest im Hinterkopf haben.

Ob die Entscheidung sich nun im Nachhinein als gut oder schlecht erweist, wird sich eventuell erst im Laufe der Zeit zeigen, aber mit der Erstellung einer umfangreichen Anbieterauswahl können Sie viele Probleme bereits im Vorfeld eliminieren und spätere Risiken besser managen. Für ein Risiko, das Sie kennen, können Sie entweder entsprechende Maßnahmen definieren oder das Risiko bewusst eingehen. Beides ist deutlich besser als von einem plötzlich eintretenden Risiko überrascht zu werden

Eine Anbieterauswahl ist deutlich komplexer und aufwändiger als es im ersten Moment den Anschein hat. Für zahlreiche Produkte gibt es bereits eine große Anbieterpalette mit vergleichbarem Funktionsumfang und Niveau, so dass eine Auswahl z.B. auf Basis von Herstellerangaben nicht mehr ohne Weiteres möglich ist. Wer die eigenen Anforderungen falsch oder nur ungenau gewichtet und die Produkte am Markt nicht im Detail prüft, muss damit rechnen, dass am Ende des Auswahlprozesses nicht das optimale Produkt steht.

Die Folgekosten dürften in diesem Fall deutlich höher sein als der Aufwand für eine solide Anbieterauswahl.