Softwarequalität unseres ERP-Systems

Softwarequalität unseres ERP-SystemsAm 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.

Qualitätspunkt detailliert Messmöglichkeiten
Anforderungsanalyse
  • Vollständigkeit der Anforderungsumsetzung
  • Umsetzungsgeschwindigkeit von Anforderungen
  • Wartbarkeit, Möglichkeit von Funktionserweiterung
Dokumentation
  • Dokumentation von Funktionsumsetzung
  • Hilfe
  • Dokumentation von Code, CodeDoc
  • Codereview
  • Comments im Verhältnis zu LOC
  • Doku im Verhältnis zu LOC
  • Hilfe im Verhältnis zu LOC
Performance
  • Gesamtperformance des Systems
  • Antwortverhalten je DB Transaktion
  • Performance im Verhältnis zu Anwendern
  • Renderingperformance
  • Antwortverhalten je Transaktion
Usability
  • Anwender kommen einfach an Infos
  • Zuverlässigkeit des Systems
Fehler
  • Fehler auf Datenbankebene (Oracle)
  • Fehler auf Codeebene (PHP)
  • Oberflächenfehler, eventuell in der Darstellung (HTML)
  • Javascriptfehler
  • Reports (BI-Publisher)
  • Fehler pro Zeiteinheit

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.

Dieser Beitrag wurde unter Softwareentwicklung veröffentlicht. Setze ein Lesezeichen auf den Permalink.

Die Kommentarfunktion ist geschlossen.