generated from leonetienne/LaTeX-Paper-template
Compare commits
10 Commits
faa1e09655
...
master
| Author | SHA1 | Date | |
|---|---|---|---|
|
5152e4f4a9
|
|||
|
94cc181278
|
|||
|
8d20bd105b
|
|||
|
117722250c
|
|||
|
fab6b215fc
|
|||
|
6652d99925
|
|||
|
758a8ad419
|
|||
|
731c03f447
|
|||
|
c40b18d8cf
|
|||
|
4528ff1318
|
@@ -33,61 +33,60 @@ Die \ac{ELN} könnte schlicht die von TYPO3 vergebene UID sein.
|
||||
Smartphone ist am sinnvollsten, da Feedback von Webseite damit möglich ist.
|
||||
Backup-Funktion, die \ac{ELN} händisch einzugeben. Das ginge dann auch mit einem Handscanner.
|
||||
|
||||
\paragraph*{Welche Fallbacks soll es geben, sollte ein Code nicht scanbar sein? Z.B.: Den Code- Inhalt in Text unter dem Code, der auch von Hand eintippbar sei.}
|
||||
Die \ac{ELN} muss auch unter dem qr code stehen.
|
||||
\paragraph*{Welche Fallbacks soll es geben, sollte ein Code nicht scanbar sein? Z.B.: Den Code-Inhalt in Text unter dem Code, der auch von Hand eintippbar sei.}
|
||||
Die \ac{ELN} muss auch unter dem QR-Code stehen.
|
||||
|
||||
\paragraph*{Gegen welche Missbrauchsszenarien sollte der QR-Code geschützt sein? Sollte ggf. ein Passwort nach dem Einscannen verlangt werden? ->Diskurs über versch. Authentifizierungsmethoden und Abwägung über Aufwand der dadurch entsteht.}
|
||||
Mitarbeiter authentifizieren sich mit einem Frontend-Nutzer. Dieser Nutzer ist Teil einer Mitarbeiter-Nutzergruppe.
|
||||
|
||||
\paragraph*{Gibt es im Lager Wlan?}
|
||||
Out of scope
|
||||
Out of scope.
|
||||
|
||||
\paragraph*{Wie wollen Sie Weinanmeldungen zwischen Jahresauswahlproben im Frontend trennen? Wichtig: Aktuelle Proben nach Anmeldeschluss sollten immer noch sichtbar sein und alte Proben ggf. gar nicht mehr angezeigt werden.}
|
||||
Es gibt eine Liste mit Jahresauswahlproben.
|
||||
Da werden verschiedene aufgelistet.
|
||||
Backenduser können die Anmeldung (Weine an Jahresauswahlproben anmelden) an- und abschalten.
|
||||
Backend-User können die Anmeldung (Weine an Jahresauswahlproben anmelden) an- und abschalten.
|
||||
Vergangene Proben werden nicht angezeigt.
|
||||
Die Probe gilt als vergangen, wenn die Proben probiert wurden.
|
||||
Die Anmeldemöglichkeit und \enquote{Probe ist vorbei}-Feststellung im Anmeldetool ist ein Clone vom „active until“ im „access-„panel. Mit Dateselector.
|
||||
|
||||
\paragraph*{Was soll der Kunde beim Versand selbst machen?}
|
||||
Wenn weinland-mosel-mitglied:
|
||||
Ggf account erstellen mit Mitgliedsnummer <schon implememtiert> <muss händisch von WM freigeschalten werden>
|
||||
In account einloggen
|
||||
Wenn Weinland-Mosel-Mitglied:
|
||||
Ggf Account erstellen mit Mitgliedsnummer <schon implememtiert> <muss händisch von WM freigeschalten werden>.
|
||||
In Account einloggen.
|
||||
|
||||
Wenn Nichtmitglied:
|
||||
Ggf account erstellen ohne Mitgliedsnummer <muss händisch freigeschalten werden>
|
||||
Ggf. Account erstellen ohne Mitgliedsnummer <muss händisch freigeschalten werden>
|
||||
|
||||
Eine Jahresauswahlprobe auswählen
|
||||
Eine Jahresauswahlprobe auswählen.
|
||||
Einen Wein anmelden, Webform zu Weindaten ausfüllen.
|
||||
PDF downloaden, ausdrucken im Paket dem Wein beilegen.
|
||||
Das PDF muss Daten zum Wein beinhalten und den qr-code mit der \ac{ELN}. (zur Zuordnung)
|
||||
Das PDF muss Daten zum Wein beinhalten und den QR-Code mit der \ac{ELN}. (zur Zuordnung)
|
||||
Nummernschwund, falls Weine gelöscht werden, ist kein Problem.
|
||||
|
||||
Adressierung wird selbst gemacht.
|
||||
Frankierung auch.
|
||||
|
||||
\paragraph*{In welcher Form sollten Mitarbeiter die ausstehenden und eingegangenen Weine sehen? Reicht eine einfache Liste, oder sind Export- und Filtermöglichkeiten erwünscht? Wenn ja: Welche Filter (auch Sortierungen)? Welche Exportformate?}
|
||||
- CSV soll ausgebbar sein
|
||||
- Filter nicht notwendig, aber probenspezifisch
|
||||
- CSV soll ausgebbar sein.
|
||||
- Filter nicht notwendig, aber probenspezifisch.
|
||||
|
||||
\paragraph*{Wenn nun ein Wein als “eingegangen” vermerkt ist, sollte ein Mitarbeiter das rückgängig machen können? Sollte ein Mitarbeiter Weine löschen können? Wenn eines der beiden ja: Einzeln, oder als Bulk-Action? (Bulk-Actions sind teuer/aufwändig umzusetzen)}
|
||||
- Was TYPO3 by-default kann, nichts eigenes bauen
|
||||
- Was TYPO3 by-default kann, nichts eigenes bauen.
|
||||
|
||||
\paragraph*{Welche Informationen soll der Kunde über seine Sendunge(n) sehen?}
|
||||
- ob sie eingegangen ist, mit emailbenachrichtigung
|
||||
- Ob sie eingegangen ist, mit Emailbenachrichtigung.
|
||||
|
||||
\paragraph*{Soll auch ein Kunde in der Lage sein, seine eigene Weinsendung(en) aus dem System zu löschen oder zu verändern? (Eventuell vertippt man sich) Wenn ja, bis wann? Bis zur Eingangsbestätigung?}
|
||||
Nach Einreichung (nicht Eingang bei WM) nicht mehr veränderbar und auch nicht löschbar.
|
||||
|
||||
\paragraph*{Die \ac{ELN} ist eine inkrementell erhöhte Ganzzahl. Ist der tatsächliche Wert dieser wichtig, oder ist es lediglich wichtig, dass sie eindeutig ist? Der einfachste/günstigste Weg wäre es, sie in der Datenbank als “auto\_increment” zu deklarieren. Dann hätte man niemals, auch über x Auswahlproben hinweggehend, die selbe \ac{ELN} zwei mal. Das verkürzt und vereinfacht die Entwicklung, den entstehenden Code und die Nutzererfahrung auf Seiten von \ac{WM}.}
|
||||
- siehe oben
|
||||
|
||||
- Siehe oben.
|
||||
|
||||
\paragraph*{Weiteres}
|
||||
Es soll einen Single-View für Weine geben, der anhand einer \ac{ELN} aufrufbar ist. Hier werden bekannte Details gezeigt.
|
||||
|
||||
\paragraph*{Zum Formular, das Winzer ausfüllen:}
|
||||
Das Formular besteht zwei Schritten:
|
||||
Schritt 1: Daten ausfüllen
|
||||
Schritt 2: Zusammenfassung anzeigen entweder zurück, weiter bearbeiten, oder submit \enquote{wein verbindlich anmelden}
|
||||
Schritt 1: Daten ausfüllen.
|
||||
Schritt 2: Zusammenfassung anzeigen entweder zurück, weiter bearbeiten, oder submit \enquote{Wein verbindlich anmelden}.
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
\chapter{Anforderungserfassung}
|
||||
\label{chap:anforderungserfassung}
|
||||
Obwohl bereits ein grober Anriss des Zielsystems bekannt ist, ist es unabdinglich eine Anforderungsanalyse durchzuführen,
|
||||
dies um Details auszuarbeiten \cite{bib:christoph-ebert-vorwort-systematisches-re}.
|
||||
um Details auszuarbeiten \cite{bib:christoph-ebert-systematisches-re}.
|
||||
Hierbei ist es wichtig, kein exzessives Pflichtenheft aufzubauen, denn letztendlich zählt nur, was dem Kunden geliefert wird.
|
||||
Nicht, wie viele gar nicht benötigte Anforderungen umgesetzt wurden.
|
||||
\enquote{\textit{Zu viele oder falsche Anforderungen ruinieren Budgets, Termine und die Qualität.}}
|
||||
\cite{bib:christoph-ebert-vorwort-systematisches-re}.
|
||||
\quotecite{Zu viele oder falsche Anforderungen ruinieren Budgets, Termine und die Qualität.}
|
||||
\cite[S. viii]{bib:christoph-ebert-systematisches-re}.
|
||||
Die Anforderungen eines Produktes sind in drei Kategorien einzuteilen: \acp{FA}, \acp{NFA}
|
||||
und Randbedingungen \cite{bib:heinemann-vorlesung-re}.
|
||||
Wie oben erwähnt, sind bereits die Randbedingungen und einige funktionale und nichtfunktionale Anforderungen bekannt. Diese sind:
|
||||
@@ -58,7 +58,7 @@ keine Suggestivfragen zu stellen
|
||||
Um Fragebögen für Stakeholder formulieren zu können, muss zunächst bekannt sein, wer die Stakeholder sind.
|
||||
\quotecite{Ein Stakeholder eines Systems ist eine Person oder Organisation, welche (direkt oder indirekt)
|
||||
\break{}Einfluss auf die Anforderungen des betrachteten Systems hat.}
|
||||
\break\cite{bib:basiswissen-re}.
|
||||
\break\cite[S. 9]{bib:kleine-re-fibel}.
|
||||
Daraus ergeben sich die Stakeholdergruppen: \enquote{Mitarbeiter \ac{WM}} und \enquote{teilnehmende Weingüter}.
|
||||
Jede dieser Stakeholdergruppen sieht das System aus einer anderen Perspektive
|
||||
\break\cite{bib:kleine-re-fibel}.
|
||||
@@ -85,15 +85,18 @@ die Probenteilnehmer übergeben.
|
||||
Aus dem Interview mit dem \ac{PO} ergibt sich ein Pflichtenheft.
|
||||
Das Pflichtenheft und das Protokoll zum Interview sind im Anhang unter je
|
||||
\fullref{chap:anhang-pflichtenheft} und \fullref{chap:anhang-interview-protokoll} zu finden.
|
||||
Ergebnisse dieses Interviews sind zahlreiche Anforderungen und Ideen. Eine der wichtigsten Ideen stellt das
|
||||
Ergebnisse dieses Interviews sind zahlreiche Anforderungen und Ideen. Eine der wichtigen Erkenntnisse stellt das
|
||||
projektbezogene, wöchentliche Statusmeeting dar: Jeden Donnerstag soll um 9:30 Uhr der aktuelle Stand
|
||||
des Projektes vorgestellt, diskutiert und Rücksprache gehalten werden.
|
||||
Weitere wichtigste Erkenntnisse des Interviews sind:
|
||||
des Projektes dem \ac{PO} vorgestellt und mit ihm diskutiert und Rücksprache gehalten werden. Ziel dessen ist unter anderem
|
||||
die pragmatische Korrektheit laufend zu überprüfen und ggf. Anforderungen zu überarbeiten.
|
||||
Diese Idee wurde unmittelbar nach Beendigung des Interviews vorgeschlagen und entzieht sich somit dem Transkript.
|
||||
\clearpage
|
||||
Weitere wichtige Erkenntnisse dieses Interviews sind:
|
||||
\begin{description}
|
||||
\item[Endgerät für Scanning und Scanneranwendung]\hfill\\
|
||||
Gescannt wird von Mobiltelefonen mit einer QR-Code-App wie QRBot.
|
||||
QRBot ermöglicht es Nutzern für jeden aufgerufenen QR-Code eine Vorlagen-URL aufzurufen,
|
||||
um den gescannten Wert als Teil der URl, z.B. als Get-Parameter, zu übergeben \cite{bib:qrbot}.
|
||||
um den gescannten Wert als Teil der URL zu übergeben \cite{bib:qrbot}.
|
||||
Das ist prädestiniert für API-ähnliche Webseitenaufrufe, um Weine einzuchecken.
|
||||
\item[Trennung von Weinen nach Jahresauswahlproben im Frontend]\hfill\\
|
||||
Da es $n$ Jahresauswahlproben gibt und Weine immer genau einer Jahresauswahlprobe zugeordnet sein müssen, macht es wenig
|
||||
|
||||
@@ -2,8 +2,8 @@
|
||||
\label{chap:einleitung}
|
||||
Der Regionalverband für Weine \ac{WM} lässt Weine in organisierten Weinproben, sog. Jahresauswahlproben, von Juroren bewerten.
|
||||
Teilnehmende Weingüter registrieren ihre Weine in verschiedenen Kategorien und schicken diese auf dem Postweg ein.
|
||||
Dieser Prozess bildet sich in Form ausgedruckter Formulare, die von Hand ausgefüllt und von Hand in eine
|
||||
Excel-Tabelle übertragen werden, ab.
|
||||
Dieser Prozess bildet sich in Form ausgedruckter Formulare ab, die von Hand ausgefüllt und von Hand in eine
|
||||
Excel-Tabelle übertragen werden.
|
||||
|
||||
\section{Problemstellung}
|
||||
\label{chap:einleitung-problemstellung}
|
||||
@@ -11,7 +11,7 @@ Die teilnehmenden Weingüter schicken ihre Weine zusammen mit Formularen über d
|
||||
Es ist der Normalfall, dass ein teilnehmendes Weingut \emph{mehrere} Weine zur Bewertung anbringt.
|
||||
In diesem Fall ist für jeden anzumeldenden Wein ein solches Formular erneut auszufüllen.
|
||||
Hierbei werden sämtliche auf das Weingut bezogene Daten redundant ausgefüllt.
|
||||
Das ist so, da diese Daten zwischen den Weinen gleichbleibend sind.
|
||||
Das ist so, weil diese Daten zwischen den Weinen gleich bleiben.
|
||||
Abgesehen davon, dass solche Redundanzen auf Weinguts- und Verbandsseite die hedonische Qualität schädigen,
|
||||
bietet ein solcher Workflow Freiraum für Fehler und Inkonsistenzen.
|
||||
Dieser Workflow, mit den zuvor genannten Nachteilen, wird auf Verbandsseite, nach Zustellung der Weine, weiter fortgeführt:
|
||||
|
||||
@@ -26,7 +26,7 @@ Diese Antworten zeigen auf, wie die Anmeldung und Zustellung von Weinen für Wei
|
||||
für Weine in der Weinregion Mosel effizient und profitabel durch eine TYPO3-Erweiterung realisiert werden können.
|
||||
\clearpage
|
||||
|
||||
\paragraph*{Nach welcher Methodik sollten Digitalisierungsprojekte im Maßstab des behandelten Projektes entwickelt werden, um effizient und profitabel zu sein?}
|
||||
\subsection*{Nach welcher Methodik sollten Digitalisierungsprojekte im Maßstab des behandelten Projektes entwickelt werden, um effizient und profitabel zu sein?}
|
||||
In der Literaturrecherche zur Wahl von Methodiken in der Softwareentwicklung und Digitalisierung
|
||||
im Kontext der effizienten
|
||||
und profitablen Umsetzung des hier behandelten Projektes stellten sich komplexe und aufwändige Modelle als
|
||||
@@ -34,16 +34,17 @@ ungeeignet heraus. Vielmehr beeindruckten simple, agile Modelle durch ihren geri
|
||||
der bei kleinen Projekten, wie der hier beleuchteten Aufgabenstellung, unabdinglich ist, um eine effiziente und profitable
|
||||
Umsetzung gewährleisten zu können.
|
||||
|
||||
\paragraph*{Welche Anforderungen sind an die TYPO3-Erweiterung gestellt?}
|
||||
\subsection*{Welche Anforderungen sind an die TYPO3-Erweiterung gestellt?}
|
||||
Um ein Pflichtenheft für die hier beleuchtete TYPO3-Erweiterung zu erarbeiten,
|
||||
wurde eine Anforderungsanalyse in Form eines Interviews mit dem \ac{PO} durchgeführt.
|
||||
Auch wurde eine quantitative Studie in Form eines Online-Fragebogens bezüglich der Bedürfnisse der Teilnehmer angestrengt, die ohne Ergebnisse verblieb.
|
||||
Dieses Pflichtenheft zeigt unter anderem auf, dass Mitglieder sowie Nichtmitglieder Teilnehmer sein können,
|
||||
wie die Nutzerführung aussieht, welche Werkzeuge \ac{WM}-Mitarbeitern zur Verfügung stehen und wie verschiedene Schnittstellen aussehen.
|
||||
Auch ist eine wichtige Erkenntnis, dass regelmäßige Statusmeetings mit dem \ac{PO} durchgeführt werden sollten.
|
||||
Das vollständige Ergebnis dieser Anforderungsanalyse liegt im Anhang anbei, unter fullref{chap:anhang-pflichtenheft}.
|
||||
Auch ist eine wichtige Erkenntnis, dass regelmäßige Statusmeetings mit dem \ac{PO} durchgeführt werden sollten,
|
||||
damit pragmatisch inkorrekte Anforderungen und Merkmale rechtzeitig erkannt und korrigiert werden können.
|
||||
Das vollständige Pflichtenheft liegt im Anhang anbei, unter \fullref{chap:anhang-pflichtenheft}.
|
||||
|
||||
\paragraph*{Welche QR-Code-Bibliothek ist für das behandelte Projekt gut geeignet?}
|
||||
\subsection*{Welche QR-Code-Bibliothek ist für das behandelte Projekt gut geeignet?}
|
||||
Um die Anmeldung und Zustellung von Weinen digital umsetzen zu können, ist lt. Anforderungen ein QR-Code-Generator notwendig.
|
||||
Generell sollten erwägte Bibliotheken aktiv gepflegt, einen gewissen Grad
|
||||
an Funktionalität aufweisen und für den angedachten Workflow geeignet sein. Das ist wichtig, damit sich dieser
|
||||
@@ -51,17 +52,17 @@ effizient, schnell und somit kostengünstig integrieren lässt.
|
||||
Vergleiche zwischen sechs QR-Code-Bibliotheken legen nahe, dass \textit{chillerlan/php-qrcode} die beste Eignung
|
||||
der betrachteten QR-Code-Generatoren aufweist.
|
||||
|
||||
\paragraph*{Wie wird sichergestellt, dass sich der digitalisierte Teilprozess der Weinanmeldung und -zustellung nahtlos mit dem verbleibenden Prozess integriert?}
|
||||
\subsection*{Wie wird sichergestellt, dass sich der digitalisierte Teilprozess der Weinanmeldung und -zustellung nahtlos mit dem verbleibenden Prozess integriert?}
|
||||
Es ist essenziell, die Schnittstelle zwischen dem digitalisierten Teilprozess und dem verbleibenden analogen Teilprozess
|
||||
zu schützen. Das wird sichergestellt, indem die Ausgabe des digitalisierten Teilprozesses der Ausgabe des vorherigen,
|
||||
analogen Teilprozesses gleicht. Ist das gegeben, kann der neue, digitale Teilprozess effizient in den Geschäftsprozess
|
||||
der Jahresauswahlproben integriert werden, dies weil die darauf aufbauenden Schritte mit der Ausgabe der digitalisierten Schritte
|
||||
kompatibel sind.
|
||||
|
||||
%\paragraph*{Wie können unangemessen hohe Entwicklungskosten vermieden werden?}
|
||||
%\subsection*{Wie können unangemessen hohe Entwicklungskosten vermieden werden?}
|
||||
%Vermeidbarer Aufwand in der Entwicklung ohne ausreichende Vorteile (Kosten-Nutzen-Rechnung) fällt zulasten der Effizienz.
|
||||
\section{Diskussion}
|
||||
\paragraph*{Nach welcher Methodik sollten Digitalisierungsprojekte im Maßstab des behandelten Projektes entwickelt werden, um effizient und profitabel zu sein?}
|
||||
\subsection*{Nach welcher Methodik sollten Digitalisierungsprojekte im Maßstab des behandelten Projektes entwickelt werden, um effizient und profitabel zu sein?}
|
||||
Um eine Entwicklungsmethodik für die Umsetzung einer wie in der Problemstellung beschriebenen TYPO3-Erweiterung auszuwählen,
|
||||
wurde eine Literaturrecherche durchgeführt.
|
||||
Diese Literaturrecherche lässt darauf schließen, dass sich simple, agile Methodiken, ohne nennenswerten Mehraufwand,
|
||||
@@ -78,9 +79,11 @@ Bei Einbezug anderer Projekttypen und -beschaffenheiten weichen die geeigneten E
|
||||
Eine Empfehlung für weitere Forschung ist es daher, ähnliche Literaturrecherchen bezüglich
|
||||
angemessener Entwicklungsmethodiken für abweichende Projekttypen und -beschaffenheiten durchzuführen.
|
||||
|
||||
\paragraph*{Welche Anforderungen sind an die TYPO3-Erweiterung gestellt?}
|
||||
\subsection*{Welche Anforderungen sind an die TYPO3-Erweiterung gestellt?}
|
||||
Um detaillierte Anforderungen an die TYPO3-Erweiterung in Erfahrung zu bringen, wurde eine Anforderungsanalyse durch verschiedene
|
||||
Befragunstechniken durchgeführt. Die verwendeten Befragunstechniken sind \enquote{Interview} und \enquote{Online-Fragebogen}.
|
||||
Auch ist es eine wichtige Erkenntnis des Interviews, regelmäßige Statusmeetings mit dem \ac{PO} zu führen.
|
||||
Diese Statusmeetings erlauben das frühzeitige Erkennen und Beheben von pragmatisch inkorrekten Merkmalen und Anforderungen.
|
||||
Es ist wichtig zu erwähnen, dass der Online-Fragebogen unbeantwortet blieb.
|
||||
Das Ergebnis dieser Anforderungsanalyse ist ein detailliertes Pflichtenheft, das die Anforderdungen an die TYPO3-Erweiterung detailliert beschreibt.
|
||||
Dieses zeigt unter anderem auf, dass Mitglieder und Nichtmitglieder Teilnehmer sein können,
|
||||
@@ -90,10 +93,10 @@ Da diese Anforderungsanalyse lediglich die Anmeldung und Zustellung von Weinen b
|
||||
des Jahresauswahlprobenwerkzeuges Forschungen bezüglich darauf aufbauender Anforderungen durchzuführen.
|
||||
|
||||
|
||||
\paragraph*{Welche QR-Code-Bibliothek ist für das behandelte Projekt gut geeignet?}
|
||||
\subsection*{Welche QR-Code-Bibliothek ist für das behandelte Projekt gut geeignet?}
|
||||
Im Interesse eine Bibliothek zur Generierung von QR-Codes für die Umsetzung dieses Softwareprojektes zu finden,
|
||||
die sich effizient, schnell und somit kostengünstig integrieren lässt,
|
||||
wurden sechs QR-Code-Bibliotheken einander gegenübergestellt und in drei verschiedenen Bewertungskategorien verglichen.
|
||||
wurden sechs QR-Code-Biblio\-theken einander gegenübergestellt und in drei verschiedenen Bewertungskategorien verglichen.
|
||||
Diese Bewertungskategorien sind \enquote{Funktionalität}, \enquote{Gepflegtheit} und \enquote{Workflow-Eignung}.
|
||||
Jede dieser Kategorien wurde mit null bis zehn Punkten bewertet. Jede Bibliothek konnte maximal 30 Punkte erhalten.
|
||||
Die Bewertung erfolgte nach subjektiver Einschätzung des Autors, basierend auf Faktoren wie dem Zustand der Github-Seite,
|
||||
@@ -109,20 +112,20 @@ Der Autor empfielt ähnliche Vergleiche für andere Arbeitsumgebungen durchzufü
|
||||
Projektkontexte angemessen sind. Ebenso nimmt dieser Vergleich nur sechs QR-Code-Bibliotheken in Betracht.
|
||||
Eine weitere Forschungsempfehlung ist es daher, weitere Vergleiche mit mehr Bibliotheken durchzuführen.
|
||||
|
||||
\paragraph*{Wie wird sichergestellt, dass sich der digitalisierte Teilprozess der Weinanmeldung und -zustellung nahtlos mit dem verbleibenden Prozess integriert?}
|
||||
\subsection*{Wie wird sichergestellt, dass sich der digitalisierte Teilprozess der Weinanmeldung und -zustellung nahtlos mit dem verbleibenden Prozess integriert?}
|
||||
Im Zuge der praktischen Umsetzung der in dieser Forschungsfrage beschriebenen TYPO3-Erweiterung zeigte sich das Problem
|
||||
der Integration der digitalisierten Weinanmeldung und -zustellung in den restlichen, von dieser Ausarbeitung unberührten
|
||||
Geschäftsprozess der Jahresauswahlprobe.
|
||||
Diese Umsetzung zeigt auf, dass es für eine nahtlose Integration in den existierenden Geschäftsprozess
|
||||
unabdinglich ist, dass die Ausgabe des digitalisierten Teilprozesses der Ausgabe des ersetzten, manuellen Teilprozesses gleicht.
|
||||
Dieser Aspekt wurde zuvor nicht bedacht. Das könnte daran liegen, dass diese Schnittstelle nicht der primäre und auch nicht
|
||||
der sekundäre Fokus der Umsetzung ist. Sie wird nicht benötigt, damit das umgesetzte Produkt intrinsisch funktioniert,
|
||||
der sekundäre Fokus in der Umsetzung ist. Sie wird nicht benötigt, damit das umgesetzte Produkt intrinsisch funktioniert,
|
||||
ist aber dennoch unverzichtlich für eine reibungslose, praktische Verwendung.
|
||||
Hierbei muss jedoch berücksichtigt werden, dass es sich um ein einzelnes, konkretes Projekt handelt und sich aus diesem Grund
|
||||
nicht unbedingt allgemeingültige Schlüsse ableiten lassen. Eine Forschungsempfehlung ist es daher, weitere Möglichkeiten
|
||||
zur Integration verschiedener Teilprozesse zu recherchieren und zu evaluieren.
|
||||
|
||||
%\paragraph*{Welche Endgeräte verwenden Weingüter und was sind ihre Bedürfnisse bezüglich der Jahresauswahlproben?}
|
||||
%\subsection*{Welche Endgeräte verwenden Weingüter und was sind ihre Bedürfnisse bezüglich der Jahresauswahlproben?}
|
||||
%Um zu beleuchten, welche Endgeräte Weingüter im Kontext der Weinanmeldung verwenden und was ihre individuellen Bedürfnisse
|
||||
%im Kontext der Jahresauswahlproben sind, wurde versucht eine quantitative Studie in Form eines Online-Formulares abzuhalten.
|
||||
%Dieses Online-Formular wurde über den Zeitraum eines Monats angeboten und mit der Bitte um Weiterleitung an Weingüter an \ac{WM}
|
||||
@@ -133,4 +136,4 @@ zur Integration verschiedener Teilprozesse zu recherchieren und zu evaluieren.
|
||||
%Es könnte auch sein, dass die Stakeholdergruppe schlicht kein Interesse an einer Teilnahme hatte.
|
||||
%Daher wird die Forschungsempfehlung ausgesprochen, dieselbe Studie erneut in einer Art und Weise durchzuführen, die eine regere Teilnahme begünstigt.
|
||||
|
||||
%\paragraph*{Wie können unangemessen hohe Entwicklungskosten vermieden werden?}
|
||||
%\subsection*{Wie können unangemessen hohe Entwicklungskosten vermieden werden?}
|
||||
|
||||
@@ -3,22 +3,24 @@
|
||||
Die vorliegende Bachelorarbeit befasste sich mit der Frage: \enquote{Wie kann die Anmeldung und Zustellung von Weinen für Weinproben
|
||||
des Regionalverbunds für Weine in der Weinregion Mosel effizient und profitabel durch eine TYPO3-Erweiterung realisiert werden?}
|
||||
Für die Beantwortung wurde eine Literaturrecherche bezüglich Entwicklungsmethodiken, eine Gegenüberstellung existierender Technik
|
||||
zur Erstellung von QR-Codes, verschiedene Befragungstechniken zur Anforderungserfassung sowie die praktischen Umsetzung der
|
||||
zur Erstellung von QR-Codes, verschiedene Befragungstechniken zur Anforderungserfassung sowie die praktische Umsetzung der
|
||||
TYPO3-Erweiterung angestrengt.
|
||||
\\
|
||||
\\
|
||||
Aus den Ergebnissen lässt sich schließen, dass sich insbesondere \enquote{extreme-programming}-Entwicklungsmethodiken eignen,
|
||||
um das aus der Forschungsfrage hervorgehende Projekt zu realisieren.
|
||||
Es wurde gezeigt, dass sich die Bibliothek \textit{chillerlan/php-qrcode} aufgrund herausragender Projektpflege und Workflow-Eignung anbietet,
|
||||
Es wurde gezeigt, dass sich die Bibliothek \enquote{chillerlan/php-qrcode} aufgrund herausragender Projektpflege und Workflow-Eignung anbietet,
|
||||
die mit dem Projekt verbundenen Anforderungen zu erfüllen, die die Erstellung von QR-Codes beschreiben. Die Umsetzung zeigte,
|
||||
dass es unverzichtlich ist, die Schnittstelle zu den verbleibenden Teilprozessen zu schützen, um eine nahtlose Integration mit diesen zu ermöglichen.
|
||||
Es wurde begründet, dass die Durchführung einer Anforderungsanalyse wichtig ist, um ein ausführliches Pflichtenheft auszuarbeiten.
|
||||
Es wurde begründet, dass die Durchführung einer Anforderungsanalyse wichtig ist, um ein ausführliches Pflichtenheft auszuarbeiten
|
||||
und es zeigte sich, dass regelmäßige Statusmeetings mit dem \ac{PO} von Vorteil sind, um die pragmatische Korrektheit laufend zu überprüfen.
|
||||
\\
|
||||
\\
|
||||
Durch diese Forschung wurde somit erwiesen, dass die Anmeldung und Zustellung von Weinen für Weinproben des Regionalverbunds für
|
||||
Weine in der Weinregion Mosel effizient und profitabel durch eine TYPO3-Erweiterung realisiert werden kann, indem für die technische
|
||||
Umsetzung \enquote{extreme-programming}-Entwicklungsmethodiken herangezogen werden, durch eine Anforderungsanalyse ein Pflichtenheft ausarbeitet wird,
|
||||
\break\textit{chillerlan/php-qrcode} als QR-Code-Bibliothek verwendet wird und die Schnittstelle zu den verbleibenden Teilprozessen geschützt wird.
|
||||
Umsetzung \enquote{extreme-programming}-Entwicklungsmethodiken herangezogen werden, durch eine Anforderungsanalyse ein Pflichtenheft ausgearbeitet wird,
|
||||
der aktuelle Stand regelmäßig in Statusmeetings mit dem \ac{PO} besprochen wird, \enquote{chillerlan/php-qrcode} als QR-Code-Bibliothek verwendet wird
|
||||
und die Schnittstelle zu den verbleibenden Teilprozessen geschützt wird.
|
||||
|
||||
\section{Ausblick}
|
||||
\label{chap:ausblick}
|
||||
|
||||
@@ -2,25 +2,26 @@
|
||||
\label{chap:umsetzung}
|
||||
Infolge der Anforderungsanalyse befasst sich das Kapitel \enquote{Konzeption und Umsetzung}
|
||||
mit der Implementation der Anforderungen in dem
|
||||
Brown-Field Projekt \cite{bib:schwarzer-vorlesung-swa} in Form einer TYPO3-Erweiterung.
|
||||
Brown-Field Projekt \cite{bib:schwarzer-vorlesung-swa} in Form einer TYPO3-\break{}Erweiterung.
|
||||
Es ist anzumerken, dass das aus \fullref{chap:anforderungserfassung} hervorgehende Pflichtenheft im Rahmen geplanter und
|
||||
opportunistischer Gespräche mit dem \ac{PO} geringfügige Änderungen erfahren wird.
|
||||
|
||||
\section{Setup der TYPO3-Erweiterung}
|
||||
TYPO3-Erweiterungen werden via Composer installiert \break\cite{bib:typo3-docs-managing-extensions}.
|
||||
TYPO3-Erweiterungen werden via Composer installiert
|
||||
\break\cite{bib:typo3-docs-managing-extensions}.
|
||||
Um eine TYPO3-Erweiterung zu erstellen, muss also ein Composer-Paket erstellt werden.
|
||||
Um vermeidbare Komplexität zu verhindern, wird das Composer-Paket, welches die hier betrachtete
|
||||
TYPO3-Erweiterung darstellt, lokal in den versionierten Ordner \enquote{packages} gelegt.
|
||||
Dieses Verzeichnis wird als Quelle für Composer-Pakete in der
|
||||
Dieses Verzeichnis wird als Quelle für
|
||||
\break{}Composer-Pakete in der
|
||||
Haupt-composer.json-Datei hinterlegt.
|
||||
Somit wird ein Composer-Paket nur für dieses Projekt bereitgestellt,
|
||||
ohne den Aufwand zu betreiben, der üblicherweise mit dem Bereitstellen eines Paketes einhergeht.
|
||||
\\
|
||||
\\
|
||||
Um das grundlegende Setup einer TYPO3-Erweiterung effizient durchzuführen, wird eine
|
||||
existierende Erweiterung mit vergleichbarem Funktionsumfang kopiert, umbenannt und eingefügt.
|
||||
Spezifisch ist dieser \enquote{vergleichbare Funktionsumfang}, dass es ebenfalls Datenmodelle und hochpersonalisierte
|
||||
Frontendlogik in Bezug auf die zuvor genannten Datenmodelle gibt.
|
||||
existierende Erweiterung mit vergleichbarem Funktionsumfang kopiert, angepasst und eingefügt,
|
||||
um eine valide Ordnerstruktur als Ausgangspunkt zu erhalten.
|
||||
|
||||
\section{Digitization}
|
||||
Die Phase der Digitization nach Verhoef et al. befasst sich mit der digitalen Abbildung von Objekten aus der realen Welt
|
||||
@@ -46,12 +47,12 @@ vier Komponenten:
|
||||
\end{description}
|
||||
\cite{bib:typo3-docs-extbase-reference}.
|
||||
|
||||
Im Folgenden wurde ein semiformales Diagramm der Objekte und ihren Relationen
|
||||
Im Folgenden wird ein semiformales Diagramm der Objekte und ihren Relationen
|
||||
angefertigt und in Rücksprache mit dem \ac{PO} finalisiert.
|
||||
|
||||
\begin{nicepic}
|
||||
\includegraphics[width=1\textwidth]{images/objektrelationen-weinlandmosel-einlieferungswerkzeug.png}
|
||||
\captionof{figure}{Objektrelationen: Weinland Mosel Einlieferungswerkzeug, Quelle: Eigene Darstellung}
|
||||
\captionof{figure}{Objektrelationen: Weinland Mosel Jahresauswahlprobenwerkzeug, Quelle: Eigene Darstellung}
|
||||
\label{fig:objektrelationen}
|
||||
\end{nicepic}
|
||||
|
||||
@@ -59,7 +60,7 @@ Nachdem in Erfahrung gebracht wird, welche konkreten Datenobjekte benötigt werd
|
||||
werden Attribute dieser Objekte dem Pflichtenheft entnommen. Diese werden in einem
|
||||
formalen Klassendiagramm festgehalten und in Rücksprache mit dem \ac{PO}
|
||||
weiter bis zu festen Datentypen und Auswahlmöglichkeiten konkretisiert.
|
||||
Beispielsweise dass Wettbewerbskategorien durch TYPO3-Categories repräsentiert werden.
|
||||
Beispielsweise dass Probenkategorien durch TYPO3-Categories repräsentiert werden.
|
||||
Das hat den Vorteil, dass TYPO3-Categories bereits native Bestandteile eines TYPO3-Redaktionssystemes sind
|
||||
und alle relevanten Attribute anbieten. Diese sind Titel,
|
||||
Parentkategorie und Beschreibung.
|
||||
@@ -74,8 +75,8 @@ Ziel dessen ist, dass sich Nutzer für einen vorgefertigten, nominalen Eintrag i
|
||||
entscheiden müssen und dass diese Auswahlmöglichkeiten im TYPO3-Backend pflegbar sind.
|
||||
Weinlagen sind im Brown-Field-Projekt bereits vorhanden, also sollen hierfür existierende Daten
|
||||
wiederverwendet werden.
|
||||
Je Wein sollen beliebig viele Weineigenschaften auswählbar sein. Wettbewerbskategorien,
|
||||
Geschmacksrichtung, etc, sind jeweils nur ein Element.
|
||||
Je Wein sollen beliebig viele Weineigenschaften auswählbar sein. Probenkategorie,
|
||||
Geschmacksangabe, etc, sind jeweils nur ein Element.
|
||||
Weitere Notizen zu diesem Gespräch sind im Anhang unter \fullref{chap:anhang-notizen-digitization}
|
||||
zu finden.
|
||||
\\
|
||||
@@ -187,18 +188,20 @@ Weiterleitungen zu bestimmten Seiten, nachdem ein Nutzer spezielle Events ausgel
|
||||
konfiguriert werden \cite{bib:typo3-docs-femanager}. Logins werden über das TYPO3-native Loginformular
|
||||
gelöst. Im TYPO3-Loginformular können Weiterleitungen zu spezialisierten Seiten im Backend-UI festgelegt werden
|
||||
\break\cite{bib:typo3-docs-felogin}.
|
||||
Für alle funktionalen Belange wird ein TYPO3-Plugin registriert. Dieses Plugin verfügt über einen
|
||||
Für alle funktionalen Belange wird ein TYPO3-Pluginobjekt registriert. Dieses Pluginobjekt verfügt über einen
|
||||
ActionController, der Nutzeranfragen an PHP-Funktionen (\enquote{Actions})
|
||||
bindet.
|
||||
In diesen Actions werden Fehlerbehandlungen durchgeführt, Datenmodelle der Domäne erstellt und in der
|
||||
Datenbank persistiert sowie Daten für die Anzeige im Frontend aufbereitet \cite{bib:typo3-docs-extbase}.
|
||||
Datenbank persistiert sowie Daten für die Anzeige im Frontend der Webseite aufbereitet
|
||||
\break\cite{bib:typo3-docs-extbase}.
|
||||
Neue Datenobjekte werden in Repository-Objekten registriert
|
||||
\break\cite{bib:typo3-docs-extdev-tut-tea-repositories}. Diese Repositories sind Aggregate des Controllers,
|
||||
\cite{bib:typo3-docs-extdev-tut-tea-repositories}. Diese Repositories sind Aggregate des Controllers,
|
||||
werden jedoch nach dem \enquote{Inversion of Control}-Prinzip via Dependency Injection instanziiert und
|
||||
ActionController-Objekten über Methoden übergeben \cite{bib:typo3-docs-di}.
|
||||
\break{}ActionController-Objekten über öffentliche Methoden übergeben
|
||||
\break\cite{bib:typo3-docs-di}.
|
||||
Als problematisch erweisen sich hierbei bidirektionale Verbindungen zwischen Datenmodellen, wenn die Foreign Keys
|
||||
über das SQL-Schlüsselwort
|
||||
\break\enquote{AUTO\_INCREMENT} in der Datenbank generiert werden.
|
||||
\enquote{AUTO\_INCREMENT} in der Datenbank generiert werden.
|
||||
Beispielsweise muss ein Masterrecord, der Betriebsinformationen speichert, bidirektional an ein Teilnehmerobjekt
|
||||
gebunden werden. Hierzu wird jedem der Elemente jeweils der Foreign Key des anderen übergeben.
|
||||
Als Foreign Keys werden hierfür die jeweiligen \acp{UID} herangezogen, da diese Werte durch
|
||||
@@ -247,18 +250,21 @@ werden Formulare und Formfelder mit den entsprechenden Fluid-Form-ViewHelpern au
|
||||
Diese ViewHelper repräsentieren und erstellen gleichnamige HTML-Tags und fügen diesen spezielle
|
||||
Attribute zur Identifizierung in Submit-Aufrufen hinzu \cite{bib:typo3-docs-fluid-form-viewhelpers}.
|
||||
Grundsätzlich entstehen hierbei drei Kategorien von Werten, die es im Formular abzubilden gilt:
|
||||
|
||||
\paragraph*{Inputfelder} sind triviale Formfelder, die nicht durch andere Datensätze beschränkt werden.
|
||||
\\
|
||||
\\
|
||||
\textbf{Inputfelder} sind triviale Formfelder, die nicht durch andere Datensätze beschränkt werden.
|
||||
Beispiele für Inputfelder sind: Weinbeschreibung, Jahrgang und Alkoholgehalt.
|
||||
Inputfelder werden mit simplen Input-Tags umgesetzt und erhalten nach Bedarf \textit{required} und
|
||||
\textit{pattern}-Attribute. Diese Attribute beschreiben jeweils, ob ein Formfeld ein Pflichtfeld ist und
|
||||
mit welcher Regular Expression der Formfeldinhalt abzugleichen ist \cite{bib:w3schools-input}.
|
||||
Die Formfeldwerte können unverändert in der Datenbank persistiert werden.
|
||||
|
||||
\paragraph*{SelectSingle} sind Formfelder, die dem Nutzer eine Auswahl aus $n$ Elementen aus
|
||||
\\
|
||||
\\
|
||||
\textbf{SelectSingle} sind Formfelder, die dem Nutzer eine Auswahl aus $n$ Elementen aus
|
||||
anderen Datenbanktabellen geben. Der Nutzer muss sich für genau ein Element entscheiden.
|
||||
Beispiele für SelectSingle-Formfelder sind: Weinlage, Qualitätsstufe, Rebsorte und Geschmacksangabe.
|
||||
\break{}SelectSingle-Formfelder werden durch Select-HTML-Tags abgebildet. Der TYPO3-Form-ViewHelper für
|
||||
\break{}SelectSingle-Formfelder werden durch Select-HTML-Tags abgebildet.
|
||||
\break{}Der TYPO3-Form-ViewHelper für
|
||||
\enquote{Select} akzeptiert eine Liste an Auswahlmöglichkeiten und erstellt selbstständig Option-HTML-Tags
|
||||
für diese.
|
||||
Die Formfeldwerte von SelectSingle-Formfeldern sind die
|
||||
@@ -315,8 +321,9 @@ auch direkt auswählbar sein sollte. Zudem besitzen Kategorie-Elemente kein Attr
|
||||
von Unterkategorien hindeutet \cite{bib:typo3-docs-sys-category}, womit eine Unterscheidung zwischen
|
||||
Baumblättern und -zweigen nicht ohne weiteres möglich wäre. Diese Entscheidung wäre jedoch
|
||||
benötigt, um zwischen einem Optgroup-Tag und einem Option-Tag abzuwägen.
|
||||
\clearpage
|
||||
|
||||
\paragraph*{SelectMultiple} sind Formfelder, die dem Nutzer eine Auswahl aus $n$ verschiedenen Elementen aus einer anderen
|
||||
\textbf{SelectMultiple} sind Formfelder, die dem Nutzer eine Auswahl aus $n$ verschiedenen Elementen aus einer anderen
|
||||
Datenbanktabelle geben. Der Nutzer kann sich für eine beliebige Auswahl dieser, eingeschlossen keinen, entscheiden.
|
||||
Ein Beispiel für SelectMultiple-Formfelder sind Weineigenschaften.
|
||||
TYPO3-Fluid implementiert hierfür keinen ViewHelper
|
||||
@@ -343,7 +350,8 @@ entfernt. Somit wird beispielsweise der Formfeld-Name \enquote{winekind-18} zu \
|
||||
Übrig bleiben die extrahierten \acp{UID} aller angehakten Elemente $a$, in Form einer Zeichenkette.
|
||||
Über die eingebaute PHP-Funktion \enquote{intval} ist es trivial diese zu Zahlen zu übersetzen,
|
||||
wodurch die tatsächlichen Objekte aus der Datenbank angefragt werden können.
|
||||
|
||||
\\
|
||||
\\
|
||||
\subsection{PDF- und QR-Code-Generierung}
|
||||
Das dynamische Erstellen und Ausgeben des Datenblattes als PDF ist ein essenzieller Bestandteil des
|
||||
Jahresauswahlprobenwerkzeuges, da dieses PDF die Schnittstelle zwischen ankommenden Weinen und dem System darstellt.
|
||||
@@ -354,7 +362,7 @@ Generierung dieses PDFs die Bibliotheken \enquote{chillerlan/php-qrcode} und
|
||||
\enquote{mpdf/mpdf} herangezogen und über Composer installiert.
|
||||
|
||||
\subsubsection{QR-Code-Generierung}
|
||||
Der QR-Code beinhaltet lediglich die Wein-\ac{UID} anstatt einer vollständigen URL. Hintergrund dessen ist, dass
|
||||
Der QR-Code beinhaltet lediglich die Wein-\ac{UID} anstatt einer vollständigen URL. Hintergrund ist, dass
|
||||
die benötigte URL, um einen Wein einzuscannen, bis auf die Wein-\ac{UID} immer identisch ist.
|
||||
Somit wird Redundanz vermieden.
|
||||
Es ist Aufgabe der QR-Code-App, die den Code einscannt, aus der Wein-\ac{UID} eine vollständige URL herzuleiten.
|
||||
@@ -410,7 +418,6 @@ zu anderen Ansichten generiert. Diese ViewHelper übergeben Parameter. Die hierf
|
||||
Ansichten sind beispielsweise Wein-\acp{UID} und Jahresauswahlproben-\acp{UID}. Um Informationen über den angemeldeten Nutzer,
|
||||
wie beispielsweise seiner Teilnehmernummer oder seiner Nutzergruppenzugehörigkeit, zu erlangen, wird sich
|
||||
der Extbase-nativen Domain-Model-FrontendUser-Klasse bedient \cite{bib:typo3-ref-extbase-model-feuser}.
|
||||
|
||||
Mit Abschluss der Phase der Digitization können alle Datenstrukturen im TYPO3-Backend händisch angelegt,
|
||||
eingesehen, gelöscht, bearbeitet und im Frontend von Nutzern befüllt werden.
|
||||
|
||||
@@ -441,8 +448,8 @@ den richtigen Wein eingescanned zu haben.
|
||||
\subsection{CSV-Export}
|
||||
Das letzte Glied des analogen Prozesses, den es zu digitalisieren gilt, ist der Datenexport der Weindaten je Jahresauswahlprobe.
|
||||
TYPO3s ListView bietet einen nativen CSV-Exporter an \cite{bib:pixelant-typo3-data-export},
|
||||
jedoch kommt dieser nicht den Anforderungen gerecht, da das CSV-Dokument Daten verschiedener Datenbanktabellen im Verein
|
||||
beinhalten muss.
|
||||
jedoch wird dieser nicht den Anforderungen gerecht, da das benötigte CSV-Dokument Daten verschiedener Datenbanktabellen im Verein
|
||||
beinhalten muss. Der Native CSV-Exporter gibt jedoch lediglich Inhalte einer Datenbanktabelle aus \cite{bib:pixelant-typo3-data-export}.
|
||||
Um eine reibungslose Integration in die restlichen Prozesse von \ac{WM} zu gewährleisten, muss das exportierte CSV
|
||||
das selbe Format haben, wie bisher bestehende Excel-Dateien. Dieses Format ist durch genaue Spaltennamen,
|
||||
Spalteneihenfolgen und den Arten von Daten, die angefragt werden, definiert.
|
||||
|
||||
@@ -3,14 +3,14 @@
|
||||
Der Stand der Forschung beleuchtet verschiedene Entwicklunsmethodiken zur Digitalisierung.
|
||||
|
||||
\section{Modell nach Parviainen et al.}
|
||||
\quotecite{The importance of digitalization is becoming understood,
|
||||
but the question now is how to do it in practice in order to best benefit from it.}
|
||||
\cite{bib:Parviainen_Tihinen_Kaariainen_Teppola_2022}.
|
||||
Parviainen et al. stellten sich diese Frage und entwickelten in ihrer Forschungsarbeit einen konzeptionellen Rahmen, um zu verstehen, wie die Digitalisierung in der Praxis umgesetzt werden kann und welche Vorteile sich daraus ergeben. Dieser Rahmen basiert auf dem \ac{PDCA} -Prinzip.
|
||||
Parviainen et al. stellten sich die Frage, wie man in der Praxis von Digitalisierung profitieren kann und entwickelten in ihrer Forschungsarbeit
|
||||
einen konzeptionellen Rahmen, um zu verstehen, wie die Digitalisierung in der Praxis umgesetzt werden kann und welche Vorteile sich daraus ergeben.
|
||||
Dieser Rahmen basiert auf dem \ac{PDCA} -Prinzip.
|
||||
\\
|
||||
\\
|
||||
Dieses Rahmenwerk sieht anhand des \ac{PDCA}-Prinzips vier Schritte vor:
|
||||
|
||||
\\
|
||||
\\
|
||||
\textbf{Im ersten Schritt} wird definiert, wie weit die Digitalisierung für das Unternehmen gehen kann und welche Position
|
||||
das Unternehmen dabei anstrebt. Dieser Schritt kann in vier Teilschritte unterteilt werden: Ausmaße, Treiber, Szenarien und
|
||||
Ziele. Für die Bestimmung der Ausmaße ist die Analyse aktueller Trends und deren Relevanz für die Domäne des Unternehmens
|
||||
@@ -19,10 +19,11 @@ wichtig. Ebenfalls ist wichtig, wie weit diese Trends bereits im Fachgebiet vera
|
||||
\\
|
||||
\\
|
||||
Aus den Ergebnissen der Trendanalysen sollten dann Treiber identifiziert werden. Diese Treiber sollten auf der Grundlage zukünftiger Ergebnisse skalierbar sein: Beispielsweise könnten drastische Maßnahmen erforderlich sein, um schlimme Auswirkungen zu verhindern oder große Verbesserungen zu erreichen.
|
||||
\\
|
||||
\\
|
||||
\clearpage
|
||||
|
||||
Für die relevantesten Treiber sollten Zukunftsszenarien untersucht werden. Dies ist wichtig, um zu wissen,
|
||||
welche Auswirkungen bestimmte Trends in welcher Ausprägung haben würden. Relevant sind hier die Vorteile der Umsetzung des Szenarios, die Kosten der Umsetzung, sowie die Risiken, das Szenario nicht umzusetzen oder doch umzusetzen. Auf dieser Basis kann das beste Szenario ausgewählt werden.
|
||||
welche Auswirkungen bestimmte Trends in welcher Ausprägung haben würden. Relevant sind hier die Vorteile der Umsetzung des Szenarios,
|
||||
die Kosten der Umsetzung, sowie die Risiken. Auf dieser Basis kann das beste Szenario ausgewählt werden.
|
||||
\\
|
||||
\\
|
||||
Aus diesem Szenario werden schließlich die Ziele der Digitalisierung abgeleitet. Diese Ziele müssen so formuliert sein, dass sie mit der Ausgangssituation verglichen werden können.
|
||||
@@ -34,7 +35,7 @@ Aus diesem Szenario werden schließlich die Ziele der Digitalisierung abgeleitet
|
||||
\end{nicepic}
|
||||
|
||||
\begin{nicepic}
|
||||
\includegraphics[width=0.5\textwidth]{images/plan-do-check-act.png}
|
||||
\includegraphics[width=0.45\textwidth]{images/plan-do-check-act.png}
|
||||
\captionof{figure}{Das Plan-Do-Check-Act-Modell, Quelle: \cite{bib:abraham2005sustainability}}
|
||||
\label{fig:model-digital-transformation}
|
||||
\end{nicepic}
|
||||
@@ -52,8 +53,8 @@ Zielzustand zu erreichen. Anschließend sollten die konkreten Schritte identifiz
|
||||
Lücke zu schließen. Wenn zum Beispiel ein Treiber \enquote{interne Effizienz} ist, könnten die Schritte darin bestehen, neue digitale
|
||||
Werkzeuge zu integrieren. Schließlich werden diese Schritte analysiert und priorisiert. Prädestiniert dafür sind
|
||||
Kosten-Nutzen-Analysen, Analysen der Umsetzbarkeit, des Wartungsaufwands und der Mitarbeiterschulung.
|
||||
\\
|
||||
\\
|
||||
\clearpage
|
||||
|
||||
\textbf{Der vierte Schritt} befasst sich mit der Umsetzung der in Schritt drei geplanten Maßnahmen und
|
||||
der Bewertung der erzielten Ergebnisse. Diese Bewertung der Ergebnisse sollte z.B. soziokulturelle Barrieren berücksichtigen,
|
||||
die sich aus den Reaktionen bestimmter Stakeholder ergeben, die möglicherweise negativ auf Veränderungen reagieren
|
||||
@@ -68,7 +69,7 @@ Diese drei Phasen sind \textit{Digitization}, \textit{Digitalization} und \texti
|
||||
Die Phase \textit{Digitization} befasst sich mit der Umwandlung analoger Datenstrukturen und Modelle in digitale Datenmodelle,
|
||||
sodass diese digital, in Form von Nullen und Einsen, gespeichert und elektronisch\break weiterverarbeitet werden können
|
||||
\cite{bib:dougherty}\break\cite{bib:loebbecke}.
|
||||
\quotecite{Examples concern the use of digital forms in ordering processes, the use of digital surveys, or the use digital applications for internal financial declarations.} \cite{bib:verhoef}.
|
||||
\quotecite{Examples concern the use of digital forms in ordering processes, the use of digital surveys, or the use digital applications for internal financial declarations.} \cite[S. 891]{bib:verhoef}.
|
||||
\textit{Digitalization} beschreibt den Prozess der Veränderung bestehender Geschäftsprozesse, um mit digitalen Werkzeugen
|
||||
und Datenmodellen zu arbeiten \cite{bib:fengli}. Beispielsweise der Verwendung von Robotern in der Produktion \cite{bib:verhoef}.
|
||||
Die letzte Phase, die \textit{Digitale Transformation}, beschreibt eine firmenweite Veränderung, die beispielsweise
|
||||
|
||||
@@ -8,7 +8,7 @@ Bibliotheken zur Erzeugung von QR-Codes und Bibliotheken zur Erzeugung von PDF-D
|
||||
Als Mitentwickler des Projektes ist dem Autor bekannt, dass die bestehende Webseite ein TYPO3-Redaktionssystem ist. Das Frontend der Webseite wird mit Webpack und Sass übersetzt.
|
||||
Webpack ist ein Modulbundler \cite{bib:smashmagazine-webpack} und Sass ein CSS-Präprozessor
|
||||
\break\cite{bib:w3schools-sass}.
|
||||
TYPO3 ist ein Redaktionssystem und PHP-Rahmen\-werk, das Daten- und Inhaltspflege in einem geschützten Bereich
|
||||
TYPO3 ist ein Redaktionssystem und PHP-\break{}Rahmenwerk, das Daten- und Inhaltspflege in einem geschützten Bereich
|
||||
ermöglicht.
|
||||
Außerdem steuert TYPO3 Frontend-, Backend-Nutzer und deren Berechtigungen \cite{bib:typo3-docs-getting-started}.
|
||||
Über die Systemerweiterung
|
||||
@@ -17,11 +17,11 @@ um hochindividualisierte Funktionalitäten zu ermöglichen.
|
||||
\\\cite{bib:typo3-docs-extbase-reference}
|
||||
|
||||
\section{QR-Code-Bibliotheken}
|
||||
Um mit QR-Codes zu arbeiten, ist es unabdinglich, QR-Codes zu erstellen, da dieselben sonst nicht vorhanden sind.
|
||||
Um mit QR-Codes zu arbeiten, ist es unabdinglich, QR-Codes zu erstellen.
|
||||
Im Folgenden werden einige Implementationen von QR-Code-Generator-Bibliotheken im Detail betrachtet. Es wird sich
|
||||
auf bereits vom System verwendete Programmiersprachen begrenzt.
|
||||
|
||||
\subsection{Javascript-Implementationen}
|
||||
\subsection{JavaScript-Implementationen}
|
||||
\subsubsection*{jquery-qrcode.js}
|
||||
\enquote{jquery-qrcode.js} ist ein Plugin für jQuery, um dynamisch QR-Codes auf Browserseite zu generieren.
|
||||
Jedoch verweist diese Bibliothek selbst auf ihren desolaten Zustand und empfielt stattdessen \enquote{kjua} zu verwenden
|
||||
@@ -33,7 +33,7 @@ um über Neuigkeiten auf dem Laufenden gehalten werden zu wollen \cite{bib:githu
|
||||
\cite{bib:larsjung-jquery-qrcode}.
|
||||
|
||||
\subsubsection*{kjua}
|
||||
\enquote{kjua} ist eine Javascript-Bibliothek, die dynamisch QR-Codes auf Browserebene generiert.
|
||||
\enquote{kjua} ist eine JavaScript-Bibliothek, die dynamisch QR-Codes auf Browserebene generiert.
|
||||
Im Gegensatz zu \enquote{jquery-qrcode.js} funktioniert \textit{kjua} auch ohne jQuery. Es werden diverse Stilattribute für gestaltete
|
||||
QR-Codes unterstützt \cite{bib:larsjung-kjua}. \enquote{kjua} kann QR-Codes über HTML-Canvas, Bilder und Vektorgrafiken umsetzen.
|
||||
Das ist bei näherer Betrachtung der Kjua-Tech-Demo \enpointy{https://larsjung.de/kjua/latest/demo} ersichtlich, jedoch
|
||||
@@ -46,7 +46,7 @@ Issues scheinen ignoriert zu werden. \enquote{kjua} ist MIT-lizensiert \cite{bib
|
||||
serverseitig, als Kommandozeilenwerkzeug, sowohl auch browserseitig an. Die Readme-Datei ist umfangreich, reich an Beispielen
|
||||
und detailreichen Erklärungen. Der letzte Commit ist zu diesem Zeitpunkt knapp älter als ein halbes Jahr. Somit macht das
|
||||
Projekt einen moderat gepflegten Eindruck. Die Readme-Datei verweist auf Unit-Tests bei Travis, jedoch lief die letzte Pipeline
|
||||
vor etwa zwei Jahren, Februar 2021, durch und schlug fehl. Einige Pull-Requests und Issues werden seit Jahren ignoriert
|
||||
Februar 2021 durch und schlug fehl. Einige Pull-Requests und Issues werden seit Jahren ignoriert
|
||||
\cite{bib:soldair-node-qrcode}.
|
||||
Die Bibliothek wurde 74 Millionen mal heruntergeladen und mit 6.308 Sternen markiert.
|
||||
\enquote{Soldair/node-qrcode} ist MIT-lizensiert \cite{bib:npmjs-soldair-node-qrcode}.
|
||||
@@ -82,7 +82,7 @@ Die Bibliothek verwendet die MIT-Lizenz.
|
||||
|
||||
\subsubsection*{Bacon/BaconQrCode}
|
||||
\enquote{Bacon/BaconQrCode} ist eine PHP-Bibliothek zur Generierung von QR-Codes, bereitgestellt von Ben Scholzen, hinter
|
||||
der Github-Organisation \enquote{Bacon}, dessen einziges Mitglied Scholzen darstellt. Verlinkt ist eine Homepage,
|
||||
der Github-\break{}Organisation \enquote{Bacon}, dessen einziges Mitglied Scholzen darstellt. Verlinkt ist eine Homepage,
|
||||
die zu einer Nginx-\enquote{Hello World}-Seite führt. Begleitet wird \enquote{BaconQrCode} von etlichen weiteren \enquote{Bacon-Projekten}
|
||||
wie Beispielsweise \enquote{BaconPdf}, \enquote{BaconStringUtils} und \enquote{BaconUser} um nur einige zu nennen.
|
||||
Insgesamt machen die stichprobenartig betrachteten Projekte einen desolaten Eindruck mit zuteils aktuellesten Commits
|
||||
@@ -109,7 +109,7 @@ Hierfür werden die zuvor vorgestellten Bibliotheken zur Erstellung von QR-Codes
|
||||
\begin{description}
|
||||
\item [Funktionialität] \hfill \\
|
||||
Der Umfang, der unterstützten Funktionen, in Annahme dessen, dass die Bibliothek
|
||||
syntaktisch und semantisch korrekt ist\\\cite{bib:heinemann-vorlesung-re}.
|
||||
syntaktisch und semantisch korrekt ist.
|
||||
|
||||
\item [Gepflegtheit] \hfill \\
|
||||
Das Ausmaß, in dem das Projekt aktiv gepflegt wird und ordnungsgemäß entwickelt zu sein scheint.
|
||||
@@ -149,7 +149,7 @@ Die Exklusivität für Nutzung in Webbrowsern schließt eine Einbindung in den W
|
||||
8 & 2 & 0 & 10\\
|
||||
\hline
|
||||
\end{tabular}
|
||||
\caption{Subjektive Evaluation: kjua}
|
||||
\caption{Subjektive Evaluation zur Eignung als QR-Code-Bibliothek: kjua}
|
||||
\end{table}
|
||||
|
||||
\subsubsection*{soldair/node-qrcode}
|
||||
@@ -171,7 +171,7 @@ drei Punkte gibt.
|
||||
8 & 3 & 4 & 15\\
|
||||
\hline
|
||||
\end{tabular}
|
||||
\caption{Subjektive Evaluation: soldair/node-qrcode}
|
||||
\caption{Subjektive Evaluation zur Eignung als QR-Code-Bibliothek: soldair/node-qrcode}
|
||||
\end{table}
|
||||
|
||||
\subsubsection*{chillerlan/php-qrcode}
|
||||
@@ -197,7 +197,7 @@ bereitgestellt \cite{bib:chillerlan-php-qrcode-composerjson} und weist eine ähn
|
||||
10 & 10 & 10 & 30\\
|
||||
\hline
|
||||
\end{tabular}
|
||||
\caption{Subjektive Evaluation: chillerlan/php-qrcode}
|
||||
\caption{Subjektive Evaluation zur Eignung als QR-Code-Bibliothek: chillerlan/php-qrcode}
|
||||
\end{table}
|
||||
|
||||
\subsubsection*{kreativekorp/barcode}
|
||||
@@ -219,7 +219,7 @@ da eine Verwendung selbst mit guter Funktionalität nicht infrage käme.
|
||||
- & 3 & 0 & -\\
|
||||
\hline
|
||||
\end{tabular}
|
||||
\caption{Subjektive Evaluation: Kreativekorp/barcode}
|
||||
\caption{Subjektive Evaluation zur Eignung als QR-Code-Bibliothek: Kreativekorp/barcode}
|
||||
\end{table}
|
||||
|
||||
\subsubsection*{Bacon/BaconQrCode}
|
||||
@@ -244,12 +244,12 @@ Dadurch werden drei Punkte einer vollkommenen Workflow-Eignung abgezogen, wodurc
|
||||
5 & 8 & 7 & 20\\
|
||||
\hline
|
||||
\end{tabular}
|
||||
\caption{Subjektive Evaluation: Bacon/BaconQrCode}
|
||||
\caption{Subjektive Evaluation zur Eignung als QR-Code-Bibliothek: Bacon/BaconQrCode}
|
||||
\end{table}
|
||||
|
||||
\subsection{Fazit}
|
||||
Nach Evaluation der verschiedenen QR-Code-Bibliotheken im Kontext der vorliegenden Problemstellung erweist sich aus Sicht des Autors
|
||||
\break\enquote{chillerlan/php-qrcode} mit 30 Gesamtpunkten als die am besten geeignetste Bibliothek.
|
||||
\break\enquote{chillerlan/php-qrcode} mit 30 Gesamtpunkten als die am besten geeignetste Bibliothek unter den Betrachteten.
|
||||
Somit wird \enquote{chillerlan/php-qrcode} als QR-Code Technologie in der Lösung dieser Problemstellung verwendet.
|
||||
|
||||
\begin{table}[htbp]
|
||||
@@ -266,9 +266,10 @@ Somit wird \enquote{chillerlan/php-qrcode} als QR-Code Technologie in der Lösun
|
||||
kreativekorp/barcode & - & 3 & 0 & -\\
|
||||
\hline
|
||||
\end{tabular}
|
||||
\caption{Gesamtübersicht: Subjektive Evaluation der QR-Code Bibliotheken}
|
||||
\caption{Gesamtübersicht: Subjektive Evaluationen zur Eignung von QR-Code Bibliotheken}
|
||||
\label{tbl:qrlib-compare-barchart}
|
||||
\end{table}
|
||||
\clearpage
|
||||
|
||||
\section{PDF-Generator}
|
||||
Firmenintern ist der PDF-Generator \enquote{mpdf/mpdf} etabliert und wird bereits
|
||||
|
||||
@@ -26,11 +26,10 @@ Studiengang \cfgUniversityDegreeCourse\\
|
||||
\cfgAuthorName, \cfgAuthorMatriculationNum\\
|
||||
\cfgAuthorContact\\
|
||||
mit Medienagenten Stange \& Ziegler oHG\\
|
||||
30.03.2023\\
|
||||
\cfgDateLastModification\\
|
||||
\cfgAuthorCity\\
|
||||
\vspace{3mm} \ \\
|
||||
Erstgutachter Prof. Dr. Volker Schwarzer\\
|
||||
Zweitgutachterin Prof. Dr. Elisabeth Heinemann\\
|
||||
\cfgUniversityCity\\
|
||||
Erstbetreuer: Prof. Dr. Volker Schwarzer\\
|
||||
Zweitbetreuerin: Prof. Dr. Elisabeth Heinemann\\
|
||||
|
||||
\end{titlepage}
|
||||
|
||||
@@ -3,18 +3,17 @@
|
||||
%
|
||||
|
||||
% Document title
|
||||
\newcommand{\cfgDocTitle}{Bachelorarbeit}
|
||||
\newcommand{\cfgDocTitle}{Bachelor of Science}
|
||||
\newcommand{\cfgDocSubTitle}{Wie kann die Anmeldung und Zustellung von Weinen für Weinproben des Regionalverbunds für Weine in der Weinregion Mosel effizient und profitabel durch eine TYPO3-Erweiterung realisiert werden?}
|
||||
|
||||
% Document classification
|
||||
\newcommand{\cfgDocClassification}{Thesis zur Erlangung des akademischen Grades
|
||||
Bachelor of Science}
|
||||
\newcommand{\cfgDocClassification}{Thesis zur Erlangung des akademischen Grades}
|
||||
|
||||
% Document version
|
||||
\newcommand{\cfgDocVersion}{2.7}
|
||||
\newcommand{\cfgDocVersion}{3}
|
||||
|
||||
% Last modification date
|
||||
\newcommand{\cfgDateLastModification}{30. März 2023}
|
||||
\newcommand{\cfgDateLastModification}{31. März 2023}
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
|
||||
|
||||
@@ -7,7 +7,9 @@
|
||||
\begin{description}
|
||||
|
||||
\item [Frontend] \hfill \\
|
||||
\quotecite{Das Frontend einer Webseite ist der Teil der Webseite, der Endnutzern präsentiert wird. Ein Frontend besteht aus HTML und Cascading Style Sheets} \cite{bib:udjaja}.
|
||||
\quotecite{Front-end website is a combination of
|
||||
hypertext markup language (HTML), cascading style sheets (CSS) and JavaScript that generates pages that can be
|
||||
viewed and interacted directly with the user.} \cite[S. 294]{bib:udjaja}.
|
||||
|
||||
\item [TYPO3-Backend] \hfill \\
|
||||
\quotecite{The backend's main role is to enable users to create and publish
|
||||
@@ -36,6 +38,10 @@
|
||||
Mitglieder profitieren von einer Reihe an
|
||||
Vorteilen, wie beispielsweise einer Auflistung auf Weinland Mosels Internetauftritt.
|
||||
Durch diesen Auftritt sind bereits Stammdatensätze vorhanden.
|
||||
Durch eine Teilnahme an einer Jahresauswahlprobe ist ein Unternehmen kein Mitglied.
|
||||
Nur durch eine Teilnahme an einer Jahresauswahlprobe ist ein Unternehmen kein Mitglied.
|
||||
|
||||
\item [Flight] \hfill \\
|
||||
Pro Tisch einer Jahresauswahlprobe werden sechs Weine gleichzeitig eingeschenkt und bewertet.
|
||||
Das ist ein Flight. Pro Tisch gibt es mehrere aufeinanderfolgende Flights.
|
||||
|
||||
\end{description}
|
||||
|
||||
@@ -135,7 +135,7 @@
|
||||
title = {EKSPANPIXEL BLADSY STRANICA: Performance Efficiency Improvement of Making Front-End Website Using Computer Aided Software Engineering Tool},
|
||||
journal = {Procedia Computer Science},
|
||||
volume = {135},
|
||||
pages = {292-301},
|
||||
pages = {{292-301}},
|
||||
year = {2018},
|
||||
note = {The 3rd International Conference on Computer Science and Computational Intelligence (ICCSCI 2018) : Empowering Smart Technology in Digital Era for a Better Life},
|
||||
issn = {1877-0509},
|
||||
@@ -275,28 +275,12 @@
|
||||
note = {Zugriff: Januar 2023}
|
||||
}
|
||||
|
||||
@article{bib:christoph-ebert-vorwort-systematisches-re,
|
||||
title = {Vorwort zu Systematisches RE},
|
||||
@article{bib:christoph-ebert-systematisches-re,
|
||||
title = {Systematisches Requirements Engineering: Anforderungen ermitteln},
|
||||
year = {2019},
|
||||
author = {Christoph Ebert},
|
||||
publisher = {dpunkt Verlag}
|
||||
}
|
||||
|
||||
@book{bib:basiswissen-re,
|
||||
author={Pohl, Klaus and Rupp, Chris},
|
||||
title={Basiswissen Requirements Engineering},
|
||||
subtitle={Aus- und Weiterbildung nach IREB-Standard zum "Certified Professional for Requirements Engineering" : Foundation Level nach IREB-Standard},
|
||||
edition={4., {\"u}berarbeitete Auflage},
|
||||
publisher={dpunkt.verlag},
|
||||
address={Heidelberg},
|
||||
year={2015},
|
||||
pages={1 Online-Ressource (xix, 171 Seiten)},
|
||||
language={ger},
|
||||
isbn={978-3-86491-673-1 and 978-3-86491-674-8 and 3-86491-674-7},
|
||||
note={Description based upon print version of record},
|
||||
keywords={CPRE},
|
||||
url={https://ebookcentral.proquest.com/lib/ub-heidelberg/detail.action?docID=2029882},
|
||||
library={UB},
|
||||
publisher = {dpunkt Verlag},
|
||||
volume = {6}
|
||||
}
|
||||
|
||||
@article{bib:kleine-re-fibel,
|
||||
|
||||
Binary file not shown.
@@ -2,21 +2,21 @@
|
||||
% Selbstständigkeitserklärung
|
||||
%
|
||||
|
||||
\includepdf[pages=-]{images/selbststaendigkeitserklaerung.pdf}
|
||||
%\includepdf[pages=-]{images/selbststaendigkeitserklaerung.pdf}
|
||||
|
||||
%\chapter*{Selbstständigkeitserklärung}
|
||||
%
|
||||
%Hiermit erkläre ich, dass ich die vorliegende Arbeit selbstständig und ohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe.
|
||||
%Alle Stellen, die wörtlich oder sinngemäß aus veröffentlichten und nicht veröffentlichten Schriften
|
||||
%entnommen wurden, sind als solche kenntlich gemacht. Die Arbeit ist noch nicht in
|
||||
%gleicher oder ähnlicher Form oder auszugsweise im Rahmen einer anderen Prüfung
|
||||
%vorgelegt worden.
|
||||
%\\
|
||||
%\\
|
||||
%\\
|
||||
%\hspace*{\fill}\cfgAuthorCity, \cfgDateLastModification
|
||||
%\\
|
||||
%\\
|
||||
%\\
|
||||
%\\
|
||||
%\hspace*{\fill}\cfgAuthorName\ \ \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
|
||||
\chapter*{Selbstständigkeitserklärung}
|
||||
|
||||
Hiermit erkläre ich, dass ich die vorliegende Arbeit selbstständig und ohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe.
|
||||
Alle Stellen, die wörtlich oder sinngemäß aus veröffentlichten und nicht veröffentlichten Schriften
|
||||
entnommen wurden, sind als solche kenntlich gemacht. Die Arbeit ist noch nicht in
|
||||
gleicher oder ähnlicher Form oder auszugsweise im Rahmen einer anderen Prüfung
|
||||
vorgelegt worden.
|
||||
\\
|
||||
\\
|
||||
\\
|
||||
\hspace*{\fill}\cfgAuthorCity, \cfgDateLastModification
|
||||
\\
|
||||
\\
|
||||
\\
|
||||
\\
|
||||
\hspace*{\fill}\cfgAuthorName\ \ \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
|
||||
|
||||
Reference in New Issue
Block a user