Software Engineering I über die Veranstaltung 2-semestrig SE-I : Einführung, allgemeine Aspekte, punktuelle Vertiefung SE-II: Vertiefung, CASE mit Werkzeugeinsatz und Projekten je nach Dozent Vorlesung / Übung 4 SWS (+ 2x Übungsgruppe je 2 SWS) Übungsmodi: Vortrag (Ergänzung der Vorlesung) Übung im Plenum (alle) Übung in den Gruppen Projektaufgabe(n) in Projektgruppen Übungsaufgaben Leistungsnachweis durch Klausur (90 min) Teilnahmeberechtigung erwerben durch Praktikum nur im WS!! keine Klausurteilnahme für Teilnehmer ohne Berechtigung zum Hauptstudium!! kein LNW für Praktikum im SS möglich!! im SS nur echte Wiederholung oder Erstablegung für HS-Berechtigte des verg. WS 2
Übersicht 1. Was ist Software-Engineering? Einordnung innerhalb der Informatik Teildisziplinen Grobmodell(e) 2. Lebenszyklus-Modell 3. Prozess-Modelle 4. Software-Projekte und ihr Management 5. Elemente des Software-Entwicklungsprozesses 1. Anforderungsanalyse / Requirements Engineering / Requirements Specification 2. System-Entwurf 3. Prototyp-Entwicklung und Simulation 4. Programmentwurf 5. Programmtest 6. Systemtest und Integration 7. Auslieferung 8. Wartung 9. Auswertung und Verbesserung 3
1. Was ist Software-Engineering? Die Software-Krise 1968 -? Karikatur der Software-Produkte (aus den 70ern): nach Erhebungen der IBM: ein Produkt verlangter Funktionsumfang 100% : 15% der Funktionen nicht geliefert 30% der Funktionen nie gebraucht, aber implementiert 15% fehlerhaft übergeben so nicht gemeint 10% nicht verlangt / bestellt, aber enthalten 30% wirklich dauerhaft eingesetzt was ist passiert? - Abgleich Funktionalität / Anforderungen bzw. Vereinbarungen - Abgleich Funktionalität / Einsatzumgebung / Gesamtbetrieblicher Prozess (Workflow) - Programmtest / Integrationstest - Abgleich Funktionalität / Anforderungen Blickwinkel auf die "Informatik" im Unternehmen Werkzeug, Hilfsmittel Automatisierung, Rationalisierung (Mark und Pfennig) Wenig Sinn für Qualitätsgedanken, Strategische Komponente eines Unternehmens im Sinne dessen Zielsetzung 4
Was ist Software-Engineering? Einflüsse auf das Software-Engineering Technik Rechnersysteme Projektorganisation Prozesse Programmiersprachen Techniken Methoden menschlich allzu Menschliches Methoden der Teamarbeit Personalführung "human ressource management" SE Prozess betriebl. Organisationen Ziele des Betriebs Arbeitsabläufe u. Ergebnis Qualitätsansprüche Wiederverwendbarkeit Sicherheit, Robustheit Änderungsfreundlichkeit Auftraggeber Entscheidungskriterien Klarheit der Vorstellungen Leistung soft factors (sekundäre Ziele) 5
Was ist Software-Engineering? Arbeitsdefinition Software-Engineering ist das geplante, systematische Vorgehen bei der Herstellung von Software unter Anwendung von Methoden und Werkzeugen der Informatik, der Betriebswirtschaft und des Personalwesens mit dem Ziel, qualitativ hochwertige Software wirtschaftlich zu produzieren. (häufiges Synonym: "ingenieurmäßige" Software-Entwicklung [z.b. Siemens]) 6
Was ist Software-Engineering? Problemlösen zu lösendes Problem oft unabhängig von Computer / Software Verstehen der Natur des Problems (des informatischen Kerns) kein Überstülpen von Informatik über das/jedes Problem erst Problemlösen wenn nötig, Technologie als Werkzeug für Implementation der Lösung nutzen 7
Umgang mit Komplexität Umgang mit Komplexität Analyse Komplexitätsreduktion Synthese Problem Zerlegung in Teilprobleme P1 P2 P3 P4 Lösung L1 L2 L3 Synthese L4 L1 L2 L3 L4 8
Einordnung innerhalb der Informatik Teilgebiet der praktischen Informatik: die Methodenlehre objektorientierte SW-Entwicklung mit UML Entity-Relationship-Modellierung zum Design von Informationssystemen Strukturierte Programmierung Objektorientierte Analyse und Design Jackson Structured Design (JSD). Teilgebiet der angewandten Informatik: die Pragmatik der Anwendung von Informatik- und anderen Methoden zur Herstellung von Software- Produkten bzw. zur Lösung konkreter Probleme Planung der Prozessinteraktionen in einem Echtzeitsystem mit Petri-Netzen Konzeptioneller Entwurf eines Informationssystems Regelbasierte Beschreibung eines Diagnosesystems Anwendung des Konzepts des "Chief Progammer Teams" für die Kooperationsstruktur im SW-Projekt Zustandsgraph-Beschreibung für Dialogsystem Hier: Prozessorientierte Sicht (2. Punkt) 9
Standpunkt in der Lehrveranstaltung ~ Leitfragen entsprechend dem pragmatischen Standpunkt Problem ABC Welche Methoden gibt es für den Problembereich ABC? Wie "funktionieren" sie? Wie kann ich das Problem darin ausdrücken? Welche Grenzen haben die Methoden? Wie verwende ich die Ergebnisse? Wie kann ich die Methoden und ihre Ergebnisse bewerten?. Software-Engineering ist das Vorgehen zur Lösung von Problemen, die Rechner- und Softwareeinsatz erfordern. 10
Teildisziplinen Methoden zur Gewinnung und Beschreibung von Anforderungen (Requirements) Systemanalyse, Anforderungsanalyse Modellierung Definition Entwurf (Design) Grob-, Feinentwurf Dekomposition, Modularität System-Architektur Auswertung, Bewertung, Validierung Programmentwicklung Programmier-"Paradigma" und Folgen Programmtest Fehlermodelle Modultest, Einzeltest, Integrationstest Systemtest Funktionstest, Leistungsbewertung, Sicherheitstests 11
Teildisziplinen - 2 Abnahmetest Übergabe Einführung (i.d. Betrieb) Schulung, Einarbeitung Dokumentation Wartung und Pflege Versions-Management Change-Management 12
2. Lebenszyklus-Modell der Softwarelebenszyklus ist ein Grobmodell für den Prozess der Herstellung und Anwendung von Software über die gesamte Lebensdauer, beginnend bei der Idee, endend mit der Ausmusterung bzw. der Idee für die Ablösung. Phasen: 1. Idee, Planung 2. Systemanalyse 3. Entwurf 4. Implementierung 5. Tests 6. Auslieferung / Einführung 7. Wartung / Pflege 8. Auswertung 9. Redesign Prozess (Merkmale): Aktivitäten, Ressoursen, Randbedingungen, Abläufe, Verfahren Ablaufpläne Prozessphasen: selbst wiederum Prozesse 13
SW - Lebenszyklus Auswertung Idee, Planung Redesign Systemanalyse Wartung / Pflege Entwurf Auslieferung / Einführung Implementierung Ideal Tests 14
SW - Lebenszyklus Auswertung Idee, Planung Redesign Systemanalyse Wartung / Pflege Entwurf Auslieferung / Einführung Implementierung Realität Tests 15
3. Software-Prozess Prozess-Modelle (= Vorgehensmodelle) welche Aktionen im SW-Lebenszyklus identifiziert / auszuführen? zu welcher Zeit? mit welchem Ergebnis? Phasenmodelle: Wasserfallmodell V-Modell Prototypingmodell Evolutionäres Modell (iteratives) Spiralmodell Transformationsmodell >> Phasen des SW-Lebenszyklus in einem modellspezifischen prozessualen Zusammenhang << 16
Wasserfallmodell (US DoD, Royce 1970) Voruntersuchung Anforderungsanalyse Systementwurf nächste Aktion Programmentwurf Realisierung Einzel- u. Integrationstest Systemtest Rückschritt Abnahmetest Wartung, Pflege 17
Wasserfallmodell Welcher Fehler verursacht größere Kosten : ein Konzeptfehler, der in Programmentwurfsphase gefunden wird oder einer, der im Systemtest gefunden wird? Warum? Sagt das Wasserfallmodell etwas über die Tätigkeiten aus, die bei Änderungswünschen auf den verschiedenen Stufen auszuführen sind? Was ist zu tun, wenn in der Testphase EINZELTEST erkannt wird, dass die Software eine geforderte Funktion / Bedingung nicht erfüllt? Vorteile: klare einfache Struktur, feste Ergebnisse einer Phase, linearisierter Lebenszyklus Nachteile: beschreibt nur die Artefakte, die am Ende einer Phase zu erzeugen sind, als Schnittstelle zur nächsten Phase keine Hinweise auf die Behandlung von Änderungen des Produkts oder der Aktivitäten während der Entwicklung abgestimmt auf Produktion mit Wiederholungsfaktor, nicht auf Prototypentwicklung " software is a creation process, not a manufactoring process. " 18
Wasserfallmodell mit Prototypentwicklung Voruntersuchung nächste Aktion Anforderungsanalyse Überprüfung Systementwurf Programmentwurf Verifikation Realisierung Prototyp Entwicklung Einzel- u. Integrationstest Systemtest Abnahmetest Wartung, Pflege Rückschritt 19
Wasserfall mit Prototyping Welche Vorteile bietet die Entwicklung eines Prototypen? 20
Wasserfall mit Prototypentwicklung Ausführen / Untersuchen des Prototyps : Kommunikation zwischen Entwickler und Auftraggeber ermöglichen Anforderungen überprüfen ist gewünscht? Umgang, Hantierung, Oberfläche überprüfen weitere Klärung zwischen Vertragspartnern Erkenntnisgewinn 21
V Modell (BM M f. Verteidigung 1992) Voruntersuchung Anforderungsanalyse überprüfe Anforderungen Abnahmetest Wartung, Pflege verifiziere Entwurf Systementwurf Programmentwurf verifiziere Entwurf Systemtest Einzel- u. Integrationstest Realisierung 22
V - Modell Welche Beziehungen bestehen zwischen den V-Schenkeln? Wie sind die Beziehungen zu interpretieren? Welche Tätigkeiten macht dieses Modell explizit? 23
V - Modell Beziehungen zwischen einander entsprechenden Anforderungen und Realisierungen bzw. Entwurfs- und Realisierungsebenen Interpretation im Sinn eines Feedback zur Überprüfung gewollte Rückwärtsschritte zur Validierung / Verifikation nicht im Wasserfallmodell enthalten bzw. als Aktionen vorgesehen 24
Prototyping Modell Revisionsliste Revisionsliste.... ünberprüfe Prototyp Benutzer- / Kunden- Review System- Anforde -rungen Prototyp Anforderungen Prototyp Entwurf Prototyp System Test ausgeliefertes System Fortlaufender Prototyping-Prozess zur Klärung der Aufgaben, kontinuierllichen Entwicklung des Systems, Reduktion von Risiken und Unsicherheiten 25
Prototyping Modell Prototyp ist Gegenstand der Kommunikation zw. Entwickler und Auftraggeber früher Test der Machbarkeit, der Akzeptanz, der Integration Prototyp mutiert über Revisionsphasen zum Produkt penible Revisionsarbeit nötig Revisions- und Versionsverwaltung regelmäßige / ständige Kommunikation nötig 26
Spiral Modell, evolutionäres Modell (Böhm 1988) Ziele, Alternativen, Randbedingungen Alternativen und Risiken auswerten Prototypen i Planen concept of operation validated requiorements Entwickeln und Testen validated design acceptance test 27
Spiral Modell / evolutionäres Modell (Böhm 1988) welche Zyklen / Iterationen sind zu identifizieren? in welcher Phase entstehen welche Dokumente / Ergebnisse? 28
Transformationsmodell (Balzer 1981) Revision / Vgl. mit Requirements Abfolge, Entscheidungen Transformation i Transformation Transformation Transformation System- Anforde -rungen Formale Spezifikation Test ausgeliefertes System Transformationen z.b.: Datendarstellungen, Algorithmenwahl, Optimierung, Compilation in Zielsprachen, Compilation in Zielmaschinenspr. 29
Transformationsmodell Einsatz einer formalen Spezifikationssprache (halb-) automatische Überführung in Realisierungsstufen abhängig von formalen Methoden Kunstaspekt der Software-Entwicklung / Programmierkunst soweit wie möglich ausgeklammert Kreativität beschränkt auf die Erfassung der Anforderungen 30
Wünschenswerte Eigenschaften von Prozessmodellen ein gutes Prozessmodell 1. ermöglicht Verständnis und Kommunikation gleichermaßen durch Auftraggeber und Entwickler, Nutzer, Ausführende des Prozesses 2. unterstützt die Verbesserung des Prozesses bei Wiederholung ganz oder in Teilen, den Erkenntnisgewinn über den Prozess 3. unterstützt Abwicklung und Verwaltung des Prozesses: Planung Abschätzung, Überwachung (Monitoring), Auswertung 4. ermöglicht die Unterstützung des Prozesses durch Werkzeuge auf den versch. Ebenen 5. kann in Teilen automatisiert werden 31
Fragen Vor und Nachteile der einzelnen Prozessmodelle Wie geht man in den einzelnen Prozessmodellen mit signifikanten Änderungen der Anforderungen in einer späten Entwicklungsphase um? Welches Modell erscheint Ihnen in dieser Hinsicht als das beste? Welche Charakteristiken der Prozessmodelle sind wesentlich für den Einsatz in einer Umgebung mit unklarem Problem- und Lösungswissen? 32
Software-Projekte und ihr Management Projekt Vorhaben mit folgenden Eigenschaften: zeitlich abgegrenzt (Terminvorgabe) auf ein vorgegebenes Ziel gerichtet (Zielvorgabe) mit Budget ausgestattet, komplex, innovativ neuartiges / einmaliges Problem, organisatorische Querschnittsaufgabe Bewältigung im Rahmen der Normalorganisation nicht vorgesehen oder nicht effektiv und effizient möglich -> Sonderaufgabe intensive Kooperation verschieden qualifizierter Fachleute aus unterschiedlichen Bereichen -> Teamarbeit, interdisziplinär 33
Software-Projekte und ihr Management - 2 Software-Entwicklung -> 2 Seiten: Vorgehensmodell <- WIE Projekt <- WER, WAS, WANN, zu welchen KOSTEN Analyse Entwurf Realisierung Projektmanagement Abgrenzung: Systementwicklung Projektmanagement Einführung 34
Software-Projekte und ihr Management - 3 Projektmanagement: 3 Aufgaben des Projektleiters Planung Überwachung Steuerung Ausführung: Projektteam Projektmitarbeiter Kompetenzfeld Team-Typ Projektleiter Projektteam (nicht hierarchiefrei) 35
Software-Projekte und ihr Management - 4 Projektplanung termingerechter Teilaufgaben wirtschaftlicher Mitteleinsatz Abschluss Grundplanung Planungsauftrag formulieren Ziele u. grundsätzliche Lösungsmöglichkeiten erarbeiten Aufwandsschätzung: (schwierig) Zeit, Mitarbeiter, Sachmittel, Kosten Terminvorschläge Entscheidungsreife 36
Software-Projekte und ihr Management - 4 Ausführungsplanung (Detailprojektierung) Projektorganisation Koordination durch Stabstelle (Projektkoordinator, keine Linienkompetenz) Task-Force-Organisation (volle Autorität; Parallellinie; Projektleiter) Matrix-Organisation (Dimensionen; Kompetenzkreuzung; Koordinationsfähigkeit) Probleme: Schnittstelle Projekt-/Normalorganisation Beteiligung der betroffenen Vernetzung arbeitsteilig ausgeführter Projekt-Anteile Projektstruktur Zerlegung in Teilaufgaben oder Teilprojekte Sachbezogen (technisch, zeitlich) Funktionsbezogen (organisatorisch, nach Verantwortlichkeiten Organigramm) Projektablauf / Steuerung Einzelaktivitäten, Teilaufgaben und ihre zeitliche Beziehung (Netzpläne, Stufen-, Balkendiagramme) 37
Software-Projekte und ihr Management - 5 Teamarbeit im Projekt Team: überschaubare Gruppe (typisch 7 Personen) gemeinsames (Arbeits-) Ziel beschränkte Mittel (Zeit, Geld) Vorteile der Teamarbeit - Synergie Team weiß mehr Team regt an Team gleicht aus Relevante Gebiete: Kommunikation Transaktionale Analyse Organisationsentwicklung psychologisches Konfliktmanagement Themenzentrierte Interaktion reiches Weiterbildungsfeld für Informatiker 38
Software-Projekte und ihr Management - 6 Zusammenstellung von Teams abhängig von Charakter des Projektes kreativ innovativ technologielastig, fachlich orientiert wirtschaftlich orientiert Persönlichkeitsspektren z.b. Team-Typ-Test nach Meyers-Briggs davon abgeleitet Rollen im Team Ziele: Ergänzung, Ausgleich, verbreitertes Spektrum "Casting"-Situation, Assessment-Center 39
Software-Projekte und ihr Management - 7 Phasen der Team-Entwicklung die Team- Entwicklungs-Uhr Orientierung: höflich, unpersönlich gespannt, vorsichtig Nahkampf unterschwellige Konflikte, Konfrontation der Personen Koalitionen, Cliquenbildung kaum Fortschritt Organisierung Entwicklg. neuer Umgangsformen, Verhaltensweisen, Feedback, Konfrontation der Standpunkte Verschmelzung ideenreich, flexibel, offen leistungsfähig, solidarisch Abschied Ausklang, Resumee Trauerarbeit Reflexion des Projekts Abschluss Abschied Reflexion Verschmelzung Effizienz Organisierung Orientierung Gährung / Klärung Nahkampf 40
Software-Projekte und ihr Management - 8 Arbeitsgruppe <-> Team Zusammensetzung Führung Organisation Gruppe feste Anzahl gleicher FB vgl.bare Kenntnisse feste Aufgaben kaum Wissenstransfer Gruppenleiter Sternorganisation Entscheidung durch GL beständig, nach festen Regeln organisiert indiv. Aufgabenzuordnung (Arbeitsabschnitte) Team feste Anzahl versch. FB Ergänzung der Fähigkeiten Hauptaufgabe, Lastausgleich Transfer Teamleiter meist verteilte Führung gleiche Stimme bei Entscheidungen variabel, selbstorganisiert gemeinsames Ziel neben Linienorganisation umfassende Aufgabenpakete 41
Verfolgen des Projektfortschritts Projektmanagement typische Fragen an das Software-Engineering-Personal: Verstehen Sie mein Problem und meine Anforderungen? Können Sie ein System entwerfen, das mein Problem und meine Anforderungen erfüllt? Wie lange wird es dauern, ein solches System zu entwickeln? Wie viel wird es kosten, Sie ein solches System entwickeln zu lassen? Projekt-Ablaufplan (Schedule) Aktivitäten, Meilensteine, Abhängigkeiten, Reihenfolgen Aufwände (Personen-Tage/Wochen/Monate, Sachaufwände) (Ab-) Lieferungen Aussagen über Termine kritischer Pfad Kapazitäten, Auslastung 42
Projektmanagement Projekt-Ablaufplan (Schedule) erstellen Aktivitäten, Meilensteine, Abhängigkeiten, Reihenfolgen ermitteln Aufwände (Personen- Tage/Wochen/Monate, Sachaufwände) ermitteln (Ab-) Lieferungen klären Phase Projekt Projektgliederung Phasen, Schritte, Aktivitäten identifizieren Schritt Zuordnung von Zeitdauern für die Aktivitäten Meilensteine und Ereignisse Beginn und Ende von Aktivitäten Projekt Phase 1 Phase 2 Phase 3 Schritt 1 Schritt 2 Schritt1 Schritt2 Schritt3 Schritt1 Schritt2 1.1 1.2 1.3 2.1 2.2 3.1 Aktivität 43
Aufwandschätzung Projektmanagement Zuordnung Zeitdauern zu Aktivitäten => Aufwandschätzung Meilensteine und Ereignisse Beginn und Ende von Aktivitäten Function-Point-Methode (A. J. Albrecht 79) 5 Kategorien der Produktanforderungen: Eingabedaten Abfragen Ausgaben Datenbestände Referenzdaten Klassifikation einfach, mittel, komplex Berechnungsformular Bewertung von Einflussfaktoren Berechnung der Function Points Eingabedaten Abfragen Fkt. Ausgaben Datenbestände Referenzdaten 44
Aufwandschätzung: Function Point Methode Projektmanagement Kategorie Anzahl Klasifizierung Gewichtung Zeilensumme Eingabedaten einfach x 3 = mittel x 4 = komplex x 6 = Abfragen einfach x 3 = mittel x 4 = komplex x 6 = Ausgaben einfach x 4 = mittel x 5 = komplex x 7 = Datenbestände einfach x 7 = mittel x 10 = komplex x 15 = Referenzdaten einfach x 5 = mittel x 7 = komplex x 10 = Summe E1 = 45
Aufwandschätzung Function-Point Point-Methode Projektmanagement Einflussfaktoren 1 Verflechtung mit anderen Systemen (0-5) = 2 3 4 a b c d 5 6 7 Summe 1-7 Dezentrale Daten, dezentrale Verarbeitung (0-5) Transaktionsrate (0-5) Verarbeitungslogik Rechenoperationen (0-10) Kontrollverfahren (0-5) Ausnahmeregelungen (0-10) Logik (0-5) Wiederverwendbarkeit (0-5) Datenkonvertierungen (0-5) Anpassbarkeit (0-5) E2 = = = = = = = = = = Einflussbewertung E2 / 100 + 0.7 E3 = Function Points E1 * E3 = 46
Aufwandschätzung Function-Point Point-Methode Projektmanagement 6. Schritt: Ablesen des Aufwands in MM aus Wertepaar-Tabelle (Function Points / MM) Voraussetzung: ausreichende Anzahl ausgewerteter / bewerteter Projekte Beispiel (IBM-Quelle): Function-P. 50 100 150 200 250 300 350.. 2400 2500 2600.. IBM MM 5 8 11 14 17 20 24.. 230 245 263.. 47
Netzplantechnik: Beispiel CPM-Methode Methode Projektmanagement CPM: critical path method Voraussetzungen: Projektgliederung Projekt auf Einzelaktivitäten / Vorgänge gebrochen Einzelaktivitäten / Vorgänge Aufwandschätzung durchgeführt Meilensteine / Ablieferungen definiert Netzwerkdarstellung Vorgangspfeilnetze / Netzpläne 1.4 1.6 1.7 1.2 1.3 1.1 1.5 3 2.5 2.1 2.2 2.4 2.6 2.8 2.3 2.7 48
Netzplantechnik: CPM-Methode Methode Projektmanagement Elemente: Vorgang <Vorgangsbezeichner> mit Anfangsereignis i und Endeereignis j i <Vorgangsbezeichner> (i-j) j Grundregeln: A 1 (1-2) 2 Jeder Vorgang beginnt und endet mit einem Ereignis. j ist Nachfolgeereignis von i. 1 A 2 B 3 C 4 A und B müssen beendet sein bevor C beginnen kann 49
Netzplantechnik: Beispiel CPM-Methode Methode Projektmanagement 1 A 2 B 3 C 4 Ende von A ist Voraussetzung für Beginn von B und C S 1 A 3 A und B besitzen gemeinsames Anfangsereignis Scheinvorgang S 2 B (Zeitdauer von S == 0) A 1 4 S B 2 3 C D 5 6 A, B, C, D: C nach Ende von A und B D nach Ende von B Scheinvorgang S für gemeinsames Ende von A, B und Start von C mit (3, 4) 50
Netzplantechnik: CPM-Methode Methode Projektmanagement B 4 A1 1 2 C A2 5 Beginn von B im Verlaufe von A=A1+A2 3 D 6 C 1 A 3 Netzpläne sind zyklenfrei (ex. keine gerichteten Zyklen) 2 B Zusammenfassung: 1. Kanten sind eindeutig definierte Vorgänge 2. Knoten sind nicht eindeutig definierte Ereignisse 3. Zur eindeutigen Darstellung sind Scheinvorgänge zu verwenden 51
Netzplantechnik: CPM-Methode Methode Projektmanagement Analyse in 3 Stufen: 1. Strukturanalyse 2. Zeitanalyse 3. Kosten- und Kapazitätsanalyse (1) Strukturanalyse in 3 Schritten: Erstellen der Vorgangsliste Entwurf des Netzplans Kontrolle der Grundregeln Vorgangsliste: 1. Welche Vorgänge sind vor dem betrachteten Vorgang abzuschließen? (Vorgänger) 2. Welche Vorgänge können unmittelbar nach dem betrachteten begonnen werden? (Nachfolger) 3. Welche Vorgänge können gleichzeitig zum betrachteten ablaufen? (unabhängig) 4. Welche Vorgänge können zu anderen überlappt ablaufen? 52
Netzplantechnik: CPM-Methode Methode Projektmanagement Beispiel Brückenbau Zs1 Ms Zs2 Vorgangsliste: E1 Pf1 Pf2 E2 Vorgang A allgemeine Planung B Fertigung Einzelteile C Herstellung Endlager E1 D Herstellung Endlager E2 E Herstellung Pfeiler Pf1 F Herstellung Pfeiler Pf2 G Montage Zwischenstück Zs1 H Montage Zwischenstück Zs2 I Montage Mittelstück Ms K Einschwimmen Mittelstück L Eröffnung Direkter Vorgänger - A A A A A B,C,E B,D,E B E,F,I G,H,K 53
Netzplantechnik: CPM-Methode Methode Projektmanagement Entwurf des Netzplans: (Beziehungsschema) aktueller Vorgang A B C D E F G H I K L A x x x x x B x x x C x Vorgänger D E F x x x x x G x H x I x K x L 54
Netzplantechnik: CPM-Methode Methode Projektmanagement Zeichnen Sie zur gegebenen Vorgangsliste und zum angegebenen Beziehungsschema den daraus folgenden Netzplan 5 G C S E 4 S 1 A 2 B F 3 I 8 K 9 L 10 D 6 S S H 7 55
Netzplantechnik: CPM-Methode Methode Projektmanagement (2) Zeitanalyse a) Bestimmen der Vorgangsdauer b) progressive und retrograde Zeitrechnung c) Ermitteln des kritischen Pfades und der Zeitreserven (a)vorgangsdauer bei SW-Projekten durch geeignete Schätzverfahren ermitteln (b) Zeitrechnung: frühest mögliche Beginn- und Abschlusszeiten spätest mögliche Beginn- und Abschlusszeiten Puffer- und Schlupfzeiten der Vorgänge 4 Elementare Zeitpunktgrößen: FA(i,j) früheste Anfangszeit SA(i,j) späteste Anfangszeit FE(i,j) früheste Endezeit SE(i,j) späteste Endezeit 56
Netzplantechnik: CPM-Methode Methode Projektmanagement Berechnung der Ereigniszeiten frühestmöglicher Zeitpunkt FZ(i) des Ereignis i = zeitlängster Weg von Start bis i; Addition der Vorgangszeiten auf dem Pfad von Start bis i spätesterlaubter Zeitpunkt SZ(i) des Ereignis i = L [zeitlängster Weg von Ziel bis i]; L minimale Gesamtprojektdauer = längster Pfad von Start bis Ziel (L=31) FZ(3) = 12 = D(1,2)+D(2,3) SZ(3) = 19 = L D(5,6) D(3,5) Puffer / Schlupf / Slack-Time: SZ(3) FZ(3) = 7 D(2,3) = +7 1 5 2 7 3 11 9 4 8 13 4 5 6 57
Netzplantechnik: CPM-Methode Methode Projektmanagement ( FZ(3) + D(3,5) = 12+8 =20 FZ(5) = max ( FZ(2) + D(2,5) = 5+11 =16 ( FZ(4) + D(4,5) = 14+13 =27 Kritischer Pfad: ein kritischer Pfad liegt vor, wenn FZ(n) == L frühester Zeitpunkt für letztes Ereignis ist längster Pfad Kritischer Vorgang (i,j) : FZ(i)==SZ(i); FZ(j)==SZ(j) frühest mögliche und spätest mögliche Zeiten fallen zusammen 58
Aufgaben - Netzplantechnik Ermitteln Sie zu einer gegebenen Vorgangsliste mit Vorgängerangaben ein Beziehungsschema Erzeugen Sie einen Netzplan und überprüfen Sie die Entwurfsregeln Identifizieren Sie den/die kritischen Pfad/e Ermitteln Sie die freien Kapazitäten Wie ließen sich die freien (Zeit-) Kapazitäten nutzen? Um welchen Preis jeweils? 59
5. Elemente des SW-Entwicklungsprozesses a. Prinzipien der SW-Entwicklung b. Problemanalyse c. System-Entwurf d. Prototyp-Entwicklung und Simulation e. Programmentwurf f. Programmtest g. Systemtest und Integration h. Auslieferung i. Wartung j. Auswertung und Verbesserung 60
5.a. Prinzipien der SW-Entwicklung Beherrschung der Komplexität Komplexitätsreduktion durch Analyse, Strukturbildung, Architekturentwicklung Beherrschung des Aufwands (Aufwandsreduktion*) durch Modularität, Standardisierung, Objektorientierung, Implementation Hiding, Lokalitätsprinzip Beherrschung der Qualitätsanforderungen Erkennen und Verfolgen allgemeiner und produktspezifischer Qualitätsziele * Aufwandsreduktion Wiederverwendbarkeit 61
Qualitätsanforderungen Ziele (Delfs 99 / E1) 5.a Qualitätsmerkmale aus Benutzersicht Funktionserfüllung Effizienz Zuverlässigkeit Benutzbarkeit Sicherheit HW-Effizienz SW-Effizienz Robustheit Fehlertoleranz Qualitätsmerkmale aus Entwicklersicht Erweiterbarkeit Wartbarkeit Portierbarkeit Wiederverwendbarkeit Konfigurierbarkeit/ Skalierbarkeit Entwurfsstabilität Änderbarkeit Testbarkeit Anpassbarkeit Montierbarkeit 62
Qualitätsmerkmale (Delfs 99 / E2) 5.a Zwei fundamentale Lehrsätze: Theorem 1: Wiederverwendbarkeit Wartbarkeit Erweiterbarkeit Änderbarkeit Anpassbarkeit "Software-Entwurf muss verständlich sein" Theorem 2: Konfigurierbarkeit Skalierbarkeit Montierbarkeit Wiederverwendbarkeit Wartbarkeit "Software muss modular mit sauberen Schnittstellen sein" ("Software-ICs") 63
"Software muss verständlich sein" (aus Delfs 99 / E4) 5.a Schließen der semantischen Lücke (semantic gap) durch verständliche SW-Architektur(en) Problem reale Anwendungswelt "Objekte" mit Eigenschaften, Beziehungen, Funktionalität natürliche Sprache Modell des Problems Modell der Lösung Analysemodell Entwurf / "Bauplan" ausreichend mächtige, ausreichend präzise, ausreichend abstrakte, ausreichend anschauliche Modellierungssprache Lösung Programm / "Werkplan" Variablen, Datenstrukturen Prozeduren, Funktionen, Operatoren Klassen, Instanzen, Instanzvariablen, Operationen, Polymorphismus, Klassenhierarchien, Vererbung, (4GL-, objektorientierte) Programmiersprache 64
Begriffe 5.a Modell: Muster, Vorbild, Entwurf oder Nachbildung in kleinerem Maßstab; Typ, Ausführungsart eine Fabrikats vereinfachte Darstellung der Funktion eines Gegenstands oder des Ablaufs eines Sachverhalts, die eine Untersuchung od. Erforschung erleichtert oder erst möglich macht Modul: austauschbares, komplexes Teil eines Gerätes od. einer Maschine, das eine geschlossene Funktionseinheit bildet unabhängig voneinander realisierbare und in ihrem Zusammenwirken überschaubare Einzelbausteine (Moduln) Modularisierung: ein Gesamtsystem in Moduln unterteilen und deren Funktionen, ihre Beziehungen zueinander und ihre Schnittstellen beschreiben 65
Software muss modular mit sauberen Schnittstellen sein 5.a Beherrschung der Komplexität Komplexitätsreduktion durch Analyse, Strukturbildung, Architekturentwicklung Systemkomponente1 Schnittstelle Systemumgebung System Systemkomponente3 Beziehung Systemkomponente2 Software-Architektur aus Komponenten und Beziehungen 66
Beherrschung der Komplexität 5.a Komplexitätsreduktion durch Analyse, Strukturbildung, Architekturentwicklung Komponente 2.1 Komponente 2.2 Komponente 2.3 Schicht 2 Komponente 1.1 Komponente 1.2 Komponente 1.3 Schicht 1 Komponente 0.1 Komponente 0.2 Komponente 0.3 Schicht 0 Komp. A benutzt Komp. B Schicht A benutzt Schicht B geschichtete Architektur 67
Schichtenarchitektur 5.a Schichtung abstrakter 'Maschinen' höhere Schicht benutzt niedrigere Implementierung der höheren Schicht mit den Komponenten der unterlagerten Schicht(en) Musterbeispiel Rechnerarchitektur (HW-Architektur, Sprachhierarchie) 68
Modularisierung - Übersicht 5.a Zerlegen eines Systems in Moduln entsprechend dem intrinsischen Modularisierungskonzept der Implementierungsebene (-Sprache): Abstraktionsformen: funktionale Abstraktion, Datenabstraktion, Klassenbildung Modultypen: Funktionsmoduln (Sammlungen log. zusammengehöriger Funktionen) Datenmoduln (Sammlungen log. zusammengehöriger Daten / Datendefinitionen) abstrakte Datenstrukturen (Abstraktion vom Elementtyp der D.-Struktur / z.b. Puffer, Keller, Warteschlange, Baum, Liste) + Zugriffsfunktionen abstrakte Datentypen (Beschreibung eines Datenstrukturtyps, Nutzung in Deklarationen von Datenstrukturen Instanzerzeugung) generische abstrakte Datentypen (Abstraktion vom Elementtyp, u. zusätzliche Parameter z.b. für Skalierung u. Dimensionierung) Klassenmoduln / Mengen von Objektklassen (OOP) Modul auch pragmatisch: Funktionsbaustein, Function Block, (betriebliche / Automatisierungs-) Funktion Planen / Entwerfen der Schnittstellen nach Problem-Anforderungen und innerer Logik der entwickelten Moduln (evtl. über explizite Anforderungen hinaus) Normierung und Standardisierung von Schnittstellen 69
Modularisierung - Übersicht Abstraktionshierarchie: Klasse generischer abstrakter Datentyp abstrakter Datentyp Abstraktion abstrakte Datenstruktur Datenstruktur(-Instanz) 70
5.b. Problemanalyse 1. Analysieren durch Modellieren der Problemsituation ( Modell) 2. Auswahl von Modellierungsmethoden hier: Semantische Datenmodellierung mit Entity-Relationship-Diagrammen (Ziel: Ableiten eines Relationenschemas / Datenbankschemas) Strukturierte Analyse (SA) Datenflussdiagramme (Kontextdiagramm + hierarchische Verfeinerungen) Zustandsdiagramme Entscheidungstabellen Datenkatalog Real-Time-Analyse (RT) Unified Modelling Language (UML) Use-Case-Diagramm (Akteure, Szenarios) Klassendiagramm (Klassen, Beziehungen) Paket-Diagramm (Strukturierung der Darstellung) Kollaborationsdiagramme (Zusammenwirken der Komponenten) Aktivitätsdiagramm (Ablaufmöglichkeiten) Sequenzdiagramme (Objekte, Interaktionen) Zustandsübergangsdiagramm (Internes Verhalten von Objekten) Komponentendiagramm (Innere Struktur der Objekte) Verteilungsdiagramm (Einbettung der Objekte in eine Umgebung) 71
5.b.1 Analysieren durch Modellieren der Problemsituation [Rumbaugh 91 / f.8.1] Benutzer Entwickler Manager Erzeuge Anforderungen Analyse Problembeschreibung Anwenderbefragung Bereichswissen Erfahrungswissen Erzeuge Modelle Objektmodell Dynamikmodell Funktionsmodell Entwurf Darstellung mit SA-Elementen 72
5.b.1 Analysieren durch Modellieren der Problemsituation Anforderungen an ein Analysewerkzeug / Modellierungswerkzeug Anschaulichkeit, intuitives Verständnis für Anwender und Leser grafische Notation, grafische Elemente, Übersichten ausreichende Mächtigkeit Vorrat von Darstellungselementen, Symbolen; Ausdruckskraft Abdecken der verschiedenen Modellierungsaspekte ausreichende Präzision Klarheit der Darstellung, Eindeutigkeit, Ansatz für nachfolgende Prozessschritte ausreichende Abstraktion Möglichkeit zur hierarchischen Abstraktion, Gliederung 73