User-Toolkits zur dienstbasierten
                 Entwicklung mobiler Applikationen


                             Peter ...
Ein Weg der Risikominimierung liegt in einer Optimierung des Entwicklungsprozesses,
wie sie in zum Beispiel in [Dor03] vor...
Die Gesamtplattform besteht einerseits aus der Logik zur Konstruktion und Ausführung
und andererseits aus einer Kommunikat...
Bekannte Beispiele für visuelle Programmiersprachen sind LabView von National
Instruments [NI03], das besonders für den Be...
Dienste: Dienste fassen immer eine Menge an Funktionalität einer spezifischen Domäne
zusammen. Da in unserem System Dienst...
Location-Services: Der Location-Service lokalisiert einen spezifizierten Benutzer. Der
Rückgabewert ist die Benutzerpositi...
Es wird keinerlei Aussage über den Zeitpunkt der Ausführung getroffen. Der
Ausführungszeitpunkt wird autonom vom Interpret...
3. Beispielapplikation
An einem Beispiel wollen wir den Toolkit veranschaulichen. Abbildung 4 zeigt den
Dienst „Schwiegerm...
Abbildung 4: Beispielapplikation für einen „Schwiegermutter-Warner“



In der bereits vorliegenden Implementierung des Too...
Literaturverzeichnis
[Dor03] Peter Dornbusch, Martin Huber, Matthias Möller, Rapid Prototyping of mobile
        Applicati...
Upcoming SlideShare
Loading in...5
×

ZüRich Ii Mobile App Final V3

1,043

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,043
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

ZüRich Ii Mobile App Final V3

  1. 1. User-Toolkits zur dienstbasierten Entwicklung mobiler Applikationen Peter Dornbusch, Martin Huber CDTM - Center for Digital Technology and Management Arcisstraße 21 - 80290 München dornbusc@in.tum.de; huber@cdtm.de Abstract: Die erfolgreiche Entwicklung und Einführung neuer mobiler Applikationen stellt besondere Herausforderungen an die Kosteneffizienz der Dienst-Entwicklung und die Identifizierung bzw. Befriedigung von Kundenbedürfnissen. Klassische Prozesse der Software-Entwicklung können diese Anforderungen oftmals nicht erfüllen. In dem vorliegenden Papier wird ein Framework vorgestellt, dass durch Integration des Kunden und eine modulare Systemarchitektur eine effiziente Entwicklung ermöglicht. Dabei konfigurieren Nutzer die Zusammenstellung und das Zusammenspiel von verschieden Basisdiensten und generieren dadurch neue Dienste. Durch Community- Funktionen können die von einzelnen Nutzern entwickelten Applikationsideen weiteren Nutzern verfügbar gemacht werden. In einem evolutionären Prozess können diese Dienste durch Beiträge aus der Gemeinschaft der Nutzer weiter verbessert werden. Die verschiedenen Iterationen innerhalb des nutzerdominierten Entwicklungsprozesses stehen dem Nutzer unmittelbar zur Verfügung, so dass durch diverse Anpassungen (Personalisierung) der Basisdienste und der Ablauflogik (Workflow-Engine) Schritt für Schritt eine erfolgreiche und kundenoptimal gestaltete Anwendung entsteht. Aufgrund der modularen Architektur, die sich auf Basisdienste stützt und einer davon abstrahierten Ablauflogik, kann das Framework leicht um weitere Basisdienste ergänzt werden und ist damit offen für Erweiterungen. 1. Einleitung Seit der Versteigerung der UMTS-Lizenzen und den damit verbundenen hohen Investitionen, versuchen die Mobilfunk- und Serviceprovider mögliche „Killer“- Applikation zu identifizieren. Allerdings stellen die hohen Kosten der Konzeption, Entwicklung und Markteinführung einer neuen mobilen Applikation und die Ungewissheit des Markterfolges erhebliche Barrieren dar. Erste ernüchternde Ergebnisse einiger Mobilfunkbetreiber zeigen, dass bei neu eingeführten mobilen Applikationen - entwickelt mit klassischen Methoden wie zum Beispiel Marktforschung - die Wahrscheinlichkeit eines Markterfolges aufgrund verfehlter Kundenbedürfnisse äußerst gering ist.
  2. 2. Ein Weg der Risikominimierung liegt in einer Optimierung des Entwicklungsprozesses, wie sie in zum Beispiel in [Dor03] vorgeschlagen wird. Insbesondere Werkzeug- unterstütztes Rapid Prototyping kann hilfreich bei einer frühzeitigen Kosten/Nutzen- Analyse sein. Das vorliegende Papier stellt eine Alternative bzw. eine Ergänzung vor, die durch Integration der Nutzer in den Entwicklungsprozess und einem Framework bestehend aus Basisdiensten und einer Workflow-Engine (Ablauflogik) eine schnelle und kosten- günstige Realisierung mobiler Applikationen ermöglicht. Durch die frühzeitige Kundenintegration ist sichergestellt, dass die Bedürfnisse der Kunden optimal befriedigt werden können und der Dienst damit eine hohe Wertschätzung und Zahlungsbereitschaft bei den Nutzern hervorruft. In einer ersten Implementierung ist unser Framework bereits für die prototypische Umsetzung von neuen Anwendungsideen einsetzbar. Für eine Umsetzung und Skalierung auf ein Live-System von Netz- bzw. Servicebetreibern müssen noch weitere Integrationsaspekte gelöst werden. Die Integration des Nutzers bei der Realisierung neuer Innovationen haben u.a. von Hippel [Hi01] und Thomke [Th02] im Bereich von materiell ausgeprägten Produkten sehr ausführlich untersucht. Dabei konnte gezeigt werden, dass die Integration des Nutzers in den Entwicklungsprozess, insbesondere bei „sticky information“, also schwer explizierbaren Informationen zu den Kundenbedürfnissen, sehr vorteilhaft ist. Außerdem zeigen Untersuchungen im Bereich von Open–Source-Software-Projekten [Fr01], [Le00], [He02], dass die Fähigkeit der schnellen Iteration von Dienstversionen und Community-Mechanismen Entwicklungsvorhaben beschleunigen können und zu besserer Qualität führen. Daneben konnte gezeigt werden, dass für innovative Technologien die „technology adoption“ bei der Markteinführung durch frühzeitige Kundenintegration deutlich beschleunigt werden kann und damit die Wahrscheinlichkeit für einen Markterfolg erhöht wird. Unser Framework ermöglicht mit wenigen, aber leistungsfähigen Basisdiensten eine Vielzahl von Applikationen. Im folgenden Kapitel stellen wir die Gesamtarchitektur unseres Systems vor. Anschließend beschreiben wir die einzelnen Basisdienste und veranschaulichen unser Konzept an einem Beispiel. 2. Technisches Konzept Der oben erläuterte Grundgedanke, den Nutzer bzw. Kunden (auch den technisch weniger versierten) die Möglichkeit zu geben an der Entwicklung einer mobilen Applikation mitwirken zu lassen, stellt hohe Anforderungen an die Benutzerschnittstelle und die Einfachheit eines solchen Konzepts.
  3. 3. Die Gesamtplattform besteht einerseits aus der Logik zur Konstruktion und Ausführung und andererseits aus einer Kommunikationsplattform zur Diskussion und Evaluierung der kreierten Applikationen. Jede Applikation, die von einem Benutzer erzeugt wurde, kann freigeschaltet und der Community zur Weiterentwicklung zur Verfügung gestellt werden. Ein Versionskontrollsystem und ein mit dem Applikation verknüpftes „schwarzes Brett“ erlauben eine koordinierte Zusammenarbeit in der Community. Abbildung 1 stellt die einzelnen Schichten unserer Architektur dar. Die Community- Komponente wird aus Gründen der Übersichtlichkeit hier nicht dargestellt. Benutzer- definierte Applikationen werden aus einer Menge von Basisdiensten zusammengestellt. Die Ausführung der einzelnen Applikationen ist an Ereignisse geknüpft. Ein Event- Handler überwacht kontinuierlich eingehende Ereignisse und stößt ggf. die ent- sprechende Anwendung an. Ein Ereignis kann hierbei zum Beispiel an ein Zeitintervall oder aber an eine Benutzeroberfläche auf dem Endgerät gekoppelt sein. Als Basisdienste sind in der Abbildung beispielhaft Module für SMS (Short Messaging Service), MMS (Multimedia Messaging Service), DB (Datenbank) und LES (Location Enabling Service) ausgewählt, die in der Applikationsschicht kombiniert werden. Endgerät GUI HTTP FTP SMS MMS Event Handler Applikationsschicht Basisdienste LES SMS MMS DB … Abbildung 1: Gesamtarchitektur mit Endgerät (Nutzer/Kunde) und Anbietersystem 2.1 Visuelle Konstruktion Um ein User-Toolkit zu realisieren, welches intuitiv von einem nicht technik-affinen Nutzer bedient werden kann, haben wir Elemente visueller Programmiersprachen (VP) aufgegriffen. VPs verwenden als Basis graphische Symbole. Diese Symbole werden dann in Graphen als Knoten oder Kanten eingesetzt. In [SIF96] wird eine visuelle Programmiersprache definiert als [...] eine formale Sprache mit visueller Syntax oder visueller Semantik zur vollständigen Beschreibung der Eigenschaften von Software. Syntax und Semantik visueller Programmiersprachen beziehen meist den zwei- oder dreidimensionalen Raum ein, während verbale Programmiersprachen auf eindimensionalen Zeichenketten beruhen.
  4. 4. Bekannte Beispiele für visuelle Programmiersprachen sind LabView von National Instruments [NI03], das besonders für den Bereich der Mess- und Regelungstechnik verbreitet ist und Lego Mindstorms, zur Programmierung kleiner aus Lego(-Technik) gebauten Robotern, das in Zusammenarbeit von Lego und dem Massachusetts Institute of Technology (MIT) entwickelt wurde [LEGO], [Sey93]. Letztere wurde entwickelt, um Kindern ohne Vorkenntnisse spielerisch das Erlernen einer Programmiersprache zu ermöglichen und zeigt, dass mit visuellen Programmiersprachen in bestimmten Domänen tatsächlich Programmierung leichter vermittelt werden kann. Die positiven Erfahrungen von Lego Mindstorm, als intuitiv bedienbare Programmiersprache, die es auch Nutzergruppen ohne Vorkenntnisse ermöglicht, Aufgaben zu übernehmen, die klassischerweise die Kenntnisse einer formalen Programmiersprache voraussetzen, kann für User-Toolkits fruchtbar eingebracht werden. LabView hingegen ist eine datenflussorientierte Programmiersprache; ein Konzept an dem sich auch das hier vorgestellte Framework orientiert. 2.2 Sprachelemente Unser Ansatz für eine visuelle Sprache ist so einfach wie möglich gehalten, da mit User- Toolkits insbesondere Applikationen kreiert werden sollen, die eine (Re-)Kombination bestehender Basisdienste sind und keine hohe Mächtigkeit der visuellen Sprache erfordern. Der innovative Charakter der Applikation, der durch den User über das Toolkit eingebracht wird liegt hier mehr in den Kundenbedürfnissen, den marktlichen Aspekten und den unterschiedlichen Nutzungskontexten. [Hau97] spricht in diesem Zusammenhang zum einen von zweckinduzierten Innovationen, die mit bestehenden Mitteln, also einer bestehenden technischen Dienstplattform, einen neuen Zweck, also eine neue Applikation, erfüllt. Zum anderen von inkrementalen Innovationen, bei denen Mittel und Zweck zwar prinzipiell unverändert bleiben, jedoch durch neuartige Kombinationen oder inkrementelle Verbesserungen im Endergebnis eine deutliche Steigerung erreicht werden kann. Auf mobile Anwendungen übertragen bedeutet dies, dass die technische Plattform (Basisdienste) unverändert bleibt, jedoch durch geringfügige Änderungen oder neuartige Kombinationen eine deutliche Verbesserung der Applikation erreicht werden kann. Die Sprache besteht aus Diensten, bedingten Anweisungen, zusätzlichen Funktionen und Konstanten. Schleifen in Form von Graphzyklen sind nicht möglich, um die Komplexität der Sprache gering zu halten und damit auch mögliche Fehlerquellen bei der Programmierung durch Nutzer mit wenig Programmierkenntnissen auszuschließen. Im Folgenden werden die Merkmale der Sprachelemente kurz diskutiert: Abbildung 2 Graphische Repräsentation eines Basis-Dienstes
  5. 5. Dienste: Dienste fassen immer eine Menge an Funktionalität einer spezifischen Domäne zusammen. Da in unserem System Dienste keine Zustände haben, bestehen Dienste aus einer Menge von Methoden. Abbildung 3: Graphische Repräsentation einer Bedingung (if distance) mit bedingtem Dienst (SMS-Service) Bedingte Anweisungen: Diese sind nah an die Basisdiensten angelegt. Abstrakte bedingte Anweisungen sind nicht möglich. Zum Beispiel stellen ortsbezogene Bedingungen die Verknüpfung der Ortsfunktion mit einem Vergleich dar. Bedingte Kommunikation überprüft beispielsweise, ob das entsprechende Postfach des Benutzers eine oder mehrere SMS, MMS oder E-Mails enthält. Zusätzliche Funktionen: Dazu gehören arithmetische Funktionen und String-Operatoren. Konstanten: Alle Dienst- und Funktionseingänge können auch mit Konstanten belegt werden. 2.3 Basisdienste Im Folgenden führen wir für ein besseres Verständnis des Konzeptes einige Basisdienste auf, die bereits realisiert wurden: SMS/MMS: Diese beiden Dienste stellen in erster Linie die Möglichkeit bereit, SMS bzw. MMS an ein anzugebendes Endgerät zu verschicken. Dazu ist es nötig, den Empfänger und den Nachrichteninhalt zu spezifizieren. Eine weitere Aufgabe ist der Abruf empfangener Nachrichten. Telefon (Sprachdienst): Der Telefondienst verbindet zwei Teilnehmer miteinander, indem die Sprachkanäle zweier Teilnehmer zusammengeschaltet werden. In der Kommunikationstechnik ist eine Telefonverbindung im Allgemeinen nicht zustandslos, sondern es werden hier unterschiedliche Zustände, wie Verbindungsaufbau, Warten auf Verbindungsannahme usw. unterschieden. Da unser System zustandslos ist, wartet der Dienst bis beide Teilnehmer erfolgreich verbunden wurden. Etwaige Störungen bei der Etablierung der Verbindung verarbeitet in diesem Fall die Ablauflogik.
  6. 6. Location-Services: Der Location-Service lokalisiert einen spezifizierten Benutzer. Der Rückgabewert ist die Benutzerposition angegeben durch Längen- und Breitengrad. E-Mail: Wie bei SMS/MMS muss hier auch der Empfänger spezifiziert werden, wobei bei einem E-Mail-Dienst dies über eine entsprechende Adresse geschieht. Ebenso kann eine Überschrift und ein Nachrichtentext angegeben werden. Buddy-List (Kontakt-Liste): Eine Buddy-List ist vergleichbar mit einem privaten Telefonbuch. Nutzerinformationen: Das Ergebnis dieses Dienstes sind nähere Informationen über einen bestimmten Nutzer. 2.4 Konfiguration Um individuelle Laufzeitparameter zu spezifizieren, wird zu jeder entworfenen Applikation, immer auch eine Konfiguration erstellt. Zum Beispiel wird in der Entwurf- phase ein User nur abstrakt in die Anwendung eingebunden. Welcher Benutzer aber tatsächlich gemeint ist, wird erst in der Konfiguration bestimmt, um den Entwurf von der eigentlichen Anwendung zu trennen und damit eine bessere gemeinschaftliche Entwick- lung in der Community zu ermöglichen. Für ein intuitives Verständnis durch den Nutzer kann die abstrakte Modellierung aber mit einer konkreten Konfiguration belegt werden. 2.5 Ausführung Die Ausführung übernimmt eine Workflow-Engine, die registrierte Ereignisse verwaltet. Die Workflow-Engine kann unterschiedliche realisiert sein und soll hier nur in den prägenden Eigenschaften beschrieben werden. Wenn ein Ereignis eintritt, wird die ent- sprechende Applikation ausgeführt. In der jetzigen Implementierung können Ereignisse ausgelöst werden, wenn ein bestimmter Zeitpunkt erreicht ist oder aber eine Nachricht (SMS, Email, etc) eingegangen ist. Da es sich bei den Anwendungen/Programmen um einfache Graphen handelt, ist die Ausführungslogik ebenfalls sehr einfach. 2.5.1 Methodenaufrufe Damit eine Methode ausgeführt werden kann, müssen drei Bedingungen erfüllt sein: 1. Alle benötigten Parameter dieser Funktion müssen mit einem entsprechenden Rückgabewert einer anderen Methode belegt sein. 2. Alle eingehenden Parameter einer Methode müssen bereits gesetzt sein. Dass bedeutet, dass Quellfunktionen bzw. Dienste bereits ausgeführt wurden. 3. Ist die Methode innerhalb einer Bedingung, so muss die Bedingung erfüllt sein. Nur wenn die Bedingungen erfüllt ist, kann eine Methode ausgeführt werden.
  7. 7. Es wird keinerlei Aussage über den Zeitpunkt der Ausführung getroffen. Der Ausführungszeitpunkt wird autonom vom Interpreter bestimmt. 2.5.2 Beenden der Ausführung Zur Beendigung einer Applikation kommt es, wenn sich kein Dienst mehr ausführen lässt. Dies ist der Fall, wenn entweder tatsächlich alle Dienste ausgeführt wurden oder aber wenn ein Dienst nicht mehr ausgeführt werden kann, weil die Eingangsparameter nicht gesetzt sind oder gesetzt werden können. 2.5.3 Ausführung eines Programms Zur Ausführung wird auf Zyklenfreiheit geprüft und dann Sequentialisiert. : Überprüfung auf Zyklenfreiheit: Um die prinzipielle Ausführbarkeit des Programms zu gewährleisten, muss sichergestellt werden, dass der entstandene Graph G zyklenfrei ist. Dies bedeutet in diesem Zusam- menhang, dass kein Dienst (Knoten des Graphen) direkt oder indirekt von sich selbst abhängig sein darf. Dazu wird für jeden Teilgraph des Graphen überprüft, ob er nach dieser Festlegung zyklenfrei ist. Trifft dies für alle Knoten von G zu, so ist auch G zyklenfrei. Um einen einzelnen Dienst zu überprüfen, muss man zuerst feststellen von welchen anderen Knoten dieser abhängig ist. Hierbei gibt es zwei unterschiedliche Arten von Abhängigkeit. Ist festgestellt worden, dass keine Zyklenabhängigkeiten vorhanden sind, so muss überprüft werden, ob das Programm ausgeführt werden kann. Um die Ausführung einer Instanz zu gewährleisten, müssen alle benötigten Parameter mit einem Wert belegt sein. Sequenzialisierung: Um das Programm ausführen zu können, muss der zuvor aufgebaute Graph sequentiali- siert werden. Dies ist nötig, da nicht allen benutzten Instanzen gleich von Anfang an ihre benötigten Parameter zur Verfügung stehen, sondern diese teilweise erst von anderen bereitgestellt werden müssen. Um mögliche Startpunkte für die Ausführung zu erhalten, werden zunächst einmal alle Instanzen gesucht, die keinerlei Abhängigkeiten von an- deren aufweisen und die nicht das Ziel einer Wertzuweisung oder eine bedingte Instanz sind. Diese Startpunkte können nun direkt ausgeführt werden, bzw. sind die, die als erstes ausgeführt werden müssen. Danach wird für jede Instanz, die nicht zu dieser ersten Gruppe gehört, überprüft, ob alle ihre Parameter von einem Dienst stammen, der zu der Gruppe der Startpunkte gehört. Ist dies der Fall, so kann der Dienst ausgeführt werden und wird zu den bereits Ausgeführten hinzugefügt. Im anderen Fall wird einfach mit dem nächsten Dienst fortgefahren und der gerade geprüfte wird wieder an den Schluss der Sequenz angehängt. Für bedingte Dienste muss ferner noch überprüft werden, ob sie aufgrund der Bedingung ausgeführt werden können oder nicht, das heißt, ob die Bedingung erfüllt ist oder nicht. Dies wird nun solange wiederholt, bis alle Dienste ausgeführt sind. Dadurch ergibt sich eine mögliche – nicht eindeutige - Reihenfolge für die Ausführung.
  8. 8. 3. Beispielapplikation An einem Beispiel wollen wir den Toolkit veranschaulichen. Abbildung 4 zeigt den Dienst „Schwiegermutter-Warner“. In der Entwurfssicht finden sich die einzelnen Basis- dienste und die Nachrichtenflüsse zwischen den Basisdiensten. Zwei Benutzer werden lokalisiert und ihr Abstand zueinander wird bestimmt. Wenn die Benutzer sich näher als 500 m kommen, wird an einen der Benutzer eine SMS gesendet. In der Konfiguration wird nun noch spezifiziert, um welche Nutzer es sich handelt. In unserem Fall ist es beispielsweise der Nutzer (also der Dienstentwickler) selbst und dessen Schwiegermutter. Wie schon anhand dieser schematischen Beispielapplikation deutlich wird, wirken sich schon inkrementelle Änderungen der Ablauflogik (z.B. Änderung des Radius von 500m auf 3km) auf die Charakteristik der mobilen Applikation aus. Durch einen vielfältigen „Trial and Error“ Prozess durch den Nutzer bzw. die Gemeinschaft der Nutzer und die evolutionäre Weiterentwicklung der Applikationsidee kann so nach mehreren Iterationen eine marktfähige und den Kundenbedürfnissen entsprechende Applikation geschaffen werden [Hi01]. Bei der Gestaltung des „Trial and Error“ Prozesses muss abgewogen werden, welche Freiräume und welche Restriktionen zugelassen werden, um einerseits einen großen Möglichkeitsraum zu gewährleisten, andererseits den Prozess sowohl für den Kunden als auch den Betreiber, insbesondere hinsichtlich der anfallenden Kosten, attraktiv zu machen. Die (Wertschöpfungs-)Beiträge innerhalb des Entwicklungs- prozesses kommen dabei maßgeblich vom Kunden/Nutzer und ermöglichen so für einen Anbieter eine veränderte Kostenstruktur für die Realisierung neuer mobiler Applikationen. In der Betriebswirtschaft wurde u.a. von Ramirez [Ram99] unter dem Begriff der “value co-production“, in ähnlichem Kontext die Vorteilhaftigkeit der Kundenintegration sehr breit diskutiert.
  9. 9. Abbildung 4: Beispielapplikation für einen „Schwiegermutter-Warner“ In der bereits vorliegenden Implementierung des Toolkits (Abbildung 4) kann das „Look-and-Feel“ der Benutzeroberfläche in unterschiedlichen Designs und mit verschiedenen Beschriftungen gestaltet werden, um eine intuitiv zugängliche und nutzerfreundliche Benutzerschnittstelle zu realisieren. 4. Fazit und Ausblick In dem vorliegenden Papier haben wir einen ersten Entwurf für einen User-Toolkit zur mobilen Applikationsentwicklung vorgestellt. In der jetzigen Phase ist vor allem noch nicht geklärt, wie entwickelte Anwendungen in den Normalbetrieb migriert werden können. Dies soll im Zuge eines 2004 anlaufenden Forschungsprojektes zusammen mit einem Industriepartner aus dem Bereich ISP bearbeitet werden. Dennoch steht bereits zum jetzigen Zeitpunkt ein mächtiges Tool zur Verfügung, welches die Möglichkeiten und Grenzen eines Toolkits für die Entwicklung mobiler Applikationen skizziert.
  10. 10. Literaturverzeichnis [Dor03] Peter Dornbusch, Martin Huber, Matthias Möller, Rapid Prototyping of mobile Applications, Proceedings of 8th International Workshop on Mobile Multimedia Communications, 2003 (to appear) [Fr01] Egon Franck, C. Jungwirth, Open versus Closed Source, Working Paper No. 4, Universität Zürich, 2001 [Hau97] Hauschildt, J.: Innovationsmanagement. Franz Vahlen Verlag, München, 2. Auflage, 1997 [He02] Joachim Henkel,Open Source Software from Commercial Firms – Tools, Complements, and Collective Invention, Discussion Paper No. 02-27, German Economic Association of Business Adminsitration, 2002 [Hi01] Von Hippel, E.: Perspective: User Toolkits for Innovation, The Journal of Product Innovation Management Vol. 18, pp. 247-257., 2001 [Le00] Josh Lerner, Jean Tirole, The Simple Econimics of Open Source, Harvard Business School, 2000 [LEGO] Lego, http://mindstorms.lego.com, 2003 [NI] National Instrument, http://www.ni.com, 2003 [SIF96] Stefan Schiffer, Visuelle Programmierung - Potential und Grenzen, 1996 [Ra99] Ramirez, R.: Value Co-Production: Intellectual Origins and Implications for Practice and Research, Strategic Management Journal, Vol. 20, pp. 49-65., 1999 [Th02] Thomke, S. and von Hippel, E.: Customers as Innovators: A new Way to Create Value, Harvard Business Review, Vol. 80, No. 2., 2002
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×