In our introduction to mapping RMM levels to CMMI levels, we presented background info on CMMI, introduced the IBM article on RMM levels, and posted an initial mapping structure. In this article, we will look at the definition of RMM level 4. W also look at the mapping from RMM level 4 to various CMMI levels.

Background
In our introduction to mapping RMM levels to CMMI levels, we presented background info on CMMI, introduced the IBM article on RMM levels, and posted an initial mapping structure. In this article, we will look at the definition of RMM level 3. We also question the language used and reinterpret some of what IBM suggests. [...]

In our introduction to mapping RMM levels to CMMI levels, we presented background info on CMMI, introduced the IBM article on RMM levels, and posted an initial mapping structure. In this article, we will look at the definition of RMM level 2. We also cover the tradeoffs and benefits of the practices it requires. Finally, we look at the mapping from RMM level 2 to various CMMI levels.

A look back at the best from a year ago.

In our introduction to mapping RMM levels to CMMI levels, we presented background info on CMMI, introduced the IBM article on RMM levels, and posted an initial mapping structure. In this article, we will look at the definition of RMM level 1. We also cover the tradeoffs and benefits of the practices it requires. Finally, we look at the mapping from RMM level 1 to various CMMI levels.

CMMI (Capability Maturity Model Integration) is a description of the level of enlightenment of a process. It is essentially a measure of the quality and capability of a process. There are five categories, into one of which every process will fall. IBM took a similar approach to defining the requirements management process. In this series of posts, we will marry the two frameworks.

From Bobby Knight, paraphrased by Mark Cuban, via Marcus Ting-A-Kee:

Everyone has got the will to win, it’s only those with the will to prepare, that do win.

Look Ma! Me Too! The temptation to compete against a checklist can be overwhelming. When we have a competitor who provides 100 of this or 200 of that, it might seem smart to offer 200 of this and 300 of that. We’ll be better off if we focus instead on creating the other thing. The best way to compete is to valuably differentiate our product, not outdo our competition.

More is better features are just that - more is better. But more of the same old thing is worth a whole lot less than some of something else.

The first step in writing the use cases for a project is to define the scope of the project. One way to do that is to list the use case names that define all of the user goals that are in scope. To do that, you need to know how to write good use case names. Good use case names also serve as a great reference and provide context and understanding throughout the life of the project. We present our tips for writing good use case names.

A look back at the best from a year ago…