Software planung, aufwandschätzung, der software-lifecycle (hand-out), spezifikation
Inhaltsverzeichnis
0 INHALTSVERZEICHNIS II
1 SOFTWARE PROJEKTPLANUNG 2
1.1 Der Projektplan 2
1.1.1 Überlegungen zum Planen 3
1.1.2 Inhalte des Projektplans 3
1.
1.3 Größenmaßnahmen 4
1.1.4 Schätzungen 4
1.1.5 Produktionsfaktoren 5
1.
1.6 Zeitpläne 6
1.1.7 Projektverfolgung 6
1.1.8 Der Entwicklungsplan 6
1.
1.9 Zusammenfassung 6
1.2 Ergänzung 7
2 AUFWANDSCHÄTZUNG 10
2.1 Einleitung 10
2.2 Vorgehen 10
2.2.
1 Überprüfung des Fachkonzepts des Auftraggebers auf 10
2.2.2 Hochrechnen von Datenobjekten und Funktionen 10
2.2.3 Schätzen des Aufwandes für das Gesamtprojekt durch 10
2.2.
4 Funktion Point Methode 10
2.3 Schritte der FPM 11
2.3.1 Geschäftsvorfälle oder Funktionen 11
2.3.2 Einflußfaktoren 12
2.
3.3 Rechenverfahren 12
2.4 Ergänzung 13
3 DER SOFTWARE-LIFECYCLE (HAND-OUT) 16
3.1 Planungsphase 16
3.2 Analysephase 17
3.3 Die Entwurfsphase 17
3.
4 Die Erstellungsphase 18
3.5 Die Einführungsphase 18
3.6 Ergänzung 19
4 SPEZIFIKATION 22
4.1 Das Pflichtenheft 22
4.2 Einige Definitionen aus dem Pflichtenheft 22
4.2.
1 Sätze ohne Aussage/Inhalt (PLATITUDES) 22
4.2.2 Zweideutigkeiten (AMBIGUITIES) 22
4.2.3 Entwurfs- & Implementierungsanweisungen 22
4.2.
4 Unterlassungen (OMISSIONS) 23
4.2.5 Mischung der Abstraktionen 23
4.3 Der Weg zur Spezifikation 23
4.4 Unterschreiben 24
4.5 Weiterentwicklung der Systemspezifikation 24
4.
5.1 Checkliste 24
4.6 Ableitung des Systems und Abnahmetest 25
4.7 Ergänzung 26
5 GRAPHISCHE BENUTZEROBERFLÄCHE 30
5.1 Einleitung 30
5.2 Wie man es besser nicht macht 30
5.
3 Die Analyse 31
5.4 Überlegungen zum Entwurf 32
5.5 Die Gestaltung der Anwendung 32
5.6 Schrift und Farbe 34
5.7 Ergänzung 34
6 DATENFLUßDIAGRAMME 36
6.1 Einleitung 36
6.
2 Definition und Komponenten eines Datenflußdiagramm 36
6.3 Prozeßspezifikation 37
6.4 Schlußkommentar 37
6.5 Control Flow Model 37
6.6 Funktionale Dekomposition 37
6.7 Abschlußbeispiel 38
6.
8 Ergänzung 38
7 INFORMATION ENGINEERING 40
7.1 Prolog 40
7.2 Was ist Information Engineering 40
7.3 Daten sind zentral 41
7.4 Daten sind statisch; Prozeduren nicht 41
7.5 Die Blöcke des Information Engineerings 41
7.
5.1 Block 1 42
7.5.2 Block 2 42
7.5.3 Block 3 42
7.
5.4 Block 4 und 5 43
7.5.5 Block 6 43
7.5.6 Block 7 44
7.
6 Das Haus auf dem Sand 45
7.7 Ergänzung 46
8 JACKSON DESIGN METHODE 48
8.1 Ergänzung 50
9 STRUKTURIERTE ANALYSE UND DESIGN 54
9.1 Datenflußdiagramm 54
9.2 Strukturdiagramm 54
9.3 Designbewertung 56
9.
4 Das Design für die Durchführung vorbereiten 57
9.5 Ergänzung 57
10 QUALITÄTSMANAGEMENT 60
10.1 Qualitätsmanagement 60
10.1.1 Die Vorteile von SQS 60
10.1.
2 Die Notwendigkeit von SQS 61
10.1.3 Die Ziele von SQS 61
10.1.4 Die Rolle von SQS 61
10.2 Die Verantwortung der SQS 62
10.
2.1 Die Funktionen der SQS 62
10.2.2 Die Berichterstattung der SQS 63
10.3 Starten des SQS-Programms 63
10.4 Der SQS-Plan 64
10.
5 Überlegungen zur SQS 65
10.6 Die SQS-Leute 66
10.7 Unabhängige Nachprüfung und Gültigkeitserklärung 66
10.8 Ergänzung 66
11 OOP 70
11.1 OOP- Grundlagen 70
11.2 Vererbung (Inheritance) 71
11.
3 Dynamisches Binden und Polymorphismus 71
11.4 Ergänzung 72
12 SORTIERALGORITHMEN 74
12.1 Spielregeln 74
12.2 Sortiermethoden 74
12.3 Was ist relevant bei den Sortieralgorithmen 74
12.4 Selection Sort 75
12.
5 Insertion Sort 76
12.6 Bubble Sort 76
12.7 Shellsort 78
12.8 Quicksort 79
12.9 Kleine Teildateien 82
12.10 Distribution Counting 82
12.
11 Sortieren von Dateien mit großen Datensätzen 83
13 ELEMENTARE SUCHMETHODEN 86
13.1 Sequentielle Suche (sequential search) 86
13.2 Binäre Suche (binary search) 87
13.2.1 Interpolationssuche (interpolation search) 87
13.3 Suche in einem Binärbaum (binary tree search) 88
13.
4 Löschen 89
13.5 Indirekte binäre Suchbäume 90
14 DATENKOMPREMIERUNG (FILE COMPRESSION) 92
14.1 Lauflängenkodierung (Run-Length Encoding) 92
14.2 Kodierung mit variabler Länge (Variable-Length Encoding) 93
14.3 Erzeugung des Huffman-Codes (Building the Huffman Code) 94
14.4 Implementation (Implementation) 95
14.
5 Ergänzung 95
15 HASHING 98
15.1 Berechnung von Hash-Funktionen 98
15.2 Methoden zur Kollisionsbehandlung 99
15.2.1 Getrennte Verkettung 99
15.2.
2 Offene Adressierung 100
15.3 Ergänzung 102
16 AUSGEGLICHENE BÄUME 104
16.1 Top-Down 2-3-4-Bäume 104
16.2 Rot-Schwarz-Bäume 106
16.3 Andere Algorithmen 108
17 FOLIEN (ZU KAPITEL 5) 110
18 GLOSSAR 116
Software Projektplanung
Zu Beginn wird von dem Projektleiter (Projektverantwortlicher) ein Projektplan erstellt. In dieser ersten Version des Projektplans müssen alle Aktivitäten enthalten, sowie gewisse Abschätzungen bezüglich Dauer und Aufwand des Projekts aufgenommen werden.
Fällt die Entscheidung für die Ausführung des Projekts, so muß dann der eigentliche Projektplan von dem Projektleiter erstellt werden. Er muß sich dabei mit verschiedenen anderen Personen oder Personengruppen beraten.
Bei größeren Projekten muß eine Teilung in einen Gesamtprojektplan und in Detailprojektpläne vorgenommen werden.
Der Gesamtprojektplan sollte unter anderem folgende Informationen enthalten:
Eine Beschreibung der Aufgabenstellung des Projekts
Die verwendete Entwicklungsmethode
Festlegung von Hauptmeilensteinen
Eine Zerlegung des Gesamtprojekts in Teilprojekte (für die es jeweils einen Detailprojektplan gibt)
Einen Zeitplan mit den wichtigsten Terminen
Wichtige zeitliche Abhängigkeiten (Netzplan)
Eine Personalübersicht
Eine Übersicht über die benötigten Ressourcen (Betriebsmittel, usw.)
Ein Detailprojektplan sollte enthalten:
Eine Zerlegung des (Teil-) Projekts in Teilaufgaben
Eine kurze Beschreibung dieser Teilaufgaben und ihrer Endprodukte
Start- und Fertigstellungstermine für die Teilaufgaben
Zuordnung der Verantwortlichkeit für die einzelnen Teilaufgaben
Zuteilung von Ressourcen zu den einzelnen Teilaufgaben bzw. zu den verantwortlichen Personen
Ein Projektplan entwickelt sich im Laufe eines Projekts schrittweise:
Zu Beginn wird ein Übersichtsprojektplan mit den Hauptmeilensteinen erstellt.
Die erste Version des eigentlichen Projektplans enthält dann eine genaue Planung aller Schritte bis zum nächstfolgenden Meilenstein, bei dem die nächste Version des Projektplans fällig ist, die dann weitere genaue Planungen enthält.
Die Definition eines Meilensteines in einem Projektplan muß drei Punkte enthalten:
Die Produkte, die zu diesem Meilenstein fertig sind
Den Termin für diesen Meilenstein
Die Kontrollverfahren, die auf die Produkte des Meilensteins angewandt werden
Der Projektplan
Der Projektplan definiert die Arbeit und wie sie zu machen ist. Er ist mit einer Definition von jeder Hauptaufgabe, einer Schätzung der Zeit und der Ressourcen die benötigt werden, sowie einer Rahmenarbeit für die Kontrolle versehen.
Der Projektplan wird am Anfang des Auftrages entwickelt und dann während des Arbeitsprozesses verfeinert. Am Anfang des Projektes sind die Forderungen eher vage und unvollständig.
Überlegungen zum Planen
Mit wenigen Ausnahmen sind anfängliche Betriebsmittelschätzungen und Zeitpläne nicht annehmbar.
Dies ist nicht auf die Unerfahrenheit der Programmierer zurückzuschließen, sondern auf die Benutzer die mehr verlangen als sie benötigen.
Faustregel:
Zeitpläne und Schätzung werden zu hoch, wenn nicht die erste Fassung des Planes nur die wesentlichsten Teile beinhaltet.
Der Planungszyklus
Der Zyklus beginnt mit den wesentlichen Anforderungen.
Die Antwort auf die Frage einer Verpflichtung muß lauten:
Ich verstehe ihre Anforderungen und werde einen Plan mit diesen Zielen entwickeln aber keinen wirklichen Plan. Ich kann keine Verpflichtung eingehen.
Der Plan muß zuerst in Schlüsselelemente zerlegt werden.
Vom Groben ins Detail - Work Breakdown Structure
Die Größe jedes Produktes ist geschätzt.
Die benötigten Ressourcen sind geplant.
Der Zeitplan wird produziert.
Inhalte des Projektplans
Die Elemente des Softwareprojektplans sind:
Ziele:
Sie beschreiben was von wem wie und wann gemacht wird.
Work Breakdown Structure (WBS):
Die WBS zerlegt das Projekt in Teile die alle definiert, geschätzt und verfolgt werden können.
Produktgrößenschätzung:
Schätzung zu der Produktgröße.
Einbezogen werden auch Erfahrungen von früheren Projekten.
Ressourcenschätzung:
Schätzung zu den benötigten Ressourcen. Es fließen auch Erfahrungen bezüglich des Produktionsfaktors ein.
Projekt-Zeitplan:
Basierend auf die Projektbelegschaft- und Ressourcenschätzungen. Ein Zeitplan für die Teilpläne wird erstellt.
Ziele
Die Ziele des Projekts werden während der Bedingungsphase entwickelt.
Dies ist auch die Verhandlungsphase in welcher die Softwareentwickler und der Kunde beschreiben was gemacht wird, wie der Erfolg gemessen wird und wieviel Zeit und Ressourcen benötigt werden.
Um weitere Wünsche der Kunden berücksichtigen zu können, müssen die Entwickler folgende Punkte einhalten:
Das Produkt muß in kleinen zunehmenden Schritten realisiert werden.
Auswahl jeder Steigerung zur Unterstützung des Erfolgs u/o verbessern des Wissens.
Festlegen der Bedingungen für jeden zunehmenden Schritt vor dem Beginnen des Designs.
Wenn sich die Bedingungen während der Einführung ändern, verzögern die Änderungen die nachfolgenden Objekt.
Die Work Breakdown Struktur (WBS)
Projektplanung beginnt mit der Schätzung von der Größe des Produktes.
Diese Schätzung beginnt mit einer detaillierten und dokumentierten Auflistung des Produktes in Arbeitselemente. Die Auflistung besteht aus zwei Elementen die Produktstruktur und der Software Prozeß.
Die Arbeitselemente werden den verschiedenen Abteilungen zugeordnet. Das Ziel der WBS ist es, das Projekt in kleine Teile aufzuteilen, um diese dann von kleinen Arbeitsgruppen in der kürzesten Zeit zu erledigen.
Generell gilt:
Je detaillierter die WBS ist, desto besser können die Produkte geschätzt werden, desto besser ist der Projektplan, desto besser kann man es verfolgen.
Größenmaßnahmen
Man kann viel über die Softwaregröße diskutieren, aber es gibt wahrscheinlich keine optimale Lösung die sämtliche Ziele beinhaltet.
Es ist weit verbreitet, die Größe des Sourcecodes zu definieren und Berechnungen zu automatisieren. Leider ist es aber oft schwer, Zeilen von Funktionen bereits vorher zu beschreiben. Um dieses Problem zu lösen wurden die sogenannten Function Points entwickelt.
Function Points
Mit Function Points sind anfängliche Anwendungen zu bestimmen, sowie die Anzahl und Komplexität der verschiedenen Eingaben und Ausgaben, Kalkulationen und der benötigten Daten.
Vorgangsweise:
Zählen der Eingaben, Ausgaben, Nachfragen, Hauptfelder und der benötigten Schnittstellen.
Multiplizieren der Zahlen mit den folgenden Faktoren:
Eingaben
4
Ausgaben
5
Nachfragen
4
Hauptfelder
10
Schnittstellen
10
Ausgleichen der Summen auf +/-25%, abhängend von der geschätzten Komplexität des Projektes.
Schätzungen
Aufwandsschätzung ist ein Muß bei jedem Softwareprojekt, da einem leider keine uneingeschränkten Ressourcen (Zeit und Geld) zur Verfügung stehen. Ein weitverbreitetes Schätzverfahren ist die Delphi-Methode.
Experten geben unabhängig voneinander Schätzungen ab. die Ergebnisse werden durch neuerliches Befragen abgeglichen. Das Delphi-Verfahren ist eine generelle Prognose nicht nur für Softwareprojekte.
1) Koordinator präsentiert jeden Experten die Spezifikation und ein Schätzformular
2) Treffen aller Experten zur Diskussion der Aufgabenstellung und der Schätzung
3) Die Experten füllen unabhängig voneinander die Schätzformulare aus
4) Der Koordinator verteilt eine Zusammenfassung der Schätzungen auf einem Wiederholformular
5) In einem Gruppentreffen werden die Punkte mit unterschiedlicher Expertenmeinung diskutiert
6) Die Experten füllen neuerlich unabhängig voneinander die Schätzformulare aus
Die Schritte 4) bis 6) werden so oft wie nötig wiederholt.
Die Schwierigkeit der Aufwandsschätzung steigt mit dem Umfang des Projekts, und sinkt mit dem Projektfortschritt (je fortgeschrittener die Projektphase, desto genauer wird die Schätzung).
Produktionsfaktoren
Wenn bereits Schätzungen über den verwendeten Sourcecode vorliegen, so können die Werte in Programmierermonaten (Mannmonaten) und in die benötigte Zeit umgerechnet werden. Diese Produktionsfaktoren können im Durchschnitt in Mannmonaten produziert werden. Produktionsfaktoren können z.B. die Codewachstumsrate sein.
Umgebungsfaktoren
obere 25%
untere 25%
Gesamt
zugeteilte Arbeitsfläche (feet ²)
78
46
63
ruhiger Arbeitsplatz
57%
29%
42%
privater Arbeitsplatz
62%
19%
39%
stilles Telefon
52%
10%
29%
Umleitung der Telefonate
76%
19%
57%
unnötige Unterbrechungen
38%
76%
62%
Gefühl der Anerkennung
57%
29%
45%
Firmenspezifische Produktionsdaten
Firmen können/müssen ihre eigenen Produktionsfaktoren entwickeln. Diese ergeben sich durch das Prüfen von den Zahlen der kürzlich erzeugten Programme, sowie dem Zählen der Codezeilen in einer konsequenten und definierten Art und Weise. Weiters kann man die Faktoren durch kalkulieren der benötigten Mannmonate für ein Projekt erhalten.
Entwicklungsspezifische Produktionsdaten
Seit Softwarefirmen ihre Arbeit generell aufgezeichnet haben, ist der erste Schritt in der Entwicklung von Produktionsdaten zu erfahren, was vorhanden ist. Mit dieser Information sollte die folgende Annäherung produziert werden:
Identifizieren einer Anzahl von bereits vorhandenen Programmen die mit dem Projekt vergleichbar sind.
Daten über die Größe des Codes zu bekommen.
Für veränderte Programme sollte nur der Prozentsatz des veränderten Codes und die Nummer der Codelinie aufgezeichnet werden.
Erhalten der Mannmonate für das Projekt.
Zeitpläne
Wenn die Anzahl aller benötigten Ressourcen ausgerechnet worden ist, kann der Zeitplan entwickelt werden. Die Ressourcen werden dabei über die Entwicklungsphasen verteilt.
Sind einmal die benötigten Betriebsmittel bekannt, so kann ein gesamter Zeitplan wie folgt erstellt werden:
Basierend auf alle Projektzeitpläne kann ein Angestelltenplan erstellt werden.
Ein vorbereitender Zeitplan für jede Phase kann durch Vergleich der anwachsenden benötigten Ressourcen erstellt werden.
Ein anfänglicher Zeitplan entsteht.
Dieser vorbereitende Plan wird überholt und die Angestellten können fest zugewiesen werden. Änderungen sind meist erforderlich.
Projektverfolgung
Mehrere Checkpoints müssen für jede Projektphase festgelegt werden. Diese sollten wie folgt lauten:
Modulspezifikation fertiggestellt und geprüft
Moduldesign fertiggestellt, geprüft und korrigiert
Moduleinheit Testplan fertiggestellt, überarbeitet und bestätigt
Modulcode fertiggestellt und kompiliert
Modulcode geprüft und korrigiert
Modul wird in System integriert
Der Entwicklungsplan
Nach Erstellung der Schätzung und des Zeitplans wird der volle Entwicklungsplan erstellt und überprüft.
Nach der Vorbereitung wird der Plan in jede eingebundene Stelle geschickt, überprüft und bestätigt.
Jede Gruppe muß mit dem Plan einverstanden sein, denn er repräsentiert ihre Verpflichtungen wie und in welcher Zeit sie die Arbeit vollbringen. Er beinhaltet:
Software Engineering
Dokumentation
Test und Testbericht
Verpackung und Version
Tools und Support
Training
Installationssupport
Wartung
Annahmetest
Software Qualitätssicherung
Zusammenfassung
Der Projektplan beinhaltet jede Hauptaufgabe, eine Schätzung der Zeit und der benötigten Ressourcen, und eine Rahmenarbeit für die Überwachung und Kontrolle. Er wird am Anfang jedes Projektes erstellt und während des Projektes verfeinert.
Die Elemente eines Softwareplans sind:
Ziele
ein abgerundetes Design
Work Breakdown Structure (WBS)
Schätzung der Produktgröße
Schätzung der Ressourcen
und ein Projektzeitplan
Nach der Erstellung der Zeitpläne und der Schätzungen wird der Entwicklungsplan erstellt und von jeder Stelle geprüft und abgezeichnet.
Ergänzung
Zielfestlegung
Zerlegung in Teilaufgaben: Word Breakdown Structure (WBS)
Zeitplanung
Teilsysteme, Aufgaben
Einplanung von Analyse, Tests und Dokumentation, Schulung, Installation, Qualitätssicherung, Codeinspektion, Reviews
verwenden von Methoden, SW
Netzplan
Meilensteine
Aufwandsschätzung (Delphi-Methode)
Einflußfaktor
Umleitung von Telefonaten
Aufwandschätzung
Einleitung
Wozu dient sie ?
Sie wird dazu benötigt, um den Aufwand eines Software-Projekts zu ermitteln. Dies geschieht, da dieser eine zentrale Bedeutung zwischen Auftraggeber und Auftragnehmer hat.
Vorgehen
Überprüfung des Fachkonzepts des Auftraggebers auf
Funktionalität
Datenbasis
Meist jedoch ist dieses Fachkonzept zu wenig detailliert.
Þ Bewertung des Fachkonzepts (mit Hilfe von z.B.: SETec - Methode)
SETec - Methode:
Der Kern wird einer kritischen Analyse mit gewissen Maßstäben unterzogen.
Hochrechnen von Datenobjekten und Funktionen
Falls dies nicht mit SETec erfolgt, wird ein erfahrener Projektmanager oder ein
computerunterstütztes Wissenssystem herangezogen, um die Anzahl der
“wahren“ Funktionen und Datenobjekte zu errechnen.
Schätzen des Aufwandes für das Gesamtprojekt durch
Funktion Point Methode
Vergleich eines Projektes aus dem Archiv mit dem zu erstellendem Projekt
Delphi-Methode
Einzelne Manager werden getrennt voneinander mit den Unterlagen und Informationen konfrontiert.
Danach schätzt jeder Manager den Aufwand nach seinen Erfahrungen.
Schließlich werden gemeinsam in einem Review die Ergebnisse analysiert, um einen akzeptablen Mittelwert zu erhalten.
Funktion Point Methode
Ziele
Bewertung von Informations-Systemen
Weitergabe dieser Bewertung
Weitergabe der Erfahrungen von positiven oder negativen Einflüssen aus der Projektarbeit
Vorteile
einheitliche Anwendbarkeit
Unabhängig von personenbezogenen Einwirkungen
Transparenz der Ergebnisse
Genauigkeit der Ergebnisse
u.s.w.
Voraussetzungen
einheitliche Vorgangsweise bei der Projektierung
klare Definitionen aller Anforderungen an das Projekt
gleicher Ausbildungs- und Kenntnisstand der Benutzer
exakte und einheitliche Abgrenzung bei der Klassifizierung
Nachteile
sie ist keine Wirtschaftlichkeitsrechnung
sie ist nicht anwendbar bei Kommunikations-Software oder systemnahe Software-Systeme
Schritte der FPM
Geschäftsvorfälle oder Funktionen
Werden unterteilt in :
a) Eingabedaten
z.
B.: - Bildschirmeingaben
- Interface-Daten von Anwendern
- Hinzufügen
- Ändern
- Löschen
b) Ausgabedaten
z.B.: - Lochkarte, Magnetband, Diskette
- Druckausgabe
- Bildschirmausgabe
- Interface-Daten an andere Anwendungen
c) Datenbestände
Jeder Datenbestand, der von der Anwendung
}
- gelesen
- geändert Update-Funktionen
- gelöscht
}
- geschützt
- geladen Service-Funktionen
- entladen
wird, ist zu zählen.
d) Referenzdaten
z.B.
: - Tabellen
e) Abfragen
Es ist jede Abfrage zu zählen, die zu einem Suchen nach Informationen in einem Datenbestand und das Ergebnis der Abfrage dem Benutzer sichtbar wird.
Diese 5 Bereich werden dann bewertet.
Einflußfaktoren
Werden unterteilt in :
a) Schnittstellen mit anderen Anwendungs-Systemen
b) Dezentraler Verarbeitung, Datenverwaltung
c) Transaktionsrate
d) Verarbeitungslogik :
- Rechenoperationen
- Kontrollverfahren
- Ausnahmeregelungen
- Logik
e) Wiederverwendbarkeit in anderen Anwendungen
f) Datenbestandskonvertierungen
g) Benutzerbedingungen
Diese werden wiederum bewertet.
Rechenverfahren
1) Unbewertete Funktion Points = Anzahl · Gewichtung
UFP = Anzahl · Gewichtung
2) Summe der unbewerteten FP
SUFP = UFP1 + UFP2 + . . .
+ UFP15
3) Summe der sieben Einflußfaktoren
SEF = EF1 + EF2 + . . . + EF7
4) Berechnung des Faktors Einflußgrad
FEG = 0,7 + ( 0,01 · SEF )
5) Produkt des Faktors Einflußgrad und
der Summe der unbewerteten FP = bewertete FP
BFP = FEG · SUFP
Hat man nun diese Summe errechnet, kann man an Hand einer Tabelle
( z.B. von IBM ) den Realisierungsaufwand in BM ablesen.
BM = Bearbeiter-Monat = 130 Arbeitsstunden bei folgenden Voraussetzungen :
überwiegend zentrale Online - Anwendungen
Verwendung von höheren Programmiersprachen
Einsatz separater Testsysteme
durchschnittliche Personalqualität
ständige Beteiligung der Anwender bei der Projektentwicklung
zentrale Projektorganisation
Einsatz von Entwicklungs - Tools und - Techniken
Durchführung von Reviews
Ergänzung
Function Point Methode von Allan Albrecht (IBM)
wie lange dauert die Arbeit
es werden alle Funktionen des Systems abgegangen:
für jede der drei Funktionen 0 - 6 Punkte (=> max. 18)
wie kompliziert ist die Eingabe (Faustregeln, Tabellen)
wie kompliziert ist die Ausgabe
Komplexität der Abfragen (Datenbankzugriffe)
pro Tabelle: Anzahl der Spalten und Reihen
Extrapunkte (0 - 60):
Schnittstellen zu anderen Systemen
Verteiltheit
Schnelligkeit
Komplexität der Logik
Wiederverwendbarkeit
Komplexität der Konvertierung vorhandener Datenbanken
Benutzeroberfläche
Punkte in Formel einsetzen => Tabelle von Punkten zu Bearbeitungsmonaten
Vorteile:
Tabellen sind auf Grund der Erfahrung sehr gut
Nachteile:
Vernachlässigung der Entwicklung guter graphischer Oberflächen
Aufwand des Managements (Testen, Organisieren) nicht beinhaltet
Erfahrung der Mitarbeiter, Teamarbeit, Arbeitsraum, ... nicht berücksichtigt
benötigt Verfahren zur Vollständigkeit der Funktionen (ERD)
Der Software-Lifecycle (Hand-Out)
In der EDV-Welt hat sich in der Projektplanung eine Unterteilung in sieben Phasen durchgesetzt. Die Phasen gliedern sich wie folgt:
(1) Anforderungsanalyse (2) Spezifikation
(3) Programmentwurf (4) Codierung
(5) Qualitätssicherung (6)Dokumentation
(7) Installation, Betrieb und Wartung
Auch beim Software-Life-Cycle wird die zuvor besprochene Unterteilung in Phasen verwendet, wenngleich sie auch manchmal anders heißen.
MS zum Software-Life-Cycle:
EINE PHASE DARF ERST BEGINNEN, WENN DIE VORHERGEHENDE PHASE ABGESCHLOSSEN, DAS ZWISCHENPRODUKT DERER GEPRÜFT UND AKZEPTIERT IST.
Aktuelle Version des SOFTWARE-LIFE-CYCLES:
(1) Planung (2) Analyse
(3) Entwurf (4) Erstellung
(5) Einführung (6) Betreuung
Planungsphase
Hier wird der Informationsbedarf einer zu untersuchenden Organisationseinheit ermittelt und eine Informationsstrategie erarbeitet. Dazu ist es notwendig, die essentiellen Informationen herauszufinden. Informationen sind dann wichtig, wenn sie bei der Erreichung eines Zieles mithelfen. Unter dem Begriff „Informationsprojekt“ wird dabei kein Projekt zur Erstellung eines EDV-Systems verstanden. Informationsprojekte sind Ergebnisse einer ersten, groben Strukturierung einer zu untersuchenden Organisation in Funktionsbereiche.
Dabei werden diejenigen Funktionen in einem Informationsprojekt zusammengefaßt, in denen weitgehend die gleichen Informationsobjekte verwendet werden.
Analysephase
Nun ist es notwendig, die einzelnen Informationsprojekte, sowohl aus Daten-, als auch aus Prozeß-Sicht, weiter zu detaillieren. Folgende Grafik soll dies schemenhaft darstellen. Die Strukturierung erfolgt nach de Marco, mittels Datenflußdiagramm.
Es muß zu jedem Zeitpunkt darauf geachtet werden, daß das Datenmodell und das Prozeßmodell zueinander konsistent sind und bleiben. So müssen also die Regeln der Referential Integrity beachtet werden.
Endziel der Analysephase ist es, festzuschreiben, WAS getan werden muß, um aus den richtigen Anfangsdaten die richtigen Ausgabedaten zu bekommen.
In der Analyse-Phase wird auch die Qualität des zu erstellenden Informationssystems festgelegt.
Die Entwurfsphase
Hier wird festgelegt, WIE das System aufgebaut werden muß, um die richtigen vorhandenen Systemdaten richtig darzustellen. Generell geht es in den Methoden, die dafür herangezogen werden können, darum, das zu entwerfende System in kleine, überschaubare Blöcke, die Module, zu untergliedern. Um die Zusammenhänge zwischen den Modulen klar und eindeutig erarbeiten zu können, werden diese Zusammenhänge graphisch dargestellt. Diese Darstellungen werden STRUCTURE CHARTS genannt.
Die Erstellungsphase
Die Erstellungsphase selbst ist, vorausgesetzt die Phasen zuvor sind alle ordnungsgemäß abgeschlossen worden, eine verhältnismäßig einfache Aufgabe. Beim Vorliegen einer strukturierten Analyse und eines strukturierten Entwurfs sollten hier keine nennenswerten Probleme mehr auftreten. Die Darstellung der Prozeß- und der Datenseite sind so eindeutig klar, daß diese Aufgabe bei Vorgabe entsprechender Systemparameter und bei Verwendung einer entsprechenden Sprache fast vollständig der Computer übernehmen kann. Auch in dieser Phase muß dokumentiert werden. Für die Tests sollten Referenzbeispiele ausgearbeitet werden, an denen die Fehleranfälligkeit besonders gut überprüft werden kann. Unter anderem wird ein Teil des Tests auch für die Projektabnahme durch den Kunden verwendet.
Die Einführungsphase
Die Einführungsphase beinhaltet eine Vielzahl von Aktivitäten, die mit der Erstellung des Informationsystems selbst relativ wenig zu tun haben.
Dazu gehört beispielsweise:
die Schulung der Anwender
die Schaffung der aufbauorganisatorischen und ablauforganisatorischen Voraussetzungen für das einzuführende System
Bereitstellung von User-freundlichen Handbüchern
die Sicherstellung der dafür erforderlichen Infrastruktur
Eine Möglichkeit, um diesen nicht unerheblichen Kostenfaktor unter Kontrolle zu bekommen, ist der möglichst rasche Einsatz von ablauffähiger Software als Kommunikationsgrundlage. Besonders heikle Teile des Programms werden deshalb modellhaft realisiert, um dem Benutzer die Möglichkeit zu geben, sich konkrete Vorstellungen zu machen und etwaige Fehler möglichst früh zu entlarven. Beginn des Prototypings ist ein Modell. Dies stellt also ein Stück ablauffähiger Software dar, das einige Funktionen ermöglicht und mit einigen wenigen Testdaten arbeiten kann. Ein Prototyp ist dann wieder eine Weiterentwicklung.
Unterschied zur fertigen Software:
geringere Softwarequalität höhere Fehlerrate
unrealistische Performance fehlende Dokumentation
Der User ist nun gefordert mit dem Modell oder dem Prototypen zu experimentieren. Der Prototyp kann dann entweder als Grundlage für das endgültige Programmodul verwendet werden, oder er wird kurzerhand ausgebaut, um selbst dann in einer ausgereiften Version als endgültiges Programmodul verwendet zu werden.
Ergänzung
Wie entwickelt man große SW - Produkte
Spezifikation
Das erste Dokument das der Entwickler bekommt, ist das Pflichtenheft des Kunden: eine Beschreibung was der Kunde von dem zu entwickelnden System verlangt. Solch ein Dokument enthält gewöhnlich Fehler, Zweideutigkeiten und Versäumnisse. Folglich ist die erste Aufgabe die der Entwickler ausführen muß, die Umschreibung des Dokumentes in eine Systemspezifikation, welche die Ausmaße des Systems beschreibt.
Das Pflichtenheft
Der erste Schritt ist das Niederschreiben der Proportionen des Systems aus der Sicht des Kunden.
Das Dokument, das zu entwerfen ist, heißt das Pflichtenheft und ist eine Beschreibung des Systems in Wörtern und nicht in irgendeiner technischen Sprache. Generell gilt: die Qualität des Pflichtenheftes hängt vom Kunden selbst ab. Ein Kunde der mit der Technologie und den Begriffen nicht vertraut ist, schreibt ein kurzes Heft in dem die Proportionen nur vage beschrieben werden, während ein anspruchsvoller Kunde, der den Umfang des System selbst festlegt, es einfacher macht, eine Systemspezifikation zu erstellen. Dieser Abschnitt beschreibt all jene Probleme, die vom schlimmst möglichen Pflichtenheft ausgehen. Die beiden Hauptkomponenten des Pflichtenheftes sind Funktionen und Einschränkungen.
Probleme beim Lesen des Pflichtenheftes:
Das Pflichtenheft soll in einer natürlichen Sprache geschrieben sein.
Dies kann oft sehr schwierig sein.
Dieses Heft ist sehr oft von Mitarbeitern geschrieben, die mit den technischen Möglichkeiten nicht vertraut sind, und oft unmögliches verlangen, das aber nicht zu realisieren ist.
Der Kunde weiß selbst nicht was er von dem zu entwickelnden System verlangen soll und schreibt eine Dokumentation die nur vage beschreibt, was das System können soll.
Einige Definitionen aus dem Pflichtenheft
Sätze ohne Aussage/Inhalt (PLATITUDES)
Ein häufig auftretender Fehler des Kunden in seinem Dokument ist es, es mit Platitudes zu "verseuchen". Solche "leere Sätze", die sehr banal sind, sind jedoch oft schwer zu beschreiben. z.
B.: Das System soll benutzerfreundlich sein
Zweideutigkeiten (AMBIGUITIES)
Zweideutigkeiten führen zu Unklarheiten, und es könnte zu einer Fehlentwicklung kommen. Eine Reorganisation erfordert viel Zeit und Geld. Anhand dieses Beispiels kann man dies vielleicht besser erklären:
Entwurfs- & Implementierungsanweisungen
Entwicklungs- & Implementierunganweisungen sind Beispiele für Einschränkungen im Pflichtenheft. Zu viele Einschränkungen können den Entwickler jedoch zu sehr einengen. Man sollte dem Entwickler soviel wie mögliche Lösungswege offen lassen, um so vielleicht bessere Systeme zu bekommen (schnellere Zeiten, weniger Speicherplatz).
Unterlassungen (OMISSIONS)
Die meisten Fehler in einem Pflichtenheft beinhalten Unterlassungen d.h. ein trivial zu scheinender Teil des Systems nimmt plötzlich Ausmaße an, mit dem man nicht gerechnet hat, und das auch nicht im Pflichtenheft genauer beschrieben ist.
Die Systemspezifikation sollte genau beschreiben was geschieht, wenn man Fehler begeht, oder welche Fehlermeldung erscheint. Dies sind die am häufigst auftretenden Fehler in solch einem Dokument.
Mischung der Abstraktionen
Das Beschreiben der Funktionen des Systems kann in verschiedene Abstraktionsebenen aufgeteilt werden.
Einige haben eine höhere und andere eine niedrigere Abstraktionsstufe. In einem Pflichtenheft oder in einer Systemspezifikation sollen beide Stufen der Abstraktion enthalten sein. d.h. wichtigere Sachen genauer beschreiben, und unwichtigere mit einer höheren Abstraktionsstufe.
Die ideale Systemspezifikation
1.
sollte vollständig sein
2. sollte eindeutig geschrieben sein
3. sollte frei von Entwurfs- & Implementierungsanweisungen sein
4. sollte keine Sätze ohne Inhalt beinhalten
5. sollte Funktionen und Einschränkungen getrennt behandeln
6. sollte sortiert sein.
Einschränkungen sind sehr wichtig, können aber beim Verstehen der Funktion oft hinderlich sein. Die ideale Systemspezifikation sollte (mit hinreichenden Querverbindungen dazwischen) Einschränkungen und Funktionen getrennt behandeln. Es ist ebenso wichtig, daß die Spezifikation hierarchisch nach Funktionen geordnet ist. Die Funktionen an der Spitze der Hierarchie sollten eine hohe Beschreibungsstufe haben.
Eine Funktion in einer hohen hierarchischen Ebene sollte wie folgt gegliedert werden:
sie sollte genauer beschrieben werden als eine Funktion unter ihr
es sollte festgehalten werden, welche Daten erforderlich sind
welche Fehler auftreten können
und welchen Effekt die Funktion haben soll
Wenn eine Funktion einen zu großen Umfang annimmt, soll man diese in eine oder mehrere Subfunktionen aufteilen. Diese wieder in Sub-Subfunktionen.
..
(Übersichtlichkeit).
Der Weg zur Spezifikation
1) Lese das Pflichtenheft des Kunden sorgfältig, und schreibe Dir Zweideutigkeiten, Auslassungen und Leersätze heraus.
2) Frage den Kunden was diese Leersätze zu bedeuten haben. Wenn diese jedoch Informationen enthalten (Funktion), müssen sie in die Spezifikation aufgenommen werden.
3) Kläre Auslassungen und Zweideutigkeiten mit dem Kunden und seinen Mitarbeitern.
4) Suche alle Entwurfs- & Implementierungsanweisungen und diskutiere diese mit dem Kunden aus, ob man diese nicht weglassen könnte. Zu klären ist auch, ob es immer notwendig ist, den Kunden zu informieren, wenn man solche Anweisungen weglassen will, wenn diese hinderlich bei der optimalen Systemfindung sind (GELD). Wenn der Kunde und der Entwickler der Meinung sind das gewisse Anweisungen gelöscht werden können, sollten sie das tun.
5) Suche Einschränkungen und Funktionen, und schreibe diese in verschiedenen Teilen der Spezifikation nieder.
6) Untersuche die Funktionen, die im Schritt 5 ausgesondert worden sind, und ordne diese in hierarchischer Reihenfolge.
7) Schreibe die erste Version mit allen Entwurfs- & Implementierungsanweisungen, Einschränkungen und Funktionen.
8) Gib diese Spezifikation den Kunden und bespricht diese mit ihm. Gemäß beinhaltet das Dokument mehrere Fehler. Nach der Besprechung mit dem Kunden schreibe eine neue Spezifikation und gib diese wiederum dem Kunden zur Überprüfung. Dies geschieht solange, bis der Kunde mit der Systemspezifikation vollkommen glücklich ist.
Unterschreiben
Der letzte Schritt ist das Abzeichnen der Systemspezifikation d.
h. der Kunde als auch der Entwickler unterschreiben die Spezifikation des zu entwickelnden Systems, der letzten Version. Wenn dies nicht geschieht besteht die Gefahr, daß der Kunde oder der Entwickler ihre Meinung, in Hinblick auf die Systemspezifikation, ändern und es so zu Zwistigkeiten kommt. Außerdem würde eine Neuüberarbeitung des Dokumentes einen Mehraufwand bedeuten (KOSTEN). Wenn beide unterschrieben haben kann der Prozeß des Systementwurfes beginnen.
Weiterentwicklung der Systemspezifikation
Das Hauptprinzip bei der Entwicklung von Softwareprojekten ist es, Fehler zu suchen und sie zu beseitigen.
Je weniger Fehler die Systemspezifikation aufzuweisen hat, desto früher ist das zu entwickelnde System fertig, und vielleicht noch wichtiger, desto billiger wird die Entwicklung. Fehler, die bis zum Schluß unentdeckt bleiben, können die Kosten für die Entwicklung ins Unendliche steigen lassen. Darum ist es unbedingt notwendig Fehler so schnell wie möglich, wenn möglich noch während der Analyse und Systemspezifikationsentwicklung, zu finden und zu beseitigen. Die Hauptaufgabe eines Systemcheckers ist es, das System zu testen. Unglücklicherweise kann man aber nicht während der Entwicklung testen, sondern erst danach, wenn der Programmcode verfügbar ist. Folglich braucht man eine andere Möglichkeit.
Eine der leistungsfähigsten Methoden ist der Systemspezifikations-Rückblick:
Bei kleineren Projekten ist das ganze nur ein zwangloser Rückblick von zwei bis drei Mitarbeitern. Dabei besteht das Team aus einem Analytiker, der für die Spezifikation verantwortlich ist, und dem Projektleiter. Normalerweise wird der Rückblick nach einer Liste von Fragen abgearbeitet, die in diesem Stadium des Projektes gestellt werden sollten.
Checkliste
Sind die Anforderungen klar formuliert ?
Jede Anforderung sollte auf Klarheit untersucht werden. Zu untersuchen ist aber auch, ob Sätze irgendwie verschachtelt sind. Gibt es Sätze mit mehreren Objekten und Subjekten ?
Gibt es Sätze mit einer Vielzahl von Fürwörtern ? Jede Anforderung sollte unter diesen Gesichtspunkten untersucht werden.
Sind die Anforderungen umgangssprachlich geschrieben ?
Wie schon erwähnt, sollte in den Sätzen so wenig wie möglich mit Fachausdrücken gearbeitet werden, um so eine höhere Verständlichkeit zu erreichen.
Sind zweckmäßige Anforderungen vom Pflichtenheft zur Spezifikation nachvollziehbar ?
d.h. der Entwickler muß das Pflichtenheft des Kunden so durchsuchen und filtern, daß Funktionen und Anforderungen deutlicher und eindeutig herauskommen.
Sind die Anforderungen technisch durchführbar ?
Ein Hauptproblem, das im Pflichtenheft immer wieder auftaucht, ist die Undurchführbarkeit einiger Anforderungen.
z.
B.: der Kunde will ein System das schnell antwortet. Will aber nicht zuviel Geld für Arbeitsspeicher ausgeben.
Dies sind zwei Dinge die sich gegenseitig ausschließen. Oft kann das Team die technische Realisierbarkeit nur anhand eines Simulationsprogrammes schätzen.
Sind die Anforderungen prüfbar ?
Dies ist die Frage, die Zweideutigkeiten, eine Menge von Unkomplettheiten und Sätze ohne Inhalt aufspürt.
Am Ende des Softwareprojektes muß man eine Reihe von Abnahmetests durchführen. Jede Annahme testet einen anderen Bereich des Systems. Diese Tests entstanden aus der Spezifikation heraus. Jede Funktion und Einschränkung des Systems sollte vom Review-Team genügend getestet werden.
Welche Tests sind für jede Anforderung erforderlich ?
Es gibt eine große Vielzahl von Testmöglichkeiten für Softwareprojekte. Die Programmcodes könnten kontrolliert werden, ob die Funktionen richtig realisiert worden sind.
Die Version könnte auf einem langsameren System getestet werden ...
Es ist nur wichtig, daß die Art des Testes während der Rückschau bekannt ist. Dies ist wichtig, da manche Tests im Echtzeitbetrieb laufen und eine spezielle Hard- bzw. Software benötigen.
Gibt es irgendwelche Entwurfs- und Implementierungsanweisungen ?
Entwurfs- oder Implementierungsanweisungen, die den Entwickler zu sehr einschränken, sollten in dieser Stufe spätestens entfernt werden. Einige werden natürlich bleiben: oft ist es notwendig, ein neues System mit einem bereits vorhandenen System zu kombinieren: d.h. der Faktor Dateistruktur kann vom Entwickler nicht selbst geändert werden.
Ableitung des Systems und Abnahmetest
System- und Abnahmetests ist der kritischste Teil bei einem Softwareprojekt. Ein System, das solch einen Test nicht besteht, kann die Anforderungen des Kunden nicht erfüllen.
Sollte es einem Fehler gelingen auch diese Stufe zu überspringen, hat dies mit sehr großer Wahrscheinlichkeit große Auswirkungen auf die Kosten der Entwicklung.
Dies hat drei Gründe:
Der Fehler erfordert einen riesigen Aufwand der Respezifikation, des Redesigns und des Reprogrammierens, um diesen Fehler wieder auszubessern.
Wenn ein Test fehlgeschlagen ist, könnte der Kunde darauf bestehen auch andere Tests wiederholen zu lassen. Der Grund für die Testwiederholung liegt darin, ein falsches Ergebnis könnte die in der Hierarchie darunterliegenden Funktionen beeinflußt haben.
Danach muß noch mal geklärt werden, ob nicht andere Fehler übersehen worden sind.
Man kann sich ungefähr ausmalen wieviele Tests dies bei einem großen Projekt sein könnten (Tausende Tests).
Als Folge eines Fehlers, muß man den gesamten Testvorgang neu starten.
Für manche mag es danach aussehen, daß in diesem Stadium es äußerst früh ist um mit dem Testen zu beginnen.
Es gibt jedoch eine Menge guter Gründe dafür:
Warum so früh testen ?
Ein Grund wurde schon genannt. Wenn man für dieses System einige spezielle Hardwaremittel braucht, diese aber erst bestellen muß, hätte man eine Standzeit, die aber Geld kostet.
Ein Softwareprojekt entsteht nicht in Isolation. Falls der Entwickler eine kleinere Firma ist, gibt es eine Reihe von anderen Projekten die gleichzeitig ablaufen.
Die Aufwandschätzung für solch ein Softwareprojekt kann ein sehr komplizierter Prozeß werden und ist keine beneidenswerte Arbeit des Managers. Es ist notwendig, so früh wie möglich eine möglichst genaue Aufwandschätzung durchzuführen.
Für viele Projekte ist der Abnahmetest zusammen mit der Systemspezifikation, die vertraglichen Dokumente. Manche Kunden ziehen es vor, einen Abnahmetest zu lesen, als eine Systemspezifikation, mit dem Vorteil, daß sie sich einen Überblick verschaffen, was das System tun wird können. Dieses Vertragsdokument sollte so früh wie möglich erstellt werden.
Die Entwicklung des Systems und Abnahmetests geschehen im gesamtem Softwareprojekt.
Man gibt, entweder kurz danach oder während der Spezifikationsphase, die genauen Testergebnisse aus.
Der Entwickler hat zwei Typen von Tests vorzubereiten:
Systemtests
Abnahmetests
Diese Tests sind sich sehr ähnlich. Jedoch ist ihr kleiner Unterschied sehr entscheidend.
Der Systemtest wird mit den Umgebungsbedingungen des Entwicklers durchgeführt, während der Abnahmetest in dem System gemacht wird, indem es laufen soll. Beim Abnahmetest wird automatisch der Kunde mit einbezogen, der als Zeuge fungieren soll, und außerdem muß er die abgeschlossenen Testdokumente signieren. Der Entwickler wählt Sets von Systemtests aus und daraus entwickelt er Subsets für die Abnahmetests.
Der Kunde ist jedoch nur an Tests interessiert, die das externe Verhalten des Systems ausgeben.
Ergänzung
Pflichtenheft (customer statement of requirements): Wird vom Kunden alleine erstellt.
Spezifikation wird vom Kunden und vom Systemanalytiker gemeinsam in Benutzersprache verfaßt.
In der Spezifikation enthalten:
Funktionen des Systems - DfD, Dekomposition
Randbedingungen - Zeit- (für Suche 0,4 sec) und Speicherverbrauch (Programm < 2 MB)
Benutzeroberfläche (Liste aller Masken)
Schnittstelle zu anderen Systemen
In der Spezifikation nicht enthalten:
Banalitäten = Platitüden = bla bla bla
Mehrdeutigkeiten wie „meistens ...
“, „verarbeiten ...“ und „normalerweise ...
“ ...
Implementierungs-, und Entwurfsanweisungen (z.B.: in C++ geschrieben)
Allgemeine Eigenschaften:
die Spezifikation muß eindeutig sein
immer Status anzeigen
viele Bilder
Masken
Übergangsgraphiken
Prüfungen für Inkonsistenzen
Graphische Benutzeroberfläche
Einleitung
Ein Windows-Entwickler kann bis ins Detail das Verhalten und Aussehen seiner Anwendungen selber festlegen.
Ihm steht die ganze Leistungsfähigkeit des Systems zur Verfügung, um blendende, elegante und vorallem nützliche Anwendungen zu schaffen.
Wie man es besser nicht macht
Bevor ich einige brauchbare Methoden für den Entwurf der Programmoberfläche vorstelle, möchte ich an einigen abschreckenden Beispielen zeigen, wie man es besser nicht tut.
Folie 1
Folie 1 zeigt die Maske, die zur Datenerfassung einer Versicherung dient. Die Augen finden keinen Ruhepunkt, die Anordnung ist einfach undurchschaubar; eine Ausrichtung ist praktisch nicht vorhanden.
Welche Daten gehören zusammen ?
Sind irgendwelche Bedienelemente von einem Anderen abhängig ?
Welches Feld ist das Wichtigste ?
Lassen sich die Zahlen in der unteren Reihe bearbeiten ?
Was bedeuten sie überhaupt ?
Folie 2
Folie 2 sieht nicht gerade besonders gut aus, denn die Reihenfolge der Arbeitsgänge ist schlechter. Die Maske zeigt an, ob ein bestimmter Versicherungsschutz für den Versicherten vorliegt.
Das statische Textfeld am unteren Rand gibt völlig überflüssige Anweisungen, denn nirgends läßt sich die Auswahl „NEW APPLICATION“ oder „UPDATE APPLICATION“ treffen.
Folie 3
In Folie 3 legte der Entwickler großen Wert auf die Ausrichtung der Bedienelemente. Bei uns ist es üblich, von links nach rechts, und von oben nach unten zu lesen. In dieser Maske muß der Anwender die Felder rechts ausfüllen und dann zur linken Seite wechseln, um die gewünschte Aktion durchzuführen.
Außerdem sind die Eingabefelder alle gleich lang, obwohl schon der erste Blick genügt, um festzustellen, daß die typischen Eingaben in die jeweiligen Felder unterschiedlich lang sein werden.
Folie 4
Der Entwickler der Eingabemaske in Folie 4 hat eine Vorliebe für verschachtelte Menüs.
Wenn es tatsächlich so viele Menüoptionen geben muß, so ist es besser, sie in einem Dialog anzubieten.
Es ist natürlich auch nicht besser so zu gestalten, wie es Folie 5 zeigt.
Folie 5
Diese Folie ertrinkt fast in Optionsschaltflächen. Sicher ist es hier besser, ein Pull-Down-Menü zu verwenden (Listbox oder Combobox).
Folie 6
Folie 6 ist ein weiteres Beispiel für rivalisierende Schaltflächen. Was ist der Unterschied zwischen APPLY und ACCEPT ? Da mit APPLY keine sichtbare Änderungen verbunden sind, ist diese Schaltfläche sowieso überflüssig.
Wichtig ist es, daß sich die Programmierer nicht nur mit dem Codieren befassen, sondern auch mit dem Layout. Sogar bei erfahrenen Entwicklern ist dieses Problem schon aufgetreten. Sie haben mit bestimmten Anforderungen an das Projekt angefangen, einer groben Spezifikation, aber sich kaum mit dem Auftraggeber über die Gestaltung der verschiedenen Masken (dem Layout) auseinandergesetzt. Sobald die ersten Probleme bezüglich Maske auftauchen, stellen die Entwickler fest, daß einige dieser Probleme ihre Ursache in der Programmstruktur haben. Ihre Behebung würde nicht nur Änderungen in der Programmstruktur nach sich ziehen, sondern auch in anderen Bereichen (Datenbankstruktur); sie müßten möglicherweise fast von vorne wieder beginnen. Der Ausdruck „QUICK AND DIRTY“ ist oft nicht fehl am Platz.
Der Entwickler soll sich wirklich Zeit für die Gestaltung der Masken nehmen.
Die Analyse
Spätestens hier ergibt sich die Frage „Wer ist mein Kunde“ ? Wenn man eine Anwendung innerhalb einer Firma entwickeln soll (Bsp.: XESAS), so muß man den direkten Kontakt zum Anwender suchen. Nur so kann der Anwender wirklich das haben, was er will. Mit dem Anwender die grobe Spezifikation zu besprechen ist sicher sinnvoll. Wenn die Spezifikation dem Anwender zusagt, so beginnt der Prozeß des Prototypings.
Der fertige Prototyp wird dann von einigen ausgewählten, nicht eingewiesenen Anwendern getestet. Auch hier können noch nicht umständliche Änderungen vorgenommen werden. Die Entwicklung wird dann weitergeführt bis zur ALPHA-Version (eine reine Testversion). Auch andere Entwickler oder Anwender können ihre graphischen Vorstellungen einbringen.
Weiters stellt sich die Frage „Kennt sich der Anwender mit PC-Programmen aus“ ? Wenn man Anwendungen für Neulinge entwickelt, darf man nicht vergessen diverse Hilfe-Funktionen zu berücksichtigen. Am besten konzentriert man sich darauf, daß die Anwenderschnittstelle so gestaltet ist, daß Sie diese am liebsten gar nicht weitergeben möchten.
Es ist auch nicht unwesentlich, wie intensiv die Anwendung benutzt wird. Wenn man den ganzen Tag damit beschäftigt ist, treten die kleinsten Entwurfsschwächen schnell zu Ärgernissen auf. Wenn man sich nicht so intensiv damit beschäftigt, soll man dem nicht so kritisch beiwohnen.
Sobald die Hauptziele der Anwendung festgelegt sind, ist es essentiell die Arbeitsabläufe zu fixieren. Vielleicht kann man ähnliche Arbeitsabläufe verwenden. Möglicherweise kann man manuelle Vorgänge automatisieren und somit Zeit und Geld sparen.
Sich die genaue Reihenfolge der Funktionen zu überlegen ist ebenfalls wichtig. Man hat ja schließlich nicht vor, dem Anwender überflüssige Programmzustände aufzuzwingen.
Überlegungen zum Entwurf
Die Amerikaner kennen das Schlagwort KISS - Keep It Simple, Stupid. Eine bessere Interpretation wäre Keep It Simple and Straightforward, also „einfach und zielsicher“. Sobald man weiß, welche Datenfelder und Verzweigungen man in der Anwendung braucht, sollte man überprüfen, was wirklich notwendig ist. Beschriftungen, statische Texte, Kontrollfelder, Gruppenrahmen und Optionsschaltflächen verstellen häufig den Blick auf die wirklich wichtigen Teile einer Eingabemaske und verbrauchen doppelt so viel Platz wie Nutzdaten.
Mit 2 einfachen Tricks erhöht man die Übersicht der Masken, nämlich:
durch eine überlegte Ausrichtung der Bedienelemente in den Masken
durch die Einheitlichkeit des Maskenaufbaus in der gesamten Anwendung.
Texte richten sich im allgemeinen nach dem linken Rand, bis auf die zentrierten Meldungen in den Meldungsfenstern, und Zahlen werden nach dem rechten Rand ausgerichtet.
Zu dem einheitlichen Erscheinungsbild der Masken gehört die gleiche Größe und Anordnung der Bedienelemente und der Beschriftung, gleiches Verhalten und gleicher Stil. Es ist nicht effizient eine Befehlsschaltfläche in der ersten Maske riesengroß und gleich in der nächsten Maske diese zu klein zu gestalten. Wenn man mittels PUSH-BUTTON eine weitere Maske öffnen kann, so soll diese Maske den selben Namen wie der PUSH-BUTTON haben. Wenn sich bestimmte Datenfelder in mehreren Masken wiederholen, wäre es sinnvoll, diese immer an der gleichen Stelle zu positionieren.
Um all diese Kriterien zu erfüllen gibt es einige grundlegende Dinge für einen einfachen Entwurf:
Anordnung der Daten in funktionalen Gruppen. Alle Informationen, die der Anwender zur Abwicklung eines bestimmten Vorganges benötigt, gehören in dieselbe Maske.
Anordnung der Felder, die am häufigsten benutzt werden, sodaß man sie gleich sieht.
Zusammenfassung der zusammengehörigen Felder in Unterguppen.
Gleichmäßige Abstände zu den verschiedenen Feldern.
Die Gestaltung der Anwendung
Sobald man die Funktion der Anwendung festgelegt hat, geht es um die Frage, wie viele Fenster man dem Anwender präsentiert.
Alle Windows-Anwendungen öffnen zuerst ein Hauptfenster, von dem aus Teilaufgaben in MDI-Fenster oder Dialogfenster abgewickelt werden. Es ist essentiell MDI-Fenster zu benutzen, wenn man in der selben Ebene mehrere Vorgänge abwickeln möchte (Bsp.: Datentausch zwischen Dokumenten). MDI-Fenster sind auch in ihrer Größe beeinflußbar.
Dialogfenster haben normalerweise eine feste Größe und eignen sich somit auf Felder mit festgelegten Datenmengen.
Die Anwenderschnittstelle bildet den Ausgangspunkt für jede Aktion, die ein Anwender durchführen kann.
Die Windows-Anwendung erhält die Befehle des Anwenders über:
Menüs
Befehlsschaltflächen
Symbole
OLE-Verbindungen (Object Linking and Embedding)
Die Funktionsschaltflächen sind von Programm zu Programm verschieden. In Word und Excel sind dies beispielsweise Befehlsschaltflächen mit denen Programmfunktionen angeboten werden; die aber auch über Menüs angesprochen werden können. Der Anwender kann seinen bevorzugten Zugriff individuell auswählen.
Die Anordnung der Menüs und Menüunterpunkte will sorgfältig überlegt sein. Die ersten Gedanken darüber hat man sicher schon in der Spezifikation gemacht; hier ist es aber höchste Zeit die genauen Menüoptionen festzulegen. Anschließend faßt man dann ähnliche Menüpunkte in Gruppen zusammen.
Die Anordnung der anderen Menüpunkte hängt von einer Reihe von verschiedenen Faktoren ab:
von der Häufigkeit der Benutzung
von der Wichtigkeit
von den Arbeitsabläufen
von der Reihenfolge
Folie 7
Folie7 zeigt ein etwas verwirrendes Menü; und die verbesserte Version. Das Sprichwort „Weniger ist oft mehr“ oder „In der Kürze liegt die Würze“ trifft hier voll zu.
Einige typische Bedienungsfehler lassen sich schon durch die Gestaltung der Masken vermeiden:
Alle Menüpunkte, deren Auswahl zu Schäden führen könnte, zu sperren, ist sicher wichtig.
Der Griff zu Auswahllisten ist sicher der richtige. Den Benutzer sooft als möglich auswählen zu lassen, verhindert unnötige Schreibfehler.
Vor jeder kritischen Situation den Anwender noch einmal bestätigen lassen (Bsp.
: Hiermit beenden Sie Ihre Windows-Sitzung).
Folie 8
Folie 8 ist ein Beispiel für feldspezifische Datenvalidierung. Die Anwendung zeigt sofort eine Fehlermeldung an, wenn der Anwender eine ungültige Staatenabkürzung eingibt und mit dem Cursor das nächste Feld anklickt.
Wenn der Anwender ein Feld anklickt, das er nicht bearbeiten darf, genügt ein simples Pieps als Hinweis.
Schrift und Farbe
Einheitlichkeit ist der Schlüssel für den effektiven Einsatz von Schriftarten und Farben. Falls die Systemschrift zu langweilig oder zu häßlich erscheint, kann man ohneweiters auf eine andere Schriftart ausweichen.
Diese sollte aber leicht lesbar und nicht zu klein bzw. zu groß sein. Alles in Großbuchstaben zu schreiben ist nicht effizient, da man dies nicht so gut und auf den ersten Blick lesen kann. Eine Ausnahme wäre beispielsweise die OK-Taste.
Um die Aufmerksamkeit des Anwenders auf sich zu lenken, sollten ebenfalls verschiedene Farben für die Maskengestaltung herangezogen werden. Die Farben sind aber eher sanft und nicht grell zu wählen.
Farben können auch als Informationsträger verwendet werden. Beispielsweise macht man gesperrte Felder grün und die fehlerhinweisenden Felder rot.
Ergänzung
Einheitlichkeit, Richtlinien (Kontrolle)
Ergonomie (Arbeitsrichtung von links nach rechts und von oben nach unten)
natürliche Reihenfolge
an bestehende schriftliche Formulare halten
Farben: auf großer Fläche keine grellen Farben und nicht zu viele Farben
Felder: Muß-, Kann- und berechnete Felder in anderen Farben
Schriften: nicht mehr als zwei verschiedene
Gruppierung
nicht zu viele Steuerelemente
PB sollten am Aussehen von Formularen etwas ändern (Checkbox)
Bilder für PB
Unterscheidung: aktiv - inaktiv
Probleme: Formulare mit zuwenig Platz
Funktionen: Menü, PB oder Hotkeys
Hilfe, Statuszeilen, Warnton
Defaults
einheitliche Benennung
Qualifikation des Anwenders beachten
Datenflußdiagramme
Einleitung
Das Datenflußdiagramm zeigt die Prozesse und den Fluß der Daten durch diese Prozesse.
Es gibt verschiedene Möglichkeiten es einzusetzen, von schwierigen Geschäftsbeziehungen bishin zu Softwareprogrammabläufen oder gar nur einzelner Unterprogramme.
Man bezeichnet ein Datenflußdiagramm auch als erste Stufe eines strukturierten Softwaredesigns, da es den gesamten Datenfluß durch das System bzw. Programm zeigt.
Es ist in erster Linie ein System-Analyse-Werkzeug, welches man für die Darstellung der Grundbestandteile und den Datenfluß durch diese benötigt.
Definition und Komponenten eines Datenflußdiagramm
Bestandteile eines Datenflußdiagramm (4 Grundkomponenten):
1) Datenfluß:
Pfeil mit Name darüber, zeigt den Datenfluß durch das System
2) Prozeß:
Abgerundetes Rechteck mit Namen des Prozesses (sprechender Name!)
Keine andere Information über den Prozeß in Datenflußdiagramm
3) Data Store:
Name zwischen zwei waagrechten Strichen, repräsentiert ein lokales File in das entweder Daten eingelesen werden, oder von dem Daten gelesen werden.
4) Terminator:
Rechteck mit Namen, gibt die Herkunft (Source) bzw. den Empfänger (Sink) der Daten an. Doch sie werden meistens nicht in die Datenflußdiagramme eingezeichnet.
Auf der Folie sehen wir ein Beispiel eines Datenflußdiagrammes für den Ablauf einer Kundenbestellung.
Zur Folie:
Wenn ein Auftrag einlangt, wird der Kunde überprüft (Existenz, Kontostand, ...).
Nun werden alle Produkte auf der Bestellung überprüft, ob sie verfügbar oder lieferbar sind. Treten hier Unzulänglichkeiten auf, wird ein Lieferrückstand erzeugt.
Schlußendlich wird eine Bestellung erzeugt und der Kundenauftrag mit dem Lieferdatum versehen.
Ein Datenflußdiagramm zeigt den Datenfluß in einem konkreten Prozeß, der wieder aus mehreren Unterprozessen besteht, die man wieder in eigene Datenflußdiagramme zerlegen kann.
So kann man ein System bis in die tiefsten Ebenen zerlegen. Also ein Datenflußdiagramm gibt uns keine Detaile über den Datenfluß in den Unterprozessen die nur als abgerundetes Kästchen dargestellt werden, doch dies kann man wieder zerlegen und so mehr über den Datenfluß erfahren.
Aber wie genau soll man ein System zersplitten?
Man soll so weit zersplitten, bis ein Prozeß durch Worte auf einer Seite vollständig beschrieben werden kann, ohne das Informationen verloren gehen.
Auch in einem Datenflußdiagramm sollte man Einschränkungen treffen, es sollten nie mehr als 12 Prozesse dargestellt werden, da es sehr schwer zu lesen wird und die gewünschte Übersichtlichkeit verloren geht.
Die ideale Anzahl wären 6-7 Prozesse.
Prozeßspezifikation
Wenn ein Datenflußdiagramm während der Strukturanalyse entwickelt wird, entwickelt man auch eine Prozeßspezifikation um zusätzliche Information über das System unterzubringen.
Sie definiert wie die Daten in und aus dem Prozeß fließen und was für Operationen mit ihnen durchgeführt werden.
Eine Variante ist eine Aktionsliste, die ähnlich einem Programm aufgebaut ist.
Data dictionary AUSLASSEN
Gane and Sarson AUSLASSEN
Schlußkommentar
Ein Datenflußdiagramm ist ein sehr wertvolles Werkzeug für die Prüfung des Dokumenten- bzw. Datenflusses in komplizierten Systemen.
Es gibt jedoch auch viele Fälle, wo ein Datenflußdiagramm falsch eingesetzt wird bzw. immer wieder Fehler auftreten, besonders bei Querverbindungen (Cross-Checking), da der Input und der Output eines Datenflußdiagrammes oft inkonsistent ist. Und ist das Programm einmal geschrieben, so ist es sehr umständlich, die Fehler auszubessern. Doch heute gibt es schon die Möglichkeit ein Datenflußdiagramm mit dem Computer zu erstellen, der das System auf Inkonsistenz überprüft.
Control Flow Model
Im Gegensatz zum Datenflußdiagramm hat man beim Control Flow Model die Möglichkeit den Datenfluß ereignisorientiert zu gestalten.
Ereignisse sind wie Boolean Variablen (true or false), oder ein konkretes Ereignis (leer, verstopft, voll).
Funktionale Dekomposition
Funktionale Dekomposition ist eine Strategie, Probleme in Unterprobleme (Sub-Components) zu zerstreuen. Diese Unterprobleme werden wieder in Unterprobleme, also in Unter-Unterprobleme (Sub-Sub-Components), zerlegt. Dies wird solange fortgesetzt bis das unterste Level der Detailierung erreicht wurde.
Konkretes Beispiel:
Lies eine Serie von Spannungen ein und bilde das Maximum, Minimum und den Durchschnitt.
Da die ersten zwei Punkte schon auf der niedrigsten Stufe sind, können sie nicht mehr in noch einfachere Bestandteile zerlegt werden.
Somit kann man nur mehr den Durchschnittswert noch weiter zerlegen.
Das ergibt folgendes Design:
einlesen einer Serie von Spannungen
errechne das Max
errechne das Min
errechne die Summe
dividiere die Summe durch die Zahl der eingelesenen Spannungen.
Am Ende werden die einzelnen Teillösungen der Teilprobleme wieder zu einem
| Anmerkungen: |
| impressum | datenschutz
© Copyright Artikelpedia.com
