Softwaretechnik- Praktikum: 5. Vorlesung

Transkript

1 Softwaretechnik- Praktikum: 5. Vorlesung Jun.-Prof Prof.. Dr. Holger Giese Raum E Tel hg@upb.de

2 Übersicht I Einleitung II Ergänzungen zur Software-Entwicklung III Software Management IV Software Qualitätssicherung V Zusammenfassung V5-2

3 Softwaretechnikpraktikum: II Ergänzungen zur Software-Entwicklung Jun.-Prof Prof.. Dr. Holger Giese Raum E Tel hg@upb.de

4 Typen von Softwareprojekten Neuentwicklung (Engl. Greenfield Engineering ) Die Entwicklung beginnt ganz von vorne und es muss kein existierendes System berücksichtigt werden (heute eher seltener der Fall) Reengineering Überarbeitung oder Neuimplementierung eines bestehenden Systems ausgelöst durch technischen Fortschritt oder durch neue Anforderungen. Schnittstellenüberarbeitung (Engl. Interface Engineering ) Neugestaltung der Schnittstelle eines vorhandenen Systems, insbesondere der Benutzerschnittstelle. V5-4

5 Legacy Systeme Softwaresysteme, die speziell für eine Organisation entwickelt wurden, haben häufig eine lange Lebensdauer, wurden mit inzwischen obsoleten Technologien entwickelt und sind für den wirtschaftlichen Betrieb der Organisation kritisch. Leider ist die Dokumentation solcher Systeme (falls überhaupt vorhanden) in der Regel nicht konsistent mit der Implementierung Large software systems that we don't know how to cope with but that are vital to our organization [Bennett1995] Keith Bennett, Legacy Systems: Coping With Success", IEEE Software 12(1):19-23, 1995 Wir werden im SWTPRA nicht nur die Neuentwicklung sondern das Reengineering eines existierenden Systems betrachten V5-5

6 II Ergänzungen zur Software- Entwicklung & Vorgriff II.1 Machbarkeitsstudie II.2 Versions- und Konfigurationsmanagement II.3 Reviewtechniken II.4 Testtechniken II.5 Reverse Engineering II.6 Diskussion & Zusammenfassung II.7 Literaturhinweise V5-6

7 II.5 Reverse Engineering Beobachtung: Software wird heute nicht mehr isoliert eingesetzt, sondern muss mit anderer Software interagieren Oft muß bestehende Software weiterentwickelt werden (Legacy Systeme) Die bestehende Software ist meist schlecht oder gar nicht dokumentiert Problem: Bevor man bestehende Software nutzen oder ändern kann, muss man sie verstehen V5-7

8 Aber Anforderungsdefinition, Analysedokument, Entwurfsdokument und Benutzerhandbücher sind häufig nicht vorhanden, nicht konsistent mit der Implementierung und unvollständig. fehlende Information muss erstmal ermittelt werden aus den vorhandenen Artefakten (häufig nur das binäre, ausführbare Programm oder der Quellcode!) V5-8

9 Was ist Reverse Engineering? [Chikofsky&Cross1990] E. J. Chikofsky and J. H. Cross, Reverse Engineering and Design Recovery: A Taxonomy IEEE Software, vol. 7, pp , Jan./Feb V5-9

10 Definition Unter Reverse-Engineering versteht man den Prozeß, die einem fertigen (und meist schlecht dokumentierten) Softwaresystem zugrundeliegenden Ideen und Konzepte aufzuspüren und zu dokumentieren Der Entwicklungsprozeß wird gewissermaßen rückwärts durchlaufen. V5-10

11 Ergebnis Das Ergebnis des Reverse-Engineering ist (im Idealfall) eine Spezifikation des Softwaresystems Bemerkung: Wir wollen im SOPRA nur soweit das System verstehen, dass die geforderten Erweiterungen sinnvoll integriert werden können. Wichtig: Überblick gewinnen und dokumentieren Abstraktion und Konzentration auf das Wesentliche Fokus auf das für die Aufgabe wichtige V5-11

12 Werkzeuge Werkzeuge können das Reverse-Engineering unterstützen! Aber sie können uns das Abstrahieren und die Auswahl des Wesentlichen nicht abnehmen. Dies ist die Aufgabe des Entwicklers. Leider liefern heutige Werkzeuge oft falsche Ergebnisse. Die müssen von Hand korrigiert werden. V5-12

13 Autom. generierte Diagramme Oft keine Kardinalitäten und Rollen müssen manuell hinzugefügt werden Attribute und Assoziationen redundant sollten von Hand beseitigt werden Wichtige und unwichtige Informationen werden extrahiert V5-13

14 Klassendiagramm V5-14

15 Manuelle Abstraktion Unwesentliche Informationen sollten beseitigt werden Viele Klassen mit vielen Details (Alle Informationen kann nur auf einer A3 bis A1 Seite gut lesbar ausgedruckt werden) muss auf verschiedene Diagramme aufgeteilt werden V5-15

16 Klassendiagramm V5-16

17 Weitere Dokumentationen Wichtigen Schnittstellen sollten durch geeignete Verhaltensdiagramme dokumentiert werden Manche Informationen lassen sich besser in Form von Tabellen darstellen Diagramme allein reichen nicht aus! V5-17

18 II.6 Diskussion & Zusammenfassung (1/5) Die Machbarkeitsstudie führt zur Auswahl des Produktes, dessen Voruntersuchung sowie einer technischen, organisatorischen und ökonomischen Durchführbarkeitsuntersuchung. stop or go Alle Verfahren für die Aufwandsschätzung erfordern Erfahrung und/oder Aufwandsdaten aus vorangegangenen Softwareprojekten (in ähnlichem Anwendungsgebiet, mit ähnlichen Entwicklungsmethoden und mit ähnlicher Firmenkultur, da sonst die Hypothese mit der konstanten Produktivität, die fast allen Verfahren zugrunde liegt, nicht stimmt). V5-18

19 Diskussion & Zusammenfassung (2/5) Die Machbarkeitsstudie umfasst ein Lastenheft, eine Aufwandsschätzung sowie einen Projektplan. Für typische Softwareprojekte (große und verteilt arbeitende Teams) haben sich Versions- und Konfigurationsmanagement Ansätze, die optimistischen Konsistenzmechanismen einsetzte, als zweckmäßiger erwiesen, da das gleichzeitiges Arbeiten am selben Dokument möglich ist und In Kombination mit Verantwortlichkeiten und Zuständigkeiten Konflikte selten und meist einfach zu beheben sind. V5-19

20 Diskussion & Zusammenfassung (3/5) Reviewtechniken wie (persönliche Reviews,) Walkthroughs, Inspections und formale technische Reviews sind sehr effektive und effiziente Low Tech Techniken, die leider in der Praxis (und der Universität) viel zu wenig genutzt werden. Neben der hohen Effizienz ist es ein wesentlicher Vorteil der Reviewtechniken, dass diese schon frühzeitig eingesetzt werden können, wenn noch keine Implementierung für Tests verfügbar ist. V5-20

21 Diskussion & Zusammenfassung (4/5) Die systematische Konstruktion der Tests kann bei Blackbox-Test mit Hilfe der Spezifikation erfolgen (ohne die Implementierung zu kennen). Beim (Whitebox) Glassbox-Test dagegen werden die Tests anhand der Implementierung abgeleitet. Selbst bei 100%iger Überdeckung durch aufwendigere Formen der Bedingungs- oder Pfadüberdeckung finden die Glassbox-Tests nicht immer alle Fehler. Trotzdem liefert der Kriterium und der Grad der Überdeckung ein gewisses Zutrauen in die Richtigkeit (Qualitätsmerkmal) des Produktes. V5-21

22 Diskussion & Zusammenfassung (5/5) Tests können auf den verschiedenen Stufen des V-Prozesses durchgeführt werden: Abnahmetest (vom/mit Auftraggeber), Systemtest, Integrationstest und Modultest. Unter Reverse-Engineering versteht man den Prozess, die einem fertigen (und meist schlecht dokumentierten) Softwaresystem zugrunde liegenden Ideen und Konzepte aufzuspüren und zu dokumentieren (dabei wird der Entwicklungsprozess gewissermaßen rückwärts durchlaufen). V5-22

23 II.7 Literaturverzeichnis [Balzert1996] Helmut Balzert: Lehrbuch der Software-Technik: Software- Entwicklung. Spektrum Akademischer Verlag [Balzert1998] Helmut Balzert: Lehrbuch der Software-Technik: Software- Management, Software- Qualitätssicherung, Unternehmensmodellierung. Spektrum Akademischer Verlag V5-23

24 Softwaretechnikpraktikum: Aktuelle Aufgaben und Fragerunde

25 Wiederholung: Testen Fragen: keine Konsequenz: kurzer Bericht des Verantwortlichen per bis Mo. 23:59 Uhr wird ab jetzt Pflicht! V5-25

26 Wiederholung: Prototyp Auftraggeber/Endbenutzer formuliert Anforderungen des Systems nicht explizit/vollständig genug Manche Anforderungen haben unterschiedliche Lösungsmöglichkeiten Fertiges Produkt Auftraggeber präsentieren, ohne Zwischenpräsentationen Prototyp Wahrscheinlichkeit groß, dass entwickeltes System von den tatsächlichen Anforderungen des Auftragsgebers abweicht Relevante Anforderungen oder Entwicklungsprobleme klären Experimentell erproben und mit Auftraggeber diskutieren Diskussionsbasis und helfen bei Entscheidungen Experimentieren und sammeln von praktischen Erfahrungen V5-26

27 Aufgabe: Pflichtenheft Nur für den Simulationsalgorithmus! Zusammenhängende Darstellung aller fachlichen Anforderungen an das Produkt (Sicht des Benutzers). Es sollte beschrieben, was das Produkt leisten sollte, nicht wie es das leistet Bemerkungen: Umfang: Simulationsalgorithmus: max. 10 Seiten Reuse des Lastenhefts! V5-27

28 Aufgaben: Reverse Engineering Reverse Engineering Code des erworbenen Plugins analysieren Das erworbene Plugin ausprobieren Dokumentation für das erworbene Plugin evaluieren Hilfen im WWW: Hinweise zum Reverse Engineering (Anhand des Beispiels aus der Vorlesung) Vorgaben für das Reverse-Engineering (Anleitung zur Erstellung des internen Dokuments) Aufgabe: Ende Mai Vorbereitung durch den Verantwortlichen: jetzt! Tutorium: nächste Woche V5-28

29 Hinweis Heute 15 Uhr ct Tutorial zu Testtechniken (E3.327) Programmierberatung wöchentlich Mittwochs Uhr ct in E3.327 V5-29

30 Fragen? V5-30