Guido Rosenbaum - ICT - Service Management - "Beta"

Die Betrachtung der Qualität von Software erfolgt aus zwei Sichtweisen:

1. Der externen Sicht durch den Anwender

Korrektheit:

• - löst Aufgaben richtig und das Software-System verhält sich wie in der Anforderungsdefinition (muss exakt und vollständig sein)

Zuverlässigkeit:

• - Software ist zuverlässig, wenn sie meistens funktioniert.

Maßeinheiten:

• - ROFOC (Rate of Failure Occurrence) Anzahl der Fehler in einer bestimmten Zeiteinheit z.B. 3 Fehler/Stunde
• - MTBF (Mean Time Between Failures) durchschnittliche Zeitabstand zwischen zwei Fehlern
• - Verfügbarkeit (Availability) durch Vefügbarkeit der Software z.B. 99% oder 99 von 100 Minuten; Software die 100% zuverlässig ist es nicht! Keine Software ist 100% fehlerfrei, auch wenn sie 100% der Anforderung entspricht.

Robustheit:

• - Software muss auch unter unvorhergesehenen Umständen weiter funktionsfähig sein. Dazu wird eine Ausnahmebehandlung (Exception Handling) verwendet.
• - Maßnahmen:
•     - Abfangen von eindeutig falschen Eingaben
•     - Hinweis auf fehlende Daten
•     - Plausibilitätsprüfungen
•     - Sicherheitsabfragen
•     - Automatisches Speichern von Daten
•     - Funktion zum Rückgängig-Machen und Wiederherstellen von Aktionen
•     - Vorgänge in Transaktionen zusammenfassen

Vertrauenswürdigkeit:

• - keine Schäden verursacht, auch wenn Fehler auftreten
• - Software muss nicht korrekt sein
• - korrekte Software muss aber nicht vertrauenswürdig sein (zB. Fehler in der Anforderungsdefinition)

Benutzerfreundlichkeit: 

• - Software muss vom Anwender schnell erlernt und einfach benutzt werden
• - Bedienung sollte möglichst selbsterklärend sein
• - Bedienung muss sich an den Erwartungen des Anwenders orientieren
• - Programm muss unterschiedliche Anwendergruppen berücksichtigen; Dazu gehört auch Zuverlässigkeit, Robustheit und Effizienz

2. Die interne Sicht durch den Entwickler

Wartbarkeit:

• - Möglichkeit der schnellen Korrektur und Änderung durch Dritte
• - Aufteilung der Software in kleine Teile
• - Eine detailierte und nachvollziehbare Dokumentation
• - Verbindliche Programmierrichtlinien, die ein schnelles Verstehen des Quellcode ermöglichen
• - Klares definiertes Änderungsmanagement – „Wer hat wann welche Änderungen in dem Programm vorgenommen?“

Wiederverwendbarkeit:

• - einzelne Teile für neue Software wieder verwenden
•       (Verwendung von vorgefertigten Komponenten nennt man Rapid Application Development (RAID))
• --> Vorgefertigte Funktionen und Klassenbibliotheken können in ein Programm eingebunden werden

Portabilität:

• - soll sicherstellen das ein System auf möglichst vielen unterschiedlichen Umgebungen eingesetzt werden kann
•       Umgebung = eingesetzte Hardware + Software mit der das System zusammenarbeitet
• - Systemteile, die von der Umgebung abhängig sind, vom Rest des Systems trennen. Diese Teile verfügen über Schnittstellen zum System und müssen im besten Fall nur getauscht werden. Z.B. Datenbankschnittstelle
• - Zumeist ist kurzfristig mit mehr Aufwand zu rechen der sich später bezahlt macht !!!!

Effizienz:

• - das System muss in der Lage sein die Aufgaben in der verfügbaren Zeit aus zu führen
• - das System sollte über möglichst kurze Antwortzeiten verfügen
• - wenn möglich und sinnvoll Aufgaben in mehrschichtigen Architekturen verteilen z.B. Client-Server-Architektur, MVC 
• - in Simulatoren lässt sich die Effizienz einer Software messen
• - Zeitkritische Funktionen lassen sich mit Profilern finden
• effiziente Herstellung: 
•     - Software möglichst schnell mit wenig Mitarbeitern erstellen 
•     - Einsatz von Generatoren die einen Teil der programmier Handarbeit abnehmen z.B. UML Klassendiagramm nach C#
•     - Die Produktivität eines Programmierers lässt sich nicht an den Zeilen Programmcode messen die er am Tag erstellt