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

Seminar zu Ursachen und Vermeidung von Fehlern in der Softwareentwicklung (vol. 2)

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.

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.

Die Themen bauen auf das gleichlautende Seminar von WS 04/05 auf.

Organisatorisches

Das Seminar ist geeignet für Informatikstudierende (auch Bachelor und Master) und Nebenfächler, die die Vorlesung Softwaretechnik gehört haben. Gasthörer sind willkommen. Im KVV ist das Seminar unter https://www.mi.fu-berlin.de/kvv/?veranstaltung=981 zu finden. Die Veranstaltungsnummer ist 19586.

Im KVV müssen Sie sich als TeilnehmerIn eintragen. Tragen Sie sich zusätzlich (auch als InteressentIn oder GasthörerIn) unbedingt in die Mailingliste http://lists.spline.inf.fu-berlin.de/mailman/listinfo/se_s_defects oder Mail an se_s_defects-request@lists.spline.inf.fu-berlin.de mit Subject subscribe ein.

Die Erstbesprechung (Foliensatz) und die Themenvergabe (siehe unten) sind abgeschlossen. Es sind noch Plätze frei. 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.

Das Seminar wird an einem Block in der vorlesungsfreien Zeit vom 3. - 5. April 2006 (KW 14) im Raum 046 (Info-Gebäude, Takustr. 9) statt finden.

Die Vorbereitungstermine sind:

• Ab sofort bis spätestens 31.1. Besprechung mit SebastianJekutsch über die Inhalte (Kurzfassung/Abstract vorher zuschicken) und Gliederung (ebenfalls vorher zuschicken) der Ausarbeitung und des Vortrags. Der Besprechungstermin wird von den TeilnehmerInnen gemacht. Eine Mail an SebastianJekutsch mit zwei Terminvorschlägen genügt.
• Bis spätestens 28.2. müssen die jeweils erste Version der Ausarbeitung und der Folien auf diese Seite hochgeladen werden, damit die Gutachter ihre Arbeit beginnen könnnen.
• Bis spätestens 19.3. müssen die Begutachtungen den Autoren per Mail zugeschickt werden. Dabei unbedingt SebastianJekutsch auf CC setzen.
• Bis spätestens 31.3., also noch vor dem Blocktermin, muss die endgültige Version der Ausarbeitung auf diese Seite hochgeladen werden. Spätere Versionen werden nicht beachtet.
• Seminarblock vom 3.-5.4., jeweils ab 10 Uhr s.t.
• Die Scheine wird es dann voraussichtlich ab dem 18.4. geben.

Die Termine sind locker gelegt, bitte nichts auf den letzten Drücker machen. Ein Versäumen einer der Termine (inkl. der des Seminarblocks) gefährdet die Scheinvergabe oder drückt auf die Note.

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 SebastianJekutsch jederzeit zur Verfügung.

Themen

Es folgen Themenvorschläge. Alle kursiv fett gedruckten und nummerierten Themen können zu einem Vortrag ausgeführt werden, lediglich fett gedrucktes sind Zwischenüberschriften.

Gerne werden auch andere thematisch passende Vorschläge angenommen! Kontaktieren Sie hierzu bitte SebastianJekutsch.

Aus dem Seminar können sich Bachelor-/Studien- und Master-/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). Die Referenzen beziehen sich auf die Tabelle darunter, wenn sie nicht direkt verlinkt sind. Durch Klick auf das Kürzel können Sie die Quelle (Berechtigung vorausgesetzt) herunterladen.

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

• (1) Einstieg: Warum schafft es die Softwaretechnik im Vergleich zu anderen Ingenieurswissenschaften nicht, Produkte hoher Qualität herzustellen? Software hat einige Eigenschaften, die sie besonders fehleranfällig machen. Quellen: Bei00, Anfang von Bro87, Mil75 und eigene Überlegungen
• 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 zwei Untersuchungen vorgestellt, wo für Industrieprojekte eine ausführliche Untersuchung der Defekte und ihrer Ursachen vorgenommen wurde. Quellen: PerSti93, LesPerSto02
  • (3) COQUALMO: Ähnlich wie es mit COCOMO eine Hilfe zur Aufwandsabschätzung gibt, wurde in COQUALMO eine Berechnungsgrundlage für Defektdichten veröffentlicht, die sich aus vielerlei Erfahrungen mit realen Projekten ergeben hat. Quellen: Offizielle Internetquelle, ChuBoe99 und eigene Internetrecherche
• 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) Modulgröße und ähnliches: Es wird untersucht, wie weit schon einfache Maße, z.B. die Größe eines Moduls, defektträchtige Stellen aufdecken können. Quellen: BasPer84, MalDen00, Hat97
  • (6) Objektbasierte Maße: Raffiniertere Maße für objeckt-orientiert entworfene Software versprechen eine bessere Näherung für die Defektrate. Quellen: BriWueDal98, BasBriMel96, ElEBenGoe02
  • (7) Historische Maße: Ein anderer Weg zur Defektabschätzung, der auf Daten in der Versionsverwaltung eines Projektes basiert. Quellen: OstWey02, OstWeyBel04, OstWey05
  • (8) Prozessmaße: Schließlich eine prozess-orientierte Messung zur Defektabschätzung mit der Hypothese: Je chaotischer die Entwicklung war, desto wahrscheinlicher hat das Ergebnis schlechtere Qualität. Quellen: NagBal05, HasHol01 (und entspr. Kapitel in der Dissertation von Hassan)

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

• (9) Mikroprozessbetrachtung: Bei dieser Arbeit wurde untersucht, wie ein Programmierer die Codestelle aufgebaut hat, in der später ein Defekt gefunden wurde. Quelle: YanMonTak94 (Japanisch!), Yan95 (Japanisch, 26 MByte!), kurze Erwähnung in TorMatNak99
• (10) Stressfaktoren: Welchen Einfluss hat Stress auf die Qualität der Arbeit von Softwareentwicklern? Quellen: Gla97, FurAraIio94, ferner Aus01 und RajAna03 plus eigene Recherche.
• (11) Semantische Validierung der objektorientierten Analyse: Die Objektorientierung wird häufig als besonders natürlich angesehen, im Gegensatz zu dem früher üblichen funktionenorientierten Ansatz. Ist dies wirklich der Fall? Es gibt einige Hinweise, dass die "OO-Denke" den Menschen gar nicht so einfach fällt, wie man glauben mag. Das birgt viele Fehlermöglichkeiten in der Modellierung als auch in der Kommunikation. Quellen (ausleihbare Bücher, Verweise unten auf der Seite): Dzi95, Hoc90, Det02

Vermeidung von Fehlern, Verhinderung von Defekten

Der Grundgedanke im zweiten Teil ist immer: Wenn das entstandene Produkt schlecht ist, muss der Fehler in der Weise liegen, wie das Produkt entstand.

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

• (12) Persönlicher Software Prozess (PSP^®) 2: Durch genaue Protokollierung der eigenen Arbeit wird man auf typische Situationen und Umstände aufmerksam, in denen man als Programmierer Fehler macht. Aufbauend auf die Ausarbeitung im Seminar WS04/05 werden hier empirische Untersuchungen zum Erfolg dieser Methode zur Vermeidung von Defekten vorgestellt. Quellen: PSP-Vortrag im vorherigen Seminar, HirKha00, FerHumKha97, Wes00
• (13) Root Cause Analysis 2: Aufbauend auf die Ausarbeitung im Seminar WS04/05 wird hier eine konkrete, kodiernahe Anwendung der Defektanalyse vorgestellt. Quellen: RCA-Vortrag im vorherigen Seminar, Yu98

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.

• (14) Programmiertipps: Es gibt eine Menge von Ratschlägen für Softwareentwickler, die vermutlich zu Code geringerer Defektdichte führen. Quellen: Eines der bekannten Bücher in diesem Bereich ist "The Pragmatical Programmer" von Andrew Hunt und David Thomas, ein anderes "Code Complete" von Steve McConnell.
• (15) Statische Analyse: Typische Programmkonstrukte (abhängig von der Programmiersprache) werden zur Compilezeit (also statisch, ohne das Programm auszuführen) verdächtigt, zum Versagen zu führen. Quellen: NagBal05, HovPug04 (dazu auch http://findbugs.sourceforge.net/)
• 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.
  • (16) Analyse vergangener Defektbehebungen: Der Programmierer bekommt Tipps der Art "Konstrukte der Form, die Du soeben kodiert hast, waren früher schon mal als Defekt erkannt worden". Quellen: WohHoeOhl00, WilHol04, LivZim05
  • (17) Analyse vergangener Änderungen: Der Programmierer bekommt Tipps der Art "Änderungen der Form, die Du soeben unternommen hast, waren früher schon mal für schlecht befunden worden". Quellen: SliZimZel05, PurPer03

Teilnehmer, Begutachtungen und Termine

Die folgende Themenverteilung ist aktuell, könnte sich aber noch ändern. Die Termine sind nicht c.t. Unter B steht ein ?, wenn noch keine Einzelbesprechung statt fand - siehe die Termine unter #Organisatorisches.

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, also für den/die TeilnehmerIn der Tabellenzeile zu begutachtenden Arbeiten. Begutachtet werden je zweimal Ausarbeitung und Vortragsfolien. Wie eine Begutachtung auszusehen hat, steht - wie so vieles - unter SeminarRegeln.

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

Referenzen

Durch Klick auf das Kürzel können Sie die Quelle (Berechtigung vorausgesetzt) herunterladen.

Aus01 (2,5 MByte)	Robert D. Austin. The Effects of Time Pressure on Quality in Software Development: An Agency Model. Information Systems Research, Volume 12, Issue: 2, June 2001, pages 195 ff.
BasBriMel96	Victor R. Basili, Lionel C. Briand, Walcélio L. Melo. A Validation of Object-Oriented Design Metrics as Quality Indicators. IEEE Transactions on Software Engineering, Volume 22, Issue 10 (October 1996), pages: 751 - 761
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
Bei00	Boris Beizer. Software is different. Annals of Software Engineering, Volume 10, Numbers 1-4, March 2000, Pages: 293 - 310
BriWueDal98	Lionel C. Briand, Jürgen Wüst, John W. Daly, D. Victor Porter. Exploring the relationship between design measures and software quality in object-oriented systems. Journal of Systems and Software, Volume 51, Issue 3 (May 2000), pages: 245 - 273
Bro87	Frederick P. Brooks, Jr.: No Silver Bullet: Essence and Accidents of Software Engineering. IEEE Computer, Vol. 20, No. 4 (April 1987) pp. 10-19
ChuBoe99	Sunita Chulani, Barry Boehm. Modeling Software Defect Introduction Removal: COQUALMO(COnstructive QUALity MOdel). Technical report USC-CSE-99-510, USC-Center for Software Engineering, 1999
CocWil01	Laurie Williams, Alistair Cockburn. The Costs and Benefits of Pair Programming. Humans and Technology Technical Report 2000.01, Jan '00
Det02	Francoise Detienne: Software Design - cognitive aspects, 2002
Dzi95	Wolfgang Dzida (Hrsg.). Psychologie des Software-Entwurfs. Göttingen/Stuttgart 1995
ElEBenGoe02	Khaled El Emam, Saïda Benlarbi, Nishith Goel, Walcelio Melo, Hakim Lounis, Shesh N. Rai. The Optimal Class Size for Object-Oriented Software. IEEE Transactions on Software Engineering, Volume 28, Issue 5 (May 2002), Pages: 494 - 509
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
FerHumKha97	Pat Ferguson, Watts S. Humphrey, Soheil Khajenoori, Susan Macke, Annette Matvya. Results of Applying the Personal Software Process. IEEE Computer, Volume 30, Issue 5 (May 1997), Pages: 24 - 31
FurAraIio94	Tsuneo Furuyama, Yoshio Arai, Kazuhiko lio. Fault Generation Model and Mental Stress Effect Analysis. J. SYSTEMS SOFTWARE 1994; 26:31-42
Gla97	Robert L. Glass. The ups and downs of programmer stress. Communications of the ACM, Volume 40, Issue 4, April 1997, pages: 17 - 19
HasHol01	Ahmed E. Hassan and Richard C. Holt. The Top Ten List: Dynamic Fault Prediction. Software Architecture Group (SWAG), School of Computer Science, University of Waterloo, Canada
Hat97	Les Hatton. Reexamining the Fault Density-Component Size Connection. IEEE Software, Volume 14, Issue 2 (March 1997), Pages: 89 - 97
HirKha00	Iraj Hirmanpour, Soheil Khajenoori. Personal Software Process Technology: An Experiential Report. In Proceedings of ISECON 2000, v 17 (Philadelphia): pp. 115
Hoc90	Jean-Michel Hoc et.al (Hrsg.). Psychology of programming. Academic Press 1990
HovPug04	David Hovemeyer, William Pugh: Finding Bugs is Easy. ACM SIGPLAN Notices, Volume 39, Issue 12, December 2004, pages: 92 - 106
NagBal05	Nachiappan Nagappan, Thomas Ball. Static analysis tools as early indicators of pre-release defect density Proceedings of the 27th International Conference on Software Engineering, St. Louis, MO, USA, pages: 580 - 586, 2005
HulAbr05	Hanna Hulkko, Pekka Abrahamsson. A multiple case study on the impact of pair programming on product quality. Proceedings of the 27th International Conference on Software Engineering, St. Louis, MO, USA, pages: 495 - 504, 2005
LesPerSto02	Marek Leszaka, Dewayne E. Perry, Dieter Stoll. Classification and evaluation of defects in a project retrospective. The Journal of Systems and Software 61 (2002) 173–187
LivZim05	V. Benjamin Livshits and Thomas Zimmermann. DynaMine: Finding Common Error Patterns by Mining Software Revision Histories. In Proceedings of the ACM SIGSOFT Symposium on the Foundations of Software Engineering (FSE 2005), September 2005
MalDen00	Yashwant K. Malaiya, Jason Denton. Module Size Distribution and Defect Density, 11th International Symposium on Software Reliability Engineering (ISSRE'00), p. 62, 2000
Mil75	Harlan D. Mills. How to write correct programs and know it. Proceedings of the international conference on Reliable software, Los Angeles, California, 1975, pp.363-370
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
NagBal05	Nachiappan Nagappan, Thomas Ball. Use of Relative Code Churn Measures to Predict System Defetc Density. Proc. ICSE 2005, St. Louis, USA, Pages 284ff.
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
OstWey02	Thomas J. Ostrand, Elaine J. Weyuker. The distribution of faults in a large industrial software system. Proceedings of the 2002 ACM SIGSOFT international symposium on Software testing and analysis, Roma, Italy 2002, Pages: 55 - 64
OstWey05	Thomas J. Ostrand, Elaine J. Weyuker. A Tool for Mining Defect-Tracking Systems to Predict Fault-Prone Files. MSR 2005: International Workshop on Mining Software Repositories
OstWeyBel04	Thomas J. Ostrand, Elaine J. Weyuker, Robert M. Bell. Where the bugs are. Proceedings of the 2004 ACM SIGSOFT international symposium on Software testing and analysis, Boston, Massachusetts, USA, Pages: 86 - 96
PerSti93	Dewayne E. Perry, Carol S. Stieg. Software Faults in Evolving a Large, Real-Time System: a Case Study. Proceedings of the 4th European Software Engineering Conference on Software Engineering, September 13 - 17, 1993, Pages: 48 - 67
PurPer03	Ranjith Purushothaman, Dewayne E. Perry. Toward understanding the rhetoric of small source code changes. IEEE Transactions on Software Engineering, Volume 31, Issue 6, June 2005, Pages 511 - 526
RajAna03	K. S. Rajeswari, R. N. Anantharaman. Development of an instrument to measure stress among software professionals: factor analytic study. Proceedings of the 2003 SIGMIS Conference on Computer Personnel Research, Philadelphia, Pennsylvania, pages: 34 - 43
SliZimZel05	Jacek Śliwerski, Thomas Zimmermann, and Andreas Zeller. When do changes induce fixes? On Fridays. Proc. International Workshop on Mining Software Repositories (MSR), Saint Louis, Missouri, USA, May 2005
Tom05	J. Tomayko. A Comparison of Pair Programming to Inspections for Software Defect Reduction. Computer Science Education, 12(3):213–222, 2002
TorMatNak99	Koji Torii, Ken-ichi Matsumoto, Kumiyo Nakakoji, Yoshihiro Takada, Shingo Takada, Kazuyuki Shima. Ginger2: An Environment for Computer-Aided Empirical Software Engineering. IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 25, NO. 4, JULY/AUGUST 1999
Wes00	Anders Wesslén, A Replicated Empirical Study of the Impact of the Methods in the PSP on Individual Engineers, Empirical Software Engineering, Volume 5, Issue 2, Jun 2000, Page 93
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
Yan95 (Japanese, 26 MByte!)	M. Yanagi. A prototype system for warning programmers against committing errors. Master's Thesis, Department of Information Systems, Graduate School of Information Science, Nara Institute of Science and Technology, NAIST-IS-MT351119, Feb. 1995
YanMonTak94 (Japanese!)	M. Yanagi, A. Monden, Y. Takada, K. Torii. A tool detecting patterns of programmers' behavior when they likely inject bugs. Technical Report of IEICE SS94-36, Vol. 94, No. 334, pp.9-16, Nov. 1994
Yu98	Weider D. Yu. A software fault prevention approach in coding and root cause analysis. Bell Labs Technical Journal, 3(2), 3-21, (1998, April/June)

Kommentare

(Hier ist Platz für Kommentare.)

Commenting is disabled while not logged inPlease Login first, before submitting content.

SWTIDSR

• paper6.pdf: