Übersicht der Vorlesung. Qualitätssicherung in der Softwareentwicklung. Review-Prozeß. Direkte Ziele VU 10. DI Dr. Bernhard K.

Transkript

1 Übersicht der Vorlesung VU 10 Institut für Softwaretechnologie (IST) TU Graz 1 Sommersemester 2007 Review-Prozeß Direkte Ziele Definition (IEEE (1990)) A process or meeting during which a work product, or set of work products, is presented to project personnel, managers, users, customers, or other interested parties for comment or approval. Methoden: : Inspektionen Walkthroughs Auffinden von Analyse- und Entwurfsfehlern, als auch von Bereichen wo Korrekturen und Vervollständigungen bzgl. der Spezifikationen notwendig sind. Identifizieren von neuen Risiken, bzgl. der Fertigstellung des Produkts. Lokalisieren von Abweichungen von Konventionen um größere Uniformität zu erreichen. Bestätigen des Analyse- oder Entwurfsdokuments um fortfahren zu können.

2 Indirekte Ziele (Formale) Design Bieten eines informellen Forums zum Austausch von Expertenwissen (Entwicklungsmethoden, Werkzeuge, Techniken). Aufzeichnen von Analyse und Designfehlern als Basis für zukünftige Verbesserungen des Entwicklungsprozesses und des Produkts. Stimulation des Entwicklungsteams ihr Bestes zu geben. Die Review-Methoden unterscheiden sich durch Betonung der verschiedenen Ziele. auch Formale Technische genannt Besonderheit: Notwendig um das Entwurfsprodukt zu bestätigen und in die nächste Phase zu gehen. Example können zu jedem Meilenstein stattfinden Development Plan R., Software Requirement Specification R., Preliminary Design R., Detailed Design R., Data Base Design R., Test Plan R., Software Test Procedure R., Version Description R., Operator Manual R., Support Manual R., Product Release R. Teilnehmer Vorbereitungen Review-Leiter: Wissen und Erfahrung in Projekten dieses Typs. Dienstalter (Stellung) ähnlich, wenn nicht höher als, Projektleiter. Gute Beziehung zum Projektleiter und seinem Team. Eine Position extern zum Projekt. Kandidaten: Manager der Entwicklungsabteilung, Chef-Softwareingeniere, Projektleiter anderer Projekte, Leiter der Qualitätssicherung, Chef-Softwareingenieur des Kunden, Konsulenten. Review-Team Senior-Members des Projekts u. anderer Projekte, Kundenrepräsentanten, Konsulenten. 3-5 Mitglieder (Mehrheit extern!) Review-Leiter Berufen der Mitglieder Zeitliches Festlegen der Review-Sessions. Verteilen des Entwurfsdokumentes unter den Mitgliedern. Review-Team Review der Design-Dokumente (kann auch aufgeteilt werden), Auflisten der Kommentare Verwendung von Checklisten Entwicklungsteam Vorbereitung einer kurzen Präsentation des Entwurfdokumentes, mit Fokus auf das Wichtigste, das Bestätigung bedarf. Achtung! Zu lange Präsentationen sabotieren Review-Sessions.

3 Session-Agenda Review-Report Dauer: 2h 1 Kurze Präsentation des Entwurfsdokumentes 2 Kommentare des Review-Teams 3 Verifikation und Validierung in der jedes der Kommentare diskutiert wird um die notwendigen Aktionen (Korrekturen, Änderungen, Hinzufügungen) festzulegen. 4 Entscheidung bzgl. des Dokumentes: Volle Bestätigung: sofort in die nächste Phase des Projektes, nur kleine Änderungen können gefordert werden. Partielle Bestätigung: mit Teilen des Projektes in nächste Phase, mit notwendigen Aktionen für den Rest. Bestätigung nach Änderung durch einen Reviewer oder einer speziellen Session. Verweigerung der Bestätigung: Review muss wiederholt werden; bei mehreren schweren bzw. kritischen Fehlern. Schnelle Herausgabe mit folgenden Sektionen: Zusammenfassung der Review-Diskussionen Entscheidung Eine vollständige Liste aller Aktionen, mit Fertigstellungsdatum und Verantwortlichen. Die Namen der Reviewers, welche die Performance der Änderungen überwachen sollen. Kennzeichen schlechter Review-Reports: Extrem kurzer Report, der nur die Bestätigung ohne Fehler dokumentiert. Ein Report, der Aktionen versch. Gewichtung listet, aber keinen Hinweis auf Follow-up-Aktionen (Zeitplan) beinhaltet. Inspektionen Unterschied zu Design- liegt in Teilnehmern und deren Autorität: DR-Teilnehmer: über dem Projektleiter, Kundenrepräsentanten PR-Teilnehmer: auf gleicher Stufe mit Projektleiter, aus seiner Abteilung Ziel ist das Finden von Fehlern und das Abweichen von Standards. Methoden: Inspektionen: Betonung auf korrektiven Aktionen bzgl. des Entwicklungsprozesses (formeller), [Fagan 1976] Walkthroughs: Kommentierung des Dokumentes [Yourdon 1979]. Kontroverse um bessere Methode und Definition. Checklisten für jeden Typ von Designdokumenten und Programmiersprachen und Werkzeuge, die periodisch upgedated werden. Tabellen mit typischen Häufigkeiten von Fehlertypen, basierend auf vergangenen Inspektionen, um die Inspektoren zu den Problemzonen zu leiten (Vorbedingungen!). Ausbildungen zum Software-Inspektor. Periodische Analyse der Effektivität von vergangenen Inspektionen um die Inspektionsmethode zu verbessern. Einführung von Inspektionen in den Zeitplan mit notwendigen Resourcen.

4 Teilnehmer bei Inspektionen Teilnehmer bei Walkthroughs 3-5 Teilnehmer: Autor und Ebenbürtige (Peers). Moderator: ist der Leiter. Designer: Systemanalyst des Projekts Kodierer: Bevorzugterweise der Leiter des Kodierungsteams Tester: Bevorzugterweise der Leiter des Testteams. Rollen: Präsentator: vom Moderator gewählt, nicht der Autor des Dokumentes, oft der Kodierer, da er am besten die Implikationen auf die Implementierung versteht; zudem ist er neutral und beeinflußt das Urteil der Reviewer weniger. Protokollführer: oft der Moderator 3-5 Teilnehmer: Autor und Ebenbürtige (Peers). Koordinator: ist der Leiter. Standards Enforcer: Lokalisieren von Abweichungen von Entwicklungsstandards. Wartungsexperte: Wartbarkeit, Flexibilität, Testbarkeit Kundenrepräsentant: interner bzw. externer Benützer zur Validierung. Rollen: Präsentator: der Autor, da am vertrautesten mit Dokument. Protokollführer: oft der Moderator Vorbereitungen Inspection-Session Leiter: Festlegen der Teile, die zu Reviewen sind (mit dem Autor): komplexe, kritische oder bekannt fehleranfällige Auswahl der Mitglieder Zeitl. Festsetzen der Sessions < 2h, bis zwei Sessions pro Tag Verteilen des Dokuments an die Teilnehmer vor der Review-Session. Teilnehmer an Inspektionen: Überblickstreffen: Autor gibt Hintergrundinformationen zum Projekt, Schnittstellen, Logik, Prozeß etc. (kann entfallen). Lesen der Dokumentsektionen und Auflisten der Kommentare. Teilnehmer an Walkthroughs: Kurzes Durchlesen des Dokuments um Überblick zu bekommen. Kommentare werden nicht vorbereitet. Präsentator liest einen Abschnitt des Dokuments vor und kommentiert Schwierigkeiten Teilnehmer geben ihre Kommentare: Diskussionen sollten sich auf Fehler nicht auf Lösungen konzentrieren. Protokollführer dokumentiert Fehler mit Ort, Beschreibung, Typ und Charakter (inkorrekt, fehlender Teil, Extrateile) und Schwere des Fehlers.

5 Walkthrough-Session Fehlerklassifizierung bei Inspektionen Autor gibt kurze Präsentation zum Hintergrund und Überblick des Projekts. Autor liest einen Abschnitt des Dokuments vor und kommentiert Schwierigkeiten. Teilnehmer geben ihre Kommentare: Diskussionen sollten sich auf Fehler nicht auf Lösungen konzentrieren. Protokollführer dokumentiert Fehler mit Ort, Beschreibung, Typ und Charakter (inkorrekt, fehlender Teil, Extrateile). Nach MIL-STD-498 [DOD 1994]: 1 (geringfügig), jeder andere Effekt. 2 Anwender/Operator-Unbequemlichkeit ohne die essentiellen Fähigkeiten zu beeinträchtigen. Unbequemlichkeit für die Entwickler oder das Wartungspersonal, aber verhindert nicht die Realisierung deren Verantwortlichkeit. 3 wie 4, es ist aber eine work-arround-lösung bekannt. 4 Behindert das Erreichen essentieller Fähigkeiten, wo keine work-arround-lösung bekannt ist. Betrifft technische, Kosten-, oder Zeitplan-Risiken, oder Wartbarkeit wo keine work-arround-lösung bekannt ist. 5 (kritisch) Verhindert Erreichen essentieller Fähigkeiten. Beeinträchtigt Safety, Security oder andere kritische Anforderungen. Reports bei Inspection Session Summary Report Daten Inspection Session Findings Report: Wird sofort nach Beendigung der Session vervollständigt und verteilt. Zweck ist die Dokumentation der Fehler und Follow-up. Inspection Session Summary Report: Nach den Sessions, die ein Dokument betreffen. Zusammenfassung des Gefundenen und der eingesetzten Resourcen. Präsentiert grundlegende Qualitäts- und Effizienzmetriken. Walkthrough Session Findings Report: die Fehlerdokumentation geht an das Entwicklerteam. Resourcen: Stunden gearbeitet pro Teammitglied Fehlerzusammenfassung: Anzahl, Art und Schwere der Fehler. Fehleranzahl wird standardisiert: Multiplikator je nach schwere des Fehlers (z.b. 5 16, 4 8, 3 4, 2 2, 1 1) Defektfindungsmetriken: Durchschnittliche Fehler pro Seite (LOC) Duchschnittliche standardisierte Fehler pro Seite (LOC) Defektfindungseffizienz: Stunden pro (standardisierten) Defekt.

6 Daten: National Software Quality Experiment 1992 Daten: Litton Projekt Inspektionslaboratorien, LOC Ges. Anzahl gefundener Fehler: 1849 Anzahl schwerer Fehler: 242 Ges. Vorbereitungszeit: Minuten Durchschn. Vorbereitungszeit pro Fehler: 12.3 Minuten Durchschn. Vorbereitungszeit pro schweren Fehler: 94.3 Minuten Gesamte Fehlerdichte (Fehler pro KLOC) : Schwere Fehlerdichte (Fehler pro KLOC) : Inspektionen von LOC Ges. Anzahl gefundener Fehler: 7165 Anzahl schwerer Fehler: 772 Ges. Vorbereitungszeit: 4612 Stunden Durchschn. Vorbereitungszeit pro Fehler: 1.5 Stunden Durchschn. Vorbereitungszeit pro schweren Fehler: 9.3 Stunden Gesamte Fehlerdichte (Fehler pro KLOC) : Schwere Fehlerdichte (Fehler pro KLOC) : 2.80 Peer-Review Abdeckung Nur 5-15% werden reviewed: Komplizierte Logik Kritische Abschnitte Abschnitte die neue Umgebungen behandeln Abschnitte von neuen oder unerfahrenen Mitgliedern