Download - 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].
-
8/3/2019 Application and Evaluation of PSP
2/24
International Journal of Basic & Applied Sciences IJBAS Vol: 9 No: 10
96010-1212 IJBAS-IJENS @ International Journals of Engineering and Sciences IJENS
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)
-
8/3/2019 Application and Evaluation of PSP
3/24
International Journal of Basic & Applied Sciences IJBAS Vol: 9 No: 10
96010-1212 IJBAS-IJENS @ International Journals of Engineering and Sciences IJENS
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.
-
8/3/2019 Application and Evaluation of PSP
4/24
International Journal of Basic & Applied Sciences IJBAS Vol: 9 No: 10
96010-1212 IJBAS-IJENS @ International Journals of Engineering and Sciences IJENS
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
-
8/3/2019 Application and Evaluation of PSP
5/24
International Journal of Basic & Applied Sciences IJBAS Vol: 9 No: 10
96010-1212 IJBAS-IJENS @ International Journals of Engineering and Sciences IJENS
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
-
8/3/2019 Application and Evaluation of PSP
6/24
International Journal of Basic & Applied Sciences IJBAS Vol: 9 No: 10
96010-1212 IJBAS-IJENS @ International Journals of Engineering and Sciences IJENS
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
16:17 17:01 0:44 W_ Follow-up Juniors
17:02 17:42 0:40 I_ Lunch Break
17:43 18:03 0:20 I_ Prayer
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
9:51 10:57 1:06 W_ Follow-up Juniors
10:58 12:58 2:00 W_ Programming
12:59 13:22 0:23 I_ Talking
13:23 13:33 0:10 I_ Prayer
13:34 14:00 0:26 I_ Phone
14:01 14:19 0:18 I_ Browsing
14:20 14:38 0: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.
-
8/3/2019 Application and Evaluation of PSP
7/24
International Journal of Basic & Applied Sciences IJBAS Vol: 9 No: 10
96010-1212 IJBAS-IJENS @ International Journals of Engineering and Sciences IJENS
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%
Table 3: E2s Weekly Activity Summary for the first week
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%
Table 4: E3s Weekly Activity Summary for the first week
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/3/2019 Application and Evaluation of PSP
8/24
International Journal of Basic & Applied Sciences IJBAS Vol: 9 No: 10
96010-1212 IJBAS-IJENS @ International Journals of Engineering and Sciences IJENS
62
Table 5: E4s Weekly Activity Summary for the first week
Table 6: E5s Weekly Activity Summary for the first week
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
Productivity TimePercentage
36.63% 3.56% 9.67% 11.30% 2.04% 2.96% 66.15%
-
8/3/2019 Application and Evaluation of PSP
9/24
International Journal of Basic & Applied Sciences IJBAS Vol: 9 No: 10
96010-1212 IJBAS-IJENS @ International Journals of Engineering and Sciences IJENS
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%
Table 8: E2s Weekly work interruptions for the first week
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%
Table 9: E3s Weekly work interruptions for the first week
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%
Table 10: E4s Weekly work interruptions for the first week
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
Productivity TimePercentage
2.63% 9.15% 2.63% 5.04% 2.74% 7.22% 4.22% 33.63%
-
8/3/2019 Application and Evaluation of PSP
10/24
International Journal of Basic & Applied Sciences IJBAS Vol: 9 No: 10
96010-1212 IJBAS-IJENS @ International Journals of Engineering and Sciences IJENS
64
Table 11: E5s Weekly work interruptions for the first week
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.
-
8/3/2019 Application and Evaluation of PSP
11/24
International Journal of Basic & Applied Sciences IJBAS Vol: 9 No: 10
96010-1212 IJBAS-IJENS @ International Journals of Engineering and Sciences IJENS
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.
Figure 4: Productivity and Interruption Time percentage during Week2 for E1, 2, 3, 4, 5
After calculating the average productivity time
percentage and the average interruptions time percentage
during the second week for the five engineers and comparing
it to the result of the first week, we had found the result shown
in Figure 5
-
8/3/2019 Application and Evaluation of PSP
12/24
International Journal of Basic & Applied Sciences IJBAS Vol: 9 No: 10
96010-1212 IJBAS-IJENS @ International Journals of Engineering and Sciences IJENS
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.
-
8/3/2019 Application and Evaluation of PSP
13/24
International Journal of Basic & Applied Sciences IJBAS Vol: 9 No: 10
96010-1212 IJBAS-IJENS @ International Journals of Engineering and Sciences IJENS
67
Figure 6: Productivity and Interruption Time percentage during Week3 for E1, 2, 3, 4, 5
This figure shows that in the third week E1, E2, E3,and E4 indeed have committed to their suggested 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
-
8/3/2019 Application and Evaluation of PSP
14/24
International Journal of Basic & Applied Sciences IJBAS Vol: 9 No: 10
96010-1212 IJBAS-IJENS @ International Journals of Engineering and Sciences IJENS
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.
Figure 8: Productivity and Interruption Time percentage during Week4 for E1, 2, 3, 4, 5
The result of this analysis is very obvious to show
that if the individual himself suggested or planned for 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
-
8/3/2019 Application and Evaluation of PSP
15/24
International Journal of Basic & Applied Sciences IJBAS Vol: 9 No: 10
96010-1212 IJBAS-IJENS @ International Journals of Engineering and Sciences IJENS
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.
-
8/3/2019 Application and Evaluation of PSP
16/24
International Journal of Basic & Applied Sciences IJBAS Vol: 9 No: 10
96010-1212 IJBAS-IJENS @ International Journals of Engineering and Sciences IJENS
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
-
8/3/2019 Application and Evaluation of PSP
17/24
International Journal of Basic & Applied Sciences IJBAS Vol: 9 No: 10
96010-1212 IJBAS-IJENS @ International Journals of Engineering and Sciences IJENS
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)
-
8/3/2019 Application and Evaluation of PSP
18/24
International Journal of Basic & Applied Sciences IJBAS Vol: 9 No: 10
96010-1212 IJBAS-IJENS @ International Journals of Engineering and Sciences IJENS
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
-
8/3/2019 Application and Evaluation of PSP
19/24
International Journal of Basic & Applied Sciences IJBAS Vol: 9 No: 10
96010-1212 IJBAS-IJENS @ International Journals of Engineering and Sciences IJENS
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.
-
8/3/2019 Application and Evaluation of PSP
20/24
International Journal of Basic & Applied Sciences IJBAS Vol: 9 No: 10
96010-1212 IJBAS-IJENS @ International Journals of Engineering and Sciences IJENS
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.
-
8/3/2019 Application and Evaluation of PSP
21/24
International Journal of Basic & Applied Sciences IJBAS Vol: 9 No: 10
96010-1212 IJBAS-IJENS @ International Journals of Engineering and Sciences IJENS
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
-
8/3/2019 Application and Evaluation of PSP
22/24
International Journal of Basic & Applied Sciences IJBAS Vol: 9 No: 10
96010-1212 IJBAS-IJENS @ International Journals of Engineering and Sciences IJENS
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
-
8/3/2019 Application and Evaluation of PSP
23/24
International Journal of Basic & Applied Sciences IJBAS Vol: 9 No: 10
96010-1212 IJBAS-IJENS @ International Journals of Engineering and Sciences IJENS
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.
-
8/3/2019 Application and Evaluation of PSP
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