Quality Assurance

Quality Function Deployment: QFD is a practice for designing your processes in response to customer needs. QFD translates what the customer wants into what the organization produces. It enables an organization to prioritize customer needs, an improve processes to maximum effectiveness. QFD is a practice that leads to process improvements that enable an organization to exceed the expectations of the customer.

Benefits of QFD:
Customer-focused: A total-quality organization is a customer-focused organization.

Time-efficient: QFD can reduce development time because it focuses on identified customer requirements.

Teamwork -orientated: All decisions in the process are based on consensus and involve in-depth discussion and brainstorming.

Documentation-orientated: One of the products of the QFD processes a comprehensive document that pulls together all pertinent data about all processes and how they stack up against customer requirements.

Basic QFD Tools:
- Affinity Diagram
- Interrelationship Digraph
- Tree Diagram
- Matrix Diagram

Creating an Affinity Diagram:

- A team of employees familiar with the issue is formed.
- The issue to be discussed is stated without detail.
- Responses of participants are stated verbally and recorded on 3 by 5 cards.
- The cards are spread on a large table, and participants are asked to group cards containing related ideas. Cards that don’t fit any particular group can be grouped as miscellaneous.
- Participants try to find a heading that describes each group.
- The information on the cards is replicated on paper with boxes around each group of ideas.

Interrelationship Digraph:

- Write the problem statement on a 3 by 5 card.

- Place the problem statement card in the upper left corner of a table. Take out all the cards used to develop the Affinity diagram and lay them on the table. Place the card most closely associated with the problem closest to the problem card. Continue on with the next closest until cards are used up.

- When the cards are all laid out, recreate them on paper. Distribute copies of the paper to the group for discussion. The group then makes a final arrangement.

- Distribute the final version to participants and ask them to draw arrows showing what contributes to what. This is the step in which relationships between and among causes are established.

Tree Diagram:

- Clearly identify the problem to be solved. It can be taken from the affinity diagram or from the interrelationship digraph. Write it on a card and place it on the left side of a table.

- Conduct a brainstorming session in which participants record on 3 by 5 cards all possible tasks, methods, and activities relating to the problem. Repeat the question “In order for this to happen, what must happen first?” Continue until all ideas are exhausted.

- Lay all cards on table to the right of the problem card. Put them in order based on what must happen first.

- Duplicate the cards on paper and distribute copies to all participates. All participates are to revise and correct the document.

Matrix Diagram: It is a helpful tool for identifying and graphically displaying connections among responsibilities, tasks, functions, and so forth.

Implementing QFD:
- Form the Project Team
- Establish Monitoring Procedures
- Select a Project
- Conduct a “Kick Off” Meeting
- Train the Team
- Develop the Matrices

Select a Project: It is a good idea to begin with an improvement project. Team members who are not familiar with QFD are at least familiar with the product.

Conduct a “Kick-Off” Meeting:

- Make sure all participants understand the mission of the project team.
- Make sure all participates understand their role on the the team.
- Establish parameters – (length, time, and frequency of meeting).

Train the Team: Team members should learn how to use QFD tools and how the QFD process works.

Develop the Matrices.

Defect: From the producer’s viewpoint, a defect is a product requirement that has not been met, or a product attribute possessed by a product or a function performed by a product that is not in the statement of requirements that define the product. From the customer’s viewpoint, a defect is anything that causes customer dissatisfaction, whether in the statement of requirements or not.

Policy: Managerial desires and intents concerning either processes (intended objectives) or products (desired attributes).

Procedure: The step-by-step method followed to ensure that standards are met.

Process
1. The work effort that produces a product. This includes efforts of people and equipment guided by policies, standards, and procedures.

(2) A statement of purpose and an essential set of practices (activities) that address that purpose. A process or set of processes used by an organization or project to plan, manage, execute, monitor, control, and improve its software related activities.

Productivity: The ratio of the output of a process to the input, usually measured in the same units. It is frequently useful to compare the value added to a product by a process, to the value of the input resources required (using fair market values for both input and output).

Quality: Operationally, the word quality refers to products. A product is a quality product if it is defect free. To the producer, a product is a quality product if it meets or conforms to the statement of requirements that defines the product. This statement is usually shortened to: quality means meets requirements. To the customer, a product is a quality product if it meets the customer’s needs, regardless of whether the requirements were met. This is referred to as fit for use.

Quality – Producer View: The producer’s view of quality has these four characteristics: Doing the right thing, Doing it the right way, Doing it right the first time, and Doing it on time without exceeding cost.

Quality – Customer View: Meeting requirements is a producer’s view of quality. This is the view of the organization responsible for the project and processes, and the products and services acquired, developed, and maintained by those processes.

Standard: A requirement of a product or process. For example: 100 percent of the functionality must be tested.

Benchmarking: Benchmarking is the process of comparing and measuring an organization’s operations or its internal processes against those of a best-in-class performer from inside or outside its industry.

Process benchmarking is a systematic and continuous improvement process; a process of continually MEASURING and COMPARING an organization’s BUSINESS PROCESSES against business pro LEADERS anywhere in the world to gain INFORMATION which will help the organization take ACTION to IMPROVE its PERFORMANCE.

Key Points:

• Benchmarking is an increasingly popular improvement tool.
• Benchmarking concerns processes and practices.
• Benchmarking is a respected means of identifying processes that require major change.
• Benchmarking is done between consenting companies that may or may not be competitors.
• Benchmarking compares your process or practice with the target company’s best-in-class process or practice.
• The goal of benchmarking is to find “secrets of success” and then adapt and improve for your own application.

Benchmarking as it Relates to Continuous Improvement:

• Today’s competitive world does not allow time for gradual improvement in areas in which a company lags way behind.
• Benchmarking can tell a firm where it stands relative to best-in-class practices and processes, and which processes must be changed.
• Benchmarking provides a best-in-class model to be adopted, or even improved upon.
• Modern customers are better informed and demand the highest quality and lowest prices. Companies have a choice to either perform or go out of business.
• Benchmarking supports total quality by providing the best means for rapid, significant process/practice improvement.

Benchmarking Approach and Process:

• Obtain management commitment.
• Baseline your own processes.
• Identify your strong and weak process and document them.
• Select processes to be benchmarked.
• Form benchmarking teams.
• Research best-in-class.
• Select candidate best-in-class benchmarking partners.
• Form agreements with benchmarking partners.
• Collect data.
• Analyze data and establish the gap
• Plan action to close the gap/surpass.
• Implement change.
• Monitor.
• Update benchmarks; continue the cycle

Benchmarking Versus Re-Engineering: Process re-engineering should only be considered when it is impossible to use benchmarking.

• No known process available for benchmarking (rare).
• Best-in-class not willing to partner.
• Best-in-class inaccessible due to geography or expense

Role of Management in Benchmarking:

• For benchmarking to be productive, management must be committed to change.
• Management must provide the necessary funding.
• Management must allocate the appropriate personal.
• Information to be disclosed to benchmarking partners can only be cleared by management.
• Top level managers must themselves be directly involved in benchmarking activities.

Process Documentation:

• All people associated with the process should have a common understanding of it, and that can come only from documentation.
• A documented starting point is needed against which to measure performance improvement after benchmarking changes have been implemented.
• The organization will be dealing with people (the partners) who are not familiar with its processes. With an understanding of where the benchmarking organization is, the partner will be better able to help.

Settling for “OK-in-Class”: Reasons organizations too often choose benchmarking partners who are not best-in-class:

• The best-in-class is not interested in partnering.
• Research identified the wrong partner.
• The benchmarking company got lazy and picked a handy partner.

Obstacles to Successful Benchmarking:

• If a company is too internally focused it may not be aware that their processes are less efficient than best-in-class.
• An overly broad benchmarking objective can guarantee failure.
• Unrealistic timetables.
• Poor team composition–the people who use the process day in and day out, must be involved.
• Improper emphasis–A frequent cause of failure in benchmarking is that teams get bogged down in collecting endless data and put too much emphasis on the numbers.
• Insensitivity to partners–If you fail to observe protocol and common courtesy in all transactions, your organization runs the risk of being cut off.

BENCHMARKING CASE STUDY: XEROX (MANUFACTURING)

• Xerox’s success is the first one in the history of benchmarking.
• From a critical situation in 1972, Xerox became what we call today a “top benchmarking partner”.
• In 1979, Xerox starts benchmarking.
• In 1989, Xerox wins the Malcolm Baldrige National Quality Award.
• Product performance during the first 30 days of installation has increased 40%
• Manufacturing lead times have been reduced 50%.
• Manufacturing labor and material over-head rates have been improved by 31% and 46% respectively.
• Customer retention rate is 20% better than U.S. industry average
• A company wide performance measurement covering 240 key areas of product, service and business performance.
• The targets of world leaders.
• Tremendous gains in quality (78% defect reduction, increased reliability with 40% decrease in unscheduled maintenance, increased copy quality, 27% decrease in service response time).
• Significant reductions in labor and material over-heads.
• First company to offer three year product warranty.

Need for checklists:

In looking at current auditing standards, ISO 19011 makes reference to “Preparing work documents” in Clause 6.4.3. The following is an extract from this clause:

“The audit team members should review information relevant to their audit assignment and prepare work documents as necessary for reference and for recording audit proceedings. Such documents may include

• Checklists and audit sampling plans, and
• Forms for recording information, such as supporting evidence, audit findings and records of meetings.

The use of checklists and forms should not restrict the extent of audit activities, which can change as a result of information collected during the audit”

Whilst not always required in management system standards, audit checklists are just one tool available from the “auditors toolbox”. Many organizations will use them to ensure that the audit at a minimum will address the requirements as defined by the scope of the audit.

There can be different approaches audit for ISO 9001:2000. For example:

• Audit from the organization’s Quality Management System to the ISO 9001:2000 requirements.
• Use of checklist to audit from the requirements to the organization’s management system.

However, it is beneficial to audit from the organization’s quality management system up to the requirements. A checklist may be used to ensure that all relevant ISO 9001 requirements addressed.

1. Checklists if developed for a specific audit and used correctly:

• Promote planning for the audit
• Ensure a consistent audit approach.
• Act as a sampling plan and time manager.
• Serve as a memory aid. Provide a repository for notes collected during the audit process (audit field notes).

2. Audit checklists need to be developed to provide assistance to the audit process.

3. Auditors need to be trained in the use of a particular checklist and be shown how to use it to obtain maximum information by using good questioning techniques.

4. Checklists should assist an auditor to perform better during the audit process.

5. Checklists help to ensure that an audit is conducted in a systematic and comprehensive manner and that adequate evidence is obtained.

6. Checklists can provide structure and continuity to an audit and can ensure that the audit scope is being followed.

7. Checklists can provide a means of communication and a place to record data for use for future reference.

8. A completed checklist provides objective evidence that the audit was performed.

9. A checklist can provide a record that the QMS was examined.

10. Checklists can be used as an information base for planning future audits.

11. Checklists can be provided to the auditee ahead of the on-site audit.

Disadvantages of using audit checklists:

1. The checklist can be seen as intimidating to the auditee.
2. The focus of the checklist may be too narrow in scope to identify specific problem areas.
3. Checklists are a tool to aid the auditor, but will be restrictive if used as the auditor’s only support mechanism.
4. Checklists should not be a substitute for audit planning.
5. An inexperienced auditor may not be able to clearly communicate what he/she is looking for, if they depend too heavily on a checklist to guide their questions.
6. Poorly prepared checklists can slow down an audit due to duplication and repetition.
7. Generic checklists, which do not reflect the specific organizational management system, may not add any value and may interfere with the audit.
8. Narrow focused checklists minimize unique assessment questions / approach.

Conclusion: There are advantages and disadvantages in using audit checklists. It depends on many factors, including customer needs, time and cost restraints, auditor experience and sector scheme requirements. Auditors should assess the value of the checklist as an aid in audit process and consider its use as a functional tool.

1. A help desk in a network control organization received the following problems during a day and the network administrator resolved them as follows:

• Terminal Keyboard locked
• Terminal 123x is hung
• Terminal shows no cursor on the screen
• Unable to start a session
• Unable to print from e-mail
• Terminal 324x can’t access menu

You have been assigned to lead a quality improvement team to improve the help desk process. Briefly describe the steps in your quality improvement process, then briefly execute theses steps to illustrate the execution of each step. As you execute your quality improvement process steps, perform any analysis needed and indicate any conclusion/ recommendations that result from your analysis.

At a minimum, you should define and quantify the problem(s), suggest a cause and a solution to the problem needed.

Q2. Where do you think the usual mistakes in a software development cycle arise from?

Q3. What are the 4 phases of team building? How will you solve the problems those will appear in the team building process?

Q4. The managers are of the opinion that the team shall not perform reviews on the products they produce, but have external persons doing it to have additional checks on their team’s work. Also, this would help ease project pressure. How would you react and why?

Q5. Identify the internal customers and their relevant work product(s) in each stage of SDLC other than the final/end user.

Q6. A potential customer of your organization requires software that can be provided only with new tools/technology, not currently available in your organization. Your management has decided to accept the contract. How should the project be planned for successful completion?

Q7. Give Suitable metrics for

• Usability
• Defects
• Maintainability
• Customer Satisfaction
• Software Reliability
• Completeness of testing
• Process Quality
• Product Quality
• Management’s Commitment to Quality
• Training
• Scalability Portability

Also See:

• CSQA Subjective questions sample paper – 2

The revision of ISO 9001:2000 to ISO 9001:2008 did not bring in drastic additions. Its changes seek to make clarification in relevant clauses based on the vast application experiences from the various industrial sectors.

Changes are the following clauses: (Soon, I’ll provide the complete details)

Clause 0.1

Clause 0.4

Clause 1

Clause 2

Clause 3

Clause 4.1

Clause 4.2.1

Clause 4.2.3

Clause 5.1

Clause 5.5.2

Clause 6.2.1

Clause 6.2.2

Clause 6.3

Clause 6.4

Clause 7.1

Clause 7.2.1

Clause 7.3.1

Clause 7.3.3

Clause 7.5.3

Clause 7.5.4

Clause 7.5.5

Clause 7.6

Clause 8.2.1

Clause 8.2.2

Clause 8.2.3

Clause 8.2.4

Clause 8.3

There are many different steps that organizations follow in benchmarking. However, most baselining processes have these four steps:

1. Develop a clearly defined baseline in your organization: This means that all of the attributes involved in your baseline are defined. In our example of defects per lines of code, clearly defining what is meant by defect and a line of code would meet the objective of this step.
2. Identify the organizations you desire to baseline against: Many factors come into this decision, such as do you want to benchmark within your industry, do you want to benchmark what you believe are leading organizations, do you want to benchmark an organization that uses the same tools that are used in your organization, and do you want to benchmark against organizations with a similar culture.
3. Compare baseline calculations: Compare how your baseline is calculated versus the baseline calculation in the company you want to benchmark against. Benchmarking is only effective when you benchmark against an organization who has calculated their baseline using approximately the same approach that your organization used to calculate the baseline.
4. Identify the cause of baseline variance in the organization you benchmarked against: When you find a variance between the baseline calculation in your company and the baseline calculation in the organization you are benchmarking against, you need to identify the cause of variance. For example, if your organization was producing 20 defects per thousand lines of code, and you benchmarked against an organization that only had 10 defects per thousand lines of code you would want to identify the cause of the difference. If you cannot identify the cause of difference, there is little value in benchmarking. Let us assume that the company you benchmarked against had a different process for requirement definition than your organization. For example, assume they use JAD (joint application development) and you did not. Learning this, you may choose to adopt JAD in your organization as a means for reducing your developmental defect rates.

A less formal method for benchmarking is to visit other organizations. This will provide the quality professionals with these benefits:

1. The cost and effort to develop new and innovative quality approaches within IT is cost-prohibitive for most companies. Learn from others and don’t “reinvent the wheel”.
2. Comparing quality programs to those in other companies can identify gaps in current processes and lead to obtaining more effective quality practices.
3. Interfacing periodically with other quality individuals is good for professional development. Those colleagues will not exist internally unless the company is large.

Also See:

• Quality Baseline Study
• Conducting Objective and Subjecting Quality Baseline studies