Quality and risk management

Quality and risk management

Summary

The purpose of this paper is to compare the relationship between software quality and software risk management. The article first reviews the basic principles, technology, and their application in the process of quality software development. Readers can know the basic concepts of risk management, including the Boehmis six-step risk management process. This paper discusses how quality software technology is both a contributor and a palliative of software development risk.

Introduction to Quality Introductory

According to the International Standards Organization (ISO), quality is the full functionality and characteristics of a product or service that relies on specific or implied capabilities to meet specific needs. This definition shows that quality is the intrinsic feature of the product and depicts the product's quality perspective. The second academic opinion insists that the goal of achieving quality must be reinforced by the concept of quality. The school of thought, quality is not a product-centric, but with customers and products are linked, where the customer is out of the money or affected by some people, and products include benefits and services. Further, the concept of quality will change with time response and environmental value changes, and value will enable people to figure out what is good and what is bad. Therefore, the quality of the software as a function/feature required by the product or service must also be positioned between the customer and the organization (R.T VIDGEN,A.T. Wood-harper). This is a useful point of view on quality. The details of these reviews are contained in the following paragraphs, and the first step is human factors.

Quality point of view

For the quality point of view, everyone in the development process has different views and contradictions. The following are a few brief descriptions provided by several key roles in the development process:

U Development Manager: The product is reliable, maintainable and can satisfy the customer, until the project ends or is forced to terminate (this leads to a compromise).

U Business Analyst: Customer and development team to protect user defined functionality and requirements from external change interference.

QA Auditor: Identify derailment from quality solutions/products-all activities that deviate from quality control will be objected to by the personnel involved in the project.

U End User: Junior employees rarely enter anything into the system, but they must be responsible for their operations. End users are dissatisfied, and they need to monitor the system's acceptability when they are unwilling to pay a cheque for the system.

U production line manager: The end user's boss usually holds the attitude that they don't need too much time period.

U Project investor: The person who pays the bill needs to deliver the product on time and on budget.

Finally, the quality perspective of the developer, which directly affects the choice of final product production methods. This stems not only from the quality perspective of the developer (the product is relative to the use), but also from how to obtain the requirements (supervisors versus objectivity) and how they create the environment in which they work (coordination versus conflict). R.t.vidgen and A.t.wood-harper presented four possible developers ' perceptions of quality:

U objective/coordinated: When the goal is not a problem and is well described, the developer will objectively think that quality is a reasonable engineering process. Quality is a combination of detailed elaboration and the need to achieve strict control of the development process. Developers tend to accept the idea that quality is the attribute of a product (which is the view of most software engineers at the moment).

U objective/contradictory: developers not only understand that quality is objective, and that the interest of understanding contradictions can be solved, so it is impossible to meet the quality needs of all, but will determine the needs of those who meet (to make managers or workers?) ）。

You are objective/consistent: developers believe that quality relates to the structure of the group, to address the different views and interests of many different groups (investors/beneficiaries). The final results reflect a consensus on different points of view.

U objective/contradictory: developers consider different views and interests, but assume that there will be conflict and functional constraints, the liberation of the construction quality of the new ideas, which requires satisfying a lot of interest and ignoring the small part of the function. This is more of a coordination rather than a unity of opinion.

Quality characteristics and Attributes

All schools believe that quality software has two distinguishing features: first, is the conformance of the specification (e.g. is this a good plan?). And second, the intentional goal that fits it (is the correct positioning of the problem?). ）。 In addition, all schools of thought have a property that constitutes a high-quality software. There are a number of different attribute lists for searching for different quality related documents, the following are the seven attributes recommended by glass:

Portability: The ability to allow software to be easily transferred from one computer to another on a computer that needs to be run.

Reliability: The ability of the software to meet demand correctly and accurately.

Efficiency: The smallest software is the ability to use computer resources (such as memory, storage and machine clock cycles, etc.).

Humanized Engineering: The ability of software to be easily understood and learned by people.

Testability: Test capability to test the performance of the software.

Understandable: the ease with which software can be read and understood by software maintenance personnel.

Modifiable: The ease with which software can be modified by software maintenance personnel.

The properties listed above do not have a specific order of precedence, just like the quality itself, there is no absolute hierarchical relationship to these attributes. Not all of these attributes are useful in any software project. In addition, the techniques used to implement these attributes can lead to a real, negative conflict with each other. Therefore, the priority of the quality attribute must be defined before the program development lifecycle to compensate for deficiencies in the program's objectives and to maintain a certain distance between the attributes.

Quality Rules

There is a rule that determines how the software development process introduces software quality factors, and that is the quality rule. The software development Community has recognized this problem and believes it helps in the risk testing of the production software process. In the software quality book "Software development and support success framework", Curran and Sanders point out that the software quality process should pay attention to four points:

U from the beginning to ensure that no error, at least should try to be wrong as far as possible not in the code is happening. This includes the adoption of appropriate software engineering standards and processes, the establishment of independent quality assurance future standards and processes, the development of formal methodologies based on past experience and lessons learned, as well as high-quality inputs like software tools and contract software.

u ensure that errors are detected early and corrected, and the longer the error is concealed, the more costly it is to fix the error. Therefore, quality control must be valued at every stage of the development lifecycle, such as requirements analysis, design, documentation, and code. These are all part of the retrospective approach, such as inspection, scheduling, and technical review.

It is unfortunate for you to eliminate the lead factor causing the error and to correct the error without finding the wrong inducement. By eliminating the temptation to do so, you have achieved the purpose of the improvement process (recall that continuous improvement is another key principle for software quality in the TQC principle of total Quality management).

You use independent quality audits in accordance with standards and procedures, there are usually two ways to check whether the project activity is carried out in accordance with predetermined standards and processes, that is, SEI and SPR.

Quality factors and risks

We have discussed the quality, and the next issue is the quality of software, or the quality of the program, the risk factors to be discussed in the Software development project. In the "Software Risk Assessment and Control" book, Jones describes his assessment experience in software development. A review of hundreds of enterprise projects using software productivity research (spr,software productivity) and software engineering Technology (Sei,software Engineering Institute) The software generated by these projects can be grouped into six categories:

U Management Information System: financial and management systems;

U-like operating system, communication software or other physical equipment control software and other systems software;

U business development projects, such as for the end user rental/sale of products;

u military software project;

U Contract/Procurement software project (civil), some fragmented client software for employees and employers;

U End user software project, that is, some software developed for a specific user.

There are more than 100 risk factors in these programs. A few projects have more than 15 risk factors, but most are 6 factors. Analyze the risk patterns in these projects and conclude that they are not all common elements in all software. Here are a few of the risk factors that appear most frequently in the sample program.

Mis:

U Slow user Needs analysis (80%)

U too much time schedule pressure (65%)

U Low Quality (60%)

U severe extra cost (55%)

U inadequate configuration control (50%)

Low-quality software is defined as not working at all, or repeated failures of operations. Jones defines low-quality software as the user reports that there are more than 0.5 errors per calendar year and every feature point. The low quality of MIS system is shown in two aspects: (1) The error of uncertainty appears, errors such as accidental or unprofessional use checking or running tests, (2) inadequate error prevention, such as standard technology that uses such as joint application Design (JAD) or information Engineering (IE) fail, some errors can produce a description of the project.

System software Risk:

U-long Plan (70%)

U Insufficient cost estimate (65%)

U too much document work (60%)

U wrong Module (50%)

U project Cancellation (35%)

Too much document work has no strict rules, however, it can be judged from the following points: (1) More than 50 scattered types of documents, (2) document costs close to or exceed the overall project cost of 50%; (3) Each feature point has more than 2000 words described. System software documents are second only to military software in order of magnitude, and too many documents are redundant to work. (Note that too many documents can cause additional problems, and there is no published work to explain how many, volumes, structures, or what kind of document style is appropriate for a software project.) )

Commercial software risk

u Insufficient user documentation (70%)

U Low User satisfaction (55%)

U Too Much marketing time (50%)

U Harmful Competitive Activity (45%)

U litigation costs (40%)

Inadequate user documentation is defined as incomplete, unclear, incorrect, or difficult to understand user information. User information, including online help and publishing materials, is a widespread problem in the business software world. This problem can be described by a few factors:

U technical description lacks considerable skill

u user documentation is not sufficient:

N New packages Publish documents every time it's difficult;

n Some vendors are unwilling to use competent authors;

n the statement of user documentation is still a very primitive method;

Low user satisfaction means that the user is dissatisfied with one or more of the following factors (in 1993, more than half of commercial software has these problems):

u low quality;

u incomplete function;

U complex MAGIC command structure;

U hard to learn;

u troublesome installation process;

U User Service and support strength is insufficient;

U excessive consumption of disk space or other hardware resources;

Military software

Software has very strict project continuity, and it also has its corresponding costly problems and risks.

U Too many documents (90%)

U low Yield (85%)

U long period (75%)

U Slow user needs (70%)

U no or no use software (45%)

Contract/Procurement software project risk

U High Maintenance Cost (60%)

Friction between the client and the contractor (50%)

U Slow user needs (45%)

U-Unpredictable Accreditation standards (30%)

U-delivered software legal ownership (20%)

Maintenance cost refers to the annual repair error or a significantly higher than the U.S standard project maintenance costs, a person can maintain the current total number of software is significantly lower than the U.S standard.

Unforeseen standard approval is defined as a problem that sometimes exists between the project principal and the contractor in relation to the conditions of delivery, payment, exceeding the initial contract or agreement. For example, a typical problem is a high quality requirement, a high demand for software performance goals, or the special needs or documentation of the software. This can eventually result in an acknowledgement failure or a user feeling dissatisfied with the job. This can cause damage to the project, affect customer relationships, and extreme situations can lead to legal action.

End user Software risk

U Non-transferable applications (80%)

U hidden Error (65%)

U Non-maintainable software (60%)

U redundant Applications (50%)

The legal relationship of the goods and software delivered by U (copyright) (20%)

A hidden error is defined as a logical or procedural error hidden in the end-user system that is not known to the developer or any other person. is more likely to occur without final review, inspection, testing, auditing, and quality analysis activities.

Software that is not maintainable. Who will maintain the software once the software developer has left the company? Some application software is poorly structured and commented out so that once a developer leaves the company, no one can maintain the software.

Boehmis Six-Step risk management

As Jones said, quality assurance activities directly affect the risk of the software development process. Current software risk management has been mapped from concepts, practices and rules to other engineering or management areas. The goal of software risk management is to identify, locate, and eliminate risk factors that prevent them from occurring before they arrive, so that the project succeeds or the probability of software rewriting is reduced. This symptom happens under certain conditions. If the operator is not aware, these risks may occur while you are not paying attention. The decision tree structure shows that the compound risk is composed of each decision item, and the compound risk is the synthesis of each part risk. This decision tree provides a quantified method for describing the degree of impact of different options, such as decision parameters that determine the parts of each risk factor. This method of analysis is useful in the probability of risk occurrence and in the absence of an accurate analysis method.

Boehm summed up the six-step risk management law, which has two key rules, each of which has three sub steps. Boehm recommends using the appropriate technology to implement each of the key steps and steps. The first step is to assess, including:

U risk recognition to identify detailed project risk factors that affect the success of the software;

U risk analysis, check the probability of occurrence of each risk factor and reduce the probability of its occurrence;

U to identify and analyze the risk factors to determine the level, that is, the sequence of risk considerations;

Once the project risk factors are sorted out, the second step is risk management. In this step, you have to control these risk factors, including:

U risk management Plan, define how each risk factor is positioned, how these risk factors are managed to integrate with the whole project plan;

U in each implementation activity or work of the risk solution, eliminate or solve the risk factors of special activities;

U risk monitoring, tracking the trend of the risk process to resolve risk activities;

Risk management application of quality factors

As I mentioned in the "Quality Factors and risks" section of this article, several ways of software development are directly or indirectly affected by related software quality issues, and in this section we discuss several techniques that can help us control, mitigate, or prevent the occurrence of risks. (Jones)

Factors: Slow user needs

Risk Mitigation Tips:

u use prototypes;

U use jads technology to analyze demand in MIS system;

U Use Information Engineering (IE) technology to create requirements-mainly in the MIS system;

U Use functional specifications to monitor the progress of requirements, once the specification is identified in the requirements phase, the research is combined with the requirements collection process. It is now possible to create the automated tools technology for the requirements feature list. The advanced features of these tools are: the rigorous and rapid collection of requirements, not only to fill in function point calculation and cost budget, but also to add this data to case tools, data models and design tools.

U new technology--based on the decomposition of function points and cost estimation of each function point. This will force users to acknowledge that slow user demand will lead to increased financial (cost).

Factors: low-quality and error-prone modules

Risk Mitigation Skills: quality control and cost control in accordance with the schedule. Four techniques that have proven to affect software quality control are:

Quality assessment and reliable assessment tools. The Quality/evaluation tool is a new market (only 6 such tools in 1993 years) and less than 10% of all software development project managers ' personnel.

Fault prevention methods. The fault prevention method includes all techniques to reduce market errors or errors, includes (a) all structural analysis and design techniques, (b) prototypes, (c) Advanced object-oriented languages, and (d) rigorous use of structured language in process languages; (e) Development of quality function (QFD) (f) Implementation of total Quality Management (TQC), (g) Implementation of software quality analysis (SQA) and (h) Clean Space development methodologies (translator:?) ）。

Fault elimination method. The method of fault elimination includes design review, structured preview (prototype), formal code validation, correctness verification, and all test steps. Formal review and validation has been effectively used to eliminate negligence and has been adopted by almost all American quality management leaders. Testing is best done after formal expert training.

Quality management procedures. Jones points out that software quality control leaders in the United States (such as Bladrige winners) already have complete quality management procedures. One of these is the expansion of functional methodologies in the area of software quality. Outdated code methods are so ambiguous and absurd that there are many errors in managing requirements analysis, design, and documentation, and there is not much important literature on quality subjects. Function Point method was in 1991 by the United States national quality departments and military systems, MIS projects and so on. The functional point method is also used to control or predict test cases or test runs for software projects in 1993.



Reference bibliography

Wallmueller, Ernest. "The practice of Software Quality Assurance" Prentice Hall, INC 1994. ISBN 0-13-819780-6

Schulmeyer, G. Gordon, 0 fault error software. Mcgraw-hill, Inc. 1990. ISBN 0-07-055663-6

Glass, Robert. "Construct software Quality". Prentice-hall, Inc. 1992. ISBN 0-13-086695-4

Boogaard, Martin. Reducing software errors through data independence in the adaptability of information systems. Thesis publishers, Amsterdam, 1994. ISBN 90-5170-289-2

Curran, E. and Sanders, J. Software quality: A successful framework for software development and support. Addison-wesley Publishing Co., Inc. 1994, ISBN 0-201-63198-9

Blackman, M., Jeffreys, M. "Prototype quality system". From "Software Quality Management," extended. Elsevier Science Publishers, London. 1993 ISBN 1-85166-963-9

Vidgen, r.t. and Wood-harper, A.T., "Identify and manage quality concepts" from "Software Quality Management," extended. Elsevier Science Publishers, London. 1993 ISBN 1-85166-963-9



(software engineering translated from the window in 2000-5-2, the original http://www.huxley.baz.com/kjordan/swse625/htm/tp-rm.htm)