Re: Function Points

2007-05-09 Thread David Bovill

I have not looked at Function Point Analysis before - but reading up on it
makes doesn't leave a good taste. Research shows that a huge percentage of
initial requirements (ie function points) never reach the final product -
from memory and the published research I read on this last year this was
well over 65% for projects of 5 months duration and over!

And perhaps more to the point:  Am I looking for a Holy Grail in trying

to find an objective measurement for projects which don't have any code
yet?



Sounds interesting Richard - would love to know more...  I have been looking
hard for this Holy Grail perhaps from a different perspective of games and
collaborative publishing.

For project management applications I'd think of going more in the direction
of as Chipp says agile development with an emphasis on light weight
documentation - and go for Unit Tests perhaps as any measure of project
complexity? I have used Unit Tests myself in Rev - but I don't think the
benefits that they have for other language type projects correspond

I think what I am trying to say is that the long term forward planing is all
but impossible and the real advantage of any form of project planning
documentation is with regard to a customer feedback cycle designed to keep
things on track? The biggest problem is trying to convince the customer that
forward planning does not work so well, and to pay for a development process
that they steer, rather than a hypothetical but detailed plan - Rev and
other Agile Tools have the advantage here in that results can be made
visible right from the word go.

The only form of quantifying I have found useful are Sprint Back Catalogues
- which basically keep a daily cumulative graph of time to completion to the
end of the next sprint cycle.

As a counter to all this Agile development nonsense I came across this ditty
a while back :)

Imagine (with apologies to John Lennon)

Imagine there's no requirements. It's easy if you try
Just a bunch of coders, reachin' for the sky
Imagine all the people, coding for today
Imagine there's no schedules. It isn't hard to do
No silly project deadlines, no one supervising you
Imagine all the people, coding hand in hand

You may say I'm an extremer but I'm not the only one
I hope someday you'll join us and make coding lots more fun.

Imagine oral documentation. I wonder if you can
No need for UML diagrams. Just words passed, man to man
Imagine just refactoring, playing in the sand

You may say I'm an extremer, but I'm not the only one
I hope someday you'll join us and make coding lots more fun.

Taken from Stephens, D. Rosenberg. Extreme Programming Refactored

But apart from saying I don't think it is possible - am I missing the point?
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Function Points

2007-05-09 Thread Richard Gaskin

Thanks for the input, Chipp and David.

I think David summed it up well here:

I have not looked at Function Point Analysis before - but reading up on it
makes doesn't leave a good taste.


For me this is more of a thought experiment than an immediate need, as I 
have a small number of multi-year projects to keep me busy enough to not 
need to worry about estimating new projects for a while.


But since most of my works spans multiple versions of products, I've 
been fleshing out some internal tools for code base analysis, with two 
goals in mind:  first, that they be usable enough to share with clients, 
and then if time permits that they become usable enough to share with 
the rest of the Rev community.


While I was working on tools for the development phase, my reading led 
me down the road of pre-development.   But my reading concurs with 
what's been discussed here:  there's just too much variance at the 
outset of a project to reliably quantify it through any semi-automated 
method.


I stumbled across this estimating tool at Construx.com, Steve 
McConnell's company:

http://construx.com/Page.aspx?nid=68

Haven't spent much time with it, but it looks like an interesting 
starting point for working in lower-level languages.


For the moment, I have enough to keep me busy writing bug-tracking and 
code base analysis tools that if there's no slam-dunk for automating 
parts of the estimating process I'll gladly leave well enough alone. :)


--
 Richard Gaskin
 Fourth World Media Corporation
 ___
 [EMAIL PROTECTED]   http://www.FourthWorld.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Function Points

2007-05-09 Thread David Bovill

Whats a slam-dunk?
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Function Points

2007-05-09 Thread David Bovill

More seriously

On 09/05/07, Richard Gaskin [EMAIL PROTECTED] wrote:


But since most of my works spans multiple versions of products, I've
been fleshing out some internal tools for code base analysis,



What sort of tools are you thinking of here Richard? I am asking because I
still have the code graphing tools hanging around waiting for a renewed
lease of I'm needed energy... they graph handler relationships, optionally
including which controls they are in... from memory you were looking at
profiling?
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Function Points

2007-05-09 Thread Richard Gaskin

David Bovill wrote:

Whats a slam-dunk?


It's an American colloquialism derived from basketball, referring to
scoring a solid point in one decisive move (slamming the ball through
the hoop).


What sort of tools are you thinking of here Richard? I am asking because I
still have the code graphing tools hanging around waiting for a renewed
lease of I'm needed energy... they graph handler relationships, optionally
including which controls they are in... from memory you were looking at
profiling?


It started out with an interest in cyclomatic complexity, tailoring
McCabe's algorithm to be more appropriate for Rev (for example, I weight
send...in time since it's one of the few ways you can introduce race
conditions into Rev code, and race conditions eat disproportionate time
when diagnosing bugs).

Then I added a few other metrics, including fan-in and fan-out, which 
led to the Fandango design pattern Ken and I talked about in our 
session last year at RevCon West.


Fan-in/Fan-out sound like overlaps of your dependency diagrams.  I've 
avoided the challenge of diagramming dependencies myself, as the ROI 
didn't match up for my needs.


But if you have dependency diagramming already in place, there may 
indeed be some way the two tools could be integrated.


The weak link to such an integration may be on my end:  while useful, 
they're of a lower priority than client work, so they get attention only 
in between phases with more important projects.  As a result, it's hard 
to say when it'll be in any form that others could use.


--
 Richard Gaskin
 Fourth World Media Corporation
 ___
 [EMAIL PROTECTED]   http://www.FourthWorld.com

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Function Points

2007-05-09 Thread David Bovill

On 09/05/07, Richard Gaskin [EMAIL PROTECTED] wrote:


It started out with an interest in cyclomatic complexity, tailoring
McCabe's algorithm to be more appropriate for Rev (for example, I weight
send...in time since it's one of the few ways you can introduce race
conditions into Rev code, and race conditions eat disproportionate time
when diagnosing bugs).



Looks fun - but I don't get the point yet why would you want to quantify
the code complexity - seems overkill for working out how much to pay
freelancers :)

Then I added a few other metrics, including fan-in and fan-out, which

led to the Fandango design pattern Ken and I talked about in our
session last year at RevCon West.

Fan-in/Fan-out sound like overlaps of your dependency diagrams.  I've
avoided the challenge of diagramming dependencies myself, as the ROI
didn't match up for my needs.

But if you have dependency diagramming already in place, there may
indeed be some way the two tools could be integrated.



Pretty sure that:* M* = *E* − *N* + *2 *where *M* = cyclomatic
complexity*E*= the number of edges of the graph
*N* = the number of nodes of the graph*P* = the number of connected
components.is pretty much there in the code though it would need to be
amended to include intra-hadler node connections, as to date i have only
been interested in graphing handler relationships not overall complexity.

The weak link to such an integration may be on my end:  while useful,

they're of a lower priority than client work, so they get attention only
in between phases with more important projects.  As a result, it's hard
to say when it'll be in any form that others could use.



Ditto - still good to know what you are up to and where to ask questions.
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Function Points

2007-05-08 Thread Chipp Walters

Nope, don't use Function points here. But I do have experience in estimating
project scope. Here's some ideas:

1) First, get a small upfront check to build the spec. A defined spec will
help greatly in creating an estimate for what it takes to complete a
project. I typically like to create large scale blueprints outlining the
interface flow/design of a project, and they generally don't cost over a
couple grand to create. I've found over the years typically more work goes
into the GUI and hooking it up, than the back-end.

2) After you have a project blueprint and have gone over it with the
customer, you'll need to define the development 'nature' of a project. We
prefer a modified Extreme Programming methodology 
http://www.extremeprogramming.org/ whereby we set early and frequent
milestones with the knowledge things can and will change during the process.

At Human Code we generally worked on a different model as a product HAD TO
SHIP ON TIME, so we could spec it out, start to finish, at the beginning.
Create a schedule and keep to it no matter what. While this did satisfy the
customer requirements, it ended up many times creating a less than stellar
finished product.

3) If forced to make a not to exceed bid, I generally go over the blueprint,
and estimate as accurately as I can how long it will take, then multiply
times 3. I typically explain to my customers they get a better and more cost
effective project by paying 'by the hour' as opposed to 'fixed bid.' Fixed
bids have more detailed specs and a ECN process (Engineering Change Notice)
by where we can modify the projected schedule, budgets and deliverables.

Lastly, THERE IS NO SUBSTITUTE FOR EXPERIENCE in estimating a project.

HTH,
Chipp
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution