International Journal of Basic & Applied Sciences IJBAS-IJENS Vol:09 No:10
33
Application and Evaluation of The
Personal Software Process
Hamdy K.Elminir#1 , Eman A.Khereba *1 , Mohamed Abu Elsoud#1 , Ibrahim El-Hennawy#2
1
Computer Science department, Mansoura University, 60 El Gomhuria st., Mansoura, Egypt
2
Computer Science department, Zagazig University, Zagazig, Egypt
*Corresponding Author: eman.khereba@yahoo.com
Abstract—
S oftware organizations differ from other
manufacturing organizations, since these software organizations
depend mainly on individuals and team works rather than
machines or raw materials. Enhancing individuals and team
works capabilities is the key solution to improve quality and
productivity levels.
Hence, Individual engineers need a quality improvement
technique to improve their performance by
bringing
discipline to the way they develop software and manage their
work to produce quality products within budget and on schedule.
This paper will propose a case study showing the application and
evaluation of the Personal S oftware Process (PS P), which
recommends applying some skills and methods that concerns the
individual engineer her/himself, like understating the meaning of
work quality, and how to estimate time and effort in order to be
able to make the right project plans which contain some
estimated data that are close to the actual data. Hence, in our
study, PS P will focus on two principles, improving individuals’
productivity, and products and process quality.
Index Term— PS P; Personal software process, Productivity,
Productivity time, Interruption time, Quality, size estimation
accuracy, effort estimation accuracy, process yield, defect
density, COQ; Cost of Quality, LOC; Lines of Code
I.
INT RODUCT ION
The success of organizations that produce software-intensive
systems depends on well managed software development
processes. Implementing disciplined software methods,
however, is often challenging. Organizations seem to know
what they want their individuals to be doing, but they struggle
with how to do it. The Personal Software Process (PSP) was
designed to provide both a strategy and a set of operational
procedures for using disciplined software process methods at
the individual and team levels. Organizations that have
implemented the PSP have experienced significant
improvements in the quality of their software systems and
reduced schedule deviation [1, 2].
The goal of the Personal Software Process (PSP) is to
help individual programmers improve their own, individual
software development process by using a disciplined and
measurable programming skills improvement process. The
PSP process steps the individual engineer through a series of
small projects during which the engineer collects
measurements on defect rates, defect types, and other
indicators of engineer productivity and effectiveness in order
to better understand and appreciate their strength and
weaknesses as an engineer.
This paper includes detailed presentations of the analyses
conducted on size and effort estimation accuracy, process
yield, defect density, and productivity. The paper also
includes other observations uncovered during the statistical
analysis and study conclusions which contain experiences of
and benefits realized by first-time PSP individuals.
We hope that by walking through this first-time individuals’
journey of using the PSP, we illustrate how the PSP creates an
environment where skilled engineers can apply disciplined
methods working on a cohesive and dedicated team.
II.
RELAT ED W ORK
Current research on software development processes intends
to define the process elements that constitute good practices,
leaving implementation and enactment of the process to
organizations. Some of these approaches include CMM [3],
CMMI [4], SPICE [5] and Bootstrap [6]. However, these
models are very descriptive in the sense that they explain
essential attributes that would be expected to characterize an
organization at a particular maturity level, but they specify
neither how to improve nor the specific means to get into a
particular maturity level. But, as dis cussed by the research
community, also important is the way processes evolve with
the changing needs of the development organization. In
addition, projects must adopt the process with some level of
detail for the organization. Process modeling techniques are
useful in defining the process, especially in the upper levels of
maturity models like CMMI. Curtis, Kellner and Over
discussed some approaches using process modeling to support
process improvement, software project management and
Process-centered
software
engineering
environments
(PCSEEs) [7].
The Software Process Management System (SPMS)
development identified and addressed the need for process
models to be reusable, to support multiple views, to recognize
process, product and human interactions to sup port process
changes during development projects, and to support historical
recording of the process over long periods of time [8].
Until shortly after World War II, the quality strategy in
most industrial organizations was based almost entirely on
testing. Groups typically established special quality
departments to find and fix problems after products had been
produced. It was not until the 1970s and 1980s that W.
Edwards Deming and J.M. Juran convinced U.S. industry to
focus on improving the way people did their jobs [9, 10]. In
the succeeding years, this focus on working processes has
been responsible for major improvements in the quality of
automobiles, electronics, or almost any other kind of product.
The traditional test-and-fix strategy is now recognized as
expensive, time-consuming, and ineffective for engineering
and manufacturing work.
Even though most industrial organizations have now adopted
modern quality principles, the software community has
continued to rely on testing as the principal quality
96010-1212 IJBAS-IJENS © December 2009 IJENS
IJENS
International Journal of Basic & Applied Sciences IJBAS-IJENS Vol:09 No:10
management method. For software, the first major step in the
direction pioneered by Deming and Juran was taken by
Michael Fagan when in 1976 he introduced software
inspections [11, 12]. By using inspections, organizations have
substantially improved software quality.
Another significant step in software quality improvement was
taken with the initial introduction of the Capability Maturity
principal focus was on the management system and the
support and assistance provided to the development engineers.
The CMM has had a substantial positive effect on the
performance of software organizations [15].
A further significant step in software quality improvement
was taken with the Personal Software Process (PSP) [13]. The
PSP extends the improvement process to the people who
actually do the work—the practicing engineers. The PSP
concentrates on the work practices of the individual engineers.
The principle behind the PSP is that to produce quality
software systems, every engineer who works on the system
must do quality work.
The PSP is designed to help software professionals
consistently use sound engineering practices.
It shows them how to plan and track their work, use a defined
and measured process, establish measurable goals, and track
performance against these goals. The PSP shows engineers
how to manage quality from the beginning of the job, how to
analyze the results of each job, and how to use the results to
improve the process for the next project.
III.
PROBLEM DEFINITION
A. The problem of improving personal practices
Perhaps the most critical issue in improving the state of
software practice is getting software engineers to use
improved methods. This is a nontrivial problem, particularly
because even intelligent people often will not do things that
common logic, experience, and even hard evidence suggests
that they should. Many software engineers thus do not use
known best methods, even when their managers tell them to
do so.
The reasons for these both explain why process improvement
is so difficult and suggests logic for addressing the problem.
In summary these reasons are:
(1) Once engineers have learned how to develop small
programs that work, they have also established some
basic personal practices.
(2) The more engineers use and reinforce these initial
methods, the more ingrained they become and the
harder they are to change.
(3) Engineers have found that many impressivesounding tools and techniques do not provide their
promised benefits. It is therefore hard to convince
them that some new methods will help them to do
better work.
(4) Since no one generally observes the methods software
engineers use, no one will know how they work. Thus
engineers don't have to change their working methods
if they don't want to.
B. Solution
34
The problems of improving the personal practices of software
engineers were our main goal, so, when we had the
opportunity, we started a study of how process improvement
principles would apply to individual software work.
The purpose of this paper is to provide results on the use of
the PSP.
The paper starts with an overview of the PSP to provide a
context for the results here. This is followed by a detailed
discussion and analysis for the PSP first principle, which
concerns individuals’ interruptions handling in order to
increase their actual working time and decrease their
interruptions time, another discussion and analysis is being
held in order to cover the second PSP principle which
concerns increasing individuals’ productivity, and product and
process quality using PSP planning and measurement forms,
Development and data collection processes are also included
to provide additional context for understanding the results.
Next, we summarize the performance after applying two
medium sized projects, with two s imilar tasks for each
engineer, of a medium size software organization that has
practiced the PSP. Then, we conclude our analysis findings
and suggest improvements for future work.
IV.
PERSONAL SOFT WARE PROCESS (PSP)
The Personal Software Process (PSP) provides engineers with
a disciplined personal framework for doing software work.
The PSP process consists of a set of methods, forms, and
scripts that show software engineers how to plan, measure,
and manage their work.
The PSP is designed for use with any programming language
or design methodology and it can be used for most aspects of
software work, including writing requirements, running tests,
defining processes, and repairing defects. When engineers use
the PSP, the recommended process goal is to produce zerodefect products on schedule and within planned costs.
A. PSP Basics
The PSP design is based on the following planning and
quality Basics:
(1) Every engineer is different; to be most effective,
engineers must plan their work and they must base their
plans on their own personal data.
(2) To consistently improve their performance, engineers
must personally use well-defined and measured
processes.
(3) To produce quality products, engineers must feel
personally responsible for the quality of their products.
Superior products are not produced by mistake; engineers
must strive to do quality work.
(4) It costs less to find and fix defects earlier in a process
than later.
(5) It is more efficient to prevent defects than to find and fix
them.
(6) The right way is always the fastest and cheapest way to
do a job.
B. PSP Structure
The structure of the PSP process is shown conceptually in
Fig. 1 [16]. Starting with a requirements statement, the first
step in the PSP process is planning. There is a planning script
that guides this work and a plan s ummary for recording the
96010-1212 IJBAS-IJENS © December 2009 IJENS
IJENS
International Journal of Basic & Applied Sciences IJBAS-IJENS Vol:09 No:10
planning data. While the engineers are following the script to
do the work, they record their time and defect data on the time
and defect logs. At the end of the job, during the postmortem
phase (PM), they summarize the time and defect data from the
logs, measure the program or task size, and enter these data in
the plan summary form. When done, they deliver the finished
product along with the completed plan summary form.
35
A. PSP first principle
1) Handling interruptions:
In the PSP, engineers use the time recording log to measure
the time spent in each task. In this log, they note the time they
started working on a task, the time when they stopped the
task, and any interruption time. For example, an interruption
would be a phone call, a brief break, or any other type of
interruptions. By tracking time precisely, engineers track the
effort actually spent on project tasks. Since interruption time
is essentially random, ignoring these times would add a large
random error into the time data and reduce estimating
accuracy.
The form used for recording time is called ―Time Recording
Log‖. The top of the form is called the header and it has
spaces for engineer’s name, department, and the date of
header information completion. The columns in the body of
the form are for recording the time data. Each time period is
entered on one line of the form as follows:
Date: the date of doing some activity, like programming or
reading.
Start: The start time of the activity.
Stop: The stop time of the activity.
Interruption Time: Any time lost due to interruptions
Delta Time: The time spent on main activities, between the
start and stop times, without interruptions
Activity: A descriptive name for the task.
Fig.. 1. PSP process flow
C. PSP Objectives
The PSP aims to provide software engineers with
disciplined methods for improving personal software
development processes. The PSP helps software engineers to:
 Improve their estimating and planning skills.
 Make commitments they can keep.
 Manage the quality of their projects.
 Reduce the number of defects in their work.
The goal of the PSP is to help developers produce quality,
zero-defect, products on schedule. Low-defect and zero defect
products have become the reality for some developers.
V.
CASE ST UDY
To make realistic plans, we had to apply the first principle
of the PSP, which focuses on estimating and evaluating
individuals’ performance then improving it in order to
improve the overall productivity level in the organization.
The way to improve the productivity and quality of work is to
start by understanding what is currently done inside the
software organization. This means that we have to know the
tasks that are done, how they are done, and the obtained
results.
We had to track and understand the way time is currently
spent.
2) Handling interruptions implementation and obtained
results:
Here, we began working with 5 engineers, we refer to
them as ―E1‖ a project manager, two developers ―E2‖ and
―E3‖, and two designers ―E4‖ and ―E5‖; where ―E5‖ is an
under training designer and this was a suitable opportunity to
follow-up, analyze and evaluate her performance in general, in
addition to evaluating her work productivity level. Every
engineer has been exposed to fill-in this log with all activities
of his working day over 4 weeks with five days per every
week and working hours are 9 hours per day, then they began
recording their start and stop time including their
interruptions. We had to gather data of the first week firstly,
and analyze them to obtain results about what is currently
done, main activities for each individual, and main
interruption that affect their work and waste time. After data
gathering of the first week, we will have to find the percentage
of time spent doing the main activities for every working day
and the percentage of interruptions during that day, to show
engineers their productivity percentages and what
interruptions that affect their work and what are their
percentages too, in order to realize what really affects their
work and waste their time and also try to eliminate these
interruptions as soon as possible.
Here, we began to present a brief introduction or
training to the individuals about this approach, and we
delivered the time recording log to every one of them to begin
filling-in every action happens during the working day in a
timely manner.
96010-1212 IJBAS-IJENS © December 2009 IJENS
IJENS
International Journal of Basic & Applied Sciences IJBAS-IJENS Vol:09 No:10
Before starting filling-in the time recording log, we
have arranged for a meeting including the five engineers to
determine their main working activities and the main
interruptions that affects their work to be included in their
logs. They determined their common working activities to be
like, emails whether for reading or writing or attachments,
browsing, reading, and talking about work, in addition to other
work specifications that each individual engineer practices.
About their common interruptions, they mentioned their
interruptions to be like, breakfast, phone calls, prayer, talking
with colleagues away from working times, lunch breaks, in
addition to other interruptions that concerns each individu al
like printing some paper, sudden meetings with clients,
helping other colleague, going to the commerce chamber,
making a change in a template or a layout design, … etc.
They have also determined their common working
activities to have a naming convention to differentiate them
36
from interrupting actions, and this naming convention is ―W_
activity name‖ for main working activities and ―I_
Interruption name‖ for interruptions, for example ―W_
Programming‖ and ―W _Browsing‖, represent programming
and browsing activities are for favor of work, in contrary with
―I_ Browsing‖ and ―I_ Lunch Break‖, which represent that
time is spent in favor of interruption like browsing for
entertainment or having a break for lunch.
After the end of the first week, we have gathered the
five time recording logs for the five engineers, and began to
read them carefully in order to analyze each one’s
performance; in both directions: estimating total productivity
time percentage and total interruption time percentage.
Table I shows the time recording logs for E2 during his
first week of work after having his first training on how to
record in the time recording log.
T ABLE I
E2’s T ime Recording Log
Time Recording Log
Engineer
E2
Name:
Department:
Project Development
9-M ay
Date:
Date
9-M ay
10-M ay
S tart
S top
Interruption
Time
9:05
9:17
0:12
9:20
9:29
9:30
9:58
9:59
10:31
10:32
10:47
10:49
13:12
13:09
13:25
13:25
15:26
15:28
16:03
0:35
I_ Lunch Break
16:07
16:30
0:23
I_ Prayer
16:32
16:38
16:39
16:53
16:54
Totals
9:01
18:08
9:20
9:33
0:13
W_ Email
9:34
10:25
0:51
W_ Follow-up Juniors
10:27
13:15
2:48
W_ Programming
13:17
13:38
0:21
I_ Prayer
13:41
13:51
0:10
I_ Browsing
13:52
14:56
14:57
15:05
15:06
16:13
16:14
16:14
16:37
16:36
Delta Time
I_ Breakfast
0:09
0:28
9:18
W_ Email
I_ Talking
0:32
0:15
W_ Follow-up juniors
I_ Phone
2:23
0:16
W_ Programming
I_ Prayer
2:01
0:06
0:14
2:23
0:17
Activity
W_ Programming
W_ Talking
I_ Browsing
1:14
6:25
W_ Programming
I_ Breakfast
1:04
0:08
W_ Programming
I_ Phone
1:07
W_ Programming
0:23
W_ Talking
I_ Prayer
0:22
96010-1212 IJBAS-IJENS © December 2009 IJENS
IJENS
International Journal of Basic & Applied Sciences IJBAS-IJENS Vol:09 No:10
11-M ay
16:37
16:50
17:13
16:49
17:12
17:22
17:23
Totals
17:54
9:32
9:53
9:54
9:58
0:04
W_ Email
9:58
13:10
3:12
W_ Programming
13:11
13:39
13:40
14:07
0:27
I_ Follow-up Juniors
14:08
14:19
0:11
W_ Reading
14:19
14:53
0:34
Programming
14:54
15:33
0:39
W_ Browsing
15:34
16:26
0:52
Programming
16:27
16:35
0:08
Phone
16:36
16:50
0:14
I_ Talking
16:51
17:06
0:15
I_ Other Interruptions
17:07
17:24
0:17
Prayer
17:25
17:42
0:17
I_ Browsing
17:43
18:19
0:36
I_ Lunch Break
18:20
18:42
13-M ay
0:09
1:52
0:31
7:06
0:21
Totals
12-M ay
0:12
0:22
I_ Talking
I_ Lunch Break
W_ Browsing
W_ Reading
I_ Breakfast
0:28
W_ Prayer
0:22
2:36
W_ Talking
6:21
9:08
9:15
0:07
9:16
9:18
I_ Breakfast
9:18
9:28
9:29
10:08
0:39
W_ Reading
10:09
12:14
2:05
W_ Programming
12:15
12:31
0:16
I_ Phone
12:32
12:53
0:21
I_ Other Interruptions
12:54
13:38
13:39
14:03
14:05
16:16
2:11
W_ Programming
16:17
17:01
0:44
W_ Follow-up Juniors
17:02
17:42
0:40
I_ Lunch Break
17:43
18:03
0:20
I_ Prayer
18:04
Totals
18:20
9:08
9:26
9:27
9:50
0:23
W_ Email
9:51
10:57
1:06
W_ Follow-up Juniors
10:58
12:58
2:00
W_ Programming
12:59
13:22
0:23
I_ Talking
13:23
13:33
0:10
I_ Prayer
13:34
14:00
0:26
I_ Phone
14:01
14:19
0:18
I_ Browsing
14:20
14:38
0:02
0:10
W_ Email
I_ Talking
0:44
0:24
2:18
37
W_ Browsing
I_ Prayer
0:16
6:41
0:18
W_ Talking
I_ Breakfast
0:18
96010-1212 IJBAS-IJENS © December 2009 IJENS
W_ Talking
IJENS
International Journal of Basic & Applied Sciences IJBAS-IJENS Vol:09 No:10
38
14:39
15:21
0:42
W_ Browsing
15:22
15:57
0:35
W_ Programming
15:59
16:05
16:07
18:22
0:06
I_ Prayer
2:15
Totals
1:41
W_ Programming
7:19
After recording these data during the first week, we
have categorized and analyzed it to know exactly the
percentage of time spent doing the main work activities and
the percentage of interruptions that affects the work. Here, we
have used a form called weekly activity summary like this
shown in Table II which categorizes the main working
activities that the engineers have frequently practiced during
their first week and we have recorded them as shown in Table
II, III, IV, V, and VI respectively
T ABLE II
E1’s Weekly Activity Summary for the first week
We e k1
E1
Activity
W_
Assigning
Task
9-Jun
W_
Browsing
W_
Customer
Service
W_
Email
W_
Followup
Seniors
work
0:19
0:35
3:02
0:31
10-Jun
0:05
0:24
1:57
11-Jun
0:20
0:33
12-Jun
0:14
W_
Managing
Projects
Tasks
W_
Reading
W_
Phone
W_
Talking
Total
Time
1:03
0:16
0:22
6:08
0:16
1:03
0:43
0:24
4:52
0:53
0:26
0:15
0:14
0:17
0:14
4:57
0:56
1:28
0:15
2:11
0:59
0:22
0:18
6:43
0:48
0:16
0:17
0:16
0:24
0:21
2:22
0:58
3:16
7:36
1:45
4:48
1:45
1:13
2:02
1:39
25:02
2.15%
7.26%
16.89%
3.89%
10.67%
3.89%
2.70%
4.52%
3.67%
55.63%
Date
13-Jun
Totals
Productivity
Time
Pe rce ntage
1:45
T ABLE III
E2’s Weekly Activity Summary for the first week
Week1
E2
Activity
W_
Programming
W_
Reading
W_ Follow-up
Juniors
W_
Browsing
W_
Email
W_
Talking
Total
Time
0:09
0:06
6:25
Date
9-Jun
5:38
0:32
10-Jun
4:59
0:31
0:51
0:09
0:13
0:23
7:06
11-Jun
4:38
0:11
0:27
0:39
0:04
0:22
6:21
12-Jun
4:16
0:39
0:44
0:44
0:02
0:16
6:41
13-Jun
4:50
1:06
0:42
0:23
0:18
7:19
Totals
24:21:00
1:21:00
3:40:00
2:14:00
0:51:00
1:25:00
33:52:00
Productivity Time
Percentage
54.11%
3.00%
8.15%
4.96%
1.89%
3.15%
75.26%
96010-1212 IJBAS-IJENS © December 2009 IJENS
IJENS
International Journal of Basic & Applied Sciences IJBAS-IJENS Vol:09 No:10
39
T ABLE IV
E3’s Weekly Activity Summary for the first week
Week1
E3
Activity
W_
Programming
Date
9-Jun
10-Jun
11-Jun
12-Jun
13-Jun
4:02
3:31
4:19
3:31
3:04
Totals
18:27:00
Productivity Time
Percentage
41.00%
W_ Follow-up
Juniors
W_
Reading
W_ Browsing
1:11
1:29
0:42
0:31
1:04
0:12
0:18
1:55:00
4:57:00
2:40:00
4.26%
11.00%
5.93%
0:43
1:12
1:07
1:03
W_
Email
W_
Talking
Total
Time
0:19
0:20
0:08
0:06
0:24
1:17:0
0
0:10
0:09
0:31
0:08
5:54:00
6:30:00
5:40:00
6:35:00
5:35:00
0:58:00
30:14:00
2.15%
67.19%
2.85%
T ABLE V
E4’s Weekly Activity Summary for the first week
Week1
E4
Activity
W_ Designing
W_
Reading
W_ Follow-up
Juniors
W_
Browsing
W_ Email
W_
Talking
Total
Time
0:11
0:32
0:05
0:10
5:49
2:38
1:33
0:08
0:14
6:35
0:14
0:19
0:03
0:05
3:44
Date
9-Jun
4:51
10-Jun
1:00
11-Jun
3:03
12-Jun
3:51
0:16
0:21
0:49
0:12
0:23
5:52
13-Jun
3:44
0:18
0:57
1:52
0:27
0:28
Totals
16:29:00
1:36:00
4:21:00
5:05:00
0:55:00
1:20:00
7:46
29:46:0
0
Productivity Time
Percentage
36.63%
3.56%
9.67%
11.30%
2.04%
2.96%
66.15%
1:02
T ABLE VI
E5’s Weekly Activity Summary for the first week
Week1
Activity
E5
W_ Designing
W_
Reading
W_
Browsing
W_ Email
W_
Talking
Total Time
0:09
0:16
3:09
1:33
0:08
0:14
4:12
0:19
0:08
0:29
3:59
Date
9-Jun
2:44
10-Jun
1:15
11-Jun
3:03
12-Jun
2:32
0:16
0:49
0:09
0:23
4:09
13-Jun
Totals
1:48
11:22:00
0:18
1:36:00
1:52
4:33:00
0:07
0:41:00
0:17
1:39:00
4:22
19:51:00
Productivity Time
Percentage
25.26%
3.56%
10.11%
1.52%
3.67%
44.11%
1:02
After categorizing these main working activities and
calculating the total time spent practicing them, we had to
know this time percentage out of the total required working
hours all over the week, which are 45 hours weekly; 9 hours
per day over 5 days for a week, in addition to the percentage
of time spent practicing every working activity.
96010-1212 IJBAS-IJENS © December 2009 IJENS
IJENS
International Journal of Basic & Applied Sciences IJBAS-IJENS Vol:09 No:10
After calculating this percentage, we have reached
that the productivity time percentage for E1, E2, E3, E4, and
E5 in week1.
Then, we had clarified this result using fig.s for
further comparisons of weekly productivity results and
presentations that will let us; the managers, professors, and the
40
engineers themselves follow-up the organization productivity
status every week.
Then we had categorized the interruptions that
interrupted E1, E2, E3, E4, and E5 during this week, and we
had found the result is as shown in Table VII, VIII, IX, X, and
XI respectively.
T ABLE VII
E1’s Weekly work interruptions for the first week
Week 1
E1
Interruption
I_
Browsing
I_
Breakfast
I_ Other
Interruptions
I_
Phone
I_
Prayer
I_ Talking
Total Time
9-Jun
0:49
0:12
0:16
0:24
0:50
0:19
2:50
10-Jun
1:07
0:22
1:47
0:08
0:42
0:03
4:09
11-Jun
2:32
0:09
0:25
0:13
0:44
0:05
4:08
12-Jun
0:28
0:33
0:09
0:13
0:45
0:08
2:16
13-Jun
2:31
0:15
0:57
1:57
0:14
0:45
6:39
Totals
Productivity Time
Percentage
7:27:00
1:31:00
3:34:00
2:55:00
3:15:00
1:20:00
20:02:00
16.56%
3.37%
7.93%
6.48%
7.22%
2.96%
44.52%
Date
T ABLE VIII
E2’s Weekly work interruptions for the first week
Week 1
E2
Interruption
I_
Breakfast
I_
Browsing
Date
9-Jun
0:12
0:14
10-Jun
11-Jun
0:17
0:21
0:10
0:17
12-Jun
13-Jun
0:07
0:18
0:18
Totals
Productivity
Time Percentage
1:15
2.78%
I_
Lunch
Break
I_
Phone
I_
Prayer
I_ Talking
Total Time
0:35
0:15
0:12
0:28
1:56
0:15
0:22
0:36
0:08
0:08
0:43
0:45
0:12
0:14
1:52
2:36
0:21
0:40
0:16
0:26
0:44
0:16
0:10
0:23
2:18
1:41
0:59
0:36
2:13
1:13
2:40
1:27
10:23:00
2.19%
1.33%
4.93%
2.70%
5.93%
3.22%
23.07%
I_ Prayer
I_ Talking
Total Time
I_ Other
Interruptions
T ABLE IX
E3’s Weekly work interruptions for the first week
Week 1
E3
Interruption
I_
Breakfast
I_
Browsing
Date
9-Jun
0:04
2:02
0:11
0:47
0:05
3:09
10-Jun
11-Jun
0:12
0:04
0:41
1:05
0:49
0:33
0:31
0:16
0:04
0:43
0:44
0:03
0:09
2:28
3:26
12-Jun
13-Jun
0:16
0:19
0:16
1:10
0:12
0:36
0:41
0:07
0:29
0:42
0:18
0:21
0:17
Totals
Productivity Time
Percentage
0:55:00
5:14:00
1:01:00
2:32:00
0:56:00
3:14:00
0:55:00
2:18
3:26
14:47:00
2.04%
11.63%
2.26%
5.63%
2.07%
7.19%
2.04%
32.85%
I_ Other
Interruptions
I_
Lunch
Break
I_
Phone
96010-1212 IJBAS-IJENS © December 2009 IJENS
IJENS
International Journal of Basic & Applied Sciences IJBAS-IJENS Vol:09 No:10
41
T ABLE X
E4’s Weekly work interruptions for t he first week
Week 1
E4
Interruption
I_
Breakfast
I_
Browsing
9-Jun
0:10
0:40
10-Jun
0:19
0:37
11-Jun
0:16
2:03
12-Jun
0:12
0:40
13-Jun
0:14
0:07
0:12
0:22
Totals
Productivity Time
Percentage
1:11:00
4:07:00
1:11:00
2:16:00
2.63%
9.15%
2.63%
5.04%
I_ Other
Interruptions
I_ Lunch
Break
I_
Phone
I_
Prayer
I_
Talking
Total
Time
0:28
0:32
0:46
0:35
3:11
Date
0:16
0:59
0:42
0:22
2:16
0:31
0:09
0:44
0:33
5:15
0:39
0:33
0:45
0:16
3:05
0:18
0:08
1:21
1:14:00
3:15:00
1:54:00
15:08:00
2.74%
7.22%
4.22%
33.63%
T ABLE XI
E5’s Weekly work interruptions for the first week
Week 1
E5
Interruption
I_ Breakfast
I_ Browsing
I_ Lunch Break
I_ Phone
I_
Prayer
I_
Talking
Total
Time
9-Jun
0:14
2:40
0:22
0:19
0:33
1:44
5:52
10-Jun
0:22
2:37
0:19
0:06
0:43
0:44
4:51
11-Jun
0:16
2:52
0:29
0:12
0:41
0:32
5:02
12-Jun
0:17
3:02
0:28
0:09
0:36
0:17
4:49
13-Jun
0:15
3:14
0:17
0:10
0:28
0:17
4:41
Totals
Productivity Time
Percentage
1:24:00
14:25:00
1:55:00
0:56:00
3:01:00
3:34:00
25:15:00
3.11%
32.04%
4.26%
2.07%
6.70%
7.93%
56.11%
Date
After categorizing the main working activities and
interruptions, we have analyzed them to know the percentage
of total interruptions time and total productivity time for each
engineer during the first week; we had found results as shown
in Fig. 2
Fig.. 2. Productivity and Interruption T ime percentage during Week1 for E1, 2, 3, 4, 5
Then, we had calculated the average productivity
time percentage and the average interruptions time percentage
during the first week for the five engineers and we had found
the result shown in Fig. 3 which shows that the average
productivity time percentage for the five engineers during the
first week is 61.67% percentage, which represents a very low
96010-1212 IJBAS-IJENS © December 2009 IJENS
IJENS
International Journal of Basic & Applied Sciences IJBAS-IJENS Vol:09 No:10
productivity percentage, in contrary with the average
interruption time percentage which reached a 38.04%, which
represents a very high interruption percentage, these results
42
indeed shows that there is a big need for productivity
improvement.
Fig.. 3. Average Productivity T ime Percentage VS. Average Interruption T ime Percentage in Week1 for E1, E2, E3, E4, and E5
After making the previous analysis, we had shown
the analysis results to every engineer, and everyone agreed
that there is a real need for improving this productiv ity level,
and they decided that this need will be their target in the
second week.
In the second week, every engineer has begun to
focus on how to improve the productivity percentage even if
they had to stay working after the original working times.
They began to do exactly what they had to do in the
first week, they filled-in their time recording log with their
main working activities and their interruptions until the end of
the second week, then we had to gather these time recording
logs and do exactly what we had to do in the first week in
addition to comparing the second week’s results with the first
weeks results for each engineer, and we have got these results
shown in Fig. 4 for E1, E2, E3, E4, and E5.
Fig.. 4. Productivity and Interruption T ime percentage during Week2 for E1, 2, 3, 4, 5
After calculating the average productivity time
percentage and the average interruptions time percentage
during the second week for the five engineers and comparing
it to the result of the first week, we had found the result shown
in Fig. 5
96010-1212 IJBAS-IJENS © December 2009 IJENS
IJENS
International Journal of Basic & Applied Sciences IJBAS-IJENS Vol:09 No:10
43
Fig.. 5. Average Productivity T ime Percentage VS. Average Interruption T ime Percentage in Week1 and 2 for E1, E2, E3, E4, and E5
This analysis shows that the average productivity
time percentage for the five engineers during the second week
is 75.67% percentage, which represents a higher percentage
than this of the first week by a factor of 14%, on the other
side, the average interruption time percentage was nearly close
to this of the first week, it was 36.39% and only decreased by
a factor of 1.65% which still represents a very high
interruption percentage.
This analysis also shows that if we added the average
productivity time to the average interruptions time of the
second week, we will find that the percentage will exceed
100% with a factor of 12.05%, in the same time the average
interruptions time was approximately the same as the first
week, hence, this means that engineers had stayed at work an
extra time that the original working time in order to avoid the
low percentage of the average productivity resulted from the
previous analysis of the first week and couldn’t get over their
interruptions time.
Increasing working hours while leaving interruption times
constant, is not the aim of or a solution to a working
organization which aims to achieve its working cycle in a
definite time, so after the analysis of the second week’s
results, we have arranged for a meeting with the attendance of
the five engineers and the management representative to show
them the second week results and to discuss some solutions or
suggestions in order to overcome the interruptions problem or
at least to eliminate it.
During this meeting, every engineer discussed his main
interruptions which cause waste of time and how he can
overcome them, of course every individual has his own
interruptions, but also there are common interruptions that can
be eliminated. Engineers thought, suggested and got
committed to a policy for them and for the organization which
focuses on eliminating interruptions and improving
productivity, and consequently improving product quality.
The policy that the engineers have stated includes the
following:
The period of breakfast will be 15 minute maximum in the
morning.








Lunch breaks will be 30 minutes maximu m per day.
Phone calls will be eliminated to be messages or if it
is very urgent, then it will be eliminated to 20
minutes maximu m per day.
Prayer will be 30 minutes maximum per day for both
prayers during the working day.
Talking out of work scope, will be at breaks, if
urgent then 10 minutes maximu m.
Browsing for entertainment is limited to 10 minutes
maximu m per day.
Concerning the other interruptions like printing a
paper, or sudden meeting with a client … etc, their
time will be recorded as a normal interruption time,
but it will be neglected because as possible as we
can, we will try to resume this amount of time after
the original working time of the day.
Browsing for work will be for an hour all over the
working day.
Following-up juniors will be eliminated to be one
hour distributed into two periods of the day, whether
before or after prayer breaks.
In the third week, engineers have resumed their work
exactly as they have done in the first and the second week, but
focusing on their commitment to their suggested policy. The
work and the commitment lasted all over the third week, and
after the end of this week, we resumed the work that we have
done since the last two weeks.
After gathering the time recording logs, and making our
analysis, we obtained these results that are shown in fig.s 6 for
E1, E2, E3, E4, and E5.
96010-1212 IJBAS-IJENS © December 2009 IJENS
IJENS
International Journal of Basic & Applied Sciences IJBAS-IJENS Vol:09 No:10
44
Fig.. 6. Productivity and Interruption T ime percentage during Week3 for E1, 2, 3, 4, 5
This fig. shows that in the third week E1, E2, E3, and
E4 indeed have committed to their suggested policy which has
led to an improvement in the percentage of every engineer
productivity level and decreased their interruptions level,
except for the last engineer E5, who was under work training,
seemed to be not active in addition to her low technical
performance which led her department manager not to depend
on her work too much.
After calculating the average productivity time percentage and
the average interruptions time percentage during the third
week for the five engineers and comparing it to the result of
the first week and second week, we had found the result that is
shown in Fig. 7
Fig.. 7. Average Productivity T ime Percentage VS. Average Interruption T ime Percentage in Week1, Week2, and Week3 for E1, E2, E3, E4, and E5
This analysis shows that the average productivity time
percentage for the five engineers during the third week is
69.24% percentage, which represents a higher percentage than
this of the first week by a factor of 6.43% and lower than the
this of the second week by a factor of 7.57% but this
percentage will be neglected since it was due to staying
working at work over the original working hours during the
second week, but the result of the third week is acceptable
since it was reached within the range of the original working
hours of the day, on the other side, the average interruption
time percentage was 30.72%, which was lower than this of the
96010-1212 IJBAS-IJENS © December 2009 IJENS
IJENS
International Journal of Basic & Applied Sciences IJBAS-IJENS Vol:09 No:10
first week by a factor of 7.32% and this of the second week by
a factor of 5.67% .
45
we have found the results shown in fig.s 8 for E1, E2, E3, E4,
and E5.
Applying this approach lasted for the fourth week as it lasted
for the previous three weeks, and after the analysis of its data,
Fig.. 8. Productivity and Interruption T ime percentage during Week4 for E1, 2, 3, 4, 5
The result of this analysis is very obvious to show that if the
individual himself suggested or planned for his needs time and
behaved as if he is his manager, he will obtain the best results,
and this will become a normal habit if he got used to do this.
From the fourth week’s fig.s, we can notice that the
after getting committed to a personal suggested policy,
productivity percentage has been improved for E1, E2, E3,
and E4, and interruption percentage has been decreased. But,
E5 proved that she is indeed a burden on the organization, and
after showing these results to the management department
which have shown an obvious improvement for individuals
performance and consequently the work productivity, and on
the other side E5 is not active, they asked for a technical
evaluation for this engineer from her head manager, and
indeed the evaluation has shown that she is technically weak
and consequently, her head manager can’t depend on her
work, so the management department with her head manager
have decided to report her with the end of her relatio nship
with the organization after finishing her probation period.
After calculating the average productivity time
percentage and the average interruptions time percentage
during the fourth week for the five engineers and comparing it
to the result of the first week, second week, and the third
week, we had found the result that is shown in Fig. 9
Fig.. 9. Average Productivity Time Percentage VS. Average Interruption Time Percentage in Week1, Week2, Week3, and Week4 for E1, E2, E 3, E4, and E5
This analysis shows that the average productivity time
percentage for the five engineers during the fourth week is
75.14% percentage, which represents a higher percentage than
this of the first week by a factor of 13.47% and lower than this
of the second week by a factor of 0.53% which can be
neglected and higher than this of the third week by a factor of
5.90% , on the other side, the average interruption time
percentage was 24.95%, which was lower than this of the first
week by a factor of 13.09%% and this of the second week by
a factor of 11.44% and this of the third week by a factor of
5.77%.
3) Handling interruptions conclusion:
Hence, we can say that form the beginning of the
assigned period to the end of this period, the average
96010-1212 IJBAS-IJENS © December 2009 IJENS
IJENS
International Journal of Basic & Applied Sciences IJBAS-IJENS Vol:09 No:10
productivity time has been increased and improved by a factor
of 13.47% percentage and the average interruptions time has
been decreased by a factor of 13.09% which represents a very
acceptable improvement percentage for productivity.
Hence, we can be assured that the first PSP principle has been
achieved successfully and with a very acceptable result.
B. PSP Second Principle
Here, we will focus on implementing the second PSP
principle, which concerns increasing individuals’ productivity,
and product and process quality using PSP planning and
measurement forms. Development and data collection
processes are also included to provide additional context for
understanding the results.
Engineers learn to use the PSP by developing different
tasks and they may use any design method or programming
language in which they are fluent.
Engineers have practiced different programming tasks, on
which they had applied what they had learned during the PSP
training sessions, to pilot test the PSP on two main similar
tasks each for two projects professionally.
During the implementation of the second principle, we
have decided to show this principle through working on two
medium sized projects of a medium size software organization
following the PSP process structure shown in Fig. 1.
We have also dedicated three engineers of those who had
been trained on how to practice PSP to work on these projects;
they were E2 (developer), E3 (developer), and E4 (designer),
and we have called our projects as PA, and PB for the first and
second project respectively.
Development time, defects, and task size are measured
and recorded on provided forms. A simple plan summary form
like shown in Fig. 10 is used to document planned and actual
results.
While writing the projects lines of code or designing
their pages, engineers have gathered process data that are
summarized in the project plan summary. With such a short
feedback loop, engineers can quickly see the effect of PSP on
their own performance.
1) PSP Measurement Framework :
46
Engineers collect three basic measures: size, time, and
defects. Size is measured in lines of code (LOC). In practice,
engineers use a size measure appropriate to the programming
language and environment they are using; for example,
number of database objects, number of use cases, number of
classes, etc. In order to ensure that size is measured
consistently, counting and coding standards are defined and
used by each engineer. Derived measures that involve size,
such as productivity or defect density, use new and changed
LOC, and new and changed Pages. ―New and changed LOC‖
is defined as lines of code that are added or modified, where
new and changed pages are those pages that are added or
modified; existing LOC is not included in the measure. Time
is measured as the direct time spent on each task. It does not
include interrupt time. A defect is anything that detracts from
the program’s ability to completely and effectively meet the
users’ needs. A defect is an objective measure that engineers
can identify, describe, and count.
Engineers use many other measures that are derived
from these three basic measures. Both planned and actual data
for all measures are gathered and recorded. Actual data are
used to track and predict schedule and quality status. All data
are archived to provide a personal historical repository for
improving estimation accuracy and product quality.
Derived measures include:








Size Estimation Accuracy
Effort Estimation Accuracy
Productivity
Defect density
Process yield
Failure cost of quality (COQ)
Appraisal COQ
Appraisal/failure COQ ratio
2) PSP Plan summary
Task summary data are recorded on the Task Plan
Summary form. This form provides a convenient summary of
planned and actual values for program size, development time,
and defects, and a summary of these same data for all similar
tasks completed to date. The Task plan summary is the source
for all data used in this study. Table XII shows the four
sections of the task plan summary that were used for E2, they
were: Program Size, Time in Phase, Defects Injected, and
Defects Removed.
96010-1212 IJBAS-IJENS © December 2009 IJENS
IJENS
International Journal of Basic & Applied Sciences IJBAS-IJENS Vol:09 No:10
47
T ABLE XII
E2 T ask Plan Summary – Project PA
PS P Task Plan S ummary - Project PA
Engineer
E2
Date
14-Jun
Task
Control Panel development
Task#
1
Language
C#
Summary
Plan
Actual
To Date
M inutes/LOC
5
4
4
LOC/Hour
12
15
15
Defects/KLOC
24
19.30
19.30
Yield
41.67
54.55
54.55
A/FR
0.17
0.34
0.34
Code Size (LOC)
Plan
Actual
To Date
Total New & Changed
500
570
570
M aximum Size
800
M inimum Size
450
Time in Phase (min.)
Plan
Actual
To Date
To Date%
Planning
312
274
274
12.02
Analysis
332
183
183
8.03
Design
258
312
312
13.68
Code
1053
1218
1218
53.42
Code/Design Review
75
70
70
3.07
Compile
64
12
12
0.53
Test
384
192
192
8.42
Postmortem
22
19
19
0.83
Total Task Time
2500
2280
2280
100.00
M aximum Time
4000
M inimum Time
2250
Defects Injected
Plan
Actual
To Date
To Date%
To Date% Def./Hour
Design
1
1
1
9.09
0.86
Code
11
10
10
90.91
0.49
Total
12
11
11
100.00
Defects Removed
Plan
Actual
To Date
To Date%
Planning
Analysis
Code/Design Review
Compile
Test
96010-1212 IJBAS-IJENS © December 2009 IJENS
Def./Hour
IJENS
International Journal of Basic & Applied Sciences IJBAS-IJENS Vol:09 No:10
48
Planning
Analysis
Design
Code
Code/Design Review
5
6
3
27.27
2.57
Compile
2
3
2
18.18
10.00
Test
5
2
6
54.55
1.88
Total
12
11
11
100.00
As shown in Table XII, the summary section holds
the rate data used to make the plan. It also provides a place to
record the actual rate data after task completion. The top entry
in the summary section is Minutes/LOC (minutes per line of
code). As shown in Table XII, E2 used his guessing as his
historical data from the prior similar tasks to get the rate of 5
Minutes/LOC; he might need to use a different value if the
new task seems particularly difficult and likely to take longer
than average.
The next entry in the summary section is LOC/Hour
(lines of code per hour). The LOC/Hour is calculated from
Minutes/LOC by dividing 60 by Minutes/LOC. The
LOC/Hour rate is commonly used by engineers to analyze
development productivity.
The program or code size (LOC) section of the project plan
summary form contains the estimated and actual data on the
task size and likely size ranges. E2 estimated the finished size
of the task he planned to develop and entered it under plan in
the Total New & Changed row as shown in Table 12.
Then he calculated the maximum and minimum size numbers,
they are useful for judging the likely time range for a
development estimate.
The next section of the plan summary table is called Time in
Phase because it is used for data on the phases of the software
development process. E2 calculated total planned
development time by multiplying the planned Minutes/LOC
by the planned New & Changed LOC. Also, he multiplied the
minimum and maximum sizes by the Minutes/LOC to give
the minimum and maximu m times respectively.
The time in phase section has a row for each phase of the
process. This row holds the planned and actual times for each
process phase. The way to do this, E2 has allocated the total
development time to the phases in proportion to the way he
has spent time on previous such tasks. He calculated these
times using ―Minutes‖ for easy calculations.
Then, he estimated from his prior knowledge the
spent time for each phase including the postmortem phase, in
which, E2 completes the plan summary form with actual time,
and size data from his Job Recording Log.
To calculate the To Date value: for each phase, E2
should enter the sum of actual time and To Date time from
the most recent previous tasks, and since there is no previous
To Date time for such previous tasks, the TO Date value will
be the same actual times.
To calculate the To Date% value: for each phase, E2
should enter 100 times the To Date time for that phase
divided by the total To Date time.
For subsequent projects, however, engineers can use the data
from previous tasks, like this task for example, to estimate the
time for each phase of the new task or project. This is the
reason for the To Date% values in the task or project plan
summary form.
The To Date and To Date% columns in the plan summary
form provide a simple way to calculate the percent
distribution of development time by process phase. The To
Date column contains the total of all the time spent in each
phase for all the completed tasks. The To Date% column
holds the percentage distribution of the times in the To Date
column.
3) Individual and Process Productivity:
Here, we have provided the skills and practices that the
engineer needs to improve his prediction, estimation
accuracy, and productivity.
 Size Estimation Accuracy
Accurate size estimates are a fundamental building block for
realistic project plans. Training in PSP provides individual
engineers with an ability to improve their skill in estimating
the size of the products they produce. This ability is clearly
demonstrated in the results presented here.
Measure of Interest
Estimated Size - Actual Size / ArgMax (Estimated Size,
Actual Size)
 Effort Estimation Accuracy
Use of historical data for deriving effort estimates is
common practice in the software industry today. However,
estimation at the level of an individual engineer’s workload
remains a challenge. The PSP training provides engineers
with the ability to make estimates, and to improve the
estimating process, at the level of an individual engineer. This
ability is clearly demonstrated in the results presented here.
Measure of Interest
Estimated Minutes - Actual Minutes / ArgMax (Estimated
Minutes, Actual Minutes)
96010-1212 IJBAS-IJENS © December 2009 IJENS
IJENS
International Journal of Basic & Applied Sciences IJBAS-IJENS Vol:09 No:10
 Productivity
That is, the number of lines of code designed, written,
and tested, per hour spent increases between the first and last
assignments.
Measure of Interest
Total New Changed LOCS / (Total Time Spent / 60)
4) Product and Process Productivity results and
analysis
49
T ABLE XIV
Effort Estimation Accuracy
Task1
Task2
E2
0.09
0.05
E3
0.18
0.02
E4
-0.11
0.01
 Size Estimation
The hypothesis tested in this section of the study is as
follows:
―As engineers progress through the PSP training, their size
estimates gradually grow closer to the actual size of the
program at the end‖ [19].
With the introduction of historical size estimation
data that every engineer has used before, and accumulating
these values To Date, engineers can progress through the PSP
training and can predict closer values to their actual size
estimation values like shown in Table XIII & Fig. 10.
Estimation Accuracy
T ABLE XIII
Size estimation accuracy
Task1
Task2
E2
E3
0.14
0.02
0.02
0.01
E4
0.18
0.02
Fig.. 11. Effort Estimation Accuracy for E2, E3, and E4 during first PSP
T ask and the second one
As shown, after analyzing development time data for the
first and second PSP assignments for the 3 engineers, their
effort estimates grow closer to the actual effort expanded for
the entire life cycle of the task.
 Productivity
The hypothesis to be tested in this section is:
Fig.. 10. Size Estimation Accuracy for E2, E3, and E4 during first PSP Task
and the second one
―As engineers progress through the PSP training, their
productivity increases‖ [19]
As shown, after analyzing size data for the first and second
PSP assignments for the 3 engineers, their size estimates
grow closer to the actual size of the task
Productivity means how much work could be done
in a definite time, by reducing the interruptions time as
preceded, engineers can focus their time on their working
tasks, and here we will find the result as ―how many lines of
code were written per hour‖ shown in Table XV & Fig. 12
 Effort Estimation
In this section, data are used to test the following
hypothesis:
―As engineers progress through the PSP training, their effort
estimates grow closer to the actual effort expended for the
entire life cycle‖ [19]
T ABLE XV
Productivity
Task1
Task2
E2
15.00
16.22
E3
12.00
12.12
E4
0.50
0.57
With the introduction of historical total development
time estimation data that every engineer has used before, and
accumulating these values To Date, engineers can progress
through the PSP training and can predict closer values to their
actual effort estimation values like shown in Table 14 & Fig.
11.
96010-1212 IJBAS-IJENS © December 2009 IJENS
IJENS
International Journal of Basic & Applied Sciences IJBAS-IJENS Vol:09 No:10
50
5) Product and Process Quality:
Here, we have provided the skills and practices that the
engineer needs to understand the defects he injects. These
skills have equipped him to efficiently find and fix most of
his defects and it also provided the data to help prevent these
defects in the future.
The plan summary included a section concerning the number
of defects that were injected during each phase and another
section defining the number of defects that were removed
during which phase.
Fig.. 12. Productivity for E2, E3, and E4 during first PSP T ask and the
second one
As shown, after analyzing productivity data for the first and
second PSP assignments for the 3 engineers, their
productivity increases.
But before filling-in the plan summary sections concerning
the defects, engineers had first to analyze defects. In
analyzing defects, it is helpful to divide them into categories
[17]. Defects are classified into 10 general types. By
categorizing defects into a few types, engineer can quickly
see which categories cause the most trouble and focus on
their prevention and removal. That, of course, is the key to
defect management. Focus on the few defect types that are
most troublesome. Once these types are under control,
identify the next set and work on them, and so on indefinitely.
The defect types used in this paper are shown in Table XVI
[17]
T ABLE XVI
Defect T ype Standard
Defect Type S tandard
Type Number
Type Name
Description
10
Documentation
comments, messages
20
Syntax
spelling, punctuation, typos, instruction formats
30
Build, package
change management, library, version control
40
Assignment
declaration, duplicate names, scope, limits
50
Interface
procedure calls and references, I/O, user formats
60
Checking
error messages, inadequate checks
70
Data
structure, content
80
Function
logic, pointers, loops, recursion, computation, function defects
90
System
config.uration, timing, memory
100
Environment
design, compile, test, other support system problems
The first step in managing defects is to understand them. To
do that, every engineer must gather defect data. Then he can
understand these mistakes and fig. out how to avoid them.

To gather data on defects in the program or the task,
every engineer should do the following:


Keep a record of every defect he finds in his program
or task.

Records enough information on each defect so, he
can later understand it.
Analyzes these data to see what defect types caused
the most problems.
Devises a way to find and correct these defects.
The defect recording log is designed to help gather defect data
[18]. The log for E2 is shown in Table XVII
T ABLE XVII
E2’s Defect Recording Log
96010-1212 IJBAS-IJENS © December 2009 IJENS
IJENS
International Journal of Basic & Applied Sciences IJBAS-IJENS Vol:09 No:10
51
Defect Recording Log [E2]
Project
Date
18-Jun
Num
Type
Injected
Removed
Fix Time
1
20
code
Code
Review
0:01
missing ;
2
50
code
Code
Review
0:03
incorrectly formatted call
3
80
design
Code
Review
0:01
forgot to initialize variable
4
20
code
Code
Review
0:01
misspelled variable
5
80
code
Code
Review
0:04
Adding an email for a female user in
the newsletters list is inserted and
saved as ―M ale‖
6
80
code
Code
Review
0:09
Admin can't obtain a search result of
registered visitors with e-mail data
form
7
20
code
Compile
0:01
; entered as :
8
60
code
Compile
0:06
Admin can’t change his old
password, always ―Error‖ message
appears
9
80
code
Compile
0:16
Editing
shops
sometimes
10
80
code
Unit Test
0:18
Editing events data, then saving the
edited data doesn’t work properly
PA
20-Jun
23-Jun
When E2 started to develop his task, he prepared this
log, and when he first encountered a defect, he entered its
number in the log, the date when it was found, its type
according to the defect type standard, the phase in which it
was injected and the phase in which it was removed, its fixing
time and a brief description of the defect to later reminds him
about the error that caused the defect.
During the postmortem phase, E2 reviewed the
defect log and counted the number of defects injected in each
phase. From the Defect Recording Log in Table 17, E2 first
counted defect 3 as injected in design so he entered 1 under
actual in the design row of his plan summary shown in Table.
The other nine defects were all injected in code, so he entered
a 9 in the code row. The total is then ten injected defects.
Next, he counted the number of defects removed in each
phase. E2 counted three defects removed in Code Review,
Two in compile, 5 in Test so he entered a 3, 2, and 5 in these
rows of the defects removed section. Again, the total is 10.
After recording the number of defects injected and
removed, E2 completed the To Date and To Date% columns
in the same way he filled the same columns with time data.
6) Quality Measures:

Description
Defect Density:
Defect density refers to the defects per new and changed
KLOC found in a program [19]. Thus, if a 150 LOC program
had 18 defects, the defect dens ity would be 1000*18/150 =
120 defects/KLOC. Defect density is measured for the entire
development process and for specific process phases. Since
testing only removes a fraction of the defects in a product,
doesn’t
work
when there are more defects that enter a test phase, there will
be more remaining after the test phase is completed.
Therefore, the number of defects found in a test phase is a
good indication of the number that remains in the product
after that test phase is completed.
Measure of Interest
Total Defects / Total New & Changed LOC /1000
 Yield:
Process yield refers to the percentage of the defects
removed before the first compile and unit test[Y]. Since the
PSP objective is to produce high quality programs, the
suggested guideline for process yield is 70% better [19].
Measure of Interest
Pre-compile defects removed / Pre-compile defects injected
 A/FR:
The appraisal to failure ratio (A/FR) measures the quality
of the engineering process, using cost-of-quality (COQ)
parameters [19].
The A stands for the appraisal quality cost, or the percentage
of development time spent in quality appraisal activities. In
PSP, the appraisal cost is the time spent in design and code
reviews, including the time spent repairing the defects found
in those reviews.
Measure of Interest
Appraisal COQ = 100*(Code Review or Design Review)
Time / Total Development Time
The F in A/FR stands for the failure quality cost,
which is the time spent in failure recovery and repair. The
96010-1212 IJBAS-IJENS © December 2009 IJENS
IJENS
International Journal of Basic & Applied Sciences IJBAS-IJENS Vol:09 No:10
failure cost is the time spent in compile and unit test,
including the time spent finding, fixing, recompiling, and
retesting the defects found in compiling and testing.
As shown, after analyzing defects data for the first and second
PSP assignments for the 3 engineers, there is a significant
increase in the defect density values.

Measure of Interest
52
Process Yield
Failure COQ = 100* (Compile Time + Test Time) / Total
Development Time
The hypothesis to be addressed in this section is as
follows:
The A/FR measure provides a useful way to assess
quality, both for individual programs and to compare the
quality of the development processes used for several
programs. It also indicates the degree to which the engineer
attempted to find and fix defects early in the development
process [19].
As engineers progress through the PSP training, their yield
increases significantly. More specifically, the introduction of
design review and code review following PSP has a
significant impact on the value of engineers’ process yield like
shown in Table XIX & Fig.14.
Measure of Interest
A/F Ratio = Appraisal COQ (A) / Failure COQ (F)
7) Quality results and analysis:
 Defect Density
T ABLE XIX
Pre-compile Defect Yield
Task1
Task2
E2
54.55
71.43
E3
55.56
62.50
E4
33.33
60.00
The hypotheses to be investigated in this section are as
follows:
As engineers progress through PSP training, the number of
defects injected and therefore removed per thousand lines of
code (KLOC) decreases [19]
With the introduction of design and code reviews in
PSP, the defect densities of programs entering the compile and
test phases decrease significantly like shown in Table XVIII&
Fig. 13.
T ABLE XVIII
Defect Density
Task1
Task2
E2
19.30
12.01
E3
20.32
18.22
E4
3.46
1.72
Fig.. 14. Pre-compile Defect Yield for E2, E2, and E4 during first PSP T ask
and the second one
As shown, after analyzing defects removed and injected
before the first compile for the first and second PSP
assignments for the 3 engineers, there is a significant increase
in the process Yield values.
 A/FR
The hypothesis to be addressed in this section is as
follows:
―As engineers progress through the PSP training, their A/FR
value increases significantly. More specifically, the A/FR
values below 1 generally indicate that many defects will be
found in test, while values above 1 generally indicate that few
if any defects will be found in test, like shown in Table XX&
Fig. 15.
T ABLE XX
A/FR
Fig.. 13. Defect Density for E2, E3, and E4 during first PSP T ask and the
second one
Task1
Task2
E2
0.34
0.68
E3
0.40
0.57
E4
2.65
2.14
96010-1212 IJBAS-IJENS © December 2009 IJENS
IJENS
International Journal of Basic & Applied Sciences IJBAS-IJENS Vol:09 No:10
53
its value at the end of PSP training (Average for the two PSP
assignments for the three engineers) like shown in Table XXI
& Fig. 16
T ABLE XXI
Summarized results
Measure
At the start of
training
At the end of
training
S ize Estimation
Accuracy
0.11
0.02
Effort Estimation
Accuracy
0.05
0.03
Productivity
9.17
9.64
Defect Density
14.36
10.65
Process Yield
47.81
64.64
Process Quality cost
ratio A/FR
1.13
1.13
Fig.. 15. A/FR for E2, E2, and E4 during first PSP Task and the second one.
As shown, after analyzing the appraisal and failure cost of
quality for the first and second PSP assignments for the 3
engineers, there is a significant increase in the process A/FR
values.
8) PSP approach summary:
The results from PSP training were impressive. These
results are summarized in Table 21 and are shown in Fig. 16.
The first column describes the measure, the second column
shows its value at the start of PSP training (First 3
assignments for E2, E3, and E4), and the third column shows
Fig.. 16. PSP Summary Measures for the three engineers for two similar tasks
Hence, we can say that form the beginning of the
assigned period to the end of this period, the second PSP has
been achieved with a very acceptable improvement percentage
for both productivity and quality.
VI.
CONCLUSION
The objectives of this study were to examine the effect of
the Personal Software Process on the performance of software
engineers, and to consider whether the observed results could
be generalized beyond the study participants.
Because the PSP was developed to improve individual
performance through the gradual introduction of new
practices, the study took a similar approach, examining the
change in individual performance as these practices were
introduced.
Our analyses grouped individual data and then examined
the change in individual performance. Using this approach we
found that the improvements in four dimensions: size
estimation accuracy, effort estimation accuracy, product
quality, and process quality, were statistically significant.
No statistically significant change in productivity was
found, and so we can state that the improvements observed in
the other performance dimensions were achieved without any
loss of productivity.
96010-1212 IJBAS-IJENS © December 2009 IJENS
IJENS
International Journal of Basic & Applied Sciences IJBAS-IJENS Vol:09 No:10
In conclusion, the analyses stated here substantiate that
trend in personal performance observed during PSP training
are significant, and that the observed improvements represent
real change in individual performance, not a change in the
average performance of the group.
Furthermore, we are confident that the observed
improvements are due to the PSP and can be generalized.
VII.
PSP ST AT US AND FUT URE TRENDS
While superior technical work will continue to be
required, the performance of each individual engineer will be
recognized as important. Quality systems require quality parts,
and unless every engineer strives to produce quality work, the
team cannot do so. Quality management will be an integral
part of software engineering training. Engineers will have to
learn how to measure the quality of their work and how to use
these measures to produce essentially defect free work.
The PSP is designed to provide the disciplined practices
software professionals will need in the future.
While some industrial organizations are introducing these
methods, we recommend a broader introduction of these
disciplined methods to be started here in Egypt universities.
Academic introduction of the PSP is currently supported with
courses at both introductory and advanced levels.
[10]
[11]
[12]
[13]
[14]
[15]
[16]
[17]
[18]
54
Deming, W. E. Out of the Crisis. MIT Center for Advanced
Engineering Study, Cambridge, MA, 1982.
Juran, J. and Gryna, F. Juran's Quality Control Handbook, Fourth
Edition. New York: McGraw- Hill Book Company, 1988.
Fagan, M. ―Design and Code Inspections to Reduce Errors in
Program Development.‖ IBM Systems Journal, 15, 3 (1976)
Fagan, M. ―Advances in Software Inspections.‖ IEEE Transactions
on Software Engineering, SE-12, 7, (July 1986)
Humphrey, W. Managing the Software Process. Reading, MA:
Addison-Wesley, 1989.
Paulk, M., et al. T he Capability Maturity Model: Guidelines for
Improving the Software Process. Reading, MA: Addison Wesley,
1995.
Herbsleb, J., Zubrow, D., Goldenson, D., Hayes, W., and Paulk,
M. ―Software Quality and the Capability Maturity Model,‖
Communications of the ACM, 40, 6 (June 1997): 30 - 40.
Humphrey, W. a Self-Improvement Process for Software
Engineers Reading, MA: Addison- Wesle, (March 2005).
[16] PSP Training for Everyone Wall, Dan, Proceedings of the
T SP Symposium, September 17, 2007,
http://www.sei.cmu.edu/tsp/proceedings07.html
Seshagiri, G. ―Making Quality Happen: The Managers’ Role, AIS
Case Study,‖ Crosstalk (June 2000).
Humphrey, Watts S. Self-Improvement Process for Software
Engineers, Reading, MA: Addison Wesley, © March 2005, ISBN:
0321305493
Several universities in the U.S., Europe, and Australia now
offer the PSP, and several institutions in Asia are considering
its introduction.
While the PSP is relatively new, the early results are
promising. Both industrial use and academic adoption are
increasing. Assuming that these trends continue, we
recommend that the future should see a closer integration of
the (Personal Software Process) PSP, (Team Software
Process) TSP, and (Capability Maturity Model) CMM
methods and a closer coupling of the PSP academic courses
with the broader computer science and software engineering
curricula.
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
REFERENCES
Ferguson, P.; Leman, G; Perini, P; Renner, S.; & Seshagiri, G.
Software Process Improvement Works! (CMU/SEI-99-T R-027,
ADA371804). Pittsburgh, PA: Software Engineering Institute,
Carnegie
Mellon
University,
1999.
<http://www.sei.cmu.edu/publications/documents/99.reports/99tr0
27/99tr027abstract.html>.
McAndrews, D. T he T eam Software Process SM: An Overview
and Preliminary Results of Using Disciplined Practices
(CMU/SEI- 2000-TR-015, ADA387260) Pittsburgh, PA: Software
Engineering Institute, Carnegie Mellon University, 2000.
<http://www.sei.cmu.edu/publications/documents/00.reports/00tr0
15.html>.
Software Engineering Institute. Capability Maturity Model for
Software (CMM), Version1.1, Carnegie Mellon University, 1993.
Software Engineering Institute. Capability Maturity Model
Integration (CMMI), Version 1.1, Carnegie Mellon University,
2002.
SPICE Project. Software Process Assessment Part 2: A model for
process management, Version 1.0, 1998.
P. Kuvaja, J. Simila, L. Krzanik, A. Bicego, G. Koch, S.
Saukkonen. Software Process Assessment and Improvement: T he
BOOT ST RAP Approach. Blackwell Publishers, 1994.
B. Curtis, M. I. Kellner, and J. Over. Process Modeling.
Communications of the ACM, vol. 35, pp. 75-90, 1992.
H. Krasner, J. T irrel, A. Linehan, P. Arnold, and W.H. Ett.
Lessons learned from a software process modeling system.
Communications of ACM, vol. 35, n.9, pp. 91-100, Sept. 1992.
96010-1212 IJBAS-IJENS © December 2009 IJENS
IJENS