See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/281444914

Application and Evaluation of the Personal Software Process

Article · January 2009

CITATIONS READS
3 762

4 authors, including:

Mohamed Abu Elsoud Ibrahim Mahmoud El-henawy

Mansoura University Zagazig University
56 PUBLICATIONS 753 CITATIONS 168 PUBLICATIONS 1,885 CITATIONS

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Grey Wolf Optimizer (GWO): theories, variants, and applications View project

Efficient Healthcare System Using IoT Devices View project

All content following this page was uploaded by Mohamed Abu Elsoud on 03 September 2015.

The user has requested enhancement of the downloaded file.

International Journal of Basic & Applied Sciences IJBAS Vol: 9 No: 10
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—Software 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 Software Process (PSP), 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, PSP will focus on two principles, improving individuals’
productivity, and products and process quality.
Keywords—PSP; 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. INTRODUCTION
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
96010-1212 IJBAS-IJENS @ International Journals of Engineering and Sciences IJENS
55
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. RELATED WORK
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 discussed 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].
International Journal of Basic & Applied Sciences IJBAS Vol: 9 No: 10
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 support 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
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 Model (CMM) for software in 1987 [13, 14]. The
CMM’s 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
96010-1212 IJBAS-IJENS @ International Journals of Engineering and Sciences IJENS
56
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 impressive-
sounding 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
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 similar 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 SOFTWARE PROCESS (PSP)
International Journal of Basic & Applied Sciences IJBAS Vol: 9 No: 10 57
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 zero-defect 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. Figure 1: PSP process flow
Superior products are not produced by mistake; engineers
must strive to do quality work. C. PSP Objectives
(4) It costs less to find and fix defects earlier in a process The PSP aims to provide software engineers with
than later. disciplined methods for improving personal software
(5) It is more efficient to prevent defects than to find and fix development processes. The PSP helps software engineers to:
them. • Improve their estimating and planning skills.
(6) The right way is always the fastest and cheapest way to • Make commitments they can keep.
do a job. • Manage the quality of their projects.
• Reduce the number of defects in their work.
B. PSP Structure The goal of the PSP is to help developers produce quality,
The structure of the PSP process is shown conceptually in zero-defect, products on schedule. Low-defect and zero defect
Figure 1 [16]. Starting with a requirements statement, the first products have become the reality for some developers.
step in the PSP process is planning. There is a planning script
that guides this work and a plan summary for recording the V. CASE STUDY
planning data. While the engineers are following the script to
do the work, they record their time and defect data on the time To make realistic plans, we had to apply the first principle
and defect logs. At the end of the job, during the postmortem of the PSP, which focuses on estimating and evaluating
phase (PM), they summarize the time and defect data from the individuals’ performance then improving it in order to
logs, measure the program or task size, and enter these data in improve the overall productivity level in the organization.
the plan summary form. When done, they deliver the finished The way to improve the productivity and quality of work is to
product along with the completed plan summary form. 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.

96010-1212 IJBAS-IJENS @ International Journals of Engineering and Sciences IJENS

International Journal of Basic & Applied Sciences IJBAS Vol: 9 No: 10
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.
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
Table 1: E2’s Time Recording Log
Time Recording Log
Engineer
E2
Name:
Department: Project Development
Date: 9-May
96010-1212 IJBAS-IJENS @ International Journals of Engineering and Sciences IJENS
58
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.
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 individual
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
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 1 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.
International Journal of Basic & Applied Sciences IJBAS Vol: 9 No: 10 59
Interruption
Date Start Stop Delta Time Activity
Time
9:05 9:17 0:12 I_ Breakfast
9:20 9:29 0:09 W_ Email
9:30 9:58 0:28 I_ Talking
9:59 10:31 0:32 W_ Follow-up juniors
10:32 10:47 0:15 I_ Phone
10:49 13:12 2:23 W_ Programming
9-May 13:09 13:25 0:16 I_ Prayer
13:25 15:26 2:01 W_ Programming
15:28 16:03 0:35 I_ Lunch Break
16:07 16:30 0:23 I_ Prayer
16:32 16:38 0:06 W_ Talking
16:39 16:53 0:14 I_ Browsing
16:54 18:08 1:14 W_ Programming
Totals 2:23 6:25
9:01 9:18 0:17 I_ Breakfast
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 1:04 W_ Programming
10-May
14:57 15:05 0:08 I_ Phone
15:06 16:13 1:07 W_ Programming
16:14 16:37 0:23 W_ Talking
16:14 16:36 0:22 I_ Prayer
16:37 16:49 0:12 I_ Talking
16:50 17:12 0:22 I_ Lunch Break
17:13 17:22 0:09 W_ Browsing
17:23 17:54 0:31 W_ Reading
Totals 1:52 7:06
11-May 9:32 9:53 0:21 I_ Breakfast
9:54 9:58 0:04 W_ Email
9:58 13:10 3:12 W_ Programming
13:11 13:39 0:28 W_ Prayer
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

96010-1212 IJBAS-IJENS @ International Journals of Engineering and Sciences IJENS

International Journal of Basic & Applied Sciences IJBAS Vol: 9 No: 10 60

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 0:22 W_ Talking
Totals 2:36 6:21
9:08 9:15 0:07 I_ Breakfast
9:16 9:18 0:02 W_ Email
9:18 9:28 0:10 I_ Talking
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-May
12:54 13:38 0:44 W_ Browsing
13:39 14:03 0:24 I_ Prayer
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 18:20 0:16 W_ Talking
Totals 2:18 6:41
9:08 9:26 0:18 I_ Breakfast
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-May 13:34 14:00 0:26 I_ Phone
14:01 14:19 0:18 I_ Browsing
14:20 14:38 0:18 W_ Talking
14:39 15:21 0:42 W_ Browsing
15:22 15:57 0:35 W_ Programming
15:59 16:05 0:06 I_ Prayer
16:07 18:22 2:15 W_ Programming
Totals 1:41 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 2 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
2, 3, 4, 5, and 6 respectively.

96010-1212 IJBAS-IJENS @ International Journals of Engineering and Sciences IJENS

International Journal of Basic & Applied Sciences IJBAS Vol: 9 No: 10 61
Table 2: E1’s Weekly Activity Summary for the first week
Week1 E1
W_
W_
W_ W_ Follow-
W_ W_ Managing W_ W_ W_ Total
Activity Assigning Customer up
Browsing Email Projects Reading Phone Talking Time
Task Service Seniors
Tasks
work
Date
9-Jun 0:19 0:35 3:02 0:31 1:03 0:16 0:22 6:08
10-Jun 0:05 0:24 1:57 0:16 1:03 0:43 0:24 4:52
11-Jun 0:20 0:33 0:53 0:26 0:15 1:45 0:14 0:17 0:14 4:57
12-Jun 0:14 0:56 1:28 0:15 2:11 0:59 0:22 0:18 6:43
13-Jun 0:48 0:16 0:17 0:16 0:24 0:21 2:22
Totals 0:58 3:16 7:36 1:45 4:48 1:45 1:13 2:02 1:39 25:02
Productivity
Time 2.15% 7.26% 16.89% 3.89% 10.67% 3.89% 2.70% 4.52% 3.67% 55.63%
Percentage

Table 3: E2’s Weekly Activity Summary for the first week

Week1 E2

W_ W_ W_ Follow-up W_ W_ W_ Total
Activity
Programming Reading Juniors Browsing Email Talking Time

Date
9-Jun 5:38 0:32 0:09 0:06 6:25
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
54.11% 3.00% 8.15% 4.96% 1.89% 3.15% 75.26%
Percentage

Table 4: E3’s Weekly Activity Summary for the first week

Week1 E3
W_ Follow-up
W_ W_ W_ W_ Total
Activity Juniors W_ Browsing
Programming Reading Email Talking Time
Date
9-Jun 4:02 1:11 0:12 0:19 0:10 5:54:00
10-Jun 3:31 0:43 1:29 0:18 0:20 0:09 6:30:00
11-Jun 4:19 0:42 0:08 0:31 5:40:00
12-Jun 3:31 1:12 0:31 1:07 0:06 0:08 6:35:00
13-Jun 3:04 1:04 1:03 0:24 5:35:00
1:17:0
Totals 18:27:00 1:55:00 4:57:00 2:40:00 0:58:00 30:14:00
0
Productivity Time
41.00% 4.26% 11.00% 5.93% 2.85% 2.15% 67.19%
Percentage

96010-1212 IJBAS-IJENS @ International Journals of Engineering and Sciences IJENS

International Journal of Basic & Applied Sciences IJBAS Vol: 9 No: 10 62
Table 5: E4’s Weekly Activity Summary for the first week
Week1 E4
W_ Follow-up
W_ W_ W_ Total
Activity W_ Designing Juniors W_ Email
Reading Browsing Talking Time

Date
9-Jun 4:51 0:11 0:32 0:05 0:10 5:49
10-Jun 1:00 1:02 2:38 1:33 0:08 0:14 6:35
11-Jun 3:03 0:14 0:19 0:03 0:05 3:44
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 7:46
29:46:0
Totals 16:29:00 1:36:00 4:21:00 5:05:00 0:55:00 1:20:00
0
Productivity Time
36.63% 3.56% 9.67% 11.30% 2.04% 2.96% 66.15%
Percentage

Table 6: E5’s Weekly Activity Summary for the first week

Week1 E5

W_ W_ W_
Activity W_ Designing W_ Email Total Time
Reading Browsing Talking

Date
9-Jun 2:44 0:09 0:16 3:09
10-Jun 1:15 1:02 1:33 0:08 0:14 4:12
11-Jun 3:03 0:19 0:08 0:29 3:59
12-Jun 2:32 0:16 0:49 0:09 0:23 4:09
13-Jun 1:48 0:18 1:52 0:07 0:17 4:22
Totals 11:22:00 1:36:00 4:33:00 0:41:00 1:39:00 19:51:00
Productivity Time
25.26% 3.56% 10.11% 1.52% 3.67% 44.11%
Percentage

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.
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 figures for
further comparisons of weekly productivity results and
presentations that will let us; the managers, professors, and the
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 7, 8, 9, 10, and 11
respectively.

Table 7: E1’s Weekly work interruptions for the first week

Week 1 E1

I_ I_ I_ Other I_ I_
Interruption I_ Talking Total Time
Browsing Breakfast Interruptions Phone Prayer

Date
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

96010-1212 IJBAS-IJENS @ International Journals of Engineering and Sciences IJENS

International Journal of Basic & Applied Sciences IJBAS Vol: 9 No: 10 63

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 7:27:00 1:31:00 3:34:00 2:55:00 3:15:00 1:20:00 20:02:00

Productivity Time
16.56% 3.37% 7.93% 6.48% 7.22% 2.96% 44.52%
Percentage

Table 8: E2’s Weekly work interruptions for the first week

Week 1 E2
I_
I_ I_ I_ Other I_ I_
Interruption Lunch I_ Talking Total Time
Breakfast Browsing Interruptions Phone Prayer
Break
Date
9-Jun 0:12 0:14 0:35 0:15 0:12 0:28 1:56
10-Jun 0:17 0:10 0:22 0:08 0:43 0:12 1:52
11-Jun 0:21 0:17 0:15 0:36 0:08 0:45 0:14 2:36
12-Jun 0:07 0:21 0:40 0:16 0:44 0:10 2:18
13-Jun 0:18 0:18 0:26 0:16 0:23 1:41
Totals 1:15 0:59 0:36 2:13 1:13 2:40 1:27 10:23:00
Productivity
2.78% 2.19% 1.33% 4.93% 2.70% 5.93% 3.22% 23.07%
Time Percentage

Table 9: E3’s Weekly work interruptions for the first week

Week 1 E3
I_
I_ I_ I_ Other I_
Interruption Lunch I_ Prayer I_ Talking Total Time
Breakfast Browsing Interruptions Phone
Break
Date
9-Jun 0:04 2:02 0:11 0:47 0:05 3:09
10-Jun 0:12 0:41 0:33 0:16 0:43 0:03 2:28
11-Jun 0:04 1:05 0:49 0:31 0:04 0:44 0:09 3:26
12-Jun 0:16 0:16 0:36 0:07 0:42 0:21 2:18
13-Jun 0:19 1:10 0:12 0:41 0:29 0:18 0:17 3:26
Totals 0:55:00 5:14:00 1:01:00 2:32:00 0:56:00 3:14:00 0:55:00 14:47:00
Productivity Time
2.04% 11.63% 2.26% 5.63% 2.07% 7.19% 2.04% 32.85%
Percentage

Table 10: E4’s Weekly work interruptions for the first week
Week 1 E4

I_ I_ I_ Other I_ Lunch I_ I_ I_ Total

Interruption
Breakfast Browsing Interruptions Break Phone Prayer Talking Time

Date
9-Jun 0:10 0:40 0:28 0:32 0:46 0:35 3:11
10-Jun 0:19 0:37 0:16 0:42 0:22 2:16
11-Jun 0:16 2:03 0:59 0:31 0:09 0:44 0:33 5:15
12-Jun 0:12 0:40 0:39 0:33 0:45 0:16 3:05
13-Jun 0:14 0:07 0:12 0:22 0:18 0:08 1:21
Totals 1:11:00 4:07:00 1:11:00 2:16:00 1:14:00 3:15:00 1:54:00 15:08:00
Productivity Time
2.63% 9.15% 2.63% 5.04% 2.74% 7.22% 4.22% 33.63%
Percentage

96010-1212 IJBAS-IJENS @ International Journals of Engineering and Sciences IJENS

International Journal of Basic & Applied Sciences IJBAS Vol: 9 No: 10 64
Table 11: E5’s Weekly work interruptions for the first week

Week 1 E5
I_ I_ Total
Interruption I_ Breakfast I_ Browsing I_ Lunch Break I_ Phone
Prayer Talking Time

Date
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 1:24:00 14:25:00 1:55:00 0:56:00 3:01:00 3:34:00 25:15:00
Productivity Time
3.11% 32.04% 4.26% 2.07% 6.70% 7.93% 56.11%
Percentage

After categorizing the main working activities and engineer during the first week; we had found results as shown
interruptions, we have analyzed them to know the percentage in Figure 2
of total interruptions time and total productivity time for each

Figure 2: Productivity and Interruption Time percentage during Week1 for E1, 2, 3, 4, 5
Then, we had calculated the average productivity productivity percentage, in contrary with the average
time percentage and the average interruptions time percentage interruption time percentage which reached a 38.04%, which
during the first week for the five engineers and we had found represents a very high interruption percentage, these results
the result shown in Figure 3 which shows that the average indeed shows that there is a big need for productivity
productivity time percentage for the five engineers during the improvement.
first week is 61.67% percentage, which represents a very low

96010-1212 IJBAS-IJENS @ International Journals of Engineering and Sciences IJENS

International Journal of Basic & Applied Sciences IJBAS Vol: 9 No: 10 65

Figure 3: Average Productivity Time Percentage VS. Average Interruption Time 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 productivity 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 Figure 4 for E1, E2, E3, E4, and E5.

Figure 4: Productivity and Interruption Time percentage during Week2 for E1, 2, 3, 4, 5

After calculating the average productivity time it to the result of the first week, we had found the result shown
percentage and the average interruptions time percentage in Figure 5
during the second week for the five engineers and comparing

96010-1212 IJBAS-IJENS @ International Journals of Engineering and Sciences IJENS

International Journal of Basic & Applied Sciences IJBAS Vol: 9 No: 10
Figure 5: Average Productivity Time Percentage VS. Average Interruption Time 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.
96010-1212 IJBAS-IJENS @ International Journals of Engineering and Sciences IJENS
66
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 maximum per day.
• Phone calls will be eliminated to be messages or if it
is very urgent, then it will be eliminated to 20
minutes maximum 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 maximum.
• Browsing for entertainment is limited to 10 minutes
maximum 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 figures 6
for E1, E2, E3, E4, and E5.
International Journal of Basic & Applied Sciences IJBAS Vol: 9 No: 10 67

Figure 6: Productivity and Interruption Time percentage during Week3 for E1, 2, 3, 4, 5

This figure 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 Figure 7

Figure 7: Average Productivity Time Percentage VS. Average Interruption Time Percentage in Week1, Week2, and Week3 for E1, E2, E3, E4, and E5

This analysis shows that the average productivity 69.24% percentage, which represents a higher percentage than
time percentage for the five engineers during the third week is this of the first week by a factor of 6.43% and lower than the

96010-1212 IJBAS-IJENS @ International Journals of Engineering and Sciences IJENS

International Journal of Basic & Applied Sciences IJBAS Vol: 9 No: 10
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
Figure 8: Productivity and Interruption Time 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 figures, 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
Figure 9: Average Productivity Time Percentage VS. Average Interruption Time Percentage in Week1, Week2, Week3, and Week4 for E1, E2, E3, E4, and E5
96010-1212 IJBAS-IJENS @ International Journals of Engineering and Sciences IJENS
68
first week by a factor of 7.32% and this of the second week by
a factor of 5.67% .
Applying this approach lasted for the fourth week as
it lasted for the previous three weeks, and after the analysis of
its data, we have found the results shown in figures 8 for E1,
E2, E3, E4, and E5.
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 relationship
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 Figure 9
International Journal of Basic & Applied Sciences IJBAS Vol: 9 No: 10
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
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 Figure 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 Figure 10 is used to document planned and
actual results.
96010-1212 IJBAS-IJENS @ International Journals of Engineering and Sciences IJENS
69
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:
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 12 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.
International Journal of Basic & Applied Sciences IJBAS Vol: 9 No: 10 70
Table 12: E2 Task Plan Summary – Project PA
PSP Task Plan Summary - Project PA
Engineer E2 Date 14-Jun
Task Control Panel development Task# 1
Language C#

Summary Plan Actual To Date

Minutes/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
Maximum Size 800
Minimum 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
Maximum Time 4000
Minimum Time 2250

Defects Injected Plan Actual To Date To Date% To Date% Def./Hour

Planning
Analysis
Design 1 1 1 9.09 0.86
Code 11 10 10 90.91 0.49
Code/Design Review
Compile
Test
Total 12 11 11 100.00

96010-1212 IJBAS-IJENS @ International Journals of Engineering and Sciences IJENS

International Journal of Basic & Applied Sciences IJBAS Vol: 9 No: 10
Defects Removed Plan Actual To Date
Planning
Analysis
Design
Code
Code/Design Review 5 6 3 27.27
Compile 2 3 2 18.18
Test 5 2 6 54.55
Total 12 11 11
As shown in Table 12, 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 12, 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 maximum 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
96010-1212 IJBAS-IJENS @ International Journals of Engineering and Sciences IJENS
71
To Date% Def./Hour
2.57
10.00
1.88
100.00
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)
 International Journal of Basic & Applied Sciences IJBAS Vol: 9 No: 10 72
• Effort Estimation Accuracy
Use of historical data for deriving effort estimates is As shown, after analyzing size data for the first and second
common practice in the software industry today. However, PSP assignments for the 3 engineers, their size estimates
estimation at the level of an individual engineer’s workload grow closer to the actual size of the task
remains a challenge. The PSP training provides engineers
• Effort Estimation
with the ability to make estimates, and to improve the
estimating process, at the level of an individual engineer. This In this section, data are used to test the following
ability is clearly demonstrated in the results presented here. hypothesis:
Measure of Interest “As engineers progress through the PSP training, their effort
estimates grow closer to the actual effort expended for the
Estimated Minutes - Actual Minutes / ArgMax (Estimated
entire life cycle” [19]
Minutes, Actual Minutes)
With the introduction of historical total development
• Productivity
time estimation data that every engineer has used before, and
That is, the number of lines of code designed, written, accumulating these values To Date, engineers can progress
and tested, per hour spent increases between the first and last through the PSP training and can predict closer values to their
assignments. actual effort estimation values like shown in Table 14 &
Figure 11.
Measure of Interest
Table 14:Effort Estimation Accuracy
Total New Changed LOCS / (Total Time Spent / 60)
Task1 Task2
4) Product and Process Productivity results and
E2 0.09 0.05
analysis
E3 0.18 0.02
• Size Estimation
The hypothesis tested in this section of the study is as E4 -0.11 0.01
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 13 & Figure 10.

Table 13: Size estimation accuracy

Task1 Task2
E2 0.14 0.02
E3 0.02 0.01
E4 0.18 0.02
Figure 11: Effort Estimation Accuracy for E2, E3, and E4 during first PSP
Task and the second one

As shown, after analyzing development time data for the

Estimation Accuracy

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:
“As engineers progress through the PSP training, their
productivity increases” [19]
Figure 10: Size Estimation Accuracy for E2, E3, and E4 during first PSP
Task and the second one

96010-1212 IJBAS-IJENS @ International Journals of Engineering and Sciences IJENS

International Journal of Basic & Applied Sciences IJBAS Vol: 9 No: 10 73
Productivity means how much work could be done As shown, after analyzing productivity data for the first and
in a definite time, by reducing the interruptions time as second PSP assignments for the 3 engineers, their
preceded, engineers can focus their time on their working productivity increases.
tasks, and here we will find the result as “how many lines of
5) Product and Process Quality:
code were written per hour” shown in Table 15 & Figure 12
Here, we have provided the skills and practices that the
Table 15: Productivity engineer needs to understand the defects he injects. These
Task1 Task2 skills have equipped him to efficiently find and fix most of
his defects and it also provided the data to help prevent these
E2 15.00 16.22 defects in the future.
E3 12.00 12.12 The plan summary included a section concerning the
E4 0.50 0.57 number of defects that were injected during each phase and
another section defining the number of defects that were
removed during which phase.
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 Table16 [17]

Figure 12: Productivity for E2, E3, and E4 during first PSP Task and the
second one
Table 16: Defect Type Standard

Defect Type Standard

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 configuration, timing, memory
100 Environment design, compile, test, other support system problems

The first step in managing defects is to understand he can understand these mistakes and figure out how to avoid
them. To do that, every engineer must gather defect data. Then them.

96010-1212 IJBAS-IJENS @ International Journals of Engineering and Sciences IJENS

International Journal of Basic & Applied Sciences IJBAS Vol: 9 No: 10 74
To gather data on defects in the program or the task, • Analyzes these data to see what defect types caused
every engineer should do the following: the most problems.
• Devises a way to find and correct these defects.
• Keep a record of every defect he finds in his program
or task. The defect recording log is designed to help gather defect data
• Records enough information on each defect so, he [18]. The log for E2 is shown in Table 17
can later understand it.

Table 17: E2’s Defect Recording Log

Defect Recording Log [E2]

Project Date Num Type Injected Removed Fix Time Description
Code
18-Jun 1 20 code 0:01 missing ;
Review
Code
2 50 code 0:03 incorrectly formatted call
Review
Code
3 80 design 0:01 forgot to initialize variable
Review

Code
4 20 code 0:01 misspelled variable
Review

Adding an email for a female user in

Code
5 80 code 0:04 the newsletters list is inserted and
Review
saved as “Male”
PA
Admin can't obtain a search result of
Code
6 80 code 0:09 registered visitors with e-mail data
Review
form
20-Jun 7 20 code Compile 0:01 ; entered as :

Admin can’t change his old

8 60 code Compile 0:06 password, always “Error” message
appears

Editing shops doesn’t work

9 80 code Compile 0:16
sometimes
Editing events data, then saving the
23-Jun 10 80 code Unit Test 0:18
edited data doesn’t work properly

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:
• 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 density 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,
when there are more defects that enter a test phase, there will
be more remaining after the test phase is completed.

96010-1212 IJBAS-IJENS @ International Journals of Engineering and Sciences IJENS

International Journal of Basic & Applied Sciences IJBAS Vol: 9 No: 10 75
Therefore, the number of defects found in a test phase is a As engineers progress through PSP training, the number of
good indication of the number that remains in the product defects injected and therefore removed per thousand lines of
after that test phase is completed. code (KLOC) decreases [19]
Measure of Interest With the introduction of design and code reviews in
PSP, the defect densities of programs entering the compile and
Total Defects / Total New & Changed LOC /1000
test phases decrease significantly like shown in Table 18&
• Yield: Figure 13.
Process yield refers to the percentage of the defects Table 18 : Defect Density
removed before the first compile and unit test[Y]. Since the Task1 Task2
PSP objective is to produce high quality programs, the
suggested guideline for process yield is 70% better [19]. E2 19.30 12.01
E3 20.32 18.22
Measure of Interest
E4 3.46 1.72
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
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. Figure 13: Defect Density for E2, E3, and E4 during first PSP Task and the
second one
Measure of Interest
As shown, after analyzing defects data for the first and second
Failure COQ = 100* (Compile Time + Test Time) / Total PSP assignments for the 3 engineers, there is a significant
Development Time increase in the defect density values.
The A/FR measure provides a useful way to assess • Process Yield
quality, both for individual programs and to compare the
quality of the development processes used for several The hypothesis to be addressed in this section is as
programs. It also indicates the degree to which the engineer follows:
attempted to find and fix defects early in the development As engineers progress through the PSP training, their yield
process [19]. 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
Measure of Interest shown in Table 19& Figure14.
A/F Ratio = Appraisal COQ (A) / Failure COQ (F) Table 19: Pre-compile Defect Yield

Task1 Task2
7) Quality results and analysis:
• Defect Density E2 54.55 71.43

The hypotheses to be investigated in this section are as E3 55.56 62.50

follows: E4 33.33 60.00

96010-1212 IJBAS-IJENS @ International Journals of Engineering and Sciences IJENS

International Journal of Basic & Applied Sciences IJBAS Vol: 9 No: 10 76

Figure 14: Pre-compile Defect Yield for E2, E2, and E4 during first PSP Task
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 20&
Figure 15.
Table 20: A/FR
Figure 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 Figure
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
its value at the end of PSP training (Average for the two PSP
assignments for the three engineers) like shown in Table 21 &
Figure 16
Table 21: Summarized results
At the start of At the end of
Measure
training training

Task1 Task2 Size Estimation

0.11 0.02
E2 0.34 0.68 Accuracy

E3 0.40 0.57
Effort Estimation
0.05 0.03
E4 2.65 2.14 Accuracy

Productivity 9.17 9.64

Defect Density 14.36 10.65

Process Yield 47.81 64.64

Process Quality cost

1.13 1.13
ratio A/FR

96010-1212 IJBAS-IJENS @ International Journals of Engineering and Sciences IJENS

International Journal of Basic & Applied Sciences IJBAS Vol: 9 No: 10 77

Figure 16: PSP Summary Measures for the three engineers for two similar tasks

Hence, we can say that form the beginning of the VI. CONCLUSION
assigned period to the end of this period, the second PSP has
The objectives of this study were to examine the effect of
been achieved with a very acceptable improvement percentage
the Personal Software Process on the performance of software
for both productivity and quality.
engineers, and to consider whether the observed results could
be generalized beyond the study participants.

96010-1212 IJBAS-IJENS @ International Journals of Engineering and Sciences IJENS

 International Journal of Basic & Applied Sciences IJBAS Vol: 9 No: 10
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.
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 STATUS AND FUTURE 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.
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.
96010-1212 IJBAS-IJENS @ International Journals of Engineering and Sciences IJENS
View publication stats
78
REFERENCES
[1] Ferguson, P.; Leman, G; Perini, P; Renner, S.; & Seshagiri, G. Software
Process Improvement Works! (CMU/SEI-99-TR-027, ADA371804).
Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University,
1999.
<http://www.sei.cmu.edu/publications/documents/99.reports/99tr027/99tr027
abstract.html>.
[2] McAndrews, D. The Team 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/00tr015.html>.
[3] Software Engineering Institute. Capability Maturity Model for Software
(CMM), Version1.1, Carnegie Mellon University, 1993.
[4] Software Engineering Institute. Capability Maturity Model Integration
(CMMI), Version 1.1, Carnegie Mellon University, 2002.
[5] SPICE Project. Software Process Assessment Part 2: A model for process
management, Version 1.0, 1998.
[6] P. Kuvaja, J. Simila, L. Krzanik, A. Bicego, G. Koch, S. Saukkonen.
Software Process Assessment and Improvement: The BOOTSTRAP
Approach. Blackwell Publishers, 1994.
[7] B. Curtis, M. I. Kellner, and J. Over. Process Modeling. Communications
of the ACM, vol. 35, pp. 75-90, 1992.
[8] H. Krasner, J. Tirrel, 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. Deming, W. E. Out of the Crisis. MIT
Center for Advanced Engineering Study, Cambridge, MA, 1982.
[9] Juran, J. and Gryna, F. Juran's Quality Control Handbook, Fourth Edition.
New York: McGraw- Hill Book Company, 1988.
[10] Fagan, M. “Design and Code Inspections to Reduce Errors in Program
Development.” IBM Systems Journal, 15, 3 (1976)
[11] Fagan, M. “Advances in Software Inspections.” IEEE Transactions on
Software Engineering, SE-12, 7, (July 1986)
[12] Humphrey, W. Managing the Software Process. Reading, MA: Addison-
Wesley, 1989.
[13] Paulk, M., et al. The Capability Maturity Model: Guidelines for
Improving the Software Process. Reading, MA: Addison Wesley, 1995.
[14] 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.
[15] 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 TSP
Symposium, September 17, 2007,
http://www.sei.cmu.edu/tsp/proceedings07.html
[17] Seshagiri, G. “Making Quality Happen: The Managers’ Role, AIS Case
Study,” Crosstalk (June 2000).
[18] Humphrey, Watts S. Self-Improvement Process for Software Engineers,
Reading, MA: Addison Wesley, © March 2005, ISBN: 0321305493