ID 7341
Christoph Strsembski
Eine Referenzimplementierung
von Web Services zur elektro-
nischen Rechnungsstellung
Diplomarbeit
Universität Dortmund
Fachbereich Informatik
Abgabe Oktober 2003
ID 7341
Strsembski, Christoph: Eine Referenzimplementierung von Web Services zur
elektronischen Rechnungsstellung
Hamburg: Diplomica GmbH, 2003
Zugl.: Universität Dortmund, Universität, Diplomarbeit, 2003
Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte,
insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von
Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der
Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen,
bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung
dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen
der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik
Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich
vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des
Urheberrechtes.
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in
diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme,
dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei
zu betrachten wären und daher von jedermann benutzt werden dürften.
Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können
Fehler nicht vollständig ausgeschlossen werden, und die Diplomarbeiten Agentur, die
Autoren oder Übersetzer übernehmen keine juristische Verantwortung oder irgendeine
Haftung für evtl. verbliebene fehlerhafte Angaben und deren Folgen.
Diplomica GmbH
http://www.diplom.de, Hamburg 2003
Printed in Germany
Zusammenfassung
Web Services sind dabei, vom technisch brillanten Geheimtipp zu einer Standardlösung
für die lose Kopplung verteilter Systeme zu werden. Im Rahmen dieser Diplomarbeit
werden Fragestellungen zum Einsatz von Web Services für die elektronische
Rechnungsstellung angesprochen und praktisch erörtert.
Die vorliegende Arbeit stellt zunächst grundlegende Erfordernisse und Probleme für die
Rechnungsstellung auf elektronischem Wege allgemein und mittels Web Services im
Besonderen dar. Anhand möglichst realitätsnaher Eckdaten werden Anforderungen
analysiert und damit ein Entwurfsprozess mit UML durchgeführt. Dem schließt sich die
Ausführung eines Softwareentwicklungsprozesses und dessen Dokumentation an. Der
so entstandene Prototyp soll bestimmten Leistungsanforderungen gerecht werden. Zur
Überprüfung wird eine Reihe von Lasttests durchgeführt, die die Leistungsfähigkeit
unter realistischen Bedingungen prüfen. Diese Tests führen zur genaueren Analyse von
Schwachstellen und zur Benennung und Behebung der Ursachen.
Abschließend werden Anleitungen und Empfehlungen für die Installation und den
Betrieb der verteilten Anwendung gegeben, welche auf den Erfahrungen dieser Arbeit
beruhen.
Abstract
Web Services are on their way from being rarely used technically sophisticated tools to
becoming a standard integration solution for distributed systems. The implementation of
Electronic Bill Presentment as a Web Service will be the focus of this diploma thesis.
Within this document, the basic requirements and problems of Electronic Bill Present-
ment giving special attention to the usage of Web Services will be analysed. Taking this
realistic base data, a draft of the software development process using UML fulfilling
specific performance demands will be made and documented. Performance tests under
realistic conditions will be run which provide a more exact analysis of bottlenecks and
also locate the causes so that solutions can be made.
Finally guidelines and advice for installation, running and usage of this distributed ap-
plication resulting from the experience of this work will be written.
Inhaltsverzeichnis
Inhaltsverzeichnis
Inhaltsverzeichnis ... 1
1 Einleitung ... 3
1.1 Kontext ... 3
1.2 Zielsetzung... 3
1.3 Struktur der Arbeit ... 5
1.4 Grundlagen... 5
2 Anforderungen ... 9
2.1 Wahl der Analyseform ... 9
2.2 Bedingungen für das System ... 10
2.3 Funktionale Anforderungen... 16
2.4 Nicht-funktionale Anforderungen... 19
2.5 Randbedingungen für das Projekt ... 22
3 Entwurf... 27
3.1 Statisches UML Modell... 27
3.2 Dynamisches UML Modell ... 29
3.3 Infrastruktur ... 31
3.4 Entwurfsentscheidungen... 33
4 Durchführung ... 39
4.1 Verwendete Komponenten ... 39
4.2 Implementierung ... 40
5 Leistungstests ... 54
5.1 Testumgebung... 54
5.2 Leistungsanforderungen ... 57
5.3 Modellierung... 57
5.4 Testplan ... 66
6 Bewertung und Rückkopplung... 68
6.1 Analyse des Lastgenerators ... 68
6.2 Erste Testreihe... 70
6.3 Zweite Testreihe... 72
6.4 Dritte Testreihe ... 78
6.5 Weitere Optimierungsmöglichkeiten ... 85
6.6 Gesamtbewertung... 86
7 Zusammenfassung... 88
7.1 Ausgangssituation ... 88
7.2 Lösungsansatz ... 88
7.3 Umsetzung ... 89
7.4 Probleme ... 89
7.5 Fazit ... 90
Anhang ... 93
A.1 Literaturverzeichnis ... 93
A.2 Benutzerhandbuch ... 96
A.3 Deployment... 102
Einleitung
3
1 Einleitung
1.1 Kontext
Die Geschichte des Word Wide Web umfasst erst ein Jahrzehnt, darin gab es jedoch
schon mehrere Paradigmenwechsel und Umbrüche. Die Zyklen der Wirtschaft und auch
die Wirtschaftsabläufe selbst wurden durch das Internet beeinflusst wie durch kein
Medium zuvor. Doch oft erweisen sich die als Revolution titulierten Entwicklungen als
technisch anspruchsvolle, praktisch aber wenig erfolgreiche Ideen. Nach dem Hoch an
den internationalen Börsen kam die Ernüchterung. Damit traten wieder einfache
betriebswirtschaftliche Fragen, wie zum Beispiel die Abwägung von Kosten und
Nutzen, in den Blickpunkt.
Aus Gründen des Kostendrucks werden in den meisten Bereichen, so auch im IT-
Umfeld, die vorhandenen Architekturen, Prozesse und Produkte hinterfragt und Wege
zur Optimierung gesucht. Ein Schlüssel dazu ist die Standardisierung von Abläufen. Für
die Organisation von komplexen Server- und Middelware-Systemen galt lange Common
Object Request Broker (CORBA) als Standard. Alternativ konnte mit Remote Method
Invocation (RMI) eine proprietäre Lösung erarbeitet werden, wenn es um den
Austausch von Daten zwischen Rechnern oder Systemen ging [AP01]. Diese Techniken
hatten aber aufgrund von hoher Komplexität, mangelnder Eignung zur
Wiederverwertung, fehlender Offenheit und schwerer Beherrschbarkeit deutliche
Schwächen. Wo für die Kommunikation Mensch/Maschine im Internet hohe Standards
formuliert und in vielen Fällen realisiert wurden [GM94], hinkt die automatische
Kommunikation Maschine/Maschine weit hinter dieser Entwicklung her.
Im Januar 2002 wurden Web Services in der Version 1.2 vorgestellt [MH03]. Sie sind
moderne, offene Architekturen, können vielfältig eingesetzt und auch wiederverwertet
werden. Diese Dienste zeichnen sich vor allem durch ihre Unabhängigkeit von
Plattform und Programmiersprache aus. Sie können einfach an vorhandene
Austauschprotokolle des Internets angeschlossen werden. Damit versprechen sie,
geradezu ideale Standards für einen maschinenbasierten Datenaustausch zu sein.
Vieles deutet auf die künftig große Bedeutung von Web Services hin [RW02]. So wird
seit geraumer Zeit kaum ein Applikationsserverframework vorgestellt, das nicht in der
neusten Version diesen Standard anbietet. Sun stellt mit Sun ONE Application Server
ein gutes Beispiel dafür dar. Microsoft reagiert mit dem .NET Framework, das
Schnittstellen bietet, die nach Marketingaussagen kompatibel mit Web Services sind.
An diesem Punkt setzt auch die neue SAP-Generation mySAP an, denn zum ersten Mal
bei einer großen Unternehmenssoftware sind darin umfassende Schnittstellen zum
Datenaustausch mit Web Services integriert.
1.2 Zielsetzung
Diese Arbeit beschäftigt sich mit der Technologie Web Services. Ein dynamisches
System soll analysiert, spezifiziert und implementiert werden. Anhand eines Prototyps
mit praktischer Einsetzbarkeit sollen die Leistungsdaten gemessen und damit die
Einleitung
4
Tauglichkeit für den Einsatz erörtert werden. Dabei soll auch die Frage geklärt werden,
ob eine lose Kopplung, wie sie durch eine solche Lösung repräsentiert wird, die
Anforderungen einer Geschäftsanwendung erfüllen kann. Wichtig dabei ist
nachzuweisen, wie leistungsfähig die Kommunikation mittels Web Services ist.
Aufgabe der zu entwickelnden Anwendung ist es, einen Anschluss an vorhandene SAP
R/3 Systeme zur Rechnungsstellung auf elektronischem Wege zu schaffen.
Rechnungsempfänger sind Privatkunden eines Energieversorgers, die innerhalb eines
Internetportals Rechnungen einsehen können. Die wichtigste Motivation für den Einsatz
einer solchen Lösung ist die Kostenersparnis gegenüber dem Versand von
Papierrechnungen. In verschiedenen Studien ist von möglichen Einsparungen von bis zu
70% die Rede[SI02]. Auch ergeben sich so neue Möglichkeiten für den Kundenverkehr,
welche die Kundenbindung verbessern helfen könnten.
Die im Rahmen der Arbeit zu programmierenden Web Services werden einerseits mit
einem SAP-System und einem Archivsystem für Dokumente, in welchem Rechnungen
als Bilddaten gespeichert sind, interagieren können. Andererseits bieten diese eine
Schnittstelle zum Benutzer. Sie können dabei auch von maschinellen Benutzern, also
zum Austausch zwischen Computersystemen, genutzt werden. Web Services treten dem
SAP- und dem Archivsystem gegenüber als Client auf, welcher Rechnungsdaten abfragt
und gegebenenfalls den Kunden über den Rechnungseingang informiert.
Die Rechnung wird aus Gründen des Datenschutzes in einem geschlossenen
Kundenbereich präsentiert. Das Angebot wird in einem Portal zusammengefasst,
welches für teilnehmende Benutzer über das Internet verfügbar ist. Darin werden
verschiedene Funktionen wie Übersicht, Einzelansicht und Herunterladen von
Rechnungen mit dem Browser angeboten. Außerdem erhält der Nutzer die Möglichkeit
seine Daten (z.B. Anschrift und Bankverbindung) online zu pflegen.
Abbildung 1.1: Kontextdiagramm zur Interaktion
Benutzt Portal
Sendet Anfrage
Benutzer
Web Services
SAP
Rechnungen /
Rechnungsbilddaten
Antwort
Archiv
Einleitung
5
1.3 Struktur der Arbeit
Zunächst findet innerhalb der Anforderungsanalyse eine Erörterung des Umfelds und
der Erfordernisse für die Anwendung statt. Darin werden allgemeine und vor allem
technische Aspekte der zu erarbeitenden Lösung festgehalten.
Aufbauend auf die Grundlagen dieser Analyse werden im Rahmen eines Entwurfs
Festlegungen getroffen, die für die Entwicklung und den Betrieb wesentlich sind. Dieser
Entwurfsprozess wird vorrangig mit Techniken der Unified Modeling Language (UML)
erarbeitet und so anschaulich gestaltet.
Die Entwicklung des Prototyps erfolgt nach diesen Vorgaben. Neben der
Implementierung werden auch die Installation, der Betrieb und die Benutzung in der
vorliegenden Arbeit thematisiert.
Der Prototyp wird in einer möglichst realistischen Arbeitsumgebung getestet und auf
die Erfüllung der Anforderungen hin überprüft. Die Ergebnisse der Leistungstests
werden vorgestellt und diskutiert. Es folgen eine Analyse der Schwachstellen und der
Versuch, eine Rückkopplung auf Implementierung bzw. auf die Installation zu schaffen.
Mit diesen Tests soll der Nachweis für die Leistungsfähigkeit der Technik Web
Services erbracht werden.
1.4 Grundlagen
Grundlagen der zu erarbeitenden Anwendung sind eine Einführung in Web Services
und deren Anwendung, die Darstellung der Vorteile sowie eine Einordnung in den
Kontext einer Unternehmensanwendung.
1.4.1 Definition
Bei den Bemühungen, einheitliche Definitionen für Web Services zu finden, hat
inzwischen das World Wide Web Consortium (W3C) die Verantwortung für die
Verabschiedung von Spezifikationen dieser Dienste übernommen [MH03]. Eine
Definition, die sich an den Vorschlägen dieses Gremiums orientiert, lautet:
,,Ein Web Service lässt sich als Komponente auffassen, die ihre Funktionalität über eine
veröffentlichte Schnittstelle anbietet und über ein offenes, im Internet verwendetes
Protokoll zugreifbar ist." [MJ02]
Danach sind Web Services Softwarekomponenten, welche über eine definierte
Schnittstellen verfügen. Über diese Anschlüsse werden Nachrichten im Extensible
Markup Language (XML)-Format ausgetauscht.
Einleitung
6
1.4.2 Struktur von Web Services
Als Standards für die Dienste sind folgende Bestandteile zu nennen, die alle im XML-
Format definiert sind: [CA03]
1.
Simple Object Access Protocol (SOAP) ist das Protokoll für den eigentlichen
Nachrichtenaustausch.
2.
Universal Description, Discovery and Integration (UDDI) dient als
Beschreibungssprache für das Verzeichnis der Web Services in der Registry.
3.
Web Services Description Language (WSDL) ist eine Sprache, die der
Beschreibung der Schnittstellen von Web Services dient. Konventionen und
Formate für den Datenaustausch werden damit definiert.
Der Web Service veröffentlicht die Beschreibung des durch ihn angebotenen Dienstes
in der so genannten Registry, einer Registrierungsinstanz. Das geschieht mit der
Beschreibungssprache UDDI. Ein (nichtmenschlicher) Benutzer sucht zunächst in der
Registry nach dem gewünschten Web Service. Dieser liefert die erforderlichen
Informationen über den Dienst. Die Definition der Schnittstelle erfolgt dann unmittelbar
durch den Web Service mit WSDL. Generell ist anzumerken, dass von maschinellen
Benutzern nur Web Services mit identischer Beschreibung und Schnittstelle als
Alternativen akzeptiert werden.
Abbildung 1.2: Struktur von Web Services
Eine solche dynamische Zuordnung wird im Rahmen dieser Arbeit jedoch nicht
verwendet. Die vorliegende Arbeit konzentriert sich auf Dienste zwischen den unteren
beiden Instanzen der Abbildung 1.2.
1.4.3 Anwendung der Web Services
Auf Seiten des Rechnungsstellers wird ein SAP-System verwendet, auf das mittels
mehrerer Schnittstellen zugegriffen wird. Vom SAP-System aus werden die dafür
vorgesehenen Business Application Programming Interfaces (BAPI) verwendet
Benutzer
Web Services
UDDI
WSDL
SOAP
Nachrichten
Registry
UDDI
Einleitung
7
[MG99]. Von Seiten der Web Services wird eine geeignete Technik zur Kopplung an
das SAP-System gesucht.
Die Übertragung der Web Services-Nachrichten erfolgt im Allgemeinen durch ein
Internet-Transportprotokoll, hier durch das Hypertext Transfer Protocol (HTTP).
1.4.4 Vorteile
Für die Verwendung von Web Services nach dem oben aufgeführten Schema spricht die
Plattformunabhängigkeit, auf die bereits in Kapitel 1.1 Kontext eingegangen wurde.
Dieses System wird aus Sicherheitsgründen innerhalb eines Firmennetzes als Teil des
Intranets realisiert. In diesem Zusammenhang steht der Begriff der Enterprise
Application Integration (EAI), der die Integration von Unternehmensanwendungen
beschreibt. Mit Hilfe der geschaffenen Schnittstellen entsteht zunächst ein Portal für
menschliche Benutzer. Diese Schnittstellen sind jedoch ebenso von weiteren
maschinellen Komponenten nutzbar.
Umgekehrt kann das geschaffene Portal auch an anderen als den ursprünglich
angelegten Schnittstellen betrieben werden. Falls statt des SAP R/3 Systems zukünftig
ein mySAP eingesetzt wird, kann das Portal grundsätzlich über das gleiche Interface
auf das System zugreifen. Der Austausch einzelner Komponenten gegen andere mit
gleicher Schnittstellendefinition ist einfach durchzuführen. Damit besteht in zweifacher
Hinsicht die Möglichkeit zur Wiederverwertung.
Für diese Technik spricht außerdem ihre relativ einfache Handhabung. Es besteht die
Möglichkeit, die Details des Datenaustauschs durch die Benutzung von
hochsprachlichen Programmierklassen zu kapseln. Bei der Wahl der
Programmiersprache wird die Portabilität, also der Einsatz auf verschiedenen
Plattformen, berücksichtigt.
Ein weiteres Argument für die Verwendung von Web Services ist die Möglichkeit einer
leichtgewichtige Realisierung. Das heißt, es wird nicht zwingend ein umfangreicher und
teurer Applikationsserver verwendet. Auch ein Framework, das die Plattform oder
technische Einzelheiten festschreibt, ist nicht erforderlich. Dadurch können hohe
Entwicklungs-, Wartungs- und Lizenzkosten vermieden werden.
1.4.5 Einordnung in den Unternehmenskontext
Für die zu erarbeitende Lösung sind einige Gegebenheiten in dem Unternehmen, in
welchem sie eingesetzt werden soll, wichtig. Auf diese wird im Folgenden eingegangen.
Zunächst soll im Rahmen dieser Arbeit ein Anschluss an ein SAP R/3 System realisiert
werden, welches ursprünglich keine Web Service-Schnittstellen beinhaltet. Diese
werden geschaffen, indem vorhandene Schnittstellen erweitert werden. Dieser Schritt
wäre bei einem mySAP-System nicht nötig, da Web Services schon Teil dieses Systems
sind. Wegen des hohen Aufwands für eine Migration wird die Einführung einer neuen
Einleitung
8
Generation unternehmensumspannender Software in naher Zukunft in vielen Firmen
jedoch nicht realisiert werden können.
Daneben bieten einige Unternehmen wie zum Beispiel SAP eigene Module an, um eine
Rechnungsstellung über das Internet zu ermöglichen. Deren Leistungsfähigkeit ist
jedoch bisher nicht erwiesen. Diese Module sind sowohl aufgrund hoher Lizenzkosten
als auch durch den erheblichen Aufwand für die Einrichtung als große Lösung zu
betrachten. Die Entscheidung für ein solches System dürfte daher wenigen Firmen mit
sehr vielen Rechnungsempfängern und häufigem Rechnungsversand vorbehalten sein
wie zum Beispiel Telekommunikationsunternehmen. Für viele andere Unternehmen ist
eine Evaluationsphase mit möglichst geringem Aufwand wichtig, die folgende Fragen
klärt:
·
Wie viele unserer Kunden nehmen die elektronische Rechnungsstellung an?
·
Welchen Aufwand haben wir dabei?
·
Wie hoch ist die Ersparnis?
·
Welche Probleme entstehen dabei?
·
Sind technisch denkbare Lösungen auch in der Praxis einsatzfähig?
Diese Fragen sind im deutschen Raum bisher wenig untersucht. Vorliegende Arbeiten
sind meist nur unspezifisch oder für einzelne Wirtschaftszweige angelegt [EB03@].
Vor diesem Hintergrund und angesichts der genannten Fragestellungen könnte diese
Arbeit dazu dienen, die Einführung von Web Services zu fördern.
Anforderungen
9
2 Anforderungen
2.1 Wahl der Analyseform
In diesem Kapitel werden die Anforderungen der zu erarbeitenden prototypischen
Anwendung analysiert. Dabei wird als Verfahren das Volere Schema zum
standardisierten Erfassen der Anforderungen angewandt.
Das von Suzanne Robertson und James Robertson vorgestellte Schema [SR99] dient der
genormten Erfassung der Anforderungen mithilfe von Kategorien. Diese insgesamt 26
Aspekte werden im Kontext des Volere Schemas Schubladen genannt.
Das Volere Schema ist ein besonderes Instrument der Analyse. Es kann helfen, Fragen
zu Randbedingungen zu klären, die sonst nicht betrachtet oder eher zufällig
angesprochen würden. Auch würden diese so meist nur unstrukturiert dokumentiert
werden. Der Sinn des Schemas ist demnach eine möglichst umfassende Dokumentation
der Anforderungen. Hierzu gehört auch die Einordnung der Situationen der beteiligten
Personen sowie der Unternehmen und der Einrichtungen. Wesentlicher Bestandteil der
Arbeit ist nicht nur das Planen, Implementieren und Testen der Software, sondern auch
der Umgang mit den beteiligten Personen, die für die Durchführung der Arbeit
entscheidend sind.
2.1.1 Definitionen
Im Folgenden sind die wesentlichen Begriffe des Schemas im Sinne der Autoren
definiert
1
:
Anforderung
Ein bewertbarer Wunsch oder eine Forderung an etwas, was das
System können soll. Eine Eigenschaft, die das System haben soll
oder eine Randbedingung, die es erfüllen soll.
Benutzer
(oder Nutzer)
Eine Person, deren Arbeit in unmittelbarerem Zusammenhang mit
dem neuen System steht oder die durch dieses (auch indirekt)
beeinflusst wird.
Beteiligter
Eine Person, die ein Interesse an der erfolgreichen Entwicklung des
Systems oder des Produkts hat.
Entwurf
Das theoretische Gestalten einer Lösung, welche die gesammelten
Anforderungen erfüllt.
Funktionale
Anforderung
Eine Aktion, die das System oder Produkt ausführen können soll.
Kunde
Die Person oder Organisation, für die das System oder Produkt
erstellt wird. In der Regel finanziert diese Person die Entwicklung.
1
modifiziert
Anforderungen
10
Nicht-
funktionale
Anforderung
Eine Eigenschaft, die das System oder Produkt haben soll. Diese soll
nachprüfbar beziehungsweise messbar sein.
System/
Produkt
Das relevante Entwicklungsziel, dessen Anforderungen untersucht
werden. Auch Prototyp genannt.
Abbildung 2.1 Definitionen
2.2.2 Struktur des Schemas
Die Analyse nach dem Volere Schema lässt sich in vier große Bereiche unterteilen:
1. Bedingungen für das System
2. Funktionale Anforderungen
3. Nicht-funktionale Anforderungen
4. Randbedingungen für das Projekt
Zu Beginn der näheren Erläuterung dieser Bereiche wird jeweils eine Übersicht über die
enthaltenen Schubladen und den damit zu erfüllenden Aufgabenbereichen gegeben.
Die Nummerierung der Schubladen erfolgt durchgehend, wird also im nächsten Bereich
wieder aufgegriffen.
2.2 Bedingungen für das System
Dieser Bereich enthält folgende Schubladen:
1. Namenskonventionen und Definitionen
2. Annahmen
3. Zweck des Systems
4. Nutzer des Produkts
5. Kunden und andere Beteiligte
6. Relevante Fakten
7. Randbedingungen
Im Folgenden werden allgemeine Bedingungen festgehalten, die für das zu
entwickelnde Produkt gelten. Mit Namenskonventionen und Randbedingungen werden
Vereinbarungen innerhalb des Projekts getroffen. Umgekehrt werden mit dem Punkt
Annahmen Voraussetzungen genannt, die beschränkenden Einfluss auf das Produkt
haben.
2.2.1 Namenskonventionen und Definitionen
Im Rahmen dieser Arbeit verwendete Fachbegriffe, Abkürzungen und Synonyme sollen
im Folgenden definiert werden.
Anforderungen
11
Ausbaustufe Eine Bezeichnung für das System, das tatsächlich zum Einsatz
kommen soll. Auch Produktiv- oder Echtsystem genannt.
ABAP
Advanced Business Application Language: SAP eigene imperative
Programmiersprache. Mit Hilfe dieser Sprache werden BAPI-
Schittstellen programmiert.
Archivsystem Ein System zum elektronischen Vorhalten von Dokumenten, die
juristisch als Originale gelten. Technisch liegt ein opto-magnetisches
System mit mehreren Medien, die mechanisch schnell gewechselt
werden, zugrunde. Der Zugriff auf die Daten erfolgt nach dem Write
Once Read Many (WORM) Prinzip. Die Zugriffszeit auf ein
Dokument liegt unter einer Sekunde.
BAPI
Business Application Programming Interface: SAP eigene
Schnittstellen zum Datenaustausch. Die Programmierung auf SAP
Seite erfolgt in der Programmiersprache ABAP.
Consolidator Eine Instanz im elektronischen Rechnungsverkehr, die Rechnungen
von verschiedenen Rechnungsstellern bündelt und damit eine
einheitliche Schnittstelle für den Kunden bietet.
DMZ
Demilitarisierte Zone: Der innere Teil einer Serverinfrastruktur, durch
eine Firewall oder weitere Sicherheitsmechanismen geschützt in dem
keine besonderen Schutzmaßnahmen angewendet werden.
EBPP
Electronic Bill Presentment and Payment: Die Rechnungsstellung und
Zahlung auf elektronischem Wege.
Heavy Tail
Distribution
Ein Effekt der statistischen Verteilung von Dokumentgrößen im
Zusammenhang mit der Häufigkeit ihres Vorkommens:
Kleine Dokumente kommen oft vor. Je größer das Dokument ist, desto
seltener kommt es vor. Allerdings haben selten vorkommende aber
sehr große Dokumente einen möglicherweise großen Einfluss auf die
durchschnittliche Größe und damit auf den Datenverkehr beim
Austausch von Dokumenten. Dieser Effekt wird bildhaft als Heavy
Tail Distribution bezeichnet. [DM02]
Portal
Ein System, das nach außen als Webserver funktioniert und die
diskutierten Funktionen für den Nutzer anbietet. Es werden
Informationen wie Rechnungskopfdaten und Kundendaten mit dem
SAP-System mittels Web Services abgeglichen.
Plattform
Bezeichnet die Art oder den Hersteller der Software auf Systemebene.
Beispiele dafür sind verschiedene Betriebssysteme.
Rechnung
"Rechnung ist jede Urkunde, mit der ein Unternehmer oder in seinem
Auftrag ein Dritter über eine Lieferung oder sonstige Leistung
gegenüber dem Leistungsempfänger abrechnet [...]" [UG03]
Anforderungen
12
RFC
Remote Function Call: Ein Aufruf einer Funktion auf einem anderen
Rechner über das Netzwerk. Damit ist eine so genannte enge
Kopplung der beteiligten Systeme verbunden.
SAP-System SAP R/3 System Version 4.6b: unternehmensumspannende
Anwendungssoftware. Es wird vor allem das Modul Financials (FI)
betrachtet. Kunden- und Rechnungskopfdaten liegen darin vor. Dieses
System verfügt nicht über eine Web Services- oder XML-
Schnittstelle. Datenschnittstellen sind im Wesentlichen BAPIs, die für
die Zwecke dieser Arbeit programmiert oder angepasst werden
können. Der Zugriff erfolgt über RMI.
SOAP
Simple Object Access Protocol: Ein XML-konformer Standard zum
Austausch von Informationen mittels Web Services.
SSL
Secure Socket Layer: Ein Übertragungsprotokoll, welches das
Abhören einer Internetverbindung mithilfe von Verschlüsselung
nahezu
2
unmöglich macht. Es wird zur Übertragung persönlicher
Daten und zur Abwicklung von Geschäftsprozessen verwendet.
Stress Tool
Microsoft Web Application Stress Tool: Ein Softwarepaket, das der
Modellierung und Generierung von Last dient.
TIFF
Tagged Image File Format: Ein Format, in dem Bilder in genormter
Form abgelegt werden. Mehrere Blätter eines Schriftstücks können in
einem Dokument gespeichert werden. Es ist weiterhin der Austausch
der so erfassten Dokumente zwischen unterschiedlichen
Rechnersystemen möglich.
TTLB
Time To Last Byte: Damit wird die Zeit angegeben, die vergeht, bis
ein Dokument komplett empfangen wurde.
UML
Unified Modeling Language: Beschreibungssprache für den
Softwareentwurf. Typische Varianten sind das Strukturmodell, das
dynamische Modell oder das Architekturmodell.
URL
Uniform Ressource Locator: Eindeutige Referenz auf ein Dokument
im Internet. Auch Links (oder Hyperlinks) verwenden dieses Format.
VPN
Virtual Private Network: Eine Erweiterung des Internetprotokolls
zwischen mehreren Teilnetzen. Durch das ,Tunneln' der
Kommunikation ist auch der Weg durch ein öffentliches Medium wie
das Internet geschützt, das heißt abhörsicher. [ML01]
Web Service Die verwendete Technik der XML-basierten Datenkommunikation,
welche Daten im SOAP-Format über ein vorhandenes
Transportprotokoll übermittelt. Damit ist eine so genannte lose
Kopplung realisiert [WS03@]
2
Die Unsicherheit bezieht sich auf die ungelöste Frage der Informatik, ob P NP ist.
Anforderungen
13
Web Service-
System
Neben der verwendeten Technik der XML-basierten
Datenkommunikation ist hiermit auch die Instanz der Architektur
gemeint, die die nativen Schnittstellen zu den verwendeten Systemen
(SAP- und Archivsystem) als Web Service anbietet.
XML
Extensible Markup Language: Eine von Menschen lesbare Sprache zur
Übermittlung von formellen und inhaltlichen Daten. Sie ist
ausdrücklich nicht an eine Plattform, ein Austauschformat oder eine
Programmiersprache gebunden.
Abbildung 2.2 Namenskonventionen und Definitionen
2.2.2 Annahmen
Im Folgenden werden Annahmen dargestellt, welche die Analyse und den Entwurf des
Systems beeinflussen. Dazu zählen sowohl selbst getroffene Festlegungen als auch
Voraussetzungen, die als gegeben anzusehen sind.
2.2.2.1 Voraussetzungen
Hard- und Software für die Entwicklung wird von der Firma Logiball zur Verfügung
gestellt. Installation und Leistungstests finden bei rku|it statt. Verwendete
Betriebssysteme sind hierbei durchgehend Windows NT einschließlich Windows 2000.
Die Rechner, auf denen die Instanzen für Web Services und das Portal installiert
werden, sind normale Arbeitsplatzcomputer. Leistungsfähigere Server Klasse Computer
stehen für die vorliegende Arbeit nicht zur Verfügung. Eine Skalierung auf
Hardwareebene in Form einer Zuschaltung weiterer Rechner bei hohen
Leistungsanforderungen ist nicht vorgesehen.
Das SAP- sowie das Archivsystem sind bei rku|it als Hochverfügbarkeitssystem
ausgelegt. Ein Zugang zum SAP-System ist wie oben beschrieben im Rahmen dieser
Arbeit zu Testzwecken möglich. Es wird außerdem ein Web Service, der an das
Archivsystem angeschlossen werden kann, für die Übertragung von
Rechnungsbilddaten in dem gleichen Format entstehen.
Das Archivsystem dient der Verwaltung von Rechnungsdaten im TIFF-Format. Dieses
Format wurde gewählt, da so Dokumentenechtheit und Fälschungssicherheit
gewährleistet werden kann. Die Echtheit resultiert aus der Fähigkeit des Formats,
mehrere Seiten die nicht ohne weiteres ausgetauscht werden können in einem
Dokument vorzuhalten. Aus juristischer Sicht spricht man von ,,Objekten des
Augenscheins von hoher Qualität im Sinne der Grundsätze des Bundesfinanzministers
vom 07.11.1995 zur ordnungsgemäßen Aufbewahrung von Dokumenten"
3
.
2.2.2.2 Durchführung der Arbeit
Die Planung im Vorfeld der Diplomarbeit erfolgt unter Einbeziehung verschiedener
Ansprechpartner an der Universität Dortmund, bei rku|it und in Abstimmung mit
3
modifiziert nach: § 147 Abgabenordnung (AO Steuerrecht), § 253 Handelsgesetzbuch (HGB)
Anforderungen
14
Logiball. Die für die Analyse wichtige Einführung in den Kontext der
Unternehmensanwendung SAP R/3, bezogen auf die Erfordernisse der
Rechnungsstellung bei Energie- und Wasserversorgern, findet in engem Austausch mit
einem Mitarbeiter von rku|it statt.
Für die Entwicklung und den Test der Schnittstellen ist entweder ein persönlicher
Zugang zum SAP-System oder ein Virtual Private Network (VPN) mit Zugriff auf das
SAP-System erforderlich. Die Entwicklungsumgebung mit der Möglichkeit über eine
VPN Schnittstelle das SAP-System anzusprechen, wird von der Firma Logiball
bereitgestellt.
Zur Installation der Anwendung und Durchführung der Leistungstests ist eine
Abstimmung mit den Mitarbeitern von rku|it erforderlich. Vor allem bei den Tests ist
eine erhebliche Belastung für das Firmennetz möglich. Um den normalen
Betriebsablauf nicht zu stören, kann diese Belastung nur in Absprache mit den
Verantwortlichen an bestimmten Terminen erfolgen, zu denen das Netzwerk und das
SAP-System von rku|it selbst nicht beansprucht wird.
2.2.3 Zweck des Systems
Aufgabe des Systems ist es, einer bestimmten Nutzergruppe Einsicht in ihre
Rechnungen zu geben. Der Zugriff erfolgt mit einem Web Browser über das Internet.
Bei der Motivation für die Nutzung eines solchen Systems können verschiedene
Faktoren eine Rolle spielen. Stichpunktartig seien genannt:
·
Zugriff jederzeit und von jedem Ort aus möglich
·
Papierlose Verwaltung, papierloses Büro
·
Mögliche Einsparungen beim Anbieter
·
Möglicher Preisnachlass für den Nutzer
Für die an der Entstehung des Systems Beteiligten gibt es verschiedene Motivationen:
·
Der Energieversorger (bzw. das Dienstleistungsunternehmen, das die
Entwicklung für diesen übernimmt) erhält auf diese Weise einen Prototyp für die
Erweiterung des SAP-Systems, welches eine Alternative zu umfangreichen und
teuer zu lizenzierenden Standardlösungen bietet. Der Prototyp, der im Rahmen
der Diplomarbeit entsteht, könnte zu einem Echtsystem erweitert werden,
welches für den Realbetrieb geeignet wäre. Weiterhin wird die
Leistungsfähigkeit dieses Prototyps im Rahmen der Diplomarbeit getestet. So
erhält der Energieversorger Kennzahlen für die Anzahl der Kunden, die auf das
System zugreifen können und damit für die Einsatzfähigkeit dieser Lösung.
·
Für das Unternehmen, das Rechnungen stellt, besteht durch das entwickelte
System die Möglichkeit, neue Marketingmaßnahmen im Zusammenhang mit
dem Internet zu gestalten. So kann der Weg zum Rechnungsportal über die
Startseite des Unternehmens führen. Dort besteht die Möglichkeit,
Informationen und Marketingaktionen an den Nutzer zu richten.
·
Ein weiterer Effekt ist, dass das Unternehmen einen qualitativ guten
Datenstamm von Kunden, die dieses Portal nutzen, erhält. Diese Güte resultiert
aus der Tatsache, dass die Nutzer ein eigenes Interesse an der Pflege dieser
Daten haben und den Erfolg der Pflege unmittelbar nachvollziehen können.
Anforderungen
15
·
Die Firma Logiball GmbH ist im Rahmen eines Hiwi-Arbeitsverhältnisses
zurzeit Arbeitgeberin des Diplomanden. Die Motivation für die Bereitstellung
von Ressourcen für die Entwicklung ist gegeben, da im Rahmen der Arbeit
sowohl wichtige Erfahrungen für den Einsatz von Web Services als auch für den
Umgang mit einem SAP-System gemacht werden. Diese können in das
Unternehmen eingebracht werden.
·
Der Diplomand erarbeitet eine Anwendung, die nicht nur im Rahmen der
Diplomarbeit, sondern auch darüber hinaus Verwendung finden kann. Er erhält
außerdem Einsicht in mehrere Firmen und lernt nebenbei zu organisieren und
die eigenen Interessen in unterschiedlichen Teams vorzutragen und zu vertreten.
2.2.4 Kunden und andere Beteiligte
Für dieses Projekt ist die Zusammenarbeit von verschiedenen Gruppen von Bedeutung.
Die Energie und Wasserversorgung Mittleres Ruhrgebiet GmbH (EWMR) ist ein
großes Unternehmen mit Geschäfts- und Privatkunden. Sie gehört zu der Zielgruppe der
Firmen, die eine solche Softwarelösung einsetzen könnten. Die rku|it GmbH ist ein
Informatik-Dienstleister, der für EWMR den Betrieb und die Entwicklung
unterschiedlicher Software und Dienstleistungen in diesem Umfeld anbietet. Unter
anderem werden die Produktion und der Versand von Rechnungen in Papierform für
EWMR durch diese Firma übernommen. Sie stellt für die vorliegende Arbeit die
Infrastruktur zum Testbetrieb und für die Leistungstests zur Verfügung.
Ansprechpartner für die Einrichtung und den Zugang zur Infrastruktur des
Unternehmens ist ein Mitarbeiter von rku|it. Er übernimmt außerdem die Anpassung
und die Programmierung des SAP-Systems, welche für diese Arbeit erforderlich ist.
2.2.5 Nutzer des Systems
Kunden eines Energieversorgungsunternehmens stellen die potentialen Benutzer dar,
welche an dem elektronischen Verfahren der Rechnungszustellung teilnehmen. Die
Nutzer sollen der Rechnungszustellung auf diesem Wege explizit zustimmen.
Zugangsdaten werden ihnen auf sicherem Weg zugesendet, zum Beispiel per Brief. Der
Abruf der Rechnungen findet dann möglichst unkompliziert über das Internet statt.
2.2.6 Randbedingungen
Zu nennen sind zunächst infrastrukturelle Vorgaben. Diese hängen von den
Möglichkeiten der beteiligten Unternehmen ab und schaffen so die
Rahmenbedingungen für die Entwicklung, die Installation und die Leistungstests. Diese
werden in Kapitel 2.2.2.1 Voraussetzungen diskutiert.
Weiter ist durch die Verwendung Web Services mit einer Hochsprache wie Java oder
perl das System weitestgehend portabel. Es wird aufgrund der infrastrukturellen
Vorgaben auf Windows NT entwickelt und betrieben.
Der zeitliche Rahmen für die Erstellung ist durch die Dauer der Diplomarbeit vom
1.4.2003 bis zum 1.10.2003 festgelegt. Für die Planung und Implementierung des
Anforderungen
16
Prototyps ist das erste Drittel der Zeit vorgesehen. Im zweiten Drittel sollen
Leistungstests und die Verbesserung der Implementierung stattfinden. Das letzte Drittel
dient der Verschriftlichung und als zeitlicher Puffer. Ein genauer Zeitplan ist in Kapitel
2.5.4 Aufgabenplanung dargestellt.
Es besteht zurzeit nicht die Möglichkeit, über die bei EWMR vorhandene Software,
Rechnungen online zuzustellen. Auch sind für Web Services direkt nutzbare
Schnittstellen weder im SAP- noch im Archivsystem vorhanden. Erst durch den
Zusammenschluss dieser beiden Systeme, sowie durch Schaffen der genannten
Schnittstellen entsteht ein sinnvoller Komplex von Kundendaten, Rechnungsdaten und
den Rechnungen selbst.
2.2.7 Relevante Fakten
Die Software, die im Rahmen der vorliegenden Arbeit erstellt wird, steht in Konkurrenz
zu Erweiterungen vorhandener Geschäftssoftware sowie neuerer SAP-Systeme. Darauf
wird in Kapitel 2.5.2 Fertiglösungen näher eingegangen. Die Einführung dieser
etablierten Anwendungen kann sowohl umfassende Änderungen als auch hohe
Lizenzkosten nach sich ziehen. Sie sind aus diesen Gründen vermutlich für einige
Unternehmen zum Zweck der Einführung der elektronischen Rechnungsstellung nicht
wirtschaftlich. Ein wie im Rahmen der vorliegenden Arbeit entstehendes System stellt
eine mögliche Alternative für solche Unternehmen dar. Sie können damit diese
Rechnungsform für ihre Kunden einführen und dabei die Akzeptanz testen.
Vorzugsweise wird für die Entwicklung, vor allem aber für Module, die Teil der zu
erarbeitenden Lösung sein werden, freie Software eingesetzt. So werden Lizenzkosten
vermieden, welche die Verwendung der Software verteuern würden.
2.3 Funktionale Anforderungen
Der zweite Bereich enthält folgende Schubladen:
8. Abgrenzung des Systems
9. Anforderungen an Funktionen und Daten des Systems
Im Folgenden werden funktionale Anforderungen festgehalten, die für das Projekt
gelten. Unter Abgrenzungen werden Grenzen des Systems benannt, also Eigenschaften
und Funktionen, die nicht zum Umfang des Prototyps zählen. Unter Anforderungen
werden Aussagen zu den Abläufen und zur Art der Beanspruchung gemacht, die alle
Teile des Systems betreffen.
2.3.1 Abgrenzung des Systems
Im Rahmen der vorliegenden Arbeit wird aus dem Kontext des Electronic Bill
Presentment and Payment (EBPP) lediglich das Bill Presentment realisiert. Zur
Bezahlung wird bei der avisierten Benutzergruppe entweder die Teilnahme am
Lastschriftverfahren oder ein entsprechender Dauerauftrag vorausgesetzt. Lösungen zur
Bezahlung auf elektronischem Weg mittels Web Services existieren [AF03] und können
Anforderungen
17
zu einem gemeinsamen System weiterentwickelt werden. Sie sind jedoch nicht
Bestandteil dieser Arbeit. Auch der Anschluss an eine Instanz, die zur Verbesserung der
Übersichtlichkeit Rechnungen verschiedener Anbieter zentral verwaltet (ein
Consolidator), wird nicht angestrebt.
Der Versand einer E-Mail an den Benutzer zur Benachrichtigung beim Eintreffen einer
neuen Rechnung wird als vorhanden unterstellt, im Rahmen der vorliegenden Arbeit
aber nicht realisiert.
Auf die Interaktionen zwischen Benutzer, Web Service und SAP- bzw. Archivsystem
wurde bereits in Kapitel 1.1 Kontext näher eingegangen.
Der Zugang zum Archivsystem ist im Rahmen dieser Arbeit nicht möglich. Daher
werden die Rechnungskopfdaten mittels Web Service aus einem Archivsystem-Dummy
übertragen, der die Eigenschaften des Systems geeignet simuliert. Für die
Spezifizierung dieser Schnittstelle ist eine Analyse der entsprechenden ,echten'
Schnittstelle erforderlich. Die Rechnungsbilddaten liegen im Archivsystem als TIFF-
Datei vor. Es erfolgt keine Umwandlung in ein anderes, üblicheres Bildformat.
Der Prototyp greift auf verschiedene Instanzen und Komponenten zu, auf die aus
Gründen der Firmenpolitik kein Einfluss genommen werden kann. So ist die
Performance des SAP-Systems durch ihre Programmierung und die eingesetzte
Hardware sowie die Last im Moment der Betrachtung bestimmt. Auch für alle anderen
Komponenten ist die Realisierung durch die von rku|it zur Verfügung gestellte
Systemsoftware und Hardware festgelegt. Die in Kapitel 2.4.3 Performance, Durchsatz
und Sicherheit gemachten Angaben zur Anzahl der Benutzer unterstellen, dass alle
Kunden des Stadtwerks an diesem Verfahren der Rechnungszustellung teilnehmen.
Wenn mit der vorgegebenen Infrastruktur diese Benutzerzahl nicht erreicht werden
kann, sollen das Element bzw. die Elemente identifiziert werden, welche die Leistung
beschränken. Außerdem ist eine Hochrechnung mit den ermittelten Leistungswerten auf
die Zahl der tatsächlich möglichen Nutzer durchzuführen.
Für den Schutz nach außen, also die Abhörsicherheit, wird im Rahmen der vorliegenden
Arbeit ein Konzept entwickelt. Wenn es sich dabei um eine Standardkomponente wie
SSL handelt, die keinen Einfluss auf die Struktur des Prototyps hat, wird sie als
vorhanden unterstellt und weggelassen.
Themen wie das Optimieren der Leistung einer Datenbank oder Anpassungen des
Webservers unter Leistungsaspekten werden in der vorliegenden Arbeit versuchsweise
durchgeführt und beschrieben.
2.3.2 Anforderungen an die Funktionen und Daten des Systems
In dieser Schublade werden zwei Arten von Anforderungen formuliert. Um die
Rahmenbedingungen für die Art und den Umfang des Systems darzustellen, wird die zu
erstellende Software innerhalb ihres Kontextes konkret beschrieben. Für die Daten des
Systems existieren vor allem strukturelle Bedingungen, die im Folgenden genannt
werden.
Anforderungen
18
2.3.2.1 Strukturelle Anforderungen
Der Austausch der Daten zwischen den Instanzen der Web Services erfolgt im XML-
Format und zwischen Web Service- und SAP-System mittels Remote Function Call
(RFC). Die XML basierte Kommunikation muss der Spezifikation des Simple Object
Access Protocol (SOAP) entsprechen, die RFCs werden eigens für die zu
transportierenden Daten spezifiziert.
Anforderungen, für die Zahlen vorliegen, betreffen im Wesentlichen die erwartete
Nutzerzahl und den erwarteten Durchsatz. Diese werden in Kapitel 2.4.3 Performance,
Durchsatz und Sicherheit näher erläutert.
2.3.2.2 Anforderungen an die Funktionen
Der Kunde eines Energieversorgers hat sich für die Rechnungszustellung online
entschieden und auf sicherem Wege die Zugangsdaten erhalten. Hierzu zählen der
Benutzername und das Passwort. Der Benutzer erhält zusätzlich die Information, wie er
zum Portal gelangt. Dies erfolgt insbesondere durch die Angabe der URL
4
der Startseite.
Mithilfe eines Web Browsers gelangt er auf das Portal. Die Verbindung zwischen Portal
und Nutzer ist mit Secure Socket Layer (SSL) für die gesamte Dauer des Aufenthalts
geschützt. Der Zugriff erfordert die Zugangsdaten. Das heißt der Nutzer muss zunächst
Benutzername und Passwort richtig eingeben. Ist die Kombination falsch, erscheint eine
entsprechende Meldung. Ist die Kombination richtig, wird die Hauptseite angezeigt.
Auf dieser Seite gibt es folgende Informationen:
·
Kundennummer
·
Kundenname
·
Anschrift des Kunden
·
Anzahl neuer Rechnungen
·
Anzahl schon eingesehener Rechnungen
·
Tabellarische Übersicht über die Rechnungen mit Rechnungsnummer, Datum
und Betrag
Außerdem bietet die Hauptseite folgende Funktionen an:
·
Möglichkeiten, die Rechnungen durch Klicken auf die Tabellenüberschriften
(Rechnungsnummer, Rechnungsbetrag, Rechnungsdatum) zu sortieren
·
Die Möglichkeit zum Herunterladen der Rechnungen durch Klick auf die
jeweilige Tabellenzeile
·
Ein Link ,Abmelden' zum Beenden der Sitzung
·
Ein Link ,Daten ändern' zum Bearbeiten der Kundenstammdaten
Auf der Internetseite zur Datenpflege gibt es folgende Eingabefelder zu den
persönlichen Daten und der Bankverbindung des Kunden:
·
Name
·
Anschrift
·
PLZ / Ort
4
Die URL hat im englischen das männliche Genus, bei der Verwendung in einem deutschen Text ist
jedoch die weibliche Form üblich.
Anforderungen
19
·
BLZ
·
Kontonummer
Hier gibt es die Möglichkeit, mit ,Daten übernehmen' die Angaben zu speichern oder
mit ,zurück' zur Ausgangsseite zu gelangen.
Weiterhin soll die Sitzung automatisch nach fünf Minuten ohne neuen Seitenaufruf
beenden werden.
2.4 Nicht-funktionale Anforderungen
Im dritten Bereich sind folgende Schubladen enthalten:
10. Oberflächenanforderungen
11. Benutzbarkeitsanforderungen
12. Performance, Durchsatz und Sicherheit
13. Operationelle Anforderungen
14. Wartungs- und Portierungsanforderungen
15. Zugriffsschutzanforderungen
16. Politische Anforderungen
17. Gesetzliche Anforderungen
Im Folgenden werden Anforderungen festgehalten, die sich auf Verhaltenseigenschaften
des Gesamtsystems beziehen. Diese sollen von den Funktionen und Daten gewährleistet
werden. Die Eigenschaften berühren die Themen Bedienung, Leistung, Sicherheit und
das Umfeld des Systems.
2.4.1 Oberflächenanforderungen
Die Oberfläche sollte in Ihrer Gestaltung möglichst klar strukturiert sein, um eine
einfache Bedienung für den Benutzer zu gewährleisten. Das Angebot soll abgesehen
von der Anmeldung nur die Hauptseite und die Seite zur Pflege der Kundendaten
umfassen. Grafiken und Bilder sollen möglichst nicht verwendet werden. Die
Gestaltung sollte im Rahmen des Prototyps nur die oben genannten Grundfunktionen
enthalten, die mit geringem Aufwand an andere Gestaltungsvorgaben angepasst werden
können.
2.4.2 Benutzbarkeitsanforderungen
Für die Oberflächengestaltung orientieren sich die Anforderungen an dem
voraussichtlichen Profil des Benutzers, der zumindest eine minimale Erfahrung als
Internetnutzer hat. Darüber hinaus werden nur durchschnittliche technische Fähigkeiten
vorausgesetzt.
Ende der Leseprobe aus 108 Seiten
- nach oben
Details
- Arbeit zitieren
- , 2003, Eine Referenzimplementierung von Web Services zur elektronischen Rechnungsstellung, Hamburg, Bedey Media GmbH, https://www.diplom.de/document/222632
Ähnliche Arbeiten
Deutschlands größter Sharing Community
Jetzt Zusammenfassungen, Skripte und Klausuren kostenlos downloaden!
Uniturm.de
Ihre Vorteile als Autor
Geld verdienen Für jedes verkaufte Exemplar erhalten Sie Autorenhonorar - bis zu 40%.Kostenlose Buchveröffentlichung
Als eBook-Studie im Original und / oder auf Wunsch zusätzlich als hochwertiges Fachbuch in unserem renommierten Buchverlag.
Renommee als Fachbuchautor
Präsentieren Sie sich als Fachfrau oder Fachmann in Ihrem Fachgebiet und machen Sie sich bekannt.
Persönliche Betreuung
Unser Lektorat wird Sie persönlich betreuen und ist auch telefonisch unter 040-655992-14 erreichbar.
Weltweit im Buchhandel
Ihr Buch ist weltweit im Buchhandel und Online-Buchhandel wie z.B. amazon erhältlich.
Jetzt Autor werden!
Kommentare