+ Programm ist nach Datenbank und Berechnungsteil gegliedert.

+ Module sind ziemlich abgeschlossen mit klaren Schnittstellen (klein oder groß, aber gut dokumentiert) und da. mit getrennt änderbar; der Sourcecode ist gut dokumentiert.

+ Die Datenbank enthält sehr viele Konfigurationsdetails.

+ Der Aufbau hat eine Struktur, der Pseudocode für die Unterprogramme ist zirka eine Seite lang.

+ Schnittstellen werden austauschbar gehalten, zum Beispiel wurde über die SQL-DB eine OODB-Schicht gelegt.

+ Die Struktur ist modular; Masken, Datendeklaration und Code werden getrennt verwaltet.

- Die Struktur ist mangelhaft (ein "Verhau").

- Viele "Verstrickungen" erschweren das "Eindenken".

- Es gibt zu wenige allgemeingültige Funktionen.

- Änderungen rufen Seiteneffekte hervor, der Datenfluß läuft über globale Variablen, wer welche Variablen benutzt, ist nicht dokumentiert.

- Das Konzept der einzelnen Schichten war schlecht.

- Einzelne Module haben eine schwierige Logik, es wurden Pointer sowie Eigenheiten der jeweiligen Sprache benutzt.

Werkzeugeinsatz

+ Es wurde viel mit Tools generiert.

+ Durch die Verwaltung von Masken sind Änderung und Erstellung leichter durchführbar, Transaktionen lassen sich verknüpfen.

+ Es gibt einen guten Versionenzyklus: Die Datenbank wird automatisch generiert; automatisch erzeugt werden auch Scripts zur DB, die die Daten umwandeln.

+ Durch das CASE-Tool werden sämtliche Querverbindungen der Module komplett erfaßt und transparent gemacht.

- Das Konvertierungsprogramm wurde von einem externen Mitarbeiter in einer von ihm selbst entwickelten Programmiersprache geschrieben; dieser Mitarbeiter hat die Firma inzwischen verlassen.

- Datendefinition bei Attributänderungen findet noch per Hand statt.

- Die Funktionsbeschreibungen lassen sich nicht kopieren, es müssen jeweils Teile gelöscht und neue eingegeben werden.

Tabellensteuerung

+ Man kann fast alles konfigurieren; bei ganz anderen Geräten geht es allerdings nicht reibungslos, weil da noch andere Stellen beteiligt sind.

+ Einige Funktionen sind sehr variabel, Änderung (zum Beispiel Sätze) müssen oft nicht im Programm gemacht werden, es gibt viele Tabellen.

+ Alle Größen, die sich verändern können, sind in Tabellen gespeichert.

+ Die Programmsteuerung ist teilweise in externen Tabellen angelegt; hier können die Fachabteilungen selbst Programmänderungen durchfuhren.

Dokumentation

+ Die Dokumentation ist stark strukturiert und ausführlich, Funktionen sind überschaubar, keine nimmt mehr als zwei Seiten in Anspruch.

+ Die Form entspricht einer Sammlung von Specs.

- Die Dokumentation ist sehr komplex, umfangreich und für eine Person schwer überschaubar.

- Es handelt sich um ein Sammelsurium von (zum Teil uralten) Programmen ohne Dokumentation, was bereits bei kleinen Änderungen unerwartete Folgen hat.

Richtlinien

+ Jeder hält sich an Standards, das wird erleichtert durch Muster und Programmierrahmen.

+ Konventionen werden größtenteils eingehalten.

+ Grundlegende Anforderungen an die Programmierung wurden erfüllt (zum Beispiel Auslagerung von Werten oder Arbeit mit Include Files).

- Viele halten sich nicht an die Rahmenbedingungen. Am Anfang wurden viele Werkstudenten eingesetzt, die noch dazu aus Zeitmangel schlecht betreut wurden. Es herrschte kein einheitlicher Programmierstil, die Regeln waren noch nicht ausgearbeitet.

- Jeder macht doch eigene Programme und Vorlagen.

Methodisches Vorgehen

+ Alles basiert auf einem zentralen Datenmodell.

+ Im eigenen Teilprojekt wurde bei der Entwurfsmethodik auf Änderbarkeit geachtet. Das Gesamtprojekt ist jedoch sehr viel komplexen, und verschiedenste Systeme müssen miteinander arbeiten, was die Änderbarkeit behindert.

+ Man hielt sich an Vorgehensmodelle (Methode, Phasenmodell).

+ Die Abstraktion ist sehr hoch.

- Der objektorientierter Ansatz ist noch nicht bis in die Verfahrenstechnik vorgedrungen.

Prozeß

+ Man nahm sich Zeit, um die Änderbarkeit im Entwurf zu berücksichtigen.

+ Es wurde in irgend einer Form spezifiziert.

- Mehrere Firmen arbeiten zusammen, alles muß abgesprochen werden.

- Es gab wenig Zeit für sauberes Design, was das System wenig änderungsfreundlich macht.

- C + + ist für ein großes Projekt mit wenig C + + -Expertise nicht geeignet. Zum Beispiel sollte die Typenkontrolle strenger sein, als sie bei vielen Entwicklern gehandhabt wird.

Anforderungen vom Anwender

+ Vom "Auftraggeber" wurde die Forderung nach Änderbarkeit explizit betont.

+ Die Anforderung nach "Zusammenarbeit" von PC und Host macht eine gute Modularisierung notwendig.

- Die fachliche Komplexität ist nicht änderungsfreundlich.

- Fachliche Zusammenhänge sind sehr komplex, bei Änderungen treten viele Nebeneffekte auf.

- Die Anforderungen wurden teilweise sofort geändert, man weiß manchmal gar nicht, ob sie überhaupt noch gelten, zum Beispiel bei Sondertarifen.

Mit "+" werden positive, mit "-" negative Auswirkungen bezeichnet.