… 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