Diese Seminararbeit behandelt die Qualität im Rahmen von Requirements und Software Engineering. Das bedeutet die Qualität muss einerseits im Aspekt der Anforderungsanalyse und andererseits für das konkrete Softwareprojekt selbst analysiert werden. Dazu werden im Rahmen des Requirements Engineering funktionale und nicht-funktionale Anforderungen beleuchtet. Ziel dieser Arbeit ist es, einen aktuellen Forschungsstand im Rahmen der Qualität von Requirements & Software Engineering aufzuzeigen.
Um die Qualität von Software zu klassifizieren und zu messen sind nicht nur das Softwareprodukt selbst, sondern auch dessen funktionale und nicht-funktionale Anforderungen nötig. Das Ziel, eine exakte und eindeutige Definition von Software Qualität zu erhalten, ist nach heutigem Stand der Forschung nicht möglich, da es nicht „das eine Kriterium, mit dem sich Software-Qualität in direkter Weise und vor allem quantitativ verbinden lässt“ gibt.
Abstract: Um die Qualität von Software zu klassifizieren und zu messen sind nicht nur das Softwareprodukt selbst, sondern auch dessen funktionale und nicht- funktionale Anforderungen nötig. Das Ziel, eine exakte und eindeutige Definition von Software Qualität zu erhalten, ist nach heutigem Stand der Forschung nicht möglich, da u.a. nach [HO13] nicht „das eine Kriterium, mit dem sich Software- Qualität in direkter Weise und vor allem quantitativ verbinden lässt“, gibt. Diese Seminararbeit behandelt die Qualität im Rahmen von Requirements und Software Engineering. Das bedeutet die Qualität muss einerseits im Aspekt der Anforderungsanalyse und andererseits für das konkrete Softwareprojekt selbst analysiert werden. Dazu werden im Rahmen des Requirements Engineering funktionale und nicht-funktionale Anforderungen beleuchtet. Ziel dieser Arbeit ist es, einen aktuellen Forschungsstand im Rahmen der Qualität von Requirements & Software Engineering aufzuzeigen.
1 Einleitung
1.1 Motivation
Über die Qualität im Software Engineering wird seit der Softwarekrise vor über 50 Jahren immer wieder nicht nur in Expertenrunden diskutiert. Anders als in anderen Sparten, wie z. B im Maschinenbau oder der Architektur, wo es standardisierte und allgemeingültige Definitionen für Qualität gibt, ist diese im Requirements und Software Engineering nur zum Teil definiert. Eine explizite und eindeutige Definition des Terminus Qualität ist in den Softwareentwicklungssparten jedoch bislang noch nicht erreicht worden. Dies folgt zum einen durch die Unterschiedlichkeit der Software-Anwendungen und zum anderen durch die unterschiedlichen Sichtweisen der Beteiligten. Ein weiterer Aspekt ist, dass viele Anforderungen erst nach dem eigentlichen Entwicklungszyklus definiert und gemessen werden können, da diese zuvor kaum messbar erscheinen, bzw. noch nicht vorhanden sind.
In den meisten Fällen wird auf die Verbesserung der Softwareprodukte und des aktuellen Stands der Technik wertgelegt. Dies bedeutet zwar auch, die Qualität zu verbessern,
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 1: Einordnung von Software (aus [HO00], Figure 1)
allerdings ist es schwierig, etwas zu verbessern, das nicht, bzw. nicht einheitlich, definiert ist.
Dass der Begriff Software Qualität letztendlich nicht nur mit den Anforderungen an eine Anwendung zu tun hat, wird auch in [KP96] aus dem Jahr 1996 deutlich. Hier werden verschiedene Sichtweisen auf Qualität von Software und auch einige Metriken und Modelle aufgezeigt, die sich mit Messbarkeit von Qualität beschäftigen. [CP09] beschäftigt sich in ähnlicher Weise mit den nichtfunktionalen Anforderungen an Software. Hierbei werden jene, in Anforderungsanalysen und zum Projektstart nicht direkt messbare, Qualitätsanforderungen angesprochen und verschiedene Modelle und Schemen zur Vergleichbarkeit und Verbesserung angeboten. Hierbei werden aktuell bestehende Repräsentationen der non-functional Requirements (NFRs) erläutert und Konzepte und Szenarien für diese „Softgoals“ für künftige Anwendungen verfügbar gemacht.
Dadurch wird deutlich, wie schwierig es ist Qualität, vor allem von nicht sichtbaren Eigenschaften, exakt zu beschreiben. Heinrich C. Mayr hat dazu 1995 einige Thesen gesammelt und diese zur Diskussion gestellt (vgl. [MA95]). In den Büchern von Wallmüller [WA01] und Hoffmann [HO13] werden diese Themen aufs Neue aufgegriffen und im aktuellen Bezug gesetzt. Dass die Begriffe Qualität im Software und Requirements Engineering unterschiedlich definiert werden ist nicht neu. Um einen Überblick über diese Definitionen zu finden wurde folgende Forschungsfrage definiert:
RQ: Wie ist Qualität in Requirements und Software Engineering definiert und wie wird diese eingesetzt?
Dieser Überblick wird allerdings durch die Vielzahl an unterschiedlichen Formulierungen auf einige Standards und den bekanntesten Vertretern reduziert. Zunächst jedoch sollte der Begriff „Software“ geklärt werden. Der IEEE Standard 610.12 definiert Software als Computerprogramme, Prozeduren, Regeln, und alle assoziierten Dokumentationen und Daten betreffend ihrer Operationen (vgl. [HO00], S. 3). In Bezug auf Hardware und - Komponenten unterstützt Abbildung 1 aus [HO00] die Einordnung von Software.
1.2 Aufbau der Arbeit
Im nächsten Kapitel werden zunächst die allgemeinen Definitionen, die es bisher zum Thema Requirements Engineering und Software Qualität definiert wurden, wiedergegeben. Zudem werden einige z.T. zeitlose Zitate und Fragen über Software Qualität und die Probleme die sich daraus ergeben thematisiert.
Im anschließenden Kapitel werden beide Begriffe kombiniert um einen detaillierteren Einblick zu geben und ein Versuch gestartet anhand der aktuell bestehenden Definitionen einen genaueren Begriff dafür zu finden. Den Abschluss bilden eine Zusammenfassung und ein Ausblick auf mögliche zukünftige Herangehensweisen um den Begriff Qualität im Software und Requirements Engineering besser verankern zu können.
2 Definitionen der Begriffe Software Qualität & Requirements Engineering
In diesem Kapitel werden die unterschiedlichen Definitionen von Software Qualität und die Definition des Begriffs Requirements Engineering näher behandelt. Hierzu wird vor allem beim Requirements Engineering der Fokus auf die Teilaspekte der Anforderungen, den sog. functional und non-functional Requirements, eingegangen.
Dass Software Engineering und Requirements Engineering zusammengehören zeigt Hofmann in seinem Werk [HO00]. Hier heißt es: Das wissenschaftliche Gebiet, das mit Methoden, technischer Ausführung und Werkzeuge zur Entwicklung von Qualitätssoftware, heißt Software Engineering. Im IEEE Standard 610.12 von 1990 wird Software Engineering mit den folgenden Punkten definiert:
(1) Die Anwendung eines systematischen, disziplinierten, quantitativ bestimmbaren Ansatzes zu der Entwicklung, Ausführung und Wartung von Software; dies ist angewandte Software Engineering.
(2) Die Studien der Ansätze wie in (1).
(vgl. [HO00], S. 16)
2.1 Software Qualität
Wie eingangs beschrieben gibt es für den Terminus Software Qualität keine eindeutige und überall gültige Definition. Die Qualität von Software-Systemen wird, wie in [KP96] beschrieben, je nach Sichtweise und Verwendung immer wieder neu definiert. Denn ein Benutzer hat in der Regel andere Vorstellungen von Qualität wie ein Entwickler oder Projektmanager.
In der ISO/IEC 9126 wird deshalb die Qualität von Software eher allgemein gültig in folgendem Satz definiert: „Software Qualität ist die Gesamtheit der Merkmale und
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2: Qualitätsmerkmale nach Hofmann (aus [HO13])
Merkmalswerte eines Software-Produkts, die sich auf dessen Eignung beziehen, festgelegte Erfordernisse zu erfüllen“ ([HO13], vgl. [ISO01]).
Wallmüller und Hoffmann bieten in ihren Werken ([WA01, HO13]) ebenfalls unterschiedliche Sichtweisen auf die Qualität der Software an. So wird in [WA01] das Qualitätsmanagement in der Softwareentwicklung hervorgehoben, wohingegen in [HO13] die Software-Qualität direkt angesprochen wird. Hoffmann betont in seinem Werk außerdem, dass „nicht das eine Kriterium“ gibt, „mit dem sich Software Qualität in direkter Weise […] verbinden lässt“. „Vielmehr verbergen sich hinter dem Begriff vielschichtige Kriterien, von denen sich einige […] gegenseitig ausschließen“ [HO13]. Dies bezieht sich in weiterer Sicht auf die funktionalen und nicht-funktionalen Anforderungen, wie Abbildung 2 zeigt. Wallmüller hingegen stützt sich auf den Lifecycle- Prozess, der im ISO/IEC-Standard vorgegeben ist (vgl. [WA01]). Auch Cadle und Yates zielen in ihrem Werk [CY08] wie auch Hoffmann und Wallmüller auf die allgemeinere Sichtweise von Software Qualität ab. Cadle und Yates beschreiben allerdings die Perspektive eines Projektmanagers oder -leiters in einem Softwareentwicklungsprojekts, wohingegen Hoffmann und Wallmüller als Zielgruppe die Softwareentwickler und IT- Experten ansprechen. In [CY08] werden mehrere Definitionen für Qualität wiedergegeben, die hier ins Deutsche übersetzt aufgezeigt werden:
- „Grad der Exzellenz einer Sache“
- „Das Produkt oder der Service macht genau das, was der Kunde spezifiziert hat.“
- „Die Gesamtheit der Features und Charakteristiken eines Produkts oder Service,
die die Fähigkeit haben implizite oder explizite Bedürfnisse zu erfüllen.“ (ISO 8402:1991)
Die beiden Autoren schreiben ebenso, dass auch der ISO-Standard nicht genau festlegt, was Qualität im Software Engineering bedeutet. Vor allem aber die beiden anderen Definitionen sind sehr ungenau und lassen Raum für Interpretationen (vgl. [CY08]). Weitere Ansätze um Software-Qualität zu definieren greift Wallmüller in [WA01] auf und stützt sich dabei auf [GA84]:
W1)Der „transzendente“ Ansatz
Qualität ist universell erkennbar und ein Synonym für kompromisslos hohe Standards und Ansprüche an die Funktionsweise eines Produkts.
[...]
-
-
-
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X.