Softwaretechnik- Praktikum: 6. Vorlesung Jun.-Prof Prof.. Dr. Holger Giese Raum E 3.165 Tel. 60-3321 Email: hg@upb.de Softwaretechnikpraktikum: IV Software-Qualitätssicherung (Fortsetzung) Jun.-Prof Prof.. Dr. Holger Giese Raum E 3.165 Tel. 60-3321 Email: hg@upb.de IV Software-Qualitätssicherung IV.1 Grundlagen IV.2 Analytisches Qualitätsmanagement IV.2.1 Analysierende Verfahren IV.2.2 Testende Verfahren IV.3 Konstruktives Qualitätsmanagement IV.5 Prozessqualität IV.6 Diskussion & Zusammenfassung IV.7 Literaturhinweise IV.3 Konstruktives Qualitätsmanagement Software-Entwicklung Notationen Methoden (1) Werkzeuge SE/TSE Modellbasierte Software- Entwicklung (siehe 2. Studienabschnitt) Infrastruktur (2) Prozeduren und Arbeitsanweisungen (3) Vorlagen und Checklisten (4) Mitarbeiter Schulung & Zertifizierung Versions- und Konfigurationsmanagement (s. 1. Vorlesung) V6-3 V6-4 (1) Werkzeuge Formen der Werkzeugunterstützung Auswirkung auf die Produktqualität Auswirkung auf die Qualität der Wartung Auswirkung auf das Projektmanagement Formen der Werkzeugunterstützung Traditionelle Werkzeuge unterstützen den Entwickler bei den Aktivitäten einer Phase des Software Lebenszyklus. Computer Aided Software Engineering (CASE) Werkzeuge unterstützen den Entwickler bei Arbeiten, die mehrere Phase des Software Lebenszyklus umfassen. V6-5 V6-6 1
Customer System analyst Programmer Tester Installation team Maintenance team Requirements determination Customer s requirements doc. Analysis System requirements doc. Traditional Design Detailed design doc. Coding Program code files Testing Installation Installed code files Operation and maintenance Customer System analyst Programmer Tester Installation team Maintenance team Requirements determination Customer s requirements doc. Analysis Upper -CASE Design Upper -CASE Coding Lower - CASE Testing CASE testing tools Installation Operation and maintenance CASE tool-supported R e p o s i t o r y Auswirkung auf die Produktqualität Beitrag zur Qualität bzgl. der Fehlerursachen Ursachen von Softwarefehlern traditionelle Werkzeuge CASE Werkzeuge 1. Fehlerhafte Anforderungen - sehr gering 2. Fehler in der Kommunikation zwischen Kunde und Entwickler - sehr gering 3. Abweichung von den Anforderungen - hoch 4. Logische Entwurfsfehler - hoch 5. Programmierfehler sehr hoch sehr hoch 6. Abweichungen von Programmier- und Dokumentationsrichtlinien beschränkt sehr hoch 7. Schwächen des Testprozesses hoch hoch 8. Fehler in der Benutzerschnittstelle oder Verfahrensfehlern beschränkt beschränkt 9. Fehler in der Dokumentation beschränkt sehr hoch V6-7 V6-8 Vollständige und immer aktuellen Auswirkung auf die Qualität der Wartung Für Korrektive Wartung: Mittels CASE Werkzeugen automatisch generierte Dokumentation führt zu einer einfacheren und zuverlässigeren Identifikation von Fehlerursachen (Querverweise, Erfassung der Korrekturen, ) Für Adaptive Wartung: V6-9 Auswirkung auf das Projektmanagement Verringerte Kosten Verringerte Entwicklungszeiten Weniger Abweichungen vom Plan da In der Regel geringeren Fehlerraten Geringere Korrekturkosten ABER: bisher sind Projektkontrolle und CASE nicht wirklich integriert V6-10 (2) Prozeduren und Arbeitsanweisungen Vorteile: Ausführung von Aktivitäten auf die effektivste und effizienteste Art. Effektive and effiziente Kommunikation zwischen Entwicklern und Wartungspersonal, die zu weniger Missverständnissen und daraus folgenden Fehlern führt. Vereinfachte Koordination zwischen den Aufgaben und Aktivitäten verschiedener Teams führt zu weniger Fehlern. Was wird durch Prozeduren geregelt? Die Fünf W's: Welche Aktivitäten müssen ausgeführt werden? Wie sollen die Aktivitäten ausgeführt werden? Wann sollen die Aktivitäten ausgeführt werden? Wo sollen die Aktivitäten ausgeführt werden? Wer sollen die Aktivitäten ausführen? V6-11 V6-12 2
Quellen für Prozeduren Ausprägung und Weiterentwicklung von Prozeduren Internationale oder nationale SQA SQA Richtlinien der Organisation Relevante Faktoren für Prozeduren Typ der Software Kundenspektrum SQA Ansatz der Organisation SQA Prozeduren der Organisation SQA Arbeitsanweisungen Update wird notwendig aufgrund von technologischem Wandel Aufgabenverlagerung der Organisation Benutzervorschlägen Analyse der eigenen Projekte Externe Analyseergebnissen V6-13 V6-14 (3) Vorlagen und Checklisten Vorlagen Schematische Vorlage für Dokumente, die während der Softwareentwicklung benötigt werden (z.b. Pflichtenheft, Testbericht, ) Checklisten Liste von Teilaufgaben, die im rahmen einer Aktivität festzulegen oder zu erledigen sind. Vorteile von Vorlagen Für das Entwicklerteam: Vereinfacht die Erstellung der Dokumente. Führt in der Regel zu vollständigeren Dokumenten. Vereinfacht die Integration neuer Teammitglieder. Vereinfacht den Review der Dokumente. Für das Wartungsteam: Ermöglicht die einfacher Lokalisierung von Informationen. V6-15 V6-16 Vorteile von Checklisten Für das Entwicklerteam: Hilft dem Entwickler bei der Überprüfung der eigenen Ergebnisse. Hilft Entwicklern bei der Vorbereitung von Aufgaben. Für das Reviewteam: Garantiert die Vollständigkeit des Reviews. Erhöht die Effizienz des Reviews. (4) Vorteile: Anwendung des State of the Art bzgl. Methoden und Prozeduren. Besseres Verständnis und Koordination zwischen Entwicklerteams und Wartungsteams. Bessere Kooperation zwischen Entwicklern und externern Projektbeteiligten. Besseres Verständnis und Koordination zwischen Anbietern und Kunden durch Aufnahme von in den Vertrag. V6-17 V6-18 3
Arten von Charakteristika Zielgruppe Fokus Zielrichtung des Ziel des Qualitätsmanagement- Management der Softwareentwicklung und/oder Wartung sowie deren SQA Abteilung Organisation, Infrastruktur und Anforderungen an diese Was soll erreicht werden Prozessqualität Prozess- Produktqualität Teams, die für die Softwareentwicklung und/oder Wartung zuständig sind Methoden zur Durchführung von Softwareentwicklungsund Wartungsprojekten Das Wie der Ausführung Organisationen die SQA entwickeln IEEE (Institute of Electric and Electronic Engineers) Computer Society ISO (International Organization) DOD (US Department of Defense) ANSI (American National Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association) V6-19 V6-20 Prozess- IEEE Software Engineering : Struktur und Inhalt IEEE/EIA Std. 12207 Software life cycle processes IEEE Std. 1012 Verification and validation IEEE Std. 1028 Reviews Klassen von IEEE A Konzeptionelle Prinzipien und Gesamtansatz IEEE 1061 Software Quality Metrics Methodology IEEE/EIA 12207.0 Information Technology Software Life Cycle Processes B, die Vorgaben festlegen Vorgaben, die eingehalten werden müssen. IEEE 829 Software Test Documentation IEEE 1012 Software Verification And Validation IEEE 1028 Software Reviews C, die Anleitung zur Ausführung geben Umsetzung der der Klasse B IEEE 1233 Guide for Developing System Requirement Specifications IEEE/EIA 12207.1 Guide, Information technology Software Life Cycle Processes Life CycleData V6-21 V6-22 IEEE/EIA Std 12207 - Information Technology Software Life Cycle Processes Ziele: Etablierung eines international anerkannten Modells für Software Lebenszyklus Prozesse auf das die Softwareindustrie weltweit verweisen kann. Das Verständnis zwischen den verschiedenen Beteiligten durch Einführung allgemein anerkannter Prozesse, Aktivitäten und Aufgaben fördern. Tailoring Acquisition Supply Development Operation Maintenance Management Documentation Infrastructure Configuration management Improvement Quality assurance Training Verification Validation Joint review Audit Problem resolution Organizational processes Copyright 1992 IEEE. All rights reserved. Primary processes IEEE/EIA Std 12207 Software life cycle processes Supporting processes S o f t w a r e l if e c y c l e V6-23 V6-24 4
IEEE Std 1012 Verification and validation Ziele: Ein allgemeines Framework für V&V Aktivitäten und Aufgaben für alle Software Lebenszyklus Prozesse. Festlegung von V&V Anforderungen inklusive der benötigten Eingaben und resultierenden Ausgaben. Festlegung von Software Integritätsstufen und der entsprechenden V&V Aufgaben. Festlegung des Inhalts des Software V&V Plans. IEEE Std 1028 Reviews Ziele: Definition systematischer Review Prozeduren, die Durchgängig für alle Reviews im Lebenszyklus der Software anwendbar sind und Mit den Anforderungen anderen an Reviews vereinbar sind. Konzepte: hochgradig formales Vorgehen Reviewtypen: Management reviews, Technical reviews, Inspections, Walkthroughs, Audits Reviews werden im durch nachfolgende Überwachung der Korrekturen begleitet V6-25 V6-26 IV.5 Prozessqualität Hintergrund: Produktivität (gemessen rein in LOC) kann kaum gesteigert werden Qualitätssicherungsmaßnahmen können nur in einem geeigneten Umfeld rational eingesetzt werden Die Qualität eines Produktes kann durch Managementmaßnahmen signifikant gesteigert werden Prozessqualität als Ansatzpunkt Eine gute Qualität eines Produktes kann besser über die Qualität des Erstellungsprozesses erreicht werden als allein über Qualitätssicherungsmaßnahmen unmittelbar am Produkt (see [Humphrey1998a]) Ansätze: ISO 9000 Familie CMM / PSP / TSP SPICE project and the ISO/IEC 15504 software process assessment standard TQM (Total Quality Management) V6-27 V6-28 QS vs. QM (in Anlehnung an TQM) Ziele Orientierung Organisation Methoden QS Bessere Produkte Geringere Kosten Produkt Starke QS Analyse (Messen, Testen) QM Bessere Unternehmen Kundenzufriedenheit Flexibilität Markt Prozeß Alle Mitarbeiter Festlegung der Prozesse Prozeßüberwachung und optimierung Schulung Arten von Charakteristika Zielgruppe Fokus Zielrichtung des Ziel des Qualitätsmanagement- Management der Softwareentwicklung und/oder Wartung sowie deren SQA Abteilung Organisation, Infrastruktur und Anforderungen an diese Was soll erreicht werden Prozessqualität Prozess- Produktqualität Teams, die für die Softwareentwicklung und/oder Wartung zuständig sind Methoden zur Durchführung von Softwareentwicklungsund Wartungsprojekten Das Wie der Ausführung V6-29 V6-30 5
Arten von Qualitätsmanagement Zertifizierungsstandards: Eine externe Zertifizierungsstelle bescheinigt einer Organisationen die Fähigkeit Produkte oder Dienstleistungen mit akzeptabler Qualität zu liefern. Dient als Basis für eine Evaluierung des Qualitätsmanagementsystems des Anbieters durch den Kunden. Fördert die Bestrebung im Bereich des Qualitätsmanagement in der Organisation mittels Einhaltung von. Assessment-: Dient Organisationen zur Selbstbeurteilung in Bezug auf die Fähigkeit Softwareentwicklungsprojekte durchzuführen. Dient zur Verbesserung von Entwicklungs- und Wartungsprozessen. Hilft die Fähigkeiten möglicher Lieferanten einzuschätzen. (1) ISO 9000-3 / ISO 9001 ISO 9001 beschreibt ganz allgemein Modelle zur Darlegung der Qualitätssicherung in Entwicklung, Produktion, Montage und Kundendienst ISO 9000-3 ist eine Richtlinie für die Anwendung von ISO 9001 auf die Entwicklung und Wartung von Software (mit der hier üblichen Terminologie) V6-31 V6-32 ISO 9001 Geforderte Qualitätssichernde Maßnahmen ISO 9000-1 legt kein Vorgehensmodell (Phasenmodell) fest; sie verlangt aber die Darlegung der Phasen, Ergebnisse und der jeweiligen Qualitätssicherungsmaßnahmen (Verifizierung) und sie legt einmalig oder periodisch im Unternehmen durchzuführende Maßnahmen und pro Projekt durchzuführende Maßnahmen Sie verlangt Maßnahmen zur Dokumentation der Projektabläufe ( Konfigurationsmanagement) Festlegung der Qualitätspolitik Festlegung eines mit der Qualitätspolitik Beauftragten Regelmäßige Überprüfung Einplanung der Ressourcen für die Qualitätssicherung Konfigurationsmanagement Schulung [Balzert1998] V6-33 V6-34 Geforderte Dokumente [Balzert1998] Zertifizierung nach ISO 9000 Vertrag Spezifikation Entwicklungsplan Qualitätssicherungsplan Testplan Wartungsplan Konfigurationsmanagementplan Die Erfüllung der Vorgaben wird durch Audits durch einer unabhängigen Zertifizierungstelle festgestellt. Zertifikat Danach werden regelmäßig Überwachungs- bzw. Wiederholungsaudits durchgeführt. Grund: ISO 9000-Zertifizierung ist ein Wettbewerbsvorteil V6-35 V6-36 6
Vor- und Nachteile Vorteile: Qualitätsbewußtsein (auf Geschäftsführungsebene und Mitarbeiterebene) Dokumentation der Qualitätspolitik und ihrer Umsetzung Anpassungszwang (jährliche Überwachung) Nachteile: Gefahr der Bürokratie (Dokumente um der Dokumente willen) Gefahr der Inflexibilität [Balzert1998] (2) CMM / PSP / TSP Die drei Dimensionen der Prozeßverbesserung: Capability Maturity Model: Richtlinien (Framework) für reife Entwicklungsprozesse in einem Unternehmen [Humphrey1998a] Personal Software Process: Verbesserung des individuellen Reife der einzelnen Software-Entwickler Team Software Process: Verbesserung der Reife des Teams [Humphrey1998b] [Humphrey1998c] V6-37 V6-38 Capability Maturity Model: Historie Motivation: Quantitative Managementmethoden erhöhen die Fähigkeit einer Organisation die Qualität zu kontrollieren und die Produktivität zu steigern. Das CMM wurde von W. S. Humphrey im Auftrag der U.S. Airforce entwickelt, um Software- Entwicklungsunternehmen auf die Reife ihre Entwicklungsprozesse hin zu bewerten. Später kamen dann PSP und TSP hinzu. CMM Assessment: Prinzipien Fünf Reifestufen helfen das Erreichte zu erfassen und notwendige Schritte zur Verbesserung zu bestimmen. Generisch Prozessgebiete legen das Was nicht das Wie fest, so dass CMM auf ein große Bandbreite an Organisationen angewendet werden kann: Unabhängig vom Lebenszyklusmodell Unabhängig vom Entwicklungsmethoden, Werkzeugen oder Programmiersprachen Unabhängig vom für die Dokumentation V6-39 V6-40 CMM: Fünf Reifestufen (1/5) CMM: Fünf Reifestufen (2/5) Stufe 1 (initial): Ad hoc Prozeß Chaotischer Prozeß Unkalkulierbar (Kosten, Zeit, Qualität) Software-Entwickler sind Künstler und Individualisten Stufe 2 (repeatable): Wiederholbarer Prozeß Intuitiver Prozeß (aufgrund von individueller Erfahrung) Termin-Kontrolle möglich Kosten und Qualität schwanken Informelle Vorgehensweise Prozeß von den beteiligten Software- Entwicklern abhängig V6-41 V6-42 7
CMM: Fünf Reifestufen (3/5) CMM: Fünf Reifestufen (4/5) Stufe 3 (defined): Definierter Prozeß Qualitativer Prozeß Zuverlässige Termin und Kostenplanung Verbesserte aber immer noch nicht vorhersagbare Qualität Prozeß ist unabhängig von den beteiligten Software-Entwicklern Stufe 4 (managed): Gesteuerter Prozeß Quantitativer Prozeß Kontrolle der Produktqualität (durch statistische Kontrolle) Prozeß durch Metriken überwacht V6-43 V6-44 CMM: Fünf Reifestufen (5/5) CMM: Risiko & Produktivität Stufe 5 (optimized) Stufe 5 (optimized): Optimierender Prozeß Rückkopplung der Prozeßdaten zur Optimierung Stufe 4 (managed) Stufe 3 (defined) Stufe 2 (repeatable) Risiko steigt Qualität & Produktivität steigen Stufe 1 (initial) V6-45 V6-46 Kriterien für Reifestufe Jeder Reifestufe sind Kriterien zugeordnet, die erfüllt sein müssen, um diese Reifestufe zu erlangen ISO 9000-3 vs. CMM Stufe 3 ISO 9000-3 und CMM sind nicht 100%ig vergleichbar! Sie haben verschiedene Ziele und Schwerpunkte. [Humphrey1998a] V6-47 V6-48 8
IV.6 Diskussion & Zusammenfassung (1/4) In einem Qualitätsmodell wird der der allgemeine Qualitätsbegriff wird durch Ableiten von Qualitätsmerkmale (factors) die auf mess- und bewertbaren Qualitätsindikatoren bzw. Metriken aufbauen operationalisiert. Qualitätsmanagement (QM): Es umfasst alle Maßnahmen und Tätigkeiten, Qualität zu erzeugen. Dieses sind Qualitätsplanung, die festlegt welches Teilprodukt (Dokument) wann, wie und von wem bezüglich welcher Qualitätsanforderungen überprüft werden muss, Qualitätslenkung, d.h. Arbeitstechniken und Tätigkeiten, die zur Erfüllung der Qualitätsanforderungen angewendet werden (dies sind in erster Linie konstruktive Maßnahmen) sowie Qualitätssicherung (QS), also Maßnahmen und Tätigkeiten, die Vertrauen schaffen, dass das Produkt die Qualitätsanforderungen erfüllt. Diskussion & Zusammenfassung (2/4) Analytische Qualitätsmaßnahmen untersuchen dabei das fertige Produkt, ob es bezüglich bestimmter Qualitätsmerkmale die gewünschte Stufe erreicht hat, während konstruktive Qualitätsmaßnahme dafür sorgen, dass möglichst während des Erstellungsprozesses direkt die benötigten Qualitätsmerkmale erfüllt werden Während produktorientiertes QM Qualität unmittelbar am Produkt gewährleistet ( QS) wird bei prozessorientiertem QM die Qualität des Prozesses betrachtet (Erfahrung zeigt: Rein produktorientiertes QM ist für Softwareprodukte unzweckmäßig.) V6-49 V6-50 Diskussion & Zusammenfassung (3/4) Bei Analytische Qualitätsmaßnahmen unterscheidet man zwischen Analysierende Verfahren, bei denen eine Untersuchung auf konzeptioneller Ebene ohne Ausführung der konkreten Software stattfindet, und Testende Verfahren (Dynamische Analyse), die zur Analyse die konkrete Software oder Teile davon ausführenn, um Abweichung von erwarteten Verhalten zu identifizieren. Sehr effiziente Analysierende Verfahren sind Reviews und Inspections (persönliche Review, Walkthroughs, Inspections, Formale technische Reviews, Audit, ). Bei der systematische Konstruktion von Tests wird zwischen Blackbox- Test, die nur mit Hilfe der Spezifikation entwickelt werden, und (Whitebox) Glassbox-Test, die anhand der Implementierung entwickelt/beurteilt werden, unterschieden. Tests werden auf verschiedenen Stufen durchgeführt: Abnahmetest (vom/mit Auftraggeber), Systemtest, Integrationstest oder Modultest. Diskussion & Zusammenfassung (4/4) Der Einsatz von Notationen, Methoden und Werkzeuge bei der Softwareentwicklung sowie Infrastrukturmaßnahmen wie Prozeduren und Arbeitsanweisungen, Vorlagen und Checklisten oder auch sind wesentliche Mittel des konstruktiven Qualitätsmanagements. Vorteile von sind die Anwendung des State of the Art bzgl. Methoden und Prozeduren und das resultierende bessere Verständnis/ Koordination innerhalb der Organisation, mit externern Projektbeteiligten und Kunden (Aufnahme von in den Vertrag). Eine gute Qualität eines Produktes kann besser über die Qualität des Erstellungsprozesses erreicht werden als allein über Qualitätssicherungsmaßnahmen unmittelbar am Produkt (siehe ISO 9000 Familie, CMM / PSP / TSP, SPICE project and the ISO/IEC 15504) V6-51 V6-52 IV.7 Literaturverzeichnis (1/2) [Balzert1996] [Balzert1998] [Gartner2001] [Humphrey1998a] Helmut Balzert: Lehrbuch der Software-Technik: Software-Entwicklung. Spektrum Akademischer Verlag 1996. Helmut Balzert: Lehrbuch der Software-Technik: Software-Management, Software-Qualitätssicherung, Unternehmensmodellierung. Spektrum Akademischer Verlag 1998. D. Galin, Software Quality Assurance: From theory to implementation. Harlow, England: Pearson Addison Wesley, 2004. Gartner Inc. Describing the Capability Maturity Model, Measure, Special Edition 2001, Gartner Inc. http://www.gartner.com/measurement Watts S. Humphrey. Three Dimensions of Process Improvement Part I: Process Maturity. (See http://www.stsc.hill.af.mil/crosstalk/1998/) Literaturverzeichnis (2/2) [Humphrey1998b] [Humphrey1998c] [SEMA 2003] Watts S. Humphrey. Three Dimensions of Process Improvement Part II: The Personal Process. CrossTalk: The Journal of Defense Software Engineering, March 1998. (See http://www.stsc.hill.af.mil/crosstalk/1998/) Watts S. Humphrey. Three Dimensions of Process Improvement Part III: The Team Process. CrossTalk: The Journal of Defense Software Engineering, April 1998. (See http://www.stsc.hill.af.mil/crosstalk/1998/) Software Engineering Measurement and Analysis, Process Maturity Profile: Software CMM, CBA IPI and SPA Appraisal Results, 2003 Mid-Year Update, Software Engineering Institute, Carnegie Mellon University September 2003, http://www.sei.cmu.edu/sema/pdf/sw- CMM/2003sepSwCMM.pdf. V6-53 V6-54 9
Übersicht I Einleitung II Ergänzungen zur Software-Entwicklung III Software-Management IV Software-Qualitätssicherung V Zusammenfassung Softwaretechnikpraktikum: V Zusammenfassung Jun.-Prof Prof.. Dr. Holger Giese Raum E 3.165 Tel. 60-3321 Email: hg@upb.de V6-55 Übersicht (1/2) Teildisziplinen der Softwaretechnik Software-Entwicklung: in TSE/SE + Ergänzungen Entwicklung des geplanten Softwareprodukts nur das nötigste Software-Management: Planung, Steuerung und Kontrolle des Entwicklungsprozesses Software-Qualitätssicherung: Planung und Durchführung von Maßnahmen zur Gewährleistung der geforderten Softwarequalität Softwarewartung und pflege: Beseitigung von Fehlern, die im Betrieb auftreten, Anpassung an geänderte Anforderungen nur das nötigste nur Reverse Engineering Übersicht (2/2) I II III IV V Einleitung Ergänzungen zur Software-Entwicklung Reverse Engineering, Machbarkeitsstudie Software Management Planung, Organisation, Personal/Leitung, Kontrolle (CVS!) Software Qualitätssicherung Analytisches Qualitätsmanagement, Konstruktives Qualitätsmanagement, Prozessqualität Zusammenfassung V6-57 V6-58 Lessons Learned Software-Entwicklung ist mehr als Programmierung. Es erfordert Kommunikation, Planung, Prüfung, Kontrolle,... Software-Entwicklung erfordert Management. Software-Entwicklung erfordert Qualitätssicherungsmaßnahmen. Langfristiger Software-Entwicklung erfordert Sicherung und stetige Verbesserung der Prozessqualität. Softwaretechnikpraktikum: Informationen, Aufgaben für die nächste Woche und Fragerunde V6-59 10
Ausblick (1/2) Ausblick (2/2) Entwurf Verfeinerung der Architektur Präzisieren der Klassendiagramme Design Review Implementierung & Test Implementierung Modultests (inkl. Code Walkthrough) Integrationstests Präsentation des Systems System- und Abnahmetests Turnierversion erstellen 22.7 16:00 Uhr Klausur 22.7 18:00 Uhr Turnier Auslieferung & Installation Dokumentation vervollständigen finale Installationsversion erstellen Deadline 31.8 24:00 Uhr Benachrichtigung über Fertigstellung (per Email) V6-61 V6-62 Klausur Turnier Fr, 22. Juli 2005, 16-17 Uhr, AM und C1 Fr, 22. Juli 2005, 18-20 Uhr, C1 Aufgaben Aufgabenstellung Praktische Fragen zu Versionsverwaltung Reverse Engineering Programmierung (Java) Test Reviews & Inspections Fragen zum Stoff der Vorlesung Höhepunkt des Praktikums Stunde der Wahrheit Viel Erfolg! V6-63 V6-64 Fragen? V6-65 11