CS460 CMM
CS460 CMM
Immature Organisations
• Software processes are often rigorously followed.
• Organisation is reactionary.
– firefighting.
– schedules and budgets routinely exceeded.
– product functionality and quality compromised to meet
deadlines.
– no objective way to judge product quality or software product
and process problems.
1
Mature Organisation
• Organisation-wide ability to manage development and
maintenance.
• Managers communicate process to employees, and process is
followed.
• Mandated process is useable and consistent with the way work
actually gets done.
• Process updated when necessary.
• Objective, qualitative basis for judging product quality and
analysing problems.
• Schedules and budgets usually met.
• Expected results for cost, schedule, functionality and quality
usually achieved.
Managed
predictable
process
Defined
standard,
consistent practice
Repeatable
disciplined
process
Initial
2
Process Maturity Levels
Process Maturity Level Key Process Areas
5 – Optimized Defect prevention
Technology change management
Process change management
4 – Managed Quantitative process management
Software quality management
3 – Defined Organization process focus
Organization process definition
Training program
Integrated software management
Software product engineering
Intergroup coordination
Peer reviews
3
Goals for Level 2 KPAs
• Requirements analysis
– System software requirements are controlled to establish a
baseline for software engineering and management use.
– Software plans, products, and activities are kept consistent
with the system requirements..
• Software Project Planning
– Software estimates are documented for use in planning and
tracking.
– Software project activities and commitments are planned
and documented,
– Affected groups and individuals agree to their commitments
related to the software project.
4
Goals for Level 2 KPAs (cont)
• Software quality assurance (SQA)
– SQA activities are planned.
– Adherence to standards, procedures, and requirements.
– Affected groups and individuals are informed of SQA
activities and results.
– Noncompliance issues that cannot be resolved are
addressed by senior management.
• Software configuration management (CM)
– CM activities are planned.
– Selected software work products are identified and
controlled.
– Changes to identified software work products are controlled.
5
Goals for Level 3 KPAs (cont)
• Training program
– Training activities are planned.
– Training for skills and knowledge needed for management
and technical roles is provided.
– Individuals receive the training necessary to perform their
roles.
• Integrated software management
– A project's defined software process is a tailored version of
the organization's standard software process.
– The project is planned and managed according to the
project's defined software process.
• Integrated product engineering
– SE tasks are defined, integrated, and consistently performed
to produce the software.
– Software work products are kept self-consistent.
6
Goals for Level 4 KPAs
• Quantitative process management
– Quantitative process management activities are planned.
– The performance of the project's defined software process is
controlled quantitatively.
– The process capability of the organization's standard
software process is known in quantitative terms.
• Software quality management (SQM)
– The project's SQM activities are planned.
– Measurable goals for quality and their priorities are defined.
– Actual progress toward achieving the set quality goals is
quantified and managed,
7
Conclusions
• The KPAs describe what to do, but they do not mandate how to
do it.
• Achieving higher levels of software maturity is incremental and
requires long term commitment to continuous process
improvement.
• Software organizations may take 10 years or more to build a
foundation for, and a culture oriented toward, continuous
process improvement. This level of effort is required to produce
mature software organizations.
• The CMM is not a silver bullet and does not address all of the
issues important for successful projects. It does not:
– address expertise in specific application domains.
– advocate specific application technologies.
– suggest how to select, hire, motivate and retain competent
staff.
Conclusions
• The CMM represents a common sense approach to software
process improvement.
• The maturity levels and KPAs have been extensively discussed
in the software engineering community.
• While the CMM is not prefect, it is a useful tool for guiding
software process improvement efforts.
• The CMM does not guarantee the software products will be
successfully built, but it can help improve cost, quality and
productivity goals.