Sono uno studente attualmente in uno stage. Mi è stato chiesto di determinare la fattibilità della migrazione di un pacchetto software C # esistente solo per Windows su Mono.
Ho già condotto un'analisi per identificare le librerie native che dovranno essere portate o sostituite con codice gestito e identificato le chiamate API di sola Windows per le quali è necessario trovare equivalenti su Linux / OS X. Da questo, ho coltivato alcune stime (molto approssimative) su quale percentuale di ogni assemblaggio dovrà essere riscritta.
Vorrei ora sviluppare una stima del tempo per l'implementazione di tali cambiamenti. Sembra che alla gente piaccia il COCOMO II per questo tipo di attività.
Tuttavia, ho difficoltà a decidere i numeri per l'input SLOC (source line of code). Ho utilizzato lo strumento Unified Code Count di USC per determinare le Logical Lines of Code (LLOC) nel progetto nel suo insieme e in specifici gruppi di interesse.
Secondo una strategia, stimiamo che circa il 10% del progetto 165 LLOC dovrà essere riscritto, e circa il 5% del resto subirà modifiche significative. Usando questi numeri, COCOMO II mi dà qualcosa come 30 mesi-uomo di sforzi. Questo mi sembra alto - è vero? Non penso di avere l'esperienza per saperlo con certezza.
Mi chiedo se dovrei applicare un fattore di twiddle all'ingresso LLOC - So che le persone fanno qualcosa di simile in alcune lingue quando si usa LOC (ad es .: dividendo Python LOC di un fattore 6). Dovrei farlo con C #, e se sì, quale fattore?
Infine, sta usando COCOMO-II anche un metodo ragionevole per farlo? Tutto quello che voglio è un'approssimazione dell'ordine di grandezza. L'inaccuratezza su scala di Fermi è ok qui. C'è un modo migliore?