Software in sicherheitsrelevanten Systemen

Präsentation zum Thema: "Software in sicherheitsrelevanten Systemen"—  Präsentation transkript:

1 Software in sicherheitsrelevanten Systemen
Ralf Pinger / Stefan Gerken / Helge Zücker Sommersemester 2017

2 Kapitel 2 - SW und Systeme
Inhaltsübersicht Abgrenzungen Vollständigkeit und Korrektheit Toleranzen bei SW und HW und Auswirkungen auf die Entwicklung Fehlerpropagation Fehler und Ausfälle Quantifizierung zufällige Fehler systematische Fehler Qualität Ralf Pinger / Stefan Gerken

3 2.1 Abgrenzungen – Definition
Definition Software Intellektuelle Schöpfung, die Programme, Verfahren, Regeln und alle dazugehörige Dokumentation umfasst, die zum Betrieb eines Systems gehören. englische Übersetzung intellectual creation comprising the programs, procedures, rules and any associated documentation pertaining to the operation of a system. Quelle: EN 50128 Ralf Pinger / Stefan Gerken

4 2.2 Vollständigkeit und Korrektheit
Wurden alle Eingangswerte und ihre Parameter definiert? Führen alle Verhaltensweisen der realen Welt zu gefährdungsfreien Reaktionen des implementierten Systems? Korrektheit Tut das System genau das, was definiert wurde? Führen alle implementierten Reaktionen des Systems zu einem gefährdungsfreien Verhalten der realen Welt? Folgerung: Korrektheit ist theoretisch nachweisbar, Vollständigkeit maximal plausibel In der Logik unterscheidet man zwischen semantischer und syntaktischer Folgerung. - Syntaktische Folgerung könnte beispielsweise das Verhalten des Systems sein. Schließlich ist dieses ja in Form eines Regelwerks oder Kalkül beschrieben. - Semantische Folgerung wäre das Verhalten der realen Welt, die Gefährdung oder Unfälle ausschließt. Korrektheit in diesem Sinne wäre dann gegeben, wenn alle syntaktischen Folgerungen auch semantisch gültig wären, sprich wenn das gesamte Verhalten des Systems mit dem Verhalten der realen Welt (gefährdungsvermeidend) übereinstimmen würde. Vollständigkeit ist, wenn alle semantischen Folgerungen auch syntaktisch ableitbar sind. Sprich alle Verhaltensweisen in der realen Welt zu einer gültigen Verhaltensableitung im System führen. Problematisch ist demnach die Unvollständigkeit der Beschreibung der realen Welt, so dass die Überprüfung auf Vollständigkeit nicht durchgeführt werden kann. Ralf Pinger / Stefan Gerken

5 2.3 Toleranzen "normaler" Funktionsbereich eines Systems ist ein schmales Band Fehlerbereich ist der Rest Grün: Alles ok, da geplant Gelb: nicht geplant, aber immer noch nicht kritisch, weil sich das System regeneriert (entweder bei analoger HW weil Toleranzen vorhanden sind oder bei digitaler SW weil z.B. ein Wert zwar zu groß ist, die Multiplikation mit einem anderen Wert aufgrund dessen beschränkten Wertebereichs aber trotzdem nicht zu einem Überlauf führt (Glück gehabt, da analoges Verhalten simuliert wurde) und den Fehler sinnvoll beherrscht (es ist an dieser Stelle robust) Rot: Der Fehler ist aufgetreten Bild: nach Sergio Montenegro Ralf Pinger / Stefan Gerken

6 2.3 Toleranzen – HW und SW Auswirkungen bei Hardware Software
Sind analoger Natur (sie „zerbricht“ nicht unmittelbar) Führen im Allgemeinen nicht sofort zu einem Ausfall des Teils Führen nicht zwangsläufig zu einem Bruch Software Ist digital (Werte sind sofort unplausibel, Wertebereiche laufen über, …) Führen im Normalfall sofort zu einem undefinierten Zustand Regenerieren sich im Normalfall nicht Die kleinste Störung, wie z.B. ein Alpha-Teilchen (subatomisches Partikel) oder ein Ion trifft eine Speicherzelle und kann einen Fehler verursachen, z.B. ein Speicherbit kippt um. Der Fehler kann einen Ausfall verursachen, beispielsweise wegen eines Bit-Kippers im Programmcode verläuft sich die Steuerung und bleibt stehen. Deswegen fällt ein Steuerrechner aus und man kann das Flugzeug nicht mehr lenken - es stürzt ab. Und alles wegen eines subatomischen Partikels! Ein am Anfang kleiner Fehler oder eine unvorhersehbare Situation kann sofort oder viel später das System in den "Fehlerbereich" bringen. Im Fehlerbereich kann sehr leicht die Kontrolle über die Anlage verloren gehen, besonders, weil es in undefinierten Zuständen arbeitet, für die die Steuerung nicht konzipiert ist. So kann ein Fehler, besonders ein Prozessorkern-Fehler, unvorhersehbare Zustände verursachen, und unvorhersehbare Zustände können wiederum Fehler verursachen. Ein Fehler kann sich erst zu einem viel späteren Zeitpunkt bemerkbar machen. So kann viel Zeit vergehen (Latenzzeit) zwischen dem Eintreten der Störung, dem ersten Fehler und dem Systemausfall. Beispiel: Ariane 5 Ralf Pinger / Stefan Gerken

7 2.3 Toleranzen – Beispiel SW-Fehler
Kincardine in Ontario, Kanada, Schwerer Reaktorunfall 1990 Beim Austausch eines abgebrannten Brennelementes geriet die computergesteuerte Umlademaschine in einen unkontrollierten Zustand. Als sie sich 40 cm über dem Schachtdeckel befand, wurden durch einen falschen Befehl im Code des Computers, der die Umlademaschine kontrollierte, zugleich alle 4 Bremsen des Hebezuges gelöst und das schwere Gerät fiel auf die Schachtabdeckung. Die Folge war der Austritt von I hochradioaktivem schweren Wasser aus dem Leck, das in den Brennstoffbehälter geschlagen worden war Das Beispiel erklärt keine Toleranzen in SW – Was ist das eigentlich genau? Finden wir dazu ein passenderes Beispiel Ralf Pinger / Stefan Gerken

8 2.4 Fehlerpropagation – Störungen und Unfälle
Ablauf: Störung oder Fehler liegen vor Störung wird wirksam Störung pflanzt sich fort Störung führt zu einem Unfall Zitat aus: Wenn ein Fehler nicht erkannt wird, kann er nicht behandelt werden. Noch schlimmer ist es aber, wenn ein unerkannter Fehler sich weiter fortpflanzt, so dass weitere übergeordnete Module und/oder andere Module, die Daten der fehlerhaften Module benutzen, sich ebenfalls fehlerhaft verhalten, bis das System ausfällt oder sogar ein Unfall geschieht. Ein unbehandelter Fehler in einem kleinen Drucksensor kann einen Fehler in seinem übergeordneten Modul - einem regulierten Dampfkessel - verursachen. Bleibt der Fehler unbehandelt, kann die ganze Anlage ausfallen oder ein Unfall geschehen. In der Regel werden Anomalien erst erkannt, nachdem sie (negative) Folgen oder gar einen Unfall verursacht haben. Dies ist besonders bei Software-, Bedienungs- und Kommunikationsfehlern der Fall. Je später die Anomalie erkannt wird, desto schlimmer werden ihre Folgen sein. Daher ist es ratsam, Redundanz und Prüfmechanismen in allen kritischen Komponenten vorzusehen. Anzustreben für eine volle Fehlertoleranz ist, die Fehler zu erkennen und zu behandeln, bevor sie sichtbare Konsequenzen haben. Ein einziger Schrauben- oder Transistorausfall kann einen gesamten Anlagenausfall verursachen, denn der am Anfang noch kleine Ausfall wird weitere übergeordnete Module befallen wie das Feuer. Eine Schraube oder ein Transistor wird nicht den eigenen Ausfall erkennen, melden und behandeln können, das nächste übergeordnete Modul vielleicht auch nicht, aber je tiefer in der Modulhierarchie die Behandlung stattfindet, desto früher kann die Fehlerverbreitung gestoppt werden und desto weicher und effektiver können die Korrekturmaßnahmen sein. Sie können verhindern, dass weitere übergeordnete Module ausfallen und dass wir die Kontrolle über die Anlage verlieren. Bei den übergeordneten Modulen ist es einfacher, eine Anomalie zu erkennen, aber dann kann es schon zu spät sein. Ein Kompromiss zwischen Aufwand (Kosten) und Nutzen muss individuell gefunden werden. Es ist wie bei den Krankheiten: Am Anfang sind sie schwer zu erkennen, aber leicht zu heilen, - später sind sie leicht zu erkennen, aber schwer zu heilen. Manchmal ist es sogar möglich vorauszusehen, dass etwas passieren wird, z.B. weil es nicht mehr zu verhindern ist! In diesen Fällen soll die Behandlung noch vor dem Eintreten des Problems starten (nicht warten bis es geschehen ist), dadurch wird die Behandlung effektiver. Um einen Fehler zu erkennen, braucht man eine Referenz zum Vergleichen: Was soll sein, was ist möglich, was ist wahrscheinlich, wie soll es passieren usw. Der Vergleich ist meistens ein Vergleich von Bereichen mit einer Toleranz. Besonderes bei heterogener Redundanz kann man identische Messgrößen oder Berechnungsergebnisse nicht erwarten. Dies betrifft nicht nur Werttoleranzen sondern auch Zeitverschiebungen. Verschiedene Komponenten werden auch zu verschiedenen Zeitpunkten reagieren und/oder Ergebnisse liefern. Bei einer zeitdiskreten Bearbeitung (digitale Systeme) muss man noch berücksichtigen, dass verschiedene Werte einige Taktzyklen verschoben sein dürfen. Wird mittels Software verglichen, so kann der Zeitunterschied zwischen dem Lesen von den verschiedenen Sensoren noch größer sein und damit auch ihr Wertunterschied. bisher beschriebene Fehlererkennung funktioniert nur bei den Sensoren und der Steuerung (HW + SW). Fehler bei den Aktuatoren können nur indirekt durch die Sensoren festgestellt werden. Wenn die erwartete Reaktion des Systems, mit einer Zeittoleranz, von den Sensoren nicht registriert wird, deutet dies auf Aktuator- aber auch auf Sensor-Fehler hin. Die Fehlerlokalisierung muss durch weitere Redundanz und Tests im Betrieb durchgeführt werden, wobei Tests im Betrieb eine riskante Aktion bedeuten können. Bild: nach Sergio Montenegro Ralf Pinger / Stefan Gerken

9 2.4 Fehlerpropagation – Hierarchisch
Fehler pflanzen sich in der funktionalen Programmhierarchie fort, da einzelne Module sich undefiniert verhalten Modell eignet sich auch zur modularen Diagnose Bild: nach Sergio Montenegro Ralf Pinger / Stefan Gerken

10 2.4 Fehlerpropagation – Datenfluss
Fehler pflanzen sich zeitlich im Datenfluss fort, da einzelne Module sich undefiniert verhalten und reaktive Systeme im Regelfall nicht gedächtnislos sind. Bild: nach Sergio Montenegro Ralf Pinger / Stefan Gerken

11 2.4 Fehlerpropagation – Fehlerauswirkungen
Wenn wir Glück haben, tritt nach einem Fehler ein Systemausfall (Nichtausführen der vorgesehenen Funktion zur festgesetzten Zeit) ohne weitere Konsequenzen ein. Wenn wir Pech haben, tritt ein Unfall mit eventuell katastrophalen Folgen ein. Danach bleibt es nur, Maßnahmen für die Schadensbegrenzung zu ergreifen. Es gibt auch (sporadische) Fehler, die sich nicht bemerkbar machen, und der Betrieb kann ungestört weitergehen. Man darf sich darauf aber nicht verlassen. Wenn wir Pech haben, dann kann allerdings auch Systemausfall zu einer Katastrophe führen (z.B. im Flugzeug) Unabhängig davon, warum ein Fehler auftritt (Unvollständigkeit der Systemdefinition oder fehlerhafte Implementierung), muss er sich auswirken, um erkannt zu werden. Fehlerhafte Implementierungen lassen sich durch defensive Programmiertechniken erkennen. Unvollständigkeit lässt sich nur durch Zufall erkennen, wenn es einen vor der Implementierung als unplausibel hergeleiteten Systemzustand gibt, der zusätzlich noch mit einer Assertion abgefangen wird. In diesem Fall würde sich dann zeigen, dass die Anforderungen oder Systemschnittstellen unvollständig definiert wurden. Sehr viel wahrscheinlicher ist in diesem Fall, dass sich eine fehlende Anforderung so auswirkt, dass das System keinen Fehler erkennt und einfach die fehlende Beeinflussung ignoriert, so dass ggf. eine Gefährdung durch den gesteuerten Prozess stattfindet. Eine Fehlerbehandlung muss diesem Schema genügen. Nach dem Erkennen muss der Fehler gemeldet werden, um andere Komponenten zu warnen und um eine Reparatur zu veranlassen. Der Fehler muss dann eingegrenzt werden und verhindert werden, dass er sich weiter verbreitet. Man muss feststellen, welche weiteren Module fehlerhafte Daten erhalten haben und sie entsprechend warnen und korrigieren. Danach wird der Fehler behandelt durch Fehlertoleranz-Maßnahmen, Rekonfiguration, sicheres Anhalten, Checkpoint Recovery u.a. (siehe unten), und am Ende sollen die ausgefallenen Komponenten im Betrieb (z.B. Kraftwerke) oder bei der nächsten Wartung (z.B. Flugzeuge) repariert werden. Bild: nach Sergio Montenegro Ralf Pinger / Stefan Gerken

12 Fehler ist die Abweichung von einem erwarteten Sollwert
2.5 Fehler und Ausfälle Fehler ist die Abweichung von einem erwarteten Sollwert Fehler kann unterschiedliche Ursachen haben Menschliche (z. B. Fehlbedienungen) Systematische (z. B. Programmierfehler, falsche Anforderungen) Zufällige Ursachen (z. B. Übertragungsfehler) Physikalische (z. B. Messfehler) Ausfall ist das Versagen einer technischen Funktion Ausfall bezieht sich auf physikalische Objekte Ausfall ist in der Regel stochastisch Nur ein unerwarteter Ausfall kann zu einem Fehler führen Ausfall und Fehler hängen zusammen, sind aber nicht identisch! Wikipedia unter „Fehler“: Ein Fehler ist eine Abweichung von einem optimalen oder normierten Zustand oder Verfahren in einem bezüglich seiner Funktionen determinierten System. Unter einem Fehler verstand man lange Zeit die Abweichung von einer Norm. Zwischenzeitlich wurde jedoch die Definition modifiziert. Auch das Deutsche Institut für Normung (DIN) definiert Fehler nun als einen „Merkmalswert, der die vorgegebenen Forderungen nicht erfüllt“ und als „Nichterfüllung einer Forderung“. Die transdisziplinäre Fehlerdefinition von Martin Weingardt erweitert das Fehlerverständnis: „Als Fehler bezeichnet ein Subjekt angesichts einer Alternative jene Variante, die von ihm – bezogen auf einen damit korrelierenden Kontext und ein spezifisches Interesse – als so ungünstig beurteilt wird, dass sie unerwünscht erscheint.“ Klassifikation von Fehlern Es gibt einerseits erwartete Fehler, die bei der Planung und Implementierung eines (z. B. technischen) Systems oder der Abwicklung eines Verfahrens vorausgesehen wurden und für deren Fehlerbehandlung geeignete Maßnahmen vorgesehen sind. Die Fehlererwartung richtet sich dabei in einer großen Population nach dem Mittelwert der Abweichungen vom Sollwert. Zu ihnen gehören auch die meisten Messfehler. Andererseits gibt es unerwartete Fehler, deren Auftreten nicht antizipiert (= vorhergesehen) wurde. Das Auftreten eines Fehlers kann von bestimmten Bedingungen, sogenannten Fehlervoraussetzungen anhängig sein, oder aber zufällig sein. Sind die Bedingungen bekannt, unter denen ein Fehler auftritt, kann er reproduziert werden. Vermeiden kann man nur Fehler mit bekannter Ursache. Die Folgen eines Fehlers sind in der Regel unerwünscht. Daher werden Fehler häufig - aber nicht ausschließlich - nach der Schwere der Fehlerauswirkungen klassifiziert. Bei Produkten ist die Abwesenheit von Fehlern ein Qualitätsmerkmal. Das Vorliegen oder Auftreten von Fehlern stellt unter Umständen einen Mangel dar. Bei Lebewesen können bestimmte physiologische Mängel rezeptive Fehler verursachen (Sehfehler, Hörfehler, Lesefehler; siehe Dyskalkulie). Andere Wahrnehmungsfehler haben kognitive Ursachen; siehe z. B. Aufmerksamkeit, Halo-Effekt, Denkfehler, Vorurteil. Auch im Bereich von Ästhetik und Kunst erfolgen Urteile über „richtig“ und „falsch“. Ein in seiner Originalität einzigartiges neues Kunstwerk kann von der Norm oder den Erwartungen abweichen und in die Kritik geraten. Die Rede vom Fehler stößt in diesem Bereich jedoch vollends an seine Grenze. „Fehler“ erlangen hier oft einen besonderen Reiz: von der „Blauen Mauritius“ bis zum Schönheitsfleck von Cindy Crawford, von den „falschen“ Farbsetzungen und Überzeichnungen moderner Künstler bis hin zu den „falschen“ Tönen im Jazz. Was als Fehler bezeichnet wird und was nicht, entspringt folglich einem subjektiven Urteil. Nicht nur in kreativen, sondern auch in innovativen Bereichen erhalten Fehler eine produktive Bedeutung: Die Entdeckung Amerikas und die Entdeckung des Penicillins erfolgten durch „Fehler“. Auch Post-it, Viagra und Teflon „basieren auf Fehlern“. Der gezielte Umgang mit Fehlern hat darum für Unternehmen eine hohe Bedeutung. Die Ausprägung der Fehlerkultur hat darum maßgeblichen Einfluss auf die Qualität der Produkte und Dienstleistungen, aber auch auf die Innovationsfähigkeit, die Wettbewerbsfähigkeit und die Produktivität des Unternehmens. Menschliche Fehler bezeichnen das Fehlverhalten von Menschen (Unterfall: Lapsus). Verkettungen von Fehlern in einem Zusammenhang werden Fehlerkette genannt; sie können zu einem Zusammenbruch ganzer Systeme führen [1], z. B. Flugzeugabsturz oder weiträumiger Stromausfall. Technische Fehler Fehler und ihre Folgen können auch durch Fehlfunktionen wie technische Defekte verursacht werden. In diesem Fall wird der Fehler nicht durch die Menschen verursacht, die ein System oder ein Gerät benutzen, sondern durch den Produzenten oder gar der Konstrukteur. Vielfach sind technische Fehler deshalb im weiteren Sinne wiederum auf menschliche Fehler in der Konstruktionsphase oder im Produktionsprozess zurückzuführen. Die Fehlermöglichkeits- und Einflussanalyse (FMEA) versucht alle möglichen Fehler, die Fehlerfolgen und schlimmstmöglichen Fehlerverkettungen systematisch zu erkennen und zu bewerten, um entsprechende Maßnahmen einzuleiten. Softwarefehler Fehler im Zusammenhang mit Software entstehen durch Mangelhafte nicht aufgabenadäquate Programmspezifikation Mangelhafte Ergonomie (Bedienbarkeit) Fehlerhaften Dateninput, z. B. falsche Bedienung oder andere Anwendungsfehler: Ein Programm kann nur bei korrektem Input einen korrekten Output liefern. Neben dieser Kernfunktion, welche oft dem EVA-Prinzip folgt, muss ein robustes Programm aber auch alle voraussehbaren Fehleingaben behandeln. Dabei sollen dem Anwender sachdienliche, möglichst explizite, und für den Anwender verständliche Hinweise in Form von Fehlermeldungen gegeben werden, was er falsch macht, bzw. wo die Ursache der Fehleingabe liegt. Diese Fehlermeldungen können am Bildschirm, akustisch oder fortlaufend in einem Fehlerprotokoll erfolgen. Programmfehler Denk-, Planungs- und Handlungsfehler In der Psychologie und Handlungstheorie unterscheidet man Denk-, Planungs- und Handlungsfehler. Sie dienen als Grundlage zur Erklärung von menschlichen Fehlern in technischen und sozialen Systemen. Das bekannteste Beispiel dieser Fehlerform ist der Konstruktionsfehler. Dies kann auch auf Softwareentwickler zutreffen. Informationsübertragungsfehler Die Fehlerlinguistik untersucht Fehler beim Sprechen und Lesen. Die digitale Datenübertragung verwendet Fehlerkorrekturverfahren. Bei der Weitergabe der Erbinformation bei der Zellteilung kann die Funktion der Zelle und eines Organismus leiden, sich aber auch verbessern. Ralf Pinger / Stefan Gerken

13 2.6 Quantifizierung Zweck:
ist nichts anderes als die Angabe von irgendetwas als Zahlenwert zum Zweck der Vergleichbarkeit erzeugt das Gefühl einer objektiven Bewertung Problem: Vergleichbarkeit Objektivität Problem: Maß vs. Metrik, also reines Ordnungskriterium vs. Größenrelation Ralf Pinger / Stefan Gerken

14 2.6.1 Quantifizierung – zufällige Fehler
Voraussetzung: Stochastisches Fehlermodell Softwarefehler besitzen (hoffentlich) deterministisches Fehlermodell  Ausfall Stochastisches Modell über die Zeit → Ausfallrate ≡ Ausfälle des Elements pro Stunde Stochastisches Modell über die Nutzungsfälle → Ausfallwahrscheinlichkeit ≡ Ausfälle pro Nutzung des Elements  Betrifft sowohl Verfügbarkeit als auch Sicherheit Ralf Pinger / Stefan Gerken

15 2.6.2 Quantifizierung – systematische Fehler
Mögliche Quantifizierung: Z. B. Gefundene Fehler pro LOC Prognose von systematischen Fehlern Systematische Fehler treten bei gleichen Eingangsbedingungen reproduzierbar immer wieder auf Zufälligkeit der Eingangsbedingungen sind nicht notwendigerweise gegeben Warum einen Fehler nicht beheben, wenn er bekannt ist? Woher weiß man, wie die Restfehler verteilt sein werden? Systematische Fehler können nur festgestellt werden Stochastische Modelle über die Nutzung sind nicht aussagekräftig, da die Benutzer in ihrer Erfahrung ähnliche Benutzerprofile haben. Damit gibt es bestimmte Benutzergruppen, in denen ein vorhandener Fehler nie wirksam wird und andere, in denen er ständig wirksam wird. Damit ist zwar ein theoretisches Modell entstanden, die Aussagekraft für die Praxis gleich Null, da das stochastische Modell, das der Benutzung zugrunde liegt, nicht realistisch ist. Ralf Pinger / Stefan Gerken

16 2.6.2 Quantifizierung – korrekt, robust und vollständig
Korrektheit ist ein Synonym für Fehlerfreiheit, das heißt: Korrektheit ist digital Korrektheit einer Realisierung ist bezogen auf deren Spezifikation Eine fehlende Spezifikation impliziert Korrektheit Vollständigkeit ist verallgemeinert, wenn alles für eine Problemlösung erforderte realisiert wurde (Normalbetrieb und Fehlerfälle) bezogen auf Software die Umsetzung aller Anforderungen der Spezifikation bezogen auf ein Problem die Spezifikation aller Aspekte eines Problems Robustheit ist unter unerwarteten Situationen sinnvoll zu reagieren nicht digital nicht proportional zur Korrektheit Ralf Pinger / Stefan Gerken

17 2.6.3 Quantifizierung – Qualität
Qualität - Lat.: qualitas – Beschaffenheit Die Gesamtheit von Merkmalen (und Merkmalswerten) einer Einheit bezüglich ihrer Eignung, festgelegte und vorausgesetzte Erfordernisse zu erfüllen. [Deutsche Gesellschaft für Qualität] Qualitätsmodelle Softwarequalität selbst ist in der Praxis nicht direkt anwendbar. weitere Detaillierung und Konkretisierung durch Qualitätsmodelle Ableitung von Unterbegriffen Nur weil man systematische Fehler nicht quantifizieren kann, heißt das nicht, dass man keine quantitativen Maßnahmen auf Qualität anwenden kann – Maße und Metriken Ralf Pinger / Stefan Gerken

18 2.6.3 Quantifizierung – Qualitätsmodelle
Qualitätsmodell nach Balzert Ralf Pinger / Stefan Gerken

19 2.6.3 Quantifizierung – Qualitätsmodelle
Qualitätsmodell nach ISO/IEC Tailoring für spezifisches Projekt/Produkt Wikipedia ISO/IEC 9126 Die Norm ISO/IEC 9126 stellt eins von vielen Modellen dar, um Softwarequalität sicherzustellen. Es bezieht sich ausschließlich auf die Produktqualität und nicht die Prozessqualität. Diese ISO-Norm ist in der Norm ISO/IEC aufgegangen und wird durch die neue Norm ersetzt. Folgende Qualitätsmerkmale werden aufgeführt (Teilmerkmale werden im Anhang der Norm nur als Vorschläge aufgeführt): Funktionalität: Inwieweit besitzt die Software die geforderten Funktionen? - Vorhandensein von Funktionen mit festgelegten Eigenschaften. Diese Funktionen erfüllen die definierten Anforderungen. Angemessenheit: Eignung von Funktionen für spezifizierte Aufgaben, z. B. aufgabenorientierte Zusammensetzung von Funktionen aus Teilfunktionen. Richtigkeit: Liefern der richtigen oder vereinbarten Ergebnisse oder Wirkungen, z. B. die benötigte Genauigkeit von berechneten Werten. Interoperabilität: Fähigkeit, mit vorgegebenen Systemen zusammenzuwirken. Sicherheit: Fähigkeit, unberechtigten Zugriff, sowohl versehentlich als auch vorsätzlich, auf Programme und Daten zu verhindern. Ordnungsmäßigkeit: Merkmale von Software, die bewirken, dass die Software anwendungsspezifische Normen oder Vereinbarungen oder gesetzliche Bestimmungen und ähnliche Vorschriften erfüllt. Zuverlässigkeit: Kann die Software ein bestimmtes Leistungsniveau unter bestimmten Bedingungen über einen bestimmten Zeitraum aufrechterhalten? - Fähigkeit der Software, ihr Leistungsniveau unter festgelegten Bedingungen über einen festgelegten Zeitraum zu bewahren. Reife: Geringe Versagenshäufigkeit durch Fehlerzustände. Fehlertoleranz: Fähigkeit, ein spezifiziertes Leistungsniveau bei Software-Fehlern oder Nicht-Einhaltung ihrer spezifizierten Schnittstelle zu bewahren. Robustheit: Fähigkeit, ein stabiles System bei Eingaben zu gewährleisten, die gar nicht vorgesehen sind. Die Software hält DAUs stand. Wiederherstellbarkeit: Fähigkeit, bei einem Versagen das Leistungsniveau wiederherzustellen und die direkt betroffenen Daten wiederzugewinnen. Zu berücksichtigen sind die dafür benötigte Zeit und der benötigte Aufwand. Konformität: Grad, in dem die Software Normen oder Vereinbarungen zur Zuverlässigkeit erfüllt. Benutzbarkeit: Welchen Aufwand fordert der Einsatz der Software von den Benutzern und wie wird er von diesen beurteilt? - Aufwand, der zur Benutzung erforderlich ist, und individuelle Beurteilung der Benutzung durch eine festgelegte oder vorausgesetzte Benutzergruppe. Verständlichkeit: Aufwand für den Benutzer, das Konzept und die Anwendung zu verstehen. Erlernbarkeit: Aufwand für den Benutzer, die Anwendung zu erlernen (z. B. Bedienung, Ein-, Ausgabe). Bedienbarkeit: Aufwand für den Benutzer, die Anwendung zu bedienen. Attraktivität: Anziehungskraft der Anwendung gegenüber dem Benutzer. Konformität: Grad, in dem die Software Normen oder Vereinbarungen zur Benutzbarkeit erfüllt. Effizienz: Wie liegt das Verhältnis zwischen Leistungsniveau der Software und eingesetzten Betriebsmitteln? - Verhältnis zwischen dem Leistungsniveau der Software und dem Umfang der eingesetzten Betriebsmittel unter festgelegten Bedingungen. Zeitverhalten: Antwort- und Verarbeitungszeiten sowie Durchsatz bei der Funktionsausführung. Verbrauchsverhalten: Anzahl und Dauer der benötigten Betriebsmittel bei der Erfüllung der Funktionen. Ressourcenverbrauch, wie CPU-Zeit, Festplattenzugriffe usw. Konformität: Grad, in dem die Software Normen oder Vereinbarungen zur Effizienz erfüllt. Änderbarkeit: Welchen Aufwand erfordert die Durchführung vorgegebener Änderungen an der Software? - Aufwand, der zur Durchführung vorgegebener Änderungen notwendig ist. Änderungen können Korrekturen, Verbesserungen oder Anpassungen an Änderungen der Umgebung, der Anforderungen oder der funktionalen Spezifikationen einschließen. Analysierbarkeit: Aufwand, um Mängel oder Ursachen von Versagen zu diagnostizieren oder um änderungsbedürftige Teile zu bestimmen. Modifizierbarkeit: Aufwand zur Ausführung von Verbesserungen, zur Fehlerbeseitigung oder Anpassung an Umgebungsänderungen. Stabilität: Wahrscheinlichkeit des Auftretens unerwarteter Wirkungen von Änderungen. Testbarkeit: Aufwand, der zur Prüfung der geänderten Software notwendig ist. Übertragbarkeit: Wie leicht lässt sich die Software in eine andere Umgebung übertragen? - Eignung der Software, von der Umgebung in eine andere übertragen werden zu können. Umgebung kann organisatorische Umgebung, Hardware- oder Software-Umgebung sein. Anpassbarkeit: Fähigkeit der Software, diese an verschiedene Umgebungen anzupassen. Installierbarkeit: Aufwand, der zum Installieren der Software in einer festgelegten Umgebung notwendig ist. Koexistenz: Fähigkeit der Software neben einer anderen mit ähnlichen oder gleichen Funktionen zu arbeiten. Austauschbarkeit: Möglichkeit, diese Software anstelle einer spezifizierten anderen in der Umgebung jener Software zu verwenden, sowie der dafür notwendige Aufwand. Konformität: Grad, in dem die Software Normen oder Vereinbarungen zur Übertragbarkeit erfüllt. Ralf Pinger / Stefan Gerken

20 2.6.3 Quantifizierung – Qualitätsmodelle
Qualitätsmodell GQM nach Basili, Rombach individueller; berücksichtigt Blickwinkel inhärent kompatibel zu Szenario-Methoden Wikipedia GQM: Das GQM-Modell beschreibt die Verfahrensweise zur Erstellung eines Qualitätsmodells, wobei sich das Modell in sechs Einzelschritte unterteilen lässt: Charakterisierung des Unternehmens- und Projektumfeldes, Erfassung des Mission Statement, Definition von Messzielen Formulieren von Fragen zur genaueren Definition der Ziele Messziele identifizieren und Metriken ableiten Entwicklung von Mechanismen zur Datensammlung Daten sammeln, analysieren und interpretieren Erfahrungen zusammenfassen und anwenden Kurz: "Der GQM Prozess beginnt mit der Charakterisierung des Organisations- und Projektumfeldes. Unter Berücksichtigung des Umfeldes werden im zweiten Schritt Informationsbedürfnisse mittels Zielen und korrespondierenden Fragen erfasst. Anschließend werden im dritten Schritt Messungen dokumentiert, die der Quantifizierung dieser Informationsbedürfnisse dienen. Im vierten und fünften Schritt werden die Messungen durchgeführt und die resultierenden Daten interpretiert. Abschließend findet im sechsten Schritt eine Nachbereitung statt. Dabei werden beispielsweise die Qualitätsplanung und gewonnene Erkenntnisse gesichert." Die Literatur ist sich bei der Aufteilung der sechs Schritte allerdings nicht ganz einig. Daher stößt man bei der Recherche nach GQM auf verschiedenste Einteilungen und diverse unterschiedliche Bezeichnungen. Einig ist sich die Literatur nur darüber, dass es sechs Schritte sind und die Verfahren, die ihnen zu Grunde liegen, immer in der gleichen Reihenfolge angewendet werden. Die ersten drei Schritte des GQM-Modells werden häufig auch als Definitionsphase bezeichnet. In dieser Phase werden auch die Ziele (Goals), Fragen (Questions) und Metriken (Metrics) ermittelt, die dem GQM-Modell seinen Namen geben. Ziele (goals) identifizieren, was wir erreichen möchten; Fragen (questions), sofern beantwortet, sagen uns, ob wir die Ziele erreichen, oder helfen uns, sie zu verstehen und zu interpretieren; und die Metriken (metrics) identifizieren die Messungen, die nötig sind, um die Fragen (questions) zu beantworten, und quantifizieren die Ziele (goals). Die Ziele, Fragen und Metriken mit deren dazugehörigen Maßen, Schaubildern und sonstigen Ausweitungen, werden als GQM-Plan zusammengefasst. Wie man in obigem Schaubild erkennen kann, ist es auch möglich, mehrere Ziele zu definieren, wobei sich mehrere Ziele eine Frage und mehrere Fragen eine Metrik teilen können. Anders gesagt: Die Beziehung zwischen „Zielen und Fragen“ und „Fragen und Metriken“ ist beide Male 1 zu n. Das gesamte GQM-Modell wird „Top-Down“ definiert, d.h. es ist ein zielorientierter Ansatz, der von den Zielen ausgehend nach unten Fragen und Metriken definiert. Die Analyse und Interpretation geschieht dann wiederum „Bottom-Up“, d.h. von unten nach oben. Ralf Pinger / Stefan Gerken

21 2.6.3 Quantifizierung – Metriken
Beispiele: McCabes zyklomatische Zahl Eindeutig definiert Reproduzierbar Nur auf Kontrollflussgraphen anwendbar Lines of Code (LOC) Unklarheit bezüglich Leerzeilen und Kommentarzeilen Function Points Basiert auf individuellen Einschätzungen Prinzipbedingt nur sehr eingeschränkt reproduzierbar die McCabe-Zahl M definiert als M = e − n + 2p e: Anzahl Kanten im Graphen n: Anzahl Knoten im Graphen p: Anzahl der einzelnen Kontrollflussgraphen (ein Graph pro Funktion/Prozedur) Bei Betrachtung eines einzelnen Kontrollflussgraphen (also p=1) gilt M = b + 1 mit b: Anzahl Binärverzweigungen, also bedingte Anweisungen mit genau zwei Zweigen, z. B. IF-Anweisungen. M ist eine untere Schranke für die Anzahl der möglichen Wege durch ein Programm. M ist außerdem eine obere Schranke für die Anzahl der Testfälle, die nötig sind, um eine vollständige Kantenabdeckung des Kontrollflussgraphen zu erreichen. Ralf Pinger / Stefan Gerken

22 2.6.3 Quantifizierung – Qualität
Qualitätsanforderungen Qualitätsmodell Architekturmodell Designmodell Wann ist eine Architektur effizient? Wann ist ein Design effizient? Bild: Axel Zechner Ralf Pinger / Stefan Gerken