Inhaltsverzeichnis

Inhaltsverzeichnis   

   3

1  Projektbeschreibung  

1.1  Einführung  3

1.2  Projektanstoß  3

1.3  Projektumfeld  3

   3

2  Planungsphase  

2.1  Projektplan  4

2.2  IST-Analyse  4

2.3  Kostenplan  5

2.4  Soll-Konzept  5

2.4.1  Funktionalitäten  5

2.4.2  Sicherheit  6

2.4.3  Integration in bestehende Intranetanwendung  6

   6

3  Entwurfsphase  

3.1  Software-Architektur und eingesetzte Technologien  6

3.2  Bestandteile des Lösungspakets  7

3.2.1  Webparts  8

3.2.2  Maps-Adressliste und Content-Type  9

3.2.3  Setupkomponente  9

   10

4  Implementierungsphase  

4.1  Installation und Konfiguration der Entwicklungsumgebung  10

4.2  Strukturierung Visual Studio Projekt Solution  10

4.3  Entwicklung der Webparts  11

4.4  Maps Adressliste und Content-Type  11

4.5  Zusätzlicher Quellcode  12

   12

5  Testphase  

   13

6  Projektbewertung  

6.1  Zielerreichung  13

6.2  Soll/Ist-Abgleich Projektphasen  13

6.3  Qualitätssicherung  13

6.4  Änderungen gegenüber Projektantrag  14

   14

7  Fazit und Ausblick  

   14

8  Literaturverzeichnis  

   15

9  Anhang  

Pr  üfungsteil A: Betriebliche Projektarbeit - Alexander Röhrig Seite  2/54

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 Tech- nologyAG 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.

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).

Prüfungsteil A: Betriebliche Projektarbeit - Alexander Röhrig Seite 3/54

2.1 Projektplan

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

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.

Prüfungsteil A: Betriebliche Projektarbeit - Alexander Röhrig Seite 4/54

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

Vergleich Kosten für die Planung von Patientenrouten

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.

Prüfungsteil A: Betriebliche Projektarbeit - Alexander Röhrig Seite 5/54

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 SharePoint-Webanwendung 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 ¹ -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 ² -Schemadefinitionen für SharePoint Listen. Die Integration der Geokarte wird über eine Maplet-Server API ³ in JavaScript realisiert.

¹ Windows SharePoint Services

² Extensible Markup Language

³ Application Programming Interface

Prüfungsteil A: Betriebliche Projektarbeit - Alexander Röhrig Seite 6/54

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

3.2 Bestandteile des Lösungspakets

Das Lösungspaket soll als voll funktionsfähige Anwendungserweiterung ⁴ 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 Lösungspaket auf dem SharePoint System installiert

⁴ vergleichbar mit dem Begriff Plugin oder Extension

⁵ Microsoft Corporation

Seite 7/54 Prüfungsteil A: Betriebliche Projektarbeit - Alexander Röhrig

Entwurfsphase

3.2.1 Webparts 6

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

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 ⁷ 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 Webpart-Basisklasse abgeleitet werden, um einen höheren Programmieraufwand zu vermeiden und die Wartbarkeit des Codes zu erhöhen.

Micro- Die abstrakte Basisklasse „MapsWebpart“ leitet von

soft.SharePoint.WebPartPages.WebPart ab und soll gemeinsame Kartenoptionen wie z. B.

⁶ Webpart: in C.NET entwickelter Container für HTML-Quellcode der serverseitig gerendert wird

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

Seite 8/54 Prüfungsteil A: Betriebliche Projektarbeit - Alexander Röhrig

Entwurfsphase

Höhe und Breite der Karten über ein Interface bereitstellen. Die abgeleiteten Klassen besitzen erweiterte kartenspezifische Eigenschaften, wie die Anzeigemöglichkeit verschiedener Kartensteuerelementen. Die Implementierung dieser Eigenschaften wird über eigene Interfaces (~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 ⁸ , einer XML ⁹ -Konfigurationsdatei sowie der im WSP-Format ¹⁰ gepackte Code, der die Maps-Adressliste, den Content-Type sowie der Webparts enthält.

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

⁸ Microsoft, http://sharepointinstaller.codeplex.com/

⁹ Extensible Markup Language

¹⁰ WSP-Format ist ähnlich zip-Format und vom Hersteller empfohlen

Seite 9/54 Prüfungsteil A: Betriebliche Projektarbeit - Alexander Röhrig

Der WSP-Builder ¹¹ (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 ¹² .

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.

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

¹² WSP - Windows SharePoint Solution Package

Prüfungsteil A: Betriebliche Projektarbeit - Alexander Röhrig Seite 10/54

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 ¹³ “, 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 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 Share-Point 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 SharePoint 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.

¹³ Adresshandler - Verbindungsklasse zwischen Adressliste und Webpartklassen

¹⁴ JSHandler -.NET Klasse zum dynamischen Erzeugen von JavaScript Code

Prüfungsteil A: Betriebliche Projektarbeit - Alexander Röhrig Seite 11/54