I’m not sure about theory. Perhaps you could build up something based on statistic, using for example function points of new code comparing to past experience. Still you should understand that defect rate depend not only on code size and complexity, but also on such factors as person who create the code, pressure of time, quality of requirements and design, etc.
More over I suggest starting with goals. If you imagine it this way: predict number of defects and wait until testers detect as much as you predicted – this is nonsense.
There are following obstacles:
1) You will never find ALL the defects
2) While fixing defects, developers will create new defects (e.g. 10% of fixes create new defect).
3) You will ever find some “fruitless“ (one that end-user would never catch) defects. If you have number of defects as goal – testers will find these one even more often.
Conclusion: I don’t recommend even trying invent such a predicting, as It will be misused by management.