Valutazione della revisione completa del software di altri

3

Ho qualche difficoltà a valutare la revisione di un software: il software è stato pagato dal cliente anni fa, mai usato, e ora il cliente ha notato che non funziona come previsto.

Ora questo cliente mi ha chiesto di valutare il progetto (ho le fonti) e dovrei dare una stima del tempo per risolverlo e probabilmente un contratto di manutenzione.

Tuttavia, dopo aver analizzato il codice tutto il giorno, noto che la base del codice sorgente è pessima. Ecco le caratteristiche cruciali:

  • Un sacco di righe sorgente (140K +)
  • C ++ senza classi, tutti allocati staticamente, tutti gli esterni, tutti pubblici
  • Scarsi commenti, scarsa documentazione
  • Un sacco di avvertenze, contate più di 7K + volte. Gli avvisi si diffondono da mancata corrispondenza / non firmata a variabili alias , fino a variabili non inizializzate .
  • Gli strumenti di analisi statici hanno segnalato overflow del buffer, variabili non assegnate, operazioni di stringa sospette.
  • Lotto di multithreading e nessuna sezione critica.

Il codice verrà compilato, ma solo la versione "debug" è in grado di funzionare per un breve periodo. Sospetto che i buffer overflow funzionino a sufficienza.

Ho già incontrato un codice come questo, non sono sorpreso che non funzioni come previsto. Ora sto pensando a come affrontare questo compito nel modo più conveniente, e questo è quello che pensavo:

  • Correggi tutti gli avvisi del compilatore.
  • Correggi tutti gli avvisi di analisi statica
  • Garantisci l'accesso esclusivo ai dati condivisi su più thread
  • Abilita _HAS_ITERATOR_DEBUGGING per il debug di std::vector accessi (il vettore viene utilizzato molto). Ciò implica un aggiornamento a VS 2005, almeno.
  • Utilizza il debug degli heap CRT il più possibile, anche se ciò implica lo spostamento della maggior parte delle variabili globali da allocare nell'heap.
  • Ampio uso di asserzioni (insieme alla creazione di minidump per l'analisi post-morte)
  • Casi di test approfonditi per dimostrare / testare la solidità del software.

Vorrei preparare il test delle unità, ma dovrei rifattare i metodi con 2500+ linee e aggiungere abbastanza dolore da abbandonare.

Penso di avere un buon piano, o forse sono solo nella giusta direzione. Penso che mi manca una misurazione per valutare effettivamente il lavoro che potrei affrontare. qualche idea?

    
posta Luca 02.04.2013 - 21:46
fonte

3 risposte

4

Non c'è modo per noi di rispondere a questo, se non per dire che ti viene chiesto di eseguire qualcosa di impossibile e di correre il più lontano possibile!

Ok, è un po 'ingiusto, ma alcune cose non possono essere conosciute / stimate. L'unico modo in cui puoi dare una stima che abbia qualche possibilità di essere vagamente correlato alla verità è lavorare con il codice e comprenderlo. Stiamo parlando da settimane a mesi. Dubito che vieni pagato per questo sforzo di stima; sembra che stai offrendo per un lavoro. Quindi, la tua attività dipende da quello che ammonterà a un'ipotesi totale.

Direi alla persona che non può essere stimato senza settimane di lavoro. Il tuo flusso di lavoro generale sembra non male, quindi ti suggerisco di farlo per un mese, e al momento ti riorganizzi. Nota che non c'è alcuna promessa che tu possa avere una stima migliore sulla quantità di lavoro, anche questo è inconoscibile. Ad un certo punto diventerà chiaro se abbia più senso continuare a versare denaro in questo codice, o ricominciare da zero, o semplicemente abbandonare l'intera idea.

Detto questo, penso che il post su questo "codice morto" sia accurato al 100%. Non riesco a stimare quanto costerebbe trasformare iterativamente una casa mobile malconcia in una villa di 35 stanze, ma posso dirti che sarebbe più economico radere al suolo la cosa e ricominciare da capo. Non è necessario stimare l'entità di un afflusso di soldi.

    
risposta data 02.04.2013 - 23:25
fonte
9

Stai descrivendo un codice morto. Se non è stato utilizzato per anni, non ha mai funzionato, e le esigenze del cliente al momento in cui è stato scritto non sono le stesse delle esigenze del cliente oggi. Un codice rotto, non testato, non mantenibile non soddisferà mai le esigenze dei tuoi clienti e passerai attraverso più dolore e il tuo cliente attraverso spese molto maggiori (per non parlare del rischio di fallimento) cercando di recuperare qualcosa di utile dalla base di codice esistente piuttosto che ricominciare da capo , con un prodotto minimo vitale che il cliente può iniziare a utilizzare presto e fornendoti un feedback.

    
risposta data 02.04.2013 - 22:04
fonte
0

Prenditi il tempo necessario per creare un sistema come questo da zero e quindi moltiplicarlo per un fattore di dieci. Ciò potrebbe acquisire adeguatamente la complessità del caso medio anche se non valuta adeguatamente tutti i rischi.

Questo è un buon esempio che riesco a immaginare quando non per fare il Big Rewrite. Qualunque sia il vero livello di sforzo, è modo oltre ogni ragionevole soglia di fattibilità.

    
risposta data 02.04.2013 - 23:55
fonte

Leggi altre domande sui tag