file downloaden

file downloaden
Weitere Files findest du auf www.semestra.ch/files
DIE FILES DÜRFEN NUR FÜR DEN EIGENEN GEBRAUCH BENUTZT WERDEN.
DAS COPYRIGHT LIEGT BEIM JEWEILIGEN AUTOR.
Software Engineering
Software-Prozess, Projektführung,
Aufwandschätzung, Qualitätssicherung,
Dokumentation und Konfigurationsverwaltung
Prof. M.Glinz
14. September, 1998
Erstellt von: Ralf Gall
Software Enigneering
Inhaltsverzeichnis
Einführung: Softwareentwicklung als Problem
Software
1.1 Software ..........................................................................................................................................3
1 Einführung: Softwareentwicklung als Problem ......................................................................................3
1.2 Softwareentwicklung .......................................................................................................................4
1.3 Software Engineering......................................................................................................................5
1.4 Ziele und Mittel des Software Engineering......................................................................................5
2.1 Zielsetzungsproblem .......................................................................................................................6
2 Zielsetzung, Messung............................................................................................................................6
2.2 Klassifikation von Zielen .................................................................................................................6
2.3 Zielverfolgung..................................................................................................................................6
2.4 Messung .........................................................................................................................................6
2.5 Wichtige Merkmale für die Ziele in der Softwareentwicklung .........................................................7
3.1 Grundlagen .....................................................................................................................................8
3 Der Software-Prozess ...........................................................................................................................8
3.2.1 Das klassische sequentielle Software-Life-Cycle-Modell .........................................................9
3.2 Prozessmodelle für die Entwicklung von Software .........................................................................9
3.2.2 Das Wasserfall-Modell ...........................................................................................................10
3.2.3 Ergebnisorientierte Phasenmodelle .......................................................................................12
3.2.4 Wachstumsmodelle................................................................................................................13
3.2.5 Das Spiral-Modell ...................................................................................................................14
3.2.6 Das prototypingorientierte Life-Cycle-Modell..........................................................................15
3.3 Prototypen.....................................................................................................................................16
3.4 Wiederverwendung und Beschaffung...........................................................................................16
3.5 Pflege (Wartung)...........................................................................................................................17
4.1 Projektplanung ..............................................................................................................................18
4 Software-Projektführung......................................................................................................................18
4.2 Projektkontrolle und -lenkung .......................................................................................................21
4.3 Der Projektabschluss ....................................................................................................................22
4.4 Software-Risikoführung.................................................................................................................22
5.1 Allgemeines ..................................................................................................................................25
5 Software-Aufwandschätzverfahren......................................................................................................25
5.2 Empirische Schätzverfahren .........................................................................................................25
5.3 Algorithmische Schätzverfahren ...................................................................................................25
5.4.1 COCOMO...............................................................................................................................26
5.4 Beispiele algorithmischer Schätzverfahren...................................................................................26
5.4.2 Das Function Point-Verfahren ................................................................................................27
5.4.3 Sonstige Methoden ................................................................................................................29
5.5 Schätzung von Pflegekosten ........................................................................................................29
5.6 Einfluss der Schätzung auf den Aufwand .....................................................................................29
Seite 2
Software Enigneering
Einführung: Softwareentwicklung als Problem
Software
Software Enigneering
Einführung: Softwareentwicklung als Problem
Software
6.5.1 Art der Darstellung .................................................................................................................33
6.5 Darstellung von Anforderungen ....................................................................................................33
6.4 Gewinnung der Anforderungen.....................................................................................................32
11 Konfigurationsverwaltung ..................................................................................................................59
10.5 Dokumenterstellung ....................................................................................................................58
10.4 Dokumentenverwaltung ..............................................................................................................58
10.3 Projektdokumente.......................................................................................................................57
10.2 Produktedokumente....................................................................................................................57
9.4 Reviewtechnik ...............................................................................................................................53
6.5.2 Formalitätsgrad der Darstellung .............................................................................................34
11.1 Grundlagen .................................................................................................................................59
9.5 Testen ...........................................................................................................................................55
6.5.3 Verfügbare Gliederung- und Abstraktionsmittel .....................................................................35
11.2 Kennzeichnung ...........................................................................................................................59
6.1 Grundlagen und Motivation ...........................................................................................................30
6.6 Ausgewählte Spezifikationsmethoden ..........................................................................................37
11.3 Registrierung und Verwaltung.....................................................................................................59
6 Anforderungsspezifikation ...................................................................................................................30
6.6.1 Spezifikation mit natürlicher Sprache .....................................................................................37
11.4 Konfiguration ...............................................................................................................................59
10.1 Grundsätze der Dokumentation ..................................................................................................56
6.6.2 Algebraische Spezifikation .....................................................................................................37
11.5 Änderungswesen ........................................................................................................................60
10 Dokumentation ..................................................................................................................................56
6.6.3 Datenflussorientierte Spezifikation: Strukturiere Analyse.......................................................37
11.6 Behandlung von Problemmeldungen..........................................................................................60
6.2 Der Spezifikationsprozess ............................................................................................................31
6.6.4 Verhaltensspezifikation mit Automaten ..................................................................................38
6.3 Dokumentation von Anforderungen ..............................................................................................31
6.6.5 Objektorientierte Spezifikation................................................................................................38
12.1 Werkzeuge..................................................................................................................................61
12 Produktivitätsfaktoren ........................................................................................................................61
12.2 Mehrfachverwendung von Software ...........................................................................................62
6.6.6 Prototypingorientierte Systemspezifikation.............................................................................39
12.3 Die Rolle der Menschen..............................................................................................................62
6.7 Prüfung der Anforderungen ..........................................................................................................40
7.1 Hauptaufgaben in der Konzipierung..............................................................................................41
7 Konzipieren von Lösungen ..................................................................................................................41
13.2 Zielsetzung, Messung .................................................................................................................63
13.1 Einführung...................................................................................................................................63
13.3 Der Software-Prozess .................................................................................................................64
13 Aufgaben ...........................................................................................................................................63
7.4 Techniken der Konzipierung .........................................................................................................43
13.4 Software-Projektführung .............................................................................................................64
7.2 Lösungsvarianten..........................................................................................................................41
7.4.1 Funktionsorientierter Entwurf .................................................................................................43
7.3 Modularisierung.............................................................................................................................41
7.4.2 Datenorientierter Entwurf .......................................................................................................44
13.5 Software-Aufwandschätzung ......................................................................................................65
Seite 4
7.4.3 Objektorientierter Entwurf.......................................................................................................44
7.5 Architekturmetaphern....................................................................................................................46
7.6.1 Beschaffung vollständige Lösung...........................................................................................46
7.6 Beschaffung und Wiederverwendung...........................................................................................46
7.6.2 Der Beschaffungsprozess: .....................................................................................................46
8 Realisierung.........................................................................................................................................48
8.1.1 Wahl Implementierungssprache ............................................................................................48
8.1 Einleitung ......................................................................................................................................48
8.1.2 Programmierstil ......................................................................................................................48
8.2 Möglichkeiten der Realisierung.....................................................................................................49
8.3 Systematisches Programmieren...................................................................................................50
8.4 Prüfung und Integration ................................................................................................................50
9.1 Grundlagen ...................................................................................................................................51
9 Qualitätsmanagement .........................................................................................................................51
9.2 Das Qualitätsmanagementsystem ................................................................................................52
9.3 Qualitätsprüfung............................................................................................................................53
Seite 3
Einführung: Softwareentwicklung als Problem
Software
Software Enigneering
Einführung: Softwareentwicklung als Problem
Softwareentwicklung
1.2 Softwareentwicklung
Software Enigneering
1 Einführung: Softwareentwicklung als Problem
Softwareentwicklung: Die Umsetzung der Bedürfnisse von Benutzern im Software. Umfasst
Spezifikation der Anforderungen, Konzept der Lösung, Entwurf und Programmierung der
Komponenten, Zusammensetzung der Komponenten und Einbindung in vorhandene Software,
Inbetriebnahme der Software sowie Überprüfung des Entwickelten nach jedem Schritt.
Software
Regel: Der Aufwand für die Erstellung von Software steigt mit wachsender Produktgrösse
überproportional an. Gründe dafür sind der überproportional wachsende Aufwand zur Beherrschung
der Komplexität und der Kommunikationsaufwand (1 Person, 0 Kommunikationspfade /
3 Personen, 3 Kommunikationspfade / 5 Personen, 10 Kommunikationspfade).
M
Die (empirisch erhärtete) Formel dafür lautet: A = bP (A= Aufwand, b = konstanter Faktor, P =
Programmgrösse und m = konstanter Exponent zwischen 1,05 und 1,2)
Software ist der Evolution unterworfen: Die Umwelt und die Bedürfnisse verändern sich ständig.
D.h. Software muss immer wieder angepasst und erweitert werden. Hinzu kommt, dass ein
bewegliches Ziel nur schwer zu treffen ist.
Seite 6
4. Fehler infolge von emotionalen Fehleinschätzungen: Was im Kleinen geht, geht auch im Grossen.
Softwareentwicklung wird einfacher eingeschätzt als sie wirklich ist.
3. Die Ziele verändern sich während dauernd aufgrund der Evolution
2. Software ist ein immaterielles Produkt
1. Die Grösse der zu lösenden Probleme: Software ist nicht einfacher als die Probleme
Warum ist Softwareentwicklung so schwierig. Grundsätzlich können vier Gründe aufgeführt werden:
erheblichen Einfluss auf die Software.
Î Software wird von Menschen gemacht: Die Fähigkeiten und Fehler dieser Menschen haben eine
Î
Î
Î Die Entwicklung von Kleinsoftware unterscheidet sich fundamental von der Entwicklung grösserer
Die Entwicklung von Software wird ungenügend beherrscht. Die Softwarekosten, bestehend aus
Entwicklungskosten und Wartungskosten (1950: 20% / 1980: 90%) sind schon lange bedeutend höher
als die Hardwarekosten.
1.1 Software
Software umfasst mehr als nur Programme: Der Aufwand für das Schreiben der Programme
beträgt nur etwa 10-20% des Gesamtaufwandes und weniger als 10% der Kosten. Der Aufwand
wird deshalb oft um ein Vielfaches unterschätzt.
Software: Programme, Verfahren, zugehörige Dokumentation und Daten, die mit dem Betrieb eines
Computersystems zu tun haben (IEEE 610.12)
Î
Î
Software ist ein immaterielles Produkt: Geistige Güter werden oft als weniger wertvoll betrachtet,
d.h. der Wert von Software wird unterschätzt. Im Gegensatz zu materiellen Produkten weist
Software keine natürlichen Grenzen in Form von Materialeigenschaften oder Naturgesetzen auf.
Bei materiellen Produkten sind Fehler leichter erkennbar (Auto mit Rädern am falschen Ort). Auch
der Entwicklungsstand ist bei materiellen Gütern leichter zu beurteilen. Software ist scheinbar sehr
flexibel und leicht zu ändern.
und Daten kann massive Veränderungen zur Folge haben.
Î Software verhält sich im mathematischen Sinn unstetig: Die kleinste Veränderung in Programmen
Wozu dient Software? Software dient dazu, ein Problem zu lösen oder zu dessen Lösung beizutragen,
indem menschliche oder technische Arbeitsvorgänge automatisiert oder unterstützt werden.
Bei der Lösung von Problemen sind immer zwei Schwierigkeiten gleichzeitig zu bewältigen: 1. Das
Problem ist im Kontext seines Sachgebietes zu verstehen und befriedigend zu lösen 2. Die
Problemlösung muss auf adäquate Softwarestrukturen abgebildet werden.
Î Wenn ein Problem von seiner Natur her komplex und schwierig zu lösen ist, so ist die Software zur
Lösung dieses Problems in der Regel nicht weniger komplex.
Î
Î
Problemlösungen schaffen neue Realitäten und wecken neue Bedürfnisse: Software konstruiert
und verändert die Realität.
Seite 5
Software Enigneering
1.3 Software Engineering
Einführung: Softwareentwicklung als Problem
Software Engineering
Anfänglich wurde kein Software Engineering benötigt, da die Programm unabhängig und von einer
beherrschbaren Grösse waren. In den 60er-Jahren kam dann aber die Softwarekrise und die
Forderung nach Software Engineering wurde laut. Inzwischen hat sich die Erkenntnis weitgehend
durchgesetzt, dass bei nichttrivialen Aufgaben eine wirtschaftliche und termingetreue Entwicklung
qualitativ guter Software ohne Software Engineering nicht möglich ist.
Software Engineering: Das technische und planerische Vorgehen zur systematischen Verstellung
und Pflege von Software, die zeitgerecht und unter Einhaltung der geschätzten Kosten entwickelt bzw.
modifiziert wird.
Software Engineering: Die Anwendung eines systematischen, disziplinierten und quanitfzierbaren
Ansatzes auf die Entwicklung, den Betrieb und die Wartung von Software, d.h. die Anwendung der
Prinzipien des Ingenieurswesens auf Software (IEEE 610.12)
1.4 Ziele und Mittel des Software Engineering
Mit Software Engineering werden grundsätzlich drei Ziele verfolgt:
1. Produktivität bei der Herstellung der Software soll gesteigert werden
2. Qualität der erstellten Software soll verbessert werden
3. Führbarkeit von Software-Entwicklungsprojekten soll erleichtert werden
Seite 7
Software Enigneering
2 Zielsetzung, Messung
Zielsetzung, Messung
Zielsetzungsproblem
Ohne definierte Ziele ist keine systematische Softwareentwicklung möglich. Eine systematische
Zielerreichung ist nur dann möglich, wenn die Ziele kontinuierlich verfolgt und Abweichungen
festgestellt werden. Hierzu sind Messungen notwendig.
2.1 Zielsetzungsproblem
Software Engineering betreiben bedeutet, dass für jede Entwicklung von Software Ziele gesetzt
werden und anschliessend systematisch auf diese Ziele hingearbeitet wird.
Î
Es gibt keine natürlichen Ziele für Software. Die Ziele müssen für jedes Entwicklungsvorhaben neu
definiert werden. Dabei ist zu beachten, dass sich Ziele konkurrenzieren (z.B. Erstellungsaufwand
und Performance) können und dass Ziele voneinander abhängig (z.B. Anzahl Anweisungen und
Speicherbedarf) sein können.
(5 Gruppen mit unterschiedlichen Zielen erstellen fünf ganz unterschiedliche Applikationen)
Î Die Wahl der Ziele hat einen erheblichen Einfluss auf das Produkt und den Entwicklungsprozesse
2.2 Klassifikation von Zielen
In den meisten Softwareprojekten lassen sich die Ziele nach dem folgenden Schema ordnen:
2.3 Zielverfolgung
Zielsetzung ist notwendig für ein systematisches Vorgehen, aber nicht hinreichend. Es braucht eine
regelmässige Zielerreichungskontrolle, so dass bei Abweichungen geeignete Gegenmassnahmen
getroffen werden können. Dazu ist es aber nötig, dass Ziele gemessen werden können.
2.4 Messung
R(M(d1), M(d2)) ⇒ R*(µ(d1), µ(d2))
R*(µ(d1), µ(d2)) ⇒ R(M(d1), M(d2)) und die Aussage R(M(d1), M(d2)) ist interpretierbar
Mass (Metriken): Sei D eine Menge gleichartiger Gegenstände mit einem zu messenden Merkmal M,
sei M(d) die Ausprägung des Merkmals M für den Gegenstand d ∈ D und sei M die Menge aller dieser
Merkmalsausprägungen. Ein Mass für das Merkmal M ist eine Abbildung µ: D → S, welche jedem
d ∈ D einen Messwert w(d) auf einer Skala S so zuordnet, dass M und S strukturähnlich sind. Dies ist
genau dann der Fall, wenn für beliebige d1, d2 aus D gilt: Zu jeder Relation R auf der Menge der
Merkmalsausprägungen M gibt es eine analoge Relation R* und der Skala S mit folgenden
Eigenschaften:
1)
2)
Seite 8
Software Enigneering
Zielsetzung, Messung
Wichtige Merkmale für die Ziele in der Softwareentwicklung
Abhängig von den Relationen, die es auf den Ausprägungen eines zu messenden Merkmals gibt, sind
auf den Skalenwerten bestimmte Operationen möglich oder eben auch nicht.
Beispiele:
Nominalskala: Erfüllt, nicht erfüllt, nicht getestet
Ordinalskala: ++, +, 0, -, -Intervallskala: Datumsreihe
Verhältnisskala:Anzahl Codezeilen für Programmgrösse
Absolutskala: Zählskala für die Anzahl gefundener Fehler in Programmen
Es gibt einige interessierende Merkmale von Software und von Software-Entwicklungsprozessen, die
sich in einfacher Weise direkt messen lassen, sogenannte direkte Masse (z.B. Grösse von
Programmen). Auf der anderen Seite gibt es aber Merkmale, für die es keine direkten Masse
existieren (z.B. Portabilität). In diesen Fällen muss man sich mit direkt messbaren Indikatoren für das
Merkmal behelfen.
2.5 Wichtige Merkmale für die Ziele in der Softwareentwicklung
Bei den Produktzielen interessieren vor allem Masse zur Messung der Funktionserfüllung (z.B.
Leistungsanforderungen), der Grösse, der Zuverlässigkeit, der Benutzerfreundlichkeit oder der
Wartbarkeit. Die meisten dieser Merkmale können aber nur indirekt gemessen werden.
Bei den Projektzielen interessieren vor allem Masse zur Messung von Aufwand, Durchlaufzeit,
Arbeitsfortschritt, Entwicklungskosten und Fehlerkosten. Diese Merkmale lassen sich verhältnismässig
einfach messen.
Seite 9
Software Enigneering
3 Der Software-Prozess
3.1 Grundlagen
Der Software-Prozess
Grundlagen
Prozess: Eine Folge von Schritten, die zur Erreichung eines gegebenen Zwecks ausgeführt wird
(IEEE 610.12)
Ein Softwareprozesse beschreiben den Ablauf der Entwicklung und Pflege von Software. Dabei kann
zwischen ad-hoc Prozessen, die spontan, individuell und ungeregelt ablaufen und systematischen
Prozessen , deren Ablauf geplant und geregelt ist, unterschieden werden.
Im nicht-professionellen Bereich wird Software typischerweise nach einem ad-hoc-Prozess erstellt.
Dabei bestehen in der Regel nur vage Sachziele und keine Termin- und Kostenvorgaben. Im
professionellen Bereich hat diese Art von Arbeit ausschliesslich bei experimentellen Entwicklungen
sowie bei der Erstellung von Wegwerfprototypen ihre Berechtigung.
Wird eine Software als Produkt oder als Teil eines Produktes entwickelt, so braucht es zwingend
systematische, d.h. geplante und gelenkte, Prozesse. Auch bestehen klare Sach-, Kosten- und
Terminziele. Der Ablauf des Prozesses wird geprüft und entsprechend gelenkt. Qualität ist wichtig, da
das fertige Produkt anschliessend meist gepflegt und weiterentwickelt werden muss. Die
systematische Pflege ist ein Prozess, welcher die Erhaltung der Gebrauchstauglichkeit eines
Softwareproduktes zum Ziel hat.
Projekt: Eine zeitlich befristete Organisationsform zur Bearbeitung einer gegebenen Aufgabe. Dient
zur Regelung der Verantwortlichkeiten und zur Zuteilung der für die Arbeit notwendigen Ressourcen.
Projekt organisiert.
Î Jede systematische Entwicklung von Software und jedes grössere Wartungsvorhaben wird als
Der Softwarelebenslauf ist ein grundlegendes Phänomen für das Verständnis von Softwareprozessen.
Jede Komponente hat einen Lebenslauf, der folgende Stadien durchläuft:
1. Initiierung
2. Entwicklung
- Spezifizieren der Anforderungen
- Konzipieren der Lösung
- Entwerfen der Lösung im Detail
- Codieren und Testen
- Integration der einzelnen Komponenten
- Installation und Test des Gesamtsystems
3. Nutzung
Softwarelebenslauf (software life cycle): Zeitraum, in dem eine Softwarekomponente bearbeitet
oder benutzt wird. Beginnt mit der Initierung und endet mit der endgültigen Ausserbetriebsetzung.
Umfasst typisch die Stadien Initiierung, Entwicklung und Nutzung, wobei die Entwicklung wiederum in
die Stadien Spezifikation der Anforderungen, Konzept der Lösung, Entwurf und Programmierung,
Zusammensetzung mit anderen Komponenten und Inbetriebnahme (einschliesslich der Überprüfung
des Entwickelten nach jedem Schritt) zerfällt.
Î
Je kleiner ein Stück Software ist, desto mehr verläuft der Lebenslauf linear. Bei grösseren
Komponenten und bei ganzen Systemen gibt es dagegen Iterationen in allen Stadien des
Lebenslaufs.
Gemäss Lehmann (1980) kann Software in drei Klassen eingeteilt werden:
• Software vom S-Typ: Durch eine formale Spezifikation beschrieben. Erfolgreich, wenn die
resultierenden Programme nachweislich die Spezifikation erfüllen
• Software vom P-Typ: Löst spezifisches, abgegrenztes Problem. Erfolgreich, wenn das Problem
zufriedenstellen gelöst ist
• Software vom E-Typ: In die reale Welt eingebettete Anwendung. Erfolgreich wenn die Anwender mit
der Software zufrieden sind
Seite 10
Der Software-Prozess
Prozessmodelle für die Entwicklung von Software
Es ist unmöglich Software vom P- oder E-Typ so zu entwickeln, dass sie während einer
mehrjährigen Lebensdauer ohne jegliche Änderungen ihre Aufgabe zur vollen Zufriedenheit der
Benutzer erfüllt. D.h. Pflege und Wartung ist bei dieser Art von Software ein unvermeidlicher
Bestandteil der zu leistenden Arbeit.
Nur Software vom S-Typ ist stabil. Software vom P- und E-Typ ist einer Evolution (aufgrund des
sich wandelnden Umfelds ist auch die Software einem permanent Wandel unterworfen)
unterworfen. Software vom E-Typ trägt selbst zur Evolution bei.
Software Enigneering
Î
Î
Î
Dauert die Entwicklung von Software vom P- oder E-Typ länger als ca. 1/2 Jahr, so ist es kaum
möglich, nach einem Satz einmal erhobener und dann festgeschriebener Anforderungen so zu
entwickeln, dass das fertige Produkt bei seiner Inbetriebnahme die Bedürfnisse der Leute, die es
benutzen sollen, optimal befriedigt.
Meilenstein: Ein Meilenstein ist eine Stelle in einem Prozess, an dem ein geplantes Ergebnis vorliegt.
Ein Meilenstein wird geplant, indem das zu Erreichende Ergebnis und die dafür zur Verfügung
stehenden Ressourcen (Zeit, Geld, Personal etc.) festgelegt werden. Ein Meilenstein ist erreicht, wenn
das Ergebnis nachweislich vorliegt. Dies kann natürlich nur überprüft werden, wenn das verknüpfte
Ergebnis so beschrieben wurde, dass sich die Erreichung auch tatsächlich messen lässt (Komponente
xy hat den Abnahmetest bestanden und nicht 90% des Codes sind realisiert).
3.2 Prozessmodelle für die Entwicklung von Software
Da man Software nicht sehen kann, ist auch der Ablauf, in welchem sie entsteht, ohne besondere
Massnahmen nicht erkennbar. Es ist daher wichtig, eine Modellvorstellung über den Ablauf der
Entstehung von Software zu haben und sowohl die Planung als auch die Kontrolle der Entwicklung an
diesem Modell zu orientieren. Grundsätzlich werden bei allen Modellen folgende Phasen
unterschieden:
• Problemanalyse und Planung
• Systemspezifikation (Anforderungsdefinition)
• System- und Komponentenentwurf
• Implementierung und Komponententest
• Systemtest
• Betrieb und Wartung
3.2.1 Das klassische sequentielle Software-Life-Cycle-Modell
Problemanalyse und Planung: Das Ziel der Problemanalyse und Planung besteht darin, für den
Aufgabenbereich, für den eine Softwarelösung angestrebt wird, festzustellen und zu dokumentieren,
welche Arbeitsschritte/Tätigkeiten ausgeführt werden sollen und welcher Art die Wechselwirkungen
sind, welche Teile automatisiert werden und welche Ressourcen zur Verfügung stehen.
Tätigkeiten: Erhebung Ist-Zustand, Abgrenzung, Skizzierung geplante Teile, Abschätzung Umfang,
Wirtschaftlichkeitsrechnung und grober Projektplan
Ergebnisse: Beschreibung Ist-Zustand, Projektauftrag und grober Projektplan.
Systemspezifikation: Das Ziel der Systemspezifikationsphase ist ein Kontrakt zwischen Auftraggeber
und Softwarehersteller, der den genauen Funktionsumfang des Softwaresystems und die
Rahmenbedingungen festlegt.
Tätigkeiten: Systemspezifikation (Anforderungsdefinition oder Pflichtenheft), Projektplan, Validierung
Spezifikation
Ergebnisse: Systemspezifikation und genauer Projektplan
System- und Komponentenentwurf: Das Ziel der Entwurfsphase besteht darin, festzulegen welche
Systemkomponenten welche Anforderungen erfüllen und wie diese Komponenten zusammenarbeiten
sollen.
Seite 11
Software Enigneering
Der Software-Prozess
Prozessmodelle für die Entwicklung von Software
Tätigkeiten: Entwurf Systemarchitektur, def. logisches Datenmodell, Entwurf der algorithmischen
Struktur der Komponenten und Validierung
Ergebnisse: Beschreibung logisches Datenmodell, Systemarchitektur und algorithmische Struktur und
Dokumentation der Entwurfsentscheidungen
Implementierung und Komponententest: Das Ziel der Implementierungsphase ist die Umsetzung
der Ergebnisse der Entwurfsphase in ausführbaren Code.
Tätigkeiten: Verfeinerung der Algorithmen, Codierung, Übertragung des logischen Datenmodells in ein
physisches, Prüfen der Korrektheit der einzelnen Komponenten (syntaktisch und semantisch)
Ergebnisse: Programmtext der Systemkomponenten, Protokolle der Komponententests und
physisches Datenmodell
Systemtest: Das Ziel der Testphase besteht darin, die Wechselwirkungen der Systemkomponenten
unter realen Bedingungen zu prüfen, möglichst viele Fehler aufzudecken und sicherzustellen, dass die
Implementation der Spezifikation entspricht.
Betrieb und Wartung: Aufgabe der Wartung ist es, Fehler die erst jetzt auftauchen zu beheben und
Systemänderungen und - erweiterungen durchzuführen.
Dokumentation und Qualitätssicherung: Sind keine Eigentlichen Phasen sondern müssen
projektbegleitend durchgeführt werden
Vorteile:
• Klarer Rahmen für die wichtigsten Tätigkeiten; erleichtert Planung und Abschätzung Aufwand
• Vorgehen ist unabhängig von Anwendungsgebiet
• Vorgegebene Strukturierung fördert Strukturierung im Projekt
• Ermöglicht arbeitsteiligen Entwicklungsprozess
Nachteile:
• Entwicklungsprozess verläuft normalerweise nicht sequentiell / Iterationen zwischen den einzelnen
Phasen sind häufig
• Realität hat gezeigt, dass es nicht möglich ist eine Phase abzuschliessen und erst dann zur
nächsten zu gehen; oft kommt wertvoller Input aus den nachgelagerten Phasen
• Einzelne Phasen überlappen sich
• Die streng sequentielle Vorgehensweise hat den Nachteil, dass erst sehr spät ein Produkt vorliegt
Seite 12
Software Enigneering
3.2.2 Das Wasserfall-Modell
Der Software-Prozess
Prozessmodelle für die Entwicklung von Software
Das Wasserfall-Modell wurde von Royce (1970) entwickelt und später vor allem von Boehm (1981)
propagiert. Es ist das älteste semantische Prozessmodell für die Entwicklung von Software.
Das Wasserfall-Modell enthält im wesentlichen zwei Erweiterungen: Rückkopplung zwischen
(aufeinanderfolgenden) Phasen (der streng sequentielle Ablauf wird dadurch aufgeweicht) und
Einbindung der (experimentellen) Validierung der Phasenergebnisse (Vermeidung und Früherkennung
von Fehlern).
Wasserfall-Modell: Ein Modell für den Software-Entwicklungsprozess, welcher die Entwicklung in eine
Sequenz von Entwicklungs- und Prüfaktivitäten unterteilt. Die Reihenfolge ist an den
Softwarelebenslauf angelehnt.
Vorteile:
• Einfachheit
• Modellierung des natürlichen Lebenslaufes
• weite Verbreitung
Nachteile:
• Aufgrund der Softwareevolution und aufgrund der Tatsache, dass die erkannten Fehler nicht immer
in der aktuellen oder vorgängigen Phase gemacht wurden, sind häufig Iterationen über mehrere
Phasen hinweg erforderlich. Dies erschwert die Projektführung und hat dem Wasserfall-Modell sehr
viel berechtigte Kritik eingetragen.
Vor allem geeignet für:
• Dieses Modell sollte heute nicht mehr verwendet werden.
Seite 13
Software Enigneering
3.2.3 Ergebnisorientierte Phasenmodelle
Der Software-Prozess
Prozessmodelle für die Entwicklung von Software
Ergebnisorientierte Modelle machen wie das Wasserfall-Modell den Softwarelebenslauf zur Grundlage
des Prozesses. Eine einzelnen Phase ist aber nicht mehr eine Tätigkeit sondern ein Zeitintervall.
Ergebnisorientiertes Phasenmodell: Ein Modell für den Software-Entwicklungsprozess, welches die
Entwicklung in eine Sequenz aufeinanderfolgender Zeitabschnitte (Phasen) unterteilt und in jeder
Phase eine Teil der insgesamt zu liefernden Ergebnisse erarbeitet. Die Reihenfolge der Phasen
orientiert sich am Softwarelebenslauf
Die Phasen sind nach dem Ergebnis oder nach der vorherrschenden Tätigkeit die, die zum Ergebnis
führt, benannt. Es gibt keine Iteration. Es können/müssen aber notwendige Nachbesserungen
gemacht werden. jeder Phasenabschluss bildet einen Meilenstein in der Entwicklung.
Vorteile:
• Leicht verständlich
• Folgen dem Softwarelebenslauf
• Geeignet für Projektführung
• Sie fördern planvolles Vorgehen
• Ausführliche Spezifikationen und Entwürfe tragen dazu bei, Fehler früh zu erkennen
Nachteile:
• Vor allem grosse Systeme können nicht planvoll in einer Abfolge von Schritten konstruiert werden,
denn sie wachsen evolutionär.
• Lauffähige Systemteile entstehen erst sehr spät. Dies ist einerseits schlecht für die Motivation der
Projektbeteiligten und anderseits wird erst sehr spät erkannt, wenn ein System nicht realisierbar ist.
• System muss in einem Schritt komplett in Betrieb genommen werden.
Vor allem geeignet für:
• Kleine bis mittlere Projekte
• Genau bekannte und präzise beschriebene Aufgaben
• Wenn Know-how im entsprechenden Problembereich vorhanden ist
• Geringes Entwicklungsrisiko
Seite 14
Der Software-Prozess
Prozessmodelle für die Entwicklung von Software
Software Enigneering
Der Software-Prozess
Prozessmodelle für die Entwicklung von Software
3.2.5 Das Spiral-Modell
Software Enigneering
3.2.4 Wachstumsmodelle
Das Spiral-Modell ist eine von Boehm stammende Weiterentwicklung des Wasserfall-Modells. Es ist
vor allem für die Entwicklung grosser, risikoreicher Systeme gedacht.
Anstelle der zyklischen Abfolge “Entwickeln, Prüfen, Entwickeln ..” tritt ein vierteiliger Zyklus, der den
vier Quadranten entspricht:
Wachstums-Modelle stellen den Gedanken der Softwareevolution in den Mittelpunkt. Ein System wird
nicht konstruiert sondern es wächst in einer Reihe aufeinanderfolgender Schritte (Versionen-Modell,
evolutionäres Modell, inkrementelles Modell).
Wachstumsmodell: Ein Modell für den Software-Entwicklungsprozess, welches die Entwicklung in der
Folge von Iterationen unterteilt. In jeder Iteration wird ein vollständiges Teilergebnis mit betriebsfähiger
Software erarbeitet und ausgeliefert.
Jede Lieferung wird als weitgehend autonomes Teilprojekt organisiert. Da diese in der Regel sehr klein
sind, kann ein ergebnisorientiertes Phasenmodell verwendet werden.
Vorteile:
• Modellierung des natürlichen Verhaltens der meisten grossen Systeme
2. Zielsetzung bzw. Zielkorrektur
1. Planung des Spiralumlaufs
3. Untersuchung von Varianten und ihren Risiken; Variantenentscheid
• Sehr geeignetes Instrument für Projektführung, denn die Projektführung im Grossen erfolgt mit den
Meilensteinen der Lieferung.
• Es entstehen sehr schnell lauffähige Teile des Systems
Boehm bezeichnet dieses Modell als risikogesteuert. Das Hauptmittel hierfür sind Prototypen.
Seite 16
Dieser Zyklus wird vier Mal durchlaufen, nämlich für die Systemdefinition, Anforderungen an die
Software, Konzipierung (Architektur-Entwurf) und Realisierung (Detailentwurf, Codierung, Test,
Integration und Installation).
4. Entwicklung und Prüfung (analog Wasserfall-Modell)
• Das System kann sanft eingeführt werden
Nachteile:
• Gefahr, dass Komponenten nicht zusammenpassen
• Die Konzepte und Strukturen können durch Ergänzungen und Änderungen in späteren Lieferung
bis zur Unkenntlichkeit entstellt werde, so dass sich die Pflegbarkeit des Gesamtsystems drastisch
verschlechtert.
Vor allem geeignet für:
• Grosse Projekte mit langer Entwicklungszeit
• Nicht gesamte Funktionalität wird von Beginn weg benötigt
• Keine vollständige Definition von Beginn weg; Sammeln von Erfahrungen
• Basisprodukt, das schnell auf dem Markt sein muss
Seite 15
Software Enigneering
Der Software-Prozess
Prototypen
3.3 Prototypen
Der Software-Prozess
Prozessmodelle für die Entwicklung von Software
3.2.6 Das prototypingorientierte Life-Cycle-Modell
Ein Softwareprototyp ist ein - mit wesentlich geringerem Aufwand als das geplante Produkt
hergestelltes - einfach zu änderndes und zu erweiterndes ausführbares Modell des geplanten
Softwareproduktes, das nicht notwendigerweise alle Eigenschaften des Zielsystems aufweisen muss,
jedoch so geartet ist, dass vor der eigentlichen Systemimplementation der Anwender die wesentlichen
Systemeigenschaften erproben kann. Prototyping umfasst alle Arbeiten, die zur Herstellung solcher
Prototypen notwendig sind.
Software Enigneering
Eine prototypingorientierte Softwareentwicklung unterscheidet sich nicht grundsätzlich von der
klassischen phasenorientierten Entwicklung; sie sind mehr komplementär als alternativ. Das Modell ist
iterativ und nicht linear. Der grösste Unterschied liegt in der Vorgehensweise und bei den Ergebnissen
der einzelnen Ergebnisse: Analyse und Spezifikation überlappen sich stark und Implementierung und
Test verschmelzen. Es handelt sich nicht mehr um Phasen sonder um Aktivitäten.
Prototyp: Ein lauffähiges Stück Software, welches kritische Teile eines zu entwickelnden Systems
vorab realisiert.
Exploratives Prototyping (Demonstrationsprototypen): Ziel ist eine möglichst vollständige
Systemspezifikation. Zweck ist eine Diskussion der verschiedenen Lösungsansätze, Einblick der
Entwickler in die Welt der Anwender und Abklärung der Realisierbarkeit. Das explorative Prototyping
unterstützt die Problemanalyse und die Systemspezifikation.
Experimentelles Prototyping (Labormuster oder Wegwerfprototypen): Ziel ist eine vollständige
Systemspezifikation von Teilsystemen als Grundlage für die Implementierung. Zudem soll die
Realisierbarkeit kritischer Systemteile untersucht und Entwurfsalternativen bewertet werden. Zweck ist
der Nachweis der Tauglichkeit von Teilspezifikationen, Architekturmodellen und Lösungsideen. Das
experimentelle Prototyping unterstützt den System- und Komponentendesign.
Evolutionäres Prototyping (Pilotsystem): Ziel ist die inkrementelle Systementwicklung. Für die klaren
Benutzerforderungen wird ein Prototyp realisiert. Auf dieser Basis werden neue Anforderungen
aufgenommen und integriert. Durch dieses Vorgehen wird die Systemspezifikation entschärft, das
Problem des Systemdesigns bleibt bestehen.
Vollständiger Prototyp: Alle wesentlichen Funktionen sind verfügbar. Die gemachten Erfahrungen
bilden die Grundlage für die endgültige Systemspezifikation.
Unvollständiger Prototyp: Es wird nur ein Teilaspekt realisiert und überprüft (Systemarchtitektur,
Benutzerschnittstelle etc.)
Das Arbeiten mit Prototypen ist kein eigenständiges Modell für die Entwicklung von Software:
• Demonstrationsprototypen: Unterstützen die Akquisition von Aufträgen und das Aufsetzen von
Projekten.
• Wegwerfprototyp: Implementierung des Prototyps kann nicht für die Realisierung verwendet
werden. Sie dienen der Risikominderung.
Die wichtigsten Aktivitäten sind:
• Prototypen spezifizieren
• Wiederverwendbarer Prototyp: Wesentliche Teile werden für die Implemtierung übernommen
nicht,
welche
im
Unternehmen
vorhandene
Software
Seite 18
3. Die Urheber von potentiell Wiederverwendbarem sind oft nicht bereit, irgendwelche Haftungen oder
Garantien zu übernehmen.
2. Oft wissen die Projektmitglieder
wiederverwendet werden könnte.
1. Wiederverwendbare Software ist in der Herstellung aufwendiger (muss allgemeingültiger angelegt
und ausführlicher dokumentiert werden).
Wiederverwendung von Software fällt nicht vom Himmel, sondern man muss ihr auf die Sprünge
helfen. Dies im wesentlichen drei Gründe:
Die einzige Möglichkeit, die Kosten pro verkauftem Exemplar Software massiv zu senken, ist eine
massive Steigerung der Stückzahl, in der diese Software verwendet oder verkauft wird. Neben grossen
Serien eines Produktes bringt die Wiederverwendung von Software Kosteneinsparungen.
Die Produktivität bei der Entwicklung neuer Software lässt sich nach heutigen Erkenntnissen nur in
ziemlich enge begrenzten Rahmen steigern, weil wesentliche Teile des Entwicklungsprozesses
kreative Arbeiten sind, die weder automatisierbar sind noch mit Hilfsmitteln massiv beschleunigt
werden können (Brooks 1987).
3.4 Wiederverwendung und Beschaffung
• Prototypen herstellen
• Mit Prototyp experimentieren
• Annahme Prototyp oder Anpassung Spezifikation und Neubeginn
Durch diese Vorgehensweise kann das Risiko einer falschen oder unvollständigen Systemspezifikation
vermindert werden. Idee ist es, so früh wie möglich mit der Implementation zu beginnen. Dadurch kann
das Risiko minimiert werden, die Qualität sichergestellt und die gemachten Erfahrungen ausgenutzt
werden.
Seite 17
Software Enigneering
Der Software-Prozess
Pflege (Wartung)
Diesen Punkten kann am besten entgegengewirkt werden, wenn es ein Profitcenter gibt, dass vom
Handel mit wiederverwendbaren Komponenten lebt (z.B. kommerziell vertriebene Klassenbibliotheken
und Software-Frameworks). Eine andere Möglichkeit zur Förderung der Wiederverwendung innerhalb
eines Unternehmens ist die Schaffung einer Informationsstelle, die die Informationen eigenständig
zusammenträgt (es entsteht kein Zusatzaufwand für Entwickler).
Wo immer möglich, werden Systeme bzw. Softwarekomponenten nicht entwickelt, sondern beschafft,
denn diese Software ist aufgrund der verkauften Stückzahlen fast immer kostengünstiger als selbst
entwickelte. Allerdings fallen neben den Beschaffungskosten oft Parametrisierungs- und
Anpassungskosten an.
3.5 Pflege (Wartung)
Pflege, oft auch Wartung genannt, ist der Prozess der systematischen Erhaltung der
Gebrauchstauglichkeit von Programmen. Die Massnahmen werden in der Regel in drei Klassen
unterteilt: Fehlerbehebung, Anpassung und Weiterentwicklung (Erweiterung und Verbesserungen).
Pflege (Wartung, maintenace): Modifikation bestehender Software und/oder Ergänzung bestehender
Software durch neue Software mit dem Ziel, Fehler zu beheben, die bestehende Software an
veränderte Bedürfnisse oder Umweltbedingungen anzupassen oder die bestehende Software um neue
Fähigkeiten zu erweitern.
Bei grosser Software, die bei vielen Kunden im Betrieb ist, ist es unmöglich jede Änderung sofort in
Betrieb zu nehmen. Statt dessen werden die Änderungen gebündelt und von Zeit zu Zeit als neuer
Release freigegeben.
Release: Eine konsistente Menge von Komponenten eines Systems, die gemeinsam zur Benutzung
freigegeben werden.
Meist wird zwischen kleinen (einige Monate) und grossen Releases (ein bis drei Jahre) unterschieden
und dies durch die Numerierung nach dem Schema m.n kenntlich gemacht. Pflegemassnahmen, auch
wenn sie sorgfältig ausgeführt werden, führen typisch dazu, dass die gepflegte Software grösser und in
ihrem strukturellen Aufbau schlechter wird.
wachsen, wenn es gebrauchstauglich bleiben soll.
Î Gesetz der kontinuierlichen Veränderung: Ein Programm unterliegt während der gesamten
Lebenszeit ständigen Veränderungen oder es verliert nach und nach seinen Nutzen.
Î Gesetz der zunehmenden Komplexität: Durch die Veränderungen nimmt die Komplexität des
Programmes ständig zu.
Î Grundgesetz der Programmevolution: Die Evolution eines Programmes unterliegt einer sich selbst
regelnden Dynamik mit statisch bestimmbaren Tendenzen und Invarianzen.
Î Gesetz der Invarianz des Arbeitsaufwandes: Der Aufwand, der in die Pflege eines Programmes
gesteckt wird, ist während der gesamten Lebenszeit konstant.
Î Gesetz der Invarianz des Release-Inhalts: Der Inhalt der Releases ist über die Folge aller Releases
während der Lebenszeit konstant.
Î Gesetz des kontinuierlichen Wachstums: Ein Programm muss während der gesamten Lebenszeit
Seite 19
Software Enigneering
4 Software-Projektführung
Software-Projektführung
Projektplanung
Es ist notwendig, dass Softwareprojekte systematisch geführt werden. Dazu gehört eine sorgfältige
Planung, fortlaufende Kontrolle und nötigenfalls eine Korrektur des Projektablaufs. Ferner muss den
Projektrisiken besondere Beachtung geschenkt werden.
4.1 Projektplanung
Neben der Definition der zu erreichenden Ziele geht es bei der Projektplanung darum, den Weg zum
Ziel und die benötigten Mittel festzulegen:
• Verwendetes Prozessmodell
• Organisationsstruktur des Projektes
• Bestimmung der Anzahl der benötigten Personen und Planung ihres Einsatzes
• Terminplan
• Kostenplan
• Festlegung der zu erstellenden Dokumente
• Anzuwendende Verfahren für die Entwicklung
• Konfigurationsmanagement
• Qualitätsmanagement und
• Abschätzung und Behandlung der Projektrisiken.
In der Planung eines konkreten Projektes wird als erstes das Prozessmodell ausgewählt, konkretisiert
und mit einer personellen Organisationsstruktur verbunden. Diese Struktur legt die Funktionen,
Aufgaben, Verantwortlichkeiten und gegenseitigen Beziehungen zwischen den Projektmitgliedern fest.
Bei der Organisation von Softwareprojekten gelten die gleichen Regeln wie für andere Projekte.
Speziell ist aber die Stellung des Projektleiters und die Beziehungen der Projektbeteiligten
untereinander.
Der Projektleiter ist die Schlüsselfigur in jedem Softwareprojekt, dessen Kompetenzen und
Verantwortlichkeiten klar geregelt sein müssen. Anzustreben ist eine Führung durch Zielsetzung: Der
Projektleiter erhält einen Auftrag (vom Auftraggeber oder aus der Linie) und wird mit den notwendigen
personellen und materiellen Ressourcen ausgestattet. Im Rahmen dieses Auftrages handelt der
Projektleiter dann eigenverantwortlich.
Die Beziehungen der Projektbeteiligten untereinander hängen von der Zahl der Personen ab. Bei allen
Organisationsformen ist anzustreben, dass möglichst viele Beteiligte möglichst ausschliesslich am
Projekt arbeiten.
Seite 20
Software Enigneering
Software-Projektführung
Projektplanung
Start eines Software-Konfigurations-Projektes
Start eines externen Auftragsprojektes
Der Projektstart ist eine der kritischen Phasen eines Projektes, denn hier werden Weichen für das
gesamte Projekt gestellt. Es empfiehlt sich, jedem Projekt ein Vorprojekt vorzuschalten, in dem das
Projekt aufgesetzt wird und wichtige Definitions- und Planungsarbeiten ablaufen.
Start eines unternehmensinternen Softwareprojektes
Start eines Produktenetwicklungprojektes
Seite 21
Software Enigneering
Software-Projektführung
Projektplanung
Im Projektplan werden alle Ergebnisse der Planung sowie alle Planungsfortschreibungen
dokumentiert:
• Warum: Vernehmlassung und Projektziele
• Was: Produktziele (Die zu liefernden Resultate)
• Wann: Geplante Termine
• Durch Wen: Personen und ihre Verantwortlichkeiten
• Womit: Zur Verfügung stehende Mittel (Geld, Geräte, Software)
• Wie: Vorgehensweise und die Massnahmen zur Sicherstellung des Projekterfolges
Bei linearen Prozessmodellen, z.B. dem ergebnisorientierten Phasenmodell, erfolgt die Planung im
Vorprojekt. Danach wird die Planung nur noch fortgeschrieben. Bei inkrementellen Prozessen, den
Wachstumsmodellen gibt es mehrere Planungsabschnitte. Im Vorprojekt erfolgt die Grobplanung, die
insbesondere die Erstellung des Lieferplans umfasst. Jedes Inkrement wird in einem kleinen
Vorprojekt geplant, wenn es zur Ausführung ansteht.
Arbeits- Termin-, Kosten- und Personaleinsatzpläne sollten grafisch in Diagrammen mit
Planungshilfsmittel dargestellt werden. Sie werden so angelegt, dass im Projektablauf ein Soll/IstVergleich geführt werden kann. Es ist wichtig, dass die geplanten und die tatsächlichen Aufwendungen
möglichst genau erfasst und dokumentiert werden, denn nur so können die Daten ausgewertet und als
Basis für Zukünftige Aufwandschätzungen verwendet werden.
Seite 22
Software Enigneering
4.2 Projektkontrolle und -lenkung
Software-Projektführung
Projektkontrolle und -lenkung
Planung ist nur sinnvoll, wenn auch kontrolliert wird, ob der Arbeitsfortschritt der Planung entspricht.
Fortschrittskontrollen müssen messbare Ergebnisse haben, wenn sie nützlich sein sollen, andernfalls
gerät man rasch in die Falle des 90%-Syndroms.
Die wichtigsten Kontrollmassnahmen sind:
• Terminverfolgung geschieht mit Hilfe von Meilensteinen. In der Planung hat jeder Meilenstein einen
Solltermin.
• Sachzielverfolgung geschieht ebenfalls mit Hilfe von Meilensteinen, indem jeder erreichte
Meilenstein ein fertiggestelltes Zwischenergebnis dokumentiert.
• Bei der Kostenverfolgung werden die budgetierten und die tatsächlichen Kosten über den
Projektfortschritt und nicht die Zeit aufgezeichnet, da die Zeit keine Aussage über den
Projektfortschritt macht. Auch hier werden oft Meilensteine zu Hilfe genommen.
• Die Risikoverfolgung wird im Kapitel 4.4, “Software-Risikoführung” erläutert
Ein nützliches Hilfsmittel in der Kontrolle vor allem grösserer Softwareprojekte ist ein organisiertes
Berichtswesen (z.B. Wochen- oder Monatsvorschrittsberichte), welches eine Frühwarnfunktion ausübt.
Werden bei der Projektkontrolle grössere Abweichungen erkannt, so müssen die Ursachen dafür
ergründet und entsprechende Lenkungsmassnahmen ergriffen werden. Wenn der Projektplan trotz
Gegenmassnahmen nicht einhaltbar ist, so muss der Projektplan den neuen Gegebenheiten
angepasst werden, denn nach unrealistischen Plänen zu arbeiten ist demotivierend und wenig effektiv.
Seite 23
Software Enigneering
4.3 Der Projektabschluss
Software-Projektführung
Der Projektabschluss
Der Projektabschluss ist fast so wichtig wie der Projektstart. Es geht darum, das entstandene Produkt
geordnet in die Phase der Pflege überzuleiten und das entstandene Projektwissen zu sichern. Die
entstandenen Dokumente und Messungen werden gezielt ausgewertet und so aufbereitet, dass
künftige Projekte auf die gemachten Erfahrungen zurückgreifen können.
Alle für die Pflege der Software, für den Nachweis qualitätsrelevanter Eigenschaften oder für eine
spätere Auswertung notwendigen Dokumente und Messungen werden archiviert, der Test wird
vernichtet.
4.4 Software-Risikoführung
Projektrisiken sind Ereignisse, welche den sachlichen oder wirtschaftlichen Erfolg eines Projektes
bedrohen. Gut geführte Projekte zeichnen sich dadurch aus, dass in ihnen die Risiken nicht dem Zufall
überlassen werden, sondern dass der Projektleiter eine explizite Risikoführung betreibt (Boehm 1989,
1991). Aufgaben der Risikoführung sind:
Ziel der Risikobestimmung ist es, die Risiken zu erkennen. Eine Checkliste oder zumindest das
Durchgehen der Liste der zehn häufigsten Software-Projektrisiken ist dabei hilfreich:
Seite 24
Software Enigneering
Software-Projektführung
Software-Risikoführung
In der Risikoanalyse wird die Gefährlichkeit der einzelnen Risiken bestimmt und werden Probleme
untersucht, die sich aus dem gleichzeitigen Eintreten mehrere Risiken ergeben. Die Gefährlichkeit
eines Risikos ist abhängig von der Eintretenswahscheinlichkeit (1-10 / Klein - Mittel - Gross) und von
der Schadenshöhe (1-10 / Klein - Mittel - Gross). Speziell müssen Restrisiken beachtet werden, denn
sie weisen einen sehr kleinen Risikofaktor auf, können aber sehr grossen (finanziellen) Schaden
anrichten.
In der Risikobewertung werden die Konsequenzen aus der Risikoanalyse gezogen. Es wird eine
Rangliste der Risiken erstellt und es werden Massnahmen zur Risikominderung geplant und
eingeleitet.
Ziel der Risikosteuerung ist es die erkannten Risiken zu behandeln. Um die erkannten Risiken in den
Griff zu bekommen, braucht es für jedes grössere Risiko einen Plan, wie das Risiko beherrscht
werden soll. Für jedes Risiko muss man sich überlegen:
• Ist das Risiko vermeidbar
• Welche Massnahmen zur Risikominderung können getroffen werden
• Wie kann das Risiko verfolgt werden
• Kann das Risiko auf Dritte abgewälzt werden
In der Tabelle zur Risikoerkennung sind Massnahmen zur Risikominderung aufgeführt. Sie lassen
sich in den Gruppen Informationsbeschaffung, Personalpolitik, Prototypen, Simulationen und
Vereinfachung zusammenfassen.
In der Risikoverfolgung geht es darum, die wichtigsten Risiken und ihre Entwicklung während der
gesamten Projektabwicklung zu überwachen. Boehm empfiehlt, in jedem Projekt eine Rangliste mit
den 10 wichtigsten Risiken zu führen und in regelmässigen Abständen in Sitzungen zu diskutieren.
Auf den ersten Blick verursacht sorgfältige Risikoführung nur Kosten. Vor allem ist es schwierig den
Nutzen zu beziffern, da über Schadensfälle nur spekuliert werden kann. In vernünftigem Umfang
eingesetzt ist die Risikoführung im statistischen Mittel wirtschaftlich und sie vermindern die
Wahrscheinlichkeit, dass der Risikofall zur finanziellen Katastrophe wird.
Seite 25
Software Enigneering
5 Software-Aufwandschätzverfahren
5.1 Allgemeines
Software-Aufwandschätzverfahren
Allgemeines
Software-Aufwandschätzung ist nicht trivial und es werden oft krasse Fehleinschätzungen gemacht.
Gründe hierfür sind:
• Softwareerstellung ist Kopfarbeit und daher stark von der Leistungsfähigkeit dieser Köpfe abhängig
(Schwankungen um mehr als eine Grössenordnung)
• Nur ein kleiner Teil der Software trägt die eigentliche Funktionalität. Ein grosser Teil (und dies wird
oft übersehen) geht in die Verwaltung, Fehlerbehandlung, Benutzerschnittstelle etc. Ein Programm
besteht aus:
• Erfahrungen aus kleineren Projekten werden linear extrapoliert
• Programmierer programmieren nicht 100% ihrer Zeit
5.2 Empirische Schätzverfahren
Expertenbeurteilung ist eine vornehme Bezeichnung für Schätzungen über den Daumen. Die Güte
der Schätzung steht und fällt mit der Erfahrung der Schätzenden.
Î
Expertenbeurteilung ist ein einfaches und billiges Schätzverfahren, das dann recht gut funktioniert,
wenn die Schätzenden Erfahrung mit gleichartigen Projekten haben. Andernfalls können die
Prognosen sehr ungenau sein.
Die Delphi-Methode versucht Expertenschätzungen zu objektivieren. Mehrere Personen geben
unabhängig voneinander eine begründete Schätzung ab. In einer nächsten Runde erhalten alle
Beteiligten eine Zusammenfassung der ersten Schätzungen. Daraufhin geben sie eine neue
Schätzung ab, wobei Abweichungen vom Mittelwert begründet werden müssen.
Î
Die Delphi-Methode liefert zuverlässigere Schätzungen als die Expertenbeurteilung, weil sie
Ausreisser eliminiert. Als Nachteil muss ein erheblich höherer Schätzaufwand in Kauf genommen
werden.
5.3 Algorithmische Schätzverfahren
Algorithmische Verfahren bestehen aus einem oder mehreren Algorithmen zur Berechnung einer
Kosten- bzw. Durchlaufzeit-Funktion aus einer Reihe von Variabeln. Bei hinreichend genauen
Eingaben ergeben sich erstaunlich präzise Prognosen. Die Genauigkeit hängt im Wesentlichen von
zwei Dingen ab:
• Die Eingangsgrössen der Kostenfunktion müssen einigermassen zutreffend geschätzt werden
• Das Modell muss kalibriert werden (Anpassung an die jeweilige Entwicklungsumgebung) wozu
genügend Messwerte von durchgeführten Projekten notwendig sind
Seite 26
Software Enigneering
Î
Software-Aufwandschätzverfahren
Beispiele algorithmischer Schätzverfahren
Algorithmische Methoden liefern die besten Schätzungen. Sie können aber nur nach
entsprechenden Vorarbeiten (Kalibrierung) überhaupt eingesetzt werden. Ausserdem sind sie stark
abhängig von der Genauigkeit, mit der die Eingangsgrössen bestimmt werden können (garbage-ingarbage-out-Problem)
5.4 Beispiele algorithmischer Schätzverfahren
5.4.1 COCOMO
COCOMO (Constructive Cost Model) ist das Kostenschätzverfahren von Boehm (1981). Es geht von
einer Schätzung der Produktgrösse in KDSI (Kilo lines of delivered source instructions) aus.
2,4 KDSI
0,38
2,5 MM
1,05
(MM = man month)
(TDEV = time of develop)
Einfache Anwendungsprogramme (organic Mode):
MM =
TDEV =
3,0 KDSI
0,35
2,5 MM
1,12
(MM = man month)
(TDEV = time of develop)
Programmsysteme mit erheblichem Anteil an Interaktion mit Betriebssystem, Gerätetreibern etc.
(semidetached mode):
MM =
TDEV =
3,6 KDSI
0,32
2,5 MM
1,2
(MM = man month)
(TDEV = time of develop)
Eingebettete Systeme (embedded mode)
MM =
TDEV =
MMKorr =
Produkt der Kostenfaktoren x MMNominal
Diese ermittelten Nominalwerte können nun noch erheblich genauer gemacht werden, indem man sie
mit einer Reihe von Kostenfaktoren multipliziert.
Seite 27
Software Enigneering
5.4.2 Das Function Point-Verfahren
Software-Aufwandschätzverfahren
Beispiele algorithmischer Schätzverfahren
Function Points sind ein relatives Mass zur Bewertung der Funktionalität, d.h. des Leistungsumfanges
eines Systems. Verfügt ein Unternehmen Erfahrungszahlen wieviel Aufwand pro Function Point im
Mittel benötigt wird um Software zu entwickeln oder zu Pflegen, so kann dieses Verfahren für die
Aufwandschätzung herangezogen werden.
Die Idee, welche von Albert (1979) bei der IBM entwickelt wurde, ist es, folgende Grössen eines
Softwaresystems in geeigneter Weise zu zählen und zu bewerten:
• Dateneingaben (External input)
• Datenausgaben (External output)
• Anfragen (External inquiry)
• Schnittstellen zu externen Datenbeständen (External interface file)
• Interne Datenbestände (Logical internal file)
All diese Werte werden mit “einfach”, “mittel” und “komplex” bewertet und mit einer entsprechenden
Gewichtung versehen.
Gewichtungskriterien für Dateneingaben:
Schema zur Berechnung des Function Point Rohwertes UFP:
Seite 28
Software Enigneering
TCF =
UFP x TCF
0,65 + 0,01 x DI
Software-Aufwandschätzverfahren
Beispiele algorithmischer Schätzverfahren
(DI = Degree of Influence)
Der Rohwert wird mit Gewichtungsfaktoren multipliziert, welche die technische Komplexität des
Systems reflektieren. Der sogenannte technische Komplexitätsfaktor (TCF, technical complexity factor)
berechnet sich nach der Formel:
FP =
Sollen Function Points zur Aufwandschätzung verwendet werden, so muss der zu erwartende Aufwand
pro Function Point bekannt sein. Dafür existieren auch Umrechnungskurven, doch die sind mit
Vorsicht zu geniessen, denn schon innerhalb der gleichen Firma weisen die zum Teil massive
Abweichungen auf.
Î
Faustregeln von Jones zur Aufwandberechnung:
0,4
Durchlaufzeit (in Monaten) = FP
Anzahl Mitarbeiter: FP / 150
0,4
Aufwand = Durchlaufzeit x Anzahl Mitarbeiter = FP x FP / 150
Sollen projektspezifische Faktoren (z.B. Erfahrung der Programmierer) berücksichtigt werden, so
müssen bei der Umrechnung von Function Points in Personenmonate zusätzliche Korrekturfaktoren
zur Anwendung kommen. Das Function Point-Verfahren muss wie jedes algorithmische Verfahren
kalibriert werden, bevor es eingesetzt werden kann.
Jones (1995) gibt folgende Erfahrungswerte für die Umrechnung von Function Points in Codezeilen an:
Vorteil des Function Point-Verfahren ist es, dass die benötigten Eingangsgrössen sich früher und
leichter bestimmen lassen als bei COCOMO. Zudem sind Produktivitätsmessungen möglich, die
weniger leicht gefälscht werden können als Messung auf Basis der erzeugten Codezeilen. Das FPVerfahren ist aber Informationssysteme zugeschnitten und das FP-Mass ist auch nicht additiv, d.h. die
Summe von n logisch zusammenhängenden Teilsystemen ist grösser als die Anzahl der FP des
Gesamtsystems, da Schnittstellen mehrfach gezählt werden.
Seite 29
Software Enigneering
5.4.3 Sonstige Methoden
• Schätzen, dass man den Auftrag in jedem Fall bekommt
• So viel schätzen, wie der Auftraggeber bereit ist zu zahlen
Software-Aufwandschätzverfahren
Schätzung von Pflegekosten
• Das Projekt kostet soviel Arbeitskapazität wie vorhanden ist (Parkinson’sches Gesetz)
5.5 Schätzung von Pflegekosten
Î
Das Kostenverhältnis zwischen Entwicklung und Pflege eines Softwareproduktes liegt im Bereich
von 30:70 und 50:50. Je länger ein Produkt lebt und je schlechter seine Qualität ist, desto höher ist
der Kostenanteil für die Pflege.
N / 500 Personen erforderlich
Î Die Kosten für die Pflege eines Softwareproduktes verteilen sich wie folgt: 60% Verbesserungen,
20% Anpassungen und 20% Fehlerbehebung.
Î Faustregel von Jones für den Pflegeaufwand: Zur Pflege eines Systems von N Function Points sind
5.6 Einfluss der Schätzung auf den Aufwand
Es gibt Hinweise dafür, dass Schätzung und tatsächlicher Aufwand keine voneinander unabhängige
Grössen sind. Dies ist das durch das Gesetz von Parkinson (Der Aufwand passt sich der verfügbaren
Zeit) beschriebene Phänomen. Dieses Phänomen tritt vor allem dann auf, wenn in zu knapp
kalkulierten Terminplänen Luft geschaffen wird.
Seite 30
Software Enigneering
6 Anforderungsspezifikation
6.1 Grundlagen und Motivation
Anforderungsspezifikation
Grundlagen und Motivation
Eine Anforderungsspezifikation ist die Zusammenstellung aller Anforderungen an eine Software.
Synonyme: Anforderungsdokument, Software Requirements Specification
Unter Anforderungsspezifikation ist die Erarbeitung eines Kontraktes zwischen Auftraggeber und
Softwareentwickler zu verstehen, der genau festlegt, was das geplante System leisten soll und welche
Prämissen für dessen Realisierung gelten.
Der Spezifikationsprozess ist der Prozess des Erfassens, des Beschreibens und Prüfens von
Anforderungen.
Werden die Aufgaben im Bereich der Spezifikation und des Spezifizierens systematisch und gezielt
angegangen, spricht man auch von Requirements Engineering (Anforderungstechnik). Requirements
Engineering ist das systematische, disziplinierte und quantitativ erfassbare Vorgehen beim
Spezifizieren, d.h. Erfassen, Beschreiben und Prüfen von Anforderungen an Software.
Die Erstellung einer Anforderungsspezifikation kostet Geld, ohne dass diesem Aufwand ein
unmittelbarer sichtbarer Ertrag in Form von Programmen gegenübersteht. Das Spezifizieren von
Anforderungen ist nur dann wirtschaftlich, wenn dem dafür zu treibenden Aufwand entsprechende
Einsparungen gegenüberstehen. Die Kosten für das Requirements Engineering müssen also tiefer
sein als die eingesparten Fehlerkosten.
Um Fehlerkosten zu senken, muss erreicht werden, dass wenig Anforderungsfehler gemacht werden
und dass viele der dennoch gemachten Fehler möglichst früh erkannt werden. Eine gute Spezifikation
zeichnet sich durch folgende Eigenschaften aus:
• Adäquatheit (Beschreiben was der Kunde will)
• Vollständigkeit (alles was der Kunde will)
• Widerspruchsfreiheit
• Verständlichkeit (für Kunde und Informatiker)
• Eindeutigkeit (Vermeidung von Fehlinterpretationen)
• Prüfbarkeit
Seite 31
Software Enigneering
Ein guter Spezifikationsprozess ist charakterisiert durch:
• Kundenorientierung
• Methodisches und zielgerichtetes Vorgehen
• Verwendung geeigneter Mittel
• Integration von Erstellung und Prüfung von Anforderungen
6.2 Der Spezifikationsprozess
Anforderungsspezifikation
Der Spezifikationsprozess
Der Prozess des Spezifizierens von Anforderungen umfasst im wesentlichen drei Aufgaben:
Gewinnung, Darstellung und Prüfung der Anforderungen. Dieser Prozess kann jedoch nicht sequentiell
durchgeführt werden, sondern basiert auf ständiger Interaktion zwischen Vertretern des Kunden und
den Informatikern/Analytikern.
6.3 Dokumentation von Anforderungen
Es gibt verschiedene Arten von Anforderungen. Auf oberster Ebene können Projekt- und Produkteanforderungen unterschieden werden. In diesem Kapitel interessieren nur die Produkteanforderungen.
Funktionale Anforderungen sind Anforderungen, die sich auf die Funktionalität eines Systems
beziehen, d.h. welche Ergebnisse aufgrund welcher Eingaben zu verarbeiten sind. Die Attribute
spezifizieren die Art und Weise, wie diese Funktionalität zu erbringen ist. Zu den Leistungsanforderungen gehören Zeiten, Mengen, Geschwindigkeiten, Raten etc. Besondere Qualitätsanforderungen sind z.B. Zuverlässigkeit oder Benutzerfreundlichkeit und zu den Randbedingungen
gehören z.B. Gesetze und Normen.
Seite 32
Software Enigneering
Anforderungsspezifikation
Gewinnung der Anforderungen
Die Anforderungen müssen häufig (z.B. bei Fremdbeschaffung oder wenn Entwicklungskosten eine
harte Rahmenbedingung darstellen) nach ihrer Wichtigkeit klassifiziert werden:
Software Enigneering
• Anwendungsszenarien bilden und durchspielen
• Fragebogentechnik (Entwickler muss Gebiet kennen)
Es gibt keine Technik, die Methodencharakter hat und allgemein für die Problemanalyse einsetzbar ist.
Es gibt aber eine Auswahl verschiedener Methoden für unterschiedliche Zielsetzungen:
Anforderungsspezifikation
Darstellung von Anforderungen
• Soll-Anforderung: Können bei zu hohen Kosten weggelassen werden
• Einzel- und Gruppeninterviews (einfach und flexibel aber schwieriger zu verarbeiten)
• Den Anwendungsbereich modellieren
• Wunsch-Anforderungen: Werden nur bei vertretbaren Kosten erfüllt
• Muss-Anforderung: Unverzichtbar
Als zentrale Elemente gehören folgende Punkte zum Inhalt der Systemspezifikation:
• Ausgedehnte Mitarbeit eines Analytikers
Seite 34
Nachteile:
- Deskriptive Beschreibung real grosser Systeme mit Text ist sehr umfangreich und wenig strukturiert
- Deskriptive Beschreibung real grosser Systeme ist sehr schwierig
- Die Prüfung ist fast unmöglich
Vorteile:
- Beschreibung beschränkt sich auf das Verhalten
- Darstellung ist lösungsneutral
Eine deskriptive Darstellung betrachtet das zu spezifizierende System als schwarzen Kasten. Die
Anforderungen werden durch Beschreibung der geforderten Zusammenhänge zwischen den
Resultatdaten und den Eingabedaten dargestellt.
6.5.1 Art der Darstellung
6.5 Darstellung von Anforderungen
• das Ist-System auf eine andere Plattform portiert werden soll
• Teile des Ist-Systems übernommen werden
• die Stärken und Schwächen des Ist-Systems nicht bekannt sind
• die Informatiker/Analytiker das Ist-System kennenlernen müssen, um mit dem Kunden über das
Soll-System zu diskutieren
Dieses Vorgehen hält jedoch in vielen Fällen der Wirtschaftlichkeitsprüfung nicht stand. Eine IstAnalyse ist gerechtfertigt, wenn:
4. Entwurf des Soll-Systems
3. Ableiten der Anforderungen an das neue System
2. Analyse der dieser Implementierung zugrundeliegenden Konzepte
1. Analyse Ist-System
In vielen Lehrbüchern älteren Datum wird verlangt, dass der Spezifikationsprozess mit einer IstAnalyse beginnt:
• Berichtsmethode (Sachbearbeiter kennt sein Gebiet sehr gut / mangelnde Erfahrung im
Berichteschreiben, Gebiet wird zu wichtig dargestellt)
Funktionaler Aspekt:
- Daten: Struktur, Verwendung, Erzeugung, Speicherung, Übertragung, Veränderung
- Funktionen: Ausgabe, Verarbeitung, Eingabe von Daten
- Fehler: Normalfall und Fehlerfälle
Leistungsaspekt (Messbare Angaben!):
- Datenmengen (Durchschnitt/Extremfall)
- Verarbeitungs-/Reaktionsgeschwindigkeit (Durchschnitt/Extremfall)
- Verarbeitungszeiten und -intervalle
Qualitätsaspekt:
- Geforderte Qualitäten (z.B. Benutzerfreundlichkeit, Zuverlässigkeit)
Randbedingungsaspekt:
- Einzuhaltende / zu verwendende Schnittstellen
- Normen und Gesetze
- Datenschutz, Datensicherung
- Explizite Vorgaben des Auftraggebers
Des weiteren sollte spezifiziert werden:
Ausgangssituation und Zielsetzung:
- Allgemeine Beschreibung der Ausgangssituation (Bezug auf Ist-Zustand)
- Projektziele und Abgrenzung zur Systemumgebung
Systemeinsatz und Systemumgebung:
Voraussetzungen, die für den Systemeinsatz gegeben sein müssen (Beschreibung aller Informationen
die für den Einsatz erforderlich sind, aber nicht Gegenstand der Implementierung sind) und Anzahl,
Häufigkeit und Aufgaben der Benutzer.
Benutzerschnittstellen:
Dokumentation der Art und Weise wie die Benutzer mit dem System kommunizieren
(Bildschirmaufbau, Druckbilder, Interaktion). Dieser Teil hat starken Einfluss auf die Akzeptanz des
Produktes.
Dokumentationsanforderungen:
Art und Umfang der Dokumentation (Benutzerdokumentation und Systempflege
Glossar und Index:
Als Referenz über die verschiedenen Inhalte und für die Definition der verwendeten Begriffe
6.4 Gewinnung der Anforderungen
Bei der Gewinnung von Anforderungen treten typischerweise die folgenden Schwierigkeiten auf:
• Unterschiedliche Vertreter des Kunden habe unterschiedliche Vorstellungen über das zu
spezifizierende System
• Die Kundenvertreter sind nicht in der Lage ihre Ideen zu formulieren
• Die Kundenvertreter wissen nur sehr wage, was sie eigentlich wollen
Um trotz der Schwierigkeiten Erfolg zu haben, ist folgendes Vorgehen sinnvoll:
• Begriffe klären und ein Glossar mit Definitionen der wichtigsten Begriffe des Anwendungsbereiches
erstellen.
• Soll-Prozessabläufe untersuchen
Seite 33
Software Enigneering
Anforderungsspezifikation
Darstellung von Anforderungen
Die konstruktive Darstellung modelliert das zu spezifizierende System als eine Menge interagierender
Komponenten. Die Anforderungen werden dargestellt, indem die zur Erzeugung der geforderten
Resultate mit Hilfe der Komponenten und deren Zusammenarbeit in idealisierter Weise beschrieben
werden. Das wohl bekannteste Beispiel ist das Datenflussdiagramm.
Vorteile:
- Spezifikation ist ein anschauliches Modell der Problemstellung
- Darstellung ermöglicht die Zerlegung der Gesamtaufgabe in Teilaufgaben
- Kombination von Teilen mit unterschiedlicher Formalisierung ist möglich
- In vielen Fällen ist es möglich die Lösung gleich wie die Aufgabenstellung zu strukturieren
Nachteile:
- Bei der Modellierung wird auf die Implementierung geschielt
- Suboptimale Lösungen können entstehen, wenn die Lösungsstruktur unverändert von
der Anforderungsstruktur übernommen wir
6.5.2 Formalitätsgrad der Darstellung
Eine informale Spezifikation erfolgt in der Regel deskriptiv mit natürlicher Sprache. Die Erstellung ist
einfach. Sie enthalten in der Regel aber sehr viele Unklarheiten, Auslassungen, Mehrdeutigkeiten und
Widersprüche, die bei der Prüfung nicht alle entdeckt werden.
Formale Spezifikationen verwenden formale Kalküle, die sich mathematischer Mittel bedienen. Es
sind sowohl konstruktive (Petri-Netze) wie auch deskriptive (Logik) Verfahren möglich. Die
Spezifikation ist immer eindeutig, die Widerspruchsfreiheit formal prüfbar. Die Kosten für die Erstellung
und die Prüfung sind aber in der Regel so hoch, dass sich der Aufwand nicht lohnt.
Seite 35
Software Enigneering
Anforderungsspezifikation
Darstellung von Anforderungen
Teilformale Spezifikationen basieren auf konstruktiven, anschaulichen Modellen, deren
Konstruktionsregeln mit ihren Bedeutungen teilweise formalisiert sind, die aber nicht formale Elemente
verwenden (z.B. Entity-Relationship-Modell, Zustandsautomaten u.a.). Diese Darstellungen weisen das
beste Kosten-Nutzenverhältnis auf, vor allem dann, wenn nicht alle Teile den gleichen
Formalisierungsgrad aufweisen müssen.
6.5.3 Verfügbare Gliederung- und Abstraktionsmittel
Abstraktionen dienen dazu, ein Modell so zu gliedern und zu strukturieren, dass die Komplexität des
Modells besser beherrschbar und die Darstellung damit leichter verständlich wird.
Seite 36
Software Enigneering
Anforderungsspezifikation
Darstellung von Anforderungen
Die Komposition fasst eine Menge von logisch zusammengehörigen Einzelkomponenten unter der
Weglassung von Details zu eine übergeordneten Komponente zusammen (kapselnde Komposition).
Die Benutzung erlaubt die Bildung von Schichten, deren Komponenten sich ihrerseits auf Leistungen
tieferer Schichten abstützen und andererseits Leistungen für höhere Schichten anbieten.
Benutzungsabstraktion - Komplexe
Gebilde durch Delegieren von
Aufgaben und Anordnung der
Aufgaben in schichten übersichtlich
und anschaulich modellieren.
Die Generalisierung fasst Gemeinsamkeiten einer Menge ähnlicher Komponenten zu einer
übergeordneten Komponenten zusammen. Dies hilft z.B. bei der Strukturierung der Begriffswelt und
erlaubt die Modellierung aufgabengerechter Modelle
Seite 37
Software Enigneering
6.6 Ausgewählte Spezifikationsmethoden
6.6.1 Spezifikation mit natürlicher Sprache
Anforderungsspezifikation
Ausgewählte Spezifikationsmethoden
Es gibt keine speziellen Methoden für die Spezifikationen mit natürlicher Sprache. In der Regel sind die
Anforderungen numeriert. Ferner werden häufig feste Gliederungsschemata verwendet.
6.6.2 Algebraische Spezifikation
Algebraische Spezifikation ist eine deskriptive, formale Spezifikationsmethode. Sie wird vor allem für
formale Spezifikationen komplexer Datentypen verwendet. Die Grundidee dabei ist, die Wirkung der
Operatoren auf den Objekten eines Typs durch die Angabe von Axiomen festzulegen. Die Syntax des
zu spezifizierenden Datentyps wird durch die Angabe von Definitions- und Wertebereich festgelegt.
6.6.3 Datenflussorientierte Spezifikation: Strukturiere Analyse
Datenfluss (dataflow)
Aktivität (Prozess, activity, process)
Transportiert Datenpaktete, die von
Aktivitäten
oder
Endknoten
produziert oder konsumiert werden.
Arbeiten nur dann, wenn alle
benötigten
Eingabe-Datenflüsse
vorliegen.
Strukturiere Analyse ist eine teilformale, konstruktive Spezifikationsmethode. Die Anforderungen
werden durch eine Hierarchie von Datenflussdiagrammen modelliert. Ein Datenflussdiagramm besteht
aus Aktivitäten, Datenflüssen und Speichern. Zur Modellierung werden ausserdem Endknoten
verwendet.
Speicher (store, file)
System-
Der Inhalt von Speichern kann von
Aktivitäten gelesen oder geschrieben
werden.
der
Sind Aktivitäten
umgebung
in
Endknoten (terminator, terminal)
Beispiel einer Datenflussdiagramm-Hierarchie in strukturierter Analyse
Datenflussdiagramme sind Übersichtsmodelle.
Zur Präzisierung müssen die Namen aller
Datenflüsse und Speicher definiert werden.
Hierzu dient ein globales Datenlexikon. Ferner
muss die Funktionalität jeder nicht hierarchisch
zerlegten Aktivität beschrieben werden. Dies
geschieht mit der Mini-Spezifikation.
Seite 38
Software Enigneering
6.6.4 Verhaltensspezifikation mit Automaten
Anforderungsspezifikation
Ausgewählte Spezifikationsmethoden
Verhaltensspezifikationen mit Automaten sind teilformale, konstruktive Modelle. Die Anforderungen
werden als eine Menge von Zuständen, Zustandsübergänge, auslösenden Ereignissen und
ausgelösten Aktionen beschrieben.
6.6.5 Objektorientierte Spezifikation
Objektorientierte Spezifikationsverfahren sind konstruktive, teilformale Methoden. Es gibt verschiedene
Ansätze: Booch, Coad und Yourdon, Jacobson et al., Rumbaugh et al., Wirfs-Brock.
Die Grundidee ist es, ein System durch eine Menge von Objekten zu spezifizieren, von denen jedes
einen in sich geschlossenen Teil der Daten, der Funktionalität und des Verhaltens des Systems
beschreibt. Dabei wird ein Ausschnitt der Realität auf Objekte (bzw. auf Klassen gleichartiger Objekte)
und deren Attribute abgebildet. Jedes Objekt / jede Klasse von Objekten kapselt logisch
zusammengehörige Daten, Operationen und Verhaltensweisen. Gleichartige Objekte werden durch
Klassen modelliert.
Objekt (object): Ein individuell erkennbares, von anderen Objekten eindeutig unterscheidbares
Element der Realität (Bsp. Hans Muster, Mustergasse 10, 1234 Musterhausen)
Klasse (class): eine eindeutig benannte Einheit, welche eine Menge gleichartiger Objekte beschreibt
(Mitarbeiter mit den Attributen Name, Adresse, PLZ und Ort).
Klassen stehen wie folgt in Beziehung zueinander:
• Assoziation: Die Objekte einer Klasse sind Merkmale von Objekten einer anderen Klasse (gilt meist
bidirektional.
• Benutzung: Die Objekte einer Klasse benutzen Attribute und Operationen einer anderen Klasse zur
Bereitstellung ihrer eigenen Attribute und Operationen.
• Vererbung: Eine Unterklasse einer anderen Klasse erbt von dieser alle Attribute und Operationen,
ohne dass diese lokal definiert werden müssen.
• Kardinalitäten: Sie müssen zu den Assoziationen definiert werden. Dabei geht es darum
festzulegen wie viele Objekte der assozierten Klassen mindestens müssen / höchstens dürfen mit
einem Objekt der eigenen Klasse assoziiert sein.
Es gibt heute eine Vielzahl verschiedener Notationen für Klassenmodelle. Die meisten Notationen
verwenden Rechtecke für Klassen und Linien für Assoziationen. Die Klassensymbole werden häufig
durch zwei Linien unterteilt: oben steht der Klassenname, in der Mitte die wichtigsten Attribute, unten
die wichtigsten Operationen. Die Notation für Benutzung und Vererbung ist sehr uneinheitlich. Hier
werden verwendet: Pfeile für Benutzung, gegabelte Linien für Vererbung. Für die Notation von
Kardinalitäten gibt es eine verwirrende Fülle von graphischen und numerischen Notationssystemen.
Hier wird die Kardinalität mit der Benennung der Beziehungsrichtung verknüpft.
Seite 39
Software Enigneering
Anforderungsspezifikation
Ausgewählte Spezifikationsmethoden
Als Alternative oder als Ergänzung zu Klassenmodellen könne Objektmodelle verwendet werden. In
solchen Modellen werden keine konkreten Objekte (d.h. solche mit bekannter Identität und bekannten
Attributwerten) modelliert, sondern abstrakte Objekte, die als Muster bzw. als Repräsentanten für
konkrete Objekte stehen. Objektmodelle sind dann von Vorteil, wenn verschiedene Objekte der
gleichen Klasse modelliert werden müssen.
6.6.6 Prototypingorientierte Systemspezifikation
Die Ermittlung, die Beschreibung und die Evaluation der Anforderungen bilden das Rückgrat des
Systemspezifikationsprozesses. Alle Aufgaben werden durch die Verwendung eines Prototypen
erleichtert.
Diese Vorgehensweise hilft bei der Vermeidung vieler Probleme beim Spezifikationsprozesses,
Verbesserung und leichtere Verständlichkeit der Systemspezifikation unter Verminderung des
schriftlichen Teils und stärkerer Berücksichtigung der ergonomischen Aspekte.
Seite 40
Software Enigneering
Anforderungsspezifikation
Prüfung der Anforderungen
Des weiteren liefert der Prototyp wertvolle Hinweise für die spätere Realisierung und senkt den
Testaufwand. Auch die Wartungskosten können verringert werden, da die Wartungs- und
Nachbesserungsaufwände geringer ausfallen.
6.7 Prüfung der Anforderungen
Beim Prüfen einer Anforderungsspezifikation geht es darum, Abweichungen von der geforderten
Qualität (Fehler, Lücken, Unklarheiten, Mehrdeutigkeiten) der Spezifikation festzustellen. In erste Linie
sollte auf Adäquatheit, Vollständigkeit, Widerspruchsfreiheit und Verständlichkeit geprüft werden (auch
Validierung genannt), in zweiter Priorität auf Prüfbarkeit und Eindeutigkeit.
Die Prüfung erfolgt sinnvollerweise unter Federführung von Informatikern. Die Einbindung von
Kundenvertretern in diesen Prozess ist aber zwingend.
Die abschliessende Prüfung erfolgt zum Zeitpunkt, wo die Spezifikation fertig ist, aber noch genügend
Zeit bleibt, die Mängel zu beheben. Bei grösseren Spezifikationen könne auch Zwischenprüfungen
durchgeführt werden.
Für die Prüfung können folgende Verfahren in Betracht gezogen werden:
• Review: Formell organisierte Zusammenkunft von Personen zur inhaltlichen oder formellen Prüfung
eines Produktteils nach vorgegebenen Prüfkriterien.
• Prüf- und Analysemittel in Werkzeugen: Diese Werkzeuge werden dann eingesetzt, wenn eine
Spezifikation mit Werkzeugen erstellt wurde.
• Simulation: Kann die Adäquatheit des Verhaltens des spezifizierten Systems in bestimmten
Situationen untersuchen
• Prototyp: Lauffähiges Stück Software, welches Teile eines zu entwickelnden Systems vorab
realisiert und als Modell für die weitere Entwicklung dient.
Seite 41
Software Enigneering
7 Konzipieren von Lösungen
Konzipieren von Lösungen
Hauptaufgaben in der Konzipierung
Das Konzipieren einer Lösung ist die Erstellung einer Dokumentation des Grob- oder
Architekturentwurfs eines Systems. Dabei werden die wesentlichen Komponenten der Lösung und die
Interaktion zwischen den Komponenten festgelegt. Das Konzept, welches die Lösung dokumentiert
wird Systemarchitektur (Architectural Design), Lösungskonzept oder auch Systemkonzept genannt
Ein sauberes Konzept ist eine Voraussetzung für die zeitliche und personelle Aufteilung einer
Entwicklung und legt den Grundstein für ein leicht pflegbares System. In der Konzipierung begangene
Fehler sind manchmal gar nicht oder nur mit sehr grossem Aufwand reparierbar.
7.1 Hauptaufgaben in der Konzipierung
Ausgehend von der Systemspezifikation wird in der iterativen Entwurfsphase die Systemarchitektur mit
dem Ziel entworfen, den festgelegten Funktionsumfang verfügbar zu machen und zu gewährleisten,
dass sich ändernde Anforderungen leicht angepasst werden können. Dieser Prozess umfasst folgende
Tätigkeiten:
Modularisierung: Gliederung der Gesamtlösung in kleinere, überschaubare Teillösungen.
Nebenläufigkeit: Enthält die Lösung Nebenläufigkeit (Parallelität), so muss festgelegt werden welche
Prozesse parallel laufen, welche Module welchem Prozess zugeordnet werden, wie die Prozesse
miteinander kommunizieren und wie die Prozesse gesteuert werden (Start, Prioritäten, Unterbrechung,
Terminierung).
Ressourcenzuteilung: Es muss entschieden werden welche Komponenten mit Software, Hardware
oder manuell realisiert werden, die Zuteilung von Prozessen zu Prozessoren und von Daten zu
Speichern muss vorgenommen werden und die zu verwendenden Betriebsarten und Prioritäten (z.B.
Dialogbetrieb/Stapelbetrieb) müssen definiert werden.
Spezielle Teilkonzepte: Oft macht die Erarbeitung eines aspektbezogenen Gesamtkonzeptes für
Teilaspekte der Lösung Sinn: Datenstrukturen, Datenschutz und- sicherung, Benutzerschnittstelle,
Fehlerbehandlung und Fehlertoleranz.
7.2 Lösungsvarianten
Überall, wo sich mehrere Lösungsvarianten ergeben, werden die möglichen Varianten soweit verfolgt,
bis ein sinnvoller Entscheid für die beste Variante möglich ist. Die Kosteneinsparungen müssen dabei
in einem Verhältnis zum getätigten Aufwand stehen.
7.3 Modularisierung
Eine gute Modularisierung ist entscheidend für die Qualität eines Lösungskonzeptes. Fehler bei der
Modularisierung können vermieden werden, wenn ein paar Punkte beachtet werden. Goos und Dennis
geben folgende Moduldefinition an:
• Jedes Modul ist eine in sich geschlossene Einheit
• Ein Modul ist eine Zusammenfassung von Operationen (Prozeduren) und Daten (Variabeln) zur
Realisierung einer abgeschlossenen Aufgabe
• Zur Integration eines Moduls darf keine Kenntnis über die inneren Aufbau notwendig sein
• Die Kommunikation eines Moduls zur Aussenwelt darf nur über eine eindeutig spezifizierte
Schnittstelle (Import- und Exportschnittstelle) erfolgen
• Änderungen im Innern eines Moduls, welche die Schnittstelle unverändert lassen, haben keine
Rückwirkungen auf das übrige System
• Die Korrektheit eines Moduls muss ohne Kenntnis seiner Einbettung in eine Programmsystem
nachprüfbar sein
Damit bewirkt Modularisierung eine Abstraktion und unterstützt bei der Bewältigung der Komplexität
eines Systems:
Seite 42
Software Enigneering
Konzipieren von Lösungen
Modularisierung
• Ein Modul ist im Detail verstehbar, ohne die Details des gesamten Systems zu kennen
• Das Gesamtsystem ist im Überblick verstehbar durch grobe Kenntnis der Wirkung der Module und
ihrer Schnittstellen
Es gibt verschiedene Möglichkeiten die Modularisierung vorzunehmen. Die nachfolgenden Kriterien
sollten berücksichtigt werden:
• Kohäsion (Modulgeschlossenheit, d.h. für eine abgeschlossene Aufgabe zuständig) und
Modulbindung (Summe der Beziehungen, die zwischen den einzelnen Operationen des Moduls
bestehen): Je nach Art des Moduls ist es ein funktional zusammenhängendes Modul oder ein
datenorientiert zusammenhängendes Modul
• Modulkopplung (Ausdruck, wie stark verschiedene Module untereinander verbunden sind):
Modulkopplung und Modulbindung hängen zusammen
• Minimalität der Schnittstelle (möglichst wenige globale Daten, möglichst wenige exportierte
Prozeduren und eine möglichst geringe Anzahl von Parametern): Je kleiner die Schnittstelle eines
Moduls ist, desto geringer ist die Gefahr einer hohen Modulkopplung
• Modulgrösse (keine allgemeingültige Aussage möglich): Von untergeordneter Bedeutung
• Testbarkeit: Korrektheit kann ohne Kenntnis der Einbettung in das Gesamtsystem überprüft
werden, d.h. eine hohe Modulkopplung und eine grosse Schnittstelle wirken sich negativ auf die
Testbarkeit aus.
• Interferenzfreiheit bedeutet, dass das Modul keine unerwünschten Nebenwirkungen auf andere
Module hat und somit durch eine anderes Modul mit der gleichen Schnittstellenbeschreibung
ersetzt werden kann.
• Importzahl gibt an, wie viele weitere Module für seine Implementierung benutzt werden. Eine hohe
Importzahl deutet darauf hin, dass eine hohe Modulkopplung und ev. Interferenzen bestehen
während eine niedrige Importzahl vor allem bei grossen (umfassenden) Modulen auftritt.
• Verwendungszahl gibt an, in wie vielen weiteren Modulen das entsprechende Modul genutzt wird.
Eine hoher Wert spricht für Allgemeinheit und hohe Wiederverwendbarkeit
• Modulhierarchie enthält typischerweise vier Hierarchien, die klar erkennbar sein sollten:
- Steuermodul (kurz, nur Aufruf einer Prozeduren der zweiten Ebene)
- Problemorientierte Module (eigentliche Bearbeitung der Teilprobleme)
- Hilfsmodule (Implementierung von Datenstrukturen, Verwaltung von Listen etc.)
- Kommunikation mit der Hardware und dem Betriebssystem
Ein Fehler, der häufig gemacht wird besteht darin, dass von Beginn weg Eigenschaften der
verwendeten Programmiersprache, des Betriebssystems oder sogar der Hardware in die
Modularisierung einfliessen. Als Probleme resultieren eine starke Modulkopplung was sich auf die
Fehlersuche und die Wartung auswirkt und eine verminderte Portierbarkeit.
Beim objektorientierten Entwurf besteht die Schwierigkeit darin, die richtigen Klassen zur Lösung einer
Aufgabe zu finden. Die Modularisierung stellt dann kein Problem mehr dar.
Seite 43
Software Enigneering
7.4 Techniken der Konzipierung
Konzipieren von Lösungen
Techniken der Konzipierung
Eine Methode zur Meisterung von Komplexität ist die Abstraktion. In diesem Zusammenhang gibt es
zwei Verfahren: Topdown- und Bottomup-Methode.
Die Grundidee des Topdown-Verfahrens (Dijkstra und Wirth) postuliert, dass die Entwurfstätigkeit mit
der Analyse der Systemspezifikation beginnen soll und Realisierungsdetails vernachlässigt werden.
Davon ausgehend werden die Aufgaben solange in Teilaufgaben zerlegt, bis die Teilaufgabe so
einfach ist, dass man einen Algorithmus für die Lösung formulieren kann. So wird das System
sukzessive konkretisiert.
Beim Bottomup-Verfahren wird umgekehrt vorgegangen. Ausgehend von einer “konkreten Maschine”
entwirft man durch sukzessives hinzufügen der benötigten Eigenschaften eine “abstrakte Maschine”
nach der anderen bis man bei der, für die Bereitstellung der gewünschten Funktionen des Benutzers
notwendigen Maschine angelangt ist.
Es lässt sich aber nicht nur die Vorgehensweise beim Entwurf, sondern auch die Kriterien, nach denen
ein System zerlegt wird, unterscheiden:
Funktionsorientierte Zerlegung: Im Mittelpunkt steht eine funktionsorienterte Systemsicht. Die
aufgabenorientierte Zerlegung erfolgt auf der Basis der funktionalen Anforderungen der
Systemspezifikation (Methoden: Wirth und Yourdon).
Datenorientierte Zerlegung: Im Mittelpunkt steht eine datenorientierte Systemsicht. Das System
sollte die Struktur der Daten wiederspiegeln und so wird die Zerlegung des Systems anhand der zu
verarbeitenden Daten abgeleitet.
Objektorientierte Zerlegung: Im Zentrum des Entwurfs steht eine objektorientierte Systemsicht. Das
System wird als eine Sammlung von kommunizierenden Objekten (unbekannte innere Struktur, darauf
ausführbare Operationen) betrachtet. Die Zerlegung orientiert sich an der Zusammengehörigkeit von
Daten und Operationen und gründet sich auf dem “principle of information hiding (Parnas) und dem
Prinzip der Vererbung (Dahl).
7.4.1 Funktionsorientierter Entwurf
Die meisten bekannten Entwurfsverfahren sind funktionsorientiert, das heisst, der Algorithmus zur
Problemlösung steht im Mittelpunkt des Interesses.
Das Prinzip der Schrittweisen Verfeinerung (Von der Black Box zu einem Netzwerk von
Teilalgorithmen) basiert auf zwei einfachen Regeln: 1. Zerlege die Aufgabe in Teilaufgaben 2.
Betrachte jede Teilaufgabe für sich und zerlege sie wieder in Teilaufgaben. Die Lösung einer Aufgabe
ist bei dieser Vorgehensweise folgendermassen charakterisiert:
• Bei jeder (Teil-)Aufgabe werden die wesentlichen Bestandteile identifiziert. Dabei muss man sich
Klarheit verschaffen, wie die Lösungen dieser Teilaufgaben zur Gesamtlösung zusammengefügt
werden können.
• Einzelheiten sollten zum spätesten möglichen Zeitpunkt behandelt werden, d.h. es geht nicht um
die Lösung dieser Teilaufgaben, sondern um den Zusammenhang.
• Die Schrittweise Verfeinerung ist durch eine ständige Komplexitätsminderung während des
Entwurfsprozesses gekennzeichnet (“Unlösbare” Probleme werden durch die Aufteilung in
Teilprobleme plötzlich trivial).
• Die Teilaufgaben werden zunehmend konkreter und erfordern zu ihrer Lösung immer detaillierte
Informationen. Das bedeutet, dass nicht nur die Algorithmen sondern auch die Daten zunehmend
verfeinert werden (Konkretisierung der Schnittstellen).
Seite 44
Software Enigneering
Konzipieren von Lösungen
Techniken der Konzipierung
• Während der Verfeinerung muss immer wieder geprüft werden, ob die Zerlegung weiter verfeinert
werden kann oder verworfen werden muss.
Das Problem dieser Methode ist es, dass die wichtigsten Zerlegungsentscheidungen zu Beginn
getroffen werden müssen, wenn man noch wenig weiss. Dadurch ist es oft notwendig Schritte
zurückzugehen und gewisse Teile neu zu zerlegen. Es stellt sich auch die Frage, nach welcher
Vorgehensweise die Verfeinerung vorgenommen wird. Hier bieten sich vier Varianten an:
• Verfeinerung in sequentieller Reihenfolge: Dieses Vorgehen macht Sinn, wenn eine Teilaufgabe in
nacheinander auszuführende Aufgaben zerfällt.
• Verfeinerung in Reihenfolge des Datenflusses: In vielen Fällen kann erst durch Analyse der
Eingabedaten festgestellt werden, welche Aktionen möglich sind.
• Rückschluss von den gewünschten Ausgabedaten: Vor allem in kaufmännischen Anwendungen
sind die gesuchten Ergebnisse bekannt.
• Hardest-First-Methode: Um möglichst früh möglichst viele Detailinformationen zu erhalten, kann es
von Vorteil sein, mit der komplexesten Aufgabe zu beginnen um grobe Fehler zu vermeiden.
7.4.2 Datenorientierter Entwurf
Die schrittweise Verfeinerung ist eine algorithmisch orientierte Vorgehensweise, die Daten treten in
den Hintergrund. Beim Entwurf mit Datenabstraktion nach dem Geheimnisprinzip ist die Grundidee,
dass jedes Modul aus einer vollständigen Realisierung einer Gruppe zusammengehöriger
Entwurfsentscheidungen besteht, wobei den Verwendern des Moduls nur bekannt ist, um welche
Entwurfsentscheidungen es sich handelt, aber nicht wie diese implementiert sind (information hiding).
Oft vernachlässigt werden attributierte Grammatiken zur statischen Beschreibung von Attributabhängigkeiten. In der Praxis findet man viele Aufgabenstellungen, wo ein Strom strukturierter
Eingabedaten verarbeitet werden muss. Solche Aufgaben können elegant mit Hilfe von attributierten
Grammatiken spezifiziert, entworfen und dokumentiert werden.
7.4.3 Objektorientierter Entwurf
Beim funktionsorientierten Entwurf geht man von den auszuführenden Aktionen aus. Während die
Gesamtaufgabe schrittweise in Teilaufgaben zerlegt wird, sollten dabei im Idealfall auch die zu
verarbeitenden Daten schrittweise verfeinert werden. Die Aktionen stehen dabei im Mittelpunkt.
Beim objektorientierten Entwurf stehen die Daten im Zentrum. Dabei werden die Algorithmen vorerst
vernachlässigt und nur die Beziehungen betrachtet. In der Literatur finden sich verschiedene Ansätze
für die objektorientierte Analyse und den objektorientierten Entwurf (z.B. Entity-Relation-Model oder
semantische Netze). Es konnte sich jedoch noch keine Methode durchsetzen.
7.4.3.1 Die Methode von Abbot
Beim objektorientierten Entwurf versucht man, möglichst schnell die an der Aufgabe beteiligten
Objekte zu identifizieren (Daten, Formulare, Geräte, Organisationsmittel etc.). Gemäss Abbott ist nach
folgendem Schema vorzugehen:
• Herausfiltern der Hauptwörter:
Gattungsnamen (Mensch, Auto) spielen ein zentrale Rolle
• Eigennamen (Paris) dienen als Bezeichner für bestimmte Objekte. Sie können indirekt zu
Klassenbildungen führen.
Mengen und Grössenangaben, Materialbezeichnungen (Holz) und Sammelnamen (Regierung)
eigenen sich meist nicht zur Bildung von Klassen
Das gleiche gilt für abstrakte Begriffe (Arbeit, Neid)
Hauptwörtlich gebrauchte Zeitwörter deuten auf Aktionen hin
• Suchen von Gemeinsamkeiten
Abklären, ob ähnliche Begriffe zusammengefasst werden können oder nicht (Typ Fahrzeug spielt
bei einer Ampelsimulation keine Rolle, bei einer Applikation des Strassenverkehrsamtes aber
schon).
Seite 45
Software Enigneering
Konzipieren von Lösungen
Techniken der Konzipierung
• Auffinden der relevanten Zeitwörter
Die Zeitwörter kennzeichnen Aktionen mit Objekten. Im Gegensatz zum funktionsorientierten
Vorgehen werden diese Aktionen nicht isoliert, sondern immer in Verbindung mit Objekten
bestimmter Klassen betrachtet.
Bei dieser Methode können mehrere Probleme auftreten: Art und Umfang der Spezifikation haben
starken Einfluss auf das Resultat. Wenn in der Spezifikationsphase Prototyping benutzt wurde, liegt
nur ein Teil der Anforderungsdefinition in einer verbalen Beschreibung vor.
Beim Entwurf eines Simulationsprogrammes für eine Ampelsteuerung können zum Beispiel folgende
Klassen entstehen:
1. Direkt aus der Spezifikation: Ampel, Auto, Strasse, Kreuzung, zeit, Statistik
2. Beim Entwurf der Klassen: Fahrspur, Richtung, Farbe, Histogramm
3. Beim algorithmischen Entwurf der Operationen: Ereignis, Generator, Warteschlange, Liste, Menge
Die Anfangs gewonnen Klassen haben noch direkt wenig mit der Problemwelt zu tun, während die
letzten Klassen nur für die Implementierung von Bedeutung sind. Durch ein Top-Down-Verfahren nach
Abbott kann daher die Abstraktionslücke (semantische Lücke), die oft zwischen der Denkwelt des
Auftraggebers und des Implementierers klafft, geschlossen werden.
7.4.3.2 Bildung von Klassenhierarchien
Ein besonderes Kennzeichen der objektorientierten Programmierung ist es, dass die Klassen
hierarchisch gegliedert werden, d.h. dass ähnliche Dinge unter einem gemeinsamen Oberbegriff
zusammengefasst werden. Dadurch entsteht eine Baumstruktur, bei der die allgemeinen, abstrakten
Begriffe nahe der Wurzel stehen und die Blätter die spezialisierten, konkreten Begriffe darstellen.
Die Klasse KFZ bestimmt die allgemeinen Eigenschaften der von ihr abhängenden Klassen. Bei jedem
Spezialisierungsschritt kommen zu den allgemeinen Eigenschaften weitere hinzu und auch die
Funktionalität wird erweitert.
Für die Bildung von Klassenhierarchien müssen zwei zentrale Eigenschaften berücksichtigt werden:
1. Vererbung: Eigenschaften und Funktionen, die für eine allgemeine Klasse definiert wurden, gelten
automatisch auch für die von ihr abhängenden, speziellen Klassen
2. Polymorphismus: Ein Programmstück, dass für Objekte einer Klasse K funktioniert, kann auch mit
Objekten einer von K abgeleiteten Klasse arbeiten. Dies ist möglich, weil in abgeleiteten Klassen
nur neue Eigenschaften hinzukommen aber nie welche entfernt werden können.
Oft kommen in einer Spezifikation Begriffe vor, die einander in vielerlei Hinsicht ähneln, sich aber in
einigen Details signifikant unterscheiden (z.B. Rechtecke und Kreise). In diesem Falle macht es Sinn,
die gemeinsamen Eigenschaften (Strichdicke, Füllmuster, Bewegen) in einer abstrakten Klasse Grafik
zusammenzufassen.
Seite 46
Software Enigneering
7.5 Architekturmetaphern
Konzipieren von Lösungen
Architekturmetaphern
Eine Metapher ist ein sprachlicher Ausdruck, bei dem ein Wort aus seinem Bedeutungszussamenhang in einen anderen übertragen, als Bild verwendet wird.
Virtuelle Maschinen: Diese Metapher charakterisiert Systeme, die aus aufeinander aufbauenden
Schichten realer oder künstlicher Maschinen bestehen. Jede Schicht besteht aus einer oder mehreren
virtuellen Maschinen. Je dieser Maschinen erbringt Leistungen für die darüberliegende Schicht. Die
unterste Schicht besteht aus eine realen Maschine. Die oberste Schicht erbringt die Leistungen, die für
den Anwender zugänglich sind.
Die Lagerhausmetapher charakterisiert Systeme, welche aus einem Lagerhaus (warehouse,
repository) bestehen, in dem Informationen gelagert sind, Agenten, welche Informationen einlagern,
ordnen und bearbeiten und aus Konsumenten, welche die Informationen aus dem Lagerhaus abrufen.
Viele technische Systeme sind nach dem Steckersystem aufgebaut, so dass sie durch Einstecken
neuer Elemente erweitert und ausgebaut werden können. Eine nach dem Steckersystem aufgebaute
Software besteht typisch aus einem Rahmen und einer Menge von Anwendungen. Der Rahmen stellt
Datenverwaltungsdienste, Kommunikationsdienste und eine Benutzerschnittstelle bereit und enthält
Steckplätze für die Anwendungen.
7.6 Beschaffung und Wiederverwendung
Wo immer möglich, werden Systeme nicht vollständig neu entwickelt, sondern es werden Teile oder
das ganze System beschafft bzw. wiederverwendet. In der Konzipierung müssen die wesentlichen
Beschaffungs- und Wiederverwendungentscheidungen getroffen werden:
• Kann eine Lösung vollständig beschafft werden (Standardsoftware)?
• Können abgeschlossene Teilsysteme (z.B. DB) beschafft werden?
• Ist das System durch Einbettung in bestehende Softwarerahmen (Framework) realisierbar?
• Können einzelne Komponenten (aus Programm- oder Klassenbibliotheken) genutzt werden?
• Können Architektur oder Entwurfsideen wiederverwendet werden?
• Kann das Lösungskonzept so modifiziert werden, dass vorhandene Software wiederverwendet bzw.
beschafft werden kann?
Bei jeder Beschaffungs- bzw. Wiederverwendungsüberlegung muss berücksichtigt werden:
• Zeit- und Kostenrahmen für Suche
• Aufwand für Parametrisierung, Konfiguration, Anpassungen und Ergänzungen
7.6.1 Beschaffung vollständige Lösung
Soll eine Lösung vollständig beschafft werden, so gibt es hierzu drei Möglichkeiten:
1. System, welches durch Konfiguration und Parametrisierung angepasst werden kann
2. Beschaffung von Teilen aus einem Baukasten
3. Beschaffung einer Standardlösung, wobei in den meisten Fällen Anpassung der Problemstellung
notwendig ist.
Schritt 1:
Schritt 0:
Marktübersicht verschafften, Grobauswahl treffen
Am Schluss sollten maximal noch 3-5 Kunden übrig bleiben
Hauptkriterien definieren
Weniger als 10 Kriterien die kritisch und unverzichtbar sind (3-5 funktionale
Anforderungen, 2 Leistungsanforderungen, Maximalpreis und Plattform)
Anforderungen ermitteln
7.6.2 Der Beschaffungsprozess:
Schritt 2:
Seite 47
Kandidaten Systeme evaluieren
Unterlagen beschaffen, ev. Demos, Aussagen zu den kritischen Punkten,
bei grösseren Produkten ist eine formale Evaluation und eventuell eine
Probeinstallation sinnvoll (Auflistung aller Anforderungen und Gewichtung)
Zusätzlich können noch weitere Punkte beurteilt werden wie Vertrauenswürdigkeit
Händler, Service, Erfahrungen mit anderen Produkten des gleichen Händlers, eigene
Beschaffungspolitik
Konzipieren von Lösungen
Beschaffung und Wiederverwendung
Schritt 3:
Entscheidung fällen und dokumentieren
Gründe für Entscheid festhalten, damit Entscheidung später nachvollziehbar bleibt
Software Enigneering
Schritt 4:
Seite 48
Software Enigneering
8 Realisierung
8.1 Einleitung
Realisierung
Einleitung
Unter dem Begriff Implementierung eines Programmsystems verstehen wir die Transformation der
Entwurfsergebnisse in Programme, die auf einem bestimmten Zielrechner ausführbar sind. Eine gute
Implementierung ist dadurch gekennzeichnet, dass sich in ihr die Entwurfsentscheidungen
widerspiegeln. Insbesondere soll gewährleistet sein,
• dass die beim Entwurf gewählten und festgelegten Zerlegungsstrukturen, Datenstrukturen und
Bezeichner sich in der Implementierung leicht erkennbar wiederfinden,
• dass die Abstraktionsebenen des Entwurfs (die Klassen, Module, Algorithmen, Datenstrukturell und
Datentypen) auch in der Implementierung realisierbar sind,
• dass die Schnittstellen zwischen den Teilen eines Programmsystems in der Implementierung
explizit beschrieben sind,
Software Enigneering
Realisierung
Möglichkeiten der Realisierung
Die wichtigsten Elemente guten Programmierstils sind Strukturiertheit, Ausdruckskraft, äussere Form
und Effizienz.
Die Strukturiertheit bezieht sich auf die Zerlegung eines Programmsystems mit dem Ziel, die
Komplexität durch Abstraktion zu meistern. Für das Verständinis und Ausprüfen von Algorithmen ist es
notwendig dass die Algorithmen einfach zu lesen sind (ohne Sprunganweisungen). Um GOTOs zu
vermeiden, sollten nur die folgenden Bausteine verwendet werden:
Eine hohe Ausdruckskraft kann erreicht werden, wenn der Benennung von Objekten und der
Beschreibung von Aktionen besondere Bedeutung zugemessen wird. Dabei sollten ein paar Regeln
berücksichtigt werden:
• dass die Konsistenz von Objekten und Operationen bereits durch den Compiler (vor dem
eigentlichen Test) geprüft werden kann.
Der Grad der Erfüllung dieser Eigenschaften hängt von der Wahl der Implementierungssprache und
vom Programmierstil ab.
• Aussagekräftige Namen wählen
• Nur gebräuchliche Abkürzungen verwenden
8.1.1 Wahl Implementierungssprache
• Variablennamen nur in einer Sprache vergeben
• Hauptwärter für Werte, Zeitwörter für Tätigkeiten und Eigenschaftswörter für Bedingungen
• Gross-Kleinschreibung gezielt einsetzen
Trotz allem gibt es keine beste Programmiersprache. Die unterschiedlichen Sprachen können aber
nach diversen Kriterien bewertet werden:
• Aufstellen von eigenen Regeln und sich daran halten.
Die Frage, welche Programmiersprache die richtige sei, ist seit jeher ein beliebtes Gesprächsthema.
Tatsächlich spielt die Entscheidung in welcher Programmiersprache ein Projekt realisiert wird, eine
wichtige Rolle, denn diese Wahl hat einen starken Einfluss auf den Entwurf.
• Modularität (in welchem Mass wird Modularisierung unterstützt)
Nicht nur der Bezeichnung von Objekten und Aktionen sollte besondere Bedeutung geschenkt werden
sondern auch Kommentare dürfen nicht fehlen:
• Bedeutung von Variablen sollte erklärt werden
• Jede Prozedur bzw. Methode sollte mit einem Kommentar versehen werden, der die Aufgabe
beschreibt.
• Jede Komponenten (jedes Modul und jede Klasse) sollte mit einer ausführlichen Beschreibung
beginnen (Was leistet die Komponente, in welchem Zusammenhang wird sie verwendet, welche
Verfahren werden benutzt, wer ist der Verfasser, wann wurde sie erstellt, vorgenommene
Änderungen)
• Dokumenationswert (Lesbarkeit und Wartbarkeit von Programmen)
• Datenstrukturen (Verfügbarkeit von unterschiedlichen und komplexen Datenstrukturen)
• Ablaufsteuerung (Art der Strukturierung)
• Effizienz (wird oft überschätzt)
• Portabilität
• Sicherheit (zum grössten Teil durch Lesbarkeit und Mechanismen zur Typenprüfung gegeben)
• Dialogtauglichkeit (für interaktive Programme)
• u.w.m.
Seite 50
In allen Fällen müssen die realisierten Einzelkomponenten zu einem System integriert werden, und
müssen die Komponenten wie auch das System geprüft werden, um mögliche Fehler zu finden und sie
anschliessend zu beheben. Sowohl beim Entwerfen wie beim Codieren werden wo möglich
vorhandene Komponenten und vorhandene Ideen (zum Beispiel Entwurfsmuster) genutzt.
• durch Konfigurieren vorhandener Komponenten.
• durch Entwerfen und Generieren
• durch Entwerfen und Codieren
Ein Lösungskonzept (d.h. eine Systemarchitektur) lässt sich auf verschiedene Arten realisieren:
8.2 Möglichkeiten der Realisierung
• spezielle Sprachelemente
Neben den Spracheigenschaften spielen auch pragmatische Erwägungen eine Rolle:
• Qualität des Compilers
• Verfügbarkeit von Bibliotheken
• Entwicklungswerkzeuge
• Firmenpolitik
• Externe Anforderungen
8.1.2 Programmierstil
Die Lesbarkeit eines Programmes hängt von der verwendeten Programmiersprache und vom
Progammierstil des Implementierers ab, Das Schreiben lesbarer Programme ist ein kreativer Prozess.
Seite 49
Software Enigneering
Realisierung
Systematisches Programmieren
Software Enigneering
9.1 Grundlagen
Qualitätsmanagement
Grundlagen
8.3 Systematisches Programmieren
Qualitätsmanagement im eigentlichen Sinn gibt es historisch erst seit der Massenproduktion, wo die
Qualität in der Produktion vor allem durch statistische Verfahren sichergestellt wird.
9 Qualitätsmanagement
Die Qualität der resultierenden Software wie auch der für die Prüfung erforderliche Aufwand lassen
sich durch systematisches Programmieren erheblich beeinflussen. Besonders wichtige Punkte sind
Im klassischen Detailentwurf werden die zu codierenden Algorithmen und Datenstrukturen festgelegt.
Dort, wo das Lösungskonzept noch zuwenig detailliert ist, werden die nötigen Details erarbeitet. In der
Codierung wird dieser Entwurf in einer Programmiersprache ausformuliert.
• Wahl von Algorithmen und Datenstrukturen und deren adäquate Programmierung
• Verwendung geschlossener Ablaufkonstrukte (solche mit einem Eingang und einem Ausgang)
Unter Qualitätsmanagement versteht man alle Tätigkeiten der Gesamtführungsaufgabe, welche die
Qualitätspolitik, Ziele und Verantwortlichkeiten festlegen sowie diese durch Mittel wie Qualitätsplanung,
Qualitätslenkung, Qualitätssicherung und Qualitätsverbesserung im Rahmen des Qualitätsmanagementsystems verwirklichen (ISO 8402).
Qualität ist folglich Zweckeignung. Sie ist keine absolute Grösse, sondern wird, da sie als Eignung für
einen bestimmten Zweck aufgefasst wird, an den gestellten Anforderungen gemessen.
Qualität ist die Gesamtheit von Merkmalen einer Einheit bezüglich ihrer Eignung, festgelegte und
vorausgesetzte Erfordernisse zu erfüllen (ISO 8402). Eine Einheit kann ein Produkt, eine
Dienstleistung, eine Tätigkeit, ein Prozess, ein System, eine Person, eine Organisation, etc. sein.
Qualitätsmanagement in der Entwicklung von Produkten ist nochmals wesentlich jünger, da
Massenphänomene (Probleme, die sich auch in der Entwicklung nur noch durch Arbeitsteilung und
Gruppenarbeit lösen lassen, zunehmende Anonymisierung, Entfremdung von Entwicklern und
Produkten) dort erst in den vergangenen 30-40 Jahren aufgetreten sind. SoftwareQualitätsmanagement ist der jüngste Spross, bei dem es speziell um die Qualität von industriell
entwickelter Software geht.
• Saubere Gliederung der Software in Prozeduren und Module
• Verwendung symbolischer Konstanten
• Verwendung selbstdokumentierender Namen für Prozeduren, Variablen, Konstanten und Typen
• Dokumentation aller Definitionen durch Kommentare
• bei Prozeduren: Voraussetzungen, die beim Aufruf erfüllt sein müssen, Ergebniszusicherungen
(Aussagen, die nach der Ausführung der Prozedur gelten), Bedeutung und
Kommunikationsrichtung der Parameter
• bei Variablen und Konstanten: Bedeutung der Variable / Konstante im Kontext des Programms
• Defensives Programmieren und vermeiden von Trickprogrammierung und Seiteneffekten
8.4 Prüfung und Integration
Hinweis: Bis vor wenigen Jahren wurde das gesamte Qualitätsmanagement als "Qualitätssicherung"
bezeichnet. Der Begriff "Qualitätssicherung" ist aber auf die Qualitätsmanagement-Darlegung, d.h. den
Nachweis der Qualitätsmassnahmen beschränkt worden.
Das Qualitätsmanagementsystem ist definiert als die Struktur, Verantwortlichkeiten und Mittel zur
Verwirklichung des Qualitätsmanagements (ISO 8402).
Software wird typischerweise komponentenweise realisiert. Jede Komponente wird nach ihrer
Fertigstellung zunächst für sich alleine geprüft. Die wichtigsten Verfahren sind:
• Prüfung auf syntaktische Richtigkeit durch Compiler
Software nimmt insofern eine Sonderstellung ein, als
Seite 52
Qualität ist nicht umsonst. Einrichtung und Unterhalt eines Qualitätsmanagementsystems kosten
erhebliche Summen (Terminlicher und kostenmässiger Einfluss auf Projekte). Das Ziel des
Qualitätsmanagementes ist es durch Verhinderung und frühzeitige Entdeckung von Fehlern Kosten zu
sparen.
Bezogen auf die Qualität heisst dies, dass die Qualität der Entwicklung gesichert werden muss, dass
auf keine Traditionen und keine Berufsethos zurückgegriffen werden kann und dass Qualitätsprüfung
von Software schwierig ist.
• Software aufgrund ihres immateriellen Charakters schwierig zu überprüfen ist.
• es praktische keine Traditionen für Softwareentwicklung gibt
• Software ein Produkt ist, bei dem nur die Entwicklung schwierig ist, die Produktion dagegen aus
blossem, völlig unproblematischem Kopieren besteht
• Prüfung auf inhaltliche Richtigkeit durch Inspektion
• Selbstinspektion
• Formale Inspektion durch dritte (siehe Kapitel 9, “ Qualitätsmanagement”))
• Komponententest (siehe Kapitel 9, “ Qualitätsmanagement”)
Die fertiggestellten und geprüften Komponenten müssen anschliessend zu einem System integriert
werden. Die Integration erfolgt schrittweise. Jede Integration ist mit einem zugehörigen Integrationstest
verbunden, der die Richtigkeit des Integrationsschritts sichert. Nach Abschluss der Integration wird das
fertiggestellte System einem gründlichen Systemtest unterworfen, dessen Ziel es ist, möglichst viele
Fehler zu finden, die erst beim Zusammenspiel zwischen den einzelnen Komponenten auftreten. Je
nach Vertragsverhältnis erfolgt eine formale Abnahme.
Seite 51
Qualitätsmanagement
Das Qualitätsmanagementsystem
Software Enigneering
Qualitätsmanagement
Qualitätsprüfung
9.3 Qualitätsprüfung
Software Enigneering
9.2 Das Qualitätsmanagementsystem
Die Qualitätsprüfung stellt fest, ob ein Arbeitsergebnis den Vorgaben entspricht. Letztlich ist zu prüfen,
ob ein fertiggestelltes Produkt die an das Produkt gestellten Anforderungen erfüllt. Mit der Prüfung darf
jedoch nicht bis zum Abschluss der Entwicklung gewartet werden, weil verfehlte Ziele dann
möglicherweise nicht mehr, oder nur mit sehr hohen Kosten doch noch erreichbar sind.
Verifikation ist die Prüfung, ob ein Arbeitsergebnis den für den betreffenden Arbeitsschritt gegebenen
Vorgaben genügt, d.h. ob das Produkt richtig entwickelt wird.
Validierung ist die Prüfung, ob ein Arbeitsergebnis geeignet ist, die Erwartungen der Endbenutzer zu
erfüllen, d.h. ob überhaupt das richtige Produkt entwickelt wird.
Qualitätsprüfung ist daher eine permanente, die Entwicklung begleitende Aufgabe. Man unterscheidet
zwei Arten der Überprüfung:
Das Qualitätswesen ist eine Sekundärorganisation innerhalb eines Unternehmens, in der die Fachleute
für Qualität zusammengefasst sind. An der Spitze steht der Qualitätsleiter, welcher unmittelbar an die
Geschäftsleitung berichtet.
Im Qualitätswesen ist das Fachwissen über Qualität, insbesondere Qualitätsmanagementsverfahren,
konzentriert. Die Qualitätsverantwortung muss jedoch vom gesamten Unternehmen getragen werden.
Im Qualitätsmanagement gelten folgende sechs Grundsätze:
1. Qualität - in der Entwicklung wie in der Produktion - muss erzeugt werden, sie kann nicht erprüft
werden.
2. Qualität bezieht sich immer sowohl auf die hergestellten Produkte wie auch auf die Prozesse zur
Herstellung (Entwicklung und Produktion) dieser Produkte.
3. Die Qualitätsverantwortung liegt immer bei den gleichen Leuten, welche auch die Sach-, Terminund Kostenverantwortung haben (Führungskräfte und Entwickler).
4. Das Qualitätswesen ist verantwortlich für die Ermittlung (Messung) der Qualität. Es erbringt
Dienstleistungen in allen Belangen der Qualität sowohl für die Entwickler wie für die
Führungsverantwortlichen.
5. Das Qualitätswesen muss einen unabhängigen Berichterstattungspfad haben, der bis zur
Geschäftsleitung geht.
6. Die Entwickler müssen über die Qualität ihrer Arbeit orientiert werden. Alle Vorgesetzten müssen
die Qualität der Arbeit ihrer Mitarbeiter in deren Beurteilung miteinbeziehen.
Die Qualitätsmanagementsverfahren kann man in drei Klassen gliedern:
Zur Qualitätsplanung im Allgemeinen gehört der Aufbau des Qualitätsmanagementsystems, die
Dokumentation im Qualitätshandbuch, die Ausprägung im Qualitätswesen und die Festlegung der zu
messenden Qualitätsmerkmale. Im Speziellen, die Festlegung der Ziele für ein Projekt oder ein
Produkt.
Vier Prüfverfahren sind von praktischer Bedeutung:
• Review
• Test
Qualitätslenkung findet im Allgemeinen durch Festlegung von Entwicklungsmethoden (Definition
Vorgehensweise), Sprachen (Normierung Ausdrucksweise) und Werkzeugen (Unterstützung des
Einsatzes von Methoden und Sprachen) statt. Im Speziellen sind alle Massnahmen, die in der Führung
eines Projektes ergriffen werden, um die Erreichung der gesetzten Ziele sicherzustellen, gemeint.
Qualitätsprüfung siehe Kapitel 9.3, “Qualitätsprüfung”
• Simulation
• Eine Inspektion ist ein Review, bei dem der Prüfling von den Gutachtern systematisch Punkt für
Punkt auf Stärken und Schwächen abgeklopft wird.
Ein Review ist eine formell organisierte Zusammenkunft von Personen zur inhaltlichen oder formellen
Überprüfung eines Produktteils (Dokument, Programmteil etc.) nach vorgegebenen Prüfkriterien und
-listen. Es lassen sich zwei Formen unterscheiden:
9.4 Reviewtechnik
• Prototyp
Das Qualitätsmanagementsystem wird wie folgt dokumentiert:
• Das Qualitätshandbuch enthält die Beschreibung des Qualitätsmanagementsystems eines
Unternehmens oder eines -bereiches.
Teil I (für Kunden): Qualitätsmanagementsorganisation und Überblick über QM-Verfahren
Teil II (intern): Unternehmensspezifisches QM-Verfahren (vertraulich)
• Der Software-Qualitätsplan enthält die Vorgaben bezüglich Qualität für die Entwicklung von
Produkten (i.d.R. ein allgemeiner Rahmenplan, der projektspezifisch ergänzt wird).
• Detaillierte Entwicklungsrichtlinien und Ausführungsbestimmungen, die den Rahmen des
Qualitätsplans sprengen würden, werden häufig in einem Software-Entwicklungshandbuch
zusammengefasst.
Sorgfältig durchgeführte Reviews verbessern die Qualität der erzeugten Software erheblich. Die
Fehlerraten können bis zu 60%, ja sogar 80-90% gesenkt werden. Des weiteren habe regelmässig
durchgeführte Reviews den Vorteil, dass ein ständiger Wissens- und Kenntnisstransfer von den
besseren zu den schlechteren Leuten resultiert. Die festgestellten Mängel lassen sich auch statistisch
auswerten. Die Resultate können für die Qualitätslenkung verwendet werden.
• Ein Walktrough ist ein Review, bei dem der Autor die Funktionsweise des Prüflings Schritt für
Schritt beschreibt, während die Gutachter aufmerksam zuhören und überall einhaken, wo sie
Mängel entdecken (Sinnvoll, wenn Urteil von Gutachtern gefragt ist, die das Produkt zu wenig gut
kennen, um eine Inspektion durchzuführen).
Ein interner Audit sollte etwa jährlich vom Qualitätswesen veranstaltet werden. Die jeweils höhere
Stelle auditiert die in der Hierachie tiefere.
Bei externen Audits wird die Überprüfung durch eine externe Organisation durchgeführt (z.B. für
Erlangung eines Zertifikates).
Seite 54
Qualitätssicherung: Die Darlegung des Qualitätsmanagementes, d.h. alle Tätigkeiten zur Schaffung
von Vertrauen, dass die Qualitätsanforderungen erfüllt werden, wird Qualitätssicherung genannt. Als
zentrale Massnahmen braucht es regelmässige Überprüfungen, ob das QM-System wie geplant
funktioniert und ob die vorgesehenen Qualitätsmassnahmen wirklich durchgeführt werden. Solche
Überprüfungen heissen Audits.
Seite 53
Software Enigneering
Qualitätsmanagement
Reviewtechnik
Effektivität und Erfolg eines Reviews hängen im wesentlichen von der richtigen Durchführung ab. Der
Ablauf sieht wie folgt aus:
1. Planung: Reviews müssen in die Entwicklung eingeplant werden (Termine, Zeitaufwand und
Kosten)
2. Vorbereitung: Alle Teilnehmer erhalten das zu prüfende Material sowie Referenzunterlagen im
voraus und bereiten sich individuell auf die Sitzung vor (Zusammentragen und nicht Suchen von
Stärken und Schwächen)
3. Sitzung: Ein Moderator übernimmt die Leitung
4. Reviewbericht: Während der Sitzung wird der Reviewbericht erstellt, welcher alle genannten
Stärken und Schwächen auflistet
Software Enigneering
9.5 Testen
Mit Tests werden zwei Ziele verfolgt:
Qualitätsmanagement
Testen
1. Im Test sollen möglichst viele der in einem Programm vorhandenen Fehler gefunden werden
(Testen ist der Prozess, ein Programm mit der Absicht auszuführen, Fehler zu finden (Myers 1997))
2. Aus der Tatsache, dass das Programm mit einer Menge von Testdaten fehlerfrei läuft, soll mit
brauchbarer statistischer Sicherheit darauf geschlossen werden, dass das Programm auch im
Einsatz fehlerfrei läuft.
Testen setzt voraus, dass die erwarteten Ergebnisse bekannt sind. Folglich muss entweder gegen eine
Spezifikation oder gegen vorhandene Testergebnisse getestet werden. Unvorbereitete und
undokumentierte Tests sind sinnlos.
Die Korrektheit eines Programmes kann durch testen (ausser in trivialen Fällen) nicht bewiesen
werden, denn dafür müsste ein Korrektheitsbeweis für alle Eingabekombinationen erbracht werden.
Die verschiedenen Beteiligten kommen unterschiedliche Aufgaben zu:
1. Testplanung: Festlegen der Teststrategie, Planung der notwendigen Arbeiten und Aufwände
5. Überarbeitung und Nachkontrolle: Der Projektverantwortliche entscheidet aufgrund des Berichtes
über die durchzuführenden Änderungen und gibt diese in Auftrag.
• Moderator: Verschickt die Einladungen, organisiert und leitet Sitzungen und sorgt für Fertigstellung
und Weiterleitung des Reviewberichtes.
Während der Sitzung geht es vor allem darum eine offene Atmosphäre zu schaffen, zurückhaltende
Personen zu Aussagen zu ermuntern, Dauerredner zu bremsen, persönliche Angriffe zu vermeiden
bzw. beizulegen, Abgleiten zu verhindern, den Konsens herzustellen und über die Einhaltung der
Regeln zu wachen.
2. Testvorbereitung: Auswahl der Testfälle, Erstellung der Testvorschriften und Bereitstellung der
Testumgebung.
Seite 56
2. Strukturorientierter Test (White-Box-Test): Die Auswahl der Testfälle erfolgt aufgrund der
Programmstruktur. Es wird angestrebt, die Programmstruktur möglichst vollständig abzudecken
(z.B. alle Anweisungen mindestens einmal zu durchlaufen.
1. Funktionsorientierter Test (Black-Box-Test): Auswahl der Testfälle erfolgt aufgrund der
Spezifikation, die Programmstruktur kann unbekannt sein. Es wird angestrebt, die geforderten
Eigenschaften (Funktionalität, Leistungsverhalten, weitere Attribute) des Prüflings möglichst
abzudecken.
Grundsätzlich lassen sich zwei Klassen von Testverfahren unterscheiden:
3. Testdurchführung: Einrichten der Testumgebung, Durchführen der Testfälle nach Testvorschrift und
Notieren aller Befunde. Die Fehlerbehebung ist kein Bestandteil des Test; sie erfolgt nachher,
indem die Testbefunde analysiert werden.
In jedem Test gibt es drei Phasen:
Nicht alle Eigenschaften können mit Testen geprüft werden. Qualitätsmerkmale wie z.B. Portabilität
und Pflegbarkeit sind nicht testbar. Auch werden beim Testen nur Fehlersymptome und nicht
Fehlerursachen gefunden.
• Der Schreiber erstellt für alle sichtbar (auf dem Hellraumprojektor) den Reviewbericht. So können
alle Teilnehmer das Geschriebene laufend verfolgen und entsprechend reagieren.
• Die Gutachter haben die Aufgabe, das zu prüfende Material in Vorbereitung zu begutachten und in
der Sitzung über ihre Erkenntnisse zu berichten. Zu den wichtigsten Punkten gehören gute
Vorbereitung, Nennung der wichtigsten Punkte, keine persönliche Profilierung, gut zuhören und
eigenen Beitrag zu einer offenen und kooperativen Atmosphäre leisten.
• Der Autor (bzw. ein Vertreter der Autorenschaft) nimmt an der Sitzung teil, weil er einerseits
Unklarheiten und Missverständnisse unter Umständen sofort klären kann und anderseits weil er
anhand des Revisorenberichtes die Mängel beheben muss.
Die Review-Teilnehmer sind verantwortlich für die Qualität des Reviews, d.h. dafür dass
einerseits schlechte Produkte erkannt werden und möglichst alle Mängel im Bericht aufgeführt werden
und dass anderseits gute Produkte als solche erkannt werden und nicht mit gesuchten Schwachstellen
belastet werden. Das Reviewteam ist aber nicht für die Qualität des Produktes verantwortlich.
Review-Regeln:
• Das zu prüfende Material wird rechtzeitig vor der Sitzung verteilt
• Die Teilnehmer müssen rechtzeitig eingeladen werden (z.B. jeden Di. 10.00-12-00)
• Alle kommen vorbereitet zur Sitzung
• Es nehmen mindestens drei, höchstens aber sieben Personen teil
• Die Sitzung dauert maximal zwei Stunden
• Die Probleme werden nur genannt, nicht gelöst
• Jeder Gutachter nennt mindestens eine positiven und einen negativen Punkt
• Stilfragen werden nicht diskutiert
• Das Produkt wird bewertet, nicht die Produzenten
• Die Prüfung ist um so einfacher und effizienter, je mehr Standards und Prüflisten bereitstehen,
nach denen gewertet werden kann.
Seite 55
Software Enigneering
10 Dokumentation
10.1 Grundsätze der Dokumentation
Dokumentation
Grundsätze der Dokumentation
Bei der Entwicklung von Software entsteht kein materielles Produkt. Alle Entwicklungstätigkeiten
manifestieren sich letztlich nur in Form von Dokumenten (im weitesten Sinne ist auch Programmcode
ein Dokument). Es gibt zwei Arten von Dokumentationen bei der Softwareerstellung:
• Produktdokumentation: Softwareprodukt und seine Benutzung
• Projektdokumentation: Entwicklung eines Softwareproduktes
Die Dokumentation hat folgende drei Hauptaufgaben:
1. Wissensicherung: Das Wissen über ein System mach einen beträchtlichen Teil des Wertes eines
Systems aus. Die Produktdokumentation hat die Aufgabe, dieses Wissen schriftlich oder auf
Datenträgern festzuhalten. Die Projektdokumentation sichert die Erfahrung in der Abwicklung von
Projekten.
2. Kommunikation: Eine geordnete Systementwicklung und - pflege ist ohne Kommunikation nicht
möglich. Mündliche Kommunikation ist bei Arbeiten in einem kleinen Personenkreis sehr effizient.
Ausschliesslich mündliche Kommunikation verursacht jedoch erhöhte Kosten, wenn der
Personenkreis sich ändert oder wenn die Systembetreuung auf einen anderen Personenkreis
übergeht. Daher müssen alle für ein System wichtigen mündlichen Informationen und Absprachen
in Dokumenten festgehalten werden.
Software Enigneering
10.2 Produktedokumente
Die Produktdokumentation muss folgende Aspekte eines Systems dokumentieren:
• die Anforderungen an das System
• das Konzept der Lösung
• die Einzelheiten der Lösung (Entwürfe und Realisierungen)
• die Montage der einzelnen Komponenten (Integration und Installation)
• die Planung von Tests und der Abnahme
• die Handhabung des Systems (Benutzerdokumentation).
Dokumentation
Produktedokumente
Die Anforderungsspezifikation legt präzise, detailliert und (soweit wie möglich) nachprüfbar fest, was
von dem zu entwickelnden System verlangt wird.
Das Lösungskonzept beschreibt die Architektur der Lösung. Dies umfasst insbesondere die
Gliederung der Lösung in Komponenten (Teilsysteme, Aufteilung in Prozesse, Modularisierung), die
Kommunikation zwischen diesen Komponenten, die Verteilung auf Software und Hardware sowie die
Verteilung der Software auf die vorhandenen Ressourcen.
Entwürfe und Programmcode beschreiben die Lösungsdetails (verwendete Algorithmen und
Datenstrukturen). Entwürfe werden entweder separat vom Programmcode dokumentiert oder sie sind
in Form von ausführlichen Kommentaren im Programmcode integriert.
Der in der Abnahmevorschrift beschriebene Abnahmetest bildet den formalen Abschluss einer
Entwicklung. Der Auftraggeber überprüft mit diesem Test, ob das System die in der
Anforderungsspezifikation gestellten Anforderungen erfüllt.
Die Testvorschriften legen fest, welche Tests für die einzelnen Komponenten nach ihrer
Fertigstellung durchzufahren sind und welche Tests nach welchem Integrationsschritt auszuführen
sind.
3. Sichtbarmachen des Projektfortschrittes: Dokumente sind die greifbaren Resultate des
Entwicklungsprozesses. Der Abschluss jeder Phase der Entwicklung wird nachprüfbar markiert
durch
die
Fertigstellung
und
Freigabe
von
Dokumenten.
Dadurch,
dass
die
Abschlussdokumentation schritthaltend mit der Entwicklung entsteht, ist der Projektfortschritt
besser quantifizierbar.
Der Integrationsplan beschreibt die Integration der einzeln fertiggestellten Komponenten zu einem in
einer Testumgebung lauffähigen Gesamtsystem.
Seite 58
Das Projektmodell enthält alle Schriftstücke und Berichte, die im Laufe der Projektabwicklung
anfallen.
Der Qualitätsplan enthält die Vorgaben, die das Projekt betreffend Qualität zu beachten hat. Ist ein
standardisierter Rahmen-Qualitätsplan vorhanden, sind projektspezifische Qualitätspläne häufig nicht
erforderlich.
Der Projektplan dokumentiert den geplanten Projektablauf, wobei den Sollvorgaben während der
Projektabwicklung laufend die Ist-Werte gegenübergestellt werden.
• Projektprotokoll
• Qualitätsplan
• Projektplan
Die wichtigen Projektdokumente sind:
10.3 Projektdokumente
Ein Glossar, welches die verwendeten Begriffe und Abkürzungen erklärt, ist sowohl in der Entwicklung
als auch nachher für die Benutzer sehr hilfreich. Ein solches Glossar sollte daher in jedem grösseren
Entwicklungsprojekt (projektbegleitend) erstellt werden.
Das Benutzerhandbuch enthält die Bedienungsanleitung für das System. Es beschreibt aus
Benutzersicht, welche Funktionen das System bereitstellt und wie man es startet und bedient. Zu
einem eingebetteten System gibt es kein Benutzerhandbuch. Seine Benutzung wird im Rahmen der
Bedienungsanleitung des übergeordneten Systems dokumentiert.
Die Installationsanleitung beschreibt, wie ein auf der Zielhardware lauffähiges System konfiguriert
und auf der Zielhardware installiert wird.
Dokumentation kostet Entwicklungszeit und -geld. Darum wird sie - vor allem unter Termindruck - oft
nicht oder nur fragmentarisch erstellt.
Dokumentation ist nicht Selbstzweck. Es darf daher nur soviel wie unbedingt notwendig dokumentiert
werden, dies aber sorgfältig und konsequent. Das notwendige Minimum ist schon recht viel; in der
Regel wird nicht zuviel, sondern zuwenig dokumentiert.
Seite 57
Software Enigneering
Dokumentation
Dokumentenverwaltung
Software Enigneering
11 Konfigurationsverwaltung
Konfigurationsverwaltung
Grundlagen
11.1 Grundlagen
10.4 Dokumentenverwaltung
Dokumente, die man nicht findet, wenn man sie braucht oder solche, die nicht mehr aktuell sind, sind
von zweifelhaftem Wert. Dokumente müssen daher der Konfigurations-Verwaltung unterworfen
werden. Vor alle drei Dinge sind wichtig:
“Ändern Sie noch eben schnell ...” Die allzu einfache Möglichkeit, Software zu ändern, verursacht eine
Menge Probleme, z.B.:
Seite 60
Eine konsistente Menge von Softwareeinheiten, sie zusammen eine gegebene Aufgabe erfüllen, heisst
Release. Releases werden vor allem zur Auslieferung von Softwareprodukten an Kunden und zur
periodischen Lieferung von Nachträgen und Nachbesserungen verwendet.
11.4 Konfiguration
Die Softwareeinheiten werden von einem Software-Bibliothekar registriert und verwaltet. Von jeder
Einheit können mehrere Versionen geführt werden. Im einfachsten Fall wird durch aufsteigende
Versionsnummern deutlich gemacht, in welcher Reihenfolge die Versionen entstanden sind.
11.3 Registrierung und Verwaltung
Softwareeinheiten haben eine eindeutige Kennzeichnung, bestehend aus einem Namen und einer
Versionsnummer für das Änderungswesen. Die Identität einer Softwareeinheit ist z.B. mit Prüfsummen
feststellbar.
11.2 Kennzeichnung
Eine Softwareeinheit ist der kleinste, im Rahmen der Konfigurationsverwaltung als atomar behandelte
Baustein einer Konfiguration. Softwareeinheiten werden nur als Ganzes registriert, freigegeben oder
geändert. Softwareeinheiten sind z.B. Prorgammmodule und Dokumente.
Eine Softwarekonfiguration ist die Gesamtheit zusammenpassender Softwareeinheiten.
Konfigurationsverwaltung von Software ist die Gesamtheit aller Verfahren zur eindeutigen
Kennzeichnung der Konfiguration eines Softwaresystems mit dem Zweck, den Aufbau und alle
Änderungen dieser Konfiguration systematisch zu überwachen, die Konsistenz des Softwaresystems
sicherzustellen und die Möglichkeit der Rückverfolgung anzubieten.
• Undokumentierte Schnellreparaturen an in Betrieb befindlicher Software
• Paralleles, unkoordiniertes Ändern eines Moduls durch mehrere Personen
• Codieren anhand der falschen Version des Entwurfs
• Klassifikation: Leichtes Finden durch geordnetes Ablegen (eindeutiger Name, einheitliches
Deckblatt, einheitliche und vollständige Kopfzeile)
• Freigabewesen: Nur Freigegebenes ist gültig (Fertiggestellte Dokumente werden geprüft,
gefundene Mängel behoben und erst dann freigegeben)
• Änderungswesen: Nur Aktuelles ist hilfreich (Dokumente werden aktuell gehalten und
unkontrollierte Änderungen und Anpassungen an Dokumenten werden verhindert)
10.5 Dokumenterstellung
Dokumente entstehen schritthaltend mit der Entwicklung. Produktdokumente sind ein Bestandteil des
zu entwickelnden Produkts. Ohne Dokumente sind weder eine vernünftige Projektführung noch eine
geordnete Prüfung und Qualitätssicherung möglich. Deshalb sollte ein Projekt nicht “Hinterher”Dokumentiert werden; es kann aber sich machen, eine Dokumentation nachträglich nochmals zu
überarbeiten.
Seite 59
Software Enigneering
11.5 Änderungswesen
Konfigurationsverwaltung
Änderungswesen
Grundlage eines geordneten Änderungwesen sind getrennte Umgebung für Entwicklung
(Arbeitsumgebung), Verwaltung (Referenzumgebung), Test (Testumgebung) und operativen Einsatz
(Produktionsumgebung) der Softwareeinheiten. Freie Änderungen sind nur in der Arbeitsumgebung
gestattet, in der Refernzumgebung gilt ein strikt reglementiertes Änderungsprozedere. Der
Änderungsstand einer Software muss immer nachweisbar sein (z.B. auf Formularen).
11.6 Behandlung von Problemmeldungen
Grundlage für die Behandlung von Problemen, die beim Verwender eines Softwaresystems auftreten,
ist ein organisiertes Problemmeldewesen (nicht Fehlermeldewesen, denn die Ursache kann ein
Softwarefehler, eine Fehlbedienung oder Unkenntnis sein). Ein möglicher Ablauf könnte wie folgt
aussehen:
• Registrierung der eingegangenen Problemmeldungen
• Analyse der Meldung
• Vorläufige Anwort
• Fehlerbehebung
• Abschliessende Antwort
• Abschluss und Ablage der Problemmeldung
• Auslieferung von neuem Release
Seite 61
Software Enigneering
12 Produktivitätsfaktoren
12.1 Werkzeuge
Produktivitätsfaktoren
Werkzeuge
Im Inforrmatik-Sprachgebrauch sind Werkzeuge rechnergestützte Hilfsmittel für die Entwicklung von
Software. Mit dem Einsatz von Werkzeugen werden primär folgende Ziele verfolgt:
• Entlastung der Entwickler von Routinearbeiten
• Bearbeitung der Sprachen (graphisch oder textuell), mittels derer die Entwickler ihre Probleme und
Lösungen formulieren
• Unterstützung des Einsatzes von Entwicklungsmethoden
• Vereinfachung von Änderungen.
Werkzeuge sind jedoch - entgegen einem weit verbreiteten Glauben - keine Wunderwaffen:
• sie steigern die Produktivität nicht um (dezimale) Grössenordnungen
• sie ersetzen das eigene Denken und sorgfältige Arbeiten nicht
• sie führen zwar in den meisten Fällen zu verbesserter Qualität der Produkte, machen aber das
Qualitätsmanagement (Reviews, Tests, etc.) nicht überflüssig.
Ein isolierter Einsatz von Werkzeugen bringt in der Regel wenig oder kann sogar kontraproduktiv sein.
Werkzeuge müssen als eine Komponente in einer Gesamtstrategie für rechnergestütztes Software
Engineering aufgefasst werden. Die Sache (Software Engineering) und das Mittel (computergestützt)
dürfen in ihrer Wichtigkeit nicht miteinander verwechselt werden.
Seit etwa 1986 werden Werkzeuge (vor allem solche für Spezifikation und Entwurf) von Software
häufig mit dem Schlagwort CASE (computer aided software engineering) bezeichnet.
Produktivitätssteigerungen von 20-50% sind durch geeigneten Werkzeugeinsatz durchaus erreichbar.
Vorher ist aber eine intensive Schulung nötig. Werkzeugeinsatz ist daher keine Massnahme, die sofort
wirksam wird, sondern ein Investition, die sich erst längerfristig, dann aber um so deutlicher, auszahlt.
Neben dem Produktivitätsgewinn stellt sich oft ein Qualitätsgewinn ein, der ebenfalls nicht zu
vernachlässigen ist.
Die vollständige Software Engineering-Umgebung, welche alle Aktivitäten durchgehend und konsistent
unterstützt, ist zwar schon vielfach postuliert und skizziert worden, aber es gibt sie noch immer nicht zu
kaufen. Vielmehr ist eine Vielzahl von Systemen mit unterschiedlichen Schwerpunkten verfügbar:
• Editoren
• Spezifikations- und Entwurfssysteme
• Programm-Entwurfssysteme
Seite 62
Software Enigneering
• Compiler, Browser und Programmierumgebung
• Programmgeneratoren
• Mess- und Testwerkzeuge
• Konfigurationsverwaltungssysteme
Produktivitätsfaktoren
Mehrfachverwendung von Software
Wenn man Werkzeuge für die Softwareentwicklung erfolgreich einführen will, so muss man sich über
folgende Fragen im klaren sein:
• Welche Aktivitäten sollen unterstützt werden?
• Wie wirtschaftlich ist der Einsatz (25% Einsparung von 20% Aufwand ergibt nur 5% Einsparung)?
• Welche Entwicklungskonzepte sollen eingesetzt werden?
• Ist die Schulung geregelt?
• Wie sieht die Einführungsstrategie aus?
• Ist die Betreuung der Werkzeugverwender geregelt?
12.2 Mehrfachverwendung von Software
Siehe Kapitel 3.4, “Wiederverwendung und Beschaffung”
12.3 Die Rolle der Menschen
Software wird von Menschen gemacht. die Softwareleute sind daher neben der Softwaremehrfachverwendung der entscheidende Produktivitätsfaktor der Softwareentwicklung.
Regeln über Menschen in der Softwareentwicklung:
Produktivität: Die Schwankungsbreite der individuellen Produktivität von Softwareentwicklern ist sehr
gross (1:20).
Disponibilität: Personal ist nicht beliebig disponierbar. Drei Regeln sind zu beachten:
1. Personalbestände in einem Projekt können nur langsam auf- und abgebaut werden.
2. Zu einem gegebenen Entwicklungsaufwand gibt es eine optimale Gruppengrösse.
3. Aufstockung des Personalbestandes in einem verspäteten Projekt führt zu noch mehr Verspätung.
Arbeitsverteilung: Softwareentwickler schreiben nicht nur Programm. Eine Studie der Bell Labs
ergab, dass ein Entwickler nur 13% seiner Zeit Programme schreibt. 16% sind Programme und
Handbücher lesen und 32% arbeitsbezogene Kommunikation. Der Rest ist persönliches, Ausbildung,
Post und Diverses.
Gruppengrösse: Jede Entwicklungsgruppe benötigt einen Teil ihrer Zeit für Organisation und
Kommunikation innerhalb der Gruppe. Mit zunehmender Personenzahl nimmt dieser nichtproduktive
Aufwand überproportional zu.
Emotionales und Rationales in der Softwareentwicklung: Emotionale Einstellungen der Beteiligten
haben erheblichen Einfluss auf das, was in der Entwicklungsabteilung tatsächlich geschieht. Der
Einfluss des Emotionalen ist um so stärker, je weniger er den Beteiligten bewusst ist.
Arbeitsumgebung: Ausbildung und Arbeitsumgebung der Menschen haben einen erheblichen
Einfluss auf den Produktionsprozess.
Seite 63
Software Enigneering
13 Aufgaben
13.1 Einführung
13.2 Zielsetzung, Messung
Aufgaben
Einführung
Seite 64
Software Enigneering
13.3 Der Software-Prozess
13.4 Software-Projektführung
Aufgaben
Der Software-Prozess
Seite 65
Software Enigneering
13.5 Software-Aufwandschätzung
Aufgaben
Software-Aufwandschätzung
Seite 66
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement