3 Vom Use Case zur Enterprise-App

Die Ausstattung mobil arbeitender Mitarbeiter mit Smart Devices gehört heutzutage fast zum Standard. Dies gilt nicht nur für große Unternehmen und Konzerne, sondern auch für den Mittelstand sowie den öffentlichen Sektor. Durch den vermehrten Einsatz von Tablets und Smartphones im privaten Gebrauch trauen sich Unternehmen immer häufiger, die Vorteile der mobilen Anwendungen auch im Geschäftsalltag für sich zu nutzen. Die Anwendungsbereiche umfassen dabei die Verwendung einfacher Kalender- und Mail-Apps bis hin zu maßgeschneiderten Businessapplikationen, die komplexe Geschäftsprozesse abbilden. Das im Nachfolgenden dargelegte Beispiel zeigt, dass sinnvoll integrierte, mobile Anwendungen in der Lage sind, bestehende Geschäftsprozesse effizienter zu gestalten und Mehrwert zu generieren.

Als Ausgangslage für die App dient ein klassischer Papierprozess, wie er in vielen Unternehmen und Behörden zu finden ist. Das Beispielszenario stützt sich auf die Bauwerksprüfung nach DIN 1076 „Ingenieurbauwerke im Zuge von Straßen und Wegen – Überwachung und Prüfung“. Als Ingenieurbauwerke sind in der DIN 1076 Brücken, Verkehrszeichenbrücken, Tunnel, Trogbauwerke, Stütz- und Lärmschutzbauwerke sowie sonstige Ingenieurbauwerke, wie Regenrückhaltebecken, definiert. Die Straßenbauverwaltung hat im Rahmen der öffentlichen Daseinsvorsorge unter Beachtung der Wirtschaftlichkeit für die Standsicherheit, Verkehrssicherheit und Dauerhaftigkeit der Ingenieurbauwerke im Zuge von Straßen und Wegen einzustehen. Aus diesem Grund müssen diese in regelmäßigen Abständen auf Schäden untersucht werden. Hierzu wird dem zuständigen Prüfingenieur eine Liste der Bauwerke vorgelegt, die in einem Begehungszyklus inspiziert werden müssen. Während der Begehung muss der Mitarbeiter ein Prüfprotokoll ausfüllen und Schäden, sowohl bereits behobene als auch neue, handschriftlich dokumentieren und mit Bildern belegen. Die unterschriebenen Protokolle werden anschließend in einem Archiv abgelegt. Kommt es aufgrund baulicher Mängel zu einem Unfall, dienen sie als Nachweis für eventuell bekannte Schäden. Aus Gründen der Verständlichkeit wurde der Prozess etwas vereinfacht dargestellt, entspricht aber einer realen Ausgangslage.

Doch welche Schritte sind notwendig, um einen solchen Prozess zu digitalisieren? Im ersten Schritt sollte in einem Anforderungsworkshop der bestehende Prozess analysiert und, falls notwendig, dokumentiert werden.

Neben den eigentlichen Entscheidern sollten auch Mitarbeiter aus den Fachbereichen frühzeitig in den Entwicklungsprozess einbezogen werden. Diese sind mit Prozessen und Arbeitsabläufen durch den täglichen Einsatz oftmals sehr gut vertraut und können einen wichtigen Beitrag zum Erfolg einer App leisten. Dadurch, dass die Anwender direkt von Anfang an mit dabei sind, werden Berührungsängste abgebaut und die Akzeptanz der Lösung gesteigert.

Ziel dieses Workshops sollte es sein, alle Kundenanforderungen zu verstehen. Auch wenn das Konzept von UWP-Apps vorsieht, dass nur noch eine Implementierung erforderlich ist, um eine Applikation auf verschiedenen Gerätefamilien betreiben zu können, ist das Entstehen zusätzlicher Aufwände für plattformspezifische Anpassungen nicht auszuschließen. Aus diesem Grund empfiehlt es sich, die Zielplattformen in einem frühen Stadium festzulegen und darauf zu verweisen, dass eine Erweiterung der aktiv von der App unterstützten Plattformen meist mit überschaubaren Aufwänden durchführbar ist. Sind externe Systeme wie Datenbanken oder Web Services involviert, sollten Aspekte hinsichtlich Erreichbarkeit, Authentifizierung und Datenschutz ebenfalls frühzeitig geklärt werden. Organisationen, die mit der Einführung von UWP-Apps noch am Anfang stehen, aber eine zentrale Datenbank benötigen, sind mitunter gut beraten, einen Cloud-Dienst in Anspruch zu nehmen. So lassen sich Aufwände für das Freischalten von Firewalls, Konfigurieren von Proxyservern usw. einsparen. Gleiches gilt für prototypische Implementierungen. Sind alle Kundenanforderungen verstanden und offene Fragen geklärt, kann die nächste Phase eingeleitet werden. Für das Anfertigen von Designentwürfen stellt Microsoft verschiedene Vorlagen für zum Beispiel PowerPoint und Photoshop bereit. Diese enthalten eine Sammlung von UWP-App-typischen Oberflächenelementen und ermöglichen das schnelle Erstellen von ersten Designentwürfen. Es ist ratsam, für jede App-Seite einen eigenen Entwurf mit allen notwendigen Oberflächensteuerelementen zu fertigen. Auf übermäßige Detailverliebtheit sollte aber bewusst verzichtet werden. Wichtig ist es, die eigentliche Zielsetzung der App nicht aus den Augen zu verlieren. Auch sollte darauf geachtet werden, die Oberflächen nicht zu überfrachten, denn ein überladenes UI wirkt schnell abschreckend, getreu dem Motto „manchmal ist Weniger mehr“. Überhaupt sollte die App möglichst intuitiv und einfach zu bedienen sein. Ein Benutzer, der mit dem Bedienkonzept von UWP-Apps vertraut ist, sollte sich ohne ausführliche Anleitung innerhalb weniger Minuten in die App einfinden können. Dennoch sollte der Detailgrad ausreichend sein, um die Entwürfe an eine Designagentur übermitteln zu können. Ob eine Designagentur hinzugezogen werden sollte, hängt stark von den Projektrahmenparametern ab. Fällt die Entscheidung zugunsten einer Agentur, muss diese sowohl Vorgaben hinsichtlich verwendeter Schriftarten und -größen, erlaubter Farben, Pixelraster usw. sowie sämtliche Grafiken in den verschiedenen benötigten Auflösungen zum Beispiel für den Splash-Screen bekommen.

Wie fast überall im Leben spielt das Thema Design auch bei Universal-Apps eine wichtige Rolle, denn mit reinen Technikfakten lassen sich die wenigsten Anwender dauerhaft begeistern.

Nach einer Freigabe der Designentwürfe kann dann mit der eigentlichen App-Entwicklung begonnen werden.

3.1 Festlegen der Zielgeräte

Ein großer Vorteil des Gerätefamilienkonzepts ist, dass eine Universal-App auf einer Vielzahl verschiedener Geräte ausgeführt werden kann. Im Gegensatz zu klassischen Windows-8.1- und Windows-Phone-8.1-Anwendungen zielen Universal-Apps nicht auf ein bestimmtes Betriebssystem ab, sondern auf eine oder mehrere Gerätefamilien. Eine Gerätefamilie identifiziert sich durch spezifische APIs oder Gerätecharaktermerkmale wie bestimmte Sensoren (Abbildung 3.1).

Abbildung 3.1: Hierarchie der UWP-Gerätefamilie

Die Funktionsweise beruht darauf, dass auf oberster Ebene, der Universal Device Family, eine bestimmte Reihe von Funktionen und APIs garantiert wird, die auf jeder Plattform zur Verfügung stehen. Je nach gewählter Gerätefamilie kommen einige weitere spezielle APIs hinzu. Mittels adaptivem Code lassen sich gerätespezifische APIs, zum Beispiel für das Ansteuern von Sensoren, ermitteln (Listing 3.1). Hierzu lässt sich die ApiInformation.IsTypePresent-Methode verwenden, die den zu prüfenden Typ in Form einer Zeichenkette entgegennimmt und einen bool-Wert zurückliefert.

Listing 3.1: Überprüfung auf das Vorhandensein gerätespezifischer APIs

Vor der Entwicklung einer jeden App sollte darüber nachgedacht werden, welche Gerätefamilie oder Gerätefamilien die App unterstützen soll. Dies hängt natürlich stark von den Anforderungen bzw. den Funktionen und Zielgruppen der App ab und muss letztendlich bei jeder Neuentwicklung individuell getroffen werden. Durch die Festlegung auf einen Formfaktor bzw. eine Gerätefamilie lässt sich der Fokus auf die Optimierung der App für die bestimmten Zielgeräte setzen. Bei entsprechender Berücksichtigung ist es zu einem späteren Zeitpunkt mit geringem Aufwand möglich, die App für weitere Formfaktoren anzupassen. Diese Vorgehensweise ist besonders für Pilotprojekte mit kleinem Budget zu empfehlen. Welche Gerätefamilie die App adressieren soll, lässt sich über das App-Manifest in der Package.appxmanifest-Datei festlegen. Im TargetDeviceFamiliy-Element können des Weiteren noch Bedingungen hinsichtlich der mindestens benötigten und der höchsten Windows-10-Version, mit der die App getestet wurde, angegeben werden. Standardmäßig enthält das Name-Attribut den Wert Windows.Universal, was bedeutet, dass die gesamte Universal-Gerätefamilie unterstützt wird (Listing 3.2).

Listing 3.2: Die UWP-App unterstützt die gesamte Universal-Gerätefamilie

Eine weitere Variante besteht darin, eine App für eine bestimmte Unterfamilie auszulegen (Listing 3.3).

Listing 3.3: Beschränken der UWP-App auf eine bestimmte Unterfamilie

Dieser Ansatz ergibt immer dann Sinn, wenn eine gerätefamilienübergreifende Nutzung unwahrscheinlich ist (z. B. bietet eine Navigations-App keinen Mehrwert, wenn sie für eine Xbox optimiert wird). Bei diesem Szenario garantiert das Universal-App-Konzept alle APIs der Universal-Gerätefamilie zuzüglich der gerätefamilienspezifischen APIs.

Da ein Desktopcomputer und eine Xbox sich charakteristisch sehr ähneln, kann es unter Umständen sinnvoll sein, bei der...