Software Quality Control

Reference:

Software Quality control involves many variables. The key is to manage and control each step. The entire software development process needs to be standardized.
1. Make a demand review when necessary. However, a good communication skill is required to guide the customer to come up with the exact requirement. The technical requirements of the development project should be reviewed on the premise that the customer needs are well understood.
2. Review and discuss the architecture during the outline design. Make sure that you have enough time and energy to fully discuss whether the summary design meets your needs. The progress cannot be too tight, and the summary cannot be used to get started directly.CodeWrite. (This is also the most common problem in previous projects .) The project manager must have the courage and confidence to withstand the pressure of the boss. Many bosses may ask, how many lines of code have you compiled? Why haven't I done anything here?
3. The detailed design should be as uniform and standardized as possible. Unified encoding rules are required. Naming rules and other constraints. Even if the geniusProgramPersonnel should also follow appropriate specifications. Otherwise, you will be scolded for maintaining the code of a genius in the future.
4. The test starts at the requirement and design stage and cannot be performed after the encoding is completed. Unit Tests in the re-coding process should be paid attention to, and exchange tests between programmers can achieve certain results. The earlier the problem is found, the less trouble it is.
5. Perform codereview on the code for implementing important functions. In order to avoid flow in the form, make full coordination and preparations before the meeting.
6. Version control. Demand change control. Use appropriate tools to control version and demand changes. Avoid confusion in later versions and do nothing.
7. Of course, there are still documents. To do this, we need to standardize and be steadfast. It is a waste of time to handle the inspection and delivery of documents. If the document is too difficult to control, it can also be annotated during coding.

 

The reality is:

1. There is no white box testing concept in the product. From the very bottom of the Code, after years of modification, it has been a lot of problems. How many implicit problems do a function have?Testing and statistics.

2. The code is not restructured, and the company's leaders do not pay attention to refactoring, resulting in serious code corruption. The fact is that a configuration variable is maintained in multiple places. Once it is modified, it needs to be modified in many places. In addition, the module is filled with thousands of lines of classes and thousands of lines of files. The largest triadapter class has 16258 rows and the welldatamanager 17055 rows. It is very convenient to use the class. You only need to find welldatamanager for data-related items, then you will be wandering in tens of thousands of lines of code. Other problems such as code duplication and excessive dependency are even more.

3. Black box testing is insufficient. Code of seven or eight people. Two people are tested. And over a long period of time, a fixed number of two people become habitual to the software, resulting in failure to test in many places.

4. There is no standardized software development process. Software Design and Test Case writing

5. If the test time is insufficient, the software function is still being developed one week before the software release.

6. Unstable requirements. Problems arising from repeated demands modification. For example, when the scale is drawn, the actual vertical painting, the subsequent horizontal painting, and the subsequent vertical painting

7.