Vorlesung SoftwareEngineering Prof Ralf Mller TUHH Arbeitsbereich STS

Vorlesung "Software-Engineering" Prof. Ralf Möller, TUHH, Arbeitsbereich STS z Vorige Vorlesung y Einführung in die durch Software-Engineering gelösten Probleme y Charakterisierung von Software-Qualität z Heute y Fortsetzung: Qualitätsmerkmale y Produkte und Leistungen y Projektphasen und Vorgehensmodelle 1

Software-Qualität: Perspektiven Auftraggeber Anwender Benutzungsfreundlichkeit Adäquatheit Effizienz Erlernbarkeit Koppelbarkeit Wieder. Benutzerdokumentation Zuverlässigkeit verwendbarkeit Korrektheit Robustheit Portabilität Verfügbarkeit Wartbarkeit Lesbarkeit Systemdokumentation Software. Betreuer 2

Qualitätsmerkmale für die Anwendung (1) z Korrektheit y Übereinstimmung zwischen funktioneller Spezifikation und Programmfunktionalität y Korrektheit in der Praxis schwer nachweisbar y Korrektheitsbeweise mit Programmverifikation nur für kleine Teilalgorithmen möglich y Vollständige Tests aller Programmzustände zu aufwendig y Korrektheit ist ein wichtiger aber vielfach theoretischer Anspruch y Korrektheit in umfangreichen Programmsystemen besonders problematisch 3

Qualitätsmerkmale für die Anwendung (2) z Effizienz y Bestimmt den Bedarf an Betriebsmitteln y Effizientes Programm: kein unnötiger Verbrauch an Betriebsmitteln y Unterscheidung von Speichereffizienz und Laufzeiteffizienz y Konflikte zu Änderbarkeit, Testbarkeit, Portierbarkeit 4

Qualitätsmerkmale für die Anwendung (3) z Robustheit y Definierte und sinnvolle Reaktion des Programms bei beliebiger externer Kommunikation y Verhindern von undefinierten Systemzuständen und "Systemabstürzen" y Besonders wichtig: Abfangen fehlerhafter Benutzereingaben y Beseitigung der Fehlersymptome, nicht der Ursachen y Spektrum von sinnvollen Reaktionsmöglichkeiten, abhängig von der Situation 5

Qualitätsmerkmale für die Anwendung (4) z Verfügbarkeit y Wahrscheinlichkeit, daß ein System zu einem gegebenen Zeitpunkt funktionsfähig ist y Kennwert in der Praxis: V= MTBF + MTTR MTBF: Mean Time Between Failures MTTR: Mean Time To Repair 6

Qualitätsmerkmale für die Anwendung (5) z Zuverlässigkeit y Zusammenspiel von Korrektheit, Robustheit und Verfügbarkeit y Auftreten von Fehlern im Zeitablauf y Berücksichtigung von Reparaturzeiten und Fehlerqualitäten y Wahrscheinlichkeit, daß ein System seine Funktion während eines Zeitintervalls korrekt erfüllt y Festlegung in den Spezifikationen 7

Qualitätsmerkmale für die Anwendung (6) z Benutzungsfreundlichkeit z Spezielles Forschungsgebiet: Software-Ergonomie z Speziellere Merkmale der Benutzungsfreundlichkeit (nach DIN 66234 Teil 8 und DIN EN ISO 9241): y y y Aufgabenangemessenheit Selbstbeschreibungsfähigkeit Steuerbarkeit Erwartungskomformität Fehlerrobustheit 8

Qualitätsmerkmale für die Anwendung (7) z Datensicherheit / Datenschutz y Schutz gegen unerwünschte bzw. unerlaubte Verfälschung/Zerstörung bzw. Preisgabe von Daten y Problem durch Dezentralisierung/Vernetzung der DV verschärft y Behandlung von Ausnahmesituationen (z. B. Stromausfall, Systemabsturz) y Restartfähigkeit (Möglichkeit zum Wiederaufsetzen) y Kombination von software-technischen und organisatorischen Maßnahmen 9

Qualitätsmerkmale für Entwicklung u. Wartung (1) z Verständlichkeit/Lesbarkeit y Maß für den Aufwand, ein (fremdes) Software-Produkt zu verstehen y Vielfältige Maßnahmen zur Erhöhung der Verständlichkeit möglich y Voraussetzung für Änderbarkeit und Reparierbarkeit 10

Qualitätsmerkmale für Entwicklung u. Wartung (2) z Änderbarkeit y Möglichkeiten zur Anpassung von (korrekter) Software an veränderte Einsatzbedingungen und Anforderungen y Begrenzung des Aufwandes bei Änderungen y Berücksichtigung bereits bei Software-Entwicklung y Weitgehend abhängig von einer geeigneten Modularisierung der Software 11

Qualitätsmerkmale für Entwicklung u. Wartung (3) z Prüfbarkeit/Testbarkeit y Möglichkeiten zum Testen eines Programms hinsichtlich Korrektheit, Robustheit und Zuverlässigkeit y Wesentlich abhängig von Modularität und Strukturierung y Parallelentwicklung von Testumgebungen 12

Qualitätsmerkmale für Entwicklung u. Wartung (4) z Wiederverwendbarkeit/Portabilität y Aspekt der Allgemeinheit der Software y Verlängerung der Lebensdauer von Software y Aufbau von Software-Bibliotheken und Nutzung objektorientierter Ansätze y Notwendigkeit zu ausführlicher Dokumentation y Ziel: Senkung von Entwicklungskosten 13

Zusammenhänge zwischen Qualitätsmerkmalen und Kosten z (nach Pomberger) + = positive Wirkung, - = negative Wirkung, 0 = keine Wirkung 14

Qualität kann nicht isoliert betrachtet werden Qualität Quantität + + Produktivität - ++ Entwicklungsdauer Entwicklungskosten 15

Projektmanagement z Aufgaben und Phasen der Softwareentwicklung y Projektplan, Meilenstein y Prozeßmodelle (auch Vorgehensmodelle genannt) Wasserfall-, V-, Prototypen-, Evolutionäres-, Inkrementelles-, Spiral-, Objectory-Modell z Lernziele y Prozeßnotation, -modell und -plan unterscheiden können. y Hauptaufgaben beim Prozeßmanagement wiedergeben können. y Prozeßmodelle wiedergeben können. 16

Projektablauf Individualsoftware Auftraggeber Anfrage (Analyseauftrag) Auftragnehmer Anforderungsermittlung Angebot (Leistung, Preis) Auftrag Produkt Abnahme, Bezahlung (AG) (AN) Wartung, Support Standardsoftware Schwerpunkt SW-Hersteller Kunde Bezahlung Produkt Customer Services Entwicklung s. o. Support 17

SW-Engineering als kooperative Aktivität (1) Aufgaben überlappen sich! Arbeitsaufteilung größerer Software-Entwicklungsteams in verschiedene Ebenen: y Programmierung: Programmierer, Entwickler, Kodierer, Datenbank. Administrator (DBA), Mediendesigner, . . . technische x Implementierung und Anpassung von Komponenten y Softwarearchitektur: Software- / System-Architekt x Analyse und Design x Definition von Komponenten und Protokollen Kompetenz Abstraktions- und Kommunikationsfähigkeiten y Projektmanagement: Projekt-, Gruppen- und Abteilungsleiter x x Anforderungsermittlung Kostenplanung, Ressourcenverteilung Projektplanung und Controlling Gruppenkommunikation und Führung betriebswirtschaftliche und soziale Kompetenz 18

Von Handarbeit zur Ingenieursdisziplin z Historisch: implizite, informelle, anonyme, “zufällige” SW-Architekturen y Projekt- und Produktgetrieben z Ziel: Erhöhung der Produktivität und Planungssicherheit großer Softwareprojekte durch explizite, formale, benannte und geprüfte Vorgehensweisen: y Verbesserte Kommunikation im Projekt-Team y Erhöhtes Wissen am Ende der Software-Engineering-Ausbildung y Verfügbarkeit eines Katalogs von Vorgehensmodellen (Handbuchartiges Wissen; vgl. Knuth / Sedgewick bei Algorithmen) y (Formale Modelle zum Testen, Verifizieren, Nutzen und Messen von Modellen). z Hindernisse y Altsysteme („legacy“), bestehendes (veraltetes) Wissen, Personal, Organisation, . . . y Schneller Fortschritt der Technik und Anwendungen z Status: Software-Engineering als sich entwickelnde Disziplin, die sich dem Reifegrad anderer Ingenieursdisziplinen annähert. 19

Evolution einer Ingenieursdisziplin wissenschaftlich fundierte Produktionstechnik vorgegebene Produktionsmittel status quo professionelle Ingenieursdisziplin Handarbeit • Virtuosen und talentierte Amateure • Intuition und “brute force” • Zufälliger Fortschritt • Fallweiser Austausch • Extravagante Benutzung vorhandener Materialien • Handarbeit für Benutzung statt Verkauf Kommerz • Erfahrene Handwerker • Etablierte Verfahren • Pragmatische Verbesserungen • Ökonomische Aspekte: Kosten und Materialien • Handarbeit für den Verkauf • Ausgebildete Profis • Analyse und Theorie • Fortschritt basiert auf Wissenschaft • neue Anwendungen durch Analyse • Markt-Segmentierung und Produktvielfalt 20

Phasen der Softwareentwicklung Prüfung gegen Produkt. Definition aus 21 [Balzert]

Aufgaben beim Software-Projektmanagement y Erstellung eines Projektplans y Auswahl einer Prozeßnotation y Auswahl eines Prozeßmodells Planung Organisation z Definitionen y Software-Entwicklungsprozeß: Aktivitäten, Methoden und Verfahren zur Entwicklung und Überprüfung von Software. y Planung: „Planung ist Entscheiden im voraus, was zu tun ist, wie es zu tun ist, wann es zu tun ist und wer es zu tun hat. “ [~ Koontz, O‘Donnell 72] 22

Begriffe der Prozeßmodellierung z 3 Abstraktionsebenen Planung Projektplan Wird für jedes konkrete Software-Projekt erstellt (Projektleiter). Beispiel: „Projektkalender“ konkretisiert Prozeßmodell Organisation Generelles Vorgehen (z. B. einer Firma) zum Entwickeln eines Software-Produkts. Auch: Vorgehensmodell. Beispiel: Wasserfall-Modell, Unified Process beschreibt Prozeßnotation Sprache zur Spezifikation des Ablaufs von Software-Entwicklungen. Beispiel: EPK 23

Ausgewählte Prozeßmodelle z Prozeßmodell definiert: y y y durchzuführende Aktivitäten Definition der Teilprodukte Fertigstellungskriterien Mitarbeiterqualifikationen Verantwortlichkeiten und Kompetenzen Standards, Richtlinien, Methoden und Werkzeuge z Hier verwendete Notation: „Boxes and Arrows“ führt zu Produkt Aktivität geht ein z häufig auch ohne Produkte (Dokumente) dargestellt 24

„Naives“ SWT-Grundmodell: Code & Fix z Grundmodell aus den Anfängen der Softwaretechnik: Code & Fix �Schreibe ein Programm. �Finde und behebe die Fehler im Programm. code Prg. fix z Nachteile y Fehlerbehebung strukturiert Programm so um, daß weitere Fehlerbehebungen und die Weiterentwicklung immer teurer werden. �Entwurfsphase wird nötig. y Selbst gut entworfene Software wird von den Benutzern oft nicht akzeptiert. �Definitionsphase vor dem Entwurf wird nötig. y Fehler sind schwer zu finden, da Tests schlecht vorbereitet und Änderungen unzureichend durchgeführt wurden. �Separate Testphase wird nötig. z Folge: Entwicklung einer Reihe von besseren Modellen. 25

Vorgehensmodelle im Überblick • • • Wasserfallmodell V-Modell Prototypmodell Evolutionsmodell Spiralmodell (Rational) Unified Process 26

Das Wasserfallmodell (1) y Weiterentwicklung des stufenorientierten Modells y Sukzessive Stufen der Entwicklung mit Rückkopplung System. Anforderungen Software. Anforderungen Analyse Entwurf Codierung Test Betrieb 27

Das Wasserfallmodell (2) z Charakteristika y Aktivitäten sind in der richtigen Reihenfolge und vollen Breite durchzuführen y Am Ende jeder Aktivität steht ein Dokument (dokumentgetriebenes Modell) y Entwicklungsablauf ist sequentiell, vorhergehende Aktivität muß beendet werden, bevor die nächste beginnt y Orientiert am Top-down-Vorgehen y Einfach, verständlich, wenig Managementaufwand y Benutzerbeteiligung nur in der Definitionsphase z Nachteile y y Notwendige „Kurskorrekturen“ nicht frühzeitig erkennbar Sequentialität nicht immer nötig Gefahr, daß Dokumente wichtiger als das System werden Risikofaktoren werden u. U. zu wenig berücksichtigt 28

Das V-Modell (1) z Erweiterung des Wasserfall-Modells, das Qualitätssicherung integriert z Verifikation und Validation werden Bestandteile des Modells „Are we building the product right? “ y Verifikation: Überprüfung der Übereinstimmung zwischen Software. Produkt und seiner Spezifikation „Are we building the right product? “ y Validation: Eignung bzw. Wert eines Produkts bezogen auf seine Einsatzzweck 29

Das V-Modell (2) Anwendungsszenarien Anforderungs. Definition Abnahmetest Testfälle Grobentwurf Systemtest Testfälle Feinentwurf Modul. Implementierung Integrationstest Testfälle Modultest y Entwickelt ab ~1990 für Bundeswehr und später für weitere Behörden (Bundesverwaltung). y Submodelle für Systemerstellung (SE), Qualitätssicherung (QS), Konfigurationsmanagement (KM) und Projektmanagement (PM). y Ursprünglich für eingebettete Systeme entwickelt. 30

Das V-Modell: Bewertung (3) z Vorteile y Integrierte, detaillierte Beschreibung von Systemerstellung, Qualitätssicherung, Konfigurationsmanagement und Projektmanagement y Generisches Vorgehensmodell y Gut geeignet für große Projekte z Nachteile y Unkritische Übernahme der Konzepte, die für eingebettete Systeme entwickelt wurden, für andere Anwendungstypen y Software-Bürokratie bei kleinen & mittleren Projekten y Ohne CASE-Unterstützung nicht handhabbar 31

Das Prototypen-Modell (1) z Probleme traditioneller Modelle: y Auftraggeber / Endbenutzer können oft Anforderungen nicht vollständig / explizit formulieren. Dies ist aber in klassischen Definitionsphasen nötig! y Kooperation zwischen Anwendern und Entwicklern endet mit der Definitionsphase: Entwicklungsabteilungen ziehen sich nach Definitionsphase zurück und präsentieren erst nach Fertigstellung das Ergebnis; wünschenswerte Koordination zum Lernen von den jeweils anderen unterbleibt y Oft existieren unterschiedliche Lösungswege, die besser experimentell erprobt werden und mit dem Auftraggeber diskutiert werden können. y Manche Anforderungen lassen sich theoretisch nicht garantieren (z. B. Echtzeitanforderungen). Vor dem Abschluß der Definitionsphase muß also ggf. einiges ausprobiert werden. y Das Überzeugen des Auftraggebers von der prinzipiellen Durchführbarkeit oder Handhabung einer Idee während der Akquisitionsphase wird nicht unterstützt (Folge für Verantwortungsteilung, Mittelfluss, etc). 32

Das Prototypen-Modell (2) z Begriffsbestimmung Software-Prototyp: (im Gegensatz zum Begriff in anderen Ingenieursdisziplinen) Ein Software-Prototyp. . . y. . . ist nicht das erste Muster einer großen Serie (beliebig kopierbar, Massenfertigung) y. . . ist keine Simulation, sondern zeigt ausgewählte Eigenschaften des Zielprodukts im praktischen Einsatz (vgl. z. B. Windkanal oder Architekturmodell) y. . . dient zum Klären von relevanten Anforderungen oder Entwicklungsproblemen. y. . . dient als Diskussionsbasis für Entscheidungen. y. . . dient zu experimentellen Zwecken und Sammeln von praktischen Erfahrungen. Vorgehensweise: „prototyping“ 33

Das Prototypen-Modell (3) z Arten von Software-Prototypen: y Demonstrationsprototyp: Dient zur Auftragsakquisition; verschafft Eindruck, wie das Produkt aussehen kann. Wichtig: Wird später weggeworfen! y Prototyp im engeren Sinne: Wird parallel zur Modellierung des Anwendungsbereiches erstellt, um Aspekte der Benutzungsschnittstelle oder Teile der Funktionalität zu veranschaulichen. Dient zur Analyse. (Exploratives Prototyping) y Labormuster: Dient zur Beantwortung konstruktionsbezogener Fragen und Alternativen. (Experimentelles Prototyping) y Pilotsystem: Dient nicht nur zur experimentelle Erprobung oder Veranschaulichung, sondern ist schon Kern des Produkts. Unterscheidung zwischen Prototyp und Produkt verschwindet später. Die Weiterentwicklung erfolgt in Zyklen unter Beteiligung der Benutzer. Es ist ein wesentlich sorgfältigerer Entwurf nötig, da der Prototyp später weiterbenutzt wird! Benutzerdokumentation wird ebenfalls nötig. (Evolutionäres Prototyping) Prototyp Pilot Produkt 34

Das Prototypen-Modell (4) z Ein fertiges Software-Produkt besteht aus vielen Komponenten und Ebenen. z Unterscheidung zwischen horizontalen und vertikalen Prototypen: Netzanbindung Benutzungsoberfläche horizontaler Prototyp Anwendung horizontaler Prototyp Datenhaltung Systemsoftware vertikaler Prototyp 35

Das Prototypen-Modell: Bewertung z Vorteile: y Reduktion des Entwicklungsrisikos durch frühzeitige/stärkere Rückkopplung. y Sinnvoll in andere Prozeßmodelle integrierbar. y Prototypen sind durch geeignete Werkzeuge schnell erstellbar. „Rapid Prototyping“ z Nachteile y Höherer Entwicklungsaufwand. y Gefahr, daß ein „Wegwerf“-Prototyp nicht weggeworfen wird. y Prototypen werden oft als Ersatz für Dokumentation angesehen. 36

Das evolutionäre/inkrementelle Modell z Beobachtung: Software-(Weiter) Entwicklung unterliegt Änderungen z Lernen zwischen Entwicklern und Anwendern nötig, da y Veränderungen im technischen und Einsatzkontext stattfinden y sich durch den Einsatz des Systems neue Anforderungen ergeben Systementwicklung in Ausbaustufen, inkrementelle Entwicklung, Prototyping Projektetablierung Revisionsetablierung Herstellung Projektabschluß Einsatz Systemgestaltung Pflege Systemspezifikation Software. Realisierung Entwickleraufgabe Nutzung Entwickleraufgabe Umfeld. Vorbereitung Nutzeraufgabe System. Version Nutzeraufgabe 37

Das Spiralmodell (1) z Das Spiralmodell ist eigentlich ein Modell höherer Ordnung z Für jedes (Teil-)Produkt sind zyklisch vier Schritte zu durchlaufen: z Schritt 1: y Identifizierung der Ziele des Teilprodukts (Leistung, Funktionalität, Anpaßbarkeit, . . . ) y Alternative Möglichkeiten zur Realisierung des Teilprodukts finden. y Randbedingungen bei verschiedenen Alternativen finden z Schritt 2: y Evaluierung der Alternativen unter Berücksichtigung aller Alternativen y Identifizieren und ggf. Überwinden von Risiken (durch Prototypen, Simulation, . . . ) z Schritt 3: y Abhängig vom Risiko wird ein Prozeßmodell festgelegt (oder eine Kombination). y Anwendung des Modells z Schritt 4: y Planung des nächsten Zyklus, Überprüfung der nächsten 3 Schritte im nächsten Zyklus, Einverständnis mit Beteiligten sichern. 38

Das Spiralmodell (2) 1 2 3 4 39

Das Spiralmodell (3) 1 4 2 3 40

Das Spiralmodell (4) z Eigenschaften y Risikogetriebenes Modell, da Hauptziel die Minimierung des Risikos ist. y Ziel: Beginne im Kleinen, halte die Spirale so eng wie möglich und erreiche das Ziel mit minimalen Kosten. z Vorteile: y y Periodische Überprüfung und ggf. Neufestlegung des Prozeßmodell ist nicht für die gesamte Dauer des Projekts festgelegt. Flexibel, leichtere Umsteuerung Erleichtert Wiederverwendung von Software durch Betrachtung von Alternativen. z Nachteile: y Hoher Managementaufwand y Für kleine und mittlere Projekte weniger gut geeignet. y Wissen über Identifizierung und Management von Risiken ist noch nicht sehr verbreitet. 41

OO-Modell: Unified Process (1) z Unified Process: Der UML-Software-Entwicklungsprozeß: Einstieg y Der Einstieg etabliert das Geschäftsziel und legt den Umfang des Projektes fest. y In der Erarbeitungsphase werden detaillierte Anforderungen gesammelt, Analyse betrieben und Entwurf grundsätzliche Architekturentscheidungen getroffen sowie der Plan für die Konstruktion gemacht. (use case diagrams) y Die Konstruktion ist ein iterativer und inkrementeller Prozeß. Jede Iteration dieser Phase baut Software. Prototypen mit Produktqualität, die getestet werden und einen Teil der Anforderungen des Projekts umsetzen. (use-case driven) y Die Überleitungsphase enthält den Beta-Test, Leistungssteigerung und Benutzer-Training. Erarbeitung Konstruktion 1 2 3 4 5. . . Überleitung 42

OO-Modell: Unified Process (2) Analyse Entwurf Überleitung Projektauslieferung Erarbeitung Anforderungen bindende Verträge Demonstration Integration Kodierung Debugging Konstruktion ausführbare Module 43