Quality Assurance at CMM Level 2 Copyright, 2000 © Jerzy R. Nawrocki Requirements.

Slides:



Advertisements
Similar presentations
Configuration Management
Advertisements

Formal Process of QA and quality related certifications Formal Process of QA and quality related certifications MIM 3 rd year – Sem V Abhishek Mishra –
Planning at CMM level 2 Copyright, 2000 © Jerzy R. Nawrocki Requirements Engineering.
Software Quality Assurance Plan
Chapter 7: Key Process Areas for Level 2: Repeatable - Arvind Kabir Yateesh.
More CMM Part Two : Details.
How ISO9001 Compares with CMM Mark C. Paulk JAN,1995 CMM version 1.1 ISO9001 July 1994 presented by Zhilan Zhou.
Procedures for CMM Level 2 Copyright, 2000 © Jerzy R. Nawrocki Quality Management.
Formal Technical Reviews
Quality Assurance Copyright, 2002 © Jerzy R. Nawrocki Quality Management Auxiliary.
Overview Lesson 10,11 - Software Quality Assurance
University of Sunderland CIFM03Lecture 1 1 Quality Management of IT CIFM03 Introduction.
Chapter 3 The Structure of the CMM
Software Configuration Management
Configuration Management Avoiding Costly Confusion mostly stolen from Chapter 27 of Pressman.
Chapter 16 Software Quality Assurance
Project Planning Copyright, 2002 © Jerzy R. Nawrocki Quality Management Auxilliary.
The Key Process Areas for Level 2: Repeatable Ralph Covington David Wang.
Introduction to Software Quality Assurance (SQA)
Rational Suite and CMM Level 2 Copyright, 2000 © Jerzy R. Nawrocki Requirements.
N By: Md Rezaul Huda Reza n
Configuration Management Copyright, 2002 © Jerzy R. Nawrocki Quality Management.
Software Quality Assurance Activities
Unit 8 Syllabus Quality Management : Quality concepts, Software quality assurance, Software Reviews, Formal technical reviews, Statistical Software quality.
Michael Dermody September 2010  Capability Maturity Model Integration ◦ Is a Trademark owned by the Software Engineering Institute (SEI) of Carnegie.
CMM Level 2 KPA’s CS 4320 Fall Requirements Management 1 Goals: – System requirements allocated to software are controlled using a baseline for.
Soft Tech Development Inc. 1 Software Project Tracking A CMM Level 2 Key Process Area Soft Tech Development Inc.
Software Quality Assurance Lecture #2 By: Faraz Ahmed.
S Q A.
Standard SRS Copyright, 2001 © Jerzy R. Nawrocki Requirements Engineering Lecture.
Requirements Verification & Validation Requirements Engineering & Project Management.
Copyright, 2006 © L. Ouyang Introduction to PSP Liubo Ouyang Personal Software Process Lecture 1.
1.  Describe an overall framework for project integration management ◦ RelatIion to the other project management knowledge areas and the project life.
PRINCE 2 for Managers Copyright, 2003 © Jerzy R. Nawrocki
Project Planning Copyright, 2002 © Jerzy R. Nawrocki Requirements Engineering.
CMM Level 2: Repeatable Copyright, 2000 © Jerzy R. Nawrocki Quality Management.
Q & QA1 Quality & Quality Assurance Advanced Software Engineering COM360 University Of Sunderland © 1999.
Georgia Institute of Technology CS 4320 Fall 2003.
Software Process Improvement: SEI Capability Maturity Model
Quality of Usage Scenarios Copyright, 2000 © Jerzy R. Nawrocki Quality Management.
© Mahindra Satyam 2009 Configuration Management QMS Training.
Implementing XP at PUT Copyright, 2000 © Jerzy R. Nawrocki Quality Management.
Introduction to SoDA Copyright, 2001 © Jerzy R. Nawrocki Requirements Engineering.
Introduction to Requirements Engineering Copyright, 2000 © Jerzy R. Nawrocki Requirements.
ReviewsReviews Copyright, 2002 © Jerzy R. Nawrocki Quality Management Auxiliary.
Ch-1 Introduction The processes used for executing a software project have major effect on quality of s/w produced and productivity achieved in project…
Configuration Management at CMM Level 2 Copyright, 2000 © Jerzy R. Nawrocki Requirements.
Purpose: The purpose of CMM Integration is to provide guidance for improving your organization’s processes and your ability to manage the development,
Change Management Requirements Engineering & Project Management Lecture 10.
Configuration Management (II) Copyright, 2000 © Jerzy R. Nawrocki Requirements.
1 Lecture 12: Chapter 16 Software Quality Assurance Slide Set to accompany Software Engineering: A Practitioner’s Approach, 7/e by Roger S. Pressman Slides.
Pittsburgh, PA CMMI Acquisition Module - Page M5-1 CMMI ® Sponsored by the U.S. Department of Defense © 2005 by Carnegie Mellon University This.
Introduction to SoDA Copyright, 2001 © Jerzy R. Nawrocki Quality Management Lecture.
Pertemuan 14 Matakuliah: A0214/Audit Sistem Informasi Tahun: 2007.
Requirements Management and Changes Copyright, 2003 © Jerzy R. Nawrocki Requirements.
Capability Maturity Model. CS460 - Senior Design Project I (AY2004)2 Immature Organisations Software processes are often rigorously followed. Organisation.
Software Project Management Lecture # 12. Outline Quality Management ( chapter 26 - Pressman )  SQA  Who does it?  SQA Activities  Software reviews.
Requirements Engineering Lecture 7
Introduction for the Implementation of Software Configuration Management I thought I knew it all !
Software Project Configuration Management
Software Quality Control and Quality Assurance: Introduction
Requirements Engineering Lecture 4
Requirements Engineering Lecture 2
Software Configuration Management
H. Overview of Capability Maturity Model (CMM)
CMMI – Staged Representation
QA Reviews Lecture # 6.
Software Reviews.
3. Software Quality Management
Presentation transcript:

Quality Assurance at CMM Level 2 Copyright, 2000 © Jerzy R. Nawrocki Requirements Engineering Lecture 11 Requirements Engineering Lecture 11

J. Nawrocki, Requirements Eng., Lecture 11 Plan of the lecture Introduction Abilities Activities

J. Nawrocki, Requirements Eng., Lecture 11 IntroductionIntroduction CMM Requirements management Software project planning Software project tracking and oversight Software subcontract management Software quality assurance Software configuration management CMM Level 2 - Repeatable

J. Nawrocki, Requirements Eng., Lecture 11 IntroductionIntroduction Generic FTR procedure Producer informs that the product is ready and sends a copy of it. The review leader contacts the participants of the meeting to establish the date. The review leader establishes the meeting agenda. The meeting takes place The recorder prepares a report.

J. Nawrocki, Requirements Eng., Lecture 11 IntroductionIntroduction FTR meeting (I) Review leader: Introduction of the agenda. Recorder: Collection of the preparation forms (copies) Producer: Presentation of the material. The producer “walks through” the material. The reviewers raise issues. The recorder takes notes.

J. Nawrocki, Requirements Eng., Lecture 11 IntroductionIntroduction FTR meeting (II) Recorder: Summary of defects and problems. All attendees except producer: Early decision. Recorder: Collecting of early decisions and their presentation. Producer: “Last word” All attendees except producer: Making final decision

J. Nawrocki, Requirements Eng., Lecture 11 IntroductionIntroduction The decision Accept. Accept provisionally. Minor defects. No additional review is required. Reject. Severe defects. Another review is necessary.

J. Nawrocki, Requirements Eng., Lecture 11 Plan of the lecture Introduction Abilities Activities

J. Nawrocki, Requirements Eng., Lecture 11 AbilitiesAbilities Ab1. A group that is responsible for co-ordinating and implementing SQA for the project (i.e. the SQA group) exists. SQA at PUT: Two 5-year students per project.

J. Nawrocki, Requirements Eng., Lecture 11 AbilitiesAbilities Ab2. Adequate resources and funding are provided. Is it enough?

J. Nawrocki, Requirements Eng., Lecture 11 AbilitiesAbilities Ab3. Members of the SQA group are trained to perform their SQA activities. Ab4. Members of the software project receive orientation on the role, responsibilities, authority, and value of the SQA group.

J. Nawrocki, Requirements Eng., Lecture 11 Plan of the lecture Introduction Abilities Activities

J. Nawrocki, Requirements Eng., Lecture 11 ActivitiesActivities Ac1. A SQA plan is prepared for each project according to a documented procedure. I’m afraid, I need a documented procedure!

J. Nawrocki, Requirements Eng., Lecture 11 ActivitiesActivities The SQA plan is developed not later than the first version of the SRS. The SQA plan is authored by the SQA group. The SQA plan can be baselined, i.e. it can be placed under SCM. The SQA plan is reviewed by all the team members including Project Managers (4th year), and Developers (3rd year). SQA Planning Procedure (I)

J. Nawrocki, Requirements Eng., Lecture 11 ActivitiesActivities The SQA plan is approved by the Project Area Manager (Bartek). The SQA plan is available through the project’s web page along with all the previous versions of it. That web page is referenced in the Initial Project Description (IPD). SQA Planning Procedure (II)

J. Nawrocki, Requirements Eng., Lecture 11 ActivitiesActivities Ac2. A documented and approved SQA plan is used as the basis for performing the SQA activities

J. Nawrocki, Requirements Eng., Lecture 11 ActivitiesActivities 1. Introduction 1.1 Purpose of the Document 1.2 Scope of the Plan 1.3 Definitions, Acronyms, and Abbreviations 1.4 References 2. Responsibilities and authority of the SQA group SQA Plan (I)

J. Nawrocki, Requirements Eng., Lecture 11 ActivitiesActivities 3. Resource requirements for the SQA group 4. The SQA group’s participation in planning 5. Evaluations, audits and reviews to be performed by the SQA group 6. Review and audit procedures 7. Documenting and tracking non-compliance issues 8. SQA documentation and reports 9. Schedule of the SQA activities SQA Plan (II)

J. Nawrocki, Requirements Eng., Lecture 11 ActivitiesActivities Ac3. The SQA group participates in the preparation and review of the project’s software development plan, standards, and procedures. 

J. Nawrocki, Requirements Eng., Lecture 11 ActivitiesActivities Ac4. The SQA group reviews the software engineering activities to verify compliance.

J. Nawrocki, Requirements Eng., Lecture 11 ActivitiesActivities Ac4. The SQA group reviews the software engineering activities to verify compliance. The activities are evaluated against the SDP, and the designated standards and procedures. Deviations are identified, documented and tracked to closure. Corrections are verified.

J. Nawrocki, Requirements Eng., Lecture 11 if (a < b) a+= b; ActivitiesActivities Ac5. The SQA group audits designated software work products to verify compliance.

J. Nawrocki, Requirements Eng., Lecture 11 ActivitiesActivities Ac5. The SQA group audits designated software work products to verify compliance. The products are evaluated against the chosen standards and contractual requirements. Deviations are identified, documented and tracked to closure. Corrections are verified. The deliverable products are evaluated before they are delivered to the customer.

J. Nawrocki, Requirements Eng., Lecture 11 ActivitiesActivities Ac6. The SQA group periodically reports the results of its activities to the software engineering group. It’s getting better!

J. Nawrocki, Requirements Eng., Lecture 11 ActivitiesActivities Ac6. The SQA group periodically reports the results of its activities to the software engineering group. By Easter: every 2 weeks By June 15: every 4 weeks Reports at PUT

J. Nawrocki, Requirements Eng., Lecture 11 ActivitiesActivities Ac7. Deviations identified in the activities and work products are documented and handled according to a documented procedure. Err

J. Nawrocki, Requirements Eng., Lecture 11 ActivitiesActivities Ac7. Deviations identified in the activities and work products are documented and handled according to a documented procedure. Deviations from the SDP, designated standards, and procedures are documented and resolved with the project managers or the project area manager (BW). Deviations not resolvable with the project area manager are presented to the SDS supervisor (JN).

J. Nawrocki, Requirements Eng., Lecture 11 ActivitiesActivities Ac7. Deviations identified in the activities and work products are documented and handled according to a documented procedure. Non-compliance items presented to the SDS supervisor are periodically reviewed (e.g. every 2 weeks) until they are resolved. The documentation of non-compliance items is managed and controlled.

J. Nawrocki, Requirements Eng., Lecture 11 From the previous lecture.. Change control at PUT Change request Err UserS.C. Manager Change request Developer Change report SCCB Deci- sion Change order P. Manager

J. Nawrocki, Requirements Eng., Lecture 11 ActivitiesActivities Ac8. The SQA group conducts periodic reviews of its activities and findings with the customer’s SQA personnel, as appropriate. Reviews at PUT Between Between and 15.06

J. Nawrocki, Requirements Eng., Lecture 11 SummarySummary SQA Planning procedure & Standard SQA plan struct. The SQA group reviews activities and audits work products. Deviations are handled at the lowest possible level of management.

J. Nawrocki, Requirements Eng., Lecture 11 Further readings [CMM] M.C. Paulk et. al.,The Capability Maturity Model: Guidelines for Improving the Software Process, Addison-Wesley, Reading, 

J. Nawrocki, Requirements Eng., Lecture 11 HomeworkHomework Write SQA plan for your project.

J. Nawrocki, Requirements Eng., Lecture 11 Quality assessment 1. What is your general impression? (1 - 6) 2. Was it too slow or too fast? 3. What important did you learn during the lecture? 4. What to improve and how?