… 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.
nach oben
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.
nach oben
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.
nach oben
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
nach oben
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!
nach oben
Maria
von Maria
Gestern um 17 Uhr wurde das Sommerstudium offiziell eröffnet. Nach einem Grußwort des Fachbereich-Dekans Christian Freksa, der spontan als Redner eingesprungen war, gab die Organisatorin der informatica, Veronika Oechtering, einen Überblick über zehn Jahre Sommerstudium.1997 entwickelten etwa 25 Frauen das bis heute stabile Konzept des Sommerstudiums mit der Zielsetzung, mehr Frauen in die Informatik zu bringen und die schon vorhandenen in einer männlich dominierten Umgebung zu unterstützen.
Das Konzept ist voll aufgegangen: An der Universität Bremen hat sich der prozentuale Anteil der Frauen an den AnfängerInnen in der Informatik von etwa 15% im Jahr 1995 auf 31% im Wintersemester 2005 gesteigert. Insgesamt haben etwa 1100 Frauen an der informatica feminale teilgenommen, 320 verschiedene Dozentinnen boten Kurse an.
Im Anschluss an Veronikas Vortrag konnten wir uns nach Herzenslust satt essen am wie immer hervorragenden Buffet von thealit. Dieser Buffetservice ist einfach einsame Spitze!
Zum 11. Mal organisiert DIGITAL PRODUCTION als Magazin für Computeranimationen dieses Jahr den Animago-Award. Wie schon in den letzten Jahren, erwarte ich dort nur das Beste – und vielleicht ist ja Eine von Euch 
Endlich ist es soweit. Das "Klima" beim Coden und Tippen lässt sich an die eigenen Vorlieben anpassen. Je nach Jahreszeit kann frau so ihr Notebook zum Wärmen oder zum Kühlen der Finger und Handballen (oben) bzw. der Oberschenkel überreden. Vorbildlich!
Studis
