A software process can be characterized as shown in Figure 2.2. A common process
framework is established by defining a small number of framework activities that are
applicable to all software projects, regardless of their size or complexity. A number
of task sets—each a collection of software engineering work tasks, project milestones,
framework is established by defining a small number of framework activities that are
applicable to all software projects, regardless of their size or complexity. A number
of task sets—each a collection of software engineering work tasks, project milestones,
work products, and quality assurance points—enable the framework activities to be
adapted to the characteristics of the software project and the requirements of the
project team. Finally, umbrella activities—such as software quality assurance, soft-
ware configuration management, and measurement2—overlay the process model.
Umbrella activities are independent of any one framework activity and occur through-
out the process.
In recent years, there has been a significant emphasis on “process maturity.” The
Software Engineering Institute (SEI) has developed a comprehensive model predi-
cated on a set of software engineering capabilities that should be present as organ-
izations reach different levels of process maturity. To determine an organization’s
current state of process maturity, the SEI uses an assessment that results in a five
point grading scheme. The grading scheme determines compliance with a capability
maturity model (CMM) [PAU93] that defines key activities required at different levels
of process maturity. The SEI approach provides a measure of the global effectiveness
of a company's software engineering practices and establishes five process maturity
levels that are defined in the following manner:
Level 1: Initial. The software process is characterized as ad hoc and occa-
sionally even chaotic. Few processes are defined, and success depends on indi-
vidual effort.
Level 2: Repeatable. Basic project management processes are established
to track cost, schedule, and functionality. The necessary process discipline is
in place to repeat earlier successes on projects with similar applications.
adapted to the characteristics of the software project and the requirements of the
project team. Finally, umbrella activities—such as software quality assurance, soft-
ware configuration management, and measurement2—overlay the process model.
Umbrella activities are independent of any one framework activity and occur through-
out the process.
In recent years, there has been a significant emphasis on “process maturity.” The
Software Engineering Institute (SEI) has developed a comprehensive model predi-
cated on a set of software engineering capabilities that should be present as organ-
izations reach different levels of process maturity. To determine an organization’s
current state of process maturity, the SEI uses an assessment that results in a five
point grading scheme. The grading scheme determines compliance with a capability
maturity model (CMM) [PAU93] that defines key activities required at different levels
of process maturity. The SEI approach provides a measure of the global effectiveness
of a company's software engineering practices and establishes five process maturity
levels that are defined in the following manner:
Level 1: Initial. The software process is characterized as ad hoc and occa-
sionally even chaotic. Few processes are defined, and success depends on indi-
vidual effort.
Level 2: Repeatable. Basic project management processes are established
to track cost, schedule, and functionality. The necessary process discipline is
in place to repeat earlier successes on projects with similar applications.
Level 3: Defined. The software process for both management and engi-
neering activities is documented, standardized, and integrated into an organi-
zationwide software process. All projects use a documented and approved
version of the organization's process for developing and supporting software.
This level includes all characteristics defined for level 2.
Level 4: Managed. Detailed measures of the software process and product
quality are collected. Both the software process and products are quantitatively
understood and controlled using detailed measures. This level includes all char-
acteristics defined for level 3.
Level 5: Optimizing. Continuous process improvement is enabled by quan-
titative feedback from the process and from testing innovative ideas and tech-
nologies. This level includes all characteristics defined for level 4.
The five levels defined by the SEI were derived as a consequence of evaluating
responses to the SEI assessment questionnaire that is based on the CMM. The results
of the questionnaire are distilled to a single numerical grade that provides an indi-
cation of an organization's process maturity.
The SEI has associated key process areas (KPAs) with each of the maturity levels.
The KPAs describe those software engineering functions (e.g., software project plan-
ning, requirements management) that must be present to satisfy good practice at a
particular level. Each KPA is described by identifying the following characteristics:
• Goals—the overall objectives that the KPA must achieve.
• Commitments—requirements (imposed on the organization) that must be met
to achieve the goals or provide proof of intent to comply with the goals.
• Abilities—those things that must be in place (organizationally and technically)
to enable the organization to meet the commitments.
• Activities—the specific tasks required to achieve the KPA function.
• Methods for monitoring implementation—the manner in which the activities
are monitored as they are put into place.
• Methods for verifying implementation—the manner in which proper practice
for the KPA can be verified.
Eighteen KPAs (each described using these characteristics) are defined across the
maturity model and mapped into different levels of process maturity. The following
KPAs should be achieved at each process maturity level:3
Process maturity level 2
• Software configuration management
• Software quality assurance
3 Note that the KPAs are additive. For example, process maturity level 4 contains all level 3 KPAs
plus those noted for level 2.
neering activities is documented, standardized, and integrated into an organi-
zationwide software process. All projects use a documented and approved
version of the organization's process for developing and supporting software.
This level includes all characteristics defined for level 2.
Level 4: Managed. Detailed measures of the software process and product
quality are collected. Both the software process and products are quantitatively
understood and controlled using detailed measures. This level includes all char-
acteristics defined for level 3.
Level 5: Optimizing. Continuous process improvement is enabled by quan-
titative feedback from the process and from testing innovative ideas and tech-
nologies. This level includes all characteristics defined for level 4.
The five levels defined by the SEI were derived as a consequence of evaluating
responses to the SEI assessment questionnaire that is based on the CMM. The results
of the questionnaire are distilled to a single numerical grade that provides an indi-
cation of an organization's process maturity.
The SEI has associated key process areas (KPAs) with each of the maturity levels.
The KPAs describe those software engineering functions (e.g., software project plan-
ning, requirements management) that must be present to satisfy good practice at a
particular level. Each KPA is described by identifying the following characteristics:
• Goals—the overall objectives that the KPA must achieve.
• Commitments—requirements (imposed on the organization) that must be met
to achieve the goals or provide proof of intent to comply with the goals.
• Abilities—those things that must be in place (organizationally and technically)
to enable the organization to meet the commitments.
• Activities—the specific tasks required to achieve the KPA function.
• Methods for monitoring implementation—the manner in which the activities
are monitored as they are put into place.
• Methods for verifying implementation—the manner in which proper practice
for the KPA can be verified.
Eighteen KPAs (each described using these characteristics) are defined across the
maturity model and mapped into different levels of process maturity. The following
KPAs should be achieved at each process maturity level:3
Process maturity level 2
• Software configuration management
• Software quality assurance
3 Note that the KPAs are additive. For example, process maturity level 4 contains all level 3 KPAs
plus those noted for level 2.
• Software subcontract management
• Software project tracking and oversight
• Software project planning
• Requirements management
Process maturity level 3
• Peer reviews
• Intergroup coordination
• Software product engineering
• Integrated software management
• Training program
• Organization process definition
• Organization process focus
Process maturity level 4
• Software quality management
• Quantitative process management
Process maturity level 5
• Process change management
• Technology change management
• Defect prevention
Each of the KPAs is defined by a set of key practices that contribute to satisfying its
goals. The key practices are policies, procedures, and activities that must occur before
a key process area has been fully instituted. The SEI defines key indicators as "those
key practices or components of key practices that offer the greatest insight into whether
the goals of a key process area have been achieved." Assessment questions are
designed to probe for the existence (or lack thereof) of a key indicator.
• Software project tracking and oversight
• Software project planning
• Requirements management
Process maturity level 3
• Peer reviews
• Intergroup coordination
• Software product engineering
• Integrated software management
• Training program
• Organization process definition
• Organization process focus
Process maturity level 4
• Software quality management
• Quantitative process management
Process maturity level 5
• Process change management
• Technology change management
• Defect prevention
Each of the KPAs is defined by a set of key practices that contribute to satisfying its
goals. The key practices are policies, procedures, and activities that must occur before
a key process area has been fully instituted. The SEI defines key indicators as "those
key practices or components of key practices that offer the greatest insight into whether
the goals of a key process area have been achieved." Assessment questions are
designed to probe for the existence (or lack thereof) of a key indicator.
No comments:
Post a Comment