• Im Projekt wird für einen Kunden 12mio elektronischen Rechnungen/Jahr der über 3,000 Partner elektronisch angebunden hat die ZUGFeRD/Factur-X Lese- und Schreibfunktionalität in C# auf Basis von iText implementiert. 
• Das Backend läuft dabei auf der Azure Cloud mit Hilfe von Service-Bus-Warteschlangen. 
• Die Entwicklung erfolgt unter Einsatz von Azure Devops und Teams, entsprechende E-Rechnungs- und XML-Knowledge-Transfer-Videos wurden ebenfalls umgesetzt. 

• Im Rahmen des Prototypefund und dadurch gefördert vom Bundesministerium für Bildung und Forschung habe ich mit einem Kollegen den Open-Source-E-Rechnungsviewer Quba () entwickelt und als Linux-, Mac- und Windows-Download zur Verfügung gestellt. Als technische Basis diente das Electron-Framework, die XSLT-basierte Kosit-X-Rechnungs-Visualisierung und Saxon.js.

Phase 1: 04/2018 ? 08/2018

• Implementierung einer neuen Version eines telefonischen Alarmierungssystems im Team mit drei C++-Programmierern. Das System wird beispielsweise an Flughäfen eingesetzt wird um bis zu 120 Personen gleichzeitig telefonisch zu erreichen. Die zuständigen Disponenten beim Kunden nutzen das PHP-Frontend, um den Kreis der telefonisch zu alarmierenden Personen zu definieren, die entsprechende Alarmierungsnachricht zusammenzustellen. Dabei werden Ansagen, Aufnahme-"Konserven" oder Text-to-Speech-Elementen in der Alarmierung ergänzt. Danach werden die Alarmierungen ausgelöst und verfolgt, insbesondere wie viele alarmierte Personen den Anruf durch Tastendruck quittiert haben. Die Lösung lief unter MySQL/MariaDB oder alternativ Oracle 12g. Single-Sign On und LDAP wurden entsprechend dem Realisierungspflichtenheft implementiert. Ich habe mich für Mustache als Templating Engine und PHP/DI für Dependency Injection entschieden. Ab 2019 wurde zusätzlich die Performance bei größeren Teilnehmerkreisen erst durch Memcached, dann durch Redis verbessert. Ich habe bei der GitLab-Erweiterung zum Continuos-Integration-Server, d.h. beim automatischen Deployment über Gitlab Runner geholfen und zur späteren Wiederverwendung von Teilen des Codes ein firmeneigenes Composer-Repository aufgesetzt. Die Backend-Module der Kollegen sind in C++ geschrieben. 

Phase 2: 08/2018 ? 05/2019

• Zusätzlich waren Wartungsarbeiten und Erweiterungen des Frontend eines Lautsprecherdurchsagesystems für Flughäfen nötig. Nach Einarbeitung, Erweiterung der Tests und Erstellung einer Entwicklerdokumentation sowie kleineren Ergänzungen habe ich auch größere Teile, Teils mit automatisierten Tests (PHPUnit), überarbeitet. Refactored wurde beispielsweise der Parser für die Scriptsprache zum Definieren von Text-to-Speech-Formularen. Korrigiert wurde beispielsweise die Listenaktualisierung. Weiterhin wurden die (mindestens) vier auseinanderlaufenden Entwicklungslinien zu einem Produkt vereinheitlicht, indem die Code-Basis zusammengelegt und konfigurierbar gemacht wurde. Ich habe zu einem werdenden Projekt durch eine praktische Machbarkeitsstudie zu einer cloudbasierten Text-To-Speech-Lösung beigetragen die auf dem Amazon Polly ?Cloud Service? aufsetzt. 

• Ein Durchsagenmanagement für ein Projekt haben wir erstmals als Single Page Application (SPA) mit Node, NPM, Webpack und Vue.js realisiert. Dabei werden erstmals SVG- statt PNG-Karten verwenden und verschieb- und zoombar dargestellt und mittlerweile zwölf (neun von mir) wiederverwendbare herstellereigene Javascript-Komponenten erstellt und in das firmeneigene NPM-Repository, ebenfalls auf Gitlab-Basis, eingecheckt. Nach dem Go-Live im März 21 wird die Anwendung von mir noch manchmal gewartet und wurde durch einen Kollegen in ein Produkt weiterentwickelt das auch an andere Kunden vertrieben wurde und wird. 

Phase 4: 11/2019 ? heute

• Zusätzlich wurde diese neue technische Basis der Vue-basierten Single-Page-Applications ab November 2019 eine Neuauflage eines bestehenden Produkts zur Verwaltung von aufgesprochenen, gespeicherten und synthetisierten geplanten, automatischen und manuellen Lautsprecherdurchsagen verwendet, das am 12.04.2022 in Version 1.0 veröffentlicht wurde und derzeit noch weiter entwickelt wird. Dieses Produkt ersetzt sukzessive das noch von mir übernommene und gewartete Vorgängerprodukt und wird unter anderem auf einigen Flughäfen eingesetzt. 

• Auf einem ZUGFeRD Entwicklertag wurde ich gebeten, für die ZUGFeRD-Community (auf Anfrage) basierend auf meiner Sammlung von ZUGFeRD-Dateien (auf Anfrage) eine Validierer-Engine zu entwickeln, um den Sprung auf ZUGFeRD 2 zu ermöglichen. Um auch die Validierung des PDF-A-Teils zu ermöglichen habe ich es zunächst als VeraPDF-Plugin veröffentlicht, kurz darauf aber VeraPDF selbst in meine Software eingebettet. Das habe ich getan und als Open-Source auf  veröffentlicht, sie wird beispielsweise auf  eingesetzt. ZUV verwendet zu 50% VeraPDF und zu ca. 45% die offiziellen Prüfdateien (Schema- und Schematron sowie Codelisten) der Herausgeber (CEN, AWV und Kosit sowie Andreas Starke?s ?Additional Data? Branchenerweiterungen): lediglich ein Bruchteil der Validiererlogik ist selbst geschrieben. ZUV unterstützt ZUGFeRD 1 und 2 und XRechnung 1.2.2 und wurde erfolgreich in Mustang 2 eingegliedert.

• Das auf Apache PDFBox basierende ZUGFeRD-Modul von Gnuaccounting (Projekt 1) habe ich als eigene Bibliothek umgesetzt und unter (auf Anfrage) als permissives Open-Source-Projekt freigegeben. Es wurde von der Open Source Business Alliance 2015 mit dem ?OSBAR? ausgezeichnet und weist bis heute eine höhere Aktivität als Gnuaccounting auf. Sehr früh wurde die reine Bibliothek von der Community um eine Möglichkeit, eigenes XML anzugeben erweitert, nach einiger Zeit habe ich auch ein kleines Kommandozeilenprogramm beigesteuert mit dem anfangs ZUGFeRD-Rechnungen nur gezählt, dann auch aus PDF und XML-Datei kombiniert beziehungsweise die XML-Informationen extrahiert werden konnten. Dann kam noch ein Patch für den Batchbetrieb. Aktuell bringt die Entwicklerversion von Mustang 2 auch Support für ZUGFeRD 2.1.1 und dessen XRechnungsprofil sowie den den Validierer (ZUV, Projekt 4) als Bibliothek und zur Nutzung über die Kommandozeile.

Mustangproject.org: Zusätzliche Attribute

• Bestimmte (?GlobalID?) Attribute für Tradeparty (bspw. GLN) und Positionen (bspw. GTIN) wurden auf Kundenanforderung implementiert, die Tradeparty- und Rechnungsklasse und der Rechnungsklassen-Importer von Mustangproject.org wurde entsprechend erweitert.

• Ein Konzern löst Konik ab und braucht einen Parser für bestimmte Attribute von Positionen. Die Rechnungsklasse und der Rechnungsklassen-Importer von Mustangproject.org wurde entsprechend erweitert.

• Der Kunde hat in Java sein eigenes ERP- und Abrechnungssystem entwickelt, das auch Factur-X/ZUGFeRD-Dateien unterstützen sollte. Schwerpunkt waren unter anderem Abrechnungszeiträume.

• Ich habe das Produkt meines Kunden zunächst um ein (UN/CEFACT) XRechnungs- dann um ein ZUGFeRD-Feature erweitert. Da nur PDF (kein PDF/A) zur Verfügung stand habe ich Ghostscript zur Umwandlung in valides ZUGFeRD PDF/A-3 und zum Einbetten der XML-Dateien in die Software verwendet. Zum Lesen der ZUGFeRD-Dateien wurde das XML mit iText aus den PDF-Dateien extrahiert. Geprüft wurde regelmäßig mit Kosit?s Open Source XRechnungs-Validierungstool und mit meinem eigenen ZUGFeRD-Validierer ZUV (später in Mustang aufgenommen).      

• Der Kunde erhält je nach Bedarf in der Regel zwischen einer und zehn Stunden Remote-Support pro Monat, die Ergebnisse werden im regulären open-source-Mustang umgesetzt. Dafür gibt es normalerweise alle zwei Wochen eine koordinierende Videokonferenz. Besonders in der Anfangsphase konnten viele Fragen geklärt werden, wurden Anforderungen analysiert und durch sowohl durch den Kunden in seiner Codebasis als auch durch mich mit neuen Open-Source-Features umgesetzt.

• Ich war im Review-Team für die ZUGFeRD-Versionen 2.1.0 und 2.1.1 tätig und habe mich vor allem auf die Schema- und Schematrondateien und Codelisten konzentriert indem ich diese gegen die zu veröffentlichenden ZUGFeRD-Beispieldateien geprüft habe. Dabei konnte ich die AWV dazu bewegen, Gitlab einzuführen, weil eine entsprechende Versuchsphase in 2.1.0 sehr effizient verlaufen war.
• In 2.1.1 konnte ich die halbautomatischen (positiv-)Tests, die nur durch mich durchgeführt werden konnten, weil ich dafür eigene Versionen meines ZUV-Validierers erstellen musste, durch vollautomatische positiv- und negativtests ersetzen. Dazu habe ich den Validierer als ?Submodul? eingebunden und befähigt, sich selbst zu aktualisieren, zu bauen, und rekursiv ganze Verzeichnisse zu validieren.

• Ich war im Review-Team für die ZUGFeRD-Versionen 2.1.0 und 2.1.1 tätig und habe mich vor allem auf die Schema- und Schematrondateien und Codelisten konzentriert indem ich diese gegen die zu veröffentlichenden ZUGFeRD-Beispieldateien geprüft habe. Dabei konnte ich die AWV dazu bewegen, Gitlab einzuführen, weil eine entsprechende Versuchsphase in 2.1.0 sehr effizient verlaufen war.
• In 2.1.1 konnte ich die halbautomatischen (positiv-)Tests, die nur durch mich durchgeführt werden konnten, weil ich dafür eigene Versionen meines ZUV-Validierers erstellen musste, durch vollautomatische positiv- und negativtests ersetzen. Dazu habe ich den Validierer als ?Submodul? eingebunden und befähigt, sich selbst zu aktualisieren, zu bauen, und rekursiv ganze Verzeichnisse zu validieren.

• Im Team des Kunden habe ich am Relaunch der Website eines Instituts (?Journalistisches Seminar?) einer Universität mit gearbeitet. Dabei kam Laravel Zero als Framework für zu programmierende Entwicklertools und Blade als Template Engine sowie Webpack als SCSS-Compiler zum Einsatz. Meine Aufgabe waren zwei projektspezifische Wordpress-Plugins, die Breadcrumb, die Social-Link Funktionalität und Entwicklertools im Laravel Zero Framework sowie die Grids für einen Custom Post Type.

• Der Kunde betreibt öffentliche Hotspots beispielsweise in Cafés und Einkaufszentren. Dafür benutzt er eine in PHP geschriebene Verwaltungssoftware. In meinem ersten ?Full remote? Projekt habe ich unter anderem zur Authentifizierung beigetragen, sodass sich Nutzer einfacher, nämlich mit ihrem Facebook-Account, einwählen konnten und der Betreiber beispielsweise vereinfacht, durch einfaches Zustimmen der Nutzer, Emailadressen erheben konnte.

• Für einen Relaunch der Website einer Zeitschriftenfamilie wurde ein begonnenes, selbst entwickeltes responsives Content-Management-System auf PHP/MySQL-Basis fertig entwickelt und ein Drupal-6-System damit abgelöst. Zusätzlich zur Projektarbeit habe ich zur Modernisierung der Infrastruktur beispielsweise durch die Einführung von Gitlab, Eclipse, xDebug, Proxmox/KVM, Vagrant und Google Tag Manager beigetragen und in einer Übergangsphase Linienarbeit übernommen und einen neuen internen Kollege eingearbeitet. Zusätzlich zur technischen Dokumentation des Projekts habe ich eine Dokumentation speziell für die Migrationsphase geschrieben und alle bestehenden Systeme der Onlineabteilung kartografiert.

• Das Onlineteam beim Kunden sammelt und koordiniert Schaltungen von Werbeanzeigen auf den Webseiten diverser Zeitungen. Zum Teil wurden dafür normale Emails, zum Teil Formulare benutzt die als PDF-Anhang an Emails angehängt wurden
• Um das Ausfüllen bestimmter Zusatzinformationen unter bestimmten Bedingungen zu ermöglichen habe ich eine Intranetanwendung zunächst als Wireframe entwickelt, daraus ein ER-Diagramm für die Datenbank erstellt, mit Doctrine Entity-Klassen generiert und die Anwendung schließlich in Zend Framework 2 umgesetzt

• Ab Januar 2014 war meine Aufgabe die Pflege und Wartung des Produkts FastBill Plus meines Bestandskunden. Innerhalb dieser Aufgabe 
  • behob ich Programmierfehler und half dem Support bei bestimmten Vorfällen 
  • Trug zu Dokumentation und Spezifikationen bei 
  • Führe Refactorings (Konsolidierungen der Anwendung) aus 
  • Übernahm Features aus dem Schwesterprodukt 
  • Implementierte neuer Features 
  • Führte manuellen Tests ein wo sie nötig waren und erweiterte die automatischen Tests 
  • Regte einen Usability-Test der Anwendung im Rahmen eines ?Usability-Testessens? an 
  • Bildete einen Mitarbeiter des Supports im Rahmen einer innerbetrieblichen Weiterbildung zum (ITSQB ?Foundation?-zertifizierten) Softwaretester aus
  • Führte Peer Reviews des Codes von Kollegen durch
• Bis 2013 hat der direkte Ansprechpartner beim Kunde selbst mitprogrammiert. Seiner Aussage nach konnte er sich 2014 auf die Aufsicht (Review der Programmänderungen) und ab 2015 auf die reine Prozessgestaltung konzentrieren. 

• IMS Health Germany (ca. 300 MA, Branche: Pharma) erstellt und verkauft Studien über Verkäufe von verschreibungs- und nichtverschreibungspflichtigen Medikamenten sowie medizinischem Hilfs- (wie beispielsweise Tupfern) und Diagnosebedarf (wie beispielsweise Teststreifen) in Deutschland
• Dazu werden Daten von verschiedenen Anbietern gekauft und unter anderem über ein internes PHP-basiertes ETL- und Produktionstools in ein Data Warehouse, ein spaltenbasiertes in-Memory ExaSol-Cluster, eingespielt. Das Tool dient auch der Datenbereitstellung für andere Systeme und zur Verarbeitung und Ausgabe von Produktkomponenten und Produkten
• In der ersten Phase vom 18.08.-31.12.2013 war meine Aufgabe, um einen kundeninternen Kollegen früher für ein anderes Projekt freizustellen, die Übernahme der Wartung und Weiterentwicklung des dafür genutzten ETL- und Produktionstools von dem Kollegen und die Übergabe an den neuen, später eingestellten kundeninternen Kollegen. Zu meinen Tätigkeiten gehörte das Zusammentragen von Informationen und Analyse der bestehenden Lösung zwecks Dokumentation auch in Form von Übersichtscharts und Video-Tutorials, die Erfassung noch zu erledigender Entwicklungsaufgaben in Jira und die Weitergabe von technischem Know-How in Form von Workshops beispielsweise zum Thema JQuery oder PHP-Debugging mit xDebug
• Meine Tätigkeiten im Bereich Pflege und Weiterentwicklung der Anwendung erstreckten sich beispielsweise auf die Übersetzung der Anwendung in englisch, um Kollegen im Produktionsteam in Manila einen direkten Zugriff zu erlauben, sowie der Erweiterung und Konsolidierung wie die Automatisierung einiger vorher manuell auszuführenden ExaSol-SQL-Scripte, Integration eines Datentest-System und der Produktion eines weiteren Produkts, die vorher auf anderen, teils außer Betrieb gehenden Systemen angesiedelt waren
• Des weiteren erstellte ich ein Konzept für den Knowledge-Transfer für das im Aufbau befindliche Offshore-Entwicklungsteam und führte mehrere Knowledge-Transfer-Webinare durch
• In der zweiten Phase vom 01.02.2014-01.04.2013 wurde ein Bestandsprodukt grundlegend neu implementiert. Da der entsprechende Business Analyst ausfiel habe ich aus den teils geänderten Anforderungen der Fachabteilungen die Spezifikation erarbeitet und Dokumentation über die bestehende Version teils zusammengetragen und teils erstellt
• Dabei habe ich sowohl Fragen der Fachabteilung, der Projektleitung und des Entwicklers beantwortet oder vermittelt, sowohl mit Fachabteilung als auch mit dem Entwickler Beispiele erstellt, vervollständigt und durchgespielt und gemeinsam eine Architektur der späteren Anwendung sowie ein Plan zum Anpassen der bestehenden Anwendung entwickelt. Die Kunden erhielten dann im Mai erstmals Daten aus der neuen Version des Berichts. 

• Ab Januar 2014 war meine Aufgabe die Pflege und Wartung des Produkts FastBill Plus meines Bestandskunden. Innerhalb dieser Aufgabe 
  • behob ich Programmierfehler und half dem Support bei bestimmten Vorfällen
  • Trug zu Dokumentation und Spezifikationen bei
  • Führe Refactorings (Konsolidierungen der Anwendung) aus 
  • Übernahm Features aus dem Schwesterprodukt 
  • Implementierte neuer Features 
  • Führte manuellen Tests ein wo sie nötig waren und erweiterte die automatischen Tests 
  • Regte einen Usability-Test der Anwendung im Rahmen eines ?Usability-Testessens? an 
  • Bildete einen Mitarbeiter des Supports im Rahmen einer innerbetrieblichen Weiterbildung zum (ITSQB ?Foundation?-zertifizierten) Softwaretester aus 
  • Führte Peer Reviews des Codes von Kollegen durch
• Bis 2013 hat der direkte Ansprechpartner beim Kunde selbst mitprogrammiert. Seiner Aussage nach konnte er sich 2014 auf die Aufsicht (Review der Programmänderungen) und ab 2015 auf die reine Prozessgestaltung konzentrieren

• IMS Health Germany (ca. 300 MA, Branche: Pharma) erstellt und verkauft Studien über Verkäufe von verschreibungs- und nichtverschreibungspflichtigen Medikamenten sowie medizinischem Hilfs- (wie beispielsweise Tupfern) und Diagnosebedarf (wie beispielsweise Teststreifen) in Deutschland
• Dazu werden Daten von verschiedenen Anbietern gekauft und unter anderem über ein internes PHP-basiertes ETL- und Produktionstools in ein Data Warehouse, ein spaltenbasiertes in-Memory ExaSol-Cluster, eingespielt. Das Tool dient auch der Datenbereitstellung für andere Systeme und zur Verarbeitung und Ausgabe von Produktkomponenten und Produkten
• In der ersten Phase vom 18.08.-31.12.2013 war meine Aufgabe, um einen kundeninternen Kollegen früher für ein anderes Projekt freizustellen, die Übernahme der Wartung und Weiterentwicklung des dafür genutzten ETL- und Produktionstools von dem Kollegen und die Übergabe an den neuen, später eingestellten kundeninternen Kollegen. Zu meinen Tätigkeiten gehörte das Zusammentragen von Informationen und Analyse der bestehenden Lösung zwecks Dokumentation auch in Form von Übersichtscharts und Video-Tutorials, die Erfassung noch zu erledigender Entwicklungsaufgaben in Jira und die Weitergabe von technischem Know-How in Form von Workshops beispielsweise zum Thema JQuery oder PHP-Debugging mit xDebug
• Meine Tätigkeiten im Bereich Pflege und Weiterentwicklung der Anwendung erstreckten sich beispielsweise auf die Übersetzung der Anwendung in englisch, um Kollegen im Produktionsteam in Manila einen direkten Zugriff zu erlauben, sowie der Erweiterung und Konsolidierung wie die Automatisierung einiger vorher manuell auszuführenden ExaSol-SQL-Scripte, Integration eines Datentest-System und der Produktion eines weiteren Produkts, die vorher auf anderen, teils außer Betrieb gehenden Systemen angesiedelt waren
• Des weiteren erstellte ich ein Konzept für den Knowledge-Transfer für das im Aufbau befindliche Offshore-Entwicklungsteam und führte mehrere Knowledge-Transfer-Webinare durch
• In der zweiten Phase vom 01.02.2014-01.04.2013 wurde ein Bestandsprodukt grundlegend neu implementiert. Da der entsprechende Business Analyst ausfiel habe ich aus den teils geänderten Anforderungen der Fachabteilungen die Spezifikation erarbeitet und Dokumentation über die bestehende Version teils zusammengetragen und teils erstellt
• Dabei habe ich sowohl Fragen der Fachabteilung, der Projektleitung und des Entwicklers beantwortet oder vermittelt, sowohl mit Fachabteilung als auch mit dem Entwickler Beispiele erstellt, vervollständigt und durchgespielt und gemeinsam eine Architektur der späteren Anwendung sowie ein Plan zum Anpassen der bestehenden Anwendung entwickelt. Die Kunden erhielten dann im Mai erstmals Daten aus der neuen Version des Berichts

• Die Hexagon Metrology GmbH (ca. 250 MA, Branche: Industrie) in Wetzlar stellt Industrieroboter zur Qualitätssicherung her. Bestimmte Funktionen dieser Roboter wurden softwareseitig mit einer proprietären C++-Lösung über eine ansonsten in PHP realisierten Website aktiviert
• Das Projekt beinhaltete die Umstellung dieser Funktionalität auf eine Standard-Lizensierungslösung, die Implementation einer Hardwaredatenbank für die Komponenten der Maschinen, die Erweiterung der Funktionalität auf eine Hardwareaktivierung sowie die Detailerfassung der Anforderungen und die enge Kooperation mit einem Kollegen, der für die Implementierung der Funktionalität in den Maschinen zuständig ist
• Nachdem die neue Softwareversion ausgerollt war und nach einer mehrmonatige Testphase mit der neuen Softwareversion wurde die Beschränkung ?scharf geschaltet? und seit dem 18.07.2014 sorgt die von mir entwickelte Lizensierungswebsite dafür, dass nur zertifizierte Hardware betrieben wird und Softwarefeatures bedarfsabhängig erworben werden können. So entstehen langfristig weniger Kosten für die Wartung und Weiterentwicklung, da weniger verschiedene Baureihen benötigt werden und der Preis für den Kunden auf die tatsächlich benötigten (softwareseitig über die Lizensierungswebsite lizensierten) Features einer einzelnen Baureihe abgestimmt werden kann. 

• FastBill ist eine Lösung zur webbasierten Abrechnung (Faktura) und Erfassung von Belegen
• In meiner Zeit bei FastBill erstellte ich eine Entwicklerdokumentation und erweiterte das Produkt unter anderem um die Möglichkeit, Eingangsgutschriften zu verbuchen. Ich ergänzte einen Export der einzuziehenden Lastschriftbeträge (DTAUS), verbesserte die Rechnungsvorschau im Kundenrechnungsportal und schrieb eine Kassenbuch-Funktionalität
• Des weiteren implementierte ich einen Onlinezugang, der es den Steuerberatern der FastBill-Kunden erlaubt, sich auf Wunsch in Echtzeit über die Eingangs/ Ausgangsbelege Ihrer Mandanten in Kenntnis zu setzen
• Die Entwicklung erfolgte vor Ort (2-3 Tage/Woche)

• Der Kunde vertreibt Wettervorhersagen. Wir entwickelten ein neues Backend zur Anpassung des Ist-Zustandes von Wetterdaten: Bislang passte der Kunde die Daten in einer MS Access-Oberfläche tabellarisch an. Dieses Backend wurde durch eine Kartenoberfläche im Intranet ersetzt, das per ODBC weiterhin auf die MS Access-Datenbank des Kunden schreibt und zusätzlich erlaubt über eine (verschiebbare, zoombare) Karte die Stützpunkten nach geografischen Aspekten zu markieren und die Wetterdaten mehrerer Stationen gleichzeitig relativ (beispielsweise Temparaturerhöhung) oder absolut (beispielsweise setzen einer bestimmten Niederschlagsmenge) zu ändern
• Die Entwicklung erfolgte remote und in Zusammenarbeit mit Weboxx

• Im November 2009 wurde der Server zur Erzeugung von Inhalten für die Internetseite, der auch als Staging-Server diente von Unix (Sparc/Solaris 8) auf eine virtuelle Maschine auf Linux-Basis (Intel x64/SuSE Linux Enterprise Server) in einem VMWare ESX-Cluster umgestellt. Im März 2010 folgte die Umstellung des Intranetservers von einer physischen Sparc/Solaris 9-Maschine ebenfalls in eine virtuelle SLES 10.2-Umgebung. 
  • Systematische Erfassung aller Module und Schnittstellen 
  • Erstellung einer Testdokumentation 
  • Aufsetzen eines Prototyps auf Linux-Basis
  • Re-Implementierung eines und Refactoring dreier Module 
  • Portierung aller C/C++ Module (nur Internet), sowie Aktualisierung aller PHP-Module und Shellskripte z.B. auf PHP 5 und MySQL 5
  • Durchführung der dokumentierten Testfälle
• Am 15.12.2010 ging, auch im Hinblick auf die Vorbereitung des Eintritts von Estland in die Euro-Zone zum 01.01.2011, eine stark erneuerte Version der Anwendung zur Publizierung von Wechselkursen auf der EZB-Internetseite live. Einige Teile der Anwendung basierten historisch bedingt noch auf C/C++-Quelltexten
• Meine Aufgaben beinhalteten die Portierung der C/C++ Teile zu PHP, die Automatisierung der Währungsumstellung in den veröffentlichten Dateien zum 02.01.2011 und eine Architekturvereinfachung die ein Geschwindigkeitsvorteil von rund 25% realisierte und erstmals ermöglichte, Push-Techniken einzusetzen: Bislang waren die Nutzer gezwungen die Daten regelmäßig abzurufen (Polling)
• Weiterhin wurden beispielsweise die Arbeiten an einem SMS-Gateway mit ActiveDirectory (AD-) Integration abgeschlossen (Februar 2011) und erfolgreich Penetration-Tests an Flash-Spielen durchgeführt (am 04.02. bzw. 09.02.2011)
• Ab Januar 2011 half ich beim Wechsel auf neue Internetserver hinter einer neuen Firewall (neue DMZ). Meine Aufgabe waren wiederum Requirementanalyse, Testaufbau und -durchführung. Das go-live fand am 10.03.2011 statt. 
• Statistiken
  • Den rund 1800 Intranet-Nutzern stand ein siebenköpfiges Team für alle Internet- und Intranet-Belange zur Verfügung. Dieses Team bestand aus dem Team-Koordinator, einem Editor, drei Administratoren, einem halb-Administrator und halb-Entwickler und mir (Vollzeit-Entwickler). Rund 150 Personen aus den Fachabteilungen konnten Inhalte ins Intranet direkt einstellen
• Im zweiten Teil der dritten Phase beantwortete das Intranet-Telefonbuch über vier Millionen Anfragen. Die Aktualisierung dieses Moduls oblag vier Teams und wurde anfangs mehr manuell (insgesamt ca. 35000 Mal), später verstärkt automatisch aktualisiert
• Das News-Modul zeigte in der dritten Phase rund 4000 ?news? insgesamt rund 1.1 Millionen Mal
• Ebenfalls wurden rund 1.1 Millionen Zugriffe auf zugriffsgeschützte Bereiche und 120000 Zugriffe auf 3900 Kalender-Einträge verzeichnet. Die EZB-Mitarbeiter benutzten meine Formulare rund 80000 mal, davon rund 20000 mit erweiterten Workflows (=Management Approval)
• Die in Phase 4 weitgehend neu geschriebene Anwendung für die Euro-Wechselkurse erzeugen eine Datei die z.B. im Dezember 2010 157.271.466 mal und im Monat nach der Umstellung (Januar 2011) 151.971.576 mal heruntergeladen wurde. 

• Für das organisationsweite Intranet wurden neun weitere Module realisiert und ein von einem Kollegen geschriebenes Modul komplett überarbeitet. Unter anderem beinhaltete das Intranet ein Telefonbuch, ein News- und ein Kalendermodul, ein Modul für personalisierte Inhalte wie Tiefgaragen-Parkberechtigung oder die Abrechnung privater Ferngespräche, ein Authentifizierungsmodul für zugriffsgeschützte Bereiche, einen Editor für hierarchische Inhalte und einen WYSIWYG-Seiteneditor (letzteres war das von mir lediglich überarbeitete Modul). Das Formular-Modul unterstützte letztlich rund zehn Eingabetypen (z.B. Texteingabe, Radio- und Checkboxen, Abteilungsauswahl oder Mitarbeitersuche) in rund 30 Formularen
• Ein, im Zeitraum ca. 13000 Mal benutztes Formular wurde dabei in Zusammenarbeit mit der IT-Abteilung mit deren Server zur Anfragenerfassung (Trouble Ticket System) vernetzt und ermöglichte neben der Freistellung einer Person die Beschleunigung des Formulardurchlaufs von vorher 15 auf dann zwei Tage
• Die Fachabteilungen hatten Schreibzugriff auf ca. 80% der Module und konnten Inhalte so direkt und ohne Umwege eintragen

• Die Liste der vorhandenen Module wurde soweit als möglich vervollständigt und ein Testsystem aktualisiert und besser isoliert. Eine Entwicklerdokumentation über die bestehenden Module wurde erstellt und im weiteren Verlauf aktualisiert
• Die Internet-Module wurden um Funktionen erweitert und geändert, beispielsweise wurden das Pressemitteilungs- und das Publikationsmodul je um einen neuen Typ ergänzt. Das Modul zur Veröffentlichung der die EZB betreffende Rechtsakte ?Legal Framework? und das Navigationsmodul wurden erweitert und verbessert

• In einem Content-Management-System wurde eine Möglichkeit für Nutzer eingeführt, sich in einen passwortgeschützten Bereich einzuloggen. Diese Methode wurde kompatibel zum bisherigen Modulsystem des CMS implementiert und später die Benutzerdatenbanken der Administratoren und Extranet-Nutzer integriert. 
• Der Code wurde ohne Funktionseinschränkungen reduziert; eine schriftliche Dokumentation eingeführt und die Entwicklung systematisiert, z.B. durch Einführung einer Versionierungssystems (CVS) und einer Liste anstehender Aufgaben (Bugzilla). 
• Durch das Versionierungssystem konnten vier bislang getrennt entwickelte Produktlinien vereinheitlicht werden. 

• In einem Content-Management-System wurde eine Möglichkeit für Nutzer eingeführt, sich in einen passwortgeschützten Bereich einzuloggen. Diese Methode wurde kompatibel zum bisherigen Modulsystem des CMS implementiert und später die Benutzerdatenbanken der Administratoren und Extranet-Nutzer integriert. 
• Der Code wurde ohne Funktionseinschränkungen reduziert; eine schriftliche Dokumentation eingeführt und die Entwicklung systematisiert, z.B. durch Einführung einer Versionierungssystems (CVS) und einer Liste anstehender Aufgaben (Bugzilla). 
• Durch das Versionierungssystem konnten vier bislang getrennt entwickelte Produktlinien vereinheitlicht werden.