At a previous job (circa 2010), my manager mentioned that he's doing some research into quality metrics. The bottom line is to answer the question how many bugs should I expect? The goal is to try and predict how many bugs are incoming, and more importantly, how many bugs we probably haven't yet found.
There are some problems around this metric. Historically, we tend to look at "lines of code," which is a horrible way of measuring functionality. Functional points seem better, but I don't have an easy way to describe and measure how many function points a piece of software has.
The other issue is that quality will obviously vary (widely) depending on if you have really horrible QA/developers, or really awesome, or somewhere in the middle.
Another issue is, obviously, what you define as a bug. Some teams look at any feature change as a bug; others try to divide (eg. new functionality vs. broken but "works as expected" functionality).
Is there any research, or body of work, on helping software teams identify and predict how many bugs they should be finding?