1. Quality Assurance Plan Change & Configuration Management Motorola Technology Center Italy Turin - 7/8 June, 2001

2. Quality Assurance2 Quality Assurance Elements

3. Turin - 7/8 June, 2001Quality Assurance3 Outline – QA Elements Quality Assurance Process Preview Quality Gate Post-Mortems Quality Goals & Metrics Configuration & Change Management

4. Turin - 7/8 June, 2001Quality Assurance4 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. Quality Assurance

5. Turin - 7/8 June, 2001Quality Assurance5 Verify System Quality (1) The prime benefit: the assurance that the officially established process is actually being implemented.

6. Turin - 7/8 June, 2001Quality Assurance6 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. Turin - 7/8 June, 2001Quality Assurance7 Development process roles are: 1. Provide guidance as to the order of a teams 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 projects products and activities Process Roles

8. Turin - 7/8 June, 2001Quality Assurance8 Function Design Function Code Function Test Requirements Gathering Requirements Analysis Core Design Core Code Core Test Function Design Function Code Function Test Requirements Gathering Development Test Deliver Requirements Gathering Development Test Deliver Requirements Gathering Development Test Deliver Process - Examples

9. Turin - 7/8 June, 2001Quality Assurance9 Project Activity Q_Gate Preview & Plan Post Mortem Process – Basic Elements

10. Turin - 7/8 June, 2001Quality Assurance10 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. Turin - 7/8 June, 2001Quality Assurance11 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 Quality Gates

12. Turin - 7/8 June, 2001Quality Assurance12 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)

13. Turin - 7/8 June, 2001Quality Assurance13 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. Turin - 7/8 June, 2001Quality Assurance14 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. Turin - 7/8 June, 2001Quality Assurance15 Change & Configuration Management

16. Turin - 7/8 June, 2001Quality Assurance16 Configuration & Change Management GOAL: to track and maintain the integrity of project assets as they evolve in the presence of changes.

17. Turin - 7/8 June, 2001Quality Assurance17 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. Turin - 7/8 June, 2001Quality Assurance18 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)

19. Turin - 7/8 June, 2001Quality Assurance19 OBJECT 1: PARTITION 1: WA.A Responsible A Objects: -D.1: Owner a1 -D.4: Owner a2 PARTITION 2: WA.B Responsible B Objects: -D.2: Owner b1 -D.5: Owner b2 -D.8: Owner b3 PARTITION 3 : WA.C Responsible C Objects: -D.3: Owner c1 -D.6: Owner c2 REGNET REPOSITORY Configuration Management (2) – Example

20. Turin - 7/8 June, 2001Quality Assurance20 D.8 D.6 D.7D.3 D.4 D.5 D.1 D.2 LINKS Configuration Management (3) - Links

21. Turin - 7/8 June, 2001Quality Assurance21 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)

22. Turin - 7/8 June, 2001Quality Assurance22 C.R. integrated C.R. verified C.R. opened C.R. closed C.R. rejected Analysis: accepted? Deployment Validation and New Release Verification ok? Request for Modification No Yes No Change Management (2) - basic process -

23. Turin - 7/8 June, 2001Quality Assurance23 New C.R.(s) opened C.R. integrated C.R. verified C.R. opened C.R. closed C.R. rejected Analysis1: accepted? Deployment Validation and New Release Verification: ok? Request for Modification Affects other WA? New Request for Modification No Yes No Yes Analysis2: accepted? Yes No Change Management (3)

24. Turin - 7/8 June, 2001Quality Assurance24 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 (CCB WAx ) for each Work Area Identify a Cross Area CCB (CCB ALL ) to verify the impact of external modification Change Management (4) - Basic elements

25. Turin - 7/8 June, 2001Quality Assurance25 CCB WAx verify the CR, approve it and categorize it internal/external For the external CR: the CCB ALL approve it, and investigate on the impact on affected artefacts of the other WA the CCB ALL generate the new CRs needed. Every CCB WAx verify the deployment of its WA. Change Management (5) - Steps

26. Turin - 7/8 June, 2001Quality Assurance26 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