Six Sigma is a set of practices originally
developed by Motorola to systematically improve
processes by eliminating defects. A defect is
defined as nonconformity of a product or service
to its specifications.
While the particulars of the methodology were
originally formulated by Bill Smith at Motorola in
1986, Six Sigma was heavily inspired by six
preceding decades of quality improvement
methodologies such as quality control, TQM, and
Zero Defects. Like its predecessors, Six Sigma
asserts the following:
Continuous efforts to reduce variation in
process outputs is key to business success
Manufacturing and business processes can be
measured, analyzed, improved and controlled
Succeeding at achieving sustained quality
improvement requires commitment from the
entire organization, particularly from top-
DMAIC Basic methodology consists of the following five (5)
Define the process improvement goals that are consistent
with customer demands and enterprise strategy.
Measure the current process and collect relevant data for
Analyze to verify relationship and causality of factors.
Determine what the relationship is, and attempt to ensure
that all factors have been considered.
Improve or optimize the process based upon the analysis
using techniques like Design of Experiments.
Control to ensure that any variances are corrected before
they result in defects. Set up pilot runs to establish
process capability, transition to production and thereafter
continuously measure the process and institute control
Basic methodology consists of the following five steps:
Define the goals of the design activity that are consistent
with customer demands and enterprise strategy.
Measure and identify CTQs (critical to qualities), product
capabilities, production process capability, and risk
Analyze to develop and design alternatives, create high-
level design and evaluate design capability to select the
Design details, optimize the design, and plan for design
verification. This phase may require simulations.
Verify the design, set up pilot runs, implement production
process and handover to process owners.
Executive Leadership includes CEO and other key top
management team members. They are responsible for setting up
a vision for Six Sigma implementation. They also empower the
other role holders with the freedom and resources to explore
new ideas for breakthrough improvements.
Champions are responsible for the Six Sigma implementation
across the organization in an integrated manner. The Executive
Leadership draws them from the upper management. Champions
also act as mentors to Black Belts. At GE this level of certification
is now called "Quality Leader".
Master Black Belts, identified by champions, act as in-house
expert coaches for the organization on Six Sigma. They devote
100% of their time to Six Sigma. They assist champions and
guide Black Belts and Green Belts. Apart from the usual rigor of
statistics, their time is spent on ensuring integrated deployment
of Six Sigma across various functions and departments.
Experts This level of skill is used primarily within
Aerospace and Defense Business Sectors. Experts work
across company boundaries, improving services,
processes, and products for their suppliers, their entire
campuses, and for their customers. Raytheon Incorporated
was one of the first companies to introduce Experts to
their organizations. At Raytheon, Experts work not only
across multiple sites, but across business divisions,
incorporating lessons learned throughout the company.
Black Belts operate under Master Black Belts to apply Six
Sigma methodology to specific projects. They devote 100%
of their time to Six Sigma. They primarily focus on Six
Sigma project execution, whereas Champions and Master
Black Belts focus on identifying projects/functions for Six
Green Belts are the employees who take up
Six Sigma implementation along with their
other job responsibilities. They operate under
the guidance of Black Belts and support them
in achieving the overall results.
Yellow Belts are employees who have been
trained in Six Sigma techniques as part of a
corporate-wide initiative, but have not
completed a Six Sigma project and are not
expected to actively engage in quality
Test plan identifier;
Features to be tested;
Features not to be tested;
Item pass/fail criteria;
Suspension criteria and resumption
Staffing and training needs;
Risks and contingencies;
A software release is the distribution, whether
public or private, of an initial or new and
upgraded version of a computer software
product. Each time a software program or
system is changed, the software engineers
and company doing the work decide on how
to distribute the program or system, or
changes to that program or system.
The software release life cycle is composed of
different stages that describe the stability of
a piece of software and the amount of
development it requires before final release.
Each major version of a product usually goes
through a stage when new features are
added, or the alpha stage; a stage when it is
being actively debugged, or the beta stage;
and finally a stage when all important bugs
have been removed, or the stable stage.
Intermediate stages may also be recognized.
The stages may be formally announced and
regulated by the project's developers, but
sometimes the terms are used informally to
describe the state of a product.
Conventionally, code names are often used by
many companies for versions prior to the
release of the product, though the actual
product and features are rarely secret.
Sometimes a build known as pre-alpha is
issued, before the release of an alpha or beta.
In contrast to alpha and beta versions, the
pre-alpha is not "feature complete". When it
is used, it refers to all activities performed
during the software project prior to software
testing. These activities can include
requirements analysis, software design,
software development and unit testing.
In Open Source world, there are several types
of pre-alpha versions. Milestone versions
include specific sets of functionality and are
released as soon as the functionality is
complete. Nightly builds are versions that are
usually automatically checked out from the
revision control system and built, typically
over night; these versions allow the testers to
test the recently implemented functionality
immediately, and find the new bugs.
The alpha build of the software is the build
delivered to the software testers, that is
persons different from the software
engineers, but usually internal to the
organization or community that develops the
software. In a rush to market, more and more
companies are engaging external customers
or value-chain partners in their alpha testing
phase. This allows more extensive usability
testing during the alpha phase.
In the first phase of testing, developers
generally test the software using white box
techniques. Additional validation is then
performed using black box or grey box
techniques, by another dedicated testing
team, sometimes concurrently. Moving to
black box testing inside the organization is
known as alpha release.
beta version is the first version released
outside the organization or community that
develops the software, for the purpose of
evaluation or real-world black/grey-box
testing. The process of delivering a beta
version to the users is called beta release.
Beta level software generally includes all
features, but may also include known issues
and bugs of a less serious variety.
The users of a beta version are called beta
testers. They are usually customers or
prospective customers of the organization
that develops the software. They receive the
software for free or for a reduced price, but
act as free testers.
eta version software is likely to be useful for
internal demonstrations and previews to
select customers, but unstable and not yet
ready for release. Some developers refer to
this stage as a preview, a prototype, a
technical preview (TP) or as an early access.
As the second major stage in the release
lifecycle, following the alpha stage, it is
named after the Greek letter beta, the second
letter in the Greek alphabet
Developers release either a closed beta or an
open beta; closed beta versions are released
to a select group of individuals for a user
test, while open betas are to a larger
community group, usually the general public.
The testers report any bugs that they found
and sometimes minor features they would
like to see in the final version.