It's a known thing. Look up "software defect estimation".

The methods aren't too dissimilar to how population ecologists estimate the population of a wild animal population (you tag individuals and note the rate at which you're repeated re-tagging the same ones), the estimated total falls out via statistics.

It's not a method that's applied frequently even within organizations (I've worked in and with QA numerous times), and my copy of Cem Kaner's Testing Computer Software doesn't seem to address the matter. Boehm's Software Engineering Economics discusses software reliability modelling at page 181 (Chapter 10: Performance Models and Cost-Effectiveness Models).

IEEE has "An efficient defect estimation method for software defect curves" which looks like it should cover the area, membership or purchase required:

http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=124539...

"Applying Software Defect Estimations: Using a Risk Matrix for Tuning Test Effort", James Cusick, Wolters Kluwer

http://arxiv.org/pdf/0711.1669.pdf

BUG COUNT ESTIMATION: http://www.testdesigners.com/bugnets/bugcountestimation.html

References Capers-Jones, leading authority in the field.

Many methods start with an assumption that software coding is essentially a progress of inserting bugs into code at a known rate (and there are studies which have established such rates with fairly high levels of confidence). So debugging and QA are then a bug removal function. Knowing what your bug insertion rate was allows you to estimate how many of those bugs you've removed.

That's the theory.

this just makes me want to push spec review, coverage/unit testing, and smoke testings a more stringent requirement for new codes :\