Cell Phone Software Forum
| View previous topic :: View next topic |
| Author |
Message |
PFUser
Guest
|
 Posted: Thu Apr 12, 2007 2:11 pm Post subject: Estimation & Scheduling |
 |
|
I have been a software devoloper for a long time, but
am absolutely terrible at estimation, both in areas I know
& in areas I am not familiar with.
I have never learnt any technique. Somebody suggested
that learning Function Point Analysis would be a good
way to start.
Can someone recommend any good websites or tutorials
for the same & also suggest good books? |
|
| Back to top |
|
 |
| |
Ads |
Advertising
Sponsor
|
|
Phlip
Guest
|
| Posted: Thu Apr 12, 2007 4:01 pm Post subject: Re: Estimation & Scheduling |
|
|
PFUser wrote:
| Quote: |
I have been a software devoloper for a long time, but
am absolutely terrible at estimation, both in areas I know
& in areas I am not familiar with.
|
That's because long term estimates of large batches of features is high
risk. So don't do that; noboby should ever try.
| Quote: |
I have never learnt any technique. Somebody suggested
that learning Function Point Analysis would be a good
way to start.
|
Each week, have a meeting with your "goal donor" - the person who's job is
figuring out what features your program should have.
Take a list of features with these criteria:
- high priority
- small
- no fluff or "nice to haves"
- testable - you know when you have them
Write their names on cards so you can sort them on the table. Estimate each
one in half-day resolution, and let the goal donor pull off one week.
Do those features during that week. If you go under, you should pad your
estimates next time, and
Deploy the features during the week so the goal donor can review each one.
Write unit tests for each feature, so you can change the code rapidly
without inserting too many bugs.
At the end of the week, repeat.
--
Phlip
http://flea.sourceforge.net/PiglegToo_1.html |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
xpyttl
Guest
|
| Posted: Thu Apr 12, 2007 4:10 pm Post subject: Re: Estimation & Scheduling |
|
|
Although I am personally a fan of Function Points, probably more than most
on this ng, I do think that FP might not be the best for estimating.
Function Points can really help with "sizing", i.e., is it bigger than a
bread box. Now the fact of the matter is, an estimate based on Function
Points is likely to be FAR better than most developer's estimates, but it
won't be all that good.
The whole FP discussion is further muddied by those analytical/analytical
types who want to try to put a fine point on what is really a relatively big
club. There are all sorts of debates about "Feature" points, "Real-Time"
function points, "Embedded" function points, that really take away from the
discussion. Function points are APPROXIMATE and getting too anal about them
really detracts from their utility.
The place to start is at the website of the IFPUG http://www.ifpug.org/.
There are also numerous papers across the web on FP vs development time, FP
vs defects, FP vs LOC, etc., etc., etc. ad nauseum.
The big advantage of Function Points is that you can get at the FP estimate
early. Even before the project is approved you should have a Function Point
estimate to get a sanity check on the size of the effort. Perhaps more
importantly, you should repeat the FP estimate throughout the project. Many
projects miss their budgets not because of an initial poor estimate, but
rather because the project grows over time. Repeated FP counts allow you to
put a number on that growth.
Function Points, like any other size/effort estimate, should be calibrated
to your organization. If you keep history on your projects, you can run a
Function Point estimate automatically against the code, and thus calibrate
your historical $/FP. This won't be perfect, but it will probably get you
closer than you have been before.
Something like COCOMO, which looks at a number of different project
dimensions, is probably better for estimating, but is really too complex for
sizing. COCOMO needs more data, and so has to be done after more is known.
The best estimating techniques are in-house models, based on history and
recalibrated regularly, that take features you can identify such as number
of database tables, number of screens, number of business functions, etc.
and make an estimate based on your own organization's history.
But even though it isn't the "best" for estimating, every Software Engineer,
IMO, should have a grounding in Function Points.
...
"PFUser" <PFUser@mailinator.com> wrote in message
news:evkvsd$9db$1@news.datemas.de...
| Quote: |
I have been a software devoloper for a long time, but
am absolutely terrible at estimation, both in areas I know
& in areas I am not familiar with.
I have never learnt any technique. Somebody suggested
that learning Function Point Analysis would be a good
way to start.
Can someone recommend any good websites or tutorials
for the same & also suggest good books?
|
|
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Dan Ligett
Guest
|
| Posted: Thu Apr 12, 2007 5:48 pm Post subject: Re: Estimation & Scheduling |
|
|
"PFUser" <PFUser@mailinator.com> wrote in message
news:evkvsd$9db$1@news.datemas.de...
| Quote: |
Can someone recommend any good websites or tutorials
for the same & also suggest good books?
|
COCOMO is a popular software estimation technique, and is described in
"Software Cost Estimation with COCOMO II" (Boehm, et al). Here's an
introduction:
http://www.softstarsystems.com/overview.htm
If that looks interesting, you can download a demo of our COCOMO product
here:
http://www.softstarsystems.com/demo.htm
Dan Ligett, Softstar Systems, (603) 672-0987 |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
H. S. Lahman
Guest
|
| Posted: Thu Apr 12, 2007 8:42 pm Post subject: Re: Estimation & Scheduling |
|
|
Responding to PFUser...
| Quote: |
I have been a software devoloper for a long time, but
am absolutely terrible at estimation, both in areas I know
& in areas I am not familiar with.
I have never learnt any technique. Somebody suggested
that learning Function Point Analysis would be a good
way to start.
|
Function Points are a measure of size, just like LOC. The main
difference is that FPs measure the size of the requirements while LOC
measures the size of the produced product. Either way, one estimates
size and then multiplies by a productivity factor to get effort estimates.
You need a track record with the size to determine the productivity
factor because it will vary greatly with context. However, once
determined it will usually remain remarkably stable for a given shop,
which is why estimates are primarily about size.
I suspect the reason FPs were suggested to you was because there is a
"cookbook" approach to counting them -- provided one has a complete and
quite detailed software requirements specification or software
functional specification. Alas, good SRSes and SFSes are about as rare
as snow leopards. If you do not have a good quality SRS or SFS in hand,
I don't think FPs will do you much good.
Lacking a good SRS or SFS, LOC are usually easier to estimate. But that
is only true if one estimates small things. So the Golden Rule of
software estimation is: break things down into tasks that are no more
than 2-3 days of /effort/.
[Years ago a shop where I worked ran experiments on this where
developers were asked to estimate a real project "normally" based on
typical task size (which was then ~3-12 weeks of effort). Then the same
developers were asked to break down the tasks until they were all < 3
effort days and re-estimate those tasks. When the estimates were done
for the second pass they were a minimum of 35% larger than those of the
first pass and the average was around 60% larger (as I recall).]
Once you have identified tasks you can improve your estimation accuracy
in two ways. One is a Delphic Approach where you average estimates form
multiple experts (i.e., other developers familiar with the domain).
Another approach is to use relative size estimation when one can't break
thing down to very small, uniform tasks (e.g., for ROM estimates of
overall project size during initial feasibility evaluation). People are
much better at judging X > Y than they are at estimating the actual size
of either X or Y.
In a relative estimation technique one identifies all the tasks and then
orders them by increasing effort. (This works better if the entire team
reaches consensus on < or > judgments.) One then "seeds" the list with
two tasks that have already been done so one knows how much real effort
was required; one small task and one larger task towards the high end.
Once the list is ordered and the "seeds" inserted, one can use the
"seed" task sizes to scale the other tasks linearly. IME this provides
surprisingly good estimates, often with only 10-20% variance even with
some tasks having several weeks of effort.
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Vladimir Trushkin
Guest
|
| Posted: Sat Apr 14, 2007 1:17 pm Post subject: Re: Estimation & Scheduling |
|
|
On Apr 12, 12:59 pm, "PFUser" <PFU...@mailinator.com> wrote:
| Quote: |
I have been a software devoloper for a long time, but
am absolutely terrible at estimation, both in areas I know
& in areas I am not familiar with.
I have never learnt any technique. Somebody suggested
that learning Function Point Analysis would be a good
way to start.
Can someone recommend any good websites or tutorials
for the same & also suggest good books?
|
If you are new to estimates then be prepared to fail. Because a few
(if any) professionals can do first estimates (based on vague concept
of the product) with more than 50% of preciseness. The preciseness of
estimates grows as you advance in the project because you learn more
details about the tasks you are doing. Estimates cannot be final until
you know everything about the task (including risks and contingencies
you may face). In some cases the time when it's final comes after the
end of a task. But all this is not excuse for trying to do correct
estimates. To master this skill you need to be learning at least from
your own mistakes. Just keep track of your estimates made and adjusted
at every phase of development and ask yourself why they are not what
you thought them to be before.
You may also use the history of past projects. If there was a similar
product developer by the same team you may just derive estimates from
it.
The moral is -- the only tool that you may apply to making estimates
is your experience.
----
Best Wishes,
Vladimir |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
xpyttl
Guest
|
| Posted: Sat Apr 14, 2007 6:36 pm Post subject: Re: Estimation & Scheduling |
|
|
"Vladimir Trushkin" <Vladimir.Trushkin@gmail.com> wrote in message
news:1176542241.216257.137480@y5g2000hsa.googlegroups.com...
| Quote: |
If you are new to estimates then be prepared to fail. Because a few
(if any) professionals can do first estimates (based on vague concept
of the product) with more than 50% of preciseness. The preciseness of
|
I think "fail" is kind of a strong word here. The key is managing
expectations. A typical developer estimate at the beginning of the project
will rarely be within a few hundred percent. A good model, well calibrated,
can often get to the 50% you suggest. So, is being an order of mignitude or
so better at estimating a failure?
Many organizations have an "estimating tunnel" so they understand how good
the estimate is likely to be depending on where in the project the estimate
is made. A 50% estimate can be good enough to decide whether to go ahead
with a project if the projected benefits are sufficient, and there are no
competing projects that offer a better return.
... |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Vladimir Trushkin
Guest
|
| Posted: Sat Apr 14, 2007 6:55 pm Post subject: Re: Estimation & Scheduling |
|
|
On Apr 14, 5:36 pm, "xpyttl" <xpyttl_NOS...@earthling.net> wrote:
| Quote: |
"Vladimir Trushkin" <Vladimir.Trush...@gmail.com> wrote in message
news:1176542241.216257.137480@y5g2000hsa.googlegroups.com...
If you are new to estimates then be prepared to fail. Because a few
(if any) professionals can do first estimates (based on vague concept
of the product) with more than 50% of preciseness. The preciseness of
I think "fail" is kind of a strong word here. The key is managing
expectations. A typical developer estimate at the beginning of the project
will rarely be within a few hundred percent. A good model, well calibrated,
can often get to the 50% you suggest. So, is being an order of mignitude or
so better at estimating a failure?
|
Right. It's all about expectations. Thanks for noting that.
----
Best Wishes,
Vladimir |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
223 Attacks blocked
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
