Fehler und ihre Kosten Inhalt Fehler in Software

Präsentation zum Thema: "Fehler und ihre Kosten Inhalt Fehler in Software"—  Präsentation transkript:

1 Fehler und ihre Kosten Inhalt Fehler in Software
Software-Technik zur Fehlervermeidung Software Prüfung zur Fehlerbehebung Prüfverfahren - erste Übersicht Softwarequalität: ACM Code der Ethik Annäherung an Objekte von a. Erfahrung aus Technik b. Ansätze aus SE c. Ansätze aus Common Sense oder Philosophie Daraus ableiten: Basiseigenschaften von Objekten und Beschreibung durch UML

2 Vorbemerkung Software ist wie jedes Ingenieurprodukt fehlerbehaftet.
Fehler verursachen Kosten und müssen daher auf ein Minimum beschränkt werden. Dies erreicht man durch Qualitätssicherung beim Prozess der Softwareerstellung (Prozessqualität) und durch Prüfung der Software (Produktqualität). Bei der Prüfung großer Softwaresysteme ist nur das Auftreten von Fehlern festzustellen. Ein Nachweis der Fehlerfreiheit ist nicht möglich (Parnas).

3 Das sollten Sie heute lernen
Fehler von Software, ihre Ursachen und ihre Folgen Warum Qualität Geld kostet Maßnahmen zur Erzielung von Softwarequalität Maßnahmen zur Verbesserung der Softwarequalität Prüfverfahren Softwaremetriken Der „code of ethics“ der Softwaretechniker

4 Eigenschaften von Software
„Unter Software versteht man die Gesamtheit oder auch einen Teil der Programme für Rechensysteme...“ ( Weitere Informationen: Definitionen des Begriffs „Software“ ) Software ist daher ein immaterielles Produkt Software unterliegt keinem Verschleiß, altert aber Software wird kaum durch physikalische Gesetze begrenzt, basiert aber auf einem Modell Software ist im allgemeinen leichter und schneller zu ändern als ein technisches Produkt, solange man nicht vergleichbare Qualitätsanforderungen stellt. Die Herstellung vieler Exemplare (Kopien) ist trivial All diese Eigenschaften haben Auswirkung auf das Auftreten von Fehlern, die Strategien zu ihrer Vermeidung und zu ihrer Behebung.

5 Fehlerursachen Fehler können auftreten beim../bei der..
Verstehen des geforderten Verhaltens - Konzeptionalisierung Umsetzen in ein Computermodell - Entwurf Erstellen des Programmes Konstruktion und Realisierung Versorgen des Programmes mit Daten - Simulation Interpretation der Ergebnisse Analyse und Betrieb ( Weitere Informationen: Definitionen des Begriffs „Fehler“ ) Häufig treten Fehler auch beim Übergang von einer Phase zur nächsten auf, insbesondere, wenn mit diesem Übergang ein Wechsel im zugrundeliegenden Modellierungsparadigma verbunden ist

6 Beispiele für Fehler im PC-Bereich
INTEL: no more than Bugs in Pentium. Example Handy (Cellular Phone): lines of program: up to 600 errors. Windows-95: 10 Mill. lines: up to errors. See also subj 4, subj9 and subj7 unter catless.ncl.ac.uk/Risks/20.82.html Klassifizierung von Software nach Fehlerhäufigkeit Banana Software: Let the Software ripe at the customer! 'It's not a bug, it's a feature!‘ Standard Software: 25 bugs per 1000 lines of program. Good Software: 2 errors per 1000 lines. Space Shuttle Software: < 1 errors per lines.

7 Beispiel: Denver-Flughafen (1993 - 1995)
– Oktober 1993: Probleme mit der High-Tech-Gepäckverteilungsanlage. – April 1994: Verschiebung der Eröffnung nach Debakel: · Gepäckstücke wurden auf Wagen geworfen, die gar nicht da waren; Wagen fielen aus den Fahrspuren heraus; usw. · Die computergesteuerte Gepäckverteilungsanlage bestand aus über Computern, 4000 Wagen auf 34 km Schienenwegen, 5000 Sensoren, 56 Barcode-Lesern; Wert der Anlage: $200 Mio., dazu $100 Mio. für Gebäudeänderungen. Hauptursache: Zu viele Nachrichten über Ethernet. Sortier-Anweisungen kamen nicht rechtzeitig wegen Überlastung des Netzwerks (LAN). Gesamtproblem zu komplex. – August 1994: Installation eines (zweiten) konventionellen Systems mit üblichen Förderbändern: $ 50 Mio. zusätzlich – Erste offizielle Inbetriebnahme: 1. März aber kurz danach wieder Stillstand; Wiedereröffnung: Oktober 1995 – Gesamtkosten: $ 520 Mio. statt geplanter $ 200 Mio.  Softwarefehler sind teuer!

8 Beispiel: Parteitag der Grünen 22.2.2002
Bericht der Stuttgarter Zeitung vom Parteitag platzt wegen eines Computerfehlers Wegen eines Computerfehlers wurden zwei Delegierte zuviel zum Listen-Parteitag der Grünen eingeladen. Der Parteitag platzte. * Die Landesgeschäftsführer hatten den Delegiertenschlüssel mittels einer Exceldatei ausrechnen lassen. Das Programm sollte die 200 Delegierten auf die 47 Kreisverbände abhängig von deren Mitgliederzahl verteilen. Durch Rundungsfehler hatte der Rechner aber 3 Kreisverbänden je einen Delegierten zuviel und einem Kreisverband einen Abgesandten zu wenig zugewiesen. Nachgeprüft wurden die einzelnen Ergebnisse erst, als in einem Wahlgang mehr als 200 Stimmen abgegeben wurden.

9 Fehlverhalten von größeren Systemen
Fehlerzahl  hohe Motivation  viel Know-how  hohe Priorität Produkt nicht mehr handhabbar – Die Zahl der noch im Produkt befindlichen Fehler kann zunächst schnell gesenkt werden – Die Fehlerzahl wird im allgemeinen nie Null erreichen – Verbesserungen und neue Anforderungen erhöhen die Fehlerzahl wieder – Nach zu vielen Revisionen entsteht ein nicht mehr handhabbares Produkt Zeit Quelle IAS

10 Hier finden Sie eine Vielzahl weiterer Fehlerberichte
ACM Auflistung von Softwareproblemen Software-Bugs (Sammlung von Web Seiten)

11 Was man aus Softwarefehlern lernen kann
– Es muss nicht nur getestet werden, was das System können sollte, sondern auch, ob es auf falsche Eingaben richtig reagiert. – Kein System-Shutdown als Antwort auf eine generelle Ausnahmebehandlung bei Systemen, die keinen „fail-safe“ Zustand haben. ( Weitere Informationen: Definition des Begriffs „fail-safe“) – In kritischen Berechnungen sollte immer ein Wert zurück gegeben werden, selbst wenn der absolut korrekte Wert nicht berechnet werden kann. Dazu ist dann ein Fehlerhinweis nötig. – Wenn immer möglich, sollten Tests unter realen Bedingungen erfolgen. – Verbessere den Reviewprozess um externen Teilnehmer. Der Review sollte alle im Code gemachten Annahmen umfassen.

12 Die Kosten von Software-1
Die Kosten eines Software-Produkts setzen sich aus Herstellungskosten und Qualitätskosten zusammen. Alle Aufwendungen für das Erbringen der geforderten Leistung, das Erzeugen der Qualität, zählen zu den Herstellungskosten. Die Qualitätskosten umfassen alle (zusätzlichen) Anwendungen für das Verhüten, Erkennen, Lokalisieren und Beheben von Fehlern sowie die evtl. Folgekosten der Fehler, die erst im Betrieb auftreten.

13 Aufwendungen für Softwaresysteme
70 % aller Aufwendungen für Softwaresysteme sind Betreuungskosten. 70 % der Softwareentwickler sind mit Pflegearbeiten beschäftigt.

14 Die Kosten von Software - 2
Software-Kosten Fehlerverhütungskosten Prüfkosten Fehlerkosten Herstellungskosten Qualitätskosten Folgekosten Garantiekosten Fehlerbehebungskosten

15 Fehlerbehebungskosten

16 Vermeidung von Fehlern: Softwaretechnik
Die Erstellung von Software ist ein technischer Prozess. Seine Umsetzung bezeichnen wir als Softwaretechnik. Wie jede Technik hat auch die Softwaretechnik zum Ziel, ihre Produkte effizient, zuverlässig und zur Zufriedenheit der Kunden zu gestalten. Ziele dabei sind: Lieferung eines Produktes, das den Vorstellungen des Kunden entspricht und die geforderten Qualitätsmerkmale einhält Produktqualität Schnelle und effiziente Entwicklung des Produkts (Entwicklungsaspekt) Sicherere Projektabwicklung (Managementaspekt) Sicherstellung der Wartbarkeit, Erweiterbarkeit, Wiederverwendbarkeit (Wartungsaspekt)

17 Kosten der Softwaretechnik
Qualität ist nicht umsonst zu erhalten. Sie erfordert Aufwand und verursacht Kosten Ungefähr 60% der Kosten sind Entwicklungskosten, 40% sind Testkosten. Für kundenspezifische Software übersteigen die Wartungskosten oft die Entwicklungskosten Kosten variieren je nach Typ des zu entwickelnden Systems, sowie nach den Anforderungen der Systemattribute, wie Performance und Systemzuverlässigkeit Verteilung der Kosten ist abhängig vom verwendeten Vorgehensmodell

18 Verbesserung der Softwarequalität
Grundannahmen Qualitätsziele werden während der Konzeptfindung vorgegeben. Der Entwicklungsprozeß bestimmt Eigenschaften und Qualität des Produktes. Die Qualität des Entwicklungsprozesses kann definiert gemessen und verbessert werden. Qualität des Produktes Nachweis durch Prüfung Anforderungen und/oder Erwartungen an das Produkt Merkmale und Eigenschaften des Produktes PROZESS Anweisungen Ausführung Prozessqualität Die Produktqualität wird wesentlich durch die Prozessqualität bestimmt

19 Basis von Prüfungen: Vergleich Soll/Ist
VERIFICATION Customer needs Specs Draft standards Drafting process For the purpose of this presentation Verification: Comparison of revised standards with approved specification Validation: Comparison of revised standards with user needs (results of survey) Commit audience to participation in validation process through national standards bodies VALIDATION Anforderung Aktivitäten Erfüllung Soll auf Basis von Modellen Ist

20 Qualitätsmerkmale und mögliche Metriken
Teilmerkmale Inspektion/Metrik Portierbarkeit Antwortzeit Geräteauslastung Laufzeit Notwendigkeit Vollständigkeit Strukturiertheit Verständlichkeit Einfachheit Robustheit Genauigkeit Konsistenz Lesbarkeit Änderbarkeit Erweiterbarkeit Testbarkeit Abrechenbarkeit Maschinenunabhängigkeit Systemsicherheit Verfügbarkeit Vergleich mit Standard Zahl derSystem Abstürze Zuverlässigkeit Zahl der BedienungsAbstürze Funktionstreue Bedienbarkeit Logik der Benutzerführung Code Inspektion Wartung Lokalität der Entwurfsentscheidungen Modularität Vergleich mit Spezifikation Angemessenheit Vergleich mit Mustern Performance monitoring Zeit Zeit

21 Metriken für objektorientierte Programme
Betrachtet wird Kopplung von Klassen = Benutzt-Beziehungen zwischen Klassen: Wenige auslaufende Benutzt-Beziehungen ist positiv, da sich dann eine Klasse auf wenige andere Klassen abstützt Viele einlaufende Benutzt-Beziehungen ist positiv, da dann eine Klasse von vielen Klassen (wieder)verwendet wird Beides kann nicht maximiert werden, da über alle Klassen hinweg gilt: Summe auslaufend = Summe einlaufend Zwei Klassen sind gekoppelt, wenn: Assoziations- oder Aggregationsbeziehung besteht auf Operationen oder Attribute anderer Klasse zugegriffen wird eine Klasse als Parametertyp der Operation einer anderen Klasse auftritt

22 Vererbungsbeziehungen in Metriken
Gesucht wird eine Metrik, die neben der Kopplung von Klassen folgende Aspekte in einer Maßzahl zusammenfasst: Vererbung definiert keine Kopplung, sondern Bindung zwischen Klassen Die Klassen einer Vererbungshierarchie sollten enge Bindung besitzen, also einem ähnlichen Zweck dienen Vererbungshierarchien sollten nicht zu tief sein Redefinition von Operationen und Mehrfachvererbung sind gefährliche Konzepte, sollten also möglichst wenig vorkommen Näheres hierzu findet man in [Ba98] auf Seite 535 ff. und in [He96].

23 Durch Softwareprüfung zu Produktqualität
statische dynamische ohne Hilfe des Rechners mit Hilfe Test Leistungsmessung : Prüfung gegen Regeln Konsistenzprüfung Quantitative Untersuchung Review :

24 Produktqualität – Prüfverfahren (Beispiele)
Komponenten Testende Verfahren Dynamisch (Kontrollfluss, Datenfluss, Funktional) Statisch (Inspektion, Review, Walk through) Verifizierende Verfahren Verifikation (Konsistenz Entwurf + Implementierung) Symbolisches Testen (statische Strukturtests) Systeme Integrationstest White Box-Test der Komponenten und ihrer Beziehungen Systemtest Black Box-Test des Systems als Ganzes Abnahmetest Black Box-Test des Systems als Ganzes nutzen Mitwirkung des Auftraggebers

25 Softwareprüfung und Fehlerbehebung
meint Erkennen von unerwartetem Verhalten stößt Prozess der Ursachenfindung an resultiert in Fehlerbehebung Fehlerbehebung führt zur Veränderung des Produktes kann unerwartetes Verhalten erzeugen Vergleich:

26 Statische Testverfahren
Systematische Verfahren zur gemeinsamen „Durchsicht“ von Dokumenten (wie z.B. UML-Modelle, implementierte Klassen, ...): Programminspektion: Stark formalisiertes Verfahren bei dem Dokument nach genau festgelegter Vorgehensweise durch Gutachterteam untersucht wird Review: Weniger formale manuelle Prüfmethode; weniger Aufwand als bei Programminspektion, ähnlicher Nutzen Walkthrough: Unstruktierte Vorgehensweise; Autor des Dokuments liest vor, Gutachter stellen spontan Fragen [Pair Programming: Programm wird von vorherein zu zweit erstellt]. Empirische Ergebnisse zu Programminspektion: Prüfaufwand liegt bei ca. 15 bis 20% des Erstellungsaufwandes 60 bis 70% der Fehler in einem Dokument können gefunden werden Nettonutzen: 20% Ersparnis bei Entwicklung, 30% bei Wartung

27 Vorgehensweise bei der Programminspektion
Inspektionsteam besteht aus Moderator, Autor (passiv), Gutachter(n), Protokollführer und ggf. Vorleser (nicht dabei sind Vorgesetzte des Autors) Gutachter sind in aller Regel selbst (in anderen Projekten) Entwickler Inspektion überprüft, ob: Dokument Spezifikation erfüllt (Implementierung konsistent zu Modell) Für Dokumenterstellung vorgeschriebene Standards eingehalten wurden Inspektion hat nicht zum Ziel: Zu untersuchen, wie entdeckte Fehler behoben werden können Beurteilung der Fähigkeiten des Autors [Lange Diskussion, ob ein entdeckter Fehler tatsächlich ein Fehler ist] Inspektionsergebnis: Formalisiertes Inspektionsprotokoll mit Fehlerklassifizierung Fehlerstatistiken zur Verbesserung des Entwicklungsprozesses

28 Ablauf einer Inspektion
Auslösung der Inspektion durch Autor eines Dokumentes (z.B. durch Freigabe) Eingangsprüfung durch Moderator (bei vielen offensichtlichen Fehlern wird das Dokument sofort zurückgewiesen) Einführungssitzung, bei der Prüfling den Gutachtern vorgestellt wird Individualuntersuchung des Prüflings (Ausschnitt) durch Gutachter anhand ausgeteilter Referenzdokumente (mit Spezifikation, Standards, ...) auf Inspektionssitzung werden Prüfergebnisse mitgeteilt und protokolliert sowie Prüfling gemeinsam untersucht Freigabe des Prüflings durch Moderator (oder Rückgabe zur Überarbeitung). Bemerkung: Von den gefundenen Fehlern entfallen auf die Individualprüfung ca. 80% und auf die gemeinsame Sitzung ca. 20% der Fehler.

29 Review und Walkthrough
Review (abgeschwächte Form der Inspektion): Prozessverbesserung und Erstellung von Metriken steht nicht im Vordergrund Moderator gibt Prüfling nicht frei, sondern nur Empfehlung an Manager kein formaler Inspektionsplan mit wohldefinierten Inspektionsregeln Walkthrough: Autor des Prüflings liest ihn vor (ablauforientiert im Falle von Software) Gutachter versuchen beim Vorlesen ohne weitere Vorbereitung Fehler zu finden Autor entscheidet selbst über weitere Vorgehensweise Zielsetzungen: Fehler/Probleme im Prüfling identifizieren Ausbildung/Einarbeitung von Mitarbeitern

30 Dynamische Testverfahren
Die zu betrachtende Komponente (Operation, Klasse, Paket, Gesamt-system) wird mit konkreten Eingabewerten ausgeführt und ihr Verhalten wird dabei beobachtet. Im wesentlichen lassen sich dabei folgende Alternativen unterscheiden: Strukturtest (White Box-Test): Die interne Struktur der Komponente oder ihrer UML-Spezifikation wird zur Testplanung und -Überwachung herangezogen Funktionstest (Black Box-Test): Die interne Struktur der Komponente wird nicht betrachtet; getestet wird Ein-/Ausgabeverhalten gegen Spezifikation Diversifikationstest: Verhalten einer Komponentenversion wird mit Verhalten anderer Komponenteversionen (oder ausführbarem Statechart) verglichen.

31 Strukturtest (White Box-Test)
Zur Testplanung und -Überwachung wird die interne Struktur der Komponente oder ihrer UML-Spezifikation herangezogen. Folgende Varianten sind möglich kontrollflussbasiert: Ablaufverhalten von Operationen wird untersucht datenflussbasiert: Variablenzugriffe (setzen/lesen) stehen im Vordergrund zustandsbasiert: Zustände und Transitionen einer Klasse werden betrachtet.

32 Funktionstest Funktionstests prüfen Implementierung gegen ihre Spezifikation und lassen die interne Programmstruktur unberücksichtigt: Komplementär zu bislang vorgestellten „White-Box“-Verfahren für Abnahmetest ohne Kenntnis des Quellcodes geeignet setzt (eigentlich) vollständig und widerspruchsfreie Spezifikation voraus repräsentative Eingabewerte/Szenarien müssen ausgewählt werden (man kann i.a. nicht alle Eingabekombinationen testen) Sequenzdiagramme aus Anwendungsfällen (use cases) beschreiben wichtige Testfälle man braucht Fachwissen oder „Orakel“ für Überprüfung der Korrektheit der Ausgaben ausführbare Statecharts als Orakel verwenden

33 Kriterien für die Auswahl von Eingabewerten
An der Spezifikation (hier in UML) orientierte Äquivalenzklassenbildung, so dass für alle Werte einer Äquivalenzklasse sich das Softwareprodukt „gleich“ verhält: Unterteilung in gültige und ungültige Eingabewerte gesonderte Betrachtung von Grenzwerten (z.B. Anfang und Ende von Intervallen) Auswahl von Repräsentanten so, dass jede Variante jedes Sequenz- und Kollaborationsdiagramms (Aktivitätsdiagramms) einmal durchlaufen wird Auswahl von Repräsentanten so, dass jede Transition jedes Statecharts (des Produktautomaten bei an-Zuständen) mindestens einmal schaltet Achtung: Auswahl von „Eingabewerten“ schwierig für Objekte als Operationsparameter, z.B. Äquivalenzklassenbildung mit: nil-Objekt, Objekt einer falschen Klasse, Objekt in bestimmtem Zustand oder mit bestimmten Attributwertkombinationen, ...)

34 Integrationsteststrategien
„Big Bang“-Strategie: Alle Teile sofort integrieren und nur als Gesamtheit testen Lokalisierung von Fehlern schwierig Arbeitsteilung kaum möglich Testen beginnt zu spät „Top-down“-Testverfahren: Zuerst A mit Dummies für B, C und D; dann B mit Dummies für E und F, ... Erstellung „vernünftiger“ Dummies schwierig Test der Basisschicht sehr spät „Bottom-Up“-Testverfahren: Zuerst E, F, G und H mit Testtreibern, die Einbindung in B, C und D simulieren; dann B, C und D mit Testtreiber ... Test des Gesamtverhaltens des Systems gegen Lastenheft erst am Ende Designfehler und Effiziensprobleme werden oft erst spät entdeckt

35 Inkrementelles Testen
Inkrementelles Testen: Grundgerüst vorhanden, weitere Komponenten werden stückweise hinzugefügt wie erstellt und testet man Grundgerüst (z.B. Top-Down-Testen mit Depth-First-Strategie) Hinzufügen von Komponenten kann bisherige Testergebnisse entwerten Regressionstest: Systemänderungen (bei Wartung oder inkrementellem Testen) können Fehler in bereits getesteten Funktionen verursachen. Möglichst viele Tests werden automatisiert bei jeder Änderung werden alle vorhandenen Tests durchgeführt neue Testergebnisse werden mit alten Testergebnissen verglichen Achtung: Nur inkrementelles Testen kombiniert mit Regressionstest passt zum inkrementellen und iterativen Softwareentwicklungsprozess von UML

36 Wann hört man auf mit Testen
Wenn Testbudget verbraucht bzw. Auslieferungszeitpunkt erreicht Die je Testfall (Zeiteinheit) gefundene Fehlerzahl sinkt unter gegebene Grenze n % absichtlich von einer Gruppe implantierter Fehler (seeded bugs) wurden von Testgruppe gefunden Aus jeder Klasse „äquivalenter“ Eingabedaten wurde ein Repräsentant getestet. Testfälle decken alle (relevanten) Programmverzweigungen ab

37 Links Links sind im Text angegeben.
Weitere Links werden kontinuierlich eingefügt.

38 Literatur Schneider, Hans-Jochen (Hrsg.): Lexikon der Informatik und Datenverarbeitung, Version 4.0, R.Oldenbourg Verlag München Wien 1997) Balzert, Helmut: Lehrbuch der Software-Technik; Software-Management, Software-Qualitätssicherung, Unternehmensmodellierung. Spektrum Akademischer Verlag Heidelberg, Berlin. 1998 Balzert, Helmut: Lehrbuch der Software-Technik; Software-Entwicklung. Spektrum Akademischer Verlag Heidelberg, Berlin. 1996 Meyer, Bertrand: Objektorientierte Softwareentwicklung, Hanser Verlag München Wien 1990 Thaller, Georg Erwin: Software- und Systementwicklung, Heise Verlag Hannover, 2001

39 Danksagung Aus folgenden Vorlesungen und Foliensammlungen aus dem Bereich Softwaretechnik konnten wir Anregungen zur Gestaltung dieses Lernmoduls gewinnen: P. Göhner Softwaretechnik 1 IAS Uni Stuttgart A. Schürr Software Engineering 1 Uni BW München

40 Zusammenfassung – Softwaretechnik ist eine Ingenieur-Disziplin, die sich mit allen Aspekten der Softwareentwicklung beschäftigt. – Softwareprodukte bestehen aus dem entwickelten Programmen und der Dokumentation. Wesentliche Produkteigenschaften sind Wartbarkeit, Zuverlässigkeit, Effizienz und Benutzbarkeit. – Der SW-Entwicklungsprozess besteht aus Aktivitäten, die bei der Entwicklung des Softwareprodukts involviert sind. Grundaktivitäten sind Software-Spezifikation, -Entwicklung, -Validierung und -Wartung. – Methoden sind eine organisierte Möglichkeit der Herstellung von Software. Sie beinhalten Ratschläge für die zu folgenden Vorgehen, die zu benützende Notation, Richtlinien für die Systembeschreibung und Entwurfsrichtlinien.

41 ACM/IEEE Code der Ethik
– Die ACM/ IEEE haben gemeinsam einen „Code of Ethics“ erstellt. – Mitglieder dieser Organisation verpflichten sich, diesen Code einzuhalten und zu praktizieren. – Der Code enthält 8 Prinzipien bezogen auf das Verhalten und getroffene Entscheidungen von professionellen Software-Ingenieuren, einschließlich Praktiker, Ausbilder, Manager, Leiter sowie Trainer und Studenten dieses Berufs

42 „Code of ethics“ - Prinzipien (1)
1. PUBLIC Software engineers shall act consistently with the public interest. 2. CLIENT AND EMPLOYER Software engineers shall act in a manner that is in the best interests of their client and employer consistent with the public interest. 3. PRODUCT Software engineers shall ensure that their products and related modifications meet the highest professional standards possible.

43 „Code of ethics“ - Prinzipien (2)
4. JUDGMENT Software engineers shall maintain integrity and independence in their professional judgment. 5. MANAGEMENT Software engineering managers and leaders shall subscribe to and promote an ethical approach to the management of software development and maintenance. 6. PROFESSION Software engineers shall advance the integrity and reputation of the profession consistent with the public interest.

44 „Code of ethics“ - Prinzipien (3)
7. COLLEAGUES Software engineers shall be fair to and supportive of their colleagues. 8. SELF Software engineers shall participate in lifelong learning regarding the practice of their profession and shall promote an ethical approach to the practice of the profession.

45 Ethische Schwierigkeiten
Beispiele: – Unstimmigkeiten in den Prinzipien mit der Politik des führenden Managements – Ihre Firma agiert in einer unethischen Weise und liefert ein sicherheitskritisches System aus, ohne das Testen des System abzuschließen. – Teilnahme an der Entwicklung von militärischen Waffensystemen

46 Software „Unter Software versteht man die Gesamtheit oder auch einen Teil der Programme für Rechensysteme. Diese Programme ermöglichen zusammen mit den Eigenschaften der Rechensysteme deren Betrieb, deren Nutzung zur Lösung gestellter Aufgaben, aber auch zusätzliche Betriebs- und Anwendungsarten der Rechensysteme. Zugehörige Dokumentation kann als Bestandteil der Software angesehen werden. (nach DIN T1).“ aus: Schneider, Hans-Jochen (Hrsg.): Lexikon der Informatik und Datenverarbeitung, Version 4.0, R.Oldenbourg Verlag München Wien 1997 – S.787 zurück

47 Fehler - 1 „ein konstatierbarer Unterschied zwischen beobachteten oder berechneten Zuständen oder Vorgängen oder Daten darüber einerseits und wahren, festgelegten oder theoretisch korrekten Zuständen oder Vorgängen bzw. Daten darüber andererseits“ ... „Überdies spricht man in anderer Umgebung, z.B. bei der Qualitätssicherung, erst dann von Fehler, wenn wegen des Unterschieds vorgegebene Forderungen nicht erfüllt werden (nach DIN T1 und DIN ).“ aus: Schneider, Hans-Jochen (Hrsg.): Lexikon der Informatik und Datenverarbeitung, Version 4.0, R.Oldenbourg Verlag München Wien 1997 Weitere Informationen zum Thema Fehler zurück

48 Fehler, Fehlverhalten, Ausnahme - 2
„Ein Fehler ist die Anwesenheit eines Elements in der Software, das seiner Spezifikation nicht genügt. Ein Fehlverhalten ist die Unfähigkeit eines Softwareelements, seinen Zweck zu erfüllen. Eine Ausnahme ist das Auftreten einer abnormen Bedingung während der Ausführung eines Softwareelements. aus: Meyer, Bertrand: Objektorientierte Softwareentwicklung, Hanser Verlag München Wien 1990 – S.160 zurück

49 Pflege, Wartung Pflege = Anpassung eines Systems an geänderte Bedingungen oder Weiterentwicklung aufgrund neuer oder geänderter Anforderungen. Wartung = Beseitigung eines nach der Inbetriebnahme auftretenden Fehlverhaltens. aus: Balzert, Helmut: Lehrbuch der Software-Technik; Software-Entwicklung. Spektrum Akademischer Verlag Heidelberg, Berlin. 1996 zurück

50 Metrik „Eine Software-Metrik definiert, wie eine Kenngröße eines Software-Produkts oder eines Software-Prozesses gemessen wird.“ aus: Balzert, Helmut: Lehrbuch der Software-Technik; Software-Management, Software-Qualitätssicherung, Unternehmensmodellierung. Spektrum Akademischer Verlag Heidelberg, Berlin. 1998 zurück

51 Prüfling, Testling, Testobjekt
Prüfling, Testling, Testobjekt: Software-Komponente bzw. Programm, das getestet werden soll. Prüfling ist dabei der allgemeine Begriff, während Testling die dynamische Ausführung eines Programmes impliziert. Beim dynamischen Test geschieht die Überprüfung des Testobjekts dadurch, dass es mit Testfällen ausgeführt wird.“ (Balzert S.393) aus: Balzert, Helmut: Lehrbuch der Software-Technik; Software-Management, Software-Qualitätssicherung, Unternehmensmodellierung. Spektrum Akademischer Verlag Heidelberg, Berlin. 1998 zurück

52 fail-safe "fail-safe"- Prinzip: System muss sofort und selbständig Sicherheitsmaßnahmen ergreifen  Fehlererkennung notwendig Bsp. aus der Stellwerkstechnik: Wenn in der Signalanlage eines Bahnhofs eine Störung auftritt, gehen alle Signale auf Rot => System reagiert nach der sicheren Seite. (Früher mit Relaistechnik, heute mittels Software realisiert.) zurück

53 Verifikation, Validation
Verifikation = Überprüfung der Übereinstimmung zwischen einem Software-Produkt und seiner Spezifikation Validation = Eignung bzw. der Wert eines Produktes bezogen auf seinen Einsatzzweck aus: Balzert, Helmut: Lehrbuch der Software-Technik; Software-Management, Software-Qualitätssicherung, Unternehmensmodellierung. Spektrum Akademischer Verlag Heidelberg, Berlin. 1998 zurück

54 White Box-Test, Black Box-Test
White Box-Test = Strukturtestverfahren: Die Implementierung eines Programms steht zum Testen zur Verfügung. (Balzert S. 415) Black Box-Test = funktionales Testverfahren: Testfälle werden aus der Programmspezifikation abgeleitet. Die Programmstrukur sollte für den Tester unsichtbar sein. Der Testling sollte für den Tester mit Ausnahme der Spezifikation ein schwarzer Kasten („black box“) sein. (Balzert S. 426) zurück aus: Balzert, Helmut: Lehrbuch der Software-Technik; Software-Management, Software-Qualitätssicherung, Unternehmensmodellierung. Spektrum Akademischer Verlag Heidelberg, Berlin. 1998

55 Software-Qualität Äußere Faktoren Korrekt Robustheit Erweiterbarkeit
Wiederverwendbarkeit Kompabilität (Verträglichkeit) Andere Qualitätseigenschaften Portabilität Verifizierbarkeit Integrität Benutzerfreundlichkeit ( Definitionen der Begriffe)

56 Äußere Qualitätsfaktoren
„Korrektheit ist die Fähigkeit von Softwareprodukten, ihre Aufgaben exakt zu erfüllen, wie sie durch Anforderungen und Spezifikationen definiert sind.“ „Robustheit heißt die Fähigkeit von Softwaresystemen, auch unter außergewöhnlichen Bedingungen zu funktionieren.“ „Erweiterbarkeit bezeichnet die Leichtigkeit, mit der Softwareprodukte an Spezifikationen angepasst werden können.“ „Wiederverwendbarkeit von Softwareprodukten ist die Eigenschaft, ganz oder teilweise für neue Anwendungen wiederverwendet werden zu können.“ „Kompabilität ist das Maß der Leichtigkeit, mit der Softwareprodukte mit anderen verbunden werden können.“ (MeyerS.2ff) aus: Meyer, Bertrand: Objektorientierte Softwareentwicklung, Hanser Verlag München Wien 1990 weiter

57 Andere Qualitätseigenschaften
„Effizienz ist die ökonomische Nutzung von Hardware-Ressourcen...“ „Portabilität ist das Maß der Leichtigkeit, mit der Softwareprodukte auf verschiedene Hardware- und Softwareumgebungen übertragen werden können.“ „Verifizierbarkeit ist das Maß der Leichtigkeit, mit der Abnahmeprozeduren, insbesondere Testdaten, und Prozeduren zur fehlererkennung und –verfolgung während der Validations- und Betriebsphase erzeugt werden können. „Integrität ist die Fähigkeit eines Softwaresystems, seine verschiedenen ... Komponenten gegen unberechtigte Zugriffe und Veränderungen zu schützen.“ „Benutzerfreundlichkeit ist die Leichtigkeit, mit der die Benutzung von Softwaresystemen, ihre Bedienung, das Bereitstellen von Eingabedaten, die Auswertung der Ergebnisse und das Wiederaufsetzen nach Benutzungsfehlern erlernt werden kann.“Meyer S.6) zurück aus: Meyer, Bertrand: Objektorientierte Softwareentwicklung, Hanser Verlag München Wien 1990

58 Qualität von Software „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.“ Balzert S.257 Softwarequalität zurück

59 Software Entwicklungsprozess
zurück Die Erstellung eines Programmes erfolgt in einem Software Entwicklungsprozess Ein allgemeiner Entwicklungsplan, der das generelle Vorgehen beim Entwickeln eines Software-Produkts festlegt, wird Prozess-Modell oder auch Vorgehensmodell genannt.

60 Prozessqualität Die Qualität eines Produktes wird wesentlich von der Qualität des Erstellungsprozesses beeinflusst. Basis der Verbesserung eines Prozesses ist seine Beschreibung durch ein Prozess Modell Die Prozessqualität ergibt sich dann aus der Qualität der Einzelschritte Basisansätze sind: ISO 9000 Das Capability Maturity Model CMM Total Quality Management TQM Aber auch Vorgehensmodelle wie das V-Modell oder der Best Practice Ansatz des RUP haben zum Ziel qualitativ hochstehende Software Entwicklung zu ermöglichen zurück

61 zurück Produktqualität
Die Produkte des Softwareengineerings sind Programme Die Produkt-Definition erfolgt in einem Dokument als Ergebnis der Systemanalyse. Sie wird oft auch als Produkt-Spezifikation oder System-Spezifikation bezeichnet. Produktqualität meint dann den Grad der Übereinstimmung zwischen Produkt Definition und Produkt Eigenschaften

62 Zuverlässigkeit 2 Definitionen für „Zuverlässigkeit“:
(1) Die Wahrscheinlichkeit, dass Software für eine bestimmte Zeit bei definierten Bedingungen keinen Fehler im System verursachen wird. Diese Wahrscheinlichkeit hängt von den Inputs und der Verarbeitung ab sowie davon, ob sich Fehler in der Software befinden. Durch die Inputs des Systems wird bestimmt, ob existierende Fehler (falls vorhanden), zu einem Scheitern des Systems führen. (2) Die Eigenschaft eines Programms, eine geforderte Funktion unter definierten Bedingungen für einen bestimmten Zeitraum zu erbringen. Anm.: „Der Begriff Zuverlässigkeit wird in der Mechanik, Elektronik und im Bereich der Software benutzt. Es stecken aber Konzepte dahinter, die sich in wesentlichen Teilen unterscheiden. So lange Zuverlässigkeit im Rahmen der Software‑Entwicklung als ein Qualitätsattribut gefordert wird, hat niemand etwas dagegen. Das ist ein qualitatives Ziel, keine quantitative Forderung, und wird daher akzeptiert.“ Thaller, Georg Erwin: Software- und Systementwicklung, Heise Verlag Hannover, 2001 – S. 233 zurück