CMMI and Software Development
So, no sooner do we become experts at one aspect of our occupation than we're asked to do somehting different.
Consequently, now that we are expert at the MOSS 2007 install, they move up to a .Net devleopment effort. And, not only that, but one that appears to be one the downslide. So they're asking me to write a bunch of code which, you guys know, is not my best talent. But all the same, we are now experts at c# so we have to act like it.
We're also using Team Foundation Server which we looked at tin detail last summer when we piloted the Visual Studio Team Edition for Database Professionals for Microsoft. More on that later.
Today, our topic is CMMI and honestly, I had to visit at least a half dozen web pages before I could fogure out what CMMI stood for. Does that bother anyone else, using a TLA when you don't know what the letters stand for?
Anyway, CMMI is "Capability Maturity Model – Integration." and here, I've found the best resource so far. Our new best friends at Entinex explain the basics:
The "maturity" scale has 5 levels, 1 through 5: ad hoc, repeatable, defined, quantitatively managed and optimizing. And, the "capability" scale has 6 levels, 0 through 5: incomplete, performed, managed, defined, quantitatively managed, and optimizing. The differences are the subject of several articles available on the SEI's Web site (www.sei.cmu.edu). Because the "maturity" levels are pre-defined, the approach is called "staged." The "capability" approach is called "continuous" because the performance of the processes are tied to business objectives (which can change) and are defined less specifically by the model.
Basically, "immature" development organizations do things in an "ad hoc" manner, i.e. "staged" level 1, and "incapable" organizations "incompletely" do what they must to get the job needed by the business done, i.e. "continuous" level 0. Unfortunately, even with CMM/CMMI now available for over a decade, most software companies still operate at these levels.
For example, go tell your boss that "we're operating at a "repeatable performance level" and he will immediatly see that the objective should be to define those processes in both terms of maturity and capabilities. Clearly, I need to work on defining my capabilities at writing c# code. But this is an inflection point because, up to now, I have always used SharePoint "out of the box" limiting the code to HTML, CSS and Javascript.
So, essentially, this is another effort to quantify just how compicated software development is. I've always thougt you avoid alot of these problems by making the product develop itself and starting by making the user write his own help files. One problem is when we had an architect that couldn't write and wouldn't pay me to transcribe his ravings. Technology is always a constraint, we just have to learn to live within it. First, we make it quit hurting and then we get to choose between making it feel good and making it quit hurting for other people.
-robot
Tags: