Bryan Moss wrote:
> Billy Brown wrote:
> > > How do you measure Defects per LOC exactly?
> > Total number of defects found / total lines of source code in the
> > project. [...]
> At what time do you count the defects? And what is a 'defect' exactly?
In essence, a defect is anything that makes the program different from the spec it is built to. It could be anything from a bug that crashes the program to a typo in a dialog box. Different organizations classify them differently, and make different decisions about borderline cases, but all of the more organized software companies have fairly good written standards that their development teams must use.
The important thing, however, is to make sure that you use the same methodology from one project to the next. That way you can use the numbers as an actual measure of changes in your own code quality. Comparisons to other organizations are a bit less informative, both because standards vary somewhat and because different companies use different programming languages. However, you can still make very rough comparisons (if company A gets 100 defects per KLOC in C++, and company B gets 500 defects per KLOC, it probably isn't just a difference in definitions).
If you are seriously interested in this sort of thing, I'd suggest the following books as an introduction to serious software engineering:
Software Project Survival Guide
The last is by far the least technical of the three.
> I'm thinking more along the lines of Apple's Opendoc, RIP. The components
> only make up apps at the user-end. At the moment a programmer can employ
> bits of Office or IE into his apps but the user can't do the same. If I
> have a spellchecker in Office and I want to use it in my mail program I
> can't. In both my mail program and Office I'm using text, I'm writing in
> English, and yet unless the programmer has hardwired the ability to use
> Office spellchecker COM object in to my mail program I can't do this very
> simple thing. In order to do this the UI would have to be created on the
> fly and you would need strict rules for how components are designed.
Unfortunately, there are good reasons why OpenDoc never went anywhere.
Your first problem is that it introduces truly horrendous user interface
problems. Either the UI has to be capable of handling any possible
component (in which case the components will be too standardized to allow
for much innovation), or the components get to draw their own windows (which
leads to dialog-box hell).
Your first problem is that it introduces truly horrendous user interface problems. Either the UI has to be capable of handling any possible component (in which case the components will be too standardized to allow for much innovation), or the components get to draw their own windows (which leads to dialog-box hell).
Your second problem is that most users don't want things to work that way. They don't want to have to figure out how to juggle the various components on their computer, picking the right combination for whatever it is they are doing at the moment. They want you, the programmer, to do that for them. Thus, such a system doesn't have much appeal for users. Since most programmers don't want it either (I'd rather invoke the component through code), that doesn't leave you with much of a market.
Billy Brown, MCSE+I