Applikationserstellung mit customX

In diesem Artikel geht es um die Kernaufgabe der Produktdigitalisierung: den Modellierungsprozess im Unternehmen, bis zur fertigen Applikation. Diese Aufgabe ist in 4 Abschnitten erläutert:

1. Die Arbeitsumgebung
2. Der Modellierungsprozess im Unternehmen →
3. Die Testphase →
4. Support, Ausbau und Änderungswesen →

1. Die Arbeitsumgebung

1.1  Die beteiligten customX-Komponenten

Im eingerichteten System bedeutet Applikationserstellung im Wesentlichen, den Upload eines mit customX-RuleBook erstellten Modellierungsstands, in den customX-Teamserver. Die eigentliche Applikation, der customX-Server, lädt einen Modellierungsstand vom Teamserver, wodurch dieser sofort (als Webservice) zur Verfügung steht.

1.2  Organisation von Änderungsberichten über den Teamserver

Im Teamserver wird eine serielle Folge von Modellierungsständen, die Änderungsberichte, angelegt. Die einzelnen Änderungsberichte können sein:

• Arbeitspakete (Erweiterungen, Änderungen, Korrekturen)
• Versionen, die in das Echtsystem übernommen werden
• Workspaces für mehrere Regelwerker∗innen

1.3  Erzeugen und bearbeiten von Änderungsberichten mit RuleBook

Änderungsberichte werden durch RuleBook im TeamServer erzeugt und aktualisiert. Die Arbeit der Regelwerker∗innen ist es:

• Anlegen von Änderungsberichten (für Arbeitspakete, Versionen, Workspaces s.o.).
• Die Kernaufgabe: Bearbeiten der Änderungsberichte mit RuleBook.
• Aktualisierung eines Modellierungsstands auf dem Teamserver.

Auf dem Windows 10-Arbeitsplatz der Regelwerker∗innen, kann ein Änderungsbericht autark/offline entwickelt und getestet werden. Zu gegebener Zeit wird der bearbeitete Änderungsbericht auf dem Teamserver aktualisiert.

1.4  Teamarbeit mehrerer Regelwerker∗innen

Die gleichzeitige Arbeit mehrerer Regelwerker∗innen wird durch eine Folge von Arbeitspaketen und Workspaces im Teamserver organisiert. Insbesondere parallele Eingaben in RuleBook, müssen sorgfältig abgesprochen und durch eine Folge von Workspaces geregelt werden. Leicht zu handhaben ist die Trennung folgender Arbeitsbereiche:

• Die Modellierungsarbeit in RuleBook
• Erstellen und Einspielen von Tabellenwerken
• Erstellen und Einspielen von CAD-Dateien, Office-Dateien, ...
• Gestaltung der Front-End-Dialoge im Templateeditor
• Eingaben in der Sprachdatenbank

2. Der Modellierungsprozess im Unternehmen ↑

Im Modellierungsprozess sind die Produktverantwortlichen und die Fachabteilungen gefordert – planen sie ausreichend Ressourcen für diese Tätigkeit ein.
Der Weg zur fertigen Applikation kann in 3 Aufgabenbereiche eingeteilt werden:

  2.1    Spezifikation der abzubildenden Produktregelwerke
  2.2    Konzeption: Lösungswege entwickeln →
  2.3    Konfiguration: Modellierung in RuleBook →

2.1  Spezifikation der abzubildenden Produktregelwerke

Die im Produktkonfigurator abzubildenden Produktregelwerke aus verschiedenen Fachabteilungen werden gesammelt, systematisiert und teils erweitert. Diese Arbeit ist unabhängig vom eingesetzten Produktkonfigurator und liefert das Lastenheft der zu digitalisierenden Aufgaben. Typische Bereiche der Spezifikation sind:

Technische Regelwerke des Produktkerns:

• Verfahren der Auslegung und Dimensionierung, incl. Berechnungsverfahren.
• Meist sehr umfangreiche Regeln der Detailkonstruktion.
• Verwendete Normen und Werksnormen und deren Geltungsbereich.
• Verwendete Normteile/Artikel tabellieren.
• Ermitteln nicht explizit formulierter Regelwerke.
• Technologische Regelwerke der Fertigungsverfahren.
• PPS-Daten spezifizieren (Artikel, Stücklisten, Arbeitspläne und daraus die HK)
• Kalkulationsregeln.
• Umfang und Inhalte der Ergebnisdateien.
• ...

Strategische Festlegungen:

• Bevorzugung oder Vermeidung bestimmter Varianten.
• Die Rollen von Benutzergruppen ausarbeiten, z.B.:
  • unterschiedliche Eingabemöglichkeiten
  • unterschiedliche Dialoganzeigen (von z.B. Preisen)
  • unterschiedliche Ergebnisdokumente
• Design und Layout von Dialogen.

Regelwerke des Vertriebsprozesses:

• Darstellung des Produkts durch die Angebotsstruktur.
• Kalkulationsregeln.
• Aufbau und Inhalt der Kundendokumente.

2.2  Konzeption:  Lösungswege entwickeln

Wie werden die im vorigen Schritt spezifizierten Aufgaben im Produktkonfigurator umgesetzt? Die Teilaufgaben bis zur Umsetzungsanleitung sind:

• Grundlegende Lösungsstrategien entwickeln.
• Aus Fallbeschreibungen ein allgemeines Regelwerk abgeleitet.
• Auswahl geeigneter Lösungsmethoden aus einer Palette von Möglichkeiten.
• Berechnungsvorschriften algorithmieren.
• Konzeption der Produktstruktur aus funktionalen Baukästen.
• Tabellenwerke redundanzfrei definieren.
• Dialoge funktional entwickeln.
• Schnittstellen ausarbeiten, zusammen mit den jeweiligen Fachabteilungen.
• Ggf. fehlende Festlegungen in den Fachabteilungen anfordern.
• ...

In der Konzeptionsphase ist es wichtig, den optimalen Lösungsweg zu finden, da dieser grundlegende Strukturen der Gesamtkonfiguration legt. Ein optimaler Lösungsweg minimiert den Aufwand für die Konfiguration/Eingabe der Regelwerke und erhöht Transparenz und Wartbarkeit der Konfiguration.

2.3  Konfiguration:  Modellieren der Regelwerke in RuleBook

In der Konzeptionsphase wurden die grundlegenden Strukturen und Lösungswege entwickelt. »Konfiguration« bedeutet, diese Konzepte und die während der Konfigurationsarbeit zu entwickelnden Detaillösungen, in RuleBook einzugeben. Typische Aufgaben dieser Konfigurationsarbeit sind:

• Aufbau der customX-Produktstruktur aus Baukästen, Assistenten (Abfragen) und Templates (Dialoge).
• Berechnungen durch eine Folge von Formelberechnungen und Tabellenzugriffen formulieren.
• Erstellen und dokumentieren von Tabellen, die teils durch die Fachabteilungen auszufüllen sind.
• Zu Detailfragen Festlegungen in den Fachabteilungen anfordern.
• Dialoge ergonomisch und ästhetisch gestalten.
• Für Meilensteine der Umsetzung erfolgt (noch vor der Testphase) die
  • Verifikation von Dialogen, durch erfahrene Projektierer und die
  • Verifikation von Ergebnisdokumenten, durch die jeweiligen Rezipienten.
• Die Ergenisse der Verifikation werden durch Verbesserungen im Regewerk umgesetzt.

Ein großes Teilgebiet ist das Konfigurieren der Ergebnisdokumente und Dialoggrafiken:

• Für das Erzeugen von 2D- und 3D-Ergebnissen, werden viele CAD-Dateien erstellt und verlinkt.
• Zeichnungen und Abwicklungen aus Inventor-3D-Modellen ableiten.
• Vektorgrafiken mit mit dem customX-eigenen CAD-Kernel erzeugen.
• 2D- und 3D-Visualisierung in interaktiven Dialoggrafiken.
• Office-Dokumente: Erstellen von Vorlagen und Komposition eines Gesamtdokuments aus optionalen Subdokumenten.
• Schnittstellen- und Parameterdateien erzeugen.

3. Die Testphase ↑

Zu Beginn der Testphase sind folgende Schritte erreicht:

• Die Modellierung im geplanten Umfang ist umgesetzt.
  • Dialoge wurden durch erfahrene Projektierer∗innen verifiziert.
  • Ergebnisdokumente wurden hinsichtlich Form und Inhalt verifiziert.
• Das neue Modul ist EDV-technisch lauffähig. Die dazu erforderlichen Schnittstellen, sowie der Postprozess sind ausgetestet (s. dazu Integration des Moduls).
• Der Testplan ist ausgearbeitet und durch eine Reihe von Testprojekten abgebildet.
• Eventuell ist ein Testsystem eingerichtet, in dem Tester und Regelwerker gemeinsame Projekte öffnen können.

Mit dieser Ausgangsbasis hat die Testphase 2 Aufgaben:

  3.1    Nachweis fehlerfreier Ergebnisse und Dialoge
  3.2    Praxistest der automatisch erzeugten Ergebnisse →

3.1  Nachweis fehlerfreier Ergebnisse und Dialoge

Komplexe Variantenprodukte können eine unüberschaubare Anzahl von möglichen Varianten und Einbaufällen erzeugen. Es ist fast unmöglich alle Varianten und Konstellationen explizit zu testen. Deshalb ist es wichtig einen guten Testplan aufzustellen, der die kritischen Testfälle abdeckt. Entsprechende Testanordnungen werden durch Testprojekte abgebildet:

• Die Produktkundigen kennen die praktischen Knackpunkte ihres Produkts sehr genau und können entsprechende Testprojekte auswählen oder im Front-End eingeben.
• Die Regelwerker∗innen kennen die theoretischen Schwierigkeiten des regelwerks und liefern entsprechende Testprojekte, die teils während der Applikationserstellung verwendet wurden.

Für die praktische Durchführung des Tests gibt es verschiedene Vorgehensweisen, die auch in Kombination zur Anwendung kommen können. Alle Tests finden dabei in einem definierten Änderungsbericht (→Abschnitt 1) statt.

3.1.1  Ticket-orientierter Test

Optimal ist es für diesen Testablauf ein Testsystem einzurichten, in dem Tester und Regelwerker auf gemeinsame Testprojekte zugreifen können. Allerdings benötigt der customX-Testserver die auch im Produktivsystem benötigten Lizenzen für CAD und Office. Der Testablauf im Testsystem:

• Die Tester∗innen öffnen und modifizieren evtl. die Testprojekte, generieren und bewerten die generierten Ergebnisse. Mängel und Änderungswünsche werden über eine Fehlerliste oder ein Ticketsystem kommuniziert.
• Die Regelwerker∗innen passen das Regelwerk an, aktualisieren das Testsystem und geben die Testprojekte zum erneuten Test frei.

3.1.2  Standardisierter Massentest

Dieses Vorgehen zielt auf den umfassenden Test der Gesamtkonfiguration und beinhaltet entsprechend viele Testprojekte. Dieser Test wird routinemäßig durchgeführt, bevor ein Änderungsbericht im Produktivsystem eingespielt wird. Der Ablauf:

1. Referenzprojekte bestimmen: Eine Menge von Testprojekten, die den Entwurfsraum und kritische Konstellationen abbilden, wird im Laufe der Applikationsentwicklung aufgestellt.
2. Ergebnisse generieren: Für die Referenzprojekte werden die Ergebnisse erzeugt; eine Stapelverarbeitung kann mit customX leicht eingerichtet und gestartet werden.
3. Sichtprüfung: Die Ergebnisse werden einer Sichtprüfung unterzogen.

Erst wenn die generierten Ergebnisdokumente den Ansprüchen genügen, folgt der Praxistest.

3.2  Praxistest

Der zu testende Zielprozesses kann hinsichtlich der beteiligten Akteure und der Prozessführung sehr unterschiedlich sein (s. dazu auch customX integrieren). Hier können typische Test-Szenarien nur allgemein beschrieben; dabei haben wir folgende Akteure:

• Benutzergruppen, die den Front-End-Dialog bedienen, sind Standard- und Poweruser (mit unterschiedlichen Berechtigungen, z.B. interne und externe Projektierer), sowie Fertiger.
• Empfänger der automatisch generierten Ergebnisse sind Kunden und die Fertigung oder Subunternehmen.

Typische Szenarien:

• Ein Poweruser gibt ein reales Projekt (bzw. ein Anfrage) im Front-End ein und verwendet die Ergebnisdokumente für die Kundenkommunikation.
• Ein zu fertigendes Projekt wird im Front-End eingegeben und die Ergebnisdokumente werden in der Fertigung (oder vom Subunternehmen) verwendet.
• Ein zu fertigendes Projekt wurde im Front-End eingegeben.
  Ein Fertiger öffnet das Projekt, trifft fertigungsspezifische Festlegungen und verwendet die generierten Fertigungsdokumente.
• Sie wollen ein Front-End veröffentlichen und simulieren einen Standarduser, indem sie ein reales Projekt eingeben und die Ergebnisse verwenden.

4. Support, Ausbau und Change Management ↑

Wie gesagt, ist es bei komplexen Produkten fast unmöglich alle Konstellationen explizit auszutesten. Die Supportfälle sind:

• Im Echtsystem werden Fehler entdeckt.
• Aus dem Praxisbetrieb entstehen Änderungswünsche und Verbesserungsvorschläge.
• Durch den Praxisbetrieb ändern sich Prioritäten des geplanten Ausbaus.

Für die Bearbeitung der Supportfälle, des geplanten Ausbaus, sowie von Änderungsanforderungen, wird ein Ablaufplan benötigt. Die einzelnen Arbeiten werden in einer Fehlerliste oder in einem Ticketsystem zusammengefaßt und nach Priorität abgearbeitet.

...lesen sie hier mehr zur Projektplanung von Support, Ausbau und Änderungswesen.