IT Methoden und Werkzeuge

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

Komponententest:

Im Komponenten werden die erstellten Softwarebausteine unmittelbar nach der Programmierphase erstmalig einem systematischen Test unterzogen.

Es wird überprüft, ob jede Komponente die Vorgaben seiner Spezifikation erfüllt.

Testziel dieser häufig durch den Softwareentwickler selbst durchgeführten Tests ist der Nachweis der technischen Lauffähigkeit und korrekter fachlicher (Teil-) Ergebnisse.

Integrationstest:

Testet die Zusammenarbeit voneinander abhängiger Komponenten (wie im technischen Systementwurf vorgesehen).

Die Gruppe von Komponten werden vom Team zu größeren Teilsystemen zusammengefügt und anschließend wird überprüft ob die einzelnen Teile korrekt zusammenspielen.

Das Ziel des Integrationstest stellt das Auffinden von Fehlern in Schnittstellen und im Zusammenspiel der Komponenten dar.

Systemtest:

Der Systemtest überprüft,  ob die spezifizierten Anforderungen vom Produkt erfüllt werden.

Der Systemtest ist die Teststufe, bei der das gesamte System gegen die gesamten Anforderungen (funktionale und nicht funktionale Anforderungen) getestet wird. Gewöhnlich findet der Test auf einer Testumgebung statt und wird mit Testdaten durchgeführt.

- Perspektive des Kunden und des späteren Anwenders.

Abnahmetest

Prüft, ob das System aus Kundensicht die vertraglich vereinbarten Leistungsmerkmale aufweist.

Vor Inbetriebnahme der Software, hierbei stehen die Sicht und das Urteil des Kunden bzw. Anwenders im Vordergrund. Der Abnahmetest ist unter Umständen der einzige Test, den der Kunde nachvollziehen kann oder an dem er direkt beteiligt ist. Der Abnahmetest ist eine spezielle Form des Systemtests. Der Abnahmetest wird beim Kunden durchgeführt.

1.       Fehlermanagement

2.       Konfigurationsmanagement

3.       Testplanung

4.       Testdurchführung

5.       Testdatengenerierung

6.       Testanalyse und –design

Der Product Owner trägt die Verantwortung für das Produkt und bestimmt demnach auch, welche Anforderungen umgesetzt werden müssen. Hierzu legt er priorisiert seine Anforderungen in den sogenannten Product Backlog ab.

Sprich hoch priorisierte sind ganz oben und werden in der nächsten Iteration umgesetzt, niedrig ranginge werden womöglich nie oder erst sehr spät umgesetzt.

Der Product Backlog  ist dynamisch und nie vollständig, da ständig Anforderungen hinzukommen oder wegfallen oder neu priorisiert werden.

Die Zuordnung der Anforderungen an die einzelnen Iterationen erfolgt in sogenannten Sprint Planning Meetings. Hier werden die Anforderungen ausgewählt, die Teil des nächstens Sprint Backlogs werden sollen. Der Product Owner bestimmt dabei, welche Anforderungen (die mit der höchsten Priorität im Product Backlog) umgesetzt werden sollen und das Team entscheidet wieviele es in der Iteration schaffen kann. Dies erfolgt auf Basis sogenannter Story Points, welche die Komplexität einer User Story abbilden. Nach einer gewissen Zeit, hat das Team ein gutes Gefühl dafür entwickelt 1.) Die Story Points korrekt zu schätzen und 2.) Wieviel Story Points in einer Iteration zu erreichen sind.

Skript:

Das Team findet heraus wie Anforderungen in ein Inkrement von Funktionaliätn eingeteilt werden und die Umsetzung erreicht wird.

Der Scrum Master ist dafür verantwortlich, dass Scrum gelingt. Dazu arbeitet er mit dem Entwicklungsteam zusammen, gehört aber meist selber nicht zu ihm. Er führt die Scrum-Regeln ein und überprüft deren Einhaltung, moderiert die Meetings und kümmert sich um jede Störung des Scrum-Prozesses. Er ist verantwortlich für die Beseitigung dieser Hindernisse. Dazu gehören Probleme im Entwicklungsteam und im Scrum-Team sowie Störungen von außen. Arbeitsmittel des Scrum Master ist das Impendiment Backlog. Darin festgehalten sind alle Hindernisse , die das Entwicklungsteam an effektiver Arbeit hindern.