Fachhochschule Gießen-Friedberg Studiengang Informatik. Achim H. Kaufmann SOFTWARETECHNIK. Vorlesungsskript. Version 1.1 (Arbeitsversion 1.

Transkript

1 Fachhochschule Gießen-Friedberg Studiengang Informatik Achim H. Kaufmann SOFTWARETECHNIK Vorlesungsskript Version 1.1 (Arbeitsversion 1. Mai 2002) Sommersemester 2002

2 Dieses Skript kann den Besuch der Vorlesung oder das Studium von Literatur nicht ersetzen, insbesondere ist es nicht ausreichend für das Bestehen der entsprechenden Prüfung. ª Die Nutzung dieses Skriptes ist auf die Vor- und Nachbereitung der auf dem Titelblatt bezeichneten Veranstaltung beschränkt. Eine darüber hinausgehende Nutzung bedarf der schriftlichen Genehmigung des Autors.

3 3 Inhaltsverzeichnis INHALTSVERZEICHNIS... 3 EINLEITUNG PROBLEMSTELLUNG Software-Technik und Software-Engineering Aufgaben SOFTWARE-ENGINEERING Software-Qualitätsmanagement Software-Entwicklungsverfahren Software-Architektur Haupt-/Unterprogramm-Architektur Schichten-Architektur Client/Server-Architektur Pipes/Filters-Architektur Aufgaben SOFTWARE-ENTWICKLUNGSPROZESS Wasserfall-Modell (Boehm/81) V-Modell (Wasserfall-Modell-Erweiterung) Prototypen-Modell...35

4 4 3.4 Evolutionäres Modell Nebenläufiges Modell Spiral-Modell (Boehm 1988) Unified Software Development Process Aufgaben METHODEN UND ERGEBNISSE DER ENTWICKLUNGSPHASEN Planungsphase Methode: Zielformulierung Methode: Projektplanung Methode: Durchführbarkeitsstudie Ergebnis: Projektdefinition Aufgaben Definitionsphase Methode: Structured-Analysis Kontextdiagramm Funktionale Dekomposition Datendiktionär Prozess-Spezifikation Methode: Modern-Structured-Analysis Object-Oriented-Analysis Business-Modell Use-case-Modell (First-cut) Aufgaben...71

5 5 4.3 Analysephase Methode: Structured-Analysis Methode: Modern-Structured-Analysis Methode: Entity-Relationship-Ansatz Methode: Object-Orientied-Analysis Aufgaben Entwurfsphase Methode: Modularisierung Modulkohäsion Modulkopplung Modulgröße Import- und Exportschnittstellen Modulhierarchie Methode: Abstraktion Datenabstraktion Algebraische Spezifikation Methode: Entwurf der Benutzerschnittstelle Methode: Structured-Design (SD) Strukturdiagramm (Structure-Chart) Übergang von SA nach SD Methode: Object-Oriented-Design Klassenbibliothek und Entwurfsmuster Aufgaben...94

6 6 4.5 Implementierungsphase Methode: Strukturierte Programmierung Methode: Jackson Structured Programming (JSP) Aufgaben Methode: Entscheidungstabellentechnik Methode: Normierte Programmierung Methode: Objektorientierte Programmierung Statisches Modell Objektmodell Aufgaben Klassenmodell Aufgaben Dynamisches Modell (Verhaltensstruktur) Use-Case-Diagramm (use case diagram) Aufgaben Aktivitätsdiagramm (activity diagram) Sequenzdiagramm (sequence diagram) Zustandsdiagramm (state diagram) Aufgaben Testen Methode: Statische Programmanalyse Methode: Dynamisches Testen Methode: Black-Box- und White-Box-Test...144

7 Methode: Vorgehensweise Aufgaben Überführungsphase Methode: Schulungsplanung/-durchführung Methode: Umstellungsplanung/-durchführung Methode: Katastrophenplanung/-beseitigung Betriebsphase Methode: Anwendungssystemmanagement Methode: Wartungsmanagement Methode: Produktionsmanagement ANLAGEN SOFTWARE-ENTWICKLUNGSMETHODEN Strucured-Analysis (SA) Prozessmodell Spezifikationsmethoden Beispiel Bewertung Moderne-Strucured-Analysis Prozessmodell Spezifikationsmethoden Beispiel Bewertung...153

8 8 1.3 Strucured-Design (SD) Prozessmodell Spezifikationsmethoden Beispiel Bewertung Unified-Methode-Language (UML) Prozessmodell (Unified-Process) Spezifikationsmethoden Beispiel Bewertung ENTWURFSMUSTER WICHTIGE AUTOREN DER SOFTWARETECHNIK LITERATURVERZEICHNIS...155

9 9 Einleitung Ziel der Veranstaltung Überblick über den Software-Entwicklungsprozess Einordnen der Veranstaltungen in diesen Rahmen Kennenlernen der Vorgehensweisen zur Entwicklung Überblick über Methoden und Ergebnisse Anwenden von Methoden der Software-Design-Phase Üben von wissenschaftlichen Voraussetzungen zur Veranstaltung Lern- und Mitarbeitsbereitschaft Abstraktionsvermögen Theoretische und praktische Programmier-Kenntnisse

10 10 Literaturempfehlung Balzert, B. Lehrbuch der Software-Technik. 2. Auflage, Spektrum, Heidelberg: 2000 Jacobson, I., Booch, G., Rumbaugh, J. The Unified Modeling Software Development Process. Reading, Mass.: 1999 Kahlbrandt, B. Software-Engineering mit der Unified Modeling Language. Springer, Berlin: 2001 Pomberger, G., Blaschek, G. Software Engineering. 3. Aufl. Hanser, München: 2002

11 Problemstellung 11 1 Problemstellung Software und Technik Software: zusammengehörige Programme, Daten und Dokumentationen Technik: Herstellungsverfahren oder Arbeitsweise Frei zitiert nach Dijkstra (1972) Als es noch keine Rechner gab, war auch das Programmieren noch kein Problem. Als es dann ein paar leistungsschwache Rechner gab, war das Programmieren ein kleines Problem. Nun, da wir gigantische Rechner haben, ist auch das Programmieren zu einem gigantischen Problem geworden.

12 Problemstellung 12 Software-Krise Fehlende Funktionalität Unzureichende Qualität Erhebliche Überschreitung der geplanten Kosten Zu lange Entwicklungszeiten 1.1 Software-Technik und Software-Engineering Software-Technik: Bereitstellung und Verwendung von Methoden und Werkzeugen zur Herstellung und systematischen Anwendung von Software Software-Engineering: Ingenieursmäßige Software-Erstellung (Synonym für Software-Technik).

13 Problemstellung Aufgaben Suchen Sie in der Literatur oder im Internet Definitionen für Software, Software-Technik bzw. Software-Engineering (jeweils mindestens 3 mit korrekter Referenzangabe). Grenzen Sie die gefundenen Definitionen mit eigenen Formulierungen gegeneinander ab. Beschreiben Sie mit eigenen Formulierungen das Problem der Software-Krise.

14 Software-Engineering 14 2 Software-Engineering Ingenieurmäßiges Arbeiten Organisation des Software-Erstellungs-Prozesses (Verfahrenslehre) Konstruktion des Software-Produktes (Konstruktionslehre). Organisation des Erstellungs-Prozesses Produktions-Qualität: Eigenschaften des Erstellungs- Prozesses Verfahren: Zielgerichtete Aktivitäten mit festgelegten Ergebnissen durch kombinierten Einsatz von Methoden, Werkzeugen und Vorschriften Vorgehens-, Prozess- oder Phasen-Modell: alle Aktivitäten im Software-Erstellungs-Prozess, ihre Voraussetzungen, Beziehungen und Ergebnisse

15 Software-Engineering 15 Konstruktion des Software-Produktes Produkt-Qualität: Eigenschaften des Software-Produktes Software-Bausteine: abgeschlossenes, begrifflich oder technisch zusammengehörige Teile eines Software- Produktes Software-Architektur: logische und physische Struktur eines Software-Produktes. Teilbereiche Software-Qualitätsmanagement Software-Entwicklungsverfahren Software-Lebenszyklus Software-Architektur 2.1 Software-Qualitätsmanagement Synonym Software-Qualitätssicherung

16 Software-Engineering 16 Qualitätsplanung, -lenkung und -kontrolle Qualitätsmaßnahmen Qualitätskriterien Qualitätsmaße Software-Management Qualität Alle Kriterien eines Software-Produktes und Produktions- Prozesses, die sich auf die Eignung zur Erfüllung gegebener Erfordernisse beziehen Erfordernisse synonym Qualitäts-(An-)Forderungen Software-Qualitätsmanagement: Planung, Lenkung und Kontrolle Qualitätsplanung: Festlegung von Kriterien, Maßen, Zielen und Vorgehensweisen Qualitätslenkung: Anwendung von Tätigkeiten und Techniken

17 Software-Engineering 17 Qualitätskontrolle: Evaluation von Ergebnissen Software-Qualitätsmanagement Maßnahmen Konstruktive: Entwicklungsverfahren Analytische: Testverfahren Organisatorische: Aufbau- und Ablauforganisation QM Software-Qualitätsmanagement Qualitätskriterien Synonym Qualitäts-Merkmale oder Eigenschaften Definieren die Produkt- oder Prozess-Qualität Software-Qualitätsmanagement Qualitätsmaße Synonym Quantifizierung Dimension und Mess-Verfahren der Qualitätskriterien Ausmaß der Qualitätsziele

18 Software-Engineering 18 Software-Qualitätskriterien Funktionalität: Richtigkeit, Angemessenheit, Interoperabilität, Ordnungsmäßigkeit, Sicherheit Zuverlässigkeit: Reife, Fehlertoleranz, Wiederherstellbarkeit Benutzbarkeit: Verständlichkeit, Erlernbarkeit, Bedienbarkeit Effizienz: Zeitverhalten, Verbrauchsverhalten Änderbarkeit: Analysierbarkeit, Modifizierbarkeit, Stabilität, Prüfbarkeit Übertragbarkeit: Anpassbarkeit, Installierbarkeit, Konformität, Austauschbarkeit Software-Qualitätskriterien Funktionalität Vorliegen von Funktionen mit Eigenschaften, welche die Anforderungen erfüllen Metrik: Anzahl der fehlenden und fehlerhaften Funktionen in Bezug auf die Festlegung im Pflichtenheft

19 Software-Engineering 19 Software-Qualitätskriterien Zuverlässigkeit Wahrscheinlichkeit, dass während eines Zeitintervalls eine Anzahl von Eingabefällen erfüllt wird Metrik: Fehlerrate Software-Qualitätskriterien Benutzbarkeit Aufwand und individuelle Beurteilung der Benutzung Metrik: Zeitaufwand zur Benutzung und individuelle Beurteilung aufgrund einer Zufriedenheitsskala Software-Qualitätskriterien Effizienz Verhältnis zwischen Leistungsniveau (Nutzen) und Umfang des Betriebsmittelverbrauchs (Kosten) Metrik: Anzahl Anwendungen/Zeiteinheit (Durchsatz) und Antwortzeit

20 Software-Engineering 20 Software-Qualitätskriterien Änderbarkeit Aufwand zur Durchführung von vorgegebenen Änderungen Metrik: Aufwand und Zeit Software-Qualitätskriterien Übertragbarkeit Eignung für ähnliche Aufgaben oder in einem geänderten Umfeld Metrik: Anzahl der bei einer Umstellung zu ändernden Einheiten oder Aufwand 2.2 Software-Entwicklungsverfahren Methodisches Vorgehen: zielorientierte, planmäßig angewandte, begründete Vorgehensweise Werkzeuggestütztes Vorgehen: weitgehend automatisierte Unterstützung aller Tätigkeiten (CASE, Computer Aided Software Engineering)

21 Software-Engineering 21 Vorschriftsmäßiges Vorgehen: Anweisungen zur Anwendung von Methoden und Werkzeugen Methodisches Vorgehen Prinzipien: Grundsätze, die dem Handeln zugrunde liegen Methoden: Umsetzung von Prinzipien in konkretes, zielgerichtetes Handeln mit verifizierbaren Ergebnissen Konzept: Grundvorstellung über Gegenstände und Ergebnisse der Entwicklung Notation: Darstellung von Konzepten durch Symbole, bestehend aus Syntax, Semantik und Pragmatik Allgemeine Prinzipien Einfachheitsprinzip: Make it simple Abstraktionsprinzip: Modellbildung,... Strukturierungsprinzip: Hierarchisierung, Modularisierung, Verfeinerung,...

22 Software-Engineering 22 Lokalitätsprinzip: Geschlossenheit,... Geheimnisprinzip: Information-Hiding,... Standardisierungsprinzip: Wiederverwendung,... Prinzip später Entscheidungen: Familienprinzip,... Kybernetisches Prinzip: Selbstregelung,... Wirtschaftlichkeitsprinzip: Effizienz, ökonomisches Prinzip,... Einfachheit (Software-Komplexität) Einfachheit ist Mangel an Komplexität Logische und strukturelle Komplexität Komplexität im Software-Entwicklungsprozess Maßnahmen zur Komplexitätsbeherrschung Strategien (grundlegende Vorgehensweisen) Top-down-Strategie: vom Groben ins Detail, schrittweise Verfeinerung

23 Software-Engineering 23 Bottom-up-Strategie: Identifikation elementarer Bestandteile, Zusammensetzung zu größeren Einheiten Inside-out-Strategie: Betrachtung der wichtigsten Bestandteile, danach derjenigen, die unmittelbar mit den bereits betrachteten in Zusammenhang stehen Outside-in-Strategie: Erst Black-box- danach White-box- Betrachtung Software-Lebenszyklus (Vorgehensmodelle) Modellierung der Lebensdauer eines Produktes von der Entwicklung (Geburt) bis zur Aussonderung (Tod) Zerlegung des gesamten Lebenszyklus in Teilbereiche (Entwicklung, Einführung, Betrieb, Aussonderung) Festlegung der zeitlichen und sachlichen Beziehungen zwischen den Teilbereichen Festlegung von Verfahren in den Teilbereichen

24 Software-Engineering 24 Beispiel Vorgehensmodell für die Entwicklung Entwicklungsplanung: Entwicklungsplan Anforderungsanalyse: Beschreibung organisatorischer Zusammenhänge Fachentwurf: Beschreibung Anwendungssystem aus Benutzersicht DV-Entwurf: Beschreibung programmtechnischer Zusammenhänge DV-Implementierung: Realisierung des DV-Entwurfs 2.3 Software-Architektur Beziehen sich auf die Architektur eines Programms oder Computersystems Bestehen aus Software-Komponenten (-Bausteinen) sowie deren nach außen sichtbaren Eigenschaften und Beziehungen

25 Software-Engineering 25 Definieren Entwicklungsregeln und Bedingungen für die Komponenten (Vorgaben für Schnittstellen, funktionale und qualitative Spezifikationen) Ergebnis: Logische und physische Struktur eines Software- Produktes Software-Architektur-Modell-Muster (Stile) Haupt-/Unterprogramm-Architektur Schichten-Architektur Client/Server-Architektur Ereignisorientierte Architektur Pipes/Filters-Architektur Repository-Architektur Interpreter-Architektur Prozess-Kontroll-Architektur

26 Software-Engineering Haupt-/Unterprogramm-Architektur Modul A Out 1 InOut 4 Modul B In 2 Flag 3 Modul C Modul D Modul E Out 5 Modul F Modul G Modul H Abbildung 1: Haupt-/Unterprogramm-Architektur

27 Software-Engineering Schichten-Architektur Usually procedure calls Useful systems Base utility Core Level Users Composites of various elements Quelle: Shaw/96, S. 25 Abbildung 2: Schichten-Architektur

28 Software-Engineering Client/Server-Architektur R/3 Applikationsserver R/3 Datenbankserver Clients Quelle: SAP/NN Abbildung 3: Client/Server-Architektur

29 Software-Engineering Pipes/Filters-Architektur Filters Pipes Quelle: Shaw/96, S. 21 Abbildung 4: Pipes/Filters-Architektur

30 Software-Engineering Aufgaben Diskutieren und erläutern Sie mit eigenen Formulierungen die Inhalte der dargestellten allgemeinen Software- Entwicklungsprinzipien. Benennen Sie 10 international bekannte Autoren der Softwaretechnik und skizzieren Sie deren fachliche Leistung.

31 Software-Entwicklungsprozess 31 3 Software-Entwicklungsprozess Prozess-Modelle Fester organisatorischer Rahmen für die Software-Erstellung Vorgabe von Aktivitäten, Teilergebnissen und Qualitätskriterien Vorgabe der Reihenfolge des Arbeitsablaufs Vorgabe von Mitarbeiterqualifikation, Verantwortlichkeiten, Kompetenzen, Standards, Richtlinien, Methoden und Werkzeugen Prozess-Modell-Arten Wasserfall-Modell V-Modell Prototypen-Modell Evolutionäres Modell

32 Software-Entwicklungsprozess 32 Nebenläufiges Modell Spiral-Modell Objektorientiertes Modell 3.1 Wasserfall-Modell (Boehm/81) Systemanforderung Softwareanforderung Analyse Entwurf Kodierung Test Betrieb Abbildung 5: Wasserfallmodell nach Boehm/81

33 Software-Entwicklungsprozess 33 Eigenschaften Keine Änderung der Anforderungen während der Entwicklung Vollständiges Phasenergebnis nach Phasenabschluss Wiederholung der zuletzt abgeschlossenen Phase bei Qualitätsmängeln Benutzerbezogene Präsentation erst nach Fertigstellung Sehr gute Planbarkeit, jedoch oft unrealistisch

34 Software-Entwicklungsprozess V-Modell (Wasserfall-Modell-Erweiterung) Anwendungsszenarien (Validierung) Abnahmetest Grobentwurf Testfälle (Verifikation) Systemtest Feinentwurf Testfälle (Verifikation) Integrationstest Testfälle (Verif.) Anforderungsdefinition Modulimplementierung Modultest Abbildung 6: V-Modell (Wasserfallmodell-Erweiterung) Eigenschaften Überprüfung von Zweck und Eignung (Validierung) Überprüfung von Spezifikation und Produkt (Verifikation) Entwickelt für Behörden, Einsatz auch in der Industrie

35 Software-Entwicklungsprozess 35 Submodelle: Systemerstellung (SE), Qualitätssicherung (QS), Konfigurations- (KM), Projektmanagement (PM) 3.3 Prototypen-Modell Prototyp- Anforderung Prototyp- Entwurf Prototyp- Realisierung Bewertung Abbildung 7: Prototypenmodell Ingenieursmäßige Entwicklung

36 Software-Entwicklungsprozess 36 Eigenschaften Entstehung aus den Nachteilen der klassischen Phasenmodelle, die Anforderungen als bekannt voraussetzen Prototyping zur Risikominderung bei unbekannten Anforderungen und Technologieproblemen Planung und Prototyping kein Gegensatz Arten Exploratives Prototyping: Kommunikationsmedium zur Ermittlung von Anforderungen Experimentelles Prototyping: Ermittlung unbekannter Eigenschaften eines Systems Evolutionäres Prototyping: Inkrementelle Entwicklung vom explorativen Prototyp bis hin zum fertigen Produkt

37 Software-Entwicklungsprozess 37 Horizontaler und vertikaler Prototyp Benutzeroberfläche Anwendung Kommunikation Datenhaltung Systemsoftware Abbildung 8: Horizontaler und vertikaler Prototyp

38 Software-Entwicklungsprozess Evolutionäres Modell Nullversion X := 0 Versions- Definition X Versions- Entwurf X Anforderungen X := X + 1 Versions- Realisierung X Versions- Einsatz X Abbildung 9: Evolutionäres Modell

39 Software-Entwicklungsprozess 39 Eigenschaften Evolutionäres Prototyping als Ausgangspunkt Gesamtentwicklung über mehrere Versionen Produktiveinsatz der Versionen Pflegeaktivitäten als eigene Versionen

40 Software-Entwicklungsprozess Nebenläufiges Modell Gesamtsystem- Definition Gesamtsystem- Zerlegung Kernsystem- Definition Kernsystem- Entwurf Erweiterungs- Definition 1 Kernsystem- Realisierung Erweiterungs- Entwurf 1 Erweiterungs- Definition 2 Erweiterungs- Realisierung 1 Erweiterungs- Entwurf 2... Erweiterungs- Realisierung Abbildung 10: Nebenläufiges Modell Eigenschaften Parallelisierung der Aktivitäten Optimierte Zeitausnutzung

41 Software-Entwicklungsprozess 41 Hohes Risiko, dass Grundlagen-Entscheidungen zu spät getroffen werden Hoher Planungs- und Koordinationsaufwand

42 Software-Entwicklungsprozess Spiral-Modell (Boehm 1988) schrittweises Vorgehen Ziele, Alternativen, Einschränkungen Risikoanalyse Prototypen Planung nächste Phasen Life-Cyle-Plan Validierung Entwicklungsplan Integration u. Test Validierung Integ. u. I.- Test Abnah.- Test Installation Entwurf Vorgehensmodell Anforderung Feinentwurf Kodierung Komp.- Test Abbildung 11: Spiralmodell (Boehm 1988)

43 Software-Entwicklungsprozess 43 Spiralzyklus-Folge Festlegen der Ziele, Lösungsvarianten, Nebenbedingungen und Einschränkungen Evaluation der Alternativen, Analyse der Risiken, Festlegen von Strategien zur Risikoüberwindung Festlegen bzw. Umsetzen des Prozessmodells Planen nächster Zyklus, Überprüfen der Planung, Genehmigen der Planung Eigenschaften Integration unterschiedlicher Prozessmodelle (Metamodell) Keine Trennung von Entwicklung und Wartung Strikte Ausrichtung am Entwicklungsrisiko Repräsentation der kumulierten Kosten durch Spiralfläche

44 Software-Entwicklungsprozess Unified Software Development Process Core Workflows Phases Inception Elaboration Construction Transition Requirements Analysis Design Implementation Test iter. #1 iter. #2 iter. # iter. #n-1 iter. #n Abbildung 12: Unified Software Development Process

45 Software-Entwicklungsprozess 45 Phasen eines Zyklus Startphase (inception): Darstellen des Endproduktes und der wichtigsten Geschäftsvorfälle, Planen der nächsten Phasen Ausarbeitungsphase (elaboration): Ausarbeiten aller Produkt- Use-Cases, der System-Architektur und der Anforderungen an die Bausteine, Realisieren kritischer Geschäftsvorfälle, Planen des Gesamtprojektes Konstruktionsphase (construction): Realisierung des Gesamtproduktes Überführungsphase (transition): Benutzertest des Produktes, Beseitigen von Fehlern, Vorbereiten nächstes Release Eigenschaften Use-case-gesteuert Architektur-zentriert interativ und inkrementell

46 Software-Entwicklungsprozess 46 Modelle des Unified-Process Use-Case-Modell Analyse-Modell Design-Modell Entwicklungs-Modell Implementierungs-Modell Test-Modell 3.8 Aufgaben Planen Sie den Bau Ihres Einfamilienhauses jeweils nach dem Wasserfall-Modell, dem evolutionären Modell und dem Spiral-Modell. Erläutern Sie die Eigenschaften des Unified Process (objektorientierten Modelles).

47 Methoden und Ergebnisse der Entwicklungsphasen 47 4 Methoden und Ergebnisse der Entwicklungsphasen Phasengliederung Planungsphase Definitionsphase (requirements) Analysephase (analysis) Entwurfsphase (design) Implementierungsphase (implementation, test) Überführungsphase Betriebsphase

48 Methoden und Ergebnisse der Entwicklungsphasen 48 Gesamtüberblick Phase, Ergebnis, Methode Phase Ergebnis Methode Planung Projektdefinition (Lastenheft) Methoden der Projektplanung Definition Pflichtenheft Analyse Entwurf Implementierung Produkt Organisation, Software, Hardware Methoden des Business (Re-)Engineering, System Engineering, Software Engineering Überführung Produktionssystem Methoden des Tests, der Schulung, der Einführung Betrieb Leistung Methoden des Software Reenginering (Wartung), der Betriebsplanung und -steuerung Abbildung 13: Gesamtüberblick: Phase, Ergebnis, Methode

49 Methoden und Ergebnisse der Entwicklungsphasen 49 Partialmethoden Zeit Phase Definition Analyse Entwurf Implementierung Funktionsgliederung (-dekomposition) Petri-Netze-Modellierung Objektorientierte Programmierung Strukturierte Programmierung Relationale Datenmodellierung Abstrakte Datentypen Entity-Relationship-Ansatz Datenfluss-Modellierung OO-Design OO-Analyse Abbildung 14: Partialmethode

50 Methoden und Ergebnisse der Entwicklungsphasen 50 Gesamtmethoden 1974 Hierarchy-plus-Input-Process-Output (HIPO), Top-down, IBM: Funktionsdekomposition, Eingabe-Verarbeitung-Ausgabe-Diagramme (EVA), Strukturierte Programmierung 1979 Strukturierte Analyse und Strukturiertes Design (SA/SD), Top-down: Kontextdiagramm, Datenflussanalyse, Funktionsdekomposition, Datenstrukturierung, Datendiktionär, Structure Chart, Kohäsion/Bindung, Strukturierte Programmierung. Varianten: SSADM, Merise, Isotec, EuroMethod Information Engineering (IE), Top-down, J. Martin: Strategic Planning (Business Objects, Subject Areas), Entity and Data Analysis, Process Analysis. Varianten: IEW, IEF, ADW, AD-Cycle 1986 Moderne Strukturierte Analyse und Strukturiertes Design, Top-down/Bottom-up (Moderne SA/SD): Umgebungsmodell (Kontextdiagramm, Ereignisliste, ER- Modell), Verhaltensmodell (Datenfluss-Analyse), Benutzermodell, Implementierungsmodell, Transaktions-/Transformationsanalyse, Structure Chart Objektorientiertes Software Engineering (OOA, OOD, OOP): Statisches und dynamisches Modell, Klassenhierarchie, Komponenten, Client- Server, Design Pattern. Varianten: OMT, UML Abbildung 15: Gesamtmethode

51 Methoden und Ergebnisse der Entwicklungsphasen Planungsphase Ziele/Ergebnisse der Planungsphase Ziel: Begründung und Entscheidung der Notwendigkeit, Dringlichkeit und Durchführbarkeit der Entwicklung Ergebnis: Projektdefinition (inklusive Lastenheft) Entscheidung: Durchführung der Entwicklung (stop or go) und ggf. zeitlicher Bezug der Durchführung Prinzipien der Planungsphase Zielvereinbarung Planung von Produkt und Prozess Personifizierte Verantwortung Wirtschaftlichkeitsprinzip Risikoabschätzung

52 Methoden und Ergebnisse der Entwicklungsphasen 52 Methoden der Planungsphase Zielformulierung Projektplanung Durchführbarkeitsstudie Methode: Zielformulierung Zieldefinition Ein Ziel ist eine normative Aussage eines Entscheidungsträgers über einen zukünftigen Zustand, der durch aktives Handel erreicht werden soll. Zielquantifizierung Zielinhalt: Festlegung der Eigenschaften eines angestrebten Zustands (Sachziel) bzw. einer angestrebten Qualität oder Güte (Formalziel)

53 Methoden und Ergebnisse der Entwicklungsphasen 53 Zielmaßstab: Festlegung der Dimension des Zielinhaltes und der Messvorschrift Ausmaß der Zielerreichung: Festlegung der Quantität des Zielinhalts, die erreicht werden soll Zeitlicher und räumlicher Bezug der Zielerreichung: Festlegung des Zeitraums oder -zeitpunkts sowie des Ortes, an dem das angestrebte Zielausmaß erreicht werden soll Methode: Projektplanung Die Projektplanung gliedert sich in folgende Teilplanungen, die auch nur in der dargestellten Reihenfolge durchgeführt werden können: Strukturplanung Aufwandsschätzung Terminplanung Einsatzmittelplanung

54 Methoden und Ergebnisse der Entwicklungsphasen 54 Kostenplanung Strukturplanung Produktstrukturplan: alle auszuliefernden Objekte und ihre Bestandteile in hierarchischer Gliederung Projektstrukturplan: alle Tätigkeiten in hierarchischer Gliederung Arbeitspaket: geschlossene, plausible Arbeitsmenge mit Ergebnis, Qualität und Qualifikationsanforderung Aufwandsschätzung Ressourceneinsatz zur Erreichung der Projektziele

55 Methoden und Ergebnisse der Entwicklungsphasen 55 Mengengerüst Einflußgrößen Aufwandsschätzmethode Aufwand Abbildung 16: Aufwandsschätzung (Ressourceneinsatz zur Erreichung der Projektziele)

56 Methoden und Ergebnisse der Entwicklungsphasen 56 Einfache Aufwandsschätzmethode Arbeitspaket Schätzeinheit Mengengerüst Nettoaufwand Zuschläge Bruttoaufwand Kosten Abbildung 17: Einfache Aufwandsschätzmethode

57 Methoden und Ergebnisse der Entwicklungsphasen Methode: Durchführbarkeitsstudie Prüfung der Vollständigkeit der Anforderungen Prüfung der Konsistenz der Anforderungen Prüfung der technischen Durchführbarkeit Prüfung der personellen Voraussetzungen Ökonomische Rechtfertigung Ergebnis: Projektdefinition Identifikation: Name, Kurzbeschreibung, Auftraggeber Organisation: Projektinstanzen Zielsetzung: Problembeschreibung, betriebliche Ziele, Projektziele, Rahmenbedingungen, Zielerreichung Produkt: Lastenheft, Produktstruktur Ablauf: Projektstruktur, Aufwandsschätzung, Meilensteine Wirtschaftlichkeit, Risiko

58 Methoden und Ergebnisse der Entwicklungsphasen 58 Lastenheft Anwendungsziele, -bereiche, Anwender Funktionsanforderungen Produktdaten Leistungsanforderungen Qualitätsanforderungen Ergänzende Anforderungen Aufgaben Bewerten Sie folgende Zielsetzung Das Programm verbessert die Auftragsbearbeitung.. Erstellen Sie eine fiktive Projektdefinition für das Software- Praktikum Ihrer Gruppe, in der Sie eine frei zu wählende Internet-Anwendung entwickeln sollen.

59 Methoden und Ergebnisse der Entwicklungsphasen Definitionsphase Ziele/Ergebnisse Ziel: Festlegung der fachlichen Anforderungen und technischen Rahmenbedingungen Ergebnis: Liste der Anforderungen Ziele/Ergebnisse Ziel: Festlegung der Systemabgrenzung, der fachlichen Anforderungen sowie technischen und organisatori-schen Rahmenbedingungen (requirements) Ergebnis: grobe Systemspezifikation (Grenzen, Umgebung, Schnittstellen, wesentliche Komponenten), Glossar, Liste der Anforderungen Synonym: Problemanalyse, Anforderungsanalyse, Requirements Analysis

60 Methoden und Ergebnisse der Entwicklungsphasen 60 Prinzipien Fachliche Vollständigkeit und Korrektheit Fachliche Verständlichkeit und Prüfbarkeit Strikte Unterscheidung in physische und logische Spezifikation Methoden Erhebungsmethoden: Interview, Besprechung (Workshop), Aufschreibung, Beobachtung, Dokumentenstudium, Schätzung Analysemethoden: Structured-Analysis, Modern-Structured- Analysis, Object-Orientied-Analysis Methode: Structured-Analysis Die Definitionsphase innerhalb der Structured-Analysis wird als Übersicht (survey) bezeichnet und von den Tätigkeiten her als

61 Methoden und Ergebnisse der Entwicklungsphasen 61 eine Art Mini-Analyse (mini-analysis) verstanden, d.h., sie beinhaltet dieselben Tätigkeiten wie die nachfolgende Analysephase jedoch in reduzierter Form. Eine genauere Festlegung wird dabei nicht vorgenommen. Die Phasen Survey und Analysis bestehen aus folgenden Bestandteilen: Kontextdiagramm (context diagram) Funktionale Dekomposition (functional decomposition) Datendiktionär (data dictionary) Prozess-Spezifikation (process specifiation)

62 Methoden und Ergebnisse der Entwicklungsphasen Kontextdiagramm Student Anmeldung Vorlesung/Prüfung Professor Bestätigung Anmeldung Liste Teilnehmer Nachweis Leistung Hochschulsystem Meldung Noten Abbildung 18: Structured-Analysis: Kontextdiagramm

63 Methoden und Ergebnisse der Entwicklungsphasen Funktionale Dekomposition Anmeldung Vorlesung/Prüfung Bestätigung Anmeldung Liste Teilnehmer Meldung Noten Anmeldesystem Notenverwaltung Nachweis Leistung Student Veranstaltung/ Prüfung Note Abbildung 19: Structured-Analysis: Kontextdiagramm

64 Methoden und Ergebnisse der Entwicklungsphasen Datendiktionär Anmeldung Vorlesung/Prüfung = Student + 1{[Vorlesung Prüfung]+Termin}n Student = Matr.Nr + Name + Geburtsdatum + Adresse Adresse = Straße + + StraßenNr +, + PLZ + + Ort Geburtsdatum = Datum Prozess-Spezifikation Pseudocode-Beschreibung (Structured English, Structured Text) Entscheidungstabellen Entscheidungsbäume Methode: Modern-Structured-Analysis Die Definitionsphase innerhalb der Modern-Structured-Analysis wird als Erstellung eines Umgebungsmodells bezeichnet. Das Umgbungsmodell bestehen aus folgenden Bestandteilen:

65 Methoden und Ergebnisse der Entwicklungsphasen 65 Textliche Beschreibung des Systemzwecks (statement of purpose) Kontextdiagramm (context diagram) Ereignisliste (event list) Datendiktionär (data dictionary) Die textliche Beschreibung des Sytemzwecks ist eine in Prosatext (Umgangssprache) formulierte Festlegung der Systemziele und ergebnisse. Sie entspricht dem Ergebnis der Projektplanung der Projektdefinition in weniger formalisierter Form. Das Kontextdiagramm ist bis auf wenige Erweiterungen (externe Speicher zur Darstellung von externen Datenbanken) identisch mit dem der Structured-Analysis und wird hier nicht nochmals dargestellt. Dies gilt ebenfalls für die Erstellung des Datendiktionärs.