Methodik

• Zielsetzung
  Oberstes Ziel eines Reviews ist die Verbesserung des Projektes unter Beachtung der Anforderungen der Projektleitung (PL) und der Projekthistorie. Hierzu ist die Kooperation aller Beteiligter und ein fairer Umgang erforderlich.
• Zulieferungen
  Gegenstand eines Review sind i.a. die Projektphasen Analyse, Design, Implementierung, Deployment und Betrieb. Für die Durchführung des Reviews werden deshalb die vorhandene Projektdokumentation (Fachkonzept, IT-Konzept inkl. Architektur, Lasttests, Betriebsübernahme) und der vollständige SourceCode benötigt.
  
• Fachkonzept
  Für einen qualifierten Review ist eine grobe Einarbeitung in die Fachlichkeit erforderlich.
• Anwenderbefragung
  Ein repräsentativer Anwender wird nach seinen Erfahrungen mit der Anwendung (meist an Hand der graphischen Oberfläche) befragt.
• Design- und Coding-Richtlinien
  Falls entsprechende Richtlinien vorhanden sind, werden diese abgestimmt und als verbindlich vereinbart. Andernfalls werden geeignete Richtlinien und Metrikvorschläge von SET geliefert und abgestimmt.
• Designentscheidungen
  Die wesentlichen Design-Entscheidungen werden hinterfragt.
• Hotspots
  Es werden die ca. 20 bis 30 wichtigsten Klassen der Anwendung ("Hotspots") festgelegt, die als Ausgangsbasis für die visuelle Code-Analyse dienen.
  
• Toolbasierte Auswertungen
  Der gesamte Source-Code wird mit verschiedenen Tools analysiert. Hierzu verwenden wir insbesondere ein von SET entwickeltes QS-Tool.
• Review-Bericht
  Ein von SET erstellter Review-Bericht hat bei einer mittleren Projektqualität und einer SourceCode-Größe von 2000 bis 3000 Klassen einen Umfang von ca. 100 bis 200 Seiten (ohne tool-basierte Auswertungen!). Hierin werden die bemängelten Schwachstellen grundsätzlich nach dem Schema "Problem, Ursache, Verbesserungs- und Massnahmenvorschläge" dargestellt. Somit werden "Schöner wohnen"-Themen vermieden und ausschliesslich Schwachstellen genannt, die für den Betreiber zu einem absehbaren Problem führen werden! Diese Probleme werden in die Kategorien Stabilität, Performance und Wartung eingeordnet, priorisiert und einer Risikobewertung unterzogen.
  Hierbei legen wir auf eine bestmögliche Dokumentation (z.B. mit Angabe Klasse und der Zeilennummer) Wert, um eine möglichst unanfechtbare Beweisführung sicherzustellen.
  Der Review-Bericht wird mit der Projektleitung abgestimmt und den Entwicklern mit der Bitte einer Gegendarstellung übergeben.
• Ergebnispräsentation, Abschlussbericht
  Der Review-Bericht wird in einem Workshop präsentiert und einer fachlichen Diskussion unterzogen. Die beschlossenen Massnahmen werden in einem Abschlussbericht dokumentiert.
• Umgesetzung der beschlossenen Massnahmen
  Auf Wunsch begleiten wir die Umsetzung der beschlossenen Massnahmen und führen eine Ergebniskontrolle durch.