Checkliste Web-App vs. Native App

Die folgenden Fragen sollen helfen, die richtige Entscheidung zwischen Web-App und nativer App zu treffen. Dabei sind die Empfehlungen, die aus den Antworten folgen, oft nicht eindeutig. Am Ende ist eine Zusammenschau nötig, wenn nicht irgendeine der Fragen zu einem KO-Kriterium für die eine oder die andere Technologie wird. Beginnen wir mit der komplexesten Frage:

Muss die Arbeit auch ohne ständige Verbindung zum Server möglich sein?

Wenn während der Arbeit ständig Daten vom Server benötigt werden, oder wenn dort ständig Daten abgelegt werden müssen, ist sowohl eine Web-App als auch die native App geeignet. Umgekehrt liegen die Dinge jedoch anders. Soll die App auch im Funkloch, also ohne Verbindung zum Internet funktionieren, ist zunächst die native App zu bevorzugen. Sie kann quasi unbegrenzt Daten lokal speichern und lässt sich natürlich, einmal installiert, auch ohne Netzverbindung aufrufen. Wenn die Serververbindung wieder steht, werden die Daten einfach übertragen. Gute Beispiele sind hier die Apps der Social-Media-Netzwerke, die das inzwischen wunderbar können.

Allerdings sind Web-Apps, die auf HTML5 basieren, auch in der Lage, Daten zwischenzuspeichern, sodass auch mit ihnen eine Weiterarbeit ohne Internetverbindung in gewissem Umfang möglich ist.

Beispiel: INDAL hat eine Web-App zur Kontrolle von Messtationen entwickelt, die oft an Orten ohne stabile Internet-Verbindung stehen. Bevor der Kontrolleur die Station aufruft, lädt er die Daten, dann gibt er vor Ort die aktuellen Werte ein – wenn die Internet-Verbindung wieder da ist, werden diese übertragen.

Wenn ohnehin ständig auf Daten aus dem Netz zugegriffen werden muss, spielt dieses Kriterium keine Rolle – dann sind Web-App und native App gleich gut geeignet.

Wird die Hardware des Smartphones oder Tablets benötigt?

Benötigt die Anwendung Zugriff auf Kamera, Mikrofon, Geo-Lokalisierung, Beschleunigungssensor und andere Teile der Hardware des Smartphones oder Tablets? In diesem Fall ist die native App zu bevorzugen. Mit ihr kann optimal auf diese Komponenten zugegriffen werden.

Allerdings ist es nicht so, dass eine Web-App da völlig “machtlos wäre”. Das Fotografieren oder das Ermitteln der aktuellen Position etwa ist auch von einer mobilen Webseite aus möglich. Hier muss man also genau untersuchen, was man braucht.

Müssen verschiedene Plattformen (iOS, Android) unterstützt werden?

Wenn man überhaupt nicht weiß, ob der Benutzer mit einem iPhone oder einem Android-Smartphone unterwegs ist, dann muss für jede Plattform eine gesonderte native App erstellt werden. Das macht die Sache teuer, zumal man die App dann auch noch via App-Store bereitstellen muss (in jedem Fall bei iOS, bei Android ist das nicht zwingend nötig). Will man diese Kosten sparen, bleibt nur die universelle Web-App – die natürlich auch in den verschiedenen Browsern, die auf den Smartphones und Tablets installiert sein können (Opera, Safari, Google Chrome), ausgiebig getestet werden müssen.

Allerdings ist es gerade bei Business-Anwendungen möglich, genau festzulegen, auf welchem Endgerät die App zum Einsatz kommt. Dann muss nur für diese Plattform entwickelt werden.

Beispiel: INDAL hat die eigene Projektzeitererfassung als Android-App entwickelt. Wer ein Android-Smartphone oder Tablet hat, kann diese nutzen, die anderen Mitarbeiter nutzen die Web-App.

Weiteres Beispiel: Für einen Kunden, dessen Vertriebsmitarbeiter eine Vielzahl von Verkaufs- und Vertragsdaten immer dabei haben wollen, wurde eine Android-App entwickelt. Die Vertriebsmitarbeiter wurden mit den passenden Geräten ausgestattet. Die Daten laden sie sich rechtzeitig vor dem Kundenbesuch auf das Tablet – so benötigen sie während des Gesprächs keine Internet-Verbindung.

Fazit

Es gibt noch einige weitere Fragen, aber die obigen drei helfen am besten bei der Entscheidung, ob eine Web-App oder eine native App für eine Business-Anwendung die richtige Lösung ist. Auf beiden Wegen ist es möglich, leistungsstarke Anwendungen für Geschäftsprozesse zu implementieren.

Weitere Informationen zur Entwicklung von Android-Apps bei INDAL finden Sie hier.

Der Beitrag Mobile Geschäftsanwendungen – Web-App oder native App erschien zuerst auf INDAL Software-Spezialist.

Vor allem aber sind die Planungsgranularitäten in jedem Unternehmen anders. In dem einen genügt eine monatsgenaue Projektverwaltung, während im nächsten auf Wochen- oder Tagesbasis geplant werden muss. In einem Falle genügt es, die Ressoucen als Mitarbeiterpools auf Abteilungsebene zuzuordnen, woanders müssen alle Mitarbeiter einzeln geplant werden. Wieder in anderen Situationen treten Mischformen auf.

Nun kann man sagen: Das alles ist doch auch mit Standard-Projektmanagement-Lösungen möglich. Das ist richtig. Allerdings ist es sehr schwierig, diese dann so zuzuschneiden, dass die Benutzer genau das bekommen, was sie gerade brauchen, und nicht mit der Funktionsvielfalt überfordert werden.

Dafür muss an der Standard-Software oft so viel angepasst werden, dass es sinnvoller ist, gleich eine Individuallösung zu programmieren. Microsoft Access bietet sich dazu aus vielen Gründen als Tool an:

1. Die Zahl der Benutzer, die mit der Lösung wirklich arbeiten sollen, ist überschaubar.
2. Die Datenmengen sind durch Access zu bewältigen. Auch die Komplexität der Datenstrukturen und Abfragen ist zumeist nicht problematisch.
3. Access bietet von sich aus eine einfache Benutzeroberfläche, die den Nutzern aus anderen Anwendungen bekannt ist. Die Erstellung neuer Dialoge ist einfach.
4. Das Reporting erfordert keine oder geringen Programmierkenntnisse und ist flexibel auf neue Anforderungen anpassbar.

Dem stehen allerdings auch Nachteile gegenüber. Als wichtigster ist zu nennen, dass eine Access-Lösung nur im lokalen Netzwerk oder im Intranet eines Unternehmens betrieben werden kann.

Zumeist überwiegen jedoch die Vorteile, wie eine Reihe individueller Projektsteuerungs-Lösungen zeigen, die wir bei INDAL in den letzten Jahren entwickelt haben.

Der Beitrag Individuelle Projektsteuerung mit Microsoft Access erschien zuerst auf INDAL Software-Spezialist.

Aber so ein Szenario ist sehr unwahrscheinlich. Das elektronische System eines modernen Autos ist hoch komplex, gerade kürzlich schrieb jemand, bei diesen Autos handle es sich eigentlich um Computer, die Daten sammeln und Prozesse steuern und zufällig auch fahren können. Die Entwicklungsprozesse sind nicht minder komplex: Da werden Pakete und Releases geplant, designt und realisiert und umfangreiche Tests konzipiert, durchgeführt und dokumentiert.

Die fragliche Manipulation ist ein Change Request, der eine Vielzahl von Nebenwirkungen haben kann und deshalb umfassend getestet werden muss. Schließlich will ja niemand, dass das Auto plötzlich auch auf der Straße so läuft, wie beim Abgastest, oder dass es plötzlich ganz zum Softwareversagen kommt.

Es ist deshalb ganz unwahrscheinlich, dass nur ein paar wenige Leute von den Manipulationen gewusst haben. Anderenfalls gäbe es bei VW keine systematische Qualitätssicherung, keine unabhängigen Tests von Software und Systemkomponenten. Das wäre nicht nur noch schlimmer, als das, was jetzt schon ans Licht gekommen ist, es wäre unter solchen Bedingungen kaum möglich, noch Autos zu produzieren, die fahren.

Also werden sehr viele Leute gewusst oder vermutet haben, was da läuft. Manager, Programmierer, Tester, Ingenieure, Arbeiter. Sie fanden das offenbar alle nicht erwähnenswert. Mancher von ihnen wird auch mal zu einem anderen Autobauer gewechselt haben. Dass da bisher gar nichts ans Licht gekommen ist, lässt mich vermuten, dass dieses Verhalten branchenüblich ist.

Der Beitrag Ein Blick auf Dieselgate aus Sicht eines Softwareentwicklers erschien zuerst auf INDAL Software-Spezialist.

Aber auch das Messnetz muss überwacht werden. Dafür ist unser Kunde, ein Landesamt in Düsseldorf, zuständig. Für diese Überwachung ist es weiterhin notwendig, dass hin und wieder ein Mensch zur Messstation fährt und sie ganz herkömmlich “in Augenschein nimmt”. Dass er dann vor Ort eine Internet-Verbindung hat, über die er sich mit einer zentralen Datenbank verbinden kann, ist nicht immer sicher.

Deshalb entwickeln wir bei INDAL derzeit in einem individuellen Softwareprojekt eine Lösung, bei der die Mitarbeiter, welche die Messstationen kontrollieren, die Stationsdaten in eine kleine lokale Datenbank “auschecken”. Diese lokale Datenbank nehmen sie auf die Dienstreise mit, in ihr nehmen sie draußen an den Stationen ihre Änderungen vor. Nach der Rückkehr des Mitarbeiters werden die geänderten Daten in die zentrale Datenbank zurück übertragen.

Wichtig ist einerseits, dass der Mitarbeiter vor Ort über eine klare, intuitiv und einfach zu nutzende Benutzeroberfläche verfügt. Vor allem kommt es aber auch darauf an, dass beim “einchecken” in die zentrale Datenbank Konflikte erkannt und beseitigt werden. Es kann nämlich sein, dass zwei Kollegen kurz nacheinander die gleiche Station besuchen um unterschiedliche Kontrollen vorzunehmen. Diese Daten dürfen natürlich nicht gegenseitig überschrieben werden, vielmehr müssen sie im Normalfall einfach zusammengeführt werden können.

Die Lösung wird bei INDAL mit Microsoft Access erstellt, wobei eine Anbindung an eine Client-Server-Datenbank wie MS-SQL-Server jederzeit möglich ist.

Der Beitrag Die Überwachung der Umwelt überwachen erschien zuerst auf INDAL Software-Spezialist.

So weit – so gut. Aber als Geschäftsführer dieses Unternehmens, der gleichzeitig Philosoph ist, kann ich bei dieser etwas oberflächlichen Betrachtung nicht stehenbleiben.

Digital, das bedeutete bekanntlich ursprünglich: Ja oder Nein, Wahr oder Falsch, 1 oder 0. Wir wissen, dass irgendwo tief in den Computern, mit denen wir die Digitalisierung vorantreiben, immer noch das elektronische Schaltprinzip und die einfache mathematische Logik des Ja-oder-Nein gilt. Aber darüber sind viele Schichten von Software gelegt, und an der Benutzeroberfläche, so scheint es, ist nichts mehr digital: Da gibt es Nachkommastellen, Texte, Bilder, viele mögliche Werte.

“Digitalisierung” – das scheint nur noch ein Wort zu sein, ein Synonym für “Computernutzung” oder “Vernetzung im Internet”, und scheint nichts mehr mit der ursprünglichen Bedeutung zu tun zu haben. Aber dieser erste Eindruck trügt, das merkt man immer, wenn man bei der Anforderungsanalyse und der Softwarespezifikation etwas genauer hinschaut. Noch immer treffen wir da wichtige Ja-Nein-Entscheidungen, und noch immer müssen wir uns ständig zwischen Wahr und Falsch entscheiden.

Digitalisierung von Geschäftsprozessen, das müssen wir zunächst mal ganz klar eingestehen, bedeutet, die unendliche Vielgestaltigkeit der realen Vorgehensweisen und Abläufe auf ein paar Standard-Prozesse abzubilden, Ausnahmen zu verbieten, Normen zu setzen.

Das hat viele Vorteile. So kann man verlangen, dass wichtige Stammdaten von Kunden bereits am Anfang eines Bestellprozesses angelegt werden. Damit ist man sicher, dass die Daten auf jeden Fall im System sind, wenn sie gebraucht werden.

Auf der anderen Seite, das hat wohl schon fast jeder erlebt, ist man auf diese Weise den eingeschränkten Optionen der Software ohnmächtig ausgeliefert, ob man der Benutzer oder der Betroffene ist. Digitalisierung bedeutet, eben auch “Alles oder nichts”. Mal etwas kurz am Rand notieren, ein Wort dahin schreiben, wo eine Zahl hingehört, etwas schon mal aufnehmen oder halbfertig beiseite legen, all das ist nach der Digitalisierung oft nicht mehr möglich.

Wir müssen die Rede von der Digitalisierung ganz wörtlich nehmen, und die Konsequenzen im konkreten Fall ehrlich und offen beurteilen. Nur so ist es möglich, die Chancen zu nutzen und die Risiken zu beherrschen. In einer digitalen Welt, in der es nur noch Schwarz und Weiß, aber kein Grau und schon gar kein Regenbogenspektrum mehr gibt, will ja dann doch niemand leben. Wir müssen unsere Software so gestalten, dass sie mehr erlaubt als verbietet.

Der Beitrag Geschäftsprozesse digitalisieren – Chancen und Risiken erschien zuerst auf INDAL Software-Spezialist.

Es wird häufig unterschätzt, dass sich nicht nur die Funktionen einer Software mit der Weiterentwicklung ändern, dass sie komfortabler oder leistungsfähiger werden, sondern dass sich die ganze Art der Kommunikation zwischen Nutzer und System ändert. Ein typisches Beispiel dafür ist der Stream, den die Menschen heute aus allen sozialen Netzwerken kennen: Hier werden ihnen, zugeschnitten auf die persönliche Einbindung des Einzelnen in das Netzwerk, die letzten relevanten Ereignisse aufgelistet.

Auch das Unternehmen ist ein soziales Netzwerk, und die Arbeit im Unternehmen ähnelt dem Agieren in den Internet-Communities oft mehr, als man denkt. Die Erwartungen an das, was eine Unternehmenssoftware leistet, werden in großem Maße dadurch geprägt, wie wir im Alltag mit Software umgehen.

Wenn Software entstehen soll, die von den Nutzern akzeptiert wird und in der sie sich leicht zurecht finden, dann ist es sinnvoll, sich bei der Konzeption der Benutzerschnittstelle an den Systemen zu orientieren, die uns allen im Alltag begegnen.

Dazu müssen Softwarelösungen zumeist nicht einmal komplett neu erstellt werden, denn die eigentlichen Anwendungsfälle bleiben weitgehend unverändert. Es geht um die Frage, wie die Funktionen gefunden werden, wie ein Mitarbeiter die Vorgänge wiederfindet, mit denen er sich tags zuvor beschäftigt hatte, wie ein Kollege auf die Zuarbeit eines anderen zugreifen kann. Hier bewähren sich die Konzepte des sozialen Netzwerks.

Der Beitrag Web-Lösungen prägen das Denken, auch im Unternehmen erschien zuerst auf INDAL Software-Spezialist.

Jede Entscheidung während des Entwurfs und der Programmierung einer Software ist eine Spekulation über die Zukunft.

Weiterlesen auf heise Developer

Der Beitrag Über spekulierende Softwareentwickler erschien zuerst auf INDAL Software-Spezialist.

Der Prototyp sollte einen Durchstich durch alle Schichten der Anwendung realisieren, somit etwa das Lesen und Schreiben von Daten, die Businesslogik und die Oberfläche umfassen. Allerdings muss hier genauer hingesehen werden. Wenn z.B. die GUI verschiedene Typen von Funktionen umfasst, sollte jeder Typ im Prototypen repräsentiert sein, Masken ebenso wie die Programmsteuerung und Reports. Das Gleiche gilt für die anderen Schichten der Anwendung.

Der Prototyp soll zeigen, wie die Migration erfolgen kann, und das betrifft zweierlei:

1. Wie wird aus den Architekturzusammenhängen der Altanwendung die Architektur der zukünftigen Anwendung? Wenn die Altanwendung z.B. eine Client-Server-Anwendung ist, die in eine Webumgebung migriert werden soll, dann ist damit zumeist auch eine neue Anwendungsarchitektur verbunden. Ein Prototyp ist also immer auch Architekturprototyp.
2. Wie kann der Code der Altanwendung möglichst systematisch (automatisch oder nach engen Programmierrichtlinien) in die neue Architektur übertragen werden? In der Regel ist das mit einem Refactoring der Businesslogik verbunden. Der Prototy sollte es erlauben, strikte Anweisungen für die “Umarbeitung” einer Anwendungsfunktion auf die neue Plattform zu definieren, oder sogar Codegeneratoren zu konzipieren, die aus dem alten Code den neuen erzeugen – wenigstens zum großen Teil.

Schließlich sollte ein Migrationsprototyp möglichst auch ein Oberflächenprototyp sein. An der Oberfläche muss eine Applikationsmigration immer den größten Spagat vollbringen: Einerseits soll der Anwender die vertrauten Funktionen ohne weiteres intuitiv wiederfinden, andererseits hat er zumeinst auch eine Erwartung, wie eine Anwendung in der neuen Umgebung auszusehen hat. Eine PC-Anwendung hat bestimmte typische Oberflächenelemente, die eine Web-Applikation nicht oder anders implementiert – und umgekehrt. Ein Oberflächenprototyp kann zeigen, wie die vertrauten Elemente sich plausibel in der neuen Umgebung wiederfindenlassen – Migration von Anwendungen ist immer ein bisschen so wie behutsame Fassadensanierung, man möchte modernisieren, aber den vertrauten Charme auch bewahren.

Der Beitrag Migrations-Prototypen erschien zuerst auf INDAL Software-Spezialist.

All diese Aspekte können dafür sprechen, auch über Jahre gewachsene Client-Server-Anwendungen in eine Web-Architektur zu überführen. Dazu sind allerdings eine Reihe von Vorüberlegungen nötig. Von einer kompletten Neuprogrammierung ist, auch wenn Ausgangs- und Ziel-Technologien weit auseinander liegen, zumeist abzuraten. Neue Anforderung und neue Technologien  in einem Projekt zu vereinen vergrößert die Gefahr, dass das Projekt zu einem Millionengrab wird und nie zu einem erfolgreichen Ende gebracht wird.

Welcher Ansatz der richtige ist, hängt oft nicht primär von der Technologie der bisherigen Anwendung ab. Ob sie in Visual Basic oder C/C++ oder in Java geschrieben ist, oder ob es sich gar um eine Großrechner-Anwendung handelt, ist zumeist nicht so wichtig wie die Frage, ob die Anwendung eine klare Schichten-und Modul-Architektur hat und ob Entwicklungsstandards während der gesamten Lebenszeit der Anwendung weitgehend eingehalten wurden.

Eine einfache Checkliste kann zu einer ersten Beurteilung eines Software-Migrationsprojekts hilfreich sein. Auf ihrer Basis ist eine Analyse möglich die zeigt, welche Bestandteile ein Durchstich-Prototyp haben sollte, mit dessen Hilfe eine seriöse Kosten- und Zeitschätzung für eine erfolgreiche Migration möglich ist.

Der Beitrag Ins Web erschien zuerst auf INDAL Software-Spezialist.

Ein Beispiel: In unserer Software SceddyPro werden natürlich auch die Regelungen des Arbeitszeitgesetzes berücksichtigt, und zwar schon in dem Moment, in dem der Benutzer die bevorzugten Schichtmuster vorgibt. Soll die Software nun verbieten, dass Muster definiert werden, in denen die Zeit zwischen zwei Schichten kürzer ist, als nach dem Gesetz erlaubt, oder soll nur eine Warnung angezeigt werden?

Wir haben uns dafür entschieden, dem Benutzer einen Hinweis zu geben, wenn er die gesetzlichen Vorgaben verletzt, ihm jedoch die Entscheidung zu überlassen, ob er streng nach dem Gesetz plant oder nicht.

Die Situation ist mit der eines Autofahrers vergleichbar, dem das Navigationssystem anzeigt, welche maximale Geschwindigkeit zulässig ist. Theoretisch wäre es denkbar, dass das System unmittelbar dafür sorgt, dass diese Vorschrift auch eingehalten wird. Auch wenn eine solche technische Lösung von manchem gewünscht wird, lehnen die meisten Fahrer sie ab. Einerseits trauen wir der Technik nicht zu, für jede Veränderung der konkreten lokalen Verkehrsvorschriften immer die aktuellen Daten ins Auto übertragen zu können, ganz davon abgesehen, dass das Navigationsystem auch Fehler machen kann. Andererseits kann es Ausnahmesituationen geben, in denen wir selbst entscheiden müssen, welche Geschwindigkeit wir fahren müssen.

So ist es auch im Fall einer Personaleinsatzplanungslösung wie SceddyPro. Einerseits ist trotz Softwarewartung und Aktualisierungsservice nicht sicher, ob die Software jeden Fall und jede Veränderung der Regelungen sofort enthalten kann. Andererseits, und das ist noch wichtiger, muss der Planer selbst in jedem Moment entscheiden können, wie er das Personal plant. Für die Einhaltung der Vorschriften ist er verantwortlich, und wie er dieser Verantwortung gerecht wird, muss er auch selbst entscheiden.

Zurück zu obigem Beispiel: ein Mitarbeiter wird für die Spätschicht und die Frühschicht am Tag darauf eingeplant. Die Ruhezeit dazwischen entspricht nicht den Vorschriften.  Der Planer vereinbart mit dem Mitarbeiter deshalb, dass er die Spätschicht etwas früher verlässt und etwas später zur Frühschicht kommt und dann entsprechend länger bleibt. Damit wird die Regelung eingehalten, das aber bei der Planung im System schon zu berücksichtigen, würde einen großen Aufwand bedeuten.

Zumeist ist, so zeigt sich an diesem Bispiel, eine Softwarelösung dann der praktischen Situation am besten angemessen, wenn sie dem Benutzer die Entscheidung über die konkrete Regeleinhaltung überlässt. Denn gearbeitet wird nicht in der Software, sondern am tatsächlichen Arbeitsplatz, und da passiert manches, was sich unsere Softwareweisheit kaum träumen lässt.

Der Beitrag Verbieten oder Warnen? erschien zuerst auf INDAL Software-Spezialist.