Übersicht. Web (Site) Engineering (WebSE) Warum Software Engineering? Software Engineering Definition

Transkript

1 Web (Site) Engineering (WebSE) Vorlesung 10: Software Engineering B. Schiemann, P. Reiß Lehrstuhl für Informatik 8 Universität Erlangen-Nürnberg / 48 Übersicht Software Engineering Definition Motivation Probleme, Ziele Vorgehensmodelle Code-and-fix -Zyklus Wasserfallmodell Prototyping Anforderungsanalyse Problemdefinition Produktanforderungen Lastenheft Projektplan Projektstruktur- und Zeitplan Meilensteine Aufwandsschätzung Kostenplanung und Risikoanalyse Projektplanung und Pflichtenheft Bibliographie 2 / 48 Software Engineering Definition Warum Software Engineering? Die Definition von Softwaretechnik ist nicht einheitlich Zielorientierte Bereitstellung und systematische Verwendung von Prinzipien, Methoden und Werkzeugen für die arbeitsteilige, ingenieurmäßige Entwicklung und Anwendung von umfangreichen Softwaresystemen. (Lit.: Balzert, Lehrbuch der Software-Technik, S. 36) Definition wird auch von Prof. Saglietti verwendet (VO Grundl. SE) Mittel zum Softwarezweck Drei wesentliche Argumente: 1. Vermeidung von Fehlern in Software (Bugs) HW immer billiger SW immer umfangreicher und damit (als Code-Monolith ) schwer zu überblicken (seit den 1970ern) 2. Kosten Fehlerfindekosten [SWp00] 3. Komplexität Einfache Berechnungen komplexere, mit GUI und Modellierungen ausgestattete Berechnungen 3 / 48 4 / 48

2 Probleme Ziele Kommunikationsprobleme mit dem Anwender Immaterielle Natur von Software, fehlende begrenzende physikalische Gesetze Änderung der Anforderungen während Entwicklungszeit Alterung ohne Verschleiß Portabilitätsprobleme Explosion der Variantenvielfalt Verknüpfung mit/abbildung von bestehenden Arbeitsabläufen Akzeptanz beim Kunden/Anwender Effiziente Entwicklung von messbar qualitativ hochwertiger Software Korrektheit und Zuverlässigkeit Robustheit Ressourcen-Effizienz Benutzerfreundlichkeit Wartbarkeit und Wiederverwendbarkeit Andere Qualitätsfaktoren (Laufzeit,... ) Für den Benutzer sichtbar Für den Entwickler sichtbar 5 / 48 6 / 48 Code-and-fix -Zyklus Klassisches Wasserfallmodell 1. Code schreiben und übersetzen 2. Code testen bzw. debuggen 3. Code verbessern (Fehlerbeseitigung, Erweiterung, Effizienzsteigerung,... ) 4. Ggf. zurück zu 1 Erwarteter/ realisierter Funktionsumfang (Entwickler- und Anwendersicht) Starke Abhängigkeit vom einzelnen Programmierer Abnehmende Wartbarkeit und Zuverlässigkeit Vorgehensweise für kleine Projekte und Übungsaufgaben 7 / 48 8 / 48

3 Wasserfallmodell: Machbarkeitsstudie Anforderungsanalyse Aufgaben Problembeschreibung und Lösungsansätze Kosten- und Ertragsschätzung der geplanten Softwareentwicklung, Angebotserstellung Ergebnisse Lastenheft (grobe Beschreibung der Anforderungen) Projektplan samt Angebot an Auftraggeber Verfahren Richtlinien für Lastenhefte Schätzverfahren, Faustregeln Projektpläne und Projektorganisation für Termin- und Ressourcenplanung Engl. Requirements Engineering Festlegung, was die Software leisten soll Aufgaben: Festlegung der Systemeigenschaften wie Funktionalität, Leistung, Benutzungsschnittstelle, Portierbarkeit,... Bestimmung von Testfällen Festlegung erforderlicher Dokumentationsdokumente Ergebnisse: Pflichtenheft = Anforderungsanalysedokument Akzeptanztestplan Benutzerhandbuch 9 / / 48 Systementwurf Programmierung und Modultest Engl. System Design Festlegung, wie die Funktionen der Software zu realisieren sind Bauplan der Software und der Softwarearchitektur Aufgaben: Programmieren im Großen = Entwicklung eines Bauplans, Grobentwurf, Zerlegung des Systems in Teilsysteme/ Module, Auswahl bereits existierender Softwarebibliotheken, Frameworks,... Feinentwurf für Modulschnittstellen und Algorithmen Ergebnisse: Entwurfsdokument mit Softwarebauplan Detaillierte Testpläne Implementierungs- und Testphase: Realisierung und Validierung einzelner Module Aufgaben: Programmieren im Kleinen = Implementierung einzelner Module Einhaltung von Programmierrichtlinien Code-Inspektionen kritischer Modulteile Test der erstellten Module Ergebnisse: Menge realisierter Module Implementierungsberichte/-protokolle Technische Dokumentation einzelner Module 11 / / 48

4 Integration und Systemtest Auslieferung und Installation Integration einzelner Module zum Gesamtsystem Aufgaben: Systemintegration = Zusammenbau der Module In die Infrastruktur des Kunden integrieren Gesamtsystemtest durch Entwicklungsorganisation Fertigstellung der Dokumentation Ergebnisse: Fertiges System Benutzerhandbuch Technische Dokumentation Testprotokolle Inbetriebnahme der Software beim Kunden findet häufig in zwei Phasen statt Aufgaben: Auslieferung an ausgewählte Benutzer Auslieferung an alle Benutzer Schulung der Benutzer Ergebnisse: Fertiges System Akzeptanztestdokument 13 / / 48 Wartung Probleme mit dem Wasserfallmodell Engl. Maintenance Softwarewartung macht ca. 60% der gesamten Softwarekosten aus! Aufgaben: Fehlerbehebung (korrektive Wartung) Anpassungen (adaptive Wartung) Verbesserungen (perfektive Wartung) Ergebnisse: Softwareproblemberichte (Bug Reports, Bug Tracking) Softwareänderungsvorschläge Neue Softwareversionen Nur ungenaue Kosten- und Ressourcenschätzungen zu Projektbeginn Pflichtenheft vs. Umgang mit dem (spät) fertigen System (Risikomaximierung) Frühes Einfrieren der Anforderungen, notwendiger Wandel (aufgrund organisatorischer, politischer, technischer,... Änderungen) Unrealistisch strikte Phaseneinteilung (notwendige Rückgriffe) Wartung (ca. 60% des Gesamtaufwandes!) nicht detailliert genug berücksichtigt Verbesserungen angebracht 15 / / 48

5 Wasserfallmodell: Verbesserungen Zyklisches Wasserfallmodell Naheliegendste Idee zur Verbesserung des Wasserfallmodells: Einführung von Zyklen bzw. Rückgriffen, Wiederaufnehmen früherer Phasen bei Problemen Modell wird komplexer und teurer 17 / / 48 Zyklisches Wasserfallmodell II Evolutionäres Prototyping Rückkehr zu früheren Stufen schwierig Überlappung von Stufen nicht vorgesehen Detaillierte Planung notwendig Mangelnde Flexibilität Erfolgsfaktor Planung kritisch bei Unsicherheit u. Unerfahrenheit 19 / / 48

6 Evolutionäres Prototyping Vorteile: Rasche Entwicklung (durch Kunden evaluierbaren Prototyp) Keine vollständige Festlegung von Kosten und Leistungsumfang des gesamten Softwaresystems zu Beginn des Projekts Vereinfachte Projektplanung ( kleinere Teilprojekte) Probleme: Erweiterbarkeit der Systemarchitektur (durch Bindung an Prototyp) Hinfälligkeit bereits realisierter Funktionen Endresultat wie nach 10 Jahren Wartung Ewiges Kunden-Wunschkonzert Rapid Prototyping Engl. auch Throw-Away-Prototyping Realisierung und Vorführung eines Prototyps des Systems (evtl. lediglich seiner Benutzeroberfläche) mit Generatoren, ausführbaren Spezifikationssprachen, Skriptsprachen etc. Vorteile: Schnelle Klärung der Funktionalität und Risikominimierung Vermeidung von Missverständnissen zwischen Entwickler und Auftraggeber Früher Test der Benutzerschnittstelle Nachteile: Gefahr der Weiterverwendung des Prototypen (ungeplantes evolutionäres Modell) Ggf. erheblicher Mehraufwand (Vorleistung SW-Anbieters) 21 / / 48 Anforderungsanalyse Anforderungsanalyse: Techniken der Durchführung Ziele: Übersetzung einer vagen Problemvorstellung in Anforderungen Schnittstelle zur Spezifikation von Design und Umsetzung Dokumentation (Validierbarkeit) Arbeitsschritte: Ermittlung der Anforderungen Beschreibung der Anforderungen (Pflichtenheft) Analyse der Anforderungen Qualitäts- und Plausibilitätsprüfung Ermittlung von Schwächen oder Unvollständigkeiten Ergebnis: Pflichtenheft Befragungstechniken Interviews mit Benutzern Interviews mit Kontaktpersonen Sammeltechniken Wünsche von einzelnen Benutzern Fragebögen Gruppentechniken Gemeinsame Sitzungen Workshop Beobachtungstechniken In die Lehre gehen Feldbeobachtung 23 / / 48

7 Motivation Erster Bestandteil (siehe Modelle) des SE Bestimmung eines Projektzweckes: Wettbewerbsdruck (allgemein und konkret) Firmenpolitik Werbung, Selbstdarstellung, Marketing Verkauf Unterhaltung, Kundensupport Gewinnung neuer Mitarbeiter Wissensmanagement... Isolierung der Ziele Entwicklung von Lösungen Machbarkeit Voraussetzungen und Vorbedingungen: Technische Möglichkeiten ( Systemlandschaft, Buzzword: Legacies) Entwicklerteam Design-Möglichkeiten Integration der verschiedenen Ziele (Benutzersicht vs. Designersicht) Identifikation der intendierten Adressaten: Nicht beliebige Benutzer Benutzermodell Qualität statt Quantität: Nicht alle, sondern die Wichtigen! Benutzertypen/Stereotypen Allgemeiner Benutzer vs. Geschäftspartner Ingenieure vs. Manager Schüler und Studenten (d.h. Lernwillige ) vs. Freizeit- Surfer 25 / / 48 Ergebnis Rahmenbedingungen Schriftliche Definition Eine bis zwei Seiten Allgemeinverständliche Sprache (Lesbar auch für Management) Aus Kundenperspektive (Noch) keine Lösungsansätze! Keine Wunschliste mit Features Kodierung GUI (HTML, PDF,... ) Buy or build? Mögliche Erweiterungen Betriebswirtschaftliche Vorüberlegungen (Beispiel E-Commerce) 27 / / 48

8 Umgang mit Leistungsbeschreibungen Abbildung Problemstellung Ziele Kostenreduktion durch frühes Festlegen von Funktionalität (Feature Creep) Geschwindigkeitszuwachs durch detaillierte Planung Reduktion auf Sinnvolles, mögliche Argumente: Unnötig zum Erreichen des Ziele Technisch nicht machbar bzw. ökonomisch zu aufwendig Zeitliche Aspekte (Deadlines!) Verschieben (erst in späterer Version sinnvoll) Lastenheft Inhalt: Basisanforderungen ( was, nicht wie ) Adressat: Auftraggeber sowie Auftragnehmer Sprache: Verbale, ausformulierte Beschreibung Form: Übersichtliche Gliederung, prägnante Sätze in natürlicher Sprache, standardisiertes, nummeriertes Gliederungsschema Qualität: Vollständig und widerspruchsfrei Umfang: Wenige Seiten Erstellungszeitpunkt: Ausschreibungs- und Angebotsgrundlage Erstellung durch Auftraggeber Alternativ: Angebotserstellung durch Auftragnehmer (Kosten!) 29 / / 48 Projektstrukturplan Projektstrukturplan II Übersicht aller notwendigen Tätigkeiten (ggf. Teilprojekte) Graphische Darstellung der Aufgaben (z.b. Baumform) Überwachung des Projektfortschrittes Auflistung der notwendigen Aufgaben Unterteilung des Gesamtprojekts in kleinere, leichter überschaubare Aktivitäten Reduzierung der Komplexität Ermittlung von Arbeitspaketen Dokumentation Präsentationen des Gesamtprojekts Kommunikation des Projektstands Förderung des Teamentwicklungsprozesses und ganzheitlichen Denkens 31 / / 48

9 Ablauf- und Zeitplan Ablauf- und Zeitplan II Weitergehende Projektaufteilung mit der Ablauf- und Zeitplanung Aufgliederung in Arbeitspakete Ermittlung von zeitlichen, logischen und sachlichen Abhängigkeiten zwischen Arbeitspaketen Erstellung von Ablaufbeziehungen Zuordnung von Arbeitspaketen Festlegung der Terminierung der Arbeitspakete Definition von Meilensteinen Erstellung von Zeitbuffern Verwendung Projektsteuerung und -überwachung Einleiten von Maßnahmen bei Terminüberschreitung Darstellung oft als Balkendiagramm oder Netzplan Planung ausgehend vom Ende des Projekts Softwareunterstützung (z.b. MS Project) 33 / / 48 Meilensteine Aufwandsschätzung Vordefinierte Zwischenstationen im Ablauf- und Zeitplan Abschluss von wichtigen Projektschritten Entscheidung über den weiteren Projektfortgang Bindung an eindeutige Ereignisse Bestandteile Name Verantwortlicher Termin für die Erbringung der Ergebnisse Festgelegte Ergebnisse (z.b. Dokumente, Prototypen, Entscheidungen) Basis: Arbeitspakete, die separat betrachtet werden Abschätzen der Arbeitsmenge (Erfahrungswerte) Mitarbeiterverteilung Ableitung der Termine für den Zeitplan Mögliche Fehler Falsche Aufwandsschätzungen bei neuen Themen Verwechslung: Aufwand und Dauer (äußere Einflüsse) Planung unter Druck unrealistische Terminpläne Nichtberücksichtigung von Aufwand: Projektmanagement, Qualitätssicherung, nicht aufgeführte Aufgaben 35 / / 48

10 Kostenplanung Kostenplanung II Maß für Personalaufwand: Mitarbeitermonate (MM) oder Mitarbeiterjahre (MJ) (syn. Mannjahre) 1 MJ entspricht 10 MM (Urlaub, Krankheit) Kostenarten: 1. Personalkosten (Verrechnungssatz, Zeit) 2. Materialkosten (Verbrauchsmaterialien) 3. Gerätekosten (anteilige Anschaffungskosten) 4. Sonstige Kosten (z.b. Reisekosten, externe Dienstleistungen) Verfahren Analogiemethode: Vergleich mit abgeschlossenen ähnlichen Projekten Gewichtungsmethode: Ermittlung durch eine Vielzahl von Faktoren (Erfahrung der Mitarbeiter, verwendete Sprachen) Vgl. Kostenplanung (BWL) Einfachere Faustregeln Analysephase: 20% Entwurfsphase: 20% Codierung: 30% Test: 25% Projektmanagement 5% 37 / / 48 Risikoanalyse Projektplanung und -organisation Ermittlung von Gefahren für den Projekterfolg Brainstorming Konservierung der Erfahrungen in Checklisten Typische Projektrisiken Ausfall von wichtigen Mitarbeitern Nichteinhaltung zugesagter Termine Äußere Faktoren Fehlende Akzeptanz bei den potenziellen Nutzern Zu optimistische Planung Unklare Definition der Projektrolle, Kompetenzkonflikte Persönliche Konflikte zwischen Teammitgliedern Erstellung von Notfallplänen Fortlaufender Prozess Grober Plan zu Projektbeginn, sukzessive Verfeinerung Heuristische Methoden Unterschiedliche Lebensdauer von Applikationen Häufig: kleine Teilprojekte (weniger als ein Jahr!) Projektmanagement (!) 39 / / 48

11 Pflichtenheft: Definition Pflichtenheft: Zentrale Rolle Schnittstelle zwischen Anforderungsanalyse und Systementwurf Definition Pflichtenheft (nach DIN): Eine ausführliche Beschreibung der Leistungen (z.b. technische, wirtschaftliche, organisatorische Leistungen), die erforderlich sind oder gefordert werden, um die Ziele des Projekts zu erreichen. Grundlage für den ersten Entwurf Vereinbarung zwischen Kunde und Auftragnehmer Bestandteil des Vertrags zwischen Auftraggeber und Entwickler Grundlage für die Beurteilung der Leistungserfüllung Grundlage für Kosten- und Zeitschätzungen Objektives Kriterium für Validierung und Abnahme Klärung bei Diskrepanzen zwischen Kunde und Auftragnehmer Leider häufig unvollständig Modifikationen, Erweiterungen zur Projektlaufzeit nötig 41 / / 48 Pflichtenheft: Spezifikation Pflichtenheft: Beispielhafter Aufbau Erfolgsfaktoren, Durchführbarkeitsanalyse, Kosten-Nutzenanalyse Angestrebte Verbesserungen der wirtschaftlichen und technischen Ziele Funktionalität, Leistungsmerkmale, Qualität Schnittstellen (Benutzerschnittstellen, Dialogkonzept) Performanz Inhalt Einzuhaltende Standards Anforderungen ans Design (z.b. Stylevorgaben) Rechtliche, Technische Vorgaben 1. Zielbestimmung Muss-Kriterien: Was muss das Produkt leisten? Wunschkriterien: Was soll das Produkt evtl. noch leisten? Abgrenzungskriterien: Was soll das Produkt nicht leisten? 2. Produkt-Einsatz definiert Anwendungsbereiche (wofür), Zielgruppen (für wen) und Betriebsbedingungen (z. B. physikalische Umgebung, Betriebszeiten,... ) 3. Produkt-Umgebung: Software, Hardware, Produkt-Schnittstellen (Betriebssystem, Rechner, Peripherie, organisatorische Voraussetzungen, z.b. Mail-Anschluss, Integration in bestehende Anwendungen) 4. Produkt-Funktionen Abstrakte Funktionalität aus Benutzersicht Textuelles Gliederungsschema 43 / / 48

12 Pflichtenheft: Beispielhafter Aufbau II Pflichtenheft: Eigenschaften 1. Produkt-Daten Beschreibung langfristig zu speichernder Daten aus Benutzersicht Funktionsbaum 2. Produkt-Leistungen: Zeit, Umfang, Benutzerzahl, Genauigkeit, Benutzungsoberfläche 4. Qualitäts-Zielbestimmung (vgl. Lastenheft) 5. Globale Testszenarien und Testfälle (Abnahmetest!) 6. Entwicklungsumgebung 7. Ergänzungen 8. Glossar, Begriffslexikon Eindeutigkeit Vollständigkeit Verifizierbarkeit Konsistenz Modifizierbarkeit Nachvollziehbarkeit Nutzbarkeit Detailliertheit 45 / / 48 Zusammenfassung Software Engineering Definition Motivation Probleme, Ziele Vorgehensmodelle Code-and-fix -Zyklus Wasserfallmodell Prototyping Anforderungsanalyse Problemdefinition Produktanforderungen Lastenheft Projektplan Projektstruktur- und Zeitplan Meilensteine Aufwandsschätzung Kostenplanung und Risikoanalyse Projektplanung und Pflichtenheft Bibliographie 47 / 48 Vielen Dank Für Ihre Aufmerksamkeit! Fragen? 48 / 48

13 Software-Pruefung : eine Anleitung zum Test und zur Inspektion. vdf Hochschulverlag, / 48