Artikel pedia
| Home | Kontakt | Artikel einreichen | Oberseite 50 artikel | Oberseite 50 autors
 
 


Artikel kategorien
Letztes fugte hinzu
    Ms-access

   Instrumentation + schnittstellen

   Pc tuning - volle kraft voraus für ihr system

   Informatorische grundlagen

   Javascript

   Interne sortieralgorithmen - der kern der sache

   Plotter und sonstige drucker

   Frage 20 (rössl priska)

   Internet - programmierung

   Monitore

   Semesterarbeit und spezialgebiet für informatik

   Erörterungs zum thema

   Inhaltsverzeichnis

   Einführung in die entwicklung ganzheitlicher informationssysteme:

   Titel dokument
alle kategorien

  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

Suchen artikel im kategorien
Schlüsselwort
  
Kategorien
  
  
   Zusammenfassung Der Vorleser

   sachtextanalyse

   interpretation zwist

   Fabel interpretation

   literarische charakteristik

   interpretation bender heimkehr

   felix lateinbuch

   interpretation der taucher von schiller

   textbeschreibung

   charakterisierung eduard selicke
Anmerkungen:

* Name:

* Email:

URL:


* Diskussion: (NO HTML)




| impressum | datenschutz

© Copyright Artikelpedia.com