Quality Assurance Plan Change

1
Quality Assurance Plan Change Configuration
ManagementMotorola Technology Center Italy
Turin - 7/8 June, 2001
2
Quality Assurance Elements
3
Outline QA Elements

• Quality Assurance
• Process
• Preview
• Quality Gate
• Post-Mortems
• Quality Goals Metrics
• Configuration Change Management

4
Quality Assurance
It has been proved that is much more expensive to
find and repair problems after deployment. For
this reason its important to continuously assess
the quality of a system with respect to its
functionality, reliability, application
performance, and system performance.
5
Verify System Quality (1)

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

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

7
Process Roles

• Development process roles are
• Provide guidance as to the order of a teams
  activity
• Specify which artefacts should be developed and
  when they should be developed.
• Direct the tasks of individual developers and
  the team as a whole
• Offer criteria for monitoring and measuring the
  projects products and activities

8
Process - Examples
?
9
Process Basic Elements
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

11
Quality Gates

• A check to determine whether or not an activitys
  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

12
Q_Gates (2)

• 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

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

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
• ...

15

• Change Configuration Management

16
Configuration ChangeManagement

• GOAL to track and maintain the integrity of
  project assets as they evolve in the presence of
  changes.

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

18
Configuration Management (1)

• 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

19
Configuration Management (2) Example
20
Configuration Management (3) - Links
21
Change Management (1)

• 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.

22
Change Management (2)- basic process -
23
Change Management (3)
24
Change Management (4)- Basic elements

• 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

25
Change Management (5)- Steps

• 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.

26
Reference

• 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