When trying to determine what to measure, the following criteria will help [MIT 16.355J / ESD.355J Software Engineering Concepts, Metrics and Reliability Assessment, p.2]:
For predicting, we need a model of relationship of predicted variable with other measurable variables. Three assumptions (Kitchenham):
1. We can accurately measure some property of software or process.
2. A relationship exists between what we can measure and what we want to know.
3. This relationship is understood, has been validated, and can be expressed in terms of a formula or model.
Size is best predictor of inherent faults remaining at start of program test. One study has shown that besides size, 3 significant additional factors:
1.Specification change activity, measured in pages of specification changes per k lines of code.
2.Average programmer skill, measured in years.
3.Thoroughness of design documentation, measured in pages of developed (new plus modified) design documents per k lines of code.
[MIT 16.355J / ESD.355J Software Engineering Concepts, Programming Languages, p.9]:
Languages affect the way we think about problems: "The tools we use have a profound (and devious) influence on our thinking habits, and, therefore on our thinking abilities?" --Dijkstra, 1982
[MIT 16.355J / ESD.355J Software Engineering Concepts, Software System Safety, p.5]:
* Are usually caused by flawed requirements
** Incomplete or wrong assumptions about operation of controlled system or required operation of computer.
** Unhandled controlled−system states and environmental conditions.
* Merely trying to get the software "correct" or to make it reliable will not make it safer under these conditions.
The primary safety problem in computer−based systems is the lack of appropriate constraints on design. The job of the system safety engineer is to identify the design constraints necessary to maintain safety and to ensure the system and software design enforces them.