Probleme bei der Erstellung von Software Ziele von Software Engineering

Transkript

1 Software Engineering : Definition Software Engineering Web Site Engineering in der Theorie: Der 4. Streich Entwicklung, Pflege und Einsatz qualitativ hochwertiger Software unter Einsatz von wissenschaftlichen Methoden, wirtschaftlichen Prinzipien, geplanten Vorgehensmodellen, Werkzeugen und quantifizierbaren Zielen [nach KAHLBRANDT] 2 Softwarekatastrophen Softwarekrise On June 4, 1996, on its maiden flight, the Ariane-5 was launched and performed perfectly for approximately 40 seconds. Then it began to veer off course. At the direction of the Ariane ground controller, the rocket was destroyed by remote control. total cost of the disaster was $500 million. [PFLEEGER. Software Engineering - Theory and Practice, S. 37] Fehler: Real-Integer-Konvertierung (!) Ausgangspunkt Zunehmende Komplexität bei Programmsystemen in den 60er Jahren Keine geeigneten (Programmier-)Sprachen Methoden/Vorgehensweisen Werkzeuge Folgen Kontinuierlicher Anstieg der Software-Kosten (vgl. Hardware!) Scheitern vieler Softwareentwicklungsprojekte Viele Fehler sind Software-Fehler! (vgl. Ansatz: Ingenieurwissenschaft und wohldef. Vorgehen statt kreativer Kunst 3 4 Probleme bei der Erstellung von Software Ziele von Software Engineering Kommunikationsprobleme mit dem Anwender Immaterielle Natur von Software, fehlende begrenzende physikalische Gesetze schwierige Modellbildung Leichte Modifizierbarkeit von Software Ä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 Mangel an Standards, Methoden und Werkzeugen Effiziente Entwicklung von messbar qualitativ hochwertiger Software Korrektheit und Zuverlässigkeit Robustheit Effizienz (bzgl. Ressourcen) Benutzerfreundlichkeit Wartbarkeit und Wiederverwendbarkeit Qualitätsfaktoren Extern (für den Benutzer sichtbar) Intern (nur für den Entwickler sichtbar) 5 6 1

2 Vorgehensmodelle: Motivation Voraussetzung für den sinnvollen Einsatz von Notationen und Werkzeugen zur Softwareentwicklung ist ein Vorgehensmodell, das den Gesamtprozess der Softwareerstellung und -pflege in einzelne Schritte aufteilt und die Verantwortlichkeiten der beteiligten Personen (Rollen) klar regelt. Vorgehensmodelle: Beispiele Code-and-fix - Zyklus (Vorgehensmodell?) Klassisches Wasserfallmodell Wasserfallmodell mit Zyklen Evolutionary Prototyping Rapid prototyping Transformationsansatz ( ) Rational Unified Process (RUP) ( 7 8 Code-and-Fix - Zyklus Wasserfallmodell Vorgehensweise für kleine Projekte und Übungsaufgaben 1. Code schreiben und übersetzen 2. Code testen bzw. debuggen 3. Code verbessern (Fehlerbeseitigung, Erweiterung, Effizienzsteigerung, ) 4. Ggf. zurück zu 1. Probleme Abnehmende Wartbarkeit und Zuverlässigkeit Starke Abhängigkeit vom einzelnen Programmierer Meinungsverschiedenheiten über erwarteten/ realisierten Funktionsumfang zwischen Entwickler und Anwender Machbarkeitsstudie Anforderungsanalyse Systementwurf Codierung und Modultest Integrations- und Systemtest Auslieferung und Installation Wartung 9 10 Machbarkeitsstudie Machbarkeitsstudie (II) Problembeschreibung Erarbeitung verschiedener Lösungsansätze Kosten- und Ertragsschätzung der geplanten Softwareentwicklung Angebotserstellung Lastenheft (enthält lediglich grobe Beschreibung der Anforderungen) Projektkalkulation Projektplan Angebot an Auftraggeber Verfahren Richtlinien für Lastenhefte Erstellungsrichtlinien Schätzverfahren Faustregeln Projektpläne und Projektorganisation für Terminund Ressourcenplanung

3 Anforderungsanalyse (Requirements Engineering) Systementwurf (System Design) Festlegung, was die Software leisten soll, und nicht, wie diese Leistungsmerkmale erreicht werden. Festlegung, wie die Funktionen der Software zu realisieren sind Bauplan der Software und der Softwarearchitektur Festlegung der Systemeigenschaften wie Funktionalität, Leistung, Benutzungsschnittstelle, Portierbarkeit, Bestimmung von Testfällen Festlegung erforderlicher Dokumentationsdokumente Pflichtenheft = Anforderungsanalysedokument Akzeptanztestplan Benutzungshandbuch 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 Entwurfsdokument mit Softwarebauplan Detaillierte Testpläne Programmierung und Modultest Integration und Systemtest Integration einzelner Module zum Gesamtsystem Implementierungs- und Testphase: Realisierung und Validierung einzelner Module Programmieren im Kleinen = Implementierung einzelner Module Einhaltung von Programmierrichtlinien Code-Inspektionen kritischer Modulteile Test der erstellten Module Menge realisierter Module Implementierungsberichte (Abweichungen vom Entwurf, Zeitplan, ) Technische Dokumentation einzelner Module Testprotokolle Systemintegration = Zusammenbau der Module Gesamtsystemtest durch Entwicklungsorganisation Fertigstellung der Dokumentation Fertiges System Benutzerhandbuch Technische Dokumentation Testprotokolle Auslieferung und Installation Wartung (Maintenance) Inbetriebnahme der Software beim Kunden findet häufig in zwei Phasen statt Softwarewartung macht ca. 60% der gesamten Softwarekosten aus! Auslieferung an ausgewählte Benutzer Auslieferung an alle Benutzer Schulung der Benutzer Fehlerbehebung (corrective maintenance) Anpassungen (adaptive maintenance) Verbesserungen (perfective maintenance) Fertiges System Akzeptanztestdokument Softwareproblemberichte (bug reports) Softwareänderungsvorschläge neue Softwareversionen

4 Referenzmodell Wasserfall: Probleme Nur ungenaue Kosten- und Ressourcenschätzungen zu Projektbeginn Pflichtenheft vs. Umgang mit dem (spät) fertigen System (Risikomaximierung) Fehlende Anforderungen für das Pflichtenheft zu Projektbeginn 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 Wasserfallmodell: Verbesserungen Naheliegendste Idee zur Verbesserung des Wasserfallmodells: Einführung von Zyklen bzw. Rückgriffen, Wiederaufnehmen früherer Phasen bei Problemen Modell wird komplexer und teurer! Evolutionäres Modell (Evolutionary Prototyping) Evolutionäres Modell (II) Rasche Entwicklung eines (durch Kunden) evaluierbaren Prototyps Keine vollständige Festlegung von Kosten und Leistungsumfang des gesamten Softwaresystems zu Beginn des Projekts Vereinfachte Projektplanung durch überschaubarere Teilprojekte Probleme Erweiterbarkeit der Systemarchitektur (Bindung an Prototyp) Hinfälligkeit bereits realisierter Funktionen Endresultat wie nach 10 Jahren Wartung Rapid Prototyping (Throw-Away-Prototyping) Transformationsansatz Realisierung und Vorführung eines Prototyps des Systems (seiner Benutzeroberfläche) mit Generatoren, ausführbaren Spezifikationssprachen, Skriptsprachen etc. 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 Formale Spezifikation der stellung (z. B. algebraische Spezifikation) Transformation in kleinen semantikerhaltenden Schritten in effiziente Implementierung Rapid prototype ggf. als Zwischenprodukt Präzise und nachweisbar konsistente Anforderungen Beweisbarkeit der Eigenschaften des Systems Nachteile Auftraggeber (Auftragnehmer) versteht formale Spezifikationen nicht Nicht alle Anforderungen werden so erfasst (Benutzeroberfläche, ) Für große Systeme kaum durchführbar

5 Rational Unified Process (RUP) Eigenschaften des RUP Basiert auf Standard-OO-Modellierungssprache UML und dem zugehörigen Vorgehensmodell Bestandteile Verschiedene Generationen Generationen bestehen aus verschiedenen Phasen mit Iterationen Inception (Vorbereitung) Elaboration (Entwurf) Construction (Konstruktion) Transition (Einführung) Modellbasiert Modelle (Dokumente) für die einzelnen Schritte des Prozesses Prozessorientiert genau definierte Abfolge von anderweitig wiederholbaren Aktivitäten Iterativ und inkrementell Risikobewusst Aktivitäten mit hohem Risiko in frühen Iterationen Zyklisch Ergebnis jedes Zyklus: Neue Systemgeneration (als kommerzielles Produkt ausgeliefert) Ergebnisorientiert Meilenstein (def. Ergebnis zu def. Zeitpunkt) steht am Ende jeder Iteration Eigenschaften des RUP (II) Bewertung des RUP Faustregeln für die Ausgestaltung eines Entwicklungsprozesses Rollenbasierte Softwareentwicklung und Arbeitsbereiche Projekte funktionieren, wenn die richtigen Personen unter Verwendung geeigneter Sprachen, Methoden und Werkzeuge kooperieren Zuweisung von Rollen an Personen klärt Verantwortlichkeiten und Kompetenzen Standardisierungsvorschlag und kommerzielles Produkt Eigene Managersicht Feinere aktivitätsorientierte Sicht für Entwickler Nachteile Komplexes, noch stark in Veränderung befindliches Vorgehensmodell Qualitätssicherung nicht integriert Trend: OO SWE Typen von Web Sites Daten- und Verhaltensmodellierung mit UML- Objekt- und Klassendiagrammen Fließender Übergang von der Analyse zum Entwurf Verwendung von Entwurfsmustern Modellierung von Softwarearchitekturen mit UML Übergang vom Entwurf zur Implementierung: Versuch der Generierung Statisch Plain HTML mit Links HTML mit Formularen Dynamisch Datenbankzugriff Generiert Web-basierte SW-Applikationen

6 SW-Kontinuum von Web Sites Anforderungen an Well-Engineered Web Sites Korrektheit Funktionalität Formal schwer nachweisbar, deshalb pragmatisch Testbarkeit ( spezielle VORL) Funktionalität Benutzbarkeit Benutzerakzeptanz Wartbarkeit ( spezielle VORL) Änderungen leicht durchführbar Bis zu 75% der Entwicklungskosten (!) Anforderungen an Well-Engineered Web Sites (II) Anforderungen an Well-Engineered Web Sites (III) Portierbarkeit/Skalierbarkeit Client Server Wiederbenutzbarkeit Standardanforderung an SW Kern übersteht Oberflächen-Änderungen Robustheit/Verlässlichkeit Implementation Übermittlung ( Medium) Effizienz Implementation Übermittlung ( Medium) Lesbarkeit: Source-Code Kommentare Formatierung Sprechende Namen Dokumentation History Help Files Präsentation: Effizienz vs. Qualität Entwicklung von Web Sites SW-Lifecycle-Implementation Unsichtbarkeit mangelnde Transparenz (???) Need for speed unrealistische Termine Inkrementelle Entwicklung Ständiger Wechsel im Softwarebereich Generelle Trends Verschiedene Komplexitätsstufen Ziel und Ausrichtung entscheidend Von Dokumenten zu Software 1. RAD (Rapid Application Development): Rapid prototyping 2. Wasserfall 3. Whirlpool: Modifizierter Wasserfall 4. JAD (Joint Application Development): Evolutionary prototyping 5. Spirale Einsatz von SW-Engineering-Methoden NB: Unterscheide Kunde und Benutzer!

7 RAD Wasserfall mit Zyklen Charakteristika Quick and dirty / implement and test Schnell, aber hochriskant Feuerwehr-Prinzip / Reiz-Reaktions-Schema Kein formaler Entwicklungsprozess Häufig genutztes Verfahren bei Web Sites Web-Krise ähnlich Software-Krise Besser formale Prozessmodelle Wasserfall mit Zyklen (II): Probleme beim Web Site Design Unzureichende Modellierung der WWW-Entwicklung Rückkehr zu früheren Stufen schwierig Überlappung von Stufen nicht vorgesehen Aber: Entwicklungsschritte bei Web Sites überlappen und wiederholen sich Detaillierte Planung: Mangelnde Flexibilität Schwierigkeiten bei Unsicherheit in der Planung Unerfahrenheit der Web Site Designer Whirlpool: Modifizierter Wasserfall Verwendung der Stufen lediglich als Meilensteine Whirlpool (II): Einsatzgebiete JAD: Ablauf Überlappung der Prozess-Schritte Vorbereitung zum Wasserfall Planung und RAS Risikoreduktion durch Iteration Anfangsprojekte 1. Gespräch Entwickler-Kunde Requirements 2. Kunde testet Prototypen Kunde schlägt ggf. Änderungen vor Falls OK: Release der fertigen SW 3. Entwickler liefert neuen Prototypen; zurück zu

8 JAD (II): Diskussion für Web Site Design Feedback statt big bang beim Release Einsatz in der Entwicklung von Intranet-Sites (Kommunikation entscheidend!) Nachteile Kunde und Benutzer als Beta-Tester Mangelnde Akzeptanz Ablenkung durch Inkompetenz Abschluss des Projekts schwer festzulegen Spirale Empfehlenswert für erfahrene Web-Designer Spirale (2): Ideen Spirale (3): Probleme Flexibilität in den Wasserfall integrieren Kritische Aspekte zuerst klären Subprojekte definieren Inkrementell entwickeln Auf weniger wichtige Teilaspekte im weiteren Verlauf zurückkommen Komplex Grenzen zwischen Stufen fließend Kostenvorhersage schwierig Ungeeignet für Anfangsprojekte Übernahme bestehender Sites Anwendbar v.a. bei Planung und Wartung WWW-Sites vs. Software WWW-Sites vs. Software (2) Dokument-Orientierung Statische Sites behalten weiterhin ihre Daseinsberechtigung Kein SW-Engineering nötig Look & feel Marketing-Aspekte: Kundennutzen Benutzer-Akzeptanz Inhalte Daten mit Design entwickeln Content Creation & Management Medium Mit Prozessmodellen allein nicht zu erfassen! Verschieden stark strukturierte Herangehensweise für unterschiedliche Teile des Entwicklungszyklus entspr. Inhalt Strukturierung Zielsetzung

9 Zusätzliche Faktoren Personal Kommunikation Kunde-Benutzer-Entwickler Unrealistische Erwartungen/Versprechungen Identifikation von Kunden und Managern mit Projekt Theorie und Praxis: Plan vs. Umsetzung SW-Engineering-Modelle und Realität Terminpläne (Wettbewerb!) Feature creep : Unbedachte Schnellschüsse Technologie-Adaption: Ständig neue Software Literatur Thomas A. Powell: Web Site Engineering, Prentice Hall 1998 I. Sommerville: Software Engineering, Addison-Wesley H. Balzert: Lehrbuch der Softwaretechnik (Band 1): Software- Entwicklung, Spektrum Akademischer Verlag (1996) C. Ghezzi, M. Jazayeri, D. Mandrioli: Fundamentals of Software Engineering, Prentice Hall (1991) S. L. Pfleeger: Software Engineering - Theory and Practice, Prentice Hall (1998) B. Kahlbrandt: Software- Engineering: Objektorientierte Software- Entwicklung mit der Unified Modeling Language, Springer (2001) G. Booch, J. Rumbaugh, I. Jacobson: The Unified Modeling Language User Guide, Addison Wesley (1999) G. Snelting u. A. Zeller, TU Braunschweig: Einführung in Software Engineering, Prof. Dr. Andy Schürr, Software Engineering,