backfiring tables for CosmicFFP

[Phil Pulley]

I am currebntly investigating the possible use of CosmicFFP as a
sizing method for software estimation.
However, as the only in-house productivity data available is in the
much maligned 'lines of code' per man day form, I am wondering if any
backfiring tables exist from which I can estimate lines of code from
FFP CFSU's.

We are using Cocomo2 to create software effort/schedule estimates
which uses SLOC for sizing (optionally converted from IFPUG FP's via
backfiring tables).
Thus, in order to use this model, I somehow need to get an SLOC based
size estimate.

Any ideas?

TIA

Phil Pulley

[Mon]

Wow! this is ambition!
I don't believe you will be able to get loc backfiring for COSMIC-FFP just
yet, if ever. I can see your point - Cocomo2 has just about managed to
acknowledge IFPUG fpa, and has backfiring options for different languages in
that, but it doesn't give an accurate-e
Phil Pulley <phil.pulley@astrium.eads.net> wrote in message
news:9d352beb.0402060805.62591f0@posting.google.com... I am currebntly investigating the possible use of CosmicFFP as a sizing method for software estimation. However, as the only in-house productivity data available is in the much maligned 'lines of code' per man day form, I am wondering if any backfiring tables exist from which I can estimate lines of code from FFP CFSU's. We are using Cocomo2 to create software effort/schedule estimates which uses SLOC for sizing (optionally converted from IFPUG FP's via backfiring tables). Thus, in order to use this model, I somehow need to get an SLOC based size estimate. Any ideas? TIA Phil Pulley

[Mon]

Sorry Phil, the posting slipped off, before I finished.
COSMIC has slightly more depth to the measurement concepts than the other
methods, as you probably know, since it can assist you to measure the
functional size of software in different layers, e.g. op system, (not to be
confused with peer pieces of software that interact with each other, often
called 'layers' or 'tiers' as in n-tier architecture'). The Viewpoint
determines whether you measure the layers (developer - identify the layers
of software being built and measure each separately; User, take the view of
the end-user only (like IFPUG).
Tentatively, (very tentatively), I would suggest using the IFPUG sloc
backfiring figures, if the project is neither very large or very small, and
see if it is any use (but don't bet your shirt on it - even for IFPUG). I
would only do this if you are doing the User viewpoint, and I can hear every
purist shouting with horror, since backfiring gives very variable results,
but I know where you are coming from. It would be interesting to hear how
you get on.
MON
Phil Pulley <phil.pulley@astrium.eads.net> wrote in message
news:9d352beb.0402060805.62591f0@posting.google.com... I am currebntly investigating the possible use of CosmicFFP as a sizing method for software estimation. However, as the only in-house productivity data available is in the much maligned 'lines of code' per man day form, I am wondering if any backfiring tables exist from which I can estimate lines of code from FFP CFSU's. We are using Cocomo2 to create software effort/schedule estimates which uses SLOC for sizing (optionally converted from IFPUG FP's via backfiring tables). Thus, in order to use this model, I somehow need to get an SLOC based size estimate. Any ideas? TIA Phil Pulley

[Dan Ligett]

"Phil Pulley" <phil.pulley@astrium.eads.net> wrote in message
news:9d352beb.0402060805.62591f0@posting.google.com... I am currebntly investigating the possible use of CosmicFFP as a sizing method for software estimation. However, as the only in-house productivity data available is in the much maligned 'lines of code' per man day form, I am wondering if any backfiring tables exist from which I can estimate lines of code from FFP CFSU's.

If you have the source code in-house, you should be able to count the SLOC
(with a tool), then count the CosmicFFP, and divide to get a backfire ration
that is tuned to your environment, your coding standards, your toolset, and
your people. That's much better than taking a generic backfire table from
someone else.

That's the same advice I gave during a panel discussion at the last COCOMO
Meeting ;)
http://www.softstarsystems.com/FPPanel.ppt

Dan Ligett, Softstar Systems, (603) 672-0987

[Mon]

Dan Ligett <ligett@softstarsystems.com> wrote in message
news:c05kso$gh2$1@pyrite.mv.net... "Phil Pulley" <phil.pulley@astrium.eads.net> wrote in message news:9d352beb.0402060805.62591f0@posting.google.com... I am currebntly investigating the possible use of CosmicFFP as a sizing method for software estimation. However, as the only in-house productivity data available is in the much maligned 'lines of code' per man day form, I am wondering if any backfiring tables exist from which I can estimate lines of code from FFP CFSU's. If you have the source code in-house, you should be able to count the SLOC (with a tool), then count the CosmicFFP, and divide to get a backfire
ration that is tuned to your environment, your coding standards, your toolset,
and your people. That's much better than taking a generic backfire table from someone else. That's the same advice I gave during a panel discussion at the last COCOMO Meeting ;) http://www.softstarsystems.com/FPPanel.ppt Dan Ligett, Softstar Systems, (603) 672-0987
That makes a lot of sense. I thought from the original question that Phil
wanted an off-the-shelf figure, and wasn't prepared / hadn't the funding to
derive a value for his own projects. However, feeding it into Cocomo would
then only be done with the SLOC, I would have thought, since Cocomo only
recognises IFPUG FPA.
MON

[Dan Ligett]

That makes a lot of sense. I thought from the original question that Phil wanted an off-the-shelf figure, and wasn't prepared / hadn't the funding
to derive a value for his own projects. However, feeding it into Cocomo would then only be done with the SLOC, I would have thought, since Cocomo only recognises IFPUG FPA. MON

Our COCOMO II tool lets you specify a backfire ratio, and I'm pretty sure
the USC tool does as well, so if you're able to derive the ratio, then you
can feed the tools the FP counts, and let the tools calculate the SLOC. So,
if you have the data, you can depart from the IFPUG FP. Of course, the
arithmetic is the easy part of this process, so this nuance isn't too
important. The hardest part would be counting the FP.

Dan http://www.SoftstarSystems.com

[Phil Pulley]

"Dan Ligett" <ligett@softstarsystems.com> wrote in message news:<c08e23$pam$1@pyrite.mv.net>... That makes a lot of sense. I thought from the original question that Phil wanted an off-the-shelf figure, and wasn't prepared / hadn't the funding to derive a value for his own projects. However, feeding it into Cocomo would then only be done with the SLOC, I would have thought, since Cocomo only recognises IFPUG FPA. MON Our COCOMO II tool lets you specify a backfire ratio, and I'm pretty sure the USC tool does as well, so if you're able to derive the ratio, then you can feed the tools the FP counts, and let the tools calculate the SLOC. So, if you have the data, you can depart from the IFPUG FP. Of course, the arithmetic is the easy part of this process, so this nuance isn't too important. The hardest part would be counting the FP. Dan http://www.SoftstarSystems.com

Thanks for the input Mon & Dan

The USC tool does indeed allow the FP to SLOC conversion ratio to be
specified so Dan's approach would work with this tool (although, as he
points out, this is fairly trivial as the FP to SLOC conversion could
easily be done outside the tool & entered as SLOC)

Mon was correct in her assumption that I was looking for generic
backfiring tables as a starting point as we have no funding to conduct
a retrospective FFP analysis of a previous development. However I
appreciate that, as FFP is relatively new compared to IFPUG, I was
asking a lot!

Thanks again

Phil