Session 1.1 – TSPi Overview

Chapter 1: Introduction to Team Software Process | Duration: 1 hr

Learning Objectives

By the end of this session, students will be able to:

  • Explain what TSPi is and why it is needed for team software development
  • Describe the four basic principles underlying TSPi design
  • Identify the seven key design decisions that shape TSPi
  • Understand the relationship between PSP, TSPi, and TSP
  • Explain the cyclic development strategy and its benefits
  • Recognize the importance of process discipline in software engineering

Introduction to Team Software Development

Most industrial software is developed by teams. Thus, to be an effective engineer, you need to be able to work on a team. If you have good sense and a willingness to cooperate, you have the basic equipment to be a successful team member.

Key Insight

Team-work is more than just getting along. Teams must plan their projects, track their progress, and coordinate their work. They also must agree on goals, have a common working process, and communicate freely and often.

To meet aggressive schedules and produce high-quality products, practiced teamwork is essential. However, practiced teamwork requires experience and calls for a specific set of skills and methods. This textbook and its accompanying course provide a comprehensive introduction to team software development.

Course Goal

Expose you to realistic teamwork problems and give you practical teamwork experience. With this experience, you will be prepared to participate in large-scale industrial software projects.

The Football Analogy

It's like a huddle in football: experienced teams first agree on the play and each member's role. If teams didn't huddle, they would do a lot of running around, but they wouldn't win many games.

What is TSPi?

TSPi (Team Software ProcessSM - Introductory) is a defined framework for a graduate or upper-level undergraduate course in team software engineering. It provides a balanced emphasis on process, product, and teamwork.

TSPi Foundation and Evolution
PSP Personal Software Process Foundation TSPi Team Software Process (Introductory) Academic Setting TSP Team Software Process (Full Industrial) Large Teams (up to 20) Builds On Prepares For

Figure: TSPi builds on PSP and prepares students for industrial TSP

Why Engineering Teams Need a Process

Merely giving a group of engineers a job does not automatically produce a team. The steps required to build a team are not obvious, and new teams often waste substantial time handling teamwork mechanics:

  • Figuring out how to work together as a team
  • Defining the job they need to do
  • Devising a strategy for doing the work
  • Allocating tasks among team members
  • Coordinating each of these tasks
  • Tracking and reporting on progress

Important: Although these team-building tasks are not trivial, they are not very difficult. There are known methods for doing every one of them, and you need not reinvent these methods for yourselves.

The Four Basic TSPi Principles

Principle 1
Defined Process & Rapid Feedback

Learning is most effective when you follow a defined process and get rapid feedback. The TSPi scripts and forms provide a defined, measured, and repeatable framework. The TSPi provides rapid performance feedback because the team produces the product in several short development cycles and evaluates results after each cycle.

Principle 2
Goals, Environment & Leadership

Productive teamwork requires a combination of specific goals, a supportive working environment, and capable coaching and leadership. The project goal is to build a working product. TSPi provides the supportive environment, one team member will be the team leader, and the instructor provides the coaching.

Principle 3
Learning Through Experience

When you have struggled with actual project problems and have been guided to effective solutions, you will appreciate the benefits of sound development practices. Without the precise guidance of TSPi, you could waste considerable time in defining your own practices, methods, and roles.

Principle 4
Building on Prior Knowledge

Instruction is most effective when it builds on the available body of prior knowledge. There has been a great deal of experience with software teams and software team courses. TSPi builds on this foundation of industrial experience in planning and managing software projects.

The Seven TSPi Design Decisions

There are many ways to design a process. In the case of TSPi, there were seven principal design decisions:

The purpose of a process is to help you do a task. When the process is too complex, you spend too much time figuring out what to do. If it's too simplistic, it doesn't provide enough guidance.

Key Points:

  • Builds on Personal Software Process (PSP) foundation
  • Most forms and scripts similar to PSP
  • Prior PSP training is a prerequisite
  • Role assignments help focus on specific tasks
  • During multicycle projects, try several roles for broader exposure

In a full TSPi course, you will complete two or three development cycles in one semester. Each cycle includes full requirements, design, implementation, and test development process.

Cycle Strategy:

  • Cycle 1: Build minimum-function subset (kernel product)
  • Cycle 2: Build on results of first cycle, may change roles
  • Cycle 3: Further enhancements if time permits

Benefits:

  • Quickly get kernel product running
  • Ensure working product at end of course
  • Identify problems early when easiest to fix
  • Gain clear evidence of what works best

Measurements are an essential part of doing consistently high-quality work. The PSP provides the basic measures and measurement skills you need.

  • Set personal and team goals
  • Learn to establish ambitious but attainable goals
  • See benefits of quality measurements
  • Understand value of project planning and tracking
  • Manage work on a daily basis

With TSPi measures, your performance and that of your teammates will be obvious. This is the nature of teamwork: everyone knows what everyone else is doing.

  • Principal purpose: help you do better work
  • Makes personal performance visible to teammates
  • If you don't make reasonable effort, expect comments from teammates
  • Transparency ensures accountability

TSPi calls for team and role evaluations. The idea is to evaluate how each role was performed and not how the people behaved.

  • Evaluates process effectiveness
  • Students best informed about team performance
  • Helps instructor give fair and equitable grades
  • Focus on role performance, not personal judgment

It is hard for software engineers to consistently do disciplined personal work. Three reasons for this:

  1. No tradition: Software engineering has no tradition of disciplined personal performance
  2. No natural discipline: Unlike hardware with factories and production engineers, software engineers must discipline themselves
  3. Need for support: Consistently disciplined work requires high standards and competent support (coaches, trainers)

With TSPi: The instructor requires you to follow the process, gather data, complete forms, and analyze results.

Even in the best-run projects, teamwork problems are common. You and your teammates have different roles with their own objectives, and when these conflict, disagreements are likely.

  • Don't assume conflicts are personality problems
  • Initially, assume teamwork issues are caused by process problems
  • Peer pressure is powerful for resolving team problems
  • Ask instructor for help when needed
  • With guidance, most engineers can be effective team members

TSPi Structure and Flow

TSPi Multi-Cycle Development Structure
Product Need Statement Cycle 1 Launch Strategy 1 Plan 1 Requirements 1 Design 1 Implementation 1 Test 1 Postmortem 1 Cycle 2 Launch Strategy 2 Plan 2 Requirements 2 Design 2 Implementation 2 Test 2 Postmortem 2 Cycle 3 Launch Strategy 3 Plan 3 Requirements 3 Design 3 Implementation 3 Test 3 Postmortem 3 Finished Product Final Evaluation

Figure: TSPi uses multiple development cycles to build the final product (adapted from Humphrey)

Cyclic Development Strategy Constraints

When you start a cyclic development strategy, consider these constraints:

  1. Each cycle should produce a testable version that is a proper subset of the ultimate product
  2. Each cycle should be small enough to be readily developed and tested in the available time
  3. When combined, the cycle products should produce the desired final product

The TSPi Process

The development script (DEV) shows the overall TSPi flow. Each script step is supported by one or more detailed scripts. Each of these scripts is described in a chapter devoted to that process step.

TSPi Script Structure

Every TSPi script includes:

  • Purpose: Brief statement of the overall purpose of the activity
  • Entry Criteria: What you need to have done before starting
  • General Section: Provides general information about the script
  • Activities: Numbered script rows showing activities to follow
  • Exit Criteria: What you should have accomplished upon finishing
TSPi Development Script (DEV)
Purpose: To guide a team through developing a software product
Entry Criteria
  • An instructor guides and supports one or more five-student teams
  • The students are all PSP-trained (Discipline for Software Engineering or Introduction to the Personal Software Process)
  • The instructor has the needed materials, facilities, and resources to support the teams
  • The instructor has described the overall product objectives
General

The TSPi process is designed to support three team modes:

  1. Develop a small- to medium-sized software product in two or three development cycles
  2. Develop a smaller product in a single cycle
  3. Produce a product element, such as a requirements document, a design specification, a test plan, and so on, in part of one cycle

Follow the scripts that apply to your project and mode of operation.

Week Step Activities
1 Review
  • Course introduction and PSP review
  • Read textbook Chapters 1, 2, and Appendix A
2 LAU1
  • Review course objectives and assign student teams and roles
  • Read textbook Chapter 3, Appendix B, and one of Chapters 11-15
STRAT1
  • Produce the conceptual design, establish the development strategy, make size estimates, and assess risk
  • Read textbook Chapter 4
3 PLAN1
  • Produce the cycle 1 team and engineer plans
  • Read textbook Chapter 5 and Appendix C
4 REQ1
  • Define and inspect the cycle 1 requirements
  • Produce the system test plan and support materials
  • Read textbook Chapter 6 and the test sections of Chapter 9
5 DES1
  • Produce and inspect the cycle 1 high-level design
  • Produce the integration test plan and support materials
  • Read textbook Chapter 7
6 IMP1
  • Implement and inspect cycle 1
  • Produce the unit test plan and support materials
  • Read textbook Chapter 8
7 TEST1
  • Build, integrate, and system test cycle 1
  • Produce user documentation for cycle 1
  • Read textbook Chapter 9
8 PM1
  • Conduct a postmortem and write the cycle 1 final report
  • Produce role and team evaluations for cycle 1
  • Read textbook Chapters 10, 16, 17, and 18
LAU2
  • Re-form teams and roles for cycle 2
  • Read the rest of textbook Chapters 11-15
STRAT2, PLAN2
  • Produce the strategy and plan for cycle 2
  • Assess risks
9 REQ2
  • Update the requirements and system test plan for cycle 2
DES2
  • Produce and inspect the cycle 2 high-level design
  • Update the integration plan for cycle 2
10 IMP2
  • Implement and inspect cycle 2, produce unit test plan
TEST2
  • Build, integrate, and system test cycle 2
  • Produce user documentation for cycle 2
11 PM2
  • Conduct a postmortem and write the cycle 2 final report
  • Produce role and team evaluations for cycle 2
LAU3
  • Re-form teams and roles for cycle 3
STRAT3, PLAN3
  • Produce the strategy and plans for cycle 3
  • Assess risks
12 REQ3
  • Update the requirements and system test plan for cycle 3
DES3
  • Produce and inspect the high-level design for cycle 3
  • Update the integration plan for cycle 3
13 IMP3
  • Implement and inspect cycle 3, produce unit test plans
14 TEST3
  • Build, integrate, and system test cycle 3
TEST3
  • Produce and review the user manual for the finished product
  • Review and update the user manual for usability and accuracy
15 PM3
  • Conduct a postmortem and write the cycle 3 final report
  • Produce role and team evaluations for cycle 3
  • Review the products produced and the processes used
  • Identify the lessons learned and propose process improvements
Exit Criteria
  • Completed product or product element and user documentation
  • Completed and updated project notebook
  • Documented team evaluations and cycle reports

Session Summary

Key Points
The Four Basic TSPi Principles:
  1. Defined process + Rapid feedback = Effective learning
  2. Goals + Environment + Leadership = Productive teamwork
  3. Experience with problems + Guided solutions = Appreciation of best practices
  4. Building on prior knowledge = Effective instruction
The Seven Design Decisions:
  1. Simple framework building on PSP
  2. Multiple development cycles
  3. Standard quality and performance measures
  4. Precise team and student measures
  5. Role and team evaluations
  6. Required process discipline
  7. Guidance on teamwork problems
Why TSPi Works:
  • Starts with small kernel product to ensure success
  • Each cycle provides learning for the next
  • Mirrors successful industrial development processes
  • Provides practical experience with realistic projects
  • Prepares students for large-scale industrial work
Next Session Preview

In the next session, we will explore the Launch Process, understanding how teams are formed, roles are assigned, and projects are initiated in TSPi.

Previous Session Course Home