ALL RIGHTS RESERVED BY GUANGDONG MOBILE COMMUNICATIONS CO.,
LTD. Team Software Process
Slide 2
Page 2 of 187 Why Study TSPi? TSPi guides students in effective
teamwork and process methods. TSPi provides defined team roles.
When students team members have explicit roles and the role
responsibilities are clearly defined and visible, instructors can
provide fairer and more specific grades.
Slide 3
Page 3 of 187 Reference Introduction to the Team Software
Process Watts S.Humphrey Tsinghua University Press Dec. 2002
TSPLeading a Development Team Watts.Humphrey Posts & Telecom
Press Jul.2006 Managing the Software Process Watts.Humphrey
Tsinghua University Press Aug. 2002 PSP A Self-Improvement Process
for Software Engineers Watts.Humphrey Posts & Telecom Press
Apr.2006 Introduction to the Personal Software Process
Watts.Humphrey Posts & Telecom Press Oct.2002.
Slide 4
Page 4 of 187 Prerequisites Introduction to the personal
Software Process The C Programming Language
Slide 5
Page 5 of 187 The Criteria of Grading Unannounced quiz 10
Midsemester 20 Final 70
Slide 6
ALL RIGHTS RESERVED BY GUANGDONG MOBILE COMMUNICATIONS CO.,
LTD. Chapter 1 TSPi OVERVIEW
Slide 7
Page 7 of 187 Contents What is TSPi? The TSPi design. The TSPi
structure and flow. The TSPi development strategy.
Slide 8
Page 8 of 187 Vocabulary Postmortem
Slide 9
Page 9 of 187 What Is TSPi TSPi Introduction to the Team
Software Process provides a structured set of steps, shows
engineers what to do at each step, and demonstrates how to connect
these steps to produce a completed product. TSPi is a reduced-scale
version of TSP. It does, however, retain the same basic concepts
and methods.
Slide 10
Page 10 of 187 TSPi Design Provide a simple framework that
builds on the foundation of Personal Software Process PSP . Develop
products in several cycles. Establish standard measures for quality
and performance. Provide precise measures for teams and students.
Use role and team evaluations. Require process discipline. Provide
guidance on teamwork problems.
Slide 11
Page 11 of 187 TSPi Structure and Flow 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
Slide 12
Page 12 of 187 Development Strategy When you start a cyclic
development strategy, the best plan is to begin with the smallest
viable product version. In deciding the size and content of each
cycle, you should consider the following constraint. Each cycle
should produce a testable version that is a proper subset of the
ultimate product. Each cycle should be small enough to be readily
developed and tested in the available time. When combined the cycle
products should produce the desired final product.
Slide 13
ALL RIGHTS RESERVED BY GUANGDONG MOBILE COMMUNICATIONS CO.,
LTD. Chapter 2 The Logic of the Team Software Process
Page 15 of 187 Contents Why projects fail. Why projects fail.
Common team problems. Common team problems. What is a team? What is
a team? Effective teams. Effective teams. How teams develop. How
teams develop. How TSPi builds teams. How TSPi builds teams.
Slide 16
Page 16 of 187 Why Projects Fail A poor or ineffective response
to pressure is often the cause of project failure. The apparent
source of pressure in software projects is the need to meet a tight
schedule. By guiding teams through a strategy and planning process,
the TSPi shows teams how to handle pressure. TSPi can help teams
manage their projects more effectively. Teams are much more likely
to do a quality job.
Slide 17
Page 17 of 187 Common Team Problems Ineffective Leadership
Failure to Compromise or Cooperate Lack of Participation
Procrastination Poor Quality Ineffective Peer Evaluation
Slide 18
Page 18 of 187 Common Team Problems Ineffective Leadership
Without effective leadership, teams generally have trouble sticking
to their plans and maintaining personal discipline. Although
effective leadership is essential, few people are natural leaders.
Most of us need to develop our leadership skills and to get
practice using them. Chapter 11 gives you helpful pointers on how
to perform the team leaders role most effectively.
Slide 19
Page 19 of 187 Common Team Problems Failure to Compromise or
Cooperate Occasionally one or more team members may not be able to
work cooperatively with the team. Peer pressure can often resolve
such problems.
Slide 20
Page 20 of 187 Common Team Problems Lack of Participation
Although some degree of variation in participation is normal, it is
important that all team members strive to meet the teams goals. If
it is clear that someone is not making a serious effort, team
spirit generally suffers.
Slide 21
Page 21 of 187 Common Team Problems Procrastination Some teams
dont set deadlines or establish goals and milestones. Others set
deadlines they never meet. Such teams generally dont track
performance and often fail to make decisions in a timely or logical
way. They take excessive time to get started, and they drift
through their projects rather than attacking them.
Slide 22
Page 22 of 187 Common Team Problems Poor Quality Quality
problems can come from many sources. For examples: a superficial
requirements inspection, a poorly design, or sloppy implementation
practices. When teams dont use personal reviews or team
inspections, they usually have quality problems. The results are
extensive testing, delayed schedules, long hours and an
unsatisfactory final product.
Slide 23
Page 23 of 187 Common Team Problems Ineffective Peer Evaluation
Experience has shown that peer evaluation can be invaluable for
student teams. Students are often reluctant to grade their
teammates and rarely do so with complete candor. As a result,
students often feel that the grading in team courses is not
entirely fair, particularly to the highly motivated students.
Slide 24
Page 24 of 187 What is a Team? A team consists of at least two
people, who are working toward a common goal/objective/ mission
where each person has been assigned specific roles or functions to
perform, and where completion of the mission requires some form of
dependency among the group members.
Slide 25
Page 25 of 187 Effective Teams An effective team is a group of
people so strongly knit that the whole is greater than the sum of
the parts.
Slide 26
Page 26 of 187 Effective Teams Team Cohesion Members of highly
cohesive groups communicate freely and often. Although they need
not be good friends, they work closely together and respect and
support each other. In less cohesive groups, members tend to
function as individuals. They have trouble compromising and dont
have common values and goals.
Slide 27
Page 27 of 187 Effective Teams Cont. Challenging Goals First,
these goals must be specific and measurable. Second, the teams
goals must represent a significant challenge.
Slide 28
Page 28 of 187 Effective Teams Cont. Feedback Goal tracking and
feedback are critically important. Effective teams are aware of
their performance and can see the progress they are making toward
their goals.
Slide 29
Page 29 of 187 Effective Teams Cont. Common Working Framework
All team members must feel that the tasks are achievable, must
understand their roles and responsibilities, and must agree on how
to accomplish them.
Slide 30
Page 30 of 187 How Teams Develop At the outset, most teams
start with individuals who have diverse goals. As teams jell, the
members come to accept a common set of team goals. The TSPi
supports this jelling process by walking teams through a launch
procedure. Even though the goals may be arbitrary, the team members
will pursue them with enormous energy.
Slide 31
Page 31 of 187 How TSPi Builds Teams Goals The TSPi helps
members accept the team goals by having all team members
participate in defining them.
Slide 32
Page 32 of 187 How TSPi Builds Teams Roles Immediately after
goals, the next issue is responsibilities. How can teams get all
members to take responsibility for their parts of the job? The TSPi
addresses this issue by establishing team member roles.
Slide 33
Page 33 of 187 How TSPi Builds Teams Plans After the team
agrees on its goals and roles, it next agrees on a strategy and a
plan for achieving these goals.
Slide 34
Page 34 of 187 How TSPi Builds Teams Communication among team
members When team members dont know the status of each others work,
they can not coordinate their work. The TSPi addresses this problem
by calling for regular weekly team meetings. With their defined
goals, roles and plans, teams members can communicate crisply and
concisely.
Slide 35
Page 35 of 187 How TSPi Builds Teams External Communication
Often, teams communicate with the manager or the instructor when
they are in trouble. Managers and instructors see only problems and
not successes, and that puts the team in a poor light. The team
cannot take advantage of the instructors or managers knowledge and
experience. TSPi calls for the team leader to make weekly summary
reports to the instructor.
Slide 36
Page 36 of 187 Summary Why projects fail. Common team problems.
What is a team. Effective teams. How teams develop. How TSPi builds
effective teams.
Slide 37
Page 37 of 187 Homework Impact of TSPi on Software Projects
Cuevas, G.; Calvo Manzano, J.; San Feliu, T.; Electronics, Robotics
and Automotive Mechanics Conference, 2007. CERMA 2007 25-28 Sept.
2007 Page(s):706 711 Electronics, Robotics and Automotive Mechanics
Conference, 2007. CERMA 2007 Chapter 1115
Slide 38
ALL RIGHTS RESERVED BY GUANGDONG MOBILE COMMUNICATIONS CO.,
LTD. Chapter 3 Launching a Team Project
Slide 39
Page 39 of 187 Contents Student information Product Objectives
Team Roles Team Goals Goal Setting for TSPi Team Member Goals The
Role Goals Team Meetings The First Team Meeting Data
Requirements
Slide 40
Page 40 of 187 Student Information To be most effective, teams
need a mix of talents and abilities. Team members also need to
spend time together and have complementary interests and abilities.
To provide the necessary information, the students need to complete
the INFO form. The instructor uses this information to make the
team and role assignments.INFO
Slide 41
Page 41 of 187 Product Objectives Please refer to Project
Practice .
Slide 42
Page 42 of 187 Team Roles Team Leader Development Manager
Planning Manager Quality/Process Manager Support Manager To the
extent practical, every student should be exposed to several
roles.
Slide 43
Page 43 of 187 Team Goals Goals setting is an essential step in
team formation and should usually be done at the start of every
project. The goals establish the framework for strategy and the
plan. Without defined goals, there is no orderly way to settle
arguments, negotiate strategies, or plan the work. Why Team
Goals?
Slide 44
Page 44 of 187 Set aggressive but realistic goals; Set specific
and measured goals; Goal-setting Consideration Team Goals
Slide 45
Page 45 of 187 Goal Setting for TSPi Team Goal 1: Produce a
quality product. Measure 1.1 Percent of defect found before the
first compile Process Yield 80 Measure 1.2 Number of defects found
in system test 0 Measure 1.3 Requirements functions included at
project completion 100 Team Goal 2 Run a productive and
well-managed project. Measure 2.1 Error in estimated product
size
Page 87 of 187 Defect Ratios provide insight into the quality
of the design and code review. Code review/compile defect ratio
(>2) when engineers find twice as many defects in a code review
as they find in compiling, they have generally done a good code
review. Design review/unit test defect ratio (>2) TSPi Planning
Process
Slide 88
Page 88 of 187 Development time ratios Requirement inspection /
requirement >= 25 HLD inspection / HLD >= 50 DLD / code >=
100 DLD review/DLD >= 50 Code review / code >= 50 TSPi
Planning Process
Slide 89
Page 89 of 187 A/FR Appraisal to Failure Ratio is the ratio of
the time spent in appraisal-type activities (such as reviews and
inspections) to the time spent in failure-type activities (such as
compile and test). In PSPi A/FR>2 In TSPi A/FR=1. TSPi Planning
Process
Slide 90
Page 90 of 187 Requirement reviews and inspections: < 2.0
single- spaced text pages/hour HLD reviews and inspections:
Slide 91
Page 91 of 187 Defect-injection Rates When you have data on
defect-injection rates, you have a basis for estimating how many
defects you will inject during each phase of a programming job.
TSPi Planning Process
Slide 92
Page 92 of 187 Defect-removal Rates When you have data on
defect-removal rates, you have a basis for estimating how many
defects you will remove during each phase of a programming job.
TSPi Planning Process
Slide 93
Page 93 of 187 Phase Yields refers to the percentage of the
defects in a program that were removed during a given phase. Ex If
you had 19 defects in a program at code review entry, injected 1
defect during the code review, and found 15 of these defects in the
review, then Code review yield = (defects found) / (defects in the
product) =15 / (19+1) =75% TSPi Planning Process
Slide 94
Page 94 of 187 Process Yields measures the percentage of the
defects removed before a given phase. Ex 30 defects were injected
and 20 defects were removed before compile. Thus the process yield
before compile is 66.7% (20/30). You must strive for the process
yields of 75 before the first compile and 85 before the first unit
test. TSPi Planning Process
Slide 95
Page 95 of 187 Use the TSPi tool to generate the final quality
plan on form SUMQ the team-level quality plan . P88 SUMQ TSPi
Planning Process
Slide 96
Page 96 of 187 7. Fill in the blanks in form SUMP according to
form SUMQ and form TASK. P93 SUMP 8. Produce the individual
engineer plans. 9. Balance team workload. TSPi Planning
Process
Slide 97
Page 97 of 187 Team TASK form Team SCHEDULE form Engineer TASK
form Engineer SCHEDULE form Team SUMP form Team SUMQ form Team SUMS
form. 10. Exit Criteria TSPi Planning Process
Slide 98
ALL RIGHTS RESERVED BY GUANGDONG MOBILE COMMUNICATIONS CO.,
LTD. Chapter 6 Defining the Requirements
Slide 99
Page 99 of 187 Contents Why We Need Requirements? The SRS Why
the SRS is Important? Requirements Process
Slide 100
Page 100 of 187 Why We Need Requirements Through requirements
development, your team gains a common understanding and agreement
on what to build.
Slide 101
Page 101 of 187 The SRS Focus the SRS (Software Requirements
Specification) on what the product is to do and avoid specifying
how it will be designed and built. For TSPi, you will concentrate
on the functional and operational requirements. Functional
requirements External interface requirements Design constraints
Attributes Other requirements
Slide 102
Page 102 of 187 Why SRS is Important Users generally cannot
know precisely what they need until they try to use the finished
product. Thus the requirements almost always change, and they keep
on changing until they are frozen in a product. There is no such
things as a free requirements change. All changes cost time and
money. The SRS helps you to manage changes. After the customers
have read the SRS and agreed with its contents, you can argue that
any changes will cost time and/or money.
Slide 103
Page 103 of 187 Requirements Process Need statements
Development strategy Development plan. 1. Entry Criteria
Slide 104
Page 104 of 187 2. Need Statement Review The development
manager leads the team in reviewing the product need statement and
ensures that all questions are clarified among the team members or
noted for discussion with the customer. Requirements Process
Slide 105
Page 105 of 187 3. Need Statement Clarification The development
manager reviews the list of questions and the team clarification
notes with the customer who discusses the answers with the team.
Requirements Process
Slide 106
Page 106 of 187 The development manager leads the team through
outlining the SRS document and the work to produce it The team
leader allocates the tasks among the team members and obtains
commitments for when they will complete these tasks. 4.
Requirements Task Allocation Requirements Process
Slide 107
Page 107 of 187 Each team member Produces and reviews his or
her portions of SRS document; Provides these to the development
manager. The development manager produces the SRS draft. 5.
Requirements Documentation Requirements Process
Slide 108
Page 108 of 187 6. System Test Plan The development manager
leads the team in producing and reviewing the system test plan.
Requirements Process
Slide 109
Page 109 of 187 The quality/process manager leads the team
through Inspecting the SRS draft and system test plan Identifying
questions and problems Defining who will resolve each question and
problem and when Documenting the inspection in form INS.INS 7.
Requirements and System Test Plan Inspection Requirements
Process
Slide 110
Page 110 of 187 The development manager obtains the updated SRS
and system test plan sections and Combines them into a final SRS
and system test plan Verifies traceability to the need statement or
other sources. 8. Requirements Update Requirements Process
Slide 111
Page 111 of 187 9. User SRS Review Have the end users read the
SRS and agree that it describes what they want. Requirements
Process
Slide 112
Page 112 of 187 10. Requirements Baseline The support manager
baselines an official SRS copy, which the team can now change only
by using the change control procedure (form CCR).CCR Requirements
Process
Slide 113
Page 113 of 187 The completed, inspected and updated SRS and
system test plan under configuration control All personal time,
defect and size data entered in the TSPi forms and support system
(LOGT LOGD SUMS TASK SCHEDULE SUMP SUMQ) The completed inspection
form (INS) from the requirements inspection Updated project
notebook. 11. Exit Criteria Requirements Process
Slide 114
ALL RIGHTS RESERVED BY GUANGDONG MOBILE COMMUNICATIONS CO.,
LTD. Chapter 7 Designing with Teams
Slide 115
Page 115 of 187 Contents Design Principles Using the Entire
Team Design Standards Designing for Reuse The SDS Design
Process
Slide 116
Page 116 of 187 Design Principles After the requirements have
been defined, the entire software process concerns various levels
of design. The high-level design must produce a SDS Software Design
Specification which includes the complete functional specifications
of each component, its interface and its state behavior. The
detailed design defines the logical structure, all the loop
initialization and stepping conditions, the detailed state
structure, and the state transitions for every program. High-level
design differs from detailed design only in scope and detail. In
TSPi, the high-level design process is described in the design
phase. The detailed-design process is described in the
implementation phase.
Slide 117
Page 117 of 187 Using the Entire Team The entire team
brainstorms the initial design ideas. After the team has picked a
general approach, only one or two engineers are usually needed to
document the highest level design, specify the interface, allocate
system functions among the components, and define the overall
program structure and logic Other engineers can do other tasks:
design studies, standards development, and reuse.
Slide 118
Page 118 of 187 Design Standards Naming conventions Interface
formats System and error messages Defect standards LOC counting
Design representation standards
Slide 119
Page 119 of 187 Designing for Reuse Reuse interface standards
Reuse documentation standards Reuse part quality Application
support. Reuse is a potentially powerful way to increase team
productivity. By establishing a reuse program, you can often save
engineering time in development cycles. During the high-level
design phase, a team should identify likely common functions and
proposing an initial set of reusable parts.
Slide 120
Page 120 of 187 The SDS Decide on the overall product structure
Allocate product functions to components Produce the component
external specification Decide which components and functions to
develop in each development cycle. The design process produces the
SDS (Software Design Specification), which defines the overall
product structure.
Slide 121
Page 121 of 187 Design Process A development strategy A
development plan A completed and inspected SRS 1. Entry
Criteria
Slide 122
Page 122 of 187 Defining the cycle-1 product structure Naming
the product components Allocating use cases to these components
Identifying the design tasks to be completed and documented. 2.
High-level Design The development manager leads the team through
Design Process
Slide 123
Page 123 of 187 3. Design Standards The quality/process manager
leads the effort to produce the name glossary and design standards.
Design Process
Slide 124
Page 124 of 187 4. Design Task Allocation The development
manager leads the team through outlining the SDS document and the
work to produce it. The team leader allocates the tasks among the
team members and obtains commitments for when they will complete
these tasks. Design Process
Slide 125
Page 125 of 187 Each team member Produces and reviews his or
her portions of the SDS document Provides these to the development
manager The development manager produces a composite SDS draft. 5.
The Design Specification Design Process
Slide 126
Page 126 of 187 6. Integration Test Plan The development
manager leads the team in producing and reviewing the integration
test plan. Design Process
Slide 127
Page 127 of 187 Every use case is covered and referenced in the
design The design is complete and correct The integration test plan
is adequate Each problem is recorded and fix responsibility
assigned 7. Design and Integration Test Plan Inspection The
quality/process manager leads the team through inspecting the SDS
draft and integration test plan so that The inspection is
documented in form INS and defects are recorded in LOGD. INSLOGD
Design Process
Slide 128
Page 128 of 187 The development manager obtains the updated SDS
and integration test plan sections and Combines them into a final
SDS and integration test plan Verifies traceability to the SRS 8.
Design and Integration Test Plan Update Design Process
Slide 129
Page 129 of 187 The support manager baselines an official SDS
copy, which the team can now change only by using the change
control procedure (form CCR). 9. Design Baseline Design
Process
Slide 130
Page 130 of 187 The completed, inspected and corrected SDS The
completed, inspected and corrected integration test plan The design
standard and name glossary The completed inspection forms (INS)
Updated SUMP and SUMQ forms Updated the project notebook 10. Exit
Criteria Design Process
Slide 131
ALL RIGHTS RESERVED BY GUANGDONG MOBILE COMMUNICATIONS CO.,
LTD. Chapter 8 Product Implementation
Slide 132
Page 132 of 187 Contents Design Completion Criteria
Implementation Standards Implementation Strategy Reviews and
Inspections Implementation Process
Slide 133
Page 133 of 187 Scrap , , Vocabulary
Slide 134
Page 134 of 187 Design Completion Criteria For large systems,
high-level design often requires several stages At the first level,
you subdivide the system into subsystems, components, or modules If
these subsystems are reasonably large, repeat the high-level design
process for each subsystem or component At the end, you should have
the external specifications for each subsystem, component, or
module and should also have the detailed design of the highest
level logic for the system.
Slide 135
Page 135 of 187 Implementation Standards Standards review
Naming, interface, and message standards Coding standards Size
standards Defect standards Defect prevention The implementation
standards add to and extend the standards defined during the design
phase
Slide 136
Page 136 of 187 Review the name, interface and message
standards developed during the design phase Check that the list of
the reusable routines is complete and that all the team members are
using it Review the name glossary Check the component and
subelement names and review the shared variable, parameter and file
names for consistency Check the standard interfaces and messages.
Standards Review Implementation Standards
Slide 137
Page 137 of 187 Pick the defect types that seem to be causing
the most trouble. These defects may waste the most test time, be
hardest to diagnose and fix, or otherwise be most annoying Examine
a number of defects of this type to identify particular defect
causes and divide which ones to address When you see a defect you
think you can prevent, make a process change to prevent it Assuming
this action is effective, start looking for the next defect
category and handle it the same way. Defect Prevention
Implementation Standards
Slide 138
Page 138 of 187 Implementation Strategy Review Reuse Testing
The implementation strategy should generally conform to the design
strategy
Slide 139
Page 139 of 187 Reviews and Inspections Many implementation
defects are simple transcription mistakes that result from random
keystroke errors Finding some of these errors in test can be
exceptionally hard Reviews and inspections can consider all the
paths and data values for a logical program segment. That is why
reviews and inspections are much more efficient than testing.
Slide 140
Page 140 of 187 Design Inspections It is hard to find
sophisticated design defects when doing a review or inspection of a
source program To produce quality programs, you must produce
thorough and complete design documents and then review, inspect,
and fix them before you start coding.
Slide 141
Page 141 of 187 Implementation Process A completed development
strategy and plan Completed, reviewed and updated SRS and SDS
specifications A defined and documented coding standard Available
copies of routine functional specification list, name glossary, and
all the other standards the team has adopted. 1. Entry
Criteria
Slide 142
Page 142 of 187 The development manager leads the work to
Define and plan the implementation tasks ( SUMP, SUMQ). 2.
Implementation Planning The team leader allocates the tasks among
the team members and obtains commitments for when they will
complete these tasks. 3. Task Allocation Implementation
Process
Slide 143
Page 143 of 187 The engineers produce the detailed design Do a
design review using thorough design review methods Complete forms
LOGD and LOGT. 4. Detailed Design and Design Review Implementation
Process
Slide 144
Page 144 of 187 The engineers produce the unit test plans The
engineers follow script UT to develop the unit test cases, test
procedures and test data. 5. Unit Test Plan Implementation
Process
Slide 145
Page 145 of 187 The quality/process manager leads the team in a
DLD inspection of each component Complete forms LOGD and INS. 6.
Detailed-Design Inspection Implementation Process
Slide 146
Page 146 of 187 The engineers produce the component source
code. Do a code review using a personal checklist Compile and fix
the code until it compiles without error Complete forms LOGD and
LOGT. 7. Code, Code Review and Compile Implementation Process
Slide 147
Page 147 of 187 The quality/process manager leads the team in a
code inspection of each component Complete forms INS, LOGD and
LOGT. 8. Code Inspection Implementation Process
Slide 148
Page 148 of 187 The engineers, following script UT Conduct the
unit tests Complete forms LOGD and LOGT. 9. Unit Test
Implementation Process
Slide 149
Page 149 of 187 If so, the component is accepted for
integration testing If not, the quality/process manager recommends
Either that the product be re-inspected and reworked Or that it be
scrapped and redeveloped. The quality/process manager reviews each
components data to determine if component quality meets established
team criteria. 10. Component Quality Review Implementation
Process
Slide 150
Page 150 of 187 When the components are satisfactorily
implemented and inspected, the engineers release them to the
support manager The support manager enters the components in the
configuration management system. 11. Component Release
Implementation Process
Slide 151
Page 151 of 187 Completed, inspected, configuration-controlled
components Completed INS forms for the design and code inspections
Unit test plans and support materials Updated LOGT LOGD SUMS TASK
SCHEDULE SUMP and SUMQ forms Updated project notebook. 12. Exit
Criteria Implementation Process
Slide 152
ALL RIGHTS RESERVED BY GUANGDONG MOBILE COMMUNICATIONS CO.,
LTD. Chapter 9 Integration and System Test
Slide 153
Page 153 of 187 Contents Testing Principles The TSPi Testing
Strategy Build and Integration Strategy System Test Strategy Test
Planning Tracking and Measuring Testing Documentation The Test
Process
Slide 154
Page 154 of 187 Regression Delve Stub Scaffold Terminology
Vocabulary
Slide 155
Page 155 of 187 Testing Principles In TSPi, the purpose of
testing is to assess the product and not to fix it. You should have
found and fixed almost all the defects before the testing phase.
The quality of a product is determined when it is developed. When
you put a poor-quality product into test, you generally get a
poor-quality product out of test.
Slide 156
Page 156 of 187 TSPi Testing Strategy Build the System Using
the developed and unit-tested parts, build the system Integration
Test Integration-test the system to verify that it is properly
built, that all the parts are present, and that they function
together System Test System-test the product to validate that it
does what the system requirements call for Regression Test In
subsequent cycles, regression tests are also needed to ensure that
the development work for this cycle has not unintentionally changed
the functionality or performance produced in prior cycles.
Slide 157
Page 157 of 187 Build and Integration Strategy The purpose of
the build process is to ensure that all needed parts are present,
to assemble a working system, and to provide this system to
integration and system test. Integration testing should merely
check that all the components are present and that all their calls
and other interactions work. You should not test the components
functions.
Slide 158
Page 158 of 187 Put all the parts together and see whether they
work. Advantage it requires the least amount of test development
Disadvantage it is rarely successful, particularly with
poor-quality systems. 1. Big-Bang Strategy Build and Integration
Strategy
Slide 159
Page 159 of 187 Advantage With each addition, you look for
problems with the newly added parts Disadvantage This strategy
requires more test development work. 2. The One-at-a-time Strategy
Build and Integration Strategy
Slide 160
Page 160 of 187 This strategy is to add parts in clusters. You
identify a class of related components and integrate them. 3. The
Cluster Strategy Build and Integration Strategy
Slide 161
Page 161 of 187 Advantage You can detect system-wide issues
early Disadvantage it usually requires large numbers of stubs or
special scaffolding to provide dummy returns for all the functions
that are not yet available. 4. The Flat-system Strategy This
strategy is to integrate all the highest level parts first and then
delve down into successive system layers in parallel. Build and
Integration Strategy
Slide 162
Page 162 of 187 System Test Strategy Firstly, test each of the
systems intended functions Check operation under stress conditions,
evaluate usability Finally, measure performance. 1. The
Function-first Strategy
Slide 163
Page 163 of 187 Cover all aspects of each functional area
before moving to the next functional area. You might start by
testing Numerical calculations for normal and adverse operation
Usability Performance Quality 2. The Functional Area Strategy
System Test Strategy
Slide 164
Page 164 of 187 Test lower level functions for normal, abnormal
and stress behavior Move to the next higher level and test
functional aggregates to ensure that they work together. Check them
under various normal and stress conditions Continue testing at
progressively higher levels until you have covered the full system.
3. Combining the Preceding-two Strategy System Test Strategy
Slide 165
Page 165 of 187 Test the highest level functions and work down,
doing normal and stress tests 4. Reversing the Preceding Strategy
System Test Strategy
Slide 166
Page 166 of 187 Test Planning A list of all the testing steps
to be performed The supporting materials required for each test The
results that the tests are to produce An estimate of the
defect-free run time, the defects to be found, and total time for
each test An estimate of the work required to develop each item in
the test plan. The completed testing plan should have
Slide 167
Page 167 of 187 Tracking and Measuring Testing The test log
(LOGTEST FORM) contains a summary of the tests run and the results
obtained LOGTEST FORM With the test log data, you can readily
determine which tests were run and which found the most defects You
can also determine the test run time and the defects found per
testing hour Data from this log can help you select the most
efficient strategy for regression-testing modified programs.
Slide 168
Page 168 of 187 Documentation In the TSPi test phase, part of
the team drafts and reviews the user documentation while the rest
of the team conducts the tests. A well-designed manual should be
organized around the readers needs and not the products structure.
Generally The first section should address what the user needs to
know first how to get started Next, you might explain what the user
can do with the product Finally, make it easy for people to find
what they want to know.
Slide 169
Page 169 of 187 Write short sentences Use simple words and
phrases Use lots of lists and bulleted items. Documentation Writing
Style
Page 171 of 187 The Test Process You have the completed and
inspected SRS and SDS specifications You have the implemented,
inspected and unit-tested components under configuration controll
For TESTn, you have a configuration- controlled prior version of
the product. 1. Entry Criteria
Slide 172
Page 172 of 187 Define any required build processes and
procedures Develop the integration test procedures and facilities
Develop the system test procedures and facilities Measure the size
and running time for each test Review the test materials and
correct errors. 2. Test Development The Test Process
Slide 173
Page 173 of 187 Check all the needed parts to ensure that they
are on hand and meet their dependency requirements Review the items
supplied for the build and identify any missing pieces Check the
proposed build for consistency and completeness. Build the product
and provide it to integration test Record all defects in the defect
log (LOGD) and all times in LOGTEST form. 3. Build The Test
Process
Slide 174
Page 174 of 187 Check the completeness of the built product Run
the planned integration tests Record the test data in form LOGTEST
If defects are found, complete a LOGD entry for every defect The
quality/process manager should determine whether testing should
continue or abort integration testing and conduct a complete
inspection of these defective components. 4. Integration Test The
Test Process
Slide 175
Page 175 of 187 Test the product for normal and stress
conditions Test the product for installation Record all test
activities in form LOGTEST Record all defects in form LOGD. 5.
System Test The Test Process
Slide 176
Page 176 of 187 Produce the user-documentation outline and
tasks Allocate these tasks to the documentation team Review the
outline with the test team for completeness Draft the first-cycle
user documentation Review, correct and produce the user
documentation. 6. Documentation The Test Process
Slide 177
Page 177 of 187 A completed, integrated and system-tested
product version A complete test record in form LOGTEST Completed
LOGD entries and a defect analysis for every defect found Completed
and reviewed user documentation Updated SUMP, SUMQ, TASK, SCHEDULE
and LOGT forms A copy of all the test data and forms in the project
notebook. 7. Exit Criteria The Test Process
Slide 178
ALL RIGHTS RESERVED BY GUANGDONG MOBILE COMMUNICATIONS CO.,
LTD. Chapter 10 The Postmortem
Slide 179
Page 179 of 187 Contents Why We Need a Postmortem? The
Postmortem Process
Slide 180
Page 180 of 187 Why We Need a Postmortem The postmortem
provides a structured way to improve your personal and team
processes The TSPi uses form PIP (Process Improvement Proposal) to
note any improvement ideas that occur to you.
Slide 181
Page 181 of 187 Postmortem Process The team has completed and
tested the product The engineers have gathered all the data and
completed all the required forms. 1. Entry Criteria
Slide 182
Page 182 of 187 Analyze project data and identify problem and
improvement areas Compare both teams and each engineers personal
performance with the quality plan. Assess where the process fell
short and what could be done to improve it in the future Submit
PIPs on these improvement suggestions. 2. Review Process Data
Postmortem Process
Slide 183
Page 183 of 187 Where they were effective Where there is room
for improvement. Team leader leads the team in evaluating the
effective of the team roles 3. Evaluate Role Performance Postmortem
Process
Slide 184
Page 184 of 187 Contents Summary Roles Reports Leadership
Development Planning Quality/Process Support Engineer Reports 4.
Prepare Cycle-1 Report Postmortem Process
Slide 185
Page 185 of 187 Each engineer completes an evaluation of the
team and of each team role using form PEER.PEER 5. Role Evaluation
Postmortem Process
Slide 186
Page 186 of 187 The team has produced a high-quality product,
together with all the required documentation The completed product
is under configuration control The process data have been
evaluated, and PIPs have been completed and submitted The role
evaluations have been completed (PEER) All TSPi forms have been
completed The project notebook is updated. 6. Exit Criteria
Postmortem Process