27.1.2006 Software-Engineering II Eingebettete Systeme, Softwarequalität, Projektmanagement Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt.

Präsentation zum Thema: "27.1.2006 Software-Engineering II Eingebettete Systeme, Softwarequalität, Projektmanagement Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt."—  Präsentation transkript:

1 27.1.2006 Software-Engineering II Eingebettete 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 Folie 2 H. Schlingloff, Software-Engineering II 27.1.2006

3 Folie 3 H. 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

4 Folie 4 H. Schlingloff, Software-Engineering II 27.1.2006 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 Folie 5 H. Schlingloff, Software-Engineering II 27.1.2006 Muster eines Testplanes (1) 1.Einführung 1.1Zielsetzung 1.2Geltungsbereich 1.3Definitionen und Abkürzungen 1.4Referenzen 1.5Übersicht 2.Teststrategie 2.1Testtypen 2.1.1Benutzbarkeitstest 2.1.2Modultest 2.1.3Integrationstest auf Komponentenebene 2.1.4Annahmeprüfung 2.1.5Systemtest 2.1.6Abnahme 2.2Test der einzelnen Releases

6 Folie 6 H. Schlingloff, Software-Engineering II 27.1.2006 Muster eines Testplanes (2) 3.Testtools 3.1Testumgebung 3.2Testmanagement und Fehlerverfolgung 3.3Funktions- und Regressionstest 3.4Last- und Performancetests 3.5Organisation 4.Rollen 5.Testumgebungen 5.1Entwicklungsumgebung 5.2Systemtestumgebung 5.3Pre-Productionumgebebung 5.4Produktionsumgebung

7 Folie 7 H. Schlingloff, Software-Engineering II 27.1.2006 Muster eines Testplanes (3) 6Verantwortungen und Akzeptanzkriterien 6.1Modultest 6.2Integrationstest auf Komponentenebene 6.3Annahmeprüfung 6.4Systemtest 6.5Abnahme 7Dokumentation 7.1Testberichte 7.2Fehlerverwaltung

8 Folie 8 H. Schlingloff, Software-Engineering II 27.1.2006 Rollen im Test RolleAufgabenPersonen TestleiterKoordinierung Testaktivitäten Zuständigkeit für Ressourcen Erstellung Managementreports abschließende Bewertung der Ergebnisse HXS TestdesignerIdentifikation, Implementierung der Testfälle Erstellung des Testplanes Beurteilung der Effizienz des Testaufwandes EKM, RSC TesterDurchführung der Tests Protokollierung u. Bewertung der Ergebnisse MAF, EMM, RSC TestautomatisiererErstellung von Testskripten Umsetzung der GUI-Map HXS, MAF Testsystem- administrator Installation und Verwaltung des Testsystems Datenbankadministration und –management EKM

9 Folie 9 H. Schlingloff, Software-Engineering II 27.1.2006 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 Folie 10 H. Schlingloff, Software-Engineering II 27.1.2006

11 Folie 11 H. Schlingloff, Software-Engineering II 27.1.2006 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 Folie 12 H. Schlingloff, Software-Engineering II 27.1.2006 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 Folie 13 H. Schlingloff, Software-Engineering II 27.1.2006

14 Folie 14 H. Schlingloff, Software-Engineering II 27.1.2006 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 Folie 15 H. Schlingloff, Software-Engineering II 27.1.2006

16 Folie 16 H. Schlingloff, Software-Engineering II 27.1.2006

17 Folie 17 H. Schlingloff, Software-Engineering II 27.1.2006 Pause!

18 Folie 18 H. Schlingloff, Software-Engineering II 27.1.2006 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

19 Folie 19 H. Schlingloff, Software-Engineering II 27.1.2006 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 Folie 20 H. Schlingloff, Software-Engineering II 27.1.2006 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 Folie 21 H. Schlingloff, Software-Engineering II 27.1.2006 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 Folie 22 H. Schlingloff, Software-Engineering II 27.1.2006 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!