SQA ALMOST COMPLETE QUIZ

Quality Assurance

It measures the quality of processes used to create a quality product. It is a system of management activities, It is a preventive process, It is applied throughout the entire life cycle and deals with the process.

Quality Control

Control Involves checking the product against a predetermined set of requirements and validating that the product meets those requirements.

Software Testing

Is a way of exploring a system to check how it operates to find possible defects.

It employs various methods to test the product, locate defects and check if they are resolved.

Software Quality Assurance

Is a set of methods and activities designed to ensure that the developed software corresponds to all the specifications.

It is a planned strategy that establishes procedures to prevent defects in the process of software development.

It deals with the management, methods and techniques of development, project analysis, checklists, etc.

QA vs QC vs Testing

[Quality Assurance[Quality Control[Testing]]]

Testing - Finds defects in the product

Quality Control - Evaluates the quality, estimate if it meets customer's expectations.

Quality Assurance - Define and improve the quality related processes and procedures to ensure quality.

Chapter 2

The differences between a Software Product & Industrial Product?

High complexity

Invisibility of the product

Opportunities/stages to detect defects

High complexity:

The potential ways in which a software product can be used with different data / data paths reflecting different incoming data is almost infinite

Manner in which industrial products can be used are usually well-defined

Think about software: every loop with different values of data reflects a different opportunity to see software fail

Invisibility of the product:

-In an industrial product, missing parts are obvious.

•Something missing? Easily identified.

-Not so in software products.

•May not be noticeable for years - if at all!

•INTEL: Almost every computer with an Intel chip dating back to 2011

-allowed hackers to effectively exploit design flaws

Opportunities/stages to detect defects:

Product Development

Product Planning

Product Manufacturing

Product Development (Industrial vs Software)

-Industrial: test product, voltages, performance, strength, size ....ready to distribute to markets

-Computer Software: once prototype and system testing are concluded, product is ready for deployment

Product Production Planning (Industrial vs Software)

Industrial: Often needs new tooling approaches, assembly lines, new manufacturing processes.

•Results in additional 'looks' at products

•One could say that there is a better chance to discover defects

Computer Software: No real additional 'look-see'

•Packages shrink-wrapped, printed, distributed to public

•No real chance to discover additional defects.

Product Manufacturing (Industrial vs Software)

-Industrial:

•Usually defects uncovered here

•Easily fixed

-Computer Software:

•We merely copyright, print copies of software and manuals

•No real chance for additional quality reviews

•No real chance for discovering additional defects

When is the best time to detect defects?

Software Development Process itself

These characteristics of software - complexity, invisibility, and limited opportunity to detect bugs has led to the development of:

ISO Guidelines and an awareness of real SQA methodology

The characteristics of the SQA environment process:

Being Contracted

Subjection to customer-supplier relationship

Requirement for teamwork

Need for cooperation and coordination with other development teams.

Need for interfaces with other software systems

Need to continue carrying out a project while the team changes

Need to continue maintaining the software system for years

Being Contracted:

Professional software development is almost always contracted

Have requirements / supplied requirements (hopefully)

-But may have in-house customer representatives.

-Or, customer representatives available...

Budget

Time schedule

Subject to Customer-Supplier Relationship

In professional software development, there is a constant (hopefully) oversight between customer and developer.

•Changes will occur

•Criticisms will arise

•Cooperation is critical to overall project success

-Customer availability/relationship is essential

-Can be problematic whether representatives are in-house or not

Required Teamwork:

-Due to

•Time required for development

-Workload is too much for a single person

-May over or under estimate deliverable timelines

•A frequent variety of experts needed

-Database; networking; algorithms; ...

•Need 'independent' reviews to ensure quality

•Who is 'on the team?'

-Developers

Cooperation and Coordination with Other Software Teams

-May be partially outsourced thus requiring cooperation

-May require liaising with venders

-Other teams may have developed similar software for the client and can offer tremendous help

•Definitively requires coordinating conflicting schedules (Students)

Interfaces with other Systems

Interfaces with other Systems

-Interface, link to, import, include other packages containing libraries of perhaps classes / packages to assist in development

-May need to cooperate with inputs coming from other systems

-And outputs requiring special formats that serve as inputs to other systems...

Need to Continue Project despite Team Changes

-Team members leave, are hired, fired, take unexpected vacations, transferred within the company, and more.

-You can count on disruption and changes!

Need to continue Software Maintenance for an Extended Period

-Whether external customers or in-house customers, follow-on maintenance is typical and for many years!!-Highly desirable from management/enterprise perspective•SQA must address development, operations, and maintenance!

Quality has 4 dimensions:

1.Specification quality

2.Design quality

3.Development (software construction) quality

4.Conformance quality

Specification Quality:

Starting point in the journey of providing a product/service

Requirements should be well defined and comprehensive

Includes the following

-Collect requirements

-Classify them: functional, non-functional - usability, safety, reliability, security etc.

-Check them against organizational standards

-Evaluate each category of requirements for comprehensiveness

-Identify missing requirements

6 aspects of specifications:

-Functionality: specify what functions are to be achieved by product/service

-Capacity: specify the load that it can withstand

-Intended Use: determine the needs that it satisfies

-Reliability: how long will it be useful before maintenance is needed

-Safety: specify the threshold levels to ensure safety

-Security: specify threats it needs to handle

Development Quality:

•Software testing can be carried out without destroying a product (material)

•It's a time consuming process, may take more time to test than to develop software

•Exhaustive (100%) testing is not practical in software development

•SQA:-Creating test plans

-Follow coding guidelines

-Follow defect prevention guidelines

-Develop process routines for security, fault tolerance etc.

Conformance Quality:

Deals with how well an organization ensures that quality was built into the product/service

•How do we determine how well an organization conducts the activities to ensure that quality is built into a product/service?

-Evaluate the efficacy of QA activities using a set of quality metrics

•Metrics may include:

-Defect Removal Efficiency:

»Blackbox Testing

»Whitebox Testing: Branch and Statement coverage

-Product Quality

.-Compare QA activities and corresponding metrics to industry benchmarks

Tools to Ensure Quality

Quality in Specification

Quality in Design

Quality in Development

Quality in Conformance

Expand on Quality in Specification

-Process documentation:

•Adopt a methodology, develop and finalize requirements

-Standards and guidelines, formats and templates:

•Agree on minimum set of requirements

-Checklists: ensure comprehensiveness

•E.g. expert reviews, peer reviews, and brainstorming sessions

Expand on Quality in Design

-Process documentation:

•Details the methodology, finalize conceptual design

-Standards and guidelines, formats and templates:

•Evaluate architecture: pros and cons,

•Look at alternatives

-Checklists:

•Ensure design is performed comprehensively and correctly

•E.g. expert reviews, peer reviews, managerial review, and brainstorming session

Expand on Quality in Development

-Use coding guidelines, change and configuration management procedures

-Testing and walkthroughs, Peer Reviews

•Unit, integration, systems testing etc.

Expand on Quality in Conformance

-Ensure correct application of quality assurance activities, processes etc.

-Audits, measurements and metrics for quality assurance activities

-Measure quality using code coverage and partitioning the input space

Chapter 3;

Software Requirements Problem

•Poor requirements accounted for 41-56% of errors discovered, and 5 of the top 8 reasons for project failure (The CHAOS Report, 1995)

•IBM and Bell Labs studies show that 80% of all product defects are inserted at the requirements definition stage(Hooks and Farry, 2001)

•Requirements errors consume from 28% to more than 40% of a typical project's budget(Hooks and Farry, 2001)

•122% average schedule overrun, 45% of delivered functions never used(Standish Group Report, 1995)

Software Quality Factors

•There is a need for comprehensive Software Quality Requirements

•We will classify requirements according to the Software Quality Factors in the following categories:

-Operation, Revision, and Transition

•Requirement Documentation (Specification) is one of the most important elements for achieving software quality

•Let us consider, what constitutes a good software requirements document.

•Some SQA Models suggest 11-15 categorized factors; some fewer, some more.

Product Operation Factors

•How well it runs & ease of use

•Correctness, reliability, efficiency, integrity, and usability

How well does it run and ease of use.

Product Operation Factors (Correctness)

-Specifying accuracies for correct outputs(less than 1% errors)

-Specifying the completeness/timelines of the outputs

Product Operation Factors (Reliability)

-Reliability deals with failure to provide service

-A heart monitoring system must have a failure rate of...

Product Operating Factors (Efficiency)

-deal with the hardware resources needed to perform the functions of the software.

(Processing power)

Product Operating Factors (Integrity)

-Deal with system security, prevent unauthorized access

Product Operation Factors (Usability)

Deals with scope of staff resources need to train new employees and how to operate the system.

Product Transition Factors

•How well it can be moved to different platforms and interface with other systems

•Portability, Reusability, Interoperability

Lecture 4

Need for Comprehensive Software Quality Requirements

•Need for improving poor requirements (reqs) documents is widespread

•Frequently reqs. lack quality factors such as: usability, reusability, maintainability, ...

•Software industry groups have a long list of related attributes called, quality factors.

-Referred to as non-functional requirements

•Emphasis varies from project to project

-Scalability, maintainability, reliability...

McCall has 11 factors. They are grouped into 3 categories:

-Product Operation Factors

-Product Revision Factors

-Product Transition Factors

Product Revision Factors

-Can I fix it easily, retest, version it, and deploy it easily?

-Maintainability

-Flexibility

-Testability

Maintainability Requirements

(Product Revision Factors)

-The degree of effort needed to identify reasons for software failure, correct failures and verify success of corrections.

-Deals with Modular structure of software.

*Example spec: size of module <= 30 statements

Cohesion vs Coupling

Cohesion: While designing you should strive for high cohesion i.e. a cohesive component/ module focus on a single task with little interaction with other modules of system.

Coupling: While designing you should strive for low coupling i.e. Dependency between modules should be less.

Flexibility Requirements

(Product Revision Factors)

-Deals with resources to change (adopt) software to different types of customers.

Testability Requirements

(Product Revision Factors)

-Deals with the efficiency in evaluating the behavior and operations of software.

--Ease of Testing, Traceability, Automated Diagnosis.

Product Transition Factors

-Portability

-Reusability

-Interoperability

-Can I move the app to different hardware?

-Does it interface easily with different hardware / software systems

Portability Requirements

(Product Transition Factors)

-Determine if the software can be ported to different environments

Reusability Requirements

(Product Transition Factors)

-Are we able to reuse parts of the SW for new applications?

-Example: Generalized functions that live across diff. apps

-Is the Structure Modular?

Interoperability Requirements:

(Product Transition Factors)

-Does the application need to interface with other existing systems?

-Be aware of input from one system to another.

Verifiability Requirements

-Addresses design and programming features that allow for efficient verification of design and programming;

-Apply to modularity, simplicity...

(Evans and Marciniak)

Expandability Requirements

-Refers to scalability and extensibility to provide more usability.

(Evans and Marciniak)

Safety Requirements

(Deutsch and Willis)

-Address conditions that could bring the equipment of application down.

-Setting alarms or sounding warnings. (conveyor belts)

Manageability Requirements

(Deutsch and Willis)

-Refer to tools primarily administrative to control versions, configurations and change management.

-Need tools to manage versions, that vary from customer to customer.

Survivability Requirements

(Deutsch and Willis)

-Refer to MTBF or continuity of service, as well as MTTR (mean time to recover)

-Similar to Reliability in McCall's model.

Both models add ______

Verifiability

-Addresses design and programming.

-Programming conventions/ standards..

Safety

Important as computers control more and more of what we do especially in both hardware & in software

Lecture 5

Pre-Project Components involves commitments have been adequately defined by:

-Considering the resources required

-Schedule

-Budget

Pre-Project components involves correctly defining the:

-Development plans

-Quality plans

What is the objective of pre-project components?

Improve the preparatory steps prior to starting work.

Contract Review

-Clarification of customer's requirements

-Review project schedule

-Evaluation of development risks

Types of reviews include:

-Defect inspection and removal (product)

-Progress reviews (product and process)

-Quality reviews (product and standards)

--Requirements evaluation

Development of quality plans

•Schedules

•Risk evaluation

•Software reuse plans

•Required man power and hardware resources

The following SQA components must be planned prior to the project's initiation:

-Reviews

-Expert Opinions

-Software Testing

-Software Maintenance

-Assurance of Quality

Formal Design Reviews

-List of corrections

-Requires approval from senior management to advance to next development stage.

Peer Reviews

Involves inspection or walkthrough,

-Peers exchange roles and provide feedback.

Expert Opinions

-Hire consultants

--Typical in small companies/organizations

Software Testing

-Plan, Design and create a variety of automated test cases.

Software Maintenance include

•Corrective maintenance: user support services and code correction

•Adaptive maintenance: change software to accommodate( new circumstance, hardware changes)

•Functionality improvement maintenance: improvement related to functionality of the existing software

Assurance of quality

•Deals with sub-contractors (out-sourcing)

•COTS or services used to develop different aspect of software

•Defined in contract, to enforce effective controls over external participants

What is the main goal of the SQA infrastructure?

To eliminate or reduce the rate of errors.

Procedures and work instructions includes definitions for ___

the performance of various development activities

NOT FINISHSED;