Windows-App-Outsourcing und Auftragsentwicklung: Was Sie vor der Beauftragung klären sollten

Wenn Sie das Outsourcing oder die Auftragsentwicklung einer Windows-Anwendung in Erwägung ziehen, ist die erste Entscheidung nicht nur „mit welcher Technologie wird entwickelt”.

In der Praxis erhalten wir häufig Anfragen wie diese:

• Wir möchten eine alte Windows-Software überarbeiten
• Wir können eine interne App, die ein Vorgänger erstellt hat, nicht übernehmen
• Die Kommunikation mit einem Gerät oder Messinstrument bricht gelegentlich ab
• 32-Bit / 64-Bit, COM / ActiveX und VBA-Integration sind alle beteiligt
• Nach dem Umzug auf Windows 11 oder einen neuen PC funktioniert sie nicht mehr
• Wir möchten alles klären, einschließlich Bereitstellung, Codesignierung, automatischer Updates und SmartScreen-Warnungen
• Wir möchten Abstürze oder Speicherwachstum nach langer Laufzeit untersuchen lassen

Mit anderen Worten: Windows-App-Outsourcing und Auftragsentwicklung bedeutet nicht nur „neue Bildschirme bauen”. Es muss als Arbeit verstanden werden, die die Untersuchung bestehender Ressourcen, Überarbeitung, Ersatz, Geräteintegration, Bereitstellung, Wartung und Fehleranalyse umfasst.

Dieser Artikel fasst aus Sicht des Auftraggebers die Punkte zusammen, die Sie klären sollten, bevor Sie Windows-App-Outsourcing oder Auftragsentwicklung in Auftrag geben.

Bereiche, die bei Windows-App-Auftragsentwicklern häufig angefragt werden

1. Neuentwicklung von Geschäftsanwendungen

Dies sind Fälle, in denen Eingabemasken, Suchmasken, Berichtsausgaben, CSV-Integration, Dateiintegration und die Anbindung externer Systeme, die den internen Betrieb unterstützen, als Windows-Anwendung erstellt werden.

Die Gründe, eine Windows-App statt einer Webanwendung zu wählen, laufen meist auf Folgendes hinaus:

• Sie benötigen eine feingranulare Verarbeitung von Dateien und Ordnern auf dem lokalen PC
• Sie möchten USB-Geräte, Messinstrumente, SPS oder Kameras integrieren
• Sie müssen die App in Offline-Umgebungen oder geschlossenen Netzwerken einsetzen
• Sie möchten bestehende Excel-, VBA-, COM- und DLL-Ressourcen nutzen
• Sie benötigen Tastatur, Barcode-Leser oder Touchpanel an Arbeitsplatz-Terminals
• Sie benötigen residente Überwachung oder Hintergrundverarbeitung

Auch bei einer Neuentwicklung verringert die frühzeitige Entscheidung, ob es eine Windows-App sein muss, ob eine Webanwendung ausreicht oder ob nur ein Teil auf der Windows-Seite verbleiben soll, spätere Kurskorrekturen.

2. Überarbeitung und Wartung bestehender Windows-Software

Bei Anfragen zu Outsourcing und Auftragsentwicklung ist die Überarbeitung und Wartung bestehender Software häufiger als eine komplette Neuentwicklung.

Zum Beispiel Situationen wie diese:

• Der Quellcode existiert, aber niemand weiß, wie man ihn baut
• Er lässt sich nur mit einer alten Version von Visual Studio öffnen
• Er ist bei VB6, MFC, WinForms oder .NET Framework stehen geblieben
• Der Verantwortliche hat das Unternehmen verlassen, und niemand kennt die Spezifikation
• Nach Windows-Updates oder einem PC-Wechsel wurde der Betrieb instabil
• Geschäftspartner oder die Belegschaft fordern neue Funktionen

In diesen Fällen beginnen wir, statt sofort neu zu bauen, mit einer Bestandsaufnahme:

• Welchen Geschäftsprozess unterstützt die Anwendung?
• Welche Funktionen sind unverzichtbar?
• In welcher Umgebung läuft sie?
• Von welchen externen Geräten, DLLs, Datenbanken und Netzlaufwerken hängt sie ab?
• Sind Protokolle und Fehlerinformationen vorhanden?
• Sind Quellcode, Build-Anleitung, Installationsprogramm und Konfigurationsdateien noch vorhanden?

Dass bestehende Software läuft, ist an sich schon ein Wert. Deshalb wird in der Auftragsentwicklung, statt nur „alles wegwerfen und neu bauen”, eine stufenweise Denkweise wichtig – behalten, einkapseln oder ersetzen.

Wenn COM / ActiveX / OCX im Spiel ist, klären Sie zunächst die Begriffe mit Eine ausführliche Erklärung der Unterschiede zwischen COM, ActiveX und OCX, und überlegen Sie sich die Migrationsstrategie anhand von Perspektiven wie der Entscheidungstabelle „Behalten / Einkapseln / Ersetzen” für ActiveX/OCX, um leichter voranzukommen.

3. Geräteintegration und Anbindung externer Ausrüstung

In Fertigung, Prüftechnik, Messtechnik, im medizinischen Umfeld und in der Forschung sind Windows-Anwendungen häufig mit externer Ausrüstung verbunden.

Typische Integrationsziele sind:

• Serielle Kommunikationsgeräte
• USB-Geräte
• Industriekameras
• SPS
• Messinstrumente
• Barcode-Leser
• Netzlaufwerke und NAS
• Bestehende native DLLs
• Vom Hersteller bereitgestellte SDKs

In diesem Bereich reicht es nicht, nur Bildschirme zu bauen – Sie müssen auch entwerfen, wie die Kommunikation abbricht, wie die Wiederverbindung erfolgt, Timeouts, Protokollierung, Rohdatenspeicherung und Statusanzeige.

Insbesondere serielle Kommunikation neigt zu Problemen bei Empfangseinheiten, Timeouts, Wiederverbindung und eingefrorener UI. Daher ist es sicher, Perspektiven wie Fallstricke bei der Entwicklung von Apps mit serieller Kommunikation von Anfang an zu berücksichtigen.

Zudem reicht der Zustand externer Geräte manchmal nicht aus, wenn er nur mit „verbunden” oder „nicht verbunden” beschrieben wird. Wenn Sie Vorhandensein, Antwortverhalten, Funktionsbereitschaft, Datenaktualität und Konfigurationsübereinstimmung getrennt betrachten, entsteht ein Bildschirm, der vor Ort seltener missverstanden wird. Näheres dazu in Design von Statusanzeigen für externe Geräte.

4. Fehleranalyse und Ursachenforschung

Bei der Auftragsentwicklung von Windows-Apps ist manchmal eine Fehleranalyse nötig, noch bevor Funktionserweiterungen anstehen.

Häufige Anfragen sehen so aus:

• Die App stürzt nur ein paar Mal am Tag ab
• Der Speicherverbrauch wächst nach langer Laufzeit kontinuierlich
• Sie funktioniert nur auf einem bestimmten PC nicht
• Die Kommunikation mit einem Gerät stoppt für ein paar Sekunden
• Bei der Dateiintegration gehen Daten verloren
• Niemand kennt die Reproduktionsschritte
• Die Protokolle sind zu spärlich, um die Ursache nachzuvollziehen

Solche Probleme lassen sich nicht allein durch das Betrachten des Codes lösen. Zunächst werden Beobachtungspunkte entworfen und Protokolle, Absturz-Dumps, Kommunikationsprotokolle, Ereignisprotokolle, Speicherverbrauch, Handle-Anzahl und Ähnliches gesammelt.

Bei der Absturzuntersuchung ist entscheidend, wie Sie den Beweis vom Moment des Absturzes festhalten, wie in Wie man Protokolle bei Windows-App-Abstürzen ausgibt und Einführung in die Sammlung von Absturz-Dumps (WER/ProcDump/WinDbg) beschrieben.

Bei wachsendem Speicherverbrauch müssen Sie unterscheiden, ob es sich nur um Warten auf den GC oder um ein echtes Speicherleck handelt. Für .NET-Anwendungen folgen Sie dem Vorgehen aus Beobachten, Vergleichen und Nachweisen, wie in GC-Wartezeit und Speicherlecks in .NET unterscheiden beschrieben.

5. Bereitstellung, Signierung und automatische Updates

Bei Windows-Apps stolpern Teams oft erst nach der Fertigstellung – bei der Frage „wie wird sie verteilt”.

• Wird ein Installationsprogramm erstellt?
• Oder werden die Dateien einfach abgelegt und ausgeführt?
• Können Standardbenutzer sie installieren?
• Werden Administratorrechte benötigt?
• Wird über interne Dateifreigaben verteilt?
• Oder laden Benutzer sie aus dem Web herunter?
• Werden automatische Updates benötigt?
• Wie wird das Codesignaturzertifikat gehandhabt?
• Wie werden SmartScreen-Warnungen erklärt und behandelt?

Zu den Bereitstellungsoptionen gehören MSI, MSIX, ClickOnce, xcopy und eigene Updater. Die Wahl sollte nicht davon abhängen, „was am einfachsten ist”, sondern davon, was beim Betriebssystem registriert wird und wer die Verantwortung für Updates trägt. Näheres dazu im Leitfaden zur Auswahl der Bereitstellungsmethode für Windows-Apps.

Für interne .NET-Windows-Apps, die an Standardbenutzer verteilt werden sollen und leichte automatische Updates benötigen, siehe Einführung in ClickOnce: Bereitstellung, Updates und Auswahlkriterien.

Andererseits werfen Web-Verteilung und externe Verteilung Fragen zu SmartScreen-Warnungen und Codesignierung auf. Warum die Meldung „Windows hat Ihren PC geschützt” erscheint, ist zusammengefasst in Warum Windows „Windows hat Ihren PC geschützt” anzeigt.

Fünf Dinge, die Sie vor der Beauftragung von Windows-App-Outsourcing oder Auftragsentwicklung klären sollten

1. Was nicht stillstehen darf

Als Erstes sollten Sie nicht eine Funktionsliste klären, sondern „die Geschäftsprozesse, die nicht zum Stillstand kommen dürfen”.

• Die Auftragsabwicklung stoppt
• Die Prüflinie steht still
• Berichte können nicht ausgegeben werden
• Die Kommunikation mit dem Gerät bricht ab
• Mitarbeiter vor Ort fallen auf manuelle Arbeit zurück
• Audits und Nachweise bleiben nicht erhalten

Bei der Auftragsentwicklung geht es nicht nur darum, Bildschirme und Funktionen zu bauen – das Design muss auch dafür sorgen, dass der Betrieb nicht zum Stillstand kommt. Sobald diese Prioritäten klar sind, lässt sich leichter entscheiden, welche Funktionen gebaut werden müssen, welche zurückgestellt werden können und welche Fehler zuerst untersucht werden sollten.

2. Die aktuelle App und ihre Umgebung

Bei der Überarbeitung und Wartung einer bestehenden App wird nicht nur die App selbst, sondern auch die umgebende Umgebung geprüft.

Informationen, die es sich zu klären lohnt:

• App-Name, Zweck und nutzende Abteilungen
• Anzahl der Benutzer und Anzahl der Maschinen
• Windows-Versionen
• 32-Bit / 64-Bit
• .NET Framework / .NET Versionen
• Visual-Studio-Version
• Datenbanken, Netzlaufwerke, externe APIs
• Angebundene Geräte, DLLs, SDKs
• Installationsverfahren
• Speicherort der Konfigurationsdateien
• Speicherort der Protokolle
• Ob der Quellcode vorhanden ist
• Ob eine Build-Anleitung vorhanden ist
• Ob Unterlagen des Vorgängers vorhanden sind

Je vollständiger diese Informationen vorliegen, desto genauer werden Angebote und Untersuchungen. Fehlen umgekehrt Informationen, ist es sicherer, die erste Phase als „Bestandsaufnahme” auszugliedern.

3. Neuentwicklung, Überarbeitung oder Ersatz?

Bei Windows-App-Anfragen ist es oft besser, sich nicht von vornherein für „neu bauen” zu entscheiden.

Ob eine .NET-Framework-App weiter genutzt oder auf .NET migriert werden sollte, hängt vom App-Typ, den abhängigen Bibliotheken, der COM-Integration und der Bereitstellungsmethode ab. Eine vorherige Bestandsaufnahme der Prüfpunkte, wie in der Checkliste vor der Migration von .NET Framework zu .NET, erleichtert die Entscheidung erheblich.

4. Bereitstellung, Updates und Berechtigungen

Bei Windows-Apps hakt es manchmal nicht bei der Entwicklung, sondern bei der Bereitstellung.

Besonders zu klären sind folgende Punkte:

• Wird sie von Standardbenutzern verwendet?
• Gibt es Vorgänge, die Administratorrechte erfordern?
• Installation für alle Benutzer oder pro Benutzer ausreichend?
• Nur interne Nutzung oder auch externe Verteilung?
• Werden automatische Updates benötigt?
• Gibt es Offline-Geräte?
• Ist Codesignierung erforderlich?
• Muss Microsoft Defender SmartScreen berücksichtigt werden?
• Gibt es Verwaltungsrichtlinien wie Intune, GPO oder App Control?

Die Trennung von Vorgängen, die Administratorrechte erfordern, von solchen, die dies nicht tun, erhöht sowohl die Sicherheit als auch die Handhabbarkeit im Alltag. Die Berechtigungsgrenze lässt sich anhand von Perspektiven wie Wann Windows-Administratorrechte erforderlich sind – und wann nicht prüfen.

5. Wartungsfreundlichkeit

Bei der Auftragsentwicklung zählt nicht nur, dass die App bei der Lieferung funktioniert. Sie soll in einem Zustand hinterlassen werden, in dem auch Jahre später eine andere verantwortliche Person untersuchen, überarbeiten und erneut ausliefern kann.

Wartungsfreundliche Windows-Apps zeichnen sich durch Folgendes aus:

• Die Build-Anleitung ist erhalten
• Abhängige Bibliotheken und ihre Versionen sind bekannt
• Speicherort und Bedeutung der Konfigurationsdateien sind bekannt
• Protokolle werden in einer für die Untersuchung nützlichen Granularität ausgegeben
• Bei einem Absturz bleiben Nachweise erhalten
• Es gibt Bereitstellungs- und Rückrollverfahren
• Die Verantwortlichkeiten im Quellcode sind klar getrennt
• Vorgänge, die Administratorrechte erfordern, sind begrenzt
• Geheime Informationen werden nicht im Klartext gespeichert

Für die minimale Sicherheitsprüfung vor der Veröffentlichung prüfen Sie Berechtigungen, Signierung, geheime Informationen, Kommunikation, Eingaben, DLLs und Protokollierung, wie in der Sicherheits-Checkliste für Windows-Apps beschrieben.

Wenn Passwörter oder Tokens in Konfigurationsdateien gespeichert werden, muss ein Design her, das Klartext-Speicherung vermeidet und die Mechanismen von Windows zum Schutz nutzt. Näheres dazu in Wie man vertrauliche Informationen in Konfigurationsdateien sicher speichert.

Häufige Entscheidungen bei der Technologiewahl für Windows-Apps

Die Wahl zwischen WinForms, WPF und WinUI

Bei der Neuentwicklung von Windows-Apps ist es eine wiederkehrende Frage, welche der Technologien WinForms, WPF oder WinUI verwendet werden soll.

Grob verglichen sieht das so aus:

Allerdings ist die neueste Technologie nicht immer die richtige Antwort. Die Wahl muss die Erfahrung des bestehenden Teams, den Wartungshorizont, die Bereitstellungsmethode, die Bildschirmanforderungen und die umgebenden Bibliotheken einbeziehen.

Näheres dazu als Entscheidungstabelle im Leitfaden zur Auswahl von WinForms/WPF/WinUI.

Reicht C# / .NET aus, oder brauchen Sie C++ oder native DLLs?

Die meisten Geschäftsanwendungen lassen sich vollständig mit C# / .NET bauen. In Fällen wie den folgenden kommen jedoch C++, native DLLs, P/Invoke, C++/CLI und COM in Betracht:

• Das Hersteller-SDK richtet sich an C/C++
• Sie müssen bestehende DLLs aufrufen
• Es gibt hochperformante Bildverarbeitung oder Gerätesteuerung
• Sie müssen bestehende COM-Ressourcen nutzen
• Sie müssen die 32-Bit-/64-Bit-Grenze überschreiten

Bei solchen Projekten müssen Sie nicht nur die Einfachheit der UI-Erstellung klären, sondern auch Prozessgrenzen, Speicherbesitz, Ausnahmen, Threading und Bitness.

Windows-App oder Web-App?

Wir erhalten auch Anfragen wie „Wir möchten eine alte Windows-App zu einer Web-App machen”. Manchmal ist der Wechsel zum Web richtig, aber nicht alles sollte zwangsläufig eine Web-App werden.

Windows-Apps eignen sich gut für Fälle wie diese:

• Direkte Verbindung zu Geräten oder lokaler Ausrüstung
• Offline-Nutzung
• Verarbeitung großer lokaler Dateien
• Nutzung bestehender COM-/DLL-/VBA-Ressourcen
• Schnelle Bedienung an Arbeitsplatz-Terminals
• Residente Überwachung und Hintergrundverarbeitung

Wenn andererseits mehrere Standorte auf dieselben Daten zugreifen sollen, ausschließlich der Browser genutzt werden soll oder die Geräteverwaltung reduziert werden soll, können ein Web- oder Cloud-Ansatz besser passen.

In der Praxis gibt es auch Strukturen, bei denen nicht alles auf einmal ins Web verlagert wird, sondern nur die Teile, die eine Windows-App wirklich benötigen, erhalten bleiben, während Datenverwaltung und -ansicht auf die Web-Seite verlagert werden.

Ablauf der Auftragsentwicklung

Windows-App-Outsourcing und Auftragsentwicklung lassen sich sicher wie folgt durchführen.

1. Bestandsaufnahme

Zunächst werden die betroffenen Geschäftsprozesse, die Nutzungsumgebung, bestehende Apps, externe Ausrüstung, die Bereitstellungsmethode und die auftretenden Probleme geklärt.

Ist eine bestehende App vorhanden, werden Quellcode, Build-Umgebung, Konfigurationsdateien, Protokolle, Installationsprogramm und zugehörige Unterlagen geprüft.

2. Design der Beobachtungspunkte

Bei Fehlern oder Instabilität wird zunächst die Ursache nachvollziehbar gemacht, bevor sofort korrigiert wird:

• Protokollierung hinzufügen
• Absturz-Dumps erfassen
• Kommunikationsprotokolle erhalten
• Speicher- und Handle-Anzahl aufzeichnen
• Bedienungsverlauf erhalten
• Screenshots und Zustand im Fehlerfall speichern

Je schwerer ein Problem zu reproduzieren ist, desto mehr zahlt sich das Design der Beobachtungspunkte aus.

3. Strategieentscheidung

Nach Betrachtung des aktuellen Zustands wird die Strategie festgelegt: Überarbeitung, Lebensdauerverlängerung, stufenweise Migration, vollständiger Ersatz oder nur Fehleranalyse.

In dieser Phase werden auch Technologiewahl, Bereitstellungsmethode, Update-Methode und Wartungsumfang festgelegt.

4. Implementierung und Test

Bei der Implementierung werden Bildschirme, Geschäftslogik, Anbindung externer Geräte, Dateiintegration, Fehlerbehandlung, Protokollierung, Konfiguration und Bereitstellung getrennt entwickelt.

Beim Testen werden nicht nur die Normalfälle, sondern auch die Fehlerfälle geprüft:

• Das Gerät ist nicht verbunden
• Die Kommunikation bricht mittendrin ab
• Eine Datei ist gesperrt
• Berechtigungen fehlen
• Das Netzwerk ist instabil
• Die Konfiguration ist beschädigt
• Ein Update schlägt fehl
• Die App wird abnormal beendet

5. Bereitstellung und Migration

Nach Fertigstellung werden Bereitstellungsverfahren, Update-Verfahren, Rückrollverfahren, Erstkonfiguration und Erläuterungen für Anwender vorbereitet.

Bei einer Migration von einer bestehenden App werden Parallelbetrieb von Alt und Neu, Rückfallszenario, Datenmigration und Anwenderschulung in die Planung einbezogen.

6. Wartung und Verbesserung

Nach der Lieferung wird die App unter Beobachtung von Protokollen und Anfragen an den Betrieb angepasst und verbessert.

Windows-Apps werden von Betriebssystem-Updates, PC-Wechseln, Änderungen an der Peripherie und Änderungen der Sicherheitsrichtlinie beeinflusst. Deshalb sind ein auf Wartung ausgelegtes Design und eine entsprechende Dokumentation unverzichtbar.

Informationen, die Sie vor einem Angebot bereithalten sollten

Zum Zeitpunkt der Anfrage muss noch nicht alles vorliegen. Die folgenden Informationen beschleunigen jedoch das Gespräch:

• Der Zweck der App
• Was derzeit Probleme bereitet
• Anzahl der Benutzer und Maschinen
• Windows-Versionen
• Ob eine bestehende App vorhanden ist
• Ob Quellcode vorhanden ist
• Entwicklungssprache und Framework
• Angebundene Geräte, Datenbanken, Dateien, APIs
• Fehlerbildschirme und Protokolle
• Reproduktionsschritte
• Gewünschter Liefertermin
• Geschäftsprozesse, die unbedingt nicht stillstehen dürfen
• Interne oder externe Verteilung
• Ob auch Wartung benötigt wird

Es ist kein Problem, wenn manche Punkte unbekannt sind. Zu klären, was bekannt ist und was nicht, ist selbst die erste Aufgabe der Auftragsentwicklung.

Zusammenfassung

Bei der Beauftragung von Windows-App-Outsourcing oder Auftragsentwicklung wird der benötigte Umfang schwer erkennbar, wenn Sie nur sagen: „Bitte bauen Sie uns eine App.”

Diese 7 Punkte sollten Sie vor der Beauftragung klären:

• Neuentwicklung, Überarbeitung bestehender Software oder Ersatz?
• Welche Geschäftsprozesse dürfen nicht stillstehen?
• Gibt es bestehende Ressourcen, externe Ausrüstung, DLLs, COM oder ActiveX?
• Technologiewahl: WinForms, WPF, WinUI, .NET-Migration und Ähnliches
• Wie werden Bereitstellung, Signierung, automatische Updates und Administratorrechte gehandhabt?
• Untersuchungsdesign für Protokolle, Absturz-Dumps, Speicher und Kommunikation
• Wie wird die App nach der Lieferung in einem wartbaren Zustand hinterlassen?

Windows-Apps sind eng mit den Geschäftsprozessen vor Ort, Ausrüstung, Dateien, Peripheriegeräten und den Einschränkungen des Windows-Betriebssystems verbunden. Genau deshalb ist es beim Outsourcing und der Auftragsentwicklung unerlässlich, nicht nur „zu bauen”, sondern auch „zu untersuchen”, „zu reparieren”, „zu dokumentieren”, „zu verteilen” und „zu betreiben” mit ins Design einzubeziehen.

Wenn Sie mit Windows-App-Outsourcing oder Auftragsentwicklung, Neuentwicklung, Überarbeitung und Wartung bestehender Software, Geräteintegration, Fehleranalyse oder Bereitstellungs-/Update-Design zu kämpfen haben, sprechen Sie uns an – beginnen Sie damit, Ihre aktuelle Situation zu klären.

Windows-App-Entwicklung anfragen

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Können wir Sie auch ohne Quellcode konsultieren?

Ja, das ist möglich. Ohne Quellcode ist der Handlungsspielraum jedoch eingeschränkt. In manchen Fällen lässt sich anhand von Konfiguration, Umgebung, Protokollen, externen Abhängigkeiten, ausführbaren Dateien, Installationsprogrammen und Kommunikationsdaten dennoch etwas untersuchen. Für Funktionserweiterungen oder grundlegende Korrekturen wird jedoch meist Quellcode benötigt, weshalb es realistisch ist, zunächst mit einer Bestandsaufnahme zu beginnen.

Können wir Sie auch bei Anwendungen mit altem VB6-, VBA-, COM- oder ActiveX-Code konsultieren?

Ja, das ist möglich. In diesem Bereich ist es wichtig, nicht alles auf einmal zu ersetzen, sondern zwischen dem, was erhalten bleibt, was eingekapselt wird und was ersetzt wird, zu unterscheiden. Insbesondere Ressourcen, die im laufenden Betrieb noch funktionieren, sollten risikobewusst schrittweise migriert werden.

Sollten wir unsere Windows-App durch eine Webanwendung ersetzen?

Das hängt vom Ziel ab. Webanwendungen eignen sich für mehrere Standorte, eine vereinfachte Geräteverwaltung und die Nutzung im Browser. Wenn hingegen Geräteintegration, lokale Dateiverarbeitung, Offline-Betrieb oder bestehende DLLs im Spiel sind, ist es oft naheliegender, die Windows-App beizubehalten. Statt alles ins Web zu verlagern, ist es auch eine Option, die Verantwortlichkeiten zwischen der Windows- und der Webseite aufzuteilen.

Können wir Sie nur mit einer Fehleranalyse beauftragen?

Ja, das ist möglich. Bei Abstürzen nach langer Laufzeit, Kommunikationsaussetzern, wachsendem Speicherverbrauch oder Fehlern, die nur auf bestimmten PCs auftreten, ist es wichtig, zunächst die Ursache nachvollziehbar zu machen, statt vorschnell Änderungen vorzunehmen. Wir bereiten Protokolle und Dumps auf, grenzen die Reproduktionsbedingungen ein und legen dann die Korrekturstrategie fest.

Können Sie auch Apps erstellen, die Administratorrechte benötigen?

Das können wir, aber ein Design, das dauerhaft mit Administratorrechten läuft, sollte sorgfältig überdacht werden. Es ist sicherer, den alltäglichen Teil mit Standardbenutzerrechten auszuführen und nur die notwendigen Vorgänge zu isolieren. Für Installation, Dienstregistrierung, Schreibzugriffe auf geschützte Bereiche, Treiber und Einstellungen für alle Benutzer klären wir zunächst das Berechtigungsdesign.

Können Sie auch kleine interne Windows-Apps in Auftrag entwickeln?

Ja. Auch bei kleinen Apps lohnt es sich, im Voraus an Bereitstellung, Updates, Protokollierung, Konfiguration, Backups und die Übergabe an neue Verantwortliche zu denken, damit sie langfristig einfach nutzbar bleiben. Insbesondere kleine Verbesserungen wie die Automatisierung von Excel-Arbeiten, CSV-Konvertierung, Dateiüberwachung, Berichtsausgabe oder das Sammeln von Gerätedaten eignen sich oft gut für Windows-Apps.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.