Software-Engineering II Eingebettete Systeme, Softwarequalit

1
Software-Engineering IIEingebettete Systeme,
Softwarequalität, Projektmanagement

• Prof. Dr. Holger Schlingloff
• Institut für Informatik der Humboldt Universität
• und
• Fraunhofer Institut für Rechnerarchitektur und
  Softwaretechnik

2
(No Transcript)
3
Prüfungstermine - Abstimmung

• 1. Termin Woche ab 6.3.2006
• 2. Termin Woche ab 3.4.2006
• Wochentage Di, Mi oder Do
• Eintrag in Liste bei Frau Heene
• Mitteilung per Mail über GOYA

4
Testplanung

• Erstellung eines detaillierten Dokumentes für
  folgende Punkte
• Testziele (welche Qualitätskriterien sollen
  eingehalten werden)
• Teststufen (in welchen Projektphasen sind welche
  Aktivitäten auszuführen)
• Testtypen (welche Tests sollen durchgeführt
  werden, welche Werkzeuge)
• Randbedingungen (Hardware / Softwareumgebung)
• Rollen und Verantwortlichkeiten
• Meilensteine und Deliverables

5
Muster eines Testplanes (1)

• 1. Einführung
• 1.1 Zielsetzung
• 1.2 Geltungsbereich
• 1.3 Definitionen und Abkürzungen
• 1.4 Referenzen
• 1.5 Übersicht
• 2. Teststrategie
• 2.1 Testtypen
• 2.1.1 Benutzbarkeitstest
• 2.1.2 Modultest
• 2.1.3 Integrationstest auf Komponentenebene
• 2.1.4 Annahmeprüfung
• 2.1.5 Systemtest
• 2.1.6 Abnahme
• 2.2 Test der einzelnen Releases

6
Muster eines Testplanes (2)

• 3. Testtools
• 3.1 Testumgebung
• 3.2 Testmanagement und Fehlerverfolgung
• 3.3 Funktions- und Regressionstest
• 3.4 Last- und Performancetests
• 3.5 Organisation
• 4. Rollen
• 5. Testumgebungen
• 5.1 Entwicklungsumgebung
• 5.2 Systemtestumgebung
• 5.3 Pre-Productionumgebebung
• 5.4 Produktionsumgebung

7
Muster eines Testplanes (3)

• 6 Verantwortungen und Akzeptanzkriterien
• 6.1 Modultest
• 6.2 Integrationstest auf Komponentenebene
• 6.3 Annahmeprüfung
• 6.4 Systemtest
• 6.5 Abnahme
• 7 Dokumentation
• 7.1 Testberichte
• 7.2 Fehlerverwaltung

8
Rollen im Test
Rolle Aufgaben Personen Personen
Testleiter Koordinierung Testaktivitäten Zuständigkeit für Ressourcen Erstellung Managementreports abschließende Bewertung der Ergebnisse Koordinierung Testaktivitäten Zuständigkeit für Ressourcen Erstellung Managementreports abschließende Bewertung der Ergebnisse HXS
Testdesigner Identifikation, Implementierung der Testfälle Erstellung des Testplanes Beurteilung der Effizienz des Testaufwandes Identifikation, Implementierung der Testfälle Erstellung des Testplanes Beurteilung der Effizienz des Testaufwandes EKM, RSC
Tester Durchführung der Tests Protokollierung u. Bewertung der Ergebnisse Durchführung der Tests Protokollierung u. Bewertung der Ergebnisse MAF, EMM, RSC
Testautomatisierer Erstellung von Testskripten Umsetzung der GUI-Map Erstellung von Testskripten Umsetzung der GUI-Map HXS, MAF
Testsystem-administrator Installation und Verwaltung des Testsystems Datenbankadministration und management Installation und Verwaltung des Testsystems Datenbankadministration und management EKM
9
Testaufwand

• Das Testen erfordert Ressourcen, muss also im
  Projekt eingeplant werden!
• Testen, Integration und Dokumentation sind oft
  die letzten Phasen der Entwicklung.
• Testphase als Dispositionsmasse für eine falsche
  Planung
• ,,Wann ist endlich das Programm x fertig?
• ,,Gleich, ich muss nur noch Testen!
• ,,Gleich, ich muss nur noch einen Fehler
  bereinigen!
• ,,Gleich, ich muss nur noch dokumentieren!
• Testplanung wie Projektplanung

10
(No Transcript)
11
Abschlusskriterien

• Wenn Ressourcen oder Zeit erschöpft?
• (am häufigsten verwendetes Abbruchkriterium)
• Wenn keine Fehler mehr gefunden werden?
• (vielleicht wurde nicht gründlich gesucht?)
• Besser Wenn vorher festgelegte Qualitätsziele
  erreicht sind!
• festgelegter Überdeckungsgrad erreicht
• Restfehlerabschätzung zufriedenstellend
• Systemabnahme erfolgreich überstanden

12
Testdurchführung

• Viele Werkzeuge zur Unterstützung und zum
  Management der Testdurchführung
• Integriert in Software-Entwicklungsumgebungen,
  Planungssoftware, Requirements-Analyse,
  Verwaltung von Defekten, Evaluation des
  Projektfortschritts usw.
• Aufgaben
• Erzeugung und Verwaltung des Testplanes
• Vernetzung mit Requirements und Modulen
• Erstellung von Testreports und metrischen
  Evaluationen
• Import und Export von externen Schnittstellen
• Beispiele Mercury Test Director, QACenter,
  Rational Test Manager, dSPACE AutomationDesk

13
(No Transcript)
14
Lebenszyklus von Fehlern

• Damit ein Test sinnvoll ist, müssen die
  Ergebnisse zu Konsequenzen führen
• Verwaltung von Findings, werkzeugunterstützt
• Lebenszyklus von Fehlern werkzeugabhängig
• bekanntestes Werkzeug Bugzilla (Mozilla Project)

15
(No Transcript)
16
(No Transcript)
17
Pause!
18
VV Peer Review

• Informelle QS-Methode
• sehr populär, sehr effektiv
• oft obligatorisch, vollständig!
• Ergänzung formaler Methoden
• Abgleich mit den ursprünglichen Zielen
• Aufzeigen von inhaltlichen (nichtformalen)
  Fehlern
• z.B. intuitive Bedeutung versus textuelle Gestalt
  eines Identifiers
• Verbesserung von Lesbarkeit und Verständlichkeit
• Durchführungsmöglichkeiten
• Code Walkthrough
• (Fagan) Inspektion

19
Ziele eines Peer Reviews

• Entdeckung von Design- und Analysefehlern in den
  zu untersuchenden Dokumenten
• Aufzeigen von Risiken, die den Projektfortschritt
  beeinträchtigen könnten
• Lokalisierung von Abweichungen gegenüber externen
  und internen Vorgaben und Richtlinien
• Bewertung bzw. Verbesserung der Qualität der
  Artefakte
• Kommunikationsmöglichkeit für die Beteiligten
• Datenbasis von Befunden für künftige Projekte

20
Artefakte für das Review

• Jedes Artefakt, welches als Ergebnis eines
  Entwicklungszyklusses vorliegt, kann per Review
  bewertet werden
• Anforderungsbeschreibung, Vermarktungsplan
• Entwicklungsplan, Ressourcenverteilung
• Entwurfsdokumente (Grob/Feinarchitektur)
• Algorithmen und Datenstrukturen, Code
• Testpläne, Testergebnisse
• Manuale, Handbücher,
• Versions- und Releasedokumente
• Wichtig es muss eine stabile Version des
  Artefakts vorliegen

21
Durchführung

• Planung, Einführung in die Thematik, Vorbereitung
• Präsentation des Dokuments
• Kommentare des Review-Teams
• Diskussion der einzelnen Kritikpunkte
• Ergebnis
• Audit Beratung mit Entscheidung über
  Fortführung, bedingte Fortführung oder Ablehnung
  (mit Begründung)
• Peer Review Eintrag der gefundenen Issues in
  Defektverfolgungssystem, Protokoll der Sitzung
  für künftige Projekte

22
Walkthrough und Inspektion

• Walkthrough geführtes Vorlesen vor aufmerksamem
  Publikum
• detaillierte Erklärung durch den Autor
• keine bzw. minimale Vorbereitung der Reviewer
• gemeinsames Verständnis als Hauptziel
• Inspektion Frage- und Antwortstunde
• Vorbereitung von Fragen durch Reviewer
  (31)(anhand Checklisten)
• Beantwortung durch Autor so weit möglich
• auch möglich Autor bekommt Fragen vorher
• unabhängige Moderation!