Viele Köche verderben den Brei

Viele Köche verderbenden Brei

Bürgerkolleg 2000Hochschule Anhalt (FH)Fachbereich Informatik

Prof. Dr. Michael Worzyk

Softwaretechnik

04/20/23 15:23 Softwaretechnik 2

Agenda

• Programmfehler• Komplexität von Software• Besonderheit von Software• Werkzeuge• Methoden


Programmfehler

Am 4. Juni 1996 startete die ESA eine unbemannte Rakete mit vier Satelliten an Bord von Französisch Guyana aus.

40 Sekunden nach dem Start explodierte die Ariane 5.

Verlust ca. 500 Millionen Dollar für Rakete und Satelliten. Entwicklungskosten ca. 7 Milliarden Dollar.


ProgrammfehlerUrsache für den Absturz: Der Bordcomputer stürzte 36.7 Sek. nach dem Start

ab als er versuchte, den Wert der horizont. Geschwindigkeit von 64 Bit Gleitkommadarstellung in 16 Bit signed Integer umzuwandeln:

Die entsprechende Zahl war grösser als 215=32768 und erzeugte einen Overflow. Das Lenksystem brach zusammen und gab die Kontrolle an eine zweite, identische Einheit ab.

Selbstzerstörung wurde ausgelöst, da die Triebwerke abzubrechen drohten.


ProgrammfehlerPentium Prozessor Divisions-Fehler 1994 Beispiel: x = 4195835.0 y = 3145727.0 z = x - (x/y) * y Bei exakter Rechnung und fehlerfreiem

Prozessor: 0 Pentium liefert als Ergebnis: 256Rückrufaktion: 475 Millionen Dollar


Programmfehler

Ursache: INTEL verwendet einen speziellen und

schnellen Divisions-Algorithmus, den Radix-4 SRT Algorithmus:

Zwischenergebnisse werden aus einer Tabelle abgelesen. In dieser Tabelle fehlten 4 von 1066 Einträgen.


Programmfehler

Bei der Neueröffnung des Flughafens in Denver sollte ein voll automatisches Gepäcksystem verwendet werden.

300 Computer, Laserscanner,Photozellen, Ethernet-Netzwerk

Eröffnung des Flughafens wegen Fehler im Gepäcksystem um 16 Monate verspätet.

Zerquetschte, verlorene Koffer usw. Verlust: ca. 3.2 Milliarden Dollar


ProgrammfehlerTeilursache: Zu viele Nachrichten über Ethernet. Sortier-Anweisungen kamen nicht

rechtzeitig wegen Überlastung des Netzwerks (LAN).

Gesamtproblem zu komplex. http://www.forwiss.tu-muenchen.de/~baumann/

bugs.htmlhttp://catless.ncl.ac.uk/Risks/


Komplexität von Software

10 MOI

20 MOI

30 MOI

40 MOI

50 MOI

60 MOI1960 1970 1980 1990 2000

MOI: Millionen Objektcode-InstruktionenEWSD: Elektronisches Wählsystem DigitalQuellen: Boehm 87, S.45 und Siemens (Unterlagen zum Seminar IndustrielleSoftware-Technik, Deutsche Informatik-Akademie Bonn 588)

MERCURY

APOLLO

SPACESHUTTLE

EWSD-APSDBP-14

EWSD fürBB-ISDN

LUNARMISSIONCONTROL

EWSD-APSWM4.2

GEMINI

7 % jährlichesProduktivitäts-wachstum


Entwicklungsdauer

Quellen: TRWDoDGEI, entnommen aus Scharf 88, S. 62

Technische Programme Kommerzielle Programme

Jah

reE

ntw

ickl

ung

szei

t

0,81

3,5

2,3

4,2

6,5

0

1

2

3

4

5

6

7

1975 19801990 19751980 1990


Teamgröße

Softwareentwicklung geschieht in TeamsTeamgröße

3 bis 50 Personen

Projektgröße 36 bis 1500 Personenmonate


Nachfrage

1980 1982 1984 1986 1988 1990 1994

0,5

1,0

1,5

2,0

2,5

Software-Nachfrage(+10–25% Jahr)

Nachfrage-lücke

Produktivitäts-steigerung(+4% Jahr)

Personal-Zuwachs(+4% Jahr)

1992

Quelle: G. Koch, European IT Conference, Brussels, June 1994

Software-Personal(in Mio.)(normiertauf 1980)


SoftwareSoftware ist ein immaterielles ProduktSoftware unterliegt keinem VerschleißSoftware wird nicht durch physikalische

Gesetze begrenztSoftware ist i. allg. leichter und schneller

änderbar als ein technisches ProduktSoftware ist schwer zu »vermessen«.


Softwaretechnik

Zielorientierte Bereitstellung und systematische Verwendung von

Prinzipien,Methoden,Konzepten,Notationenund Werkzeugenfür die arbeitsteilige, ingenieurmäßige

Entwicklung und Anwendung von umfangreichen Software-Systemem

H. Balzert


zielorientiertQualität Quantität

Projektdauer Kosten

+

++

+

- -

--


Werkzeuge

Projektmanagement Programme

CASE-Tools

Computer Aided Software

Engineering

Programmierumgebungen

Testumgebungen


ProjektmanagementNr. Vorgangsname Dauer

1 SE 1.1 Externe Vorgaben 0 Tage

2 SE 1.2 Anwendungssystem beschreiben 1 Tag

3 SE 1.5 Handbuch erstellen 1 Tag

4 SE 2.1 System technisch entwerfen 1 Tag

5 SE 3.4 Anforderungen an die Qualität der SW-Einheit definieren 1 Tag

6 SE 4.1-SW SW-Architektur entwerfen 1 Tag

7 SE 4.3 Datenkatalog erstellen 1 Tag

8 SE 5.1 ERD erstellen 1 Tag

9 SE 6.2 Datenbank realisieren 1 Tag

10 SE 6.1.1 Maske Profil erstellen 1 Tag

11 SE 6.1.2 Maske Eingabe erstellen 1 Tag

12 SE 6.1.3 Maske Anzeigen erstellen 1 Tag

13 SE 7.3 Zur SW-EinheitEingabe integrieren 1 Tag

14 SE 8.1 Zum System integrieren 1 Tag

15 SE 9.3 System in Betrieb nehmen 1 Tag

16 QS 1.1 QS-Plan erstellen 1 Tag

17 QS 2.1 Prüfmethoden und -kriterien festlegen 1 Tag

18 QS 2.3 Prüffälle festlegen 1 Tag

19 QS 4.2 Produkt inhaltlich prüfen 1 Tag

20 KM 1.1 KM-Plan erstellen 1 Tag

21 PM 1.3 Projektspezifisches V-Modell erstellen 1 Tag

22 PM 1.4 Methoden und werkzeuge erstellen 1 Tag

23 PM 1.5 Grobplan erstellen 1 Tag

24 PM 4 Feinplan 1 Tag

25 PM 8 Projekt-Controlling 10 Tage

29.08.

M D F S S M D M D F S S M D M D F S S M D M D F S S M D Mg '00 28. Aug '00 04. Sep '00 11. Sep '00 18. Sep '


CASE-Tools


Programmierumgebung


NotationenBeschreibung eines Sachverhaltes

durch SymboleBeispiel:Selektion innerhalb eines ProgrammsWenn eine Bedingung zutrifft, mach

dieses, wenn sie nicht zutrifft, mach jenes


ProgrammablaufplanSelektion:


StruktogrammSelektion:

Else

Bedingung

xThen

Bedingung

x1

2

3


Klassenstruktur

m_ p A d re sse

0 ..1

ad

ress

e

Au

ftra

gg

eb

er

m_ p L e ite r

0 ..1

m_ p ro je kte n d e n

0 ..*

CAdresse(P ro je kt)

-m_ stra sse :

P tS trin g-m_ p lz:

P tS trin g

-m_ o rt: P tS trin g-m_ la n d : P tS trin g

CPerson(P ro je kt)

-m_ n a me :

P tS trin g-m_ vo rn a me :

P tS trin g

# m_ p A d re sse : CA d re sse# m_ a lte r: in t

CMitarbeiter(P ro je kt)

# m_ zimme rn u mme r:

P tS trin g# m_ te le fo n n u mme r:

P tS trin g# m_ sta mmn u mme r:

in t

CAuftraggeber(P ro je kt)

-m_ a u ftra g g e b e rn u mme r:

in t# m_ n a me :

P tS trin g# m_ te le fo n n u mme r:

P tS trin g# m_ p a d re sse :

CA d re sse

CProjekt(P ro je kt)

# m_ n a me :

P tS trin g# m_ b e sch re ib u n g :

P tS trin g# m_ p L e ite r:

CMita rb e ite r# m_ p A Uftra g g e b e r:

CA u ftra g g e b e r# m_ a n fa n g :

P tDa te# m_ p ro je kte n d e n :

CP ro je kte n d e

CProjektende(P ro je kt)

# m_ e n d e :

P tDa te# m_ g ru n d :

P tS trin g

m_p

adre

sse

0. .

1

m_p

Auf

trag

gebe

r

0. .

1


KonzepteModellierung eines definierten

Sachverhales– Programmablaufplan (DIN 66001)– Struktogramm (Nassi-Shneiderman

Diagramm)– Entity Relation Diagramm– Entscheidungstabelle


GetränkeautomatGroschenröhre = 1050-Pfg-Röhre = 10Markröhre = 10immer

Groschenröhre < 5 oder 50-Pfg-Röhre < 5 oder Markröhre < 5 ?

Bitte abgezähltes Geld einwerfennein ja

Eingeworfenes Geld zählenKosten = Kosten des ausgewählten Produktssolange bis Eingeworfenes Geld >= Kosten

Eingeworfenes Geld zählen

1 DM auswerfenEingeworfenes Geld = eingeworfenes Geld-100Markröhre = Markröhre - 1

50 Pfg auswerfenEingeworfenes Geld = eingeworfenes Geld-10050-Pfg-Röhre = 50-Pfg-Röhre - 1

Groschen auswerfen usw.

Ware auswerfensolange bis Eingeworfenes Geld-Kosten<100 oder Markröhre = 0

solange bis Eingeworfenes Geld-Kosten<50 oder 50-Pfg-Röhre = 0

solange bis Eingeworfenes Geld-Kosten=0 oder Groschenröhre = 0

Eingeworfenes Geld in die Röhren sortieren


ERDPatientenaufnahme

Patient

Aufenthalt

Adresse

Informant

Angehöriger

Notfall

Station

Pflegesatz

Kostenträger

Hauptversicherter

Leistung

Sonderrechnungsempfänger

Arzt

1

6

2

43

8

5

7Arbeitgeber10

9

12

14

11

15

13

16

B.Rassmann,

G.Tusch


MethodenVorgehensmodelle

WasserfallmodellV-ModellObjektorientiertes VorgehenPrototyping

TestmethodenInspektionBlackboxPfadüberdeckung


Software Entwicklung Projektmanagement

EDV Phasen

RealisierungEinführung

ProjektinitierungVorstudieFachkonzeptDV-Design

Gewährleistung

Qualitätssicherung

Dokum

entation


Wasserfallmodell

Anforderungen

Design

Realisierung

Testen

Produktion


V - ModellMachbarkeitsstudie

Pflichtenheft

Grobkonzept

Feinkonzept

Realisierung

Modultest

Integrationstest

Einführung

Produktion


Objektorientierte Softwareentwicklung


Prototyping

• exploratives (provokatives)

• experimentelles

• evolutionäres


Fehlerkosten


Inspektion (Review)Formaler BewertungsprozessDie Teilnehmer müssen vorbereitet seinEs wird das Produkt geprüft, nicht der

ProduzentEs wird ein Protokoll erstelltEs gibt eine Erledigungsliste der

Korrekturen-> Frühe und umfassende

Mängelaufdeckung


Blackboxtest

Es wird das Ein- Ausgabeverhalten des Programms getestet, nicht die interne Struktur

Besipiel: Umwandlung Jahrestag -> Datumz.B.: Tag 100 -> 10.April


Testfälle

Sinnvoll: 1, 0, -1, 60 (28. oder 29. Februar),

365, 366, 367weniger sinnvoll:2, 3, 100, 101, 102


Pfadüberdeckung

Alle möglichen Verzweigungen des Programms werden betrachtet.

Es werden die Testfälle so konstruiert, dass jeder mögliche Pfad durch das Programm durchlaufen wird.


Prinzipien

Ziel der Softwaretechnik ist es,

qualitativ hochwertige Programme

in einem vertretbaren Kosten- und

Zeitrahmen herzustellen.

Documents

Viele Köche verderben den Brei