Web (Site) Engineering (WebSE)

Web (Site) Engineering (WebSE) Vorlesung 10: Spezifikation, Implementierung, Testen und Wartung B. Schiemann, P. Reiß Lehrstuhl für Informatik 8 Univ...
Author: Helge Frei
0 downloads 0 Views 172KB Size
Web (Site) Engineering (WebSE) Vorlesung 10: Spezifikation, Implementierung, Testen und Wartung

B. Schiemann, P. Reiß Lehrstuhl für Informatik 8 Universität Erlangen-Nürnberg

10.01.2006

1 / 48

Übersicht Spezifikation bis Systementwurf Formale, Modellorientierte, Informale Spezifikation Tools Systementwurf Implementierung Programmierung, Systemintegration Validierung Testen und Post-Development Testprozess Testüberblick Testfehler Post-Development

2 / 48

Modellierung

1. Modellausrichtung: Was soll modelliert werden? I I

Systembestandteil Systembewertung

2. Systemart: Was soll vom System geleistet werden? I I I I

Konferenz Kooperation Kommunikation Konsultation

3. Modellierungstechnik (strukturell, operationell, informell)

3 / 48

Modellierung II

Modellierungsform 1. Formale Spezifikation (nach DRESSLER) I I I I

Vor- und Nachbedingungen Modellorientierte Spezifikation Algebraische Spezifikation Spezifikation mit Prädikaten und Regeln

2. „Direkte“, informale Spezifikation (nach ZELLER) I I

Hilfsmittel, Tools Systeme

4 / 48

Formale Spezifikation: Vor- und Nachbedingungen

I

„Klassisches“ Spezifikationsverfahren

I

Grundannahme: Funktionen verändern Programmzustand

I

D.h. Voraussetzungen und Effekte

I

Vorbedingungen: Eingabeparameter und Programmzustand

I

Nachbedingungen: Ausgabeparameter und Programmzustand Zusätzlich: Erinnerung/Querverbindungen, d.h.

I

I I

TI II: Schleifen-Invarianten KI I: Klassisches Planen

5 / 48

Modellorientierte Spezifikation

I

Standardisierte Sprache auf hohem Abstraktionsniveau −→ entsprechend hohe Anforderungen an Entwickler

I

Methodik zur Erstellung korrekter Software

I

Prädikatenlogik kann zur Modellierung benützt werden −→ Einsatz von Beweissystemen zum automatischen Ableiten von Eigenschaften der Spezifikation

I

Gute Lehrbücher und Werkzeuge verfügbar

I

Rapid Prototyping durch Codegenerierung möglich

6 / 48

Informale Spezifikation: UML-Diagramme

I

Use-Case-Diagramm für Kommunikationsstrukturen

I

Sequenzdiagramm für Kommunikationsinhalte (AGE.prot.pdf)

I

Objektdiagramm für zeit-unabhängigen Bezug der beteiligten Systemkomponenten Darüber hinaus

I

I I

Storyboards für multimediale Systeme Tools zur Modellierung (für Web-CASE, -Messsysteme, -Standards, -Erfahrungen, -Community)

7 / 48

Tools zur Spezifikation

I

Programme, die formalisierte Entwicklungsschritte selbständig durchführen

I

Stark spezialisiert (z.B. auf Generierung von Formularen)

I

Mit konkretem Ergebnis (z.B. ablauffähiges Programm)

I

Oft als „Rendering Engine“ im Hintergrund von grafischen Entwicklungsumgebungen (z.B. IBM RationalRose) Szenarien

I

I I

Programmgeneratoren Grafik-Editoren

8 / 48

Systementwurf (System Design) Definition: I

Festlegung, wie die Funktionen der Software zu realisieren sind

I

Festlegung der Softwarearchitektur

Aufgaben: I

I

„Programmieren im Großen“ = Entwicklung eines Bauplans Fachlicher und technischer Grob- und Feinentwurf I

I

Komponenten, Klassen, Modulstruktur, Schnittstellen, Algorithmen, Datenmodell Auswahl bereits existierender Softwarebibliotheken, Frameworks, . . .

9 / 48

Systementwurf (System Design) II

Ergebnisse: I

Beschreibung des Systementwurfs mit Softwarebauplan (Spezifikation)

I

Detaillierte Testpläne

Phasen: 1. Fachlicher Feinentwurf 2. Technischer Grobentwurf 3. Technischer Feinentwurf

10 / 48

Entwurfsphase: Fachlicher Feinentwurf

I

Verfeinerung der rein sprachlichen Funktionsbeschreibung des Pflichtenhefts

I

Abbildung verbale Beschreibung −→ Pseudocode Aber: Pseudocode ineffizient, deshalb besser in der Zielsprache direkt (unter Verwendung von Kommentaren) (Triviales) Beispiel:

I

I

I

Pflichtenheft: „Der Verkaufspreis ist in DM und EURO aufzuführen.“ Entwurf: Angabe der Umrechnungsformel DM −→ EURO durch Pseudocode

11 / 48

Entwurfsphase: Technischer Grobentwurf Systemarchitektur für Web-Applikationen I

Hardwareplattform als Basis; häufig Client/Server

I

Steuersystem, Teilsysteme (Module), Dienstleistungssysteme (Web-Server, DB-Server, Applikationsserver, . . . )

I

Datenmodell: Datenorganisation, Datenstrukturen, Datenbankschema 3 Tier Architektur:

I

I I

I

Client Tier: Darstellung, Benutzerschnittstelle Web & Business Tier: Verarbeitung, Ablaufkontrolle, Zustellung Backend Tier: Datenhaltung (Datenbank mit Zugriffsfunktionen)

12 / 48

Entwurfsphase 3: Technischer Feinentwurf

I

Ablaufstruktur und Datenstrukturen im Detail

I

Modulbeschreibung, Schnittstellenbeschreibung

I

Datenmodell

Ergebnis: I

Pseudocode

I

Sequenzdiagramme

I

Zustands-Übergangs-Diagramme

I

(E.) Entity-Relationship-Diagramme

I

Klassendiagramme

13 / 48

Methoden zum technischen Feinentwurf

1. Datenorientierter Ansatz I I

Datenmodell im Mittelpunkt des Entwurfs Beispiele: JACKSON, WARNIER

2. Objektorientierter Ansatz I I I

Objekt im Mittelpunkt des Entwurfs Objekte bestehen aus Daten und Methoden Beispiele: BOOCH, JOHNSON, UML

14 / 48

Systementwurf: Architektur

I

Entwurfstechniken: I I

I I

Top-down (s.o.) vs. Bottom-up Hardest-first

Architekturstruktur beinhaltet Komponenten Entwurfsparadigmen: I I I

Imperativ Applikativ Objektorientiert

15 / 48

Systementwurf: Architektur II

I

Architekturstruktur I I I

I

Akquisition Neu- bzw. Eigenentwicklung Re-Use (auch bei Komponenten)

Entwurfstest I I

Verifikation Code-Reviews

16 / 48

Implementierung

I

Klassischer Hauptbestandteil bei der Software-Entwicklung, aber durch die formalen Methoden beim (Web)SE nun weniger zentral!

I

Umsetzung des Entwurfs in ein lauffähiges Programm

I

Einsatz formaler Verfahren auch beim Programmieren

I

Einsatz von „höheren Programmiersprachen“

I

Aufteilung in Modulimplementation und Systemintegration

17 / 48

Programmierung und Modultest

Aufgaben: I

„Programmieren im Kleinen“ = Implementierung der einzelnen Module

I

Code-Inspektion kritischer Modulteile

I

Test der erstellten Module

Ergebnisse: I

Realisierte Module

I

Technische Dokumentation der Module

I

Implementierungs- und Testprotokolle der Module

18 / 48

Integration und Systemtest Integration einzelner Module zum Gesamtsystem Aufgaben: I

Systemintegration = Zusammenbau der Module

I

Gesamtsystemtest durch Entwicklungsorganisation

I

Fertigstellen der Dokumentation

Ergebnisse I

Fertiges System („Version 1.0“)

I

Benutzerhandbuch

I

Technische Dokumentation u.a. Testprotokolle des Gesamtsystems

19 / 48

Implementierung: Programmierrichtlinien

I

Hierarchischer Programmaufbau

I

Strukturiert auch in der Feinstruktur

I

Aussagefähige Bezeichner: Konvention durchhalten!

I

Kommentare („selbsterklärenden“ Code gibt es nicht!)

I

Warnungen des Compilers nicht ignorieren

I

Code lesen und Inspektion sind effektiver als nachträgliche Tests

20 / 48

Implementierung von Web Sites

I

Ausgereifte Verfahren/Tools I

I

I

Templates führen zu konsistentem Layout Problem: Indizierung durch Suchmaschinen erhalten! Link-Checker zur Vermeidung von „Sackgassen“und „Waisenkindern“

Ursachen für schlechtes Design und Implementierung I

I I I

Inhärente Komplexität und Heterogenität verwendeter Software Komplexität von Web-Projekten Zeitconstraints Adressaten (heterogen und unkontrollierbar)

21 / 48

Validierung

I

„Bauen wir das richtige Produkt“ ?

I

Das Produkt muss die Anforderungen des Benutzers erfüllen Methoden:

I

I

I

I

I

Usability Inspections früh im Entwicklungsprozess (Prototyp!) „Heuristische Evaluierung“: Usability-Experten mit Checklisten Usability Testing: (Naive) Versuchspersonen, die „laut denken“(!) sollen Requirements Management Tools bereits ab der Anforderungsdefinition

22 / 48

Programmverifikation

I I

„Bauen wir das Produkt richtig“ ? Sicherstellung des korrekten Programmablaufs I I

Ein-/Ausgabeverhalten Terminierung

I

Nur mit formaler Spezifikation und Codegenerierung vollständig durchführbar

I

Aus Sourcecode ohne Spezifikation unmöglich

I

Besser: Testen

23 / 48

Qualitätsmerkmale — Metriken für Tests

I

Zuverlässigkeit

I

Wiederherstellbarkeit (Absturz, Neuinstallation)

I

Sicherheit

I

Performanz (Antwortzeiten, Lastverhalten)

I

Begreifbarkeit

I

Erlernbarkeit

I

Ergonomie

I

Barrierefreiheit

24 / 48

Aufgaben im Testprozess

1. Planung oder Auswahl der Tests 2. Vorbereitung der Tests 3. Organisation der Ressourcen 4. Messung von Charakteristika 5. Ermittlung der Unterschiede zwischen Ist- und Sollzustand 6. Entdeckung von Fehlern 7. Dokumentation der Fehler (im Kontext) 8. Schätzung/Bewertung der Zuverlässigkeit

25 / 48

V-Modell für Web (Site) Engineering

26 / 48

Idealer Test- und Entwicklungszusammenhang

27 / 48

Arten von Tests: Überblick

Testtypen: I

Funktionstests

I

Inhaltstests

I

Benutzbarkeitstests

I

Automatisches vs. manuelles Testen

28 / 48

Funktionstests

I

Überprüfung der Funktion entsprechend der Spezifikation

I

Entwicklung von Testfällen

I

Separates Testen von Untereinheiten wie Pages, Java-Applets, Formulare, JavaScript-Funktionen, Vermeidung von syntaktischen und logischen Fehlern

I

Integrationstest Interaktion und Zusammenspiel der verschiedenen Einheiten

I

Systemtest Test des Gesamtsystems

29 / 48

Inhaltstests

Review bei Technischer Redaktion I

Inhaltliche Richtigkeit

I

Vollständigkeit

I

Rechtschreibung

I

Grammatik

I

Copyrights

I

Typographie

I

Graphisches Design

I

...

30 / 48

Benutzbarkeitstests

I

Benutzbarkeit (nach J. NIELSEN) I I I I I

I

Leichte Erlernbarkeit Effizienz Einprägbarkeit Fehlertoleranz und -erkennung Angenehme Bedienbarkeit (Ergonomie)

Referenz: „Dümmster anzunehmender Kunde“, nicht die Entwickler

31 / 48

Teststrategien

I

Walkthroughs und Inspections Direkt am Code

I

White Box Testing Black Box Testing

I

I

I

I

Voraussetzungen: Funktionale Beschreibung, Qualitätsanforderungen Überprüfen der beabsichtigten Funktionalität

Re-Testing (Regression Testing)

32 / 48

Testfehler - allgemein

I

Tester für Qualität verantwortlich machen

I

Zukünftigen Testaufwand von bestehender Fehlerzahl abhängig machen

I

Fehlende Fehlerdokumentation: Keine Beschreibung des Fehlerkontextes

I

Verspäteter Testbeginn: nur Fehlerreduktion statt Fehlervermeidung

I

Versuch, alle Tests zu automatisieren

33 / 48

Testfehler in der Planung

I

Falsche Gewichtung der Risikofelder

I

Suche nach weniger relevanten Fehlern

I

Hohe Gewichtung der Funktionstests Vernachlässigung von:

I

I I I

I

. . . Dokumentation . . . Installation . . . Stress Testing und Load Testing

Verlassen auf Beta-Tests

34 / 48

Post-Development — Wartung

I I

Ausgangspunkt: Site ist fertig im Netz Wie bei klassischem SE: Entwicklung nicht beendet I I

I

Feedback Wartung

Ausführung im: I I

Spiralenmodell für kleinere Änderungen Wasserfall für größere Änderungen

35 / 48

Feedback

I

Muss entsprechend vorbereitet sein

I

Sobald Site im Netz verfügbar und auffindbar

I

Benutzer melden Fehler und machen Verbesserungsvorschläge: Diskussionsforen, Mailformulare, ...

I

Strukturiertes Vorgehen zum Einsammeln und Verwenden erforderlich

36 / 48

Direktes Feedback

I

Feedback institutionalisieren und fördern I I I I

Formulare mit Kommentaren Generische E-Mail-Adresse Befragungen und Studien Intranet (Kunden) vs. Extranet (Benutzer)

I

Mehrheitsentscheidungen akzeptieren

I

Machbarkeit überprüfen!

37 / 48

Indirektes Feedback

I

Terminologie: Hits, Views, Visits

I

Statistiken führen und auswerten Logfiles überprüfen und interpretieren

I

I I I

I

Access Log Error Log Software zur Analyse von Logfiles verwenden

Tipp: Interpretation und Extrapolation nicht übertreiben!

38 / 48

Wartung

I

Web-Applikation als „lebendiges Wesen“

I

Content-Management-Systeme und Communities, Foren, Boards leben von Benutzeränderungen → Wartung nicht nur technisch, sondern als Redaktionsprozess

I

Vorschläge von Kunden und Nutzern aufgreifen und einarbeiten

39 / 48

Wartung: Kosten

I

50% der Programmierkosten einer Firma

I

70% der Kosten eines SW-Produkts

I

Wartung doppelt so fehleranfällig wie Neucodieren

I

Exponentionelle Kostensteigerung mit System-Lebensdauer bei schlechter Strukturierung

I

Bei WebSE ist Wartung statistisch häufiger durchzuführen

40 / 48

Wartung: Einflussgrößen

I

Technisch I I I I

I

Programmiersprache Markup-Sprache Struktur der Site und der Seiten Programmier-/Markup-Stil

Nicht-Technisch I I I I

Vertrautheit mit der Site Qualität des Entwicklers Kommunikation Dokumentation

41 / 48

Wartung: Durchführung

I

Individuelle Änderungen: Spiralmodell

I

Größere Änderungen: Wasserfallmodell Qualitative und quantitative Unterschiede

I

I

I I

Statische Seiten: Periodische Überprüfung und Updates von Inhalt und externen Links Zeitkritische Seiten: Tägliche, ggf. stündliche Updates Dynamische Seiten: Server-Aktivität und Performanz überprüfen

−→ Engineering-Ansatz in jedem Fall nötig

42 / 48

Wartung des Inhalts: Was, wer, wie?

I

Manuell oder automatisch?

I

In-House oder Outsourcing?

I

Redaktionelle Aufbereitung, Coding und Posting

I

Zentrale Instanz (Webmaster) oder Arbeitsgruppe?

I

Feste Termine für Änderungen

I

Guidelines für Updates (Kommentare, Filenamen)

I

Niemals online ändern! Staging Mirror Site

I

I I

Offline-Plattform für Änderungen und Tests Backup für Online-Version

43 / 48

Wartung der Funktionalität

I

Korrektiv, adaptiv, perfektiv

I

Wenig vorhersagbar: Krisenmanagement Automatische Überwachung mit Tools

I

I I I I I

Interne Konsistenz von Links Falsche Links, Broken Links Fehlende Tags Seitengröße Simulation der Benutzung: Senden von (auch fehlerhaften!) Testdaten an Formulare

−→ vgl. Testen!

44 / 48

Wartung der Auslieferung

I

Traffic überwachen

I

Bandbreite und Serverzahl anpassen

I

Internes Netz anpassen oder outsourcen

I

Mirrors oder verteilte Hosts

I

HW- und OS-Upgrades

I

Upgrades von Server-SW und Middleware

45 / 48

Zusammenfassung Spezifikation bis Systementwurf Formale, Modellorientierte, Informale Spezifikation Tools Systementwurf Implementierung Programmierung, Systemintegration Validierung Testen und Post-Development Testprozess Testüberblick Testfehler Post-Development

46 / 48

Nächste Woche:

Gastvortrag: G. Held, TOP-IT Services I

17:00 - 18:30

I

Raum 00.152

47 / 48

Vielen Dank

I

Für Ihre Aufmerksamkeit!

I

Fragen?

48 / 48

Literatur & Links III I

Nguyen, Hung Q. Testing Web-Based Applications, Analyzing and reproducing errors in web environment. www.stickyminds.com/

I

VeriTest Services: www.veritest.com/

I

Bazzana, G.; Fagnoni, E. Testing web-based applications. www.guideitalia.org/documenti/280901roma02.pdf

I

Sobey, A.J. Software Testing. louisa.levels.unisa.edu.au/se1/testing-notes/testing.htm

I

Bowers, Neil. Weblint: Quality Assurance for the World-Wide Web. www.weblint.org/www5-paper.html

I

Chak, Andrew. Usability Tools: A Useful Start. www.webtechniques.com/archives/2000/08/stratrevu/

49 / 48