I'm a student currently on an internship. I've been asked to determine the feasibility of migrating an existing Windows-only C# software package to Mono.
I've already conducted an analysis to identify the native libraries that will need to be ported or replaced with managed code, and identified the Windows-only API calls for which equivalents on Linux/OS X will need to be found. From this, I've cultivated some (very rough) estimates on what percentage of each assembly will need to be rewritten.
I would now like to develop a time estimate for implementation of those changes. It appears people seem to like the COCOMO II for this type of task.
However, I'm having trouble deciding on numbers for the SLOC (source lines of code) input. I have used USC's Unified Code Count tool to determine the Logical Lines of Code (LLOC) in the project as a whole and in specific assemblies of interest.
Under one strategy, I estimate somewhere around 10% of the 165k LLOC project will need to be rewritten, and about 5% of the remainder will undergo significant modification. Using these numbers, COCOMO II gives me something like 30 man-months of effort. This seems high to me - is it actually? I don't think I have the experience to know for sure.
I'm wondering if I should apply a twiddle factor to the LLOC input - I know people do something like this for some languages when using LOC (eg: dividing Python LOC by a factor of 6). Should I do this with C#, and if so, what factor?
Finally, is using COCOMO-II even a reasonable method of doing this? All I want is an order-of-magnitude approximation. Fermi-scale inaccuracy is okay here. Is there a better way?