• Set D = http://www.inf.fu-berlin.de/inst/ag-se/teaching/S-ERROR-2004

Seminar zu Ursachen und Vermeidung von Fehlern in der Softwareentwicklung

Inhalt

Unter Software-Qualitätssicherung wird häufig lediglich das nachträgliche Testen eines Programms oder das Durchsehen des Codes verstanden. Warum aber verhindert man nicht von vorneherein, dass Programmierer Defekte in die Software einbauen? Denn ist ein "Bug" (siehe Bild) erst einmal verbreitet, ist es schwer, ihn zu entdecken und zu entfernen.

In diesem Seminar soll untersucht werden, was die Ursachen für das Einbauen von Defekten sind, in welchen Ausprägungen diese auftauchen und welche (neuen wie alten) Strategien entwickelt wurden, sie zu vermeiden.

Wegen der großen Nachfrage nach Themen wurde auch das angrenzende Gebiert der statistischen Defektvorhersage hinzugenommen.

Jede/r Teilnehmer/in arbeitet in diesem Seminar ein Referat zu einem interessanten Teilaspekt aus. Neben der fachlichen Arbeit werden auch Vortragstechniken diskutiert und das Schreiben von Ausarbeitungen geübt.

Organisatorisches

Das Seminar ist geeignet für Informatikstudierende (auch Bachelor und Master), die die Vorlesung Softwaretechnik zumindest zur Kenntnis genommen haben. Gasthörer sind willkommen. Im KVV ist das Seminar unter https://www.mi.fu-berlin.de/kvv/?veranstaltung=623 zu finden. Die Veranstaltungsnummer ist 19584.

Stattfinden wird das Seminar in der Woche vor Beginn der Vorlesungen im Sommersemester, also

4.-8. April jeweils etwa 9-16 Uhr (nicht c.t.) im Raum SR 051 im Informatikgebäude

Die Vorbereitungstermine sind:

• Ab sofort bis spätestens 18.2. Besprechung mit dem Seminarleiter über die Inhalte und Gliederung der Ausarbeitung und des Vortrags. Diese Besprechung sollte vor dem Schreiben dieser Texte statt finden. Der Besprechungstermin wird von den Teilnehmern gemacht; Mail an SebastianJekutsch mit zwei Terminvorschlägen genügt.
• Bis spätestens 17.3. müssen Versionen der Ausarbeitung und der Folien auf diese Seite hochgeladen werden, damit die Gutachter ihre Arbeit beginnen könnnen.
• Bis spätestens 25.3. müssen die Begutachtungen den Autoren per Mail zugeschickt werden. Dabei unbedingt SebastianJekutsch auf CC setzen.
• Seminarblock vom 4.-8.4.
• Bis spätestens 22.4. muss die endgültige Version der Ausarbeitung auf diese Seite hochgeladen werden.

Die Termine sind locker gelegt, bitte nichts auf den letzten Drücker machen. Ein Versäumen eines der Termine (inkl. Anwesenheit während des ganzen Seminars 4.-8.4.) gefährdet die Scheinvergabe oder drückt auf die Note.

Tragen Sie sich als TeilnehmerIn oder GasthörerIn bitte unbedingt in die Mailingliste http://lists.spline.inf.fu-berlin.de/mailman/listinfo/se_s_defects ein. Darüber laufen eventuell wichtige Informationen.

Die Erstbesprechung (Foliensatz) und die Themenvergabe (siehe unten) sind abgeschlossen. Falls eineR der TeilnehmerInnen nachträglich doch nicht teilnehmen möchte, bitte möglichst früh einen Hinweis an den Veranstalter schicken. Das ermöglicht es andere, das Thema zu übernehmen und erspart unnötige Nachfragen.

Bei allgemeinen Fragen zum Wesen und Ablauf eines Seminars schauen Sie bitte unter SeminarRegeln. Dort sind im Anhang auch Vorlagen für Powerpoint-Folien und für Word-Ausarbeitungen zu finden, die bitte benutzt werden sollten. Wenn Sie ein anderes Format einsetzen möchten, versuchen Sie sich bitte grob an diese Vorlagen zu halten. Die Auslieferung erfolgt in allen Fällen im PDF-Format. Für sonstige Fragen (Themen, Termine, etc.) steht der Veranstalter jederzeit zur Verfügung.

Themen

Es folgt die vorläufige Auswahl an Themen. Alle kursiv fett gedruckten und nummerierten Themen können zu einem Vortrag ausgeführt werden, lediglich fett gedrucktes sind Zwischenüberschriften.

Eigene Themenvorschläge sind herzlich willkommen!

Aus dem Seminar können sich auch Studien- und Diplomarbeitsthemen ergeben.

Ursachenforschung

Im ersten Teil gehen wir eher analytisch an das Thema heran und betrachten Untersuchungen über das Auftreten von Defekten (in der Software) und Fehlern (von Programmierern = Menschen).

Defektanalyse: Es geht um die reine statistische Betrachtung von Defekten.

• (1) Wahre Geschichten: Als Einstieg eine lockere Einführung in die Problematik, anhand von den Defekten in TeX und vielleicht über "Bug Wars" - Geschichten aus der rauen Wirklichkeit. Quelle: Knu89 (mit Anhang: Knu89e), bei Bedarf auch: Eis97
• Erkenntnisse über Defekte: Mit Hinblick auf die Ursachen ihrer Entstehung, lohnt es sich zunächst, einen Blick auf die Defekte selbst zu legen.
  • (2) Defektuntersuchungen: Hier werden einige Ergebnisse der systematischen Defektbeobachtung überblicksartig zusammengefasst. Quellen: Mar90, vielleicht ShuBasBoe02, evtl. zitierte Papers detaillierter betrachtet.
  • (3) Klassifizierungen: Wir betrachten, wie man Defekte klassifizieren kann und wozu man eine solche Klassifizierung in der Praxis nutzt und nutzen kann. Quellen: FreBas98, Fre01
• Defektabschätzung: Aufgrund von Prozess-, Programm- und Änderungsmetriken versucht man die noch vorhandenen Defekte vorher zu sagen, was der Qualitätssicherung früh helfen kann.
  • (4) Abschätzung 1: Hier werden einige Herangehensweisen an die Problematik vorgestellt. Quellen: FenOhl98, HasHol01
  • (5) Abschätzung 2: Aus der Erfahrung anderer Arbeiten wird eine optimale Formel errechnet. Quellen: MocWei00, GraKarMar99
  • (6) Abschätzung 3: Hier wird eine kritische Sicht auf die Vorhersagen geworfen. Quellen: FenNei99, FenNei00

Fehleranalyse: Im Gegensatz zur Betrachtung der Defekte, geht es hier um die Analyse der (menschlichen) Fehler, die zu den Defekten führen.

• Kognitive Aspekte: Da der Programmierer immer noch ein Mensch ist und Defekte immer auch sog. "menschliches Versagen" ist, lohnt sich eine Betrachtung der psychologischen Aspekte. Die Verbindung von Informatik mit der kognitiven Psychologie steckt allerdings noch in den Kinderschuhen.
  • (7) Denkfallen: Beim Programmieren muss man ständig komplizierte Rätsel lösen. Kein Wunder, dass man hier und da in Denkfallen tappt. Quelle: Kapitel 3 aus Gra90
  • (8) Menschliches Versagen: Es gibt Ansätze, die Gründe für das Einbauen von Defekten auf der psychologischen Theorie des Menschlichen Versagens zu begründen. Quellen: CocSalMit93, KoMye03, evtl. noch Rea90 zum Verständnis.
• (9) Arbeitsumgebung und Arbeitsorganisation: Nicht nur individuell kognitive Umstände führen zu Fehlern, sondern auch das Arbeitsumfeld. Quellen: MarLis85, SolBerLat98, JacDawWil01

Vermeidung von Fehlern, Verhinderung von Defekten

Der Grundgedanke hier ist immer: Wenn das entstandene Produkt schlecht ist, muss der Fehler in der "Maschine" liegen, also der Weise, wie das Produkt entstand.

Prozessorientierte Mittel: Hier werden Vorgaben für den Entwicklungsprozess diskutiert, also der gesamte Weg der Produktentstehung wird untersucht.

• Lernende Unternehmen durch Prozessverbesserung: Durch Nachbetrachtung des abgelaufenen Herstellungsprozesses und der Symptomatik von Defekten werden systematische Lehren gezogen.
  • (10) Persönlicher Software Prozess (PSP^®): Durch genaue Protokollierung der eigenen Arbeit wird man auf typische Situationen und Umstände aufmerksam, in denen man als Programmierer Fehler macht. Quellen: Hum96 (zur Übersicht), HirKha00, Pre01
  • Root Cause Analysis : Eine intensive nachträgliche Betrachtung einzelner Defekte und ihrer Ursache deckt gezielt Schwachstellen auf.
    • (11) RCA 1: Einführung und eine Anwendung. Quellen: Car98, LesPerSto00
    • (12) RCA 2: Zwei Eigenentwicklungen. Quellen: PerEva85, NakKum91
  • (13) Orthogonal Defect Classification: Auch eine Art von Root Cause Analysis, jedoch mit dem Ziel, alle Defekte gleichmäßig zu erfassen. Quellen: ChiBhaCha92, ButMunKra02
• (14) Formale Methoden, Cleanroom Software Engineering: Fehler können auch verhindert werden, indem man möglichst viele Arbeitsschritte formal als korrekt nachweist, statt lediglich auf Intuition und Erfahrung zu setzen. Quellen: SelBasBak87, Lin94

Kodierorientierte Mittel: Ohne die Notwendigkeit, den gesamten Herstellungsprozess in Frage zu stellen, lassen sich einige Techniken einsetzen, den Programmierer (als Kodierer und Feinentwerfer) zu unterstützen und Fehler von vorneherein zu vermeiden.

• (15) Programmiersprachen: Es wurde untersucht, ob und wie viele Fehler eine statische Typsicherung verhindert - eine der vielen Mittel, die Programmiersprachen zur Defektvermeidung beitragen können. Quellen z.B.: Gan77, PreTic98
• (16) Semi-formale Mittel: Durch eine geschickte Erweiterung der Semantik einer Programmiersprache lassen sich automatisch Defekte erkennen. Quellen: FleLeiLil02, RusLei01
• (17) Programmiertipps: Es gibt eine Menge von Ratschlägen für Softwareentwickler, die vermutlich zu Code geringerer Defektdichte führen, wenn sie beachtet werden. Quellen: Es gibt viele Bücher dazu, z.B. "Der Pragmatische Programmierer", eine andere Quelle ist Code Smells.
• (18) Anti-Idioms, Anti-Patterns: Typische Programmkonstrukte (evtl. abhängig vom Produkt) werden im Vorhinein (also statisch, ohne das Programm auszuführen) verdächtigt, zum Versagen zu führen. Quellen: XieEng03, EngCheHal01
• Archäologisches: Durch automatisiertes Lernen aus der Vergangenheit und alten Programmteilen wird der Programmierer aufmerksam gemacht, was er tun und was er besser lassen sollte.
  • (19) Analyse vergangener Tätigkeiten: Der Programmierer bekommt Tipps der Art "Kollegen, die vor Dir das gleiche getan haben wie Du, haben gleichzeitig aber noch was anderes getan". Quellen: YinMurNg03, ZimWeiDie04
  • (20) Analyse vergangener Defektbehebungen: Der Programmierer bekommt Tipps der Art "Konstrukte der Art, die Du soeben kodiert hast, waren früher schon mal als Defekt erkannt worden". Quellen: WohHoeOhl00, WilHol04

Teilnehmer, Begutachtungen und Termine

Die folgende Themenverteilung ist aktuell, könnte sich aber noch ändern. Bitte fügt zu dieser Liste Eure aktuellen Versionen der Ausarbeitungen und Folien selbstständig ein (Hinweise siehe FileAttachment - nennt Euer PDF wie in der Spalte angegeben, Anmelden muss man sich mit seinem gewohnten inf-Account), damit die Gutachter Zugriff darauf haben. Unter Bg 1/2 stehen die zu begutachtenden Themen. Begutachtet werden zweimal Ausarbeitung, Vortrag und Vortragsfolien. Die Termine sind nicht c.t und sind eng gelegt, so dass ein Überziehen nicht ausgeschlossen ist. Unter B steht ein ?, wenn noch keine Einzelbesprechung statt fand - siehe die Termine unter SeminarFehlerSoftwareentwicklung2004.

(Man kann die Spalten sortieren, indem man auf den Spaltenkopf klickt.)

Referenzen

BasPer84	Victor R. Basili, Barry T. Perricon. Software errors and complexity: an empirical investigation, Communications of the ACM, Volume 27, Issue 1 (January 1984), Pages: 42 - 52
BhaHalTar93	Inderpal S. Bhandari, Michael Halliday, Eric Tarver, David Brown, Jarir Chaar, Ram Chillarege. A Case Study of Software Process Improvement During Development. IEEE Trans. Software Eng. 19(12): 1157-1170 (1993)
ButMunKra02	M. Butcher, H. Munro, T. Kratschmer. Improving software testing via ODC: Three case studies. IBM Systems Journal, March, 2002
Car98	David N. Card. Learning from Our Mistakes with Defect Causal Analysis. IEEE Software, Volume 15, Issue 1 (January 1998), Pages: 56 - 63
ChiBhaCha92	Ram Chillarege, Inderpal S. Bhandari, Jarir K. Chaar, Michael J. Halliday, Diane S. Moebus, Bonnie K. Ray, Man-Yuen Wong. Orthogonal Defect Classification - A Concept for In-Process Measurements. IEEE Transactions on Software Engineering, Vol 18, No. 11, Nov 1992
CocSalMit93	Trevor Cockram, Jim Salter, Keith Mitchell, Judith Cooper, Brian Kinch, John May. Human Error in the Software Generation Process. http://www.branchlines.org.uk/
CocWil01	Laurie Williams, Alistair Cockburn. The Costs and Benefits of Pair Programming. Humans and Technology Technical Report 2000.01, Jan '00
Dij68	Edsger W. Dijkstra. Go To Statement Considered Harmful, Communications of the ACM, Vol. 11, No. 3, March 1968, pp. 147-148
Eis97	Marc Eisenstad. My hairiest bug war stories, Communications of the ACM, Volume 40, Issue 4 (April 1997), Pages 30 - 37
EndCheHal01	Dawson Engler, David Yu Chen, Seth Hallem, Andy Chou, and Benjamin Chelf: Bugs as Deviant Behavior: A General Approach to Inferring Errors in Systems Code. Proceedings of the eighteenth ACM symposium on Operating systems principles, Banff, Alberta, Canada 2001, pp. 57 - 72
FenNei00	Norman Fenton, Martin Neil. Software Metrics: A Roadmap, from "The Future of Software Engineering" , Anthony Finkelstein (Ed.), ACM Press 2000
FenNei99	Norman E. Fenton, Martin Neil. A Critique of Software Defect Prediction Models, IEEE Transactions on Software Engineering, September/October 1999 (Vol. 25, No. 5), pp. 675-689
FenOhl98	Norman E. Fenton, Niclas Ohlsson. Quantitative Analysis of Faults and Failures in a Complex Software System, IEEE Transactions of Software Engineering, August 2000 (Vol. 26, No. 8), pp. 797-814
FleLEiLil02	Cormac Flanagan, K. Rustan M. Leino, Mark Lillibridge, Greg Nelson, James B. Saxe, Raymie Stata: Extended Static Checking for Java. In Proc. PLDI, 2002
Fre01	Bernd Freimut. Developing and Using Defect Classification Schemes. Report Fraunhofer IESE-072.01/E, Sep. 1, 2001
FreBas98	Michael Fredericks, Victor Basili. Using Defect Tracking and Analysis to Improve Software Quality, DACS State-of-the-Art Report SP0700-98-4000, Data & Analysis Center for Software, 14 November 1998
Gan77	J. D. Gannon. An experimental evaluation of data type conventions. Communications of the ACM, Volume 20, Issue 8 (August 1977), Pages: 584 - 595
Gra90	Timm Grams. Denkfallen und Programmierfehler, Springer-Verlag Berlin Heidelberg 1990
GraKarMar99	Todd L. Graves, Alan F. Karr, J. S. Marron, Harvey Siy. Predicting Fault Incidence Using Software Change History, IEEE Transactions on Software Engineering archive, Volume 26, Issue 7 (July 2000), Pages: 653 - 661
HasHol01	Ahmed E. Hassan, Richard C. Holt. The Top Ten List: Dynamic Fault Prediction, Draft (Software Architecture Group (SWAG), University Of Waterloo), [http://citeseer.ist.psu.edu/650283.html]
HilRee96	Knut Hildebrand, Jan-Arnim Reepmeyer: Repeat-Statement considered harmful? Ergebnisse einer empirischen Untersuchung, Informatik-Spektrum 19:68-70 (1996)
HirKha00	Hirmanpour, I and S Khajenoori. Personal Software Process Technology: An Experiential Report. In The Proceedings of ISECON 2000, v 17 (Philadelphia): §115
Hum96	Watts S. Humphrey. Using A Defined and Measured Personal Software Process, IEEE Software, May 1996 (Vol. 13, No. 3), pp. 77-88
JacDawWil01	T. W. Jackson, R. J. Dawson, D. Wilson. The cost of email interruption, Journal of Systems and Information Technology, 5 (1), 81-92, 2001
Knu89	D. E. Knuth. The errors of TEX, Software—Practice & Experience archive, Volume 19, Issue 7 (July 1989), Pages 607 - 685
KoMye03	Andrew J. Ko, Brad A. Myers. A Framework and Methodology for Studying the Causes of Software Errors in Programming Systems, To appear in the Journal of Visual Languages and Computing
LesPerSto00	Marek Leszak, Dewayne E. Perry, Dieter Stoll: A case study in root cause defect analysis. Proceedings of the 22nd International Conference on on Software Engineering, June 4-11, 2000, Limerick Ireland. ACM, 2000, pp. 428-437
Lin94	R.C Linger: Cleanroom Process Model. IEEE Software 11,2 (March 1994), pp. 50-58
Mar90	Brian Marick. A survey of software fault surveys. Technical Report UIUCDCS-R-90-1651, University of Illinois at Urbana Champaign, December 1990
MarLis85	Tom De Marco, Tim Lister. Programmer performance and the effects of the workplace, Proceedings of the 8th international conference on Software engineering, p.268-272, August 28-30, 1985, London, England
MocWei00	Audris Mockus, David M. Weiss. Predicting Risk of software changes, Bell Labs Technical Journal, April-June 2000, pp. 169-180
Mue03	Matthias M. Müller. Are Reviews an Alternative to Pair Programming? In Conference on Empirical Assessment In Software Engineering (EASE), Keele, UK, April 2003
NakKum91	Takeshi Nakajo, Hitoshi Kume. A case history analysis of software error cause-effect relationships. IEEE Transactions on Software Engineering, Volume 17, Issue 8 (August 1991), Pages: 830 - 838
NawWoj01	Jerzy Nawrocki, Adam Wojciechowski. Experimental Evaluation of Pair Programming. In: K.Maxwell, S.Oligny, R. Kusters, E. van Veenendaal (eds.), Project Control: Satisfying the Customer, Shaker Publishing 2001 (Proceedings of the 12th European Software Control and Metrics Conference, ESCOM 2001, 2-4 April 2001, London), 269-276
Nos98	John T. Nosek. The case for collaborative programming. Communications of the ACM, Volume 41, Issue 3 (March 1998), Pages: 105 - 108
PerEva85	Dewayne E. Perry, W. Michael Evangelist. An Empirical Study of Software Interface Faults, Proceedings of the International Symposium on New Directions in Computing, IEEE Computer Society, August 1985, Trondheim, Norway, pages 32-38
Pre01	Lutz Prechelt. Accelerating Learning from Experience: Avoiding Defects Faster. IEEE Software. 18(6):56-61, November 2001.
PreTic98	L. Prechelt, W. F. Tichy. A controlled experiment to assess the benefits of procedure argument type checking. IEEE Transactions on Software Engineering, 24(4):302--312, Apr. 1998.
Rea90	James Reason. Human Error, Cambridge, MA: Cambridge University Press 1990
RusLei01	K. Rustan, M. Leino. Extended static checking: A ten-year perspective. In Reinhard Wilhelm, editor, Informatics: 10 Years Back, 10 Years Ahead, volume 2000 of Lecture Notes in Computer Science, pages 157--175. Springer-Verlag, 2001
SelBasBak87	Richard W. Selby, Victor R. Basili, F. Terry Baker. Cleanroom Software Development: An Empirical Evaluation. IEEE Transactions on Software Engineering, Volume 13, Issue 9 (September 1987), Pages: 1027 - 1037
ShuBasBoe02	Forrest Shull, Vic Basili, Barry Boehm, A. Winsor Brown, Patricia Costa, Mikael Lindvall, Dan Port, Ioana Rus, Roseanne Tesoriero, Marvin Zelkowitz. What We Have Learned About Fighting Defects. eWorkshop Results, NSF Center for Empirically Based Software Engineering
SolBerLat98	Rini van Solingen, Egon Berghout, Frank van Latum: Interrupts. Just a Minute never is, IEEE Software, 15 (5), pp. 97-103, 1998
WilHol04	Chadd C. Williams, Jeffrey K. Hollingsworth. Bug Driven Bug Finders. International Workshop on Mining Software Repositories (MSR), May 2004
WilKesCun00	Laurie Williams, Robert R. Kessler, Ward Cunningham, Ron Jeffries. Strengthening the Case for Pair Programming. IEEE SOFTWARE, July/August 2000, pp 19--25
WohHoeOhl00	Claes Wohlin, Martin Höst, Magnus C. Ohlsson Understanding the Sources of Software Defects: A Filtering Approach. 8th International Workshop on Program Comprehension (IWPC'00), June 10 - 11, Limerick, Ireland 2000, p. 9
XieEng03	Yichen Xie, Dawson Engler. Using redundancies to find errors. SIGSOFT Softw. Eng. Notes, volume 27, number 6, 2002, pp. 51-60
YinMurNg03	Annie T.T. Ying, Gail C. Murphy, Raymond Ng, Mark C. Chu-Carroll: Predicting Source Code Changes by Mining Revision History, Transactions on Software Engineering, September 2004 (Vol. 30, No. 9), pp. 574-586
ZimWeiDiw04	Thomas Zimmermann, Peter Weißgerber, Stephan Diehl, Andreas Zeller. Mining Version Histories to Guide Software Changes. Proc. 26th International Conference on Software Engineering (ICSE), Edinburgh, UK, May 2004.

Kommentare

(Hier ist Platz für Kommentare.)