Syntel CQA Forum Quality Principles in Nutshell Part I

CQA Doc No 1
Quality Principles  Plan-Do-Check-Act
 Definitions of Quality  Six Sigma
 Quality Concepts  Benchmarking
 Quality Objectives  Continuous Improvement
 Quality Attributes  Best Practices
 QA v/s QC Software Quality Concepts
 Quality Pioneers  Quality is conformance to product
requirements and should be free.
 Quality Vocabulary
 Quality is achieved through prevention
Definitions of Quality
of defects .
 Quality Software and Software Quality
 Quality control is aimed at finding
 Software that exhibits all the functional problems as early as possible and
capabilities and non-functional fixing them.
attributes that ensure that it can be put
 Doing things right the first time is the
to all its intended uses with the least
performance standard which results in
effort, inconvenience and resource cost
zero defects and saves the expenses of
to the user is Quality Software
doing things over.
 Software Product Evaluation lists six
 The expense of quality is
key factors in producing Quality
nonconformance to product
Software
requirements
♦ functionality
Software Quality Concepts
♦ reliability
 Quality is what distinguishes a good
♦ usability
company from a great one.
♦ efficiency
 Quality is meeting or exceeding our
♦ maintainability
customer's needs and requirements.
♦ portability
 Software Quality is measurable.
Definitions of Software Quality
 Quality is continuous improvement.
 "Quality is Conformance to
requirements" - CROSBY  The quality of a software product
comes from the quality of the process
 "Software Quality means fitness for
used to create it.
purpose" - OULD
Cost of Quality
 Quality is all the features that allow a
product to satisfy stated or implied  Quality costs are the costs associated
needs at an affordable cost - ISO-8402 with preventing, finding and correcting
defective work
Definitions of Software Quality
 One of the key functions of a quality
 GARVIN gives five views of Quality
engineer is the reduction of the total
♦transcendent cost of quality associated with a
♦ product-based product
♦ user-based Prevention Costs
♦ manufacturing-based  These are costs of activities specifically
♦ value-based designed to prevent poor
Conclusions quality(coding errors, design errors,
 It is generally accepted that quality of bad documentation, unmaintainable
the process plays a crucial role in coding)
determining the quality of the product  E.g., Staff Training, Requirement
 Quality must be built into software from Analysis, Fault-tolerant design,
the outset - it cannot be added on later defensive programming, usability
analysis, clear specification, accurate
 It is people that determine whether or internal documentation, evaluation of
not a quality product is produced the reliability of development tools
Quality Concepts Appraisal Costs
 Cost Of Quality

10718219.doc
Page 1 of 13
Syntel CQA Forum Quality Principles in Nutshell Part I
CQA Doc No 1
 These are Costs of activities designed  Map the Process
to find quality problems, such as code  Validate the map of the process
inspections and any type of testing
 Identify potential cause of the problem
 E.g., Design Review, Code Inspection,
White box testing, Black box testing,  Collect and analyze data related to the
training testers, Beta testing, test problem
automation, usability testing  Verify or revise the original problem
Failure Costs statement
 Costs that result from poor quality,  Identify root causes of the problem
such as the cost of fixing bugs and cost  Collect additional data if needed to
of dealing with customer complaints verify root causes
 Internal failure costs are failure costs Step 3 Do - Develop Solutions
that arises before your company  Establish criteria for selecting a
supplies the product to customer solution
 External failure costs are failure costs  Generate potential solutions that will
that arises after your company supplies address the root causes of the problem
the product to customer
 Select a solution
Internal failure Costs
 Gain approval and supporter for the
 Bug fixes, Regression testing chosen solution
 Wasted in-house user time  Plan the solution
 Wasted tester time, Wasted writer time Step 4 Do - Implement Solutions
 Wasted marketer time  Implement the chosen solution on a
 Wasted advertisements trial or pilot basis
 Direct cost of late shipment  If the Problem Solving Process is being
 Opportunity cost of late shipment used in conjunction with the
Continuous Improvement Process,
External failure costs return to Step 6 of the Continuous
 Technical support calls, Investigation of Improvement Process
customer complaints, refunds and  If the Problem Solving Process is being
recalls, coding/testing of interim bug fix used as a standalone, continue to Step
releases, shipping of updated product, 5
added expense of supporting multiple
versions of the product, lost sales, lost Step 5 Check - Evaluate the Results
customer goodwill, warranty costs,  Gather data on the solution
liability costs, penalties.  Analyze the data on the solution
 Total Cost of Quality = Sum of all costs Achieved the Desired Goal?
 Prevention + Appraisal + Internal  If YES, go to Step 6.
failure + External failure
 If NO, go back to Step 1.
Plan-Do-Check-Act
Step 6 Act - Standardize the solution
Step 1 Plan - Identify the Problem
 Identify systematic changes and
 Select the problem to be analyzed training needs for full implementation
 Clearly define the problem and  Adopt the solution
establish a precise problem statement
 Plan ongoing monitoring of the solution
 Set a measurable goal for the problem
solving effort  Continue to look for incremental
improvements to refine the solution
 Establish a process for coordinating
with and gaining approval of leadership  Look for another improvement
opportunity
Step 2 Plan - Analyze the Problem
Six Sigma
 Identify the processes that impact the
problem and select one  The word 'Sigma' is a statistical term
that measures how far a given process
 List the steps in the process as it deviates from perfection.
currently exists

10718219.doc
Page 2 of 13
Syntel CQA Forum
CQA Doc No 1
 The significance of Six Sigma is that if
you can measure how many defects
you have in a process, you can
systematically figure out how to
eliminate them and get as close to
'zero defects' as possible.
Key Concepts of Six Sigma
 Critical to Quality: Attributes most
important to the customer
 Defect: Failing to deliver what the
customer wants
 Process Capability: What your process
can deliver
 Variation: What the customer sees and
feels
 Stable operations: Ensuring consistent,
predictable processes to improve what
the customer sees and feels
 Design: Designing to meet customer
needs and process capability
Critical to Quality
 Understanding Customer's needs and
expectations by employing six
approaches to communicating with
customer
 Measure business performance against
dynamic customer requirements and
respond to changing market place
conditions
 Quality function deployment (QFD) and
failure modes and effects analysis
(FMEA) can help identify critical to
quality characteristics.
Defect
 Reducing the defect rate
 Determining the defect cost
 Mistake Proofing techniques eliminate
the sources of errors and ensure that a
process is free of defects.
Process Capability
 Understanding Process Capability
principles and calculating Process
Capability are integral to staying
competitive and meeting customer
requirements.
Variation
 Two sources of variation : Common
cause and special cause
 Multi-Vari Analysis offers a means of
reducing large numbers of unrelated
causes of variation to a family of
related causes.
10718219.doc
Page 3 of 13
Quality Principles in Nutshell Part I
 Reducing common-cause variation so
that the distribution has a very small
standard deviation
Stable operations
 Operational Excellence methodology
for identifying the right projects, using
the right people to lead projects, right
tools and roadmap
 Turning quality into a management
system
 Improving cycle time to process
applications for long term disability
benefits
Design
 Follow a four phase process to achieve
design. Identify, Design, Optimize and
Validate
 Design helps eliminate designed-in
quality problems that account for 70-
80% of defects
 Link Six Sigma with QS 9000
Benchmarking
 The continuous process of measuring
products, services, and practices
against the toughest competitors and
industry leaders
 The search for industry best practices
that lead to superior performance
 It is not a mechanism for determining
resource reductions
Elements of Benchmarking
 A structured process/approach
 Continuous/ongoing
 Involves measuring, evaluating, and
comparing results (and the process of
benchmarking)
 Focus on best practices/results
 Goal is to improve to level of best
Fundamentals of Benchmarking
 Focus on key services/processes
 Learn from others
 Apply what has been learned
Types of Benchmarking
 Internal - best within organization
 Competitive - best within competition
 Functional - best within industry
 Collaborative - best within voluntary
network
Syntel CQA Forum Quality Principles in Nutshell Part I
CQA Doc No 1
10 Step Benchmarking Process  Continuous improvement is a TQM
 Planning concept which involves examining
processes to proactively determine
♦ Identify benchmarking subject & improvement opportunities apart from
team problem solving.
♦ Identify & select benchmarking
 Both problems and opportunities can
partners
be addressed using the same
♦ Identify data collection techniques methodology (Continuous
 Analysis Improvement)
♦ Determine current performance gap Steps in continuous improvement
♦ Project future performance levels  Describe the issue
 Integration
 Identify the cause
♦ Communicate findings & gain
 Resolve the issue
acceptance
♦ Establish functional improvement  Follow up
goals Describe the issue
 Action  Identify improvement opportunities
♦ Develop action plan from sources such as trouble reports,
♦ Implement plans & monitor progress customer complaints and employee
ideas.
♦ Recalibrate & reset benchmark
performance levels  Utilize information gathered through
out software development life cycle
Benchmarking Made easy
such as defect analysis, post project
 Observe reviews or reviewing project attribute
♦ Who’s best? How do you know? data
Identify practices.  Once an issue has been identified,
 Understand describe it fully and quantify the
♦ Are others better? Why? How much consequences of making changes.
better? What can be adopted?  Consequences can be the cost of not
 Act fixing a problem or the cost of savings
resulting from the improvement.
Commit to findings. Set goals.
♦
Communicate new direction. Take  These consequences are due to
action to change. Recalibrate reduced rework or increased quality
Common Pitfalls and productivity

 No clear purpose/wrong purpose Determine the cause

 Poor team balance  Addressing the symptoms instead of

causes leaves the problems for long
 Too many subjects and the improvements would be
 Too many metrics/poor metrics ineffective
 No management buy-in  Techniques used to determine root
 Unrealistic schedule causes are process flow analysis,
requirements reviews, cause/effect or
 Wrong partners fishbone diagramming, and
Accelerators of Benchmarking measurement.
 Leadership commitment  Brainstorming is an effective technique
for smaller issues
 Organizational preparation
Resolve the issue
 Identification & mapping of key
processes  Resolutions involves brainstorming or
research.(also the necessity to
 Capacity for learning
understand individual authority and
 Knowledge of customers & competitors responsibility to determine what level
 Resources of commitment and involvement from
others is necessary is important)
Continuous Improvement
 Impacts on time, cost, customers,
 Software development mainly focuses
suppliers and schedules should be
on Problem Solving.
10718219.doc
Page 4 of 13
Syntel CQA Forum Quality Principles in Nutshell Part I
CQA Doc No 1
analyzed to select the appropriate ♦ Best Practice Identification Systems
action ♦ Best Practice Recognition Systems
Implementing the Resolution ♦ Communicating Best Practices
 Need to be planned to avoid problems ♦ Best Practice Knowledge Sharing
Systems
 This can be a project plan which
involves specifying activities, ♦ Ongoing Nurturing of Best Practices
responsibilities and time frames for Quality Objectives
making process changes  Improve Customer Satisfaction
 Project plan also ensures resources are  Reduce development costs
available when following up on the
 Improve time-to-market capability
improvement
 Improve processes
Follow up
Customer Satisfaction
 Making sure that the changes have
been correctly implemented and the  Knowing what to ask
desired outcome was achieved  Knowing how to ask
 Follow-up enables organizations to  Knowing who to ask
show successes and demonstrate the
 Turning the results into information
impact of improvements
Customer Satisfaction Survey
 It involves measuring the impact
against the initial objectives  Provides the management with the
information they need to determine
 More specifically, results are measured
their customer’s level of satisfaction
to see if costs have been reduced or
with their software products and with
avoided and whether defects have
the services associated with those
decreased or productivity has
products.
increased
 Technical staff can use the survey info
Conclusions
to identify opportunities for ongoing
 Improving processes should be part of process improvements and to monitor
what is done every day the impact of those improvements
 As industries, customers and C S Survey : Key Steps
technologies grow and change,
 Focusing on Key Customer Quality
organizations need to move ahead as
Requirements
well. Often what has worked in the past
will not work in the future  Creating the Questionnaire
 Individuals must be willing to look for  Deciding Who to Ask
ways to resolve problems and improve  Designing a Customer Satisfaction
processes so their jobs will be efficient, Database
effective and meet company needs.
 Reporting Survey Results: Turning Data
Best Practices into Information
 What is a best practice ? Reduce development costs / improve
♦ ”Best practices" are documented time-to-market capability
strategies and tactics employed by  Seven ways to better software projects
highly admired companies in terms of money, effort and quality
♦ Due to the nature of competition  Minimize overhead work during a
and their drive for excellence, the project. Stop tinkering the project plan.
profiled practices have been Put away the audit checklists. Cut
implemented and honed to help meeting times to bare minimum and
place their practitioners as the most keep them focussed. Take lengthy
admired, the most profitable, and discussions off-line. You need to ship
the keenest competitors in business. software, so make it your mantra. Dont
Integrated Performance Systems do any activity that makes it harder. To
make sure you ship good software keep
 Key Performance dimensions identified
reading..
using best practice
 Cutting buggy features and excess new
♦ Link Best Practices to Strategy
functionality to meet release dates will
Fulfillment
10718219.doc
Page 5 of 13
Syntel CQA Forum
CQA Doc No 1
allow you to get revenue in the door
sooner rather than later. It is hard to
decide what and when to let go. Get
help deciding. Prioritization of features
will also give your project team more
guidance on what the key high-priority
items are so they know where to spend
their time instead of investing long
hours on less important or trivial
features.
 Manage Stakeholders' Expectations
Work with your stakeholders to make
sure that, as things change and
schedules slip, they know what's going
on. They can help with determining
priorities, and provide valuable input
into making decisions. At the same
time, they will appreciate you being
honest with them about any changes
needed or problems encountered.
Asking your stakeholders for input will
make them part of the process - and
they will have a greater interest in
seeing you succeed. As well, the
stakeholders' might be willing to let
certain things go - such as being more
flexible on a shipping date in order to
keep a feature, or on the feature set in
order to meet a release date.
 Before buying a tool, consider how well
the tool fits into the processes you are
currently working with, regardless of
whether those processes are formal or
informal. Remember, you need to
spend time and money to train your
resources to be able to integrate the
new tool into your project effectively. If
you can't do that and ship your next
release simultaneously, while doing a
good job at each, the tool will quickly
become shelf-ware and the
organization will have lost money,
time, and buy-in for future tool
purchases.
 Proper risk analysis can provide
guidance for you and your team in
deciding what you must do, what you
can avoid, and what you are not going
to worry about. Perhaps appoint one
person on the project team to be the
"Risk Officer", responsible for tracking
the project's risks and the status of
mitigation/avoidance plans, and to
report on this information to the rest of
the team during project status
meetings. Regular risk reviews and
implementation of mitigation strategies
will make your software journey a
safer, more successful experience.
10718219.doc
Page 6 of 13
Quality Principles in Nutshell Part I
 Look for Quick Wins Quick Wins are
things that are easy to implement or
adopt and have a large potential return
on investment (ROI) in the short term.
Continually looking for Quick Wins in a
planned manner means you are now
doing continuous process improvement
at a rate that makes sense for you.
Quick wins are the kinds of small
changes that you can make in the way
you do things that, while consuming
less than 5% of your daily available
time, can add up to significant savings
(time, effort) at the end of the project.
 Skip the training - Hire the brains.
Bringing in experts in the present can
pave the way for leveraging less senior
resources in the future. This is one
good way to avoid or mitigate risks.
These "hired guns" are experts in
ramping up quickly on new projects,
and can become effective in a very
short period of time.
 In short: keep your product and
processes simple, do it well manually
first and automate only when it makes
sense, make changes and
improvements in process as you go
rather than all at once, and never stop
looking for better ways to do things
that make sense for your organization,
product, and market
Quality Attributes
 Reliability
 Maintainability
 Usability
 Portability
Software Reliability
 Reliability is the ability of a system or
component to perform its required
functions under stated conditions for a
specified period of time
 Software Reliability is the application of
statistical techniques to data collected
during system development and
operation to specify, predict, estimate,
and assess the reliability of software-
based systems
 Software Reliability Engineering (SRE)
is a standard, proven best practice that
makes testing more reliable, faster,
and cheaper. It can be applied to any
system using software and to
frequently-used members of software
component libraries
Software Reliability Engineering
Syntel CQA Forum Quality Principles in Nutshell Part I
CQA Doc No 1
 Set quantitative reliability objectives  Prepare for testing (includes preparing
that balance customer needs for test cases, test procedures and any
reliability, timely delivery, and cost autmated tools decided to use)
 Characterize quantitatively how users  Execute tests(conducting testing and
will employ your product then identifying failures, determining
 Track reliability during test when they occurred, and establishing
the severity of their impact)
 Maximize the efficiency of development
and test by focusing resources on the  Interpret failure data in development
operations that are most used and/or testing and certification testing.
most critical, by realistically (applying failure data to guide
reproducing field conditions, and by decisions)
delivering just enough reliability Maintainability
The advantages of SRE  Qualitative Definition
 is unique in helping testers ensure ♦ the characteristics of material
necessary reliability in minimum design and installation which make it
delivery time and cost possible to meet operational
 increases tester productivity and objectives with a minimum
reduces time to market of a product expenditure of maintenance effort
under operational environmental
 improves customer satisfaction and conditions in which scheduled and
reduces the risk of angry customers unscheduled maintenance will be
Applying SRET performed
 SRET should be applied over the entire  Quantitative Definition
software life cycle, including all ♦ maintainability is a characteristic of
releases with particular focus on design and installation which is
testing expressed as the probability that an
 Apply to feature, load, performance, item will be restored to specified
regression, certification or acceptance conditions within a given period of
testing time when maintenance action is
 Determine which associated system performed in accordance with
requires separate testing prescribed procedures and resources

 Decide which type of SRET required for Software Maintenance

each system to be tested  Is the process of modifying the existing
 Descision is made to apply program to keep the system up and
development testing to the product functioning
and certification testing to the  Is the final phase of Software life cycle
operating system designed using Water fall model
 Determine Operational Role of a Software Maintainer
Mode(Operational mode is a distinct  Understand the software completely
pattern of system use and/or and the changes to be made for
environment that needs separate modification
testing).
 Modify the software to incorporate
 Define failure in terms of severity changes by creating new programs or
classes changing existing programs
 Set failure intensity objectives  Revalidate the modified software to
 Engineer reliability strategies (means ensure correctness and to ensure that
finding the right balance among them no side effects were introduced
to achieve the failure intensity  Interact with customers to identify and
objective in the required time and at correct all problems
minimum cost)
Software maintenance problems
 Develop Operational profiles
(Operational profile is simply the set of  Program understanding
operations and their probabilities of  Top-down approach
occurrence)  Poor software design
 Poorly coded software
10718219.doc
Page 7 of 13
Syntel CQA Forum
CQA Doc No 1
 Outdated hardware
 Lack of common data definitions
 More than one programming language
 Increasing Inventory
 Excessive resource requirements
 User requirements
Classes of Software Maintenance
 Corrective maintenance : improving a
system as the result of an error
 Adaptive maintenance : improving a
system as a result of changes in the
environment
 Perfective maintenance : improving a
system as a result of the needs of end
users
 Emergency maintenace : unscheduled
corrective maintenance to prevent
disaster
 Preventive maintenance : developing
maintainable software that in turn
reduces the amount of maintenence
expense
Standards for software maintenance
 Phase 1: Problem/modification
identification and classification The
maintainer identifies, classifies and
prioritizes the modification request
 Phase 2: Analysis - The maintainer uses
repository information and modification
request to analyze the scope of the
modification and devises a preliminary
plan for design, implementation, test
and delivery
 Phase 3: Design - the maintainer
designs the modification to the system
 Phase 4: Implementation - the
maintainer implements the changes to
the system
 Phase 5: Regression/System Testing -
the system is tested for completeness
and accuracy and also to validate that
the modified code does not introduce
faults.
 Phase 6: Acceptance Testing - the
system is tested to ensure that the
modifications are satisfactory. Problems
encountered are docuemented
 Phase 7: Delivery - Once the system
has been approved the system is
delivered to the customer
Usability - Definitions
 Usability is defined in ISO 9241 part 11
as the extent to which a product can be
10718219.doc
Page 8 of 13
Quality Principles in Nutshell Part I
used by specified users to achieve
specified goals with effectiveness,
efficiency and satisfaction in a
specified context of use
 Effectiveness - How well the user
achieves the goals they set out to
achieve using the system.
 Efficiency - The resources consumed in
order to achieve their goals.
 Satisfaction - How the user feels about
their use of the system.
 User - the person who will use the
product to do their job
 User-centered design - an approach to
design in which a high level of usability
of the end product is an objective. It
includes involving users, obtaining their
feedback on the design and use of the
system, providing prototypes for users
to try out and re-designing as a result
of user feedback.
 Usability evaluation - the process by
which the level of usability of a system
is measured. It involves observing
users as they try out certain aspects of
a prodcut or process
Aspects of usability
 User-centered design
♦ Designers must understand who the
users will be and what tasks they
will do. If possible, designers should
learn to do some or all of the users'
tasks. This must take place before
the system design work starts, and
design for usability must start by
creating a usability specification.
 Participative design
♦ A panel of expected users should
work closely with the design team,
especially during the early
formulation stages and when
creating the usability specification.
To enable these users to make useful
contributions, they will need to show
a range of possibilities and
aletrnatives by means of mock-ups
and simulations
 Experimental design
♦ Early in the development process,
the expected users should do pilot
trials and then subsequently use the
simulations, and later the
prototypes, to do real work.
Whenever possible alternative
versions of important features and
interfaces should be simulated or
Syntel CQA Forum
CQA Doc No 1
prototyped for evaluation by
comparative testing.
 Iterative design
♦ The difficulties revealed in user tests
must be remedied by redesign, so
the cycle design, test and measure,
redesign must be repeated as often
as is necessary until the usability
specification is satisfied.
 User Supportive design
♦ Careful attention to user support
facilities such as documentation,
help screens can significantly assist
usability
 Design for all
♦ By taking account of the needs of
the people with say, impaired
hearing, vision, speech and motor
skills, the future product will be
more useful to a wider range of
people, and be more successful as a
result.
Usability activities
 User requirement specification
♦ analysing the user population and
the tasks they perform in a given
working environment will help in
producing a more precise user
requirement specification
♦ Studies have found that a major
cause of IT system failure is that
user requirements are not identified
properly, so the software was not
matched to them.
 Design guidelines and standards
♦ Use and advise design guidelines
and ergonomic standards relevant to
IT applications
♦ The user interface may follow the
latest styles guides, and it'll look
great. But unless the system helps
the user carry out what they want to
do effectively and efficiently, this
glossy front may restrict rather than
help them.
 Prototyping
♦ Use the methods for making and
evaluating prototypes, to validate
the functions of the system and to
develop the user interface.
♦ An International rent-a-car company
wanted to provide a 24-hour service
via stand alone terminals in airport
lounges. By using prototyping
techniques, an efficient and user-
10718219.doc
Page 9 of 13
Quality Principles in Nutshell Part I
friendly design (based upon
touchscreen terminals) was
produced in less than two months.
 User Acceptance Testing
♦ There are well estd methods for
testing systems in terms of user
performance and people’s attitudes
crucial to acceptance in the work
place.
♦ A telecommunications company,
developed a desktop videophone.
They wanted to ensure that it could
be used by senior, non-technical,
staff. Acceptance testing with
typical users confirmed that the
videophone’s simple and elegant
user interface would be well
accepted.
 Introduction of new technologies
♦ Advise on how to introduce systems
into the workplace so that users
learn and cope with the changes as
easily as possible, without the need
for expensive re-training courses
and minimising disruption to the
business.
♦ Creating a usable system will also
involve considering how it will fit into
the customer's organisation and be
widely acceptable to its employees.
This requires user involvement
throughout the design process.
Usability Questions
 What is user-centered design
♦ It means that the design is based on
the needs and requirements of the
users of the future system.
 How can user centred design be
achieved?
♦ Firstly by studying the users, their
tasks and the environment in which
the system will be located. Secondly
the system should be developed
iteratively, so that it gradualy meets
user requirements.
 How do you know when a usable
design has been achieved?
♦ As part of user requirements, a set
of of usability goals should be
defined in specific terms. Thus
usability testing can show to what
extent the goals have been
achieved.
 What would be an example of such a
goal ?
Syntel CQA Forum Quality Principles in Nutshell Part I
CQA Doc No 1
♦ For example, for a new telephone ♦ 1993, Ergonomic requirements for
system, a usability goal might be: "It office work with visual display
should be possible for 95% of users terminals (VDTs)
to make a call successfully within 30 ♦ 1993, Guidance on task
seconds, making no errors". requirements
 How do you identify such goals ? ♦ Guidance on usability(how to
♦ By studying the user performing identify the information which it is
tasks, and identifying the required necessary to take into account when
performance levels for those tasks. specifying or evaluating usability in
 How do you define usability ? terms of measures of user
performance and satisfaction)
♦ It is the effectiveness, efficiency and
satisfaction with which a product can ♦ 1994, Ergonomic principles related
be used by a given set of users to mental work-load
performing a given set of tasks in a ♦ Evaluation of Software Products(the
given environment. extent to which an entity satisfies
 Why is it such a long definition ? stated and implied needs when used
under stated conditions)
♦ This is because it recognises that
usability is not a unique property. It  Product oriented standards
depends on the particular ♦ Visual display requirements
circumstances in which the system ♦ Keyboard requirements
will be used i.e. its 'context of use' ♦ Workstation layout and postural
 How do go about measuring usability? requirements
♦ By studying the context of use of the ♦ Environmental requirements
intended product or system. From ♦ Display requirements with
this study, a sample of typical users reflections
and tasks will emerge. based on the ♦ Requirements for displayed colours
tasks, a set of usability goals (or test ♦ Requirements for non-keyboard
criteria) can be defined. A set of input devices
tests can then be run with a sample
♦ Dialogue(b/w human & information
of users to see if when they perform
systems)principles
the defined tasks, the criteria levels
are achieved. ♦ Presentation of information of visual
displays
 How many users do you need ?
♦ User guidance for user interfaces
♦ From experience, about 10 users are ♦ User-computer Menu dialogues
employed from each major user
♦ Command language user-computer
group e.g. 10 novices and 10
dialogues
experts. In this way the results from
different user groups can be ♦ Direct Manipulation dialogues
compared. ♦ Form filling dialogues
♦ Dialogue interaction - cursor control
for text editing
Usability Standards
♦ Framework for icon symbols and
 Standards related to human-centred functions
design Usability Evaluation Methods
♦ process-oriented: these specify  Testing Approach
procedures and processes to be
followed. ♦ Here the representative users work
on typical tasks using the system
♦ product-oriented: these specify and evaluators use the results to see
required attributes of the user how the user interface supports the
interface. user to do their tasks
 Process oriented standards  Inspection Approach
♦ 1981, Ergonomic principles in the ♦ Here usability specialists and
design of work systems sometimes software developers,
♦ 1997, Human-centred design users and other professionals,
processes for interactive systems

10718219.doc
Page 10 of 13
Syntel CQA Forum Quality Principles in Nutshell Part I
CQA Doc No 1
examine usability-related aspects of ♦ Portable software is easire to
a user interface maintain for multiple environments
 Inquiry approach  Vendors
♦ Here usability evaluators obtain ♦ Portable software is easier to
information about users' likes, support
dislikes, needs, and understanding ♦ Users will repurchase the same
of the system by talking to them, product for new environments
observing them using the system in  Managers
real work or letting them answer
♦Portable software reduces
questions verbally or in written form
maintenance costs
Portability - Definition ♦ Portability reduces headaches during
 Portability is an attribute which may be product enhancement
possessed by a software unit to a What can we port ?
specific degree with respect to a
 Programs , Components, Systems
specific class of environments.
 Data
 Portability may also be an attribute of
auxiliary elements such as data,  Libraries
documentation, and human  Tools
experience.
 System Software
 A software unit is portable (exhibits
 Documentation
portability) across a class of
environments to the degree that the  Experience
cost to transport and adapt it to a new Levels of Porting
environment in the class is less than
the cost of redevelopment.  Source
♦ Programming language or higher-
Portability - Key Concepts
level form. Adaptation is feasible.
 Software Units  Binary
 Environments ♦ Executable form. Most convenient,
 Classes of Environments but adaptation is difficult.
 Degree of Portability  Intermediate
 Costs and benefits ♦ May allow limited adaptation without
exposing source.
 Phases of Porting : Transportation &
Adaptation Typical Activities
 Porting vs Redevelopment  Adapting existing programs to new
environments
Why Should we port ?
 Designing programs to be portable
 Many Hardware and Software Platforms
 Improving portability of existing
 We want familiar software in different programs
environments
 System support for portability
 We want easier migration to new
system versions and to totally new Goals & Tasks
environments  Application Installers
 We want more new development, less ♦ Goal: To port applications to specific
redevelopment, and lower software new environments.
costs ♦ Tasks: Analyze environment; adapt
Who should care for Portability and compile (perhaps); configure
and install.
 Users
♦ Resources: Source (perhaps) or
♦ Portable software should be cheaper executable files; application
♦ Portable software should work the documentation; system
same in various environments documentation.
 Developers  Application designers
♦ Portable software costs less to
develop for multiple environments

10718219.doc
Page 11 of 13
Syntel CQA Forum Quality Principles in Nutshell Part I
CQA Doc No 1
♦ Goal: To design applications which  Study the symptoms of defects and
can be easily ported among different failures
environments.  Develop a theory on the causes of
♦ Tasks: Define environment classes; symptoms
develop portable design; document
 Test the theory until the cause is known
for portability.
♦ Resources: Requirements  Stimulate the remedial action by
specification; language specification appropriate action
and other relevant standards. Juran - Classification of defects
 System Implementors  Worker Controllable and Management
♦Goal: To provide mechanisms for controllable
specific environments which  Worker Responsibility
facilitate porting.
♦ worker knows what to do
♦ Tasks: Identify relevant services and
♦ worker knows result of own work
resources; support standards;
document for porting. ♦ worker has means of controlling
result
♦ Resources: System documentation;
relevant standards.  Management Responsibility
Three Related Concepts ♦ Sequence of events for improving
quality and reducing quality costs
 Portability
♦ Universal feedback loop for control
♦ Ability to use the same program (or
♦ Fundamental is data collection and
component) in multiple
analysis
environments
 Reusability
♦ Ability to use the same software
component in multiple programs Deming - 14 Principles
 Interoperability  Create constancy of purpose towards
♦ Ability of different programs to "work improvement of product and service
together," especially by exchanging  Adopt the new philosophy
data  Cease dependence on inspection to
Portability Myths achieve quality - build quality in, in the
 It is claimed that portability has been first place
solved by  End the practice of awarding business
♦ standard languages (e.g., FORTRAN, on the basis of price tag - get single
COBOL, Ada, C, C++, Java) supplier for any one item. Instead
♦ universal operating systems (e.g., minimize total cost
Unix, MS-DOS, Windows, JavaOS)  Improve constantly and forever the
♦ universal platforms (e.g., IBM-PC, system of production and service to
SPARC, JavaVM) improve quality and productivity - this
♦ open systems and POSIX constantly decreases costs
♦ OOP and distributed object models  Institute training on the job
(e.g., OLE, CORBA)  Institute leadership. The aim of
♦ Software patterns, architectures, supervision is to help people to do a
and UML better job
♦ The World Wide Web  Drive out fear, so everyone may work
Quality Pioneers effectively for the company
JURAN - Strategy for achieving Quality  Break down the barriers between
 structured annual improvements in departments - work in teams
quality  Eliminate slogans, and targets for the
 a massive quality-oriented training workforce asking for zero-defects and
programme new levels of productivity. They create
adversarial relationships. The bulk of
 upper management must lead the causes of low quality and low
company's approach to product quality productivity belong to the system
JURAN -Achieving Quality Improvement
10718219.doc
Page 12 of 13
Syntel CQA Forum Quality Principles in Nutshell Part I
CQA Doc No 1
 Eliminate work standards and ♦ it costs a lot more to produce quality
management by objectives - substitute software
leadership ♦ people make mistakes - it is
 Remove barriers that rob inevitable there will be errors in
workers/managers of the right to pride large systems
of workmanship - abolish annual merit  There is an underlying assumption that
rating the three goals of quality, cost,
 Institute a vigorous program of schedule are conflicting and mutually
education and self improvement exclusive. In contrast, Deming claims
that the only way to increase
 Put everybody in the company to work productivity and lower cost is to
to accomplish the transformation - the increase quality
transformation is everybody's job
Deming - Contribution to QC
 “The economic and social revolution
which took hold in Japan, upset in 15
years the economy of the world and
shows what can be accomplished by
serious study and adoption of
statistical methods and statistical logic
in industry at all levels from the top
downwards”
 The analysis of errors for either type or
cause will help control errors - this is
particularly important for software.
 The results enable improvement of the
process so that less errors are
produced.
 You cannot inspect quality into a
product - you must build in quality right
from the outset.
CROSBY
 Crosby suggests there are five
maturing stages through which quality
management evolves.
♦ uncertainty
♦ awakening
♦ enlightenment
♦ wisdom
♦ certainty
 Crosby used a Quality Management
Maturity Grid to define his approach.
The advantage in this is it defines a
quality improvement path for an
organization as well as a means for
assessing where at any time the
organization is on the path to quality
Crosby’s defintion of Software Quality
 "conformance to requirements”
 Misconceptions about software quality
♦ quality means goodness, cannot be
defined or measured
♦ people do not produce quality
because they don't care

10718219.doc
Page 13 of 13