Bottleneck Systemverifizierung: Risiko durch eine späte Einbindung

March 27, 2017

In fast allen Projekten wird die Verifizierung erst spät in die Entwicklung eingebunden. Zwei Hauptursachen lassen sich für dieses Problem identifizieren:

  1. Es herrscht eine generelle Knappheit von Ressourcen und zu Projektbeginn werden diese noch in anderen Projekten benötigt.

  2. Dem Projektleiter fehlt das Bewusstsein, dass die späte Einbindung der Verifizierung das Projektrisiko steigert.

Häufig wird die Verifizierung auch nur als formaler Akt am Ende der Entwicklung betrachtet.

 

Im Folgenden möchte ich kurz erläutern, warum eine späte Einbindung Risiken für das Projekt birgt und welche Vorteile eine rechtzeitige Einbindung für ein Projekt haben kann.

 

Projektrisiken entstehen

 

Die meisten Angestellten, die in Projekten im regulierten Umfeld arbeiten, kennen das immer wiederkehrende Problem: Am Ende der Projektenwicklungsphase treten unerwartete Probleme und Abweichungen auf, die aufwendige, späte Änderungen am Produkt notwendig machen. Dies ist bei einer rückwirkenden Betrachtung von Projekten häufig auf die späte Einbindung der Verifizierung zurückzuführen.

 

Wird die Verifizierung erst spät in ein Projekt im regulierten Umfeld eingebunden, entstehen schwer zu kalkulierende Risiken für das Projekt. Das Potenzial, die Möglichkeiten und das Know-how der Verifizierung wird nicht genutzt. Betrachtet man die Verifizierung als Garant und Leuchtturm für die Einhaltung von diversen internen und externen Anforderungen und Standards an das zu entwickelnde Produkt, wird schnell klar, dass die Verifizierung die Qualität und die Konformität des zu entwickelnden Produkts sicherstellt. Insbesondere die Qualität sollte nicht erst am Ende eines Projekts sichergestellt oder erst in das Produkt gebracht werden. Hier gilt die einfache Annahme, dass die Kosten für einen Fehler immer höher werden, je später sie gefunden werden.

 

Folgende Risiken für das Projekt entstehen durch das Fehlen der Verifizierung in der Start- und Konzeptphase eines Projekts:

 

  • Nicht testbare Anforderungen

  • Unvollständige Anforderungen

  • Fehlerhaft ausgelegte normative Anforderungen

  • Nicht berücksichtigte normative Anforderungen

 

Frühe Einbindung der Verifizierung ist eine logische Konsequenz

 

Hieraus ergibt sich die logische Konsequenz, dass die Verifizierung frühzeitig - wenn auch nicht notwendigerweise mit voller Teamstärke - das Projekt begleiten sollte.

 

In dem sogenannten W-Modell lässt sich recht vereinfacht darstellen, dass es das Ziel der Verifizierung sein muss, früh in die Projektabläufe einzugreifen, um rechtzeitig Problem zu erkennen und adressieren zu können.

 

 

Koordinator für die Produktqualität als Kompromiss

 

Zu Beginn eines Projekts stehen häufig nicht die Ressourcen zur Verfügung, um bereits mit einem kompletten Team das Projekt zu unterstützen. Deshalb stellt die Einführung eines Koordinators für die Produktqualität einen sehr guten Kompromiss dar. Dieser fungiert bereits zu Beginn des Projekts als Schnittstelle zwischen Entwicklung und der Produktqualifikation. Die Produktqualifikation umfasst jegliche Maßnahmen zur Ermittlung und Sicherstellung der Produktqualität und -konformität. Hierzu zählen neben der Verifizierung auch die Reliability- und Usability-Maßnahmen.

 

Aus dieser Überlegung entsteht das folgende Schaubild. Zu Beginn der Projektentwicklung ist zunächst nur der Koordinator für die Produktqualität involviert. Im Verlauf der Projektphasen baut sich anschließend die Teamgröße entsprechend der notwendigen Tätigkeiten weiter auf. Spätestens zum Start der Verifizierungsphase sollte die komplette Teamgröße zur Verfügung stehen.  Es ist jedoch zu empfehlen, dass bereits für eine Probeverifizierung am Ende der Projektphase die geplante Teamstärke zur Verfügung steht. Dadurch werden bereits durch die Projektverifizierung die Einarbeitung des Teams und die Abläufe trainiert. Durch eine Probeverifizierung wird somit die offizielle Verifizierungsphase beschleunigt.

 

Wozu dieser Aufwand?

 

Natürlich ist ein Projektleiter vom zusätzlichen Ressourcenbedarf bereits zu Beginn der Entwicklung wenig begeistert, da dieser häufig unter Kostendruck und Ressourcenmangel leidet. Dabei sind die positiven Effekte und die dadurch verringerten Projektrisiken und verminderte Kosten für die Verifizierungsphase des Projekts höher einzuschätzen als die der Ressourcenbedarf zu Beginn des Projekts.

 

Zusammenfassend kann man sagen, dass man durch eine frühzeitige Einbindung der Verifizierungskompetenzen eine Verbesserung der Produktqualität und Produktreife zu Beginn der offiziellen Verifizierungsphase erreichen kann. Die wesentlichen Punkte und positive Aspekte sind hier noch mal zusammengefasst:

 

  • Sicherstellen der Testgrundlagen (Risiko-, System- und Normanforderungen)

    • Testbarkeit

    • Vollständigkeit

  • Frühzeitige Planung von Testzeiten in externen oder internen Testhäusern (Standardtests)

  • Konkreter Ansprechpartner für die Entwicklung in Bezug auf Testfragen (z.B. Interpretation von Standards)

  • Frühzeitiges Festlegen der Testverantwortlichkeiten zwischen System- und Integrationstest (Testlevel)

  • Kompetente Abschätzung von Aufwendungen im Test für späte Änderungen im Produkt

  • Probeverifizierungen erhöhen die Wahrscheinlichkeit, dass die offizielle Verifizierung mit weniger Schleifen erfolgreich durchgeführt wird.

  • Die Fehlerfindungsrate in der offiziellen Verifizierung wird geringer

 

Ich hoffe, hiermit Ihr Interesse an dem Thema frühzeitige Einbindung der Verifizierung in das Projekt wecken. Bitte zögern Sie sich nicht unsere Experten anzusprechen, um Fragen zu beantworten oder vielleicht haben Sie ja auch Interesse die Möglichkeiten einer frühzeitigen Einbindung der Verifizierung mit uns zu diskutieren. Wir freuen uns auf den Austausch mit Ihnen!

 

 

Please reload

Kontakt: 0431 - 888 2111 0

E-Mail: marketing@scope-engineering.de

  • YouTube
  • Twitter
  • XING
  • LinkedIn

© 2020 SCOPE Engineering GmbH

Impressum

Datenschutz

Kontakt

SCOPE Engineering Website       I       test!t     I     t(ea)talk     I     Dezentrales Arbeiten