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 Responsibility3. Internal Quality Auditing 2. Quality System4. Corrective Actions  Life Cycle 1. Contract Evaluation5. Design and Implementation 2. Product Deliverables6. Testing and Validation 3. Design Process7. Acceptance ( inspection ) 4. Quality planning8. Maintenance and support  Supporting Activities 1. Configuration Management6. Tools and Techniques 2. Document Management7. Purchasing 3. Quality Records8. Tracebility 4. Quality Mesurements9. Training 5. 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 number 1 - or total number total number result: Scalar = sum(metrics) / number of applicable cases

Metrics 2 Predictabilityschedule effort cost Business impacttime to market cost savings customer satisfaction Appropriatenesssatisfaction of specs fitness for use conformance to objectives Reliabilitycorrectness availability Adaptibilityresponsiveness to changes user support deviation from # elapsed weeks deviation from # hours per Phase deviation from # rework hours dev. from estimated # hours x cost/phase dev. from estim. # rework hours x cost /p # elapsed weeks deviation from schedule personel cost savings HW, SW, facility cost saving turnaround time # support hours # problem report user 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 hours problem 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