DE102010016541A1

DE102010016541A1 - Computergestütztes Verfahren zum Erzeugen eines softwarebasierten Analysemoduls

Info

Publication number: DE102010016541A1
Application number: DE102010016541A
Authority: DE
Inventors: Anmelder Gleich
Original assignee: Individual
Current assignee: Individual
Priority date: 2010-04-20
Filing date: 2010-04-20
Publication date: 2011-10-20
Also published as: WO2011131186A3; WO2011131186A2; US9710232B2; US20130263079A1

Abstract

Die Erfindung betrifft ein computergestütztes Verfahren zum Erzeugen eines softwarebasierten Analysemoduls für eine Analyse von elektronischen Rohdaten, die ein erfasstes Stimulus-Verhalten einer Testperson in einem Testprojekt repräsentieren. Das Verfahren umfasst die folgenden Schritte: Bereitstellen von Logikdaten, welche eine benutzerdefinierte Berechnungslogik repräsentieren, in einer auf einer Computereinrichtung implementierten Anwendungssoftware, Bereitstellen von Projektdaten, welche eine benutzerdefinierte Projektdefinition mit einer strukturierten Ordnung von Projektentitäten des Testprojektes repräsentieren, in der Anwendungssoftware, Erzeugen von Projekteinstellparameterdaten, indem beim Zuordnen der Logikdaten zu den Projektdaten die benutzerdefinierte Berechnungslogik den Projektentitäten zugeordnet wird und hieraus Projekteinstellparameter für die Projektentitäten des Testprojektes abgeleitet werden, Bereitstellen der Projekteinstellparameterdaten für eine Datenausgabe über eine Benutzeroberfläche und Erfassen von zugeordneten Benutzereingaben für einen Teil der Projekteinstellparameterdaten, und Erzeugen eines Analysemoduls entsprechend der Logikdaten, der Projektdaten und der Projekteinstellparameterdaten, welches konfiguriert ist, elektronische Rohdaten, die ein erfasstes Stimulus-Verhalten einer Testperson repräsentieren, zu empfangen und zum Analysieren des Verhaltens der Testperson zu verarbeiten.

Description

Die Erfindung betrifft ein computergestütztes Verfahren zum Erzeugen eines softwarebasierten Analysemoduls für eine Analyse von elektronischen Rohdaten, die ein erfasstes Stimulus-Verhalten einer Testperson in einem Testprojekt repräsentieren.
Hintergrund der Erfindung
Derartige softwarebasierte Analysemodule werden eingesetzt, um elektronische Rohdaten zu analysieren, die zuvor im Rahmen eines Testprojektes erfasst wurden. Die Rohdaten repräsentieren das Stimulus-Verhalten einer Testperson in der konkret genutzten Testumgebung. Derartige Testprojekte werden in Verbindung mit der Marktforschung genutzt, bei der es sich um eines der wichtigsten Werkzeuge des Marketings handelt. Die Marktforschung liefert aber nicht nur für das Marketing Entscheidungshilfen sondern auch für andere Unternehmensbereiche wie zum Beispiel das Controlling und den Vertrieb.
Softwarebasierte Technologien werden genutzt, um die Testprojekte der Marktforschung effizient, umfassend und kosteneffektiv durchzuführen. Typische Forschungsaufgaben sind beispielsweise das Erforschen von der Qualität eines Produktes, der Wirksamkeit von Werbung, der Effektivität des Vertriebes oder der Gestaltung eines Verkaufspreises. Ein typisches Testprojekt betrifft beispielsweise das Verhalten einer Testperson in einer Verkaufsumgebung („Point of Sale”). Es stellen sich hierbei Fragen nach der optimalen Platzierung eines Produktes für einen Abverkauf oder der Wirkung von Werbeaktionen für den Abverkauf eines Produktes. Andere Testprojekte betreffen die Erforschung der Wirkung und Verbesserung von Werbespots im Fernsehen oder von Anzeigen im Internet. Die Testperson wird im Rahmen des jeweiligen Testprojektes dann den einzelnen Stimuluselementen ausgesetzt, also zum Beispiel einer konkreten Produktpräsentation in einer Verkaufsumgebung oder dem Werbespot, die den so genannten Stimulus des Testprojektes bilden. Hierauf wird das Verhalten der Testperson erfasst, woraus elektronische Rohdaten abgeleitet werden. Rohdaten werden zum Beispiel mittels des so genannten „Eye Trackings” erfasst, welches dazu dient, die Augenausrichtung der Testperson auf einzelne oder mehrere Stimuluselemente zu erfassen. In Verbindung mit einem Testprojekt zur Wirkung von Werbespots können ergänzend oder alternativ Rohdaten aus Benutzereingaben erfasst werden, die die Testperson über eine Tastatur eines Computers macht.
Der tatsächlichen Ausführung des Testprojektes sind eine Planung und eine Definition der Elemente des Testprojektes vorausgegangen. Hierbei werden, ausgehend von der oder den Fragestellungen, die Testumgebung und die Stimuluselemente festgelegt. Nachdem das Testprojekt der vorgegebenen Definition entsprechend durchgeführt worden ist und die das Stimulusverhalten der Testperson repräsentierenden Rohdaten erfasst worden sind, werden diese analysiert, um hieraus Informationen bezüglich der im Rahmen des Testprojektes zu bearbeitenden Fragestellungen zu erhalten. Die hierbei aus den Rohdaten abgeleiteten Daten werden als sogenannte Metricsdaten bezeichnet. Das Ergebnis der Analyse der elektronischen Rohdaten wird anschließend für eine Präsentation bereitgestellt.
In bekannten Testprojekten werden Applikationen eingesetzt, um einzelne Elemente des Prozesses softwaretechnisch zu unterstützen.
Zusammenfassung der Erfindung
Aufgabe der Erfindung ist es, ein computergestütztes Verfahren zum Erzeugen eines softwarebasierten Analysemoduls für eine Analyse von elektronischen Rohdaten, die ein erfasstes Stimulusverhalten einer Testperson in einem Testprojekt repräsentieren, anzugeben, mit dem eine einfache und effiziente Individualanpassung zur automatisierten Analyse der Rohdaten ermöglicht ist.
Diese Aufgabe wird erfindungsgemäß durch ein computergestütztes Verfahren zum Erzeugen eines softwarebasierten Analysemoduls für eine Analyse von elektronischen Rohdaten nach dem unabhängigen Anspruch 1 gelöst. Vorteilhafte Ausgestaltungen der Erfindung sind Gegenstand von abhängigen Unteransprüchen.
Die Erfindung umfasst den Gedanken eines computergestützten Verfahrens zum Erzeugen eines softwarebasierten Analysemoduls für eine Analyse von elektronischen Rohdaten, die ein erfasstes Stimulusverhalten einer Testperson in einem Testprojekt repräsentieren, wobei das Verfahren die folgenden in einer Computereinrichtung ausgeführten Schritte umfasst:

– Bereitstellen von Logikdaten, welche eine benutzerdefinierte Berechnungslogik repräsentieren, in einer auf der Computereinrichtung implementierten Anwendungssoftware,
– Bereitstellen von Projektdaten, welche eine benutzerdefinierte Projektdefinition mit einer strukturierten Ordnung von Projektentitäten des Testprojektes repräsentieren, in der Anwendungssoftware,
– Erzeugen von Projekteinstellparameterdaten, indem beim Zuordnen der Logikdaten zu den Projektdaten die benutzerdefinierte Berechnungslogik den Projektentitäten zugeordnet wird und hieraus Projekteinstellparameter für die Projektentitaten des Testprojektes abgeleitet werden,
– Bereitstellen der Projekteinstellparameterdaten für eine Datenausgabe über eine Benutzeroberfläche und Erfassen von zugeordneten Benutzereingaben für wenigstens einen Teil der Projekteinstellparameterdaten, und
– Erzeugen eines Analysemoduls entsprechend der Logikdaten, der Projektdaten und der Projekteinstellparameterdaten, welches konfiguriert ist, elektronische Rohdaten, die ein erfasstes Stimulusverhalten einer Testperson in einem Testprojekt repräsentieren, zu empfangen und zum Analysieren des Verhaltens der Testperson zu verarbeiten.

Das Verfahren ermöglicht einerseits eine benutzerdefinierte Individualanpassung des Testprojektes zum Erfassen des Stimulusverhaltens, indem Logikdaten und Projektdaten benutzerdefiniert bereitgestellt werden. Hierbei werden die Projektdaten getrennt von den Logikdaten bereitgestellt, was eine individuelle Konfigurierbarkeit und eine getrennte Handhabung, Bearbeitung sowie Verwaltung ermöglicht. Mit den Logikdaten wird eine Berechnungslogik für das konkrete Testprojekt festgelegt. Der Anwender kann bei seiner benutzerdefinierten Festlegung der Berechnungslogik vorzugsweise auf vordefinierte Transformations- oder Logikmodule zurückgreifen. Die Projektdaten repräsentieren eine benutzerdefinierte Projektdefinition mit einer strukturierten Anordnung von Projektentitäten des Testprojektes. Hierin werden alle an der Projektdefinition beteiligten Elemente in einer hierarchischen Anordnung zusammengefasst. Aus einer Zuordnung der Logikdaten und der Projektdaten werden dann für das Projekt Projekteinstellparameterdaten erzeugt, welche Projekteinstellparameter für die Projektentitäten des Testprojektes repräsentieren. Der Anwender erhält hierauf die Möglichkeit, die Projekteinstellparameterdaten individuell einzustellen. Schließlich wird ausgehend hiervon das Analysemodul erzeugt, welches, nachdem die elektronischen Rohdaten im Rahmen des Testprojektes erfasst worden sind, zu deren Auswertung genutzt wird. Der Einsatz des Analysemoduls erfolgt bevorzugt mittels einer sogenannten Transformer Host Applikation.
Eine Erzeugung oder Bereitstellung des Analysemoduls liegt auch darin, dieses auf Basis eines existierenden Analysemoduls entsprechend der Logikdaten, der Projektdaten und der Projekteinstellparameterdaten in angepasster Form für das konkrete Projekt zu erzeugen. Es erfolgt eine angepasste Bereitstellung des Analysemoduls für das mittels der Logikdaten, der Projektdaten und der Projekteinstellparameterdaten definierte Projekt.
Mit der Erfindung ist eine Technologie bereitgestellt, die es ermöglicht, für beliebige Testprojekte ein zugeordnetes Analysemodul zur Auswertung der im Rahmen des Testprojektes erfassten Rohdaten für das Stimulusverhalten einer Testperson automatisiert zur erstellen. Die erfindungsgemäß vorgesehene, getrennte Bereitstellung von Logikdaten einerseits und Projektdaten andererseits unterstützt eine größtmögliche Flexibilität beim Erzeugen des projektspezifischen Analysemoduls.
Eine bevorzugte Ausgestaltung der Erfindung sieht vor, dass die Logikdaten und/oder die Projektdaten einer Graphenrepräsentation entsprechend bereitgestellt werden. Bei dieser Ausführungsform werden vordefinierte Module dem Anwender in einem grafischen Layout bereitgestellt und der Anwendereingabe entsprechend in einer Grafenrepräsentation verbunden und bereitgestellt.
Eine weitere bevorzugte Ausgestaltung der Erfindung sieht vor dass der Schritt zum Erzeugen des Analysemoduls das Umwandeln der Logikdaten in Quelltextdaten sowie das Bereitstellen der Projekteinstellparameter mit zugeordneten Projekteinstellparameterwerten umfasst. Die Projekteinstellparameterdaten umfassen somit schließlich definierte Einstellparameter einerseits sowie zugeordnete Werte für die Einstellparameter andererseits.
Eine weitere bevorzugte Ausgestaltung der Erfindung sieht vor, dass die Logikdaten, die Projektdaten und/oder die Projekteinstellparameterdaten in einem XML-basierten Datenformat bereitgestellt werden.
In einer bevorzugten Ausgestaltung der Erfindung ist vorgesehen, dass der Schritt zum Erzeugen von Projekteinstellparameterdaten das Ableiten von Einstellparameterdaten aus den Logikdaten, indem die Logikdaten nach von ihnen umfassten Parameter untersucht werden, und das Zuordnen der Einstellparameterdaten zu den Projektentitäten des Testprojektes in den Projektdaten umfasst. Das Ableiten von Einstellparameterdaten führt in einer Ausgestaltung zu einer so genannten Parameterliste, die dann auf die Projektdaten angewendet wird, was zum Zuordnen der Einstellparameterdaten aus der Parameterliste zu den Projektentitäten des Testprojektes führt.
Eine weitere bevorzugte Ausgestaltung der Erfindung sieht vor, dass die Logikdaten zunächst als editierbare Ausgangslogikdaten bereitgestellt und mittels eines zugeordneten Editors hierauf bezogene Benutzereingaben erfasst werden, mit denen die Ausgangslogikdaten editiert werden. Mit Hilfe des zugeordneten Editors ist dem Anwender die Möglichkeit gegeben auf einfache und effiziente Art und Weise die Logikdaten projektspezifisch zu definieren. Hierbei ist vorgesehen, dass dem Anwender zunächst Ausgangslogikdaten präsentiert werden, die wahlweise bereits eine zusammenhängende Berechnungslogik repräsentieren können, welche der Anwender dann ganz oder teilweise übernehmen kann.
Des Weiteren sieht eine bevorzugte Ausgestaltung der Erfindung vor, dass mit dem Editor welcher den Logikdaten zugeordnet ist, vordefinierte und vom Benutzer auswählbare Berechnungslogikbausteine bereitgestellt werden.
Eine weitere bevorzugte Ausgestaltung der Erfindung sieht vor, dass die Projektdaten zunächst als editierbare Ausgangsprojektdaten bereitgestellt und mittels eines zugeordneten Editors hierauf bezogene Benutzereingaben erfasst werden, mit denen die Projektdaten editiert werden. Der den Projektdaten zugeordnete Editor ist vorzugsweise getrennt vom Editor für die Logikdaten gebildet und implementiert. Unabhängig davon, ob die Editoren vollständig oder nur teilweise voneinander getrennt sind, erfolgt das Erfassen der Logikdaten getrennt von den Projektdaten.
Eine weitere bevorzugte Ausgestaltung der Erfindung sieht vor, dass der Editor, welcher den Projektdaten zugeordnet ist, mit einem oder mehreren Teileditoren bereitgestellt wird, die die folgenden Teileditoren umfassen:

– einen Baum-Editor, welcher konfiguriert ist, eine hierarchische Struktur der strukturierten Ordnung der Projektentitäten anzuzeigen und hierauf bezogenen Benutzereingaben zu erfassen,
– einen Knoten-Editor, welcher konfiguriert ist, Eigenschaftsparameter eines aktuell ausgewählten Knotens der strukturierten Ordnung der Projektentitäten anzuzeigen und hierauf bezogene Benutzereingaben zu erfassen, und
– einen Canvas-Editor, welcher konfiguriert ist, eine räumliche Anordnung von Knoten der strukturierten Ordnung der Projektentitäten anzuzeigen und hierauf bezogene Benutzereingaben zu erfassen.

Eine weitere bevorzugte Ausgestaltung der Erfindung sieht vor, dass die Projekteinstellparameterdaten für hierdurch repräsentierte Projekteinstellparameter jeweils Metadaten umfassen, die wenigstens eine Datenart ausgewählt aus der folgenden Gruppe von Datenarten umfasst:

– Wertebereichsempfehlungsdaten,
– Wertebereichsbeschränkungsdaten,
– Kommentardaten,
– Prioritätsdaten,
– Control-Typdaten,
– Gruppierungs-, Filter- und/oder Sortierdaten und
– Verweisdaten zum Verweisen auf Hilfefunktionen.

Eine weitere bevorzugte Ausgestaltung der Erfindung sieht vor, dass das Analysemodul konfiguriert wird, beim Verarbeiten der Rohdaten das Verhalten der Testperson repräsentierende Metricsdaten zu erzeugen. Metricsdaten sind aus den Rohdaten abgeleitete Daten, diefür einen Benutzer, zum Beispiel einen Entscheidungsträger in der Marktforschung, eine direkte Aussagekraft in Bezug auf die Performance/Qualität einer Produkteigenschaft (Stimuluselement) haben. Ein Beispiel für einen Metricswert ist die Betrachtungsdauer des Stimuluselementes Produktverpackung. Die Metricsdaten sind in einer Ausführung die folgenden Informationen umfassend gebildet: Angabe zu einer oder mehreren Testpersonen, Angaben zu der oder den bearbeiteten Fragestellungen und Angaben zu den Eigenschaften der untersuchten Stimuluselemente in der Kommunikation mit der oder den Testpersonen.
Beschreibung bevorzugter Ausführungsbeispiele
Die Erfindung wird im Folgenden anhand von bevorzugten Ausführungsbeispielen unter Bezugnahme auf Figuren einer Zeichnung näher erläutert. Hierbei zeigen:
1 eine schematische Blockdarstellung in Verbindung mit einem computergestützten Verfahren zum Erzeugen eines softwarebasierten Analysemoduls für eine Analyse von elektronischen Rohdaten, die ein erfasstes Stimulusverhalten einer Testperson in einem Testprojekt der Marktforschung repräsentieren,
2 eine schematische Blockdarstellung eines softwarebasierten Analysemoduls,
3 eine schematische Blockdarstellung zu weiteren Details in Verbindung mit einem ATG-Editor,
4 eine schematische Darstellung zur Übersetzung und zum Einsatz eines ATG-Modells,
5 eine weitere schematische Blockdarstellung des ATG-Editors,
6 eine schematische Blockdarstellung zu weiteren Details in Verbindung mit einem PEG-Editor,
7 eine schematische Blockdarstellung in Verbindung mit einem APV-Editor, wobei auch der ATG-Editor und der PEG-Editor dargestellt sind,
8 eine schematische Blockdarstellung für ein verteiltes Hosting,
9 eine schematische Darstellung zur Anwendung einer Transformer Host Applikation,
10 die Integration einer ATL.DLL in den Verarbeitungsprozess der Transformer Host Applikation,
11 einen EventData- und einen EventCollect-Datensatz in tabellarischer Form,
12 einen SubjectStimulusAggregate- und einen StimulusAggregate-Datensatz in tabellarischer Form,
13 einen schematischen Aufbau und einen beispielhaften Anwendungsfall des PEG-Editors,
14 eine schematische Darstellung zur Parametrisierung von sogenannten Items und
15 eine schematische Darstellung zur Parametrisierung von sogenannten Groups.
1 zeigt eine schematische Blockdarstellung in Verbindung mit einem Testprojekt auf dem Gebiet der Marktforschung. In einer Phase der Datensammlung 10 werden im Rahmen des Testprojektes sogenannte Rohdaten 11 erfasst, die das Stimulusverhalten der Testperson repräsentieren. Die Rohdatenerfassung erfolgt in einer Testumgebung einer vorher festgelegten Testprojektdefinition entsprechend. Rohdaten können zum Beispiel im Rahmen des sogenannten „Eye Trackings” erfasst werden, welches dazu dient, die Augenausrichtung der Testperson auf einzelne oder mehrere Stimuluselemente des Testprojektes zu erfassen. Eine weiterhin nutzbare Möglichkeit der Rohdatenerfassung besteht darin, Eingaben zu erfassen, die die Testperson über eine Eingabeeinrichtung eines Computers macht, zum Beispiel eine Maus oder eine Tastatur. Die Rohdaten 11 werden gemäß der Darstellung in 1 in einer Datenbank 12 abgelegt. Die im Rahmen des Testprojektes erfassten Rohdaten können durch externe Daten 13 ergänzt werden.
Im nächsten Schritt des Testprojektes werden die Rohdaten 11 an ein Analysemodul 14 übergeben, mit dem die Rohdaten einer vorgegebenen Analysestrategie entsprechend ausgewertet und in Metricsdaten 15 umgewandelt werden. Das Analysemodul 14 ist mit Hilfe einer softwarebasierten Technologie implementiert und gewährleistet eine automatische Datenanalyse der Rohdaten 11. Die Metricsdaten 15 werden in einer zugeordneten Datenbank 16 abgelegt. Die Metricsdaten 15 können anschließend einer Datenpräsentation 17 zugeführt werden, die dazu dient, das Ergebnis des Testprojektes zur Marktforschung zu präsentieren.
Nachfolgend werden Technologien in Verbindung mit dem computergestützten Erzeugen des softwarebasierten Analysemoduls 14 für die Analyse der Rohdaten 11 beschrieben.
2 zeigt eine schematische Blockdarstellung eines softwarebasierten Analysemoduls 14, welches in der dargestellten Ausführungsform vier Hauptkomponenten umfasst, die nachfolgend näher erläutert werden.
Ein ATG-Editor 20 (ATG – „Analysis Transform Graph”) ermöglicht es dem Anwender, eine Berechnungslogik für das auszuführende Testprojekt zu definieren und zu verwalten. 3 zeigt eine schematische Blockdarstellung zu weiteren Details in Verbindung mit dem ATG-Editor 20.
Die Definition der Berechnungslogik für die Analysephase des Testprojektes erfolgt getrennt vom Source Code der Software in einer speziell für diesen Zweck entworfenen grafischen Datentransformationssprache. Zum Entwurf einer Berechnungslogik greift der Anwender 30 auf eine Auswahl von vordefinierten Transformationsmodulen 31 zurück, die ihm in dem ATG-Editor 20 präsentiert werden. Die vordefinierten Transformationsmodule werden in einem grafischen Layout arrangiert und zu einem Transformationsgraphen 32 miteinander verbunden. Der Anwender kann mittels seiner Eingaben den Transformationsgraphen 32 projektspezifisch festlegen. Der Transformationsgraph 32 wird schließlich in einem XML-basierten Format als ATG-File 33 abgespeichert. Der „Method Definition Lager” (Methodendefinitionslayer) mit dem ATG-Editor 20 beantwortet die Frage: „Mit welcher Logik soll berechnet werden?”
Der ATG-File 33 ist ein Model der Berechnungslogik. 4 illustriert die Übersetzung und den Einsatz des ATG-Modells. Das ATG-File 33 wird mit Hilfe eines Generatormoduls 40 des Analysis Transform Lagers zunächst in C# Quelltext übersetzt. Im nächsten Schritt wird der Quelltext in ein .NET Assembly kompiliert, nämlich ATL.DLL 41 („Analysis Transform Lib”).
5 zeigt eine schematische Blockdarstellung des ATG-Editors 20. Er setzt sich aus drei Elementen zusammen: Module Box 50, Canvas 51 und Macro Canvases Bar 52. Das Element Module Box 50 bietet dem Benutzer eine Auswahl an Datentransformationsmodulen an, die in der Analysis.Transforms.DLL definiert sind. Der Benutzer kann die Module per Drag and Drop in den Canvas Bereich 51 ziehen und sie zu einem Transform Graphen zusammensetzen. Der Transform Graph eines Canvases lässt sich als ATG-Modul abspeichern und in dem Element Macro Canvases Bar 52 anzeigen. ATG-Module können als Element in anderen Analysis Transform Graphen eingesetzt und somit wieder verwendet werden. Auf diese Weise können einfache und standardisierte Basiselemente die Grundlage für umfangreichere und speziellere Datenreports bilden.
Um die Vergleichbarkeit eines Metricsdatenreports über verschiedene Testprojekte hinweg zu gewährleisten, wird die Berechnungslogik des Reports in der Regel als Standard definiert und projektübergreifend in möglichst vielen Studien unverändert eingesetzt.
Für den ATG-Editor 20 können folgende Vorteile festgehalten werden:

– Freie Definition der Analyselogik durch den Anwender.
– Effektivere Definition der Analyselogik mit Hilfe einer spezialisierten Datentransformationssprache.
– Bessere Verständlichkeit und Dokumentation der Analyselogik durch grafisches Layout.
– Die Analyselogik kann unabhängig vom Source Code der Software verwaltet, ausgetauscht und vertrieben werden.
– Schutz vertraulicher proprietärer Verfahren.

Ein PEG-Editor 21 in 2 ermöglicht die Erstellung des zentralen Projektkonfigurationsformates für das Testprojekt. 6 zeigt eine schematische Blockdarstellung zu weiteren Details in Verbindung mit dem PEG-Editor 21.
Es werden Projektentitäten 60 in ihrer hierarchischen Struktur zueinander definiert, so dass in dem PEG-Editor 21 den Vorgaben des Anwenders 61 entsprechend ein Projektentitätengraph (PEG) 62 des Projektes gebildet wird, aus dem ein PEG-File 63 abgeleitet wird. Der PEG-File 63 ist eine umfassende hierarchische Beschreibung des Testprojektes und des zu untersuchenden Stimulus. Der PEG-File 63 wird in einem XML-basierten Format abgespeichert. Der „Project Definition Layer” (Projektdefinitions-Layer) mit dem PEG-Editor 21 beantwortet die Frage: „Mit welchen Entitäten soll gerechnet werden?”
Im Rahmen des Erzeugens des Analysemoduls hat der Anwender die Möglichkeit, eine Anzahl von Berechnungsparametern einzustellen, was im so genannten APV-Editor 22 erfolgt. 7 zeigt eine schematische Blockdarstellung zu weiteren Details in Verbindung mit dem APV-Editor 22, wobei auch der mittels des ATG-Editors 20 erzeugte ATG-File 33 und der mittels des PEG-Editors 21 erstellte PEG-File 63 dargestellt sind.
Die Zusammenstellung der Berechnungsparameter ergibt sich aus der Beschreibung des Untersuchungsgegenstandes (PEG-File 63), also der hierarchischen Struktur der Projektentitäten, und der eingesetzten Berechnungslogik (ATG-File 33), was zuvor beides mittels der zugeordneten Editoren, nämlich des PEG-Editors 21 und des ATG-Editors 20, benutzerdefiniert erfasst worden ist. Der erzeugte Analyseparameter-File 70, welcher auch als API-File bezeichnet wird, wird in den APV-Editor 22 geladen. Der Anwender 71 kann dann mittels APV-Editors 22 die Berechnungsparameter ausfüllen und die eingegebenen Werte als APV-File 73 abspeichern. Der „Parameter Setup Layer” (Parametereinstellungslayer) beantwortet die Frage: „Mit welchen Einstellungen soll berechnet werden?”.
Die Grundidee des APV-Editors 22 ist es, dem Anwender ein für das Projektdesign und die gewählte Methodendefinition maßgeschneidertes Interface zur Verfügung zu stellen. Hierzu wird der Transform Graph (ATG-File 33) auf die in ihm definierten Parametermodule hin durchsucht. Die entstehenden Parameter-Listen enthalten für jeden Parameter die folgenden Metadaten, die vom Ersteller des ATG-Files 33 hinterlegt werden können: Empfehlungen (Wertebereiche, die üblich sind), Constraints (Einschränkungen für nicht sinnvolle Werte, Warnung beim Verletzen von standard-relevanten Einstellungen), Kommentare, Priorität (Parameter können als mandatory, optional oder advanced deklariert werden), Control Type (Als Standard wird ein Parameter durch das default Control seines Datentypen dargestellt. Beispielweise eine Checkbox für einen booleschen Wert. Abweichend können andere Control-Typen festgelegt werden.), Tags für Filter, Gruppierung, Sortierung und/oder Verweise zu allgemeiner Hilfefunktion.
In einem nächsten Schritt werden die gewonnenen Parameterlisten auf die im PEG-File 63 (vgl. 6) definierten Entitäten des Testdesigns und des Stimulus übertragen. Als Ergebnis dieser Kombination wird eine Analysis Parameter Items Datei (API-File 70, vgl. 7) erstellt, die eine Struktur von Berechnungsparametern und zugehörigen Metadaten darstellt.
Die API-Datei 70 wird in den APV-Editor 22 geladen. Die API-Datei 70 ist die Basis für die dynamischen und Aufgaben angepassten User Interface Funktionen des APV-Editors 22 (vgl. 7). Das User Interface des APV-Editors 22 ist in zwei Bereiche untergliedert: Einen PEG-Viewer Bereich 75 und den Parameter Explorer Bereich 76. Der Parameter Explorer präsentiert dem Benutzer eine Liste von User Controls (User Control Liste) für die im API-File 70 definierte Parameterliste. Die User Control Liste des Parameter Explorers kann nach den im API-File 70 hinterlegten Metadaten gefiltert, gruppiert und sortiert werden, zum Beispiel wie folgt: alphabetische Sortierung der Controls, Gruppieren nach Aufgabenbereichen oder Filtern von optionalen oder angewendeten Controls.
Jedes User Control zeigt die vom Ersteller des ATG-Files 70 hinterlegten Metainformationen an, zum Beispiel: Empfehlungen (Wertebereiche, die üblich sind), Constraints (Einschränkungen für nicht sinnvolle Werte, Warnung beim Verletzen von standardrelevanten Einstellungen), Kommentare und/oder Verweise zu allgemeiner Hilfefunktion (vgl. oben).
Im APV-Editor 22 können Parametereinstellungen auf bestimmte Projektentitäten bezogen werden (beispielsweise einen Task oder eine ScreenGroup). Die gewählte Einstellung (beispielsweise ein Cutoff Wert für eine Transition Berechnung). Die Einstellung ist dann gleichzeitig für die der Projektentität untergeordneten Entitäten gültig. Optional kann der Parameter auf einer niederen Ebene des PEG spezifiziert und damit die globale Einstellung überschrieben werden. Auf diese Weise wird die manuelle Definition einer Vielzahl von Detaileinstellungen erleichtert.
Der PEG-Viewer Bereich in der Benutzeroberfläche des APV-Editors 22 setzt die bekannten Editoren und Bedienprinzipien des PEG-Editors 21 ein. Der PEG-Viewer Bereich ermöglicht dem Benutzer die Selektion von Berechnungsparametern nach ihrer Zugehörigkeit zu den verschiedenen Projektentitäten.
In Verbindung mit dem vorgeschlagenen APV-Editor 22 ergeben sich mehrere Vorteile hinsichtlich der Benutzbarkeit. So werden nur die für die spezielle Berechnung nötigen Parameter angezeigt. Es werden spezielle Empfehlungen, Constraints und Kommentare des Autors der Berechnungsmethodik angezeigt. Auch können alle Bedienelemente nach ihrer Priorität und ihnen zugeordneten Tags gefiltert und sortiert werden.
Gemäß 2 dient schließlich eine so genannte Transformer Host Applikation 23 dem tatsachlichen Durchführen der Berechnung. Hierzu werden zunächst die in den drei vorangegangenen Lagern erzeugten Konfigurationsdateien ATG-File 33, APV-File 73 und PEG-File 63 geladen. Mit Hilfe der zuvor im ATG-Editor 20 definierten Berechnungslogik, der im PEG-Editor 21 erzeugten Beschreibung der Projektentitäten und den im APV-Editor 22 benutzerspezifisch erzeugten Berechnungseinstellungen wird aus den für das Testprojekt erfassten Rohdaten ein Metricsdatensatz (Ergebnisdaten) berechnet.
Wie im Diagramm zu sehen, ist die Phase des beschriebenen Verfahrens in der Transformer Host Applikation 23 abhängig von den Eingaben in den vorherigen Phasen in dem Projektdefinitionslayer, dem Methodendefinitionslayer und dem Parametereinstellungslayer. Die Phase zur Parametereinstellung ist abhängig von den zuvor erfassten Eingaben in dem Parametereinstellungslayer und dem Methodendefinitionslayer. Die Phasen in dem Parametereinstellungslayer und dem Methodendefinitionslayer sind komplett unabhängig von allen anderen Phasen.
Der Datenaustausch zwischen den vier Komponenten ATG-Editor 20, PEG-Editor 21, APV-Editor 22 und Transformer Host Applikation 23 erfolgt über vier definierte Schnittstellen: „Analysis Transform Graph” (ATG.XML), ”Project Entities Graph” (PEG.XML), ”Analysis Parameter Items” (API.XML) und ”Analysis Parameter Values” (APV.XML). Der Datenaustausch über die Schnittstellen erfolgt in Form von XML Dateien. Alle Formate sind als XML-Schema (XSD) definiert. (XSD ist ein vom World-Wide-Web Konsortium entwickelter Standard zur Beschreibung von XML Dokumenten (http://www.w3.org/TR/xmlschema-1/-29. November 2009). Die vier zentralen Schnittstellen in einem offenen industriestandard-konformen Format, ermöglichen es verschiedenen Anwendern, unabhängig die vier Hauptkomponenten in ihre Systeme zu integrieren.
Die oben genannten Eigenschaften, nämlich die Nutzung diskreter Lager, die Nutzung streng definierter Schnittstellen zwischen den Lagern und das Ausbilden limitierter Abhängigkeiten zwischen den Lagern, ermöglichen ein verteiltes Hosting der vier Hauptkomponenten auf unterschiedlichen physikalischen Einheiten (Tiers). Der Datenaustausch erfolgt über Web-Services, die die unter Schnittstellen dargestellten XML Dateien transferieren.
Die Multilager-Architektur implementiert in besonders effektiver Weise vorteihafte Software-Design Prinzipien: „Encapsulation”, „Cohesion”, „Separation of Concerns” und „Loose Coupling”. Folglich werden die beschriebenen Vorteile dieser Prinzipien wirksam: Leichtere Wartung, verbessere Erweiterbarkeit und besserte Testbarkeit.
8 zeigt eine schematische Blockdarstellung für ein verteiltes Hosting. Die Konfigurationseditoren ATG-Editor 20, PEG-Editor 21 und APV-Editor 22 können auf unterschiedlichen Personalcomputern als Web- oder Rich-Client-Applikationen (.NET XBap oder Silverlight) über einen Web-Server aufgerufen werden. Die Transformer Host Applikation 23 wird auf einem hochperformanten Application Server gehostet.
Es ergeben sich mehrere Vorteile. Die Aufteilung in die vier diskreten Layer (ATG-Editor 20, PEG-Editor 21, APV-Editor 22 und Transformer Host Applikation 23) ermöglicht einen Betrieb der Module mit Hilfe der offenen Schnittstellenformate und über zusätzliche Import und Exportfunktionen auch unabhängig voneinander. Sie lassen sich ohne weiteres später in ein erweitertes Gesamtsystem integrieren. Insbesondere die Module ATG-Editor 20 und PEG-Editor 21 können in ein bestehendes System integriert werden, um dessen Funktionalität zu ergänzen oder aufzuwerten. Alternativ können einzelne Module als Stand-Alone Auslieferung eine Teilfunktionalität des Gesamtsystems schon vorab zur Verfügung stellen.
Die Multilager-Architektur hat weiterhin den Vorteil einer schrittweisen Migration von einem bestehenden System. Diese Möglichkeit ist insbesondere für Anwender interessant, die Teile der Funktionalität ihres alten Systems aus Kompatibilitäts- oder Gewährleistungsgründen noch über einen gewissen Zeitraum weiter betreiben müssen.
Die vier Module bieten jeweils eine generische Funktionalität:
ATG-Editor 20 – Definition von Berechnungslogik
PEG-Editor 21 – Definition eines Stimulus und eines Experimentaldesigns
APV-Editor 22 – Editierung und Verwaltung von Parametern
Transformer Host Applikation 23 – Ausführen einer Berechnung,
die auch unabhängig von ihrer speziellen Integration in softwarebasierten Systemen nutzbar ist.
Aufgrund der starken Unabhängigkeit der Layer untereinander können spezialisierte Entwicklungsteams gebildet werden. Der Kommunikationsaufwand zwischen den Teams kann gering gehalten werden.
Performance-intensiven Anforderungen können gezielt Hardware-Ressourcen zugeteilt werden. Speziell unter Nutzung eines Cloud Computing Systems ist punktuell bei Bedarf ein Vielfaches der üblichen Rechenleistung einsetzbar. Es lässt sich beispielsweise das 50-fache einer üblichen PC Performance einsetzen. So lassen sich Berechnungszeiten drastisch reduzieren und gleichzeitig Hardware-Maintainance- und Anschaffungskosten einsparen. Teure Desktop-Systeme können speziell nach Anforderung konfiguriert und nach Bedarf eingesetzt werden.
Projektbeteiligte können von unterschiedlichen Orten aus unabhängig voneinander zusammen die verschiedenen Phasen einer Projektarbeit ausführen: Definition von Berechnungslogik, Definition eines Stimulus und eines Experimentaldesigns und Editierung und Verwaltung von Parametern. Es ist außerdem möglich, dass mehrere Projektbeteiligte gleichzeitig eine Projektphase bearbeiten. Beispielsweise kann die Erstellung der Projekt- und Stimulusdefinition (PEG-File 63) von mehreren Mitarbeitern und PCs aus gleichzeitig erfolgen. So können Produktionszeiten arbeitsintensiver Projektphasen durch einen höheren Personaleinsatz stark reduziert werden.
Die Transformer Host Applikation 23 ist für die tatsächliche Durchführung der Verarbeitung der Rohdaten verantwortlich. Dazu werden die in den drei vorangegangenen Layern erzeugten Konfigurationsdateien, nämlich ATG-File 33 und PEG-File 63, eingesetzt. 9 zeigt eine schematische Darstellung zur Anwendung der Transformer Host Applikation 23. Die Definition der Berechnungslogik (ATG) wird vor jeder Datenverarbeitung in eine aktuelle ATL.DLL 90 kompiliert. Die Berechnungslogik (ATG-File 33) steht der Transformer Host Applikation 23 im Rahmen des erzeugten Analysemoduls, also als ausführbarer Byte-Code (ATL.DLL) zur Verfügung, den diese dann zur Datenverarbeitung einsetzt. Die Transformer Host Application 23 verarbeitet Rohdaten 91, die in einer Testumgebung 82 mit einer Testperson 83 gewonnen werden, zu Metricsdaten 92. Die Metricsdaten 92 können in einer Präsentation 80 dargestellt werden. Die Präsentation 80 kann anschließend Nutzern 81, beispielsweise dem Auftraggeber der Analyse, vorgeführt werden (vgl. 8).
10 zeigt die Integration der ATL.DLL in den Verarbeitungsprozess der Transformer Host Applikation 23. Die Transformer Host Applikation 23 wird typischer Weise auf einem hochperformanten Applikationsserver (ggf. Cloud Computing) gehostet. Eine Kommunikation mit den Modulen APV-Editor 22, CAP.Conduction Scheduler 100 und CAP.Presentation 101 erfolgt über die in 10 dargestellten Eventschnittstellen. Der CAP.Conduction Scheduler 100 hat die Aufgabe, den Testablauf und die Datenerfassung zu kontrollieren. Nach der Vorgabe in den Projektdaten (PEG) liefert der CAP.Conduction Scheduler 100 beispielsweise die Aufgabenstellung in der Startposition für die Testaufgabe (beispielsweise eine URL) an die Testperson aus. Nach dem Abschluss einer Aufgabenbearbeitung informiert der CAP.Conduction Scheduler 100 die Transformer Host Applikation 23 über einen neu vorliegenden Rohdatensatz und löst damit Berechnungsschritte in der Transformer Host Applikation 23 aus. Die Berechnungsschritte innerhalb der Transformer Host Applikation 23 werden mit Hilfe der Processing Scheduler Komponente gesteuert. Nach der Abarbeitung eines Berechnungsschrittes informiert die Processing Scheduler Komponente den Datenvisualisierungs- und Reporting Layer des Systems, der daraufhin seine Darstellung unter Einbeziehung der neu berechneten Metricsdaten erneuert.
Das layer- und tier-übergreifende Eventsystem ist in Form von Web-Services implementiert.
Ein inkrementeller Berechnungsschritt der Transformer Host Applikation 23 beginnt mit einem Empfang des CAP.Conduction-Events 100 und endet mit der Versendung des CAP.Presentation-Update-Events 101. Der im Folgenden beschriebene Berechnungsprozess wird in der Praxis in maximal zwei Sekunden durchgeführt.
Das CAP.Conduction-Event 100 übergibt eine PEG-Referenz 102 einer im laufenden Testprojekt soeben abgeschlossenen Stimuluseinheit 103 (typischerweise eines Screens). Ein Processing-Scheduler 103 bezieht daraufhin die PEG-Definition des Screens aus dem PEG-File 63 des Projektes. Im nächsten Schritt werden die Berechnungsparameterwerte aus dem APV-File 73 geladen. Der entstandene Parameterdatensatz wird einem Collect-Modul 104 übergeben. Das Collect-Modul 104 übergibt der Eingabeschnittstelle der ATL.DLL den Eingabeparametersatz. Das Collect-Modul 104 erwartet als Ergebnis der Berechnung in der ATL einen sogenannten SubjectStimulusAggregate-Datensatz 105 (vgl. 12).
Eine sogenannte InputFactory 106 triggert das Laden des soeben im Testprojekt erzeugten Rohdatensatzes 91 des zu berechnenden Screens in die Berechnungslogik der ATL. Die Berechnungsmodule der ATL transformieren die Rohdaten aus dem EventData-Format zunächst in das EventCollect-Format, beispielweise mit Hilfe des Visit-Moduls 107 (vgl. 10).
11 zeigt die Formate EventData und EventCollect in tabellarischer Form. Darauffolgend wird mit Hilfe eines Aggregate-Moduls eine Aggregation der EventCollect-Daten zu den in dem ATG-File 33 definierten Metricsdaten durchgeführt. Der entstehende SubjectStimulus-Aggregate-Datensatz (vgl. 12) wird an das Collect-Modul zurück gegeben. Der SubjectStimulusAggregate-Datensatz hat im Vergleich zu den EventDate-Daten (vgl. 11) nur ein minimales Datenvolumen. Er wird im PersistData-Speichermodul in binärer Form zwischengespeichert.
Im nächsten Arbeitsschritt wird ein StimulusAggregate-Modul eingesetzt, um den SubjectStimulusAggregate-Datensatz zu einem StimulusAggregate-Datensatz zu aggregieren. Der SubjectStimulusAggregate- und der StimulusAggregate-Datensatz sind in 12 in tabellarischer Form dargestellt.
Im nächsten Schritt werden die für die Stimuluseinheit aggregierten Metricswerte in die ResultData Datenbank gespeichert. Nach Abschluss der Berechnung wird das Update Event an CAP.Analysis verschickt. Der aktive ReportClient lädt daraufhin die aktualisierten Datenwerte. Die Metricsdaten für die soeben im Testprojekt abgeschlossene Betrachtung eines Screens liegen somit aktualisiert im Datenreport vor.
Der Processing-Scheduler protokolliert die durchgeführten Berechnungsschritte in einem sogenannten Track-Memory-Modul. Mittels Zwischenspeichern der feingliedrigen Elemente des PEG-Files 63 und der gestaffelten Berechnungsphasen (EventData, EventCollect, SubjectStimulusAggregate und StimulusAggregate) ist auch nach einer Einstellungsveränderung im AVP-Modul nur selten eine komplette Neuberechnung der Daten nötig.
Nachfolgend wird der PEG-Editor 21 weiter erläutert.
Der PEG-Editor 21 ermöglicht die Erstellung des zentralen Projektkonfigurationsformates, nämlich des PEG-Files 63 eines Projektes. Der PEG-File 63 ist eine umfassende hierarchische Beschreibung des Testdesigns und des zu untersuchenden Stimulus. Die 13 und 14 zeigen den schematischen Aufbau und einen beispielhaften Anwendungsfall des PEG-Editors 21.
Das User Interface des PEG-Editors 21 ist in drei separate Editoren untergliedert, die gleichzeitig für den Benutzer sichtbar sind und ihm eine Erstellung und Bearbeitung des Projektentätätengraphen ermöglichen. Ein Treeview Editor 130 zeigt den hierarchischen Aufbau des Projektentitätengraphen. Über Drag & Drop- und Kontextmenüfunktionen hat der Benutzer die Möglichkeit, Knotenpunkte (Kodes) hinzuzufügen, zu löschen oder zu kopieren. Ein Node Editor 131 zeigt die Eigenschaftsparameter des aktuell ausgewählten Knotenpunkts und ermöglicht ihre Bearbeitung. Ein Canvas Editor 132 zeigt die räumliche Anordnung der definierten Stimulus Kodes (Items und Groups) und ermöglicht deren Bearbeitung.
Das Projektentitätenschema (PES) ist die Definition des PEG-Dateiformates. Zur Umsetzung der gestellten Entwicklungsziele wie Integration aller Projektkonfigurationen der verschiedenen Projektphasen in ein gemeinsames Format, Anwendbarkeit auf komplexe Studiendesigns, Standardisierung der Projektdefinition und Vergleichbarkeit über verschiedene Medien wird das Projektentitätenschema als eine umfangreiche Beschreibungssprache (Taxonomie) für Testdesigns und Medien konzipiert. Grundkonzept des PES ist die Anordnung aller an einer Projektdefinition beteiligten Elemente (Projektentitäten) in einem hierarchischen Graphen, sowie deren einheitliche Parametrisierung. Um eine Standardisierung über die vielseitigen Anwendungsfälle zu erreichen, werden Projektentitäten in Form von sieben abstrakten Klassen definiert: „Subject”, ”Task”, ”Setting”, ”ScreenGroup”, ”Screen”, ”ItemGroup” und ”Item”.
Der folgende Abschnitt gibt Definitionen und Beispiele für diese sieben Klassen. Der darauf folgende Abschnitt zeigt ein einheitliches Parametrisierungsschema für alle Projektentitätenklassen.
Ein „Subject” ist ein handelndes Individuum.
Ein „Task” ist eine induzierte (auch selbst-induzierte) Disposition die sich über einen Untersuchungszeitraum (Task-Zeitraum) auf ein Subject auswirkt. Ein Task beeinflusst (wie das Item) das Handeln der Testperson. Der Taskzeitraum ist klar durch ein Startereignis (”TaskStart”) und ein Endereignis (”TaskEnd”) begrenzt. Das TaskEnd Ereignis ist häufig an eine Aktion der Testperson gebunden. Das TaskStart Ereignis kann an eine Aktion der Testperson gebunden sein. Den Taskzeitraum erlebt die Testperson als eine Abfolge von Screens.
Während des Screen-Zeitraums, erlebt ein Subject eine Ansammlung von Items. Beispiele sind: Eine Testperson liest neuen Eintrag auf Einkaufszettel („TaskStart”), oder eine Testperson kauft ein Produkt bei amazon.com („TaskEnd”).
Eine Gruppe von „items” (über alle Tasks und Screens hinweg) die mit einer Gruppe von anderen (disjunkten) Items verglichen werden soll. Eine systematische Variation der Eigenschaften von Items, deren Auswirkung auf die Testperson untersucht werden soll. Die Items eines Settings sollten nie gleichzeitig (innerhalb eines Screens – besser noch Tasks) mit den Items eines anderen Settings auf die Testperson einwirken.
Eine „ScreenGroup” ist eine „Group”, deren Kinder (Items oder Groups) der Testperson alternativ dargeboten werden. Eine „ScreenGroup kann einem ConductionPresenter zugeordnet werden.
Ein modaler Ausschnitt in der Wahrnehmung der Testperson. Eine Gruppe von Items, die sich modal auf die Testperson auswirkt. Es ist keine (periphere) Wahrnehmung von Items in anderen Screens möglich. Während des Screenzeitraums erlebt ein „Subject” eine Ansammlung von Items, zum Beispiel eine Webpage, eine Magazindoppelseite oder einen TV-Clip (Bei der Unterteilung von zeitbasierten Medien muss die Dauer des auditiven und visuellen Puffers in der menschlichen Wahrnehmung beachtet werden – einzelne aufeinander folgende Bilder in einem Video sind (in der Wahrnehmung der Testperson) zueinander nicht modal.)
Eine „ItemGroup” ist eine „Group”, deren Kinder (Items oder Groups) der Testperson gleichzeitig dargeboten werden. „ItemGroups” können eine funktionale Struktur von Items realisieren (Menü, Wrap-Panel, Slide-Panel, etc). Ihr Effekt auf Items wird damit wahrnehmbar (sichtbar).
Ein „Item” ist ein Element des Stimulus, das sich auf die Testperson auswirkt. Ein Item kann einen Hyperlink enthalten, der im ConductionPresenter einen neuen Screen oder eine ScreenGroup aufruft.
Um die sieben PES-Klassen einheitlich zu parametrisieren, werden sie in zwei Gruppen aufgeteilt: „Items” (Item PES Klasse), „Groups” (Per Definition alle weiteren PES Klassen) und spezielle Groups (Setting und Task Klasse).
Die 15 und 16 zeigen schematische Darstellungen zur Parametrisierung von Items und Groups.
Das PEG-Schema ermöglicht die hierarchische Deklaration der Stimuluselemente. Instanzen von Stimuluselementen und Merkmalen können mit Hilfe von Gruppierungen oder der Tag-Property gekennzeichnet werden. Auf Basis PEG-Definition können umfangreiche Segmentierungen des Stimulus (horizontal und vertikal) vorgenommen werden. Im Zusammenspiel mit der ATG-Definition werden Bezüge zwischen Trackingdatenebenen und den definierten Stimuluselementen hergestellt.
Beispielsweise können für Stimuluselemente in einem Testprojekt „Point of Sale” mehrere Ebenen unterschieden werden:
Ebene 1:
Zur Untersuchung des urbanen Shopping-Verhaltens mit Hilfe von GPS-Tracking, können die zu untersuchenden Stimuluselernente mit Hilfe des PEG-Editors 21 definiert werden. Als Inhalt des Canvas Editors dient eine Stadtkarte des Untersuchungsbereichs.
Ebene 2:
Zur Untersuchung der Kundenbewegung innerhalb einer Verkaufspassage oder eines Shopping-Centers werden Schaufenster, Ladeneingänge und Leitsystem im PEG-Editor 21 definiert.
Ebene 3:
Innerhalb eines Marktes werden die unterschiedlichen Abteilungen und das Leitsystem des Marktes im PEG-Editor 21 definiert.
Ebene 4:
Innerhalb eines Regalganges werden Deckenhänger, Aufsteller und Regalsperrer definiert.
Ebene 5:
Für jedes Regal können weitere Untergruppen definiert werden: Regalsegment (Bay), Segmentebene (Base), Produktgruppe (SKU-Group) und Produkt (SKU).
Ebene 6:
Für jedes Produkt können die Verpackungselemente für die verschiedenen räumlichen Ansichten definiert werden.
Die in der vorstehenden Beschreibung, den Ansprüchen und der Zeichnung offenbarten Merkmale der Erfindung können sowohl einzeln als auch in beliebiger Kombination für die Verwirklichung der Erfindung in ihren verschiedenen Ausführungsformen von Bedeutung sein.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Nicht-Patentliteratur

http://www.w3.org/TR/xmlschema-1/-29 [0061]

Claims

Computergestütztes Verfahren zum Erzeugen eines softwarebasierten Analysemoduls für eine Analyse von elektronischen Rohdaten, die ein erfasstes Stimulus-Verhalten einer Testperson in einem Testprojekt repräsentieren, wobei das Verfahren die folgenden in einer Computereinrichtung ausgeführten Schritte umfasst: – Bereitstellen von Logikdaten, welche eine benutzerdefinierte Berechnungslogik repräsentieren, in einer auf der Computereinrichtung implementierten Anwendungssoftware, – Bereitstellen von Projektdaten, welche eine benutzerdefinierte Projektdefinition mit einer strukturierten Ordnung von Projektentitäten des Testprojektes repräsentieren, in der Anwendungssoftware, – Erzeugen von Projekteinstellparameterdaten, indem beim Zuordnen der Logikdaten zu. den Projektdaten die benutzerdefinierte Berechnungslogik den Projektentitäten zugeordnet wird und hieraus Projekteinstellparameter für die Projektentitäten des Testprojektes abgeleitet werden, – Bereitstellen der Projekteinstellparameterdaten für eine Datenausgabe über eine Benutzeroberfläche und Erfassen von zugeordneten Benutzereingaben für wenigstens einen Teil der Projekteinstellparameterdaten, und – Erzeugen eines Analysemoduls entsprechend der Logikdaten, der Projektdaten und der Projekteinstellparameterdaten, welches konfiguriert ist, elektronische Rohdaten, die ein erfasstes Stimulus-Verhalten einer Testperson in einem Testprojekt repräsentieren, zu empfangen und zum Analysieren des Verhaltens der Testperson zu verarbeiten.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Logikdaten und/oder die Projektdaten einer Graphenrepräsentation entsprechend bereitgestellt werden.
Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass der Schritt zum Erzeugen des Analysemoduls das Umwandeln der Logikdaten in Quelltextdaten sowie das Bereitstellen der Projekteinstellparameter mit zugeordneten Projekteinstellparameter-Werten umfasst.
Verfahren nach mindestens einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass die Logikdaten, die Projektdaten und/oder der Projekteinstellparameterdaten in einem XML-basierten Datenformat bereitgestellt werden.
Verfahren nach mindestens einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass der Schritt zum Erzeugen von Projekteinstellparameterdaten die folgenden Schritte umfasst: – Ableiten von Einstellparameterdaten aus den Logikdaten, indem die Logikdaten nach von ihnen umfassten Parameter untersucht werden, und – Zuordnen der Einstellparameterdaten zu den Projektentitäten des Testprojektes in den Projektdaten.
Verfahren nach mindestens einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass die Logikdaten zunächst als editierbare Ausgangslogikdaten bereitgestellt und mittels eines zugeordneten Editors hierauf bezogene Benutzereingaben erfasst werden, mit denen die Ausgangslogikdaten editiert werden.
Verfahren nach Anspruch 6, dadurch gekennzeichnet, dass mit dem Editor, welcher den Logikdaten zugeordnet ist, vordefinierte und vom Benutzer auswählbare Berechnungslogikbausteine bereitgestellt werden.
Verfahren nach mindestens einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass die Projektdaten zunächst als editierbare Ausgangsprojektdaten bereitgestellt und mittels eines zugeordneten Editors hierauf bezogene Benutzereingaben erfasst werden, mit denen die Projektdaten editiert werden.
Verfahren nach Anspruch 8, dadurch gekennzeichnet, dass der Editor, welcher den Projektdaten zugeordnet ist, mit einem oder mehreren Teileditoren bereitgestellt wird, die die folgenden Teileditoren umfassen: – einen Baum-Editor, welcher konfiguriert ist, eine hierarchische Struktur der strukturierten Ordnung der Projektentitäten anzuzeigen und hierauf bezogenen Benutzereingaben zu erfassen, – einen Knoten-Editor, welcher konfiguriert ist, Eigenschafts-Parameter eines aktuell ausgewählten Knotens der strukturierten Ordnung der Projektentitäten anzuzeigen und hierauf bezogenen Benutzereingaben zu erfassen, und – einen Canvas-Editor, welcher konfiguriert ist, eine räumliche Anordnung von Knoten der strukturierten Ordnung der Projektentitäten anzuzeigen und hierauf bezogenen Benutzereingaben zu erfassen.
Verfahren nach mindestens einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass die Projekteinstellparameterdaten für hierdurch repräsentierte Projekteinstellparameter jeweils Metadaten umfassen, die wenigstens eine Datenart ausgewählt aus der folgenden Gruppe von Datenarten umfasst: – Wertebereichsempfehlungsdaten, – Wertebereichsbeschränkungsdaten, – Kommentardaten, – Prioritätsdaten, – Control-Typdaten, – Gruppierungs-, Filter- und/oder Sortierdaten und – Verweisdaten zum Verweisen auf Hilfefunktionen.
Verfahren nach mindestens einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass das Analysemodul konfiguriert wird, beim Verarbeiten der Rohdaten das Verhalten der Testperson repräsentierende Metricsdaten zu erzeugen.