Systems Engineering Tools
Eigene Werkzeuge für die Systems-Engineering-Praxis und die Methodik, nach der sie entstehen.
Systems Engineering Tools
In-house tools for Systems Engineering practice and the methodology behind them.
Wie eine solche Anwendung entsteht
How Such an Application Is Built
Viele Abläufe in einem Unternehmen sind nie digitalisiert worden, weil sich der Aufwand nicht gelohnt hat. Eine Freigabe läuft über eine Mailkette, eine Planung über eine gewachsene Excel-Datei, eine Prüfung über eine Papierliste. Für solche Abläufe gibt es selten ein fertiges Produkt, das genau passt, und eine klassische Eigenentwicklung war dafür zu teuer.
Mit KI-gestützten Entwicklungswerkzeugen verschiebt sich diese Grenze. Entscheidend ist dabei nicht die Geschwindigkeit beim Schreiben von Code, sondern das Vorgehen davor. Eine Anwendung, die aus einer Reihe von Prompts an ein Sprachmodell entsteht, erfüllt am Ende keine Anforderung vollständig und lässt sich später von niemandem prüfen. Deshalb muss eine solche Anwendung nach derselben Methodik entstehen wie ein technisches Produkt: nach dem V-Modell des Systems Engineering.
Der linke Ast des V legt fest, was gebaut wird, und zwar von den Beteiligten über die Anforderungen bis zur Architektur. Der rechte Ast prüft das Ergebnis gegen genau diese Festlegungen. Die Akzeptanzkriterien verbinden beide Äste: Sie werden links formuliert und rechts geprüft.
Many workflows in a company have never been digitalised because the effort did not pay off. An approval runs through a mail chain, a plan through a spreadsheet that grew over the years, an inspection through a paper list. For workflows like these, an off-the-shelf product rarely fits exactly, and a classic in-house development was too expensive.
AI-supported development tools shift that boundary. What matters is not the speed of writing code, but the method applied beforehand. An application that emerges from a series of prompts to a language model ends up meeting no requirement in full, and nobody can verify it afterwards. Such an application must therefore be built with the same methodology as a technical product: the V-model of Systems Engineering.
The left branch of the V defines what is built, from the people involved via the requirements to the architecture. The right branch verifies the result against exactly those definitions. The acceptance criteria connect both branches: they are formulated on the left and verified on the right.
Die nummerierten Felder sind die fünf Schritte aus dem Text. Die gestrichelten Linien verbinden jede Festlegung mit der Stelle, an der sie geprüft wird. Die beiden offenen Felder gehören nicht zum Bau, sondern zu dem, was danach dauerhaft läuft.
The numbered boxes are the five steps described below. The dashed lines connect each definition with the point where it is verified. The two open boxes are not part of the build, but of what runs permanently afterwards.
Die fünf Schritte
The Five Steps
Stakeholder ermitteln
Zuerst steht fest, wer mit dem Ablauf zu tun hat: wer ihn heute ausführt, wer das Ergebnis weiterverwendet, wer die fachliche Verantwortung trägt und wer die Software später betreibt. Ein Sprachmodell liefert hier im Dialog Rollen, die in der eigenen Betrachtung regelmässig fehlen, etwa der IT-Betrieb, der Datenschutz oder die Nachbarabteilung, die mit den Zahlen weiterarbeitet. Bewertet und entschieden wird die Liste im Unternehmen, nicht vom Modell.
Bedürfnisse und Anforderungen
Aus jedem Stakeholder leitet das Sprachmodell seine Bedürfnisse in einer festen Form ab: Als Projektleiter möchte ich X, damit Y. Daraus werden nummerierte Anforderungen, jede mit Bezug auf ein Bedürfnis und mit Akzeptanzkriterien darunter. Das Akzeptanzkriterium ist die Stelle, an der später geprüft wird, und zugleich der Test, ob die Anforderung überhaupt eindeutig formuliert ist. Was sich nicht prüfbar aufschreiben lässt, ist noch nicht verstanden.
Die Nummern bleiben über die gesamte Lebensdauer stabil. Eine geänderte Anforderung behält ihre Nummer, eine neue bekommt die nächste. Damit lässt sich noch nach Jahren nachvollziehen, warum eine Funktion existiert.
Stakeholder, Bedürfnisse und Anforderungen stehen gemeinsam in einem Anforderungsdokument, das mit der Anwendung mitwächst. Es liegt neben dem Code im selben Repository, sodass zu jedem Stand der Software der zugehörige Stand der Anforderungen vorliegt.
Technologie, Architektur und Design
Erst danach fällt die Entscheidung über den Technologie-Stack: wo die Daten liegen, ob ein Server nötig ist, welche Schichten es gibt und wo die Schnittstellen verlaufen. Jede Entscheidung wird gegen die Anforderungen begründet statt nach Geschmack getroffen.
Zur Architektur gehört auch die Frage nach den Schnittstellen. Wo die Anwendung Daten aus einem vorhandenen System übernimmt oder ihr Ergebnis weitergibt, wird das Format früh festgelegt, etwa eine Exportdatei für das ERP oder eine Ablage, aus der ein Berichtswerkzeug liest. Fällt diese Frage erst nach der Umsetzung an, entsteht genau der Medienbruch, den die Anwendung beseitigen sollte.
An dieser Stelle fällt auch die wichtigste Vorentscheidung über die spätere Wartbarkeit. Je weniger Bestandteile eine Anwendung hat, desto länger läuft sie ohne Pflegeaufwand. Eine Anwendung aus HTML, CSS und JavaScript ohne Build-Schritt hat keine Abhängigkeiten, die veralten können, und startet in fünf Jahren im Browser genauso wie heute.
Firmendesign und Umsetzung
Vor der ersten Zeile Code steht fest, wie die Oberfläche aussehen muss. Grundlage ist das Erscheinungsbild des Unternehmens: Farben, Schriften, Abstände und die wiederkehrenden Komponenten kommen aus dem Firmendesign, statt für jede Anwendung neu erfunden zu werden. Ohne diese Festlegung bekäme jeder neue Bildschirm ein eigenes Aussehen, weil das Sprachmodell ohne Vorgabe jedes Mal neu entscheidet.
Die Umsetzung erfolgt dann in kleinen Schritten, je Schritt gegen eine Anforderung. Jeder Schritt ist damit einzeln prüfbar und einzeln zurücknehmbar. Ein Umsetzungsplan legt die Reihenfolge fest und wird Schritt für Schritt abgearbeitet. Eine Versionsverwaltung wie Git hält jede Änderung mit ihrem Grund fest, sodass auch nach Monaten nachvollziehbar bleibt, was wann entstanden ist.
Abnahme gegen die Akzeptanzkriterien
Der rechte Ast des V prüft jede Anforderung gegen ihr Kriterium. Was in Schritt 02 unscharf formuliert war, fällt hier auf und geht zurück in die Anforderungsliste. Die Liste bleibt damit über die gesamte Laufzeit die Beschreibung des Soll-Zustands, nicht eine Momentaufnahme vom Projektbeginn.
Identify the Stakeholders
The first step establishes who is involved in the workflow: who carries it out today, who uses the result, who holds the professional responsibility, and who will operate the software later. In dialogue, a language model supplies roles that are regularly missing from one's own view, such as IT operations, data protection, or the neighbouring department that works on with the figures. The list is assessed and decided in the company, not by the model.
Needs and Requirements
From each stakeholder, the language model derives their needs in a fixed form: as a project manager I want X so that Y. These turn into numbered requirements, each referring to one need and carrying acceptance criteria below it. The acceptance criterion is the point where verification happens later, and at the same time the test of whether the requirement is stated unambiguously at all. What cannot be written down in a verifiable way is not yet understood.
The numbers stay stable across the entire lifetime. A changed requirement keeps its number, a new one receives the next. Years later it remains traceable why a function exists.
Stakeholders, needs, and requirements sit together in one requirements document that grows with the application. It lies next to the code in the same repository, so that every state of the software has the matching state of the requirements.
Technology, Architecture, and Design
Only then is the technology stack decided: where the data resides, whether a server is needed, which layers exist, and where the interfaces run. Every decision is justified against the requirements rather than made by preference.
Interfaces are part of the architecture as well. Wherever the application takes data from an existing system or passes its result on, the format is settled early, for instance an export file for the ERP or a location that a reporting tool reads from. If the question only comes up after the build, exactly the break in the data chain arises that the application was meant to remove.
This is also where the most important preliminary decision about later maintainability is made. The fewer parts an application has, the longer it runs without upkeep. An application made of HTML, CSS, and JavaScript without a build step has no dependencies that can age, and it starts in the browser in five years exactly as it does today.
Corporate Design and Build
Before the first line of code, it is settled how the interface has to look. The basis is the visual identity of the company: colours, fonts, spacing, and the recurring components come from the corporate design instead of being invented anew for each application. Without that definition every new screen would get its own appearance, because a language model without a specification decides anew each time.
The build then proceeds in small steps, one step per requirement. Each step is therefore individually verifiable and individually reversible. An implementation plan sets the order and is worked through step by step. A version control system such as Git records every change together with its reason, so that months later it remains traceable what came about when.
Acceptance Against the Criteria
The right branch of the V checks every requirement against its criterion. Whatever was stated vaguely in step 02 surfaces here and goes back into the requirements list. The list thus remains the description of the target state across the entire runtime instead of a snapshot from the start of the project.
Der Unterschied zum ungeplanten Vorgehen liegt nicht im Ergebnis der ersten Woche, sondern in dem, was nach der ersten Woche existiert. Bei diesem Vorgehen gibt es neben der Anwendung eine Anforderungsliste, eine begründete Architektur und eine Abnahme. Eine Änderung beginnt deshalb bei der Anforderung und endet im Code, nicht umgekehrt. Genau das ist die Voraussetzung dafür, dass die Anwendung später von jemand anderem weitergeführt werden kann. Der SE Demonstrator aus der Übersicht führt dieselbe Kette an einem technischen Produkt vor.
The difference from an unplanned approach lies not in the result of the first week, but in what exists after that week. With this method, a requirements list, a justified architecture, and an acceptance record exist alongside the application. A change therefore starts at the requirement and ends in the code, not the other way around. That is precisely the precondition for someone else to continue the application later. The SE Demonstrator from the overview walks through the same chain for a technical product.
Gegenüberstellung
Comparison
Die Entscheidung zwischen eigenem Werkzeug und eingekaufter Software hängt nicht am Geschmack, sondern daran, ob das Werkzeug einen unternehmenseigenen Ablauf trägt oder reine Infrastruktur ist. Die Gegenüberstellung nennt für beide Seiten die nachprüfbaren Punkte.
The choice between an in-house tool and purchased software does not depend on preference, but on whether the tool carries a company-specific workflow or is pure infrastructure. The comparison names the verifiable points for both sides.
| Kriterium | Eigenes Werkzeug | Eingekaufte Standardsoftware |
|---|---|---|
| Passung zum Ablauf | Bildet den vorhandenen Ablauf ab | Der Ablauf passt sich der Software an, Abweichungen werden zur Sonderlösung daneben |
| Zeit bis zur ersten Nutzung | Tage bis wenige Wochen für einen abgegrenzten Ablauf | Sofort verfügbar, die Einführung dauert je nach Umfang Monate |
| Funktionsumfang | Genau die Funktionen, die gebraucht werden | Grosser Umfang aus jahrelanger Entwicklung, davon bleibt ein Teil ungenutzt |
| Kostenverlauf | Entwicklungszeit zu Beginn, danach Pflege, unabhängig von der Nutzerzahl | Lizenz pro Nutzer und Jahr, wächst mit der Zahl der Anwender |
| Datenhaltung | Bleibt auf der eigenen Infrastruktur oder lokal im Browser | Liegt beim Anbieter, mit dessen Zusicherungen und dessen Standorten |
| Änderungen | Anforderung anpassen, umsetzen und abnehmen, im Rahmen von Tagen | Änderungswunsch, Priorisierung beim Hersteller und nächster Release |
| Wartung | Liegt im Unternehmen und braucht einen benannten Eigentümer | Liegt beim Hersteller, solange der Wartungsvertrag läuft |
| Support und Haftung | Kein Vertragspartner, der im Fehlerfall einsteht | Vertraglich zugesichert, mit Reaktionszeiten und Ansprechpartner |
| Zertifizierung | Muss bei normativer Pflicht selbst nachgewiesen werden | Häufig bereits qualifiziert vom Hersteller mitgeliefert |
| Abhängigkeit | Von der eigenen Fähigkeit, das Werkzeug weiterzuführen | Vom Hersteller, seiner Preisgestaltung und seiner Produktstrategie |
| Criterion | In-house tool | Purchased standard software |
|---|---|---|
| Fit to the workflow | Reflects the existing workflow | The workflow adapts to the software, deviations turn into workarounds alongside it |
| Time to first use | Days to a few weeks for one delimited workflow | Available immediately, the rollout takes months depending on scope |
| Scope of functions | Exactly the functions that are needed | Large scope from years of development, part of it stays unused |
| Cost profile | Development time up front, maintenance afterwards, independent of the number of users | Licence per user and year, grows with the number of users |
| Data storage | Stays on your own infrastructure or locally in the browser | Resides with the vendor, under their assurances and at their locations |
| Changes | Adjust the requirement, implement it and accept it, within days | Change request, prioritisation at the vendor and the next release |
| Maintenance | Sits in the company and needs a named owner | Sits with the vendor for as long as the maintenance contract runs |
| Support and liability | No contractual partner answering for a failure | Contractually assured, with response times and a named contact |
| Certification | Must be demonstrated in-house where a standard requires it | Frequently supplied already qualified by the vendor |
| Dependency | On your own ability to carry the tool forward | On the vendor, their pricing, and their product strategy |
Wo der Einkauf eines Tools die bessere Wahl ist
Where Buying a Tool Is the Better Choice
Eigenentwicklung ist kein Grundsatz. Für einen Teil der Werkzeuglandschaft ist der Einkauf die richtige Entscheidung, und zwar aus nachprüfbaren Gründen.
Building in-house is not a principle. For part of the tool landscape, buying is the right decision, for reasons that can be checked.
- Kernsysteme mit langer Datenhaltung: ERP und PLM tragen Stammdaten, Stücklisten und Freigaben über Jahrzehnte. Migration und Betrieb einer Eigenentwicklung stehen hier in keinem Verhältnis zum Nutzen.
- Werkzeuge mit Zertifizierungslast: Verlangt eine Norm die Qualifikation des Werkzeugs selbst, etwa in der sicherheitsrelevanten Entwicklung, ist ein bereits qualifiziertes Produkt der kürzere Weg.
- Etablierte Formate und Schnittstellen: CAD, Simulation und Messtechnik hängen an Dateiformaten, Solvern und Gerätetreibern. Diese Basis baut niemand sinnvoll nach.
- Abläufe ohne eigenen Anteil: Entspricht der Ablauf ohnehin dem Standard, gibt es nichts zuzuschneiden. Dann ist die fertige Lösung die günstigere.
- Core systems with long-lived data: ERP and PLM carry master data, bills of materials, and approvals across decades. Migrating and operating an in-house build is out of proportion to the benefit here.
- Tools carrying certification load: Where a standard requires the qualification of the tool itself, for instance in safety-related development, an already qualified product is the shorter route.
- Established formats and interfaces: CAD, simulation, and measurement depend on file formats, solvers, and device drivers. Nobody rebuilds that base sensibly.
- Workflows without a company-specific share: If the workflow matches the standard anyway, there is nothing to tailor. The finished solution is then the cheaper one.
Die Trennlinie verläuft dort, wo ein Werkzeug den eigenen Prozess trägt. Trägt es ihn, lohnt der Zuschnitt. Ist es reine Infrastruktur, lohnt der Einkauf.
The dividing line runs where a tool carries the company's own process. If it does, tailoring pays off. If it is pure infrastructure, buying pays off.
Die drei Nachteile im Klartext
The Three Drawbacks in Plain Terms
Kein Vertragspartner im Fehlerfall
Fällt eingekaufte Software aus, gibt es eine Nummer, eine zugesagte Reaktionszeit und im Zweifel eine Haftung. Bei einem eigenen Werkzeug gibt es das nicht. Für ein Werkzeug, das die Produktion anhält, wenn es steht, ist das ein Ausschlusskriterium. Für ein Werkzeug, das eine Planung unterstützt, ist es eine Verfügbarkeitsfrage.
Der Funktionsumfang beginnt bei null
Ein Standardprodukt bringt Funktionen mit, an die im eigenen Haus niemand gedacht hat, weil sie aus den Anforderungen hunderter anderer Anwender stammen. Diesen Vorsprung holt ein eigenes Werkzeug nicht auf, und für breite Standardaufgaben soll es das auch nicht.
Das Werkzeug braucht einen Eigentümer
Ohne eine benannte Rolle, die für Inhalt und Weiterentwicklung zuständig ist, verwaist jede interne Anwendung. Dieser Punkt ist der häufigste Grund, warum Eigenentwicklungen scheitern, und er ist zugleich der am leichtesten lösbare. Der Reiter „Wartung und IT“ behandelt ihn.
No Contractual Partner When It Fails
When purchased software fails, there is a number, an agreed response time, and if it comes to it, liability. An in-house tool offers none of that. For a tool that halts production when it stops, this rules it out. For a tool that supports a planning task, it is a question of availability.
The Scope of Functions Starts at Zero
A standard product brings functions nobody in the company thought of, because they stem from the requirements of hundreds of other users. An in-house tool does not catch up with that lead, and for broad standard tasks it should not try.
The Tool Needs an Owner
Without a named role responsible for content and further development, every internal application is orphaned. This point is the most common reason in-house developments fail, and it is at the same time the easiest to solve. The tab “Maintenance and IT” addresses it.
Der Einwand
The Objection
Der Einwand ist berechtigt, und er beschreibt einen realen Zustand in vielen Unternehmen. Er trifft allerdings zwei verschiedene Probleme, die getrennt zu lösen sind: die Wartbarkeit der Anwendung und ihre Einbettung in die IT.
Das erste Problem hat sich technisch verschoben. Das zweite löst sich nicht über Technik, sondern über das Vorgehen bei der Einführung.
The objection is justified, and it describes a real situation in many companies. It does, however, cover two separate problems that need separate solutions: the maintainability of the application and its integration into IT.
The first problem has shifted technically. The second is not solved by technology, but by the way the tool is introduced.
Warum sich die Wartungsrechnung geändert hat
Why the Maintenance Calculation Has Changed
Klassisch war der Einwand richtig. Eine Eigenentwicklung war so lange wartbar, wie ihr Entwickler im Haus war, weil das Wissen über die Software in seinem Kopf lag und nicht im Projekt. Ging er, blieb ein Codebestand ohne Erklärung, und dessen Übernahme kostete mehr als eine Neuentwicklung. Aus dieser Erfahrung stammt die Regel, im Zweifel zu kaufen. Drei Punkte haben diese Rechnung verändert.
The objection used to be correct. An in-house development stayed maintainable for as long as its developer remained with the company, because the knowledge about the software sat in their head and not in the project. Once they left, a body of code without explanation remained, and taking it over cost more than a rebuild. That experience is the origin of the rule to buy when in doubt. Three points have changed this calculation.
Die Anforderungsliste trägt das Wissen, nicht der Entwickler
Wer eine Anwendung übernimmt, die nach der Methodik aus dem Reiter „Methodik“ entstanden ist, liest zuerst die Anforderungen mit ihren Akzeptanzkriterien. Dort steht, welche Funktion aus welchem Bedürfnis entstanden ist. Diese Information liess sich aus Code noch nie rekonstruieren, unabhängig davon, wie gut er geschrieben war.
KI-Werkzeuge verkürzen das Einlesen
Der teuerste Teil einer Übernahme war immer die Zeit, bis ein Nachfolger den fremden Codebestand überblickt. Ein Sprachmodell erklärt einen unbekannten Codebestand entlang konkreter Fragen und schlägt Änderungen vor, die zur vorhandenen Struktur passen.
Der Nachfolger muss den Code damit nicht mehr auswendig kennen. Er muss beurteilen können, ob eine vorgeschlagene Änderung richtig ist, und das ist eine wesentlich geringere Anforderung.
Ein einfacher Technologie-Stack veraltet nicht
Der grösste Teil des Pflegeaufwands klassischer Anwendungen entsteht nicht durch neue Funktionen, sondern durch Abhängigkeiten: Frameworks mit neuen Hauptversionen, Bibliotheken mit Sicherheitslücken und Build-Ketten, die nach einem Jahr nicht mehr durchlaufen. Eine Anwendung ohne diese Bestandteile hat diesen Aufwand nicht. Das ist der Grund, warum die Entscheidung in Schritt 03 so stark auf die Wartbarkeit durchschlägt.
The Requirements List Carries the Knowledge, Not the Developer
Whoever takes over an application built with the method in the “Method” tab reads the requirements with their acceptance criteria first. They state which function came from which need. That information could never be reconstructed from code, no matter how well it was written.
AI Tools Shorten the Familiarisation
The most expensive part of a handover was always the time until a successor could survey an unfamiliar body of code. A language model explains unfamiliar code along concrete questions and proposes changes that fit the existing structure.
The successor therefore no longer needs to know the code by heart. They need to be able to judge whether a proposed change is correct, and that is a considerably lower requirement.
A Simple Technology Stack Does Not Age
Most of the upkeep of classic applications comes not from new functions, but from dependencies: frameworks with new major versions, libraries with security holes, and build chains that stop working after a year. An application without those parts does not carry that effort. This is why the decision in step 03 has such a strong effect on maintainability.
Die Wartung verschwindet dadurch nicht. Sie verschiebt sich von Spezialwissen einer einzelnen Person zu einer Aufgabe, die jemand mit technischem Grundverständnis und KI-Werkzeugen übernehmen kann.
Maintenance does not disappear as a result. It shifts from the specialist knowledge of a single person to a task that someone with basic technical understanding and AI tools can take on.
Einbettung in die IT
Integration into IT
Das zweite Problem löst sich über das Vorgehen. Ein eigenes Werkzeug wird wie eine interne Anwendung behandelt und nicht wie eine Datei auf einem Laufwerk. Fünf Punkte reichen dafür aus.
The second problem is solved by procedure. An in-house tool is treated like an internal application and not like a file on a shared drive. Five points are sufficient for that.
- Ein benannter Eigentümer: Eine Rolle im Unternehmen verantwortet Inhalt und Weiterentwicklung und entscheidet über Änderungswünsche. Ohne diese Rolle verwaist jede Anwendung, gleich wer sie gebaut hat.
- Der Quellcode liegt im Firmen-Repository: Nicht auf einem Laptop und nicht in einem privaten Konto. Damit existieren Versionsstände, eine Änderungshistorie und ein Zugriff, der nicht an einer Person hängt.
- Der Betrieb läuft über die vorhandene Infrastruktur: Bereitstellung über den internen Webserver oder das bestehende Hosting, Zugriff über die vorhandene Anmeldung und Sicherung über das vorhandene Backup. Es entsteht kein zweiter Betriebsweg neben dem etablierten.
- Die Dokumentation gehört zum Werkzeug: Anforderungsliste, Architekturentscheidungen und eine Bedienungsseite liegen neben dem Code im Repository. Sie beantworten nach der Übergabe die Fragen, die sonst beim Ersteller landen.
- Die IT nimmt vor dem Produktivgang ab: Geprüft wird dasselbe wie bei eingekaufter Software: wo die Daten liegen, wer Zugriff hat, was bei einem Ausfall passiert und wie Aktualisierungen eingespielt werden.
- A named owner: One role in the company is responsible for content and further development and decides on change requests. Without that role every application is orphaned, no matter who built it.
- The source code sits in the company repository: Not on a laptop and not in a private account. Version states, a change history, and access that does not depend on one person all follow from that.
- Operation runs on the existing infrastructure: Delivery via the internal web server or the existing hosting, access via the existing sign-in, and backup via the existing backup. No second operating route arises next to the established one.
- Documentation belongs to the tool: The requirements list, the architecture decisions, and a user guide sit next to the code in the repository. After the handover they answer the questions that would otherwise reach the original author.
- IT accepts the tool before it goes live: The same points are checked as with purchased software: where the data resides, who has access, what happens in case of a failure, and how updates are applied.
Ein Werkzeug, das diese fünf Punkte erfüllt, ist keine Schatten-IT, sondern eine interne Anwendung mit bekanntem Eigentümer und bekanntem Betriebsweg. Umgekehrt wird auch eingekaufte Software zur Schatten-IT, sobald eine Abteilung sie ohne Abstimmung einführt und selbst betreibt. Die Frage hängt am Vorgehen bei der Einführung, nicht daran, wer die Software geschrieben hat.
A tool that meets these five points is not shadow IT, but an internal application with a known owner and a known operating route. Conversely, purchased software also becomes shadow IT as soon as a department introduces and runs it without coordination. The question depends on the procedure at introduction, not on who wrote the software.
Übersicht
Overview
Fünf Anwendungen decken je einen Teil der Beratungsarbeit ab, von der Einstufung eines Projekts bis zur Auswertung von Betriebsdaten. Jede Karte führt auf eine Seite, die Zweck und Ablauf des Werkzeugs erklärt und von dort in die Anwendung verlinkt.
Five applications each cover one part of the consulting work, from classifying a project to evaluating operational data. Each card leads to a page explaining the purpose and workflow of the tool, with a link into the application from there.
SE Tailoring Tool
Stuft ein Entwicklungsprojekt als Minimal, Standard oder Erweitertes SE ein und zeigt, welche SE-Bereiche zuerst Aufmerksamkeit brauchen. Eine zweite Ebene bewertet den SE-Reifegrad des ganzen Unternehmens.
Mehr erfahren → 02SE Demonstrator
Führt an einem durchgehenden Beispiel von der Anforderung über das SysML-Modell bis zum Prompt. Der Vergleich zeigt, warum ein Modell als Kontext bessere Ergebnisse liefert als eine formlose Beschreibung.
Mehr erfahren → 03SE Log Analyzer
Wertet sechs Monate Betrieb einer Kompressorstation aus: Zeitreihen, Fehlerereignisse und Reparaturen. Der Drilldown auf ein Ereignis zeigt das Betriebsverhalten zwei Stunden davor und danach.
Mehr erfahren → 04SE Stakeholder Management
Erfasst die Stakeholder eines Projekts, ordnet sie nach Einfluss und Betroffenheit in einer Map ein und hält ihre Bedürfnisse sowie die geführte Kommunikation nachvollziehbar fest.
Mehr erfahren → 05Kapazitätsplanung
Bildet ab, wer wann zu welchem Anteil welchem Projekt zugeteilt ist. Engpässe zwischen Hardware, Software und Mechanik werden sichtbar, bevor sie den Terminplan treffen.
Mehr erfahren →SE Tailoring Tool
Classifies a development project as minimal, standard, or extended SE and shows which SE areas need attention first. A second level assesses the SE maturity of the entire company.
Learn more → 02SE Demonstrator
Works through one continuous example, from the requirement via the SysML model to the prompt. The comparison shows why a model as context yields better results than an informal description.
Learn more → 03SE Log Analyzer
Evaluates six months of compressor station operation: time series, fault events, and repairs. Drilling into an event shows the operating behaviour two hours before and after it.
Learn more → 04SE Stakeholder Management
Records the stakeholders of a project, positions them by influence and level of impact on a map, and keeps their needs and the communication with them traceable.
Learn more → 05Capacity Planning
Shows who is assigned to which project at what share and when. Bottlenecks between hardware, software, and mechanics become visible before they hit the schedule.
Learn more →