permaculture playing cards*
The moose likes Agile and Other Processes and the fly likes Sizing & Estimation Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Soft Skills this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "Sizing & Estimation" Watch "Sizing & Estimation" New topic
Author

Sizing & Estimation

Ingudam Manoranjan
Ranch Hand

Joined: Jul 31, 2006
Posts: 48
Not sure if this will be the right forum, but couldn't figure out where to post, so posting here.

We have a product which has grown over the years. We wanted to re engineer the product again & hence need to size the product and come up with the estimation. Some of the ways I can think of are:

1) Function Point estimation - which is very well for new requirements. However, identifying all the FPs of the product will take quite an effort.

2) Lines of Code - This is something I can easily find out. But how do i estimate? Basically need a corelation of the effort with the LOC.

Thanks.
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
I haven't used FP's myself but all those who've tried that I know of have said they wouldn't recommend it.

An estimate based on lines of code is about as accurate as asking the fortune teller.

I'd suggest generating relative, abstract estimates (you might call it "complexity" or you could call it "wazhingle points") for all functionality you want in the system and then implementing one thin slice of the system. That slice won't take an enormous time to implement and it sufficient for calibrating your relative estimates.

This approach would have the benefit of spending a relatively low effort in estimation ("This is twice as complex as that, that over there is about the same as this, ...") and you get more trustworthy estimates because they're based on history data (the slice) instead of pure speculation.


Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
I wholeheartedly agree with that approach. One thing you'll notice right off is there's not conversion formula from complexity to days or man-hours or anything like that. The first time you do it for a given team and customer and technology, there's no good guideline. If you take a few tasks early on and work them, you can start to develop that relationship. Maybe tasks with effort or complexity of 8 jelly beans take about 4 days.

If you have the luxury of a few days and dollars, get Mike Cohn's books on stories (a hip word for right-sized tasks) and estimates

Having done this re-platforming or re-engineering gig a couple times, I can point out some opportunities for horrific mistakes. View everything as freshly as possible. Don't assume everything in the current system is important or necessary or was ever a good idea. Don't duplicate the bugs Learn the idioms and capabilities of the new language or platform and be prepared for those to make some of your favorite bits of the old design unnecessary.
[ September 30, 2007: Message edited by: Stan James ]

A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
What exactly do you mean by "reengineering", and why do you want to do it?


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Ingudam Manoranjan
Ranch Hand

Joined: Jul 31, 2006
Posts: 48
Thanks Lasse Koskela & Stan James.
I agree with you with the approach. I have done this to some extent. We already have some historical data on the effort required for "simple", "medium" & "complex" use cases. Some analysis has been done to come up with the list of use cases and classified based on the complexity.

This is some sorta informed gut feeling type of estimation I had done. However, I am not very confident. So I want to verify with some other method.

Hi Ilja Preuss ,
Reengineering, I am not sure will be the right word or not. Maybe it is plain refactoring. But here is the situation. The said product is in java & jsp codes and we want to do architectural changes.

Now I have loads of jsp & java files. I can come up with LOC per file and also come up with a a figurative complexity of each file, maybe like cyclomatic complexity [ some tools are readily available for that] and classify each file to a type complexity like again "simple", "medium", "complex".

Based on the above classification, I can put some rough figure for each type of file by doing, as Lasse Koskela was suggesting, a recoding of the file in the new architecure.
Rajah Nagur
Ranch Hand

Joined: Nov 06, 2002
Posts: 239
Are there any plans of re-using existing code wherever applicable like - business layer, data access layer etc? This can affect your estimation


You can't wake a person who is <b><i>pretending</i></b> to be asleep.<br />Like what <b>"it"</b> does not like - <i> Gurdjieff </i>
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
Any mention of "use cases" and estimating scares. I'm not against having such documents, but from experience, they are much too large to use in estimation, work breakdown structures, assignments, tracking, etc. Misusing use cases and reusing old use cases led us directly to some of the nightmare scenarios that I hinted at above.

That's one reason I emphasized Mike Cohn's work. The finer grained your list of "things the customer wants" the better. I prodded my old team to switch from S,M,L estimates of 25-30 use cases to 1,2,4,8 estimates of 350-400 stories and it helped the team in many ways.

Follow up on some XP, Scrum or Story books to get more on how stories are used.
Frank Martinig
Ranch Hand

Joined: Oct 12, 2004
Posts: 59
If you want to have a view on how Mike Cohns estimates with use case points, you can read his 2005 article "Estimating With Use Case Points" published by Methods & Tools

http://www.methodsandtools.com/archive/archive.php?id=25

Enjoy reading it

Franck


<a href="http://www.martinig.ch" target="_blank" rel="nofollow">http://www.martinig.ch</a>
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Ingudam Manoranjan:
Reengineering, I am not sure will be the right word or not. Maybe it is plain refactoring. But here is the situation. The said product is in java & jsp codes and we want to do architectural changes.


OK.

The best way to do this I know is doing it while implementing new features, in very small increments.

It sounds like you want to do it at one fell swoop. Can you tell us more about the reasoning?
Scott Ambler
author
Ranch Hand

Joined: Dec 12, 2003
Posts: 608
I provide some tips on estimating at http://www.ambysoft.com/essays/agileProjectPlanning.html#Estimating which you may find useful.

- Scott


<a href="http://www-306.ibm.com/software/rational/bios/ambler.html" target="_blank" rel="nofollow">Scott W. Ambler</a><br />Practice Leader Agile Development, IBM Rational<br /> <br />Now available: <a href="http://www.ambysoft.com/books/refactoringDatabases.html" target="_blank" rel="nofollow">Refactoring Databases: Evolutionary Database Design</a>
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Sizing & Estimation