Unit 3

Unit 3
August 9, 2011
Elements of Quality Engineering
There are two goals of the software quality engineering (SQE). The rst goal is to build quality into the software from the beginning. The second goal of the SQE is to keep that quality in the software throughout the software life cycle (SLC). The elements of the software quality engineering are as follows: 1. Standards; 2. Reviewing; 3. Testing; 4. Defect analysis; 5. Conguration management (CM); 6. Security; 7. Risk management. Every SLC(Software Life Cycle) model has divisions, or periods of eort, into which the work of developing and using the software is divided.
P.Selvapriyavadhana,Asst.Prof,ACT
Recognition of a need or problem (e.g., Requirement); Denition of the software solution to be applied (e.g., Analysis); Development of the software that solves the problem or satises the need (e.g., design and coding); Proving that the solution is correct (e.g., testing); Implementing the solution (e.g., installation and acceptance); Using the solution (e.g., operation); Improving the solution (e.g., maintenance);
Standards
Standards are intended to provide consistent, rigorous, uniform, and enforceable methods for software development and operation activities. Standards cover all aspects of the SLC, including the very denition of the SLC itself. Whether a standard comes from within a company, is imposed by government, or is adopted from an industry source, it must have several characteristics. These include the following: Necessity. No standard will be observed for long if there is no real reason for its existence. Feasibility. Common sense tells us that if it is not possible to comply with the tenets of a standard, then it will be ignored. Measurability. It must be possible to demonstrate that the standard is being followed. Each of these characteristics supports the total enforceability of the standard.
SQM 2
Reviewing
Reviews permit ongoing visibility into the software development and installation activities. Product reviews, also called technical reviews, are formal or informal examinations of products and components throughout the development phases of the life cycle. They are conducted throughout the software development life cycle (SDLC).
SQM
Figure 1: SDLC reviews
SQM
Informal reviews include walk-throughs and inspections. Inspections are a more structured type of walkthrough. Process reviews may be held at any time. The purpose of a process review is to examine the success of the software process in eect.
Testing
Tests provide increasing condence and, ultimately, a demonstration that the software requirements are being satised. Test activities include planning, design, execution, and reporting.
SQM
Figure 2: Simplied test process
SQM
Test planning begins during the requirements phase and parallels the requirements development. Actual testing begins with the debugging and early unit and module tests conducted by the programmer. An important aspect of complete testing is user acceptance testing. Test cases, scenarios, data, and procedures, together with expected results and completion criteria, should be ready to be applied from module testing (if included on the particular project) through qualication and acceptance tests. Test reports document the actual results of the testing eort as it progresses. For each test that is run, a report of the expected results, actual results, and the conclusions of the test conductor concerning success of the test should be prepared. Test reports document the actual results of the testing eort as it progresses.
Defect analysis
Defect analysis is the combination of defect detection and correction, and defect trend analysis. Defect detection and correction, together with change control, presents a record of all discrepancies found in each software component. It also records the disposition of each discrepancy, perhaps in the form of a software problem report or software change request. Once the change is completed and tested, it will be reported by CM to all concerned parties, installed into the operational software by the developers or operations sta, and tested for functionality and compatibility in the full environment. This procedure is required for the ongoing project to make sure that all defects found are properly xed and closed. It also serves future projects by providing a means for feeding defect information back into the development life cycle and modifying the software development process so that future occurrences of certain defects are reduced.
SQM
Figure 3: Typical change procedure
SQM
SQM
Conguration management
CM is, in fact, three related activities: identication, control, and accounting. If the physical and functional audits are included as CM responsibilities, there are four activities. CM may be informal for the organization itself, to keep track of how the development is proceeding and to maintain control of changes.
SQM
10
Figure 4: CM activities
SQM
11
Conguration identication is, as its name implies, the naming, and documentation, of each component. Conguration control is that activity that prevents unauthorized changes to any software product. Conguration accounting keeps track of the status of each component. The latest version or update of each software component is recorded.
Security
Security activities are applied both to data and to the physical data center itself. These activities are intended to protect the usefulness of the software and its environment. Damager of the quality of output of an otherwise high-quality software system is data that has been unknowingly modied. Hackers and software attackers and the burgeoning occurrences of viruses also need to be considered. These threats to software quality must be recognized and countered.
Risk management
There are several types of risk associated with any software project. Risks range from the simple, such as the availability of trained personnel to undertake the project, to more threatening, such as improper implementation of complicated algorithms, to the deadly, such as failure to detect an alarm in a nuclear plant. Risk management includes identication of the risk; determining the probability, cost, or threat of the risk; and taking action to eliminate, reduce, or accept the risk. Risk and its treatment is a necessary topic in the project plan and may deserve its own risk management plan.
SQM
12
Software Quality Assurance
Software Quality Assurance is an umbrella activity that is applied throughout the software process.Quality assurance consists of the auditing and reporting procedures used to provide management with data needed to make proactive decisions. SQA does this by checking that: - plans are dened according to standards; - procedures are performed according to plans; - products are implemented according to standards. Quality assurance plan is the central aid for planning and checking the quality assurance. Quality assurance system is the organizational structure, responsibilities, procedures, processes and resources for implementing quality management. Conformance to software requirements is the foundation from which software quality is measured.Software must conform to implicit requirements (ease of use, maintainability, reliability, etc.) as well as its explicit requirements.
SQA Group Activities - 1
1. Prepare SQA plan for the project. 2. Participate in the development of the projects software process description. 3. Review software engineering activities to verify compliance with the dened software process.
SQA Group Activities - 2
1. Audit designated software work products to verify compliance with those dened as part of the software
SQM 13
process. 2. Ensure that any deviations in software or work products are documented and handled according to a documented procedure. 3. Record any evidence of noncompliance and reports them to management.
SQA Group Plan
Evaluations to be performed. Audits and reviews to be performed. Standards that are applicable to the project. Procedures for error reporting and tracking. Documents to be produced by the SQA group. Amount of feedback provided to software project team.
SQA Group Activities
Participates in the development of the projects software process description Reviews software engineering activities to verify compliance with the dened software process. Audits designated software work products to verify compliance with those dened as part of the software process. Ensures that deviations in software work and work products are documented and handled according to a document procedure. Records any non-compliance and reports to senior management.
SQM 14
2.1
Software Quality Control
Software Reviews
Software reviews are important SQA activities. Filter for the software engineering process Purify the software work products that occur as a result of analysis, design, and coding. Achieve technical work of more uniform, greater and more predictable quality. Detect errors and problems at the earliest possible time.
2.1 Software Quality Control
The function of software quality that checks that the project follows its standards, processes, and procedures, and that the project produces the required internal and external (deliverable) products. Software Quality Control is the set of procedures used by organizations to ensure that a software product will meet its quality goals at the best value to the customer, and to continually improve the organizations ability to produce software products in the future. Software quality control refers to specied functional requirements as well as non-functional requirements such as supportability, performance and usability. It also refers to the ability for software to perform well in unforeseeable scenarios and to keep a relatively low defect rate. These specied procedures and outlined requirements leads to the idea of Verication and Validation and software testing.
SQM 15
It is distinct from software quality assurance which includes audits of the quality management system against a standard. Software quality control is a control of products, Software quality assurance is a control of processes.
Reliability
Software Reliability is the probability of failure-free software operation for a specied period of time in a specied environment. Software Reliability is also an important factor aecting system reliability. It diers from hardware reliability in that it reects the design perfection, rather than manufacturing perfection. The high complexity of software is the major contributing factor of Software Reliability problems. Software Reliability is an important to attribute of software quality, together with functionality, usability, performance, serviceability, capability, installability, maintainability, and documentation. Once a software system is functioning, as specied, and delivered the reliability characteristic denes the capability of the system to maintain its service provision under dened conditions for dened periods of time. One aspect of this characteristic is fault tolerance that is the ability of a system to withstand component failure. For example if the network goes down for 20 seconds then comes back the system should be able to recover and continue functioning.
SQM
16
Maintainability
The ability to identify and x a fault within a software component is what the maintainability characteristic addresses. In other software quality models this characteristic is referenced as supportability. Maintainability is impacted by code readability or complexity as well as modularization. Anything that helps with identifying the cause of a fault and then xing the fault is the concern of maintainability. Also the ability to verify (or test) a system, i.e. testability, is one of the subcharacteristics of maintainability. 5 Testability
Testability is the degree that characteristics that provide for testing exist, and the degree to which economically feasible tests can be devised for determining whether the developed software will satisfy the requirements. 6 Veriability
Veriability is the measure of eort to verify (via tests, inspection, demonstration and analysis) specied software. 7 Safety
The discipline of software safety is a systematic approach to identifying, analyzing, tracking, mitigating and controlling software hazards and hazardous functions (data and commands) to ensure safe operation within a system.
SQM
17
Supportability
Which may include testability, extensibility, adaptability, maintainability, compatibility, congurability, serviceability, installability. 9 Historical Perspective Elements Of QMS
There are three main historical perspectives to quality management: Demings conformity and dependability Demings approach to quality is orientated around the customer. Deming is highly credited for Japans road to manufacturing success. He is credited for the quality approaches adopted by Japanese manufacturing industry that ensured its dominance of manufacturing for the greater part of three decades. Demings approach was that quality improvement lay in the ability to control and manage systems and processes properly. This involved the use of readily available existing technology and common sense. Deming advocates Statistical Process Control (SPS) for improving and removing variation within processes. This is done through the identication and subsequent removal of common causes of failures. Deming emphasises senior management responsibility in taking the lead to change processes and systems. He also promotes employee participation in decision making. Overall, Demings approach to quality management can be described as people focused also. Deming suggested 14 points for managing quality.
SQM
18
Demings 14 quality management points. 1. Constancy of purpose 2. A new philosophy 3. Cease dependence on inspections 4. End lowest tender contracts 5. Improve every process 6. Institute training on job 7. Institute leadership 8. Drive out fear 9. Break down barriers 10. Eliminate exhortations 11. Eliminate targets 12. Permit pride of workmanship 13. Encourage education 14. Create top management structures Jurans tness for purpose Similar to Deming, Jurans approach to quality management and improvement advocates the use of Statistical Process Control. Juran also places strong emphasis on people.
SQM
19
Juran advocates 10 points for improving software quality 1. Build awareness of need and opportunity for improvement. 2. Set goals for improvement. 3. Organize to reach goals. 4. Provide training. 5. Carry out projects to solve problems. 6. Report progress. 7. Give recognition. 8. Communicate results. 9. Keep score. 10. Maintain momentum by making annual improvement part of the regular process of the company. Deming and Jurans approaches advocate the use of Statistical Process Control (SPC) techniques to manage quality. Crosbys zero defects approach. Crosbys approach to quality management focuses on PREVENTION. Crosby suggests that quality is achieved through the preventative measures that are instituted in a system. Crosbys approach to quality management is sometimes known as the zero defect approach to quality management. Crosby also shares common themes with Juran and Deming in terms of his emphasis on quality improvement.
SQM
20
Crosby provides 14 steps to quality improvement. 1. Make it clear that management is committed to quality. 2. Form quality improvement teams with each department committed. 3. Determine where current and potential problems lie. 4. Evaluate the cost of quality and explain its use as a tool. 5. Raise the quality awareness and concerns of all employees. 6. Take actions to correct problems identied. 7. Establish a committee for zero defects programme. 8. Train supervisors to actively carry out their role in quality improvement. 9. Hold a zero defects day for all employees to highlight the changes. 10. Encourage individuals to establish improvement goals. 11. Encourage communication with management about obstacles to improvement. 12. Recognize and appreciate participants. 13. Encourage education. 14. Create top management structures.
SQM
21
QMS: Quality management system The International Standard Organization ISO denes a Quality Management system as: The organizational structure, responsibilities, procedures, processes and resources for implementing quality management . The QMS provides a structure to ensure that the process is carried out in a formal and systematic way. Elements of a QMS The International Standards Organization (ISO) denes a quality management system as having the following components: Organizational structure Responsibilities Procedures Processes Resources The four principal aspects of a QMS for software All the concepts of QMS discussed above apply to software. However, writers like Gilles (1997) suggest that there are four principal aspects to a quality management system for software development. These are:
SQM
22
Development procedures Should include the use of software design and development methodologies and tools. It should also include software testing methodologies and tools. Above all, development procedures for software should also specify a programme for training software development sta in the use of these methodologies and tools. Quality control Quality control is a series of activities designed to monitor quality during the development of software.These activities include planning, progress meeting, conguration management, documentation control and design reviews. Quality improvement A QMS for software should specify all the activities that are aimed at establishing a human quality culture amongst software developers. These activities include quality forums, quality improvement teams and other similar activities. Quality assurance Quality assurance is the monitoring of a QMS to ensure that it is being carried out properly. Quality assurance is ongoing. In eect, QA is a way of ensuring that the quality deliverables are being met.Personnel who are independent of the software development operations and are usually from a cross section of sta usually carry it out. These may be from senior management to grassroots practitioner groups.
SQM
23
Figure 5: Plan-Check-Do-Act cycle
SQM
24
10
Human Factor:
There are two important parts to a QMS. There are the tools and procedures, discussed above, and then there are the people. The procedures, tools and techniques are only there to enable the people to achieve a quality result. Sta acceptance is therefore vital. This will not happen by itself. The management of change is critical to the success of the process. The danger is that the introduction of a QMS by management will be seen as the imposition of new working practices. The system can only work if sta perceives the benets to themselves. These include the potential for: Greater job satisfaction Less time spent on pointless activity Greater pride in work More group participation More sta input into the way they do their job. However, Oakland points out that sta will not be well motivated towards a quality programme in the absence of top management commitment and action, organizational quality climate and a team approach to quality problems. It is particularly important that communication is a twoway process. For sta to be motivated, they must feel involved and that their contribution and ideas will make a dierence.One of the principal means of getting sta involved is through the use of quality circles.
SQM 25
A quality circle is a group of workers who are asked, not told, to join. They will generally have a trained leader, who might be their foreman or line manager. There should be an overall supervisor to co-ordinate the whole quality circle programme throughout an organization. Finally, management must be committed to the programme. Whilst they retain the right and obligation to manage, they must not reject recommendations without good reason or they will strangle the idea at birth. Quality circles are generally made up of between three and 15 people. Larger than this and the group become fragmented, with some members opting out. The author strongly recommends a group size in single gures to obtain maxi mum benet. They are better if held at a site away from the work area. Optimum frequency of meeting appears to vary from one to three weeks, depending upon the problems under consideration.
SQM
26
Figure 6: Quality Chain
SQM
27
Top down or Bottom Up The top-down force is the desire to manage . Management is absolutely necessary; it is not possible to achieve quality by committee. Without rm management, there will be no policy, no strategy, no consistency in decision-making, and chaos will ensue. However, there is a clear need to feed ideas up the organization. A quality culture will actually increase the ow of ideas from the work force. Strong management can verge on autocracy. People with ideas which conict with those of management can be seen as trouble makers. A perception that the last person to have an idea was sacked for it will not encourage others to come forward. There are no clear rules on this. A balance between structure, direction and policy on the one hand and innovation, lateral thinking and creativity on the other is required. Views of quality which emphasize conformance in components can too easily lead to an emphasis on conformance when dealing with sta. There is a time for doing things by the book and a time for not. One of the best denitions of an expert is some one who knows when the rule book can be safely discounted.
SQM
28
Managing people: the rst stereotype The rst stereotypical character we shall consider is the cynic. They have been there, seen it, done it and heard it all before. They appear to have been at Deming s inaugural lecture in Japan and they know that it won t work. This sort of person can be very destructive in many situations. However, they can also oer much: They are usually experienced sta with a wealth of experiential knowledge which could be usefully exploited. The role of devil s advocate can be an extremely useful one, particularly in the situation where outside consultants have been employed. They are likely to become strong advocates of good practice if they can be convinced. How often have you heard, Well, of course, I always thought ... shortly after a U-turn of amazing proportions? One strategy is to try to carve out a role for such a person who exploits their strengths of experience and scepticism whilst trying to insulate many other younger impressionable sta from their negative attitude. Many such people will thrive on being given such a role.
SQM
29
The second stereotype: the enthusiast Enthusiasm is a valuable commodity but it can cause as many headaches as it solves. Enthusiasm tends to be short-lived. People who become enthusiastic tend to get bored and move onto the next idea that comes along. Enthusiasm can also lead people to be uncritical and not to see potential pitfalls until it is too late. It might seem an attractive proposition to put our enthusiast and cynic together, as the best of both would be almost ideal. However, such a combination is likely to be destructive before it ever bears fruit. Rather than put the two together it is often more useful to allow their inuences on a group of people to balance each other out. If this can be achieved without bringing the two bodies together in an explosive combination, then the net eect may be benecial. The role of the enthusiast should be to feed other people with ideas and enthusiasm. The ideas remaining are likely to be both useful and sustaining. It is rare though very valuable to nd a creative enthusiast with the potential to develop their ideas. Fortunately, perhaps, most people fall between our two stereotypical images. However, the balance between nurturing creativity and maintaining structure can be tricky. Ensuring that everyone has a role to play in a work force aiming quality is a challenge and reinforces the
SQM 30
views of all three gurus that ultimately the buck stops with senior management. QMS For Software Quality Assurance Quality assurance is not a phase of the quality plan; it is an ongoing process to ensure that the plan is being carried out according to the procedures laid down. It should also have a role in monitoring the eectiveness of procedures intended to establish a quality culture. The role of quality assurance is to ensure that the quality of the procedures and processes results in a product that fully meets the users requirements. As such it is suggested that the QA function be carried out by an independent group of people whose function is solely to monitor the implementation of the quality plan, under the rst three headings. The group will require as far as possible a crosssection of both management and technical expertise. It should also include representatives of dierent levels of the company.
TQM: Total quality management
TQM is described by Oakland (1989) as A method for ridding peoples lives of wasted eort by involving every body in the process of improving the eectiveness of work, so that results are achieved in less time. TQM is often misunderstood, perhaps because of the publicity that Crosby s zero defects idea has attracted.
SQM 31
In the mind of the author, total quality management refers to the involvement of all people and all processes within the quality management exercise. It does not imply, promise or guarantee perfection. Quality Assurance or Quality improvement? -The historical origins of quality management in the work of Deming, Juran and others clearly demonstrate the crucial role of quality improvement. - It is not enough to monitor current levels of quality or to inspect your product and eliminate those failing to meet a specication. -The process improvement cycle is crucial to any quality initiative, since it is from reducing waste and improving quality that most economic benet is derived. -One manifestation of quality improvement is the Japanese concept of Kaizen. -In some ways, Kaizen is just another successor to TQM in those circles where TQM is now considered pass, but it has something to oer because of its emphasis upon improvement as well as inspection.
Kaizen
Quality assurance is dened by theJ I S as A manufacturer s systematic activities intended to ensure that quality fully meets consumer needs. JIS (Japanese Industrial Standards)
SQM
32
This may be compared with the US IEEE/ANSI denition which emphasizes conformity to specication and replaces full satisfaction with adequate condence : A planned and systematic pattern of all activities to provide adequate condence that the item or product conforms to established technical requirements. (IEEE/ANSI) This customer-centered view as opposed to a processcentered view is at the heart of Kaizen. Too many engineers (software or otherwise), Kaizen may seem more like a mystic religion than an approach to quality. Huda and Preston (1992) describe it thus: Kaizen is a holistic approach to problem solving and its difference lies in being people- centered rather than system-centered. It recognizes the over riding importance of the human element and gives a new perspective to problem solving by minimizing conict and of eliminating blame, so that people work together instead of individually towards goals. Imai (1986) represented Kaizen as an overarching umbrella. Because Kaizen is a philosophy rather than a particular set of methods, it is dicult to compare it with other approaches. Indeed, many of the techniques used are common to other approaches. What mark Kaizen out are its emphasis on small group co-operative working and the emphasis upon worker suggestions, which may be seen in the following mini case study from Fujitsu in Japan, reported by Itakura and Takei (1994).
SQM
33
11
The ISO9000 series:A Generic quality management standard
The 1SO9000 series of standards are the international standards dened to quality management systems. The series dates from 1979, when BS 5750 are introduced in the UK. In 1987, the corresponding ISO, BS and EN standard were harmonized to produce three identical series of standards. In this text, shall use the ISO numbers for consistency. Minor modications were introduced in 1994. Applied within software development. 1S09002 is intended for many manufacturing situations where the product is produced to a predened specication and 1SO9001 for easy applications where the quality can be determined by a simple nal inspection and testing procedure. ISO9000 provides guidance on which standard to adopt and 1SO9004 assistance on how to establish a QMS which meets the requirements of the ISO9000 series. In their report on Software Standards commissioned by the DTI for the UK. Government,Logica(1988) made the following recommendations regarding the Adoption of 1SO9001: Standards for software should be harmonized, using BS 5880 as a basis. In the medium term, ISO9001 should be tailored to take account of the specic needs of software. An authoritative guide to the application of ISO9001 to software is required.
SQM 34
Associated methods and tools should be brought into line with ISO9001. Increased condence in certication is required. 1S09001 should be promoted throughout the UK. However, the author s own consultation with IT professionals suggests that the widespread adoption of the standard faces a number of problems. Suppliers are skeptical about the benets in a number of ways. 1S09001 is perceived, erroneously, as a manufacturing standard. Suppliers do not think a manufacturing standard is appropriate to IT. They do not believe that accreditation to the standard will bring sucient competitive advantage. They dont think their customers will have heard of it and even when they have heard of it, customers may be skeptical about the benets, especially if they are asked to pay a higher price for better quality. This is discussed further at the end of the chapter when quantitative evidence - of the take-up rate of ISO9000 standards in the UK is explored. In the UK currently, the situation is being driven by those suppliers whose customers are insisting on accreditation as a prerequisite for bidding for con tracts. For many years, the MOD has operated its own AQAP accreditation scheme, which it is now hoped can be harmonized with the ISO standards. he MOD and other government agencies are asking for accreditation of all suppliers, and this is forcing many suppliers to pursue accreditation.
SQM 35
The contents of the standard
In this section, we shall deal with the requirements of the 1SO9001 standard. The 1SO9002 and 1SO9003 standards may be thought of as subsets of the 1SO9000 standard, and in any case most software applications will require the full range of 1SO9001 activity. The standard is based around a model specication for a quality management System. This underlying model is based around two fundamental principles: Right rst time. Fitness for purpose The standard is intended to be realistic and implement able and, therefore, sets no prescriptive quality performance targets, referring instead to standards agreed as part of the contract with the customer and acceptable to them. The standard focuses upon ensuring that procedures are carried out in a systematic. Way and that the results are documented, again in a systematic manner. Those clauses also found in 1S09002 and 1S09003 are marked with a tick in the right-hand columns. It should be noted that in 1S09003, some of the clauses are simplied Standards. 12 Tools for Quality
Here follows a brief description of the basic set of Total Quality Management tools. They are:
SQM 36
1. Pareto Principle 2. Scatter Plots 3. Control Charts 4. Flow Charts 5. Cause and Eect , Fishbone, Ishikawa Diagram 6. Histogram or Bar Graph 7. Check Lists 8. Check Sheets
Pareto Principle
The Pareto principle suggests that most eects come from relatively few causes. In quantitative terms: 80% of the problems come from 20% of the causes (machines, raw materials, operators etc.); 80% of the wealth is owned by 20% of the people etc. Therefore eort aimed at the right 20% can solve 80% of the problems. Double (back to back) Pareto charts can be used to compare before and after situations. General use, to decide where to apply initial eort for maximum eect.
SQM
37
Figure 7: Pareto principle
Scatter Plots
A scatter plot is eectively a line graph with no line i.e. the point intersections between the two data sets are plotted but no attempt is made to physically draw a line. The Y axis is conventionally used for the characteristic whose behavior we would like to predict. Use, to dene the area of relationship between two variables. Warning: There may appear to be a relationship on the plot when in reality there is none, or both variables actually relate independently to a third variable.
SQM
38
Figure 8: Scatter Plots
Control Charts
Control charts are a method of Statistical Process Control, SPC. (Control system for production processes). They enable the control of distribution of variation rather than attempting to control each individual variation. Upper and lower control and tolerance limits are calculated for a process and sampled measures are regularly plotted about a central line between the two sets of limits. The plotted line corresponds to the stability/trend of the process. Action can be taken based on trend rather than on individual variation. This prevents overcorrection/compensation for random variation, which would lead to many rejects.
SQM
39
Figure 9: Control Charts
SQM
40
Flow Charts
Pictures, symbols or text coupled with lines, arrows on lines show direction of ow. Enables modelling of processes; problems/opportunities and decision points etc. Develops a common understanding of a process by those involved. No particular standardization of symbology, so communication to a dierent audience may require considerable time and explanation.
SQM
41
Figure 10: ow chart
Cause and Eect , Fishbone, Ishikawa Diagram
The cause-and-eect diagram is a method for analyzing process dispersion. The diagrams purpose is to relate causes and eects. Three basic types: Dispersion analysis, Process classication and cause enumeration. Eect = problem to be resolved, opportunity to be grasped, result to be achieved. Excellent for capturing team brainstorming output and for lling in from the wide picture. Helps organize and relate factors, providing a sequential view. Deals with time direction but not quantity. Can become very complex. Can be dicult to identify or demonstrate interrelationships.
SQM
42
Figure 11: Fishbone, Ishikawa
SQM
43
Histogram or Bar Graph
A Histogram is a graphic summary of variation in a set of data. It enables us to see patterns that are dicult to see in a simple table of numbers. Can be analyzed to draw conclusions about the data set. A histogram is a graph in which the continuous variable is clustered into categories and the value of each cluster is plotted to give a series of bars as above. The above example reveals the skewed distribution of a set of product measurements that remain nevertheless within specied limits. Without using some form of graphic this kind of problem can be dicult to analyze, recognize or identify.
SQM
44
Figure 12: Histogram or Bar Graph
Check Sheets
A Check Sheet is a data recording form that has been designed to readily interpret results from the form itself. It needs to be designed for the specic data it is to gather. Used for the collection of quantitative or qualitative repetitive data. Adaptable to dierent data gathering situations. Minimal interpretation of results required. Easy and quick to use. No control for various forms of bias - exclusion, interaction, perception, operational, non-response, estimation.
SQM
45
Check Lists
A Checklist contains items that are important or relevant to a specic issue or situation. Checklists are used under operational conditions to ensure that all important steps or actions have been taken. Their primary purpose is for guiding operations, not for collecting data. Generally used to check that all aspects of a situation have been taken into account before action or decision making. Simple, eective.
SQM
46

Unit 3

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Unit 3

Hochgeladen von

Copyright:

Verfügbare Formate

Unit 3

Elements of Quality Engineering

Figure 1: SDLC reviews

Figure 2: Simplied test process

Figure 3: Typical change procedure

Software Quality Assurance

SQA Group Activities - 2

SQA Group Plan

Software Quality Control

Figure 5: Plan-Check-Do-Act cycle

Figure 6: Quality Chain

The ISO9000 series:A Generic quality management standard

The contents of the standard

Figure 7: Pareto principle

Figure 8: Scatter Plots

Figure 9: Control Charts

Figure 10: ow chart

Cause and Eect , Fishbone, Ishikawa Diagram

Figure 11: Fishbone, Ishikawa

Histogram or Bar Graph

Figure 12: Histogram or Bar Graph

Das könnte Ihnen auch gefallen