CMU
Master of Software Engineering
Carnegie Mellon University
Seminar
on Software Process, Spr 02
Critique of Watts Humphrey’s
Introduction to the Team Software Process
Prepared on 4/12/2002 by
Table of Contents
Critique of Introduction
to the Team Software Process
Mike Lester
April 10, 2002
The Team Software Process (TSP) is an industrial process intended for large teams designing large complex software systems. Quality, productivity, and team performance are emphasized by the TSP, which defines a prescriptive process (the “how”) for implementing some of the Software Capability Maturity Model’s concepts (the “what.”)
The TSPi, presented in the book reviewed, is a subset of TSP designed for use in software engineering courses such as the CMU MSE Studio program. Both TSP and TSPi build upon practices of the prerequisite Personal Software Process (PSP). This paper will summarize some of the key elements of TSPi, such as the motivation for TSP, its lifecycle, critical workflows, metrics, and principles.
There are many reasons that software projects fail, and most of the reasons have nothing to do with software or technology. Management issues such as ineffective communication and teamwork are frequently at flaw. Regarding teamwork, Humprey says, “Merely giving a group of engineers a job does not automatically produce a team…Teams don’t just happen, and superior team performance is not an accident.”
The TSP provides a needed process framework for team development. It does so by establishing common goals for the project, emphasizing planning, and fostering communications by establishing well-defined roles for team members. Other proven software engineering principles found in the SW CMM are instantiated within the TSP.
Having defined roles for the project eases planning and execution by reducing ambiguity over who gets which tasks. Roles in TSP are summarized in Table 1.
|
Role |
Goals |
Activities |
|
-Build and maintain an
effective team. -Motivate team members to
work aggressively on the project -Resolve all issues team
members bring forward -Keep the instructor fully
informed about the team’s progress -Ensure that
instructor/client is informed of any team problems -Perform effectively as team’s meeting facilitator |
-Motivate team members. -Run weekly team meeting -Report weekly status -Help team to allocate
tasks -Act as facilitator and
timekeeper for team meetings -Maintain the project
notebook -Lead team in producing dev
cycle report. -Act as development engineer. |
|
|
-Produce a superior product -Fully utilize team members’ skills and abilities |
-Lead team in producing dev
strategy. -Lead team in producing
size and time estimates -Lead dev of SRS -Lead team in producing
high-level design -Lead team in SDS -Lead team in implementing
product -Lead team in developing
build, integration, and system test plans -Lead team in developing
the test materials and running the tests -Lead team in producing
product’s user documentation -Participate in dev cycle report |
|
|
-Produce a complete,
precise, and accurate plan for team and each team member -Accurately report team status each week |
-Lead team in producing the
task plan for next dev cycle -Lead team in producing
schedule for next dev cycle -Lead in balancing/leveling
the plan -Track team’s progress
against plan -Participate in producing
the dev cycle report. -Act as a development engineer. |
|
|
-All team members
accurately report and use TSPi process data -Team faithfully follows
TSPi quality plan & produces a quality product -All team inspections are
properly moderated and reported -Team meetings are accurately reported and in the proj notebook. |
-Lead team in producing and
tracking quality plan -Alert the team lead and
instructor to quality problems -Lead team in defining and
documenting processes and in maintaining PIPs -Eestablish and maintain
team dev standards -Review and approve all
products before submission to configuration control board. -Act as team’s inspection
moderator -Act as recorder in all
team meetings -Partcipate in producing
dev cycle report -Act as a dev engineer |
|
|
-Team has suitable tools
and methods to support its work.
Ex: change management system,
issue-tracking, config management, etc -No unauthorized changes
are made to baselined products -All team’s risks and
issues are recorded in issue-tracking system -Team meets its reuse goals for dev cycle |
-Lead team in determining
its support needs and obtaining tool/facilities -Chair the CCB and manage
change control system -Manage the configuration
management system -Maintain the system
glossary. (a listing of all the system names) -Maintain the team’s issue
and risk-tracking system -Act as team’s reuse
advocate -Participate in producing
the development cycle report |
Table 1. TSP Roles, Goals, and Activities
Roles are explained in greater detail in the book, which dedicates a chapter to each role and gives pointers on how to effectively perform each role. The rest of the book details the TSP process and activities, which are presented here after establishing some conventions.
As might be expected, there are many checklists and process scripts in the book. Rather than reproduce them in this critique, the following shorthand is used. Activities are named in italics. Sequence will be shown by connecting activities with arrows (Y), similar to the formal specifications language Communicating Sequential Processes (CSP). Important points from each activity will be presented.
Like Rational Unified Process (RUP) and Extreme Programming (XP), the TSP reduces total project risk by delivering software incrementally. At any given time, the risk of incorrect requirements is limited to the current increment. Integration efforts for the increment are also smaller than with a “big-bang” waterfall project. Much like RUP, TSP advocates essentially a “mini-waterfall” workflow for each cycle, performing the following activities repeatedly until the project is finished.
Cycle = = Launch Y Strategy Y Plan Y Requirements Y Design Y Implementation Y Test Y Postmortem Y (Cycle | Finished)
First is the launch, which builds team agreement on what a successful project would look like. Roles are chosen, and individual and team goals are set. The following script is followed for launch.
Launch
= = Assign Roles Y Develop Team & Member Goals Y
Conduct Team Meetings Y Develop Metrics Requirements Y
Start Project
After Launch, the project is started in the Development Strategy activity.
This activity’s purpose is to devise a strategy for doing the work, create a conceptual product design, and make prelimary estimates of product size and development time. Strategy is prerequisite to planning, and includes such activities as conceptual design, risk identification and management, and reuse strategy. The script, one of TSP’s longest, is:
Strategy = = Strategy OverviewY Establish Strategy Criteria Y Produce Conceptual Design Y Select Development Strategy Y Produce Preliminary Size Estimate (LOC) Y Produce Preliminary Time Estimate Y Assess Risks Y Document Strategy Y Update Development Strategy Y Produce CM Plan
True to guidance about inspections, Humphrey recommends keeping inspection rates less than 200 LOC per hour. For requirements documents, he recommends inspecting no more than 2 single-spaced text pages per hour. For design reviews, 5 pages per hour is the maximum.
Once a strategy determines “were the project wants to go,” a map is needed to point the direction. Perhaps one of the most important activities in the plan is the quality plan, which establishes metrics to be tracked. Some recommend metrics include defects per kLOC, review rates, inspection rates, and many more. The development plan script follows.
Project
Planning = = Planning overview Y Enter Size Estimates Y
Produce Task Plan Y Produce Quality Plan Y Produce Individual
Engineer Plans Y Balance/Level Workload
Requirements are a “clear and unambiguous description of that the product is to be, including precise criteria for evaluating the finished product to ensure it does what it is supposed to do.” Producing the Software Requirements Specification is important, but the requirements development PROCESS is more important, as it is in requirements meetings that the team gains a common understanding of what is planned to build. Everyone must participate for the team to be successful.
Requirements = = Requirements Process Overview Y Need Statement Review Y Need Statement Clarification Y Requirements Tasks Y Task Allocation Y Requirements Documentation Y System Test Plan Y Requirements and Test Plan Inspection Y Requirements Update Y User SRS Review Y Requirements Baseline
TSPi does not prescribe a particular design method over another, but does present some things to consider:
· Design Standards (naming conventions, interface formats, etc)
· Design Representation Standards
· Design for Reuse
· Designing for Usability
· Designing for Testability
Of course, no chapter of a Watts Humphrey book would be complete without a process script.
Design == Design Process Review Y High-Level Design Y Design Standards Y Design Tasks Y Task Allocation Y Design Specification Y Integration Test Plan Y Design and Integration Test Plan Inspection Y Design Update Y Update Baseline
After verifying the design completion criteria, implementation can start. Implementation standards such as coding standards and defect tracking should be created to extend standards defined during the design phase
Implementation = = Imp Process Overview Y Imp planning Y task allocation Y detailed design Y unit test plan Y test development Y detailed-design inspection Y code Y code inspection Y unit test Y component quality review Y component release
Integration and System Testing are intended to assess the product; not to fix it. Integration test verifies that the system was built properly, with all parts present, and functioning together. The System test examines the product against its system requirements.
Test = = Test Process Overview Y Test Development Y Build product Y Integration Tests Y System Test Y Documentation
To quote an old idiom, “it ain’t over until the paperwork’s finished.” A postmortem is required at the end of each cycle to review the team’s work and ensure all necessary tasks are complete and data is recorded. The data will be crucial for continuous improvement. It is in this activity that most process improvement proposals are written.
Postmortem = = Postmortem Process Overview Y Review Process Data Y Evaluate Role Performance Y Prepare Cycle-n Report Y Prepare Role Evaluation using PEER evaluation
The TSPi’s iterative, data and metrics-based approach to sofware development provides a good example of how things can be done for those of us who have trouble defining effective processes. Even if an organization does not adopt TSP, the principles and examples could be valuable resources to apply towards software process improvement efforts.
Though Humphrey makes a strong case for all of the data, the number of metrics suggested for collection in TSPi is formidible-- too extensive for a class project to collect manually. Mentioned in the book is the “TSP Tool” which is supposed to automate some of the tracking and collecting of metrics. It would be useful if more detail were provided about this tool, including studies of efficiencies gained.