quality principles in software development

7/30/2019 Quality Principles in Software Development

1/114

CSQA Preparation

Quality

Principles


2/114

Quality Principles

Definitions of Quality

Quality Concepts

Quality Objectives

Quality Attributes

QA v/s QC

Quality Pioneers

Quality Vocabulary


3/114

Definitions of Quality

Quality Software and Software Quality

Software that exhibits all the functionalcapabilities and non-functional attributesthat ensure that it can be put to all its

intended uses with the least effort,inconvenience and resource cost to theuser is Quality Software


4/114

Software Product Evaluation lists six keyfactors in producing Quality Software functionality

reliability

usability

efficiency

maintainability

portability


5/114

Definitions of Software

Quality

"Quality is Conformance to requirements"

- CROSBY "Software Quality means fitness for

purpose" - OULD

Quality is all the features that allow aproduct to satisfy stated or implied needsat an affordable cost - ISO-8402


6/114

Definitions of Software

Quality

GARVIN gives five views of Quality

transcendent product-based

user-based

manufacturing-based

value-based


7/114

Conclusions

It is generally accepted that quality of

the process plays a crucial role indetermining the quality of the product

Quality must be built into software from

the outset - it cannot be added on later It is people that determine whether or

not a quality product is produced


8/114

Quality Concepts

Cost Of Quality

Plan-Do-Check-Act

Six Sigma

Benchmarking

Continuous Improvement

Best Practices


9/114

Software Quality Concepts

Quality is conformance to product requirementsand should be free.

Quality is achieved through prevention of defects .

Quality control is aimed at finding problems asearly as possible and fixing them.

Doing things right the first time is the performance

standard which results in zero defects and savesthe expenses of doing things over.

The expense of quality is nonconformance toproduct requirements


10/114

Software Quality Concepts

Quality is what distinguishes a good companyfrom a great one.

Quality is meeting or exceeding ourcustomer's needs and requirements.

Software Quality is measurable.

Quality is continuous improvement.

The quality of a software product comes fromthe quality of the process used to create it.


11/114

Cost of Quality

Quality costs are the costs associated

with preventing, finding and correctingdefective work

One of the key functions of a quality

engineer is the reduction of the total costof quality associated with a product


12/114

Prevention Costs

These are costs of activities specificallydesigned to prevent poor quality(coding

errors, design errors, bad documentation,un maintainable coding)

E.g.,Staff Training, Requirement Analysis,Fault-tolerant design, defensiveprogramming, usability analysis, clearspecification, accurate internaldocumentation, evaluation of the reliability

of development tools


13/114

Appraisal Costs

These are Costs of activities designed to

find quality problems, such as codeinspections and any type of testing

E.g.,Design Review, Code Inspection,

White box testing, Black box testing,training testers, Beta testing, testautomation, usability testing


14/114

Failure Costs

Costs that result from poor quality, such asthe cost of fixing bugs and cost of dealingwith customer complaints

Internal failure costs are failure costs thatarises before your company supplies theproduct to customer

External failure costs are failure costs thatarises after your company supplies theproduct to customer


15/114

Internal failure Costs

Bug fixes, Regression testing

Wasted in-house user time

Wasted tester time, Wasted writer time

Wasted marketer time

Wasted advertisements

Direct cost of late shipment

Opportunity cost of late shipment


16/114

External failure costs

Technical support calls, Investigation of

customer complaints, refunds and recalls,coding/testing of interim bug fix releases,shipping of updated product, addedexpense of supporting multiple versions

of the product, lost sales, lost customergoodwill, warranty costs, liability costs,penalties.


17/114

Total Cost of Quality = Sum of all costs

Prevention + Appraisal + Internal failure+ External failure


18/114

Plan-Do-Check-Act


19/114

Step 1 Plan - Identify the

Problem Select the problem to be analyzed

Clearly define the problem and establisha precise problem statement

Set a measurable goal for the problem

solving effort Establish a process for coordinating with

and gaining approval of leadership


20/114

Step 2 Plan - Analyze the

Problem Identify the processes that impact the

problem and select one

List the steps in the process as itcurrently exists

Map the Process Validate the map of the process

Identify potential cause of the problem


21/114

Step 2 Plan - Analyze the

Problem (continued) Collect and analyze data related to the

problem

Verify or revise the original problemstatement

Identify root causes of the problem Collect additional data if needed to verify

root causes


22/114

Step 3 Do - Develop Solutions

Establish criteria for selecting a solution

Generate potential solutions that will

address the root causes of the problem

Select a solution

Gain approval and supporter for thechosen solution

Plan the solution


23/114

Step 4 Do - Implement

Solutions Implement the chosen solution on a trial

or pilot basis

If the Problem Solving Process is beingused in conjunction with the ContinuousImprovement Process, return to Step 6 of

the Continuous Improvement Process

If the Problem Solving Process is beingused as a standalone, continue to Step 5


24/114

Step 5 Check - Evaluate the

Results

Gather data on the solution

Analyze the data on the solution


25/114

Achieved the Desired Goal?

If YES, go to Step 6.

If NO, go back to Step 1.


26/114

Step 6 Act - Standardize the

solution Identify systematic changes and training

needs for full implementation

Adopt the solution

Plan ongoing monitoring of the solution

Continue to look for incrementalimprovements to refine the solution

Look for another improvement opportunity


27/114

Six Sigma

The word 'Sigma' is a statistical term thatmeasures how far a given processdeviates from perfection.

The significance of Six Sigma is that ifyou can measure how many defects you

have in a process, you can systematicallyfigure out how to eliminate them and getas close to 'zero defects' as possible.


28/114

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, predictableprocesses to improve what the customer sees andfeels

Design:Designing to meet customer needs andprocess capability


29/114

Critical to Quality

Understanding Customer's needs and expectationsby employing six approaches to communicating

with customer Measure business performance against dynamic

customer requirements and respond to changingmarket place conditions

Quality function deployment (QFD) and failuremodes and effects analysis (FMEA) can help identifycritical to quality characteristics.


30/114

Defect

Reducing the defect rate

Determining the defect cost

Mistake Proofing techniques eliminate thesources of errors and ensure that a

process is free of defects.


31/114

Process Capability

Understanding Process Capabilityprinciples and calculating ProcessCapability are integral to stayingcompetitive and meeting customerrequirements.


32/114

Variation

Two sources of variation : Common causeand special cause

Multi-Vari Analysis offers a means ofreducing large numbers of unrelated causesof variation to a family of related causes.

Reducing common-cause variation so thatthe distribution has a very small standarddeviation


33/114

Stable operations

Operational Excellence methodology foridentifying the right projects, using the rightpeople to lead projects, right tools androadmap

Turning quality into a management system

Improving cycle time to process applicationsfor long term disability benefits


34/114

Design

Follow a four phase process to achievedesign. 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


35/114

Benchmarking

The continuous process of measuringproducts, services, and practices againstthe toughest competitors and industryleaders

The search for industry best practices

that lead to superior performance It is not a mechanism for determining

resource reductions


36/114

Elements of Benchmarking

A structured process/approach

Continuous/ongoing

Involves measuring, evaluating, andcomparing results (and the process ofbenchmarking)

Focus on best practices/results

Goal is to improve to level of best


37/114

Fundamentals of

Benchmarking Focus on key services/processes

Learn from others

Apply what has been learned


38/114

Types of Benchmarking

Internal - best within organization

Competitive - best within competition

Functional - best within industry

Collaborative - best within voluntarynetwork


39/114

10 Step Benchmarking

Process Planning

Identify benchmarking subject & team

Identify & select benchmarking partners Identify data collection techniques

Analysis

Determine current performance gap

Project future performance levels


40/114

10 Step Benchmarking

Process Integration

Communicate findings & gain acceptance

Establish functional improvement goals

Action

Develop action plan

Implement plans & monitor progress

Recalibrate & reset benchmark performancelevels


41/114

Benchmarking Made easy

Observe

Whos best? How do you know? Identifypractices.

Understand

Are others better? Why? How much better?What can be adopted?

Act

Commit to findings. Set goals. Communicatenew direction. Take action to change.

Recalibrate


42/114

Common Pitfalls

No clear purpose/wrong purpose

Poor team balance

Too many subjects

Too many metrics/poor metrics

No management buy-in

Unrealistic schedule

Wrong partners


43/114

Accelerators of Benchmarking

Leadership commitment

Organizational preparation

Identification & mapping of key processes

Capacity for learning

Knowledge of customers & competitors

Resources


44/114

Continuous Improvement

Software development mainly focuses onProblem Solving.

Continuous improvement is a TQM conceptwhich involves examining processes toproactively determine improvementopportunities apart from problem solving.

Both problems and opportunities can beaddressed using the same methodology(Continuous Improvement)


45/114

Steps in continuous improvement

Describe the issue

Identify the cause

Resolve the issue

Follow up


46/114

Describe the issue

Identify improvement opportunities fromsources such as trouble reports, cutomercomplaints and employee ideas.

Utilize information gathered through outsoftware development life cycle such asdefect analysis, post project reviews orreviewing project attribute data


47/114

Describe the issue(contd)

Once an issue has been identified,describe it fully and quantify theconsequences of making changes.

Consequences can be the cost of notfixing a problem or the cost of savingsresulting from the improvement.

These consequences are due to reducedrework or increased quality andproductivity


48/114

Determine the cause

Addressing the symptoms instead of causesleaves the problems for long and the

improvements would be ineffective

Techniques used to determine root causes areprocess flow analysis, requirements reviews,

cause/effect or fishbone diagramming, andmeasurement.

Brainstorming is an effective technique for

smaller issues


49/114

Resolve the issue

Resolutions involves brainstorming orresearch.(also the necessity tounderstand individual authority andresponsibility to determine what level ofcommitment and involvement fromothers is necessary is important)

Impacts on time, cost, customers,suppliers and schedules should beanalyzed to select the appropriate action


50/114

Implementing the Resolution

Need to be planned to avoid problems

This can be a project plan which involvesspecifying activities, responsibilities andtime frames for making process changes

Project plan also ensures resources are

available when following up on theimprovement


51/114

Follow up

Making sure that the changes have been correctlyimplemented and the desired outcome was achieved

Follow-up enables organizations to show successes

and demonstrate the impact of improvements

It involves measuring the impact against the initialobjectives

More specifically, results are measured to see ifcosts have been reduced or avoided and whetherdefects have decreased or productivity hasincreased


52/114

Conclusions

Improving processes should be part of what isdone every day

As industries, customers and technologies

grow and change, organizations need to moveahead as well. Often what has worked in thepast will not work in the future

Individuals must be willing to look for ways toresolve problems and improve processes sotheir jobs will be efficient, effective and meetcompany needs.


53/114

Best Practices

What is a best practice ?

Best practices" are documented strategiesand tactics employed by highly admiredcompanies

Due to the nature of competition and their drivefor excellence, the profiled practices have beenimplemented and honed to help place theirpractitioners as the most admired, the mostprofitable, and the keenest competitors inbusiness.


54/114

Integrated Performance

Systems Key Performace dimensions identified

using best practise

Link Best Practices to Strategy Fulfillment

Best Practice Identification Systems

Best Practice Recognition Systems

Communicating Best Practices

Best Practice Knowledge Sharing Systems

Ongoing Nurturing of Best Practices


55/114

Quality Objectives

Improve Customer Satisfaction

Reduce development costs

Improve time-to-market capability

Improve processes


56/114

Customer Satisfaction

Knowing what to ask

Knowing how to ask

Knowing who to ask

Turning the results into information


57/114

Customer Satisfaction Survey

Provides the management with theinformation they need to determine theircustomers level of satisfaction with their

software products and with the servicesassociated with those products.

Technical staff can use the survey info to

identify opportunities for ongoing processimprovements and to monitor the impact ofthose improvements


58/114

C S Survey : Key Steps

Focusing on Key Customer QualityRequirements

Creating the Questionnaire Deciding Who to Ask

Designing a Customer Satisfaction

Database Reporting Survey Results: Turning

Data into Information


59/114

Reduce development costs/improvetime-to-market capability Seven ways to better software projects in terms of money,

effort and quality

Minimize overhead work during a project. Stop tinkering the projectplan. Put away the audit checklists. Cut meeting times to bare

minimum and keep them focussed. Take lengthy discussions off-line.You need to ship software, so make it your mantra. Dont do anyactivity that makes it harder. To make sure you ship good softwarekeep reading..

Cutting buggy features and excess new functionality to meet releasedates will allow you to get revenue in the door sooner rather thanlater. It is hard to decide what and when to let go. Get help deciding.Prioritization of features will also give your project team moreguidance on what the key high-priority items are so they know whereto spend their time instead of investing long hours on less importantor trivial features.

Manage Stakeholders' Expectations Work with your stakeholderst k th t thi h d h d l li th k


60/114

to make sure that, as things change and schedules slip, they knowwhat's going on. They can help with determining priorities, andprovide valuable input into making decisions. At the same time,they will appreciate you being honest with them about anychanges needed or problems encountered. Asking yourstakeholders for input will make them part of the process - andthey 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 theprocesses you are currently working with, regardless of whetherthose processes are formal or informal. Remember, you need tospend time and money to train your resources to be able tointegrate the new tool into your project effectively. If you can't dothat and ship your next release simultaneously, while doing agood job at each, the tool will quickly become shelf-ware and the

organization will have lost money, time, and buy-in for future toolurchases.

Proper risk analysis can provide guidance for you and your team


61/114

Proper risk analysis can provide guidance for you and your teamin deciding what you must do, what you can avoid, and what youare not going to worry about. Perhaps appoint one person on theproject team to be the "Risk Officer", responsible for tracking the

project's risks and the status of mitigation/avoidance plans, and toreport on this information to the rest of the team during projectstatus meetings. Regular risk reviews and implementation ofmitigation strategies will make your software journey a safer,more successful experience.

Look for Quick Wins Quick Wins are things that are easy toimplement or adopt and have a large potential return oninvestment (ROI) in the short term. Continually looking for QuickWins in a planned manner means you are now doing continuous

process improvement at a rate that makes sense for you. Quickwins are the kinds of small changes that you can make in the wayyou do things that, while consuming less than 5% of your dailyavailable time, can add up to significant savings (time, effort) atthe end of the project.


62/114

Skip the training - Hire the brains. Bringing in experts in the

present can pave the way for leveraging less seniorresources in the future. This is one good way to avoid or

mitigate risks. These "hired guns" are experts in ramping upquickly on new projects, and can become effective in a veryshort 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 gorather than all at once, and never stop looking for betterways to do things that make sense for your organization,

product, and market


63/114

Quality Attributes

Reliability

Maintainability

Usability

Portability


64/114

Software Reliability

Reliability is the ability of a system or component to performits required functions under stated conditions for a specifiedperiod of time

Software Reliability is the application of statistical techniquesto data collected during system development and operationto specify, predict, estimate, and assess the reliability ofsoftware-based systems

Software Reliability Engineering (SRE) is a standard, provenbest practice that makes testing more reliable, faster, andcheaper. It can be applied to any system using software andto frequently-used members of software component libraries

S ft R li bilit E i i


65/114

Software Reliability Engineering

Set quantitative reliability objectives that balancecustomer needs for reliability, timely delivery, andcost

Characterize quantitatively how users will employ

your product

Track reliability during test

Maximize the efficiency of development and test byfocusing resources on the operations that are mostused and/or most critical, by realisticallyreproducing field conditions, and by delivering just

enough reliability


66/114

The advantages of SRE

is unique in helping testers ensurenecessary reliability in minimum deliverytime and cost

increases tester productivity andreduces time to market of a product

improves customer satisfaction andreduces the risk of angry customers


67/114

Applying SRET

SRET should be applied over the entire software life cycle,including all releases with particular focus on testing

Apply to feature, load, performance, regression, certification

or acceptance testing

Determine which associated system requires separatetesting

Decide which type of SRET required for each system to betested

Descision is made to apply development testing to theproduct and certification testing to the operating system


68/114

Applying SRET(Contd)

Determine Operational Mode(Operational mode is a distinctpattern of system use and/or environment that needsseparate testing).

Define failure in terms of severity classes

Set failure intensity objectives

Engineer reliability strategies (means finding the rightbalance among them to achieve the failure intensity

objective in the required time and at minimum cost) Develop Operational profiles (Operational profile is simply

the set of operations and their probabilities of occurrence)


69/114

Applying SRET(Contd)

Prepare for testing (includes preparing test cases, testprocedures and any autmated tools decided to use)

Execute tests(conducting testing and then identifying

failures, determining when they occurred, and establishingthe severity of their impact)

Interpret failure data in development testing and certificationtesting. (applying failure data to guide decisions)

For further details referhttp://www.cs.bsu.edu/homepages/metrics/cs639d/CS639WWW/musa-oneil/index.htm


70/114

Maintainability

Qualitative Definition

the characteristics of material design and installationwhich make it possible to meet operational objectiveswith a minimum expenditure of maintenance effort underoperational environmental conditions in which scheduledand unscheduled maintenance will be performed

Quantitative Definition

maintainability is a characteristic of design and installationwhich is expressed as the probability that an item will berestored to specified conditions within a given period oftime when maintenance action is performed in

accordance with prescribed procedures and resources


71/114

Software Maintenance

Is the process of modifying the existingprogram to keep the system up and

functioning

Is the final phase of Software life cycledesigned using Water fall model


72/114

Role of a Software Maintainer

Understand the software completely and thechanges to be made for modification

Modify the software to incorporate changes by

creating new programs or changing existingprograms

Revalidate the modified software to ensure

correctness and to ensure that no side effects wereintroduced

Interact with customers to identify and correct all

problems


73/114

Software maintenance problems

Program understanding

Top-down approach

Poor software design

Poorly coded software

Outdated hardware

Lack of common data definitions

More than one programming language

Increasing Inventory

Excessive resource requirements

User requirements


74/114

Classes of Software Maintenance

Corrective maintenance : improving a system as theresult 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 correctivemaintenance to prevent disaster

Preventive maintenance : developing maintainablesoftware that in turn reduces the amount of

maintenence expense

f f


75/114

Standards for softwaremaintenance Phase 1:Problem/modification identification and classification

The maintainer identifies, classifies and prioritizes themodification request

Phase 2:Analysis - The maintainer uses repositoryinformation and modification request to analyze the scope ofthe modification and devises a preliminary plan for design,implementation, test and delivery

Phase 3:Design - the maintainer designs the modification tothe system

Phase 4:Implementation - the maintainer implements thechanges to the system


76/114

Standards (Contd)

Phase 5:Regression/System Testing - the systemis tested for completeness and accuracy and alsoto validate that the modified code does not

introduce faults.

Phase 6:Acceptance Testing - the system istested to ensure that the modifications are

satisfactory. Problems encountered aredocuemented

Phase 7:Delivery - Once the system has been

approved the system is delivered to the customer


77/114

Usability - Definitions

Usability is defined in ISO 9241 part 11 as theextent to which a product can be used byspecified users to achieve specified goals witheffectiveness, efficiency and satisfaction in aspecified context of use

Effectiveness - How well the user achieves the goalsthey set out to achieve using the system.

Efficiency - The resources consumed in order toachieve their goals.

Satisfaction -How the user feels about their use of the

system.

Usability Definitions


78/114

Usability - Definitions

User - the person who will use the product to dotheir job

User-centered design - an approach to design inwhich a high level of usability of the end product is

an objective. It includes involving users, obtainingtheir 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 thelevel of usability of a system is measured. It involvesobserving users as they try out certain aspects of aprodcut or process

Aspects of usability


79/114

Aspects of usability

User-centered design

Designers must understand who the users will be andwhat tasks they will do. If possible, designers shouldlearn to do some or all of the users' tasks. This must takeplace before the system design work starts, and design

for usability must start by creating a usabilityspecification.

Participative design

A panel of expected users should work closely with thedesign team, especially during the early formulationstages and when creating the usability specification. Toenable these users to make useful contributions, they willneed to show a range of possibilities and aletrnatives by

means of mock-ups and simulations

Usabilit Aspects


80/114

Usability Aspects

Experimental design Early in the development process, the expected users

should do pilot trials and then subsequently use thesimulations, and later the prototypes, to do real work.

Whenever possible alternative versions of importantfeatures and interfaces should be simulated orprototyped for evaluation by comparative testing.

Iterative design

The difficulties revealed in user tests must be remediedby redesign, so the cycle design, test and measure,redesign must be repeated as often as is necessary until

the usability specification is satisfied.

U bilit A t (C td)


81/114

Usability Aspects (Contd)

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 withsay, impaired hearing, vision, speech and motorskills, the future product will be more useful to awider range of people, and be more successful as aresult.

Usability activities


82/114

Usability activities

User requirement specification analysing the user population and the tasks theyperform in a given working environment will help inproducing a more precise user requirement

specification Studies have found that a major cause of IT system

failure is that user requirements are not identifiedproperly, so the software was not matched to them.

Design guidelines and standards

Use and advise design guidelines and ergonomicstandards relevant to IT applications

Usability Acitivities(contd)


83/114

Usability Acitivities(contd)

The user interface may follow the latest styles guides,and it'll look great. But unless the system helps the usercarry 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 developthe user interface.

An International rent-a-car company wanted to provide a24-hour service via stand alone terminals in airportlounges. By using prototyping techniques, an efficientand user-friendly design (based upon touchscreen

terminals) was produced in less than two months.

Usability Activities(contd)


84/114


User Acceptance Testing

There are well estd methods for testing systems interms of user performance and peoples attitudescrucial to acceptance in the work place.

A telecommunications company, developed a desktopvideophone. They wanted to ensure that it could beused by senior, non-technical, staff. Acceptancetesting with typical users confirmed that the

videophones simple and elegant user interface wouldbe well accepted.



85/114


Introduction of new technologiesAdvise on how to introduce systems into the

workplace so that users learn and cope with thechanges as easily as possible, without the need for

expensive re-training courses and minimisingdisruption to the business.

Creating a usable system will also involve consideringhow it will fit into the customer's organisation and be

widely acceptable to its employees. This requiresuser involvement throughout the design process.

Usability Questions


86/114

Usability Questions

What is user-centered design

It means that the design is based on the needs andrequirements of the users of the future system.

How can user centred design be achieved?

Firstly by studying the users, their tasks and theenvironment in which the system will be located.Secondly the system should be developed iteratively, sothat it gradualy meets user requirements.

How do you know when a usable design has beenachieved?

As part of user requirements, a set of of usability goalsshould be defined in specific terms. Thus usability testing

can show to what extent the goals have been achieved.

Usability Questions(contd)


87/114


What would be an example of such a goal ?

For example, for a new telephone system, a usability goalmight be:"It should be possible for 95% of users to make a callsuccessfully within 30 seconds, making no errors".

How do you identify such goals ?

By studying the user performing tasks, and identifying therequired performance levels for those tasks.

How do you define usability ?

It is the effectiveness, efficiency and satisfaction withwhich a product can be used by a given set of usersperforming a given set of tasks in a given environment.



88/114

y Q ( ) Why is it such a long definition ?

This is because it recognises that usability is not a uniqueproperty. It depends on the particular circumstances in whichthe systen will be used i.e. its 'context of use'

How do go about measuring usability?

By studying the context of use of the intended product orsystem. From this study, a sample of typical users and taskswill emerge. based on the tasks, a set of usability goals (or testcriteria) can be defined. A set of tests can then be run with asample of users to see if when they perform the defined tasks,

the criteria levels are achieved.

How many users do you need ?

From experience, about 10 users are employed from eachmajor user group e.g. 10 novices and 10 experts. In this way

the results from different user groups can be compared.

Usability Standards


89/114

y

Standards related to human-centred design

process-oriented: these specify procedures andprocesses to be followed.

product-oriented: these specify required attributes of

the user interface. Process oriented standards

1981, Ergonomic principles in the design ofwork systems

1997, Human-centred design processes forinteractive systems

1993, Ergonomic requirements for office work with

visual display terminals (VDTs)

Usability Standards(contd)


90/114

y ( )

Process oriented Standards

1993, Guidance on task requirements

Guidance on usability(how to identify the informationwhich it is necessary to take into account when

specifying or evaluating usability in terms ofmeasures of user performance and satisfaction)

1994, Ergonomic principles related to mental work-load

Evaluation of Software Products(the extent to whichan entity satisfies stated and implied needs whenused under stated conditions)



91/114


Product oriented standardsVisual display requirements

Keyboard requirements

Workstation layout and postural requirements Environmental requirements

Display requirements with reflections

Requirements for displayed colours

Requirements for non-keyboard input devices

Dialogue(b/w human & informationsystems)principles



92/114


Product oriented Standards Presentation of information of visual displays

User guidance for user interfaces

User-computer Menu dialogues

Command language user-computer dialogues

Direct Manipulation dialogues

Form filling dialogues

Dialogue interaction - cursor control for text editing

Framework for icon symbols and functions

Usability Evaluation Methods


93/114

y

Testing Approach

Here the representative users work on typical tasks usingthe system and evaluators use the results to see how theuser interface supports the user to do their tasks

Inspection Approach Here usability specialists and sometimes software

developers, users and other professionals, examineusability-related aspects of a user interface

Inquiry approach Here usability evaluators obtain information about users' likes,

dislikes, needs, and understanding of the system by talking tothem, observing them using the system in real work or letting

them answer questions verbally or in written form

Portability - Definition


94/114

Portability Definition

Portability is an attribute which may be possessedby a software unit to a specific degree withrespect to a specific class ofenvironments.

Portability may also be an attribute of auxiliary

elements such as data, documentation, and humanexperience.

Asoftware unit is portable (exhibits portability)

across a class ofenvironments to the degreethat the cost to transport and adapt it to a newenvironment in the class is less than the cost ofredevelopment.

Portability - Key Concepts


95/114

y y p

Software Units

Environments

Classes of Environments

Degree of Portability

Costs and benefits

Phases of Porting : Transportation & Adaptation

Porting vs Redevelopment

Why Should we port ?


96/114

Why Should we port ?

Many Hardware and Software Platforms

We want familiar software in differentenvironments

We want easier migration to new systemversions and to totally new environments

We want more new development, lessredevelopment, and lower software costs

Who should care for Portability


97/114

y

Users

Portable software should be cheaper

Portable software should work the same in various environments

Developers

Portable software costs less to develop for multiple environments Portable software is easire to maintain for multiple environments

Vendors

Portable software is easier to support

Users will repurchase the same product for new environments

Managers

Portable software reduces maintenance costs

Portability reduces headaches during product enhancement


98/114

What can we port ?

Programs , Components, Systems

Data

Libraries

Tools

System Software

Documentation

Experience


99/114

Levels of Porting

Source

Programming language or higher-level form.Adaptation is feasible.

Binary

Executable form. Most convenient, butadaptation is difficult.

Intermediate

May allow limited adaptation withoutexposing source.


100/114

Typical Activities

Adapting existing programs to newenvironments

Designing programs to be portable

Improving portability of existing

programs

System support for portability

Goals & Tasks


101/114

Application Installers

Goal: To port applications to specific new environments.

Tasks: Analyze environment; adapt and compile (perhaps);configure and install.

Resources: Source (perhaps) or executable files;application documentation; system documentation.

Application designers

Goal: To design applications which can be easily ported

among different environments. Tasks: Define environment classes; develop portable

design; document for portability.

Resources: Requirements specification; language

specification and other relevant standards.

Goals & Tasks


102/114

Goals & Tasks

System Implementors

Goal: To provide mechanisms for specificenvironments which facilitate porting.

Tasks: Identify relevant services and resources;

support standards; document for porting.

Resources: System documentation; relevantstandards.


103/114

Three Related Concepts

Portability

Ability to use the same program (orcomponent) in multiple environments

Reusability

Ability to use the same software componentin multiple programs

Interoperability

Ability of different programs to "worktogether," especially by exchanging data

Portability Myths


104/114

Portability Myths

It is claimed that portability has been solved by

standard languages (e.g., FORTRAN, COBOL, Ada, C,C++, Java)

universal operating systems (e.g., Unix, MS-DOS,

Windows, JavaOS)

universal platforms (e.g., IBM-PC, SPARC, JavaVM)

open systems and POSIX

OOP and distributed object models (e.g., OLE,CORBA)

Software patterns, architectures, and UML

The World Wide Web


105/114

Quality Pioneers

What relevance do general quality

principles that have been developed in

other fields have with softwaredevelopment and software quality?

This is addressed by studying the

principles advocated by Qualtiy Experts

JURAN - Strategy for achieving Quality


106/114

JURAN Strategy for achieving Quality

structured annual improvements inquality

a massive quality-oriented trainingprogramme

upper management must lead company'sapproach to product quality

JURAN -Achieving Quality Improvement


107/114

JURAN Achieving Quality Improvement

Study the symptoms of defects and failures

Develop a theory on the causes of symptoms

Test the theory until the cause is known

Stimulate the remedial action by appropriateaction

Juran - Classification of defects


108/114

Worker Controllable and Management controllable

Worker Responsibility

worker knows what to do

worker knows result of own work

worker has means of controlling result

Management Responsibility

Sequence of events for improving quality andreducing quality costs

Universal feedback loop for control

Fundamental is data collection and analysis

Deming - 14 Principles


109/114

Create constancy of purpose towards improvement of

product and service

Adopt the new philosophy

Cease dependence on inspection to achieve quality -

build quality in, in the first place

End the practice of awarding business on the basis ofprice tag - get single supplier for any one item.

Instead minimize total cost

Improve constantly and forever the system ofproduction and service to improve quality and

productivity - this constantly decreases costs



110/114

Institute training on the job

Institute leadership. The aim of supervision is to helppeople to do a better job

Drive out fear, so everyone may work effectively for the

company

Break down the barriers between departments - work inteams

Eliminate slogans, and targets for the workforce askingfor zero-defects and new levels of productivity. Theycreate adversarial relationships. The bulk of the causesof low quality and low productivity belong to the system



111/114

Eliminate work standards and management by

objectives - substitute leadership

Remove barriers that rob workers/managers ofthe right to pride of workmanship - abolish

annual merit rating

Institute a vigorous program of education andself improvement

Put everybody in the company to work toaccomplish the transformation - thetransformation is everybody's job

Deming - Contribution to QC


112/114

The economicand social revolution which took hold in

Japan, upset in 15 years the economy of the world andshows what can be accomplished by serious study andadoption of statistical methods and statistical logic inindustry at all levels from the top downwards

The analysis of errors for either type or cause will helpcontrol 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 mustbuild in quality right from the outset.

CROSBY


113/114

Crosby suggests there are five maturing stages

through which quality management evolves. uncertainty

awakening

enlightenment wisdom

certainty

Crosby used a Quality Management Maturity Grid todefine his approach. The advantage in this is itdefines a quality improvement path for anorganization as well as a means for assessing where

at any time the organization is on the path to quality

Crosbys defintion of Software Quality


114/114

"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

it costs a lot more to produce quality software

people make mistakes - it is inevitable there will be errorsin large systems

There is an underlying assumption that the threegoals of quality, cost, schedule are conflicting andmutually exclusive In contrast Deming claims that

quality principles in software development

Documents