Software-Qualität

Zuverlässigkeitsmetriken

Fehlertoleranzmaßnahmen

Wartungsmetriken

COCOMO

Halstead

Function Points

OO-Metriken

Inspection

Anforderungen → Volere

Anforderungsanalyse

Qualitätsmodelle

Prozessmetriken

CMM Grundprinzip

Entwicklungskomplexitäten

Vorgehen (3 Schritte)

Zählen der UFP (4 Schritte)

Was ist ein Elementarprozess?

Funktionskategorien Datenbestände/Transaktionen (5)

Was ist Kohäsion/Kopplung?

Balzert: hohe Kohäsion/geringe Kopplung → ausgeprägte Struktur/hohe Modularität → geringe Komplexität, Einfachheit, Verständlichkeit

Bindungsstärken (8)

Programmbereiche (2)

Zeilentypen strukturell (4)

Zeilentypen inhaltlich (5)

Herleitung D, L, E, I

übliche Werte für S

Grenzwert für die zyklomatische Zahl

Formeln/Verständnis

Kostenverteilung Wartung

Klassifizierung (3)

Wertebereich E

Stahlknecht Bedeutung

Welche gibt es?

repeatable (6)

defined (7)

managed (2)

optimized (3)

Durchführungsverpflichtung (2)

Durchführbarkeit (3)

Prozessbewertung (2)

Verifikation (2)

Durchzuführende Aktivitäten (5)

formelles Assessment (6 Schritte)

informelles Assessment (3 Bereiche, 6 Stufen)

Eingangsprüfung (5 Kriterien)

Planung (4 Schritte)

Einführungssitzung (4 Aufgaben)

Vorbereitung

Inspektionssitzung

3. Stunde

Nachbereitung

Mängelbeseitigung

Nachprüfung

Autor (3 Aufgaben)

Moderator (6 Aufgaben)

Prüfkriterien (4)

Basis-Checkliste (Beispiele für Prüfhinweise)

Beispiele für Inspektionsrichtlinien (9)

Erhebungsbogen (9 Angaben)

Inspektionsprotokoll (4 Angaben)

Wann sollten Inspektionen durchgeführt werden?

Schwerpunkte (6)

Review (5 Punkte)

Walkthrough (6 Punkte)

Vorteile (4)

Nachteile (1)

Qualität ist die Übereinstimmung mit den Anforderungen

Nur auf Basis bekannter Anforderungen kann eine Aussage über Qualität getroffen werden, da sie sonst nur subjektiv bewertbar ist.

Unzuverlässigkeit entsteht durch Ausfälle. Diese sind zu definieren und Maßstäbe zu finden, anhand derer die Schwere der Ausfälle bewertet werden kann.

Ein System bietet system services (in der Anforderungsddefinition festgelegt) an und zwar mit einer gewissen quality of service.

Konstruktive Maßnahmen (Methoden, Techniken)

Organisatorische Maßnahmen (Vorgehensweisen)

Analytische Maßnahmen (Test, Review)

Anforderungen <> Unzulänglichkeiten (Bewertungsmaßstäbe für Nichterfüllung, Maßnahmen zur Verbesserung)

Unzulänglichkeiten können nicht abgestellt, aber beherrscht werden

Bewertungsmaßstäbe müssen anforderungsbezogen eingesetzt werden

Maßnahmen müssen zielgerichtet eingesetzt werden

nicht akzeptables Systemverhalten (tatsächliche Mängel des Systems)

nicht zufriedenstellendes Systemverhalten (Missverständnis des Benutzers)

MDT (mean down time): mittlerer Zeitraum, während dessen das System nicht zur Verfügung steht (Instandsetzung).

MUT (mean up time) / MTTF (mean time to failure): mittlerer Zeitraum, während dessen das System zur Verfügung steht.

required time: Zeit, während der das System zur Verfügung stehen muss.

non-required time: Zeit, während der das System nicht zur Verfügung stehen muss.

up time: Zeit, in der das System funktionsfähig ist.

disabled time: Ziet, in der das System nicht funktionsfähig ist.

undetected fault time: Zeit zwischen Ausfall und Erkennen der Störung.

administrative delay: Zeit, während der keine Wartung durchgeführt werden kann.

maintenance time: Zeit, während der Wartung durchgeführt wird.

Badewannenkurve: Frühausfälle, useful operating life, Spätausfälle

steady state availability: MUT / (MUT + MDT)

analog zur Ausfallverteilung

analog zur Ausfallrate

Verlässlichkeit (dependability): Vertrauenswürdigkeit in die Leistung des Systems.

Verfügbarkeit (availability performance): Fähigkeit des Systems, eine Leistung zu einem bestimmten Zeitpunkt zu erbringen.

Zuverlässigkeit (reliability performance): Fähigkeit des Systems, eine Leistung für einen vorgegebenen Zeitabschnitt zu erbringen.

Instandsetzbarkeit (maintainability performance): Fähigkeit des Systems, durch Wartung instandgehalten oder repariert werden zu können.

Wartungsunterstützung (maintenance support performance): Fähigkeit der Wartungsorganisation, die benötigten Ressourcen für die Instandsetzung bereitzustellen.

funktional: beschreiben den Funktionsumfang des Systems (Aufgaben, Dienstleistungen)

Rand-/Zusatzbedingung: beeinflusst die Umsetzung der funktionalen Anforderungen

ursprüngliche Texte aufbewahren!

Fehlervermeidung: Einsatz von konstruktiven Maßnahmen

Fehlerbeseitigung: Untersuchen des Systems auf Fehler und Beseitigung dieser vor Inbetriebnahme

error detection: Finden des Fehlers

damage confinement: Schadensbegrenzung

error recovery: System in fehlerfreien Zustand versetzen

fault treatment / continued service: Fehlerursache (Störung) beheben

error processing: Überführung der Störung in einen latenten Zustand → fehlerfreies System

reconfiguration: Behebung der Störung

Systemaspekt

Aktivierung

Fehlerart

Fehlerkorrektur (Prüfsummenbildung)

Fehlermaskierung (TMR-System)

Rückwärtsfehlerbehebung (recovery points)

Vorwärtsfehlerbehebung

Rekonfiguration (TMR mit zwei Ersatzkomponenten)

Entwicklungsaufwand in Mann-Monaten: PM (personal month)

Entwicklungsaufwand in Monaten: TDEV (time of development)

Entwicklungsaufwand in Personen: N (number of programmers)

Festlegen der Systemgrenzen

Unadjusted Function Points ermitteln

Adjusted Function Points ermitteln

Funktionskategorien (Datenbestände/Transaktionen)

Elementarprozess / Transaktion

Höhenmaß, Breitenmaß, rel. Breitenmaß, Maß der Baumähnlichkeit

Bindung (cohesion)

Kopplung (coupling)

Bindungstypen: zufällig, logisch, zeitlich, prozedural, kommunikativ, sequentiell, informal, funktional

Vokabular

Programmlänge

Programmumfang

Schwierigkeitsgrad

Abstraktionsniveau

Programmieraufwand

Intellektueller Gehalt

Programmierzeit

mittlere Fehlermenge

nicht in der Formelsammlung

Fehlerbeseitigung, Optimierung, Portierung

Aufwandsmetriken (Lesbarkeit, Korrekturzeit, Fehlerbeseitigungszeit)

Änderungsbezogene Metriken (Lokalisierung, Perfektionierung, Wiederverwendbarkeit)

Fehlerbezogene Metriken (Fehlerhäufigkeit, Fehlerzuwachs)

Entwicklungseffektivität

Änderungsmetrik von Stahlknecht

Portabilitätsmetriken

Produktgröße, -komplexität, Entwicklungsumgebung

Messlatte zur Ermittlung der Prozessqualität

Hilfestellung bei der Festlegung von Verbesserungsmaßnahmen

SW-Entwicklungs- und Wartungsprozesse kontrollieren

kritische Bereiche erkennen

die Prozesse gezielt verbessern

firmenweite Methodik zur Organisation von SW-Entwicklung

Rollen und Verantwortlichkeiten sind klar definiert

die Beteiligten befolgen die disziplinierte Vorgehensweise aus innerer Überzeugung

Arbeiten werden gemäß der Planung durchgeführt

Prozess ist exakt erläuterbar

Manager überwachen die Qualität des Prozesses

es liegen objektive und quantifizierbare Kriterien zur Prozessanalyse vor

Zeitplan- und Budget-Vorgaben sind realistisch und basieren auf Erfahrung

es gibt festgelegte Verfahren zur Problemanalyse

chaotisch / initial → disziplinieren

reproduzierbar / repeatable → konsistent machen / standardisieren

definiert / defined → vorhersagbar machen

gesteuert / managed → weiterentwickeln / kontinuierlich verbessern

optimiert / optimized

Vorhersagbarkeit

Kontrolle

Effektivität

Stärken/Schwächen des Unternehmens identifizieren

Auswahl von Unterauftragnehmern

Maßnahmen zur Prozessverbesserung erkennen

Definition und Optimierung des eigenen Prozesses

Reifegrad → Schlüsselgebiet → Maßnahmenkategorie → Handlungsanweisung

Ergreifen von Maßnahmen in Schlüsselgebieten um Ziele zu erreichen.

Aktivitätenkategorien → Handlungsanweisungen (Aktivitäten oder Infrastrukturmaßnahmen)

Schlüsselgebiet: Für die Verbesserung des Entwicklungsprozesses besonders wirksame Prozessbereiche.

Anforderungsmanagement

SW-Projektplanung

SW-Projektverfolgung

Subcontractormanagement

SW-Qualitätssicherung

SW-Konfigurationsmanagement

firmenweite Prozessüberwachung

firmenweite Prozessdefinition

Ausbildungsprogramm

ganzheitliche Prozessdefinition

SW-Produktengineering

Koordination zwischen Entwicklungsteams

Reviews

Quantitatives Prozessmanagement

SW-Qualitätsmanagement

Defektverhinderung

Technologieveränderungsmanagement

Prozessveränderungsmanagement

Feststellung der erfolgreichen Etablierung des betroffenen Bereichs im Prozess

Stecken der Rahmen der Verbesserungsmaßnahmen ab

Ableitung von Handlungsanweisungen, Aktivitäten und Infrastrukturmaßnahmen

Infrastrukturmaßnahmen (Institutionelle Basis)

Aktivitäten (müssen implementiert werden)

Die Handlungsanweisungen beschreiben das Vorgehen um die Schlüsselbereiche möglichst effizient zu etablieren. Jede Handlungsanweisung kann in einem Satz definiert werden. Eine Handlungsanweisung beschreibt was zu tun ist, aber nicht wie im Einzelnen verfahren werden soll.

Formelles CMM-Assessment

Informelles CMM-Assessment

technisch (Methoden, Werkzeuge, Sprachen)

organisatorisch (Richtlinien, Standards, Checklisten)

analysierend (statische Analyse, Animation, Verifikation, Prüfmethoden)

testend (Schreibtischtest, Simulation, symbolischer und dynamischer Test)

(Fagan-)Inspektion, Review, Walkthrough

mehrere Teilnehmer prüfen ein Prüfobjekt

möglichst schnell nach der Erstellung (→ mit Objekt soll weitergearbeitet werden)

in evtl. mehreren Sitzungen

gegen eine Vorgabe/Referenz

Prüfobjekt vorlegen

Eingangsprüfung

Planung

(Einführungssitzung)

Vorbereitung

Inspektionssitzung

(3. Stunde)

Nachbereitung

Mängelbeseitigung

Überprüfung

Freigabe

Autor(en)

Moderator

Inspektor(en)

Protokollführer

Vorleser

Prüfungen haben eine hohe Priorität

der benötigte Aufwand muss eingeplant werden

Vorgesetzte und Zuhörer dürfen nicht teilnehmen

Inspektoren müssen Pürfmethode beherrschen

Prüfkriterien

Erhebungsbögen der Inspektoren

Inspektionsprotokoll

Nach jedem Prozessschritt, auf jeder Softwarearchitekturebene sollte das jeweilige Zwischenprodukt geprüft werden.

Schwerpunkte: Konformität zu Vorgängerprodukten, Vollständigkeit, Struktur, Fehlerverhalten, Lesbarkeit und Verständlichkeit, Überflüssiges streichen

Review

Walkthrough

Vorteile: Semantikprüfung, ganzes Team trägt Entscheidung, Mängel werden früh und effektiv gefunden, Lerneffekt bei Entwicklern

44% der Kosten eines Projekts entfallen auf Fehlerbeseitigung

Kosten zu Beginn hoch aber durch weniger Fehlerbehebung am Ende relativiert

Aufwand für systematische Inspektionen: 15%-20% des Gesamtaufwands

70%-80% aller Fehler können durch Inspektionen gefunden werden

Kosten/Zeitüberschreitung lassen sich um 30% reduzieren

Lerneffekt bei den Entwicklern

Risiko: trügerische Sicherheit, wenn Verfahren nicht beherrscht wird

Ermittlung des Umfangs der zu erbringenden Leistung bzw. Ermittlung der Aufgabenstellung.

Identifikation der Geschäftsvorfälle in Zusammenhang mit dem Leistungsangebot / der Aufgabenstellung.

Festlegung der Rolle des künftigen Produktes bei der Erbringung der Leistung.

Ableitung von Anforderungen zu jedem Anwendungsfall.

Zusatzinformationen zu den Anforderungen: Randbedingungen, Stakeholder, Leistungsumfang des Produkts → Volere

Beispiel ab S. 183

Tabelle S. 190

Grundbegriffe Zuverlässigkeit

Verteilte Systeme II

Reliability and Safety

Recommendation E.800

Binäre Bäume

Binärbäume und AVL-Bäume

Wann bezeichnet man ein System als verlässlich oder zuverlässig? Was macht die Qualität eines Systems aus?

Wie macht man ein System verlässlich bzw. zuverlässig? Wie stellt man die Qualität eines Systems sicher?

Ein Ausfall bezeichnet die Beendigung eines Elements, eine angeforderte Leistung zu erbringen (z.B. Hardware geht kaputt).

Eine Störung bezeichnet die Unfähigkeit eines Elements, eine angeforderte Leistung zu erbringen. Störungen können durch Ausfälle verursacht werden (müssen es aber nicht, Bsp. Programmierfehler).

Ein Fehler ist jegliche Abweichung von berechneten, beobachteten oder gemessenen Werten von den tatsächlich gültigen (Grundlage: Theorie, Spezifikation). Fehler sind auf Störungen zurückzuführen (Indikatoren für Störungen).

Software wird zwar mit der Zeit (wie alle Dinge) älter, verursacht aber keine altersbedingten Fehler, wie Hardware es tut. Daher müssen für Software keine Vorkehrungen getroffen werden, um Altersfehlern vorzubeugen (sofern das Soft-/Hardwarekonstrukt gleich bleibt).

Siehe Kapitel 1.3.5 im Skript.

MUT + MDT = MTBF → MUT = 365 - 2 = 363

A = MUT / MTBF = 363 / 365 = 99,452%

Eine Basisanforderung, die keine funktionale Anforderung ist, wird als required constraint bezeichnet. RQs stellen Randbedingungen dar und wirken sich auf die Architektur des Systems aus. Sie lassen sich kategorisieren in physical, environmental, development und product assurance.

In Gesprächen, Beobachtungen usw. werden initiale Anforderungen der Stakeholder erfasst und zu Papier gebracht (→ ablegen).

Diese Anforderungen werden nun genauer untersucht und Basisanforderungen abgeleitet (→ getrennt ablegen).

Die Basisanforderungen werden in funktionale Anforderungen und Randbedingungen aufgeteilt.

Funktionale Anforderungen werden (wenn sie nicht mehr weiter unterteilbar sind) in die Systemanalyse übernommen (→ getrennt ablegen).

Randbedingungen werden in die Systemarchitektur übernommen.

Fehlertoleranz bezeichnet die Fähigkeit eines Systems auch im Fehlerfall weiter seine Funktionalität anzubieten.

Phasen und Methoden siehe Skript S.68

Informationsredundanz (Nutzdaten und Prüfsumme)

strukturelle Redundanz (Speicherung von Nutzdaten und Prüfsumme)

funktionale Redundanz (Funktion zum Codieren und Decodieren)

Zeitredundanz (Zeit zum Codieren und Decodieren)

Designfehlern lässt sich nur durch redundante Entwicklung von Systemkomponenten entgegenwirken (z.B. N-Version Programming)

Da die Bewertung der Lesbarkeit und Verständlichkeit von Texten bei verschiedenen Personen subjektiv recht unterschiedlich ausfallen kann, werden die Metriken verwendet, um eine objektive Bewertung der Texte vorzunehmen.

Flesh-Cincaid-Verständlichkeitsgrad ("Schulnotensystem")

Flesh-Cincaid-Lesbarkeitsgrad (Skala von 1 bis 100)

UFP = 55

Die Function Point Metrik steht für die voraussichtliche Größe des Projekts. Auf Basis dieses Wertes kann dann z.B. die erwartete Entwicklungsdauer ermittelt werden (z.B. über COCOMO).

Die Metrik von Blaschek kann eingesetzt werden, um in der Entwurfsphase die Modulstruktur einer Software zu analysieren (Baumhöhe, -breite, -ähnlichkeit). Anhand von Vergleichen mit erfolgreichen Softwareprojekten kann dann die vorliegende Architektur bewertet werden.

Zufällige Bindung: Die zusammengefassten Module stehen in keinem logischen Zusammenhang zueinander.

Für das Zählen der LOC gibt es verschiedene Vorgehensweisen. Normalerweise sollten die Codezeilen ohne Kommentare und Leerzeilen gezählt werden.

a) Länge des Programms (Gesamtzahl aller verwendeten Operatoren und Operanden)

b) Vokabular des Programms (Gesamtzahl aller möglichen Operatoren und Operanden)

Man kann in der Wartungsphase früherer Projekte die Anzahl der benötigten Updates je Komponente und deren Komplexität ermitteln und dokumentieren. Aus diesen Werten kann man mit der Zeit eine Funktion ableiten, die das Verhältnis zwischen Komplexität und Fehlerzahl darstellt. Nun kann eine maximale Fehlerzahl festgelegt werden und die daraus resultierende maximale Komplexität ermittelt werden.

Qualitätsmodelle sind Modelle idealer Entwicklungsprozesse, an denen sich die Prozessqualität eines Unternehmens messen lässt. Sie dienen zum Einen der Bewertung des aktuellen Standes des Entwicklungsprozesses und zum Anderen zum Ermitteln von sinnvollen Verbesserungsmaßnahmen.

CMM, CMMI, Spice, Bootstrap, ISO 9000

Unternehmen sollten sich nicht auf ein Qualitätsmodell als Allheilmittel verlassen. Die Prozessverbesserung muss immer auch mit einer verbesserten Technologiekompetenz einhergehen.

initial: Keinerlei Struktur, Erfolg abhängig von Individualleistungen

repeatable: Entwicklungsprozess mit klaren Phasen und Meilensteinen, Phasen sind black boxes

defined: Unternehmensweit einheitlich definierter Entwicklungsprozess

managed: Entwicklungsprozess wird anhand von festgelegten Kriterien kontrolliert und gesteuert

optimized: Entwicklungsprozess unterliegt einer ständigen Optimierung

Key Process Areas stellen wichtige Bereiche des Entwicklungsprozesses dar, denen im Rahmen der Optimierung des Prozesses eine besondere Aufmerksamkeit zuteil werden sollte.

KPAs werden aufgeteilt in die Bereiche Management, Organisation und Engineering. Für jeden Reifegrad sind unterschiedliche KPAs definiert, die berücksichtigt werden müssen.

Sämtliche Aktivitäten werden mit Punkten zwischen 0 und 10 bewertet. Über die einzelnen Bereiche des Prozesses werden dann Durchschnittswerte gebildet. Ein Durchschnitt von über 8 deutet auf ein mögliches positives Prüfergebnis einer formellen Evaluierung hin.

Durch einen höheren CMM-Level steigt die Vorhersagbarkeit der Prozessergebnisse, der Grad der Kontrolle über den Prozess und die Effektivität des Prozesses.

siehe S. 200

Mindestens Autor, Inspektor und Moderator, maximal 7 Personen, um eine optimale Kommunikation zu gewährleisten

Max. 2-2,5 Stunden. Optional ist die "3. Stunde"

Es sind keine Zuhörer erlaubt (Vorgesetzte/Gäste)

Sachliche Diskussion über das Prüfobjekt, nicht den Autor (keine Verteidigung etc.)

Ein Inspektor (nicht der Autor) liest das Prüfobejkt vor

In Problemen denken, nicht in Lösungen. Keine Verbesserungen suchen!

Durch den gezielten Einsatz von Inspektionen mit geschulten Teilnehmern kann die Qualität der Software deutlich gesteigert werden. Fehler werden früh entdeckt und Beseitigungskosten können eingespart werden. Außerdem sind sie die einzige Möglichkeit, um eine semantische Prüfung der Prüfobjekte durchzuführen. Wichtig ist die Kompetenz der Teilnehmer, um nicht zu einem falschen Sicherheitsempfinden zu kommen.

Ermittlung des Umfangs der zu erbringenden Leistung (Systemgrenzen ermitteln).

Ermittlung von Geschäftsvorfällen im Rahmen der zu erbringenden Leistung (Datenströme ins/vom System).

Festlegen der Rolle des Produkts / Abgrenzung zum System (Anwendungsfälle des Produkts).

Ermitteln von Anforderungen für jeden Anwendungsfall.

Ein Geschäftsprozess ist eine Menge an logisch und zeitlich zusammenhängenden, evtl. organisatorisch getrennten Aktivitäten, die durchgeführt werden, um einen fachlichen Geschäftsvorfall zu bearbeiten.

Ein Geschäftsvorfall ist ein Geschäftsobjekt, das durch die in einem Geschäftsprozess beschriebenen Aktivitäten bearbeitet wird. Ein Geschäftsvorfall wird durch ein Ereignis ausgelöst.

Organisationen, Personen, technische Systeme

aktive, autonome, kooperative

Organisation: Staat, Geschäftspartner

Person: Bankkunde, Bediener

technisches System: Kreditkartenvalidierer, Online-Banking

aktiv: Person, Kunde

autonom: Börsenkurssystem

kooperativ: Schufa

System und Produkt können sich entsprechen, sie müssen es aber nicht. Das System kann außer dem Produkt noch andere Systeme oder Personen enthalten, die Aufgaben übernehmen, die das Produkt somit nicht anbieten muss.

Durch das Erstellen eines Prototyps des Produkts kann zusammen mit den Benutzern experimentell erarbeitet werden, ob vorhandene Anforderungen stimmen oder sogar noch neue hinzukommen, die vorher nicht bedacht wurden. Bei der aktiven Arbeit am Prototypen fällt den Benutzern schnell auf, was noch nicht so umgesetzt ist, wie gewünscht.

Liste der identifizierten Geschäftsvorfälle, die das System abdecken soll

Kontext des Systems / Systemgrenzen

Ein Anwendungsfall ist die Beschreibung einer durch das Produkt zu erbringenden Leistung aus Sicht des Akteurs. Ein Anwendungsfall wird durch einen Akteur initiiert und führt zu einem für diesen wahrnehmbaren Ergebnis

Anforderungen werden aus Anwendungsfällen abgeleitet.