zuverlässigkeit von computerprogrammen · Friedrich-Alexander-Universität Erlangen-Nürnberg Lehrstuhl für Software Engineering z uverlässigkeit von c omputerprogrammen durch

Friedrich-Alexander-UniversitätErlangen-Nürnberg

Lehrstuhl fürSoftware Engineering

zuverlässigkeit von computerprogrammen

durch software engineering erlangen

Francesca SagliettiAntrittsvorlesung

Tag der InformatikFriedrich-Alexander-Universität Erlangen-Nürnberg

Erlangen, den 26. April 2002



Gegenstand des Software Engineering ist:die ingenieurmäßige Entwicklungkomplexer, umfangreicher Softwaresystemehoher Qualität unter Berücksichtigungder einzusetzenden Arbeits- und Zeitressourcen.

1. Problemkomplexität Größe [SW] > 20 K LOC

2. Qualitätsvorgaben Zuverlässigkeit, Wartbarkeit

3. Kostenlimits Geld, Personal

4. Terminvereinbarungen Lieferung, Genehmigung

Software EngineeringZielsetzung



Lernen aus Fehlerszenarien“Learn from the mistakes of others,...

you'll never live long enough to make them all yourself.“

�Ariane 5 Explosion

�LH Airbus 320 Unglück bei Landung

�Therac 25 Verstrahlung mehrerer Patienten

�Scheitern der Mars Probe Mission

�Rechnerabsturz der Berliner Feuerwehr

�Scheitern des Patriot-Abwehrsystem bei Scud-Rakete

�Inkorrekte Diagnosen d. Fehlbedienung in Blutdatenbank

�Explosion einer chemischen Fabrik



“... the application of a

systematic, disciplined, quantifiable approach

to the development, operation, and maintenance of software;

that is, the application of engineering to software“.

IEEE Computer Society

Software Engineering is ...



Historischer Hintergrund

1967 Study Group of NATO Science Committee1968 Arbeitstagung in Garmisch

F.L. Bauer “There is so much tinkering with software… what we need is software engineering”.

B. Randell “deliberately chosen as being provocative…need for theoretical foundations and practical disciplines,traditional in the established branches of engineering.”

Software Krise(n)

Ausgangslage: niedrige Qualität, zu spät, zu teuer

Heutige Lage: niedrige Qualität, zu spät, zu teuer



Vergleich mit klassischen Ingenieurwissenschaften

Herleitung konstruktiver Prinzipienaufgrund naturwissenschaftlicher und empirischer Erkenntnisse

Mechanik, Thermodynamik

Elektrizitätslehre, MagnetismusStatik, WerkstoffwissenschaftenChemie

Informatik /Computer Science

Maschinenbau

Elektrotechnik

Bauwesen

Verfahrenstechnik

Software Engineering

NaturwissenschaftIngenieurwissenschaft



�Unreife 50-Jahre alt, Brückenbau > 3000 Jahre�Komplexität Normierung, Skalierung schwieriger�Konformität den Letzten beißen die Hunde�Flexibilität nur scheinbar leicht Änderbarkeit�Immaterialität ...nicht zu fassen!�Unstetigkeit keine Sicherheit d, Überdimensionieren�Haftung “Bananen-Software“ reift beim Kunden�Unveränderlichkeit Perfektion prinzipiell möglich!�Einmaligkeit nur einmal produziert�Menschliche Faktoren selber schuld!

Software cannot be engineered?

Unterschiede zu klass. Ingenieurwissenschaften



.

Vorgaben aus realer Welt: Mensch (Kunde), Rechner,

technische Prozesse

Ausgaben an reale Welt: Mensch (Operateur),

Rechner, technische Prozesse

Einsatz von Logikzur Überbrückung nicht-formaler Domänen

Ein- und Ausgaben beziehen sich auf reale Welt mit Gesetzen der Physik



“...It has been saidthat Newton designed it,

and that it was so elegantly constructed it needed only

mathematical principles, rather than screws or nails,

to hold it together.“

Queens' College

Cambridge Mythology: Mathematical Bridge

... but:the original bridge was built 1749 (22 years after Newton‘s death) by James Essex the Younger (with screws).



Heterogene Domänen

4 Ps

� ProjektGesamte Koordination

Alle 4 Aspekte kontrollieren, also messen!"You cannot control what you cannot measure!“ (Tom De Marco)

� PersonalWer entwickelt?

� ProzessWie wird entwickelt?

� ProduktWas ist das Ergebnis?



Personal AusbildungSWE-BOK Body of Knowledge ACM / IEEEECTS Curricula “on demand“

Messinstrumentarium

Kosten, Reife, Bildung

Projekt AufwandCOCOMO Cost Control ModelFPA Function Point Analysis

Prozess Reifegrad, TransparenzCMM Capability Maturity Model SEISPICE Software Process Improvement



bei SW-Erstellung

Menschliche Faktoren

Psychologische Faktoren, Hintergrundwissen

�Transiente Irrtümervorübergehende Unachtsamkeit

�Individuelle UnvermögenBildung, Begabung,Konzentrationsfähigkeit

�Überindividuelle DenkfallenGrenzen des menschlichen Denkens



Begrenztheit der Ressourcen (Gedächtnis, Verarbeitungsfähigkeit)

Scheinwerferprinzip: Konzentration auf das WesentlicheSparsamkeitsprinzip: Ökonomie durch falsche Hypothesen

Steuerung des Wissenserwerbs

Prägnanztendenz: Erwartung von GesetzmäßigkeitLineares Kausaldenken: 1-dimensionale Ursache-Wirkungs-Kette

Grenzen menschlicher Wahrnehmung

William of Ockham (1285- 1349)



z.B. wenn „Quelle verseucht“:

60% - 70% aller Fehler sindSpezifikations- und Entwurfsfehler

Trotz aller Sorgfalt an Personal, Prozess und Projektkann das Produkt schlecht sein

Clean pipes, dirty water?



� Irrtum mistake Vermeidenmentaler Vorgang ↓ !

� Produktfehler fault Erkennen(Zwischen-)Produkt ↓ ?

� Zustandsfehler error Behebeninterner Zustand ↓ ?

� Versagen failure MaskierenVerhalten

Fehlerarten

Abweichung Maßnahmezwischen Absicht und Realisierung

Maßnahmen zur Beherrschung



Ermittlung und Analyse der AnforderungenWozu? Warum? Ob?

Spezifikation der Anforderungen / ProjektplanungWas? welche Zwischenergebnisse?bis wann? wie teuer?

Entwurf / Umsetzung der AnforderungenWie insgesamt aufgebaut? Wie im einzelnen?

Implementation / Integration

Installation, Nutzung, Wartung, Ablösung

Lebenszyklus



Absichten Aufgaben

Anforderungsspezifikation

Systementwurf

SW-Grobentwurf

SW-Feinentwurf SW-Moduln

Integrierte SW-Moduln

Integriertes System

Installiertes System

Genutztes System

V-Modell

spiegelsymmetrisch als Λ-Modell

Validierung

richtige Aufgabe gelöst

Verifikation

Aufgabe richtig gelöst



Verifikationkann auf vollständig formalisierbarem Nachweis basieren

�Theorem-Beweiser: {Axiome} � Aussage�Gödel, 1931: der Nachweis braucht nicht zu existieren

�Turing, 1936: der Nachweis braucht nicht automatisierbar zu sein

Nachweis interaktiv: erzeuge Beweisverpflichtungen, entlaste manuell

�Beweis-Checker: {Beweisregeln, Beweis} � Korrektheit�prüft korrekte Anwendung deduktiver Beweisregeln

Theoretische Grenzen der Verifikation

Kurt Gödel, Alan Turing



Validierung i.a. nicht vollständig formalisierbarmuss auf empirischen Beobachtungen basieren

�Popper, 1935:empirisch-wissenschaftliche Theorien können nicht verifiziert,sondern höchstens widerlegt werden (Falsifikationskriterium)

Statistisches Testen (Simulation & Stichprobentheorie)zu beliebiger Aussagesicherheit α bestimme untere Schranke R‘der Überlebenswahrscheinlichkeit R: P {R > R‘} > α

Model Checking: {spez. System} � Eigenschaftbei endlichen Automaten vollst. automatischer Nachweis bzw.Widerlegung von Eigenschaften in temporaler Logik (CTL)

Theoretische Grenzen der Validierung

Karl Popper



“An Essay Concerning Human Understanding„ 1690

�Bewusstsein ist unbeschriebene Tafel tabula rasa

�einfache Eindrücke aufnehmen Sinnesideen

�einfache Eindrücke ordnen / zusammensetzen Reflexionsideen

John Locke

Thesen zum menschlichen Verständnis



�AbstraktionErsetzung komplexer Strukturen durch OberbegriffeVorteile:

�Verständnis solcher Strukturen jeweils einmal erforderlich,�Wiederverwendung einfach

�Teile und herrsche�hohe Kohäsion starke funktionale Bindung�lose Kopplung geringer Datenaustausch

Menschliche Strategien

zur Beherrschung der Komplexität



Abstraktionsebenen

Abstraktionsebene

�Programmierstil�Höhere Programmiersprachen: Maschinenbefehle

�strukturierte Programmierung: Programmablauf: Sequenz, if, while

�Modulare Programmierung: funktional zs. gehörige SW-Teile

�Objekt-orientierte Progr. Datenobjekte, Operationen / Attribute

�Entwurfsstil�Entwurfsmuster: Entwurfsschritte

�Off-the-Shelf-Software: ganze Programmpakete

Programmier- und Entwurfsstilrichtungen



“Ausmaß an Hilfsmitteln, von einem System benötigt,um mit einem Software-Teil zu interagieren.”

Spezialfall: interagierendes System besteht aus Menschenerforderlicher menschlicher Aufwand, um Software zu:

� Verstehen: unabhängig rekonstruieren� Wiederverwenden: Funktionalitäten dem Code zuordnen� Instandsetzen: Fehler entfernen� Verändern: um neu Funktionalitäten erweitern

an neue Umgebung anpassen� Testen: repräsentative Testfälle auswählen� Beweisen: formale Korrektheit nachweisen

Komplexität

Victor Basili



Prozess: Software-bezogene Tätigkeit(Spezifizieren, Entwerfen, Codieren, Testen,…)

Produkt: Ergebnis eines Prozesses(Spezifikation, Entwurf, Code, Testfälle, …)

Ressource: Eingabe zum Prozess(Personal, Software, Hardware, Arbeitsumgebung, …)

Interne Attribute: Eigenschaften, die sich direkt messen lassen

Beispiele:Produkt: Länge (LOC), Wortschatz, Verzweigungen im KontrollflussProzess: Zeitaufwand, Anzahl beobachteter VersagensfälleRessource: Preis, Geschwindigkeit, Alter

Was kann man messen?

Interne Attribute



“... am eigenen Haarzopfe herausgezogen...“

Was möchte man messen?

Externe Attribute:Eigenschaften, die sich nur indirektanhand der Auswirkungenauf ihre Umgebung messen lassen.

Beispiele:Produkt: Zuverlässigkeit, ÄnderbarkeitProzess: Kosteneffizienz, TransparenzRessource: Einsetzbarkeit, Benutzerfreundlichkeit

Externe Attribute durch Interne bestimmen!

Externe Attribute



Anzahl unterschiedlicher Operatoren u. Operanden: n1, n2

Programmwortschatz: n = n1 + n2

Gesamtanzahl vorkommender Operatoren u. Operanden: N1, N2

Programmlänge: N = N1 + N2

Programmvolumen: V = N ld(n) Auswahlvorgängeminimales Volumen: V* höchste Abstraktionsebene

Abstraktionsniveau: L = V* / VMentaler Aufwand: E = V / L direkt zum Volumen

indirekt zum Abstraktionsniveau

Messung des Abstraktionsniveaus

Halstead's "Software Science"



�Kontrollflussgraph G�n Knoten (sequentielle Code-Blöcke)�e Kanten

�Komplexitätsmaß�ν[G] = e - n + 2

gibt maximale Anzahl linearunabhängiger Programmpfade an.

Verifiziere Basis aus Pfaden:weitere Programmausführungensind Linearkombinationenbereits verifizierter Pfade.

Messung der Dimension des Kontrollflussraums

McCabe’s zyklomatisches Maß



Stärke der funktionalen Bindung

�Daten-Kohäsion:

�funktional: nur Elemente zur Lösung einer Aufgabe

�sequentiell: Ergebnisse nacheinander weiterverarbeitet

�kommunikativ: gemeinsame Daten, verschiedene Aufgaben

�Kontroll-Kohäsion:�prozedural: Kontrolle von einer Aktivität an nächste

�zeitlich: unabhängige Teilfunktionenin zeitlichem Zusammenhang aktiviert

� Zufällige Kohäsion: "zufallgesteuertes" Modularisieren

Kohäsion



Messung der funktionalen Bindung

Ri: Knoten des Kontrollflussgraphen mit Bezug auf Variable i

|G|: Anzahl der Knoten im gesamten Kontrollflussgraphen G

Kohäsionsmaß der i-ten Variablen:

Modul-Kohäsionsmaß von Emerson: ( ) ( )�κ⋅ν

=κ=

v

1ii G,R

1:G

( ) [ ][ ] GG

RR:G,Rii

i ⋅ν⋅ν

=κ

Emerson‘s Kohäsionsmetrik

Daten-Kohäsion > Kontroll-Kohäsion > Zufällige Kohäsion



s Pfadsegmente�Statement Testing: Anteil ausgeführter Anweisungen ΟΟΟΟ(s)

�Branch Testing: Anteil ausgeführter Alternativen ΟΟΟΟ(s)

�Boundary Testing: Anteil ausgeführter Pfade ohne Iterationen

�Interior Testing: Anteil ausgeführter Pfade mit einer Iteration

�Structured Path T.: Anteil ausgeführter Pfade mit ≤≤≤≤ k Iterationen ΟΟΟΟ(2s)

�Path Testing: Anteil aller ausgeführter Pfade (→→→→ ∞∞∞∞)

Messung strukturellen Testens

durch Überdeckungsmaße



durch Trendmodelle

Messung der Testeffektivität

Berücksichtigung inkorrekter Testläufe:

� wenn Versagen beobachtet:entferne Fehler

� zwischen 2 Versagen:Bayes‘sche Zeitmodelle

jeweils neue Produkte getestet:geringe Aussagesicherheit!

Zeit

Versagensrate Korrektur

Bayes



Fehlertolerierende Architekturendiversitäre SW-Varianten

Varianten S, S’ unabhängig voneinander entstandenEingabe x gewählt nach Anforderungsprofil Q

Bewertungsfunktion VS(x):= 0, wenn x von S korrekt verarbeitet wirdVS(x):=1, sonst

Intensitätsfunktion Θ(x) := ES[VS(x)]

durchschn. Wahrscheinlichkeit für Einzelversagen: ES[ � VS(x) dQ ] = E[ΘΘΘΘ]

für Doppelversagen: ES,S‘‚ [� VS(x)·VS‘(x) dQ] = E[ΘΘΘΘ2] = E[ΘΘΘΘ]2 + Var[Θ]

BVerarbeitung der Eingabedaten i.a. unterschiedlich komplex (Var[Θ] ≠0)

Produktregel gilt i.a. nicht!



Messen der Versagensabhängigkeit

Experimentelle und theoretische Ansätze

haben bereits eine Reihe von Einflussfaktoren identifiziert, die sich schwächend auf Versagensabhängigkeit auswirken:

� Diversitäre Entwicklungsmethoden

angefangen mit funktionaler Diversität

�Frühe Überprüfung von Zwischenergebnissen

verhindert die Propagierung unterschiedlicher Fehlerin gemeinsame Richtungen



Wiederverwendbarkeitvorgefertigter Softwarebausteine

Durch Einsatz bereits vorliegender, bewährter Produkte:

� ökonomische Vorteile

� i. a. auch Zuverlässigkeitsgewinne, aber:

� Bewertung kann neue Probleme aufwerfen,da vorgefertigte Produkte i. a. zum Einsatzunter anderen Systemverhältnissenkonzipiert / zertifiziert

Zur Nachqualifizierung vorgefertigter Software:

Gegenüberstellungvorliegender Betriebserfahrungund neu anzustrebender operationaler Einsatzprofile



( )Ψ−

α−−≤1

hn1ln

p

��

��

γβ−γ

=ψj

jj

jmax:

Erwartetes künftiges Betriebsprofil ( ) γ=π jjC

β jAnteil der gesamten bisherigen Betriebserfahrungdie sich auf gleiche Anforderungsklasse bezieht

maximale relative Abweichung zwischen vergangener und künftiger Systembeanspruchung

Obere Schranke für Versagenswahrscheinlichkeitbzw.konservativer Wert für Zuverlässigkeit

Messung der Betriebsbewährung



Vorgaben aus realer Welt: Mensch (Kunde), technische Prozesse

Abgaben an reale Welt: Mensch (Operateur)

Rechner

Zusammenfassung



Kontrollfluss



nur wahre Aussagen...

... am Lehrstuhl 11

Documents

zuverlässigkeit von computerprogrammen · Friedrich-Alexander-Universität Erlangen-Nürnberg Lehrstuhl für Software Engineering z uverlässigkeit von c omputerprogrammen durch