Lade Inhalt...

Microsoft SharePoint® Lösungspaket zur Visualisierung von Geostandorten

Projektarbeit 2010 55 Seiten

Informatik - Angewandte Informatik

Leseprobe

Inhaltsverzeichnis

1 Projektbeschreibung
1.1 Einführung
1.2 Projektanstoß
1.3 Projektumfeld

2 Planungsphase
2.1 Projektplan
2.2 IST-Analyse
2.3 Kostenplan
2.4 Soll-Konzept
2.4.1 Funktionalitäten
2.4.2 Sicherheit
2.4.3 Integration in bestehende Intranetanwendung

3 Entwurfsphase
3.1 Vorüberlegungen
3.2 Bestandteile des Lösungspakets
3.2.1 Webparts
3.2.2 Maps-Adressliste und Content-Type
3.2.3 Setupkomponente

4 Implementierungsphase
4.1 Installation und Konfiguration der Entwicklungsumgebung
4.2 Strukturierung Visual Studio Projekt Solution
4.3 Entwicklung der Webparts
4.4 Maps Adressliste und Content-Type
4.5 Zusätzlicher Quellcode

5 Testphase

6 Projektbewertung
6.1 Zielerreichung
6.2 Soll/Ist-Abgleich Projektphasen
6.3 Qualitätssicherung
6.4 Änderungen gegenüber Projektantrag

7 Fazit und Ausblick

8 Literaturverzeichnis

9 Anhang

A Projektplan

B Pflichtenheft

Zielbestimmung

1 Projektbeschreibung

1.1 Einführung

Der Kunde (richtiger Kundename darf namentlich nicht genannt werden) ist ein erfolgreiches Unternehmen im Gesundheitsgewerbe mit mehreren Standorten in der Region Norddeutschland. Der Kunde betreut Therapiepatienten im Rehabilitations- und Präventionsbereich.

Zu den Aufgaben der Verwaltungsabteilung gehören u. a. die Planung und Durchführung von Abhol- und Bringediensten für Patienten, die die jeweiligen Therapiestandorte eigenständig nicht erreichen können.

Aufgrund der Vielzahl von Patienten, deren Abholorte ein große räumliche Ausdehnung zueinander besitzen sollen die Fahrtrouten mit einem unternehmensweit einsetzbaren System optimiert werden.

1.2 Projektanstoß

Im vergangenen Jahr hat der Kunde eine Kollaborationsplattform auf Basis von Microsoft Windows SharePoint® Services 3.0 im Unternehmen etabliert. Die Webanwendung dieser Plattform bietet berechtigten Mitarbeitern Zugriff auf gemeinsam genutzte Ressourcen wie Dokumente, News- und Kalendereinträge sowie Adressinformationen. Der Wunsch nach Einbindung der bereits vorhandenen Adressinformationen in eine Lösung zur Visualisierung von Patientenstandorten ist ein wichtiger Schritt der Optimierung von Arbeitsprozessen und damit eine Reduzierung von Kosten.

In einer ersten Realisierungsphase, die im Rahmen dieser Projektarbeit abgedeckt wird möchte der Kunde die Standorte der Patienten auf einer Geokarte visualisieren.

1.3 Projektumfeld

Das Projekt wird in der Abteilung „Software-Engineering“ der Firma EVES Information Technology AG durchgeführt. Es ist ein Projekt in enger Zusammenarbeit mit dem Kunden.

Projektleiter und Ausführender ist Alexander Röhrig, Auszubildender im Beruf Fachinformatiker - Fachrichtung Anwendungsentwicklung. Projektverantwortlicher ist der Ausbildungsleiter Martin Bravin.

2 Planungsphase

Die Planungsphase enthält Projektplan, Ist Analyse und Soll-Konzept (Pflichtenheft).

2.1 Projektplan

Die folgende Auflistung stellt das Gesamtprojekt mit den Aufwänden der einzelnen Teilschritte dar. Der Gesamtaufwand beträgt 70 h.

Abbildung in dieser Leseprobe nicht enthalten

Die Teilaufgaben des Gesamtprojekts wurden in Microsoft Project 2007 übertragen (siehe Anhang B Pflichtenheft.

2.2 IST-Analyse

Prozess der Planung von Fahrtrouten

Der Planungsprozess wurde in einem halbstündigen Gespräch gemeinsam mit dem Verantwortlichen Projektleiter des Kunden besprochen. Das Ergebnis des Gesprächs lautete wie folgt:

Der Kunde nutzt für die Erfassung von Adressinformationen eine proprietäre Softwarelösung (Therapieorganisation - THEORG), die u. a. auch die Verwaltung von Abrechungsmodalitäten mit den Kostenträgern (Kranken- und Pflegekassen) übernimmt.

Die Patienten vereinbaren Termine für die Durchführung von rehabilitativen Maßnahmen, die in diese Software eingegeben werden.

Der Abholzeitpunkt muss von dem verantwortlichen Mitarbeiter ohne Kenntnis der genauen Patientenstandorte durch Visualisierung auf einer Karte manuell festgelegt werden.

Schlussfolgerung aus der IST-Analyse

Die Planung der Abholtermine erfolgt ausschließlich durch einen erfahrenen Mitarbeiter unter erheblichem Zeitaufwand.

2.3 Kostenplan

Die Kostenplanung beschreibt die Wirtschaftlichkeit der zu entwickelnden Software. Sie führt genauere Kostendetails auf.

Kosten-Stundensatz Entwicklung: 58,00 € Kosten- Stundensatz Kunde: 40,00 €

Einmalige Entwicklungskosten

Abbildung in dieser Leseprobe nicht enthalten

Vergleich Kosten für die Planung von Patientenrouten

Abbildung in dieser Leseprobe nicht enthalten

Amortisierungsdauer

Entwicklungskosten : Ersparnis = Dauer 3596,00 € : 9600,00 € ≈ 4,5 Monate

Die Entwicklungskosten würden beim Einsatz der Software in etwa 4,5 Monaten gedeckt sein.

2.4 Soll-Konzept

Im Soll-Konzept werden die Anforderungen an das Projekt beschrieben. Es wird festgelegt ich welcher Form das Lösungspaket zu erstellen ist.

Im Folgenden werden die wesentlichen Punkte des Soll-Konzepts aufgezeigt. Die detaillierten Anforderungen sind in der Anlage B Pflichtenheft beschrieben.

2.4.1 Funktionalitäten

Auf die Geokarte soll aus dem Intranet (Windows SharePoint® Services Webanwendung) zugegriffen werden.

Die Adressinformationen für die Markerpunkte auf der Karte sollen in einer SharePoint Liste gespeichert werden sein.

2.4.2 Sicherheit

Der Zugriff auf die Adressinformationen unterliegt den allgemeinen Richtlinien für Datenschutz und Datensicherheit.

Es dürfen nur berechtigte Benutzer auf die Adressdaten zugreifen können.

Das Lösungspaket soll im Sicherheitskontext des SharePoint® System für die jeweils angemeldete Windows-Benutzeridentität laufen.

2.4.3 Integration in bestehende Intranetanwendung

Die Lösung soll sich vollautomatisch als ausführbare „exe“ Datei in die SharePointWebanwendung integrieren lassen um dem Kunden eine anwenderfreundliche und kostensparende Installationsmöglichkeit zu bieten

3 Entwurfsphase

In der Entwurfsphase wird festgelegt in welcher Weise die erforderlichen Komponenten implementiert und welche Entwicklungsstrategien verfolgt werden.

3.1 Vorüberlegungen

Die Integration von Kartenfunktionaliät in eine bestehende WSS[1]-Webanwendung erfordert eine genaue Planung der benötigten Komponenten und ein detailliertes Wissen über die Architektur, Entwicklungskonzepte sowie über die Möglichkeiten der Integration des interaktivem Kartenmaterials.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Integration der Geokarte in eine Intranetanwendung auf Basis von Windows SharePoint Services

3.2 Bestandteile des Lösungspakets

Das Lösungspaket wird als voll funktionsfähige Anwendungserweiterung[2] in einer beliebigen Webanwendung eines SharePoint Systems (Version 3.0) integrierbar sein.

Nach der Installation und Aktivierung des Lösungspakets werden folgende Funktionalitäten laut Soll-Konzept in der Webanwendung bereitgestellt:

- Ein SharePoint-Webpart mit einer Google Karte und einer Bing Karte
- eine Maps-Adressliste für die Speicherung der adressbezogenen Standortinformationen aus dem THEORG-Programm
- Ein Adresslisten-Inhaltstyp, der an die Adressliste geknüpft ist und folgende Listenfelder besitzt: Name (Patientenname), Straße, Postleitzahl, Ort
- Eine Setup-Komponente, die das gesamten Lösungspaket auf ein SharePoint System installiert

3.2.1 Webparts

Die Webparts stellen einen HTML/JavaScript-Container für die Darstellung der Karte in der Windows SharePoint Services Webanwendung dar.[3]

Die Webparts werden mit der .NET Technologie entwickelt, der erstellte Code wird vom SharePoint System serverseitig ausgeführt und an den Webbrowser gesendet.

Bei der Entwicklung steht der komplette Funktionsumfang des Microsoft .NET Frameworks Version 3.5 zur Verfügung. Somit ist eine kostengünstige, robuste und vom Hersteller unterstützte Entwicklung möglich.

Karten APIs

Die Anbieter Google und Bing[4] stellen eigene APIs[5] zur Einbindung von interaktivem Kartenmaterial auf Webseiten zur Verfügung.

Die Funktionalität beider Kartensysteme ist weitestgehend identisch und umfasst u. a. folgende Funktionalitäten:

- Interaktive 2D-Darstellung von Straßen- und Geländeinformationen
- Zoom-In und Zoom-Out Funktion
- Darstellung von Markern bzw. Pins (Markerpunkte auf der Karte) auf Grundlage von Längen und Breitengraden oder Adressinformationen (reverse Geokodierung)
- Interaktive 3D Darstellung (z. b. Streetviews) nach zusätzlicher Installation eines Browser-Plugins

Die Nutzung der Google Maps API erfordert die Registrierung eines API-Schlüssels, was momentan noch kostenfrei[6] möglich ist.

Beide Anbieter bieten eine JavaScript-basierte Lösung an, die sich in bestehende Webanwendungen integrieren lässt.

Da mehrere Kartentypen unterstützt werden sollen muss von einer abstrakten WebpartBasisklasse abgeleitet werden um einen höheren Programmieraufwand zu vermeiden und die Wartbarkeit des Codes zu erhöhen.

Die abstrakte Basisklasse „MapsWebpart“ leitet von

Microsoft.SharePoint.WebPartPages.WebPart ab von soll gemeinsame Kartenoptionen wie

Höhe, Breite der Karten über ein Interface bereitstellen.

Die abgeleiteten Klassen besitzen erweiterte kartenspezifische Eigenschaften, wie die Anzeige von Kartensteuerelementen und API-Keys, deren Implementierung über eigene Interfaces (~MapsWebpartProperties) erzwungen wird.

3.2.2 Maps-Adressliste und Content-Type

Die Maps-Adressliste ist eine SharePoint Liste, die durch eine separate Software mit den

Adressdaten aus dem THEORG-System befüllt wird.

Die Entwicklung dieser Lösung ist nicht Bestandteil der Projektarbeit.

Um eine höchstmögliche Flexibilität für den Endanwender zu ermöglichen ist die Änderung des Adressdatenbestands in der Liste auch nach dem Import mit dem THEORG-System möglich. Die Adressdaten müssen für die Visualisierung der Karte in einem bestimmten Format vorliegen, und vor der Speicherung validiert werden. Dafür wird ein SharePoint Content-Type (Inhaltstyp) für die Adressliste erstellt, der festlegt welche Feldwerte in welchem Datenformat in der Liste speicherbar sind.

- Name des Patienten (Textfeld, max. Länge 255 Zeichen)
- Strasse (Textfeld, max. Länge 255 Zeichen)
- PLZ (Textfeld, max. Länge 5 Zeichen)
- Ort (Textfeld, max. Länge 255 Zeichen)

Der Content-Typ stellt außerdem sicher, dass in den Formularen („Neue Adresse hinzufügen“ und „Adresse bearbeiten“ Eingabefelder für die Daten bereitgestellt werden.

3.2.3 Setupkomponente

Die Setupkomponente besteht aus der Anwendung SharePoint Solution Installer[7], einer XML-Konfigurationsdatei sowie die im WSP-Format gepackte Form des Codes für die MapsAdressliste, des Content-Types sowie der Webparts.

Durch die Setupkomponente wird sichergestellt, dass alle Funktionalitäten auf dem SharePoint Zielsystem bereitgestellt werden.

Der WSP-Builder[8] (nicht Bestandteil des Lösungspakets) ist ein Visual Studio Add-IN und ermöglicht die Kompilierung des Quellcodes eines Visual Studio Projekts in eine WSP-

Datei[9]. Es wird der Quellcode für die Webparts, den Content-Type sowie der Adressliste kompiliert.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Erzeugung und Installation des Lösungspakets

4 Implementierungsphase

4.1 Installation und Konfiguration der Entwicklungsumgebung

Die Erstellung des Projekt-Quellcodes erfordert eine entsprechend konfigurierte Entwicklungsumgebung.

Für die Installation der Entwicklungsumgebung wird ein virtualisiertes Windows 2003 Server System als Hostsystem aller Entwicklungskomponenten verwendet.

Eine vorkonfigurierte Entwicklungsumgebung (laut Anhang F Komponenten der Entwicklungsumgebung) wurde von der Abteilung IT & Mobile Solutions der Firma EVES-IT bereitgestellt und wird daher hier nicht weiter beschrieben.

4.2 Strukturierung Visual Studio Projekt Solution

Für die Erstellung des Lösungspakets wurde ein neues Visual Studio Projekt auf Basis einer WSP-Builder Projektvorlage erstellt (siehe dazu auch Anhang E Visual Studio Projektstruktur).

Ordner 12

Die Struktur dieses Ordners entspricht dem Filesystem der Windows SharePoint Services Webanwendung. Bei der Installation des Lösungspakets werden die erstellten Dateien (XML- Schemadefinitionen und JavaScripte) in die entsprechenden Ordner kopiert. Die Struktur stellt somit ein Mapping für die Verzeichnisstruktur der Windows SharePoint Services Webanwendung dar und ist für die Integration des Lösungspakets unbedingt erforderlich.

Ordner WebpartCode, FeatureCode

In diesem Ordnern wird der C# Code für die .NET basierten Funktionalitäten des Lösungspakets erstellt.

4.3 Entwicklung der Webparts

Durch Überschreiben der virtuellen Funktion „CreateChildControls“ der Basisklasse

„MapsWebpart“ kann JavaScript-Code für den Webpart Container bereitgestellt werden, der auf der SharePoint Webanwendung angezeigt wird.

Der JavaScript-Code wird dynamisch über ein Objektmodell (siehe Anhang E Modell für die Interaktion der .NET Klassen zur Zusammenstellung des JavaScript Codes) zusammengestellt. Wesentlich sind hierbei die Verbindungsklasse „Adresshandler“, die Adressen aus der SharePoint Adressliste holt und diese Adressdaten dem „JSHandler“ bereitstellt. Der „JSHandler“ bereitet die Daten als JavaScript auf und übergibt eine Anfrage an die jeweilige Karten-API. Die Karten-API kann dann die Karte mit Markerpunkten für jede Adresse zurückgeben.

Durch dieses modulare Konzept der Kapselung der Basisfunktionalitäten konnte die sehr gute Wartbarkeit und Nachvollziehbarkeit des Quellcodes auch für andere Entwickler erreicht werden. Zudem ist es möglich über die entsprechende Sichtbarkeit von Klassen und Funktionen eine Wiederverwendbarkeit für Erweiterungen zu erreichen.

4.4 Maps Adressliste und Content-Type

Das SharePoint System benötigt eine XML-Schemadefinition für die Abbildung einer SharePoint Liste in der Webanwendung. Der Quellcode dieser Schemadefinition beinhaltet die wichtigsten Einstellungen für die Liste wie Name, ID, Inhaltstypen u. a.

Der XML-Code unterliegt einem vom Microsoft geforderten Schema und wird bereits von der Entwicklungsumgebung während der Designzeit validiert.

XML-Schemadefinition für Adressliste

Die Schemadefinition der Adressliste gibt an, in welcher Form die Adressliste auf dem

SharePoint System bereitgestellt wird (siehe dazu auch Anhang

Schemadefinition für den Maps-Adressliste).

XML-Schemadefinition für Content-Type

Die Erstellung des Content-Types erfolgt ebenfalls auf Basis einer XML-Schemadefinition.

Die Schemadefinition enthält über das XML-Element „FieldRef“ alle Einstellungen über die Adressfelder, die in der Maps-Adressliste benötigt werden.

Das Attribut „ID“ des „Content-Type“ Elements wird in der Maps Adressliste referenziert. Damit wird eine Zuordnung des Content-Types zur Adressliste sichergestellt.

4.5 Zusätzlicher Quellcode

Für die Aktivierung, bzw. Deaktivierung des Lösungspakets in der Windows SharePoint Services Webanwendung wurde noch zusätzlicher Quellcode (FeatureReceiver-Code) benötigt.

Der Code übernimmt folgende Funktionalitäten, die die Integrität des Lösungspakets in der Webanwendung sicherstellen:

- Aktivierungsfunktionen

Es müssen alle Bestandteile des Lösungspakets einzeln aktiviert werden, damit das Gesamtpaket in den aktiven Zustand gesetzt wird.

Es wird überprüft, ob die SharePoint Anwendung alle benötigten Voraussetzungen (Konfigurationseinstellungen, abhängige Features) bereitstellt, bevor das Lösungspaket aktiviert werden kann.

- Listenfunktionen

Erstellung der Listeninstanz der Maps Adressliste nach Aktivierung des Maps- Lösungspakets sowie einen Link in der SharePoint Navigationsleiste

- Deaktivierungsfunktionen

Deaktivierung bzw. Entfernen aller Bestandteile (Navigationslink und Listeninstanz der Maps-Adressliste, Entfernen der Webparts und des Content-Types) nach Deaktivierung des Lösungspakets

5 Testphase

In der Testphase wurden sowohl die Integrationsfähigkeit sowie die Funktionalität des Lösungspakets getestet.

Alle Testfälle[10] wurden von Alexander Röhrig erstellt und von einer zweiten eingewiesenen Person durchgeführt. Diese Methode hat sich in vergangenen Projekten bewährt und ist ein allgemeiner Standard für Softwareentwicklungsprojekte.

Die Testfälle wurden in einem Testprotokoll aufgeführt und sind jeweils pro Testdurchlauf vollständig abgearbeitet wurden bis kein Fehler in der Anwendung mehr auftrat.

6 Projektbewertung

Die Projektbewertung beschreibt, ob alle Zielvorgaben und Zeitplanungen eingehalten wurden.

6.1 Zielerreichung

Nach der erfolgreichen Einführung des Lösungspakets konnte die Reduzierung des Arbeitsaufwandes für die Planung von Patientenrouten durch den Kunden bestätigt werden.

Der Kunde hatte nach der Planungsphase den Wunsch nach der Einbindung eines zweiten Kartenanbieters geäußert. Dadurch ergaben sich geringfügig höhere Entwicklungsaufwände, die durch das Konzept der Ableitung einer abstrakten MapsWebpart-Klasse für beide Kartenanbieter ausgeglichen werden konnten.

6.2 Soll/Ist-Abgleich Projektphasen

Der im Antrag vorgestellte Zeitplan mit einem Gesamtaufwand von 70 Stunden wurde eingehalten. Der höhere Aufwand für die Implementierung konnte durch weniger Aufwand im Bereich des Testings ausgeglichen werden. Bereits zur Entwicklungszeit konnte durch Debuggen des .NET Codes in der Entwicklungsumgebung eine schnelle und effektive Implementierung gewährleistet werden.

Abbildung in dieser Leseprobe nicht enthalten

6.3 Qualitätssicherung

Der erstellte Quellcode wurde zeitgleich mit der Erstellung mit Kommentaren versehen. Die Integrität der XML-Schemadefinitionen wurde mit dem Funktionstest auf Webanwendungsebene sichergestellt. Das SharePoint System erlaubt keinen fehlerhaften XML-Code. Fehler im Quellcode wurde vom SharePoint System in Form von Exceptions in

der Webanwendung und im Eventlog des Servers angezeigt.

Bei der Installation des Lösungspakets überprüft der Sharepoint Solution Installer den bereitgestellten Quellcode. Somit konnte die Installationsfähigkeit des Pakets vor der Auslieferung einwandfrei sichergestellt werden.

6.4 Änderungen gegenüber Projektantrag

Während des Projekts wurde vom Kunden ein zweites Kartenformat neben Google Maps gewünscht. Daher wurde das Projekt auch für die Bing Karte umgesetzt.

[...]


[1] Windows SharePoint Services

[2] vergleichbar mit dem Begriff Plugin oder Extension

[3] Webpart: in C.NET entwickelte Container für HTML-Quellcode der serverseitig gerendert wird

[4] Microsoft Corporation

[5] Application Programming Interface

[6] Registrierung Google-Maps Api-Schlüssel unter http://code.google.com/apis/maps/signup.html

[7] Microsoft, http://sharepointinstaller.codeplex.com/ (Open-Source-Projekt)

[8] Free Software Foundation, Inc., http://wspbuilder.codeplex.com/ (Open-Source-Projekt)

[9] WSP - Windows SharePoint Solution Package

[10] siehe Anlage C Testprotokolle

Details

Seiten
55
Jahr
2010
ISBN (eBook)
9783640772506
ISBN (Buch)
9783640772957
Dateigröße
1.2 MB
Sprache
Deutsch
Katalognummer
v160755
Note
Schlagworte
Visualisierung Geostandorten Projektbericht .NET Framework Fachinformatiker Projektarbeit Google Maps; Bing Maps; Windows SharePoint Services; Feature; Objektmodell; Anwendungsentwicklung; Ausbildung zum Fachinformatiker ASP.NET; Webentwicklung

Autor

Teilen

Zurück

Titel: Microsoft SharePoint® Lösungspaket zur Visualisierung von Geostandorten