| |
Five
Levels of Software Process Maturity |
|
| |
Government
and industry have the need to assess the maturity of their
internal software acquisition processes. The purpose of assessing
the maturity of organizations' software acquisition processes
is to identify areas needing improvement. In order for organization
to make improvements, they must know the ultimate goal and
what is required to achieve that goal. |
|
| |
Typically
a portion of the goals or activities of some key process areas
is satisfied/performed at a lower level. However, a key process
area cannot be achieved until all it's goals have been satisfied.
A maturity level is achieved by mastering all of its key process
areas. Once the maturity level is achieved, the model requires
that the satisfaction of all lower level goals is maintained.
|
|
| |
The
stages of the level are complementary and flow upward. The
following characterizations of the five maturity levels highlight
the primary process changes made at each level: |
|
| |
Five
Levels of Software Process Maturity |
|
| |
| |
5.
Optimization
4.
Managed
3.
Defined
2.
Repeatable
1.
Initial
|
 |
|
|
| |
Initial |
|
| |
The
software process is characterized as ad hoc, and occasionally
even chaotic. Few processes are defined, and success depends
on individual effort. For an organization to mature beyond
the initial level, it must install basic management controls
to instill self-discipline. |
|
| |
Repeatable |
|
| |
Basic
software acquisition project management processes are established
to plan all aspects of the acquisition, manage software requirements,
track project team and contractor performance, manage the
project's cost and schedule baselines, evaluate the products
and services, and successfully transition the software to
its support organization. The project team is basically reacting
to circumstances of the acquisition as they arise. The necessary
process discipline is in place to repeat earlier successes
on projects in similar domains. For an organization to mature
beyond the level of self-discipline, it must use well-defined
processes as a foundation for improvement. |
|
| |
Defined |
|
| |
The
acquisition organization's software acquisition process is
documented and standardized. All projects use an approved,
tailored version of the organization's standard software acquisition
process for acquiring their software products and services.
Project and contract management activities are proactive,
attempting to anticipate and deal with acquisition circumstances
before they arise. Risk management is integrated into all
aspects of the project, and the organization provides the
training required by personnel involved in the acquisition.
For an organization to mature beyond the level of defined
processes, it must base decisions on quantitative measures
of its processes and products so that objectivity can be attained
and rational decisions made. |
|
| |
Quantitative |
|
| |
Detailed
measures of the software acquisition processes, products,
and services are collected. The software processes, products,
and services are quantitatively and qualitatively understood
and controlled. |
|
| |
Optimization |
|
| |
Continuous
process improvement is empowered by quantitative feedback
from the process and from piloting innovative ideas and technologies.
Ultimately an organization recognizes that continual improvement
(and continual change) is necessary to survive. |
|
