5.3.4 Sollkonzept
Das Sollkonzept ist so zu gestalten, daß es gleichzeitig als Programmvorgabe dienen kann. D.h. es muß alle Unterlagen, die für das Schreiben und Testen des gesamten Programmsystems benötigt werden, enthalten. Die Erstellung muß vor Beginn der Programmierung abgeschlossen sein.
Das Sollkonzept muß vollständig, übersichtlich, eindeutig und - darauf ist besonderer Wert zu legen - für alle im Projektteam beteiligten Sachbearbeiter verständlich sein.
Für die sachliche Richtigkeit des Sollkonzeptes tragen die Projektmitglieder Fachabteilung, für die EDV-technologischen die Systemanalytiker und Programmierer die Verantwortung.
Im einzelnen enthält das Sollkonzept folgende Teile:
- Verfahrensbeschreibung, zusammenfassend verbal. Sie wird aus dem Grobkonzept übernommen, ggf. modifiziert, um insbesondere der Unterrichtung betroffener Fachabteilungen
und der Bediener zu dienen.
- Gesamtdatenflußplan (DFP) mit Ergänzungen und derselben Aussagefähigkeit wie bei "Ist-Analyse" unter 5.3.1 dargestellt; dient der übersichtlichen Darstellung
des Gesamtvorhabens, insbesondere seiner Schnittstellen und Einbindung in den Betrieb. (FileMan-Datei)
- Formulare bzw. Dateien
- Datennamen mit Wertebereichen und ggf. Schlüsselbedeutung
- Ausführliche Verfahrensbeschreibung. Sie ergänzt die Unterlagen zu vollständigen Programmiervorhaben. Besonders wichtig ist die Detailgliederung der Programme in Module/Programmbausteine unter Berücksichtigung der Programmierrichtlinien festgelegt
werden. Hierzu ist die gewünschte Funktionalität in sog. Struktogrammen (Nassi-Shnyderman-Diagrammen) auf dem Wege schrittweiser Verfeinerung (top down design) festzulegen. Für
jedes Modul muß die Benutzbarkeit von FileMan/Kernel utilities geprüft werden (bottom up construction).Alle Punkte müssen berücksichtigt sein, Struktogramme sind vorgeschrieben, generell ist formatierte Darstellung empfehlenswert (FileMan), freie Darstellung zugelassen:
- Geräte, Basissoftware und Netz-Schnittstellen (FileMan)
- Ersterfassung von Stammdateien oder Datenübernahme (ggf. mit organisatorischen Implikationen)
- Prüfungen bei der Datenerfassung, Plausibilitätskontrollen (FileMan)
- Unterteilung in Programme/Module (Struktogramme)
- Verarbeitungslogik (Struktogramme)
- Verarbeitungszeiten und Verarbeitungsrhythmus, periodische Arbeiten (FileMan)
- Datensicherung, Archivierung (FileMan)
- Datenschutz (FileMan)
- Wartung und Änderungsdienst nach Inbetriebnahme (FileMan)
- Datenbeschreibung: In dieser Phase (d.h. vor Beginn der Programmierung) werden definitiv festgelegt:
Dabei ist verbindlich, daß
- Namen für Datei, Satzart und Dateninhalt nur ein einziges Mal pro Projekt vergeben werden,
- die Dateibeschreibung einen Verweis auf vorkommende Daten,
- die Daten mit sämtlichen erlaubten Inhalten und deren Bedeutungen nur ein einziges Mal pro Projekt beschrieben werden.
Diese Festlegungen sind Voraussetzungen für die vorgeschlagene Form der "Sammlung" (s. 6.1.3)
- Ein-/Ausgabematrix:
Pro Projekt muß eine Gesamt-E/A-Matrix in formalisierter Form erstellt werden, die in der einen Koordinate die Daten, in der anderen die Formulare/Masken enthält, in der die Daten
verändert werden. Diese formalisierte E/A-Matrix wird als Teil des Datenlexikons in VC/RE automatisch angelegt.
Erweitert man die Matrix an den Schnittpunkten um Verweise auf die Entscheidungs- bzw. Verarbeitungslogik, kann auf gesonderte Darstellung der Verarbeitungslogik verzichtet werden. (FileMan!)
- Programmnachrichten:
Es ist verbindlich, daß sämtliche Programmeldungen durchnumeriert und via "Sammlung" (s. 6.1) in das Bediener- und Anwenderhandbuch aufgenommen werden.
Programmnachrichten sollten mehrsprachig sein. Die entsprechende Funktion in FileMan ist zu nutzen (auch wenn man die Nachrichten zunächst nur in einer Sprache formuliert).
