Operational Risk Management (ORM) is a growing area of concern for many in the investment banking community, especially as operational risk is now linked directly to required capital reserves.  The Basel II accord requires that banks have an ORM system which is “sound and implemented with integrity”, but in practice mapping such a high level requirement onto the development and management of software is complex.  However, it is clear that risk in software must be quantified, and that reducing such risks will reduce operational risk, and thus capital requirements, for investment banks.

There is no absolute means of measuring the risk associated with software, but a variety of metrics can be used to provide approximations or indicators of risk.  One obvious way of measuring future risk is to quantify past failures and extrapolate forward, but this can’t predict the risk in a new system, and takes time to reflect changes or improvements made in new versions.

Other simple metrics might include number of lines of code, cyclometric complexity, or the number of serious outstanding bugs in the defect management system.  However, these tend to scale with the size of a project as well as with the complexity – and a large but well engineered system will tend to be much more robust than a small system thrown together with no design or structure.

ThreadSafe provides metrics for risky programming patterns in the area our customers tell us is most likely to cause hard-to-find failures.  This is a proxy for the risk that software contains programming mistakes which can’t be detected with conventional testing, which can feed into an ORM system.

ThreadSafe also identifies specific instances of risky or incorrect coding to developers, giving them the opportunity to make a repair and thus reduce risk.  Learn more about ThreadSafe.