Estimation techniques used in embedded porting projects

Hi all, This is slightly an offtopic question though related to embedded projects:

We have to work on porting projects.We till now are not aware of a good effort estimation to arrive at for the porting project.I would like to know what techniques industry uses or you experts have followed while doing effort estimation for embedded software porting sort of project with RTOS and couple of tasks.The biggest difficulty we face is in conveying to the client the needed time based on perfect estimates.

Looking farward for your replys, Regards, s.subbarayan

Reply to
Loading thread data ...

My guess would be that there are no standard techniques for this, simply because the job of "porting" is so unspecified. The software part of it will range from a few hours or days to port a project from one CPU to a different one from the same family (and redesigned PCB to go with it), to what effectively amounts to a complete rewrite from scratch if you port to a different CPU, with different peripherals and a different RTOS.

There ain't no such thing as a perfect estimate.

Reply to
Hans-Bernhard Bröker

And given this to be true, most s/w engs called upon to answer such a vague question do what a project manager would do: take the LOC number for the original code, multiply by an arbitrary constant to get an estimated number of resource-hours for the job, then pad by 50% or more.

Reply to

Well, actually there is. It is called the 'retrospective' estimate. It is used by the poorer types of project managent systems. There is also a 'converging' estimation which has the advantage over the 'retrospective' one that it has a better lower bound midway through the project and converges to the same final estimate. The disadvantage is that it requires more work. The building trade use both these estimate to great affect.

Reply to
Peter Dickerson

On Jul 31, 6:49 am, "Peter Dickerson"

LOL. As I sit in the middle of a multimillion dollar office relocation project (delayed by two to seven years from the original date, depending on who you ask), looking at the contractors scurrying to and fro, wires dangling out of missing drop-ceiling tiles, sweat dripping down my face because it's 85 degrees Fahrenheit at my desk (contrast

35 degrees forty feet away) and squinting at my monitor because the glass wall lets in far too much light and the queen bee insisted we have low cell walls that don't block it, I have to wonder just how many building contractors you have dealt with!

I can count on the fingers of one ear the number of building projects I'm aware of - starting with the Pyramids - that were either on time or on budget.

Reply to

??? You're in the southern hemisphere?

You were there for the pyramids' construction? What were the time and cost estimates?

You can always make things look good if you can sell a generous time and cost estimate in the beginning. Give yourself twice the time and twice the cost estimate and you can regularly beat the estimate.

Reply to
Everett M. Greene

Not unless New York came adrift and nobody told me. My GPS claims I am still north of the equator.

Take a look at the history books - if they're anything like the ones I read in school, they're full of statements like "The tomb wasn't finished until 20 years after King XYZ died", or "he ran out of resources".

Can't agree with you. Projects always expand beyond the budgeted resources, even if they are padded by any arbitrary percentage. It is better to estimate accurately how long it SHOULD take, and establish a contingency fund to cover unexpected occurrences. Otherwise you'll still wind up over budget, but the budget will be artificially bigger.

Reply to

  1. define all the requirements. Everything. This means you need to know everything that the previous device does. IF you don't understand then you need to find out from the people who do.
  2. Once all requirements are specified, get them reviewed by: a. the people who use the device b. the people who install the device c. the people who maintain the device. d. any one else who has anything to do with the device.
  3. If step 2 brings up any issues, go back to step 1.


  2. Once past step 5, get some qualified experienced engineers to estimate on each requirement. And make sure they understand what the requirements mean,

  1. add contingency to each requirement.

If all this sounds like to much then the project is probably not worth a real estimate and a educated guess plus contingency should suffice. Furthermore, it looks like a lot, but step one and two can be cycled between emails whilst doing other things. Most of the time the people in step 2 will write the requirements for you, you will just need to consolidate/collaborate the various responses.

Over the years I have learnt the hard way. It is imperative that you work to a set of defined requirements that is signed off by the customer. Without this you will suffer from scope creep and it will cost you in the end.

In the end, it does not matter how good you are, some times you will stuff it up. Its a fact of life. But with good planning you can get pretty damn close most of the time.

For the flamers: I am not a manager or project manager. I have worked in hardware and firmware. I am now a software engineer. (I write code for cash) I work for a large global consultancy, one of the few that gets it right. I have seen estimation work successfully.

Reply to
The Real Andy

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.