software quality aspects of software project managementhossein/811/papers/stu... · software...

4 May 2005

Slide 1

Software Quality Aspects of Software Project Management

Eric Bean

EECS 811: Software Project Management

University of Kansas

Spring 2005

Eric Bean EECS 811: Software Project Management (University of Kansas, Spring 2005)

Software Quality Aspects of Project Management Slide 2

Agenda

• Introduction

– Introduction to the Quality Experts

– Total Quality Management

– Philip Crosby – Quality Without Tears

• CMM Software Quality Key Process Areas

– Software Quality Assurance

– Break and Quiz

– Peer Reviews

– Software Quality Management

– Defect Prevention

• ISO 9000

• Summary



W. Edwards Deming

• Considered the father of quality

• Quality should target needs of customers

• Focuses on prevention:

– Process

– Analysis

– Control

• Quality improvement based on statistical methods throughout development lifecycle 1900 - 1993



Deming Chain

Lower Costs

IncreasedMarketShare

Better QualityImprovedProductivity

More Jobs



Joseph M. Juran

• Among first to recognize importance of quality planning

• Juran Trilogy of Quality Management:

– Quality planning—focus on customer needs

– Quality control—maintain status quo

– Quality improvement—improving processes

1904 -



Kaoru Ishikawa

• Focus on training and education at all levels

• Six attributes of quality work:

– Quality control

– Quality control audits

– Education and training

– Quality circles activities

– Statistical methods

– Nationwide quality control promotions

• Developed fishbone, cause and effect diagram

1915 - 1989



Philip B. Crosby

• Quality is Free: The Art of Making Quality Certain (1979)

• Quality Without Tears: The Art of Hassle-Free Management (1984)

• Let’s Talk Quality: 96 Questions You Always Wanted to Ask Phil Crosby(1989)

• Heavy emphasis on

– Prevention

– Role of management

– Zero defects

1926 - 2001



Total Quality Management

• Approach to management in which the primary focus is quality and customer (both internal and external) satisfaction

• TQM involves:

– Customer focus

• Involve customer in process improvement

• Understand their needs

– Continuous improvement strategy

• Critical to quality

– People and culture

• Enable employees to be involved in changes

– Management support

• Long term commitment

• Communication to all levels



A Quality Carol

• Quality Past

– Too much quality costs money

• Quality Present

– Lack of quality costs money

– Management culture oriented toward cost and schedule with quality a distant third

• Quality Future

– Company in bankruptcy

– Establishes quality policy to deliver defect-free products



Antibodies for Quality Problems

• Antibodies not found in detailed procedures and controls—these help but are not enough

• Antibodies must be built into the management style

• Knowledge of the antibodies has to permeate the company to keep from causing quality problems

• All non-conformances are caused

• Anything that is caused can be prevented



Administering the Vaccine

• Administering the vaccine continually to the company requires three management actions:

– Determination

• Management decides they've had enough

– Education

• Give all employees a common language of quality

• Help employees understand their role

– Implementation

• Guide the improvement along the “yellow brick road”

• Process never ends



Determination [1]

• Companies lack quality because of a lack of determination

• Companies that seem to have determination but no improvement have these characteristics:– They have a program rather than a process

– Efforts target lower levels of the organization

– Quality control people are cynical

– Training materials created by training function

• Concepts require comprehension from experience

– Management is impatient for results• Leads to short-range actions, centralization, more hassle

• Real determination sets in when management recognizes that it needs to change



Determination [2]

• No try, only do

• Dedication, determination, drive necessary for something to happen

• People don't try to “do it wrong”– They just don't feel all the requirements are critical

• Real problem is management doesn't take requirements seriously

• Management has to insist on conformance to requirements and assists in prevention

• Quality procedures alone won't make quality happen

• Employees must have common language of quality and understand what management wants



Comprehension of Quality Concepts

• Real comprehension of quality concepts necessary for real determination

• Hard to reach someone enthusiastically agreeing with you

• No one against quality but few have it

• Four concepts of quality improvement process led to Absolutes of Quality Management

• Absolutes answer four questions

– What is quality?

– What system is needed to cause quality?

– What performance standard should be used?

– What measurement system is required?



Quality Management Absolute #1

The definition of quality is conformance to requirements—not “goodness”

• Allows organization to operate on something other than opinion and experience

• Quality improvement built on doing it right the first time

• Management has 3 tasks related to this:– Clearly establish requirements– Supply means to meet requirements– Spend time helping employees meet requirements

• For software—invest in “quality requirements”



Quality Requirements

• Software requirements must conform to the requirements for software requirements:

– Correct

– Complete

– Unambiguous

– Consistent

– Traceable

– Modifiable

– Verifiable

– Prioritized

• Successful projects are ready and able to deal with changing requirements (often through some form of iterative development process)



Software Quality Criteria: James McCall

• Product operation quality factors– Correctness

– Reliability

– Efficiency

– Integrity

– Usability

• Product revision quality factors– Maintainability

– Testability

– Flexibility

• Product transition quality factors– Portability

– Reusability

– Interoperability



ISO 9126

• Ambiguity in definitions of quality criteria lead to a standard, ISO 9126

• Identifies six software quality criteria

– Functionality

– Reliability

– Usability

– Efficiency

– Maintainability

– Portability

• Downside is these criteria are only measured after the system is complete



ISO 9126: Software Quality Criteria

• Functionality

– Suitability

– Accuracy

– Interoperability

– Compliance

– Security

• Reliability

– Maturity

– Fault tolerance

– Recoverability

• Usability

– Understandability

– Learnability

– Operability

• Efficiency

– Time behavior

– Resource behavior

• Maintainability

– Analyzability

– Changeability

– Stability

– Testability

• Portability

– Adaptability

– Installability

– Conformance

– Replaceability




The system of quality is prevention

• Appraisal is expensive, unreliable means of getting quality

• Prevention is key to achieving quality

• Secret of prevention is to look at process and identify opportunities for error

• Checking, sorting, evaluation only “sift” existing work

• Real-time data helps to control a process




The performance standard is zero defects

• Mistakes are caused by two factors:

– Lack of knowledge

– Lack of attention

• Knowledge can be measured and deficiencies corrected

• Lack of attention is an attitude problem

– Can only be corrected by person re-evaluating own moral values

• Why a performance standard?

– “No one has to ask for something twice as large or as fast as they need just to make certain they get what they really want.”




The measurement of quality is the price of nonconformance

• Cost of quality– Price of conformance (POC)– Price of nonconformance (PONC)

• POC is what it takes to do something right– Usually represents 3-4% of sales in well-run company

• PONC are all expenses involved in doing things wrong– Typically 20% of sales in manufacturing companies– Typically 35% of operating costs in service companies

– Used to track company improvement– Used to identify best corrective action opportunities



Cost of Software Quality

• Price of Conformance

– Prevention costs• Training, process improvement, design reviews, metrics collection, analysis, etc.

– Appraisal costs• Code inspections, testing, measurement, audits, etc.

• Price of Non-Conformance

– Internal costs• Programming rework, reinspection, retesting

– External costs• Field service, maintenance, liability damages, litigation



Cost of Nonconformance

Estimated cost of nonconforming software at one company: $250,000 or 10 Cadillacs



Costs per Line of Code

From Slaughter, S., et. al. “Evaluating the Cost of Software Quality,” Communications of the ACM 41:8, p. 71



Diversion



CMM Quality Key Process Areas

• Level 1 Initial

– ????

• Level 2 Repeatable

– Software Quality Assurance

• Level 3 Defined

– Peer Reviews

• Level 4 Managed

– Software Quality Management

• Level 5 Optimizing

– Defect Prevention



Software Quality Assurance [1]

• Purpose of SQA: to provide management with appropriate visibility into process being used by software project and of products being built

• SQA KPA goals are:

1. Software quality assurance activities are planned

2. Adherence of software products and activities to the applicable standards, procedures, and requirements is verified objectively

3. Affected groups and individuals are informed of software quality assurance activities and results

4. Noncompliance issues that cannot be resolved within the software project are addressed by senior management



Software Quality Assurance [2]

• Project follows a written organizational policy for implementing SQA

• SQA group has a reporting channel to senior management that is independent of:

– Project manager

– Project’s software engineering group

– Other software related groups

• Adequate resources and funding are provided for performing SQA activities



Goal 1. Software Quality Planning [1]

Software quality assurance activities are planned

• Software engineering suffered from notion that quality was injected at end of assembly or development process through system testing

• System testing frequently detected more defects than expected

• Project managers started planning for reviews and unit testing

• Quality can be treated like effort and schedule with use of measurements and historical data

• Quantitative quality goals and objectives can be set



Goal 1. Software Quality Planning [2]

• To achieve goals, quality management task is to:

– Plan suitable quality control activities

– Properly execute and control them

• SQA plan is prepared for software project according to a documented procedure

– SQA plan is developed in the early stages of, and in parallel with, the overall project planning

– SQA plan is reviewed by affected groups and individuals

– Plan is managed and controlled



Goal 1. Software Quality Planning: Step Wise

The following steps in Step Wise relate to quality:

• Step 1: Identify project scope and objectives

– Identify quality objectives

• Step 2: Identify project infrastructure

– Namely standards and procedures related to quality

• Step 3: Analyze project characteristics

– Identify special quality characteristics

• Step 4: Identify the products and activities of the project

– Entry, process, exit requirements for each activity

• Step 8: Review and publicize plan

– Review quality aspects



Goal 1. Software Quality Planning: SQA Plan

IEEE 730-1989

• Purpose – scope of plan

• List of references to other documents

• Management

• Documents to be produced

• Standards, practices, conventions

• Reviews and audits

• Testing

• Problem reporting and corrective action

• Tools, techniques, and methodologies

• Code, media, and supplier control

• Records collection, maintenance, and retention

• Training

• Risk management –methods to be used



Goal 1. Software Quality Planning: Test Plans [1]

• Test plan acts as service level agreement between test department and other departments

• Test plan communicates:

– Methodology used to test the product

– Resources

• Hardware

• Software

• Personnel

– Test schedule

– Process used to manage testing project




A test plan may include:

• Introduction

• Scope

• Test Plan Strategy

– Outlines objectives

– Description of each test and how it will be done

• Test environment

– Describes hardware and software configuration requirements

• Schedule for executing test plan




• Control procedures

– How are results and problems recorded and communicated

• Control activities

– Walk-throughs or reviews

• Function to be tested

• Functions not to be tested

• Risks and assumptions

• Deliverables

• Test Tools

• Approvals

• Exit Criteria



Goal 2. Adherence to Standards & Requirements [1]

Adherence of software products and activities to the applicable standards, procedures, and requirements is verified objectively

• Use of coding standards

– What impact do they have on software quality?

– How is their use enforced?

• SQA group participates in the preparation and review of the project's software development plan, standards, and procedures



Goal 2. Adherence to Standards & Requirements [2]

• SQA group reviews the software engineering activities and work products to verify compliance

• Use of documentation standards

– e.g. IEEE standards

– Company standards and templates

• Adherence to a Quality Management System (ISO 9000)



Goal 3. SQA Visibility [1]

Affected groups and individuals are informed of software quality assurance activities and results

• Quality improvement progress reports continually supplied to all employees

• SQA group periodically reports the results of its activities to the software engineering group

• Deviations identified in software activities and software work products are documented and handled according to a documented procedure



Goal 3. SQA Visibility [2]

• SQA group conducts periodic reviews of its activities and findings with the customer's SQA personnel, as appropriate

• Ensure that all employees have common language of quality and understand their role in causing quality to be routine

• Policies are clear and unambiguous

• Communication goes both ways in a timely manner

• Each management status meeting begins with a factual and financial review of quality activities and results



Goal 4. Noncompliance Issues [1]

Noncompliance issues that cannot be resolved within the software project are addressed by senior management

• Crosby would say there should be no noncompliance issues

– Management commitment will be tested until it can be assumed

• Quality management function dedicated to measuring conformance to requirements and accurately reporting differences



Goal 4. Noncompliance Issues [2]

• Deviations from plan, designated standards and procedures are documented and resolved with the appropriate software task leaders, software managers, or project manager, where possible

• Deviations not resolvable with the project leaders and managers are documented and presented to the designated senior manager

• Noncompliance items presented to the senior manager are periodically reviewed until resolved

• Documentation of noncompliance items is managed and controlled



Peer Reviews [1]

• One of CMM Level 3 Defined Key Process Areas

• KPA goals include:

1. Peer review activities are planned

2. Defects in software work products are identified and removed

• Adequate funding and resources should be provided for peer reviews

• Data on the conduct and results of the peer reviews are recorded

• SQA group reviews and/or audits the activities and work products for peer reviews and reports the results



Peer Reviews [2]

• “Egoless programming” (Gerald Weinberg)

• Effective at removing errors early

– IBM reported 83% and AT&T 92% defect detection through inspections

• Motivates developers to develop better structured and self-explanatory code

• Best talent in organization can be utilized regardless of assignment to the project

• Preserves team spirit and motivation

• Team members develop skills through discussions

• Experienced people can mentor newbies



Peer Reviews [3]

• Help prevent defects by creating more awareness about them

• Results should never be used for performance appraisals

• Focus on work product not producer

• Group reviews highly effective but ‘expensive’

– Remember “quality is free”

– Formal design & code inspections average ~65% efficiency in finding defects

• One-person reviews or desktop reviews may be appropriate for less critical software



Peer Reviews [4]

• Capers Jones: Omission of reviews or inspections causes the following problems:

– The large number of defects still present when testing slows project to a standstill

– The bad fix injection rate is extremely high—up to 20%

• With inspections about 2%; industry average 7%

– Overall defect removal efficiency associated with only testing leads to total defect removal rate of <= 80%

• Removal rate with inspections achieves up to 95%



Fagan Inspections [1]

• Inspections done on all major deliverables

• All types of defects recorded

• Carried out by colleagues except very top levels

• Carried out using predefined set of steps

• Inspection meetings not to last more than 2 hours

• Led by trained moderator (not the author)

• One person acts as recorder

• Another person acts as reader

• Other participants are reviewers



Fagan Inspections [2]

• Checklists are used to aid defect-finding process

• Material inspected at optimal rate of 100 lines per hour

• Statistics are maintained so process effectiveness can be determined and improvements made



Peer Review Process

PlanningWork productfor review

Preparation& overviewSchedule, select review

team, invitation

Groupreviewmeeting

Self-preparationlogs

Rework&

follow-up Defects log, recommendation

Reviewed workproduct, summaryreport



Software Quality Management [1]

• CMM Level 4 Key Process Area

• KPA goals include:

1. The project’s software quality management activities are planned

2. Measurable goals for software product quality and their priorities are defined

3. Actual progress toward achieving the quality goals for the software products is quantified and managed




• Purpose of Software Quality Management:

– To gain quantitative understanding of quality of software artifacts

– To achieve specific quality goals

• As with other KPAs:

– Adequate funding and resources should be provided

– Plan should be developed and followed

– SQA group reviews and/or audits the activities and work products for software quality management and reports the results




• Project's quantitative quality goals for software products are:

– Defined

– Monitored

– Revised throughout the software life cycle

• Quality of the project's software products is

– Measured

– Analyzed

– Compared to the products' quantitative quality goals on an event-driven basis



Quality Concepts

• Software quality often measured as the delivered defect density:

– Number of defects per unit size in delivered software

• Defect: something that causes software to behave contrary to requirements or needs of customer

– Or, nonconformance to requirements

• Software development highly people-oriented �highly error-prone

• Active defect removal necessary for high quality

• Cost of removal increases as latency of defects increases



Defect Injection and Removal

RequirementsAnalysis

R Design R Coding RUnit

Testing

IntegrationTesting/

System Testing

AcceptanceTesting

Development Process

Defect Injection

Defect Removal

R = Review



Procedural Approach to Quality Management [1]

• Defects are detected through reviews and testing

• Procedures and guidelines established for review and testing activities

• Performance of certain processes at set points to find defects

• Review and testing activities:

– are planned

– carried out according to defined procedures



Procedural Approach to Quality Management [2]

• Disadvantages:

– Does not allow claims about number of defects removed or quality of software following procedure

– No basis for determining effectiveness of procedure

– Highly dependent on quality of procedure and how well it’s performed

– Lacks quantitative means for assessing quality of software product



Quantitative Approach to Quality Management

• Key aspects:

– Setting quantitative quality goals

– Managing development process quantitatively to ensure goals are met with high confidence

• Intended to provide early warning signs

• Involves prediction of some parameters at various stages

• Data from defect detection processes used to ensure that processes were optimally performed



Quantitative Approach: Software Reliability Models

• Use failure data during final testing stages to estimate reliability of software product

• Pros

– Indicates whether reliability is acceptable or if more testing is needed

• Cons

– Don’t provide intermediate goals for early phases



Quantitative Approach: Defect Removal Efficiency

• Defect removal efficiency: percentage of existing total defects detected by a QC activity

• If overall injection rate is known, DRE defines quality (delivered defect density)

• Pros

– Useful metric for identifying areas of improvement in a development process

• Cons

– Can be computed only at end of project

– No direct way to control quality during development



Quantitative Approach: Defect Prediction [1]

• Quality goals set in terms of delivered defect density

• Estimate number of defects detected by various activities to set intermediate goals

• Compare to actual defect levels

• Throughout project determine if action needed to achieve desired final delivered defect density

• Defect rate follows same pattern as effort rate

– Follows a Rayleigh curve

– Reaches peak usually around unit testing time



Rayleigh Distribution Curve



Rayleigh Curve Formulas

• Defect Arrival Rate (PDF): the number of defects to arrive at time t

f(t) = K*(2t/c2)*e-(t/c)2

• Cumulative Defects (CDF): total number of defects to arrive by time t

F(t) = K*(1 - e-(t/c)2)

• Where c is a function of the time tmax that the curve reaches its peak

c = tmax * sqrt(2)

K = total number of injected defects



Quantitative Approach: Defect Prediction [2]

• Curve can be specified in terms of percentages

• Estimate of total number of defects made from estimate of injection rate and project size

• Pros

– Makes quality management resemble effort and schedule management

• Cons

– Effectiveness depends on the quality of the defect predictions for each stage of development

– If actual number of defects is less than predicted, other indicators must be evaluated to determine cause



Quantitative Approach: Statistical Process Control

• Performance expectations of QC processes set in terms of control limits

• If actual performance not within limits:

– Analyze the situation

– Take appropriate action

• Control limits are like predictions of defect levels based on past performance

• Control limits also used for monitoring finer level activities (e.g. module review or unit testing)



Diversion



Defect Tracking [1]

• “Measures of quality are powerful indicators of top-ranked software producers and are almost universal on successful projects. Projects that are likely to fail, or have failed, almost never measure quality.” (Capers Jones)

• On successful projects, response to problem reports is “strong and immediate”

– Corrective actions planned

– Task forces assigned

– Corrections done ASAP



Example Defect Data

Problem Report and Change Request Metric (Cumulative)

0

200

400

600

800

1000

Aug-9

9D

ec-9

9Apr

-00

Aug-0

0D

ec-0

0Apr

-01

Aug-0

1D

ec-0

1Apr

-02

Aug-0

2D

ec-0

2Apr

-03

Aug-0

3D

ec-0

3Apr

-04

Aug-0

4D

ec-0

4Apr

-05

Aug-0

5D

ec-0

5

0

30

60

90

120

150

180

210

240

270

300

PR-CR Opened PR-CR Closed Balance Open



Defect Tracking [2]

• Tracking defects is essential to achieving quality

• Formal defect tracking considered a project management “best practice”

• Defect tracking necessary because:

– Defects detected by many different people

– Defects detected at different stages of development

– Defects corrected by someone other than person who found the defect

– Need to remove most or all defects before final delivery of software

– Defect reporting and closure cannot be informal



Defect Tracking [3]

• Defect tracking involves recording:

– Manifestation of defect

– Defect location

– Who discovered the defect

– Who resolved the defect

– In what development phase was the defect found

• Analysis needed to determine:

– Number of defects found so far

– Percentage of defects still open

– At what development stage the defect was injected

• Also track number of defects per module



Example Defect Data [2]



Other Example Quality Data

Code Profile

13.00

16.00

19.00

22.00

25.00

28.00

31.00

34.00

37.00

Mar-0

2M

ay-02

Jul-0

2Sep-

02Nov

-02

Jan-

03M

ar-03

May-0

3Ju

l-03

Sep-03

Nov-0

3Ja

n-04

Mar-0

4M

ay-04

Jul-0

4Sep-

04Nov

-04

2.50

2.56

2.63

2.69

2.75

2.81

2.88

2.94

3.00

Av

g C

yc

lom

ati

c C

om

ple

xit

y

Average Method Size

Average Comments per 100 SLOC

Average Cyclomatic Complexity



Defect Prevention [1]

• CMM Level 5 Key Process Area

• Purpose: to identify cause of defects and prevent them from recurring

• KPA goals:

1. Defect prevention activities are planned

2. Common causes of defects are sought out and identified

3. Common causes of defects are prioritized and systematically eliminated

• “The error that does not exist cannot be missed”

• Anything that is caused can be prevented




• Defect prevention activities include:

– Joint application design to reduce downstream changes

– Formal design methods

– Structured coding methods

– Formal test plans

– Formal test case construction

– Reviews (authors learn to avoid kind of errors reviews detect)




• Software process improvement aids prevention

• Defect prevention improves productivity

• Cleanroom software engineering

– Correctness built in by use of formal specification, design, and verification

– Typically enters system testing with near zero defects and occasionally at zero defects

– “Although it is theoretically impossible to ever know for certain that a software product has zero defects, it is possible to know that it has zero defects with high probability.” (Linger)



Process Maturity, Rework & Quality Results

0.00X<= 0.05Continuous Learning and Improvement

0.0X0.05 – 0.15Management by Fact

0.X0.15 – 0.25Defined Organizational Process

X0.25 – 0.50Project Controlled

XX>= 0.50Immature

Product Quality (defect density)

Rework (% of total development effort)

Process Maturity

(characteristics)

From results of study of projects at Lockheed at various CMM levels.

From Krasner, H. “Using the Cost of Quality Approach for Software,” Crosstalk: The Journal of Defense Software Engineering, Nov. 1998, p. 9.



CMM Impact on Quality & Productivity

From King, J. & Diaz, M., “How CMM Impacts Quality, Productivity, Rework, and the Bottom Line”, Crosstalk, March 2002.



ISO 9000 Series

• International standard that attempts to ensure a company has a monitoring and control system in place for checking quality

• Concerned with certifying the developmentprocess, not the end product

• Governs quality in general—not just for software

• IS0 9000 describes primary features of a QMS

• ISO 9001 describes how a QMS is applied to creation of products and services

• ISO 9002 focuses on production and testing

• ISO 9003 focuses on final product only

• ISO 9004 applies ISO 9000 to process improvement



ISO 9000:2000 QMS Requirements

• Standard built on following principles:

– Understanding of needs of customer

– Leadership to direct achievement of quality objectives

– Involvement of staff at all levels

– Focus on individual processes used to create intermediate or deliverable products

– Continuous improvement of processes

– Decision-making based on factual evidence

– Building mutually beneficial relationships with suppliers



Quality Management System [1]

• Purpose of any QMS: “Say It, Do It, Prove It”

– Say It

• Quality manual, procedures, work instructions

– Do It

• Follow procedures and work instructions

– Prove It

• Record what you do

– Perform internal audits

• Check, check, check and take corrective action

– Continuous improvement

• Measurement, analysis, review



Quality Management System [2]

Continual Improvement of the Quality Management System

CUSTOMERCUSTOMER

Requirements

Management

Responsibility

Resource

Management

Measurement,

Analysis,

Improvement

Product

Realization Product

CUSTOMERCUSTOMER

Satisfaction



ISO 9000-3 [1]

• Title: “Guidelines for Application of ISO 9001 to the Development, Supply, and Maintenance of Software”

• Describes controls and methods for developing software that conforms to customer requirements

• Sets guidelines for software quality assurance

• Specific issues addressed:

– Internal audits

– Purchasing specifications

– Training

– Standardized testing and validation procedures



ISO 9000-3 [2]

• Requires formal company-defined processes documenting development life-cycle

– Inspection points defined

• Formal procedures cover:

– Development “framework”• In-house QA programs

– “Life-cycle activities”• Overall development process

– “Supporting activities”• Activities required to:

– Qualify

– Conform

– Confirm software developed properly



ISO 9000-3 [3]

• Some ISO 9000-3 software quality guidelines are that quality planning should include:

– Quality requirements, expressed in measurable terms, where appropriate

– The life-cycle model to be used for software development

– Defined criteria for starting and ending each project phase

– Identification of types of reviews, tests and other verification and validation activities to be carried out

– Identification of configuration management procedures to be carried out



Software Engineering QMS Document

• Sample document:

– QMS3-04-300en.pdf



ISO 9000 Criticisms

• Customers may think ISO 9000 certification implies that the final product is “certified”

• Certification is expensive and time-consuming putting small businesses at a disadvantage

• Focus on certification may shift focus from real quality problems

• Documentation of for documentation’s sake



Summary

• Quality requires management commitment and determination

• Definition of quality is conformance to requirements

• Plan quality assurance activities

• Set quantitative, measurable, quality goals

• Control processes for continual improvement to achieve quality goals

• Track defect and other quality data

• Peer reviews are highly effective for early defect detection and removal

• Prevent defects through process improvement and use of formal methods



Final Diversion



Sources [1]

Cochran, K. “The ISO/AS Standards”, Honeywell Business, Regional & General Aviation, Olathe, Kansas, February 2005.

Crosby, Philip B. Quality Without Tears: The Art of Hassle-Free Management, McGraw-Hill, Inc., New York, 1984.

Jones, C. “Software Project Management Practices: Failure Versus Success,”Crosstalk: The Journal of Defense Software Engineering, October 2004, pp. 5-9.

Jalote, P. Software Project Management in Practice, Addison-Wesley, 2002.

Hughes, B. and Cotterell, M., Software Project Management, 3rd Edition, McGraw-Hill, 2002.

Krasner, H. “Using the Cost of Quality Approach with Software,” Crosstalk: The Journal of Defense Software Engineering, November 1998, pp. 6 -11.

Laird, L. “In Praise of Defects,” Stevens Institute of Technology, 2005, http://www.njspin.org/Linda%20Laird%20March%202005.pdf[Available: 2 May 2005].

Linger, R. “Cleanroom Software Engineering for Zero Defect Software,”Proceedings of the 15th International Conference on Software Engineering, May 1997, pp. 2 - 13.



Sources [2]

Paulk, M., et. al. “Key Practices of the Capability Maturity Model,”CMU/SEI-93-TR-025, February 1993, http://www.sei.cmu.edu/pub/documents/93.reports/pdf/tr25.93.pdf[Available: 2 May 2005].

Saiedian, H. and McClanahan, L. “A Study of Two Frameworks for Quality Software Process,” SAC '95: Proceedings of the 1995 ACM Symposium on Applied Computing, 1995, ACM Press, New York, NY, pp. 434-9.

Saiedian, H. “Key for Quiz 1,” EECS 812: Software Requirements Engineering, University of Kansas, February 12, 2003.

Slaughter, S., Harter, D., and Krishan, M. “Evaluating the Cost of Software Quality,” Communications of the ACM Vol 41 No.8, pp. 67-73.

Sumner, M. “The Impact of Total Quality Management on the Roles and Responsibilities of Information Systems Professionals,” SIGCPR '93: Proceedings of the 1993 Conference on Computer Personnel Research, 1993, ACM Press, New York, NY, p.234.

Tantara Inc., “Applicability of ISO 9001 to Software Development,”http://www.tantara.ab.ca/iso90003.htm, [Available: 2 May 2005].

Wheeler, S. and Duggins, S. “Improving Software Quality,” ACM-SE 36: Proceedings of the 36th Annual Southeast Regional Conference, 1998, ACM Press, New York, NY, pp. 300 – 309.



Crossword Puzzle Key