Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

1 Vorlesung "Software-Engineering" zVorige Vorlesung yEinführung in die durch Software-Engineering gelösten Probleme yCharakterisierung von Software-Qualität.

Ähnliche Präsentationen


Präsentation zum Thema: "1 Vorlesung "Software-Engineering" zVorige Vorlesung yEinführung in die durch Software-Engineering gelösten Probleme yCharakterisierung von Software-Qualität."—  Präsentation transkript:

1

2 1 Vorlesung "Software-Engineering" zVorige Vorlesung yEinführung in die durch Software-Engineering gelösten Probleme yCharakterisierung von Software-Qualität zHeute yFortsetzung: Qualitätsmerkmale  Produkte und Leistungen yProjektphasen und Vorgehensmodelle Prof. Ralf Möller, TUHH, Arbeitsbereich STS

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

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

5 4 Qualitätsmerkmale für die Anwendung (2) zEffizienz yBestimmt den Bedarf an Betriebsmitteln yEffizientes Programm: kein unnötiger Verbrauch an Betriebsmitteln yUnterscheidung von Speichereffizienz und Laufzeiteffizienz yKonflikte zu Änderbarkeit, Testbarkeit, Portierbarkeit

6 5 Qualitätsmerkmale für die Anwendung (3) zRobustheit yDefinierte und sinnvolle Reaktion des Programms bei beliebiger externer Kommunikation yVerhindern von undefinierten Systemzuständen und "Systemabstürzen" yBesonders wichtig: Abfangen fehlerhafter Benutzereingaben yBeseitigung der Fehlersymptome, nicht der Ursachen ySpektrum von sinnvollen Reaktionsmöglichkeiten, abhängig von der Situation

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

8 7 Qualitätsmerkmale für die Anwendung (5) zZuverlässigkeit yZusammenspiel von Korrektheit, Robustheit und Verfügbarkeit yAuftreten von Fehlern im Zeitablauf yBerücksichtigung von Reparaturzeiten und Fehlerqualitäten yWahrscheinlichkeit, daß ein System seine Funktion während eines Zeitintervalls korrekt erfüllt yFestlegung in den Spezifikationen

9 8 Qualitätsmerkmale für die Anwendung (6) zBenutzungsfreundlichkeit zSpezielles Forschungsgebiet: Software-Ergonomie zSpeziellere Merkmale der Benutzungsfreundlichkeit (nach DIN Teil 8 und DIN EN ISO 9241): yAufgabenangemessenheit ySelbstbeschreibungsfähigkeit ySteuerbarkeit yErwartungskomformität yFehlerrobustheit

10 9 Qualitätsmerkmale für die Anwendung (7) zDatensicherheit / Datenschutz ySchutz gegen unerwünschte bzw. unerlaubte Verfälschung/Zerstörung bzw. Preisgabe von Daten yProblem durch Dezentralisierung/Vernetzung der DV verschärft yBehandlung von Ausnahmesituationen (z.B. Stromausfall, Systemabsturz) yRestartfähigkeit (Möglichkeit zum Wiederaufsetzen) yKombination von software-technischen und organisatorischen Maßnahmen

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

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

13 12 Qualitätsmerkmale für Entwicklung u. Wartung (3) zPrüfbarkeit/Testbarkeit yMöglichkeiten zum Testen eines Programms hinsichtlich Korrektheit, Robustheit und Zuverlässigkeit yWesentlich abhängig von Modularität und Strukturierung yParallelentwicklung von Testumgebungen

14 13 Qualitätsmerkmale für Entwicklung u. Wartung (4) zWiederverwendbarkeit/Portabilität yAspekt der Allgemeinheit der Software yVerlängerung der Lebensdauer von Software yAufbau von Software-Bibliotheken und Nutzung objektorientierter Ansätze yNotwendigkeit zu ausführlicher Dokumentation yZiel: Senkung von Entwicklungskosten

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

16 15 Qualität kann nicht isoliert betrachtet werden QualitätQuantität EntwicklungskostenEntwicklungsdauer Produktivität

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

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

19 18 Aufgaben überlappen sich! SW-Engineering als kooperative Aktivität (1) Arbeitsaufteilung größerer Software-Entwicklungsteams in verschiedene Ebenen: yProgrammierung: Programmierer, Entwickler, Kodierer, Datenbank- Administrator (DBA), Mediendesigner,... xImplementierung und Anpassung von Komponenten ySoftwarearchitektur: Software- / System-Architekt xAnalyse und Design xDefinition von Komponenten und Protokollen yProjektmanagement: Projekt-, Gruppen- und Abteilungsleiter xAnforderungsermittlung xKostenplanung, Ressourcenverteilung xProjektplanung und Controlling xGruppenkommunikation und Führung technische Kompetenz Abstraktions- und Kommunikations- fähigkeiten betriebswirtschaftliche und soziale Kompetenz

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

21 20 Handarbeit vorgegebene Produktionsmittel Kommerz wissenschaftlich fundierte Produktionstechnik professionelle Ingenieursdisziplin Virtuosen und talentierte Amateure Intuition und “brute force” Zufälliger Fortschritt Fallweiser Austausch Extravagante Benutzung vorhandener Materialien Handarbeit für Benutzung statt Verkauf 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 Evolution einer Ingenieursdisziplin status quo

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

23 22 Aufgaben beim Software-Projektmanagement yErstellung eines Projektplans yAuswahl einer Prozeßnotation yAuswahl eines Prozeßmodells zDefinitionen ySoftware-Entwicklungsprozeß: Aktivitäten, Methoden und Verfahren zur Entwicklung und Überprüfung von Software. yPlanung: „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] Organisation Planung

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

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

26 25 „Naives“ SWT-Grundmodell: Code & Fix zGrundmodell aus den Anfängen der Softwaretechnik: Code & Fix  Schreibe ein Programm.  Finde und behebe die Fehler im Programm. zNachteile yFehlerbehebung strukturiert Programm so um, daß weitere Fehlerbehebungen und die Weiterentwicklung immer teurer werden.  Entwurfsphase wird nötig. ySelbst gut entworfene Software wird von den Benutzern oft nicht akzeptiert.  Definitionsphase vor dem Entwurf wird nötig. yFehler sind schwer zu finden, da Tests schlecht vorbereitet und Änderungen unzureichend durchgeführt wurden.  Separate Testphase wird nötig. zFolge: Entwicklung einer Reihe von besseren Modellen. codePrg.fix

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

28 27 Das Wasserfallmodell (1) yWeiterentwicklung des stufenorientierten Modells ySukzessive Stufen der Entwicklung mit Rückkopplung System- Anforderungen Software- Anforderungen Analyse Entwurf Codierung Test Betrieb

29 28 Das Wasserfallmodell (2) zCharakteristika yAktivitäten sind in der richtigen Reihenfolge und vollen Breite durchzuführen yAm Ende jeder Aktivität steht ein Dokument (dokumentgetriebenes Modell) yEntwicklungsablauf ist sequentiell, vorhergehende Aktivität muß beendet werden, bevor die nächste beginnt yOrientiert am Top-down-Vorgehen yEinfach, verständlich, wenig Managementaufwand yBenutzerbeteiligung nur in der Definitionsphase zNachteile yNotwendige „Kurskorrekturen“ nicht frühzeitig erkennbar ySequentialität nicht immer nötig yGefahr, daß Dokumente wichtiger als das System werden yRisikofaktoren werden u.U. zu wenig berücksichtigt

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

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

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

33 32 Das Prototypen-Modell (1) z Probleme traditioneller Modelle: yAuftraggeber / Endbenutzer können oft Anforderungen nicht vollständig / explizit formulieren. Dies ist aber in klassischen Definitionsphasen nötig! yKooperation 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 yOft existieren unterschiedliche Lösungswege, die besser experimentell erprobt werden und mit dem Auftraggeber diskutiert werden können. yManche Anforderungen lassen sich theoretisch nicht garantieren (z.B. Echtzeitanforderungen). Vor dem Abschluß der Definitionsphase muß also ggf. einiges ausprobiert werden. yDas Ü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).

34 33 Das Prototypen-Modell (2) zBegriffsbestimmung 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“

35 34 Das Prototypen-Modell (3) z Arten von Software-Prototypen: yDemonstrationsprototyp: Dient zur Auftragsakquisition; verschafft Eindruck, wie das Produkt aussehen kann. Wichtig: Wird später weggeworfen! yPrototyp 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) yLabormuster: Dient zur Beantwortung konstruktionsbezogener Fragen und Alternativen. (Experimentelles Prototyping) yPilotsystem: 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

36 35 Das Prototypen-Modell (4) zEin fertiges Software-Produkt besteht aus vielen Komponenten und Ebenen. zUnterscheidung zwischen horizontalen und vertikalen Prototypen: Benutzungsoberfläche Systemsoftware vertikaler Prototyp horizontaler Prototyp Anwendung DatenhaltungNetzanbindung

37 36 Das Prototypen-Modell: Bewertung zVorteile: yReduktion des Entwicklungsrisikos durch frühzeitige/stärkere Rückkopplung. ySinnvoll in andere Prozeßmodelle integrierbar. yPrototypen sind durch geeignete Werkzeuge schnell erstellbar.  „Rapid Prototyping“ zNachteile yHöherer Entwicklungsaufwand. yGefahr, daß ein „Wegwerf“-Prototyp nicht weggeworfen wird. yPrototypen werden oft als Ersatz für Dokumentation angesehen.

38 37 Projektetablierung Das evolutionäre/inkrementelle Modell zBeobachtung: Software-(Weiter) Entwicklung unterliegt Änderungen zLernen zwischen Entwicklern und Anwendern nötig, da yVeränderungen im technischen und Einsatzkontext stattfinden ysich durch den Einsatz des Systems neue Anforderungen ergeben  Systementwicklung in Ausbaustufen, inkrementelle Entwicklung, Prototyping Revisionsetablierung Projektabschluß System- spezifikation Software- Realisierung Umfeld- Vorbereitung SystemgestaltungPflegeNutzung System- Version Herstellung Einsatz Entwickleraufgabe Nutzeraufgabe

39 38 Das Spiralmodell (1) zDas Spiralmodell ist eigentlich ein Modell höherer Ordnung zFür jedes (Teil-)Produkt sind zyklisch vier Schritte zu durchlaufen: zSchritt 1: yIdentifizierung der Ziele des Teilprodukts (Leistung, Funktionalität, Anpaßbarkeit,...) yAlternative Möglichkeiten zur Realisierung des Teilprodukts finden. yRandbedingungen bei verschiedenen Alternativen finden zSchritt 2: yEvaluierung der Alternativen unter Berücksichtigung aller Alternativen yIdentifizieren und ggf. Überwinden von Risiken (durch Prototypen, Simulation,...) zSchritt 3: yAbhängig vom Risiko wird ein Prozeßmodell festgelegt (oder eine Kombination). yAnwendung des Modells zSchritt 4: yPlanung des nächsten Zyklus, Überprüfung der nächsten 3 Schritte im nächsten Zyklus, Einverständnis mit Beteiligten sichern.

40 39 Das Spiralmodell (2)

41 Das Spiralmodell (3)

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

43 42 OO-Modell: Unified Process (1) z Unified Process: Der UML-Software-Entwicklungsprozeß: yDer Einstieg etabliert das Geschäftsziel und legt den Umfang des Projektes fest. yIn 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) yDie 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) yDie Überleitungsphase enthält den Beta-Test, Leistungssteigerung und Benutzer-Training. Einstieg Erarbeitung Überleitung Konstruktion

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


Herunterladen ppt "1 Vorlesung "Software-Engineering" zVorige Vorlesung yEinführung in die durch Software-Engineering gelösten Probleme yCharakterisierung von Software-Qualität."

Ähnliche Präsentationen


Google-Anzeigen