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.
