Softwarearchitekturen einmal anders gesehen

Standard

Im Internet gefunden. Hat mir sehr gefallen.

Man kann sich natürlich auch beliebige Kombinationen vorstellen. Z.B. Lasagne mit Spaghetti Schichten. Soll durchaus auch heute noch bei manchen Entwicklern üblich sein.

Advertisements

Über die Kunst Software anwendergerecht zu testen

Standard
Es gibt sie, die Anwender mit den „goldenen“ Fingern. Alles ist fertig. Die Software ist getestet und abgenommen. Dann passiert’s. Die Anwender klagen über Fehler. Der Kundenbetreuer ist verzweifelt, der Projektleiter wütend über die Entwickler, die Entwickler verstehen das nicht. Geht doch alles.
Woran liegt’s, das ist hier die Frage.
Oder doch nicht? Lag’s nur am Softwareerstellungsprozess?
Muss: der Anwender-Stakeholder beschreibt vor Beginn der Implementierung zusammen mit dem Softwareprojektleiter was rauskommen soll. D.h., Anwenderprozess, Use cases. Was soll an Bedienung möglich sein, was nicht. Der Softwareprojektleiter achtet auf das „Außenherum“ und macht den Stakeholder auf Abhängigkeiten und Einschränkungen aufmerksam.
Muss: der Softwareprojektleiter gibt dem Entwickler die Beschreibung weiter, ergänzt und erläutert diese. Weißt auf Abhängigkeiten hin. Prüft, ob der Entwickler das verstanden hat. Er definiert Tests, die eine Verifikation der Realisierung der neuen Anforderung zulassen.
Muss: Code review mit einem erfahrenen Entwickler. Der Ersteller des neuen Codes erklärt, was dieser tun soll.
No go: der Entwickler checkt sein Werk ein. Es compiliert ja.
Muss: der Entwickler testet, dass das, was er entwickelt hat, prinzipiell geht.
Herausforderung: Automatisierung von Tests zur Minimierung des Aufwandes und für Nachvollziehbarkeit. Interne Algorithmik gerne mit Unit Tests. Die müssen allerdings vor der Implementierung geschrieben sein und auch verifiziert werden. Sonst nutzen sie dem Entwickler nichts. Anwenderprozesse, schwierig. Aufgezeichnet über Makros. Zwar nachvollziehbar, aber sie können nicht die Umgebung und die Kreativität von Anwendern abbilden. Daher aufwendig und weniger brauchbar.
No go: nur der Entwickler testet. Denn, der weiß, welche Algorithmik er programmiert hat und deshalb testet er nur auch den Weg, der funktioniert.
Muss: Test durch einen Softwaretester. Der Projektleiter erklärt die Anforderung und die Use Cases, sowie die Abhängigkeiten und in welchen Prozess beim Kunden das Ganze eingebettet ist. Ebenso übergibt er die Liste der definierten Tests. Der Softwaretester verifiziert an Hand der Tests und muss dann in einem begrenzten Zeitraum versuchen, mögliches und unmögliches zu tun, um Fehler zu provozieren. Alles sollte nachvollziehbar dokumentiert werden.
No go: Damit wird die Software für die produktive Umgebung freigegeben.
Muss: Anwendertest mit echten Endkundenanwendern auf einem Testsystem. Beurteilung der Bedienbarkeit und testen durch ganz normales Arbeiten.
No go: Anwender testen nicht, weil zu mühsam, keine Zeit, keine Lust, eh unnötig.
Muss: alle Beteiligen (Stakeholder, testende Key User, Projektleiter Softwaretester) müssen aus ihrer Sicht das Go geben.
Ergebnis: einen Monat später Fehlermeldung durch Anwender im fernen Timbuktu. Feststellung Daten korrupt. Nicht erklärbar, oder doch. Andere Länder, andere Denkweisen. Wurde leider nicht in den Key User Test einbezogen. Hat ganz andere Vorgehensweise. Wurde im Test nie überprüft und genau da sitzt der Bug.

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.

Software … ein gutes Stück Handwerk

Standard
Immer noch hat der Softwerker den Geruch des Nerds, des freien Künstlers, des Geistesarbeiters, desjenigen, der nie eine Aussage treffen wird, wann eine gestellte Aufgabe denn fertig sein wird.
Doch das hat sich gewandelt und wandelt sich immer weiter.
Softwerker sind immer mehr spezialisierte Handwerker, die ihre Werkzeuge gut kennen müssen, die die Bereiche verstehen müssen in denen SIe arbeiten, die eine Aufgabe selbständig abklären und einfach abarbeiten können müssen.
Der selbstverliebte Programmierer, der der sich nur um seinen Code kümmern und nicht die zu lösende Aufgabe verstehen will und damit keine Verantwortung für eine gute Anwenderlösung übernehmen will, der ist out.
Viele der in Programmen versteckten Fehler, viele Misserfolge von Softwareentwicklungen sind, meiner Meinung nach, darauf zurückzuführen, dass etwas spezifiziert und einfach auch so umgesetzt wurde, wie die einzelnen Realisierungshäppchen spezifiziert waren. Aber Spezifikateure machen auch Fehler, bedenken nicht alles und sehen manche Randaspekte nicht, die sich erst bei der eigentlichen Softwarerealisierung ergeben. An dieser Stelle ist der Softwerker gefordert. Wenn ihm etwas auffällt, das  er nicht versteht, hat er nachzufragen, abzuklären, eigenständig einen Vorschlag zu machen.
Ein Softwerker erfasst die Aufgabe. Beschreibt vor dem Tun seine Vorgehensweise, kommentiert seinen Code, verwendet eine Quellcodeversionierung, dokumentiert die Abläufe der entstandenen Funktion. Und, ganz wichtig, er ist kein einsamer Wolf, er kommuniziert mit dem Team und trifft Entscheidungen zusammen mit dem Team.
Zumindest bei einer Firmengröße wie der unsrigen, mit den komplexen Aufgabenstellungen, die wir haben, ist die Grundeinstellung, ein Handwerker, ein Softwareingenieur zu sein, unabdingbar für den Erfolg unserer Projekte.
Und so ist es nicht verwunderlich, dass es, ähnlich den Handwerkskammern, auch eine Vereinigung von handwerklich guten Softwerkern, die Softwerkskammer, gibt. https://www.softwerkskammer.org

Alles zu kompliziert !

Standard
Meine Kollegen lachen schon, wenn ich mal wieder sage, alles zu kompliziert. Oder stimmt das etwa nicht? Machen wir uns das Leben oft nicht unnötig schwer, weil wir zu kompliziert denken? Sicher, die Dinge sind komplex, aber nicht unbedingt so kompliziert wie wir sie machen. Und das betrifft nicht nur uns Softwerker.
Es fängt schon an, man denkt um die Ecke. Man weiß es ja besser, eigentlich sollte man bevor man Software schreibt erst einmal den Anwendungsprozess, der sich aus den Anwendungsfällen ergibt, erst einmal aufschreiben. Leider sind die Anwendungsfälle oftmals schon nicht durchdacht und daher zu kompliziert.Tipp: man darf dem Anwender durchaus auch mal sagen, dass er zu kompliziert arbeitet und es vielleicht leichter geht.
Dann sollte man sauber die benötigten Datenstrukturen definieren. Danach eine saubere Softwarestruktur. Grob den Anwendungsprozess in diese Struktur hineinalgorithmisieren (tolle Worterfindung) und dann noch mal darüber schlafen (wichtig!).
Bei all dem sollte man nicht zu kurz denken. Oft macht man sich das Leben schwer, weil man irgendwas, z.B. Datenmengen, von vorne herein optimieren will. Schade, leider wird dadurch der Code komplizierter, weil die Sonderfälle nun zu berücksichtigen sind. Er wird schwerer verständlich, zumal wenn schon ein bisschen Zeit vergangen ist. Jede weitere Änderung birgt Fehlerquellen und Mehraufwände. Dann ist wegen „zu kurz gedacht“ eben alles viel zu kompliziert.
 Drum, alles erst mal möglichst einfach machen. Mut zur Lücke.

Entwicklungsintegration von Product Stakeholder und Product Owner / Development mittels TFS und Sharepoint

Standard

Am Anfang stand die Einführung des Team Foundation Servers, a) um unseren Quellcode besser verwalten zu können und b) das Projektmanagement mit SCRUM besser unterstützen zu können.

Dadurch wurde auch die Sharepointwelt für uns eröffnet und die Idee kam auf, diese als Plattform zur Zusammenarbeit mit unseren Kunden zu benutzen. Es bietet sich einfach an Requirements und Bugs (im TFS, Oberfläche Sharepoint) gemeinsam zu sammeln, zu beurteilen und dem Kunden die Möglichkeit zu geben, direkt einen Überblick über den Fortschritt der Realisierung zu erhalten. Genauso können wir darüber Dokumentationen teilen.

Voraussetzung, dass das Zusammenarbeiten klappt, ist eine site to site VPN Verbindung, die die Netzwerkverbindung zwischen uns und dem Kunden ermöglicht und die auf beiden Seiten die Netzwerke gegen einen Zugriff außerhalb der Sharepointwelt schützt. So ist z.B. unser TFS für den Kunden nicht erreichbar. Die Entwicklungswelt bleibt unsere Angelegenheit.

OP2_TFS_SharepointAuch innerhalb Sharepoint kann man über die Verrechtung den Zugriff auf nicht öffentliche Bereiche, die nur die Entwicklung betreffen, einschränken.

So gibt es einen Bereich auf den das gesamte Projektteam bestehend aus Kundenmitarbeitern und ZOZ & PARTNER Mitarbeitern zugreifen kann.

OP2_TFS_Sharepoint_2Und einen Bereich nur für ZOZ & PARTNER.

OP2_TFS_Sharepoint_3Die gemeinsamen Sharepointseiten ermöglichen es so, dem Kunden, neue Anforderungen direkt in einer Liste in Form von Product backlog items zu sammeln (unser Kunde nennt diese Anforderungen TCR (tool change request).). Diese Sammlung wird in regelmäßigen Meetings durchgesprochen. Jedes dieser Items dürchläuft einen Prozess. Es wird vorab bewertet, qualifiziert, zur Abschätzung freigegeben, beauftragt, realisiert und schließlich in Betrieb genommen. Eine Anforderung kann aber auch zurückgestellt oder gar abgelegt werden.

OP2_TFS_Sharepoint_4Um diese Beurteilungen zu treffen existiert ein gemischtes Team aus Stakeholdern und ZOZ & PARTNER Mitarbeitern, die die Anforderungen gemeinsam miteinander diskutieren.

Ebenso werden über diese Methode die einzelnen Programmupdates geplant und es wird dokumentiert welche backlog Items mit dem Update produktiv gesetzt wurde.Newsletter, die für jedes Update an den Kunen gehen, werden über die Informationen im backlog item erzeugt und als Datei zusätzlich im Sharepoint abgelegt.

Somit ist über die Datensammlung im TFS + Sharepoint die Historie der Produktentwicklung auch für den Kunden jederzeit einsehbar und aktuell.