Quanto tempo e sforzo dovrebbe un progetto spendere per la compatibilità a ritroso? [chiuso]

Question

Dato che ogni progetto software ha solo tante programmatore-ore dedicate ad esso, quanto vuoi spendere per fare in modo che il prodotto è compatibile con le versioni precedenti? In realtà ci sono diversi punti da considerare:

• Il dell'età del software influenzare la vostra decisione? Will si investe meno tempo in retrocompatibilità quando il programma è più recente?
• È la decisione basata esclusivamente sul numero di clienti con copie installate?
• si fa a fare uno sforzo attivo per la produzione di formati di codice e di file che supporta i cambiamenti futuri?
• Quando si sta sviluppando v1.0, cerchi di costruito per rendere più facile per v2.0 per essere compatibile con v1.0? (Lasciando i campi "riservati" è un esempio.)
• Come si fa a decidere che "No, non abbiamo intenzione di sostenere che più" sulle caratteristiche?

Answer 1

La base di clienti è la chiave nel determinare se o non si dovrebbe supportare grande problema di compatibilità all'indietro.

In sostanza, è necessario valutare che, come tutti gli altri requisiti non funzionali è necessario implementare, ed è necessario specificare con cura ciò che è incluso in un "a ritroso compatibilità" caratteristica :

• compatibilità API . Ciò significa che le versioni successive di una libreria di fornire la stessa API che le versioni precedenti fanno, in modo da programmi scritti contro la versione precedente sarà ancora in grado di compilare ed eseguire con la nuova versione. In aggiunta alle realtà lasciando le stesse funzioni in giro, questo implica anche che le funzioni tutti fanno la stessa cosa nella versione più recente, che hanno fatto in quelli più anziani
• Application Binary Interface, o ABI, la compatibilità . Ciò significa che la compatibilità è conservato a livello del codice oggetto binario prodotta quando si compila la libreria.
  Di solito c'è una certa sovrapposizione tra API e compatibilità ABI, ma ci sono differenze importanti. Per mantenere la compatibilità ABI, tutto quello che dovete fare è assicurarsi che il vostro programma esporta tutti gli stessi simboli.
  Ciò significa che tutte le stesse funzioni e gli oggetti a livello globale accessibili bisogno di essere lì, in modo che i programmi legati contro la versione precedente sarà ancora in grado di correre con la nuova versione.
  E 'possibile mantenere la compatibilità ABI rompendo compatibilità API . Nel codice C, lasciare i simboli nelle file C, ma rimuoverli dalle intestazioni pubbliche, in modo nuovo codice che tenta di accedere ai simboli non riuscirà a compilare, mentre il vecchio codice che gli utenti compilati con la versione precedente continuerà a funzionare
• Compatibilità protocollo client-server . Ciò significa che un client che utilizza la versione del protocollo di rete fornite nelle release precedenti continuerà a funzionare quando di fronte a un server più recente, e che i programmi client più recente continuerà a lavorare con un server più vecchio.
• Compatibilità formato dati . Le versioni più recenti del codice devono essere in grado di lavorare con i file di dati scritti da versioni più vecchie, e viceversa. Idealmente si dovrebbe anche essere in grado di costruire una certa compatibilità in avanti verso formati di dati. Se la vostra routine di gestione dei file possono ignorare e preservare i campi non riconosciuti, allora la nuova funzionalità può modificare formati di dati in modi che non si rompono le vecchie versioni. Questo è uno dei generi più critiche di compatibilità, semplicemente perché gli utenti diventano molto turbato quando si installa una nuova versione di un programma e improvvisamente non possono accedere ai loro vecchi dati.

Se si combinano i criteri precedenti (natura della compatibilità a ritroso) con la natura della vostra base di clienti, si può decidere che:

• Se i vostri clienti sono interni alla vostra azienda, il bisogno è più bassa, e 2,0 può rompere le funzioni significative.

• Se i vostri clienti sono esterni, un 2.0 potrebbe ancora rompere le cose, ma potrebbe essere necessario fornire guida migrazione

• Al limite, se i vostri clienti sono tutto il mondo, come ho già menzionate nelle questo SO domande su java , si può finire per fornire nuove funzionalità, senza mai deprecando quelli vecchi! O anche preservare BUGS i vecchi prodotti , perché le applicazioni del cliente dipende da quegli insetti !!

---

• Il dell'età del software influenzare la vostra decisione? Will si investe meno tempo in retrocompatibilità quando il programma èpiù recente?
  Credo che questo abbia a che fare con ciò che è già stato distribuito: un programma di recente dovrà fare i conti con meno esigenze di compatibilità a ritroso rispetto a quello che è di circa da 20 anni

.

• E 'la decisione basata esclusivamente sul numero di clienti con copie installate?
  Essa dovrebbe essere basata su un caso aziendale: (? A causa di tutte le nuove funzionalità luccicanti che porta) fa la migrazione - - se necessario, a causa di una mancanza di retrocompatibilità è in grado di essere "venduto" in modo efficace ai vostri clienti

• si fa a fare uno sforzo attivo per la produzione di formati di codice e di file che supporta i cambiamenti futuri?
  Cercando di prevedere "il cambiamento futuro" può essere molto controproducente e rapidamente borderline a YAGNI (you are not gonna need it):. Un buon set di strumenti di migrazione può essere molto più efficace

• Quando si sta sviluppando v1.0, cerchi di costruito per rendere più facile per v2.0 per essere compatibile con v1.0? (Lasciando i campi "riservati" è un esempio.)
  Per i applicazioni interne ho lavorato su, no. A Parallel Run è il nostro modo per garantire un "funzionale" compatibilità all'indietro. Ma questa non è una soluzione universale.

• Come si fa a decidere che "No, non abbiamo intenzione di sostenere che più" sulle caratteristiche?
  Ancora una volta, per interno applicazioni, il processo decisionale può essere molto diverso da un distribuito esternamente uno. Se una funzione non apporta alcun valore aggiunto per il business, un compito interno "coerenza" è impostato per controllare con ogni altra applicazione interna del costo della migrazione (vale a dire "non più utilizzare questa funzione"). Lo stesso compito è molto più difficile da fare con i clienti al di fuori dell'organizzazione.

Answer 2

Il più il sistema è utilizzato giorno per giorno, più si dovrebbe concentrarsi su di esso.

Il più il sistema è profondamente radicata nei processi core dei vostri clienti, più si dovrebbe concentrarsi su di esso.

Il più il vostro sistema ha concorrenti, più si dovrebbe concentrarsi su di esso.

Gli utenti più che utilizzano versioni più vecchie, più si dovrebbe concentrarsi su di esso.

Il buy-in più complesso e più profondo v'è per un cliente al sistema, in termini di come grande di un impatto il software ha sul proprio business, più si dovrebbe concentrarsi sulla compatibilità all'indietro.

Se non li può fare a lungo su nuove versioni attraverso prezzi interessanti, ecc, potrebbe essere opportuno prendere in considerazione il rischio di costringere tutti in su.

Come Vista o Office 2007. Quelli erano formidabile per aiutarmi ad Apple.

Answer 3

Il mio assumere la compatibilità del software:

1.) Se la sua un prodotto largamente utilizzato già da molti clienti, quindi vorrei fare in modo che la nuova versione di questo prodotto è ancora utilizzando lo stesso "codice base" (codice che realizza le funzionalità di base dell'applicazione in fase di sviluppo) . Le nuove caratteristiche dovrebbero essere considerati in questo codice di base o costruite in cima a questa base di codice con cambiamenti necessari in ambiente di esecuzione della presente domanda come possibile. Non si vuole fare i vostri utenti esistenti di eseguire molti cambiamenti nei loro impianti esistenti. Quindi è un trade-off tra il sostenere una nuova funzionalità e rinnovamento nel processo di installazione e utilizzo esistente per il cliente.

2.) In un nuovo prodotto, se possibile identificare tutte le caratteristiche possibili di tale applicazione proprio in principio prima ancora che v1.0 è fuori. Identificare che dispone di u stanno andando per la spedizione in v1.0. e quali sarebbero stati conservati per versioni successive. Ove possibile mantenere queste "caratteristiche momenti successivi" a mente durante la progettazione, implementazione del codice, di finalizzare l'uscita da / dell'applicazione per soddisfare le caratteristiche nelle versioni future. per esempio. Lascia elementi aggiuntivi / campi di bit nelle vostre strutture dati.

-AD.

Answer 4

Un sacco. Se non si vuole incazzare ogni uno dei vostri clienti fedeli!

Answer 5

La mia esperienza è con complessi sistemi termoretraibile con relativamente pochi (100 - 5000).
utenti Marketing ha spesso un atteggiamento Devo farlo sulla compatibilità all'indietro, senza un pieno apprezzamento dei costi del ciclo di vita. Ad esempio, i risparmi per mantenere bug nel sistema per la base di utenti corrente possono essere facilmente sminuito dai costi di supporto per i nuovi utenti oltre il ciclo di vita del sistema.