QS-Methoden und Grundlagen
QS-Ansätze sind frühzeitig in einem Projekt einzuplanen, damit Zeit und Geld in der Planung berücksichtigt werden. Grundsätzlich gibt es sehr unterschiedliche Maßnahmen, mit denen man bestimmte Qualitätsaspekte betrachten kann. Sehr allgemein kann man von Maßnahmen sprechen, die bereits in der Entwicklung berücksichtigt werden, dazu gehören Vorgaben für den jeweiligen Entwicklungsschritt (sogenannte konstruktive QS) und Maßnahmen, die ergriffen werden, wenn ein Produkt bereits erstellt wurde, dazu gehört das Testen (sogenannte analytische QS). Weitere Klassifizierungen der QS-Maßnahmen sind möglich, wie es z. B. in [Lig02] oder [Hof08] gezeigt wird, wo auch einige der genannten Verfahren noch genauer vorgestellt werden. Eine besondere Rolle nehmen formale Ansätze ein, die meist konstruktive und analytische Anteile eng verbinden.
Die folgenden Links verweisen auf detailliertere bzw. weiterführende Beschreibungen zu den einzelnen Maßnahmen und geben Informationen zu den Grundlagen der dahinter liegenden Ansätze.
Konstruktive Qualitätssicherung
- Guidelines: Vorgaben für die Erstellung von bestimmten Produkten, wie Quell-Code und Dokumentation
- QS-Planung: Berücksichtigung von Planungs- und Schulungsanforderungen zum systematischen Einsatz von QS-Maßnahmen
Analytische Qualitätssicherung
- Funktionale Tests: Ansätze zur Prüfung, ob ein in Entwicklung befindliches System die geforderte Funktionalität liefert
- Äquivalenzklassenanalyse: Ansatz zur systematischen Auswahl möglichst weniger Testfälle, die möglichst viele potenzielle Fehler aufdecken können
- Überdeckungstests: Ansätze zur Prüfung, ob bestimmte Anweisungen, Ablaufpfade oder Boolesche Bedingungen garantiert in Testfällen berücksichtigt werden
- Prüfung sogenannter nicht-funktionaler Anforderungen:
- Performance-Analyse (Lasttest): Prüfung, ob ein in Entwicklung befindliches System auch unter bestimmten Lasten die erwartete Reaktionsgeschwindigkeit beibehält
- Speichernutzung: Prüfung, ob ein in Entwicklung befindliches System auch unter bestimmten Lasten Grenzen für die maximale Speichernutzung beibehält
- Codequalitätsanalyse durch Metriken: Berechnung von speziellen Kennzahlen einer Software, um Indikatoren für die Qualität des Programmcodes hinsichtlich Wartbarkeit und Änderbarkeit zu erhalten
- Usability-Prüfung: Analyse, ob ein in Entwicklung befindliches System nutzbar ist
- Manuelle Prüfverfahren: Menschen prüfen (Teil-)Produkte eines in Entwicklung befindlichen Systems nach bestimmten Kriterien, die typischerweise nicht automatisch geprüft werden können, wie z. B. die Lesbarkeit von Dokumenten und die vollständige Umsetzung von Anforderungen
Formale Entwicklung
- Modelchecking: Zunächst wird ein Modell des zu entwickelnden Systems in einer Modellierungs- oder Programmiersprache erstellt, dann werden die Anforderungen an das System in einer Anforderungssprache, einer passenden Logik, formalisiert. Danach kann ein Modelchecking-Algorithmus vollautomatisch prüfen, ob das Modell die Anforderungen erfüllt. Das so verifizierte Modell kann dann in weiteren Entwicklungsschritten genutzt werden.
- Verifikation: Wieder werden ein Modell des zu entwickelnden Systems und die Anforderungen in einer Logik erzeugt. Die Überprüfung erfolgt dann durch die Anwendung von Verifikationsregeln, mit denen schrittweise versucht wird, zu zeigen, dass das Modell die Anforderungen erfüllt. Mit diesem Ansatz können wesentlich mehr Anforderungen als mit dem Model-Checking nachgewiesen werden, allerdings ist der Aufwand typischerweise wesentlich höher und benötigt sehr viel Erfahrung. Das so verifizierte Modell kann dann in weiteren Entwicklungsschritten genutzt werden.
- Generierung: Es wird ein abstraktes Modell des zu entwickelnden Systems geschrieben. Für dieses Modell wird mit unterschiedlichen Test- oder Verifikationsansätzen geprüft, dass die geforderten Eigenschaften vorhanden sind. Danach wird das Modell mit teilweise auch im Projekt zu entwickelnden Transformationsregeln in ein weniger abstraktes Modell, z. B. direkt ein ausführbares Programm, übersetzt. Diese Transformation kann in mehreren Schritten passieren, wobei Konkretisierungen z. B. in der Wahl des Betriebssystems, der Infrastruktur, der Programmiersprache und der Persistenz-Verwaltung bestehen können. Typische Vertreter sind die Model Driven Architecture (MDA) und das verwandte Model Driven Software Development (MDSD).
Zurück zur CSI-Hauptseite