IT Methoden und Werkzeuge

Softwarequalität nach ISO 9126 (ISO 25000): Softwarequalität ist die Gesamtheit von Funktionen und Merkmalen eines Softwareprodukts, das die Fähigkeit besitzt, angegebene oder implizierte Bedürfnisse zu befriedigen.

Die Erfüllung von Qualitätszielen, die durch Vorgaben für Qualitätsmerkmale und ihre Teilmerkmale definiert sind

• Qualität ist der Grad, in dem von einem Satz inhärenter Merkmale (eines Produkts) die Anforderungen erfüllt werden. (DIN EN ISO 9000:2005)

• Qualitätsmerkmale beziehen sich auf Anforderungen

– Funktionale Anforderungen (Fachlichkeit, Funktionen, Schnittstellen, ...)

– Nicht-Funktionale Anforderungen (Qualitäts- und Realisierungsanforderungen, Projektspezifische Anforderungen, ...)

Gebrauchsqualität: Betrachtung von Merkmalen, wenn das Produkt von einem Endbenutzer in dessen Umgebung benutzt wird.

Produktqualität:

Intern: Betrachtung von Merkmalen des isolierten Produkts, ohne dass es ausgeführt wird, z. B. Untersuchung von Quelltext.

Extern: Betrachtung von Merkmalen, wenn das Produkt ausgeführt wird (in einer definierten Umgebung), häufig basierend auf Tests.

Prozessqualität: Betrachtung von Merkmalen des Entwicklungsprozesses, der bei der Entstehung eines Produkts geplant, durchgeführt und kontrolliert wird.

Factors-Criteria-Metrics (FCM) Qualitätsmodelle:

Hierbei werden für das abstrakte Qualitätskonzept zunächst eine Anzahl von Merkmalen(engl. „factors“) identifiziert, die verschiedene Seiten des Qualitätsbegriffs konkreter machen. Dann werden für jedes dieser Merkmale einige Teilmerkmale (engl. „criteria“) aufgelistet, um es weiter zu konkretisieren. Der letzte Schritt der FCM-Methode ist die Bestimmung von Metriken für jedes der Teilmerkmale, die unmissverständlich definieren, wie für den zu untersuchenden Gegenstand festgestellt werden kann, inwiefern ein hinsichtlich seiner Qualität zu überprüfender Gegenstand die aus einem Qualitäts-Teilmerkmal erwachsenden Anforderungen erfüllt.

Goal-Question-Metric Methode

Kernidee des Konzeptes sind drei Schritte hin zur Messbarkeit von Arbeitsergebnissen und zur Bewertung von Effekten:

1.    Definition des Ziels (Goal)

2.    Definition von Fragen, deren Beantwortung aussagt, ob das Ziel erreicht wurde (Questions)

3.    Definition von Metriken, die eine messbare Beantwortung der Fragen darstellen (Metrics)

Wichtig ist hierbei den Top-Down Ansatz zu verfolgen und sich zuerst klar zu machen, welches Ziel man eigentlich mit seiner Evaluierung verfolgt und wie man dieses durch Fragen genau definieren kann. Alles andere würde zu unnötigen Messungen / Metriken führen, die bestenfalls mit sehr viel Aufwand nachträglich interpretiert werden müssen, oder schlimmstenfalls komplett überflüssig sind.

Nehmen wir an unser Ziel sei

§  "Die Erstellung von Palladio Modellen zu verbessern".

Eine mögliche Frage wäre zum Beispiel:

§  "Wurde der manuelle Aufwand zur Erstellung reduziert?"

Mögliche Metriken wären nun:

§  "Anzahl der Mausklicks zur Erstellung einer Komponente"

§  "Laufzeit des Editors auf einem Referenzsystem, bis eine Komponente gezeichnet wurde"

Best Practices

·         Entwurf nach Zuständigkeit: Jede Klasse, jedes Package, jedes Subsystem, jede Schicht sollte für eine klar definierte Aufgabe zuständig sein.

·         Prinzip der Verschwiegenheit

·         Große Einheiten vermeiden: Gleichmäßig große Klassen, Packages, Methoden

·         Kopplungsgrad: (Bottlenecks vermeiden und prüfen ob Objekte loose gekoppelt sind?

·         Komponentenabhängigkeit prüfen

·         Zyklen zwischen Klassen, Packages Subsysteme und Schichten vermeiden

Entwurfsmuster

Muster beschreiben wiederkehrende Entwurfsprobleme und bewährte Lösungen und helfen

·         die Komplexität zu verringern durch Einteilung des Systems in Subsysteme

·         Erleichterung der Benutzung durch Minimierung der zu handhabbaren Objekte

·         Minimierung von Kommunikation und Abhängigkeiten – lose Kopplung

·         ermöglicht Änderung an Subsystemen ohne Neuübersetzung des Gesamtsystems

Bsp: Model View Controller, Factory, Fassade, Repository

Architekturstile

Beschreiben den Gesamtaufbau gleichartiger Softwaresysteme. Dadurch das wiederkehrende Entwurfsprobleme gelten, bildet sich eine Muster zum Bauen der Software à Architektur

Ein Architekturstil ist eine prinzipielle Lösungsstruktur, die für ein Softwaresystem durchgängig und i.d.R ohne Ausnahmen angewandt werden soll. Sie beschreiben die grundliegende Organisation und Interkation zwischen der Komponenten der Anwendung

Bsp: SOA, Client Server, Schichtenarchitektur

Für die Erstentwicklung eines Software-Systems ist eine durchgängige und klare Architektur vorgegeben, die größtenteils auch so implementiert wird. Jedes Software-System wird jedoch in seinem Lebenszyklus erweitert, gewartet und von Fehlern befreit. Dabei wird immer weniger auf die Architektur geachtet, beispielsweise, weil neue Personen mit der Entwicklung betraut werden. Es entsteht eine wachsende Kluft zwischen der gewollten Architektur und der Implementierung. Dieser Prozess des Verfalls der Struktur wird auch Architekturerosion genannt.

Architektur-Erosion macht sich nur durch ihre Symptome und Auswirkungen bemerkbar:

·         Steigende Entwicklungskosten,

·         höherer Testaufwand,

·         längere Entwicklungszyklen,

·         steigendes Projektrisiko

·         Verdeckte Abhängigkeiten führen zu Seiteneffekten

·         die Architekten sich kontinuierlich weiterbilden

·         Automatische Tests und Refactoring durchgeführt werden

·         die Codierrichtlinien, Architekturprinzipien und Architekturstile eingehalten werden

·         Definition einer Zyklen-freien logische Architektur und einer konsistente Package Namenskonvention. Alle Packages müssen logischen Architekturelementen zugeordnet werden.

·         Keine Zyklen zwischen Packages

·         Kontrolle des Kopplungsgrades

·         Beschränkung der Größe von Java Sourcen (700 Zeilen)

·         Beschränkung der Zyklomatischen Komplexität von Methoden (z.B. 20)

·         Regelmäßige, automatische Überprüfung der Regeln Qualität muss als Zielvorgabe von allen Managementebenen mitgetragen werden!

·         Regelmäßige Architekturanalysen, Analyse Tools:

o   Lattix

o   Axivion Bauhaus

o   SotoArc und Sotograph

Structure 101

Grundsatz 5

Tests nur zu wiederholen, bringt keine neuen Erkenntnisse. Testfälle sind zu prüfen, zu aktualisieren und zu modifizieren.

Wird ein Test lediglich wiederholt, bringt dies keine neuen Erkenntnisse. Zur Veranschaulichung kann man sich folgendes Beispiel vorstellen:

Getestet wird ein Feld „Geburtstagsdatumseingabe“

Nun wurde in einer frühen Phase ein Test entwickelt, der nach Eingabe des Geburtsdatums das Alter der Person ausgibt. Dies hat auch funktioniert.

Nun haben die Entwickler weiterentwickelt und haben „Ränder“ zur Eingabe des Datums festgelegt.

Würde nun der Gleiche Testfall von vorher durchgeführt werden, bringt dies keine neuen Erkenntnise.

Es muss nun ein modifizeriter Testfall angewendet werden, der tatsächlich die Randgebiete des Datumfeldes überprüft.

Grundsatz 7

Ein System ohne Fehlerwirkungen bedeutet nicht, dass das System auch den Vorstellungen der späteren Nutzer entspricht.

Dies ist wahr. Da nur, weil ein System korrekt funktioniert, impliziert dies nicht, dass z.B. auch die Graphische Oberfläche tatsächlich so aussieht, wie der Nutzer sich das vorstellt.

Die Teststufen leiten sich aus dem V-Modell ab und stellen Tests zu den jeweiligen Konstruktionsphasen.

Eingeplant werden sollten:

-       Komponententest

-       Integrationstest

-       Systemtest

-       Abnahmetest