Outsourcing e sviluppo su commissione di app Windows: cosa chiarire prima di affidare l'incarico

Quando si valuta l’outsourcing o lo sviluppo su commissione di un’applicazione Windows, la prima decisione da prendere non riguarda solo “con quale tecnologia costruirla”.

Nella pratica, riceviamo frequentemente richieste come queste:

• Vogliamo revisionare un vecchio software Windows
• Non riusciamo a prendere in carico un’app interna creata da un predecessore
• La comunicazione con un dispositivo o uno strumento di misura si interrompe occasionalmente
• Sono coinvolti 32 bit / 64 bit, COM / ActiveX e integrazione VBA
• Dopo il passaggio a Windows 11 o a un nuovo PC non funziona più
• Vogliamo chiarire tutto, inclusi distribuzione, firma del codice, aggiornamenti automatici e avvisi SmartScreen
• Vogliamo far indagare crash o crescita della memoria dopo un lungo funzionamento

In altre parole, l’outsourcing e lo sviluppo su commissione di un’app Windows non significano solo “costruire nuove schermate”. Va considerato come un lavoro che comprende l’analisi degli asset esistenti, la revisione, la sostituzione, l’integrazione con dispositivi, la distribuzione, la manutenzione e l’analisi dei guasti.

Questo articolo riassume, dal punto di vista del committente, i punti da chiarire prima di affidare in outsourcing o su commissione lo sviluppo di un’app Windows.

Le aree più spesso affidate agli sviluppatori su commissione di app Windows

1. Sviluppo di una nuova applicazione aziendale

Si tratta dei casi in cui schermate di inserimento, schermate di ricerca, output di report, integrazione CSV, integrazione di file e integrazione con sistemi esterni a supporto delle operazioni interne vengono realizzati come applicazione Windows.

I motivi per scegliere un’app Windows anziché un’applicazione web sono in genere questi:

• Serve una gestione dettagliata di file e cartelle sul PC locale
• Si vuole integrare dispositivi USB, strumenti di misura, PLC o telecamere
• Serve utilizzarla in ambienti offline o reti chiuse
• Si vogliono sfruttare asset Excel, VBA, COM e DLL esistenti
• Servono tastiera, lettore di codici a barre o touch panel sui terminali di reparto
• Serve monitoraggio residente o elaborazione in background

Anche per un nuovo sviluppo, decidere fin dall’inizio se debba essere un’app Windows, se un’applicazione web sia sufficiente, o se solo una parte debba rimanere lato Windows, riduce i ripensamenti successivi.

2. Revisione e manutenzione di software Windows esistente

Nelle richieste di outsourcing e sviluppo su commissione, la revisione e la manutenzione di software esistente sono più frequenti di uno sviluppo completamente nuovo.

Per esempio, situazioni come queste:

• Il codice sorgente esiste, ma nessuno sa come compilarlo
• Si apre solo con una vecchia versione di Visual Studio
• È rimasto fermo a VB6, MFC, WinForms o .NET Framework
• Il responsabile ha lasciato l’azienda e nessuno conosce le specifiche
• Il funzionamento è diventato instabile dopo aggiornamenti Windows o un cambio di PC
• Partner commerciali o il reparto operativo richiedono nuove funzionalità

In questi casi, invece di ricostruire subito, si parte da un censimento dello stato attuale:

• Quale attività supporta l’applicazione?
• Quali funzionalità sono indispensabili?
• In quale ambiente funziona?
• Da quali dispositivi esterni, DLL, database e cartelle condivise dipende?
• Restano log e informazioni sugli errori?
• Restano codice sorgente, istruzioni di build, programma di installazione e file di configurazione?

Il fatto stesso che un software esistente sia in funzione rappresenta un valore. Per questo, nello sviluppo su commissione, invece di limitarsi a “buttare via tutto e ricostruire”, diventa importante un approccio graduale: mantenere, incapsulare o sostituire.

Se sono coinvolti COM / ActiveX / OCX, chiarite prima la terminologia con Una spiegazione approfondita delle differenze tra COM, ActiveX e OCX, e considerate la strategia di migrazione con prospettive come la Tabella decisionale mantenere / incapsulare / sostituire per ActiveX/OCX, per procedere più facilmente.

3. App di integrazione con dispositivi e apparecchiature esterne

Nel settore manifatturiero, nell’ispezione, nella misurazione, in ambito medicale correlato e nella ricerca, le applicazioni Windows sono spesso collegate ad apparecchiature esterne.

Gli obiettivi di integrazione tipici sono:

• Dispositivi di comunicazione seriale
• Dispositivi USB
• Telecamere industriali
• PLC
• Strumenti di misura
• Lettori di codici a barre
• Cartelle condivise e NAS
• DLL native esistenti
• SDK forniti dal produttore

In quest’area non basta costruire le schermate: bisogna anche progettare come si interrompe la comunicazione, la riconnessione, i timeout, il logging, la conservazione dei dati grezzi e la visualizzazione dello stato.

La comunicazione seriale in particolare tende a generare problemi su unità di ricezione, timeout, riconnessione e blocco dell’interfaccia, quindi è prudente considerare fin dall’inizio prospettive come Le insidie dello sviluppo di app con comunicazione seriale.

Inoltre, a volte lo stato di un dispositivo esterno non è sufficientemente descritto solo da “connesso” o “non connesso”. Distinguere presenza del dispositivo, reattività, prontezza delle funzionalità, freschezza dei dati e coerenza della configurazione produce una schermata più difficile da fraintendere sul campo. Per approfondire, vedere Progettare la visualizzazione dello stato dei dispositivi esterni.

4. Analisi dei bug e ricerca delle cause

Nello sviluppo su commissione di app Windows, a volte è necessaria un’analisi dei bug prima ancora di lavorare su nuove funzionalità.

Ecco richieste frequenti:

• L’app va in crash solo poche volte al giorno
• La memoria continua a crescere dopo un lungo funzionamento
• Non funziona solo su un PC specifico
• La comunicazione con un dispositivo si interrompe per alcuni secondi
• Nell’integrazione dei file si perdono dei dati
• Nessuno conosce i passaggi per riprodurre il problema
• I log sono troppo scarsi per risalire alla causa

Problemi di questo tipo non si risolvono limitandosi a guardare il codice. Prima si progettano i punti di osservazione, poi si raccolgono log, dump di crash, log di comunicazione, log degli eventi, utilizzo della memoria, numero di handle e così via.

Per l’analisi dei crash, la chiave è come conservare le prove nel momento stesso del crash, come descritto in Come registrare i log al crash di un’app Windows e Introduzione alla raccolta di dump di crash (WER/ProcDump/WinDbg).

Per la memoria in crescita, bisogna distinguere se si tratta di una semplice attesa del GC o di una vera perdita di memoria. Per le applicazioni .NET, si segue la procedura osservare-confrontare-dimostrare descritta in Distinguere l’attesa del GC da una perdita di memoria in .NET.

5. Distribuzione, firma e aggiornamenti automatici

Un’app Windows, una volta completata, spesso incontra ostacoli sul “come distribuirla”.

• Si crea un programma di installazione?
• Oppure basta depositare i file perché funzionino?
• Gli utenti standard possono installarla?
• Servono privilegi di amministratore?
• Si distribuisce tramite condivisione file interna?
• Gli utenti la scaricano dal web?
• Servono aggiornamenti automatici?
• Come si gestisce il certificato di firma del codice?
• Come si spiegano e si affrontano gli avvisi SmartScreen?

Le modalità di distribuzione includono MSI, MSIX, ClickOnce, xcopy e updater personalizzati. La scelta non dovrebbe basarsi su “quale sia più semplice”, ma su cosa si registra nel sistema operativo e chi si assume la responsabilità degli aggiornamenti. Per approfondire, vedere la Guida alla scelta del metodo di distribuzione per app Windows.

Per un’app Windows .NET a uso interno che si vuole distribuire a utenti standard con aggiornamenti automatici leggeri, vedere Introduzione a ClickOnce: distribuzione, aggiornamenti e criteri di scelta.

D’altra parte, la distribuzione via web o verso l’esterno comporta problemi di avvisi SmartScreen e firma del codice. Il motivo per cui compare il messaggio “Windows ha protetto il tuo PC” è riassunto in Perché Windows mostra “Windows ha protetto il tuo PC”.

Cinque cose da chiarire prima di affidare in outsourcing o su commissione un’app Windows

1. Cosa non deve fermarsi

La prima cosa da chiarire non è un elenco di funzionalità, ma “le attività che, se si fermano, creano problemi”.

• Si ferma l’elaborazione degli ordini
• Si ferma la linea di ispezione
• Non si possono produrre report
• Si interrompe la comunicazione con il dispositivo
• Il personale sul campo torna al lavoro manuale
• Audit e tracce non vengono conservati

Nello sviluppo su commissione, la progettazione non riguarda solo la costruzione di schermate e funzionalità, ma si estende a garantire che l’attività non si fermi. Una volta chiare queste priorità, diventa molto più facile decidere quali funzionalità costruire, quali rimandare e quali bug indagare per primi.

2. L’app attuale e l’ambiente circostante

Nella revisione e manutenzione di un’app esistente si verifica non solo l’app in sé, ma anche l’ambiente circostante.

Le informazioni utili da chiarire sono le seguenti:

• Nome dell’app, scopo e reparti che la utilizzano
• Numero di utenti e numero di postazioni
• Versioni di Windows
• 32 bit / 64 bit
• Versioni di .NET Framework / .NET
• Versione di Visual Studio
• Database, cartelle condivise, API esterne
• Dispositivi, DLL, SDK integrati
• Procedura di installazione
• Posizione dei file di configurazione
• Posizione dei log
• Presenza o meno del codice sorgente
• Presenza o meno delle istruzioni di build
• Presenza o meno di documentazione lasciata dal predecessore

Più queste informazioni sono disponibili, più preventivi e analisi guadagnano precisione. Al contrario, se le informazioni sono insufficienti, è più prudente ritagliare la prima fase come “analisi dello stato attuale” a sé stante.

3. Nuovo sviluppo, revisione o sostituzione?

Nelle richieste su app Windows, spesso è meglio non decidere fin da subito di “ricostruire da zero”.

Se continuare a usare un’app .NET Framework o migrare a .NET dipende dal tipo di app, dalle librerie dipendenti, dall’integrazione COM e dal metodo di distribuzione. Fare prima un censimento dei punti di verifica, come nella Checklist pre-migrazione da .NET Framework a .NET, facilita molto la decisione.

4. Distribuzione, aggiornamenti e privilegi

Per le app Windows, a volte l’ostacolo non è lo sviluppo ma la distribuzione.

I punti da verificare in particolare sono questi:

• Sarà usata da utenti standard?
• Ci sono operazioni che richiedono privilegi di amministratore?
• Installazione per tutti gli utenti o basta per singolo utente?
• Solo uso interno o anche distribuzione esterna?
• Servono aggiornamenti automatici?
• Ci sono postazioni offline?
• È richiesta la firma del codice?
• Serve tenere conto di Microsoft Defender SmartScreen?
• Esistono criteri di gestione come Intune, GPO o App Control?

Separare le operazioni che richiedono privilegi di amministratore da quelle che non li richiedono migliora sia la sicurezza sia la gestibilità nell’uso quotidiano. Il confine dei privilegi può essere verificato con prospettive come Quando i privilegi di amministratore Windows sono necessari e quando non lo sono.

5. Facilità di manutenzione

Ciò che conta nello sviluppo su commissione non è solo che l’app funzioni al momento della consegna. Si desidera che resti, anche dopo anni, in uno stato tale che un’altra persona responsabile possa analizzarla, revisionarla e ridistribuirla.

Le app Windows facili da mantenere presentano queste caratteristiche:

• Le istruzioni di build sono conservate
• Sono note le librerie dipendenti e le loro versioni
• Sono noti posizione e significato dei file di configurazione
• I log vengono emessi con una granularità utile per l’analisi
• Al crash restano tracce probatorie
• Esistono procedure di distribuzione e di rollback
• Le responsabilità nel codice sorgente sono ben separate
• Le operazioni che richiedono privilegi di amministratore sono limitate
• Le informazioni segrete non sono salvate in chiaro

Per la verifica di sicurezza minima prima del rilascio, controllate privilegi, firma, informazioni segrete, comunicazione, input, DLL e logging, come nella Checklist di sicurezza per app Windows.

Se password o token vengono salvati nei file di configurazione, occorre evitare l’archiviazione in chiaro e progettare la protezione usando i meccanismi di Windows. Per approfondire, vedere Come conservare in sicurezza le informazioni riservate nei file di configurazione.

Decisioni tecnologiche comuni per le app Windows

Scegliere tra WinForms, WPF e WinUI

Per lo sviluppo di una nuova app Windows, quale usare tra WinForms, WPF e WinUI è una questione ricorrente.

A grandi linee, il confronto è questo:

Tuttavia, la tecnologia più recente non è sempre la risposta giusta. La scelta deve tenere conto dell’esperienza del team esistente, dell’orizzonte di manutenzione, del metodo di distribuzione, dei requisiti delle schermate e delle librerie correlate.

Per approfondire, vedere la tabella decisionale nella Guida alla scelta tra WinForms/WPF/WinUI.

C# / .NET bastano, oppure servono C++ o DLL native?

La maggior parte delle app aziendali si può realizzare interamente in C# / .NET. Tuttavia, in casi come i seguenti si valutano talvolta C++, DLL native, P/Invoke, C++/CLI e COM:

• L’SDK del fornitore è pensato per C/C++
• Serve richiamare DLL esistenti
• C’è elaborazione di immagini ad alta velocità o controllo di dispositivi
• Serve usare asset COM esistenti
• Serve superare il confine tra 32 bit e 64 bit

In progetti di questo tipo, occorre chiarire non solo la facilità di realizzazione dell’interfaccia, ma anche i confini di processo, la proprietà della memoria, le eccezioni, il threading e la bitness.

App Windows o applicazione web?

Riceviamo anche richieste come “vogliamo trasformare in web una vecchia app Windows”. A volte il passaggio al web è la scelta giusta, ma non tutto deve necessariamente diventare web.

Le app Windows sono adatte, per esempio, in casi come questi:

• Connessione diretta a dispositivi o apparecchiature locali
• Uso offline
• Gestione di grandi file locali
• Uso di asset COM / DLL / VBA esistenti
• Necessità di operazioni rapide sui terminali di reparto
• Monitoraggio residente ed elaborazione in background

D’altra parte, se più sedi devono consultare gli stessi dati, se si vuole un uso solo tramite browser, o se si vuole ridurre la gestione dei dispositivi, un approccio web o cloud può essere più adatto.

Nella pratica, invece di spostare tutto sul web in una volta sola, esistono anche architetture che mantengono solo le parti che richiedono davvero un’app Windows, spostando sul lato web la gestione e la consultazione dei dati.

Come procede lo sviluppo su commissione

L’outsourcing e lo sviluppo su commissione di un’app Windows procedono in sicurezza in questo modo.

1. Comprensione dello stato attuale

Innanzitutto si chiariscono l’attività target, l’ambiente d’uso, l’app esistente, le apparecchiature esterne, il metodo di distribuzione e i sintomi problematici.

Se esiste un’app esistente, si verificano codice sorgente, ambiente di build, file di configurazione, log, programma di installazione e documentazione correlata.

2. Progettazione dei punti di osservazione

In presenza di bug o instabilità, prima di intervenire con correzioni immediate si rende tracciabile la causa:

• Aggiungere logging
• Catturare dump di crash
• Conservare i log di comunicazione
• Registrare memoria e numero di handle
• Conservare la cronologia delle operazioni
• Salvare screenshot e stato al momento dell’anomalia

Più un problema è difficile da riprodurre, più la progettazione dei punti di osservazione paga.

3. Decisione dell’approccio

Dopo aver osservato lo stato attuale, si decide l’approccio: revisione, prolungamento, migrazione graduale, sostituzione completa o solo analisi dei bug.

In questa fase si decidono anche la scelta tecnologica, il metodo di distribuzione, il metodo di aggiornamento e l’ambito di manutenzione.

4. Implementazione e test

Nell’implementazione si sviluppano separatamente schermate, logica di business, integrazione con dispositivi esterni, integrazione di file, gestione degli errori, logging, configurazione e distribuzione.

Nei test si verificano non solo gli scenari normali, ma anche quelli anomali:

• Il dispositivo non è connesso
• La comunicazione si interrompe a metà
• Un file è bloccato
• I privilegi sono insufficienti
• La rete è instabile
• La configurazione è danneggiata
• Un aggiornamento fallisce
• L’app termina in modo anomalo

5. Distribuzione e migrazione

Al termine, si preparano procedure di distribuzione, aggiornamento, rollback, configurazione iniziale e spiegazioni per gli utenti.

In caso di migrazione da un’app esistente, si include nel piano il funzionamento parallelo vecchio/nuovo, il ripristino, la migrazione dei dati e la formazione degli utenti.

6. Manutenzione e miglioramento

Dopo la consegna, si migliora l’app in base a log e richieste ricevute, adattandola all’operatività reale.

Le app Windows risentono di aggiornamenti del sistema operativo, sostituzioni di PC, cambi di periferiche e cambi di policy di sicurezza. Per questo, una progettazione e una documentazione orientate alla manutenzione sono indispensabili.

Informazioni utili da preparare prima di un preventivo

Al momento della consultazione non è necessario avere già tutto pronto. Tuttavia, avere le seguenti informazioni velocizza il confronto:

• Lo scopo dell’app
• Cosa crea problemi attualmente
• Numero di utenti e postazioni
• Versioni di Windows
• Presenza o meno di un’app esistente
• Presenza o meno del codice sorgente
• Linguaggio di sviluppo e framework
• Dispositivi, database, file, API integrati
• Schermate di errore e log
• Passaggi per riprodurre il problema
• Tempistica di consegna desiderata
• Attività che assolutamente non devono fermarsi
• Distribuzione interna o esterna
• Se serve anche la manutenzione

Non c’è alcun problema se alcuni punti restano sconosciuti. Chiarire cosa si sa e cosa non si sa è di per sé il primo lavoro dello sviluppo su commissione.

Riepilogo

Quando si affida in outsourcing o su commissione lo sviluppo di un’app Windows, dire semplicemente “sviluppateci un’app” rende difficile capire l’ambito necessario.

Ecco i 7 punti da chiarire prima di affidare l’incarico:

• Nuovo sviluppo, revisione dell’esistente o sostituzione?
• Quali attività non devono fermarsi?
• Ci sono asset esistenti, apparecchiature esterne, DLL, COM o ActiveX?
• Scelta tecnologica: WinForms, WPF, WinUI, migrazione a .NET e simili
• Come gestire distribuzione, firma, aggiornamenti automatici e privilegi di amministratore?
• Progettazione dell’analisi per log, dump di crash, memoria e comunicazione
• Come lasciare l’app in uno stato manutenibile dopo la consegna?

Le app Windows sono strettamente legate alle attività sul campo, alle apparecchiature, ai file, alle periferiche e ai vincoli del sistema operativo Windows. Proprio per questo, nell’outsourcing e nello sviluppo su commissione, è essenziale progettare non solo per “costruire”, ma anche per “analizzare”, “correggere”, “documentare”, “distribuire” e “gestire”.

Se avete difficoltà legate all’outsourcing o allo sviluppo su commissione di app Windows, a nuovo sviluppo, revisione e manutenzione di software esistente, integrazione con dispositivi, analisi dei bug o progettazione di distribuzione e aggiornamenti, iniziate contattandoci per chiarire la vostra situazione attuale.

Contattaci per lo sviluppo di app Windows

Articoli correlati

Articoli recenti con gli stessi tag per approfondire argomenti vicini.

Argomenti correlati

Queste pagine collocano l’argomento in un contesto più ampio di servizi e decisioni.

Servizi collegati all’argomento

L’articolo è direttamente collegato ai servizi seguenti.

Domande frequenti

Domande che ricorrono nelle consulenze sull’argomento dell’articolo.

Possiamo consultarvi anche senza il codice sorgente?

Sì, è possibile. Tuttavia, senza codice sorgente ciò che possiamo fare è limitato. In alcuni casi è possibile indagare a partire da configurazione, ambiente, log, dipendenze esterne, eseguibili, programmi di installazione e contenuto delle comunicazioni. D'altra parte, l'aggiunta di funzionalità o correzioni sostanziali richiedono spesso il codice sorgente, quindi è realistico partire da un'analisi dello stato attuale.

Possiamo consultarvi anche per un'app che include vecchio VB6, VBA, COM o ActiveX?

Sì, è possibile. In quest'area, invece di sostituire tutto in una volta, è importante distinguere cosa mantenere, cosa incapsulare e cosa sostituire. In particolare, gli asset ancora operativi in produzione è più sicuro migrarli gradualmente, valutando i rischi passo dopo passo.

Dovremmo sostituire la nostra app Windows con un'applicazione web?

Dipende dall'obiettivo. Le applicazioni web sono adatte a più sedi, a una gestione semplificata dei dispositivi e all'uso tramite browser. D'altra parte, se sono presenti integrazione con dispositivi, elaborazione di file locali, funzionamento offline o utilizzo di DLL esistenti, mantenere un'app Windows può risultare più naturale. Invece di spostare tutto sul web, è un'opzione anche suddividere le responsabilità tra il lato Windows e il lato web.

Possiamo affidarvi solo un'analisi dei bug?

Sì, è possibile. Per crash dopo un lungo funzionamento, interruzioni di comunicazione, crescita della memoria o malfunzionamenti che si verificano solo su PC specifici, è importante prima rendere la causa rintracciabile, piuttosto che intervenire subito con modifiche. Organizziamo log e dump, restringiamo le condizioni di riproduzione e poi decidiamo la strategia di correzione.

Potete sviluppare anche app che richiedono privilegi di amministratore?

Sì, ma un design che esegue sempre con privilegi di amministratore va valutato con attenzione. È più sicuro eseguire la parte di uso quotidiano con un account utente standard e isolare solo le operazioni che richiedono l'elevazione. Per installazione, registrazione di servizi, scrittura in aree protette, driver e impostazioni per tutti gli utenti, chiariamo prima il design dei privilegi.

Potete sviluppare su commissione anche piccole app Windows a uso interno?

Sì. Anche per le app di piccole dimensioni, pensare in anticipo a distribuzione, aggiornamenti, log, configurazione, backup e passaggio di consegne tra responsabili le rende più facili da usare a lungo termine. In particolare, piccoli miglioramenti operativi come l'automazione di lavori Excel, la conversione CSV, il monitoraggio di file, l'output di report o la raccolta di dati da dispositivi si adattano spesso bene alle app Windows.

Profilo dell’autore

Pagina di presentazione dell’autore dell’articolo.

Go Komura

Rappresentante di KomuraSoft LLC

Specializzato nello sviluppo di software Windows, nella consulenza tecnica e nell’analisi dei malfunzionamenti, soprattutto nei progetti con sistemi esistenti e guasti difficili da riprodurre.