Software Process requirements - CMM
Introduction
As a Process Engineer responsible for the Software Process
within your company, you or management are probably asking the following
questions:
-
What are we aiming for as an organisation in terms of the
level of process required?
-
When is enough enough in terms of process? How do we know when
to stop?
-
What are our Company policies? How do we define them?
-
Where do we start and what should we be aiming for?
-
What sort of standards are out there?
Luckily others out there have given all these questions quite
some considerable thought. In fact back in 1988 a team of people from the
Software Engineering Institute (SEI) at
Carnegie Mellon got together and defined a paper which was released in 1991,
entitled
Key Practices of the capability maturity model. This has since been through
many iterations and refinements.
The 5
Maturity Levels of the Model
| The Capability Maturity
Model (CMM) has defined a set
of process guidelines and key process areas which describe what an
organisation should aim for, to enhance the level of the development process
to a certain defined level of maturity. In simple terms these are similar to
requirements for a software system, except they are requirements for a
software process.
The concept is that you start off with an initial State where the process
is unpredictable and inadequately controlled (1) and move to a more
disciplined process which is repeatable (2).
From here the team moves to a Defined Process (3) which is standard and
consistent. The team understands the process fairly well at this point.
Level (4) is a Managed process, that is predictable and uses statistical
process control.
Ultimately the team arrives at level (5) which lives in a continual state
of optimising itself. At this level the process starts preventing defects
from occurring.
The Capability maturity Model does not define HOW to achieve the results,
all it defines is WHAT the organisation should be aiming for. |
 |
Structure of
the CMM
As can be seen by the UML class diagram entitled "Structure of
the CMM", each maturity level indicates a the capability of the process at this
level and contains some Key Process Areas (KPA).
Each key process area identifies a cluster of related activities
that, when performed collectively, achieve a set of goals considered important
for establishing process capability at that maturity level.
Level 1 activity - Status before reaching Level 2
Key Process Areas to move into
Level 2
-
Requirements Management
-
Software Project planning
-
Software Project Tracking & oversight
-
Software Sub-contract management
-
Software Quality Assurance
-
Software Configuration Management
Conclusion
So in answer to some of the questions posed in the introduction
above, the CMM is an excellent place to start improving the process. Obviously
it will depend very much on the size of the company, the seriousness of the buy
in from senior management, and many other factors as to whether this level of
process improvement is necessary and sustainable for your organisation.
Even if it is not formally adopted in your organisation, it
certainly gives the Process Engineer some serious food for thought in terms of
what can be implemented, what to aim for and in what sort of order one can
implement these process improvements.
Home
References
Reitzig, Rolf , Feb 2002. Rational Webinar entitled
Achieving CMM Level 2 with the RUP
Software Engineering Institute's, 1993.
Key Practices of the capability maturity model
Edwards, Charles. March 2002. ProcessWave Limited.