Pflichtenheft - Berner Fachhochschule

Pflichtenheft
Mobile DMS-Datenerfassung
DMS Datenerfassung
Abstract
Die bestehende Software-Suite
Suite der Firma GCS soll um eine mobile Komponente basierend auf
Windows Mobile ergänzt werden. In dieser Arbeit steht dabei eine Technologie-Studie
Studie für den
Datenaustausch zwischen mobilem Gerät und Server im Zentrum.. Anhand eines Prototyps wird die
Umsetzbarkeit geprüft.
Schlüsselwörter: Windows Mobile, .NET Compact Framework, SQL Server Compact, Webservices,
DMS – Dealer Management System
Master Thesis Nr.:
Datum:
Version:
MAS-07--01.07
28.04.2009
.04.2009
1.0
Student:
Philipp Buser, Unterm Stallen 5, 4104 Oberwil
P: 079 708 37 94
[email protected]
G: 061 726 97 44
[email protected]
Betreuer:
Reto Dellenbach, Mühlemattstrasse 24a, 4104 Oberwil
G: 061 726 97 45
[email protected]
Experte:
Rolf Wenger, Steingrübliweg 8a, 3072 Ostermundigen
G: 079 820 61 29
[email protected]
Projekt
Seite
Mobile DMS-Datenerfassung
Datenerfassung
Autor
Datum
Version
Dokument
Philipp Buser
28.04.2009
1.0
Pflichtenheft
2(29)
Änderungsnachweis
Version
Beschreibung der Änderung
Datum
Autor(en)
0.1
Erste (provisorische) Version
17.04.2009
Philipp Buser
0.2
Glossar eingefügt
Kontextdiagramm (s. 8) eingefügt
Aktivitätsdiagramm (s. 17) eingefügt
Einige Schreibfehler korrigiert
20.04.2009
Philipp Buser
0.3
Adresse Experte aktualisiert
Kapitelüberschrift „Begriffe und Abkürzungen“ statt
„Glossar und Akronyme“,
Akronyme“ Tabelle aktualisiert
Kapitel 1.4 leicht gekürzt
Nicht-Ziele
Ziele in Kapitel 2.3 ergänzt
Meilensteine aktualisiert
Einige Anpassungen in Kapitel 2.6.1.
Liste der nicht benötigten Punkte in Kapitel 2.6.1
entfernt
Kapitel 4 vollständig überarbeitet
Prioritätenliste aktualisiert
Abschnitt Unit Test in Kapitel 6.1 geändert
Projektplan aktualisiert
24.04.2009
Philipp Buser
1.0
Genehmigte und eingereichte Version
28.04.2009
Philipp Buser
Projekt
Mobile DMS-Datenerfassung
Datenerfassung
Autor
Datum
Version
Dokument
Philipp Buser
28.04.2009
1.0
Pflichtenheft
Seite
3(29)
Inhaltsverzeichnis
1
................................
..................................... 4
Allgemeines ................................................................................................................................
1.1
Zweck des Dokumentes................................................................................................
........................................... 4
1.2
Zielgruppe des Dokumentes................................................................................................
.................................... 4
1.3
Umfang der Master Thesis ................................................................................................
...................................... 4
1.4
Umfeld ................................................................................................................................
................................
..................................... 4
1.5
Begriffe und Abkürzungen................................................................................................
....................................... 6
1.6
Quellenverzeichnis ................................................................................................
................................
.................................................. 7
2
Gesamtüberblick ................................................................................................
................................
............................................................. 8
2.1
Produktumfeld ................................................................................................
................................
........................................................ 8
2.2
Ziel des Auftraggebers ................................................................................................
........................................... 10
2.3
Ziel der Master Thesis ................................................................................................
........................................... 10
2.4
Meilensteine ................................................................................................
................................
.......................................................... 11
2.5
Vorgesehene Erweiterungen ................................................................................................
................................. 12
2.6
Rahmenbedingungen ................................................................................................
................................
............................................ 12
2.6.1
Zielsystem Mobiles Gerät ..............................................................................................
.............................. 12
2.6.2
Zielsystem Server................................................................................................
Server
........................................... 13
2.6.3
Entwicklungssystem ................................................................................................
...................................... 14
3
Technologie-Studie ................................................................................................
................................
........................................................ 15
3.1
Grundlagen ................................................................................................
................................
............................................................ 15
3.2
Datenaustausch / Kommunikation ................................................................
........................................................ 15
3.3
Spracherkennung ................................................................................................
................................
.................................................. 16
4
Detaillierte Anforderungen ................................................................................................
........................................... 17
4.1
Use Cases ...............................................................................................................................
................................
............................... 17
4.1.1
Aufgabe erledigen ................................................................................................
......................................... 18
4.1.2
Auftrag bearbeiten ................................................................................................
........................................ 20
4.1.3
Kunde kontaktieren ................................................................................................
....................................... 22
4.2
Funktionale
tionale Anforderungen ................................................................................................
.................................. 23
4.3
Nicht funktionale Anforderungen ................................................................
......................................................... 24
5
Übersicht und Prioritäten ................................................................................................
................................
.............................................. 25
5.1
Technologie-Studie ................................................................................................
................................
................................................ 25
5.2
Prototyp................................................................................................................................
................................
................................. 26
6
Vorgehen und Zeitplan ................................................................................................
................................
.................................................. 27
6.1
Tests ................................................................................................................................
................................
...................................... 27
6.2
Projektplan ................................................................................................
................................
............................................................ 28
7
Risiken und Kosten ................................................................................................
................................
........................................................ 29
7.1
Risiken ................................................................................................................................
................................
................................... 29
7.2
Kosten ................................................................................................................................
................................
.................................... 29
Projekt
Mobile DMS-Datenerfassung
Datenerfassung
Autor
Datum
Version
Dokument
Philipp Buser
28.04.2009
1.0
Pflichtenheft
Seite
4(29)
1 Allgemeines
1.1 Zweck des Dokumentes
Das vorliegende Pflichtenheft bildet die Grundlage zur Master Thesis „Mobile DMS-Datenerfassung“.
DMS
Es dient als Leistungsvereinbarung einerseits zwischen dem Auftraggeber (Herr Dellenbach,
Geschäftsführer der Firma GCS Garage
G
& Carrosserie System GmbH) und dem internen
Auftragnehmer (Philipp Buser),, und anderseits – da dieses Projekt im Rahmen einer Master
Ma
Thesis an
der Berner Fachhochschule (BFH) durchgeführt wird – zwischen der BFH (vertreten durch Herrn
Wenger) und Philipp Buser als Diplomanden.
Diplomanden
Der Zweck ist es, die Aufgabenstellung und die Anforderungen einfach und präzis zu beschreiben.
Anhand von
n Diagrammen und Prosa wird die zugrundeliegende Idee vermittelt,
vermittelt, die Anforderungen
werden priorisiert und das Vorgehen wird festgelegt.
1.2 Zielgruppe
elgruppe des Dokumentes
Dieses Dokument richtet sich primär an den Experten, an den Betreuer und Auftraggeber und an den
Autor dieser Arbeit. Selbstverständlich
lbstverständlich sind auch andere interessierte Personen willkommen, das
Pflichtenheft zu lesen. Grundkenntnisse im Software-Engineering
Software Engineering können fürs Verständnis von
Vorteil sein.
Das Dokument ist in Deutsch gehalten, dort wo es jedoch
jedoch sinnvoll erschien, wurden die englischen
Originalbegriffe verwendet.
1.3 Umfang der Master Thesis
Diese Arbeit bildet den Abschluss des MAS-Studiums
MAS Studiums „Master of Advanced Studies in Information
Technology“. Sie umfasst 12 ECTS Punkte, was einem Arbeitsaufwand von 360 Stunden entspricht,
und dauert sechs Monate.
Lieferobjekte
• Pflichtenheft
• Prototyp (Source Code, Applikation)
• Dokumentation (Bericht)
1.4 Umfeld
Die Firma GCS Garage & Carrosserie System GmbH
Die GCS Garage & Carrosserie System
Sys
GmbH (kurz GCS) mit Sitz in Oberwil BL ist Partner von Garagen
und Carrosseriebetrieben im Informatik Umfeld. Sie ist der Auftraggeber dieser Arbeit. Sie wurde
2006 gegründet und erhält zu diesem Zeitpunkt von der Firma KSR die Vertriebsrechte des gesamten
Produkteportfolio
ukteportfolio für die Deutschschweiz. Vorher (seit 2003) wurde dieses Portfolio durch die Firmen
EurotaxGlass's und it kompetenzkompetenz & dienstleistungscenter gmbh in der Schweiz vertrieben.
Die damals bestehenden
enden rund 400 Installationen wurden
wu
in einer gemeinsamen
amen Übergangszeit von
beiden Firmen (EurotaxGlass’s und GCS) betreut. Danach wurden den Kunden einen Umstieg auf die
Linien von GCS angeboten.
Seither vertreibt und installiert GCS die Software-Produkte
Software
von KSR in der Schweiz, betreut und
unterstützt die Kunden bei ihrer Arbeit damit und bietet Support und Helpdesk. Mit diversen
Eigenentwicklungen im SchnittstellenSchnittstellen und Add-on-Bereich
Bereich schliesst GCS die Lücken im Schweizer
Markt, die von der deutschen KSR nicht abgedeckt werden.
Allgemeines
Projekt
Mobile DMS-Datenerfassung
Datenerfassung
Autor
Datum
Version
Dokument
Philipp Buser
28.04.2009
1.0
Pflichtenheft
Seite
5(29)
Die Firma KSR EDV-Ingenieurbüro
eurbüro GmbH
Die Grundsteine der Firma wurden bereits 1989 gelegt und sie entwickelte sich seither von einer 22
Mann-Garagen-Firma
Firma zu einem marktführenden Unternehmen mit rund 3000 zufriedenen Kunden
Ku
in
Deutschland, Österreich und der Schweiz, die heute mit KSR-Produkten
Produkten arbeiten, die
kundenindividuell aus Grundprogramm und Erweiterungsmodulen zu einem massgeschneiderten
Paket zusammengestellt werden können. 1997 erfolgte die Gründung der Firma KSR EDVEDV
Ingenieurbüro GmbH (kurz KSR) mit einer 25%-Beteiligung
25%
der Firma Eurotax AG in Freienbach
(Schweiz). Heute zählt KSR mit Firmensitz in Bibertal bei Ulm (Deutschland) zu den führenden
Anbietern von Management-Software.
Software.
Die Firma EurotaxGlass’s International AG
EurotaxGlass’s International AG (kurz EurotaxGlass’s) ist der europaweit grösste Anbieter von
entscheidungsrelevanten Informationen, Lösungen und Business Intelligence Services für die
Automobilwirtschaft. Die Firma EurotaxGlass’s resultierte aus der Fusion zwischen Eurotax AG und
Glass's Information Services Limited und hat ihre Unternehmenszentrale in Freienbach bei Zürich.
EurotaxGlass’s ist in 30 Ländern mit 660 Mitarbeitern aktiv. Bekannt ist EurotaxGlass’s vor allem
durch ihre Bewertungs- und Schadenskalkulationsdaten.
GCS arbeitet bereits seit Beginn sehr eng mit EurotaxGlass's zusammen. In allen GCS-Produkten
GCS
sind
die Eurotax-Programme
Programme voll integriert.
Allgemeines
Projekt
Mobile DMS-Datenerfassung
Datenerfassung
Autor
Datum
Version
Dokument
Philipp Buser
28.04.2009
1.0
Pflichtenheft
Seite
6(29)
1.5 Begriffe und Abkürzungen
Begriff
ADO.NET
APS
DMS
DPI
EKS
GCS
GPRS
GSM
HSDPA
IIS
JPS
KSR
MSF
OS
PDA
RDA
RFID
Beschreibung
ADO.NET ist ein Teil der von Microsoft entwickelten .NET-Plattform.
Plattform. Es handelt
sich um eine Sammlung von Klassen, die den Zugriff auf relationale
ionale Datenbanken
gewährleisten. ADO.NET gilt als Nachfolger der ActiveX Data Objects (ADO).
Auto Planing System, ein GCS Software-Produkt
Software
Dealer Management
Managemen System
Ein Dealer-Management
Management-System ist ein IT-System, welches Autohäuser bei der
Abwicklung aller anfallenden
a
Geschäftsprozesse unterstützt.
Dots per inch, Punkte pro Zoll, Masseinheit für die Angabe von Auflösungen
Elektronisches Kassensystem, ein GCS-Software-Produkt
GCS
GCS Garage und Carrosserie System GmbH
General Packet Radio Service
GPRS (deutsch: „Allgemeiner paketorientierter Funkdienst“) ist ein
paketorientierter Dienst zur Datenübertragung, welcher in GSM Netzen
verwendet wird.
Global System for Mobile Communications
GSM ist ein Standard für volldigitale Mobilfunknetze,, der hauptsächlich für
Telefonie,, aber auch für leitungsvermittelte und paketvermittelte
Datenübertragung sowie Kurzmitteilungen genutzt wird.
High Speed Downlink Packet Access
HSDPA, auch als 3.5G, 3G+ und UMTS-Broadband
UMTS Broadband vermarktet, ist ein
Übertragungsverfahren des Mobilfunkstandards
Mob
UMTS. Das Verfahren ermöglicht
DSL-ähnliche
ähnliche Übertragungsgeschwindigkeiten im Mobilfunknetz (abhängig von
der Qualität der Funkverbindung 3,6 bis 13,98 MBit/s) und macht damit den
Download von großen Datenmengen (etwa Spielen, Filmen, etc.) ohne KabelKabel
oder WLAN-Verbindung
Verbindung möglich.
möglich
Internet Information Services
IIS ist eine Diensteplattform der Firma Microsoft für PCs und Server.
Server Über sie
können Dokumente und Dateien im Netzwerk zugänglich gemacht werden.
werd Als
Kommunikationsprotokolle kommen zum Beispiel HTTP, HTTPS oder FTP zum
Einsatz.
Job Planing System, ein GCS Software-Produkt
Software
KSR EDV-Ingenieurbüro
Ingenieurbüro GmbH
Microsoft Sync Framework
MSF ist eine umfangreiche Synchronisierungsplattform, die Zusammenarbeit und
Offlinezugriff für Anwendungen, Dienste und Geräte ermöglicht.
Operating System, Betriebssystem
Personal Digital Assistant
Ein PDA ist ein kompakter, tragbarer Computer,, der neben vielen anderen
Programmen hauptsächlich für die persönliche Kalender-,, AdressAdress und
Aufgabenverwaltung benutzt wird.
wird
Remote Database Access
Ein ISO/OSI-Standard
Standard zur Verteilung von Datenbankoperationen
Datenbankoperationen in heterogenen
verteilten Systemen.
Radio Frequency Identification
Der englische Begriff „Radio Frequency Identification“ bedeutet im Deutschen
Allgemeines
Projekt
Mobile DMS-Datenerfassung
Datenerfassung
Autor
Datum
Version
Dokument
Philipp Buser
28.04.2009
1.0
Pflichtenheft
Begriff
SAPI
SDK
SQL
UMTS
Use Case
VCS
VGA
VIS
VTS
Webservice
WLAN
Seite
7(29)
Beschreibung
„Identifizierung
Identifizierung mit Hilfe von elektromagnetischen Wellen“.. RFID ermöglicht die
automatischen Identifizierung und Lokalisierung von Gegenständen und
erleichtert damit erheblich die Erfassung und Speicherung von Daten.
Daten
Speech Application Prorgramming Interface
SAPI ist eine Schnittstelle zur Anbindung von Bibliotheken zur Sprachsynthese
und Spracherkennung unter dem Betriebssystem Microsoft Windows.
Windows
Software Development Kit
Ein SDK ist eine Sammlung
Sammlung von Programmen und Dokumentationen zu einer
bestimmten Software,
Software die es Softwareentwicklern erleichtern bzw. erst
ermöglichen soll, eigene darauf basierende Anwendungen
Anwendungen zu erstellen.
erstellen
Structured Query Language
SQL ist eine Datenbanksprache zur Definition, Abfrage und Manipulation von
Daten in relationalen Datenbanken.
Datenbanken
Universal Mobile Telecommunications System
UMTS steht für den Mobilfunkstandard der dritten Generation (3G), mit dem
deutlich höhere Datenübertragungsraten
Datenübertragungsraten (384 kbit/s bis 7,2 Mbit/s) als mit dem
Mobilfunkstandard der zweiten Generation (2G), dem GSM-Standard
Standard (9,6 kbit/s
bis 220 kbit/s), möglich sind.
sind
Ein Anwendungsfall,
Anwendungsfall, auch im Deutschen eher unter dem englischen Ausdruck Use
Case bekannt, definiert ein Verhalten zwischen Akteuren und dem betrachteten
System, die stattfindet, um ein bestimmtes fachliches Ziel zu erreichen.
Vehicle Calculation System, ein GCS Software-Produkt
Software
Video Graphics Array
VGA bezeichnet einen Computergrafik-Standard,
Standard, der bestimmte Kombinationen
von Bildauflösung und Farbanzahl sowie Wiederholfrequenz definiert.
definiert
Vehicle Inhouse System, ein GCS Software-Produkt
Software
Vehicle Trading System, ein GCS Software-Produkt
Software
Ein Webservice oder Webdienst ist eine Software-Anwendung,
Anwendung, die mit einem
Uniform Resource Identifier (URI) eindeutig identifizierbar ist und deren
Schnittstelle als XML-Artefakt
Artefakt definiert, beschrieben und gefunden werden kann.
Ein Webservice unterstützt die direkte Interaktion mit anderen Software-Agenten
unter Verwendung XML-basierter
XML basierter Nachrichten durch den Austausch über
internetbasierte Protokolle.
Wireless LAN, Wireless Local Area Network
WLAN bezeichnet ein „drahtloses“,
„
lokales Funknetz,, wobei meistens ein
Standard der IEEE-802.11-Familie
IEEE
gemeint ist.
1.6 Quellenverzeichnis
Chris Rupp & die SOPHISTen, Requirements-Engineering
Requirements
und Management, 4. Auflage, Hanser 2007,
ISBN: 978-3-446-40509-7
Ian Sommerville,
erville, Software Engineering, 8. Auflage, Pearson Studium 2007,
2007, ISBN: 978-3-8273-7257-4
978
PM-HANDBUCH.COM,
HANDBUCH.COM, Kostenloser Leitfaden für Projektmanager, http://www.pm-handbuch.com
http://www.pm
MSDN, Microsoft Developer Network, http://msdn.microsoft.com
Wikipedia, Diee freie Enzyklopädie,
Enzyklopädie http://www.wikipedia.org
Allgemeines
Projekt
Mobile DMS-Datenerfassung
Datenerfassung
Autor
Datum
Version
Dokument
Philipp Buser
28.04.2009
1.0
Pflichtenheft
Seite
8(29)
2 Gesamtüberblick
2.1 Produktumfeld
System besteht aus mehreren Produkten und Komponenten, die je nach
Das Dealer-Management-System
Bedarf und Anforderung auch einzeln eingesetzt werden können:
VTS (Vehicle Trading System): Das System für die Gebrauchtfahrzeugvermarktung. Zu jedem
Fahrzeug das in einer Garage steht, gibt es eine Fülle von Informationen die einmal in das VTS
eingeben werden müssen und dann immer sofort abrufbar sind, wenn ein Kunde Interesse an einem
Angebot zeigt. Die Kunden
n haben in der Regel ganz spezielle Vorstellungen wie ein zukünftiges
Fahrzeug aussehen soll. Mittels SQL Datenbank und einer ausgefeilten Suchfunktion kann
kan in
Sekundenschnelle eine Liste aller Fahrzeuge, die den Wünschen des Kunden entsprechen,
entsprechen erzeugt
werden. Kunden, die sich nicht im Einzugsgebiet befinden,, erreicht man über den einfachen Upload
des Fahrzeugangebots auf die Homepage und zu Automobilbörsen wie zum Beispiel
Beispie Autoscout24.
Sobald ein Kunde sich
ich für eines oder mehrere
me
Fahrzeuge entschieden hat, können im Handumdrehen
Gesamtüberblick
Projekt
Mobile DMS-Datenerfassung
Datenerfassung
Autor
Datum
Version
Dokument
Philipp Buser
28.04.2009
1.0
Pflichtenheft
Seite
9(29)
alle Verträge sowie Dokumente erstellt werden, die für den erfolgreichen Abschluss des Geschäfts
und zur Übergabe der Fahrzeuge im AnA und Verkauf benötigt werden.
VCS (Vehicle Calculation System): Das
as Kalkulationssystem für Karosseriefachbetriebe. VCS stellt die
Möglichkeit zur Verfügung, auf Informationen über alle Aufträge, Fahrzeuge und Kontakte des
Kunden zugreifen zu können (Kundenhistorie). Diese Ausgangslage ermöglicht es,
es schnellstmöglich
auf die Belange eines Kunden einzugehen. Die Auftragskostenermittlung
Auftra
kann sofort nach der
Fahrzeugbesichtigung mit Hilfe des Kalkulationsmoduls des Datenlieferanten erledigt und das
Ergebnis in Form eines Kostenvoranschlags entweder persönlich oder aus dem VCS
VCS heraus per Fax
F
oder Email an den Kunden übermittelt werden.
VIS (Vehicle Inhouse System): VIS vereint die Funktionen der Programme VCS für den
Werkstattbereich und VTS für den Fahrzeughandel so, dass diese auf eine KundenKunden bzw.
Fahrzeugdatenbank zurückgreifen
greifen können. Durch ein ausgefeiltes ZugriffsZugriffs und Rechtemanagement
Rechteman
können jedem Mitarbeiter nur die Programmfunktionen und Informationen zur Verfügung gestellt
werden, die sich in dessen Aufgabenbereich befinden. Der standortübergreifende Einsatz des VIS
VI ist
zum Beispiel unter Zuhilfenahme des Microsoft Windows Terminal Server zu bewerkstelligen.
Abgerundet wird die Software durch den Einsatz der Schnittstellen zur Finanzbuchhaltung,
Betriebsdatenerfassung InTime2000
2000 sowie dem Werkstattannahme- und Planungssystem
ngssystem JPS.
JPS VIS
stellt damit das zentrale Produkt in der GCS-Softwareumgebung
GCS
dar.
APS (Auto Planing System): Das Annahme-,
Annahme Auftrags- und Mietwagenplanungssystem. APS ist für alle
Karosserie-, Lackierfach- und Kfz-Betriebe
Kfz Betriebe sowie Autohäuser geeignet. Ziel ist eine Optimierung der
Kundenannahme, Ersatzfahrzeugverplanung und die Steigerung der Kundenzufriedenheit. Es wird
eine hohe Terminsicherheit erreicht und Wartezeiten
Wartezeiten werden verkürzt oder sogar vermieden. Durch
die optionale Erweiterung mit dem Reifenservice ist das APS auch interessant für alle Betriebe, die
für Ihre Kunden Reifen einlagern bzw. damit handeln. Eine detaillierte KundenKunden und
Fahrzeugverwaltung mit allen
llen hierzu gehörenden Daten und Dokumenten, sowie einem TerminTermin und
Kontaktmanagement mit automatischem Wiedervorlagesystem erleichtert die notwendigen
Verwaltungsaufgaben
altungsaufgaben in hohem Masse.
Mass
JPS (Job Planing System): Das Service-,
Service Annahme- und Werkstattplanungssystem.
ungssystem. JPS dient für die
Planung und Organisation der Kundendienstannahme, der Werkstatt und des TeileTeile und
Zubehörlagers, sowie aller übrigen Bereiche des Betriebes inklusive der externen Zuarbeiten durch
andere Betriebe. Es gibt einen schnellen Überblick
Überblick über freie Werkstattkapazitäten unter
Berücksichtigung von Urlaubs-,, Krankheits-,
Krankheits Schulungs- und anderer Ausfallzeiten der Mitarbeiter. In
Verbindung mit entsprechenden Zeitmodellen ist eine gleichmässige Werkstattauslastung die Folge.
Darüber hinaus erhält man die nötige Flexibilität für z.B. einen unvorhersehbaren Einsatz des
Personals oder anderer Betriebsressourcen. Der schnelle und detaillierte Überblick über schon
eingeplante Service-Termine
Termine erleichtert zudem die Entzerrung der Auftragsannahme und
u der
Werkstattdurchlaufzeiten. Komplette Vorgänge können von der Annahme bis zur
Fahrzeugauslieferung und Rechnungsstellung geplant, überwacht/kontrolliert bzw. gesteuert
werden.
Das heisst: mit
it diesem Programm arbeitet die (Telefon-)Zentrale,
(Telefon
die Kundendienstannahme,
ndienstannahme, der
Werkstattmeister, eventuell sogar die Werkstattmitarbeiter,
Werkstattmitarbeiter die Buchhaltung (Rechnungsstellung)
(Rechnungsstel
und das Management.
Gesamtüberblick
Projekt
Mobile DMS-Datenerfassung
Datenerfassung
Autor
Datum
Version
Dokument
Philipp Buser
28.04.2009
1.0
Pflichtenheft
Seite
10(29)
EKS (Elektronisches Kassensystem): EKS ist ein Zusatzprogramm für die GCS FakturaFaktura und
Lagersysteme. Es übernimmt die Aufgaben einer Kasse in einem Betrieb. EKS ist für alle Karosserie-,
Karosserie
Lackierfach-, Kfz-Betriebe
Betriebe und Autohäuser geeignet. Dabei ist es unerheblich, ob die Zahlung durch
Bargeld oder mit einer EC-, VISA--, Master- oder American Express-Karte erfolgt.
europa3000: Die Business Software von europa3000 steuert die Debitoren-,, Kreditorenverwaltung
und die Finanzbuchhaltung zur GCS-Gesamtlösung
GCS
bei.
InTime2000: InTime2000 ist ein BetriebsdatenBetriebsdaten und Zeiterfassungssystem.
2.2 Ziel des Auftraggebers
Garagen und Carrosseriebetrieben,
iebetrieben, die mit den oben beschriebenen Produkten arbeiten, soll mit
einer mobilen Datenerfassungssoftware die Möglichkeit geboten werden, ihre Werkstattplanung
Wer
noch einen weiteren Schritt zu digitalisieren und automatisieren.
Motivation
Was waren die Überlegungen, den Schritt zu mobilen Geräten zu wagen, wo doch damit so
offensichtliche Nachteile wie kleine Displays und damit schlechtere Bedienbarkeit
eit oder mangelnde
Robustheit verbunden sind?
Ein erster Punkt ist natürlich der, dass mit diesem Projekt im Rahmen einer Master Thesis dem
Auftraggeber kaum Kosten entstehen und das Risiko somit relativ klein ist.
ist
Der Grundgedanke ist aber ein anderer: Der
D Auftraggeber hat bei seinen Kunden den Trend
beobachtet, dass sie für Informatikmittel
Informatik
immer weniger zu investieren
en bereit sind.
sind Hier könnte die
Mehrfachverwendung von mobilen Geräten
Geräte eine Chance sein:
•
•
•
•
oder haben muss, kann damit dann auch
Ein Verkäufer, der sowieso ein Geschäftshandy hat oder
noch seine Daten erfassen und zurückmelden.
Das Handy mit der Geschäftsapplikation kann einem Mitarbeiter auch für private Zwecke
Zweck zur
Verfügung gestellt werden (z.B. als Lohnbestandteil oder anstelle einer Lohnerhöhung).
Lohnerhöhung
Ein Mitarbeiter installiert die Applikation auf seinem privaten Handy und verwendet es
(gegen ein Entgelt) im Betrieb.
usw.
Das bedeutet:
•
•
•
Es muss keine
eine doppelte Investition in Hardware getätigt werden.
Es bleibt mehr
ehr Budget für
fü Software (auf Hardware gibt es kaum mehr Marge).
Marge)
Die Bereitschaft
eitschaft etwas auszuprobieren ist grösser,, wenn nicht extra Hardware gekauft
werden muss bzw. wenn die Hardware auch für Anderes
A
(z.B.
z.B. im privaten Bereich)
verwendet werden kann.
2.3 Ziel der Master Thesis
Es soll eine Applikation
ation mit dem Windows Mobile SDK für Geräte mit Windows Mobile 6.0/6.1
Betriebssystem erstellt werden, welche die bestehende DMS-Software-Suite
DMS
Suite von GCS um eine mobile
Komponente ergänzt. Der Fokus richtet sich jedoch nicht unbedingt auf die Applikation selbst,
sel
sondern auf die Untersuchung und Ausarbeitung der Grundlagen für die Kommunikation und den
Datenaustausch zwischen
en der DMS-Lösung
DMS
und dem mobilen Gerät. Anhand
hand eines vertikalen
Prototyps im Bereich vom Job Planing System (JPS) soll dann die Umsetzbarkeit
eit geprüft werden.
Gesamtüberblick
Projekt
Seite
Mobile DMS-Datenerfassung
Datenerfassung
Autor
Datum
Version
Dokument
Philipp Buser
28.04.2009
1.0
Pflichtenheft
Projektteilziele
11(29)
Ergebnisse
Geräteauswahl
•
2 mobile Testgeräte
Anforderungen und Anwendungsfall des Prototyps
definieren
•
Pflichtenheft
Windows Mobile SDK sowie .NET Compact
Framework kennenlernen
•
Kleine Testanwendung
Möglichkeiten des Datenaustausches untersuchen
- Webservices
- Datenbank Merge-Replikation
Replikation
- Datenbank Remote-Datenzugriff
Datenzugriff
- Sync Services for ADO.NET
•
Technologie-Studie,
Studie,
Softwarearchitektur
Prototyp für den Anwendungsfall implementieren
•
Funktionierender Prototyp
Optional: Spracherkennung evaluieren und allenfalls
implementieren
•
Prototyp mit Sprachunterstützung
Dokumentation erstellen
•
Bericht
Nicht-Ziele
Es ist nicht das Ziel eine fertige, einsatzfähige Applikation
Applikation zu erstellen.
Dementsprechend ist auch kein Benutzerhandbuch o.ä. zu schreiben.
Eine webbasierte Lösung
L
wird nicht verfolgt,, damit für zukünftige
Erweiterungen keine Einschränkungen bestehen.
Wirkung / Nutzen
Grundlage für weitere Entwicklung. Prototyp als Machbarkeitsstudie sowie
als Demonstrationsobjekt für zukünftige Kundenbefragungen.
Projektphasen /
Hauptaufgaben
1.
2.
3.
4.
5.
Einarbeitung und Anforderungen
Technologie-Studie
Analyse und Entwurf
Entwicklung und Verifikation
Dokumentation
2.4 Meilensteine
Nr.
Meilenstein
Termin
MS 1
Projektstart
MO, 09.03.2009
MS 2
Projektauftrag liegt vor
FR, 20.03.2009
MS 3
Anforderungen festgelegt, Abgabe Pflichtenheft
DO, 23.04.2009
MS 4
Pflichtenheft bestätigt
FR, 08.05.2009
MS 5
Technologie-Studie
Studie abgeschlossen
FR, 10.07.2009
MS 6
Entwicklung und Verifikation abgeschlossen
MS 7
Abgabe Bericht
FR, 10.09.2009
MS 8
Präsentation und Projektende
FR, 11.09.2009
Gesamtüberblick
MO, 04.09.2009
Projekt
Mobile DMS-Datenerfassung
Datenerfassung
Autor
Datum
Version
Dokument
Philipp Buser
28.04.2009
1.0
Pflichtenheft
Seite
12(29)
2.5 Vorgesehene Erweiterungen
Der Prototyp,, wie er anhand der funktionalen Anforderungen in Kapitel 4.2 beschrieben ist, wird
nach Projektabschluss primär mal als Umfrage- und Demonstrationsobjekt dienen und
u zudem in
einem Pilotprojekt eingesetzt werden, um die Akzeptanz bei den Kunden zu überprüfen und um
Feedback einzuholen. Danach wird über weiterführende Entwicklungsschritte entschieden.
entschieden
Das Endziel wäre, die komplette Werkstattkarte, die zurzeit noch auf Papier geführt wird,
elektronisch
ronisch auf dem mobilen Gerät
Ger abzubilden. Dies beinhaltet die Zeiterfassung, die Auswahl und
Rückmeldung der verbauten Ersatzteile, verschiedene Checklisten zur Unterstützung, usw.
2.6 Rahmenbedingungen
Es soll wo immer möglich mit den aktuellsten Technologien und Produkten gearbeitet werden. Es
sind dies:
•
•
•
•
•
•
Windows Mobile 6.1 Professional
.NET Framework 3.5
.NET Compact Framework 3.5
SQL Server 2008
SQL Server Compact 3.5
Visual Studio 2008 Professional Edition
Die Hardware- und Softwareanforderungen an das mobile Gerät, an den Server und an das
Entwicklungssystem sind in den folgenden Unterkapiteln beschrieben.
2.6.1 Zielsystem Mobiles Gerät
Zusammen mit dem Auftraggeber sind
s die folgenden Muss-Anforderungen
Anforderungen an das mobile Gerät
definiert worden:
•
•
•
Windows Mobile Betriebssystem
Wir konzentrieren uns auf Geräte mit
mi Windows Mobile Betriebssystem.. Die aktuelle Version
6.0 oder 6.1 wird bevorzugt, je nachdem kommt auch noch die Version
Version 5.0 in Frage.
Der Einsatz von WindowsWindows und .NET-Technologien
Technologien in der Firma GCS hat Tradition. Die
gesamte Software-Produktpalette
Produktpalette basiert darauf. Deshalb kommen für den Auftraggeber nur
windowsbasierte Systeme in Frage und auf die Evaluation von Geräten
Geräten mit Symbian-OS
Symbian
oder
Palm-OS,
OS, etc. wird vollständig verzichtet.
Mit Windows Mobile sehen wir zudem die Möglichkeit, dass sowohl professionelle Geräte
wie auch bei Bedarf eine Vielzahl von einfacheren und günstigeren Smartphones oder PDA‘s
PD
zum Einsatz kommen
ommen können.
Windows Mobile 6.0/6.1
/6.1 ist die aktuellste Betriebssystem-Version.
Betriebssystem Version. Die Version 6.5 sollte
Mitte Jahr, Windows Mobile 7.0 dann gegen Ende Jahr auf den Markt kommen.
Touchscreen
Die Applikation muss über einen Touchscreen (per Finger oder Stift)
Stift) bedient werden können.
Unser Zielgerät wird deshalb mit Windows Mobile 6 Classic oder Professional ausgerüstet
sein, wohingegen Windows Mobile 6 Standard für Geräte ohne Touchscreen zum Einsatz
kommt.
Grosses Farbdisplay
Für die Praxistauglichkeit und Akzeptanz
Akzeptanz des Gerätes spielt das Display sicherlich eine
massgebende Rolle. Displaygrössen ab 2.8 Zoll kommen in Frage.
Gesamtüberblick
Projekt
Mobile DMS-Datenerfassung
Datenerfassung
Autor
Datum
Version
Dokument
Philipp Buser
28.04.2009
1.0
Pflichtenheft
•
•
•
Seite
13(29)
Auflösung: mindestens 240x320
240x
Pixel
Um die geplanten Funktionalitäten benutzergerecht darstellen zu können, wird eine
möglichst hohe Auflösung benötigt.
benötigt. Ideal wäre wohl VGA (480x640 Pixel).
Pixel)
Wireless-LAN: IEEE 802.11b (11 MBit/s) oder IEEE 802.11g (54 MBit/s).
Der Datenaustausch zwischen mobilen Gerät und Server erfolgt vorzugsweise über WLAN, in
Ausnahmefällen natürlich auch über GSM/GPRS.
WLAN stellt zurzeit die beste Möglichkeit dar, in einem überschaubaren Gebiet die drahtlose
Kommunikation kostengünstig zu gewähren.
Robustes Gehäuse oder zumindest Schutzhülle erhältlich
Das Umfeld, in welchem die zu entwickelnde Applikation auf dem mobilen Gerät eingesetzt
werden soll, sind Autowerkstätten, Garagen
Garage und Carrosserie-Betriebe.
etriebe. Also ein Umfeld, in
welchem das Gerät auch mal mit schmutzigen Händen bedient wird, oder es vom Tisch fallen
kann. Deswegen soll das Gerät einigermassen stabil und robust sein.
Optionale Anforderungen zur Erhöhung der Funktionalität oder für eine bessere Betriebsstabilität
sind:
•
•
•
•
Sender/Empfänger
RFID-Sender/Empfänger
Für spätere Anwendungsfälle, die jedoch nicht Bestandteil von diesem Projekt sind, könnte
die RFID-Technologiee durchaus zum Einsatz kommen.
Barcode-Leser
Ebenfalls für weitere Anwendungsfälle einsetzbar.
GSM/GPRS/UMTS/HSDPA
Die Nutzung der klassischen Mobilfunktechnologien
Mobilfunktechnologien macht auf jeden Fall als Alternative zum
WLAN Sinn und bieten auch die Möglichkeit, das mobile
mobile Gerät von extern oder für andere
Zwecke zu verwenden.
Akku und Ladestation
Der Batterie bzw. der Akkudauer sollte ebenfalls Aufmerksamkeit beigemessen werden.
Zudem sollte der Akku problemlos ausgewechselt werden können, falls er mit der Zeit
schwächer wird. Grundsätzlich sind Akkus mit langer Betriebs- und Standbyzeit, schnelle
Wiederaufladung und langer Lebensdauer zu bevorzugen. Idealerweise gibt es zum Gerät
eine Ladestation in welcher es versorgt
ve
und geladen werden kann.
2.6.2 Zielsystem Server
Ein DMS-Server besteht – nebst den GCS-Programmen
GCS
– typischerweise aus folgender Software:
•
•
•
•
Windows Server 2003 oder 2008
SQL Server 2008
.NET Framework 3.5
Internet Information Services (IIS) 6.0 oder 7.0
Für Kleinstkunden, die ohne Server-Betriebssystem
Server
arbeiten, kann jedoch auch folgende
Konfiguration zum Einsatz kommen:
•
•
•
•
Windows XP Professional
SQL Server 2008 Express Edition with Advanced Services
.NET Framework 3.5
Internet Information Services (IIS) 5.1
Gesamtüberblick
Projekt
Mobile DMS-Datenerfassung
Datenerfassung
Autor
Datum
Version
Dokument
Philipp Buser
28.04.2009
1.0
Pflichtenheft
2.6.3 Entwicklungssystem
Das zur Verfügung stehende Entwicklungssystem weist folgende Software auf:
•
•
•
•
•
•
•
•
Windows XP Professional
SQL Server 2008 Express Edition with Advanced Services
.NET Framework 3.5
Internet Information Services (IIS) 5.1
Visual Studio 2008 Professional Edition
Windows
ndows Mobile 6 Professional SDK
Enterprise Architect 7.5
ActiveSync 4.5
Gesamtüberblick
Seite
14(29)
Projekt
Mobile DMS-Datenerfassung
Datenerfassung
Autor
Datum
Version
Dokument
Philipp Buser
28.04.2009
1.0
Pflichtenheft
Seite
15(29)
3 Technologie-Studie
Studie
Der Entwicklung des Prototyps geht eine Technologie-Studie
Technologie
voraus. Dabei sollen verschiedene
Aspekte untersucht werden, die im Folgenden kurz beschrieben sind.
3.1 Grundlagen
Als erstes geht es darum, die Grundlagen für die Applikationsentwicklung für Windows Mobile zu
erarbeiten. Die Ergebnisse werden nur soweit dokumentiert, wie sie für dieses Projekt relevant sind.
Windows Mobile SDK und .NET Compact Framework [Req: TS001]
Es soll untersucht werden, welche Funktionen und Möglichkeiten aber auch welche Einschränkungen
das Windows Mobile Software Development Kit und das .NET Compact Framework 3.5 bietet,
bietet
insbesondere natürlich im Hinblick auf den zu entwickelnden Prototyp.
Pr
. Dazu wird eine kleine
Testanwendung erstellt, mit der auch die Handhabung des Deployments aufs mobile Gerät getestet
werden kann.
SQL Server Compact [Req: TS002]
02]
Das Ziel in diesem ersten Schritt ist die Installation des SQL Server Compact auf dem mobilem Gerät,
sowie das Abrufen von Daten in der Datenbank aus der Testanwendung heraus.
3.2 Datenaustausch / Kommunikation
Das Schwergewicht dieser Technologie-Studie
Technologie
liegt auf der Untersuchung der verschiedenen
Möglichkeiten des Datenaustausches zwischen mobiler Applikation und der serverbasierten
Datenbank. Dazu kommen die im Folgenden beschriebenen Technologien und Verfahren in Frage,
deren Sachverhalt und Praxistauglichkeit
Praxistauglichkeit in Bezug auf die Anforderungen des Prototyps überprüft
und bewertet werden sollen. Es gilt auch die Konsequenzen auf die Applikationslogik, auf den
Programmieraufwand und auf die Performance zu untersuchen.
Webservices [Req: TS003]
Im mobilen Bereich ist die Aufrechterhaltung der Verbindung über langsame, teure und
unzuverlässige Netze oftmals problematisch. Bei der Arbeit mit Webservices und anderen
Netzwerkprotokollen, die eigentlich für Breitbandverbindungen designt wurden, stellt das eine
Herausforderung dar. Das .NET Compact Framework erlaubt es angeblich auf einfache Weise, die
Verwendung der existierenden Webservice-Technologie
Webservice Technologie auf mobile Geräte auszudehnen.
SQL Server Merge-Replikation [Req: TS004]
T
Die Merge-Replikation stellt gemäss Microsoft eine robuste Lösung mit vollem Funktionsumfang dar,
die einer mobilen Anwendung ermöglicht, autonome Änderungen an replizierten Daten
vorzunehmen und diese Änderungen zu einem späteren Zeitpunkt mit einer Microsoft SQL ServerServer
Datenbank zusammenzuführen
usammenzuführen sowie gegebenenfalls auftretende Konflikte zu lösen.
SQL Server Remote-Datenzugriff
Datenzugriff [Req: TS005]
Eine mobile Anwendung kann per Remote-Datenzugriff
Remote Datenzugriff auf einfache Weise auf Daten in entfernt
gespeicherten Microsoft SQL Server-Datenbanktabellen
Server
en und lokalen SQL Server MobileMobile
Datenbanktabellen zugreifen (Pull-Vorgang)
(Pull Vorgang) und Daten an diese Datenbanktabellen senden (Push(Push
Vorgang). Mit RDA können ebenfalls SQL-Befehle
SQL Befehle auf einem Server ausgegeben werden, auf dem SQL
Server ausgeführt wird.
Technologie-Studie
Projekt
Mobile DMS-Datenerfassung
Datenerfassung
Autor
Datum
Version
Dokument
Philipp Buser
28.04.2009
1.0
Pflichtenheft
Seite
16(29)
Sync Services for ADO.NET [Req: TS006]
T
Sync Services for ADO.NET ist ein Teil von Microsoft Sync Framework (MSF). Sync Framework ist eine
umfassende Synchronisierungsplattform, die Zusammenarbeit und Offlinezugriff für Anwendungen,
Dienste und Geräte ermöglicht. Es stellt Technologien und Tools für Roaming, Freigabe und
Offlinebereitstellung von Daten zur Verfügung. Mithilfe von Sync Framework können Entwickler
synchronisierte heterogene Systeme erstellen, die beliebige Anwendungen mit beliebigen Daten aus
beliebigen
gen Speichern integrieren, indem beliebige Protokolle über beliebige Netzwerke verwendet
werden.
ActiveSync / Windows Mobile Device Center
Microsoft ActiveSync ist eine Software zur Datensynchronisation eines PCs mit einem mobilen Gerät,
Gerät
Windows Mobile Device
vice Center ist die Nachfolgeversion von ActiveSync für Windows Vista.
Leider hat Microsoft ab Version 4.0 von ActiveSync die Remotesynchronisierung über WLAN oder
GPRS abgeschafft bzw. sie funktioniert nur noch in Verbindung mit einem Microsoft Exchange Server.
S
Damit entfällt diese Möglichkeit des Datenaustausches für unsere Zwecke und ich gehe nicht mehr
weiter darauf ein.
3.3 Spracherkennung
Aufgrund der beschränkten Displaygrösse von mobilen Geräten und der Anforderung, dass die
Anwendung über den Touchscreen bedient werden können soll,, müssen die einzelnen graphischen
Elemente im Verhältnis zum verfügbaren Platz relativ gross dargestellt werden.
werden. Würde man auf die
Anforderung der Touch-Bedienung
Bedienung verzichten und stattdessen eine Bedienung über Spracheingabe
realisieren, so könnten
ten die Elemente platzsparender und damit mehr Informationen auf einmal
dargestellt werden.
Dies ist jedoch ganz klar ein
n optionales Ziel, welches nur in Angriff genommen wird, wenn
ausreichend Zeit zur Verfügung steht. Dabei können zum Beispiel die folgenden oder allenfalls auch
noch andere Produkte und Technologien untersucht werden.
T
Microsoft Voice Command [Req: TS007]
Microsoft Voice Command verwandelt ein Windows Mobile Gerät zu einem eigenen virtuellen,
persönlichen Assistenten: Man kann mit der Stimme Kontakte suchen, Telefonanrufe tätigen, Daten
im Kalender abfragen, Musik abspielen oder steuern und auch Programme starten.
starten. Es ist zu
überprüfen, ob und wieweit diese Software auch für selbstentwickelte Programme verwendet
werden kann.
Speech Application Programming Interface (SAPI) [Req: TS008]
SAPI ist eine von Microsoft entwickelte Schnittstelle zur Anbindung von Bibliotheken zur
Sprachsynthese und Spracherkennung in Windows-Anwendungen.
Anwendungen. Sie wird unter anderem auch von
Microsoft Voice Command verwendet.
Technologie-Studie
Projekt
Mobile DMS-Datenerfassung
Datenerfassung
Autor
Datum
Version
Dokument
Philipp Buser
28.04.2009
1.0
Pflichtenheft
Seite
17(29)
4 Detaillierte Anforderungen
In diesem Kapitel werden die Use Cases und die funktionalen und nicht-funktionalen
funktionalen Anforderungen
an den zu entwickelnden
lnden Prototyp beschrieben, die in diesem Projekt realisiert werden sollen.
4.1 Use Cases
Akteure
Für den zu entwickelnden Prototyp gibt es nur einen Akteur.
Akteur. Es ist dies der Mitarbeiter (Monteur
oder Verkäufer), welcher im GaragenGaragen oder Carrosseriebetrieb mit dem mobilen Gerät seine
erledigten Arbeiten zurückmeldet. Ein zweiter Akteur, welcher zuvor die Arbeiten im (bestehenden)
System erfasst und plant, ist für die folgenden Use Cases nicht relevant.
Übersicht
Use Cases sind „Aufgabe erledigen“, „Auftrag bearbeiten“ und „Kunde kontaktieren“.
Die drei Haupt-Use
Sie werden in den folgenden Unterkapiteln in weitere Use Cases unterteilt und dort beschrieben.
Detaillierte Anforderungen
Projekt
Mobile DMS-Datenerfassung
Datenerfassung
Autor
Datum
Version
Dokument
Philipp Buser
28.04.2009
1.0
Pflichtenheft
Seite
18(29)
4.1.1 Aufgabe erledigen
Der Use Case „Aufgabe erledigen“ kann in 3 feinere Use Cases unterteilt werden.
ID
Use Case
Beschreibung
Auslöser
Vorbedingungen
Ergebnis
Ablauf
Ausnahmen
Erweiterungen
UC001
Aufgabenliste abrufen
Der Benutzer
Ben
kann sich die Aufgaben zu einem Auftrag anzeigen lassen
Der Benutzer klickt auf die Schaltfläche „Aufgaben“
• Ein Auftrag ist geladen
Die Aufgabenliste zum Auftrag wird angezeigt
1. Der Benutzer klickt auf die Schaltfläche „Aufgaben
Aufgaben“
• Es sind keine Aufgaben vorhanden
Eine Meldung anstelle der Aufgabenliste wird angezeigt
• Filtern der Aufgaben (RQ001)
• Aktualisieren der Aufgaben (RQ002)
• Anpassung an Bildschirmauflösung (RQ006)
• Wechsel zwischen Hoch- und Querformat
erformat (RQ007)
(RQ007
• Touchscreen-Bedienung (RQ008)
• Bedienung per Spracheingabe (RQ009)
Detaillierte Anforderungen
Projekt
Mobile DMS-Datenerfassung
Datenerfassung
Seite
19(29)
Autor
Datum
Version
Dokument
Philipp Buser
28.04.2009
1.0
Pflichtenheft
ID
Use Case
Beschreibung
Auslöser
Vorbedingungen
Ergebnis
Ablauf
Ausnahmen
Erweiterungen
UC002
Aufgabendetails abrufen
Der Benutzer kann sich Details zu einer Aufgabe anzeigen lassen
Der Benutzer klickt auf eine Aufgabe
• Die Aufgabenliste wird angezeigt (UC001)
Detailinformationen zur Aufgabe werden angezeigt
1. Der Benutzer klickt auf eine Aufgabe
--• Anpassung an Bildschirmauflösung (RQ006)
• Wechsel zwischen Hoch- und Querformat (RQ007)
(RQ007
• Touchscreen-Bedienung (RQ008)
ID
Use Case
Beschreibung
Auslöser
Vorbedingungen
UC003
Aufgabe als erledigt zurückmelden
Der Benutzer kann eine Aufgabe als erledigt zurückmelden
Der Benutzer klickt auf die Schaltfläche „Übermitteln“
• Die Aufgabenliste (UC001) oder die Detailinformationen zu einer
Aufgabe (UC002) werden angezeigt
Die markierte Aufgabe wird auf dem Server als erledigt gekennzeichnet
und verschwindet aus der Liste der offenen Aufgaben
1. Der Benutzer markiert eine Aufgabe als erledigt, indem er
a. in der Aufgabenliste die bei einer Aufgabe stehende
Checkbox aktiviert oder
b. in den Detailinformationen einer Aufgabe auf die
Schaltfläche „Erledigen“ klickt (Priorität 2)
2. Der Benutzer klickt auf die Schaltfläche „Übermitteln“
• Keine Aufgabe als erledigt markiert
Es passiert nichts
• Eine als erledigt markierte Aufgabe wurde inzwischen bereits von
einem anderen Benutzer erledigt
Die Aufgabe wird ganz normal als erledigt übermittelt
• Automatische Aktualisierung der Aufgaben (RQ003)
• Mehrere Aufgaben aufs Mal erledigen (RQ004)
• Touchscreen-Bedienung (RQ008)
Ergebnis
Ablauf
Ausnahmen
Erweiterungen
Detaillierte Anforderungen
Projekt
Mobile DMS-Datenerfassung
Datenerfassung
Autor
Datum
Version
Dokument
Philipp Buser
28.04.2009
1.0
Pflichtenheft
Seite
20(29)
4.1.2 Auftrag bearbeiten
Der Use Case „Auftrag bearbeiten“
bearbeiten kann ebenfalls in 3 Use Cases unterteilt werden.
ID
Use Case
Beschreibung
Auslöser
Vorbedingungen
Ergebnis
Ablauf
Ausnahmen
Erweiterungen
UC004
Termininformationen abrufen
Der Benutzer kann sich die Termininformation zum Auftrag anzeigen lassen
Der Benutzer klickt auf die Schaltfläche „Termine“
• Ein Auftrag ist geladen
Die Termininformationen zum Auftrag werden angezeigt
1. Der Benutzer klickt auf die Schaltfläche „Termine“
--• Anpassung an Bildschirmauflösung (RQ006)
• Wechsel zwischen Hoch- und Querformat (RQ007)
(RQ007
• Touchscreen-Bedienung (RQ008)
• Bedienung per Spracheingabe (RQ009)
Detaillierte Anforderungen
Projekt
Mobile DMS-Datenerfassung
Datenerfassung
Seite
21(29)
Autor
Datum
Version
Dokument
Philipp Buser
28.04.2009
1.0
Pflichtenheft
ID
Use Case
Beschreibung
UC005
Fahrzeuginformationen abrufen
Der Benutzer kann sich die Fahrzeuginformationen zum Auftrag anzeigen
lassen
Der Benutzer klickt auf die Schaltfläche „Fahrzeug“
• Ein Auftrag ist geladen
Die Fahrzeuginformationen zum Auftrag werden angezeigt
1. Der Benutzer klickt auf die Schaltfläche „Fahrzeug
Fahrzeug“
--• Anpassung an Bildschirmauflösung (RQ006)
• Wechsel zwischen Hoch- und Querformat (RQ007)
• Touchscreen-Bedienung (RQ008)
• Bedienung per Spracheingabe (RQ009)
Auslöser
Vorbedingungen
Ergebnis
Ablauf
Ausnahmen
Erweiterungen
ID
Use Case
Beschreibung
Auslöser
Vorbedingungen
Ergebnis
Ablauf
Ausnahmen
Erweiterungen
UC006
Auftrag abschliessen
Der Benutzer kann einen Auftrag abschliessen
Der Benutzer klickt auf die Schaltfläche „Auftrag abschliessen“
• Alle Aufgaben des Auftrags sind bereits als erledigt zurückgemeldet
worden
Der Auftrag ist abgeschlossen
1. Der Benutzer klickt auf die Schaltfläche „Auftrag abschliessen“
--• Touchscreen-Bedienung (RQ008)
• Bedienung per Spracheingabe (RQ009)
Detaillierte Anforderungen
Projekt
Mobile DMS-Datenerfassung
Datenerfassung
Autor
Datum
Version
Dokument
Philipp Buser
28.04.2009
1.0
Pflichtenheft
Seite
22(29)
4.1.3 Kunde kontaktieren
Der Use Case „Kunde kontaktieren“ kann in 2 Use Cases unterteilt werden.
ID
Use Case
Beschreibung
Auslöser
Vorbedingungen
Ergebnis
Ablauf
Ausnahmen
Erweiterungen
UC007
Kundeninformationen abrufen
Der Benutzer kann sich die Kundeninformationen zum Auftrag anzeigen
lassen
Der Benutzer klickt auf die Schaltfläche „Kunde“
• Ein Auftrag ist geladen
Die Kundeninformationen zum Auftrag werden angezeigt
1. Der Benutzer klickt auf die Schaltfläche „Termine“
--• Anpassung an Bildschirmauflösung (RQ006)
• Wechsel zwischen Hoch- und Querformat (RQ007)
• Touchscreen-Bedienung (RQ008)
• Bedienung per Spracheingabe (RQ009)
Detaillierte Anforderungen
Projekt
Mobile DMS-Datenerfassung
Datenerfassung
Seite
23(29)
Autor
Datum
Version
Dokument
Philipp Buser
28.04.2009
1.0
Pflichtenheft
ID
Use Case
Beschreibung
UC008
Kunde kontaktieren
Der Benutzer kann aus den Kundeninformationen heraus den Kunden
anrufen, eine SMS oder eine Email schreiben
Der Benutzer klickt auf die entsprechende Schaltfläche
• Die Kundeninformationen werden
den angezeigt (UC007)
(UC007
Eine Telefonverbindung zum Kunden wird hergestellt oder der SMSSMS oder
Emailversand an den Kunden wird vorbereitet
1. Der Benutzer klickt auf die entsprechende Schaltfläche
2. Die gewählte Funktion wird ausgeführt:
a. Bei Anruf: Die Telefonverbindung wird direkt hergestellt
b. Bei SMS: Eine SMS wird erstellt und zur weiteren
Bearbeitung angezeigt
c. Bei Email: Eine Email wird erstellt und zur weiteren
Bearbeitung angezeigt
• Ungültige Telefonnummer / Emailadresse
wird nicht geprüft
• Touchscreen-Bedienung (RQ008)
• Bedienung per Spracheingabe (RQ009)
Auslöser
Vorbedingungen
Ergebnis
Ablauf
Ausnahmen
Erweiterungen
4.2 Funktionale Anforderungen
ID
Anforderung
Beschreibung
Verwendet von Use
Cases
ID
Anforderung
Beschreibung
Verwendet von Use
Cases
ID
Anforderung
Beschreibung
Verwendet von Use
Cases
RQ001
Filtern der Aufgaben
Das System soll dem Benutzer die Möglichkeit bieten, über einen Filter die
offenen, die bereits erledigten oder alle Aufgaben zu einem Auftrag
abzurufen.
• Aufgabenliste abrufen (UC001)
RQ002
Aktualisieren der Aufgaben
Das System soll dem Benutzer die Möglichkeit bieten, die Aufgabenliste auf
Knopfdruck zu aktualisieren.
• Aufgabenliste abrufen (UC001)
RQ003
Automatische Aktualisierung der Aufgabenliste
Nachdem der Benutzer erledigte Aufgaben zurückgemeldet hat, soll das
System die Aufgabenliste automatisch aktualisieren.
• Aufgabe als erledigt zurückmelden (UC003)
Detaillierte Anforderungen
Projekt
Mobile DMS-Datenerfassung
Datenerfassung
Seite
24(29)
Autor
Datum
Version
Dokument
Philipp Buser
28.04.2009
1.0
Pflichtenheft
ID
Anforderung
Beschreibung
RQ004
Mehrere Aufgaben auf einmal erledigen
Das System soll dem Benutzer die Möglichkeit bieten, mehrere Aufgaben
auf einmal als erledigt zurückzumelden.
zurück
• Aufgabe als erledigt zurückmelden (UC003)
Verwendet von Use
Cases
4.3 Nicht funktionale Anforderungen
ID
Anforderung
Beschreibung
RQ005
Eingaben überprüfen
Das System muss die vom Benutzer eingegebenen Daten auf ihre Gültigkeit
überprüfen und den Benutzer im Fehlerfall benachrichtigen.
ID
Anforderung
Beschreibung
RQ006
Anpassung an Bildschirmauflösung
Die zurzeit auf dem Markt erhältlichen mobilen Geräte unterscheiden sich
zum Teil stark bei der Bildschirmauflösung, DPI-Zahl
Zahl und der Ausrichtung.
Das System soll die
d Auflösung eines Geräts erkennen und die Darstellung
dementsprechend anpassen.
ID
Anforderung
Beschreibung
RQ007
Wechsel zwischen HochHoch und Querformat
Einige Geräte unterstützen die dynamische Änderung der
Bildschirmausrichtung Das System soll wenn möglich auch diesem Feature
Bildschirmausrichtung.
Rechnung tragen.
ID
Anforderung
Beschreibung
RQ008
Touchscreen
Touchscreen-Bedienung
Das System soll möglichst vollständig mit dem Finger über die
Touchoberfläche des mobilen Geräts bedient werden können.
ID
Anforderung
Beschreibung
RQ009
Bedienung per Spracheingabe
Das System soll dem Benutzer die Möglichkeit bieten, einzelne Aktionen
per Spracheingabe
Sprachein
auszulösen.
ID
Anforderung
Beschreibung
RQ010
Sprache
Die Bedienerführung der Anwendung ist in Deutsch. Es müssen keine
anderen Sprachen unterstützt werden.
ID
Anforderung
Beschreibung
RQ011
Sicherheit
Die übermittelten Daten sind nicht sensitiv.
sensitiv Deshalb sind im Moment keine
Vorkehrungen für Verschlüsselung, Authentifizierung oder Ähnlichem
vorgesehen.
Detaillierte Anforderungen
Projekt
Seite
Mobile DMS-Datenerfassung
Datenerfassung
Autor
Datum
Version
Dokument
Philipp Buser
28.04.2009
1.0
Pflichtenheft
25(29)
5 Übersicht und Prioritäten
Die Ziele der Technologie-Studie
Studie und die Anforderungen an den Prototyp sind in den folgenden
Tabellen stichwortartig zusammengefasst und priorisiert. Es werden 3 Prioritätsstufen
unterschieden:
Projektbezogene
Einteilung
Einfluss auf die
Bewertung der Master
Thesis
Priorität 1
Obligatorische
Kernziele und
Hauptanforderungen
Ziele mit Priorität 1
müssen für eine gute
Bewertung zwingend
erreicht werden
Priorität 2
Nützliche, aber nicht
obligatorische Ziele
und Anforderungen
Erfolgreich umgesetzte
Ziele der Priorität 2
haben einen positiven
Einfluss auf die
Bewertung, nicht
umgesetzte Ziele
bewirken aber keine
Abzüge
Priorität 3
„Nice to have“, falls
genügend Zeit zur
Verfügung steht
Ziele mit Priorität 3
sind nicht direkt
not
notenrelevant
5.1 Technologie-Studie
ID
Priorität 1
Priorität 2
Priorität 3
Kennenlernen,
Testanwendung
-
-
TS002
Windows Mobile SDK
und .NET Compact
Framework
SQL Server Compact
Kennenlernen,
Testanwendung
-
-
TS003
Webservice
TS004
SQL Server MergeReplikation
SQL Server RemoteDatenzugriff
Sync Services for
ADO.NET
Datensatz abrufen,
Daten
Tabelle/Liste abrufen zurückschreiben1
Tabelle replizieren
Tabellenstruktur
replizieren
Datensatz abrufen,
Daten
Tabelle/Liste abrufen zurückschreiben1
Datensatz abrufen,
Daten
Tabelle/Liste abrufen zurückschreiben1
TS001
TS005
TS006
TS007
TS008
Microsoft Voice
Command
Speech Application
Programming Interface
-
1
-
Sprachsteuerung
testen
Sprachsteuerung
implementieren
Falls sich nicht die SQL Server Merge-Replikation
Replikation als die am besten geeignete Methode herausstellt,
herausstellt dann muss
mindestens einer der 3 Fälle „Daten zurückschreiben“ zwingend realisiert werden, um im Anschluss die Anforderungen an
den Prototyp umsetzen zu können.
Übersicht und Prioritäten
Projekt
Seite
Mobile DMS-Datenerfassung
Datenerfassung
Autor
Datum
Version
Dokument
Philipp Buser
28.04.2009
1.0
Pflichtenheft
26(29)
5.2 Prototyp
ID
Priorität 1
UC001
UC002
UC003
UC004
UC005
UC006
UC007
UC008
Aufgabenliste abrufen
Aufgabendetails abrufen
Aufgabe als erledigt zurückmelden
Termininformationen abrufen
Fahrzeuginformationen abrufen
Auftrag abschliessen
Kundeninformationen abrufen
Kunde kontaktieren
RQ001
RQ002
RQ003
RQ004
Filtern der Aufgaben
Aktualisieren der Aufgaben
Automatische Aktualisierung der Aufgaben
Mehrere Aufgaben auf einmal erledigen
RQ005
RQ006
RQ007
RQ008
RQ009
RQ010
RQ011
Eingaben überprüfen
Anpassung an Bildschirmauflösung
Wechsel zwischen HochHoch und Querformat
Touchscreen-Bedienung
Bedienung
Bedienung per Spracheingabe
Sprache
Sicherheit
Übersicht und Prioritäten
Priorität 2
Priorität 3
Projekt
Mobile DMS-Datenerfassung
Datenerfassung
Autor
Datum
Version
Dokument
Philipp Buser
28.04.2009
1.0
Pflichtenheft
Seite
27(29)
6 Vorgehen und Zeitplan
Dadurch bedingt, dass dies grösstenteils eine Einzelarbeit ist, halten sich AbstimmungsAbstimmungs und
Koordinationsaufwand in Grenzen. Ein Projektplan wurde natürlich trotzdem erstellt und er wird
auch fortlaufend überprüft und wenn nötig angepasst.
ange
Auf einen wöchentlichen Statusbericht an den Experten wird verzichtet. Stattdessen treffen wir uns
ca. alle 4 Wochen zu einem Review/Workshop. Der nächste Termin wird jeweils während der
aktuellen Review-Sitzung
Sitzung definiert.
Mit dem Betreuer und Auftraggeber werden ebenfalls Meetings durchgeführt. Diese können jedoch
bei Bedarf und Gelegenheit sehr kurzfristig angesetzt werden, so wie wir dies bei uns auch in
anderen Projekten handhaben.
6.1 Tests
Grundsätzlich wird die Applikation auf und mithilfe von
von Emulatoren entwickelt. Für die Tests stehen
zudem auch physische Geräte zur Verfügung. Voraussichtlich sind dies ein HTC Touch HD und in der
Endphase auch ein Psion Teklogix Ikôn.
Ikôn Die Entwicklung wird dann auf diesen Geräten getestet, wenn
möglich soll die
ie Applikation natürlich auch auf möglichst vielen anderen Geräten funktionieren und
zum Einsatz kommen können.
Unit-Tests
Soweit wie sinnvoll werden die Klassen und Komponenten fortlaufend mit Unit-Tests
Tests getestet.
Integrations-Test
In Funktionstests werden sämtliche funktionalen Anforderungen manuell durchgetestet. Von den
Use-Cases und Anforderungen mit Priorität 1 müssen 100% der Tests erfolgreich verlaufen.
System-Test
Für den Systemtest werden die Use-Cases
Use
in unterschiedlichen Workflows getestet. Zudem werden
Test Cases erstellt, welche Fehlersituationen erzeugen.
Usability- und Abnahme-Tests
Im Rahmen dieser Master Thesis sind keine UsabilityUsability und Abnahme-Tests
Tests vorgesehen.
Vorgehen und Zeitplan
Projekt
Mobile DMS-Datenerfassung
Datenerfassung
Autor
Datum
Version
Dokument
Philipp Buser
28.04.2009
1.0
Pflichtenheft
6.2 Projektplan
Vorgehen und Zeitplan
Seite
28(29)
Projekt
Mobile DMS-Datenerfassung
Datenerfassung
Autor
Datum
Version
Dokument
Philipp Buser
28.04.2009
1.0
Pflichtenheft
Seite
29(29)
7 Risiken und Kosten
7.1 Risiken
Grundsätzlich ist das Projekt in einer Grössenordnung, in welcher die Risiken
isiken überschaubar bleiben.
Projektrisiken
Qualitätsrisiken
Technische Risiken
Auslastungsrisiken
Terminrisiken
Akzeptanzrisiken
Budgetrisiken
Gering.
In diesem Projekt geht es (unter anderem) genau darum, die technischen
Möglichkeiten und allfällige Probleme und Risiken zu untersuchen und
Lösungen zu finden.
Der veranschlagte Aufwand ist fix definiert (20% Arbeitspensum plus
Freizeit), deshalb eher gering.
Hoch. Das Projekt muss „in time“ abgeschlossen werden.
Der zu entwickelnde Prototyp wird für sich alleine nur bedingt Akzeptanz bei
den Kunden finden. Dazu sind Folgeprojekte notwendig.
Gering.
7.2 Kosten
Der budgetierte Aufwand seitens des Studenten beträgt 360 Stunden, die ausserhalb der Arbeitszeit
geleistet werden und dadurch für den Auftraggeber keine Kosten verursachen.
verursachen. Darin enthalten sind
Projektführung, Analyse, Entwurf, Implementierung,, Tests und Dokumentation sowie auch sämtliche
Meetings und Reviews im Zusammenhang
Zusammen
mit dem Projekt.
Der Arbeitsplatz, die Hardware (ausser der 2 Testgeräte) und die benötigte Software
(Entwicklungsumgebung, etc.) sind ohnehin schon vorhanden.
Projektbudget & Wirtschaftlichkeit
Personalkosten
Philipp Buser: 360 h, ohne Kosten
Reto Dellenbach: 20 h
Summe Pers.kosten
CHF 4000.4000.
Ausgabewirksame
Kosten
2 Testgeräte
max. CHF 3000.3000.
Mobilfunk und Abo-Gebühren
Mobilfunk-
CHF 250.-
Sonstige Ressourcen
Keine
Gesamtprojektkosten CHF 7250.7250.
/ Projektbudget
Projekteinnahmen /
Wirtschaftlichkeit
Da das Projekt eher forschenden Charakter hat und als Resultat „nur“ ein
Prototyp entsteht, sind nach Beendigung des Projekts keine Einnahmen zu
erwarten. Die Projektkosten können demnach nicht direkt, sondern
allenfalls erst in einem Folgeprojekt kompensiert
kompensiert werden.
Folgekosten nach
Beendigung des
Projekts
Keine
Risiken und Kosten