What Are the Main Steps in the Recording Process?

The Personal Software Process (PSP) is a self-continuous improvement process that can be used to control, manage, and improve the way people work. It is a structured framework that includes software development forms, guidelines, 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 explain the principles of individual software processes; help software engineers make accurate plans; determine the steps software engineers need to take to improve product quality; establish benchmarks for measuring individual software process improvements; determine the impact of process changes on software engineer capabilities

Personal software process

along with

The purpose of PSP0 is to establish individual processes

PSP1 focuses on individual planning and introduces an estimation-based planning method PROBE (P

The focus of PSP2 is on individual quality management. The inspection form is established based on the defects of the program, and the design review and code review (sometimes called "

The goal of PSP3 is to extend the production efficiency and production quality that can be achieved by individual development of small programs to large programs; the method is to use a spiral upward process, that is,

PSP is a process that needs to be improved step by step.

When Watts S. Humphrey was in military service, he had to learn to shoot with machine guns. At the beginning of the training, he hit mud pigeons with shotguns. Watts' performance was very poor, and hard training still did not improve. The instructor observed Watts for a while and advised him to shoot with his left hand. As a right-handed person, Watts was very accustomed to starting, but after practicing a few times, Watts' results are almost always close to excellent.

This case illustrates several issues. First of all, to diagnose a problem through measurement, it is easy to see that some adjustments to Watts must be made by understanding how many Watts have hit and missed the target. Then, the measured data must be objectively analyzed. By observing the shooting of Watts, the instructor can analyze the process of Watts shooting loading, positioning, tracking the target, aiming, and finally firing. The purpose of the instructor was to find out what steps were wrong with Watts and to find out what the problem was, so the suggestion was to find out that he was shooting with his left hand.

Finally, and most importantly, is its own change. Process improvement is very difficult because people are often reluctant to try new things. Their traditional habits seem so natural that they don't believe that change will help. Watts always uses his right hand and never thought about what left-handed shooting would look like. But since Watts adopted the instructor's advice, his grades have improved.

Defining a measurement method is not easy, but it is always possible. First define the measurement method. Once a measurement method is specified, data must be collected and analyzed. If improvements are needed, the next step is to analyze the work process and see what needs to be improved. In the end, to really improve, you must actually make improvements.

If Watts doesn't improve his shooting process, his results will not change in a few years, and he will not become an excellent gunner. Measurment alone will not produce much improvement, and hardly any improvement by effort alone. The way you work determines the results you get. If you still work the same way, you will get the same results.

Improving the way it works is the same as Watts learning to shoot. They are not complicated, as shown in Figure 1:

What are the flaws in personal software processes

Defects refer to errors in the program, such as syntax errors, punctuation errors, or an incorrect program statement. Anything that affects the completeness and effectiveness of the program and meets user requirements is an objective thing that can be represented, described, and counted.

Some people call bugs bugs, which is incorrect. When it became a bug, it was thought that those nasty bugs should be shot dead or ignored. This will make some important issues considered trivial and develop a wrong attitude. Defects are not like trivial bugs, they are more like time bombs. Everyone may feel a bit exaggerated, most of the small flaws have not caused serious consequences. Unfortunately, a small number of seemingly insignificant defects can cause serious problems. Although defects are not a serious problem for you now, they will soon become an important problem.

The complexity of design errors is not directly related to the impact of the resulting defects, but some minor coding errors can cause serious system problems. In fact, the vast majority of software defects stem from the negligence of programmers.

In order to reduce defects, you must conduct defect management, study the defects that have been introduced, determine the causes of these defects, and learn how to avoid repeating the same mistakes in the future.

Defect classification. When analyzing defects, it is helpful to classify them. Through defect classification, you can quickly find out 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.

Table 4.1-Classification of defects

. Focus on the types of defects that are most likely to cause problems, and once those types of defects are under control, find new ones that are likely to cause problems. Table 4.1 is the work of Chillarege and his IBM Institute.

Don't rush to subdivide each of the 10 types into several sub-categories until you have collected a large number of program defect data. Only then can you see where more detail is needed and what information is most useful.

Count the number of defects. Use a defect log to record defects that remain in the product after you complete your initial design or coding. It is easy to justify defects, but to manage them, you must collect accurate data about them. If you forgive your flaws, you will only deceive yourself. If you do this, don't expect to improve.

Personal software process defect finding technology

Why find defects early. Don't expect a simple patchy program full of defects that can be modified to become a qualified product. Once a flawed program is produced, it will always be flawed. Although you can fix all known issues and make it pass all tests, it is still a buggy program with many uncertainties. If the engineer is tolerant of defective work, he will produce a low-quality product. "We are busy, we will fix it in the future." Such an attitude cannot produce high-quality products.

The cost of finding and repairing defects. In a typical project, the product is divided into many small modules, which are developed by a different engineer. After module design, implementation, and compilation, engineers make initial unit tests; after unit tests, multiple modules form large components for integration testing; after various levels of component testing, these components are integrated into products for product design; finally , Integrate the product into the system for system testing. With the size and complexity of the system, the type, duration, and complexity of unit testing, integration testing, component testing, product testing, and system testing vary, but almost all software products of this size require this process.

Research has proven that the average cost of finding and fixing defects increases tenfold with each advance of the development process. Although the time to repair a defect varies greatly, the average time always follows this pattern, regardless of the type of defect.

Methods for finding and repairing defects. Although there is no way to not introduce defects, it is possible to find and fix defects early in the development process. There are many ways to find defects in a program, basically including the following steps: indicating the symptoms of the defect; inferring the location of the defect from the symptoms; determining the error in the program; deciding how to repair the defect; repairing the defect; verifying whether the repair has been completed solved this problem.

There are various tools and aids to help complete these steps. The most commonly used tool for engineers is the compiler, which can express most syntax defects. But the most basic task of a compiler is to generate object code, and it may generate code if the source program is defective. Therefore, you cannot check all spelling, punctuation, or other grammatical defects. Generally the compiler only provides signs of defects. You must locate the problem yourself and determine what the problem is. You can usually do this quickly, but occasionally it takes a long time.

Another common method is the test described above. The quality of the test is determined by how well the test case covers all program functions. Testing can be used to verify almost all functions of the program, but it has its own disadvantages: like the compiler, it can only meet the first step of the defect dispatch. You must still find the source of the problem from the symptoms of the defect, and then you can repair it. With the expansion of the project scale, comprehensive testing will take a lot of time, and it is almost impossible to perform a complete test.

The most effective way to find and repair defects is to personally review the source program listing. This method is very difficult to completely remove the defects in the program, but it turns out that this is the fastest and most effective method.

Personal software process code review

Code review is to study the source code and find errors from it. The reason code review is more effective is that you see the problem itself rather than the symptoms during the review. When reviewing code from start to finish, consider what the program should do. Therefore, when you see something incorrect, you can see what the possible problem is and immediately verify the code. The disadvantages of re-examination are: it is very time-consuming, and it is difficult to carry out properly; of course, a skill can be improved through learning and practice.

The first step in code review is to understand the types of defects you introduced. This 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 be the case. On the other hand, when you have the skills and experience or change the process, the type and number of defects will change accordingly. But to a certain extent, improvement becomes very difficult. This is where defects must be studied, which can help you find better ways to find and fix defects.

How to conduct a code review. The goal of code review is to get as early as possible in the software process and

Table 4.3-Code Review

Find as many defects as possible, and the less time it takes to find them, the better. Using an orderly inspection method described in Table 4.3, code review before compilation is the best way to achieve the goal.

Review before compiling. There are several reasons why code review should be performed before compilation: whether it takes approximately the same time to perform a complete code review before or after compilation; whether before or after compilation, the effect of checking the validity of the syntax is the same; do it first The review will save a lot of compilation time. Without code review, it usually takes 12% to 15% of the development time to compile. Once the code review is used, the compilation time can be shortened to 3% or less. After the program is compiled, the code is generally The review is difficult to carry out thoroughly; experience has shown that when there are a large number of defects in the compilation phase, there are also many defects in the testing phase.

Create a personal code review checklist. If you want to find and correct every defect in your program, you must follow a precise procedure. A checklist ensures that this procedure is followed. It includes a series of programmatic steps. When you follow the checklist, you know how to perform a code review.

If you can use the checklist correctly, you can also know how many defects were found at each step. This will measure the efficiency of the review process and further improve the checklist. The checklist includes personal experience. By constantly using and improving your personal checklist, you can help find these defects in less time. Table 4.4 is an example of a C ++ program code review table.

Checklists are updated regularly. Over time, the checklist will naturally grow larger. However, the main purpose of the checklist is to help you focus on the key aspects. When it is too big, you will lose focus. Therefore, it is necessary to periodically review the defect data and delete those entries that cannot find the problem.

From the method of personal checklist, we can recognize that each engineer has its own characteristics, and the practical experience of an engineer may not be applicable to others. Therefore, design a checklist that suits you and check it regularly to ensure that the checklist is more effective. As long as you leave out defects in your code review, keep looking for ways to improve your checklist.

Progress is slow. Initially, your ability to find defects improves with each review. Thereafter, improvement will become difficult. We must persist in collecting and analyzing defect data and thinking about how we can prevent the occurrence of defects or how to better find them. As long as you continue to do it, you can continue to make progress in the code review and continuously improve the quality of your own programs.

Coding standards. Coding standards are a widely accepted set of coding practices that can be used as working examples. Good coding standards will effectively help you avoid developing potentially dangerous code and help prevent defects. For example, you can list in the coding standards those methods that should be avoided, the loop entry of the specification number, or initialization variables in the description, and avoid bad variable naming. Coding standards can also effectively unify and standardize overall development activities. When other developers join the project, they can adapt to it all. The code will also become more standardized and easier to maintain.

Review of other kinds of codes. In software organizations, a common method is peer review, where several engineers review procedures with each other. Well-organized peer reviews will typically find 50% to 70% of defects in the process. Although mutual inspection takes a lot of time, it can effectively find defects, because engineers often find it difficult to find their own design errors. They create this design until the program should be complete. Even if the concept is flawed, the design is wrong, or the assumptions are implemented, they are often difficult to find. Checking this can help them overcome these issues. For a large project, the best inspection strategy is to do a personal code review before compiling, and then peer review as any testing progresses.

Careful work pays off. When an engineer feels a quality responsibility for a program he develops, he does not rely on a compiler or other tool to find defects. Comprehensive code reviews take time, but they save much more time and can produce better products.

Personal software process defect prediction

Introducing defects is a normal human phenomenon, and all engineers introduce defects. Therefore, all engineers should know the type and data of the defects they introduced.

During development, there is always another round of testing or code review, and the only way to decide whether to do this is to analyze the defect data. By analyzing historical data, you can estimate the number of defects in the program. By putting the quality of the current project data. This will determine if you need to add some troubleshooting steps.

Defect rate prediction. When developing a new program, you may find it difficult to estimate how many defects you will introduce because the number of defects varies from program to program. The number of defects is unstable due to the following reasons. First of all, make the issue of experience, individual skills are constantly improving. When you start programming, you face many problems that you haven't encountered before. Often it is not sure how some procedures and functions are executed, it may be that the structure of the language is unclear or you may encounter problems with new compilers or programming environments. These problems can cause fluctuations in development time and defects. With experience, you will gradually overcome these problems and make fewer mistakes. This reduces both the total number of defects and fluctuations in the number of defects. The reduction in defects was initially due to increased experience and improved language proficiency. After this initial improvement, defect data needs to be collected and analyzed for further improvements.

The second cause of defective path fluctuations is the instability of individual processes. When you start learning to write programs, you also start to learn to use new processes and methods. Your process will continue to evolve with actual experience, which will cause fluctuations in the time to complete different program tasks and introduce flawed data.

Finally, the defects themselves are the reason for this change. The more defects you introduce, the longer it will take to fix them. The longer it takes to repair a defect, the more likely it is that a new defect will be introduced. Therefore, the modification time of the defect varies greatly. Therefore, it is difficult to predict a process that introduces many defects.

As the development process improves, the process will gradually stabilize. This stabilization will improve the accuracy of defect prediction. Experiments have shown that if enough time is spent on code review, your process will quickly stabilize. Once your process is fairly stable, defects will also be easy to predict.

By tracking the number of defects introduced and excluded per thousand lines for the most recent program, you can estimate the number of defects that may be introduced and eliminated in future programs.