Statistical control

Many organizations use statistical process control to bring the organization to Six Sigma levels of quality, in other words, so that the likelihood of an unexpected failure is confined to six standard deviations on the normal distribution. This probability is less than four one-millionths. Items controlled often include clerical tasks such as order-entry as well as conventional manufacturing tasks.

Traditional statistical process controls in manufacturing operations usually proceed by randomly sampling and testing a fraction of the output. Variances of critical tolerances are continuously tracked, and manufacturing processes are corrected before bad parts can be produced.

Statistical Process Control (SPC) is an effective method of monitoring a method through the use of organizes charts. Organize charts allow the use of objective criteria for distinguishing background distinction from actions of impact based on statistical techniques. Much of its control lies in the capability to monitor both process center and its variation about that center. By collecting data from samples at various points within the process, variations in the process that may affect the quality of the end product or service can be detected and corrected, thus reducing waste as well as the likelihood that problems will be passed on to the customer. With its emphasis on early detection and prevention of problems, SPC has a distinct advantage over quality methods, such as inspection, that apply resources to detecting and correcting problems in the end product or service.

In addition to reducing waste, SPC can lead to a reduction in the time required to produce the product or service from end to end. This is partially due to a diminished likelihood that the final product will have to be reworked, but it may also result from using SPC data to identify bottlenecks, wait times, and other sources of delays within the process. Process cycle time reductions coupled with improvements in yield have made SPC a precious tool from both a cost reduction and a customer satisfaction standpoint.

History

Statistical Process Control was pioneered by Walter A. Shewhart in the early 1920s. The concept of quality control in manufacturing was first advanced by Walter Shewhart The first to apply the newly discovered statistical methods to the problem of quality control was Walter A. Shewhart of the Bell Telephone Laboratories. He issued a memorandum on May 16, 1924 that featured a sketch of a modern control chart. W. Edwards Deming later introduced SPC methods in the United States during World War II, thereby successfully improving quality in the manufacture of weapons and other strategically important products. Deming was also instrumental in introducing SPC methods to Japanese industry after the war had ended.

Shewhart formed the basis for the control chart and the concept of a state of statistical control by carefully designed experiments. While Dr. Shewhart drew from pure mathematical statistical theories, he understood that data from physical processes seldom produces a "normal distribution curve". He revealed that observed variation in manufacturing data did not always behave the same way as data in nature. Dr. Shewhart concluded that while every process displays variation, some processes display controlled variation that is natural to the process, while others display uncontrolled variation that is not present in the process causal system at all times .

In 1989, the Software Engineering Institute introduced the idea that SPC can be applied to non-manufacturing processes, such as software engineering processes, in the Capability Maturity Model (CMM). This idea exists today within the Level 4 and Level 5 practices of the Capability Maturity Model Integrated (CMMI).

General

In mass-manufacturing, the worth of the completed article was usually achieved through post-manufacturing inspection of the product; accepting or rejecting each piece based on how well it met its design specifications. In contrast, Statistical Process Control uses statistical tools to observe the performance of the production process in order to predict significant deviations that may later result in rejected product.

Two kinds of variation occur in all manufacturing processes. The first is known as natural or common cause variation and may be variation in temperature, difference in raw materials, voltage. This variation is minute, the observed values generally being quite close to the average value. The second kind of variation is known as special cause variation, and happens less frequently than the first.

How to Use SPC

Initially, one starts with a quantity of data from a manufacturing process with a definite metric, i.e. mass, length, surface energy of a widget. There should be upper threshold and lower threshold. The Upper threshold Limits of the process would be set to average plus three units and the Lower Control Limit would be set to average minus three units. The action taken depends on gauge and where each run lands on the SPC chart in order to control but not tamper with the process.

After some times other process-monitoring tools have been developed, including:

Cumulative Sum (CUSUM) charts: the ordinate of each plotted point represents the algebraic sum of the previous ordinate and the most recent deviations from the target.

Exponentially Weighted Moving Average (EWMA) charts: each chart point represents the weighted average of current and all previous subgroup values, giving more weight to recent process history and decreasing weights for older data.

Failure testing

Failure testing is an important part of the manufacturing process, no matter what are manufacturing. Failure testing is a way to ensure that the product and service that will not fail under different circumstances and situations of stress, weather, temperature, and so on and so forth. Continuous failure testing, even after a product is developed, will help you ensure that your manufacturing processes are on optimum possible way and that which continually improving the products and the services.

When a product fails, then examine those failures quickly so that the problem corrected. When failure testing is performing on a component that has failed, or just to test for a known failure, then it is very necessary to correlate the observations of a number of unusual aspects of the module: the appearance of the component or product, its composition, and its strength. Also keep in mind the design of the product, the operating conditions, the service environment, and the manufacturing record.

Failure testing measures enclose many of the same components and practices as failure examination. Failure analysis occurs after the fact, but failure testing strives to occur before the fact so that failure can hopefully be avoided by continually testing products and components so that they can be improved before they fail. It would be beneficial to you and your customers if you engage in failure testing on a regular basis, so that you can prevent any future problems. There are a number of different ways that you can go through failure testing; the best approaches to failure testing will be specific to your particular industry. A good overall approach to manufacturing processes, such as lean manufacturing or Six Sigma, will include failure testing as a part of its approach to industrialized process management.

Ensure the test to be conduct so that, to take into consideration material composition, the macro structure and the micro structure of the particular component, the distribution of hardness, the mechanical properties of the component, how well the element or the product resists deterioration, what happens when the product is put into prolonged contact with saline, the consequence of moisture on the product or the component, different environmental exposures, and what happens when the product is confronted with abrasives. It is advised to look carefully at fatigue, fracture testing, the flexural, yield, and ultimate strength of your product or component, the impact strength and corrosion resistance of every component of your product, and more.

Failure testing will help to ensure the quality of the products and the services. Regular failure testing will be a preventative measure than a necessarily corrective measure that occurs after the potentially disastrous fact. Quality within a business is usually defined in terms of the relation between the customer, the process or product, and the business.

Stress is a form of testing that is used to determine the stability of a given system or entity. It involves testing beyond normal operational capacity, often to a breaking point, in order to observe the results. Stress testing a subset of load testing

Stress testing is a form of testing that is used to determine the stability of a given system or entity. It involves testing beyond normal operational capacity, often to a breaking point, in order to observe the results. Stress testing may have a more specific meaning in certain industries.

Stress testing tries to smash the system under test by crushing its resources or by taking resources away from it it is sometimes called negative testing. The main purpose behind this madness is to make sure that the system fails and recovers gracefully -- this quality is known as recoverability.

I'm sure devious testers can enhance this list with their favorite ways of breaking systems.

Stress testing practices employed prior to the start of the crisis in four broad areas: (i) use of stress testing and integration in risk governance; (ii) stress testing methodologies; (iii) scenario selection; and (iv) stress testing of specific risks and products.

Quality assurance activitiy

Quality assurance covers all the activities including design, development, production, installation, servicing and documentation. The introduction of the rules: "fit for purpose" and "do it right the first time". It includes the guideline of the quality of raw materials, assemblies, products and components; services related to production; and management, production, and review processes.

One of the commonly used prototypes for QA management is the PDCA (Plan-Do-Check-Act) approach.

Plan–Do–Check–Act Cycle

The concept of the PDCA Cycle was originally developed by Walter Shewhart, the pioneering statistician who developed statistical process control in the Bell Laboratories in the US during the 1930's. It is often referred to as `the Shewhart Cycle'. It was taken up and promoted very effectively from the 1950s on by the famous Quality Management authority, W. Edwards Deming, and is consequently known by many as `the Deming Wheel'.

Description

The plan–do–check–act cycle (Figure 1) is a four-step model for carrying out change. It is just as a circle that has no end, the PDCA cycle should be repeated again and again for continuous improvement. Use the PDCA Cycle to coordinate your continuous improvement efforts. It both emphasizes and demonstrates that improvement programs must start with careful planning, must result in effective action, and must move on again to careful planning in a continuous cycle.

Figure 1: Plan-do-check-act cycle

When Plan-Do-Check-Act come into play?

It is a model of continuous improvement.

When the starting of a new improvement project.

When developing a new or improved design of a process, product or service.

When defining a repetitive work process.

When planning data collection and analysis in order to verify and prioritize problems or root causes.

When implementing any change.

Plan-Do-Check-Act Procedure

Plan. Recognize an opportunity and plan a change. Plan to improve your operations first by finding out what things are going wrong (that is identify the problems faced), and come up with ideas for solving these problems.

Do. Test the change. Carry out a small-scale study. Do changes designed to solve the problems on a small or experimental scale first. This minimises disruption to routine activity while testing whether the changes will work or not.

Study. Review the test, analyze the results and identify what you’ve learned. Check whether the small scale or experimental changes are achieving the desired result or not. Also, continuously Check nominated key activities (regardless of any experimentation going on) to ensure that you know what the quality of the output is at all times to identify any new problems when they crop up.

Act. Take action based on what you learned in the study step: If the change did not work, go through the cycle again with a different plan. Act to implement changes on a larger scale if the experiment is successful. This means making the changes a routine part of your activity.

. The diagram below lists the tools and techniques which can be used to complete each stage of the PDCA Cycle.

Quality Management Components

Quality Management Components

Quality control is a process engaged to make sure a certain level of quality in a product or service. It consists whatever actions a industry deems crucial to provide for the control and verification of certain characteristics of a product or service. The basic goal of quality control is to make sure that the products provided meet specific requirements.

Quality control involves the examination of a product for certain minimum levels of quality. The goal of a quality control team is to identify products that do not meet a company's specified standards of quality. If a problem is recognized, the job of a quality control team is like that the quality to prescribe to stop production temporarily. It depends on the particular product, type of problem identified.

Generally, it is not the job of a quality control team to correct quality issues. Other individuals, who are involved, discover the cause of quality issues and fix them. Once these kinds of problems are overcome, the product continues production or implementation as planned.

Quality control can cover not only products, services, and processes, but also people. Employees are an important part of the company. If a company has employees that don't have adequate skills or training, have trouble understanding directions, or are misinformed, quality may be severely diminished. When quality control is considered about human beings, it concerns correctable issues.

Often, quality control is confused with quality assurance. Even if the two are very similar, there are some basic differences. Quality control is concerned with the product and quality assurance is process oriented.

Even with such a clear-cut difference defined, identifying the differences among the two is hard. Basically, quality control involves evaluating a product. Quality assurance is designed to make sure processes are sufficient to meet objectives. Quality assurance ensures a product is manufactured, implemented, created, or produced in the right way. Quality control evaluates whether the end result is satisfactory.

Quality assurance (QA) is the activity of providing evidence needed to establish quality in work. The activities that require good quality are being performed effectively. All the systematic actions, which provide enough confidence, that a product will satisfy the given requirements for quality.

Requirements Testing

Requirements testing seem to be brief. They fly in and out of projects; they are unpredictable, inflexible and sometimes invisible. While gathering requirements we are looking for all the criteria for a system’s success. Some of the techniques Using gathering information for requirements testing are Blitzing, Rapid Application Development (RAD), Joint Application Development (JAD), Quality Function Deployment (QFD), interviewing, apprenticing, data analysis.

1. Abstract
Testing the software is an integral part of building a system. But if the software is based on inaccurate requirements, then with well written code software will be unsatisfactory.

2. The Quality Gateway:
As the requirement got singled out then testing can start. The aim is to catch requirements-related defects as early as identified. It would prevent from incorporating incorrect requirements in the design and implementation. To pass through the quality gateway, requirement must pass a number of tests. These tests are concerned about ensuring that the requirements are accurate. This will make sure that the requirement will not cause any problem in design and implementation in later stages.

3. Make the Requirement Measurable
There would be a quality measure for each requirement. Each requirement should have a quality measure that makes it possible to divide all solutions of the requirement into two classes: those which that fit into the requirement and those which that they do not fit into the requirement. In other words quality measure for a requirement means that any solution that meets the measure will be acceptable. Of course it is also true to say that any solution that does not meet the measure will not be acceptable. The quality measures are used for testing the new system against the requirements.

4. Quantifiable Requirements
Quantifiable requirement are those which the system respond quickly to customer enquiries. First thing to find a property of this requirement that provides us with a scale for measurement within the context.

5. Non-quantifiable Requirements
An attempt to define the quality measure for a requirement helps to rationalize fuzzy requirements. Something like “the system must provide good value” is an example of a requirement that everyone would agree with, but each person has his own meaning. By investigating the scale that must be used to measure “good value” identify the diverse meanings.

6. Coherency and Consistency
The requirements engineer has the intention that each requirement to be understood in the same way by every person who reads it. This subjectivity means that many systems are built to satisfy the wrong interpretation of the requirement. The obvious solution to this problem is to specify the requirement in such that it is understood in only one way.

Black Box Testing

Black box testing takes an external perspective of the test object to derive test cases. These test cases can be functional or non-functional. Usually functional test cases are called Black box testing. The test designer selects positive and negative cases and determines the adequate output. There is no information of the test object's internal formation.

1. Testing Strategies/Technique

* Black box testing should make use of randomly generated inputs, to eliminate any guess work by the tester as to the methods of the function.
* Data outside of the specified input range should be tested to check the robustness of the system.
* Boundary cases should be tested (top and bottom of specified range) to make sure the highest and lowest allowable inputs produce proper output
* The number zero should be tested when numerical data is to be input
* Stress testing should be performed, especially with real time systems
* Crash testing should be performed to see what it takes to bring the system down
* Test monitoring tools to track which tests have been performed and the outputs of these tests, to avoid repetition and to help in the software maintenance
* Other functional testing techniques include: Transaction testing, Syntax testing, Domain testing, Logic testing, and State testing.
* Finite state machine models can be used as a guide to design functional tests

2. Black Box Testing Strategy:

Black Box Testing is not a type of testing; it is a testing strategy. As the name "black box" indicates, no knowledge of internal logic or code structure is required. The types of testing under this strategy are totally based/focused on the testing for requirements and functionality of the work product/software application. Black box testing is sometimes also named as "Opaque Testing", "Functional/Behavioral Testing" and "Closed Box Testing".

The base of the Black box testing strategy lies in the selection of appropriate data as per functionality and testing against the functional specifications. It is becoming common to handle the Testing work to a third party as the developer of the system knows about the internal logic and coding of the system.

In order to implement Black Box Testing Strategy, the tester is needed to be thorough with the requirement specifications of the system and as a user, should know, how the system should behave in response to the particular action.

Various testing types that fall under the Black Box Testing strategy are: functional testing, stress testing, recovery testing, volume testing, User Acceptance Testing (also known as UAT), system testing, Sanity or Smoke testing, load testing, Usability testing, Exploratory testing, ad-hoc testing, alpha testing, beta testing etc.

These testing types are again divided in two groups

a) Testing in which user plays a role of tester and

b) User is not required.


3. Advantages

More effective on larger units of code.

Tester needs no knowledge of implementation.

Tester and programmer are independent of each other.

Tests are done from a user's point of view.

Will help to expose any ambiguities in the specifications

Test cases can be designed as soon as the specifications are complete.


4. Disadvantages

Only a small number of possible inputs can actually be tested.

Without clear and concise specifications, test cases are hard to design.

There may be redundant test inputs if the tester is not informed of test cases the programmer has already tried.

May leave many program, paths untested.

Cannot be directed toward specific segments of code, which may be very complex.

Prototype Model

A prototype is a working model that is functionally equivalent to a component of the product. In many instances the client only has a general view of what is expected from the software product. In the case of absence of detailed information regarding the input to the system, the processing needs and the output requirements, the prototyping model may be employed.
This model reflects increase the flexibility of the development process by allowing the client to interact and experiment with a working product model. The developmental process only continues once the client is satisfied with the functioning of the prototype. That time the developer come to know about clients real need.

Software prototyping

Software prototyping, is the creation of Beta versions, i.e., incomplete versions of the software program being developed.A prototype only contains a small subset of the features of the actual program, and the implementation is also not called robust.The purpose of a prototype is to allow users of the software to evaluate the design of the actual product by actually trying them out.

Benefits:
The software developer can obtain early feedback from the users. The client can compare if the software matches the software specification, according to which the software program is built. It will help to determine the developer to kept a goal of his own for the project.

Process of prototyping involves the following steps

1)Identify basic requirements
Determine basic requirements including the input and output information desired. Details, such as security, can typically be ignored.
2)Develop Initial Prototype
The initial prototype is developed that includes only user interfaces.
3) Review
The customers, including end-users, examine the prototype and provide feedback on additions or changes.
4) Revise and Enhancing the Prototype
Using the feedback both the specifications and the prototype can be improved.

Classifications

it can be classified as throwaway prototyping and evolutionary prototyping
Throwaway or Rapid Prototyping refers to the creation of a model that will eventually be discarded rather than becoming part of the finally delivered software.
The main goal when using Evolutionary Prototyping is to build a very robust prototype in a structured manner and constantly refine it.

Advantages

Reduced time and costs:
Improved and increased user involvement:

Disadvantages

Insufficient analysis:
User confusion of prototype and finished system:
Developer attachment to prototype:
Excessive development time of the prototype:
Expense of implementing prototyping:

Methods

Dynamic Systems Development Method (DSDM) is a framework for delivering business solutions that relies heavily upon prototyping as a core technique, and is itself ISO 9001 approved.
The four categories of prototypes as recommended by DSDM are:

• Business prototypes.
• Usability prototypes.
• Performance and capacity prototypes.
• Capability/technique prototypes.

Tools

Visual basic etc.