Softwarequalität beginnt mit der Anforderungsanalyse zum System, in unserem Fall mit den Anforderungen für unser ERP-System. Analysieren wir unsere Anforderungen falsch, unvollständig oder gar nicht kann die Qualität unseres ERP-Systems kaum genügend sein. Die Usability, fester Bestandteil von Softwarequalität, wird sich bedingt proportional zu der Integration von Anforderungen durch uns in unser System verhalten. Implementieren wir viele unglaubliche Features die niemand braucht mag und das zwar viel Entwicklungsspaß bringen, bei den Anforderungen haben wir aber klar gepatzt und unsere Usability … ihr ahnt es bereits. Nun hatte ich in meinem letzten Beitrag bereits festgestellt, dass die vollständige Umsetzung aller Anforderungen ein Bestandteil des Qualitätpunktes Anforderungsanalyse ist – ungünstig das die Summe der Anforderungen ein ungesunden Verhältnis zu unserer Arbeitszeit hat.

Ich kann mir nicht helfen, aber in dieser Situation entsteht für uns ein Konflikt. Natürlich wollen wir ein super System bauen und alle Anforderungen der Anwender umsetzen, trotzdem müssen wir mit den vorhanden Entwicklern auch an dem großen Gesamtziel – Gesamtumsetzung ERP-System – hinterher eilen. Vor geraumer Zeit haben wir bereits angefangen zu scrumen.Wir hatten den Vorteil eines agilen Vorgehensmodelles für uns erkannt und kommen alle zwei Woche zusammen um zu beraten welche Punkte umgesetzt werden sollen und was wir für diese Punkte an Umsetzungsaufwandveranschlagen, ganz wie es SCRUM verlangt. Toll, alles super – wir haben einen Plan und nun kann nix mehr schief gehen. Ich muss etwas ausholen um zu meinem Problem zu kommen. Wir setzen unser System modular um und geben einzelne Module nach Fertigstellung zur Nutzung frei. Bereits aktive Module wären Bestellwesen, Stücklistenwesen und 23 weitere Module. Der nächste dicke Fisch ist unser Planungsmodul, geplante Freigabe dieses Jahr. Wir haben also folgende Komponenten: Anforderungsanalyse nach agilen Ansatz betreiben wir, Planung der Aufgaben mit Zeitschätzung und Verbuchung von Zeiten haben wir, einen Haufen cooler freigegebener Module haben wir und ein Ziel für das nächste Modul haben wir auch. Toll.

Irgendwie nicht toll. Etwas gnaschig musste ich jüngst feststellen, dass die gebuchten Stunden zu der Implementierung des Moduls Planung nicht für eine rasche Umsetzung des Moduls sprechen. Wie kann das sein? Das Problem ist die vollständige Umsetzung aller Anforderungen, ihr wisst der Unterpunkt für gute Softwarequalität. Wir investieren soviel Energie in die Abrundung und Verbesserung der freigegebenen Funktionen, dass die Arbeiten für das gänzlich neue Modul nicht fokussiert genug betrieben werden. Fazit: Softwarequalität steht in Konkurrenz zu zügiger Weiterentwicklung. Antwort: Wir müssen nicht nur die Zeiten der Aufgaben schätzen die wir umsetzen wollen, sondern im Vorfeld prozentual festlegen wie viel Zeit wir zum abrunden und weiterkommen aufbringen wollen – na klar, ist einfach, haben wir aber nicht gemacht, haben wir nun aber vor. Ideen sind toll, aber unserer Stammtisch hat gesagt nur kontrollierte Ideen haben eine Chance – der Informatiker würde sagen wir brauchen eine Metrik. Gefühlt können wir uns mit einem einfachen Report helfen, sobald ich was habe reiche ich das nach.

Am Montag ging es in unserer ersten Stammtischrunde um Softwarequalität, loses philosophieren zu der Thematik. Wir haben zahlreiche Ideen diskutiert, scheinbare Ansätze zur Optimierung unserer Softwarequalität entdeckt …aber Moment mal, wie definiert sich in unserem Kontext – Eigenentwicklung eines unternehmenskritschen ERP-Systems – überhaupt Softwarequalität und warum müssen wir das wissen?

„Unterm Strich zählt was rauskommt“ und das bedeutet für uns nicht mehr oder weniger als „wie gut ist unser ERP-System – sprich wie gut ist unsere Arbeit, den unsere Arbeit ist der Bau des Systems „. Ein wenig Google geschüttelt kommen Erinnerungen zu vergangen Softwarevorlesungen hoch, ein Haufen DIN’s und ISO’s beschreiben jargontypisch um was es bei Softwarequalität geht, um was es geht wenn wir gute Arbeit machen wollen. Am Stammtisch können wir philosophieren, aber in einem Disput ob ich gute oder schlechte Arbeit mache hätte ich lieber harte Fakten, Zahlen in der Schublade – zur Not für einen selbstangesetzten Schulterklopfer. Ich würde gerne frühzeitig bemerken, dass unsere Arbeit nicht mehr gut ist und möglichst exakt sehen wo anzusetzen ist. Nun entsteht eine Kausalkette: Wir wollen ein gutes ERP-System => dazu muss die Qualität unglaublich gut sein => dies müssen wir stetig messen => und optimieren.

Konkrete: Wie definiert sich unsere Softwarequalität, wie messe wir diese Qualität stetig und wie setzen wir die Erkenntnisse in Ergebnisse um? Bevor ich mir Gedanken zum tracken, benchen und aufzeichnen mache folgend eine lose Sammlung was für uns Qualität ist – Unvollständigkeit garantiert.

Ich habe das Gefühl es ist sinnig, wenn ich diese erste Idee unserer Qualität in ein Schaubild bringe und mir Gedanken zu Tools und Verfahren mache, wie wir diese Qualität bei uns in Zahlen ausdrücken, wie die Zahlen aussehen und wie wir die Zahlen nach oben bringen.

Vergangenes Jahr hatte ich auf der IPC09 die Möglichkeit mit Pierre Joye über die Hardware unsers ERP-System in der Firma zu sprechen – ein fluschiger Webserver mit PHP. Ergebnis: Unsere Hardware gleicht der Kasse im Lidlmarkt. Ganz so vernichtet war das Diskussionsergebnis faktisch zwar nicht, trotzdem Anlas genug für uns neue Hardware zu beschaffen. Neue Hardware sollte in der Regel immer besser sein, spannend ist die Frage wie viel besser und ob die Anschaffung wirklich sinnvoll oder gar nötig war.

Alter Server: Win2008 R2 Server, IIS 7.0, PHP 5.3.2 mit Wincache, Xeon 5140 2,33 GHz, 3 GB RAM

Neuer Server: Win2008 R2 Server, IIS 7.5, PHP 5.3.2 mit Wincache, Xeon E5530 2,4 GHz, 16 GB RAM

Die Konfiguration der beiden Server ist identisch ebenso die Anbindung an die selbe Datenbank. Für einen ersten Vergleich habe ich mir eine Seite aus dem ERP-System ausgesucht die ich mit JMeter unter Last gesetzt habe. Ich habe dabei eine variierende Benutzerzahl von 10 bis 50 simuliert, diese führen 10x alle 3sec die gleiche Anfrage aus. Im Ergebnis kann man sehen welche Benutzerzahlen die Webserver gleichzeitig bei Interaktion verkraften können oder anders gesagt was ein Web- und was ein Kassenserver ist.

ist.

Fazit: Die neue Hardware bringt eine Steigerung um Faktor 10 beim Datendurchsatz. Der alte Server ist bereits bei einer Benutzerzahl von 10 Personen mit seinem Durchsatz am Limit, während der neue Server immerhin min. bis zu 60 Benutzer gut handeln kann bevor der Durchsatz stagniert – mehr Benutzer kann ich leider mit einem Client nicht simulieren. Auf einem Webserver mit 3 GB RAM sind mehr als 8 CGI Instanzen nach dem Test nicht zu empfehlen, dies führt eher zu schlechteren max. Responsezeiten. Für den neuen Server habe ich momentan 32 für die max. CGI Instanzen eingestellt, ich werde später noch detaillierterer auf die Einstellungen des Webservers eingehen. Bleibt nur zu sagen, gut das wir einen neuen Server gekauft haben – ich habe nur die Testergebnisse veröffentlich die zur einer sinnigen Erkenntnis führen.