Change-Request-Audit in Polarion: 1 Arbeitstag Analyse als 72-Sekunden-Lauf

In Kürze

Wir haben unseren Camemi-Agenten gegen eine produktive Polarion-Instanz laufen lassen. Datenbasis: ein ADAS-Pilotprojekt nach V-Modell mit 100 Software-Requirements, 95 Test Cases, einem Change Request mit drei semantischen Drifts und fünf Coverage-Lücken.

Ergebnis:

• 72 Sekunden Echtzeit für einen kombinierten Change-Request-Audit-Lauf — Coverage-Lücken und semantische Drifts werden in einem Aufruf erkannt
• 8 von 8 eingebauten Findings korrekt erkannt auf der kontrollierten Bench-Datenlage (100 % Recall, 0 % False Positives — Recall = Trefferquote über alle echten Findings)
• Faktor ~20× günstiger pro Lauf als die manuelle Vergleichsanalyse (1.100–1.400 € abgerechnet bei 100 €/h) bei aktiver Nutzung. Break-even ab etwa 4 Läufen pro Monat. Vollkostenrechnung im begleitenden TCO-Blog.
• Auditierbarer Trail mit Run-ID, geprüftem Stand, Modell-Versionen, Tool-Calls und Zeitstempeln fällt als Nebenprodukt an. Kein separater Report nötig.
• Kein Pilot-Mock auf gestellten Daten, sondern ein reproduzierbarer Benchmark gegen die tatsächliche Polarion-API.

Warum Change Requests in regulierten Polarion-Projekten so teuer sind

Wer in Automotive, MedTech oder Aerospace mit Polarion arbeitet, kennt diesen Moment: Ein Change Request kommt rein, ein Requirement wird verschärft oder umformuliert. Ab da ist das Test-Modell potenziell inkonsistent. Die Frage, welche Test Cases jetzt nicht mehr aktuell sind, ist dabei selten ein einfacher Datenbank-Lookup. Es ist eine semantische Frage:

• Hat sich der Schwellwert geändert? (numerischer Drift)
• Wurde eine Bedingung gestrichen oder hinzugefügt? (qualifizierender Drift)
• Ist ein neues Akzeptanzkriterium dazugekommen, das im Test fehlt? (Akzeptanz-Drift)

Diese Fragen beantwortet niemand schnell aus dem Polarion-Dashboard heraus. Sie verlangen, dass eine erfahrene Test-Managerin Requirement und Test Case nebeneinanderlegt, die Formulierung versteht und entscheidet, ob der Test die neue Anforderung tatsächlich noch verifiziert.

In unserer Erfahrung, gestützt durch Schätzungen aus QA-Teams in Polarion-Projekten, kostet diese Arbeit pro Change Request bei einem Umfang von 100 Requirements zwischen 6 und 8 Stunden Fokuszeit, in der Praxis als 11–14 Stunden abgerechnete Elapsed-Time (mit Polarion-UI-Overhead, Trace-Lookups, Selbst-Review, Kontext-Switches im Büro). Plus die Nacharbeit, wenn ein Drift im Audit doch übersehen wurde.

In der Sprache des ASPICE-Standards: Hier scheitern viele Organisationen an PIM.3 BP7. Nicht, weil sie nicht messen wollen, sondern weil Messung neben dem operativen Druck nicht passiert.

Der Benchmark — was wir aufgesetzt haben

Um die Frage „Was leistet ein KI-Agent auf einer ehrlichen Datenlage?“ beantworten zu können, haben wir einen reproduzierbaren Benchmark in einer produktiven Polarion-Instanz aufgebaut. In der produktiven Pipeline laufen Coverage- und Staleness-Analyse zusammen in einem einzigen Aufruf (siehe „Bonus“ am Ende von Lauf 2). Wir zeigen sie hier nacheinander, um die Verarbeitung pro Schritt sauber sichtbar zu machen.

Eingebaute „Fehler“ als Ground Truth:

• 5 Coverage-Lücken — Requirements ohne zugehörigen Test Case, davon zwei sicherheitskritisch (Watchdog-Selftest, Exception-Handling) und einer Security (Audit-Log-Integrität)
• 3 semantische Drifts durch einen Change Request CR-2026-001:
  • Numerischer Drift: Latenzanforderung von 200 ms auf 150 ms verschärft, Test prüft noch 200 ms
  • Qualifizierender Drift: Einschränkung „bei Tageslicht“ gestrichen, Test deckt nur Tageslicht ab
  • Akzeptanz-Drift: Mindesthalt von 1 Sekunde nach Stillstand neu gefordert, Test prüft nur das Anhalten

Das ist die realistische Dichte an Drift-Typen, die in einem mittleren Change Request anfallen kann.

Lauf 1 — Coverage-Analyse

Aufgabe an den Agenten: „Analysiere die Testabdeckung für die Requirements-Spezifikation im Projekt ADAS_Bench.“

Output ist nicht „5 Items haben keinen Test“, sondern eine Liste mit Item-IDs, Titeln und Risikoeinschätzung — direkt im Schema, das ein Auditor lesen kann.

Lauf 2 — Staleness-Analyse (semantische Drift-Erkennung)

Das ist die eigentlich anspruchsvolle Aufgabe. Hier reicht keine Datenbank-Logik mehr.

Aufgabe: „Prüfe Staleness im Dokument. Welche Test Cases sind nicht mehr aktuell zu ihren Requirements?“

Was uns dabei beeindruckt hat: nicht nur die Trefferquote, sondern die Diagnosequalität der Findings. Ein Auszug aus dem Output:

ADAS-526 / ADAS-626: „Anforderung wurde verschärft und fordert nun eine maximale Latenz von 150 ms. Der Test Case prüft jedoch noch gegen den veralteten Schwellwert von 200 ms.“

ADAS-571 / ADAS-670: „Anforderung wurde um ein wichtiges Akzeptanzkriterium erweitert: Das Fahrzeug muss nach dem Anhalten an der Haltelinie für mindestens 1 Sekunde im Stillstand verharren. Der Test Case prüft nur das Anhalten selbst.“

Pro Finding wird automatisch eine konkrete Empfehlung generiert — z. B. „Test Case ADAS-626 muss angepasst werden, um die Latenz gegen den neuen Grenzwert von 150 ms zu verifizieren“.

Bonus: Da die Pipeline für die Drift-Bewertung ohnehin alle Paare einliest, fallen die fünf Coverage-Lücken im selben Lauf mit aus. Ein einziger Aufruf liefert die vollständige Audit-Antwort eines Change-Request-Reviews — strukturelle Lücken und inhaltliche Drifts.

Manueller Vergleich — was die gleiche Arbeit ohne Agent kostet

Wie die Per-Lauf-Kosten zustande kommen: Plattform-Software-Anteil plus on-premise Inferenz-Server (Anschaffung, Strom, Wartung) ergeben fixe Monatsvollkosten. Diese verteilen sich auf alle Läufe im Monat — je höher die Auslastung, desto niedriger die Allokation pro Lauf. Die Skalierungslogik ist linear, der Multi-Workflow-Effekt drückt sie zusätzlich. Break-even gegen manuelle Analyse liegt bei etwa 4 Läufen pro Monat. Schon ein Audit pro Woche rechnet sich.

Die vollständige Vollkostenlogik (Hardware-Vollkosten, Plattform-Software-Anteil, Skalierung über Workflow-Klassen, Cloud-API-Vergleich und Compliance-Overhead gegen EU-Region-Hyperscaler) ist im begleitenden Beitrag beschrieben: Was on-premise KI wirklich kostet — vier Säulen und eine ehrliche Vollkostenrechnung.

Selbst konservativ gerechnet, mit 50 % manuellem Aufwand für Fälle, in denen eine erfahrene Person mit Polarion-Bordmitteln schneller wird, bleibt der Faktor zweistellig. Und der entscheidende Punkt ist nicht der Faktor allein.

Der Audit-Trail als Nebenprodukt

Der eigentliche Mehrwert für ein reguliertes Polarion-Projekt liegt nicht in der Geschwindigkeit. Er liegt darin, was automatisch entsteht, ohne dass jemand einen Improvement-Report schreiben muss:

Das ist genau die Datenlage, die ein Assessor in einem ASPICE-Audit, einem MedSPICE-Review oder einer DO-178C-Conformity-Bewertung sehen will.

Audit-Frage → was das System beantwortet:

Im Vokabular des ASPICE-Standards (PIM.3): BP7 (Confirm improvements) und BP8 (Communicate results) fallen einfach an. Sie sind kein separater Aufwand neben der Arbeit. Sie sind die Arbeit.

Was als nächstes kommt — der Fix-Lauf

Drift gefunden ist nicht Drift behoben. Der jetzt anstehende Schritt ist der zweite Teil des Workflows:

• Trigger: Change Request wechselt in Status „approved“
• Abdeckungs-Prüfung + Staleness-Analyse (diesen Stand haben wir gerade gezeigt)
• Empfehlungs-Generierung pro Paar (ebenfalls fertig)
• Human-in-the-Loop-Approval (HITL): Test-Manager bekommt Vorschläge mit Begründung, akzeptiert oder editiert pro Finding
• Automatischer Polarion-Update der Test-Steps, mit Audit-Eintrag pro Änderung
• Auto-Digest an betroffene Stakeholder (QA-Lead, Project-Manager, Process-Owner)

Schritt 4–6 sind die nächste Benchmark-Runde. Wir sind zuversichtlich, dass die Akzeptanzquote der Vorschläge in den hohen 90ern liegen wird — die Diagnosequalität in Schritt 2/3 ist dafür der Indikator.

Was sich dadurch in der Change-Request-Implementierung zusätzlich verbessern dürfte:

• Durchlaufzeit von CR-Approval bis konsistentem Test-Modell: von Tagen auf Stunden
• Nachbearbeitungsquote durch Erstattung übersehener Drifts in späteren Audits: gegen Null
• Prüfer-Aufwand: der Test-Manager liest Vorschläge und bestätigt, statt von der weißen Seite zu starten
• Konsistenz-Score über das gesamte LiveDoc: automatisch nachverfolgbar als Kennzahl

Der Folge-Blog dokumentiert diesen Lauf, sobald er auf dem Bench gelaufen ist.

Was sich bei Ihnen reproduzieren lässt

Der Bench ist nicht proprietär. Wer einen Polarion-Zugang hat und das Setup aufsetzen will:

• 100 Requirements + 95 Test Cases + Change Request liegen als YAML-Fixtures vor
• Ein Seed-Skript lädt sie über die Polarion-API ein
• Ein Apply-Skript wendet die drei Drifts an
• Ein Verify-Skript prüft die Datenlage gegen Ground Truth

Ein Senior Engineer kann das Setup in unter einer Stunde durchziehen. Danach ist die Pipeline live und reproduzierbar.

Zusammenfassung

Was der Benchmark gezeigt hat:

• Eine vollständige Change-Request-Impact-Analyse über 100 Requirements und 95 Test Cases dauert 72 Sekunden statt 6–8 h Fokuszeit (in der Praxis 11–14 h abgerechnet) — Abdeckung und semantische Drifts in einem kombinierten Lauf
• Erkennungsqualität war auf der kontrollierten Bench-Datenlage 100 % Recall, 0 % False Positives — bei 8 eingebauten Befunden. Auf produktiven Datenlagen mit unsauberen Strukturen, abweichenden Formulierungen und Domain-Mischungen erwarten wir niedrigere Werte; wir empfehlen daher jedem Pilotkunden, gegen eigene Vergleichsdaten zu validieren.
• Vollkosten pro Lauf (Plattform-Software-Anteil + Hardware, anteilig): niedriger zweistelliger Euro-Bereich bei aktiver Nutzung. Break-even gegen manuelle Analyse ab etwa 4 Läufen pro Monat. Bei Mehr-Projekt-Setups deutlich niedriger pro Lauf.
• Audit-Trail entsteht automatisch: Run-Record, Tool-Calls, Skill-Versionen, reproduzierbare Datenpfade

Wofür das relevant ist:

Für jedes Polarion-Projekt unter ASPICE, MedSPICE, DO-178C, ISO 26262 oder vergleichbarem Compliance-Druck. Methodik bleibt Menschen-Arbeit: Improvement-Goals, Management-Commitment, Priorisierung. Was wegfällt, ist die operative Mess-Reibung. Und genau die ist heute der Hauptgrund, warum BP7 und BP8 in der Praxis so oft als Pflichtübung statt als Erkenntnisquelle landen.

Wenn Sie das Setup interessiert oder Sie den Bench gegen Ihre eigene Polarion-Instanz laufen lassen wollen: melden Sie sich.

ISUDO entwickelt Camemi — eine Agenten-Plattform für Enterprise-Workflows mit eingebautem Human-in-the-Loop und auditierbarem Trail. Wir bauen für Polarion, SAP IS-U und vergleichbare Systeme in regulierten Industrien. Demo-Anfragen: c.muelder@isu-do.com