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 applications in quality software development. Readers can know the basic concepts of risk management, including the six-step risk management process of Boehmis. The article discusses how the quality software technology is both the contributor of software development risks again.
Getting started
According to the definition of the International Standards (ISO), the quality is the ability to meet specific or secret to meet all functions and characteristics of specific needs. This definition shows that quality is the inherent feature of the product, depicts the quality of the product. The second academic party's point of view insists that if the goal to achieve quality must be strengthened in this quality concept. This school believes that quality is not alone, but it is related to customers and products, and customers are some of the funds or affected people, while products include interests and services. Further, the concept of quality changes over time and the changes in the environment value, the value will make people find what is good, what is not good. Therefore, the quality of the software is used as the function / characteristics of the product or service, and must also be positioned in the content between customers and organizations (R.T. Vidgen, A.T. Wood-Harper). This is a useful view of quality. The details of these reviews are included in the following paragraphs, the first step is human factors.
Quality point of view
For quality views, everyone in the development process has different views and contradictions. Summary of the following points provided by several key roles in the development process:
u Development Manager: The product is reliable and maintainable, allowing customers to be satisfied, so until the project ends or forced termination (this leads to compromise).
u Business Analyst: Customer and Development Team joint, protect user-defined features and demands are not subject to external changing interference.
U QA Auditor: Discovering the phenomenon of derailment from mass programs / products - all activities that deviate from quality control will be opposed to those related to the project.
u End users: Primary employees have rarely entered what to enter, but must be responsible for it. End users are not satisfied, when they don't want to pay checks for the system, they need to monitor the acceptance of the system.
u Production Line Manager: The end user's boss usually holds this attitude, that is, they don't need too much time period.
u Support investors: People who pay the banknotes, need to deliver the product according to budget.
Finally, it is the quality point of development, which directly affects the method of selecting the final product production. This not only originated from the developer's quality point of view (product relative to the use), but also originated from how to obtain demand (director relative to objective), and how they create their work (coordination relative to conflict). R. T. Vidgen and A.t.wood-harper have proposed four possible developers' knowledge about quality:
u Objective / coordinated: When there is no problem in the target and gets a good description, developers will objectively think that quality is a reasonable engineering process. Quality is in detail, and the need for strict control of development process is achieved. Developers tend to accept quality is the view of the properties of the product (this is the point of view of most software engineers).
u Objective / Contradiction: Developers not only understand that quality is objective, but understanding contradictory interest is solved, so it is impossible to meet the quality needs of everyone, but will determine who meets who needs (so that managers are workers ?).
u Objective / Consistent: Developers believe that quality is related to the structure of the group, to solve different opinions and interests of many different groups (investors / beneficiaries). The final result reflects the agreement of different perspectives.
u Objective / Contradiction: Developers have considered different views and interests, but it is assumed that there will be conflict and functional restrictions, and the new ideas of the liberal constructive quality, which requires more interest and ignores small partial functions. This is more like a coordination instead of unity. Quality characteristics and attributes
All schools believe that quality software has two distinct features: First, is the consistency of the specification (such as this is a good solution?), Second, the intentional goal is suitable for it (it is correct Positioning?). In addition, all schools believe that there is an attribute that makes up high quality software. Search for different quality-related literatures will have many different attributes, the following is seven properties of the Glass suggestion:
Lightweight: Allows the software to easily transfer from a computer to another computer that needs to run.
Reliability: The software correctly meets the ability to meet demand.
Efficiency: Software is the ability to use computer resources (such as memory, deposit, and machine clock cycle).
Humanized Project: The software can be easily understood and learned.
Easy to measure: In order to test the performance of the executable performance of the software.
Apprecient: The software can be read and understood by software maintenance personnel.
Modification: The software can be modified by software maintenance personnel.
The attributes of the above examples have no specific order, just like the quality itself, there is no absolute hierarchical relationship to these attributes. Not all of these properties are useful in any software engineering project. In addition, techniques for implementing these attributes may result in indeed, negative mutual conflicts. Therefore, the priority of quality attributes must be defined before the program development life period, to make up for the shortcomings of the program target and reserve a certain distance between the attributes.
Quality rule
One rule can determine how the software development process introduces software quality factors, that is, the quality rule. Software development groups have recognized this issue and considered this to help the risk test of the production software process. In the Software Quality Books "Software Development and Support Success Framework", Curran and Sanders pointed out that the software quality process should pay attention to four points:
u From the beginning, it is necessary to ensure that it is not wrong, at least the effort is that the error is not in the code. To do this, this includes adopting appropriate software engineering standards and processes, establishing an independent quality assurance future standards and processes; formal methods based on past experiences and lessons; high quality inputs like software tools and contract software.
u ensures that the error is found as soon as possible and correct it, the longer the error hidden, the greater the cost of fixing the error. Therefore, quality control must pay attention to each stage of the development of life cycles, such as demand analysis, design, documentation, and code. These are all affiliated to all review methods such as inspections, pre-arrangements and technical reviews.
u eliminates the guiding factor caused by errors, and the incorrect cause is not found to correct the wrong party. By excluding erroneous incentives, you have achieved the purpose of improving process (recall continuous improvement process is another key principle for software quality in the TQC principle).
u Using independent quality review works in accordance with standards and processes, there are usually two ways to check if the project activity is performed in a predetermined standard and process, ie SEI and SPR.
Quality factors and risks
We have discussed the quality, the next problem is the quality of the software, or the quality of the program, and the risk factors to be discussed in the software development project. In the book "Software Risk Assessment and Control", Jones describes his evaluation experience in software development. With software productivity research (SPR, Software Productivity Research) and software engineering (SEI, Software Engineering Institute) to review hundreds of businesses, the software generated by these projects can be divided into six categories: U management information system: finance and Management system;
U image operating system, communication software, or other physical device control software and other system software;
u Business development project, such as for the end user rent / sale products;
u military software project;
U Contract / Purchasing Software Project (Folk), some of the scattered client software for staff and employers;
U End User Software Project, software that is developed to specific users.
There are more than 100 risk factors in these programs. A few project has more than 15 risk factors, but most of them are 6 factors. Analyze the risk model in these projects, the conclusion is that they are not all common factors in all software. It lists several risk factors that have occurred in the sample program.
MIS:
U slow user demand analysis (80%)
U Overgading time progress pressure (65%)
U low quality (60%)
u severe cost (55%)
u insufficient configuration control (50%)
Low quality software is defined as at all, or the phenomenon of repeated operation failure. Jones Defines Low Quality Software Yes, the user report is more than 0.5 errors in each function point. MIS system low quality performance in two aspects: (1) Uncertain error occurs, such as accidental or non-professional use checks or running tests; (2) Insufficient erroneous prevention, such as using icon combined application design ( JAD) or Information Engineering (IE) standard technology failed, some errors can generate a description of the project.
System software risk:
U long-term plan (70%)
u Insufficient cost estimate (65%)
u too many documentation (60%)
u error module (50%)
u project cancel (35%)
Excessive documentation does not have a strict law, but can be judged from the following points to "too many": (1) more than 50 decentralized documents; (2) Document cost approaches or exceeds the entire project fee 50%; (3) Each function point has more than 2,000 words. The documentation of the system software is second only to military software, too many documents are redundant. (Note that too many documents will cause additional problems. At present, there are no publishing related works explaining how the number, roll, structure or what kind of document style is suitable for software projects.)
Business software risk
u Insufficient user document (70%)
u low user satisfaction (55%)
U too much marketing time (50%)
u Minor Competition (45%)
u Litigation fee (40%) Insufficient user document is defined as incomplete, unclear, wrong or understanding of difficult user information. User information includes online help and publishing materials, which are existing in the commercial software world. This problem can have a factor to describe:
u Technical description lack of quite skills
u User documentation is insufficient:
The documentation released by the N new packages is very difficult.
n Some manufacturers are reluctant to use the author;
N The statement of user documents is still very original;
Low user satisfaction means that users are dissatisfied with the following or more factors (in 1993, more than half of business software exists):
U low quality;
u incomplete function;
u Complex incredible command structure;
u is difficult to learn;
u troubleding installation process;
u User service and support for support;
u Excessive occupied disk space or other hardware resources;
Military software
According to software, there is a quite strict project continuity, and there is also its corresponding expense of high problems and risks.
U too many documents (90%)
u low yield (85%)
U long cycle (75%)
U slow user requirements (70%)
u Do not use or not use software (45%)
Contract / procurement software project risk
U high maintenance costs (60%)
u Principal and contracted world friction (50%)
U slow user requirements (45%)
u Unspetent approval standard (30%)
u Deliverable software legal ownership (20%)
Maintenance costs refers to a year-on-a-month repair or project maintenance costs that are significantly higher than the U.S standard.
Unspected standard recognition is defined as a problem with the presence of product delivery conditions, payment, payment, exceeding the initial contract or agreement between project envelope and contractors. For example, a typical issue is excessive quality requirements, excessive requirements for software performance goals, or special needs or documentation for software. This situation will eventually make the recognition fail, or cause the user to feel unsatisfactory. This will cause damage to the project, affecting customer relationship, and extreme situations will cause legal proceedings.
End user software risk
u Unsmpinked application (80%)
u Hidden error (65%)
u Unsariarable software (60%)
u Excess application (50%)
u Delivered items and software legal relationships (copyright) (20%)
Attractive error is defined as logic or program errors that are not known to developers or any other person in the end user system. It is easier to appear without the final review, inspection, testing, auditing and quality analysis activities.
Unmatched software. Once the software developer leaves the company, who will maintain the software? Some application software institutions are very poor, and the notes are not complete, so that once the developer leaves the company, there is no one who can maintain the software.
Six-step risk management of Boehmis
As Jones said, quality assurance activities directly affect the risk of software development processes. Current software risk management has been corresponding to other projects or management in terms of concept, practical and rules. The goal of software risk management is used to identify, position, and eliminate various risk factors, preventing it from happening to make the project successfully or decrease the probability of software rewriting. This indication occurs under certain conditions. If the operator does not pay attention, these risks may not pay attention to you. The decision tree structure shows that the composite risk is composed of each decision, and the composite risk is a synthesis of the risks of each part. This decision tree provides a quantified method for describing the degree of influence of different options, just as deciding to decide decision parameters for each risk factor. This analysis method is useful when risky probability and no precise analysis methods. Boehm summarizes the six-step risk management rule, which has two key rules, and each method has three sub-steps. Boehm recommends appropriate techniques to implement each of the key steps and sub-steps. The first step is to evaluate, including:
u Risk confirmation, confirm the detailed project risk factor affecting the success of the software;
u Risk Analysis, check the probability of each risk factor and the possibility of reducing the probability of its occurrence;
u gives the risk factor for confirmation and analysis, that is, the order of risk considerations;
Once the order of the project risk factors are arranged, the second step is risk management. In this step, these risk factors should be controlled, including:
u Risk Management Plan, develop how each risk factor is positioned, how these risk factors are managed to integrate with the entire project plan;
u In each risk solution, eliminating or resolving risk factors in each implementation or working;
u Risk monitoring, tracking the trend of the risk of resolving risk activities;
Risk management application of quality factors
As I mentioned in this article "Quality Factors and Risk" section, several ways of software development are directly or indirectly affected by relevant software quality issues, in this section, we have to discuss several can help us control , Mitigate or prevent risk of risk. (Jones)
Factor: Slow user needs
Reduce risk skills:
u use prototype;
u Using JADS technology analysis requirements in the MIS system;
u Using Information Engineering (IE) Technology Creating Demand - Mainly used in the MIS system;
u Using the functional specifications method to monitor the demand, once the specifications are determined during the demand phase, the study is combined with the demand collection process. Automatic tool technology for creating a list of demand features is feasible. The advanced extent of these tools is: strict and rapid collection needs, not only fill in functional points calculations and cost budgets, but also add this data to the Case tool, data model, and design tools.
u New technology - Based on the decomposition of functional points and cost estimates for each function point. This will force users to admit slow users will result in increased financial (cost).
Factor: Module of low quality and wrong tendency
Tips for alleviating risks: quality control and cost control in accordance with progress plans. It has proven that the four skills that affect software quality control are:
Quality assessment and reliable assessment tool. Quality / Assessment Tool is a new market (only 6 kinds of tools in 1993), less than 10% of all software development project managers.
Neglax prevention method. Neglax prevention methods include all technologies that reduce market errors or errors, including: (a) all structured analysis and design technology; (b) prototype; (c) advanced object-oriented language; (d) Strictly use in process language Structured language; (e) Conduct quality function development (QFD); (f) to carry out comprehensive quality management (TQC); (g) Carry out software quality analysis (SQA); (H) cleaning space development method (Translator:? ). Lainable cancellation method. The fault elimination method includes design review, structured preview (prototype), regular code test, correct check, and all test procedures. Regular review and verification have been effectively used to eliminate negligence, almost used by all US quality management leaders. The test work is best used after formal expert training.
Quality management program. Jones pointed out that in the US software quality control leaders (such as Bladrige winners) have a complete quality management program. One of them is to expand in the functional method of the software quality. Outdated code methods are very unclear, very ridiculous, so there are many errors in management demand analysis, design, and documentation, there is no many important documentary materials in terms of quality main body. Function point method is adopted by the US national quality sector and military system, MIS project in 1991. In 1993, the functional point method also used to control or predict the test case or test operation of the software project.
bibliography
Wallmueller, Ernest. "Software Quality Assurance Practice" Prentice Hall, Inc 1994. ISBN 0-13-819780-6
Schulmeyer, Gordon "zero-lost error software". McGraw-Hill, Inc. 1990. ISBN 0-07-05563-6
Glass, Robert. "Constructive Software Quality". Prentice-Hall, Inc. 1992. ISBN 0-13-086695-4
Boogaard, Martin. "In the adaptability of the information system, the software error is reduced by data. The Publishers,
Amsterdam
, 1994. ISBN 90-5170-289-2
Curran, E. And Sanders, J. Software Quality: Software Development and Support Success Framework ". Addison-Wesley Publishing Co., Inc. 1994, ISBN 0-201-63198-9
Blackman, M., Jeffreys, M. "Prototype Quality System". From "Software Quality Management," Extension. Elsevier Science Publishers,
London
. 1993 ISBN 1-85166-963-9
Vidgen, R.T. and Wood-Harper, A.t., "Determining and Management Quality Concept", from "Software Quality Management," extension. Elsevier Science Publishers,
London
. 1993 ISBN 1-85166-963-9
(Window Software Engineering Translation "2000-5-2, original http://www.huxley.baz.com/kjordan/swse625/htm/tp-rm.htm)
