Kapitel 1 - Einführung Softwaretechnik
- Einführung
- Charakterisierung
- Programming in the small
- Programmieren im Großen
- Geschichte der Softwareentwicklung
|
Softwaretechnik: "multi-person construction of multi-version
software"
(Parnas (1987)
Software Engineering - charakteristische Eigenschaften und Ziele
Es geht darum Fehler zu beheben, die Funktionalität zu erweitern, Altes
Entfernen oder an neue Umgebungen anzupassen. Gemeinsame Prinzipien sind
-
Separation der Belange / Anforderungen
-
Modulatität (Dekomposition komplexer Probleme, d.h. Top Down
oder Zusammensetzen eines komplexen Systems aus bestehenden Fabrikteilen, d.h.
Buttom-up)
-
Abstraktion (wichtige Dinge herausheben und Details ignorieren
und gegebenfalls verschiedene Abstraktionen der gleichen Realität darstellen)
-
Voraussicht auf Änderungen (d.h. bei Entwicklung bedenken, daß
sich Anforderungen im Laufe der Zeit ändern werden. Somit Version Managment
notwendig)
-
Generalisierung (d.h. Probleme versuchen zu generalisieren, um
diese auf einer höheren Ebene anzugehen)
-
Inkrementelles Vorgehen (Incrementality / schrittweises
Vorgehen ermöglicht einen evulotionären Entwicklungsprozess bei dem ein frühes
Feedback die initialen Anforderungen erreicht)
Teildisziplinen der Softwaretechnik:
SW-Entwicklung, SW-Management, SW-Qualitätssicherung und Wartung und Pflege
Programmieren im Kleinen und im Großen, Unterschiede
- Anforderungen sind im Kleinem bekannt
- Programme können von Einzelnen geschrieben und entworfen werden
- Bei großen Anwendungen ist Anforderung nicht mehr trivial und überschaubar
- Präzise Spezifikation wird notwendig und ein Modell der Andwendung wird
ausgearbeitet
- Es wird nun im Team gearbeitet
Engineering - systematischer Ansatz zum Problemlösen
- Sytematisches Herangehen
- Genaues Definieren des Problemes
- Von bestehenden Lösungen lernen
- Wiederholende Muster muss man erkennen können
- Definieren von formalen Modellen, da diese Automatisierung
fördern
- Entwicklung erfolgt mit Standard-Werkzeugen
- Techniken entwickeln mit denen Klassen von Problemen gelöst werden können
Warum ist Software Engineering so kompliziert?
- Nur unklare oder uneindeutige Spezifikationen möglich
- Semantik ist sehr komplex und es gibt keine mathematische Unterstützung
Geschichte des Software Engineering
- Früher Probleme zwischen nur einem User und Computer und keinen anderen
Personen
- Somit waren Probleme einfach und überschaubar
- Benutzer spezifizierten das Problem
- Programmierer interpretierten die Spezifikation und programmierten danach
Probleme der Entwicklung von großen Softwaresystemen und Ursachen
- Nur unklare oder uneindeutige Spezifikationen möglich
- Semantik ist sehr komplex und es gibt keine mathematische Unterstützung
- 67 % allein an Wartungskosten
Lebenszyklus eines Softwaresystems
- Entwicklung und Evolution eines Software Systems wird systematisch nach einer
bestimmten Methode umgesetzt
- Entwicklung und Evolution eines Software Systems besteht aus wohldefinierten
Phasen
- Jede Phase hat wohldefinierte Anfangs- und Endpunkte, welche klar den
Übergang zur nächsten Phase definieren
Wasserfallmodell des Lebenszyklus eines Softwaresystems
- Analyse
- Design
- Implementation und Modultest
- Inegration und Systemtests
- Inbetriebnahme und Wartung
Phasen des Wasserfallmodells
- Anforderungsanalyse und Spezifikation (Was ist das Problem?)
- Design und Spezifikation (Wie kann man es lösen?)
- Coding und Modultests (Funktionsrumpfe werden programmiert)
- Integration und Systemtest (Alle module werden zusammengesetzt)
- Übergabe (GoLive) und Wartung (Änderungen nach der Kundenübergabe)
Programmiersprachen und SE (Einfluss)
- Zentrale Werkzeuge bei Entwicklung
- Sollten Modularität, Software Architektur, seprarate und unabhängige
Kompilierung von Modulen, GUI Design und von Implementierung unabhängige
Spezifikation ermöglichen
Grund für Datenbanken:
Datenunabhängigkeit, d.h. Verwendung von Daten, ohne die zugrundeliegende
Datenrepräsentation kennen zu müssen
-> Trennung von Spezifikation und Implementierung
Datenbanken und SE (Einfluss)
- Große strukturierte Objekte speicherbar (Quellen)
- Große unstrukturierte Objekte speicherbar (Object Programs)
- Configuration und version managment einfach möglich
- Datenbankschema's sind gleichzeitig Dokumentation
Management und Software Engineering - Ziele und Struktur
Technisches Managment
- Kostenschätzung
- Projektplanung
- Ressourcenplanung
- Arbeitseilung
- projekt Überwachung
Personalmanagment
- Motivation
- Anstellung
- Auswahl der richtigen Subjekte
|
|
|
|
|
|
Kapitel 1
|
Einleitung
|
|
Einführung, Geschichte...
|
|
Kapitel 2
|
Eigenschaften
|
|
Filtern und Trennen, Modularisierung...
|
|
Kapitel 3
|
Strukturierte Analyse
|
|
Strukturierte und OO-Analyse, Petri-Netze
|
|
Kapitel 4
|
Spezifikation
|
|
Risikoanalyse, Modellierungshilfen, Spezifikationen
|
|
Kapitel 5
|
Entwurfsprozess
|
|
Entwurf, DFD, Tests, UI...
|
|
Kapitel 6
|
Prozessmodelle
|
|
Softwarekrise, Lebenszyklusmodelle...
|
|
Kapitel 7
|
CASE und PM
|
|
CASE, Projektmanagement...
|
|
Kapitel 8
|
Software-Metriken
|
|
Softwarequalität, Entwurfsmetriken...
|
|
Kapitel 9
|
Programmierungskonzepte
|
|
Legacy Systeme, Reengineering...
|
|
|
|
|
|
|
Quellen:
|
Petr Kroha
Softwaretechnologie
|
Prof. Kroha
Vorlesungsskript
|
L. Rosenhainer
Vorlesungsskript
|
Word Wide Web
Verschiedenste Seiten
|
|
|
|
|