Overblog
Folge diesem Blog Administration + Create my blog

Vertretungsprofessur an der FH Dortmund

Ab diesem Wintersemester werde ich an der FH Dortmund eine Vertretungsprofessur für Softwaretechnik bekleiden. Ich freue mich schon. Im Wintersemester halte ich dort "Softwaretechnik 1" (Requirements Engineering und UML) und "Einführung in die Programmierung".

Andrea Herrmann

Kommentare anzeigen

AKAD-Forum am 18.09.2019

Am 18.09. findet in Stuttgart das AKAD-Forum statt mit dem Thema "Digitale Bildung mit und gegen Künstliche Intelligenz". Ich werde dort zwei Vorträge halten:

- über meine Stellenanzeigenstudie zur Arbeit im Requirements Engineering,

- über die ethischen Aspekte von Künstlicher Intelligenz und welche Folgen dies für das Berufsleben von Informatiker haben wird.

Ich arbeite schon seit 2009 für die AKAD University als freiberufliche Dozentin, Lehrbuchautorin und Betreuerin von Abschlussarbeiten, und freue mich, dieses Jahr zum ersten Mal beim AKAD-Forum dabei zu sein.

Andrea Herrmann

 

Kommentare anzeigen

Der Neckarsteig von Mosbach bis Neunkirchen

Vorigen Freitag führte ich mein Projekt "Ich wandere den gesamten Neckar entlang" weiter. Da es mit geringer Priorität nebenher läuft, zieht sich die Projektdauer etwas in die Länge. Um dem Ende in Mannheim schnell näher zu kommen, hatte ich mir für Freitag zwei der offiziellen Tagesetappen vorgenommen, also 31 km. Ich hab's auch geschafft! Allerdings war das mal wieder eine Grenzerfahrung. Gefreut hat mich meine gute Kondition, die ja in meinem Alter nicht selbstverständlich ist. Regelmäßiger, selbst leichter Sport, tut eben seine Wirkung! (Ich unterbreche mein Loblied der Disziplin an dieser Stelle.)

Auf so einer Wanderung geht es ja zu wie im echten Leben. So dauern die guten Phasen gerade mal so lange wie man braucht, um sich zu entspannen und zu denken: "So könnte es für den Rest des Tages (Lebens) weitergehen." Kaum hat man den Gedanken zu Ende gebracht, folgt eine brutale Steigung, ein schwindelerregender Abstieg, eine glitschige Matschstrecke oder man hat sich verlaufen und muss wieder zurück. Man macht viele Extrakilometer und kann sich dann entweder über sich selbst ärgern, über diejenigen, die die Strecke so halbgut markiert haben, oder man sagt: "Ein bisschen Schwund gibt's immer."

Zwischendurch hatte ich eine Strecke, auf der ich vor allem an alles mit A dachte: Apfelschorle, Abkürzungen, ... Weiter kam ich gedanklich nicht, wegen hochgradigem Durst. Ich musste bei meinen beiden letzten Wanderungen feststellen, dass es auf dem Land eher schwierig ist, an Essen und Trinken zu kommen, außer an das üppig strömende Wasser im Dorfbrunnen der Marke "Kein Trinkwasser". Die Restaurants öffneten unter der Woche erst ab 17 Uhr. Normalerweise kann man wenigstens in einem Supermarkt noch Getränke kaufen, aber dergleichen fand ich erst in Neunkirchen. Dafür gestern in Hessigheim einen Tante-Emma-Laden, der am Samstagmorgen von 8 bis 10 Uhr bedient. Oder in Neckarkatzenbach ein Restaurant, das nur für Gruppen ab 10 Personen öffnet.

Je stärker der Durst, umso mehr wandten sich die Fragen dem W-Bereich zu: Wozu tue ich mir das an? Will ich das wirklich? Warum folge ich den fraktal verschlungenen Windungen des Neckarsteigs, der mich an jede noch so einsame Infotafel und zu jedem Aussichtspunkt ganz oben führt, statt einfach dem Radweg am Flussufer zu folgen? Wo und wann fährt wohl ein Bus? (Montag bis Freitag jeweils um 16 Uhr der letzte Linienbus, ab 22 Uhr wieder Ruftaxi. So einen Busfahrplan habe ich auch noch nie gesehen!)

Bisher fand ich den Neckarsteig prima. Er führt durch die schönsten Städte von Baden-Württemberg, Deutschland bzw. eigentlich der ganzen Welt. Aber dieser Abschnitt verbannte mich eher ins Nirgendwo.

Über die Ähnlichkeit von Wanderungen und Projekten habe ich mich ja bereits in meinem Lehrbuch "Projektmanagement beim Wandern" ausführlich ausgelassen. Auch bei diesem Projekt dauerte einiges länger als gedacht, der Zeitplan konnte nicht eingehalten werden, aber immerhin war ich früh genug fertig, damit ich mit öffentlichen Verkehrsmitteln nach Hause und in den Sonnenuntergang reisen konnte. Woran lag's? Als erfahrener Wanderer kennt man doch seinen Stundenschnitt. Allerdings wurde dieser auf verschiedenen Teilstrecken nicht erreicht, da der Weg überdurchschnittlich schwierig war (auf der Karte sind Steigungen nicht eingezeichnet!) oder ich durch Irrwege Zeit verlor (schlechte Spezifikation in der Wegbeschreibung).

Besonders grenzwertig war die Margarethenschlucht. Nur 600 m lang ist der Klettersteig und mit festen Halteseilen gesichert. Trotzdem braucht man sich wohl nicht sehr anzustrengen, um dort abzustürzen. Ein schmaler, steiler Pfad führt immer hart an der Kante an einem nicht enden wollenden Wasserfall entlang, über krümelnden roten Sandstein, der sich bei Regen vermutlich in eine Rutschbahn verwandelt. Teilweise robbte ich auf dem Hosenboden hinunter, und an mehreren Stellen setzte eine Minipanik ein. Dank hoher Konzentration und Selbstüberwindung schaffte ich den Weg, war aber froh, wieder Tageslicht und breite Wege zu erblicken. Hurra, ich lebe noch!

Nur ein kurzer Hinweis darauf, dass ich den Kurs "Projektmanagement beim Wandern" weiterhin anbiete. Dann aber nur auf Wegen, die ich vorher schon ausprobiert habe.  Dieser ganztägige Kurs besteht aus einer Wanderung mit regelmäßigen Lernpausen, in denen wir alle Themen des Projektmanagements besprechen.

Andrea Herrmann

Kommentare anzeigen

Als Freiberufler innovativ sein: zwischen Investition und Fortbildung

Gerade erschien ein Artikel von mir auf dem SOLCOM Freiberufler-Blog über die Frage, wie man als Freiberufler innovativ sein kann. Neben dem täglichen Trott und dem Geldverdienen sollten wir das nämlich auch noch machen! Das geht, wenn es auch  nebenher funktionieren muss. Aber ein Freiberufler ist per Definition eine Firma, und Firmen müssen sich weiterentwickeln...

Andrea Herrmann

Kommentare anzeigen

Das Lastenheft als Kunstwerk

"Lastenheft", das klingt nach dem lästigen Dokument, das man früher monatelanger harter Arbeit geschrieben hat. Und dabei hat scheinbar die Agilität gezeigt, dass man das gar nicht braucht. Alle hatten es schon immer geahnt und darum möglichst wenig Aufwand hinein investiert. Am Ende kam ja sowieso alles anders. Eine typische Self-Fullfilling Prophecy. Wenn man schon beim Schreiben glaubt, dass das Lastenheft keiner lesen wird und sich keine Mühe gibt, die Inhalte zu prüfen, dann wird es sich tatsächlich als irrelevant und nutzlos herausstellen, das lieblos gemachte Pseudodokument.

Aber ich glaube an das Lastenheft. Wenn man sorgfältig die Inhalte zusammensucht, konsolidiert und diszipliniert darstellt und qualitätssichert, dann hat man eine verlässliche Grundlage für die weitere Arbeit. Das habe ich schon so erlebt. Natürlich ändern sich Kundenwünsche, die Technik unterstützt dann doch nicht die Umsetzung so wie man sich das vorgestellt hatte, oder irgendetwas war dann doch nicht für den Entwickler verständlich gewesen. Hat der Requirements Engineer sorgfältig gearbeitet, kann es sich dabei jedoch nur um Kleinigkeiten handeln. Die fatalen Überraschungen bleiben aus.

Außer Lastenheften habe ich schon zahlreiche andere Bücher geschrieben, Fachliteratur und Belletristik. Eine Anforderungsspezifikation ist darum für mich nur "just another book I wrote". Übung spielt in jedem Fall eine Rolle. Nur die ersten zehn Bücher sind schwer zu schreiben. Anschließend fließt der Text nur so über die Tasten. Die schmerzhafte Disziplin für das mehrmalige Überarbeiten des eigenen Werks bringt nur der professionelle Autor auf, der weiß, dass und wie jede Formulierung sich noch verbessern lässt und dass kein Text jemals fertig wird. Das Schreiben ist genau darum eine so brutale Kunst, weil man im Gegensatz zum Maler, dem Schauspieler, Tänzer und Musiker sein Werk jederzeit noch ändern kann. Da gibt es keine Ausrede im Stil von "Am Tag der Première hatte ich leider Antibiotika genommen und war darum nicht in Bestform" und in Zeiten von digitalen Dokumenten, E-Books und Print on Demand auch keine Ausrede wie "Als ich den Tippfehler bemerkt habe, war die ganze Auflage schon gedruckt." Das Schreiben ist eine anstrengende Kunst.

Hinzu kommt bei Lastenheften noch ihr politischer, oft umstrittener Inhalt, der schnell veraltet. Das ist eine nicht zu unterschätzende emotionale Belastung für die verantwortliche Autorin.

Die agile Entwicklung scheint einen Ausweg aufzuzeigen: Niemand schreibt mehr alleinverantwortlich ein ganzes Buch. Stattdessen reden alle miteinander, und eine kurze stenographische Notiz auf einer Karteikarte genügt als Erinnerungshilfe.

Das Problem ist nur, dass die entstandene Software ihren Herstellungsprozess widerspiegelt. Wird sie auf Grundlage eines konsistenten Gesamtkonzeptes erstellt, dann fühlt sich auch ihre Benutzung entsprechend flüssig, konsistent und wohldurchdacht an. Die Software ist ein Gesamtkunstwerk, das durch das Lastenheft bereits entworfen und in Gedankenexperimenten aus Benutzersicht simuliert worden war. Die ganze Arbeit, die in das Lastenheft investiert wurde, spiegelt sich in der Software wieder: die Konkretisierung der Systemziele, die Benutzeranalyse, die Usability-Optimierung der Use Cases, die Komplettierung aller Alternativzenarien, die Definition von Styleguides für die Benutzeroberfläche, die Konsolidierung der Begrifflichkeiten in einem Glossar. Dies alles verbessert die-  User Experience. Der unbedarfte Benutzer spürt das intuitiv, die Expertin kann direkt mit dem Finger auf die Fehler zeigen, die durch eine ungenügende Spezifikation und eine iterative Entwicklung typischerweise entstehen.

Zahlreiche agil und iterativ entwickelte IT-Systeme zeigen dieselben Schwächen:

  • inkonsistente Bezeichnungen für dasselbe
  • inkonsistente Benutzerführung (ähnliche Funktionalitäten sind an verschiedenen Stellen unterschiedlich zu bedienen)
  • übervolle Benutzeroberflächen, wobei die Inhalte offensichtlich chronologisch in ihrer Implementierungsreihenfolge angeordnet sind, nicht entsprechend den Geschäftsprozessen oder Benutzerbedürfnissen
  • unnötige, inzwischen nicht mehr benötigte Felder und Funktionalitäten, die man mal entfernen könnte
  • schlechte Benutzerführung durch ein Nutzungsszenario
  • zahlreiche Fallen, wo Benutzern leicht Fehler unterlaufen
  • Gimmicks, die der Entwickler vermutlich sehr kreativ fand, die aber den Benutzer verwirren
  • schlechte Performance

Natürlich findet man das alles auch bei Legacy-Systemen, aber erstens haben sich diese Fehler dort über Jahrzehnte zusammengeläppert und zweitens hätte man sie dort durch gutes Requirements Engineering und gelegentliches Refactoring vermeiden oder beheben können. Agil entwickelte Software wird aber sehr viel schneller zum Legacy-System, weil es nicht nachhaltig geplant wird. Ich denke hier insbesondere an die Prototypen, die ich von Start-ups schon zu sehen bekam, und die gleich von Anfang an Kunden in die Verzweiflung trieben. Schlimmstenfalls funktionierten wichtige Use Cases überhaupt nicht oder nur durch einen komplizierten Workaround, weil es angeblich technisch nicht besser ging. (Zusätzlich zur Anforderungsspezifikation war oft auch das Testen vernachlässigt worden. Der Kunde testet mit Echtdaten, und dann ist oft tatsächlich technisch nicht mehr viel Änderung möglich.)

Dass dies passiert, ist nur zu logisch. Stellen Sie sich vor, jemand schreibt einen Roman im Team. Alle Stakeholder dürfen einzelne Sätze vorschlagen. Diese werden dann priorisiert oder durch Storymapping in eine chronologische Reihenfolge gebracht. Eventuell fallen noch Gedankensprünge auf, und fehlende Sätze werden spontan ergänzt. Natürlich unter Zeitdruck wegen der Timebox. Vielleicht bringt man den Roman auch zunächst als Minimum Viable Product als Kurzgeschichte heraus und erweitert ihn iterativ im Zwei-Wochen-Rhythmus. Das würde wohl kaum einen hochwertigen Roman ergeben, sondern schnell als das entlarvt, was es ist: eine Liste von Einzelsätzen.

Genauso ist die agil entwickelte Software ebenfalls eine Sammlung von Feldern und Funktionalitäten. Aber leider kein Kunstwerk, das sich für den Benutzer "richtig" anfühlt. Die Spezifikation von IT-Systemen ist eine Kunst, die erlernt und jahrelang trainiert werden muss. Das ist kein aussterbendes Handwerk!

 

 

 

 

 

 

 

 

Kommentare anzeigen

Gerhard Fessler: Software-Entwicklung in China

Gestern Abend trug Gerhard Fessler bei der Regionalgruppe Stuttgart / Böblingen vor über das Thema "Software-Entwicklung in China". Darin fasste er seine jahrelange Arbeit als CMMI-Auditor in diesem Land zusammen.

Damit wir die Größenordnungen richtig einschätzen können, verglich er die Größe Chinas mit "Europa bis zum Ural". Allerdings leben dort doppelt so viele Menschen wie in Europe auf derselben Fläche. Dabei konzentrieren sich Bevölkerung und Metropolen vor allem im Osten des Landes. Die Größenordnungen der Einwohnerzahlen der Städte übertreffen unsere Maßstäbe.

Im Alltag ist die Digitalisierung weit fortgeschritten: Mobilzugang gibt es überall in den Städten, und bezahlt wird nur noch mit dem Smartphone. Interessant fand ich auch die Information, dass die chinesische Schrift sprachunabhängig ist und genauso gut auch die deutsche oder andere europäische Sprachen dokumentieren könnte.

Die chinesische Arbeitskultur und Lebenseinstellung beeinflussen, was der Auditor vor Ort vorfindet. Obwohl oder vielleicht gerade darum, weil China ein Land von Formalismen und Bürokratie ist, brechen Chinesen gerne Regeln, und es stört sie auch nicht, wenn andere das tun. Nur wenn sie direkt darauf angesprochen werden, werden Regeln befolgt. Die Menschen sind offen für Neues und passen sich schnell an. Die Firmen investieren intensiv in Aus- und Fortbildung.

CMMI ist in China sehr verbreitet. Die Regierung fördert die Digitalisierung und fordert von den Auftragnehmern öffentlicher Aufträge ein CMMI-Level von mindestens 3. In den zu entwickelnden Provinzen finanziert sie sogar die Kosten für die Zertifizierung. Dank CMMI entstehen selbst in kleinen, jungen Firmen saubere Entwicklungsprozesse. Es ist durchaus möglich, dass so ein Unternehmen innerhalb von anderthalb Jahren von null auf CMMI-Level 3 kommt. Wasserfall-Projekte bzw. Stage-Gate-Prozesse herrschen vor. Agile Vorgehensweisen würden zur Kultur nicht passen.

Die Software-Firmen arbeiten sehr kundenorientiert und erfüllen die Anforderungen des Kunden. Allerdings auch nicht mehr als das. Fordert der Kunde nicht ausdrücklich Security und Safety ein, werden diese bei der Entwicklung nicht berücksichtigt. Da machen Payment-Systeme keine Ausnahme. Damit werden technische Schulden angesammelt. Zwischen Auftraggeber und Auftragnehmer wird täglich kommuniziert, genauso auch zwischen Vorgesetztem und Mitarbeiter. Ein Vorgesetzter führt hier maximal vier Mitarbeiter/innen. Der Führungsstil ist fürsorglich-bestimmend.

Oft werden mehrere ähnliche Projekte bei verschiedenen Software-Firmen beauftragt und anschließend entschieden, welche Lösung landesweit zum Einsatz kommt. Für die technische Realisierung wird selten etwas neu programmiert, sondern stattdessen auf Frameworks gesetzt. Dies führt in der Regel zu einer schnellen 80%-Lösung, was aber akzeptiert wird.

Als deutscher Auditor in China genießt man mehr Vertrauen als ein einheimischer. Chinesen misstrauen einander prinzipiell. Vereinfacht wird die Zusammenarbeit durch die Ähnlichkeit der chinesischen und deutschen Körpersprache sowie durch die Toleranz der Chinesen.

Wie sieht die Zukunft von Chinas Software-Entwicklung aus? Herr Fessler sagt: "Die Kunst ist nicht der Aufbau. Die Kunst ist, oben zu bleiben." Er attestiert Deutschland in dieser Hinsicht gute Erfolge, was das Publikum erstaunte. Hört man doch allerorten nur Jammern und die Befürchtung, die deutsche Software-Entwicklung könne international nicht mithalten. Auf keinen Fall ist China ein mächtiger Feind, der uns unterbuttern möchte, sondern sie wollen nur einfach groß und reich werden. Ob sie das schaffen, muss sich zeigen. Dies hängt davon ab, wie sie mit den technischen Schulden klar kommen, die sie momentan im rasanten Wachstum anhäufen. (Wobei ich persönlich glaube, dass sie dank ihres Pagmatismus Altsysteme ohne viel Federlesens einstampfen, wenn sie sich nicht mehr rentieren.)

 

 

Kommentare anzeigen

Bericht von der Informatica Feminale 2019

Gestern Abend kam ich frisch zurück von der Informatica Feminale 2019 in Furtwangen (Informatik-Sommerhochschule für Frauen). Ich gab dort von Donnerstag bis Samstag einen Kurs über "Künstliche Intelligenz". Dabei ging es um automatische und KI-unterstützte Entscheidungen, um Ontologien und Fuzzy-Logik, Text- und Sprachverarbeitung, maschinelles Lernen sowie Maschinenethik.

Fotos von der Veranstaltung gibt es hier: https://www.linkedin.com/company/scientificabw/

Auf der Informatica Feminale treffen sich etablierte und junge Informatikerinnen zum fachlichen und sonstigen Austausch. Wie immer gab es viel zu lernen, altbekannte und neue Gesichter. Eine ausgezeichnete Organisation, inspirierendes Hochschulambiente und durchgängige Verpflegung. Eine Frauenveranstaltung fühlt sich anders an als eine gemischte Konferenz. So vollständig ohne Mansplaining und ohne dass mein Gesprächspartner ständig meint, er müsse mich daran erinnern, dass ich eine Frau bin. Das mag ja sein, sollte aber in einem Fachgespräch nicht erwähnenswert sein und keinen Einfluss auf die Bewertung meiner Worte haben. In den Pausen und Abendveranstaltungen habe ich interessante Gespräche geführt und neue Kontakte geknüpft.

Neu war: Die Ausstellung über die 100jährige Geschichte des Frauenwahlrechts. Sie wechselt sich mit der bisherigen Ausstellung "Patente Frauen" ab, die dokumentiert, welche der wichtigsten Erfindungen von Frauen stammen.

Auch das Wetter muss man lobend erwähnen: durchgängiger Sonnenschein bei angenehmsten Temperaturen. Frühere Sommerschulen fanden schon bei strömendem Regen statt. Der Schwarzwald hat eben sein eigenes Mikroklima.

 

 

 

Kommentare anzeigen