Using historical data
As the others have said, you'll need to estimate future outcomes, based on historical models.
For best results, you need to do this with your own records.
However, for benchmarking and validation, you can also look into buying extracts from commercially-available databases of software project metrics.
Predictive Indicators in the Literature
If you poke around in IEEEXplore and the ACM Digital Library, you'll find hundreds of papers on how this or that metric is a jolly good way to predict something else. But notice that in all such cases the researchers 1. gathered the data and then 2. generated the models.
That is what we are all telling you to do: gather data. Generate models from the data.
So for example:
- Nagappan and Ball found that defects found by static analysis was a predictive metric for defects found by testing.
- Basili, Briand and Melo found that selected OO-related complexity metrics predicted the fault-proneness of different classes.
- Nagappan, Ball and Zeller also found a correlation between code complexity metrics and fault-proneness.
- Nagappan and Ball again, this time correlating defects to code churn.
... and so on it goes. There are hundreds of such papers.
But Not All Is Happy in Paradise
Except, how good is this literature? A lot of stuff published on any topic in Software Engineering has problems with small sample sizes, weak statistical power, defective experiment design and so on. Software engineering is just one of those fields where the formidable apparatus of science is difficult and expensive to deploy. There are many things we will never know with any certainty.
Fenton and Neil wrote a brutal literature review in 1999 in which they point out all these problems with the literature on metrics as quality indicators.
Many organizations want to predict the number of defects (faults) in software systems, before they are deployed, to gauge the likely delivered quality and maintenance effort. To help in this numerous software metrics and statistical models have been developed, with a correspondingly large literature ... However, there are a number of serious theoretical and practical problems in many studies.
They go on to advocate Bayesian networks, which, if you are following closely, means that you will still need to ... collect data and generate models.
We Cannot Do Your Homework For You
There are no general equations of software quality. Only rules of thumb.
Software engineering is a complex process, in the sense that Bartosz Rakowski meant. There's lots of circular causality and lot of it is unobservable. The best you can do is form some loose models.
If you want to be able to say "Doing X has led to Y", you will need to collect those numbers yourself and derive your own figures and accept that they will be wrong anyhow. The second-best option is to use the industry statistics I linked to above.
percentage of defects that customers report
actually buy you in your scenario?