top of page

Erfolgreiche Projektrettung - So gelingt der Turnaround bei Troubled-Projects

Aktualisiert: 18. Jan.


Bild 1 - Wie kann durch Testmanagement der Projektverlauf positiv beeinflusst werden?
Bild 1 - Wie kann durch Testmanagement der Projektverlauf positiv beeinflusst werden?

Beispiel 1 - Testmanagement: Firmware Entwicklung in Bereich Automobilindustrie


Nach zweijähriger Projektüberlaufzeit sind beim Auftragnehmer alle Meilensteine des Projektes gerissen. Mittlerweile schwindet die Hoffnung auf ein erfolgreiches Projektende nicht nur beim verantwortlichen Unternehmen, sondern auch bei allen Lieferanten und der Kunde überlegt eine Rückabwicklung unter Zuhilfenahme der Rechtsabteilung. Der Auftragnehmer versucht diesen hohen finanziellen Schaden durch Zuhilfenahme eines neuen externen Testmanager von mpindustries.at beziehungsweise projektretter.at abzuwenden.


Durch unseren Berater konnten wir schon in der ersten Beauftragungswoche ein positives Feedback vom Kunden erhalten, weil wir eine einfache Feedbackschleife nach Durchführung manueller Smoke-Tests eingeführt haben. Ein zusätzlicher Sanity-Test hat eine zeitnahe Rückmeldung von Abweichungen an das externe Entwicklerteam ermöglicht und so konnte innerhalb weniger Wochen ein erster funktionaler Prototyp mit Basisfunktionalität dem Kunden präsentiert werden. Mit dem Blick auf die Projektorganisation wurde vor allem der Projektleiter durch die Etablierung eines Softwarelebenszyklus (SDLC) entlastet und konnte wichtige Weichenstellungen für zukünftige Herausforderungen anpacken.


Im der nächsten Phase haben wir die Testabdeckung über eine Requirements-Testmatrix ermittelt und in der Gap-Analyse gemerkt, dass mit Hilfe von User-Stories für Tests die Mehrheit an offenen Anforderungen abgedeckt werden kann. In Durchschnitt konnte ein Test mehr als fünfzehn Anforderungen abdecken. Dadurch konnte ein vollständiger Testzyklus innerhalb von einem halben Tag abgewickelt werden. Nach zwei Monaten "Bugfixing" konnte schneller als geplant die finale Testphase im Fahrzeug vor Ort beim Softwarelieferanten und Endkunden getestet werden. Wenige Wochen später hat der Kunde Mercedes die Freigabe für die Firmware gegeben. Mit unserer Hilfe konnte in weit unter einem Jahr die Produktentwicklung erfolgreich abgeschlossen werden.


Welche Faktoren haben dazu geführt, dass dieses Projekt erfolgreich abgeschlossen werden konnte?

  1. Zwischenlieferungen vom Softwarelieferanten wurden zeitnah auf die Grundfunktionalität überprüft. Dies geschah oft auch vor Ort beim Softwarelieferanten, was dazu geführt hat, dass der Endkunde erstmals nach Jahren der Entwicklung einen Projektfortschritt wahrgenommen hat. Mehrmals täglich konnten wir Feedback direkt an die Entwicklermannschaft liefern und wurden mit einer Firmware-Zwischenlieferung belohnt.

  2. Durch eine vollständige Testabdeckung konnten Regressionstest durchgeführt und Rückschritte in der Software zeitnah den Entwicklern gemeldet werden. Dadurch wurden die kontinuierlichen Lieferungen stabiler und durch eine höhere Testabdeckung konnten auch neue Features der Firmware entwicklungsbegleitend unter Test gestellt werden.

  3. Durch die zusätzliche Testkapazität ist eine Multiplikator Wirkung ausgegangen, weil auch beim Kunden und Softwarelieferanten mehr Mitarbeiter im Projekt eingesetzt worden sind. Dies zeigt, dass es wichtig ist auf allen Ebenen zusammenzuarbeiten.


Das Beispiel zeigt auch, dass durch die Einbringung einer externen Unterstützung im Testumfeld das verlorengegangene Kundenvertrauen durch Einbringung eines Testmanager wiederhergestellt worden ist und auch ein Projekt mit Schieflage erfolgreich abgeschlossen werden kann. Im Vergleich mit einer Abwicklung des Projektes auf rechtlicher Ebene konnten wir mit Sicherheit finanzielle Nachteile im sechs- bis siebenstelligen Euro-Bereich abgewandt werden.



Beispiel 2 - Business-Analyse: Plattform zum Melden von Unfällen:


Der Go-Life-Termin für eine Smartphone-Applikation zur Unfallmeldung droht eine Verzögerung auf unbestimmte Zeit, weil das Webservice ohne ersichtlichen Grund abstürzt und Unfallmeldungen nur teilweise am Server eingehen, obwohl in der App am Handy eine Unfallwarnung abgesetzt wird.


Gemeinsam mit dem gesamten Team hat  mpindustries.at beziehungsweise projektretter.at folgende Strategie erarbeitet:  

1. Einbau eines Retry-Mechanismus in der Smartphone-App; 

2. Aktivierung vom Watchdog und der Logfile-Generierung am Server;  

3. Unterstützung durch manuelle Lasttests statt langwieriger Regressionstests;  

4. Übergabe vom manuellen Report inklusive essentieller Fehlermeldungen in den Logfiles.


Nach der Implementierung hat der erste Report ergeben, dass ALLE Unfallmeldungen am Server ankommen. Wegen Ressourcenengpässe am Webservice gibt es oftmals Abstürze der Server-Applikation, die durch Logfiles dokumentiert sind. Hier sorgt der Retry-Mechanismus dafür, dass keine Meldung verloren geht.


Innerhalb von einer Woche hat das Management genügend Kapazitäten am Server bereitgestellt, die Webservices laufen dadurch stabil und alle Unfallmeldungen werden im Backend weiterverarbeitet. Eine weitere Woche später konnten die restlichen Features, wie zum Beispiel die Übermittlung zusätzlicher Unfallinformationen freigeschalten werden.



Beispiel 3 - Qualitätsmanagement: Softwareentwicklung für eine Verkaufskette


Eine Verkaufskette im Nachbarland hat die Softwarelösung für die Unterstützung des Verkaufsbetriebes bei einer ausländischer Firma beauftragt. Die Implementierung der Softwarelösung und die Unterstützung bei produktiver Inbetriebnahme der Lösung lag in der Verantwortung vom Systemintegrator. Leider hat die Softwarelösung nicht richtig funktioniert.

Die Landesorganisation vom Systemintegrator hat auf eigene Faust versucht das Problem zu lösen und die Zentrale nicht vollständig über den Status informiert. Als Konsequenz hat der hoch unzufriedene Kunde das Problem an Zentrale des Systemintegrator eskaliert und mit Kündigung des Vertrages gedroht.


Die Zentrale hat unserer, damals bei Systemintegrator beschäftigter, Mitarbeiter beauftragt die Lage zu ermitteln und die Sanierungsmaßnahmen zu definieren und implementieren.

Die Begutachtung des Projektes haben gezeigt, dass:

  1. Die Entwicklungsdokumentation war wegen fehlerhafter Module nicht vollständig war;

  2. Die Gründe für fehlerhafte Verhalten der Software waren NICHT bekannt;

  3. Der Softwarelieferant hat nicht ausreichende Ressourcen für das Projekt zugeordnet;

  4. Die Landesorganisation des Systemintegrators hat versucht die Probleme gegenüber der Zentrale zu verstecken und Missstände zu vertuschen;

  5. Projektleiter war im nicht ausreichenden Ausmaß mit Projekt beschäftigt und deswegen hat er die Situation nicht kontrolliert.


Die rasche Implementierung von korrektiven Maßnahmen, wie:

  1. Inspektion des Softwarehauses mit Schwerpunkten auf Zustand der Dokumentation (Anforderungen und High Level Design der Anwendung);

  2. Durchführung von Quellencode Review in Hinblick auf mögliche Fehlerursachen;

  3. Verstärkung des Entwicklungsteams mit erfahrenen Software Architekten;

  4. Identifizierung von fehlerhaftem Code;

  5. Korrektur von Softwaremängel;

  6. Austausch des Projektleiters;

  7. Austausch des Managers in der Landesorganisation des Systemintegrators


haben dazu geführt, dass innerhalb von wenigen Wochen wurde die Lage völlig stabilisiert zu voller Zufriedenheit des Kunden.



Beispiel 4 - Qualitätsmanagement: Outsourcing Projekt für eine Versicherung


Der Service Provider hat einen mehrjährigen Vertrag über Betrieb der gesamter IT Infrastruktur unterzeichnet. Nach einiger Zeit hat sich herausgestellt, dass der Betrieb nicht ordentlich funktioniert, es kommt zu Ausfällen der Infrastruktur und der Kunde war mit der Qualität von Leitungen unzufrieden. Das Management von Service Provider hat unser, damals bei Service Provider beschäftigter, Mitarbeiter beauftragt die Situation des Projektes zu Begutachten.

Im aus der Begutachtung resultierenden Bericht wurden folgende Defizite identifiziert:

  1. Nicht ausreichende Qualifikationen der Betriebsmannschaft in Bereich Risiko- und Issue Management;

  2. Reaktive statt präventiver Vorgehensweise beim Betrieb;

  3. Überbelastung von kritischen Ressourcen;

  4. Technische Fehler begangene durch nicht immer ausreichend qualifizierte Mitarbeiter.


Als Antwort und Reaktion auf die identifizierten Mängel wurden zahlreiche korrektiven Maßnahmen unternommen und durchgeführt. Diese Maßnahmen haben inkludiert:

  1. Nominierung eines Risiko Managers, der alle auf Risikomanagement bezogene Aktivitäten koordiniert und geleitet hat;

  2. Breite Schulung des Mittelschicht Managements und Betriebsmannschaften in Sachen Risiko- und Issue-Management;

  3. Einführung von Werkzeugen und Prozessen, die regelmäßige Durchführung von Risiko- und Issue-Management ermöglicht haben;

  4. Regelmäßige Risiko- und Issue-Management Aktivitäten auf allen Ebenen des Projektes;

  5. Einführung von Regelmäßigen Reviews und Assessment von Risiken und Probleme mit der Teilnahme von Führung Team des Projektes und Risiko Manager;

  6. Verbesserung von Ressourcen-Management um die fachlichen Kenntnisse der verfügbaren Mitarbeiter effektiv zu nutzen;

  7. Einführung von "vier Augen" Prinzip bei der Durchführung von komplizierten Aktivitäten um das Eintreten von Fehler zu eliminieren.


    Konsequente, mehrjährige Implementierung von allen vorgeschlagenen Maßnahmen haben dazu geführt, dass die Erfüllung des Vertrages zu Zufriedenheit des Kunden in weiterer Folge die Verlängerung des ursprünglichen Vertrages über mehrere Jahre ermöglich hat.

​

Beispiel 5 - Testautomatisierung: Steuereinheit für ein Automobil-Matrixlicht:


Dieses Kundenprojekt beschäftigt sich mit der Neuentwicklung der Lichtsteuerung für Luxusautomarken von VW, Audi und Porsche. Die LED-Matrixlichter an der Front und der Rückseite des Fahrzeuges können zum Beispiel so angesteuert werden, dass entgegenkommende Fahrzeuge oder Personen nicht geblendet werden. Weiters wird eine Kurve ausgeleuchtet und der Scheinwerfer automatisch auf- und abgeblendet. Auf der System- und Softtestwareebene sind große Anstrengungen notwendig um die von Automotive-Spice (Software Process Improvement and Capability Determination) geforderte Testabdeckung von  einhundert Prozent zu erreichen.


Wir von mpindustries.at beziehungsweise projektretter.at haben mit Regressionstests auf folgende beiden Ebenen begonnen, diese erstellt, durchgeführt und das Issue-Tracking verfolgt, möglichst eine Testautomatisierung über die prozedurale Programmiersprache CAPL implementiert und für die CI/CD-Pipeline eine automatisierte Testdurchführung erstellt:


1. System-Engineering-Ebene (SYS):

Auf dieser Ebene wurde das System inklusive der Hardware getestet. Unsere Aufgabe war die Erstellung und Durchführung der Regressions-Tests. Zum Beispiel haben wir im Rahmen der Tätigkeiten die  End-Of-Line-Daten (EOL), Gyro-Daten, die GMSL-Videoschnittstelle und Boot/Security-Testfälle vom Steuermodul validiert.


2. Software-Engineering-Ebene (SWE):

Hier haben wir die Erstellung und Durchführung der Software Integration Tests umgesetzt. Unter anderem haben wir die Inter-Process-Communication (IPC), die Beleuchtungs-Modi, die Status-Modi und Ermittlung der Fehlerklassen validiert.


Unsere Ergebnisse waren einer Erhöhung der Testabdeckung auf beiden Ebenen von 0 % auf ~75 % inklusive Test-Architektur- und Design.


Verwendete kollaborative Werkzeuge waren Polarion inklusive mehrstufige Inner-Join-Abfragen, GitLab und SVN. Die RESTbus-Simulation wurde mit Vector CANoe, CANape und CAPL, Texas Instruments CCSTUDIO und Python 3.9 umgesetzt. Hardwareseitig war neben der zu entwickelnden ECU, Gigabit Multimedia Serial Link, UART, SPI-Bus, I2C-Bus, Arduino und Oszilloskop​​​​​ notwendig.


Beispiel 6 - Testautomatisierung: Aufbau einer Produktvalidierung für Smart-Meter:


Die Smart-Meter von Honeywell/Elster Solutions sind marktführend in den USA. Für eine Pruduktneuentwicklung gilt eine vollautomatisierte Validierung aufzubauen. Wir von mpindustries.at beziehungsweise projektretter.at haben die Weiterentwicklung der Toolchain unter Jenkins und die Erstellung von Testfällen für Zeitumstellung, Authentifizierung, Verschlüsselung und Cybersicherheit umgesetzt. Wir haben außerdem die Sicherheitszertifizierung der Smart-Meter bei der Zertifizierungsbehörde in Den Haag begleitet, um die Einhaltung relevanter Sicherheitsstandards sicherzustellen.


Verwendete Technologien waren C#, Team Foundation Server (heute AzureDevOp), StyleCop, Kema Test Facility, Jama Contour, Jira, Confluence, Bitbucket, Jenkins, QTest, SVN, COSEM, IDIS, IDIS 2 und HDLC.


Beispiel 7 - Testmanagement: Mobile Anzeigentafel für Verkehrstafeln:


Für die ASFiNAG hat mpindustries.at beziehungsweise projektretter.at in der Mautabteilung Testmanagement für ein vernetztes mobiles Telematik-System zum Anzeigen von Verkehrsschildern und -Informationen in den Regelbetrieb übergeführt.


Erfolgreich durchgeführte Aufgaben bei ASFiNAG für Anzeigesystem:

  • Erstellung von technischen Anforderungen, Testplan, Testfälle, Testing und vom Reporting;

  • Aussteuerung von Defektmanagement bei den Entwicklern;

  • End-2-End Abschlusstests vom Java-Backend/Middleware.


Verwendete Werkzeuge waren Polarion, Jira mit Erweiterung XRay, Confluence, C#, Python, hdlc, RabbitMQ, Insomnia, Postman, WireMock.Net, Wireshark, WebMethods, SoapUI, Icinga und Grafana.


 
 
bottom of page