Quality Assurance Plan Change & Configuration Management

Motorola Technology Center Italy

Turin - 7/8 June, 2001

Turin - 7/8 June, 2001 Quality Assurance 2

Quality Assurance Elements

Turin - 7/8 June, 2001 Quality Assurance 3

Outline – QA Elements

Quality Assurance Process

PreviewQuality GatePost-Mortems

Quality Goals & Metrics Configuration & Change Management

Turin - 7/8 June, 2001 Quality Assurance 4

It has been proved that is much more expensive to find and repair problems after deployment.

For this reason it’s important to continuously assess the quality of a system with respect to its functionality, reliability, application performance, and system performance.

Quality Assurance

Turin - 7/8 June, 2001 Quality Assurance 5

Verify System Quality (1)

The prime benefit: the assurance that the officially established process is actually being implemented.

Turin - 7/8 June, 2001 Quality Assurance 6

Verify System Quality (2)

More specifically: An appropriate development methodology is in

place Standards and procedures are used Documentation is produced (during and not after

development) Changes are controlled Testing and verification are focused on areas of

highest risk Defects are identified earlier

Turin - 7/8 June, 2001 Quality Assurance 7

Development process roles are:

1. Provide guidance as to the order of a team’s

activity

2. Specify which artefacts should be developed and

when they should be developed.

3. Direct the tasks of individual developers and the

team as a whole

4. Offer criteria for monitoring and measuring the

project’s products and activities

Process Roles

Turin - 7/8 June, 2001 Quality Assurance 8

FunctionDesign

FunctionCode

FunctionTest

RequirementsGathering

RequirementsAnalysis

CoreDesign

Core Code

Core Test

FunctionDesign

FunctionCode

FunctionTest

RequirementsGathering

Development

Test

Deliver

RequirementsGathering

Development

Test

Deliver

RequirementsGathering

Development

Test

Deliver

Process - Examples

Turin - 7/8 June, 2001 Quality Assurance 9

Project Activity

Q_Gate

Preview &Plan

Post Mortem

Process – Basic Elements

Turin - 7/8 June, 2001 Quality Assurance 10

Preview

Communication to all team members the

detailed plan of an activity

Produce a common understanding of the

purpose and expected outcome of an activity

Conducted for the benefit of the project team

Turin - 7/8 June, 2001 Quality Assurance 11

A check to determine whether or not an

activity’s output is fit for its intended purpose

The purpose of the output should be agreed

to at the activity preview

The common forms of quality gate are:

peer review (inspections)testing

Quality Gates

Turin - 7/8 June, 2001 Quality Assurance 12

At the beginning of the activity the following shall be

addressed: What submit to Q_G

Who conduct the Q_G

How it is conducted

When...(remind to leave time to rework faults)

Who is responsible

Reports and Documentation

Identification of specific Q_Gates for specific Deliverables

Q_Gates (2)

Turin - 7/8 June, 2001 Quality Assurance 13

Post Mortem

Mechanism for learning from the completed

activity

Generally held at the end of the activity before

the next activity starts

Discover strengths and weakness of the

process

Conducted for the benefit of the project team

and the organization

Turin - 7/8 June, 2001 Quality Assurance 14

Metrics & Q_Goals

PROCESS/PROJECT METRICS

Schedule Estim. Accuracy (or On-time Delivery or

Commitment Slippage)

Zero known defects

Q_Gate containment effectiveness

Cost of Poor Quality

Test Coverage/Functional Coverage

PRODUCT METRICS

...

Turin - 7/8 June, 2001 Quality Assurance 15

Change & Configuration Management

Turin - 7/8 June, 2001 Quality Assurance 16

Configuration & ChangeManagement

GOAL: to track and maintain the integrity of

project assets as they evolve in the

presence of changes.

Turin - 7/8 June, 2001 Quality Assurance 17

Configuration Management (CM) deals with: artifact identification

versions

dependencies between artifacts

Change Management deals with: capture and management of requested changes

analysis of potential impact and tracking of

changes

Turin - 7/8 June, 2001 Quality Assurance 18

Identify a common repository and appropriate

partitions

Define objects and partitions to be put in the

repository and related responsabilities (owners: is

responsible for the official “versions” of the object)

Define accesses

Identify links (internal and external)

Manage the history-versions of the objects

Configuration Management (1)

Turin - 7/8 June, 2001 Quality Assurance 19

OBJECT 1:

PARTITION 1:

WA.AResponsible

A

Objects:-D.1: Owner

a1-D.4: Owner

a2

PARTITION 2:

WA.BResponsible

B

Objects:-D.2: Owner

b1-D.5: Owner

b2 -D.8: Owner

b3

PARTITION 3:

WA.CResponsible

C

Objects:-D.3: Owner

c1-D.6: Owner

c2

REGNET REPOSITORY

Configuration Management (2) – Example

Turin - 7/8 June, 2001 Quality Assurance 20

D.8

D.6

D.7 D.3

D.4

D.5

D.1

D.2

LINKSLINKS

Configuration Management (3) - Links

Turin - 7/8 June, 2001 Quality Assurance 21

A process for changes deployment shall be defined to

assure that all affected parties are informed about

changes, agree to them, and consequently integrate

changes to their artifacts.

Change processing shall be used at least once an

artifact has been released. Prior to this changes may be

made without resorting to a formal change processing.

Change Management (1)

Turin - 7/8 June, 2001 Quality Assurance 22

C.R. integrated

C.R.verified

C.R.opened

C.R. closed

C.R.rejected

Analysis: accepted?

Deployment

Validation andNew Release

Verificationok?

Request forModification

No

Yes

Yes No

Change Management (2)- basic process -

Turin - 7/8 June, 2001 Quality Assurance 23

New C.R.(s)opened

C.R.integrated

C.R.verified

C.R.opened

C.R.closed

C.R.rejected

Analysis1: accepted?

Deployment

Validation andNew Release

Verification: ok?

Request forModification

Affects other WA?

New Request forModification

NoYes

Yes

No

No

Yes

Analysis2: accepted?

Yes

No

Change Management (3)

Turin - 7/8 June, 2001 Quality Assurance 24

Definition of a C.R. Form (changes, reason why,...)

Identification of criteria for addressing “internal” or “external” C.R.s (i.e. “internal”: no other WAs affected by the change; “external”: other WAs are affected by the change)

Identify at least one Change Control Board (CCBWAx) for each Work Area

Identify a Cross Area CCB (CCBALL) to verify the impact of “external” modification

Change Management (4)- Basic elements

Turin - 7/8 June, 2001 Quality Assurance 25

CCBWAx verify the CR, approve it and categorize it internal/external

For the “external” CR: the CCBALL approve it, and investigate on the impact on affected artefacts of the other WA

the CCBALL generate the new CRs needed.

Every CCBWAx verify the deployment of its WA.

Change Management (5)- Steps

Turin - 7/8 June, 2001 Quality Assurance 26

Watts S. Humphrey, “Managing the software Process”, CMU/SEI, 1989

M.C. Paulk, C.V.Weber, S.M.GarciaM.B.Chrissis, M.Bush, Key Practices of the Capability Maturity Model”, CMU/SEI, 1993

Mark C. Paulk “A comparison of ISO9001 and the Capability Maturity Model for Software” , CMU/SEI, 1994

Watts S. Humphrey, “A discipline for Software Engineering”, Addison-Wesley, 1995

Roger S. Pressman, “Software Engineering”, McGraw Hill, 1997

Philippe Kruchten, “The Rational Unified Process”, Addison-Wesley, 1998

Reference