Eurex kommt auf eine neue Plattform. Die Funktionalität wird
schrittweise von OpenVMS auf eine aus Linux, Jboss
Application Server und Enterprisedb (postgresql) bestehende
Platform umgesetzt, mit Web-basierte User Interfaces.
Ergänzung der Testumgebung. Alle Belange des
Produktionssystems sind abgebildet: JBOSS Application
Servers, Graylog für Logginganalyse, Apache Loadbalancers,
Paare von EnterpriseDB servers unter Veritas, Tomcat
Webservers, AMQP Brokers und Icinga für Monitoring. Alles
über 2 Rechenzentren verteilt wegen Ausfallsicherheit.
Mitwirkung bei der Entwurf neuer Verfahren für Operations,
Configuration, Delivery, Test und Tools. Python, Java, Maven,
subversion, git, apache tomcat, LDAP, apache qpid, Veritas,
eclipse.
Die funktionale Tests wurden in HP-ALM abgebildet.
Meine Hauptaufgabe war, die Sicherstellung der technischen
Verträglichkeit der Lieferungen (Iterations).
Gelieferte Datenbankkonvertierungen mit
Produktionsähnliche Datenmengen durchführen
Konfigurationsparameter überprüfen, Sinn und Wirksamkeit
Steuerungs- und Überwachungs-Möglichkeiten für
Operations
Resourcenbedarf der Komponenten und 'System limits'
kontrollieren
Verhalten unter Last und in Fehlerszenarien
Automation so weit wie möglich
Um dieses nachzukommen war es nötig alle eingehende
Änderungen je nach Relevanz zu Überprüfen sowohl bei den
Ursprungs-Requirement als auch bei der Lösungsansatz.
Passende Testansätze zu entwickeln und zu implementieren,
manchmal unter Zeitdruck. Wir hatten ständig kontakt zu den
Entwicklergruppen. Auch mit Qualitätssicherung und Server-
Operations müssten wir eng zusammenarbeiten.
Andere Änderungsquellen waren z.B. Redhat Linux (RHEL),
Redhat JBOSS-EAP, Postgresql (EnterpriseDB) deren
Versionswechsel auch eingeplant und getestet werden
mussten.
Mitwirkung bei dem Entwurf des Gesamtsystems
Implementierung der Zentralrechnersoftware auf PDP-11
unter RSX in Fortran und Assembler. Kommunikation mit
den Testrechnern über RS-232.
Umfangreiches System, welches die Bearbeitung von
palettenweise angelieferten Rohlingen durch
Bearbeitungsmachinen zu Getriebewellen steuert und
überwacht. Die Paletten werden durch Kräne automatisch zu
ihrem nächsten Bearbeitungsschritt befördert. Alle
Fertigungsinformationen werden am Leitstand bearbeitet
und visualisiert.
Meine Teile des Projekts waren:
- die Implementierung der Gerätetreiber (Device driver)
für VMS und RSX-11, damit die anderen Entwickler
mit den Siemens SPS Rechner an den Kränen und
Bearbeitungsmachinen kommunizieren können.
Angewandtes Protocol: 3964(R)
- Spezifizierung und Implementierung eines verteilten
Datenbank Systems, damit die 8 PDP-11 Processrechner
und die VAX als zentrale Auftragsrechner ihre
Informationen austauschen können, ohne die anderen
Entwickler mit Netzwerkprogrammierung zu belästigen.
Macro-11, VAX-Macro, DECnet
- Entwicklung einer Simulation der Fertigungsstrasse,
damit das Gesamtsystem getestet werden konnte, ohne
die echte Fertigungsstrasse angebunden zu haben.
Hierfür wurde ein System bereitgestellt, das alle in
der Fertigung vorhandenen Siemens SPS mit ihren
jeweiligen Kränen und Bearbeitungsmachinen in ihrer
Art und ihrem zeitlichen Verhalten nachahmte
- Beratung der anderen Entwickler in den feineren
Aspekten der VMS- und RSX-Programmierung
- Systemmanagement für VAXcluster und PDP-11 Systeme
In 1988 wurde das System für einen weiteren Autohersteller
auf einen reinen VAX-Verbund umgestellt und das
Datenbanksystem neu in VAX-Pascal geschrieben. Die
Kommunikation mit den SPS wurde mit Sinec-H1 und
VAX OSAK (jetzt DECnet/OSI) realisiert.
Bereich den einfachen Datenaustausch mit einem zentralen
IBM-Rechner zu ermöglichen.
Das Programm hat sich bei der IBM wie ein interaktiver
Anwender eingeloggt und dann Anfragen von VAX-Anwendungen
an die IBM weitergegeben und die Antworten dann an die
Anwendungen zurückgemeldet. Kommunikation mit der IBM
über 3270 Emulation und mit den Anwendungen über
Mailboxes. Programm war in VAX Fortran geschrieben - der
Kunde bestand darauf - und konnte 50 Anwendungen
gleichzeitig bedienen.
Im Rahmen der Qualitätssicherung ist es erstrebenswert,
für bis zu 10 Jahre nach Abschluss eines Auftrages
nachweisen zu können, nicht nur, daß alle Produktteile
gemessen wurden, sondern auch, daß die verwendeten
Prüfmittel auch zum Zeitpunkt der Messung in Ordnung
waren. Dazu bekam jedes Prüfmittel eine Barcode-Nummer
und es wurde verfolgt, wann dieses Prüfmittel mit welchen
Toleranzwerten kalibriert wurde und von wem es angewendet
wurde. Nach einer vom Prüfmitteltyp abhängigen Zeit
musste das Prüfmittel wieder zur Kalibrierung vorgelegt
werden. Das System hat als Anwender:
- die Kalibrierstellen, die die Messergebnisse eingeben
bzw. nicht mehr kalibrierbare Prüfmittel als Ausschuss
deklarieren
- die Werkzeugsausgaben, die die Prüfmittel lagern, und
an die Mitarbeiter ausleihen und von ihnen zurücknehmen
- der Systemverwalter, der überfällige Prüfmittel bei
den Mitarbeitern zur Rückgabe anmahnt und Statistiken
auswertet
Dieses System wurde unter VAX/VMS mit RDB, FMS und VAX C
realisiert.
Als kleiner Nachtrag wurde in 1992 die Direktanbindung
einer Messmaschine über einen LAT Terminalserver verlangt,
um per Knopfdruck die gemessenen Daten in die Maske
für die Kalibrierung zu übernehmen.
das Problem, daß obwohl sein Spektrometer sehr beliebt
war, er seinen Kunden auch die Übermittlung der Daten
an die unterschiedlichsten Systeme zusichern musste. In
diesem Rahmen entstanden viele kleine Aufgaben, unter
anderem: Einbindung von Röntgen-Spektrometer in den
Fertigungsablauf eines Stahlwerks in China.
Hier kamen drei Spektrometer zum Einsatz
- Proben aus dem Kochtopf wurden während des Kochens
analysiert, um die Hineingabe verschieder Elemente
automatisch zu steuern.
- Eine Probe wurde beim Giessen analysiert als Nachweis
für die Charge
- Die dritte war offline betrieben für Forschungszwecke.
Die Kommunikation mit dem Hauptstahlwerkrechner (eine VAX)
wurde über DECnet abgewickelt. Die Programmierung der
Spektrometerrechner war in PDP-11 Fortran.
Hierbei handelt es sich um eine über die Jahre gewachsene
Umgebung von damals 2 VAXen mit 40 Anwendern auf heute
28 VMS Maschinen in 2 VMSClusters, 4 UNIX Maschinen,
2 NT-Servers und über 200 PCs mit DECnet, TCP/IP, NFS,
Pathworks, Rumba und SNA Gateway.
Ich habe immer beraten bei der Auswahl, dem Einsatz und
der Konfiguration der Hard- und Software-Komponenten.
Der Kunde unterhält eine kleine EDV-Gruppe für
das Tagesgeschäft, die ich als eine Art "Second-level
Support" für die grösseren Probleme unterstütze.
In manchen Fällen habe ich Lösungen mit Hilfe der
jeweiligen C-Compiler und RFC-nnn herbeiführen können.
Manchmal reicht eine DCL Kommando-Prozedur oder
ein Shell-Skript.
Probleme mit Datenkonvertierung zwischen den jeweiligen
Systemen hat immer wieder für Beschäftigung gesorgt. An
einer UNIX Machine habe ich für deren zentrale Sicherung
gesorgt, in dem ich einen speziellen FTP Client
geschrieben habe. An einem Catia-System wurde es
notwendig, den Inhalt eines Modelltopfs aufzulisten. Die
Konvertierung von Schriftstücke eines Unix-Systems nach
All-In-1 kam vor.
Aufgrund meiner langjährigen Erfahrung weiss ich immer,
welcher Ansatz zur Lösung führt.
Ein System für die Verfolgung des Stundenverbrauchs
bei laufenden Aufträgen. Die RDB-Datenbank speichert
die pro Auftrag anfallenden Stunden, die jeder Mitarbeiter
als Stundenzettel an seinem PC eingibt. Die Projektleiter
können im Tagesrhythmus die angefallenen Stunden als
Kosten auf ihren PCs auswerten. Der Systemverwalter
sorgt für die periodische Übermittlung der Daten zum und
vom SAP-System. Dieses eventuell als "Insel-Lösung" zu
bezeichnende System wurde angestrebt, weil es mit viel
niedrigeren Rechnerkosten verbunden war, als die gleiche
Funktionalität direkt in einem geographish weit entfernten
IBM-Grossrechner zu implementieren, wo alle Vorgänge über
Standleitungen abgewickelt werden mussten. So gibt es
definierte Schnittstellen zu SAP und das ganze System
ist vor Ort. RDB VMS System als Datenspeicher, MS-Access
über ODBC für die Auswertungen, C und Visual-Basic
Client-Programme für die Stundeneingabe und
Systemverwalterfunktionen.
Im Laufe der letzten Jahre hat es einige Projekte gegeben.
Der Client betreibt eine grosse VMS-Installation mit
All-In-1 als Haupt-Anwendung, in der er mit seiner
Entwicklungsgruppe seinen EDV-Bedarf deckt. Bei Engpässen
werde ich gerne hinzugezogen, um für absteckbare Aufgaben
die Programmierung zu übernehmen. Diese werden häufig
zu Plug-In Modulen für das All-In-1 System, die
aufwendigere Berechnungen - für All-In-1 selbst kaum
zumutbar - vornehmen. Schwerpunkte hier sind die
Berechnung und Verfolgung von Zahlungen von bewilligten
Forschungsgeldern. Die Programme wurden zum grössten Teil
in DEC C geschrieben mit RDB als Datenbank. Neuerdings
wurde auch eine MS-Access Lösung realisert.
Zwecks logistischer Aussagen zur Erhaltung eines Fahrzeugs
wird eine Datenbank gepflegt, woraus die Fehlerhäufigkeit
eines jeden Bauteils sich errechnen lässt. Zusätzlich
werden in dieser Datenbank die Instandsetzungsschritte mit
der dazugehörigen Personal- und Materialaufwand
gespeichert.
Hieraus lassen sich für jedes Fahrzeug die
Instandhaltungskosten und statistische Ausfallperioden
ermitteln. Da ein neues Fahrzeug zum grössen Teil aus
bekannten oder ähnlichen Bauteilen besteht, sind diese
Kostenfaktoren berechenbar, bevor das Fahrzeug gebaut
wird.
Dieses System nutzt RDB als Speichermedium. Alle
Berechnungen und Ausgaben sind in MS-Access.
Zugriff via ODBC.
Dieses System verfolgt die einzelnen Reparaturaufträge,
die von den Mitarbeitern ausgeführt werden und stellt
die Arbeiten in Rechnung. Klingt einfach, aber die
Regeln für derartige Aufträge weichen um einiges davon
ab, wie man es in der Industrie gewöhnt ist. Dieses
Projekt wurde mit MS-Access, C und RDB realisiert.
Als Ergänzung zum obigen Projektverfolgungssystem
werden die Projekte in allen Einzelheiten geplant, um
die Daten den Iststunden gegenüber zu stellen und
Kapazitätsmangel oder drohenden Terminverzug frühzeitig
zu erkennen. Jeder Projektleiter gibt seine Planung ein.
Jede ausführende Einheit kann ihre Auslastung anhand
dieser Planung erkennen. Dieses Projekt wurde mit
MS-Access, C und RDB realisiert.
Zeitraum: 10.1997 - 31.12.1998
Firma/Institut: eine grössere Derivaten Börse in Frankfurt.
Projekt: Euro Einführung.
Die Entwicklung, in einem kleinen Team, eines Verfahrens der so lange einstudiert wird bis Fehler ausgeschlossen sind. Haupt Bedingungen: Korrektheit. Kein Terminverzug. Keine Nachbesserung.
Zeitraum: 10.1999 -
Firma/Institut: eine grössere Derivaten Börse in Frankfurt.
Projekt: Weitere Verfolgung der unterschiedlichen Ziele.
- Actual/actual Zinsberechnung
- Perfomance enhancements
- Integrated Clearing
- Risk Engine
- Data Warehuse
- Eurex/US
- Global Clearing Link
- Common report engine
Eurex kommt auf eine neue Plattform. Die Funktionalität wird
schrittweise von OpenVMS auf eine aus Linux, Jboss
Application Server und Enterprisedb (postgresql) bestehende
Platform umgesetzt, mit Web-basierte User Interfaces.
Ergänzung der Testumgebung. Alle Belange des
Produktionssystems sind abgebildet: JBOSS Application
Servers, Graylog für Logginganalyse, Apache Loadbalancers,
Paare von EnterpriseDB servers unter Veritas, Tomcat
Webservers, AMQP Brokers und Icinga für Monitoring. Alles
über 2 Rechenzentren verteilt wegen Ausfallsicherheit.
Mitwirkung bei der Entwurf neuer Verfahren für Operations,
Configuration, Delivery, Test und Tools. Python, Java, Maven,
subversion, git, apache tomcat, LDAP, apache qpid, Veritas,
eclipse.
Die funktionale Tests wurden in HP-ALM abgebildet.
Meine Hauptaufgabe war, die Sicherstellung der technischen
Verträglichkeit der Lieferungen (Iterations).
Gelieferte Datenbankkonvertierungen mit
Produktionsähnliche Datenmengen durchführen
Konfigurationsparameter überprüfen, Sinn und Wirksamkeit
Steuerungs- und Überwachungs-Möglichkeiten für
Operations
Resourcenbedarf der Komponenten und 'System limits'
kontrollieren
Verhalten unter Last und in Fehlerszenarien
Automation so weit wie möglich
Um dieses nachzukommen war es nötig alle eingehende
Änderungen je nach Relevanz zu Überprüfen sowohl bei den
Ursprungs-Requirement als auch bei der Lösungsansatz.
Passende Testansätze zu entwickeln und zu implementieren,
manchmal unter Zeitdruck. Wir hatten ständig kontakt zu den
Entwicklergruppen. Auch mit Qualitätssicherung und Server-
Operations müssten wir eng zusammenarbeiten.
Andere Änderungsquellen waren z.B. Redhat Linux (RHEL),
Redhat JBOSS-EAP, Postgresql (EnterpriseDB) deren
Versionswechsel auch eingeplant und getestet werden
mussten.
Mitwirkung bei dem Entwurf des Gesamtsystems
Implementierung der Zentralrechnersoftware auf PDP-11
unter RSX in Fortran und Assembler. Kommunikation mit
den Testrechnern über RS-232.
Umfangreiches System, welches die Bearbeitung von
palettenweise angelieferten Rohlingen durch
Bearbeitungsmachinen zu Getriebewellen steuert und
überwacht. Die Paletten werden durch Kräne automatisch zu
ihrem nächsten Bearbeitungsschritt befördert. Alle
Fertigungsinformationen werden am Leitstand bearbeitet
und visualisiert.
Meine Teile des Projekts waren:
- die Implementierung der Gerätetreiber (Device driver)
für VMS und RSX-11, damit die anderen Entwickler
mit den Siemens SPS Rechner an den Kränen und
Bearbeitungsmachinen kommunizieren können.
Angewandtes Protocol: 3964(R)
- Spezifizierung und Implementierung eines verteilten
Datenbank Systems, damit die 8 PDP-11 Processrechner
und die VAX als zentrale Auftragsrechner ihre
Informationen austauschen können, ohne die anderen
Entwickler mit Netzwerkprogrammierung zu belästigen.
Macro-11, VAX-Macro, DECnet
- Entwicklung einer Simulation der Fertigungsstrasse,
damit das Gesamtsystem getestet werden konnte, ohne
die echte Fertigungsstrasse angebunden zu haben.
Hierfür wurde ein System bereitgestellt, das alle in
der Fertigung vorhandenen Siemens SPS mit ihren
jeweiligen Kränen und Bearbeitungsmachinen in ihrer
Art und ihrem zeitlichen Verhalten nachahmte
- Beratung der anderen Entwickler in den feineren
Aspekten der VMS- und RSX-Programmierung
- Systemmanagement für VAXcluster und PDP-11 Systeme
In 1988 wurde das System für einen weiteren Autohersteller
auf einen reinen VAX-Verbund umgestellt und das
Datenbanksystem neu in VAX-Pascal geschrieben. Die
Kommunikation mit den SPS wurde mit Sinec-H1 und
VAX OSAK (jetzt DECnet/OSI) realisiert.
Bereich den einfachen Datenaustausch mit einem zentralen
IBM-Rechner zu ermöglichen.
Das Programm hat sich bei der IBM wie ein interaktiver
Anwender eingeloggt und dann Anfragen von VAX-Anwendungen
an die IBM weitergegeben und die Antworten dann an die
Anwendungen zurückgemeldet. Kommunikation mit der IBM
über 3270 Emulation und mit den Anwendungen über
Mailboxes. Programm war in VAX Fortran geschrieben - der
Kunde bestand darauf - und konnte 50 Anwendungen
gleichzeitig bedienen.
Im Rahmen der Qualitätssicherung ist es erstrebenswert,
für bis zu 10 Jahre nach Abschluss eines Auftrages
nachweisen zu können, nicht nur, daß alle Produktteile
gemessen wurden, sondern auch, daß die verwendeten
Prüfmittel auch zum Zeitpunkt der Messung in Ordnung
waren. Dazu bekam jedes Prüfmittel eine Barcode-Nummer
und es wurde verfolgt, wann dieses Prüfmittel mit welchen
Toleranzwerten kalibriert wurde und von wem es angewendet
wurde. Nach einer vom Prüfmitteltyp abhängigen Zeit
musste das Prüfmittel wieder zur Kalibrierung vorgelegt
werden. Das System hat als Anwender:
- die Kalibrierstellen, die die Messergebnisse eingeben
bzw. nicht mehr kalibrierbare Prüfmittel als Ausschuss
deklarieren
- die Werkzeugsausgaben, die die Prüfmittel lagern, und
an die Mitarbeiter ausleihen und von ihnen zurücknehmen
- der Systemverwalter, der überfällige Prüfmittel bei
den Mitarbeitern zur Rückgabe anmahnt und Statistiken
auswertet
Dieses System wurde unter VAX/VMS mit RDB, FMS und VAX C
realisiert.
Als kleiner Nachtrag wurde in 1992 die Direktanbindung
einer Messmaschine über einen LAT Terminalserver verlangt,
um per Knopfdruck die gemessenen Daten in die Maske
für die Kalibrierung zu übernehmen.
das Problem, daß obwohl sein Spektrometer sehr beliebt
war, er seinen Kunden auch die Übermittlung der Daten
an die unterschiedlichsten Systeme zusichern musste. In
diesem Rahmen entstanden viele kleine Aufgaben, unter
anderem: Einbindung von Röntgen-Spektrometer in den
Fertigungsablauf eines Stahlwerks in China.
Hier kamen drei Spektrometer zum Einsatz
- Proben aus dem Kochtopf wurden während des Kochens
analysiert, um die Hineingabe verschieder Elemente
automatisch zu steuern.
- Eine Probe wurde beim Giessen analysiert als Nachweis
für die Charge
- Die dritte war offline betrieben für Forschungszwecke.
Die Kommunikation mit dem Hauptstahlwerkrechner (eine VAX)
wurde über DECnet abgewickelt. Die Programmierung der
Spektrometerrechner war in PDP-11 Fortran.
Hierbei handelt es sich um eine über die Jahre gewachsene
Umgebung von damals 2 VAXen mit 40 Anwendern auf heute
28 VMS Maschinen in 2 VMSClusters, 4 UNIX Maschinen,
2 NT-Servers und über 200 PCs mit DECnet, TCP/IP, NFS,
Pathworks, Rumba und SNA Gateway.
Ich habe immer beraten bei der Auswahl, dem Einsatz und
der Konfiguration der Hard- und Software-Komponenten.
Der Kunde unterhält eine kleine EDV-Gruppe für
das Tagesgeschäft, die ich als eine Art "Second-level
Support" für die grösseren Probleme unterstütze.
In manchen Fällen habe ich Lösungen mit Hilfe der
jeweiligen C-Compiler und RFC-nnn herbeiführen können.
Manchmal reicht eine DCL Kommando-Prozedur oder
ein Shell-Skript.
Probleme mit Datenkonvertierung zwischen den jeweiligen
Systemen hat immer wieder für Beschäftigung gesorgt. An
einer UNIX Machine habe ich für deren zentrale Sicherung
gesorgt, in dem ich einen speziellen FTP Client
geschrieben habe. An einem Catia-System wurde es
notwendig, den Inhalt eines Modelltopfs aufzulisten. Die
Konvertierung von Schriftstücke eines Unix-Systems nach
All-In-1 kam vor.
Aufgrund meiner langjährigen Erfahrung weiss ich immer,
welcher Ansatz zur Lösung führt.
Ein System für die Verfolgung des Stundenverbrauchs
bei laufenden Aufträgen. Die RDB-Datenbank speichert
die pro Auftrag anfallenden Stunden, die jeder Mitarbeiter
als Stundenzettel an seinem PC eingibt. Die Projektleiter
können im Tagesrhythmus die angefallenen Stunden als
Kosten auf ihren PCs auswerten. Der Systemverwalter
sorgt für die periodische Übermittlung der Daten zum und
vom SAP-System. Dieses eventuell als "Insel-Lösung" zu
bezeichnende System wurde angestrebt, weil es mit viel
niedrigeren Rechnerkosten verbunden war, als die gleiche
Funktionalität direkt in einem geographish weit entfernten
IBM-Grossrechner zu implementieren, wo alle Vorgänge über
Standleitungen abgewickelt werden mussten. So gibt es
definierte Schnittstellen zu SAP und das ganze System
ist vor Ort. RDB VMS System als Datenspeicher, MS-Access
über ODBC für die Auswertungen, C und Visual-Basic
Client-Programme für die Stundeneingabe und
Systemverwalterfunktionen.
Im Laufe der letzten Jahre hat es einige Projekte gegeben.
Der Client betreibt eine grosse VMS-Installation mit
All-In-1 als Haupt-Anwendung, in der er mit seiner
Entwicklungsgruppe seinen EDV-Bedarf deckt. Bei Engpässen
werde ich gerne hinzugezogen, um für absteckbare Aufgaben
die Programmierung zu übernehmen. Diese werden häufig
zu Plug-In Modulen für das All-In-1 System, die
aufwendigere Berechnungen - für All-In-1 selbst kaum
zumutbar - vornehmen. Schwerpunkte hier sind die
Berechnung und Verfolgung von Zahlungen von bewilligten
Forschungsgeldern. Die Programme wurden zum grössten Teil
in DEC C geschrieben mit RDB als Datenbank. Neuerdings
wurde auch eine MS-Access Lösung realisert.
Zwecks logistischer Aussagen zur Erhaltung eines Fahrzeugs
wird eine Datenbank gepflegt, woraus die Fehlerhäufigkeit
eines jeden Bauteils sich errechnen lässt. Zusätzlich
werden in dieser Datenbank die Instandsetzungsschritte mit
der dazugehörigen Personal- und Materialaufwand
gespeichert.
Hieraus lassen sich für jedes Fahrzeug die
Instandhaltungskosten und statistische Ausfallperioden
ermitteln. Da ein neues Fahrzeug zum grössen Teil aus
bekannten oder ähnlichen Bauteilen besteht, sind diese
Kostenfaktoren berechenbar, bevor das Fahrzeug gebaut
wird.
Dieses System nutzt RDB als Speichermedium. Alle
Berechnungen und Ausgaben sind in MS-Access.
Zugriff via ODBC.
Dieses System verfolgt die einzelnen Reparaturaufträge,
die von den Mitarbeitern ausgeführt werden und stellt
die Arbeiten in Rechnung. Klingt einfach, aber die
Regeln für derartige Aufträge weichen um einiges davon
ab, wie man es in der Industrie gewöhnt ist. Dieses
Projekt wurde mit MS-Access, C und RDB realisiert.
Als Ergänzung zum obigen Projektverfolgungssystem
werden die Projekte in allen Einzelheiten geplant, um
die Daten den Iststunden gegenüber zu stellen und
Kapazitätsmangel oder drohenden Terminverzug frühzeitig
zu erkennen. Jeder Projektleiter gibt seine Planung ein.
Jede ausführende Einheit kann ihre Auslastung anhand
dieser Planung erkennen. Dieses Projekt wurde mit
MS-Access, C und RDB realisiert.
Zeitraum: 10.1997 - 31.12.1998
Firma/Institut: eine grössere Derivaten Börse in Frankfurt.
Projekt: Euro Einführung.
Die Entwicklung, in einem kleinen Team, eines Verfahrens der so lange einstudiert wird bis Fehler ausgeschlossen sind. Haupt Bedingungen: Korrektheit. Kein Terminverzug. Keine Nachbesserung.
Zeitraum: 10.1999 -
Firma/Institut: eine grössere Derivaten Börse in Frankfurt.
Projekt: Weitere Verfolgung der unterschiedlichen Ziele.
- Actual/actual Zinsberechnung
- Perfomance enhancements
- Integrated Clearing
- Risk Engine
- Data Warehuse
- Eurex/US
- Global Clearing Link
- Common report engine
Direktester geht's nicht! Ganz einfach Freelancer finden und direkt Kontakt aufnehmen.