1 / 26

Quality Assurance Plan: Change & Configuration Management

Learn about the key elements of quality assurance, including process, quality gate, post-mortems, and configuration & change management.

teems
Télécharger la présentation

Quality Assurance Plan: Change & Configuration Management

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Quality Assurance Elements Quality Assurance

  3. Outline – QA Elements • Quality Assurance • Process • Preview • Quality Gate • Post-Mortems • Quality Goals & Metrics • Configuration & Change Management Quality Assurance

  4. Quality Assurance 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

  5. Verify System Quality (1) The prime benefit: the assurance that the officially established process is actually being implemented. 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 Quality Assurance

  7. Process Roles Development process roles are: • Provide guidance as to the order of a team’s 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 project’s products and activities Quality Assurance

  8. Requirements Gathering Requirements Gathering Requirements Gathering Requirements Gathering Core Design Function Design Function Design Development Development Development Requirements Analysis Core Code Function Code Function Code Test Test Test Core Test Function Test Function Test Deliver Deliver Deliver Process - Examples ? Quality Assurance

  9. Q_Gate Project Activity Post Mortem Preview & Plan Process – Basic Elements 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 Quality Assurance

  11. Quality Gates • 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 Assurance

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

  15. Change & Configuration Management Quality Assurance

  16. Configuration & ChangeManagement GOAL: to track and maintain the integrity of project assets as they evolve in the presence of changes. 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 Quality Assurance

  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 Quality Assurance

  19. OBJECT 1: REGNET REPOSITORY • 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 Configuration Management (2) – Example Quality Assurance

  20. D.1 D.8 D.2 LINKS D.7 D.3 D.6 D.4 D.5 Configuration Management (3) - Links Quality Assurance

  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 leastonce an artifact has been released. Prior to this changes may be made without resorting to a formal change processing. Quality Assurance

  22. Analysis: accepted? Request for Modification No C.R. rejected C.R. opened Yes WARNING: ALL THOSE WHOSE WORK IS AFFECTED MUST BE AWARE OF THE CHANGES Deployment C.R. closed Verification ok? Validation and New Release Yes No C.R. integrated C.R. verified Change Management (2)- basic process - Quality Assurance

  23. Analysis1: accepted? Request for Modification No C.R. rejected C.R. opened No Yes Affects other WA? Analysis2: accepted? Yes Validation and New Release Yes No New Request for Modification C.R. integrated Yes New C.R.(s) opened Verification: ok? Deployment C.R. verified C.R. closed No Change Management (3) Quality Assurance

  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 Quality Assurance

  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. Quality Assurance

  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 Quality Assurance

More Related