Stand: 21. Dezember 2019
| Fachprofil |
| Projekttabelle |
| Projektliste |
Auf dieser Seite sind alle Projekte der Vergangenheit in antichronologischer Reihenfolge
aufgelistet und detailiert beschrieben. Informationen zu speziellen Projekten lassen sich
am besten aus der überblicksartigen Projekttabelle durch Klicken auf DETAILS ansteuern.
Backend-Entwicklung für Batch-Komponenten von Kartensystemen
Die Einführung eines neuen Payment-Providers gibt Anlaß zu einer Reihe von Projekten, die die bestehenden Kartensysteme für den Provider erweitern:
Entwicklung eines Batch-Verfahrens zum Update der Kartendaten im Spiegelbestand
Das bestehende Verfahren, mit dem die Kartendaten vom Kartenprozessor in die Kartendatenbank integriert werden, wird erweitert, indem die Kartendaten auf einem separaten Pfad auf einen dem Provider zuzuordnenden Server per Datentransfer übertragen werden.
Entwicklung eines Batch-Verfahrens zur Bereinigung obsoleter teilqualifizierter Kartensperren
Migration aller teilqualifizierten Kartensperren auf vollqualifizierte Kartensperren
In diesen beiden Projekten wird die Sperrdatenbank bereinigt und umgestellt in der Weise, dass sie in Zukunft nur vollqualifizierte Kartensperren erhalten soll. Damit werden einige Probleme eliminiert, die in seltenen Konstellationen auftreten können, beispielsweise bei der Wiederbelebung von Kontonummern oder bei Fusionen.
Erweiterungen von Listenprogrammen
Mit der Einführung des neuen Providers werden einige Standardlisten um neue Features erweitert. Gleichzeitig werden Assemblermodule, die bei den bestehenden Verfahren aufgerufen wurden, abgelöst.
- Entwicklung des Architekturkonzeptes
- Realisierung in COBOL und JCL
- Überwachung des Verfahrenseinsatzes
Entwicklungsumgebung: z/OS, DB2, JCL, COBOL, SQL,..., XPEDITER, RDz
Zeitraum: April 2019 bis dato.
Backend-Entwicklung für Batch-Komponenten von Online-Bezahlverfahren:
Entwicklung eines Batch-Verfahrens zur Synchronisation der Stammdaten zwischen der führenden Datenhaltung bei der Bank und dem Spiegelbestand des Providers
Die Stammdatensynchronisation beginnt mit einem Full Load und wird fortgesetzt mit werktäglich laufenden Delta-Loads. Die Daten des Erstlaufes werden dem dispositiven Bestand entnommen, die Daten der Delta-Loads aus der Änderungsdatenbank. Dabei wird eine Datei mit den zu aktualisierenden Daten per Datentransfer zum Provider übertragen, und danach wird eine Antwortdatei des Providers erwartet. Das aus einer Jobkette bestehende Verfahren erkennt selbstständig, in welchem Ablaufstadium es sich gerade befindet und erkennt durch Plausibilitätsprüfungen, ob es eine Störung gegeben hat. Beispielsweise wird ein Delta-Load nicht ausgeführt, so lange die Antwort des letzten Laufes noch nicht eingegangen ist und verarbeitet wurde.
Das Verfahren ist stabil gegenüber Ausfällen sowohl beim Datentransfer als auch bei der Verarbeitung im Zielsystem. Wenn die Versanddatei durch eine Ablaufstörung nicht abgeholt wird oder wenn keine Antwortdatei eintrifft, wird das betreuende Team durch eine Alert-Mail informiert und kann das Verfahren durch Anstarten dafür vorgesehener Jobs zurücksetzen. Dabei ist die Kette der Verarbeitungsintervalle automatisch lückenlos.
- Entwicklung des Architekturkonzeptes
- Realisierung in COBOL und JCL
- Überwachung des Verfahrenseinsatzes
Entwicklungsumgebung: z/OS, DB2, JCL, COBOL, SQL,..., XPEDITER, RDz
Zeitraum: Januar 2018 bis März 2019.
Batch-Verfahren zur Registrierung von Online-Banking-Kunden für ein Online-Bezahlverfahren
Den Online-Banking-Kunden des Bankenverbundes soll das Online-Bezahlverfahren auf komfortable Weise nahegebracht werden. Zu diesem Zwecke wird ein Batch-Verfahren entwickelt, welches sowohl die Registrierung der Kunden beim Träger des Bezahlverfahrens als auch in den Datenbanken des Bankenverbundes durchführt. Die Kunden können dann mit wenigen einfachen Mouseclicks ihr Online-Banking um die Online-Bezahlfunktion erweitern, wozu sie durch eine elektronische Mail nach Abschluß der Registrierung eingeladen werden.
Eine technische Besonderheit des Batchverfahrens ist die Notwendigkeit, Web-Services vom Batch aus aufzurufen. Dazu stellt die IBM die EXCI – Umgebung zur Verfügung. Unter EXCI sind jedoch viele andere Prozessaufrufe des Verfahrens nicht lauffähig. Als Konsequenz ergibt sich für das Verfahren eine Architektur, bei der die Aufrufe der Web-Services in einem Schritt separat durchgeführt und alle anderen Teile der Verarbeitung entweder davor oder danach ausgeführt werden. Als weitere Konsequenz ergibt sich die Notwendigkeit eines modifizierten, vom Standard stark abweichenden Recovery-Konzeptes. Die Zwischenergebnisse eines jeden Verfahrensschrittes werden mitsamt der Statuscodes in einer Steuerdatei mitgeführt, und im Abbruchfalle werden die vor dem Abbruch erfolgreich teilverarbeiteten Daten zu Ende verarbeitet; erst danach wird durch Restart des Jobs von vorne die Recovery eingeleitet. Bei unvollständiger Verarbeitung wird das Betreuungsteam durch eine im Job generierte eMail auf den entstandenen Handlungsbedarf hingewiesen.
- Entwicklung des Architekturkonzeptes
- Realisierung in COBOL und JCL
- Überwachung des Verfahrenseinsatzes
Entwicklungsumgebung: z/OS, DB2, CICS, EXCI, WS, JCL, COBOL, SQL,..., XPEDITER, RDz
Zeitraum: Mai 2017 bis Dezember 2017.
Entwicklung und Support für eine Host-basierte Client-Server Welt; Unterstützung des Rechenzentrumsbetriebes bis zur Ablösung der Mandantensysteme
Dieser Auftrag besteht aus der Anwendung eines Configuration Change Management Systems, das für die Mandanten Software-Aktualisierungen vornimmt und laufend weiterentwickelt wird; hinzu kommen noch weitere Dienste im Zusammenhang mit einem in dieser Zeit separat entwickelten Auftragstool.
- Umsetzung der Anforderungen aus dem laufenden Betrieb
- Durchführung der Software–Verteilung und –Aktivierung
- Betreuung der Produktivsetzung von Installationen
- Weiterentwicklung des Configuration Change Management Systems
- Entwicklung eines Auftragstools
- Abschluß der Entwicklung eines Auftragstools mit weiteren Dialogen zur Konfiguration und Datenpflege
- Mitwirkung bei der Ablösung der Mandantensysteme durch eine zentrale Branchenanwendung
Entwicklungsumgebung: z/OS; DB2, CICS, TWS; SQL, JCL, REXX; .rex, .php, Powershell, JavaScript, jQuery
Zeitraum: September 2011 bis Dezember 2016.
Im Folgenden werden die Entwicklungen, die in diesem Zeitraum durchgeführt wurden, kurz beschrieben:
Teilprojekte:
Werkzeugentwicklung für Configuration / Change - Management
Für die Aktualisierungen der Softwarestände der betreuten Mandanten ist ein halbautomatisches System im Einsatz, welches neue Versionen als Lieferung entgegennehmen und mit umgebungsbezogenen Aufträgen installieren kann. Dieses wird bei laufendem Betrieb ständig weiterentwickelt, so daß die Funktionalitäten erweitert und die Notwendigkeiten für manuelle Eingriffe zurückgedrängt werden.
Das System besteht im Wesentlichen aus einer DB2-basierten Verwaltungsdatenbank, zugehörigen REXX-Prozeduren, über die der Ablauf der Installationen gesteuert wird und einer überwiegend in .php geschriebenen
Web-Anwendung, über die mit den Mandanten über die auszuführenden Installationsaufträge kommuniziert wird; ferner werden Lieferungen mit .rex-Prozeduren entgegengenommen. Dezentrale Komponenten werden mit Powershell-Skripten auf die Server der Mandanten verteilt.
Zunächst werden die verschiedenen Mandantensysteme zu einem einzigen mandantenfähigen System zusammengeführt, was Anpassungen in fast allen Komponenten des Systems involviert. Insbesondere wird die Verwaltungsdatenbank an den meisten Tabellen um ein Mandantenkennzeichen erweitert. Es folgt die Migration der mandantenspezifischen Verwaltungsdaten. Eine der ersten entstehenden Vorzüge nach der Umstellung ist eine webbasierte selbstaktualisierende Funktion für eine mandantenübergreifende Verarbeitungsstatistik. Webbasierte Report-Funktionen bleiben mandantenbezogen, werden jedoch komfortabler gestaltet mit verbesserten Sortier- und Blätterfunktionen und verfeinerter Statusanzeige.
Die neue Verwaltungsdatenbank wird einmal jährlich nach Datensicherung auf den Bestand der letzten zwei Jahre reduziert, wobei nach Releaseständen abgegrenzt wird.
Mit der Mandantenfähigkeit des Systems entsteht die Möglichkeit, Software-Aktualisierungen mandantenübergreifend zu erfassen und als Multilieferungen für die Aufnahme in Installationsaufträgen bereitzustellen. Das Verfahren wird diesbezüglich erweitert.
Logisch unabhängig von den Installationsverfahren werden die Konfigurationen der dezentralen Server in der Verwaltungsdatenbank abgespeichert, so daß die Historie der Serverkonfigurationen nachvollziehbar ist. Hier kommen wie bei der Verteilung von dezentralen Komponenten auf Mandantenserver Powershell-Skripte zum Einsatz.
- Entwicklung eines mandantenfähigen umfassenden Datenmodells auf der Basis der Strukturen der mandantenabhängigen Datenbanken; Anpassung der .rex-Skripte für die Lieferungen, der REXX-Skripte für die Auftragsverarbeitung und der .php-Skripte der Web-Anwendung; Migration der Altbestände.
- Entwicklung einer Web-Anwendung zur Anzeige einer mandantenübergreifenden Verarbeitungsstatistik
- Überarbeitung der Web-Anwendung zur Einführung verfeinerter Datenanzeige
- SQL-Entwicklung für die Reduktion der Verwaltungsdatenbank auf die Daten der letzten zwei Jahre
- SQL-Entwicklung für das Laden der dezentralen Serverdaten in die Verwaltungsdatenbank
- Entwicklung eines Verfahrens zum File-Transfer und zur Weiterverteilung dezentraler Komponenten auf File-Server eines Mandanten
- Anwendung des Systems: Empfang von Lieferungen, Generierung und Ausführung von Installationsaufträgen in Test- und Produktionsumgebungen; manuelle Eingriffe in das Verfahren
Zwei neue Anwendungen für das Berechtigungsmanagement:
Bearbeiten von RACF-Berechtigungen
Das Anlegen von RACF-berechtigten Usern und die zugehörige Rechteverwaltung wird durch eine webbasierte Anwendung gesteuert, die Änderungen von RACF-Berechtigungen als Schnittstellendatei generiert. Die Anwendung wird später durch eine Reportfunktion erweitert, welche die erteilten Aufträge zur Rechteverwaltung protokolliert.
Verfeinerte auftragsbezogene Berechtigungen im Auftragstool
Das Auftragstool der Mandanten enthält eine Logik, die den einzelnen Mitarbeitern die Berechtigung für einzelne Anwendungen oder Gruppen von Anwendungen zuordnet. Auf Wunsch der Mandanten sollen die Berechtigungen differenziert werden hinsichtlich diverser Leserechte, dem Recht zur Ausführung der Anwendung und dem Recht zur Administration.
Die neue Anwendung enthält zu jeder Anwendung eine Anzeige der Gruppen- und Einzelberechtigungen ebenso wie eine Gesamtübersicht im XML-Format. Die bestehenden Berechtigungen werden den Mandanten in einem Excel-Sheet vorgelegt. Die Mandanten definieren die verfeinerten Berechtigungen in dem Excel-Sheet durch Ersetzen des Berechtigungskennzeichens durch ein Berechtigungsprofil. Diese Daten werden exportiert,
ausgewertet und in die Datenbank geladen.
- Entwicklung und Implementierung dieser Anwendungen
TWS-Einführung
Die Verfahren der Software–Verteilung und –Produktivsetzung werden in den Tivoli Work Scheduler eingeführt. Das TWS wird bei der Bearbeitung des Installationsauftrages durch eine Triggerdatei angestartet. In dem Verfahren sind vordefinierte Haltepunkte festgelegt, die nach den entsprechenden Überprüfungen während des Installationsablaufes manuell entfernt werden.
- Generierung der Triggerdatei aus der webbasierten Anwendung zur Installationsauftragsbearbeitung
- Erweiterung der Statusanzeige für TWS-basierte Installationen und Produktivsetzungen
Parallele Installation von dezentralen Komponenten auf 32-Bit (XP)- und 64-Bit (Windows 7)-Systemen
Die Umstellung der Mandaten von 32-Bit-Clients auf 64-Bit-Clients läßt sich organisatorisch nicht vollständig synchronisieren. Daher müssen für einen Mandanten in einer Übergangszeit parallel zu den 64-Bit-Lieferungen entsprechende 32-Bit-Lieferungen erzeugt und installiert werden. Die Umstellung auf 64-Bit erfolgt zu einem späteren, vom diesem Mandanten gewählten Zeitpunkt.
- Abgleich der parallelen dezentralen Komponenten in der Routine zum Empfang der Lieferungen
- Separate Ermittlung der letzten Altlieferung bezogen auf 32-Bit- bzw. 64-Bit-Lieferungen
- Unterstützung beider Varianten bei der Auftragsgenerierung
- Einsatz modifizierter Powershell-Scripte bei der Ausführung der 32-Bit-Variante
Windows-7-Support für Anwendungssystemkonfiguration
Die Umstellung auf Windows-7-Clients macht an vielen Stellen Eingriffe in die Systemkonfiguration der Anwendungen notwendig. Beispielsweise kann die IP-Adresse des Clients nicht mehr auf die herkömmliche Weise ermittelt werden. In den neuen Scripten werden je nach Modus (32-/64-Bit) unterschiedliche Werte definiert.
- Anpassungen in den .cmd-Scripten und .ini-Files
- Test der Gesamtkonfiguration in beiden Modi
Einführung neuer Prozesse in das Installationsverfahren
Die Verfahren, die Dateien oder Dateisysteme auf den Servern neu anlegen, führen im Laufe der Zeit zu einem Speicherüberlauf, wenn nicht die veralteten Dateien bzw. Dateisysteme in entsprechendem Umfang gelöscht werden. Bis zur Einführung der neuen Prozesse wird das manuell erledigt. Danach werden bei jeder Installation die Löschungen in konfigurierbarem Umfang automatisch ausgeführt.
- Löschung von veralteten Runtime-Umgebungen
- Löschung von veralteten Textbibliotheken
Überarbeitung bestehender webbasierter Tools
Zwei Werkzeuge wurden weiterentwickelt bis zum Produktionseinsatz:
- Performance-Tool
- Auftragstool
Umstellung FTP->FTPS mit WS-Ipswitch
Um für einen Mandanten die Datenübertragung sicherer zu machen, wird der Einsatz von FTPS in Betracht gezogen. Mit dem Einsatz von WS-Ipswitch wird die einfache Machbarkeit im Test nachgewiesen.
- Definition eines FTP-Verfahrensschalters und Bereitstellung von FTPS-Scripten zum Aufruf von Ipswitch
- Test der Datenübertragung zusammen mit den zugehörigen Firewall-Einstellungen und der nachfolgenden Verarbeitung
Zusatzprojekt: Anbindung eines Host-basierten Provisionssystems an die Branchenlösung
Im Zusammenhang mit der Migration der Mandanten auf die neu entwickelte Gesamtanwendung behält ein Mandant das Provisionssystem aus der Altanwendung bei. Dazu wird eine stark verkleinerte Version des Altsystems, innerhalb dessen das Provisionssystem lauffähig ist, in einer neu angelegten Umgebung bereitgestellt. Für den täglichen Batch und den Monatslauf werden die Exportdaten auf die Umgebung übertragen, TWS-gesteuert automatisch verarbeitet und zurück übertragen.
- Analyse der Altanwendung und Eliminierung der nicht erforderlichen Systemkomponenten
- Dokumentation im Betriebshandbuch
- Weiterführung des Configuration Change Managements bis zum Cutover-Termin
Zeitraum des Zusatzprojektes: September 2016 bis Dezember 2016.
Die Technische Fusion ist ein den gesamten Datenbestand der fusionsrelevanten Tabellen des Bankanwendungssystems erfassendes Verfahren, das in mehreren Abschnitten durch Umsetzung der Fusionskonzepte und durch mehrere Testfusionen den Ablauf der Datenzusammenführung am Cutovertag ermöglicht und seinen Erfolg sicherstellt.
Das System ist in der gegenwärtigen Form bereits seit Jahren in Betrieb, jedoch werden die Kontrollsysteme, die Dateninkonsistenzen oder andere Anomalien im Ablauf der Testfusion erkennbar machen, zunehmend verfeinert, um die Überwachung des Ablaufes zu erleichtern.
In dem Zusammenhang werden in den Jobs erkannte unerwünschte Situationen in Protokolldateien dargestellt, die dann weiter verdichtet werden. In vielen Fällen werden Besonderheiten durch eine vom Job selbst verschickte eMail an das Fusionsteam bekannt gemacht.
Die Umstellung des Gateways macht eine Erfassung aller dieser Jobs erforderlich, um sie dann einzeln oder zentral über die Mailprozeduren umzustellen.
- Entwicklung von Jobs zum Transfer von Dateien mit Connect Direct (C:D) sowie einer Windows .cmd-Datei mit FTP-Aufruf für dieselben Dateien (redundantes Verfahren)
- Erfassung aller mit dem SMTP Gateway verknüpften Jobs durch Durchsuchen der Bibliotheken für Jobs und Prozeduren sowie für SYSIN-Member, die auf SMTP hindeuten
- Einschränkung des Ergebnisses auf die zu den Bereichen Fusion und Migration gehörigen Jobs durch Einsatz eines SAS-Programms
- Entwicklung bzw. Bearbeitung von Mail-Komponenten in bestehenden Jobs
( - Umstellung von über 100 Jobs auf das neue Gateway)
Entwicklungsumgebung: z/OS, JCL, ENDEVOR, SAS)
Zeitraum: Januar 2017 bis März 2017.
Bestandscoring, Führende Bonität, Frühwarnsystem
Noch im Aufbau bzw. in der Weiterentwicklung befindliche Risikoklassifizierungsverfahren wurden entwickelt, aufeinander abgestimmt bzw. einem Reengineering unterzogen. Die Verfahren setzen auf einer DB2-basierten Datenhaltung auf, stellen Ausgabedateien für einen Datenexport bereit und kommunizieren über PMS-Prozesse (ROCHADE) mit dem Frontend.
Entwicklungsumgebung: z/OS; DB2, CICS; PMS-Prozesse; SQL, JCL; Java; JBoss
Zeitraum: Juni 2006 bis Juli 2011.
Im Folgenden werden die Entwicklungen, die in diesem Zeitraum durchgeführt wurden, kurz beschrieben:
Teilprojekte:
Bestandsscoring–Entwicklung
Für Baufinanzierungskredite und Konsumentenkredite konzipierte Kennzahlen werden aus der Datenbank kundenbezogen gelesen und ausgewertet. Das Ergebnis wird in Form von Punkten und Noten in die Datenbank und in eine Ausgabedatei geschrieben, die als Ausgangspunkt für das nachfolgende Exportverfahren dient.
Exportverfahren für Bestandsscoring und Verhaltensscoring
Die Ausgabedaten der genannten Scoring-Verfahren werden gemäß den je nach Geschäftssituation des Bankkunden variierenden Lieferungsanforderungen angereichert, formatiert, gekennzeichnet und ins XML-Format konvertiert, um sie dann an eine externe Stelle zu versenden
- Entwicklung eines DV-Konzeptes auf der Basis eines bestehenden Fachkonzeptes
- Technische Umsetzung (Programmierung, Test, Koordination des Integrationstest)
Entwicklungsumgebung: z/OS, COBOL, DB2, XPEDITER; XML
Zeitraum: Juni 2006 bis Dezember 2007
Ermittlung der Führenden Bonität
Durch die Weiterentwicklung der Scoring- und Rating-Systeme ergeben sich regelmäßig Notwendigkeiten zur Anpassung der zentralen Steuerung, die aus den konkurrierenden Verfahren das für den Bankkunden gültige auswählt.
Verbundanalyse für die Verfahrensvereinheitlichung
Der Anwender hat weitgehend freie Hand, einem Bankkunden ein Scoring-/Ratingverfahren zuzuordnen. Bei Personenverbünden sollte dieses allerdings für alle Mitglieder einheitlich sein. Die Verbundstrukturen eines Bankkunden werden als Superverbund rekursiv konstruiert und an das Frontend zur Darstellung bereitgestellt, so daß der Anwender dort Änderungen vornehmen kann. Außerdem wird ein Musterselect bereitgestellt, bei dem für Superverbünde mit uneinheitlichen Verfahren ein Repräsentant ausgegeben wird, mit dessen Hilfe der Superverbund angezeigt und dann die Situation abgeändert werden kann.
Frühwarnsystem - Reengineering
Das Frühwarnsystem des Kunden war funktional unauffällig, wurde jedoch durch seinen Aufbau und durch die von strukturellen Änderungen der Systemumgebung kommenden Anforderungen als nicht mehr wartbar eingestuft. Daher entschloß man sich zu einem vollständigen Reengineering des Systems. Das umfangreiche Batch-Programm wurde in insgesamt vier Einzelmodule zerlegt: Eine Vorverarbeitung, welche die Eingangsdaten – im Wesentlichen die Daten der Bankkunden und ihrer Kennzahlen – aus der Datenbank beschafft und in drei Dateien bereitstellt, anstatt sie sofort weiter zu verarbeiten; dann ein Steuermodul, welches sich mit Hilfe eines Konfigurationsmoduls seine Metadaten beschafft und schließlich die Ausgangsdaten der Vorverarbeitung liest, um sie dem Programm der personenbezogenen Verarbeitung zuzuführen.
Durch das Reengineering wurde eine klare, leicht nachvollziehbare Struktur der Abläufe erreicht, und so wurde das System insgesamt auf eine höhere Qualitätsstufe gehoben.
- Konzeptionelle Vorstudie zur Eingrenzung kapselbarer Komponenten des Altsystems
- Programmierung der vier Komponentenmodule unter weitestmöglicher Erhaltung alter Code-Strukturen
- Durchführung von Paralleltests mit dem Altsystem zur Überprüfung der Ausgangsdateien der Vorverarbeitung, der Ausgangsdateien des Verfahrens als Ganzes und schließlich zur Überprüfung der Datenbank-Updates; diese werden mit Trace-Funktionen simuliert und dann maschinell verglichen.
- Nachweis sporadischer Fehler, die bisher aus dem produktiven Betrieb nicht bekannt waren, und deren Behebung.
Entwicklungsumgebung: z/OS, COBOL, DB2, XPEDITER; ROCHADE
Zeitraum: Januar 2008 bis Oktober 2008
Rating für Geschäftskunden mit oder ohne Girokonten
Geschäftskunden, die nur Aval- oder Darlehenskonten bei der Bank haben, sind hinsichtlich der Bonität schwerer zu beurteilen als solche, die auch Girokonten haben. Das Verfahren zur Bewertung der Bonität zieht daher dann auch Zusatzinformationen aus anderen Bereichen heran. Aus technischer Sicht komplex ist die Logik der Verfahrenswechsel bei Eröffnung und bei Schließung eines Girokontos. Wegen der hinzukommenden neuen Komplexität wird das bestehende Verfahren einem Reengineering unterzogen, in dem eine modulare Trennung zwischen Datenbeschaffung, Datenaufbereitung und personenbezogener Verarbeitung in einem ersten Schritt umgesetzt wird.
- Reengineering des bestehenden Ratingverfahrens
- Erweiterung der Programme um die Verarbeitung neuer Kundenmerkmale
- Entwicklung und Umsetzung eines Konzeptes zur logischen Abgrenzung der beiden Verfahren innerhalb der kundenbezogenen Verarbeitungslogik
Entwicklungsumgebung: z/OS
Zeitraum: Oktober 2008 bis September 2009
Wartung und Weiterentwicklung von bestehenden Systemen;
Frontend-Entwicklung für das Frühwarnsystem
Drei Spezialthemen werden im Folgenden beschrieben:
Online - Verfügbarkeit der Führenden Bonität
Im Normalbetrieb wird die Führende Bonität , d. h., das Verfahren, das bei Vorliegen konkurrierender Ratings gültig sein soll, im täglichen Batch ermittelt und steht daher erst am Folgetag zur Verfügung. Um es sofort nach Erstellen eines Ratings zur Verfügung zu haben, wird das Programm zur Erstellung der Führenden Bonität eines Kunden an den zugehörigen PMS-Prozess angebunden. Das führt zu einer Überarbeitung der Programmarchitektur und zu fachlich identischen, aber technisch unterschiedlichen Datenbank-Cursors. Denn das Tuning der SQL unterscheidet sich in der Einzelverarbeitung (beim Online-Aufruf) von dem in der Gesamtverarbeitung (im täglichen Batch). Eine Protokollierung der Verarbeitung in der Änderungsdatenbank ist nur beim Online-Aufruf notwendig, da beim Batch das Jobprotokoll mit den umfassenden Informationen standardmäßig archiviert wird.
Entwicklungsumgebung: z/OS
Identifikation von Kunden der öffentlichen Hand durch ihre Kundensystematik
Kunden der öffentlichen Hand erhalten fest vorgegebene Ratingnoten, die durch ihre Kundensystematik fachlich definiert und zugeordnet werden. Diese Zuordnung wird an mehreren Stellen benötigt: bei der Plausibilisierung der Ratingzuordnung aus dem Frontend und bei der initialen Ratingzuordnung bei der Einführung des Systems. Daher werden die zugehörigen Datenstrukturen und die zugehörige Auswertungslogik zentral bereitgestellt. Wegen der erheblichen Gefahr von Schreibfehlern beim Einpflegen von Änderungen der Zuordnungen wird ein Testtreiber bereitgestellt, der eine große Anzahl von Testfällen automatisch verifizieren kann.
Entwicklungsumgebung: z/OS
Frontend-Entwicklungen zum Frühwarnsystem
Anforderungen zur Optimierung des Frühwarnsystem-Frontends dienen der Verbesserung bestehender Dialoge und der Bereitstellung zusätzlicher Daten oder zugänglicher Daten auf einem anderen Pfad. Als Verbesserung bestehender Dialoge wird die Ein- bzw. Ausblendung von Anzeigekomponenten in Abhängigkeit von zentralen Konfigurationsparametern entwickelt. In der allgemeinen Testphase erweist sich für die Überprüfung von Testdaten der Zugang zum Backend meistens als Erleichterung.
Entwicklungsumgebung: z/OS; Java; JBoss, Apache
Zeitraum: Oktober 2009 bis Juli 2011
__________________________________________________________________________________
Bei der Einführung des SAP-Moduls "zentraler Geschäftspartner" (ZGP) werden die Datenbestände der in ASSEMBLER und COBOL geschriebenen Host-Altsysteme einerseits in den ZGP migriert, andererseits müssen zum Erhalt der Altsysteme die ZGP-Daten in den Formaten des Altsystems redundant weitergeführt und vom ZGP in die Altsysteme demigriert werden.
Die Demigration der ZGP-Daten in die Altsysteme erfolgt in einem zweistufigen Verteilungsprozeß, der in Gestalt zweier CICS-Transaktionen im Hintergrund abläuft und jeweils bei Bedarf aktiv wird. Fehler bei der Demigration werden über eine Sperrtabelle einer manuellen Behandlung zugeführt. Wenn die Daten zu einem Geschäftspartner sich geändert haben, wird die GP-ID des Partners zu der Änderung bekanntgegeben. Die Verteilungstransaktion sucht über Zugriffsmodule die Daten aus DB2-Tabellen zusammen und speichert sie in den VSAM-Beständen des Altsystems. Die Verfahren des Altsystems werden dahingehend geändert, daß Pflegefunktionen zu ZGP-Daten gesperrt werden, da die Pflege nur noch über den ZGP selbst erfolgen kann.
Entwicklungsumgebung: z/OS, CICS; COBOL, ASSEMBLER; DB2; XPEDITER; SAP FS-CD und FS-CS
Zeitraum: März 2005 bis Februar 2006
__________________________________________________________________________________
Für die flexible Datenbereitstellung von Statistikdaten für das Meldewesen (GS I, GS II,...) wird ein auf alten ASSEMBLER-Modulen basierendes, auf technische Restriktionen stoßendes Altsystem auf ein neues Verfahren umgestellt, in dem die Struktur der Statistiken in einem DB-Repository abgebildet sind und wo die Auswertungen mit maschinell generierten Skripts von dem Auswertungstool ACL erstellt werden.
Um nachzweisen, daß das ACL – System die gestellten Anforderungen erfüllen kann, muß eine umfassende Evaluierung der Entscheidung über seinen Einsatz vorausgehen. Die Evaluierung hinsichtlich der Abdeckung der logischen Anforderungen ist leicht zu führen, aufwendiger ist die Abschätzung des Ressourcenverbrauches beim Einsatz mit Massendaten. Dazu wird ein Prognosesystem entwickelt, welches für eine Auswertung mit gegebenen Eingangsparametern (Dateigröße, Satzlänge, auswertungslogische Parameter) eine Schätzung für den prozessorinvariant in Service-Units gemessenen Verbrauch an Rechenzeit berechnet.Dabei genügt für die Prognose bei GROUP – Auswertungen ein im Wesentlichen lineares Modell, während bei SUMMARIZE – Auswertungen alle Abhängigkeiten nichtlinear modelliert werden müssen.
Das Datenmodell der für die Statistik-Auswertung benötigten Felder wird vorrangig unter dem Gesichtspunkt der Performance-Optimierung gestaltet. Ausgehend von der Menge der in irgendeiner Statistik definierten Felder werden die obsoleten Felder ermittelt und eliminiert. Die Tabellenabhängigkeiten werden denormalisiert modelliert, wenn eine fachlich begründete Obergrenze für die Anzahl der Detailsätze zu einem Mastersatz feststeht.
Entwicklungsumgebung: z/OS; ASSEMBLER, C; DB2; technische Darstellungen überwiegend mit EXCEL
Zeitraum: Oktober 2004 bis März 2005
__________________________________________________________________________________
Eine Kernproblematik bei Datenüberleitungssystemen besteht in der Grundsatzentscheidung, ob ein interpretierendes System (ein Produkt wie z. B. MERCATOR) zum Einsatz kommen oder die Datenüberleitung in einer speziellen Neuentwicklung bewerkstelligt werden soll. Persönliche Projekterfahrungen der Vergangenheit besagen, daß die Neuentwicklung trotz ihres Charakters als Insellösung (s. u.) erfolgreicher war. Die Ursachen dafür sind sehr vielschichtig, wobei die Bedienerverständlichkeit im Vordergrund steht. Ungeachtet dessen wird ein interpretierender Datenkonverter noch als erfolgversprechend eingestuft, wenn er gewisse Leistungsmerkmale erfüllt, u. a.
ist. Dafür wurde auf der Basis bestehender Erfahrungen ein neues Konzept entwickelt, welches die Leistungsmerkmale des DAKAR-Monitors (s. u.) in den wesentlichen Punkten übertrifft.
Entwicklungsumgebung: C++, LINUX 8.2
Zeitraum: Januar bis April 2004
Zu untersuchen war ein seit ca. 20 Jahren bestehendes Verfahren, das systemweit i. W. alle Programmaufrufe steuerte. Dieses Verfahren umfaßt eine Tabellenverwaltung sämtlicher geladenen Module und ist obsolet geworden dadurch, daß die Weiterentwickling des MVS bis zum heutigen z/OS genügend technische Funktionalität bereitgestellt hat, so daß das Betriebssystem selber die Modulverwaltung übernehmen kann.
Das dynamische Linkverfahren pflegt in seiner Modultabelle zu jedem Modulnamen alle zugehörigen technischen Daten wie Ladeadresse, Programmzustand, BLDL-Daten etc.; dazu ist es belastet mit einer von der Standard-Aufrufstruktur abweichenden Alt-Schnittstelle und Parameterübergaben in Spezialfällen, die über die Standard Linkage Convention hinausgehen. Es kontrolliert auch den Auf- und Abbau der Runtime-Umgebungen und die Systemresourcen (Speicher above/below the line), wozu es auf MVS-Systemtabellen zugreift.
Zur Lösung des Problems wurde zunächst die Alt-Schnittstelle in ein separates vorgelagertes LE-konformes Assembler-Programm ausgelagert. Das Aufrufprogramm wurde dann zunächst in native Assembler entwickelt. Im dritten Schritt wurde ein Maximum an LE-Konformität angestrebt, ohne die Allgemeingültigkeit der Aufrufschnittstelle einzuschränken.
Entwicklungsumgebung: z/OS, ASSEMBLER, in geringem Anteil auch: COBOL, C; IMS
Zeitraum: Ende März 2003 bis Juli 2003
__________________________________________________________________________________
Entwicklung einer DB2-Zugriffsschicht im Rahmen einer Migration von IMS nach DB2
Die Umstellung von IMS nach DB2 besteht im Wesentlichen aus drei Entwicklungsschritten:
Mit dem Wechsel der Datenbanken wird teilweise die Entwicklungssprache von /370-ASSEMBLER nach C/370 umgestellt.
Die Zugriffsschicht bildet die ehemaligen Strukturen über der hierarchischen Datenbank ab in Kontrollstrukturen und rekursive Prozesse über elementare DB2-Zugriffsbausteine. Die dazu entwickelten Aktionstabellen und ihre Ausführungsmodule sind beliebig erweiterbar.
Eine Besonderheit der Zugriffsschicht ist die Wiederanlauffähigkeit der Zugriffsmethoden. Diese erfordern spezielle Eigenschaften der verwendeten SQL.
Entwicklungsumgebung: OS/390, ASSEMBLER, C, COBOL; DB2, IMS;
Zeitraum: Februar 2002 bis März 2002
Fusion der Sparkasse Goslar mit zwei kleineren Instituten: Fusion der Ertragsdatenbank und Datenversorgung der Direct Brokerage Schnittstelle NETLIFE mit Depotmerkmalen und Orderdaten nach der Fusion
Bei einer Institutsfusion sind ein aufnehmendes Institut und ein oder mehrere abgebende Institute definiert. Bei den abgebenden Instituten wird die Institutsnummer auf die des aufnehmenden Institutes gesetzt. Bei allen Instituten werden außerdem die Depotkontonummern mit Hilfe einer Kontensatzdatei in einer Weise modifiziert, daß nach der Fusion keine Überschneidungen auftreten.
Das Fusionsprogramm, das dieses leistet, setzt voraus, daß die referentiellen Integritäten der Ertragsdatenbank ausgeschaltet sind. Es liest dann jede einzelne Tabelle aus und schreibt die mit der Kontensatzdatei modifizierten Daten in eine Zwischendatei. Danach wird die Zwischendatei gelesen und der Inhalt in die jeweils zugehörige Tabelle geschrieben. Im Fehlerfalle wird ein Rollback der Datenbank ausgeführt. Nach der Fusion werden die referentiellen Integritäten wieder eingeschaltet.
Die Datenversorgung von NETLIFE im normalen Tagesgeschäft wird über eine Deltaversorgung bezüglich der Daten des Vortages bewerkstelligt. Durch die Institutsfusion werden die Vortagesdaten aufgrund obsoleter Depotkontonummern und Institutsnummern ungültig. Es wird daher ein Zwischenlauf eingeschoben zu dem Zweck, geeignete Ersatzdateien für die nächste Tagesverarbeitung bereitzustellen. Dieser basiert auf dem bestehenden Verfahren "Erstladung", benutzt aber modifizierte Selektionsmechanismen und hat daher auch eine eigene Position im Auftragsverwaltungssystem.
Entwicklungsumgebung: OS/390, ASSEMBLER, C, COBOL; DB2;
Zeitraum: April 2002 bis September 2002
Umstellung der 6-stelligen numerischen Wertpapierkennummer in eine 12-stellige alphanumerische ISIN
Die Umstellung wird in mehreren Schritten durchgeführt.
Im ersten Schritt wird eine sechsstellige alphanumerische Wertpapierkennummer gestattet. In den beiden folgenden Schritten wird die volle Allgemeinheit erreicht.
Im Wesentlichen besteht der erste Schritt darin, die Typvalidierung aller Felder mit der Bedeutung einer Wertpapierkennummer zu modifizieren. Die Modifikation besteht im Ersatz eines Validierungsmakros durch ein anderes. Wo die ISIN zum Einsatz kommt, wird sie aus der Gattungsdatenbank gelesen oder aus vorgelagerten Verfahrensschritten übernommen.
Darüber hinaus weden alle Algorithmen umgestellt, die einen numerischen Typ voraussetzen. So werden bei einer Auswertung der Gattungsdaten in der alten Version alle möglichen numerischen Kennummern numerisch durchgezählt und per Direktzugriff gelesen, in der neuen Version wird dagegen die Gattungsdatentabelle sequentiell durchgelesen.
Die Umstellungen betreffen hauptsächlich Validierungsprogramme im Online und Listenprogramme und deren Datenbereitstellungsmodule im Batch.
Entwicklungsumgebung: OS/390, ASSEMBLER;
Zeitraum: August 2002 bis Januar 2003
__________________________________________________________________________________
Für die Überleitung der Daten kommt ein interpretierendes System (s. u.) aus Performancegründen nicht für die Umsetzung in Betracht. Wegen des Datenumfanges wird das System vielmehr in COBOL durchprogrammiert, wobei bereits in der Konzeptionsphase starkes Augenmerk auf die zu erwartende Verarbeitungszeit gelegt wird.
Die Architektur wird so entworfen, daß ein für alle Sparten gemeinsames Steuerprogramm existiert, das die zu verarbeitenden Spartennummern als Jobparameter erhält und spartenabhängig die zu verarbeitenden Datenpakete zusammenstellt. Die fachliche Logik der Verarbeitung ist in spartenabhängigen Modulen konzentriert, die auch die Ausgabe der Ergebnisse veranlassen. Fehlerbehandlung und I/O-Statistik ist Sache des Steuerprogramms.
Die überzuleitenden Sparten können sowohl parallel verarbeitet werden, d. h., mit einem separaten Job pro Sparte, als auch sequentiell, durch einen einzigen Aufruf des Steuerprogramms und Spezifikation aller Sparten, sowie in Mischformen.
Da bei einigen der spartenabhängig zu verarbeitenden Datenpakete die Größe nicht prognostiziert werden kann, werden die zugehörigen Speicherbereiche zur Laufzeit generiert und bei Bedarf vergrößert. Die initiale Größe wird dabei so dimensioniert, daß nach 2 bis 3 Erweiterungen eine Anzahl von Datensätzen aufgenommen werden kann, die einer groben worst-case Schätzung entspricht, ohne dabei eine obere Grenze zu definieren. Zu Beginn einer Spartenverarbeitung werden die erforderlichen Datenbereiche in initialer Größe generiert, nach Ende der Spartenverarbeitung in der jeweiligen aktuellen Größe wieder freigegeben. Es wird daher immer nur der für die aktuell verarbeitete Sparte benötigte Speicherplatz in Anspruch genommen.
Für die Allokation und die Freigabe von Heap Memory werden Systemfunktionen des Language Environment benutzt. Der Vorteil gegenüber einem Standardmodul zur Behandlung von Hauptspeichertabellen besteht hauptsächlich in der Performance, die bei dem vorliegenden Mengengerüst als relevant eingestuft wird.
Entwicklungsumgebung: OS/390, COBOL, IBM Language Environment, ENDEVOR, DB2, ... ; WINDOWS NT
Zeitraum: August 2001 bis Dezember 2001
Erweiterung des Überleitungssystems um drei neue Schnittstellen
Um die Logik des Steuerprogramms nutzen zu können, hauptsächlich hinsichtlich der Bildung der verarbeitenden Datenpakete, werden drei weitere Sparten angebunden, die ursprünglich für dieses System nicht vorgesehen waren. Dabei wurde der Schlüssel der zusammenzuführenden Daten verallgemeinert.
Entwicklungsumgebung: OS/390, COBOL, IBM Language Environment, ENDEVOR, DB2, ... ; WINDOWS NT
Zeitraum: Januar 2002
__________________________________________________________________________________
Um die Kommunikation mit Unternehmensberatungen effektiver zu gestalten und gleichzeitig die Marktpräsenz stärker sichtbar zu machen, wurde eine Internet-Site entwickelt, aus der die fachlichen Daten - Profil und Projekthistorie - sowie die aktuelle Verfügbarkeit entnommen werden können.
Diese Website wird ständig weiterentwickelt und aktualisiert.
Entwicklungsumgebung: WINDOWS 98, Adobe GoLive 5.0;
Zeitraum: Juli 2001; Implementierung später.
__________________________________________________________________________________
Die für Umsatzlisten und Briefe an den Kunden benötigten Daten werden in einem separaten Datenpool gehalten und dort mit Hilfe eines Selektionsprogrammes in eine sequentielle Datei geschrieben. Das nachfolgende Programm liest und sortiert die Datei und gibt die einzelnen Geschäftsdatenblöcke an ein Drucksystem weiter, in dem die erforderlichen Layouts für die Druckausgabe hinterlegt sind.
Entwicklungsumgebung: OS/390; COBOL II; SQS Testsystem für DB2
Zeitraum: Januar 2001 bis Juni 2001;
__________________________________________________________________________________
Im Zuge der 6. KWG-Novelle besteht die Anforderung, aus unterschiedlichen Quellen stammende Geschäftsdaten von Wertpapiergeschäften zu bewerten, wobei teilweise die eingehenden Daten in Teilgeschäfte auf mehreren Ebenen zerlegt und nach der Bewertung wieder zusammengefügt werden müssen.
Anstelle eines in COBOL programmierten Anwendungsystems, das jede Schnittstelle programmtechnisch separat behandelt, wird die Aufgabe durch ein integriertes Softwaresystem gelöst, welches in einem allgemein konzipierten und daher wiederverwendbaren Schnittstellenmonitor mit austauschbaren Komponenten für Datenzugriffe und Verarbeitungsfunktionen besteht. Die Behandlung der einzelnen Geschäfte wird dabei durch Customizing festgelegt.
Der Monitor besteht aus einem in Assembler geschriebenen Kernel, der die reine Steuerungsfunktionalität umfaßt und wartungsfrei konzipiert ist, und einer in COBOL geschriebenen Peripherie, welche die fachliche Funktionalität umfaßt und innerhalb derer funktionale oder technische Änderungen und Erweiterungen leicht umgesetzt werden können.
Der Monitor liest Vorlaufdaten und Konfigurationsdaten ("K-Daten"), um sich für die in dem jeweiligen Batchlauf durchzuführenden Aufgaben zu konditionieren. Für die Verarbeitung eines jeden Input-Datensatzes von Geschäftsdaten liest er die durchzuführenden Anforderungen aus einem Pool von Customizing Daten ("S-Daten", "T-Daten") und bringt diese zur Ausführung. Die Ausgabe kann sowohl direkt (Verarbeitungsmodus II oder IO) als auch über eine Zwischenablage mit einem nachfolgenden neuen Batchlauf erfolgen (Verarbeitungsmodus IV und VO).
Im Modus VO kann zusätzlich ein Verdichtungsalgorithmus ("Assoziierende Verarbeitung") ausgeführt werden, dessen Ablauf durch vom Customizer zu definierende Schlüsseldaten ("A-Daten") gesteuert wird.
Fachliche oder technische Fehler der Verarbeitung werden nach Severity klassifiziert und können in zwei Fehlerlisten ausgegeben werden. Die Behandlung der Fehler wird durch die Fehlerdaten ("F-Daten") von außen definiert.
Für den Monitor existiert eine in ACCESS und VISUAL BASIC entwickelte PC - Version, die während der Entwicklung als Prototyp und im produktiven Einsatz als Customizing Tool fungiert, und eine funktional identische Mainframe - Version, die für die Verarbeitung von Massendaten entwickelt wurde.
Entwicklungsumgebung: OS/390; ASSEMBLER, COBOL II, C/370; ACCESS; VISUAL BASIC
Zeitraum: Februar 1998 bis November 1999;
Für die bei der Entwicklung des DAKAR Host-Monitors federführende Unternehmensberatung bestand das Interesse, die Allgemeingültigkeit und Abstraktheit des verwendeten Ansatzes für zukünftige Probleme nutzen zu können.
Zu diesem Zwecke wurde der Monitor-Kernel in COBOL neu geschrieben und dabei teilweise weiterentwickelt. Die Peripherie wurde neu gestaltet, wobei eine allgemeine Funktionsbibliothek mit einem Bedingungsmodul (COMPARE) und mehreren Aktionsmodulen (OPERATION, STRING, ADDRESS) bereitgestellt wurde. Insbesondere wurden hiermit Kontrollstrukturen für die über die Schnittstellenmatrix ablaufenden Verarbeitungsprozesse eingeführt. Weiterhin wurde ein Aktionsmodul (STATISTICS) für statistische Auswertungen (Mittelwert und Standardabweichung) bereitgestellt.
Für den neuen Monitor wurde eine DEMO-Anwendung im Verarbeitungsmodus IO bereitgestellt, in der aus STAMMDATEN und BEWEGUNGSDATEN bestehende Eingabedaten mit geringem Aufwand manipuliert und wieder ausgegeben werden.
Darüber hinaus bestand Interesse, den Monitor datenbankfähig zu machen. Hierfür wurde ein umfassendes Konzept entwickelt. Realisiert wurden die dafür erforderlichen Erweiterungen der Kernel-Steuerung und die Selbstkonfiguration des Monitors aus den Systemkatalogen der Datenbank im Spezialfall DB2 mit den sogenannten K-Daten.
Entwicklungsumgebung: wie oben.
Zeitraum: November 1999 bis Dezember 2000;
__________________________________________________________________________________
Die betroffenen Datenbestände (Archivierung, Auszahlungen, ...) werden von VSAM nach ADABAS-C migriert. Dabei werden die Satzstrukturen leicht modifiziert.
Aufgrund der Anforderung des Jahrtausendwechsels werden alle Datumsangaben auf achtstelliges Format erweitert. Beim Buchungssatz wird ein Währungskennzeichen eingeführt.
Gleichzeitig werden einige Standardmodule durch neue Module ersetzt.
Entwicklungsumgebung: MVS/ESA, CICS; Dokumentationstool: POESY;
Weitere Tools: SETLIBER (Dateiverwaltung)
Parallel dazu für bisher 2 Tage die erste Einführung in SAP: Bestellanforderungen und Freigabestrategien in MM; 'Hello, World' als ABAP/4-Report; der Materialstammsatz und seine speziellen Sichten
Zeitraum: April 1997 bis Januar 1998
__________________________________________________________________________________
Das Informationssystem besteht aus einer Host - Komponente, einer LAN - Komponente und einer Notebook - Komponente. Der Datenaustausch zwischen Notebook und LAN erfolgt über den Austausch von ASCII - Dateien via LOTUS NOTES. Für die Replikation der Daten auf dem Host wurde eine separate SEND/RECEIVE - Komponente bereitgestellt.
Kernstück der Erweiterung des bestehenden Systems war die Integration einer zweiten Produktlinie mit weitreichenden Konsequenzen für die Auftragsleitfunktionalität.
Objektorientierte Entwicklungsumgebung: SQLWindows
Zeitraum: August 1995 bis März 1997;
__________________________________________________________________________________
Entwicklung eines Systems für die Verwaltung von Telebanking - Verträgen
Objektorientierte Entwicklungsumgebung: VISUAL AGE/VISPRO; SMALLTALK
Zeitraum: Februar 1995 bis Juni 1995;
__________________________________________________________________________________
Zwei Kurzprojekte mit GUPTA-Systemen:
Objektorientierte Entwicklungsumgebung: SQLWindows
Zeitraum: Dezember 1994 bis Januar 1995;
Objektorientierte Entwicklungsumgebung: SQLWindows
Zeitraum: April 1994 bis Oktober 1994;
__________________________________________________________________________________
Objektorientierte Entwicklungsumgebung: Visual Basic, C++
Zeitraum: Februar 1994 bis März 1994;
__________________________________________________________________________________
Entwicklungsumgebung: MVS/ESA
Zeitraum: November 1993 bis Januar 1994;
__________________________________________________________________________________
Entwicklungsumgebung: MVS/ESA
Zeitraum: Juni 1993 bis September 1993;
__________________________________________________________________________________
parallel dazu:
Erstprojekt in Objektorientierten Technologien: ENFIN/2
Zeitraum: Januar 1993 bis Juni 1993
__________________________________________________________________________________
Es wurden Listenprogramme erstellt und Online-Funktionalitäten erweitert.
Entwicklungsumgebung: BS2000, KORDOBA, überwiegend ASSEMBLER, COBOL
Zeitraum: Mai 1992 bis Dez. 1992
__________________________________________________________________________________
zusammen mit der MOVTEC GmbH, Pforzheim
Entwicklungsumgebung: WINDOWS, C++
Zeitraum: Oktober 1991 bis April 1992
__________________________________________________________________________________
Systementwicklung IBM - Bankterminals - zwei Projekte:
Die ATMs (Automatic Teller Machines) der Familie 473x basieren auf einer speziellen Architektur, die in 8086-Assembler und in der IBM - internen Entwicklungssprache PLAS (ähnlich wie PL/1) entwickelt wird. Um die fortschreitend wachsenden Anforderungen an Grafikleistungen zu erfüllen, wurde zunächst der verfügbare Speicher durch Einbindung einer Speichererweiterungskarte, dem XMA (Expanded Memory Adapter), ausgedehnt und für die Grafikbibliothek nutzbar gemacht. In einem zweiten Schritt wurde die Maschine mit der Fähigkeit ausgestattet, ihre Bilddatenbibliothek mit Delta-Dateien zu aktualisieren. Diese Delta-Dateien werden mit demselben PC-Tool erzeugt, mit dem auch die Bilddatenbibliothek generiert wurde.
Der für die Bilddatenbibliothek des Bankautomaten vorgesehene Speicherplatz wird durch optionale Ansteuerung einer Speicher-Erweiterungskarte ("XMA") vergrößert.
Entwicklung nach High Level Design Vorgabe.
Der vergrößerte Speicherplatz für die Bilddatenbibliothek des Bankautomaten wird genutzt, um die Grafikbibliothek zu verändern.
Entwicklung von Design und Code.
Alle Entwicklungen mit umfassender Dokumentation auf High Level Design, Low Level Design und Code Design Ebene.
Zeitraum: Juli 1989 bis Juni 1991
Aus dem letzten Projekt im IBM-Labor stammt der folgende Limerick, der die Stimmungslage des Entwicklers und des Teams beim Aufbohren der sog. G-Komponente des Customization Image beschreibt:
Once a programmer thought in despair:
"Splitting up the CI is not fair!".
But the cutting location
then became a sensation
when he put the dumm' G-compon'nt there!
ENDE
enthält, wie so oft, bereits die Antwort -
hier in der Gestalt eines Schüttelreimes.
Das Beispiel unterstreicht nachdrücklich
den Wert einer guten Dokumentation.