II.3. Reviewtechniken. Übersicht. Softwaretechnik- Praktikum: 3. Vorlesung. Qualität und Phasen der Entwicklung?

Transkript

1 Softwaretechnik- Praktikum: 3. Vorlesung Jun.-Prof Prof.. Dr. Holger Giese Raum E Tel hg@upb.de Übersicht I Einleitung II Ergänzungen zur Software-Entwicklung III Software Management IV Software Qualitätssicherung V Zusammenfassung V3-2 Softwaretechnikpraktikum: II Ergänzungen zur Software-Entwicklung Qualität und Phasen der Entwicklung? Phase Testen Reviews Anforderungsdefinition? Analyse? Entwurf? Jun.-Prof Prof.. Dr. Holger Giese Raum E Tel hg@upb.de Implementierung Testen (Verifikation) Testen (Validation) V3-4 II Ergänzungen zur Software- Entwicklung & Vorgriff II.1 Machbarkeitsstudie II.2 Versions- und Konfigurationsmanagement II.3 Reviewtechniken II.4 Testtechniken II.5 Reverse Engineering II.6 Diskussion & Zusammenfassung II.7 Literaturhinweise II.3. Reviewtechniken Mehr oder weniger formales Vorgehen, in dem es darum geht, Fehler, Unklarheiten, Inkonsistenzen (allg. Schwächen) eines Dokumentes aufzudecken oder ein Entscheidung über Annahme oder Ablehnung zu fällen. Dazu wird das Dokument systematisch in einem Team (teilw. unter Beteiligung der Autoren des Dokuments) angesehen und besprochen Menschen und deren Sachverstand und nicht Werkzeuge sind hier das Mittel zur Untersuchung des Dokumentes Das Ergebnis sind identifizierte Probleme oder die Freigabe des Dokumentes (ggf. nach Iteration). V3-5 V3-6 1

2 Aufgabe und Ziele Sicherstellen, dass die Software Die Anforderungen erfüllt, Gegebenen Vorgaben/Standards entspricht und auf gleichartige Art und Weise entwickelt wird Auffinden von Fehlern Früher Mehrere und andere Andere Perspektive hinzufügen Projekte besser handhabbar machen Um neue Risiken zu identifizieren, die das Projekt beeinträchtigen könnten Verbesserung der Kommunikation Ständige Fortbildung aller Beteiligten Software sichtbar machen! Die beteiligten Rollen Review Team Manager Entwickler V3-7 V3-8 Rolle des Entwicklers Problem: Entwickler können in die Schusslinie geraten bzw. werden in die Mangel genommen Entwickler neigen deswegen dazu ihre Ergebnisse zu rechtfertigen statt sie nur zu erklären Psychologie des Reviews Grundregeln: Keine Vorgesetzen anwesend Keine Beurteilung anhand der Reviews Sachliche Gesprächsform Je nach Form des Reviews: Entwickler dabei oder auch nicht Entwickler Beteiligung der Manager Bewertung ist eigentlich Aufgabe der Manager Probleme: Technische Kompetenz Bewertung eines Produkts vs. Bewertung einer Person Aktive Beteiligung Nur als Aussenstehender! Als Projekt- oder Teamleiter Allgemeine Kompetenz Post facto Beteiligung Review Material Ggf. Bericht des Review V3-9 V3-10 Was und Wann? Was/Inhalt: Jedes im Rahmen der Entwicklung enstehende Dokument: Anforderungsdefinition, Analyse, Entwurf, Code, Dokumentation, Prozeduren, Schnittstellen,... Kontrolle der Produktkomplexität (implizit) Wann/Organisation: Kontrolle der Länge der Reviews 2 Stunden Termine für Reviews festlegen 10 Uhr Arten der Reviews (1) Persönliche Reviews (2) Walkthroughs (3) Inspections (4) Formale technische Reviews V3-11 V3-12 2

3 (1) Personal Review Informal Durch den Entwickler selber Nicht wirklich objektiv (nur eine Person) Nicht unabhängig (Entwickler hat als Ziel die Entwicklung abzuschließen und nicht Fehler zu finden begrenzter Überprüfungseffekt) Für jeden Entwickler verfügbar (2) Walkthroughs Gewisse Struktur Entwickler präsentiert oder steht zur Information zur Verfügung Größeres Publikum kann teilnehmen (Fortbildung) Material muss für eine Sitzung passen Kaum Vorbereitungszeit Nachteil: Es ist schwer zu trennen zwischen Entwickler und Vorführendem Erklärung und Rechtfertigung V3-13 V3-14 Prozess und Rollen (3) Inspections Teammitglieder prüfen das Material unabhängig voneinander Das Team und die Entwickler treffen sich um die Ergebnisse zu diskutieren Nur selektierte Aspekte eines Produktes können so betrachtet werden Fokus auf wichtige Dinge Wenn man weiß welche das sind Begrenzung des Materials pro Sitzung Signifikanter Aufwand für das Durcharbeiten des Materials V3-15 V3-16 Prozess und Rollen (4) Formale Technische Reviews Formalität Fest geplante Termine Fest definierte Abläufe Abschlussbericht notwendig Unabhängiges Team Entwickler ist nicht anwesend Höherer Zeitbedarf für die Vorbereitung Es kann weiniger Material in einer Sitzung besprochen werden Produkt muss für sich alleine angenommen oder abgelehnt werden See also: IEEE Standard for Software Reviews and Audits [IEEE 1028, 1988] V3-17 V3-18 3

4 Prozess Agenda einer Review Sitzung: Eine kurze Präsentation des Dokuments Kommentare Verifikation und Validation der Kommentare, um benötigte Aktivitäten zu bestimmen (Korrekturen, Änderungen oder Ergänzungen). Entscheidung über das Dokument, die den Projektfortschritt bestimmt Vergleich Eigenschaft Vortreffen Vorbereitung der Teammitglieder Sitzung Nachfolgende Aktivitäten Formales Training de Teilnehmer Checklisten Formaler technischer Review sehr gründlich No No Inspection - gründlich Walkthrough - oberflächlich Post Review Aktivitäten: Bericht erstellen Überwachung der identifizierten Korrekturen, Änderungen oder Ergänzungen Systematische Erfassung von Fehlern Review dokument Nicht formal benötigt Formal design review report Formal benötigt 1) Bericht zu den Ergebnissen der Inspection-Sitzung 2) Zusammenfassung der Inspection-Sitzung Nicht formal benötigt V3-19 V3-20 Formality of Technical Reviews Formaler technischer Review Inspections Korrektheit Walkthroughs Fehler erkennen Personal Review verbessern Team-orientiert individuelle Initiative Effektivität Year Defect detection method Defects per 1000 lines of Test Design Code review inspection maintained % % % code from [Cusomano1991] V3-21 V3-22 Effizienz Case Study: 700 KLOC Projekt, Echtzeitsystem, über 400 Entwickler, moderne Hochsprache, 3 hre Entwicklungsdauer Kosten gespart Effizienz = Kosten benötigt Zeit für Korrekturen (Stunden): 7.5 Entwurf 6.3 Code 11.6 Testen Fazit sehr effektive und effiziente Technik Low Tech (keine Tools etc.) Leider in der Praxis (und der Universität) viel zu wenig genutzt! Design Reviews 8.44 Code Reviews 1.38 Testen 0.17 [Collofello&Woodfield1989] V3-23 V3-24 4

5 Weitere Quellen [Ackerman+1989] A.F. Ackerman, L.S. Buchwald, F.H. Lewski, Software inspections: an effective verification process, IEEE Software 6 (May 1989), pp [Bush 1990] M. Bush, Improving software quality: the use of formal inspections at Jet Propulsion laboratory Proceedings of the 12th International Conference on Software Engineering, Nice, France, March 1990, pp [Collofello&Woodfield1989] J.S. Collofello and S. N. Woodfield. Evaluating the Effectiveness of Reliability-Assurance Techniques. Journal of Systems and Software, March [Cusumano1991] M. A. Cusumano. pan s Software Factories A Challange to u.s. Management. Oxford University Press, New York, [Dobbins1998] J. H. Dobbins. Inspections as an up-front quality technique. In G. G. Schulmeyer and J. i. McManus (eds), handbook of Software Quality Assurance, Prentice Hall, Harlow, Essex, UK, [Doolan1992] Doolan, E. P. Experience with Fagan s Inspection Method, Software-Practice and Experience, 22, 2, February 1992: [Fagan 1976] M.E. Fagan, Design and code inspections to reduce errors in program development, IBM Systems Journal 15 (No. 3, 1976), pp [Fagan 1986] M.E. Fagan, Advances in software inspections, IEEE Transactions on Software Engineering, SE-12 (July 1986), pp [Fowler 1986] P.J. Fowler, In-process inspections of workproducts at AT&T, AT&T Technical Journal 65 (March/April 1986), pp [Kelly+1992] J. C. Kelly, J. S. Sherif, and J. Hops. An Analysis of Defect Densities Found During Software Inspections. Journal of Systems and Software, [Parnas&Weiss1985] Parnas, D. L. & Weiss, D. M. Active Design reviews: Principles and Practices, Proceedings of the 8th Conference on Software Engineering, pp , August, [Parter+1994] Porter, A. A.; Votta, Jr., L. G.; & Basili, V. R. Comparing Inspection Methods for Software Requirements Inspections: A Replicated Experiment, University of Maryland Technical Report (CS-TR-3327), [E&S Tech Rept MDU 3327] [Weller1993] E. F. Weller. Lessons From Three Years of Inspection Data. IEEE Software, Sept Softwaretechnikpraktikum: Aktuelle Aufgaben und Fragerunde V3-25 Wiederholung: CVS Fragen (konzeptionell): keine Fragen (technisch): Versehentliches anlegen von Verzeichnissen unter CVSROOT? Commit in CVSROOT ist technisch unterbunden. Verzeichnisse werden beim hinzufügen (CVS add) bereits angelegt und das wird nicht technisch unterbunden. Löschen/Umbenennen von Verzeichnissen? Geht NICHT! Einfach ignorieren (als Modul sieht man das eh nie, Bei einem Verzeichnis in einem Modul kann man den CVS-Client so einstellen, dass er leere Verzeichnisse lokal löscht (Stichwort: "prune empty directory") Mit anderen Werkzeugen (z.b. Subversion) geht das schon! Aufgaben: Allgemeines (immer noch!) Machen Sie sich mit der Aufgabenstellung vertraut: Wichtige Begriffe und Konzepte (Glossar) Zusammenfassung der Aufgabenstellung Liste mit Fragen und Unklarheiten Gute Ideen sammeln Machen Sie sich mit der Projektplanskizze vertraut Was sollen wir alles machen? V3-27 V3-28 Aufgabe: Lastenheft Nur für die 1. Teilaufgabe (und nicht für den Simulationsalgorithmus oder die Integration) Zusammenfassung aller fachlichen Basisanforderungen wesentliche Funktionen (Use Cases) wesentliche Daten Grundlage für die Aufwandsschätzung Grundlage für die Erstellung des Projektplanes Bemerkungen: Umfang: wenige Seiten Reuse für das Pflichtenheft! Aufgabe: Aufwandsschätzung Alle Schätzverfahren erfordern Viel Erfahrung Aufwandsdaten aus vorherigen Softwareprojekten (Basis für die Hypothese der konstanten Produktivität) Im Praktikum wird deshalb Die Aufwandsschätzung wird nicht bewertet! Am Ende das Schätzergebnis mit dem tatsächlichen Umfang bzw. Aufwand nur vergleichen Stundenzettel Aufgabe: Gebt bitte eine solche Zählen der LOC (CVS) Aufwandschätzung ab, wie ihr ihr sie auch für für einen potentiellen Kunden gestalten würdet. V3-29 V3-30 5

6 Aufgabe: Pflichtenheft Nur für die Teilaufgabe! Zusammenhängende Darstellung aller fachlichen Anforderungen an das Produkt (Sicht des Benutzers). Es sollte beschrieben, was das Produkt leisten sollte, nicht wie es das leistet Fragen? Bemerkungen: Umfang: max. 30 Seiten Reuse des Lastenhefts! V3-31 V3-32 6