Software Maturity Index

(A metric in IEEE 982.1-1988, see http://www.standards.ieee.org/reading/ieee/std_public/description/se/982.1-1988_desc.html)

M = number of modules in current version

A = number of added modules in current version

C = number of changed modules in current version

D = number of deleted modules in current version compared to the previous version

SMI = (M - (A + C + D)) / M

More perspicuously, SMI = 1 - N/M, where M is the total number of modules in the current version of the system and N is the number of modules added, changed or deleted between the previous version and this one.

SMI can be a measurement of product stability, when SMI approaches 1.0 the product is stable. When correlated with the time it takes to complete a version of the software, you have an indication of the maintenance effort needed.

This kind of maturity seems to be different from the maturity detailed in the CapabilityMaturityModel. Comments? Connection? Discussion?

The maturity that the CapabilityMaturityModel for software is speaking about is process maturity. SMI is a metric for product maturity

A mature product is not necessarily a stable product. And this is an index of stability.

And vice versa, a stable product is not necessarily a mature product. Perhaps the metric should be called Software Stability Index? Then again, that gives other associations...

If my SMI gets "too big," I can just make smaller iterations...

Then your boss orders you to report every n:th iteration instead...

Hey. It's not in the rules that my boss can be smarter than me at manipulating statistics.

The changed, added and deleted percentages ought to be computed off the total module count of the last release, not the current one, to give a more normalized view of product changes.

However, modules don't necessarily correspond well to functionality, so what you have here is more of a code perspective of product stability. The user may get a very different picture.

You ought to define your terms when you say "maturity" and "stability", especially when you claim them to be independent concepts. In statistical process control, stability is a prerequisite for maturity, and both terms have fairly precise meanings.

But, why have this index? In particular, what do you do when it's, say, very high? Very low? Would it be more useful if correlated with quality problems in the same release? That way, you might get an idea of how fast you can develop products safely. -- WaldenMathews

Why have this index? Well, naïvely - when SMI=1.0 the product is ready for release.

Oh my, that is naïve indeed! When SMI=1.0, the product is ready for a decent Christian (oops, can't say that here anymore) burial, not release. To find out when a product is ready for release, you have to measure something different -- something about your customer. -- WaldenMathews

Perhaps it should be called the (or a) "software stagnation index". Clearly a piece of software becomes mature when everyone working on it is so hopelessly mired in confusion that they are afraid to change anything. Or, of course, when it is so flawless that there is no reason to change anything. Deciding which outcome is more likely is left as an exercise for the reader.

As someone approaching maturity myself, I resent the attempt to equate maturity with stagnation. The product is mature when it has attained in large part what was expected of it. Studying change rates can tell you something of this, but it's not the whole picture. Indeed, stagnation along the road to maturity will prevent maturity, not herald its arrival. -- WaldenMathews

Perhaps the index does apply to people. I often remind older developers that they can learn an api in a day and a language in a week, where learn is defined by the community standard and isn't particularly difficult. Adult stagnation occurs when developers refuse to replace or update their own modules (skills, patterns?) and this usually happens when they see the new stuff as inferior to the old, which it may be, but that doesn't matter. -- WardCunningham

Accepted. But perhaps OldTimers need to moan more as they learn. Was this use of Wiki anticipated? Hasn't this brought great benefit to the industry even if it hasn't always increased GoodStyle or the WikiPolitenessLevel?

One problem with C (the number of changed modules) is that determining what has really changed can't be trivially automated. Simple case in point: every year we touch nearly all of our source files to increment the Copyright period. C approaches M. This usually happens in the middle of a development cycle, so it isn't easy to take a non-scored time out. One could add a little intelligence to the "has this really changed" determination, but this is one example of many. Another example of a non-change change is when the Legal department changes the boilerplate that they want in all customer visible files. Should this cause the product's "maturity" to take a hit? -- DaveSmith

Absolutely not, Dave. According to good accounting principles, we leave maturity index at 100 and use the copyright and boilerplate stuff to lower the developer stagnation index. And keep our fingers crossed and hope we never have to learn C#, or get a visit from WardCunningham! -- WaldenMathews (t.i.c.)

What is module in this context? I only know that word in the PerlLanguage sense. -- EarleMartin

CategoryMetrics