The software industry is diverse and volatile. All methodologies for creating
software have supporters and critics, and the CMM is no exception.
Praise
The CMM was developed to give Defense organizations a yardstick to
assess and describe the capability of software contractors to provide
software on time, within budget, and to acceptable standards. It has
arguably been successful in this role, even reputedly causing some software
sales people to clamour for their organizations' software
engineers/developers to "implement CMM."
The CMM is intended to enable an assessment of an organization's
maturity for software development. It is an important tool for outsourcing
and exporting software development work. Economic development agencies in
India, Brazil, Ireland, Egypt, Syria, and elsewhere have praised the CMM for
enabling them to be able to compete for US outsourcing contracts on an even
footing.
The CMM provides a good framework for organizational improvement. It
allows companies to prioritize their process improvement initiatives.
Criticism
CMM has failed to take over the world. It's hard to tell exactly how
wide spread it is as the SEI only publishes the names and achieved levels of
compliance of companies that have requested this information to be listed.
The most current Maturity Profile for CMMI is available online.
CMM is well suited for bureaucratic organizations such as government
agencies, large corporations and regulated monopolies. If the organizations
deploying CMM are large enough, they may employ a team of CMM auditors
reporting their results directly to the executive level. (A practice
encouraged by SEI.) The use of auditors and executive reports may influence
the entire IT organization to focus on perfectly completed forms rather than
application development, client needs or the marketplace. If the project is
driven by a due date, CMMs intensive reliance on process and forms may
become a hindrance to meeting the due date in cases where time to market
with some kind of product is more important than achieving high quality and
functionality of the product.
Suggestions of scientifically managing the software process with metrics
only occur beyond the Fourth level. There is little validation of the
processes cost savings to business other than a vague reference to empirical
evidence. It is expected that a large body of evidence would show that
adding all the business overhead demanded by CMM somehow reduces IT
headcount, business cost, and time to market without sacrificing client
needs.
No external body actually certifies a software development center as
being CMM compliant. It is supposed to be an honest self-assessment. Some
organizations misrepresent the scope of their CMM compliance to suggest that
it applies to their entire organization rather than a specific project or
business unit.
The CMM does not describe how to create an effective software
development organization. The CMM contains behaviors or best practices that
successful projects have demonstrated. Being CMM compliant is not a
guarantee that a project will be successful, however being compliant can
increase a project's chances of being successful.
The CMM can seem to be overly bureaucratic, promoting process over
substance. For example, for emphasizing predictability over service provided
to end users. More commercially successful methodologies (for example, the
Rational Unified Process) have focused not on the capability of the
organization to produce software to satisfy some other organization or a
collectively-produced specification, but on the capability of organizations
to satisfy specific end user "use cases" as per the Object Management
Group's UML (Unified Modeling Language) approach.
From the systemic perspective, the CMM(I) represents a (n+1) classical
engineering approach which does not take under consideration numerous human
cognitive, organizational and cultural factors, essential for the success of
every projects, see also socio-cognitive engineering viewpoint. On the other
hand, a process design is strongly connected with the process carrier
systems and their requested functions and goals, these clear computational
relations are especially important for the validation of the results of the
CMM(I) applications. It seems, the CMM(I) requires yet a solid theoretical
ontological and epistemological background in order to be a trustworthy
standard, for an example only, the arbitrary initial choice of the levels
and Key Process Areas are not sufficiently motivated.
Critical analysis of CMM has been published in at least two papers. Bach
raises questions about the validity of CMM's assertions regarding what
constitutes good software-development processes. Bollinger and McGowan
discuss flaws in CMM's use of assembly-line process models. They show that
manufacturing is fundamentally different than software development, as the
former is primarily concerned with replication and the latter with design.
