Il modo migliore per stimare i costi relativi al porting del codice dalla lingua A alla lingua B?

Se l'obiettivo è semplicemente quello di riprodurre un'applicazione esattamente in una nuova lingua, ti suggerirei di parlare del tuo cliente. Il porting è una delle cose più pericolose che puoi fare perché tutte quelle stranezze che sono emerse perché implementate in Language A possono essere invocate dagli utenti finali, e improvvisamente devi ricrearle in Lingua B . Roba brutta Per non parlare del fatto che il porting è un costo completamente sprecato che non potranno mai sperare di recuperare.

Suggerirei di trattare il progetto come un altro e raccogliere i requisiti e stimare come se l'originale non esistesse. Probabilmente scoprirai che l'utente finale ha una nuova prospettiva sul prodotto da quando lo usa. Se hai intenzione di riscriverlo, potrebbe anche renderlo migliore.

Se hai già una base di codice Perl, conosci il conteggio delle righe di codice (LOC). Vedi se riesci a trovare un confronto di espressività tra Perl e Lingua B. Ecco uno per esempio.

Il linguaggio B è Java. Quindi la LOC stimata per la porta sarà circa quattro volte la LOC dell'originale (espressività 6 contro 1,5).

Quindi utilizza qualcosa come il software Construx Estimate in modalità LOC per stimare quanto tempo ci vorrà (e quante persone ci vorranno).

Questo ti darà le stime del costo e del tempo dello stadio di gioco, oltre a un'idea di quanto è probabile che superi il limite.

Se sei già esperto in Language B e hai eseguito diversi progetti misurati, puoi utilizzare il software Construx Estimate per calibrare il tuo team.

Joels più articolo popolare , "Le cose che non dovresti mai fare" lo dicono meglio: Lo hanno fatto facendo l'unico errore strategico peggiore che qualsiasi azienda di software possa fare:

They decided to rewrite the code from scratch.

Se riesci a riscriverlo, riscrivilo correttamente e non limitarti a portarlo:

• Quali parti del programma non vengono più utilizzate? Salta queste parti.
• Quali parti del programma sono più importanti? Porta queste prima.
• Un nuovo programma, il tempo di aggiornare la GUI e renderlo più facile da usare e più "sexy".
• Oh, l'enorme investimento nel tempo non è più utilizzato per aggiungere solo altre funzionalità al vecchio codice?

Mi ci vorrà molto tempo. Sarà meglio che ne valga la pena. Prova a prendere una sezione del codice e a portarla. Moltiplicare quanto tempo impiega il rapporto tra le righe di codice che hai portato e le linee totali di codice. Ti darà una cifra di palla da baseball, quella reale sarà più alta di molti più probabilmente.

In pratica stai scrivendo l'app da zero ma hai i requisiti specificati in un'altra lingua, non è banale.

Penso innanzitutto che dovresti davvero considerare se questa è una buona scelta. Quali sono i vantaggi dell'uso del linguaggio B invece del linguaggio A?

Penso che IBM abbia avuto un'indagine che diceva che i programmatori scrivono, in media, 100LOC all'ora. C'è ancora molto più sviluppo, ma la vecchia architettura è ancora in programma. Diciamo che il 50% scriverà il codice, altrimenti il programma è ancora pianificato, giusto? (Potrebbe essere così che tu abbia un programma strutturato e tu vuoi uno orientato agli oggetti e quello sarebbe un compito più grande).

Ma se si scrivesse 100LOC / ora, dividere la quantità di LOC corrente nel sistema e moltiplicarla per la vendita media di un programmatore e moltiplicarla per 2. Ciò potrebbe fornire una stima approssimativa. Non prendere i numeri che prendi molto sul serio. (ancora meglio, non prenderli sul serio). Quello che vuoi fare dipende dal modo in cui è possibile misurare molte cose, come ad esempio:

• La competenza dei programmatori nella nuova lingua
• Quanto bene documentato il vecchio progetto è
• Da quale lingua viene convertito e in cui viene convertito?

Dipende da quanto tempo hai a disposizione. Alcune opzioni:

• Non c'è più tempo, fallo e basta - Prendi il retro di un tovagliolo e vai ad esso. È come essere meno di quanto necessario per renderlo in primo luogo e più che semplicemente ridigitare il codice in una sintassi diversa.
• 1-3 giorni : cerca di capire quale rielaborazione dell'architettura potrebbe essere necessaria, prova a stimare. Calcola la quantità di logica che deve essere trasferita, individua una sorta di rapporto. Aggiungi un po 'di tempo extra per le attività legate alla sicurezza che ti daranno la speranza di aver aumentato la sicurezza nel processo. Aggiungi tempo per i test di integrazione in base alla complessità del lavoro e alla semplicità della tua architettura.
• 1 monthish - prova un po 'di stage in un'architettura di test e prova a eseguire il porting di qualcosa. Scopri quale frazione del codice hai portato e stimare ulteriormente. Probabilmente scoprirai anche alcune cose che erano totalmente impossibili nel nuovo linguaggio, e fornirà una base migliore del lavoro reale necessario per realizzare la transizione.

In un mondo ideale, proporrei al cliente che pagasse un'attività investigativa per coprire quel mese di lavoro per permetterti di prototipare solo quello che avresti fatto. Questo dà loro la possibilità di fermarsi e non andare avanti se il costo è troppo grande. E, sei ancora pagato per il lavoro che hai svolto.

C'è solo un modo per ottenere una stima decente per un'attività software. Assegna il personale disponibile a fare COMPLETAMENTE una parte piccola ma verificabile dell'attività e vedere quanto tempo impiega. Rompere il lavoro rimanente nel maggior numero possibile di casi d'uso e stimare lo stesso personale ogni iterazione rispetto al lavoro già svolto. Non chiedere loro di stimare il tempo, basta chiedere loro di dirti come si confronta con la prima iterazione. Questo ti darà la migliore stima possibile per il resto del progetto.