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