Viele Werkzeuge. Ein Faden.
Unser Ziel: Mirador soll den ganzen Produktlebenszyklus durchgängig unterstützen und die Werkzeuge einbinden, die Sie schon nutzen – ohne Export und Import von Hand.
Was über das heutige Mirador hinausgeht, ist unser Ziel – keine Zusage zu Funktionen, Umfang oder Terminen. Was Mirador heute kann, zeigen die Merkmale.
Wo heute Zeit verloren geht
Eine Spezifikation kommt als Dokument, wird in ein Werkzeug übertragen, zerlegt, für die Tests in ein zweites exportiert und für die Konstruktion in ein drittes. Jeder Übergang kostet Zeit, und an jedem kann etwas verloren gehen.
Wer wissen will, ob ein Entwurf noch zur Anforderung passt, sucht in mehreren Systemen.
Heute, Ziel und Fernziel
Heute:Anforderungen durchgängig
In Mirador erfassen Sie Anforderungen oder übernehmen sie per ReqIF; mit Excel arbeiten Sie hin und zurück. Mirador erkennt Schnittstellen, schlägt Merkmale vor und ordnet Anforderungen ein – in die Spezifikation kommt nur, was Sie freigeben.
Über bis zu zehn Ebenen verfolgen Sie jede Anforderung bis zum Test, und ändert sich etwas, kann Mirador die betroffenen Beziehungen als verdächtig markieren. Baselines halten Stände fest, Reviews prüfen sie in Runden, und aus jeder Baseline entsteht ein Dokument aus Ihrer Vorlage. Mit Jira und Jama gleicht Mirador Anforderungen in beide Richtungen ab, weitere Werkzeuge binden Sie über eigene Adapter oder die REST-API an.
Ziel:Der ganze Lebenszyklus
Spezifikationen, die als Dokument kommen, direkt einlesen und gliedern; Testläufe planen und ihre Ergebnisse an der Anforderung festhalten; die Werkzeuge anderer Anbieter fertig anbinden, wie heute schon Jira und Jama, und so Export und Import von Hand überflüssig machen.
Fernziel:Von der Anforderung zum ersten Entwurf
Aus geprüften Anforderungen soll Mirador die Werkzeuge der Entwicklung so ansteuern, dass sie erste Entwürfe und Designstudien erstellen – als Ausgangspunkt, nicht als Ergebnis:
- Testfälle und Testspezifikationen,
- einen CAD-Entwurf eines Bauteils aus Bauraum, Lasten und Werkstoff,
- einen Schaltplanentwurf mit Bauteilauswahl und, aus den erkannten Schnittstellen, Signal- und Steckerlisten für Verdrahtung und Kabelbaum,
- eine erste Hardwarebeschreibung in VHDL oder Verilog für Chip oder FPGA, samt Testbench,
- ein Gerüst aus Schnittstellen und Tests für die Software, auch die eingebettete,
- Architektur- und Simulationsmodelle, mit denen sich Lösungsvarianten früh vergleichen lassen,
- erste Gefährdungs- und Fehleranalysen, die Ihr Sicherheitsteam prüft und vervollständigt.
Prüfen, ändern und freigeben werden Sie. Jeder Entwurf soll bis zur Anforderung zurückverfolgbar bleiben: So wie Mirador heute Beziehungen nach einer Änderung als verdächtig markieren kann, soll dann sichtbar werden, welcher Entwurf betroffen ist.
Ein Entwurf ersetzt keine Auslegung, keine Berechnung und keinen Nachweis – er soll Ihnen ersparen, mit einem leeren Blatt zu beginnen.
Abläufe, die Sie selbst beschreiben
Einiges läuft in Mirador heute schon von selbst: Änderungen aus Jira und Jama kommen nach Plan oder auf Meldung, und Beziehungen können nach einer Änderung als verdächtig markiert werden.
Unser Ziel sind Abläufe, die Sie selbst beschreiben und die Mirador dann ausführen soll – mit Ihnen an jeder Stelle, die eine Entscheidung braucht. Zum Beispiel:
Eine Anforderung ändert sich.
Heute: Mirador kann die Beziehungen zu abhängigen Anforderungen und Tests als verdächtig markieren.
Ziel: auch betroffene Entwürfe und Dokumente markieren, die Verantwortlichen benachrichtigen, eine Review-Runde vorbereiten.
Eine neue Fassung der Kundenspezifikation kommt.
Heute: Kommt sie als ReqIF, übernehmen Sie sie als neuen Bestand.
Ziel: sie einlesen, gliedern, gegen den bisherigen Stand legen und die Unterschiede zur Prüfung bereitstellen.
Ein Stand wird freigegeben.
Heute: Jedes Review läuft über eine eingefrorene Baseline, in der nächsten Runde wird nur neu beurteilt, was sich geändert hat, und aus jeder Baseline erzeugen Sie Dokumente.
Ziel: mit der Freigabe Baseline, Dokumente und den Abgleich mit den angebundenen Werkzeugen ohne weiteres Zutun anstoßen.
Testergebnisse kommen zurück.
Heute: Mirador zeigt, welche Anforderung keinen Test hat.
Ziel: Ergebnisse aus der Testumgebung an den Anforderungen festhalten, die sie nachweisen, und zeigen, was ungetestet oder durchgefallen ist.
Jeder Ablauf soll nachvollziehbar bleiben: was ihn ausgelöst hat, was er getan hat und wer freigegeben hat – so wie heute jede Änderung aus einem KI-Vorschlag den Namen dessen trägt, der sie freigab.
Was dabei gilt
Sie entscheiden.
Mirador soll vorschlagen und entwerfen; freigeben werden Sie – so wie heute bei den KI-Vorschlägen.
Offen statt geschlossen.
Vorhandene Werkzeuge einbinden, nicht ersetzen.
Nachvollziehbar.
Jeder Schritt mit Beleg und einem Weg zurück zur Anforderung.
Was über das heutige Mirador hinausgeht, ist unser Ziel – keine Zusage zu Funktionen, Umfang oder Terminen. Was Mirador heute kann, zeigen die Merkmale.
Beginnen Sie mit dem, was heute geht.
In einer Vorführung zeigen wir Ihnen, was Mirador heute kann – und hören gern, was Sie sich für Ihre Entwicklung wünschen.