Introduction-to-software-quality-assurance-1210258325202994-9.ppt 6g3f2b
This document was ed by and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this report form. Report r6l17
Overview 4q3b3c
& View Introduction-to-software-quality-assurance-1210258325202994-9.ppt as PDF for free.
More details 26j3b
- Words: 1,607
- Pages: 31
Introduction to Software Quality Assurance (SQA)
02/24/15
Compiled by Arthur
1
Software Quality (IEEE Standard Glossary) • The degree to which a system, component, or process meets specified requirements. • The degree to which a system, component or process meets customer or needs or expectations. 02/24/15
Compiled by Arthur
2
Software Quality Attributes http://satc.gsfc.nasa.gov//STC_APR96/qualtiy/stc_qual.html
02/24/15
Compiled by Arthur
3
SQA (via IEEE) • A planned and systematic pattern of all actions necessary to provide adequate confidence that an item or product conforms to established technical requirements. • A set of activities designed to evaluate the process by which products are developed or manufactured. Contrast with: quality control (1). 02/24/15
Compiled by Arthur
4
IEEE Std 730-2002 (Revision of IEEE Std 730-1998) IEEE Standard for Software Quality Assurance Plans
02/24/15
Compiled by Arthur
5
Required SQAP Sections • • • • •
Purpose Reference Documents Management Documentation Standards, practices, conventions, and metrics • Test • Problem Reporting and corrective action • Tools, techniques, and methodologies 02/24/15
• Media control • Supplier control • Records collection, maintenance, and retention • Training • Risk management • Glossary • SQAP change procedure and history
Compiled by Arthur
6
4.4 Documentation (section 4 of the SQAP) • • • •
4.4.2.1 Software requirements description (SRD) 4.4.2.2 Software design description (SDD) 4.4.2.3 Verification and validation plans 4.4.2.4 Verification results report and validation results report • 4.4.2.5 documentation • 4.4.2.6 Software configuration management plan (SCMP) • 4.4.3 Other documentation – – – –
a) Development process plan b) Software development standards description c) Software engineering methods/procedures/tools description d) Software project management plan (see IEEE Std 1058™1998 [B13]) – e) Maintenance plan (see IEEE Std 1219™-1998 [B15]) – f) Software safety plans (see IEEE Std 1228™-1994 [B16]) – g) Software integration plan
02/24/15
Compiled by Arthur
7
4.5 Standards, practices, conventions, and metrics (section 5 of the SQAP) • 4.5.1 Purpose • 4.5.2 Content – The subjects covered shall include the basic technical, design, and programming activities involved, such as documentation, variable and module naming, programming, inspection, and testing. As a minimum, the following information shall be provided (see IEEE Std 982.1™-1988 [B6] and IEEE Std 982.2™-1988 [B7]): • • • • • •
02/24/15
a) Documentation standards b) Design standards c) Coding standards d) Commentary standards e) Testing standards and practices f) Selected software quality assurance product and process metrics
Compiled by Arthur
8
4.6 Software reviews (section 6 of the SQAP) • •
4.6.1 Purpose 4.6.2 Minimum requirements – – – – – – –
4.6.2.1 Software specifications review (SSR) 4.6.2.2 Architecture design review (ADR) 4.6.2.3 Detailed design review (DDR) 4.6.2.4 Verification and validation plan review 4.6.2.5 Functional audit 4.6.2.6 Physical audit 4.6.2.7 In-process audits • • • •
– – – –
a) Code versus design documentation b) Interface specifications (hardware and software) c) Design implementations versus functional requirements d) Functional requirements versus test descriptions
4.6.2.8 Managerial reviews 4.6.2.9 Software configuration management plan review (SCMPR) 4.6.2.10 Post-implementation review 4.6.3 Other reviews and audits
02/24/15
Compiled by Arthur
9
Software Capability Maturity Model SW-CMM
02/24/15
Compiled by Arthur
10
SW-CMM Key Practices for Software Quality Assurance • A SQA plan is prepared for the SW project ATADP. • The SQA group’s activities are performed IAW the SQA plan. • The SQA group participates in the preparation & review of the project’s SW dev plan, standards, & procedures. • The SQA group reviews the SWE activities to compliance. • The SQA group audits designated SW work products to compliance. • The SQA group periodically reports the results of its activities to the SWE group. • Deviations identified in the SW activities & SW work products are documented & handled ATADP. • The SQA group conducts periodic reviews of its activities & findings with the customer’s SQA personnel, as appropriate.
02/24/15
Compiled by Arthur
11
RUP Steps for SQA All the following text is from Rational Unified Process 7.0. 02/24/15
Compiled by Arthur
12
Ensure Quality Objectives are Defined for the Project • The Project Manager may not necessarily define the quality goals for the project, but ensures that these definitions are created and agreed by the customer, and captured ultimately in the Software Requirements Specification. The developing organization may also have a standard set of quality goals, in a quality policy statement, which can form the basis for these definitions. • Where possible, these objectives should be described in measurable . For example: – "Zero known severity 1 defects" (...and include a definition of a severity 1 defect) – "Maximum 3 second response time" – " can pick up software and begin entering information within 1 hour"
02/24/15
Compiled by Arthur
13
Define Quality Assurance Roles and Responsibilities • The next step is to define the organization, roles and responsibilities that will participate in these tasks. • This should include the reporting channel for the results of Quality Assurance reviews. • In many situations, the Quality Assurance task should submit its reports directly to the Project Review Authority. • The Rational Unified Process recommends that the Software Engineering Process Authority (SEPA) should have responsibility for the process aspects of quality, and perform process reviews and audits, as well as ensuring the proper planning and conduct of the review events described in the Review and Audit section of the Quality Assurance Plan.
02/24/15
Compiled by Arthur
14
Coordinate With Developers of Referenced Plans • The Quality Assurance Plan also references a number of other plans describing project standards and how various ing process (e.g. configuration management) to be handled. • This information is used to help determine the types of Quality Assurance reviews that will be done, and their frequency. • The referenced plans would normally include the following: – – – – – – – –
Documentation Plan Measurement Plan Risk Management Plan Problem Resolution Plan Configuration Management Plan Software Development Plan Test Plan Subcontractor Management Plan
02/24/15
Compiled by Arthur
15
Define Quality Assurance Tasks and Schedule • Identify the tasks of Quality Assurance. Typically these reviews would include: – Audit/review of project plans to ensure they follow the defined delivery process for the project. – Audit/review of project to ensure the work performed is following the project plans. – Approval of deviations from the standard organizational project processes. – Process improvement assessments
• The Project Review Authority and Project Manager together determine the schedule for Quality Assurance reviews and audits, and the schedule is captured in the project and iteration plan, which may then be referenced from the Quality Assurance Plan. • The contract may also allow the customer to request audits.
02/24/15
Compiled by Arthur
16
What SWEBOK Says about SQA All text is taken from the 2004 Guide to the SWEBOK. I formatted the text to highlight certain parts. 02/24/15
Compiled by Arthur
17
• SQA processes provide assurance that the – software products and – processes
• in the project life cycle – conform to their specified requirements
• by planning, enacting, and performing a set of activities to provide adequate – confidence
• that quality is – being built into
• the software. 02/24/15
Compiled by Arthur
18
• This means ensuring that the problem is clearly and adequately stated and that the solution’s requirements are properly defined and expressed.
02/24/15
Compiled by Arthur
19
• SQA seeks to maintain the quality throughout the development and maintenance of the product by the execution of a variety of activities at each stage which can result in early identification of problems, an almost inevitable feature of any complex activity. 02/24/15
Compiled by Arthur
20
• The role of SQA with respect to process is to ensure that planned processes are appropriate and later implemented according to plan, and that relevant measurement processes are provided to the appropriate organization. 02/24/15
Compiled by Arthur
21
• The SQA plan defines the means that will be used to ensure that software developed for a specific product satisfies the ’s requirements and is of the highest quality possible within project constraints.
02/24/15
Compiled by Arthur
22
• In order to do so, it must first ensure that the quality target is clearly defined and understood.
02/24/15
Compiled by Arthur
23
• It must consider management, development, and maintenance plans for the software.
02/24/15
Compiled by Arthur
24
• Refer to standard (IEEE730-98) for details.
02/24/15
Compiled by Arthur
25
• The specific quality activities and tasks are laid out, with their costs and resource requirements, their overall management objectives, and their schedule in relation to those objectives in the software engineering management, development, or maintenance plans.
02/24/15
Compiled by Arthur
26
• The SQA plan should be consistent with the software configuration management plan (refer to the Software Configuration Management KA).
02/24/15
Compiled by Arthur
27
• The SQA plan identifies documents, standards, practices, and conventions governing the project and how they will be checked and monitored to ensure adequacy and compliance.
02/24/15
Compiled by Arthur
28
• The SQA plan also identifies measures, statistical techniques, procedures for problem reporting and corrective action, resources such as tools, techniques, and methodologies, security for physical media, training, and SQA reporting and documentation. 02/24/15
Compiled by Arthur
29
• Moreover, the SQA plan addresses the software quality assurance activities of any other type of activity described in the software plans, such as procurement of supplier software to the project or commercial off-the-shelf software (COTS) installation, and service after delivery of the software. 02/24/15
Compiled by Arthur
30
• It can also contain acceptance criteria as well as reporting and management activities which are critical to software quality.
02/24/15
Compiled by Arthur
31
02/24/15
Compiled by Arthur
1
Software Quality (IEEE Standard Glossary) • The degree to which a system, component, or process meets specified requirements. • The degree to which a system, component or process meets customer or needs or expectations. 02/24/15
Compiled by Arthur
2
Software Quality Attributes http://satc.gsfc.nasa.gov//STC_APR96/qualtiy/stc_qual.html
02/24/15
Compiled by Arthur
3
SQA (via IEEE) • A planned and systematic pattern of all actions necessary to provide adequate confidence that an item or product conforms to established technical requirements. • A set of activities designed to evaluate the process by which products are developed or manufactured. Contrast with: quality control (1). 02/24/15
Compiled by Arthur
4
IEEE Std 730-2002 (Revision of IEEE Std 730-1998) IEEE Standard for Software Quality Assurance Plans
02/24/15
Compiled by Arthur
5
Required SQAP Sections • • • • •
Purpose Reference Documents Management Documentation Standards, practices, conventions, and metrics • Test • Problem Reporting and corrective action • Tools, techniques, and methodologies 02/24/15
• Media control • Supplier control • Records collection, maintenance, and retention • Training • Risk management • Glossary • SQAP change procedure and history
Compiled by Arthur
6
4.4 Documentation (section 4 of the SQAP) • • • •
4.4.2.1 Software requirements description (SRD) 4.4.2.2 Software design description (SDD) 4.4.2.3 Verification and validation plans 4.4.2.4 Verification results report and validation results report • 4.4.2.5 documentation • 4.4.2.6 Software configuration management plan (SCMP) • 4.4.3 Other documentation – – – –
a) Development process plan b) Software development standards description c) Software engineering methods/procedures/tools description d) Software project management plan (see IEEE Std 1058™1998 [B13]) – e) Maintenance plan (see IEEE Std 1219™-1998 [B15]) – f) Software safety plans (see IEEE Std 1228™-1994 [B16]) – g) Software integration plan
02/24/15
Compiled by Arthur
7
4.5 Standards, practices, conventions, and metrics (section 5 of the SQAP) • 4.5.1 Purpose • 4.5.2 Content – The subjects covered shall include the basic technical, design, and programming activities involved, such as documentation, variable and module naming, programming, inspection, and testing. As a minimum, the following information shall be provided (see IEEE Std 982.1™-1988 [B6] and IEEE Std 982.2™-1988 [B7]): • • • • • •
02/24/15
a) Documentation standards b) Design standards c) Coding standards d) Commentary standards e) Testing standards and practices f) Selected software quality assurance product and process metrics
Compiled by Arthur
8
4.6 Software reviews (section 6 of the SQAP) • •
4.6.1 Purpose 4.6.2 Minimum requirements – – – – – – –
4.6.2.1 Software specifications review (SSR) 4.6.2.2 Architecture design review (ADR) 4.6.2.3 Detailed design review (DDR) 4.6.2.4 Verification and validation plan review 4.6.2.5 Functional audit 4.6.2.6 Physical audit 4.6.2.7 In-process audits • • • •
– – – –
a) Code versus design documentation b) Interface specifications (hardware and software) c) Design implementations versus functional requirements d) Functional requirements versus test descriptions
4.6.2.8 Managerial reviews 4.6.2.9 Software configuration management plan review (SCMPR) 4.6.2.10 Post-implementation review 4.6.3 Other reviews and audits
02/24/15
Compiled by Arthur
9
Software Capability Maturity Model SW-CMM
02/24/15
Compiled by Arthur
10
SW-CMM Key Practices for Software Quality Assurance • A SQA plan is prepared for the SW project ATADP. • The SQA group’s activities are performed IAW the SQA plan. • The SQA group participates in the preparation & review of the project’s SW dev plan, standards, & procedures. • The SQA group reviews the SWE activities to compliance. • The SQA group audits designated SW work products to compliance. • The SQA group periodically reports the results of its activities to the SWE group. • Deviations identified in the SW activities & SW work products are documented & handled ATADP. • The SQA group conducts periodic reviews of its activities & findings with the customer’s SQA personnel, as appropriate.
02/24/15
Compiled by Arthur
11
RUP Steps for SQA All the following text is from Rational Unified Process 7.0. 02/24/15
Compiled by Arthur
12
Ensure Quality Objectives are Defined for the Project • The Project Manager may not necessarily define the quality goals for the project, but ensures that these definitions are created and agreed by the customer, and captured ultimately in the Software Requirements Specification. The developing organization may also have a standard set of quality goals, in a quality policy statement, which can form the basis for these definitions. • Where possible, these objectives should be described in measurable . For example: – "Zero known severity 1 defects" (...and include a definition of a severity 1 defect) – "Maximum 3 second response time" – " can pick up software and begin entering information within 1 hour"
02/24/15
Compiled by Arthur
13
Define Quality Assurance Roles and Responsibilities • The next step is to define the organization, roles and responsibilities that will participate in these tasks. • This should include the reporting channel for the results of Quality Assurance reviews. • In many situations, the Quality Assurance task should submit its reports directly to the Project Review Authority. • The Rational Unified Process recommends that the Software Engineering Process Authority (SEPA) should have responsibility for the process aspects of quality, and perform process reviews and audits, as well as ensuring the proper planning and conduct of the review events described in the Review and Audit section of the Quality Assurance Plan.
02/24/15
Compiled by Arthur
14
Coordinate With Developers of Referenced Plans • The Quality Assurance Plan also references a number of other plans describing project standards and how various ing process (e.g. configuration management) to be handled. • This information is used to help determine the types of Quality Assurance reviews that will be done, and their frequency. • The referenced plans would normally include the following: – – – – – – – –
Documentation Plan Measurement Plan Risk Management Plan Problem Resolution Plan Configuration Management Plan Software Development Plan Test Plan Subcontractor Management Plan
02/24/15
Compiled by Arthur
15
Define Quality Assurance Tasks and Schedule • Identify the tasks of Quality Assurance. Typically these reviews would include: – Audit/review of project plans to ensure they follow the defined delivery process for the project. – Audit/review of project to ensure the work performed is following the project plans. – Approval of deviations from the standard organizational project processes. – Process improvement assessments
• The Project Review Authority and Project Manager together determine the schedule for Quality Assurance reviews and audits, and the schedule is captured in the project and iteration plan, which may then be referenced from the Quality Assurance Plan. • The contract may also allow the customer to request audits.
02/24/15
Compiled by Arthur
16
What SWEBOK Says about SQA All text is taken from the 2004 Guide to the SWEBOK. I formatted the text to highlight certain parts. 02/24/15
Compiled by Arthur
17
• SQA processes provide assurance that the – software products and – processes
• in the project life cycle – conform to their specified requirements
• by planning, enacting, and performing a set of activities to provide adequate – confidence
• that quality is – being built into
• the software. 02/24/15
Compiled by Arthur
18
• This means ensuring that the problem is clearly and adequately stated and that the solution’s requirements are properly defined and expressed.
02/24/15
Compiled by Arthur
19
• SQA seeks to maintain the quality throughout the development and maintenance of the product by the execution of a variety of activities at each stage which can result in early identification of problems, an almost inevitable feature of any complex activity. 02/24/15
Compiled by Arthur
20
• The role of SQA with respect to process is to ensure that planned processes are appropriate and later implemented according to plan, and that relevant measurement processes are provided to the appropriate organization. 02/24/15
Compiled by Arthur
21
• The SQA plan defines the means that will be used to ensure that software developed for a specific product satisfies the ’s requirements and is of the highest quality possible within project constraints.
02/24/15
Compiled by Arthur
22
• In order to do so, it must first ensure that the quality target is clearly defined and understood.
02/24/15
Compiled by Arthur
23
• It must consider management, development, and maintenance plans for the software.
02/24/15
Compiled by Arthur
24
• Refer to standard (IEEE730-98) for details.
02/24/15
Compiled by Arthur
25
• The specific quality activities and tasks are laid out, with their costs and resource requirements, their overall management objectives, and their schedule in relation to those objectives in the software engineering management, development, or maintenance plans.
02/24/15
Compiled by Arthur
26
• The SQA plan should be consistent with the software configuration management plan (refer to the Software Configuration Management KA).
02/24/15
Compiled by Arthur
27
• The SQA plan identifies documents, standards, practices, and conventions governing the project and how they will be checked and monitored to ensure adequacy and compliance.
02/24/15
Compiled by Arthur
28
• The SQA plan also identifies measures, statistical techniques, procedures for problem reporting and corrective action, resources such as tools, techniques, and methodologies, security for physical media, training, and SQA reporting and documentation. 02/24/15
Compiled by Arthur
29
• Moreover, the SQA plan addresses the software quality assurance activities of any other type of activity described in the software plans, such as procurement of supplier software to the project or commercial off-the-shelf software (COTS) installation, and service after delivery of the software. 02/24/15
Compiled by Arthur
30
• It can also contain acceptance criteria as well as reporting and management activities which are critical to software quality.
02/24/15
Compiled by Arthur
31
More Documents from "abbasamir2998" 524b4t
Introduction-to-software-quality-assurance-1210258325202994-9.ppt 6g3f2b
December 2019 16
Project Scope Management 3z543k
April 2022 0