Application and Evaluation of the Personal Software Process

Transcription

1 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 Abstract Software organizations differ from other manufacturing organizations, since these software organizations depend mainly on individuals and team works rather than machines or raw materials. Enhancing individuals and team works capabilities is the key solution to improve quality and productivity levels. Hence, Individual engineers need a quality improvement technique to improve their performance by bringing discipline to the way they develop software and manage their work to produce quality products within budget and on schedule. This paper will propose a case study showing the application and evaluation of the Personal Software Process (PSP), which recommends applying some skills and methods that concerns the individual engineer her/himself, like understating the meaning of work quality, and how to estimate time and effort in order to be able to make the right project plans which contain some estimated data that are close to the actual data. Hence, in our study, PSP will focus on two principles, improving individuals productivity, and products and process quality. Keywords PSP; Personal software process, Productivity, Productivity time, Interruption time, Quality, size estimation accuracy, effort estimation accuracy, process yield, defect density, COQ; Cost of Quality, LOC; Lines of Code I. INTRODUCTION The success of organizations that produce 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 small projects during which the engineer collects measurements on defect rates, defect types, and other indicators of engineer productivity and effectiveness in order to better understand and appreciate their strength and weaknesses as an engineer. This paper includes detailed presentations of the analyses conducted on size and effort estimation accuracy, process yield, defect density, and productivity. The paper also includes other observations uncovered during the statistical analysis and study conclusions which contain experiences of and benefits realized by first-time PSP individuals. We hope that by walking through this first-time individuals journey of using the PSP, we illustrate how the PSP creates an environment where skilled engineers can apply disciplined methods working on a cohesive and dedicated team. II. RELATED WORK Current research on software development processes intends to define the process elements that constitute good practices, leaving implementation and enactment of the process to organizations. Some of these approaches include CMM [3], CMMI [4], SPICE [5] and Bootstrap [6]. However, these models are very descriptive in the sense that they explain essential attributes that would be expected to characterize an organization at a particular maturity level, but they specify neither how to improve nor the specific means to get into a particular maturity level. But, as discussed by the research community, also important is the way processes evolve with the changing needs of the development organization. In addition, projects must adopt the process with some level of detail for the organization. Process modeling techniques are useful in defining the process, especially in the upper levels of maturity models like CMMI. Curtis, Kellner and Over discussed some approaches using process modeling to support process improvement, software project management and Process-centered software engineering environments (PCSEEs) [7].

2 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 CMM s 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. 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. 56 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 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)

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

4 A. PSP first principle 1) Handling interruptions: In the PSP, engineers use the time recording log to measure the time spent in each task. In this log, they note the time they started working on a task, the time when they stopped the task, and any interruption time. For example, an interruption would be a phone call, a brief break, or any other type of interruptions. By tracking time precisely, engineers track the effort actually spent on project tasks. Since interruption time is essentially random, ignoring these times would add a large random error into the time data and reduce estimating accuracy. The form used for recording time is called Time Recording Log. The top of the form is called the header and it has spaces for engineer s name, department, and the date of header information completion. The columns in the body of the form are for recording the time data. Each time period is entered on one line of the form as follows: Date: the date of doing some activity, like programming or reading. Start: The start time of the activity. Stop: The stop time of the activity. Interruption Time: Any time lost due to interruptions Delta Time: The time spent on main activities, between the start and stop times, without interruptions Activity: A descriptive name for the task. 2) Handling interruptions implementation and obtained results: Here, we began working with 5 engineers, we refer to them as E1 a project manager, two developers E2 and E3, and two designers E4 and E5 ; where E5 is an under training designer and this was a suitable opportunity to follow-up, analyze and evaluate her performance in general, in addition to evaluating her work productivity level. Every engineer has been exposed to fill-in this log with all activities of his working day over 4 weeks with five days per every week and working hours are 9 hours per day, then they began recording their start and stop time including their interruptions. We had to gather data of the first week firstly, and analyze them to obtain results about what is currently done, main activities for each individual, and main interruption that affect their work and waste time. After data gathering of the first week, we will have to find the percentage of time spent doing the main activities for every working day and the percentage of interruptions during that day, to show engineers their productivity percentages and what interruptions that affect their work and what are their percentages too, in order to realize what really affects their work and waste their time and also try to eliminate these interruptions as soon as possible. Here, we began to present a brief introduction or training to the individuals about this approach, and we delivered the time recording log to every one of them to begin filling-in every action happens during the working day in a timely manner. Before starting filling-in the time recording log, we have arranged for a meeting including the five engineers to determine their main working activities and the main interruptions that affects their work to be included in their logs. They determined their common working activities to be like, s 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 activity name for main working activities and Interruption name for interruptions, for example Programming and W _Browsing, represent programming and browsing activities are for favor of work, in contrary with Browsing and 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 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. 58 Table 1: E2 s Time Recording Log Time Recording Log Engineer Name: E2 Department: Project Development Date: 9-May

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

6 60 17:07 17:24 0:17 Prayer 17:25 17:42 0:17 Browsing 17:43 18:19 0:36 Lunch Break 12-May 13-May 18:20 18:42 0:22 Talking Totals 2:36 6:21 9:08 9:15 0:07 Breakfast 9:16 9:18 0:02 9:18 9:28 0:10 Talking 9:29 10:08 0:39 Reading 10:09 12:14 2:05 Programming 12:15 12:31 0:16 Phone 12:32 12:53 0:21 Other Interruptions 12:54 13:38 0:44 Browsing 13:39 14:03 0:24 Prayer 14:05 16:16 2:11 Programming 16:17 17:01 0:44 Follow-up Juniors 17:02 17:42 0:40 Lunch Break 17:43 18:03 0:20 Prayer 18:04 18:20 0:16 Talking Totals 2:18 6:41 9:08 9:26 0:18 Breakfast 9:27 9:50 0:23 9:51 10:57 1:06 Follow-up Juniors 10:58 12:58 2:00 Programming 12:59 13:22 0:23 Talking 13:23 13:33 0:10 Prayer 13:34 14:00 0:26 Phone 14:01 14:19 0:18 Browsing 14:20 14:38 0:18 Talking 14:39 15:21 0:42 Browsing 15:22 15:57 0:35 Programming 15:59 16:05 0:06 Prayer 16:07 18:22 2:15 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 2 which categorizes the main working activities that the engineers have frequently practiced during their first week and we have recorded them as shown in Table 2, 3, 4, 5, and 6 respectively.

7 Week1 Activity Date E1 Assigning Task Browsing Table 2: E1 s Weekly Activity Summary for the first week Customer Service Followup Seniors work Managing Projects Tasks Reading Phone Talking 9-Jun 0:19 0:35 3:02 0:31 1:03 0:16 0:22 6:08 10-Jun 0:05 0:24 1:57 0:16 1:03 0:43 0:24 4:52 11-Jun 0:20 0:33 0:53 0:26 0:15 1:45 0:14 0:17 0:14 4:57 12-Jun 0:14 0:56 1:28 0:15 2:11 0:59 0:22 0:18 6:43 13-Jun 0:48 0:16 0:17 0:16 0:24 0:21 2:22 Totals 0:58 3:16 7:36 1:45 4:48 1:45 1:13 2:02 1:39 25:02 Productivity Time Percentage 2.15% 7.26% 16.89% 3.89% 10.67% 3.89% 2.70% 4.52% 3.67% 55.63% Total Time 61 Week1 E2 Table 3: E2 s Weekly Activity Summary for the first week Activity Programming Reading Follow-up Juniors Browsing Talking Total Time Date 9-Jun 5:38 0:32 0:09 0:06 6:25 10-Jun 4:59 0:31 0:51 0:09 0:13 0:23 7:06 11-Jun 4:38 0:11 0:27 0:39 0:04 0:22 6:21 12-Jun 4:16 0:39 0:44 0:44 0:02 0:16 6:41 13-Jun 4:50 1:06 0:42 0:23 0:18 7:19 Totals 24:21:00 1:21:00 3:40:00 2:14:00 0:51:00 1:25:00 33:52:00 Productivity Time Percentage Week1 Activity 54.11% 3.00% 8.15% 4.96% 1.89% 3.15% 75.26% E3 Programming Table 4: E3 s Weekly Activity Summary for the first week Reading Follow-up Juniors Browsing 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%

8 62 Table 5: E4 s Weekly Activity Summary for the first week Week1 Activity E4 Designing Reading Follow-up Juniors Browsing Talking Total Time Date 9-Jun 4:51 0:11 0:32 0:05 0:10 5:49 10-Jun 1:00 1:02 2:38 1:33 0:08 0:14 6:35 11-Jun 3:03 0:14 0:19 0:03 0:05 3:44 12-Jun 3:51 0:16 0:21 0:49 0:12 0:23 5:52 13-Jun 3:44 0:18 0:57 1:52 0:27 0:28 7:46 Totals 16:29:00 1:36:00 4:21:00 5:05:00 0:55:00 1:20:00 29:46:0 0 Productivity Time Percentage 36.63% 3.56% 9.67% 11.30% 2.04% 2.96% 66.15% Week1 Table 6: E5 s Weekly Activity Summary for the first week E5 Activity Designing Reading Browsing 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. 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. Week 1 E1 Table 7: E1 s Weekly work interruptions for the first week Interruption Browsing Breakfast Other Interruptions Phone Prayer 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

9 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% 63 Week 1 Interruption Date E2 Breakfast Browsing Table 8: E2 s Weekly work interruptions for the first week Other Interruptions Lunch Break Phone Prayer Talking Total Time 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% Week 1 Interruption Date E3 Breakfast Browsing Table 9: E3 s Weekly work interruptions for the first week Other Interruptions Lunch Break Phone Prayer Talking Total Time 9-Jun 0:04 2:02 0:11 0:47 0:05 3:09 10-Jun 0:12 0:41 0:33 0:16 0:43 0:03 2:28 11-Jun 0:04 1:05 0:49 0:31 0:04 0:44 0:09 3:26 12-Jun 0:16 0:16 0:36 0:07 0:42 0:21 2:18 13-Jun 0:19 1:10 0:12 0:41 0:29 0:18 0:17 3:26 Totals 0:55:00 5:14:00 1:01:00 2:32:00 0:56:00 3:14:00 0:55:00 14:47:00 Productivity Time Percentage 2.04% 11.63% 2.26% 5.63% 2.07% 7.19% 2.04% 32.85% Week 1 E4 Table 10: E4 s Weekly work interruptions for the first week Interruption Breakfast Browsing Other Interruptions Lunch Break Phone Prayer 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%

10 Table 11: E5 s Weekly work interruptions for the first week 64 Week 1 E5 Interruption Breakfast Browsing Lunch Break Phone Prayer 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 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.

11 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 week s 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

12 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 couldn t get over their interruptions time. Increasing working hours while leaving interruption times constant, is not the aim of or a solution to a working organization which aims to achieve its working cycle in a definite time, so after the analysis of the second week s results, we have arranged for a meeting with the attendance of the five engineers and the management representative to show them the second week results and to discuss some solutions or suggestions in order to overcome the interruptions problem or at least to eliminate it. During this meeting, every engineer discussed his main interruptions which cause waste of time and how he can overcome them, of course every individual has his own interruptions, but also there are common interruptions that can be eliminated. Engineers thought, suggested and got committed to a policy for them and for the organization which focuses on eliminating interruptions and improving productivity, and consequently improving product quality. The policy that the engineers have stated includes the following: The period of breakfast will be 15 minute maximum in the morning. Lunch breaks will be 30 minutes maximum per day. Phone calls will be eliminated to be messages or if it is very urgent, then it will be eliminated to 20 minutes maximum per day. Prayer will be 30 minutes maximum per day for both prayers during the working day. Talking out of work scope, will be at breaks, if urgent then 10 minutes maximum. Browsing for entertainment is limited to 10 minutes maximum per day. Concerning the other interruptions like printing a paper, or sudden meeting with a client etc, their time will be recorded as a normal interruption time, but it will be neglected because as possible as we can, we will try to resume this amount of time after the original working time of the day. Browsing for work will be for an hour all over the working day. Following-up juniors will be eliminated to be one hour distributed into two periods of the day, whether before or after prayer breaks. In the third week, engineers have resumed their work exactly as they have done in the first and the second week, but focusing on their commitment to their suggested policy. The work and the commitment lasted all over the third week, and after the end of this week, we resumed the work that we have done since the last two weeks. After gathering the time recording logs, and making our analysis, we obtained these results that are shown in figures 6 for E1, E2, E3, E4, and E5.

13 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

14 this of the second week by a factor of 7.57% but this percentage will be neglected since it was due to staying working at work over the original working hours during the second week, but the result of the third week is acceptable since it was reached within the range of the original working hours of the day, on the other side, the average interruption time percentage was 30.72%, which was lower than this of the first week by a factor of 7.32% and this of the second week by a factor of 5.67%. Applying this approach lasted for the fourth week as it lasted for the previous three weeks, and after the analysis of its data, we have found the results shown in figures 8 for E1, E2, E3, E4, and E5. 68 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 week s 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 can t depend on her work, so the management department with her head manager have decided to report her with the end of her relationship with the organization after finishing her probation period. After calculating the average productivity time percentage and the average interruptions time percentage during the fourth week for the five engineers and comparing it to the result of the first week, second week, and the third week, we had found the result that is shown in Figure 9 Figure 9: Average Productivity Time Percentage VS. Average Interruption Time Percentage in Week1, Week2, Week3, and Week4 for E1, E2, E3, E4, and E5

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

16 Table 12: E2 Task Plan Summary Project PA PSP Task Plan Summary - Project PA Engineer E2 Date 14-Jun Task Control Panel development Task# 1 Language C# 70 Summary Plan Actual To Date Minutes/LOC LOC/Hour Defects/KLOC Yield A/FR Code Size (LOC) Plan Actual To Date Total New & Changed Maximum Size 800 Minimum Size 450 Time in Phase (min.) Plan Actual To Date To Date% Planning Analysis Design Code Code/Design Review Compile Test Postmortem Total Task Time Maximum Time 4000 Minimum Time 2250 Defects Injected Plan Actual To Date To Date% To Date% Def./Hour Planning Analysis Design Code Code/Design Review Compile Test Total

17 71 Defects Removed Plan Actual To Date To Date% Def./Hour Planning Analysis Design Code Code/Design Review Compile Test Total 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)

18 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 engineer s workload remains a challenge. The PSP training provides engineers with the ability to make estimates, and to improve the estimating process, at the level of an individual engineer. This ability is clearly demonstrated in the results presented here. Measure of Interest Estimated Minutes - Actual Minutes / ArgMax (Estimated Minutes, Actual Minutes) Productivity That is, the number of lines of code designed, written, and tested, per hour spent increases between the first and last assignments. Measure of Interest Total New Changed LOCS / (Total Time Spent / 60) 4) Product and Process Productivity results and analysis Size Estimation The hypothesis tested in this section of the study is as follows: As engineers progress through the PSP training, their size estimates gradually grow closer to the actual size of the program at the end [19]. With the introduction of historical size estimation data that every engineer has used before, and accumulating these values To Date, engineers can progress through the PSP training and can predict closer values to their actual size estimation values like shown in Table 13 & Figure 10. 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 Task2 E E E Table 13: Size estimation accuracy Task1 Task2 E E E Figure 11: Effort Estimation Accuracy for E2, E3, and E4 during first PSP Task and the second one Estimation Accuracy Figure 10: Size Estimation Accuracy for E2, E3, and E4 during first PSP Task and the second one As shown, after analyzing development time data for the first and second PSP assignments for the 3 engineers, their effort estimates grow closer to the actual effort expanded for the entire life cycle of the task. Productivity The hypothesis to be tested in this section is: As engineers progress through the PSP training, their productivity increases [19]

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 15 & Figure 12 Table 15: Productivity Task1 Task2 E E E 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] 73 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 Type Name Description 10 Documentation comments, messages 20 Syntax spelling, punctuation, typos, instruction formats 30 Build, package change management, library, version control 40 Assignment declaration, duplicate names, scope, limits 50 Interface procedure calls and references, I/O, user formats 60 Checking error messages, inadequate checks 70 Data structure, content 80 Function logic, pointers, loops, recursion, computation, function defects 90 System configuration, timing, memory 100 Environment design, compile, test, other support system problems The first step in managing defects is to understand them. To do that, every engineer must gather defect data. Then he can understand these mistakes and figure out how to avoid them.

20 To gather data on defects in the program or the task, every engineer should do the following: Keep a record of every defect he finds in his program or task. Records enough information on each defect so, he can later understand it. Analyzes these data to see what defect types caused the most problems. Devises a way to find and correct these defects. The defect recording log is designed to help gather defect data [18]. The log for E2 is shown in Table Table 17: E2 s Defect Recording Log Defect Recording Log [E2] Project Date Num Type Injected Removed Fix Time Description 18-Jun 1 20 code 2 50 code 3 80 design 4 20 code Code Review Code Review Code Review Code Review 0:01 missing ; 0:03 incorrectly formatted call 0:01 forgot to initialize variable 0:01 misspelled variable PA 5 80 code 6 80 code Code Review Code Review 20-Jun 7 20 code Compile 0:01 ; entered as : 0:04 0:09 Adding an 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 data form 8 60 code Compile 0: code Compile 0:16 23-Jun code Unit Test 0:18 Admin can t change his old password, always Error message appears Editing shops doesn t work sometimes Editing events data, then saving the edited data doesn t work properly When E2 started to develop his task, he prepared this log, and when he first encountered a defect, he entered its number in the log, the date when it was found, its type according to the defect type standard, the phase in which it was injected and the phase in which it was removed, its fixing time and a brief description of the defect to later reminds him about the error that caused the defect. During the postmortem phase, E2 reviewed the defect log and counted the number of defects injected in each phase. From the Defect Recording Log in Table 17, E2 first counted defect 3 as injected in design so he entered 1 under actual in the design row of his plan summary shown in Table. The other nine defects were all injected in code, so he entered a 9 in the code row. The total is then ten injected defects. Next, he counted the number of defects removed in each phase. E2 counted three defects removed in Code Review, Two in compile, 5 in Test so he entered a 3, 2, and 5 in these rows of the defects removed section. Again, the total is 10. After recording the number of defects injected and removed, E2 completed the To Date and To Date% columns in the same way he filled the same columns with time data. 6) Quality Measures: Defect Density: Defect density refers to the defects per new and changed KLOC found in a program [19]. Thus, if a 150 LOC program had 18 defects, the defect 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.

21 Therefore, the number of defects found in a test phase is a good indication of the number that remains in the product after that test phase is completed. Measure of Interest Total Defects / Total New & Changed LOC /1000 Yield: Process yield refers to the percentage of the defects removed before the first compile and unit test[y]. Since the PSP objective is to produce high quality programs, the suggested guideline for process yield is 70% better [19]. Measure of Interest Pre-compile defects removed / Pre-compile defects injected A/FR: The appraisal to failure ratio (A/FR) measures the quality of the engineering process, using cost-of-quality (COQ) parameters [19]. The A stands for the appraisal quality cost, or the percentage of development time spent in quality appraisal activities. In PSP, the appraisal cost is the time spent in design and code reviews, including the time spent repairing the defects found in those reviews. Measure of Interest Appraisal COQ = 100*(Code Review or Design Review) Time / Total Development Time The F in A/FR stands for the failure quality cost, which is the time spent in failure recovery and repair. The failure cost is the time spent in compile and unit test, including the time spent finding, fixing, recompiling, and retesting the defects found in compiling and testing. Measure of Interest Failure COQ = 100* (Compile Time + Test Time) / Total Development Time The A/FR measure provides a useful way to assess quality, both for individual programs and to compare the quality of the development processes used for several programs. It also indicates the degree to which the engineer attempted to find and fix defects early in the development process [19]. Measure of Interest A/F Ratio = Appraisal COQ (A) / Failure COQ (F) 7) Quality results and analysis: Defect Density The hypotheses to be investigated in this section are as follows: As engineers progress through PSP training, the number of defects injected and therefore removed per thousand lines of code (KLOC) decreases [19] With the introduction of design and code reviews in PSP, the defect densities of programs entering the compile and test phases decrease significantly like shown in Table 18& Figure 13. Table 18 : Defect Density Task1 Task2 E E E 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 Task1 Task2 E E E

22 76 Figure 14: Pre-compile Defect Yield for E2, E2, and E4 during first PSP Task and the second one As shown, after analyzing defects removed and injected before the first compile for the first and second 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 Task1 Task2 E E E Figure 15: A/FR for E2, E2, and E4 during first PSP Task and the second one. As shown, after analyzing the appraisal and failure cost 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 At the start of training At the end of training Productivity Defect Density Process Yield Process Quality cost ratio A/FR

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