Quality of Information systems

Quality

Quality is the degree on which a product satifies the requirements

Quality management requires that :

• that requirements are stated

. functional

. program environment

. privacy and security

. personal and ergonomical

• that those requirements can be controled

• that the control is performed

Quality aspects on : - hardware

- software

- information

Quality is

never

absolute

Quality is

never

absolute

Functional quality

Functional or external quality

. important for the client

. relative , never in absolute terms

. most important parameters

- system reliability

- performance

- robustness

- user friendliness , ergonomical aspects

- completeness

Intrinsic quality

Intrinsic or internal quality most important aspect for the supplier

• reflects on functional quality

• measure for quality of production process

• reduces maintenance cost

• suppliers quality label

most important parameters

• modularity of the structure

• source code documentation

• maintainability , flexibility , extendibility

• complexity

• portability , testability , reusability

Causes for poor Quality software

Management

Technical

Training

Management errors

unclear definition of responsibilities

inadequate project estimates and planning

ineffective project management and control

no commitments agreed with end-user

no independent quality assurance or wrong people

senior management not understanding good quality management concepts

Technical errors

inadequate definition of user requirements

incomplete documentation

inadequate or inconsistent use of standards

lack of formal reviews or walk-troughs

no common development framework

maximising the engineering elegance at the expense of technical solution required

poor understanding of maintainability requirements

inadequate test strategies and testing

Training deficiencies

user ignorance of their role in the development process ,

e.g. requirements and accepance testing

inadequate training of development staff in the use of

standards, methods and tools

little or no understanding of of the accountability and

responsibility for project management concepts

Software quality

Software Quality

. Quality of the product

. Quality of the production process

reasons:

Quality can not be added afterwards via testing

easier to measure production process quality ( ISO9001 )

production process important for developers survival

ISO9000 Organization Framework

1. Management Responsibility 3. Internal Quality Auditing2. Quality System 4. Corrective Actions

Life Cycle1. Contract Evaluation 5. Design and

Implementation2. Product Deliverables 6. Testing and Validation3. Design Process 7. Acceptance ( inspection )4. Quality planning 8. Maintenance and support

Supporting Activities1. Configuration Management 6. Tools and Techniques2. Document Management 7. Purchasing3. Quality Records 8. Tracebility4. Quality Mesurements 9. Training5. Rules, Conventions, standards

ISO 9000 framework

Management responsibility

Quality system

Internal quality audit

Corrective action

ISO 9000

ISO 9000 Quality assurance and normalization

ISO 9001 Quality systems: development

ISO 9002 implementation

installation and maintenance

ISO 9003 Acceptance and testing

ISO 9004 Guidelines

Management Quality expert

An expert is one who starts off knowing a lot about a little and who comes to know moreand more about less and less until he knows absolutely everything about nothing.

A manager is one who starts off knowing a little about a lot and who comes to know less and less about more and more until he knows nothing about absolutely everything .

Management must nominate a Quality manager

Quality manager must convince management

Management view

Timeliness

Within budget

Cost/benefit 80/20 rules

CSF

Project Management

Time Budget

Quality

Measurement of Quality

Requires the ability to quantify: number of defects in programming work products

defect removal efficiency of reviews , inspections , tests

the "bad-fix" rate

the origin of defects : requirement , design , code , ...

distribution of defects through modules (to isolate error-free modules)

graded severity of defects

probability that defect will be encountered by more than one user

Metrics

Three types of measures Binary type: 0 or 1

Numerical type: the number of satisfactory cases in the associated definition

Procentual type:

number of exceptions partial number1 - or

total number total number

result: Scalar = sum(metrics) / number of applicable cases

Metrics 2

Predictability schedule

effort

cost

Business impact time to market

cost savings

customer satisfaction

Appropriateness satisfaction of specs

fitness for use

conformance to objectives

Reliability correctness

availability

Adaptibility responsiveness to changes

user support

deviation from # elapsed weeksdeviation from # hours per Phasedeviation from # rework hoursdev. from estimated # hours x cost/phasedev. from estim. # rework hours x cost /p

# elapsed weeksdeviation from schedulepersonel cost savingsHW, SW, facility cost savingturnaround time# support hours# problem reportuser satisfaction ratinguser satisfaction rating% requirements implemented# design changes# hours spent in requirements collection# prototype iterations% business objectives implemented# design changes# defects# rework hours x cost% of up-time

# rework hoursproblem request completion rate# problem reports% problem reports completed

Source: Software quality Methodology : Coopers & Lybrand

Software quality: facts

more problems with ad-hoc software

real time embedded software is more difficult

due to synchronization problems

problems increase more than linear with the size

error intensity / 1000 lines decreasing but number of lines increases

Reasons for failing

No specific budget for QA

Insufficient management involvement

Unexperienced people in QA team

QA starts together with the acceptance procedure

Objectives not well known