Unit 8 Syllabus Quality Management : Quality concepts, Software quality assurance, Software Reviews,...
-
Upload
bruce-lawson -
Category
Documents
-
view
213 -
download
0
Transcript of Unit 8 Syllabus Quality Management : Quality concepts, Software quality assurance, Software Reviews,...
Unit 8 Syllabusbull Quality Management Quality concepts
Software quality assurance Software Reviews Formal technical reviews Statistical Software quality Assurance Software reliability The ISO 9000quality standards
1
INDEXUnit 8
SNo Topic Name Lecture No Slide No
1 Quality Management Quality Concepts L1 4
2 Software Quality Assurance L2 7
3 Software Reviews L3 10
4 Formal Technical Review L4 11
5 Statistical software quality assurance L5 18
6 Software Reliability L6 20
7 ISO 9000 2000 quality assurance L7 21
Quality ManagementQuality Concepts
Variation control is the heart of quality control Form one project to another we want to
minimize the difference between the predicted resources needed to complete a project and the actual resources used including staff equipment and calendar time
Quality of design Refers to characteristics that designers specify
for the end product
3
Quality Management
Quality of conformance Degree to which design specifications are
followed in manufacturing the product Quality control Series of inspections reviews and tests used to
ensure conformance of a work product to its specifications
Quality assurance Consists of a set of auditing and reporting
functions that assess the effectiveness and completeness of quality control activities
4
Quality Managementbull Cost of Quality Prevention costs Quality planning formal technical reviews test
equipment training Appraisal costs In-process and inter-process inspection
equipment calibration and maintenance testing Failure costs rework repair failure mode analysis External failure costs Complaint resolution product return and
replacement help line support warranty work
5
Software Quality Assurance
bull Software quality assurance (SQA) is the concern ofbull every software engineer to reduce cost and improvebull product time-to-marketbull A Software Quality Assurance Plan is not merelybull another name for a test plan though test plans arebull included in an SQA planbull SQA activities are performed on every softwarebull projectbull Use of metrics is an important part of developing abull strategy to improve the quality of both softwarebull processes and work products
6
Software Quality Assurance
bull Definition of Software Quality serves to emphasize1Conformance to software requirements is the foundation from which software quality is measured2 Specified standards are used to define the development criteria that are used to guide the manner in which software is engineered3Software must conform to implicit requirements (ease of use maintainability reliability etc) as well as its explicit requirements
7
SQA Activitiesbull Prepare SQA plan for the projectbull Participate in the development of the projects softwarebull process descriptionbull Review software engineering activities to verify compliancebull with the defined software processbull Audit designated software work products to verify compliancebull with those defined as part of the software processbull Ensure that any deviations in software or work products arebull documented and handled according to a documentedbull procedurebull Record any evidence of noncompliance and reports them tobull management
8
Software Reviews
bull Purpose is to find errors before they arebull passed on to another software engineeringbull activity or released to the customerbull Software engineers (and others) conductbull formal technical reviews (FTRs) for softwarebull quality assurancebull Using formal technical reviews (walkthroughsbull or inspections) is an effective means forbull improving software quality
9
Formal Technical Review
bull A FTR is a software quality control activity performed by software engineers and othersThe objectives are
1 To uncover errors in function logic or implementation for any representation of the software
2 To verify that the software under review meets its requirements
3 To ensure that the software has been represented according to predefined standards
4 To achieve software that is developed in a uniform manner and
5 To make projects more manageable
10
Formal Technical Review
Review meeting in FTRbull The Review meeting in a FTR should abide to
the following constraints1Review meeting members should be between
three and five2Every person should prepare for the meeting
and should not require more than two hours of work for each person
3The duration of the review meeting should be less than two hours
11
Formal Technical Reviewbull The focus of FTR is on a work product that is requirement specification a
detailed component design a source code listing for a component
bull The individual who has developed the work product ie the producer informs the project leader that the work product is complete and that a review is required
bull The project leader contacts a review leader who evaluates the product for readiness generates copy of product material and distributes them to two or three review members for advance preparation
bull Each reviewer is expected to spend between one and two hours reviewing the product making notes
12
Formal Technical Reviewbull The review leader also reviews the product and establish an agenda for the
review meeting
bull The review meeting is attended by review leader all reviewers and the producer
bull One of the reviewer act as a recorderwho notes down all important points discussed in the meeting
bull The meeting(FTR) is started by introducing the agenda of meeting and then the producer introduces his product Then the producer ldquowalkthroughrdquo the product the reviewers raise issues which they have prepared in advance
bull If errors are found the recorder notes down
13
Review reporting and Record keeping
bull During the FTR a reviewer( recorder) records all issues that have been raised
bull A review summary report answers three questions1 What was reviewed2 Who reviewed it3 What were the findings and conclusionsbull Review summary report is a single page form with
possible attachmentsbull The review issues list serves two purposes1 To identify problem areas in the product2 To serve as an action item checklist that guides the
producer as corrections are made
14
Review Guidelinesbull Review the product not the producerbull Set an agenda and maintain it bull Limit debate and rebuttalbull Enunciate problem areas but donrsquot attempt to solve every problem
notedbull Take return notes bull Limit the number of participants and insist upon advance
preparationbull Develop a checklist for each product ie likely to be reviewedbull Allocate resources and schedule time for FTRSbull Conduct meaningful training for all reviewerbull Review your early reviews
15
Software Defects
bull Industry studies suggest that design activitiesbull introduce 50-65 of all defects or errorsbull during the software processbull Review techniques have been shown to be upbull to 75 effective in uncovering design flawsbull which ultimately reduces the cost ofbull subsequent activities in the software process
16
Statistical Quality Assurance
bull Information about software defects is collectedbull and categorizedbull Each defect is traced back to its causebull Using the Pareto principle (80 of the defectsbull can be traced to 20 of the causes) isolatebull the vital few defect causesbull Move to correct the problems that caused thebull defects in the vital fewrdquo
17
Six Sigma for Software Engineeringbull The most widely used strategy for statistical quality assurancebull Three core stepsbull 1 Define customer requirements deliverables and project goals via well-definedbull methods of customer communicationbull 2 Measure each existing process and its output to determine current qualitybull performance (eg compute defect metrics)bull 3 Analyze defect metrics and determine vital few causesbull For an existing process that needs improvementbull 1 Improve process by eliminating the root causes for defectsbull 2 Control future work to ensure that future work does not reintroduce causes ofbull defectsbull If new processes are being developedbull 1 Design each new process to avoid root causes of defects and to meetbull customer requirementsbull 2 Verify that the process model will avoid defects and meet customerbull requirements
18
Software Reliabilitybull Defined as the probability of failure free operation of abull computer program in a specified environment for a specifiedbull time periodbull Can be measured directly and estimated using historical andbull developmental databull Software reliability problems can usually be traced back tobull errors in design or implementationbull Measures of Reliabilitybull 1048708 Mean time between failure (MTBF) = MTTF + MTTRbull 1048708 MTTF = mean time to failurebull 1048708 MTTR = mean time to repairbull 1048708 Availability = [MTTF (MTTF + MTTR)] x 100
19
ISO 9000 Quality Standards
bull Quality assurance systems are defined as thebull organizational structure responsibilities proceduresbull processes and resources for implementing qualitybull managementbull ISO 9000 describes the quality elements that mustbull be present for a quality assurance system to bebull compliant with the standard but it does not describebull how an organization should implement thesebull elementsbull ISO 90012000 is the quality standard that containsbull 20 requirements that must be present in an effectivebull software quality assurance system
20
- Unit 8 Syllabus
- INDEX Unit 8
- Quality Management
- Slide 4
- Slide 5
- Software Quality Assurance
- Slide 7
- SQA Activities
- Software Reviews
- Formal Technical Review
- Slide 11
- Slide 12
- Slide 13
- Review reporting and Record keeping
- Review Guidelines
- Software Defects
- Statistical Quality Assurance
- Six Sigma for Software Engineering
- Software Reliability
- ISO 9000 Quality Standards
-
INDEXUnit 8
SNo Topic Name Lecture No Slide No
1 Quality Management Quality Concepts L1 4
2 Software Quality Assurance L2 7
3 Software Reviews L3 10
4 Formal Technical Review L4 11
5 Statistical software quality assurance L5 18
6 Software Reliability L6 20
7 ISO 9000 2000 quality assurance L7 21
Quality ManagementQuality Concepts
Variation control is the heart of quality control Form one project to another we want to
minimize the difference between the predicted resources needed to complete a project and the actual resources used including staff equipment and calendar time
Quality of design Refers to characteristics that designers specify
for the end product
3
Quality Management
Quality of conformance Degree to which design specifications are
followed in manufacturing the product Quality control Series of inspections reviews and tests used to
ensure conformance of a work product to its specifications
Quality assurance Consists of a set of auditing and reporting
functions that assess the effectiveness and completeness of quality control activities
4
Quality Managementbull Cost of Quality Prevention costs Quality planning formal technical reviews test
equipment training Appraisal costs In-process and inter-process inspection
equipment calibration and maintenance testing Failure costs rework repair failure mode analysis External failure costs Complaint resolution product return and
replacement help line support warranty work
5
Software Quality Assurance
bull Software quality assurance (SQA) is the concern ofbull every software engineer to reduce cost and improvebull product time-to-marketbull A Software Quality Assurance Plan is not merelybull another name for a test plan though test plans arebull included in an SQA planbull SQA activities are performed on every softwarebull projectbull Use of metrics is an important part of developing abull strategy to improve the quality of both softwarebull processes and work products
6
Software Quality Assurance
bull Definition of Software Quality serves to emphasize1Conformance to software requirements is the foundation from which software quality is measured2 Specified standards are used to define the development criteria that are used to guide the manner in which software is engineered3Software must conform to implicit requirements (ease of use maintainability reliability etc) as well as its explicit requirements
7
SQA Activitiesbull Prepare SQA plan for the projectbull Participate in the development of the projects softwarebull process descriptionbull Review software engineering activities to verify compliancebull with the defined software processbull Audit designated software work products to verify compliancebull with those defined as part of the software processbull Ensure that any deviations in software or work products arebull documented and handled according to a documentedbull procedurebull Record any evidence of noncompliance and reports them tobull management
8
Software Reviews
bull Purpose is to find errors before they arebull passed on to another software engineeringbull activity or released to the customerbull Software engineers (and others) conductbull formal technical reviews (FTRs) for softwarebull quality assurancebull Using formal technical reviews (walkthroughsbull or inspections) is an effective means forbull improving software quality
9
Formal Technical Review
bull A FTR is a software quality control activity performed by software engineers and othersThe objectives are
1 To uncover errors in function logic or implementation for any representation of the software
2 To verify that the software under review meets its requirements
3 To ensure that the software has been represented according to predefined standards
4 To achieve software that is developed in a uniform manner and
5 To make projects more manageable
10
Formal Technical Review
Review meeting in FTRbull The Review meeting in a FTR should abide to
the following constraints1Review meeting members should be between
three and five2Every person should prepare for the meeting
and should not require more than two hours of work for each person
3The duration of the review meeting should be less than two hours
11
Formal Technical Reviewbull The focus of FTR is on a work product that is requirement specification a
detailed component design a source code listing for a component
bull The individual who has developed the work product ie the producer informs the project leader that the work product is complete and that a review is required
bull The project leader contacts a review leader who evaluates the product for readiness generates copy of product material and distributes them to two or three review members for advance preparation
bull Each reviewer is expected to spend between one and two hours reviewing the product making notes
12
Formal Technical Reviewbull The review leader also reviews the product and establish an agenda for the
review meeting
bull The review meeting is attended by review leader all reviewers and the producer
bull One of the reviewer act as a recorderwho notes down all important points discussed in the meeting
bull The meeting(FTR) is started by introducing the agenda of meeting and then the producer introduces his product Then the producer ldquowalkthroughrdquo the product the reviewers raise issues which they have prepared in advance
bull If errors are found the recorder notes down
13
Review reporting and Record keeping
bull During the FTR a reviewer( recorder) records all issues that have been raised
bull A review summary report answers three questions1 What was reviewed2 Who reviewed it3 What were the findings and conclusionsbull Review summary report is a single page form with
possible attachmentsbull The review issues list serves two purposes1 To identify problem areas in the product2 To serve as an action item checklist that guides the
producer as corrections are made
14
Review Guidelinesbull Review the product not the producerbull Set an agenda and maintain it bull Limit debate and rebuttalbull Enunciate problem areas but donrsquot attempt to solve every problem
notedbull Take return notes bull Limit the number of participants and insist upon advance
preparationbull Develop a checklist for each product ie likely to be reviewedbull Allocate resources and schedule time for FTRSbull Conduct meaningful training for all reviewerbull Review your early reviews
15
Software Defects
bull Industry studies suggest that design activitiesbull introduce 50-65 of all defects or errorsbull during the software processbull Review techniques have been shown to be upbull to 75 effective in uncovering design flawsbull which ultimately reduces the cost ofbull subsequent activities in the software process
16
Statistical Quality Assurance
bull Information about software defects is collectedbull and categorizedbull Each defect is traced back to its causebull Using the Pareto principle (80 of the defectsbull can be traced to 20 of the causes) isolatebull the vital few defect causesbull Move to correct the problems that caused thebull defects in the vital fewrdquo
17
Six Sigma for Software Engineeringbull The most widely used strategy for statistical quality assurancebull Three core stepsbull 1 Define customer requirements deliverables and project goals via well-definedbull methods of customer communicationbull 2 Measure each existing process and its output to determine current qualitybull performance (eg compute defect metrics)bull 3 Analyze defect metrics and determine vital few causesbull For an existing process that needs improvementbull 1 Improve process by eliminating the root causes for defectsbull 2 Control future work to ensure that future work does not reintroduce causes ofbull defectsbull If new processes are being developedbull 1 Design each new process to avoid root causes of defects and to meetbull customer requirementsbull 2 Verify that the process model will avoid defects and meet customerbull requirements
18
Software Reliabilitybull Defined as the probability of failure free operation of abull computer program in a specified environment for a specifiedbull time periodbull Can be measured directly and estimated using historical andbull developmental databull Software reliability problems can usually be traced back tobull errors in design or implementationbull Measures of Reliabilitybull 1048708 Mean time between failure (MTBF) = MTTF + MTTRbull 1048708 MTTF = mean time to failurebull 1048708 MTTR = mean time to repairbull 1048708 Availability = [MTTF (MTTF + MTTR)] x 100
19
ISO 9000 Quality Standards
bull Quality assurance systems are defined as thebull organizational structure responsibilities proceduresbull processes and resources for implementing qualitybull managementbull ISO 9000 describes the quality elements that mustbull be present for a quality assurance system to bebull compliant with the standard but it does not describebull how an organization should implement thesebull elementsbull ISO 90012000 is the quality standard that containsbull 20 requirements that must be present in an effectivebull software quality assurance system
20
- Unit 8 Syllabus
- INDEX Unit 8
- Quality Management
- Slide 4
- Slide 5
- Software Quality Assurance
- Slide 7
- SQA Activities
- Software Reviews
- Formal Technical Review
- Slide 11
- Slide 12
- Slide 13
- Review reporting and Record keeping
- Review Guidelines
- Software Defects
- Statistical Quality Assurance
- Six Sigma for Software Engineering
- Software Reliability
- ISO 9000 Quality Standards
-
Quality ManagementQuality Concepts
Variation control is the heart of quality control Form one project to another we want to
minimize the difference between the predicted resources needed to complete a project and the actual resources used including staff equipment and calendar time
Quality of design Refers to characteristics that designers specify
for the end product
3
Quality Management
Quality of conformance Degree to which design specifications are
followed in manufacturing the product Quality control Series of inspections reviews and tests used to
ensure conformance of a work product to its specifications
Quality assurance Consists of a set of auditing and reporting
functions that assess the effectiveness and completeness of quality control activities
4
Quality Managementbull Cost of Quality Prevention costs Quality planning formal technical reviews test
equipment training Appraisal costs In-process and inter-process inspection
equipment calibration and maintenance testing Failure costs rework repair failure mode analysis External failure costs Complaint resolution product return and
replacement help line support warranty work
5
Software Quality Assurance
bull Software quality assurance (SQA) is the concern ofbull every software engineer to reduce cost and improvebull product time-to-marketbull A Software Quality Assurance Plan is not merelybull another name for a test plan though test plans arebull included in an SQA planbull SQA activities are performed on every softwarebull projectbull Use of metrics is an important part of developing abull strategy to improve the quality of both softwarebull processes and work products
6
Software Quality Assurance
bull Definition of Software Quality serves to emphasize1Conformance to software requirements is the foundation from which software quality is measured2 Specified standards are used to define the development criteria that are used to guide the manner in which software is engineered3Software must conform to implicit requirements (ease of use maintainability reliability etc) as well as its explicit requirements
7
SQA Activitiesbull Prepare SQA plan for the projectbull Participate in the development of the projects softwarebull process descriptionbull Review software engineering activities to verify compliancebull with the defined software processbull Audit designated software work products to verify compliancebull with those defined as part of the software processbull Ensure that any deviations in software or work products arebull documented and handled according to a documentedbull procedurebull Record any evidence of noncompliance and reports them tobull management
8
Software Reviews
bull Purpose is to find errors before they arebull passed on to another software engineeringbull activity or released to the customerbull Software engineers (and others) conductbull formal technical reviews (FTRs) for softwarebull quality assurancebull Using formal technical reviews (walkthroughsbull or inspections) is an effective means forbull improving software quality
9
Formal Technical Review
bull A FTR is a software quality control activity performed by software engineers and othersThe objectives are
1 To uncover errors in function logic or implementation for any representation of the software
2 To verify that the software under review meets its requirements
3 To ensure that the software has been represented according to predefined standards
4 To achieve software that is developed in a uniform manner and
5 To make projects more manageable
10
Formal Technical Review
Review meeting in FTRbull The Review meeting in a FTR should abide to
the following constraints1Review meeting members should be between
three and five2Every person should prepare for the meeting
and should not require more than two hours of work for each person
3The duration of the review meeting should be less than two hours
11
Formal Technical Reviewbull The focus of FTR is on a work product that is requirement specification a
detailed component design a source code listing for a component
bull The individual who has developed the work product ie the producer informs the project leader that the work product is complete and that a review is required
bull The project leader contacts a review leader who evaluates the product for readiness generates copy of product material and distributes them to two or three review members for advance preparation
bull Each reviewer is expected to spend between one and two hours reviewing the product making notes
12
Formal Technical Reviewbull The review leader also reviews the product and establish an agenda for the
review meeting
bull The review meeting is attended by review leader all reviewers and the producer
bull One of the reviewer act as a recorderwho notes down all important points discussed in the meeting
bull The meeting(FTR) is started by introducing the agenda of meeting and then the producer introduces his product Then the producer ldquowalkthroughrdquo the product the reviewers raise issues which they have prepared in advance
bull If errors are found the recorder notes down
13
Review reporting and Record keeping
bull During the FTR a reviewer( recorder) records all issues that have been raised
bull A review summary report answers three questions1 What was reviewed2 Who reviewed it3 What were the findings and conclusionsbull Review summary report is a single page form with
possible attachmentsbull The review issues list serves two purposes1 To identify problem areas in the product2 To serve as an action item checklist that guides the
producer as corrections are made
14
Review Guidelinesbull Review the product not the producerbull Set an agenda and maintain it bull Limit debate and rebuttalbull Enunciate problem areas but donrsquot attempt to solve every problem
notedbull Take return notes bull Limit the number of participants and insist upon advance
preparationbull Develop a checklist for each product ie likely to be reviewedbull Allocate resources and schedule time for FTRSbull Conduct meaningful training for all reviewerbull Review your early reviews
15
Software Defects
bull Industry studies suggest that design activitiesbull introduce 50-65 of all defects or errorsbull during the software processbull Review techniques have been shown to be upbull to 75 effective in uncovering design flawsbull which ultimately reduces the cost ofbull subsequent activities in the software process
16
Statistical Quality Assurance
bull Information about software defects is collectedbull and categorizedbull Each defect is traced back to its causebull Using the Pareto principle (80 of the defectsbull can be traced to 20 of the causes) isolatebull the vital few defect causesbull Move to correct the problems that caused thebull defects in the vital fewrdquo
17
Six Sigma for Software Engineeringbull The most widely used strategy for statistical quality assurancebull Three core stepsbull 1 Define customer requirements deliverables and project goals via well-definedbull methods of customer communicationbull 2 Measure each existing process and its output to determine current qualitybull performance (eg compute defect metrics)bull 3 Analyze defect metrics and determine vital few causesbull For an existing process that needs improvementbull 1 Improve process by eliminating the root causes for defectsbull 2 Control future work to ensure that future work does not reintroduce causes ofbull defectsbull If new processes are being developedbull 1 Design each new process to avoid root causes of defects and to meetbull customer requirementsbull 2 Verify that the process model will avoid defects and meet customerbull requirements
18
Software Reliabilitybull Defined as the probability of failure free operation of abull computer program in a specified environment for a specifiedbull time periodbull Can be measured directly and estimated using historical andbull developmental databull Software reliability problems can usually be traced back tobull errors in design or implementationbull Measures of Reliabilitybull 1048708 Mean time between failure (MTBF) = MTTF + MTTRbull 1048708 MTTF = mean time to failurebull 1048708 MTTR = mean time to repairbull 1048708 Availability = [MTTF (MTTF + MTTR)] x 100
19
ISO 9000 Quality Standards
bull Quality assurance systems are defined as thebull organizational structure responsibilities proceduresbull processes and resources for implementing qualitybull managementbull ISO 9000 describes the quality elements that mustbull be present for a quality assurance system to bebull compliant with the standard but it does not describebull how an organization should implement thesebull elementsbull ISO 90012000 is the quality standard that containsbull 20 requirements that must be present in an effectivebull software quality assurance system
20
- Unit 8 Syllabus
- INDEX Unit 8
- Quality Management
- Slide 4
- Slide 5
- Software Quality Assurance
- Slide 7
- SQA Activities
- Software Reviews
- Formal Technical Review
- Slide 11
- Slide 12
- Slide 13
- Review reporting and Record keeping
- Review Guidelines
- Software Defects
- Statistical Quality Assurance
- Six Sigma for Software Engineering
- Software Reliability
- ISO 9000 Quality Standards
-
Quality Management
Quality of conformance Degree to which design specifications are
followed in manufacturing the product Quality control Series of inspections reviews and tests used to
ensure conformance of a work product to its specifications
Quality assurance Consists of a set of auditing and reporting
functions that assess the effectiveness and completeness of quality control activities
4
Quality Managementbull Cost of Quality Prevention costs Quality planning formal technical reviews test
equipment training Appraisal costs In-process and inter-process inspection
equipment calibration and maintenance testing Failure costs rework repair failure mode analysis External failure costs Complaint resolution product return and
replacement help line support warranty work
5
Software Quality Assurance
bull Software quality assurance (SQA) is the concern ofbull every software engineer to reduce cost and improvebull product time-to-marketbull A Software Quality Assurance Plan is not merelybull another name for a test plan though test plans arebull included in an SQA planbull SQA activities are performed on every softwarebull projectbull Use of metrics is an important part of developing abull strategy to improve the quality of both softwarebull processes and work products
6
Software Quality Assurance
bull Definition of Software Quality serves to emphasize1Conformance to software requirements is the foundation from which software quality is measured2 Specified standards are used to define the development criteria that are used to guide the manner in which software is engineered3Software must conform to implicit requirements (ease of use maintainability reliability etc) as well as its explicit requirements
7
SQA Activitiesbull Prepare SQA plan for the projectbull Participate in the development of the projects softwarebull process descriptionbull Review software engineering activities to verify compliancebull with the defined software processbull Audit designated software work products to verify compliancebull with those defined as part of the software processbull Ensure that any deviations in software or work products arebull documented and handled according to a documentedbull procedurebull Record any evidence of noncompliance and reports them tobull management
8
Software Reviews
bull Purpose is to find errors before they arebull passed on to another software engineeringbull activity or released to the customerbull Software engineers (and others) conductbull formal technical reviews (FTRs) for softwarebull quality assurancebull Using formal technical reviews (walkthroughsbull or inspections) is an effective means forbull improving software quality
9
Formal Technical Review
bull A FTR is a software quality control activity performed by software engineers and othersThe objectives are
1 To uncover errors in function logic or implementation for any representation of the software
2 To verify that the software under review meets its requirements
3 To ensure that the software has been represented according to predefined standards
4 To achieve software that is developed in a uniform manner and
5 To make projects more manageable
10
Formal Technical Review
Review meeting in FTRbull The Review meeting in a FTR should abide to
the following constraints1Review meeting members should be between
three and five2Every person should prepare for the meeting
and should not require more than two hours of work for each person
3The duration of the review meeting should be less than two hours
11
Formal Technical Reviewbull The focus of FTR is on a work product that is requirement specification a
detailed component design a source code listing for a component
bull The individual who has developed the work product ie the producer informs the project leader that the work product is complete and that a review is required
bull The project leader contacts a review leader who evaluates the product for readiness generates copy of product material and distributes them to two or three review members for advance preparation
bull Each reviewer is expected to spend between one and two hours reviewing the product making notes
12
Formal Technical Reviewbull The review leader also reviews the product and establish an agenda for the
review meeting
bull The review meeting is attended by review leader all reviewers and the producer
bull One of the reviewer act as a recorderwho notes down all important points discussed in the meeting
bull The meeting(FTR) is started by introducing the agenda of meeting and then the producer introduces his product Then the producer ldquowalkthroughrdquo the product the reviewers raise issues which they have prepared in advance
bull If errors are found the recorder notes down
13
Review reporting and Record keeping
bull During the FTR a reviewer( recorder) records all issues that have been raised
bull A review summary report answers three questions1 What was reviewed2 Who reviewed it3 What were the findings and conclusionsbull Review summary report is a single page form with
possible attachmentsbull The review issues list serves two purposes1 To identify problem areas in the product2 To serve as an action item checklist that guides the
producer as corrections are made
14
Review Guidelinesbull Review the product not the producerbull Set an agenda and maintain it bull Limit debate and rebuttalbull Enunciate problem areas but donrsquot attempt to solve every problem
notedbull Take return notes bull Limit the number of participants and insist upon advance
preparationbull Develop a checklist for each product ie likely to be reviewedbull Allocate resources and schedule time for FTRSbull Conduct meaningful training for all reviewerbull Review your early reviews
15
Software Defects
bull Industry studies suggest that design activitiesbull introduce 50-65 of all defects or errorsbull during the software processbull Review techniques have been shown to be upbull to 75 effective in uncovering design flawsbull which ultimately reduces the cost ofbull subsequent activities in the software process
16
Statistical Quality Assurance
bull Information about software defects is collectedbull and categorizedbull Each defect is traced back to its causebull Using the Pareto principle (80 of the defectsbull can be traced to 20 of the causes) isolatebull the vital few defect causesbull Move to correct the problems that caused thebull defects in the vital fewrdquo
17
Six Sigma for Software Engineeringbull The most widely used strategy for statistical quality assurancebull Three core stepsbull 1 Define customer requirements deliverables and project goals via well-definedbull methods of customer communicationbull 2 Measure each existing process and its output to determine current qualitybull performance (eg compute defect metrics)bull 3 Analyze defect metrics and determine vital few causesbull For an existing process that needs improvementbull 1 Improve process by eliminating the root causes for defectsbull 2 Control future work to ensure that future work does not reintroduce causes ofbull defectsbull If new processes are being developedbull 1 Design each new process to avoid root causes of defects and to meetbull customer requirementsbull 2 Verify that the process model will avoid defects and meet customerbull requirements
18
Software Reliabilitybull Defined as the probability of failure free operation of abull computer program in a specified environment for a specifiedbull time periodbull Can be measured directly and estimated using historical andbull developmental databull Software reliability problems can usually be traced back tobull errors in design or implementationbull Measures of Reliabilitybull 1048708 Mean time between failure (MTBF) = MTTF + MTTRbull 1048708 MTTF = mean time to failurebull 1048708 MTTR = mean time to repairbull 1048708 Availability = [MTTF (MTTF + MTTR)] x 100
19
ISO 9000 Quality Standards
bull Quality assurance systems are defined as thebull organizational structure responsibilities proceduresbull processes and resources for implementing qualitybull managementbull ISO 9000 describes the quality elements that mustbull be present for a quality assurance system to bebull compliant with the standard but it does not describebull how an organization should implement thesebull elementsbull ISO 90012000 is the quality standard that containsbull 20 requirements that must be present in an effectivebull software quality assurance system
20
- Unit 8 Syllabus
- INDEX Unit 8
- Quality Management
- Slide 4
- Slide 5
- Software Quality Assurance
- Slide 7
- SQA Activities
- Software Reviews
- Formal Technical Review
- Slide 11
- Slide 12
- Slide 13
- Review reporting and Record keeping
- Review Guidelines
- Software Defects
- Statistical Quality Assurance
- Six Sigma for Software Engineering
- Software Reliability
- ISO 9000 Quality Standards
-
Quality Managementbull Cost of Quality Prevention costs Quality planning formal technical reviews test
equipment training Appraisal costs In-process and inter-process inspection
equipment calibration and maintenance testing Failure costs rework repair failure mode analysis External failure costs Complaint resolution product return and
replacement help line support warranty work
5
Software Quality Assurance
bull Software quality assurance (SQA) is the concern ofbull every software engineer to reduce cost and improvebull product time-to-marketbull A Software Quality Assurance Plan is not merelybull another name for a test plan though test plans arebull included in an SQA planbull SQA activities are performed on every softwarebull projectbull Use of metrics is an important part of developing abull strategy to improve the quality of both softwarebull processes and work products
6
Software Quality Assurance
bull Definition of Software Quality serves to emphasize1Conformance to software requirements is the foundation from which software quality is measured2 Specified standards are used to define the development criteria that are used to guide the manner in which software is engineered3Software must conform to implicit requirements (ease of use maintainability reliability etc) as well as its explicit requirements
7
SQA Activitiesbull Prepare SQA plan for the projectbull Participate in the development of the projects softwarebull process descriptionbull Review software engineering activities to verify compliancebull with the defined software processbull Audit designated software work products to verify compliancebull with those defined as part of the software processbull Ensure that any deviations in software or work products arebull documented and handled according to a documentedbull procedurebull Record any evidence of noncompliance and reports them tobull management
8
Software Reviews
bull Purpose is to find errors before they arebull passed on to another software engineeringbull activity or released to the customerbull Software engineers (and others) conductbull formal technical reviews (FTRs) for softwarebull quality assurancebull Using formal technical reviews (walkthroughsbull or inspections) is an effective means forbull improving software quality
9
Formal Technical Review
bull A FTR is a software quality control activity performed by software engineers and othersThe objectives are
1 To uncover errors in function logic or implementation for any representation of the software
2 To verify that the software under review meets its requirements
3 To ensure that the software has been represented according to predefined standards
4 To achieve software that is developed in a uniform manner and
5 To make projects more manageable
10
Formal Technical Review
Review meeting in FTRbull The Review meeting in a FTR should abide to
the following constraints1Review meeting members should be between
three and five2Every person should prepare for the meeting
and should not require more than two hours of work for each person
3The duration of the review meeting should be less than two hours
11
Formal Technical Reviewbull The focus of FTR is on a work product that is requirement specification a
detailed component design a source code listing for a component
bull The individual who has developed the work product ie the producer informs the project leader that the work product is complete and that a review is required
bull The project leader contacts a review leader who evaluates the product for readiness generates copy of product material and distributes them to two or three review members for advance preparation
bull Each reviewer is expected to spend between one and two hours reviewing the product making notes
12
Formal Technical Reviewbull The review leader also reviews the product and establish an agenda for the
review meeting
bull The review meeting is attended by review leader all reviewers and the producer
bull One of the reviewer act as a recorderwho notes down all important points discussed in the meeting
bull The meeting(FTR) is started by introducing the agenda of meeting and then the producer introduces his product Then the producer ldquowalkthroughrdquo the product the reviewers raise issues which they have prepared in advance
bull If errors are found the recorder notes down
13
Review reporting and Record keeping
bull During the FTR a reviewer( recorder) records all issues that have been raised
bull A review summary report answers three questions1 What was reviewed2 Who reviewed it3 What were the findings and conclusionsbull Review summary report is a single page form with
possible attachmentsbull The review issues list serves two purposes1 To identify problem areas in the product2 To serve as an action item checklist that guides the
producer as corrections are made
14
Review Guidelinesbull Review the product not the producerbull Set an agenda and maintain it bull Limit debate and rebuttalbull Enunciate problem areas but donrsquot attempt to solve every problem
notedbull Take return notes bull Limit the number of participants and insist upon advance
preparationbull Develop a checklist for each product ie likely to be reviewedbull Allocate resources and schedule time for FTRSbull Conduct meaningful training for all reviewerbull Review your early reviews
15
Software Defects
bull Industry studies suggest that design activitiesbull introduce 50-65 of all defects or errorsbull during the software processbull Review techniques have been shown to be upbull to 75 effective in uncovering design flawsbull which ultimately reduces the cost ofbull subsequent activities in the software process
16
Statistical Quality Assurance
bull Information about software defects is collectedbull and categorizedbull Each defect is traced back to its causebull Using the Pareto principle (80 of the defectsbull can be traced to 20 of the causes) isolatebull the vital few defect causesbull Move to correct the problems that caused thebull defects in the vital fewrdquo
17
Six Sigma for Software Engineeringbull The most widely used strategy for statistical quality assurancebull Three core stepsbull 1 Define customer requirements deliverables and project goals via well-definedbull methods of customer communicationbull 2 Measure each existing process and its output to determine current qualitybull performance (eg compute defect metrics)bull 3 Analyze defect metrics and determine vital few causesbull For an existing process that needs improvementbull 1 Improve process by eliminating the root causes for defectsbull 2 Control future work to ensure that future work does not reintroduce causes ofbull defectsbull If new processes are being developedbull 1 Design each new process to avoid root causes of defects and to meetbull customer requirementsbull 2 Verify that the process model will avoid defects and meet customerbull requirements
18
Software Reliabilitybull Defined as the probability of failure free operation of abull computer program in a specified environment for a specifiedbull time periodbull Can be measured directly and estimated using historical andbull developmental databull Software reliability problems can usually be traced back tobull errors in design or implementationbull Measures of Reliabilitybull 1048708 Mean time between failure (MTBF) = MTTF + MTTRbull 1048708 MTTF = mean time to failurebull 1048708 MTTR = mean time to repairbull 1048708 Availability = [MTTF (MTTF + MTTR)] x 100
19
ISO 9000 Quality Standards
bull Quality assurance systems are defined as thebull organizational structure responsibilities proceduresbull processes and resources for implementing qualitybull managementbull ISO 9000 describes the quality elements that mustbull be present for a quality assurance system to bebull compliant with the standard but it does not describebull how an organization should implement thesebull elementsbull ISO 90012000 is the quality standard that containsbull 20 requirements that must be present in an effectivebull software quality assurance system
20
- Unit 8 Syllabus
- INDEX Unit 8
- Quality Management
- Slide 4
- Slide 5
- Software Quality Assurance
- Slide 7
- SQA Activities
- Software Reviews
- Formal Technical Review
- Slide 11
- Slide 12
- Slide 13
- Review reporting and Record keeping
- Review Guidelines
- Software Defects
- Statistical Quality Assurance
- Six Sigma for Software Engineering
- Software Reliability
- ISO 9000 Quality Standards
-
Software Quality Assurance
bull Software quality assurance (SQA) is the concern ofbull every software engineer to reduce cost and improvebull product time-to-marketbull A Software Quality Assurance Plan is not merelybull another name for a test plan though test plans arebull included in an SQA planbull SQA activities are performed on every softwarebull projectbull Use of metrics is an important part of developing abull strategy to improve the quality of both softwarebull processes and work products
6
Software Quality Assurance
bull Definition of Software Quality serves to emphasize1Conformance to software requirements is the foundation from which software quality is measured2 Specified standards are used to define the development criteria that are used to guide the manner in which software is engineered3Software must conform to implicit requirements (ease of use maintainability reliability etc) as well as its explicit requirements
7
SQA Activitiesbull Prepare SQA plan for the projectbull Participate in the development of the projects softwarebull process descriptionbull Review software engineering activities to verify compliancebull with the defined software processbull Audit designated software work products to verify compliancebull with those defined as part of the software processbull Ensure that any deviations in software or work products arebull documented and handled according to a documentedbull procedurebull Record any evidence of noncompliance and reports them tobull management
8
Software Reviews
bull Purpose is to find errors before they arebull passed on to another software engineeringbull activity or released to the customerbull Software engineers (and others) conductbull formal technical reviews (FTRs) for softwarebull quality assurancebull Using formal technical reviews (walkthroughsbull or inspections) is an effective means forbull improving software quality
9
Formal Technical Review
bull A FTR is a software quality control activity performed by software engineers and othersThe objectives are
1 To uncover errors in function logic or implementation for any representation of the software
2 To verify that the software under review meets its requirements
3 To ensure that the software has been represented according to predefined standards
4 To achieve software that is developed in a uniform manner and
5 To make projects more manageable
10
Formal Technical Review
Review meeting in FTRbull The Review meeting in a FTR should abide to
the following constraints1Review meeting members should be between
three and five2Every person should prepare for the meeting
and should not require more than two hours of work for each person
3The duration of the review meeting should be less than two hours
11
Formal Technical Reviewbull The focus of FTR is on a work product that is requirement specification a
detailed component design a source code listing for a component
bull The individual who has developed the work product ie the producer informs the project leader that the work product is complete and that a review is required
bull The project leader contacts a review leader who evaluates the product for readiness generates copy of product material and distributes them to two or three review members for advance preparation
bull Each reviewer is expected to spend between one and two hours reviewing the product making notes
12
Formal Technical Reviewbull The review leader also reviews the product and establish an agenda for the
review meeting
bull The review meeting is attended by review leader all reviewers and the producer
bull One of the reviewer act as a recorderwho notes down all important points discussed in the meeting
bull The meeting(FTR) is started by introducing the agenda of meeting and then the producer introduces his product Then the producer ldquowalkthroughrdquo the product the reviewers raise issues which they have prepared in advance
bull If errors are found the recorder notes down
13
Review reporting and Record keeping
bull During the FTR a reviewer( recorder) records all issues that have been raised
bull A review summary report answers three questions1 What was reviewed2 Who reviewed it3 What were the findings and conclusionsbull Review summary report is a single page form with
possible attachmentsbull The review issues list serves two purposes1 To identify problem areas in the product2 To serve as an action item checklist that guides the
producer as corrections are made
14
Review Guidelinesbull Review the product not the producerbull Set an agenda and maintain it bull Limit debate and rebuttalbull Enunciate problem areas but donrsquot attempt to solve every problem
notedbull Take return notes bull Limit the number of participants and insist upon advance
preparationbull Develop a checklist for each product ie likely to be reviewedbull Allocate resources and schedule time for FTRSbull Conduct meaningful training for all reviewerbull Review your early reviews
15
Software Defects
bull Industry studies suggest that design activitiesbull introduce 50-65 of all defects or errorsbull during the software processbull Review techniques have been shown to be upbull to 75 effective in uncovering design flawsbull which ultimately reduces the cost ofbull subsequent activities in the software process
16
Statistical Quality Assurance
bull Information about software defects is collectedbull and categorizedbull Each defect is traced back to its causebull Using the Pareto principle (80 of the defectsbull can be traced to 20 of the causes) isolatebull the vital few defect causesbull Move to correct the problems that caused thebull defects in the vital fewrdquo
17
Six Sigma for Software Engineeringbull The most widely used strategy for statistical quality assurancebull Three core stepsbull 1 Define customer requirements deliverables and project goals via well-definedbull methods of customer communicationbull 2 Measure each existing process and its output to determine current qualitybull performance (eg compute defect metrics)bull 3 Analyze defect metrics and determine vital few causesbull For an existing process that needs improvementbull 1 Improve process by eliminating the root causes for defectsbull 2 Control future work to ensure that future work does not reintroduce causes ofbull defectsbull If new processes are being developedbull 1 Design each new process to avoid root causes of defects and to meetbull customer requirementsbull 2 Verify that the process model will avoid defects and meet customerbull requirements
18
Software Reliabilitybull Defined as the probability of failure free operation of abull computer program in a specified environment for a specifiedbull time periodbull Can be measured directly and estimated using historical andbull developmental databull Software reliability problems can usually be traced back tobull errors in design or implementationbull Measures of Reliabilitybull 1048708 Mean time between failure (MTBF) = MTTF + MTTRbull 1048708 MTTF = mean time to failurebull 1048708 MTTR = mean time to repairbull 1048708 Availability = [MTTF (MTTF + MTTR)] x 100
19
ISO 9000 Quality Standards
bull Quality assurance systems are defined as thebull organizational structure responsibilities proceduresbull processes and resources for implementing qualitybull managementbull ISO 9000 describes the quality elements that mustbull be present for a quality assurance system to bebull compliant with the standard but it does not describebull how an organization should implement thesebull elementsbull ISO 90012000 is the quality standard that containsbull 20 requirements that must be present in an effectivebull software quality assurance system
20
- Unit 8 Syllabus
- INDEX Unit 8
- Quality Management
- Slide 4
- Slide 5
- Software Quality Assurance
- Slide 7
- SQA Activities
- Software Reviews
- Formal Technical Review
- Slide 11
- Slide 12
- Slide 13
- Review reporting and Record keeping
- Review Guidelines
- Software Defects
- Statistical Quality Assurance
- Six Sigma for Software Engineering
- Software Reliability
- ISO 9000 Quality Standards
-
Software Quality Assurance
bull Definition of Software Quality serves to emphasize1Conformance to software requirements is the foundation from which software quality is measured2 Specified standards are used to define the development criteria that are used to guide the manner in which software is engineered3Software must conform to implicit requirements (ease of use maintainability reliability etc) as well as its explicit requirements
7
SQA Activitiesbull Prepare SQA plan for the projectbull Participate in the development of the projects softwarebull process descriptionbull Review software engineering activities to verify compliancebull with the defined software processbull Audit designated software work products to verify compliancebull with those defined as part of the software processbull Ensure that any deviations in software or work products arebull documented and handled according to a documentedbull procedurebull Record any evidence of noncompliance and reports them tobull management
8
Software Reviews
bull Purpose is to find errors before they arebull passed on to another software engineeringbull activity or released to the customerbull Software engineers (and others) conductbull formal technical reviews (FTRs) for softwarebull quality assurancebull Using formal technical reviews (walkthroughsbull or inspections) is an effective means forbull improving software quality
9
Formal Technical Review
bull A FTR is a software quality control activity performed by software engineers and othersThe objectives are
1 To uncover errors in function logic or implementation for any representation of the software
2 To verify that the software under review meets its requirements
3 To ensure that the software has been represented according to predefined standards
4 To achieve software that is developed in a uniform manner and
5 To make projects more manageable
10
Formal Technical Review
Review meeting in FTRbull The Review meeting in a FTR should abide to
the following constraints1Review meeting members should be between
three and five2Every person should prepare for the meeting
and should not require more than two hours of work for each person
3The duration of the review meeting should be less than two hours
11
Formal Technical Reviewbull The focus of FTR is on a work product that is requirement specification a
detailed component design a source code listing for a component
bull The individual who has developed the work product ie the producer informs the project leader that the work product is complete and that a review is required
bull The project leader contacts a review leader who evaluates the product for readiness generates copy of product material and distributes them to two or three review members for advance preparation
bull Each reviewer is expected to spend between one and two hours reviewing the product making notes
12
Formal Technical Reviewbull The review leader also reviews the product and establish an agenda for the
review meeting
bull The review meeting is attended by review leader all reviewers and the producer
bull One of the reviewer act as a recorderwho notes down all important points discussed in the meeting
bull The meeting(FTR) is started by introducing the agenda of meeting and then the producer introduces his product Then the producer ldquowalkthroughrdquo the product the reviewers raise issues which they have prepared in advance
bull If errors are found the recorder notes down
13
Review reporting and Record keeping
bull During the FTR a reviewer( recorder) records all issues that have been raised
bull A review summary report answers three questions1 What was reviewed2 Who reviewed it3 What were the findings and conclusionsbull Review summary report is a single page form with
possible attachmentsbull The review issues list serves two purposes1 To identify problem areas in the product2 To serve as an action item checklist that guides the
producer as corrections are made
14
Review Guidelinesbull Review the product not the producerbull Set an agenda and maintain it bull Limit debate and rebuttalbull Enunciate problem areas but donrsquot attempt to solve every problem
notedbull Take return notes bull Limit the number of participants and insist upon advance
preparationbull Develop a checklist for each product ie likely to be reviewedbull Allocate resources and schedule time for FTRSbull Conduct meaningful training for all reviewerbull Review your early reviews
15
Software Defects
bull Industry studies suggest that design activitiesbull introduce 50-65 of all defects or errorsbull during the software processbull Review techniques have been shown to be upbull to 75 effective in uncovering design flawsbull which ultimately reduces the cost ofbull subsequent activities in the software process
16
Statistical Quality Assurance
bull Information about software defects is collectedbull and categorizedbull Each defect is traced back to its causebull Using the Pareto principle (80 of the defectsbull can be traced to 20 of the causes) isolatebull the vital few defect causesbull Move to correct the problems that caused thebull defects in the vital fewrdquo
17
Six Sigma for Software Engineeringbull The most widely used strategy for statistical quality assurancebull Three core stepsbull 1 Define customer requirements deliverables and project goals via well-definedbull methods of customer communicationbull 2 Measure each existing process and its output to determine current qualitybull performance (eg compute defect metrics)bull 3 Analyze defect metrics and determine vital few causesbull For an existing process that needs improvementbull 1 Improve process by eliminating the root causes for defectsbull 2 Control future work to ensure that future work does not reintroduce causes ofbull defectsbull If new processes are being developedbull 1 Design each new process to avoid root causes of defects and to meetbull customer requirementsbull 2 Verify that the process model will avoid defects and meet customerbull requirements
18
Software Reliabilitybull Defined as the probability of failure free operation of abull computer program in a specified environment for a specifiedbull time periodbull Can be measured directly and estimated using historical andbull developmental databull Software reliability problems can usually be traced back tobull errors in design or implementationbull Measures of Reliabilitybull 1048708 Mean time between failure (MTBF) = MTTF + MTTRbull 1048708 MTTF = mean time to failurebull 1048708 MTTR = mean time to repairbull 1048708 Availability = [MTTF (MTTF + MTTR)] x 100
19
ISO 9000 Quality Standards
bull Quality assurance systems are defined as thebull organizational structure responsibilities proceduresbull processes and resources for implementing qualitybull managementbull ISO 9000 describes the quality elements that mustbull be present for a quality assurance system to bebull compliant with the standard but it does not describebull how an organization should implement thesebull elementsbull ISO 90012000 is the quality standard that containsbull 20 requirements that must be present in an effectivebull software quality assurance system
20
- Unit 8 Syllabus
- INDEX Unit 8
- Quality Management
- Slide 4
- Slide 5
- Software Quality Assurance
- Slide 7
- SQA Activities
- Software Reviews
- Formal Technical Review
- Slide 11
- Slide 12
- Slide 13
- Review reporting and Record keeping
- Review Guidelines
- Software Defects
- Statistical Quality Assurance
- Six Sigma for Software Engineering
- Software Reliability
- ISO 9000 Quality Standards
-
SQA Activitiesbull Prepare SQA plan for the projectbull Participate in the development of the projects softwarebull process descriptionbull Review software engineering activities to verify compliancebull with the defined software processbull Audit designated software work products to verify compliancebull with those defined as part of the software processbull Ensure that any deviations in software or work products arebull documented and handled according to a documentedbull procedurebull Record any evidence of noncompliance and reports them tobull management
8
Software Reviews
bull Purpose is to find errors before they arebull passed on to another software engineeringbull activity or released to the customerbull Software engineers (and others) conductbull formal technical reviews (FTRs) for softwarebull quality assurancebull Using formal technical reviews (walkthroughsbull or inspections) is an effective means forbull improving software quality
9
Formal Technical Review
bull A FTR is a software quality control activity performed by software engineers and othersThe objectives are
1 To uncover errors in function logic or implementation for any representation of the software
2 To verify that the software under review meets its requirements
3 To ensure that the software has been represented according to predefined standards
4 To achieve software that is developed in a uniform manner and
5 To make projects more manageable
10
Formal Technical Review
Review meeting in FTRbull The Review meeting in a FTR should abide to
the following constraints1Review meeting members should be between
three and five2Every person should prepare for the meeting
and should not require more than two hours of work for each person
3The duration of the review meeting should be less than two hours
11
Formal Technical Reviewbull The focus of FTR is on a work product that is requirement specification a
detailed component design a source code listing for a component
bull The individual who has developed the work product ie the producer informs the project leader that the work product is complete and that a review is required
bull The project leader contacts a review leader who evaluates the product for readiness generates copy of product material and distributes them to two or three review members for advance preparation
bull Each reviewer is expected to spend between one and two hours reviewing the product making notes
12
Formal Technical Reviewbull The review leader also reviews the product and establish an agenda for the
review meeting
bull The review meeting is attended by review leader all reviewers and the producer
bull One of the reviewer act as a recorderwho notes down all important points discussed in the meeting
bull The meeting(FTR) is started by introducing the agenda of meeting and then the producer introduces his product Then the producer ldquowalkthroughrdquo the product the reviewers raise issues which they have prepared in advance
bull If errors are found the recorder notes down
13
Review reporting and Record keeping
bull During the FTR a reviewer( recorder) records all issues that have been raised
bull A review summary report answers three questions1 What was reviewed2 Who reviewed it3 What were the findings and conclusionsbull Review summary report is a single page form with
possible attachmentsbull The review issues list serves two purposes1 To identify problem areas in the product2 To serve as an action item checklist that guides the
producer as corrections are made
14
Review Guidelinesbull Review the product not the producerbull Set an agenda and maintain it bull Limit debate and rebuttalbull Enunciate problem areas but donrsquot attempt to solve every problem
notedbull Take return notes bull Limit the number of participants and insist upon advance
preparationbull Develop a checklist for each product ie likely to be reviewedbull Allocate resources and schedule time for FTRSbull Conduct meaningful training for all reviewerbull Review your early reviews
15
Software Defects
bull Industry studies suggest that design activitiesbull introduce 50-65 of all defects or errorsbull during the software processbull Review techniques have been shown to be upbull to 75 effective in uncovering design flawsbull which ultimately reduces the cost ofbull subsequent activities in the software process
16
Statistical Quality Assurance
bull Information about software defects is collectedbull and categorizedbull Each defect is traced back to its causebull Using the Pareto principle (80 of the defectsbull can be traced to 20 of the causes) isolatebull the vital few defect causesbull Move to correct the problems that caused thebull defects in the vital fewrdquo
17
Six Sigma for Software Engineeringbull The most widely used strategy for statistical quality assurancebull Three core stepsbull 1 Define customer requirements deliverables and project goals via well-definedbull methods of customer communicationbull 2 Measure each existing process and its output to determine current qualitybull performance (eg compute defect metrics)bull 3 Analyze defect metrics and determine vital few causesbull For an existing process that needs improvementbull 1 Improve process by eliminating the root causes for defectsbull 2 Control future work to ensure that future work does not reintroduce causes ofbull defectsbull If new processes are being developedbull 1 Design each new process to avoid root causes of defects and to meetbull customer requirementsbull 2 Verify that the process model will avoid defects and meet customerbull requirements
18
Software Reliabilitybull Defined as the probability of failure free operation of abull computer program in a specified environment for a specifiedbull time periodbull Can be measured directly and estimated using historical andbull developmental databull Software reliability problems can usually be traced back tobull errors in design or implementationbull Measures of Reliabilitybull 1048708 Mean time between failure (MTBF) = MTTF + MTTRbull 1048708 MTTF = mean time to failurebull 1048708 MTTR = mean time to repairbull 1048708 Availability = [MTTF (MTTF + MTTR)] x 100
19
ISO 9000 Quality Standards
bull Quality assurance systems are defined as thebull organizational structure responsibilities proceduresbull processes and resources for implementing qualitybull managementbull ISO 9000 describes the quality elements that mustbull be present for a quality assurance system to bebull compliant with the standard but it does not describebull how an organization should implement thesebull elementsbull ISO 90012000 is the quality standard that containsbull 20 requirements that must be present in an effectivebull software quality assurance system
20
- Unit 8 Syllabus
- INDEX Unit 8
- Quality Management
- Slide 4
- Slide 5
- Software Quality Assurance
- Slide 7
- SQA Activities
- Software Reviews
- Formal Technical Review
- Slide 11
- Slide 12
- Slide 13
- Review reporting and Record keeping
- Review Guidelines
- Software Defects
- Statistical Quality Assurance
- Six Sigma for Software Engineering
- Software Reliability
- ISO 9000 Quality Standards
-
Software Reviews
bull Purpose is to find errors before they arebull passed on to another software engineeringbull activity or released to the customerbull Software engineers (and others) conductbull formal technical reviews (FTRs) for softwarebull quality assurancebull Using formal technical reviews (walkthroughsbull or inspections) is an effective means forbull improving software quality
9
Formal Technical Review
bull A FTR is a software quality control activity performed by software engineers and othersThe objectives are
1 To uncover errors in function logic or implementation for any representation of the software
2 To verify that the software under review meets its requirements
3 To ensure that the software has been represented according to predefined standards
4 To achieve software that is developed in a uniform manner and
5 To make projects more manageable
10
Formal Technical Review
Review meeting in FTRbull The Review meeting in a FTR should abide to
the following constraints1Review meeting members should be between
three and five2Every person should prepare for the meeting
and should not require more than two hours of work for each person
3The duration of the review meeting should be less than two hours
11
Formal Technical Reviewbull The focus of FTR is on a work product that is requirement specification a
detailed component design a source code listing for a component
bull The individual who has developed the work product ie the producer informs the project leader that the work product is complete and that a review is required
bull The project leader contacts a review leader who evaluates the product for readiness generates copy of product material and distributes them to two or three review members for advance preparation
bull Each reviewer is expected to spend between one and two hours reviewing the product making notes
12
Formal Technical Reviewbull The review leader also reviews the product and establish an agenda for the
review meeting
bull The review meeting is attended by review leader all reviewers and the producer
bull One of the reviewer act as a recorderwho notes down all important points discussed in the meeting
bull The meeting(FTR) is started by introducing the agenda of meeting and then the producer introduces his product Then the producer ldquowalkthroughrdquo the product the reviewers raise issues which they have prepared in advance
bull If errors are found the recorder notes down
13
Review reporting and Record keeping
bull During the FTR a reviewer( recorder) records all issues that have been raised
bull A review summary report answers three questions1 What was reviewed2 Who reviewed it3 What were the findings and conclusionsbull Review summary report is a single page form with
possible attachmentsbull The review issues list serves two purposes1 To identify problem areas in the product2 To serve as an action item checklist that guides the
producer as corrections are made
14
Review Guidelinesbull Review the product not the producerbull Set an agenda and maintain it bull Limit debate and rebuttalbull Enunciate problem areas but donrsquot attempt to solve every problem
notedbull Take return notes bull Limit the number of participants and insist upon advance
preparationbull Develop a checklist for each product ie likely to be reviewedbull Allocate resources and schedule time for FTRSbull Conduct meaningful training for all reviewerbull Review your early reviews
15
Software Defects
bull Industry studies suggest that design activitiesbull introduce 50-65 of all defects or errorsbull during the software processbull Review techniques have been shown to be upbull to 75 effective in uncovering design flawsbull which ultimately reduces the cost ofbull subsequent activities in the software process
16
Statistical Quality Assurance
bull Information about software defects is collectedbull and categorizedbull Each defect is traced back to its causebull Using the Pareto principle (80 of the defectsbull can be traced to 20 of the causes) isolatebull the vital few defect causesbull Move to correct the problems that caused thebull defects in the vital fewrdquo
17
Six Sigma for Software Engineeringbull The most widely used strategy for statistical quality assurancebull Three core stepsbull 1 Define customer requirements deliverables and project goals via well-definedbull methods of customer communicationbull 2 Measure each existing process and its output to determine current qualitybull performance (eg compute defect metrics)bull 3 Analyze defect metrics and determine vital few causesbull For an existing process that needs improvementbull 1 Improve process by eliminating the root causes for defectsbull 2 Control future work to ensure that future work does not reintroduce causes ofbull defectsbull If new processes are being developedbull 1 Design each new process to avoid root causes of defects and to meetbull customer requirementsbull 2 Verify that the process model will avoid defects and meet customerbull requirements
18
Software Reliabilitybull Defined as the probability of failure free operation of abull computer program in a specified environment for a specifiedbull time periodbull Can be measured directly and estimated using historical andbull developmental databull Software reliability problems can usually be traced back tobull errors in design or implementationbull Measures of Reliabilitybull 1048708 Mean time between failure (MTBF) = MTTF + MTTRbull 1048708 MTTF = mean time to failurebull 1048708 MTTR = mean time to repairbull 1048708 Availability = [MTTF (MTTF + MTTR)] x 100
19
ISO 9000 Quality Standards
bull Quality assurance systems are defined as thebull organizational structure responsibilities proceduresbull processes and resources for implementing qualitybull managementbull ISO 9000 describes the quality elements that mustbull be present for a quality assurance system to bebull compliant with the standard but it does not describebull how an organization should implement thesebull elementsbull ISO 90012000 is the quality standard that containsbull 20 requirements that must be present in an effectivebull software quality assurance system
20
- Unit 8 Syllabus
- INDEX Unit 8
- Quality Management
- Slide 4
- Slide 5
- Software Quality Assurance
- Slide 7
- SQA Activities
- Software Reviews
- Formal Technical Review
- Slide 11
- Slide 12
- Slide 13
- Review reporting and Record keeping
- Review Guidelines
- Software Defects
- Statistical Quality Assurance
- Six Sigma for Software Engineering
- Software Reliability
- ISO 9000 Quality Standards
-
Formal Technical Review
bull A FTR is a software quality control activity performed by software engineers and othersThe objectives are
1 To uncover errors in function logic or implementation for any representation of the software
2 To verify that the software under review meets its requirements
3 To ensure that the software has been represented according to predefined standards
4 To achieve software that is developed in a uniform manner and
5 To make projects more manageable
10
Formal Technical Review
Review meeting in FTRbull The Review meeting in a FTR should abide to
the following constraints1Review meeting members should be between
three and five2Every person should prepare for the meeting
and should not require more than two hours of work for each person
3The duration of the review meeting should be less than two hours
11
Formal Technical Reviewbull The focus of FTR is on a work product that is requirement specification a
detailed component design a source code listing for a component
bull The individual who has developed the work product ie the producer informs the project leader that the work product is complete and that a review is required
bull The project leader contacts a review leader who evaluates the product for readiness generates copy of product material and distributes them to two or three review members for advance preparation
bull Each reviewer is expected to spend between one and two hours reviewing the product making notes
12
Formal Technical Reviewbull The review leader also reviews the product and establish an agenda for the
review meeting
bull The review meeting is attended by review leader all reviewers and the producer
bull One of the reviewer act as a recorderwho notes down all important points discussed in the meeting
bull The meeting(FTR) is started by introducing the agenda of meeting and then the producer introduces his product Then the producer ldquowalkthroughrdquo the product the reviewers raise issues which they have prepared in advance
bull If errors are found the recorder notes down
13
Review reporting and Record keeping
bull During the FTR a reviewer( recorder) records all issues that have been raised
bull A review summary report answers three questions1 What was reviewed2 Who reviewed it3 What were the findings and conclusionsbull Review summary report is a single page form with
possible attachmentsbull The review issues list serves two purposes1 To identify problem areas in the product2 To serve as an action item checklist that guides the
producer as corrections are made
14
Review Guidelinesbull Review the product not the producerbull Set an agenda and maintain it bull Limit debate and rebuttalbull Enunciate problem areas but donrsquot attempt to solve every problem
notedbull Take return notes bull Limit the number of participants and insist upon advance
preparationbull Develop a checklist for each product ie likely to be reviewedbull Allocate resources and schedule time for FTRSbull Conduct meaningful training for all reviewerbull Review your early reviews
15
Software Defects
bull Industry studies suggest that design activitiesbull introduce 50-65 of all defects or errorsbull during the software processbull Review techniques have been shown to be upbull to 75 effective in uncovering design flawsbull which ultimately reduces the cost ofbull subsequent activities in the software process
16
Statistical Quality Assurance
bull Information about software defects is collectedbull and categorizedbull Each defect is traced back to its causebull Using the Pareto principle (80 of the defectsbull can be traced to 20 of the causes) isolatebull the vital few defect causesbull Move to correct the problems that caused thebull defects in the vital fewrdquo
17
Six Sigma for Software Engineeringbull The most widely used strategy for statistical quality assurancebull Three core stepsbull 1 Define customer requirements deliverables and project goals via well-definedbull methods of customer communicationbull 2 Measure each existing process and its output to determine current qualitybull performance (eg compute defect metrics)bull 3 Analyze defect metrics and determine vital few causesbull For an existing process that needs improvementbull 1 Improve process by eliminating the root causes for defectsbull 2 Control future work to ensure that future work does not reintroduce causes ofbull defectsbull If new processes are being developedbull 1 Design each new process to avoid root causes of defects and to meetbull customer requirementsbull 2 Verify that the process model will avoid defects and meet customerbull requirements
18
Software Reliabilitybull Defined as the probability of failure free operation of abull computer program in a specified environment for a specifiedbull time periodbull Can be measured directly and estimated using historical andbull developmental databull Software reliability problems can usually be traced back tobull errors in design or implementationbull Measures of Reliabilitybull 1048708 Mean time between failure (MTBF) = MTTF + MTTRbull 1048708 MTTF = mean time to failurebull 1048708 MTTR = mean time to repairbull 1048708 Availability = [MTTF (MTTF + MTTR)] x 100
19
ISO 9000 Quality Standards
bull Quality assurance systems are defined as thebull organizational structure responsibilities proceduresbull processes and resources for implementing qualitybull managementbull ISO 9000 describes the quality elements that mustbull be present for a quality assurance system to bebull compliant with the standard but it does not describebull how an organization should implement thesebull elementsbull ISO 90012000 is the quality standard that containsbull 20 requirements that must be present in an effectivebull software quality assurance system
20
- Unit 8 Syllabus
- INDEX Unit 8
- Quality Management
- Slide 4
- Slide 5
- Software Quality Assurance
- Slide 7
- SQA Activities
- Software Reviews
- Formal Technical Review
- Slide 11
- Slide 12
- Slide 13
- Review reporting and Record keeping
- Review Guidelines
- Software Defects
- Statistical Quality Assurance
- Six Sigma for Software Engineering
- Software Reliability
- ISO 9000 Quality Standards
-
Formal Technical Review
Review meeting in FTRbull The Review meeting in a FTR should abide to
the following constraints1Review meeting members should be between
three and five2Every person should prepare for the meeting
and should not require more than two hours of work for each person
3The duration of the review meeting should be less than two hours
11
Formal Technical Reviewbull The focus of FTR is on a work product that is requirement specification a
detailed component design a source code listing for a component
bull The individual who has developed the work product ie the producer informs the project leader that the work product is complete and that a review is required
bull The project leader contacts a review leader who evaluates the product for readiness generates copy of product material and distributes them to two or three review members for advance preparation
bull Each reviewer is expected to spend between one and two hours reviewing the product making notes
12
Formal Technical Reviewbull The review leader also reviews the product and establish an agenda for the
review meeting
bull The review meeting is attended by review leader all reviewers and the producer
bull One of the reviewer act as a recorderwho notes down all important points discussed in the meeting
bull The meeting(FTR) is started by introducing the agenda of meeting and then the producer introduces his product Then the producer ldquowalkthroughrdquo the product the reviewers raise issues which they have prepared in advance
bull If errors are found the recorder notes down
13
Review reporting and Record keeping
bull During the FTR a reviewer( recorder) records all issues that have been raised
bull A review summary report answers three questions1 What was reviewed2 Who reviewed it3 What were the findings and conclusionsbull Review summary report is a single page form with
possible attachmentsbull The review issues list serves two purposes1 To identify problem areas in the product2 To serve as an action item checklist that guides the
producer as corrections are made
14
Review Guidelinesbull Review the product not the producerbull Set an agenda and maintain it bull Limit debate and rebuttalbull Enunciate problem areas but donrsquot attempt to solve every problem
notedbull Take return notes bull Limit the number of participants and insist upon advance
preparationbull Develop a checklist for each product ie likely to be reviewedbull Allocate resources and schedule time for FTRSbull Conduct meaningful training for all reviewerbull Review your early reviews
15
Software Defects
bull Industry studies suggest that design activitiesbull introduce 50-65 of all defects or errorsbull during the software processbull Review techniques have been shown to be upbull to 75 effective in uncovering design flawsbull which ultimately reduces the cost ofbull subsequent activities in the software process
16
Statistical Quality Assurance
bull Information about software defects is collectedbull and categorizedbull Each defect is traced back to its causebull Using the Pareto principle (80 of the defectsbull can be traced to 20 of the causes) isolatebull the vital few defect causesbull Move to correct the problems that caused thebull defects in the vital fewrdquo
17
Six Sigma for Software Engineeringbull The most widely used strategy for statistical quality assurancebull Three core stepsbull 1 Define customer requirements deliverables and project goals via well-definedbull methods of customer communicationbull 2 Measure each existing process and its output to determine current qualitybull performance (eg compute defect metrics)bull 3 Analyze defect metrics and determine vital few causesbull For an existing process that needs improvementbull 1 Improve process by eliminating the root causes for defectsbull 2 Control future work to ensure that future work does not reintroduce causes ofbull defectsbull If new processes are being developedbull 1 Design each new process to avoid root causes of defects and to meetbull customer requirementsbull 2 Verify that the process model will avoid defects and meet customerbull requirements
18
Software Reliabilitybull Defined as the probability of failure free operation of abull computer program in a specified environment for a specifiedbull time periodbull Can be measured directly and estimated using historical andbull developmental databull Software reliability problems can usually be traced back tobull errors in design or implementationbull Measures of Reliabilitybull 1048708 Mean time between failure (MTBF) = MTTF + MTTRbull 1048708 MTTF = mean time to failurebull 1048708 MTTR = mean time to repairbull 1048708 Availability = [MTTF (MTTF + MTTR)] x 100
19
ISO 9000 Quality Standards
bull Quality assurance systems are defined as thebull organizational structure responsibilities proceduresbull processes and resources for implementing qualitybull managementbull ISO 9000 describes the quality elements that mustbull be present for a quality assurance system to bebull compliant with the standard but it does not describebull how an organization should implement thesebull elementsbull ISO 90012000 is the quality standard that containsbull 20 requirements that must be present in an effectivebull software quality assurance system
20
- Unit 8 Syllabus
- INDEX Unit 8
- Quality Management
- Slide 4
- Slide 5
- Software Quality Assurance
- Slide 7
- SQA Activities
- Software Reviews
- Formal Technical Review
- Slide 11
- Slide 12
- Slide 13
- Review reporting and Record keeping
- Review Guidelines
- Software Defects
- Statistical Quality Assurance
- Six Sigma for Software Engineering
- Software Reliability
- ISO 9000 Quality Standards
-
Formal Technical Reviewbull The focus of FTR is on a work product that is requirement specification a
detailed component design a source code listing for a component
bull The individual who has developed the work product ie the producer informs the project leader that the work product is complete and that a review is required
bull The project leader contacts a review leader who evaluates the product for readiness generates copy of product material and distributes them to two or three review members for advance preparation
bull Each reviewer is expected to spend between one and two hours reviewing the product making notes
12
Formal Technical Reviewbull The review leader also reviews the product and establish an agenda for the
review meeting
bull The review meeting is attended by review leader all reviewers and the producer
bull One of the reviewer act as a recorderwho notes down all important points discussed in the meeting
bull The meeting(FTR) is started by introducing the agenda of meeting and then the producer introduces his product Then the producer ldquowalkthroughrdquo the product the reviewers raise issues which they have prepared in advance
bull If errors are found the recorder notes down
13
Review reporting and Record keeping
bull During the FTR a reviewer( recorder) records all issues that have been raised
bull A review summary report answers three questions1 What was reviewed2 Who reviewed it3 What were the findings and conclusionsbull Review summary report is a single page form with
possible attachmentsbull The review issues list serves two purposes1 To identify problem areas in the product2 To serve as an action item checklist that guides the
producer as corrections are made
14
Review Guidelinesbull Review the product not the producerbull Set an agenda and maintain it bull Limit debate and rebuttalbull Enunciate problem areas but donrsquot attempt to solve every problem
notedbull Take return notes bull Limit the number of participants and insist upon advance
preparationbull Develop a checklist for each product ie likely to be reviewedbull Allocate resources and schedule time for FTRSbull Conduct meaningful training for all reviewerbull Review your early reviews
15
Software Defects
bull Industry studies suggest that design activitiesbull introduce 50-65 of all defects or errorsbull during the software processbull Review techniques have been shown to be upbull to 75 effective in uncovering design flawsbull which ultimately reduces the cost ofbull subsequent activities in the software process
16
Statistical Quality Assurance
bull Information about software defects is collectedbull and categorizedbull Each defect is traced back to its causebull Using the Pareto principle (80 of the defectsbull can be traced to 20 of the causes) isolatebull the vital few defect causesbull Move to correct the problems that caused thebull defects in the vital fewrdquo
17
Six Sigma for Software Engineeringbull The most widely used strategy for statistical quality assurancebull Three core stepsbull 1 Define customer requirements deliverables and project goals via well-definedbull methods of customer communicationbull 2 Measure each existing process and its output to determine current qualitybull performance (eg compute defect metrics)bull 3 Analyze defect metrics and determine vital few causesbull For an existing process that needs improvementbull 1 Improve process by eliminating the root causes for defectsbull 2 Control future work to ensure that future work does not reintroduce causes ofbull defectsbull If new processes are being developedbull 1 Design each new process to avoid root causes of defects and to meetbull customer requirementsbull 2 Verify that the process model will avoid defects and meet customerbull requirements
18
Software Reliabilitybull Defined as the probability of failure free operation of abull computer program in a specified environment for a specifiedbull time periodbull Can be measured directly and estimated using historical andbull developmental databull Software reliability problems can usually be traced back tobull errors in design or implementationbull Measures of Reliabilitybull 1048708 Mean time between failure (MTBF) = MTTF + MTTRbull 1048708 MTTF = mean time to failurebull 1048708 MTTR = mean time to repairbull 1048708 Availability = [MTTF (MTTF + MTTR)] x 100
19
ISO 9000 Quality Standards
bull Quality assurance systems are defined as thebull organizational structure responsibilities proceduresbull processes and resources for implementing qualitybull managementbull ISO 9000 describes the quality elements that mustbull be present for a quality assurance system to bebull compliant with the standard but it does not describebull how an organization should implement thesebull elementsbull ISO 90012000 is the quality standard that containsbull 20 requirements that must be present in an effectivebull software quality assurance system
20
- Unit 8 Syllabus
- INDEX Unit 8
- Quality Management
- Slide 4
- Slide 5
- Software Quality Assurance
- Slide 7
- SQA Activities
- Software Reviews
- Formal Technical Review
- Slide 11
- Slide 12
- Slide 13
- Review reporting and Record keeping
- Review Guidelines
- Software Defects
- Statistical Quality Assurance
- Six Sigma for Software Engineering
- Software Reliability
- ISO 9000 Quality Standards
-
Formal Technical Reviewbull The review leader also reviews the product and establish an agenda for the
review meeting
bull The review meeting is attended by review leader all reviewers and the producer
bull One of the reviewer act as a recorderwho notes down all important points discussed in the meeting
bull The meeting(FTR) is started by introducing the agenda of meeting and then the producer introduces his product Then the producer ldquowalkthroughrdquo the product the reviewers raise issues which they have prepared in advance
bull If errors are found the recorder notes down
13
Review reporting and Record keeping
bull During the FTR a reviewer( recorder) records all issues that have been raised
bull A review summary report answers three questions1 What was reviewed2 Who reviewed it3 What were the findings and conclusionsbull Review summary report is a single page form with
possible attachmentsbull The review issues list serves two purposes1 To identify problem areas in the product2 To serve as an action item checklist that guides the
producer as corrections are made
14
Review Guidelinesbull Review the product not the producerbull Set an agenda and maintain it bull Limit debate and rebuttalbull Enunciate problem areas but donrsquot attempt to solve every problem
notedbull Take return notes bull Limit the number of participants and insist upon advance
preparationbull Develop a checklist for each product ie likely to be reviewedbull Allocate resources and schedule time for FTRSbull Conduct meaningful training for all reviewerbull Review your early reviews
15
Software Defects
bull Industry studies suggest that design activitiesbull introduce 50-65 of all defects or errorsbull during the software processbull Review techniques have been shown to be upbull to 75 effective in uncovering design flawsbull which ultimately reduces the cost ofbull subsequent activities in the software process
16
Statistical Quality Assurance
bull Information about software defects is collectedbull and categorizedbull Each defect is traced back to its causebull Using the Pareto principle (80 of the defectsbull can be traced to 20 of the causes) isolatebull the vital few defect causesbull Move to correct the problems that caused thebull defects in the vital fewrdquo
17
Six Sigma for Software Engineeringbull The most widely used strategy for statistical quality assurancebull Three core stepsbull 1 Define customer requirements deliverables and project goals via well-definedbull methods of customer communicationbull 2 Measure each existing process and its output to determine current qualitybull performance (eg compute defect metrics)bull 3 Analyze defect metrics and determine vital few causesbull For an existing process that needs improvementbull 1 Improve process by eliminating the root causes for defectsbull 2 Control future work to ensure that future work does not reintroduce causes ofbull defectsbull If new processes are being developedbull 1 Design each new process to avoid root causes of defects and to meetbull customer requirementsbull 2 Verify that the process model will avoid defects and meet customerbull requirements
18
Software Reliabilitybull Defined as the probability of failure free operation of abull computer program in a specified environment for a specifiedbull time periodbull Can be measured directly and estimated using historical andbull developmental databull Software reliability problems can usually be traced back tobull errors in design or implementationbull Measures of Reliabilitybull 1048708 Mean time between failure (MTBF) = MTTF + MTTRbull 1048708 MTTF = mean time to failurebull 1048708 MTTR = mean time to repairbull 1048708 Availability = [MTTF (MTTF + MTTR)] x 100
19
ISO 9000 Quality Standards
bull Quality assurance systems are defined as thebull organizational structure responsibilities proceduresbull processes and resources for implementing qualitybull managementbull ISO 9000 describes the quality elements that mustbull be present for a quality assurance system to bebull compliant with the standard but it does not describebull how an organization should implement thesebull elementsbull ISO 90012000 is the quality standard that containsbull 20 requirements that must be present in an effectivebull software quality assurance system
20
- Unit 8 Syllabus
- INDEX Unit 8
- Quality Management
- Slide 4
- Slide 5
- Software Quality Assurance
- Slide 7
- SQA Activities
- Software Reviews
- Formal Technical Review
- Slide 11
- Slide 12
- Slide 13
- Review reporting and Record keeping
- Review Guidelines
- Software Defects
- Statistical Quality Assurance
- Six Sigma for Software Engineering
- Software Reliability
- ISO 9000 Quality Standards
-
Review reporting and Record keeping
bull During the FTR a reviewer( recorder) records all issues that have been raised
bull A review summary report answers three questions1 What was reviewed2 Who reviewed it3 What were the findings and conclusionsbull Review summary report is a single page form with
possible attachmentsbull The review issues list serves two purposes1 To identify problem areas in the product2 To serve as an action item checklist that guides the
producer as corrections are made
14
Review Guidelinesbull Review the product not the producerbull Set an agenda and maintain it bull Limit debate and rebuttalbull Enunciate problem areas but donrsquot attempt to solve every problem
notedbull Take return notes bull Limit the number of participants and insist upon advance
preparationbull Develop a checklist for each product ie likely to be reviewedbull Allocate resources and schedule time for FTRSbull Conduct meaningful training for all reviewerbull Review your early reviews
15
Software Defects
bull Industry studies suggest that design activitiesbull introduce 50-65 of all defects or errorsbull during the software processbull Review techniques have been shown to be upbull to 75 effective in uncovering design flawsbull which ultimately reduces the cost ofbull subsequent activities in the software process
16
Statistical Quality Assurance
bull Information about software defects is collectedbull and categorizedbull Each defect is traced back to its causebull Using the Pareto principle (80 of the defectsbull can be traced to 20 of the causes) isolatebull the vital few defect causesbull Move to correct the problems that caused thebull defects in the vital fewrdquo
17
Six Sigma for Software Engineeringbull The most widely used strategy for statistical quality assurancebull Three core stepsbull 1 Define customer requirements deliverables and project goals via well-definedbull methods of customer communicationbull 2 Measure each existing process and its output to determine current qualitybull performance (eg compute defect metrics)bull 3 Analyze defect metrics and determine vital few causesbull For an existing process that needs improvementbull 1 Improve process by eliminating the root causes for defectsbull 2 Control future work to ensure that future work does not reintroduce causes ofbull defectsbull If new processes are being developedbull 1 Design each new process to avoid root causes of defects and to meetbull customer requirementsbull 2 Verify that the process model will avoid defects and meet customerbull requirements
18
Software Reliabilitybull Defined as the probability of failure free operation of abull computer program in a specified environment for a specifiedbull time periodbull Can be measured directly and estimated using historical andbull developmental databull Software reliability problems can usually be traced back tobull errors in design or implementationbull Measures of Reliabilitybull 1048708 Mean time between failure (MTBF) = MTTF + MTTRbull 1048708 MTTF = mean time to failurebull 1048708 MTTR = mean time to repairbull 1048708 Availability = [MTTF (MTTF + MTTR)] x 100
19
ISO 9000 Quality Standards
bull Quality assurance systems are defined as thebull organizational structure responsibilities proceduresbull processes and resources for implementing qualitybull managementbull ISO 9000 describes the quality elements that mustbull be present for a quality assurance system to bebull compliant with the standard but it does not describebull how an organization should implement thesebull elementsbull ISO 90012000 is the quality standard that containsbull 20 requirements that must be present in an effectivebull software quality assurance system
20
- Unit 8 Syllabus
- INDEX Unit 8
- Quality Management
- Slide 4
- Slide 5
- Software Quality Assurance
- Slide 7
- SQA Activities
- Software Reviews
- Formal Technical Review
- Slide 11
- Slide 12
- Slide 13
- Review reporting and Record keeping
- Review Guidelines
- Software Defects
- Statistical Quality Assurance
- Six Sigma for Software Engineering
- Software Reliability
- ISO 9000 Quality Standards
-
Review Guidelinesbull Review the product not the producerbull Set an agenda and maintain it bull Limit debate and rebuttalbull Enunciate problem areas but donrsquot attempt to solve every problem
notedbull Take return notes bull Limit the number of participants and insist upon advance
preparationbull Develop a checklist for each product ie likely to be reviewedbull Allocate resources and schedule time for FTRSbull Conduct meaningful training for all reviewerbull Review your early reviews
15
Software Defects
bull Industry studies suggest that design activitiesbull introduce 50-65 of all defects or errorsbull during the software processbull Review techniques have been shown to be upbull to 75 effective in uncovering design flawsbull which ultimately reduces the cost ofbull subsequent activities in the software process
16
Statistical Quality Assurance
bull Information about software defects is collectedbull and categorizedbull Each defect is traced back to its causebull Using the Pareto principle (80 of the defectsbull can be traced to 20 of the causes) isolatebull the vital few defect causesbull Move to correct the problems that caused thebull defects in the vital fewrdquo
17
Six Sigma for Software Engineeringbull The most widely used strategy for statistical quality assurancebull Three core stepsbull 1 Define customer requirements deliverables and project goals via well-definedbull methods of customer communicationbull 2 Measure each existing process and its output to determine current qualitybull performance (eg compute defect metrics)bull 3 Analyze defect metrics and determine vital few causesbull For an existing process that needs improvementbull 1 Improve process by eliminating the root causes for defectsbull 2 Control future work to ensure that future work does not reintroduce causes ofbull defectsbull If new processes are being developedbull 1 Design each new process to avoid root causes of defects and to meetbull customer requirementsbull 2 Verify that the process model will avoid defects and meet customerbull requirements
18
Software Reliabilitybull Defined as the probability of failure free operation of abull computer program in a specified environment for a specifiedbull time periodbull Can be measured directly and estimated using historical andbull developmental databull Software reliability problems can usually be traced back tobull errors in design or implementationbull Measures of Reliabilitybull 1048708 Mean time between failure (MTBF) = MTTF + MTTRbull 1048708 MTTF = mean time to failurebull 1048708 MTTR = mean time to repairbull 1048708 Availability = [MTTF (MTTF + MTTR)] x 100
19
ISO 9000 Quality Standards
bull Quality assurance systems are defined as thebull organizational structure responsibilities proceduresbull processes and resources for implementing qualitybull managementbull ISO 9000 describes the quality elements that mustbull be present for a quality assurance system to bebull compliant with the standard but it does not describebull how an organization should implement thesebull elementsbull ISO 90012000 is the quality standard that containsbull 20 requirements that must be present in an effectivebull software quality assurance system
20
- Unit 8 Syllabus
- INDEX Unit 8
- Quality Management
- Slide 4
- Slide 5
- Software Quality Assurance
- Slide 7
- SQA Activities
- Software Reviews
- Formal Technical Review
- Slide 11
- Slide 12
- Slide 13
- Review reporting and Record keeping
- Review Guidelines
- Software Defects
- Statistical Quality Assurance
- Six Sigma for Software Engineering
- Software Reliability
- ISO 9000 Quality Standards
-
Software Defects
bull Industry studies suggest that design activitiesbull introduce 50-65 of all defects or errorsbull during the software processbull Review techniques have been shown to be upbull to 75 effective in uncovering design flawsbull which ultimately reduces the cost ofbull subsequent activities in the software process
16
Statistical Quality Assurance
bull Information about software defects is collectedbull and categorizedbull Each defect is traced back to its causebull Using the Pareto principle (80 of the defectsbull can be traced to 20 of the causes) isolatebull the vital few defect causesbull Move to correct the problems that caused thebull defects in the vital fewrdquo
17
Six Sigma for Software Engineeringbull The most widely used strategy for statistical quality assurancebull Three core stepsbull 1 Define customer requirements deliverables and project goals via well-definedbull methods of customer communicationbull 2 Measure each existing process and its output to determine current qualitybull performance (eg compute defect metrics)bull 3 Analyze defect metrics and determine vital few causesbull For an existing process that needs improvementbull 1 Improve process by eliminating the root causes for defectsbull 2 Control future work to ensure that future work does not reintroduce causes ofbull defectsbull If new processes are being developedbull 1 Design each new process to avoid root causes of defects and to meetbull customer requirementsbull 2 Verify that the process model will avoid defects and meet customerbull requirements
18
Software Reliabilitybull Defined as the probability of failure free operation of abull computer program in a specified environment for a specifiedbull time periodbull Can be measured directly and estimated using historical andbull developmental databull Software reliability problems can usually be traced back tobull errors in design or implementationbull Measures of Reliabilitybull 1048708 Mean time between failure (MTBF) = MTTF + MTTRbull 1048708 MTTF = mean time to failurebull 1048708 MTTR = mean time to repairbull 1048708 Availability = [MTTF (MTTF + MTTR)] x 100
19
ISO 9000 Quality Standards
bull Quality assurance systems are defined as thebull organizational structure responsibilities proceduresbull processes and resources for implementing qualitybull managementbull ISO 9000 describes the quality elements that mustbull be present for a quality assurance system to bebull compliant with the standard but it does not describebull how an organization should implement thesebull elementsbull ISO 90012000 is the quality standard that containsbull 20 requirements that must be present in an effectivebull software quality assurance system
20
- Unit 8 Syllabus
- INDEX Unit 8
- Quality Management
- Slide 4
- Slide 5
- Software Quality Assurance
- Slide 7
- SQA Activities
- Software Reviews
- Formal Technical Review
- Slide 11
- Slide 12
- Slide 13
- Review reporting and Record keeping
- Review Guidelines
- Software Defects
- Statistical Quality Assurance
- Six Sigma for Software Engineering
- Software Reliability
- ISO 9000 Quality Standards
-
Statistical Quality Assurance
bull Information about software defects is collectedbull and categorizedbull Each defect is traced back to its causebull Using the Pareto principle (80 of the defectsbull can be traced to 20 of the causes) isolatebull the vital few defect causesbull Move to correct the problems that caused thebull defects in the vital fewrdquo
17
Six Sigma for Software Engineeringbull The most widely used strategy for statistical quality assurancebull Three core stepsbull 1 Define customer requirements deliverables and project goals via well-definedbull methods of customer communicationbull 2 Measure each existing process and its output to determine current qualitybull performance (eg compute defect metrics)bull 3 Analyze defect metrics and determine vital few causesbull For an existing process that needs improvementbull 1 Improve process by eliminating the root causes for defectsbull 2 Control future work to ensure that future work does not reintroduce causes ofbull defectsbull If new processes are being developedbull 1 Design each new process to avoid root causes of defects and to meetbull customer requirementsbull 2 Verify that the process model will avoid defects and meet customerbull requirements
18
Software Reliabilitybull Defined as the probability of failure free operation of abull computer program in a specified environment for a specifiedbull time periodbull Can be measured directly and estimated using historical andbull developmental databull Software reliability problems can usually be traced back tobull errors in design or implementationbull Measures of Reliabilitybull 1048708 Mean time between failure (MTBF) = MTTF + MTTRbull 1048708 MTTF = mean time to failurebull 1048708 MTTR = mean time to repairbull 1048708 Availability = [MTTF (MTTF + MTTR)] x 100
19
ISO 9000 Quality Standards
bull Quality assurance systems are defined as thebull organizational structure responsibilities proceduresbull processes and resources for implementing qualitybull managementbull ISO 9000 describes the quality elements that mustbull be present for a quality assurance system to bebull compliant with the standard but it does not describebull how an organization should implement thesebull elementsbull ISO 90012000 is the quality standard that containsbull 20 requirements that must be present in an effectivebull software quality assurance system
20
- Unit 8 Syllabus
- INDEX Unit 8
- Quality Management
- Slide 4
- Slide 5
- Software Quality Assurance
- Slide 7
- SQA Activities
- Software Reviews
- Formal Technical Review
- Slide 11
- Slide 12
- Slide 13
- Review reporting and Record keeping
- Review Guidelines
- Software Defects
- Statistical Quality Assurance
- Six Sigma for Software Engineering
- Software Reliability
- ISO 9000 Quality Standards
-
Six Sigma for Software Engineeringbull The most widely used strategy for statistical quality assurancebull Three core stepsbull 1 Define customer requirements deliverables and project goals via well-definedbull methods of customer communicationbull 2 Measure each existing process and its output to determine current qualitybull performance (eg compute defect metrics)bull 3 Analyze defect metrics and determine vital few causesbull For an existing process that needs improvementbull 1 Improve process by eliminating the root causes for defectsbull 2 Control future work to ensure that future work does not reintroduce causes ofbull defectsbull If new processes are being developedbull 1 Design each new process to avoid root causes of defects and to meetbull customer requirementsbull 2 Verify that the process model will avoid defects and meet customerbull requirements
18
Software Reliabilitybull Defined as the probability of failure free operation of abull computer program in a specified environment for a specifiedbull time periodbull Can be measured directly and estimated using historical andbull developmental databull Software reliability problems can usually be traced back tobull errors in design or implementationbull Measures of Reliabilitybull 1048708 Mean time between failure (MTBF) = MTTF + MTTRbull 1048708 MTTF = mean time to failurebull 1048708 MTTR = mean time to repairbull 1048708 Availability = [MTTF (MTTF + MTTR)] x 100
19
ISO 9000 Quality Standards
bull Quality assurance systems are defined as thebull organizational structure responsibilities proceduresbull processes and resources for implementing qualitybull managementbull ISO 9000 describes the quality elements that mustbull be present for a quality assurance system to bebull compliant with the standard but it does not describebull how an organization should implement thesebull elementsbull ISO 90012000 is the quality standard that containsbull 20 requirements that must be present in an effectivebull software quality assurance system
20
- Unit 8 Syllabus
- INDEX Unit 8
- Quality Management
- Slide 4
- Slide 5
- Software Quality Assurance
- Slide 7
- SQA Activities
- Software Reviews
- Formal Technical Review
- Slide 11
- Slide 12
- Slide 13
- Review reporting and Record keeping
- Review Guidelines
- Software Defects
- Statistical Quality Assurance
- Six Sigma for Software Engineering
- Software Reliability
- ISO 9000 Quality Standards
-
Software Reliabilitybull Defined as the probability of failure free operation of abull computer program in a specified environment for a specifiedbull time periodbull Can be measured directly and estimated using historical andbull developmental databull Software reliability problems can usually be traced back tobull errors in design or implementationbull Measures of Reliabilitybull 1048708 Mean time between failure (MTBF) = MTTF + MTTRbull 1048708 MTTF = mean time to failurebull 1048708 MTTR = mean time to repairbull 1048708 Availability = [MTTF (MTTF + MTTR)] x 100
19
ISO 9000 Quality Standards
bull Quality assurance systems are defined as thebull organizational structure responsibilities proceduresbull processes and resources for implementing qualitybull managementbull ISO 9000 describes the quality elements that mustbull be present for a quality assurance system to bebull compliant with the standard but it does not describebull how an organization should implement thesebull elementsbull ISO 90012000 is the quality standard that containsbull 20 requirements that must be present in an effectivebull software quality assurance system
20
- Unit 8 Syllabus
- INDEX Unit 8
- Quality Management
- Slide 4
- Slide 5
- Software Quality Assurance
- Slide 7
- SQA Activities
- Software Reviews
- Formal Technical Review
- Slide 11
- Slide 12
- Slide 13
- Review reporting and Record keeping
- Review Guidelines
- Software Defects
- Statistical Quality Assurance
- Six Sigma for Software Engineering
- Software Reliability
- ISO 9000 Quality Standards
-
ISO 9000 Quality Standards
bull Quality assurance systems are defined as thebull organizational structure responsibilities proceduresbull processes and resources for implementing qualitybull managementbull ISO 9000 describes the quality elements that mustbull be present for a quality assurance system to bebull compliant with the standard but it does not describebull how an organization should implement thesebull elementsbull ISO 90012000 is the quality standard that containsbull 20 requirements that must be present in an effectivebull software quality assurance system
20
- Unit 8 Syllabus
- INDEX Unit 8
- Quality Management
- Slide 4
- Slide 5
- Software Quality Assurance
- Slide 7
- SQA Activities
- Software Reviews
- Formal Technical Review
- Slide 11
- Slide 12
- Slide 13
- Review reporting and Record keeping
- Review Guidelines
- Software Defects
- Statistical Quality Assurance
- Six Sigma for Software Engineering
- Software Reliability
- ISO 9000 Quality Standards
-