Entwicklung einer browserbasierten Packmittelverwaltung ......SAPUI5 ist ein von SAP entwickeltes MVC-Framework, welches auf HTML5, CSS und JavaScript basiert, mehr als 400 UI-Elemente

Entwicklung einer browserbasierten Packmittelverwaltung

mittels der SAPUI5-Technologie

Björn Theuerkauf

Dokumentation zur betrieblichen Projektarbeit von

Björn Theuerkauf

Identnummer: 854755

zur Erlangung des Abschlusses als

Fachinformatiker

Anwendungsentwicklung

Ausbildungsbetrieb:

SCHÜTZ GmbH & Co. KGaA

Schützstraße 12

56242 Selters

Projektbetreuer: Herr Schwarz

Ausführungszeit: 26.03-09.04.18

Entwicklung einer browserbasierten

Packmittelverwaltung mittels der

SAPUI5-Technologie



Björn Theuerkauf

Inhaltsverzeichnis

1 Einleitung ....................................................................................................................... 1

1.1 Projektauftrag .......................................................................................................... 1

1.2 Projektbeschreibung ................................................................................................ 1

1.3 Projektziel ............................................................................................................... 2

1.4 Projektumfeld .......................................................................................................... 2

1.5 Projektbegründung .................................................................................................. 2

1.6 Projektschnittstellen ................................................................................................ 3

1.6.1 Technische Schnittstellen ................................................................................. 3

1.6.2 Fachliche Schnittstellen .................................................................................... 3

1.7 Projektabgrenzung .................................................................................................. 3

2 Projektplanung ............................................................................................................... 3

2.1 Projektphasen ......................................................................................................... 3

2.2 Ressourcenplanung ................................................................................................ 4

2.3 Entwicklungsprozess ............................................................................................... 4

3 Analysephase ................................................................................................................. 4

3.1 Ist-Analyse .............................................................................................................. 4

3.2 Wirtschaftlichkeitsanalyse ....................................................................................... 4

3.2.1 Make-Or-Buy-Analyse ...................................................................................... 4

3.2.2 Projektkosten ................................................................................................... 4

3.2.3 Amortisationsrechnung ..................................................................................... 5

3.3 Nicht-finanzielle Vorteile .......................................................................................... 5

3.4 Use-Cases .............................................................................................................. 5

4 Entwurfsphase ............................................................................................................... 6

4.1 Zielplattform ............................................................................................................ 6

4.2 Architekturdesign .................................................................................................... 6

4.3 Datenmodell ............................................................................................................ 6

4.4 Entwurf der Benutzeroberfläche .............................................................................. 7



Björn Theuerkauf

4.5 Geschäftslogik ......................................................................................................... 7

4.6 Qualitätssicherung................................................................................................... 8

5 Implementierungsphase ................................................................................................. 8

5.1 Implementierung der Datenstrukturen ..................................................................... 8

5.2 Implementierung des OData-Service ....................................................................... 8

5.3 Implementierung des Frontend ................................................................................ 9

6 Test -und Korrekturphase ............................................................................................... 9

7 Abnahme und Einführung ..............................................................................................10

7.1 Mitarbeiterschulung ................................................................................................10

8 Dokumentation ..............................................................................................................10

9 Fazit ..............................................................................................................................10

10 Anhang ..........................................................................................................................11

10.1 Fehleranfälligkeit der Excel-Lösung - Wertüberschreibung .....................................11

10.2 Projektplanung - Grober Zeitplan ............................................................................12

10.3 Projektplanung - Ressourcenplanung .....................................................................13

10.3.1 Eclipse Plugins für ABAP Entwicklung ............................................................14

10.4 Erweitertes Wasserfallmodell – Erläuterung ...........................................................14

10.5 Wirtschaftlichkeitsanalyse - Personalkosten des Projektes .....................................15

10.6 Use-Case-Diagramm ..............................................................................................16

10.7 Architekturdesign - MVC-Modell .............................................................................17

10.8 Entwurf des Datenmodells ......................................................................................17

10.9 Entwurf der Benutzeroberfläche .............................................................................19

10.10 Implementierung der Datenstrukturen .................................................................20

10.11 Implementierung des OData-Service ..................................................................21

10.12 Implementierung des Frontend ...........................................................................22

10.12.1 Benutzeroberflächen ....................................................................................25

10.13 Auszüge des Quellcodes ....................................................................................29

10.13.1 Allgemeine Funktionen ................................................................................29

10.13.2 OData-Service .............................................................................................31



Björn Theuerkauf

10.13.3 Frontend ......................................................................................................37

10.14 Abweichungen im Zeitplan ..................................................................................43

10.15 Auszüge der praxisüblichen Unterlagen ..............................................................44

10.15.1 Benutzerhandbuch.......................................................................................44

10.15.2 Entwicklerdokumentation .............................................................................45

10.16 Begleitschein ......................................................................................................46



Björn Theuerkauf

Abbildungsverzeichnis

Abbildung 1 Fehleranfälligkeit - Wertüberschreibung ............................................................11

Abbildung 2 Eclipse Plugins ABAP .......................................................................................14

Abbildung 3 Use Case Diagramm ........................................................................................16

Abbildung 4 MVC-Modell ......................................................................................................17

Abbildung 5 Register der Excel-Lösung ................................................................................17

Abbildung 6 Inhalt des Registers Daten ................................................................................17

Abbildung 7 OData-Model ....................................................................................................18

Abbildung 8 Einstiegsmaske Excel-Lösung ..........................................................................19

Abbildung 9 Tabellenstruktur ZPACKMANCONNOTE ..........................................................20

Abbildung 10 Tabellenstruktur ZPACKMANSTGELOC .........................................................21

Abbildung 11 Frontend - Generierte Projektstruktur ..............................................................22

Abbildung 12 Frontend - erweiterte Projektstruktur ...............................................................23

Abbildung 13 GUI - Einstiegsmaske .....................................................................................25

Abbildung 14 GUI - Anlieferung erfassen..............................................................................26

Abbildung 15 GUI - Tausch von Abladestelle erfassen .........................................................26

Abbildung 16 GUI - Rücklieferung von Abladestelle .............................................................27

Abbildung 17 GUI - Rückgabe an Spediteur .........................................................................27

Abbildung 18 GUI - Auswertung pro Abladestelle .................................................................28

Abbildung 19 GUI - Auswertung Spediteur ...........................................................................29

Abbildung 20 Quellcode - NUMBER_GET_NEXT ................................................................29

Abbildung 21 Quellcode - TileNavigation.view.xml ...............................................................30

Abbildung 22 Code - CONNOTESET_CREATE_ENTITY ....................................................31

Abbildung 23 Quellcode - CONNOTESET_DELETE_ENTITY ..............................................32

Abbildung 24 Quellcode - CONNOTESET_GET_ENTITY ....................................................32

Abbildung 25 Quellcode - CONNOTESET_GET_ENTITYSET Teil 1 ....................................33



Abbildung 28 Quellcode - CONNOTESET_UPDATE_ENTITY .............................................36



Björn Theuerkauf

Abbildung 29 Code - CarrierSet Mockdaten .........................................................................37

Abbildung 30 Code - Mockdaten metadata.xml ....................................................................38

Abbildung 31 Code - TileCollection TileNavigation ...............................................................39

Abbildung 32 Code - manifest.json Routing ..........................................................................40

Abbildung 33 Code - index.html ............................................................................................41

Abbildung 34 Code - TileNavigation.controller.js ..................................................................42

Abbildung 35 Auszug des Benutzerhandbuchs ....................................................................44

Abbildung 36 Auszug der Entwicklerdokumentation .............................................................45

Abbildung 37 Begleitschein ..................................................................................................46



Björn Theuerkauf

Tabellenverzeichnis

Tabelle 1 Grober Zeitplan .....................................................................................................12

Tabelle 2 Ressourcenplanung ..............................................................................................14

Tabelle 3 Stundensätze Mitarbeitergruppen .........................................................................15

Tabelle 4 ProjektkostenermittlungUse-Case Diagramm ........................................................16

Tabelle 5 Abweichungen im Zeitplan ....................................................................................43



Björn Theuerkauf

Literaturverzeichnis

Bolz, M. (20. Mai 2014). Von heise.de: https://www.heise.de/developer/artikel/Daten-

exponieren-mit-OData-und-Apache-Olingo-2190973.html?seite=all abgerufen

ITEMIS AG. (19. Januar 2015). Von https://blogs.itemis.com/:

https://blogs.itemis.com/de/scrum-kompakt-wasserfallmodell abgerufen

SAP COMPONENT. (kein Datum). Von

https://help.sap.com/viewer/468a97775123488ab3345a0c48cadd8f/7.4.19/en-

US/27ce0e4987cd426f8fa3e60836316428.html abgerufen

SAP MANDT. (kein Datum). Von help.sap.com:

https://help.sap.com/saphelp_erp60_sp/helpdata/de/5d/a9463c288dbc5de10000000a

11402f/frameset.htm abgerufen

SAP MVC. (kein Datum). Von help.sap.com:

https://help.sap.com/saphelp_uiaddon20/helpdata/en/91/f233476f4d1014b6dd926db0

e91070/frameset.htm abgerufen



Björn Theuerkauf

Abkürzungsverzeichnis

API Application Programming Interface

VBA Visual Basic for Applications

MVC Model View Controller

ABAP Advanced Business Application Programming

CSS Cascading Style Sheets

HTML Hypertext Markup Language

UI User Interface

ZWE Zentraler Wareneingang

OData Open Data Protocol

SAPUI5 SAP User Interface for HTML 5

REST Representational State Transfer

URI Uniform Resource Identifier

HTTP Hypertext Transfer Protocol

ERP Enterprise Resource Planning

EE Enterprise Edition

IDE Integrated Development Environment

GUI Graphical User Interface

GWP Gateway Produktiv

URL Uniform Resource Locator

CRUD Create Read Update Delete

PaaS Platform as a Service

WYSIWYG What You See Is What You Get

XML Extensible Markup Language



Björn Theuerkauf

Syntaktische Hinweise

Auf dieser Seite finden Sie Hinweise bezüglich der Syntax der Projektdokumentation. Diese

sollen Ihnen zum besseren Verständnis und einer erhöhten Lesbarkeit dienen.

Abkürzungen

Im Text auftretende Abkürzungen sind blau markiert. Diese werden im Abkürzungsverzeichnis

ausgeschrieben.

Zitate

Zitate, gleich ob direkt oder indirekt, werden durch einen in der Fußnote angehangenen,

eingeklammerten Verweis gekennzeichnet. Dieser Verweis findet sich im Literaturverzeichnis

wieder und wird dort genauer definiert.

Anlagen

Auf Informationen, welche sich in den Anlagen finden, beispielsweise Abbildungen oder

Tabellen, wird durch Kursivschrift hingewiesen.

z.B.: Abbildung 1 Fehleranfälligkeit - Wertüberschreibung oder

siehe Anlage 10.1

Fachbegriffe

Wenn ein Fachbegriff erstmalig erscheint, so ist er durch eine Hochzahl gekennzeichnet. Die

Erklärung dieses Fachbegriffes findet sich in der Fußnote wieder.



Björn Theuerkauf 1

1 Einleitung

Die folgende Projektdokumentation beschreibt die Durchführung des IHK Abschlussprojektes, welches der Autor im Rahmen seiner Ausbildung zum Fachinformatiker Anwendungsentwicklung durchgeführt hat.

Der Ausbildungsbetrieb ist die Schütz GmbH & Co. KGaA.

1.1 Projektauftrag

Entwickeln einer browserbasierten Packmittelverwaltung1 mithilfe der SAPUI5-Technologie zur Ablösung einer bestehenden Excel-Lösung.

1.2 Projektbeschreibung

In der Vergangenheit hatte die Firma Schütz GmbH & Co. KGaA nur eingeschränkte Möglichkeiten mittels ihrem SAP-System die Bewegungen und Salden der Packmittel im Außenverhältnis zu Spediteuren sowie im Innenverhältnis zu den einzelnen Produktionsbereichen darzustellen. Dies führte immer wieder zu nicht kontrollierbaren Rechnungsstellungen mitgelieferter Packmittel durch Spediteure. Zudem nahmen einige Berufskraftfahrer mehr Packmittel, insbesondere Europaletten, wieder mit zurück, als sie lieferten.

Um diesen Missständen entgegenzuwirken, entschied man sich dafür, angelieferte Packmittel im zentralen Wareneingang zu erfassen und den entsprechenden Berufskraftfahrern einen Begleitschein2 auszustellen. Die dabei erfassten Informationen werden gespeichert, um einen Überblick über die Salden verschiedener Spediteure zu haben.

Dies wird seit einigen Jahren mittels einer um VBA-Code erweiterten Excel-Datei erledigt. Dort wird die Ankunft eines Lastkraftwagens erfasst und ein Formular mit den Informationen über die Spedition, die Menge und Art der Packmittel(Europaletten/Gitterboxen) sowie über die Abladestelle3 erzeugt und ausgedruckt. Diesen Ausdruck nimmt der Fahrer mit und lässt sich das Abladen sowie das Tauschen der Paletten/Gitterboxen unterzeichnen. Er bestätigt zudem noch mit seiner Unterschrift, dass er die getauschten Packmittel erhalten hat.

Darüber hinaus werden die Packmittel mit Hilfe der zuvor erwähnten Datei intern umgelagert. Zusätzlich ist es möglich die gespeicherten Informationen nach Spediteur und nach Abladestelle auszuwerten, um so einen Überblick über die Salden der verschiedenen Speditionen sowie die örtliche Verteilung eigener Packmittel zu bekommen.

Diese Excel-Datei führt aufgrund ihrer Fehleranfälligkeit allerdings oft zu Problemen, wie das Arbeiten mit verschiedenen Kopien, Überschreiben programmrelevanter Zellen, in denen gewisse Werte erwartet werden oder fehlerhafte Sicherheitsoptionen, die das Ausführen von Makros verhindern. Zudem werden in dieser Excel-Datei Informationen über Spediteure und Abladestellen gespeichert sowie manuell eingepflegt/bearbeitet, was eine Redundanz zu unseren Daten im SAP-System darstellt.

Aus den vorgenannten Gründen hat die Leitung der IT-Abteilung mich damit beauftragt, im Rahmen meines Abschlussprojekts, die bestehende Excel-Lösung mit einer SAPUI5-Anwendung abzulösen. SAPUI5 ist ein von SAP entwickeltes MVC-Framework, welches auf HTML5, CSS und JavaScript basiert, mehr als 400 UI-Elemente beinhaltet und zur Kommunikation mit dem SAP-System das OData-Protokoll verwendet. Es ist somit für die Entwicklung von Web-Applikationen prädestiniert. Die Implementierung der Geschäftslogik im Backend geschieht mittels der Programmiersprache ABAP.

1 Der Begriff Packmittel beinhaltet sowohl Paletten, als auch Gitterboxen 2 siehe Abbildung 37 Begleitschein S.46 3 Eine Abladestelle ist ein Gebäude auf dem Produktionsgelände



Björn Theuerkauf 2

Das Projekt soll mithilfe der SAPUI5-Technik umgesetzt werden, da die Firma Schütz seit 18 Jahren SAP-Lösungen im Einsatz hat und verstärkt in diese Richtung, weg von der klassischen SAP-Benutzeroberfläche, gehen möchten. Zudem ist die Anwendung dann auf einem aktuellen Stand der Technik und bietet im Gegensatz zu der bestehenden Excel-Lösung eine Integration in unser SAP-System.

Die in diesem Projekt anfallenden Aufgaben werden alle von mir bearbeitet. Darunter fällt die Analyse der derzeitigen Handhabung und Abläufe, das Entwerfen der neuen Anwendung sowie die letztliche Entwicklung und Dokumentation.

1.3 Projektziel

Ziel des Projektes ist die Entwicklung und Einführung einer Webbrowser-gestützten SAPUI5 Anwendung, welche die gleiche Funktionalität wie die unter Top 1.2 Projektbeschreibung S.1 beschriebene Excel-Anwendung hat, jedoch im Vergleich zu dieser wesentlich weniger Fehleranfälligkeit besitzt und somit stabiler läuft.

Erreicht werden soll hierdurch, dass der laufende Betrieb nicht mehr durch Fehler seitens der Packmittelverwaltung gestört wird.

1.4 Projektumfeld

Die Kernkompetenz von SCHÜTZ als Technologieunternehmen liegt in der Metall- und Kunststoffverarbeitung. An unserem Stammsitz in Selters und an den weltweiten Standorten der internationalen SCHÜTZ Gruppe entwickeln, fertigen und vertreiben wir mit über 4.100 Mitarbeitern innovative Produkte und patentierte Fertigungsverfahren.

Dabei ist es unsere Strategie, die verwendeten Technologien bis in die Tiefe selbst zu beherrschen. Die zentrale IT-Abteilung, in der ich als Auszubildender Fachinformatiker Anwendungsentwicklung tätig bin, ist im Hauptsitz des Unternehmens in Selters angesiedelt. Derzeit sind rund 60 Mitarbeiter in dieser Abteilung beschäftigt, von der aus alle IT-Services für die weltweiten Standorte bereitgestellt werden.

Die Umsetzung des Projekts findet in der Zentrale des Unternehmens in Selters statt. Als betriebsinterne Ansprechpartner für das Projekt sind Herr Karsten Klein und Herr Hans-Jürgen Weingart vorgesehen.

1.5 Projektbegründung

Die Hauptschwachstelle der vorhandenen (Excel-)Lösung ist die Fehleranfälligkeit. Da täglich rund 200 Lastkraftwagen bei der Firma Schütz in Selters eintreffen und jeder dieser LKWs zur Stauvermeidung zeitnah abgefertigt werden muss, ist es notwendig, dass die Packmittelverwaltung reibungslos funktioniert.

Derzeit treten häufig sehr triviale Fehler auf, die zwar einfach zu lösen, aber oftmals schwer zu finden sind. Wie z.B.:

Wertüberschreibung - wie in der Abbildung 1 Fehleranfälligkeit - Wertüberschreibung(siehe Anlage 10.1 S.11) zu sehen, wird der Wert der markierten Zeile versehentlich überschrieben/gelöscht, was dazu führt, dass keine neuen Begleitscheine angelegt werden können, da sich die Programmlogik der Excel-Lösung auf diese fortlaufende Nummer bezieht. Das Arbeiten mit versch. Kopien - ferner kommt es dazu, dass sich Mitarbeiter im zentralen Wareneingang aus verschiedensten Gründen Kopien dieser Excel-Datei machen und mit diesen arbeiten. Folgen sind die dezentrale Speicherung verschiedener Begleitscheine, was bei Rückfragen zur langwierigen Suche anderer Mitarbeiter führt. Außerdem sind die Lagerbestände der Lagerorte in der "führenden" Excel-Datei nicht korrekt.



Björn Theuerkauf 3

Sicherheitsoptionen - um Makros und VBA-Code in Excel- oder Word-Dateien nutzen zu können, müssen diese "aktiviert" sein. Da die Betriebssysteme und Anwendungen auf all unseren Computern nicht gleichermaßen konfiguriert sind (aufgrund von Individuallösungen, Auslassen von Neustarts usw.), kommt es vor, dass manche Benutzer diese Sicherheitsoptionen manuell anpassen müssen.

Neben den aufgeführten Fehlerquellen spricht noch die Tatsache der doppelten Datenhaltung- und Pflege (SAP-System und Excel-Datei) von z.B. Speditionen, gegen die Excel-Lösung.

1.6 Projektschnittstellen

1.6.1 Technische Schnittstellen

Die Kommunikation zwischen der Packmittelverwaltung und dem SAP-System -in welchem alle relevanten Daten abgespeichert sind/werden- soll mit Hilfe eines Protokolls, dem sogenannten OData, umgesetzt werden.

"Das Open Data Protocol (OData) ermöglicht das Erstellen von REST-basierten Datendiensten, welches erlauben, Ressourcen, die über Uniform Resource Identifiers (URIs) identifiziert werden und in einem Datenmodell definiert sind, mittels der Verwendung von HTTP-Nachrichten, durch Web-Clienten zu veröffentlichen und zu bearbeiten."4

1.6.2 Fachliche Schnittstellen

Betreut wird der Autor während der Durchführung des Projektes zum einen von Herrn Karsten Klein, der mit technischem Wissen zur Seite steht, und zum anderen von Herrn Hans-Jürgen Weingart, welcher mit fachlichem Rat unterstützt.

Die Endbenutzer der Anwendung sind Kollegen aus dem ZWE, welche ebenfalls jederzeit um fachlichen Beistand gebeten werden können.

1.7 Projektabgrenzung

Die IHK Koblenz legte eine zeitliche Abgrenzung von 70 Stunden fest.

Das Projekt soll die bestehende Excel-Lösung nicht anpassen und/oder optimieren, sondern durch eine SAPUI5-Webanwendung ersetzen.

Der SAP Gateway-Server5, welcher die Schnittstelle zwischen dem Backend-System und dem Frontend -welches mittels OData und HTTP Daten konsumiert- darstellt, wird nicht vom Autor implementiert/konfiguriert, da dies bereits in der Vergangenheit zu anderen Zwecken von Arbeitskollegen erledigt wurde. Lediglich die Services, welche die entsprechende Funktionalität des Datenaustauschs zur Verfügung stellen, müssen dort vom Autor implementiert werden.

Des Weiteren müssen Tabellen für die Datenhaltung von Spediteuren, Lieferanten und Kunden nicht angelegt werden, da diese standardmäßig im Datenbanksystem der SAP, genauer im ERP, enthalten sind.

2 Projektplanung

2.1 Projektphasen

Dem Autor standen 70 Stunden für die Umsetzung des Projektes zur Verfügung. Diese wurden vor Projektbeginn in mehrere Phasen unterteilt, welche sich der Tabelle 1 Grober Zeitplan(siehe Anlage 10.2 S.12) entnehmen lassen.

4 (Bolz, 2014) 5 Kann Geräte, Plattformen und andere Umgebungen mit dem SAP-System verbinden



Björn Theuerkauf 4

2.2 Ressourcenplanung

Eine Übersicht der vom Autor genutzten Ressourcen befindet sich in der Anlage 10.3 Projektplanung - Ressourcenplanung S.13. Hier sind sowohl alle benötigten Software- als auch Hardware- und Personalressourcen aufgeführt.

2.3 Entwicklungsprozess

Bevor mit der Durchführung des Projektes begonnen werden konnte, musste sich der Autor für einen geeigneten Entwicklungsprozess entscheiden, der im Verlaufe der Umsetzung durchlaufen wurde. Der Autor entschied sich für das erweiterte Wasserfallmodell, welches unter der Anlage 10.4 Erweitertes Wasserfallmodell – Erläuterung S.14 näher erläutert wird.

Durch diese Entscheidung ist der Autor in der Lage, stetig Tests während der Implementierungsphase durchzuführen, um die Funktionalität des Quelltextes zu prüfen. Außerdem kann er während der Oberflächenmodellierung zusammen mit dem Fachbereich Rücksprache halten, um so schon frühzeitige Design-Fehler auszumerzen.

Dieses Modell erwies sich bereits in der Vergangenheit als praktikabel.

3 Analysephase

3.1 Ist-Analyse

Wie bereits vom Autor im Abschnitt 1.2 Projektbeschreibung S.1 und im Abschnitt 1.5 Projektbegründung S.2 beschrieben, leidet die derzeit produktiv genutzte Packmittelverwaltung, welche mithilfe einer um VBA-Code erweiterten Excel-Datei umgesetzt wurde, unter einer hohen Fehleranfälligkeit, welche regelmäßig zur Störung des Betriebes führt, indem Lastkraftwagenfahrer auf ihre Papiere (Begleitschein) warten müssen.

Hinzu kommt, dass Stammdaten6 welche in SAP gepflegt werden, zusätzlich in der Excel-Lösung abgespeichert werden und somit Redundanzen bilden.

3.2 Wirtschaftlichkeitsanalyse

Da die Ablösung der derzeitigen Excel-Lösung früher oder später stattfinden muss, da sonst die steigende Flut an LKW-Fahrern nicht mehr abgefertigt werden kann bzw. die Auswirkungen eines wie in Abschnitt 1.5 Projektbegründung S.2 beschriebenen Fehlers zu fatal wäre, gilt es nun in den folgenden Abschnitten zu klären, ob die Realisierung dieses Projektes auch aus wirtschaftlicher Perspektive gerechtfertigt ist.

3.2.1 Make-Or-Buy-Analyse

Da Individualsoftware bzw. bereits entwickelte Software im SAP-Umfeld meist sehr teuer ist, entschied sich die Leitung der IT-Abteilung für eine Eigenentwicklung.

3.2.2 Projektkosten

Ein wichtiger Aspekt bei der Wirtschaftlichkeitsanalyse des Projektes sind die Kosten, welche die Durchführung erzeugt.

Die Kalkulation hierfür findet aufgrund von Personalkosten statt, welche der Geheimhaltung unterliegen und sich entsprechend nur dem realen Wert annähern.

Die Stundensätze der verschiedenen im Projekt involvierten Mitarbeiter(-gruppen) sind in der Tabelle 3 Stundensätze Mitarbeitergruppen S.15 aufgeführt.

6 Grundinformationen über Objekte welche betrieblich relevant sind.



Björn Theuerkauf 5

Für die Berechnung der Projektkosten wurden lediglich die Personalkosten betrachtet, da genutzte Hard -und Software bereits vorhanden ist und nicht ausschließlich für den Zweck dieses Projektes angeschafft worden ist.

Unter Berücksichtigung dieser Aspekte belaufen sich die Kosten für die Durchführung des Projektes auf 1.190,00 €. Die Herkunft dieses Betrages sowie die einzelnen Positionen lassen sich der Tabelle 4 Projektkostenermittlung S.16 entnehmen.

3.2.3 Amortisationsrechnung

Im folgenden Abschnitt soll ermittelt werden, ob und ab wann sich die entwickelte Anwendung amortisiert hat. Mithilfe dieses Ergebnisses lässt sich dann entscheiden, ob die Umsetzung des Projektes auch aus wirtschaftlicher Sicht attraktiv ist.

Um die Amortisationsdauer errechnen zu können werden sowohl die Projektkosten, als auch die Einsparungen, welche durch die Nutzung der neuen Packmittelverwaltung einhergehen, benötigt.

Die Einsparnisse setzen sich aus den Stunden zusammen, in denen kein Mitarbeiter der IT-Abteilung Fehler beheben muss, welche derzeit noch durch die Excel-Lösung, wie in Abschnitt 1.5 Projektbegründung S.2 erläutert, verursacht werden.

Der zuständige Mitarbeiter der IT Abteilung, welcher die Excel-Lösung vor ca. vier bis fünf Jahren entwickelt hat, schätzt drei Stunden pro Monat Service für diese Excel-Lösung zu leisten. Da man nie ausschließen kann, dass Support für eine Anwendung geleistet werden muss, rechnet der Autor mit einem monatlichen Aufwand von einer Stunde für die im Rahmen des Projektes entwickelte Packmittelverwaltung. Hieraus ergibt sich eine Zeiteinsparung durch Einführung der neuen Packmittelverwaltung von zwei Stunden pro Monat.

Auf Grundlage dessen wird die Amortisationsdauer berechnet. Dafür teilt man die Projektkosten in Höhe von 1.190€ durch den monatlichen Rückfluss von 60€7 und erhält ein Ergebnis von ca. 20 Monaten8.

3.3 Nicht-finanzielle Vorteile

Wie bereits im Abschnitt 3.2 Wirtschaftlichkeitsanalyse S.4 erläutert, ist die Umsetzung des Projektes auch aus wirtschaftlicher Sicht interessant. Die Gründe, welche letztlich zu der Entscheidung führten dieses Projekt umzusetzen, sind allerdings nicht monetär. Denn neben der Kosteneinsparung ist die Durchführung hauptsächlich wegen der Beseitigung der im Abschnitt 1.5 Projektbegründung S.2 aufgeführten Schwachstellen attraktiv. Mit dieser Anwendung kann also für einen reibungsloseren Betrieb, Stauvermeidung von LKWs am zentralen Wareneingang, stressfreierem Arbeiten entsprechender Mitarbeiter und Entlastung des bereits erwähnten IT-Mitarbeiters gesorgt werden. Diese Vorteile stellen für die Firma Schütz und allen beteiligten Personen einen höheren Mehrwert als die rein wirtschaftlichen Aspekte dar.

3.4 Use-Cases

Um eine bessere Übersicht der derzeitig in der Excel-Lösung verwendeten Funktionen zu erhalten, fertigte der Autor während der Analysephase ein Use-Case Diagramm an. Dieses soll ihm die spätere Planung der Anwendung erleichtern, indem es die Funktionen abbildet, welche aus Anwendersicht benötigt bzw. bereits genutzt werden.

Hierfür hat der Autor sich stark an dem GUI der Excel-Lösung orientiert, da dort alle angebotenen Funktionen in Form von Buttons bereits "visualisiert" sind. Die Möglichkeit eine neue Spedition hinzuzufügen, zu bearbeiten oder gar zu löschen, fällt ganz weg, da die

7 zwei Stunden * Stundensatz in Höhe von 30€ 8 dieses Ergebnis ist gerundet, das tatsächliche Ergebnis lautet: 19,833



Björn Theuerkauf 6

Notwendigkeit dieser Tätigkeiten durch die Datenhaltung und Datenpflege im SAP System nicht mehr gegeben ist. Diese Aufgaben werden bereits durch Mitarbeiter einer anderen Abteilung erledigt und somit sind die Daten garantiert vorhanden, da andernfalls der Transportauftrag9 nicht angelegt werden könnte (z.B. bei fehlender Spedition).

Das erstellte Use-Case Diagramm findet sich in der Abbildung 3 Use Case Diagramm S.16.

4 Entwurfsphase

4.1 Zielplattform

Die im Zuge des Projektes vom Autor entwickelte SAPUI5-Anwendung wird in dem produktiven Gateway-System der SAP-Datenbank, dem sogenannten GWP, zur Verfügung gestellt. Mittels des SAP-Standard10 Programms "/UI5/UI5_REPOSITORY_LOAD" wird das Projekt in das bereits erwähnte Gateway-System hochgeladen.

Die Packmittelverwaltung lässt sich dann von den Usern per Webbrowser ihrer Wahl aufrufen.

4.2 Architekturdesign

Das Unternehmen SAP entschied die Entwicklung der UI5-Applikationen auf einem sogenannten MVC-Architekturmuster aufzubauen. Das Hauptmerkmal dieses Architekturmusters ist die strikte Trennung der Präsentation von Informationen(View), den Benutzerinteraktionen sowie die datenverarbeitende Geschäftslogik(Controller) und dem Datenmodell(Model), dessen Daten mit den entsprechenden Views gebunden werden(Data binding).

Aus dieser Trennung ergeben sich einige Vorteile, wie z.B.:

Bessere...

...Lesbarkeit

...Wartbarkeit

...Erweiterbarkeit

Zudem kann man Views anpassen ohne die darunter liegende Geschäfts -und Verarbeitungslogik anpassen zu müssen. Außerdem lassen sich beliebig viele Views für eine Datengrundlage anlegen.11

Um die Zusammenhänge der MVC-Komponenten zu verdeutlichen befindet sich im Anhang die Abbildung 4 MVC-Modell S.17.

4.3 Datenmodell

Um einen Überblick der Daten zu bekommen, welche für die Packmittelverwaltung relevant sind, analysierte der Autor zunächst die bereits bestehende Excel-Lösung.

In dieser Excel-Datei werden über verschiedene Register verteilt alle relevanten Informationen abgespeichert.

In dem Register Daten sind Informationen über Speditionen und Abladeorte abgelegt. Da alle notwendigen Daten über Speditionen in dem Datenbanksystem der Firma Schütz abgelegt sind, bedarf es nicht der Extraktion dieser Daten. Was die Abladestellen angeht sieht das jedoch anders aus. Diese werden zwar ebenfalls in der Datenbank geführt, jedoch enthalten sie nicht alle notwenigen Informationen und haben andere Bezeichnungen, was den Mitarbeitern im ZWE den Einstieg in die neue Packmittelverwaltung erschweren würde. Zudem

9 Ein Paket, mit dem Daten zwischen verschiedenen Datenbankinstanzen transportiert werden. 10 Mit Auslieferung des SAP-Datenbanksystems vorhanden/nicht selbst entwickelt. 11 Vgl. (SAP MVC, kein Datum)



Björn Theuerkauf 7

gibt es einen zusätzlichen Reiter indem die Bestandsführung der Gitterboxen der jeweiligen Abladeorte geführt wird. In dem Register Begleitscheine werden alle erstellten Begleitscheine, mit Informationen über die Spedition, gelieferte & getauschte Gitterboxen/Paletten abgespeichert. Außerdem gibt es noch zusätzliche Register für die Auswertungen der Abladestellen, Spediteure oder des ZWE.

Zur Veranschaulichung wurden beispielhaft Auszüge der Excel-Datei im Anhang 10.8 Entwurf des Datenmodells S.17 zur Verfügung gestellt.

Auf Grundlage dieser Analyse erstellte der Autor mithilfe der IDE eclipse und dem Plugin Ogee12 ein Odata-Model, welches die künftige Datenschnittstelle zwischen dem SAP-Datenbanksystem und der SAPUI5 Packmittelverwaltung darstellt. Dieses Modell wird als Service im Gateway-System registriert und die CRUD-Methoden des OData-Models sind über entsprechende URLs ansprechbar. Anhand dieses Modells lassen sich die notwendigen Tabellen ablesen. Die Entitäten, zu denen noch manuell Datenbanktabellen angelegt werden müssen, wurden rot umrahmt.

4.4 Entwurf der Benutzeroberfläche

Zum Entwerfen des GUI traf sich der Autor zunächst mit den entsprechenden Mitarbeitern des ZWE um generelle Designfragen zu klären. Bei diesem Treffen wurden noch keine konkreten GUIs entworfen, lediglich die Idee eines Entwurfes. Die o.g. Mitarbeiter äußerten den Wunsch, dass das Design der neuen Packmittelverwaltung an jenes der bestehenden Excel-Lösung angelehnt wird. Somit ergibt sich aus der Excel-Lösung ein ungefähres Bild der neuen Anwendung, zumindest was die Auf- und Verteilung der Oberflächenelemente betrifft.

Hieraus wurden keine expliziten MockUps13 erstellt, diese werden mithilfe des SAP Web IDE WYSIWYG-Designers während der Erstellung der Views entworfen (on-the-fly14) und nach Absprache mit den Mitarbeitern des ZWE übernommen oder ggf. angepasst. Hierdurch kann der Autor bereits mit der Entwicklung des Backends, den Controllern und den Models beginnen, bevor er zusammen mit den Mitarbeitern die Oberflächen ausgearbeitet hat. Außerdem ist es ihm hierdurch möglich, die Oberflächen zunächst nach eigenem Ermessen zu erstellen um Funktionalitäten während des Entwicklungsprozess zu testen. Die spätere Anpassung der Oberflächen hat keine Auswirkungen auf die Geschäftslogik, da in der MVC-Architektur die Views von den Controllern und den Models getrennt sind.

Die in dem oben erwähnten Gespräch entstandene, grobe Idee des Entwurfes der Anwendung findet sich in der Anlage 10.9 Entwurf der Benutzeroberfläche S.19.

4.5 Geschäftslogik

Da sich die zu implementierenden Klassen und Funktionen erst während der Entwicklungsphase ergeben (z.B. durch die Generierung der Klassen für die CRUD-Methoden der OData-Datenschnittstelle) kann im Vorfeld kein Klassendiagramm erstellt werden. Prinzipiell ist die Implementierung der Geschäftslogik stark von vorherigen Schritten abhängig, denn gerade im Umfeld der MVC-Architektur und dem damit einhergehenden "Programm-Grundgerüst", welches von der SAP Web IDE generiert wird, entstehen schon standardmäßig viele Punkte an denen programmiert werden muss, die dem Autor zum Zeitpunkt des Entwurfs noch nicht bekannt sind. Aufgrund dessen wurde der Programmumfang lediglich mithilfe des UseCase-Diagramms der Abbildung 3 Use Case Diagramm S.16 entworfen. Dadurch sind dem Autor während der Implementierungsphase nicht die Hände gebunden, denn er kann flexibel auf die "generierte Umgebung" reagieren und das Programm den Anforderungen entsprechend entwickeln.

12 Eclipse Plugin zur Modellierung von OData-Models 13 Nachbildungen/Entwürfe von grafischen Oberflächen 14 Spontan, während der Durchführung, nicht im Vorfeld



Björn Theuerkauf 8

Zu der Geschäftslogik im Backend lässt sich noch sagen, dass aus der Abbildung 7 OData-Model S.18 bereits hervorgeht, welche CRUD-Methoden implementiert werden müssen. Zu den Entitäten Customer, Carrier und Vendor müssen die CRUD-Methoden Entitätsname_Get_Entity und Entitätsname_Get _EntitySet implementiert werden, womit die Read-Methoden abgedeckt werden. Sowohl die Create als auch Update und Delete-Methoden werden bei den drei genannten Entitäten nicht implementiert, da es nicht vorgesehen ist, dass Mitarbeiter des ZWE Speditions-, Kunden- oder Lieferantenstammdaten ändern. Für die restlichen Entitäten ConNote und StorageLocation müssen jeweils alle CRUD-Methoden implementiert werden. Diese werden wie folgt benannt. Entitätsname_Get_Entity, Entitätsname_Get_EntitySet, Entitätsname_Create_Entity, Entitätsname_Delete_Entity, Entitätsname_Update_Entity.

4.6 Qualitätssicherung

Zur Sicherung der Qualität der Software ist eine Testphase geplant. Hierbei werden sowohl vom Autor als auch von mindestens einem Mitarbeiter des ZWE und mindestens einem Mitarbeiter der IT Testszenarien on-the-fly15 erstellt und durchgeführt. Auftretende Fehler o.ä. werden im Anschluss vom Autor bearbeitet.

5 Implementierungsphase

5.1 Implementierung der Datenstrukturen

Die Implementierung der Datenstruktur wird vom Autor in dem Entwicklungssystem16, dem TS1, des SAP-Datenbanksystems durchgeführt. Als Grundlage hierfür dient das in der Entwurfsphase entwickelte OData-Model (siehe Anlage Abbildung 7 OData-Model S.18). Zu den im Modell vorhanden Entitäten Vendor, Customer und Carrier sind im SAP-Standard entsprechende Tabellen enthalten und müssen daher nicht manuell vom Autor angelegt werden. Die Tabellen haben folgende Bezeichnungen.

Vendor: LFA1

Carrier: LFA1

Customer: KNA1

Die OData-Entitäten Vendor und Carrier beziehen sich auf dieselbe SAP-Tabelle, da in dieser sowohl Lieferanten(Vendor) als auch Spediteure(Carrier) gespeichert werden. Bei der Firma Schütz wird zwischen diesen wie folgt unterschieden: Lieferanten sind Unternehmen, die uns beispielsweise Materialien verkaufen. Spediteure sind Unternehmen, die uns die gekauften Materialien physikalisch liefern.

Aus den genannten Gründen erstellte der Autor also lediglich die Tabelle ZPACKMANCONNOTE für die Entität ConNote und die Tabelle ZPACKMANSTGELOC für die Entität StorageLocation. Dies geschah mittels der SAP-Transaktion17 SE1118. Auszüge der erzeugten Tabellen finden sich in der Anlage 10.10 Implementierung der Datenstrukturen S.20. Zusammen mit den bereits erwähnten SAP-Standard Tabellen decken die zwei vom Autor angelegten Tabellen die Anforderungen an die Datenbank ab.

5.2 Implementierung des OData-Service

Die prinzipielle Vorgehensweise des Autors bei der Implementierung des OData-Service, welcher die Schnittstelle zwischen Frontend und Datenstruktur darstellt, war wie folgt.

15 Spontan, während der Durchführung, nicht im Vorfeld 16 Datenbankinstanz in der Veränderungen/Entwicklungen vorgenommen werden 17 Ausführbares Programm, bezeichnet durch ein meist vier-stelliges Kürzel 18 Anlegen und bearbeiten von Data Dictionary Objekten(Tabellen, Datentypen,Domänen,...)



Björn Theuerkauf 9

Zunächst wurde in dem Entwicklungssystem TS1 mithilfe der SAP-Transaktion SEGW das während der Entwurfsphase erstellte OData-Model im XML-Format hochgeladen. Daraufhin wurden die Laufzeitartefakte19 generiert. Im Anschluss redefinierte der Autor die entsprechenden CRUD-Methoden. Hierfür wurde die Entwicklungsumgebung eclipse verwendet. Einen beispielhaften Auszug der CRUD-Methoden der OData-Entität ConNote findet sich im Anhang 10.13.2 OData-Service. Wie bereits in Abschnitt 4.5 Geschäftslogik beschrieben, bedarf es bei den Entitäten Vendor, Customer und Carrier lediglich der Implementierung der Methoden Entitätsname_Get_Entity und Entitätsname_Get _EntitySet. Die Erreichbarkeit dieses Services ist in der Anlage 10.11 Implementierung des OData-Service S.21 geschildert.

5.3 Implementierung des Frontend

Zur Entwicklung des Frontend nutzte der Autor die Entwicklungsumgebung SAP Web IDE, welche als PaaS von der Firma SAP zur Verfügung gestellt wird.

Er entschied sich für den Einsatz dieser IDE aufgrund der Möglichkeit, das Grundgerüst einer SAPUI5 Anwendung generieren zu lassen.

Zu Beginn erstellte der Autor also eine neue "QuickStartApplication" und erhielt eine vorgefertigte Projektstruktur mit den entsprechend notwendigen Dateien(siehe Abbildung 11 Frontend - Generierte Projektstruktur S.22 ).

Auf Grundlage dieser Struktur wurde letztlich die Projektstruktur, welche in Abbildung 12 Frontend - erweiterte Projektstruktur S.23 abgebildet und erläutert ist, erstellt.

Die verschiedenen Views wurden mithilfe des in der IDE integrierten WYSIWYG Designers entworfen. Dies geschah zunächst auf der Grundlage des im Anhang befindlichen groben Entwurfs(siehe Anlage 10.9 Entwurf der Benutzeroberfläche S.19).

Nachdem die Views entworfen waren traf sich der Autor erneut mit den entsprechenden Mitarbeitern des ZWE um abzuklären, ob das Design der Anwendung in Ordnung ist. Nach kleinen Änderungen standen die Benutzeroberflächen dann fest. Diese sind dem Anhang 10.12.1 Benutzeroberflächen S.25 zu entnehmen.

6 Test -und Korrekturphase

Aufgrund der Tatsache, dass der Autor während der Entwicklung regelmäßig Tests durchführte und somit die Korrekturphase kleiner ausfiel, war die Test -und Korrekturphase kürzer als zunächst angenommen.

Zusammen mit Herrn Weingart und einem Mitarbeiter aus dem ZWE wurde die Anwendung über vier Stunden hinweg getestet. Hierfür wurden Daten aus dem Produktivsystem20 im JSON Format extrahiert und im Ordner localService/mockdata (siehe Abbildung 12 Frontend - erweiterte Projektstruktur S.23) als Mockdaten abgelegt.

In der Testphase ist aufgefallen, dass am Monitor in der Vollbildansicht eines Browsers die Toolbar am Fuße der Anwendung(enthält die zwei Buttons für das Bestätigen oder Abbrechen der Eingabe) nicht im sichtbaren Bereich war. Dieser Fehler wurde durch das Hinzufügen des Attributes class="sapUiContentPadding" zum Knotenpunkt <Page> gelöst. Des Weiteren sind lediglich einige wenige Unstimmigkeiten in der Formatierung aufgetreten.

Die Korrekturphase war somit nach drei Stunden beendet. Die Dauer der gesamten Test -und Korrekturphase betrug demnach nur sieben, statt der angenommenen zehn Stunden.

19 ABAP-Klassen welche die Geschäftslogik bereitstellen, sollte ein OData-Service genutzt werden. 20 ERP System auf dem das Tagesgeschäft aufbaut und mit dem es arbeitet.



Björn Theuerkauf 10

7 Abnahme und Einführung

Nachdem der bereits erwähnte Entwickler der IT-Abteilung, Herr Karsten Klein, sich den Quellcode angeschaut und für in Ordnung befunden hatte, wurde die Anwendung für den Import in das Produktivsystem freigegeben. Alle Entwicklungen SAP-seitig wurden in einen Transportauftrag gehangen und in das bereits erwähnte Produktivsystem transportiert. Das Frontend wurde im Gateway-Entwicklungssystem hochgeladen und zusammen mit dem OData-Service in das produktive Gateway-System transportiert.

7.1 Mitarbeiterschulung

Durch die Abstimmung mit dem Fachbereich(ZWE) bzgl. der GUIs und der Testphase waren die entsprechenden Endanwender weitestgehend im Umgang mit der Anwendung vertraut. Nichtsdestotrotz betreute der Autor die User zwei Stunden lang im produktiven Betrieb und gab Hilfestellung.

8 Dokumentation

Diese Projektdokumentation beschreibt die einzelnen, vom Autor durchlaufenen Projektphasen. Hinzu kommt sowohl ein Benutzerhandbuch, welches dem Endanwender die Bedienung der Anwendung näher bringen soll, als auch eine Entwicklerdokumentation, welche künftiges bearbeiten/erweitern der Anwendung erleichtern soll. Auszüge der zwei genannten Dokumente finden sich in der Anlage 10.15 Auszüge der praxisüblichen Unterlagen S.44.

9 Fazit

Rückblickend betrachtet kann festgestellt werden, dass alle Anforderungen an die Anwendung in der vorgegebenen Zeit umgesetzt wurden. Dabei traf die Zeitplanung nicht vollends zu, die letztlich benötigten Zeiten für die jeweiligen Phasen wichen allerdings nur geringfügig von der ursprünglichen Planung ab und konnten durch die anderen Phasen ausgeglichen werden. Diese Abweichungen sind der Tabelle 5 Abweichungen im Zeitplan S.43 zu entnehmen.

Die Durchführung des Projektes war eine lehrreiche Aufgabe für den Autor. Neben den wertvollen Erfahrungen in den Themen Planung und Durchführung gewann der Autor ebenfalls einen Einblick in die Wichtigkeit ständiger Kommunikation. Fehler, sowohl im Design als auch in der Geschäftslogik, fallen durch stetige Rücksprachen schneller auf und können früher ausgemerzt werden. Zudem machte der Autor erste proaktive Erfahrungen im Umgang mit der SAPUI5 Technologie des Unternehmens SAP, welche das Fundament für künftige Entwicklungen bilden.

Obwohl alle Anforderungen an die Anwendung erfüllt wurden, sieht der Autor in die Zukunft blickend bereits Erweiterungen an der Software. So wird beispielsweise derzeit ein Yard-Management21 in der Firma Schütz eingeführt, welches die Abwicklung von LKW-Fahrern ein Stück weit automatisieren soll. Derzeit müssten diese LKW-Fahrer jedoch noch immer in den zentralen Wareneingang gehen, um sich dort ihren Begleitschein abzuholen. Diese Aufgabe könnte in Zukunft mithilfe einer Erweiterung der neuen Packmittelverwaltung über ein Self-Service Terminal von den entsprechenden LKW-Fahrern selbst erledigt werden.

21 Koordination und Kontrolle von Frachtbewegungen innerhalb des Betriebsgeländes.




10 Anhang

10.1 Fehleranfälligkeit der Excel-Lösung - Wertüberschreibung

Beispielhafte Fehlerquelle der bestehenden Excel-Lösung. Der markierte Wert wird versehentlich überschrieben, woraufhin es Probleme beim Erstellen von neuen Begleitscheinen gibt.

Abbildung 1 Fehleranfälligkeit - Wertüberschreibung




10.2 Projektplanung - Grober Zeitplan

Projektphase Geplante Zeit

Analyse 3h

Entwurf 10h

Implementierung 30h

Test- und Korrekturphase 10h

Abnahme und Einführung 3h

Dokumentation 12h

Puffer 2h

Gesamt 70h

Tabelle 1 Grober Zeitplan




10.3 Projektplanung - Ressourcenplanung

Art der Ressource Definition der Ressource

Hardware Büroarbeitsplatz mit Desktop-Computer

Software Entwicklungsumgebungen ABAP:

Eclipse Java EE IDE for Web Developers.

o Version: Neon.3 Release (4.6.3)

o Erweitert um die Plugins siehe Anlage

10.3.1 Eclipse Plugins für ABAP

Entwicklung

SAP Transaktionen

o SE80 - Object Navigator

o SE38 - ABAP Editor

o SE24 - Class Builder

Modellierung OData-Model:

Eclipse Plugin Ogee Release 0.7.0

Entwicklungsumgebungen Frontend:

SAP Web IDE

SAP Transaktionen

SE11 - ABAP Dictionary

SEGW - SAP Gateway Service Builder

SNRO - Nummernkreisobjektpflege

SE10 - Transport Organizer

/IWFND/MAINT_SERVICE - Services aktivieren

und verwalten

Datenbanksystem Software: EHP8 FOR SAP ERP 6.0 auf Basis von NetWeaver

7.50

Server Application: Virtuell

Server Application OS: SUSE Linux Enterprise 12 SP2

Server Datenbank: Virtuell




Server Datenbank OS: SUSE Linux Enterprise 12 SP2

Datenbank: SAP Hana 1.0 SP12

Systemlandschaft: 3-Systemlandschaft22

Personal Auszubildender Fachinformatiker für Anwendungsentwicklung

(der Autor) - Durchführung des Projektes

Mitarbeiter der IT-Abteilung - Schnittstelle zur Fachabteilung ZWE

Mitarbeiter der Fachabteilung ZWE - Test und Abnahme der

Software

Tabelle 2 Ressourcenplanung

10.3.1 Eclipse Plugins für ABAP Entwicklung

Abbildung 2 Eclipse Plugins ABAP

10.4 Erweitertes Wasserfallmodell – Erläuterung

Bei diesem Vorgehensmodell wird das Projekt in verschiedene Phasen unterteilt (z.B.: Analyse, Entwurf, Implementierung, Tests, Übergabe) welche nacheinander durchlaufen werden. Es heißt „Wasserfallmodell“, da die Ergebnisse der Phasen immer in die Folgende fließen. Das „Erweiterte Wasserfallmodell“ erlaubt zusätzlich Sprünge in vorherige Phasen. So

22 Ein Datenbanksystem, beispielsweise das ERP, wird bei der Firma Schütz in drei Instanzen gehalten. Zum einen als Entwicklungssystem, im dem Änderungen vorgenommen werden. Diese werden dann in das Qualitätssicherungssystem transportiert, wo die Änderungen getestet werden. Anschließend werden die Änderungen in das Produktivsystem transportiert. Mit diesem System arbeitet der Betrieb.




ist es beispielsweise möglich, immer wieder während der Implementierung Tests durchzuführen.23

10.5 Wirtschaftlichkeitsanalyse - Personalkosten des Projektes

Mitarbeitergruppe Stundensatz

Auszubildender 10 €

Mitarbeiter der IT-Abteilung 30 €

Mitarbeiter des ZWE 25 €

Tabelle 3 Stundensätze Mitarbeitergruppen

Mitarbeiter Anzahl Vorgang Zeit Kosten

24

Auszubildender 1 Analyse & Entwurf 13 h 130 €

Auszubildender 1 Implementierung 30 h 300 €

Auszubildender 1 Tests, Korrekturen und

Abnahme

13 h 130 €

Auszubildender 1 Dokumentation & mögl.

genutzter Puffer

14 h 140 €

Mitarbeiter der

IT-Abteilung

1 Fachliche Hilfe bei Analyse 1 h 30 €

Mitarbeiter der

IT-Abteilung

1 Technische Hilfe bei

Implementierung

2 h 60 €

Mitarbeiter der

IT-Abteilung

1 Abnahme der IT-Leitung 1 h 30 €

Mitarbeiter der

IT-Abteilung

1 Testphase 4 h 120 €

Mitarbeiter des

ZWE

1 Mitwirken beim Entwurf des

GUI

2 h 50 €

23 (ITEMIS AG, 2015) 24 Die Kosten ergeben sich aus der Anzahl der Mitarbeiter * Zeit * Stundensatz




Mitarbeiter des

ZWE

1 Testphase 4 h 100 €

Mitarbeiter des

ZWE

2 Mitarbeiterschulung 2 h 100 €

Gesamtkosten 1.190,00 €

Tabelle 4 ProjektkostenermittlungUse-Case Diagramm

10.6 Use-Case-Diagramm

Abbildung 3 Use Case Diagramm




10.7 Architekturdesign - MVC-Modell

Abbildung 4 MVC-Modell25

10.8 Entwurf des Datenmodells

Die folgende Abbildung zeigt alle Register der bestehenden Excel-Lösung. Die Register GUI, Formular und log sind für die Modellierung des Datenmodells nicht relevant.

Abbildung 5 Register der Excel-Lösung

Die folgende Abbildung zeigt wie derzeit die Informationen der Speditionen und der Abladeorte(Kopfdaten) in dem Register Daten der bestehenden Excel-Lösung abgespeichert werden.

Abbildung 6 Inhalt des Registers Daten

25 (SAP MVC, kein Datum)




Die folgende Abbildung zeigt das während der Entwurfsphase erzeugte OData-Model. Dieses Model wird in das Entwicklungssystem des SAP-Datenbanksystems mithilfe der Transaktion SEGW hochgeladen und dient ab diesem Zeitpunkt, nach Registrierung des damit erstellten Service am Gateway-System, als Datenschnittstelle zwischen dem SAP-System und der SAPUI5 Packmittelverwaltung. Die rot umrahmten Entitäten stellen Datenbanktabellen dar, welche nicht im gewünschten Umfang im SAP-Standard enthalten sind und daher manuell angelegt werden müssen.

Abbildung 7 OData-Model




10.9 Entwurf der Benutzeroberfläche

Die Mitarbeiter des ZWE äußerten in einem persönlichen Gespräch, welches in der Entwurfsphase stattgefunden hatte, den Wunsch, dass sich das Design der neuen Packmittelverwaltung an das Design der bestehenden Excel-Lösung anlehnt. Dadurch fiele es ihnen leichter sich in die neue Anwendung einzuarbeiten was zu einem schnelleren Übergang in das gewohnte Tagesgeschäft führe.

Die Einstiegsmaske der derzeitigen Excel-Lösung sieht wie folgt aus.

Abbildung 8 Einstiegsmaske Excel-Lösung

Die mit einem X markierten Schaltflächen fallen weg, denn zum einen soll der Begleitschein automatisch erstellt werden sobald eine Anlieferung erfasst wurde, zum anderen brauchen die drei anderen Funktionalitäten(siehe Radio-Buttons) keinen extra "Start-Button". Somit fällt die Schaltfläche "Neuen Begleitschein erstellen" weg. Die Funktion dieses Buttons war ohnehin davon abhängig, welche Option ausgewählt war. Die vier Optionen sollen jeweils eine eigene Kachel in der Einstiegsmaske der neuen Packmittelverwaltung bekommen. Des Weiteren fällt die Möglichkeit weg, Speditionsstammdaten zu erfassen/verändern/löschen, denn künftig stehen der Anwendung die Daten aus dem SAP-Datenbanksystem zur Verfügung. Diese Stammdaten werden von Mitarbeitern anderer Abteilungen gepflegt und somit fällt dies nicht in den Aufgabenbereich eines Mitarbeiters des ZWE.




10.10 Implementierung der Datenstrukturen

Abbildung 9 Tabellenstruktur ZPACKMANCONNOTE

Die in der Abbildung 9 Tabellenstruktur ZPACKMANCONNOTE zu sehenden, mit einem Z anfangenden, Datenelemente wurden vom Autor manuell mithilfe der SAP-Transaktion SE11 angelegt. Bei dem Datenelement ZCONNOTEID handelt es sich um ein sogenanntes Nummernkreisobjekt, welches der Autor mithilfe der SAP-Transaktion SNRO anlegte. Dieses stellt die in anderen Datenbanken übliche Funktion der (halb-)automatischen Inkrementierung zur Verfügung. Wenn also ein neuer Begleitschein erstellt wird muss der Autor die Funktion "NUMBER_GET_NEXT" aufrufen, und erhält so die nächste ID(siehe Abbildung 20 Quellcode - NUMBER_GET_NEXT S.29).

Das Feld CLIENT wurde hinzugefügt, damit diese Tabelle nicht mandantenunabhängig ist.

"Der Mandant ist definiert als für sich handelsrechtlich, organisatorisch und datentechnisch abgeschlossene Einheit innerhalb eines SAP-Systems. Das bedeutet, dass alle betriebswirtschaftlichen Daten gegenüber anderen Mandanten geschützt sind. Jeder Mandant verfügt über seine eigenen Kundendaten, die er als sein exklusives Eigentum betrachten kann.

Andererseits bietet ein SAP-System eine für alle Mandanten gemeinsame implementierte Systemlösung, die im zentralen Repository und mandantenübergreifenden Tabellen abgelegt ist (zentraler Datenbestand)."26

26 (SAP MANDT, kein Datum)




Abbildung 10 Tabellenstruktur ZPACKMANSTGELOC

Für die In der Abbildung 10 Tabellenstruktur ZPACKMANSTGELOC S.21 zu sehende Tabelle gilt bzgl. der Felder ID und CLIENT gleiches wie für die Tabelle der Abbildung 9 Tabellenstruktur ZPACKMANCONNOTE S.20.

10.11 Implementierung des OData-Service

Der OData-Service ist über die folgende URL erreichbar:

http://gwtall00.schuetz.org:8010/sap/opu/odata/sap/ZLO_PACKAGING_COCKPIT_SRV/

Beispiele:

Abfrage des Begleitscheins mit der ID 2:

http://gwtall00.schuetz.org:8010/sap/opu/odata/sap/ZLO_PACKAGING_COCKPIT_SRV/ConNoteSet('0000000002')

Abfrage aller Kunden aufsteigend nach Namen sortiert:

http://gwtall00.schuetz.org:8010/sap/opu/odata/sap/ZLO_PACKAGING_COCKPIT_SRV/ CustomerSet?$orderby=Name asc




10.12 Implementierung des Frontend

Abbildung 11 Frontend - Generierte Projektstruktur




Abbildung 12 Frontend - erweiterte Projektstruktur




Die in der Abbildung 12 Frontend - erweiterte Projektstruktur zu sehende Struktur setzt sich aus folgenden Bestandteilen zusammen:

Ordner view o enthält die einzelnen Views im XML Format, beispielhaft findet sich ein solches

View in der Abbildung 21 Quellcode - TileNavigation.view.xml S.30.

Ordner controller o enthält die Controller zu den jeweiligen Views. Diese steuern die

Benutzereingabe/Geschäftslogik. Beispiel: Abbildung 34 Code - TileNavigation.controller.js S.42.

Ordner css o enthält generell .css Dateien, welche die grafische Darstellung von XML/HTML

Elementen festlegen. Generiert wird bereits die Datei style.css welche für das Erstellen eigener Stile dient. Davon sah der Autor jedoch ab, da kein Bedarf bestand vom SAP-Standard abzuweichen.

Ordner i18n o Enthält .properties Dateien welche der Internationalisierung dienen. Hier

werden alle angezeigten Texte abgelegt und können mittels verschiedener .properties Dateien übersetzt werden. Die erste Datei(ohne Länderkürzel) stellt die Fallback Sprache da, sollte die im Browser eingestellte Sprache nicht übersetzt worden sein, werden die Texte aus dieser Datei genutzt.

Ordner localService o Dieser Ordner enthält die Dateien, welche für das Betreiben der Software mit

Mockdaten relevant sind. o Ordner mockdata

Dieser Ordner enthält die konkreten Mockdaten, welche in der Anwendung genutzt werden können und vom Autor während der Entwicklung genutzt wurden. Als Beispiel befindet sich ein Auszug der CarrierSet.json in der Abbildung 29 Code - CarrierSet Mockdaten S.37.

o metadata.xml Diese Datei enthält die Beschreibung des OData-Models im XML

Format und wurde mithilfe der URL http://gwtall00.schuetz.org:8010/sap/opu/odata/sap/ZLO_PACKAGING_COCKPIT_SRV/$metadata erzeugt.

Ordner model o Enthält alle Javascript Dateien, in denen models definiert werden können.

Ordner TileCollections o Enthält alle JSON Dateien, in welchen die Kacheln definiert und

zusammengefasst sind. Als Beispiel hierfür dienen die Kacheln welche in der Einstiegsmaske zu sehen sind (siehe Abbildung 31 Code - TileCollection TileNavigation S.39).

Datei component.js o "The component.js file is the component controller and provides the runtime

metadata and the component methods."27

Datei index.html o Diese Datei enthält das bootstrapping und stellt den Container für die

Anwendung zur Verfügung(siehe Abbildung 33 Code - index.html S.41).

Datei manifest.json o Diese Datei enthält die Metadaten der Anwendung. Z.B.:

Name & Beschreibung der Anwendung Definierte Routen (Navigation innerhalb der Anwendung, siehe

Abbildung 32 Code - manifest.json Routing ) Pfad für die Internationalisierung

27 (SAP COMPONENT, kein Datum)




Dateien .project.json und .user.project.json o Diese Dateien enthalten projektbezogene Einstellung und wurden vom Autor

nicht näher betrachtet.

Datei neo-app.json o Diese Datei stellt den Deskriptor der Anwendung dar mit dem sich die

Verhaltensweise der Anwendung konfigurieren lässt. Diese Datei wurde vom

Autor nicht näher betrachtet.

10.12.1 Benutzeroberflächen

Abbildung 13 GUI - Einstiegsmaske

In Abbildung 13 GUI - Einstiegsmaske ist der Startbildschirm zu sehen. Nach Klicken auf die Kacheln gelangt man zu den entsprechenden Ansichten die folgend zu sehen sind.




Abbildung 14 GUI - Anlieferung erfassen

Zur Abbildung 14 GUI - Anlieferung erfassen: Nach Klick auf den grünen Haken wird auf Grundlage der eingegebenen Daten ein Begleitschein erstellt und ausgedruckt.

Abbildung 15 GUI - Tausch von Abladestelle erfassen




Abbildung 16 GUI - Rücklieferung von Abladestelle

Abbildung 17 GUI - Rückgabe an Spediteur

Zu den Abbildungen:

Abbildung 15 GUI - Tausch von Abladestelle erfassen

Abbildung 16 GUI - Rücklieferung von Abladestelle

Abbildung 17 GUI - Rückgabe an Spediteur

Nach einem Klick auf den grünen Haken wird in jedem dieser Szenarien ein Begleitschein erstellt, jedoch nicht ausgedruckt. Diese Begleitscheine werden persistiert, um Salden sowohl




im Innenverhältnis, also zwischen ZWE und den einzelnen Abladestellen, als auch im Außenverhältnis zu den Spediteuren überblicken zu können. Somit sind die Mitarbeiter des ZWE in der Lage zu überprüfen ob der Spediteur xy, der gerade Paletten/Gitterboxen anfragt, noch welche guthat, oder ob er uns sogar noch welche schuldet. Dem kommt noch hinzu, dass bei entsprechender Knappheit von Packmitteln der ZWE eine Übersicht darüber bekommt, bei welcher Abladestelle er sich diese Packmittel zurückholen kann. Diese Auswertungen sind beispielsweise in Abbildung 18 GUI - Auswertung pro Abladestelle und Abbildung 19 GUI - Auswertung Spediteur dargestellt.

Abbildung 18 GUI - Auswertung pro Abladestelle




Abbildung 19 GUI - Auswertung Spediteur

10.13 Auszüge des Quellcodes

10.13.1 Allgemeine Funktionen

Abbildung 20 Quellcode - NUMBER_GET_NEXT




Abbildung 21 Quellcode - TileNavigation.view.xml




10.13.2 OData-Service

Abbildung 22 Code - CONNOTESET_CREATE_ENTITY




Abbildung 23 Quellcode - CONNOTESET_DELETE_ENTITY

Abbildung 24 Quellcode - CONNOTESET_GET_ENTITY




Abbildung 25 Quellcode - CONNOTESET_GET_ENTITYSET Teil 1












Abbildung 28 Quellcode - CONNOTESET_UPDATE_ENTITY




10.13.3 Frontend

Abbildung 29 Code - CarrierSet Mockdaten

Die Abbildung 29 Code - CarrierSet Mockdaten zeigt einen Ausschnitt aus der Mockdaten Datei CarrierSet.json, welche die Ergebnismenge des OData-Methodenaufruf CARRIERSET_GET_ENTITYSET darstellt.




Abbildung 30 Code - Mockdaten metadata.xml




Abbildung 31 Code - TileCollection TileNavigation




Abbildung 32 Code - manifest.json Routing




Abbildung 33 Code - index.html




Abbildung 34 Code - TileNavigation.controller.js




10.14 Abweichungen im Zeitplan

Projektphase Planung(in Std) Realität(in Std) Differenz(in Std)

Analyse 3 3 0

Entwurf 10 10 0

Implementierung 30 34 +4

Test -und

Korrekturphase

10 7 -3

Abnahme und

Einführung

3 3 0

Dokumentation 12 13 +1

Puffer 2 Genutzt für

Implementierung

0

Gesamt 70 70

Tabelle 5 Abweichungen im Zeitplan




10.15 Auszüge der praxisüblichen Unterlagen

10.15.1 Benutzerhandbuch

Abbildung 35 Auszug des Benutzerhandbuchs




10.15.2 Entwicklerdokumentation

Abbildung 36 Auszug der Entwicklerdokumentation




10.16 Begleitschein

Abbildung 37 Begleitschein

Documents

Entwicklung einer browserbasierten Packmittelverwaltung ......SAPUI5 ist ein von SAP entwickeltes MVC-Framework, welches auf HTML5, CSS und JavaScript basiert, mehr als 400 UI-Elemente