How to ensure software quality - 2002 system analyst exam afternoon test second summary: Software quality is the life of software. Ensure that software quality requires a benign management environment in addition to technology. The software process acts as a software-developed management environment plays a decisive role in software quality. A successful software process should have the following characteristics: 1. The software process is effective, can determine and solve the uncertain factors in software development 2, All resources in the software can be controlled, and there is no dependence on certain resources, such as relying on a developer, or relying on a computer, etc. 3. The software process is predictable and tracked, and it is possible to know the status of software development and possible defects. 4, the software process is scalable, adjustable; after knowing the defect, it is possible to modify the software process. 5. The software process should be a management process. Each team is a subject of management. Their behavior directly affects the quality of the product, full mobilization and stimulating the energy of the team members have a positive role in improving software quality. This article intends to talk about its own experience in the above aspects to ensure software quality. The body has experienced software development from the development and evolution of computer software development technology, has experienced software development from simple development to large-scale. It is certain that the software quality is always the core competitiveness of the software regardless of how software development evolves. At present, the software development of our country is also advancing towards large-scale software development, and many foreign advanced experiences have strong guiding roles in our management software development. Below I intend to talk about the software process, risk management, and team organizations in combination with their five-year development experience. Views and practices that guarantee software quality. Software process. From a few years of development experience, traditional waterfall development is not suitable for the current small team (<10 people) development, rapid development tool RAD's emergence and the use of auxiliary design tools, plus software scale is growing, we More needed as an iterative development process such as RUP, a fast strain ability of various issues into a single software development organization's mature logo. First we have to realize that the complete software process like RUP is unrealistic to a small team, so it is necessary to cut the standard RUP development process, so that it meets the characteristics of its own development, so a development process Whether it is effective to see if you can solve the actual problem. Last year, I participated in a project that was not very successful. The project's progress was over-term. The developer faith is all right. Everyone shizes responsibility, and the problem is also mechanical response. After the summary, it was found that there is a big reason for the unsuccessful project. There is no development process that meets its own characteristics. There is no pre-set system to coordinate after the problem occurs, so a software development process that meets its own characteristics is to ensure software quality. basis. According to RUP's experience, we divide software development into four phases as RUP: initialization, refine, build, and deploy four phases. Since we were initial to use the RUP development process, the target positioning of software development in the key process domain (KPA) that found software development was basically satisfied with the critical process domain of CMM 3, according to our group. We have developed several key processes such as demand analysis, change and configuration management, project management, analysis design, testing, and controlling the activities of the entire software through the definition of these critical processes. Demand Analysis Key activities are resources that are required to achieve collection and define software development. According to the nature of the development project, the focus of demand analysis is different. For example, for the database, we focus on the business logic of the project, mainly analyzing and compare the differences and implementation between business logic, such as simple Forwarding projects, for projects with compliance with the system, focus on demand analysis on the implementation of the interface and related to the platform, such as network packet analysis projects.
Practice has proved that the differences between projects have important significance for our project plan and formulate project plans. Change and configuration management critical activities define the countermeasures taken when needed to change. The strategy we take is that when there is a change in demand, all members will exchange the impact of this change to the project progress, and then determine if it is necessary to make changes, once the countermeasures are determined, any member must have unconditionally, This activity is relatively easy to achieve due to the smaller team. Project Management Key activities are mainly to define the environment you need to develop and how to coordinate the progress between members. Implementation of this key activity is mainly focused on version control, using current version control tools, such as CVS, VSS can effectively manage and coordinate the development of small teams. Analysis of these two key activities we mainly adopt several principles. First, analysis and design are appropriately separated. Can't do the analysis, do not do design, in the design, people who do not analyze the analysis may find the defects of the analysis, and the identification of the analysis should be implemented by all members. Second, design and testing are appropriately separated, and the developer is not very happy to do a complicated testing, and the developer's test ideas are narrow. Third, the design and document writers are appropriately separated. The designer should put the energy in design and provide a simple sample, and the specific documentation should be handed over. Practice has proven that the application of the above principles is successful. In addition to several important key activities described above, the RUP software process also defines some more finest key activities, which will not be described in detail here. Risk management risks are the factors that are most likely to impact software progress, often affecting the entire development schedule during development projects. As far as I have experienced, the project can probably be divided into two categories of business custom software and general commercial software, and most of the project for enterprise custom software. It is not difficult to see. In addition to the risk of business custom software, there are almost no other risks such as technical risk, so for such projects, we must put energy in technology, mainly to pre-judging the technical solutions to projects. Success does it have a promotion, such as a project that has been developed with VB and combined with the operating system is not appropriate. In addition to such a problem, when the emergency arrives, we must work hard according to the defined process, do not act freely or according to the main concept, and if there is no process and definition, you should ask member's opinion and define one The process of everyone accepted, which increased the consciousness of the developer's owner. For universal commercial software, in addition to technical risks, business risks are also very important, close attention to the state of competitors and the market's level of accommodation is also the key to the success of the project. Due to the insufficient practice, it is not a lot. Every member of the team group is the main body of the development project, and their behavior directly affects software quality. A successful software must have a good team, so we must fully respect and mobilize each member of the team when developing a project. For a long time, we all use tree type management (Figure 1). A project manager tested several programmers, allocated by the project manager. The programmer completed the task on time. This mode is very high in the project manager. The risk of project success is borne by the project manager. The initiative of the member is not enough. The project manager leaving, and the entire project is falling into the state. This model is more suitable for a project to participate in a newbie, which complement the task under the guidance of the project manager. A more democratic mode than this mode is the mutual equality mode (Figure 2). In this mode, members are equally equal to each other, discussing together, can fully utilize the initiative of each member, but this mode problem is to easily delay the time after the problem occurs.
