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

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
1

Computer Science department, Mansoura University, 60 El Gomhuria st., Mansoura, Egypt 2 Computer Science department, Zagazig University, Zagazig, Egypt
*Corresponding Author: eman.khereba@yahoo.com

AbstractSoftware organizations differ from other manufacturing organizations, since these software organizations depend mainly on individuals and team works rather than machines or raw materials. Enhancing individuals and team works capabilities is the key solution to improve quality and productivity levels.
Hence, Individual engineers need a quality improvement technique to improve their performance by bringing discipline to the way they develop software and manage their work to produce quality products within budget and on schedule. This paper will propose a case study showing the application and evaluation of the Personal Software Process (PSP), which recommends applying some skills and methods that concerns the individual engineer her/himself, like understating the meaning of work quality, and how to estimate time and effort in order to be able to make the right project plans which contain some estimated data that are close to the actual data. Hence, in our study, PSP will focus on two principles, improving individuals productivity, and products and process quality. 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

small projects during which the engineer collects measurements on defect rates, defect types, and other indicators of engineer productivity and effectiveness in order to better understand and appreciate their strength and weaknesses as an engineer. This paper includes detailed presentations of the analyses conducted on size and effort estimation accuracy, process yield, defect density, and productivity. The paper also includes other observations uncovered during the statistical analysis and study conclusions which contain experiences of and benefits realized by first-time PSP individuals. We hope that by walking through this first-time individuals journey of using the PSP, we illustrate how the PSP creates an environment where skilled engineers can apply disciplined methods working on a cohesive and dedicated team. II. RELATED WORK

I.

INTRODUCTION

The success of organizations that produce softwareintensive 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

Current research on software development processes intends to define the process elements that constitute good practices, leaving implementation and enactment of the process to organizations. Some of these approaches include CMM [3], CMMI [4], SPICE [5] and Bootstrap [6]. However, these models are very descriptive in the sense that they explain essential attributes that would be expected to characterize an organization at a particular maturity level, but they specify neither how to improve nor the specific means to get into a particular maturity level. But, as discussed by the research community, also important is the way processes evolve with the changing needs of the development organization. In addition, projects must adopt the process with some level of detail for the organization. Process modeling techniques are useful in defining the process, especially in the upper levels of maturity models like CMMI. Curtis, Kellner and Over discussed some approaches using process modeling to support process improvement, software project management and Process-centered software engineering environments (PCSEEs) [7].

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

International Journal of Basic & Applied Sciences IJBAS Vol: 9 No: 10 The Software Process Management System (SPMS) development identified and addressed the need for process models to be reusable, to support multiple views, to recognize process, product and human interactions to support process changes during development projects, and to support historical recording of the process over long periods of time [8]. Until shortly after World War II, the quality strategy in most industrial organizations was based almost entirely on testing. Groups typically established special quality departments to find and fix problems after products had been produced. It was not until the 1970s and 1980s that W. Edwards Deming and J.M. Juran convinced U.S. industry to focus on improving the way people did their jobs [9, 10]. In the succeeding years, this focus on working processes has been responsible for major improvements in the quality of automobiles, electronics, or almost any other kind of product. The traditional test-and-fix strategy is now recognized as expensive, time-consuming, and ineffective for engineering and manufacturing work. Even though most industrial organizations have now adopted modern quality principles, the software community has continued to rely on testing as the principal quality management method. For software, the first major step in the direction pioneered by Deming and Juran was taken by Michael Fagan when in 1976 he introduced software inspections [11, 12]. By using inspections, organizations have substantially improved software quality. Another significant step in software quality improvement was taken with the initial introduction of the Capability Maturity Model (CMM) for software in 1987 [13, 14]. The CMMs 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 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 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

56

A. The problem of improving personal practices Perhaps the most critical issue in improving the state of software practice is getting software engineers to use improved methods. This is a nontrivial problem, particularly because even intelligent people often will not do things that common logic, experience, and even hard evidence suggests that they should. Many software engineers thus do not use known best methods, even when their managers tell them to do so. The reasons for these both explain why process improvement is so difficult and suggests logic for addressing the problem. In summary these reasons are: (1) Once engineers have learned how to develop small programs that work, they have also established some basic personal practices. (2) The more engineers use and reinforce these initial methods, the more ingrained they become and the harder they are to change. (3) Engineers have found that many impressivesounding tools and techniques do not provide their promised benefits. It is therefore hard to convince them that some new methods will help them to do better work. (4) Since no one generally observes the methods software engineers use, no one will know how they work. Thus engineers don't have to change their working methods if they don't want to. B. Solution The problems of improving the personal practices of software engineers were our main goal, so, when we had the opportunity, we started a study of how process improvement principles would apply to individual software work. The purpose of this paper is to provide results on the use of the PSP. The paper starts with an overview of the PSP to provide a context for the results here. This is followed by a detailed discussion and analysis for the PSP first principle, which concerns individuals interruptions handling in order to increase their actual working time and decrease their interruptions time, another discussion and analysis is being held in order to cover the second PSP principle which concerns increasing individuals productivity, and product and process quality using PSP planning and measurement forms, Development and data collection processes are also included to provide additional context for understanding the results. Next, we summarize the performance after applying two medium sized projects, with two similar tasks for each engineer, of a medium size software organization that has practiced the PSP. Then, we conclude our analysis findings and suggest improvements for future work. IV. PERSONAL SOFTWARE PROCESS (PSP)

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

International Journal of Basic & Applied Sciences IJBAS Vol: 9 No: 10 The Personal Software Process (PSP) provides engineers with a disciplined personal framework for doing software work. The PSP process consists of a set of methods, forms, and scripts that show software engineers how to plan, measure, and manage their work. The PSP is designed for use with any programming language or design methodology and it can be used for most aspects of software work, including writing requirements, running tests, defining processes, and repairing defects. When engineers use the PSP, the recommended process goal is to produce zero-defect products on schedule and within planned costs. A. PSP Basics The PSP design is based on the following planning and quality Basics: (1) Every engineer is different; to be most effective, engineers must plan their work and they must base their plans on their own personal data. (2) To consistently improve their performance, engineers must personally use well-defined and measured processes. (3) To produce quality products, engineers must feel personally responsible for the quality of their products. Superior products are not produced by mistake; engineers must strive to do quality work. (4) It costs less to find and fix defects earlier in a process than later. (5) It is more efficient to prevent defects than to find and fix them. (6) The right way is always the fastest and cheapest way to do a job. B. PSP Structure The structure of the PSP process is shown conceptually in 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 the planning data. While the engineers are following the script to do the work, they record their time and defect data on the time and defect logs. At the end of the job, during the postmortem phase (PM), they summarize the time and defect data from the logs, measure the program or task size, and enter these data in the plan summary form. When done, they deliver the finished product along with the completed plan summary form.

57

Figure 1: PSP process flow

C. PSP Objectives The PSP aims to provide software engineers with disciplined methods for improving personal software development processes. The PSP helps software engineers to: Improve their estimating and planning skills. Make commitments they can keep. Manage the quality of their projects. Reduce the number of defects in their work. The goal of the PSP is to help developers produce quality, zero-defect, products on schedule. Low-defect and zero defect products have become the reality for some developers. V. CASE STUDY

To make realistic plans, we had to apply the first principle of the PSP, which focuses on estimating and evaluating individuals performance then improving it in order to improve the overall productivity level in the organization. The way to improve the productivity and quality of work is to start by understanding what is currently done inside the software organization. This means that we have to know the tasks that are done, how they are done, and the obtained results. We had to track and understand the way time is currently spent.

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

International Journal of Basic & Applied Sciences IJBAS Vol: 9 No: 10 A. PSP first principle 1) Handling interruptions: In the PSP, engineers use the time recording log to measure the time spent in each task. In this log, they note the time they started working on a task, the time when they stopped the task, and any interruption time. For example, an interruption would be a phone call, a brief break, or any other type of interruptions. By tracking time precisely, engineers track the effort actually spent on project tasks. Since interruption time is essentially random, ignoring these times would add a large random error into the time data and reduce estimating accuracy. The form used for recording time is called Time Recording Log. The top of the form is called the header and it has spaces for engineers 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

58

of time spent doing the main activities for every working day and the percentage of interruptions during that day, to show engineers their productivity percentages and what interruptions that affect their work and what are their percentages too, in order to realize what really affects their work and waste their time and also try to eliminate these interruptions as soon as possible. Here, we began to present a brief introduction or training to the individuals about this approach, and we delivered the time recording log to every one of them to begin filling-in every action happens during the working day in a timely manner. Before starting filling-in the time recording log, we have arranged for a meeting including the five engineers to determine their main working activities and the main interruptions that affects their work to be included in their logs. They determined their common working activities to be like, emails whether for reading or writing or attachments, browsing, reading, and talking about work, in addition to other work specifications that each individual engineer practices. About their common interruptions, they mentioned their interruptions to be like, breakfast, phone calls, prayer, talking with colleagues away from working times, lunch breaks, in addition to other interruptions that concerns each individual like printing some paper, sudden meetings with clients, helping other colleague, going to the commerce chamber, making a change in a template or a layout design, etc. They have also determined their common working activities to have a naming convention to differentiate them from interrupting actions, and this naming convention is W_ activity name for main working activities and I_ Interruption name for interruptions, for example W_ Programming and W _Browsing, represent programming and browsing activities are for favor of work, in contrary with I_ Browsing and I_ Lunch Break, which represent that time is spent in favor of interruption like browsing for entertainment or having a break for lunch. After the end of the first week, we have gathered the five time recording logs for the five engineers, and began to read them carefully in order to analyze each ones performance; in both directions: estimating total productivity time percentage and total interruption time percentage. Table 1 shows the time recording logs for E2 during his first week of work after having his first training on how to record in the time recording log.

Table 1: E2s Time Recording Log

Time Recording Log Engineer E2 Name: Project Development Department: 9-May Date:

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

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

Date Start 9:05 9:20 9:30 9:59 10:32 10:49 9-May 13:09 13:25 15:28 16:07 16:32 16:39 16:54 Totals 9:01 9:20 9:34 10:27 13:17 13:41 10-May 13:52 14:57 15:06 16:14 16:14 16:37 16:50 17:13 17:23 Totals 11-May 9:32 9:54 9:58 13:11 13:40 14:08 14:19 14:54 15:34 16:27 16:36 16:51 Stop 9:17 9:29 9:58 10:31 10:47 13:12 13:25 15:26 16:03 16:30 16:38 16:53 18:08 9:18 9:33 10:25 13:15 13:38 13:51 14:56 15:05 16:13 16:37 16:36 16:49 17:12 17:22 17:54 1:52 9:53 9:58 13:10 13:39 14:07 14:19 14:53 15:33 16:26 16:35 16:50 17:06 0:08 0:14 0:15 0:28 0:27 0:11 0:34 0:39 0:52 0:21 0:04 3:12 0:22 0:12 0:22 0:09 0:31 7:06 0:08 1:07 0:23 0:21 0:10 1:04 2:23 0:17 0:14 1:14 6:25 0:13 0:51 2:48 0:35 0:23 0:06 0:16 2:01 0:15 2:23 0:28 0:32 Interruption Time 0:12 0:09 Delta Time Activity I_ Breakfast W_ Email I_ Talking W_ Follow-up juniors I_ Phone W_ Programming I_ Prayer W_ Programming I_ Lunch Break I_ Prayer W_ Talking I_ Browsing W_ Programming I_ Breakfast W_ Email W_ Follow-up Juniors W_ Programming I_ Prayer I_ Browsing W_ Programming I_ Phone W_ Programming W_ Talking I_ Prayer I_ Talking I_ Lunch Break W_ Browsing W_ Reading I_ Breakfast W_ Email W_ Programming W_ Prayer I_ Follow-up Juniors W_ Reading Programming W_ Browsing Programming Phone I_ Talking I_ Other Interruptions

59

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

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

17:07 17:25 17:43 18:20 Totals 9:08 9:16 9:18 9:29 10:09 12:15 12-May 12:32 12:54 13:39 14:05 16:17 17:02 17:43 18:04 Totals 9:08 9:27 9:51 10:58 12:59 13:23 13-May 13:34 14:01 14:20 14:39 15:22 15:59 16:07 Totals 9:26 9:50 10:57 12:58 13:22 13:33 14:00 14:19 14:38 15:21 15:57 16:05 18:22 1:41 0:06 2:15 7:19 0:23 0:10 0:26 0:18 0:18 0:42 0:35 9:15 9:18 9:28 10:08 12:14 12:31 12:53 13:38 14:03 16:16 17:01 17:42 18:03 18:20 2:18 0:18 0:23 1:06 2:00 0:40 0:20 0:16 6:41 I_ Breakfast W_ Email W_ Follow-up Juniors W_ Programming I_ Talking I_ Prayer I_ Phone I_ Browsing W_ Talking W_ Browsing W_ Programming I_ Prayer W_ Programming 0:24 2:11 0:44 0:16 0:21 0:44 0:10 0:39 2:05 17:24 17:42 18:19 18:42 2:36 0:07 0:02 0:17 0:17 0:36 0:22 6:21 I_ Breakfast W_ Email I_ Talking W_ Reading W_ Programming I_ Phone I_ Other Interruptions W_ Browsing I_ Prayer W_ Programming W_ Follow-up Juniors I_ Lunch Break I_ Prayer W_ Talking Prayer I_ Browsing I_ Lunch Break W_ Talking

60

After recording these data during the first week, we have categorized and analyzed it to know exactly the percentage of time spent doing the main work activities and the percentage of interruptions that affects the work. Here, we have used a form called weekly activity summary like this

shown in Table 2 which categorizes the main working activities that the engineers have frequently practiced during their first week and we have recorded them as shown in Table 2, 3, 4, 5, and 6 respectively.

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

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

Table 2: E1s Weekly Activity Summary for the first week

61

Week1

E1 W_ Assigning Task W_ Browsing W_ Customer Service W_ Email W_ Followup Seniors work 1:03 1:03 0:15 2:11 0:16 4:48 10.67% 1:45 3.89% 1:13 2.70% 1:45 0:14 0:59 W_ Managing Projects Tasks W_ Reading W_ Phone W_ Talking Total Time

Activity

Date 9-Jun 10-Jun 11-Jun 12-Jun 13-Jun Totals Productivity Time Percentage 0:58 2.15% 0:19 0:05 0:20 0:14 0:35 0:24 0:33 0:56 0:48 3:16 7.26% 3:02 1:57 0:53 1:28 0:16 7:36 16.89% 0:31 0:16 0:26 0:15 0:17 1:45 3.89% 0:16 0:43 0:17 0:22 0:24 2:02 4.52% 0:22 0:24 0:14 0:18 0:21 1:39 3.67% 6:08 4:52 4:57 6:43 2:22 25:02 55.63%

Table 3: E2s Weekly Activity Summary for the first week

Week1 Activity Date 9-Jun 10-Jun 11-Jun 12-Jun 13-Jun Totals Productivity Time Percentage

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

5:38 4:59 4:38 4:16 4:50 24:21:00 54.11% 1:21:00 3.00% 0:31 0:11 0:39

0:32 0:51 0:27 0:44 1:06 3:40:00 8.15% 0:09 0:39 0:44 0:42 2:14:00 4.96%

0:09 0:13 0:04 0:02 0:23 0:51:00 1.89%

0:06 0:23 0:22 0:16 0:18 1:25:00 3.15%

6:25 7:06 6:21 6:41 7:19 33:52:00 75.26%

Table 4: E3s Weekly Activity Summary for the first week

Week1 Activity Date 9-Jun 10-Jun 11-Jun 12-Jun 13-Jun Totals Productivity Time Percentage

E3 W_ Programming 4:02 3:31 4:19 3:31 3:04 18:27:00 41.00% W_ Reading W_ Follow-up Juniors W_ Browsing W_ Email 0:19 0:20 0:08 0:06 0:24 1:17:0 0 2.85% W_ Talking 0:10 0:09 0:31 0:08 0:58:00 2.15% Total Time 5:54:00 6:30:00 5:40:00 6:35:00 5:35:00 30:14:00 67.19%

0:43 1:12 1:55:00 4.26%

1:11 1:29 0:42 0:31 1:04 4:57:00 11.00%

0:12 0:18 1:07 1:03 2:40:00 5.93%

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

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

Table 5: E4s Weekly Activity Summary for the first week

62

Week1 Activity Date 9-Jun 10-Jun 11-Jun 12-Jun 13-Jun Totals Productivity Time Percentage

E4 W_ Designing W_ Reading W_ Follow-up Juniors W_ Browsing W_ Email W_ Talking Total Time

4:51 1:00 3:03 3:51 3:44 16:29:00 36.63% 0:16 0:18 1:36:00 3.56% 1:02

0:11 2:38 0:14 0:21 0:57 4:21:00 9.67%

0:32 1:33 0:19 0:49 1:52 5:05:00 11.30%

0:05 0:08 0:03 0:12 0:27 0:55:00 2.04%

0:10 0:14 0:05 0:23 0:28 1:20:00 2.96%

5:49 6:35 3:44 5:52 7:46 29:46:0 0 66.15%

Table 6: E5s Weekly Activity Summary for the first week

Week1

E5 W_ Reading W_ Browsing W_ Talking

Activity

W_ Designing

W_ Email

Total Time

Date 9-Jun 10-Jun 11-Jun 12-Jun 13-Jun Totals Productivity Time Percentage 2:44 1:15 3:03 2:32 1:48 11:22:00 25.26% 0:16 0:18 1:36:00 3.56% 1:02 1:33 0:19 0:49 1:52 4:33:00 10.11% 0:09 0:08 0:08 0:09 0:07 0:41:00 1.52% 0:16 0:14 0:29 0:23 0:17 1:39:00 3.67% 3:09 4:12 3:59 4:09 4:22 19:51:00 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. After calculating this percentage, we have reached that the productivity time percentage for E1, E2, E3, E4, and E5 in week1.

Then, we had clarified this result using figures for further comparisons of weekly productivity results and presentations that will let us; the managers, professors, and the engineers themselves follow-up the organization productivity status every week. Then we had categorized the interruptions that interrupted E1, E2, E3, E4, and E5 during this week, and we had found the result is as shown in Table 7, 8, 9, 10, and 11 respectively.

Table 7: E1s Weekly work interruptions for the first week

Week 1 Interruption Date 9-Jun 10-Jun

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

0:49 1:07

0:12 0:22

0:16 1:47

0:24 0:08

0:50 0:42

0:19 0:03

2:50 4:09

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

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

11-Jun 12-Jun 13-Jun Totals Productivity Time Percentage 2:32 0:28 2:31 7:27:00 16.56% 0:09 0:33 0:15 1:31:00 3.37% 0:25 0:09 0:57 3:34:00 7.93% 0:13 0:13 1:57 2:55:00 6.48% 0:44 0:45 0:14 3:15:00 7.22% 0:05 0:08 0:45 1:20:00 2.96% 4:08 2:16 6:39 20:02:00 44.52%

63

Table 8: E2s Weekly work interruptions for the first week

Week 1 Interruption Date 9-Jun 10-Jun 11-Jun 12-Jun 13-Jun Totals Productivity Time Percentage

E2 I_ Breakfast 0:12 0:17 0:21 0:07 0:18 1:15 2.78% 0:18 0:59 2.19% 0:36 1.33% 2:13 4.93% I_ Browsing 0:14 0:10 0:17 0:15 0:21 I_ Other Interruptions I_ Lunch Break 0:35 0:22 0:36 0:40 I_ Phone 0:15 0:08 0:08 0:16 0:26 1:13 2.70% I_ Prayer 0:12 0:43 0:45 0:44 0:16 2:40 5.93% I_ Talking Total Time

0:28 0:12 0:14 0:10 0:23 1:27 3.22%

1:56 1:52 2:36 2:18 1:41 10:23:00 23.07%

Table 9: E3s Weekly work interruptions for the first week

Week 1 Interruption Date 9-Jun 10-Jun 11-Jun 12-Jun 13-Jun Totals Productivity Time Percentage

E3 I_ Breakfast 0:04 0:12 0:04 0:16 0:19 0:55:00 2.04% I_ Browsing 2:02 0:41 1:05 0:16 1:10 5:14:00 11.63% 0:12 1:01:00 2.26% 0:49 I_ Other Interruptions I_ Lunch Break 0:11 0:33 0:31 0:36 0:41 2:32:00 5.63% I_ Phone I_ Prayer I_ Talking Total Time

0:16 0:04 0:07 0:29 0:56:00 2.07%

0:47 0:43 0:44 0:42 0:18 3:14:00 7.19%

0:05 0:03 0:09 0:21 0:17 0:55:00 2.04%

3:09 2:28 3:26 2:18 3:26 14:47:00 32.85%

Table 10: E4s Weekly work interruptions for the first week

Week 1 Interruption Date 9-Jun 10-Jun 11-Jun 12-Jun 13-Jun Totals Productivity Time Percentage

E4 I_ Breakfast I_ Browsing I_ Other Interruptions I_ Lunch Break I_ Phone I_ Prayer I_ Talking Total Time

0:10 0:19 0:16 0:12 0:14 1:11:00 2.63%

0:40 0:37 2:03 0:40 0:07 4:07:00 9.15% 0:12 1:11:00 2.63% 0:59

0:28 0:16 0:31 0:39 0:22 2:16:00 5.04%

0:32 0:09 0:33 1:14:00 2.74%

0:46 0:42 0:44 0:45 0:18 3:15:00 7.22%

0:35 0:22 0:33 0:16 0:08 1:54:00 4.22%

3:11 2:16 5:15 3:05 1:21 15:08:00 33.63%

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

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

Table 11: E5s Weekly work interruptions for the first week

64

Week 1 Interruption Date 9-Jun 10-Jun 11-Jun 12-Jun 13-Jun Totals Productivity Time Percentage

E5 I_ Breakfast I_ Browsing I_ Lunch Break I_ Phone I_ Prayer I_ Talking Total Time

0:14 0:22 0:16 0:17 0:15 1:24:00 3.11%

2:40 2:37 2:52 3:02 3:14 14:25:00 32.04%

0:22 0:19 0:29 0:28 0:17 1:55:00 4.26%

0:19 0:06 0:12 0:09 0:10 0:56:00 2.07%

0:33 0:43 0:41 0:36 0:28 3:01:00 6.70%

1:44 0:44 0:32 0:17 0:17 3:34:00 7.93%

5:52 4:51 5:02 4:49 4:41 25:15:00 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 found the 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 results indeed shows that there is a big need for productivity improvement.

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

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

65

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

After making the previous analysis, we had shown the analysis results to every engineer, and everyone agreed that there is a real need for improving this productivity level, and they decided that this need will be their target in the second week. In the second week, every engineer has begun to focus on how to improve the productivity percentage even if they had to stay working after the original working times.

They began to do exactly what they had to do in the first week, they filled-in their time recording log with their main working activities and their interruptions until the end of the second week, then we had to gather these time recording logs and do exactly what we had to do in the first week in addition to comparing the second 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

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

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

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 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 couldnt 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 weeks results, we have arranged for a meeting with the attendance of the five engineers and the management representative to show them the second week results and to discuss some solutions or suggestions in order to overcome the interruptions problem or at least to eliminate it. During this meeting, every engineer discussed his main interruptions which cause waste of time and how he can overcome them, of course every individual has his own interruptions, but also there are common interruptions that can be eliminated. Engineers thought, suggested and got committed to a policy for them and for the organization which focuses on eliminating interruptions and improving productivity, and consequently improving product quality.

The policy that the engineers have stated includes the following: The period of breakfast will be 15 minute maximum in the morning. Lunch breaks will be 30 minutes maximum per day. Phone calls will be eliminated to be messages or if it is very urgent, then it will be eliminated to 20 minutes maximum per day. Prayer will be 30 minutes maximum per day for both prayers during the working day. Talking out of work scope, will be at breaks, if urgent then 10 minutes maximum. Browsing for entertainment is limited to 10 minutes maximum per day. Concerning the other interruptions like printing a paper, or sudden meeting with a client etc, their time will be recorded as a normal interruption time, but it will be neglected because as possible as we can, we will try to resume this amount of time after the original working time of the day. Browsing for work will be for an hour all over the working day. Following-up juniors will be eliminated to be one hour distributed into two periods of the day, whether before or after prayer breaks.

In the third week, engineers have resumed their work exactly as they have done in the first and the second week, but focusing on their commitment to their suggested policy. The work and the commitment lasted all over the third week, and after the end of this week, we resumed the work that we have done since the last two weeks. After gathering the time recording logs, and making our analysis, we obtained these results that are shown in figures 6 for E1, E2, E3, E4, and E5.

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

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

67

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

This figure shows that in the third week E1, E2, E3, and E4 indeed have committed to their suggested policy which has led to an improvement in the percentage of every engineer productivity level and decreased their interruptions level, except for the last engineer E5, who was under work training, seemed to be not active in addition to her low technical performance which led her department manager not to depend on her work too much.

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

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

This analysis shows that the average productivity 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

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

International Journal of Basic & Applied Sciences IJBAS Vol: 9 No: 10 this of the second week by a factor of 7.57% but this percentage will be neglected since it was due to staying working at work over the original working hours during the second week, but the result of the third week is acceptable since it was reached within the range of the original working hours of the day, on the other side, the average interruption time percentage was 30.72%, which was lower than this of the

68

first week by a factor of 7.32% and this of the second week by a factor of 5.67% . Applying this approach lasted for the fourth week as it lasted for the previous three weeks, and after the analysis of its data, we have found the results shown in figures 8 for E1, E2, E3, E4, and E5.

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

The result of this analysis is very obvious to show that if the individual himself suggested or planned for his needs time and behaved as if he is his manager, he will obtain the best results, and this will become a normal habit if he got used to do this. From the fourth 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 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 cant depend on her work, so the management department with her head manager have decided to report her with the end of her relationship with the organization after finishing her probation period. After calculating the average productivity time percentage and the average interruptions time percentage during the fourth week for the five engineers and comparing it to the result of the first week, second week, and the third week, we had found the result that is shown in Figure 9

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

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

International Journal of Basic & Applied Sciences IJBAS Vol: 9 No: 10 This analysis shows that the average productivity time percentage for the five engineers during the fourth week is 75.14% percentage, which represents a higher percentage than this of the first week by a factor of 13.47% and lower than this of the second week by a factor of 0.53% which can be neglected and higher than this of the third week by a factor of 5.90% , on the other side, the average interruption time percentage was 24.95%, which was lower than this of the first week by a factor of 13.09%% and this of the second week by a factor of 11.44% and this of the third week by a factor of 5.77%. 3) Handling interruptions conclusion: Hence, we can say that form the beginning of the assigned period to the end of this period, the average productivity time has been increased and improved by a factor of 13.47% percentage and the average interruptions time has been decreased by a factor of 13.09% which represents a very acceptable improvement percentage for productivity. Hence, we can be assured that the first PSP principle has been achieved successfully and with a very acceptable result. B. PSP Second Principle Here, we will focus on implementing the second PSP principle, which concerns increasing individuals productivity, and product and process quality using PSP planning and measurement forms. Development and data collection processes are also included to provide additional context for understanding the results. Engineers learn to use the PSP by developing different tasks and they may use any design method or programming language in which they are fluent. Engineers have practiced different programming tasks, on which they had applied what they had learned during the PSP training sessions, to pilot test the PSP on two main similar tasks each for two projects professionally. During the implementation of the second principle, we have decided to show this principle through working on two medium sized projects of a medium size software organization following the PSP process structure shown in Figure 1. We have also dedicated three engineers of those who had been trained on how to practice PSP to work on these projects; they were E2 (developer), E3 (developer), and E4 (designer), and we have called our projects as PA, and PB for the first and second project respectively. Development time, defects, and task size are measured and recorded on provided forms. A simple plan summary form like shown in Figure 10 is used to document planned and actual results.

69

While writing the projects lines of code or designing their pages, engineers have gathered process data that are summarized in the project plan summary. With such a short feedback loop, engineers can quickly see the effect of PSP on their own performance. 1) PSP Measurement Framework: Engineers collect three basic measures: size, time, and defects. Size is measured in lines of code (LOC). In practice, engineers use a size measure appropriate to the programming language and environment they are using; for example, number of database objects, number of use cases, number of classes, etc. In order to ensure that size is measured consistently, counting and coding standards are defined and used by each engineer. Derived measures that involve size, such as productivity or defect density, use new and changed LOC, and new and changed Pages. New and changed LOC is defined as lines of code that are added or modified, where new and changed pages are those pages that are added or modified; existing LOC is not included in the measure. Time is measured as the direct time spent on each task. It does not include interrupt time. A defect is anything that detracts from the programs ability to completely and effectively meet the users needs. A defect is an objective measure that engineers can identify, describe, and count. Engineers use many other measures that are derived from these three basic measures. Both planned and actual data for all measures are gathered and recorded. Actual data are used to track and predict schedule and quality status. All data are archived to provide a personal historical repository for improving estimation accuracy and product quality. Derived measures include: Size Estimation Accuracy Effort Estimation Accuracy Productivity Defect density Process yield Failure cost of quality (COQ) Appraisal COQ Appraisal/failure COQ ratio

2) PSP Plan summary Task summary data are recorded on the Task Plan Summary form. This form provides a convenient summary of planned and actual values for program size, development time, and defects, and a summary of these same data for all similar tasks completed to date. The Task plan summary is the source for all data used in this study. Table 12 shows the four sections of the task plan summary that were used for E2, they were: Program Size, Time in Phase, Defects Injected, and Defects Removed.

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

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

Table 12: E2 Task Plan Summary Project PA

70

PSP Task Plan Summary - Project PA Engineer Task Language E2 Control Panel development C# Date Task# 14-Jun 1

Summary Minutes/LOC LOC/Hour Defects/KLOC Yield A/FR

Plan 5 12 24 41.67 0.17

Actual 4 15 19.30 54.55 0.34

To Date 4 15 19.30 54.55 0.34

Code Size (LOC) Total New & Changed Maximum Size Minimum Size

Plan 500 800 450

Actual 570

To Date 570

Time in Phase (min.) Planning Analysis Design Code Code/Design Review Compile Test Postmortem Total Task Time Maximum Time Minimum Time

Plan 312 332 258 1053 75 64 384 22 2500 4000 2250

Actual 274 183 312 1218 70 12 192 19 2280

To Date 274 183 312 1218 70 12 192 19 2280

To Date% 12.02 8.03 13.68 53.42 3.07 0.53 8.42 0.83 100.00

Defects Injected Planning Analysis Design Code Code/Design Review Compile Test Total

Plan

Actual

To Date

To Date%

To Date% Def./Hour

1 11

1 10

1 10

9.09 90.91

0.86 0.49

12

11

11

100.00

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

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

Defects Removed Planning Analysis Design Code Code/Design Review Compile Test Total 5 2 5 12 6 3 2 11 3 2 6 11 27.27 18.18 54.55 100.00 2.57 10.00 1.88 Plan Actual To Date To Date% Def./Hour

71

As shown in Table 12, the summary section holds the rate data used to make the plan. It also provides a place to record the actual rate data after task completion. The top entry in the summary section is Minutes/LOC (minutes per line of code). As shown in Table 12, E2 used his guessing as his historical data from the prior similar tasks to get the rate of 5 Minutes/LOC; he might need to use a different value if the new task seems particularly difficult and likely to take longer than average. The next entry in the summary section is LOC/Hour (lines of code per hour). The LOC/Hour is calculated from Minutes/LOC by dividing 60 by Minutes/LOC. The LOC/Hour rate is commonly used by engineers to analyze development productivity. The program or code size (LOC) section of the project plan summary form contains the estimated and actual data on the task size and likely size ranges. E2 estimated the finished size of the task he planned to develop and entered it under plan in the Total New & Changed row as shown in Table 12. Then he calculated the maximum and minimum size numbers, they are useful for judging the likely time range for a development estimate. The next section of the plan summary table is called Time in Phase because it is used for data on the phases of the software development process. E2 calculated total planned development time by multiplying the planned Minutes/LOC by the planned New & Changed LOC. Also, he multiplied the minimum and maximum sizes by the Minutes/LOC to give the minimum and maximum times respectively. The time in phase section has a row for each phase of the process. This row holds the planned and actual times for each process phase. The way to do this, E2 has allocated the total development time to the phases in proportion to the way he has spent time on previous such tasks. He calculated these times using Minutes for easy calculations. Then, he estimated from his prior knowledge the spent time for each phase including the postmortem phase, in

which, E2 completes the plan summary form with actual time, and size data from his Job Recording Log. To calculate the To Date value: for each phase, E2 should enter the sum of actual time and To Date time from the most recent previous tasks, and since there is no previous To Date time for such previous tasks, the TO Date value will be the same actual times. To calculate the To Date% value: for each phase, E2 should enter 100 times the To Date time for that phase divided by the total To Date time. For subsequent projects, however, engineers can use the data from previous tasks, like this task for example, to estimate the time for each phase of the new task or project. This is the reason for the To Date% values in the task or project plan summary form. The To Date and To Date% columns in the plan summary form provide a simple way to calculate the percent distribution of development time by process phase. The To Date column contains the total of all the time spent in each phase for all the completed tasks. The To Date% column holds the percentage distribution of the times in the To Date column. 3) Individual and Process Productivity: Here, we have provided the skills and practices that the engineer needs to improve his prediction, estimation accuracy, and productivity. Size Estimation Accuracy Accurate size estimates are a fundamental building block for realistic project plans. Training in PSP provides individual engineers with an ability to improve their skill in estimating the size of the products they produce. This ability is clearly demonstrated in the results presented here. Measure of Interest Estimated Size - Actual Size / ArgMax (Estimated Size, Actual Size)

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

International Journal of Basic & Applied Sciences IJBAS Vol: 9 No: 10 Effort Estimation Accuracy Use 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 engineers with the ability to make estimates, and to improve the estimating process, at the level of an individual engineer. This ability is clearly demonstrated in the results presented here. Measure of Interest Estimated Minutes - Actual Minutes / ArgMax (Estimated Minutes, Actual Minutes) Productivity That is, the number of lines of code designed, written, and tested, per hour spent increases between the first and last assignments. Measure of Interest Total New Changed LOCS / (Total Time Spent / 60) 4) Product and Process Productivity results and analysis Size Estimation
E2 E3 E4

72

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 & Figure 11.
Table 14:Effort Estimation Accuracy

Task1 0.09 0.18 -0.11

Task2 0.05 0.02 0.01

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 13 & Figure 10.
Table 13: Size estimation accuracy

Task1 E2 E3 E4 0.14 0.02 0.18

Task2 0.02 0.01 0.02

Figure 11: Effort Estimation Accuracy for E2, E3, and E4 during first PSP Task and the second one

Estimation Accuracy

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]
Figure 10: Size Estimation Accuracy for E2, E3, and E4 during first PSP Task and the second one

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

International Journal of Basic & Applied Sciences IJBAS Vol: 9 No: 10 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 15 & Figure 12
Table 15: Productivity

73

As shown, after analyzing productivity data for the first and second PSP assignments for the 3 engineers, their productivity increases. 5) Product and Process Quality: Here, we have provided the skills and practices that the engineer needs to understand the defects he injects. These skills have equipped him to efficiently find and fix most of his defects and it also provided the data to help prevent these defects in the future. The plan summary included a section concerning the number of defects that were injected during each phase and another section defining the number of defects that were removed during which phase. But before filling-in the plan summary sections concerning the defects, engineers had first to analyze defects. In analyzing defects, it is helpful to divide them into categories [17]. Defects are classified into 10 general types. By categorizing defects into a few types, engineer can quickly see which categories cause the most trouble and focus on their prevention and removal. That, of course, is the key to defect management. Focus on the few defect types that are most troublesome. Once these types are under control, identify the next set and work on them, and so on indefinitely. The defect types used in this paper are shown in Table16 [17]

Task1 E2 E3 E4 15.00 12.00 0.50

Task2 16.22 12.12 0.57

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

Defect Type Standard Type Number 10 20 30 40 50 60 70 80 90 100 Type Name Documentation Syntax Build, package Assignment Interface Checking Data Function System Environment comments, messages spelling, punctuation, typos, instruction formats change management, library, version control declaration, duplicate names, scope, limits procedure calls and references, I/O, user formats error messages, inadequate checks structure, content logic, pointers, loops, recursion, computation, function defects configuration, timing, memory design, compile, test, other support system problems Description

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.

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

International Journal of Basic & Applied Sciences IJBAS Vol: 9 No: 10 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.

74 Analyzes these data to see what defect types caused the most problems. Devises a way to find and correct these defects.

The defect recording log is designed to help gather defect data [18]. The log for E2 is shown in Table 17

Table 17: E2s Defect Recording Log

Defect Recording Log [E2] Project Date 18-Jun Num 1 2 3 4 Type 20 50 80 20 Injected code code design code Removed Code Review Code Review Code Review Code Review Code Review Code Review Compile Compile Fix Time 0:01 0:03 0:01 0:01 missing ; incorrectly formatted call forgot to initialize variable misspelled variable Adding an email for a female user in the newsletters list is inserted and saved as Male Admin can't obtain a search result of registered visitors with e-mail data form ; entered as : Admin cant change his old password, always Error message appears Editing shops sometimes doesnt work Description

5 PA 6 20-Jun 7 8

80

code

0:04

80 20 60

code code code

0:09 0:01 0:06

9 23-Jun 10

80 80

code code

Compile Unit Test

0:16 0:18

Editing 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 its number in the log, the date when it was found, its type according to the defect type standard, the phase in which it was injected and the phase in which it was removed, its fixing time and a brief description of the defect to later reminds him about the error that caused the defect. During the postmortem phase, E2 reviewed the defect log and counted the number of defects injected in each phase. From the Defect Recording Log in Table 17, E2 first counted defect 3 as injected in design so he entered 1 under actual in the design row of his plan summary shown in Table. The other nine defects were all injected in code, so he entered a 9 in the code row. The total is then ten injected defects. Next, he counted the number of defects removed in each phase. E2 counted three defects removed in Code Review,

Two in compile, 5 in Test so he entered a 3, 2, and 5 in these rows of the defects removed section. Again, the total is 10. After recording the number of defects injected and removed, E2 completed the To Date and To Date% columns in the same way he filled the same columns with time data. 6) Quality Measures: Defect Density: Defect density refers to the defects per new and changed KLOC found in a program [19]. Thus, if a 150 LOC program had 18 defects, the defect density would be 1000*18/150 = 120 defects/KLOC. Defect density is measured for the entire development process and for specific process phases. Since testing only removes a fraction of the defects in a product, when there are more defects that enter a test phase, there will be more remaining after the test phase is completed.

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

International Journal of Basic & Applied Sciences IJBAS Vol: 9 No: 10 Therefore, the number of defects found in a test phase is a good indication of the number that remains in the product after that test phase is completed. Measure of Interest Total Defects / Total New & Changed LOC /1000 Yield: Process yield refers to the percentage of the defects removed before the first compile and unit test[Y]. Since the PSP objective is to produce high quality programs, the suggested guideline for process yield is 70% better [19]. Measure of Interest Pre-compile defects removed / Pre-compile defects injected A/FR: The appraisal to failure ratio (A/FR) measures the quality of the engineering process, using cost-of-quality (COQ) parameters [19]. The A stands for the appraisal quality cost, or the percentage of development time spent in quality appraisal activities. In PSP, the appraisal cost is the time spent in design and code reviews, including the time spent repairing the defects found in those reviews. Measure of Interest Appraisal COQ = 100*(Code Review or Design Review) Time / Total Development Time The F in A/FR stands for the failure quality cost, which is the time spent in failure recovery and repair. The failure cost is the time spent in compile and unit test, including the time spent finding, fixing, recompiling, and retesting the defects found in compiling and testing. Measure of Interest Failure COQ = 100* (Compile Time + Test Time) / Total Development Time The A/FR measure provides a useful way to assess quality, both for individual programs and to compare the quality of the development processes used for several programs. It also indicates the degree to which the engineer attempted to find and fix defects early in the development process [19].

75

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 18& Figure 13.
Table 18 : Defect Density

Task1 E2 E3 E4 19.30 20.32 3.46

Task2 12.01 18.22 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 second PSP assignments for the 3 engineers, there is a significant increase in the defect density values. Process Yield The hypothesis to be addressed in this section is as follows: As engineers progress through the PSP training, their yield increases significantly. More specifically, the introduction of design review and code review following PSP has a significant impact on the value of engineers process yield like shown in Table 19& Figure14.
Table 19: Pre-compile Defect Yield

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:

Task1 E2 E3 E4 54.55 55.56 33.33

Task2 71.43 62.50 60.00

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

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

76

Figure 14: Pre-compile Defect Yield for E2, E2, and E4 during first PSP Task and the second one

Figure 15: A/FR for E2, E2, and E4 during first PSP Task and the second one.

As shown, after analyzing defects removed and injected before the first compile for the first and second PSP assignments for the 3 engineers, there is a significant increase in the process Yield values. A/FR The hypothesis to be addressed in this section is as follows: As engineers progress through the PSP training, their A/FR value increases significantly. More specifically, the A/FR values below 1 generally indicate that many defects will be found in test, while values above 1 generally indicate that few if any defects will be found in test, like shown in Table 20& Figure 15.
Table 20: A/FR

As shown, after analyzing the appraisal and failure cost of quality for the first and second PSP assignments for the 3 engineers, there is a significant increase in the process A/FR values. 8) PSP approach summary: The results from PSP training were impressive. These results are summarized in Table 21 and are shown in Figure 16. The first column describes the measure, the second column shows its value at the start of PSP training (First 3 assignments for E2, E3, and E4), and the third column shows its value at the end of PSP training (Average for the two PSP assignments for the three engineers) like shown in Table 21 & Figure 16
Table 21: Summarized results

Measure Size Estimation Accuracy Effort Estimation Accuracy Productivity

At the start of training 0.11

At the end of training 0.02

Task1 E2 E3 E4 0.34 0.40 2.65

Task2 0.68 0.57 2.14

0.05 9.17 14.36

0.03 9.64 10.65

Defect Density

Process Yield

47.81

64.64

Process Quality cost ratio A/FR

1.13

1.13

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

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

77

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

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

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

International Journal of Basic & Applied Sciences IJBAS Vol: 9 No: 10 Because the PSP was developed to improve individual performance through the gradual introduction of new practices, the study took a similar approach, examining the change in individual performance as these practices were introduced. Our analyses grouped individual data and then examined the change in individual performance. Using this approach we found that the improvements in four dimensions: size estimation accuracy, effort estimation accuracy, product quality, and process quality, were statistically significant. No statistically significant change in productivity was found, and so we can state that the improvements observed in the other performance dimensions were achieved without any loss of productivity. In conclusion, the analyses stated here substantiate that trend in personal performance observed during PSP training are significant, and that the observed improvements represent real change in individual performance, not a change in the average performance of the group. Furthermore, we are confident that the observed improvements are due to the PSP and can be generalized. VII. PSP STATUS AND FUTURE TRENDS REFERENCES

78

[1] Ferguson, P.; Leman, G; Perini, P; Renner, S.; & Seshagiri, G. Software Process Improvement Works! (CMU/SEI-99-TR-027, ADA371804). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 1999. <http://www.sei.cmu.edu/publications/documents/99.reports/99tr027/99tr027 abstract.html>.
[2] McAndrews, D. The Team Software Process SM: An Overview and Preliminary Results of Using Disciplined Practices (CMU/SEI- 2000-TR-015, ADA387260) Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2000. <http://www.sei.cmu.edu/publications/documents/00.reports/00tr015.html>. [3] Software Engineering Institute. Capability Maturity Model for Software (CMM), Version1.1, Carnegie Mellon University, 1993. [4] Software Engineering Institute. Capability Maturity Model Integration (CMMI), Version 1.1, Carnegie Mellon University, 2002. [5] SPICE Project. Software Process Assessment Part 2: A model for process management, Version 1.0, 1998. [6] P. Kuvaja, J. Simila, L. Krzanik, A. Bicego, G. Koch, S. Saukkonen. Software Process Assessment and Improvement: The BOOTSTRAP Approach. Blackwell Publishers, 1994. [7] B. Curtis, M. I. Kellner, and J. Over. Process Modeling. Communications of the ACM, vol. 35, pp. 75-90, 1992. [8] H. Krasner, J. Tirrel, A. Linehan, P. Arnold, and W.H. Ett. Lessons learned from a software process modeling system. Communications of ACM, vol. 35, n.9, pp. 91-100, Sept. 1992. Deming, W. E. Out of the Crisis. MIT Center for Advanced Engineering Study, Cambridge, MA, 1982. [9] Juran, J. and Gryna, F. Juran's Quality Control Handbook, Fourth Edition. New York: McGraw- Hill Book Company, 1988. [10] Fagan, M. Design and Code Inspections to Reduce Errors in Program Development. IBM Systems Journal, 15, 3 (1976) [11] Fagan, M. Advances in Software Inspections. IEEE Transactions on Software Engineering, SE-12, 7, (July 1986) [12] Humphrey, W. Managing the Software Process. Reading, MA: AddisonWesley, 1989. [13] Paulk, M., et al. The Capability Maturity Model: Guidelines for Improving the Software Process. Reading, MA: Addison Wesley, 1995. [14] Herbsleb, J., Zubrow, D., Goldenson, D., Hayes, W., and Paulk, M. Software Quality and the Capability Maturity Model, Communications of the ACM, 40, 6 (June 1997): 30- 40. [15] Humphrey, W. a Self-Improvement Process for Software Engineers Reading, MA: Addison- Wesle, (March 2005). [16] PSP Training for Everyone Wall, Dan, Proceedings of the TSP Symposium, September 17, 2007, http://www.sei.cmu.edu/tsp/proceedings07.html [17] Seshagiri, G. Making Quality Happen: The Managers Role, AIS Case Study, Crosstalk (June 2000). [18] Humphrey, Watts S. Self-Improvement Process for Software Engineers, Reading, MA: Addison Wesley, March 2005, ISBN: 0321305493

While superior technical work will continue to be required, the performance of each individual engineer will be recognized as important. Quality systems require quality parts, and unless every engineer strives to produce quality work, the team cannot do so. Quality management will be an integral part of software engineering training. Engineers will have to learn how to measure the quality of their work and how to use these measures to produce essentially defect free work. The PSP is designed to provide the disciplined practices software professionals will need in the future. While some industrial organizations are introducing these methods, we recommend a broader introduction of these disciplined methods to be started here in Egypt universities. Academic introduction of the PSP is currently supported with courses at both introductory and advanced levels. Several universities in the U.S., Europe, and Australia now offer the PSP, and several institutions in Asia are considering its introduction. While the PSP is relatively new, the early results are promising. Both industrial use and academic adoption are increasing. Assuming that these trends continue, we recommend that the future should see a closer integration of the (Personal Software Process) PSP, (Team Software Process) TSP, and (Capability Maturity Model) CMM methods and a closer coupling of the PSP academic courses with the broader computer science and software engineering curricula.

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