application and evaluation of the personal software process - ijens

International Journal of Basic & Applied Sciences IJBAS-IJENS Vol:09 No:10 33

96010-1212 IJBAS-IJENS © December 2009 IJENS I J E N S

Application and Evaluation of The

Personal Software Process

Hamdy K.Elminir#1

, Eman A.Khereba*1

, Mohamed Abu Elsoud#1

, Ibrahim El-Hennawy#2

1Computer Science department, Mansoura University, 60 El Gomhuria st., Mansoura, Egypt

2Computer Science department, Zagazig University, Zagazig, Egypt

*Corresponding Author: [email protected]

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.

Index Term— 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

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].

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

mailto:[email protected]



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 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 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 SOFTWARE 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 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.

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 summary for recording the



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.

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 STUDY

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.

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

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 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

Name: E2

Department: Project Development

Date: 9-May

Date Start Stop Interruption

Time Delta Time Activity

9-May

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

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

10-May

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

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

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

12-May

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:54 13:38 0:44 W_ Browsing

13:39 14:03 0:24 I_ Prayer

14:05 16:16 2:11 W_ Programming


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

13-May

9:08 9:26 0:18 I_ Breakfast

9:27 9:50 0:23 W_ Email


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: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 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

Week1 E1

Activity W_

Assigning Task

W_ Browsing

W_ Customer

Service

W_ Email

W_

Follow-up

Seniors

work

W_ Managing Projects

Tasks

W_ Reading

W_ Phone

W_ Talking

Total Time

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

Percentage

2.15% 7.26% 16.89% 3.89% 10.67% 3.89% 2.70% 4.52% 3.67% 55.63%

T ABLE III


Week1 E2

Activity W_

Programming

W_

Reading

W_ Follow-up

Juniors

W_

Browsing

W_

Email

W_

Talking

Total

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

Percentage 54.11% 3.00% 8.15% 4.96% 1.89% 3.15% 75.26%



T ABLE IV


Week1 E3

Activity W_

Programming

W_

Reading

W_ Follow-up

Juniors W_ Browsing W_

Email

W_

Talking

Total

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

Totals 18:27:00 1:55:00 4:57:00 2:40:00 1:17:0

0 0:58:00 30:14:00

Productivity Time

Percentage 41.00% 4.26% 11.00% 5.93% 2.85% 2.15% 67.19%

T ABLE V


T ABLE VI


Week1 E5

Activity W_ Designing W_

Reading

W_

Browsing W_ Email

W_

Talking Total Time

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

Percentage 25.26% 3.56% 10.11% 1.52% 3.67% 44.11%

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.

Week1 E4

Activity W_ Designing W_

Reading

W_ Follow-up

Juniors W_

Browsing W_ Email

W_

Talking

Total

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

Totals 16:29:00 1:36:00 4:21:00 5:05:00 0:55:00 1:20:00 29:46:0

0

Productivity Time

Percentage 36.63% 3.56% 9.67% 11.30% 2.04% 2.96% 66.15%



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

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

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

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

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

T ABLE VIII


Week 1 E2

Interruption I_

Breakfast

I_

Browsing

I_ Other

Interruptions

I_

Lunch Break

I_

Phone

I_

Prayer I_ Talking Total Time

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

Time Percentage 2.78% 2.19% 1.33% 4.93% 2.70% 5.93% 3.22% 23.07%

T ABLE IX


Week 1 E3

Interruption I_

Breakfast

I_

Browsing

I_ Other

Interruptions

I_

Lunch

Break

I_

Phone I_ Prayer I_ Talking Total Time

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

Percentage 2.04% 11.63% 2.26% 5.63% 2.07% 7.19% 2.04% 32.85%



T ABLE X

E4’s Weekly work interruptions for t he first week

Week 1 E4

Interruption I_

Breakfast

I_

Browsing

I_ Other

Interruptions

I_ Lunch

Break

I_

Phone

I_

Prayer

I_

Talking

Total

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

Percentage 2.63% 9.15% 2.63% 5.04% 2.74% 7.22% 4.22% 33.63%

T ABLE XI


Week 1 E5

Interruption I_ Breakfast I_ Browsing I_ Lunch Break I_ Phone I_

Prayer

I_

Talking

Total

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

Percentage 3.11% 32.04% 4.26% 2.07% 6.70% 7.93% 56.11%

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



productivity percentage, in contrary with the average

interruption time percentage which reached a 38.04%, which

represents a very high interruption percentage, these results

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 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 Fig. 4 for E1, E2, E3, E4, and E5.


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



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 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 fig.s 6 for

E1, E2, E3, E4, and E5.




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



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 fig.s 8 for E1, E2, E3, E4,

and E5.


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 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 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



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 :

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.



T ABLE XII

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

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



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 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

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)


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)



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

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.

T ABLE XIII Size estimation accuracy

Task1 Task2

E2 0.14 0.02

E3 0.02 0.01

E4 0.18 0.02

Fig.. 10. Size Estimation Accuracy for E2, E3, and E4 during first PSP Task and the second one

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

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]

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.

T ABLE XIV


Task1 Task2

E2 0.09 0.05

E3 0.18 0.02

E4 -0.11 0.01

Fig.. 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

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]

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

T ABLE XV

Productivity Task1 Task2

E2 15.00 16.22

E3 12.00 12.12

E4 0.50 0.57

Est

ima

tio

n A

ccu

ra

cy



Fig.. 12. Productivity for E2, E3, and E4 during first PSP Task and the second one

As shown, after analyzing productivity data for the first and

second PSP assignments for the 3 engineers, their

productivity increases.

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.

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 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 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



Defect Recording Log [E2]

Project Date Num Type Injected Removed Fix Time Description

PA

18-Jun 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 ―Male‖

6 80 code Code

Review 0:09

Admin can't obtain a search result of registered visitors with e-mail data

form

20-Jun 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 doesn’t work

sometimes

23-Jun 10 80 code Unit Test 0:18 Editing events data, then saving the

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 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,

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



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.

Measure of Interest

Failure COQ = 100* (Compile Time + Test Time) / Total

Development Time

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].

Measure of Interest

A/F Ratio = Appraisal COQ (A) / Failure COQ (F)

7) Quality results and analysis:

Defect Density

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.. 13. Defect Density for E2, E3, and E4 during first PSP Task and the second one

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.

Process Yield

The hypothesis to be addressed in this section is as

follows:

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.

T ABLE XIX

Pre-compile Defect Yield Task1 Task2

E2 54.55 71.43

E3 55.56 62.50

E4 33.33 60.00

Fig.. 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 XX&

Fig. 15.

T ABLE XX

A/FR Task1 Task2

E2 0.34 0.68

E3 0.40 0.57

E4 2.65 2.14



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

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

Size Estimation

Accuracy 0.11 0.02


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.. 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.



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.

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/99tr027abstract.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.

[3] <http://www.sei.cmu.edu/publications/documents/00.reports/00tr0

15.html>. [4] Software Engineering Institute. Capability Maturity Model for

Software (CMM), Version1.1, Carnegie Mellon University, 1993.

[5] Software Engineering Institute. Capability Maturity Model Integration (CMMI), Version 1.1, Carnegie Mellon University, 2002.

[6] SPICE Project. Software Process Assessment Part 2: A model for

process management, Version 1.0, 1998. [7] P. Kuvaja, J. Simila, L. Krzanik, A. Bicego, G. Koch, S.

Saukkonen. Software Process Assessment and Improvement: The BOOTSTRAP Approach. Blackwell Publishers, 1994.

[8] B. Curtis, M. I. Kellner, and J. Over. Process Modeling. Communications of the ACM, vol. 35, pp. 75-90, 1992.

[9] 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.

Deming, W. E. Out of the Crisis. MIT Center for Advanced Engineering Study, Cambridge, MA, 1982.

[10] Juran, J. and Gryna, F. Juran's Quality Control Handbook, Fourth Edition. New York: McGraw- Hill Book Company, 1988.

[11] 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)

[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] [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

http://www.sei.cmu.edu/tsp/proceedings07.html

application and evaluation of the personal software process - ijens

Documents