Principles of project management and staff recruitment

Содержание

Слайд 2

Outline Software Quality Assurance Plan Definition of quality for software products

Outline

Software Quality Assurance Plan
Definition of quality for software products
Software Metrics
Software Testing,

types of testing
Слайд 3

Outcomes Understand the key parts of the Software Testing process Know

Outcomes

Understand the key parts of the Software Testing process
Know how to

identify the metrics of software
Be able to write a SQAP
Have a clear understanding of what is Quality in software products
Слайд 4

Software Quality Assurance Plan The purpose of the Software Quality Assurance

Software Quality Assurance Plan

The purpose of the Software Quality Assurance Plan

(SQAP) is to define the techniques, procedures, and methodologies that will be used at project to assure timely delivery of the software that meets specified requirements within project resources.
Слайд 5

Software Quality Assurance Plan Set common templates (standards) Define the sequence

Software Quality Assurance Plan

Set common templates (standards)
Define the sequence of actions
Ensure

that standards and processes are used
Conduct an analysis of completed projects
Analyze and learn, using the defect data
Use what you have learned
Слайд 6

What is Quality? How do you understand the term Quality of

What is Quality?

How do you understand the term Quality of software

product?
Is it rather about conformance to requirements?
Is it rather about fitness of use?
Слайд 7

What is Quality? Verification – The evaluation of whether or not

What is Quality?

Verification – The evaluation of whether or not a

product, service, or system complies with a regulation, requirement, specification, or imposed condition. It is often an internal process. Contrast with validation.
Validation -The assurance that a product, service, or system meets the needs of the customer and other identified stakeholders. It often involves acceptance and suitability with external customers. Contrast with verification.
Слайд 8

Fault, failure and error Fault/defect – a condition that may cause

Fault, failure and error

Fault/defect – a condition that may cause a

failure in a system, also called a bug.
Failure/problem – the inability of a system to perform a function according to its specification, result of a defect.
Error – a mistake made by software engineer or programmer
Слайд 9

Cost of Quality (CoQ)

Cost of Quality (CoQ)

Слайд 10

Software Project Metrics Tools for anyone involved in software engineering to

Software Project Metrics

Tools for anyone involved in software engineering to understand

varying aspects of the code base, and the project progress.
They are different from just testing for errors because they can provide a wider variety of information about the following aspects of software systems:
Quality of the software, different metrics look at different aspects of quality
Schedule of the software project on the whole, some metrics look at functionality and some look at documents produced.
Cost of the software project. Includes maintenance, research and typical costs associated with a project.
Size/Complexity of the software system. This can be either based on the code or at the macro-level of the project and it’s dependency on other projects.
Слайд 11

Seven basic Quality tools

Seven basic Quality tools

Слайд 12

Software Metrics: effects of proper usage Reduce cost by 15% -

Software Metrics: effects of proper usage

Reduce cost by 15% - 20%

by just measuring
Create baseline of quality and productivity and compare against industry averages.
Pinpoint opportunities for improvement.
Ability to measure initiatives and measure ROI (return of investments).
Слайд 13

Software Project Metrics: types Life Cycle Step metrics Costs and budget

Software Project Metrics: types

Life Cycle Step metrics
Costs and budget metrics
Requirements’ change

metrics
Development process metrics
Testing metrics
Defect metrics
Efficiency metrics
Слайд 14

Software Project Metrics in Agile An agile version of the Goal

Software Project Metrics in Agile

An agile version of the Goal Question Metric

(GQM) strategy.
The fundamental idea behind GQM is that you first identify:
a goal that you would like to achieve,
a set of questions whose answers are pertinent to determining how well you’re achieving that goal,
and then the metric(s) that could help you to answer each question
Слайд 15

Software Project Metrics General Project Metrics: Completed activities budget (percentage of

Software Project Metrics

General Project Metrics:
Completed activities budget (percentage of completed tasks)
Actual

budget ratio of the planned budget ( Budget(actual) / Budget(planned) )
Dispersion (var) of costs (Budget(actual) - Budget(planned) )
Schedule execution ( Effort (actual) / Effort (planned) )
Dispersion (var) of schedule ( Effort (actual) - Effort (planned) )
Schedule delays ( ∑ delay time )
Coefficient of closed tasks ( closed tasks / planned tasks)
Productivity
Слайд 16

Software Metrics Requirements Metrics: Frequency of change in the total requirements

Software Metrics

Requirements Metrics:
Frequency of change in the total requirements set
Rate of

introduction of new requirements
Traceability
Volatility of requirements
Percentage of defects as requirement as a root cause
Number of requirement-related change requests
Requirement Stability Index : 1- ((No of changed + No of deleted + No of added) / Total no of Initial requirements) x100
Слайд 17

Software Metrics Process Metrics:

Software Metrics

Process Metrics:

Слайд 18

Software Metrics Product Metrics: Testing General Testing time Test cases metrics

Software Metrics

Product Metrics:
Testing
General
Testing time
Test cases metrics
Passed/Failed Test Cases
Not Run Test

Cases
Bugs
Open/Closed Bugs
Reopened/Closed Bugs
Rejected/Opened Bugs
Bugs by Severity
Bugs by Priority
Слайд 19

What is Testing of SW? Maintaining a set of techniques for

What is Testing of SW?

Maintaining a set of techniques for detecting

and correcting errors in a software products
(testing process can be automated)

Testing should be applied to all artifacts of software projects development.

Слайд 20

Testing Test Plan - a document describing the scope, approach, resources

Testing

Test Plan - a document describing the scope, approach, resources and

schedule of intended test activities. It identifies amongst others test items, the features to be tested, the testing tasks, who will do each task, degree of tester independence, the test environment, the test design techniques and entry and exit criteria to be used, and the rationale for their choice, and any risks requiring contingency planning. It is a record of the test planning process.
Слайд 21

Testing Master Test Plan: A single high-level test plan for a

Testing

Master Test Plan: A single high-level test plan for a project/product that

unifies all other test plans.
Testing Level Specific Test Plans: Plans for each level of testing.
Unit Test Plan
Integration Test Plan
System Test Plan
Acceptance Test Plan
Testing Type Specific Test Plans: Plans for major types of testing like Performance Test Plan and Security Test Plan.
Слайд 22

Testing of SW? Who does the testing Programmers (developers) Testers Users

Testing of SW?

Who does the testing
Programmers (developers)
Testers
Users (Alpha testing & Beta

testing)
Testing levels:
Unit testing;
Functional testing;
Integration and system testing (regression test, smoke test);
Слайд 23

Слайд 24

Testing of SW? Testing purposes: Acceptance testing Conformance testing Configuration testing;

Testing of SW?

Testing purposes:
Acceptance testing
Conformance testing
Configuration testing;
Performance testing;
Stress testing;
User interface testing
Test

cases based on:
Intuition
Specification (known as black-box testing)
Code (white-box testing)
Existing test cases
Faults
Слайд 25

Requirements Traceability Matrix Requirement Traceability Matrix – Parameters include Requirement ID

Requirements Traceability Matrix

Requirement Traceability Matrix – Parameters include
Requirement ID
Risks
Requirement Type and

Description
Trace to design specification
Unit test cases
Integration test cases
System test cases
User acceptance test cases
Trace to test script
Слайд 26

Requirements Traceability Matrix

Requirements Traceability Matrix

Слайд 27

Requirements Traceability Matrix

Requirements Traceability Matrix

Слайд 28

Requirements Traceability Matrix

Requirements Traceability Matrix

Слайд 29

Requirements Traceability Matrix

Requirements Traceability Matrix

Слайд 30

Requirements Traceability Matrix

Requirements Traceability Matrix

Слайд 31

Requirements Traceability Matrix

Requirements Traceability Matrix

Слайд 32

Requirements Traceability Matrix

Requirements Traceability Matrix

Слайд 33

Product Complexity Metrics Source lines of code. Cyclomatic complexity, is used

Product Complexity Metrics

Source lines of code.
Cyclomatic complexity, is used to measure

code complexity.
Function point analysis (FPA), is used to measure the size (functions) of software.
Bugs per lines of code.
Bang Metric