Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "Quality Assurance at CMM Level 2 Copyright, 2000 © Jerzy R. Nawrocki Requirements."— Presentation transcript:

1 Quality Assurance at CMM Level 2 Copyright, 2000 © Jerzy R. Nawrocki Jerzy.Nawrocki@put.poznan.pl www.cs.put.poznan.pl/jnawrocki/mse/require/ Requirements Engineering Lecture 11 Requirements Engineering Lecture 11

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

3 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

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

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

6 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

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

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

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

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

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

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

13 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!

14 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)

15 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)

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

17 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)

18 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)

19 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. 

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

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

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

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

24 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!

25 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

26 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

27 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).

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

29 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

30 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 1.04 - 21.04 Between 23.05 and 15.06

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

32 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, 1994. 

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

34 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?


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

Similar presentations


Ads by Google