DE10150388A1 - Kollaborationssitzungs-Aufnahmemodell - Google Patents

Abstract

Es wird ein Objektmodell zum Nachvollziehen von Entscheidungen und eine Schnittstelle beschrieben, die administrative und wesentliche Tagungsinformationen erfaßt und zusammen mit deren verbundenen Beziehungen in einer Objektmodelldatenbank speichert. Jedes Objektmodell enthält Informationen und Beziehungen, auf die über eine öffentlich definierte Schnittstelle zugegriffen werden kann.

Description

Die vorliegende Erfindung betrifft allgemein die Informati­ onsverwaltung und im Besonderen ein System und ein Verfah­ ren zum Erfassen, Speichern und Nachvollziehen von tagungs­ bezogenen Informationen einer Online-Gemeinschafts­ arbeitssitzung bzw. einer Kollaborationssitzung.

Die Produktentwicklung wird durch computerbasierte Anwen­ dungen unterstützt, unter anderem durch Textverarbeitungs­ werkzeuge und grafische Werkzeuge, Verwaltungswerkzeuge und Dispositionswerkzeuge sowie durch Produktdatenverwaltungs­ werkzeuge. Der typische Produktentwicklungszyklus beginnt mit einer Idee für ein Produkt oder einer Verbesserung für ein Produkt, das sich an einen Bedarf in der Industrie richtet oder eine Lösung für ein Problem bietet. Von der Produktidee können alternative Entwürfe untersucht werden. Schließlich wird ein Entwurf bzw. eine Gestaltung gewählt, entworfen und implementiert. Während der anfänglichen Pha­ sen des Produktentwicklungszyklusses werden oft Textverar­ beitungs-, grafische, Verwaltungswerkzeuge und Ablaufsteue­ rungsprogramme benutzt, um Informationen, wie Marketingana­ lysen, projektierte Entwicklungspläne und Beschreibungen und Begründungen hinter konkreten Entwurfsentscheidungen zu erfassen. Während der Entwicklungs- bzw. Entwurfsphase wer­ den entwicklungs- bzw. entwurfsbezogene Informationen, wie Entwurfsspezifikationen und dreidimensionale Modelldaten, typischer Weise durch Verwendung eines CAD-Werkzeugs er­ faßt. Während der Herstellung des Produkts werden Informa­ tionen bezogen auf das Nachvollziehen von Teilen typischer­ weise durch Verwendung eines PDM-Werkzeugs (PDM: product data management, Produktdatenverwaltung) erfaßt. Während jeder Phase des Produktentwicklungszyklusses tauchen Pro­ bleme auf und werden Entscheidungen gefällt.

Kollaborationswerkzeuge wurden entwickelt, um den Produkt­ entwicklungsprozeß zu unterstützen und eine bessere Kommu­ nikation zu fördern, indem diese es Personen ermöglichen, Tagungen oder Besprechungen online, d. h. über ein Daten­ netz verbunden, von entfernten Orten aus durchzuführen. Diese Kollaborationswerkzeuge bieten einige Mittel, die er­ möglichen, daß gleichzeitig auf dieselben Daten geschaut wird, und mindestens ein Kommunikationsverfahren (bei­ spielsweise grafische Zeiger, grafische Markierungen, hör­ bare Kommunikation, wie bspw. ein Internettelefon, und textbasierte Konferenzprogramme).

Während offensichtlich ist, daß verschiedene computerba­ sierte Werkzeuge bei der Erfassung von Informationen und dem Nachvollziehen des Fortgangs des Produkts unterstützen sowie die Kommunikation zwischen Kollegen, Gruppen und En­ titäten unterstützen, könnte der gegenwärtige Stand der Technik verbessert werden. Zunächst existiert gegenwärtig kein Gemeinschaftsarbeitswerkzeug zum speziellen Erfassen und Nachvollziehen von Ideefragen, Antworten und Entschei­ dungen, die mit allen Phasen des Produktentwicklungszyklus­ ses verbunden sind. Das Erforschen und Untersuchen von Ide­ en ist oftmals eine Situation, bei der viele Fragen und Probleme präsentiert und sich ergebende Antworten oder Lö­ sungen präsentiert werden und die oft letztendlich zu Ent­ scheidungen führt. Um erfolgreich solche Untersuchungen nachzuvollziehen, ist es notwendig, viele lediglich teil­ weise vollständige Informationsstrukturen zu erfassen, mit aufgeworfenen Fragen, Vorschlägen für Lösungen, Antworten auf die Fragen, gefällte Entscheidungen; darunter fallen die Entscheidungen einen Untersuchungspfad fortzusetzen oder zu verwerfen, und die Gründe hinter diesen Entschei­ dungen. Im Stand der Technik existiert kein einziges Werk­ zeug zum Erfassen und Nachvollziehen solcher Informationen. Weiterhin ist kein Kollaborationswerkzeug speziell darauf abgestimmt, Produktentwurfsinformationen zu erfassen. Schließlich ist, selbst wenn einige der Informationen durch Verwendung eines oder mehrerer unterschiedlicher Werkzeuge erfaßt werden, da die Informationen nicht in einer Anwen­ dung integriert sind oder leicht zugänglich sind, außer un­ ter Verwendung des konkreten Werkzeugs, das die Informatio­ nen erfaßt hat, viele der Informationen betreffend die Ent­ wurfsauswahlen und Entscheidungsgründe, sowie die Probleme und Vorschläge, die während der Entwicklung des Produkts untersucht wurden, typischerweise nicht effektiv erfaßt und können, wenn der Entwicklungszyklus des Produkts voran­ schreitet, sogar verloren gehen.

Es gibt viele Gründe, weshalb es vorteilhaft wäre, die Mög­ lichkeit zu haben, unter Verwendung verschiedener Werkzeuge auf Daten zuzugreifen, die durch ein einziges Werkzeug er­ zeugt werden. Insbesondere die Informationen, die unter Verwendung eines Werkzeugs erfaßt werden, können nützlich für verschiedene Personen von verschiedenen Entitäten, die verschiedene Rollen ausüben, sein. Beispielsweise können bestimmte Informationen, die während des Entwurfs bzw. der Entwicklung des Produkts erfaßt wurden, nicht nur nützlich für die Entwurfsingenieure sein, sondern auch für Produkti­ ons- und Testingenieure, Manager des Produkterzeugungspro­ zesses, Servicetechniker, Marketing- und Verkaufspersonal, auftragsbearbeitendes Personal, Web-Seiten-Designer und Verwaltungspersonal, Kunden und. Lieferanten, um einige zu nennen.

Folglich existiert ein Bedarf an einer Art, Produktent­ wurfsproblemstellungen und Entscheidungsinformationen zu erfassen, zu speichern und nachzuvollziehen. Darunter fal­ len gestellte Fragen und Antworten, auf denen Entscheidun­ gen basieren oder nicht basieren, und die Gründe hinter den Entscheidungen. Es besteht außerdem ein Bedarf an der Fä­ higkeit, solche Informationen von innerhalb einer Kollabo­ rationssitzung zu erfassen, um die Entwicklung in Echtzeit von Ideen, Problemen und Lösungen durch viele entfernte Sitzungsteilnehmer zu ermöglichen. Zusätzlich besteht ein Bedarf am Erfassen dieser Informationen in einer werkzeug­ neutralen bzw. werkzeugunabhängigen Form, die jedem Werk­ zeug einen Zugriff auf die erfaßten Informationen ermög­ licht und gestattet, diese zu modifizieren, wo dies geeig­ net ist.

Die vorliegende Erfindung betrifft ein System und ein Ver­ fahren zum Erfassen, Speichern und Nachvollziehen von Pro­ duktentwurfsinformationen, die während einer Online-Tagung entwickelt wurden, und zwar in einer werkzeugneutralen dau­ erhaften Form. Die Erfindung erfaßt auch die Informationen und vollzieht diese, die auf die Details einer Tagung bezo­ gen sind, wie Büroinformationen, Zeit, Ort, Teilnehmer, Agenda bzw. Tagungsplan und Zeitplan.

Die vorliegende Erfindung umfaßt vorzugsweise ein Kollabo­ rationsobjektmodell, das Informationen erfaßt, die eine On­ line-Tagung betreffen, mit getrennten bzw. separaten Ta­ gungsplanobjekten, Tagungsagendaobjekten, Tagungszielset­ zungsobjekten, Tagungsprogrammobjekten, Tagungsdiskussi­ onsobjekten, Konversationsobjekten, Aktorobjekten, Aufga­ benobjekten und Verpflichtungsobjekten. Die Beziehung zwi­ schen den verschiedenen Objekten werden ebenfalls erfaßt.

Das Kollaborationsmodell koppelt vorzugsweise an ein Inno­ vationsinformations-Verwaltungsobjektmodell, um entwurf­ sentwicklungsspezifische Informationen und Entscheidungs­ nachvollziehungsobjektmodelle zu erfassen, um entschei­ dungsrelevante Informationen zu erfassen.

Die Erfindung erleichtert auch anspruchsvolle bzw. hochwer­ tige Anfragen an die Objektmodelle, um interessierende In­ formationen von der Gesamtheit der gespeicherten Informa­ tionen herauszuziehen. Die Erfindung ist aus vielen Gründen vorteilhaft. Darunter fällt bspw. die Fähigkeit vieler Per­ sonen mit unterschiedlichen Rollen, auf Informationen zuzu­ greifen und diese herauszuziehen, und zwar auf Weisen, die Bedeutung für deren Rolle haben.

Weitere Vorteile und Ausgestaltungen der Erfindung ergeben sich aus der Beschreibung und der beiliegenden Zeichnung.

Es versteht sich, daß die vorstehend genannten und die nachstehend noch zu erläuternden Merkmale nicht nur in der jeweils angegebenen Kombination, sondern auch in anderen Kombinationen oder in Alleinstellung verwendbar sind, ohne den Rahmen der vorliegenden Erfindung zu verlassen.

Die Erfindung ist anhand von Ausführungsbeispielen in der Zeichnung dargestellt und wird im folgenden unter Bezugnah­ me auf die Zeichnung näher erläutert. Dabei wird die Erfin­ dung durch Lesen der folgenden ausführlichen Beschreibung in Verbindung mit den Zeichnungen besser verstanden werden, in denen gleiche Referenzzeichen verwendet werden, um glei­ che Elemente zu bezeichnen.

Fig. 1 zeigt ein konzeptionelles Objektmodelldiagramm, das die Trennung von Informationseinheiten und deren zugehörige Beziehungen zu anderen Informa­ tionseinheiten veranschaulicht.

Fig. 2 zeigt ein Blockdiagramm eines Kollaborationsob­ jektmodells, das erfindungsgemäß implementiert ist.

Fig. 3 zeigt ein UML-Schnittstellendiagramm (UML: uni­ fied method language, vereinheitlichte Verfah­ renssprache), das eine bevorzugte Ausführungsform der Kollaborationsobjektmodell-Schnittstelle für das Kollaborationsobjektmodell aus Fig. 2 ver­ deutlicht.

Fig. 4 zeigt ein UML-Schnittstellendiagramm, das eine bevorzugte Ausführungsform der Inovationsinforma­ tionsverwaltungsobjektmodell-Schnittstelle veran­ schaulicht.

Fig. 5 zeigt ein UML-Schnittstellendiagramm, das eine bevorzugte Ausführungsform der Entscheidungsnach­ vollziehungsobjektmodell-Schnittstelle veran­ schaulicht.

Fig. 6 zeigt ein Blockdiagramm der dauerhaften Spei­ cherentitäten, die durch das Entscheidungsnach­ vollziehungsobjektmodell aus Fig. 2 erzeugt und erhalten werden, indem die in Fig. 3 beschriebe­ nen Schnittstellen verwendet werden.

Fig. 1 zeigt ein konzeptionelles Blockdiagramm, das die Trennung der Informationseinheiten und deren zugehörige Be­ ziehungen zu anderen Informationseinheiten veranschaulicht, wobei diese die Zugänglichkeit auf die Informationen durch unterschiedliche Werkzeuge verdeutlicht. Insbesondere eine Auswahl an Objektmodellen 10a, 10b, 10c, 10d, 10e, 10f, die Informationen und Objektbeziehungen beschreiben, die durch eine Vielzahl von unterschiedlichen Werkzeugen 20a, 20b, 20c, 20d, . . ., 20n während der Entwicklung eines Produkts erzeugt wurden, sind in einer werkzeugneutralen Form in ei­ nem dauerhaften Speicher 30 abgelegt. Wichtig ist, daß die Objektmodelle 10a, 10b, 10c, 10d, 10e, 10f nicht irgendei­ nem Werkzeug gehören, darunter die Werkzeuge 20a, 20b, 20c, 20d, . . ., 20n, die diese erzeugt haben. Jedes Objektmodell 10a, 10b, 10c, 10d, 10e, 10f enthält Objekte, die äußerst abhängige Objektbeziehungen haben.

Von den Objektmodellen 10a, 10b, 10c, 10d, 10e, 10f hat je­ des eine definierte öffentliche Schnittstelle, die jedem Werkzeug 20a, 20b, 20c, 20d, . . ., 20n, das die Schnittstel­ lendefinition versteht, erlaubt, legale bzw. erlaubte Daten zu lesen und zu dem entsprechenden Objektsatz zu schreiben. Obwohl es sein kann, daß lediglich ein Anwendungswerkzeug ein einzelnes Attribut vollständig versteht (bspw. ein CAD- Werkzeug, das eine dreidimensionale Geometrie und Topologie versteht), erlaubt die öffentliche Schnittstellendefinition virtuell jedem Werkzeug, Zugriff auf die Teile des Objekts zu haben, die dieses versteht, mit dessen Beziehungen zu anderen Objekten. Zum Beispiel das CAD-Werkzeug 20a (bspw. SolidDesigner) erzeugt Daten, die teilweise in dem CAD- Modell-Objektmodell 10a und teilweise in dem Produktstruk­ turobjektmodell 10b gespeichert werden. Es ist wichtig zu erkennen, daß das CAD-Werkzeug 20a nicht seine interne Da­ tenstruktur oder seine Benutzerschnittstelle ändern muß. Vielmehr braucht das CAD-Werkzeug 20a lediglich die Fähig­ keit, nur die Objekte und Strukturen zu verstehen, die die­ ses liest und beschreibt (dies kann durch Verwendung einer Erweiterungen, die Import/Exportfähigkeiten erlaubt, er­ reicht werden; Techniken von diesen sind wohlbekannt im Stand der Technik). Bei diesem Beispiel greift ein Kollabo­ rationswerkzeug 20d (beispielsweise das Produkt OneSpace der Firma CoCreate Software Inc.) auf das Kollaborationsob­ jektmodell 10f, auf das CAD-Datenobjektmodell 10a und das Entwurfsalternativmodell 10c zu. Folglich muß das PDM- Werkzeug 20b die Fähigkeiten haben, Änderungen, die an dem Produktstrukturmodell 10b durch das CAD-Werkzeug 20a durch­ geführt wurden, zu bearbeiten und ebenso muß das CAD- Werkzeug 20a die Fähigkeiten haben, Änderungen, die durch das PDM-Werkzeug 20b an dem Produktstrukturmodell 10b durchgeführt wurden, zu bearbeiten. Das gemeinsame Objekt­ modell (das heißt das Produktstrukturmodell 10b), das diese verstehen, verbessert die Zusammenarbeit zwischen dem CAD- Werkzeug 20a und dem PDM-Werkzeug 20b.

Es ist ebenfalls wichtig zu bemerken, daß andere Werkzeuge (bspw. 20n) auch auf die Objektmodelle 10a, 10b, 10c, 10d, 10e, 10f zu jeder Zeit zugreifen können und die Auswahl an Objektmodellen 10a, 10b, 10c, 10d, 10e, 10f jeder Zeit er­ weitert werden kann. Folglich erweitert sich die Auswahl an Informationen und Beziehungen mit den anderen Objekten und entwickelt sich über den Verlauf des Produktzyklusses, in­ dem diese die "wie entworfenen" Aspekte des Produkts er­ faßt. Zusätzlich erlaubt die werkzeugneutrale dauerhafte Form der Objektmodelle beides, nämlich synchrone und asyn­ chrone Zusammenarbeit der Produktentwicklung, indem diese vielen unterschiedlichen Personen (bspw. Ingenieuren, Mana­ gement, Verwaltungspersonal und selbst Kunden) mit geeigne­ ten Genehmigungen erlaubt, auf die in den Objektmodellen enthaltenen Daten zuzugreifen, die den gegenwärtigen Zu­ stand des Produkts repräsentieren.

Unter den Objektmodellen in der Objektmodelldatenbank 30 ist ein Kollaborationssitzungsobjektmodell 10f, das die zu einer Kollaborationstagungssitzung zugehörigen Informatio­ nen enthält, mit dem Tagungsplan, der Tagungsagenda, der Tagungszielsetzung, dem Tagungszeitplan, den Tagungsteil­ nehmern, der Konversation der Tagungsteilnehmer sowie Auf­ gaben und Verpflichtungen. Das Kollaborationssitzungsob­ jektmodell 10f erfaßt auch die Beziehungen zwischen jedem der unterschiedlichen Typen der vorstehend genannten Infor­ mationen.

Objekte in dem Kollaborationssitzungsobjektmodell 10f kön­ nen automatisch durch eines oder mehrere Werkzeuge 20a, 20b, 20c, 20d, . . ., 20n erzeugt werden oder können speziell durch Nutzer über spezielle Tagungserfassungsdialogfelder erzeugt werden, auf die über die Nutzerschnittstelle der Werkzeuge zugegriffen wird. Bei einer Ausführungsformen er­ faßt ein Kollaborationswerkzeug 20d die Kollaborationssit­ zungstagungsdaten. Wie jedoch vorstehend bemerkt, besitzt kein Werkzeug die Daten in irgendeinem Objektmodell 10a, 10b, 10c, bd, 10e, 10f und jedes Werkzeug kann auf jedes der Objekte über die öffentlich definierte Schnittstelle, die anschließend beschrieben wird, zugreifen.

Fig. 2 zeigt ein Blockdiagramm, das eine bevorzugte Aus­ führungsform 100 des Kollaborationssitzungsobjektmodells 10f aus Fig. 1 veranschaulicht, das ein Objektmodell, zum Erfassen und Speichern von Informationen in einer werkzeug­ neutralen dauerhaften Form bietet, die eine Online-Tagung betreffen.

Wie in Fig. 2 gezeigt, enthalten die Hauptinformationsein­ heiten in dem Kollaborationssitzungsobjektmodell 100 fol­ gende Objekte: Tagungsplan-Objekt 110, Tagungsagenda-Objekt 120, Tagungszielsetzungs-Objekt 130, Tagungszeitplan-Objekt 140, Tagungsdiskussions-Objekt 150, Konversationsobjekt 160, Aktorobjekt 170, Aufgabe-Objekt 180 und Verpflichungs­ objekt 190. Diese Objekte zusammen mit einer öffentliche definierten Schnittstelle zum Erzeugen und Zugreifen auf diese, modellieren die Umgebung, die notwendig ist, um eine synchrone Kollaborationssitzung einzurichten, diese durch­ zuführen und sich mit dieser zu befassen.

Ein Tagungsplan-Objekt 110 umfaßt den Bedarf, eine Tagung durchzuführen. Die Tagung kann physisch, d. h. mit unmit­ telbarem Kontakt der Teilnehmer, oder online sein. Ein Ta­ gungsagendaobjekt 120 umfaßt einen Agendaplan der Tagung. Ein Tagungszielsetzungsobjekt 130 umfaßt die Zielsetzungen der Tagung. Ein Tagungszeitplanobjekt 140 umfaßt einen Zeitplan für die Tagung. Ein Tagungsdiskussionsobjekt 150 umfaßt ein Beispiel für eine Tagungssitzung. Die Tagung kann sich über mehrere Sitzungen erstrecken.

Ein Konversationsobjekt 160 umfaßt den Austausch zwischen Tagungsteilnehmern während einer Tagung.

Ein Aktorobjekt 170 repräsentiert eine bei der Tagung teil­ nehmende Person. Ein Aufgabe-Objekt 180 umfaßt eine einzel­ ne Anfrage oder eine Arbeitseinheit, die zu tun ist. Ein Verpflichtungsobjekt 190 umfaßt eine Verpflichtung für ei­ nen Aktor, der etwas zu tun hat. Verschiedene Aufgabe- Objekte 180 können mit einem Verpflichtungsobjekt 190 ver­ bunden sein.

Innerhalb des Kollaborationssitzungsobjektmodells 100 be­ stehen Beziehungen zwischen den unterschiedlichen Objekten, wie dies durch die Verbindungslinien zwischen den Objekten verdeutlicht ist. Beispielsweise kann jedes Tagungsplan- Objekt 110 Verbindungen mit verschiedenen Tagungsdiskussi­ onsobjekten 150 haben (was bspw. der Fall wäre, wenn die Kollaborationssitzung über verschiedene unterschiedliche Zeitabschnitte durchgeführt wird). Jedes Tagungsdiskussi­ onsobjekt kann viele Konversationsobjekte 160 haben, die die Konversation erfassen, die während der konkreten Ta­ gungsabschnitte stattgefunden haben, die durch deren ver­ bundene Tagungsdiskussion repräsentiert sind. Ein einzelnes Tagungsplan-Objekt kann Verbindungen mit mehreren Tagungs­ zielsetzungsobjekten haben, von denen jedes eine unter­ schiedliche Zielsetzung repräsentiert.

Fig. 3 zeigt ein UML-Schnittstellendiagramm, das eine be­ vorzugte Ausführungsform der Kollaborationssitzungsobjekt­ modell-Schnittstelle für das Kollaborationssitzungsobjekt­ modell 100 aus Fig. 2 veranschaulicht. Wie in Fig. 3 ge­ zeigt ist, enthält die für das Kollaborationssitzungsob­ jektmodell 200 aus Fig. 2 definierte öffentliche Schnitt­ stellen: Tagungsplan 210 (MeetingPlan), Tagungsagenda 220 (MeetingAgenda), Tagungszielsetzung 230 (MeetingObjective), Tagungszeitplan 240 (MeetingSchedule), Tagungsdiskussion 250 (MeetingDiscussion), Konversation 260 (Conversation), Aktor 270 (Actor), Aufgabe 280 (ActionItem) und Verpflich­ tung 290 (Commitment). Die Kollaborationssitzungsschnitt­ stellendefinition modelliert die Umgebung, die notwendig ist, um eine synchrone Kollaborationssitzung einzurichten, durchzuführen und sich mit dieser zu befassen.

Wenn eine Tagung zunächst geplant wird, wird der Bedarf, eine Tagung durchzuführen, über die Tagungsplan- 210 Schnittstelle erfaßt und in einem Tagungsplan-Objekt 110 (Fig. 2) umfaßt. Verwaltungsinformationen betreffend die Tagung, wie beispielsweise Zeit (oder Zeitplan), Ort, Zweck (oder Zielsetzung), Agenda und Teilnehmer können über die jeweiligen Schnittstellen eingerichtet werden, zusammen mit Tagungszeitplan 240, Tagungsort 225 (Meeting Location), Ta­ gungszielsetzung 230, Tagungsagenda 220 und Aktor 270. Ty­ pischerweise wird die Tagung zu einer bestimmten Zeit durch Verwendung der Tagungsplanschnittstelle 210 eingerichtet, die jeden Aktor über die Tagung und relevante Informationen unterrichtet, die mit dem Tagungsplan verbunden sind. Die gegenwärtige Tagungsdiskussion wird zu einer anderen einge­ planten Zeit stattfinden. Das Kollaborationssitzungsobjekt­ modell erfaßt die anfänglichen Einrichtungsinformationen in getrennten Informationsobjekten (bspw. Tagungsplanobjekt IIO, Tagungsagenda 120, Tagungszielsetzung 130 und Tagungs­ zeitplan 140) über die geeigneten Schnittstellen aus Fig. 3, die dann in einem dauerhaften Speicher in einer werk­ zeugneutralen Form gespeichert werden und später mit den Tagungsdiskussionsobjekten 150 verbunden werden, die Pro­ duktentwurfsentwicklungsobjekte umfassen.

Eine Tagungsdiskussionsschnittstelle 250 (Meeting Discussi­ on interface) bietet insbesondere eine Schnittstelle zum Erfassen von Produktanforderungen, Entwurfsrepräsentatio­ nen, Produktideen, Entwurfsalternativen, Entwurfsbedingun­ gen, Entwurfsnotizen, Entwurfsabsichten und Fragen, Ent­ scheidungen und Antworten betreffend jedes präsentierte Entwurfsproblem. Die Verfahren, durch die die Produktent­ wicklungsinformationen erfaßt werden, verfügen über die je­ weiligen Schnittstellen, nämlich Produktanforderung 270 (ProductRequirement), Entwurfsrepräsentation 271 (Design Re­ presentation), Produktidee 272 (ProductIdea), Entwurfsal­ ternative 273 (Design Alternative), Entwurfsbedingung 274 (DesignConstraint), Entwurfsnotiz 275 (Decision), Entwurfs­ absicht 276 (DesignIntent), Frage 277 (Question), Entschei­ dung 278 (Decision) und Antwort 279 (Answer). Diese Schnittstellen sind das Portal in das Innovationsinformati­ onsmanagement-(IIM)-Objektmodell 10e (Fig. 1), das die während der Untersuchung der Lösungen zu einer Produktidee entwickelten Informationen modelliert, und in das Entschei­ dungsnachvollziehungsobjektmodell 10d (Fig. 1), das die in dem Prozeß des Treffens von Entwurfsentscheidungen gemach­ ten Informationen modelliert.

Fig. 4 zeigt ein UML-Diagramm des IIM-Objektmodells 10e, das in der veranschaulichenden Ausführungsform der Erfin­ dung verwendet wird, die ausführlicher in der ebenfalls an­ hängigen Anmeldung desselben Erfinders mit dem Titel "Inno­ vation Information Management Model" (Innovationsinformati­ onsverwaltungsmodell) beschrieben ist und ist in dieser Schrift mit allen was diese lehrt enthalten. Insbesondere jeweilige Schnittstelle, nämlich Produktanforderung 270 (ProductRequirement), Entwurfsrepräsentation 271 (Design Re­ presentation), Produktidee 272 (ProductIdea), Entwurfsal­ ternative 273 (Design Alternative), Entwurfsbedingung 274 (DesignConstraint), Entwurfsnotiz 275 (DesignNote), Ent­ wurfsabsicht 276 (DesignIntent) enthalten Entwurfsinforma­ tionen in getrennten Objekten, mit Produktideeobjekten, Entwurfsalternativobjekten, Entwurfsbedingungsobjekten, Entwurfsnotizobjekten und Entwurfsabsichtsobjekten.

In Übereinstimmung mit dem IIM-Objekt-Modell 10e umfaßt ein Produktideeobjekt eine Idee zu einem Produkt. Ein Produkti­ deeobjekt kann eine Idee für ein neues Produkt sein, eine Verbesserung oder Erweiterung zu einem existierenden Pro­ dukt, oder die Lösung für ein bekanntes Problem, wie bei­ spielsweise einen Technikwechsel, für ein existierendes Produkt. Ein Produktanforderungsobjekt umfaßt eine Anforde­ rung, die das Produkt erfüllen muß, erfüllen soll oder er­ füllen könnte. Für ein gegebenes Produkt werden typischer­ weise viele Anforderungen von vielen unterschiedlichen Quellen vorliegen, wie beispielsweise Marketing, Kunden, Technik und Produktion.

Ein Entwurfsalternativobjekt umfaßt Informationen, die eine mögliche Lösung oder einen Entwurf für eine Idee umfassen, die in einem Produktideeobjekt eingekapselt sind. Ein Ent­ wurfsrepräsentationsobjekt umfaßt einen Weg der Modellie­ rung der vorgeschlagenen Lösung oder des Entwurfs, der in einem Entwurfsalternativobjekt repräsentiert ist. Ein Ent­ wurfsabsichtsobjekt umfaßt eine spezielle Absicht oder Zielsetzung des Entwurfs bzw. der Entwicklung. Ein Ent­ wurfsnotizobjekt umfaßt eine Notiz betreffend den Entwurf. Ein Entwurfsproblemobjekt ist mit einer Entwurfsrepräsenta­ tion verbunden. Das in einem Entwurfsproblemobjekt umfaßte Problem repräsentiert eine interessierende oder offene Fra­ ge, die nach Betrachten dieser Repräsentation der Ent­ wurfsalternative aufgetreten ist. Ein Entwurfsbedingungsob­ jekt umfaßt eine Bedingung bzw. eine Beschränkung, über die die Organisation eine gewisse Kontrolle hat, die die Ent­ wurfsalternative erfüllen muß.

Fig. 5 zeigt ein UML-Diagramm des Entscheidungsnachvoll­ ziehungsobjektmodells 10d (Fig. 1), das in der vorliegen­ den Erfindung verwendet wird und das die in dem Prozeß der Entwurfsentscheidungsfindung verwendeten Informationen mo­ delliert und ausführlicher in der anhängigen Anmeldung mit dem Titel "Object Model For Decision And Issue Trak­ king" (Objekt-Model zum Nachvollziehen von Entscheidungen und Problemen) desselben Erfinders beschrieben ist und mit allem was darin gelehrt wird hierin enthalten ist. Insbe­ sondere jeweilige Schnittstellen, nämlich Frage 277 (Que­ stion), Entscheidung 278 (Decision) und Antwort 279 (Ans­ wer) umfassen Entwurfsinformationen in getrennten Objekten, mit Frageobjekten, Entscheidungsobjekten und Antwortobjek­ ten.

In Übereinstimmung mit dem Entscheidungsnachvollziehungsob­ jektmodell 10d umfaßt ein Entscheidungsobjekt eine Ent­ wurfsentscheidung über einen Aspekt eines Produkts. Unter­ schiedliche Typen von Entscheidungen können definiert sein, die spezifisch für einen bestimmten Entwurfsaspekt sind. Ein Frageobjekt umfaßt eine Frage, die relevant oder nicht relevant für die Bildung einer Entwurfsentscheidung sein kann, die durch ein Entscheidungsobjekt umfaßt ist. Ein Antwortobjekt umfaßt eine Antwort auf eine Frage, die in einem Frageobjekt umfaßt ist.

Die Schnittstelle zu dem IIM-Objektmodell 10e und Entschei­ dungsnachvollziehungsobjektmodell 10d von dem Kollaborati­ onssitzungsobjektmodell 10f ermöglicht, daß alle Entwurfs­ entwicklungsinformationen, die während einer Online-Tagung diskutiert werden, erfaßt werden, modifiziert werden und daß auf diese von allen Teilnehmern in der Tagung zugegrif­ fen werden kann. Weiterhin erlaubt dies, daß alle Tagungs­ informationen, mit den Entwurfsentwicklungsinformationen, die in dieser Tagung erfaßt wurden, zugänglich sind und zu einem späteren Zeitpunkt unter Verwendung anderer Anwendun­ gen aufgebaut werden können. Beispielsweise kann ein CAD- Ingenieur mit einer Verpflichtung, einen Teil des Entwurfs in einer besonderen Weise zu ändern, nicht die konkrete Entwurfsabsicht der Änderung, die auf einer Online-Tagung diskutiert wurde, zurückrufen. Durch Verwendung eines CAD- Werkzeugs 10a, das die öffentlichen Schnittstellen für die geeigneten Objektmodelle verwendet, die das Kollaborations­ sitzungsobjektmodell 10f und IIM-Objektmodell 10e umfaßt, kann der Ingenieur die Objektmodelle abfragen, um die Ent­ wurfsabsicht abzurufen, die mit der Entwurfsänderungsaufga­ be verbunden ist.

Die in dem UML-Diagrammen in den Fig. 3, 4 und 5 defi­ nierten Schnittstellen sind vorzugsweise in einer objekt­ orientierten Sprache, wie beispielsweise C++ oder Java2 im­ plementiert. Die gegenwärtige Klassenimplementierung kann von System zu System variieren, da es oftmals Sinn machen wird, einige der Schnittstellen in eine einzelne Klasse zu kombinieren für eine Effizienz der Implementierung und/oder Performance bzw. Leistungsfähigkeit.

Fig. 6 zeigt eine Blockdiagramm, das eine Ausführungsform der dauerhaften Speicherentitäten verdeutlicht, die durch das Kollaborationssitzungsobjektmodell 100 aus Fig. 2 un­ ter Verwendung der in Fig. 3 definierten Schnittstellen erzeugt und erhalten werden. Bei dieser Ausführungsform hat jede der Schnittstellen mit sich eine dauerhafte Speicher­ datei verbunden, vorzugsweise in Form einer relationalen Datenbank. Die Daten, die unter Verwendung jeder jeweiligen Schnittstelle umfaßt sind, sind in deren jeweiligen rela­ tionalen Datenbankdateien gespeichert. Folglich gibt es ei­ ne getrennte bzw. separate relationale Datenbankdatei für jede definierte Schnittstelle. In der veranschaulichenden Ausführungsform speichert eine Tagungsplantabelle 310 alle Daten, auf die durch Verwendung der Tagungsplanschnittstel­ le 210 zugegriffen wird. Eine Tagungsagendatabelle 320 speichert alle Daten, auf die durch Verwendung der Ta­ gungsagendaschnittstelle 220 zugegriffen wird. Eine Ta­ gungszielsetzungstabelle 330 speichert alle Daten, auf die unter Verwendung der Tagungszielsetzungsschnittstelle 230 zugegriffen wird. Eine Tagungszeitplantabelle 340 speichert alle Daten, auf die unter Verwendung der Tagungszeitplan­ schnittstelle 240 zugegriffen wird. Eine Tagungsdiskussi­ onstabelle 350 speichert alle Daten, auf die unter Verwen­ dung der Tagungsdiskussionsschnittstelle 250 zugegriffen wird. Eine Konversationstabelle 360 speichert alle Daten, auf die unter Verwendung der Konversationsschnittstelle 260 zugegriffen wird. Eine Aktortabelle 370 speichert alle Da­ ten, auf die unter Verwendung der Aktorschnittstelle 270 zugegriffen wird. Eine Verpflichtungstabelle 390 speichert alle Daten, auf die unter Verwendung der Verpflichtungs­ schnittstelle 290 zugegriffen wird. Eine Aufgabentabelle 380 speichert alle Daten, auf die unter Verwendung der Auf­ gabenschnittstelle 280 zugegriffen wird. Die gestrichelten Linien, die die unterschiedlichen Tabellen verbinden, re­ präsentieren einen fremden Schlüssel bzw. einen fremden Kennbegriff, das heißt eine gemeinsame Spalte in jeder ver­ bundenen relationalen Datenbank, der verwendet wird, um Be­ ziehungen zwischen in den Tabellen gespeicherten Daten zu repräsentieren.

Bei der bevorzugten Ausführungsform ist jede Tabelle unter Verwendung einer getrennten relationalen Datenbankdatei im­ plementiert, wo jede Reihe auf ein unterschiedliches Objekt des in dieser konkreten relationalen Datenbankdatei gespei­ cherten Typs abbildet, und jede Spalte auf ein Attribut ab­ bildet, das unter Verwendung der konkreten verbundenen Schnittstelle umfaßt ist oder an einen primären Schlüssel, der verwendet wird, um eindeutig ein bestimmtes Objekt in der Datei zu identifizieren oder auf einen fremden Schlüs­ sel, der verwendet wird, um ein Objekt in einer Datei mit einem Objekt in einer der anderen relationalen Datenbankda­ teien zu verbinden.

Tagungsinformationen können über Benutzerschnittstellendia­ logfelder bzw. -Boxen und/oder automatisch ohne Nutzerin­ tervention erfaßt werden. Beispielsweise können der Ta­ gungsplan und verbundene Zielsetzung und Teilnehmer manuell durch einen Nutzer über ein Dialogfeld eingegeben werden, während der Zeitplan und der Ort der Tagung durch eine au­ tomatische Zeitplananwendung bestimmt werden können und dann in den Kollaborationssitzungsobjektmodell erfaßt wer­ den können. Ähnliche Dialogfelder können implementiert sein, um entwurfsspezifische Probleme und Themen, Produkt­ anforderungsentscheidungen, Produktfunktionsentscheidungen, Entwurfsalternativentscheidungen und Entwurfsrepräsentati­ onsentscheidungen zu erfassen.

Wie vorstehend ausführlicher beschrieben ist, bietet die Erfindung eine neue Art der Erfassung, Speicherung, des Zu­ greifens und Nachvollziehens von Fragen, Antworten, Proble­ men und Entscheidungen. Das Entscheidungsnachvollziehungs­ objektmodell der Erfindung erlaubt das Erfassen des inkre­ mentellen Aufbaus von Entscheidungsuntersuchungsdaten, mit Fragen, Antworten und die Produktprobleme betreffenden Ent­ scheidungen, alternative Entwurfsvorschläge, Produktanfor­ derungen und Produktfunktionen, die während der Entwicklung eines Produkts untersucht werden. Die Entscheidungsnach­ vollziehungsinformationen sind in einer Form repräsentiert, auf die auf unterschiedliche Weise unter Verwendung unter­ schiedlicher computerbasierter Anwendungen zugegriffen wer­ den kann und die präsentiert werden kann.

Obwohl die Erfindung anhand der veranschaulichenden Ausfüh­ rungsformen beschrieben wurde, werden Fachleute erkennen, daß verschiedene Änderungen und Modifikationen, zu den ver­ anschaulichenden Ausführungsformen gemacht werden können, ohne den gedanklichen Hintergrund und den Bereich der Er­ findung zu verlassen. Es ist beabsichtigt, daß der Bereich der Erfindung auf keine Weise auf die veranschaulichenden Ausführungsbeispiele beschränkt ist, die gezeigt und be­ schrieben sind.

Claims (20)

1. Objektmodell zum Erfassen von Informationen, die eine Online-Tagung betreffen, mit:
einer Tagungsplan-Schnittstelle zum Erfassen von admini­ strativen Tagungsinformationen einer Tagung in einem Ta­ gungsplanobjekt, und
einer Tagungsdiskussionsschnittstelle zum Erfassen von we­ sentlichen Informationen in einem Tagungsdiskussionsobjekt, die den Inhalt der Diskussion während der Tagung betreffen.

2. Objektmodell nach Anspruch 1, bei dem das Tagungsplan­ objekt und das Tagungsdiskussionsobjekt jeweils in einer werkzeugneutralen dauerhaften Form gespeichert sind.

3. Objektmodell nach Anspruch 2 bei dem das Tagungspla­ nobjekt und das Tagungsdiskussionsobjekt jeweils in einer separaten relationalen Datenbank gespeichert sind, wobei Verbindungen zwischen jeweils dem Tagungsplanobjekt und dem Tagungsdiskussionsobjekt unter Verwendung fremder Kennbe­ griffe bzw. Schlüssel erfaßt sind.

4. Objektmodell nach Anspruch 1, bei dem die Tagungsdis­ kussionsschnittstelle produktentwurfsbezogene Informationen in einem produktentwurfsbezogenem Objekt erfaßt.

5. Objektmodell nach Anspruch 1, bei dem die Tagungsdis­ kussionsschnittstelle entscheidungsbezogene Informationen in einem Entscheidungsobjekt erfaßt.

6. Objektmodell nach Anspruch 1, bei dem die Tagungsplan­ schnittstelle die Fähigkeit bietet, eine Tagungsagenda in einem Tagungsagendaobjekt, eine Tagungszielsetzung in einem Tagungszielsetzungsobjekt und einen Tagungszeitplan in ei­ nem Tagungszeitplanobjekt zu erfassen, wobei das Tagungsa­ gendaobjekt, das Tagungszielsetzungsobjekt und das Tagungs­ zeitplanobjekt separat in einer werkzeugneutralen Form ge­ speichert sind.

7. Objektmodell nach Anspruch 1, bei dem die Tagungsplan­ schnittstelle die Fähigkeit hat, eine Aufgabe in einem Auf­ gabenobjekt und eine Verpflichtung durch einen Tagungsteil­ nehmer, der diese Aufgabe auszuführen hat, in einem Ver­ pflichtungsobjekt zu erfassen, wobei das Verpflichtungsob­ jekt und das Aufgabenobjekt separat in einer werkzeugneu­ tralen Form gespeichert sind.

8. Verfahren zum Erfassen von Informationen, die eine On­ line-Tagung betreffen, mit folgenden Schritten:
Erfassen von administrativen Tagungsinformationen einer Ta­ gung in einem Tagungsplanobjekt, und
Erfassen von wesentlichen Informationen betreffend den In­ halt der Diskussionen während der Tagung in einem Tagungs­ diskussionsobjekt.

9. Verfahren nach Anspruch 8, mit dem Schritt des Spei­ cherns jeweils des Tagungsplanobjekts und des Tagungsdis­ kussionsobjekts in einer werkzeugneutralen dauerhaften Form.

10. Verfahren nach Anspruch 9, mit dem Schritt des Spei­ cherns jeweils des Tagungsplanobjekts und des Tagungsdis­ kussionsobj ekts in einer separaten relationalen Datenbank, wobei Verbindungen zwischen dem Tagungsplanobjekt und dem Tagungsdiskussionsobjekt jeweils unter Verwendung fremder Kennbegriffe erfaßt werden.

11. Verfahren nach Anspruch 8, mit dem Schritt des Erfas­ sens von produktentwurfsbezogenen Informationen in einem produktentwurfsbezogenen Objekt.

12. Verfahren nach Anspruch 8, mit dem Schritt des Erfas­ sens von entscheidungsbezogenen Informationen in einem Ent­ scheidungsobjekt.

13. Verfahren nach Anspruch 8, mit dem Schritt des Erfas­ sens einer Tagungsagenda in einem Tagungsagendaobjekt, ei­ ner Tagungszielsetzung in einem Tagungszielsetzungsobjekt, eines Tagungszeitplans in einem Tagungszeitplanobjekt, und den Schritt des Speicherns des Tagungsagendaobjekts, des Tagungszielsetzungsobjekts und des Tagungszeitplanobjekts separat in einer werkzeugneutralen Form.

14. Verfahren nach Anspruch 13, mit folgenden Schritten:
Erfassen einer Aufgabe in einem Aufgabenobjekt und einer Verpflichtung durch einen Tagungsteilnehmer, der diese Auf­ gabe auszuführen hat, in einem Verpflichtungsobjekt, und Speichern des Verpflichtungsobjekts und des Aufgabenobjekts separat in einer werkzeugneutralen Form.

15. Computerlesbares Speichermedium, das faßbar Programm­ befehle umfaßt, die ein Verfahren zum Erfassen von Informa­ tionen, die eine Online-Tagung betreffen, implementieren, wobei das Verfahren folgende Schritte umfaßt:
Erfassen von administrativen Tagungsinformationen einer Ta­ gung in einem Tagungsplanobjekt, und
Erfassen von wesentlichen Informationen betreffend den In­ halt der Diskussion während der Tagung in einem Tagungsdis­ kussionsobjekt, und
jeweils Speichern des Tagungsplanobjekts und des Tagungsdi­ kussionsobjekts in einer werkzeugneutralen dauerhaften Form.

16. Computerlesbares Speichermedium nach Anspruch 15, wo­ bei das Verfahren den Schritt des Speicherns jeweils des Tagungsplanobjekts und des Tagungsdiskussionsobjekts in ei­ ner separaten relationalen Datenbank umfaßt, wobei Verbin­ dungen zwischen dem Tagungsplanobjekt und dem Tagungsdis­ kussionsobjekt jeweils unter Verwendung fremder Kennbegrif­ fe erfaßt werden.

17. Computerlesbares Speichermedium nach Anspruch 16, wo­ bei das Verfahren den Schritt des Erfassens von produktent­ wurfsbezogenen Informationen in einem produktentwurfsbezo­ genen Objekt umfaßt.

18. Computerlesbares Speichermedium nach Anspruch 15, wo­ bei das Verfahren den Schritt des Erfassens entscheidungs­ bezogener Informationen in einem Entscheidungsobjekt um­ faßt.

19. Computerlesbares Speichermedium nach Anspruch 15, wo­ bei das Verfahren folgende Schritte umfaßt:
Erfassen einer Tagungsagenda in einem Tagungsagendaobjekt, einer Tagungszielsetzung in einem Tagungszielsetzungsobjekt und eines Tagungszeitplans in einem Tagungszeitplanobjekt, und
Speichern des Tagungsagendaobjekts, des Tagungszielset­ zungsobjekts und des Tagungszeitplanobjekts separat in ei­ ner werkzeugneutralen Form.

20. Computerlesbares Speichermedium nach Anspruch 15, wo­ bei das Verfahren folgende Schritte umfaßt:
Erfassen einer Aufgabe in einem Aufgabenobjekt und einer Verpflichtung durch einen Tagungsteilnehmer, der diese Auf­ gabe auszuführen hat, in einem Verpflichtungsobjekt, und
Speichern des Verpflichtungsobjekts und des Aufgabenobjekts separat in einer werkzeugneutralen Form.