 Every stage from phase DESIGN in Software Development Process will have “design document” especially in analysis and design phases.  “Design document”

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

1.Quality-“a characteristic or attribute of something.” As an attribute of an item, quality refers to measurable characteristics— things we are able to.
Damian Gordon.  Static Testing is the testing of a component or system at a specification or implementation level without execution of the software.
More CMM Part Two : Details.
PERTEMUAN - 2 SOFTWARE QUALITY. OBJECTIVES After completing this chapter, you will be able to: ■ Define software, software quality and software quality.
Testing Without Executing the Code Pavlina Koleva Junior QA Engineer WinCore Telerik QA Academy Telerik QA Academy.
SOFTWARE QUALITY ASSURANCE Maltepe University Faculty of Engineering SE 410.
Overview Lesson 10,11 - Software Quality Assurance
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.
SE 555 Software Requirements & Specification Requirements Validation.
OHT 22.1 Galin, SQA from theory to implementation © Pearson Education Limited Objectives of cost of software quality metrics 2.The classic model.
Chapter 8 Assuring the quality of external participants’ contributions
Software Quality Assurance
SQA Architecture Software Quality.
Development and Quality Plans
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
Release & Deployment ITIL Version 3
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.
SQA Architecture Software Quality By: MSMZ.
Introduction to Software Quality Assurance (SQA)
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.
Formal and Informal Peer Reviews
Lecture #9 Project Quality Management Quality Processes- Quality Assurance and Quality Control Ghazala Amin.
Overview of SQA Components
S Q A.
Software Project Management Lecture # 10. Outline Quality Management (chapter 26)  What is quality?  Meaning of Quality in Various Context  Some quality.
SacProNet An Overview of Project Management Techniques.
Galin, SQA from theory to implementation © Pearson Education Limited Chapter 8.2 Reviews.
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.
Formal Methods in Software Engineering
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.
Requirements Management with Use Cases Module 10: Requirements Across the Product Lifecycle Requirements Management with Use Cases Module 10: Requirements.
OHT 12.1 Galin, SQA from theory to implementation © Pearson Education Limited 2004 Introduction Types of external participants Risks and benefits of introducing.
Software Quality Assurance SOFTWARE DEFECT. Defect Repair Defect Repair is a process of repairing the defective part or replacing it, as needed. For example,
Software Quality assurance SQA - SWE 333
© Michael Crosby and Charles Sacker, 2001 Systematic Software Reviews Software reviews are a “quality improvement process for written material”.
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.
Prof. Mohamed Batouche An SQA Architecture Project Development plan and Quality Plan Ch.6 Pre-project SQA components Project Life.
Multitude of source of errors - various style of source of errors will affect the SQA components * The environment in which software development & maintenance.
Pertemuan 14 Matakuliah: A0214/Audit Sistem Informasi Tahun: 2007.
1 Definition Introduction and key stages Steps and standards used Plan Team Characteristics Implementation documentation Reviews & Audit Software Quality.
1 Definition Quality costs Plan Team Characteristics Implementation documentation Reviews & Audit Software Quality Assurance.
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.
Verification vs. Validation Verification: "Are we building the product right?" The software should conform to its specification.The software should conform.
Components of software quality assurance system overview
Software Quality Control and Quality Assurance: Introduction
Supporting quality devices
Software Configuration Management (SCM)
Components of software quality assurance system overview
Testing Process Roman Yagodka ISS Test Leader.
CMMI – Staged Representation
Software Quality Assurance
Chapter # 5 Supporting Quality Devices
Chapter # 6 Software Configuration Management
QA Reviews Lecture # 6.
Engineering Processes
Chapter # 3 The Components of SQA
Software Reviews.
3. Software Quality Management
Presentation transcript:

 Every stage from phase DESIGN in Software Development Process will have “design document” especially in analysis and design phases.  “Design document” is a document that will record all the progress of the development work in every stage.  The S.A who prepared the document will check in order to detect any error. In addition, development team leader are also will check this document before granting their approval to the next phase.  However, it is clear these are also the people that involved in producing the document, they are unlikely to detect some of their own error.  Therefore, only “others” such as peers, expert or customer representative are capable to review the document.

 After completing this chapter, you will be able:- ◦ Explain the direct and indirect objectives of review methodologies. ◦ Explain the contribution of external expert ◦ Compare the three major review methodologies.

 The review objective will be divided into two categories which is Direct Review Objective and Indirect Review Objective.  Direct review objective will deal with the current project.  Indirect review objective is more general in nature, deal with the contribution member knowledge and improvement of the development methodologies applied by the organization.

 Direct Objective ◦ To detect analysis and design errors as well as subjects where corrections, changes and completions are required ◦ To identify new risks likely to affect the project. ◦ To locate deviations from templates, style procedures and conventions. ◦ To approve the analysis or design product. Approval allows the team to continue on to the next development phase.

◦ Team members who need to coordinate their own codes with code modules developed by “non-complying” team members can be expected to encounter more than the usual number of difficulties when trying to understanding the software developed by the other team member. ◦ Individuals replacing the “non-complying” team member (who has retired or been promoted) will find it difficult to fully understand his/her work. ◦ The design review team will find it more difficult to review a design prepared by a non-complying team. ◦ The test team will find it more difficult to test the module;

 Indirect objectives ◦ To provide an informal meeting place for exchange of professional knowledge about methods, tools and techniques.  To record analysis and design errors that will serve as a basis for future corrective actions.

 The secretary is expected to perform the reporting task efficiently. However, it is expected that for performing the task he/she will require many clarifications to ensure correct reporting. The clarification questions will break the natural flow of review discussion, at least causing some waste of time. In cases where no clarification is requested by the secretary one may expect a proportion of wrong or incomplete documentation. Reporting by the coordinator himself is expected to be much more accurate and to mention the main findings. 

 Variously called “design review”, “DRs” and “formal technical review (FTR)”.  Different with other review where this is the only review that are necessary for approval of the design product..  Without this approval, the development team cannot continue to the next phase.  Conducted at any development milestone requiring completion of analysis or design document.

 DPR – Development Plan Review  SRSR – Software Requirement Specification Review  PDR – Preliminary Design Review  DDR – Detailed Design Review  DBDR – Data Base Design Review  TPR – Test Plan Review  STPR – Software Test Procedure Review  VDR – Version Description Review  OMR – Operator Manual Review  SMR – Support Manual Review  TRR – Test Readiness Review  PRR – Product Release Review  IPR – Installation Plan Review

 The choice of appropriate participants is of special importance because of their power to approve or disapprove a design product  Review leader Because review leader is a major factor affecting the DR’s success, certain characteristic are to be looked for this position:- ◦ Knowledge and experience in development of projects of the type reviewed. ◦ Seniority at a project level is similar if not higher than that of the project leader. ◦ A good relationship with the project leader and his team. ◦ A position external the project team  Therefore, example of the candidate will be development department’s manager, chief software engineer, leader of another project, head of software quality assurance unit.

 Review team Should be selected:- ◦ Senior members of the project team ◦ Customer-user representatives ◦ Software development consultant ◦ Recommended for non-project staff to make up majority of the review team.

 Review leader preparations ◦ Appoint team members ◦ Scheduled the review sessions ◦ Distribute design document among the team members  Review team preparations ◦ Review design document ◦ List their comments prior to the review session  It is important that review session be scheduled shortly after the design document has been distribute to the review team members. Because to reduce the risk of going off schedule.

 A short presentation of the design document.  Comments made by members of the review team.  Verification and validation of comments is discussed to determine the required action items (corrections, changes and additions). ◦ Verification:- Process of evaluating a system or component to determine whether the product of a given development phase satisfy the condition imposed at the start of the phase. ◦ Validation:- Process of evaluating a system or component during or at end of the development process whether it satisfies specified requirement.

 Decisions about the design product (document), which determines the project's progress: ◦ Full approval.  Enable immediate continuation to the next phase of the project. ◦ Partial approval.  Approval of immediate continuation to the next phase for some parts of the project with major action items is needed. ◦ Denial of approval.  Demands a repeat of the DR. This decision is applied in case of multiple major defects or critical defects.

Apart from DR report, the DR team is required to follow up performance of the corrections and check the corrected session. DR Report  One of the review leader responsibilities is to issue the DR report after review session.  Early distribution enables the development team to perform the corrections earlier and minimize the delays of the project schedule.

Report major sections contain:-  Summary of the review discussions  Decision about continuation of the project  Full list of the required actions  Name of the review team members assigned to follow up corrections performance.

 Two peer review method 1.Inspection 2.Walkthrough  Major difference between formal design and peer review is their participant and authority. Participant:-  DR participant are superior position to the project leader and customer representative.  Participant in peer review are project leader, member of the department and other unit. Degree of authority and objective review method  Formal design review are authorized to approve the design document.  This authority is not granted in peer review which the main objective for peer review is detecting errors.

 Different between inspection and walkthrough ◦ Inspection is more formal than walkthrough ◦ Inspection emphasizes the objective of corrective action ◦ Walkthrough are limited to comments on the document review.

 Review leader (moderator)  The author  Specialized professionals: ◦ Designer ◦ Coder or implementer ◦ Tester  Review leader (coordinator)  The author  Specialized professionals: ◦ Standards enforcer ◦ Maintenance expert ◦ User representative

PropertiesDesign reviewInspectionWalkthrough Overview meetingNoYesNo Participant’s preparations Yes - thorough Yes - brief Review sessionYes Follow-up of corrections Yes No Formal training of participants NoYesNo Participant’s use of checklists NoYesNo Error-related data collection Not formally required Formally required Not formally required Review documentation Formal design review report 1) Inspection session findings report 2) Inspection session summary report

 Task:- ◦ Preparing expert judgment about document. ◦ Participating as a member of internal design review, inspection or walkthrough team.  Will give more advantage in the following situations: ◦ Insufficient in-house professional capabilities in specialized area ◦ Lack of in-house professional due to workload pressures. ◦ In small organizations, where the number of suitable candidates for review team is insufficient.