It may be possible if there is previous research on the costs of similar projects that have been successfully completed. Otherwise, it is impossible.

You can estimate the required programing hours by estimating the scope of the software and not the detailed requirements because the scope could be a good index for the complexity of the required program

Cost estimation is always based on some sort of specification of the software to be developed. However, the level of completeness, precision and detail of the specifications can vary widely. Actually, specs can consist of just a very abstract indication of the application objectives (e.g., "I need a CRM system") to a complete and detailed specification of the application responsibilities, with precise requirements concerning both functional and non functional qualities.

Of course, the more information you have, the more accurate the estimation can be.

If you have only a very shallow description of the required application, the best you can do is estimation by analogy. If you have historical data concerning the cost of similar applications (or if you can find these data in the literature or in public datasets), you can use those data to make an estimate.

So, for instance, if you are asked the cost of developing a new CRM system and in the past you developed two such systems, and they required 12 and 15 PersonMonths respectively, you may conclude that the development effort will be in the 12-15 PM range, and you will be able to compute the corresponding cost range.

Of course, it can happen that the new system is more complex than both the old ones, or that it requires more functionality, or that better reliability is required, etc. In all these cases the cost of developing the new application will be higher than expected, and you will know this only when the actual requirements are given.

To overcome this problem, you can propose a development cost related to the actual features of the already developed applications, clarifying that requests for additional functionality or better quality will increase the application cost.

In the area of ERP, CRM, HR, .. there are so many commercial products that a 10 minute talk with the busness organization will give you a hint towards an exsiting application that will fullfill 80 % of the needs. Try to get a quotation on that, and you will have a decent first estimate, probably on the high end of the bandwith. Building a tailor made solution can be less expensive than that, under the condition that you manage to have a decent requirements management in your project, and a business organization that is actively involved in the project.

If estimation is done by other than those who will build it, you end creating a system where the person who makes the estimates is not accountable for them: it is always the team who delivers who is accountable for the estimates. A team should refuse to estimate anything for which there are not picture-perfect requirements; anything else is just a wild guess, because it puts the team in the role of clarifying requirements. You can't time-box requirements acquisition: it is research.

So you need not only requirements collection but, as Scrum stipulates, a set of enabling specifications for the deliverable. That means that estimating anything of which advanced requirements analysis has been done will have a large standard deviation. Research at the Simula Center in Oslo has borne this out. Anything short of enabling specifications, targeted for short-term delivery, will lead to wildly imprecise (and inaccurate) measurements.

This is an empirically substantiated result.

Thank You,

Dear all Sir, for your valuable advice.

Now we're go to forward by based on your all feedback .

I think software cost estimation is a problem before requirement collection.

But is this problem is directly mentioned in any paper or has been proved?

please help me .................

I think I referred you to the papers from the Simula Center in Oslo. Look for papers by Magne Jørgensen. There is a lot of research on estimation that is even more pessimistic than I make it out to be. Estimation of a total project, where you are building something you haven't built before, is pure guesswork if you're forecasting more than a few days.