The SEI Approach to Software Engineering Process Models

The SEI
Approach
Modelos de Procesos y
Metodologías de Ingeniería de
software
Mayo de 2013
Universidad de Caldas
Facultad de Ingenierías
Maestría en Ingeniería Computacional

Content
Personal Software Process (PSP)
Team Software Process (TSP)
PSP & TSP & CMMI

Sources
• Ron S. Kenett & Emanuel R. Baker. Process Improvement and CMMI® for
Systems and Software. 2010 Taylor and Francis Group, LLC. ISBN 978-1-
4200-6051-5
• James McHale and Daniel S. Wall. Mapping TSP to CMMI. TECHNICAL
REPORT CMU/SEI-2004-TR-014 ESC-TR-2004-014. April 2005. Available in
http://www.sei.cmu.edu/reports/04tr014.pdf
•Hayes, W. and Over, J.W., The Personal Software ProcessSM (PSPSM): An
Empirical Study of the Impact of PSP on Individual Engineers, (CMU/SEI-97-
TR-001), Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon
University, December 1997.
•Mukesh Jain. Delivering Successful Projects with TSPSM and Six Sigma A
Practical Guide to Implementing Team Software Process. Auerbach
Publications, 2009. ISBN 978-1-4200-6143-7

National Interest around CMMI,
PSP/TSP
• SENA
• MINTIC
http://programa.gobiernoenlinea.gov.co/convoca
toria_TSP_PSP.shtml
• Goverment  PSP, TSP, CMMI
• National Industry  Scrum
Why?

Relations between CMMI-TSP-PSP
•The CMMI constellations address issues related to how
organizations develop or acquire systems and services
•The Team Software Process (TSP) and the Personal
Software Process (PSP) address issues regarding
development at the next lower levels of organizations: TSP
at the team level and PSP at the personal level.
•Although one may look at the organization of models as a top-
down architecture, in reality, the TSP extends and builds upon
the concepts contained in the PSP.
•These techniques provide detailed guidance for how to
implement individual- and team-based processes to
quantitatively manage and improve software development

Source: http://www.gonet.us/index.asp?action=home.interior&SectId=1295&CatId=1539&ArtId=656

CMM/CMMI - for
organizational
capability
TSP - for quality
products on cost
and schedule
PSP - for
individual skill
and discipline
Adapted From “Three Dimensions of Process Improvement,” Watts Humphrey, CROSSTALK, February 1998
Source: www.enel.ucalgary.ca/People/Smith/2011webs/encm511_11/11_Lectures/11_November/ExtraTalk_4Nov2011_PSP.ppt

Personal Software Process
(From Watts Humphrey):
“Engineers are understandably skeptical about
changes to their work habits; although they may be
willing to make a few minor changes, they will
generally stick fairly closely to what has worked for
them in the past until they are convinced a new
method will be more effective. This, however, is a
chicken-and-egg problem: engineers only believe new
methods work after they use them and see the results,
but they will not use the methods until they believe they
work”

Personal Software Process
(From Hayes and Over):
The PSP course incorporates what has been called
a “self-convincing” learning strategy that uses
data from the engineer’s own performance to
improve learning and motivate use. The course
introduces the PSP practices in steps corresponding to
seven PSP process levels. Each level builds on the
capabilities developed and historical data gathered in
the previous level.

TEAM Power
• The initial TSP objective is to convince management
to let your team be self directed.
• A self-directed team
• sets its own goals
• establishes its own roles
• decides on its own development strategy
• defines its own processes
• develops its own plans
• measures, manages, and controls its own work
• Self-directed teams do the best work.
• The PSP provides the knowledge and skill that
developers need to work on TSP teams

TEAM Power
• Management will agree to your managing your own
work as long as they believe that you are doing a
superior job.
• To convince them of this, you must
• maintain precise and accurate plans
• measure and track your work
• regularly show management that you are doing
superior work
• The PSP shows you how to do this

PSP Principles (I)
• The quality of a software system is determined by
the quality of its worst components.
• The quality of a software component is governed by
the individual who developed it.
• The quality of a software component is
governed by the quality of the process used to
develop it.
• The key to quality is the individual developer’s skill,
commitment, and personal process discipline.

PSP Principles (II)
• As a software professional, you are responsible for
your personal process.
• You should measure, track, and analyze your work.
• You should learn from your performance variations.
• You should incorporate lessons learned into your
personal practices.

What Does a PSP Provide? (I)
A stable, mature PSP allows you to
• estimate and plan your work
• meet your commitments
• resist unreasonable commitment pressures
• You will also understand your current performance
be better equipped to improve your capability
The PSP provides:
• a proven basis for developing and using an
industrial-strength personal process
• a discipline that shows you how to improve your
personal process
• the data to continually improve the productivity,
quality, and predictability of your work

What Does a PSP Provide? (III)
• The PSP process is designed for individual use.
• It is based on scaled-down industrial software
practice.
• The PSP course demonstrates the value of using a
defined and measured process.
• It helps you and your organization meet the
increasing demands for high quality and timely
software.

How to learn PSP?
In a SEI PSP Official course, Engineers learn to use the
PSP by writing ten programs, one or two at each of the
seven levels, and preparing five written reports.
Engineers may use any design method or programming
language in which they are fluent. The programs are
typically around one hundred lines of code (LOC) and
require a few hours on average to complete.
While writing the programs, engineers gather process data
that are summarized and analyzed during a postmortem
phase. With such a short feedback loop, engineers can
quickly see the effect of PSP on their own performance.
They convince themselves that the PSP can help them to
improve their performance; therefore, they are motivated to
begin using the PSP after the course

Learning the PSP
• The PSP methods are organized into seven process
versions and address different aspects of how PSP is
applied.
• The process versions are labeled PSP0, PSP0.1, PSP1,
PSP1.1, PSP2, PSP2.1, and PSP3.
• Each process version contains a similar set of scripts,
logs, forms, and standards.
• You write one or more module-sized programs at each
step.
• You gather and analyze data on your work.
• You use the results to improve your personal
performance

Learning the PSP
source:
SEI
official
training
slides

Learning the PSP
• PSP0: You establish a measured performance
baseline.
• PSP1: You make size, resource, and schedule
plans.
• PSP2: You practice defect and yield
management
• PSP3: You scale efficiently PSP to real life
projects

PSP 0 (I)
•PSP0 and PSP0.1 formulate a baseline understanding of
PSP, focusing on developing and understanding the need
for establishing an initial base of historical size, time, and
defect data.
•These process versions address issues such as
understanding the current process in use, the need for
basic measures, the importance of measures of size
(which relate to productivity), etc.
•In PSP training courses, in learning this aspect of PSP,
students develop small programs, using their own
methods but following a rigorous process. They are
required to estimate, plan, perform, measure, compare
actuals to estimates, and conduct a post-mortem when
finished.

PSP 0 (II)
• The objective for PSP0 is to demonstrate the use of
a defined process in writing small programs
• Incorporate basic measurements in the software
development process require minimal changes to
your personal practices.
•The PSP is not the process for writing software.
•The PSP is a process for learning about process.
•It’s the process equivalent of a code sample
•examine your PSP data
•review your experience and PIPs (Process
Improvement Proposals)
•tailor the PSP to meet your needs

PSP 0 (III)
•Planning – produces a plan for developing the
program defined by the requirements.
•Design – produces a design specification for the
program defined by the requirements.
•Coding – transforms the design specification into
programming language statements
•Compile – translates the programming language
statements into executable code.
•Test – verifies that the executable code satisfies the
requirements.
•Postmortem – summarizes and analyzes the project
data.

Process Scripts
•Process scripts guide you through the process.
•You should
•check the entry criteria before starting a phase
•record the phase start time
•perform the phase steps and instructions
•record defects as they are found and corrected
•check the exit criteria before ending a phase
•record the phase end time
•go to the next phase
•Force yourself to use this paradigm until it becomes
a habit.

PSP0 Measures and Forms
•PSP0 measures
•Time – track time in phase
•Defects – record defects as they are found and
fixed
•PSP0 has four forms
•PSP0 Project Plan Summary – summarizes
planned and actual time and defects by phase
•PSP0 Time Recording Log – used to record time
•PSP0 Defect Recording Log – used to record
defects
•PSP0 Defect Type Standard – used to define
standard defect types

PSP0
•In using PSP0, your principal objective is to learn
to gather and report accurate and complete data
on your work.
•Gather and record data on your process as you work,
not afterwards. If you forget, promptly make your best
guess.
• Be precise and accurate.
• Track time in minutes.
• Count every defect.
•You will be using your own data to manage your
process; gather data that is worthy of your trust.

PSP 0.1 (I)
• Your principal objective is to measure and estimate
the size of the programs that you produce so that you
can effectively plan and manage your work
• The objectives of PSP0.1 are to help you to
measure the size of the programs that you
produce, perform size accounting for the
programs that you produce make accurate and
precise size measurements
•There are two new process elements.
•process improvement proposal (PIP) form
•size counting and coding standards

PSP 0.1 (II)
• The additions to the PSP0.1 process scripts include new
steps for
•estimating and reporting software size
•distributing development time over planned project phases
•using a size counting and coding standard
•recording process problems and improvement ideas
• To improve your process, you will need to capture process
problems and propose improvements for future reference.
• You will need to know
•any problems you have encountered in using the process
•any suggestions you have for process improvements
•your observations and findings from doing the assignments

PSP 0.1 and coding standards
• Coding and size counting standards are needed to
write the PSP programs.
• These standards are tailored to your language and
needs designed to make size counting easier
• The coding standard defines quality-oriented exit
criteria for the code phase.

PSP 0.1 size measurements
•In the PSP, software size measures are used to
•relate the amount of product produced with effort
expended to project total effort
•calculate productivity
•normalize defects
•project the total defects
•Software size is measured in LOC.
•To accurately relate size to effort, the different types of
LOC in your program are counted separately
•Your principal objective is to measure and estimate
the size of the programs that you produce so that you
can effectively plan and manage your work.

PSP and measurements
•The basic PSP data are
•program size
•time spent by phase
•defects found and injected by phase
•Both actual and estimated data are gathered on
every item.
•Measures derived from these data
•support planning
•characterize process quality.

PSP and size measurements
•The goals of the PSP size measures are to
•Define a consistent size measure
•Establish a basis for normalizing time and defect
data
•Help make better size estimates
•Some of the questions these data can help to answer
are
•What size program did I plan to develop?
•How good was my size estimate?
•What was the completed size of the finished
program?

PSP and time measurements
•The goals of the PSP time measures are to
•Determine how much time you spend in each PSP
phase
•Help you to make better time estimates
•Typical questions these data can help answer are
•How much time did I spend by PSP phase?
•How much time did I plan to spend by PSP
phase?

PSP and defect measurements
•The goals of the PSP defect measures are to
•provide a historical baseline of defect data
•understand the numbers and types of defects
injected
•understand the relative costs of removing defects
in each PSP phase
•Some questions these data can help answer are
•How many defects did I make in each phase?
•How many defects did I remove in each phase?
•How much time did it take to find and fix each
defect?

Size Versus Development Effort
•The principal requirement: If the size measure is not
directly related to development cost, it is not worth using.
•There are many possible measures.
•database elements
•lines of code (LOC)
•function points
•pages, screens, scripts, reports
•Pages are often an acceptable measure for document
development.
•LOC is usually a good measure for developing source
programs like Pascal and C++.
•Other possible measures are function points, screens,
modules, database elements, and maintenance fixes.

PSP 1 and PSP 1.1
• PSP1 and PSP1.1 focus on personal project
management techniques, introducing size and
effort estimating, schedule planning, and
schedule tracking methods.
• The objective of PSP1 is to establish an orderly and
repeatable procedure for developing software size
estimates.

The Project Planning Framework

Estimating
The advantages of using defined estimating methods
are that you
•have known practices that you can improve
•have a framework for gathering estimating data
•can consistently use historical data to produce
balanced estimates

Estimating with PROBE (I)
• The PSP uses the PROBE method to estimate and
plan projects.
• PROBE stands for PROxy Based Estimating.
• PROBE uses proxies to estimate program size and
development time.
• A good proxy will help you to make accurate
estimates.
• The size measure should be sensitive to language,
design, and development practice.

Estimating with PROBE (II)
• A good proxy should correlate closely to development
costs.
• A good proxy should be easy to visualize early in
development.
• It should also be a physical entity that can be measured
• The basic issue
• Good size measures are detailed.
• It is generally hard to visualize product details early in a
project.
• Alternatives
• Wait to estimate until you have the detail.
• Make your best guess.
• Identify a suitable proxy.

Some proxies
• Classes, functions, and procedures
• Product elements
• database elements
• screens, reports, scripts, files
• book chapters
• Correlation with development hours
• Numbers of classes correlates reasonably well.
• Class size correlates very closely.
• Class size can be estimated using historical data.
• The program size estimate is then calculated from the
historical relationship between total class size and program
size.

• With a good correlation, calculate program size from the
relationship between class size and program size.
• When classes are selected as application entities, they can
be visualized early in development.
• Functions and procedures can often be estimated in the
same way.
• Classes, functions, procedures, and their sizes can be
automatically counted.
• Accurate size estimates will help you to make better
development plans.
• Estimating skill improves with practice.
• A defined and measured process provides a repeatable
basis for improvement.
• To make accurate estimates, you must use historical data
and follow sound methods.
Some proxies ideas with PROBE

PSP 1.1
• The objectives of PSP1.1 are to introduce and practice
methods for making resource and schedule plans
• tracking your performance against these plans
• judging likely project completion dates
• There are two new process elements.
• task planning template
• schedule planning template
• These are typically used for projects that take several
days or weeks.
• The project plan summary has been expanded to
include basic process statistics.

PSP 2 and 2.1
• PSP2 and PSP2.1 fold in methods for managing
quality.
• The notion of personal reviews for design and code
are introduced.
• The use of design notation and templates for design
are also introduced.
• Importantly, the need for measures to manage
process and product quality is also addressed

PSP 2 and 2.1
(From Hayes and Over)
“The goal of quality management in the PSP is to find
and remove all defects before the first compile. The
measure associated with this goal is yield. Yield is
defined as the percent of defects injected before
compile that were removed before compile. A yield of
100% occurs when all the defects injected before
compile are removed before compile.”

PSP 2 and 2.1
(From Hayes and Over)
“Starting with PSP2, engineers also begin using the historical
data to plan for quality and control quality during development.
Their goal is to remove all the defects they inject before the first
compile. During planning, they estimate the number of defects
that they will inject and remove in each phase. Then they use the
historical correlation between review rates and yield to plan
effective and efficient reviews. During development, they control
quality by monitoring the actual defects injected and removed
versus planned, and by comparing actual review rates to
established limits (e.g., less than 200 lines of code reviewed per
hour). With sufficient data and practice, engineers are capable of
eliminating 60% to 70% of the defects they inject before their first
compile.”

PSP 2 (I)
• The objectives of PSP2 are to introduce
• design and code reviews
• methods for evaluating and improving the quality of
your reviews
• PSP2 adds two key capabilities to the PSP
• design and code reviews
• quality planning
• Quality planning involves
• estimating the total number of defects that will be injected
• estimating the number of defects that will be injected and
removed in each process phase
• estimating the amount of time needed for design and code
reviews
• adjusting these parameters as needed to ensure a high
quality result

PSP 2 (II)
• To estimate the total defects injected and removed, use the
estimated program size and to-date defect density to calculate
the estimated total defects.
• Benchmark data on code review rates can be used to estimate
review time.
• From PSP data, we know that code review rates under 200
LOC/hour generally give high yield.
• Using planned added and modified LOC, code review time can
be calculated using this formula

The PSP Quality Focus (I)
• Defects are not important to users, as long as they do not
• affect operations
• cause inconvenience
• cost time or money
• cause loss of confidence in the program’s results
• The defect content of software products must be managed
before more important quality issues can be addressed.
• Low defect content is an essential prerequisite to a quality
software process.
• Since low defect content can best be achieved where the
defects are injected, engineers should
• remove their own defects
• determine the causes of their defects
• learn to prevent those defects

The PSP Quality Focus (II)
• Improve product quality and accelerate development
work by
• doing reviews and inspections to remove defects
before test
• using testing to check product quality, not to remove
volumes of defects
• Design and code reviews
• improve the quality of your programs
• save development time
• To do effective reviews, you must
• establish review goals
• follow a disciplined review process
• measure and improve your review practices

PSP 2.1 (I)
• The objectives of PSP2.1 are to introduce
• additional measures for managing process quality
• design templates that provide an orderly
framework and format for recording designs
• PSP2.1 adds the following process elements:
• PSP2.1 design review script
• PSP2.1 design review checklist
• operational specification template
• functional specification template
• state specification template
• logic specification template

PSP 2.1 (II)
• Since there is no single best design method, the
PSP supports multiple methods.
• The PSP focuses on what a complete design should
contain.
• The goal is to eliminate requirements and design
defects.
• The PSP uses design templates to provide
• criteria for design completeness
• reviewable designs

PSP 2.1 Design
• It is important to separate two issues.
• how to do the design
• how to represent the design when it is completed
• Since the PSP can be used with any design method, it
does not specify a specific design approach.
• However, the PSP does address design representation.
• Four design templates are used in the PSP to cover the
four design views.
• operational specification template
• functional specification template
• state specification template
• logic specification template

PSP 3 (I)
• PSP <= 2.1 have focused on basic techniques that will
improve the engineer’s ability and skill to deliver small
(up to 2000 lines of code) programs predictably (effort,
schedule, and quality).
• PSP3 needs to scale the PSP2 process to deliver the
same rigor and benefits to large systems.
• The strategy here is to subdivide the big system to
smaller programs, which can be managed effectively
by the PSP2 process. The cyclic process of PSP3
works very well for programs between 2000 and
20,000 lines of code .

PSP 3 (II)
• PSP3, Cyclic Personal Process, addresses scalability.
• It is important for students who are learning PSP to
be able to scale upward efficiently from what they
have learned in the PSP training course to larger,
real-life projects, without sacrificing either quality or
productivity.
• PSP3 addresses scalability by decomposing large
programs into smaller elements, developing them, and
then integrating them. This reduces the development
problem to something that is analogous to developing
software using methods described in PSP2.1.

PSP Key
• One important aspect of the PSP is that
implementing process improvement models,
whether it’s the CMMI, ISO 12207, or any other
model, enables the developers within the
organization to accept the disciplined methodologies
associated with these standards.
• Once a developer understands the value in his/her
own use of disciplined practices as a result of using
PSP, he/she will be more willing to accept the
disciplined practices associated with implementing a
process improvement model.

PSP & CMMI levels
Source: www.enel.ucalgary.ca/People/Smith/2011webs/encm511_11/11_Lectures/11_November/ExtraTalk_4Nov2011_PSP.ppt
Level 2
Software configuration management
Software quality assurance
Software subcontract management
Software project tracking and oversight*
Software project planning*
Requirements management
*PSP key practices
Level 3
Peer reviews*
Intergroup coordination
Software product engineering*
Integrated software management*
Training program
Organization process definition*
Organization process focus*
Level 4
Quality management*
Process measurement and analysis*
Level 5
Process change management*
Technology innovation*
Defect prevention*
Level 1
W. S. Humphrey,
“A Discipline for Software
Engineering”, 1995

TSP – Team Software Process
• The TSP is a framework and a process structure
for building and guiding engineering teams.
• The TSP contains
• a team-building process that builds shared goals,
commitments, and cohesion
• a team-working process that guides the team’s
engineering processes and practices

What Does the TSP Do?
• The TSP establishes an environment that builds,
develops, uses, and supports self-directed
teamwork.
• A self-directed team
• sets its own goals
• establishes its own roles
• decides on its own development strategy
• defines its own processes
• develops its own plans
• measures, manages, and controls its own work
• Self-directed teams are jelled teams and they do the
best work.

Management Support
• Management will agree to you and your team mates
working as a self-directed team as long as you
• strive to meet their needs
• regularly report on your work
• convince them that your plans are sound
• do quality work
• respond to changing needs
• come to them for help when you need it
• While this is not hard for you to do, it takes
• skill
• disciplined work
• guidance and support

Building Needed Skills
• The PSP shows you how to
• measure and manage your personal work
• use data to make sound plans
• manage the quality of your work
• produce quality products on predictable
schedules
• With the TSP, you use these skills to convince
management to support self-directed teamwork.

TSP Structure and Flow
• A TSP launch kicks off each major project phase.
• The team builds a common understanding of the
work and the way to do it.
• The members produce plans to guide their work.
• Subsequent phases kick off with a TSP relaunch.

TSP Launch
• The TSP process recognizes that up-front project
planning is performed on the basis of a lot of
unknowns; consequently, the process addresses
planning at four points during the development
cycle: at project start, at the start of architectural
design, at the start of implementation (e.g., coding),
and at the start of integration and test.
• The initial point is referred to as the launch, and
the other three points are referred to as
relaunches.
• As with the PSP, there are a number of scripts,
forms, and standards that are a part of the TSP
process.

TSP Launchs
• The launch, which is the team-building component of
TSP, consists of nine meetings spread over 4 days.
• It focuses on planning the team’s work and covers
the following topics: establishing product and
business goals, assigning roles and establishing
team goals, laying out the development strategy,
building top-down and next-phase plans, developing
the quality plan, building bottom-up and consolidated
plans, conducting the risk assessment, preparing the
briefing to management and the launch report,
holding a management review, and conducting the
launch post-mortem.

Working on a TSP Project
• Once you have management support to launch a
TSP team, you need to keep that support.
• This requires that you and your teammates do five
things.
• Follow the process you have defined.
• Maintain the individual and team plans.
• Manage product quality.
• Regularly track and report your progress.
• Continually demonstrate high performance.

TSP & CMMI
• TSP might be considered from some perspectives
as a micro-implementation of the CMMI
• TSP complements CMMI implementation by helping
project and line managers implement the project
management practices contained in the Project
Planning, Project Monitoring and Control, Integrated
Project Management, and Risk Management
Process Areas.
• It facilitates the team (or teams) being able to hit the
ground running when the project starts.

TSP & CMMI Categories
Source: Mapping TSP to CMMI. TECHNICAL REPORT CMU/SEI-2004-TR-014 ESC-TR-2004-014. Available in

TSP & CMMI Process Mgmnt

TSP & CMMI Project Mgmtn

TSP & CMMI Engineering

TSP & CMMI Support

TSP & CMMI ML 2

TSP & CMMI ML 3

TSP & CMMI ML 4

TSP & CMMI ML 5

More Info
•CMMI and TSP Resources:
http://cmmiinstitute.com/cmmi-getting-
started/cmmi-compatibility/cmmi-and-tsp/
•PSP/TSP support tool open-source initiative:
http://www.processdash.com/download

The SEI Approach to Software Engineering Process Models

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to The SEI Approach to Software Engineering Process Models

Similar to The SEI Approach to Software Engineering Process Models (20)

More from Fáber D. Giraldo

More from Fáber D. Giraldo (20)

Recently uploaded

Recently uploaded (20)

The SEI Approach to Software Engineering Process Models