Personal Software Process)

 
 
Personal Software Process (PSP)A self-continuous improvement process that can be used to control, manage, and improve the way individuals work. It is a structured framework that includes software development forms, guides, and procedures. PSP is relatively independent of specific technologies (programming languages, tools, or design methods), and its principles can be applied to almost any software engineering task. PSP can describe the principles of individual software processes, help software engineers make accurate plans, determine the steps that software engineers should take to improve product quality, and establish benchmarks for measuring the improvement of individual software processes; determine the impact of process changes on the software engineer's capabilities.

 

 

With the popularization of software engineering knowledge, software engineers know that to develop high-quality software, the process of software production must be improved. At present, it is recognized that the Software Capability Maturity Model SW-CMM developed by CMU/SEI is the best software process at present, and CMM has become the de facto industrial standard of software process. However, although CMM provides a powerful software process improvement framework, it only tells us "what to do", rather than "How to do it ", no specific knowledge or skills are provided to implement key process domains. To compensate for this deficiency, Humphrey presided over the development of the personal software process (PSP ).

 

12 of the 18 key process domains in CMMS 70% are related to PSP. According to statistics, of the software project development cost depends on the individual skills, experience, and work habits of software developers. Therefore, if a software developer of an organization can receive PSP training, the upgrade of the Software Capability Maturity of the Organization is a powerful guarantee. CMM focuses on the macro management of software processes in software enterprises. for software development enterprises, PSP focuses on the micro-optimization of software processes in enterprises and for software developers. They support and complement each other.

 

According to PSP procedures, the steps to improve the software process first need to clarify the quality objectives, that is, the requirements that the software will meet in terms of functionality and performance and the potential needs of users. The next step is to measure the product quality. If you have a goal, the goal is only a matter of principle and is not easy for actual operations and judgment. Therefore, you must decompose and measure the target, enables software quality to be "measured ". Then, you can understand the current process, locate the problem, and adjust the process. Finally, apply the adjusted process, measure the practical results, compare the results with the target, identify the gaps, analyze the causes, and continuously improve the software process.

 

Just as CMM provides a tiered evolutionary framework for the capabilities of software enterprises, PSP provides a tiered evolutionary framework for individual capabilities to introduce the concept of a process in a step-by-step manner, each level contains all the elements in the lower level and adds new elements. This evolutionary framework is a good way to learn the basic concepts of the PSP process. It gives software personnel measurement and analysis tools so that they can clearly recognize their own performance and potential, this improves your skills and skills.

 

 

I. Individual measurement process psp0 and psp0.1

Psp0 aims to establish an individual process baseline. Through this step, you can learn to use various forms of PSP to collect data about the process. At this time, the current process of the software development unit is executed, it usually includes three phases: planning, development (including design, encoding, compilation and testing), and post-processing, and necessary questions, such as measuring the software development time, according to the selected defect type standards, the number of defects introduced by the measurement and the number of excluded defects, etc., used as a benchmark for measuring progress in the PSP process.

 

Psp0.1 adds three key process domains: coding standard, program scale measurement, and process improvement suggestions, the Process Improvement Suggestions table is used to record problems in the process, measures to solve the problems, and methods to improve the process at any time to improve the quality awareness and Process awareness of software developers.

 

It should be emphasized that in the psp0 stage, we must understand and learn to use unqualified technologies for planning and measurement. It is not easy to design a good table. You need to accumulate experience in practice to accurately meet the expected needs. The most important thing is to maintain data consistency, usefulness, and simplicity.

 

 

　Ii. Individual Planning Process psp1 and psp1.1

Psp1 focuses on individual plans. It introduces the estimation-based planning method probe (proxy based estimating) and uses its own historical data to predict the size of new programs and the required development time, the linear regression method is used to calculate the estimation parameters and determine the confidence interval to evaluate the prediction credibility. Psp1.1 adds planning for the task and progress.

 

In the psp1 stage, you should learn to prepare a project development plan, which is not only important for undertaking large-scale software development, but also essential for developing small software. This is because only by objectively evaluating your abilities can you make more accurate plans and accept and complete the tasks entrusted by the customer (customer) in a realistic manner.

 

 

　Iii. Individual Quality Management Process psp2 and psp2.1

Psp2 focuses on individual quality management. It establishes a detection table based on program defects and carries out design review and code review based on the detection table (sometimes referred to as "code lookup") to detect defects as soon as possible, minimize the cost of fixing defects. With the accumulation of personal experience and technology, you should also learn how to improve the test table to meet your requirements. Psp2.1 discusses the design process and design template, introduces the design method, and provides the design template, but PSP does not emphasize the selection of design methods, but emphasizes the design completeness criteria and design verification technology.

 

An important goal of PSP implementation is to learn to deal with program defects caused by people's negligence in the early stage of software development. People expect high-quality software, but only high-quality software developers can develop high-quality software by following the appropriate software process. Therefore, psp2 introduces and emphasizes the design review and code review technologies. A qualified software developer must master these two basic technologies.

 

 

　4. Individual cycle process psp3

The goal of psp3 is to extend the production efficiency and quality that individual small programs can achieve to large programs. The method is to adopt a spiral process, that is, iterative incremental development method, first, the large program is divided into small modules, and then each module is developed according to the process described in psp2.1. Finally, these modules are gradually integrated into a complete software product.

 

To develop a large software system using psp3, you must adopt an incremental development method and require high quality for each increment. In this case, the regression testing method can be used in a new development cycle to check whether the newly added increment meets the requirements. Therefore, strict design review and code review are required in psp2, and efforts are made to follow the design termination guidelines in psp2.1.

 

From the brief description of the individual software process framework, we can clearly see that the most basic problems in any software development process are how to make good project planning and how to ensure product quality.

 

PSP can help software engineers to apply process principles on their own. With some measurement and analysis tools provided by PSP, they can understand their skills and control and manage their work methods, make your daily work evaluation, planning and prediction more accurate and effective, and then improve your work performance and improve your work quality and output, actively and effectively participate in software engineering process improvement within the organization promoted by senior management and process personnel.

 

PSP software engineering procedures provide software engineers with a structured framework and a required methodology for developing personal skills. In the software industry, if developers do not pass PSP training, they can only rely on the development to gradually master these skills and methods through practice. This is not only a long cycle, but also a huge cost, and there are growing risks. There are many training methods, including going to a specialized school for further study, self-study, and participation in training courses.

 

 

　　5. Personal Software Process PSP Process Improvement

PSP is a process that requires gradual improvement.

 

When Watts S. Humphrey Performs military service, he must learn to fire machine guns. When I started training, I used a shotgun to beat the pigeon. Watts scored very poorly, and the training effort was still not improved. After observing Watts for a while, the instructor suggested that he use his left hand to take a shot. As a person who is used to his right hand, he is not used to Watts. However, after several times of practice, Watts's performance is almost always close to excellent.

 

This example illustrates several problems. First, we need to diagnose a problem through measurement. By understanding how Watts has hit a few pigeons and missed the target, it is easy to see that some adjustments must be made to Watts. Then, we must objectively analyze the measurement data. By observing Watts shooting, instructors can analyze the Watts shooting process-loading, positioning, tracking, and aiming, and finally shooting. The instructor aims to find out which steps of Watts have problems and find the problem. Therefore, we recommend that you use the left-hand shooting method.

 

Last, it is also the most important thing, that is, its own changes. Process improvement is very difficult, because people often do not want to try new things. Their traditional habits seem so natural that they do not believe in the help of changes. Watts always uses its right hand and never imagined what it would look like. However, since Watts adopted the instructor's suggestion, his score has improved.

 

Defining a measurement method is not easy, but it is always possible. First, define the measurement method. After the measurement method is defined, data must be collected and analyzed. If you need to make some improvements, we need to analyze the work process to see where improvements are needed. Finally, we must make improvements to achieve real improvements.

 

If Watts does not improve the shooting process, its scores won't change in a few years and won't become a good gunman. There is no improvement in measurement alone, and no improvement in effort alone. To a large extent, the way of work determines the result. If you still work in the old way, the results will look the same.

 

The improvement method is the same as that of Watts learning and shooting. They are not complex, as shown in 1:

 

　　

　　Vi. Time Management for PSP in individual software processes

 

　1. logical principles of time management

People may arrange the week as they did last week. Of course, there are many exceptions with different jobs.

 

In order to develop a practical plan, the time used must be tracked. If you ask how the last week was used, most people think that it is easy to get how much time each job took, but when you see the actual data, you may be surprised: the time spent on programming is much less than the estimated time, and the time spent on recreation is much more than expected. The time spent on doing things is especially fast, and the time spent seems to be very small, A headache seems to take much more time than it actually takes. To find out where time is used, you must track the time and keep an accurate record.

 

To check the accuracy of time estimates and plans, you must document and compare them with the actual situation in the future. Planning is a kind of skill. The first step in learning to make a good plan is to first make a plan and then write it down to compare it with the actual data in the future.

 

In order to develop a more accurate plan, you need to know which errors exist in the previous plan and where improvements can be made. Record the time spent when performing work as planned. By comparing documented plans and actual results, you can find out the errors in the plan and how to improve the planning process. The key to making an accurate plan is to stick to the plan and compare each plan with the actual results. Then we will know how to make a better plan.

 

In order to manage the time, first make a time allocation plan and then follow the plan. It is easy to prepare a plan, but it is difficult to implement it. In the beginning, it may be difficult to work according to the plan. You may have many excuses. The most common thing is that the plan is not well prepared. But only by following the plan can you know its advantages and disadvantages.

 

There are three benefits to working as planned: first, understanding the problems in the Plan helps to better plan the next project. Second, complete the work according to the good plan. This does not seem important, but in fact many errors in software engineering are caused by poor consideration, carelessness, or inattention to small details. Working in a good plan is the best way to avoid these errors. Another more subtle benefit is that it is actually changing the way you work. With a plan, you don't have to waste time thinking about what to do next, it helps you focus on your tasks with little distraction, improving your work efficiency.

 

　2. Understand the time usage
Classify main activities. When you start to allocate time, you will find that most of the time is spent on a relatively small number of activities.

 

Record the time spent on each major activity. A strong self-discipline is required to keep records of time. To make a precise record, you must record the start time and end time of each major task. Unless you know how much time you actually spent, it is impossible to manage the time used.

 

Use the standard method to record the time. Standard Time logs must be used. Because the amount of time data to be collected increases rapidly, if you do not carefully record and store the data, they are likely to be lost or become chaotic, which is not conducive to searching or interpreting them. If you do not plan to sort and summarize the data properly, you do not have to collect the data.

 

 

Measured in minutes. A project generally takes less than one hour to complete tasks. Therefore, measuring the work time on an hourly basis cannot provide detailed data required for planning and managing the work, however, it is much easier to track data in minutes. Once time tracking is determined, using the minute as the measurement unit is more appropriate than using the hour.

 

Processing interruption time. When Table 2.1 is used for tracking time, a common problem is interruption. The number of calls, chats, occasional troubles, and necessary breaks is surprising. The interruption time is not a valid working time, and the variation is very large. If you do not measure it, a random number is actually added to the time record, it is difficult to use time data to plan and manage time. Data in Event Logs can help you understand the frequency of interruptions. Most interruptions not only waste time, but also interrupt your thinking and lead to lower efficiency and errors. Therefore, understanding the frequency of interruptions helps improve the quality and efficiency of your work.

 

Save the time data in a proper place. The recommended way to record time consumption is to use the project notepad to record time and other things. For a software professional, the project notebook has many purposes. It can record time logs, program design schemes, and calculation results, and can be used as a credential for the correct project implementation solution you follow, you can record a transient thought in your mind. The recommended method is to record the main activities and the time consumed from the first page of the Project notepad, and record the time logs forward from the last page. Record the main activity and the time it took. The last page starts to record the time log.

 

Weekly activity summary table. By using time logs to collect time data, you can gradually understand how you control the time. However, the data in the time log is too detailed and a more useful table is needed to summarize the data. The weekly activity summary table can well complete this task. Of course, we don't only care about the short time of a week, but also the average time, maximum time, and minimum time spent on various tasks within a period of time. Therefore, the format shown in Table 2.2 is used. The data in the weekly activity summary table can help you understand where the time is spent, and you can use these books to plan for the next few weeks. For example, with this data, you can determine that the time required for a large task may be close to the longest time in the summary table, and the time required for a simple task may be close to the shortest time.

 

Time record prompt. Prepare the project notebook at any time. When you occasionally forget to record the start time, end event or interrupt time, make an early Estimation Based on your memory; Summarize the recorded time data in a timely manner.

 

　VII. Individual Software Process PSP formulation plan

 

　1. How to develop a phase plan

Here we will introduce two types of plans: phase plan and product plan. The phase plan is about the schedule during this period, and the product plan is about the schedule during the production activities. Take reading a book as an example to illustrate the difference between a phase plan and a product plan. To plan this task, first estimate how much time the entire task should spend. For example, you may want to read chapter 20 of the book within 20 hours. For this task, the product plan is to finish reading all the books in 20 hours, and the phase plan is to arrange one hour of reading every week. Represents the relationship between product plans and phase plans in the business field.

 

In order to develop a stage plan, you must be clear about the time usage. Based on the weekly activity summary table introduced in the previous chapter, we can track and record how we control the time. When developing a plan for the next week, you can refer to the Summary Table of the last week's activities. Based on the time spent by previous tasks, you can determine how much time will be spent on these tasks in the next week. The simplest way to develop such a plan is to assume that the time to be used is the same as the average time in the past. A more accurate method is to first consider the work to be done next week, and then estimate a suitable time based on the longest and shortest time in the past.

 

　2. How to develop a product plan

When engineers work in the project team, they need to plan their personal work. Planning is the basis for reliable completion of promised tasks on schedule. It can coordinate the work of engineers in the process of product development, and help engineers understand the status of the project. Planning is an important part of the work of software engineers. To become a talented engineer, you must know how to make accurate plans and how to compare these plans with actual results, so as to learn to develop better plans.

 

Developing product plans is a skill that can be improved through events. From now on, develop a plan for each product. The product can be a configurable program, a program design plan, or a test plan, and continue to do so in future projects.

 

Collect historical project data. For engineers, a product plan includes three estimates: product scale, working time, and progress. The most basic product plan only includes an estimate of the time required for a task or job. By collecting data on the time used by different previous tasks, we can estimate the approximate time required for similar tasks in the future. Table 3.1 is a job ID log designed to record the estimated time and actual time of each project. Based on the historical project data, we can make an estimation conveniently and accurately. Accurate estimation is the key to a good plan.

 

 

Estimate the program scale. The first step of the product plan is to estimate the scale of the product. For programs, you can use the code line measurement method to estimate the size of the new program. For accurate estimation, we need to use the previous scale data. Therefore, it is helpful to classify the previous scale data by function. First, check the requirements of the new program, estimate the number of lines of various types of code, and then compare with the previous statistics to determine how long it takes to develop the new program. As more and more data is accumulated, the estimation will become more accurate. Job ID logs provide a simple way to record a large number of historical scale and efficiency data. You can also use table 3.2 to record the historical data of unsupported programs and sort the logs by scale.

 

　
There are many methods for scale measurement. Different estimation methods should be used based on different objects. Even for programs, the code line measurement method cannot cover all situations. There is no way to ensure that the estimation results are accurate. The key to making a good scale estimation is to have a large amount of historical data and carry out multiple scale estimates, in addition, the actual results should be regularly compared with the estimated values.

 

　　3. Manage the time

You can follow the steps below to manage the time:

1. analyze the historical records of the time used by the user;

2. Create a time schedule to determine how to use the time;

3. Follow up the time used in the scheduling table;

4. Decide what to change and what your actions should meet the requirements of the arrangement.

 

Review the category of the time. The weekly activity summary table shows the average time, maximum time, and minimum time used for each activity every week. Check whether the category of these activities is too large and the other categories are too detailed. The focus of time management is on the few activities that the site spends most of its time on.

 

Make Schedules. The schedule table describes how to use the schedule. Based on the previous schedule data, you can plan and allocate the time required for future activities, as shown in table 3.3.

 

 

Find more time. The key to managing the time is to gradually balance the time used, because the time is fixed 24 hours a day. If you want to spend more time on some tasks in the future, unless you want to spend less time on other tasks, this is often just a wish.

 

Create basic rules. We are doing many things according to certain rules. In order to effectively manage the time, rules also need to be followed. The difference is that the previous rules are made by others, and time management must develop these rules by themselves. In fact, the schedule of time management is a rule designed to manage your own time. The basic rules of time management: If you have decided on how to use the time, You must actually follow the predefined method. In order to do it according to the specific schedule, you must have a very specific plan. Table 3.4 is the daily schedule table from the location to the daily activity.

 

 

Set the priority of the time allocation. Some time periods are fixed, such as weekly meetings, which can be called fixed time. The time for other activities is the time that can be changed, as long as there is time to do these activities. The variable time is divided into the tasks to be completed and the tasks to be considered. The required activities, such as programming and reading, are required, but their time can be changed, because they can be done no matter how time is identified, in addition, the time spent on these activities is different every week. All the other things you need to consider: eating, sleeping, socializing, watching TV and other entertainment activities.

 

When a comprehensive schedule is made, there is no problem with a fixed schedule. The most common problem is the allocation of changeable schedules. List the tasks that need to be done as soon as possible, and first try to complete the most important tasks. When pushing important tasks, you may unconsciously worry about these tasks. It is often more effective to deal with them immediately, and it will also bring people a sense of accomplishment to complete the task. Remember that once you start a daunting task, it will rarely feel as difficult as you think.

 

You may consider taking extra time out of your own discretion, but this requires reasonable arrangements for whether the individual is willing to execute according to the schedule. Having no time to rest will lead to people overthrowing the idea of managing time. It is important to schedule and track the time, but the time schedule must be acceptable to you.

 

Execution schedule table. The ability to work by schedule depends largely on the self-consciousness of the individual, but it also depends on the number of jobs to be done and their priority. Unexpected time is a natural and normal part of life, especially in software engineering. Crisis often breaks people's plans and has to make adjustments.

 

When using a schedule table for the first time, you may feel that it is not very useful. This is normal. Do not give up the schedule process because it does not work for the first time, instead, we need to consider what happened and see if there are abnormal times that are impossible to happen again, or if it takes a lot of time to accidentally lead to a normal event? In an emergency, you don't have to make a big adjustment to the schedule. Try again next week and review the results. If some frequent incidents disrupt the arrangement, you should consider making changes to the arrangement and make preparations for similar incidents in the future.

 

Finally, track the performance of the implementation according to the schedule table and continue to collect time data. According to the experience review schedule, the change schedule should be changed gradually based on the needs and experience. When changing the schedule table, save the previous version.

 

Time management goals. The collection time is used to help you manage the time. If the collected data proves to be useless, you need to reconsider the method of collecting time data. However, this can only be done after the scheduled time has been put into practice. The schedule is recorded. If the schedule changes significantly for some reasons, you should also collect more data and know how to use the time.

 

　8. defect management of PSP in individual software processes

 

　1. What are defects?

Defects refer to errors in the program, such as syntax errors, punctuation errors, or an incorrect program statement. They are anything that affects the integrity and effectiveness of the program to meet user requirements, it is an objective thing that can represent, describe, and count.

 

Some people call the defect a bug, which is incorrect. When it becomes a bug, it is suggested that the annoying Bugs should be shot dead or ignored. This will make some important issues considered trivial and will lead to a wrong attitude. Defects are not like insignificant bugs, but more like time bombs. You may feel a bit exaggerated, and the vast majority of small defects do not cause serious consequences. Unfortunately, a small portion of seemingly insignificant defects can cause serious problems. Although the current defect is not a serious problem for you, it will soon become an important problem.

 

There is no relationship between the complexity of design errors and the impact of the defects caused. Some minor coding errors may cause serious system problems. In fact, the vast majority of Software defects stem from the negligence of programmers.

 

To reduce defects, defect management must be performed to study the introduced defects, identify the causes of these defects, and learn how to avoid repeating the same errors in the future.

 

Defect category. It is helpful to classify defects when analyzing them. Through defect classification, you can quickly identify which type of defect has the biggest problem, and then focus on preventing and eliminating this type of defect. This is the key to defect management. Focus on the several types of defects that are most likely to cause problems. Once these types of defects are controlled, we can further find new ones that are likely to cause problems. Table 4.1 is the work of chillarege and his IBM Research Institute.

 

Do not rush to split each of the 10 types into several sub-classes until you have collected a large number of program defect data. At that time, we can see where more detailed information is needed and what kind of information is most useful.

 

 

Count the number of defects. Use the defect record log to record the defects that remain in the product after you complete the initial design or code. It is easy for people to justify defects, but to manage defects well, they must collect accurate data about the defects. If you forgive defects, you will only deceive yourself. If you do this, don't expect improvement.

　

　　2. defect search technology

Why should we discover defects as soon as possible. Do not expect a simply patchwork program that is full of defects. After modification, it can become a qualified product. Once a defective program is produced, it will always be defective. Although you can fix all known problems and make them pass all tests, it is still a program with many bugs. If an engineer is tolerant of defective work, he will produce low-quality products. "We are busy. We will fix it later." Such an attitude cannot produce high-quality products.

 

Fees for discovering and repairing defects. In a typical project, the product is divided into many small modules, and the engineer is responsible for the development. After the module is designed, implemented, and compiled, engineers perform initial unit tests. After unit tests, multiple modules form some major components for integration testing. After Various levels of component tests, these components are integrated into the product for product design. Finally, the product is integrated into the system for system testing. The unit test, integration test, component test, product test, system test type, duration, and complexity vary with the scale and complexity of the system, however, this process is required for almost all software products.

 

Research shows that the average cost of discovering and Repairing Defects increases by 10 times every step forward in the development process. Although the repair time of a defect changes greatly, the average time always follows this pattern, regardless of the type of the defect.

 

Methods for discovering and repairing defects. Although there is no way to avoid defects, it is still possible to discover and fix them as soon as possible during the development process. There are a variety of methods for discovering defects in the program, basically including the following steps: to indicate the symptoms of the defect; to deduce the location of the defect from the symptoms; to determine the errors in the program; to determine how to fix the defects; To repair the defects; verify that the fix has fixed the problem.

 

There are multiple tools and auxiliary means to help complete these steps. The most commonly used tool by engineers is the compiler, which can express most of the syntax defects. However, the most basic task of the compiler is to generate the target code, and the code may be generated when the source program has defects. Therefore, you cannot check all spelling, punctuation marks, or other defects that do not conform to the syntax. Generally, the compiler only provides symptoms of defects. You must locate the problem and determine what the problem is. Generally, this can be done quickly, but occasionally it takes a long time.

 

Another common method is the test described above. The test quality is determined by the degree to which the test case covers all program functions. Testing can be used to verify almost all functions of the program, but it has its own disadvantage: like the compiler, it can only meet the first step sent by the defect. You must still identify the root cause of the problem from the defect symptom, and then repair; as the scale of the project expands, it will take a lot of time to complete the test, and it is almost impossible to complete the test.

 

The most effective way to discover and fix defects is to review the source program list. This method is difficult to completely remove defects in the program, but it turns out that this is the fastest and most effective method.

 

　3. Code Review

Code review is to study the source code and find errors from it. The reason why code review is more effective is that the problem itself is not a symptom during the review. When reviewing the code from start to end, consider what the program should do. Therefore, when you see that something is incorrect, you can see what the possible problem is and immediately verify the code. The disadvantage of review is that it is very time-consuming and difficult to carry out properly. Review is a kind of skill, which can be improved through study and practice.

 

The first step of code review is to understand the types of defects introduced by yourself, which is the main reason for collecting defect data. Because the types of defects introduced in the next program are generally similar to the previous ones, as long as the same software development method is used, this will always happen. On the other hand, when you have the skills and experience or change the process, the type and number of defects change accordingly. However, to a certain extent, improvement becomes very difficult. If this is the case, you must study the defects. This helps you find a better way to discover and fix the defects.

 

How to review code. The purpose of code review is to discover as many defects as possible in the software process. The less time the defect is found, the better. Using an ordered check method described in table 4.3, code review before compilation is the best method to accomplish the goal.

 

 
Review before compilation. There are several reasons for the code review before Compilation: No matter before or after compilation, the full code review takes about the same time; no matter before or after compilation, the effectiveness of the check syntax is the same; review first will save a lot of compilation time. If you do not review the code, it usually takes 12% ~ 15% of the development time for compilation. Once the code is reviewed, the Compilation Time can be shortened to 3% or less. After the program is compiled, it is generally difficult to thoroughly review the code, when there are many defects in the compilation phase, there are also many defects in the testing phase.

 

Create a personal code review checklist. If you want to discover and correct every defect in the procedure, you must follow an accurate procedure. The checklist ensures that this procedure is followed by a series of program steps. When you follow the checklist, you will know how to review the code.

 

If you can use the checklist correctly, you can also know how many defects are found in each step. In this way, the efficiency of the review process can be measured and the checklist can be further improved. The checklist includes personal experience. By constantly using and improving the personal checklist, you can discover these defects with less time. Table 4.4 is an example of a C ++ code review table.

 

Regularly update the checklist. As time passes, the checklist will naturally become larger. However, the main function of checklists is to help you focus on key aspects. If it is too big, you will lose focus. Therefore, we need to regularly review the defect data and delete the table items that cannot be found.

 

From the personal checklist method, we can realize that each engineer has its own characteristics, and the practical experience of an engineer is not necessarily applicable to others. Therefore, you need to design a checklist suitable for you and check it regularly to ensure that the checklist is more effective. As long as you have missed any defects in the code review, you must constantly look for methods to improve the checklist.

 

Progress is very slow. Initially, your ability to discover defects increases with each review. Since then, it will become very difficult to improve. We must constantly collect and analyze defect data, and constantly think about how to prevent or better find defects. As long as you keep doing it, you can continue to improve in the code review, and constantly improve the quality of your own programming.

 

Encoding standard. The coding standard is a widely accepted set of coding practices that can serve as work samples. Good coding standards will effectively help you avoid developing potentially dangerous code and help prevent defects. For example, you can list the methods that should be avoided in the encoding standard, specify the circular entry of the number or indicate that the variable is initialized to avoid bad variable naming. Coding standards can also effectively unify and standardize the overall development activities. When other developers join the project, they can well adapt to it. The code will become more standardized and easier to maintain.

 

Review other types of code. In a software organization, a common method is peer review, that is, several engineers review each other's procedures. Well-organized peer review generally finds 50% ~ 70% of defects. Although mutual check takes a lot of time, it can effectively discover defects, because engineers are often difficult to find their own design errors. They create this design until the program should be complete, even if the concept is flawed, wrong design or implementation assumptions, they are often hard to find. Checking this helps them overcome these problems. For a large project, the best check strategy is to first review the personal code and then compile it, And then perform a peer check as any test progresses.

 

Careful work is rewarding. When an engineer feels that a quality responsibility is attached to a program developed by him, he will not rely on compilers or other tools to discover defects. Comprehensive code review takes much time, but they save much time than they do and can produce better products.

 

　4. Defect Prediction

Introducing defects is a normal phenomenon for humans, and all engineers will introduce them. Therefore, all engineers should understand the types and data of defects introduced by themselves.

 

During the development process, you can always perform another test or code review. The only way to decide whether to do so is to analyze the defect data. By analyzing historical data, we can estimate the number of defects in the program. By comparing the data of the current project with the estimated data, you can probably know the quality of the program being developed. In this way, you can determine whether to add some defect elimination steps.

 

Defect rate prediction. When developing a new program, it may be difficult to estimate how many defects you will introduce, on the grounds that the number of defects varies depending on the program. The number of defects is unstable due to the following reasons. First, let the experience problem be solved. personal skills are constantly improved. At the beginning of programming, there are many problems that have not been encountered before. It is often difficult to determine how some processes and functions are executed. It may be that the language structure is unclear or there may be new compiler or programming environment problems. These problems will cause fluctuations in development time and defect paths. With experience, you will gradually overcome these problems and make fewer mistakes. This reduces both the total number of defects and the fluctuation of the number of defects. The reduction of defects was initially due to the increase in experience and the improvement in language proficiency. After the initial improvement, we need to collect and analyze the defect data for further improvement.

 

The second cause of defect fluctuations is the instability of the individual process. When you begin to learn to write programs, you also begin to learn to use new processes and methods. Your process will continue to grow with practical experience, which will lead to fluctuations in the time to complete different program tasks and introduce defective data.

 

Finally, the defect itself is also the cause of this change. The more defects introduced, the longer it takes to fix these defects. The longer it takes to fix a defect, the more likely it will be to introduce it. Therefore, the modification time of the defect changes greatly. Therefore, it is difficult to predict a process that introduces many defects.

 

With the improvement of the development process, the process will gradually stabilize. This stability will improve the accuracy of defect prediction. The test proves that if you spend enough time reviewing the Code, your process will be quickly stabilized. Once your process is quite stable, defects are easy to predict.

 

Based on the number of defects introduced and eliminated per thousand lines of the latest program, we can estimate the number of defects that may be introduced and eliminated in future programs.