INFO 637 Lecture #10 2
TSP Overview
The TSP is designed for teams of up to 20 people Here we used TSPi, which uses the same
concepts, but designed for a team of 4-8 people
TSPi is based on a waterfall-like life cycle model, adapted for cyclical development Features are developed in cycles, which each
build on previous cycles
INFO 637 Lecture #10 3
TSP Steps Within Each Cycle
StrategyPlanRequirementsDesignImplementationTestPostmortem
INFO 637 Lecture #10 4
TSP Structure
The structure of the TSP is designed to avoid most common problems associated with team formation and lack of peer review Everyone is assumed to be a software
developer (Development Engineer), and also take on an additional role
INFO 637 Lecture #10 5
TSP is Implementation-Independent
TSP doesn’t assume any type of development methodology Object oriented Procedural development
Any kind of analysis techniques or models could be used Use cases, formal specification, ERD, DFD,
class diagram, interaction diagrams, etc.
INFO 637 Lecture #10 6
TSP Roles
Team LeaderDevelopment ManagerPlanning ManagerQuality and Process Manager
May be two separate roles
Support Manager
INFO 637 Lecture #10 7
TSP Activities
The management of activities is similar to version 2.0 of the PSP Time is logged for all activities Defects are logged Tasks are planned, and actual times recorded Size of work products is estimated, and
compared to actuals Risks and issues are identified and tracked
INFO 637 Lecture #10 8
TSP Activities
TSP also introduces a peer review process, which allows estimation of defects missed during inspection
A change control process is added to prevent conflicting changes to the same artifact (code, documentation, etc.)
INFO 637 Lecture #10 9
Typical Scripts for one Cycle
We used the scripts for one project cycle Launch & Development Strategy Development Plan SRS and System Test Plan Design and Integration Test Plan Implementation Script Test Script (conduct integration & system test) Post Mortem
INFO 637 Lecture #10 10
Launch Script
The launch script includes: Course overview Assigning roles Describing the objectives of your product
How will you know if it’s been created correctly? Hold the first team meeting Review of data reporting requirements
INFO 637 Lecture #10 11
Development Strategy Script
Key steps in this phase are: Create Conceptual Design of the product Define Development Strategy
What features go into each cycle? Estimate Product size and development effort Assess Risks Document the Development Strategy Define Configuration Management Plan
INFO 637 Lecture #10 12
Development Plan Script
Based on the conceptual design Identify specific products to be produced,
and estimate their sizes Record STRAT data in SUMS
Produce task plan using TASK formProduce team’s schedule plan using
SCHEDULE form, including expected weekly hours per person
INFO 637 Lecture #10 13
Development Plan Script
Produce the quality plan using estimated SUMP and SUMQ plans
Break out individual plans based on the team TASK and SCHEDULE plans
Balance workload, then reconsolidate the team TASK and SCHEDULE plans
Send TASK, SCHEDULE, SUMS, SUMP, and SUMQ to team members and instructor
INFO 637 Lecture #10 14
SRS Script
The development script for creating the SRS includes: Reviewing and clarifying the system needs Allocating parts of the SRS to be done by
each team member Developing the system test plan Inspecting the SRS and test plan Refining the SRS and test plan
INFO 637 Lecture #10 15
Design Scripts
Conduct high level design to identify and name the major components Capture the design using one or more methods
mentioned earlier
Define design standards (like in the PSP)Allocate design tasks to team members
INFO 637 Lecture #10 16
Design Scripts
Prepare parts of the SDS separatelyPrepare the integration test plan Inspect the draft design document and
test planUpdate and agree upon the final SDS,
and prove that it is traceable to the SRS
INFO 637 Lecture #10 17
Implementation Script
Plan implementation tasks using SUMP and SUMQ
Allocate tasks to team membersConduct detailed design
Do design review using LOGD and LOGT
Create unit test plan, test cases, procedures, and test data
INFO 637 Lecture #10 18
Implementation Script
Inspect the detailed design for each component using INS and LOGD
Create the code, and review it using code checklist Record defects using LOGD and LOGT
Do formal code inspection using INS and LOGD
INFO 637 Lecture #10 19
Implementation Script
Have quality manager verify every component
Release accepted componentsHence the outputs from this script are:
Completed code Forms INS, SUMP, SUMQ, LOGD, and LOGT Test plans and materials (test cases, etc.) Updated project notebook
INFO 637 Lecture #10 20
Test Scripts
Test script includes: Develop build, integration test, and system
test procedures Determine size, time, and materials needed
for each test Build the product Conduct integration testing Conduct system testing
INFO 637 Lecture #10 21
Test Scripts
Produce user documentation, review and fix it
Outputs include An integrated and tested product for this cycle Completed LOGD and LOGTEST forms for
all tests Completed user documentation Time, size, and defect data in TSP system
INFO 637 Lecture #10 22
Post Mortem Scripts
The post mortem is started when the team has completed, tested, and documented this cycle’s product
Review the SUMP and SUMQ forms from this cycle Which processes worked, and which didn’t? How did product quality compare to
previous cycles (if any) or expectations?
INFO 637 Lecture #10 23
Post Mortem Scripts
Did process efficiency change much (e.g. the productivity measures)?
Were the roles successfully executed? Were there any problems with any roles?
Look for improvement ideas, and submit them on PIP forms
Prepare a cycle report
INFO 637 Lecture #10 24
Cycle Report
Each team member writes a description of What did you produce? What processes did you use? What roles did you perform? What worked, and what didn’t? How well did your role work with the team? How were you as a developer?
INFO 637 Lecture #10 25
Waterfall Similarities
Notice that the combination of test planning with development phases is straight from classic waterfall structure The system test plan is written with the system
requirements The integration test plan is written with the high
level design The unit test plan is written with detailed design
(in the implementation phase)
INFO 637 Lecture #10 26
Continuous Evaluation and Improvement
As each cycle progresses, earned value is tracked, and measures of quality, productivity, and defect removal effectiveness are made
This forms, over many cycles, an objective basis for predicting future development efforts and truly understanding the caliber of work produced by your team