1

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?

Improve this question
4
  • I might be off topic, but why not use an empirical prediction-by-generalization approach instead ? Migrate a small representative part of the package, measure and extrapolate. It seems to me there are too many holes in your COCOMO equation to produce anything more than guesstimates here.
    – guillaume31
    Feb 21, 2014 at 11:23
  • Unfortunately, the codebase is kind of hellish. It was worked on by a very small team (two or three electrical and mechanical engineers) who understand everything about it very well because they built it from the ground up. Unfortunately, that means that they also might have been somewhat lax when it came to maintainability. Multi-hundred line methods, multi-thousand line classes which do everything including the kitchen sink, integers passed around as magic numbers, reliance on globals... this thing pretty much has to go over in a few big chunks.
    – Synchrondyne
    Feb 21, 2014 at 11:59
  • @freyyr: all you wrote in your last comment are arguments for trying empirical predication, not against it.
    – Doc Brown
    Feb 21, 2014 at 12:55
  • Since it's mostly a syntactic migration involving no redesign or new features, i.e. migration of one line of code doesn't have repercussions on any other line, maybe you could take an arbitrarily sized portion of code (like a method), do the work and extrapolate from there. 30 man months seems huge indeed. I've always been suspicious of estimation methodologies that claim to produce accurate predictions for work that a team has never done before, but that might just be me.
    – guillaume31
    Feb 21, 2014 at 12:59

1 Answer 1

Reset to default
1

It seems like COCOMO II may be the appropriate tool. I'm not sure what tool you are using, but I've had good luck with the COCOMO Suite of Constructive Cost Models and Expert COCOMO II (currently / temporarily? offline) tools presented at the USC CSSE website. You may need to change the setting to COCOMO.

This tool takes inputs that you didn't mention - precedentedness, required reliability, process maturity, experience, capability, complexity, and more. You may also want to look at the phase breakdown of effort - since it's a translation effort, unless you are adding new functionality or are reverse engineering specifications, you already have most of the effort for Inception and Elaboration done going into this project.

I think that if you check the factors and remove effort for activities that are already done, you'll be at your order-of-magnitude.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.