Autor: 
… und sprich mit der Entwicklerin
Anfang Dezember hatte ich das Glück, einmal ein professionelles Analytikerseminar besuchen zu dürfen. Ein paar Dinge, die ich dort gelernt habe, und ein paar Dinge, die mir dort und danach selbst (wieder) eingefallen sind, stelle ich in diesem Artikel vor.
Wenn eine neue Software entwickelt oder ein altes System modernisiert werden soll, steht erst einmal eine Analyse an: Was wird derzeit eingesetzt? Was gibt es überhaupt an Aufgaben, die mit oder ohne Software erledigt werden? Welche Wünsche an eine neue Software existieren? Und so weiter, und so fort… Für diese Phase der IT-Systementwicklung gibt es Modellierungsmethoden. Bei OOSE (www.oose.de) gibt es nicht nur den UML-Becher (s. auch die Rezension „Unified Modeling Language“ vom 7. Juni 2003), sondern auch Seminare. Völlig subjektiv sag ich hier mal, dass die klasse sind. [Anm. der Red. Natürlich nicht ganz so klasse wie die Kurse bei der IF… ;-) , aber auch sehr, sehr gut.] Kurz und gut, OOSE lehrt Methoden und Sprachen, die frau online auch beschnuppern kann. Wer noch Weiterbildung sucht, die ihr Chef für sie fordert, sollte hier mal nachsehen. Genug unbezahlte Werbung, jetzt kommt endlich ein bisschen Inhalt.
Interviews
Am Anfang stehen die Interviews. Interviews mit Jenen, die die Software später benutzen. Worum geht es hier? Die Analytikerin will herausbekommen, welche Arbeitsabläufe überhaupt existieren. Dabei gibt es ein paar Punkte, die frau beachten kann:
- Fragen: „Welches sind die Probleme?“
- Probleme identifizieren, erst SPÄTER Lösungen überlegen
- Anzahl identischer Antworten mitzählen sowie Prioritäten protokollieren
- Interviews möglichst zu zweit mit den Interviewpartner/innen führen (dann hat man schon mal vier Ohren und zwei Sichten)
Eine Gefahr bei der Systementwicklung ist „Der goldene Hammer“. Was bedeutet das? Wer als Werkzeug nur den Hammer kennt, für den sieht alles aus wie ein Nagel. Das gilt insbesondere auch für Programmierer/Coder. So könnte es passieren, dass vorschnell Lösungen vorgeschlagen werden, die anscheinend auf der Hand liegen, ohne andere Möglichkeiten zu berücksichtigen.
Im Gespräch bleiben und den Weg im Auge behalten
Wichtig ist die Diskussion, das Gespräch! Details gehören dazu, stehen aber nie im Mittelpunkt (in dieser Phase). Es geht darum, um was es geht! Mit dem Vorsatz, Einigkeit in der Sicht auf die Dinge zu erreichen. Das Ziel ist, das zu modellierende neue Softwaresystem für alle Beteiligten möglichst nützlich und brauchbar entwickeln zu können. Dafür muss frau erst mal wissen, wie der Rahmen aussieht. Details können später geklärt werden. Abstraktion ist hier das Zauberwort.
Eine Schwierigkeit bei der Analyse besteht darin, dass endlose Diskussionen und das Hinabtauchen in Detailfragen den Zeitrahmen sprengen. Was also kann die Analytikerin tun, um das Problem „Zeit einhalten“ bei Arbeitstreffen in den Griff zu bekommen?
- Den Zeitrahmen für Treffen vorgeben (und den Beteiligten vorab und mittendrin mitteilen)
- Das Bewusstsein schaffen: Irgendwann muss man entscheiden
- (Noch) offene Probleme explizit notieren
- „Stehung“ statt Sitzung
Eine Methode, Deadline-Verschiebungen zu vermeiden, ist das „time boxing“: Zeit geht vor Inhalt, d. h. die Deadlines sind fest, nicht die Ergebnisse. Das Ganze geht mit agiler Softwareentwicklung Hand in Hand. Keine Frage, so eine Vorgehensweise muss mit den Entscheiderinnen und Entscheidern abgesprochen werden! Nichtsdestotrotz ist time boxing sinnvoll:
Auftraggeber/innen kaufen lieber fertige Software, die nicht perfekt ist, als perfekte Software, die nicht fertig ist!
Ein Startpunkt jeder Modellierung ist der „gute Fall“, das bedeutet, dass Ausnahmen und Sonderfälle jetzt noch nicht betrachtet werden. Solche werden später eingefügt. Das hilft nicht nur, die Zeit einzuhalten, sondern erhöht auch die Übersichtlichkeit.
Erfolgsformel
Diese Formel habe ich von einem OOSE-Mitarbeiter gelernt – und sofort geglaubt: Erfolg = Qualität * Akzeptanz. Sie beschreibt die Abhängigkeit des Erfolgs nicht nur von der Qualität des Produkts, sondern auch von der Akzeptanz seitens der Kundschaft. Trivial? Klar, aber der eine Faktor (welcher wohl…?) wird leider immer noch viel zu oft ignoriert.
Kreativitätsmethode „Produktkarton“
Aufgabe: Produktkarton für das fertige Produkt (SOLL) entwerfen, in dem der Benutzerin oder dem Benutzer und anderen Beteiligten das System „verkauft“ werden soll. Die Größe sollte etwa die eines Schuhkartons sein. Darauf geschrieben werden Ideen/Systemvoraussetzungen etc. Ein Beispiel ist auf dem Foto zu sehen.
- Wie heißt das Produkt? (Hier: go4IT)
- Produktfeatures: 5-15 Merkmale und Eigenschaften (im Bsp. vier Anwendungsbereiche)
- Voraussetzungen: Hardware, Softwarearchitektur, Systemumgebung/Fremdsysteme (Schnittstellen), Entwicklungswerkzeuge, organisatorische und personelle Voraussetzungen …
- Für Verkaufsprodukte: Preis
Beschreibung und Messkriterien
Zur Beschreibung bietet sich die UML an, die Unified Modeling Language. Außer den Diagrammen gibt es aber noch andere wichtige Aspekte. Wie umfangreich soll die textuelle Beschreibung einzelner Anwendungsfälle denn nun sein? Als Daumenregel kann frau sich merken: Eine Din-A4-Seite. Auch Systemidee und Ziel passen auf max. eine Din-A4-Seite (vgl. Produktkarton). Natürlich helfen bei der Umsetzung auch Kennzahlen. Sie helfen, sind aber immer auch mit Vorsicht zu genießen. Ein Beispiel aus der Nagelfabrikation: Da lautete die Kennzahl „möglichst viele Nägel pro Monat produzieren“. Was dazu führte, dass nur noch kleine Nägel hergestellt wurden. Bei der Kennzahl „Stahlverbrauch pro Monat“ dagegen kam es zur Produktion riesiger Nägel… (auch das ein Beispiel aus dem Seminar und nicht auf meinem Mist gewachsen – aber eingängig).
Was gilt es noch zu beachten? (Achtung, Ausnahmen gibt es ab und an.)
- Ist das verständlich formuliert (Sprache der Anwender/in, nicht der Entwickler/in)? Alle möglichen Leser/innen müssen die Beschreibung verstehen können!
- Substantiv und Verb
- Aus Sicht des Unternehmens bzw. des Akteurs
- Die Beschreibung ist technologieunabhängig, der Name fachlich
- Ist es ein Anwendungsfall oder nur ein Detailschritt?
- Auslöser und Ergebnis finden
- Ist das Beschriebene überhaupt relevant? (Im Zweifel erst mal aufschreiben, streichen kann frau hinterher immer noch)
- Glossar führen: Begriffe definieren
Aus der Praxis
Hier noch ein paar Mosaiksteinchen aus der Praxis. Es gibt Organisationen, die haben für alle Softwaresysteme die Vorgabe „handschuhbedienbar“. Klingt aus meiner Sicht gut, denn ich bin zwar kurzsichtig, aber durchaus technikaffin und erlebe die Miniaturisierung der Webtexte und Links als absolut abstoßend!
Wo war ich stehengeblieben? Ach ja, Mosaiksteinchen. Präsentationen des neuen Softwarekonzepts bei der Auftraggeberin sollten zu zweit oder mehr gehalten werden. Wozu? Eine spricht, ein anderer notiert Fragen während der Präsentation, um diese später zu beantworten. Die Rollen können wechseln, das erhöht die Aufmerksamkeit des Publikums.
Etwas Psychologie kann auch nicht schaden: Haben wir es hier mit einem risikofreudigen oder einem kostenbewussten Typ zu tun? Liegt gerade ein anderes Problem in der Luft, das eigentlich nix mit der Software zu tun hat? Solche Störungen können den Erfolg einer Präsentation bekanntlich stark beeinflussen, das haben wir alle wohl schon mal erlebt.
Fazit
Modellieren ist ein Prozess, der nie abgeschlossen ist (klar, panta rhei). Modelle sind einfach Mittel, die die Kommunikation und gegebenenfalls den Konsens untersützten sollen. Viel Spaß dabei!
Maria
von Maria
Christy Marx ist Schreiberin, Gamedesignerin und entwickelt in dieser Funktion Stories für Animationen, Comics und Spiele. Auf ihrer Verdienstliste stehen unter anderem: Babylon 5; 20,000 Leagues Under the Sea; He-Man; X-Men Evolution; Teenage Mutant Ninja Turtles; Lord of the Rings; Elfquest. Und noch mehr.
Dieses Buch bringt Praxiswissen und Techniken, die frau für ihre eigenen Ajax-Implementierungen braucht. Ajax – Asynchronous JavaScript and XML – ist ein Begriff für Vieles: für asynchrone http-Anfragen, die mittels JavaScript Informationen von einem Server abrufbar machen, ohne dass die ganze HTML-Seite neu geladen werden muss. Damit wurde mal wieder ein Hype eröffnet, der derzeit in Aller Munde ist: die neue Generation von Webanwendungen, mit der das bisherige Klicken-und-Warten der Vergangenheit angehört. Dafür muss frau sich aber auch bewusst sein, dass z. B. Formulareingaben gesendet werden, BEVOR ich noch auf einen Sendebutton klicke.
Es gibt wieder mal ein gutes Buch für Karrierefrauen. Viele persönliche Beispiele, auch zum Erklären des „kleinen Unterschieds“ (nämlich in der eigenen Einstellung), machen das Lesen sehr leicht. Auch für Informatikerinnen, die ja eher weniger mit solchen weichen Fakten wie Psychologie anfangen können… Die Autorin beschreibt fundiert und verständlich, wie frau ihren eigenen Karriereplan strategisch aufstellen kann. Dabei spricht sie auch Hindernisse an, die bei der Umsetzung der Tipps auftreten können (und wahrscheinlich sogar auftreten werden). Beim Lesen hab ich immer wieder zustimmend genickt.
Genau wie die erste Auflage ist die Zweite sehr kurz gehalten. Wer schnell liest, ist in zwei Stunden durch. Das Ganze ist auch sehr verständlich geschrieben. Die einzelnen Abschnitte orientieren sich stark an der Praxis. Manche Grafiken stehen dem eigentlich guten Fachwissen leider ein bisschen entgegen, z. B. ist die Farbkodierung bei zwei aufeinanderfolgenden Grafiken inkonsistent. Auch einzelne Piktogramme haben mir nicht gefallen, da „total frustriert/Nase voll?“ bzw. „Website unzufrieden verlassen“ sind meines Erachtens schlecht zugeordnet.
Das englischsprachige Buch betrachtet Patzer beim Design von Benutzungsschnittstellen. Dabei werden kommerzielle Software, Websites und Informationsprogramme begutachtet. Der Autor erklärt, wie durchaus intelligente und mit bester Absicht werkelnde Profis peinliche Fehler konstruieren können – und wie frau solcherart Fehler vermeidet.
Nachdem der Internetboom heftig abgebremst hatte, wurde auch dem letzten Webdesigner klar, dass Profit nur mit qualitativ hochwertigen Websites zu erwirtschaften ist. Eine grundlegende Komponente von Qualität ist Usability. Das Web ist nicht so leicht zu benutzen, wie es für die Durchschnittssurfer zu wünschen wäre. Die verlassen sich aber trotzdem darauf, auf Informationen, kommerzielle Seiten oder Unterhaltung zugreifen zu können.
Wie stellt frau sich eine perfekte Flugreise vor? Keine Warteschlangen beim Einchecken, keine Verspätungen, die Koffer sind tatsächlich am Ziel angekommen. Die Universität Bremen ist mit einem Informatikteam am Projekt "E-Cab" beteiligt, um solche Vorstellungen zum Alltag werden zu lassen. "E-Cab" steht für "E-enabled Cabin and Associated Logistics for Improved Passenger Services and Operational Efficiency".
Die Autorin will mit ihrem schmalen Buch Frauen (und schüchternen Männern) helfen, entspannt vor Publikum aufzutreten, Schüchternheit zu überwinden und spürbares Selbstvertrauen aufzubauen. Dazu bedient sie sich Imaginationstechniken und Körperübungen. Die CD zum Buch enthält dazu den Ton.
Das Buch beantwortet die Frage, wie frau komplexe Systeme entwickeln kann. Verschiedene Komponenten aus so unterschiedlichen Bereichen wie Software, Mechanik und Elektrotechnik werden durch eine neue Generation von Entwicklungswerkzeugen handhabbar. Der Autor, Mitautor der SysML-Spezifikation, führt in die Methoden des Systems Engineering ein, die von konkreten Disziplinen wie Software- oder Hardwareentwicklung unabhängig sind. Anhand eines Fallbeispiels zeigt er, wie ein komplexes, heterogenes System ganzheitlich beschrieben und modelliert wird.
Die 
Frau Prof. Dr. Christa Kaune, Mit-Organisatorin, hat mir Rede und Antwort gestanden. Sie ist schon seit 2002 mit der Sommerakademie verbunden. Außerhalb der Akademie ist sie Apl. Professorin am Fachbereich Mathematik/Informatik der Universität Osnabrück an der Universität in Osnabrück.
Schwarzweiß-Fotos vermitteln ein ungewohntes Bild. Ihr Ausdrucksmittel ist der Kontrast. Die Bildaussage wird konzentriert auf den Inhalt, wenn die Farben weggelassen werden. Vor allem die Beherrschung des Kontrastes – im technischen wie im gestalterischen Sinn – unterscheidet Spitzenfotos von Allerweltsaufnahmen.
Ruby ist schon länger in aller Munde, wenn es darum geht, effiziente Webanwendungen zu entwickeln. Durch die Einbindung von AJAX ist das Buch „Ruby on Rails“ nochmal interessanter. Leider ist der Schreibstil schlecht. Flappsig zu formulieren sollte sich nur erlauben, wer (trotzdem) sehr gut erklären kann. Zum Beispiel ist die Erklärung des Model-View-Controller-Konzepts für Kennerinnen überflüssig; Leserinnen, die das Konzept nicht kennen, können mit der Erklärung nichts anfangen. Es werden immer wieder dieselben Phrasen wiederholt, selbst Anwendungs- und Codebeispiele kommen schwammig daher.
