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.
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)
- (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
- (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 SeminarFehlerSoftwareentwicklung2005. 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.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.)
SWTIDSR