SOFTWARE QUALITY ASSURANCE Maltepe University Faculty of Engineering SE 410.

Slides:



Advertisements
Similar presentations
By: MSMZ. Objective After completing this chapter, you will be able to: Explain 2 contract review stage List the objective of each stage of the contract.
Advertisements

Chapter 4 Quality Assurance in Context
Chapter 7: Key Process Areas for Level 2: Repeatable - Arvind Kabir Yateesh.
More CMM Part Two : Details.
Software Project Management Lecture # 11. Outline Quality Management ( chapter 26 - Pressman )  Software reviews  Formal Inspections & Technical Reviews.
PERTEMUAN - 2 SOFTWARE QUALITY. OBJECTIVES After completing this chapter, you will be able to: ■ Define software, software quality and software quality.
 Every stage from phase DESIGN in Software Development Process will have “design document” especially in analysis and design phases.  “Design document”
OHT 8.1 Galin, SQA from theory to implementation © Pearson Education Limited Review objectives Formal design reviews (FDRs) Participants Preparations.
OHT 8.1 Galin, SQA from theory to implementation © Pearson Education Limited 2004 Review objectives Formal design reviews (FDRs) Participants Preparations.
OHT 22.1 Galin, SQA from theory to implementation © Pearson Education Limited Objectives of cost of software quality metrics 2.The classic model.
Components of software quality assurance system overview
OHT 5.1 Galin, SQA from theory to implementation © Pearson Education Limited 2004 Contract review process and stages Contract review objectives Implementation.
Chapter 8 Assuring the quality of external participants’ contributions
AUDITS AND INSPECTIONS
SQA Architecture Software Quality.
Development and Quality Plans
SOFTWARE QUALITY ASSURANCE Maltepe University Faculty of Engineering SE 410.
OHT 8.1 Galin, SQA from theory to implementation © Pearson Education Limited 2004 Continuing… Peer reviews (Inspections and Walkthroughs) Participants.
Design Reviews Peer Reviews. Agenda Peer Reviews Participants of Peer Review Preparation for a Peer Review Session The Peer Review Session Post-peer Review.
OHT 4.1 Galin, SQA from theory to implementation © Pearson Education Limited 2004 Software Quality assurance (SQA) SWE 333 Dr Khalid Alnafjan
OHT 22.1 Galin, SQA from theory to implementation © Pearson Education Limited 2004 Software Quality assurance (SQA) SWE 333 Dr Khalid Alnafjan
Prof. Mohamed Batouche Costs of software quality Introduction  More and more, commercial companies or public organizations are requiring.
SE513 Software Quality Assurance Lecture04: Contract Review Galin, SQA from Theory to Education Limited 2004.
S/W Project Management
CHAPTER 5 Infrastructure Components PART I. 2 ESGD5125 SEM II 2009/2010 Dr. Samy Abu Naser 2 Learning Objectives: To discuss: The need for SQA procedures.
Software Quality assurance SQA – SWE 333
SQA Architecture Software Quality By: MSMZ.
Introduction to Software Quality Assurance (SQA)
Software Inspections and Walkthroughs By. Adnan khan.
Chapter 4 Components of the Software Quality Assurance System
Galin, SQA from theory to implementation © Pearson Education Limited 2004 Review objectives Formal design reviews (FDRs) Participants Preparations The.
S oftware Q uality A ssurance Part One Reviews and Inspections.
Software Quality Assurance Activities
Software Inspection A basic tool for defect removal A basic tool for defect removal Urgent need for QA and removal can be supported by inspection Urgent.
Chapter 5 Contract review Contract review process and stages
Quality Control Project Management Unit Credit Value : 4 Essential
S Q A.
CHAPTER 3 Pre-Project Components. 2 ESGD5125 SEM II 2009/2010 Dr. Samy Abu Naser Learning Objectives: To discuss: Contract Review Development and Quality.
Product Documentation Chapter 5. Required Medical Device Documentation  Business proposal  Product specification  Design specification  Software.
OHT 5.1 Galin, SQA from theory to implementation © Pearson Education Limited 2004 Contract review process and stages Contract review objectives Implementation.
SacProNet An Overview of Project Management Techniques.
Communications Skills (ELE 205)
Georgia Institute of Technology CS 4320 Fall 2003.
CHAPTER 9 INSPECTIONS AS AN UP-FRONT QUALITY TECHNIQUE
CHAPTER 4 Life-Cycle Components. 2 ESGD5125 SEM II 2009/2010 Dr. Samy Abu Naser 2 Learning Objectives: To discuss: Integrating quality activities in the.
Software Testing and Maintenance 1 Code Review  Introduction  How to Conduct Code Review  Practical Tips  Tool Support  Summary.
Pre-Project Components
OHT 7.1 Galin, SQA from theory to implementation © Pearson Education Limited 2004 Software development methodologies: - The software development life cycle.
Reviews and Inspections. Types of Evaluations Formal Design Reviews conducted by senior personnel or outside experts uncover potential problems Inspections.
Capturing the requirements  Requirement: a feature of the system or a description of something the system is capable of doing in order to fulfill the.
Communications Skills (ELE 205) Dr. Ahmad Dagamseh Dr. Ahmad Dagamseh.
OHT 12.1 Galin, SQA from theory to implementation © Pearson Education Limited 2004 Introduction Types of external participants Risks and benefits of introducing.
© Michael Crosby and Charles Sacker, 2001 Systematic Software Reviews Software reviews are a “quality improvement process for written material”.
Chapter 9* Managing Meetings. Chapter 10/Managing Meetings Hilgert & Leonard © Explain why meetings, committees, and being able to lead meetings.
SEN 460 Software Quality Assurance. Bahria University Karachi Campus Waseem Akhtar Mufti B.E(C.S.E) UIT, M.S(S.E) AAU Denmark Assistant Professor Department.
Multitude of source of errors - various style of source of errors will affect the SQA components * The environment in which software development & maintenance.
More SQA Reviews and Inspections. Types of Evaluations  Verification Unit Test, Integration Test, Usability Test, etc  Formal Reviews  aka "formal.
Pertemuan 14 Matakuliah: A0214/Audit Sistem Informasi Tahun: 2007.
P RE - PROJECT P RE - PROJECT SOFTWARE QUALITY COMPONENTS Dr. Ahmad F. Shubita.
Software Project Management Lecture # 12. Outline Quality Management ( chapter 26 - Pressman )  SQA  Who does it?  SQA Activities  Software reviews.
SQA COMPONENTS IN THE PROJECT LIFE CYCLE C HAPTER 8 Dr. Ahmad F. Shubita.
S TANDARDS, CERTIFICATION AND ASSESSMENT C HAPTER 23 Dr. Ahmad F. Shubita.
Software Quality Assurance
Software Quality Control and Quality Assurance: Introduction
Software Configuration Management (SCM)
Chapter # 8 Quality Management Standards
QA Reviews Lecture # 6.
Chapter # 3 The Components of SQA
Project Closure And Termination
Software Reviews.
Presentation transcript:

SOFTWARE QUALITY ASSURANCE Maltepe University Faculty of Engineering SE 410

CHAPTER 6 REVIEW PROCESS SE Software Quality Assurance

Review Intro  A common product of the software development process, especially in its analysis and design phases, is a design document in which the progress of the development work performed is recorded.  The system analyst or analysts who prepared the document will check it repeatedly, it is to be assumed, in order to detect any possible error that might have entered.

SE Software Quality Assurance Review Intro (…)  In addition, development team leaders are also expected to examine this document and its details so as to detect any remaining errors before granting their approval.  However, it is clear that because these professionals were involved in producing the document, they are unlikely to detect some of their own errors irrespective of the number of checks.

SE Software Quality Assurance Review Intro (…)  Therefore, only others – such as peers, superiors, experts, and customer’s representatives (those having different experiences and points of view, yet not directly involved in creating the document) – are capable of reviewing the product and detecting the errors unnoticed by the development team.

SE Software Quality Assurance Review Process – Definition  “A process or meeting during which a work product, or set of work products, is presented to project personnel, managers, users, customers, or other interested parties for comment or approval.” (IEEE)

SE Software Quality Assurance Review Process – Definition  As these documents are products of the project’s initial phases, reviews acquire special importance in the SQA process because they provide early detection and prevent the passing of design and analysis errors “downstream”, to stages where error detection and correction are much more intricate, cumbersome, and therefore costly.

SE Software Quality Assurance Review Methods  Several methodologies can be implemented when reviewing documents:  Formal Design Reviews  Peer Review (Inspections and Walkthtoughs)  Expert opinions

SE Software Quality Assurance Review Objectives  The review’s direct objectives deal with the current project, whereas its indirect objectives, more general in nature, deal with the contribution of the review proper to the promotion of team members’ professional knowledge and the improvement of the development methodologies applied by the organization.

SE Software Quality Assurance Review Objectives (…)  Direct Objectives  To detect analysis and design errors as well as subjects where corrections, changes and completions are required with respect to the original specifications and approved changes.  To identify new risks likely to affect completion of the project.  To approve the analysis or design product. Approval allows the team to continue to the next development phase.

SE Software Quality Assurance Review Objectives (…)  Indirect Objectives  To provide an informal meeting place for exchange of Professional knowledge about development methods, tools and techniques.  To record analysis and design errors that will serve as a basis for future corrective actions. The corrective actions are expected to improve development methods by increasing effectiveness and quality, among other product features.

SE Software Quality Assurance Formal Design Reviews  Formal design reviews, variously called “design reviews”, “DRs” and “formal technical reviews (FTR)”, differ from all other review instruments by being the only reviews that are necessary for approval of the design product.

SE Software Quality Assurance Formal Design Reviews (…)  Without this approval, the development team cannot continue to the next phase of the software development project.  Some common formal design reviews:  Development Plan Review  Software Requirement Specification Review  Detailed Design Review  Data Base Design Review  Test Plan Review

SE Software Quality Assurance Formal Design Reviews (…)  Without this approval, the development team cannot continue to the next phase of the software development project.  Some common formal design reviews:  Development Plan Review  Software Requirement Specification Review  Detailed Design Review  Data Base Design Review  Test Plan Review

SE Software Quality Assurance The participants in a DR  All DRs are conducted by a review leader and a review team.  The choice of appropriate participants is of special importance because of their power to approve or disapprove a design product.

SE Software Quality Assurance The participants in a DR (…)  The review leader  Because the appointment of an appropriate review leader is a major factor affecting the DR’s success, certain characteristics are to be looked for in a candidate for this position: Knowledge and experience in development of projects of the type reviewed. Seniority at a level similar to if not higher than that of the project leader. A good relationship with the project leader and his team.

SE Software Quality Assurance The participants in a DR (…)  The review leader  Small development departments and small software houses typically have substantial difficulties finding an appropriate candidate to lead the review team.  One possible solution to this predicament is the appointment of an external consultant to the position.

SE Software Quality Assurance The participants in a DR (…)  The review team  The entire review team should be selected from among the senior members of the project team together with appropriate senior professionals assigned to other projects and departments, customer–user representatives, and in some cases, software development consultants.  It is desirable for non-project staff to make up the majority of the review team.

SE Software Quality Assurance The participants in a DR (…)  The review team  A review team of three to five members is expected to be an efficient team, given the proper diversity of experience and approaches among the participants are assured.  An excessively large team tends to create coordination problems, waste review session time and decrease the level of preparation, based on a natural tendency to assume that others have read the design document.

SE Software Quality Assurance Preparations for a DR  Each participant is required to focus on distinct aspects of the process.  Review leader preparations  The main tasks of the review leader in the preparation stage are: To appoint the team members To schedule the review sessions To distribute the design document among the team members

SE Software Quality Assurance Preparations for a DR (…)  Review leader preparations  It is of utmost importance that the review session be scheduled shortly after the design document has been distributed to the review team members.

SE Software Quality Assurance Preparations for a DR (…)  Review team praparations  Team members are expected to review the design document and list their comments prior to the review session.  In cases where the documents are sizable, the review leader may ease the load by assigning to each team member review of only part of the document.

SE Software Quality Assurance Preparations for a DR (…)  Development team praparations  The team’s main obligation as the review session approaches is to prepare a short presentation of the design document.  Assuming that the review team members have read the design document thoroughly and are now familiar with the project’s outlines, the presentation should focus on the main Professional issues awaiting approval rather than wasting time on description of the project in general.

SE Software Quality Assurance The Design Review Session  The review leader’s experience in leading the discussions and sticking to the agenda is the key to a successful DR session.  A typical DR session agenda includes:  A short presentation of the design document.  Comments made by members of the review team.  Verification and validation in which each of the comments is discussed to determine the required actions (corrections, changes and additions) that the project team has to perform.

SE Software Quality Assurance The Design Review Session (…)  A typical DR session agenda includes:  Decisions about the design product (document), which determines the project’s progress. These decisions can take three forms: Full, approval, Partial approval, Denial of approval

SE Software Quality Assurance Post-review activities  Apart from the DR report, the DR team or its representative is required to follow up performance of the corrections and to examine the corrected sections.  The DR Report  One of the review leader’s responsibilities is to issue the DR report immediately after the review session.  Early distribution of the DR report enables the development team to perform the corrections earlier and minimize the attendant delays to the project schedule.

SE Software Quality Assurance Post-review activities (…)  The DR Report  The report’s major sections contain: A summary of the review discussions. The decision about continuation of the project. A full list of the required actions – corrections, changes and additions that the project team has to perform. For each action item, the anticipated completion date and project team member responsible are listed. The name(s) of the review team member(s) assigned to follow up performance of corrections.

SE Software Quality Assurance Post-review activities (…)  The Follow-Up Process  The person appointed to follow up the corrections, in many cases the review leader him or herself, is required to determine whether each action item has been satisfactorily accomplished as a condition for allowing the project to continue to the next phase.