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
|
|