27.1.2006 software-engineering ii eingebettete systeme, softwarequalität, projektmanagement prof....

27.1.2006

Software-Engineering IIEingebettete Systeme, Softwarequalität, Projektmanagement

Prof. Dr. Holger SchlingloffInstitut für Informatik der Humboldt Universität

und

Fraunhofer Institut für Rechnerarchitektur und Softwaretechnik

http://www.hu-berlin.de/index.html

Folie 2H. Schlingloff, Software-Engineering II 27.1.2006


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


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


Muster eines Testplanes (1)

1. Einführung1.1 Zielsetzung1.2 Geltungsbereich1.3 Definitionen und Abkürzungen1.4 Referenzen1.5 Übersicht2. Teststrategie2.1 Testtypen2.1.1 Benutzbarkeitstest2.1.2 Modultest2.1.3 Integrationstest auf Komponentenebene2.1.4 Annahmeprüfung2.1.5 Systemtest2.1.6 Abnahme2.2 Test der einzelnen Releases



3. Testtools3.1 Testumgebung3.2 Testmanagement und Fehlerverfolgung3.3 Funktions- und Regressionstest3.4 Last- und Performancetests3.5 Organisation4. Rollen5. Testumgebungen5.1 Entwicklungsumgebung5.2 Systemtestumgebung5.3 Pre-Productionumgebebung5.4 Produktionsumgebung



6 Verantwortungen und Akzeptanzkriterien6.1 Modultest6.2 Integrationstest auf Komponentenebene6.3 Annahmeprüfung6.4 Systemtest6.5 Abnahme7 Dokumentation7.1 Testberichte7.2 Fehlerverwaltung


Rollen im Test

Rolle Aufgaben Personen

Testleiter Koordinierung TestaktivitätenZuständigkeit für RessourcenErstellung Managementreportsabschließende Bewertung der Ergebnisse

HXS

Testdesigner Identifikation, Implementierung der Testfälle Erstellung des TestplanesBeurteilung der Effizienz des Testaufwandes

EKM, RSC

Tester Durchführung der TestsProtokollierung u. Bewertung der Ergebnisse

MAF, EMM, RSC

Testautomatisierer Erstellung von TestskriptenUmsetzung der GUI-Map

HXS, MAF

Testsystem-administrator

Installation und Verwaltung des TestsystemsDatenbankadministration und –management

EKM


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


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


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


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)


Pause!


V&V: 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


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


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


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


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 (3:1)

(anhand Checklisten) Beantwortung durch Autor so weit möglich auch möglich: Autor bekommt Fragen vorher

• unabhängige Moderation!

27.1.2006 software-engineering ii eingebettete systeme, softwarequalität, projektmanagement prof....

Documents