Probleme lösen mit dem Einstein-Prinzip

Manche Probleme scheinen sehr hartnäckig zu sein. Man kann sie nicht wirklich dauerhaft lösen, so sehr man es auch versucht. In solch verzwickten Situationen fühlt man sich gefangen in seinem kleinen Mikrokosmos. Da lohnt sich dann ein Wechsel des Betrachtungspunktes,

Kennen Sie das nicht auch? Ein Problem, das Sie nicht wirklich in den Griff bekommen können, das hartnäckig bestehen bleibt, und wo jede Änderung nur eine Verlängerung oder kurzfristige Symptom-Bekämpfung darstellt? Der ständig wiederkehrende Ärger, die oft stressigen Quick-Fixes und die Unzufriedenheit der Anwender sind zermürbend, kosten sehr viel Energie, und natürlich auch Unmengen an Geld. Man löst alte Probleme immer wieder aufs neue, ohne Gefühl, voran zu kommen, und fühlt sich dadurch wie gelähmt. Continue reading “Probleme lösen mit dem Einstein-Prinzip”

Was ich eigentlich arbeite…

Neulich hat mich eine Frage meiner zwei älteren Kinder (damals noch zweite und dritte Klasse Volksschule) sehr beschäftigt: “Papa, was machst Du eigentlich, was ist Dein Beruf?” Diese Fragestellung, so simpel sie auch erscheinen mag, hat mich an eine meiner ersten Vorlesungen in Software-Engineering zurückversetzt, wo wir von unserem Professor Gustav Pomberger eine ähnliche Frage gestellt bekommen haben: Er fragte damals: “Und wenn Ihr in einem Flugzeug von Wien nach Zürich sitzts, und neben Euch sitzt jemand, der von Computer keine Ahnung hat, wie erklärt Ihr ihm, was Ihr macht?” Continue reading “Was ich eigentlich arbeite…”

Analyst, geh aus Deiner Höhle raus!

Wenn ich die Analyse-Ergebnisse manch studierter IT-Berater ansehe, muss ich dabei oft an Platons Höhlengleichnis denken. Scheinbar sieht der Analyst nur das, was man ihm auf leichtem Weg zu sehen gibt. Und das ist – wie bei Platons Gefangenen in der Höhle, nur ein Schatten der Wirklichkeit. Wie könnte nun der Business-Analyst seine Fesseln ablegen und die Wahrheit erkennen, die sich hinter dem scheinbar wirren Geschwafel seiner Kunden versteckt? Hier ein paar Tipps, um bei der Anforderungsanalyse ans Licht zu gelangen. Continue reading “Analyst, geh aus Deiner Höhle raus!”

Häufige Fehler bei der Anforderungsanalyse

Der spannendste Prozess der gesamten Software-Entwicklung ist für mich die Anforderungsanalyse. Hier wird entschieden, ob die Software wirklich eine Lösung für ein Problem darstellt, oder neue Probleme verursacht. Fehler in diesem Prozess sind meist sehr teuer und können ein gesamtes Projekt zum Scheitern verurteilen.
In meiner Arbeit habe ich viele schlechte Anforderungen erhalten. Die hauptsächlichen Fehlerquellen liegen in den folgenden Bereichen:

 

Substantive werden immer in Klassen modelliert

Das scheint ein Klassiker zu sein. Immer wieder ist mir dieser Fehler begegnet. Dabei wird offensichtlich mit dem Kunden gesprochen und seine Wünsche in einem Prosa-Aufsatz festgehalten. Dieser Aufsatz wird dann analysiert und Substantive als Kandidaten für Entities (Klassen) abgeleitet. Eine Modellierung als eigenständige Klasse erschwert aber immens die Implementierung und die spätere Wartung.

Besser: Viele dieser Substantive sind in Wahrheit Typen von übergeordneten Klassen, durch einen generischen Ansatz werden sowohl bei der Implementierung, als auch bei der späteren Wartung der Software hohe Aufwände gespart.

 

User-Interfaces werden von Modell-Klassen abgeleitet

Offensichtlich ist es zum durchdenken einfacher, wenn man pro Klasse eine Listenansicht und eine Bearbeitungsmaske gestaltet. Schließlich hat doch jeder Entwickler schon einmal eine MS Access-Datenbankanwendung mit den coolen Wizards erstellt.  Doch hier denkt man nicht an den Endanwender. Denn dieser benötigt oft Daten aus unterschiedlichen Klassen auf einer Maske, um sinnvoll mit dem System zu arbeiten.

Besser: Eine Analyse der Use-Cases ist unumgänglich. Die Ergebnisse sollten in sinnvolle Userinterfaces umgewandelt werden.

 

User-Interfaces werden nur verbal beschrieben

Aus einer verbalen Beschreibung ist es nicht möglich, eine Benutzeroberfläche zu bauen, die genau den Vorstellungen des Endkunden entspricht. Daher werden notgedrungen Fehler entstehen, wenn auf ein Mockup verzichtet wird.

Besser: Mit einfachen Mockup-Tools wie z.B. Pencil, Powerpoint, Word, eine Skizze zeichen. Zur Not reicht fürs erste eine einfache Zeichnung mit Kugelschreiber und Papier.

 

Geschäftsprozesse werden nur verbal beschrieben

Manche Analysten weigern sich immer noch, gängige Ablauf-Diagramme zu verwenden. UML ist inzwischen ein Standard, aber das hat sich leider noch nicht überall herumgesprochen. Dabei werden wichtige Zusammenhänge durch die Verwendung einer graphischen Darstellung viel besser veranschaulicht.

Besser: Die Verwendung eines UML-Werkzeugs, um Prozesse visuell darzustellen, erleichtert allen die Klärung der Anforderungen.

 

Modell-Klassen werden auf reine Getter- und Setter beschränkt

Eine etwas übertriebene Auslegung der Trennung von Modell- und Business-Logik sieht vor, die Modell-Klassen auf reine Getter- und Setter-Methoden zu beschränken. Logik, die zwar eine Klasse betrifft, aber über einen reinen Getter hinaus geht, wird dabei in eine eigene Schicht verschoben. Dadurch entsteht Wartungsaufwand für eine neue Software-Schicht.

Besser: Logik, die ein Objekt einer Klasse betrifft, kann und soll direkt in der Modell-Klasse abgebildet werden.

18plus

Unter dem Titel “18plus” betreibt das BM für Wissenschaft, Forschung und Wirtschaft eine Website, die SchülerInnen vor der Matura bei der Berufs- und Studienwahl unterstützt. Dazu werden psychologische Beratungen angeboten, die von den BildungsberaterInnen in den Schulen gebucht werden können. Zusätzlich werden zwei Interessenstests online angeboten, die von den SchülerInnen genutzt werden können. Dazu werden über unser System Zugangscodes generiert, die für eines der beiden Testsysteme verwendet werden können.

Weiters können BildungsberaterInnen Unterrichtsmaterialien über diese Plattform bestellen und Schüler einen Online-Fragebogen absolvieren, der Empfehlungen für die weiteren Schritte der Berufs- und Studienwahl geben kann.

Rolle:
Berater, Systemanalyst, Entwickler

Kunde:
BMWFW

Zeitraum:
seit 2008