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

ssubbarayan wrote:

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.

On Jul 31, 6:02 am, Hans-Bernhard Bröker <HBBroe...@t-online.de>
wrote:
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.

"Hans-Bernhard Bröker" <HBBroeker@t-online.de> wrote in message
news:f8n1bo$hft$00$1@news.t-online.com...
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.

--
Peter

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.

larwe <zwsdotcom@gmail.com> writes:
??? 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.

On Jul 31, 3:10 pm, moja...@mojaveg.lsan.mdsg-pacwest.com (Everett M.
Greene) wrote:

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.

On Tue, 31 Jul 2007 04:48:01 -0000, ssubbarayan <ssubba@gmail.com>
wrote:

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.

4. GET ALL REQUIREMENTS SIGNED OFF.

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

6. 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.