TMP3413

Software
Engineering Lab

Lecture 10:
The Postmortem
Topics
 Why we need a postmortem?
 What a postmortem can do for you?
 The process improvement proposal.
 The TSPi postmortem scripts.
1.0 Why we need a postmortem?
(cont…)
 Continuous improvement is important for
software creators
 Software provides the logic for almost all
new products and services in almost
every industry.
 Knowing how to develop software is
critical skill.
 the team should view every project as a
chance to improve.
1.0 Why we need a postmortem?
 The postmortem is the final step in the
TSP process
 Itprovides an orderly way to identity
areas that need to be improved and to
make the needed changes.
 Team members need to review their
team’s work to ensure that they have
completed all the needed task and
recorded all the required data.
2.0 What a postmortem can do for us?
(cont…)
 Every TSP development cycle ends with a
postmortem, which provides a structured
way to learn and improve.
 In the postmortem, we examine what we did
compared to what we planned to do.
 By using the postmortem process, we will see
changes from one cycle to the next.
 The first TSP cycle provides a baseline.
2.0 What a postmortem can do for us?

 We assess the products produced, the effort

spent to produce them and the process steps
that we followed.
 Determine the accuracy of plans and suitability
of the processes
 Identify problem, determine causes and
prevention measures
 Postmortem can identify specific improvement
opportunities and decide where and how to
incorporate changes into personal and team
processes.
3.0 The process Improvement Proposal
(cont…)
 The key to successful improvement is to
focus on small changes.
 There will exist major opportunities, but they
will be rare.
 As we assess our work, however we will see
many small ways to improve things.
 Each small improvement will help a little,
and over time , by compounding these
many small changes we will see a significant
overall change.
3.0 The process Improvement
Proposal
 Both PSP and TSP uses the Process
Improvement Proposal (PIP).
 Any improvement ideas and small changes
can be added in the PIP form.
 This might include better personal practices,
improved tools, process changes and almost
anything else.
 When the postmortem comes, the team will
be able to reconstruct the these ideas and
deal with them in an elderly way.
4.0 The TSP Postmortem Scripts
 The difference is PM1 calls for the
instructor to describe the PM process
 In PMn, the opening discussion time is
used to cover any problem or lesson
from previous postmortem.
 The product of postmortem is the cycle
report.
 Section describing what you did in the cycle,
 Comparing it with the plan and with any
prior development cycle
 Calls for a team discussion of the
project data and a review and critique
of the roles.
 In this discussion, concentrate on topics
most relevant to the member’s role
responsibilities and note any ideas or
relevant facts and data.
The TSP Postmortem Scripts
Purpose
To gather, analyze, and record
project data.
 to evaluate the team’s and each
role’s performance.
 to identify ways to improve the
cycle process
To produce the cycle report
 The suggested cycle report outline:
Table of contents
Summary
Role Reports
Leadership
Development
Planning
Process
Quality
Support
Engineer Reports

 The
team leader produces the report table
and write report summary that briefly
describes the report’s key findings.
Entry Criteria
The postmortem entry criteria are
as follows:
The team has completed and
tested the product
The engineers have gathered all
the data and completed all the
required forms.
All the engineers have read this
chapter.
Review Process Data
 The objectives of this review are to:
 Examine the date on what the team and
team members did
 Identify where the process worked and
where it did not
 Compare the team’s performance with its
goals and plans
 Identify problem areas and needs for
improvement
 Devise process improvements
Quality Review
 Compare both the team’s and each
engineer’s personal performance with quality
plan.
 Address the following problem
 How did actual performance compare with the
plan?
 What lessons can we learn from this experience?
 Should we use different personal or team criteria in
the future?
 Where did this team do well and where did it fall
short?
 How did your performance compare with what other
teams have done?
 Where should we modify the processes we used?
Role Evaluations
 The team leader leads the team through
examining each role.
 focus on objective facts.
 Start with the team leader’s role and then
review the other roles.
 Consider the following questions;
 What worked?
 Where were there problems?
 Where is there room for improvement?
 What improvement goals would make sense
for the next development project?
Role Evaluations
 Each team member prepares a personal copy
of form PEER.
 All members must give their views on the
team’s performance and on how each role
was performed.
 These reviews provide an opportunity to
recognize good work and to suggest where
roles or tasks could be better handled in the
future.
TSPi TEAM and PEER
Evaluation:
FORM PEER
Exit Criteria
 The postmortem exit criteria are as
follows:
 The team has produced a high-quality
product, together with all the required
documentation.
 The completed product is under
configuration control.
 The role evaluations have been completed
and submitted.
 All TSP forms have been completed for the
system and all its components parts.
Summary (cont…)

 The postmortem is the final step in the

TSP process.
 It provide a structured way to improve
personal and team performance.
 Every TSP development cycle will ends
with a postmortem.
Summary (cont..)
 The
postmortem starts with the
quality/process manager leading the
team through a review of the team’s
data.
 Thisreview examines what you did, identifies
where the process worked and where it did
not work, and
 compares the team’s performance with its
goals and plans.
Summary (cont…)
 Next,the team leader leads the team in
evaluating each role.
 These evaluations focus on what worked,
where there were problems, and where
there is room for improvement.
 The team reviews the team leader's role first
and then reviews each of the others.
 Finally, the team evaluates the faculty and
facilities.
 Throughout all the evaluations, concentrate
on suggested areas for improvement, being
specific wherever possible.
Summary (cont…)
 The cycle report describes what you
produced, the process that you used, and the
roles you performed.
 It describes what worked and what did not work
and suggests how to do better the next time.
 Keep the report brief and factual.
 Emphasize the lessons learned and how to use
these lessons to do better work.
 compare performance with prior development
cycles and highlight any trends.
Summary (cont…)
 In the final postmortem step, every
team member completes a PEER form.
 give your personal views on the team’s and
each role’s performance.
 making additional comments on any topics
on the back of the form or on separate
sheets.
 Write the evaluations in a constructive way
and focus on improvement opportunities.