Re: Function Points
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
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
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
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
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
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
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
