Non credo che esista uno standard del genere, certamente non applicabile a tutto il mondo accademico. Per la tua tesi, suggerirei che potrebbe essere più utile parlare di software "aggiornato di recente" / "attualmente sviluppato", piuttosto che etichettare il resto come obsoleto.

"Deprecato" segnala che il creatore no consiglia di utilizzare il software. Non riesco a pensare a nessun esempio reale per un pacchetto software completo (cioè andare oltre la deprecazione di una parte di un'API), ma immagino che potrebbe accadere se si sa che il software produce cattivi risultati.

Il software potrebbe essere "obsoleto" se di fatto è stato sostituito da un'opzione migliore, ma certamente non solo perché è vecchio. Anche allora, la vecchia opzione potrebbe essere abbastanza buona. Visita un paio di laboratori sperimentali (affermati) nel campo delle scienze e probabilmente vedrai molte vecchie apparecchiature che eseguono ancora vecchi software. Cambiare tutto sarebbe solo inutile sovraccarico e non è garantito che aiuti. C'è quasi sempre un posto migliore per spendere i soldi che potresti avere ... Da un altro punto di vista, se consideri le implementazioni di algoritmi numerici e le librerie come strumenti, ce ne sono un certo numero che sono passati decenni senza aggiornamenti, ma sono ancora regolarmente importati e utilizzati nello sviluppo di nuovi software.

L'utilizzo più comune di "deprecato" è abbastanza diverso e non ha nulla a che fare con la data dell'ultimo aggiornamento. Significa che lo sviluppatore (o il gruppo) responsabile dell'intero sistema (ad esempio le librerie Java) ha deciso che in futuro la funzionalità potrebbe essere abbandonata o modificata in modo da non essere compatibile con le versioni precedenti. È una promessa sul possibile futuro, non una dichiarazione sul passato.

Un po 'correlata, un'organizzazione, solitamente di grandi dimensioni, può deprecare l' uso di un software, nel senso che consente ai dipendenti di continuare a utilizzarlo per progetti aziendali, ma lo farà non forniscono più supporto IT. Ma questa è una decisione aziendale individuale e potrebbe avvenire in qualsiasi momento.

Anche la tua idea "obsoleta" è difettosa. Non si tratta di quando è stato cambiato l'ultima volta, ma di quando è stato utilizzato l'ultima volta per lavori importanti. Il software può essere aggiornato regolarmente, ma se non interessa a nessuno, è effettivamente obsoleto.

Naturalmente, puoi ridurre il numero di strumenti che consideri adatti a te stesso. Ma molto probabilmente dovresti concentrarti sugli strumenti usati più comunemente, piuttosto che su quelli che non sono stati aggiornati per un po '. Dopo tutto, una versione stabile è apprezzata se è adatta allo scopo. Se lo spazio problematico non cambia, gli strumenti meno recenti potrebbero avere un vantaggio. Allo stesso modo uno strumento costruito in un linguaggio specifico del dominio potrebbe essere molto utile per gli utenti, quindi escluderlo arbitrariamente potrebbe essere un errore.

Quindi, solo due punti:

1) "imposti" 5 anni, che è giustificabile in quanto "ciò che si può sostenere è un limite ragionevole", è valido quanto qualsiasi altro assunto come te menzionare che non c'è altro studio con un punto di vista paragonabile.

2) potresti sostenere solo l'ammissione del software che è attualmente completamente supportato e che è in fase di aggiornamento. Sebbene il software più vecchio possa ancora essere utilizzato, hai un "limite" che il software è ancora in grado di essere sviluppato per cambiare man mano che avvengono gli sviluppi.

Se, come ho capito, stai semplicemente "tracciando una linea la sabbia "quindi chiarire i parametri dovrebbe essere sufficiente. Molti possono, e forse correttamente, sostenere che il software X & Y avrebbe potuto o dovuto essere incluso, ma per mantenere la tesi entro parametri ragionevoli di durata &, è necessario prendere alcune decisioni arbitrarie.

fortuna comunque.