Professional Documents
Culture Documents
December 2010
SPECIAL REPORT
CMU/SEI-2010-SR-021
http://www.sei.cmu.edu
This report was prepared for the
The ideas and findings in this report should not be construed as an official DoD position. It is published in the
interest of scientific and technical information exchange.
This work is sponsored by the U.S. Department of Defense. The Software Engineering Institute is a federally
funded research and development center sponsored by the U.S. Department of Defense.
NO WARRANTY
This material was created in the performance of Federal Government Contract Number FA8721-05-C-0003 with
Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded research
and development center. The U.S. Government's rights to use, modify, reproduce, release, perform, display, or
disclose this material are restricted by the Rights in Technical Data-Noncommercial Items clauses (DFAR 252-
227.7013 and DFAR 252-227.7013 Alternate I) contained in the above identified contract. Any reproduction of
this material or portions thereof marked with this legend must also reproduce the disclaimers contained on this
page.
For information about SEI publications, please visit the library on the SEI website (www.sei.cmu.edu/library).
Table of Contents
Abstract iii
2 AIM/CMMI Overview 2
2.1 AIM Process Approach 2
2.1.1 Overview of AIM Process Assets 3
2.2 AIM Process Elements 3
2.2.1 Scripts 3
2.2.2 Forms 4
2.2.3 Roles 5
2.2.4 Other 6
2.2.5 Training 7
References 89
This document therefore provides guidance to lead appraisers and appraisal teams unfamiliar with
TSP+ when conducting Standard CMMI Appraisal Method for Process Improvement
(SCAMPISM) appraisals within organizations that use the TSP+ as a foundational operational
practice. The intended benefits of this guidance are (1) to shorten the time needed to prepare and
conduct such appraisals; (2) to provide information helpful for appropriate interpretations; (3) and
to familiarize SCAMPI leads and appraisal teams with a powerful, proven, and available technol-
ogy.
This document is aimed at the lead appraiser and appraisal team for a Standard CMMI Appraisal
Method for Process Improvement (SCAMPI) appraisal targeting maturity levels 2 and 3 of Capa-
bility Maturity Model Integration for Development, version 1.2 (CMMI-DEV V1.2) in an organi-
zation using the Accelerated Improvement Method (AIM) and Team Software Process Plus
(TSP+) as foundational practices. Secondarily, the document is intended to guide those responsi-
ble for the preparations for such appraisals.
SCAMPI appraisals focus on the specific and generic practices of the model scope under consid-
eration—that is, what CMMI® practices are to be looked at during the appraisal, as well as what
parts of the organization are to be reviewed in the appraisal. Usually, determining how that model
scope connects to the artifacts and attributes of a particular organization is unique to that organi-
zation. However, when organizations use TSP+ as the foundation of a CMMI implementation
strategy, appraisal teams have an advantage because the training, standard artifacts, and practices
are known and generally available. Commonality of approach and artifacts provides opportunities
for streamlining the preparation and conduct of SCAMPI appraisals.
Organizing the data and artifacts in the standard AIM implementation and relating them to the
appropriate practices in the CMMI model will, we believe, provide valuable assistance to those
preparing for or performing a SCAMPI appraisal. This document provides such guidance, first via
an overview of the base TSP+ process assets, then briefly in terms of a combined staged–
continuous view of CMMI implementation, and finally practice-by-practice in the form of prac-
tice implementation indicators (PIIs) that are the expected direct artifacts of TSP usage.
®
CMMI is registered in the U.S. Patent and Trademark Office by Carnegie Mellon University.
The TSP-based AIM approach combines the field-proven methods of TSP with the best lessons
learned when using TSP as the foundation of model-based improvement. The TSP has been used
for more than a decade with a proven record of performance, starting with pilot projects prior to
2000 and with the official TSP release in November 2000. This consistent performance includes
use in both government and commercial organizations. Organizations also have combined suc-
cessfully the original TSP with model-based improvement methods, including the original Soft-
ware Capability Maturity Model and transitioning to CMMI for Systems Engineering/Software
Engineering (CMMI-SE/SW) and now CMMI-DEV V1.2.
The AIM approach first focuses on appropriate training and buy-in with senior management, then
through the chain of command to middle and first-line management, and finally to the developers
who staff self-directed teams on initial AIM pilot projects. Training and piloting in every organi-
zation is a must, and is a formal part of the recommended TSP introduction strategy [Humphrey
2011].1 After the initial AIM project pilots, the focus moves to the organizational level as the use
of TSP+ extends to the process group, which is responsible for CMMI implementation in an or-
ganization.
1
Further discussion of TSP introduction strategy appears in Leadership, Teamwork, and Trust: Building a Com-
petitive Software Capability by Watts S. Humphrey and James W. Over [Humphrey 2011].
AIM embodies the next generation of TSP process assets. While the overall structure of those as-
sets is unchanged from previous generations, AIM includes a new version of TSP assets designed
to maximize CMMI compatibility.
Use of TSP processes to support an engineering process group serves as an example of how to
adapt the standard TSP assets to a new organization and a new domain. This acknowledges pre-
vious organizations that successfully combined TSP and CMMI, especially within multiple
groups at the Naval Air Systems Command (NAVAIR), and reflects the SEI’s own internal use of
the TSP [Wall 2007].
These assets are summarized in the table below. Note that the following descriptions and tables in
this section are updated from those listed in Section 5 of the TSP+ Launch Notebook, and are pre-
sented in the order they appear in that document.2
2.2.1 Scripts
Script TSP+ Script Name (please see the TSP+ Launch Notebook) Page
Abbreviation Reference
POPS Overall process operations, the initiating process improvement script 3
POPS7 Process group formation 5
TOPS Team operations, overall guidance for TSP introduction 6
TOPS4 Post launch TSP and TSPm team operation 7
ANA Impact analysis 8
2
The TSP+ Launch Notebook is available to SEI Partners with a TSP license. For more information on becoming
an SEI Partner and obtaining a TSP license, see www.sei.cmu.edu/partners.
2.2.2 Forms
Form Form and Instructions Name Page
Abbreviation Reference
CCR Configuration Change Request 3
CHECKTMDR Checkpoint Team Member Data Review 6
CIBPS Project Configuration Item Baseline, Plan, and Status 11
CIR Configuration Identification Release 13
DAR Decision Analysis and Resolution 15
DEFECT Defect Reporting Form 18
GOAL Team Goals 20
2.2.3 Roles
Role Description Page Reference
Meeting Meeting roles and responsibilities 2
Inspection Inspection roles and responsibilities 3
TSP Coach TSP Coach responsibilities 4
Team Leader Team Leader responsibilities 6
Team Member General responsibilities of team members 8
Customer Interface Customer Interface Manager responsibilities 10
Manager
Design Manager Design Manager responsibilities 12
Implementation Implementation Manager responsibilities 14
Manager
Planning Manager Planning Manager responsibilities 16
Process Manager Process Manager responsibilities 18
Quality Manager Quality Manager responsibilities 20
Support Manager Support Manager responsibilities 22
2.2.4 Other
Grouping/Name Description Notes
Preparation checklists
PREPL Preparation for launch
PREPR Preparation for relaunch
Launch guidance
Launch coach Launch guidelines for the TSP coach
Marketing Launch guidelines for the marketing management
presentation
Other attendees (2) Launch guidelines for the TSP coach One for launches, one for re-
launches
Senior Management Launch guidelines for the senior management
presentation
Team leader (2) Launch guidelines for the team leader
Team members (2) Launch guidelines for team members
Other pre-launch assets
Initial contact letter TSP launch preparation
Preparation package TSP launch preparation material
cover letter
Preparation package TSP launch preparation material
instructions
Default guidelines
Planning guidelines SEI-provided benchmark planning metrics
Quality guidelines SEI-provided benchmark quality metrics
Executive assets
Plan assessment check- Team plan review questions; a quick start for an These assets can be found in Win-
list executive reviewing a TSP team’s plan ning with Software [Humphrey
Quarterly review Project review questions; a quick start for senior 2002].
checklist managers to probe the status of a TSP project
TSP introduction A generic procedure and timeline for TSP imple-
strategy mentation in an organization
Other specifications and assets
NOTEBOOK Storage for project artifacts
STATUS Management status report
SUMMARY Project analysis report
TSP workbook (individu- Automated individual and team (consolidated) Excel-based; provided by the SEI
al and consolidated) plans and actuals for size, effort, defects, and as part of the licensed TSP product
schedule; functionally equivalent versions of suite
items under Forms, above, are included in the
TSP Workbook
Checkpoint review A review of the project to date conducted by the
TSP coach or other process expert
Weekly meeting Minutes from weekly team meetings
minutes
The following material will provide in detail a CMMI practice-by-practice analysis of the artifacts
and the approach taken by AIM. Explanations and cautions are provided to help those who are
unfamiliar with AIM. At a minimum, this guidance can provide an appraiser with a starting list of
artifacts to request and an opening line of questioning, phrased for the AIM methodology.
Project planning and project monitoring and control are strongly implemented in the TSP and
AIM. The planning process is well defined and executed in the AIM launch process. The goal of
the launch is to provide each individual and the team as a whole with detailed development plans
for this cycle or iteration. This is accomplished in the launch meetings by developing a clear un-
derstanding of the requirements and a “conceptual design” for the product. The conceptual design
lists the parts of the product to be developed and describes how they will operate separately and as
an integrated product. The plan is developed based on the requirements and conceptual design.
The approach used by AIM and TSP for planning differs from the classic MS-Project, WBS
(work breakdown structure), or Gantt-chart approach. The AIM approach follows the concepts of
Lean Six Sigma and establishes a set of “value chain activities” and work products. Thus each
individual has a set of tasks and work products that represent the work to be done and the prod-
ucts to be developed. This list of tasks and activities is presented in order of execution. Thus task
one is worked first, task two second, and so forth. This list of tasks represents the WBS and is
carefully established and maintained (monitored and controlled) as the project executes.
In addition to focusing on value chain activities, the planning process employs “inch pebble” de-
composition. Each task is 8-10 hours of duration. This inch pebble decomposition allows for
earned value tracking and load balancing and early warning on a near-real-time basis.
The following table lists the elements of the Project Planning process area employed in the AIM
approach.
The following table lists the elements of the Project Monitoring and Control (PMC) process area
employed in the AIM approach.
The following table lists the elements of the Integrated Project Management + IPPD (IPM)
process area employed in the AIM approach.
Support IPM GP 2.6 Place designated work LOGCI of the project Configuration and data man-
manager products of the inte- notebook if the notebook agement are planned during
role and grated project man- is put under formal CM launch preparation, CM
role teams agement process un- otherwise appropriate processes are observed, and
der appropriate levels level of control. planning CIs are entered in
of control. The Support Manager role form LOGCI. Formal or in-
is responsible for CM for formal CM methods may be
the project. The work appropriate.
products from the launch
will be CIs in form LOGCI
and placed under appro-
priate control. The project
notebook may be under
informal configuration
control.
Typically, you would have
to look at the CM system
supported by the project or
organization (a protected
folder on a drive, or full
CM with CVS).
IPM GP 2.7 Identify and involve RSIM (Relevant Stake-
the relevant stake- holder Involvement Matrix)
holders of the inte- PREPL filled out, LAU9
grated project man- meeting report
agement process as Team meetings presenta-
planned. tions and minutes
Status meetings presenta-
tion and minutes
IPM GP 2.8 Monitor and control PREPL, PREPR shows The coach is responsible for
the integrated project launch is planned. ensuring that the planning
management process Launch meeting minutes process embedded in the
against the plan for in form MTG for each launch is on track and fol-
performing the meeting lowed.
process and take ap- Combine this with launch
propriate corrective artifacts.
action. Weekly meeting minutes
The following table lists the elements of the Risk Management (RM) process area employed in
the AIM approach.
TSP/PSP CMMI CMMI PA: RSKM Direct Artifact Guidance
Reference Risk Management
RSKM Establish and maintain the plan Schedule and agenda Planning and execution of
GP 2.2 for performing the risk man- for the launch and the the launch includes plan-
agement process. team meetings. ning for risk management in
Launch meeting 7 is meeting LAU7; weekly
dedicated to risk and meetings have a standard
risk management. step to evaluate & update
PREPL checklist risks.
(filled out) The team meetings are
Attendee list (usually attended by all on the team
in meeting 9 presen- and have a schedule and
tation) agenda.
Script WEEK Risks are part of the man-
agement status meetings;
see Specification STATUS.
RSKM Provide adequate resources for PREPL filled out Time and resources for Risk
GP 2.3 performing the risk manage- Management are planned
ment process, developing the for in the launch and the
work products, and providing weekly meetings and status
the services of the process. meetings.
Tasks may also be found in
individual plans for work
associated with the execu-
tion of a risk mitigation plan.
RSKM Assign responsibility and au- Team Lead role is The team lead is responsi-
GP 2.4 thority for performing the specifically charged ble for leading the team
process, developing the work with responsibility; through the risk assessment
products, and providing the may delegate as in LAU7 and leading the
services of the risk manage- shown in ITL (IRTL in team through the team and
ment process. SEI workbooks) management meetings.
RSKM Train the people performing or TSP TL Training in- TSP Team leader training
GP 2.5 supporting the risk manage- structs on LAU7
ment process as needed. OJT for TL and the
team as necessary
RSKM Place designated work products LOGCI if the decision Configuration and data
GP 2.6 of the risk management process is made to put the management are planned
under appropriate levels of project notebook during launch preparation,
control. under formal CM. CM processes are ob-
Otherwise the project served, and planning CIs
notebook will be put are entered in form LOGCI.
under appropriate Formal or informal CM me-
level of control. thods will be chosen.
The Support Manager
role is responsible for
CM for the project.
The work products
from the launch will
be CIs in form LOGCI
and placed under
appropriate control.
The project notebook
Typically, you would
have to look at the
CM system supported
by the project or or-
ganization (a pro-
tected folder on a
drive, or full CM with
CVS).
RSKM Identify and involve the relevant RSIM The launch process identi-
GP 2.7 stakeholders of the risk man- Launch scripts fies the major planning
agement process as planned. PREPL filled out, stakeholders. RSIM pro-
LAU9 meeting report vides a comprehensive set
of stakeholders and in-
volvement.
TSP Coach RSKM Monitor and control the risk PREPL, PREPR The team launch process
role GP 2.8 management process against shows launch is produces the plan, including
TSP TL role the plan for performing the planned. the risk plan.
process; and take appropriate Launch meeting mi- The coach is responsible for
corrective action. nutes in form MTG for seeing that the risk planning
each meeting process embedded in the
Combine this with launch is on track and fol-
launch artifacts. lowed.
Weekly meeting mi-
nutes
Checkpoint
Team meeting sche-
dule
RSKM Objectively evaluate adherence Checkpoint report The TSP Coach will perform
GP 2.9 of the risk management process TSP Coach involve- a Checkpoint to evaluate
against its process description, ment pre-launch process and work products.
standards, and procedures; (PREPL/PREPR filled During the launch, the
address noncompliance. out), during the coach guides process fideli-
launch (LAU meeting ty for RSKM. As the project
minutes) and after executes, the team leader,
(LAUPM). and planning and process
See the role of the PG managers, objectively eva-
(Process Group) luate.
Coaching Manager. When the Process Group
Coaching Manager (PG) is formed the Coach-
report ing Manager role will objec-
tively evaluate the launch
process and artifacts for
each launch.
STATUS RSKM Review the activities, status, STATUS report to
spec GP 2.10 and results of the risk manage- higher level manage-
TL role ment process with higher level ment
management ; resolve issues.
RSKM Establish and maintain the The TSP+ role of See the PG Support Man-
GP 3.1 description of a defined risk Process Group Sup- ager and PG Process Man-
management process. port Manager is re- ager roles.
sponsible for estab-
lishing and
maintaining the
OSSP. The OSSP will
contain the launch
processes, which are
the main planning
processes.
The Launch Notebook
(PREPL, PREPR,
LAU1-9, WEEK)
RSKM Collect work products, meas- The Process Asset The TSP+ has been ex-
GP 3.2 ures, measurement results, and Library and asso- panded to include a PG
improvement information de- ciated collection me- Process Asset and Data
rived from planning and per- chanisms Repository Manager.
forming the RSKM process to The organizational
support the future use and im- infrastructure (includ-
provement of the organization’s ing the PAL and the
processes and process assets. measurement reposi-
tory) is developed by
the Process Group.
See OPF, OPD.
The guidance documents that follow were developed from the PSP/TSP and were not augmented
with tools, methods, and procedures representation any single development domain or customer
use case. There are practices and direct artifacts missing or only partially fulfilling CMMI expec-
tations. This is understandable as the organization will have made or will need to make implemen-
tation decisions specific to the organization’s development domain and environment. For exam-
ple, the configuration management system can be implemented by simple manual methods or by
employing a fully automated CM system.
The following table lists the elements of the Requirements Management (REQM) process area
employed in the AIM approach.
The following table lists the elements of the Requirements Development (RD) process area em-
ployed in the AIM approach.
RD GP Place designated work prod- LOGCI for SRS or Configuration and data
2.6 ucts of the requirements de- equivalent management are planned
velopment process under The Support Manager during launch preparation,
appropriate levels of control. role is responsible for CM processes are ob-
CM for the project. The served, and planning CIs
work products from the are entered in form LOGCI.
launch will be CIs in
form LOGCI and placed
under appropriate con-
trol.
The project notebook
Typically, this informa-
tion would appear in the
CM system supported
by the project or organi-
zation (a protected
folder on a drive, or full
CM with CVS).
RD GP Identify and involve the rele- RSIM (Relevant Stake-
2.7 vant stakeholders of the re- holder Involvement
quirements development Matrix) for ANA, SRS
process as planned. Role Assignment Matrix
ROLEMX
Customer Interface
Role
RD GP Monitor and control the re- Filled-in WEEK forms The launch and the weekly
2.8 quirements development showing customer inter- meetings form the basis for
process against the plan for face role reports, rep- monitoring the RD activities.
performing the process and lans, plans resulting
take appropriate corrective from relaunches
action.
RD GP Objectively evaluate adhe- Checkpoint report The TSP Coach will perform
2.9 rence of the requirements TSP Coach involvement a Checkpoint to evaluate
development process against pre-launch process and work products.
its process description, stan- (PREPL/PREPR filled During the launch, the
dards, and procedures, and out), during the launch Coach guides process fideli-
address noncompliance. (LAU meeting minutes), ty, including RD. As the
and after (LAUPM) project executes, the Team
Leader, and Planning and
Process managers objec-
tively evaluate.
When the Process Group
(PG) is formed the Coach-
ing Manager role will objec-
tively evaluate the launch
process and artifacts for
each launch.
The following table lists the elements of the Technical Solution (TS) process area employed in the
AIM approach.
TS GP Establish and maintain the Scripts HLD and IMP, See the Design Manager role
2.2 plan for performing the and LAU and REL, form activities and plan.
technical solution process. SUMS
TS GP Provide adequate re- Design Manager role Design activities during the
2.3 sources for performing the plan from LAU3, LAU4, launch and tasks in the plan.
technical solution process, and LAU6, recorded in
developing the work prod- TASK and SCHEDULE
ucts, and providing the
services of the process.
TS GP Assign responsibility and PREPL/PREPR, LAU2 See the Design Manager role.
2.4 authority for performing role assignments, Team
the process, developing Leader, and Design
the work products, and Manager roles
providing the services of
the technical solution
process.
TS GP Train the people perform- PSP training, as well as Design templates from PSP
2.5 ing or supporting the tech- on-the-job training pro- training map fairly well to com-
nical solution process as vided to Design Manager ponent-level technical solution
needed. role by TSP Coach or requirements. Typical TSP
Team Leader as an ad- teams augment HLD and IPM
junct to the role descrip- processes with their own local
tion knowledge.
There is no guidance or refer-
ence on alternative solutions or
evaluation criteria.
TS GP Place designated work LOGCI for SRS or equiv- Configuration and data man-
2.6 products of the technical alent agement are planned during
solution process under The Support Manager launch preparation. CM
appropriate levels of con- role is responsible for CM processes are observed and
trol. for the project. The work planning CIs are entered in
products from the launch form LOGCI.
will be CIs in form LOGCI
and placed under appro-
priate control. Other arti-
facts will be placed under
informal control.
The project notebook
Typically, this information
would appear in the CM
system supported by the
project or organization (a
protected folder on a
drive, or full CM with
CVS).
Design TS GP Identify and involve the RSIM (Relevant Stake- Customer Interface role, De-
Manager 2.7 relevant stakeholders of holder Involvement Ma- sign Manager, and possibly the
role the technical solution trix) for ANA, SRS Team Leader interact with
process as planned. Role Assignment Matrix design stakeholders and report
ROLEMX to the team weekly (and fill in
WEEK forms).
TS GP Monitor and control the Filled-in WEEK forms
2.8 technical solution process showing Design Manager
against the plan for per- role reports, replans, and
forming the process; and plans resulting from re-
take appropriate corrective launches
action.
TS GP Objectively evaluate adhe- Checkpoint report The TSP Coach will perform a
2.9 rence of the technical TSP Coach involvement Checkpoint to evaluate
solution process against pre-launch process and work products.
its process description, (PREPL/PREPR filled During the launch, the Coach
standards, and proce- out), during the launch guides process fidelity includ-
dures; address noncom- (LAU meeting minutes) ing TS. As the project ex-
pliance. and after (LAUPM) ecutes, the Team Leader, and
Planning and Process Manag-
ers objectively evaluate.
When the Process Group (PG)
is formed the Coaching Man-
ager role will objectively eva-
luate the launch process and
artifacts for each launch.
TS GP Review the activities, sta- TASK plans that show The STATUS specification
2.10 tus, and results of the the TS activities should does not address review of TS
technical solution process be included in the Design activities explicitly; however as
with higher level manage- Manager role activities. a practical matter, TS activities
ment ;resolve issues. These can be reviewed are typically included in TASK
with upper management. plans that are regularly re-
viewed.
TS GP Establish and maintain the The TSP+ role of See the PG Support Manager
3.1 description of a defined Process Group Support and PG Process Manager
technical solution process. Manager is responsible roles.
for establishing and
maintaining the OSSP.
The OSSP will contain
the launch processes,
which are the main plan-
ning processes.
The Launch Notebook
(PREPL, PREPR, LAU1-
9, WEEK)
TS GP Collect work products, SRSs, ERSs, impact The TSP+ has been expanded
3.2 measures, measurement analyses, PIPs, and data to include a PG Process Asset
results, and improvement contained in the project and Data Repository Manager.
information derived from NOTEBOOK regarding
planning and performing requirements manage-
the technical solution ment activities
process to support the The Process Asset Li-
future use and improve- brary and associated
ment of the organization’s collection mechanisms
processes and process The organizational infra-
assets. structure (including the
PAL and the measure-
ment repository) is de-
veloped by the Process
Group; see OPF, OPD.
The following table lists the elements of the Product Integration (PI) process area employed in the
AIM approach.
PI GP 3.1 Establish and maintain the The TSP+ role of See the PG Support Man-
description of a defined Process Group Support ager and PG Process Man-
product integration process. Manager is responsible ager roles.
for establishing and
maintaining the OSSP.
The OSSP will contain
the processes, scripts,
and forms.
The Launch Notebook
(PREPL, PREPR, LAU1-
9, WEEK)
PI GP 3.2 Collect work products, Actual integration plans, The TSP+ has been ex-
measures, measurement PIPs, and data con- panded to include a PG
results, and improvement tained in the project Process Asset and Data
information derived from NOTEBOOK regarding Repository Manager.
planning and performing the integration activities
product integration process SRSs, ERSs, impact
to support the future use analyses, PIPs, and data
and improvement of the contained in the project
organization’s processes NOTEBOOK regarding
and process assets. requirements manage-
ment activities
The Process Asset Li-
brary and associated
collection mechanisms
The organizational infra-
structure (including the
PAL and the measure-
ment repository) is de-
veloped by the Process
Group; see OPF, OPD.
The following table lists the elements of the Verification (VER) process area employed in the
AIM approach.
The following table lists the elements of the Validation (VAL) process area employed in the AIM
approach.
Scripts VAL SP Establish and maintain System Test Plan (called for The Customer Interface
DEV, 1.3 procedures and criteria for in TEST3) including usability Manager clearly has
MAINT, validation. tests responsibility for advocat-
REQ, ing the customer point of
ANA, view, while the Test
TEST3 Manager has responsi-
Customer bility for developing and
Interface executing these tests
Manager internally. External tests
and Test (e.g., on-site customer
Manager acceptance tests) proba-
role speci- bly would reside with the
fications Customer Interface role,
or perhaps the Team
Leader.
There is no standard
template or criteria for
validation test proce-
dures, nor is there specif-
ic guidance for the Cus-
tomer Interface and Test
Managers to develop
such procedures and
criteria.
VAL SG 2 The product or product Two TSP activities, proto-
components are validated typing and system test-
to ensure that they are ing, seem to address the
suitable for use in their intent of validation. How-
intended operating envi- ever, the direction in the
ronment. existing TSP process
assets is sparse and
scattered.
Scripts VAL SP Perform validation on the Prototypes used to validate Direction in the specified
REQ, 2.1 selected products and important specification ques- scripts is extremely high
ANA, product components. tions; outputs of other vali- level, and only partially
TEST3 dation activities identified by addresses validation
Forms the Customer Interface role issues in the form of
TESTLOG, usability tests.
LOGT, There is no standard
LOGD, template or criteria for
TASK recording prototype re-
Customer sults or outcomes. There
Interface is no clear delineation in
and Test TESTLOG between vali-
Manager dation and other kinds of
role speci- system tests.
fications
Scripts VAL SP Analyze the results of the PM results The weekly team meeting
REQ, 2.2 validation activities. WEEK form – the Customer and postmortem activi-
ANA, Interface Role manager ties, while clearly provid-
TEST3, reports on the status of re- ing a venue for such
WEEK, quirements development analyses, provide no
PM specific guidance to the
Customer relevant role managers.
Interface There is no standard
Manager template or criteria for
and Test validation data analysis.
role speci-
fication.
VAL GP Objectively evaluate adhe- Checkpoint report and The TSP Coach will per-
2.9 rence of the validation postmortem report form a Checkpoint to
process against its process The Coach, Team Lead, and evaluate process and
description, standards, and Process Manager review work products.
procedures; address non- Customer Interface and During the launch, the
compliance. Quality Manager reports and coach guides process
validation results fidelity, including VAL. As
the project executes, the
Team Leader, and Plan-
ning and Process Man-
agers objectively eva-
luate. The Coach will
perform a formal objec-
tive evaluation in the
checkpoint and the PM.
When the Process Group
(PG) is formed, the
Coaching Manager role
will objectively evaluate
the launch process and
artifacts for each launch.
VAL GP Review the activities, sta- TASK plans that show the VAL activities are typical-
2.10 tus, and results of the VAL activities included in ly included in TASK plans
validation process with various role and team mem- that are regularly re-
higher level management ; ber activities. These can be viewed.
resolve issues. reviewed with upper man-
agement.
VAL GP Establish and maintain the The TSP+ role of Process See the PG Support
3.1 description of a defined Group Support Manager is Manager and PG process
validation process. responsible for establishing manager roles.
and maintaining the OSSP.
The OSSP will contain the
processes, scripts, and
forms.
The Launch Notebook
(PREPL, PREPR, LAU1-9,
WEEK)
VAL GP Collect work products, NOTEBOOK regarding veri- The TSP+ has been
3.2 measures, measurement fication activities. expanded to include a
results, and improvement The Process Asset Library PG Process Asset and
information derived from and associated collection Data Repository Manag-
planning and performing mechanisms er.
the validation process to The organizational infra-
support the future use and structure (including the PAL
improvement of the organ- and the measurement repo-
ization’s processes and sitory) is developed by the
process assets. Process Group; see OPF,
OPD.
The following table lists the elements of the Organizational Process Focus (OPF) process area
employed in the AIM approach.
The following table lists the elements of the Organizational Process Definition + IPPD (OPD)
process area employed in the AIM approach.
RSIM, OPD GP Assign responsibility and au- The PG TSP plan will
SRAM, 2.4 thority for performing the have the role assign-
ROLE process, developing the work ment also in form
products, and providing the ROLE and SRAM.
services of the organizational
process definition process.
TRNM, OPD GP Train the people performing or TRNM (Training Ma-
LOGTRNM 2.5 supporting the organizational trix) and LOGTRNM
process definition process as PSP and TSP training
needed. records for both full-
and part-time PG
members
LOGCI, OPD GP Place designated work prod- OSSP, PAL, Mea- The OPD work products OSSP,
NOTEBOOK 2.6 ucts of the organizational surement and other PAL, and Measurement Reposi-
process definition process OPD work products tory will all be CIs in the CM
under appropriate levels of will be configuration system and placed under ap-
control. items in the CM sys- propriate levels of control.
tem.
Form LOGCI.
As with any other TSP
team, the informally
controlled items will
reside in the project
notebook.
RSIM, OPD GP Identify and involve the rele- RSIM
RSAM 2.7 vant stakeholders of the orga- PG TSP Plan
nizational process definition as
planned.
WEEK, PM OPD GP Monitor and control the orga- PG TSP Plan moni- The main mechanism for moni-
2.8 nizational process definition tored using PMC toring and controlling is the
process against the plan for Filled-in WEEK form PMC of TSP plans.
performing the process and and weekly meeting See the management meetings
take appropriate corrective minutes from the PG and presentations. In some
action. team ways Checkpoint and PM also.
CHECKPOI OPD GP Objectively evaluate adhe- PG Checkpoint The main mechanism for objec-
NT 2.9 rence of the organizational tive evaluation is the Check-
process definition process point.
against its process description,
standards, and procedures;
address noncompliance.
STATUS OPD GP Review the activities, status, PG management
2.10 and results of the organiza- reviews
tional process definition
process with higher level man-
agement ; resolve issues.
CIBPS OPD GP Establish and maintain the The OSSP will include The PG Process Manager
3.1 description of a defined orga- the organizational working with the PG Support
nizational process definition process definition Manager, and PG Process
process. process. The OSSP Asset and Data Repository
will be defined using Manager will establish and
the CIBPS (Configura- maintain the description of the
tion Item Baseline, organization’s process definition
Plan, and Status) form process using the established
and maintained using CM process.
the CM process.
Process OPD GP Collect work products, meas- The Process Asset The TSP+ has been expanded
Group roles 3.2 ures, measurement results, Library and asso- to include a PG Process Asset
and respon- and improvement information ciated collection me- and Data Repository Manager
sibilities derived from planning and chanisms who will be responsible for the
performing the OPD process The organizational design and development of the
to support the future use and infrastructure (includ- PAL.
improvement of the organiza- ing the PAL and the
tion’s processes and process measurement reposi-
assets. tory) is developed by
the Process Group.
The following table lists the elements of the Organizational Training (OT) process area employed
in the AIM approach.
The following table lists the elements of the Configuration Management (CM) process area em-
ployed in the AIM approach.
The following table lists the elements of the Process and Product Quality Assurance (PPQA)
process area employed in the AIM approach.
There is a sophisticated measurement and analysis system incorporated into the TSP+. The Im-
plementation guide will describe this system and how it should be adapted to satisfy the CMMI
practices
MA SP Specify how measurement Individual and con- The Chart Controls portion
1.4 data will be analyzed and solidated workbooks, of the PROJECT Tab in the
reported. particularly charts electronic TSP workbooks
and graphs provides charts and analysis
Script PM and of the measure.
WEEK, forms
WEEK, SUMP,
SUMQ, and the
NOTEBOOK and
STATUS specifica-
tions
MA SG 2 Measurement results, which
address identified information
needs and objectives, are
provided.
MA SP Obtain specified measure- Individual and con- Data collected by practition-
2.1 ment data. solidated workbooks ers in their individual work-
Filled-in forms books
SUMS, LOGT, One of the purposes of the
LOGD, and TASK planning manager role is to
ensure that the members of
the team follow the process
in collecting and reporting
actual data in real time. (The
coach plays a role here as
well.)
MA SP Analyze and interpret mea- Analysis in individual In general actuals shall be
2.2 surement data. and consolidated compared to planned to see
workbooks if the variance is within ac-
Management pres- ceptable tolerance.
entations The data analysis completed
Checkpoint and in support of the projects
postmortem analysis shall be in the workbooks,
Forms WEEK (and the checkpoints and
any associated cycle/project postmortem.
charts and graphs), The analysis reported during
SUMP, SUMQ, and the weekly status meetings
actual NOTEBOOK with management. In addi-
data and STATUS tion to the information pre-
presentations. sented off the PROJECT
Tab of the workbook, the
project established goals
shall also be reported.
MA SP Manage and store measure- Individual and team Generally, all data collected
2.3 ment data, measurement workbooks including (both base and derived), the
specifications, and analysis weekly summary resulting analysis as re-
results. data (form WEEK), ported to management shall
PM results, and of be stored in accordance with
actual NOTEBOOK the project plan or some
and STATUS pres- organizational directive.
entations. The data is stored and daily
backups of the server files
are maintained by the sys-
tem administrators according
to good configuration man-
agement practices.
MA GP Train the people performing or PSP/TSP training TSP and AIM training
2.5 supporting the measurement records The TSP has training re-
and analysis process as quirements for TSP team
needed. members. All SEI-authorized
PSP/TSP courses address
the principles for measure-
ment needed for specific
roles (e.g., leader, member,
developer)
Comprehensive SEI training
and authorization for TSP
coaches.
MA GP Place designated work prod- Stored project note- The planning manager is
2.6 ucts of the measurement and book using appropri- responsible for placing all
analysis process under ap- ate configuration project planning artifacts into
propriate levels of control management prac- the project notebook. The
tices content of the project note-
book is defined in specifica-
tion NOTEBOOK.
The support manager is
responsible for developing a
plan for the management of
all project data identified in
the specification
NOTEBOOK. This is usually
accomplished by designating
a specific project folder on a
drive or using a web-based
file-sharing system; levels of
control are handled by set-
ting access permissions.
MA GP Identify and involve the rele- RSIM RSIM provides a compre-
2.7 vant stakeholders of the mea- Launch scripts hensive set of stakeholders
surement and analysis PREPL filled out, and involvement.
process as planned. LAU9 meeting report
MA GP Monitor and control the mea- Launch meeting M&A is embedded in the
2.8 surement and analysis minutes, workbooks, AIM business rhythm. Col-
process against the plan for and launch meeting lection of data is monitored
performing the process and 9 closely by the coach, plan-
take appropriate corrective Weekly meeting ning manager, and the team
action minutes leader.
Management meet- Management monitors M&A
ing minutes by reviewing project data
weekly/
MA GP Objectively evaluate adhe- Checkpoint report The TSP coach will perform
2.9 rence of the measurement See the role of the a Checkpoint to evaluate
and analysis process against PG (Process Group) process and work products,
its process description, stan- Coaching Manager. including M&A
dards, and procedures; ad- Coaching Manager During the launch, the coach
dress noncompliance. report guides process fidelity for
TSP coach involve- M&A. As the project ex-
ment pre-launch ecutes, the team leader and
(PREPL/PREPR planning and process man-
filled out), during the agers objectively evaluate.
launch (LAU meeting When the Process Group
minutes), and after (PG) is formed the Coaching
(LAUPM) Manager role will objectively
TSP checkpoint evaluate the launch process
results and artifacts for each launch.
MA GP Establish and maintain the The OSSP will con- The TSP+ role of Process
3.1 description of a defined mea- tain the standard Group Support Manager is
surement and analysis processes, which responsible for establishing
process. include M&A/ and maintaining the OSSP.
The Launch Note- The OSSP will contain the
book (PREPL, launch processes, which are
PREPR, LAU1-9, the main planning processes
WEEK) along with associated data
collection and reporting.
The Launch Notebook
(PREPL, PREPR, LAU1-9,
WEEK)
MA GP Collect work products, meas- Project It is the responsibility of all
3.2 ures, measurement results, NOTEBOOKS (in- project personnel to includ-
and improvement information cludes weekly ing management to report
derived from planning and SUMS, SUMP, lessons learned and/or
performing the measurement SUMQ, WEEK process improvements as-
and analysis process to sup- project status, sociated with MA activities.
port the future use and im- SUMMARY reports This information shall be
provement of the organiza- and PM results) reported to the process
tion’s processes and process Lessons Learned group.
assets. and Process Im- All projects shall report
provements. process improvements on a
PIP Form. In particular
projects need to use their
postmortem time as an op-
portunity for process im-
provement and lessons
learned.
The following table lists the elements of the Decision Analysis and Resolution (DAR) process
area employed in the AIM approach.
[Humphrey 2011]
Humphrey, W. & Over, J. Leadership, Teamwork, and Trust: Building a Competitive Software
Capability. Addison-Wesley, 2011 (ISBN: 0321624505).
[Wall 2007]
Wall, D.; McHale, J; & Pomeroy-Huff, M. Case Study: Accelerating Process Improvement by
Integrating the TSP and CMMI (CMU/SEI-2007-TR-013). Software Engineering Institute, Car-
negie Mellon University, 2007. www.sei.cmu.edu/library/abstracts/reports/07tr013.cfm
Public reporting burden for this collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and
maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information, in-
cluding suggestions for reducing this burden, to Washington Headquarters Services, Directorate for information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, Arlington, VA
22202-4302, and to the Office of Management and Budget, Paperwork Reduction Project (0704-0188), Washington, DC 20503.
1. AGENCY USE ONLY 2. REPORT DATE 3. REPORT TYPE AND DATES COVERED
17. SECURITY CLASSIFICATION OF 18. SECURITY CLASSIFICATION 19. SECURITY CLASSIFICATION 20. LIMITATION OF ABSTRACT
REPORT OF THIS PAGE OF ABSTRACT
UL
Unclassified Unclassified Unclassified
NSN 7540-01-280-5500 Standard Form 298 (Rev. 2-89) Prescribed by ANSI Std. Z39-18 298-102