Geschäftsprozesse versus Softwarequalität – a bisserl a Satire

Standard
Aber nur a bisserl a Satire.
Vorneweg, es gibt Software und Software. Die eine ist weniger von Geschäftsprozessen betroffen, das Paket ist so, wie es ist. Man kann es in bestimmtem Umfang customizen (anpassen, konfigurieren), zahlt dafür Lizenzen, hat dafür eine feste Funktionalität. Der Stakeholder (Prozess / IT) verbiegt sich, um die Geschäftsprozesse halbwegs darin abzubilden und wundert sich, dass die Anwender murren. Über diese Art Software möchte ich hier nicht sprechen.
Dann gibt es Software, die kundenspezifisch erstellt, nach den Anforderungen des Kunden maßgeschneidert wird (aber natürlich wenig kosten soll). Also unser Metier bei Z&P. Hier ist die Spielwiese, hier kann sich der prozessorientierte Anwender erst einmal wiederfinden und die Jahre vorher in zig Besprechungen ermittelten Anforderungen an die Software stellen (Phase der enthusiastischen Begeisterung).
Der Stakeholder kann sich austoben, seine Wünsche äußern, neue Prozessvarianten erfinden. Am besten während der Realisierung ständig Verfeinerungen einbringen oder auch mal alles umwerfen oder erkennen, das man in der jahrelangen Vorarbeit irgendwie nicht wirklich was entscheidendes formuliert hat (einsetzende plötzliche Verwirrung). Das ist die Phase, in der der Product Owner (Entwicklungsseite) nicht mehr versteht was der Stakeholder (Auftraggeber) will (Phase der totalen Verwirrung).
Denn, der eine Anwenderkreis arbeitet so und möchte gerne diese Unterstützung und hat eine andere Sicht auf die Dinge wie der andere Anwenderkreis. Und bitteschön, da wir heutzutage nicht mehr kommunizieren können (In der Tat ist die telefonische Erreichbarkeit im Zeitalter von Handys schlechter als früher, da man in Besprechungen nun mal nicht auf Anrufe reagiert), dann bitte automatische Benachrichtigungen. => „Ich habe nichts bekommen, deshalb habe ich nichts gemacht.“ Hmm. Also wieder ein Protokollsystem für das Verschicken der Mails eingebaut. Aha, man kann’s nun beweisen. Wirklich? Wichtig, die Anwender müssen gesteuert werden, damit der Prozess funktioniert (manche verlernen dabei das Denken).
Wichtig in dieser Phase: die ständige Anpassung des Terminplans, die ja am nächsten Tag wegen neuer Anforderungen nicht mehr gilt. An irgendwas muss man ja seine Key Performance Indicators festmachen.
Tja, schon ist es nichts mehr mit dem Motto: „Einfacher ist besser“.
Schön ausgedachte Algorithmen werden nun geändert. Neue kommen hinzu. Die Zeit wird knapper, auch weil man eigentlich fertig werden müsste, aber der Stakeholder nicht mit seinen Vorstellungen und Entscheidungen aus den Puschen kommt und das Budget in der Regel schon durch die Besprechungen aufgebraucht wurde. Also entscheidet die Entwicklung sich für die Notbremse, Vereinfachungen, das Machbare (Phase der totalen Ernüchterung).
Unbestreitbar, nun ist es vorbei mit einer guten Softwarequalität, -strukturierung, – dokumentation,…
Termindruck. Da testet man halt was geht und macht keinen Plan mehr. Hatte man am Anfang zwar mal, ist aber voll agil über den Haufen geworfen worden.
Keyuser Test. Wenn da mal was getestet würde. Keiner hat Lust, keiner hat Zeit. Ausnahmen bestätigen die Regel. Alles ok, wir gehen produktiv.
2 Jahre später oder noch später. Unglaubliche Fehler enthüllen sich. Anwender melden komische Verhaltensweisen. Inzwischen wurden schon viele AddOns entwickelt, sogenannte Rucksäckchen. Neue Abläufe, basierend auf den Dingen der Vergangenheit, realisiert.
Und wer ist schuld? Na, die Software!
Advertisements

Konzepte erstellen

Standard
Konzepte für neue Softwarefunktionalitäten entstehen meistens nicht auf der grünen Wiese und müssen meist vorhandene Daten und bestehende Funktionen nutzen und die bereits vorhandenen Prozesse abbilden.
Zuerst, Erfassung was ist gewollt. Wie ist der Anwenderprozess bisher. Welche Use Cases gilt es zu berücksichtigen. Wer ist der Nutznießer und was macht er z.B. mit den neu entstehenden Datenauswertungen.
Dann Überblick verschaffen, was ist vorhanden, was muss man benutzen, wo entstehen Synergien.
Dann versuchen die Anforderungen auf die Grundlagen und das Bestehende abzubilden. Entwickeln von Verfahrensweisen. Kreieren neuer Anwenderfunktionen in Anlehnung an den bestehenden Prozess.
Nicht vergessen parallel eine Präsentation zu entwickeln. Bitte keine Schlagwortsammlung, sondern viele Bilder und Schemata an denen später etwas erkennbar und nachvollziehbar ist. Keine langen Wordtraktate, Bilder sagen mehr wie tausend Worte.
Und immer einen Sparingspartner suchen, diskutieren, eigene Denkfehler und Manifestationen aufdecken und beseitigen.
Jetzt ist es an der Zeit festzustellen, ob es gegenüber vorher überhaupt einen Benefit gibt und worin dieser genau besteht.
Hier wird man in der Regel feststellen: bisher alles zu kompliziert, an einigen Stellen unlogisch.Hier entstehen dann die neuen Fragen.
Dann gilt es kreativ Vorschläge zu ermitteln. Diese müssen jedoch bei der Präsentation des Konzeptes beim, neudeutsch, Stakeholder abgeklärt werden. Der wird erst mal nicht verstehen, um was es geht und dann dem Gedankengang oft nicht folgen kann. Neue Anforderungen, Fragestellungen entstehen.
Also: Konzept die Zweite, ein weiterer Durchlauf. Irgendwann jedoch kommt der Punkt wo man Mut zur Lücke haben muss. Sonst wird das Konzept nie fertig.

Software lebt ständig

Standard
Sei es während der Entwicklung oder später im Pflegezyklus, einmal entworfener und geschriebener Code ist einem ständigen Wandel unterworfen.
Eine gute Software sollte ja schließlich
  • lesbar sein
  • übersichtlich
  • verständlich und nachvollziehbar
  • erweiterbar
  • auf jeden Fall Redundanzen vermeiden
  • und testbar sein.
Schon in der Entwurfsphase wird der Code einem ständigen Refactoring unterzogen. Allein schon wegen der Lesbarkeit werden Funktions- und Variablennamen umbenannt, wenn sich Sinn und Zweck geändert haben. Schließlich ist die Erstellung von lesbarem Code, der die Wartung erleichtert, das Ziel. Da kein Spaghetticode erstellt werden soll, wird weiter in aufrufbare Funktionen verfeinert. Mehrfachprogrammierung der gleichen Funktionalität ist verboten.
Ähnlich der Modellierung von Prozessabläufen ändert sich ständig der Verfeinerungsgrad. Wie beim Verfeinern von Prozessen werden neue Ausführungsebenen in den Code eingezogen.
Jede Änderung sollte auch mit einem kurzen Inlinekommentar versehen werden. Ebenso sollten anhand von Kommentaren die Abläufe nachvollziehbar sein. Da sich die Software jedoch im Entstehungsprozess ändert, bitte auch die Kommentare nachführen.
Gleichzeitig sollte die Anforderunge(en) so umgesetzt werden, dass zukünftige Änderungen nur lokale Auswirkungen haben und keine anderen Funktionalitäten des Softwarepakets davon betroffen sind. Auch deshalb ist ein ständiger Wandel bei der Realisierung erforderlich.
Zum Abschluss der Realisierung, nach dem erfolgreichen Test, sollten auch alle auskommentierten Codezeilen, die man vorsorglich im Code belassen hat entfernt werden. Das erleichtert später bei der Wartung die Übersicht ungemein.
In der Wartungsphase, bei der Fehlersuche, erkennt man oft Codestellen, die man in eigene Funktionen ausgliedern kann, um die Lesbarkeit zu erhöhen, evtl. um sehr ähnliche, mehrfach verwendete Codezeilen in einer Funktion zu kapseln, damit das Gleiche nur noch an einer Stelle gemacht und somit die Wiederverwendbarkeit des Codes erhöht wird.
Wird die Funktionalität nachträglich erweitert oder geändert, kann es wiederum Sinn machen, vorhandene Variablen und Funktionen umzubenennen. Nichts ist schlimmer, als wenn Code mit der Zeit eine andere Bedeutung bekommt und man sich aufgrund von Benamungen nicht mehr zurecht findet.
Aus Erfahrung kann ich nur sagen, dass man sich an die Regeln halten sollte, die einmal geschriebenen Code auch noch nach Jahren verbessern können. Denn, nichts ist schlimmer als schlecht strukturierten und inline dokumentierten Code Ewigkeiten nach der Entstehung warten und Fehler korrigieren zu müssen.

ZOZ & PARTNER wünscht allen Kunden, Bloglesern und allen anderen, die uns kennen, ein frohes Osterfest…

Standard
Ein Viertel des Jahres ist vorbei. da kann man schon mal wieder ein paar Tage zum Durchschnaufen gebrauchen.
Wir wünschen alle an den Ostertagen viel Entspannung, machen Sie sich keinen Stress, sondern genießen Sie das Zusammensein mit der Familie und/oder Freunden.
Wenn Sie alleine sind, einfach relaxen und ein gutes Buch lesen.