application and evaluation of psp

8/3/2019 Application and Evaluation of PSP

1/24

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

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

55

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]

AbstractSoftware organizations differ from othermanufacturing organizations, since these software organizations

depend mainly on individuals and team works rather than

machines or raw materials. Enhancing individuals and teamworks capabilities is the key solution to improve quality and

productivity levels.

Hence, Individual engineers need a quality improvementtechnique 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 ofwork quality, and how to estimate time and effort in order to be

able to make the right project plans which contain someestimated data that are close to the actual data. Hence, in our

study, PSP will focus on two principles, improving individualsproductivity, and products and process quality.

KeywordsPSP; 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. INTRODUCTIONThe success of organizations that produce software-

intensive systems depends on well managed software

development processes. Implementing disciplined softwaremethods, however, is often challenging. Organizations seem

to know whatthey 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, individualsoftware 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 orderto better understand and appreciate their strength and

weaknesses as an engineer.

This paper includes detailed presentations of the analysesconducted on size and effort estimation accuracy, process

yield, defect density, and productivity. The paper alsoincludes other observations uncovered during the statisticalanalysis 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 thePSP creates an environment where skilled engineers can apply

disciplined methods working on a cohesive and dedicated

team.

II. RELATEDWORKCurrent 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, butthey 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 processesevolve with the changing needs of the development

organization. In addition, projects must adopt the process with

some level of detail for the organization. Process modelingtechniques 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 modelingto support process improvement, software project

management and Process-centered software engineeringenvironments (PCSEEs) [7].


2/24



56

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 processchanges 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 qualitydepartments 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 tofocus 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 engineeringand manufacturing work.

Even though most industrial organizations have nowadopted modern quality principles, the software community

has continued to rely on testing as the principal qualitymanagement method. For software, the first major step in thedirection pioneered by Deming and Juran was taken by

Michael Fagan when in 1976 he introduced software

inspections [11, 12]. By using inspections, organizations havesubstantially 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]. TheCMMs 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 onthe 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 workthe 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 showsengineers how to manage quality from the beginning of the

job, how to analyze the results of each job, and how to use theresults to improve the process for the next project.

III. PROBLEM DEFINITION

A. The problem of improving personal practicesPerhaps 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 useknown best methods, even when their managers tell them to

do so.

The reasons for these both explain why process improvementis 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 convincethem 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. SolutionThe 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 toprovide 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 beingheld 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 twomedium 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 findingsand suggest improvements for future work.

IV. PERSONAL SOFTWARE PROCESS (PSP)


3/24



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. Whenengineers use the PSP, the recommended process goal is toproduce zero-defect products on schedule and within planned

costs.

A. PSP BasicsThe 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, engineersmust 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; engineersmust strive to do quality work.

(4) It costs less to find and fix defects earlier in a processthan later.

(5) It is more efficient to prevent defects than to find and fixthem.

(6) The right way is always the fastest and cheapest way todo a job.

B. PSP StructureThe structure of the PSP process is shown conceptually in

Figure 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 theplanning data. While the engineers are following the script todo 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 thelogs, 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.

Figure 1: PSP process flow

C. PSP ObjectivesThe 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 STUDYTo 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 thetasks that are done, how they are done, and the obtained

results.

We had to track and understand the way time is currentlyspent.


4/24



58

A. PSP first principle1)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 theystopped 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. Sinceinterruption 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 engineers name, department, and the date ofheader 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 obtainedresults:

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 anunder training designer and this was a suitable opportunity to

follow-up, analyze and evaluate her performance in general, inaddition 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 theirinterruptions. 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 maininterruption 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 wedelivered the time recording log to every one of them to beginfilling-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 todetermine 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 otherwork 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, inaddition 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 workingactivities 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 withI_ 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 thefive time recording logs for the five engineers, and began to

read them carefully in order to analyze each onesperformance; 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 torecord in the time recording log.

Table 1: E2s Time Recording Log

Time Recording Log

Engineer

Name:E2

Department: Project Development

Date: 9-May


5/24



59

Date Start StopInterruption

TimeDelta Time Activity

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

9-May

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

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

10-May

17:23 17:54 0:31 W_ Reading

Totals 1:52 7:06

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_ Browsing15:34 16:26 0:52 Programming

16:27 16:35 0:08 Phone

16:36 16:50 0:14 I_ Talking

11-May

16:51 17:06 0:15 I_ Other Interruptions


6/24



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

12-May

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


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

13-May

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


7/24



61

Table 2: E1s Weekly Activity Summary for the first week

Week1 E1

Activity

W_

AssigningTask

W_Browsing

W_

CustomerService

W_Email

W_

Follow-

up

Seniorswork

W_

ManagingProjects

Tasks

W_Reading

W_Phone

W_Talking

TotalTime

Date

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

ProductivityTime

Percentage

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


Week1 E2

ActivityW_

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 TimePercentage

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


Week1 E3

ActivityW_

ProgrammingW_

Reading

W_ Follow-up

Juniors W_ BrowsingW_

EmailW_

TalkingTotalTime

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:001:17:0

00:58:00 30:14:00

Productivity Time

Percentage

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


8/24



62



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

Percentage25.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 toknow 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 percentageof time spent practicing every working activity.

After calculating this percentage, we have reached

that the productivity time percentage for E1, E2, E3, E4, andE5 in week1.

Then, we had clarified this result using figures for

further comparisons of weekly productivity results andpresentations 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 11respectively.

Table 7: E1s Weekly work interruptions for the first week

Week 1 E1

Interruption I_Browsing

I_Breakfast

I_ OtherInterruptions

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

Week1 E4

Activity W_ DesigningW_

Reading

W_ Follow-up

JuniorsW_

BrowsingW_ 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:0029:46:0

0


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


9/24



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

Percentage16.56% 3.37% 7.93% 6.48% 7.22% 2.96% 44.52%


Week 1 E2

InterruptionI_

Breakfast

I_

Browsing

I_ Other

Interruptions

I_

Lunch

Break

I_

Phone

I_

PrayerI_ 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 Percentage2.78% 2.19% 1.33% 4.93% 2.70% 5.93% 3.22% 23.07%


Week 1 E3

InterruptionI_

Breakfast

I_

Browsing

I_ Other

Interruptions

I_

Lunch

Break

I_

PhoneI_ 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:00Productivity Time

Percentage2.04% 11.63% 2.26% 5.63% 2.07% 7.19% 2.04% 32.85%


Week 1 E4

InterruptionI_

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


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


10/24



64


Week 1 E5

Interruption I_ Breakfast I_ Browsing I_ Lunch Break I_ PhoneI_

PrayerI_

TalkingTotalTime

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

Percentage3.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 Figure 2

Figure 2: Productivity and Interruption Time 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 foundthe result shown in Figure 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 resultsindeed shows that there is a big need for productivity

improvement.


11/24



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 ofthe second week, then we had to gather these time recording

logs and do exactly what we had to do in the first week inaddition to comparing the second weeks 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.


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


12/24



66

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 otherside, the average interruption time percentage was nearly close

to this of the first week, it was 36.39% and only decreased bya 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 averageinterruptions 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 couldnt get over theirinterruptions 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 weeks

results, we have arranged for a meeting with the attendance ofthe 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 orat 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 owninterruptions, but also there are common interruptions that can

be eliminated. Engineers thought, suggested and gotcommitted 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 themorning.

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 bothprayers during the working day.

Talking out of work scope, will be at breaks, ifurgent then 10 minutes maximum.

Browsing for entertainment is limited to 10 minutesmaximum per day.

Concerning the other interruptions like printing apaper, or sudden meeting with a client etc, theirtime 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 theworking day.

Following-up juniors will be eliminated to be onehour 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. Thework and the commitment lasted all over the third week, and

after the end of this week, we resumed the work that we havedone 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.


13/24



67


This figure shows that in the third week E1, E2, E3,and E4 indeed have committed to their suggested policywhich 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 worktraining, 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 percentageduring 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

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


14/24



68

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 acceptablesince 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 figures 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 hisneeds 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 weeks 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 individualsperformance 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, andindeed the evaluation has shown that she is technically weak

and consequently, her head manager cant depend on her

work, so the management department with her head manager

have decided to report her with the end of her relationshipwith the organization after finishing her probation period.

After calculating the average productivity time

percentage and the average interruptions time percentageduring 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

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


15/24



69

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 thisof 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 timepercentage 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 of5.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 hasbeen 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 beenachieved successfully and with a very acceptable result.

B. PSP Second PrincipleHere, 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 collectionprocesses are also included to provide additional context for

understanding the results.

Engineers learn to use the PSP by developing differenttasks 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 measuredand recorded on provided forms. A simple plan summary form

like shown in Figure 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 ontheir 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 programminglanguage 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 measuredconsistently, 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 ormodified; 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 fromthe programs ability to completely and effectively meet the

users needs. A defect is an objective measure that engineerscan identify, describe, and count.

Engineers use many other measures that are derived

from these three basic measures. Both planned and actual datafor 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 ratio2) PSP Plan summaryTask summary data are recorded on the Task Plan

Summary form. This form provides a convenient summary ofplanned 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 sourcefor 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, andDefects Removed.


16/24



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


17/24



71

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 12, the summary section holdsthe 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 5Minutes/LOC; he might need to use a different value if the

new task seems particularly difficult and likely to take longerthan 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. TheLOC/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 actualdata on the task size and likely size ranges. E2 estimated the

finished size of the task he planned to develop and entered itunder plan in the Total New & Changed row as shown in

Table 12.

Then he calculated the maximum and minimum sizenumbers, 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 thesoftware development process. E2 calculated total planned

development time by multiplying the planned Minutes/LOC

by the planned New & Changed LOC. Also, he multiplied theminimum 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 phaseof 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 theway he has spent time on previous such tasks. He calculated

these times using Minutes for easy calculations.

Then, he estimated from his prior knowledge thespent 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, E2should 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 phasedivided by the total To Date time.

For subsequent projects, however, engineers can use

the data from previous tasks, like this task for example, toestimate 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% columnholds the percentage distribution of the times in the To Datecolumn.

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


18/24



72

Effort Estimation AccuracyUse of historical data for deriving effort estimates is

common practice in the software industry today. However,

estimation at the level of an individual engineers workload

remains a challenge. The PSP training provides engineerswith 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 (EstimatedMinutes, Actual Minutes)

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

Size EstimationThe 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 theprogram at the end [19].

With the introduction of historical size estimation

data that every engineer has used before, and accumulatingthese values To Date, engineers can progress through the PSP

training and can predict closer values to their actual sizeestimation 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 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 secondPSP assignments for the 3 engineers, their size estimates

grow closer to the actual size of the task

Effort EstimationIn this section, data are used to test the following

hypothesis:

As engineers progress through the PSP training, their effortestimates grow closer to the actual effort expended for theentire 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 &Figure 11.

Table 14:Effort Estimation Accuracy

Task1 Task2

E2 0.09 0.05

E3 0.18 0.02

E4 -0.11 0.01

Figure 11: Effort Estimation Accuracy for E2, E3, and E4 during first PSPTask 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]EstimationAccuracy


19/24



73

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 ofcode were written per hour shown in Table 15 & Figure 12

Table 15: Productivity

Task1 Task2

E2 15.00 16.22

E3 12.00 12.12

E4 0.50 0.57

Figure 12: Productivity for E2, E3, and E4 during first PSP Task and thesecond 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 andanother section defining the number of defects that were

removed during which phase.

But before filling-in the plan summary sectionsconcerning 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]

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

them. To do that, every engineer must gather defect data. Then

he can understand these mistakes and figure out how to avoid

them.


20/24



74

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

Records enough information on each defect so, hecan later understand it.

Analyzes these data to see what defect types causedthe 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 17

Table 17: E2s Defect Recording Log

Defect Recording Log [E2]

Project Date Num Type Injected Removed Fix Time Description

18-Jun 1 20 codeCode

Review0:01 missing ;

2 50 codeCode

Review0:03 incorrectly formatted call

3 80 designCode

Review0:01 forgot to initialize variable

4 20 codeCode

Review0:01 misspelled variable

5 80 code

Code

Review 0:04

Adding an email for a female user in

the newsletters list is inserted andsaved as Male

6 80 codeCodeReview

0:09

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

form

20-Jun 7 20 code Compile 0:01 ; entered as :

8 60 code Compile 0:06Admin cant change his old

password, always Error message

appears

9 80 code Compile 0:16Editing shops doesnt work

sometimes

PA

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

edited data doesnt work properly

When E2 started to develop his task, he prepared this

log, and when he first encountered a defect, he entered itsnumber in the log, the date when it was found, its type

according to the defect type standard, the phase in which itwas 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 thedefect 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 entereda 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 willbe more remaining after the test phase is completed.


21/24



75

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 thePSP objective is to produce high quality programs, thesuggested 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 codereviews, including the time spent repairing the defects foundin 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. Thefailure 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) / TotalDevelopment Time

The A/FR measure provides a useful way to assessquality, 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 engineerattempted 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 DensityThe 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 andtest phases decrease significantly like shown in Table 18&

Figure 13.

Table 18 : Defect Density

Task1 Task2

E2 19.30 12.01

E3 20.32 18.22

E4 3.46 1.72

Figure 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 secondPSP assignments for the 3 engineers, there is a significant

increase in the defect density values.

Process YieldThe 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 likeshown in Table 19& Figure14.

Table 19: Pre-compile Defect Yield

Task1 Task2

E2 54.55 71.43

E3 55.56 62.50

E4 33.33 60.00


22/24



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 PSPassignments for the 3 engineers, there is a significant increase

in the process Yield values.

A/FRThe hypothesis to be addressed in this section is as

follows:

As engineers progress through the PSP training, their A/FRvalue 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 fewif any defects will be found in test, like shown in Table 20&

Figure 15.

Table 20: A/FR

Task1 Task2

E2 0.34 0.68

E3 0.40 0.57

E4 2.65 2.14

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 ofquality for the first and second PSP assignments for the 3

engineers, there is a significant increase in the process A/FRvalues.

8) PSP approach summary:The results from PSP training were impressive. These

results are summarized in Table 21 and are shown in Figure16. 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 showsits value at the end of PSP training (Average for the two PSP

assignments for the three engineers) like shown in Table 21 &

Figure 16Table 21: Summarized results

MeasureAt the start of

training

At the end of

training

Size Estimation

Accuracy0.11 0.02

Effort Estimation

Accuracy0.05 0.03

Productivity 9.17 9.64

Defect Density 14.36 10.65

Process Yield 47.81 64.64

Process Quality costratio A/FR

1.13 1.13


23/24



77

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

Hence, we can say that form the beginning of theassigned 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. CONCLUSIONThe 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.


24/24

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

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

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, productquality, and process quality, were statistically significant.

No statistically significant change in productivity wasfound, 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 representreal 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. PSPSTATUS AND FUTURE TRENDSWhile 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 tolearn 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 Australianow 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 ofthe (Personal Software Process) PSP, (Team Software

Process) TSP, and (Capability Maturity Model) CMM

methods and a closer coupling of the PSP academic courseswith the broader computer science and software engineering

curricula.

REFERENCES

[1] Ferguson, P.; Leman, G; Perini, P; Renner, S.; & Seshagiri, G. SoftwareProcess Improvement Works! (CMU/SEI-99-TR-027, ADA371804).

Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University,

1999..

[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] 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. Lessonslearned 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. MITCenter 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 onSoftware 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 TSPSymposium, 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

application and evaluation of psp

Documents