#1
  1. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Oct 2002
    Posts
    91
    Rep Power
    12

    Best practices for estimating a sofware project?


    Hi!

    what is your best practices for estimating a software project?
    And did you show the customer your detail estimation sheet?
  2. #2
  3. Contributed User
    Devshed Specialist (4000 - 4499 posts)

    Join Date
    Jun 2005
    Posts
    4,392
    Rep Power
    1871
    Originally Posted by AimyThomas
    n the good old days, software development costs were purely based upon the number of man-hours that were put into it. This was good for many techies, as many didnít have a clue of how to deliver the solution and a lot of trial and error was involved. Most software developers were usually put in a department called R&D ). This was bad for the software industry as it meant that costs were ridiculously high for even medium sized projects, which meant that most investors kept away from such endeavors. None could question the situation, as nobody knew any better (least of all, the techies).

    get more information at codeproject.com/Articles/8137/How-to-estimate-a-software-project-in-man-hours
    In the good old days, people cited the sources they were copy/pasting from.

    Your code project link is broken as well.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper
  4. #3
  5. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Feb 2004
    Location
    South Africa
    Posts
    59
    Rep Power
    11
    Hi,

    In a small corporate environment where many people do many things (ie. not specialized positions), I a Developer need to do Dev Specifications and Requirements Specifications as well. Based on a very customized version of Extreme Programming (eg. info here http://xprogramming.com/book/whatisxp/) I tend to the following concepts (please note that I am only speaking roughly here - and maybe my numbers to agree with those of other developers).

    1. Dev Costs involve more than just the manhours for development implementation. Dev Costs include planning and requirements analysis and testing.

    a) Many cases have proven that the end user understands the problem and what "they" need, but not necessarily how their needs would affect other customers using the same system. As Developer / Analyst is remains you responsibility to judge the development risks and benefits, and work out the requirements for development (ie. existing process flows, existing data strucutures and then to present a suggested development implementation. This takes time and a lot of conversation / consulting. This undoubtedly has to form part of the process and price. This step results in a Requirements Specification which needs to be okayed by the client and which will contain mostly Functional Requirements.

    b) Technical Development Specifications need to be development (based on requirements), This is an internal department task and will determine how the new implementation affects / fits into existing system structures. This will determine system processes / data structures. This will contain both Functional and Non Functional Requirements.

    c) Actual development - ie the time it takes to do the programming (In my case usually based on a single developer). If you use more than 1 then the time it takes will be less, but the cost won't. This time should include you developer's testing of the modification.

    d) Testing and Fixing: Internal testing needs to be performed by individuals other than the developer (either another developer - but this would result in using a more expensive resource - OR by another individual who could test from a user's perspective. This will result in additional development due to either bugs / irritations / interface or concept design problem).

    e) Piloting / End User Acceptance Testing: This is where the user will receive his / her version of the software as a test-release for Acceptance Testing. You cant bill the client for this testing of course - BUT you need to include a cost for development required during this period. You have to determine a % of development costs to cover this. This step of the process can take a lot longer than anticipated.

    f) Official Release

    My (very roughly judged) percentages of cost:

    a) 30% Major Part of Dev Process
    b) 10% Technical Internal Planning
    c) 30 % Dev Time
    d) 20% Testing + Extra Dev
    e) 10% In Addition To Dev Time
    f) Release

    Showing the detailed estimation? I don't think it would be an issue showing a detailed estimation: some might query the testing at 20% (asking why), It is a general part of development and could just as well have fallen together weith 30% dev time (making it 30 + 20 = 50) but be seen as a simple iterative process. So yes I would show the weights on my estimation (even in detail on a Development Specification). Honestly make the best policy :-)

    Hope this is an acceptable / understandable answer :-)

    Comments on this post

    • terriwells agrees : Very informative!
  6. #4
  7. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Feb 2007
    Location
    Charlotte
    Posts
    412
    Rep Power
    144
    Originally Posted by dve83
    Hi,

    In a small corporate environment where many people do many things (ie. not specialized positions), I a Developer need to do Dev Specifications and Requirements Specifications as well. Based on a very customized version of Extreme Programming (eg. info here http://xprogramming.com/book/whatisxp/) I tend to the following concepts (please note that I am only speaking roughly here - and maybe my numbers to agree with those of other developers).

    1. Dev Costs involve more than just the manhours for development implementation. Dev Costs include planning and requirements analysis and testing.

    a) Many cases have proven that the end user understands the problem and what "they" need, but not necessarily how their needs would affect other customers using the same system. As Developer / Analyst is remains you responsibility to judge the development risks and benefits, and work out the requirements for development (ie. existing process flows, existing data strucutures and then to present a suggested development implementation. This takes time and a lot of conversation / consulting. This undoubtedly has to form part of the process and price. This step results in a Requirements Specification which needs to be okayed by the client and which will contain mostly Functional Requirements.

    b) Technical Development Specifications need to be development (based on requirements), This is an internal department task and will determine how the new implementation affects / fits into existing system structures. This will determine system processes / data structures. This will contain both Functional and Non Functional Requirements.

    c) Actual development - ie the time it takes to do the programming (In my case usually based on a single developer). If you use more than 1 then the time it takes will be less, but the cost won't. This time should include you developer's testing of the modification.

    d) Testing and Fixing: Internal testing needs to be performed by individuals other than the developer (either another developer - but this would result in using a more expensive resource - OR by another individual who could test from a user's perspective. This will result in additional development due to either bugs / irritations / interface or concept design problem).

    e) Piloting / End User Acceptance Testing: This is where the user will receive his / her version of the software as a test-release for Acceptance Testing. You cant bill the client for this testing of course - BUT you need to include a cost for development required during this period. You have to determine a % of development costs to cover this. This step of the process can take a lot longer than anticipated.

    f) Official Release

    My (very roughly judged) percentages of cost:

    a) 30% Major Part of Dev Process
    b) 10% Technical Internal Planning
    c) 30 % Dev Time
    d) 20% Testing + Extra Dev
    e) 10% In Addition To Dev Time
    f) Release

    Showing the detailed estimation? I don't think it would be an issue showing a detailed estimation: some might query the testing at 20% (asking why), It is a general part of development and could just as well have fallen together weith 30% dev time (making it 30 + 20 = 50) but be seen as a simple iterative process. So yes I would show the weights on my estimation (even in detail on a Development Specification). Honestly make the best policy :-)

    Hope this is an acceptable / understandable answer :-)
    Pretty good answer. I would say to take everything he said and try to calculate total time.... then multiply by TWO.

    LOL

    Project Estimation for anything but the most trivial projects is an inexact science.
  8. #5
  9. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Feb 2004
    Location
    South Africa
    Posts
    59
    Rep Power
    11
    LOL @ X2 - it happens that you need to do that at times. :-)

    Originally Posted by Ronster
    Pretty good answer. I would say to take everything he said and try to calculate total time.... then multiply by TWO.

    LOL

    Project Estimation for anything but the most trivial projects is an inexact science.
  10. #6
  11. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Mar 2005
    Posts
    4
    Rep Power
    0
    I agree to pad almost any estimate from a developer, because I think as developers tend to under-estimate because we all fear that:

    1. people won't understand why something that looks so simple could take so long
    2. another developer will come along and say "how could it possibly take you THAT long?"

    So when I used to Project Manage developers (I'm a developer now), I would usually add a certain amount of padding to the estimates they gave me, sometimes up to a week, but usually a few days, depending on the confidence level they communicated.

    And yes, this is completely an art, not a science, so don't expect to get close, only closer than you would with no estimates. And always rebaseline a schedule, when possible, based on new information.

IMN logo majestic logo threadwatch logo seochat tools logo