Software Engineering - Estimate the cost, complexity and duration of a project.

Author

Estimate the cost, complexity and duration of a project.

gotostop

2007-11-01, 4:22 am

Hello every,

I just want to get some useful information.

Given that you are the Software Engineer in a small software company
doing custom software applications. How do you estimate the cost,
complexity and duration of a project.

I started trying to build a function which can be utilized to
directly get the cost with two parameters product complexity and
development duration.

Cost=f (complexity, duration...)

Q1, besides product complexity and duration, any other factors could
influence the cost?

Q2, for the first parameters how many factors could be used to count
for the coefficient or value, how is duration?

I will be very appreciate for your replying.

Phlip

2007-11-02, 4:24 am

gotostop wrote:

> I just want to get some useful information.
>
> Given that you are the Software Engineer in a small software company
> doing custom software applications. How do you estimate the cost,
> complexity and duration of a project.

You do the project in 1-w

iterations. That means, at the beginning of the
w

, you ask your users what's the smallest high-value feature they could
use right now. You implement only that feature (and its unit test), and
deliver it. Then you ask what the next features are.

This system allows you to track the time each feature takes. You can
estimate day- and w

-sized features more accurately, and this allows you
to estimate w

- and month-sized goals in terms of the general numbers of
features involved.

> I started trying to build a function which can be utilized to
> directly get the cost with two parameters product complexity and
> development duration.
>
> Cost=f (complexity, duration...)
>
> Q1, besides product complexity and duration, any other factors could
> influence the cost?
>
> Q2, for the first parameters how many factors could be used to count
> for the coefficient or value, how is duration?

This assumes your long-term plan knows the detail of every feature you need.
That would be great if you were omniscient. But any attempt to estimate
every possible feature, in advance, runs the risk of scheduling too many
features.

The point of interacting with the customer, and constantly deploying new
versions, is to find the minumum set of features you need. Don't do the ones
the customer isn't asking for _this_ w

. Your mission is to participate
with the customer in finding this minumum set of high-value features.

--
Phlip

EventHelix.com

2007-11-02, 10:06 pm

> I just want to get some useful information.
>
> Given that you are the Software Engineer in a small software company
> doing custom software applications. How do you estimate the cost,
> complexity and duration of a project.
>
> I started trying to build a function which can be utilized to
> directly get the cost with two parameters product complexity and
> development duration.
>
> Cost=f (complexity, duration...)
>
> Q1, besides product complexity and duration, any other factors could
> influence the cost?
>
> Q2, for the first parameters how many factors could be used to count
> for the coefficient or value, how is duration?
>
> I will be very appreciate for your replying.

Developer experience in the area of development is a big factor in
estimation. I would recommend looking at COCOMO and COCOMO II
techniquest for help in estimation.

--
EventStudio 4.0 - http://www.EventHelix.com/EventStudio
Sequence Diagram based Systems Engineering Tool

xpyttl

2007-11-02, 10:06 pm

"gotostop" <liu.feixiong@gmail.com> wrote in message
news:1193900358.794366.101850@i13g2000prf.googlegroups.com...

> Cost=f (complexity, duration...)
>
> Q1, besides product complexity and duration, any other factors could
> influence the cost?

If you want reasonable estimates, the estimates need to be based on your
historical data. The more granular your data is the better, but if you have
good historical data (your accounting system might be a resource here) then
you can do better than any of the published models by using your own data.

Generally the size is much more of an impact than "complexity". Complexity
is a hard thing to measure. Size isn't so bad. You can get a reasonable
handle on size via function points (or feature points if that is your
preference). If you are disciplined at writing requirements, then you can
make a size estimate based on requirements. I know one very large
contracting house that has a very strained way of writing requirements.
They then count the number of times the word "shall" appears in the
requirements, multiplies that by a factor, and that is their bid. They are
rarely far off.

Certain "types" of projects tend to be markedly different than others. For
example, data warehouse projects tend to generate few function points, so
the hours per function point value tends to be significantly larger than the
"average" project. Ditto for embedded projects. How granular you can
usefully make the "type" of project depends on how good your data is, and
how much of it you have.

> Q2, for the first parameters how many factors could be used to count
> for the coefficient or value, how is duration?

As I mentioned, companies can be effective with only a requirements count,
but that depends on your environment and data. I know another (of the very
few shops that can estimate effectively) that has a complex spreadsheet
involving things like how many screens, how many databases, how many
different platforms, etc. They can also estimate very accurately, but
obviously developing that spreadsheet requires a lot of data.

As far as duration, generally there is an optimum team size which ends up
affecting the time.duration relationship. Another

truth of software
development is that adding resources after the project is started will only
slow it down, so you need to determine the resources you need up front.
Again, a robust estimating model can help here, particularly if it can
identify specific skills needed, but again, that takes a lot of data.

Another thing to keep in mind is that as soon as developers start to work,
they begin injecting defects. How soon you begin removing those defects
will affect the timeline significantly (perhaps more significantly than most
realize). Implementation of Fagan inspections beginning with requirements
will help ensure there are no nasty surprises on the defect front at the
end. Of course, the assumption is that you already have a robust testing
regime in place. Your estimating model needs to provide for all these
things up front. Cutting costs on inspection or testing will increase the
overall cost of the project. It is best if your estimating model also
includes a defect model. Managers like to believe that shortening the
timeline will reduce the cost; in fact, for a given project size just the
opposite is true. You need to understand defects to grasp the optimum
timeline.

...

H. S. Lahman

2007-11-03, 7:07 pm

Responding to Gotostop...

> Given that you are the Software Engineer in a small software company
> doing custom software applications. How do you estimate the cost,
> complexity and duration of a project.
>
> I started trying to build a function which can be utilized to
> directly get the cost with two parameters product complexity and
> development duration.
>
> Cost=f (complexity, duration...)

Note that to a first approximation for software development,

cost = developer project hours * pay rate.

Unless there is something really unusual about the shop, the errors in
other estimates will tend to dwarf any error using this simple formula.
Also not that duration is basically a scheduling problem for fitting
project hours into a calendar. So the real estimate is of developer
project hours; that is where all the variance will be.

I wouldn't go this route, at least initially. Most of the error will lie
in estimating the input parameters. Trying to refine those estimates
will tend to lead to more variables to define. There are a number of
commercial models (SLIM, COCOMO, etc.) that provide estimation this way
but they have a gazillion factors that need to be quantified locally.

Instead I would use relative estimation initially and then collect data
for a track record of projects and use statistical analysis to enhance
the estimates over time. In fact, there are spreadsheets and whatnot
available for the statistical part once one has a track record. (There
is one that comes with the "Team Software Process" book by Humphreys or
you can google around; it is basic linear regression.)

Relative estimation depends on two things: breaking up projects into
relatively small tasks and that people are much better at deciding A > B
than they are are deciding how big either A or B actually is. So the
steps are:

(1) break up the project into several smaller tasks.

(2) order the tasks in terms of increasing size by comparing individual
tasks for </>.

(3) pick two tasks, one small and one large, that have already been done
that would go somewhere near the ends of the list.

(4) plug in the actual effort for the tasks from (3).

(5) do a linear extrapolation to associate effort with the tasks to be
estimated so that the two "known" tasks fit. This yields individual
estimates for each task relative to the known tasks.

IME, this sort of estimation alone can lead to -0/+20% variance on
projects of 10 ey. Combined with adjustments for a known track record
one can get -5/+15% variance. That's not bad for a couple of hours
planning for a 10 ey project.

Note that there is no complexity estimate. That's implicit in the
relative ordering. As long as tasks are fairly small there is no need to
worry about it explicitly.

*************
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

Alexei Polkhanov

2007-11-08, 4:20 am

On Oct 31, 10:59 pm, gotostop <liu.feixi...@gmail.com> wrote:
> Hello every,
>
> I just want to get some useful information.
>
> Given that you are the Software Engineer in a small software company
> doing custom software applications. How do you estimate the cost,
> complexity and duration of a project.
>
> I started trying to build a function which can be utilized to
> directly get the cost with two parameters product complexity and
> development duration.
>
> Cost=f (complexity, duration...)
>
> Q1, besides product complexity and duration, any other factors could
> influence the cost?
>
> Q2, for the first parameters how many factors could be used to count
> for the coefficient or value, how is duration?
>
> I will be very appreciate for your replying.

You may find it useful to refer to PSP (Personal Software Process) and
other Statistical methods. There should be a feed-back loop in basis
of each estimation method. First you need to choose metric you will
use to measure the complexity - among common metrics you can find
direct SLOC/LOC or (Software Lines Of Code) or Proxies such as
Function Points, Inputs, number of dialogs, pages on website etc. Some
proxies such as UI Dialogs or Objects work better with one type of
application rather than the other. So selecting right proxy for the
complexity is very important.

Another thing you should remember developing a business systems is
that - YOU CANNOT GROW SOFTWARE like you grow wealth or apple trees.
Very often you cannot add new feature to existing system without re-
designing 2-3 others, so STABILITY OF REQUREMENTS constitutes greatly
to overall costs. I would recommend to use $$$ MONEY $$$ not days or
months when talking with management and customers about requirements.
Phrase "The design change you proposed will increase cost of this
project by 14,000 USD" understood much better than "This will require
additional 23 hour of development time".

Second step is to get estimates of your team performance using same
metric as you used for complexity. If your team in the past were able
to produce 200, 340 and 180 LOC/day you estimates most likely will
not be very accurate if you use LOC. You may find that trying Proxy
will help you to reduce that deviation. If historical data for your
team are not available then take "suggested" number and adjust it
every w

including new data. Make sure you honestly exclude time not
directly spent on development (washroom, chat with co-worker, email,
Internet etc.) Usually single developer can spend 4 - 4.8 out of 8
hours directly on project related tasks. If number is bigger it is
probably not true. There is less productive time in overtime so by
adding 4 hours of overtime you probably add just 1.5 hour to total
productive time.

Once you calculate your productivity for a w

/month - feed it back
into process, by doing so you establish feed-back that will allow you
to increase estimation accuracy. Don't be surprised if at first your
estimates will be missed by 80-250%.

Applying same principles for all development stages you can get total
estimated cost.

COST(N) = PRODUCTIVITY(N)* COMPLEXITY(N)

TOTAL COST = COST(Requirements) + COST(Design) + Cost(Construction) +
COST(Test) + COST(Administration) + (???) COST(Maintenance)

For requirements, allocation and design stage you use articles. For
code construction - SLOCS or other proxies. Testing usually have
constant cost if it used only to measure quality.

By dividing total complexity by total team productivity (for each
stage) you get duration. Remember that adding new developer to the
team does not proportionally increase productivity dues to increased
communication overhead.

Alexei.

Alexei Polkhanov

2007-11-08, 10:08 pm

On Oct 31, 10:59 pm, gotostop <liu.feixi...@gmail.com> wrote:
> Hello every,
>
> I just want to get some useful information.
>
> Given that you are the Software Engineer in a small software company
> doing custom software applications. How do you estimate the cost,
> complexity and duration of a project.

You may find it useful to refer to PSP (Personal Software Process) and
other Statistical methods. There should be a feed-back loop in basis
of each estimation method. First you need to choose metric you will
use to measure the complexity - among common metrics you can find
direct SLOC/LOC or (Software Lines Of Code) or Proxies such as
Function Points, Inputs, number of dialogs, pages on website etc. Some
proxies such as UI Dialogs or Objects work better with one type of
application rather than the other. So selecting right proxy for the
complexity is very important.

Another thing you should remember developing a business systems is
that - YOU CANNOT GROW SOFTWARE like you grow wealth or apple trees.
Very often you cannot add new feature to existing system without re-
designing 2-3 others, so STABILITY OF REQUREMENTS constitutes greatly
to overall costs. I would recommend to use $$$ MONEY $$$ not days or
months when talking with management and customers about requirements.
Phrase "The design change you proposed will increase cost of this
project by 14,000 USD" understood much better than "This will require
additional 23 hour of development time".

Second step is to get estimates of your team performance using same
metric as you used for complexity. If your team in the past were able
to produce 200, 340 and 180 LOC/day you estimates most likely will
not be very accurate if you use LOC. You may find that trying Proxy
will help you to reduce that deviation. If historical data for your
team are not available then take "suggested" number and adjust it
every w

Sponsored Links