Microsoft SharePoint® Lösungspaket zur Visualisierung von Geostandorten
Ausbildung zum Fachinformatiker für Anwendungsentwicklung
Projektarbeit 2010 54 Seiten
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 Software-Architektur und eingesetzte Technologien
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
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 Norddeutsch- land. 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 Bringdiensten für Patienten, die die jeweiligen Therapiestandorte eigenständig nicht erreichen können.
Aufgrund der Vielzahl von Patienten, deren Abholorte eine 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 Fachinformati- ker - Fachrichtung Anwendungsentwicklung. Projektverantwortlicher ist der Ausbildungsleiter Martin Bravin.
Die Abarbeitung der Testfälle wurde durch Herrn Damian Burghardt unterstützt.
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
Tabelle 1: Soll-Aufwände für die Teilphasen des Projekts
Die Teilaufgaben des Gesamtprojekts wurden in Microsoft Project 2007 übertragen (siehe Anhang A Projektplan).
2.2 IST-Analyse
Prozess der Planung von Fahrtrouten
Der Planungsprozess wurde in einem halbstündigen Gespräch gemeinsam mit dem verant- wortlichen 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 Abrechnungsprozessen 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 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 €
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.
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.
Das Lösungspaket soll im Sicherheitskontext des SharePoint® Systems für die jeweils angemeldete Windows-Benutzeridentität ausgeführt werden.
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 Software-Architektur und eingesetzte Technologien
Die Integration von Kartenfunktionaliät in eine bestehende WSS[1]-Webanwendung erfordert eine genaue Planung der benötigten Komponenten, detailliertes Wissen über die Architektur, die Entwicklungskonzepte und eingesetzte Technologien sowie über die Möglichkeiten der Integration interaktiven Kartenmaterials.
Die Entwicklung auf Basis einer SharePoint Anwendung erfordert die Erstellung von .NET Framework basiertem Quellcode in der Programmiersprache C# sowie die Entwicklung von XML[2]-Schemadefinitionen für SharePoint Listen. Die Integration der Geokarte wird über eine Maplet-Server API[3] in JavaScript realisiert.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 1: Integration der Geokarte in eine Intranetanwendung auf Basis von Windows SharePoint Ser- vices
3.2 Bestandteile des Lösungspakets
Das Lösungspaket soll als voll funktionsfähige Anwendungserweiterung[4] 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[5] 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 Lösungspaket auf dem SharePoint System instal- liert
3.2.1 Webparts
Die Webparts stellen einen HTML/JavaScript-Container für die Darstellung der Karte in der Windows SharePoint Services Webanwendung dar.[6]
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 und Betrieb möglich.
Karten APIs
Die Anbieter Google und Bing stellen eigene APIs 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[7] möglich ist und damit keine weiteren Folgekosten für den Kunden verursacht.
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 Micro-
soft.SharePoint.WebPartPages.WebPart ab und soll gemeinsame Kartenoptionen wie z. B.
Höhe und Breite der Karten über ein Interface bereitstellen. Die abgeleiteten Klassen besit- zen erweiterte kartenspezifische Eigenschaften, wie die Anzeigemöglichkeit verschiedener Kartensteuerelementen. Die Implementierung dieser Eigenschaften wird über eigene Inter- faces (~MapsWebpartProperties) erzwungen (siehe dazu auch Anhang E Vererbungsmodell für die Webpartklassen).
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 in 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. Diese Entscheidung trägt auch zur Robustheit der gesamten Lösung bei.
3.2.3 Setupkomponente
Die Setupkomponente besteht aus der Anwendung SharePoint Solution Installer[8], einer XML[9]-Konfigurationsdatei sowie der im WSP-Format[10] gepackte Code, der die MapsAdressliste, den Content-Type sowie der Webparts enthält.
Durch die Setupkomponente wird sichergestellt, dass alle Funktionalitäten auf dem SharePoint Zielsystem bereitgestellt werden.
Der WSP-Builder[11] (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[12].
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). Die Projektvorlage ermöglicht ein Anpassung bereits vordefinierter Projektdateien und damit einen schnellen Entwicklungszyklus.
Ordnerstruktur
Die Struktur der angelegten Ordner entspricht dem Filesystem der Windows SharePoint Services Webanwendung. Bei der Installation des Lösungspakets auf dem WSS-Server werden die erstellten Dateien (XML-Schemadefinitionen und JavaScripte) automatisch in die entsprechenden Ordner gespeichert. 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.
4.3 Entwicklung der Webparts
Durch Überschreiben der virtuellen Funktion „CreateChildControls“ der Webpart-Basisklasse „MapsWebpart“ kann HTML/JavaScript-Code bereitgestellt werden, der später auf der SharePoint Webanwendung als Karte 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) zusammenge- stellt. Wesentlich sind hierbei die Verbindungsklasse „Adresshandler[13]“, die Adressen aus der SharePoint Adressliste holt und diese Adressdaten dem „JSHandler[14]“ 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 zu- rückgeben.
Durch dieses modulare Konzept der Kapselung der Basisfunktionalitäten konnte eine sehr gute Wartbarkeit, Nachvollziehbarkeit und Testability 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, u. a. Name, ID und Inhaltstypen.
Der XML-Code unterliegt einem von Microsoft geforderten Schema und wird bereits von der Entwicklungsumgebung während der Designzeit validiert. Somit ist bereits jetzt sichergestellt, dass kein fehlerhafter Quellcode produziert wird.
XML-Schemadefinition für Adressliste
Die Schemadefinition der Adressliste gibt an, in welcher Form die Adressliste auf dem Sha-
rePoint System bereitgestellt wird (siehe dazu auch Anhang
Schemadefinition für die 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 Ser- vices 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 MapsLö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[15] 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 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 Kar- tenanbieter im Rahmen der geforderten Projektdauer ausgeglichen werden konnten.
6.2 Soll/Ist-Abgleich Projektphasen
Der im Antrag vorgestellte Zeitplan mit einem Gesamtaufwand von 70 Stunden wurde einge- halten. Der höhere Aufwand durch die nachträglich geforderte Kartenerweiterung konnte durch weniger Aufwand im Bereich des Testings und der Planung ausgeglichen werden.
Tabelle 2: Soll/Ist-Vergleich der Projektaufwände
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 durch zusätzliche Funktionstests auf Webanwendungsebene sichergestellt. Das SharePoint System erlaubt keinen fehlerhaften XMLCode. Fehler im Quellcode wurden 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 ebenfalls den bereitgestellten Quellcode. Somit konnte die Installationsfähigkeit des Pakets vor der Auslieferung einwandfrei sichergestellt werden.
[...]
[1] Windows SharePoint Services
[2] Extensible Markup Language
[3] Application Programming Interface
[4] vergleichbar mit dem Begriff Plugin oder Extension
[5] Microsoft Corporation
[6] Webpart: in C.NET entwickelter Container für HTML-Quellcode der serverseitig gerendert wird
[7] Registrierung Google-Maps Api-Schlüssel unter http://code.google.com/apis/maps/signup.html
[8] Microsoft, http://sharepointinstaller.codeplex.com/
[9] Extensible Markup Language
[10] WSP-Format ist ähnlich zip-Format und vom Hersteller empfohlen
[11] Free Software Foundation, Inc., http://wspbuilder.codeplex.com/, (Open-Source-Projekt)
[12] WSP - Windows SharePoint Solution Package
[13] Adresshandler - Verbindungsklasse zwischen Adressliste und Webpartklassen
[14] JSHandler -.NET Klasse zum dynamischen Erzeugen von JavaScript Code
[15] siehe Anlage C Testprotokolle
Details
- Seiten
- 54
- Jahr
- 2010
- ISBN (eBook)
- 9783640759859
- ISBN (Buch)
- 9783640760237
- Dateigröße
- 1.7 MB
- Sprache
- Deutsch
- Katalognummer
- v160756
- Note
- 1.6
- Schlagworte
- Sharepoint Fachinformatiker Ausbildung; Microsoft; Feature; Projektarbeit; Projektbericht Google Maps; Bing Maps; Google .NET Framework; C#.NET C-Sharp