software before the release of the development process is mainly divided into requirements analysis, design, coding and validation of four phases, the final software quality and the four phases of the relationship between the respective quality is:Final Software quality = demand Analysis quality && design quality && Coding quality && validation qualityThat is , the final quality from the quality of each stage of the "and", as long as one of the links quality is poor, the overall quality of the product will be poor, do not think it is "or" relationship. It seems that the quality of each stage plays a decisive role.
Complete Demand AnalysisThe purpose of the requirement analysis is to make the project team understand what to do, to decide what kind of software should be developed, and clearly complete demand analysis is the premise of high-quality software. If the software developed is inconsistent with what the user wants, it is impossible for the user to say "the quality of the software is very good". If the direction is not right, software development to "good" also has no meaning. The development cost of a demand analysis error is high, as is mentioned in the book "Software Engineering", so the industry is sufficiently aware of the importance of demand analysis. Of course, know its importance and how to obtain a complete demand analysis is two different things, as to how to do a good job in demand analysis, readers refer to the relevant books. Demand Analysis If there is a mistake, there is a feature-it will definitely be exposed! It's just that the presence is exposed to the software development process or in the hands of the user. Therefore, the problem caused by demand analysis, although serious, but it can be found in order to get the attention of the project team, and thus can certainly be repaired, but at different stages of the cost of finding such problems will be different.
DesignThe design phase is a better way to find the software through the design approach, noting that this is "better" two words, rather than emphasizing the best. bad design is not as easy to expose as a demand analysis error, but it exposes more appearances, such as complex logic, difficult maintenance, and so on. If the participants do not have the insight to find the hidden behind the phenomenon of the bad design essence, it is likely to suffer the harm but can not extricate themselves, and thought that "is already so complex." project Development is a gradual evolution of the process, the team members of the understanding of the needs of the gradual deepening of the first appropriate design to the back seems likely to be insufficient or inadequate, if the use of the previous design will naturally expose its shortcomings, and then will appear to require higher maintenance costs. The idea of reconstruction is designed to help the project evolve, of course, when using the refactoring method, we should ensure that the project has enough unit test cases to prevent the refactoring and introduce new defects. Refactoring is not just a word, its core should be a methodology, a methodology for optimizing design.
Programming Good habitsThe result of the design phase output is the blueprint, but a good blueprint does not guarantee that the final quality will be good. Take a house to make an analogy, drawing design is better, if the construction of materials used, the final house must be good. What is the "building material" in software development? Is the code written by the programmer. How to ensure its quality? This needs to be ensured through good programming habits. in the real project, the design may have a certain degree of blending with the code, that is, by a certain encoding to assist the design. This practice does not affect the design and coding here are divided into two key elements of quality assurance.
Validationvalidation is one of the most common methods of quality assurance that can easily be thought of as testing. But the verification should contain more connotation, such as verifying the software demand is one of the users hope. The understanding of validation still requires the building of houses as an analogy to deepen understanding. In the construction of the house, when the building materials to the site, it needs to be inspected to ensure that its quality is qualified, otherwise it can not be used for construction. corresponding to software development, this phase is unit testing. How does a software engineer make sure that the code behaves as it wants after writing the code? That can only be verified by unit tests. After the house has been built, the house must be inspected as a whole to ensure that it is finally qualified. For example, the use of a random wall of cement and sand ratio is appropriate. Although cement and sand are inspected and qualified when they enter the site, they need to be mixed in a certain proportion during construction to be used as building adhesives, and the mixing ratio will determine the bond strength. In the software development process, the software integration test is like the house after the construction good acceptance. a few conclusions can be drawn from the above analogy. First, unit testing is essential in the software development process. Its absence is like the construction of a building material that has not been tested. Second, the unit test should be completed before the integration test. Some projects at the outset did not have a unit test process, but later found that need to increase this link, so the integration test has been completed, then the unit test this situation. The situation is still a bit strange, it is like the house has been built, and then knocked out the wall to check whether the brick is good. The courage to "knock the walls out and check bricks" is good, but if you deploy unit tests early in your project, you can avoid this strange phenomenon. integration (including development integration and system integration) testing is widely used in the software industry to ensure software quality, but the importance of unit testing for software quality assurance in the industry also lacks a broad, deep understanding, it is more regarded as a burden rather than an effective means of quality assurance.
the necessary processThe understanding of the process may vary from one project team to another, but the process necessary to ensure the quality of the software is guaranteed. Design reviews are required to ensure design quality; unit tests, static analysis and dynamic analysis are required as processes to control coding quality, code versioning processes are required to implement parallel development, requirements management processes are required to ensure that the development Department develops the products required by the user, and that the testing department does not omit to validate the product, and so on. Whether a software project has the necessary process is to check whether it is a "manual workshop" important indicators, regardless of the size of the project, the necessary processes should be indispensable, otherwise it can only rely on the subjective consciousness of people to act, and this is inevitably more prone to mistakes. The purpose of the process is to help avoid unnecessary "low-level errors", or to help the project team maintain a good working order through an external, concrete approach. of course, the process is not omnipotent, do not superstition the role of the process, set up with their own project team to match the process is meaningful, otherwise the team for the process to pay a great effort but the effect is not good, and then draw "process useless theory." If the discovery process is used so that the team does not have the time to do something really meaningful, it should reflect on the process to find content that is not worth it and improve it. Do not for the process and "process", there are a large number of domestic adoption process but can not understand its original meaning and can not be well executed examples. The application of the process is not only to perform the actions prescribed by the process, but rather to understand the ideas behind them and to understand the benefits of each movement from the perspective of the development team in favor of delivering high-quality software on time. in order for the process to be truly used in the organization, it takes time, and the beginning of the process is inevitably subject to conflict, because the deployment process is actually a change in the way people behave, and when a person involves a change in his or her behavior, there is a certain amount of emotion. To make the process popular, we should start from the top leadership and understand the significance of the Organization, and then advocate "This is the necessary guarantee for our success." If the upper-level leader does not understand the role of the process, it can be asserted that the deployed process is highly unlikely to be effectively used in the organization. The best process is to "seamlessly" integrate with the project's development environment, and the effort required to use the process is as small as possible, generally improving its operability. In addition, the process should be as instrumental or automated as possible, and a complex process is destined to be another device. Agile Software Development has been popular for the last more than 10 years, and its core idea is "simplification", simplifying the process of software development. Of course, the purpose of simplification is not to be lazy, but to be more responsive to the uncertainties in the software development process to ensure the success of the project as much as possible. The author believes that the use of Agile ideas to guide the development of software needs a higher level, it is intended to require users to understand the characteristics of the software industry, and then simplify. However, some project groups actually have no process at all, just because they do not call themselves the use of agile ideas, but also the agile of the one-sided content as an excuse for not doing something. For example, the requirement for software design documentation in agile software development is relatively low, but some people use it as an excuse to say, "You see, agile thinking doesn't advocate writing documents."
the right toolwhat does the process of software development depend on to support it? That's the tool. UML tools are needed to support the design, and the static analysis and dynamic analysis of the code need to be supported by the corresponding analysis tools, the version control tool is needed for code versioning, and demand management tools are needed to support the requirements management. It can be said that the development of software is inseparable from the support of the appropriate tools, otherwise the project team is likely to be another form of "Manual workshop." The team should be happy to find and use new tools to streamline processes and improve development efficiency, and with open source software, there are plenty of open source tools to help improve software quality and development efficiency. For example, splint is an open source code static analysis tool, Valgrind is open source code Dynamic Analysis tool, Gcov is open source Code coverage tool, Cvs, subversion and git are open source source control tools, Bugzilla is open source defect tracking tool, etc.
Development DocumentationThe high quality of the software should also include efficient work, and documentation plays a very important role in this regard. The documentation can include software design documentation, development guidance to guide developers through development work, test Manuals to guide test work, and so on, which can help teams improve development efficiency. with the rise of the idea of agile software development, some development teams will not write the document as a matter of course, but the author thinks that software development does not write documents equivalent to chronic suicide. The focus of the document is on the elaboration of design ideas or methods of work, and its focus should be on "donuts" to clear TD, rather than "long and smelly". What is the purpose of writing a document? Do you look professional for long enough? or to communicate and improve efficiency? If you want to improve communication and efficiency as the purpose of writing documents, you may be able to make it easier to write documents, and more people will be willing to write. In addition, a page of paper can be finished if two pages of paper, it will be read this document every reader is a waste of time. When the author examines the design document at work, he will ask "what is the purpose of this passage?" Will it be a little superfluous? ", or" here seems to lack a bit of background knowledge? To remind document authors whether they can simplify the document or write it more understandable. In addition to the design documentation, development guides, test manuals and other documents are also very important. For large projects, there are many workflows, including how to prepare the development environment, compile, and so on. With the guidance documents, when the project has new entrants, they help to significantly save the project team to cultivate new people's time, otherwise the new entrants also have to let the old staff spend a lot of time to help him, and thus aggravate the lack of human resources this dilemma. The guidance document also helps the project team to precipitate the knowledge in the development activities, and large projects inevitably have many non-software defect issues in the development process, while documenting the problem in the instructional documentation helps speed up the development process. writing a good document should not be a device, the key to making the document really useful is to advocate a team culture that is accustomed to using documents, and to do this, the author of the document is key. As far as the author's observation, many people wrote the document, others asked him to write the relevant content in the document, he still happily answer, but this is not a way to make use of the document habit of a good method. In this case, the author will often say, "The document has already written this aspect of the content, you can first look, if there is unclear where I revise it", only in this way people will attach importance to the use of documents and improve the quality of the document writing. This article is from the "to Jianli" blog, be sure to keep this source http://yunli.blog.51cto.com/831344/322826
The overall quality theory of a project
