Qualitätsmanagement. Software Engineering 1 WS 2010/2011. Dr. Ina Schaefer Software Systems Engineering Technische Universität Braunschweig
|
|
- Roland Sommer
- vor 8 Jahren
- Abrufe
Transkript
1 Qualitätsmanagement Software Engineering 1 WS 2010/2011 Dr. Ina Schaefer Software Systems Engineering Technische Universität Braunschweig (Folien von Prof. B. Rumpe und Dr. A. Herrmann)
2 Was ist Qualität? Qualität: Gesamtheit von Eigenschaften und Merkmalen eines Produkts oder einer Tätigkeit, die sich auf deren Eignung zur Erfüllung gegebener Erfordernisse bezieht [DIN 55350, Teil 11] Achtung: bezieht sich auf Produkt und Prozess. Achtung: Qualitäts-Anforderungen ändern sich mit der Zeit! Achtung: Qualität muss gegenüber Kosten und Zeit abgewogen werden Dr. Ina Schaefer Software Engineering 1 Seite 2
3 Qualität nach ISO9216 Funktionalität Angemessenheit Sicherheit Genauigkeit der Berechnung Interoperabilität Konformanz zu Standards Zuverlässigkeit Reife Fehlertoleranz Wiederherstellbarkeit Benutzbarkeit Verständlichkeit Erlernbarkeit Bedienbarkeit Effizienz Zeitverhalten Verbrauchsverhalten Änderbarkeit Analysierbarkeit Modifizierbarkeit Stabilität Prüfbarkeit Übertragbarkeit Anpassbarkeit Installierbarkeit Konformanz zu Standards Austauschbarkeit Dr. Ina Schaefer Software Engineering 1 Seite 3
4 Verifikation & Validierung Benutzererwartungen Anforderungsdokument... Code Verifikation: haben wir es richtig gemacht? Validierung: haben wir das Richtige gemacht? Dr. Ina Schaefer Software Engineering 1 Seite 4
5 Übersicht Konstruktive Qualitätssicherung Qualität von Prozessen Reifegradmodelle Analytische Qualitätssicherung Statische Tests (Reviews) Dynamische Tests Begriffe und Grundsätze Testprozess Testmethoden Testarten (Unit-, Integrations-, System-, Akzeptanztest) Dr. Ina Schaefer Software Engineering 1 Seite 5
6 Produktqualität und Prozessqualität Software: Kaum Qualitätsmängel durch Massenproduktion Qualitätsmängel im Herstellungsprozess begründet Qualitätsmanagement: Organisatorische Maßnahmen zur Prüfung und Verbesserung der Prozessqualität Beachtung von internen Kunden-/Lieferantenbeziehungen Konstruktive Qualitätssicherung: Qualität des Prozesses Analytische Qualitätssicherung: Qualität des Produkts Dr. Ina Schaefer Software Engineering 1 Seite 6
7 ISO 9000 Internationales Normenwerk ISO 9000: Allgemeiner Leitfaden ISO : Leitfaden zur Anwendung von ISO 9001 auf Software ISO 9001: Modelle zur Darlegung der Qualitätssicherung insbesondere in Entwurf und Entwicklung Allgemeingültige Forderungen an die Organisation eines Unternehmens: Regelung von Zuständigkeiten Erstellung und korrekte Verwaltung wesentlicher Dokumente Existenz eines unabhängigen Qualitätssicherungs-Systems Zertifizierung: durch unabhängige (zertifizierte) Prüforganisationen Audit, Prüfsiegel ISO 9000 prüft nicht die Qualität des Produkts, sondern die Qualität der Organisation! Dr. Ina Schaefer Software Engineering 1 Seite 7
8 Reifegradmodelle: Ziele und Nutzen messen Reife des gesamten Software-Entwicklungsprozesses entdecken Schwachstellen und Verbesserungspotenzial schlagen Maßnahmen zur Qualitätsverbesserung vor messen die Wirkung dieser Maßnahmen helfen bei Bewertung von Lieferanten bei Auftragsvergabe Dr. Ina Schaefer Software Engineering 1 Seite 8
9 Reifegradmodelle: Beispiele CMM CMMI (Weiterentwicklung von CMM, quasi V2.0) BOOTSTRAP (Erweiterung und Anpassung von CMM für Europa) SPICE/ ISO (Weiterentwicklung von Bootstrap) DIN ISO 9000 TQM = Total Quality Management Dr. Ina Schaefer Software Engineering 1 Seite 9
10 Capability Maturity Model (CMM) Entwickelt 1987 von Software Engineering Institute (SEI), Vorläufer Mutter vieler späterer Modelle 1991 CMM Version 1.0, 1993 CMM V CMMI = Capability Maturity Model Integrated, löst CMM ab Fragebögen mit ja/nein-fragen 5 Reifegrad-Stufen Um Stufe x+1 zu erreichen, müssen alle Bedingungen von Stufe x erfüllt sein. Dr. Ina Schaefer Software Engineering 1 Seite 10
11 Capability Maturity Model (CMM) Stufe 4: Gesteuert Stufe 5: Optimierend Kontrolle über Produktqualität Kontrolle über Prozessqualität Stufe 3: Definiert Kosten und Termine zuverlässig, aber Qualität schwankend Stufe 2: Wiederholbar Stufe 1: Stufe1: Initialer Prozess Initial Terminkontrolle, aber Kosten und Qualität schwanken Kosten, Zeit, Qualität unvorhersehbar Dr. Ina Schaefer Software Engineering 1 Seite 11
12 5 Stufen in CMMI 1. Ad hoc (Initial) Keine formelle Planung und Kontrolle Kein oder schlechtes Konfigurationsmanagement 2. Wiederholbar (Repeatable) Etabliertes Projektmanagement Abwicklung von Standardprojekten wird beherrscht. bei neuartigen Projekten größere Risiken Prozess ist abhängig von den Personen, die ihn durchführen. Keine etablierten Maßnahmen zur Verbesserung des Prozesses 3. Definiert (Defined) Der Prozess ist klar definiert und läuft definitionsgemäß ab. Es existiert eine Gruppe mit der Aufgabe, den Software Engineering Prozess zu lenken und zu verbessern. Dr. Ina Schaefer Software Engineering 1 Seite 12
13 5 Stufen in CMMI (2) 4. Geführt (Managed) Eine Mindestmenge an Qualitäts- und Produktivitätsmessgrößen wird erhoben und ausgewertet. Es gibt eine Datenbank, in der alle relevanten Daten über den Prozess abgelegt werden und Mittel zur Pflege und Auswertung dieser Daten. 5. Optimierend (Optimizing) Etablierter Regelkreis für Messung und Verbesserung des Prozesses Datenerhebung und Erkennung von Schwachstellen weitgehend automatisiert. Durchgeführte Maßnahmen aus dem erhobenen Datenmaterial begründet. Etablierte Ursachenanalyse für alle Fehler und zugehörige Fehlerpräventionsmaßnahmen. Dr. Ina Schaefer Software Engineering 1 Seite 13
14 Analytische Qualitätssicherung Ziel: Überprüfen, ob Produkt die Aufgabenspezifikation erfüllt Prüfmethoden: Beweis (mathematischer Nachweis, nur bei einfachen Programmen händisch möglich, ansonsten komplexe Beweis- Werkzeuge) Test (Ausprobieren für eine sorgfältig ausgewählte Menge von Eingaben) Inspektion (systematisches Durchlesen) Metriken (automatische Bestimmung von Charakteristika) Dr. Ina Schaefer Software Engineering 1 Seite 14
15 Statische und Dynamische Tests Statische Tests: Überprüfung nicht-ausführbarer Entwicklungsartefakte (Dokumente) durch Inspektionen und Reviews Dynamische Tests: Überprüfung ausführbarer Artefakte (Prototypen, Programmcode) durch Testdaten Dr. Ina Schaefer Software Engineering 1 Seite 15
16 Test-Arten im V-Modell Reviews, Prototyp der Oberfläche Reviews, Konsistenzprüfungen, Machbarkeitsstudien Code-Reviews, Test-Planung Dr. Ina Schaefer Software Engineering 1 Seite 16
17 Qualitätssicherung für Analyse und Entwurf Hohe Bedeutung früher Phasen für Produktqualität! Deshalb: Alle Dokumente frühzeitig überprüfen ("Validation"). Techniken: Anforderungskatalog-Begutachtung Echte Benutzer einbeziehen Anforderungskatalog auf Vollständigkeit und Korrektheit prüfen Use-Case-Szenarien Echte Benutzer einbeziehen "Funktionsfähigkeit" der abstrakten Modelle demonstrieren Prototyping Prototyp auf der Basis der Analyse/Entwurfs-Dokumente Echte Benutzer einbeziehen Vorgezogener Akzeptanztest Abgleich des Entwurfs mit Use-Cases/Anforderungskatalog Erste verifizierende Tätigkeiten Dr. Ina Schaefer Software Engineering 1 Seite 17
18 Begutachtung (Review) Produkt wird von Expertengremium begutachtet Anwendbar auf fast alle Phasen der Entwicklung Was wird begutachtet? Genau definiertes Dokument (Art, Status, Prozesseinbindung) Teil der Gesamtplanung des Projekts (Termin) Wer begutachtet? Teammitglieder (Peer-Review) Externe Spezialisten Echte Benutzer Moderator, Manager Wie läuft die Begutachtung ab? Einladung Vorbereitung, Sammlung von Kommentaren Begutachtungssitzung(en), Protokolle Auswertung und Konsequenzen (Wiederholung, Statusänderung) Dr. Ina Schaefer Software Engineering 1 Seite 18
19 Regeln für wirkungsvolle Begutachtung "Checklisten" für die Gutachter vorbereiten z.b. "Enthält das Dokument alle laut Firmenstandard vorgesehenen Informationen?" - "Gibt es für jede Klasse eine informelle Beschreibung?" - "Sind Kardinalitäten im Klassendiagramm vollständig und korrekt?" - "Sind alle Klassen kohärent?" -... Das Dokument wird begutachtet, nicht die Autoren! Richtige Vorkenntnisse der Gutachter sind wesentlich. Die Rolle des Moderators ist anspruchsvoll: Vermittlung in persönlichen Konflikten und Gruppenkonflikten Fachlicher Gesamtüberblick Das Ziel ist Einigkeit, nicht ein Abstimmungsergebnis! Ergebnisse von Begutachtungen müssen Auswirkungen haben. Wesentliche Beiträge von Gutachtern müssen Anerkennung finden. Begutachtung ist auch anwendbar auf Programm-Code (Code-Inspektion). Dr. Ina Schaefer Software Engineering 1 Seite 19
20 Dynamisches Testen: Begriffe Testgegenstand (Testling, Prüfling): Programm bzw. Komponente, die zu testen ist Testfall: Satz von Eingabedaten, der die (vollständige) Ausführung des Testgegenstands bewirkt Testdaten: Daten, die für den Testfall benötigt werden Testtreiber: Rahmenprogramm für Ausführung von Tests Attrappe (Stub, Dummy): Ersatz für ein (noch) nicht vorhandenes Unterprogramm Regressionstest: Nachweis, dass eine geänderte Version des Testgegenstands früher durchgeführte Tests erneut besteht Alphatest: Test experimenteller Vorversion durch Benutzer Betatest: Test funktional vollständiger Software durch Benutzer Dr. Ina Schaefer Software Engineering 1 Seite 20
21 Fehlfunktionen Fehlfunktion (fault): Unerwartete Reaktion des Testlings Unterscheidung zwischen dem fehlerhaften Code (error, bug) und dem Auftreten des Fehler (fault): Ein fault kann aufgrund mehrerer bugs auftreten. Ein bug kann mehrere faults hervorrufen. Arten von Fehlfunktionen: Falsches oder fehlendes Ergebnis Nichtterminierung Unerwartete oder falsche Fehlermeldung Inkonsistenter Speicherzustand Unnötige Ressourcenbelastung (z.b. von Speicher) Unerwartetes Auslösen einer Ausnahme, "Abstürze" Falsches Abfangen einer Ausnahme Dr. Ina Schaefer Software Engineering 1 Seite 21
22 Grundsätze des Testens Nach: ISTQB Syllabus Certified Tester Foundation Level Grundsatz 1 Vollständiges Testen - Austesten - ist nicht möglich. Grundsatz 2 Mit Testen wird die Anwesenheit von Fehlerwirkungen nachgewiesen. Dass keine Fehlerzustände im Testobjekt vorhanden sind, kann durch Testen nicht gezeigt werden. Program testing can be used to show the presence of bugs, but never to show their absence! Edsger Dijkstra Dr. Ina Schaefer Software Engineering 1 Seite 22
23 Grundsätze des Testens (2) Grundsatz 3 Testen ist keine späte Phase in der Softwareentwicklung, es soll damit so früh wie möglich begonnen werden. Durch frühzeitiges Prüfen (z.b. Reviews) werden früher Fehler(zustände) erkannt und somit Kosten gesenkt. Grundsatz 4 Fehlerzustände sind in einem Testobjekt nicht gleichmäßig verteilt, vielmehr treten sie gehäuft auf. Dort wo viele Fehlerwirkungen nachgewiesen wurden, finden sich vermutlich auch noch weitere. Dr. Ina Schaefer Software Engineering 1 Seite 23
24 Grundsätze des Testens Grundsatz 5 Tests nur zu wiederholen, bringt keine neuen Erkenntnisse. Testfälle sind zu prüfen, zu aktualisieren und zu modifizieren. Grundsatz 6 Testen ist abhängig vom Umfeld. Sicherheitskritische Systeme sind intensiver zu testen als beispielsweise der Internetauftritt einer Einrichtung. Grundsatz 7 Ein System ohne Fehlerwirkungen bedeutet nicht, dass das System auch den Vorstellungen der späteren Nutzer entspricht. Dr. Ina Schaefer Software Engineering 1 Seite 24
25 Pareto-Prinzip % der Fehlfunktionen % der betroffenen Module Fenton/Ohlsson 2000 und andere empirische Untersuchungen: 20 % der Module sind verantwortlich für 60 % der Fehler Diese 20 % der Module entsprechen 30 % des Codes Testmuster: "Scratch'n sniff" Fehlerhafte Stellen deuten oft auf weitere Fehler in der Nähe hin. Dr. Ina Schaefer Software Engineering 1 Seite 25
26 Testplanung und Testkonzept Testen ist aufwändig, deshalb ist gute Planung nötig! Testplanung sollte bereits mit der Anforderungsanalyse beginnen und im Entwurf verfeinert werden (V-Modell, Test-First-Ansatz)! Typische Bestandteile eines Testkonzepts: Phasenmodell des Testprozesses Zusammenhang zur Anforderungsspezifikation z.b. dort festgelegte Qualitätsziele Zu testende Produkte Zeitplan für die Tests Abhängigkeiten der Testphasen Aufzeichnung der Testergebnisse Hardware- und Softwareanforderungen Einschränkungen und Probleme Dr. Ina Schaefer Software Engineering 1 Seite 26
27 Testprozess Testspezifikation: Testfälle, Priorisierung, Testdaten und Soll- Ergebnisse Testplanung: Ressourcen, Aufwand, Termine Testdurchführung: sowie Testprotokollierung und Meldung des Fehlers an den Entwickler (Fehlerverwaltung) Testmanagement: Prüfen der Testberichte und Entscheidung über Testende Dr. Ina Schaefer Software Engineering 1 Seite 27
28 Details der Teststrategie Pro Dokument und Entwicklungsergebnis Festlegung der Testmethode Festlegung des Abdeckungsgrades Priorisierung der einzelnen Tests Eintrittswahrscheinlichkeit eines Fehlers (z.b. häufig vom Kunden genutztes Prüfobjekt, intern kritisches Prüfobjekt, komplexes Prüfobjekt) Fehlerschwere Für Kunden: Schaden beim Auftreten bzw. Zufriedenheit Für Hersteller: Größe des Behebungsaufwandes Priorität der Anforderungen Dr. Ina Schaefer Software Engineering 1 Seite 28
29 Testfälle Logischer Testfall: abstrakte Beschreibung eines Testfalls Konkreter Testfall: Konkretisierung eines logischen Testfalls durch Testdaten Testlauf: Protokoll einer Durchführung eines konkreten Testfalls Logischer Testfall 1 1..n konkreter 1 1..n Testfall Testlauf Dr. Ina Schaefer Software Engineering 1 Seite 29
30 Testfallspezifikation Inhalt einer Test case specification : Test case specification identifier Test items Input specifications Output specifications Environmental needs (hardware, software, others) Special procedural requirements Intercase dependencies (nach IEEE Standard for Software Test Documentation ) Dr. Ina Schaefer Software Engineering 1 Seite 30
31 Testberichte/ Testendekriterium Testberichte: Welche Tests wurden mit welchem Ergebnis durchgeführt? Testabdeckung = Anzahl der durchgeführten Tests / Anzahl der durchzuführenden Tests Anzahl der noch offenen Fehler Priorisierung von Testfällen und Fehlern Testendekriterium: Wann wird die QS beendet? Alle Testfälle durchgeführt? Alle Fehler behoben? Alle schweren Fehler behoben? Nimmt Fehlerfindungsrate ab? Termin erreicht?/ Budget verbraucht? Dr. Ina Schaefer Software Engineering 1 Seite 31
32 Fehlerverwaltung Informationen pro Fehler: Testfall, Testdurchführung, Eingabedaten und Ergebnis Zuständiger Tester Zuständiger Entwickler (für Fehlerbehebung) Status Offen (von Tester entdeckt, Entwickler zuständig) in Bearbeitung (durch Entwickler) Behoben (durch Entwickler, Tester wieder zuständig) Erledigt (=Bestätigung durch Tester) Schwere. z.b.: schwer = Arbeit unmöglich + kein Workaround vorhanden mittel = Arbeit erschwert + Workaround vorhanden leicht = stört nicht beim Arbeiten) Dr. Ina Schaefer Software Engineering 1 Seite 32
33 Testarten Baustein- Test Modul- Test Integration Bausteintest (unit test): Traditionell: Prozeduren OO: Methoden Modultest: Traditionell: Module OO: Klassen Integrations- Test System- Test Akzeptanz- Test Integrationstest: OO: Pakete Dr. Ina Schaefer Software Engineering 1 Seite 33
34 Testmethoden Funktionaler Test (black box test):testfallauswahl beruht auf Spezifikation) Äquivalenzklassentest, Grenzwerte, Test spezieller Werte Zustandstest auf Spezifikationsbasis Strukturtest (white box test, glass box test):testfallauswahl beruht auf Programmstruktur Kontrollflussorientierter Test Anweisungsüberdeckung, Zweigüberdeckung, Pfadüberdeckung Datenflussorientierter Test: Definition/Verwendung von Variablen Weitere Testmethoden (Beispiele) Zufallstest ("monkey test") Stress-, Lasttest Dr. Ina Schaefer Software Engineering 1 Seite 34
35 Funktionaler Test (black box) Funktionale Spezifikation Erwartete Ausgabedaten Vergleich Testfälle (Eingabedaten) Programmausführung Ausgabedaten Dr. Ina Schaefer Software Engineering 1 Seite 35
36 Äquivalenzklassentest Äquivalenzklasse: Teilmenge der möglichen Datenwerte der Eingabeparameter Annahme: Programm reagiert für alle Werte aus der Äquivalenzklasse prinzipiell gleich Test je eines Repräsentanten jeder Äquivalenzklasse Finden von Äquivalenzklassen: Kriterien für Werte entwickeln und diese wo sinnvoll kombinieren Zulässige und unzulässige Teilbereiche der Datenwerte Unterteilung der zulässigen Bereiche nach verschiedenen Ausgabewerten Dr. Ina Schaefer Software Engineering 1 Seite 36
37 Äquivalenzklassentest: Beispiel int search (int[] a, int k) Vorbedingung: a.length >= 0 Nachbedingung: (result 0 a[result] == k) (result == 1 ( i. 0 i < a.length a[i] == k)) Kriterien für Äquivalenzklassen: Kriterium 1A: a.length == 0 Kriterium 1B: a.length > 0 Kriterium 2A: k in a Kriterium 2B: k nicht in a Äquivalenzklassen / Testfälle: drei Äq.-Klassen, da 1A und 2A nicht kompatibel a == [], k == 17, result == undef. (1A, 2B) a == [11, 17, 45], k == 17, result == 1 (1B, 2A) a == [11, 23, 45], k == 17, result == -1 (1B, 2B) Dr. Ina Schaefer Software Engineering 1 Seite 37
38 Grenzwertanalyse und Test spezieller Werte Grenzwerte: Randfälle der Spezifikation Werte, bei denen "gerade noch" ein gleichartiges Ergebnis zum Nachbarwert erzielt wird, bzw. "gerade schon" ein andersartiges Beispiele: Ränder von Zahl-Intervallen Schwellenwerte Spezielle Werte: Zahlenwert 0 Leere Felder, Sequenzen und Zeichenreihen Einelementige Felder, Sequenzen und Zeichenreihen Null-Referenzen Sonderzeichen (Steuerzeichen, Tabulator) Dr. Ina Schaefer Software Engineering 1 Seite 38
39 Grenzwertanalyse: Beispiel int search (int[] a, int k) Vorbedingung: a.length > 0 Nachbedingung: (result 0 a[result] == k) (result == 1 ( i. 0 i < a.length a[i] == k)) Weitere Kriterien für Äquivalenzklassen: 3A: Element am linken Rand a[0]==k 3B: Element am rechten Rand a.last==k 3C: Element an keinem Rand... 4A: a einelementig a.length==1 4B: a nicht einelementig a.length!=1 5A: k ist 0 k==0 5B: k ist nicht 0 k!=0 Neue Testfälle: a == [17], k == 17, result == 0 (Kriterien 1B, 2B, 3A+B, 4A, 5B) a == [11, 23, 0], k == 0, result == 2 (Kriterien 1B, 2B, 3B, 4B, 5A) Dr. Ina Schaefer Software Engineering 1 Seite 39
40 Strukturtest (glass-box) Programm- Code Testfälle (Eingabedaten) Programmausführung Ausgabedaten Vergleich Funktionale Spezifikation oder "Orakel" Erwartete Ausgabedaten Dr. Ina Schaefer Software Engineering 1 Seite 40
41 Überdeckungsgrad (coverage) Maß für die Vollständigkeit eines Tests Welcher Anteil des Programmtexts wurde ausgetestet? Messung der Überdeckung: Instrumentierung des Programmcodes Ausgabe statistischer Informationen Planung der Überdeckung: gezielte Anlage der Tests auf volle Überdeckung Überdeckungsarten: Anweisungsüberdeckung: Anteil ausgeführter Anweisungen Zweigüberdeckung: Anteil ausgeführter Anweisungen und Verzweigungen Pfadüberdeckung: Anteil ausgeführter Programmablaufpfade Hilfsmittel: Kontrollflussgraph Dr. Ina Schaefer Software Engineering 1 Seite 41
42 Beispielprogramm: Binäre Suche public static final int NOTFOUND = -1; // Binaere Suche auf Array a. // Annahme: a ist sortiert // Ergebnis ist NOTFOUND, wenn k nicht in A enthalten ist. // Ergebnis ist i falls a[i] gleich k ist. public static int binsearch (int[] a, int k) { int ug = 0, og = a.length-1, m, pos = NOTFOUND; while (ug <= og && pos == NOTFOUND) { m = (ug + og) / 2; if (a[m] == k) pos = m; else if (a[m] < k) ug = m + 1; else og = m - 1; }; return pos; } Dr. Ina Schaefer Software Engineering 1 Seite 42
43 Binäre Suche - Kontrollflussgraph public static final int NOTFOUND = -1; 1 public static int binsearch (int[] a, int k) { int ug = 0, og = a.length-1, m, pos = NOTFOUND; // 1 while (ug <= og && pos == NOTFOUND) { // 2 m = (ug + og) / 2; // 3 if (a[m] == k) // pos = m; // 5 else if (a[m] < k) // 6 ug = m + 1; // 7 else og = m - 1; // 8 }; return pos; // 9 } Dr. Ina Schaefer Software Engineering 1 Seite 43 9
44 Anweisungsüberdeckender Test Überdeckung aller Anweisungen: C 0 -Test Jede Anweisung (numerierte Zeile) des Programms wird mindestens einmal ausgeführt. Beispiel: a = {11, 22, 33, 44, 55}, k = 33 überdeckt Anweisungen: 1, 2, 3, 4, 5, 9 a = {11, 22, 33, 44, 55}, k = 15 überdeckt Anweisungen: 1, 2, 3, 4, 6, 7, 8, 9 Beide Testfälle zusammen erreichen volle Anweisungsüberdeckung. Messen der Anweisungsüberdeckung: "Instrumentieren" des Codes (durch Werkzeuge) Einfügen von Zählanweisungen bei jeder Anweisung Dr. Ina Schaefer Software Engineering 1 Seite 44
45 Zweigüberdeckender Test Überdeckung aller Zweige: C 1 -Test Bei jeder Fallunterscheidung (einschließlich Schleifen) werden beide Zweige ausgeführt (Bedingung=true und Bedingung=false). Zweigtest zwingt auch zur Untersuchung "leerer" Alternativen: if (x >= 1) Beispiel: y = true; // kein else-fall Die beiden Testfälle der letzten Folie überdecken alle Zweige. Messung/Instrumentierung von Anweisung i: Fallunterscheidung: if (...) { bt[i]++;... } else { bf[i]++;... } While-Schleife: while (...) { bt[i]++;... } bf[i]++; Dr. Ina Schaefer Software Engineering 1 Seite 45
46 Pfadüberdeckung Pfad = Sequenz von Knoten im Kontrollflussgraphen, so dass in der Sequenz aufeinanderfolgende Knoten im Graphen direkt miteinander verbunden sind. Anfang = Startknoten, Ende = Endknoten. Theoretisch optimales Testverfahren Explosion der Zahl von möglichen Pfaden, deshalb nicht praxisrelevant. (Schleifen haben unendliche Pfad-Anzahlen) Praktikablere Varianten, z.b. bounded-interior-pfadtest: Alle Schleifenrümpfe höchstens n-mal (z.b. einmal) wiederholen Dr. Ina Schaefer Software Engineering 1 Seite 46
47 Testen objektorientierter Programme Klassische Verfahren anwendbar für einzelne Methoden aber: Methoden vergleichsweise kurz und einfach Komplexität liegt zum großen Teil in der Kooperation. Probleme mit Vererbung: Tests der Oberklassen müssen u.u. für alle Unterklassen wiederholt werden: Beeinflussung von Variablen der Oberklasse Redefinition von Methoden der Oberklasse Dr. Ina Schaefer Software Engineering 1 Seite 47
48 Klassentest Festlegung einer Testreihenfolge für einzelne Methoden Konstruktoren Get-Methoden Boolsche Methoden (is ) Set-Methoden Iteratoren Komplexe Berechnung oder Ablaufsteuerung in einer Klasse Sonstige Methoden Destruktoren Dr. Ina Schaefer Software Engineering 1 Seite 48
49 Klassentest (2) Festlegung einer Testreihenfolge für das Zusammenspiel der Methoden Berücksichtige Abhängigkeiten zwischen den Methodenaufrufen Nicht-modal: keine (z.b. Sortierung) Testfälle müssen internen Zustand nicht berücksichtigen Uni-modal: feste Reihenfolge (z.b. Ampel) Testfälle testen alle zulässigen und unzulässigen Reihenfolgen Quasi-modal: inhaltsabhängige Reihenfolge (z.b. Stack) Testfälle für alle Zustände und Zustandsübergänge Modal: fachliche Reihenfolge (z.b. Konto) Wie quasi-modal Zusätzliche Berücksichtigung fachlicher Zusammenhänge Dr. Ina Schaefer Software Engineering 1 Seite 49
50 Zustandstests Spezifikationsbezogen ("black box"): Verwendung von Zustandsdiagrammen (z.b. UML) aus Analyse und Entwurf Abdeckungskriterien: alle Zustände alle Übergänge für jeden Übergang alle Folgeübergänge der Länge n Praxistauglich Programmbezogen ("glass box"): Automatische Berechnung eines Zustandsdiagramms Zustand = Abstraktion einer Klasse zulässiger Attributwerte Bestimmung der Übergänge erfordert symbolische Auswertung von Methoden (problematisch bei Schleifen und Rekursion) Im Forschungsstadium Dr. Ina Schaefer Software Engineering 1 Seite 50
51 Test-driven Development Programmierer testen meist nicht gerne. Testen ist zerstörerische Tätigkeit. Zu spätes Testen führt zu komplizierten Fehlersuchen! Test-First-Ansatz: Tests entstehen parallel zum Code (oder sogar vor dem Code) Programmierer schreiben Tests für praktischen Nutzen: Klare Spezifikation von Schnittstellen Beschreibung kritischer Ausführungsbedingungen Dokumentation von Fehlerbeseitigung Festhalten von notwendigem Verhalten vor größerem Umbau ("Refaktorisierung") Tests werden archiviert und sind automatisch ausführbar. Weitere Information: K. Beck, E. Gamma: Programmers love writing tests (JUnit) K. Beck: Extreme programming explained, Addison-Wesley 2000 Dr. Ina Schaefer Software Engineering 1 Seite 51
52 Wohin mit dem Test-Code? Zur Durchführung von Tests entsteht zusätzlicher Code: Testtreiber Testattrappen (Stubs) Testsuiten Testcode muss aufbewahrt werden, da Tests nach allen größeren Änderungen wiederholt werden. Alternativen: Testcode als Bestandteil der Klassen einfach zu verwalten, vergrößert Code "Spiegelbildliche" Hierarchie von Testklassen Redundanzproblem Erleichtert Verwendung von Test-Frameworks (z.b. JUnit) Testskripten in eigenen Sprachen klassischer Ansatz, keine Vererbung von Testfällen möglich Test-Unterklassen problematisch wegen Mehrfachvererbung Dr. Ina Schaefer Software Engineering 1 Seite 52
53 Integrationstests Integrationstests betrachten das Zusammenspiel von Komponenten. Falls Komponenten nicht allein lauffähig sind, muss Testrahmen bereitgestellt werden. Platzhalter (Stubs) Ersetzen nicht Vorhandene Codeteile Testobjekt Laufzeitumgebung, Monitore (protokollieren Ausgaben) Testtreiber (Driver) Liefern Testdaten, Stossen Ausführung an Dr. Ina Schaefer Software Engineering 1 Seite 53
54 Top-Down Integrationsteststrategie Benötigt viele Stubs, wenige Testtreiber Testing Level 1 Level 1 sequence... Level 2 Level 2 Level 2 Level 2 Level 2 stubs Level 3 stubs Dr. Ina Schaefer Software Engineering 1 Seite 54
55 Bottom-Up Integrationsteststrategie Benötigt viele Testtreiber, keine Stubs Test drivers Level N Level N Level N Level N Level N Testing sequence Test drivers Level N 1 Level N 1 Level N 1 Dr. Ina Schaefer Software Engineering 1 Seite 55
56 Inkrementelle Integration Test, dass neue Komponente nicht bisheriges Zusammenspiel stört. A T1 A T1 A T1 T2 B T2 T2 B T3 B T3 C T3 T4 C T4 D T5 Test sequence 1 Test sequence 2 Test sequence 3 Dr. Ina Schaefer Software Engineering 1 Seite 56
57 Systemtest Testet ob Kunden-Anforderungen richtig umgesetzt wurden (Verifikation) Testumgebung sollte Produktiv-Umgebung möglichst nahe kommen (also keine Stubs und Testtreiber) Produktiv-Umgebung oft selbst nicht geeignet wegen Schadensrisiko und mangelnder Kontrolle Einzelne Funktionen, aber auch Funktionssequenzen (für Geschäftsprozesse) testen Sollte Test von nicht-funktionalen Anforderungen beinhalten, wie Performanz, Sicherheit. Dr. Ina Schaefer Software Engineering 1 Seite 57
58 Abnahmetest wird vom Kunden vorgenommen Input: System Abnahmekriterien Testfälle Testplan Protokollvorlagen Systemdokumentation Abnahme -test Output: Testprotokolle Unterschriebenes Abnahmeprotokoll Abnahme ohne Mängel Abnahme mit Mängeln Abnahme verweigert Dr. Ina Schaefer Software Engineering 1 Seite 58
59 Zusammenfassung: Qualitätsmanagement Qualitätsmanagement umfasst Qualität der Prozesse und der Produkte (konstruktive vs. analytische Qualitätssicherung). Analytische Qualitätssicherung: Statisches Testen: Reviews, Inspektionen Dynamisches Testen: Unittests Integrationstests Systemtests Akzeptanztests Testmethoden: Black Box vs. White Box Testen, Coveragekriterien Dr. Ina Schaefer Software Engineering 1 Seite 59
3. Qualitätsmanagement 3.1. Prozessqualität
Farbe! Softwaretechnik Vorlesung 3. Qualitätsmanagement Prof. Dr. Bernhard Rumpe Technische Universität Braunschweig http://www.sse-tubs.de/ 3. Qualitätsmanagement 3.1. Prozessqualität Analyse Entwurf
MehrProf. Dr. B. Rumpe Software Systems Engineering TU Braunschweig. Seite 4. vl15.fse/02/01
Seite 4 Qualitätssicherung für Analyse und Entwurf Farbe! Softwaretechnik Vorlesung Prof. Dr. Bernhard Rumpe Technische Universität Braunschweig http://www.sse-tubs.de/ Hohe Bedeutung früher Phasen für
Mehr7. Qualitätssicherung
7. Qualitätssicherung 7.1 Test und Integration Test, Integration Wartung Allg. Literatur: Sommerville 19-20 Balzert Band 2, LE 14-15 Ambler Kap. 12 Speziell: Robert V. Binder: Testing object-oriented systems,
MehrQualitätsmanagement. Software Engineering 1 WS 2011/2012. Dr. Ina Schaefer Software Systems Engineering Technische Universität Braunschweig
Qualitätsmanagement Software Engineering 1 WS 2011/2012 Dr. Ina Schaefer Software Systems Engineering Technische Universität Braunschweig (Folien von Prof. B. Rumpe und Dr. A. Herrmann) Was ist Qualität?
MehrEinführung in die Softwaretechnik
oftware ngineering Farbe! Einführung in die technik Vorlesung, Teil 2 Kapitel 8. Qualitätsmanagement: Testen Prof. Dr. Bernhard Rumpe Lehrstuhl Informatik 3 ( ) Rheinisch-Westfälische Technische Hochschule
MehrQualitätssicherung. Was ist Qualität?
Ein Überblick Methoden und Werkzeuge zur Softwareproduktion Was ist Qualität? "Als Qualität eines Gegenstandes bezeichnen wir die Gesamtheit seiner charakteristischen Eigenschaften" Hesse et al. 2 Was
MehrSoftwaretechnik. Vertretung von Prof. Dr. Blume Fomuso Ekellem WS 2011/12
Vertretung von Prof. Dr. Blume WS 2011/12 Inhalt Test, Abnahme und Einführung Wartung- und Pflegephase gp Vorlesung Zusammenfassung Produkte und Recht (Folien von Prof. Blume) 2 , Abnahme und Einführung
MehrTestphase. Das Testen
Testphase VIS Projekt Freie Universität Berlin N.Ardet - 17.4.2001 Das Testen Testen ist das Ausführen eines Software- (Teil)systems in einer definierten Umgebung und das Vergleichen der erzielten mit
MehrHauptseminar Automotive Software Engineering Testen, Rapid Prototyping und x in the loop
Hauptseminar Automotive Software Engineering Testen, Rapid Prototyping und x in the loop Christoph Niedermayr 20.01.2005 Überblick 1 2 X in the loop Rapid Prototyping Begriffe Was versteht man unter statischem
MehrTesten Prinzipien und Methoden
Testen Prinzipien und Methoden ALP 2 SS2002 4.7.2002 Natalie Ardet Definition Im folgenden gilt: Software = Programm + Daten + Dokumentation Motivation Software wird immer mehr in Bereichen eingesetzt,
MehrT1 - Fundamentaler Testprozess
AK 2 am Armin Beer, Support Center Test der Software- Entwicklung 1 für einen erfolgreichen Test? Projektteam strebt nach Qualität Aufwände sind eingeplant (Richtwerte) 20 bis 30% des Gesamtaufwandes In
MehrQualitätsmanagement im Projekt
Software-Engineering Qualitätsmanagement im Projekt Vorlesung im Wintersemester 2008/2009 Fakultät Wirtschaftsinformatik Klaus Mairon, M.Sc. Inhalte Messen und Bewerten: Metriken in der Qualitätssicherung
MehrProgrammiertechnik II
Modultests Ziele Überprüfung der Korrektheit eines Moduls Korrektheit: Übereinstimmung mit (informaler) Spezifikation Modul: kleine testbare Einheit (Funktion, Klasse) Engl.: unit test White box testing
MehrSoftwaretechnikpraktikum SS 2004. Qualitätsmanagement I. 1. Überblick. Qualität. Qualitätsmerkmal
Softwaretechnikpraktikum SS 2004 Qualitätsmanagement I 5. Vorlesung 1. Überblick Planungsphase Definitionsphase Entwurfsphase Implem.- phase Fragen Was ist Qualität? Wie kann man Qualität messen? Wie kann
MehrT2 Fundamentaler Testprozess
T2 Fundamentaler Siemens AG Österreich 2005 All Rights Reserved Institut f. Software Technology, TU-Graz Armin Beer, PSE Support-Center Test Overview der Software- Entwicklung 2 1 Wasserfall-Modell Analyse
Mehr,$ -. "+0 *+*+ ! / -#$%$. #$%'' $ () 1 2$ #$%$! 1 2$3 )!
*+*+ *,$ -.! / -#$%$. #$%'' $ () "+0 *+*+ 4 *+*+ 1 2$ #$%$! 1 2$3 )! 1 *+*+ $& #$%'!' '!' 5 1! 1 4$5%! 1 63$ 1 $7$! 1 3! 1 77 8'7 1 /!$' 1 83% *+*+ 0 #$%'' '' #$%'' ''$' )%! $' #$% 5 87 $ 8$! 7$+ 1 #$%9$
MehrWhitebox-Tests: Allgemeines
-Tests: Allgemeines Andere Bezeichnungen Logic driven, Strukturelles Der Tester entwickelt Testfälle aus einer Betrachtung der Ablauflogik des Programms unter Berücksichtigung der Spezifikation Intuitiv
MehrQualitätsmanagement. Grundlagen
Grundlagen Historie: Mit industriellen Massenproduktion erforderlich geworden (Automobilindustrie, Anfang des letzten Jahrhunderts); Qualitätsmanagement zunächst nur in der Fertigung Mitte des letzten
MehrSoftwarequalität: Einführung. 15. April 2015
Softwarequalität: Einführung 15. April 2015 Überblick Warum ist Softwarequalität wichtig? Was ist Softwarequalität? Wie erreicht man Softwarequalität? Taentzer Softwarequalität 2015 8 Berühmte Software-Fehler
MehrTesten im Software- Entwicklungsprozess
Technologie-Event 2006 Testen im Software- Entwicklungsprozess W.Lukas, INGTES AG Was nicht getestet wurde, funktioniert nicht. -- R.Güdel (ca. 1998) Seite 2 Was sollen wir tun? Anomalien & Defekte von
MehrTypisierung des Replikationsplan Wirries, Denis Datenbankspezialist
Typisierung des Replikationsplan Wirries, Denis Datenbankspezialist Feintypisierung - Überblick Ergebnisse Ergebnisse aus aus anderen anderen Arbeitsergebnissen Arbeitsergebnissen Replikationsplan Replikationsplan
MehrValidierung und Verifikation!
Martin Glinz Thomas Fritz Software Engineering Kapitel 7 Validierung und Verifikation 2005-2013 Martin Glinz. Alle Rechte vorbehalten. Speicherung und Wiedergabe für den persönlichen, nicht kommerziellen
MehrFragebogen ISONORM 9241/110-S
Fragebogen ISONORM 9241/110-S Beurteilung von Software auf Grundlage der Internationalen Ergonomie-Norm DIN EN ISO 9241-110 von Prof. Dr. Jochen Prümper www.seikumu.de Fragebogen ISONORM 9241/110-S Seite
MehrSoftware- Qualitätsmanagement
Software- Qualitätsmanagement Thomas Kugel Brandenburg, den 10.12.2002 Agenda Einleitung Was heißt Softwarequalitätssicherung und Test Die Rolle von Test und QS in Softwareprojekten Wie wird getestet Statische
MehrDiplomarbeit. Konzeption und Implementierung einer automatisierten Testumgebung. Thomas Wehrspann. 10. Dezember 2008
Konzeption und Implementierung einer automatisierten Testumgebung, 10. Dezember 2008 1 Gliederung Einleitung Softwaretests Beispiel Konzeption Zusammenfassung 2 Einleitung Komplexität von Softwaresystemen
MehrSoftwarequalität: Zusammenfassung und Ausblick. 17. Juli 2013
Softwarequalität: Zusammenfassung und Ausblick 17. Juli 2013 Überblick Rückblick: Qualitätskriterien Qualitätsmanagement Qualitätssicherungsmaßnahmen Thesen zur Softwarequalität Ausblick: Lehrveranstaltungen
MehrÜbungsbeispiele für die mündliche Prüfung
Übungsbeispiele für die mündliche Prüfung Nr. Frage: 71-02m Welche Verantwortung und Befugnis hat der Beauftragte der Leitung? 5.5.2 Leitungsmitglied; sicherstellen, dass die für das Qualitätsmanagementsystem
MehrTesten - Konzepte und Techniken
Testen - Konzepte und Techniken Magdalena Luniak 21.11.2007 Magdalena Luniak () Testen - Konzepte und Techniken 21.11.2007 1 / 42 Übersicht 1 Motivation 2 Grundbegrie 3 Testen im Softwareentwicklungsprozess
MehrStandard Inhaltsverzeichnis für Testvorschrift
Standard Inhaltsverzeichnis für Testvorschrift Inhaltsverzeichnis 1. Zweck, Veranlassung... 1 2. Allgemeines... 1 2.1 Zweck der Testvorschrift... 1 2.2 Freigabe und Änderungen... 1 2.3 Prinzipien... 2
MehrPRÜFUNG FÜR ELEKTROINGENIEURE. Softwaretechnik I. Musterlösung SS 12. - Ohne Gewähr -
PRÜFUNG FÜR ELEKTROINGENIEURE Softwaretechnik I Musterlösung SS 12 - Ohne Gewähr - LfdNr. Thema Punkte Zeitbedarf in min 1 Analyse und Entwurf 15 30 2 Basistechniken und Test 15 30 3 Projektmanagement
MehrTesten. SEPR Referat: Testen - Oliver Herbst
Testen Inhalt 1. Grundlagen des Testens 2. Testen im Softwarelebenszyklus 3. Statischer Test 4. Dynamischer Test 5. Besondere Tests 2 1. Grundlagen des Testens 3 Grundlagen des Testens Motivation erfüllt
MehrProjektmanagement. Vorlesung von Thomas Patzelt 9. Vorlesung
Projektmanagement Vorlesung von Thomas Patzelt 9. Vorlesung 1 Pläne Kein Plan überlebt die erste Feindberührung - Feldmarschall Helmuth von Moltke Prognosen sind schwierig, besonders wenn sie die Zukunft
MehrProjektmanagement Vorlesung 14/ 15: Wiederholung ausgewählter Themen zur Klausurvorbereitung. Prof. Adrian Müller, PMP, PSM-1, CSM FH Kaiserslautern
Projektmanagement Vorlesung 14/ 15: Wiederholung ausgewählter Themen zur Klausurvorbereitung Prof. Adrian Müller, PMP, PSM-1, CSM FH Kaiserslautern phone: +49 631/3724-5329 http://www.hs-kl.de/~amueller
MehrSoftware Engineering II (IB) Testen von Software / Modultests
Testen von Software / Modultests Prof. Dr. Oliver Braun Fakultät für Informatik und Mathematik Hochschule München SS 2015 Programm-Tests Tests sollen zeigen, dass ein Programm das tut was es tun soll sowie
MehrSEP 114. Design by Contract
Design by Contract SEP 114 Design by Contract Teile das zu entwickelnde Programm in kleine Einheiten (Klassen, Methoden), die unabhängig voneinander entwickelt und überprüft werden können. Einheiten mit
MehrTestautomatisierung. Lessons Learned. qme Software. Gustav-Meyer-Allee 25 13355 Berlin. Telefon 030/46307-230 Telefax 030/46307-649
Testautomatisierung Lessons Learned qme Software GmbH Gustav-Meyer-Allee 25 13355 Berlin Telefon 030/46307-230 Telefax 030/46307-649 E-Mail qme Software info@qme-software.de GmbH Testautomatisierung Lessons
MehrInformationssystemanalyse Problemstellung 2 1. Trotz aller Methoden, Techniken usw. zeigen Untersuchungen sehr negative Ergebnisse:
Informationssystemanalyse Problemstellung 2 1 Problemstellung Trotz aller Methoden, Techniken usw. zeigen Untersuchungen sehr negative Ergebnisse: große Software-Systeme werden im Schnitt ein Jahr zu spät
MehrBasiswissen Softwaretest
Andreas Spillner Tilo Linz Basiswissen Softwaretest Aus- und Weiterbildung zum Certified Tester Foundation Level nach ISTQB-Standard 3., überarbeitete und aktualisierte Auflage I Technische l'^vrau«! D~w.-iE*arit
MehrISO 9001 und CMM im Vergleich
ISO 9001 und CMM im Vergleich internationale Norm ISO 9001 umfasst 20 Forderungen/ Klauseln 1 Vorbereitung Audit Wie wird zertifiziert Wie erfolgt Dokumentation? Handbuch (QMH) Verfahrensanweisungen (QMV)
MehrWas beinhaltet ein Qualitätsmanagementsystem (QM- System)?
Was ist DIN EN ISO 9000? Die DIN EN ISO 9000, 9001, 9004 (kurz ISO 9000) ist eine weltweit gültige Norm. Diese Norm gibt Mindeststandards vor, nach denen die Abläufe in einem Unternehmen zu gestalten sind,
MehrEinsatz automatischer Testdatengenerierung im modellbasierten Test
Einsatz automatischer Testdatengenerierung im modellbasierten Test Sadegh Sadeghipour sadegh.sadeghipour@itpower.de Gustav-Meyer-Allee 25 / Gebäude 12 13355 Berlin www.itpower.de Modellbasierte Software-Entwicklung
MehrTestplan. Hochschule Luzern Technik & Architektur. Software Komponenten FS13. Gruppe 03 Horw, 16.04.2013
Software Komponenten FS13 Gruppe 03 Horw, 16.04.2013 Bontekoe Christian Estermann Michael Moor Simon Rohrer Felix Autoren Bontekoe Christian Studiengang Informatiker (Berufsbegleitend) Estermann Michael
MehrFortgeschrittenes Programmieren mit Java. Test Driven Development
Fortgeschrittenes Programmieren mit Java Test Driven Development Test getriebene Programmierung Benedikt Boeck Hochschule für Angewandte Wissenschaften Hamburg 6. November 2009 B. Boeck (HAW Hamburg) Test
MehrClient-Server-Beziehungen
Client-Server-Beziehungen Server bietet Dienste an, Client nutzt Dienste Objekt ist gleichzeitig Client und Server Vertrag zwischen Client und Server: Client erfüllt Vorbedingungen eines Dienstes Server
Mehrwhite sheep GmbH Unternehmensberatung Schnittstellen Framework
Schnittstellen Framework Mit dem Schnittstellen Framework können Sie einerseits Ihre Schnittstellen automatisch überwachen. Eine manuelle Kontrolle wird überflüssig, da das Schnittstellen Framework ihre
MehrInformation zur Revision der ISO 9001. Sehr geehrte Damen und Herren,
Sehr geehrte Damen und Herren, mit diesem Dokument möchten wir Sie über die anstehende Revision der ISO 9001 und die sich auf die Zertifizierung ergebenden Auswirkungen informieren. Die folgenden Informationen
MehrSystematisches Testen von Software
Programmierung Systematisches Testen von Software Markus Eckstein Systematika Information Systems GmbH Kurfürsten-Anlage 36 69115 Heidelberg markus.eckstein@systematika.com Zusammenfassung Die wichtigsten
MehrBasiswissen Softwaretest
Basiswissen Softwaretest Vergleich der Vorlesung Software-Engineering Wartung und Qualitätssicherung (Stand WS13/14) mit der 4. überarbeiteten und aktualisierten Auflage von Spillner&Linz: Basiswissen
MehrGPP Projekte gemeinsam zum Erfolg führen
GPP Projekte gemeinsam zum Erfolg führen IT-Sicherheit Schaffen Sie dauerhaft wirksame IT-Sicherheit nach zivilen oder militärischen Standards wie der ISO 27001, dem BSI Grundschutz oder der ZDv 54/100.
MehrEinführung von Testautomatisierung reflektiert. Erkenntnisse eines Linienmanagers zu Herausforderungen und Fallgruben
Einführung von Testautomatisierung reflektiert Erkenntnisse eines Linienmanagers zu Herausforderungen und Fallgruben Matt Young Leiter Test Acquiring Inhaltsverzeichnis Einleitung Testautomatisierung PostFinance
MehrSoftwareentwicklungsprozess im Praktikum. 23. April 2015
Softwareentwicklungsprozess im Praktikum 23. April 2015 Agile Softwareentwicklung Eine agile Methodik stellt die beteiligten Menschen in den Mittelpunkt und versucht die Kommunikation und Zusammenarbeit
MehrSoftwaretechnik. Fomuso Ekellem WS 2011/12
WS 2011/12 Inhalt Projektvorstellung Übung 1 Wiederholung zusammengefasst Planungsphase Lernziele Ziele und Inhalt der Planungsphase Anlass und Aufgabestellung(Was ist dabei erförderlich) Requirement Engineering
MehrFragebogen zur Anforderungsanalyse
Fragebogen zur Anforderungsanalyse Geschäftsprozess Datum Mitarbeiter www.seikumu.de Fragebogen zur Anforderungsanalyse Seite 6 Hinweise zur Durchführung der Anforderungsanalyse Bevor Sie beginnen, hier
MehrZusammenfassung der Testarten
oftware-test Zusammenfassung der Testarten Komponententest Integrationstest Systemtest Grenztest Black Box Test zustands basierter Test White Box Test Pfadtest Strategie: Urknall Top Down Bottom Up Sandwich
Mehrextreme Programming (XP) Hermann Götz Sergij Paholchak Agenda Was ist XP? Grundprinzipien Der Entwicklungsprozess Die Projektplanung Praktiken Vorteile und Nachteile Wann macht XP Sinn für ein Projekt?
Mehr6. Programmentwicklung
6. Programmentwicklung Fertigungsprozess Qualitativ hochwertige Software ist ein Industrieprodukt -> Methoden der Industrie übertragen auf der Herstellprozess -> Herstellprozess gliedert sich in Phasen
MehrAlgorithmen und Datenstrukturen
Algorithmen und Datenstrukturen Dipl. Inform. Andreas Wilkens 1 Organisatorisches Freitag, 05. Mai 2006: keine Vorlesung! aber Praktikum von 08.00 11.30 Uhr (Gruppen E, F, G, H; Vortestat für Prototyp)
MehrTestmanagement. Q-Day. Frank Böhr Fraunhofer IESE frank.boehr@iese.fraunhofer.de
Frank Böhr Fraunhofer IESE frank.boehr@iese.fraunhofer.de Agenda Warum Testmanagement? Was sind die wichtigsten Schritte beim Testmanagement? Wie funktioniert Testmanagement Toolunterstützung Page 1/15
MehrInhalt. 1 Einleitung 1. 2 Grundkonzepte 11. 3 Erfahrungen systematisch nutzen 39
xi 1 Einleitung 1 1.1 Softwarequalität betrifft viele................................ 1 1.2 Für wen dieses Buch gemacht ist.............................. 1 1.3 Was Sie von diesem Buch erwarten können......................
MehrInhalt. 1 Einleitung AUTOMATISCHE DATENSICHERUNG AUF EINEN CLOUDSPEICHER
AUTOMATISCHE DATENSICHERUNG AUF EINEN CLOUDSPEICHER Inhalt 1 Einleitung... 1 2 Einrichtung der Aufgabe für die automatische Sicherung... 2 2.1 Die Aufgabenplanung... 2 2.2 Der erste Testlauf... 9 3 Problembehebung...
MehrTest-Strategien. Grundsätzliches Blackbox-Testen Whitebox-Testen Graybox-Testen Ablauf von Tests Zusammenfassung. HS Mannheim
Test- Grundsätzliches - - - Ablauf von Tests Grundsätzliche Test- -Tests Äquivalenzklassenbildung Randwertanalyse -Tests Man unterscheidet verschiedene Überdeckungsgrade: Statement Coverage Decision Coverage,
MehrJ O L A N T H E D L U G O K E C K I C A R O L I N K A N J A
Qualitätsmanagement JOLANTHE DLUGOKECKI CAROLIN KANJA Gliederung Definitionen 3 Nutzen des Qualitätsmanagements 4 Bestandteile des Qualitätsmanagements 5-8 EFQM-Modell 9 ISO 9000 ff. 10-11 ISO 10006 und
MehrQM: Prüfen -1- KN16.08.2010
QM: Prüfen -1- KN16.08.2010 2.4 Prüfen 2.4.1 Begriffe, Definitionen Ein wesentlicher Bestandteil der Qualitätssicherung ist das Prüfen. Sie wird aber nicht wie früher nach der Fertigung durch einen Prüfer,
MehrManagementbewertung Managementbewertung
Managementbewertung Grundlagen für die Erarbeitung eines Verfahrens nach DIN EN ISO 9001:2000 Inhalte des Workshops 1. Die Anforderungen der ISO 9001:2000 und ihre Interpretation 2. Die Umsetzung der Normanforderungen
MehrSenior Consulting. Senior Consulting Strategical, Conceptual and Technical Consulting. 30.01.2011 Seite 1
30.01.2011 Seite 1 This flyer is exclusively for the use of client personnel. No part of it may be distributed, quoted or reproduced outside the client organisation without the prior written approval of
MehrWas versteht man unter Softwaredokumentation?
Was versteht man unter? Mit bezeichnet man die Dokumentation von Computer-Software. Sie erklärt für Anwender, Benutzer und Entwickler in unterschiedlichen Rollen, wie die Software funktioniert, was sie
MehrSoftware - Testung ETIS SS05
Software - Testung ETIS SS05 Gliederung Motivation Was ist gute Software? Vorurteile gegenüber Testen Testen (Guidelines + Prinzipien) Testarten Unit Tests Automatisierte Tests Anforderungen an Testframeworks
MehrValidierung und Verifikation
Martin Glinz Harald Gall Software Engineering Kapitel 7 Validierung und Verifikation Universität Zürich Institut für Informatik 2005, 2009 Martin Glinz. Alle Rechte vorbehalten. Speicherung und Wiedergabe
MehrProzessbewertung und -verbesserung nach ITIL im Kontext des betrieblichen Informationsmanagements. von Stephanie Wilke am 14.08.08
Prozessbewertung und -verbesserung nach ITIL im Kontext des betrieblichen Informationsmanagements von Stephanie Wilke am 14.08.08 Überblick Einleitung Was ist ITIL? Gegenüberstellung der Prozesse Neuer
MehrProbeklausur. Lenz Belzner. January 26, 2015. Lenz Belzner Probeklausur January 26, 2015 1 / 16
Probeklausur Lenz Belzner January 26, 2015 Lenz Belzner Probeklausur January 26, 2015 1 / 16 Definieren Sie Software Engineering in Abgrenzung zu Individual Programming. Ingenieursdisziplin professionelle
MehrModul 07-203-2102. Klausur zu den Teilgebieten Software-Management und Software-Qualitätsmanagement
Modul 07-203-2102 Klausur zu den Teilgebieten Software-Management und Software-Qualitätsmanagement Prof. Fähnrich, Prof. Gräbe, Dr. Riechert Institut für Informatik Sommersemester 2013 Allgemeine Bemerkungen
MehrÜbungsaufgaben zum Software Engineering: Management
Übungsaufgaben zum Software Engineering: Management Grundbegriffe: Aufgabe 1: Aus welchen Disziplinen setzt sich das Software Engineering zusammen? a. Informatik b. Physik c. Psychologie d. Chemie e. Geologie
MehrTestmanagement in IT-Projekten
Teil 1: Projektmagazin 05/20009 Teil 2: Projektmagazin 06/2009 1 Test: Prozess, bei dem ein Programm oder ein Software-System ausgeführt wird, um Fehler zu finden Teil 1: Projektmagazin 05/20009 Teil 2:
MehrSoftwaretechnik (Allgemeine Informatik) Überblick
Softwaretechnik (Allgemeine Informatik) Überblick 1 Einführung und Überblick 2 Abstraktion 3 Objektorientiertes Vorgehensmodell 4 Methoden der Anforderungs- und Problembereichsanalyse 5 UML-Diagramme 6
MehrAgile Vorgehensmodelle in der Softwareentwicklung: Scrum
C A R L V O N O S S I E T Z K Y Agile Vorgehensmodelle in der Softwareentwicklung: Scrum Johannes Diemke Vortrag im Rahmen der Projektgruppe Oldenburger Robot Soccer Team im Wintersemester 2009/2010 Was
MehrSoftware Engineering in der Praxis
Software Engineering in der Praxis Praktische Übungen Dirk Wischermann Marc Spisländer Lehrstuhl für Software Engineering Friedrich-Alexander-Universität Erlangen-Nürnberg 18. Dezember 2006 Inhalt Nachlese
MehrQualität in Projekten
Qualitätssicherung (QS) / Qualitätsmanagement (QM).. was braucht ein Projekt? 1 Inhalte Begrüßen / Vorstellen QS / QM im Unternehmen & QS / QM im Projekt Beispiele (Kosten) Zusammenfassung / Abschluss
MehrTest. Dipl. Wirtsch. Ing. Alexander Werth 9-1
Test Dipl. Wirtsch. Ing. Alexander Werth 9-1 Phasen der Problemdefinition Anforderungsanalyse Spezifikation Entwurf Implementation Erprobung Wartung Methoden der 9-2 Software Test / Erprobung Messen der
MehrKonzeption. und prototypische Implementierung. eines Werkzeuges. für den funktionalen Klassentest
Konzeption und prototypische Implementierung eines Werkzeuges für den funktionalen Klassentest Übersicht Motivation Zielsetzung Lösungsansatz und dessen Realisierung Anwendungs-Szenarien Präsentation von
MehrÜbungsklausur vom 7. Dez. 2007
Übungsklausur vom 7. Dez. 2007 Ein Lösungsmuster Teilbereiche der Softwaretechnik Software Anforderungen Software Entwurf Software Konstruktion Software Test Software Wartung Software Konfigurationsmanagement
MehrAgile Software-Entwicklung im Kontext der EN50128 Wege zum Erfolg
Herzlich willkommen Agile Software-Entwicklung im Kontext der EN50128 Wege zum Erfolg Heike Bickert Software-/Systemingenieurin, Bereich Quality Management Braunschweig // 17.11.2015 1 Agenda ICS AG Fragestellungen
MehrWir erledigen alles sofort. Warum Qualität, Risikomanagement, Gebrauchstauglichkeit und Dokumentation nach jeder Iteration fertig sind.
Wir erledigen alles sofort Warum Qualität, Risikomanagement, Gebrauchstauglichkeit und Dokumentation nach jeder Iteration fertig sind. agilecoach.de Marc Bless Agiler Coach agilecoach.de Frage Wer hat
MehrKlausur zu den Teilgebieten Software-Management und Software-Qualitätsmanagement
Klausur zu den Teilgebieten Software-Management und Software-Qualitätsmanagement Prof. Dr. H.-G. Gräbe, T. Riechert Institut für Informatik Sommersemester 2010 Allgemeine Bemerkungen Jedes Blatt ist mit
MehrKomponententest. Testen von Software Systemen. Übung 02 SS 2009 Version: 1.0 09.06.2009
Testen von Software Systemen Übung 02 SS 2009 Version: 1.0 09.06.2009 Komponententest Kunde: Dr. Reinhold Plösch Dr. Johannes Sametinger Kundenreferenz: 259.019 Team 19 Mitarbeiter: Christian Märzinger
Mehr2015-06-11 Tagesprogramm
1 2015-06-11 Tagesprogramm Design-by-Contract 2 Vertragspartner Anbieter (Server) bietet Leistungen (Services) an Kunde (Client) nimmt von Anbietern angebotene Leistungen in Anspruch Details der Inanspruchnahme
MehrQualitätssicherung im Lebenszyklus des itcs. Anspruch und Wirklichkeit.
Qualitätssicherung im Lebenszyklus des itcs. Anspruch und Wirklichkeit. BEKA: Frankfurt, 25. Oktober 2012 T-Systems Angebot Umsetzung des globalen Telematikprojekts für den ÖPNV im Großherzogtum Luxemburg.
MehrProzessoptimierung. und. Prozessmanagement
Prozessoptimierung und Prozessmanagement Prozessmanagement & Prozessoptimierung Die Prozesslandschaft eines Unternehmens orientiert sich genau wie die Aufbauorganisation an den vorhandenen Aufgaben. Mit
MehrSoftwareentwicklung Schrittweise Verfeinerung, Programmieren üben: Tic-Tac-Toe in Raten
Mag. iur. Dr. techn. Michael Sonntag Softwareentwicklung Schrittweise Verfeinerung, Programmieren üben: Tic-Tac-Toe in Raten E-Mail: sonntag@fim.uni-linz.ac.at http://www.fim.uni-linz.ac.at/staff/sonntag.htm
MehrWirtschaftsinformatik I Teil 2. Sommersemester 2008. 1. Übung
Wirtschaftsinformatik I Teil 2 Sommersemester 2008 1. Übung Sarah Mund, Kirstin Simon, Markus Trierweiler, Christian Molitor, Jonathan Jäger, Björn Kirsten Aufgabenstellung Diskutieren Sie die Vor- und
MehrQualitätssicherungskonzept
Softwaretechnikpraktikum Gruppe: swp15.aae SS 2015 Betreuer: Prof. Gräbe Datum: 15.06.2015 Tutor: Klemens Schölhorn Qualitätssicherungskonzept Projektteam: Felix Albroscheit Dorian Dahms Paul Eisenhuth
MehrMaintenance & Re-Zertifizierung
Zertifizierung nach Technischen Richtlinien Maintenance & Re-Zertifizierung Version 1.2 vom 15.06.2009 Bundesamt für Sicherheit in der Informationstechnik Postfach 20 03 63 53133 Bonn Tel.: +49 22899 9582-0
MehrStuPro-Seminar Dokumentation in der Software-Wartung. StuPro-Seminar Probleme und Schwierigkeiten in der Software-Wartung.
StuPro-Seminar Dokumentation in der Software-Wartung StuPro-Seminar Probleme und Schwierigkeiten in der Software-Wartung Folie 1/xx Software-Wartung: theoretisch Ausgangslage eigentlich simpel: fertige
MehrSoftware-Entwicklungsprozesse zertifizieren
VDE-MedTech Tutorial Software-Entwicklungsprozesse zertifizieren Dipl.-Ing. Michael Bothe, MBA VDE Prüf- und Zertifizierungsinstitut GmbH BMT 2013 im Grazer Kongress 19.09.2013, 10:00-10:30 Uhr, Konferenzraum
MehrHow to do? Projekte - Zeiterfassung
How to do? Projekte - Zeiterfassung Stand: Version 4.0.1, 18.03.2009 1. EINLEITUNG...3 2. PROJEKTE UND STAMMDATEN...4 2.1 Projekte... 4 2.2 Projektmitarbeiter... 5 2.3 Tätigkeiten... 6 2.4 Unterprojekte...
MehrDatenbank-Verschlüsselung mit DbDefence und Webanwendungen.
Datenbank-Verschlüsselung mit DbDefence und Webanwendungen. In diesem Artikel werden wir Ihnen zeigen, wie Sie eine Datenbank verschlüsseln können, um den Zugriff einzuschränken, aber trotzdem noch eine
MehrFUTURE NETWORK 20.11.2013 REQUIREMENTS ENGINEERING
18/11/13 Requirements Engineering 21 November 2013 DIE GRUNDFRAGEN Wie erhält der Kunde den größten Nutzen? Wie kann der Kunde am besten spezifizieren, was er haben will? Welchen Detailierungsgrad braucht
MehrKlausur WS 2006/07 Programmiersprache Java Objektorientierte Programmierung II 15. März 2007
Fachhochschule Bonn-Rhein-Sieg University of Applied Sciences Fachbereich Informatik Prof. Dr. Peter Becker Klausur WS 2006/07 Programmiersprache Java Objektorientierte Programmierung II 15. März 2007
MehrZiel- und Qualitätsorientierung. Fortbildung für die Begutachtung in Verbindung mit dem Gesamtplanverfahren nach 58 SGB XII
Ziel- und Qualitätsorientierung Fortbildung für die Begutachtung in Verbindung mit dem Gesamtplanverfahren nach 58 SGB XII Qualität? In der Alltagssprache ist Qualität oft ein Ausdruck für die Güte einer
MehrSoftware Engineering. Dokumentation! Kapitel 21
Martin Glinz Thomas Fritz Software Engineering Kapitel 21 Dokumentation 2005-2013 Martin Glinz. Alle Rechte vorbehalten. Speicherung und Wiedergabe für den persönlichen, nicht kommerziellen Gebrauch gestattet;
Mehr