Software Engineering I

1
Vorlesung Software Engineering I

• Qualitätssicherung I
• Konstruktive QS

2
Definition Qualität

• Die Erfüllung von Qualitätszielen, die durch
  Vorgaben für Qualitätsmerkmale und ihre
  Teilmerkmale definiert sind
• Qualität ist der Grad, in dem von einem Satz
  inhärenter Merkmale (eines Produkts) die
  Anforderungen erfüllt werden. (DIN EN ISO
  90002005)
• Qualitätsmerkmale beziehen sich immer auf
  Anforderungen
• Funktionale Anforderungen (Fachlichkeit,
  Funktionen, Schnittstellen, ...)
• Nicht-Funktionale Anforderungen(Qualitäts- und
  Realisierungsanforderungen,Projektspezifische
  Anforderungen, ...)

Angelehnt an DIN EN ISO 90002005
Qualitätsmanagementsysteme Grundlagen und
Begriffe. Beuth Verlag, Berlin, 2005
3
Definition Software-Qualität

• Qualität DIN 55350, Teil 11
• Qualität ist die Gesamtheit von Eigenschaften
  und Merkmalen eines Produkts oder einer
  Tätigkeit, die sich auf deren Eignung zur
  Erfüllung gegebener Erfordernisse bezieht
• Software-Qualität DIN ISO 9126
• ist die Gesamtheit der Merkmale und
  Merkmalswerte eines SW-Produkts, die sich auf
  dessen Eignung beziehen, festgelegte oder
  vorausgesetzte Erfordernisse zu erfüllen
• Qualität ist die Übereinstimmung mit den
  Kundenanforderungen, und zwar die mit den
  tatsächlichen Anforderungen von den beteiligten
  Personen.
• Vertrieb will andere Qualitäten als der
  Entwickler als der Kunde als das Marketing !
• Die zu erreichenden Qualitäten müssen möglichst
  klar und verständlich spezifiziert und offensiv
  kommuniziert werden!
• Qualität entsteht während der Entwicklung und
  lässt sich nicht (oder nur sehr aufwändig) später
  einbauen.

4
Software-Qualität nach DIN/ISO/IEC 9126 (1)
Softwarequalität
ISO/IEC 91261991 Bewerten von Softwareprodukten,
Qualitätsmerkmale und Leitfaden zu ihrer
Verwendung (identisch mit DIN 66272, 94)
5
Software-Qualität nach DIN/ISO/IEC 9126 (2)
Softwarequalität
6
Qualitätsmerkmale Safety Security

• Weitere, oft wichtige Qualitätsmerkmale sind
• Schutz (safety)
• Schutz der Umwelt, LeibLeben vor dem System
• Sicherheit (security)
• Schutz des Systems vor der Umwelt, unerlaubtem
  Zugriff etc.
• Sie erfordern weitere separate Überlegungen und
  Maßnahmen
• (nicht Gegenstand dieser Vorlesung).

7
Übersicht Software-Qualitätsmerkmale
8
Qualitätsanforderungen

• Qualitätsanforderungen geben vor, welche
  Qualitätsmerkmale das Produkt in welcher Güte
  aufweisen soll (Qualitätsniveau).
• Gesamtheit aller Qualitätsmerkmale und deren
  geforderte Ausprägung.
• Nicht alle Qualitätsmerkmale lassen sich gleich
  gut erfüllen.
• Z.B. geht Effizienz oft zu Lasten der
  Wartbarkeit.
• Prioritäten festlegen
• In engster Absprache mit Auftraggebern und
  Anwendern.
• Qualitätsanforderungen sind Bestandteil der
  nicht-funktionalen Anforderungen im
  Pflichtenheft.

9
Software-Qualitätssicherung (SW-QS)
Qualitätssicherung
Analytische QS
Konstruktive QS
Normen, Standards,Prozessmodelle,Projektleitung,
Software-Technik,Software-Architektur,Erfahrung
saustausch,Ausbildungsmaßnahmen...
Ergebnisse
Prozesse
Audits
Dokumente
Reviews,...
Software
Testen
10
SW-QS im Entwicklungszyklus

• Konstruktive QS ? vermeide Fehler
• Analytische QS ? finde Fehler

Quelle http//de.wikipedia.org/wiki/SystemtestSy
stemtest
11
SW-QS im V-Modell
Review des Designs
12
Was ist ein Risiko?
No Risk No Fun!

• Risiko Problem, das in der Zukunft eintreten
  könnte und unerwünschte Folgen hat ein Faktor,
  der zu negativen Konsequenzen in der Zukunft
  führen könnte.
• Die Höhe eines Risikos ergibt sich aus der
  Wahrscheinlichkeit des Problemeintritts (W) und
  dem damit verbundenen Schaden (S)
• Risiken unterteilen sich in
• Projektrisiken und
• Produktrisiken

Risikodiagramm
R W S
13
Projektrisiken

• Risiken bezüglich der Erreichung der Projektziele
• Lieferantenaspekte
• Versagen einer dritten Partei, Vertragsaspekte
• Organisatorische Aspekte
• Qualifikation, Mitarbeiterengpässe, Personal- und
  Trainingsaspekte
• Politische Aspekte
• Kommunikationsprobleme in der Entwicklungsorganisa
  tion
• Nichteinhaltung von Prozessen
• Keine Nutzung von Erkenntnissen, die beim Testen
  oder in Reviews gefunden werden (z.B. keine
  Umsetzung von erkannten Verbesserungen der
  Entwicklungs- und Testpraktiken)
• Technische Aspekte
• Beschreibung der Anforderungen ist zu ungenau
• Unzureichende Qualität des Designs, des Codes und
  der Tests

14
Produktrisiken

• Risiken bezüglich des Produktes und seines
  Einsatzes
• Produkt könnte Geräten, Menschen oder
  Organisationen Schaden zufügen
• Produkt ermöglicht bzw. unterstützt kriminelle
  Handlungen (Viren, phishing, ...)
• Risiken bezüglich der Qualität des (gelieferten)
  Produkts
• Software ist fehlerbehaftet
• Nichterfüllung der geforderten/erwarteten
  Funktionen durch die Software
• Unzureichende Eigenschaften der Software(z.B.
  mangelnde Sicherheit, ungenügende
  Zuverlässigkeit, schlechte Benutzbarkeit und
  nicht ausreichende Leistungsfähigkeit/Performanz)

15
Risikomanagement

• Risikomanagement ist die systematische Anwendung
  von Praktiken für die Aufgaben der
  Risikoidentifizierung, Risikoanalyse,
  Risikopriorisierung und Risikosteuerung zur
  Verhinderung von Fehlschlägen.
• Aktivitäten
• Ermittlung des Risikokontextes
• Risikoidentifikation
• Risikoanalyse und -priorisierung
• Risikosteuerung und -bewältigung
• Risikoüberprüfung und überwachung

16
Risikoliste
LegendeW - Wahrscheinlichkeit des Auftretens (1
vernachlässigbar, ... , 9 sehr hoch)S -
Schaden (nichtlineare Abbildung auf (Geld-)Werte
z.B. 1, 10, 50, 100, 500, 1000)RPZ -
Risikoprioritätszahl (RPZ S W)Indikator -
Messgröße zur Ankündigung eines bevorstehenden
RisikoeintrittsTrigger - Schwellwert mit
Einleitung der Maßnahmen zur Risikobekämpfung
(z.B. Fail-Eing.Test - bei mehr als 3
fehlgeschlagenen Eingangstest pro Tag
sind als Maßnahme vermehrt Code-Reviews
durchzuführen.)
Tabelle ausSpillner, Roßner, Winter, Linz
Praxiswissen Softwaretest Testmanagement.
dpunkt verlag, Heidelberg, 2006, S. 191
17
Risikoorientierter QS-Ansatz

• Pro-aktive Möglichkeit zur Reduzierung des
  Produktrisikos, beginnend mit Projektstart
• Identifikation von Produktrisiken und ihre
  Berücksichtigung bei der Steuerung der
  konstruktiven und analytischen Qualitätssicherung
• Identifizierte Risiken bestimmen
• Welche konstruktiven Maßnahmen zu Risikoreduktion
  notwendig sind (z.B. die Bereitstellung von
  Schulungsmaßnahmen für unerfahrene Designer)
• die einzusetzenden Testtechniken und den Umfang
  der Tests
• die Priorisierung der Tests mit dem Ziel,
  kritische Fehler so früh wie möglich zu finden

18
Fehler möglichst früh finden ...

• ... denn Fehlerkosten steigen rapide über die
  Entwicklungsphasen an
• Ein Fehler, der sehr früh entsteht (z.B. ein
  Fehler in der Anforderungsdefinition), kann,
  solange er unentdeckt bleibt, in den
  anschließenden Entwicklungsphasen viele
  Folgefehler produzieren (Multiplikation des
  Effekts des ursprünglichen Fehlers)
• Je später ein Fehler entdeckt wird, umso mehr
  Korrekturen sind notwendig. Unter Umständen
  müssen vorangegangene Phasen (Anforderungsdefiniti
  on, Design, Programmierung) zumindest teilweise
  wiederholt werden
• Fehlerrisiko senken durch konstruktive Maßnamen
• Fehlerrisiko begrenzen durch frühzeitige
  analytische Maßnahmen (Prüfungen und Tests)

19
Fehler und Folgefehler

• Anforderungs-definition,Fachkonzept
• Entwurf
• Realisierung
• Produktion

20
Fehlerursprung und Entdeckung
Anforderungen
Design
Codierung
Dokumentation
Test
Wartung
Fehler- ursprung
Fehler- entdeckung
Anforderungen
Design
Codierung
Dokumentation
Test
Wartung
Mit Einsatz formaler Inspektionsmethoden
21
Konstruktive QS Normen und Standards (1)

• Zu den Aufgaben der konstruktiven QS gehört es
  festzustellen, welche Normen, Standards oder
  evtl. gesetzliche Richtlinien für das zu testende
  Produkt (Produktnormen) oder auch für das Projekt
  (Prozessnormen) relevant sind, und deren
  Einhaltung sicherzustellen.
• Firmenstandards
• Firmeninterne Richtlinien und Verfahrensanweisunge
  n (des Herstellers und ggf. des Kunden), wie z.B.
  Qualitätsmanagement-handbuch, Rahmentestplan,
  Programmierrichtlinien
• Best Practices
• Nicht standardisierte, aber fachlich bewährte
  Vorgehensweisen und Verfahren, die den Stand der
  Technik in einem Anwendungsgebiet darstellen.

22
Konstruktive QS Normen und Standards(2)

• Qualitätsmanagementstandards
• Branchenübergreifende Standards, die
  Mindestanforderungen an Prozesse spezifizieren,
  ohne konkrete Anforderungen bezüglich der
  Umsetzung zu formulieren.
• Bekanntes Beispiel ist ISO 9000, die z.B.
  fordert, dass im Produktionsprozess (also auch im
  Spezialfall Software-entwicklungsprozess)
  geeignete (Zwischen-)Prüfungen vorzusehen sind,
  ohne anzugeben, wann und wie diese zu erledigen
  sind

ISO 9000 ISO 90002000Qualitätsmanagementsystem
e Grundlagen und Begriffe.
23
Konstruktive QS Normen und Standards(3)

• Generische Standards
• Die IEC 61508 ist als Sicherheits-Grundnorm
  (i.S.v. Safety) ausgewiesen, das heißt sie kann
  als Basis für anwendungs- /branchenspezifische
  Normen dienen.
• Branchenstandards
• Branchenspezifische Standards, beispielsweise
• DIN 60601-1-4 für Medizinprodukte,
• RTC-DO 178B für Software in Flugzeugen,
• EN 50128 für Bahn-Signalsysteme,
• die für eine bestimmte Produktkategorie oder ein
  Einsatzgebiet festlegen, in welchem Mindestumfang
  Tests durchzuführen oder nachzuweisen sind

DIN 60601-1-4 DIN EN 60601-1-4, Ausgabe
2001-04 Medizinische elektrische Geräte Teil
1-4 Allgemeine Festlegungen für die Sicherheit
Ergänzungsnorm Programmierbare elektrische
medizinische Systeme RTC-DO 178B RTC-DO Std
178B, Software Considerations in Airborne
Systems and Equipment Certification, RTCA, Inc.,
1992 EN 50128 EN 501282001Railway
applications Communication, signalling and
processing systems Software for railway control
and protection systems, European Committee for
Electrotechnical Standardization
24
Konstruktive QS Normen und Standards (4)

• Softwareteststandards
• Prozessstandards, die produktunabhängig
  festlegen, wie Softwaretests fachgerecht
  durchzuführen sind
• Beispiele sind die Normen ISO 9126, BS
  7925-2, IEEE 829, IEEE 1028

ISO 9126 ISO/IEC 9126 Teile 1-4 Software
Engineering - Product Quality, 2001 Part 1
Quality model Part 2 External Metrics Part 3
Internal Metrics Part 4 Quality in Use
Metrics BS 7925-2 British Standard
7925-2 Software testing, Part 2 Software
component testing, 1998 IEEE 829 IEEE Std
829-1998 IEEE Standard for Software Test
Documentation IEEE 1028 IEEE Std
1028-1997 IEEE Standard for Software Reviews
25
Analytische QS Risikoorientiertes Testen

• Riskoorientiertes Testen bietet Auskunft über
  verbleibende Risiken
• Beim risikoorientierten Testen werden das Wissen
  und die Kenntnisse der Stakeholder genutzt, um
  Risiken zu identifizieren und die erforderlichen
  Tests zum Behandeln der Risken zu bestimmen
• Zusätzlich kann Testen
• die Identifikation neuer Risiken unterstützen
• helfen festzulegen, welche Risiken reduziert
  werden sollen
• die Unsicherheit bezüglich der Risiken verringern

26
Was sind Software-Fehler ?
27
Moderne Kunst im Software-Engineering ?
28
Der erste Bug

• Eine Motte im Rechner Mark II verursacht Fehler
  in Relay Nr. 70, Panel F.
• Mrs. Grace Murray Hopper (Amazing Grace)
• beseitigt den Fehler und dokumentiert ihn im
  Log-Buch.First actual case of bug being
  found. offen-sichtlicher Fehler!
  Beseitigung ist einfach!

9.9.1945 1545
http //www.hopper.navy.mil/grace/grace.htm
29
Auswirkungen von Software-Fehlern

• NASA - Erdbeobachtungssatelliten 1979-1985
• Ozonloch 7 Jahre (!) lang nicht erkannt
• Ursache Softwarefehler Veränderung der
  Ozonschicht als Sensordrift durch automatische
  Nullpunktkorrektur herausgemittelt
• ESA, Kourou, Franz. Guyana, 4. Juni 1996
• Selbstzerstörung der Ariane 5 beim Jungfernflug
  39 Sekunden nach dem Start
• Ursache Softwarefehler Lageregelungssoftware
  aus Ariane 4 ohne Test in Ariane 5
  wiederverwendet,Konvertierungsfehler.
• Bemannte NASA-Raumkapsel Gemini V
• Verfehlte Landeplatz um ca. 160 Kilometer
• Ursache Softwarefehler Rotation der Erde um
  die Sonne nicht berücksichtigt!

30
T-Mobile 2009 Viele Betroffene

• 21. April 2009 Software-Fehler legt
  T-Mobile-Netz lahm
• Etwa ab 16 Uhr waren Millionen T-Mobile-Kunden
  mit ihren Handys nicht mehr erreichbar und
  konnten auch selbst niemanden mehr anrufen.
• Wer Geduld hatte und eine lange Stille nach dem
  Wählen der Nummer aushielt, konnte sich von
  einer kühlen Frauenstimme sagen lassen
  "Dieser Anschluss ist aus technischen Gründen
  vorübergehend nicht erreichbar. Bitte rufen sie
  später wieder an.
• T-Mobile-Sprecher Dirk Wende sagte, gegen 19 Uhr
  hätten Techniker das System zurückgesetzt und neu
  gestartet. Ab etwa 22 Uhr sollte das Netz wieder
  flächendeckend funktionieren.
• Ursache Softwarefehler im Home Location Register
  (HLR). Dort werden die Telefonnummern den
  einzelnen SIM-Karten zugeordnet. Insgesamt drei
  Datenbanken waren betroffen und mussten nach und
  nach wieder verfügbar gemacht werden.

www.spiegel.de/video/video-61903.html
31
NASA - Mariner 1 Codierfehler

• Die NASA verliert die auf dem Weg zur Venus
  befindliche Raumsonde Mariner 1 am 22.6.1962
  Because of a launch-vehicle deviation from the
  planned flight path, Mariner R-1 was destroyed by
  the range safety officer after approximately 290
  seconds of flight.
• Korrekt codiert wäre gewesen
• DO 10 I1,3 (Definition einer Schleife...
  in FORTRAN IV) 10 CONTINUE
• Fehlerhaft codiert wurdeDO10I1.3
  (Zuweisung des Werts 1.3... an die
  Variable DO10I)10 CONTINUE

32
NASA - Mariner 1

• Nur ein FORTRAN-Problem?
• C FOR (i1 ilt3 i) f(i)
• (1 mal mit i4)
• Pascal FOR i1 TO 3 DO f(i)
• (1 mal mit i?)
• Modula 2 FOR i1 TO 3 DO f(i) END
• (richtig)

H. Klaeren Probleme des Software-Engineering.
Informatik Spektrum (1994) 17 21-28
33
Validierung und Verifikation - Definition

• Validierung Prüfung, ob ein Entwicklungsergebnis
  die individuellen Anforderungen bezüglich einer
  speziellen beabsichtigten Nutzung erfüllt.
• Haben wir das richtige System realisiert?
• Wenn nicht ? Mangel
• VerifikationPrüfung, ob die Ergebnisse einer
  Entwicklungsphasedie Vorgaben der
  Phaseneingangs-Dokumente erfüllen.
• Haben wir das System richtig realisiert?
• Wenn nicht ? Fehler

34
Was gilt als Fehler oder Mangel?

• Eine Situation kann nur dann als fehlerhaft
  eingestuft werden, wenn vorab festgelegt wurde,
  wie die erwartete, korrekte, also nicht
  fehlerhafte Situation aussehen soll.
• Ein Fehler ist die Nichterfüllung einer
  festgelegten Anforderung, eine Abweichung
  zwischen dem Ist-Verhalten (während der
  Ausführung der Tests oder des Betriebs
  festgestellt) und dem Soll-Verhalten (in der
  Spezifikation oder den Anforderungen festgelegt).
  
• Ein Mangel liegt vor, wenn eine gestellte
  Anforderung oder eine berechtigte Erwartung in
  Bezug auf einen beabsichtigten Gebrauch nicht
  angemessen erfüllt wird. Ein Mangel ist z.B. die
  Beeinträchtigung der Verwendbarkeit bei
  gleichzeitiger Erfüllung der Funktionalität oder
  die Nichterfüllung einer angemessenen Erwartung
  (z.B. Benutzerfreundlichkeit).

Angelehnt an DIN EN ISO 90002005
Qualitätsmanagementsysteme Grundlagen und
Begriffe. Beuth Verlag, Berlin, 2005
35
Ursachenkette für Fehler

• Jeder Fehler oder Mangel ist seit dem Zeitpunkt
  der Fertigstellung in der Software vorhanden. Er
  kommt jedoch erst bei der Ausführung der Software
  zum Tragen.
• Dieser Sachverhalts wird als Fehlerwirkung
  (failure) bezeichnet (auch Fehlfunktion, äußerer
  Fehler, Ausfall).
• Mögliche Ursachen einer Fehlerwirkung
• Fehlerzustand (fault) in der Software (oder
  Hardware)(auch als Defekt, innerer Fehler
  bezeichnet)
• Fehlhandlung (error) einer Person

Angelehnt an DIN 662711995Informationstechnik
- Software-Fehler und ihre Beurteilung durch
Lieferanten und Kunden, Beuth Verlag, Berlin, 1995
36
Fehlhandlung - Definition

• Fehlhandlung (error)
• 1. Die menschliche Handlung (des Entwicklers),
  die zu einem Fehlerzustand in der Software
  führt.
• 2. Eine menschliche Handlung (des Anwenders),
  die ein unerwünschtes Ergebnis (im Sinne von
  Fehlerwirkung) zur Folge hat (Fehlbedienung).

• Problem (issue, incident)
• Verhalten anders als erwartet, aber Ursache noch
  unklar
• Fehlermaskierung
• Ist die Kompensierung eines Fehlerzustands durch
  andere, so dass keine Fehlerwirkung erkennbar
  ist. Ein Fehler wird also durch einen anderen
  Fehler verdeckt.

37
Zusammenhang
38
Testen ?? Debugging

• Debugging
• Funktion im Laufversuch überprüfen
  (unsystematischer Ad-hoc-Test).
• Fehlerursache lokalisieren, analysieren und
  beheben.
• Konstruktiver Ansatz
• Testen
• Fehlverhalten provozieren, reproduzieren und
  dokumentieren.
• Destruktiver Ansatz
• Wenn Entwickler von Testen sprechen, meinen sie
  oft Debugging.
• Gleichzeitig konstruktiv und destruktiv zu
  denken, ist schwierig!
• Testen sollte grundsätzlich systematisch
  erfolgen!

39
Wo findet Testen statt ?

• Teststufen im Entwicklungsprozess nach V-Modell

40
Zu guter Letzt
Bilder von http//www.moffem.de/de/keller2/