Software quality metrics are challenging and can lead to encouraging bad behavior if not watched closely. For example, if you proclaim that number of lines of code per day per developer is good, you'll get lots of lines of code but not necessarily quality. If you proclaim the number of bugs fixed per day per developer is good, you'll get plenty of bugs fixed but not necessarily improving quality. If you proclaim the number of bugs found by test is good, they'll find bugs, but many that aren't too useful.
Static analysis tools can give good insight (e.g., code complexity) but don't get religious over the numbers. There are often very good reasons for added complexity in code.
Clearly, the best measure of software quality is the number of problems reported from the field. But that's more of a systemic measure than software quality; i.e., why was the bug introduced in the first place, what was the earliest point where it should have been detected (phase escape), etc.
The absolute worst thing you can do is to try to use the metrics to assess performance. As soon as there's any inkling of management doing that, you can kiss any thought of getting rational data out. Developers will quickly slip into the habit of making the numbers look good rather than focusing on quality. Along the same lines, don't punish developers if bugs do get into the field. If that does occur (and it will - there is no bug-free code), a number of factors had to occur. Presuming the requirements and design were correct and the developer did introduce the bug, why wasn't there a review that caught the error? Why didn't unit and/or integration testing catch the error? Why didn't system testing catch the error? It would be like blaming a goalie in hockey for goals allowed (where was the rest of the defense?).
Since the goal for metrics should be for eventual improvement, I would (instead) set up a feedback / improvement process. I would start with problems reported from the field. Do an analysis on each as to why the problem occurred and where the problem should have been caught. If you have a large number of bugs reported, you may need to employ a prioritization scheme to help focus. Generally, developers get on board if the focus is kept on improvement and not for punitive actions.