Product Line Engineering mit iQUAVIS

Schreibe einen Kommentar / MBSE, iQUAVIS, Two Pillars Blog / Christian Dr. Bremer

Im Product Line Engineering (PLE) entstehen Produktlinien systematisch aus einer gemeinsamen Basis. Dahinter steckt ein hochkomplexes Engineering, das wir in diesem Beitrag in der Theorie erläutern. In einem weiteren Beitrag werden wir die praktische Umsetzung aufzeigen. Wie Produktlinien systematisch entstehen Product Line Engineering (PLE) verspricht, aus einer gemeinsamen Basis effizient viele individuelle Produkte zu entwickeln. In der Regel wird dabei zwischen Domänen-Engineering und Application Engineering unterschieden. Doch was passiert eigentlich in diesen beiden Phasen und wie unterstützt iQUAVIS bei der Umsetzung dieses Ansatzes? Zwei mal zwei Perspektiven Im Schaubild Abb. 1 unten ordnen wir die wesentlichen Fähigkeiten von iQUAVIS ein. Das Bild ist horizontal in zwei Bereiche unterteilt: Links: Domänen-Entwicklung, die sozusagen die wiederverwendbaren Kernartefakte in den Blick nimmt. Rechts: die Anwendungs-Entwicklung, die auf ein konkretes Produkt fokussiert. Vertikal werden zwei Ebenen unterschieden: Oben, die Marktperspektive, die Feature und Konfigurationen für die Kunden beschreibt, sowie unten die Architekturperspektive, in der es um die technische Basis geht, um ebendiese Feature realisieren zu können. Domänen-Entwicklung: Die gemeinsame Basis schaffen Den methodischen Einstieg in die Domänen-Entwicklung bildet das Feature-Modell. Es repräsentiert die Marktsicht einer Produktlinie. Dabei ist ein Feature ein vom Kunden bestellbares Merkmal. Ein Feature fasst inhaltlich funktionale und nicht-funktionale Anforderungen zusammen. Folgende Fragestellungen stehen hinter der Feature-Modellierung: Das Feature-Modell beschreibt also nicht ein einzelnes Produkt, sondern die gesamte Lösungsdomäne. Es ist das zentrale Kommunikationsmittel zwischen Vertrieb, Produktmanagement und Technik. Die Lösungsbausteine zu dem beschriebenen Feature-Modell finden wir in der Architekturperspektive in Form von Modulen bzw. architektonischen Bausteinen. Bei der Entwicklung dieser Bausteine zielt man auf: Jeder Baustein ist so entworfen, dass er für viele Produkte wieder verwendbar ist. Variabilität wird bewusst eingeplant – nicht als Sonderfall, sondern als Kernprinzip. Das Ergebnis der Domänen-Entwicklung ist damit: Anwendungs-Entwicklung: Konkrete Produkte bauen Während die Domänen-Entwicklung sozusagen die Bühne aufbaut, beginnt in der Anwendungs-Entwicklung die konkrete Ausprägung . Im oberen rechten Bereich des Schaubildes sieht man die Konfigurationen. Hier wird das Feature Model verwendet, um konkrete Produkte zu definieren: Eine Konfiguration ist damit eine gültige Auswahl aus dem Feature Model – sie beschreibt genau ein Produkt. Aus der Konfiguration wird auf der Architekturebene im unteren rechten Bereich die Produktarchitektur abgeleitet. Das Schaubild zeigt: So entsteht eine konkrete, lauffähige Architektur, die genau die zuvor gewählten Features unterstützt. Zwischenfazit kurz und knapp: Die Domänenentwicklung liefert also die Bausteine – die Anwendungsentwicklung setzt sie zusammen. Die Verbindung zwischen beiden Welten Ein zentrales Element des Bildes sind die Verbindungen: Genau diese Durchgängigkeit unterscheidet Product Line Engineering von klassischer Wiederverwendung oder Copy‑&‑Paste‑Entwicklung. Die Verknüpfung von Marktanforderungen bis zur technischen Umsetzung erfolgt modellbasiert und ist die Grundlage für Kommunikation und Kooperation Produktmanagent und Technik. Entscheidend ist, dass das aufgebaute Beziehungswissen nun in den unterschiedlichen Phasen der Produktentstehung genutzt wird: Diese Liste an Nutzungsmöglichkeiten ließe sich noch weiter fortführen. Wie unterstützt iQUAVIS bei diesem Ansatz? iQUAVIS bieten die notwendigen Toolfunktionalitäten, um den beschriebenen Ansatz umzusetzen. Es beinhaltet die Möglichkeit, Feature-Modelle zu definieren und entsprechende Abhängigkeiten zu modellieren. Die Feature können Lösungselementen zugeordnet werden. Bedingungen wie Exclude oder Mandatory können in verschiedenen Sichten angezeigt und bearbeitet werden. Der VariantenManager in iQUAVIS bietet darauf aufbauend die Möglichkeit, Varianten konkret auszuprägen – natürlich unter Berücksichtigung der Bedingungen des Featurebaums. iQUAVIS auch bietet die Möglichkeit, wiederverwendbare Architekturbausteine anzulegen. Es stellt alle gängigen Modellierungsmethoden des MBSE zur Verfügung, um die Architekturbausteine in konkreten Systemmodellen zu nutzen. Haben wir Ihr Interesse geweckt? Christian Dr. BremerDr. Christian Bremer ist Gründer und Geschäftsführer bei Two Pillars. Er verantwortet die Bereiche Entwicklung und IT und ist zuständig für iQUAVIS. Seit seiner Zeit beim Fraunhofer IEM beschäftigt sich Christian Bremer mit Model-Based Systems Engineering. Er berät und begleitet Unternehmen bei der Einführung. Dabei werden immer wieder auch neue Use-Cases und Feature in iQUAVIS implementiert. www.two-pillars.de/

Product Line Engineering mit iQUAVIS Weiterlesen »

Varianz im Systemmodell. Blogtitel Grafik mit Dr. Christian Bremer

Varianz im Systemmodell berücksichtigen

Schreibe einen Kommentar / MBSE, Two Pillars Blog / Christian Dr. Bremer

Varianz im Systemmodell ist neben der Interdisziplinarität einer der wesentlichen Komplexitätstreiber bei der Entwicklung moderner mechatronischer Produkte und daher auch einer der Hauptgründe zur Nutzung von Model-Based Systems Engineering. Dabei taucht Varianz an unterschiedlichen Stellen auf, sei es im Systementwurf, in der Stückliste oder der Fertigung. Im diesem Beitrag analysieren wir, wie die Varianz auf Systemebene berücksichtigt werden kann. Einordnung in den RFLP Ansatz Wir fokussieren uns in unserem Beitrag auf Varianz, die auf Systemebene entsteht. Betrachten wir ein Systemmodell nach dem RFLP-Ansatz, tritt Varianz typischerweise auf funktions-, logischer- und physischer Ebene auf. Auf Funktionsebene geht es typischerweise um mögliche alternative Funktionsumfänge, die das Produkt aufweisen kann. In diesem Zusammenhang wird an Stelle einer Funktion häufig auch der Begriff „Feature“ verwendet. Beschrieben wird, welche Funktionen oder Feature, ein Kunde wählen kann oder am Markt angeboten werden sollen. Auf logischer Ebene wird dann zugeordnet, wie eine Funktion umgesetzt wird. Dabei findet man jedoch nicht unbedingt immer eine 1:1 Zuordnung, es wird vielmehr in Betracht gezogen, ob ein Systemelement bspw. mehrere Funktionen umsetzen kann oder ob eine Überspezifikation zugunsten einer Teileersparnis Sinn macht. Darüber hinaus kann es auch gut sein, dass Funktionen, die ähnlich klingen und vermeintlich nur geringfügige Unterschiede aufweisen, mit anderen Technologien oder unterschiedlichen Produktfamilien umgesetzt werden. Dementsprechend ergibt sich der Variantenbaum aus genannten Überlegungen und ist daher in der Regel kein einfaches Spiegelbild des Funktionsbaums. Auf physischer Ebene wird die konkrete Umsetzung mit einem Bauteil definiert. Auf dieser Ebene spiegelt sich Varianz bspw. in Bauteilen wider, die von unterschiedlichen Zulieferern kommen, aber die gleich Spezifikation aufweisen oder an unterschiedlichen Standorten verbaut werden. Berücksichtigung von Varianz im Systemmodell Wie im Diagramm angedeutet, verstehen wir Varianz als Teil der Beziehungen zwischen den Modellelementen. Dabei kann diese Beziehung drei Ausprägungen annehmen: Darüber hinaus kann die Varianz in einem Modell durch Bedingungen eingeschränkt werden. Solche Bedingungen sind: In iQUAVIS setzen wir Varianten-Beziehung als Teil der Hierarchiebeziehung um. Im Bild zu sehen ist das Beispiel einer Wetterstation, die bspw. über zwei verschiedene Bildschirmgrößen verfügen könnte. Mögliche Bedingungen werden mittels Abhängigkeitsbeziehung modelliert, im Beispiel zwischen der kleineren Bildschirmgröße und dem Feature, auch Wind messen zu können. Im rechten Teil des Bilds wird der Feature Baum im „Varianten Filter“ noch einmal visualisiert. Hier gibt es die Möglichkeit, mittels Checkboxen, eine bestimmte Variante oder Option auswählen und somit die Varianz des Systemmodells auszuprägen. Damit kann zum einen das Verhalten des Modells geprüft sowie zum anderen konkrete Konfigurationen erzeugt werden. Nutzung des Systemmodells Ein MBSE Modell, das Varianz beinhaltet, kann als Grundlage zur Kommunikation und Kooperation mit anderen Projektbeteiligten genutzt werden. Die Informationen zur Varianz im Systemmodell bilden die Basis für verschiedene aufbauende Aktivitäten. Eine Plausibilitätsprüfung kann sicherstellen, dass die modellierte Variantenlogik frei von Widersprüchen ist. Das Product Line Engineering benötigt die Möglichkeit, Varianz auf Systemebene darzustellen, die sie sowohl für die Beschreibung der Produktlinie als auch der Produktfamilie relevant ist. In iQUAVIS setzt das Thema Varianz mit dem VariantenManager um. Mehr dazu erfahren Sie auf der Seite zum Variantenmanagement mit iQUAVIS. Christian Dr. BremerDr. Christian Bremer ist Gründer und Geschäftsführer bei Two Pillars. Er verantwortet die Bereiche Entwicklung und IT und ist zuständig für iQUAVIS. Seit seiner Zeit beim Fraunhofer IEM beschäftigt sich Christian Bremer mit Model-Based Systems Engineering. Er berät und begleitet Unternehmen bei der Einführung. Dabei werden immer wieder auch neue Use-Cases und Feature in iQUAVIS implementiert. www.two-pillars.de/

Varianz im Systemmodell berücksichtigen Weiterlesen »

Die CONSENS Methode in iQUAVIS, Blog Titelbild mit Dr. Christian Bremer und Headline

Die Methode CONSENS in iQUAVIS

Schreibe einen Kommentar / MBSE, iQUAVIS, Two Pillars Blog / Christian Dr. Bremer

In diesem Beitrag stellen wir die Umsetzung der Methode CONSENS in iQUAVIS vor. iQUAVIS lässt sich für die Umsetzung der CONSENS Methode speziell vorbereiten. Wir liefern das entsprechende Profil standardmäßig an unsere Kunden aus, die sich damit ihre konkrete CONSENS Umsetzung auch beliebig weiter anpassen können. Ein einheitlicher methodischer Rahmen ist dabei nicht nur wichtig, um in das Thema einzusteigen, sondern auch, um sicherzustellen, dass alle Modelle im Unternehmen vergleichbar sind. Nur so können sie letztlich wiederverwendet und ausgewertet werden. Mehr zum methodischen Hintergrund der Methode CONSENS finden Sie in unserem separaten Beitrag zu CONSENS. Übersicht zur CONSENS Methode Die CONSENS Methode ist gegliedert in zwei Phasen: Die Analyse- und die Synthese-Phase. In der ersten Phase arbeitet der Anwender mit Anwendungsszenarien, Umfeldelemente und Anforderungen. In der zweiten Phase sind es hauptsächlich Funktionen, Lösungselement und ggf. Verhalten. In iQUAVIS bieten sich Baumansichten an, um die Übersicht über die Phasen und die Traceability zwischen den Modellelemente zu überblicken. Neben den reinen Daten gibt CONSENS auch Bearbeitungsschritte vor, nämlich die schrittweise Erarbeitung der einzelnen Partialmodelle. iQUAVIS ermöglicht die Umsetzung solcher Vorgaben in der Prozesstabelle. Hier werden Aufgaben (standardisiert) definiert. Zu jeder Aufgabe gehören Sichten, in die der Nutzer direkt springen kann um so die Inhalte zu erarbeiten. Diese Sicht richtet sich daher an alle Nutzer und wird als Absprungebene in die einzelnen Aktivitäten genutzt. Umsetzung der Partialmodelle Die Partialmodelle von CONSENS werden in verschiedene Sichten in iQUAVIS umgesetzt. Für die Darstellung von Wirkstruktur und Umfeldmodell werden die Entity-Block-Diagramme verwenden. Für die Funktionshierarchie wird mit einer Baumansicht gearbeitet. Wie in CONSENS beabsichtigt, arbeitet iQUAVIS dabei auch mit starken optischen Unterscheidungselementen: So sind bspw. alle lösungsbehafteten Elemente (in iQUAVIS „Entity“) mit rechtwinkligen Ecken versehen. Lösungsneutrale Modellelemente wie bspw. Funktionen haben abgerundete Ecken. Auch mit Farben für Elemente oder Beziehungen kann gearbeitet werden. Die Verhaltensmodellierung wird ebenfalls mit den entsprechende Diagrammtypen ermöglicht. In den Bildern zu sehen sind die Sequenz-, Aktivitäts- und Zustandsdiagramme. Traceability und Nutzung der Methode CONSENS in iQUAVIS Die in CONSENS angefertigten Partialmodelle stehen nicht für sich alleine, sondern ergeben ein konsistentes Ganzes. Dazu werden die Modellelemente zueinander verknüpft. Beispielsweise ergeben sich Anwendungsszenarien oder Use Cases aus Umfeldelementen; Funktionen werden durch Systemelemente realisiert; Anforderungen werden mit Testfällen abgesichert. In der unten stehenden Grafik haben wir versucht, das so entstehende Systemmodell zu veranschaulichen. Insbesondere die Querbeziehungen bilden später die Grundlage für aussagekräftige Auswertungen: Wir haben dem Aufbau des Systemmodells einen eigenen Beitrag gewidmet: Das Systemmodell mit iQUAVIS Anpassung des CONSENS Profils Die CONSENS Methode ist gut geeignet um einen Einstieg in das Thema MBSE zu ermöglichen. Sobald man jedoch als Nutzer die ersten Projekterfahrungen gesammelt hat und Schritt für Schritt tiefer in das Thema einsteigt, stellt man in der Regel fest, dass es weitergehende Anforderungen an die Methode gibt. Beispielsweise werden weitere Anforderungsklassen notwendig, oder neue Sichten werden benötigt für bestimmte (bereits etablierte) Methoden. Diese Situation ist unser Erfahrung nach die Regel, denn letztlich gibt es immer unternehmensspezifische Aspekte, die der Branche, der Art der Projekte oder den Unternehmensstruktur geschuldet sind. Hier bietet iQUAVIS intuitiv zu bedienende Tools für die Erweiterung an. Neue Modellelement-Klassen oder neue Attribute können direkt im Tool erzeugt werden. iQUAVIS bietet dazu ein separates Administrationstool, mit dem Vorlagen und Profile zentral editiert und an alle Nutzer ausgerollt werden können. So kann auch dauerhaft sichergestellt werden, dass alle Nutzer mit den selben Modellelementen arbeiten und die Modelle so vergleichbar und standardisiert weiterverwendbar werden. Ihre Fragen? Haben Sie noch Fragen zur Methode CONSENS und wie iQUAVIS sie umsetzt? Fragen Sie uns gern über die Kommentarfunktion oder melden Sie sich für eine kostenlose Live Demo am Beispiel Ihres Use Cases an! Wir freuen uns auf Ihre Anfrage! Mehr über iQUAVIS erfahren Sie außerdem auf dieser Seite. Christian Dr. BremerDr. Christian Bremer ist Gründer und Geschäftsführer bei Two Pillars. Er verantwortet die Bereiche Entwicklung und IT und ist zuständig für iQUAVIS. Seit seiner Zeit beim Fraunhofer IEM beschäftigt sich Christian Bremer mit Model-Based Systems Engineering. Er berät und begleitet Unternehmen bei der Einführung. Dabei werden immer wieder auch neue Use-Cases und Feature in iQUAVIS implementiert. www.two-pillars.de/

Die Methode CONSENS in iQUAVIS Weiterlesen »

iQUAVIS ist TÜV-zertifiziert mit ISO 26262

Schreibe einen Kommentar / iQUAVIS, News / Christian Dr. Bremer

Zum zweiten Mal in diesem Jahr freuen wir uns über ein TÜV-Zertifikat! Nachdem wir im Januar als Unternehmen mit der ISO 27001 zertifiziert wurden (wir berichteten), wurde nun iQUAVIS in der Version 9 vom TÜV Rheinland zertifiziert. Die ISO 26262 Die ISO 26262 definiert ein Vorgehensmodell zusammen mit geforderten Aktivitäten und Arbeitsprodukten („work products“) sowie anzuwendenden Methoden in Entwicklung und Produktion. Dabei deckt sie unter anderem auch die Konzeptphase oder Produktentwicklung auf Systemlevel ab. Damit betrifft die Norm auch Aktivitäten, die in iQUAVIS durchgeführt werden. iQUAVIS ist mit den bekannten Sichten und Modellierungsmöglichkeiten bestens geeignet, die geforderten Methoden umzusetzen – das hat nun auch der TÜV Rheinland bestätigt. Mit der Zertifizierung erhalten Nutzer die Sicherheit, dass iQUAVIS die Methoden verlässlich umsetzt und iQUAVIS somit auch für sicherheitsrelevante Risikoanalysen wie der HARA geeignet ist. iQUAVIS: Die Zertifizierung Die iQUAVIS Version 9, wurde durch den TÜV Rheinland für ISO 26262 für die Kapitel 3 -6, 8, 11 und 12 zertifiziert. Für die Umsetzung stellen wir in iQUAVIS geeignete Vorlagen zur Verfügung – sprechen Sie uns gern darauf an! Den Wortlaut des Zertifikats haben wir hier übersetzt: iQUAVIS ist ein Softwaretool, das die Anforderungen des Tool Confidence Level (TCL) 1 für ASIL D gemäß ISO 26262-8 erfüllt. iQUAVIS unterstützt während des gesamten Entwicklungsprozesses eine Vielzahl von Aufgaben, darunter Systemdesign, Projektmanagement, Risikomanagement und Änderungsmanagement. Dazu gehören Aktivitäten wie Konzeptdesign, Systemdesign, Hardwareentwicklung und Softwareentwicklung für Automobilprodukte und -komponenten. iQUAVIS erleichtert die Erstellung der in ISO 26262 Teile 3 – 6, 8, 11 und 12 geforderten Arbeitsprodukte. Das Zertifikat mit dem Originaltext auf Englisch steht hier zur Einsicht bereit. Arbeiten mit iQUAVIS und der ISO 26262 Wir wollen Ihnen die Arbeit möglichst erleichtern und stellen für Ihren Prüfprozess geeignete Vorlagen zur Verfügung. Christian Dr. BremerDr. Christian Bremer ist Gründer und Geschäftsführer bei Two Pillars. Er verantwortet die Bereiche Entwicklung und IT und ist zuständig für iQUAVIS. Seit seiner Zeit beim Fraunhofer IEM beschäftigt sich Christian Bremer mit Model-Based Systems Engineering. Er berät und begleitet Unternehmen bei der Einführung. Dabei werden immer wieder auch neue Use-Cases und Feature in iQUAVIS implementiert. www.two-pillars.de/

iQUAVIS ist TÜV-zertifiziert mit ISO 26262 Weiterlesen »

Produktentwicklung mit iQUAVIS: Die 3 Säulen des Systemmodells

Schreibe einen Kommentar / Anwendungsbeispiele, iQUAVIS / Christian Dr. Bremer

iQUAVIS ist ein MBSE-Tool für die Produktentwicklung, erfolgreiches Systems Engineering und integriertes Projektmanagement. Ein großer Vorteil ist die intuitive Bedienbarkeit der Software. So kann Ihr Team iQUAVIS schnell und ohne hohe Vorabinvestitionen erlernen und erste Schritte unternehmen. Über iQUAVIS iQUAVIS wurde vom japanischen Unternehmen DENTSU SOKEN Inc. gemeinsam mit produzierenden Unternehmen wie Toyota entwickelt. In Zusammenarbeit mit dem Fraunhofer IEM und Two Pillars wurde es zu einem SysML-freien Modellierer weiterentwickelt, der sich perfekt an jede MBSE-Methode, z. B. die CONSENS-Methode, anpasst. iQUAVIS steht für „Quality Visualisation“ und verdeutlicht den Ursprung: Quality Engineering. Wie funktioniert Produktentwicklung mit iQUAVIS? Mit dem Systemmodell in iQUAVIS decken wir drei Hauptaspekte eines Systems ab: die Struktur, das Verhalten und die Anforderungen. Die strukturelle Betrachtung beginnt typischerweise mit einer Umgebungsbetrachtung. Das zu entwickelnde Produkt ist eine Blackbox, und die Elemente der Umgebung, bzw. des Kontexts, werden identifiziert. Die Beziehungen zwischen dem System und seiner Umgebung werden durch Funktionslinien und entsprechende Ports dargestellt. Bei der Betrachtung des Produkts transformieren wir die Blackbox in eine Whitebox und betrachten die inneren Bestandteile, bzw. Module des Systems. Die Wirkstruktur beschreibt, wie die verschiedenen Systemteile zusammenarbeiten und wie die zuvor identifizierten Schnittstellen bzw. Ports genutzt werden. Solche Blockdiagramme decken Aspekte aller Disziplinen ab und bilden so die Grundlage für ein einheitliches Systemverständnis aller Beteiligten. Systemelemente können übrigens auch klassifiziert werden, um bspw. Sensoren von Aktoren zu unterscheiden. Mit der Verhaltensansicht betrachten wir die Funktionalität des Systems. Der Einstieg in das Verhalten wird häufig über Use-Cases gemacht, die das Systemverhalten auf übergeordneter Ebene beschreiben. Das Systemverhalten kann dann weiter detailliert werden. Mit dem Zustandsdiagramm beschreiben wir die Betriebszustände des Systems, z.B.: Ein Ereignis löst den Übergang von einem Zustand in einen anderen aus. Ein Zustand kann sich dann auf ein funktionales Verhalten beziehen, das in diesem Zustand ausgeführt wird. Dieses Verhalten lässt sich im Funktionsblockdiagramm nach den Regeln eines Aktivitätsdiagramms beschreiben. Dabei werden Funktionen ein einen Ablauf gebracht. Es gibt auch die Möglichkeit, technische Abhängigkeiten zwischen Funktionen zu beschreiben. Noch detaillierter wird es dann mit dem Sequenzdiagramm, mit dem konkrete Kommunikation zwischen Systemelementen beschrieben werden kann. Anforderungen und Anforderungsmanagement Anforderungen können aus etablierten Anforderungsmanagement-Tools synchronisiert, aber auch basierend auf der zuvor beschriebenen Analyse abgeleitet oder verfeinert werden. iQUAVIS bietet beispielsweise Baumansichten zur Übersicht über die Anforderungen. Darüber hinaus ermöglicht eine solche Ansicht die Verknüpfung der Anforderungen mit den zuvor genannten Funktionen und Lösungselementen. Das Ergebnis ist ein Traceability-Baum, der die Anforderungen, die funktionale und die logische Ansicht abdeckt. Projektmanagement Das Projektmanagement in iQUAVIS bietet verschiedene Möglichkeiten zur Steuerung des Entwicklungsprojekts. Aufgaben werden in einem Zeitplandiagramm organisiert, wie unten dargestellt. Darüber hinaus ermöglicht iQUAVIS beispielsweise die Verwaltung von Ressourcen und kann mehrere Projekte in einem Plan abwickeln. Kurz gesagt: iQUAVIS bietet Ihnen … Kontakt und weitere Informationen Für Fragen stehen wir Ihnen gern zur Verfügung. Schauen Sie sich auch gern unsere Webinare und Tutorials auf YouTube an, stöbern Sie hier auf unserer Seite oder richten Sie Ihre Mitteilung direkt an uns. Wir sind übrigens nicht nur Tool-Vendoren, sondern beraten auch zum Thema Systems Engineering und MBSE. Mehr über iQUAVIS Lernen Sie iQUAVIS kennen: Christian Dr. BremerDr. Christian Bremer ist Gründer und Geschäftsführer bei Two Pillars. Er verantwortet die Bereiche Entwicklung und IT und ist zuständig für iQUAVIS. Seit seiner Zeit beim Fraunhofer IEM beschäftigt sich Christian Bremer mit Model-Based Systems Engineering. Er berät und begleitet Unternehmen bei der Einführung. Dabei werden immer wieder auch neue Use-Cases und Feature in iQUAVIS implementiert. www.two-pillars.de/

Produktentwicklung mit iQUAVIS: Die 3 Säulen des Systemmodells Weiterlesen »

Requirements-Management-Tools-Schnittstellen in iQUAVIS

Schreibe einen Kommentar / iQUAVIS, Two Pillars Blog / Christian Dr. Bremer

Systems Engineering bedeutet Denken und Arbeiten in Systemen und Modellen. Das gilt auch für SE-Tools wie unsere MBSE Software iQUAVIS. Systems Engineering bezieht sich dabei nicht nur auf die Systemarchitektur (in iQUAVIS), sondern auch auf viele andere auf Systemebene relevante Informationen – zum Beispiel Anforderungen (Requirements). Unsere Kunden arbeiten mit unterschiedlichen Requirements-Management-Tools, an die iQUAVIS dann von uns angeschlossen wird. Wir wollen im Folgenden einen Blick auf diese Schnittstellen zu Requirements-Management-Software werfen. Requirements-Management-Tools: Datenaustausch mit ReqIF Prinzipiell ist ein Datenaustausch mit RM-Tools nichts Neues. Alt bewährt ist der Datenaustausch über ReqIF. iQUAVIS ermöglicht den Im- und Export von ReqIF Dateien und ist dabei auch roundtripfähig. Das bedeutet, dass die IDs von Anforderungen bei Änderungen beibehalten werden, sodass Änderungen an Anforderungen nachgezogen werden können. Das ReqIF-Format ist etabliert, aber es gibt Nachteile: Der dateibasierte Ansatz birgt die Gefahr, dass man mit veralteten Daten arbeitet und auf diese Weise viel Zeit und Nerven investieren muss, um auf einem aktuellen Stand zu bleiben. Mit ReqIF werden einzelne Dateien ausgetauscht, die womöglich schon kurz nach dem Export nicht mehr aktuell sind. Das wird besonders bei großen Projekten mit vielen Projektteilnehmern zum Killer und führt zu Ärger, Überstunden und Verzögerungen. Datenbankbasierter Austausch auf Basis von Web-Schnittstellen Aufgrund der genannten Erfahrungen und weil uns das Streben nach Optimierung in der DNA liegt, bieten wir unseren Kunden für iQUAVIS schon seit langem webbasierte Schnittstellen an – zugeschnitten auf die kundenspezifischen Bedürfnisse. Was wir immer wieder zu Ohren bekommen, ist die Annahme, mit dem Einstieg ins Systems Engineering und in iQUAVIS müsse man das gesamte Unternehmen umkrempeln und die Organisation auf den Kopf stellen. Das stimmt so nicht (ganz): Wir passen iQUAVIS an Kundenbedürfnisse an. Das begann ursprünglich als individuelle Lösung. Inzwischen sind daraus eigene Schnittstellen entstanden, die wir als zusätzliche Feature anbieten. Wir werden diese Plugins demnächst hier auf dem Blog einzeln vorstellen. Über Webschnittstellen wie bspw. die REST API realisieren wir einen datenbankbasierten Austausch, der das Arbeiten mit stets aktuellen Daten ermöglicht – auch bei großen Projekten und auch bei großen Teams. Wir bieten mittlerweile Schnittstellen zu verschiedenen Tools an, etwa zu Jira oder zu Codebeamer an. Mit den Schnittstellen verknüpfen Sie die entsprechenden Umgebungen kinderleicht: Sie werden per URL angesteuert. In der Schnittstellenkonfiguration erfolgt dann das Mapping zwischen Anforderungsklasse und iQUAVIS-Klasse. Die Datenintegration läuft dann auf Knopfdruck. Dieser datenbankbasiere Ansatz bietet nicht nur den Vorteil, dass Daten schnell aktuell gehalten werden können, es werden auch Konzepte für Rechte/Rollen leicht durchsetzbar, da wir mit den bestehenden Berechtigungen auf dem Requirements-Tool arbeiten. Immer ein offenes Ohr für unsere Kunden Durch die enge Zusammenarbeit mit den Kunden sind wir von Two Pillars sehr nah an der Praxis: Wir verkaufen Ihnen nicht einfach die Software und wünschen viel Spaß beim Ausprobieren, sondern wir begleiten unsere Kunden in ihrem Prozess zum Model-Based Systems Engineering und passen iQUAVIS immer detaillierter an Ihre Anforderungen an. Uns macht es jedes Mal Spaß, die Fortschritte zu sehen und auch selbst dazuzulernen. Nicht umsonst bieten wir regelmäßig Key User Meetings an, bei denen wir Neues vorstellen und den Anwendern auch untereinander die Möglichkeit geben, sich auszutauschen. Denn auch wenn die Branchen und Produkte verschieden sind – die Fragen und Probleme sind oft ähnlich. Haben Sie Fragen zu unseren Schnittstellen? Schreiben Sie gern einen Kommentar oder wenden Sie sich per Kontaktformular an uns. Weitere Informationen zu unseren Schnittstellen finden Sie hier. Christian Dr. BremerDr. Christian Bremer ist Gründer und Geschäftsführer bei Two Pillars. Er verantwortet die Bereiche Entwicklung und IT und ist zuständig für iQUAVIS. Seit seiner Zeit beim Fraunhofer IEM beschäftigt sich Christian Bremer mit Model-Based Systems Engineering. Er berät und begleitet Unternehmen bei der Einführung. Dabei werden immer wieder auch neue Use-Cases und Feature in iQUAVIS implementiert. www.two-pillars.de/

Requirements-Management-Tools-Schnittstellen in iQUAVIS Weiterlesen »

iQUAVIS 7.0 – Update 2023

Schreibe einen Kommentar / iQUAVIS, Updates / Christian Dr. Bremer

iQUAVIS 7.0 ist da! In den letzten Wochen haben wir intensiv an dem Update unserer MBSE Software gearbeitet, um iQUAVIS noch bedienungsfreundlicher zu machen. Nun ist iQUAVIS 7.0 vollständig ausgerollt und bereits bei allen Kunden in Betrieb. Die neue Version bringt einige Verbesserungen mit, die das Arbeiten mit ihr noch einfacher und intuitiver macht. Im Folgenden stellen wir einige Highlights der Version 7.0 vor. Browserunterstützung für das Projektmanagement iQUAVIS ist dient als Tool in erster Linie einem umfassenden Projektmanagement und verbindet unterschiedliche Disziplinen in der Produktentwicklung. Dieser ganzheitliche Ansatz des Systems Engineering ist die große Stärke der Software. In der Version 7.0 haben wir an der Verbesserung des Projektmanagements gearbeitet: Projektpläne und Aufgaben sind nun auch über den Browser verfügbar. Die Voraussetzung dafür ist die Web-API im Lizenzpaket. Mit der Browserunterstützung kann der User über einen Browser iQUAVIS bedienen, ohne dass die Software auf dem jeweiligen Gerät installiert sein muss! Das erleichtert nicht nur die interdisziplinäre Zusammenarbeit, sondern auch die Installation der Software selbst. Diese Vorbereitungen für eine Browser-Readiness beschränkt sich zunächst auf das Projektmanagement, bildet aber gleichzeitig die Grundlage, um in Zukunft auch MBSE-Modelle im Browser verfügbar zu machen – weitere Updates zu diesem Thema werden demnächst folgen. Neuigkeiten geben wir über den Newsletter, hier auf dem Blog und über unsere LinkedIn-Seite bekannt. Arbeitsblätter Die Browserunterstützung ist die größte Neuerung beim Update auf iQUAVIS 7.0, aber nicht die einzige: Wir haben noch an weiteren kleinen, nützlichen Details gefeilt, die das Arbeiten mit iQUAVIS leichter machen: Innerhalb der Arbeitsblätter ist nun das Editieren innerhalb einer Zeile möglich. Außerdem haben wir die Filter-Funktion in orthogonalen Tabellen verbessert. Baumdiagramme mit zusätzlichen Bedingungen Bei den Baumdiagrammen ist nun eine erweiterte Vorwärts- und Rückwärtsexpansion mit zusätzlichen Bedingungen möglich. Die Funktion „Baum-Erweiterung“ wurde um die Möglichkeit ergänzt, mit ausgewählten Bedingungen zu erweitern. Web-API Die Web-API wurde in ihrem Funktionsumfang deutlich erweitert. Die Erweiterung dient bereits der Vorbereitung für das browsergestützte Arbeiten, auf dem künftig ein Schwerpunkt liegen wird. Performanceverbesserung Beim Laden und Anlegen neuer Projekte ist eine deutliche Performanceverbesserung spürbar: iQUAVIS läuft schneller und effizienter! Christian Dr. BremerDr. Christian Bremer ist Gründer und Geschäftsführer bei Two Pillars. Er verantwortet die Bereiche Entwicklung und IT und ist zuständig für iQUAVIS. Seit seiner Zeit beim Fraunhofer IEM beschäftigt sich Christian Bremer mit Model-Based Systems Engineering. Er berät und begleitet Unternehmen bei der Einführung. Dabei werden immer wieder auch neue Use-Cases und Feature in iQUAVIS implementiert. www.two-pillars.de/

iQUAVIS 7.0 – Update 2023 Weiterlesen »

iQUAVIS 5.0

Updates, iQUAVIS / Christian Dr. Bremer

iQUAVIS hilft Ihnen, komplexe Entwicklungsprojekte mit Hilfe von Systems Engineering zu meistern. Mit seinen Komponenten Systemarchitektur und Projektmanagement verschafft Ihnen iQUAVIS den entscheidenden Wettbewerbsvorteil. Bringen Sie Ihr Entwicklungsprojekt erfolgreich und schneller zum Abschluss! Die Version 5.0 von iQUAVIS beinhaltet viele spannende Neuerungen mit Fokus auf die Verbesserung von Arbeitsabläufen und Usability, so dass die Zusammenarbeit in Projekten noch reibungsloser verläuft. Insbesondere ist die nahtlose Zusammenarbeit mit Microsoft Office-Produkten gelingt nun noch besser. Einige Beispiele stellen wir heute vor. Action Priority Tables Jetzt auch Action Priority Tables mit iQUAVIS anwenden für Ihre FMEA konform mit VDA/AIAG Standard. Zur Priorisierung von Risiken wird in der FMEA die Schwere (Severity), Auftretenswahrscheinlichkeit (Occurance) und Entdeckungswahrscheinlichkeit (Detectability) bewertet. Das Produkt dieser drei Werte ergibt in der klassischen Form der FMEA die sogenannte Risikoprioritätszahl. Je höher diese Zahl, desto höher auch die Priorität, die diesem Risiko beigemessen wird. Dieses Vorgehen hat jedoch die Schwachstelle, das z.B. schwerwiegende Risiken eventuell zu gering bewertet werden, sofern die anderen beiden Werte niedrig sind. Dabei wäre bereits das einmalige Auftreten katastrophal. Im neuen Standard der VDA/AIAG werden anstatt der Risikoprioritätszahl Action Priority Tables genutzt. Hierbei wird mit Wertebereichen für die drei beschriebenen Einflussfaktoren gearbeitet. Auf diese Weise können Risiken realitätsnäher bewertet werden. Die Einordnung des jeweiligen Risikos erfolgt dann in eine der drei Kategorien – gering, mittel oder hoch. iQUAVIS unterstützt beide Varianten der FMEA, Im folgenden Bild ist dargestellt, wie zusätzlich zur herkömmlichen Methode nun auch die Dimension der Action Priority betrachtet und mit in die Bewertung einbezogen wird. Individualisierte Aufwandsplanung Aufgabendauer präziser planen! Ein und dieselbe Aufgabe kann je nach Erfahrung des zugewiesenen Mitarbeiters schneller oder langsamer bearbeitet werden. Wenn man diesen Faktor in der Aufgabenplanung nicht berücksichtigt, führt das zu Fehlplanungen. Mit Hilfe von Faktoren, die den Erfahrungsgrad der Mitarbeiter widerspiegeln, ermöglicht iQUAVIS eine realistische Planung der Aufgaben auch bei Wechsel der Zuständigkeit. Nehmen Sie als Beispiel eine Aufgabe, für die im Schnitt 6 Personentage benötigt werden. Teilt man nun diese Aufgabe gleichmäßig auf drei verschiedene Ressourcen auf, ergibt sich als Basis zur Berechnung der Gesamtdauer dieser Aufgabe folgendes Bild: Eine Ingenieurin erledigt ihren Teil der Aufgaben in zwei Tagen (Faktor 1) und ein Senior Engineer erledigt seinen Teil der Aufgaben in 1,4 Arbeitstagen (Faktor 0,7). Ein Junior Engineer benötigt dagegen 3 Arbeitstage für seinen Teil (Faktor 1,5). Insgesamt wird die Aufgabe bei gleichmäßiger Verteilung in 6.5 Tagen erledigt sein. iQUAVIS nutzt diese Faktoren bei der Zuweisung von Aufgaben und ermöglicht so eine deutlich realitätsnähere Planung. Die Faktoren dienen dabei rein der Einstufung des Erfahrungsgrads und nicht als Einzelbewertung der individuellen Mitarbeiter. Mit diesem Feature erweitern sich für den Projektplaner die Möglichkeiten der Aufgabenplanung. Außerdem sind die Erwartungen an die Mitarbeiter transparent und nachvollziehbar. Automatisiertes Einfärben von Elementen: Neue Möglichkeiten der Visualisierung Wir arbeiten in iQUAVIS bewusst mit Farben, um Unterschiede zwischen Klassen, Datensätzen u.a. zu visualisieren. Es ist jetzt möglich Modellelemente per Knopfdruck einzufärben. Diese Einfärbung kann auf Basis von Klassen, Datensätzen oder benutzerdefiniert erfolgen. So kann schnell überblickt werden, welche unterschiedliche Klassen oder Datensätze in einem Modell vorhanden sind. In Diagrammen und Bäumen ist es jetzt möglich, zwischen verschiedenen farblichen Darstellungen zu wechseln. Die folgenden Bilder zeigen die Möglichkeit, in Diagrammen zwischen Farben Bäume ermöglichen den Wechsel zwischen Klassen- und Datensatz-Darstellung. Aus der Kombination aus Klassen und Datensätzen ergeben sich interessante neue Möglichkeiten zur Darstellung Ihrer Modelle. Microsoft Outlook und iQUAVIS synchronisiert Sparen Sie Arbeitsschritte = Sparen Sie Zeit! Aufgaben werden in iQUAVIS bisher im Home-Screen oder im Projekt übersichtlich dargestellt. Mit der neuen iQUAVIS Version können Mitarbeiter bei neuen Aufgaben direkt per E-Mail informiert werden. Der Mitarbeiter kann mit dieser Mail direkt in das iQUAVIS Projekt navigieren oder sogar die Aufgaben unmittelbar in der Mail quittieren. Die Aktualisierung der Aufgaben wird direkt mit dem iQUAVIS Projekt synchronisiert. Die Notwendigkeit, iQUAVIS zu öffnen und manuell die Information hinzuzufügen, d.h. den Aufgabenstatus auf „erledigt“ zu setzten, entfällt. Dadurch wird die Aufgabenbearbeitung in iQUAVIS noch effektiver in den Arbeitsalltag integriert. Mit diesem Feature machen Sie einen großen Schritt in Richtung verbesserte Workflows und nahtlose digitale Prozesssteuerung! Insbesondere auch die Kombination mit dem Microsoft Teams-Connector „2Psync“ bietet dann eine ganzheitliche Kommunikationslösung zwischen Technik und Projekt. Single Sign-on (SSO) mit Microsoft Azure Machen Sie sich das Arbeitsleben einfacher, indem Sie die Single Sign-on (SSO) Methode mit Microsoft Azure nutzen. Ohne SSO müssen Sie sich bei jedem Start von iQUAVIS mit Ihrem Benutzernamen und einem (hoffentlich anspruchsvollem) Kennwort einloggen.Mit SSO, können Sie sich diesen Schritt in Zukunft sparen: Nachdem Sie sich wie gewohnt beim Start Ihres Computers in ihr Windows-Konto eingeloggt haben, brauchen Sie iQUAVIS nur noch zu starten und können direkt loslegen, ohne zusätzliche Passworteingabe. Die Authentifizierung wird im Hintergrund über Microsoft Azure abgewickelt. Das ist nicht nur bequemer sondern auch sicherer. Denn so entfällt das „Passwort-Wirrwarr“ und Logins können zentral verwaltet werden. Christian Dr. BremerDr. Christian Bremer ist Gründer und Geschäftsführer bei Two Pillars. Er verantwortet die Bereiche Entwicklung und IT und ist zuständig für iQUAVIS. Seit seiner Zeit beim Fraunhofer IEM beschäftigt sich Christian Bremer mit Model-Based Systems Engineering. Er berät und begleitet Unternehmen bei der Einführung. Dabei werden immer wieder auch neue Use-Cases und Feature in iQUAVIS implementiert. www.two-pillars.de/

iQUAVIS 5.0 Weiterlesen »

iQUAVIS 4.0 – unser MBSE Software-Update

Updates, iQUAVIS, News / Christian Dr. Bremer

iQUAVIS 4.0 ist da! Wir freuen uns, Ihnen das neueste Update von iQUAVIS vorstellen zu dürfen! Das Werkzeug iQUAVIS hilft Ihnen, komplexe Entwicklungsprojekte mit Hilfe von Systems Engineering zu meistern. Mit seinen Komponenten Systemarchitektur und Projektmanagement verschafft Ihnen iQUAVIS den entscheidenden Wettbewerbsvorteil. In der neuen Version gibt es ein paar sehr schöne Neuerungen, die Ihnen die Arbeit noch mehr erleichtern. Ein paar davon stellen wir Ihnen in diesem Beitrag vor. Datenaustauschformate Mit der Version 4.0 wurden die Möglichkeiten zur Werkzeugkopplung gestärkt. Das geht nun sowohl über unsere REST API als auch über das Konzept der OSLC (Open Services for Lifecycle Collaboration). OSLC (Open Services for Lifecycle Collaboration) Es erfordert großen Aufwand, Daten, die redundant in mehren Dateien projektübergreifend verwendet werden, durch Kopieren und Einfügen zu synchronisieren. Ein solcher manueller Schritt kann leicht Fehler zur Folge haben und Daten verfälschen. Aus diesen Grund hat sich das modellbasierte Systems Engineering entwickelt, kurz MBSE. iQUAVIS hat auf Basis des OSLC Konzeptes nun die Möglichkeiten geschaffen, sich mit anderen Werkzeugen automatisch zu verbinden. REST API Die REST API wurde gestärkt. Neben generellen Verbesserungen ist auch die Anbindung von Werkzeugen des Requirement Managements im Fokus gewesen, s.d. nun beispielsweise die Round Trip-Fähigkeit über ReqIF Datenaustausch stark profitiert: Der Anwender kann vorhandene Daten aktualisieren oder löschen, wenn er Daten zwischen DOORS und iQUAVIS importiert oder exportiert. Bei diesem Vorgang können Benutzer wahlweise den Befehl „gekennzeichnete DOORS Daten löschen“ ausführen oder weglassen. Transparenz bei der Zusammenarbeit Wenn Sie im Team an einem gemeinsamen Datensatz arbeiten, ist es wichtig zu erfahren, was in Ihrer Abwesenheit passiert ist. Veränderte Daten können von iQUAVIS im Worksheet nun automatisch farblich hervorgehoben und mit Zeitstempel gekennzeichnet werden. So ersparen Sie sich zeitaufwändige Kontrollen. Außerdem besteht die Möglichkeit, alle Änderungen ab einem beliebigen Datum anzeigen zu lassen. Dazu müssen keine zusätzlichen Verlaufsdaten gespeichert werden. Neue Abhängigkeitstypen und Visualisierung Ein neuer Abhängigkeitstyp „Abhängigkeit (Beziehung)“ ergänzt die bestehende „Abhängigkeit (Hierarchie)“. Durch zwei unterschiedliche Arten von Abhängigkeiten erweitern sich Ihre Möglichkeiten zur Modellierung und Analyse von Modellen (z. B. Kostenanalyse, Marktauswirkungen, etc.). Die Abhängigkeitstypen können als Bedingungen zum Extrahieren von Informationen genutzt werden, z. B. in Filtern und Arbeitsblättern. Die Funktion „Baum erweitern“ ermöglicht das Verfolgen der „Abhängigkeit (Beziehung)“. Funktionslinien aus den Blockdefinitionsdiagrammen können nun zusätzlich auch im Baum angezeigt werden. Die Darstellung der Abhängigkeitsbeziehungen kann im Menü aktiviert werden. Veränderte Daten im Arbeitsblatt markieren In diesem kurzen Video geben wir einen Einblick in iQUAVIS und wie Sie veränderte Daten im Arbeitsblatt markieren können: Christian Dr. BremerDr. Christian Bremer ist Gründer und Geschäftsführer bei Two Pillars. Er verantwortet die Bereiche Entwicklung und IT und ist zuständig für iQUAVIS. Seit seiner Zeit beim Fraunhofer IEM beschäftigt sich Christian Bremer mit Model-Based Systems Engineering. Er berät und begleitet Unternehmen bei der Einführung. Dabei werden immer wieder auch neue Use-Cases und Feature in iQUAVIS implementiert. www.two-pillars.de/

iQUAVIS 4.0 – unser MBSE Software-Update Weiterlesen »

NEU: Wrike-Schnittstelle in iQUAVIS

iQUAVIS, Updates / Christian Dr. Bremer

Um dem rasanten, technologischen Fortschritt in der Produktentwicklung mechatronischer Systeme Rechnung zu tragen, haben wir in iQUAVIS eine Wrike-Schnittstelle eingerichtet. Wrike ist ein Online-Tool für Projektmanagement und Zusammenarbeit. Die neue Schnittstelle ermöglicht das nahtlose Arbeiten in iQUAVIS und Wrike. Wrike Projektmanagement und iQUAVIS Die Nachfrage nach flexiblen und individualisierten Produkten steigt. Die Folge: Die einzelnen Projekte werden immer komplexer. Gleichzeitig sind sie oft stark untereinander vernetzt. Damit diese Projekte erfolgreich abgeschlossen werden können, muss Transparenz über das technische System herrschen und sich auch zugunsten der Mitarbeiter in einer klaren Organisation ihrer Aufgaben widerspiegeln. Damit wird die flexible und effektive Zusammenarbeit vom Vertrieb über die Entwicklungsabteilung bis hin zum Service zur wichtigen Managementaufgabe. Eine besondere Herausforderung ist dabei die integrative Betrachtung von Technologie und Projekt. Vor diesem Hintergrund hat ISID eine Schnittstelle zu Wrike entwickelt: Dadurch gelingt nicht nur die Integration von Produktspezifikation und Projektmanagement, wie von iQUAVIS bislang ausgelegt, sondern auch der Schulterschluss mit der feingliedrigen Arbeitsorganisation der individuellen Projektressourcen. Dabei stechen für den Mitarbeiter bspw. die Aufgabenverwaltung und Time-Tracker hervor, genauso wie z.B. die Möglichkeit für Diskussionen per Chat und eine Dokument-Kollaboration. Während mit iQUAVIS also das Produkt spezifiziert und das Gesamtprojekt geplant und gesteuert wird, unterstützt Wrike auf individueller, operativer Arbeitsebene. Diese Kombination bietet sich gerade für Unternehmen an, die nicht auf komplexe IT-Landschaften setzen, sondern die methodische Zusammenarbeit ihrer Mitarbeiter stärken wollen. Vorteile der Kombination aus iQUAVIS und Wrike für Ingenieure Die Kombination von iQUAVIS und wrike bietet einige Vorteile, die wir im Folgenden vorstellen. Vollständige Nachverfolgbarkeit von Aufgaben und Projektergebnissen iQUAVIS gleicht Zeitpläne und Ressourcen ab und erstellt den optimalen Entwicklungsplan. Mit der Schnittstelle „iQUAVIS-Wrike“ wird diese Information in die tägliche, persönliche Arbeit integriert. Sämtliche Fortschritte werden anschließend von iQUAVIS wiederverwendet. Die nahtlose Verbindung zwischen dem Gesamtplan und der persönlichen Arbeit ermöglicht ein flexibles und effizientes Projektmanagement. Die beiden Programme ergänzen sich gegenseitig. Fließende Team-Zusammenarbeit und mobile Working Mit einer intuitiven Benutzeroberfläche und einem gerätekompatiblen Cloud-Service ist es möglich, unabhängig von Standort und Nutzungsumgebung, praktisch und leicht mit Personen in verschiedenen Abteilungen zu kommunizieren, ohne Informationen zu verlieren. Neben der Verbesserung der betrieblichen Effizienz in den Design- und Entwicklungsabteilungen werden damit Arbeitsweisen wie z.B. Mobile Working gefördert. Ausblick Während iQUAVIS bislang maßgeblich bei vielen japanischen Unternehmen eingesetzt wird, ist Wrike™ eine globale Kollaborationsplattform, die von mehr als 20.000 Unternehmen weltweit eingesetzt wird. iQUAVIS-Wrike als eine Projektmanagement-Lösung für die Fertigungsindustrie wird bereits von etwa 100 großen Fertigungsunternehmen zur Visualisierung von groß angelegten und komplexen Produktentwicklungsprozessen eingesetzt. ISID wird seine Softwarelösungen für die Produktentwicklung, einschließlich iQUAVIS, weiter stärken und ausbauen, um die Unternehmensinnovation in der Fertigungsindustrie zu unterstützen. Wir von Two Pillars entwickeln auch selbst Schnittstellen für iQUAVIS in Kooperation mit unseren Kunden. Christian Dr. BremerDr. Christian Bremer ist Gründer und Geschäftsführer bei Two Pillars. Er verantwortet die Bereiche Entwicklung und IT und ist zuständig für iQUAVIS. Seit seiner Zeit beim Fraunhofer IEM beschäftigt sich Christian Bremer mit Model-Based Systems Engineering. Er berät und begleitet Unternehmen bei der Einführung. Dabei werden immer wieder auch neue Use-Cases und Feature in iQUAVIS implementiert. www.two-pillars.de/

NEU: Wrike-Schnittstelle in iQUAVIS Weiterlesen »

Autorenname: Christian Dr. Bremer