zuverlässigkeit von computerprogrammen · Friedrich-Alexander-Universität Erlangen-Nürnberg...
-
Upload
vuongthuan -
Category
Documents
-
view
217 -
download
0
Transcript of zuverlässigkeit von computerprogrammen · Friedrich-Alexander-Universität Erlangen-Nürnberg...
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
Friedrich-Alexander-UniversitätErlangen-Nürnberg
Lehrstuhl fürSoftware Engineering
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
Friedrich-Alexander-UniversitätErlangen-Nürnberg
Lehrstuhl fürSoftware Engineering
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
Friedrich-Alexander-UniversitätErlangen-Nürnberg
Lehrstuhl fürSoftware Engineering
“... 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 ...
Friedrich-Alexander-UniversitätErlangen-Nürnberg
Lehrstuhl fürSoftware Engineering
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
Friedrich-Alexander-UniversitätErlangen-Nürnberg
Lehrstuhl fürSoftware Engineering
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
Friedrich-Alexander-UniversitätErlangen-Nürnberg
Lehrstuhl fürSoftware Engineering
�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
Friedrich-Alexander-UniversitätErlangen-Nürnberg
Lehrstuhl fürSoftware Engineering
.
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
Friedrich-Alexander-UniversitätErlangen-Nürnberg
Lehrstuhl fürSoftware Engineering
“...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).
Friedrich-Alexander-UniversitätErlangen-Nürnberg
Lehrstuhl fürSoftware Engineering
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?
Friedrich-Alexander-UniversitätErlangen-Nürnberg
Lehrstuhl fürSoftware Engineering
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
Friedrich-Alexander-UniversitätErlangen-Nürnberg
Lehrstuhl fürSoftware Engineering
bei SW-Erstellung
Menschliche Faktoren
Psychologische Faktoren, Hintergrundwissen
�Transiente Irrtümervorübergehende Unachtsamkeit
�Individuelle UnvermögenBildung, Begabung,Konzentrationsfähigkeit
�Überindividuelle DenkfallenGrenzen des menschlichen Denkens
Friedrich-Alexander-UniversitätErlangen-Nürnberg
Lehrstuhl fürSoftware Engineering
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)
Friedrich-Alexander-UniversitätErlangen-Nürnberg
Lehrstuhl fürSoftware Engineering
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?
Friedrich-Alexander-UniversitätErlangen-Nürnberg
Lehrstuhl fürSoftware Engineering
� 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
Friedrich-Alexander-UniversitätErlangen-Nürnberg
Lehrstuhl fürSoftware Engineering
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
Friedrich-Alexander-UniversitätErlangen-Nürnberg
Lehrstuhl fürSoftware Engineering
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
Friedrich-Alexander-UniversitätErlangen-Nürnberg
Lehrstuhl fürSoftware Engineering
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
Friedrich-Alexander-UniversitätErlangen-Nürnberg
Lehrstuhl fürSoftware Engineering
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
Friedrich-Alexander-UniversitätErlangen-Nürnberg
Lehrstuhl fürSoftware Engineering
“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
Friedrich-Alexander-UniversitätErlangen-Nürnberg
Lehrstuhl fürSoftware Engineering
�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
Friedrich-Alexander-UniversitätErlangen-Nürnberg
Lehrstuhl fürSoftware Engineering
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
Friedrich-Alexander-UniversitätErlangen-Nürnberg
Lehrstuhl fürSoftware Engineering
“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
Friedrich-Alexander-UniversitätErlangen-Nürnberg
Lehrstuhl fürSoftware Engineering
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
Friedrich-Alexander-UniversitätErlangen-Nürnberg
Lehrstuhl fürSoftware Engineering
“... 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
Friedrich-Alexander-UniversitätErlangen-Nürnberg
Lehrstuhl fürSoftware Engineering
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"
Friedrich-Alexander-UniversitätErlangen-Nürnberg
Lehrstuhl fürSoftware Engineering
�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ß
Friedrich-Alexander-UniversitätErlangen-Nürnberg
Lehrstuhl fürSoftware Engineering
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
Friedrich-Alexander-UniversitätErlangen-Nürnberg
Lehrstuhl fürSoftware Engineering
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
Friedrich-Alexander-UniversitätErlangen-Nürnberg
Lehrstuhl fürSoftware Engineering
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
Friedrich-Alexander-UniversitätErlangen-Nürnberg
Lehrstuhl fürSoftware Engineering
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
Friedrich-Alexander-UniversitätErlangen-Nürnberg
Lehrstuhl fürSoftware Engineering
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!
Friedrich-Alexander-UniversitätErlangen-Nürnberg
Lehrstuhl fürSoftware Engineering
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
Friedrich-Alexander-UniversitätErlangen-Nürnberg
Lehrstuhl fürSoftware Engineering
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
Friedrich-Alexander-UniversitätErlangen-Nürnberg
Lehrstuhl fürSoftware Engineering
( )Ψ−
α−−≤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
Friedrich-Alexander-UniversitätErlangen-Nürnberg
Lehrstuhl fürSoftware Engineering
Vorgaben aus realer Welt: Mensch (Kunde), technische Prozesse
Abgaben an reale Welt: Mensch (Operateur)
Rechner
Zusammenfassung