There is no substitute for experience.
Here are the approaches most commonly used to estimate the time and cost of software projects.
Story Points – An approach favored by agile software teams. The simplest unit of work is one point. As units of work are evaluated, they are compared to the simplest and to each other on a relative scale. While some of the estimates will be too short or too long, hopefully, they will balance out and produce a good overall duration.
Function Points – A rigorous approach based on system inputs, outputs, interfaces, tables, etc. Some teams find this metric too complex and time consuming. Significant design work is required to derive an accurate estimate. If you have the time and patience, this is a robust technique.
Lines of Code – Simple right? How many lines of software source code will it take to implement the system? Unfortunately, lines of code vary widely across systems and teams. An accurate estimate is much harder than it looks. Your team will need substantial experience to produce accurate estimates.
Use Case Points – A technique for converting use cases into a point metric. This technique has never achieved much traction in the industry. Use cases, which include multiple scenarios, can be complex making them difficult to estimate.
Hours (or Days) – This is the ultimate measure because the conversion to dollars is simple. In the end, all of the above measures will be converted to hours or days so that a cost estimate can be derived. The problem is that teams need some baseline to estimate time. How much work can be done in four hours or two days?
Wild-A$$ Guess – Someone with lots of experience decides how long the project should take. This technique is commonly used and the cause of many project time and cost overruns. If you must do this, provide a range not a single value. For example, rather than say the project will take six months, say the project will take between five and eight months.
Scientific Wild-A$$ Guess – Someone calculates how long a portion of the project will take — usually either the requirements gathering or code implementation part. They apply standard metrics to the rest of the project to calculate a total duration. Again, if you must do this, offer a range.
The bottom line is simple. Software construction estimates are notoriously unreliable. The only good estimates are produced by teams that follow a repeatable process and maintain good records. There is no substitute for experience when it comes to estimating.