Hi,<p>One of the most difficult stuff of being a developer, it's than I'm never sure about my estimations about a software project development time/effort required and cost.<p>How do yo do this? I can find a suitable answer specially when dealing with people with no computer science backgrounds
Experience. When you have done the same thing multiple times then it's pretty easy to throw a number out there based on past projects.<p>Break the project down into the pieces small enough that you feel confident about each piece. This makes creation of an estimate a project in itself, but it's worth it in the headaches and stress that it will save you from down the road.<p>Make a gut check. After you have broken down the components and come up with a sum of all the parts, your gut will usually be a good second opinion. For example, you know that while breaking each component down came to X hours which could be done in two weeks, your gut might tell you that a full month would be more accurate. Take another look at your breakdown.<p>Keep in mind that you will probably always be far more optimistic than realistic. If you have range from your gut, then the top end of your range might actually be the low to medium range of what the project will actually require.<p>You will often find two different types of clients. One client will choke over your estimate and ask you if you can get it lower. Another client will take your estimate and add more padding than you have already given it. The decision for which client to go with in this case is simple.<p>On the cost side, try going with a total project fee where you can give a hefty premium compared to what you would charge with hourly rates. Then if you go over your estimated time, at least you have plenty of wiggle room built in.<p>Don't give an estimate. In some cases product developers simply say "it will be released when it's done." This is more for developing your own products though.<p>This is my experience as a freelance web developer. The combination of what you can get away with depends on what sort of situation you are in.
The best I've ever heard comes from Agile - take the time to break the whole thing down into the finest detail you can tolerate (yes, you're doing part of the work this way), and /then/ estimate it. You'll still be wrong, but you'll be closer than if you hadn't done that.