Einführung in Software Engineering
Einführung in Software Engineering
Einführung in Software Engineering
Erfolgreiche ePaper selbst erstellen
Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.
c) Projektpläne und Projektorganisation<br />
• Am Ende der Machbarkeitsstudie steht die Erstellung e<strong>in</strong>es Projektplans mit:<br />
(1) Identifizierung e<strong>in</strong>zelner Arbeitspakete<br />
(2) Term<strong>in</strong>planung<br />
(3) Ressourcenplanung<br />
• Machbarkeitsstudie ohne grobes <strong>Software</strong>design nicht möglich da:<br />
(1) Arbeitspakete ergeben sich aus <strong>Software</strong>struktur<br />
(2) Abhängigkeiten und Umfang der Pakete ebenso<br />
(3) Realisierungsart der Pakete bestimmt über Ressourcen<br />
• Konsequenz: Projektplanung und ‐organisation ist fortlaufender Prozess. Zu<br />
Projektbeg<strong>in</strong>n ist dies nur grober Plan.<br />
• Abschließende Checkliste<br />
(1) Machbarkeitsstudie soll nur wenige Tage dauern<br />
(2) ggf. Vorprojekt zur Risikoabschätzung<br />
(3) folgende Punkte s<strong>in</strong>d zu klären:<br />
(a) Angaben im Lastenheft mit Kunden abgestimmt?<br />
(b) mit geplanten Ressourcen technisch realisierbar?<br />
(c) vertrauenswürdige Kostenschätzung?<br />
(d) Produktentwicklung wirtschaftlich <strong>in</strong>teressant?<br />
(e) realistischer Zeitplan?<br />
(f) Phasenverantwortliche?<br />
(g) Risikoabschätzung durchgeführt?<br />
d) Hilfsmittel bei Anforderungsanalyse – Modelle/Diagramme<br />
• E<strong>in</strong>gesetzte klassische Modellierungssprachen<br />
(1) funktionale Aspekte – Verhalten<br />
(a) Datenflussdiagramme<br />
(b) Funktionsbäume<br />
(2) Datenstrukturen<br />
(a) Data Dictionary = Typdef<strong>in</strong>itionen<br />
(b) Entity‐Relationship‐Diagramme (Klassendiagramm ohne Operationen)<br />
(3) Kontrollstrukturen<br />
(a) Struktogramme (Nassi‐Shneiderman‐Diagramme)<br />
(b) Pseudocode<br />
(4) zustandsbehaftete nebenläufige Systeme<br />
(a) Zustandsübergangsdiagramme (endliche Automaten)<br />
(b) Petr<strong>in</strong>etze<br />
• Kritik an aufgezählten Modellen<br />
(1) starke Trennung zwischen Daten‐ und Verhaltensaspekten<br />
(a) folgend Konsistenshaltungsprobleme<br />
(2) verschiedene Konzepte und Sprachen <strong>in</strong> e<strong>in</strong>zelnen Entwicklungssprachen<br />
(a) Konsistenz?<br />
(b) gewünschte Trennung zwischen Analyse und Entwurf wird erzwungen<br />
• Voraussetzung für erfolgreiche <strong>Software</strong>modellierung<br />
(1) Sprachen mit wohldef<strong>in</strong>ierter Syntax und Semantik<br />
(2) präzise sprachübergreifende Konsistenz‐ und Abbildungsregeln<br />
e) Objektorientierte Modellierungssprachen<br />
• Vielzahl von OO‐Modellierungsdialekten wird durch Standard‐Sprache ersetzt um so<br />
(Idee von Booch)<br />
(1) Vorteile verschiedener Modellierungsansätze zu vere<strong>in</strong>en<br />
(2) potentiellen Anwendern die Qual der Wahl abzunehmen<br />
(3) Voraussetzungen für Datenaustausch zwischen OO‐Werkzeugen zu schaffen<br />
(4) enge Integration von OO‐Werkzeugen
Change language