1

SE311-Software Construction and development

Week 3 Lecture 5-6

Instructor: Ali Haider

Personal and Team Software Process

► The best software process is one that is close to the people who will be doing the work.
► If a software process model has been developed at a corporate or organizational level, it
can be effective only if it is amenable to significant adaptation to meet the needs of the
project team that is actually doing software engineering work.
► In an ideal setting, you would create a process that best fits your needs, and at the same
time, meets the broader needs of the team and the organization.
Personal and Team Software Process

► Alternatively, the team itself can create its own process, and at the same time meet the
narrower needs of individuals and the broader needs of the organization.
► Watts Humphrey argues that it is possible to create a “personal software process” and/or a
“team software process.” Both require hard work, training, and coordination, but both are
achievable.
Personal Software Process (PSP)

► Every developer uses some process to build computer software.

► The process may be haphazard or ad hoc; may change on a daily basis; may not be
efficient, effective, or even successful; but a “process” does exist.
► Watts Humphrey suggests that in order to change an ineffective personal process, an
individual must move through four phases, each requiring training and careful
instrumentation.
Personal Software Process (PSP)

► The Personal Software Process (PSP) emphasizes personal measurement of both the work
product that is produced and the resultant quality of the work product. In addition PSP
makes the practitioner responsible for project planning (e.g., estimating and scheduling)
and empowers the practitioner to control the quality of all software work products that are
developed.
► The PSP model defines five framework activities:
Personal Software Process (PSP)

► Planning: This activity isolates requirements and develops both size and resource
estimates. In addition, a defect estimate (the number of defects projected for the work) is
made. All metrics are recorded on worksheets or templates. Finally, development tasks are
identified and a project schedule is created.
► High-level design: External specifications for each component to be constructed are
developed and a component design is created. Prototypes are built when uncertainty
exists. All issues are recorded and tracked.
Personal Software Process (PSP)

► High-level design review: Formal verification methods are applied to uncover errors in
the design. Metrics are maintained for all important tasks and work results.
► Development: The component level design is refined and reviewed. Code is generated,
reviewed, compiled, and tested. Metrics are maintained for all important tasks and work
results.
► Postmortem: Using the measures and metrics collected (this is a substantial amount of
data that should be analyzed statistically), the effectiveness of the process is determined.
Measures and metrics should provide guidance for modifying the process to improve its
effectiveness.
Drawbacks

► However, PSP has not been widely adopted throughout the industry. The reasons, sadly,
have more to do with human nature and organizational inertia than they do with the
strengths and weaknesses of the PSP approach.
► PSP is intellectually challenging and demands a level of commitment (by practitioners and
their managers) that is not always possible to obtain. Training is relatively lengthy, and
training costs are high.
► The required level of measurement is culturally difficult for many software people.
Team Software Process (TSP)

► Because many industry-grade software projects are addressed by a team of practitioners,

Watts Humphrey extended the lessons learned from the introduction of PSP and proposed
a Team Software Process (TSP).
► The goal of TSP is to build a “selfdirected” project team that organizes itself to produce
high-quality software. Humphrey [Hum98] defines the following objectives for TSP:
Team Software Process (TSP)

► Build self-directed teams that plan and track their work, establish goals, and own their
processes and plans. These can be pure software teams or integrated product teams (IPT)
of three to about 20 engineers.
► Show managers how to coach and motivate their teams and how to help them sustain peak
performance.
► Accelerate software process improvement by making CMM Level 5 behavior normal and
expected.
► The Capability Maturity Model (CMM), a measure of the effectiveness of a software process, is
discussed in Chapter 30.
Team Software Process (TSP)

► Provide improvement guidance to high-maturity organizations.

► Facilitate university teaching of industrial-grade team skills.
Team Software Process (TSP)

► A self-directed team has a consistent understanding of its overall goals and objectives;
defines roles and responsibilities for each team member; tracks quantitative project data
(about productivity and quality); identifies a team process that is appropriate for the
project and a strategy for implementing the process; defines local standards that are
applicable to the team’s software engineering work; continually assesses risk and reacts to
it; and tracks, manages, and reports project status.
Team Software Process (TSP)

► TSP defines the following framework activities:

► Project launch
► High-level design
► Implementation
► Integration
► Test and postmortem
Team Software Process (TSP)

► Like their counterparts in PSP (note that terminology is somewhat different), these
activities enable the team to plan, design, and construct software in a disciplined manner
while at the same time quantitatively measuring the process and the product.
► The postmortem sets the stage for process improvements.
Team Software Process (TSP)

► TSP makes use of a wide variety of scripts, forms, and standards that serve to guide team
members in their work.
► “Scripts” define specific process activities (i.e., project launch, design, implementation,
integration and system testing, postmortem) and other more detailed work functions (e.g.,
development planning, requirements development, software configuration management,
unit test) that are part of the team process.
► TSP recognizes that the best software teams are self-directed.
Team Software Process (TSP)

► Team members set project objectives, adapt the process to meet their needs, control the
project schedule, and through measurement and analysis of the metrics collected, work
continually to improve the team’s approach to software engineering.
► Like PSP, TSP is a rigorous approach to software engineering that provides distinct and
quantifiable benefits in productivity and quality. The team must make a full commitment
to the process and must undergo thorough training to ensure that the approach is properly
applied.
Reference

► Software Engineering: A Practitioner’s Approach by Pressman chapter 2