Il monitoraggio dell'utilizzo è esoterico o allo stato dell'arte? [chiuso]

Il monitoraggio dell'utilizzo è molto più popolare nelle applicazioni Web per una serie di motivi:

1. Le applicazioni Web condividono un lato client comune, per lo più fatto di tecnologie standard (HTML, CSS, Javascript). È molto più semplice creare strumenti di analisi, quando ciò che stai analizzando è praticamente standardizzato e pubblicamente disponibile.
2. La prototipazione evolutiva è un approccio abbastanza standard nello sviluppo web e il monitoraggio dell'utilizzo è particolarmente utile.
3. Il rallentamento delle funzionalità fa più male sulle applicazioni Web. Una funzionalità che richiede una libreria Javascript 40K danneggia l'esperienza di ogni utente ed è abbastanza importante sapere quanti utenti effettivamente la usano.

Detto questo, il monitoraggio dell'utilizzo è o dovrebbe essere importante per ogni applicazione, ma non è altrettanto facile da implementare o prezioso sulle applicazioni desktop. Un esempio di monitoraggio dell'utilizzo tradizionale è il TestPilot di Firefox

Tuttavia, ciò che è un po 'più interessante è un insieme emergente di tecnologie raggruppate nella buzzword Runtime Intelligence :

The term runtime intelligence (RI) refers to technologies, managed services and practices for the collection, integration, analysis, and presentation of application usage levels, patterns and practices. RI is a discipline within both business intelligence (BI) and software development lifecycle (SDLC) management that focuses on precision method-level monitoring within applications and macro-level monitoring across populations of applications, platforms and domains.

E l'esempio più rappresentativo che conosco è il monitoraggio delle applicazioni a livello di funzionalità di CE di Dotfuscator Software Services :

Beyond Obfuscation

Dotfuscator CE combines its trusted obfuscation technology with injection technology to provide near real-time views into application deployment, stability, and usage. In addition to obfuscation, Dotfuscator CE offers a new category of detective control to better monitor, manage, and protect your applications. Dotfuscator CE can:

• Provide a near real-time view into application integrity and activity at runtime.
• Instrument applications to detect if they have been tampered with and if so, optionally send a message to the Runtime Intelligence Service.
• Instrument applications with expiration, de-activation, and notification logic that reacts to application expiration by exiting the application and/or sending a Runtime Intelligence Services message.

In questo caso, il runtime funge da base comune, in modo simile al lato client comune delle applicazioni Web.

In ogni caso, il monitoraggio dell'utilizzo non sostituisce la specifica dei requisiti , il suo ruolo è complementare. Se mostra che stai sbagliando più volte di quanto tu stia facendo bene, allora il problema è più profondo ...

Vorrei aggiungere che l'applicazione sull'app per dispositivi mobili (non per le app Web mobili) è molto importante perché:

• Può essere d'aiuto avere una vista sul numero di istanze del tuo software in esecuzione

• ti dà visibilità su quale sistema operativo questi app sono in esecuzione. Questa è la chiave per sapere su quale versione del software del sistema operativo che si desidera mantenere è

• può aiutarti a capire il modello di utilizzo, il tasso di conversione, ecc ...

Molte di queste funzionalità sono disponibili solo da quando in ritardo (meno di 5 anni) grazie alla disponibilità di piani dati a prezzi accessibili e, naturalmente, alla distribuzione di iPhone, anche se era disponibile prima

Flurry fa un ottimo lavoro in quest'area

Non è uno stato dell'arte, poiché è raramente necessario:

Se hai sviluppato una certa funzionalità, perché dovresti rimuoverla, anche se è usata raramente? Forse i tuoi menu sono troppo grandi, rendendo difficile trovare le cose spesso usate? Ma poi hai molte opportunità, come abilitare alcune opzioni solo tramite un file di configurazione, lasciare che l'utente passi ad una modalità esperta, dove può mostrare alcune opzioni.

A volte, le opzioni potrebbero aumentare la complessità, quindi devi mantenere molte cose, e con 4 opzioni di tipo A e 3 opzioni di tipo B, termina in 3 * 4 funzioni da scrivere, mentre 3 * 3 o 3 * 2 funzioni sarebbero molto meno codice.

Ma devi essere consapevole che molte funzioni potrebbero essere usate raramente, ma possono comunque essere importanti. Forse hai 100 utenti, che usano tutte 90 funzioni. E ogni utente usa un'altra funzione, di cui è l'unico utente. Ma la rimozione di questa funzione potrebbe rendere inutile l'intero programma.

Se la tua preoccupazione non è tanto il costo di sviluppo, o l'esperienza dell'utente, ma la dimensione che il tuo programma occupa nella RAM, potresti usare plugin e inizializzazione pigra per ridurlo.

Se le parti grandi possono essere utilizzate indipendentemente dagli altri, puoi estrarre le parti usate raramente e fornire 2 o più programmi, ognuno più piccolo come combinazione di entrambi.

La registrazione può essere utilizzata per aiutare a tenere traccia dei problemi e interrogati come metodo per analizzare l'utilizzo delle funzionalità. Puoi raccogliere campioni e analizzarli nel tempo, ma non andrei tanto lontano quanto raccoglierli tutti da ogni installazione (a meno che tu non ne abbia molti).

Se ritieni che ci siano funzioni che nessuno vuole usare, inizia a lavorare sulla tua metodologia per raccogliere i requisiti degli utenti e determinare perché stai sprecando il tuo tempo aggiungendoli in primo luogo. Non sarai mai perfetto. Le esigenze cambiano nel tempo in molto dominio.

Assicurati di avere un dialogo aperto con i tuoi utenti. Imparerai molto.

Ricordo di aver lavorato in una società di software in cui un giovane dev era così orgoglioso del rapporto da lui creato (non parte delle specifiche) con un grafico a torta senza valore. Il proprietario la guardò e disse al giovane dev: "Torna al tuo computer e fai qualcosa che posso vendere".