Qual è il concetto di usura del software?

Ciò a cui ci si riferisce probabilmente è entropia del software o software rot . Questi sono termini presi in prestito o analoghi a cose del mondo fisico, ma applicati al software.

L'idea è presa in prestito dalla termodinamica . Quando viene applicato al software, significa che quando si introducono modifiche in un sistema, il sistema ottiene solo disordine. Esistono tecniche che possono essere utilizzate per limitare la quantità di disturbo, come il refactoring, ma nel corso della sua vita, ci sarà un aumento netto del disturbo del sistema. La quantità di disturbo è spesso legata alla capacità di continuare a mantenere il sistema.

Il software rot è simile. Quando si modifica qualsiasi aspetto del sistema, dall'ambiente in cui viene eseguito ai requisiti sottostanti che hanno guidato la progettazione e l'implementazione, lo stato del sistema cambia in un modo che lo rende "peggiore". Potrebbe andare dalle differenze estetiche (una libreria UI sottostante viene aggiornata e il comportamento delle modifiche del sistema) a funzionale (le modifiche apportate all'architettura della CPU influenzano le caratteristiche di esecuzione del sistema, causando errori di sincronizzazione o sincronizzazione). Il software rot non richiede necessariamente modifiche al sistema software, ma solo nell'ambiente in cui viene distribuito il software.

Potrebbe significare che, più aggiungi funzionalità al tuo software, meno il suo design rimane pulito, elegante e ulteriormente estensibile, il che significa che a un certo punto devi riscriverlo / refactarlo in parti sostanziali di esso?

Nel corso del tempo ci sono molte cose che potrebbero accadere a un code base che potrebbero causarne il deterioramento.

• Più sviluppatori, di diversi set di abilità che modificano il codice base.
• Anche gli standard di codifica non vengono rispettati.
• I pattern di progettazione dell'architettura utilizzati vengono ignorati per ottenere correzioni rapide in

Questi potrebbero portare a ciò che si potrebbe chiamare usura del software.

È vero in senso stretto che il software in sé non si consuma. Ma tutto il resto sull'intero processo di distribuzione, configurazione e utilizzo del software passa attraverso modifiche che possono avere lo stesso effetto nell'impressione dell'utente. Ne hai già elencati alcuni. Altri includono:

• Configurazione: il software che ha funzionato bene durante l'esecuzione come un'installazione pristine può iniziare a comportarsi in modo imprevisto o mostrare difetti non visibili all'inizio quando gli utenti hanno terminato di modificare l'installazione nel modo desiderato. Basti pensare al registro di Windows: la più potente e potente compagnia di software al mondo non è in grado di diagnosticare in modo affidabile i problemi derivanti da troppe o conflittuali impostazioni di configurazione nel registro; la procedura operativa standard consiste nel dire al cliente di reinstallare il sistema operativo piuttosto che impiegare più di un tempo minimo per provare a risolverlo.
• Aspettative e abitudini degli utenti: usare lo stesso programma per un certo periodo di tempo abitua l'utente al modo in cui funziona. Ciò che inizialmente era nuovo ed eccitante diventa normale. Questo può funzionare per il prodotto, in quanto gli utenti imparano le stranezze di cose operative che inizialmente consideravano confuse, ma possono anche causare accumulati dubbi che alla fine culminano nell'odio.
• caricamento dei dati: più a lungo viene utilizzato un programma, maggiore è il numero di dati con cui solitamente deve essere gestito. Viste, rapporti e procedure che all'inizio erano accettabilmente veloci riducono spesso le prestazioni, maggiore è il numero di dati da gestire, fino a quando i tempi di esecuzione per le attività tipiche che una volta erano accettabili diventano insolitamente lunghi. Ancora una volta, tecnicamente questo espone semplicemente un difetto che era già presente nel software fin dall'inizio (e il test di carico corretto avrebbe dovuto farlo), ma l'impressione sugli utenti è di "usura": "È veramente lento ora!"

Molti fattori possono cospirare contro un programma che è considerato accettabile, buono o addirittura ottimo per erodere la sua reputazione e la sua capacità di svolgere la sua funzione.

• Quello era allora, questo è adesso. Ho visitato un museo a Chicago e ho visto il pannello di controllo in una capsula spaziale Apollo. A quel tempo, era lo stato dell'arte, la migliore tecnologia disponibile. Secondo i nostri standard oggi, si considererebbero fattori umani poveri, vecchi interruttori goffi piuttosto che un touch screen. Il suo computer era piccolo e lento. Le menti geniali l'hanno creato, con alcuni aspetti del loro design completamente originali e senza modelli precedenti da imitare.
• Coltello Bowie per coltellino svizzero. Quando è stato realizzato, aveva una funzione e lo faceva bene con grande facilità d'uso. Potrebbe essere arrivato in un solo colore (nero), ma è stato solido e ha sostituito un sistema manuale che richiede tempo che le persone ricordano ancora (e odiano). Nel corso del tempo, le nuove versioni hanno aggiunto funzionalità e opzioni complesse. La gente ha dimenticato quanto poco fosse stato fatto il sistema manuale e quanto fosse difficile da usare, ma sta diventando difficile da usare e non gli piace.
• L'integrità del design originale è compromessa. Se originariamente messo in campo, il design poteva essere basato su un design semplice e chiaro. Ad esempio, nel nome del miglioramento, il programma di migliaia di righe C che aveva una funzione per funzionalità è stato sostituito con un programma C ++ che è stato ricodificato, ma non rearchitected.
• Gli orfani possono essere presi a calci in giro. Gli autori originali e gli stakeholder originali avevano alcuni obiettivi relativi a funzionalità, ambito, ritorno sull'investimento, idoneità per uno scopo particolare e, probabilmente, il software era di alta priorità. Una volta in manutenzione, a volte il livello delle risorse, la quantità di attenzione, la chiarezza degli scopi e la proprietà e l'emancipazione delle parti interessate fluttuano. Le nuove persone sanno meno delle persone originali, non rispettano i loro contratti scritti o non scritti sul software, e possono apportare modifiche veloci e sporche o lente e costose, guadagnando rapidamente disapprovazione dal QA o dai gestori di risorse / progetti.
• La legge di Moore. Se il software è stato costruito ai limiti dell'hardware (ad esempio 640 KB di RAM e 10 MB di disco rigido), alcuni anni dopo può essere ricordato con nostalgia, ma è una reliquia.
• Nuovi paradigmi. I software per Pocket PC che non collegavano le app con altre app non potevano essere altrettanto versatili di un'app che alimenta i suoi intenti in una selezione di utenti tra diversi programmi (pensa la condivisione di foto su un telefono o tablet Android). Quel terminale basato sul testo con i menu selezionati digitando un numero e premendo enter non corrisponde a una pagina Web efficace, non solo di facile utilizzo, ma anche di inter-connettività, scalabilità e manutenibilità.
• I nuovi design competitivi brillano al confronto. Essere i primi può essere una strada difficile, e per parafrasare Newton che ha detto di stare sulle spalle dei giganti, può essere doloroso per il software se ha concorrenti in cima esso. Il software che smette di crescere e migliorare è come le persone che smettono di crescere e migliorare. La Honda Accord è stata una delle prime dieci aziende della rivista Car and Drivers per oltre venti anni, ma poche persone pagherebbero il nuovo prezzo della vettura per una copia nuova di zecca di un'auto ventenne (a parte forse un bug VW del costruttore brasiliano). Nel software, il problema è amplificato perché i prezzi guidano verso il basso per molti prodotti basati su software.